(57)【要約】【課題】既存の決済システムに参加しない利用者が存在する場合でも、電子的な決済媒体の価値を保証した上で電子的な決済を実現することを目的とする。【解決手段】プロセッサとメモリを有する決済要求装置と、プロセッサとメモリを有する決済実行装置と、電子的な債権または債務を管理する電子債権管理装置と、を有する決済システムであって、前記決済要求装置は、電子的な決済媒体による支払要求を発行し、前記決済実行装置は、前記決済媒体による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置へ記録させ、前記決済媒体を受取人へ送信する。【選択図】図２
2020144526.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサとメモリを有する決済要求装置と、
プロセッサとメモリを有する決済実行装置と、
電子的な債権または債務を管理する電子債権管理装置と、を有する決済システムであって、
前記決済要求装置は、
電子的な決済媒体による支払要求を発行し、
前記決済実行装置は、
前記決済媒体による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置へ記録させ、前記決済媒体を受取人へ送信することを特徴とする決済システム。
【請求項２】
請求項１に記載の決済システムであって、
前記決済実行装置は、
前記決済媒体に対応する価値の債務を前記電子債権管理装置へ記録させることで、前記決済媒体の価値を保証することを特徴とする決済システム。
【請求項３】
請求項１に記載の決済システムであって、
前記決済実行装置は、
前記受取人が前記電子債権管理装置を利用できない場合には、当該決済実行装置の運用者の保証を付与して前記受取人へ前記決済媒体を送信することを特徴とする決済システム。
【請求項４】
請求項３に記載の決済システムであって、
前記決済実行装置は、
前記受取人が前記電子債権管理装置を利用できない場合には、当該決済実行装置で割引を行って、当該割引の残余を前記受取人への決済媒体の価値とすることを特徴とする決済システム。
【請求項５】
請求項１に記載の決済システムであって、
前記決済要求装置は、
前記決済媒体の換金要求を発行し、
前記決済実行装置は、
前記換金要求を受け付けて、前記換金要求を申し込んだ決済要求装置の運用者が前記電子債権管理装置を利用可能か否かを判定し、利用できない場合には、前記換金要求を受け付けた決済実行装置の運用者を保証人として、前記決済媒体の発行元へ通知することを特徴とする決済システム。
【請求項６】
請求項１に記載の決済システムであって、
前記決済要求装置と決済実行装置は、前記決済媒体の授受を記録する分散台帳を共有し、前記決済要求装置は、前記支払要求を前記分散台帳へ書き込むことで、前記支払要求を前記決済実行装置へ通知することを特徴とする決済システム。
【請求項７】
プロセッサとメモリを有する決済要求装置と、プロセッサとメモリを有する決済実行装置と、電子的な債権または債務を管理する電子債権管理装置で、決済を実行する決済方法であって、
前記決済要求装置が、電子的な決済媒体による支払要求を発行する支払要求発行ステップと、
前記決済実行装置が、前記決済媒体による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置へ記録する債務記録ステップと、
前記決済実行装置が、前記決済媒体を前記支払要求に含まれる受取人へ送信する送信ステップと、
を含むことを特徴とする決済方法。
【請求項８】
請求項７に記載の決済方法であって、
前記債務記録ステップでは、
前記決済媒体に対応する価値の債務を前記電子債権管理装置へ記録させることで、前記決済媒体の価値を保証することを特徴とする決済方法。
【請求項９】
請求項７に記載の決済方法であって、
前記送信ステップでは、
前記受取人が前記電子債権管理装置を利用できない場合には、当該決済実行装置の運用者の保証を付与して前記受取人へ前記決済媒体を送信することを特徴とする決済方法。
【請求項１０】
請求項９に記載の決済方法であって、
前記送信ステップでは、
当該決済実行装置で割引を行って、当該割引の残余を前記受取人への決済媒体の価値とすることを特徴とする決済方法。
【請求項１１】
請求項７に記載の決済方法であって、
前記決済要求装置が、前記決済媒体の換金要求を発行する換金要求発行ステップと、
前記決済実行装置が、前記換金要求を受け付けて、前記換金要求を申し込んだ決済要求装置の運用者が前記電子債権管理装置を利用可能か否かを判定し、利用できない場合には、前記換金要求を受け付けた決済実行装置の運用者を保証人として、前記決済媒体の発行元へ通知する換金要求受付ステップと、
をさらに含むことを特徴とする決済方法。
【請求項１２】
請求項７に記載の決済方法であって、
前記決済要求装置と決済実行装置は、前記決済媒体の授受を記録する分散台帳を共有し、
支払要求発行ステップでは、
前記決済要求装置が、前記支払要求を前記分散台帳へ書き込むことで、前記支払要求を前記決済実行装置へ通知することを特徴とする決済方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子的な決済システムに関する。
【背景技術】
【０００２】
金融や商取引の電子化が進展しており、企業が所有する手形等の債権を電子化して、債権の流動性を向上させる技術として電子債権管理システムが知られている（例えば、特許文献１）。
【０００３】
電子債権管理システムでは、電子債権記録機関が管理する記録原簿へ電子的な債権（電子債権）の記録を行うことで債権の発生とし、譲渡等の資金（金銭債権）の移動を管理する。支払企業（債務者）は納入企業（債権者）に対して電子債権を受け渡し、電子債権管理システム側では債務の発生を記録しておく。そして、電子債権の支払期日には、電子債権管理システムに参加する金融機関が支払企業の口座から納入企業の口座に資金を移動する。
【０００４】
また、電子債権管理システムでは、従来の手形と同様に債権の譲渡や割引を行うことができ、資金の流動性を確保している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−１２１４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来例では、支払企業と納入企業の全員が電子債権管理システムに加入していることが前提であり、電子債権管理システムへ加入していない納入企業は電子債権を利用することはできない、という問題があった。
【０００７】
また、サプライチェーン等のコミュニティでは、仮想通貨などの電子的な決済媒体による決済を行うことも可能ではあるが、仮想通貨は法定通貨との関連はないため価値の保証はなく、利用するのが難しいという問題があった。
【０００８】
そこで本発明は、上記問題点に鑑みてなされたもので、既存の決済システムに参加しない利用者が存在する場合でも、電子的な決済媒体の価値を保証した上で電子的な決済を実現することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、プロセッサとメモリを有する決済要求装置と、プロセッサとメモリを有する決済実行装置と、電子的な債権または債務を管理する電子債権管理装置と、を有する決済システムであって、前記決済要求装置は、電子的な決済媒体による支払要求を発行し、前記決済実行装置は、前記決済媒体による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置へ記録させ、前記決済媒体を受取人へ送信する。
【発明の効果】
【００１０】
したがって、本発明は、決済要求装置と決済実行装置を含むコミュニティ内で決済媒体（例えば、トークン）を発行して債権の流通を実現し、既存の決済システム（電子債権管理装置）と連携することで、決済媒体の価値を担保することができる。そして、本発明では、既存の決済システムに参加しない企業（運用者）が存在するコミュニティでも、電子的な決済媒体（トークン）の価値を保証した上で決済を実現することができる。
【００１１】
本明細書において開示される主題の、少なくとも一つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例１を示し、決済システムの装置構成の一例を示すブロック図である。
【図２】本発明の実施例１を示し、決済システムを利用するトークンコミュニティと、企業及び金融機関の関係の一例を示す図である。
【図３】本発明の実施例１を示し、コミュニティ決済要求装置の一例を示すブロック図である。
【図４】本発明の実施例１を示し、コミュニティ決済実行装置の一例を示すブロック図である。
【図５】本発明の実施例１を示し、コミュニティ決済実行装置で行われるトークン発行処理の一例を示すフローチャートである。
【図６】本発明の実施例１を示し、コミュニティ決済要求装置で行われるトークン支払要求処理の一例を示すフローチャートである。
【図７】本発明の実施例１を示し、コミュニティ決済実行装置で行われるトークン支払受け付け処理の一例を示すフローチャートである。
【図８】本発明の実施例１を示し、コミュニティ決済要求装置で行われるトークン換金要求処理の一例を示すフローチャートである。
【図９】本発明の実施例１を示し、コミュニティ決済実行装置で行われるトークン換金受け付け処理の一例を示すフローチャートである。
【図１０】本発明の実施例１を示し、口座管理テーブルの一例を示す図である。
【図１１】本発明の実施例１を示し、コミュニティ管理テーブルの一例を示す図である。
【図１２】本発明の実施例１を示し、トークン残高管理テーブルの一例を示す図である。
【図１３】本発明の実施例１を示し、トークン分散台帳の一例を示す図である。
【図１４】本発明の実施例１を示し、電子債権管理テーブルの一例を示す図である。
【図１５】本発明の実施例２を示し、トークン分散台帳の一例を示す図である。
【図１６】本発明の実施例３を示し、トークン分散台帳の一例を示す図である。
【図１７】本発明の実施例４を示し、企業ノードの一例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明の実施形態を添付図面に基づいて説明する。
【実施例１】
【００１４】
図１は、本発明の実施例１を示し、決済システムの装置構成の一例を示すブロック図である。本実施例１の決済システムは、メーカやサプライヤ等で構成されるサプライチェーンのコミュニティの中で、電子的な通貨（トークン）で商取引の決済を行う。
【００１５】
決済システムは、電子的な決済媒体としてのトークンの発行依頼や、トークンの支払や、トークンの換金要求を実行するコミュニティ決済要求装置１００と、トークンの発行や割引や換金等の業務を実行するコミュニティ決済実行装置２００と、前記従来例と同様に電子債権（金銭債権）を管理する電子債権管理システム３００と、コミュニティ決済要求装置１００及びコミュニティ決済実行装置２００を管理する管理端末４００と、コミュニティ決済要求装置１００とコミュニティ決済実行装置２００と電子債権管理システム３００及び管理端末４００を相互に接続するネットワーク１０と、を含む。
【００１６】
サプライチェーンを構成するメーカやサプライヤ等の企業でひとつのコミュニティが形成される。このコミュニティに含まれる企業にはコミュニティ決済要求装置１００が配置され、トークンによって商取引の決済が行われる。以下、トークンによって決済を行うコミュニティをトークンコミュニティとする。また、トークンコミュニティに含まれる企業の一部は、電子債権管理システム３００の利用者として登録されている。なお、トークンコミュニティの企業と取引を行う金融機関もトークンコミュニティに含むことができる。
【００１７】
コミュニティの各企業と取引を行う金融機関には、トークンの発行や割引又は換金等の処理を行うコミュニティ決済実行装置２００が配置される。各金融機関は、電子債権管理システム３００に参加する。
【００１８】
図２は、本発明の決済システムを利用するトークンコミュニティと、企業及び金融機関の関係の一例を示す図である。サプライチェーンは、支払企業（メーカ）としての企業Ｘと、企業Ｘへ部品を納入する納入企業（サプライヤ）としての企業Ｙと、企業Ｙへ部品を納入する納入企業（サプライヤ）としての企業Ｚで構成される。
【００１９】
企業Ｘは金融機関Ａと取引を行い、企業Ｙは金融機関Ｂと取引を行い、企業Ｚは金融機関Ｃと取引を行う。サプライチェーンの企業Ｘ〜Ｚと金融機関Ａ〜Ｃは、トークンを利用するトークンコミュニティを構成する。
【００２０】
トークンコミュニティでは、各企業及び金融機関でトークン分散台帳５００を共有することで、トークンの管理が行われる。企業Ｘ〜Ｚは、トークンを利用するためにコミュニティ決済要求装置１００−Ｘ〜１００−Ｚを有する。なお、以下の説明では、コミュニティ決済要求装置を個々に特定しない場合には、「−」以降を省略した符号１００を用いる。他の構成要素の符号についても同様である。
【００２１】
金融機関Ａ〜Ｃは、トークンの利用と口座の管理のためにコミュニティ決済実行装置２００−Ａ〜２００−Ｃを有する。コミュニティ決済実行装置２００は、トークン分散台帳５００の管理と、口座の管理と、電子債権管理システム３００に対する記録の依頼（代理要求）を実施する。また、コミュニティ決済実行装置２００が実施する電子債権管理システム３００への依頼は、トークンコミュニティにおける債権の発生等の記録である。
【００２２】
トークンコミュニティ内では、コミュニティ決済要求装置１００とコミュニティ決済実行装置２００がトークン分散台帳５００を共有して管理する。そして、金融機関Ａ〜Ｃのコミュニティ決済実行装置２００は、トークン分散台帳５００と電子債権管理システム３００の債務（または債権）を連携させる。
【００２３】
なお、金融機関Ａ〜Ｃは、電子債権管理システム３００に参加しており、企業Ｘと企業Ｙは、電子債権管理システム３００の利用者である。企業Ｚは、電子債権管理システム３００を利用していないため、電子債権を利用することはできない。
【００２４】
＜概要＞
以下に、トークンコミュニティで行われる決済の概要について説明する。
【００２５】
まず、サプライチェーンの企業Ｘが、サプライチェーンの代表としてトークンコミュニティの口座を開設する。企業Ｘのコミュニティ決済要求装置１００−Ｘは、金融機関Ａのコミュニティ決済実行装置２００−Ａに対して、口座の開設（トークンの発行）を依頼する（Ｐ１）。コミュニティ決済実行装置２００は、トークンコミュニティの口座を開設して企業Ｘのコミュニティ決済要求装置１００−Ｘにトークン発行権を付与する（Ｐ２）。
【００２６】
次に、企業Ｘは納品の対価として企業Ｙにトークンで支払を実施する。企業Ｘのコミュニティ決済要求装置１００−Ｘは、トークンによる支払要求を金融機関Ａのコミュニティ決済実行装置２００へ通知する。金融機関Ａのコミュニティ決済実行装置２００−Ａは、トークン分散台帳５００にトークンの発行を記載し、トークンを発行する。コミュニティ決済実行装置２００−Ａは、発行されたトークンを企業Ｙのコミュニティ決済要求装置１００−Ｂへ送信する（Ｐ３）。
【００２７】
なお、トークンには、企業Ｘからの支払の履歴と、金額と、支払期日と、受取人が含まれる。また、コミュニティ決済要求装置１００−Ｘがトークン分散台帳５００へ書き込む内容は、トークンを発行したトランザクション内容が記録される。なお、金融機関Ａで発行されたトークンは、企業Ｘのコミュニティ決済要求装置１００−Ａから企業Ｙへ送信するようにしてもよい。
【００２８】
企業Ｘの口座を管理する金融機関Ａでは、コミュニティ決済実行装置２００−Ａがトークン分散台帳５００から企業Ｘのトークンによる支払要求を取得し、電子債権管理システム３００へ企業Ｘから企業Ｙに対する債務（金銭債務）の発生を記録させる（Ｐ４）。電子債権管理システム３００は、コミュニティ決済実行装置２００−Ａの依頼を受け付けて、電子債権管理テーブル３１０にトークンの内容を記録する。
【００２９】
コミュニティ決済実行装置２００−Ａが、企業Ｘの支払要求によって発行されたトークンの内容を電子債権管理システム３００の電子債権管理テーブル３１０へ記録させることによって、トークンの価値は電子債権管理システム３００に登録された法定通貨の価値で担保されることになる。これにより、本発明の決済システムでは、トークンコミュニティと実社会の決済システムを連携させることで、トークンコミュニティ内の電子的な決済媒体であるトークンと、実社会の法定通貨を連携させて、企業間の決済を実現することができる。
【００３０】
電子債権管理システム３００は、企業Ｙの債権の発生を金融機関Ｂのコミュニティ決済実行装置２００−Ｂへ通知する。企業Ｙの口座を管理する金融機関Ｂのコミュニティ決済実行装置２００−Ｂは、送金の通知をトークン分散台帳５００へ記録する。
【００３１】
次に、企業Ｙが、トークンの支払期日以前にトークンの譲渡（割引）を金融機関Ｂへ依頼する。ここで、企業Ｙは、電子債権管理システム３００を利用していない企業Ｚとの取引に対して、トークンでの決済（譲渡）を希望して、金融機関Ｂへ企業Ｚへの譲渡及び割引を申し込む（Ｐ６）。
【００３２】
金融機関Ｂは、企業Ｙと電子債権管理システム３００の利用契約をしており、コミュニティ決済実行装置２００−Ｂは、割引対象のトークンの記録を、企業Ｙから金融機関Ｂへの譲渡に変更し、電子債権管理システム３００へ書き込みを依頼する（Ｐ７）。
【００３３】
金融機関Ｂは、企業Ｘの信用に基づきトークンの割引率を算出し、割引分を金融機関Ｂの持分とし、割引いた残り金額（価値）を企業Ｚに支払うトークンとして発行する。すなわち、金融機関Ｂは、企業Ｘから企業Ｙへの支払いが滞っても、金融機関Ｂは企業Ｙから企業Ｚへの支払いを保証し、保証する対価として割り引きを実施する（Ｐ８）。
【００３４】
コミュニティ決済実行装置２００−Ｂは、割引後の価値のトークンを企業Ｙのコミュニティ決済要求装置１００−Ｙへ送信する（Ｐ９）。企業Ｙのコミュニティ決済要求装置１００−Ｙは、トークンを企業Ｚのコミュニティ決済要求装置１００−Ｚへ送信して支払を実行する。なお、企業Ｙから企業Ｚへのトークンの支払は、金融機関Ｂのコミュニティ決済実行装置２００−Ｂが企業Ｚのコミュニティ決済要求装置１００−Ｚへ送信してもよい。
【００３５】
次に、トークンを受け取った企業Ｚは、支払期日以降に金融機関Ｃに対してトークンの換金を依頼する（Ｐ１０）。金融機関Ｃのコミュニティ決済実行装置２００−Ｃは、トークンの発行元である金融機関Ａのコミュニティ決済実行装置２００−Ａに、トークンの換金を要求する（Ｐ１１）。トークンの発行元は、コミュニティ決済実行装置２００がトークン分散台帳５００の履歴を参照することで取得することができる。
【００３６】
コミュニティ決済実行装置２００−Ａは、トークンの換金の要求を受け付けて、企業Ｘの口座からトークンの割引後の金額を金融機関Ｃの企業Ｚの口座へ送金し、割引額を金融機関Ｃへ送金する（Ｐ１１）。そして、コミュニティ決済実行装置２００−Ａは、トークンの支払が完了したので、企業Ｘ（金融機関Ａ）の債務の抹消を電子債権管理システム３００へ依頼する。
【００３７】
なお、金融機関Ａ〜Ｃ間の決済は、口座単位で行う必要はなく、一定の期日毎にまとめて差額分を決済するネッティングを用いることができる。
【００３８】
以上のように、本発明の決済システムでは、トークンコミュニティと既存の決済システム（電子債権管理システム３００）をトークン分散台帳５００で連携させることで、電子的な決済媒体の価値を担保して、トークンコミュニティ内で決済を行うことが可能となる。そして、トークンコミュニティ内の企業の一部が既存の決済システムに加入していなくても、安全に決済を行うことができる。
【００３９】
＜コミュニティ決済要求装置＞
図３は、コミュニティ決済要求装置１００の一例を示すブロック図である。コミュニティ決済要求装置１００は、メモリ１０１と、演算装置１０２と、入力装置１０３と、出力装置１０４と、通信装置１０５と、ストレージ装置１０６を含む計算機である。
【００４０】
ストレージ装置１０６には、トークンによる支払を金融機関に要求するトークン支払要求プログラム１１０と、受け付けたトークンの換金を金融機関に要求するトークン換金要求プログラム１２０と、トークンをトークンコミュニティ内で共有するトークン分散台帳５００と、トークン残高管理テーブル６００と、コミュニティ管理テーブル７００が格納される。
【００４１】
入力装置１０３は、例えば、キーボードやマウスあるいはタッチパネルで構成される。出力装置１０４は、例えば、ディスプレイなどで構成される。通信装置１０５は、ネットワーク１０に接続されて、他の計算機と通信を行う。
【００４２】
トークン支払要求プログラム１１０と、トークン換金要求プログラム１２０は、メモリ１０１にロードされて演算装置１０２によって実行される。
【００４３】
演算装置１０２は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、演算装置１０２は、トークン支払要求プログラム１１０に従って処理を実行することでトークン支払要求部として機能する。他のプログラムについても同様である。さらに、演算装置１０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
【００４４】
トークン分散台帳５００は、トークンコミュニティの参加者で分散して共有される管理台帳である。本実施例１では、企業Ｘ〜Ｚのコミュニティ決済要求装置１００と、金融機関Ａ〜Ｃのコミュニティ決済実行装置２００にそれぞれ格納され、トークンの情報を共有する。図１３は、トークン分散台帳５００の一例を示す図である。
【００４５】
トークン分散台帳５００は、金融機関Ａ〜Ｃのコミュニティ決済実行装置２００または企業Ｘ〜Ｙのコミュニティ決済要求装置１００によって更新される。トークン分散台帳５００は、取引ＩＤ５０１と、取引内容５０２と、支払人５０３と、受取人５０４と、取引額５０５と、対象取引５０６と、記録ＩＤ５０７と、保証人５０８とをひとつのエントリに含む。
【００４６】
取引ＩＤ５０１は、トークンの処理で発生したトランザクションの識別子（ＩＤ）が格納される。トランザクションの識別子は、コミュニティ決済実行装置２００またはコミュニティ決済要求装置１００が付与した識別子で、トークンコミュニティ内でユニークな値である。
【００４７】
取引内容５０２には、トークンの処理内容や、企業または金融機関における処理の内容が格納される。支払人５０３には、トークンの送金元の名称が格納される。受取人５０４には、トークンの受取人が格納される。取引額５０５には、トークンの金額（または価値）が格納される。
【００４８】
対象取引５０６には、当該トランザクションに関連する取引ＩＤが格納される。記録ＩＤ５０７には、当該トランザクションに関連する情報が格納された電子債権管理システム３００の識別子が設定される。記録ＩＤ５０７は、電子債権管理システム３００が設定した値を用い、１以上の識別子を格納することができる。保証人５０８には、当該トランザクションの取引額を担保する人または機関の名称が格納される。
【００４９】
図１２は、トークン残高管理テーブル６００の一例を示す図である。トークン残高管理テーブル６００は、トークンコミュニティの参加者で分散して共有され、金融機関Ａ〜Ｃのコミュニティ決済実行装置２００によって更新される。
【００５０】
トークン残高管理テーブル６００は、トークン名６０１と、トークン残高６０２と、有効期限６０３と、引換開始日６０４をひとつのエントリに含む。トークン名６０１は、金融機関Ａ〜Ｃのコミュニティ決済実行装置２００が決定した名称または識別子が格納される。なお、トークン名６０１は、トークンコミュニティ内でユニークな値である。
【００５１】
トークン残高６０２には、トークンの価値（金額）が格納される。有効期限６０３には、当該トークンを利用可能な期間の最終日が格納される。引換開始日６０４は、当該トークンを通貨に交換可能な日付が格納される。なお、トークン残高６０２には最新のトークンの残高が格納される。
【００５２】
図１１は、コミュニティ管理テーブル７００の一例を示す図である。コミュニティ管理テーブル７００は、トークンコミュニティの参加者で分散して共有され、金融機関Ａ〜Ｃのコミュニティ決済実行装置２００によって設定される。
【００５３】
コミュニティ管理テーブル７００は、トークン名７０１と、発行額７０２と、参加者名７０３と、代表者フラグ７０４と、でんさい契約有無７０５をひとつのエントリに含む。
【００５４】
トークン名７０１には、トークンの名称または識別子が格納される。発行額７０２には、発行可能なトークンの値（金額）が格納される。参加者名７０３には、当該トークンを利用可能なトークンコミュニティの参加者の名称が格納される。
【００５５】
代表者フラグ７０４には、当該トークンコミュニティの代表者に「Ｙ」が設定される。なお、本実施例１では、トークンの支払人（企業Ｘ）が、代表者となり、代表者が参加者名７０３を決定する例を示すがこれに限定されるものではない。
【００５６】
でんさい契約有無７０５には、トークンコミュニティの参加者のうち、電子債権管理システム３００の利用契約を締結している参加者には「Ｙ」が設定される。なお、本実施例１では、実社会の決済システムとして電子債権管理システム３００を利用する例を示したが、これに限定されるものではない。例えば、債務または債権を登録可能な決済システムであれば、利用することが可能である。
【００５７】
また、本実施例１では、トークンコミュニティの代表者は、電子債権管理システム３００の利用契約を有するものとする。
【００５８】
トークンコミュニティの参加者の追加や変更などの情報がトークン分散台帳５００に随時記録され、最新の状態がコミュニティ管理テーブル７００に反映される。
【００５９】
＜コミュニティ決済実行装置＞
図４は、コミュニティ決済実行装置２００の一例を示すブロック図である。コミュニティ決済実行装置２００は、メモリ２０１と、演算装置２０２と、入力装置２０３と、出力装置２０４と、通信装置２０５と、ストレージ装置２０６を含む計算機である。
【００６０】
ストレージ装置２０６には、トークンを発行するトークン発行プログラム２１０と、トークンの支払要求を処理するトークン支払受付プログラム２２０と、トークンの換金を処理するトークン換金受付プログラム２３０と、トークン分散台帳５００と、トークン残高管理テーブル６００と、コミュニティ管理テーブル７００と、口座管理テーブル８００と、信用スコアテーブル９００が格納される。
【００６１】
なお、トークン分散台帳５００と、トークン残高管理テーブル６００と、コミュニティ管理テーブル７００は、コミュニティ決済要求装置１００と同様であるので説明を省略する。
【００６２】
入力装置２０３は、例えば、キーボードやマウスあるいはタッチパネルで構成される。出力装置２０４は、例えば、ディスプレイなどで構成される。通信装置２０５は、ネットワーク１０に接続されて、他の計算機と通信を行う。
【００６３】
演算装置２０２は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、演算装置２０２は、トークン発行プログラム２１０に従って処理を実行することでトークン発行部として機能する。他のプログラムについても同様である。さらに、演算装置２０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
【００６４】
図１０は、口座管理テーブル８００一例を示す図である。口座管理テーブル８００は、金融機関Ａ〜Ｃのコミュニティ決済実行装置２００によって管理される。口座管理テーブル８００は、口座番号８０１と、利用者名８０２と、残高８０３をひとつのエントリに含む。
【００６５】
信用スコアテーブル９００は、図示はしないが、トークンコミュニティの参加者のそれぞれについて、信用の度合いを示すスコアが設定される。各金融機関Ａ〜Ｃのコミュニティ決済実行装置２００は、信用スコアテーブル９００のスコアを参照して、トークンの割引率等を決定することができる。
【００６６】
＜電子債権管理システム＞
電子債権管理システム３００は、前記特許文献１や周知の電子記録債権サービスを提供する計算機システムまたは計算機である。図１４は、電子債権管理システム３００が管理する電子債権管理テーブル３１０の一例を示す図である。
【００６７】
電子債権管理テーブル３１０は、記録ＩＤ３１１と、債務者３１２と、債権者３１３と、債権額３１４と、削除フラグ３１５をひとつのエントリに含む。記録ＩＤ３１１は、電子債権管理システム３００で付与された識別子でユニークな値で、トークン分散台帳５００の記録ＩＤ５０７に対応する。
【００６８】
債務者３１２、債権者３１３には、法人名または氏名が格納される。債権額３１４には、金額が格納される。削除フラグ３１５には、抹消されたエントリに「Ｄ」が格納される。
【００６９】
図示の例では、債権額３１４が「１００」の企業Ｙの債権が、金融機関Ｂで割引されて分割され、債権額３１４が「８０」の企業Ｙの債権と、債権額３１４が「２０」の金融機関Ａの債権に分割された例を示す。
【００７０】
なお、上記実施例１では、債権の管理を行う既存の決済システムとして電子債権管理システム３００を用いる例を示したが、電子債権管理装置等の単一の計算機であってもよい。
【００７１】
＜処理＞
図５は、トークン発行処理の一例を示すフローチャートである。この処理は、金融機関のコミュニティ決済実行装置２００のトークン発行プログラム２１０が、企業のコミュニティ決済要求装置１００からトークン発行要求を受け付けると開始される。
【００７２】
以下の説明では、コミュニティ決済実行装置２００を処理の主体として説明するが、トークン発行プログラム２１０や演算装置２０２を処理の主体としてもよい。
【００７３】
コミュニティ決済実行装置２００は、企業のコミュニティ決済要求装置１００からトークン支払要求を受け付ける（Ｓ１）。コミュニティ決済実行装置２００は、口座管理テーブル８００を参照して、トークンの支払を要求した利用者の口座残高を取得し、支払額に対して残高の不足がないことを判定する（Ｓ２）。
【００７４】
次に、コミュニティ決済実行装置２００は、トークンの名称を決定し、トークンの支払要求に含まれる支払額と参加者等の情報をコミュニティ管理テーブル７００に登録する（Ｓ３）。
【００７５】
コミュニティ決済実行装置２００は、決定したトークンの名称をコミュニティ管理テーブル７００のトークン名７０１に設定し、支払額７０２を設定し、支払要求の送信元を代表者として、参加者名７０３に登録し、代表者フラグ７０４を「Ｙ」に設定し、電子債権管理システム３００の利用契約の有無に応じてでんさい契約有無７０５を設定する。
【００７６】
また、コミュニティ決済実行装置２００は、支払要求に設定されたトークンコミュニティの参加者について、参加者名７０３、代表者フラグ７０４＝「Ｎ」及びでんさい契約有無７０５を設定する。
【００７７】
コミュニティ決済実行装置２００は、当該金融機関が保有するトークンとして、上記のように決定した新たなトークンを、トークン分散台帳５００に登録する（Ｓ４）。本実施例１では、コミュニティ決済実行装置２００が、新たなトークンとして取引ＩＤ５０１が「ＴＸ１００」のエントリを追加し、図１３のトークン分散台帳５００に登録する例を示す。
【００７８】
コミュニティ決済実行装置２００は、金融機関が発行した新たなトークンを、支払を要求した代表者の所有に移転して、トークンの発行を完了する（Ｓ５）。本実施例１では、コミュニティ決済実行装置２００が、取引ＩＤ５０１＝「ＴＸ２００」で、取引内容５０２が「発行」のエントリを追加する。図１３の例では、支払人５０３が「金融機関Ａ」、受取人５０４が「企業Ｘ」の内容で金融機関Ａから企業Ｘへの移転がトークン分散台帳５００に登録される。
【００７９】
上記処理によって、トークン分散台帳５００には、金融機関によって登録された新たなトークンが、取引ＩＤ５０１の「ＴＸ２００」で企業Ｘの支払用のトークンとして発行される。そして、新たなトークンの発行は、トークン分散台帳５００によってトークンコミュニティの参加者に通知される。
【００８０】
なお、トークンを発行するための金融機関の口座は、当座預金のような既存の決済用の口座を用いることができ、あるいは、トークン決済用の特別な口座を利用してもよい。また、トークンの発行額は、発行の要求で指定されてもよいし、指定せずに残高全額を発行額としてもよい。
【００８１】
また、上記では、トークンの支払要求の際に、コミュニティの参加者を指定する例を示すが、これに限定されるものではない。例えば、コミュニティの代表が個別に参加者を登録してもよい。あるいは、代表以外の参加者が参加申請し、代表者が承認してコミュニティ管理テーブル７００に登録してもよい。
【００８２】
金融機関またはその他の組織が、図示しない取引履歴などを元に、企業Ｘ、企業Ｙ、企業Ｚがサプライチェーンを構成していると判断し、参加者名７０３に企業Ｘ〜企業Ｚを登録してもよい。
【００８３】
図６は、トークン支払要求処理の一例を示すフローチャートである。この処理は、企業のコミュニティ決済要求装置１００のトークン支払要求プログラム１１０が、利用者からトークン支払要求を受け付けると開始される。
【００８４】
コミュニティ決済要求装置１００は、入力装置１０３等からトークン支払要求を受け付ける（Ｓ１０）。トークン支払要求には、例えば、支払額、受取人、支払期日などが含まれる。コミュニティ決済要求装置１００は、コミュニティ管理テーブル７００を参照して、受取人が電子債権管理システム３００の利用契約を有しているか否かを判定する。受取人が電子債権管理システム３００の利用者であれば、ステップＳ１２へ進み、そうでない場合にはステップＳ１３へ進む。
【００８５】
ステップＳ１２では、コミュニティ決済要求装置１００は、取引内容５０２を「支払」として、受取人へのトークンの支払をトークン分散台帳５００に登録する。本実施例１では、企業Ｘから企業Ｙへの支払として取引ＩＤ５０１＝「ＴＸ３００」のエントリをコミュニティ決済要求装置１００がトークン分散台帳５００に登録する例を示す。
【００８６】
一方、ステップＳ１３では、受取人が電子債権管理システム３００を利用していないので、コミュニティ決済要求装置１００は、取引内容５０２を「保証付支払」として、受取人の金融機関Ｂへの支払としてトークン分散台帳５００に登録する。本実施例１では、図２で示したように、電子債権管理システム３００に未加入の企業Ｚへ企業Ｙがトークンで支払う際には、金融機関Ｂを受取人とし、取引ＩＤ５０１＝「ＴＸ４００」としてトークン分散台帳５００に登録する例を示す。
【００８７】
取引ＩＤ５０１＝「ＴＸ４００」の「保証付支払」のトークンは、支払人５０３が「企業Ｘ」で、受取人５０４が「金融機関Ｂ」で、金融機関Ｂが企業Ｚへの支払を担保する例を示す。
【００８８】
上記処理によって、トークン分散台帳５００には、支払のトランザクション（ＴＸ３００、またはＴＸ４００）が登録される。金融機関のコミュニティ決済実行装置２００は、トークン分散台帳５００を参照することで、企業Ｘから企業Ｙ（企業Ｚ）への支払要求が新たに発生したことを検出することができる。
【００８９】
図７は、トークン支払受付処理の一例を示すフローチャートである。この処理は、金融機関のコミュニティ決済実行装置２００のトークン支払受付プログラム２２０が、トークン分散台帳５００に新たな支払要求を検出したときに開始される。
【００９０】
コミュニティ決済実行装置２００は、トークン分散台帳５００から新たな支払要求のエントリを検出し、支払人５０３と受取人５０４及び取引ＩＤ５０１を読み込む（Ｓ２１）。
【００９１】
ステップＳ２２では、コミュニティ決済実行装置２００が、口座管理テーブル８００を参照して支払人の口座の有無に基づいて、当該支払が自金融機関（以下、自行とする）行で行う処理であるか否かを判定する。当該支払を自行で行う場合は、ステップＳ２３へ進み、そうでない場合には処理を終了する。
【００９２】
次に、ステップＳ２３では、コミュニティ決済実行装置２００が、コミュニティ管理テーブル７００を参照して、支払人が代表者であるか否かを判定する。支払人が代表者であればステップＳ２４へ進み、そうでない場合にはステップＳ２６へ進む。
【００９３】
ステップＳ２４では、コミュニティ決済実行装置２００が、電子債権管理システム３００に対して、支払人に債務が発生した記録（発生記録）を依頼（代理請求）する。
【００９４】
ステップＳ２５では、コミュニティ決済実行装置２００は、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、発生記録の識別子を受け付け、当該支払の取引ＩＤ５０１＝「ＴＸ３００」に関連する取引ＩＤ５０１として「ＴＸ３１０」を生成して、トークン分散台帳５００へエントリを追加する。
【００９５】
そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ１０」を格納し、対象取引５０６に支払のエントリの取引ＩＤ５０１＝「ＴＸ３００」を格納して処理を終了する。
【００９６】
一方、ステップＳ２２で支払人が代表者でない場合には、ステップＳ２６でコミュニティ決済実行装置２００がコミュニティ管理テーブル７００を参照し、受取人５０４（支払要求を発行したコミュニティ決済要求装置１００の運用者）が電子債権管理システム３００の利用契約を有するか否かを判定する。利用契約がある場合にはステップＳ２７へ進み、ない場合にはステップＳ２９へ進む。
【００９７】
ステップＳ２７では、コミュニティ決済実行装置２００が、電子債権管理システム３００に対して、代表者以外の支払人に債務が発生した記録（譲渡記録）を依頼（代理請求）する。この場合の処理は、代表者（または他の参加者）から当該受取人へ債権を譲渡することになる。
【００９８】
ステップＳ２８では、コミュニティ決済実行装置２００は、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、譲渡記録の識別子を受け付け、当該支払の取引ＩＤ５０１に関連する新たな取引ＩＤ５０１を生成してトークン分散台帳５００へエントリを追加する。
【００９９】
そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子を格納し、対象取引５０６に支払のトランザクションの取引ＩＤ５０１を格納して処理を終了する。
【０１００】
上記ステップＳ２６の判定で、受取人に電子債権管理システム３００の利用契約がない場合のステップＳ２９では、コミュニティ決済実行装置２００は、当該支払人へ保証を付与可能か否かを判定する。この処理は、支払期日や金融機関の取引履歴や与信の履歴と所定の基準に基づいて、コミュニティ決済実行装置２００が保証を付与するか否かを決定する。保証を付与する場合にはステップＳ３０へ進み、付与しない場合にはステップＳ３７へ進む。
【０１０１】
ステップＳ３０では、トークンの割引を行うために、コミュニティ決済実行装置２００が、信用スコアテーブル９００を参照して、当該支払人の信用のスコアから支払額に対する割引額を算出する。次に、ステップＳ３１では、コミュニティ決済実行装置２００が、当該トークンを金融機関の持分と、受取人の持分に分割し、分割の内容を登録するように電子債権管理システム３００へ依頼（代理請求）する。
【０１０２】
なお、トークンの価値は、割引額を金融機関の持分とし、支払額から割引額を差し引いた残余を受取人の持分とする。
【０１０３】
なお、トークンの分割は、受取人が当該トークンの支払期日前に換金する場合には、金融機関と受取人の２者で当該トークンが分割され、受取人が当該トークンの支払期日前に他の受取人へ送金する場合には、金融機関と受取人で分割されてから、受取人から他の受取人への譲渡が行われる。
【０１０４】
ステップＳ３２では、コミュニティ決済実行装置２００が、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、分割記録の識別子「Ｄ２０、Ｄ２１、Ｄ２２」を受け付け、当該保証支払の取引ＩＤ５０１＝「ＴＸ４００」に関連する取引ＩＤ５０１として「ＴＸ４１０」を生成し、トークン分散台帳５００へエントリを追加する。
【０１０５】
そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ２０、Ｄ２１、Ｄ２２」を格納し、対象取引５０６に保証支払のトランザクション（取引ＩＤ５０１）「ＴＸ４００」を格納する。
【０１０６】
ステップＳ３３では、上記分割したトークンに受取人への譲渡が含まれるか否かを判定する。受取人が存在する場合には譲渡であるのでステップＳ３４へ進み、そうでない場合にはステップＳ３７へ進む。
【０１０７】
ステップＳ３４では、トークンの譲渡を行うために、コミュニティ決済実行装置２００が、受取人宛の譲渡の内容を登録（譲渡記録）するように電子債権管理システム３００へ依頼（代理請求）する。
【０１０８】
ステップＳ３５では、コミュニティ決済実行装置２００が、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、譲渡記録の識別子「Ｄ２２」を受け付け、当該支払の取引ＩＤ５０１＝「ＴＸ４００」に関連する取引ＩＤ５０１として「ＴＸ４２０」を生成し、トークン分散台帳５００へエントリを追加する。
【０１０９】
そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ２２」を格納し、対象取引５０６に保証支払のトランザクション（取引ＩＤ５０１）「ＴＸ４００」を格納する。
【０１１０】
次に、ステップＳ３６では、コミュニティ決済実行装置２００が、支払人（金融機関Ｂ）から受取人（企業Ｚ）への保証付きの支払をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、当該保証付き支払の取引ＩＤ５０１として「ＴＸ５００」を生成し、トークン分散台帳５００へエントリを追加する。そして、コミュニティ決済実行装置２００は、当該エントリの保証人５０８に「金融機関Ｂ」を格納し、支払人５０３に「金融機関Ｂ」、受取人５０４に「企業Ｚ」を格納する。
【０１１１】
一方、ステップＳ３３の判定で、譲渡ではない場合のステップＳ３７では、支払人の債務が抹消されるので、トークンの抹消を行うために、コミュニティ決済実行装置２００が、取引ＩＤ５０１が「ＴＸ４００」の保証付き支払を抹消するように電子債権管理システム３００へ依頼（代理請求）する。
【０１１２】
ステップＳ３８では、コミュニティ決済実行装置２００が、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、抹消記録の識別子「Ｄ２１」を受け付け、当該支払の取引ＩＤ５０１＝「ＴＸ４００」に関連する取引ＩＤ５０１として「ＴＸ４３０」を生成し、トークン分散台帳５００へエントリを追加する。
【０１１３】
そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ２１」を格納し、対象取引５０６に保証支払のトランザクション（取引ＩＤ５０１）「ＴＸ４００」を格納する。
【０１１４】
上記処理によって、トークンの支払、譲渡、分割、抹消がトークン分散台帳５００に記録され、債務（債権）の移動や変更が発生する度に電子債権管理システム３００に変更の内容が登録され、決済システムはトークンの価値を債務者及び債権者に保証することができる。
【０１１５】
また、上記の処理によって、支払者がトークンコミュニティの代表者ではなく、かつ、受取人５０４が電子債権管理システム３００の利用契約を有していない場合には、支払を実行する金融機関で割引を実行し、支払人に代わって当該金融機関が債務を担保することができる。これにより、電子債権管理システム３００の利用契約がない受取人に対してもトークンの価値を法定通貨と同様に保証することが可能となるのである。
【０１１６】
図８は、トークン換金要求処理の一例を示すフローチャートである。この処理は、企業のコミュニティ決済要求装置１００のトークン換金要求プログラム１２０が、利用者からトークン換金要求を受け付けると開始される。
【０１１７】
コミュニティ決済要求装置１００は、入力装置１０３からトークンの換金要求を受け付ける（Ｓ４１）。コミュニティ決済要求装置１００は、換金要求から取引ＩＤ５０１（またはトークン名）と金額と利用者名（参加者名７０３）を取得する。
【０１１８】
コミュニティ決済要求装置１００は、コミュニティ管理テーブル７００を参照して、換金要求の利用者が電子債権管理システム３００の利用契約の有無を判定する（Ｓ４２）。コミュニティ決済要求装置１００は、利用契約がある場合にはステップＳ４３へ進み、利用契約がない場合にはステップＳ４４へ進む。
【０１１９】
ステップＳ４３では、コミュニティ決済要求装置１００が、取引内容５０２を「換金」としたトークンの受け渡しをトークン分散台帳５００に追加する。一方、ステップＳ４３では、コミュニティ決済要求装置１００が、取引内容５０２を「保証付換金」としたトークンの受け渡しをトークン分散台帳５００に追加する。「保証付換金」の場合、コミュニティ決済要求装置１００は、トークン分散台帳５００の保証人５０８に金融機関の名称（または識別子）を格納する。
【０１２０】
図１３では、取引ＩＤ５０１＝「ＴＸ６００」に受取人５０４が「金融機関Ｃ」の保証付換金が登録され、保証人５０８が「金融機関Ｂ」であることを示している。
【０１２１】
図９は、トークン換金受付処理の一例を示すフローチャートである。
【０１２２】
この処理は、金融機関のコミュニティ決済実行装置２００のトークン換金受付プログラム２３０が、トークン分散台帳５００に新たな換金要求を検出したときに開始される。
【０１２３】
コミュニティ決済実行装置２００は、トークン分散台帳５００から新たな換金のエントリを検出し、換金対象のトークンの支払人５０３と受取人５０４及び取引ＩＤ５０１（またはトークン名）を読み込む（Ｓ５１）。
【０１２４】
そして、コミュニティ決済実行装置２００は、口座管理テーブル８００を参照して受取人５０４が自行の口座を保有しているか否かを判定する（Ｓ５２）。受取人５０４が自行の口座を保有している場合にはステップＳ５３へ進み、そうでない場合には処理を終了する。
【０１２５】
ステップＳ５３では、コミュニティ決済実行装置２００が、コミュニティ管理テーブル７００を参照して受取人５０４が電子債権管理システム３００の利用契約を有するか否かを判定する。受取人５０４が電子債権管理システム３００の利用契約を有する場合にはステップＳ５４へ進み、そうでない場合にはステップＳ５９へ進む。
【０１２６】
ステップＳ５４では、コミュニティ決済要求装置１００が、トークン分散台帳５００を参照して、換金対象のトークンの記録ＩＤ５０７に基づいて、当該トークンを発行した金融機関を特定し、当該金融機関へトークンの換金を申し込む。
【０１２７】
換金の申込みは、コミュニティ決済実行装置２００が、トークン分散台帳５００へ新たな換金（交換）要求を追加することで、発行元の金融機関に通知する。例えば、図１３の取引ＩＤ５０１が「ＴＸ８００」では、取引内容５０２が「交換」で、支払人５０３が「金融機関Ｂ」で、受取人５０４が「金融機関Ａ」のトランザクションが追加される。
【０１２８】
そして、ステップＳ５５では、コミュニティ決済実行装置２００が、電子債権管理システム３００に対して、換金要求を受け付けた金融機関で債務が抹消した記録（抹消記録）の追加を依頼（代理請求）する。
【０１２９】
ステップＳ５６では、コミュニティ決済実行装置２００は、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。
【０１３０】
コミュニティ決済実行装置２００は、代理請求の応答として、抹消記録の識別子「Ｄ２２」を受け付け、当該支払の取引ＩＤ５０１＝「ＴＸ８００」に関連する取引ＩＤ５０１として「ＴＸ８１０」を生成して、トークン分散台帳５００へエントリを追加する。
【０１３１】
そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ２２」を格納し、対象取引５０６に支払のトランザクション（取引ＩＤ５０１）「ＴＸ８００」を格納する。
【０１３２】
次に、コミュニティ決済実行装置２００は、トークンを発行した金融機関からの入金を検知すると（Ｓ５７）、換金要求を申し込んだ利用者の口座へ入金し、処理を終了する（Ｓ５８）。
【０１３３】
上記ステップＳ５３の判定で、換金要求の申込者が電子債権管理システム３００の利用契約を有していない場合、ステップＳ５９へ進んで、コミュニティ決済実行装置２００が、トークンの発行元金融機関に対して保証付きの換金を申し込む。トークンに対する債務の保証は、当該換金要求を受け付けたコミュニティ決済実行装置２００を運用する金融機関が保証人となる。なお、換金の申込みは、上述したように、コミュニティ決済実行装置２００が、トークン分散台帳５００へ新たな換金要求を追加することで、発行元の金融機関に通知する。
【０１３４】
例えば、図１３の取引ＩＤ５０１が「ＴＸ７００」では、取引内容５０２が「交換」で、支払人５０３が「金融機関Ｃ」で、受取人５０４が「金融機関Ａ」のエントリが追加される。このエントリでは、換金要求を受け付けた金融機関Ｂが債務を保証するので、保証人５０８に「金融機関Ｂ」が登録される。その後は、上記と同様に電子債権管理システム３００に抹消登録を依頼し、金融機関Ａからの入金を申込者の口座へ入金する。
【０１３５】
上記処理によって、電子債権管理システム３００の利用契約の有無にかかわらず、トークンを換金して申込者の口座へ入金することが可能となる。
【０１３６】
以上のように、本実施例１の決済システムでは、電子債権管理システム３００に参加しない企業（運用者）が存在するコミュニティでも、電子的な決済媒体（トークン）の価値を保証した上で決済を実現することができる。なお、上記実施例１では、電子的な決済媒体としてトークンを用いる例を示したが、これに限定されるものではなく、電子的な決済媒体として仮想通貨やポイントなどを用いることができる。
【０１３７】
また、本実施例１では、トークンの価値を法定通貨で保証する例を示したが、これに限定されるものではなく、例えば、金などの貴金属でトークンの価値を保証することができる。
【０１３８】
また、本実施例１では、トークン分散台帳５００や、トークン残高管理テーブル６００や、コミュニティ管理テーブル７００をテーブルとした例を示したが、これらの情報はテーブルに限定されるものではなく、スキーマレスのデータとして格納されてもよい。
【０１３９】
また、本実施例１では、トークン分散台帳５００をトークンコミュニティの参加者で共有する例を示したが、情報の閲覧に制限を設けてもよい。例えば、支払や換金の情報は、支払人と受取人の当事者及び金融機関に閲覧を許可し、他の参加者の閲覧を禁止することができる。
【０１４０】
なお、本実施例１では、トークンコミュニティを単一のコミュニティで構成する例を示したが、これに限定されるものではない。例えば、トークン分散台帳５００を共有範囲が異なる複数のサブコミュニティを設定し、取引内容の開示範囲に合わせてサブコミュニティを使い分けることができる。
【０１４１】
また、上記実施例１では、企業間のサプライチェーンに本発明を適用する例を示したが、これに限定されるものではない。資金の移動が必要なコミュニティであれば、本実施例１の決済システムを適用することができる。
【０１４２】
また、上記実施例１では、金融機関にコミュニティ決済実行装置２００を配置する例を示したが、これに限定されるものではない。例えば、トークンコミュニティへ法定通貨を支払い可能で、かつ、トークンに対応する債権の発生から消滅までを電子債権管理システム３００へ依頼可能な団体や組織あるいは決済サービス会社であればよい。
【実施例２】
【０１４３】
図１５は、実施例２を示し、トークン分散台帳５００の一例を示す図である。本実施例２では、トークン分散台帳５００にブロックチェーンを採用し、図１３に示したひとつのエントリを、ひとつのトランザクションとして、複数のトランザクションとハッシュ値でブロック５１１、５１２、５１３を構成する例を示す。その他の構成については、前記実施例１と同様である。
【０１４４】
各ブロック５１１〜５１３では、ブロック内の複数のトランザクションの内容と直前のブロックのハッシュ値から当該ブロックのハッシュ値が演算されて、トランザクションの内容とハッシュ値が各ブロック５１１〜５１３でそれぞれ保持される。
【０１４５】
ブロックチェーンの技術については、周知の技術であり、Ｐ２Ｐネットワークと、コンセンサスアルゴリズムと、スマートコントラクトと、偽造防止及び暗号化技術を組み合わせた分散型の台帳管理システムである。
【０１４６】
本実施例２では、ブロックチェーンの特性のうち、非中央集権性と、透明性と、耐改竄性と、耐障害性と、自動実行（自動取引）を利用する例を示す。
【０１４７】
まず、非中央集権性は、特定の参加者がデータの管理を独占することを禁止して、ブロックチェーンに参加するそれぞれの参加者がデータの管理を可能にすることを示す。
【０１４８】
次に、透明性は、各参加者が生成した情報を、全ての参加者に公開し、全ての参加者で共有することを示す。トークンコミュニティに参加する参加者は、全ての情報を閲覧することができ、記録された情報の一貫性が保証されている。
【０１４９】
耐改竄性は、各参加者でトランザクションを生成し、各トランザクションを電子署名とハッシュ値に基づき鎖状に繋ぐことで、データの改竄を抑止する。また、各参加者が生成した情報を公開することにより、データの改竄に対する意欲を抑制することができる。
【０１５０】
耐障害性は、各参加者がデータまたはデータの複製をブロックチェーンに参加する参加者で保持することで、一部の参加者に障害が発生しても、データが毀損や消失を防止することである。
【０１５１】
自動実行（自動取引）については、複数の必要条件に関する判定結果が集約された後に取引や情報の発行を実行することを示す。あるいは、発行された情報についての合意を、効率的に行うことを示す。
【０１５２】
なお、上記実施例２では、トランザクションの内容と、直前のブロックのハッシュ値から当該ブロックのハッシュ値を算出する例を示したが、これに限定されるものではない。
【０１５３】
例えば、各ブロック内にはトランザクションの内容に代わって、トランザクションの内容のハッシュ値とトランザクションの識別子（取引ＩＤ５０１）を格納するようにしてもよい。この場合、直前のブロックのハッシュ値と、トランザクションの内容のハッシュ値とトランザクションの識別子から当該ブロックのハッシュ値を算出すればよい。
【０１５４】
そして、トランザクションの内容は、各参加者で保持すればよい。または、各参加者のトランザクションの内容を格納する装置を設けてもよい。この場合では、各トランザクションの内容を非公開とすることができ、各参加者間での取引の内容は限定された参加者に提供することができる。
【実施例３】
【０１５５】
図１６は、実施例３を示し、コミュニティ決済要求装置１００及びコミュニティ決済実行装置２００を、トークン分散台帳５００を管理するノードとして扱う例を示す。
【０１５６】
企業Ｘノード１０００Ｘは、実施例１のコミュニティ決済要求装置１００−Ｘ（図２参照）に相当し、企業Ｙノード１０００Ｙは、実施例１のコミュニティ決済要求装置１００−Ｙに相当する。金融機関Ａノード２０００−Ａは、実施例１のコミュニティ決済実行装置２００−Ａ（図２参照）に相当し、金融機関Ｂノード２０００−Ｂは、実施例１のコミュニティ決済実行装置２００−Ｂ（図２参照）に相当する。
【０１５７】
各ノードの構成は同一であるので、以下では、企業Ｘノード１０００Ｘについて説明し、他のノードの説明を省略する。図１７は、企業Ｘノード１０００Ｘの一例を示すブロック図である。
【０１５８】
企業Ｘノード１０００−Ｘは、トークン分散台帳５００の複製を保持し、当該トークン分散台帳５００から各トークンの最新の残高を算出してトークン残高管理テーブル６００に格納する。そして、トークン分散台帳５００は、前記実施例２で示したブロックチェーンで構成される。なお、トークン分散台帳５００のマスタは、金融機関Ａのトークン分散台帳５００とし、他のノードは複製を保持する。
【０１５９】
上記の構成により、耐障害性と耐改竄性を備えた決済システムを提供することができる。
【０１６０】
＜まとめ＞
以上のように、上記実施例１〜３の決済システムは、以下の構成とすることができる。
【０１６１】
（１）プロセッサ（演算装置１０２）とメモリ（１０１）を有する決済要求装置（コミュニティ決済要求装置１００）と、プロセッサ（演算装置２０２）とメモリ（２０１）を有する決済実行装置（コミュニティ決済実行装置２００）と、電子的な債権または債務を管理する電子債権管理装置（電子債権管理システム３００）と、を有する決済システムであって、前記決済要求装置（１００）は、電子的な決済媒体（トークン）による支払要求を発行し、前記決済実行装置（２００）は、前記決済媒体（トークン）による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置（３００）へ記録させ、前記決済媒体を受取人（５０４）へ送信する。
【０１６２】
上記構成により、電子債権管理システム３００に参加しない企業（運用者）が存在するコミュニティでも、コミュニティ決済実行装置２００（決済実行装置）がトークン（電子的な決済媒体）の価値を電子債権管理システム３００で保証した上で決済を実現することができる。
【０１６３】
（２）上記（１）に記載の決済システムであって、前記決済実行装置（２００）は、前記決済媒体（トークン）に対応する価値の債務を前記電子債権管理装置（３００）へ記録させることで、前記決済媒体の価値を保証する。
【０１６４】
上記構成により、コミュニティ決済実行装置２００（決済実行装置）は、発生したトークン（決済媒体）の債務を電子債権管理システム３００へ連携させることで、トークン（決済媒体）を法定通貨に対応付けて価値を保証することができる。
【０１６５】
（３）上記（１）に記載の決済システムであって、前記決済実行装置（２００）は、前記受取人が前記電子債権管理装置（３００）を利用できない場合には、当該決済実行装置（２００）の運用者（金融機関）の保証を付与して前記受取人へ前記決済媒体（トークン）を送信する。
【０１６６】
上記構成により、トークンの受取人５０４が電子債権管理システム３００を利用できない場合でも、コミュニティ決済実行装置２００を運用する金融機関（運用者）の保証を付与することでトークンの流通が可能となる。
【０１６７】
（４）上記（３）に記載の決済システムであって、前記決済実行装置（２００）は、前記受取人が前記電子債権管理装置（３００）を利用できない場合には、当該決済実行装置（２００）で割引を行って、当該割引の残余を前記受取人への決済媒体（トークン）の価値とする。
【０１６８】
上記構成により、トークンの受取人５０４が電子債権管理システム３００を利用できない場合には、支払要求を受け付けたコミュニティ決済実行装置２００（決済実行装置）の金融機関（運用者）が割引を行い、支払額から割引額を差し引いた残余を受取人５０４へのトークンとすることで、金融機関はリスクの対価を受け取ることができる。
【０１６９】
（５）上記（１）に記載の決済システムであって、前記決済要求装置（１００）は、前記決済媒体（トークン）の換金要求を発行し、前記決済実行装置（２００）は、前記換金要求を受け付けて、前記換金要求を申し込んだ決済要求装置（１００）の運用者が前記電子債権管理装置（３００）を利用可能か否かを判定し、利用できない場合には、前記換金要求を受け付けた決済実行装置（２００）の運用者を保証人として、前記決済媒体（トークン）の発行元へ通知する。
【０１７０】
上記構成により、受取人５０４や支払人５０３の電子債権管理システム３００の利用契約の有無にかかわらず、トークンを換金して申込者の口座へ入金することが可能となる。
【０１７１】
（６）上記（１）に記載の決済システムであって、前記決済要求装置（１００）と決済実行装置（２００）は、前記決済媒体（トークン）の授受を記録する分散台帳（トークン分散台帳５００）を共有し、前記決済要求装置（１００）は、前記支払要求を前記分散台帳（５００）へ書き込むことで、前記支払要求を前記決済実行装置（２００）へ通知する。
【０１７２】
上記構成により、トークン分散台帳５００を介してトークン（決済媒体）の流通を電子債権管理システム３００へ反映させて、債務の発生、譲渡、分割、抹消を管理することが可能となる。
【０１７３】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。
【０１７４】
また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【０１７５】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【０１７６】
１００  コミュニティ決済要求装置
１１０  トークン支払要求プログラム
１２０  トークン換金要求プログラム
２００  コミュニティ決済実行装置
２１０  トークン発行プログラム
２２０  トークン支払受付プログラム
２３０  トークン換金受付プログラム
３００  電子債権管理システム
５００  トークン分散台帳
６００  トークン残高管理テーブル
７００  コミュニティ管理テーブル
【図１】
2020144526.tif 000003
【図２】
2020144526.tif 000004
【図３】
2020144526.tif 000005
【図４】
2020144526.tif 000006
【図５】
2020144526.tif 000007
【図６】
2020144526.tif 000008
【図７】
2020144526.tif 000009
【図８】
2020144526.tif 000010
【図９】
2020144526.tif 000011
【図１０】
2020144526.tif 000012
【図１１】
2020144526.tif 000013
【図１２】
2020144526.tif 000014
【図１３】
2020144526.tif 000015
【図１４】
2020144526.tif 000016
【図１５】
2020144526.tif 000017
【図１６】
2020144526.tif 000018
【図１７】
2020144526.tif 000019