JP2020080085A - 決済システム及び決済方法 - Google Patents

Abstract

【課題】分散台帳による情報共有技術と、情報の正当性を確認できる基盤システムとを利用して、効率的な決済を支援するための決済システム及び決済方法を提供する。【解決手段】支払人システム１０が、取引の契約に基づいて振出情報を分散台帳Ｄ１に登録し、支払人口座が開設された金融機関システム３０が、振出情報について、承認情報を分散台帳Ｄ１に登録する。受取人口座が開設された金融機関システム４０が、振出情報の入金条件を充足する情報を分散台帳Ｄ１において確認し、入金条件の充足に基づいて、受取人口座に、振出情報に基づいて入金を行ない、振出情報についての取引完了情報を分散台帳Ｄ１に記録する。【選択図】図１

Description

本発明は、取引の決済を行なうための決済システム及び決済方法に関する。

ピア・ツー・ピア・ネットワークを活用したブロックチェーン技術が決済等に利用されつつある（例えば、非特許文献１参照）。非特許文献１に記載された技術では、ブロックチェーンを活用して、大規模な決済システムを新規に構築することなく、約定情報を改ざん不可能なデータとして瞬時に共有・決済できる仕組みが検討されている。このブロックチェーン技術では、順序付けられたレコードを、分散台帳で連続的に管理することにより、ブロック内のデータの遡及的な変更を防止する。

また、オンライン取引において利用されている仮想通貨の改ざんを防止するために、ブロックチェーン技術が利用される場合もある（例えば、特許文献１参照）。この技術では、約定情報に基づく残高情報をブロックチェーンで繋げたまとまりとして分散台帳に記録する。

また、複数のコンピューティングノードを含む分散型ブロックチェーン・コンピューティングシステムを用いて取引を支援する技術も検討されている（例えば、特許文献２参照）。この技術では、取引所は、注文書と、異なるクライアントに関連する複数のデジタルウォレットを格納する。コンピュータシステムは、注文書に追加される新たなデータ取引要求を受け取る。データ取引要求の間のマッチが識別され、個別のデータ取引要求に関連するデジタルウォレットに関連するハッシュが生成される。取引相手は、相手方のハッシュを、マッチに関する情報とともに受け取り、各当事者は、ブロックチェーン取引をブロックチェーンに追加させる。両方のマッチがブロックチェーンに追加されたかどうかを判断するためにブロックチェーンをモニタする。

また、分散型台帳技術を用いて、債務記録情報の正当性を確認できる基盤システムを利用して、支払を支援するための支払支援システム及び支払支援方法も検討されている（例えば、特許文献３参照）。この技術では、支払人端末及び支払人金融機関サーバに接続され、ブロックチェーン等の分散型台帳技術により情報の正当性を確認できる基盤システムを用いる。支払人端末は、債務者から債権者に対する支払方式の選択情報を取得し、選択された支払方式の債務記録情報を分散台帳に記録し、選択された支払方式に応じた支払人金融機関サーバに債務記録情報の発行を通知する。支払人金融機関サーバは、分散台帳を確認し、債務記録情報の承認情報を分散台帳に記録し、支払方式に基づいて、債権者に対する支払処理を行ない、債務記録情報の失効情報を分散台帳に記録する。

特開２０１６−１５１８０２号公報 特表２０１８−５１５８３３号公報 特許第６３６３２５４号公報

株式会社みずほ銀行、「国境を越えた証券取引の決済プロセス効率化に向けた実証実験を実施」、平成２８年３月８日、［online］、株式会社みずほ銀行、［平成３０年９月９日検索］、インターネット＜https://www.mizuhobank.co.jp/release/pdf/20160308release_jp.pdf＞

例えば、ネット取引においては、商品の提供と支払のタイミングが一致するとは限らない。そこで、支払のための資金を第三者が確保し、所定の条件に基づいて、その資金を相手方に支払うエスクローサービスが利用されることもある。しかしながら、支払者、受取人、第三者との間での情報共有を効率的にできなければ、手続が煩雑となる。

上記課題を解決する決済システムでは、取引における支払人の支払人システムと、取引を行なった支払人及び受取人の支払人口座及び受取人口座が開設された金融機関システムとが、分散台帳により情報の正当性を確認できる基盤システムを介して接続された決済システムを用いる。そして、前記支払人システムが、前記取引の契約に基づいて振出情報を前記分散台帳に登録し、前記支払人口座が開設された金融機関システムが、前記振出情報についての承認情報を前記分散台帳に登録し、前記受取人口座が開設された金融機関システムが、前記振出情報の入金条件を充足する情報を前記分散台帳において確認し、前記入金条件の充足に基づいて、前記受取人口座に、前記振出情報に基づいて入金処理を実行し、前記支払人口座が開設された金融機関システムが、前記振出情報についての取引完了情報を前記分散台帳に記録する。

