JP2010108249A - 商取引システム、クライアント装置、商取引方法、プログラム及び記録媒体 - Google Patents

Abstract

【課題】クレジットカードを所有できないものの所定の収入や財産を有する買い主が代金後払い取引を行うことができるようにする。
【解決手段】クライアント装置とサーバ装置とを有して構成され、クライアント装置は、生体情報取得部、取引可否判定部、精算管理部を有し、サーバ装置は、購買者情報データベース、取引管理部を有し、クライアント装置において、精算管理部が購買者から後払い取引の申し込みを受け付けたとき、生体情報取得部は購買者の生体情報を取得し、精算管理部は該生体情報とともに購買者の取引情報の取得要求をサーバ装置に送信し、サーバ装置において、取引管理部は該取得要求に応じて生体情報に関連付けられた購買者の取引情報を購買者情報データベースから取得してクライアント装置に送信し、クライアント装置において、取引可否判定部はサーバ装置から送信された購買者の取引情報を用いて後払い取引の可否を判定する。
【選択図】図１

Description

本発明は、商取引システム、クライアント装置、商取引方法、プログラム及び記録媒体に関し、特に、クレジットカードを所有できない買い主が商品代金の後払い取引を行う際に好ましく適用される技術に関するものである。

商取引における商品売買では、商品の引渡しと代金の支払いが同時に行われるのが基本である。もちろん、代金を後払いにして商品の引渡しを先行して受ける場合もある。例えば、零細企業や個人事業主が商取引を行う場合、商品の引渡しを先に行って商品代金を後でまとめて支払う（商品を掛けで買う）ような取引が行われる。このような取引は、取引相手同士の関係が親密で両者の信用のもとに取引が成り立っている。

一方、不特定多数の個人を相手にする取引において、上記のような掛けでの売買を採用することは事実上困難である。これに代わる取引方法としては、クレジットカードを利用したものがあり、現在の代金後払い取引の主流をなしているといえる。当然のことながら、買い主が店舗で商品代金の後払いを利用するには、クレジットカードの所有が必要である。そして、買い主がクレジットカードを所有するには、銀行などの金融機関の信用保証が必要となる。

しかしながら、現実には、購買者となりうる買い主に所定の収入や財産はあるものの、金融機関の信用保証がなくクレジットカードを所有できない場合がある。この場合、買い主の金融機関による信用保証がないため、店舗においてクレジットカードを利用した代金後払いによる商品の購入ができない。消費者が多様化する現代社会にあって、消費活動を停滞させずに活発化させるためにも、このような消費者に対応しうる商取引方法が望まれる。

ところで、例えば特許文献１では、電子商取引において決済の信頼性が向上する電子商取引の決済方法が開示されている。当該決済方法では、電子商取引の決済に関する信用枠をユーザに決済資金の少なくとも一部として与えておき、商取引に関する決済依頼がユーザから決済処理装置に入力されたことに基づいて、商取引の買掛金が商取引の買い主の決済資金の枠内であるか否かを判定し、枠内であるとき決済を承認することを少なくともユーザに電気通信路を介して通知する。

また、例えば特許文献２では、精度良く信用リスクを算出できるように支援する情報処理装置が開示されている。当該情報処理装置では、入力された債権に関する情報をもとに、債務者リスク特性と取引リスク特性との特性値の組み合わせを特定し、該特性値の組み合わせをもとに区分を特定して、特定された区分に基づいて債権における債務不履行発生率の推定値を特定する。
特開２００１−３１２６７５号公報 特開２００６−２４４３１０号公報

特許文献１の発明は、電子商取引の決済において決済資金の枠内であれば決済を承認するものであり、また特許文献２の発明は、ＢＩＳ規制に対応するためにデフォルト率やデフォルト時損失率を推計して信用リスクを算出できるようにするものであり、いずれの発明も、クレジットカードを所有できないものの所定の収入や財産を有する買い主に代金後払い取引を可能ならしめるものではない。

そこで、本発明は、クレジットカードを所有できないものの所定の収入や財産を有する買い主が代金後払い取引を行うことができるようにすることを目的とする。

かかる目的を達成するために、本発明の第１の商取引システムは、購買者との取引で使用されるクライアント装置と、購買者の情報を保持するサーバ装置と、を有して構成され、クライアント装置は、購買者の生体情報を取得する生体情報取得部と、生体情報に関連付けられた購買者の取引情報を用いて商品購入代金の後払い取引の可否を判定する取引可否判定部と、取引申し込みから取引確定に至るまでの購買者との取引を管理する精算管理部と、を有し、サーバ装置は、購買者の生体情報と購買者の取引情報を関連付けて保持する購買者情報データベースと、購買者情報データベースにおける取引情報を管理する取引管理部と、を有し、クライアント装置において、精算管理部が購買者から後払い取引の申し込みを受け付けたとき、生体情報取得部は、購買者の生体情報を取得し、精算管理部は、取得された生体情報とともに購買者の取引情報の取得要求をサーバ装置に送信し、サーバ装置において、取引管理部は、クライアント装置からの取得要求に応じて、生体情報に関連付けられた購買者の取引情報を購買者情報データベースから取得してクライアント装置に送信し、クライアント装置において、取引可否判定部は、サーバ装置から送信された購買者の取引情報を用いて、後払い取引の可否を判定する。

