JP2004151703A - 情報処理装置及び情報処理方法 - Google Patents

Abstract

【課題】カートリッジで供給されるトナーについて、契約内容及び印刷枚数に応じた課金を実現する。
【解決手段】ユーザ１０２の機器からプリント枚数データ８がサービスセンタ１０１に送信されると、サービスセンタ１０１ではユーザごとの、メンテナンス内容が異なる契約に応じた単価及びプリント枚数に基づいて課金を行い、ユーザ１０２に請求金額を通知する。また、サービスセンタ１０１でユーザ１０２の機器からトナーロウ情報１を得ると、トナー切れの時期を予測し、カートリッジの補充及び空きカートリッジの回収の通知をユーザ１０２に対して発する。
【選択図】図１

Description

本発明は、たとえばトナー等を充填したカートリッジなどといった消耗品を使用する、プリンタ等のデバイスにおける消耗品課金方法及び消耗品課金システムに関する。

従来、プリンタやファクシミリなどといった記録材、特に記録材としてトナーを消費する電子写真方式の機器には、トナーをカートリッジに封入し、トナーの残量が無くなったならカートリッジ毎交換するというカートリッジ方式の機器があった。この方式は、カートリッジの交換が容易に行え、また、カートリッジに転写体などの他の消耗部品を設けておけば、その部品もカートリッジの交換とともに交換でき、保守が非常に容易であるという利点がある。また、カートリッジに機器の構成の一部を分け持たせることで、機器本体の製造原価を引き下げることができる。

このカートリッジ（以下、ＣＲＧと略称することもある）は、それを使用する機器のメーカーから販売チャネルを通じて機器ユーザに販売されるのが普通であり、また、使用済みのカートリッジも機器メーカにより回収される。

図３１（Ａ）はカートリッジの販売形態を示す図である。カートリッジは販売店からユーザにその代金と引き替えに売り切り形態で販売され、ユーザは買い取ったカートリッジをユーザ自身で管理する。ここでいう売り切り形態とはユーザーにカートリッジ（ＣＲＧ）を完全に買い取ってもらう形態である。

図３１（Ｂ）は、従来、使用済みカートリッジの回収がどのように行われていたかを示す図である。この図に示したように、ユーザは、使用済みのカートリッジを販売店に持ち込んだり、あるいは、回収用の箱に入れて回収拠点あてに送ることで回収する方法が一般的であった。

また、図３１（Ｃ）として、従来の機器本体のメンテナンスの形態を示す。このように、機器本体も、カートリッジなどの消耗品も売り切り形態で販売されていたために、保守契約を販売店と結ばないかぎり、ユーザは、ユーザ自身で機器を保守するか、あるいは、必要に応じて修理（スポット修理）を依頼する必要があった。

一方、このような売り切り形態とは別に、クリックチャージと呼ばれる課金方式もある。これは複写機などに用いられている方式である。この方式では、複写機に複写した枚数を数えるためのカウンタを備え、定期的に、あるいはユーザの要請に応じて技術者がユーザのサイトに出向き、技術者は複写機の保守を行うとともにカウンタの値を読み、その値と前回チェックしたカウンタ値との差分を複写枚数として記録する。そして、その複写枚数に応じた金額と、保守の費用との合計値を郵便等を介してユーザに請求する。

しかしながら、プリンタのようにカートリッジの売り切り方式では、トナーがなくなる（トナー切れ）時期を予想できず、かつ、交換時期が一定ではないので、機器の保守及び消耗品の購入に必要とされる予算の管理が難しい。例えば、修理やカートリッジの交換をするとその都度費用を支払う必要がある。また、プリント枚数やプリンタの稼働状況を把握できず、正確に経費を見積もることが難しい。

また、プリンタなどは業務時間中には常時使用可能にしておかねばならないため、トナー切れが生じたなら直ちに交換できるよう、常時予備カートリッジを確保しておかなければならない。カートリッジのための保管場所を設けて常時在庫をおくことになれば、そのための費用が発生することになる。

一方複写機などで用いられるクリックチャージ方式は、ユーザが複写枚数を知ることができ、予算化しやすいという利点はあるものの、定期的あるいは非定期的に技術者がユーザサイトに出向かねばならないため、保守の費用が高くつくという問題点があった。また、トナー切れなどが生じた場合に直ちに対応するためにはユーザ自身がトナーの補給を行わねばならないという点、また、そのための予備トナーを常時用意しておかねばならないという点は、カートリッジの売り切り方式と同様であった。

さらに、複写機などでは、トナーを補給する方式であるのでトナーに無駄がでず、クリックチャージ方式が実現できたが、カートリッジ式の機器にそのままクリックチャージ方式を適用すると、カートリッジ内に残存して廃棄されるトナーが無駄となり、原価を押し上げる要因となる。このために、クリックチャージ方式をプリンタ等、一般の機器にまで適用することができなかった。

また、カートリッジ方式を採用しない複写機においては、複写枚数に応じて、部品の劣化が進行し、これに伴う部品交換等定期的な保守作業が必要となり、それ故クリックチャージ方式を適用する場合が多かった。しかしながら、トナー及び現像器等を収納するプロセスカートリッジ（以下、単に「カートリッジ」という）を用いるプリンタにおいては、消耗品や劣化による故障を生じ易い部品の多くがカートリッジ内に収納されているため、特に形成装置本体の使用年数があまり経過しない場合にはサービスマン等に修理を依頼することは希であり、また、通常、定期的な保守、点検は行われない。しかも、プリント枚数が多くても、必ずしも保守に要する費用が大きくなるとは限らない。したがって、通常、カートリッジ式のプリンタにおいて保守契約が結ばれる場合、保守サービス料金は出力枚数に拘わらず一定となっている。

一方、プリンタにおけるカートリッジ方式は、消耗品の補充と部品の交換とが、一度にかつ容易にできること、保守、点検の点から見て優れているが、環境問題の立場から、使用済みのカートリッジが問題となる。各メーカーは、使用済みのカートリッジを回収、分解、再利用に努めており、環境問題を解決するためには、使用済みのカートリッジの回収率の向上が不可欠である。

また、プリント不能になる前にトナー切れの警告を発するプリンタも多いが、斯かる警告がされたとしても、数十枚〜数百枚のプリントは可能であり、警告後すぐにカートリッジを交換するユーザーは少ない。したがって、ユーザーは、トナー残量が少なくなったとき、プリントのかすれによる再プリントを強いられたり、カートリッジを取り外し、左右に振って再装着するなどの手間を強いられるという問題があった。

また、近年複写機能、スキャナー機能、プリンタ機能を同時に有した複合機が普及してきたが、このような機器に関しては複写機、プリンタ等の区別がなく、また、複写機能を主なものとしている機器においても、カートリッジ方式を採用するものも販売されるようになった。このような機器の場合カートリッジ方式を採用するものの、多機能化に伴う部品増加等の理由により、一般家庭で使用されるようなプリンタ機器のように保守メンテナンスが不必要というわけではなくなった。また、複合機にかかわらず、高速出力画像形成装置においては、カートリッジ方式を採用していても保守メンテナンスをする必要があり、特にある程度の期間使用しつづけた場合には、部品の消耗等の原因により保守メンテナンスが必要となる。このような状況のもと従来の保守契約形態では対応しきれなくなるという問題点が発生してきた。例えば、保守サービスは印刷枚数に応じた料金体系（クリックチャージ）で契約し、カートリッジ代金は別途支払う体系等も考えられるが、支払いが非常に複雑でありユーザ及び前記支払いを受けるサービスマンにとっても不便なものである。

本発明は上記従来例に鑑みてなされたもので、機器の消耗品使用量に応じた課金を行うことで消耗品の費用をより正確に把握することができるとともに、ユーザサイトに存在する機器全体についてその消耗品の消費量を把握し、その消費量に応じた課金を行うことができる消耗品課金システム及び方法を提供することを目的とする。

また本発明の更なる目的は、カートリッジを用いることによるプリンタにおける利便性を維持しつつ、トナー残量が少なくなったときの利便性を向上するとともに、カートリッジの回収率を向上することができる課金システム及び方法を提供することである。

また本発明の更なる目的は、ユーザが使用する画像形成装置の使用状態、または、画像形成装置の機種等にも応じたような、より柔軟な且つ利便性の高い保守契約をユーザに提供できるようなの仕組みを提供することにある。

また本発明の更なる目的はユーザが契約内容を変更した場合にも、ユーザが複数の契約の中からより適切な保守契約を選択することができるような仕組みを提供することにある。

上記目的を達成するために、本発明は次のような構成を有する。

画像形成装置に係る複数種類の契約を管理する情報処理装置において、
前記画像形成装置における印刷枚数の情報をネットワークを介して取得する取得手段と、
画像形成装置のサービスマンによるメンテナンス内容が異なる契約に応じて、印刷出力１枚あたりの課金金額を異ならせて記憶する記憶手段と、
前記取得された印刷枚数と、前記画像形成装置における契約に応じて前記記憶手段に記憶された前記画像形成装置の印刷出力一枚あたりの課金金額と、に基づいて請求金額を計算する計算手段とを有する。

また好ましくは、前記記憶手段には、サービスマンによるメンテナンス内容が異なる第１種契約と第２種契約との夫々に対応して印刷出力一枚当たりの第１課金金額と第２課金金額とが記憶されており、前記第２課金金額は前記第１課金金額に所定料金が加算されている。

また好ましくは、前記契約を指示するための、ブラウザーで読込み可能な契約指示画面情報を外部装置に供給する供給手段をさらに有し、前記計算手段は、前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算する。

また好ましくは、前記契約を指定するための契約指示画面情報に基づく画面を介しての指示を受付ける手段をさらに有し、前記計算手段は、前記受付けた契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算する。

また好ましくは、前記契約を指示するための契約指示画面情報に基づく画面を介して入力された契約の種別と、該種別の契約に対応する期間の指示を受付ける手段をさらに有し、前記計算手段は、前記受付けた前記期間に対応して取得された印刷出力枚数と、前記期間に対応する契約の種別に対応する印刷出力一枚当たりの課金金額とに基づき前記期間における請求金額を計算する。

また好ましくは、プリンタを識別する識別子と該識別子に対応する契約を確認する画面を外部装置に送信する送信手段をさらに有する。

また好ましくは、前記画像形成装置の稼動情報に基づき最適な契約情報を検索し通知する通知手段をさらに有する。

また好ましくは、前記稼動情報には使用状況、及び、故障状況が含まれる。

あるいは本発明は以下のような構成を有する。

画像形成装置に係る複数種類の契約を管理する情報処理装置において、
前記画像形成装置における契約が、サービスマンによるメンテナンス内容が第１内容の第１種契約か、メンテナンス内容が第２内容の第２種契約か、を管理する管理手段と、
前記画像形成装置における印刷枚数の情報をネットワークを介して取得する取得手段と、
前記画像形成装置の契約が第１種契約か第２種契約かに応じて前記画像形成装置に対応させて印刷出力一枚当たりの課金金額を異ならせて記憶する記憶手段と、
前記取得された前記画像形成装置の印刷枚数と、前記画像形成装置に対応させて前記記憶手段に記憶された印刷出力一枚当たりの課金金額と、に基づき請求金額を計算する計算手段とを有する。

また好ましくは、前記契約を指示するための契約指示画面情報を外部装置に提供する提供手段をさらに有し、前記計算手段は、前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算する。

あるいは本発明は以下のような構成を有する。

画像形成装置に係る複数種類の契約を管理する情報処理装置において、
画像形成装置における契約を指示するための契約指示画面情報を外部装置に供給する供給手段と、
前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約の種別を画前記像形成装置に関連付けて管理する管理手段と、
前記指示された契約の種別に対応した印刷出力一枚当たりの課金金額を前記画像形成装置と関連付けて記憶する記憶手段と、
前記画像形成装置の印刷出力枚数を通信回線を介して取得する取得手段と、
前記取得手段により取得した前記印刷出力枚数と、前記記憶手段に記憶された前記画像形成装置の印刷出力一枚あたりの課金金額と、に基づき請求金額を計算する計算手段とを有する。

本発明によれば次のような効果が得られる。
（１）消耗品が消尽する時期を予測し、その時期に消耗品の交換を行うために、消耗品を使い切らせることができ、資源の節約や原価の低減に寄与する。
（２）利用者が複数のデバイスを利用していても、それらのデバイスで使用される消耗品に対してまとめて課金することができる。このため、利用者単位で課金や保守を行うことができる。
（３）保守メンテナンス料金をデバイスが印刷出力した１枚あたりの課金金額に含めるようにしたので、ユーザからの保守契約内容の変更があった際にも柔軟に対応するシステムを提供することができる。課金テーブルをサービスセンタに設けることにより、デバイス機器毎、消耗品毎、ユーザ毎に対応した１枚当たりの印刷出力料金を設定することが可能となり、ユーザのニーズにあった保守契約を提供するシステムの構築が可能となった。
（４）ユーザインターフェースを介してユーザーは希望する保守形態に応じて、スポット保守契約、基本保守契約、総合保守契約等複数の契約条件を任意に選択することが可能となり、ユーザーはこれらの契約条件を、任意の期間で選択・変更する事が出来る。

本発明に係る実施の形態であるカートリッジ管理システムの詳細を説明する前にその特徴を説明する。

（１）プリント枚数に応じた課金システム（プリント枚数課金システム）がカートリッジ式プリンタについて実現されている。これにより次のような効果が得られる。
・売り切り形態では一度に代金を支払うのに対して、ユーザーは印刷費用の支払いを分散させることができる。
・プリンタ単位での使用枚数や、保守に要する金額の把握が可能となる。このため、プリンタを部署単位でまとめれば、部署単位等での保守に要する金額の把握も容易である。
・プリンタに加えて、カートリッジ管理システムに組み込まれた複数の機器すべてを含めた一括管理が可能となる。これにより、大量に消耗品を消費するユーザに対しては値引き（ボリュームディスカウント）をおこなうなど、ユーザ毎のサービスが可能となる。
・ネットワークを利用してシステムを自動化している。これによりシステムの管理のために人件費をかけずに済む。従来のクリックチャージ方式では、人手を要するために、カウンタを確認しに行くこと自体がコスト増の要因となっていた。
・プリンタの状態をネットワークで把握し、サービスマンのユーザー訪問回数を最小限におさえることができる。
・ユーザがプリンタを使用する限りそれに対して課金できるために、売り手にとっては収益の安定化が可能となる。これはユーザにとってもサービス性の向上という効果を及ぼす。

（２）カートリッジの配送及び回収をネットワークを用いてシステム化した。これにより次のような効果が得られる。
・ 配送及び回収をネットワーク上で手配してしまうことで、手配に関する手間を減らし、コストの引き下げに貢献する。
・メンテナンスとの組み合わせにより、高付加価値なシステムとすることができる。
・管理はすべてサービスセンタでおこなうために、ユーザーはプリントするだけでよい。
・使用済みカートリッジの回収を、より確実に行える。
・プリンタの状態をサービスセンタで把握しているために、消耗品切れや修理要求に迅速に応答でき、ダウンタイムを減少させることができる。