本発明によれば、分散台帳による情報共有技術と、情報の正当性を確認できる基盤システムとを利用して、効率的な決済を支援することができる。

本実施形態のシステム概略図。 ハードウェア構成例の説明図。 本実施形態の各システムの説明図であって、（ａ）は支払人システム、（ｂ）は受取人システム、（ｃ）は金融機関システムの説明図。 本実施形態で分散台帳に記録される情報の説明図であって、（ａ）は振出情報、（ｂ）は承認情報、（ｃ）は入金情報、（ｄ）は決済完了情報、（ｅ）は失効情報の説明図。 本実施形態の処理手順の説明図。 他の実施形態のシステム概略図。 他の実施形態で分散台帳に記録される情報の説明図。 他の実施形態の処理手順の説明図。

（第１の実施形態）
以下、図１〜図５を用いて、決済システム及び決済方法を具体化した一実施形態を説明する。本実施形態では、支払人と受取人との間で取引を行ない、この取引についての決済を支援する。例えば、支払人は取引対象物（商品）の購入者であり、受取人は、この商品の販売者である。

図１に示すように、本実施形態では、分散台帳Ｄ１に接続された支払人システム１０、受取人システム２０、金融機関システム３０，４０を用いる。本実施形態では、ブロックチェーンにより取引決済情報の記録の正当性を確認できる基盤システムを用いて、決済を支援する場合を想定する。なお、ネットワークに接続された複数のノードで同じデータを保持し合う分散台帳Ｄ１（分散型台帳）を用いるものであれば、ブロックチェーン技術を用いる場合に限定されるものではない。そして、取引決済情報は、金融機関の決済に関する情報を電子的に記録するものであり、取引決済情報は分散台帳Ｄ１に記録され、ブロックチェーン技術により固定化される。更に、所謂仮想通貨とは異なり、この記録自体では決済は完了せず、単に振出〜決済に関する情報が記録されるだけである。本実施形態では、取引決済情報に関わる関係者間で契約に基づき、承認又は定められた方法で初めて決済が完了する（債権債務関係の成立）。

支払人システム１０〜金融機関システム４０は、ピア・ツー・ピア（Peer to Peer）のネットワークで接続されている。このピア・ツー・ピアは、多数のシステム間で通信を行なうためのアーキテクチャのひとつであり、ピア同士が通信を行なう通信方式の基盤システムである。例えば、情報の改ざんを防止するために、ブロックチェーン方式を用いることができる。ブロックチェーン方式では、「取引の記録」をまとめた「ブロック」を「チェーン」状に順次追加していく。ブロックチェーンを構成するそれぞれのブロックは、そのブロックと一つ前のブロックに関する情報を含む「ヘッダ」と、ある時間内に行なわれた取引のリストを記録した「トランザクション」とにより構成される。ブロックチェーンにおいては、過去からの全取引記録が記録されているため、仮に不正を行なおうとした場合、不正以降の全ブロックを書き換える必要があり、計算負荷が大きく改ざんを困難にしている。そして、ピア・ツー・ピアネットワークに接続されている各システムは、一つのピアが発信した情報を、それぞれで分散して共有することになる。

そして、支払人システム１０〜金融機関システム４０は、それぞれ、ピア・ツー・ピアネットワークにおいて共有する情報を保存する分散台帳Ｄ１を保持する。一つのシステムの分散台帳Ｄ１に、所定の情報が書き込まれた場合、ピア・ツー・ピアネットワークにより、他のすべてのシステムが保有する分散台帳Ｄ１に、同じ分散情報が書き込まれる。

（ハードウェア構成例）
図２は、支払人システム１０〜金融機関システム４０等として機能する情報処理装置Ｈ１０のハードウェア構成例である。

情報処理装置Ｈ１０は、通信装置Ｈ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶部Ｈ１４、プロセッサＨ１５を有する。なお、このハードウェア構成は一例であり、他のハードウェアを有していてもよい。

通信装置Ｈ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。

入力装置Ｈ１２は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置Ｈ１３は、各種情報を表示するディスプレイやタッチパネル等である。

記憶部Ｈ１４は、支払人システム１０〜金融機関システム４０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置（例えば、後述する情報記憶部Ｍ２）である。例えば、記憶部Ｈ１４は、情報記憶部Ｍ２に示した情報を記憶する。記憶部Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。