また、本発明の第１のクライアント装置は、購買者の取引情報を購買者の生体情報に関連付けて保持するサーバ装置とともに商取引システムを構成し、購買者の生体情報を取得する生体情報取得部と、生体情報に関連付けられた購買者の取引情報を用いて商品購入代金の後払い取引の可否を判定する取引可否判定部と、取引申し込みから取引確定に至るまでの購買者との取引を管理する精算管理部と、を有し、生体情報取得部は、精算管理部が購買者から後払い取引の申し込みを受け付けたとき購買者の生体情報を取得し、精算管理部は、取得された生体情報とともに購買者の取引情報の取得要求をサーバ装置に送信し、取引可否判定部は、サーバ装置において取得された生体情報に関連付けられた購買者の取引情報を用いて、後払い取引の可否判定を行う。

また、本発明の第１の商取引方法は、購買者との取引で使用されるクライアント装置と、購買者の情報を保持するサーバ装置と、を有して構成される商取引システムにおける商取引方法であって、サーバ装置は、購買者の生体情報と購買者の取引情報を関連付けて保持する購買者情報データベースを備え、クライアント装置において、購買者から商品購入代金の後払い取引の申し込みが受け付けられたとき、購買者の生体情報を取得する生体情報取得ステップと、クライアント装置において、取得された生体情報とともに購買者の取引情報の取得要求をサーバ装置に送信する取引情報要求ステップと、サーバ装置において、クライアント装置からの取得要求に応じて、生体情報に関連付けられた購買者の取引情報を購買者情報データベースから取得してクライアント装置に送信する取引情報送信ステップと、クライアント装置において、サーバ装置から送信された購買者の取引情報を用いて、後払い取引の可否を判定する取引可否判定ステップと、を有する。

また、本発明の第１のプログラムは、購買者との取引で使用されるクライアント装置と、購買者の情報を保持するサーバ装置と、を有して構成される商取引システムに用いられるプログラムであって、クライアント装置のコンピュータに、購買者から商品購入代金の後払い取引の申し込みが受け付けられたとき取得された購買者の生体情報とともに、購買者の取引情報の取得要求をサーバ装置に送信する取引情報要求ステップと、サーバ装置から送信された購買者の取引情報を用いて、後払い取引の可否を判定する取引可否判定ステップと、を実行させ、サーバ装置のコンピュータに、クライアント装置からの取得要求に応じて、生体情報に関連付けられた購買者の取引情報を、購買者の生体情報と購買者の取引情報が関連付けて保持された購買者情報データベースから取得してクライアント装置に送信する取引情報送信ステップを実行させる。

また、本発明の第１の記録媒体は、上記のプログラムを記録したコンピュータ読み取り可能な記録媒体である。

本発明によれば、クレジットカードを所有できないものの所定の収入や財産を有する買い主が代金後払い取引を行うことが可能となる。

本発明に係る商取引システム１００は、図１に示すように、サーバ装置１１０及びクライアント装置１２０から構成される。サーバ装置１１０は、購買者の生体情報と購買者の取引情報を関連付けて保持する購買者情報データベース１１１と、購買者情報データベース１１１で保持された取引情報を管理する取引管理部１１２と、を有する。クライアント装置１２０は、購買者の生体情報を取得する生体情報取得部１２１と、生体情報に関連付けられた購買者の取引情報を用いて商品購入代金の後払い取引の可否を判定する取引可否判定部１２２と、取引申し込みから取引確定に至るまでの購買者との取引を管理する精算管理部１２３と、を有する。商取引システム１００では、後払い取引の可否判定をクライアント装置１２０で行うように構成している。また、図示は省略するが、他の態様として、取引可否判定部をサーバ側に設けてサーバ側で取引判定を行ったり、クライアント側及びサーバ側に設けていずれの装置でも取引判定を行い得るように構成することも可能である。

例えば店舗に設置されたクライアント装置１２０は、買い手が店舗で選択した複数の商品の代金の合算を行う。買い手が後払いを希望したとき、クライアント装置１２０は、合算した代金の精算に関して、買い手の購買履歴を用いて代金後払いを許可するか否かを判断する。クライアント装置１２０は、購買履歴に不具合履歴が少ないことを信用保証として、代金後払いによる商品の購入を許可する。クライアント装置１２０は、買い手の生体情報を買い手の購買履歴の識別に用いる。なお、生体情報によって買い手と買い手の購買履歴とが１対１の対応となる。

全体的な処理の流れは以下のようになる。クライアント装置１２０は、買い手の信用保証として買い手の購買履歴を用いる。すなわち、クライアント装置１２０は、購買履歴に不具合履歴が少ないことを信用保証として、代金後払いによる商品の購入を許可する。クライアント装置１２０は、買い手の生体情報を利用して買い手を特定するとともに、買い手の生体情報を利用して買い手の購買履歴であることを保証された購買履歴を用いて、後払いを許可するか否かを判断する。具体的には、取引金額に応じた正常取引率の基準値と、不具合総件数の基準値を満たすと、後払いを許可する。そして、クライアント装置は、買い手の生体情報を利用して買い手の個人情報を抽出し、買い手に渡す請求先を作成する。

以下、図面を参照しながら、本発明の実施形態について詳細に説明する。なお、後述する実施形態は、本発明の好適な実施の形態であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの態様に限られるものではない。

［第１実施形態］
本発明の第１実施形態は、クライアント側で後払い取引の可否判定を行うように構成した商取引システムである。全体構成としては図１のシステム構成でよいが、ここでは取引可否判定部をサーバ側及びクライアント側に備える構成とする。

はじめに、本実施形態の商取引システムの構成について説明する。図２は、本実施形態の商取引システムの構成を示した全体図である。本実施形態の商取引システム１は、請求項のクライアント装置に相当し、複数の店舗に設置される取引金額精算装置２と、請求項のサーバ装置に対応する取引管理サーバ３とを有して構成される。取引金額精算装置２と取引管理サーバ３とは、インターネットや無線ＬＡＮなどのネットワーク４を介して接続され、相互に通信を行う。

