JP2002269269A

JP2002269269A - 機器管理システム及びその制御方法及び記憶媒体及びコンピュータプログラム

Info

Publication number: JP2002269269A
Application number: JP2001072559A
Authority: JP
Inventors: Wataru Mishima; 渉三島
Original assignee: Canon Inc; Canon Marketing Japan Inc
Current assignee: Canon Inc; Canon Marketing Japan Inc
Priority date: 2001-03-14
Filing date: 2001-03-14
Publication date: 2002-09-20

Abstract

(57)【要約】【課題】保守サービスを必要とする機器について、そ
の製造段階から廃棄或いは再利用されるまでを管理し、
各販売店に対して有効な情報の提供し、事業の効率化を
図る。【解決手段】センタのＤＢは、中央倉庫からの製品に
ユニークな機番情報を受信した場合に、新規のその機番
用のデータを登録する。また、販売店に設置された端末
から顧客への納品指示があった場合には、当該要求され
た機器の配送手続きを行い、搬送される機器の機器番号
を有するデータ中の所有者を示す領域に、顧客を特定す
る情報で更新する。そして、処分所から廃棄処分或いは
再生処理の通知を受けた場合、該当する機番情報を持つ
データを抹消する。そして、また、再生処理が施された
ことを通知を受けた場合には、この再生処理後の機器に
ついて新規の機番情報を付与し、データベースに登録す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は機器管理システム及
びその制御方法及び記憶媒体及びコンピュータプログラ
ムに関するものである。

【０００２】

【従来の技術】ＯＡ製品、特に、複写機を例にして説明
する。

【０００３】一般に、メーカの工場で複写機が製造され
ると、先ず、中継倉庫に搬送されそこで管理される。ま
た、この中継倉庫から、地方にある各中継倉庫に搬送さ
れることもある。販売店に顧客がついた場合、その販売
店はメーカの販売部門（又はメーカの販売会社）を介し
て所定の手続きを行い、最寄りの倉庫から顧客まで搬送
及び設置作業を行い、メンテナンス等についての契約を
交わす。以後、この契約に従い、定期的なメンテナン
ス、及び、複写枚数のチェックを行うことになる。

【０００４】メンテナンス及び複写枚数のチェックは、
その顧客にとって最寄りの販売店員が行うことになり、
その課金による請求書も販売店単位に行うことになる。

【０００５】しかしながら、例えば国内全域の販売店の
数は膨大であり、且つ、メンテナンス及び複写枚数のチ
ェックのスケジュールの管理、及び、請求書の発行の管
理は相当の時間と労力を必要とする。従って、かかる管
理を各販売店毎に独立して行うようにすると、国内全体
の販売店のそれに費やす時間及び労力は、販売店の数に
比例したものとなり、膨大なものとなる。

【０００６】そこで、中枢となるセンタを設け、ここで
全ての製品を管理するシステムが考えられる。かかるシ
ステムにすると、販売店とセンタとは回線を介してデー
タ授受を行い、販売店側としては専ら簡単なデータ入力
を行うだけとなり、メンテナンス及び複写枚数のチェッ
クのスケジュールもセンタ側で行い、販売店側はこれを
閲覧するだけで済むことになる。また、請求書にして
も、センタが発送元となって、顧客に請求書を郵送する
等で対処すれば良いので、販売店の負担も軽減でき、し
かも、全ての販売店で共通した仕事環境を提供できるこ
とにより、作業の効率化も進むことになる。

【０００７】

【発明が解決しようとする課題】かかるシステムを構築
するには、全製品（販売済み及び販売待機状態となって
いる製品も含む）の現在の状況（所在等）と、個々の製
品を設置した顧客、及びその接点となる販売店等の情報
が必要になる。しかも、廃棄処分となったもの、再生さ
れた装置をも管理する必要が生じてくる。

【０００８】本発明は保守サービスを必要とする機器に
ついて、その製造段階から廃棄或いは再利用されるまで
を管理し、各販売店に対して有効な情報の提供し、事業
の効率化を図ることを可能ならしめる機器管理システム
及びその制御方法及び記憶媒体及びコンピュータプログ
ラムを提供しようとするものである。

【０００９】

【課題を解決するための手段】この課題を解決するた
め、例えば機器管理システムは以下の構成を備える。す
なわち、保守サービス対象の機器及びその周辺機器に対
し、それら機器製造後の初期段階で付与された個々の機
器を特定する機番情報を入力する第１の端末と、販売店
及び保守サービス店に設置された第２の端末と、処分所
に設置された第３の端末と、前記第１乃至第３の端末と
の通信を行い、機器管理を行うセンタサーバとを備える
製品管理システムであって、前記センタサーバは、前記
第１の端末からの登録の指示があった場合、当該第１の
端末より受信した前記機番情報を主情報とする機器管理
データをデータベースに登録する手段と、前記第２の端
末から顧客への納品指示があった場合に、当該要求され
た機器の配送手続きを行い、搬送される機器の機器番号
を有するデータ中の所有者を示す領域に、前記顧客を特
定する情報で更新する手段と、前記第３の端末から廃棄
処分或いは再生処理の通知を受けた場合、前記データベ
ースから該当する機番情報を持つデータを抹消する手段
とを備え、再生処理が施されたことを通知を受けた場
合、当該再生処理後の機器について新規の機番情報を付
与し、前記データベースに登録することを特徴とする機
器管理システム。

【００１０】

【発明の実施の形態】以下、添付図面に従って本発明に
かかる実施形態を詳細に説明する。

【００１１】実施形態では、メンテナンス（保守点検）
を必要とする製品の中の代表的な複写機及びそれに付随
可能な周辺機器（ソータ、ネットワークプリンタとして
機能する装置等）を例にして説明する。

【００１２】＜全体の構成とその流れ＞先ず、複写機の
製造に始まる一連の製品の流れ及び実施形態におけるシ
ステムの全体の動作を説明する。

【００１３】複写機及びそれに接続可能な周辺機器が製
造されると、それぞれユニークな機番（モデル名も判別
可能な文字列）が付加され、中央倉庫に一旦に搬送され
る。中央倉庫では、搬送されてきた機番、及びその搬入
日（もしくは製造日）をサブセンタのＤＢ（データベー
ス）に登録する。サブセンターに登録されたデータベー
ス中の新規に登録された製品情報は、例えば一日に一回
という頻度で、センタに設けられたサーバに通知され
る。センタはこれを受け、製品一つ一つに対する基礎フ
ォームに、その製品のデータを登録する。これ以降、各
製品に関する流通にかかる情報は、この基礎フォームを
更新することで一元管理されることになる。すなわち、
全ての国内販売店で販売される複写機の管理が開始す
る。

【００１４】尚、上記例では、中央倉庫に搬入されるこ
とをトリガにして、サブセンタ→センタへとデータの登
録がなされるものとしたが、製造工場から出荷する際に
サブセンタもしくはセンタに登録するようにしても構わ
ない。

【００１５】また、一旦、サブセンタにデータをストア
してからセンタサーバにまとめて転送するのは、１つ１
つの製品に搬入される度に送信するようにしてしまう
と、回線使用回数が増えることによる通信費増大するた
めである。

【００１６】また、センタには、各製品を管理する上
で、機番とモデル名との対応を示すＤＢ、顧客や販売店
を管理するＤＢ等、複数のＤＢが稼動している。ここで
言う、センタにおけるＤＢとは、ＤＢシステムがそれぞ
れ独立した分散型システムでも良いし、１つのＤＢシス
テム内に複数のＤＢを構築しても良い。要は互いに関連
する環境で全体のシステムを構築するものであればよ
い。

