JP2003050878A - サーバ装置およびサーバ装置の制御方法、機器保証システム、機器保証サーバ装置、機器保証システムの制御方法 - Google Patents

Abstract

(57)【要約】 【課題】サービス時のユーザの利便性を向上させ、また
サービス側の情報管理を一元化する。 【解決手段】消耗品を使用する機器１０２において、機
器１０２の保証は保証付消耗品を購入することで付与さ
れ、該保証の情報を管理サーバ１０１が管理する。ユー
ザ１０３からサービス依頼情報を受信すると、サービス
依頼のあった機器が保証対象か判定し、対象であれば、
故障内容を通知させるための書式データをユーザに送信
して故障内容を通知させ、故障内容とともにサービス依
頼情報をサービス店端末や販売店端末に対して通知す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、消耗品を使用する
機器の保証情報を管理するサーバ装置およびサーバ装置
の制御方法、制御プログラム、該プログラムを記録した
記録媒体及び該サーバ装置を有する機器保証システムや
その制御方法に関するものである。

【０００２】

【従来の技術】従来、電子機器などを利用者が購入した
場合、その機器について製造者が保証を与えるサービス
がひろく行われている。機器の販売とともに付与される
保証は、一般的には、例えば半年あるいは一年など、本
体機器購入後の一定期間について保守サービスを無償と
するなどの内容である。

【０００３】これに対して、消耗品の交換頻度が多くそ
の種類も多い機器、例えばトナーなどの消耗品を補給す
るタイプの複写機やファクシミリなどの事務機器では、
それらの使用期間全体にわたる継続的な保守が必要とさ
れる。そのために、保守サービスを実施するサービス店
と機器を使用するユーザとが消耗品の交換と機器の修理
を含む保守サービスを内容とする有償保証契約を結び、
ユーザが保証代金として一定額をサービス店又は販売店
などに支払う保証の方法がある。

【０００４】このような保守サービス契約の対象となら
ない製品については、保証期間が切れた場合には、故障
の都度サービス店に依頼して有償で修理を行うことにな
る。

【０００５】いずれにしても、保証契約の有無に限ら
ず、機器の故障修理や点検が必要な際は、保守サービス
を契約しているサービス店に連絡して修理を依頼してい
た。

【０００６】

【発明が解決しようとする課題】しかしながら、従来の
保守サービス依頼及びその受諾に関しては、人手を介し
て全て行っており、契約情報の管理や契約の期限の管理
などが煩雑となっていた。また、情報管理が複雑化して
いることで、サービス店側の対応に遅れが生じることも
多く、サービスがスムースに提供できないため、ユーザ
に対して不満を与える結果となっていた。また、サービ
ス店側はこうした対応を人手を介して行う以上、人件費
などの増加に繋がることとなっていた。

【０００７】また、サービスを行う場合、サービス店側
は事前にサービスを行う機器の設置箇所や機器の種類を
特定するだけでなく、ユーザへの訪問日時や機器の故障
状況など、把握する必要がある情報が多岐に渡る。こう
した情報をその都度ユーザと電話などを用いてやり取り
することで情報を入手することは、情報伝達の観点から
見て効率的とは言えず、時には必要な情報が把握できな
かったり、意思疎通が不十分となるなどして、サービス
店とユーザ間でのトラブルの発生要因となっていた。

【０００８】さらに、機器に使用する消耗品を販売する
販売店と、サービスを依頼するサービス店とが同一でな
い場合が多いため、夫々がユーザに関する情報を各自で
管理する必要があった。これはユーザ側からしてみると
複数の相手先に同じ情報を伝えることになるため面倒で
あるし、また消耗品の発注先とサービスの依頼先が異な
るため、伝票管理などの事務手続きを夫々に対して行う
必要が生じて作業が煩雑化し、利便性の高いものとはい
えなかった。

【０００９】本発明はこれらの課題に鑑み成されたもの
であり、消耗品の受発注とサービス依頼及びサービス提
供とを一元的に管理し処理することで、ユーザの利便性
を向上させ、また、サービス提供側においても、コスト
低減などが実現できる機器保証システム及びサーバ装
置、サーバ装置の制御方法、制御プログラム、該プログ
ラムを記録した記録媒体を提供することを目的とする。

【００１０】

【課題を解決するための手段】上記目的を達成するため
に本願発明は次の構成から成る。

【００１１】消耗品を使用する機器において、前記機器
の保証は保証付き消耗品を購入することで付与され、該
保証の情報を管理するサーバ装置であって、前記機器に
対する保守サービス依頼情報を受信するサービス依頼情
報受信手段と、前記サービス依頼情報受信手段で受信し
た情報と前記保証情報とに基づいて、前記保守サービス
依頼が前記保証の対象となるか否かを判別する判別手段
とを有する。

【００１２】好ましくは、前記サービス依頼情報受信手
段は、サービス依頼に関する情報を受信すると共に、前
記機器を使用するユーザに関する情報、前記機器に関す
る情報、前記保証情報のうち少なくともひとつの情報を
受信し、該情報と前記保証情報とから、前記機器が保証
の対象となるか否かを前記判別手段が判別する。

【００１３】好ましくは、前記サービス依頼情報受信手
段で受信したサービス依頼が、前記判別手段による判別
の結果、前記保証の対象外である機器に対しての依頼で
あった場合、前記保証の対象外である旨の情報と、保証
対象外の機器に対して保守サービスを依頼するか否かを
再度選択させる情報とを、保守サービスの依頼元が利用
可能な端末に送信する。

【００１４】好ましくは、機器に発生し得る故障内容情
報を格納した機種別故障内容情報格納手段と、前記サー
ビス依頼情報受信手段によって受信した前記機器の情報
に基づいて、該機器に発生し得る故障内容情報を前記機
種別故障内容情報格納手段から出力する出力手段と、前
記出力手段によって出力された情報を保守サービスの依
頼元が利用可能な端末に送信する機種別故障情報送信手
段とをさらに有する。

【００１５】好ましくは、前記保守サービス依頼元は、
前記保守サービスを依頼する故障を、前記機種別故障情
報送信手段によって送信された前記予想される故障情報
から適宜選択し、前記保守サービス依頼元が利用可能な
端末から前記サーバ装置に送信した保守サービス依頼内
容情報を、前記保守サービスを行うサービス店が利用可
能な端末へ送信する転送手段を有する。

【００１６】好ましくは、前記転送手段は、前記端末へ
転送する情報に、前記サービス店が前記保守サービス可
能な日時の入力を要求する情報を付加して送信する。

【００１７】好ましくは、前記サービス店が指定した前
記保守サービス可能な日時情報を前記機器を使用するユ
ーザが利用可能な端末に送信する保守サービス受諾情報
送信手段を有する。

【００１８】好ましくは、前記機器に対する保守サービ
スの依頼情報を受信したことに基づいて、前記保守サー
ビスを行うサービス店が利用可能な端末に、保守サービ
スを実施した結果情報の入力を要求する情報を送信す
る。

【００１９】好ましくは、前記保守サービスの結果情報
に基づいて前記保守サービスの費用を算出する費用算出
手段と、前記保証情報に基づいて、前記費用の決済を行
う決済手段とをさらに有する。

【００２０】

【発明の実施の形態】［第１の実施形態］ ＜システム構成＞図１は本発明の実施形態である機器保
証管理システム全体の構成を示す図である。機器保証管
理システム（以下単にシステムとも呼ぶ）は、管理サー
バ１０１と、保守サービス店端末１０４、機器販売店端
末１０５、ユーザ端末１０３をネットワーク１０６で接
続して構成されている。ネットワーク１０６は、機器メ
ーカや販売店、保守サービス店、ユーザの地域的な広が
りに応じた規模であればよい。一般的にはインターネッ
ト網が適当である。なお、図１においては、ネットワー
ク１０６にサーバ及び端末が直接接続されているかのよ
うに記載されているが、ローカルエリアネットワーク
（ＬＡＮ）を介して接続されている場合も含まれる。ま
た、各端末は保守サービス店や機器販売店に設置されて
いる据置型コンピュータである必要はない。例えば携帯
情報端末などであってもよい。次に各端末及びサーバの
構成について説明する。

【００２１】管理サーバ１０１は、機器製造メーカやメ
ーカ代理店などにより運用されるが、本実施形態ではカ
ートリッジ方式のプリンタを製造するメーカにより運用
されるものとする。管理サーバ１０１は、機器としての
プリンタやプリンタで利用する消耗品、プリンタを利用
するユーザ等に関する各種データベースを備えたコンピ
ュータであり、各端末からの要求に応じてそのデータベ
ースを更新あるいは参照して、後述する機器保証管理プ
ログラム等の処理を遂行する。図２は、管理サーバ１０
１等を実現するコンピュータのブロック図である。

【００２２】図２において、管理サーバ１０１は、後述
する図１０乃至図１２で説明するフローチャートに係る
各種プログラムを実行するＣＰＵ２０１を備え、システ
ムバス２０４に接続される各デバイスはＣＰＵ２０１に
より統括的に制御される。ＲＡＭ２０２は、ＣＰＵ１の
主メモリとして機能し、ＣＰＵ２０１はＲＡＭ２０２に
ロードされたプログラムを実行する。キーボードコント
ローラ（ＫＢＣ）２０５は、キーボード２０９ａやポイ
ンティングデバイス２０９ｂからの入力を制御する。Ｃ
ＲＴコントローラ（ＣＲＴＣ）２０６は、ディスプレイ
２１０の表示を制御する。ディスクコントローラ（ＤＫ
Ｃ）２０７は、ブートプログラムやオペレーティングシ
ステム、および後述する図１０乃至図１２で説明するフ
ローチャートに係るプログラムを含む種々のプログラム
や、これも後述するデータベース等を記憶するハードデ
ィスク（ＨＤ）等の外部メモリ２１１とのアクセスを制
御する。プリンタコントローラ（ＰＲＴＣ）２０８は、
所定の双方向インターフェース（双方向Ｉ／Ｆ）２１を
介して不図示のプリンタに接続されて、プリンタとの通
信制御処理を実行する。なお、ＣＰＵ２０１は、例えば
ＲＡＭ２０２上に設定された表示情報ＲＡＭヘの画面イ
メージの展開処理を実行し、後述する各種画面をディス
プレイ２１０上に表示させる。ネットワークインターフ
ェース２０３は、ネットワーク１０６とのインターフェ
ースであるが、サーバ１０１がＬＡＮを介してネットワ
ーク１０６に接続されている場合には、ＬＡＮとのイン
ターフェースとなり、ネットワーク１０６とのインター
フェースはそのＬＡＮ中に別途用意される。