図３は、本実施形態における取引金額精算装置２の構成を示したブロック図である。取引金額精算装置２は、精算装置２１、取引判定装置２２、生体情報入力装置２３、商品データベース２４、取引データベース２５、表示装置２６、リーダ装置２７、入力装置２８、出力装置３３、データ通信装置３６を有する。

精算装置２１は、請求項の精算管理部に対応し、取引金額清算装置２で行われる取引を管理、制御する。買い手からの商品購入の取引を管理、制御、処理する。また、買い手の生体情報の入手処理や、取引の許可処理を管理、制御する。また、取引判定装置２２は、請求項の取引可否判定部に対応し、買い手の購買履歴を用いて商品先渡しの取引金額後払いの取引方法を許可するか否かを判断する。また、生体情報入力装置２３は、請求項の生体情報取得部に対応し、買い手の生体情報（指紋、掌紋、虹彩、静脈流、顔面など）を読み取り、生体データとして出力する。

商品データベース２４は、店舗で取引する全ての商品の情報を保有する。商品データベース２４に記憶されている商品の情報は、商品の画像、商品の商品名、数字あるいは英数字からなる商品識別番号、商品の金額、商品の在庫数、商品の発注先からなる。また、取引データベース２５は、商品先渡しの取引金額後払いの取引方法を精算装置２１が許可した取引を記憶する。

表示装置２６は取引金額等を表示する。また、表示装置２６は、タッチパネル型の表示装置であり、買い手あるいは売り手が表示画面にタッチして選択したデータを出力する。リーダ装置２７は、商品に付与されたバーコードまたはＲＦＩＤタグから、数字あるいは英数字からなる商品識別番号を出力する。入力装置２８１１は、キーボードや十字キーなどからなり、売り手はキーボードや十字キーなどを利用してデータを入力する。出力装置３３は、プリンタなどからなり、請求書や領収書を印刷出力する。データ通信装置３６は、ネットワーク４とのインタフェース機能を有し、ネットワーク４を介してや他の端末、装置、サーバ（取引管理サーバ３を含む）とデータを相互に通信する。

図４は、本実施形態における取引管理サーバ３の構成を示したブロック図である。取引管理サーバ３は、取引管理装置３１、取引判定装置３２、出力装置３３、購買者情報データベース３４、取引データベース３５、データ通信装置３６を有する。

取引管理装置３１は、請求項の取引管理部に対応し、買い手の生体情報、買い手の個人情報、買い手の購買履歴を管理する。取引管理装置３１は、取引管理サーバ３を管理、制御する。また、取引管理装置３１は、購買者情報データベース３４と取引データベース３５のアクセス、取引判定装置３２の制御を行う。

購買者情報データベース３４は、請求項の購買者情報データベースに対応し、買い手の生体情報、買い手の購買履歴、買い手の個人情報を記憶する。買い手ごとに、買い手の生体情報、買い手の購買履歴、買い手の個人情報が関連付けられて記憶されている。買い手の生体情報は、指紋、掌紋、虹彩、静脈流、顔面のいずれかの情報である。買い手の個人情報は、買い手の数字あるいは英数字からなる識別番号、郵便番号、住所、氏名、年齢、性別、電話番号、メールアドレスである。

買い手は、商品先渡しの取引金額後払いの取引方法を初めて利用する前に、あらかじめ買い手の生体情報と買い手の個人情報を、取引金額清算装置２から取引管理サーバ３へ送信する。取引管理サーバ３の取引管理装置３１は、買い手の生体情報と買い手の個人情報を関連付けて購買者情報データベース３４に記憶する。

取引データベース３５は、取引金額精算装置２側で許可された代金後払い取引の情報を蓄積し、購買者の取引情報として保持する。当該取引情報は買い手と店舗との取引の結果である。取引管理装置３１は、店舗の取引金額精算装置２１から送信された取引の結果を受信すると、取引データベース３５に買い手ごとにそれぞれ記憶されている取引情報に、取引の結果を追加して記憶する。購買者の取引情報は、買い手の取引評価と買い手の個々の購買履歴とからなる。

取引判定装置３２、出力装置３３、データ通信装置３６は、取引金額精算装置２が有する各装置と同様の構成であり、その説明は省略する。なお、本実施形態では、クライアント側の取引金額精算装置２において、後払い取引の可否判定や請求書作成（出力）の処理を行うため、取引管理サーバ３の取引判定装置３２及び出力装置３３では、後払い取引の可否判定や請求書作成の処理を行わない。

図５は、本実施形態における買い手の取引評価のデータ例を示した図である。買い手の取引評価は、買い手ごとの総取引件数、正常取引件数、正常取引率、不具合取引件数からなる。正常取引率は、総取引件数に対する正常取引件数の割合である。不具合取引件数は、正常取引以外の取引結果の総数である。

図６は、本実施形態における買い手の購買履歴のデータ例を示した図である。買い手の個々の購買履歴は、１取引ごとに取引日、店舗名、店舗の取引金額精算装置２１のアドレス、取引金額、取引結果、不具合レベルからなる。

図７は、本実施形態における不具合レベルテーブルの例を示した図である。購買履歴項目の取引結果は、正常取引、不当要求、不当クレーム、商品交換、返金、支払遅延、未払い、買い手の行方不明からなる。取引結果の不具合のレベルに応じて不具合レベルが０から５に分類される。重大な不具合の取引結果は、不具合レベルが大きくなる。正常取引では不具合がないとして不具合レベルは０であり、未払いまたは買い手の行方不明は重大な不具合として最大不具合レベルの５に対応する。