【００１７】さて、中央倉庫から、更に、地方の主だっ
た倉庫に搬送される。各地方への搬送する台数は、各倉
庫の規模や各地方の顧客数等を勘案されて行われる。配
送手続きを行う者は、例えばハンディターミナルを用い
て、製品に付加された機番と配送先の倉庫のコードを入
力し（一般にバーコードを読み取る等して入力）、その
ハンディターミナルに格納されたデータを所定の端末に
転送することで、最終的にセンターに通知する。センタ
ＤＢはこの通知を受け、各製品の所在位置を更新する。

【００１８】一方、販売店側には、センタと通信する端
末が設置してあって、その動きは次のようになる。

【００１９】先ず、顧客から要望があった場合、その機
種が最寄りの地方倉庫或いは中央倉庫に存在するか否か
をセンタに対して問い合わせをする。センタは、全ての
複写機並びにその周辺機器（以下、単に特に断りがない
限り、複写機という）を管理しており、指示された倉庫
の該当する機種の保管状況（台数）を販売店端末に通知
する。販売店側では、在庫が確認できると、顧客向けの
発送手続きをセンタに対して行う。また、在庫がない場
合には、センタに対し、中央倉庫からの発送手続き申請
する。この場合、センタは中央倉庫に対して、配送を指
示することになる。尚、かかる配送業務にかかる処理内
容の詳細については後述する。

【００２０】上記のようにして、顧客の所へ複写機が搬
送されることになるが、販売店員は、複写機の到着時
（或いはそれより前でも後でも構わない）に、ユーザー
と保守契約書を作成する。

【００２１】保守契約書には、顧客の名称、住所、更に
は購入機種モデル、複写枚数等のカウンタチェックの期
間間隔（何ヶ月単位にするか等）の情報を記述すること
になる。また、このとき、保守点検サービスの予定日、
及び、期間間隔、そして保守点検を行う店名も記述する
（販売店と保守点検サービスを行う店が同じでも構わな
い）。そして、この契約書を販売店に持ち帰り、端末を
操作することで該当する機番（複写機）に対する情報
と、その販売店のＩＤ及び保守点検サービスを行う店の
ＩＤも併せて登録し、その情報をセンタに通知する。セ
ンタは、この情報を受け、該当する機番の所在として顧
客ＩＤを割り当てる。尚、顧客はＤＢ内でＩＤコードと
して管理されており（ＩＤコードと顧客との関係につい
ては別途ＤＢが設けられている）、センタでは機番の基
礎フォームの該当する領域を受け取ったデータで埋めて
いく。これ以降、その機番（複写機等）に対する保守点
検のスケジュール管理、カウンタチェック日のスケジュ
ール管理が開始される。

【００２２】保守点検を受け持つ店では、例えばメンテ
ナンスする必要がある顧客を調べたい場合には、端末を
操作して自身の店のＩＤを入力し、センタに接続する。
そして、メンテナンスの状況を表示する指示を与える。
センタは、接続依頼元の店のＩＤを既に取得しているわ
けであるから、その保守点検対象となっている保守サー
ビス店の項目に、その店ＩＤを持つデータを検索し、例
えば顧客名を第１ソート、メンテナンス予定日を第２ソ
ートのキーにしてその一覧をその店の持つ端末に転送す
る。これにより、保守サービス店側は、メンテナンスの
スケジュールを行うことが可能になる。つまり、同じ顧
客に対して幾つものメンテナンス対象の製品があれば、
それらをまとめてメンテナンスを行う等に活用できるよ
うになる。

【００２３】尚、実際にメンテナンスを行った場合に
は、その旨を機番毎にセンタに通知する。センタはこれ
を受けて、次回のメンテナンスの予定日を更新すること
になる。

【００２４】上記は、カウンタチェックについても同様
である。ただし、カウンタチェックを行って、センタに
それを通知すると、センタは前回に受けたカウンタとの
差分に１未満の所定比率を乗算した結果に基づいて請求
書の作成を行う。尚、所定比率を乗算する理由は、顧客
において或る頻度でジャム等のエラーがあったものとす
るためである。そのため、この比率に含まれるジャムエ
ラー率は、実際のそれより多めにしてある。尚、カウン
タチェック及びメンテナンスについてシステムの動作の
詳細については後述する。

【００２５】請求書発行は、顧客の要望する様式が様々
であるので、予め多数の請求書フォームを容易してお
き、その顧客の要望に沿ったフォームを用いて印刷する
ことになる。請求書には、取り引き金融機関（銀行名と
口座番号）を付して印刷する。

【００２６】さて、上記は通常の使用における動作であ
るが、場合によっては、顧客は新しいモデルに替える、
或いは追加することもあり得るし、単に従前に使用して
いた機種の引き取り、廃棄依頼を行うことも当然にあり
得る。

【００２７】新機種への切り換え若しくは新規導入する
場合の、その新機種の設置にかかる手続きについては上
記の通りであるので、ここでは従前に使用していた機種
の引き取りについて説明する。

【００２８】販売店が顧客より引き取りの依頼を受ける
と、所定の引き上げ業者に依頼を発行し、最寄りの処分
所に配送を行うと共に該当する機番についての所有者情
報として処分所のＩＤで置き換える。処分所に配送され
てきた装置は、処分所において再利用できるかどうか
（多くの場合には使用している部品に依存する）を判断
され、廃棄所と再生所の２つのルートに分別され、それ
ぞれに配送が行われる。廃棄書に搬送された装置につい
て、処分所でその機番抹消手続きを行い、それをセンタ
に通知する。センタは、指示された機番に該当するデー
タをＤＢから削除する等の処理を行う。一方、再生所に
配送された装置については、最寄りの地方倉庫又は中央
倉庫へと配送され、それが再生作業がお粉割る。このと
き、新たな機番（ただし、再生された製品化どうかを区
別可能になっている）が付されるので、従前の機番に関
する情報はＤＢより抹消する手続きを行う。再生処理は
行われると、最寄りの地方倉庫又は中央倉庫へと配送さ
れる。倉庫側の端末では、再生所から配送されてきた機
種について、その機番を新規にセンタに登録する依頼す
る。

【００２９】以上のようにして、製造されてから廃棄処
理、更には再登録処理が繰り返され、全ての製品につい
てその所在を管理し、且つ、顧客に対するメンテナンス
等の管理を一元管理することが可能になる。

【００３０】＜センタの構成＞次に、実施形態における
センタにおけるＤＢシステムについて以下に詳述する。

【００３１】図２は、実施形態におけるセンタのＤＢシ
ステムを構成する装置のブロック構成図である。

【００３２】図中、１は装置全体の制御を司るＣＰＵで
あり、２はブートプログラムやＢＩＯＳ等を記憶してい
るＲＯＭ、３はＣＰＵ１の処理するプログラムを展開し
たり、ワークエリアとして使用されるＲＡＭである。４
はハードディスク装置であり、内部にはＯＳ、ＤＢシス
テムとして動作するサーバアプリケーションを格納す
る。また、図示に示すように、実施形態の中枢となる機
番やその機種を管理する機番管理マスタＤＢを始め、そ
れをサポートする顧客に関する顧客ＤＢ、販売店に関す
る販売店ＤＢ、請求書に関する請求書ＤＢ、請求先の振
込時の振込人名称を管理する名寄せＤＢで構成される。