プロセッサＨ１５は、記憶部Ｈ１４に記憶されるプログラムやデータを用いて、支払人システム１０〜金融機関システム４０における各処理（例えば、後述する台帳管理部Ｍ１における処理）を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各種処理に対応する各種プロセスを実行する。例えば、プロセッサＨ１５は、支払人システム１０〜金融機関システム４０のアプリケーションプログラムが起動された場合、後述する図５に示す各処理を実行するプロセスを動作させる。

プロセッサＨ１５は、自身が実行するすべての処理についてソフトウェア処理を行うものに限られない。例えば、プロセッサＨ１５は、自身が実行する処理の少なくとも一部についてハードウェア処理を行う専用のハードウェア回路（例えば、特定用途向け集積回路：ＡＳＩＣ）を備えてもよい。すなわち、プロセッサＨ１５は、（１）コンピュータプログラム（ソフトウェア）に従って動作する１つ以上のプロセッサ、（２）各種処理のうち少なくとも一部の処理を実行する１つ以上の専用のハードウェア回路、或いは（３）それらの組み合わせ、を含む回路（circuitry）として構成し得る。プロセッサは、ＣＰＵ並びに、ＲＡＭ及びＲＯＭ等のメモリを含み、メモリは、処理をＣＰＵに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。

（各情報処理装置の機能）
図３に示すように、支払人システム１０、受取人システム２０、金融機関システム３０、４０は、それぞれ、台帳管理部Ｍ１、情報記憶部Ｍ２を備える。台帳管理部Ｍ１は、自システムの情報記憶部Ｍ２に書き込まれた情報を、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に書き込む。

図３（ａ）に示す支払人システム１０は、支払人（商品の購入者）が用いるコンピュータシステムである。支払人システム１０は、制御部１１を備える。制御部１１は、支払人の入力に応じて、振出情報を生成し、分散台帳Ｄ１に記録する。

図３（ｂ）に示す受取人システム２０は、支払人との間で取引を行なう商品販売者のコンピュータシステムである。この受取人システム２０は、取引管理部２１、取引情報記憶部２２を備える。
取引管理部２１は、支払人との取引を管理する処理を行なう。

取引情報記憶部２２には、支払人との取引について取引管理情報が記録される。この取引管理情報には、取引コード、取引日時、購入者、取引内容に関する情報が記録される。

取引コードデータ領域には、各取引を特定するための識別子に関するデータが記録される。
取引日時データ領域には、取引を行なった年月日及び時刻に関するデータが記録される。

購入者データ領域には、取引を行なった商品購入者（支払者）を特定するためのデータが記録される。
取引内容データ領域には、販売対象の商品種別や商品数量に関するデータが記録される。

図３（ｃ）に示す金融機関システム３０，４０は、金融機関の顧客（支払人や受取人）の口座を管理する金融機関のコンピュータシステムである。この金融機関システム３０，４０は、それぞれ口座管理部３１，４１、口座情報記憶部３２，４２を備える。

口座管理部３１，４１は、顧客の口座を管理する処理を実行する。本実施形態では、受取人システム２０からの振出情報に応じて、支払人の口座に残高があることを確認した上で決済承認を行なう。

口座情報記憶部３２，４２には、金融機関に開設された口座を管理するための口座管理情報が記録される。この口座管理情報には、口座識別子、口座名義人、残高、入出金履歴が記録される。

口座識別子データ領域には、金融機関に開設された口座を特定するための識別子に関するデータが記録される。
口座名義人データ領域には、この口座の名義人（支払人や受取人）を特定するための識別子に関するデータが記録される。

残高データ領域には、この口座の残高に関するデータが記録される。
入出金履歴データ領域には、この口座への入金や、この口座からの出金の履歴情報が記録される。

（分散台帳に記録される情報）
図４に示すように、分散台帳Ｄ１には、振出情報５１０、承認情報５２０、入金情報５３０、決済完了情報５４０、失効情報５５０が記録される。

図４（ａ）に示すように、振出情報５１０には、発行番号、取引コード、支払人、受取人、支払人金融機関、受取人金融機関、金額、入金条件に関する情報が含まれる。本実施形態では、この振出情報５１０は、必要に応じて、本取引に関わる関係者（支払人システム１０〜金融機関システム４０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、振出情報５１０を特定するための識別子に関するデータが記録される。
取引コードデータ領域には、支払人と受取人との間での取引を特定するための識別子に関するデータが記録される。本実施形態では、取引コードを、分散台帳Ｄ１に記録される一連の情報（振出情報５１０〜失効情報５５０）を関連付けるために用いられる。