（３）カートリッジに不揮発性記憶媒体を持たせ、任意のデータを格納できるようにした。これにより次のような効果が得られる。
・カートリッジ毎により正確なデータを収集できる。
・このため配送・回収の日程をより正確に作成できる。
・トナー切れをより正確に予測できるので、トナー切れを発生させずにトナーをできるだけ多く使用することができる。これは資源の節約や経費削減に貢献する。

以下、上記特徴を有するカートリッジ管理システムについて説明する。

［第１の実施の形態］
＜システム構成＞
図２はカートリッジ管理システムのシステム構成の一例を示す図である。本システムは、公衆線や専用線といった電話回線やインターネットなどの遠隔通信網２０５を介して接続された機器メーカのサービスセンタとユーザサイトとを有する。通常、ひとつのサービスセンタに対して複数のユーザサイトが接続され、またサービスセンタも複数存在し得るが、ここではひとつのサービスセンタとひとつのユーザサイトに限って説明する。なお、本実施形態のユーザサイトとは、特に本システムのプリント枚数課金方式でサービス及び課金を実施するとの契約を機器メーカあるいは販売店と交わしたユーザである。また、サービスセンタは、ユーザと契約した機器メーカや販売店により設けられており、ユーザに対して保守やカートリッジの配送及び回収サービスの提供や、課金などを行う。

サービスセンタ１０１においては、ゲートウエイ２０２が遠隔通信網２０５と接続されている。このゲートウエイ２０２には、後述するデータベースを管理するためのデータベースサーバ２０１と、パーソナルコンピュータ（ＰＣ）２０３と、ＬＡＮを管理するためのネットワークサーバ２０４とがＬＡＮにより接続されている。ここでいうゲートウエイにはルータも含まれている。データベースサーバ２０１には後述するデータベース１９９９が構築されている。また、サービスセンタ１０１における処理を遂行する窓口端末としてＰＣ２０３が利用される。窓口端末であるＰＣ２０３では、後述する図１０乃至図１２におけるサービスセンタ側の処理を行うためにサービスモジュール２１０と、トナー切れの予測を行うための分析システム（分析モジュール）２２０とが実行される。また、窓口端末２０３では、ユーザインターフェース画面の表示なども行う。なお、このサービスセンタの構成は一例であり、遠隔通信網２０５からのデータをＰＣ２０３に取り込む仕組みと、ＰＣ２０３からデータベース１９９９にアクセスする仕組みとがあれば十分である。

ユーザサイト１０２においては、ゲートウエイ２０７が遠隔通信網２０５に接続されている。そのゲートウエイ２０７には、ＬＡＮによってＰＣ２０８とプリンタ１００ｂとが接続されている。ＰＣ２０８はローカルプリンタ１００ａを有している。プリンタ１００ｂ及びＰＣ２０８は、ＬＡＮを介して遠隔通信網２０５にアクセスすることができる。さらに、ユーザサイトには、ゲートウエイ２０７とは別の回線で遠隔通信網２０５に接続されたファクシミリ２０６がおかれている。ユーザサイトにおける処理を遂行する窓口端末としてはＰＣ２０８が利用される。窓口端末であるＰＣ２０８では、後述する図１１乃至図１２におけるユーザサイト側の処理を行うためのユーザモジュール２５０が実行される。また、ファクシミリ２０６やプリンタ１００ｂといった、遠隔通信網２０５に直接アクセス可能なデバイスには、後述する図１０や図１２におけるトナーロウ信号やプリント枚数といったデバイス発のデータをサービスサイトに送信するためのデバイスモジュール２４０が含まれる。また、デバイスモジュール２４０は後述するデバイスモジュール２３０とも同等の機能を有する。ホストを介して遠隔通信網２０５に接続されるプリンタ１００ａのようなデバイスでは、図１０や図１２におけるトナーロウ信号やプリント枚数といったデバイス発のデータをホストに送信するためのデバイスモジュール２３０が含まれる。この場合には、デバイスから受信した信号をサービスサイト１００に送信するための転送モジュールはホストに含まれる。

このように、ユーザサイト１０２の各機器とサービスセンタ１０１との間は、常時、あるいは必要に応じて接続され、互いに通信することが可能となっている。

なお、以下単にユーザサイトあるいはサービスセンタと記載した場合には、それぞれの窓口端末を指す。本例では窓口端末はそれぞれのサイトのＬＡＮに接続されたコンピュータであるが、各窓口端末同士を直接遠隔通信網２０５によって接続したネットワークを形成していても良い。また、ユーザサイト１０２のプリンタ及びファクシミリはすべてプリント枚数課金方式で課金されるものとする。

（コンピュータ）
図３にパーソナルコンピュータのブロック構成図を示す。ＰＣは、ＲＯＭ３０７に書き込まれたプログラム、あるいはＲＡＭ３０２に書き込まれたＯＳやアプリケーションプログラムをＣＰＵ３０１により実行することで、各種制御や後述する手順（例えばサービスモジュールやユーザモジュールなど）を実現する。ＨＤ３０３及びＦＤ／ＣＤ（フロッピ（登録商標）ディスクドライブまたはＣＤドライブ）３０８はファイル記憶媒体で、プログラムファイルやデータファイルを格納する。特にＦＤ／ＣＤ３０８は、記憶媒体が交換可能であり、データやプログラムをその媒体からＰＣに供給することができる。キーボード及びポインティングデバイス３０９は、利用者が入力を行うための入力デバイスであり、ディスプレイ３０４とともに、後述するユーザインターフェースなどを実現している。ＬＡＮインターフェース３０６はＬＡＮに接続するためのインターフェース回路である。プリンタインターフェース３０５はＰＣにプリンタをローカル接続するためのインターフェースで、図２の例ではＰＣ２０８だけが使用している。リモートインターフェース３１０は、モデムやルータなど、遠隔通信網２０５に接続するためのデバイスであり、図２では、ゲートウエイ２０２及びゲートウエイ２０７が使用している。遠隔通信網は電話回線に限らないので、電話回線でない場合（例えばケーブルＴＶ回線、無線通信回線）にはその通信網に即したインターフェースが用いられる。このような構成により、サービスセンタ及びユーザサイトのコンピュータは互いに接続される。

（ファクシミリ）
図４は、ファクシミリ２０６の構成を示す断面図である。図２において、リーダ部１の原稿給送装置４１０１は原稿を最終頁から順に１枚ずつプラテンガラス４１０２上へ給送し、原稿の読み取り動作終了後、プラテンガラス４１０２上の原稿を排出する。原稿がプラテンガラス４１０２上に搬送されると、ランプ４１０３を点灯し、そしてスキャナユニット４１０４の移動を開始させて、原稿を露光走査する。この時の原稿からの反射光は、ミラー４１０５，４１０６，４１０７、及びレンズ４１０８によってＣＣＤイメージセンサ（以下ＣＣＤという）４１０９へ導かれる。このように、走査された原稿の画像はＣＣＤ４１０９によって読み取られるＣＣＤ４１０９から出力される画像データは、画像入出力制御部４１１０へ転送され、エンコードされて、画像入出力制御部４１１０に接続された不図示の回線を介して遠隔通信網上の宛先へと送信される。

一方、遠隔通信網からファクシミリ信号を受信すると、それをデコードし、デコードされた画像データに応じて、プリンタ部２のレーザドライバ４２２１によってレーザ発光部４２０１を駆動する。そうして、画像データに応じたレーザ光をレーザ発光部４２０１に発光させる。このレーザ光は感光ドラム４２０２に照射され、感光ドラム４２０２にはレーザ光に応じた潜像が形成される。この感光ドラム４２０２の潜像の部分には、トナーカートリッジ４２０３に含まれる現像器によって現像剤が付着される。そして、レーザ光の照射開始と同期したタイミングで、カセット４２０４及びカセット４２０５のいずれかから記録紙を給紙して転写部４２０６へ搬送し、感光ドラム４２０２に付着された現像剤を記録紙に転写する。現像剤の乗った記録紙は定着部４２０７に搬送され、定着部４２０７の熱と圧力により現像剤は記録紙に定者される。定着部４２０７を通過した記録紙は排出ローラ４２０８によって排出され、ソータ４２２０は排出された記録紙をそれぞれのピンに収納して記録紙の仕分けを行う。なお、ソータ４２２０は仕分けが設定されていない場合は最上ピンに記録紙を収納する。また、両面記録が設定されている場合は、排出ローラ２０８のところまで記録紙を搬送した後、排出ローラ４２０８の回転方向を逆転させ、フラッパ４２０９によって再給紙搬送路へ導く。多重記録が設定されている場合は、記録紙を排出ローラ４２０８まで搬送しないようにフラッパ４２０９によって再給紙搬送路へ導く。再給紙搬送路へ導かれた記録紙は上述したタイミングで転写部４２０６へ給紙される。このようにしてファクシミリ２０６は、画像の送受信を実現している。

図７は、ファクシミリ２０６の制御構成を示す。図７において、ＲＯＭ７０６にはプリンタを駆動するために制御プログラムやフォントデータなどが格納されており、ＣＰＵ７０１により、デバイスモジュールを含むそのプログラムを実行することでファクシミリ受信や印刷動作が実現される。外部メモリ７０５には、外部から供給されるデータ等が格納される。操作部７０７は表示部と一体となったパネルであり、これによって状態が表示されるほか、使用者が操作入力を行うことができる。リモートインターフェース７０３は、モデムなど遠隔通信網２０５に接続するためのインターフェースのひとつである。

スキャナ部７０４は図４のスキャナ部１であり、印刷部７０８は図４に示したプリンタ部２に相当する。印刷部７０８にはカートリッジ４２０３が装着される。カートリッジ４２０３には不揮発性の書込み可能なメモリ４２０３ａが備えられており、カートリッジ４２０３の装着とともに、メモリ４２０３ａはファクシミリ２０６の制御部と電気的に接続されて、ＣＰＵ７０１、あるいは、印刷部７０８がローカルに有する不図示のＣＰＵから書き込み及び読み出しが可能となる。メモリ４２０３ａから読み出されたデータは、ＬＡＮインターフェース７０４あるいはホストインターフェース７０３を介してＬＡＮあるいはホストに送出することができる。なお、メモリと制御部とは必ずしも電気的な接点で接続しているとは限らず、電波や光信号などの非接触の形態でも接続され得るが、ここでは信号を送受可能なこれらの接続形態を含めて単に電気的な接続と呼んでいる。

（プリンタ）
図５はプリンタ１００ａ，１００ｂの断面図を示す。図５において、印刷するための用紙は、用紙カセット８０２あるいは８０５のいずれかから、給紙ローラ８０３，８０６及び搬送ローラ８０４，８０７により供給される。いずれの給紙カセット用いるかは、このプリンタを用いるホストコンピュータ等から印刷時に指定される。用紙は、レジストローラ８０８を経てトナーカートリッジ８１０の下をとおり、感光ドラム８１１上に形成されたトナー像が、転写ローラ１５の電荷により用紙に転写される。感光ドラム上のトナー像は、レーザスキャナユニット８０９から発せられ、反射鏡８１７で反射された、画像信号により変調されたレーザビームにより形成された静電潜像に、トナーを付着させて現像させたものである。

トナー像が転写された用紙は定着ドラム８１２により加熱され、溶融したトナーは用紙上に定着する。定着ローラを通過した用紙は、両面デフレクタ８１３により、両面ユニット８２０へ入るか、あるいは排出されるか方向付けられる。用紙が上方へ向けられて排出される場合には、さらにフェイスアップ／フェイスダウンセレクタ８１４により、排出径路が切り換えられる。フェイスダウン排出の場合には、用紙は図の右方向へと向けられ、フェイスダウン排出ローラ８１５によりフェイスダウン排出トレイ８１６上に直前に印刷された面を下にして排出される。フェイスアップ排出が選択された場合には、フェイスアップ排出口８１９から、印刷された面を上にして不図示のトレイ上に排出される。フェイスアップ／フェイスダウンセレクタの位置は、センサによって検出され信号として出力される。

一方、両面印刷が選択されている場合、両面ユニット８２０へ入った用紙は、搬送ローラ８２１により搬送されて両面トレイ８２６上に一旦載置される。片面の印刷が済んだ用紙は両面トレイから給送ローラ８２２により搬送される。搬送された用紙は、一旦両面パス８２４まで送られ、用紙の後端がほぼ両面搬送ローラ８２３に達すると、回動の中心が略両面搬送ローラ８２３と一致している反転デフレクタ８２５を、左端が径路８２８に達するまで回転させる。その状態で用紙を逆方向（図の左側）に向けて搬送すると、用紙の左端はデフレクタにより持ち上げられてそのまま両面パスピックアップローラ８２８により搬送され、レジストローラ８０８に達する。後は、通常の印刷と同じ径路・手順で画像が形成される。

両面印刷時には、その印刷の制御はホストコンピュータからの指示で行われる。例えば、効率的に印刷するために、用紙を１枚ずつ両面に印刷して排出するのではなく、給紙トレイと両面トレイとから交互に用紙を現像部に供給して交互に印刷するといった制御方法がある。すなわち、印刷の順序としては、「１枚目表」→「２枚目表」→「１枚目裏」→「３枚目表」→「２枚目裏」→「４枚目表」→「３枚目裏」→…→「最後から３枚目裏」→「最後の１枚表」→「最後から２枚目裏」→「最後の１枚裏」のように、最初と最後でそれぞれ表と裏の印刷が連続することを除き、表と裏の印刷を交互に行う。表面が印刷された用紙は両面ユニットに送り込まれ、裏面が印刷された用紙はそのまま排紙トレイ上に排出される。すなわち、給紙トレイから供給された用紙に画像が形成されるその用紙は両面トレイに送られ、両面トレイから送られてきた用紙に画像が形成されると、その用紙は排紙トレイに排出される。

両面印刷時の制御はこれに限ったものではなく、１枚ずつ両面を印刷して次の用紙にも同様に両面を印刷する、といったように印刷を進めることできる。このような制御は、ホストコンピュータからの命令によって切り換えることができる。

また、両面トレイに複数枚の用紙が載置できるならば、両面トレイに載置できる枚数だけ片面印刷し、そのあとで、両面トレイから順次用紙を取り出してもう片方の面に印刷することもできる。これも、両面トレイ上の容量をホストコンピュータが知ることができれば、ホストコンピュータから制御の仕方を切り換えることができる。

ホストコンピュータからの命令に応じて、制御ユニット８０１によりプリンタ全体の制御がおこなわれる。さらに、両面ユニット８１０は着脱が可能であり、それが取り付けられているか、取り外されているかという情報は、センサにより検知されてホストコンピュータへと渡される。

ここで、筐体は、カートリッジ８１０上で開閉自在なカバーとなっており、そのカバーの開閉はセンサによって検知することができる。また、カートリッジにメモリが備えられている場合には、そのメモリに対して、データの読み出し及び書き込みを行う手段が用意されている。

また、カートリッジ内のトナー残量が所定量まで減少したことを示すセンサがカートリッジには内蔵されており、プリンタ、あるいは後述するファクシミリなどのデバイスは、そのセンサからの検出信号を受けて、トナーロウ信号を出力する。すなわち、トナーロウ信号は、トナー残量が所定の量に達したことを示す信号である。このトナーロウ信号は、カートリッジに残量センサが備えられている場合にはカートリッジからの検出信号を受けて発生される。しかしながら、残量センサを持たないカートリッジを使用するデバイスは、プリント枚数と印字率とをカートリッジ交換時を初期状態として印刷の都度更新することで、おおよその残量を推定し、トナーロウ信号を発生することができる。