【００３３】ここで、顧客ＤＢは、顧客ＩＤ、その顧客
の住所、正式名称、電話、ファクシミリ等の顧客固有の
情報を管理する。販売店ＤＢは、その販売店或いはメン
テナンスサービスを行う店のＩＤ、住所等を管理する。
請求書ＤＢは、請求先に対する多数の請求書フォーム
と、実際の請求書を構成する請求書データ等を管理する
ものである。名寄せＤＢは、請求書に対する請求先から
の入金処理を効率的に実行するために、１つの請求先に
対して使用された複数種類の振込人名称を請求先毎に逐
次登録し管理するものである。

【００３４】これらのＤＢは全て機番管理マスタＤＢの
補助するために存在する。

【００３５】５は各販売店、サービス店や倉庫等に設置
された端末との通信接続するための通信インターフェー
スであり、６はキーボード、７は表示装置、８はセンタ
内に設置されたネットワークに接続するためのネットワ
ークインターフェースである。請求書の印刷を行うプリ
ンタも、このネットワークに接続されている。

【００３６】上記構成において、実施形態における機番
管理マスタＤＢのデータフォーマットは図３に示す構造
を成している。図示は、１つの機番、つまり、１製品に
関するデータフォーマットである。

【００３７】図示の項目の意味は以下の通りである。

【００３８】機番：文字とおり製品をユニークに識別す
る「機番ＩＤ」を格納する領域、機種：機番からモデル名を特定するモデルコードを格納
する領域（機番からだけでも機種が判別できるが、分か
り易くするために設けた）、作成日：該当する機番のデータを作成した日を格納する
領域、リンク情報：該当する機番が複写機である場合には、周
辺機器があるか否かを示す情報が格納され、周辺機器で
ある場合には接続する複写機の機番が格納される。

【００３９】顧客：顧客ＩＤを格納する領域、販売店：その製品を販売した店ＩＤを格納する領域、サービス店：製品の保守点検を行う店ＩＤを格納する領
域、契約開始日：最新の契約日を格納する領域、初回契約日：その機種の一番最初の契約日を格納する領
域（「契約開始日」が何度も更新された中の最新の契約
日であるのに対し、この「初回契約日」は最初の契約開
始日となる）、契約終了日：契約が満了する日を格納する領域、契約期間：契約開始日からの月数が格納される領域、締め予定日：その機番に対する請求書を発行する際の締
め日を格納する領域、締め予定サイクル：締めを行う月数を格納する領域、保守予定日：保守点検を行う日を格納する領域、保守サイクル：保守点検を行う間隔である月数を格納す
る領域、前回保守日：前回保守点検した日を格納する領域、前回締め日：コピー枚数をチェックした最新日を格納す
る領域、前回値Ａ,Ｂ,Ｃ…：前回チェックした際の累積コピー枚
数（複写機が有するカウンタ値）を格納する領域、今回値Ａ,Ｂ,Ｃ…：今回チェックした際の累積コピー枚
数を格納する領域である。

【００４０】ここで、カウンタを複数分確保したのは、
以下の理由による。

【００４１】これまでのモノクロ複写機における課金の
仕方は、１つのカウンタによるものであった。また、一
般に知られているように、モノクロ複写機はＡ４，Ａ
３、Ｂ５，Ｂ４等複数の記録紙に複写できるものが多
い。従って、課金の算定は、これら異なる用紙サイズを
予め設定した比率で消費されることを見越し、コピー枚
数から課金額を算定していた。しかしながら、専ら一方
でサイズの小さい用紙しか消費しない顧客もあり得るの
で、上記課金は正しく算定できない。また、昨今の様
に、カラー複写機が普及しつつあることで、モノクロ、
カラーの切り分けも正しくさせないと、更に問題が発生
するし、複写機をスタンドアロン装置として設置するの
ではなく、ネットワークプリンタとして機能させる周辺
機器を導入してパーソナルコンピュータ（以下、ＰＣ）
等のプリンタとして活用する場合、そのＰＣによる印刷
枚数による課金は、複写時より低くしなければならな
い。

【００４２】そこで、本システムでは、用紙サイズにつ
いてはＡ４サイズ以下（Ｂ５を含む）、それより大きい
サイズ（Ｂ４，Ａ３等）サイズのいずれであるか、モノ
クロかカラーか、更には、複写によるものかＰＣよりの
印刷かの３つの条件に見合うカウンタ値を格納する領域
を確保した。３つの条件による組み合わせは、２の３乗
＝８通りの組み合わせが存在するから、上記の前回値の
領域は８つ、今回値の領域も８つ備える。注意したいの
は、全ての複写機にカウンタが８つ備えられていること
を意味するものではない。つまり、カラー複写機単独で
使用した場合には、ＰＣによる印刷はできないわけであ
るから、使用する領域は前回値及び今回値とも４つにな
る。そして、そのカラー複写機が、ネットワークプリン
タとして機能する周辺装置を接続可能で、実際にその周
辺機器を接続して活用するようになると、上記カウンタ
が機能することになる。

【００４３】尚、複写機の周辺装置（ソータ（これにも
ステイプル機能付き等の様々なものがある）、ネットワ
ーク接続装置等）には、カウンタに関する情報はない、
もしくはその領域はあってもダミー扱いになる。

【００４４】上記構成において、製品が製造され、中央
倉庫に搬入されセンタに通知を受けると、その機番に基
づいて図３の新規レコードを作成することになる。この
時に埋められるデータ項目は、機番、機種、作成日であ
り、顧客の欄には、その倉庫を示す店ＩＤが格納される
ことになり、顧客に納品されると、顧客の欄にはその顧
客のＩＤが埋められることになる。

【００４５】図４は、機番管理マスタＤＢについて或る
機番（図示では機番「LGH06935」）をアクセスした際に
表示される一例を示している。図示において、各矩形枠
内にあるコロン“：”の右側が編集可能な領域であり、
枠外に表示される文字列は、枠内にあるＩＤやコードに
基づいて別ＤＢを参照することで得られた結果を示して
いる。

【００４６】図示によれば、機番“LGH06935”で示され
る機種は“6022”であり、顧客は顧客ＩＤ“L9-1111”
の“ＡＢＣ株式会社”である。その他については説明す
るまでもないであろう。尚、カウンタ値で今回のカウン
タ値から前回のカウンタ値を差し引くことで、その間の
コピー枚数を算出し、請求書の発行を行うことになる。
入金が確認処理を行うことで、今回のカウンタ値が前回
カウンタ値に置き換えられることになる。従って、図示
では、前回の締め日が２０００年２月１５日であるの
で、その日に締めを行ってから入金がない状態を示して
いることになる。因に、この機番の顧客は、締め予定日
は２０日で、締めサイクルは２ヶ月であるので、次回の
締め処理は２０００年４月２０日までに行うことにな
る。つまり、カウンタチェックはそれ以前に完了してい
ることが必要になる。

【００４７】＜納品処理の説明＞顧客から機種導入の要
望を受けると、販売店員は、自身の店ＩＤを入力し、セ
ンタにログインし、初期メニュー（不図示）中の「配送
手続き」を選択して配送に係る操作を行う。具体的に
は、要望のあった１セット単位に機種番号（この段階で
は店員には機番は不明）とその台数を入力し、センタに
通知する。尚、ここで言う１セットとは、例えば複写機
Ａ、それに付加するソータ及びネットワークプリンタと
して機能する装置等がある場合には、それらのまとまり
を言う。