【００２３】機器販売店端末１０５は、メーカが製造し
た機器を販売する機器販売店により運用される。保守サ
ービス店端末１０４は、ユーザに利用されている機器の
保守サービスを提供する保守サービス店により運用され
る。ユーザ端末１０３は、機器のユーザにより使用され
ている。これらの端末１０３〜１０５は管理サーバ１０
１と同様にコンピュータであるため、ここではその説明
を省略する。ただし、管理サーバ１０１と端末１０３，
１０４，１０５との機能上の相違により、インストール
されるプログラムや必要な資源については相違がある。
管理サーバ１０１は、データベースを管理するための資
源として大容量の記憶デバイスを必要とし、また、デー
タベースを管理するためのデータベース管理システム用
プログラムも必要とする。これに対して各端末１０３〜
１０５は、サーバ１０１のデータベースに関する資源は
不要である。サーバおよび端末に共通して必要とされる
のは、後述する情報の交換を実現するための電子メール
等のプログラムである。ネットワーク１０６としてイン
ターネットを利用する場合には、電子メールプログラム
として、インターネット標準である電子メールプロトコ
ル（ＳＭＴＰ，ＰＯＰ）をサポートするプログラムを利
用できる。また、端末に所望の画面を表示させ、必要な
入力データを端末からサーバに応答させるために、各端
末側ではクライアントとしてインターネット標準である
ハイパーテキスト転送プロトコル（ＨＴＴＰ）をサポー
トするウエブブラウザプログラムを利用することがで
き、管理サーバ１０１はウエブサーバプログラムを利用
することができる。ＨＴＴＰに従って端末から送信され
たデータは、ウエブサーバからいわゆるＣＧＩ（Common
Gateway Interface）を介して後述する機器保証管理プ
ログラムに渡されて処理に供せられる。

【００２４】ここで、ユーザ端末１０３には、直接又は
LANなどの適当なネットワークを介してプリンタ１０２
が接続されている。プリンタ１０２は電子写真方式のプ
リンタであり、トナーを含む現像部と静電ドラムとをユ
ニット化したトナーカートリッジにより消耗品が供給さ
れる。図３はプリンタ１０２の断面図である。

【００２５】図３において、プリンタ本体１０２は、供
給される文字パターン等を基に、記録媒体である記録紙
上に像を形成する。操作パネル７００には操作のための
スイツチ及びＬＥＤ表示器などが配されている。制御ユ
ニット３０１はプリンタ１０２全体の制御及び文字パタ
ーン情報等の解析を行う。この制御ユニット３０１は主
に文字パターン情報をビデオ信号に変換してレーザドラ
イバ３０２に出力する。制御ユニット３０１には、フォ
ントデータやページ記述言語のエミュレーションプログ
ラム等を供給する外部メモリ３１１を接続することもで
きる。

【００２６】レーザドライバ３０２は半導体レーザ３０
３を駆動するための回路であり、入力されたビデオ信号
に応じて半導体レーザ３０３から発射されるレーザ光３
０４をオン・オフ切替えする。レーザ光３０４は回転多
面鏡３０５で左右方向に振られてトナーカートリッジ３
０７内に設けられた静電ドラム３０６上を走査する。こ
れにより、静電ドラム３０６上には文字パターンの静電
潜像が形成される。この潜像は静電ドラム３０６周囲の
現像部によりトナー現像され、現像されたトナー像は記
録紙に転写される。この記録紙にはカットシートを用
い、カットシート記録紙はプリンタ１０２に装着した用
紙カセツト３０８に収納され、給紙ローラ３０９及び搬
送ローラ３１０により静電ドラム３０６に供給される。

【００２７】記録紙に転写されたトナー像は定着部３１
２により加熱されて記録紙上に定着され、その後、排出
部に排出される。

【００２８】消耗品であるトナーが無くなったり、ある
いは静電ドラムが損傷した場合には、利用者がプリンタ
筐体に設けられた不図示の開口部を開き、使用済みのカ
ートリッジ３０７を取り出してから新たなカートリッジ
と交換する。

【００２９】＜データベースの概要＞管理サーバ１０１
は、上記システムによって、製造販売した製品およびそ
のユーザや保証、製品を販売した機器販売店や保守サー
ビスを行う保守サービス店等を管理している。その管理
の基本となる情報は記憶手段としてのデータベースとし
て管理される。データベースとして管理すべき情報には
次の様なものがある。

【００３０】（１）製品（本体機器）情報データベース 本体機器に関する情報を集積したデータベースであり、
製品ごとに次の項目を有する。 ・製品名 … 製品の名称 ・製品コード … 製品を固有に識別するためのコード ・使用消耗品情報 … 製品の消耗品に関する情報であ
り、例えば消耗品に与えられた消耗品コード ・価格情報 … 製品の価格。

【００３１】（２）製品（消耗品）情報データベース 消耗品に関する情報を集積したデータベースであり、製
品ごとに次の項目を有する。 ・製品名 … 製品（消耗品）の名称 ・消耗品コード … 消耗品を識別するためのコード ・使用本体情報 … 消耗品を使用する本体製品に関す
る情報であり、例えば本体製品に与えられた製品コード ・保証有り価格情報 … 消耗品を本体製品の保証つき
で販売する価格 ・保証無し価格情報 … 消耗品を本体製品の保証なし
で販売する価格。

【００３２】（３）顧客情報データベース 顧客に関する情報を集積したデータベースであり、顧客
ごとに次の項目を有する。 ・ユーザＩＤ … 製品の購買者等、顧客に固有に与え
られたコード ・パスワード … ユーザ認証用のコード ・顧客情報 … 顧客の名称（社名、部門、担当者）、
住所、電話番号、ファクシミリ番号など ・電子メールアドレス … 顧客の電子メールアドレス ・購入製品コード … 顧客が購入した製品の製品コー
ド ・購入履歴 … 過去に購入した製品に関する履歴情報 ・保証契約履歴 … 過去に購入した製品の保証契約に
関する履歴情報 ・サービス履歴 … 過去に受けた保守サービスに関す
る履歴情報 ・支払い情報 … 購入した製品等に対する支払い情
報。

【００３３】（４）販売店データベース 販売代理店に関する情報を集積したデータベースであ
り、販売店ごとに次の項目を有する。 ・販売店ＩＤ … 機器メーカの販売代理店に固有に与
えられたコード ・パスワード … 販売店認証用のコード ・販売店情報 … 販売店の名称、法人コード、住所、
電話番号、ファクシミリ番号等 ・電子メールアドレス … 販売店の電子メールアドレ
ス ・ユーザＩＤ … 販売店の顧客のユーザＩＤ ・保守サービス可/不可フラグ … 販売店の保守サー
ビス能力に関する情報 ・販売履歴 … 過去に販売した製品に関する履歴情報 ・在庫情報 … 現在在庫している製品に関する情報 ・インセンティブ情報 … 製品を販売した販売店に対
して、その製品のための消耗品をメーカ側が販売した際
に与えられるインセンティブに関する情報。

【００３４】（５）サービス店情報データベース 保守サービスを提供するサービス店に関する情報を集積
したデータベースであり、サービス店ごとに次の項目を
有する。なお、サービス店情報は、サービス提供の便宜
から、複数の店舗を有するサービス店に関しては店舗ご
とに管理される。 ・サービス店ＩＤ … 保守サービスを提供するサービ
ス店に固有に与えられるコード ・パスワード … サービス店認証用のコード ・サービス店情報 … サービス店の名称、法人コー
ド、住所、電話番号、ファクシミリ番号等 ・電子メールアドレス … サービス店の電子メールア
ドレス ・ユーザＩＤ … サービス店の顧客のユーザＩＤ ・サービス履歴 … 過去に提供したサービスに関する
履歴情報 ・サービス費用情報 … 提供するサービスの料金に関
する情報。

【００３５】（６）機種別故障項目データベース 本体機器の故障に関する情報を集積したデータベースで
あり、製品ごとに次の項目を有する。 ・機種（製品名） … 製品名あるいは製品コード ・予想される故障項目 … 製品ごとに生じやすい故障
の内容。

【００３６】（７）サービス情報データベース サービスに関する情報を集積したデータベースであり、
サービスごとに次の項目を有する。 ・ユーザＩＤ … サービスを提供された顧客のユーザ
ＩＤ ・対応サービス店ＩＤ … サービスを提供したサービ
ス店のＩＤ ・故障内容情報 … 修理の場合には故障の内容に関す
る情報 ・サービス依頼情報登録日時 … サービス依頼を受け
た日時に関する情報 ・サービス実施予定日時 … 依頼に対して予定された
実施日時に関する情報 ・サービス実施日時 … 実際にサービスを実施した日
時に関する情報 ・サービス結果情報 … サービスの結果に関する情
報。

【００３７】（８）保守サービス費用データベース サービスに対する対価に関する情報を集積したデータベ
ースであり、故障の内容ごとに次の項目を有する。 ・故障内容 … サービスの対象となる故障の内容 ・標準修理時間 … 修理に要する標準的な時間 ・標準修理料金 … 修理に要する標準的な料金。

【００３８】（９）保証情報データベース 本体機器に対する保証に関する情報を集積したデータベ
ースであり、発生した保証ごとに次の項目を有する。 ・ユーザＩＤ … 製品のユーザのユーザＩＤ ・製品コード … 保証対象となっている製品の製品コ
ード ・消耗品コード … 本体製品の保証つきで販売された
消耗品の消耗品コード ・保証コード … 保証ごとに付された固有のコード ・保証開始日 … 保証が開始される日に関する情報 ・保証終了日 … 保証が終了した日（保証期間中は終
了予定日）に関する情報 ・消耗品購入履歴 … 過去に購入した消耗品に関する
履歴情報 ・サービス依頼履歴 … 過去に依頼された保守サービ
スに関する履歴情報。

【００３９】管理サーバ１０１は、このようなデータベ
ースを管理し、本体製品や消耗品の購入やサービスの提
供などのイベントが発生するごとに、データベースを参
照して適切な処理を行うとともに、必要に応じてデータ
ベースを更新する。次に、機器保証管理システム全体に
わたる動作を、発生したイベントごとに説明する。な
お、管理サーバ１０１による手順の詳細は全体にわたる
動作説明のあとでフローチャートを参照して説明する。

【００４０】＜本体製品販売時の処理＞図４は、ユーザ
が新規にプリンタなどの本体製品を購入した場合におけ
る機器保障管理システムの動作を示す図である。

【００４１】図４において、メーカから機器販売店への
機器卸４０１、ユーザから販売店への機器の発注４０２
および販売４０３は、取引の現状に即して行われ、本発
明にかかる機器保証管理システムは関与していない。こ
の後の説明においては、販売４０３後のメッセージは、
特にことわらない限り機器保証管理システム内で交換さ
れる。なお、図４におけるかっこ書きの数字は、画面等
の具体例を示す図との対応を示している。これは図５乃
至図９においても同様である。

【００４２】ユーザへの機器（本体製品）の販売が行わ
れると、販売店はメーカに対して、機器の販売を行った
旨を通知する。この通知は機器保証管理システムを介し
て行っても良いし、そうでなくとも良い。この通知を受
けたメーカは、管理サーバ１０１から販売店端末１０５
に対してユーザ登録画面４０４（図１３）を支給する。
このとき、販売店ＩＤが割り当てられていない販売店に
ついては、新たに販売店ＩＤを割り当ててそれを同時に
通知する。その際、管理サーバ１０１は販売店データベ
ースに新たな販売店に関する項目を追加する。

【００４３】画面の支給は、ＨＴＴＰに従ってＨＴＴＰ
サーバおよび該サーバにおけるディレクトリを特定する
ＵＲＬ(unified resource locators)を管理サーバ１０
１から端末に通知することで実現される。この通知はオ
ンラインで行うのが好適だがオフラインで行っても良
い。