図６は、プリンタ１００ａ，１００ｂの制御構成である。図６において、ＲＯＭ６０６にはプリンタを駆動するために制御プログラムやフォントデータなどが格納されており、ＣＰＵ６０１によりそのプログラムを実行することで印刷動作が実現される。外部メモリ６０５には、外部から供給されるデータ等が格納される。操作部６０７は表示部と一体となったパネルであり、これによって状態が表示されるほか、使用者が簡単な操作入力を行うことができる。ホストインターフェース６０３はパーソナルコンピュータなどのローカルプリンタとしてプリンタを接続するためのインターフェースであり、図２においてはプリンタ１００ａがこれを使用している。ＬＡＮインターフェース６０４はＬＡＮに接続するためのインターフェースであり、図２においてプリンタ１００ｂがこれを介してＬＡＮに接続されている。

印刷部６０８は図５に示した機構そのものであり、カートリッジ８１０が装着される。カートリッジ８１０には不揮発性の書換え可能なメモリ８１０ａが備えられている。カートリッジ８１０の装着とともに、メモリ８１０ａはプリンタ１００ａあるいは１００ｂの制御部と電気的に接続されて、ＣＰＵ６０１、あるいは、印刷部６０８がローカルに有する不図示のＣＰＵから書き込み及び読み出しが可能となる。メモリ８１０ａから読み出されたデータは、ＬＡＮインターフェース６０４あるいはホストインターフェース６０３を介してＬＡＮあるいはホストに送出することができる。

（カートリッジの構成）
図８にカートリッジ８１０あるいは４２０３（以下単にカートリッジ８１０と呼ぶ）の構成を示す。カートリッジ８１０は図のようにプリンタ１００ａ、１００ｂあるいはファクシミリ２０６に装着される。カートリッジ８１０には半導体メモリ８１０ａ（カートリッジ４２０３については４２０３ａ）が取り付けられており、カートリッジの装着によってプリンタ本体に電気的に接続され、読み書きが可能となる。また、図８には示していないが、図９に示すデータ、特にカートリッジタイプＩＤ／シリアル番号や総印刷枚数、トナー残量等を表示するための表示パネルを設けても良い。カートリッジタイプＩＤ／シリアル番号は製造時に決定されて変更されることはないのでカートリッジの筐体に印刷する、シールとして貼り付けるなどして記録しても良い。総印刷枚数やトナー残量は、カートリッジの使用に応じて変わる値であるので、これらの値を表示するためには表示パネルが必要となる。表示パネルとしては、その制御回路やバックアップ電源とを含む小型の液晶表示パネルなどを用いることができる。また、例えば強誘電性液晶など電源を遮断しても表示状態を残すことができる表示デバイスを利用すれば、電源は機器本体から供給して、カートリッジには表示パネルを取り付けるだけで済む。表示パネルを有する場合には、後述するトナー残量の送信タイミングに合わせたり、あるいは定期的に、カートリッジを利用するデバイスによって表示を更新する。

このように、そのカートリッジタイプＩＤ／シリアル番号といった識別子や、トナー残量や印刷枚数といったカートリッジの状態に関する情報をカートリッジ自体に表示させることで、未使用のカートリッジと使用されているカートリッジとをカートリッジの外観により判別することができる。このため、例えばカートリッジを交換する際に、使用済みのカートリッジを新たなカートリッジであるとオペレータ（ユーザあるいはサービスマン）が誤認識し、使用済みのカートリッジを装着してしまうといったことを防止できる。

図９はメモリ８１０ａに格納されるデータの一例を示す図である。メモリ８１０ａには、そのカートリッジを用いて印刷された全枚数及び全ジャム枚数を示す総カウント／総ジャムカウント、サイズ毎の印刷枚数とジャム枚数９０２，９０３が格納される。これらのカウンタは、このカセットが装着されたデバイスによって、１ページの印刷を行う毎に加算される。トナー残量９０４には、トナーの残量そのものを示す値を格納しても良いが、所定量までトナーが減少したことを検知する不図示のセンサの出力（すなわちトナーロウ出力）をフラグとして格納しても良い。

さらに、メモリ８１０ａには、カートリッジ個々を識別するためのカートリッジＩＤ／シリアル番号９０７が格納される。カートリッジＩＤ／シリアル番号９０７は、製造時あるいは出荷時に予め書き込まれる。さらに、メモリ８１０ａには、トナー切れ通報などの宛先となるサービスセンタ宛先といったデータが格納されていてもよい。

使用開始日／終了日９０５はそれぞれ使用が開始された日付と使用が終了した日付を格納する。このためには、例えば、カートリッジのカバーの開閉センサによりカバーが開閉されたことを検知した場合に、予め保存しておいた使用中のカートリッジＩＤ／シリアル番号と、カートリッジから読み出したカートリッジＩＤ／シリアル番号とを比較し、不一致であればカートリッジが交換されたものとみなしてそのときの日付を使用開始日として書き込めばよい。また、例えば２４時間おきに日付を必ず使用終了日として書き込めば、使用終了日を記録できる。使用期間９０６も、使用終了日と同時に、使用開始日から使用終了日までの期間を書き込んでおけばよい。

本実施形態のシステムでは、以上のようなデータをカートリッジに保持している。なお、以下、単に印刷枚数といった場合には、サイズ毎の印刷枚数や総印刷枚数など、印刷枚数に関するすべてのデータを含むものとする。

＜カートリッジ管理及び課金手順＞
次に、前記システムにおけるカートリッジの交換管理手順を説明する。なお、ユーザサイトとは、特に本カートリッジ管理システムでサービス及び課金を実施するとの契約を機器メーカあるいは販売店と交わしたユーザを指す。図１は管理手順の概略を示している。

ユーザサイト１０２におけるプリンタ１００ａや１００ｂ、あるいはファクシミリ２０６において、トナーが所定量以下にまで減少する状態、すなわちトナーロウ（Toner Low）が発生すると、トナーカートリッジに内蔵されたセンサによってそれが検知される。この状態はユーザサイト１０２からトナーロウ信号(1)としてサービスセンタ１０１に通報される。なお、単にサービスセンタと呼んでいるが、具体的にはサービスセンタ１０１においてサービスモジュールが機能するＰＣ２０３に対してこの通報は送信される。

この通報をＰＣ２０３によって受信したサービスセンタ１０１は、配送業者１０３に対して、ユーザサイト１０２への新しいトナーカートリッジの配送及び使用済みカートリッジの回収の依頼(2)を出し、配送業者１０３から配送の日程についての回答(3)を得る。

サービスセンタ１０２は、配送業者から得た回答に基づいて、ユーザサイト１０２にカートリッジの配送及び回収の通知(4)を送信する。ただし、後述するとおり、この通知は単純に送信されるのではなく、ユーザとの日程調整のシーケンスを含む。また、本発明における通知とは情報の送信処理を指すものである。なお、サービスセンタ１０１からユーザサイト１９２に対してデータが送信されるといった場合には、具体的には、サービスセンタのＰＣ２０３から、ユーザサイトにおいてユーザモジュールが機能するＰＣ２０８に対してデータは送信される。

一方、配送業者１０３は、カートリッジの配送及び回収の通知(4)で決定された日程をサービスセンタ１０１から受け、その日程に従ってユーザサイト１０２に新しいカートリッジの配送(5)、及び、使用済みのカートリッジの回収(6)を遂行する。配送業者１０３は更に、回収したカートリッジを回収拠点１０４に運ぶ。

回収拠点１０４では、回収された使用済みカートリッジのメモリから必要なデータを読み出し、読み出したデータをサービスセンタ１０１が管理するデータベースに蓄積する。

こういったカートリッジの配送とは非同期に、ユーザサイト１０２からサービスセンタ１０１に対して、カートリッジのメモリ８２０ａから読み出した印刷枚数カウントを基にしたプリント枚数データ(8)が送信される。

サービスセンタ１０１は、受信したプリント枚数データに応じた料金を計算し、料金請求(9)をユーザサイト１０２に送信する。ユーザは請求された金額を別途取り決めた支払方法によってサービスセンタ宛に支払われる。また、このときの支払先は、サービスセンター以外の別途取り決めた支払先であっても良い。

このようにサービスセンタ１０１は、ユーザサイト１０２からのイベントの通知（トナーロウ通知）をきっかけとする、ユーザサイトから必要なデータの収集、カートリッジの配送及び回収の手配や課金情報の生成、手配した日程や課金情報のユーザサイト１０２への通知を、すべて遠隔通信網２０５を介して実現している。

なお、配送業者１０３とユーザサイト１０２との関係には人や物の移動が伴うが、配送業者１０３とサービスセンタ１０２との関係は、データの交換だけである。したがって、配送業者１０３が電話回線などのネットワークに接続されたＰＣを保有している場合には、サービスセンタと配送業者との間の情報の交換を、ＰＣによりプログラムを実行することで自動化することも可能である。

その場合、ＰＣ２０３がトナーロウ信号(1)を受信したならば、配送業者１０３宛に、カートリッジの回収の依頼(2)を電子的なメッセージとして送信する機能を実現するプログラムステップをサービスモジュールに組み込んでおく。また、配送業者から回答(3)を電子的なメッセージとしてＰＣ２０３が受信した場合には、通知(4)をユーザのＰＣ２０８宛に送信する機能を実現するプログラムステップもサービスモジュールに組み込んでおく。

このように構成することで、ユーザサイト１０２とサービスセンタ１０１との間のみならず、配送業者１０３も含めて、情報の交換をコンピュータ化する事ができる。

次に図１０以下で図１の手順の詳細を説明する。

＜カートリッジの交換日程の通知及び調整のシーケンス＞
図１０及び図１１は、カートリッジの交換のための日程をサービスセンタ１０１とユーザサイト１０２との間で調整するための手順を示している。図１０においては、ユーザサイトと記載されている部分は図１のユーザサイト１０２により遂行される。さらにユーザサイト１０２の処理においては、デバイスと記載されているステップはトナーカートリッジが装着されるプリンタや複写機といった各デバイスのデバイスモジュール２３０，２４０により実行される。デバイスモジュールは、各デバイスを制御するためのプロセッサにより実行されるプログラムモジュールとして実現される。またホストと記載されているステップはデバイスが接続されたＰＣ等のホストコンピュータにより実行される。また、サービスセンタと記載されている部分はサービスセンタ１０１のＰＣ２０３により実行されるサービスモジュール２１０で遂行される処理である。

図１０はユーザサイト１０２からのトナーロウ通知(1)の送信、及び、サービスセンタ１０１によるその受信までの手順を示している。まず、ステップ１００１でユーザの保有するデバイス、例えば図２のプリンタ１００ａ，１００ｂあるいはファクシミリ２０６においてトナーロウが検知され、その情報がデバイスモジュール２３０，２４０によってトナーロウ信号として出力される。ここで、デバイスがファクシミリ２０６やプリンタ１００ｂであれば、そのトナーロウ信号は、図１のトナーロウ信号(1)としてサービスセンタ１０１に送信される。このトナーロウ信号には、トナーロウであることを示す情報とともに、カートリッジから読み出したカートリッジＩＤ／シリアル番号が添付される。さらにトナーロウ信号には、必要に応じてトナー残量や印刷枚数といった情報を添付しても良い。これらの情報は、カートリッジが図９のような情報を記憶するメモリ８１０ａ，４２０３ａを有する場合にはそのメモリから取得され、遠隔通信網２０５を介してサービスセンタに送信される。メモリを有していない場合には、前述したように、カートリッジが使用開始されてからからの累積印刷枚数や印字率により推定されたトナーの残量が、トナーロウ通知(1)添付される情報として利用される。この情報はデバイス機器本体に設けられた不揮発性メモリに記憶されたものであり、この不揮発性メモリには本体のＩＤ／シリアル番号も記憶されている。例えば、ステップ１００１においては、この本体のＩＤ／シリアル番号情報と供に累積印字枚数やトナーの残量情報が送信される。

なお、デバイスがプリンタ１００ｂやファクシミリ２０６のように直接コンピュータネットワークに接続されていれば、トナーロウ通知(1)は図１０の矢印１００１ａとして示したように直接サービスセンタのＰＣ２０３に送信される。

一方、デバイスがプリンタ１００ａのようにホストにローカル接続されたプリンタである場合、またはホストを介してサービスセンタと通信が可能な場合には、ホストに対してトナーロウ信号が発行される。この場合には、ホストはステップ１００２でトナーロウ信号を受信する。その後は、そのホストの遠隔通信網２０５（遠隔相互通信手段）への接続形態に応じ、そのホストが遠隔通信網２０５にアクセス可能であれば、ステップ１００４でホストからサービスセンタ１０１にトナーロウ信号が通知される。

ホストが遠隔通信網２０５にアクセス不可能か、あるいはアクセスが禁止されているのであれば、ステップ１００３において、管理者が人手で、たとえば図２のパーソナルコンピュータ２０８からトナーロウを示すデータを入力し、トナーロウ信号としてサービスセンタ１０１に送信させる。

サービスセンタ１０１は、いずれかの方法で送信されたトナーロウ信号をステップ１００５で受信する。その後図１１のステップに進む。

図１１の処理はサービスセンタ１０１のＰＣ２０３上のサービスモジュール２１０及び分析モジュール２２０において行われる。図１１においてサービスセンタ１０１からユーザサイト１０２へデータを送信する場合には、送信宛先は窓口端末２０８になり、そこにおけるユーザインターフェース画面の表示等の処理はユーザモジュール２５０によって遂行される。

図１１において、まず、ステップ１１０１においてサービスセンタ１０１における分析システムへのデータ入力方式が自動であるかマニュアルであるかにより処理が別れる。ステップ１１０１はサービスセンタにおいて必ずしも行われる必要はない。これは、サービスセンタの構成に応じた処理手順を表現するための擬似的なステップであり、サービスセンタにおける実際の処理はその構成に応じてステップ１１０２あるいはステップ１１０３から始まる。

マニュアル入力の場合には、ステップ１１０２で、トナーロウ信号の受信を操作担当者に通知するための画面表示を行い、担当者により、配送日程を管理するための分析システムへの情報の入力を行わせる。

一方、自動入力の場合には、受信したトナーロウ信号及びカートリッジから読み出したデータはそのまま分析システム２２０に入力される（ステップ１１０３）。ここで、入力されたトナーロウ情報にトナー残量情報や印刷枚数情報が添付されている場合には、これらの情報もカートリッジＩＤ／シリアル番号とともにサービスセンターのＰＣ２０３で受信され、分析システム２２０に入力される。

分析システム２２０にデータが入力されると、分析システムによってトナー切れの日付けが予測され、それに基づいて配送日の候補が決定される（ステップ１１０４）。この予測手順については後述する。この後のステップは人手によって行われても良いが、ここではすべて自動化されているものとする。