【００４８】センタは、上記機種番号（複数でも良い）
を受け付けるとそれをキーにして、機番管理マスタＤＢ
を検索する。検索された結果は、要請の合った販売店に
近い倉庫を優先してソートし、その結果を販売店の端末
に返す。このとき、各機種の機番が判明するので、機番
も併せて販売店端末に通知し、その結果を表示させる。

【００４９】販売店は、これを受けて、配送指示を行う
と、センタは該当する機番のうち、複写機の周辺機器で
ある機番データ中のリンク情報に、複写機の機番を書き
込み、複写機と周辺機器とのリンクを図る。そして、配
送日として、所定日数後（例えば翌日）になることを販
売店端末に通知すると共に、該当する倉庫の端末に発呼
し、該当する機番の装置を顧客宛に上記の配送日に配送
するよう要求する。

【００５０】尚、既に顧客で使用されている複写機に対
する周辺機器を配送手続きを行う場合もある。この場合
には、例えばその複写機の機種番号ではなく、機番を入
力し、それに接続する周辺機器の機種番号を上記のよう
にして入力する。

【００５１】センタは、複写機の機番が指定されること
で、該当する機番と、新規導入する周辺機器の機番との
リンクを張ることになる。

【００５２】図５は、最終的にセンタから販売店に通知
される配送処理結果の画面の一例を示している。図示に
おいて、「新」とは、新規導入機器であることを示して
おり、図示の場合には３つの製品とも同じ倉庫に在庫が
あって、２０００年４月２０日に配送手続きを行うこと
を示している。顧客が現に使用している複写機に対して
周辺機器を導入する場合には、その複写機については
「新」は表示されない。いずれにしても、複写機と周辺
機器とのリンクが確立することに変わりはない。

【００５３】センタのＤＢシステムにおけるＣＰＵ１の
動作処理としては、図６に示すフローチャートになろ
う。尚、以下は、販売店からのログインが完了して、
「配送手続き」が指示され、販売店より機種番号の通知
を行った場合の処理である。

【００５４】先ず、ステップＳ１において、販売店より
の情報を入力する。次いで、ステップＳ２に進み、該当
する機種を機番管理マスタＤＢから検索し、その販売店
に最寄りの機番データを抽出する。そして、ステップＳ
３に進み、配送可能日（ログイン日＋所定日数）を設定
し、ステップＳ４で、検索結果得られた機番と共に販売
店端末に通知し、ステップＳ５で販売店端末よりの返答
を待つ。

【００５５】ＯＫの指示があった場合には、ステップＳ
６に進み、配送依頼のあった各機番のリンクを張る処理
を行う。勿論、１台の複写機のみの場合には、この処理
は行わない。

【００５６】そして、ステップＳ７に進み、該当する機
番を管理している倉庫に対して機番と、配送予定日を通
知する。

【００５７】尚、上記例では、配送を行うときに、複写
機とその周辺機器とのリンクを行ったが、配送が完了し
た後に、各販売店は顧客に設置処理する際の接続状態か
ら選択にセットの機番を列挙し入力することで、リンク
の確立を図っても構わない。

【００５８】＜保守点検の説明＞次に、サービス店にお
ける保守点検に関して説明する。

【００５９】保守点検は、１セット単位に行われる。つ
まり、１つの複写機に、１乃至複数の周辺機器が接続さ
れた状態で使用されている場合には、それらをまとめて
保守点検対象とする。実施形態では、上記の通り、複写
機とその周辺機器とは、機番管理マスタＤＢ内ではリン
クされた状態で管理されているから、都合が良い。

【００６０】さて、保守サービスを行う店（以下、サー
ビス店）では、毎月、自店が管轄する複写機及びその周
辺機器について保守点検を行うスケジュールを立てる必
要がある。

【００６１】このため、サービス店側では端末からセン
タへ、自店ＩＤを用いてログインし、初期メニュー（不
図示）中の「保守サービス」を選択する。

【００６２】この結果、センタ側のシステムは、その店
ＩＤをサービス店ＩＤとして格納されているデータを検
索する。そして、得られた機番データ中の、前回保守日
にその保守サイクル（月数）を加算した月の、「保守
日」の欄に格納されている月日を算出し、それをソート
してサービス店の端末に通知する。このとき、周辺機器
が接続されている複写機については、その周辺機器も含
めて通知する。サービス店では、受信したデータを表示
もしくは印刷することになる。

【００６３】図７はその出力例を示している。図示の場
合、機番ＬＧＨ０６９３１に対しては、周辺機器である
機番ＸＹ１１２３３４及びＰＱ２４３３１０（例えばソ
ータやネットワーク接続装置）が接続されていることを
示している。

【００６４】サービス店側では、この出力結果を受け、
実際に行う保守点検日のスケジュールや、準備する器材
の準備を行うことになる。

【００６５】センタのＣＰＵ１は、上記処理を行う場合
には、図８に示すフローチャートに従って動作すること
になる。

【００６６】先ず、ステップＳ１１で、ログインに使用
したＩＤに合致するサービス店ＩＤを持つデータを機番
管理マスタＤＢから検索する。次いで、ステップＳ１２
において、得られたデータにある前回保守日に、保守サ
イクル（月）を加算した結果の年月を求め、残りの日に
ついては機番データ中の「保守日」を使用し、次回の保
守点検予定日を算出する。そして、ステップＳ１３に進
み、複写機本体とセットになる複写機とのリンク処理を
行い（複写機の機番＋周辺機器の機番の文字列を作成す
る）、ステップＳ１４でその結果を要求元のサービス店
の端末に通知する。

【００６７】尚、ログインした日以降に保守点検予定日
があるものと、それより前に予定日があるもの（保守点
検が未完のデータ）を識別可能（例えば色を替えると
か、別々にして表示する等）にして表示するようにして
もよい。

【００６８】また、保守点検が完了した場合には、セン
タにログインし、保守点検の完了手続きを行う。ここで
は、機番と、保守点検を行った日を入力し、センタに通
知する作業であるので、説明するまでもないであろう。
センタは、通知を受けた機番データ内の「前回保守日」
の欄を更新する。

【００６９】＜カウンタチェックの説明＞販売店員は、
顧客との契約で設定した時期になると、その顧客が有す
る複写機内のカウンタをチェックし、それをセンタに通
知する。センタはこれを受けて、前回のカウンタとの差
分から課金額を算定し、顧客に対して請求書を発行する
ことになる。ここでは、このカウンタチェックにおける
スケジュールについて説明する。

【００７０】販売店では、毎月、自店が管轄する複写機
についてカウンタチェックの作業のスケジュールを立て
る必要がある。

【００７１】このため、販売店側の端末からセンタへ、
自店ＩＤを用いてログインし、初期メニュー（不図示）
中の「カウンタチェック」を選択する。これにより、入
力画面が表示されるので、ここにデータを埋め込み、最
後に送信キー（図示せず）を押下する。

【００７２】センタ側のシステムは、上記内容を受信す
ると、その店ＩＤを販売店ＩＤとして格納されている機
番データを検索する。そして、得られた機番データ中
の、前回締め日の年月に、締めサイクルで示される月数
を加算する。そして、その加算結果の年月に「締め日」
の欄に格納されている日数を追加することで、最終的に
年月日を算出し、それを通知する。販売店側では、受信
したデータを表示もしくは印刷し、締め日に間に合うよ
う各顧客の複写機内のカウンタチェックを行う。