支払人、受取人の各データ領域には、それぞれ、取引を行なった支払人、受取人を特定するための識別子に関するデータが記録される。
支払人金融機関、受取人金融機関の各データ領域には、それぞれ、支払人、受取人が口座を開設した金融機関を特定するための識別子に関するデータが記録される。

金額データ領域には、取引のために支払人が支払う金額に関するデータが記録される。
入金条件データ領域には、支払人と受取人との間での取引契約に基づいて、金融機関が受取人の口座に入金するための条件に関するデータが記録される。

図４（ｂ）に示すように、承認情報５２０には、発行番号、取引コード、支払人金融機関、承認結果に関する情報が含まれる。本実施形態では、この承認情報５２０も、必要に応じて、本取引に関わる関係者（支払人システム１０〜金融機関システム４０等）で復号可能なキーにより暗号化される。
発行番号データ領域には、承認情報５２０を特定するための識別子に関するデータが記録される。

取引コードデータ領域には、支払人と受取人との間での取引を特定するための識別子に関するデータが記録される。
支払人金融機関データ領域には、支払人が口座を保有する金融機関を特定するための識別子に関するデータが記録される。

承認結果データ領域には、口座を利用しての振出についての承認の結果を特定するためのフラグが記録される。

図４（ｃ）に示すように、入金情報５３０には、発行番号、取引コード、受取人金融機関に関する情報が含まれる。本実施形態では、この入金情報５３０も、必要に応じて、本取引に関わる関係者（支払人システム１０〜金融機関システム４０等）で復号可能なキーにより暗号化される。
発行番号データ領域には、入金情報５３０を特定するための識別子に関するデータが記録される。
取引コードデータ領域には、振出対象の取引を特定するための識別子に関するデータが記録される。
受取人金融機関データ領域には、受取人が口座を保有する金融機関を特定するための識別子に関するデータが記録される。

図４（ｄ）に示すように、決済完了情報５４０には、発行番号、取引コード、入金条件、支払人金融機関、決済完了に関する情報が含まれる。本実施形態では、この決済完了情報５４０も、必要に応じて、本取引に関わる関係者（支払人システム１０〜金融機関システム４０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、決済完了情報５４０を特定するための識別子に関するデータが記録される。
取引コードデータ領域には、支払人と受取人との間での取引を特定するための識別子に関するデータが記録される。

入金条件データ領域には、振出における入金条件に関するデータが記録される。
支払人金融機関データ領域には、支払人が口座を保有する金融機関を特定するための識別子に関するデータが記録される。
決済完了データ領域には、決済が完了したことを示すフラグが記録される。

図４（ｅ）に示すように、失効情報５５０には、発行番号、取引コード、入金条件、支払人金融機関、失効に関する情報が含まれる。本実施形態では、この失効情報５５０も、必要に応じて、本取引に関わる関係者（支払人システム１０〜金融機関システム４０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、失効情報５５０を特定するための識別子に関するデータが記録される。
取引コードデータ領域には、支払人と受取人との間での取引を特定するための識別子に関するデータが記録される。

入金条件データ領域には、振出における入金条件に関するデータが記録される。
支払人金融機関データ領域には、支払人が口座を保有する金融機関を特定するための識別子に関するデータが記録される。
失効データ領域には、失効を示すフラグが記録される。

（取引処理）
次に、図５を用いて、取引処理を説明する。ここでは、例えば、振出情報５１０〜失効情報５５０として、ブロックチェーンを利用するオープンアセットプロトコルによるカラードコインを用いる。

図５に示すように、受取人システム２０は、支払依頼処理を実行する（ステップＳ１−１）。具体的には、支払人システム１０と受取人システム２０との間で取引を行なう。例えば、支払人システム１０は、受取人システム２０にアクセスし、所望の商品の購入依頼を送信する。この場合、受取人システム２０は、支払人システム１０に対して、取引コード、受取人金融機関に関する情報を含めた支払依頼を送信する。

次に、支払人システム１０は、振出情報の登録処理を実行する（ステップＳ１−２）。具体的には、支払人によって支払指示が入力された場合、支払人システム１０の制御部１１は、振出情報を作成する。この振出情報には、発行番号、取引コード、支払人、受取人、支払人金融機関、受取人金融機関、金額、入金条件に関する情報を含める。そして、振出指示が入力された場合、制御部１１は、振出情報５１０を、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に振出情報５１０を書き込む。

