(57)【特許請求の範囲】
【請求項１】
金融機関システム、ユーザ端末が、分散台帳により情報の正当性を確認できる基盤システムを介して接続された決済システムであって、
前記金融機関システムが、ユーザＩＤに関連付けて、支払可能金額を含めた支払保証枠に関する支払保証枠情報を、前記分散台帳に記録し、
前記ユーザ端末が、
支払指示を受け付けた場合、前記分散台帳において、ユーザＩＤに関連付けられた支払保証枠情報を特定し、
今回の支払額が前記支払保証枠情報の支払可能金額以下の場合、前記支払額の支払情報を、前記分散台帳に記録し、
前記金融機関システムが、前記支払額を減額した支払可能金額により更新した支払保証枠情報を前記分散台帳に記録することを特徴とする決済システム。
【請求項２】
金融機関システム、ユーザ端末が、分散台帳により情報の正当性を確認できる基盤システムを介して接続された決済システムであって、
前記金融機関システムが、ユーザＩＤに関連付けて、支払可能金額を含めた支払保証枠に関する支払保証枠情報を、前記分散台帳に記録し、
前記ユーザ端末が、
支払指示を受け付けた場合、前記分散台帳において、ユーザＩＤに関連付けられた支払保証枠情報を特定し、前記支払保証枠情報に関連付けられた支払情報を特定し、
今回の支払額が、前記支払保証枠情報の支払可能金額から前記支払情報の支払額を差し引いた支払可能残額以下の場合、前記今回の支払額を含めた支払情報を前記分散台帳に記録することを特徴とする決済システム。
【請求項３】
前記金融機関システムが、前記ユーザ端末から取得した支払予定情報に基づいて、前記支払保証枠を、前記分散台帳に記録することを特徴とする請求項１又は２に記載の決済システム。
【請求項４】
前記金融機関システムが、
前記支払保証枠情報を前記分散台帳に記録したユーザの信用情報を取得し、
前記信用情報により支払保証枠の維持ができないと判定した場合、前記支払保証枠情報の失効情報を、前記分散台帳に記録することを特徴とする請求項１〜３の何れか一項に記載の決済システム。
【請求項５】
前記金融機関システムが、前記ユーザ端末からの指示に基づいて、前記支払保証枠情報の失効情報を、前記分散台帳に記録することを特徴とする請求項１〜４の何れか一項に記載の決済システム。
【請求項６】
前記支払保証枠情報には、期限が設定されており、
前記金融機関システムが、前記期限の到来と判定した場合、前記支払保証枠情報の失効情報を、前記分散台帳に記録することを特徴とする請求項１〜５の何れか一項に記載の決済システム。
【請求項７】
金融機関システム、ユーザ端末が、分散台帳により情報の正当性を確認できる基盤システムを介して接続された決済システムを用いた決済方法であって、
前記金融機関システムが、ユーザＩＤに関連付けて、支払可能金額を含めた支払保証枠に関する支払保証枠情報を、前記分散台帳に記録し、
前記ユーザ端末が、
支払指示を受け付けた場合、前記分散台帳において、ユーザＩＤに関連付けられた支払保証枠情報を特定し、
今回の支払額が前記支払保証枠情報の支払可能金額以下の場合、前記支払額の支払情報を、前記分散台帳に記録し、
前記金融機関システムが、前記支払額を減額した支払可能金額により更新した支払保証枠情報を前記分散台帳に記録することを特徴とする決済方法。
【請求項８】
金融機関システム、ユーザ端末が、分散台帳により情報の正当性を確認できる基盤システムを介して接続された決済システムを用いた決済方法であって、
前記金融機関システムが、ユーザＩＤに関連付けて、支払可能金額を含めた支払保証枠に関する支払保証枠情報を、前記分散台帳に記録し、
前記ユーザ端末が、
支払指示を受け付けた場合、前記分散台帳において、ユーザＩＤに関連付けられた支払保証枠情報を特定し、前記支払保証枠情報に関連付けられた支払情報を特定し、
今回の支払額が、前記支払保証枠情報の支払可能金額から前記支払情報の支払額を差し引いた支払可能残額以下の場合、前記今回の支払額を含めた支払情報を前記分散台帳に記録することを特徴とする決済方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、取引の決済を行なうための決済システム及び決済方法に関する。
【背景技術】
【０００２】
ピア・ツー・ピア・ネットワークを活用したブロックチェーン技術が決済等に利用されつつある。具体的には、ブロックチェーンを活用して、大規模な決済システムを新規に構築することなく、約定情報を改ざん不可能なデータとして瞬時に共有・決済できる仕組みが検討されている。このブロックチェーン技術では、順序付けられたレコードを、分散台帳で連続的に管理することにより、ブロック内のデータの遡及的な変更を防止する。
【０００３】
また、オープンかつ分散を前提としたサービスで提供される仮想通貨の取引情報の真正性の保証度を高めるために、ブロックチェーン技術が利用される場合もある（例えば、特許文献１参照）。この技術では、投資家と海外証券会社との間で国内証券を取引対象とする取引が約定された場合、投資管理システムが、約定情報及び紐付け情報を記録した仮想通貨を分散台帳に登録する。
【０００４】
また、分散型台帳技術を用いて、債務記録情報の正当性を確認できる基盤システムを利用して、支払を支援するための技術も検討されている（例えば、特許文献２参照）。この技術では、支払人端末及び支払人金融機関サーバに接続され、ブロックチェーン等の分散型台帳技術により情報の正当性を確認できる基盤システムを用いる。支払人端末は、債務者から債権者に対する支払方式の選択情報を取得し、選択された支払方式の債務記録情報を分散台帳に記録し、選択された支払方式に応じた支払人金融機関サーバに債務記録情報の発行を通知する。支払人金融機関サーバは、分散台帳を確認し、債務記録情報の承認情報を分散台帳に記録し、支払方式に基づいて、債権者に対する支払処理を行ない、債務記録情報の失効情報を分散台帳に記録する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１８−３２０８０号公報
【特許文献２】特開２０１８−１９０１５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、金融機関の承認を待って支払を行なっていたのでは、迅速な支払を行なうことができない場合がある。一方、金融機関の承認前に支払を受け入れたのでは、支払人の預金残高不足により決済が不成立となる可能性がある。
【課題を解決するための手段】
【０００７】
上記課題を解決する決済システムは、金融機関システム、ユーザ端末が、分散台帳により情報の正当性を確認できる基盤システムを介して接続される。そして、前記金融機関システムが、ユーザＩＤに関連付けて、支払可能金額を含めた支払保証枠に関する支払保証枠情報を、前記分散台帳に記録し、前記ユーザ端末が、支払指示を受け付けた場合、前記分散台帳において、ユーザＩＤに関連付けられた支払保証枠情報を特定し、今回の支払額が前記支払保証枠情報の支払可能金額以下の場合、前記支払額の支払情報を、前記分散台帳に記録し、前記金融機関システムが、前記支払額を減額した支払可能金額により更新した支払保証枠情報を前記分散台帳に記録する。
また、上記課題を解決する決済システムは、金融機関システム、ユーザ端末が、分散台帳により情報の正当性を確認できる基盤システムを介して接続される。そして、前記金融機関システムが、ユーザＩＤに関連付けて、支払可能金額を含めた支払保証枠に関する支払保証枠情報を、前記分散台帳に記録し、前記ユーザ端末が、支払指示を受け付けた場合、前記分散台帳において、ユーザＩＤに関連付けられた支払保証枠情報を特定し、前記支払保証枠情報に関連付けられた支払情報を特定し、今回の支払額が、前記支払保証枠情報の支払可能金額から前記支払情報の支払額を差し引いた支払可能残額以下の場合、前記今回の支払額を含めた支払情報を前記分散台帳に記録する。
【発明の効果】
【０００８】
本発明によれば、分散台帳による情報共有技術と、情報の正当性を確認できる基盤システムとを利用して、効率的な取引を支援することができる。
【図面の簡単な説明】
【０００９】
【図１】実施形態のシステム概略図。
【図２】実施形態のハードウェア構成例の説明図。
【図３】本実施形態で分散台帳に記録される情報の説明図であって、（ａ）は支払保証枠情報、（ｂ）は支払情報、（ｃ）は承認情報、（ｄ）は失効情報の説明図。
【図４】実施形態の処理手順の説明図。
【図５】実施形態の処理手順の説明図。
【図６】実施形態の処理手順の説明図。
【発明を実施するための形態】
【００１０】
以下、図１〜図６を用いて、決済システム及び決済方法を具体化した一実施形態を説明する。
図１に示すように、本実施形態では、分散台帳Ｄ１に接続されたユーザ端末１０、金融機関サーバ２０を用いる。本実施形態では、ブロックチェーンにより支払保証枠情報の記録の正当性を確認できる基盤システムを用いて、支払を支援する場合を想定する。なお、ネットワークに接続された複数のノードで同じデータを保持し合う分散台帳Ｄ１（分散型台帳）を用いるものであれば、ブロックチェーン技術を用いる場合に限定されるものではない。そして、支払保証枠情報は、金融機関が支払を保証する金額に関する情報を電子的に記録するものであり、分散台帳Ｄ１に記録され、ブロックチェーン技術により固定化される。更に、所謂仮想通貨とは異なり、この記録自体では決済は完了せず、単に支払の保証枠に関する情報が記録されるだけである。
【００１１】
ユーザ端末１０、金融機関サーバ２０は、ピア・ツー・ピア（Peer to Peer）のネットワークで接続されている。このピア・ツー・ピアは、多数のシステム間で通信を行なうためのアーキテクチャのひとつであり、ピア同士が通信を行なう通信方式の基盤システムである。例えば、情報の改ざんを防止するために、ブロックチェーン方式を用いることができる。ブロックチェーン方式では、「取引の記録」をまとめた「ブロック」を「チェーン」状に順次追加していく。ブロックチェーンを構成するそれぞれのブロックは、そのブロックと一つ前のブロックに関する情報を含む「ヘッダ」と、ある時間内に行なわれた取引のリストを記録した「トランザクション」とにより構成される。ブロックチェーンにおいては、過去からの全取引が記録されているため、仮に不正を行なおうとした場合、不正以降の全ブロックを書き換える必要があり、計算負荷が大きく改ざんを困難にしている。そして、ピア・ツー・ピアネットワークに接続されている各システムは、一つのピアが発信した情報を、それぞれで分散して共有することになる。
【００１２】
そして、ユーザ端末１０、金融機関サーバ２０は、それぞれ、ピア・ツー・ピアネットワークにおいて共有する情報を保存する分散台帳Ｄ１を保持する。一つのシステムの分散台帳Ｄ１に、所定の情報が書き込まれた場合、ピア・ツー・ピアネットワークにより、他のすべてのシステムが保有する分散台帳Ｄ１に、同じ情報が書き込まれる。
【００１３】
（ハードウェア構成例）
図２は、ユーザ端末１０、金融機関サーバ２０等として機能する情報処理装置Ｈ１０のハードウェア構成例である。
【００１４】
情報処理装置Ｈ１０は、通信装置Ｈ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶部Ｈ１４、プロセッサＨ１５を有する。なお、このハードウェア構成は一例であり、他のハードウェアを有していてもよい。
【００１５】
通信装置Ｈ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。
【００１６】
入力装置Ｈ１２は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置Ｈ１３は、各種情報を表示するディスプレイやタッチパネル等である。
【００１７】
記憶部Ｈ１４は、ユーザ端末１０、金融機関サーバ２０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置（例えば、情報記憶部Ｍ２）である。記憶部Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。
【００１８】
プロセッサＨ１５は、記憶部Ｈ１４に記憶されるプログラムやデータを用いて、ユーザ端末１０、金融機関サーバ２０における各処理（例えば、台帳管理部Ｍ１、制御部１１、保証枠管理部２１における処理）を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各種処理に対応する各種プロセスを実行する。例えば、プロセッサＨ１５は、ユーザ端末１０、金融機関サーバ２０のアプリケーションプログラムが起動された場合、後述する図４〜図６に示す各処理を実行するプロセスを動作させる。
【００１９】
プロセッサＨ１５は、自身が実行するすべての処理についてソフトウェア処理を行うものに限られない。例えば、プロセッサＨ１５は、自身が実行する処理の少なくとも一部についてハードウェア処理を行う専用のハードウェア回路（例えば、特定用途向け集積回路：ＡＳＩＣ）を備えてもよい。すなわち、プロセッサＨ１５は、（１）コンピュータプログラム（ソフトウェア）に従って動作する１つ以上のプロセッサ、（２）各種処理のうち少なくとも一部の処理を実行する１つ以上の専用のハードウェア回路、或いは（３）それらの組み合わせ、を含む回路（circuitry）として構成し得る。プロセッサは、ＣＰＵ並びに、ＲＡＭ及びＲＯＭ等のメモリを含み、メモリは、処理をＣＰＵに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。
【００２０】
（各情報処理装置の機能）
図１に示すように、ユーザ端末１０、金融機関サーバ２０は、それぞれ、台帳管理部Ｍ１、情報記憶部Ｍ２を備える。台帳管理部Ｍ１は、自システムの情報記憶部Ｍ２に書き込まれた情報を、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に書き込む。
【００２１】
ユーザ端末１０は、金融機関の顧客であって、取引を行なうユーザが用いるコンピュータシステムである。ユーザ端末１０は、制御部１１を備える。制御部１１は、ユーザの入力に応じて、支払保証枠を用いての決済を支援する。このため、制御部１１は、ユーザ端末１０を利用する顧客のユーザＩＤや、支払保証枠の利用可否を示すフラグを記録するメモリを備える。
【００２２】
金融機関サーバ２０は、顧客の口座を管理する金融機関のコンピュータシステムである。この金融機関サーバ２０は、保証枠管理部２１、顧客情報記憶部２２を備える。
【００２３】
保証枠管理部２１は、ユーザに対して提供した支払保証枠を管理する処理を実行する。
顧客情報記憶部２２には、金融機関の顧客であるユーザに関する顧客管理情報が記録される。この顧客管理情報には、ユーザＩＤ、口座識別子、残高、取引履歴、支払可能金額が記録される。
【００２４】
ユーザＩＤデータ領域には、各ユーザを特定するための識別子に関するデータが記録される。
口座識別子データ領域には、このユーザの口座を特定するための識別子に関するデータが記録される。
【００２５】
残高データ領域には、この口座の残高に関するデータが記録される。
取引履歴データ領域には、ユーザの口座の入出金履歴や取引履歴、与信枠に関するデータが記録される。
支払可能金額データ領域には、ユーザに対して設定した支払保証枠の金額に関するデータが記録される。
【００２６】
（分散台帳に記録される情報）
図３に示すように、分散台帳Ｄ１には、支払保証枠情報５１０、支払情報５２０、承認情報５３０、失効情報５４０が記録される。ここでは、支払保証枠情報５１０〜失効情報５４０として、例えば、ブロックチェーンを利用するオープンアセットプロトコルによるカラードコインを用いる。
【００２７】
図３（ａ）に示すように、支払保証枠情報５１０には、発行番号、金融機関ＩＤ、ユーザＩＤ、支払可能金額、設定日時、有効期限に関する情報が含まれる。この支払保証枠情報５１０は、必要に応じて、本取引に関わる関係者システム（ユーザ端末１０、金融機関サーバ２０等）で復号可能なキーにより暗号化される。
【００２８】
発行番号データ領域には、支払保証枠を特定するための識別子に関するデータが記録される。本実施形態では、この発行番号は、分散台帳Ｄ１に記録される一連の情報を特定するための識別子として用いられる。
【００２９】
金融機関ＩＤデータ領域には、支払保証枠を設定した金融機関を特定するための識別子に関するデータが記録される。
ユーザＩＤデータ領域には、この支払保証枠を設定したユーザを特定するための識別子に関するデータが記録される。
【００３０】
支払可能金額データ領域には、このユーザに対して金融機関が支払保証を行なう金額に関するデータが記録される。
設定日時データ領域には、この支払保証枠を設定した年月日及び時刻に関するデータが記録される。
有効期限データ領域には、この支払保証枠が有効な期限（年月日）に関するデータが記録される。
【００３１】
図３（ｂ）に示すように、支払情報５２０には、発行番号、支払番号、ユーザＩＤ、支払先、支払額に関する情報が含まれる。この支払情報５２０は、必要に応じて、本取引に関わる関係者システムで復号可能なキーにより暗号化される。
【００３２】
発行番号データ領域には、支払保証枠を特定するための識別子に関するデータが記録される。
支払番号データ領域には、支払保証枠を用いた支払を特定するための識別子に関するデータが記録される。
【００３３】
ユーザＩＤデータ領域には、支払を行なうユーザを特定するための識別子に関するデータが記録される。
支払先データ領域には、支払先を特定する識別子に関するデータが記録される。例えば、支払先の口座番号や、決済機関で用いられている取引先コード等を用いることができる。
支払額データ領域には、ユーザが支払先に送金する金額に関するデータが記録される。
【００３４】
図３（ｃ）に示すように、承認情報５３０には、発行番号、支払番号、金融機関ＩＤ、承認日時に関する情報が含まれる。この承認情報５３０は、必要に応じて、本取引に関わる関係者システムで復号可能なキーにより暗号化される。
【００３５】
発行番号データ領域には、支払保証枠を特定するための識別子に関するデータが記録される。
支払番号データ領域には、支払保証枠を用いた支払を特定するための識別子に関するデータが記録される。
【００３６】
金融機関ＩＤデータ領域には、支払保証枠を設定した金融機関を特定するための識別子に関するデータが記録される。
承認日時データ領域には、支払保証枠を用いた支払を承認した年月日及び時刻に関するデータが記録される。
【００３７】
図３（ｄ）に示すように、失効情報５４０には、発行番号、失効日時に関する情報が含まれる。この失効情報５４０は、必要に応じて、本取引に関わる関係者システムで復号可能なキーにより暗号化される。
【００３８】
発行番号データ領域には、支払保証枠を特定するための識別子に関するデータが記録される。
失効日時データ領域には、支払保証枠が失効した年月日及び時刻に関するデータが記録される。
【００３９】
（支払保証枠の設定処理）
次に、図４を用いて、支払保証枠の設定処理を説明する。
まず、ユーザ端末１０は、支払予定の指示処理を実行する（ステップＳ１−１）。具体的には、ユーザは、ユーザ端末１０を用いて、支払予定画面に、支払予定に関する情報を入力する。この支払予定画面には、支払予定日、支払予定金額に関する情報を設定する。支払予定の入力を完了した場合、制御部１１は、支払予定情報を金融機関サーバ２０に送信する。この支払予定情報には、ユーザＩＤ、支払予定日、支払予定金額に関する情報を含める。
【００４０】
次に、金融機関サーバ２０は、支払保証の担保処理を実行する（ステップＳ１−２）。具体的には、保証枠管理部２１は、支払予定情報に含まれるユーザＩＤに基づいて、顧客情報記憶部２２から、ユーザとの取引状況を取得する。次に、保証枠管理部２１は、取引状況に基づいて、支払保証可能かどうかを判定する。例えば、取引履歴に支払保証の担保が記録されておらず、ユーザが保有する口座に支払予定金額に対応する残高がある場合には、支払保証枠を設定可能と判定する。また、取引履歴に支払保証の担保が記録されておらず、ユーザとの取引状況に基づいて設定された与信枠に支払予定金額が収まる場合にも、支払保証枠を設定可能と判定する。保証枠管理部２１は、支払保証枠を設定可能と判定した場合には、口座残高や与信枠において、顧客管理情報の取引履歴に、支払保証の担保を記録する。この支払保証の担保により、支払保証枠以外での口座残高や与信枠の利用を不可にする。そして、保証枠管理部２１は、顧客情報記憶部２２の顧客管理情報に、支払保証を担保するために、支払可能金額を記録する。
【００４１】
次に、金融機関サーバ２０は、支払保証枠の設定処理を実行する（ステップＳ１−３）。具体的には、保証枠管理部２１は、支払保証枠情報５１０を生成する。この支払保証枠情報５１０には、発行番号、金融機関ＩＤ、ユーザＩＤ、支払可能金額、設定日時、有効期限に関する情報を含める。発行番号データ領域には、支払保証枠を特定するための識別子を設定する。金融機関ＩＤデータ領域には、金融機関サーバ２０を特定するための識別子を設定する。ユーザＩＤデータ領域には、このユーザを特定するための識別子を設定する。支払可能金額データ領域には、支払予定金額に対応した金額を設定する。設定日時データ領域には、現在日時を設定する。有効期限データ領域には、支払予定日に対応した年月日を設定する。そして、保証枠管理部２１は、支払保証枠情報５１０を、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に支払保証枠情報５１０を書き込む。
【００４２】
次に、ユーザ端末１０は、支払保証の記録処理を実行する（ステップＳ１−４）。具体的には、制御部１１は、情報記憶部Ｍ２の分散台帳Ｄ１に記録された支払保証枠情報５１０を取得し、支払保証枠が設定されていることを示す有効フラグをメモリに記憶する。
【００４３】
（失効管理処理）
次に、図５を用いて、失効管理処理を説明する。この処理は、支払保証枠毎に定期的に実行される。
【００４４】
まず、金融機関サーバ２０は、有効期限が到来したかどうかについての判定処理を実行する（ステップＳ２−１）。具体的には、保証枠管理部２１は、支払保証枠情報５１０に記録されている有効期限と現在日とを比較する。現在日が有効期限を経過している場合には、有効期限の到来と判定する。
【００４５】
有効期限が到来していないと判定した場合（ステップＳ２−１において「ＮＯ」の場合）、金融機関サーバ２０は、顧客状況の特定処理を実行する（ステップＳ２−２）。具体的には、保証枠管理部２１は、支払保証枠を設定した顧客について、顧客情報記憶部２２に記録されている顧客管理情報を取得する。そして、保証枠管理部２１は、信用情報として顧客管理情報の残高や取引履歴を特定する。
【００４６】
次に、金融機関サーバ２０は、保証枠を継続可能かどうかについての判定処理を実行する（ステップＳ２−３）。具体的には、保証枠管理部２１は、特定した顧客状況に基づいて、支払保証枠の失効の要否を判定する。例えば、顧客管理情報の残高や与信枠が支払可能金額以上の場合には、保証枠を継続可能と判定する。一方、残高や与信枠が支払可能金額未満の場合には、保証枠の継続不可と判定する。また、取引履歴に応じて、この顧客との取引について所定期間の取引がない場合にも、保証枠の継続不可と判定する。
【００４７】
有効期限が到来と判定した場合（ステップＳ２−１において「ＹＥＳ」の場合）や、保証枠を継続不可と判定した場合（ステップＳ２−３において「ＮＯ」の場合）、金融機関サーバ２０は、失効情報の設定処理を実行する（ステップＳ２−４）。具体的には、保証枠管理部２１は、失効情報５４０を生成する。この失効情報５４０には、支払保証枠情報５１０の発行番号を設定し、失効日時を記録する。そして、保証枠管理部２１は、失効情報５４０を、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に失効情報５４０を書き込む。
【００４８】
次に、ユーザ端末１０は、支払枠の失効処理を実行する（ステップＳ２−５）。具体的には、制御部１１は、情報記憶部Ｍ２の分散台帳Ｄ１に記録された失効情報５４０を取得し、支払保証枠が失効したことを示す無効フラグをメモリに記憶する。ここで、口座残高を支払保証の担保としていた場合、支払保証枠情報５１０の支払保証金額の残額を、ユーザＩＤの口座に戻す。また、信用枠を支払保証の担保としていた場合、信用枠の全額利用を可能にする。
【００４９】
一方、保証枠を継続可能と判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、金融機関サーバ２０は、失効情報の設定処理（ステップＳ２−４）をスキップして、この支払保証枠についての処理を終了する。
【００５０】
（支払処理）
次に、図６を用いて、支払処理を説明する。
ここでは、ユーザ端末１０は、支払額の確定処理を実行する（ステップＳ３−１）。具体的には、ユーザ端末１０を用いて支払いを行なう場合、支払画面に、支払に関する情報を入力する。この支払画面には、支払先及び支払額に関する情報を設定する。この場合、制御部１１は、入力された支払先及び支払額に関する情報を取得する。支払先としては、商品の販売者の口座等、送金先を特定できる情報を用いる。
【００５１】
次に、ユーザ端末１０は、支払保証枠の特定処理を実行する（ステップＳ３−２）。具体的には、制御部１１は、情報記憶部Ｍ２の分散台帳Ｄ１から、ユーザＩＤが記録された支払保証枠情報５１０を取得する。この場合、制御部１１は、失効情報５４０が記録されていない支払保証枠情報５１０を特定する。
【００５２】
次に、ユーザ端末１０は、支払保証枠で支払可能かどうかについての判定処理を実行する（ステップＳ３−３）。具体的には、制御部１１は、分散台帳Ｄ１において特定した支払保証枠情報５１０の支払可能金額と支払額とを比較する。支払額が支払可能金額以下の場合には、支払保証枠で支払可能と判定する。一方、支払額が支払可能金額を超えている場合や、失効情報５４０が記録されていない支払保証枠情報５１０を特定できない場合には、支払保証枠で支払不可と判定する。
【００５３】
支払保証枠で支払可能と判定した場合（ステップＳ３−３において「ＹＥＳ」の場合）、ユーザ端末１０は、支払情報の登録処理を実行する（ステップＳ３−４）。具体的には、制御部１１は、支払情報５２０を生成する。この支払情報５２０には、発行番号、支払番号、ユーザＩＤ、支払先、支払額に関する情報を含める。発行番号データ領域には、利用する支払保証枠の発行番号を設定する。支払番号データ領域には、この支払を特定する識別子に関するデータを記録する。ユーザＩＤデータ領域には、ユーザ端末１０に記録されたユーザＩＤを設定する。支払先データ領域には、商品の販売者の口座等、送金先を特定できる情報を設定する。支払額データ領域には、支払額を設定する。そして、制御部１１は、支払情報５２０を、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に支払情報５２０を書き込む。
【００５４】
次に、ユーザ端末１０は、支払完了処理を実行する（ステップＳ３−５）。具体的には、制御部１１は、表示装置Ｈ１３に支払を完了したことを示すメッセージを出力する。
一方、支払保証枠で支払不可と判定した場合（ステップＳ３−３において「ＮＯ」の場合）、ユーザ端末１０は、支払不可処理を実行する（ステップＳ３−６）。具体的には、制御部１１は、表示装置Ｈ１３に支払保証枠を利用できないことを示すメッセージを出力する。
【００５５】
次に、金融機関サーバ２０は、支払情報の取得処理を実行する（ステップＳ３−７）。具体的には、保証枠管理部２１は、金融機関サーバ２０の情報記憶部Ｍ２の分散台帳Ｄ１に記録された支払情報５２０を取得する。
【００５６】
次に、金融機関サーバ２０は、承認処理を実行する（ステップＳ３−８）。具体的には、保証枠管理部２１は、支払情報５２０のユーザＩＤに基づいて、顧客情報記憶部２２から顧客管理情報を取得する。次に、保証枠管理部２１は、支払情報５２０の支払額が顧客管理情報の保証枠内であることを確認する。そして、保証枠管理部２１は、承認情報５３０を生成する。この承認情報５３０には、発行番号、支払番号、金融機関ＩＤ、承認日時に関する情報を含める。発行番号、支払番号の各データ領域には、支払情報５２０の発行番号、支払番号を設定する。金融機関データ領域には、金融機関サーバ２０が保持している金融機関ＩＤを設定する。承認日時データ領域には、現在の年月日及び時刻を設定する。そして、制御部１１は、承認情報５３０を、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に承認情報５３０を書き込む。
【００５７】
次に、金融機関サーバ２０は、元の支払保証枠の失効処理を実行する（ステップＳ３−９）。具体的には、保証枠管理部２１は、失効情報５４０を生成する。この失効情報５４０には、支払保証枠情報５１０の発行番号を設定し、失効日時を記録する。そして、保証枠管理部２１は、失効情報５４０を、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に失効情報５４０を書き込む。
【００５８】
次に、金融機関サーバ２０は、新規の支払保証枠の登録処理を実行する（ステップＳ３−１０）。具体的には、保証枠管理部２１は、支払保証枠情報５１０を生成する。この支払保証枠情報５１０には、発行番号、金融機関ＩＤ、ユーザＩＤ、支払可能金額、設定日時、有効期限に関する情報を含める。発行番号データ領域には、新たな支払保証枠を特定するための識別子を設定する。金融機関ＩＤデータ領域、ユーザＩＤデータ領域、有効期限データ領域には、元の支払保証枠情報５１０と同じ識別子を設定する。支払可能金額データ領域には、元の支払保証枠情報５１０の支払可能金額から支払額を差し引いた金額を設定する。設定日時データ領域には、現在日時を設定する。そして、保証枠管理部２１は、支払保証枠情報５１０を、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に支払保証枠情報５１０を書き込む。
【００５９】
次に、金融機関サーバ２０は、販売者への送金処理を実行する（ステップＳ３−１１）。具体的には、保証枠管理部２１は、支払情報５２０に記録された送金先に、支払額の送金により支払を行なう。
【００６０】
本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、支払保証枠情報５１０、支払情報５２０、承認情報５３０、失効情報５４０が分散台帳Ｄ１に記録される。これにより、取引の関係者が、支払保証枠の状況を確認することができる。そして、ブロックチェーンを用いた分散台帳Ｄ１により、分散台帳による情報共有技術と、ブロックチェーン等による記録の改竄防止技術とを利用して、記録の内容が不変で、記録の照合が容易であり、迅速で効率的な支払についての一連の処理を支援することができる。
【００６１】
（２）本実施形態では、ユーザ端末１０は、支払予定の指示処理を実行する（ステップＳ１−１）。また、金融機関サーバ２０は、支払保証の担保処理（ステップＳ１−２）、支払保証枠の設定処理（ステップＳ１−３）を実行する。これにより、ユーザに対して支払保証枠を提供することができる。
【００６２】
（３）本実施形態では、金融機関サーバ２０は、有効期限が到来かどうかについての判定処理を実行する（ステップＳ２−１）。有効期限が到来と判定した場合（ステップＳ２−１において「ＹＥＳ」の場合）、金融機関サーバ２０は、失効情報の設定処理を実行する（ステップＳ２−４）。これにより、支払予定日が経過した場合には、支払保証枠を解除することができる。
【００６３】
また、金融機関サーバ２０は、顧客状況の特定処理（ステップＳ２−２）、保証枠を継続可能かどうかについての判定処理（ステップＳ２−３）を実行する。保証枠を継続不可と判定した場合（ステップＳ２−３において「ＮＯ」の場合）、金融機関サーバ２０は、失効情報の設定処理を実行する（ステップＳ２−４）。これにより、顧客状況に基づいて、支払保証枠を解除することができる。
【００６４】
（４）本実施形態では、ユーザ端末１０は、支払保証枠の特定処理（ステップＳ３−２）、支払保証枠で支払可能かどうかについての判定処理（ステップＳ３−３）を実行する。支払保証枠で支払可能と判定した場合（ステップＳ３−３において「ＹＥＳ」の場合）、ユーザ端末１０は、支払情報の登録処理を実行する（ステップＳ３−４）。これにより、予め設定された支払保証枠を用いて、速やかに決済を行なうことができる。
【００６５】
（５）本実施形態では、金融機関サーバ２０は、元の支払保証枠の失効処理（ステップＳ３−９）、新規の支払保証枠の登録処理（ステップＳ３−１０）を実行する。これにより、支払に応じて支払保証枠を更新することができる。
【００６６】
本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、支払保証枠情報５１０〜失効情報５４０として、ビットコインのブロックチェーンを利用するオープンアセットプロトコル（カラードコイン）を用いる場合を想定した。分散台帳Ｄ１に記録される各情報は、カラードコインに限定されるものではない。ビットコイン以外の分散台帳Ｄ１を応用した、通貨以外の役割・機能を持たすことを主目的とした基盤システムを利用することができる。
【００６７】
・上記実施形態では、支払保証枠情報５１０〜失効情報５４０を分散台帳Ｄ１に記録する。分散台帳Ｄ１に記録する情報はこれらに限定されるものではない。
例えば、ユーザ端末１０は、支払予定の指示処理（ステップＳ１−１）において、分散台帳Ｄ１に支払保証枠設定依頼情報を記録してもよい。この支払保証枠設定依頼情報には、ユーザＩＤ、金融機関ＩＤ、支払予定日、支払予定金額に関する情報を含める。
そして、支払保証枠設定依頼情報の金融機関ＩＤの金融機関サーバ２０は、分散台帳Ｄ１に記録された支払保証枠設定依頼情報に基づいて、支払保証の担保処理を実行する（ステップＳ１−２）。
【００６８】
・上記実施形態では、ユーザ端末１０からの指示に基づいて、金融機関サーバ２０は、支払保証枠の設定処理を実行する（ステップＳ１−３）。これに加えて、ユーザ端末１０からの指示に基づいて、金融機関サーバ２０は、失効情報の設定処理（ステップＳ２−４）を実行するようにしてもよい。ここでも、口座残高を支払保証の担保としていた場合、支払保証枠情報５１０の支払保証金額の残額を、ユーザＩＤの口座に戻す。また、信用枠を支払保証の担保としていた場合、信用枠の全額利用を可能にする。
【００６９】
・上記実施形態では、ユーザ端末１０からの指示に基づいて、金融機関サーバ２０は、支払保証枠の設定処理を実行する（ステップＳ１−３）。ユーザ端末１０からの指示に代えて、金融機関サーバ２０は、定期的に支払保証枠の設定処理（ステップＳ１−３）を実行するようにしてもよい。この場合には、顧客状況に応じて、支払可能金額を設定する。例えば、口座残高や取引量に基づいて、支払可能金額を設定する。残高が高い場合や、取引量が多い場合には、支払可能金額を高く設定する。また、顧客状況に応じて有効期限を長くしてもよい。
【００７０】
・上記実施形態では、有効期限が到来と判定した場合（ステップＳ２−１において「ＹＥＳ」の場合）、金融機関サーバ２０は、失効情報の設定処理を実行する（ステップＳ２−４）。これに加えて、有効期限を設けない支払保証枠を提供してもよい。この場合には、支払保証枠情報５１０の有効期限を設定しない。
【００７１】
・上記実施形態では、ユーザ端末１０は、支払保証枠の特定処理（ステップＳ３−２）、支払保証枠で支払可能かどうかについての判定処理（ステップＳ３−３）を実行する。ここで、支払情報５２０の支払額の合計額を用いて、支払保証枠で支払可能かどうかを判定してもよい。この場合には、ユーザ端末１０は、支払保証枠情報５１０と同じ発行番号で関連付けられた支払情報５２０を特定し、特定した支払情報５２０の支払額の合計額を算出する。そして、ユーザ端末１０は、支払保証枠情報５１０の支払可能額から合計額を差し引いた支払可能残額と、今回の支払額とを比較する。今回の支払額が支払可能残額内の場合に、支払保証枠で支払可能と判定する。この場合には、金融機関サーバ２０における新規の支払保証枠の登録処理（ステップＳ３−１０）は不要である。そして、金融機関サーバ２０は、支払情報５２０の合計額が支払保証枠の支払可能額に達した場合に、元の支払保証枠の失効処理を実行する（ステップＳ３−９）。
【００７２】
・上記実施形態では、分散台帳Ｄ１に記録する情報は、必要に応じて、本取引に関わる関係者で復号可能なキーにより暗号化される。暗号化の必要性は、ネットワークや情報に応じて行なえばよい。例えば、関係者のみが用いるクローズド型（プライベート型）ネットワークの場合には、暗号化の必要はない。
【００７３】
・上記実施形態では、分散台帳Ｄ１に記録される一連の情報を特定するための識別子として、支払保証枠情報５１０の発行番号等を用いる。一連の情報を特定できる識別子であれば、支払保証枠情報５１０の発行番号に限定されるものではない。
【符号の説明】
【００７４】
１０…ユーザ端末、１１…制御部、２０…金融機関サーバ、２１…保証枠管理部、２２…顧客情報記憶部、Ｄ１…分散台帳、Ｍ１…台帳管理部、Ｍ２…情報記憶部。
【要約】
【課題】分散台帳を用いて、記録の正当性を確認できる基盤システムを利用して、効率的な取引や決済を支援するための決済システム及び決済方法を提供する。
【解決手段】金融機関サーバ２０が、ユーザＩＤに関連付けて、支払可能金額を含めた支払保証枠に関する支払保証枠情報を、分散台帳Ｄ１に記録し、ユーザ端末１０が、支払指示を受け付けた場合、分散台帳Ｄ１において、ユーザＩＤに関連付けられた支払保証枠情報を特定し、今回の支払額が支払保証枠情報の支払可能金額以下の場合、支払額の支払情報を、分散台帳Ｄ１に記録し、金融機関サーバ２０が、支払額を減額した支払可能金額により更新した支払保証枠情報を分散台帳Ｄ１に記録する。
【選択図】図１【図１】
0006792032.tif 000002
【図２】
0006792032.tif 000003
【図３】
0006792032.tif 000004
【図４】
0006792032.tif 000005
【図５】
0006792032.tif 000006
【図６】
0006792032.tif 000007