【００７３】尚、上記の販売店側における出力形態は、
先に示した図７と同様であり、それを出力するセンタ側
の処理も、上記の「保守点検の説明」からすれば容易に
理解できるであろうから、その説明は省略する。

【００７４】また、販売店が実際にカウンタチェックを
行った場合には、その機番と計数値を入力し、センタに
通知するだけでよい。

【００７５】図９は、この通知処理における画面の例を
示している。図示の如く、入力する項目は、機番、チェ
ック日、各カウンタの値で構成される。

【００７６】尚、先に説明したように、機番によりその
複写機がモノクロ複写機かどうか、及び、その複写機に
周辺装置としてパーソナルコンピュータのプリンタとし
て機能するネットワーク接続装置が接続されているかは
センタ側で把握できているので、例えばモノクロ複写機
である場合に、カラーのカウンタ値を入力しても無視さ
れる。

【００７７】また、この表示画面はセンタからの情報に
基づいて表示されるので、機番を先ず入力し、その後に
設定画面を送信するようにすれば、その機番に適したカ
ウンタの入力画面を送信することもできる。つまり、カ
ウンタ値を入力する個数も、その機番及び周辺機器の接
続形態に依存したものとすることができる。

【００７８】いずれにせよ、入力した内容をセンタに通
知すると、センタ側のシステムは該当する機番データ内
の今回値の中に、受信した値を書き込む処理を行う。

【００７９】この後、センタ側では、毎日、機番管理マ
スタＤＢ内の今回値の内容を調べ、それが格納されてい
る機番データを探し出す。そして、その機番データから
顧客ＩＤを抽出し、顧客に対して請求書を発行すること
になる。

【００８０】尚、請求書に対して、振り込みの通知が提
携金融機関よりあった場合、その今回のカウンタ値を前
回カウンタ値に書き込み、今回のカウンタ値をリセット
し、次回に備える。

【００８１】＜センタ側の管理の説明＞以上のように、
全販売店或いはサービス店からの情報により、各機番
（製品）のデータはその都度更新され、次回の業務に必
要な情報が構築することが可能であるが、各販売店やサ
ービス店の業務の効率化を図るための指針情報を構築
し、各店に通知することも可能になる。

【００８２】例えば、カウンタチェックを行うことで、
その顧客に対して請求書を発行する処理に移行すること
ができるものの、逆に、カウンタチェックを行わないと
業務上の収入がないことになる。

【００８３】上記のシステムにすることで、締め予定日
を過ぎても該当する機番（複写機）のカウンタの入力が
ないものを検索することは容易である。また、各機番デ
ータには、販売店のＩＤも含まれているので、販売店毎
の締め作業がどの程度進行しているのかを把握すること
も容易にできるようになる。

【００８４】そこで、センタでは、毎月、各販売店の締
め率（例えば前月に締めがあった顧客数を分母にし、締
めを行った顧客数を分子にした割合）を算出し、全ての
販売店或いは地域に含まれる店の締め率を閲覧可能にし
て作成する。

【００８５】販売店は、センタにログインした際に、そ
の閲覧を指示することで、例えば図１０に示すようなデ
ータがセンタから受信し、表示する。これにより、他の
販売店の業務の遂行と比較して自店の業務内容を把握で
きることが可能になり、業務遂行の１つの指標を与える
こともできるようになる。

【００８６】＜請求書発行処理＞次に、請求書発行処理
について、以下に詳述する。

【００８７】上述したように、顧客は、受領する請求書
のレイアウトに様々な要望があるので、請求書ＤＢに
は、予め多数の請求書フォームを用意し管理しておく。
その一例を、以下の図１１に示す。

【００８８】図１１（ａ）に示すように、請求書は、請
求先に対し、機番単位で請求書を出力する。つまり、請
求先が抱えている複写機やその周辺機器の各機番の数だ
け、請求書が発行される。

【００８９】また、請求先によっては、自身が抱えてい
る複写機やその周辺機器に対する請求を一括して受領し
たい場合もある。そこで、図１１（ｂ）に示すように、
請求先が抱えている複写機やその周辺機器に対する請求
をまとめ、それを１枚の請求書にして発行する。

【００９０】更に、複数の部署を有する企業等では、各
部署が抱えている複写機やその周辺機器に対する請求を
一括して受領し、尚かつ、各部署の請求内訳を把握した
い場合もある。そこで、図１１（ｃ）に示すように、請
求先の各部署が抱えている複写機やその周辺機器に対す
る請求を、各部署毎にまとめ、更に、それらを１枚の請
求書にして発行する。

【００９１】これ以外にも、支店や支所毎の請求を１枚
の請求書にして発行したり、複写機１台毎、複数台毎、
部署や支店、支所、課、人（担当者）等の所定単位毎
に、それぞれの請求書にして発行したりすることが可能
である。もちろん、この場合は、請求書ＤＢに必要な請
求書フォームが用意されていることは言うまでもない。
また、顧客によっては、請求書に用いる印刷用紙のサイ
ズや、印刷枚数、向き（Ａ４縦、Ａ４横等）等を要望す
る場合があるので、請求書フォームに、印刷用紙のサイ
ズ、印刷枚数、向き等を指定する印刷情報を付加し、こ
の印刷情報に基づく印刷が可能なプリンタから請求書を
印刷するようにすることもできる。

【００９２】尚、これらの請求書フォームは、各フォー
ム毎に請求書フォーム番号が付加されており、この請求
書フォーム番号は、顧客ＩＤに対応する顧客情報とし
て、顧客ＤＢに管理されている。

【００９３】請求書の発行は、基本的には、販売店が行
い、各販売店に用意されている端末を用いて行う。請求
書を発行する場合、販売店は、まず、請求書を発行する
ための専用画面（請求書発行画面）を端末上で表示す
る。請求書発行画面には、顧客名、管轄のサービス店
名、販売店名、請求先名、顧客が抱えている複写機やそ
の周辺機器の機番、機種番号、請求書フォーム番号等を
表示／入力する領域を有している。その画面例を、図１
２に示す。但し、この画面例は、あくまでも一例であ
り、必要に応じて各種情報を表示／入力するための領域
を構成できることは言うまでもない。

【００９４】この図１２を用いて、請求書発行画面を構
成する各領域について説明する。

【００９５】図１２において、１２００は顧客ＩＤを入
力する領域であり、ここに、顧客ＩＤを入力すると、顧
客ＩＤに対応づけて顧客ＤＢで管理されている顧客情報
（例えば、顧客名、請求書フォーム番号、機番、機種番
号等）が検索され、顧客名が領域１２０１、請求書フォ
ーム番号が領域１２０３、機番、機種番号が領域１２０
５にそれぞれ呼び出される。また、ボタン１２０４は、
請求書フォーム番号を変更する場合に使用し、このボタ
ン１２０４を操作すると、現在使用可能な請求書フォー
ム番号のリストが表示され、所望の請求書フォーム番号
を選択して入力することができる。１２０２は販売店員
が所属している販売店、サービス店等を表示する領域で
ある。