【００４４】販売店では、その端末１０５により、販売
した機器に対応するＵＲＬをウエブクライアントを使用
して指定する。販売店に通知されるＵＲＬはユーザ登録
のための入り口を示すものであってもよいが、さらに機
器ごとのＵＲＬが割り当てられていることが望ましい。
それにより、管理サーバ１０１に置かれた機器ごとのユ
ーザ登録画面が指定したＵＲＬに応じて読み出され、販
売店端末１０５のディスプレイ画面上に表示される。図
１３はユーザ登録画面の一例を示す図である。図１３
は、必要な情報がすでに入力されている状態を示す。図
１３の画面で入力される情報は、ユーザに関しては、そ
の名称や電話番号等や機器の設置場といった顧客情報１
３０２、購入した本体装置（本例では電子写真プリン
タ）の名称と機番（一般的には機種ごとに決定されたシ
リアルナンバーであり、以降Ｓ／Ｎと略す）や、本体に
使用する消耗品（本例ではトナーカートリッジ）の名称
と番号等の機器情報１３０１である。また、機器販売店
に関しては、その名称や電話番号等の販売店情報１３０
３が入力される。さらに、機器販売店では、販売した機
器の保守サービスをその販売店で行うか、それとも他の
販売店や保守サービス店に依頼するかの選択情報１３０
４や、次回のカートリッジ販売時に、ユーザが保証付の
カートリッジを予定しているのか、それとも購入時に改
めて選択するのかの選択１３０６を入力させる。なお、
消耗品であるカートリッジの保証付と保証無しの販売価
格１３０５は、管理サーバ１０１の有する製品データベ
ースから得た値が記述されている。

【００４５】このように必要な入力が済んだなら、登録
ボタンを押すことで、入力された登録データ４０５が管
理サーバ１０１にネットワークを介して送信される。こ
の登録データには、図４の情報４０５ａに示すように、
図１３の画面で入力されたデータが含まれる。この登録
データを受けた管理サーバ１０１は、受信した登録デー
タを用いてデータベースを更新する。ユーザが新規であ
れば、顧客情報データベースに新たなユーザが登録され
る。また、新規に販売される本体製品には保証付のカー
トリッジが付属するために、機器登録の時点で新たな保
証が発生し、保証情報データベースにも新たなエントリ
が登録される。

【００４６】次に管理サーバ１０１は、新規販売された
機器の保守サービスを行う保守サービス店を決定する。
サービス店は、例えば登録データに含まれる機器の設置
場所とサービス実施店の選択情報１３０４や、別途管理
サーバ１０１が備えている地図データベース、サービス
店データベース等を参照し、設置場所へのアクセス容易
性等を考慮して決定される。決定されたサービス店は、
決定されたサービス店が製品の販売店と同一の場合には
その販売店へ、そうでない場合には決定されたサービス
店に電子メールのメッセージ４０６により通知される。
そのメッセージ４０６には、機器を使用するユーザを特
定するユーザＩＤや保証に対して一意に生成された保証
番号（保証コードとも呼ぶ）、製品機種名、保証対象の
本体機番、保証期間等の情報４０６ａが含まれる。図１
４はサービス店決定通知メールの一例を示す図である。
この電子メールは管理サーバ１０１に用意されたプログ
ラムにより自動的に作成され、送信される。電子メール
アドレスは、サービス店情報データベースから検索され
る。また、メールに含まれる定型的でない情報、例えば
ユーザＩＤなどは、データベースに登録された情報から
得られる。これは、この後の手順で送信される電子メー
ルの作成にあたっても同様である。

【００４７】以上のようにして新規製品販売に伴う所定
の手続きを完了し、管理サーバ１０１のデータベースが
更新されたならば、管理サーバ１０１は登録完了を知ら
せるメッセージ４０７を、電子メールによりユーザ端末
１０３に対して送信する。このメッセージ４０７には、
情報４０６ａに消耗品の発注や保守サービス依頼の連絡
先を加えた情報４０７ａが含まれる。図１５は保証登録
完了メールの一例を示す図である。

【００４８】以上の手順で、本体製品の新規販売に伴う
登録処理がすべて完了する。その後、メーカからユーザ
に対して保証書が送られる。保証書は管理サーバ１０１
に登録された各種登録データを利用して自動的に作成・
印刷されるものであると利便性の面からして好適であ
る。図１６は保証書の書式の一例を示す図である。な
お、保証書は書面を郵送するものであっても良いが、例
えば電子透かし等を施すことで改竄防止処理を施した画
像データとして、本機器保証システムを介して電子メー
ル等により送信することもできる。

【００４９】＜カートリッジ販売時の処理＞次に図５を
参照して、本体製品を購入したユーザに消耗品であるカ
ートリッジを販売する際の手順を説明する。図５は、ユ
ーザがトナーカートリッジ（などの消耗品を購入した場
合における機器保障管理システムの動作を示す図であ
る。

【００５０】図５において、ユーザが保証完了メール
（図１５）あるいは保証書（図１６）に記載されたカー
トリッジ発注用のＵＲＬ（図１６の例では"http://www.
otsu-corp.com/ABC1234456")にユーザ端末１０３にイン
ストールされたウエブクライアントからアクセスする
と、そのＵＲＬで指定される場所におかれたユーザ認証
用の画面データ５０１がユーザ端末１０３にメッセージ
として渡され、表示される。なお、このＵＲＬは該画面
データ５０１が管理サーバ１０１に置かれた場所を示
す。本例ではユーザに連絡先として通知するＵＲＬの末
尾にユーザＩＤが付加され、それによりユーザの識別が
されているが、ユーザＩＤを認証に用いる場合には、ユ
ーザ名称など、認証用のコード以外の文字列を付加する
ようにしてもよい。

【００５１】図１７はユーザ認証画面の一例を示す図で
ある。この画面が表示されたなら、ユーザは、自分自身
に割り当てられて上述した保証書等で通知されたユーザ
ＩＤを入力し、認証ボタン１７０１を押す。この動作に
よって、入力されたユーザＩＤ５０２がユーザ端末１０
３から管理サーバ１０１にネットワークを介して送信さ
れる。

【００５２】管理サーバ１０１は、受信したユーザＩＤ
を、ユーザにより最初に指定されたＵＲＬに対応する、
顧客情報データベースに登録されたユーザＩＤと照合す
る。両者が一致しなければ、認証が失敗した旨を示すエ
ラー画面５０３をユーザ端末１０３に送信する。図１８
は認証失敗時のエラー画面の一例を示す図である。一
方、ユーザ認証が成功した場合には、ユーザ端末１０３
に対して、ユーザがカートリッジの発注あるいは修理を
依頼するための発注・修理依頼選択画面５０４を送信・
支給する。図１９は、ユーザ端末１０３に表示される発
注・修理依頼選択画面の一例を示す図である。

【００５３】ユーザは、図１９の画面に表示された「ト
ナーカットリッジ発注」か「修理依頼」か、いずれか所
望する方を選択する。選択肢はいわゆるプルダウンメニ
ュー表示され、メニュー表示されるなかから一つが選択
できる。図１９は「トナーカットリッジ発注」と「修理
依頼」の２項目がプルダウンメニューとして表示されて
いる様子を示す。ユーザがその選択後、決定ボタンを押
すと、選択された項目が選択データ５０５として管理サ
ーバ１０１に送信される。

【００５４】選択データを受信した管理サーバ１０１
は、ユーザ端末１０３に対して、選択内容に応じた画面
５０６を送信する。ここではトナーカートリッジの発注
のための画面を用いて説明を進める。なお、修理依頼が
選択されていた場合については後述する。カートリッジ
発注が選択された場合、管理サーバ１０１は、認証され
たユーザが使用される機器についての保証が現在有効で
あれば、顧客情報データベースを参照して、そのユーザ
が使用する機器に用いるために購入予定のカートリッジ
が保証付であるか否かを判定する。この判定は、図１３
に示したユーザ登録画面における次回購入カートリッジ
選択１３０６における入力データを利用する。

【００５５】機器の新規登録時に、ユーザが次回も「保
証付」カートリッジを購入予定である旨の情報が入力さ
れていれば、管理サーバ１０１は保証付カートリッジ発
注画面をユーザ端末１０３に送信する。図２０は、保証
付カートリッジ発注画面の一例を示す図である。画面に
は、ユーザＩＤほか、そのユーザが購入した本体装置の
機種名や機番（Ｓ／Ｎ）、カートリッジの単価等が、管
理サーバ１０１によりあらかじめ書き込まれている。ユ
ーザは、その画面上で、購入数量２００１を入力し、発
注ボタン２００２を押下する。なお、好適には、入力さ
れた購入数量に応じた金額やそれに税金を加算した合計
支払い金額を計算して画面上に表示するためのスクリプ
トを発注画面とともに送信しておくことで、管理サーバ
１０１に負荷をかけることなく、それらの値をユーザに
通知することで、ユーザに視覚的に金銭情報や個数情報
を確認させることができる。発注ボタンが押されると、
入力された購入数量を含む発注データ５０６が管理サー
バ１０１に送信される。

【００５６】また、機器の新規登録時に、ユーザが次回
の以降のカートリッジは「購入時選択」の予定である旨
の情報が入力されていれば、管理サーバ１０１は、カー
トリッジ種別の選択メニュー付のカートリッジ選択発注
画面をユーザ端末１０３に送信する。図２１はカートリ
ッジ選択発注画面の一例を示す図である。図２１の画面
には、図２０の画面に加えて、発注するカートリッジの
種別を選択するためのプルダウンメニュー２１０１が表
示される。ただし、カートリッジの単価は保証の有無に
応じて異なるために、カートリッジの種別選択後に初め
て単価が表示される。この画面でも、数量入力後に発注
ボタンが押されることで、選択されたカートリッジ種別
と数量とを含む発注データ５０６が管理サーバ１０１に
送信される。

【００５７】また、すでに保証期間が切れているなど、
保証が有効でない場合には、管理サーバ１０１は保証無
しカートリッジの発注画面をユーザ端末１０３に送信す
る。図２２は保証無しカートリッジ発注画面の一例を示
す図である。表示される内容は図２０と同様であるが、
保証付カートリッジとは単価が異なるために、単価の欄
には種別に応じた価格が表示されている。この場合に
も、発注ボタンが押されると、入力された数量を含む発
注データ５０６が管理サーバ１０１に送信される。

【００５８】ユーザからカートリッジの発注があった場
合、管理サーバ１０１は、カートリッジ種別に応じて２
通りの処理を行う。受注したカートリッジが保証無しカ
ートリッジの場合には、顧客情報データベースや保証情
報データベース等、必要なデータの更新を行う。例え
ば、保証が有効であった機器に対して保証無しカートリ
ッジが発注された場合は、保証のステータス情報を"保
証無し"に切り換える。そして、図５の符号"Ａ"からの
処理が遂行される。すなわち、商品の発送５０９が手配
されて、実際に配送が行われる。もちろん、機器に対す
る保証書は付属しない。