配送日の候補が決定されると、その決定された日をＰＣ２０３から配送業者１０３へ通知する（ステップ１１０５）。

ステップ１１０６及びステップ１１０７では、配送業者１０３においてスケジュールの調整を行ってそれをサービスセンタに送信する。すなわち、在庫や適当な配送車あるいは配送車の候補や配送時間等のスケジュールが配送業者により決定され、スケジュールをサービスセンタのＰＣ２０３に対して通知する。配送不可能な日が含まれていれば、その日も含めて通知する。

スケジュールを受信したサービスセンターのＰＣ２０３は、ユーザサイトの窓口端末２０８に対して予想交換時期を送信する（ステップ１１０８）このとき、送信データには、配送のスケジュール情報も含まれる。

これを受けたユーザサイト１０２では、ＰＣ２０８のユーザモジュール２５０により図１３のユーザインターフェース（ＵＩ）画面が表示される。操作者がこの画面に対してカートリッジ交換を行う旨の入力（ＯＫ）をすると、ステップ１１０８で受信されている配送日や時間に基づいて図１４の画面を表示する。この画面では、操作者が予想交換期間のなかから希望する日時を入力する。

入力された指定日はサービスセンタ１０１のＰＣ２０３に送信される。サービスセンタ１０１では、この指定日に基づいて決定された配送・回収の予定日時をユーザ（ユーザサイトのＰＣ２０８、或いはプリンタ等のデバイス）に通知し（ステップ１１０９）、最終的な確認を求める。このときにユーザ側で表示される画面が図１５である。

以上の手順によって確定した日時が配送業者にも通知され、指定された日時に配送業者がカートリッジの配送及び回収を実施する。

図１１においては、ステップ１１０３，１１０４，１１０５，１１０８，１１０９がサービスセンタのＰＣ１０３により実行され、ステップ１１０６，１１０７は配送業者のＰＣ等により実行される。すなわち、ＰＣ２０３においては、ステップ１１０５の後は配送業者からの応答待ちとなり、応答を受信するとそれを基にしてステップ１１０８から処理が再開される。また、ステップ１１０８では、ユーザのＰＣ２０３よりサービスのＰＣに対して指定日等の情報が送信される。

＜トナー切れの予測＞
図１９はステップ１１０４において分析システム２２０により実行される、配送・回収日の日程を決める基準となる、トナー切れの時期を予想する手順を示すブロック図である。トナー切れ時期の予想は、デバイスから受信したトナーロウ信号とデータベース１９９９とに基づいて行われる。

データベースサーバ２０１にはデータベース１９９９が構築されている。このデータベース１９９９には、ユーザ毎／デバイス毎／消耗品毎に、印刷枚数推移１９１５、カートリッジあたりの平均印字率１９１６、カートリッジ配送日１９１７、トナーロウ信号発生日１９１８、累積使用日数１９０６、累積印刷枚数１９０７が蓄積されている。また、カートリッジのメモリに記録されたデータを、回収拠点などに設置されたＰＣからサービスセンタに送信することで、カートリッジ毎のトナー切れ信号発生日１９０８、カートリッジ毎のトナーロウ信号発生日１９０９、カートリッジ毎の使用期間１９１０、カートリッジごとの使用枚数１９１１、カートリッジ毎の印刷枚数データ１９１２も蓄積される。

カートリッジあたりの平均印字率１９１６は、カートリッジの使用個数１９０３と回収日１９０４とカートリッジあたりの印刷枚数データ１９０５から算出されたカートリッジごとの平均印字率１９１３を蓄積している。また、印刷枚数推移１９１５は、印刷枚数データ１９０５を月別に集積し、月ごとの推移として蓄積されている。

さらに、回収したカートリッジからは、平均印字率１９１３よりも正確なカートリッジの平均印字率１９１９（これはカートリッジの種類毎などに求められる）及びトナーロウから実際にトナー切れまでの平均期間１９２０が求められ、これもデータベース１９９９に蓄積される。

予測に当たっては、まず、カートリッジの平均印字率１９１９から残り印刷可能枚数１９２１を予測し、そこからトナー切れまでの期間１９２２を予測する。このとき、印刷枚数推移１９１５などのデータを用いて予測値を補正することもできる。得られたトナー切れまでの期間１９２２と、トナーロウ信号の発生日１９０１とから適当な配送日１９２３を求めて予想交換時期を出力する。ユーザサイトに対しては、在庫や配送スケジュールなどを参照して配送が可能となる日時からトナー切れの予測日までを、交換日の候補として出力する。

図２０は、トナー切れ時期の予想をより正確に行うための補正処理の内容を示す図である。例えば、８月３１日にトナーロウ信号をサービスセンタのＰＣ２０３で受信したとする。トナーロウ信号には、カートリッジＩＤ／シリアル番号が含まれているため、同じタイプのカートリッジの平均印字率から残り印刷可能枚数が１０００枚であるとわかる。直前の印刷枚数が月あたり１０００枚であれば、残りのトナーは１ヶ月後に切れ、それまでにカートリッジを交換する必要があることがわかる。

ここで補正値が参照される。月別の印刷枚数推移１９１５から、９月から１２月の時期は月あたりの印字枚数が２０００枚であり、また、今年は去年の２倍に印刷量が増加していることがわかると、これらの値から、９月になれば月あたり４０００枚の印刷が行われる可能性があることもわかる。

残りトナーで印刷可能な枚数である１０００枚をこの推定印刷量で期間に換算すれば、残トナーは４分の１月、ほぼ１週間しか保たない可能性があることがわかる。そこで、予想交換時期としては８月３１日から１週間後の９月７日がえられる。ユーザに対しては、カートリッジが配送可能となる日から９月７日までの期間を配送及び回収日の候補として提示する（送信する）。

以上のようにして、データベースに蓄積されたデータに基づいて、まず平均的な値から予想交換時期を求め、さらに、これもデータベースから獲得できる周期的な変動や最近の傾向などから、求められた予想交換時期を補正している。こうしてより正確なトナー切れの期日を予測し、それまでにカートリッジを交換可能なようにユーザにその予想日を示すことができる。なお、残トナーで印刷可能な期間が非常に長いと予想される場合には、トナーをできる限り使わせるために、カートリッジの配送及び回収日の期間を、予想されるトナー切れの日を含む所定日数、例えば１週間に限定するなどしても良い。この場合、例えば残りのトナーで印刷可能な期間があと１月と予測されれば、そのうちの最後の１週間を配送及び回収日の候補としてユーザに提示する。

また、トナーロウ信号とともにカートリッジＩＤ／シリアル番号とトナー残量をサービスセンタ１０１のＰＣ２０３が受信した場合には、カートリッジＩＤ／シリアル番号及びトナー残量からトナー切れとなる日をより正確に予測できる。例えば、カートリッジＩＤ／シリアル番号がわかれば、そのカートリッジが使用されているデバイスの機種を限定できる。そのため、カートリッジから得られたカートリッジＩＤ／シリアル番号とトナー残量の情報とにより、そのカートリッジを使用するデバイスに限定して平均的な印字率やプリント枚数を求められる。これを、データベース１９９９で管理されている周期的変動や傾向といった情報で補正することで、一層正確なトナー切れの予測が可能となる。

さらに、サービスセンタのＰＣ２０３でユーザ毎に配送したカートリッジを管理していれば、どこのユーザでどのデバイスで使用されているカートリッジであるか、ということまで判別できる。データベース１９９９において、ユーザごと、さらには各ユーザにおける機種毎にトナー消費量や印字率、プリント枚数等を管理していれば、ユーザに設置されたデバイス単位で平均印字率や周期的変動、最近の傾向といった情報を蓄積できる。このユーザ毎、デバイス毎に蓄積した情報を、上述したデータベースと同様に用いることで、トナー切れを予測することができる。

このように、カートリッジの配送及び回収日程を、トナー切れの時期を高精度に予測して決定できるので、カートリッジの交換時期をトナー切れが生じる時期に合わせることで、カートリッジのトナーをできるだけ使い切らせることができる。これは、資源の節約に貢献する。さらにプリント枚数課金方式ではプリント枚数に応じて課金しているので、未使用のまま廃棄されるトナーを減らせればその分原価を下げることができ、料金の引き下げや利幅の増大に寄与する。

＜課金のシーケンス＞
図１２は、ユーザサイトにおいて印刷された枚数に応じて課金を行うための手順を示す図である。ここでは課金シーケンスはユーザサイトから定期的に発信されるプリント枚数データをきっかけとして開始されるものとする。しかしながら、サービスセンタからの要求に応じて開始されても良いし、トナーロウ信号をきっかけとして開始されても良い。また、サービスセンタによる請求書の発行等の課金業務は、ユーザサイトからサービスセンタに対するプリント枚数データの送信とは非同期に行うようにしても良い。

図１２においては、ユーザサイトと記載されている部分はユーザサイト１０２において遂行され、サービスセンタと記載されている部分はサービスセンタのＰＣ２０８によって遂行される処理である。また、ユーザサイト１０２の処理においては、デバイスと記載されているステップはトナーカートリッジが装着されるデバイスにより実行され、ホストと記載されているステップはデバイスがケーブル又はネットワークを介して接続されたＰＣ等のホストコンピュータにより実行される。また、一旦サービスセンタ１０１のＰＣ２０３にプリント枚数データが送信された後は、サービスセンタとユーザサイトとの通信は、それぞれの窓口端末同士の通信となる。

まず、図１２において、ユーザサイト１０２に含まれる、プリント枚数課金方式の契約がされているデバイスから、前回の課金シーケンス以降に発生したプリント枚数データがデバイスモジュールにより読み取られてサービスセンタ１０１に送信される（ステップ１２０１，１２０２，１２０２ａ）。カートリッジの交換と課金とは非同期に行われるために、送信されるプリント枚数データは後述するような手順で求められる。

なおデバイスがホスト経由で遠隔通信網２０５に接続されている場合には、ホストコンピュータが一旦プリント枚数データを受信し（ステップ１２０３）、人手を介する場合には管理者により入力され、自動の場合には自動的にサービスセンターへと受信したデータを送信する（ステップ１２０４，１２０５）。なお、本発明においてホスト経由で遠隔通信網２０５に接続される形態としては、デバイスがホストにケーブルを介して接続される場合、或いは、デバイスがホストにＬＡＮ等のネットワークを介して接続される場合が想定される。またホストはサーバ的機能を有するものでもあり、該サーバ機能を有するホストに更に別のホスト（サーバ機能を有しないホスト）が接続された形態も想定される。

サービスセンタ１０１のＰＣ２０３はプリント枚数データを受信し（ステップ１２０６）、そのデータがＰＣ２０３のサービスモジュール２１０に渡される。そして、サービスモジュール２１０は、ユーザごとに、各デバイスのプリント枚数を集計し（ステップ１２０７）、その値をもとにして請求金額を計算し（ステップ１２０８）、その金額を、契約台数や印刷枚数といった明細情報とともにＰＣ２０８のユーザモジュール２５０に送信する（ステップ１２０９）。

この時に表示される画面が図１６の画面である。請求金額とともに明細が画面に表示される。ユーザはこの請求に応じる場合にはＹＥＳボタンを押し、疑義がある場合にはＮｏボタンを押して別途問合せ・交渉を行うことになる。最後に、予め定めておいた方法で決済が行われる（ステップ１２１０）。このステップ１２１０はコンピュータネットワークを通じた決済であれば一連の処理の一部として実行可能であるが、あらかじめ定められた方法が電子的な決済方法でなく、例えば銀行口座への振り込みなどであれば、ステップ１２１０を行うことなくサービスモジュール２１０における処理は終了する。

図１７（ｂ）は、デバイスモジュール２３０，２４０により遂行される、ユーザのデバイスからプリント枚数を発信するための図１２のステップ１２０１，１２０２の詳細の一例を示す図である。図１７（ａ）はデバイスがそのＲＡＭに有するプリント枚数の格納領域である。格納領域としては、現在までに使用されたトナーカートリッジについて、まだ料金が精算されていないプリント枚数を表す未課金プリント枚数１７１１と、現在装着されているトナーカートリッジについて、既に料金を請求し終えた既課金プリント枚数１７１２と、カートリッジの交換直前に、使用済みのカートリッジから読み出されたプリント枚数１７１３とが含まれる。

デバイスからプリント枚数データを送信する際には、まずカートリッジのメモリからプリント枚数を読み出し、読み出したプリント枚数から既課金プリント枚数１７１２の値を減算し、その値を未課金プリント枚数１７１１として格納する（ステップ１７０１）。その未課金プリント枚数をサービスセンタ、あるいはホストに送信する（ステップ１７０２）。最後に、未課金プリント枚数が送信されたことが確認できたなら、未課金プリント枚数１７１１に０をセットし、既課金プリント枚数にカートリッジから読み出したプリント枚数をセットする。なお、図１７のフローチャートは、デバイスに設けられた時計機能により、１ヶ月毎など所定の期間毎に実行される。また、図１２には示されていないが、ＰＣ２０８に蓄積されたデバイスの未課金の出力枚数情報を送信するような命令を、所定期間毎にＰＣ２０３のほうからＰＣ２０８に送信し、出力枚数等の課金情報をＰＣ２０３にて取得するようなことが本発明では想定される。更に、ＰＣ２０８に設けられた時計機能により所定期間毎に自装置に蓄積されたデバイスの出力枚数等の未課金情報をＰ２０３に対して送信することも本発明では想定される。

一方、カートリッジが交換された際には、プリンタ１００やファクシミリ２０６等のデバイスは図１８の手順を遂行する。図１８の手順は、デバイス本体に設けられたカートリッジ収納部のカバーが開いてから再び閉じられた場合、あるいは電源が投入された場合に、カートリッジが交換された可能性があるものとして遂行される。カートリッジ収納部のカバーが開いているか否かはセンサによって検知される。デバイスは、カートリッジのカバーが開けられた直後か、あるいは電源オフ後の処理シーケンスにおいて、そのときに装着されているカートリッジのメモリからプリント枚数データを読み出してカートリッジのプリント枚数１７１３として保存しておく。

その後、カートリッジのカバーが閉じられたかあるいは電源が投入されると、現在装着されているカートリッジからカートリッジＩＤ／シリアル番号を読み取り、カートリッジ交換後に読み取って保存しておいたカートリッジＩＤ／シリアル番号と比較する（ステップ１８０１）。その結果をステップ１８０２で判定し、同一であればカートリッジは交換されていないので処理を終了する。

一方、同一でなければカートリッジは交換されているので、読み取ったカートリッジＩＤ／シリアル番号を現在のカートリッジＩＤ／シリアル番号として保存する（ステップ１８０３）。

そして保存しておいたプリント枚数をカートリッジのプリント枚数１７１３から読み出し（ステップ１８０４）、そこで読み出されたプリント枚数から既課金プリント枚数１７１２の値を減算した値を未課金プリント枚数に加算する（ステップ１８０５）。

そして、既課金プリント枚数１７１２に０をセットする（ステップ１８０６）。

このようにすることで、カートリッジに記録されたプリント枚数のうち、既に料金の請求が終わっている分とまだ請求されていない分とを区別することができる。このため、課金処理においては、未課金のプリント枚数を基にした正確な料金をユーザに請求できる。

