WO2010032620A1

WO2010032620A1 - 取引精算システム、取引精算システムにおける精算装置、取引管理サーバ、取引精算方法およびプログラム

Info

Publication number: WO2010032620A1
Application number: PCT/JP2009/065381
Authority: WO
Inventors: 川畑正昭; 梨本徹
Original assignee: 日本電気株式会社
Priority date: 2008-09-17
Filing date: 2009-08-27
Publication date: 2010-03-25
Also published as: JP5407246B2; JP2010072820A

Abstract

クレジットカードを所有できない買い手が、店舗等で容易に自身の信用保証を行えるとともに、前払いの不足分に対して後払いが可能となる取引精算システムを提供する。　本発明の取引精算システムは、買い手の前払い金を管理する前払い入金装置と、入金済みの前払い金額情報と買い手の生体情報とを関連づけて格納した記憶手段を有する取引管理サーバと、取引金額の情報および買い手の生体情報を受け取ると、取引管理サーバにアクセスして当該買い手の入金済みの前払い金額情報を取得し、該前払い金額情報および取引金額の情報に基づいて前払いの可否判断を行い、前払い金による全額支払い不可と判断した場合、無条件にまたは所定の許可条件を満たしたときに、不足金額に対する後払い取引を伴う前払い取引を開始する精算装置とを備える。

Description

取引精算システム、取引精算システムにおける精算装置、取引管理サーバ、取引精算方法およびプログラム

　本発明は取引精算システムに関し、特に、クレジットカードを所有できない買い手が店舗等で容易に自身の信用保証を行え、取引金額の後払いが可能となる取引精算システムに関する。

　店舗等での信用取引による商品購入には、一般的に、買い手の信用保証が容易なクレジットカードが利用されている。しかし、クレジットカードを所有するためには、銀行等の保証が必要であり、クレジットカードを所有できない人も存在する。
　このようなクレジットカードの問題を解決する一つの手段として、例えば、特許文献１には、プリペイドカード購入時に利用者の指紋を登録しておき、指紋認証を用いてプリペイドカードの使用の可否を判断するプリペイドカード代用システムが開示されている。特許文献１記載の技術では、提供者側で代金の徴収漏れが生じることがないため、誰でも信用取引による商品購入を行うことができる。
特開２００５−１８２２４０

　しかしながら、上述した特許文献１記載の技術には、プリペイドカードによる前払いで不足分が生じた場合には取引を行うことができないという問題がある。
　本発明の目的は、クレジットカードを所有できない買い手が、店舗等で容易に自身の信用保証を行えるとともに、前払いの不足分に対して後払いが可能となる取引精算システムを提供することにある。
発明の効果
　本発明には、店舗等において、クレジットカードを所有できない買い手の売り手に対する信用保証を容易に行えるとともに、前払いの不足分に対しては後払いを行う取引（商品先渡しの取引金額後払いの取引）も可能になるという効果がある。

本発明の第１および第２の実施の形態における取引精算システムを示すブロック図である。本発明の第１および第２の実施の形態における精算装置の構成を示すブロック図である。本発明の第１および第２の実施の形態における取引管理サーバの構成を示すブロック図である。本発明における前払い入金装置の構成を示すブロック図である。本発明における前払い金の入金動作を示すタイミングチャートである。本発明の第１および第３の実施形態における取引精算システムの処理動作を示すタイミングチャートである。本発明の第２および第４の実施形態における精算装置の構成を示すブロック図である。本発明の第２および第４の実施形態における取引管理サーバの構成を示すブロック図である。本発明における取引履歴情報の一例を示す図である。本発明における取引結果と不具合レベルと格付けポイントとの対応表の一例を示す図である。本発明における買い手の取引評価情報の一例を示す図である。本発明の第２および第４の実施形態における取引精算システムの処理動作を示すタイミングチャートである。本発明の第３および第４の実施の形態における取引精算システムを示す図である。本発明の第３および第４の実施の形態における端末の構成を示すブロック図である。本発明の第３および第４の実施形態における取引精算システムの処理動作を示すタイミングチャートである。本発明における設定情報を示す図である。

１−１~１−３　　店舗
２−１~２−３　　精算装置
２１　　制御手段
２１１　決算手段
２１２　取引判断手段
２２　　入力手段
２３　　記憶手段
２３１　商品データベース（ＤＢ）
２３２　　取引データベース（ＤＢ）
２４　　表示手段
２５　　通信手段
２６　　生体情報読取手段
２７　　商品情報読取手段
３　　　取引管理サーバ
３１　　制御手段
３１１　取引管理手段
３１２　取引判断手段
３２　　入力手段
３３　　記憶手段
３３１　　買い手情報データベース（ＤＢ）
３３２　　取引データベース（ＤＢ）
３４　　表示手段
３５　　通信手段
３６　　生体情報読取手段
３７　　出力手段
４　　　前払い入金装置
４１　　生体情報入力手段
４２　　表示手段
４３　　　入金手段
４４　　　制御手段
４５　　通信手段
５　　　ネットワーク
６　　　取引精算システム
７　　　端末
７１　　制御手段
７２　　入力手段
７３　　記憶手段
７４　　表示手段
７５　　通信手段
７６　　　生体情報入力手段

