(57)【特許請求の範囲】
【請求項１】
各保守サービス店が保守点検をする対象の主機器及びその周辺機器の前記保守点検のスケジュールを、一元管理する機器管理システムであって、
前記各保守サービス店の端末と通信する通信手段と、
前記主機器に対してユニークに付与された機番情報と、前記主機器に対して保守サービスを行う保守サービス店を特定する保守サービス店情報と、前回保守点検を行った保守点検実施日とを保持するデータベースと、
主機器に接続する周辺機器情報を受け付ける受付手段と、
前記受け付けた周辺機器情報を前記主機器の機番情報とリンクさせて管理する管理手段と、
前記保守サービス店の端末から、保守サービス店情報を含む次回の保守点検予定日の問い合わせがあったとき、当該保守サービス店の保守サービス店情報をキーにして前記データベースを検索する検索手段と、
前記検索手段により得られた機番情報の前回の保守点検実施日に保守サイクルを加算し、次回の保守点検予定日を算出する算出手段と、
前記検索手段が検索した該当する機器に、前記算出手段が算出した次回の保守点検予定日と、保守点検対象となる主機器の機番情報及び前記管理手段が管理する当該主機器に接続される周辺機器情報とをセットにしたリストを次回の保守点検予定日でソートし、前記通信手段を介して、問い合わせ元の保守サービス店の端末に通知する通知手段と、
を備えることを特徴とする機器管理システム。
【請求項２】
更に、前記サービス店の端末より保守点検の完了通知を前記通信手段より受けた場合、該当する機器の前回保守点検実施日を更新する手段を備えることを特徴とする請求項第１項に記載の機器管理システム。
【請求項３】
前記主機器は複合機であることを特徴とする請求項１又は請求項２のいずれか１項に記載の機器管理システム。
【請求項４】
各保守サービス店の端末と通信する通信手段と、主機器に対してユニークに付与された機番情報、前記主機器に対して保守サービスを行う保守サービス店を特定する保守サービス店情報、並びに、前回保守点検を行った保守点検実施日を保持するデータベースとを有し、前記各保守サービス店が保守点検する対象の主機器及びその周辺機器を、一元管理する機器管理システムの制御方法であって、
受付手段が、主機器に接続する周辺機器情報を受け付ける受付工程と、
管理手段が、前記受け付けた周辺機器情報を前記主機器の機番情報とリンクさせて管理する管理工程と、
検索手段が、前記保守サービス店の端末から、保守サービス店情報を含む次回の保守点検予定日の問い合わせがあったとき、当該保守サービス店の保守サービス店情報をキーにして前記データベースを検索する検索工程と、
算出手段が、前記検索工程により得られた機番情報の前回の保守点検実施日に保守サイクルを加算し、次回の保守点検予定日を算出する算出工程と、
通知手段が、前記検索工程で検索した該当する機器に、前記算出工程で算出した次回の保守点検予定日と、保守点検対象となる主機器の機番情報及び前記管理工程で管理する当該主機器に接続される周辺機器情報とをセットにしたリストを次回の保守点検予定日でソートし、前記通信手段を介して、問い合わせ元の保守サービス店の端末に通知する通知工程と、
を有することを特徴とする機器管理システムの制御方法。
【請求項５】
各保守サービス店の端末と通信する通信手段と、主機器に対してユニークに付与された機番情報、前記主機器に対して保守サービスを行う保守サービス店を特定する保守サービス店情報、並びに、前回保守点検を行った保守点検実施日を保持するデータベースとを有するコンピュータに読み込ませ実行させることで、前記コンピュータを、前記各保守サービス店が保守点検する対象の主機器及びその周辺機器を、一元管理する機器管理システムとして機能させるコンピュータプログラムであって、
前記コンピュータを、
主機器に接続する周辺機器情報を受け付ける受付手段、
前記受け付けた周辺機器情報を前記主機器の機番情報とリンクさせて管理する管理手段、
前記保守サービス店の端末から、保守サービス店情報を含む次回の保守点検予定日の問い合わせがあったとき、当該保守サービス店の保守サービス店情報をキーにして前記データベースを検索する検索手段、
前記検索手段により得られた機番情報の前回の保守点検実施日に保守サイクルを加算し、次回の保守点検予定日を算出する算出手段、
前記検索手段で検索した該当する機器に、前記算出手段で算出した次回の保守点検予定日と、保守点検対象となる主機器の機番情報及び前記管理工程で管理する当該主機器に接続される周辺機器情報とをセットにしたリストを次回の保守点検予定日でソートし、前記通信手段を介して、問い合わせ元の保守サービス店の端末に通知する通知手段、
として機能させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は機器管理システム及びその制御方法及びコンピュータプログラムに関するものである。
【０００２】
【従来の技術】
ＯＡ製品、特に、複写機を例にして説明する。
【０００３】
一般に、メーカの工場で複写機が製造されると、先ず、中継倉庫に搬送されそこで管理される。また、この中継倉庫から、地方にある各中継倉庫に搬送されることもある。販売店に顧客がついた場合、その販売店は所定の手続きを行い、最寄りの倉庫から顧客まで搬送及び設置作業を行い、メンテナンス等についての契約を交わす。以後、この契約に従い、定期的なメンテナンス（保守点検）、及び、複写枚数のチェックを行うことになる。
【０００４】
メンテナンス及び複写枚数のチェックは、その顧客にとって最寄りのサービス店員又は販売店員が行うことになり、その課金による請求書も販売店単位に行うことになる。
【０００５】
しかしながら、例えば国内全域の販売店の数は膨大であり、且つ、メンテナンス及び複写枚数のチェックのスケジュールの管理、及び、請求書の発行の管理は相当の時間と労力を必要とする。従って、かかる管理を各販売店毎に独立して行うようにすると、国内全体の販売店のそれに費やす時間及び労力は、販売店の数に比例したものとなり、膨大なものとなる。
【０００６】
そこで、中枢となるセンタを設け、ここで全ての製品を管理するシステムが考えられる。かかるシステムにすると、販売店とセンタとは回線を介してデータ授受を行い、販売店側としては専ら簡単なデータ入力を行うだけとなり、メンテナンス及び複写枚数のチェックのスケジュールもセンタ側で行い、販売店側はこれを閲覧するだけで済むことになる。また、請求書にしても、センタが発送元となって、顧客に請求書を郵送する等で対処すれば良いので、販売店の負担も軽減でき、しかも、全ての販売店で共通した仕事環境を提供できることにより、作業の効率化も進むことになる。
【０００７】
【発明が解決しようとする課題】
ところで、一般に複写機と言っても、単独で使用するよりは、その周辺機器、例えば、オートフィーダ、ソータ（ステイプル機能の有／無も含む）、ネットワークプリンタとして機能するネットワーク接続装置等と共に使用することが多い。また、１つの顧客が複数の複写機を備えることも当然にあり得る。
【０００８】
従って、保守点検を行う場合であっても、その顧客の使用環境に適した準備をしてから行うことが望まれる。
【０００９】
かかる作業は、全国のサービス店の数だけ存在することになり、それに費やす時間のトータルは、もはや無視できないものである。
【００１０】
そこで、本発明は、各サービス店（販売店兼用の場合も当然にあり得る）が管理する機器を一元管理すると共に、複写機等の主機器とその周辺機器の使用状況を含めた、スケジュール管理を行い、その情報をサービス店に提供することを可能ならしめる機器管理システム及びその制御方法及びコンピュータプログラムを提供しようとするものである。
【００１１】
【課題を解決するための手段】
この課題を解決するため、例えば機器管理システムは以下の構成を備える。すなわち、
各保守サービス店が保守点検をする対象の主機器及びその周辺機器の前記保守点検のスケジュールを、一元管理する機器管理システムであって、
前記各保守サービス店の端末と通信する通信手段と、
前記主機器に対してユニークに付与された機番情報と、前記主機器に対して保守サービスを行う保守サービス店を特定する保守サービス店情報と、前回保守点検を行った保守点検実施日とを保持するデータベースと、
主機器に接続する周辺機器情報を受け付ける受付手段と、
前記受け付けた周辺機器情報を前記主機器の機番情報とリンクさせて管理する管理手段と、
前記保守サービス店の端末から、保守サービス店情報を含む次回の保守点検予定日の問い合わせがあったとき、当該保守サービス店の保守サービス店情報をキーにして前記データベースを検索する検索手段と、
前記検索手段により得られた機番情報の前回の保守点検実施日に保守サイクルを加算し、次回の保守点検予定日を算出する算出手段と、
前記検索手段が検索した該当する機器に、前記算出手段が算出した次回の保守点検予定日と、保守点検対象となる主機器の機番情報及び前記管理手段が管理する当該主機器に接続される周辺機器情報とをセットにしたリストを次回の保守点検予定日でソートし、前記通信手段を介して、問い合わせ元の保守サービス店の端末に通知する通知手段と、を備える。
【００１２】
【発明の実施の形態】
以下、添付図面に従って本発明にかかる実施形態を詳細に説明する。
【００１３】
実施形態では、メンテナンス（保守点検）を必要とする製品の中の代表的な複写機及びそれに付随可能な周辺機器（ソータ、ネットワークプリンタとして機能する装置等）を例にして説明する。
【００１４】
＜全体の構成とその流れ＞
先ず、複写機の製造に始まる一連の製品の流れ及び実施形態におけるシステムの全体の動作を説明する。
【００１５】
複写機及びそれに接続可能な周辺機器が製造されると、それぞれユニークな機番（モデル名も判別可能な文字列）が付加され、中央倉庫に一旦に搬送される。中央倉庫では、搬送されてきた機番、及びその搬入日（もしくは製造日）をサブセンタのＤＢ（データベース）に登録する。サブセンターに登録されたデータベース中の新規に登録された製品情報は、例えば一日に一回という頻度で、センタに設けられたサーバに通知される。センタはこれを受け、製品一つ一つに対する基礎フォームに、その製品のデータを登録する。これ以降、各製品に関する流通にかかる情報は、この基礎フォームを更新することで一元管理されることになる。すなわち、全ての国内販売店で販売される複写機の管理が開始する。
【００１６】
尚、上記例では、中央倉庫に搬入されることをトリガにして、サブセンタ→センタへとデータの登録がなされるものとしたが、製造工場から出荷する際にサブセンタもしくはセンタに登録するようにしても構わない。
【００１７】
また、一旦、サブセンタにデータをストアしてからセンタサーバにまとめて転送するのは、１つ１つの製品に搬入される度に送信するようにしてしまうと、回線使用回数が増えることによる通信費増大するためである。
【００１８】
また、センタには、各製品を管理する上で、機番とモデル名との対応を示すＤＢ、顧客や販売店を管理するＤＢ等、複数のＤＢが稼動している。ここで言う、センタにおけるＤＢとは、ＤＢシステムがそれぞれ独立した分散型システムでも良いし、１つのＤＢシステム内に複数のＤＢを構築しても良い。要は互いに関連する環境で全体のシステムを構築するものであればよい。
【００１９】
さて、中央倉庫から、更に、地方の主だった倉庫に搬送される。各地方への搬送する台数は、各倉庫の規模や各地方の顧客数等を勘案されて行われる。配送手続きを行う者は、例えばハンディターミナルを用いて、製品に付加された機番と配送先の倉庫のコードを入力し（一般にバーコードを読み取る等して入力）、そのハンディターミナルに格納されたデータを所定の端末に転送することで、最終的にセンターに通知する。センタＤＢはこの通知を受け、各製品の所在位置を更新する。
【００２０】
一方、販売店側には、センタと通信する端末が設置してあって、その動きは次のようになる。
【００２１】
先ず、顧客から要望があった場合、その機種が最寄りの地方倉庫或いは中央倉庫に存在するか否かをセンタに対して問い合わせをする。センタは、全ての複写機並びにその周辺機器（以下、単に特に断りがない限り、複写機という）を管理しており、指示された倉庫の該当する機種の保管状況（台数）を販売店端末に通知する。販売店側では、在庫が確認できると、顧客向けの発送手続きをセンタに対して行う。また、在庫がない場合には、センタに対し、中央倉庫からの発送手続き申請する。この場合、センタは中央倉庫に対して、配送を指示することになる。尚、かかる配送業務にかかる処理内容の詳細については後述する。
【００２２】
上記のようにして、顧客の所へ複写機が搬送されることになるが、販売店員は、複写機の到着時（或いはそれより前でも後でも構わない）に、ユーザーと保守契約書を作成する。
【００２３】
保守契約書には、顧客の名称、住所、更には購入機種モデル、複写枚数等のカウンタチェックの期間間隔（何ヶ月単位にするか等）の情報を記述することになる。また、このとき、保守点検サービスの予定日、及び、期間間隔、そして保守点検を行う店名も記述する（販売店と保守点検サービスを行う店が同じでも構わない）。そして、この契約書を販売店に持ち帰り、端末を操作することで該当する機番（複写機）に対する情報と、その販売店のＩＤ及び保守点検サービスを行う店のＩＤも併せて登録し、その情報をセンタに通知する。センタは、この情報を受け、該当する機番の所在として顧客ＩＤを割り当てる。尚、顧客はＤＢ内でＩＤコードとして管理されており（ＩＤコードと顧客との関係については別途ＤＢが設けられている）、センタでは機番の基礎フォームの該当する領域を受け取ったデータで埋めていく。これ以降、その機番（複写機等）に対する保守点検のスケジュール管理、カウンタチェック日のスケジュール管理が開始される。
【００２４】
保守点検を受け持つ店では、例えばメンテナンスする必要がある顧客を調べたい場合には、端末を操作して自身の店のＩＤを入力し、センタに接続する。そして、メンテナンスの状況を表示する指示を与える。センタは、接続依頼元の店のＩＤを既に取得しているわけであるから、その保守点検対象となっている保守サービス店の項目に、その店ＩＤを持つデータを検索し、例えば顧客名を第１ソート、メンテナンス予定日を第２ソートのキーにしてその一覧をその店の持つ端末に転送する。これにより、保守サービス店側は、メンテナンスのスケジュールを行うことが可能になる。つまり、同じ顧客に対して幾つものメンテナンス対象の製品があれば、それらをまとめてメンテナンスを行う等に活用できるようになる。
【００２５】
尚、実際にメンテナンスを行った場合には、その旨を機番毎にセンタに通知する。センタはこれを受けて、次回のメンテナンスの予定日を更新することになる。
【００２６】
上記は、カウンタチェックについても同様である。ただし、カウンタチェックを行って、センタにそれを通知すると、センタは前回に受けたカウンタとの差分に１未満の所定比率を乗算した結果に基づいて請求書の作成を行う。尚、所定比率を乗算する理由は、顧客において或る頻度でジャム等のエラーがあったものとするためである。そのため、この比率に含まれるジャムエラー率は、実際のそれより多めにしてある。尚、カウンタチェック及びメンテナンスについてシステムの動作の詳細については後述する。
【００２７】
請求書発行は、顧客の要望する様式が様々であるので、予め多数の請求書フォームを容易しておき、その顧客の要望に沿ったフォームを用いて印刷することになる。請求書には、取り引き金融機関（銀行名と口座番号）を付して印刷する。
【００２８】
さて、上記は通常の使用における動作であるが、場合によっては、顧客は新しいモデルに替える、或いは追加することもあり得るし、単に従前に使用していた機種の引き取り、廃棄依頼を行うことも当然にあり得る。
【００２９】
新機種への切り換え若しくは新規導入する場合の、その新機種の設置にかかる手続きについては上記の通りであるので、ここでは従前に使用していた機種の引き取りについて説明する。
【００３０】
販売店が顧客より引き取りの依頼を受けると、所定の引き上げ業者に依頼を発行し、最寄りの処分所に配送を行うと共に該当する機番についての所有者情報として処分所のＩＤで置き換える。処分所に配送されてきた装置は、処分所において再利用できるかどうか（多くの場合には使用している部品に依存する）を判断され、廃棄所と再生所の２つのルートに分別され、それぞれに配送が行われる。廃棄書に搬送された装置について、処分所でその機番抹消手続きを行い、それをセンタに通知する。センタは、指示された機番に該当するデータをＤＢから削除する等の処理を行う。一方、再生所に配送された装置については、最寄りの地方倉庫又は中央倉庫へと配送され、それが再生作業がお粉割る。このとき、新たな機番（ただし、再生された製品化どうかを区別可能になっている）が付されるので、従前の機番に関する情報はＤＢより抹消する手続きを行う。再生処理は行われると、最寄りの地方倉庫又は中央倉庫へと配送される。倉庫側の端末では、再生所から配送されてきた機種について、その機番を新規にセンタに登録する依頼する。
【００３１】
以上のようにして、製造されてから廃棄処理、更には再登録処理が繰り返され、全ての製品についてその所在を管理し、且つ、顧客に対するメンテナンス等の管理を一元管理することが可能になる。
【００３２】
＜センタの構成＞
次に、実施形態におけるセンタにおけるＤＢシステムについて以下に詳述する。
【００３３】
図２は、実施形態におけるセンタのＤＢシステムを構成する装置のブロック構成図である。
【００３４】
図中、１は装置全体の制御を司るＣＰＵであり、２はブートプログラムやＢＩＯＳ等を記憶しているＲＯＭ、３はＣＰＵ１の処理するプログラムを展開したり、ワークエリアとして使用されるＲＡＭである。４はハードディスク装置であり、内部にはＯＳ、ＤＢシステムとして動作するサーバアプリケーションを格納する。また、図示に示すように、実施形態の中枢となる機番やその機種を管理する機番管理マスタＤＢを始め、それをサポートする顧客に関する顧客ＤＢ、販売店に関する販売店ＤＢ、請求書に関する請求書ＤＢ、請求先の振込時の振込人名称を管理する名寄せＤＢで構成される。
【００３５】
ここで、顧客ＤＢは、顧客ＩＤ、その顧客の住所、正式名称、電話、ファクシミリ等の顧客固有の情報を管理する。販売店ＤＢは、その販売店或いはメンテナンスサービスを行う店のＩＤ、住所等を管理する。請求書ＤＢは、請求先に対する多数の請求書フォームと、実際の請求書を構成する請求書データ等を管理するものである。名寄せＤＢは、請求書に対する請求先からの入金処理を効率的に実行するために、１つの請求先に対して使用された複数種類の振込人名称を請求先毎に逐次登録し管理するものである。
【００３６】
これらのＤＢは全て機番管理マスタＤＢの補助するために存在する。
【００３７】
５は各販売店、サービス店や倉庫等に設置された端末との通信接続するための通信インターフェースであり、６はキーボード、７は表示装置、８はセンタ内に設置されたネットワークに接続するためのネットワークインターフェースである。請求書の印刷を行うプリンタも、このネットワークに接続されている。
【００３８】
上記構成において、実施形態における機番管理マスタＤＢのデータフォーマットは図３に示す構造を成している。図示は、１つの機番、つまり、１製品に関するデータフォーマットである。
【００３９】
図示の項目の意味は以下の通りである。
【００４０】
機番：文字とおり製品をユニークに識別する「機番ＩＤ」を格納する領域、
機種：機番からモデル名を特定するモデルコードを格納する領域（機番からだけでも機種が判別できるが、分かり易くするために設けた）、
作成日：該当する機番のデータを作成した日を格納する領域、
リンク情報：該当する機番が複写機である場合には、周辺機器があるか否かを示す情報が格納され、周辺機器である場合には接続する複写機の機番が格納される。
【００４１】
顧客：顧客ＩＤを格納する領域、
販売店：その製品を販売した店ＩＤを格納する領域、
サービス店：製品の保守点検を行う店ＩＤを格納する領域、
契約開始日：最新の契約日を格納する領域、
初回契約日：その機種の一番最初の契約日を格納する領域（「契約開始日」が何度も更新された中の最新の契約日であるのに対し、この「初回契約日」は最初の契約開始日となる）、
契約終了日：契約が満了する日を格納する領域、
契約期間：契約開始日からの月数が格納される領域、
締め予定日：その機番に対する請求書を発行する際の締め日を格納する領域、
締め予定サイクル：締めを行う月数を格納する領域、
保守予定日：保守点検を行う日を格納する領域、
保守サイクル：保守点検を行う間隔である月数を格納する領域、
前回保守日：前回保守点検した日を格納する領域、
前回締め日：コピー枚数をチェックした最新日を格納する領域、
前回値Ａ,Ｂ,Ｃ…：前回チェックした際の累積コピー枚数（複写機が有するカウンタ値）を格納する領域、
今回値Ａ,Ｂ,Ｃ…：今回チェックした際の累積コピー枚数を格納する領域である。
【００４２】
ここで、カウンタを複数分確保したのは、以下の理由による。
【００４３】
これまでのモノクロ複写機における課金の仕方は、１つのカウンタによるものであった。また、一般に知られているように、モノクロ複写機はＡ４，Ａ３、Ｂ５，Ｂ４等複数の記録紙に複写できるものが多い。従って、課金の算定は、これら異なる用紙サイズを予め設定した比率で消費されることを見越し、コピー枚数から課金額を算定していた。しかしながら、専ら一方でサイズの小さい用紙しか消費しない顧客もあり得るので、上記課金は正しく算定できない。また、昨今の様に、カラー複写機が普及しつつあることで、モノクロ、カラーの切り分けも正しくさせないと、更に問題が発生するし、複写機をスタンドアロン装置として設置するのではなく、ネットワークプリンタとして機能させる周辺機器を導入してパーソナルコンピュータ（以下、ＰＣ）等のプリンタとして活用する場合、そのＰＣによる印刷枚数による課金は、複写時より低くしなければならない。
【００４４】
そこで、本システムでは、用紙サイズについてはＡ４サイズ以下（Ｂ５を含む）、それより大きいサイズ（Ｂ４，Ａ３等）サイズのいずれであるか、モノクロかカラーか、更には、複写によるものかＰＣよりの印刷かの３つの条件に見合うカウンタ値を格納する領域を確保した。３つの条件による組み合わせは、２の３乗＝８通りの組み合わせが存在するから、上記の前回値の領域は８つ、今回値の領域も８つ備える。注意したいのは、全ての複写機にカウンタが８つ備えられていることを意味するものではない。つまり、カラー複写機単独で使用した場合には、ＰＣによる印刷はできないわけであるから、使用する領域は前回値及び今回値とも４つになる。そして、そのカラー複写機が、ネットワークプリンタとして機能する周辺装置を接続可能で、実際にその周辺機器を接続して活用するようになると、上記カウンタが機能することになる。
【００４５】
尚、複写機の周辺装置（ソータ（これにもステイプル機能付き等の様々なものがある）、ネットワーク接続装置等）には、カウンタに関する情報はない、もしくはその領域はあってもダミー扱いになる。
【００４６】
上記構成において、製品が製造され、中央倉庫に搬入されセンタに通知を受けると、その機番に基づいて図３の新規レコードを作成することになる。この時に埋められるデータ項目は、機番、機種、作成日であり、顧客の欄には、その倉庫を示す店ＩＤが格納されることになり、顧客に納品されると、顧客の欄にはその顧客のＩＤが埋められることになる。
【００４７】
図４は、機番管理マスタＤＢについて或る機番（図示では機番「LGH06935」）をアクセスした際に表示される一例を示している。図示において、各矩形枠内にあるコロン“：”の右側が編集可能な領域であり、枠外に表示される文字列は、枠内にあるＩＤやコードに基づいて別ＤＢを参照することで得られた結果を示している。
【００４８】
図示によれば、機番“LGH06935”で示される機種は“6022”であり、顧客は顧客ＩＤ“L9-1111”の“ＡＢＣ株式会社”である。その他については説明するまでもないであろう。尚、カウンタ値で今回のカウンタ値から前回のカウンタ値を差し引くことで、その間のコピー枚数を算出し、請求書の発行を行うことになる。入金が確認処理を行うことで、今回のカウンタ値が前回カウンタ値に置き換えられることになる。従って、図示では、前回の締め日が２０００年２月１５日であるので、その日に締めを行ってから入金がない状態を示していることになる。因に、この機番の顧客は、締め予定日は２０日で、締めサイクルは２ヶ月であるので、次回の締め処理は２０００年４月２０日までに行うことになる。つまり、カウンタチェックはそれ以前に完了していることが必要になる。
【００４９】
＜納品処理の説明＞
顧客から機種導入の要望を受けると、販売店員は、自身の店ＩＤを入力し、センタにログインし、初期メニュー（不図示）中の「配送手続き」を選択して配送に係る操作を行う。具体的には、要望のあった１セット単位に機種番号（この段階では店員には機番は不明）とその台数を入力し、センタに通知する。尚、ここで言う１セットとは、例えば複写機Ａ、それに付加するソータ及びネットワークプリンタとして機能する装置等がある場合には、それらのまとまりを言う。
【００５０】
センタは、上記機種番号（複数でも良い）を受け付けるとそれをキーにして、機番管理マスタＤＢを検索する。検索された結果は、要請の合った販売店に近い倉庫を優先してソートし、その結果を販売店の端末に返す。このとき、各機種の機番が判明するので、機番も併せて販売店端末に通知し、その結果を表示させる。
【００５１】
販売店は、これを受けて、配送指示を行うと、センタは該当する機番のうち、複写機の周辺機器である機番データ中のリンク情報に、複写機の機番を書き込み、複写機と周辺機器とのリンクを図る。そして、配送日として、所定日数後（例えば翌日）になることを販売店端末に通知すると共に、該当する倉庫の端末に発呼し、該当する機番の装置を顧客宛に上記の配送日に配送するよう要求する。
【００５２】
尚、既に顧客で使用されている複写機に対する周辺機器を配送手続きを行う場合もある。この場合には、例えばその複写機の機種番号ではなく、機番を入力し、それに接続する周辺機器の機種番号を上記のようにして入力する。
【００５３】
センタは、複写機の機番が指定されることで、該当する機番と、新規導入する周辺機器の機番とのリンクを張ることになる。
【００５４】
図５は、最終的にセンタから販売店に通知される配送処理結果の画面の一例を示している。図示において、「新」とは、新規導入機器であることを示しており、図示の場合には３つの製品とも同じ倉庫に在庫があって、２０００年４月２０日に配送手続きを行うことを示している。顧客が現に使用している複写機に対して周辺機器を導入する場合には、その複写機については「新」は表示されない。いずれにしても、複写機と周辺機器とのリンクが確立することに変わりはない。
【００５５】
センタのＤＢシステムにおけるＣＰＵ１の動作処理としては、図６に示すフローチャートになろう。尚、以下は、販売店からのログインが完了して、「配送手続き」が指示され、販売店より機種番号の通知を行った場合の処理である。
【００５６】
先ず、ステップＳ１において、販売店よりの情報を入力する。次いで、ステップＳ２に進み、該当する機種を機番管理マスタＤＢから検索し、その販売店に最寄りの機番データを抽出する。そして、ステップＳ３に進み、配送可能日（ログイン日＋所定日数）を設定し、ステップＳ４で、検索結果得られた機番と共に販売店端末に通知し、ステップＳ５で販売店端末よりの返答を待つ。
【００５７】
ＯＫの指示があった場合には、ステップＳ６に進み、配送依頼のあった各機番のリンクを張る処理を行う。勿論、１台の複写機のみの場合には、この処理は行わない。
【００５８】
そして、ステップＳ７に進み、該当する機番を管理している倉庫に対して機番と、配送予定日を通知する。
【００５９】
尚、上記例では、配送を行うときに、複写機とその周辺機器とのリンクを行ったが、配送が完了した後に、各販売店は顧客に設置処理する際の接続状態から選択にセットの機番を列挙し入力することで、リンクの確立を図っても構わない。
【００６０】
＜保守点検の説明＞
次に、サービス店における保守点検に関して説明する。
【００６１】
保守点検は、１セット単位に行われる。つまり、１つの複写機に、１乃至複数の周辺機器が接続された状態で使用されている場合には、それらをまとめて保守点検対象とする。実施形態では、上記の通り、複写機とその周辺機器とは、機番管理マスタＤＢ内ではリンクされた状態で管理されているから、都合が良い。
【００６２】
さて、保守サービスを行う店（以下、サービス店）では、毎月、自店が管轄する複写機及びその周辺機器について保守点検を行うスケジュールを立てる必要がある。
【００６３】
このため、サービス店側では端末からセンタへ、自店ＩＤを用いてログインし、初期メニュー（不図示）中の「保守サービス」を選択する。
【００６４】
この結果、センタ側のシステムは、その店ＩＤをサービス店ＩＤとして格納されているデータを検索する。そして、得られた機番データ中の、前回保守日にその保守サイクル（月数）を加算した月の、「保守日」の欄に格納されている月日を算出し、それをソートしてサービス店の端末に通知する。このとき、周辺機器が接続されている複写機については、その周辺機器も含めて通知する。サービス店では、受信したデータを表示もしくは印刷することになる。
【００６５】
図７はその出力例を示している。図示の場合、機番ＬＧＨ０６９３１に対しては、周辺機器である機番ＸＹ１１２３３４及びＰＱ２４３３１０（例えばソータやネットワーク接続装置）が接続されていることを示している。
【００６６】
サービス店側では、この出力結果を受け、実際に行う保守点検日のスケジュールや、準備する器材の準備を行うことになる。
【００６７】
センタのＣＰＵ１は、上記処理を行う場合には、図８に示すフローチャートに従って動作することになる。
【００６８】
先ず、ステップＳ１１で、ログインに使用したＩＤに合致するサービス店ＩＤを持つデータを機番管理マスタＤＢから検索する。次いで、ステップＳ１２において、得られたデータにある前回保守日に、保守サイクル（月）を加算した結果の年月を求め、残りの日については機番データ中の「保守日」を使用し、次回の保守点検予定日を算出する。そして、ステップＳ１３に進み、複写機本体とセットになる複写機とのリンク処理を行い（複写機の機番＋周辺機器の機番の文字列を作成する）、ステップＳ１４でその結果を要求元のサービス店の端末に通知する。
【００６９】
尚、ログインした日以降に保守点検予定日があるものと、それより前に予定日があるもの（保守点検が未完のデータ）を識別可能（例えば色を替えるとか、別々にして表示する等）にして表示するようにしてもよい。
【００７０】
また、保守点検が完了した場合には、センタにログインし、保守点検の完了手続きを行う。ここでは、機番と、保守点検を行った日を入力し、センタに通知する作業であるので、説明するまでもないであろう。センタは、通知を受けた機番データ内の「前回保守日」の欄を更新する。
【００７１】
＜カウンタチェックの説明＞
販売店員は、顧客との契約で設定した時期になると、その顧客が有する複写機内のカウンタをチェックし、それをセンタに通知する。センタはこれを受けて、前回のカウンタとの差分から課金額を算定し、顧客に対して請求書を発行することになる。ここでは、このカウンタチェックにおけるスケジュールについて説明する。
【００７２】
販売店では、毎月、自店が管轄する複写機についてカウンタチェックの作業のスケジュールを立てる必要がある。
【００７３】
このため、販売店側の端末からセンタへ、自店ＩＤを用いてログインし、初期メニュー（不図示）中の「カウンタチェック」を選択する。これにより、入力画面が表示されるので、ここにデータを埋め込み、最後に送信キー（図示せず）を押下する。
【００７４】
センタ側のシステムは、上記内容を受信すると、その店ＩＤを販売店ＩＤとして格納されている機番データを検索する。そして、得られた機番データ中の、前回締め日の年月に、締めサイクルで示される月数を加算する。そして、その加算結果の年月に「締め日」の欄に格納されている日数を追加することで、最終的に年月日を算出し、それを通知する。販売店側では、受信したデータを表示もしくは印刷し、締め日に間に合うよう各顧客の複写機内のカウンタチェックを行う。
【００７５】
尚、上記の販売店側における出力形態は、先に示した図７と同様であり、それを出力するセンタ側の処理も、上記の「保守点検の説明」からすれば容易に理解できるであろうから、その説明は省略する。
【００７６】
また、販売店が実際にカウンタチェックを行った場合には、その機番と計数値を入力し、センタに通知するだけでよい。
【００７７】
図９は、この通知処理における画面の例を示している。図示の如く、入力する項目は、機番、チェック日、各カウンタの値で構成される。
【００７８】
尚、先に説明したように、機番によりその複写機がモノクロ複写機かどうか、及び、その複写機に周辺装置としてパーソナルコンピュータのプリンタとして機能するネットワーク接続装置が接続されているかはセンタ側で把握できているので、例えばモノクロ複写機である場合に、カラーのカウンタ値を入力しても無視される。
【００７９】
また、この表示画面はセンタからの情報に基づいて表示されるので、機番を先ず入力し、その後に設定画面を送信するようにすれば、その機番に適したカウンタの入力画面を送信することもできる。つまり、カウンタ値を入力する個数も、その機番及び周辺機器の接続形態に依存したものとすることができる。
【００８０】
いずれにせよ、入力した内容をセンタに通知すると、センタ側のシステムは該当する機番データ内の今回値の中に、受信した値を書き込む処理を行う。
【００８１】
この後、センタ側では、毎日、機番管理マスタＤＢ内の今回値の内容を調べ、それが格納されている機番データを探し出す。そして、その機番データから顧客ＩＤを抽出し、顧客に対して請求書を発行することになる。
【００８２】
尚、請求書に対して、振り込みの通知が提携金融機関よりあった場合、その今回のカウンタ値を前回カウンタ値に書き込み、今回のカウンタ値をリセットし、次回に備える。
【００８３】
＜センタ側の管理の説明＞
以上のように、全販売店或いはサービス店からの情報により、各機番（製品）のデータはその都度更新され、次回の業務に必要な情報が構築することが可能であるが、各販売店やサービス店の業務の効率化を図るための指針情報を構築し、各店に通知することも可能になる。
【００８４】
例えば、カウンタチェックを行うことで、その顧客に対して請求書を発行する処理に移行することができるものの、逆に、カウンタチェックを行わないと業務上の収入がないことになる。
【００８５】
上記のシステムにすることで、締め予定日を過ぎても該当する機番（複写機）のカウンタの入力がないものを検索することは容易である。また、各機番データには、販売店のＩＤも含まれているので、販売店毎の締め作業がどの程度進行しているのかを把握することも容易にできるようになる。
【００８６】
そこで、センタでは、毎月、各販売店の締め率（例えば前月に締めがあった顧客数を分母にし、締めを行った顧客数を分子にした割合）を算出し、全ての販売店或いは地域に含まれる店の締め率を閲覧可能にして作成する。
【００８７】
販売店は、センタにログインした際に、その閲覧を指示することで、例えば図１０に示すようなデータがセンタから受信し、表示する。これにより、他の販売店の業務の遂行と比較して自店の業務内容を把握できることが可能になり、業務遂行の１つの指標を与えることもできるようになる。
【００８８】
＜請求書発行処理＞
次に、請求書発行処理について、以下に詳述する。
【００８９】
上述したように、顧客は、受領する請求書のレイアウトに様々な要望があるので、請求書ＤＢには、予め多数の請求書フォームを用意し管理しておく。その一例を、以下の図１１に示す。
【００９０】
図１１（ａ）に示すように、請求書は、請求先に対し、機番単位で請求書を出力する。つまり、請求先が抱えている複写機やその周辺機器の各機番の数だけ、請求書が発行される。
【００９１】
また、請求先によっては、自身が抱えている複写機やその周辺機器に対する請求を一括して受領したい場合もある。そこで、図１１（ｂ）に示すように、請求先が抱えている複写機やその周辺機器に対する請求をまとめ、それを１枚の請求書にして発行する。
【００９２】
更に、複数の部署を有する企業等では、各部署が抱えている複写機やその周辺機器に対する請求を一括して受領し、尚かつ、各部署の請求内訳を把握したい場合もある。そこで、図１１（ｃ）に示すように、請求先の各部署が抱えている複写機やその周辺機器に対する請求を、各部署毎にまとめ、更に、それらを１枚の請求書にして発行する。
【００９３】
これ以外にも、支店や支所毎の請求を１枚の請求書にして発行したり、複写機１台毎、複数台毎、部署や支店、支所、課、人（担当者）等の所定単位毎に、それぞれの請求書にして発行したりすることが可能である。もちろん、この場合は、請求書ＤＢに必要な請求書フォームが用意されていることは言うまでもない。また、顧客によっては、請求書に用いる印刷用紙のサイズや、印刷枚数、向き（Ａ４縦、Ａ４横等）等を要望する場合があるので、請求書フォームに、印刷用紙のサイズ、印刷枚数、向き等を指定する印刷情報を付加し、この印刷情報に基づく印刷が可能なプリンタから請求書を印刷するようにすることもできる。
【００９４】
尚、これらの請求書フォームは、各フォーム毎に請求書フォーム番号が付加されており、この請求書フォーム番号は、顧客ＩＤに対応する顧客情報として、顧客ＤＢに管理されている。
【００９５】
請求書の発行は、基本的には、販売店が行い、各販売店に用意されている端末を用いて行う。請求書を発行する場合、販売店は、まず、請求書を発行するための専用画面（請求書発行画面）を端末上で表示する。請求書発行画面には、顧客名、管轄のサービス店名、販売店名、請求先名、顧客が抱えている複写機やその周辺機器の機番、機種番号、請求書フォーム番号等を表示／入力する領域を有している。その画面例を、図１２に示す。但し、この画面例は、あくまでも一例であり、必要に応じて各種情報を表示／入力するための領域を構成できることは言うまでもない。
【００９６】
この図１２を用いて、請求書発行画面を構成する各領域について説明する。
【００９７】
図１２において、１２００は顧客ＩＤを入力する領域であり、ここに、顧客ＩＤを入力すると、顧客ＩＤに対応づけて顧客ＤＢで管理されている顧客情報（例えば、顧客名、請求書フォーム番号、機番、機種番号等）が検索され、顧客名が領域１２０１、請求書フォーム番号が領域１２０３、機番、機種番号が領域１２０５にそれぞれ呼び出される。また、ボタン１２０４は、請求書フォーム番号を変更する場合に使用し、このボタン１２０４を操作すると、現在使用可能な請求書フォーム番号のリストが表示され、所望の請求書フォーム番号を選択して入力することができる。１２０２は販売店員が所属している販売店、サービス店等を表示する領域である。
【００９８】
同様に、領域１２０５の各請求項目の欄には、ボタン１２０４と同等の機能を果たすボタンが用意されており、販売店員は、これらのボタンを操作すると、頻繁に使用する請求項目のリストが表示され、所望の請求項目を選択して入力することができる。もちろん、直接手入力で、所望の請求項目を入力することも可能である。また、選択されたあるいは入力された請求項目が、特に、複写機の複写枚数を示すカウンタ値の場合は、上述の機番管理マスタＤＢで管理されている機番ＩＤに対応する請求対象のカウンタ値と複写機のコピー単価と上述したジャムエラー率等を考慮した所定比率を参照して、今回請求する請求代金を自動計算して請求代の欄に表示する。それ以外にも、自動計算が可能な請求項目に関しては、同様に、自動計算して請求代の欄に表示し、そうでない請求項目に関しては、販売店員が直接請求代の欄に請求代金を入力する。
【００９９】
１２０６は請求書作成ボタンであり、領域１２０５に必要な各請求項目毎の請求代金を入力した後に、この請求書作成ボタン１２０６を操作すると、指定された請求書フォーム番号に対応する請求書フォームを請求書ＤＢから取得し、また、請求書番号や請求代の入金を行うための請求先コード、入金確定／未確定を示す入金確定／未確定フラグ等の請求書管理情報をセンタから取得して、取得した請求書フォーム、請求書管理情報、請求書発行画面で入力された請求書データ（請求項目、請求代等）に基づいて請求書を作成し印刷する。同時に、請求書データ及び請求書管理情報は、請求書ＤＢに顧客毎に管理される。また、請求書を作成した旨をセンタに通知し、この通知に基づく処理をセンタは実行する。
【０１００】
以上の請求書発行処理のフローチャートを示すと、図１３のようになる。以下同フロー参照して、図１及び図２に示すセンタのシステムの作動を説明する。
【０１０１】
まず、ステップＳ１３０１で、販売店員は請求書発行画面を販売店の端末上に表示させる。ステップＳ１３０２で、端末より入力された情報をセンタＣＣ側に請求先の顧客ＩＤを入力する。ステップＳ１３０３で、入力された顧客ＩＤに基づいて、センタＣＣのＣＰＵは請求書発行画面に表示された請求対象の機番に対し、それぞれ請求項目、請求代を入力あるいは自動計算し、端末側の請求書作成ボタンを操作する。ステップＳ１３０４で、指定された請求書フォームに対応する請求書フォームを請求書ＤＢから取得し、取得した請求書フォームと請求書発行画面で入力された請求書データ、更にセンタＣＣが生成する請求書管理情報に基づいて請求書を作成し、端末のプリンタで印刷する。一方で、センタＣＣ側では、処理対象の請求書に対する請求書管理情報（請求書番号、請求先コード、入金確定／未確定フラグ等）を生成しており、処理対象の請求書のデータと対応づけて請求書ＤＢに記憶して登録する。
【０１０２】
＜自動入金処理＞
次に、自動入金処理について説明する。これは、発行した請求書に対する請求先からの入金を確認し、確定する処理である。
【０１０３】
請求先からの入金には、様々な入金形態があり、例えば、自動振替、銀行振込、集金等がある。特に、入金が銀行振込の場合には、請求先の振込時の振込人名称には、その振込処理を行う人間によって異なる場合が多々ある。例えば、カタカナ株式会社の振込人名称としては、その振込人によって「カタカナ（カブ）」であったり、「カタカナカブシキカイシャ」であったりする。
【０１０４】
そのため、請求先からの入金を確認する販売店では、確認用の請求先の振込人名称（基本振込人名称）が１つだけしか存在しないと、処理対象の入金の振込人名称が１字でも違ってしまうと、正しい請求先からの入金であっても、それを正しいと認識することができない。そこで、請求先の振込人名称が複数種類存在することがあることを考慮して、基本振込人名称以外に、それと同じものとみなせる振込人名称が発生する毎に、その基本振込人名称に対応する振込人名称として逐次登録し管理する上述の名寄せＤＢを構成する。つまり、この名寄せＤＢを参照し、処理対象の入金の振込人名称と一致する振込人名称が存在すれば、正しい請求先からの入金であるものとして、以降の処理を進めることができる。
【０１０５】
ここで、名寄せＤＢのデータフォーマットについて、図１４に示す。
【０１０６】
図１４に示すように、各顧客ＩＤ毎に、基本振込人名称が対応づけてられており、更に、基本振込人名称以外で振込人名称として用いられる可能性がある振込人名称のグループとして名寄せ項目に登録されている。この名寄せ項目に登録される振込人名称は、事前に顧客から通知を受けた振込人名称であったり、販売店員が顧客に対して確認した振込人名称であったりする。
【０１０７】
次に、自動入金処理処理の詳細について、以下、説明する。
【０１０８】
センタあるいは販売店は、定期的に提携金融機関に対して入金確認を行い、なにかしらの入金があった場合には、その入金に関する入金データ（請求コード、それに付随する振込人名、入金日、入金額）を取得することができる。但し、請求コードの入力は、請求先に依存してしまうので、必ず入金データに対して存在するものではない。
【０１０９】
次に、自動入金処理の詳細について、以下、説明していく。
【０１１０】
上述の自動入金処理を実行する場合、販売店は、まず、処理対象の入金を確認するための専用画面（自動入金確認画面）を端末上で表示する。自動入金確認画面には、請求先を示す請求先コード、振込人名、入金日、入金額、管轄のサービス店名、販売店名等を表示／入力する領域を有している。その画面例を図１５に示す。但し、この画面例は、あくまでも一例であり、必要に応じて各種情報を表示／入力するための領域を構成できることは言うまでもない。
【０１１１】
この図１５を用いて、自動入金確認画面を構成する各領域について説明する。
【０１１２】
図１５において、入金データを取得すると、その入力データから得られる各種データが指定の領域に呼び出される。１５０１は請求先コードを表示する領域であり、１５０２は振込人名を表示する領域１５０２、１５０３が入金日を表示する領域１５０３、１５０４が入金額を表示する領域１５０４である。但し、上述したように、入金データ中には請求コードは必ずしも存在しないので、そのような場合は、販売店員が適宜、必要な情報を各領域に入力する。もちろん、集金等で現金で請求代を領収した場合には、販売店員が必要な情報を各領域に入力する。１５０５は販売店員が所属している販売店、サービス店等を表示する領域である。
【０１１３】
１５０６は入金チェックボタンであり、上記の各領域に必要な情報が入力された後に、この入金チェックボタン１５０６を操作すると、処理対象の入金が正しい請求先からのものであるか否かをチェックし、そのチェック結果に応じて処理を実行する。
【０１１４】
以下、この入金チェックを含む自動入金処理のフローチャートを図１６に示す。以下同フロー及び図１、２を参照して、動作を説明する。
【０１１５】
ます、ステップＳ１６０１で、販売店員は、販売店の端末上に表示させた自動入金確認画面に対し、端末からの入金処理対象の入金データをセンタＣＣのシステムに入力する。ステップＳ１６０２で、端末から自動入金確認画面内の入金チェックボタンが操作されたかをチェックする。ステップＳ１６０２で、自動入金確認画面に請求コードが入力されているか否かを端末、センタＣＣがチェックする。請求コードがある場合、ステップＳ１６０５に進む。一方、請求コードがない場合、ステップＳ１６０３に進む。
【０１１６】
ステップＳ１６０３で、センタＣＣのＣＰＵは振込人名称が名寄せＤＢに存在するか否かを判定する。存在する場合、ステップＳ１６０５に進む。一方、存在しない場合、ステップＳ１６０４に進み、センタＣＣのＣＰで新規振込人名称に対応する基本振込人名称を決定し、名寄せＤＢに記憶して登録する。
【０１１７】
ステップＳ１６０５で、入金額をチェックする。このチェックは、ステップＳ１６０５に到達するまでの上記ステップ群の経路によって、処理内容が異なっている。
【０１１８】
まず、ステップＳ１６０２からステップＳ１６０５に到達した場合、つまり、請求先コードが存在する場合には、センタＣＣのＣＰＵで請求コードに対応する請求先の未処理の請求代と入金額を比較する。この比較の結果、請求代と入金額が一致する場合、ステップＳ１６０７に進み、正しい入金が行われたものとして、その入金を確定し、センタＣＣのＣＰＵで、その入金に対する請求書に対応する請求書管理情報の入金確定／未確定フラグを確定状態にする。一方、一致しない場合、ステップＳ１６０６に進み、その入金は未処理とし、また、センタＣＣのＣＰＵで入金に対する請求書に対応する請求書管理情報の入金確定／未確定フラグを未確定状態にする（但し、入金確定／未確定フラグは、初期状態で、未確定状態になっているので、実際には、この未確定状態にするための処理は行われない）。その後、後述する未処理入金一覧を出力する。
【０１１９】
また、ステップＳ１６０３からステップＳ１６０５に到達した場合、つまり、請求先コードが存在せず、名寄せＤＢに登録されている振込人名称である場合には、センタＣＣのＣＰＵでその振込人名称に対応する基本振込人名称の請求先で、未処理の請求代と入金額を比較する。この比較の結果、請求代と入金額が一致する場合、ステップＳ１６０７に進み、正しい入金が行われたものとして、その入金を確定し、センタＣＣのＣＰＵでその入金に対する請求書に対応する請求書管理情報の入金確定／未確定フラグを確定状態にする。一方、一致しない場合、ステップＳ１６０６に進み、その入金は未処理とし、また、センタＣＣのＣＰＵで入金に対する請求書に対応する請求書管理情報の入金確定／未確定フラグを未確定状態にする（但し、入金確定／未確定フラグは、初期状態で、未確定状態になっているので、実際には、この未確定状態にするための処理は行われない）。
その後、後述する未処理入金一覧を出力する。
【０１２０】
また、ステップＳ１６０４からステップＳ１６０５に到達した場合、つまり、請求先コードが存在せず、名寄せＤＢに新規な振込人名称が登録された場合には、その振込人名称に対応する基本振込人名称の請求先で、未処理の請求代と入金額を比較する。この比較の結果、請求代と入金額が一致する場合、ステップＳ１６０７に進み、正しい入金が行われたものとして、その入金を確定し、その入金に対する請求書に対応する請求書管理情報の入金確定／未確定フラグを確定状態にする。一方、一致しない場合、ステップＳ１６０６に進み、その入金は未処理とし、また、センタＣＣのＣＰＵで入金に対する請求書に対応する請求書管理情報の入金確定／未確定フラグを未確定状態にする。その後、後述する未処理入金一覧を表示装置あるいはプリンタに出力する。
【０１２１】
上述したように、ステップＳ１６０６で、処理対象の入金が未確定となると、未確定の入金群を一覧にした未処理入金一覧を生成し出力する。この未処理入金一覧は、未確定の入金群が所定数以上発生した後に出力するようにしても構わないし、未確定の入金が発生する毎に逐次その未処理入金一覧に出力するようにしても構わない。ここでいう出力とは、端末上の表示装置への出力、端末に接続されるプリンタへの出力、端末に接続されるネットワークへの出力等を含む。
【０１２２】
図１６における自動入金処理における請求先を特定するための各種判定は（例えば、ステップＳ１６０２、ステップＳ１６０３等）は、これに限定されるものではない。より精度を高めるために、例えば、振込人である請求先の振込銀行や、電話番号、住所等の振込人である請求先を特定できる情報に関する判定を適宜追加することができる。
【０１２３】
＜変形例＞
上述した請求書発行処理は、販売店側が印刷した請求書を請求先である顧客に送付する構成としたが、この請求書を電子データ（電子請求書）として、例えば、インターネット等のネットワークを介して顧客に送信するような構成にすることもできる。但し、電子請求書の正当性及び秘匿性を維持し、証明するために、例えば、電子請求書は既存の電子署名技術を用いて販売店と顧客間で送受信する。また、汎用性及び利便性を高めるため、電子請求書（例えば、図１７）には販売店の公開鍵を管理する認証局（例えば、日本ベリサイン社等の第三者認証機関）のネットワーク上のアドレス（例えば、ＵＲＬ）を記述しておき、顧客は受信した電子請求書に記述されている認証局へアクセスして販売店の公開鍵を取得させるように構成する。
【０１２４】
以下、その具体例を図１８を用いて説明する。
【０１２５】
販売店は、認証局から顧客の公開鍵を受信し、その公開鍵を用いて電子請求書を暗号化し、生成される暗号文を顧客へ送信する。同時に、電子請求書をハッシュ関数を用いて回復不能文を作成し、これを販売店自身の秘密鍵を用いて回復不能文を暗号化し、生成される回復不能暗号文を顧客へ送信する。
【０１２６】
一方、顧客は、受信した電子請求書の暗号文を顧客自身の秘密鍵を用いて復号化し、電子請求書を取得する。また、この電子請求書は、ハッシュ関数を用いて回復不能文を作成する。次に、取得した電子請求書に記述されている認証局へアクセスし、販売店の公開鍵を取得し、別途販売店から受信した回復不能文をその公開鍵を用いて復号化し、回復不能文を復元する。そして、この回復不能文と既にハッシュ関数を用いて作成した回復不能文とを比較し、一致していれば、改善されていない正規の請求書として判断することができる。
【０１２７】
尚、図１８では、ネットワークを介して販売店から顧客へ電子請求書を送信するような構成としたが、上述したセンタに各販売店からの電子請求書を一旦を収集し、センタから各顧客へ送信するようにすることもできる。このようにすることで、各販売店で発行される電子請求書をセンタで一元管理することができ、より効率的に処理を行うことができる。
【０１２８】
尚、上記実施形態における各倉庫や販売店等に設置される端末、及び、センタに設置されるサーバは、基本的に汎用の情報処理装置やワークステーション等で構成することが可能である。
【０１２９】
つまり、本発明は、上記実施形態を実現するための装置及び方法及び実施の形態で説明した方法を組み合わせて行う方法のみに限定されるものではなく、上記システム又は装置内のコンピュータ（ＣＰＵあるいはＭＰＵ）に、上記実施の形態を実現するためのソフトウエアのプログラムコードを供給し、このプログラムコードに従って上記システムあるいは装置のコンピュータが上記各種デバイスを動作させることにより上記実施の形態を実現する場合も本発明の範疇に含まれる。
【０１３０】
また、この場合、前記ソフトウエアのプログラムコード自体が上記実施の形態の機能を実現することになり、そのプログラムコード自体、及びそのプログラムコードをコンピュータに供給するための手段、具体的には上記プログラムコードを格納した記憶媒体は本発明の範疇に含まれる。
【０１３１】
この様なプログラムコードを格納する記憶媒体としては、例えばフロッピーディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ等を用いることができる。
【０１３２】
また、上記コンピュータが、供給されたプログラムコードのみに従って各種デバイスを制御することにより、上記実施の形態の機能が実現される場合だけではなく、上記プログラムコードがコンピュータ上で稼働しているＯＳ（オペレーティングシステム）、あるいは他のアプリケーションソフト等と共同して上記実施の形態が実現される場合にもかかるプログラムコードは本発明の範疇に含まれる。
【０１３３】
更に、この供給されたプログラムコードが、コンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能格納ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって上記実施の形態が実現される場合も本発明の範疇に含まれる。
【０１３４】
【発明の効果】
以上説明したように本発明によれば、各サービス店（販売店兼用の場合も当然にあり得る）が管理する機器を一元管理すると共に、複写機等の主機器とその周辺機器の使用状況を含めた、スケジュール管理を行い、その情報をサービス店に提供することが可能になる。
【図面の簡単な説明】
【図１】実施形態における製品管理システムにおける全体構成と製品及び情報の流れを模式的に示す図である。
【図２】実施形態におけるセンタにおける装置のブロック構成図である。
【図３】実施形態における機番管理マスタデータベースにおけるデータフォーマットを示す図である。
【図４】機番管理マスタデータベースにおける機番データの表示画面の一例を示す図である。
【図５】配送手続きの通知画面の例を示す図である。
【図６】センタ側における配送手続き処理手順を示すフローチャートである。
【図７】保守点検予定一覧の表示例を示す図である。
【図８】センタ側における保守点検予定一覧を作成する処理手順を示すフローチャートである。
【図９】実施形態におけるカウンタ入力画面の一例を示す図である。
【図１０】実施形態における各点の締め率一覧の出力例を示す図である。
【図１１】実施形態における請求書フォームの構成例を示す図である。
【図１２】実施形態における請求書発行画面の一例を示す図である。
【図１３】販売店側における請求書発行手順を示すフローチャートである。
【図１４】実施形態における名寄せＤＢのデータフォーマットを示す図である。
【図１５】実施形態における自動入金確認画面の一例を示す図である。
【図１６】販売店側における自動入金手順を示すフローチャートである。
【図１７】実施形態における電子請求書の一例を示す図である。
【図１８】実施形態における電子署名技術を用いた電子請求書の発行例を示す図である。
【図１】
0004638992.tif 000002
【図２】
0004638992.tif 000003
【図３】
0004638992.tif 000004
【図４】
0004638992.tif 000005
【図５】
0004638992.tif 000006
【図６】
0004638992.tif 000007
【図７】
0004638992.tif 000008
【図８】
0004638992.tif 000009
【図９】
0004638992.tif 000010
【図１０】
0004638992.tif 000011
【図１１】
0004638992.tif 000012
【図１２】
0004638992.tif 000013
【図１３】
0004638992.tif 000014
【図１４】
0004638992.tif 000015
【図１５】
0004638992.tif 000016
【図１６】
0004638992.tif 000017
【図１７】
0004638992.tif 000018
【図１８】
0004638992.tif 000019