次に、本実施形態の商取引システムにおける各装置の具体的な動作処理について説明する。図９は、本実施形態の商取引システムにおける各装置の動作処理の流れを示したシーケンスチャートである。なお、繰り返しになるが、本実施形態では、取引金額清算装置２が購買者の取引履歴を用いて商品代金の後払い取引の可否判定を行う。

買い手は店舗に入店すると、購入希望の１個あるいは複数の商品を選択する。買い手は商品の取引金額の精算を行うため、取引金額清算装置２の前に進む。売り手はそれぞれの商品に付与されたバーコードをリーダ装置２７から読み込ます。リーダ装置２７は、読み込んだバーコードから商品の数字あるいは英数字からなる商品識別番号を取得し、精算装置２１に出力する（Ｓ１０１０）。精算装置２１は、リーダ装置２７からの商品識別番号を用いて商品データベース２４を検索し、それぞれの商品の金額を取得する（Ｓ１０２０）。精算装置２１は、１個あるいは複数の商品の金額を合算し、買い手が購入希望の商品の合計の金額を表示装置２６に表示する（Ｓ１０３０）。

さらに、精算装置２１は、表示装置２６に、取引金額を清算するための取引方法の選択を要求する。表示装置２６に複数の取引方法（商品先渡しの取引金額後払い、現金払い、クレジットカード払い）が示される。買い手は、複数の取引方法（商品先渡しの取引金額後払い、現金払い、クレジットカード払い）の中から、表示装置２６のタッチパネルを利用して、商品先渡しの取引金額後払いの取引方法を選択する。精算装置２１は、商品先渡しの取引金額後払いの取引方法の選択信号を表示装置２６から受信する（Ｓ１０４０）。

精算装置２１は、商品先渡しの取引金額後払いの取引方法の選択信号を受信すると、買い手が購入希望の商品の合計の金額を取引金額として、取引金額に対して商品先渡しの取引金額後払いの取引方法を許可するか否かの判断を開始する。精算装置２１はこの取引を管理するために、数字あるいは英数字からなる取引管理番号を生成する（Ｓ１０５０）。

次いで、精算装置２１は、表示装置２６に、買い手に生体情報の入力を指示する画面を表示させる。買い手は、生体情報入力装置２３から生体情報として例えば指紋を読み込ます。生体情報入力装置２３は読み込んだ指紋から特徴点を抽出し、特徴点の座標の集合からなるデータを買い手の生体情報として取得し、精算装置２１に出力する（Ｓ１０６０）。そして、精算装置２１は、取引管理番号、買い手の生体情報、買い手の取引情報の取得要求を、データ通信装置３６によりネットワーク４を介して、取引管理サーバ３の取引管理装置３１に送信する（Ｓ１０７０）。

一方で、取引管理サーバ３の取引管理装置３１は、取引金額精算装置２から受信した買い主の生体情報をキーにして、購買者情報データベース３４を検索する（Ｓ１０８０、Ｓ１０９０）。そして、取引管理装置３１は、生体情報に関連付けられた買い手の取引情報、買い手の個人情報を取得する（Ｓ１１００）。買い手の取引履歴は、先に述べたように、買い手の取引評価と買い手の個々の購買履歴からなる。そして、取引管理装置３１は、取引管理番号、買い手の取引情報、買い手の個人情報を、ネットワーク４を介して取引金額清算装置２の精算装置２１に送信する（Ｓ１１１０）。

取引金額清算装置２の精算装置２１は、取引管理番号、買い手の取引情報、買い手の個人情報を受信すると、取引判定装置２２に取引管理番号、取引金額、買い手の取引情報を送信する（Ｓ１１２０）。取引判定装置２２は、精算装置２１から受信した取引管理番号、取引金額、買い手の取引情報を用いて、取引金額に対して、買い手が選択した商品先渡しの取引金額後払いの取引方法を許可するか否かの判断を開始する（Ｓ１１３０）。

図１０は、本実施形態における取引可否判定処理の流れを示したフローチャートである。まず、取引金額精算装置２の取引判定装置２２は、取引管理サーバから受信した買い手の取引情報から取引評価、購買履歴を取得する（Ｓ１１３１）。そして、取引評価から正常取引率を抽出する（Ｓ１１３２）。次いで、取引判定装置２２は、取引金額に対応する不具合レベルごとの取引件数を購買履歴から抽出する（Ｓ１１３３）。正常取引率が基準値以上で（Ｓ１１３４／ＹＥＳ）、不具合レベルごとの取引件数が基準値以下である場合（Ｓ１１３５／ＹＥＳ）に、商品代金の後払い取引を許可する判定を行う（Ｓ１１３６）。それ以外の場合（Ｓ１１３４／ＮＯ、Ｓ１１３５／ＮＯ）は、後払い取引を拒否する判定を行う（Ｓ１１３７）。

取引可否判定についてさらに具体的に説明する。商品先渡しの取引金額後払いの取引方法を許可するか否かの判断は、取引情報の中から、取引金額に応じた買い手の正常取引率と、取引金額と買い手のそれぞれの不具合のレベル（不具合レベル１〜不具合レベル５）に応じた不具合総件数を用いる。なお、取引金額が低い場合は、取引金額に応じた買い手の正常取引率のみ、あるいは取引金額と買い手のそれぞれの不具合のレベル（不具合レベル１〜不具合レベル５）に応じた不具合総件数のみを用いて判断してもよい。