【００５９】他方、受注したカートリッジが保証付カー
トリッジであれば、管理サーバ１０１は、顧客情報デー
タベースや保証情報データベースを受注内容に応じて更
新する。例えば、顧客情報データベースにおける購入履
歴や保証契約履歴、保証情報データベースの保証終了日
や消耗品購入履歴など、新たな受注内容に応じた保証内
容や保証期間に基づいて、保証に関する情報５０７ａが
更新される。また、販売店情報データベースのインセン
ティブ情報等も更新される。

【００６０】保証の更新処理が終了すると、管理サーバ
１０１はその旨を示す登録完了メメッセージ５０８を電
子メールでユーザ端末１０３に送信する。図２３は登録
完了メッセージ５０８の内容の一例を示す図である。そ
のメッセージには、保証期間と保証対象を明示するため
の情報として、ユーザＩＤ，保証対象の機種名，機番
（Ｓ／Ｎ），保証を特定するための保証番号が含まれ
る。この後、保証の登録済みカートリッジ及び印刷され
た保証書をユーザの元への配送５０９が行われる。な
お、上述した通り、保証書は画像データ等で代用可能で
あれば、必ずしも必要としない。

【００６１】消耗品であるカートリッジが販売される
と、そのカートリッジが使用される本体製品を販売した
販売店に対して、メーカからインセンティブが与えられ
る。このインセンティブは、本体製品の販売促進のため
に販売店に与えられる特典であり、上記に示した発注シ
ステムを利用して販売したカートリッジ価格のうち一定
割合の金銭などである。そのため、管理サーバ１０１
は、一定期間に販売されたカートリッジについて、それ
が使用される本体製品を販売した各販売店に対して、イ
ンセンティブ情報通知メール５１０を送信する。図２４
は、インセンティブ情報通知メールの内容の一例を示す
図である。そのメッセージには、インセンティブ集計の
対象となる期間と、与えられる特典の内容、すなわちイ
ンセンティブ内容が金銭賞与であればその金額が含まれ
ている。さらに、販売店からその内容の詳細、例えばイ
ンセンティブの対象となる発注を行ったユーザに関する
情報や発注個数など、今後の営業活動に有益となるよう
な情報を参照するためのＵＲＬも含まれている。このＵ
ＲＬで特定される場所（ディレクトリ）は管理サーバ１
０１内にあり、管理サーバ１０１が、インセンティブの
発生に応じて、データベースの内容を参照して用意して
おく。

【００６２】以上のようにして、本体製品とともにカー
トリッジが販売され、またその販売後に、本体製品に使
用されるカートリッジの受注−販売手順が遂行される。
このため、ユーザは消耗品を発注する際に保証の付与を
選択可能となるので、保証の選択に対して柔軟性を持た
せることができるため、多種多様なユーザのニーズに応
えることができる。

【００６３】また、消耗品と消耗品を使用する機器に対
する保証を一体にしたことにより、消耗品を使用する機
器の管理、さらには該機器を使用するユーザに関する情
報の管理を容易かつ継続的に行うことが可能となる。そ
れによって機器メーカの開発・生産活動や販売店の営業
活動に有益な情報を管理・蓄積することができる。

【００６４】また、消耗品であるカートリッジにそれを
使用する本体に対する保証をつけて販売するという本実
施形態のシステムにより、稼働率が高く、保守サービス
提供の頻度も高い製品に対しては保証の対価も高くな
り、逆に稼働率が低く、保守サービスの頻度が低い製品
に対しては保証の対価が安価に設定されることになる。
すなわち、継続的な保守契約を伴わない、いわゆる売り
切り販売される本体製品や消耗品についても、それらに
対する保守サービスの頻度に対応した適正料金の有償保
証を、消耗品の販売という従来通りの行為を通じて提供
することができる。さらに、保証期間の限度を通常考え
得るカートリッジの使用期間（本例では１年間）に設定
しておくことで、故障発生頻度や製品寿命等を参酌した
場合に必要以上の長期間にわたる保証を免れることがで
きる。即ち、長期間に渡る不要な保証によって発生して
いた高額の保証費用を低減できるメリットがユーザに対
して生じることになる。

【００６５】また、この手順により、管理サーバ１０１
は、受注したカートリッジが、本体機器の保証付のもの
であれば保証に関する情報を更新し、保守サービスの発
生や次回保証の更新などに備えることができる。加え
て、有償保証の処理を行うためのシステムを別途用意す
る必要がない。また、消耗品と製品保証とが同時に販売
されるために、それらを個別に販売する場合に比べて情
報管理を容易にできる。また、保証の提供と消耗品の提
供というそれぞれの販売チャネルを一本化できるため無
駄を排除でき、それに伴ってコストを引き下げる効果が
生じる。

【００６６】一方、ユーザは、機器を利用していく上で
必要であるカートリッジ購入時に、特別な手続き無しで
本体製品の保証を継続することができる。消耗品は本体
製品を使用する限り購入するものであるため、保証の継
続手続きを怠ったまま放置するといった、ユーザの過誤
による保証切れを防止することができる。また、ユーザ
に対してはカートリッジ発注時に定期的かつ短いスパン
で保証を見直すことができ、長期に渡る保証契約に伴う
高額な保証費用の支払いを免れることができる。

【００６７】＜保守サービス実施時の手順＞次に図６お
よび図７を参照して、装置の保守サービス時における依
頼から実施、料金の支払いまでにわたる保守サービスの
手順を説明する。図６および図７は、ユーザがメーカに
対して修理等の保守サービスを依頼する時点から開始さ
れる機器保証システムによる動作手順を示す図である。

【００６８】図６において、機器の修理や点検を依頼す
るユーザは、装置購入時に通知された図１５のメッセー
ジや図１６の保証書に記載されたカートリッジ発注兼修
理受付ＵＲＬを、ユーザ端末１０３のウエブクライアン
トから指定する。それに対して管理サーバ１０１は、指
定されたＵＲＬの画面をユーザ端末１０３に送信し、な
お、このＵＲＬに対応する画面としては認証画面が適当
である。この認証画面データ６０１から発注・修理選択
画面データ６０４の送信までは、図５で説明したカート
リッジ購入時の手順と同様である。

【００６９】ここで発注・修理選択画面６０４を受信し
たユーザ端末１０３には、図１９の画面が表示される。
修理依頼時には、ユーザはメニューから「修理依頼」を
選択し、決定ボタンを押す。これに応じて、ユーザ端末
１０３から管理サーバ１０１に対して、修理選択データ
６０５が送信される。

【００７０】この修理選択データを受信した管理サーバ
１０１は、保証番号確認画面データをユーザ端末１０３
に送信する。図２５は、その保証番号確認画面の一例を
示す図である。ただし、保証番号確認画面は、図２５の
２点鎖線より上の画面２５ａとなる。すなわち、この時
点では、ユーザ端末１０３には、図２５の下半分の画面
２５ｂは表示されない。なお、これらを全くの別画面と
しても良いことは言うまでもない。

【００７１】また、図２５はユーザが必要な入力を行っ
た状態を示しており、保証番号（保証Ｎｏ．）入力ボッ
クス２５０１および本体機番（Ｓ／Ｎ）入力ボックス２
５０２の内容は最初に表示された状態では空欄となって
いる。ユーザはこれら空欄を適当な内容で埋めた後に確
認ボタンを押す。この結果、保証番号及び本体機番デー
タ６０７が、管理サーバ１０１に送信される。

【００７２】管理サーバ１０１は、保証番号及び本体機
番データ６０７を受信すると、保証情報データベースを
参照して、その保証番号と本体機番がデータベースに登
録されているか、また、先に入力したユーザＩＤに正し
く対応しているかを判定する。これらが正しくなけれ
ば、入力された保証番号や本体機番に誤りがあると判定
して、エラー画面をユーザ端末に送って表示させ、再度
の入力を促す。図２６はエラー画面の一例を示す図であ
る。図２６には記載されていないが、この画面にも確認
ボタンを配置し、それが押されたなら改めて保証番号確
認画面データをユーザ端末１０３に表示させても良い。

【００７３】また入力された本体機器を特定する機番が
認証された場合には、該機器の保証が有効か否か、保証
情報データベースの保証終了日等を参照して判定する。
保証期間がすでに経過しており、保証が継続していなけ
れば、保証切れ画面データをユーザ端末に送信して保証
切れ画面を表示させる。図２７は保証切れ画面の一例を
示す図である。ユーザは保証が切れていることを確認し
た上で、修理を依頼するか否か決定できる。修理を依頼
しない場合には「終了」ボタンを押すことで、修理依頼
の手順は中断する。一方、修理を依頼する場合には、画
面上に指定された「こちら」部分を押す。それにより、
ユーザが保証切れを確認した上で修理依頼する旨を示す
データが管理サーバ１０１に送信される。

【００７４】保証番号及び本体機番データ６０７が認証
され、かつ保証が現在も有効であることが確認された場
合、あるいは、保証切れを確認した上で修理依頼する旨
のデータを受信した場合には、管理サーバ１０１は、サ
ービス依頼画面データ６０８をユーザ端末１０３に送信
し、表示させる。図２５の下半分の画面２５ｂがサービ
ス依頼画面である。このとき、入力済みの保証番号確認
画面２５ａも表示されており、ユーザ端末１０３の画面
上には図２５全体の画面が表示される。もちろん、２５
aと２５ｂを別の画面としても良い。 サービス依頼画
面２５ｂには、製品の故障内容をユーザが特定するため
のチェックボックス２５０３および文字入力ボックス２
５０４が配置されている。ここで、チェックボックス２
５０３にリスト表示されている故障内容は、管理サーバ
１０１が機種別故障項目データベースから検索した、修
理依頼された製品について予想される故障項目の内容で
ある。機種別故障項目データベースは、例えば開発の段
階で予想された、又は統計によって得られた故障情報な
どを元に、機種ごとに発生頻度が高い故障をピックアッ
プして登録しているものである。また、過去の修理依頼
などの情報に基づいて発生頻度を記録し、発生しやすい
故障を既に登録されている情報に対して随時更新するこ
とで、現状に即したデータベースとすることができる。

【００７５】さて、ユーザはこの画面上に表示された故
障の候補の内から該当する故障内容をチェックするか、
あるいは、文字入力ボックス２５０４に故障内容を記述
して、送信ボタンを押す。それにより、サービス依頼デ
ータ６０９が管理サーバ１０１に送信される。なお、サ
ービス依頼画面２５ｂ（保証番号確認画面２５ａも含
む）は、この後、故障の内容を表示するために繰り返し
表示される画面であるため、この画面のデータは、サー
ビス情報データベースの故障内容情報などとして、まと
めて何らかの記録媒体を利用して保存しておいても良
い。

【００７６】サービス依頼データ６０９を受信した管理
サーバ１０１は、サービス依頼データに含まれる故障内
容により、データベースを更新する。更新の対象は、例
えば、保証情報データベースのサービス依頼履歴、サー
ビス情報データベースのサービス依頼情報登録日時など
である。必要なデータベースの更新処理の後、サービス
情報データベースから、修理依頼したユーザに対応する
サービス実施店にあてて保守サービス対応連絡メール７
０１を送信する。図７においては、メーカから機器販売
店およびサービス店に対して送信されているかのように
記載されているが、これは、サービス実施店がこのいず
れかであることを意味しており、メールはサービス実施
店にしか送信されない。図２８は保守サービス対応ＵＲ
Ｌ連絡メール７０１の一例を示す図である。ここに示さ
れたＵＲＬにより指定される場所は管理サーバ１０１に
置かれている。