振出情報５１０に記録された支払人金融機関の金融機関システム３０は、振出情報の確認処理を実行する（ステップＳ１−３）。具体的には、金融機関システム３０の口座管理部３１は、分散台帳Ｄ１において、決済完了情報５４０や失効情報５５０が記録されておらず、支払人の金融機関が記録された振出情報５１０を取得する。そして、口座管理部３１は、取得した振出情報５１０の支払人情報を用いて、口座情報記憶部３２において、支払人の口座を特定する。そして、口座管理部３１は、支払人の口座残高と、振出情報５１０の金額とを比較する。

次に、支払人金融機関の金融機関システム３０は、承認情報の登録処理を実行する（ステップＳ１−４）。具体的には、金融機関システム３０の口座管理部３１は、支払人の口座残高において決済可能と判定した場合には、支払人の口座から、振出情報５１０の金額を引き落とす。そして、口座管理部３１は、発行番号、取引コード、支払人金融機関に関する情報を含めた承認情報５２０を生成する。そして、金融機関システム３０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、承認情報５２０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に承認情報５２０を書き込む。なお、支払人の口座残高が振出情報５１０の金額よりも低く、決済不可と判定した場合には、口座管理部３１は、支払人に対して、振出不可通知を送信する。振出不可通知を取得した支払人は、自身の口座への入金を行なう。この場合、口座管理部３１は、支払人の口座残高を用いて決済可能と判定し、それ以降の処理を実行する。

次に、受取人金融機関の金融機関システム４０は、承認情報を取得したかどうかについての判定処理を実行する（ステップＳ１−５）。具体的には、口座管理部４１は、分散台帳Ｄ１において、決済完了情報５４０や失効情報５５０が記録されておらず、受取人金融機関情報が記録された承認情報５２０の登録の有無を確認する。

承認情報５２０を取得していない場合（ステップＳ１−５において「ＮＯ」の場合）、受取人金融機関の金融機関システム４０は、承認情報の取得を待機する。
一方、承認情報５２０を取得した場合（ステップＳ１−５において「ＹＥＳ」の場合）、受取人金融機関の金融機関システム４０は、入金条件の充足判定処理を実行する（ステップＳ１−６）。具体的には、口座管理部４１は、承認情報５２０の取引コードを用いて、分散台帳Ｄ１に記録された振出情報５１０を特定する。そして、口座管理部４１は、振出情報５１０に記録された入金条件を取得する。次に、口座管理部３１は、現在の状況が入金条件を満足するかどうかを判定する。例えば、入金条件として入金日が設定されている場合には、現在日時と入金日とを比較する。入金条件を充足していない場合には、口座管理部４１は、入金条件を充足するまで待機する。

入金条件を充足していると判定した場合、金融機関システム４０は、入金情報の登録処理を実行する（ステップＳ１−７）。具体的には、口座管理部４１は、受取人の口座に、振出情報５１０の金額を入金する。そして、口座管理部４１は、発行番号、取引コード、受取人金融機関に関する情報を含めた入金情報５３０を生成する。そして、金融機関システム３０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、入金情報５３０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に入金情報５３０を書き込む。

次に、支払人金融機関の金融機関システム３０は、入金情報を取得したかどうかについての判定処理を実行する（ステップＳ１−８）。具体的には、口座管理部３１は、分散台帳Ｄ１において、決済完了情報５４０や失効情報５５０が記録されておらず、支払人金融機関情報が記録された入金情報５３０の登録の有無を確認する。

入金情報５３０を取得した場合（ステップＳ１−８において「ＹＥＳ」の場合）、支払人金融機関の金融機関システム３０は、決済完了情報登録処理を実行する（ステップＳ１−９）。具体的には、口座管理部３１は、発行番号、取引コード、支払人金融機関、決済完了に関する情報を含めた決済完了情報５４０を生成する。そして、金融機関システム３０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、決済完了情報５４０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に決済完了情報５４０を書き込む。

一方、入金情報５３０を取得していない場合（ステップＳ１−８において「ＮＯ」の場合）、支払人金融機関の金融機関システム３０は、入金条件は有効かどうかについての判定処理を実行する（ステップＳ１−１０）。具体的には、口座管理部３１は、分散台帳Ｄ１において、振出情報５１０の入金条件が有効かどうかを確認する。例えば、入金条件において、振出情報５１０に有効期間が設定されている場合、この有効期間を徒過していないかどうかを確認する。

入金条件は有効と判定した場合（ステップＳ１−１０において「ＹＥＳ」の場合）、支払人金融機関の金融機関システム３０は、入金情報を取得したかどうかについての判定処理（ステップＳ１−８）を継続する。