取引金額に応じた買い手の正常取引率と、取引金額と買い手のそれぞれの不具合のレベル（不具合レベル１〜不具合レベル５）に応じた不具合総件数は、売り手により取引判定装置２２に予め基準値が設定されている。商品先渡しの取引金額後払いの取引方法を許可する条件として、取引金額に応じた正常取引率と、取引金額と買い手のそれぞれの不具合のレベル（不具合レベル１〜不具合レベル５）に応じた不具合総件数（１年間分）が、基準値を満たす必要がある。

図８は、本実施形態における基準値テーブルの例を示した図である。基準値テーブルは、取引金額に応じた正常取引率の基準値と、取引金額と買い手のそれぞれの不具合のレベル（不具合レベル１〜不具合レベル５）に応じた不具合総件数（１年間分）の基準値が設定されたものである。

取引許可と判断する正常取引率の基準値は、取引金額の上昇に応じて高くなるよう設定されている。例えば、取引金額が９９９円以下の正常取引率の基準値は４０％であるが、取引金額が１，０００円から９，９９９円の正常取引率の基準値は６０％に、設定されている。取引許可と判断するには、買い手の正常取引率が、取引金額に応じた正常取引率の基準値と同じ、または基準値より高いことが必要である。例えば、取引金額が２，０００円であると、取引許可と判断するには、正常取引率が６０％以上である必要がある。

取引金額と買い手のそれぞれの不具合のレベル（不具合レベル１〜不具合レベル５）に応じた不具合総件数（１年間分）の基準値は、取引金額の上昇に応じて低くなるよう設定されている。例えば、取引金額が９９９円以下の不具合レベル１の不具合総件数の基準値は２０件に設定され、取引金額が１，０００円から９，９９９円の不具合レベル１の不具合総件数の基準値は１５件に設定されている。また、同じ取引金額でも、不具合のレベルが上昇する程、不具合総件数の基準値は低く設定されている。例えば、取引金額が９９９円以下の、不具合レベル１の不具合総件数の基準値は２０件に設定され、不具合レベル２の不具合総件数の基準値は５件に設定されている。

取引許可と判断するには、買い手のそれぞれの不具合レベルに対する不具合総件数（１年間分）が、取引金額に応じた不具合総件数の基準値と同じ、または基準値より低いことが必要である。例えば、取引金額が２，０００円の場合、取引許可と判断するには、不具合レベル１の不具合総件数が１５件以下であり、不具合レベル２の不具合総件数が４件以下であり、不具合レベル３の不具合総件数が２件以下であり、不具合レベル４の不具合総件数が１件以下であり、不具合レベル１の不具合総件数が０件以下である必要がある。
不具合レベル５の不具合総件数の基準値（１年間）は、０件に設定されている。したがって、買い手と電子商店装置２間の取引が、不具合レベル５に対応する取引結果（未払いまたは買い手の行方不明）となると、買い手に対して全ての取引は許可されない。

商取引システムにおける各装置の動作処理（図９）の説明に戻る。取引判定装置２２は、図１０に示すように、買い手の取引情報が取引金額に応じた商品先渡しの取引金額後払いの取引方法を許可する条件を満たしていると判断すると、買い手が選択した商品先渡しの取引金額後払いの取引を許可する。そして、取引判定装置２２は、取引許可番号を生成し、取引管理番号、買い手の個人情報とともに精算装置２１に送信する（Ｓ１１４０）。

取引管理番号、取引許可番号、個人情報を受信した精算装置２１は、取引許可番号の取得により、買い手が選択した商品先渡しの取引金額後払いの取引を取引判定装置２２が許可したと認識する。そして、精算装置２１は、商品先渡し及び取引金額の後払いの取引方法を許可したことを表示装置２６に表示する。また、精算装置２１は、買い手の個人情報（郵便番号、住所、氏名）を用いて買い手の氏名を請求先とし、また取引金額を請求金額として、請求先、請求金額、請求金額支払先口座、支払期日などが記載された請求書を作成し、出力装置３３から請求書を印刷して出力する（Ｓ１１５０）。

売り手は、請求書と１個または複数の商品を買い手に渡し、買い手は、請求書と商品を受領する。精算装置２１は、取引管理番号、商品識別番号、請求金額、請求金額支払先口座、支払期日、買い手の個人情報（買い手の識別番号、郵便番号、住所、氏名）を取引管理情報として、取引データベース２５に格納する（Ｓ１１６０）。

そして、精算装置２１は支払期日を取引の終了として、買い手との取引結果の情報を取引管理装置３１に報告する（Ｓ１１７０）。買い手からの不当クレーム、未払いなどは、買い手の購買履歴に不具合取引として記憶される。精算装置２１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金があった場合は、正常取引であったことを取引の結果として、取引管理装置３１に送信する。精算装置２１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金がない場合は、未払いによる不具合取引で不具合レベル５であることを取引の結果として、取引管理装置３１に送信する。買い手の未払いによる取引金額分の損失は、売り手の店舗の損失とする。

これに対し、取引管理サーバ３の取引管理装置３１は、取引金額清算装置２の精算装置２１から受信した取引結果情報を、購買者情報データベース３４の取引情報（取引評価、購買履歴）に追加記憶する（Ｓ１１８０、Ｓ１１９０）。

［第２実施形態］
本発明の第２実施形態は、サーバ側で後払い取引の可否判定を行うように構成した商取引システムである。システムの全体構成は、第１実施形態と同様であるため説明を省略し、システムにおける各装置の具体的な動作処理について説明する。図１１は、本実施形態の商取引システムにおける各装置の動作処理の流れを示したシーケンスチャートである。

