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

Abstract

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

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などが実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれる。

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

【０２４９】

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

【図面の簡単な説明】

【図１】第１の実施の形態におけるカートリッジ管理シ
ステムの概略を示す図である。

【図２】第１の実施の形態におけるユーザサイト及びサ
ービスセンタの構成を示す図である。

【図３】パーソナルコンピュータのブロック図である。

【図４】ファクシミリの断面図である。

【図５】プリンタの断面図である。

【図６】プリンタのブロック図である。

【図７】ファクシミリのブロック図である。

【図８】メモリを備えるトナーカートリッジの外観図で
ある。

【図９】カートリッジの備えるメモリに記憶されるデー
タの一例を示す図である。

【図１０】第１実施形態におけるトナーロウ信号の送信
と受信の手順を示すシステムフローチャートである。

【図１１】第１実施形態におけるトナーロウ信号を受信
したサービスセンタにおける処理手順を示すフローチャ
ートである。

【図１２】第１実施形態における課金情報の送信及び処
理を示すシステムフローチャートである。

【図１３】カートリッジ交換を促すＵＩ画面の一例を示
す図である。

【図１４】カートリッジ交換日時を調整するためのＵＩ
画面の一例を示す図である。

【図１５】カートリッジの配送及び回収予定の確認を促
すＵＩ画面の一例を示す図である。

【図１６】請求金額を通知するＵＩ画面の一例を示す図
である。

【図１７】デバイスにおけるプリント枚数送信の手順を
示すフローチャートである。

【図１８】デバイスにおけるカートリッジ交換時の手順
を示すフローチャートである。

【図１９】第１実施形態におけるカートリッジのトナー
切れを予測する分析システムの構成を示すブロック図で
ある。

【図２０】第１実施形態におけるカートリッジのトナー
切れを予測する分析システムの構成を示すブロック図で
ある。

【図２１】ユーザから不具合情報を送信して修理に至る
までのシステムフローチャートである。

【図２２】修理日時を調整するためのＵＩ画面及び不具
合内容を通知するためのＵＩ画面の一例を示す図であ
る。

【図２３】第２実施形態において、各デバイスが保持す
るデータの一例を示す図である。

【図２４】第２実施形態において、課金情報の送信及び
処理を示すシステムフローチャートである。

【図２５】第２実施形態におけるカートリッジのトナー
切れを予測する分析システムの構成を示すブロック図で
ある。

【図２６】第２実施形態におけるカートリッジのトナー
切れを予測する分析システムの構成を示すブロック図で
ある。

【図２７】第３の実施の形態におけるカートリッジ管理
システムの概略を示す図である。

【図２８】第３実施形態におけるトナーロウ信号を受信
したサービスセンタにおける処理手順を示すフローチャ
ートである。

【図２９】第３の実施の形態におけるユーザサイト及び
サービスセンタの構成を示す図である。

【図３０】第４実施形態におけるトナーロウ信号の送信
と受信の手順を示すシステムフローチャートである。

【図３１】従来のトナーカートリッジの販売及び回収、
保守の仕方を説明するための図である。

【図３２】第５実施形態におけるユーザサイトとサービ
スセンタ間での契約処理の一例のフローチャートであ
る。

【図３３】第５実施形態におけるユーザ毎の契約状況を
示すＵＩ画面の一例を示す図である。

【図３４】第５実施形態におけるユーザ毎の契約状況を
示すＵＩ画面、或いは、データベースサーバの記憶内容
の一例を示す図である。

【図３５】第５実施形態における契約変更を行うための
ＵＩ画面、或いは、データベースサーバの記憶内容の一
例を示す図である。

【図３６】第５実施形態における契約内容の確認を行う
ためのＵＩ画面の一例を示す図である。

【図３７】第５実施形態における契約内容の確認を行う
ためのＵＩ画面の一例を示す図である。

【図３８】第５実施形態における契約期間の指定を行う
ためのＵＩ画面の一例を示す図である。

【図３９】第５実施形態における契約変更確認を行うた
めのＵＩ画面の一例を示す図である。

【図４０】第５実施形態における契約変更確定の確認を
行うためのＵＩ画面の一例を示す図である。

【図４１】第５実施形態におけるユーザ毎の契約状況を
示すＵＩ画面、或いは、データベースサーバの記憶内容
の一例を示す図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 二木 徹 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 酒部 勇治 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 川本 謙吾 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内

Claims (29)

【特許請求の範囲】
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. 【請求項２５】 画像形成装置の不具合情報を受信する
    受信手段と、 前記受信した不具合情報を、前記画像形成装置の不具合
    に対応するサービス部門に設けられたコンピュータに送
    信する送信手段とを有することを特徴とする情報処理装
    置。
26. 【請求項２６】 前記画像形成装置の不具合情報を入力
    し送信するための画面情報を生成する画面情報生成手段
    を更に有することを特徴とする請求項２５に記載の情報
    処理装置。
27. 【請求項２７】 画像形成装置の不具合情報を受信する
    受信工程と、 前記受信した不具合情報を、前記画像形成装置の不具合
    に対応するサービス部門に設けられたコンピュータに送
    信する送信工程とを有することを特徴とする情報処理方
    法。
28. 【請求項２８】 画像形成装置の不具合情報を受信する
    受信手段と、 前記受信した不具合情報を、前記画像形成装置の不具合
    に対応するサービス部門に設けられたコンピュータに送
    信する送信手段とを実現するためのコンピュータプログ
    ラム。
29. 【請求項２９】 請求項２８に記載のコンピュータプロ
    グラムを格納することを特徴とするコンピュータ可読記
    憶媒体。