　次に、本発明の取引精算システムの第１の実施の形態について説明する。
　図１は、本発明の取引精算システム６を示すブロック図である。
　取引精算システム６は、店舗１−１~１−３にそれぞれ設置された精算装置２−１~２−３と、取引管理サーバ３と、前払い入金装置４とを含む。
精算装置２−１~２−３と取引管理サーバ３と前払い入金装置４とはインターネット、無線ＬＡＮまたは無線通信等のネットワーク５で相互に接続されている。
　図１では、店舗１−１に精算装置２−１が設置され、店舗１−２に精算装置２−２が設置され、店舗１−３に精算装置２−３が設置されている場合を例示しているが、各店舗における精算装置の設置数は任意であり、また、ネットワーク５に接続される精算装置２の総数も任意である。また、精算装置２−Ｉの設置場所についても任意であり店舗に限定されるものではない。
　図２は、精算装置２−Ｉ（Ｉ＝１~３）の構成を示すブロック図である。
　精算装置２−Ｉでは、店舗で買い手により選択された購入希望商品の精算が行われる。精算装置２−Ｉは、制御手段２１と入力手段２２と記憶手段２３と表示手段２４と通信手段２５と生体情報読取手段２６と商品情報読取手段２７と出力手段２８とから構成される。制御手段２１は決算手段２１１を有する。記憶手段２３は商品データベース（ＤＢ）２３１を有する。
　決算手段２１１は、精算装置２−Ｉで行われる取引を管理、制御する。買い手からの商品購入の取引の管理、制御および処理が行われる。また、買い手の生体情報の入手処理や、取引の許可処理の管理および制御が行われる。
　商品データベース２３１には、当該取引装置２−Ｉが設置された店舗１−Ｉで取引される全ての商品情報が記憶されている。この商品情報には、商品の画像、商品の商品名、数字または英数字からなる商品識別番号、商品の金額、商品の在庫数、商品の発注先の情報等が含まれる。
　生体情報読取手段２６は、買い手の、指紋、掌紋、虹彩、静脈流、顔面等の生体情報を読み取り、生体情報として出力する。
　商品情報読取手段２７は、商品に付与されたバーコードまたはＲＦＩＤタグを読み取り、数字または英数字からなる商品識別番号を出力する。例えば、商品情報読取手段２７はバーコードリーダ装置等である。なお、本実施の形態では商品情報読取手段２７で商品の情報を読み取る構成としているが、売り手が入力手段で必要な情報を入力する場合等には、精算装置２−Ｉが商品情報読取手段２７を持たなくても良い。
　入力手段２２は、買い手がデータを入力するために使用される。例えば、入力手段２２はキーボードやテンキー等である。
　表示手段２４は、取引金額等の情報を表示する。例えば、表示手段２４はタッチパネル型であり、買い手または売り手は表示手段２４の表示画面にタッチして情報を選択する。本実施の形態では表示手段２４がタッチパネル型であるとして説明するが、これに限定されるものではない。
　通信手段２５は、ネットワーク５とのインタフェース機能を有し、ネットワーク５を介して他の端末、装置、サーバとのデータ通信を行う。
　出力手段２８は、例えばプリンタ等であり、請求書や領収書を印刷出力する。なお、電子メール等で請求書や領収書を買い手に送付する場合等は、精算装置２−Ｉが出力手段２８を持たなくても良い。
　図３は取引管理サーバ３の構成を示すブロック図である。
　取引管理サーバ３は制御手段３１と入力手段３２と記憶手段３３と表示手段３４と通信手段３５と生体情報読取手段３６と出力手段３７とから構成される。制御手段３１は取引管理手段３１１を有する。記憶手段３３は買い手情報データベース（ＤＢ）３３１を有する。
　買い手情報データベース３３１には、買い手の生体情報、買い手の取引履歴情報、買い手の前払い金額情報および買い手の個人情報が記憶されている。買い手毎に、買い手の生体情報、買い手の前払い金額情報、買い手の取引履歴情報、買い手の個人情報が関連付けられて記憶されている。買い手の生体情報は、指紋、掌紋、虹彩、静脈流および顔面のいずれかの情報である。買い手の前払い金額情報とは、前払い入金装置４より入金された金額の情報である。買い手の取引履歴情報には支払期日の情報と未納があるか否かを示す未納情報とが含まれる。買い手の個人情報とは、買い手の数字または英数字からなる識別番号、郵便番号、住所、氏名、年齢、性別、電話番号およびメールアドレス等である。
　買い手は、「商品先渡しの取引金額後払い」の取引を初めて利用する場合、予め自身の生体情報と買い手の個人情報とを精算装置２−Ｉから入力し、取引管理サーバ３へ送信する。取引管理サーバ３の取引管理手段３１１は、買い手の生体情報と買い手の個人情報とを関連づけて買い手情報データベース３３１に記憶する。
　また、取引管理手段３１１は、精算装置２−Ｉから、「商品先渡しの取引金額後払い」が完了した旨の通知を受けると、買い手情報データベース３３１の取引履歴情報を更新する。
　本実施の形態では、支払期日を超過した未納取引がない買い手に対してのみ、「商品先渡しの取引金額後払い」の取引が許可されるが、その許可条件はこれに限定されるものではない。
　図４は、前払い入金装置４の構成を示すブロック図である。
　前払い入金装置４は、買い手が前払い金を入金する際に使用される。前払い入金装置４は、生体情報入力手段４１、表示手段４２、入金手段４３、制御手段４４および通信手段４５から構成される。例えば、表示手段４２はタッチパネル型であり、以下ではタッチパネル型として説明するがこれに限定されるものではない。制御手段４４は、前払い入金装置４を制御する。
　次に、図５を用いて前払い金の入金動作について説明する。
　前払い入金装置４の制御手段４４は、表示手段４２に、買い手の生体情報の入力を指示する画面（生体認証指示画面）を表示させる（Ｓ５０１）。生体情報入力手段４１は買い手の指紋を読み込む（Ｓ５０２）。生体情報入力手段４１は読み込んだ指紋から特徴点を抽出し、特徴点の座標の集合からなる生体情報データを出力して制御手段４４に送信する（Ｓ５０３）。制御手段４４は、通信手段４５を介して、生体情報データを取引管理サーバ３に送信して買い手の前払い金額情報を問い合わせる（Ｓ５０４）。なお、本実施の形態では指紋を生体情報として用いたが、これに限定されるものではない。
　取引管理サーバ３の取引管理手段３１１は、買い手の生体情報データを受信すると（Ｓ５０５）、買い手情報データベース３３１を検索する（Ｓ５０６）。取引管理手段３１１は、買い手の生体情報データと一致するものが登録されていると判断すると、買い手の生体情報に関連付けられた入金済みの前払い金額情報を抽出し、通信手段３５を介して前払い入金装置４に送信する（Ｓ５０７、Ｓ５０８）。
　前払い入金装置４は、取引管理サーバ３から受信した買い手の前払い金額情報を表示手段４２に表示する（Ｓ５０９）。このとき、表示手段４２は、前払い希望金額を選択するためのボタン（タッチパネル型）も表示する。買い手は、表示手段４２に表示されたボタンの中からタッチパネルで前払い希望金額のボタンを選択し、さらに前払い希望金額を入金装置４３から入金する（Ｓ５１０）。前払い入金装置４は、入金金額情報を、取引管理サーバ３の取引管理手段３１１に送信する（Ｓ５１１）。そして、取引管理サーバ３の取引管理手段３１１は、入金金額情報を受信すると、これまでの前払い金額情報と入金金額情報との合計金額を新たな買い手の前払い金額情報として買い手情報データベース３３１を更新する（Ｓ５１２）。
　また、取引管理サーバ３の取引管理手段３１１は、買い手の生体情報データと一致するものが買い手情報データベース３３１に登録されていないと判断すると、前払い入金装置４にエラーを送信し（Ｓ５０７、Ｓ５１３）、前払い入金装置４の表示手段４２はエラーを表示する（Ｓ５１４）。
　次に、図６を用いて、取引精算システム６における全体の処理動作について説明する。
　まず、精算装置２−Ｉは取引金額の決定を行う（Ｓ６０１）。その後、取引方法として前払い金による支払いが選択されるとともに買い手の生体情報の入力が行われると（Ｓ６０２）、精算装置２−Ｉはその旨を取引管理サーバ３へ通知し、取引管理サーバ３は前払い金額情報を抽出する（Ｓ６０３）。
　精算装置２−Ｉは、前払金額情報の抽出結果を受け取ると、前払金により全額前払いが可能か否か判断する（Ｓ６０４）。前払金で全額支払い可と判断された場合、精算装置２−Ｉは、前払金で決済を行うとともにその旨を取引管理サーバ３へ通知する（Ｓ６０６）。そして、取引管理サーバ３は買い手情報データベース３３１を更新する（Ｓ６０７）。一方、前払いで全額支払い不可と判断された場合、精算装置２−Ｉは不足金額を算出し、不足金額および取引方法を表示させる（Ｓ６０５）。取引方法として「商品先渡しの取引金額後払い」が選択されると（Ｓ６０８）、取引管理サーバ３は支払期日を過ぎた未納取引があるか否かを判断する（Ｓ６０９）。支払期日を過ぎた未納取引がある場合には、取引管理サーバ３はその旨を精算装置２−Ｉに通知し、精算装置２−Ｉは取引を中止する（Ｓ６１０）。一方、支払期日を過ぎた未納取引がない場合には、取引管理サーバ３はその旨を精算装置２−Ｉに通知し、精算装置２−Ｉは「商品先渡しの取引金額後払い」の取引（前払いできない不足分に対しては後払いを行う取引）を許可する（Ｓ６１１）。精算装置２−Ｉは前払金による決済を行うとともに、不足分については後払いの取引を行う（Ｓ６１２）。次に、精算装置２−Ｉは請求書を発行する（Ｓ６１３）。その後、後日、買い手により不足分の後払いが行われると、精算装置２−Ｉは取引管理サーバ３に報告し（Ｓ６１４）、取引管理サーバ３は買い手情報データベース３３１を更新する（Ｓ６１５）。
　以下、図６の各ステップにおける詳細な動作について説明する。
　「１．取引金額の決定／前払い金による支払いの選択（図６のＳ６０１~Ｓ６０２）」
　精算装置２−Ｉの商品情報読取手段２７は、買い手の購入希望商品の情報（例えば、バーコード等）を読み取る。商品情報読取手段２７は、商品の数字または英数字からなる商品識別番号を出力し決算手段２１１に送信する。決算手段２１１は、商品データベース２３１から商品識別番号に基づいて購入希望商品の金額を検索する。決算手段２１１は、１個または複数の購入希望商品の合計金額（取引金額）を算出し、表示手段２４に表示させる。
　さらに、決算手段２１１は、取引金額を精算するための取引方法を表示手段２４に表示させる。表示手段２４は、複数の取引方法（「前払い金による支払い」、「商品先渡しの取引金額後払い」、「現金払い」および「クレジットカード払い」等）を表示する。ここでは、買い手が、複数の取引方法（「前払い金による支払い」、「商品先渡しの取引金額後払い」、「現金払い」および「クレジットカード払い」等）の中から、「前払い金による支払い」を選択したとする。
　精算装置２−Ｉの決算手段２１１は、表示手段２４から「前払い金による支払い」の選択信号を受信すると、この取引を管理するために数字または英数字からなる取引管理番号を生成し、「前払い金による支払い」の取引を開始する。
　決算手段２１１は、買い手の前払い金額情報を問い合わせるために、表示手段２４に生体情報の入力を買い手に指示するための画面を表示させる。生体情報入力手段２６は、買い手の生体情報として指紋を読み込む。生体情報入力手段２６は読み込んだ指紋から特徴点を抽出し、特徴点の座標の集合からなるデータを買い手の生体情報として出力する。なお、本実施の形態では生体情報として指紋を用いているが、これに限定されるものではない。その後、決算手段２１１は、取引管理番号、買い手の生体情報を、ネットワーク５を介して取引管理サーバ３の取引管理手段３１１に送信し、買い手の前払い金額情報を問い合わせる。
　「２．前払い金額情報の抽出（図６のＳ６０３）」
　取引管理サーバ３の取引管理手段３１１は、取引管理番号および買い手の生体情報を受信すると、買い手情報データベース３４を検索する。取引管理手段３１１は、買い手の生体情報と同じ生体情報が登録されていると判断すると、買い手の生体情報に関連付けられた買い手の前払い金額情報を出力する。取引管理手段３１１は、取引管理番号および買い手の前払い金額情報を、精算装置２−Ｉの決算手段２１１に送信する。
　「３．前払い金による支払いを許可するか否かの判断（図６のＳ６０４~Ｓ６０６）」
　精算装置２−Ｉの決算手段２１１は買い手の前払い金額情報を受信すると、前払い金額から取引金額を差し引いた前払い金残高を算出する（前払い金額−取引金額＝前払い金残高）。
　前払い金残高が正の値になった場合は、決算手段２１１は、前払い金によって取引金額の全額支払い可能と判断し、買い手に対して前払い金による支払いを許可する。そして、決算手段２１１は前払い金にて取引金額を決済し、前払い金額、取引金額および前払い金残高を表示手段２４に表示させる。
　一方、前払い金残高が負の値になった場合は、決算手段２１１は、前払い金額によって取引金額による全額支払い不可能と判断する。そして、決算手段２１１は、前払い金残高を不足金額として、前払い金額、取引金額および不足金額を表示手段２４に表示するとともに、不足金額を精算するための複数の取引方法（「商品先渡しの取引金額後払い」、「現金払い」、「クレジットカード払い」および「取引の中止」等）を表示手段２４に表示する。
　「４．買い手情報データベース３３１の更新（図６のＳ６０７）」
　前払金による支払いが許可されると、決算手段２１１は、決済取引管理番号および取引金額を取引管理サーバ３の取引管理手段３１１に送信する。取引管理手段３１１は、取引管理番号および取引金額情報を受信すると、前払い金額と取引金額との差分を買い手の新たな前払い金額として買い手情報データベース３３１を更新する。
　「５．不足金額を後払い（図６のＳ６０８~Ｓ６１２）」
　不足金額を精算するための複数の取引方法が表示手段２４に表示される。ここで、買い手により「商品先渡しの取引金額後払い」が選択されたとすると、その旨が取引管理サーバ３に通知される。取引管理手段３の取引管理手段３１１は、支払期日を過ぎた未納取引があるか否かを判断する。支払期日を過ぎた未納取引がある場合には、取引管理手段３１１はその旨を精算装置２−Ｉに通知し、精算装置２−Ｉの決算手段２１１はその取引を中止する。一方、支払期日を過ぎた未納取引がない場合には、取引管理手段３１１はその旨を精算装置２−Ｉに通知し、精算装置２−Ｉの決算手段２１１は「商品先渡しの取引金額後払い」の取引（前払金による前払いを行うとともに不足分については後払いを行う取引）を許可する。そして、決算手段２１１は「商品先渡しの取引金額後払い」の取引を行う。
　「６．不足分の請求書発行（図６のＳ６１３）」
　決算手段２１１は、買い手の個人情報（郵便番号、住所、氏名）を利用して買い手の氏名を請求先として、また後払い金額を請求金額として、請求先、請求金額、請求金額支払先口座および支払期日等が記載された請求書を作成し、精算装置２−Ｉの出力装置２８から請求書を印刷して出力するとともに、前払い金額全額で支払われた支払金額の領収書を印刷して出力する。
　売り手は、請求書と領収書と購入された１個または複数の商品とを買い手に渡す。買い手は、請求書と領収書と購入した１個または複数の商品とを受領する。
　「７．取引結果の報告（図６のＳ６１４~Ｓ６１５）」
　決算手段２１１は支払期日を取引の終了として、買い手との「商品先渡しの取引金額後払い」の取引結果を取引管理サーバ３の取引管理手段３１１に報告する。取引管理手段３１１は買い手情報データベース３３１を更新する。
　また、図示しないが、精算装置２−Ｉはネットワーク５を介して銀行端末等に接続されており、買い手により不足分の支払いが行われると、銀行端末等はその旨を精算装置２−Ｉに通知する。なお、買い手が不足分の支払いを行う端末は銀行端末に限定されるものではない。
　なお、本実施の形態では、支払期日を取引の終了として、決算手段２１１が取引結果を取引管理手段３１１に報告する構成としたが、銀行端末等から支払完了の報告を受ける毎に取引管理手段３１１に報告する構成としても良い。
　また、本実施の形態は、支払い期日が過ぎた未納取引がない場合にのみ、「商品先渡しの取引金額後払い」の取引を行う構成としたが、買い手の希望に応じて無条件に「商品先渡しの取引金額後払い」の取引を行うようにしても良い。
　また、本実施の形態は、購入商品とともに請求書および領収書を買い手に手渡す構成であるが、メール等を用いて買い手に請求書および領収書を送る構成にしても良い。
　また、取引管理サーバ３は、表示手段３４および出力手段３７を持たない構成であっても良い。
　このように、本発明の第１の実施の形態には、生体認証を伴う前払い取引を行うとともに前払金で全額支払い不可の場合に買い手が取引方法を選択する構成としたため、売り手に対してクレジットカードを所有できない買い手の信用保証を容易に行えるとともに、前払いできない不足分に対しては後払いを行う取引（「商品先渡しの取引金額後払い」の取引）を行うことも可能になるという効果がある。
　次に、本発明の第２の実施の形態について説明する。
　第１の実施の形態では、「商品先渡しの取引金額後払い」の取引が行われた場合、買い手の不具合取引（例えば、商品交換、返金、不当クレーム、不当要求、支払遅延、未払いおよび買い手の行方不明等を伴った取引である。）により売り手に損失が生じる可能性がある。第２の実施の形態では、以下で説明するように、前払いできない不足分に対して後払いを行う取引（商品先渡しの取引金額後払いの取引）が行われた場合に売り手に生じた損失を補償することを可能としている。
　第２の実施の形態における取引精算システム６の構成は第１の実施の形態と同様であるためその説明は省略する（図１）。また、前払い入金装置４の構成も第１の実施の形態と同様であるためその説明は省略する（図４）。また、前払い金の入金動作も第１の実施の形態と同様であるためその説明は省略する（図５）。
　図７は、第２の実施形態における精算装置２−Ｉの構成を示すブロック図である。
　第２の実施形態における精算装置２−Ｉは、制御手段２１が取引判断手段２１２を有する点、および、記憶手段２３が取引データベース（ＤＢ）２３２を有する点のみが第１の実施の形態における精算装置と異なる。
　取引判断手段２１２は、取引方法として「商品先渡しの取引金額後払い」を許可するか否かを判断する。
　取引データベース（ＤＢ）２３２には、「商品先渡しの取引金額後払い」として許可された取引の情報が記憶されている。例えば、取引管理番号、商品識別番号、請求金額、請求金額支払先口座、支払期日および買い手の個人情報（買い手の識別番号、郵便番号、住所および氏名）を含む取引管理情報が格納されている。
　図８は第２の実施形態における取引管理サーバ３の構成を示すブロック図である。
　第２の実施形態における取引管理サーバ３は、第１の実施の形態のように買い手の前払い金の入金／出金の管理、「商品先渡しの取引金額後払い」の取引の運用管理を行うだけでなく、買い手の不具合取引によって生じた未払い等による売り手の損失を上限補償金額範囲内で補償する。すなわち、売り手に損失が生じた場合、取引管理サーバ３は店舗に対して上限補償金額内で補償金を支払う。構成としては、制御手段３１が取引判断手段３１２を有する点と買い手の取引履歴情報の内容とが第１の実施の形態とは異なる。
　取引判断手段３１２は、「商品先渡し取引金額後払い」の取引を許可するか否かを判断する。
　買い手の取引履歴情報は買い手と店舗１−Ｉとの間の「商品先渡しの取引金額後払い」の取引結果を示す情報である。取引管理手段３１１は、精算装置２−Ｉから「商品先渡しの取引金額後払い」の取引結果を受信すると、その取引結果を反映するよう買い手情報データベース３３１の取引履歴情報を更新する。
　買い手の取引履歴情報には買い手の「商品先渡しの取引金額後払い」の取引評価情報が含まれる。
　図９に取引履歴情報の一例を示す。
　取引履歴情報は、取引毎に、取引日、店舗名、精算装置２−Ｉのアドレス、取引金額、取引結果、不具合レベル、格付けポイントおよび累積格付けポイントの情報を有する。累積格付けポイントは、取引毎の格付けポイントにより加減算される。
　取引結果は、正常取引、不当要求、不当クレーム、商品交換、返金、支払遅延、未払いおよび買い手の行方不明のいずれかから選択される。取引結果の不具合のレベルに応じて不具合レベルは０から５に分類される。重大な不具合の取引結果の場合には、不具合レベルが大きくなり、マイナス値の大きい格付けポイントとなる。なお、本実施の形態では不具合レベルの分類を５段階としたが、これに限定されるものではない。また、取引履歴情報の項目もこの例に限定されるものではない。
　図１０に、取引結果と不具合レベルと格付けポイントとの対応表の一例を示す。この対応表は取引データベース３３２に格納されている。正常取引では格付けポイントが＋１点であり、＋１点が図４の取引履歴情報の累積格付けポイントに加算される。未払いまたは買い手が行方不明の場合は重大な不具合として最大不具合レベルの５となる。また、この場合、格付けポイントは−４点であり、４点が図４の取引履歴情報の累積格付けポイントから減算される。なお、対応表の項目、レベルや格付けポイントの分類についてはこの例に限定されるものではない。
　図１１に、買い手の取引評価情報の一例を示す。
　買い手の取引評価情報は、買い手毎の、総取引件数、正常取引件数、正常取引率、不具合取引件数、累積格付けポイントおよびそれぞれの不具合レベルの１年間の不具合総件数からなる。正常取引率は、総取引件数に対する正常取引件数の割合である。不具合取引は正常取引以外の取引であり、具体的には、商品交換、返金、不当クレーム、不当要求、支払遅延、未払いおよび買い手の行方不明等を伴った取引である。不具合取引件数は、不具合取引の総数である。なお、この例では、不具合取引件数のカウント期間を１年としているがこれに限定されるものではない。また、買い手の評価情報の項目等についてもこの例に限定されるものではない。
　図１２を用いて、取引精算システム６における全体の処理動作について説明する。
　「取引金額の決定（Ｓ１２０１）」から「商品先渡しの取引金額後払いの選択（Ｓ１２０８）」までは第１の実施の形態における図６のＳ６０１~Ｓ６０８と同様であるため、その説明は省略する。Ｓ１２０９以降について以下に説明する。
　取引方法として「商品先渡しの取引金額後払い」が選択されると、精算装置２−Ｉは取引管理サーバ３に補償金額の問い合わせを行う（Ｓ１２０９）。取引管理サーバ３は、問い合わせを受けると、補償金により全額補償が可能か否かを判断する（Ｓ１２１０）。全額補償可の場合には、取引管理サーバ３はその旨を精算装置２−Ｉに通知し、精算装置２−Ｉは「商品先渡しの取引金額後払い」の取引（前払いできない不足分に対しては後払いを行う取引）を許可する（Ｓ１２１３）。一方、補償金により全額補償不可（すなわち、無保証金が発生する）と判断されると、取引管理サーバ３はその旨を精算装置２−Ｉに通知し、精算装置２−Ｉは取引を中止する（Ｓ１２１１）。
　「商品先渡しの取引金額後払い」の取引が許可されると（Ｓ１２１２）、精算装置２−Ｉは前払金による決済を行うとともに、不足分については後払いの取引を行う（Ｓ１０１３）。精算装置２−Ｉは請求書の発行を行う（Ｓ１２１４）。その後、精算装置２−Ｉは取引結果を取引管理サーバ３に報告する（Ｓ１２１５）。取引管理サーバ３は、買い手による未払いがあれば補償金による補償を行う（Ｓ１２１６、Ｓ１２１７）。
　以下、図１２の各ステップにおける詳細な動作について説明する。Ｓ１２０１~Ｓ１２０８は第１の実施の形態におけるＳ６０１~Ｓ６０８と同様であるため、その説明は省略する。
「６．不足金額を後払い（図１２のＳ１２０９）」
　精算装置２−Ｉの決算手段２１１は、買い手と店舗１−Ｉとの間の「商品先渡しの取引金額後払い」の取引において、買い手の不具合取引等により売り手の店舗１−Ｉに損失が生じた場合に、売り手の店舗１−Ｉに取引管理サーバ３が補償する金額（以降、補償金額）を、取引管理サーバ３に問い合わせる。
「７．補償金額／無保証金額の決定（図１２のＳ１２１０~Ｓ１２１１）」
　取引管理サーバ３の取引管理手段３１１は、生体情報をキーにして、買い手情報データベース３３１を検索し、生体情報に関連付けられた、買い手の取引履歴情報および買い手の個人情報を出力する。
　取引管理手段３１１は取引管理番号および買い手の取引履歴情報を取引判断手段３１２に送信する。
　取引判断手段３１２は、最初に、取引管理手段３１１が補償する上限の補償金額（以降、上限補償金額）の決定を行う。
　上限補償金額の決定には買い手の取引履歴情報を用いる。上限補償金額は、正常取引率の基準値と不具合レベルの不具合総件数（１年間分）の基準値との両方を満たすように設定される。
　図１６に、正常取引率の基準値および不具合レベルの不具合総件数（１年間分）の基準値の設定情報を示す。この設定情報は、取引管理装置３１の運用者により予め設定され、取引データベース３３２に記憶されている。
　正常取引率の基準値は、上限補償金額の上昇に応じて高くなるよう設定されている。例えば、上限補償金額が１０００円では、正常取引率の基準値は４０％であるが、上限補償金額が３０００円では、正常取引率の基準値は６０％に、設定されている。
　一方、不具合レベルの不具合総件数（１年間分）の基準値は、上限補償金額の上昇に応じて低くなるよう設定されている。例えば、上限補償金額が１０００円では、不具合レベル１の不具合総件数の基準値は２０件に設定され、上限補償金額が３０００円では、不具合レベル１の不具合総件数の基準値は１５件に設定されている。
　また、同じ上限補償金額でも、不具合のレベルが上昇する程、不具合総件数の基準値は低く設定されている。例えば、上限補償金額が１０００円では、不具合レベル１の不具合総件数の基準値は２０件に設定されているが、不具合レベル２の不具合総件数の基準値は５件に設定されている。なお、設定情報の内容はこの例に限定されるものではない。
　図１１の買い手の取引評価情報を用いて上限補償金額の設定方法について説明する。図１１の例では、正常取引率が６３％、不具合レベル１、２および４の不具合総件数がそれぞれ１件、並びに不具合レベル２および５の不具合総件数がそれぞれ０件であるため、これらの値は、上限補償金額が３０００円となる基準値を満たしている。したがって、この場合、取引判断装置３２は上限補償金額を３０００円と決定する。
　取引判断手段３１２は、不足金額から上限補償金額を差し引いた無補償金額を算出する
（不足金額−上限補償金額＝無補償金額）。
取引判断手段３１２は、無補償金額が負の値になった場合は、不足金額以上の金額が補償されていると判断して、不足金額を補償金額とする。
　一方、取引判断手段３１２は、無補償金額が正の値になった場合は、上限補償金額を補償金額とし、無補償金額を店舗１−Ｉの負担とする
　取引判断手段３１２は、取引管理番号と補償金額、または、取引管理番号と補償金額と無補償金額を、取引管理手段３１１に送信する。取引管理手段３１１は、取引管理番号と補償金額、または、取引管理番号と補償金額と無補償金額を、精算装置２−Ｉに送信する。
　精算装置２−Ｉの精算手段２１１は、取引管理サーバ３から取引管理番号と補償金額と無補償金額を受信した場合は、不足金額は一部補償されるが無補償金額は売り手の店舗１−Ｉの損失になると判断し、買い手との取引を中止する。決算手段２１１は、取引が中止になった旨を表示手段２４に表示し、買い手との取引を終了する。
「８．不足金額が全額補償／前払い金額による支払い（図１２のＳ１２１２~Ｓ１２１３）」
　精算手段２１１は、取引管理番号と補償金額とを受信した場合は、不足金額が補償金額で全額補償されていると判断して、買い手との「商品先渡しの取引金額後払い」の取引（前払いできない不足分に対しては後払いを行う取引）を許可し、その取引を行う。
　精算装置２−Ｉの決算手段２１１は、前払い金全額を支払い金額、補償金額を後払い金額として決済し、商品先渡し及び取引金額の後払いの取引を許可したこと及び取引金額、支払い金額、前払い金残高、後払い金額を表示装置４４に表示する。決算手段２１１は取引管理番号と支払金額とを取引管理サーバ３の取引管理手段３１１に送信する。
　取引管理サーバ３の取引管理装置３１は、支払金額を受信すると、前払い金額と支払金額との差分を買い手の新たな前払い金額とするように、買い手の生体情報に関連付けられた買い手の前払い金額を更新する。
「９．補償金額分の請求書発行（図１２のＳ１２１４）」
　精算装置２−Ｉの決算手段２１１は、買い手の個人情報（郵便番号、住所および氏名）を利用して買い手の氏名を請求先として、また、後払い金額を請求金額として、請求先、請求金額、請求金額支払先口座および支払期日等が記載された請求書を作成し、精算装置２−Ｉの出力装置２８から請求書を印刷して出力するとともに、前払い金額全額で支払われた支払金額の領収書を印刷して出力する。
　決算手段２１１は買い手の個人情報（郵便番号、住所および氏名）を利用して商品と共に買い手に請求書と領収書とを発送する。
　決算手段２１１は取引管理番号、商品識別番号、請求金額、請求金額支払先口座、支払期日および買い手の個人情報（買い手の識別番号、郵便番号、住所および氏名）を取引管理情報として取引データベース２３２に記憶する。
「１０．取引結果の報告（図１２のＳ１２１５~Ｓ１２１７）」
　決算手段２１１は支払期日を取引の終了として、買い手との「商品先渡しの取引金額後払い」の取引結果を取引管理サーバ３の取引管理手段３１１に報告する。買い手からの不当クレーム、未払い等は、買い手の取引履歴に不具合取引として記憶される。
　決算手段２１１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金があった場合は、「商品先渡しの取引金額後払い」の取引が正常取引であったことを取引結果として、取引管理サーバ３の取引管理手段３１１に送信する。送信されるこの取引結果の情報には、取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、前払い金額、補償金額および取引結果が含まれる。
　決算手段２１１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金が無い場合は、「商品先渡しの取引金額後払い」の取引が未払いによる不具合取引であることを取引結果として、取引管理サーバ３の取引管理手段３１１に送信する。送信されるこの取引結果の情報には、取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、前払い金額、補償金額および取引結果が含まれる。
　取引管理手段３１１は、未払いの取引結果を受信すると、取引管理番号から、先に決定した補償金額を抽出する。取引管理手段３１１は、店舗１−Ｉに対し補償金額分の補償を行う。そして、取引管理手段３１１は、精算装置２−Ｉから受信した買い手との取引結果（取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、前払い金額、補償金額および取引結果）から、不具合レベル、格付けポイントおよび累積格付けポイントを出力し、買い手情報データベース３４の取引履歴に追加記憶する。
　このように、本発明の第２の実施形態では、第１の実施の形態の構成に加えて、取引管理サーバ３が全額補償可能である「商品先渡しの取引金額後払い」の取引（前払いできない不足分に対しては後払いを行う取引）のみを許可する構成としたため、クレジットカードを所有できない買い手の売り手に対する信用保証が容易に行えるとともに、「商品先渡しの取引金額後払い」の取引が行われた際に売り手に損失が生じた場合にもそれを補償することができるという効果がある。
　次に、本発明の第３の実施の形態について説明する。
　第１の実施の形態は、ネットワーク５上に開設された仮想店舗のＷｅｂページで商品購入を行う場合にも適用可能である。第３の実施の形態では、第１の実施の形態の応用例として、買い手がネットワーク５上に開設された仮想店舗のＷｅｂページで商品購入を行う場合について説明する。
　図１３に、第３の実施の形態における取引精算システムを示す。
　本実施の形態はネットワーク５上に端末７が接続されている点のみが第１の実施の形態と異なる。
　図１４は端末７の構成を示すブロック図である。
　端末７は、制御手段７１と入力手段７２と記憶手段７３と表示手段７４と通信手段７５と生体情報入力手段７６とから構成される。買い手の生体情報（指紋）の入力は、端末７の生体情報入力手段７６を利用して行われる。精算装置２−Ｉから買い手への問い合わせは、端末７の表示装置７４を利用して行われる。また、買い手の返答は、端末７の入力手段７２を利用して行われる。なお、本実施の形態では、指紋を生体情報として説明するが、これに限定されなるものではない。
　精算装置２−Ｉ、取引管理サーバ３および前払い入金装置４の構成は第１の実施の形態と同様であるため、その詳細な説明は省略する（図２、図３および図４）。また、前払い金の入金動作も第１の実施の形態と同様であるためその説明は省略する（図５）。
　次に、図１５を用いて、取引精算システム６における全体の処理動作について説明する。
　買い手が仮想店舗のＷｅｂページ上で購入手続きを行うと（Ｓ１５０１）、精算装置２−Ｉが取引金額の決定を行う（Ｓ１５０２）。その後、端末７の表示手段７３で支払方法として前払い金額による支払いが選択されるとともに生体情報の入力が行われると（Ｓ１５０３）、端末７はその旨を精算装置２−Ｉに通知する。精算装置２−Ｉは取引管理サーバ３へ前払い金の問い合わせを行い（Ｓ１５０４）、取引管理サーバ３は前払い金額情報の抽出を行う（Ｓ１５０５）。
　精算装置２−Ｉは、前払金額情報の抽出結果を受け取ると、前払金により全額前払いが可能か否か判断する（Ｓ１５０６）。前払金で全額支払い可と判断された場合、精算装置２−Ｉは、前払金で決済を行うとともにその旨を取引管理サーバ３へ通知する（Ｓ１５０７）。そして、取引管理サーバ３は買い手情報データベース３３１を更新する（Ｓ１５０９）。一方、前払いで全額支払い不可と判断された場合、精算装置２−Ｉは不足金額を算出して端末７に通知し、端末７は不足金額および取引方法を表示する（Ｓ１５０８）。支払方法として「商品先渡しの取引金額後払い」が選択されると（Ｓ１５１０）、取引管理サーバ３は支払期限日を過ぎた未納取引があるか否かを判断する（Ｓ１５１１）。支払期限日を過ぎた未納取引がある場合には、取引管理サーバ３はその旨を精算装置２−Ｉに通知し、精算装置２−Ｉは取引を中止する（Ｓ１５１２）。一方、支払期限日を過ぎた未納取引がない場合には、取引管理サーバ３はその旨を精算装置２−Ｉに通知し、精算装置２−Ｉは「商品先渡し取引金額後払い」の取引（前払いできない不足分に対しては後払いを行う取引）を許可する（Ｓ１５１３）。精算装置２−Ｉは前払金による決済を行うとともに、不足分については後払いの取引を行い（Ｓ１５１４）、請求書を発行する（Ｓ１５１５）。買い手により不足分の後払いが行われると、精算装置２−Ｉは取引管理サーバ３に報告し（Ｓ１５１６）、取引管理サーバ３は買い手情報データベース３３１を更新する（Ｓ１５１７）。
　以下、図１５の各ステップにおける詳細な動作について説明する。
　「１．取引金額の決定／前払い金による支払いの選択（図１５のＳ１５０１~Ｓ１５０４）」
　端末７を用いてＷｅｂページ上で購入手続きが行われる点、端末７の表示手段７３で前払い金による支払方法の選択が行われる点、および端末７の生体情報入力手段７６で生体情報（指紋）の入力が行われる点のみが第１の実施の形態（図６のＳ６０１~６０２）と異なる。精算装置２−Ｉの決算手段２１１は、前払い金による支払いの取引方法の選択信号を、端末７から受信すると、この取引を管理するために数字または英数字からなる取引管理番号を生成し、前払い金額による支払いの取引を開始する。
　決算手段２１１は、端末７の表示手段７４に、買い手に生体情報の入力を指示する。端末７の表示手段７４は生体情報の入力画面を表示する。買い手は、生体情報入力手段７６から生体情報として自身の指紋を入力し、精算装置２−Ｉに送信する。精算装置２−Ｉは、取引管理番号および買い手の生体情報を、ネットワーク５を介して取引管理サーバ３の取引管理手段３１１に送信し、買い手の前払い金額を問い合わせる。
　その他は第１の実施の形態と同様であるため説明は省略する。
　「２．前払い金額情報の抽出（図１５のＳ１５０５）」
　第１の実施の形態（図６のＳ６０３）と同様であるため、説明は省略する。
　「３．前払い金による支払いを許可するか否かの判断（図１５のＳ１５０６~Ｓ１５０８）」
　前払い金による全額支払い不可能と判断された場合に、決算手段２１１が、前払い金残高を不足金額として、前払い金額、取引金額および不足金額を端末７に通知し、端末７の表示手段７４がそれを表示するとともに、不足金額を精算するための複数の取引方法（「商品先渡しの取引金額後払い」、「現金払い」、「クレジットカード払い」、および「取引の中止」等）を表示する点のみが第１の実施の形態（Ｓ６０４~Ｓ６０６）と異なる。その他については第１の実施の形態と同様である。
　「４．買い手情報データベース３３１の更新（図１５のＳ１５０９）」
　第１の実施の形態（図６のＳ６０７）と同様であるため、説明は省略する。
　「５．不足金額を後払い（図１５のＳ１５１０~Ｓ１５１４）」
　端末７の表示手段７４において、取引方法として「商品先渡しの取引金額後払い」が選択され、その旨が取引管理サーバ３に通知される点以外は第１の実施の形態（図６のＳ６０８~Ｓ６１２）と同様であるため、説明は省略する。
　「６．不足分の請求書発行（図１５のＳ１５１５）」
　第１の実施の形態（図６のＳ６１３）と同様であるため、説明は省略する。
　「７．取引結果の報告（図１５のＳ１５１６~Ｓ１５１７）」
　第１の実施の形態（図６Ｓ６１４~Ｓ６１５）と同様であるため、説明は省略する。
　本発明の第３の実施の形態も、第１の実施の形態と同様の効果を奏する。
　次に、本発明の第４の実施の形態について説明する。
　第２の実施の形態は、ネットワーク５上に開設された仮想店舗のＷｅｂページで商品購入を行う場合にも適用可能である。第４の実施の形態では、第２の実施の形態の応用例として、買い手がネットワーク５上に開設された仮想店舗のＷｅｂページで商品購入を行う場合について説明する。
　本実施の形態における取引精算システム６は第３の実施の形態と同様であるため、説明は省略する。また、精算装置２−Ｉ、取引管理サーバ３および前払い入金装置４の構成は第２の実施の形態と同様であるため、説明は省略する（図７、図８および図４）。
　本実施の形態における取引精算システム６の処理動作は、第２の実施の形態と第３の実施の形態との組み合わせである。具体的には、本実施の形態は、図１５のＳ１５０１~Ｓ１５１０と図１２のＳ１２０９~Ｓ１２１７との組み合わせである。本実施の形態では、「商品先渡しの取引金額後払い」の選択（図１２のＳ１２１３）が端末７の表示手段７４で行われる点のみが上記組み合わせと異なるが、その他については上記組み合わせと同様であるため、詳細な説明は省略する。
　本実施の形態も、第２の実施の形態と同様の効果を奏する。
　なお、本発明の第１~４の実施の形態では、取引管理サーバ３が買い手情報データベース３３１（買い手の生体情報、買い手の取引履歴情報、買い手の前払い金額情報および買い手の個人情報等）と取引データベース３３２（取引結果と不具合レベルと格付けポイントとの対応表）とを持つ構成であったが、これらの情報を精算装置２−Ｉが持つ構成にしても良い。この場合、第１~４の実施の形態において取引管理サーバが行っていた処理（補償金の支払いは除く）を精算装置２−Ｉが行うようにすれば良い。補償金の支払いに関しては、精算装置２−Ｉが、補償金の支払いが必要である旨を予め契約を結んでいる機関等に通知し、精算装置２−Ｉがその機関等に補償金の支払いを行わせるようにすれば良い。