取引金額精算装置２において、商品の取引金額の精算を行うため、リーダ装置２７がバーコードを読み込んで商品識別番号を取得し（Ｓ２０１０）、精算装置２１がリーダ装置２７からの商品識別番号を用いて商品データベース２４を検索して各商品の金額を取得する（Ｓ２０２０）。そして、精算装置２１は、商品の合計金額を取得する（Ｓ２０３０）。さらに、精算装置２１は、取引金額を清算するための取引方法を取得する（Ｓ２０４０）。そして、精算装置２１は、商品先渡しの取引金額後払いの取引方法の選択信号を受信すると、この取引を管理するための取引管理番号を生成する（Ｓ２０６０）。次いで、精算装置２１は、表示装置２６に、買い手に生体情報の入力を指示する画面を表示させ、生体情報入力装置２３が買い手の生体情報を取得する（Ｓ２０６０）。ここまでは、第１実施形態と同様である。

次に、精算装置２１は、取引管理番号、買い手の生体情報、取引金額（精算金額）、取引可否判定結果の取得要求を、データ通信装置３６によりネットワーク４を介して、取引管理サーバ３の取引管理装置３１に送信する（Ｓ２０７０）。本実施形態では、取引可否判定をサーバ側で行うことから、取引可否判定に使用する情報をクライアント側からサーバ側へ送る必要がある。そのため、クライアント側は第１実施形態で送信していなかった取引金額の情報をサーバ側へ送信している。また、後払い取引の許可判定が出された場合に、クライアント側において買い手との取引を確定させる必要があるため、取引可否判定結果の取得要求をサーバ側へ送信している。

他方、取引管理サーバ３の取引管理装置３１は、取引金額精算装置２から受信した買い主の生体情報をキーにして、購買者情報データベース３４を検索する（Ｓ２０８０、Ｓ２０９０）。そして、取引管理装置３１は、生体情報に関連付けられた買い手の取引情報、買い手の個人情報を取得し、取引判定装置３２に送信する（Ｓ２１００）。買い手の取引履歴は、先に述べたように、買い手の取引評価と買い手の個々の購買履歴からなる。取引判定装置３２は、取引管理装置３１から受信した取引金額、買い手の取引情報を用いて、取引金額に対して、買い手が選択した商品先渡しの取引金額後払いの取引方法を許可するか否かの判断を開始する（Ｓ２１１０）。取引可否判定処理のフローは第１実施形態と同様に図１２に示すとおりであり、また取引可否判定の具体的手法も第１実施形態で述べたものと同様であるため、ここでは省略する。

取引判定装置３２は、図１２に示すように、買い手の取引情報が取引金額に応じた商品先渡しの取引金額後払いの取引方法を許可する条件を満たしていると判断すると、買い手が選択した商品先渡しの取引金額後払いの取引を許可する。そして、取引判定装置２２は、取引許可番号を生成し、取引管理番号や個人情報とともに精算装置２１に送信する（Ｓ２１２０、Ｓ２１３０）。

取引管理番号、取引許可番号、個人情報を受信した精算装置２１は、取引許可番号の取得により、買い手が選択した商品先渡しの取引金額後払いの取引を取引判定装置２２が許可したと認識する。そして、精算装置２１は、商品先渡し及び取引金額の後払いの取引方法を許可したことを表示装置２６に表示する（Ｓ２１４０）。精算装置２１は、入力装置２８からの取引確定情報の入力を受け付け、取引確定情報を取得する（Ｓ２１５０）。取引確定情報は、買い手との取引の確定を示す情報で、例えば商品の引渡しが行われる際に入力される取引確定フラグでもよい。そして、精算装置２１は、取引確定情報を取得した後、取引管理番号、取引確定情報、請求金額を取引管理サーバ３に送信する（Ｓ２１６０）。

取引管理装置３１は、取引管理番号、取引確定情報、請求金額を取引金額精算装置２から受信した後（Ｓ２１７０）、買い手の個人情報（郵便番号、住所、氏名）を用いて買い手の氏名を請求先とし、また取引金額を請求金額として、請求先、請求金額、請求金額支払先口座、支払期日などが記載された請求書を作成し、出力装置３３から請求書を印刷して出力する（Ｓ２１８０）。なお、出力された請求書は、買い手の個人情報（郵便番号、住所、氏名）を用いて、買い手に発送される。また、取引管理装置３１は、取引管理番号、商品識別番号、請求金額、請求金額支払先口座、支払期日、買い手の個人情報（買い手の識別番号、郵便番号、住所、氏名）を取引管理情報として、取引データベース３５に格納する（Ｓ２１９０）。

後日、取引管理装置３１は、支払期日を取引の終了として、買い手との取引結果の情報を取得する（Ｓ２２００）。買い手からの不当クレーム、未払いなどは、買い手の購買履歴に不具合取引として記憶される。そして、取引管理装置３１は、取得した取引結果情報を用いて購買者情報データベース３４の取引情報（取引評価、購買履歴）を更新する（Ｓ２２１０）。取引管理装置３１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金があった場合は、正常取引であったことを購買履歴として、購買者情報データベース３４の取引情報に追加する。取引管理装置３１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金がない場合は、未払いによる不具合取引で不具合レベル５であることを購買履歴として、購買者情報データベース３４の取引情報に追加する。

また、取引管理装置３１は、請求金額支払先口座に買い手から請求金額の入金があった場合は、店舗に入金分を送金する。逆に、取引管理装置３１は、請求金額支払先口座に買い手から請求金額の入金がなく未払い状態と判断すると、店舗に取引金額と同額の金額を補償し、店舗に補償金を送金する。

上述してきたような本発明の実施形態によれば、店舗において、買い手の購買履歴を用いて、取引金額に応じた商品先渡しの取引金額後払いの取引が可能となる。また、買い手の生体情報を用いて、購買履歴が買い手の購買履歴であることを保証することが可能となる。また、電子商店は、買い手の生体情報を用いて入手した買い手の個人情報（郵便番号、住所、氏名）を利用して、買い手の請求書を作成することが可能となる。

