(57)【要約】【課題】過去の取引履歴に基づいて補償金額を算定することで商取引を保証する商取引システムを提供する。【解決手段】取引金額精算装置と取引管理サーバとがネットワークを介して接続された商取引システムであって、購入希望の商品の金額情報から精算し、精算した金額（取引金額）と複数の取引方法を呈示し、商品先渡し取引金額後払いの取引方法が選択された場合は、現在行っている商取引を識別する取引管理番号を生成し、取引管理サーバに取引管理番号と取引金額と買い手の識別情報とを送って取引保証可否の問い合せを行う。取引管理サーバは、送信された買い手の識別情報に基づいて買い手情報ＤＢから買い手の取引履歴を抽出し、取引保証の可否を判断する。【選択図】図１
2010128785.tif 000002
【特許請求の範囲】
【請求項１】
取引金額精算装置と、取引管理サーバとがネットワークを介して接続されている商取引システムであって、
前記取引金額精算装置は、
少なくとも商品識別番号と商品の金額情報とを含む商品情報を格納する商品データベースと、
商品に付与されたタグから商品識別番号を読み取る読取り手段と、
前記読取り手段から読み取った商品識別番号と同じ商品識別番号に該当する商品の金額情報を前記商品データベースから抽出し、商品金額を精算する精算手段と、
前記精算した金額を取引金額として表示し、複数の取引方法を呈示する表示手段と、
買い手の識別情報を入力する入力手段と、
前記ネットワークを介して前記取引管理サーバとデータ通信を行う通信手段と、を備え、
前記複数の取引方法は、少なくとも商品先渡し取引金額後払いの取引方法を含み、
前記精算手段は、前記商品先渡し取引金額後払いの取引方法が選択された場合は、現在行っている商取引を識別する取引管理番号を生成し、前記通信手段を介して前記取引管理サーバに、前記取引管理番号と、前記取引金額と、前記買い手の識別情報とを送って取引保証可否の問い合せを行い、
前記表示手段は、前記取引管理サーバから受信した、問い合せた取引保証可否の回答として表示することを特徴とし、
前記取引管理サーバは、
買い手の取引履歴と、少なくとも買い手の識別情報を含む個人情報とを関連付けて格納する買い手情報データベースと、
補償金額の上限を算定する際に参照する対応表を格納する取引データベースと、
前記ネットワークを介して前記取引金額精算装置とデータ通信を行う通信手段と、
前記取引金額精算装置から取引保証可否について問い合せを受けた場合に、前記取引金額精算装置から送信された前記買い手の識別情報に基づいて、前記買い手情報データベースから一致する買い手の識別情報を含む個人情報と関連付けて格納されている買い手の取引履歴を抽出する取引管理手段と、
取引保証の可否を判断する取引判断手段と、を備え、
前記取引判断手段は、前記取引管理手段により抽出された買い手の取引履歴と、前記取引データベースに格納された対応表とを参照して、補償金額の上限を算出し、算出した上限補償金額を前記取引金額から減算して無補償金額を算出し、前記無補償金額が負の値になった場合は前記取引金額を第１の補償金額とし、正の値になった場合は前記上限補償金額を第２の補償金額とし、
前記データ通信手段は、前記第１の補償金額のみ、若しくは、第２の補償金額及び無補償金額を、前記取引管理番号と共に、前記取引金額算定装置へ取引保証可否の回答として送信することを特徴とする商取引システム。
【請求項２】
前記取引金額算定装置が備える精算手段は、前記取引管理サーバから受信した、問い合せた取引保証可否の回答が、前記第１の補償金額のみの場合は、共に送られた取引管理番号の取引が保証されたと判断し、前記回答が、前記第２の第２の補償金額及び無補償金額である場合は、共に送られた取引管理番号の取引が一部保証と判断し、
前記表示手段は、前記精算手段の判断に基づいて、保証された旨、若しくは一部保証のため、無補償金額分の支払いが必要となる旨を、問い合せた取引保証可否の回答として表示することを特徴とする請求項１記載の商取引システム。
【請求項３】
前記取引判断手段が行う前記上限補償金額の算出は、買い手の取引履歴のうち、正常取引の割合によって算出する請求項１又は２記載の商取引システム。
【請求項４】
前記取引判断手段が行う前記上限補償金額の算出は、買い手の取引履歴のうち、買い手の不具合件数によって算出する請求項１から３のいずれか１項記載の商取引システム。
【請求項５】
前記取引判断手段が行う前記上限補償金額の算出は、買い手の取引履歴のうち、買い手の不具合レベルに対する不具合件数によって算出する請求項１から４のいずれか１項記載の商取引システム。
【請求項６】
前記買い手の識別情報は、生体情報であることを特徴とする請求項１から５のいずれか１項記載の商取引システム。
【請求項７】
店舗サーバと、取引金額精算装置と、取引管理サーバと、通信端末とがネットワークを介して接続されている商取引システムであって、
前記通信端末は、
買い手の識別情報を入力する入力手段と、
前記ネットワークを介して前記店舗サーバ、前記取引金額精算装置とデータ通信を行う第１の通信手段と、
前記店舗サーバにアクセスし、Ｗｅｂサイトを表示する表示手段と、を備え、
前記表示手段は、前記取引管理サーバから、問い合せた取引保証可否の回答として送信された情報を表示することを特徴とし、
前記店舗サーバは、
少なくとも商品名を列挙したＷｅｂサイトを開設し、前記Ｗｅｂサイトに列挙した商品名のうち、前記通信端末から選択された商品の識別番号を、前記ネットワークを介して前記取引金額精算装置に通知する通知手段を備え、
前記取引金額精算装置は、
少なくとも商品識別番号と商品の金額情報とを含む商品情報を格納する商品データベースと、
前記店舗サーバから通知された商品識別番号と同じ商品識別番号に該当する商品の金額情報を前記商品データベースから抽出し、商品金額を精算する精算手段と、
前記ネットワークを介して、前記店舗サーバ、前記取引管理サーバ、前記通信端末とデータ通信を行う第２の通信手段と、を備え、
前記第２の通信手段は、前記精算した金額を取引金額として、複数の取引方法と共に前記通信端末に送信し、
前記複数の取引方法は、少なくとも商品先渡し取引金額後払いの取引方法を含み、
前記精算手段は、前記第２の通信手段を介して前記通信端末から前記複数の取引方法のうち前記商品先渡し取引金額後払いの取引方法が選択されたと通知された場合は、現在行っている商取引を識別する取引管理番号を生成し、前記通信端末から買い手の識別情報を取得し、前記第２の通信手段を介して前記取引管理サーバに、前記取引管理番号と、前記取引金額と、前記買い手の識別情報とを送って取引保証可否の問い合せを行い、
前記第２の通信手段は、前記取引管理サーバから、取引保証可否の回答として送信された情報を前記通信端末に送信することを特徴とし、
前記取引管理サーバは、
買い手の取引履歴と、少なくとも買い手の識別情報を含む個人情報とを関連付けて格納する買い手情報データベースと、
補償金額の上限を算定する際に参照する対応表を格納する取引データベースと、
前記ネットワークを介して前記取引金額精算装置とデータ通信を行う第３の通信手段と、
前記取引金額精算装置から取引保証可否について問い合せを受けた場合に、前記取引金額精算装置から送信された前記買い手の識別情報に基づいて、前記買い手情報データベースから一致する買い手の識別情報を含む個人情報と関連付けて格納されている買い手の取引履歴を抽出する取引管理手段と、
取引保証の可否を判断する取引判断手段と、を備え、
前記取引判断手段は、前記取引管理手段により抽出された買い手の取引履歴と、前記取引データベースに格納された対応表とを参照して、補償金額の上限を算出し、算出した上限補償金額を前記取引金額から減算して無補償金額を算出し、前記無補償金額が負の値になった場合は前記取引金額を第１の補償金額とし、正の値になった場合は前記上限補償金額を第２の補償金額とし、
前記データ第３の通信手段は、前記第１の補償金額のみ、若しくは、第２の補償金額及び無補償金額を、前記取引管理番号と共に、前記取引金額算定装置へ取引保証可否の回答として送信することを特徴とする商取引システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、商取引システムに関し、特に過去の取引履歴に基づいて補償金額を算定することで商取引を保証する商取引システムに関する。
【背景技術】
【０００２】
店舗等で利用されるシステムに関しては、例えば顧客の固定化を図るために顧客を会員化し、購買金額や取引金額に応じてポイントを付与するポイント付与システムが知られている。特許文献１記載のポイント付与システムでは、会員カード等を呈示する必要はなく、顧客の生体情報から顧客の認識を行ない、顧客データベースから顧客の取引履歴情報を呼び出し、取引内容に応じて顧客ポイントを加減算して顧客データベースを更新することを特徴とする。
【０００３】
また、店舗等で行われる商取引の種類は様々あり、売り手の店舗が、後払いで買い手との取引を行うこともある。この場合に、買い手の不具合による取引金額の未払いが生じると、その損失は店舗が負担することになる。そこで、店舗等での信用取引による商品購入が行われる場合は、買い手の信用保証が容易なクレジットカードの利用が必須となっている。しかしながら、クレジットカードを所有するには、銀行等の保証が必要となるため、クレジットカードを所有できない人や、年会費の負担、紛失した際の危険性等を考慮して、所有しない人も多く存在する。クレジットカードを所有していない買い手が、店舗等で容易に買い手の信用保証を行え、取引金額の後払いが可能となる取引が求められている。
【０００４】
そこで、商品の未着や代金の未払い等による買い手又は売り手の損害の発生を確実に防止することで、電子商取引の普及を促進することが出来る電子商取引システムが提案されている（特許文献２参照）。具体的には、注文情報における買い手の支払い金額が購入限度額以下で、かつ、買い手の購入数量が販売可能数以下である場合に、商取引を保証可能と判断し、当該取引を保証する旨を購入者端末に通知し、注文情報の内容を販売者端末に通知することを特徴とする。これにより、商品の未着や代金の未払いなどにより買い手又は売り手が損害を受けた場合に、買い手又は売り手がサーバに対して損害補償の請求をすることができるので、取引における買い手又は売り手の損害の発生を確実に防止することができ、電子商取引に対する信頼性を向上させることができる。
【特許文献１】特開２００１−０５２０４５号公報
【特許文献２】特開２００２−１４０５９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記のような電子商取引システムは、現時点の商取引の保証について買い手の「購入限度額」に基づいて判断しているため、問題となる。「購入限度額」とは、「本システムにおいて買い手が所定の期間内に商品を購入することができる合計金額の上限であり、例えば、買い手の前年度の年間所得額の１２０分の１、又は、前年度の所得税額の１２分の１のいずれか大きい方の金額」（特許文献２、段落００２６）である。かかる購入限度額が、買い手が選択した商品の金額を上回っているかどうかのみで、保証可能と判断しているが、該電子商取引システムでは所得額が多くても支払いが滞る買い手への対応が出来ず、また、購入限度額があるために買い手側は自由な商品選択が出来ないという問題がある。
【０００６】
本発明はこのような状況に鑑みてなされたものであり、過去の取引履歴に基づいて補償金額を算定することで商取引を保証し、買い手側の自由な商品選択を実現することを目的としている。
【課題を解決するための手段】
【０００７】
本発明に係る第１の商取引システムは、取引金額精算装置と、取引管理サーバとがネットワークを介して接続されている商取引システムであって、前記取引金額精算装置は、少なくとも商品識別番号と商品の金額情報とを含む商品情報を格納する商品データベースと、商品に付与されたタグから商品識別番号を読み取る読取り手段と、前記読取り手段から読み取った商品識別番号と同じ商品識別番号に該当する商品の金額情報を前記商品データベースから抽出し、商品金額を精算する精算手段と、前記精算した金額を取引金額として表示し、複数の取引方法を呈示する表示手段と、買い手の識別情報を入力する入力手段と、前記ネットワークを介して前記取引管理サーバとデータ通信を行う通信手段と、を備え、前記複数の取引方法は、少なくとも商品先渡し取引金額後払いの取引方法を含み、前記精算手段は、前記商品先渡し取引金額後払いの取引方法が選択された場合は、現在行っている商取引を識別する取引管理番号を生成し、前記通信手段を介して前記取引管理サーバに、前記取引管理番号と、前記取引金額と、前記買い手の識別情報とを送って取引保証可否の問い合せを行い、前記表示手段は、前記取引管理サーバから受信した、問い合せた取引保証可否の回答として表示することを特徴とし、前記取引管理サーバは、買い手の取引履歴と、少なくとも買い手の識別情報を含む個人情報とを関連付けて格納する買い手情報データベースと、補償金額の上限を算定する際に参照する対応表を格納する取引データベースと、前記ネットワークを介して前記取引金額精算装置とデータ通信を行う通信手段と、前記取引金額精算装置から取引保証可否について問い合せを受けた場合に、前記取引金額精算装置から送信された前記買い手の識別情報に基づいて、前記買い手情報データベースから一致する買い手の識別情報を含む個人情報と関連付けて格納されている買い手の取引履歴を抽出する取引管理手段と、取引保証の可否を判断する取引判断手段と、を備え、前記取引判断手段は、前記取引管理手段により抽出された買い手の取引履歴と、前記取引データベースに格納された対応表とを参照して、補償金額の上限を算出し、算出した上限補償金額を前記取引金額から減算して無補償金額を算出し、前記無補償金額が負の値になった場合は前記取引金額を第１の補償金額とし、正の値になった場合は前記上限補償金額を第２の補償金額とし、前記データ通信手段は、前記第１の補償金額のみ、若しくは、第２の補償金額及び無補償金額を、前記取引管理番号と共に、前記取引金額算定装置へ取引保証可否の回答として送信することを特徴とする。
【０００８】
本発明に係る第２の商取引システムは、店舗サーバと、取引金額精算装置と、取引管理サーバと、通信端末とがネットワークを介して接続されている商取引システムであって、前記通信端末は、買い手の識別情報を入力する入力手段と、前記ネットワークを介して前記店舗サーバ、前記取引金額精算装置とデータ通信を行う第１の通信手段と、前記店舗サーバにアクセスし、Ｗｅｂサイトを表示する表示手段と、を備え、前記表示手段は、前記取引管理サーバから、問い合せた取引保証可否の回答として送信された情報を表示することを特徴とし、前記店舗サーバは、少なくとも商品名を列挙したＷｅｂサイトを開設し、前記Ｗｅｂサイトに列挙した商品名のうち、前記通信端末から選択された商品の識別番号を、前記ネットワークを介して前記取引金額精算装置に通知する通知手段を備え、前記取引金額精算装置は、少なくとも商品識別番号と商品の金額情報とを含む商品情報を格納する商品データベースと、前記店舗サーバから通知された商品識別番号と同じ商品識別番号に該当する商品の金額情報を前記商品データベースから抽出し、商品金額を精算する精算手段と、前記ネットワークを介して、前記店舗サーバ、前記取引管理サーバ、前記通信端末とデータ通信を行う第２の通信手段と、を備え、前記第２の通信手段は、前記精算した金額を取引金額として、複数の取引方法と共に前記通信端末に送信し、前記複数の取引方法は、少なくとも商品先渡し取引金額後払いの取引方法を含み、前記精算手段は、前記第２の通信手段を介して前記通信端末から前記複数の取引方法のうち前記商品先渡し取引金額後払いの取引方法が選択されたと通知された場合は、現在行っている商取引を識別する取引管理番号を生成し、前記通信端末から買い手の識別情報を取得し、前記第２の通信手段を介して前記取引管理サーバに、前記取引管理番号と、前記取引金額と、前記買い手の識別情報とを送って取引保証可否の問い合せを行い、前記第２の通信手段は、前記取引管理サーバから、取引保証可否の回答として送信された情報を前記通信端末に送信することを特徴とし、前記取引管理サーバは、買い手の取引履歴と、少なくとも買い手の識別情報を含む個人情報とを関連付けて格納する買い手情報データベースと、補償金額の上限を算定する際に参照する対応表を格納する取引データベースと、前記ネットワークを介して前記取引金額精算装置とデータ通信を行う第３の通信手段と、前記取引金額精算装置から取引保証可否について問い合せを受けた場合に、前記取引金額精算装置から送信された前記買い手の識別情報に基づいて、前記買い手情報データベースから一致する買い手の識別情報を含む個人情報と関連付けて格納されている買い手の取引履歴を抽出する取引管理手段と、取引保証の可否を判断する取引判断手段と、を備え、前記取引判断手段は、前記取引管理手段により抽出された買い手の取引履歴と、前記取引データベースに格納された対応表とを参照して、補償金額の上限を算出し、算出した上限補償金額を前記取引金額から減算して無補償金額を算出し、前記無補償金額が負の値になった場合は前記取引金額を第１の補償金額とし、正の値になった場合は前記上限補償金額を第２の補償金額とし、前記データ第３の通信手段は、前記第１の補償金額のみ、若しくは、第２の補償金額及び無補償金額を、前記取引管理番号と共に、前記取引金額算定装置へ取引保証可否の回答として送信することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、過去の取引履歴に基づいて補償金額を算定することで商取引を保証し、買い手側の自由な商品選択を実現することができる。
【発明を実施するための最良の形態】
【００１０】
以下に、本発明の実施形態について図面を用いて詳細に説明する。なお、以下に述べる実施形態は、本発明の好適な実施形態であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの態様に限られるものではない。
【００１１】
（構成）
＜商取引システム＞
図１は、本発明の実施形態に係る商取引システムの全体構成図である。各店舗（ａ〜ｃ）に置かれた取引金額精算装置１ａ〜１ｃと、取引管理サーバ２とが、ネットワーク３を介して接続されている。本実施形態では、取引金額精算装置を３つ用いているが、これは一例であり、取引金額精算装置は１以上であれば良い。
【００１２】
ネットワーク３は、インターネット、無線ＬＡＮ、無線通信等である。各取引金額精算装置と取引管理サーバ２は、データ通信部を用いてネットワーク３を介して相互に通信を行う。
【００１３】
＜取引金額精算装置１＞
図２は、本実施形態に係る取引金額精算装置１の構成ブロック図である。取引金額精算装置１は、各店舗に設置され、買い手が店舗で選択した購入希望の１個または複数の商品の精算を行う。取引金額精算装置１は、精算部１１、入力部１２、商品データベース（ＤＢ）１４を有する記憶部１０、表示部１６、リーダ部１７、データ通信部１９から構成される。
【００１４】
リーダ部１７は、商品に付与されたバーコードやＲＦＩＤ（Radio Frequency Identification）タグ等を読取る読取り手段であり、数字または英数字からなる商品識別番号を出力する。
【００１５】
商品ＤＢ１４は、取引金額精算装置１が置かれている店舗で取引する全ての商品の情報を保有する。商品ＤＢ１４に記憶されている商品の情報は、少なくとも商品の金額、数字または英数字からなる商品識別番号を含み、他には例えば商品の画像、商品の商品名、商品の在庫数、商品の発注先等である。
【００１６】
データ通信部１９は、ネットワーク３とのインタフェース機能を有し、ネットワーク３を介して外部装置（端末、装置、サーバ等）とデータを相互に通信する。
【００１７】
精算部１１は、取引金額精算装置１で行われる取引を管理、制御する。具体的には、精算処理や、選択された取引方法が「商品先渡し取引金額後払いの取引」の場合は補償される金額の問い合わせ（取引の許可処理）等である。詳細は後述する。
【００１８】
表示部１６は、取引金額等を表示する。また、表示部１６はタッチパネル方式を用いた液晶表示部としても良い。表示部１６は、表示画面にタッチして選択されたデータを出力する。
【００１９】
なお、取引金額精算装置１は、さらに取引ＤＢ１５を備え、商品先渡し取引金額後払いの取引方法を精算部１１が許可した場合に行われた取引の内容を記憶しても良い。具体的には、例えば、取引管理番号、商品識別番号、請求金額、請求金額支払先口座、支払期日、買い手の個人情報（買い手の識別番号、郵便番号、住所、氏名）等の取引管理情報を記憶する。
【００２０】
＜取引管理サーバ２＞
図３は、本実施形態に係る取引管理サーバ２の構成ブロック図である。取引管理サーバ２は、主に補償金額の算定を行う。また、買い手の不具合取引によって、商品先渡し取引金額後払いの取引に生じた未払い等による売り手の店舗ａ〜ｃの損失を、上限補償金額範囲内で補償する。
【００２１】
取引管理サーバ２は、取引管理部２１、取引判断部２２、データ通信部２６、買い手情報データベース（ＤＢ）２４及び取引データベース（ＤＢ）２５を有する記憶部２７から構成される。
【００２２】
取引管理部２１は、取引管理サーバ２全体の管理、制御を行なう。詳細は後述する。
【００２３】
買い手情報ＤＢ２４は、買い手毎に、買い手の取引履歴、買い手の個人情報が関連付けて記憶されている。買い手の個人情報は、少なくとも買い手の識別番号（数字または英数字から成る）を含み、他には例えば郵便番号、住所、氏名、年齢、性別、電話番号、メールアドレス等である。
【００２４】
買い手の個人情報は、本実施形態に係る商取引システムにおいて商品先渡し取引金額後払いの取引方法を選択する前に、予めＤＢ２４に入力される（ユーザ登録）。買い手の個人情報は、例えば取引金額精算装置１が備える入力部１２から入力され、データ通信部１９はネットワーク３を介して取引管理サーバ２へ送信し、取引管理サーバ２が備える取引管理部２１は、データ通信部１９で受信した個人情報を買い手情報ＤＢ２４に記憶しても良い。買い手が取引金額精算装置１で精算中に初めて商品先渡し取引金額後払いの取引方法を選択した場合でも、取引金額精算装置１から迅速にユーザ登録出来るため、ユーザにとって利用し易い。ここで言う入力部１２は、例えばキーボードや十字キー等からなり、キーボードや十字キー等を利用してデータを入力することが出来る。
【００２５】
買い手情報ＤＢ２４が格納する「買い手の取引履歴」とは、買い手と各店舗との商品先渡し取引金額後払いの取引結果の履歴である。商品先渡し取引金額後払いの取引結果は、取引金額精算部１１から受信する。取引管理部２１は、受信した商品先渡し取引金額後払いの取引結果を、買い手情報ＤＢ２４に買い手毎にそれぞれ記憶されている取引履歴に追加する。
【００２６】
買い手情報ＤＢ２４が格納する買い手の取引履歴は、買い手の個々の取引履歴と、個々の取引履歴をまとめて評価した取引評価とに分けて格納されている。以下、詳述する。
【００２７】
図４は、一人の買い手の個々の取引履歴の例を示す図である。買い手の個々の取引履歴は、一取引毎に、取引日、店舗名、取引金額精算部１１のアドレス、取引金額、取引結果、不具合レベル、格付けポイント、累積格付けポイントから成る。累積格付けポイントは、一取引毎の格付けポイントにより加減算される。
【００２８】
取引履歴項目の「取引結果」とは、正常取引、不当要求、不当クレーム、商品交換、返金、支払遅延、未払い、買い手の行方不明から成る。また、取引履歴項目の「不具合レベル」は、取引結果に応じて分類される。不具合レベルの分類については後述するが、重大な不具合の取引結果は、不具合レベルが大きくなり、またマイナス値の大きい格付けポイントとなる。
【００２９】
「取引結果」は、取引金額精算装置１の精算部１１が、支払い期日を取引の終了として、買い手との商品先渡し取引金額後払いの取引の結果を取引管理サーバ２に報告したものである。取引管理部２１は、報告された「取引結果」に応じた不具合レベル等を、取引ＤＢ２５に格納されている対応表に基づいて分類する。以下、詳述する。
【００３０】
図５は、取引結果に応じた不具合レベルと、不具合レベルに応じた格付けポイントの一例を示す図である。図５に示す対応表は、取引ＤＢ２５に格納されている。図５に示す表によると、正常取引では格付けポイントが＋１であり、＋１が累積格付けポイントに加算される。未払いまたは買い手の行方不明は重大な不具合として最大不具合レベルの５に対応し、また格付けポイントは−４であり、４が累積格付けポイントから減算される。
【００３１】
図６は、一人の買い手の取引評価の一例を示す図である。買い手の取引評価は、買い手毎の、総取引件数、正常取引件数、正常取引率、不具合取引件数、累積格付けポイント、それぞれの不具合レベルの１年間の不具合総件数から成る。正常取引率は、総取引件数に対する正常取引件数の割合である。不具合取引は、正常取引以外の取引であり、商品交換、返金、不当クレーム、不当要求、支払遅延、未払い、買い手の行方不明等からなり、不具合取引件数は、不具合取引の総数である。
【００３２】
（動作）
次に、本実施形態の動作処理について説明する。図７は、本実施形態に係る商取引システムの動作処理を示すタイムチャートである。なお、特にステップＳ１からＳ４までの処理が本実施形態の特徴と言え、ステップＳ５からＳ７は補償金額問い合せ・結果表示（Ｓ１〜Ｓ４）後の処理の一例である。
【００３３】
＜ステップＳ１；取引金額の後払い／補償金額の問い合わせ＞
取引金額精算装置１が備えるリーダ部１７は、商品に付与されたバーコード等を読込み、商品の数字または英数字からなる商品識別番号を出力する。すなわち、店舗に入店した買い手が、購入を希望する１以上の商品を選択し、選択した商品の取引金額の精算を行うために取引金額精算装置１の前に進み、店舗の売り手が、それぞれの商品に付与されたバーコードをリーダ部２７から読み込ませることで、取引金額精算装置１は買い手が選択した商品の商品識別番号を取得することが出来る。
【００３４】
精算部１１は、リード部１７が出力した商品識別番号に基づき、商品ＤＢ１４から商品の金額を検索する。精算部１１は、商品の金額を合算し、買い手が購入希望する商品の合計の金額（すなわち、取引金額）を表示部１６に表示する。さらに、精算部１１は、表示部１６に、取引金額を精算するための取引方法の選択を要求する。表示部１６の表示例を図８に示す。
【００３５】
取引方法は複数あり、買い手が任意に選択できる。選択できる取引方法は、少なくとも「商品先渡し取引金額後払い」を含み、他には例えば「現金払い」、「クレジットカード払い」が考え得る。買い手は、表示された複数の取引方法の中から、希望する取引方法を選択する。例えば表示部１６がタッチパネルである場合は、選択したい支払い方法をタッチすることで選択できる。
【００３６】
精算部１１は、上記複数の取引方法のうち「商品先渡し取引金額後払い」が選択された場合は、買い手に商品先渡し取引金額後払いの取引方法を許可するか否かを判断するために、補償金額の問い合せを取引管理サーバ２に行う。補償金額とは、この商取引で買い手の不具合取引等により売り手側（店舗）に損失が生じた場合に、取引管理サーバ２が補償できる金額である。例えば取引管理サーバ２は保険会社が所有し、取引管理サーバ２で算出された補償金額について、買い手の不払い等があった場合に上記保険会社が売り手側に補償する。
【００３７】
精算部１１はこの商取引を識別するために、数字または英数字からなる取引管理番号を生成する。また、精算部１１は、この商取引を行う買い手を特定するために、買い手識別情報を入力部１２から取得する。買い手識別情報は、例えば識別番号（数字または英数字から成る）や、指紋等の生体情報が考え得る。識別情報を生体情報とする場合は、取引金額精算装置１は、さらに生体情報入力部１３を備えても良いし、入力部１２で兼用できるようにしても良い。生体情報は、例えば、指紋、掌紋、虹彩、静脈流、顔面のいずれかの情報が考え得る。
【００３８】
精算部１１は、取引管理番号、取引金額、買い手の識別情報を、ネットワーク３を介して取引管理サーバ２の取引管理部２１に送信することで、補償金額の問い合わせを行う。
【００３９】
＜ステップＳ２；補償金額／無保証金額の決定＞
取引管理部２１は、取引金額精算装置１から、取引管理番号、取引金額、買い手の識別情報を受信すると、取引判断部２２を用いて、買い手の商品先渡し取引金額後払いの取引における補償金額の決定処理を開始する。
【００４０】
取引管理部２１は、買い手の識別情報をキーにして、買い手情報ＤＢ２４を検索し、該当する買い手の識別情報に関連付けて格納されている、買い手の取引履歴、買い手の個人情報を抽出する。買い手の取引履歴は、買い手の個々の取引履歴とそれらをまとめた買い手の取引評価とから成る。
【００４１】
取引管理部２１は、取引管理番号、買い手の取引履歴（取引履歴、取引評価）を、取引判断部２２に送信する。
【００４２】
取引判断部２２は、まず、取引管理部２１が補償する金額の上限（以降、上限補償金額と称す）の決定を開始する。上限補償金額の決定には、買い手の取引履歴を用いる。買い手の取引履歴の、正常取引率と買い手のそれぞれの不具合のレベルに応じた不具合総件数（１年間分）により決定される。
【００４３】
上限補償金額に応じて、正常取引率の基準値と、上限補償金額に応じたそれぞれの不具合レベルの不具合総件数（１年間分）の基準値をそれぞれ満たす必要がある。図９は、上限補償金額に応じた正常取引率の基準値と、上限補償金額に応じたそれぞれの不具合レベルの不具合総件数（１年間分）の基準値の設定の一例を示す図である。図９に示す上限補償金額と基準値との対応表は、取引管理部２１の運用者（所有者、例えば保険会社）により予め設定され、取引ＤＢ２５に格納されている。
【００４４】
正常取引率の基準値は、上限補償金額の上昇に応じて高くなるよう設定されている。例えば、上限補償金額が１０００円では、正常取引率の基準値は４０％であるが、上限補償金額が３０００円では、正常取引率の基準値は６０％に、設定されている。
【００４５】
それぞれの不具合レベルの不具合総件数（１年間分）の基準値は、上限補償金額の上昇に応じて低くなるよう設定されている。例えば、上限補償金額が１０００円では、不具合レベル１の不具合総件数の基準値は２０件に設定され、上限補償金額が３０００円では、不具合レベル１の不具合総件数の基準値は１５件に設定されている。
【００４６】
また、同じ上限補償金額でも、不具合のレベルが上昇する程、不具合総件数の基準値は低く設定されている。例えば、上限補償金額が１０００円では、不具合レベル１の不具合総件数の基準値は２０件に設定され、不具合レベル２の不具合総件数の基準値は５件に設定されている。
【００４７】
例えば、図６に示す買い手の取引評価を例にすると、図６に示す取引評価は、正常取引率：６３％、不具合レベル１、２，４の不具合総件数がそれぞれ１件であるため、上限補償金額が３０００円の基準値を満たしている。従って、取引判断部２２は、上限補償金額を３０００円と決定する。
【００４８】
次に、取引判断部２２は、取引金額から上限補償金額を差し引いた無補償金額を算出する。
取引金額−上限補償金額＝無補償金額
【００４９】
取引判断部２２は、無補償金額が負の値になった場合は、取引金額以上の金額が補償されていると判断して、取引金額を補償金額とする。一方、正の値になった場合は、上限補償金額を補償金額とし、無補償金額を各店舗（売り手側）の負担とする。
【００５０】
取引判断部２２は、取引管理番号と補償金額、または、取引管理番号と補償金額と無補償金額を、取引管理部２１に送信する。取引管理部２１は、取引管理番号と補償金額、または、取引管理番号と補償金額と無補償金額を、取引金額精算装置１の精算部１１に送信する。
【００５１】
＜ステップＳ３；取引金額が全額補償＞
取引金額精算装置１の精算部１１は、取引管理番号と補償金額を受信した場合は、取引金額が補償金額で全額補償されていると判断し、買い手との商品先渡し取引金額後払いの取引を許可する。精算部１１は、取引金額を請求金額として、商品先渡し及び取引金額の後払いの取引方法を許可したこと及び取引金額、請求金額を、表示部１６に表示する。なお、支払い期日を表示しても良い。この場合の表示例を図１０に示す。
【００５２】
＜ステップＳ４；取引金額の一部補償／無保証金額分の支払い＞
精算部１１は、取引管理番号と補償金額と無補償金額を受信した場合は、取引金額が一部補償され、無補償金額が売り手側の損失になると判断し、表示部１６に取引の成立のために、買い手が無補償金額分の支払いを必要なことを表示する。この場合の表示例を図１１に示す。
【００５３】
取引金額精算装置１の精算部１１で無補償金額分の支払い処理が行われた場合は、精算部１１は、補償金額を請求金額として、商品先渡し及び取引金額の後払いの取引方法を許可したこと及び取引金額、支払い済み金額、請求金額を、表示部１６に表示する。なお、支払い期日を表示しても良い。この場合の表示例を図１２に示す。
【００５４】
また、精算部１１は、この商取引の取引管理番号、商品識別番号、請求金額、請求金額支払先口座、支払期日、買い手の個人情報（買い手の識別番号、郵便番号、住所、氏名）を取引管理情報として取引ＤＢ１５に格納する。
【００５５】
上記実施形態により、売り手側の店舗が、買い手と商品先渡し取引金額後払いの取引方法を行う場合に、買い手の不具合による取引金額の未払いが生じても、その損失を補償できる上限補償金額が、買い手の取引履歴を用いて決定されるため、不具合取引を過去に行った買い手の上限補償金額は低く抑えることが可能で、補償システム運用者が不具合取引により売り手の店舗に支払う補償金を低く押さえることが可能となった。
【００５６】
なお、図７に示すタイムチャートでは、ステップＳ５以降の処理について記載されているが、これは上記実施形態における補償金額問い合せ・結果表示（Ｓ１〜Ｓ４）後の処理の一例である。以下のようにして取得した情報が、取引管理サーバ２の買い手情報ＤＢの取引履歴として更に追加される。
【００５７】
＜ステップＳ５；補償金額分の請求書発行＞
精算部１１は、買い手の個人情報（郵便番号、住所、氏名）を利用して買い手の氏名を請求先として、請求先、請求金額、請求金額支払先口座、支払期日等が記載された請求書を作成し、取引金額精算装置１が備える出力部から請求書を印刷して出力する。売り手は、請求書と商品を買い手に渡す。買い手は、請求書と商品を受領し、後日支払いを行う。ここで言う出力部は、例えばプリンタ等であり、請求書や領収書を印刷出力出来る。
【００５８】
＜ステップＳ６；取引結果の報告＞
精算部１１は支払期日を取引の終了として、買い手との商品先渡し取引金額後払いの取引の結果を取引管理サーバ２の取引管理部２１に報告する。買い手からの不当クレーム、未払い等は、買い手の取引履歴に不具合取引として記憶される。精算部１１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金があった場合は、商品先渡し取引金額後払いの取引が正常取引であったことを取引結果として、取引管理サーバ２の取引管理部２１に、買い手との取引結果（取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、補償金額、取引結果）を送信する。請求金額支払先口座に買い手から請求金額の入金があったか否かは、例えばネットワーク３を介して接続される入金管理装置（ＡＴＭ（automatic teller machine）でも良い）に買い手が所定の口座（請求金額支払先口座）を指定して入金した場合や、銀行・郵便局・コンビニエンスストアでの入金処理が、ネットワーク３を介して接続される装置により行われた場合に、取引金額精算装置１に通知されることにより、判明する。
【００５９】
精算部１１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金が無い場合は、商品先渡し取引金額後払いの取引が未払いによる不具合取引であることを取引結果として、取引管理サーバ２の取引管理部２１に、買い手との取引結果（取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、補償金額、取引結果）を送信する。
【００６０】
取引管理サーバ２の取引管理部２１は、未払いの取引結果を受信すると、取引管理番号から、先に決定した補償金額を抽出する。これにより、取引管理部２１は、売り手側の店舗に対し補償金額分の補償を行う。例えば所定の口座から補償金額分を請求金額支払先口座に入金する等の処理を行う。
【００６１】
＜ステップＳ７；補償金の支払い／取引結果の記憶＞
取引管理サーバ２の取引管理部２１は、取引金額精算装置１の精算部１１から受信した買い手との取引結果（取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、前払い金額、補償金額、取引結果）から、図５に示す対応表（取引ＤＢ２５に格納されている）を参照して、不具合レベル、格付けポイントを出力し、買い手情報ＤＢ２４の取引評価（図６参照）を更新する。格付けポイントは過去のポイントと累積され、累積格付けポイントとして更新される。
【００６２】
（他の実施形態）
次に、本発明の他の実施形態に係る商取引システムについて説明する。上記実施形態は、取引金額精算装置１が店舗に設置されていることが前提とされ、買い手が店舗にある商品を選び、取引金額精算装置１のところまで持ってきた場合に売り手が商品に付いているバーコード等をリード部１７で読み込ませることを想定している。しかしながら、昨今はインターネット上での商取引も普及している。個人が所有する通信端末からインターネットにアクセスして商取引を行うことで、どこでも好きな時間に自由に行うことが出来る。本発明は、このようなインターネット上で行われる商取引にも対応できる。
【００６３】
（構成）
図１３は、本発明の実施形態に係る商取引システムの全体構成図である。取引金額精算装置１と、取引管理サーバ２と、買い手が利用する通信端末４とが、ネットワーク３を介して接続されている。取引金額精算装置１は、店舗サーバ内にある構成となっているが、店舗サーバはネットワーク３を介して接続されていれば良く、これに限定されることはない。店舗サーバは、取り扱っている商品の一覧や金額等をＷＥＢとしてインターネット上に呈示する機能を有する。通信端末４から店舗サーバにアクセスし、店舗サーバは、呈示したＷｅｂサイトに列挙した商品名のうち、通信端末４から選択された商品の識別番号を、購入希望商品として取引金額精算装置１に通知する。
【００６４】
取引金額精算装置１の構成は、上記実施形態で説明した図２に示す構成のうち、リーダ部１７と入力部１２を除く構成となる。取引管理サーバ２の構成は、上記実施形態で説明した図３に示す構成と同様である。
【００６５】
図１４は、本実施形態に係る通信端末４の構成ブロック図である。通信端末４は、少なくとも入力部４１、表示部４３、データ通信部４５から構成される。その他、通信端末４全体を制御する制御部４４や、ＲＯＭ（Read Only Memory）等から成る記憶部４６など、一般的な構成を備える。ユーザ登録を行う際に登録する個人情報や、買い手の識別情報を番号で入力する場合等は、通信端末４１が備える入力部４１から入力できる。なお、買い手の識別情報を生体情報とする場合は、生体情報入力部４２をさらに備えても良いし、入力部４１で兼用しても良い。表示部４３は、例えば液晶表示部であり、タッチパネル方式を用いても良い。
【００６６】
（動作処理）
図１５は、本実施形態に係る商取引システムの動作処理を示すタイムチャートである。
＜ステップＳ１１；取引金額の後払い／補償金額の問い合わせ＞
買い手は通信端末４１を利用して店舗サーバが呈示するＷｅｂサイト上の商品を選択する。表示部４３がタッチパネル方式を用いている場合は、購入希望の商品をタッチすることで選択出来る。Ｗｅｂサイトにおいて、通信端末４１からいずれの商品が選択されたかを店舗サーバが取引金額精算装置１に通知する。
【００６７】
取引金額精算装置１の精算部１１は、選択された商品の合計の金額すなわち取引金額を精算するための取引方法の選択を要求する。具体的には、通信端末４１の表示部４３に、複数の取引方法（商品先渡し取引金額後払い、現金払い、クレジットカード払い）が示される。この場合の表示例は上記実施形態の際に用いた図８と同様である。
【００６８】
買い手が、複数の取引方法の中から、商品先渡し取引金額後払いの取引方法を選択した場合は、買い手に商品先渡し取引金額後払いの取引方法を許可するか否かを判断するために、取引管理サーバ２に補償金額の問い合わせを開始する。精算部１１はこの取引を管理するために、数字または英数字からなる取引管理番号を生成する。
【００６９】
取引金額精算装置１の精算部１１は、通信端末４１の表示部４３に、買い手の識別情報の入力を指示する画面を表示させる。識別情報を生体情報とする場合は、生体情報の入力を指示する画面を表示させる。以下、買い手の識別情報を生体情報とする場合を例として説明する。買い手は、通信端末４１の生体情報入力部４２から生体情報として指紋を読み込ます。生体情報入力部４２は読み込んだ指紋から特徴点を抽出し、特徴点の座標の集合からなるデータを買い手の生体情報として出力し、精算部１１に送信する。
【００７０】
取引金額精算装置１の精算部１１は、商品先渡し取引金額後払いによる支払いの取引方法の選択信号を、表示部１６から受信すると、取引管理番号、取引金額、買い手の生体情報を、ネットワーク３を介して取引管理サーバ２の取引管理部２１に送信し、補償金額を取引管理部２１に問い合わせる。
【００７１】
＜ステップＳ１２；補償金額／無保証金額の決定＞
取引管理部２１は、取引管理番号、買い手の生体情報を受信すると、取引判断部２２を用いて、買い手の商品先渡し取引金額後払いの取引における補償金額を決定し、取引管理番号と補償金額、または、取引管理番号と補償金額と無補償金額を、取引金額精算装置１の精算部１１に送信する。
【００７２】
＜ステップＳ１３；取引金額が全額補償＞
精算部１１は、取引管理番号と補償金額を受信した場合は、取引金額が補償金額で全額補償されていると判断して、買い手との商品先渡し取引金額後払いの取引を許可する。取引金額精算装置１の精算部１１は、商品先渡し及び取引金額の後払いの取引方法を許可したこと及び取引金額、請求金額を、表示部４３に表示する。なお、支払い期日を同時に表示しても良い。この場合の表示例は上記実施形態の際に用いた図９と同様である。
【００７３】
＜ステップＳ１４；取引金額の一部補償／取引の中止＞
精算部１１は、取引管理番号と補償金額と無補償金額を受信した場合は、無補償金額が売り手側の損失になると判断し、買い手との取引を中止する。この場合の表示例を図１６に示す。
【００７４】
上記実施形態により、買い手が通信端末を利用してインターネット上で行われる商取引であっても、商品先渡し取引金額後払いの取引方法を行う場合に、買い手の不具合による取引金額の未払いが生じても、その損失を補償できる上限補償金額が、買い手の取引履歴を用いて決定され、不具合取引を過去に行った買い手の上限補償金額は低く抑えることが可能で、補償システム運用者が不具合取引により売り手の店舗に支払う補償金を低く押さえることが可能となる。
【００７５】
なお、図１５に示すタイムチャートでは、ステップＳ１５以降の処理について記載されているが、これは補償金額問い合せ・結果表示（Ｓ１１〜Ｓ１４）後の処理の一例である。以下のようにして取得した情報が、取引管理サーバ２の買い手情報ＤＢの取引履歴として更に追加される。
【００７６】
＜ステップＳ１５；補償金額分の請求書発行＞
精算部１１は、買い手の個人情報（郵便番号、住所、氏名）を利用して、買い手の氏名を請求先として、請求先、請求金額、請求金額支払先口座、支払期日等が記載された請求書を送る。通信端末４１に通知しても良いし、指定のメールアドレスに通知しても良い。また、請求書を、取引金額精算装置１の出力部から紙媒体に印刷して出力しても良い。売り手側は、出力された請求書を、商品を発送する際に併せて発送することが出来る。
【００７７】
精算部１１は、取引管理番号、商品識別番号、請求金額、請求金額支払先口座、支払期日、買い手の個人情報（買い手の識別番号、郵便番号、住所、氏名）を取引管理情報として、取引ＤＢ１５に記憶する。
【００７８】
＜ステップＳ１６；取引結果の報告＞
精算部１１は支払期日を取引の終了として、買い手との商品先渡し取引金額後払いの取引の結果を取引管理サーバ２の取引管理部２１に報告する。買い手からの不当クレーム、未払い等は、買い手の取引履歴に不具合取引として記憶される。
【００７９】
精算部１１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金があった場合は、商品先渡し取引金額後払いの取引が正常取引であったことを取引結果として、取引管理サーバ２の取引管理部２１に、買い手との取引結果（取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、補償金額、取引結果）を送信する。
【００８０】
精算部１１は、支払期日までに請求金額支払先口座に買い手から請求金額の入金が無い場合は、商品先渡し取引金額後払いの取引が未払いによる不具合取引であることを取引結果として、取引管理サーバ２の取引管理部２１に、買い手との取引結果（取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、補償金額、取引結果）を送信する。
【００８１】
＜ステップＳ１７；補償金の支払い／取引結果の記憶＞
取引管理部２１は、未払いの取引結果を受信すると、取引管理番号から、先に決定した補償金額を抽出する。取引管理部２１は、店舗ａ〜ｃに対し補償金額分の補償を行う。
【００８２】
取引管理サーバ２の取引管理部２１は、取引金額精算装置１の精算部１１から受信した買い手との取引結果（取引管理番号、取引日、店舗名、店舗の取引金額精算装置のアドレス、取引金額、前払い金額、補償金額、取引結果）から、不具合レベル、格付けポイント、累積格付けポイントを出力し、買い手情報ＤＢ２４の取引履歴に追加記憶する。
【００８３】
なお、各図のタイムチャートに示す処理を、ＣＰＵが実行するためのプログラムは本発明によるプログラムを構成する。このプログラムを記録する記録媒体としては、半導体記憶部や光学的及び／又は磁気的な記憶部等を用いることができる。このようなプログラム及び記録媒体を、前述した各実施形態とは異なる構成のシステム等で用い、そこのＣＰＵで上記プログラムを実行させることにより、本発明と実質的に同じ効果を得ることができる。
【００８４】
以上、本発明を好適な実施形態に基づき具体的に説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【図面の簡単な説明】
【００８５】
【図１】本発明の実施形態に係る商取引システムの全体構成図である。
【図２】本発明の実施形態に係る取引金額精算装置１の構成ブロック図である。
【図３】本発明の実施形態に係る取引管理サーバ２の構成ブロック図である。
【図４】本発明の実施形態に係る買い手情報ＤＢ２４に格納されている取引履歴の一例を示す図である。
【図５】本発明の実施形態に係る取引ＤＢ２５に格納されている対応表の一例を示す図である。
【図６】本発明の実施形態に係る買い手情報ＤＢ２４に格納されている取引評価の一例を示す図である。
【図７】本発明の実施形態に係る商取引システムの動作処理を示すタイムチャートである。
【図８】本発明の実施形態に係る取引金額精算装置１が備える表示部１６に表示される画面の一例を示す図である。
【図９】本発明の実施形態に係る取引ＤＢ２５に格納されている上限補償金額と各基準値との対応表の一例を示す図である。
【図１０】本発明の実施形態に係る取引金額精算装置１が備える表示部１６に表示される画面の一例を示す図である。
【図１１】本発明の実施形態に係る取引金額精算装置１が備える表示部１６に表示される画面の一例を示す図である。
【図１２】本発明の実施形態に係る取引金額精算装置１が備える表示部１６に表示される画面の一例を示す図である。
【図１３】本発明の他の実施形態に係る商取引システムの全体構成図である。
【図１４】本発明の他の実施形態に係る通信端末４１の構成ブロック図である。
【図１５】本発明の他の実施形態に係る商取引システムの動作処理を示すタイムチャートである。
【図１６】本発明の他の実施形態に係る通信端末４１が備える表示部４３に表示される画面の一例を示す図である。
【符号の説明】
【００８６】
ａ〜ｃ    店舗
１ａ〜１ｃ    取引金額精算装置
２    取引管理サーバ
３    ネットワーク
４    通信端末
１０    記憶部
１１    精算部
１２    入力部
１３    生体情報入力部
１４    商品データベース
１５    取引データベース
１６    表示部
１７    リーダ部
１９    データ通信部
２１    取引管理部
２２    取引判断部
２４    買い手情報データベース
２５    取引データベース
２６    データ通信部
２７    記憶部
４１    入力部
４２    生体情報入力部
４３    表示部
４４    制御部
４５    データ通信部
４６    記憶部
【図１】
2010128785.tif 000003
【図２】
2010128785.tif 000004
【図３】
2010128785.tif 000005
【図４】
2010128785.tif 000006
【図５】
2010128785.tif 000007
【図６】
2010128785.tif 000008
【図７】
2010128785.tif 000009
【図８】
2010128785.tif 000010
【図９】
2010128785.tif 000011
【図１０】
2010128785.tif 000012
【図１１】
2010128785.tif 000013
【図１２】
2010128785.tif 000014
【図１３】
2010128785.tif 000015
【図１４】
2010128785.tif 000016
【図１５】
2010128785.tif 000017
【図１６】
2010128785.tif 000018