JP3659491B2 - 電子決済仲介方法、電子決済仲介システム、および電子決済仲介プログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、電子的なデータのやりとりにより代金の支払いを行う電子決済技術に係り、特に電子手形・電子小切手による電子決済における電子決済仲介方法、電子決済仲介システム、および電子決済仲介プログラムに関するものである。
【０００２】
【従来の技術】
近年、インターネットなどのネットワーク上での商品売買が頻繁に行われるようになった。これに伴い代金を支払ったのに商品が届かない、あるいは品物を送ったのに代金が支払われないといったトラブルが多くなっている。その解決策の一つとしてエスクローと呼ばれる商品の引渡しと代金の支払いとを仲介するサービスが実現されている（日経ネットビジネス 2000 年 10 月号「ｅ−マーケットプレイスを１２０％使いこなす」参照）。
【０００３】
このサービスでは、まずエスクローサービスを提供する仲介業者が商品の購入者から商品の代金を受け取る。代金を受取ると、次に、仲介業者は販売者に対して商品の発送を指示する。商品の配送は仲介業者自身あるいは仲介業者の関連会社により購入者に届けられる。仲介業者は、この配送を確認した上で代金を販売者に対して支払う。以上により、上述した如き代金を支払ったのに商品が届かない、あるいは品物を送ったのに代金が支払われないといったトラブルを回避する。ただし上記決済モデルは、仲介業者に対して資金が移動する決済モデルであり、仲介業者の倒産時のリスクやエスクローによる代金の持ち逃げなどのリスクが内在する決済モデルである。
【０００４】
一方、現実社会においての商品取引において、代金後払いの決済手段として利用されている手形や小切手を電子化する電子手形・電子小切手と呼ばれる技術も数多く知られている（ 特開平2000-113089号公報、特開平2000-113075号公報、特開平9-218905号公報参照）。これらの技術では、将来の代金の支払いを行う意図があることを示す電子データを、支払人のシステムから受取人のシステムに登録し、前記登録データの内容に従い資金を決済する技術である。
【０００５】
またこれらの技術においては、電子手形・電子小切手の複製が生成され二重に譲渡されることを防止する必要があるため、電子手形・電子小切手を受取人のシステムに保管するのではなく、公的な登録機関を用意し、該登録機関に電子手形・電子小切手を保存するようにした仕組みも知られている（特開平11-296603号公報参照）。
【０００６】
【発明が解決しようとする課題】
本発明が解決しようとする第１の課題は、商品の受渡しや資金決済と同期して電子手形・電子小切手の受渡しを行う仕組みを提供することであり、電子手形・電子小切手決済を用いたエスクローサービスを提供することである。またこの際に、エスクローサービスを提供する仲介業者が電子手形・電子小切手の受取人・支払人にはならなず、商品の販売者・購入者間でのみ電子手形・電子小切手による支払の約束がなされる決済モデルを実現する。これにより仲介業者の信用リスクが生じないようにする。
【０００７】
本発明が解決しようとする第２の課題は、電子手形・電子小切手を振り出す際に振出許可あるいは支払保証を受けた上で振り出す仕組みを提供することであり、さらには振出許可あるいは支払保証の処理中に債権・債務の効力を持つ電子手形・小切手が不正に流通することを防止する仕組みを提供することである。
【０００８】
【課題を解決するための手段】
本発明を実施するシステムは、商品の購入を行う購入者のシステムと、商品の販売を行う販売者のシステムである販売者システムと、電子手形・電子小切手の管理・保管を行う仲介業者システムと、資金決済を行う金融機関のシステムにより構成される。本発明のベースとなる解決策は、購入者システムが電子手形・電子小切手を仲介業者のシステムに登録する際に、電子手形・電子小切手の債権・債務が発生する条件である本登録条件とを合わせて登録することによる。
【０００９】
具体的に、第１の課題を解決手段では、購入者のシステムは、商品の支払に当てる電子手形・電子小切手の登録と共に、本登録条件として、例えば「物流会社からの商品の配送通知が到着した上で本登録する」ことを意味する条件データを登録する。次に、仲介業者のシステムにおいて、本登録を承認する本登録要求データを外部より受ける。この例の場合、外部からの入力は、物流会社のシステムから送信される配送通知である。この本登録要求データの受信を受けて電子手形・電子小切手を本登録とする。
【００１０】
本登録となった電子手形・電子小切手について、仲介業者のシステムは金融機関のシステムに対して、電子手形・電子小切手の内容に従い購入者の口座から販売者の口座に対して代金を支払うよう指示する。この仕組みにより、販売者は仲介業者のシステムに対して、仮登録された電子手形・電子小切手の内容を確認した上で商品の発送を指示することにより、商品の配送完了と共に電子手形・電子小切手を入手可能となる。
【００１１】
また、第２の課題の解決手段では、購入者のシステムは、商品の支払に当てる電子手形・電子小切手の登録と共に、本登録条件として、例えば「金融機関からの承認・保証通知を受けた上で本登録を行う」ことを意味する条件データを合わせて登録する。前記登録を受けると、仲介業者のシステムは電子手形・電子小切手を金融機関のシステムに送信する。金融機関のシステムでは、電子手形・電子小切手の支払元となる口座の残高や前記口座からの今後の支払予定額、さらに電子手形・電子小切手の振出し者の権限を確認した上で、仲介業者のシステムに対して、承認あるいは保証可能かを通知する。仲介業者のシステムでは、金融機関システムから承認可能・保証可能の通知を受けて電子手形・電子小切手を本登録とする。
【００１２】
この仕組みにより、本発明の方式は、債権・債務の効力を持つ電子手形・小切手を振り出した上で金融機関の承認・保証を受ける方式と比較した場合には、承認・保証の審査中に効力を持つ電子手形・電子小切手が事故あるいは故意で流通する危険性を軽減できる。一方、電子手形・電子小切手の発行内容を金融機関に送付し承認・保証を受けた上で電子手形・電子小切手を発行する方式と比較した場合には、購入者は、内容確認の依頼・手形発行の２回の処理プロセスが必要であったのを、電子手形・電子小切手の条件付き仮登録という１回の処理プロセスで処理できるようになる。
【００１３】
【発明の実施の形態】
以下、本発明の第１の実施形態を、図面を用いて詳細に説明する。
図１は、本発明の第１の実施形態におけるシステム構成図である。第１の実施形態では、購入者あるいは代理購入者が使用する購入者システム１１００と、販売者あるいは代理販売者が使用する販売者システム１３００と、決済仲介機関が使用する決済仲介システム１２００と、金融機関が使用する金融機関システム１４００と、配送業者が使用する配送業者システム１７００とを、ネットワーク１５００により接続して構成する。
【００１４】
ここで、購入者とは、商品を購入しその対価として金銭を支払う支払人であり、金銭の支払義務を負う債務者である。また代理購入者とは、前記購入者の合意の下、前記購入者の代理として購入者システム１１００に対するオペレーションを行う者である。販売者とは、商品を販売しその対価として金銭を受け取る受取人であり、金銭を受け取る権利を有する債権者である。また代理販売者とは、前記販売者の合意の下、前記販売者の代理として販売者システム１３００に対するオペレーションを行う者である。
【００１５】
決済仲介機関とは、支払人からの支払意図の登録を受け、その内容に従い受取人の口座に代金を振込むように金融機関に指示する業者である。ここで“支払意図”とは、支払人が受取人に対して、現時点あるいは将来のある時点において代金を支払う意志があることを証拠化する電子データであり、例えば、電子手形や電子小切手である。
【００１６】
金融機関とは、金融取引を仲介する機関であり、例えば、日本銀行、普通銀行、長期信用銀行、信託銀行、信用金庫、信用組合、農業協同組合、漁業協同組合、保険会社、証券会社、ノンバンク、郵便局などをいう。配送業者とは、商品を販売者から購入者へ配送する業者であり、例えば運送業者・宅配業者・郵政事業庁である。
【００１７】
購入者システム１１００、決済仲介システム１２００、販売者システム１３００、金融機関システム１４００、配送業者システム１７００は計算機システムであり、例えばパーソナルコンピュータ、ワークステーション、汎用コンピュータである。ネットワーク１５００は、放送電波や電気通信回線であり、例えばインターネットである。
【００１８】
図２は、本発明の第１の実施形態における購入者システム１１００のシステム構成図である。同図に示すように、購入者システム１１００は、記憶装置２０１０、通信装置２０２０、処理装置２０３０、入力装置２０４０、出力装置２０５０をバス２０７０で接続して構成される。
【００１９】
記憶装置２０１０は、データや処理プログラムを記憶する装置であり、例えばメモリである。通信装置２０２０は、ネットワーク１５００と接続し、購入者システム１１００が、他のシステム、すなわち決済仲介システム１２００、販売者システム１３００、金融機関システム１４００、配送業者システム１７００と、データを送受信するのに用いる装置であり、例えばネットワークカードである。
【００２０】
処理装置２０３０は、記憶装置２０１０に記憶されたプログラムを実行する装置であり、例えばＣＰＵである。入力装置２０４０は、装置の使用者等による外部からの入力をうける装置であり、例えばキーボードやマウスである。出力装置２０５０は、装置の使用者等の外部に対して情報を出力する装置であり、例えばディスプレィである。
【００２１】
決済仲介システム１２００、販売者システム１３００、金融機関システム１４００、配送業者システム１７００も図２に示す購入者システム１１００と同じシステム構成を有する。
【００２２】
図１に示すように、購入者システム１１００は、支払意図登録処理１１１０と購入者秘密鍵１１９０とを記憶する。ここで支払意図登録処理とは支払意図登録処理を実行するためのプログラムのことをいう（以下同様）。これらは具体的には購入者システム１１００の記憶装置２０１０（図２参照）に記憶する。以下図１の各システム内に記載した処理ならびに各秘密鍵は、同様に各システムを構成する記憶装置２０１０に記憶するものとする。また、ここで秘密鍵とは公知技術である公開鍵暗号の秘密鍵である。
【００２３】
決済仲介システム１２００の記憶装置２０１０は、支払意図登録受付処理１２１５、振込口座指定受付処理１２２５、本登録要求受付処理１２３０、定期処理１２４０とを記憶する。決済仲介システム１２００は、さらに、参加者ＤＢ１２１０と支払意図ＤＢ１２２０が接続してある。参加者ＤＢ１２１０と支払意図ＤＢ１２２０は、例えばハードディスクに記憶されたデータであり、決済仲介システム１２００に記憶してある各々の処理（処理プログラム）から読み出しおよび書き込みが可能である。
【００２４】
販売者システム１３００の記憶装置２０１０は、振込口座指定処理１３１０，販売者秘密鍵１３９０とを記憶する。金融機関システム１４００の記憶装置２０１０は、振込処理１４１０と支払処理１４２０と金融機関秘密鍵を記憶する。金融機関システム１４００は、さらに、口座ＤＢ１４８０が接続してある。口座ＤＢ１４８０は、例えばハードディスクに記憶されたデータであり、金融機関システム１４００に記憶してある各々の処理（処理プログラム）から読み出しおよび書き込みが可能である。配送業者システム１７００の記憶装置２０１０は、本登録要求処理１７１０と配送業者秘密鍵１７９０とを記憶する。
【００２５】
以下、第１の実施形態の処理手順について詳細に説明する。
まず、購入者と販売者との間において物品・サービス等の売買契約が成立する。この売買契約の成立手順については本特許の範囲外であるので詳細は割愛する。売買契約が成立すると、購入者システム１１００の支払意図登録処理１１１０において支払意図３０００を作成し、決済仲介システム１２００に送信する。
【００２６】
図３は、支払意図３０００の構造例を示す図である。
支払意図３０００は、同図に示すように、支払意図ＩＤ３０５０、いくつかの取引ＩＤ３１００、支払人ＩＤ３２００、支払額３３００、支払日３４００，支払口座３５００、受取人ＩＤ３６００、本登録条件４０００、支払人署名３７００からなる。支払意図ＩＤ３０５０とは、各々の支払意図３０００を識別するためのデータである。取引ＩＤ３１００は、支払意図３０００がどの取引に対する支払なのかを特定するためのデータである。
【００２７】
取引ＩＤ３１００が複数存在する場合は、支払意図３０００が複数の取引に対する支払に用いられるものとする。支払人ＩＤ３２００は支払を行う者を特定するためのデータである。支払額３３００はいくらの支払を行うかを示すデータである。支払日３４００はいつ支払うかを示すデータである。支払口座３５００は、どの口座から支払うかを示すデータである。受取人ＩＤ３６００は支払を受ける者（受け取る者）を特定するためのデータである。
【００２８】
本登録条件４０００は、支払意図３０００の内容に従い債権・債務が発生する（本登録とよぶ）条件を指定するデータであり、その構造は後述（図４）する。なお、本実施例では支払意図３０００に本登録条件４０００そのものを含んでいるが、支払意図３０００には対応する本登録条件４０００を特定するためのデータを含んでいても良い。支払人署名３７００は、支払意図３０００が支払人の意志に基づくものかを検証するデータであり、例えば支払人によりなされる電子署名である。
【００２９】
図４は、本登録条件４０００の構造例を示す図である。
本登録条件４０００は、同図に示すように、有効日４１００、有効期限４２００と、いくつかの本登録要求者ＩＤ４３００から構成される。有効日４１００は、本登録が有効日４１００以降に可能となることを示すデータである。空欄の場合は本登録が即日可能であることを示す。有効期限４２００は、本登録が有効期限４２００以降は行えないことを示すデータである。空欄の場合は有効期限に制限がないことを示す。
【００３０】
本登録要求者ＩＤ４３００は、本欄で指定される者からの本登録要求７０００（図７参照）を受信することにより本登録が行えることを示すデータである。空欄の場合は、本登録要求７０００を受信しなくても本登録が可能であることを示す。また本登録要求者ＩＤ４３００が複数存在する場合には、各々の欄で指定される全ての者からの本登録を受信することにより本登録が可能になることを示す。本登録要求７０００の構造については後述（図７）する。第１の実施形態においては、配送業者を特定するＩＤ（データ）を要求者ＩＤ４３００に記憶しておくものとする。本登録条件４０００は、それが含む全ての条件が成立した場合に、本登録が可能となる。
【００３１】
支払意図登録処理１１１０による支払意図３０００（図３）の作成は、まず購入者システム１１００の入力装置２０４０により、取引ＩＤ３１００、支払人ＩＤ３２００、支払額３３００，支払日３４００，支払口座３５００、受取人ＩＤ３６００、本登録条件４０００の値が入力される。ここで、本登録条件４０００の値の入力は、具体的には、有効日４１００，有効期限４２００，本登録要求者ＩＤ４３００の値の入力によって行われる。また、支払意図ＩＤ３０５０は、決済仲介システム１２００で各々の支払意図３０００ごとに異なるＩＤを生成し、それを購入者システム１１００が受信し挿入する。
【００３２】
次に、支払意図ＩＤ３０５０，取引ＩＤ３１００、支払人ＩＤ３２００、支払額３３００，支払日３４００，支払口座３５００、受取人ＩＤ３６００、本登録条件４０００に対する署名値を計算し、支払人署名３７００に格納する。署名方法は、ＸＭＬ（Extensible Mark-up Language）文章等に対する電子署名の付与と同様に行う。
【００３３】
具体的には、支払意図ＩＤ３０５０，取引ＩＤ３１００、支払人ＩＤ３２００、支払額３３００，支払日３４００，支払口座３５００、受取人ＩＤ３６００、本登録条件４０００の内容を一連のビット列にシリアライズする。このシリアライズは、例えば前記内容を示す文字列の文字コードを並べビット列とする。次に、シリアライズしたビット列のハッシュ値を計算する。ハッシュ値は、ビット列から固定長の疑似乱数を生成する不可逆な一方向関数（ハッシュ関数）で処理することにより算出する。最後に、ハッシュ値を、購入者秘密鍵１１９０を用いて暗号化する。
【００３４】
購入者秘密鍵１１９０は、公開鍵暗号における秘密鍵である。秘密鍵で暗号化したデータは、対応する公開鍵で復号化できる。以後、本明細書において署名を付与する場合は、上記署名方法と同じ方法で付与するものとする。上記一連の処理により支払意図３０００が作成されると、購入者システム１１００は作成した支払意図３０００を決済仲介システム１２００に送信する。
【００３５】
決済仲介システム１２００は、購入者システム１１００から支払意図３０００を受信すると、支払意図登録受付処理１２１５を実行する。以下支払意図登録受付処理１２１５の処理内容について述べる。
【００３６】
まず、受信した支払意図３０００の支払人署名３７００が正当な署名であるかを検証する。署名の検証は参加者ＤＢ１２１０の内容を用いて検証する。図５は、参加者ＤＢ１２１０の構造例を示す図である。参加者ＤＢ１２１０は、同図に示すように、参加者情報５０００が登録してあるテーブルである。参加者情報５０００は、参加者ＩＤ５１００、公開鍵５３００、連絡先５４００とを有する。
【００３７】
参加者情報５０００の参加者ＩＤ５１００は、その参加者情報５０００がどの参加者に関する情報であるかを特定するために用いるデータである。ここで参加者とは、決済仲介システム１２００に直接または間接的にアクセスし、データの送受信を行う者である。本実施形態においては、参加者として、購入者、販売者、配送業者、金融機関とを登録しておく。
【００３８】
公開鍵５３００は、参加者の公開鍵であり、各参加者の持つ秘密鍵に対応する公開鍵を記録しておく。ここで公開鍵とは、公開鍵暗号における公開鍵である。連絡先５４００は、決済仲介システム１２００から参加者に情報を送る際の連絡先であり、例えばＥメールアドレス、住所、電話番号である。図５はＥメールアドレスの場合の例である。
【００３９】
上述した署名の検証は、まず参加者ＤＢ１２１０の中から、参加者ＩＤ５１００の値が、支払意図３０００の支払人ＩＤ３２００と同一の参加者情報５０００を選択する。次に、選択した参加者情報５０００の公開鍵５３００を抽出する。この公開鍵５３００を用いて支払人署名３７００の検証を行う。公開鍵による署名検証は、公知技術であるＸＭＬ（Extensible Mark-up Language）文章等に対する電子署名の検証と同様に行う。
【００４０】
具体的には、署名対象である支払意図ＩＤ３０５０，取引ＩＤ３１００、支払人ＩＤ３２００、支払額３３００，支払日３４００，支払口座３５００、受取人ＩＤ３６００、本登録条件４０００の内容を一連のビット列にシリアライズする。さらにシリアライズしたビット列のハッシュ値を計算する。これらの処理は署名付与時に行った処理と同じである。
【００４１】
次に、支払人署名３７００の内容を抽出した公開鍵５３００を用いて復号化する。この復号した値とハッシュ値が同一である場合は署名が正当であると判断し、異なる場合は正当ではないと判断する。以下、本明細書において署名を検証する場合は、上記署名検証方法と同じ方法で行うものとする。
【００４２】
次に、支払人署名３７００が正当と判断した場合は受信した支払意図３０００を格納する支払意図情報６０００を作成して支払意図ＤＢ１２２０に登録し、正当ではないと判断した場合には支払意図登録受付処理１２１５を終了する。
【００４３】
図６は、支払意図ＤＢ１２２０の構造例を示す図である。支払意図ＤＢ１２２０に登録してある支払意図情報６０００は、同図に示すように、支払意図３０００、振込口座指定データ８０００および複数の本登録要求７０００を格納する記憶エリアと、さらに状態６１００を含むデータである。
【００４４】
本登録要求７０００は、同一の支払意図情報６０００内の支払意図３０００に対して本登録を要求するデータである。振込口座指定データ８０００は、同一の支払意図情報６０００内の支払意図３０００により支払われる代金を受け取る口座を指定するデータである。本登録要求７０００（図７参照）および振込口座指定データ８０００（図８参照）の詳細については後述する。
【００４５】
状態６１００は、同一の支払意図情報６０００内の支払意図３０００の状態を保持するデータであり、「仮登録」、「本登録」、「支払済」、「失効済」の４つの状態をとる。ここで、「仮登録」とは、支払意図３０００が仮登録された状態（本登録になっていない状態）であることを示す。「本登録」とは、支払意図３０００が本登録された状態であることを示す。「支払済」とは、支払意図３０００の内容に従い債務者から債権者に代金の支払が完了したことを示す。「失効済」とは、支払意図３０００が失効したことを示す。支払意図情報６０００の支払意図ＤＢ１２２０への登録は、支払意図３０００を支払意図情報６０００に格納し、さらに状態６１００を「仮登録」として登録する。
【００４６】
次に、支払意図３０００の受取人ＩＤ３６００と同一の参加者ＩＤ５１００を有する参加者情報５０００を参加者ＤＢ１２１０から検索する。次に、検索した参加者情報５０００の連絡先５４００を用いて、販売者に対して支払意図３０００が仮登録されたことを通知する。これは、例えば連絡先５４００がＥメールアドレスの場合は、「支払意図が仮登録されました」という文字列と共に、支払意図３０００を送信する。本実施形態においては前記メッセージは販売者システム１３００に送信され、販売者システム１３００の出力装置２０５０に前記メッセージが表示される。
【００４７】
次に、購入者が代金を受け取る口座を指定する処理である購入者システム１１００の振込口座指定処理１３１０について説明する。
振込口座指定処理１３１０では、まず、振込口座指定データ８０００を作成する。図８は、振込口座指定データ８０００の構造例を示す図である。振込口座指定データ８０００は、同図に示すように、支払意図ＩＤ３０５０，振込口座８２００，受取人署名８３００から構成される。
【００４８】
支払意図ＩＤ３０５０は、振込口座指定データ８０００がどの支払意図３０００に対して振込口座を指定するデータなのかを特定するためのデータである。振込口座８２００は代金を受け取る口座を指定するデータである。受取人署名８３００は、振込口座指定データ８０００が販売者の意志に基づき生成されたものかを検証するためのデータである。
【００４９】
振込口座指定データ８０００の作成は、支払意図ＩＤ３０５０、振込口座８２００の値を、販売者システム１３００の入力装置２０４０を用いて外部から入力を受ける。なお、販売者は、支払意図ＩＤ３０５０を例えば決済仲介システム１２００から通知される支払意図３０００の仮登録通知内に含まれる支払意図ＩＤ３０５０により知りうることができる。
【００５０】
これらの入力後、支払意図ＩＤ３０５０と振込口座８２００に対する署名を販売者秘密鍵１３９０を用いて計算し受取人署名８３００に記録する。署名の付与は前述の付与方法と同様に行う。次に、このようにして販売者システム１３００で作成した振込口座指定データ８０００を決済仲介システム１２００に送信する。
【００５１】
次に、決済仲介システム１２００は、販売者システム１３００から振込口座指定データ８０００を受信すると、振込口座指定受付処理１２２５を起動する。以下、振込口座指定受付処理１２２５の処理手順について述べる。
【００５２】
まず、販売者システム１３００から受信した振込口座指定データ８０００の支払意図ＩＤ３０５０と同一の支払意図ＩＤ３０５０を有する支払意図３０００を支払意図ＤＢ１２２０に登録してある支払意図情報６０００の中から検索する。見つからない場合は振込口座指定受付処理１２２５を終了する。
【００５３】
見つかった場合は、次に、検索した支払意図３０００の受取人ＩＤ３６００と同一の参加者ＩＤ５１００を有する参加者情報５０００を参加者ＤＢ１２１０から検索する。見つからない場合は振込口座指定受付処理１２２５を終了する。
【００５４】
見つかった場合は、次に、検索した参加者情報５０００の公開鍵５３００を用いて、受信した振込口座指定データ８０００の受取人署名８３００が正当な署名であるかを検証する。署名の検証は前述の検証方法と同様に行う。署名が正当でないと判断した場合は振込口座指定受付処理１２２５を終了する。正当と判断した場合は、検索した支払意図３０００を含む支払意図情報６０００に、受信した振込口座指定データ８０００を格納する。
【００５５】
次に、本システムの範囲外であるが、実際の処理では、支払意図３０００により支払が行われる取引商品を購入者に配送するように販売者から配送業者に対して指示が出される。この指示は具体的には実社会における郵便や宅配要求である。これにより購入者に商品が配送される。
配送後、本発明では、以下のような処理を行う。
【００５６】
配送業者システム１７００における本登録要求処理１７１０において、本登録要求７０００を生成する。図７は、本登録要求７０００の構造例を示す図である。本登録要求７０００は、同図に示すように、取引ＩＤ３１００、本登録要求者ＩＤ４３００、本登録要求者署名７１００から構成される。取引ＩＤ３１００は、どの取引に関する支払意図３０００の本登録を要求するかを特定するためのデータである。本登録要求者ＩＤ４３００は、本登録要求を行おうとする者を特定するためのデータである。本登録要求者署名７１００は、本登録要求７０００が、本登録要求７０００を行おうとする者の意志に基づき作成されたものかを検証するためのデータである。
【００５７】
取引ＩＤ３１００と本登録要求者ＩＤ４３００は、配送業者システム１７００の入力装置２０４０より外部から入力を受ける。ここでの取引ＩＤ３１００は、支払意図３０００の取引ＩＤ３１００と同じ値をとる。これは、例えば売買契約時に購入者と販売者の双方で取引ＩＤを取り決めておき、商品を配送する際に購入者から配送業者にこの取引ＩＤを通知することにより配送業者が知り得る情報となる。次に、配送業者秘密鍵１７９０を用いて、取引ＩＤ３１００と本登録要求者ＩＤ４３００に対する署名を作成して本登録要求者署名７１００に格納する。署名の付与は前述した署名付与方法と同様に行う。次に、このようにして配送業者システム１７００で作成した本登録要求７０００を決済仲介システム１２００に送信する。
【００５８】
次に、決済仲介システム１２００は、配送業者システム１７００から本登録要求７０００を受信すると、本登録要求受付処理１２３０を起動する。以下、本登録要求受付処理１２３０の処理手順について述べる。
まず、受信した本登録要求７０００の本登録要求者署名７１００が正当な署名であるかを検証する。この検証手順は、前述した支払意図３０００の支払人署名３７００の検証と同じであり、参加者ＤＢ１２１０の中で、参加者ＩＤ５１００が本登録要求者ＩＤ４３００と一致する参加者情報５０００の公開鍵５３００を用いて検証する。検証が失敗すると本登録要求受付処理１２３０を中止する。
【００５９】
検証が成功した場合は、支払意図ＤＢ１２２０に登録してある支払意図情報６０００の中から、受信した本登録要求７０００の取引ＩＤ３１００と一致する取引ＩＤ３１００を有する支払意図３０００を検索する。次に、検索した支払意図３０００に含まれる本登録条件４０００の本登録要求者ＩＤ４３００の中で受信した本登録要求７０００の本登録要求者ＩＤ４３００と同一の値を含むものが存在するかを判別する。存在しない場合は本登録要求受付処理１２３０を中止する。存在する場合は、検索した支払意図３０００を含む支払意図情報６０００の本登録要求７０００の記憶エリアに、受信した本登録要求７０００を記憶する。
【００６０】
次に、決済仲介システム１２００で定期的（例えば１時間毎など）に実行される定期処理１２４０の処理手順を説明する。定期処理１２４０は、支払意図ＤＢ１２２０内の各々の支払意図情報６０００に対して定期的に状態６１００を遷移させることと、決済日を迎えた支払意図３０００に対する代金の支払いを金融機関システム１４００に指示することを目的とした処理である。
【００６１】
図９は、定期処理１２４０の処理手順を示すフローチャートである。
同図に示すように、まず、決済仲介システム１２００は、処理ステップ９０１０において、後述する処理ステップ９０２０〜９０５０によってなされる処理ループにおいて未処理の支払意図情報６０００を支払意図ＤＢ１２２０から選択する。以後、処理ステップ９０５０を除く本処理の説明において、単に支払意図情報６０００と記した場合は、本処理で選択した支払意図情報６０００を指すものとする。
【００６２】
次に、処理ステップ９０２０において、支払意図情報６０００の状態６１００が「支払済」か「失効済」かを判断し、「支払済」あるいは「失効済」である場合は（処理ステップ９０２０：Ｙ）、処理ステップ９０５０に進み、「支払済」および「失効済」でない場合は（処理ステップ９０２０：Ｎ）、処理ステップ９０３０に進む。
【００６３】
処理ステップ９０３０において、支払意図情報６０００の状態６１００が「仮登録」かを判断し、「仮登録」である場合には（処理ステップ９０３０：Ｙ）、処理ステップ９０６０に進み、「仮登録」でない場合は（処理ステップ９０３０：Ｎ）、処理ステップ９０４０に進む。処理ステップ９０４０において、支払意図情報６０００の支払意図３０００の支払日３４００が過ぎたかを判断し、過ぎた場合は（処理ステップ９０４０：Ｙ）、処理ステップ９１００に進み、過ぎてない場合は（処理ステップ９０４０：Ｎ）、処理ステップ９０５０に進む。処理ステップ９０５０において、支払意図ＤＢ１２２０に登録してある全ての支払意図情報６０００に対して処理が完了したかを判断し、完了したと判断した場合は（処理ステップ９０５０：Ｙ）、定期処理１２４０を終了し、完了していないと判断した場合は（処理ステップ９０５０：Ｎ）、処理ステップ９０１０に戻る。
【００６４】
また、処理ステップ９０６０では、支払意図情報６０００の支払意図３０００の本登録条件４０００（以下本処理ステップの説明においては単に本登録条件４０００と記載する）で未成立の条件があるかを判断し、未成立の条件がある場合には（処理ステップ９０６０：Ｙ）、処理ステップ９０８０に進み、未成立の条件がない場合は（処理ステップ９０６０：Ｎ）、処理ステップ９０７０に進む。
【００６５】
ここで、本登録条件４０００における条件の成立の判断は、具体的には以下の本登録条件４０００の各々の項目に対して条件が成立するかを判断することによって行われる。
まず、有効日４１００が過ぎたかを判断する。次に、有効期限４２００を過ぎていないかを判断する。
【００６６】
次に、全の本登録条件４０００の本登録要求者ＩＤ４３００と同一の本登録要求者ＩＤ４３００を有する本登録要求７０００が支払意図情報６０００に存在するかを判断する。またさらに支払意図情報６０００の支払意図３０００に複数の取引ＩＤ３１００が含まれている場合には、全ての取引ＩＤ３１００と本登録要求者ＩＤ４３００の組み合わせを有する本登録要求７０００が存在するかを判断する。
【００６７】
例えば、支払意図情報６０００の支払意図３０００の取引ＩＤ３１００として、「取引ＩＤ１」，「取引ＩＤ２」の２つが含まれているとし、本登録条件４０００の本登録要求者ＩＤ４３００として「本登録要求者１」「本登録要求者２」が含まれている場合には、取引ＩＤ３１００および本登録条件４０００の組み合わせに、「取引ＩＤ１」と「本登録要求者１」、「取引ＩＤ１」と「本登録要求者２」、「取引ＩＤ２」と「本登録要求者１」、「取引ＩＤ２」と「本登録要求者２」を持つ４つの本登録要求７０００が存在する場合に、全ての本登録要求７０００が存在すると判断する。上記判断により、支払意図３０００が複数の取引の支払に使用する場合に、全ての取引が成立した場合にのみ支払意図３０００を本登録するように制御可能となる。
【００６８】
処理ステップ９０７０において、支払意図情報６０００の状態６１００を「本登録」に遷移する。その後、処理ステップ９０７５において、支払意図情報６０００の支払意図３０００の支払人ＩＤ３２００と受取人ＩＤ３６００と同一の値を参加者ＩＤ５１００に持つ参加者情報５０００をそれぞれに対して一つずつを検索し、検索したそれぞれの参加者情報５０００の連絡先５４００に対して、支払が行われた旨を通知する。例えば、「本登録済」の文字列と共に支払意図３０００を送信する。処理ステップ９０７５の終了後は、処理ステップ９０５０に進む。
【００６９】
本登録条件４０００で未成立の条件がある場合は（処理ステップ９０６０：Ｙ）、処理ステップ９０８０において、支払意図情報６０００の支払意図３０００の本登録条件４０００の有効期限４２００を過ぎていないかを判断し、過ぎていない場合は（処理ステップ９０８０：Ｙ）、処理ステップ９０５０に進み、過ぎている場合は（処理ステップ９０８０：Ｎ）、処理ステップ９０９０に進む。処理ステップ９０９０において、支払意図情報６０００の状態６１００を「失効済」に遷移する。処理ステップ９０９０の終了後、処理ステップ９０５０に進む。
【００７０】
処理ステップ９０４０において、支払意図情報６０００の支払意図３０００の支払日３４００を迎えている場合は（処理ステップ９０４０：Ｙ）、処理ステップ９１００において、支払意図情報６０００に振込口座指定データ８０００が未登録かを判断し、未登録である場合は（処理ステップ９１００：Ｙ）、処理ステップ９０５０に進み、登録済の場合は（処理ステップ９１００：Ｎ）、処理ステップ９１１０に進む。
【００７１】
処理ステップ９１１０において、決済仲介システム１２００は、金融機関システム１４００に対して、支払意図情報６０００の支払意図３０００の支払口座３５００と支払額３３００を送信し、支払処理１４２０を実行するように要求する。さらに決済仲介システム１２００は、金融機関システム１４００に対して、支払意図情報６０００の振込口座指定データ８０００の振込口座８２００と支払意図情報６０００の支払意図３０００の支払額３３００を送信して振込処理１４１０を実行するように要求する。
【００７２】
なお、上記実施例では、振込処理１４１０と支払処理１４２０は同一の金融機関システム１４００で行う例について述べたが、それぞれを別の金融機関システム１４００で実施するようにしてもよい。具体的には、支払口座と振込口座が別の金融機関の口座である場合がこのケースにあたる。
【００７３】
次に、処理ステップ９１２０において、支払意図情報６０００の支払意図３０００の支払人ＩＤ３２００と受取人ＩＤ３６００と同一の値を参加者ＩＤ５１００に持つ参加者情報５０００をそれぞれに対して一つずつ検索する。次に、決済仲介システム１２００は、検索したそれぞれの参加者情報５０００の連絡先５４００に対して、支払が行われた旨を通知する。例えば、「支払済」の文字列と共に支払意図３０００を送信する。処理ステップ９１２０の終了後、処理ステップ９０５０に進む。
【００７４】
次に、金融機関システム１４００の振込処理１４１０について説明する。
金融機関システム１４００の振込処理１４１０は、決済仲介システム１２００から振込口座８２００と支払額３３００を受信すると、口座ＤＢ１４８０から振込口座８２００と同一の値の口座番号１１１００を有する口座情報１３０００を検索する。口座ＤＢ１４８０の構造は、図１０に示すように、いくつかの口座情報１３０００からなるテーブルである。
【００７５】
口座情報１３０００は、口座番号１１１００と残高１１３００から構成される。口座番号１１１００は、各々の口座を特定するためのデータである。残高１１３００は、口座の残高を示すデータである。次に、検索した口座情報１３０００の残高１１３００の値に、受信した支払額３３００の値を加える。
【００７６】
次に、金融機関システム１４００の支払処理１４２０について述べる。支払処理１４２０は、決済仲介システム１２００から支払口座３５００と支払額３３００を受信すると、口座ＤＢ１４８０から振込口座８２００と同一の値の口座番号１１１００を有する口座情報１３０００を検索する。次に、検索した口座情報１３０００の残高１１３００の値から受信した支払額３３００の値を引く。
【００７７】
以下、本発明の第１の実施形態についてまとめる。
第１の実施形態において、支払人（購入者）は支払意図３０００の登録時に、支払意図３０００を本登録するための条件である本登録条件４０００を一緒に登録する。支払人は支払意図３０００および本登録条件４０００の双方を含めて署名することにより、支払意図３０００および本登録条件４０００のいずれもが支払人の意志により作成されたことが確認可能となる。
【００７８】
仮登録された支払意図３０００は、本登録条件４０００内で指定される条件（本登録可能な有効日を迎えたかあるいは本登録が可能な有効期限内であるか本登録要求７０００を指定された者から受信したか）が満たされた場合に本登録となる。これにより受取人（販売者）等、配送業者、金融機関が、仮登録された支払意図３０００の内容を確認した上で、支払人が指定する条件を満たすような処理を行うことにより仮登録された支払意図３０００を本登録することができる。
【００７９】
この仕組みを応用することで、商品の販売者が購入者が仮登録した支払意図３０００の内容を確認した上で配送業者に商品の配送指示を出し、配送業者が購入者に商品を配送と共に、本登録を要求することで支払意図３０００の本登録と商品の配送を同期させることができる。また金融機関は、仮登録された支払意図３０００の内容を確認した上で、支払意図３０００の振り出しの承認あるいは支払保証を行い、支払意図３０００を本登録させることができる。
【００８０】
以上による支払人におけるメリットとしては、まず、支払義務が生じない仮登録という状態で支払意図３０００が提示でき、受取人の契約不履行（商品を発送しない等）時には支払意図３０００が効力が発生しないようにできる。さらに、前記手続きが決済仲介システム１２００に一度アクセスするだけで実現できる（複数回のアクセスを必須としない）こともメリットである。
【００８１】
また、支払意図３０００の振り出しの承認あるいは支払保証の審査中に、不正に効力を持つ支払意図３０００が流通するリスクも回避することができる。
【００８２】
一方、受取人におけるメリットは、支払意図３０００の支払意図３０００の本登録前にその内容が確認でき、またその内容に従い本登録されるため、契約履行後に条件と異なる支払意図３０００が発行されることを未然に防ぐことができる。
【００８３】
なお、本実施形態では、商品の代金の支払いに支払意図を用いる場合を具体例としてあげたが、資金の借り入れの代償として支払意図を用いる場合（電子社債や電子ＣＰ）においても配送業者を金融機関に置き換えることで実現可能である。
【００８４】
次に、本発明の第２の実施形態について述べる。
図１１は、本発明の第２の実施形態におけるシステム構成図である。
第２の実施形態のシステム構成は、第１の実施形態のシステム構成と以下の点において異なる。
【００８５】
まず、決済仲介システム１２００には、支払意図登録受付処理１２１５の代わりに支払意図登録受付処理’１０４００を記憶する。また金融機関システム１４００には、支払処理１４２０の代わりに支払処理’１０３００を記憶し、新たに支払条件確認処理１０１００と引き出し処理１０６００を記憶する。また金融機関システム１４００の口座ＤＢ１４８０には、口座情報１３０００の代わりに口座情報’１１０００を記憶する。口座情報’１１０００の構造については後述する（図１２参照）。購入者システム１１００には、支払意図登録処理１１１０の代わりに支払意図登録処理’１０５００を記憶する。
【００８６】
次に、第２の実施形態の処理手順について、第１の実施形態と異なる手順についてのみ説明する。
最初に、購入者システム１１００の支払意図登録処理’１０５００における変更は、支払意図登録処理１１１０で本登録条件４０００の本登録要求者ＩＤ４３００として運送業者を特定するためのＩＤを指定していたのを、運送業者と金融機関を特定するＩＤを指定する点で異なる。
【００８７】
次に、決済仲介システム１２００の支払意図登録受付処理’１０４００では、支払意図登録受付処理１２１５の全ての処理が完了した後に、金融機関システム１４００に購入者システム１１００より受信した支払意図３０００を送信して、支払条件確認処理１０１００を呼び出す点で異なる。
【００８８】
金融機関システム１４００の支払条件確認処理１０１００は、支払意図３０００に対して与信を行うかを判断する処理であり、以下その処理内容について述べる。支払条件確認処理１０１００は、受信した支払意図３０００（以下、本処理の説明において単に支払意図３０００と記載）の支払口座３５００と同一の口座番号１１１００を有する口座情報’１１０００を口座ＤＢ１４８０から検索する。
【００８９】
第２の実施形態における口座情報’１１０００の構造は、図１２に示すように、図１０の口座情報１３０００が持つ項目以外に、支払予定額１１５００と公開鍵５３００を持つ。
【００９０】
公開鍵５３００は、参加者情報５０００の持つ同項目と同じである。支払予定額１１５００は、同一の口座情報’１１０００に含まれる口座番号１１１００により特定される口座から、今後支払が予定されている金額の情報である。なお、第２の実施形態においては、第１の実施形態における口座情報１３０００を口座情報’１１０００に変更したことにより、金融機関システム１４００の全ての処理は、口座情報１３０００ではなく口座情報’１１０００に対して処理を行うものとする。
【００９１】
次に、検索した口座情報’１１０００の公開鍵５３００を用いて支払意図３０００の支払人署名３７００が正当な署名であるかを検証する。これにより正当な口座の所持人からの支払要求であるかを確認する。正当な署名でない場合は、支払条件確認処理１０１００を終了する。
【００９２】
次に、検索した口座情報’１１０００の残高１１３００と支払意図３０００の支払額３３００を比較して、支払額３３００の一定の割合以上の（あるいは超える）金額が残高１１３００に残っているかを確認する。前記割合は、金融機関と購入者との間で別途合意されているものであり、例えば支払額３３００の１／１０以上などである。
【００９３】
残高１１３００が不足している場合は、支払条件確認処理１０１００を終了する。次に、検索した口座情報’１１０００の支払予定額１１５００に支払意図３０００の支払額３３００を加えた金額が、一定の金額を超えないか確認する。前記一定の金額とは、金融機関と購入者との間で事前に合意されているものであり、例えば支払額１億円以下（あるいは未満）などの情報である。前記金額を越えた場合は、支払条件確認処理１０１００を終了する。
【００９４】
次に、検索した口座情報’１１０００の支払予定額１１５００に支払意図３０００の支払額３３００を加える。次に、支払意図３０００に含まれる全ての取引ＩＤ３１００に対する本登録要求７０００を作成し、決済仲介システム１２００に送信する。具体的には、各々の取引ＩＤ３１００と、本登録者ＩＤ４３００として金融機関を特定するＩＤを含む本登録要求７０００を作成する。さらに金融機関秘密鍵１４９０を用いて前記取引ＩＤ３１００と、本登録者ＩＤ４３００に対する署名値を計算し、本登録要求者署名７１００に格納する。
【００９５】
次に、金融機関システム１４００の引き出し処理１０６００について述べる。本実施形態における引き出しとは、支払意図３０００の決済以外の目的で、口座から資金を払い出す行為を指すものとする。具体的には口座からの現金の引き出しや他の口座に対する振替を指すものとする。金融機関システム１４００は、口座番号１１１００と引き出す金額を外部より受信する。ここで外部とは金融機関システム１４００の入力装置２０４０から入力を受けるものとする。実際には金融機関システム１４００はＡＴＭ（現金自動支払機）から引き出し要求や振替要求を受けそれが外部からの入力となるが本実施形態ではそれを単純化してある。
【００９６】
次に、受信した口座番号１１１００と同一の口座番号１１１００を持つ口座情報’１１０００を口座ＤＢ１４８０から検索する。次に、検索した口座情報’１１０００の残高１１３００から受信した引き出し金額を引いた金額が支払予定額１１５００の金額以上の（あるいは越える）場合のみ支払を引き出しを許可する。具体的な引き出し方法については、従来のＡＴＭによる支払や口座振替と同じであるので詳細は割愛する。
【００９７】
次に、金融機関システム１４００の支払処理’１０３００について述べる。支払処理’１０３００が支払処理１４２０の処理が完了した後に、口座情報’１１０００の支払予定額１１５００から受信した支払額３３００を引く。
【００９８】
以下、本発明の第２の実施形態についてまとめる。
第２の実施形態では、支払意図３０００が本登録条件４０００に金融機関からの本登録要求７０００を受ける条件を加える。金融機関は支払意図３０００に対し、正当な者からの要求であるか、また支払口座３５００の残高が一定の金額以上残っているか、また既に支払が約束されている支払金額が一定の金額以内かを判断した上で本登録要求７０００を送信する。この本登録要求７０００をする意味は、例えば支払意図３０００の発行許可、あるいは支払意図３０００に対する保証（購入者が支払えない場合の金融機関の代理支払の約束）であるものとする。
【００９９】
さらに第２の実施形態では、金融機関システム１４００は、口座の残高が、仮登録した支払意図３０００により約束される支払金額分の合計以上に達するまで、口座からの資金の引き出しを制限する。以上により、金融機関が、支払意図３０００の支払元となる口座の残高やその口座から今後支払が予定されている金額の確認、また支払意図３０００を振り出した者の口座に対する権限を確認した上で、支払意図３０００の振り出しを許可するあるいは保証を行う決済モデルが実現できる。
【０１００】
本発明の実施形態により、商品の受渡しや資金決済と同期して電子手形・電子小切手の受渡しを行う仕組みが提供でき、電子手形・電子小切手決済を用いたエスクローサービスを提供できる。またこの際に、エスクローサービスを提供する仲介業者が電子手形・電子小切手の受取人・支払人にはならず、商品の販売者・購入者間でのみ電子手形・電子小切手による支払の約束がなされる決済モデルが実現できる。これにより仲介業者の信用リスクが生じなくなる。
【０１０１】
また本発明の実施形態により、電子手形・電子小切手を振り出す際に振出許可あるいは支払保証を受けた上で振り出す仕組みを提供できる。さらには振出許可あるいは支払保証の処理中に債権・債務の効力を持つ電子手形・小切手が不正に流通することを防止する仕組を提供できる。
【０１０２】
なお、上記第１の実施形態および第２の実施形態における電子決済仲介方法やシステムを実現するためのプログラムは、ＣＤ−ＲＯＭ，ＤＶＤなどのコンピュータ読み取り可能な記録媒体に記録して流通させたり、ネットワークを介して配布することが可能である。本発明を利用しようとする者は、記録媒体やネットワークから本発明に係るプログラムを入手してシステムにロードすることによって本発明の電子決済方法を容易に実現することができる。
【０１０３】
【発明の効果】
本発明によれば、決済仲介者の故障や不正によって生じる決済者または被決済者の損害を低減するという効果を奏する。
また、本発明によれば、電子手形や電子小切手が不正にまたは無断で流通した場合に生じる決済者または被決済者の損害を低減するという効果を奏する。
【図面の簡単な説明】
【図１】本発明の第１の実施形態におけるシステム構成図である。
【図２】本発明の第１の実施形態における購入者システムの構造例を示す図である。
【図３】本発明の第１の実施形態における支払意図の構造例を示す図である。
【図４】本発明の第１の実施形態における本登録条件の構造例を示す図である。
【図５】本発明の第１の実施形態における参加者ＤＢの構造例を示す図である。
【図６】本発明の第１の実施形態における支払意図ＤＢの構造例を示す図である。
【図７】本発明の第１の実施形態における本登録要求の構造例を示す図である。
【図８】本発明の第１の実施形態における振込口座指定データの構造例を示す図である。
【図９】本発明の第１の実施形態における定期処理のフローチャートを示す図である。
【図１０】本発明の第１の実施形態における口座情報の構造例を示す図である。
【図１１】本発明の第２の実施形態におけるシステム構成図である。
【図１２】本発明の第２の実施形態における口座情報の構造例を示す図である。
【符号の説明】
１１００：購入者システム、１２００：決済仲介システム、１２１０：参加者ＤＢ、１２２０：支払意図ＤＢ、１３００：販売者システム、１４００：金融機関システム、１４８０：口座ＤＢ、１５００：ネットワーク、１７００：配送業者システム、
２０１０：記憶装置、２０２０：通信装置、２０３０：処理装置、２０４０：入力装置、２０５０：出力装置、２０７０：バス、
３０００：支払意図、４０００：本登録条件、７０００：本登録要求、８０００：振込口座指定データ。

