(57)【要約】【課題】ＥＣサイトなどにおけるエスクロー決済では、サービス提供者の各作業が独立しており、必ずしも安全性や信頼性が高いものとはいえない。また、スマートコントラクトによるエスクロー決済の場合、購入者はＢＣ上の資産である仮想通貨を利用する必要がある。【解決手段】エスクロー決済における一連の処理を、仮想通貨を用いない形でスマートコントラクトを用いて構築および実行することにより、安全性および信頼性を担保した取引を行なう。【選択図】図３
2018139068.tif 000002
【特許請求の範囲】
【請求項１】
スマートコントラクトによるエスクロー決済を実行するシステムにおけるコンピュータであって、前記コンピュータは第１のコンピュータであって、
第２のコンピュータから、購入希望商品の支払指示データを受信し、
前記支払指示データ、および前記購入希望商品の購入希望者の口座データに少なくとも基づいて、前記購入希望商品の販売者への代金の入金が可能か否かを判定し、
前記代金への入金が可能であると判定した場合、入金が可能である旨を前記スマートコントラクトが格納された第３のコンピュータに通知し、前記スマートコントラクトは、入金が可能である旨の前記通知を受信すると、前記第３のコンピュータに前記購入希望商品の決済処理を実行させるものであり、前記決済処理は、少なくとも、前記購入希望商品の支払処理および納品処理の指示を含み、
前記購入希望商品の決済データを前記第３のコンピュータから受信し、
前記決済データに基づいて、前記購入希望者から前記販売者への前記支払処理を実行する
ように構成されたことを特徴とするコンピュータ。
【請求項２】
前記支払処理の指示として、前記購入希望商品の前記決済データを前記第３のコンピュータから受信することは、前記第１のコンピュータ上のアプリケーションプログラムインターフェース（ＡＰＩ）が前記スマートコントラクトから呼び出されることにより行なわれるものであることを特徴とする請求項１に記載のコンピュータ。
【請求項３】
前記支払処理の実行結果を前記第３のコンピュータに通知するようにさらに構成され、前記実行結果が失敗したことを示す場合、前記スマートコントラクトは、前記第３のコンピュータに前記納品処理の指示を実行させないことを特徴とする請求項１または２に記載のコンピュータ。
【請求項４】
前記納品処理が失敗した場合に送信される前記支払処理の取消指示を前記第３のコンピュータから受信し、
前記取消指示を受信したことに応答して、前記支払処理の取消処理を実行する
ようにさらに構成されたことを特徴とする請求項１乃至３のいずれかに記載のコンピュータ。
【請求項５】
前記代金の入金が可能であると判定した場合、前記購入希望者の口座データから、前記代金を予め引き落とすようにさらに構成されたことを特徴とする請求項１乃至４のいずれかに記載のコンピュータ。
【請求項６】
スマートコントラクトによるエスクロー決済を実行するシステムにおける第１のコンピュータによって実行される方法であって、前記方法は、
前記第１のコンピュータが、第２のコンピュータから、購入希望商品の支払指示データを受信するステップと、
前記第１のコンピュータが、前記支払指示データ、および前記購入希望商品の購入希望者の口座データに少なくとも基づいて、前記購入希望商品の販売者への代金の入金が可能か否かを判定するステップと、
前記代金への入金が可能であると判定した場合、前記第１のコンピュータが、入金が可能である旨を前記スマートコントラクトが格納された第３のコンピュータに通知するステップであって、前記スマートコントラクトは、入金が可能である旨の前記通知を受信すると、前記第３のコンピュータに前記購入希望商品の決済処理を実行させるものであり、前記決済処理は、少なくとも、前記購入希望商品の支払処理および納品処理の指示を含む、ステップと、
前記第１のコンピュータが、前記購入希望商品の決済データを前記第３のコンピュータから受信するステップと、
前記第１のコンピュータが、前記決済データに基づいて、前記購入希望者から前記販売者への前記支払処理を実行するステップと
を備えたことを特徴とする方法。
【請求項７】
スマートコントラクトによるエスクロー決済を実行するシステムにおける第１のコンピュータに実行させるコンピュータプログラムであって、前記コンピュータプログラムは前記第１のコンピュータによって実行されると、
第２のコンピュータから、購入希望商品の支払指示データを受信するステップと、
前記支払指示データ、および前記購入希望商品の購入希望者の口座データに少なくとも基づいて、前記購入希望商品の販売者への代金の入金が可能か否かを判定するステップと、
前記代金への入金が可能であると判定した場合、入金が可能である旨を前記スマートコントラクトが格納された第３のコンピュータに通知するステップであって、前記スマートコントラクトは、入金が可能である旨の前記通知を受信すると、前記第３のコンピュータに前記購入希望商品の決済処理を実行させるものであり、前記決済処理は、少なくとも、前記購入希望商品の支払処理および納品処理の指示を含む、ステップと、
前記購入希望商品の決済データを前記第３のコンピュータから受信するステップと、
前記決済データに基づいて、前記購入希望者から前記販売者への前記支払処理を実行するステップと
を前記第１のコンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項８】
スマートコントラクトによるエスクロー決済を実行するシステムにおけるコンピュータであって、前記コンピュータは、第１のコンピュータであって、前記スマートコントラクトが格納され、前記スマートコントラクトに、
購入希望商品の販売者への代金の入金が可能である旨の通知を第２のコンピュータから受信させ、前記通知は、前記第２のコンピュータが購入希望商品の支払指示データを第３のコンピュータから受信したことに応答して、前記支払指示データ、および前記購入希望商品の購入希望者の口座データに少なくとも基づいて、前記購入希望商品の販売者への代金の入金が可能か否かを判定し、前記代金への入金が可能であると判定した場合に通知され、
入金が可能である旨の前記通知を受信すると、前記購入希望商品の決済データを作成させ、
前記第２のコンピュータに前記購入希望商品の決済処理を実行させるために、前記作成した決済データを前記第２のコンピュータに送信させ、前記決済処理は、少なくとも、前記購入希望商品の支払処理および納品処理の指示を含み、
前記決済処理の実行結果を前記第２のコンピュータから受信させ、
前記支払処理が成功したか否かを判定させ、
前記支払処理が成功したと判定した場合に、前記納品処理を実行させる
ように構成されたことを特徴とするコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スマートコントラクトによるエスクロー決済方法およびシステムに関する。より詳細には、エスクロー決済における一連の処理を、スマートコントラクトを用いて構築および実行することにより、安全性および信頼性を担保した取引を行なうことができる方法およびシステムに関する。
【背景技術】
【０００２】
エスクロー決済は、商取引における安全性を担保するために、売り手と買い手の間に第三者が仲介し決済を行なうものである。エスクロー決済を、ＥＣモールなどインターネット上で行なう場合、サービス提供者である第三者が提供するＥＣサイトを介して、商品の販売者が商品の出品登録を行ない、商品の購入希望者（以下、「購入者」という）が商品の購入申請と共に、クレジットカードなどにより入金手続きを行なう。サービス提供者は、購入者からの入金を確認すると（確認作業）、購入者に商品を納品すると共に（納品作業）、販売者に代金を支払う（支払作業）。
【０００３】
一方で、取引の信頼性を第三者に担保させることにより取引データの改ざんが困難であるブロックチェーン（以下「ＢＣ」という）は、その安全性の高さから、商取引での利用が活発化している。特に、ＢＣの応用技術として注目されているスマートコントラクトは、一連の処理をプログラム化し、特定の条件を満たすと一連の処理を滞りなく自動的に実行するというプログラムである（このプログラムはＢＣ上で公開および管理されるため改ざんが困難である）。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ＥＣサイトにおけるエスクロー決済では、サービス提供者の各作業が独立しており、必ずしも安全性や信頼性が高いものとはいえない。例えば、購入者が入金しても、サービス提供者の各作業に対して遅延や忘却が発生し、購入者に商品が届かなかったり、販売者への代金の支払い正しく行なわれなかったりといった問題が発生する可能性がある。また、サービス提供者による商品や代金の盗難が発生しないとも言い切れない。
【０００５】
そこで、エスクロー決済の一連の処理を、スマートコントラクトを用いて構築することにより、取引の安全性および信頼性を担保することができる見込みがある。例えば、購入者の入金を特定の条件とし、これを満たすことをトリガに、納品処理および支払処理を自動的に実行するようにスマートコントラクトを構成する。この場合、購入者の入金から、納品処理および支払処理が実行されるまでの間に第三者が介入できる余地はない。
【０００６】
しかしながら、このようなスマートコントラクトによるエスクロー決済の場合、購入者はＢＣ上の資産である仮想通貨（例えば、ビットコイン）を利用する必要がある。また、サービス提供者からすると、仮想通貨の交換業者がいない状況下ではサービスが成立しにくい。さらに、仮想通貨が現実の通貨と同等の価値や保証を持たない限り、結局のところ、代金の支払いは法定通貨で行なわれ、スマートコントラクトを用いるためだけに仮想通貨を使わざるを得ない状態になってくることも想定できる。
【０００７】
本発明はこのような問題に鑑みてなされたものであり、その目的とするところは、エスクロー決済における一連の処理を、スマートコントラクトを用いて構築および実行することにより、安全性および信頼性を担保した取引を行なうことにある。さらに、このようなスマートコントラクトによるエスクロー決済を、仮想通貨を用いない形で実現し、購入者などの手間を軽減させることにある。
【課題を解決するための手段】
【０００８】
本発明は、このような目的を達成するために、スマートコントラクトによるエスクロー決済を実行するシステムにおけるコンピュータであって、前記コンピュータは第１のコンピュータであって、
第２のコンピュータから、購入希望商品の支払指示データを受信し、
前記支払指示データ、および前記購入希望商品の購入希望者の口座データに少なくとも基づいて、前記購入希望商品の販売者への代金の入金が可能か否かを判定し、
前記代金への入金が可能であると判定した場合、入金が可能である旨を前記スマートコントラクトが格納された第３のコンピュータに通知し、前記スマートコントラクトは、入金が可能である旨の前記通知を受信すると、前記第３のコンピュータに前記購入希望商品の決済処理を実行させるものであり、前記決済処理は、少なくとも、前記購入希望商品の支払処理および納品処理の指示を含み、
前記購入希望商品の決済データを前記第３のコンピュータから受信し、
前記決済データに基づいて、前記購入希望者から前記販売者への前記支払処理を実行する
ように構成されたことを特徴とする。
【０００９】
また、前段落に記載の第１のコンピュータにおいて、前記支払処理の指示として、前記購入希望商品の前記決済データを前記第３のコンピュータから受信することは、前記第１のコンピュータ上のアプリケーションプログラムインターフェース（ＡＰＩ）が前記スマートコントラクトから呼び出されることにより行なわれるものであることを特徴とする。
【００１０】
さらに、前２段落に記載の第１のコンピュータは、前記支払処理の実行結果を前記第３のコンピュータに通知するようにさらに構成され、前記実行結果が失敗したことを示す場合、前記スマートコントラクトは、前記第３のコンピュータに前記納品処理の指示を実行させないことを特徴とする。
【００１１】
そして、前３段落に記載の第１のコンピュータは、前記納品処理が失敗した場合に送信される前記支払処理の取消指示を前記第３のコンピュータから受信し、
前記取消指示を受信したことに応答して、前記支払処理の取消処理を実行する
ようにさらに構成されたことを特徴とする。
【００１２】
また、前４段落に記載の第１のコンピュータは、前記代金の入金が可能であると判定した場合、前記購入希望者の口座データから、前記代金を予め引き落とすようにさらに構成されたことを特徴とする。
【００１３】
また本発明は、別の実施形態において、スマートコントラクトによるエスクロー決済を実行するシステムにおける第１のコンピュータによって実行される方法であって、前記方法は、
前記第１のコンピュータが、第２のコンピュータから、購入希望商品の支払指示データを受信するステップと、
前記第１のコンピュータが、前記支払指示データ、および前記購入希望商品の購入希望者の口座データに少なくとも基づいて、前記購入希望商品の販売者への代金の入金が可能か否かを判定するステップと、
前記代金への入金が可能であると判定した場合、前記第１のコンピュータが、入金が可能である旨を前記スマートコントラクトが格納された第３のコンピュータに通知するステップであって、前記スマートコントラクトは、入金が可能である旨の前記通知を受信すると、前記第３のコンピュータに前記購入希望商品の決済処理を実行させるものであり、前記決済処理は、少なくとも、前記購入希望商品の支払処理および納品処理の指示を含む、ステップと、
前記第１のコンピュータが、前記購入希望商品の決済データを前記第３のコンピュータから受信するステップと、
前記第１のコンピュータが、前記決済データに基づいて、前記購入希望者から前記販売者への前記支払処理を実行するステップと
を備えたことを特徴とする。
【００１４】
さらに本発明は、さらに別の実施形態において、スマートコントラクトによるエスクロー決済を実行するシステムにおける第１のコンピュータに実行させるコンピュータプログラムであって、前記コンピュータプログラムは前記第１のコンピュータによって実行されると、
第２のコンピュータから、購入希望商品の支払指示データを受信するステップと、
前記支払指示データ、および前記購入希望商品の購入希望者の口座データに少なくとも基づいて、前記購入希望商品の販売者への代金の入金が可能か否かを判定するステップと、
前記代金への入金が可能であると判定した場合、入金が可能である旨を前記スマートコントラクトが格納された第３のコンピュータに通知するステップであって、前記スマートコントラクトは、入金が可能である旨の前記通知を受信すると、前記第３のコンピュータに前記購入希望商品の決済処理を実行させるものであり、前記決済処理は、少なくとも、前記購入希望商品の支払処理および納品処理の指示を含む、ステップと、
前記購入希望商品の決済データを前記第３のコンピュータから受信するステップと、
前記決済データに基づいて、前記購入希望者から前記販売者への前記支払処理を実行するステップと
を前記第１のコンピュータに実行させることを特徴とする。
【００１５】
また本発明は、さらに別の実施形態において、スマートコントラクトによるエスクロー決済を実行するシステムにおけるコンピュータであって、前記コンピュータは、第１のコンピュータであって、前記スマートコントラクトが格納され、前記スマートコントラクトに、
購入希望商品の販売者への代金の入金が可能である旨の通知を第２のコンピュータから受信させ、前記通知は、前記第２のコンピュータが購入希望商品の支払指示データを第３のコンピュータから受信したことに応答して、前記支払指示データ、および前記購入希望商品の購入希望者の口座データに少なくとも基づいて、前記購入希望商品の販売者への代金の入金が可能か否かを判定し、前記代金への入金が可能であると判定した場合に通知され、
入金が可能である旨の前記通知を受信すると、前記購入希望商品の決済データを作成させ、
前記第２のコンピュータに前記購入希望商品の決済処理を実行させるために、前記作成した決済データを前記第２のコンピュータに送信させ、前記決済処理は、少なくとも、前記購入希望商品の支払処理および納品処理の指示を含み、
前記決済処理の実行結果を前記第２のコンピュータから受信させ、
前記支払処理が成功したか否かを判定させ、
前記支払処理が成功したと判定した場合に、前記納品処理を実行させることを特徴とする。
【発明の効果】
【００１６】
以上説明したように、本発明によれば、エスクロー決済における一連の処理を、スマートコントラクトを用いて構築および実行することにより、安全性および信頼性を担保した取引を行なうことができる。さらに、このようなスマートコントラクトによるエスクロー決済を、仮想通貨を用いない形で実現し、購入者などの手間を軽減させることができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に係るシステムの全体構成を示す図である。
【図２】本発明の一実施形態に係るシステムの金融機関サーバの構成を示す図である。
【図３】本発明の一実施形態に係るエスクロー決済処理を示すフローチャートである。
【図４】本発明の一実施形態に係るスマートコントラクト上で管理される商品データを示す図である。
【図５】本発明の一実施形態に係る支払指示データ記憶部に格納されたデータを示す図である。
【図６】本発明の一実施形態に係る口座データ記憶部に格納されたデータを示す図である。
【図７】本発明の一実施形態に係る入金可能通知データ記憶部に格納されたデータを示す図である。
【図８】本発明の一実施形態に係る決済データ記憶部に格納されたデータを示す図である。
【発明を実施するための形態】
【００１８】
以下、添付した図面を参照して、本発明の実施形態に係るシステムを詳細に説明する。図１は、本発明の一実施形態に係るシステムの全体構成を示す図である。図１において、金融機関が管理する金融機関サーバ１００は、データセンタなどに設置される。ＥＣサイトサーバ１０４は、ＥＣモールなどのＥＣサイトサービスを提供する運営会社（以下、「サービス提供者」という）が管理するコンピュータである。ＥＣサイトサーバ１０４は、ネットワーク１０３（例えば、インターネット）を介して、ＥＣサイトを利用する購入者および販売者がそれぞれ利用する購入者端末１０１および販売者端末１０２と通信を行なうように構成される。なお、サービス提供者を介さない購入者と販売者との個人間取引の場合、ＥＣサイトサーバ１０４は不要である。また、金融機関サーバ１００も、ネットワーク１０３を介して、購入者端末１０１などと通信を行なうように構成される。
【００１９】
ＥＣサイトサーバ１０４は、サービス提供者によって管理され、ＥＣサイトサービスを提供する。ＥＣサイトサーバ１０４は、エスクロー決済を行なうためのスマートコントラクト１０５を格納する。なお、スマートコントラクト１０５は、ブロックチェーンネットワーク（以下、「ＢＣ−ＮＷ」という）に参加しているＢＣユーザ端末上で稼動するプログラムであり、必ずしもＥＣサイトサーバ１０４で稼動する必要はない（特に、サービス提供者を介さない購入者と販売者との個人間取引や、サービス提供者が存在しないＥＣサイトも想定される）。すなわち、ＥＣサイトサーバ１０４は、本発明において必須構成ではなく、サーバコンピュータである必要もない。しかしながら、安定したＥＣサイトサービスを提供する場合は、サービス提供者が管理するサーバコンピュータを用いる方がよく、以下に詳述する実施形態では、ＥＣサイトサーバ１０４上のスマートコントラクト１０５を実行することによりＥＣサイトサービスを提供することを想定して記載している。
【００２０】
購入者端末１０１および販売者端末１０２はそれぞれ、ＥＣサイトを利用する購入者および販売者が利用する端末であり、ＢＣ−ＮＷに参加している。そのため、図１では示していないが、購入者端末１０１および販売者端末１０２上でもスマートコントラクト１０５を稼動させることができる。販売者は、販売者端末１０２を介して、ＥＣサイトサーバ１０４が提供するＥＣサイトに商品を出品登録する。ただし、別の実施形態では、購入者端末１０１および／または販売者端末１０２は、ＢＣ−ＮＷに参加していなくてもよい（少なくとも出品登録された商品のデータがスマートコントラクト１０５上に連携されればよい）。購入者は、購入者端末１０１を介して、ＥＣサイトに出品された各商品を閲覧する。購入者は購入を希望する商品がある場合、購入者端末１０１を介して、金融機関サーバ１００に対し、希望商品の支払を指示する。
【００２１】
金融機関サーバ１００は、金融機関によって管理され、ＢＣ−ＮＷには参加していない。金融機関サーバ１００は、購入者端末１０１から希望商品の支払指示を受信すると、購入者の口座を確認し、販売者への入金が可能か否かを判定する。入金が可能であると判定した場合、金融機関サーバ１００は、スマートコントラクト１０５にその旨を通知し、決済処理（支払処理および納品処理）を実行させる。なお、決済処理における支払処理（購入者の口座から販売者の口座への資金移動）は金融機関サーバ１００で行なわれる。そのため、スマートコントラクト１０５は金融機関サーバ１００上の支払処理用のアプリケーションプログラムインターフェース（ＡＰＩ）を呼び出し、金融機関サーバ１００は支払処理の実行後、実行結果をスマートコントラクト１０５に返す（通知する）。
【００２２】
次に、金融機関サーバ１００の構成を詳細に説明する。図２は、本発明の一実施形態に係るシステムの金融機関サーバの構成を示す図である。なお、図２では、単一のサーバコンピューティングシステムを想定しているが、別の実施形態では、各処理部を複数台のサーバコンピュータに分散するように構成するなど、分散型コンピューティングシステムとして構成することもできる。金融機関サーバ１００は、システムバス１１５を介して相互に接続された、ＣＰＵ１１０、ＲＡＭ１１１、入力装置１１２、出力装置１１３、通信制御装置１１４、および記憶装置１１６を備えている。記憶装置１１６は不揮発性記憶媒体（ＲＯＭやＨＤＤなど）で構成され、ソフトウェアプログラムを格納したプログラム格納領域と、当該ソフトウェアプログラムで取り扱うデータを格納したデータ格納領域とを備えている。後述するプログラム格納領域の各処理部は、実際は独立したソフトウェアプログラム、そのルーチンやコンポーネントなどであり、記憶装置１１６に格納されている。各処理部は、実行時にＣＰＵ１１０によって記憶装置１１６から呼び出されＲＡＭ１１１のワークエリアに展開されることで、データベースなどに適宜アクセスしながら各機能を発揮することができる。
【００２３】
図２の記憶装置１１６におけるプログラム格納領域に格納されたソフトウェアプログラムは、本発明に関連するものだけを列挙すると、入金可否判定処理部１２０、および支払処理部１２１を備えている。これらの処理部は、ＣＰＵ１１０によって実行される。
【００２４】
図２の記憶装置１１６におけるデータ格納領域は、本発明に関連するものだけを列挙すると、支払指示データ記憶部１３０、口座データ記憶部１３１、入金可能通知データ記憶部１３２、および決済データ記憶部１３３を備える。いずれも、記憶装置１１６内に確保された一定の記憶領域である。
【００２５】
次に、図２の記憶装置１１６に格納された各処理部の機能について説明する。図２の入金可否判定処理部１２０は、購入者端末１０１から希望商品の支払指示を示す支払指示データを受信し、支払指示データ記憶部１３０に格納する。また、入金可否判定処理部１２０は、受信した支払指示データに基づいて口座データ記憶部１３１に格納された購入者の口座データを検索し、購入者から販売者への入金が可能か否かを判定する。入金が可能であると判定された場合、入金可否判定処理部１２０は、入金可能である旨を示す入金可能通知データを作成し、入金可能通知データ記憶部１３２に格納する。また、入金可否判定処理部１２０は、作成した入金可能通知データをスマートコントラクト１０５に送信する。入金可能通知データを受信したスマートコントラクト１０５は、決済データを作成し、金融機関サーバ１００の支払処理部１２１に支払処理の実行を指示する（金融機関サーバ１００上の支払処理用のＡＰＩを実行する）。
【００２６】
図２の支払処理部１２１は、支払処理の実行を指示するための決済データをスマートコントラクト１０５から受信し、決済データ記憶部１３３に格納する。また、支払処理部１２１は、受信した決済データに基づいて、口座データ記憶部１３１に格納された購入者の口座データから、販売者の口座データへの資金移動（支払処理）を実行する。また、支払処理部１２１は、スマートコントラクト１０５に支払処理の実行結果を通知する。実行結果を受信したスマートコントラクト１０５は、支払処理が成功した場合、納品処理を実行する。
【００２７】
次に、図２の記憶装置１１６の各記憶部に記憶されたデータについて説明する。図２の支払指示データ記憶部１３０は、購入希望商品の支払指示に関するデータを格納する。図５は、本発明の一実施形態に係る支払指示データ記憶部１３０に格納された支払指示データを示す図である。
【００２８】
図５における支払指示データには、購入希望商品を一意に示す「商品ＩＤ」、ＢＣ上の購入者を一意に示す「購入者アドレス」、および購入者の口座を一意に示す「購入者口座」などを格納することができる。
【００２９】
図５における支払指示データは、ＥＣサイトを閲覧した購入者により購入者端末１０１を介して作成されるトランザクションデータである。図５における「商品ＩＤ」は、後述するスマートコントラクト１０５上の商品データ（図４）における「商品ＩＤ」であり、これにより、支払指示データと、商品データとを紐付けることができる。「購入者口座」は、図５の例では、後述する口座データ（図６）の「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」を結合した値を設定しており、これにより購入者の口座を一意に示すことができる。
【００３０】
図２の口座データ記憶部１３１は、金融機関における契約顧客の口座データを格納する。本実施形態における契約顧客は、ＥＣサイトを利用する購入者および販売者に加え、サービス提供者も含む。サービス提供者の口座に対し手数料が支払われる場合があるためである。図６は、本発明の一実施形態に係る口座データ記憶部１３１に格納された口座データを示す図である。
【００３１】
図６における口座データには、契約口座の提供元である金融機関を一意に示す「金融機関コード」およびその名称を示す「金融機関名」、当該金融機関の支店を一意に示す「支店コード」およびその名称を示す「支店名」、契約口座の口座種別（科目）を示す「口座種別」、契約口座の口座番号を示す「口座番号」、契約口座の口座名義を示す「口座名義」、ならびに契約口座の現在の預金額を示す「預金額」などを格納することができる。
【００３２】
図６における口座データは、契約顧客の口座開設時に金融機関によって登録されるマスタデータである。契約口座は、「金融機関コード」、「支店コード」、「口座種別」、および「口座番号」によって一意に識別される。「口座種別」には、口座種別を示す数値（例えば、１：普通預金、２：当座預金・・・）を設定することができる。また、図６における口座データは、実口座を想定して記載されているが、別の実施形態では、仮想口座により本発明を実現することもできる。
【００３３】
図２の入金可能通知データ記憶部１３２は、購入者から販売者への入金が可能な購入希望商品に関するデータを格納する。図７は、本発明の一実施形態に係る入金可能通知データ記憶部１３２に格納された入金可能通知データを示す図である。
【００３４】
図７における入金可能通知データには、入金が可能な購入希望商品を一意に示す「商品ＩＤ」、ＢＣ上の購入者を一意に示す「購入者アドレス」、購入者の口座を一意に示す「購入者口座」、ＢＣ上の販売者を一意に示す「販売者アドレス」、販売者の口座を一意に示す「販売者口座」、ならびに購入希望商品の価格および手数料をそれぞれ示す「商品価格」および「手数料」などを格納することができる。
【００３５】
図７における入金可能通知データは、販売者への代金の入金が可能と判定された場合に金融機関サーバ１００によって作成されるトランザクションデータである。図７における「商品ＩＤ」にも、後述する商品データ（図４）における「商品ＩＤ」を設定し、入金可能通知データと、スマートコントラクト１０５上の商品データとを紐付けることができる。「購入者口座」および「販売者口座」は、支払指示データ（図５）における「購入者口座」と同様である。「手数料」は、サービス提供者が存在する場合にサービス提供者に支払われるものである。そのため、サービス提供者への手数料が発生する場合の入金可否判定は、「商品価格」＋「手数料」の合計金額が「購入者口座」の預金額内であるか否かを判定する。
【００３６】
図２の決済データ記憶部１３３は、入金可能と判定された購入希望商品の決済に関するデータを格納する。図８は、本発明の一実施形態に係る決済データ記憶部１３３に格納された決済データを示す図である。
【００３７】
図８における決済データには、決済対象の購入希望商品を一意に示す「商品ＩＤ」、購入者、販売者、およびサービス提供者の口座をそれぞれ一意に示す「購入者口座」、「販売者口座」、および「提供者口座」、ならびに決済対象商品の価格および手数料をそれぞれ示す「商品価格」および「手数料」などを格納することができる。
【００３８】
図８における決済データは、購入希望商品に対する入金可能通知を受信した場合にスマートコントラクト１０５によって作成されるトランザクションデータである。「購入者口座」、「販売者口座」および「提供者口座」は、支払指示データ（図５）における「購入者口座」と同様である。決済データに基づく支払処理により、「商品価格」＋「手数料」の合計金額が購入者口座から引き落とされ、「商品価格」の金額は「販売者口座」、「手数料」の金額は「提供者口座」にそれぞれ入金される。
【００３９】
次に、スマートコントラクト１０５上に連携される商品データについて説明する。商品データは、ＥＣサイトに対し販売者が出品登録した商品に関するデータである。図４は、本発明の一実施形態に係るスマートコントラクト上の商品データを示す図である。
【００４０】
図４における商品データには、出品登録された商品を一意に示す「商品ＩＤ」、商品の名称を示す「商品名」、ＢＣ上の出品した販売者を一意に示す「販売者アドレス」、出品された商品の価格を示す「商品価格」、および出品した販売者の口座を一意に示す「販売者口座」などを格納することができる。
【００４１】
図４における商品データは、販売者が販売者端末１０２を介して商品を出品登録する度にスマートコントラクト１０５に作成されるマスタデータである。図４における「販売者口座」は、支払指示データ（図５）における「購入者口座」と同様である。「販売者口座」および「販売者アドレス」を関連付けて記憶することにより、ＢＣ上の販売者と金融機関における口座を紐付けることができる。しかしながら、スマートコントラクト１０５上には「販売者口座」を連携せず、金融機関サーバ１００上で「販売者口座」と「販売者アドレス」とのマッピングデータ（図示せず）を記憶することもできる。この場合は、図４における商品データには「販売者口座」は含まれない。
【００４２】
次に、図３のフローチャート、図４−８のデータを参照して、本発明の一実施形態に係るエスクロー決済処理を流れに沿って説明する。図３は、本発明の一実施形態に係るエスクロー決済処理を示すフロー図である。本処理は、販売者がＥＣサイトに商品を出品登録し、出品された商品の購入を希望する購入希望者が金融機関に対し支払指示を行ない、販売者への代金の入金可否判定を行なった後、スマートコントラクトにより決済処理（支払処理および納品処理）が行なわれるものである。
【００４３】
まず、販売者は、販売者端末１０２を介して、ＥＣサイトに出品したい商品の商品データ（図４）を登録し、スマートコントラクト１０５は商品データを受信する（ステップＳ３００）。販売者端末１０２は、ＢＣ−ＮＷに参加しており、販売者端末１０２とスマートコントラクト１０５とのやり取りはＢＣ−ＮＷ上で行なわれる。しかしながら、別の実施形態では、販売者端末１０２は、ＢＣ−ＮＷに参加していなくてもよい（この場合であっても、例えば、ＥＣサイトサーバ１０４を介して、出品登録された商品のデータがスマートコントラクト１０５上に連携される）。商品データには、出品登録する商品のデータのみならず、ＢＣ上の販売者を示す販売者アドレスや、商品の代金が入金される販売者の口座データを含めることができる。これにより、ＢＣ上の販売者と金融機関における口座とを関連付けることができる。なお、図４の商品データは、様々な販売者が出品登録した商品群を示している。そのため、ステップＳ３００で受信される商品データは、少なくとも販売者単位のデータとなる。
【００４４】
次に、購入者は、購入者端末１０１を介してＥＣサイトにアクセスし、出品登録された商品群を閲覧する。購入を希望する商品が見つかった場合、購入者は、購入者端末１０１を介して金融機関に対して購入希望商品の支払を指示する。その後、金融機関サーバ１００の入金可否判定処理部１２０は、支払指示データ（図５）を受信し（ステップＳ３０１）、支払指示データ記憶部１３０に格納する（ステップＳ３０２）。購入者端末１０１と入金可否判定処理部１２０とのやり取りは、購入者端末１０１の出力装置（画面）に表示されたＥＣサイトを介して、支払指示データをパラメータや引数として入金可否判定処理部１２０に渡すことにより行なわれる。なお、別の実施形態では、スマートコントラクト１０５を介して入金可否判定処理部１２０に支払指示データが送信されてもよい。この場合、スマートコントラクト１０５は、受信した支払指示データと共に商品データ（図４）を入金可否判定処理部１２０に送信することにより、後述するステップＳ３０３における商品データの取得をステップＳ３０１と同時に行なうことができる。
【００４５】
入金可否判定処理部１２０は、支払指示データ（図５）を受信すると、支払指示データにおける「商品ＩＤ」を検索キーとして、スマートコントラクト１０５上の商品データ（図４）を取得する（ステップＳ３０３）。
【００４６】
次に、入金可否判定処理部１２０は、ステップＳ３０１で受信した支払指示データ（図５）と、ステップＳ３０３で取得した商品データ（図４）とに基づいて、購入者の口座データ（図６）を確認し、販売者への代金の入金が可能か否かを判定する（ステップＳ３０４）。具体的には、支払指示データ（図５）における「購入者口座」を検索キーとして、口座データ記憶部１３１に格納された口座データ（図６）を検索し、購入者口座の「預金額」を取得する。取得した預金額と、商品データ（図４）における「商品価格」とを比較し、預金額が商品価格以上であれば、入金可能と判定する。なお、この際、各種手数料（例えば、サービス提供者や、金融機関に対する手数料）を考慮する必要がある場合は、預金額が商品価格＋手数料以上であるか否かを判定する。
【００４７】
ステップＳ３０４にて入金不可であると判定した場合、ステップＳ３０５のＮｏルートに進み、入金可否判定処理部１２０は、入金不可である旨を購入者に通知する（ステップＳ３０８）。具体的には、例えば、ＥＣサイト上での通知や、購入者が指定したアドレスへのメール通知などが考えられる。ステップＳ３０８の後、本処理は終了する。
【００４８】
一方、ステップＳ３０４にて入金可能であると判定した場合、ステップＳ３０５のＹｅｓルートに進み、入金可否判定処理部１２０は、スマートコントラクト１０５に通知するための入金可能通知データ（図７）を作成し、入金可能通知データ記憶部１３２に格納する（ステップＳ３０６）。なお、入金可能である場合、購入者口座の預金額から予め商品価格（手数料含む）を引き落としておき、金融機関で代金を確保しておくこともできる。これは、入金可能であると判定してから支払処理を行なうまでの間に別トランザクションによる引落しが行なわれ、入金不可となってしまうことを防ぐためである。
【００４９】
次に、入金可否判定処理部１２０は、ステップＳ３０６で作成した入金可能通知データ（図７）を送信することにより、入金可能である旨をスマートコントラクト１０５に通知する（ステップＳ３０７）。入金可能通知データには、入金可能と判定された商品の代金や、購入者および販売者の口座データが含まれる。
【００５０】
スマートコントラクト１０５は、入金可能通知データを受信すると（ステップＳ３０９）、入金可能通知データに基づいて、支払処理を実行するための決済データ（図８）を作成する（ステップＳ３１０）。決済データには、支払処理の対象となる商品の代金や、購入者および販売者の口座データに加え、サービス提供者への手数料の支払いも行なう場合にはサービス提供者の口座データが含まれる。
【００５１】
次に、スマートコントラクト１０５は、ステップＳ３１０で作成した決済データ（図８）を送信することにより、支払処理の実行を支払処理部１２１に指示する（ステップＳ３１１）。具体的には、例えば、スマートコントラクト１０５が金融機関サーバ１００上の支払処理用のＡＰＩを呼び出す。
【００５２】
次に、支払処理部１２１は、決済データを受信し（ステップＳ３１２）、決済データ記憶部１３３に格納する（ステップＳ３１３）。
【００５３】
次に、支払処理部１２１は、受信した決済データ（図８）に基づいて、口座データ記憶部１３１に格納された口座データ（図６）に対して支払処理を実行する（ステップＳ３１４）。具体的には、決済データの「購入者口座」に紐付けられる口座データの「預金額」から決済データの「商品価格」＋「手数料」の合計金額が引き落とされ、「商品価格」の金額は「販売者口座」、「手数料」の金額は「提供者口座」にそれぞれ入金される。なお、購入者口座、販売者口座、または提供者口座が異なる金融機関に係るものである場合は、でんさいネットなどを介して、異なる金融機関の口座間での資金移動が行なわれる。また、ステップＳ３０６部分の説明において記載したように、購入者口座の預金額から予め商品価格（手数料含む）を引き落としている場合は、本ステップで再度の引き落としは行なわれない。
【００５４】
次に、支払処理部１２１は、支払処理の実行結果をスマートコントラクト１０５に通知する（ステップＳ３１５）。具体的には、ステップＳ３１１にて呼び出されたＡＰＩの戻り値として実行結果を、スマートコントラクト１０５に戻す。
【００５５】
スマートコントラクト１０５は、実行結果を受信すると（ステップＳ３１６）、受信した実行結果に基づいて、支払処理が成功したか否かを判定する（ステップＳ３１７）。支払処理が失敗したと判定した場合、ステップＳ３１８のＮｏルートに進み、スマートコントラクト１０５は、エラー処理を実行する（ステップＳ３２１）。ここでのエラー処理は、例えば、管理者端末（図示せず）へのエラー通知である。ステップＳ３２１の後、本処理は終了する。
【００５６】
一方、支払処理が成功したと判定した場合、ステップＳ３１８のＹｅｓルートに進み、スマートコントラクト１０５は、納品処理を実行する（ステップＳ３１９）。納品処理とは、例えば、運送会社に対する商品の発送指示である。納品処理が失敗した場合、ステップＳ３２０のＮｏルートに進み、スマートコントラクト１０５は、エラー処理を実行する（ステップＳ３２１）。ここでのエラー処理は、管理者端末へのエラー通知に加え、支払処理部１２１に対する支払処理の取消指示である。支払処理部１２１は取消指示を受信すると、支払処理の取消処理として、例えば、販売者の口座から代金を引き落とし、金融機関が代金を保持する。これにより、納品処理をリトライするなどし、納品処理が成功した後、改めて販売者の口座に入金を行なうことができる。また、別の実施形態では、支払処理の前に納品処理を実行し、納品処理が成功した場合に支払処理を実行することもできる。
【００５７】
ステップＳ３１９における納品処理が成功した場合は、ステップＳ３２０のＹｅｓルートに進み、本処理は終了する。この際、スマートコントラクト１０５は、商品の発送完了の旨を購入者に通知すること（例えば、ＥＣサイト上での通知や、購入者指定アドレスへのメール通知）もできる。
【００５８】
以上により、本発明によれば、エスクロー決済における一連の処理を、スマートコントラクトを用いて構築および実行することにより、安全性および信頼性を担保した取引を行なうことができる。さらに、このようなスマートコントラクトによるエスクロー決済を、仮想通貨を用いない形で実現し、購入者などの手間を軽減させることができる。
【図１】
2018139068.tif 000003
【図２】
2018139068.tif 000004
【図３】
2018139068.tif 000005
【図４】
2018139068.tif 000006
【図５】
2018139068.tif 000007
【図６】
2018139068.tif 000008
【図７】
2018139068.tif 000009
【図８】
2018139068.tif 000010