【００９６】同様に、領域１２０５の各請求項目の欄に
は、ボタン１２０４と同等の機能を果たすボタンが用意
されており、販売店員は、これらのボタンを操作する
と、頻繁に使用する請求項目のリストが表示され、所望
の請求項目を選択して入力することができる。もちろ
ん、直接手入力で、所望の請求項目を入力することも可
能である。また、選択されたあるいは入力された請求項
目が、特に、複写機の複写枚数を示すカウンタ値の場合
は、上述の機番管理マスタＤＢで管理されている機番Ｉ
Ｄに対応する請求対象のカウンタ値と複写機のコピー単
価と上述したジャムエラー率等を考慮した所定比率を参
照して、今回請求する請求代金を自動計算して請求代の
欄に表示する。それ以外にも、自動計算が可能な請求項
目に関しては、同様に、自動計算して請求代の欄に表示
し、そうでない請求項目に関しては、販売店員が直接請
求代の欄に請求代金を入力する。

【００９７】１２０６は請求書作成ボタンであり、領域
１２０５に必要な各請求項目毎の請求代金を入力した後
に、この請求書作成ボタン１２０６を操作すると、指定
された請求書フォーム番号に対応する請求書フォームを
請求書ＤＢから取得し、また、請求書番号や請求代の入
金を行うための請求先コード、入金確定／未確定を示す
入金確定／未確定フラグ等の請求書管理情報をセンタか
ら取得して、取得した請求書フォーム、請求書管理情
報、請求書発行画面で入力された請求書データ（請求項
目、請求代等）に基づいて請求書を作成し印刷する。同
時に、請求書データ及び請求書管理情報は、請求書ＤＢ
に顧客毎に管理される。また、請求書を作成した旨をセ
ンタに通知し、この通知に基づく処理をセンタは実行す
る。

【００９８】以上の請求書発行処理のフローチャートを
示すと、図１３のようになる。以下同フロー参照して、
図１及び図２に示すセンタのシステムの作動を説明す
る。

【００９９】まず、ステップＳ１３０１で、販売店員は
請求書発行画面を販売店の端末上に表示させる。ステッ
プＳ１３０２で、端末より入力された情報をセンタＣＣ
側に請求先の顧客ＩＤを入力する。ステップＳ１３０３
で、入力された顧客ＩＤに基づいて、センタＣＣのＣＰ
Ｕは請求書発行画面に表示された請求対象の機番に対
し、それぞれ請求項目、請求代を入力あるいは自動計算
し、端末側の請求書作成ボタンを操作する。ステップＳ
１３０４で、指定された請求書フォームに対応する請求
書フォームを請求書ＤＢから取得し、取得した請求書フ
ォームと請求書発行画面で入力された請求書データ、更
にセンタＣＣが生成する請求書管理情報に基づいて請求
書を作成し、端末のプリンタで印刷する。一方で、セン
タＣＣ側では、処理対象の請求書に対する請求書管理情
報（請求書番号、請求先コード、入金確定／未確定フラ
グ等）を生成しており、処理対象の請求書のデータと対
応づけて請求書ＤＢに記憶して登録する。

【０１００】＜自動入金処理＞次に、自動入金処理につ
いて説明する。これは、発行した請求書に対する請求先
からの入金を確認し、確定する処理である。

【０１０１】請求先からの入金には、様々な入金形態が
あり、例えば、自動振替、銀行振込、集金等がある。特
に、入金が銀行振込の場合には、請求先の振込時の振込
人名称には、その振込処理を行う人間によって異なる場
合が多々ある。例えば、カタカナ株式会社の振込人名称
としては、その振込人によって「カタカナ（カブ）」で
あったり、「カタカナカブシキカイシャ」であったりす
る。

【０１０２】そのため、請求先からの入金を確認する販
売店では、確認用の請求先の振込人名称（基本振込人名
称）が１つだけしか存在しないと、処理対象の入金の振
込人名称が１字でも違ってしまうと、正しい請求先から
の入金であっても、それを正しいと認識することができ
ない。そこで、請求先の振込人名称が複数種類存在する
ことがあることを考慮して、基本振込人名称以外に、そ
れと同じものとみなせる振込人名称が発生する毎に、そ
の基本振込人名称に対応する振込人名称として逐次登録
し管理する上述の名寄せＤＢを構成する。つまり、この
名寄せＤＢを参照し、処理対象の入金の振込人名称と一
致する振込人名称が存在すれば、正しい請求先からの入
金であるものとして、以降の処理を進めることができ
る。

【０１０３】ここで、名寄せＤＢのデータフォーマット
について、図１４に示す。

【０１０４】図１４に示すように、各顧客ＩＤ毎に、基
本振込人名称が対応づけてられており、更に、基本振込
人名称以外で振込人名称として用いられる可能性がある
振込人名称のグループとして名寄せ項目に登録されてい
る。この名寄せ項目に登録される振込人名称は、事前に
顧客から通知を受けた振込人名称であったり、販売店員
が顧客に対して確認した振込人名称であったりする。

【０１０５】次に、自動入金処理処理の詳細について、
以下、説明する。

【０１０６】センタあるいは販売店は、定期的に提携金
融機関に対して入金確認を行い、なにかしらの入金があ
った場合には、その入金に関する入金データ（請求コー
ド、それに付随する振込人名、入金日、入金額）を取得
することができる。但し、請求コードの入力は、請求先
に依存してしまうので、必ず入金データに対して存在す
るものではない。

【０１０７】次に、自動入金処理の詳細について、以
下、説明していく。

【０１０８】上述の自動入金処理を実行する場合、販売
店は、まず、処理対象の入金を確認するための専用画面
（自動入金確認画面）を端末上で表示する。自動入金確
認画面には、請求先を示す請求先コード、振込人名、入
金日、入金額、管轄のサービス店名、販売店名等を表示
／入力する領域を有している。その画面例を図１５に示
す。但し、この画面例は、あくまでも一例であり、必要
に応じて各種情報を表示／入力するための領域を構成で
きることは言うまでもない。

【０１０９】この図１５を用いて、自動入金確認画面を
構成する各領域について説明する。

【０１１０】図１５において、入金データを取得する
と、その入力データから得られる各種データが指定の領
域に呼び出される。１５０１は請求先コードを表示する
領域であり、１５０２は振込人名を表示する領域１５０
２、１５０３が入金日を表示する領域１５０３、１５０
４が入金額を表示する領域１５０４である。但し、上述
したように、入金データ中には請求コードは必ずしも存
在しないので、そのような場合は、販売店員が適宜、必
要な情報を各領域に入力する。もちろん、集金等で現金
で請求代を領収した場合には、販売店員が必要な情報を
各領域に入力する。１５０５は販売店員が所属している
販売店、サービス店等を表示する領域である。

【０１１１】１５０６は入金チェックボタンであり、上
記の各領域に必要な情報が入力された後に、この入金チ
ェックボタン１５０６を操作すると、処理対象の入金が
正しい請求先からのものであるか否かをチェックし、そ
のチェック結果に応じて処理を実行する。

【０１１２】以下、この入金チェックを含む自動入金処
理のフローチャートを図１６に示す。以下同フロー及び
図１、２を参照して、動作を説明する。

【０１１３】ます、ステップＳ１６０１で、販売店員
は、販売店の端末上に表示させた自動入金確認画面に対
し、端末からの入金処理対象の入金データをセンタＣＣ
のシステムに入力する。ステップＳ１６０２で、端末か
ら自動入金確認画面内の入金チェックボタンが操作され
たかをチェックする。ステップＳ１６０２で、自動入金
確認画面に請求コードが入力されているか否かを端末、
センタＣＣがチェックする。請求コードがある場合、ス
テップＳ１６０５に進む。一方、請求コードがない場
合、ステップＳ１６０３に進む。