【００７７】このメール７０１を受信したサービス実施
店では、その端末（販売店端末１０５あるいはサービス
店端末１０４）のウエブクライアントにより、メールで
通知されたＵＲＬを指定する。管理サーバ１０１は、保
守サービス対応画面データ７０２をＵＲＬを指定した端
末に送信する。図２９は、保守サービス対応画面の一例
を示す図である。保守サービス対応画面の内容は、図２
５に示す修理依頼画面にユーザが入力したものそのもの
を含んでおり、それに加えて、サービス店で保守サービ
スが可能な時間を入力する入力欄２９０１も含まれる。
この保守サービス可能時間が入力されて「送信」ボタン
が押されると、サービス店の端末１０４あるいは１０５
は、管理サーバ１０１に対して訪問日時データ７０３ａ
を含むサービス受諾データを送信する。

【００７８】管理サーバ１０１は、訪問日時データ７０
３ａを受信すると、サービスを実施する日時を決定し、
それによりデータベースを更新する。サービス実施日時
は、ユーザの都合等もあるため、図２５の修理依頼画面
でユーザに希望日時を入力させても良い。その場合、サ
ービス店では、ユーザの希望を参酌してサービス可能日
時を入力できる。この時点では、例えば、サービス情報
データベースのサービス実施予定日時や対応サービス店
などが更新される。

【００７９】こうしてサービス実施日時が決定すると、
サービス受諾メール７０４が管理サーバ１０１からユー
ザ端末１０３に送信される。図３０はサービス受諾メー
ルの一例を示す図である。サービス受諾メールには、サ
ービスの対象となる製品名やその機番、保証が付いてい
る場合には保証番号、そしてサービス実施予定日時の情
報７０４ａが含まれる。

【００８０】そして、管理サーバ１０１はサービス実施
店に対して、サービス終了後のレポートを記入するため
の画面に対応したＵＲＬを、サービスレポートＵＲＬ連
絡メール７０５により通知する。図３１はサービスレポ
ートＵＲＬ連絡メール７０５の一例を示す図である。な
お、サービス受諾メール７０４とサービスレポートＵＲ
Ｌ連絡メール７０５の順序は前後しても良い。

【００８１】この後、サービス実施店からユーザのもと
に技術者が派遣されて、保守サービス７０６が実施され
る。もちろん、この手続きは機器保証管理システムによ
るものではない。サービスが終了すると、サービス実施
店端末から、サービスレポートＵＲＬ連絡メール７０５
で通知されたＵＲＬが指定され、そのＵＲＬで特定され
るサービスレポート記入画面データ７０７が管理サーバ
１０１からサービス実施店の端末に送信される。図３２
はサービスレポート記入画面の一例を示す図である。そ
の上半分には、図２５に示す修理依頼画面に対してユー
ザが入力した故障内容３２０１そのものが表示される。
この部分は、故障内容データが保存されている場合に
は、ユーザＩＤや製品の機番から検索できる。

【００８２】その故障内容の下部には、技術者が施した
処理を入力させるためのチェックボックスと文字入力ボ
ックスが表示される。処置方法は、故障内容に該当する
処置方法をいくつか表示して、チェックボックスを付す
る。故障内容と処置方法とを含むデータベースについて
はこれまでに示していないが、例えば機種別故障項目デ
ータベースの一項目として含ませても良い。サービス実
施店が行った処置が入力されて送信ボタンが押される
と、その端末から管理サーバ１０１に対してサービスレ
ポートデータ７０７ａが送信される。

【００８３】サービスレポートを受診した管理サーバ１
０１は、そのレポートに従って、サービス店情報データ
ベースのサービス履歴やサービス情報データベースのサ
ービス実施日時などを更新する。処置の内容は、サービ
ス情報データベースのサービス結果情報として蓄積され
る。

【００８４】また、管理サーバ１０１は、サービス終了
後に、サービス店が提出したサービスレポートデータに
応じて、保守サービス費用データベースの故障内容、標
準修理料金等を参照して代金を計算する。計算した代金
はサービス店情報データベースのサービス費用情報とし
て格納される。

【００８５】以上のようにして、修理依頼から修理の実
施までの手順が完了する。これにより、ユーザからのサ
ービスの依頼時に故障情報を生成するために、サービス
店は故障の特定をするための作業が軽減されて利便性が
向上する。同様に、ユーザも予め提示される予想される
故障情報の中から該当のものを選択するだけであるの
で、利便性が向上する。また、これにより、ユーザは的
確な故障内容をサービスの依頼先に通知できるため、サ
ービスの迅速化およびサービスコストの低減が可能とな
る。

【００８６】また、ユーザからの修理依頼からサービス
実施店までの故障内容の通報や修理作業予定の作成、作
業予定のユーザへの通知までが一連の処理として本実施
形態の機器保証管理システムにより行われるため、連絡
漏れや遅延による保守サービスの不実施やトラブルを防
止することができる。

【００８７】また、ユーザとメーカ、サービス実施店の
間の連絡が、管理サーバ１０１から支給される画面への
書き込みや電子メールといった電子文書で行われ、それ
らの記載内容はデータベースとして管理されるために、
改めて伝票入力するといった作業をなくすことができる
とともに、後日に連絡内容を確認することも可能とな
る。

【００８８】また、顧客情報やサービス情報を一元的に
管理できるために、営業活動や製品開発へ情報を利用し
やすくなる。

【００８９】＜サービス代金の精算手順＞サービスが実
施された後、修理に要した費用が精算される。図８は、
サービス代金の精算手順を示す図である。

【００９０】図８において、サービス代金精算の手順
は、提供したサービスが保証付の製品に対するものであ
るか否か、即ち、保守サービスを行った製品の保証が有
効か無効かに応じて異なる。保証が有効である機器に対
するサービスであった場合、その費用は保守サービスを
保証しているメーカが負担することになる。そのため、
保証が有効である機器に対してサービスを行った場合に
は、管理サーバ１０１は、サービス店情報データベース
のサービス費用情報を参照して、サービス実施店の端末
に対して、サービス代金支払い通知メール８０１を送信
する。図３６は、保守代金支払いメール８０１の一例を
示す図である。金額と支払期日、支払い内容のサマリに
アクセスするためのＵＲＬが記述されている。実際の支
払いは本例では金融機関を利用した振り込みによって行
われる。

【００９１】一方、保証が有効でない機器に対して行わ
れた保守サービスの場合は、ユーザがその費用を支払う
ことになる。その場合には、メーカが集金の代行をし、
集金後にサービスを実施した店に代金を支払う。そのた
め、管理サーバ１０１は、サービス店情報データベース
のサービス費用情報およびサービス情報データベースの
ユーザＩＤ等を参照して、ユーザに対して保守サービス
費用請求メール８０２を送信する。図３５は保守サービ
ス費用請求メール８０２の一例を示す図である。内容は
通常の請求書とほぼ同様である。

【００９２】この請求に対してユーザから支払い８０３
があると、サービス代金支払いメール８０４が管理サー
バ１０１からサービス実施店の端末に対して送信され
る。なお、本例では、支払いは機器保証管理システムで
は行われないものとしているが、クレジットカードなど
の支払い代行による電子商取引を利用することで、ユー
ザ端末からメーカの管理サーバ１０１に対する手続きと
して、本機器保証管理システム上で行うことができる。
なお、サービス実施店に対するサービス代金支払いメー
ル８０４の内容は、図３６と同様である。

【００９３】このようにして代金支払い処理を行うこと
で、サービス時におけるサービス代金の決済業務を簡素
化することができる。また、請求されたユーザや支払い
を受けたサービス店がその明細を望んだ場合には、管理
サーバ１０１において明細を記したサマリにアクセスす
るためのＵＲＬを、支払い通知或いは請求書とともに知
らせてあるため、ユーザ端末或いはサービス店端末か
ら、そのＵＲＬを参照して管理サーバ１０１におかれた
明細を参照することができる。なお明細は、請求書或い
は支払い通知書作成と同時に、保守サービス費用データ
ベースの故障内容、標準修理料金等を参照して作成さ
れ、格納される。

【００９４】＜保証期間切れ通知手順＞前述したように
保証には一定の期限が設けられているのが一般的であ
る。そのため、本機器保証管理システムは、提供してい
る保証それぞれについて期限管理を行っている。そし
て、保証の有効期限が切れる前に、その旨をユーザに通
知して保証の更新の機会を提供している。図９は、保証
期限切れ通知をユーザに対して発行する手順を示す図で
ある。

【００９５】管理サーバ１０１は、例えば日次処理とし
て、保証情報データベースに登録されたすべてのエント
リについて保証終了日時項目を調べ、保証終了日時が現
在日時から２週間後となるものがあれば、保証切れ警告
メール９０１をユーザ端末１０３にあてて送信する。一
度メールを発行したならその旨を示すフラグ等をセット
して、すでに保証切れ警告メールの送信処理を終えてい
ることを該当する各エントリについて記録しておく。図
３３は保証切れ警告メールの一例を示す図である。メー
ルには、保証対象の製品の機種名や機番（シリアルナン
バー（Ｓ／Ｎ））、保証番号等、保証やその対象となる
製品を特定するための情報と、保証登録日が示される。
本例では保証は１年間であることから、保証登録日（保
証の初日）から１年後の日が保証切れの日となる。もち
ろん、保証登録日の代わりに保証期限日を表示しても良
いし、共に表示しても良い。さらに、メールには、図１
７に示す認証画面からカートリッジの購入のための図５
の手順へ至る入り口となるＵＲＬが表示されている。ユ
ーザは、ユーザ端末１０３からこのＵＲＬにアクセスし
てカートリッジを購入することで、保証が有効である期
限が切れる前に、保証の更新をすることができる。

【００９６】保証の更新がされないままに保証期間が経
過すると、今度は保証切れを通知する保証期間経過メー
ル９０２を、管理サーバ１０１はユーザ端末１０３に対
して送信する。図３４は保証期間経過メールの一例を示
す図である。このメールには、保証対象の製品の機種名
や機番（シリアルナンバー（Ｓ／Ｎ））、保証番号等、
保証やその対象となる製品を特定するための情報と、保
証登録日、保証切れを知らせるメッセージが表示され
る。

【００９７】このようにして、管理サーバ１０１が管理
する保証期間に関する情報（保証終了日）に基づいて、
ユーザに保証切れ警告を通知し、更新する機会を与える
ことができる。