Claims (7)

1. 電子データの送受信を利用した電子決済を仲介する、コンピュータによる電子決済仲介方法であって、
   前記コンピュータの通信装置が、金銭の支払人あるいは該支払人の代理人が使用する支払人システムから金銭の支払う意図に関する電子データである支払意図情報であって、当該支払意図情報に係る取引を特定するための電子データである複数の取引ＩＤ情報、前記支払人を特定するデータである支払人ＩＤ情報、前記金銭の受取人を特定するデータである受取人ＩＤ情報、前記取引の金額情報、及び金銭の支払日情報を含む前記支払意図情報と、該支払意図による債権・債務が発生する条件に関する電子データである本登録条件情報であって、前記債権・債務がその日以降に発生可能とする日時を指定する電子データである有効日情報、前記債権・債務がその日時までに発生しないとそれ以降は前記債権・債務の発生を禁止する日時を指定する電子データである有効期限情報、前記受取人から前記支払人への前記取引に係る商品の運送を仲介する運送業者を特定するデータである運送業者ＩＤ情報及び前記支払人から前記受取人への前記金銭の支払いを仲介する金融機関を特定するデータである金融機関ＩＤ情報を含む前記本登録条件情報の両者を受信し、
   前記コンピュータの処理装置が、受信された前記支払意図情報と前記本登録条件情報を前記コンピュータの記憶装置に格納し、
   前記処理装置が、前記支払意図情報を、前記通信装置を介して、前記金融機関のシステムへ送信し、
   前記通信装置が、前記金融機関が前記支払人から前記受取人への前記金銭の支払いを保証可能な場合に、前記金融機関のシステムから前記支払意図情報に含まれる前記取引ＩＤ情報と前記金融機関ＩＤ情報を受信し、
   前記処理装置が、受信された前記取引ＩＤ情報に対応する取引ＩＤ情報を含む前記支払意図情報に対応して、前記金融機関ＩＤ情報を前記記憶装置に格納し、
   前記通信装置が、前記運送業者のシステムから取引ＩＤ情報と運送業者ＩＤ情報を受信し、
   前記処理装置が、受信された前記取引ＩＤ情報に対応する取引ＩＤ情報を含む前記支払意図情報に対応して、前記運送業者ＩＤ情報を前記記憶装置に格納し、
   前記処理装置が、未処理の前記支払意図情報を前記記憶装置から定期的に読み出し、
   前記処理装置が、読み出された前記支払意図情報の状態が支払済又は失効済であるかを判断し、
   前記処理装置が、支払済及び失効済でない前記支払意図情報に対応する前記支払人システムからの本登録条件情報と支払済及び失効済でない前記支払意図情報に対応する前記金融機関システムからの金融機関ＩＤ情報及び前記運送業者システムからの運送業者ＩＤ情報を前記記憶装置から読み出し、前記支払人システムからの本登録条件情報に含まれる前記金融機関ＩＤ情報及び前記運送業者ＩＤ情報と前記金融機関のシステムからの金融機関ＩＤ情報及び前記運送業者のシステムからの運送業者ＩＤ情報とが一致するか否かを判断し、前記本登録条件情報に含まれる前記有効日情報で示された日を過ぎているか否かを判断し、及び前記本登録条件情報に含まれる前記有効期限情報で示された期限を過ぎていないか否かを判断し、前記支払意図情報に含まれる前記複数の取引ＩＤ情報について前記支払人システムからの本登録条件情報に含まれる前記金融機関ＩＤ情報及び前記運送業者ＩＤ情報と前記金融機関のシステムからの金融機関ＩＤ情報及び前記運送業者システムからの運送業者ＩＤ情報が一致し、前記本登録条件情報に含まれる前記有効日情報で示された日を過ぎ、及び前記本登録条件情報に含まれる前記有効期限情報で示された期限を過ぎていない場合に、前記本登録条件が成立したと判断し、
   前記処理装置が、該本登録条件が成立したと判断した場合に、読み出された前記支払意図情報に含まれる前記支払日で示された日を過ぎているか否かを判断し、
   前記処理装置が、前記支払日で示された日を過ぎていると判断した場合に、前記支払意図情報に含まれる前記取引の金額情報で示される金額を、前記支払人が保有する財貨の中から前記支払意図情報で示された前記受取人が保有する財貨の中に移動することを指示するための電子データを、前記通信装置を介して前記金融機関のシステムへ送信し、
   前記処理装置が、前記有効期限情報で示された期限を過ぎている場合に、前記記憶装置内の前記支払意図情報の状態を失効済へ遷移することを特徴とする電子決済仲介方法。
