知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024095433
(43)【公開日】2024-07-10
(54)【発明の名称】取引処理プログラム、取引処理方法および情報処理装置
(51)【国際特許分類】
G06Q 20/38 20120101AFI20240703BHJP
G06Q 20/40 20120101ALI20240703BHJP
【ＦＩ】
G06Q20/38 310
G06Q20/40 300
【審査請求】未請求
【請求項の数】7
【出願形態】ＯＬ
(21)【出願番号】P 2022212717
(22)【出願日】2022-12-28
(71)【出願人】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】西間木 哲
【テーマコード（参考）】
5L020
5L055
【Ｆターム（参考）】
5L020AA72
5L055AA72
(57)【要約】
【課題】特定の時間を指定した取引を適正に行う。
【解決手段】取引処理プログラムは、金融資産の分散台帳を管理する各ノードのコンピュータに、金融資産の移転元アカウントからの要求に基づき、金融資産の移転を承認する承認トランザクションを分散台帳に登録する処理と、登録された承認トランザクションの中の、自ノードが移転先アカウントを管理する承認トランザクションについて、自ノードが管理する管理時刻が承認トランザクションに含まれる移転時刻に到達後、承認トランザクションの検証を第１の他ノードに依頼し、第１の他ノードの検証結果に基づいて承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行する処理と、第２の他ノードから承認トランザクションの検証依頼を受け付けた場合、承認トランザクションに含まれる移転時刻が管理時刻より後であるか否かの検証結果を第２の他ノードに返信する処理とを実行させる。
【選択図】図１
【解決手段】取引処理プログラムは、金融資産の分散台帳を管理する各ノードのコンピュータに、金融資産の移転元アカウントからの要求に基づき、金融資産の移転を承認する承認トランザクションを分散台帳に登録する処理と、登録された承認トランザクションの中の、自ノードが移転先アカウントを管理する承認トランザクションについて、自ノードが管理する管理時刻が承認トランザクションに含まれる移転時刻に到達後、承認トランザクションの検証を第１の他ノードに依頼し、第１の他ノードの検証結果に基づいて承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行する処理と、第２の他ノードから承認トランザクションの検証依頼を受け付けた場合、承認トランザクションに含まれる移転時刻が管理時刻より後であるか否かの検証結果を第２の他ノードに返信する処理とを実行させる。
【選択図】図１
【特許請求の範囲】
【請求項1】
金融資産にかかる分散台帳を管理する各ノードのコンピュータに、
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行させることを特徴とする取引処理プログラム。
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行させることを特徴とする取引処理プログラム。
【請求項2】
前記発行する処理は、前記第１の他ノードの検証結果に基づいて前記要求トランザクションの発行を否定した場合、所定時間経過後に、前記承認トランザクションの検証を再依頼する、
ことを特徴とする請求項１に記載の取引処理プログラム。
ことを特徴とする請求項１に記載の取引処理プログラム。
【請求項3】
前記発行する処理は、前記登録された承認トランザクションの中の、第３の他ノードが前記移転先アカウントを管理する承認トランザクションについて、前記管理時刻が前記承認トランザクションに含まれる移転時刻に到達してから所定時間経過後に当該承認トランザクションにかかる要求トランザクションが発行されていない場合、前記承認トランザクションの検証を第４の他ノードに依頼し、当該第４の他ノードの検証結果に基づいて前記承認トランザクションにかかる要求トランザクションを前記第３の他ノードを代理して発行する、
ことを特徴とする請求項１に記載の取引処理プログラム。
ことを特徴とする請求項１に記載の取引処理プログラム。
【請求項4】
前記発行する処理は、前記登録された承認トランザクションの中の、前記自ノードと同一のグループに属する前記第３の他ノードが前記移転先アカウントを管理する承認トランザクションについて、当該承認トランザクションにかかる要求トランザクションを前記第３の他ノードを代理して発行する、
ことを特徴とする請求項３に記載の取引処理プログラム。
ことを特徴とする請求項３に記載の取引処理プログラム。
【請求項5】
前記発行する処理は、前記検証を複数の前記第１の他ノードに依頼し、複数の前記第１の他ノードの検証結果に基づいて前記要求トランザクションを発行する、
ことを特徴とする請求項１に記載の取引処理プログラム。
ことを特徴とする請求項１に記載の取引処理プログラム。
【請求項6】
金融資産にかかる分散台帳を管理する各ノードのコンピュータが、
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行することを特徴とする取引処理方法。
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行することを特徴とする取引処理方法。
【請求項7】
金融資産にかかる分散台帳を管理する情報処理装置であって、
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行する演算装置を含むことを特徴とする情報処理装置。
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行する演算装置を含むことを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、取引処理プログラム、取引処理方法および情報処理装置に関する。
【背景技術】
【0002】
近年、銀行や証券会社が仲介を行う中央集権的な金融とは異なる分散型金融のＤｅＦｉ（Decentralized Finance）が注目されている。ＤｅＦｉでは、中央管理者を置かずに、コミュニティ全体で取引の安全性を保証する仕組みのため、取引仲介の無人化や自律運用による市場流動性の向上が期待されている。
【0003】
ＤｅＦｉのシステム構築にあたっては、ブロックチェーン（以下、「ＢＣ」、「分散台帳」とも称する）の適用が考えられており、その一つの取り組みとして、ＢＣ上で発行されるトークンを用いた金融システム（以下、「取引システム」とも称する）の実現に向けた検討が始まっている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】米国特許出願公開第２０２２／００５８６４１号明細書
【特許文献2】特表２０１９－５１４０８９号公報
【特許文献3】特表２０２０－５２４４２５号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
一般に、金融システムでは、債券の償還や配当の支払いなどで日時を指定し、金銭と債券の移転が行われる。一方、ブロックチェーン（ＢＣ）は、複数ノードが非同期に処理を実行することが前提となっているため、特定の時間を指定した処理や取引を適正に行うことが難しいといった点に、ＢＣを用いた金融システム実現への障壁がある。
【0006】
１つの側面では、特定の時間を指定した取引を適正に行うことを可能とする取引処理プログラム、取引処理方法および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
１つの案では、取引処理プログラムは、金融資産にかかる分散台帳を管理する各ノードのコンピュータに、登録する処理と、発行する処理と、返信する処理とを実行させる。登録する処理は、金融資産の移転元アカウントからの要求に基づき、移転元アカウントと、移転先アカウントと、金融資産の移転量と、金融資産の移転時刻とを含む、金融資産の移転を承認する承認トランザクションを分散台帳に登録する。発行する処理は、登録された承認トランザクションの中の、自ノードが移転先アカウントを管理する承認トランザクションについて、自ノードが管理する管理時刻が承認トランザクションに含まれる移転時刻に到達後、承認トランザクションの検証を第１の他ノードに依頼し、第１の他ノードの検証結果に基づいて承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行する。返信する処理は、第２の他ノードから承認トランザクションの検証依頼を受け付けた場合、承認トランザクションに含まれる移転時刻が管理時刻より後であるか否かの検証結果を第２の他ノードに返信する。
【発明の効果】
【0008】
特定の時間を指定した取引を適正に行うことができる。
【図面の簡単な説明】
【0009】
【発明を実施するための形態】
【0010】
以下、図面を参照して、実施形態にかかる取引処理プログラム、取引処理方法および情報処理装置を説明する。実施形態において同一の機能を有する構成には同一の符号を付し、重複する説明は省略する。なお、以下の実施形態で説明する取引処理プログラム、取引処理方法および情報処理装置は、一例を示すに過ぎず、実施形態を限定するものではない。また、以下の各実施形態は、矛盾しない範囲内で適宜組みあわせてもよい。
【0011】
（従来技術と課題）
ブロックチェーンにおける時間を指定した取引の仕組みとしてＥｔｈｅｒｅｕｍ Ａｌａｒｍ Ｃｌｏｃｋ（https://www.ethereum-alarm-clock.com/）がある。このＥｔｈｅｒｅｕｍ Ａｌａｒｍ Ｃｌｏｃｋでは、まず時間指定のトランザクションを管理するＴｉｍｅノードに取引を登録する。その後、Ｔｉｍｅノードで逐次、現在時刻と取引リストを確認し、指定時間となった取引のトランザクションを発行することで、指定時間に取引を実行する。
ブロックチェーンにおける時間を指定した取引の仕組みとしてＥｔｈｅｒｅｕｍ Ａｌａｒｍ Ｃｌｏｃｋ（https://www.ethereum-alarm-clock.com/）がある。このＥｔｈｅｒｅｕｍ Ａｌａｒｍ Ｃｌｏｃｋでは、まず時間指定のトランザクションを管理するＴｉｍｅノードに取引を登録する。その後、Ｔｉｍｅノードで逐次、現在時刻と取引リストを確認し、指定時間となった取引のトランザクションを発行することで、指定時間に取引を実行する。
【0012】
また、ブロックチェーンにおける時間を指定した取引の仕組みにおいては、時間暗号を用いたスケジュール実行方式（特表２０２０－５２４４２５号公報、"ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法"）がある。この方式は、トークンの受け手に対して、復号化に一定時間を要するタイムロックパズルを解かせ、その暗号が復号化できた時に、トークン移転のトランザクション発行に必要な秘密鍵を公開し、資金の移動を可能にする。
【0013】
上記のブロックチェーンにおける時間を指定した取引の仕組みでは、ブロックチェーンの内外にトランザクションの発行を管理するスケジューリング機能を持たせることで、指定時間での取引を実現している。スケジューリング機能により、処理を実行することは計算機処理では一般的であるが、スケジューリング機能により実行された時間を信頼することが前提の処理となる。そのため、スケジューリング機能を悪意のあるユーザに攻撃された際に、他ノードは、その取引が指定時間になっていなくてもトランザクションの処理を履行し、取引が承認されてしまうことがある。
【0014】
ここでの問題点は、トリガとなった時刻データを全面的に信用した処理のため、取引するＢＣのノードでの時間の検証ができていないことにある。特定のノードが持つ時間情報の信用を前提とした取引は脆弱性が高まるため、ＢＣ全体として取引を判定することが望ましい。
【0015】
上記の問題点から、「ブロックチェーンにおける時間指定取引において、指定時間外にトランザクションが発行された場合の取引を棄却し、指定した時間指定時間での取引の実行と結果を保証すること」が本実施形態が解決する課題の一つである。
【0016】
トランザクションを検証するノードで取引を実行する時間を検証する点においては、ＵＳ２０２２－００５８６４１，"DEVICE AND METHOD FOR PROCESSING DATA OF TRANSACTIONS BASED ON BLOCK CHAIN, AND STORAGE MEDIUM "のように、ブロックデータの最新のタイムスタンプを用いて検証する従来技術がある。
【0017】
しかしながら、ブロックデータのタイムスタンプは、マイナーがブロックデータを記録した時間であり、そのタイムスタンプの記録における検証では、前のブロックのタイムスタンプよりも後の時刻か否かの判定にとどまる。ブロックチェーンの種類により、前のブロックのタイムスタンプよりも一定時間以上の差がないことなどの検証がされる場合もあるが、正確性の面では、十分な検証はない。そのため、ブロックデータのタイムスタンプと現在の時刻では大幅にずれが生じ、本来実行したい時刻にトランザクションが実行されることを十分に保証できない点で、本実施形態が解決する課題の一つを解決するものではない。
【0018】
ここで、ブロックチェーンのおける時間情報の扱い方について説明する。ブロックチェーンに参加しているノードは、それぞれがタイムサーバーと同期する等により、現在の時間を設定している。
【0019】
そのため、多くのノードは比較的正確な時間で動作している（完全に正確な時間ではないが、ミリ秒～数秒程度のずれの範疇で正確な時間を設定しいている）。ただし、完全にノード同士の時刻が同期されているわけではないため、各々のノードで多少の時刻のずれが発生している。
【0020】
また、悪意のあるユーザなどは、あえて時間をずらして設定することもありえる。Ｂｉｔｃｏｉｎの場合は、マイナーが故意に時間をずらしたとしても、よほどシステム上で異常な時間で設定されていない限りはそのブロックは容認されてしまう（なぜなら時間のずれがあることが前提のため、どのノードも正確であることを保証できないため）。
【0021】
以上のことからブロックチェーンにおいては、共通の時間情報を参照して処理を実行することは難しい。上記のＵＳ２０２２－００５８６４１のように、ブロックデータのタイムスタンプは、全ノードで共有された時間情報であるが、その時間が正確である保証はない点で、送り手の指示した時間通りに取引が実行されない可能性がある。
【0022】
（実施形態の概要）
図１は、実施形態の概要を説明する説明図である。図１に示すように、実施形態にかかる取引システムは、金融資産（以下、「トークン」とも称する）に関するＢＣ台帳を共有して管理する複数のＢＣノード１ａ～１ｄを有する。このＢＣノード１ａ～１ｄそれぞれは、特定の時間を指定したトランザクションに基づく取引を実行する時間取引実行部１０を有する。なお、以下の説明において、ＢＣノード１ａ～１ｄそれぞれを特に区別しない場合は、単にＢＣノード１と表記する。
図１は、実施形態の概要を説明する説明図である。図１に示すように、実施形態にかかる取引システムは、金融資産（以下、「トークン」とも称する）に関するＢＣ台帳を共有して管理する複数のＢＣノード１ａ～１ｄを有する。このＢＣノード１ａ～１ｄそれぞれは、特定の時間を指定したトランザクションに基づく取引を実行する時間取引実行部１０を有する。なお、以下の説明において、ＢＣノード１ａ～１ｄそれぞれを特に区別しない場合は、単にＢＣノード１と表記する。
【0023】
ＢＣノード１ａは、金融資産の移転元アカウント（以下、「送り手」とも称する）の一例である「ｕｓｅｒＡ」のアカウントを管理するノード（以下、「送り手ノード」とも称する）である。ＢＣノード１ｂは、金融資産の移転先アカウント（以降、「受け手」とも称する）の一例である「ｕｓｅｒＢ」のアカウントを管理するノード（以下、「受け手ノード」とも称する）である。ＢＣノード１ｃ、１ｄは、「ｕｓｅｒＡ」、「ｕｓｅｒＢ」以外のアカウントを管理するノードである。
【0024】
実施形態にかかる取引システムにおいて、トークンの移転処理は、ブロックチェーン技術を活用したスマートコントラクトにより実現され、ブロックチェーンネットワークに参加したＢＣノード１ａ～１ｄの全ノードで実行および結果の検証が可能である。
【0025】
まず、送り手ノードのＢＣノード１ａでは、送り手（ｕｓｅｒＡ）の要求にもとづいて、金融資産の移転を承認（許可）するトランザクション（時間指定引き出し許可）を発行する（Ｓ１）。この発行されたトランザクションは、各ＢＣノードで承認された後に各ＢＣノードのＢＣ台帳に登録される（Ｓ２）。
【0026】
この時間指定の引き出し許可（approve()）には、送り手のアカウントの「from」、受け手のアカウントの「to」、引き出し許可するトークン量（移転量）の「amount」、引き出しが可能になる時間（移転時刻）の「date」が含まれる。この時間指定の引き出し許可では、「date」の時間以降に引き出し可能となることを表し、「date」の時間以前では、引き出しの取引は失敗することを表す。
【0027】
受け手ノードのＢＣノード１ｂでは、自ノードが管理する受け手（ｕｓｅｒＢ）に該当する時間指定の引き出し許可の取引に関して、自ノードのシステム時刻（管理時刻）が「date」の時間以後に、他ノードに対して時間指定の引き出し許可の取引の検証を依頼する。ＢＣノード１ｂでは、この検証結果にもとづいて引き出し要求のトランザクションを発行する（Ｓ３）。
【0028】
この引き出し要求のトランザクションには、引き出しを行う受け手のアカウントを表す「account」が含まれる。引き出し要求のトランザクションは、「account」のアカウントが現時点で引き出しが可能なトークンを検索し、トークン移転を実行するためのトランザクションとなる。
【0029】
時間指定の引き出し許可の取引について検証を行うノード（ＢＣノード１ａ、１ｃ、１ｄ）は、引き出し要求を基に、時間指定引き出し許可のリスト（引き出し要求に含まれる「account」に該当する時間指定の引き出し許可）をＢＣ台帳より抽出する。ついで、ＢＣノード１ａ、１ｃ、１ｄは、抽出した時間指定の引き出し許可をもとに下記の判定を行い、検証結果としてＢＣノード１ｂへ返信する（Ｓ４）。
・指定時間がノードのシステム時刻以降の引き出し許可がない場合は、引き出し要求のトランザクションは破棄（取引ＮＧ）とする。
・指定時間がノードのシステム時刻以降の引き出し許可がある場合は、引き出し許可の情報に基づいてトークンを移転（取引ＯＫ）とする。
・指定時間がノードのシステム時刻以降の引き出し許可がない場合は、引き出し要求のトランザクションは破棄（取引ＮＧ）とする。
・指定時間がノードのシステム時刻以降の引き出し許可がある場合は、引き出し許可の情報に基づいてトークンを移転（取引ＯＫ）とする。
【0030】
このように、実施形態にかかる取引システムでは、ブロックチェーンのトランザクションの検証の過程で取引の可否を各ノードの検証結果をもとに決定することで、指定時間外での取引は実行せず、指定の時間以降にトークンが移転できることを保証する。これらにより、実施形態にかかる取引システムでは、課題の一つである「ブロックチェーンにおける時間指定取引において、指定時間外にトランザクションが発行された場合の取引を棄却し、指定した時間指定時間での取引の実行と結果を保証すること」を解決し、時間を指定した安全な取引を実現する。
【0031】
なお、トークン移転の方法は、大きく分けて２つある。図２は、トークン移転方法の一例を説明する説明図である。
【0032】
図２に示すように、ケースＣ１は、送り手（ｕｓｅｒＡ）が送金トランザクションを実行する方法であり、ケースＣ２は、受け手（ｕｓｅｒＢ）が送金トランザクションを実行する方法である。
【0033】
ケースＣ１は、送り手がトランザクションを実行したタイミングですぐに送金が実行されるもので、店舗で支払いをするといった通常の送金では、その場で送金するため、こちらの方法が一般的に使われる。一方、ケースＣ２は、まず送り手側で引き出し可能なトークン量を指定する。その後、受け手側で引き出し許可された分だけトークンを移転するという方法である。引き出し許可という形で、トークンを予約状態にすることで、特定の条件を満たした時に受け手が引き出せるといった、条件付き送金に用いることが可能である。実施形態にかかる取引システムでは、ケースＣ２のやり方を基に実現する点が従来技術と異なる。
【0034】
（実施形態）
図３は、実施形態にかかる情報処理装置のハードウェア構成例を示すブロック図である。図３に示すように、情報処理装置１００は、ＰＣ（Personal Computer）等の一般的なコンピュータと同等のハードウェア構成であり、取引システムにおける各ノード、ホスト端末等に相当する。
図３は、実施形態にかかる情報処理装置のハードウェア構成例を示すブロック図である。図３に示すように、情報処理装置１００は、ＰＣ（Personal Computer）等の一般的なコンピュータと同等のハードウェア構成であり、取引システムにおける各ノード、ホスト端末等に相当する。
【0035】
具体的には、情報処理装置１００は、ＣＰＵ（Central Processing Unit）等の演算装置１０１、ＲＡＭ（Random Access Memory）等の主記憶装置１０２、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等の補助記憶装置１０３、ネットワークインターフェース１０４を有する。これら演算装置１０１、主記憶装置１０２、補助記憶装置１０３およびネットワークインターフェース１０４は、データバス１０５を介して接続されている。
【0036】
補助記憶装置１０３は、演算装置１０１と、演算装置１０１が実行時に参照する各種設定やＢＣ台帳などの各種データ１０２ｂとが格納される。情報処理装置１００の各種機能は、プログラム１０２ａとして記述されている。演算装置１０１は、プログラム１０２ａを主記憶装置１０２にロードして順次実行することで、各種機能を提供する。また、情報処理装置１００の各種機能は、クラウドコンピューティングにより、複数のコンピュータが協働して提供してもよい。また、情報処理装置１００は、ネットワークＮに接続されたネットワークインターフェース１０４を介して、ユーザ（またはユーザが操作するアプリ）や通信装置とメッセージを送受信することができる。
【0037】
なお、プログラム１０２ａは、補助記憶装置１０３に記憶されていなくてもよい。例えば、情報処理装置１００が読み取り可能な記憶媒体に記憶されたプログラム１０２ａを読み出して実行するようにしてもよい。情報処理装置１００が読み取り可能な記憶媒体は、例えば、ＣＤ－ＲＯＭやＤＶＤディスク、ＵＳＢ（Universal Serial Bus）メモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ、ハードディスクドライブ等が対応する。また、ネットワークＮに接続された外部装置にプログラム１０２ａを記憶させておき、情報処理装置１００がネットワークインターフェース１０４を介して外部装置からプログラム１０２ａを読み出して実行するようにしてもよい。
【0038】
図４は、実施形態にかかる取引システムの全体構成例を説明する説明図である。図４に示すように、実施形態にかかる取引システムは、前述したＢＣノード１ａ～１ｄの他、ホスト端末２ａ～２ｄおよびブロック生成ノード３を有する。この取引システムにおいて、ＢＣノード１ａ～１ｄ、ホスト端末２ａ～２ｄおよびブロック生成ノード３は、ＬＡＮ（Local Area Network）、インターネット等のネットワークＮを介して互いに通信可能に接続されている。
【0039】
なお、以下の説明において、ホスト端末２ａ～２ｄそれぞれを特に区別しない場合は、単にホスト端末２と表記する。図中のホスト端末２ａ～２ｄに記載された［］内の表記は、所有者（アカウント）が誰であるのかを示している。具体的には、ホスト端末２ａは、送り手Ｈ１」が所有する端末である。ホスト端末２ｂは、受け手Ｈ２が所有する端末である。ホスト端末２ｃ、２ｄは、送り手Ｈ１および受け手Ｈ２以外のアカウントである参加者Ｈ３が所有する端末である。
【0040】
同様に、図中のＢＣノード１ａ～１ｄに記載された［］内の表記は、各ノードがどのアカウントを管理しているかを示している。具体的には、ＢＣノード１ａは、送り手Ｈ１を管理するノードである。ＢＣノード１ｂは、受け手Ｈ２を管理するノードである。ＢＣノード１ｃ、１ｄは、参加者Ｈ３を管理するノードである。
【0041】
ホスト端末２は、送信部２０、受信部２１および操作・表示部２２を有する。送信部２０は、ネットワークＮを介してＢＣノード１に各種データを送信する処理部である。例えば、送信部２０は、送り手Ｈ１による金融資産の移転要求などの指示をＢＣノード１に通知する。
【0042】
受信部２１は、ネットワークＮを介してＢＣノード１から送信された各種データを受信する処理部である。例えば、受信部２１は、送り手Ｈ１による金融資産の移転要求等に対する応答をＢＣノード１より受信する。
【0043】
操作・表示部２２は、ユーザ（送り手Ｈ１、受け手Ｈ２、参加者Ｈ３）の操作入力の受け付けやユーザへの表示出力を行う処理部である。例えば、操作・表示部２２は、送り手Ｈ１による金融資産の移転内容を受け付ける。また、操作・表示部２２は、送り手Ｈ１より受け付けた移転内容に基づいた移転要求に対するＢＣノード１からの応答を表示出力する。
【0044】
ＢＣノード１は、時間取引実行部１０、トランザクション／ブロック処理部１１、システム時間管理部１２、受信部１３、送信部１４およびＢＣ台帳１５を有する。
【0045】
時間取引実行部１０は、前述した時間指定の引き出し許可に関する取引を実行する処理部である。トランザクション／ブロック処理部１１は、ブロックチェーン（ＢＣ）におけるトランザクションの発行やブロックの検証等の処理を行う処理部である。この時間取引実行部１０、トランザクション／ブロック処理部１１に関する処理の詳細は後述する。
【0046】
システム時間管理部１２は、ＢＣノード１のシステム時刻を管理する処理部である。具体的には、システム時間管理部１２は、ＲＴＣ（Real Time Clock）等の計時機能を有し、ＮＴＰ（Network Time Protocol）サーバ等と同期させたシステム時刻を計時している。システム時間管理部１２は、時間取引実行部１０等の要求に応じて計時しているシステム時刻を通知する。
【0047】
受信部１３は、時間取引実行部１０、トランザクション／ブロック処理部１１等の要求に応じて、ネットワークＮを介して他のノード（ＢＣノード、ブロック生成ノード３）等に各種データを受信する処理部である。送信部１４は、ネットワークＮを介して、ホスト端末２、他のノード（ＢＣノード、ブロック生成ノード３）等から通知されたデータを送信する処理部である。
【0048】
ＢＣ台帳１５は、ブロックチェーンに関するデータであり、各ＢＣノード１が共有して管理する金融資産に関する分散台帳である。
【0049】
ブロック生成ノード３は、発行されたトランザクションをブロック化し、各ノードに送信する処理を担当するノードである。ブロック生成ノード３は、送信部３０、受信部３１、システム時間管理部３２およびブロック生成部３３を有する。
【0050】
送信部３０は、ネットワークＮを介してＢＣノード１に各種データを送信する処理部である。受信部３１は、ネットワークＮを介してＢＣノード１から通知されたデータを受信する処理部である。システム時間管理部３２は、ＢＣノード１のシステム時間管理部１２と同様、ブロック生成ノード３のシステム時刻を管理する処理部である。
【0051】
ブロック生成部３３は、ブロックチェーンのブロックを生成する処理部である。例えば、ブロック生成部３３は、Ｂｉｔｃｏｉｎにおけるマイニングノードや、コンソーシアム型ブロックチェーンのＯＳＳであるＨｙｐｅｒｌｅｄｇｅｒ（登録商標） ＦａｂｒｉｃのＯｒｄｅｒｉｎｇ Ｓｅｒｖｉｃｅ（The Ordering Service, Hyperledger Fabric, “https://hyperledger-fabric.readthedocs.io/en/release-2.0/orderer/ordering_service.html”）等の公知の技術をもとに、ブロックチェーンのブロックを生成する。
【0052】
次に、指定した時間に送金の取引を実行する場合の以下の手順について詳細説明する。
０．初期状態
１．引き出し許可登録
２．引き出し待機・引き出し実行
０．初期状態
１．引き出し許可登録
２．引き出し待機・引き出し実行
【0053】
（０．初期状態）
図５は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図であり、より具体的には、ＢＣ台帳１５に登録されたデータの初期状態を示している。図５に示すように、ＢＣ台帳１５に登録されたデータには、トークン残高データＤ１と、引き出し許可データＤ２とが含まれる。
図５は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図であり、より具体的には、ＢＣ台帳１５に登録されたデータの初期状態を示している。図５に示すように、ＢＣ台帳１５に登録されたデータには、トークン残高データＤ１と、引き出し許可データＤ２とが含まれる。
【0054】
トークン残高データＤ１のａｃｃｏｕｎｔは、ユーザのアカウントアドレス、ｂａｌａｎｃｅはトークンの残高、ｒｅｓｅｒｖｅｄ ｔｏｋｅｎは引き出し許可により送金が予約されたトークン量を表す。
【0055】
本実施形態では、わかりやすさのためにアカウントごとのトークンの残高を管理するアカウント型のトークン管理手法で説明するが、ＵＴＸＯ型の手法でも同様に実施可能である。図示例（初期状態）において、トークン残高データＤ１には、０ｘ１２３４［送り手］のアカウントについて、１００のトークンの残高と、引き出し許可により送金が予約されたトークン量が０であることが登録されている。また、０ｘ２３４５［受け手］のアカウントについて、０のトークンの残高と、引き出し許可により送金が予約されたトークン量が０であることが登録されている。
【0056】
引き出し許可データＤ２は、図１で説明した時間指定の引き出し許可（approve()）に関するデータである。図示例において、引き出し許可データＤ２は空で、初期状態でまだ取引が登録されていない状態である。
【0057】
【0058】
図６Ａに示すように、ＢＣノード１ａ［送り手］は、ホスト端末２ａ［送り手］からの時間指定取引登録に関するトランザクション発行要求を受け付ける（Ｓ１１）。具体的には、ＢＣノード１ａは、［送り手］、［受け手］のアドレス（from,to）と、送金するトークン量（amount）と、引き出しが可能になる時刻（date）とが指定されたトランザクション発行要求を受け付ける。実施形態上は時間の指定方法は問わないが、電子計算機で比較のできる形式が望ましい。たとえば、協定世界時をミリ秒に変換した値などがある。本稿で時間情報は、ＩＳＯ８６０１のフォーマットで表記する。この要求内容に基づき、ＢＣノード１ａは、引き出しが可能になる時刻を含んだトランザクションを発行する（Ｓ１２～Ｓ２１）。
【0059】
具体的には、トランザクション／ブロック処理部１１は、要求内容に基づいてトランザクション作成・署名付与を行い（Ｓ１２）、作成したトランザクションの検証依頼を他のノード（ＢＣノード１ｂ～１ｄ）に通知する（Ｓ１３、Ｓ１４）。
【0060】
トランザクションの検証依頼を受信したＢＣノード１ｃ、１ｄのトランザクション／ブロック処理部１１は、トランザクションデータの検証を行った後に署名付与を行い（Ｓ１５）、トランザクションの検証結果をＢＣノード１ａに返信する（Ｓ１６）。トランザクションの検証依頼を受信したＢＣノード１ｂのトランザクション／ブロック処理部１１も同様、トランザクションデータの検証を行った後に署名付与を行い（Ｓ１７）、トランザクションの検証結果をＢＣノード１ａに返信する（Ｓ１８）。
【0061】
このように、実施形態の取引システムでは、発行されたトランザクションデータは、発行したノード（１ａ）とは別ノード（１ｂ～１ｄ）で、実行結果が検証される。
【0062】
トランザクションデータの検証方法は、ブロックチェーンごとに種類があるが、本実施形態では、Ｈｙｐｅｒｌｅｄｇｅｒ ＦａｂｒｉｃでのＴｒａｎｓａｃｔｉｏｎ Ｆｌｏｗ（Transaction Flow, Hyperledger Fabric, “https://hyperledger-fabric.readthedocs.io/ja/latest/txflow.html”）に基づき、ブロック化される前に各ノードでトランザクションデータを検証する方法で説明を行う。Ｅｔｈｅｒｅｕｍ等の他のブロックチェーンの場合でも、発行したノード以外でトランザクションを検証する点、また実行後でもその結果を検証できる点で、同様の検証が可能である。
【0063】
ついで、ＢＣノード１ａのトランザクション／ブロック処理部１１は、実行結果を検証したトランザクションを発行し、発行したトランザクションをブロック生成ノード３へ通知する（Ｓ１９）。ブロック生成ノード３は、通知されたトランザクションに関する完了通知をＢＣノード１ａへ返信する（Ｓ２０）。ＢＣノード１ａのトランザクション／ブロック処理部１１は、ブロック生成ノード３からの完了通知をホスト端末２ａへ通知する（Ｓ２１）。
【0064】
また、ブロック生成ノード３は、マイニングなどによりＢＣのブロック生成を行い（Ｓ２２）、通知されたトランザクションがブロックデータとしてまとめられる。
【0065】
図６Ｂに示すように、ついで、ブロック生成ノード３は、通知されたトランザクションを含むブロックをＢＣノード１ａ～１ｄに配布し（Ｓ２３～Ｓ２５）、ブロックチェーン上で全参加者（ＢＣノード１ａ～１ｄ全て）に共有される。
【0066】
具体的には、ＢＣノード１ａのトランザクション／ブロック処理部１１は、ブロック生成ノード３より配布されたブロックを検証した上でＢＣ台帳１５へ記入し（Ｓ２６、Ｓ２７）、ＢＣ台帳１５への記入済み完了を取得する（Ｓ２８）。
【0067】
このように取引が登録されると、引き出しが許可した分の情報が更新されることから、ＢＣノード１ａの時間取引実行部１０は、ＢＣ台帳１５を参照して引き出し許可データＤ２を取得し（Ｓ２９）、引き出し許可リストを更新する（Ｓ３０）。
【0068】
また、ＢＣノード１ｃ、１ｄのトランザクション／ブロック処理部１１も同様に、ブロック生成ノード３より配布されたブロックを検証した上でＢＣ台帳１５へ記入し（Ｓ３１、Ｓ３２）、ＢＣ台帳１５への記入済み完了を取得する（Ｓ３３）。
【0069】
このように取引が登録されると、引き出しが許可した分の情報が更新されることから、ＢＣノード１ｃ、１ｄの時間取引実行部１０は、ＢＣ台帳１５を参照して引き出し許可データＤ２を取得し（Ｓ３４）、引き出し許可リストを更新する（Ｓ３５）。
【0070】
また、ＢＣノード１ｂのトランザクション／ブロック処理部１１も同様に、ブロック生成ノード３より配布されたブロックを検証した上でＢＣ台帳１５へ記入し（Ｓ３６、Ｓ３７）、ＢＣ台帳１５への記入済み完了を取得する（Ｓ３８）。
【0071】
このように取引が登録されると、引き出しが許可した分の情報が更新されることから、ＢＣノード１ｂの時間取引実行部１０は、ＢＣ台帳１５を参照して引き出し許可データＤ２を取得し（Ｓ３９）、引き出し許可リストを更新する（Ｓ４０）。ここで、引き出し許可リストには、自ノードが管理するアカウントである［受け手］の時間指定引き出し許可が新たに含まれていることから、時間取引実行部１０は、この時間指定引き出し許可をイベント登録する（Ｓ４１）。
【0072】
図７は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図であり、より具体的には、ブロック配布による更新後のＢＣ台帳１５の状態を例示している。例えば、図５と図７とを比較すれば明らかなように、図７では、ｒｅｓｅｒｖｅｄ ｔｏｋｅｎの値が変化している。図７に示すように、各ノードの時間取引実行部１０は、引き出し許可データＤ２の更新を監視している。そして、各ノードの時間取引実行部１０は、自ノードに関連するアカウントの情報に更新（時間指定引き出し許可の追加）があった場合は、更新された時間指定引き出し許可をイベント登録し（Ｓ４１）、引き出しの待機状態に移行する。
【0073】
図８は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図であり、より具体的には、図７の引き出し許可データＤ２に引き出し時間の異なる取引をもう一つ登録した状態を例示している。図８の例では、引き出し許可データＤ２のパラメータを”（ｆｒｏｍ：０ｘ１２３４，ｔｏ：０ｘ２３４５，ａｍｏｕｎｔ：１０，ｄａｔｅ：２０２２１００１Ｔ１２００００）”とする取引についで、２度目の取引が登録されている。具体的には、１度目の登録との差分として、ａｍｏｕｎｔが２０、ｄａｔｅが２０２２１００１Ｔ１３００００とする取引が、１度目に加えて更に登録されている。時間取引実行部１０は、このように登録された取引ごとに、自ノードに関連するアカウントを「to」とする取引であるか否かを判定し、「to」とする取引である場合はイベント登録する。
【0074】
【0075】
図９Ａに示すように、Ｓ４１の後に待機状態になったＢＣノード１ｂの時間取引実行部１０は、自ノードのシステム時間管理部１２より取得した現在時刻データ（システム時刻）に基づいて、イベント登録された時間指定引き出し許可の指定時間まで処理を待機する（Ｓ５１、Ｓ５２）。
【0076】
ついで、ＢＣノード１ｂの時間取引実行部１０は、システム時刻が指定時間を経過した後に、引き出しを実行するトランザクションの発行要求をトランザクション／ブロック処理部１１へ通知する（Ｓ５３）。ここでは、現在時刻が２０２２年１０月１日１２時になったものとする。このため、時間取引実行部１０は、ｄａｔｅが” ２０２２１００１Ｔ１２００００”の引き出し要求のトランザクションについて、発行要求をトランザクション／ブロック処理部１１へ通知する。
【0077】
ついで、ＢＣノード１ｂのトランザクション／ブロック処理部１１は、発行要求を受けたトランザクションについて、トランザクション作成・署名付与を行い（Ｓ５４）、トランザクションの検証依頼を他のノード（ＢＣノード１ａ、１ｃ、１ｄ）に通知する（Ｓ５５）。
【0078】
トランザクションの検証依頼を受信したＢＣノード１ａ、１ｃ、１ｄのトランザクション／ブロック処理部１１は、トランザクションデータの検証を行った後に（Ｓ５６）、システム時間管理部１２より現在時刻データ（システム時刻）を取得する（Ｓ５７、Ｓ５８）。ついで、ＢＣノード１ａ、１ｃ、１ｄのトランザクション／ブロック処理部１１は、システム時刻がトランザクションの指定時刻より後である否かの検証結果（取引ＯＫ／取引ＮＧ）をＢＣノード１ｂへ通知する（Ｓ５９）。
【0079】
取引ＯＫの通知を受けたＢＣノード１ｂのトランザクション／ブロック処理部１１は、発行要求を受けたトランザクションを発行し、発行したトランザクションをブロック生成ノード３へ通知する（Ｓ６０）。ブロック生成ノード３は、通知されたトランザクションに関する完了通知をＢＣノード１ｂへ返信する（Ｓ６１）。ＢＣノード１ｂのトランザクション／ブロック処理部１１は、ブロック生成ノード３からの完了通知を時間取引実行部１０へ通知する（Ｓ６２）。なお、取引ＮＧの通知を受けたＢＣノード１ｂのトランザクション／ブロック処理部１１は、発行要求を受けたトランザクションを破棄する。
【0080】
また、ブロック生成ノード３は、マイニングなどによりＢＣのブロック生成を行い（Ｓ６３）、通知されたトランザクションがブロックデータとしてまとめられる。
【0081】
図９Ｂに示すように、ついで、ブロック生成ノード３は、通知されたトランザクションを含むブロックをＢＣノード１ａ～１ｄに配布する（Ｓ６４、Ｓ６５）。これにより、通知されたトランザクションを含むブロックは、ブロックチェーン上で全参加者（ＢＣノード１ａ～１ｄ全て）に共有される。
【0082】
ＢＣノード１ｂのトランザクション／ブロック処理部１１は、ブロック生成ノード３より配布されたブロックを検証した上でＢＣ台帳１５へ記入し（Ｓ６６、Ｓ６７）、ＢＣ台帳１５への記入済み完了を取得する（Ｓ６８）。同様に、ＢＣノード１ａ、１ｃ、１ｄのトランザクション／ブロック処理部１１は、ブロック生成ノード３より配布されたブロックを検証した上でＢＣ台帳１５へ記入し（Ｓ６９、Ｓ７０）、ＢＣ台帳１５への記入済み完了を取得する（Ｓ７１）。
【0083】
このように、発行要求を受けたトランザクションは、トランザクションを検証する他のノードが持つシステム時刻を基に引き出し可能な取引の有無を確認する。引き出し許可がある場合は、ＢＣノード１ｂのトランザクション／ブロック処理部１１は、その取引で許可されているトークン量を送り手のアカウントから受け手のアカウントに移転する。引き出し許可がない場合、ＢＣノード１ｂのトランザクション／ブロック処理部１１は、その取引は実行できないものとし、引き出しのトランザクションを破棄する。
【0084】
本実施形態では、取引ＯＫが過半数ノード以上の場合にトランザクションの取引が実行され、過半数より少ない場合は、取引が失敗しトークンは移転されないものとする（どの程度のノード数が取引ＯＫの判定の場合に取引を実行するかは、そのブロックチェーンのポリシーにより決定してよい）。
【0085】
図示例では、３ノードすべてでシステム時刻が２０２２年１０月１日１２時以降となっているため、引き出し可能な取引として、ｄａｔｅが” ２０２２１００１Ｔ１２００００”のものが該当するため、取引実行を承認する取引ＯＫの結果をＢＣノード１ｂへ返している。したがって、ＢＣノード１ｂのトランザクション／ブロック処理部１１は、ａｍｏｕｎｔに設定されている１０トークンを送り手から受け手に移転する。本実施形態では、該当する取引が１つのみであったが、該当する取引が複数ある場合は、それらをまとめてトークン移転を実行することも可能である。
【0086】
上記のトランザクションにより引き出しの取引が実行されると、移転を実行した引き出し許可データの取引は削除され、ｒｅｓｅｒｖｅｄ ｔｏｋｅｎの値を減少させる。したがって、取引実行後のＢＣ台帳１５の状態は更新される。
【0087】
図１０は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図であり、より具体的には図８に例示したＢＣ台帳１５の更新後の内容を示している。図１０に示すように、更新後のＢＣ台帳１５では、２０２２年１０月１日１２時以降において、図８に例示した引き出し許可データＤ２の一番目の取引が実行されている。すなわち、０ｘ１２３４［送り手］から０ｘ２３４５［受け手］に対して１０のａｍｏｕｎｔが移転している。
すなわち、トークン残高データＤ１における０ｘ１２３４［送り手］のｂａｌａｎｃｅは９０となり、０ｘ２３４５［受け手］のｂａｌａｎｃｅは１０となっている。
すなわち、トークン残高データＤ１における０ｘ１２３４［送り手］のｂａｌａｎｃｅは９０となり、０ｘ２３４５［受け手］のｂａｌａｎｃｅは１０となっている。
【0088】
なお、２０２２年１０月１日１２時の時点において、まだ指定時間になっていない取引（ｄａｔｅが” ２０２２１００１Ｔ１３００００”の２０トークンの移転）は実行されていない。以上のように、本実施形態では、時間指定の引き出し許可に基づいて各ノードが取引を検証し、時間になった取引のみを実行することができるため、上述した課題の一つが解決されている。
【0089】
（引き出し要求が失敗した場合）
ブロックチェーン（ＢＣ）では、各ノードが持つシステム時刻は同期していないことが前提となる。そのため、トランザクションを発行したノードのシステム時刻上は、指定時刻になっていたとしても、実際の時刻とは誤差が生じており、必ずしも取引を実行できるとは限らない。そこで、そういった引き出しの要求が失敗の際に、取引を保証する処理を示す。
ブロックチェーン（ＢＣ）では、各ノードが持つシステム時刻は同期していないことが前提となる。そのため、トランザクションを発行したノードのシステム時刻上は、指定時刻になっていたとしても、実際の時刻とは誤差が生じており、必ずしも取引を実行できるとは限らない。そこで、そういった引き出しの要求が失敗の際に、取引を保証する処理を示す。
【0090】
（０．初期状態）
初期状態は、前述したケースと同様に、図５の状態とする。つまりは、初期状態でのそれぞれのアカウントのトークン残高データＤ１は、０ｘ１２３４（送り手）が１００トークン、０ｘ２３４５（受け手）が０トークンの状態である。また、引き出し許可データＤ２は空で、初期状態でまだ取引が登録されていない状態である。
初期状態は、前述したケースと同様に、図５の状態とする。つまりは、初期状態でのそれぞれのアカウントのトークン残高データＤ１は、０ｘ１２３４（送り手）が１００トークン、０ｘ２３４５（受け手）が０トークンの状態である。また、引き出し許可データＤ２は空で、初期状態でまだ取引が登録されていない状態である。
【0091】
（１．引き出し許可登録）
引き出し許可登録は、前述したケースと同様に実施する（フローチャートは図６Ａ、図６Ｂと同様）。更新後の引き出し許可データＤ２の状態は、図７にように１つの引き出し許可が登録された状態となる。
引き出し許可登録は、前述したケースと同様に実施する（フローチャートは図６Ａ、図６Ｂと同様）。更新後の引き出し許可データＤ２の状態は、図７にように１つの引き出し許可が登録された状態となる。
【0092】
（２．引き出し待機・引き出し実行）
まずは、１度目では引き出し要求が失敗するケースを説明する。図１１は、引き出し要求が失敗するケースの一例を示すフローチャートである。
まずは、１度目では引き出し要求が失敗するケースを説明する。図１１は、引き出し要求が失敗するケースの一例を示すフローチャートである。
【0093】
図１１に示すように、前述したケースと同様の処理が行われ（Ｓ８１～Ｓ８４）、指定時刻になったことを契機にＢＣノード１ｂのトランザクション／ブロック処理部１１が、トランザクション検証依頼を各ノードに送信する（Ｓ８５、Ｓ８６）。
【0094】
しかし、今回のケースでは、受け手ノードのシステム時刻に誤差が生じており、実際の時刻よりも早く引き出し要求されている。具体的には、現在時刻は、２０２２年１０月１日１１時５９分であるが、受け手のノードのシステム時刻は現在時刻が２０２２年１０月１日１２時になっているものとする。また、システム時刻の誤差は、悪意のあるユーザによる外部的な要因でも良いし、内部的な要因で偶発的に起こる場合や、故意に発生させた場合も問わない。
【0095】
トランザクション検証を依頼されたＢＣノード１ｃ、１ａ、１ｄは、前述したケースと同様、それぞれのシステム時刻に基づいて引き出しの可否を判定し、トランザクション結果をＢＣノード１ｂへ返信する（Ｓ８７～Ｓ９４）。
【0096】
受け手ノード同様に、時刻が早いノードは取引ＯＫと返してしまう場合もあるが、大半のノードはより正確な時刻で動作しているため、取引ＮＧとして結果が返される。図示例では、ＢＣノード１ｃが取引ＯＫ、ＢＣノード１ａ、１ｄが取引ＮＧを返している。
【0097】
本実施形態のポリシーでは、過半数のノードで取引ＯＫの結果を得られない場合には、取引を実行できないため、ＢＣノード１ｂのトランザクション／ブロック処理部１１は、このトランザクションの取引は失敗とする結果を時間取引実行部１０に返す（Ｓ９５）。取引失敗の結果を受けたＢＣノード１の時間取引実行部１０は、再び待機状態に移行する（Ｓ９６）。
【0098】
ブロックチェーンの形態によっては、本実施形態のように、明示的にトランザクション検証の結果を受け取れない場合がある。その場合でも、時間取引実行部１０が、ＢＣ台帳１５を監視し、発行したトランザクションの成功の可否を確認することで同様の処理が可能である。その場合、一定時間経過してもトークンが移転されないことをもって、取引失敗と判定し、時間取引実行部１０は再び待機状態に移行する。
【0099】
【0100】
図１１のＳ９６において待機状態に移行したＢＣノード１ｂの時間取引実行部１０は、一定時間、たとえば１分などの待ち時間を待機した後（Ｓ１０１）、Ｓ５３～Ｓ７１と同様の処理を行う。
【0101】
具体的には、ＢＣノード１ｂのトランザクション／ブロック処理部１１は、再び引き出しのためのトランザクションを発行するため、トランザクション検証依頼を各ノードに送信する（Ｓ１０４、Ｓ１０５）。１度目と同様に、トランザクション検証を依頼されたＢＣノード１ｃ、１ａ、１ｄのトランザクション／ブロック処理部１１は、それぞれのシステム時刻に基づいて、引き出しの可否を判定する。ここで、一定時間の待機を行ったことで、先ほどは指定時間前であったノードも、システム時刻が指定時間を経過し、取引ＯＫの判定を返す。
【0102】
この結果、過半数の取引ＯＫの結果を得られたため、ＢＣノード１ｂのトランザクション／ブロック処理部１１は、ブロック生成ノード３にトランザクション発行を送信し（Ｓ１１４）、ブロックチェーン上で全参加者に共有され、引き出しの取引が実行される。
【0103】
引き出しの取引が実行されると、移転を実行した引き出し許可データの取引は削除され、ｒｅｓｅｒｖｅｄ ｔｏｋｅｎの値を減少させる。
【0104】
図１３は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図である。図１３に示すように、１度目は、指定時刻前で取り下げられた取引が２度目の再送により、指定時間とブロックチェーン上の各ノードで認められ、１０トークン移転が実行されている。
【0105】
以上のように、実施形態にかかる取引システムでは、ノードごとにシステム時刻のずれがあった場合でも、ブロックチェーン上でのノード間で時間を検証し、かつ、失敗した取引の再送を制御することで、指定時間での取引結果を保証することができる。
【0106】
（引き出し要求するノードを冗長化させる場合）
以下のケースでは、受け手のノードで何かしらの問題が発生し、指定時間にトランザクションが発行できない場合について説明する。
以下のケースでは、受け手のノードで何かしらの問題が発生し、指定時間にトランザクションが発行できない場合について説明する。
【0107】
上記のケースでは、それぞれ受け手ノードを起点に、引き出し要求のトランザクションが指定時間通りに実行されたものかを検証していたが、起点となるノードがエラーになると、それ以降の処理も実行ができず、時間指定の取引が実行されることを保証できない。そこで今回のケースでは、トランザクションを発行するノードの冗長化を行うことで、受け手ノードが引き出し要求トランザクションを発行できない場合でも指定時間での取引を保証する。
【0108】
（０．初期状態）
図１４は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図であり、より具体的には、今回のケースにおいてＢＣ台帳１５に登録されたデータの初期状態を示す。
図１４は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図であり、より具体的には、今回のケースにおいてＢＣ台帳１５に登録されたデータの初期状態を示す。
【0109】
図１４に示すように、トークン残高データＤ１において、それぞれのアカウントのトークン残高は、０ｘ１２３４（送り手）が１００トークン、０ｘ２３４５（受け手１）、０ｘ３４５６（受け手２）はそれぞれ０トークンの状態である。また、引き出し許可データは空である。引き出し許可データＤ２は、初期状態でまだ取引が登録されていない状態である。
【0110】
また、今回のケースでは、ＢＣ台帳１５において、新たにグループデータＤ３が追加されている。グループデータＤ３は、冗長化を行う上でのグループを定義するデータで、ノードごとにグループが指定されている。また、各アカウントにも、グループ情報が付与されており、各ノードは同じグループに所属する時間指定の取引に関しては、自身アカウントの取引同様に監視を行い、必要に応じて、代替のトランザクションを発行する。
【0111】
具体的には、グループデータＤ３では、［受け手］のＢＣノード１ｂと［参加者］のＢＣノード１ｃとが同一のグループ「Ｇ１」に属していることが定義されている。また、グループデータＤ３では、［送り手］のＢＣノード１ａと、［参加者］のＢＣノード１ｄとが同一のグループ「Ｇ２」に属していることが定義されている。
【0112】
（１．引き出し許可登録）
図１５Ａ、図１５Ｂは、引き出し登録にかかる処理の一例を示すフローチャートである（図１５Ｂは、図１５Ａの処理の続きを示す）。図１５Ａ、図１５Ｂに示すように、引き出し登録については、前述した図６Ａ、図６ＢのＳ１１～Ｓ３８と同様の処理（Ｓ１３１～Ｓ１５８）が行われる。
図１５Ａ、図１５Ｂは、引き出し登録にかかる処理の一例を示すフローチャートである（図１５Ｂは、図１５Ａの処理の続きを示す）。図１５Ａ、図１５Ｂに示すように、引き出し登録については、前述した図６Ａ、図６ＢのＳ１１～Ｓ３８と同様の処理（Ｓ１３１～Ｓ１５８）が行われる。
【0113】
具体的には、実行行結果を検証したトランザクションは、ブロック生成ノード３で、ブロックデータとしてまとめられ、ブロックチェーン上で全参加者に共有される。ＢＣ台帳１５に取引が登録されると、引き出しが許可した分の情報が更新される。
【0114】
図１６は、ＢＣ台帳１５に登録されたデータの一例を説明する説明図であり、より具体的にはブロック配布（Ｓ１４３～Ｓ１４５）による更新後のＢＣ台帳１５の状態を例示している。図１６に示すように、更新後のＢＣ台帳１５には、引き出し許可データＤ２のパラメータを”（ｆｒｏｍ：０ｘ１２３４，ｔｏ：０ｘ２３４５，ａｍｏｕｎｔ：１０，ｄａｔｅ：２０２２１００１Ｔ１２００００）”とする取引が登録されている。ここで、この取引の［受け手］と同一のグループである「Ｇ１」に属するアカウントはＢＣノード１ｃに属する［参加者］となる。
【0115】
各ノードの時間取引実行部１０は、引き出し許可データＤ２の更新を監視しており、自ノードに関連するアカウントの情報に更新があった場合は、引き出しの待機状態に移行する。前回までのケースでは、自ノードで管理するアカウントのみに絞って、取引を確認していたが、今回のケースでは、同じグループに所属するアカウントを含めて確認を行う。すなわち、時間取引実行部１０は、アカウント０ｘ２３４５はＧ１のグループに所属しているため、ＢＣノード１ｂ、１ｃがそれぞれ待機状態に移行する。
【0116】
【0117】
図１７Ａに示すように、今回のケースでは、受け手のＢＣノード１ｂの時間取引実行部１０が待機状態（Ｓ１７１、Ｓ１７２）であるとともに、Ｇ１のグループに所属しているＢＣノード１ｃも、ＢＣノード１ｃと同様に待機状態（Ｓ１７３、Ｓ１７４）となっている。
【0118】
ついで、ＢＣノード１ｃのトランザクション／ブロック処理部１１は、ＢＣノード１ｂと同様、指定時間になったことを契機に、引き出しを実行するトランザクションを発行する（Ｓ１７５～Ｓ１９０）。
【0119】
ここでは、２０２２年１０月１日１２時になったものとし、ｄａｔｅが”２０２２１００１Ｔ１２００００”の引き出し許可のトランザクションが発行される。本来であれば、受け手のアカウントが所有するＢＣノード１ｂがトランザクションを発行するべきであるが、ここでは、何かしら問題によりＢＣノード１ｂのシステム時刻が大幅にずれており、何もしないものとする。ＢＣノード１ｂがトランザクションを発行しない場合は、同じグループに所属し、待機状態になっているＢＣノード１ｃが引き出し要求をするために動作（Ｓ１７５以降）を開始する。
【0120】
具体的には、ＢＣノード１ｃの時間取引実行部１０は、自ノードのシステム時刻に基づいて、指定時間まで待機する（Ｓ１７３、Ｓ１７４）。そして、指定時間になった時に、引き出しを実行するトランザクションを発行する。ここで、本来実行するノードと競合が発生しないように、冗長化されたノードであるＢＣノード１ｃは、指定時間よりも一定時間、たとえば１分など待機した後に、動作を開始するものとする。
【0121】
ついで、ＢＣノード１ｃの時間取引実行部１０は、本来実行するノード（ＢＣノード１ｂ）がトランザクションを発行していないことを確認するために、ＢＣ台帳１５のデータを取得し、時間指定取引の状態を見る（Ｓ１７５～Ｓ１７７）。これら処理を経て、受け手のノードが動いていないと判定されると、時間取引実行部１０は、冗長化されたノードが代わりに引き出し要求を行う（Ｓ１７８）。
【0122】
発行されたトランザクションは、トランザクションを検証するノードが持つシステム時刻を基に引き出し可能な取引の有無を確認する（Ｓ１８０～Ｓ１８９）。今回は、３つのノードのうち、２つのノードはｄａｔｅが” ２０２２１００１Ｔ１２００００”の取引が引き出し可能となっているため（受け手のＢＣノード１ｂの時刻がずれているため）、取引実行を承認する取引ＯＫの結果を返し、ａｍｏｕｎｔに設定されている１０トークンを送り手から受け手に移転する。
【0123】
引き出しの取引が実行されると、移転を実行した引き出し許可データの取引は削除され、ｒｅｓｅｒｖｅｄ ｔｏｋｅｎの値を減少させる。
【0124】
図１８は、ＢＣ台帳に登録されたデータの一例を説明する説明図であり、より具体的には、引き出しの取引後のＢＣ台帳１５の状態を例示する。図１８に示すように、冗長化されたノード（ＢＣノード１ｃ）により引き出しの取引が行われることから、本来実行すべき受け手ノードが正常に動作できない場合でも、冗長化されたノードにより、指定時間に取引を実行することが保証できる。
【0125】
なお、グループの設定情報はＢＣ台帳１５で管理する以外の形態でも構わない。例えば、Ｈｙｐｅｒｌｅｄｇｅｒ ＦａｂｒｉｃのＭｅｍｂｅｒｓｈｉｐ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒｓ（Membership Service Providers, Hyperledger Fabric, “https://hyperledger-fabric.readthedocs.io/ja/latest/msp.html”）などを用いて、ノードが所属する組織を冗長化の単位としてもよい。また、本実施形態のように、あらかじめグループの設定が困難な場合は動的にグループを作成することにより、同様の処理を実現することができる。
【0126】
以上のように、ＢＣ台帳１５を管理する各ノードは、金融資産の移転元アカウントからの要求に基づき、移転元アカウントと、移転先アカウントと、金融資産の移転量と、金融資産の移転時刻とを含む、金融資産の移転を承認する承認トランザクションをＢＣ台帳１５に登録する。各ノードは、登録された承認トランザクションの中の、自ノードが移転先アカウントを管理する承認トランザクションについて、自ノードが管理する管理時刻が承認トランザクションに含まれる移転時刻に到達後、承認トランザクションの検証を他ノードに依頼し、他ノードの検証結果に基づいて承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行する。各ノードは、他ノードから承認トランザクションの検証依頼を受け付けた場合、承認トランザクションに含まれる移転時刻が管理時刻より後であるか否かの検証結果を他ノードに返信する。
【0127】
これにより、ＢＣ台帳１５を管理する各ノードで構成される取引システムでは、ブロックチェーンによる安全な時間指定の取引を実現できる。その結果、ブロックチェーン上のトークンを用いて、債券同様の時間を指定した取引の実行が可能となり、ＤｅＦｉでのファイナンスシステムの実現に寄与する。また、引き出し許可によるトークンの移転管理は、実際に引き出しがされてトークンが移転されるまでは、トークンは送り手の元にあり、移転されていない。そのため、引き出し許可された残高を基に戻すのみで指定時間前の取り消しができ、エスクローを使って一度、別のアカウント移動する方式などに比べて、時間前の取引の取り消しが容易となり、ユーザビリティが向上する。
【0128】
以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
【0129】
（付記１）金融資産にかかる分散台帳を管理する各ノードのコンピュータに、
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行させることを特徴とする取引処理プログラム。
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行させることを特徴とする取引処理プログラム。
【0130】
（付記２）前記発行する処理は、前記第１の他ノードの検証結果に基づいて前記要求トランザクションの発行を否定した場合、所定時間経過後に、前記承認トランザクションの検証を再依頼する、
ことを特徴とする付記１に記載の取引処理プログラム。
ことを特徴とする付記１に記載の取引処理プログラム。
【0131】
（付記３）前記発行する処理は、前記登録された承認トランザクションの中の、第３の他ノードが前記移転先アカウントを管理する承認トランザクションについて、前記管理時刻が前記承認トランザクションに含まれる移転時刻に到達してから所定時間経過後に当該承認トランザクションにかかる要求トランザクションが発行されていない場合、前記承認トランザクションの検証を第４の他ノードに依頼し、当該第４の他ノードの検証結果に基づいて前記承認トランザクションにかかる要求トランザクションを前記第３の他ノードを代理して発行する、
ことを特徴とする付記１に記載の取引処理プログラム。
ことを特徴とする付記１に記載の取引処理プログラム。
【0132】
（付記４）前記発行する処理は、前記登録された承認トランザクションの中の、前記自ノードと同一のグループに属する前記第３の他ノードが前記移転先アカウントを管理する承認トランザクションについて、当該承認トランザクションにかかる要求トランザクションを前記第３の他ノードを代理して発行する、
ことを特徴とする付記３に記載の取引処理プログラム。
ことを特徴とする付記３に記載の取引処理プログラム。
【0133】
（付記５）前記発行する処理は、前記検証を複数の前記第１の他ノードに依頼し、複数の前記第１の他ノードの検証結果に基づいて前記要求トランザクションを発行する、
ことを特徴とする付記１に記載の取引処理プログラム。
ことを特徴とする付記１に記載の取引処理プログラム。
【0134】
（付記６）金融資産にかかる分散台帳を管理する各ノードのコンピュータが、
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行することを特徴とする取引処理方法。
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行することを特徴とする取引処理方法。
【0135】
（付記７）前記発行する処理は、前記第１の他ノードの検証結果に基づいて前記要求トランザクションの発行を否定した場合、所定時間経過後に、前記承認トランザクションの検証を再依頼する、
ことを特徴とする付記６に記載の取引処理方法。
ことを特徴とする付記６に記載の取引処理方法。
【0136】
（付記８）前記発行する処理は、前記登録された承認トランザクションの中の、第３の他ノードが前記移転先アカウントを管理する承認トランザクションについて、前記管理時刻が前記承認トランザクションに含まれる移転時刻に到達してから所定時間経過後に当該承認トランザクションにかかる要求トランザクションが発行されていない場合、前記承認トランザクションの検証を第４の他ノードに依頼し、当該第４の他ノードの検証結果に基づいて前記承認トランザクションにかかる要求トランザクションを前記第３の他ノードを代理して発行する、
ことを特徴とする付記６に記載の取引処理方法。
ことを特徴とする付記６に記載の取引処理方法。
【0137】
（付記９）前記発行する処理は、前記登録された承認トランザクションの中の、前記自ノードと同一のグループに属する前記第３の他ノードが前記移転先アカウントを管理する承認トランザクションについて、当該承認トランザクションにかかる要求トランザクションを前記第３の他ノードを代理して発行する、
ことを特徴とする付記８に記載の取引処理方法。
ことを特徴とする付記８に記載の取引処理方法。
【0138】
（付記１０）前記発行する処理は、前記検証を複数の前記第１の他ノードに依頼し、複数の前記第１の他ノードの検証結果に基づいて前記要求トランザクションを発行する、
ことを特徴とする付記６に記載の取引処理方法。
ことを特徴とする付記６に記載の取引処理方法。
【0139】
（付記１１）金融資産にかかる分散台帳を管理する情報処理装置であって、
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行する演算装置を含むことを特徴とする情報処理装置。
前記金融資産の移転元アカウントからの要求に基づき、前記移転元アカウントと、移転先アカウントと、前記金融資産の移転量と、前記金融資産の移転時刻とを含む、前記金融資産の移転を承認する承認トランザクションを前記分散台帳に登録し、
前記登録された承認トランザクションの中の、自ノードが前記移転先アカウントを管理する承認トランザクションについて、前記自ノードが管理する管理時刻が前記承認トランザクションに含まれる移転時刻に到達後、前記承認トランザクションの検証を第１の他ノードに依頼し、当該第１の他ノードの検証結果に基づいて前記承認トランザクションにかかる金融資産の移転を要求する要求トランザクションを発行し、
第２の他ノードから前記承認トランザクションの検証依頼を受け付けた場合、当該承認トランザクションに含まれる移転時刻が前記管理時刻より後であるか否かの検証結果を前記第２の他ノードに返信する、
処理を実行する演算装置を含むことを特徴とする情報処理装置。
【0140】
（付記１２）前記発行する処理は、前記第１の他ノードの検証結果に基づいて前記要求トランザクションの発行を否定した場合、所定時間経過後に、前記承認トランザクションの検証を再依頼する、
ことを特徴とする付記１１に記載の情報処理装置。
ことを特徴とする付記１１に記載の情報処理装置。
【0141】
（付記１３）前記発行する処理は、前記登録された承認トランザクションの中の、第３の他ノードが前記移転先アカウントを管理する承認トランザクションについて、前記管理時刻が前記承認トランザクションに含まれる移転時刻に到達してから所定時間経過後に当該承認トランザクションにかかる要求トランザクションが発行されていない場合、前記承認トランザクションの検証を第４の他ノードに依頼し、当該第４の他ノードの検証結果に基づいて前記承認トランザクションにかかる要求トランザクションを前記第３の他ノードを代理して発行する、
ことを特徴とする付記１１に記載の情報処理装置。
ことを特徴とする付記１１に記載の情報処理装置。
【0142】
（付記１４）前記発行する処理は、前記登録された承認トランザクションの中の、前記自ノードと同一のグループに属する前記第３の他ノードが前記移転先アカウントを管理する承認トランザクションについて、当該承認トランザクションにかかる要求トランザクションを前記第３の他ノードを代理して発行する、
ことを特徴とする付記１３に記載の情報処理装置。
ことを特徴とする付記１３に記載の情報処理装置。
【0143】
（付記１５）前記発行する処理は、前記検証を複数の前記第１の他ノードに依頼し、複数の前記第１の他ノードの検証結果に基づいて前記要求トランザクションを発行する、
ことを特徴とする付記１１に記載の情報処理装置。
ことを特徴とする付記１１に記載の情報処理装置。
【符号の説明】
【0144】
１、１ａ～１ｄ…ＢＣノード
２、２ａ～２ｄ…ホスト端末
３…ブロック生成ノード
１０…時間取引実行部
１１…トランザクション／ブロック処理部
１２…システム時間管理部
１３…受信部
１４…送信部
１５…ＢＣ台帳
２０…送信部
２１…受信部
２２…操作・表示部
３０…送信部
３１…受信部
３２…システム時間管理部
３３…ブロック生成部
１００…情報処理装置
１０１…演算装置
１０２…主記憶装置
１０２ａ…プログラム
１０２ｂ…各種データ
１０３…補助記憶装置
１０４…ネットワークインターフェース
１０５…データバス
Ｃ１、Ｃ２…ケース
Ｄ１…トークン残高データ
Ｄ２…引き出し許可データ
Ｄ３…グループデータ
Ｈ１…送り手
Ｈ２…受け手
Ｈ３…参加者
Ｎ…ネットワーク
２、２ａ～２ｄ…ホスト端末
３…ブロック生成ノード
１０…時間取引実行部
１１…トランザクション／ブロック処理部
１２…システム時間管理部
１３…受信部
１４…送信部
１５…ＢＣ台帳
２０…送信部
２１…受信部
２２…操作・表示部
３０…送信部
３１…受信部
３２…システム時間管理部
３３…ブロック生成部
１００…情報処理装置
１０１…演算装置
１０２…主記憶装置
１０２ａ…プログラム
１０２ｂ…各種データ
１０３…補助記憶装置
１０４…ネットワークインターフェース
１０５…データバス
Ｃ１、Ｃ２…ケース
Ｄ１…トークン残高データ
Ｄ２…引き出し許可データ
Ｄ３…グループデータ
Ｈ１…送り手
Ｈ２…受け手
Ｈ３…参加者
Ｎ…ネットワーク
【図1】
【図2】
【図3】
【図4】
【図5】
【図6A】
【図6B】
【図7】
【図8】
【図9A】
【図9B】
【図10】
【図11】
【図12A】
【図12B】
【図13】
【図14】
【図15A】
【図15B】
【図16】
【図17A】
【図17B】
【図18】