【０１１４】ステップＳ１６０３で、センタＣＣのＣＰ
Ｕは振込人名称が名寄せＤＢに存在するか否かを判定す
る。存在する場合、ステップＳ１６０５に進む。一方、
存在しない場合、ステップＳ１６０４に進み、センタＣ
ＣのＣＰで新規振込人名称に対応する基本振込人名称を
決定し、名寄せＤＢに記憶して登録する。

【０１１５】ステップＳ１６０５で、入金額をチェック
する。このチェックは、ステップＳ１６０５に到達する
までの上記ステップ群の経路によって、処理内容が異な
っている。

【０１１６】まず、ステップＳ１６０２からステップＳ
１６０５に到達した場合、つまり、請求先コードが存在
する場合には、センタＣＣのＣＰＵで請求コードに対応
する請求先の未処理の請求代と入金額を比較する。この
比較の結果、請求代と入金額が一致する場合、ステップ
Ｓ１６０７に進み、正しい入金が行われたものとして、
その入金を確定し、センタＣＣのＣＰＵで、その入金に
対する請求書に対応する請求書管理情報の入金確定／未
確定フラグを確定状態にする。一方、一致しない場合、
ステップＳ１６０６に進み、その入金は未処理とし、ま
た、センタＣＣのＣＰＵで入金に対する請求書に対応す
る請求書管理情報の入金確定／未確定フラグを未確定状
態にする（但し、入金確定／未確定フラグは、初期状態
で、未確定状態になっているので、実際には、この未確
定状態にするための処理は行われない）。その後、後述
する未処理入金一覧を出力する。

【０１１７】また、ステップＳ１６０３からステップＳ
１６０５に到達した場合、つまり、請求先コードが存在
せず、名寄せＤＢに登録されている振込人名称である場
合には、センタＣＣのＣＰＵでその振込人名称に対応す
る基本振込人名称の請求先で、未処理の請求代と入金額
を比較する。この比較の結果、請求代と入金額が一致す
る場合、ステップＳ１６０７に進み、正しい入金が行わ
れたものとして、その入金を確定し、センタＣＣのＣＰ
Ｕでその入金に対する請求書に対応する請求書管理情報
の入金確定／未確定フラグを確定状態にする。一方、一
致しない場合、ステップＳ１６０６に進み、その入金は
未処理とし、また、センタＣＣのＣＰＵで入金に対する
請求書に対応する請求書管理情報の入金確定／未確定フ
ラグを未確定状態にする（但し、入金確定／未確定フラ
グは、初期状態で、未確定状態になっているので、実際
には、この未確定状態にするための処理は行われな
い）。その後、後述する未処理入金一覧を出力する。

【０１１８】また、ステップＳ１６０４からステップＳ
１６０５に到達した場合、つまり、請求先コードが存在
せず、名寄せＤＢに新規な振込人名称が登録された場合
には、その振込人名称に対応する基本振込人名称の請求
先で、未処理の請求代と入金額を比較する。この比較の
結果、請求代と入金額が一致する場合、ステップＳ１６
０７に進み、正しい入金が行われたものとして、その入
金を確定し、その入金に対する請求書に対応する請求書
管理情報の入金確定／未確定フラグを確定状態にする。
一方、一致しない場合、ステップＳ１６０６に進み、そ
の入金は未処理とし、また、センタＣＣのＣＰＵで入金
に対する請求書に対応する請求書管理情報の入金確定／
未確定フラグを未確定状態にする。その後、後述する未
処理入金一覧を表示装置あるいはプリンタに出力する。

【０１１９】上述したように、ステップＳ１６０６で、
処理対象の入金が未確定となると、未確定の入金群を一
覧にした未処理入金一覧を生成し出力する。この未処理
入金一覧は、未確定の入金群が所定数以上発生した後に
出力するようにしても構わないし、未確定の入金が発生
する毎に逐次その未処理入金一覧に出力するようにして
も構わない。ここでいう出力とは、端末上の表示装置へ
の出力、端末に接続されるプリンタへの出力、端末に接
続されるネットワークへの出力等を含む。

【０１２０】図１６における自動入金処理における請求
先を特定するための各種判定は（例えば、ステップＳ１
６０２、ステップＳ１６０３等）は、これに限定される
ものではない。より精度を高めるために、例えば、振込
人である請求先の振込銀行や、電話番号、住所等の振込
人である請求先を特定できる情報に関する判定を適宜追
加することができる。

【０１２１】＜変形例＞上述した請求書発行処理は、販
売店側が印刷した請求書を請求先である顧客に送付する
構成としたが、この請求書を電子データ（電子請求書）
として、例えば、インターネット等のネットワークを介
して顧客に送信するような構成にすることもできる。但
し、電子請求書の正当性及び秘匿性を維持し、証明する
ために、例えば、電子請求書は既存の電子署名技術を用
いて販売店と顧客間で送受信する。また、汎用性及び利
便性を高めるため、電子請求書（例えば、図１７）には
販売店の公開鍵を管理する認証局（例えば、日本ベリサ
イン社等の第三者認証機関）のネットワーク上のアドレ
ス（例えば、ＵＲＬ）を記述しておき、顧客は受信した
電子請求書に記述されている認証局へアクセスして販売
店の公開鍵を取得させるように構成する。

【０１２２】以下、その具体例を図１８を用いて説明す
る。

【０１２３】販売店は、認証局から顧客の公開鍵を受信
し、その公開鍵を用いて電子請求書を暗号化し、生成さ
れる暗号文を顧客へ送信する。同時に、電子請求書をハ
ッシュ関数を用いて回復不能文を作成し、これを販売店
自身の秘密鍵を用いて回復不能文を暗号化し、生成され
る回復不能暗号文を顧客へ送信する。

【０１２４】一方、顧客は、受信した電子請求書の暗号
文を顧客自身の秘密鍵を用いて復号化し、電子請求書を
取得する。また、この電子請求書は、ハッシュ関数を用
いて回復不能文を作成する。次に、取得した電子請求書
に記述されている認証局へアクセスし、販売店の公開鍵
を取得し、別途販売店から受信した回復不能文をその公
開鍵を用いて復号化し、回復不能文を復元する。そし
て、この回復不能文と既にハッシュ関数を用いて作成し
た回復不能文とを比較し、一致していれば、改善されて
いない正規の請求書として判断することができる。

【０１２５】尚、図１８では、ネットワークを介して販
売店から顧客へ電子請求書を送信するような構成とした
が、上述したセンタに各販売店からの電子請求書を一旦
を収集し、センタから各顧客へ送信するようにすること
もできる。このようにすることで、各販売店で発行され
る電子請求書をセンタで一元管理することができ、より
効率的に処理を行うことができる。

【０１２６】尚、上記実施形態における各倉庫や販売店
等に設置される端末、及び、センタに設置されるサーバ
は、基本的に汎用の情報処理装置やワークステーション
等で構成することが可能である。

【０１２７】つまり、本発明は、上記実施形態を実現す
るための装置及び方法及び実施の形態で説明した方法を
組み合わせて行う方法のみに限定されるものではなく、
上記システム又は装置内のコンピュータ（ＣＰＵあるい
はＭＰＵ）に、上記実施の形態を実現するためのソフト
ウエアのプログラムコードを供給し、このプログラムコ
ードに従って上記システムあるいは装置のコンピュータ
が上記各種デバイスを動作させることにより上記実施の
形態を実現する場合も本発明の範疇に含まれる。