なお、ユーザに配送される新たなカートリッジについては実質的に料金を徴収することなく供給される。

以上のようにして、トナーカートリッジによりトナーを供給するプリンタなどの機器に対しても、プリント枚数に応じて課金するプリント枚数課金方式を適用することができる。プリント枚数課金方式を適用することで、カートリッジの交換や回収といった作業とは非同期に精算でき、かつ、印刷量に応じた料金体系を実現できる。これにより、メーカあるいは販売者等のサービス側にとっては、継続的かつ安定的な収益が期待できるために、サービスの拡充などが図れる。また、プリント枚数課金方式のためのデータ収集をネットワークを介して行うために、人手を介する部分を減らすことができ、高精度のデータを迅速に入手できる。

また、カートリッジのトナー切れ時期をより正確に予想する管理システムと連動させることにより、未使用トナーの廃棄による原価の高騰を防止することができ、カートリッジについてのプリント枚数課金方式を商業ベースに載せることが可能となる。

一方ユーザ側にすれば、印刷のための経費の変動が少なくなり、また、プリント枚数から単純に料金の確認や推測ができるために、支払金額の確認や印刷経費の予算化が容易になり、これら作業の生産性向上に寄与する。

なお、デバイスがプリント枚数を送信するときに、カートリッジＩＤ／シリアル番号も同時に送信しても良い。この場合、サービスセンタはこれを受信して、図２０のデータベースにデータを蓄積する。

＜デバイスの保守＞
図２１は、ユーザの保有するデバイスに不具合が生じた場合の手順を示す。本実施形態ではユーザサイトとサービスセンタとがネットワークで接続されているために、不具合発生の通報及び修理要請もネットワークを介して行える。

ユーザのデバイスが故障を検知するなどして不具合情報を発生すると、そのデバイスが遠隔通信網２０５に接続されている場合にはそれを介してサービスセンタに直接、あるいは、ホストを介して遠隔通信網２０５に接続されている場合にはホストに不具合情報を送信する（ステップ２１０１）。

デバイスが不具合のセンサを保たない場合や、発生した不具合を検出できなかった場合、あるいは、デバイスが遠隔通信網に接続されていない場合には、操作者がマニュアルで不具合情報を、遠隔通信網２０５に直接、あるいは、遠隔通信網２０５に接続されたホストに入力する（ステップ２１０２）。

ホストに対して不具合情報が送信された場合には、ホストが不具合情報を受信して（ステップ２１０３）、操作者の手を介して（ステップ２１０４）あるいは自動的に（ステップ２１０５）、不具合情報がサービスセンタに送信される。

サービスセンタにおいては、ＰＣ２０３が不具合情報を受信すると（ステップ２１０６）、自動的にあるいはマニュアルで、機器メーカのサービス部門や修理業者に対して必要な情報が通知され、サービス部門や業者との間で日程が調整される（ステップ２１０７）。調整された日程をユーザサイトの窓口端末２０８に送信し、さらに日程を調整して確定されると（ステップ２１０８）、決定された日程で修理が行われる。日程の調整のために、ステップ２１０７においてはサービス部門等と、ステップ２１０８においてはユーザサイトとの間で、データの交換が行われても良い。

図２２（Ａ）は、ステップ２１０８においてサービスセンタからユーザサイトに日程が通知されたときに表示される画面である。ユーザはこの画面で日程を選択し、サービスセンタに返送する。

図２２（Ｂ）は、不具合の内容を予め確認するためのサービスセンタからユーザサイトに送信される画面情報の表示様子である。ユーザは表示された候補の中から該当する故障内容を選択してサービスセンタに送信する。図２２（Ｂ）は、日程の調整時に表示しても良いし、日程調整前に表示しても良い。日程調整前にユーザに不具合内容を通知させておけば、故障の程度を日程に反映させることもできる。

このように、ネットワークを介して不具合の通知や修理日程の調整を行うこともできる。こうして調整された日程で、プリンタの点検や修理をするサービスマンがサービスセンタからユーザへと派遣されるが、この際には、実質的に、プリント枚数に関するデータに応じた料金以外の料金は徴収されない。

以上のように、少なくともトナー及び現像器を収納するカートリッジを着脱可能なプリンタの使用に対する本実施形態に係るプリント枚数課金システム課金システムでは、カートリッジが装着されたプリンタから出力される、当該プリンタにおいてプリントされたプリント枚数に関するデータ及び前記カートリッジ内のトナー残量に関するデータを、遠隔通信手段を介してサービスセンターに供給するとともに、サービスセンターは、遠隔通信手段を介して供給されたプリント枚数に関するデータに応じた料金を、プリンタのユーザーから徴収するとともに、トナー残量に関するデータに基づいて、プリンタ内のカートリッジと交換して装着されるべき新たなカートリッジを、実質的に料金を徴収することなく、ユーザーに供給している。

さらに、プリント枚数に関するデータに応じた料金は、前記プリンタに対する保守サービス料金に含まれ、さらに、前記カートリッジが装着されたプリンタから出力される、当該プリンタの障害に関するデータを、遠隔通信手段を介して前記サービスセンターに供給するとともに、サービスセンターは、遠隔通信手段を介して供給されたプリンタの障害に関するデータに基づいて、実質的に、プリント枚数に関するデータに応じた料金以外の料金を徴収することなく、プリンタを点検、修理するサービスマンを派遣している。

さらに、サービスセンターの機能は、例えばカートリッジの配送業者といった配送機能を含み、新たなカートリッジの供給の際に、使用済みのカートリッジを回収している。

＜第１の実施の形態における効果＞
以上説明した本実施形態のカートリッジ管理システムによれば次のような効果が得られる。

（１）トナーロウ信号が発せられた時点でトナー切れ時期を予測し、その時期にカートリッジの交換を行うために、カートリッジ内のトナーを使い切らせることができ、資源の節約や原価の低減に寄与する。

（２）カートリッジのトナー切れの直前にカートリッジが交換できるために、トナー切れによるプリンタ等のデバイスのダウンタイムがなくなる。

（３）カートリッジのトナー切れの直前にカートリッジがユーザに配送されるために、交換用のカートリッジの買いだめや保管、使用済みのカートリッジの保管が不要になる。

（４）カートリッジの配送と回収とを組みあわせているので、ユーザは使用済みカートリッジをメーカや販売店に持ち込む必要が無くなり、しかも新しいカートリッジの配送後直ちに使用済みのそれと交換することで、使用済みカートリッジを確実に回収することができる。

（５）ユーザサイトに保有されている複数のデバイスに対してまとめて課金することができる。このため、ユーザ単位で課金や保守を行うことができる。

（６）カートリッジ自体にメモリを備え、そこにプリント枚数などの印刷記録のデータを記録しているために、そのデータをデータベース化して蓄積しておくことができ、それをもちいて正確なトナー切れの予測が可能となる。

（７）カートリッジ自体に、それを固有に識別するためのカートリッジのタイプを示すＩＤやシリアル番号といった識別データをもつことで、カートリッジの交換を確認することができる。また、これら識別データを用いて、プリント枚数課金方式契約によって配送されたカートリッジであるか確認でき、カートリッジの不正使用などを防止できる。また、再使用・再資源化のサイクルを管理することもできる。

（８） カートリッジ自体にデータをもたせているために、デバイスから取り外された状態であっても、そのカートリッジのもつデータから印刷枚数等を把握できる。

（９） サービスセンターでデータを集中して管理するため、より正確な印字比率や交換時期を計算することができる。

［第２の実施の形態］
第２の実施形態として、メモリを有していないカートリッジを用いたシステムを説明する。本システムは第１の実施形態を基にして、相違点に限って説明する。したがって、その全体的な構成は図１，図２に示したとおりであり、カートリッジにメモリがないことを除けば機器の構成も第１の実施形態と同様である。

＜課金のシーケンス＞
図２３は本実施形態のプリント枚数課金方式で課金されるデバイスのメモリに用意される、データ領域の一例である。基本的にはカートリッジのメモリに保持されるデータと同様であるが、カートリッジに固有のデータは除外される。総印刷枚数／ジャム枚数２３００は、プリントされた枚数及びプリントをし損じた総数を示す。Ａ３の印刷枚数／ジャム枚数２３０１，Ａ４の印刷枚数／ジャム枚数２３０２は、サイズ毎の枚数を示す。これらの値は、デバイスが該当するサイズの用紙１ページを印刷する毎に１ずつ加算される。

サービスセンタ宛先２３０３は、プリント枚数やトナーロウ信号を送信する宛先である。このフィールドは、デバイスが直に遠隔通信網２０５に接続されている場合に用いられる。カートリッジタイプＩＤは、デバイスからサービスセンタにカートリッジの種類を通知するために用いる。これらフィールド２３０３，２３０４の内容は滅多に変更されることはないと考えられるので、ＲＯＭに記録してしまっても良い。またカートリッジＩＤ（２３０４）の代わりに、デバイス本体のＩＤ（本体メモリに記憶）を適用することも本発明では考えられる。

図２４は、第１の実施形態の図１２に変えて本実施形態で実行される課金の手順を示す図である。

デバイスモジュールは定期的あるいはサービスサイトからの要請に応じて、図２３のプリント枚数データ２３００〜２３０２を読み出し、接続先に応じて、遠隔通信網２０５あるいはデバイスが接続されたホストに送信する（ステップ２４０１）。送信が確認されたなら、読み出されたプリント枚数データ２３００〜２３０２には０をセットしておく。

ステップ２４０３〜２４１０は、図１２のステップ１２０３〜ステップ１２１０と同様であるので、説明は省略する。

このように、カートリッジにメモリを備えていない場合にも、デバイス毎のプリント枚数に応じてサービスセンタは課金を行うことができる。また、このシーケンスはメモリを備えたカートリッジを使用するデバイスに対しても有効であるので、第１の実施形態の図１２の手順に変えて本実施形態の図２４の手順を利用することもできる。また、図１２と図２４とで相違するのはデバイス側の処理だけであるために、メモリを有するカートリッジを使用するデバイスに対しては図１２の手順を適用し、メモリを有しないカートリッジを使用するデバイスに対しては図２４の手順を適用することで、それらのデバイスが混在するユーザサイトにも対応することができる。

＜トナー切れの予測＞
本実施形態においては、デバイスのトナーロウ信号発信をきっかけとして開始される、カートリッジの交換日程の通知及び調整のシーケンスは、第１の実施形態における図１０及び図１１とほぼ同様である。しかしながら、カートリッジごとのデータをもてないために、トナーロウ信号とともにカートリッジのシリアル番号を送信することはない。また、データベースに反映されるデータが第１の実施形態とは異なっており、予測の仕方も異なる。

図２５は、図１１のステップ１１０４において分析システム２１０により実行される、配送及び回収日の日程を決める基準となる、トナー切れの時期を予想する手順を示すブロック図である。

分析システムにはデータベース２５９９が構築されている。このデータベース２５９９には、ユーザ毎に、印刷枚数推移１９１５、カートリッジあたりの平均印字率１９１６、カートリッジ配送日１９１７、トナーロウ信号発生日１９１８、累積使用日数１９１９０６、累積印刷枚数１９０７が蓄積されている。

カートリッジあたりの平均印字率は１９１６は、カートリッジの使用個数１９０３と回収日１９０４とカートリッジあたりの印刷枚数データ１９０５から算出された平均印字率１９１３を蓄積している。また、印刷枚数推移１９１５は、印刷枚数データ１９０５を月別に集積し、月ごとの推移として蓄積されている。

予測に当たっては、まず、平均印字率１９１３から残り印刷可能枚数２５０１を予測し、そこからトナー切れまでの期間２５０２を予測する。このとき、過去の平均印字率１９１６や印刷枚数推移１９１５といったデータを用いて予測値を補正することもできる。得られたトナー切れまでの期間２５０２と、トナーロウ信号の発生日１９０１とから適当な配送日２５０３を求めて予想交換時期を出力する。ユーザサイトに対しては、在庫や配送スケジュールなどを参照して配送が可能となる日時からトナー切れの予測日までを、交換日の候補として出力する。

図２６は、トナー切れ時期の予想をより正確に行うための補正の内容を示す図である。例えば、８月３１日にトナーロウ信号をサービスセンタで受信したとする。直前のカートリッジの平均印字率から求められる印刷可能枚数から、残りのトナーは１ヶ月後に切れ、それまでにカートリッジを交換する必要があることがわかる。

ここで補正値が参照される。過去のカートリッジあたりの平均印字率１９１６及び月別の印刷枚数推移１９１５から、９月から１１月の時期は印字率が１０％にまであがることがわかったとすると、９月から１１月平均印字率は直前の平均印字率のほぼ３倍になる。すなわち、トナーロウ信号からトナー切れまで１０日しかないことがわかる。そこで、トナーロウ信号発生日である８月３１日から１０日後の９月１０日を補充用カートリッジの配送日の期限とする。そしてユーザに対しては、カートリッジが配送可能となる日から９月１０日までの期間を配送及び回収日の候補として提示する。

以上のようにして、正確なトナー切れの期日を予測し、それまでにカートリッジを交換可能なようにユーザにその予想日を示すことができる。なお、残トナーで印刷可能な期間が非常に長いと予想される場合には、トナーをできる限り使わせるために、カートリッジの配送及び回収日の期間を、予想されるトナー切れの日を含む所定日数、例えば１週間に限定するなどしても良い。この場合、例えば印刷可能な期間が１月あれば、そのうちの最後の１週間を配送及び回収日の候補としてユーザに提示する。

このように、カートリッジの配送・回収日程を、トナー切れの時期を高精度で予測して決定できるので、カートリッジのトナーをできるだけ使い切らせることができる。プリント枚数課金方式ではプリント枚数に応じて課金しているので、未使用のまま廃棄されるトナーを減らせればその分原価を下げることができ、料金の引き下げや利幅の増大に寄与する。

なお、図１９の予測方式及び図２５の予測方式が混在した分析システムを構築することもできる。その場合、メモリを備えていないカートリッジについては図２５及び図２６の方法でトナー切れを予測し、メモリを備えているカートリッジについては図１９及び図２０の方法でトナー切れを予測する。

＜第２の実施の形態における効果＞
以上説明した本実施形態のカートリッジ管理システムによれば次のような効果が得られる。

（１）トナーロウ信号が発せられた時点でトナー切れ時期を予測し、その時期にカートリッジの交換を行うために、カートリッジ内のトナーを使い切らせることができ、資源の節約や原価の低減に寄与する。

（２）カートリッジのトナー切れの直前にカートリッジが交換できるために、トナー切れによるプリンタ等のデバイスのダウンタイムがなくなる。

（３）カートリッジのトナー切れの直前にカートリッジがユーザに配送されるために、交換用のカートリッジの買いだめや保管、使用済みのカートリッジの保管が不要になる。

（４）カートリッジの配送と回収とを組み合わせているので、ユーザは使用済みカートリッジをメーカや販売店に持ち込む必要が無くなり、しかも新しいカートリッジの配送後直ちに使用済みのそれと交換することで、使用済みカートリッジをより確実に回収することができる。

（５）ユーザサイトに保有されている複数のデバイスに対してまとめて課金することができる。このため、ユーザ単位で課金や保守を行うことができる。