【００９８】なお、保証期間が経過して保証が無効とな
った場合でも、上述したカートリッジ発注及び保守サー
ビス依頼を行うことが可能である。その場合、既にユー
ザに対して付与されているユーザＩＤを図１７に示した
画面に入力することでユーザの認証を行い、図１９に示
した画面でトナーカートリッジ発注か保守サービス（修
理）依頼のいずれかを選択すればよい。カートリッジ発
注を選択した場合は、図２２に示した保証無しカートリ
ッジ発注画面がユーザ端末に表示され、必要情報を入力
することでカートリッジの発注が可能となる。また、保
守サービス（修理）依頼を選択した場合は、図２５aで
示した認証画面が提供される。ここで本体機器の機番
（Ｓ／Ｎ）と保証コード（保証Ｎｏ．）を入力して認証
を行う。なお、保証コードは既に無効となったコードを
入力することになるが、保証が無効となった以降は特定
のコードを示して入力させるように対応しても良い。

【００９９】以上、保証期限切れ通知手順について説明
したが、機器の保証期限日に至っても前回購入したカー
トリッジがまだ継続使用されている場合に新たなカート
リッジを購入しなければ、保証が無効となる本形態は、
ユーザに対して利便性の低いものであるように一見思わ
れる。しかし、製品の使用頻度が所定のレベルよりも低
いのであれば、保証が付与されたカートリッジを購入し
て保守サービスを無償とするよりも、保証が付与されて
いないが価格の安い保証無しカートリッジを購入し、万
が一保守が必要な場合は、そのつど有料で修理した方が
ユーザにとっても負担が軽減されることになる。利用す
る以前から長期の保証契約を高額の保証代金を支払って
結ぶよりも、機器を利用することによって認識できる実
際の使用状況に応じて保証の有無を選択できる方がより
ユーザの利便性を向上させることができる。

【０１００】＜管理サーバ１０１の動作手順＞以上、機
器保証管理システム全体としての動作を説明してきた
が、ここで、このシステムの中心となる管理サーバ１０
１の動作についてあらためて説明する。それというの
は、ユーザ端末１０３や販売店端末１０５、サービス店
端末１０４については、市販されているパーソナルコン
ピュータに、これも市販や無償配布されているウエブブ
ラウザプログラム、メールプログラム等をインストール
することで実現できるが、管理サーバ１０１は、このシ
ステムのために特に設計されたプログラムを実行してお
り、それにより本実施形態の機器保証管理システムが実
現されるためである。このプログラムは、市販あるいは
無償提供のウエブサーバプログラムによりネットワーク
に対してウエブページ（前述したＵＲＬで指定される各
表示画面である）を提供する機能やその中のフォームに
記入されたデータを受け取る機能、市販のデータベース
管理プログラムによるデータベースの定義，参照，更新
機能等を利用することができる。そのため、フローチャ
ートの説明においては、それらの手順には深く言及しな
い。

【０１０１】（新規登録）図１０は、本体装置の新規登
録時の手順を示すフローチャートである。この手順は図
４において説明されている。図１０の手順は、管理サー
バ１０１から販売店端末１０４に対してユーザ登録画面
を支給した時点から開始される。なお、以降の処理は管
理サーバ１０１が行う処理である。

【０１０２】まず、販売店端末１０４からユーザ登録画
面（図１３）を利用して送信された製品機番（本体機器
Ｓ／Ｎ），カートリッジ番号，設置場所等のユーザ情報
を受信する（ステップＳ１００１）。受信した製品機番
から、その製品が新規登録される機器であるか判定し
（ステップＳ１００２）、そうでなければ誤った登録と
してステップＳ１００１に戻り、再送信を待つ。このと
き再送信を促すメッセージを販売店端末１０４に送信し
ても良い。

【０１０３】新規登録のユーザであると判定されれば、
ユーザＩＤ、保証対象機種名および機番、保証開始日、
販売店名、設定場所、保証番号等を含む新規ユーザ情報
を生成し、それら項目を含むデータベース、例えば顧客
情報データベースや保証情報データベース、販売店デー
タベースなどにあらたなエントリを登録する（ステップ
Ｓ１００３）。

【０１０４】そして、ユーザ登録情報に含まれるサービ
ス実施店の指定を判定し（ステップＳ１００４）、「自
社」がチェックされていれば製品を販売した販売店をサ
ービス実施店として決定し（ステップＳ１００５）、
「乙社委託」がチェックされていれば、あらかじめ登録
されている保守サービス店のなかから、機器設置場所と
サービス店との距離などを元に適当な保守サービス店を
選択する（ステップＳ１００６）。決定されたサービス
店についても、サービス店データベースや顧客情報デー
タベースに登録する。そして決定されたサービス実施店
の端末に対してサービス店決定通知（図１４）を送信し
（ステップＳ１００７）、ユーザ端末１０３に対して登
録完了メール（図１５）を送信する（ステップＳ１００
８）。なお、このサービス店の決定やメール送信の順序
は、図１４，図１５に示した通知を発行できるような順
序であれば図１０の順序に限らない。

【０１０５】（カートリッジ受注）図１１は、カートリ
ッジの発注を受けた際の管理サーバ１０１で処理する手
順を示すフローチャートである。ユーザがあらかじめ通
知されたＵＲＬに対応する入力画面にアクセスし、図１
７の画面においてユーザＩＤを入力して認証を求めた時
点から図１１の処理は開始されている。

【０１０６】まず、ユーザ端末１０３から送信されたユ
ーザＩＤを受信し（ステップＳ１１０１）、それが正し
いユーザＩＤであるか判定する（ステップＳ１１０
２）。正しくなければ図１８の画面表示データをユーザ
端末１０３に送信して再度の送信を待つ。一方、正しい
場合、すなわち認証が行われた場合には、図１９の画面
データをユーザ端末１０３に送信してカートリッジの発
注か修理の依頼かを選択させる。その応答があれば内容
を判定し（ステップＳ１１０３）、カートリッジ発注で
なければ図１２のステップＳ１２０１に分岐する。カー
トリッジ発注ならばステップＳ１１０４に分岐する。ス
テップＳ１１０４から先の処理がカートリッジ発注に固
有の処理である。

【０１０７】発注があった場合、発注が保証付カートリ
ッジであるか保証無しカートリッジであるか判定する
（ステップＳ１１０４）。この結果に応じて保証情報デ
ータベースの内容を更新する。その際に、保証付カート
リッジの発注であれば、保証情報データベースの保証終
了日等を保証継続情報に更新し（ステップＳ１１０
５）、保証無しカートリッジの発注であれば、保証停止
情報に更新する（ステップＳ１１１０）。保証情報の更
新は保証情報データベースにとどまらず、顧客情報デー
タベースの保証契約履歴の更新なども行う。なお保証停
止情報への更新は、例えば保証情報データベースの保証
終了日に保証停止の確定を示す識別子等を付すことで実
現できる。

【０１０８】保証が継続される場合には、保証書記載情
報を、ステップＳ１１０５で更新された保証情報に基づ
いて生成する（ステップＳ１１０６）。そして、ユーザ
端末１０３へと保証の更新が完了した旨を示す登録完了
メール（図２３）を送信する（ステップＳ１１０７）。

【０１０９】保証に関する処理が終了したなら、販売店
に支払うインセンティブをカートリッジ価格などに応じ
て決定して、販売店データベースのインセンティブ情報
を更新する（ステップＳ１１０８）。インセンティブ情
報には単に金額を積算するだけではなく、明細書作成の
ために明細を記録しておく。

【０１１０】最後に、インセンティブ情報に基づいて販
売店端末１０４へインセンティブ情報（図２４）を送信
する（ステップＳ１１０９）。なお、ステップＳ１１０
９の処理は、本実施形態では月次処理としているため、
独立したひとつのプログラムとしてあることが望まし
い。

【０１１１】（サービス依頼受け）図１２Ａ及び図１２
Ｂは、サービス依頼を受けた際の管理サーバ１０１によ
る処理手順を示すフローチャートである。ステップＳ１
２０１以前のステップは図１１と共通（別々に記載して
いるが本来ひとつのもの）であるため、説明を省略す
る。

【０１１２】ユーザからのサービス依頼を受信すると、
管理サーバ１０１はユーザ端末１０３に対して図２５の
修理依頼画面データを送信して、製品機番や保証番号等
を入力させ、修理依頼画面で入力され送信されたそれら
の情報を受信する（ステップＳ１２０１）。次に受信し
た製品機番（機器Ｓ／Ｎ）が正しいか判定する（ステッ
プＳ１２０２）。製品機番が正しくなければ図２６の画
面データをユーザ端末１０３に送信してエラーを通知す
るとともに、再送信を促す。

【０１１３】一方、受信した情報が正しければ、続いて
その製品の保証は有効であるか判定する（ステップＳ１
２０３）。保証が有効でないと判定されれば、その旨通
知する画面データ（図２７）をユーザ端末１０３に送信
し、依頼がなければサービス依頼受け処理を終了する。

【０１１４】保証が有効の場合、あるいは有償サービス
が依頼された場合、保証対象の製品の機種別故障情報を
機種別故障項目データベースから検索し、修理依頼画面
を作成してユーザ端末１０３に送信する（ステップＳ１
２０５）。ユーザがこれに対して該当する項目をチェッ
クしたり、あるいは、故障内容を記入してサービス依頼
として管理サーバ１０１に送信すると、そのサービス依
頼を受信する（ステップＳ１２０６）。

【０１１５】受信したサービス依頼によって保証情報デ
ータベースのサービス依頼履歴や、サービス情報データ
ベースのサービス依頼情報登録日時等、サービス履歴情
報が更新される（ステップＳ１２０７）。そして、該当
するサービス実施店をサービス情報データベースから検
索して、その店の端末に対して、サービス依頼情報（サ
ービス対応ＵＲＬ連絡メール：図２８）を送信する（ス
テップＳ１２０８）。そのＵＲＬが指定されると、管理
サーバ１０１からその端末に対して図２９の保守サービ
ス対応画面が渡され、画面に入力され、送信された保守
サービス可能日時を受信する（ステップＳ１２０９）。

【０１１６】管理サーバ１０１は、サービス日時を決定
し、ユーザ端末に対してサービス受諾情報（図３０）を
送信し（ステップＳ１２１０）、サービス実施店の端末
に対しては、サービスレポートＵＲＬ連絡メール（サー
ビス結果入力依頼情報：図３１）を送信する（ステップ
Ｓ１２１１）。

【０１１７】サービス実施店は、サービス終了の後、実
施したサービス結果を、通知されたＵＲＬを指定すると
表示されるサービスレポート入力画面上から記入する。
このＵＲＬは管理サーバ１０１上にあり、記入され、送
信されたサービス結果を管理サーバ１０１が受信する
（ステップＳ１２１２）。

【０１１８】サービス結果を受信するとサービス履歴情
報が最終的に更新される（ステップＳ１２１３）。ここ
では、顧客情報データベースやサービス店情報データベ
ースのサービス履歴の他、サービス情報データベースの
サービス実施日時、サービス結果情報が更新される。

【０１１９】それとともに、サービスレポートに記載さ
れた処置の内容から、保守サービス費用データベースを
参照してサービス費用を算出する（ステップＳ１２１
４）。算出されたサービス費用は、ステップＳ１２１５
における保証の有効か否かの判定結果に応じて、有効で
なければユーザにその費用を請求するために、ユーザ端
末１０３へと費用請求メール（図３５）を送信する（ス
テップＳ１２１６）。

【０１２０】また、保証の有無に関わらず、サービス実
施店に対して費用の支払いをするため、サービス店端末
１０４に対して費用支払いメール（図３６）を送信する
（ステップＳ１２１７）。