2. 請求項１記載の電子決済仲介方法であって、
   前記金融機関のシステムが、前記支払人の口座の残高が前記支払意図情報に含まれる前記取引の金額情報で示される金額の一定の割合以上であることを判断することにより、前記金融機関が前記支払人から前記受取人への前記金銭の支払い保証することを特徴とする電子決済仲介方法。
3. 請求項１記載の電子決済仲介方法であって、
   前記金融機関のシステムが、前記支払人の口座の残高が前記支払意図情報に含まれる前記取引の金額情報で示される金額に達していない場合に、前記支払人の口座の残高が前記支払意図情報に含まれる前記取引の金額情報で示される金額に達するまで、前記支払人の口座からの金銭の引き出しを制限することにより、前記金融機関が前記支払人から前記受取人への前記金銭の支払い保証することを特徴とする電子決済仲介方法。
4. 電子データの送受信を利用した電子決済を仲介する電子決済仲介システムであって、
   記憶装置と、
   金銭の支払人あるいは該支払人の代理人が使用する支払人システムから金銭の支払う意図に関する電子データである支払意図情報であって、当該支払意図情報に係る取引を特定するための電子データである複数の取引ＩＤ情報、前記支払人を特定するデータである支払人ＩＤ情報、前記金銭の受取人を特定するデータである受取人ＩＤ情報、前記取引の金額情報、及び金銭の支払日情報を含む前記支払意図情報と、該支払意図による債権・債務が発生する条件に関する電子データである本登録条件情報であって、前記債権・債務がその日以降に発生可能とする日時を指定する電子データである有効日情報、前記債権・債務がその日時までに発生しないとそれ以降は前記債権・債務の発生を禁止する日時を指定する電子データである有効期限情報、前記受取人から前記支払人への前記取引に係る商品の運送を仲介する運送業者を特定するデータである運送業者ＩＤ情報及び前記支払人から前記受取人への前記金銭の支払いを仲介する金融機関を特定するデータである金融機関ＩＤ情報を含む前記本登録条件情報の両者を受信する通信装置と、
   受信された前記支払意図情報と前記本登録条件情報を前記記憶装置に格納し、前記支払意図情報を、前記通信装置を介して、前記金融機関のシステムへ送信し、前記金融機関が前記支払人から前記受取人への前記金銭の支払いを保証可能で、前記金融機関のシステムからの前記支払意図情報に含まれる前記取引ＩＤ情報と前記金融機関ＩＤ情報が前記通信装置によって受信された場合に、受信された前記取引ＩＤ情報に対応する取引ＩＤ情報を含む前記支払意図情報に対応して、前記金融機関ＩＤ情報を前記記憶装置に格納し、前記運送業者のシステムからの取引ＩＤ情報と運送業者ＩＤ情報が前記通信装置によって受信された場合に、受信された前記取引ＩＤ情報に対応する取引ＩＤ情報を含む前記支払意図情報に対応して、前記運送業者ＩＤ情報を前記記憶装置に格納し、未処理の前記支払意図情報を前記記憶装置から定期的に読み出し、読み出された前記支払意図情報の状態が支払済又は失効済であるかを判断し、支払済及び失効済でない前記支払意図情報に対応する前記支払人システムからの本登録条件情報と支払済及び失効済でない前記支払意図情報に対応する前記金融機関システムからの金融機関ＩＤ情報及び前記運送業者システムからの運送業者ＩＤ情報を前記記憶装置から読み出し、前記支払人システムからの本登録条件情報に含まれる前記金融機関ＩＤ情報及び前記運送業者ＩＤ情報と前記金融機関のシステムからの金融機関ＩＤ情報及び前記運送業者のシステムからの運送業者ＩＤ情報とが一致するか否かを判断し、前記本登録条件情報に含まれる前記有効日情報で示された日を過ぎているか否かを判断し、及び前記本登録条件情報に含まれる前記有効期限情報で示された期限を過ぎていないか否かを判断し、前記支払意図情報に含まれる前記複数の取引ＩＤ情報について前記支払人システムからの本登録条件情報に含まれる前記金融機関ＩＤ情報及び前記運送業者ＩＤ情報と前記金融機関のシステムからの金融機関ＩＤ情報及び前記運送業者のシステムからの運送業者ＩＤ情報が一致し、前記本登録条件情報に含まれる前記有効日情報で示された日を過ぎ、及び前記本登録条件情報に含まれる前記有効期限情報で示された期限を過ぎていない場合に、前記本登録条件が成立したと判断し、該本登録条件が成立したと判断した場合に、読み出された前記支払意図情報に含まれる前記支払日で示された日を過ぎているか否かを判断し、前記支払日で示された日を過ぎていると判断した場合に、前記支払意図情報に含まれる前記取引の金額情報で示される金額を、前記支払人が保有する財貨の中から前記支払意図情報で示された前記受取人が保有する財貨の中に移動することを指示するための電子データを、前記通信装置を介して前記金融機関のシステムへ送信し、前記有効期限情報で示された期限を過ぎている場合に、前記記憶装置内の前記支払意図情報の状態を失効済へ遷移する処理装置とを有することを特徴とする電子決済仲介システム。