なお、上述する実施形態は、本発明の好適な実施形態であり、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。

すなわち、本実施形態における商取引システムで実行されるプログラムは、先に述べた各部（精算管理部、取引可否判定部、取引管理部等）を含むモジュール構成となっており、実際のハードウェアを用いて具体的手段を実現する。すなわち、コンピュータ（ＣＰＵ）が所定の記録媒体からプログラムを読み出して実行することにより上記各手段が主記憶装置上にロードされ、精算管理部、取引可否判定部、取引管理部等が主記憶装置上に生成される。

本実施形態における商取引システムで実行されるプログラムは、インターネット等のネットワークに接続されたコンピュータ上に格納され、ネットワーク経由でダウンロードさせることにより提供されるように構成してもよい。また、上記プログラムをインターネット等のネットワーク経由で提供あるいは配布するように構成してもよい。

また、上記プログラムは、インストール可能な形式又は実行可能な形式のファイルで、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ、不揮発性のメモリカード等のコンピュータで読み取り可能な記録媒体に記録されて提供されるように構成してもよい。また、上記プログラムは、ＲＯＭ等にあらかじめ組み込んで提供するように構成してもよい。

この場合、上記記録媒体から読み出された又は通信回線を通じてロードし実行されたプログラムコード自体が前述の実施形態の機能を実現することになる。そして、そのプログラムコードを記録した記録媒体は本発明を構成する。

本発明に係る商取引システムの構成を示した図である。 本発明の実施形態に係る商取引システムの構成を示した全体図である。 本発明の実施形態に係る取引金額精算装置の構成を示したブロック図である。 本発明の実施形態に係る取引管理サーバの構成を示したブロック図である。 本発明の実施形態における買い手の取引評価のデータ例を示した図である。 本発明の実施形態における買い手の購買履歴のデータ例を示した図である。 本発明の実施形態における不具合レベルテーブルの例を示した図である。 本発明の実施形態における基準値テーブルの例を示した図である。 本発明の実施形態における各装置の動作処理の流れを示したシーケンスチャートである。 本実施形態における取引可否判定処理の流れを示したフローチャートである。 本発明の実施形態における各装置の動作処理の流れを示したシーケンスチャートである。

符号の説明

１，１００ 商取引システム
２ 取引金額精算装置
３ 取引管理サーバ
４ ネットワーク
２１ 精算装置
２２，３２ 取引判定装置
２３ 生体情報入力装置
２４ 商品データベース
２５，３５ 取引データベース
２６ 表示装置
２７ リーダ装置
２８ 入力装置
３１ 取引管理装置
３３ 出力装置
３４ 購買者情報データベース
３６ データ通信装置
１１０ サーバ装置
１１１ 購買者情報データベース
１１２ 取引管理部
１２０ クライアント装置
１２１ 生体情報取得部
１２２ 取引可否判定部
１２３ 精算管理部

Claims (15)

1. 購買者との取引で使用されるクライアント装置と、購買者の情報を保持するサーバ装置と、を有して構成される商取引システムであって、
   前記クライアント装置は、
   購買者の生体情報を取得する生体情報取得部と、
   生体情報に関連付けられた購買者の取引情報を用いて商品購入代金の後払い取引の可否を判定する取引可否判定部と、
   取引申し込みから取引確定に至るまでの購買者との取引を管理する精算管理部と、
   を有し、
   前記サーバ装置は、
   購買者の生体情報と購買者の取引情報を関連付けて保持する購買者情報データベースと、
   前記購買者情報データベースにおける前記取引情報を管理する取引管理部と、
   を有し、
   前記クライアント装置において、前記精算管理部が購買者から前記後払い取引の申し込みを受け付けたとき、前記生体情報取得部は、購買者の生体情報を取得し、前記精算管理部は、前記取得された生体情報とともに購買者の取引情報の取得要求を前記サーバ装置に送信し、
   前記サーバ装置において、前記取引管理部は、前記クライアント装置からの前記取得要求に応じて、前記生体情報に関連付けられた購買者の取引情報を前記購買者情報データベースから取得して前記クライアント装置に送信し、
   前記クライアント装置において、前記取引可否判定部は、前記サーバ装置から送信された購買者の取引情報を用いて、前記後払い取引の可否を判定することを特徴とする商取引システム。
2. 前記サーバ装置の前記購買者情報データベースは、購買者の生体情報と購買者の取引情報と購買者の個人情報を関連付けて保持し、
   前記クライアント装置の前記精算管理部は、前記後払い取引の許可判定結果を受けて、前記購買者情報データベースに保持された前記生体情報に関連付けられた前記購買者の個人情報を取得し、前記取得した前記個人情報を用いて前記後払い取引に係る請求書を作成することを特徴とする請求項１に記載の商取引システム。
3. 前記クライアント装置の前記精算管理部は、前記後払い取引による取引結果情報を前記サーバ装置に送信し、
   前記サーバ装置の前記取引管理部は、前記精算管理部から受信した前記取引結果情報を用いて前記購買者情報データベースにおける前記取引情報を更新することを特徴とする請求項１又は２に記載の商取引システム。
4. 前記取引情報は、購買者の取引全体についての正常取引率を含む取引評価と、個々の取引についての取引金額及び取引結果に応じた不具合レベルごとの取引件数を含む購買履歴と、から構成されることを特徴とする請求項１から３のいずれか１項に記載の商取引システム。
5. 前記取引情報は、購買者の取引全体についての正常取引率を含む取引評価と、個々の取引についての取引金額及び取引結果に応じた不具合レベルごとの取引件数を含む購買履歴と、から構成され、
   前記クライアント装置の前記取引可否判定手段は、前記取得された前記購買者の取引情報のうち正常取引率が所定の閾値以上である場合に前記後払い取引の許可判定を行うことを特徴とする請求項１から４のいずれか１項に記載の商取引システム。