【０１２１】以上のようにして、管理サーバ１０１は機
器保証管理システムの中心的な処理を遂行する。管理サ
ーバ１０１以外の端末は市販ソフトウエアや無償ソフト
ウエアを使用可能であるため、システムを安価に構築す
ることができる。また、管理サーバ１０１の提供者（本
例ではメーカ）以外のサービス店や販売店、ユーザは、
事業者であれば相当普及しているパーソナルコンピュー
タや携帯情報端末を利用してネットワークに接続可能で
さえあればよく、本システム実現のために特別な投資を
必要としない。

【０１２２】また、製品の新規購入に伴うユーザ登録か
らカートリッジの受注、保証の認証を伴う保守サービス
の手配まで、管理サーバ１０１が一元的に行うため、こ
れら管理処理の効率化・単純化が実現できる。

【０１２３】＜本実施形態によるシステムの奏する効果
＞以上のようにして本体製品とともにカートリッジが販
売され、またその販売後に、本体製品に使用されるカー
トリッジの受注−販売手順が遂行される。このため、本
体製品及びカートリッジの販売においては、ユーザは消
耗品を発注する際に使用する機器に対する保証の付与を
選択可能となるので、保証の選択に対して柔軟性を持た
せることができるため、多種多様なユーザのニーズに応
えることができる。

【０１２４】また、消耗品と消耗品を使用する機器に対
する保証を一体にしたことにより、消耗品を使用する機
器の管理、さらには該機器を使用するユーザに関する情
報の管理を容易かつ継続的に行うことが可能となる。そ
れによって機器メーカの開発・生産活動や販売店の営業
活動に有益な情報を管理・蓄積することができる。

【０１２５】また、消耗品であるカートリッジにそれを
使用する本体に対する保証をつけて販売するという本実
施形態のシステムにより、稼働率が高く、保守サービス
提供の頻度も高い製品に対しては保証の対価も高くな
り、逆に稼働率が低く、保守サービスの頻度が低い製品
に対しては保証の対価が安価に設定されることになる。
すなわち、継続的な保守契約を伴わない、いわゆる売り
切り販売される本体製品や消耗品についても、それらに
対する保守サービスの頻度に対応した適正料金の有償保
証を、消耗品の販売という従来通りの行為を通じて提供
することができる。さらに、保証期間の限度を通常考え
得るカートリッジの使用期間（本例では１年間）に設定
しておくことで、故障発生頻度や製品寿命等を参酌した
場合に必要以上の長期間にわたる保証を免れることがで
きる。即ち、長期間に渡る不要な保証によって発生して
いた高額の保証費用を低減できるメリットがユーザに対
して生じることになる。

【０１２６】また、消耗品及び機器を提供するメーカ側
が、保守サービスの保証を付加しないユーザについても
顧客情報管理を行うことが可能となる。

【０１２７】また、この手順により、管理サーバ１０１
は、受注したカートリッジが、本体機器の保証付のもの
であれば、保証に関する情報を更新し、保守サービスの
発生や次回保証の更新などに備えることができる。加え
て、有償保証の処理を行うためのシステムを別途用意す
る必要がない。また、消耗品と製品保証とが同時に販売
されるために、それらを個別に販売する場合に比べて情
報管理を容易にできる。また、保証の提供と消耗品の提
供というそれぞれの販売チャネルを一本化できるため無
駄を排除でき、それに伴ってコストを引き下げる効果が
生じる。

【０１２８】また、メーカが一括して消耗品を販売して
いるために、販売店及びメーカそれぞれが抱える消耗品
の在庫を減らすことができ、販売店及びメーカの収益の
悪化原因を除去できる。

【０１２９】一方、ユーザは、機器を利用していく上で
必要であるカートリッジ購入時に、特別な手続き無しで
本体製品の保証を継続することができる。消耗品は本体
製品を使用する限り購入するものであるため、保証の継
続手続きを怠ったまま放置するといった、ユーザの過誤
による保証切れを防止することができる。また、ユーザ
に対してはカートリッジ発注時に定期的かつ短いスパン
で保証を見直すことができ、長期に渡る保証契約に伴う
高額な保証費用の支払いを免れることができる。

【０１３０】また、上述した手順で、サービス依頼から
その手配までが完了する。さらに、ユーザが使用する機
器が特定されていることで、ユーザからのサービスの依
頼時に予想される故障情報が生成可能であるために、ユ
ーザは故障の特定をするための作業及び故障情報の登録
作業が軽減されて利便性が向上する。また、これによ
り、ユーザは的確な故障内容をサービスの依頼先に通知
できるため、サービスの迅速化およびサービスコストの
低減が可能となる。

【０１３１】また、保守サービスの実施についても、ユ
ーザ情報や機種情報、保証情報の管理が一元化でき、ユ
ーザからの保守サービス依頼の際、ユーザとメーカ、サ
ービス店との間で情報の混乱を防止し、サービス実施の
日時の調整が簡単に行え、迅速な対応が可能となる。

【０１３２】また、ユーザからの修理依頼からサービス
実施店までの故障内容の通報や修理作業予定の作成、作
業予定のユーザへの通知までが一連の処理として本実施
形態の機器保証管理システムにより行われるため、連絡
漏れや遅延による保守サービスの不実施やトラブルを防
止することができる。

【０１３３】また、ユーザとメーカ、サービス実施店の
間の連絡が、管理サーバ１０１から支給される画面への
書き込みや電子メールといった電子文書で行われ、それ
らの記載内容はデータベースとして管理されるために、
改めて伝票入力するといった作業をなくすことができる
とともに、後日に連絡内容を確認することも可能とな
る。

【０１３４】また、サービス実施店の決定の段階で、最
もユーザに適したサービス店が選択されるために、迅速
なサービスが可能となる。

【０１３５】また、顧客情報やサービス情報を一元的に
管理できるために、営業活動や製品開発へ情報を利用し
やすくなる。

【０１３６】また、上述したように代金支払い処理を行
うことで、サービス時におけるサービス代金の決済業務
を簡素化することができる。また、請求されたユーザや
支払いを受けたサービス店がその明細を望んだ場合に
は、管理サーバ１０１において明細を記した情報に対応
するＵＲＬを、支払い通知或いは請求書とともに知らせ
てあるため、ユーザ端末或いはサービス店端末から、そ
のＵＲＬからアクセスして管理サーバ１０１におかれた
明細を参照することができる。

【０１３７】また、上述したように、管理サーバ１０１
が管理する保証期間に関する情報（保証終了日）に基づ
いて、ユーザに保証切れ警告を通知し、更新する機会を
与えることができるので、更新をし忘れるといったミス
を低減できる。

【０１３８】また、製品の使用頻度、即ちカートリッジ
の購入頻度が低いユーザは、有償の保証を購入して保守
サービスを無償とするよりも、故障のつど有料で修理し
た方が軽い負担で済み、ユーザにとっても保守のための
負担が軽減されることになる。

【０１３９】また、上述したように、管理サーバ１０１
は機器保証管理システムの中心的な処理を遂行し、管理
サーバ１０１以外の端末は市販ソフトウエアや無償ソフ
トウエアを使用可能であるため、システムを安価に構築
することができる。また、そのため、管理サーバ１０１
の提供者（本例ではメーカ）以外のサービス店や販売
店、ユーザは、本システム実現のために特別な投資を必
要としない。

【０１４０】また、製品の新規購入に伴うユーザ登録か
らカートリッジの受注、保証の認証を伴う保守サービス
の手配まで、管理サーバ１０１が一元的に行うため、こ
れら管理処理の効率化・単純化が実現できる。

【０１４１】なお、本発明の目的は、前述した実施形態
の手順を実現するソフトウェアのプログラムコードを記
録した如何なる記憶媒体（または記録媒体）を、システ
ムあるいは装置に供給し、そのシステムあるいは装置の
コンピュータ（またはCPUやMPU）が記憶媒体に格納され
たプログラムコードを読み出し実行することによって達
成される。

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

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

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

【０１４５】また、上記制御を行うプログラムコード及
びアプリケーションをネットワークを介して提供するこ
とで、前述した実施形態の機能の実現及び効果が得られ
る場合も含まれる。

【０１４６】以上、本発明についての詳細な説明では、
トナーカートリッジを使用する電子写真プリンタを用い
てきたが、本発明はこれに限定されるものではなく、消
耗品を定期的に購入・交換する機器全般に対して適用可
能である。

【０１４７】

【発明の効果】以上のように本発明によれば、消耗品と
サービスとを一元的に管理し処理することで、ユーザの
利便性を向上させ、また、サービス提供側においても、
コスト低減などが実現できる。

【０１４８】また、さらに、ユーザが使用する機器が特
定されていることで、ユーザからのサービスの依頼時に
予想される故障情報が生成可能であるために、ユーザは
故障の特定をするための作業および故障情報の登録作業
が軽減されて利便性が向上する。また、これにより、ユ
ーザは的確な故障内容をサービスの依頼先に通知できる
ため、サービスの迅速化およびサービスコストの低減が
可能となる。

【０１４９】また、保守サービスの実施についても、ユ
ーザ情報や機種情報、保証情報の管理が窓口と実施者と
で一元化でき、ユーザからの保守サービス依頼の際、情
報の混乱を防止し、サービス実施の日時の調整が簡単に
行え、迅速な対応が可能となる。

【０１５０】また、ユーザからの修理依頼からサービス
実施者までの故障内容の通報や修理作業予定の作成、作
業予定のユーザへの通知までが一連の処理として行われ
るため、連絡漏れや遅延による保守サービスの不実施や
トラブルなどを防止することができる。

【０１５１】また、ユーザと窓口（サーバ）、サービス
実施者の間の連絡が、サーバから支給される画面への書
き込みや電子メールといった電子文書で行われ、それら
の記載内容はデータベースとして管理されるために、改
めて伝票入力するといった作業をなくすことができると
ともに、後日に連絡内容を確認することも可能となる。

【０１５２】また、サービス実施店の決定の段階で、最
もユーザに適したサービス店が選択されるために、迅速
なサービスが可能となる。

【０１５３】また、サービス時における代金の決済業務
を簡素化することができる。

【図面の簡単な説明】

【図１】本発明の実施形態である機器保証管理システム
全体の構成を示す図である。

【図２】管理サーバ１０１等を実現するコンピュータの
ブロック図である。

【図３】プリンタ１０２の断面図である。

【図４】ユーザが新規にプリンタなどの本体製品を購入
した場合における機器保障管理システムの動作を示す図
である。

【図５】ユーザがカートリッジを購入した場合における
機器保障管理システムの動作を示す図である。

【図６】ユーザがメーカに対して修理等の保守サービス
を依頼する時点から開始される機器保証システムによる
動作手順を示す図である。

【図７】ユーザがメーカに対して修理等の保守サービス
を依頼する時点から開始される機器保証システムによる
動作手順を示す図である。

【図８】サービス代金の精算手順を示す図である。

【図９】保証期限切れ通知をユーザに対して発行する手
順を示す図である。

【図１０】本体装置の新規登録時の管理サーバ１０１に
よる手順を示すフローチャートである。