一方、入金条件は有効でないと判定した場合（ステップＳ１−１０において「ＮＯ」の場合）、支払人金融機関の金融機関システム３０は、入金条件の失効処理を実行する（ステップＳ１−１１）。具体的には、口座管理部３１は、発行番号、取引コード、入金条件、支払人金融機関、失効に関する情報を含めた失効情報５５０を生成する。そして、金融機関システム３０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、失効情報５５０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に失効情報５５０を書き込む。

本実施形態によれば、以下のような効果を得ることができる。
（１−１）本実施形態では、振出情報５１０、承認情報５２０、入金情報５３０、決済完了情報５４０、失効情報５５０が分散台帳Ｄ１に記録される。これにより、取引の関係者が、取引内容や取引状況を確認することができる。そして、ブロックチェーンを用いた分散台帳Ｄ１により、分散台帳による情報共有技術と、ブロックチェーン等による記録の改ざん防止技術とを利用して、記録の内容が不変で、記録の照合が容易であり、迅速で効率的な取引決済を支援することができる。

（１−２）本実施形態では、支払人金融機関の金融機関システム３０は、振出情報の確認処理（ステップＳ１−３）、承認情報の登録処理（ステップＳ１−４）を実行する。承認情報５２０を取得した場合（ステップＳ１−５において「ＹＥＳ」の場合）、受取人金融機関の金融機関システム４０は、入金条件の充足判定処理を実行する（ステップＳ１−６）。これにより、支払人の金融機関の承認情報に基づいて入金を行なうことができる。

入金条件を充足していると判定した場合、金融機関システム４０は、入金情報の登録処理を実行する（ステップＳ１−７）。これにより、取引内容に応じて、入金を行なうための条件を設定することができる。

（１−３）入金情報５３０を取得した場合（ステップＳ１−８において「ＹＥＳ」の場合）、支払人金融機関の金融機関システム３０は、決済完了情報の登録処理を実行する（ステップＳ１−９）。これにより、振出情報を、決済完了情報に基づいて、完結させることができる。

（１−４）本実施形態では、入金条件は有効でないと判定した場合（ステップＳ１−１０において「ＮＯ」の場合）、支払人金融機関の金融機関システム３０は、入金条件の失効処理を実行する（ステップＳ１−１１）。これにより、入金できなかった振出情報を無効化することができる。

（第２の実施形態）
次に、図６〜図８に従って、決済システム及び決済方法を具体化した第２の実施形態を説明する。なお、第２の実施形態は、入金条件を変更したのみの構成であるため、同様の部分についてはその詳細な説明を省略する。第１の実施形態では、入金条件として設定された入金日の充足により入金を行なう。第２の実施形態では、入金条件として、取引物（配送対処物）の配送完了を用いる。

図６に示すように、ピア・ツー・ピアのネットワークには、配送管理システム５０を設ける。この配送管理システム５０は、支払人システム１０〜金融機関システム４０と同様に、情報処理装置Ｈ１０により構成され、台帳管理部Ｍ１、情報記憶部Ｍ２を備える。

更に、配送管理システム５０は、配送管理部５１、配送情報記憶部５２を備える。
配送管理部５１は、配送物の配送状況を管理する。
配送情報記憶部５２には、追跡番号に対して配送状況に関する情報が記録される。この配送状況には、配送対象物の配達開始や中継拠点の通過、配送完了を特定する情報が記録される。

更に、図７に示すように、分散台帳Ｄ１には、配送完了情報５６０が記録される。
配送完了情報５６０には、発行番号、取引コード、追跡番号、配送事業者、配送状況に関する情報が含まれる。本実施形態では、この配送完了情報５６０も、必要に応じて、本取引に関わる関係者（支払人システム１０〜配送管理システム５０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、配送完了情報５６０を特定するための識別子に関するデータが記録される。
取引コードデータ領域には、支払人と受取人との間での取引を特定するための識別子に関するデータが記録される。

追跡番号データ領域には、配送事業者において、配送対象物を特定するための識別子に関する情報が記録される。
配送事業者データ領域には、配送対象物を配送する配送事業者を特定するための識別子に関するデータが記録される。
配送状況データ領域には、配送対象物の配送完了を特定する情報が記録される。

なお、分散台帳Ｄ１には、上記第１実施形態と同様に、振出情報５１０〜失効情報５５０も記録される。本実施形態では、振出情報５１０には、発行番号〜入金条件に加えて、取引物を配送する配送事業者に関する情報を記録する。