（６）第１の実施形態に比して、メモリを備えないカートリッジを使用する従来通りのデバイスを使用して、プリント枚数課金方式の課金システム及び配送及び回収システムを構築できる。

（７）サービスセンターでデータを集中して管理するため、より正確な印字比率や交換時期を計算することが出来る。

［第３の実施の形態］
第３の実施の形態として、第１の実施形態のシステムからネットワーク上で配送業務を委託する配送業者を除いたシステムを説明する。本システムの構成や各デバイスの構成は、第１の実施形態の図２乃至図９と同様である。

図２７は第３の実施の形態の管理手順の概略を示している。図１と同じメッセージについては同じ番号を与えてある。

ユーザサイト１０２におけるプリンタ１００ａや１００ｂ、あるいはファクシミリ２０６において、トナーが所定量以下にまで減少する状態、すなわちトナーロウ（Toner Low）が発生すると、カートリッジに内蔵されたセンサによってそれが検知される。この状態はユーザサイト１０２のＰＣ２０８または直接デバイスからトナーロウ信号(1)としてサービスセンタ１０１に通報される。なお、ここでは単にサービスセンタと呼んでいるが、サービスセンタに含まれるＰＣ２０３などが通報先となる。

これを受けたサービスセンタ１０１は、ユーザサイト１０２にカートリッジの配送及び回収の通知(4)を送信する。ただし、後述するとおり、この通知は単純に送信されるのではなく、ユーザとの日程調整のシーケンスを含む。

サービスセンタ１０１は、カートリッジの配送及び回収の通知(4)で決定された日程に従って、ユーザサイト１０２に新しいカートリッジの配送(10)を行い、同時に、使用済みのカートリッジの回収(11)を行って、回収したカートリッジを回収拠点１０４に運ぶ。

回収拠点１０４では、回収された使用済みカートリッジのメモリから必要なデータを読み出し、読み出したデータをサービスセンタ１０１が管理するデータベースに蓄積する。読み出されたデータは、カートリッジデータ(12)としてサービスセンタ１０１に送信される。

これらカートリッジの配送とは非同期に、ユーザサイト１０２からサービスセンタ１０１に対して、カートリッジのメモリ８２０ａから読み出した印刷枚数カウントを基にしたプリント枚数データ(8)が送信される。

サービスセンタ１０１は、受信したプリント枚数データに応じた料金を計算し、料金請求(9)をユーザサイト１０２に送信する。ユーザは請求された金額を別途取り決めた支払方法によってサービスセンタ宛に支払われる。また、このときの支払い先はサービスセンタ以外の別途取り決めた支払先であっても良い。

このようにサービスセンタ１０１は、ユーザサイト１０２からのイベントの通知（トナーロウ通知）をきっかけとする、ユーザサイトから必要なデータの収集、カートリッジの配送及び回収の手配や課金情報の生成、手配した日程や課金情報のユーザサイト１０２への通知を、すべて遠隔通信網２０５を介して実現している。

＜カートリッジの交換日程の通知及び調整のシーケンス＞
図２７の構成において、ユーザサイト１０２からサービスセンタ１０１にトナーロウ信号が送信され、サービスセンタ１０１がそれを受信する手順は、第１実施形態の図１０に示したとおりである。しかしながら、トナーロウ信号を受信したサービスセンタにおける処理は図２８のようになる。

図２８において、まず、ステップ１１０１においてサービスセンタ１０１における分析システムへのデータ入力方式が自動であるかマニュアルであるかにより処理が別れる。ステップ１１０１はサービスセンタにおいて必ずしも行われる必要はない。これは、サービスセンタの構成に応じた処理手順を表現するための擬似的なステップであり、サービスセンタにおける実際の処理はその構成に応じてステップ１１０２あるいはステップ１１０３から始まる。なお、分析システムは、本実施形態ではデータベースサーバ２０１に構築されているデータベースを参照して後述する手順の分析プログラムを実行することで、ＰＣ２０３上で実現されるものとする。

マニュアル入力の場合には、ステップ１１０２で、トナーロウ信号の受信を操作担当者に通知するための画面表示を行い、担当者により、配送日程を管理するための分析システムへの情報の入力を行わせる。

一方、自動入力の場合には、受信したトナーロウ信号及びカートリッジから読み出したデータはそのまま分析システムに入力される（ステップ１１０３）。

分析システムにデータが入力されると、分析システムによってトナー切れの日付けが予測され、それに基づいて配送日の候補が決定される（ステップ１１０４）。この予想手順については後述する。この後のステップは人手によって行われても良いが、ここではすべて自動化されているものとする。

配送日の候補が決定されると、その日をユーザへと予想交換時期として通知する（ステップ１１０８）。

これを受けたユーザサイト１０２では、窓口端末であるＰＣ２０８により図１３のユーザインターフェース（ＵＩ）画面が表示される。操作者がこの画面に対してカートリッジ交換を行う旨の入力（ＯＫ）をすると、図１４の画面に切り替わる。この画面では、操作者が予想交換期間のなかから、希望する日時を入力する。

入力された指定日はサービスセンタ１０１に送信される。サービスセンタ１０１では、この指定日に基づいて決定された配送及び回収の予定日時をユーザに通知し、最終的な確認を求める（ステップ１１０９）。このときにユーザ側で表示される画面が図１５である。

以上の手順によって確定した日時に従って、サービスセンタ１０１から保守などを行うサービスマンやＩＴ要員、単に配送を行うだけの配送などがユーザサイトに派遣され、カートリッジの配送及び回収、必要があれば機器の保守を実施する。派遣される要員及び作業内容は、サービスセンタを運営する販売店やメーカとユーザとで結ばれた契約等に依存する。

また、プリント枚数に依存した課金方式（プリント枚数課金方式）による課金システムはカートリッジの配送及び回収とは非同期であるため、第１の実施形態あるいは第２の実施形態と全く同様に機能する。

以上のように、本実施形態では、ネットワーク上で配送業務を委託しないシステムを構築することができる。この場合の効果は第１の実施形態あるいは第２の実施形態の効果と同様である。

［第４の実施の形態］
第４の実施形態のシステムは、基本的な構成は第１の実施形態と同様であるが、ユーザサイトに在庫管理システムを含む点で第１の実施形態のシステムと相違する。図２９に示すように、在庫管理システム２６０は、ユーザサイト１０２におけるＰＣ４などで所定のプログラムを実行することで実現されている。この在庫管理システム２６０はトナーカートリッジの社内在庫も管理しており、カートリッジ管理システムと連動する。また、在庫管理システムが稼働するコンピュータは、直接あるいは間接にでも遠隔通信網２０５にアクセス可能な必要がある。

図３０は、第４の実施形態におけるユーザサイト１０２からのトナーロウ通知の送信、及び、サービスセンタ１０１によるその受信までの手順を示している。まず、ステップ２９０１でユーザの保有するデバイス、例えば図２のプリンタ１００ａ，１００ｂあるいはファクシミリ２０６において、トナーロウが検知され、その情報がデバイスモジュールによりトナーロウ信号として出力される。ここで、デバイスがファクシミリ２０６やプリンタ１００ｂであれば、そのトナーロウ信号は、社内在庫管理システムが稼働するＰＣ２０８に送信され、在庫管理システム２６０への入力信号となる。

デバイスがプリンタ１００ａのようにホストにローカル接続されたプリンタであれば、ホストに対してトナーロウ信号が発行される。この場合には、ホストはステップ２９０２でトナーロウ信号を受信する。その後、ホストから社内在庫管理システム２６０へとトナーロウ信号が送信される。

在庫管理システム２６０は、トナーロウ信号を受信すると、トナーロウ信号の発信元の情報から、あるいは、トナーロウ信号とともに送信される本体ＩＤ／シリアル番号またはカートリッジタイプＩＤ／シリアル番号情報から、デバイスの使用するカートリッジのタイプを判別し、その在庫があるかを判定する（ステップ２９０３）。在庫があればＰＣ２０８のディスプレイ等にその旨を表示し、利用者の注意を喚起する（ステップ２９０４）。

在庫が無いと判定された場合には、トナーロウ信号の発信元デバイスと遠隔通信網２０５との接続形態に応じて、サービスセンタ１０１宛に在庫管理システム２６０からトナーロウ信号が送信される。デバイスが遠隔通信網２０５に直接アクセス可能な場合には、直接サービスセンター宛にトナーロウ信号が送信される（ステップ２９０７）。ホストコンピュータを介して接続されている場合には、そのホストからサービスセンタ１０１にトナーロウ信号が送信される（ステップ２９０６）。遠隔通信網にオンラインでアクセスできない場合には、操作者のマニュアル入力によってサービスセンタ１０１にトナーロウ信号が送信される（ステップ２９０５）。

こうして発せられたトナーロウ信号を、サービスセンタ１０１で受信し（ステップ２９０８）、以下、図１１と同様の手順でサービスモジュール２１０とユーザモジュール２５０とによって処理が進められる。

以上のようにして、第１の実施形態及び第２の実施形態における効果に加えて、ユーザが在庫管理を行っている場合には、ユーザの在庫を利用したカートリッジ管理システムを構築することができる。

［第５の実施形態］
第１の実施形態の図１２の説明では、ユーザサイトにおいて印刷された出力枚数に応じて課金を行う処理、及び、図２１の説明ではデバイスの保守の処理において、プリント枚数情報に関すデータに応じた料金がプリンタに対する保守サービス料金を含み、実質的にプリント枚数に関するデータに応じた料金以外の料金を徴収することなく、プリンタを点検、修理するサービスマンを派遣指示する処理についての説明を行ってきた。

第５の実施形態においては、さらにユーザにとってより利便性のある保守サービスを提供することができる課金システムについての説明を行う。

図３２は、ユーザサイトとサービスセンタ間での契約処理に関するデータの送受信の概要を示すものである。ユーザサイト、サービスセンタは図１におけるユーザサイト、サービスセンタにそれぞれ対応するものである。図３２の各ステップの処理において、ユーザサイト側での処理はＰＣ２０８によって行われ、サービスセンタ側での処理はＰＣ２０３によって行われるものとする。ここで、ＰＣ２０８、ＰＣ２０３の機能は第１〜第４の実施例において説明したものと同様であり、ブロック構成図は図３に示されるものに該当する。ＰＣ２０８、ＰＣ２０３における各処理はＲＯＭ３０７、ＲＡＭ３０２、ＨＤ３０３の何れかに記憶されたプログラムコードに基づく処理をＣＰＵ３０１が制御することによって実現されるものである。また、ＰＣ２０３はデータベースサーバ２０１と連動しており、該データベースサーバ２０１に記憶されたデータ内容に基づくデータ管理、データ提供（ユーザサイトへのデータ送信）ＣＰＵ３０１によって行われる。無論、ＰＣ２０３とデータベースサーバ２０１とは物理的に別々であっても同一であっても本発明の機能は実現可能であり、ＰＣ２０３とデータベース２０１は連動して本発明の機能を達成できるものであればよい。

また、ユーザサイト側での処理はＰＣ２０８に限定されて行われるものではなく、プリンタ１００ａ、プリンタ１００ｂ、ファクシミリ２０６等のデバイス機器にＰＣ２０８と同等の機能（例えば遠隔通信網２０５を介して外部と双方向の通信が可能な機能）を持たせることにより、デバイス機器によって処理を行わせることも本発明では想定される。なお、その際の各デバイスのブロック構成図は図６、図７等に示したものと同様のものであり、デバイスに設けられた記憶部に記憶されたプログラムコードに基づく処理がＣＰＵ６０１、７０１の制御によって実現される。

ステップＳ３２０１ではユーザサイトからＩＤの送信が実行される。該ＩＤはユーザＩＤ、或いは、特定のユーザに関連付けられたけ契約ＩＤに該当するものであり、あるユーザに対する契約情報を特定するためのＩＤである。以下では、ユーザＩＤを例に説明を行っていく。

Ｓ３２０１において送信されるＩＤは、ＰＣ２０８或いは各デバイスに表示画面を介して入力される情報である。本発明ではＰＣ２０８、ＰＣ２０３、各デバイスがＨＴＭＬ、ＸＭＬの等言語を処理できるブラウザ機能を有しているのが望ましい。ＩＤを入力するための画面は、ユーザがＵＲＬ、ファイル特定情報を指定することにより、ＰＣ２０３で生成され送信されてくる。そして、ＰＣ２０８、デバイス等の表示部に表示される。また、ＩＤを入力する画面が表示される前に、ログイン情報の入力をユーザに促すよような画面を表示させるようにすれば、不正にアクセスすることを防止することができる。なお本発明の機能はブラウザ機能を有したものに限らず、双方通信可能な機能をサポートするものであればよい。

ここで、ユーザサイトからサービスセンタへのＩＤ情報の送信は、先に説明したデバイス発のデータをサービスセンタに送信するためのデバイスモジュール２４０、デバイスモジュール２３０、ホストコンピュータのユーザモジュール２５０、在庫管理システム２６０等によって実行される。

ステップＳ３２０２ではユーザサイトから送信されてきたＩＤに応じた契約情報の検索が実行される。ステップＳ３２０３において、ステップＳ３２０２で検索された情報がサービスセンタからユーザサイトに向けて送信される。

ステップＳ３２０４では、ステップＳ３２０３にて送信されてきた情報の表示処理がユーザサイト側の機器で行われる。該表示処理は、ユーザサイトにおけるＰＣ２０８、プリンタ１００ａ等に設けられた表示部に表示される。ここで、該表示部は図３のディスプレイ３０４、図６の操作部６０７、図７の操作部７０７等に相当するものである。

また、後述で説明する図３３、３４、３５、３６、３７、３８、３９、４０、４１に示される表示例（表示情報）は、すべてサービスセンタ側のデータベースサーバ２０１、ＰＣ２０３等の記憶部に管理されるデータであり、それらがユーザサイト側に送信されてプリンタ１００a、プリンタ１００ｂ、ファクシミリ２０６、ＰＣ２０８等の表示部に表示される。また、図１３〜１６、図２２Ａ、２２Ｂについても同様の仕組みとする。

図３３はステップＳ３２０４における表示例であり、デバイス機種（３３０５）毎の契約内容（３３０６）を示すものである。以下の説明では、デバイス毎の契約内容の変更について説明を行うこととする。また、図３３の３３０５に示されるデバイスの種類はプリンタに限定されるものではなく、ファクシミリ、複写機、複合機、パーソナルコンピュータ等の機器が想定される。また、図３４〜４１についてもプリンタに限定されるものではない。

図３４もステップＳ３２０４における表示例であり、該表示情報はユーザが所有するデバイス機器（３４０１）、該デバイスにそれぞれ対応するＩＤ（３４０２）、契約状況（３４０３）、デバイス毎の出力枚数（３４０４）、契約状況に対応する１枚あたりの出力単価（３４０５）、１枚当たりの出力単価に基づく請求金額（３４０６）、デバイス毎に対応する契約期間（３４０７）がそれぞれ表示されている。デバイス毎の出力枚数（３４０４）は未課金の枚数に対応するような形態を示しており、この他に契約期間内の総印刷枚数、月、週等の所定期間毎の印刷枚数集計が表示されることも本願では想定される。さらに、第１〜３実施例の仕組みに基づいて所定期間毎に出力枚数（３４０４）がサービスセンタにてカウントされ、カウントされた枚数に応じて課金計算処理がサービスセンタにて実行される。図３４のような表示情報がユーザサイトで閲覧することができるため、ユーザは契約更新に際して、どの機器に対して契約更新を行えばよいか等を明確に知ることができる。また、サービスセンタにおけるデバイス毎、消耗品毎の出力枚数３４０４の取得については第１、２、３の実施の形態で説明してきたような仕組みと同様なのでここでは詳細な説明は省略する。