【０１２８】また、この場合、前記ソフトウエアのプロ
グラムコード自体が上記実施の形態の機能を実現するこ
とになり、そのプログラムコード自体、及びそのプログ
ラムコードをコンピュータに供給するための手段、具体
的には上記プログラムコードを格納した記憶媒体は本発
明の範疇に含まれる。

【０１２９】この様なプログラムコードを格納する記憶
媒体としては、例えばフロッピー（登録商標）ディス
ク，ハードディスク，光ディスク，光磁気ディスク，Ｃ
Ｄ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，Ｒ
ＯＭ等を用いることができる。

【０１３０】また、上記コンピュータが、供給されたプ
ログラムコードのみに従って各種デバイスを制御するこ
とにより、上記実施の形態の機能が実現される場合だけ
ではなく、上記プログラムコードがコンピュータ上で稼
働しているＯＳ（オペレーティングシステム）、あるい
は他のアプリケーションソフト等と共同して上記実施の
形態が実現される場合にもかかるプログラムコードは本
発明の範疇に含まれる。

【０１３１】更に、この供給されたプログラムコード
が、コンピュータの機能拡張ボードやコンピュータに接
続された機能拡張ユニットに備わるメモリに格納された
後、そのプログラムコードの指示に基づいてその機能拡
張ボードや機能格納ユニットに備わるＣＰＵ等が実際の
処理の一部または全部を行い、その処理によって上記実
施の形態が実現される場合も本発明の範疇に含まれる。

【０１３２】

【発明の効果】以上説明したように本発明によれば、保
守サービスを必要とする機器について、その製造段階か
ら廃棄或いは再利用されるまでを管理し、各販売店に対
して有効な情報の提供し、事業の効率化を図ることが可
能になる。

【図面の簡単な説明】

【図１】実施形態における製品管理システムにおける全
体構成と製品及び情報の流れを模式的に示す図である。

【図２】実施形態におけるセンタにおける装置のブロッ
ク構成図である。

【図３】実施形態における機番管理マスタデータベース
におけるデータフォーマットを示す図である。

【図４】機番管理マスタデータベースにおける機番デー
タの表示画面の一例を示す図である。

【図５】配送手続きの通知画面の例を示す図である。

【図６】センタ側における配送手続き処理手順を示すフ
ローチャートである。

【図７】保守点検予定一覧の表示例を示す図である。

【図８】センタ側における保守点検予定一覧を作成する
処理手順を示すフローチャートである。

【図９】実施形態におけるカウンタ入力画面の一例を示
す図である。

【図１０】実施形態における各点の締め率一覧の出力例
を示す図である。

【図１１】実施形態における請求書フォームの構成例を
示す図である。

【図１２】実施形態における請求書発行画面の一例を示
す図である。

【図１３】販売店側における請求書発行手順を示すフロ
ーチャートである。

【図１４】実施形態における名寄せＤＢのデータフォー
マットを示す図である。

【図１５】実施形態における自動入金確認画面の一例を
示す図である。

【図１６】販売店側における自動入金手順を示すフロー
チャートである。

【図１７】実施形態における電子請求書の一例を示す図
である。

【図１８】実施形態における電子署名技術を用いた電子
請求書の発行例を示す図である。

Claims

【特許請求の範囲】

【請求項１】保守サービス対象の機器及びその周辺機
器に対し、それら機器製造後の初期段階で付与された個
々の機器を特定する機番情報を入力する第１の端末と、販売店及び保守サービス店に設置された第２の端末と、処分所に設置された第３の端末と、前記第１乃至第３の端末との通信を行い、機器管理を行
うセンタサーバとを備える製品管理システムであって、前記センタサーバは、前記第１の端末からの登録の指示があった場合、当該第
１の端末より受信した前記機番情報を主情報とする機器
管理データをデータベースに登録する手段と、前記第２の端末から顧客への納品指示があった場合に、
当該要求された機器の配送手続きを行い、搬送される機
器の機器番号を有するデータ中の所有者を示す領域に、
前記顧客を特定する情報で更新する手段と、前記第３の端末から廃棄処分或いは再生処理の通知を受
けた場合、前記データベースから該当する機番情報を持
つデータを抹消する手段とを備え、再生処理が施されたことを通知を受けた場合、当該再生
処理後の機器について新規の機番情報を付与し、前記デ
ータベースに登録することを特徴とする機器管理システ
ム。
【請求項２】前記センタサーバが管理する機番情報の
データには、当該機器の販売店及び保守サービスを行う
店を特定する情報と、顧客との契約でなされた保守点検
のスケジュールに関する情報を格納する領域を有するこ
とを特徴とする請求項第１項に記載の機器管理システ
ム。
【請求項３】前記センタサーバは、前記第２の端末か
ら要求があった場合、当該第２の端末を有するサービス
店が管理する機番情報を検索し、次回の保守点検予定日
の一覧を当該第２の端末に対して通知する手段を備える
ことを特徴とする請求項第２項に記載の機器管理システ
ム。
【請求項４】前記保守サービス対象の機器は複写機で
あって、前記センタサーバが管理する機番情報のデータ
には、複写機の累積印刷枚数を記憶する領域が備えられ
ることを特徴とする請求項第１項乃至第３項のいずれか
１項に記載の機器管理システム。
【請求項５】前記センタサーバは、前記第２の端末か
ら要求があった場合、当該第２の端末を有する販売店が
管理する機番情報を検索し、次回の印刷枚数のチェック
予定日一覧を当該第２の端末に対して通知する手段を備
えることを特徴とする請求項第４項に記載の機器管理シ
ステム。
【請求項６】前記累積印刷枚数には、モノクロ／カラ
ーの種別、更には、情報処理装置用のプリンタとして機
能した場合のモノクロ／カラーの種別それぞれ毎の、記
録紙サイズの違いによる累積印刷枚数が含まれることを
特徴とする請求項第５項に記載の機器管理システム。
【請求項７】保守サービス対象の機器及びその周辺機
器に対し、それら機器製造後の初期段階で付与された個
々の機器を特定する機番情報を入力する第１の端末と、販売店及び保守サービス店に設置された第２の端末と、処分所に設置された第３の端末と、前記第１乃至第３の端末との通信を行い、機器管理を行
うセンタサーバとを備える製品管理システムの制御方法
は、前記第１の端末からの登録の指示があった場合、当該第
１の端末より受信した前記機番情報を主情報とする機器
管理データをデータベースに登録する工程と、前記第２の端末から顧客への納品指示があった場合に、
当該要求された機器の配送手続きを行い、搬送される機
器の機器番号を有するデータ中の所有者を示す領域に、
前記顧客を特定する情報で更新する工程と、前記第３の端末から廃棄処分或いは再生処理の通知を受
けた場合、前記データベースから該当する機番情報を持
つデータを抹消する工程とを備え、再生処理が施されたことを通知を受けた場合、当該再生
処理後の機器について新規の機番情報を付与し、前記デ
ータベースに登録することを特徴とする機器管理システ
ムの制御方法。
【請求項８】請求項７に記載の各工程のプログラムコ
ードを格納する記憶媒体。
【請求項９】請求項７に記載の各工程で構成されるコ
ンピュータにより実行可能なコンピュータプログラム。