（取引処理）
次に、図８を用いて、取引処理を説明する。
ここでは、受取人システム２０は、ステップＳ１−１と同様に、支払依頼処理を実行し（ステップＳ２−１）、支払人システム１０は、ステップＳ１−２と同様に、振出情報の登録処理を実行する（ステップＳ２−２）。支払人金融機関の金融機関システム３０は、ステップＳ１−３、Ｓ１−４と同様に、振出情報の確認処理（ステップＳ２−３）、承認情報の登録処理（ステップＳ２−４）を実行する。

次に、受取人金融機関の金融機関システム４０は、ステップＳ１−５と同様に、承認情報を取得したかどうかについての判定処理を実行する（ステップＳ２−５）。
承認情報５２０を取得していない場合（ステップＳ２−５において「ＮＯ」の場合）、受取人金融機関の金融機関システム４０は、承認情報の取得を待機する。

一方、承認情報５２０を取得した場合（ステップＳ２−５において「ＹＥＳ」の場合）、受取人金融機関の金融機関システム４０は、ステップＳ１−６と同様に、入金条件の充足判定処理を実行する（ステップＳ２−６）。ここでは、商品の配送完了が入金条件として記録されており、まだ配送完了情報を取得していない場合を想定する。

また、配送管理システム５０は、承認情報を取得したかどうかについての判定処理を実行する（ステップＳ２−７）。具体的には、配送管理システム５０の配送管理部５１は、分散台帳Ｄ１において、決済完了情報５４０や失効情報５５０が記録されておらず、受取人金融機関情報が記録された承認情報５２０の登録の有無を確認する。

承認情報５２０を取得していない場合（ステップＳ２−７において「ＮＯ」の場合）、配送管理システム５０は、承認情報の取得を待機する。
一方、承認情報５２０を取得した場合（ステップＳ２−７において「ＹＥＳ」の場合）、配送管理システム５０は、配送指示処理を実行する（ステップＳ２−８）。具体的には、配送管理部５１は、配送対象物について、配送指示を、配送事業者の担当者端末に出力する。そして、配送管理部５１は、配送時に、配送対象物の配送ラベルに印字された追跡番号を読み取った場合に、配送情報記憶部５２に配送状況を記録する。

そして、配送管理システム５０は、配送完了情報の登録処理を実行する（ステップＳ２−９）。具体的には、配送管理システム５０の配送管理部５１は、配送情報記憶部５２に、追跡番号に関連付けられた配送状況として配送完了情報が記録された場合、発行番号、取引コード、追跡番号、配送事業者、配送状況に関する情報を含めた配送完了情報５６０を生成する。そして、配送管理システム５０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、配送完了情報５６０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に配送完了情報５６０を書き込む。

受取人金融機関の金融機関システム４０は、配送完了情報を取得したかどうかについての判定処理を実行する（ステップＳ２−１０）。具体的には、口座管理部４１は、分散台帳Ｄ１において、決済完了情報５４０や失効情報５５０が記録されておらず、配送事業者情報が記録された配送完了情報５６０を確認する。

配送完了情報を取得していない場合（ステップＳ２−１０において「ＮＯ」の場合）、受取人金融機関の金融機関システム４０は、配送完了情報の取得を待機する。
一方、配送完了情報を取得した場合（ステップＳ２−１０において「ＹＥＳ」の場合）、受取人金融機関の金融機関システム４０は、ステップＳ１−６、Ｓ１−７と同様に、入金条件の充足判定処理（ステップＳ２−１１）、入金情報の登録処理（ステップＳ２−１２）を実行する。
そして、支払人金融機関の金融機関システム３０は、ステップＳ１−８以降の処理を実行する。

本実施形態によれば、以下のような効果を得ることができる。
（２−１）本実施形態では、承認情報５２０を取得した場合（ステップＳ２−７において「ＹＥＳ」の場合）、配送管理システム５０は、配送指示処理を実行する（ステップＳ２−８）。これにより、分散台帳Ｄ１に記録された情報に基づいて、商品の発送を行なうことができる。

（２−２）本実施形態では、配送管理システム５０は、配送完了情報の登録処理を実行する（ステップＳ２−９）。これにより、分散台帳Ｄ１を用いて、商品の配送状況情報を関係者で共有することができる。

（２−３）本実施形態では、配送完了情報を取得した場合（ステップＳ２−１０において「ＹＥＳ」の場合）、配送管理システム５０は、入金条件の充足判定処理（ステップＳ２−１１）、入金情報の登録処理（ステップＳ２−１２）を実行する。これにより、配送状況に基づいて入金を行なうことができる。

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記各実施形態では、振出情報５１０〜配送完了情報５６０として、ビットコインのブロックチェーンを利用するオープンアセットプロトコル（カラードコイン）を用いる場合を想定した。分散台帳Ｄ１に記録される各情報は、カラードコインに限定されるものではない。ビットコイン以外の分散台帳Ｄ１を応用した、通貨以外の役割・機能を持たすことを主目的とした基盤システムを利用することができる。