6. 前記取引情報は、購買者の取引全体についての正常取引率を含む取引評価と、個々の取引についての取引金額及び取引結果に応じた不具合レベルごとの取引件数を含む購買履歴と、から構成され、
   前記クライアント装置の前記取引可否判定手段は、前記取得された前記購買者の取引情報のうち不具合レベルごとの取引件数が所定の閾値以下である場合に前記後払い取引の許可判定を行うことを特徴とする請求項１から５のいずれか１項に記載の商取引システム。
7. 購買者の取引情報を購買者の生体情報に関連付けて保持するサーバ装置とともに商取引システムを構成するクライアント装置であって、
   購買者の生体情報を取得する生体情報取得部と、
   生体情報に関連付けられた購買者の取引情報を用いて商品購入代金の後払い取引の可否を判定する取引可否判定部と、
   取引申し込みから取引確定に至るまでの購買者との取引を管理する精算管理部と、
   を有し、
   前記生体情報取得部は、前記精算管理部が購買者から前記後払い取引の申し込みを受け付けたとき購買者の生体情報を取得し、
   前記精算管理部は、前記取得された生体情報とともに購買者の取引情報の取得要求を前記サーバ装置に送信し、
   前記取引可否判定部は、前記サーバ装置において取得された前記生体情報に関連付けられた購買者の取引情報を用いて、前記後払い取引の可否判定を行うことを特徴とするクライアント装置。
8. 前記サーバ装置は、購買者の生体情報と購買者の取引情報と購買者の個人情報を関連付けて保持し、
   前記精算管理部は、前記サーバ装置において取得された前記生体情報に関連付けられた購買者の個人情報を受信し、前記受信した前記個人情報を用いて前記後払い取引に係る請求書を作成することを特徴とする請求項７に記載のクライアント装置。
9. 前記精算管理部は、取得した取引結果情報を用いて前記取引情報を更新する前記サーバ装置に、前記後払い取引による取引結果情報を送信することを特徴とする請求項７又は８に記載のクライアント装置。
10. 前記取引情報は、購買者の取引全体についての正常取引率を含む取引評価と、個々の取引についての取引金額及び取引結果に応じた不具合レベルごとの取引件数を含む購買履歴と、から構成されることを特徴とする請求項７から９のいずれか１項に記載のクライアント装置。
11. 前記取引情報は、購買者の取引全体についての正常取引率を含む取引評価と、個々の取引についての取引金額及び取引結果に応じた不具合レベルごとの取引件数を含む購買履歴と、から構成され、
    前記取引可否判定手段は、前記取得された前記購買者の取引情報のうち正常取引率が所定の閾値以上である場合に前記後払い取引の許可判定を行うことを特徴とする請求項７から１０のいずれか１項に記載のクライアント装置。
12. 前記取引情報は、購買者の取引全体についての正常取引率を含む取引評価と、個々の取引についての取引金額及び取引結果に応じた不具合レベルごとの取引件数を含む購買履歴と、から構成され、
    前記取引可否判定手段は、前記取得された前記購買者の取引情報のうち不具合レベルごとの取引件数が所定の閾値以下である場合に前記後払い取引の許可判定を行うことを特徴とする請求項７から１１のいずれか１項に記載のクライアント装置。
13. 購買者との取引で使用されるクライアント装置と、購買者の情報を保持するサーバ装置と、を有して構成される商取引システムにおける商取引方法であって、
    前記サーバ装置は、購買者の生体情報と購買者の取引情報を関連付けて保持する購買者情報データベースを備え、
    前記クライアント装置において、購買者から商品購入代金の後払い取引の申し込みが受け付けられたとき、購買者の生体情報を取得する生体情報取得ステップと、
    前記クライアント装置において、前記取得された生体情報とともに購買者の取引情報の取得要求を前記サーバ装置に送信する取引情報要求ステップと、
    前記サーバ装置において、前記クライアント装置からの前記取得要求に応じて、前記生体情報に関連付けられた購買者の取引情報を前記購買者情報データベースから取得して前記クライアント装置に送信する取引情報送信ステップと、
    前記クライアント装置において、前記サーバ装置から送信された購買者の取引情報を用いて、前記後払い取引の可否を判定する取引可否判定ステップと、
    を有することを特徴とする商取引方法。
14. 購買者との取引で使用されるクライアント装置と、購買者の情報を保持するサーバ装置と、を有して構成される商取引システムに用いられるプログラムであって、
    前記クライアント装置のコンピュータに、
    購買者から商品購入代金の後払い取引の申し込みが受け付けられたとき取得された購買者の生体情報とともに、購買者の取引情報の取得要求を前記サーバ装置に送信する取引情報要求ステップと、
    前記サーバ装置から送信された購買者の取引情報を用いて、前記後払い取引の可否を判定する取引可否判定ステップと、
    を実行させ、
    前記サーバ装置のコンピュータに、
    前記クライアント装置からの前記取得要求に応じて、前記生体情報に関連付けられた購買者の取引情報を、購買者の生体情報と購買者の取引情報が関連付けて保持された購買者情報データベースから取得して前記クライアント装置に送信する取引情報送信ステップを実行させることを特徴とするプログラム。
15. 請求項１４に記載のプログラムを記録しコンピュータ読み取り可能なことを特徴とする記録媒体。

Images