　店舗等において、クレジットカードを所有できない買い手の売り手に対する信用保証を容易に行えるため、前払いの不足分に対して後払いを行う取引（商品先渡しの取引金額後払いの取引）に適用できる。

Claims

　買い手の前払い金を管理する前払い入金装置と、
　入金済みの前払い金額情報と前記買い手の生体情報とを関連づけて格納した記憶手段を有する取引管理サーバと、
　取引金額の情報および前記買い手の生体情報を受け取ると、前記取引管理サーバにアクセスして当該買い手の入金済みの前払い金額情報を取得し、該前払い金額情報および前記取引金額の情報に基づいて前払いの可否判断を行い、前払い金による全額支払い不可と判断した場合、無条件にまたは所定の許可条件を満たしたときに、不足金額に対する後払い取引を伴う前払い取引を開始する精算装置と、
　を備えたことを特徴とする取引精算システム。
　前記許可条件には、支払期日を過ぎた未納取引がないという条件が含まれることを特徴とする請求項１記載の取引精算システム。
　前記精算装置は、前払金による全額支払い不可と判断すると、前記取引管理サーバに取引保証に関する問い合わせを行い、
　前記許可条件には、前記問い合わせに応答して前記取引管理サーバから前記不足金額の補償が可能である旨の通知を受けるという条件が含まれることを特徴とする請求項１または２記載の取引精算システム。
　前記許可条件には、前記問い合わせに応答して前記取引管理サーバから前記不足金額の全額補償が可能である旨の通知を受けるという条件が含まれることを特徴とする請求項３記載の取引精算システム。
　前記取引管理サーバは、
　前記買い手の取引履歴情報が格納された記憶手段と、
　前記買い手の取引履歴情報に基づいて前記取引補償を行う上限補償金額を決定し、当該上限補償金額と前記不足金額とに基づいて前記不足金額の補償が可能か否かを判断する制御手段と、
　を備えたことを特徴とする請求項３または４記載の取引精算システム。
　前記買い手の取引履歴情報には、正常取引率の基準値と不具合レベル毎の不具合件数の基準値と前記買い手の生体情報とに対応づけされた前記上限補償金額の情報が含まれることを特徴とする請求項５記載の取引精算システム。
　支払期日を過ぎても前記不足金額が未納の場合、前記取引管理サーバは、前記不足金額を補償するための処理を行うことを特徴とする請求項３ないし６のいずれかに記載の取引精算システム。
　前記入金装置は、前記買い手の生体情報が入力されると、前記買い手の前払い金額情報を表示する表示手段を有することを特徴とする請求項１ないし７のいずれかに記載の取引精算システム。
　取引管理サーバに接続された精算装置において、
　制御手段と、
　生体情報読取手段と、
を備え、
　前記生体情報読取手段が取引金額の情報および買い手の生体情報を受け取ると、前記制御手段は、前記買い手の生体情報に基づいて前記取引管理サーバから買い手の入金済みの前払い金額情報を取得し、該前払い金額情報および前記取引金額の情報に基づいて前払いの可否判断を行い、前払い金による全額支払い不可と判断した場合、無条件にまたは所定の許可条件を満たしたときに、不足金額に対する後払い取引を伴う前払い取引を開始することを特徴とする精算装置。
　前記許可条件には、支払期日を過ぎた未納取引がないという条件が含まれることを特徴とする請求項９記載の精算装置。
　前記許可条件には、前記不足金額の補償が可能であるという条件が含まれることを特徴とする請求項９または１０記載の精算装置。
　前記許可条件には、前記不足金額の全額補償が可能であるという条件が含まれることを特徴とする請求項１１記載の精算装置。
　買い手の取引履歴情報が格納された記憶手段と、
　前記買い手の取引履歴情報に基づいて前記取引補償を行う上限補償金額を決定し、当該上限補償金額と前記不足金額とに基づいて前記不足金額の補償が可能か否かを判断する制御手段と、
　を備えたことを特徴とする取引管理サーバ。
　前記制御手段が、前記上限補償金額と前記不足金額とに基づいて、前記不足金額の全額補償が可能か否かを判断することを特徴とする請求項１３記載の取引管理サーバ。
　前記買い手の取引履歴情報には、正常取引率の基準値と不具合レベル毎の不具合件数の基準値と前記買い手の生体情報とに対応づけされた前記上限補償金額の情報が含まれることを特徴とする請求項１３または１４記載の取引管理サーバ。
　精算装置における取引精算方法において、
　取引金額の情報および買い手の生体情報を受け取る受信ステップと、
　前記買い手の生体情報に基づいて前記買い手の入金済みの前払い金額情報を取得する取得ステップと、
　前記前払い金額情報および前記取引金額の情報に基づいて前払いの可否判断を行う判断ステップと、
　前払い金による全額支払い不可と判断した場合、無条件にまたは所定の許可条件を満たしたときに、不足金額に対する後払い取引を伴う前払い取引を開始する取引ステップとを有することを特徴とする取引精算方法。
　前記許可条件には、支払期日を過ぎた未納取引がないという条件が含まれることを特徴とする請求項１６記載の取引精算方法。
　前記許可条件には、前記不足金額の補償が可能であるという条件が含まれることを特徴とする請求項１６または１７記載の取引精算方法。
　前記許可条件には、前記不足金額の全額補償が可能であるという条件が含まれることを特徴とする請求項１８記載の取引精算方法。
　前記判断ステップにおいて、買い手の取引履歴情報に基づいて前記取引補償を行う上限補償金額を決定し、前記上限補償金額と前記不足金額とに基づいて前記不足金額の補償が可能か否かを判断することを特徴とする請求項１８あるいは１９記載の取引精算方法。
　前記買い手の取引履歴情報には、正常取引率の基準値と不具合レベル毎の不具合件数の基準値と前記買い手の生体情報とに対応づけされた前記上限補償金額の情報が含まれることを特徴とする請求項２０記載の取引精算方法。
　さらに、前記不足金額が未納の場合に前記不足金額を補償するための処理を行う補償ステップを有することを特徴とする請求項１８ないし２１のいずれかに記載の取引精算方法。
　コンピュータに、
　入力手段から取引金額の情報および買い手の生体情報を受け取る受信ステップと、
　前記買い手の生体情報に基づいて買い手の入金済みの前払い金額情報を記憶手段から取得する取得ステップと、
　前記前払い金額情報および前記取引金額の情報に基づいて前払いの可否判断を行う判断ステップと、
　前払い金による全額支払い不可と判断した場合、無条件にまたは所定の許可条件を満たしたときに、不足金額に対する後払い取引を伴う前払い取引を開始する取引ステップと、
　を実行させることを特徴とするプログラム。
　前記許可条件には、支払期日を過ぎた未納取引がないという条件が含まれることを特徴とする請求項２３記載のプログラム。
　前記許可条件には、前記不足金額の補償が可能であるという条件が含まれることを特徴とする請求項２３または２４記載のプログラム。
　前記許可条件には、前記不足金額の全額補償が可能であるという条件が含まれることを特徴とする請求項２５記載のプログラム。
　コンピュータに、
　記憶手段に記憶された買い手の取引履歴情報に基づいて取引補償を行う上限補償金額を決定する決定ステップと、
　前記上限補償金額と前払い取引の不足金額とに基づいて、前記不足金額の補償が可能か否かを判断する判断ステップと、
　を実行させることを特徴とするプログラム。
　前記判断ステップにおいて、前記上限補償金額と前記不足金額とに基づいて、前記不足金額の全額補償が可能か否かを判断することを特徴とする請求項２７記載のプログラム。
　前記買い手の取引履歴情報には、正常取引率の基準値と不具合レベル毎の不具合件数の基準値と前記買い手の生体情報とに対応づけされた前記上限補償金額の情報が含まれることを特徴とする請求項２７または２８記載のプログラム。
　買い手の前払い金を管理する前払い入金装置と、
　取引金額の情報および買い手の生体情報を受け取ると、前記買い手の生体情報に基づいて当該買い手の入金済みの前払い金額情報を取得し、該前払い金額情報および前記取引金額の情報に基づいて前払いの可否判断を行い、前払い金による全額支払い不可と判断した場合、無条件にまたは所定の許可条件を満たしたときに、不足金額に対する後払い取引を伴う前払い取引を開始する精算装置と、
　を備えたことを特徴とする取引精算システム。
　前記許可条件には、支払期日を過ぎた未納取引がないという条件が含まれることを特徴とする請求項３０記載の取引精算システム。
　前記許可条件には、前記不足金額の補償が可能であるという条件が含まれることを特徴とする請求項３０または３１記載の取引精算システム。
　前記許可条件には、前記不足金額の全額補償が可能であるという条件が含まれることを特徴とする請求項３２記載の取引精算システム。
　前記精算装置は、
　前記買い手の取引履歴情報が格納された記憶手段と、
　前記買い手の取引履歴情報に基づいて前記取引補償を行う上限補償金額を決定し、当該上限補償金額と前記不足金額とに基づいて前記不足金額の補償が可能か否かを判断する制御手段と、
　を備えたことを特徴とする請求項３２または３３記載の取引精算システム。
　前記買い手の取引履歴情報には、正常取引率の基準値と不具合レベル毎の不具合件数の基準値と前記買い手の生体情報とに対応づけされた前記上限補償金額の情報が含まれることを特徴とする請求項３４記載の取引精算システム。
　支払期日を過ぎても前記不足金額が未納の場合、前記精算装置は、前記不足金額を補償するための処理を行うことを特徴とする請求項３２ないし３５のいずれかに記載の取引精算システム。