・上記各実施形態では、振出情報５１０〜配送完了情報５６０を分散台帳Ｄ１に記録する。分散台帳Ｄ１に記録する情報はこれらに限定されるものではない。
・上記各実施形態では、分散台帳Ｄ１に記録する情報は、必要に応じて、本取引に関わる関係者で復号可能なキーにより暗号化される。暗号化の必要性は、ネットワークや情報に応じて行なえばよい。例えば、関係者のみが用いるクローズド型（プライベート型）ネットワークの場合には、暗号化の必要はない。
・上記各実施形態では、分散台帳Ｄ１に記録される一連の情報を特定するための識別子として取引コードを用いる。一連の情報を特定できる識別子であれば、取引コードに限定されるものではなく、例えば振出情報５１０の発行番号を用いてもよい。
・上記第２の実施形態では、配送完了情報を取得した場合（ステップＳ２−１０において「ＹＥＳ」の場合）、配送管理システム５０は、入金条件の充足判定処理（ステップＳ２−１１）、入金情報の登録処理（ステップＳ２−１２）を実行する。取引者、金融機関以外からの情報を入金条件とする場合、入金条件は配送完了情報に限定されるものではなく、分散台帳Ｄ１に記録された情報を入金条件として用いることができる。

１０…支払人システム、１１…制御部、２０…受取人システム、２１…制御部、３０，４０…金融機関システム、３１，４１…口座管理部、３２，４２…口座情報記憶部、５０…配送管理システム、Ｄ１…分散台帳、Ｍ１…台帳管理部、Ｍ２…情報記憶部。

Claims (5)

1. 取引における支払人の支払人システムと、取引を行なった支払人及び受取人の支払人口座及び受取人口座が開設された金融機関システムとが、分散台帳により情報の正当性を確認できる基盤システムを介して接続された決済システムであって、
   前記支払人システムが、前記取引の契約に基づいて振出情報を前記分散台帳に登録し、
   前記支払人口座が開設された金融機関システムが、前記振出情報についての承認情報を前記分散台帳に登録し、
   前記受取人口座が開設された金融機関システムが、前記振出情報の入金条件を充足する情報を前記分散台帳において確認し、
   前記入金条件の充足に基づいて、前記受取人口座に、前記振出情報に基づいて入金処理を実行し、
   前記支払人口座が開設された金融機関システムが、前記振出情報についての取引完了情報を前記分散台帳に記録することを特徴とする決済システム。
2. 前記支払人口座が開設された金融機関システムが、前記振出情報に基づいて、取引完了情報を前記分散台帳に記録できなかった場合、失効情報を前記分散台帳に記録することを特徴とする請求項１に記載の決済システム。
3. 前記振出情報の入金条件として、前記支払人口座が開設された金融機関システムによる承認情報が前記分散台帳に登録されることを特徴とする請求項１又は２に記載の決済システム。
4. 前記支払人システムが、支払人と受取人との間で、配送事業者により配送される商品に関する契約に基づいて振出情報を前記分散台帳に登録し、
   前記振出情報に基づいて、配送管理システムが、前記契約に関連する商品の配送完了情報を前記分散台帳に登録し、
   前記振出情報の入金条件として、前記配送管理システムによる配送完了情報が前記分散台帳に登録されることを特徴とする請求項１〜３の何れか一項に記載の決済システム。
5. 取引における支払人の支払人システムと、取引を行なった支払人及び受取人の支払人口座及び受取人口座が開設された金融機関システムとが、分散台帳により情報の正当性を確認できる基盤システムを介して接続された決済システムを用いて、決済を支援する方法であって、
   前記支払人システムが、前記取引の契約に基づいて振出情報を前記分散台帳に登録し、
   前記支払人口座が開設された金融機関システムが、前記振出情報についての承認情報を前記分散台帳に登録し、
   前記受取人口座が開設された金融機関システムが、前記振出情報の入金条件を充足する情報を前記分散台帳において確認し、
   前記入金条件の充足に基づいて、前記受取人口座に、前記振出情報に基づいて入金処理を実行し、
   前記支払人口座が開設された金融機関システムが、前記振出情報についての取引完了情報を前記分散台帳に記録することを特徴とする決済方法。