ステップＳ３２０５においては、契約処理の対象となる機器を特定する情報の入力が図３３のチェック欄３３０４の指示入力に応じて行われれる。

ステップＳ３２０６ではステップＳ３２０５で入力された契約対象機器の情報がＩＤとともに（ステップＳ３２０１でのＩＤ）ユーザサイトからサービスセンタに対して送信される。

サービスセンタでは、ステップＳ３２０６においてユーザサイトから送信されてきた契約機器を特定する情報とＩＤとに基づく詳細情報の検索が実行処理され、検索結果がユーザサイトに送信される（Ｓ３２０７）。

図３５はステップＳ３２０７で送信されてきた情報のユーザサイトにおける表示例である。図３５の表示例においては、ＬＢＰ−Ａ２（ＬＢＰの２台目という意味）が図３３において選択された結果を示している。３５０３には、「ＬＢＰ−Ａ２に２００１年１２月３１日まで「スポット保守契約」が結ばれている」ことを示している。３５０５はユーザが変更したい契約内容を選択するためのチェック欄であり、該チェック欄に入力がなされると、ユーザが識別可能なマークが画面に付加される。また、３５０７は各契約内容の詳細情報を表示するための指示ボタンであり、該指示ボタンに入力がなされると、各契約内容の詳細が画面に表示される。この詳細内容を表示するための指示ボタンは図３３の３３０７としても表示されており、このようにすることでユーザは契約内容を事前に確認するこができる。

図３６、３７はサービスセンタのデータベースサーバ２０１に記憶管理されているデータを示すものであり、先に説明した詳細図３３、３５の詳細ボタン３３０７、３５０７の指示情報とＩＤと（Ｓ３２０９）に応じて、ユーザ側に送信され（Ｓ３２１０）閲覧されるものである。ここで、図３６（Ａ）、図３６（Ｂ）に示される各契約内容の詳細について説明をする。

（スポット保守契約）
スポット保守契約は、料金にＣＲＧ（カートリッジ）の使用料のみが含まれ、出張料金、修理代金、部品代金等はその都度支払う形態である。

（基本保守契約）
基本保守契約は、ＣＲＧの使用料に加え、定期的な訪問メンテナンスと、契約期間内における修理金額が上限を越えない場合には、出張料金、修理代金、部品代金等、修理に伴い発生する費用全てについて、修理回数に関わらず無料で修理を受けることが出来る。上限を越えた分は実費精算となる。図３６（Ｂ）には機種毎の上限金額が記憶管理されているものを示すものであり、図３４と同様にデータベースサーバ２０１に記憶管理されている。

（総合保守契約）
総合保守契約はＣＲＧの使用料に加え、契約期間中の定期的な訪問メンテナンス、出張料金、修理代金、部品代金等、修理に伴い発生する費用について、修理回数・金額に関わらず例外を除いて全て無償となる。

ユーザーはこれらの契約条件を、任意の期間で選択・変更する事が出来る。例えば、プリンタを購入して１年目は故障頻度が低いと想定し、スポット保守契約を選択し、２年目は基本保守契約を、３年目以降は総合保守契約を選択すること等が可能である。

また契約の種類及び内容は、これら３種類に限定されるものではなく、例えばスキャナ―、予約印刷等で使用されるＨＤ、ソータ等の画像形成装置に係るオプションを使用するか否かの選択指示ボタンを図３３等の表示に設け、該オプションの使用課金を出力枚数の課金額に含めるような契約も考えることができる。この場合後述する図３７に示す課金テーブルにオプションの使用料を１枚当たりの金額に対応させたようなデータが記憶された課金テーブルが想定される。

図３７は契約内容に応じて印刷出力プリント１枚あたりの課金金額を示すデータであり、ＬＢＰ―Ａ、Ｂ、Ｃ、Ｄに対応する各種保守契約の印刷出力１枚当たりの課金金額が示されている。該課金テーブルの金額は先に説明したように、１枚当たりの課金金額に保守料金を含む場合と、含まない場合が存在するので、保守料金を含む場合のほうが高い金額となっている。また、Ｓ３２０６において機器を特定する情報がサービスセンタに送信されてきた場合には、ユーザが閲覧する情報として特定された機器に対応する課金テーブル表示情報のみをサービスセンタからユーザサイトへ送信するようにすれば、よりユーザにとって利便性の高いものとなる。

また、本発明では画像形成装置の印刷出力枚数と図３４、図３７のような課金テーブルより求まる１枚当たりの印刷出力枚数の金額とに応じてユーザへの請求金額がサービスセンタにて計算される。なお、サービスセンタがユーザサイトの画像形成装置の印刷出力枚数情報を取得することに関しては、第１〜３の実施例において図１２、図１７（ｂ）、図２４、図２７等で説明したものと同様とするので詳細な説明は省略する。

また、図３６および３７は同時に表示される形態でも、切り替わり表示されるような表示形態であってもよい。また、図示はされていないが、「戻る」等の指示ボタンを設けることによって直前に閲覧していた画面にリターンするようにすれば、図３３、３５等の画面に戻ることができる。

一方、ステップＳ３２０８において詳細ボタンの入力が行われなかった場合（Ｓ３２０８のＮｏ）、または、Ｓ３２０９、Ｓ３２１０の処理が行われた後、Ｓ３２１１において、図３５の画面を介したユーザからの指示に応じた保守形態を特定する契約情報の入力が行われるＳ３２１２で契約更新情報（図３５の３５０９の入力に対応）の送信がユーザサイトからサービスセンタに向けて行われる。この契約更新情報には、図３５の画面を介して生成されたある機器に対する保守形態を特定する情報、そしてＩＤが少なくとも含まれている。ステップＳ３２１２で送信されてくる情報を受信したサービスセンタは、契約期間の指定を行うための情報をユーザサイト側へ送信する（図示はせず）。その表示例が図３８である。

ステップＳ３２１３ではさらに、図３８の３８０４を介して契約期間が入力され、３８０６の「ＯＫボタン」の入力がなされると、新たな契約に対する期間指定情報の送信がＩＤ，機器及び保守形態を特定する情報と供にユーザサイトからサービスセンタに対して行われる。

Ｓ３２１４でサービスセンタからのＳ３２１３に応じた契約確認画面情報の送信がユーザサイトへ送信される。ユーザサイトにおける表示例を図３９に示す。これにユーザが同意する（図３９の了承ボタン３９０５の入力）と、了承を示す情報がユーザサイトからサービスセンタへ送信される。

了承の情報を受信したサービスセンタからは図４０に示すような情報がユーザサイトへ送信される（フローには図示せず）。該表示情報には印刷を実行するための指示ボタン情報（４００５）が含まれており、該ボタンの入力がなされると、該表示された情報に対応する印刷出力が実行される。該印刷出力は図４０の情報を表示している機器がパーソナルコンピュータ（ＰＣ）であった場合には、ＰＣに接続されたプリンタ等から、また、図４０を表示している機器がプリンタ装置等のデバイス機器であった場合自装置において出力処理が行われる。

図４０に示される処理が終了した後のサーバ内での契約情報管理について説明する。図４０にて、最終的にユーザの契約内容が変更された場合、或いは指定した期間において変更予定の場合には、図３４に示されるような画面が、新たな契約内容が盛り込まれたような内容に変更され、それに対応するデータの内容も変更される。変更されたデータはサービスセンタ側のデータベースサーバ２０１、ＰＣ２０３等の記憶部に記憶されるとともに、ユーザが閲覧することもできる。

図３５を参照すると、ＬＢＰ−Ａ２に対する契約情報として、２００１年１２月３１日まで、「スポット保守契約」が結ばれているが、図３５、図３８、３９に示されるユーザインターフェイスを介して２００２年０１月０１日〜２００２年６月３０日まで「基本保守契約」を結ぶようにユーザにより指示された場合に、図３４の表示は図４１のように変更される。また、データベースサーバ２０１、ＰＣ２０３等の記憶部に記憶された情報も、図３４に示された情報から図４１に示される情報に変更される。機種がＬＢＰＡで「スポット契約」から「基本保守契約」に変更されたことがデータベースサーバ２０１、ＰＣ２０３において認識されると、図３７の記憶テーブルが参照され、１枚当たりの単価が１０円から１３円に変更され、図４１に示されるようなデータが生成され、管理される。なお、図４１では、契約中の機種（４１０８）と、契約予定の機種（４１０９）が識別可能となるように表示されており、これに対応したデータがデータベースサーバ２０１、ＰＣ２０３に記憶されている。また、契約期間切れの機種に関しても識別可能に表示させるようなことも本実施形態では想定される。

上に説明したような図３４、図４１に示されるような管理テーブルをデータベースサーバ２０１、ＰＣ２０３で記憶管理することにより、ユーザサイト側からＩＤと供に送信されてきた印刷枚数等の使用状況情報を受信して、受信したＩＤに対応する印刷枚数当と、図３４、図４１に示されるテーブルとに基づいてユーザに請求金額情報が所定期間毎に送信される。なお、ユーザ先に表示される請求金額情報を示す表示例は図１６に示される表示例に該当する。

このときに、ユーザサイトから使用状況情報と供に送信されてくるＩＤとしては、ユーザＩＤ，機種ＩＤ（機番ＩＤ），契約ＩＤ等が考えられ、これら、ＩＤ情報はカートリッジに設けられた不揮発性メモリ、或いは、画像形成装置に設けられた不揮発性メモリ、或いはＰＣ２０８の記憶部に記憶されたものであり、どの機器に対する使用状況情報かを特定するための情報である。

また、画像形成装置毎（プリンタ１００a、プリンタ１００ｂ、ファクシミリ２０６等）、或いは、消耗品毎の出力枚数等の使用状況情報がＩＤとともにユーザサイト側からサービスセンタに送信されてくる仕組みについては、第１〜３の実施形態の図１２、図１７（ｂ）、図２４、図２７等で説明したものと同様である。即ち、ＰＣ２０８から使用状況情報がＩＤと供に送信される形態と、デバイス機器本体から使用状況情報がＩＤと供に送信される形態とが本発明では想定される。この画像形成装置或いは消耗品の使用状況情報と供に送信されるＩＤは、図３２のＳ３２０１において、特定のユーザの契約情報を特定するためのＩＤ（ユーザＩＤ）と同じＩＤであることが望ましいが、無論別のＩＤであっても本発明の目的を達成することは可能である。

上に説明してきた第５実施例における更なる応用例を以下に説明する。

（１）図３２のＳ３２０１〜Ｓ３２０４の説明においてはユーザの契約情報を特定するＩＤとしてユーザＩＤを例に説明を行ってきたが、本発明はユーザＩＤのみに限定されるものではなく、例えば、"機器本体のＩＤ"、トナーカートリッジ等の"消耗品ＩＤ"、"特定の機器、消耗品に対応させた契約ＩＤ"等にも適応可能である。即ち、契約内容及び契約対象となる機器を特定できるＩＤであれば本発明の目的は達成される。例えば、図３２のＳ３２０１でユーザサイトからサービスセンタに送信されるＩＤに機器本体のＩＤ、消耗品ＩＤ、特定の機器、消耗品に対応した契約ＩＤ等の何れかを適応することよって、図３２の各ステップ処理は特定の機器、消耗品に対して実行されるような形態になる。これは、契約変更対象機種等が予め絞られている場合などに有用となってくる。

（２）ステップ３２０４における表示例においては、画像形成装置の機器本体に対応する契約内容を表示させるような形態を説明してきたが、Ｓ３２０１で送信されるＩＤ（ユーザＩＤ）に消耗品ＩＤを関連させることで消耗品毎（例えばカートリッジ）の契約内容を表示させることも本発明では想定される。ここで消耗品毎のＩＤはユーザＩＤと関連されてデータベースサーバ２０１で管理されており、ＣＰＵ３０１によってユーザＩＤからユーザが使用している消耗品を検索することができ、消耗品ＩＤ毎の契約管理が行われる。ここで、第１〜３の実施例で説明した、消耗品毎の印刷出力枚数等の使用状況情報をサービスセンタで取得する仕組みを組み合わせることにより、プリント１枚当たりの課金は、特定の消耗品の契約内容に応じて行われることになる。また、消耗品にＩＤを記憶する記憶手段が備えられている場合には、契約対象範囲にある複数の機器間を移動して消耗品が使用されても、消耗品が取り付けられるデバイスにより消耗品のＩＤが認識可能なため、複数の機器をまたがる消耗品の契約及び使用状況の管理が本発明では可能となる。このように消耗品毎のＩＤを管理する形態では、図３２の各ステップにおけるＩＤは消耗品ＩＤに対応し、各表示画面は機器毎に対して表示されるのではなく、各消耗品毎に対して行われることとなる。

（３）サービスセンタに設置されたデータベースサーバ２０１で特定のユーザの画像形成装置等の使用状況、故障状況、使用期間等の情報を管理し、該管理する情報に応じて図３６に示される保守契約の中から適切な保守契約情報を生成または検索し、ユーザサイトに通知するようにすれば、ユーザには画像形成装置の消耗状況に応じた保守メンテナンスサービスを容易に提供することができる。例えば、第１の実施の形態の図２１で説明したようなユーザの所有するデバイス（プリンタ等）の不具合情報をデータベースサーバ２０１に蓄積しておき、予め機種と，故障状況とに応じて適切な契約内容をユーザに通知するようにすることができる。

また、サービスの形態として、図３５で示された「総合保守契約」、「基本保守契約」、「スポット保守契約」等の複数の契約を自動的に切り替えるようにすることも本願発明では可能である。例えば、データベースサーバ２０１に予め、デバイス機種毎の使用状況（総印刷出力枚数、各種故障状況）に対応させた適切な契約情報を記憶しておき、図２１に説明したようなユーザのデバイスの不具合情報を受信することにより、自動的にユーザに適切な保守契約を提供することも可能である。さらに、自動的に保守契約内容を変更し、データベースサーバ２０１の契約情報記憶内容を更新する際にはユーザにその旨を通知する電子メール等を送信し確認するようにすれば、ユーザが確認したうえで、自動的に保守契約を変更することが可能となる。

＜第５の実施の形態における効果＞
以上説明した本実施形態のカートリッジ管理システムによれば次のような効果が得られる。

（１）保守メンテナンス料金をデバイスが印刷出力した１枚あたりの課金金額に含めるようにしたので、ユーザからの保守契約内容の変更があった際にも柔軟に対応するシステムを提供することができる。図３７に示すような課金テーブルをサービスセンタに設けることにより、デバイス機器毎、消耗品毎、ユーザ毎に対応した１枚当たりの印刷出力料金を設定することが可能となり、ユーザのニーズにあった保守契約を提供するシステムの構築が可能となった。