【図１１】カートリッジの発注を受けた際の管理サーバ
１０１による手順を示すフローチャートである。

【図１２Ａ】サービス依頼を受けた際の管理サーバ１０
１による処理手順を示すフローチャートである。

【図１２Ｂ】サービス依頼を受けた際の管理サーバ１０
１による処理手順を示すフローチャートである。

【図１３】ユーザ登録画面の一例を示す図である。

【図１４】サービス店決定通知メールの一例を示す図で
ある。

【図１５】保証登録完了メールの一例を示す図である。

【図１６】保証書の書式の一例を示す図である。

【図１７】ユーザ認証画面の一例を示す図である。

【図１８】認証失敗時のエラー画面の一例を示す図であ
る。

【図１９】ユーザ端末１０３に表示される発注・修理依
頼選択画面の一例を示す図である。

【図２０】保証付カートリッジ発注画面の一例を示す図
である。

【図２１】カートリッジ選択発注画面の一例を示す図で
ある。

【図２２】保証無しカートリッジ発注画面の一例を示す
図である。

【図２３】登録完了メッセージ５０８の内容の一例を示
す図である。

【図２４】インセンティブ情報通知メールの内容の一例
を示す図である。

【図２５】保証番号確認画面の一例を示す図である。

【図２６】エラー画面の一例を示す図である。

【図２７】保証切れ画面の一例を示す図である。

【図２８】保守サービス対応ＵＲＬ連絡メールの一例を
示す図である。

【図２９】保守サービス対応画面の一例を示す図であ
る。

【図３０】サービス受諾メールの一例を示す図である。

【図３１】サービスレポートＵＲＬ連絡メール７０５の
一例を示す図である。

【図３２】サービスレポート記入画面の一例を示す図で
ある。

【図３３】保証切れ警告メールの一例を示す図である。

【図３４】保証期間経過メールの一例を示す図である。

【図３５】保守サービス費用請求メール８０２の一例を
示す図である。

【図３６】保守代金支払いメール８０１の一例を示す図
である。

フロントページの続き (72)発明者 清水 由紀彦 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 上田 晃生 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 安藤 展広 東京都港区三田３丁目11番28号 キヤノン 販売株式会社内 (72)発明者 近藤 一臣 東京都港区三田３丁目11番28号 キヤノン 販売株式会社内

Claims (22)

【特許請求の範囲】
1. 【請求項１】 消耗品を使用する機器において、前記機
   器の保証は保証付き消耗品を購入することで付与され、
   該保証の情報を管理するサーバ装置であって、 前記機器に対する保守サービス依頼情報を受信するサー
   ビス依頼情報受信手段と、 前記サービス依頼情報受信手段で受信した情報と前記保
   証情報とに基づいて、前記保守サービス依頼が前記保証
   の対象となるか否かを判別する判別手段とを有すること
   を特徴とするサーバ装置。
2. 【請求項２】 前記サービス依頼情報受信手段は、サー
   ビス依頼に関する情報を受信すると共に、前記機器を使
   用するユーザに関する情報、前記機器に関する情報、前
   記保証情報のうち少なくともひとつの情報を受信し、該
   情報と前記保証情報とから、前記機器が保証の対象とな
   るか否かを前記判別手段が判別することを特徴とする請
   求項１に記載のサーバ装置。
3. 【請求項３】 前記サービス依頼情報受信手段で受信し
   たサービス依頼が、前記判別手段による判別の結果、前
   記保証の対象外である機器に対しての依頼であった場
   合、前記保証の対象外である旨の情報と、保証対象外の
   機器に対して保守サービスを依頼するか否かを再度選択
   させる情報とを、保守サービスの依頼元が利用可能な端
   末に送信することを特徴とする請求項１又は２に記載の
   サーバ装置。
4. 【請求項４】 機器に発生し得る故障内容情報を格納し
   た機種別故障内容情報格納手段と、 前記サービス依頼情報受信手段によって受信した前記機
   器の情報に基づいて、該機器に発生し得る故障内容情報
   を前記機種別故障内容情報格納手段から出力する出力手
   段と、 前記出力手段によって出力された情報を保守サービスの
   依頼元が利用可能な端末に送信する機種別故障情報送信
   手段とをさらに有することを特徴とする請求項１乃至２
   のいずれか１に記載のサーバ装置。
5. 【請求項５】 前記保守サービス依頼元は、前記保守サ
   ービスを依頼する故障を、前記機種別故障情報送信手段
   によって送信された前記予想される故障情報から適宜選
   択し、前記保守サービス依頼元が利用可能な端末から前
   記サーバ装置に送信した保守サービス依頼内容情報を、
   前記保守サービスを行うサービス店が利用可能な端末へ
   送信する転送手段を有することを特徴とする請求項４に
   記載のサーバ装置。
6. 【請求項６】 前記転送手段は、前記端末へ転送する情
   報に、前記サービス店が前記保守サービス可能な日時の
   入力を要求する情報を付加して送信することを特徴とす
   る請求項５に記載のサーバ装置。
7. 【請求項７】 前記サービス店が指定した前記保守サー
   ビス可能な日時情報を前記機器を使用するユーザが利用
   可能な端末に送信する保守サービス受諾情報送信手段を
   有することを特徴とする請求項６に記載のサーバ装置。
8. 【請求項８】 前記機器に対する保守サービスの依頼情
   報を受信したことに基づいて、前記保守サービスを行う
   サービス店が利用可能な端末に、保守サービスを実施し
   た結果情報の入力を要求する情報を送信することを特徴
   とする請求項１乃至７のいずれか１に記載のサーバ装
   置。
9. 【請求項９】 前記保守サービスの結果情報に基づいて
   前記保守サービスの費用を算出する費用算出手段と、 前記保証情報に基づいて、前記費用の決済を行う決済手
   段とをさらに有することを特徴とする請求項８に記載の
   サーバ装置。
10. 【請求項１０】 消耗品を使用する機器において、前記
    機器の保証は保証付き消耗品を購入することで付与さ
    れ、該保証の情報を管理するサーバ装置の制御方法であ
    って、前記機器に対する保守サービス依頼情報を受信す
    るサービス依頼情報受信工程と、 前記サービス依頼情報受信工程で受信した情報と前記保
    証情報とに基づいて、前記保守サービス依頼が前記保証
    の対象となるか否かを判別する判別工程とを有すること
    を特徴とするサーバ装置の制御方法。
11. 【請求項１１】 前記サービス依頼情報受信工程では、
    サービス依頼に関する情報を受信すると共に、前記機器
    を使用するユーザに関する情報、前記機器に関する情
    報、前記保証情報のうち少なくともひとつの情報を受信
    し、該情報と前記保証情報とから、前記機器が保証の対
    象となるか否かを前記判別工程で判別することを特徴と
    する請求項１０に記載のサーバ装置の制御方法。
12. 【請求項１２】 前記サービス依頼情報受信工程で受信
    したサービス依頼が、前記判別工程で判別された結果、
    前記保証の対象外である機器に対しての依頼であった場
    合、前記保証の対象外である旨の情報と、保証対象外の
    機器に対して保守サービスを依頼するか否かを再度選択
    させる情報とを、保守サービスの依頼元が利用可能な端
    末に送信することを特徴とする請求項１０又は１１に記
    載のサーバ装置の制御方法。
13. 【請求項１３】 前記サーバ装置は、機器に発生し得る
    故障内容情報を格納した機種別故障内容情報格納部をさ
    らに有し、 前記サービス依頼情報受信工程で受信した前記機器の情
    報に基づいて、該機器に発生し得る故障内容情報を前記
    機種別故障内容情報格納部から出力する出力工程と、 前記出力工程で出力された情報を保守サービスの依頼元
    が利用可能な端末に送信する機種別故障情報送信工程と
    をさらに有することを特徴とする請求項１０乃至１２の
    いずれか１に記載のサーバ装置の制御方法。
14. 【請求項１４】 前記保守サービス依頼元は、前記保守
    サービスを依頼する故障を、前記機種別故障情報送信工
    程で送信された前記予想される故障情報から適宜選択す
    る工程と、前記保守サービス依頼元が利用可能な端末か
    ら前記サーバに送信した保守サービス依頼内容情報を、
    前記保守サービスを行うサービス店が利用可能な端末へ
    送信する転送工程と、を有することを特徴とする請求項
    １３に記載のサーバ装置の制御方法。
15. 【請求項１５】 前記転送工程では、前記端末へ転送す
    る情報に、前記サービス店が前記保守サービス可能な日
    時の入力を要求する情報を付加して送信することを特徴
    とする請求項１４に記載のサーバ装置の制御方法。
16. 【請求項１６】 前記サービス店が指定した前記保守サ
    ービス可能な日時情報を、前記機器を使用するユーザが
    利用可能な端末に送信する保守サービス受諾情報送信工
    程をさらに有することを特徴とする請求項１５に記載の
    サーバ装置の制御方法。
17. 【請求項１７】 前記機器に対する保守サービスの依頼
    情報を受信したことに基づいて、前記保守サービスを行
    うサービス店が利用可能な端末に、保守サービスを実施
    した結果情報の入力を要求する情報を送信する工程をさ
    らに有することを特徴とする請求項１０乃至１６のいず
    れか１に記載のサーバ装置の制御方法。
18. 【請求項１８】 前記保守サービスの結果情報に基づい
    て前記保守サービスの費用を算出する費用算出工程と、 前記保証情報に基づいて、前記費用の決済を行う決済工
    程と をさらに有することを特徴とする請求項１７に記載のサ
    ーバ装置の制御方法。
19. 【請求項１９】 請求項１０乃至１８のいずれかに記載
    の方法をコンピュータにより実行させるためのコンピュ
    ータプログラム。
20. 【請求項２０】 請求項１９に記載のコンピュータプロ
    グラムを格納するためのコンピュータ可読記憶媒体。
21. 【請求項２１】 消耗品を使用する機器を使用するユー
    ザが利用可能な端末と、前記端末と前記機器に対する保
    証情報を管理するサーバ装置とがネットワークを介して
    接続される構成を含む機器保証システムであって、 機器に対する保証が付与された消耗品を購入すること
    で、前記機器に対して保証が発生し、 前記端末は前記機器に対する保守サービス依頼情報を前
    記サーバに送信するサービス依頼情報送信手段を有し、 前記サーバ装置は、前記サービス依頼情報送信手段によ
    って送信された前記保守サービス依頼情報と前記保証情
    報とに基づいて、前記保守サービス依頼が前記保証の対
    象となるか否かを判別する判別手段を有することを特徴
    とする機器保証システム。
22. 【請求項２２】 消耗品を使用する機器を使用するユー
    ザが利用可能な端末と、前記端末と前記機器に対する保
    証情報を管理するサーバ装置とがネットワークを介して
    接続される構成を含む機器保証システムの制御方法であ
    って、 前記端末は前記機器に対する保守サービス依頼情報を前
    記サーバ装置に送信し、 前記サーバ装置は、前記端末から送信された前記保守サ
    ービス依頼情報と前記保証情報とに基づいて、前記保守
    サービス依頼が前記保証の対象となるか否かを判別する
    判別工程を有することを特徴とする機器保証システムの
    制御方法。