5. 請求項４記載の電子決済仲介システムであって、
   前記金融機関のシステムは、前記支払人の口座の残高が前記支払意図情報に含まれる前記取引の金額情報で示される金額の一定の割合以上であることを判断することにより、前記金融機関が前記支払人から前記受取人への前記金銭の支払い保証することを特徴とする電子決済仲介システム。
6. 請求項４記載の電子決済仲介システムであって、
   前記金融機関のシステムは、前記支払人の口座の残高が前記支払意図情報に含まれる前記取引の金額情報で示される金額に達していない場合に、前記支払人の口座の残高が前記支払意図情報に含まれる前記取引の金額情報で示される金額に達するまで、前記支払人の口座からの金銭の引き出しを制限することにより、前記金融機関が前記支払人から前記受取人への前記金銭の支払い保証することを特徴とする電子決済仲介システム。
7. 電子データの送受信を利用した電子決済を仲介する手段としてコンピュータを機能させるための電子決済仲介プログラムであって、
   前記コンピュータの通信装置を、金銭の支払人あるいは該支払人の代理人が使用する支払人システムから金銭の支払う意図に関する電子データである支払意図情報であって、当該支払意図情報に係る取引を特定するための電子データである複数の取引ＩＤ情報、前記支払人を特定するデータである支払人ＩＤ情報、前記金銭の受取人を特定するデータである受取人ＩＤ情報、前記取引の金額情報、及び金銭の支払日情報を含む前記支払意図情報と、該支払意図による債権・債務が発生する条件に関する電子データである本登録条件情報であって、前記債権・債務がその日以降に発生可能とする日時を指定する電子データである有効日情報、前記債権・債務がその日時までに発生しないとそれ以降は前記債権・債務の発生を禁止する日時を指定する電子データである有効期限情報、前記受取人から前記支払人への前記取引に係る商品の運送を仲介する運送業者を特定するデータである運送業者ＩＤ情報及び前記支払人から前記受取人への前記金銭の支払いを仲介する金融機関を特定するデータである金融機関ＩＤ情報を含む前記本登録条件情報の両者を受信する手段として機能させ、
   前記コンピュータの処理装置を、受信された前記支払意図情報と前記本登録条件情報を前記コンピュータの記憶装置に格納する手段として機能させ、
   前記処理装置を、前記支払意図情報を、前記通信装置を介して、前記金融機関のシステムへ送信する手段として機能させ、
   前記通信装置を、前記金融機関が前記支払人から前記受取人への前記金銭の支払いを保証可能な場合に、前記金融機関のシステムから前記支払意図情報に含まれる前記取引ＩＤ情報と前記金融機関ＩＤ情報を受信する手段として機能させ、
   前記処理装置を、受信された前記取引ＩＤ情報に対応する取引ＩＤ情報を含む前記支払意図情報に対応して、前記金融機関ＩＤ情報を前記記憶装置に格納する手段として機能させ、
   前記通信装置を、前記運送業者のシステムから取引ＩＤ情報と運送業者ＩＤ情報を受信する手段として機能させ、
   前記処理装置を、受信された前記取引ＩＤ情報に対応する取引ＩＤ情報を含む前記支払意図情報に対応して、前記運送業者ＩＤ情報を前記記憶装置に格納する手段として機能させ、
   前記処理装置を、未処理の前記支払意図情報を前記記憶装置から定期的に読み出す手段として機能させ、
   前記処理装置を、読み出された前記支払意図情報の状態が支払済又は失効済であるかを判断する手段として機能させ、
   前記処理装置を、支払済及び失効済でない前記支払意図情報に対応する前記支払人システムからの本登録条件情報と支払済及び失効済でない前記支払意図情報に対応する前記金融機関のシステムからの金融機関ＩＤ情報及び前記運送業者のシステムからの運送業者ＩＤ情報を前記記憶装置から読み出し、前記支払人システムからの本登録条件情報に含まれる前記金融機関ＩＤ情報及び前記運送業者ＩＤ情報と前記金融機関のシステムからの金融機関ＩＤ情報及び前記運送業者のシステムからの運送業者ＩＤ情報とが一致するか否かを判断し、前記本登録条件情報に含まれる前記有効日情報で示された日を過ぎているか否かを判断し、及び前記本登録条件情報に含まれる前記有効期限情報で示された期限を過ぎていないか否かを判断し、前記本登録条件情報に含まれる前記複数の取引ＩＤ情報について前記支払人システムからの本登録条件情報に含まれる前記金融機関ＩＤ情報及び前記運送業者ＩＤ情報と前記金融機関システムからの金融機関ＩＤ情報及び前記運送業者のシステムからの運送業者ＩＤ情報が一致し、前記本登録条件情報に含まれる前記有効日情報で示された日を過ぎ、及び前記本登録条件情報に含まれる前記有効期限情報で示された期限を過ぎていない場合に、前記本登録条件が成立したと判断する手段として機能させ、
   前記処理装置を、該本登録条件が成立したと判断した場合に、読み出された前記支払意図情報に含まれる前記支払日で示された日を過ぎているか否かを判断する手段として機能させ、
   前記処理装置を、前記支払日で示された日を過ぎていると判断した場合に、前記支払意図情報に含まれる前記取引の金額情報で示される金額を、前記支払人が保有する財貨の中から前記支払意図情報で示された前記受取人が保有する財貨の中に移動することを指示するための電子データを、前記通信装置を介して前記金融機関のシステムへ送信する手段として機能させ、
   前記処理装置を、前記有効期限情報で示された期限を過ぎている場合に、前記記憶装置内の前記支払意図情報の状態を失効済へ遷移する手段として機能させるための電子決済仲介プログラム。

Images