（２）図３３、３５、図３８等のユーザインターフェースを介してユーザーは希望する保守形態に応じて、スポット保守契約、基本保守契約、総合保守契約等複数の契約条件を任意に選択することが可能となり、ユーザーはこれらの契約条件を、任意の期間で選択・変更する事が出来る。例えば、プリンタを購入して１年目は故障頻度が低いと想定し、スポット保守契約を選択し、２年目は基本保守契約を、３年目以降は総合保守契約を選択すること等が可能である。

なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した第１乃至第５実施形態の機能を実現する、図１０乃至図１２、図１７乃至図１８、図２１、図２４、図２８、図３０、図３２に示されている手順のプログラムコードを、実行主体に応じてデバイスモジュール、ユーザモジュール、サービスモジュールごとに区分して記憶媒体に記録し、その記憶媒体（または記録媒体）を、実行主体であるデバイスやパーソナルコンピュータにそれぞれ供給し、それら（またはCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

なお、本発明は、トナーにとどまらず、たとえば感光ドラム、定着部材、クリーニング部材などのあらゆる消耗品に適用できる。

第１の実施の形態におけるカートリッジ管理システムの概略を示す図である。 第１の実施の形態におけるユーザサイト及びサービスセンタの構成を示す図である。 パーソナルコンピュータのブロック図である。 ファクシミリの断面図である。 プリンタの断面図である。 プリンタのブロック図である。 ファクシミリのブロック図である。 メモリを備えるトナーカートリッジの外観図である。 カートリッジの備えるメモリに記憶されるデータの一例を示す図である。 第１実施形態におけるトナーロウ信号の送信と受信の手順を示すシステムフローチャートである。 第１実施形態におけるトナーロウ信号を受信したサービスセンタにおける処理手順を示すフローチャートである。 第１実施形態における課金情報の送信及び処理を示すシステムフローチャートである。 カートリッジ交換を促すＵＩ画面の一例を示す図である。 カートリッジ交換日時を調整するためのＵＩ画面の一例を示す図である。 カートリッジの配送及び回収予定の確認を促すＵＩ画面の一例を示す図である。 請求金額を通知するＵＩ画面の一例を示す図である。 デバイスにおけるプリント枚数送信の手順を示すフローチャートである。 デバイスにおけるカートリッジ交換時の手順を示すフローチャートである。 第１実施形態におけるカートリッジのトナー切れを予測する分析システムの構成を示すブロック図である。 第１実施形態におけるカートリッジのトナー切れを予測する分析システムの構成を示すブロック図である。 ユーザから不具合情報を送信して修理に至るまでのシステムフローチャートである。 修理日時を調整するためのＵＩ画面及び不具合内容を通知するためのＵＩ画面の一例を示す図である。 第２実施形態において、各デバイスが保持するデータの一例を示す図である。 第２実施形態において、課金情報の送信及び処理を示すシステムフローチャートである。 第２実施形態におけるカートリッジのトナー切れを予測する分析システムの構成を示すブロック図である。 第２実施形態におけるカートリッジのトナー切れを予測する分析システムの構成を示すブロック図である。 第３の実施の形態におけるカートリッジ管理システムの概略を示す図である。 第３実施形態におけるトナーロウ信号を受信したサービスセンタにおける処理手順を示すフローチャートである。 第３の実施の形態におけるユーザサイト及びサービスセンタの構成を示す図である。 第４実施形態におけるトナーロウ信号の送信と受信の手順を示すシステムフローチャートである。 従来のトナーカートリッジの販売及び回収、保守の仕方を説明するための図である。 第５実施形態におけるユーザサイトとサービスセンタ間での契約処理の一例のフローチャートである。 第５実施形態におけるユーザ毎の契約状況を示すＵＩ画面の一例を示す図である。 第５実施形態におけるユーザ毎の契約状況を示すＵＩ画面、或いは、データベースサーバの記憶内容の一例を示す図である。 第５実施形態における契約変更を行うためのＵＩ画面、或いは、データベースサーバの記憶内容の一例を示す図である。 第５実施形態における契約内容の確認を行うためのＵＩ画面の一例を示す図である。 第５実施形態における契約内容の確認を行うためのＵＩ画面の一例を示す図である。 第５実施形態における契約期間の指定を行うためのＵＩ画面の一例を示す図である。 第５実施形態における契約変更確認を行うためのＵＩ画面の一例を示す図である。 第５実施形態における契約変更確定の確認を行うためのＵＩ画面の一例を示す図である。 第５実施形態におけるユーザ毎の契約状況を示すＵＩ画面、或いは、データベースサーバの記憶内容の一例を示す図である。

Claims (25)

1. 画像形成装置に係る複数種類の契約を管理する情報処理装置において、
   前記画像形成装置における印刷枚数の情報をネットワークを介して取得する取得手段と、
   画像形成装置のサービスマンによるメンテナンス内容が異なる契約に応じて、印刷出力１枚あたりの課金金額を異ならせて記憶する記憶手段と、
   前記取得された印刷枚数と、前記画像形成装置における契約に応じて前記記憶手段に記憶された前記画像形成装置の印刷出力一枚あたりの課金金額と、に基づいて請求金額を計算する計算手段と、を有することを特徴とする情報処理装置。
2. 前記記憶手段には、サービスマンによるメンテナンス内容が異なる第１種契約と第２種契約との夫々に対応して印刷出力一枚当たりの第１課金金額と第２課金金額とが記憶されており、前記第２課金金額は前記第１課金金額に所定料金が加算されていることを特徴とする請求項１に記載の情報処理装置。
3. 前記契約を指示するための、ブラウザーで読込み可能な契約指示画面情報を外部装置に供給する供給手段をさらに有し、前記計算手段は、前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記契約を指定するための契約指示画面情報に基づく画面を介しての指示を受付ける手段をさらに有し、前記計算手段は、前記受付けた契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算することを特徴とする請求項１又は２に記載の情報処理装置。
5. 前記契約を指示するための契約指示画面情報に基づく画面を介して入力された契約の種別と、該種別の契約に対応する期間の指示を受付ける手段をさらに有し、前記計算手段は、前記受付けた前記期間に対応して取得された印刷出力枚数と、前記期間に対応する契約の種別に対応する印刷出力一枚当たりの課金金額とに基づき前記期間における請求金額を計算することを特徴とする請求項１又は２に記載の情報処理装置。
6. プリンタを識別する識別子と該識別子に対応する契約を確認する画面を外部装置に送信する送信手段をさらに有することを特徴とする請求項１から５の何れかに記載の情報処理装置。
7. 前記画像形成装置の稼動情報に基づき最適な契約情報を検索し通知する通知手段をさらに有することを特徴とする請求項１から６の何れかに記載の情報処理装置。
8. 前記稼動情報には使用状況、及び、故障状況が含まれることを特徴とする請求項１から６の何れかに記載の情報処理装置。
9. 画像形成装置に係る複数種類の契約を管理する情報処理装置において、
   前記画像形成装置における契約が、サービスマンによるメンテナンス内容が第１内容の第１種契約か、メンテナンス内容が第２内容の第２種契約か、を管理する管理手段と、
   前記画像形成装置における印刷枚数の情報をネットワークを介して取得する取得手段と、
   前記画像形成装置の契約が第１種契約か第２種契約かに応じて前記画像形成装置に対応させて印刷出力一枚当たりの課金金額を異ならせて記憶する記憶手段と、
   前記取得された前記画像形成装置の印刷枚数と、前記画像形成装置に対応させて前記記憶手段に記憶された印刷出力一枚当たりの課金金額と、に基づき請求金額を計算する計算手段と、を有することを特徴とする情報処理装置。
10. 前記契約を指示するための契約指示画面情報を外部装置に提供する提供手段をさらに有し、前記計算手段は、前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算することを特徴とする請求項９に記載の情報処理装置。
11. 画像形成装置に係る複数種類の契約を管理する情報処理装置において、
    画像形成装置における契約を指示するための契約指示画面情報を外部装置に供給する供給手段と、
    前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約の種別を画前記像形成装置に関連付けて管理する管理手段と、
    前記指示された契約の種別に対応した印刷出力一枚当たりの課金金額を前記画像形成装置と関連付けて記憶する記憶手段と、
    前記画像形成装置の印刷出力枚数を通信回線を介して取得する取得手段と、
    前記取得手段により取得した前記印刷出力枚数と、前記記憶手段に記憶された前記画像形成装置の印刷出力一枚あたりの課金金額と、に基づき請求金額を計算する計算手段とを有することを特徴とする情報処理装置。
12. 画像形成装置に係る複数種類の契約を管理する情報処理方法であって、
    前記画像形成装置における印刷枚数の情報をネットワークを介して取得する取得ステップと、
    画像形成装置のサービスマンによるメンテナンス内容が異なる契約に応じて、印刷出力１枚あたりの課金金額を異ならせて記憶部に記憶させる制御ステップと、
    前記取得された印刷枚数と、前記画像形成装置における契約に応じて前記記憶部に記憶された前記画像形成装置の印刷出力一枚あたりの課金金額と、に基づいて請求金額を計算する計算ステップと、を有することを特徴とする情報処理方法。
13. 前記記憶部には、サービスマンによるメンテナンス内容が異なる第１種契約と第２種契約との夫々に対応して印刷出力一枚当たりの第１課金金額と第２課金金額とが記憶されており、前記第２課金金額は前記第１課金金額に所定料金が加算されていることを特徴とする請求項１２に記載の情報処理方法。
14. 前記契約を指示するための、ブラウザーで読込み可能な契約指示画面情報を外部装置に供給する供給ステップをさらに有し、前記計算ステップは、前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算することを特徴とする請求項１２又は１３に記載の情報処理方法。
15. 前記契約を指定するための契約指示画面情報に基づく画面を介しての指示を受付けるステップをさらに有し、前記計算ステップは、前記受付けた契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算することを特徴とする請求項１２又は１３に記載の情報処理方法。
16. 前記契約を指示するための契約指示画面情報に基づく画面を介して入力された契約の種別と、該種別の契約に対応する期間の指示を受付けるステップをさらに有し、前記計算ステップは、前記受付けた前記期間に対応して取得された印刷出力枚数と、前記期間に対応する契約の種別に対応する印刷出力一枚当たりの課金金額とに基づき前記期間における請求金額を計算することを特徴とする請求項１２又は１３に記載の情報処理方法。
17. プリンタを識別する識別子と該識別子に対応する契約を確認する画面を外部装置に送信する送信ステップをさらに有することを特徴とする請求項１２から１６の何れかに記載の情報処理方法。
18. 前記画像形成装置の稼動情報に基づき最適な契約情報を検索し通知する通知ステップをさらに有することを特徴とする請求項１２から１７の何れかに記載の情報処理方法。
19. 前記稼動情報には使用状況、及び、故障状況が含まれることを特徴とする請求項１２から１８の何れかに記載の情報処理方法。
20. 画像形成装置に係る複数種類の契約を管理する情報処理方法であって、
    前記画像形成装置における契約が、サービスマンによるメンテナンス内容が第１内容の第１種契約か、メンテナンス内容が第２内容の第２種契約か、を管理する管理ステップと、
    前記画像形成装置における印刷枚数の情報をネットワークを介して取得する取得ステップと、
    前記画像形成装置の契約が第１種契約か第２種契約かに応じて前記画像形成装置に対応させて印刷出力一枚当たりの課金金額を異ならせて記憶部に記憶させる制御ステップと、
    前記取得された前記画像形成装置の印刷枚数と、前記画像形成装置に対応させて前記記憶部に記憶された印刷出力一枚当たりの課金金額と、に基づき請求金額を計算する計算ステップと、を有することを特徴とする情報処理方法。
21. 前記契約を指示するための契約指示画面情報を外部装置に提供する提供ステップをさらに有し、前記計算ステップは、前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約に応じた印刷出力一枚当たりの課金金額と、前記印刷出力枚数とに基づき請求金額を計算することを特徴とする請求項２０に記載の情報処理方法。
22. 画像形成装置に係る複数種類の契約を管理する情報処理方法であって、
    画像形成装置における契約を指示するための契約指示画面情報を外部装置に供給する供給ステップと、
    前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約の種別を画前記像形成装置に関連付けて管理する管理ステップと、
    前記指示された契約の種別に対応した印刷出力一枚当たりの課金金額を前記画像形成装置と関連付けて記憶部に記憶させる制御ステップと、
    前記画像形成装置の印刷出力枚数を通信回線を介して取得する取得ステップと、
    前記取得ステップにおいて取得された前記印刷出力枚数と、前記記憶部に記憶された前記画像形成装置の印刷出力一枚あたりの課金金額と、に基づき請求金額を計算する計算ステップとを有することを特徴とする情報処理方法。
23. 画像形成装置に係る複数種類の契約を管理する情報処理装置において実行されるコンピュータプログラムであって、
    前記画像形成装置における印刷枚数の情報をネットワークを介して取得する取得ステップと、
    画像形成装置のサービスマンによるメンテナンス内容が異なる契約に応じて、印刷出力１枚あたりの課金金額を異ならせて記憶部に記憶させる制御ステップと、
    前記取得された印刷枚数と、前記画像形成装置における契約に応じて前記記憶部に記憶された前記画像形成装置の印刷出力一枚あたりの課金金額と、に基づいて請求金額を計算する計算ステップとをコンピュータに実行させるためのコンピュータプログラム。
24. 画像形成装置に係る複数種類の契約を管理する情報処理装置において実行されるコンピュータプログラムであって、
    前記画像形成装置における契約が、サービスマンによるメンテナンス内容が第１内容の第１種契約か、メンテナンス内容が第２内容の第２種契約か、を管理する管理ステップと、
    前記画像形成装置における印刷枚数の情報をネットワークを介して取得する取得ステップと、
    前記画像形成装置の契約が第１種契約か第２種契約かに応じて前記画像形成装置に対応させて印刷出力一枚当たりの課金金額を異ならせて記憶部に記憶させる制御ステップと、
    前記取得された前記画像形成装置の印刷枚数と、前記画像形成装置に対応させて前記記憶部に記憶された印刷出力一枚当たりの課金金額と、に基づき請求金額を計算する計算ステップとをコンピュータに実行させるためのコンピュータプログラム。
25. 画像形成装置に係る複数種類の契約を管理する情報処理装置において実行されるコンピュータプログラムであって、
    画像形成装置における契約を指示するための契約指示画面情報を外部装置に供給する供給ステップと、
    前記契約指示画面情報に基づく前記外部装置における画面を介して指示された契約の種別を画前記像形成装置に関連付けて管理する管理ステップと、
    前記指示された契約の種別に対応した印刷出力一枚当たりの課金金額を前記画像形成装置と関連付けて記憶部に記憶させる制御ステップと、
    前記画像形成装置の印刷出力枚数を通信回線を介して取得する取得ステップと、
    前記取得ステップにおいて取得された前記印刷出力枚数と、前記記憶部に記憶された前記画像形成装置の印刷出力一枚あたりの課金金額と、に基づき請求金額を計算する計算ステップとをコンピュータに実行させるためのコンピュータプログラム。

Images