特許 7550941 トランザクション管理システムおよびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-09-05

(45)【発行日】2024-09-13

(54)【発明の名称】トランザクション管理システムおよびプログラム

(51)【国際特許分類】

   G06Q 40/04 20120101AFI20240906BHJP

【ＦＩ】

G06Q40/04

【請求項の数】 9

(21)【出願番号】P 2023144045

(22)【出願日】2023-09-05

【審査請求日】2023-09-13

(73)【特許権者】

【識別番号】596108508

【氏名又は名称】株式会社大和総研

(74)【代理人】

【識別番号】100114638

【弁理士】

【氏名又は名称】中野 寛也

(72)【発明者】

【氏名】桑木 大輔

【審査官】深津 始

(56)【参考文献】

【文献】特表２０２２－５３２４６４（ＪＰ，Ａ）

【文献】特許第６１６２８４３（ＪＰ，Ｂ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ －Ｇ０６Ｑ ９９／００

(57)【特許請求の範囲】

【請求項1】

ブロックチェーンを用いて移転することが可能なセキュリティトークンのトランザクションを管理するコンピュータにより構成されたトランザクション管理システムであって、
金融機関の申請担当者若しくは顧客により登録されるか、または売買システムから取得して登録された移転元および移転先の各アカウントのアカウント情報を含む移転申請データを、申請番号と対応付けて記憶する移転申請データベースと、
この移転申請データベースに記憶された前記移転申請データについて前記金融機関の承認担当者による承認が得られた場合に前記申請番号を含む承認済リクエストを記憶する先入先出用のキューと、
前記移転申請データベースに記憶された前記移転申請データに対する前記承認担当者による承認を受け付け、前記承認済リクエストを前記キューに格納する承認処理手段と、
この承認処理手段による処理とは独立したタイミングで、前記キューから１件分の前記承認済リクエストを取り出し、取り出した前記承認済リクエストに含まれる前記申請番号を用いて、承認された前記移転申請データを前記移転申請データベースから取得する移転申請データ取得手段と、
この移転申請データ取得手段により取得した前記移転申請データに含まれる前記移転元のアカウントのアカウント情報を用いて、この移転元のアカウントについてのナンスの値を、通信回線を介してブロックチェーンシステムを構成するノードから取得するナンス取得手段と、
前記移転申請データ取得手段により取得した前記移転申請データ、および前記ナンス取得手段により取得したナンスの値を用いて、このナンスの値を付与したトランザクションデータを作成するトランザクション作成手段と、
このトランザクション作成手段により作成した前記トランザクションデータを、通信回線を介して前記ノードに送信するトランザクション送信手段と、
このトランザクション送信手段により送信した前記トランザクションデータに対する処理結果の通知を、通信回線を介して前記ノードから受信し、前記移転申請データ取得手段による次の前記承認済リクエストの処理への移行のための処理を実行する確認手段と
を備えたことを特徴とするトランザクション管理システム。

【請求項2】

前記キューは、複数設けられ、
各アカウントが移転元になっている前記移転申請データに係る前記承認済リクエストを複数の前記キューのうちのいずれに格納するのかを定めるアカウント・キュー対応関係を示す情報として、各アカウントのアカウント情報と各キューのキュー識別情報とを対応付けて記憶するアカウント・キュー対応関係記憶手段を備え、
前記承認処理手段は、
前記移転申請データベースに記憶された前記移転申請データに対する前記承認担当者による承認を受け付け、前記移転申請データに含まれる前記移転元のアカウントのアカウント情報を用いて、この移転申請データに係る前記承認済リクエストが格納される前記キューのキュー識別情報を前記アカウント・キュー対応関係記憶手段から取得し、取得したキュー識別情報の前記キューに前記承認済リクエストを格納する構成とされている
ことを特徴とする請求項１に記載のトランザクション管理システム。

【請求項3】

前記承認処理手段は、
前記移転申請データベースに記憶された複数の前記移転申請データに対する前記承認担当者による一括承認を受け付け、一括承認された複数の前記移転申請データの中に、同じ移転元のアカウントの前記移転申請データが含まれている場合に、前記同じ移転元のアカウントの複数の前記移転申請データに係る複数の前記承認済リクエストを１つのグループとしてまとめたグループ承認済リクエストを前記キューに格納する構成とされ、
前記移転申請データ取得手段は、
前記キューから１つの前記グループ承認済リクエストを取り出した場合には、前記グループ承認済リクエストに含まれる複数の前記申請番号を用いて、一括承認された複数の前記移転申請データの中の前記同じ移転元のアカウントの複数の前記移転申請データを前記移転申請データベースから取得する構成とされ、
前記ナンス取得手段は、
前記移転申請データ取得手段により前記グループ承認済リクエストが取り出された場合に、前記移転申請データベースから取得した複数の前記移転申請データに含まれている前記同じ移転元のアカウントのアカウント情報を用いて、この移転元のアカウントについてのナンスの値を、通信回線を介して前記ノードから取得する構成とされ、
前記トランザクション作成手段は、
前記移転申請データ取得手段により取得した複数の前記移転申請データ、および前記ナンス取得手段により取得したナンスの値を用いて、取得したナンスの値およびこの値に続くナンスの値をそれぞれ付与した複数の前記トランザクションデータを作成する構成とされ、
前記トランザクション送信手段は、
前記トランザクション作成手段により作成した最も若いナンスの値を付与した前記トランザクションデータを前記ノードに送信した後に、前記ノードからの前記処理結果の通知を待つことなく、前記最も若いナンスの値に続くナンスの値を付与した前記トランザクションデータを前記ノードに送信する構成とされ、
前記確認手段は、
前記トランザクション送信手段により送信した１つの前記グループ承認済リクエストに係る複数の前記トランザクションデータのうちの最後に送信した前記トランザクションデータに対する処理結果の通知を、通信回線を介して前記ノードから受信した場合に、前記移転申請データ取得手段による次の前記承認済リクエストの処理への移行のための処理を実行する構成とされている
ことを特徴とする請求項１または２に記載のトランザクション管理システム。

【請求項4】

前記移転申請データベースに記憶された前記移転申請データの移転元のアカウントのアカウント情報および処理状況を示すステータスを用いて、各アカウントが移転元になっている前記移転申請データに係る前記承認済リクエストが、集計期間中に前記キューに実際に格納されたアカウント別実績件数を集計して求める格納実績集計手段と、
この格納実績集計手段により集計して得られた前記アカウント別実績件数を、移転元の各アカウントのアカウント情報と関連付けて記憶する格納実績記憶手段と、
この格納実績記憶手段に記憶された各アカウントの前記アカウント別実績件数を用いて、複数の前記キューの各々で前記アカウント別実績件数を合計した前記集計期間中のキュー別合計件数が均一または略均一になるように、各アカウントの前記アカウント別実績件数を複数の前記キューのいずれかに割り当てることにより、前記アカウント・キュー対応関係を示す情報を変更し、変更後の前記アカウント・キュー対応関係を示す情報を、前記アカウント・キュー対応関係記憶手段に記憶させるアカウント・キュー対応関係変更手段と
を備えたことを特徴とする請求項２に記載のトランザクション管理システム。

【請求項5】

前記格納実績集計手段は、
前記移転申請データベースに記憶された前記移転申請データの承認日時を用いて、午前および午後、またはその他の複数の時間帯に分けて、前記承認済リクエストが前記集計期間中に前記キューに実際に格納されたアカウント別実績件数を集計して求め、求めた時間帯毎のアカウント別実績件数を用いて、承認が行われた時刻について時間帯に偏りのあるアカウントを決定する構成とされ、
前記アカウント・キュー対応関係変更手段は、
前記格納実績集計手段により決定された時間帯に偏りのあるアカウントの前記アカウント別実績件数を、複数の前記キューに分散させて割り当てた後に、
複数の前記キューの各々で前記アカウント別実績件数を合計した前記集計期間中のキュー別合計件数が均一または略均一になるように、残っている各アカウントの前記アカウント別実績件数を複数の前記キューのいずれかに割り当てることにより、前記アカウント・キュー対応関係を示す情報を変更し、変更後の前記アカウント・キュー対応関係を示す情報を、前記アカウント・キュー対応関係記憶手段に記憶させる構成とされている
ことを特徴とする請求項４に記載のトランザクション管理システム。

【請求項6】

前記キューは、
他の前記承認済リクエストよりも優先度の高い優先度付きの前記承認済リクエストが格納された場合に、この優先度の高い優先度付きの前記承認済リクエストを他の前記承認済リクエストよりも先に送出することができる優先度付きキューとされ、
前記移転申請データベースは、
緊急で移転する必要のある優先承認対象として指定された移転申請に係る前記移転申請データ、および優遇すべき優良顧客の移転申請に係る前記移転申請データを、申請番号および優先度と対応付けて記憶する構成とされ、
前記承認処理手段は、
特別な権限を有する予め定められた承認担当者による承認を受け付けた場合、並びに、前記優先承認対象として指定された前記移転申請データおよび前記優良顧客の移転申請に係る前記移転申請データに対する承認を受け付けた場合に、優先度の高い優先度付きの前記承認済リクエストを前記キューに格納する構成とされている
ことを特徴とする請求項１に記載のトランザクション管理システム。

【請求項7】

複数の前記キューのいずれも、
他の前記承認済リクエストよりも優先度の高い優先度付きの前記承認済リクエストが格納された場合に、この優先度の高い優先度付きの前記承認済リクエストを他の前記承認済リクエストよりも先に送出することができる優先度付きキューとされ、
前記移転申請データベースは、
優遇すべき優良顧客の移転申請に係る前記移転申請データを、申請番号および優先度と対応付けて記憶する構成とされ、
前記承認処理手段は、
前記優良顧客の移転申請に係る前記移転申請データに対する承認を受け付けた場合に、優先度の高い優先度付きの前記承認済リクエストを前記キューに格納する構成とされ、
前記アカウント・キュー対応関係変更手段は、
複数の前記優良顧客のアカウントの前記アカウント別実績件数を、複数の前記キューに分散させて割り当てた後に、
複数の前記キューの各々で前記アカウント別実績件数を合計した前記集計期間中のキュー別合計件数が均一または略均一になるように、残っている各アカウントの前記アカウント別実績件数を複数の前記キューのいずれかに割り当てることにより、前記アカウント・キュー対応関係を示す情報を変更し、変更後の前記アカウント・キュー対応関係を示す情報を、前記アカウント・キュー対応関係記憶手段に記憶させる構成とされている
ことを特徴とする請求項４に記載のトランザクション管理システム。

【請求項8】

前記アカウント・キュー対応関係変更手段は、
複数の前記キューの各々で前記アカウント別実績件数を合計した前記集計期間中のキュー別合計件数が均一または略均一になるように、各アカウントの前記アカウント別実績件数を複数の前記キューのいずれかに割り当てる際には、
割当処理途中の各時点で各アカウントの前記アカウント別実績件数を合計した時点合計のキュー別合計件数が最も小さい前記キューを求め、求めた前記キューに対し、残っているアカウントのうち割当処理途中の各時点で前記アカウント別実績件数が最も大きいアカウントの前記アカウント別実績件数を割り当てる処理を繰り返す構成とされていることを特徴とする請求項４，５，７のいずれかに記載のトランザクション管理システム。

【請求項9】

請求項１，２，４～７のいずれかに記載のトランザクション管理システムとして、コンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ブロックチェーンを用いて移転することが可能なセキュリティトークンのトランザクションを管理するコンピュータにより構成されたトランザクション管理システムおよびプログラムに係り、例えば証券会社等の金融機関が、セキュリティトークンの移転時のブロックチェーンシステムへのトランザクションの送信管理を行う場合に利用できる。

【背景技術】

【0002】

近年、ブロックチェーンシステム上で発行され、管理されるセキュリティトークン（デジタル化された有価証券）が普及し始めている。ブロックチェーンシステムにおいて、銀行口座に相当する概念のものはアカウントと呼ばれ、ブロックチェーンシステム上で発行されている〇〇トークン（△△コイン等も含む。）は、その残高をトークン毎で、かつ、アカウント毎に管理されている。

【0003】

あるアカウントから別のアカウントにトークンを移転する場合、移転元のアカウントの所有者がトランザクションを生成し、送信する必要がある。この際、ナンス（nonce）と呼ばれる０以上の整数も同時に送信する必要がある。このナンスは、アカウント単位で管理されており、トランザクションをブロックチェーンシステムに送信する都度に、その値を１つずつ増やさなければならない。なお、このナンスの値の管理は、トークンの種類に依拠しない。

【0004】

一方、セキュリティトークン（ブロックチェーンを使って発行された有価証券）の場合には、証券会社が全投資家（自社の全顧客）のアカウントおよび保有トークンを預かる形になるので、トークン数およびアカウント数の双方ともに膨大な数となる。例えば、投資家Ａのアカウント（投資家とアカウントとは１対１の関係であるため、以下、アカウントＡという表現も使用する。）が保有するトークンＸ，Ｙをこの順でそれぞれ別のアカウントに移転しようとした場合、先に送信するトークンＸのトランザクションに、例えば、ナンスの値＝１を付したとすると、後に送信するトークンＹのトランザクションには、ナンスの値＝２を付さなければならない。双方のトランザクションは、移転元がアカウントＡで同じであるため、トークンの種類であるＸ，Ｙに依拠することなく、１つずつナンスの値を増やさなければならないからである。仮に、後に送信するトークンＹのトランザクションのナンスの値を１にした場合には、エラーとなる。

【0005】

なお、本発明では、ブロックチェーンシステムを構成するノードへのトランザクションの送信管理を行う際にキューを用いるが、この観点で本発明に関連するシステムとしては、キューを用いてトランザクションの送信管理を行うブロックチェーン・トランザクション・マネージャーが知られている（特許文献１参照）。このブロックチェーン・トランザクション・マネージャーでは、特許文献１の段落［００５０］，［００６２］に記載のように、本発明と同様に、低ナンス・エラーへの対処を課題として挙げている。すなわち、各トランザクションは、二重支出問題を防ぐため、ナンスと結び付られ、各トランザクションに割り当てられるナンスは、その前のトランザクションのナンスより１大きいことが要求されると記載されている。そして、このブロックチェーン・トランザクション・マネージャーにより複数のトランザクションが並列処理されている場合は、特許文献１の段落［００６４］に記載のように、ロック機構を使い、それらのトランザクションのうち、一度に１つしかナンスを計算しないようにしている。しかし、このブロックチェーン・トランザクション・マネージャーでは、特許文献１の［請求項１］に記載のように、本発明とは異なり、トランザクションをトランザクション・キューに入れている。

【0006】

また、本発明では、複数のキューを用いてもよいが、この観点で本発明に関連するシステムとしては、本願出願人による複数の発注キューを備えた取引所接続システムが知られている（特許文献２参照）。この特許文献２の段落［００８６］，［０１３２］に記載のように、証券会社等の取引参加者の取引所接続システム１０に設けられた取引参加者側の仮想サーバＡ，Ｂ，Ｃ，Ｄ等は、取引所システム７０に設けられた取引所側の対応する仮想サーバＡ，Ｂ，Ｃ，Ｄ等との間で電文の送受信を行うために設けられ、それぞれ取引所システム７０へ送出する電文データを一時的に保存する発注キューを備えている。従って、取引所接続システム１０には、複数の発注キューが設けられている。しかし、詳細は後述するように、本発明で複数のキューを設ける場合の趣旨や目的とは異なっている。

【0007】

また、特許文献２の取引所接続システム１０で複数の発注キューに分散して割り当てられるのは、銘柄（特許文献２の図５、段落［０１０７］～［０１１３］，［０１９９］～［０２０２］）または注文（特許文献２の段落［０１１４］～［０１１６］）である。一方、本発明では、詳細は後述するように、複数のキューに割り当てられるのは、アカウントであるため、特許文献２の取引所接続システム１０とは、キューに割り当てるものが相違し、かつ、割り当てて分散させる趣旨や目的も異なっている。

【0008】

さらに、特許文献２の図５に示すように、取引所接続システム１０では、複数の発注キューへの銘柄の割当を変更できるようになっているが、この銘柄の割当の変更は、特許文献２の段落［０２０３］に記載のように、異常発生に伴って、稼働している仮想サーバの台数が変化するので、つまり発注キューの数が変化するので、その変化に対応させているだけである。一方、上記のように、本発明で各アカウントを複数のキューのいずれかに割り当てる場合において、アカウント・キュー対応関係（各アカウントと各キューとの対応関係）を変更できるようにしてもよいが、詳細は後述するように、本発明でのアカウント・キュー対応関係の変更は、特許文献２の取引所接続システム１０での銘柄の割当の変更とは趣旨や目的が異なっている。

【先行技術文献】

【特許文献】

【0009】

【文献】特表２０２２－５３２４６４号公報（段落［００５０］，［００６２］，［００６４］、請求項１）

【文献】特許第６１６２８４３号掲載公報（段落［００８６］，［０１０７］～［０１１６］，［０１３２］，［０１９９］～［０２０３］、図５）

【発明の概要】

【発明が解決しようとする課題】

【0010】

前述したように、移転元が同じアカウントになっているトランザクションをブロックチェーンシステムに送信する場合は、その都度に、ナンスの値を１つずつ増やしてトランザクションに付さなければならない。

【0011】

また、証券会社がセキュリティトークンを扱う際の作業フローとして、その証券会社の申請担当者による「申請」と、その証券会社の承認担当者による「承認」とがある。すなわち、申請担当者が自社の顧客の移転申請を登録し、承認担当者がその移転申請を承認し、その後、移転のトランザクションが、ブロックチェーンシステムを構成するノードに送信されることになる。

【0012】

この際、複数の承認担当者が、短時間の間（ほぼ同時）に、移転元が同じアカウントになっている複数の移転申請を承認した場合、トランザクション毎にナンスを適切に割り当てる仕組みがなければ、トランザクションをノードに送信しても、エラーとなり、失敗してしまう可能性がある。ナンスに起因するエラーが発生した場合には、証券会社の承認担当者は、再度、移転申請を承認してトランザクションを送信しなければならず、事務的な負担が生じるうえ、トランザクションのブロックチェーンシステム（分散型台帳）への登録も遅れてしまう。従って、このナンスに起因するエラーの発生を回避することが望まれる。

【0013】

また、ナンスに起因するエラーの発生の問題は、前述した特許文献１にも記載され、このエラーの発生を回避することは既知の課題であるが、上述したように、証券会社には「申請」、「承認」という作業フローがあるので、その作業フローの中で、つまり作業フローを維持しつつ、その間のデータの流れとの関係で、効率的にエラーの発生を回避することが望まれる。

【0014】

本発明の目的は、ナンスに起因するエラーの発生を効率的に回避し、金融機関の担当者の作業負担の軽減およびトランザクションの早期登録を実現することができるトランザクション管理システムおよびプログラムを提供するところにある。

【課題を解決するための手段】

【0015】

本発明は、ブロックチェーンを用いて移転することが可能なセキュリティトークンのトランザクションを管理するコンピュータにより構成されたトランザクション管理システムであって、
金融機関の申請担当者若しくは顧客により登録されるか、または売買システムから取得して登録された移転元および移転先の各アカウントのアカウント情報を含む移転申請データを、申請番号と対応付けて記憶する移転申請データベースと、
この移転申請データベースに記憶された移転申請データについて金融機関の承認担当者による承認が得られた場合に申請番号を含む承認済リクエストを記憶する先入先出用のキューと、
移転申請データベースに記憶された移転申請データに対する承認担当者による承認を受け付け、承認済リクエストをキューに格納する承認処理手段と、
この承認処理手段による処理とは独立したタイミングで、キューから１件分の承認済リクエストを取り出し、取り出した承認済リクエストに含まれる申請番号を用いて、承認された移転申請データを移転申請データベースから取得する移転申請データ取得手段と、
この移転申請データ取得手段により取得した移転申請データに含まれる移転元のアカウントのアカウント情報を用いて、この移転元のアカウントについてのナンスの値を、通信回線を介してブロックチェーンシステムを構成するノードから取得するナンス取得手段と、
移転申請データ取得手段により取得した移転申請データ、およびナンス取得手段により取得したナンスの値を用いて、このナンスの値を付与したトランザクションデータを作成するトランザクション作成手段と、
このトランザクション作成手段により作成したトランザクションデータを、通信回線を介してノードに送信するトランザクション送信手段と、
このトランザクション送信手段により送信したトランザクションデータに対する処理結果の通知を、通信回線を介してノードから受信し、移転申請データ取得手段による次の承認済リクエストの処理への移行のための処理を実行する確認手段と
を備えたことを特徴とするものである。

【0016】

ここで、「確認手段」における「移転申請データ取得手段による次の承認済リクエストの処理への移行のための処理」は、確認手段から移転申請データ取得手段に、次の承認済リクエストの処理を開始させる指令を送る処理でもよく、移転申請データ取得手段が監視している情報を、確認手段が変更することにより、次の承認済リクエストの処理の開始タイミングを、確認手段から移転申請データ取得手段に伝達する処理でもよい。

【0017】

このような本発明のトランザクション管理システムにおいては、承認処理手段により、移転申請データベースに登録された移転申請データに対する承認担当者による承認を受け付け、申請番号を含む承認済リクエストをキューに格納する。また、この承認処理手段による処理とは独立したタイミングで、移転申請データ取得手段により、キューから１件分の承認済リクエストを取り出し、取り出した承認済リクエストに含まれる申請番号を用いて、承認された移転申請データを移転申請データベースから取得し、ナンス取得手段により、移転元のアカウントについてのナンスの値をノードから取得し、トランザクション作成手段により、ナンスの値を付与したトランザクションデータを作成し、トランザクション送信手段により、トランザクションデータをノードに送信し、確認手段により、送信したトランザクションデータに対する処理結果の通知をノードから受信し、移転申請データ取得手段による次の承認済リクエストの処理への移行のための処理を実行する。

【0018】

従って、移転申請データベースへの移転申請データの登録処理、並びに、承認処理手段による処理（登録された移転申請データに対する承認担当者による承認の受付およびキューへの承認済リクエストの格納処理）と、移転申請データ取得手段から確認手段までの処理とは、分離されている。よって、移転申請データ取得手段から確認手段までの処理が繰り返し実行されている最中でも、新たな移転申請データの登録、新たな承認、キューへの新たな格納の処理が実行される。そして、キューへの格納が行われると、移転申請データ取得手段から確認手段までの処理により、順次、ナンスが割り当てられ、トランザクションデータがノードに送信される。このため、ナンスに起因するエラーの発生を回避することが可能となる。

【0019】

また、「申請」のタイミングと「承認」のタイミングとの間には、タイムラグがあり、その間、移転申請データを保持する必要がある。また、移転元が同じアカウントになっている複数のトランザクションがある場合は、ナンスに起因するエラーが発生しないように、それらの複数のトランザクションの各々に１つずつ増えるナンスを付して順次ノードに送信する管理を行わなければならないので、それらの複数のトランザクションのうちの最初のトランザクションの送信タイミングと、後続のトランザクションの送信タイミングとの間には、タイムラグがあり、その間、後続のトランザクションを送信しない状態で保持する必要がある。前者の保持は、移転申請データベースにより実現され、後者の保持は、キューおよび移転申請データベースにより実現される。従って、移転申請データベースは、双方の保持に利用されることになるので、ナンスに起因するエラーの発生を、効率的に回避することが可能となる。このため、前述した特許文献１とは異なり、キューにトランザクションデータ（トークンＩＤ、移転元および移転先の各アカウントのアカウント情報、移転数量などのデータ）を入れるのではなく、申請番号を含む承認済リクエストを入れるので、リソースの有効活用が図られ、これらにより前記目的が達成される。

【0020】

＜複数のキューを備え、アカウント・キュー対応関係記憶手段に記憶されたアカウント・キュー対応関係を示す情報に従って、承認済リクエストを格納するキューを決める構成＞

【0021】

また、前述したトランザクション管理システムにおいて、
キューは、複数設けられ、
各アカウントが移転元になっている移転申請データに係る承認済リクエストを複数のキューのうちのいずれに格納するのかを定めるアカウント・キュー対応関係を示す情報として、各アカウントのアカウント情報と各キューのキュー識別情報とを対応付けて記憶するアカウント・キュー対応関係記憶手段を備え、
承認処理手段は、
移転申請データベースに記憶された移転申請データに対する承認担当者による承認を受け付け、移転申請データに含まれる移転元のアカウントのアカウント情報を用いて、この移転申請データに係る承認済リクエストが格納されるキーのキー識別情報をアカウント・キュー対応関係記憶手段から取得し、取得したキー識別情報のキューに承認済リクエストを格納する構成としてもよい。

【0022】

このように複数のキューを備え、アカウント・キュー対応関係記憶手段に記憶されたアカウント・キュー対応関係を示す情報に従って、承認済リクエストを格納するキューを決める構成とした場合には、移転元が同一のアカウントになっている移転申請データに係る承認済リクエストは、予め定められたアカウント・キュー対応関係に従って、同一のキューに格納されるので、ナンスに起因するエラーの発生を回避することが可能となる。

【0023】

また、複数のキューを備えているので、移転元が異なるアカウントになっている移転申請データに係る承認済リクエストは、複数のキューに分散して格納され、それぞれのキューについて、並列的に、移転申請データ取得手段から確認手段までの処理が行われるため、同時期または略同時期に発生した複数のトランザクションデータを早期にノードに送信し、早期に分散型台帳に登録することが可能となる。

【0024】

＜一括承認を受け付ける構成＞

【0025】

さらに、以上に述べたトランザクション管理システムにおいて、
承認処理手段は、
移転申請データベースに記憶された複数の移転申請データに対する承認担当者による一括承認を受け付け、一括承認された複数の移転申請データの中に、同じ移転元のアカウントの移転申請データが含まれている場合に、同じ移転元のアカウントの複数の移転申請データに係る複数の承認済リクエストを１つのグループとしてまとめたグループ承認済リクエストをキューに格納する構成とされ、
移転申請データ取得手段は、
キューから１つのグループ承認済リクエストを取り出した場合には、グループ承認済リクエストに含まれる複数の申請番号を用いて、一括承認された複数の移転申請データの中の同じ移転元のアカウントの複数の移転申請データを移転申請データベースから取得する構成とされ、
ナンス取得手段は、
移転申請データ取得手段によりグループ承認済リクエストが取り出された場合に、移転申請データベースから取得した複数の移転申請データに含まれている同じ移転元のアカウントのアカウント情報を用いて、この移転元のアカウントについてのナンスの値を、通信回線を介してノードから取得する構成とされ、
トランザクション作成手段は、
移転申請データ取得手段により取得した複数の移転申請データ、およびナンス取得手段により取得したナンスの値を用いて、取得したナンスの値およびこの値に続くナンスの値をそれぞれ付与した複数のトランザクションデータを作成する構成とされ、
トランザクション送信手段は、
トランザクション作成手段により作成した最も若いナンスの値を付与したトランザクションデータをノードに送信した後に、ノードからの処理結果の通知を待つことなく、最も若いナンスの値に続くナンスの値を付与したトランザクションデータをノードに送信する構成とされ、
確認手段は、
トランザクション送信手段により送信した１つのグループ承認済リクエストに係る複数のトランザクションデータのうちの最後に送信したトランザクションデータに対する処理結果の通知を、通信回線を介してノードから受信した場合に、移転申請データ取得手段による次の承認済リクエストの処理への移行のための処理を実行する構成としてもよい。

【0026】

このように一括承認を受け付ける構成とした場合には、キューに格納された承認済リクエストを１件ずつ取り出し、１件ずつナンスの値を取得し、取得したナンスの値をトランザクションに付してノードに送信し、その処理結果の通知を受信して次の承認済リクエストの処理に移行するという原則的な処理に対し、ナンスに起因するエラーを発生させない例外的な処理を行って、トランザクションの送信処理を迅速に進めることが可能となる。

【0027】

すなわち、一括承認は、一人の承認担当者による一時期の作業であるから、一括承認された複数の移転申請データに係る複数の承認済リクエストをグループ化してまとめて１つのグループ承認済リクエストとして取り扱えば、それらの複数の承認済リクエストの間に、タイミング的に、他の承認担当者による他の承認済リクエストが入り込むことはないので、それらのグループ化された複数の承認済リクエストに係る各トランザクションデータに付すナンスの値を連続させること（１つずつ増やしていくこと）ができる。換言すれば、同じ承認担当者による同時期または略同時期の複数の承認が行われたとしても、それが一括承認でなければ、それらの複数の承認の間に、他の承認担当者による他の承認が入る可能性があり、それらが同じ移転元のアカウントについての移転申請データに対する承認であれば、ナンスの値が１つずつ増えるような管理を行わなければならないので、原則的な処理を行うことになる。しかし、一括承認であれば、キューには、一括承認を行った承認担当者による複数の承認済リクエストが必ず１つのグループとして格納され、他の承認担当者による他の承認済リクエストがそれらの間に入り込むことはないので、例外的な処理が可能となる。

【0028】

＜格納実績を集計し、アカウント別実績件数を用いて、アカウント・キュー対応関係を変更する構成＞

【0029】

また、前述した複数のキューを備え、アカウント・キュー対応関係記憶手段に記憶されたアカウント・キュー対応関係を示す情報に従って、承認済リクエストを格納するキューを決める構成とする場合において、
移転申請データベースに記憶された移転申請データの移転元のアカウントのアカウント情報および処理状況を示すステータスを用いて、各アカウントが移転元になっている移転申請データに係る承認済リクエストが、集計期間中にキューに実際に格納されたアカウント別実績件数を集計して求める格納実績集計手段と、
この格納実績集計手段により集計して得られたアカウント別実績件数を、移転元の各アカウントのアカウント情報と関連付けて記憶する格納実績記憶手段と、
この格納実績記憶手段に記憶された各アカウントのアカウント別実績件数を用いて、複数のキューの各々でアカウント別実績件数を合計した集計期間中のキュー別合計件数が均一または略均一になるように、各アカウントのアカウント別実績件数を複数のキューのいずれかに割り当てることにより、アカウント・キュー対応関係を示す情報を変更し、変更後のアカウント・キュー対応関係を示す情報を、アカウント・キュー対応関係記憶手段に記憶させるアカウント・キュー対応関係変更手段と
を備えた構成としてもよい。

【0030】

ここで、「格納実績集計手段」における「集計期間」は、例えば、１日、１週間、１か月、半年、１年など、任意である。また、「アカウント・キュー対応関係変更手段」によるアカウント・キュー対応関係の変更は、定期的に繰り返し行ってもよく、不定期に行ってもよく、後者の不定期の場合は、金融機関のシステム担当者が決めた任意のタイミングで行ってもよい。

【0031】

このように格納実績を集計し、アカウント別実績件数を用いて、アカウント・キュー対応関係を変更する構成とした場合には、集計期間中の各キューへの格納実績を用いてアカウント・キュー対応関係を変更することができるので、複数のキューのそれぞれについて行われる処理（移転申請データ取得手段から確認手段までの処理を繰り返す処理）の負荷を、均等または略均等に分散させることができるため、トランザクションデータのノードへの送信、分散型台帳への登録を、より一層迅速に行うことが可能となる。

【0032】

＜複数の時間帯に分けて格納実績を集計し、承認が行われた時刻について時間帯に偏りのあるアカウントを決定し、時間帯に偏りのあるアカウントを複数のキューに分散させて割り当てる構成＞

【0033】

さらに、上述した格納実績を集計し、アカウント別実績件数を用いて、アカウント・キュー対応関係を変更する構成とする場合において、
格納実績集計手段は、
移転申請データベースに記憶された移転申請データの承認日時を用いて、午前および午後、またはその他の複数の時間帯に分けて、承認済リクエストが集計期間中にキューに実際に格納されたアカウント別実績件数を集計して求め、求めた時間帯毎のアカウント別実績件数を用いて、承認が行われた時刻について時間帯に偏りのあるアカウントを決定する構成とされ、
アカウント・キュー対応関係変更手段は、
格納実績集計手段により決定された時間帯に偏りのあるアカウントのアカウント別実績件数を、複数のキューに分散させて割り当てた後に、
複数のキューの各々でアカウント別実績件数を合計した集計期間中のキュー別合計件数が均一または略均一になるように、残っている各アカウントのアカウント別実績件数を複数のキューのいずれかに割り当てることにより、アカウント・キュー対応関係を示す情報を変更し、変更後のアカウント・キュー対応関係を示す情報を、アカウント・キュー対応関係記憶手段に記憶させる構成としてもよい。

【0034】

このように複数の時間帯に分けて格納実績を集計し、承認が行われた時刻について時間帯に偏りのあるアカウントを決定し、時間帯に偏りのあるアカウントを複数のキューに分散させて割り当てる構成とした場合には、時間帯を考慮せずに１日を通して見たときには、複数のキューのそれぞれに格納される承認済リクエストの件数が均等または略均等に分散しているが、例えば、午前中に申請担当者に手続を依頼することが多い顧客（アカウント）が、同じキューに集まる等により、時間帯で見たときに、複数のキューのそれぞれに格納される承認済リクエストの件数に偏りが生じるといった不都合を未然に防止することが可能となるので、トランザクションデータのノードへの送信、分散型台帳への登録を、より一層迅速に行うことが可能となる。

【0035】

＜優先度付きキューを用いる構成＞

【0036】

また、前述したトランザクション管理システムにおいて、
キューは、
他の承認済リクエストよりも優先度の高い優先度付きの承認済リクエストが格納された場合に、この優先度の高い優先度付きの承認済リクエストを他の承認済リクエストよりも先に送出することができる優先度付きキューとされ、
移転申請データベースは、
緊急で移転する必要のある優先承認対象として指定された移転申請に係る移転申請データ、および優遇すべき優良顧客の移転申請に係る移転申請データを、申請番号および優先度と対応付けて記憶する構成とされ、
承認処理手段は、
特別な権限を有する予め定められた承認担当者による承認を受け付けた場合、並びに、優先承認対象として指定された移転申請データおよび優良顧客の移転申請に係る移転申請データに対する承認を受け付けた場合に、優先度の高い優先度付きの承認済リクエストをキューに格納する構成としてもよい。

【0037】

このように優先度付きキューを用いる構成とした場合には、キューに先に格納された承認済リクエストが、移転申請データ取得手段により先に取り出されるという原則的な処理に対し、特別な権限を有する承認担当者による承認を受け付けたとき、あるいは、緊急の移転申請や、優良顧客の移転申請に対する承認を受け付けたときに、他の承認済リクエストよりも先に、それらの優先度の高い優先度付きの承認済リクエストが取り出されるようにする例外的な処理を行うことが可能となる。

【0038】

＜優先度付きキューを用いて優良顧客の移転申請に係る承認済リクエストの優先度を高めるとともに、格納実績を集計し、アカウント別実績件数を用いて、アカウント・キュー対応関係を変更する際に、優良顧客のアカウントを複数のキューに分散させて割り当てる構成＞

【0039】

さらに、前述した格納実績を集計し、アカウント別実績件数を用いて、アカウント・キュー対応関係を変更する構成とする場合において、
複数のキューのいずれも、
他の承認済リクエストよりも優先度の高い優先度付きの承認済リクエストが格納された場合に、この優先度の高い優先度付きの承認済リクエストを他の承認済リクエストよりも先に送出することができる優先度付きキューとされ、
移転申請データベースは、
優遇すべき優良顧客の移転申請に係る前記移転申請データを、申請番号および優先度と対応付けて記憶する構成とされ、
承認処理手段は、
優良顧客の移転申請に係る移転申請データに対する承認を受け付けた場合に、優先度の高い優先度付きの承認済リクエストをキューに格納する構成とされ、
アカウント・キュー対応関係変更手段は、
複数の優良顧客のアカウントのアカウント別実績件数を、複数のキューに分散させて割り当てた後に、
複数のキューの各々でアカウント別実績件数を合計した集計期間中のキュー別合計件数が均一または略均一になるように、残っている各アカウントのアカウント別実績件数を複数のキューのいずれかに割り当てることにより、アカウント・キュー対応関係を示す情報を変更し、変更後のアカウント・キュー対応関係を示す情報を、アカウント・キュー対応関係記憶手段に記憶させる構成としてもよい。

【0040】

このように優先度付きキューを用いて優良顧客の移転申請に係る承認済リクエストの優先度を高めるとともに、格納実績を集計し、アカウント別実績件数を用いて、アカウント・キュー対応関係を変更する際に、優良顧客のアカウントを複数のキューに分散させて割り当てる構成とした場合には、優良顧客のアカウントについての承認済リクエストが、同じキューに集まり、優先度の高い優先度付きの承認済リクエストであるにもかかわらず、キューへの滞留時間が長くなってしまうという不都合を未然に防止することが可能となる。

【0041】

＜格納実績を集計し、アカウント別実績件数を用いて、アカウント・キュー対応関係を変更する際に、割当処理途中の各時点でキュー別合計件数が最も小さいキューを求め、そのキューに対し、残っているアカウントのうち割当処理途中の当該時点でアカウント別実績件数が最も大きいアカウントを割り当てる構成＞

【0042】

集計期間中のキュー別合計件数が均一または略均一になるように、残っているアカウントのアカウント別実績件数を、複数のキューのいずれかに割り当てる方法は、１通りではないが、次の割当方法を採用すると、キュー別合計件数を容易に均一または略均一にすることが可能となる。

【0043】

すなわち、前述した格納実績を集計し、アカウント別実績件数を用いて、アカウント・キュー対応関係を変更する構成とする場合において、
アカウント・キュー対応関係変更手段は、
複数のキューの各々でアカウント別実績件数を合計した集計期間中のキュー別合計件数が均一または略均一になるように、各アカウントのアカウント別実績件数を複数のキューのいずれかに割り当てる際には、
割当処理途中の各時点で各アカウントのアカウント別実績件数を合計した時点合計のキュー別合計件数が最も小さいキューを求め、求めたキューに対し、残っているアカウントのうち割当処理途中の各時点でアカウント別実績件数が最も大きいアカウントのアカウント別実績件数を割り当てる処理を繰り返す構成とすることができる。

【0044】

このように割当処理途中の各時点でキュー別合計件数が最も小さいキューを求め、求めたキューに対し、残っているアカウントのうち割当処理途中の当該時点でアカウント別実績件数が最も大きいアカウントを割り当てる構成とした場合には、キュー別合計件数を容易に均一または略均一にすることが可能となるとともに、特別な目的を持った割当（時間帯に偏りのある顧客のアカウントの各キューへの分散割当や、優良顧客のアカウントの各キューへの分散割当）と容易に組み合わせることが可能となる。

【0045】

＜プログラムの発明＞

【0046】

そして、本発明のプログラムは、以上に述べたトランザクション管理システムとして、コンピュータを機能させるためのものである。

【0047】

なお、上記のプログラムまたはその一部は、例えば、光磁気ディスク（ＭＯ）、コンパクトディスク（ＣＤ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、フレキシブルディスク（ＦＤ）、磁気テープ、読出し専用メモリ（ＲＯＭ）、電気的消去および書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、フラッシュディスク等の記録媒体に記録して保存や流通等させることが可能であるとともに、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等の有線ネットワーク、あるいは無線通信ネットワーク、さらにはこれらの組合せ等の伝送媒体を用いて伝送することが可能であり、また、搬送波に載せて搬送することも可能である。さらに、上記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。

【発明の効果】

【0048】

以上に述べたように本発明によれば、キューに承認済リクエストを格納するまでの処理と、キューから承認済リクエストを取り出し、ナンスの値をノードから取得し、ナンスの値を付したトランザクションデータをノードに送信する処理とが分離されているので、ナンスに起因するエラーの発生を回避し、金融機関の担当者の作業負担の軽減およびトランザクションの早期登録を実現することができるとともに、キューには、申請番号を含む承認済リクエストを格納し、キューから取り出した承認済リクエストに含まれる申請番号を用いて移転申請データベースから移転申請データを取得してトランザクションデータを作成するので、リソースの有効活用を図り、効率的にエラーの発生の回避を実現することができるという効果がある。

【図面の簡単な説明】

【0049】

【図1】本発明の一実施形態のトランザクション管理システムの全体構成図。

【図2】前記実施形態の移転申請データベースの構成図。

【図3】前記実施形態のキューの構成図。

【図4】前記実施形態のアカウント・キュー対応関係記憶手段の構成図。

【図5】前記実施形態の格納実績記憶手段の構成図。

【図6】前記実施形態のアカウント・キュー対応関係の変更例を示す図。

【図7】前記実施形態の個人情報記憶手段の構成図。

【図8】前記実施形態の分散型台帳記憶手段の構成図。

【図9】前記実施形態の分散型台帳記憶手段内のステートルート算出用データ保存領域の構成図。

【図10】前記実施形態の一括承認の処理の説明図。

【図11】前記実施形態の移転申請の受付および承認、並びにトランザクション送信の流れを示すフローチャートの図。

【図12】前記実施形態の各キューへのアカウントの割当処理の流れを示すフローチャートの図。

【発明を実施するための形態】

【0050】

以下に本発明の一実施形態について図面を参照して説明する。図１には、本実施形態のトランザクション管理システム１０の全体構成が示されている。また、図２には、移転申請データベース４１の構成が示され、図３には、キュー４２の構成が示され、図４には、アカウント・キュー対応関係記憶手段４３の構成が示され、図５には、格納実績記憶手段４４の構成が示されている。図６には、アカウント・キュー対応関係の変更例が示されている。図７には、個人情報記憶手段４５の構成が示され、図８には、分散型台帳記憶手段６０の構成が示され、図９には、分散型台帳記憶手段６０内のステートルート算出用データ保存領域６２の構成が示されている。図１０は、一括承認の処理の説明図である。さらに、図１１には、移転申請の受付および承認、並びにトランザクション送信の流れがフローチャートで示され、図１２には、各キューへのアカウントの割当処理の流れがフローチャートで示されている。

【0051】

＜トランザクション管理システム１０の全体構成＞

【0052】

図１において、トランザクション管理システム１０は、証券会社等の金融機関が設置・運営する金融機関サーバ２０と、この金融機関サーバ２０と通信回線１を介して接続されたノード５０とを備えている。また、金融機関サーバ２０には、Ｐ２Ｐ（ピア・ツー・ピア）以外のネットワーク２を介して、当該金融機関（自社）の担当者（申請担当者、承認担当者、システム担当者）が操作する複数台の担当者端末７０が接続されている。

【0053】

ノード５０は、当該金融機関（自社）が設置したノードであり、他の証券会社等の金融機関（他社）が設置した複数のノード８０とＰ２Ｐネットワーク３で接続され、自社のノード５０と、他社の複数のノード８０とにより、ブロックチェーンシステム９０が構成されている。

【0054】

ここで、通信回線１は、例えばＬＡＮやイントラネット等の内部ネットワークであるが、一旦、外部を経由する外部ネットワークとしてもよい。また、ネットワークではなく、専用線としてもよい。さらに、金融機関サーバ２０と、ノード５０とが、同じコンピュータ内に一体化されて構築されている場合には、この通信回線１は不要であるが、請求項における「通信回線」の解釈上、コンピュータ内のバスであると考えてもよい。

【0055】

ネットワーク２は、Ｐ２Ｐネットワークではなく（ネットワーク２内のコンピュータは、Ｐ２Ｐ接続されていない。）、主としてインターネットにより構成された外部ネットワークであり、インターネットと、ＬＡＮやイントラネット等の内部ネットワークとの組合せでもよく、有線であるか無線であるか、さらには有線および無線の混在型であるかは問わず、要するに、複数地点（距離の長短は問わない。）間で、ある程度の速度をもって情報を伝送することができるものであればよい。

【0056】

ネットワーク３は、分散型台帳形成用（ブロックチェーンシステム９０の構成用）のＰ２Ｐネットワークであり、分散型台帳への参加者ノード５０，８０は、Ｐ２Ｐ接続されることになる。具体的には、ネットワーク３は、例えばインターネットや通信事業者が提供する各種のサービス網等の公衆ネットワークを使って形成された仮想的なネットワーク（インターネット上にＶＰＮ（バーチャル・プライベート・ネットワーク）を用いて構築されたイントラネットを含む。）などである。従って、ネットワーク３は、物理的には、ネットワーク２（Ｐ２Ｐ以外）と同じ通信回線を使用していてよい。

【0057】

金融機関サーバ２０は、１台または複数台のコンピュータにより構成され、セキュリティトークンのトランザクションの送信管理を含む各種処理を実行する処理手段２０Ａと、この処理手段２０Ａに接続された移転申請データベース４１、キュー４２、アカウント・キュー対応関係記憶手段４３、格納実績記憶手段４４、顧客情報記憶手段４５、担当者情報記憶手段４６、およびキュー別案件処理状況記憶手段４７とを備えて構成されている。

【0058】

処理手段２０Ａは、申請受付手段２１と、承認処理手段２２と、移転申請データ取得手段２３と、ナンス取得手段２４と、トランザクション作成手段２５と、トランザクション送信手段２６と、確認手段２７と、格納実績集計手段２８と、アカウント・キュー対応関係変更手段２９と、設定手段３０とを含んで構成されている。

【0059】

ここで、処理手段２０Ａに含まれる各手段２１～３０は、金融機関サーバ２０の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段２１～３０の詳細は後述する。

【0060】

移転申請データベース４１、キュー４２、アカウント・キュー対応関係記憶手段４３、格納実績記憶手段４４、顧客情報記憶手段４５、担当者情報記憶手段４６、およびキュー別案件処理状況記憶手段４７としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。但し、格納実績記憶手段４４は、格納実績集計手段２８からアカウント・キュー対応関係変更手段２９にデータを渡すことができれば、主メモリ（揮発性メモリ）としてもよい。また、キュー別案件処理状況記憶手段４７も主メモリとしてもよい。これらの移転申請データベース４１、キュー４２、および各記憶手段４３～４７の詳細は後述する。

【0061】

ノード５０は、１台または複数台のコンピュータにより構成され、セキュリティトークンの取引や残高管理に関する各種処理を実行する処理手段５０Ａと、この処理手段５０Ａに接続された分散型台帳記憶手段６０とを備えている。

【0062】

処理手段５０Ａは、ナンス取得要求応答手段５１と、トランザクション記録手段５２とを含んで構成されている。

【0063】

ここで、処理手段５０Ａに含まれる各手段５１，５２は、ノード５０の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段５１，５２の詳細は後述する。

【0064】

なお、処理手段５０Ａの機能には、ブロックチェーンが有する基本的な機能と、スマートコントラクトにより実現される機能とがあるが、これらの機能は、いずれも本発明のために特別に設けた機能ではなく、自社のノード５０および他社の複数のノード８０に共通の機能であるという点で、区別する必要はない。

【0065】

分散型台帳記憶手段６０としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。この分散型台帳記憶手段６０の詳細は後述する。

【0066】

担当者端末７０は、コンピュータにより構成されている。また、この担当者端末７０は、例えば、スマートフォンやタブレット端末等の携帯機器であってもよい。

【0067】

ノード８０は、１台または複数台のコンピュータにより構成され、ノード５０と同様な構成および機能を備えている。

【0068】

＜金融機関サーバ２０／処理手段２０Ａ／申請受付手段２１の構成＞

【0069】

申請受付手段２１は、証券会社等の金融機関（自社）の申請担当者により入力されて担当者端末７０からネットワーク２を介して送信されてくる移転申請データ（トークンＩＤ、移転元および移転先の各アカウントのアカウント情報（アドレス）、移転数量を含む。）を受信し、受信した移転申請データを、申請番号と関連付けて移転申請データベース４１（図２参照）に記憶させる処理を実行するものである。

【0070】

ここで、金融機関の申請担当者は、顧客からの移転取引の依頼を受けて移転申請データを移転申請データベース４１（図２参照）に登録する。また、申請受付手段２１は、担当者端末７０からの金融機関の申請担当者による移転申請データだけではなく、顧客端末（不図示）からの顧客自身による移転申請データを直接に受け付けてもよい。

【0071】

そして、トランザクション管理システム１０で取り扱う取引には、証券会社等の金融機関（自社）とその顧客との間の相対取引が含まれる。従って、アカウントには、証券会社等の金融機関（自社）のアカウントも含まれる。また、金融機関（自社）とその顧客との間の相対取引の他に、自社の顧客間の取引も含まれる。

【0072】

さらに、トランザクション管理システム１０で取り扱う取引には、自社の顧客間で成立したＰＴＳ（Proprietary Trading System、私設取引システム）取引を含めてもよく、成立したＰＴＳ取引をブロックチェーンシステム９０に反映させる処理を実行するようにしてもよい。この場合、金融機関の申請担当者が担当者端末７０を操作し、その操作に基づき、申請受付手段２１により、売買システムである私設取引システム（ＰＴＳ）から成立した取引データを取得し、移転申請データとして移転申請データベース４１（図２参照）に記憶させてもよく、あるいは、申請受付手段２１が、売買システムである私設取引システム（ＰＴＳ）から成立した取引データを取得し、移転申請データとして移転申請データベース４１に記憶させてもよい。

【0073】

そして、申請受付手段２１は、個人情報記憶手段４５（図７）を参照し、登録する移転申請データの移転元のアカウントが、優良顧客のアカウントであるか否かを判断し、優良顧客のアカウントである場合には、移転申請データと対応させて、優良顧客に基づく優先度（図７の例では、優先度＝１）を、移転申請データベース４１（図２参照）における「緊急または優良顧客に基づく優先度」のカラムに記憶させる処理も実行する。

【0074】

また、申請受付手段２１は、緊急で移転する必要のある優先承認対象として指定された移転申請である場合（緊急の案件であることは、申請担当者が認識しているので、申請担当者が緊急の指定をする。）には、移転申請データと対応させて、緊急に基づく優先度を、移転申請データベース４１（図２参照）における「緊急または優良顧客に基づく優先度」のカラムに記憶させる処理も実行する。

【0075】

＜金融機関サーバ２０／処理手段２０Ａ／承認処理手段２２の構成＞

【0076】

承認処理手段２２は、担当者端末７０からネットワーク２を介して送信されてくる金融機関（自社）の承認担当者の承認対象表示要求に応じ、移転申請データベース４１（図２参照）に記憶された移転申請データのうちの未承認の移転申請データ（ステータスが「承認待ち」になっているもの）の全部、または当該承認担当者が承認すべき一部の移転申請データを、ネットワーク２を介して担当者端末７０に送信し、その後、送信した移転申請データに対する承認担当者による承認を受け付け、承認された移転申請データの申請番号を含む承認済リクエストを、キュー４２に格納する処理を実行するものである。なお、申請（申請担当者）と、承認担当者との関係は、１対多でも、多対多でもよく、承認作業が滞ることのない仕組みや運用があれば、１対１、多対１でもよい。

【0077】

この際、本実施形態では、複数（一例として３つ）のキュー４２Ａ，４２Ｂ，４２Ｃが設けられているので、承認処理手段２２は、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されたアカウント・キュー対応関係を示す情報を用いて、承認済リクエストを格納するキュー４２を決定する。すなわち、承認処理手段２２は、承認を受け付けた移転申請データに含まれる移転元のアカウントのアカウント情報（アドレス）を用いて、アカウント・キュー対応関係記憶手段４３から、移転元のアカウントに対応するキュー４２のキュー識別情報（キュー番号）を取得し、そのキュー４２に、承認された移転申請データの申請番号を含む承認済リクエストを格納する。なお、キュー４２が１つの場合は、このような格納先のキュー４２を決定する処理は省略することができる。

【0078】

そして、承認処理手段２２は、承認済リクエストをキュー４２に格納した後に、移転申請データベース４１（図２参照）において、取り出した承認済リクエストに係る移転申請データ（取り出した承認済リクエストに含まれる申請番号の移転申請データ）のレコードのステータスを「承認待ち」から「処理中」に変更する。

【0079】

また、承認処理手段２２は、移転申請データベース４１（図２参照）に記憶された複数の移転申請データに対する承認担当者による一括承認を受け付け、一括承認された複数の移転申請データの中に、同じ移転元のアカウントの移転申請データが含まれている場合には、同じ移転元のアカウントの複数の移転申請データに係る複数の承認済リクエストを１つのグループとしてまとめたグループ承認済リクエストをキュー４２に格納する処理を実行する。そして、本実施形態では、複数（一例として３つ）のキュー４２Ａ，４２Ｂ，４２Ｃが設けられているので、移転元のアカウントが同じであると判断された当該アカウントに対応するキュー４２（アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されたアカウント・キュー対応関係で定まるキュー４２）に、グループ承認済リクエストを格納する。このグループ承認済リクエストには、複数の申請番号（一括承認された複数の移転申請データの各々の申請番号）が含まれている。

【0080】

また、グループ承認済リクエストは、アカウントが異なれば、複数生成されてもよく、例えば、一括承認された複数の移転申請データの中に、移転元のアカウントＡの移転申請データが３つあり、移転元のアカウントＢの移転申請データが２つあり、移転元のアカウントＣの移転申請データが４つあるとすると、アカウントＡに対応するキュー４２に格納されるグループ承認済リクエスト（３つの申請番号を含む。）と、アカウントＢに対応するキュー４２に格納されるグループ承認済リクエスト（２つの申請番号を含む。）と、アカウントＣに対応するキュー４２に格納されるグループ承認済リクエスト（４つの申請番号を含む。）とが生成される。

【0081】

一方、一括承認された複数の移転申請データの中に、同じ移転元のアカウントの移転申請データが含まれていない場合（すなわち、全ての移転申請データの移転元のアカウントがそれぞれ異なっている場合）には、それらの移転申請データについては、通常の承認済リクエスト（申請番号を１つしか含んでいない承認済リクエスト）を、それぞれのアカウントに対応するキュー４２に格納する。また、一括承認された複数の移転申請データの全部について移転元のアカウントが同じになっているというわけではなく、一部の移転申請データについて移転元のアカウントが同じであり、残りの一部の移転申請データについては、それぞれ異なる移転元のアカウントになっている場合における残りの一部の移転申請データについても同様であり、通常の承認済リクエスト（申請番号を１つしか含んでいない承認済リクエスト）を、それぞれのアカウントに対応するキュー４２に格納する。

【0082】

具体的には、図１０に示すように、申請番号＝T0001，T0003，T0005の移転申請データが一括承認されたとすると、申請番号＝T0001，T0003の移転申請データの移転元がアカウントＡで同じであるため、これらの移転申請データに係る承認済リクエストがグループ化されて、２つの申請番号＝T0001，T0003を含むグループ承認済リクエストが生成される。なお、後述するように、グループ化される各移転申請データの優先度は同じでなければならないが、図１０の例では、優先度＝０で同じである。そして、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されたアカウント・キュー対応関係で、アカウントＡが第１のキュー４２Ａに割り当てられているとすれば、２つの申請番号＝T0001，T0003を含むグループ承認済リクエストは、優先度＝０を付されて第１のキュー４２Ａに格納される。

【0083】

また、申請番号＝T0005の移転申請データの移転元は、アカウントＥであるため、上記の申請番号＝T0001，T0003の移転申請データと一括承認されたとしても、アカウントが異なるため、グループ化されない。また、一括承認された複数の移転申請データの中に、移転元がアカウントＥになっている他の移転申請データはないので、アカウントＥについてのグループ承認済リクエストが生成されることもない。従って、１つの申請番号＝T0005を含む通常の承認済リクエストが生成される。そして、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されたアカウント・キュー対応関係で、アカウントＥが第２のキュー４２Ｂに割り当てられているとすれば、１つの申請番号＝T0005を含む通常の承認済リクエストは、優先度＝０を付されて第２のキュー４２Ｂに格納される。

【0084】

また、１つのグループ承認済リクエスト（複数の申請番号を含む。）は、キュー４２に格納する１つの要素として生成してもよく、複数の要素（グループ化する複数の移転申請データの数と同数の要素）として生成してもよい。ここでいう要素は、キュー４２で先入先出の管理処理を行う場合の１単位であり、要素同士の仕切り方は、採用するキュー４２の仕様で定めるところによる。

【0085】

前者の場合は、移転申請データ取得手段２３により、キュー４２から１つの要素を取り出すと、その１つの要素がグループ承認済リクエストであり、取り出した１つの要素の中に、複数の申請番号が含まれていることになる。

【0086】

一方、後者の場合は、移転申請データ取得手段２３により、キュー４２から１つの要素を取り出すと、それはグループ化された承認済リクエスト群のうちの１つであり、取り出した１つの要素の中には、その要素がグループ化されていることを示す情報として、グループ化された要素の数（グループ化された承認済リクエストの数）およびグループの何番目の要素（グループの何番目の承認済リクエスト）であるかを示す情報が含まれているか、あるいは、グループの最初の要素、最後の要素であることを示す情報（すなわち、この要素からグループが始まり、この要素でグループが終わるという情報）が含まれている。従って、後者の場合は、移転申請データ取得手段２３によるキュー４２からのグループ承認済リクエストの取り出し処理は、１つずつ要素を取り出し、取り出した要素がグループを形成しているか否かを判断しながら、連続して複数の要素を取り出す処理となる。

【0087】

さらに、承認処理手段２２は、特別な権限を有する予め定められた承認担当者（担当者情報記憶手段４６で定められている。）による承認を受け付けた場合、並びに、緊急の移転を要する優先承認対象として指定された移転申請データ（移転申請データベース４１（図２参照）に緊急に基づく優先度が記憶されている。）および優良顧客の移転申請に係る移転申請データ（移転申請データベース４１に優良顧客に基づく優先度が記憶されている。）に対する承認を受け付けた場合には、優先度の高い（本実施形態では、優先度＝１の）優先度付きの承認済リクエストをキュー４２に格納する。そして、承認処理手段２２は、特別な権限を有する予め定められた承認担当者による承認を受け付けた場合には、移転申請データベース４１（図２参照）における「承認担当者の特別権限に基づく優先度」のカラムに、高い優先度（本実施形態では、優先度＝１）を記憶させ、そうでない承認担当者（図２の例では、大和友子、大和梅子、大和五郎）による承認を受け付けた場合には、低い優先度（本実施形態では、優先度＝０）を記憶させる。従って、図２に示すように、ステータスが「承認待ち」になっている移転申請データについては、未だ承認処理手段２２による処理が行われていないので、そのレコードの「承認担当者の特別権限に基づく優先度」のカラムには、優先度は設定されていない。なお、承認処理手段２２による処理を行う際には、移転申請データベース４１における「緊急または優良顧客に基づく優先度」のカラムには、申請受付手段２１による処理で設定された優先度（本実施形態では、０または１）が既に記憶されている状態である。

【0088】

また、承認処理手段２２は、優先度の異なる承認済リクエスト（移転申請データ）をグループ化することはできない。但し、承認担当者の特別権限に基づく優先度は、当該承認担当者の承認で設定されるので、一括承認を行った承認担当者が、特別な権限を有する承認担当者だった場合には、同じ優先度になるため、問題は生じない。また、一括承認されてグループ化される移転申請データは、同じ移転元のアカウントの移転申請データであるから、そのアカウントの顧客が、優良顧客である場合は、同じ優先度（本実施形態では、優先度＝１）になり、優良顧客でない場合も、同じ優先度（本実施形態では、優先度＝０）になるため、問題は生じない。従って、一括承認された複数の移転申請データの中に、同じ移転元のアカウントの複数の移転申請データが含まれていても、それらがグループ化されない場合とは、例えば、優良顧客ではない顧客（本実施形態では、優先度＝０）が移転元のアカウントになっている移転申請データと、その顧客が移転元のアカウントになっていて、かつ、緊急で移転する必要があり、申請受付手段２１による処理で高い優先度（本実施形態では、優先度＝１）が設定された移転申請データとがあり、それらの移転申請データに対して承認担当者が一括承認した場合である。この場合は、一括承認された複数の移転申請データの中に、同じ移転元のアカウントの複数の移転申請データが含まれているが、それらの移転申請データの優先度が同じではないため、グループ化されずに、別々の通常の承認済リクエストとして、そのアカウントに対応するキュー４２に格納される。

【0089】

＜金融機関サーバ２０／処理手段２０Ａ／移転申請データ取得手段２３の構成＞

【0090】

移転申請データ取得手段２３は、承認処理手段２２による処理（申請受付手段２１から承認処理手段２２までの処理）とは独立したタイミングで、キュー４２から１件分の承認済リクエストを取り出し、取り出した承認済リクエストに含まれる申請番号を用いて、承認された移転申請データを、移転申請データベース４１（図２参照）から取得する処理を実行するものである。

【0091】

また、移転申請データ取得手段２３は、キュー４２から１つのグループ承認済リクエストを取り出した場合（図１０参照）には、その１つのグループ承認済リクエストに含まれる複数の申請番号を用いて、一括承認された複数の移転申請データの中の同じ移転元のアカウントの複数の移転申請データを、移転申請データベース４１（図２参照）から取得する処理を実行する。そして、承認処理手段２２の説明で既に詳述したように、キュー４２から１つのグループ承認済リクエストを取り出す際には、グループ承認済リクエストを１つの要素として一度に取り出してもよく、グループ化された複数の要素として各要素を１つずつ連続して取り出してもよい。

【0092】

さらに、移転申請データ取得手段２３は、承認処理手段２２による処理とは独立したタイミングで、キュー４２から承認済リクエスト（通常の承認済リクエスト、またはグループ承認済リクエスト）を取り出すので、取り出すタイミングは、一例として、トランザクション管理システム１０の稼働開始時（但し、キュー４２に、承認済リクエストが格納されている状態になっているとき）と、確認手段２７から次の承認済リクエストの処理を開始させる指令（キュー４２毎の指令であり、キュー番号を含む。）を受け取ったときである。

【0093】

また、取り出すタイミングの別の例として、移転申請データ取得手段２３は、確認手段２７から受け取った指令（キュー別の指令）に基づき次の承認済リクエストの処理を開始する（キュー４２から次の承認済リクエストを取り出す）のではなく、キュー別案件処理状況記憶手段４７（図１１参照）に記憶されている各キュー４２の「キュー取出後の処理中の案件の申請番号」の状態を監視し、キュー４２から取り出されて処理中の案件の申請番号が記憶されている状態から、空欄の状態（確認手段２７が処理結果の通知を受け取って空欄に変える。）に変化したキュー４２があるときに、そのキュー４２から次の承認済リクエストを取り出すようにしてもよい。

【0094】

さらに、移転申請データ取得手段２３は、キュー４２から承認済リクエストを取り出した場合は、キュー別案件処理状況記憶手段４７（図１１参照）における承認済リクエストの取出しを行ったキュー４２に対応する「キュー取出後の処理中の案件の申請番号」に、取り出した承認済リクエストに含まれる申請番号を記憶させる。なお、キュー別案件処理状況記憶手段４７における処理中の状態（申請番号が記憶されている状態）は、キュー４２からの取出後における処理中という意味であるから、移転申請データベース４１（図２参照）のステータスの「処理中」とは、意味が異なっている。移転申請データベース４１のステータスは、承認が行われて承認済リクエストがキュー４２に格納された段階（従って、キュー４２から承認済リクエストが未だ取り出されていない段階）で「処理中」になるからであり、この移転申請データベース４１のステータスの「処理中」への変更処理は、承認処理手段２２により実行される。

【0095】

＜金融機関サーバ２０／処理手段２０Ａ／ナンス取得手段２４の構成＞

【0096】

ナンス取得手段２４は、移転申請データ取得手段２３により取得した移転申請データの移転元のアカウントについてのナンス取得要求信号（取得した移転申請データに含まれる当該移転元のアカウントのアカウント情報を含む。）を、通信回線１を介してブロックチェーンシステム９０を構成するノード５０に送信するとともに、ノード５０から通信回線１を介して送信されてくる当該移転元のアカウントについてのナンスの値を受信する処理を実行するものである。

【0097】

また、ナンス取得手段２４は、移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合（図１０参照）には、移転申請データベース４１（図２参照）から取得した複数の移転申請データに含まれている同じ移転元のアカウントのアカウント情報を用いて、この移転元のアカウントについてのナンスの値を、通信回線１を介してノード５０から取得する処理を実行する。この際、移転元のアカウントは同じであるから、当該アカウントについてのナンスの値の取得要求は１回であり、取得するナンスの値は１つである。

【0098】

＜金融機関サーバ２０／処理手段２０Ａ／トランザクション作成手段２５の構成＞

【0099】

トランザクション作成手段２５は、移転申請データ取得手段２３により取得した移転申請データ、およびナンス取得手段２４により取得したナンスの値を用いて、このナンスの値を付与したトランザクションデータ（図３参照）を作成し、その後、作成したトランザクションデータに対し、個人情報記憶手段４５（図７参照）から取得した移転元のアカウントの秘密鍵を用いて署名する処理を実行するものである。

【0100】

なお、トランザクションデータに付すナンスの値は、ノード５０から取得した値をそのまま使用すればよく、取得した値に１を加えて付す必要はない。従って、ノード５０から送信されてくるのは、最後に送信したトランザクションデータで使用されたナンスの値ではなく、次に送信するトランザクションデータに付すべきナンスの値である。すなわち、トランザクションデータが一度も送信されていないときに、ナンスの値を問い合わせると、０（ゼロ）が返ってくる。過去にトランザクションデータを１件送信していた場合は１が返ってきて、２件送信していた場合は２が返ってくる。ナンスの値は０（ゼロ）から始まるので、次のトランザクションデータを送信する際には、ノード５０から取得したナンスの値をそのまま使用すればよい。

【0101】

また、トランザクション作成手段２５は、移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合（図１０参照）には、移転申請データ取得手段２３により取得した複数の移転申請データ、およびナンス取得手段２４により取得したナンスの値（複数の移転申請データに含まれている同じ移転元のアカウントについてのナンスの値）を用いて、取得したナンスの値およびこの値に続くナンスの値をそれぞれ付与した複数のトランザクションデータを作成し、その後、作成した複数のトランザクションデータに対し、個人情報記憶手段４５（図７参照）から取得した移転元のアカウントの秘密鍵を用いて署名する処理を実行する。この際、ノード５０から取得しているナンスの値は、１つであるから、最初のトランザクションデータに対しては、取得したナンスの値そのものを付し、後続のトランザクションデータに対しては、ナンスの値を１ずつ増やしながら付していく。また、移転元のアカウントは同じであるから、秘密鍵は１つであり、複数のトランザクションデータの各々に対し、１つの秘密鍵で署名を行う。

【0102】

＜金融機関サーバ２０／処理手段２０Ａ／トランザクション送信手段２６の構成＞

【0103】

トランザクション送信手段２６は、トランザクション作成手段２５により作成し、署名したトランザクションデータを、通信回線１を介してノード５０に送信する処理を実行するものである。

【0104】

ここで、送信するトランザクションデータは、図３に示す分散型台帳に記帳されるトランザクションデータの一部であり、トークンＩＤと、移転先のアカウントのアカウント情報（アドレス）と、移転数量と、移転元のアカウントの署名（移転元のアカウントの秘密鍵を用いた署名）と、移転元のアカウントのナンスの値とを含んでいる。また、その他に、図示は省略されているが、Ｇａｓ（ガス：手数料）に関する値等も含んでいる。図３の例は、図２の申請番号＝T0001の移転申請データを用いて作成、署名、ノード５０への送信を行った後に、分散型台帳記憶手段６０に記憶されたブロック６１内のトランザクションデータである。

【0105】

図３に示す分散型台帳に記帳されるトランザクションデータのうち、トランザクションハッシュは、トランザクションデータ（図３に示したトランザクションデータにおけるトークンＩＤ以降の部分）を用いて計算されたハッシュ値であり、申請番号の対応情報（申請番号と１対１で紐づけられる情報）である。トランザクションハッシュと申請番号との対応関係は、トランザクションハッシュ・申請番号対応関係記憶手段（不図示）に記憶しておき、その後のノード５０への問合せや、ノード５０からの通知の案件特定で使用する。このトランザクションハッシュは、ノード５０においてトランザクション記録手段５２により算出される。従って、トランザクションハッシュは、計算により求めることができる値であるため、送信する必要はなく、金融機関サーバ２０からの送信時には、トランザクションデータの中に含まれていない。

【0106】

また、移転先のアカウントのアドレスは、アカウント情報（移転先のアカウントを特定するための情報）として、トランザクションデータの中に含めてノード５０に送信する必要があるが、移転元のアカウントのアドレスについては、ノード５０に送信しなくてもよい。ノード５０に送信するトランザクションデータについて、移転元のアカウントの署名（移転元のアカウントの秘密鍵を用いた署名）を行っていれば、その署名がアカウント情報（移転元のアカウントを特定するための情報）として機能するからである。すなわち、ブロックチェーンシステム９０では、数学的に署名から署名者（ここでは、移転元のアカウントの所有者）の公開鍵を求めることができる仕組みとなっていることから、署名者の公開鍵が分かればアドレス（ここでは、移転元のアカウントのアドレス）を求めることができるので、あえて移転元のアカウントのアドレスを送信する必要がないためである。従って、トランザクション記録手段５２（スマートコントラクトの機能）により署名から移転元のアカウントのアドレスを割り出したうえで、移転元および移転先の各アカウントのアドレスを含む移転のためのトランザクションデータがブロック６１に格納されて分散型台帳記憶手段６０に記憶される。

【0107】

なお、本実施形態では、秘密鍵が２５６ビットの乱数で生成され、秘密鍵から楕円曲線暗号（ECDSA）の仕組みを使って公開鍵が導出され（公開鍵から秘密鍵を逆に導出することは困難な仕組みとなっている。）、公開鍵からハッシュ関数（Keccak-256）の仕組みを使ってアドレスが導出される。従って、アドレスは、秘密鍵から一意に導出される。そして、アドレスに紐づく暗号資産であるセキュリティトークンを移転させたい場合は、その移転元のアカウントのアドレスの導出元となった秘密鍵を用いてトランザクションデータに署名を行う必要がある。よって、本願では、秘密鍵、秘密鍵から一意に導出されるアドレス、秘密鍵を用いた署名を、アカウントについて１対１で紐づけられる情報として、アカウント情報と呼んでいる。

【0108】

さらに、上記の説明では、ノード５０に送信するトランザクションデータについて、移転元のアカウントの署名（移転元のアカウントの秘密鍵を用いた署名）を行うので、移転元のアカウントのアドレスについては、ノード５０に送信しなくてもよかったが、移転元のアカウントの署名ではなく、予め移転の権限を委譲された第三者のアカウント（移転元および移転先の各アカウント以外のアカウント）の署名を行う場合（本発明では、この場合を排除していない。）には、ノード５０に送信するトランザクションデータの中に移転元のアカウントのアドレスを含めておく。この場合は、移転元のアカウントの署名ではなく、移転元のアカウントのアドレスが、移転元のアカウントを特定するためのアカウント情報として機能することになる。このように第三者のアカウントの秘密鍵を用いた署名を行う場合は、事前に、第三者（権限を委譲される者）のアカウントに移転の権限を委譲するためのトランザクションデータを作成し、それに権限を委譲する者（つまり、移転元）のアカウントの秘密鍵で署名し、ノード５０に送信しておく。例えば、アカウントＡからアカウントＢへの移転を、第三者のアカウントＣの署名で実行する場合には、先ず、アカウントＣに移転の権限を委譲するためのトランザクションデータを作成してアカウントＡの秘密鍵で署名・送信し、ブロックチェーンシステム９０に記録しておき、その後、移転元のアカウントＡのアドレス、移転先のアカウントＢのアドレス、移転数量を含むトランザクションデータについてアカウントＣの秘密鍵で署名・送信することで、スマートコントラクトにより権限が委譲されているかどうかを確認したうえで、アカウントＡからアカウントＢへの移転を分散型台帳記憶手段６０に記憶させる。

【0109】

また、トランザクション送信手段２６は、移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合（図１０参照）には、トランザクション作成手段２５によりそのグループ承認済リクエストに係る複数のトランザクションデータが作成されるので、トランザクション作成手段２５により作成した最も若いナンスの値（ノード５０から取得したナンスの値）を付与したトランザクションデータを、通信回線１を介してノード５０に送信した後に、ノード５０からの処理結果の通知を待つことなく（確認手段２７による処理を経ないで）、最も若いナンスの値に続くナンスの値（ノード５０から取得した最も若いナンスの値に対し、１ずつ増やしていったナンスの値）を付与した後続のトランザクションデータを、通信回線１を介してノード５０に送信する処理を実行する。

【0110】

この際、後続のトランザクションデータが複数ある場合には、後続のトランザクションデータ同士の間でも、ノード５０からの処理結果の通知を待つことなく（確認手段２７による処理を経ないで）、次のトランザクションデータを送信する。すなわち、最初のトランザクションデータを送信後に、そのトランザクションデータの処理結果の通知を待たずに、２番目のトランザクションデータを送信し、この２番目のトランザクションデータの処理結果の通知を待たずに、３番目のトランザクションデータを送信し、この３番目のトランザクションデータの処理結果の通知を待たずに、４番目のトランザクションデータを送信し、このような送信処理を、最後のトランザクションデータが送信されるまで続ける。

【0111】

＜金融機関サーバ２０／処理手段２０Ａ／確認手段２７の構成＞

【0112】

確認手段２７は、トランザクション送信手段２６により送信したトランザクションデータに対する処理結果の通知（トランザクションハッシュ（申請番号の対応情報）を含む。）を、通信回線１を介してノード５０から受信し、移転申請データ取得手段２３による次の承認済リクエストの処理への移行のための処理を実行するものである。

【0113】

ここで、移転申請データ取得手段２３による次の承認済リクエストの処理への移行のための処理とは、確認手段２７から移転申請データ取得手段２３に、次の承認済リクエストの処理を開始させる指令（キュー４２毎の指令であり、キュー番号を含む。）を送る処理でもよく、移転申請データ取得手段２３が監視している情報（キュー別案件処理状況記憶手段４７（図１１参照）に記憶されている各キュー４２の「キュー取出後の処理中の案件の申請番号」の状態）を、確認手段２７が変更する（処理結果の通知を受け取って空欄に変える。）ことにより、次の承認済リクエストの処理の開始タイミングを、確認手段２７から移転申請データ取得手段２３に伝達する処理でもよい。

【0114】

また、確認手段２７は、移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合（図１０参照）には、トランザクション送信手段２６によりそのグループ承認済リクエストに係る複数のトランザクションデータが送信されるので、トランザクション送信手段２６により送信した１つのグループ承認済リクエストに係る複数のトランザクションデータのうちの最後に送信したトランザクションデータに対する処理結果の通知を、通信回線１を介してノード５０から受信した場合に、移転申請データ取得手段２３による次の承認済リクエストの処理への移行のための処理を実行する。

【0115】

なお、移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合（図１０参照）には、トランザクション送信手段２６によりそのグループ承認済リクエストに係る複数のトランザクションデータが送信されるので、そのグループ承認済リクエストが取り出されたキュー４２についてキュー別案件処理状況記憶手段４７（図１１参照）に記憶されている「キュー取出後の処理中の案件の申請番号」の状態は、複数のトランザクションデータの全部を送信した直後には、送信された複数のトランザクションデータに係る各申請番号（各トランザクションハッシュの対応情報）が記憶されている状態となり、確認手段２７が処理結果の通知（トランザクションハッシュ（申請番号の対応情報）を含む。）を受け取る都度に、記憶されている申請番号の数が減っていき、最後の処理結果の通知を受け取ったときに、空欄の状態となり、これが移転申請データ取得手段２３による次の承認済リクエストの処理への移行のための処理となる。

【0116】

さらに、確認手段２７は、ノード５０からトランザクションデータの処理結果の通知（トランザクションハッシュ（申請番号の対応情報）を含む。）を受け取った場合に、移転申請データベース４１（図２参照）において、そのトランザクションデータに係る移転申請データ（受け取った処理結果の通知に含まれるトランザクションハッシュに対応する申請番号の移転申請データ）のレコードにおけるステータスを「処理中」から「移転成功」に変更する。なお、本発明では、少なくともナンスに起因するエラーは発生しないので、「移転成功」に変更されるが、他の原因で「移転失敗」に変更される可能性はあり、その解消は、本発明の目的とするところではない。

【0117】

＜金融機関サーバ２０／処理手段２０Ａ／格納実績集計手段２８の構成＞

【0118】

格納実績集計手段２８は、図５に示すように、移転申請データベース４１（図２参照）に記憶された移転申請データの移転元のアカウントのアカウント情報および処理状況を示すステータス（ここでは、承認待ちの状態か、承認済の状態かがわかればよい。）を用いて、各アカウントが移転元になっている移転申請データに係る承認済リクエストが、集計期間中にキュー４２に実際に格納されたアカウント別実績件数を集計して求めるとともに、求めたアカウント別実績件数をキュー４２毎に合計してキュー別合計件数（実績値）を算出し、求めたアカウント別実績件数、および算出したキュー別合計件数（実績値）を、格納実績記憶手段４４に記憶させる処理を実行するものである。

【0119】

図５の例では、アカウントＡ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈについて求めたアカウント別実績件数は、それぞれ１０，２０，５０，０，１０，２０，１００，１０件となっている。また、第１、第２、第３のキュー４２Ａ，４２Ｂ，４２Ｃについて算出したキュー別合計件数（実績値）は、それぞれ８０，３０，１１０件となっている。

【0120】

この際、ステータスが「承認待ち」になっている移転申請データは、未だキュー４２に格納されていないので、集計の対象外であるから、ステータスが「処理中」以降の状態になっている移転申請データを集計対象とする。また、集計期間は、例えば、１日、１週間、１か月、半年、１年など、任意であり、集計期間中であるか否かは、承認日時のうちの日付を用いて判断される。さらに、集計は、定期的に繰り返し行ってもよく、不定期に行ってもよく、後者の不定期の場合は、金融機関のシステム担当者が決めた任意のタイミングで行ってもよい。従って、毎回の集計の期間長は、一定長でもよく、毎回違っていてもよい。

【0121】

また、格納実績集計手段２８は、移転申請データベース４１（図２参照）に記憶された移転申請データの承認日時のうちの時刻を用いて、午前および午後、またはその他の複数の時間帯に分けて、承認済リクエストが集計期間中にキュー４２に実際に格納されたアカウント別実績件数を集計して求め、求めた時間帯毎のアカウント別実績件数を用いて、承認が行われた時刻について時間帯に偏りのあるアカウントを決定し、さらに、求めた時間帯毎のアカウント別実績件数をキュー４２毎に合計して時間帯毎のキュー別合計件数（実績値）を算出し、求めた時間帯毎のアカウント別実績件数、決定した時間帯に偏りのあるアカウント（各アカウントについての時間帯の偏りの有無）、および算出した時間帯毎のキュー別合計件数（実績値）も、格納実績記憶手段４４に記憶させる処理を実行する。

【0122】

ここで、本実施形態では、午前および午後の２つの時間帯Ｔ１，Ｔ２に分けて集計を行っているが、時間帯の数は２つではなく、３以上の時間帯Ｔ１，Ｔ２，Ｔ３，…としてもよく、例えば、１日の営業時間帯を１時間、あるいは２時間で仕切って分けてもよく、分けた各時間帯の時間長は、必ずしも同じである必要はなく、異なっていてもよい。

【0123】

また、承認が行われた時刻について時間帯に偏りのあるアカウントを決定する際には、全体（時間帯を考慮しない全体）のアカウント別実績件数が予め定めた閾値以上または閾値を超えるアカウントについて、全体のアカウント別実績件数に対する時間帯毎のアカウント別実績件数の割合が、予め定めた閾値以上または閾値を超えている否かを判断し、閾値以上または閾値を超えている場合に、そのアカウントを、時間帯に偏りのあるアカウントであると判断する。

【0124】

例えば、図５の例で、全体のアカウント別実績件数についての閾値を１０件以上と定めておき、上記の割合についての閾値を、９０％以上と定めておいたとすると、アカウントＢにつては、集計期間中の全体のアカウント別実績件数＝２０件であり、集計期間中の時間帯Ｔ１（午前）のアカウント別実績件数＝１９件、集計期間中の時間帯Ｔ２（午後）のアカウント別実績件数＝１件であるから、時間帯Ｔ１（午前）の割合が、１９／２０＝９５％であり、閾値の９０％以上となるので、アカウントＢを、時間帯Ｔ１（午前）への集中があるアカウントであると判断する。また、アカウントＣにつては、集計期間中の全体のアカウント別実績件数＝５０件であり、集計期間中の時間帯Ｔ１（午前）のアカウント別実績件数＝４７件、集計期間中の時間帯Ｔ２（午後）のアカウント別実績件数＝３件であるから、時間帯Ｔ１（午前）の割合が、４７／５０＝９４％であり、閾値の９０％以上となるので、アカウントＣも、時間帯Ｔ１（午前）への集中があるアカウントであると判断する。

【0125】

＜金融機関サーバ２０／処理手段２０Ａ／アカウント・キュー対応関係変更手段２９の構成＞

【0126】

アカウント・キュー対応関係変更手段２９は、格納実績記憶手段４４（図５参照）に記憶された各アカウントのアカウント別実績件数を用いて、複数のキュー４２（本実施形態では、一例として３つのキュー４２Ａ，４２Ｂ，４２Ｃ）の各々でアカウント別実績件数を合計した集計期間中のキュー別合計件数が均一または略均一になるように、各アカウントのアカウント別実績件数を複数のキューのいずれかに割り当てることにより、アカウント・キュー対応関係を示す情報を変更し、変更後のアカウント・キュー対応関係を示す情報を、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶させる処理を実行するものである。

【0127】

また、アカウント・キュー対応関係変更手段２９は、格納実績集計手段２８により決定された時間帯（承認が行われた時刻の帰属時間帯）に偏りのあるアカウントのアカウント別実績件数を、複数のキュー４２に分散させて割り当てた後に、複数のキュー４２の各々でアカウント別実績件数を合計した集計期間中のキュー別合計件数が均一または略均一になるように、残っている各アカウント（時間帯に偏りのあるアカウント以外のアカウント）のアカウント別実績件数を複数のキューのいずれかに割り当てることにより、アカウント・キュー対応関係を示す情報を変更し、変更後のアカウント・キュー対応関係を示す情報を、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶させる処理を実行する。

【0128】

さらに、アカウント・キュー対応関係変更手段２９は、複数の優良顧客のアカウント（顧客情報記憶手段４５（図７参照）の「顧客の優先度」カラムが１になっているアカウント）のアカウント別実績件数を、複数のキュー４２に分散させて割り当てた後に、複数のキュー４２の各々でアカウント別実績件数を合計した集計期間中のキュー別合計件数が均一または略均一になるように、残っている各アカウント（優良顧客のアカウント以外のアカウント）のアカウント別実績件数を複数のキュー４２のいずれかに割り当てることにより、アカウント・キュー対応関係を示す情報を変更し、変更後のアカウント・キュー対応関係を示す情報を、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶させる処理を実行する。

【0129】

ここで、複数のキュー４２の各々でアカウント別実績件数を合計した集計期間中のキュー別合計件数が均一または略均一になるように、各アカウントのアカウント別実績件数を複数のキュー４２のいずれかに割り当てる方法は、１通りではないが、次の方法を採用することにより、キュー別合計件数を容易に均一または略均一にすることができるとともに、時間帯に偏りのあるアカウントについての複数のキュー４２への分散割当や、優良顧客のアカウントについての複数のキュー４２への分散割当と容易に組み合わせることができる。

【0130】

すなわち、アカウント・キュー対応関係変更手段２９は、割当処理途中の各時点で各アカウントのアカウント別実績件数を合計した時点合計のキュー別合計件数が最も小さいキュー４２を求め、求めたキュー４２に対し、残っているアカウントのうち割当処理途中の各時点でアカウント別実績件数が最も大きいアカウントのアカウント別実績件数を割り当てる処理を繰り返す基本アルゴリズムを採用することができる。そして、時間帯に偏りのあるアカウントについての複数のキュー４２への分散割当や、優良顧客のアカウントについての複数のキュー４２への分散割当と組み合わせる場合には、これらの分散割当を行った後に、上記の基本アルゴリズムによる処理を行って、集計期間中のキュー別合計件数が均一または略均一になるようにすることができる。なお、時間帯に偏りのあるアカウントについての複数のキュー４２への分散割当と、優良顧客のアカウントについての複数のキュー４２への分散割当との双方を行う場合には、いずれの分散割当を先に行ってもよい。

【0131】

また、時間帯に偏りのあるアカウントについての複数のキュー４２への分散割当や、優良顧客のアカウントについての複数のキュー４２への分散割当の方法としては、例えば、アカウント別実績件数が多い順に各キュー４２に各アカウント（のアカウント別実績件数）を割り当てていき、全てのキュー４２への割り当てを終えた後に、割り当てるアカウントが未だ残っている場合には、割り当てていく方向を反転させる折り返し割当方法を採用することができる。すなわち、第１、第２、第３のキュー４２があるとすると、これらの３つのキュー４２について、アカウント別実績件数が多いアカウントの順に、各アカウント（のアカウント別実績件数）を、第１、第２、第３のキュー４２にこの順番で割り当てていき、その後、折り返して、第３、第２、第１のキュー４２にこの順番で割り当てていき、さらに、折り返して、第１、第２、第３のキュー４２にこの順番で割り当てていくといった処理を繰り返すのが、折り返し割当方法である。キュー４２の数が２つ、あるいは４つ以上の場合も、同様な折り返し割当方法を採用することができる。

【0132】

なお、このような折り返し割当方法は、時間帯に偏りのあるアカウントの分配割当、優良顧客のアカウントの分配割当のいずれにも採用することができるが、双方の分配割当を行う場合には、時間帯に偏りのあるアカウントと、優良顧客のアカウントとを混在させた状態で、上記の折り返し割当方法を適用するのではなく、別々に適用する。すなわち、先ず、時間帯に偏りのあるアカウントを、第１、第２、第３、第３、第２、第１、第１、第２、第３、…のように割り当て、次に、優良顧客のアカウントを、第１、第２、第３、第３、第２、第１、第１、第２、第３、…のように割り当てるか、または、この逆順として、先に優良顧客のアカウントに折り返し割当方法を適用し、次に、時間帯に偏りのあるアカウントに折り返し割当方法を適用する。また、優良顧客のアカウントと、時間帯に偏りのあるアカウントとに重複がある場合（ある１つのアカウントが、双方のアカウントに該当する場合）には、いずれかのアカウントに帰属させて折り返し割当方法を適用する。

【0133】

具体的には、例えば、図６に示すようにして新たなアカウント・キュー対応関係を決定し、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されたアカウント・キュー対応関係を示す情報を変更することができる。図６の例では、アカウント・キュー対応関係の変更前における各キュー４２へのアカウントの割当状態が、図５の上部に示す状態であり、変更後における各キュー４２へのアカウントの割当状態が、図５の下部に示す状態である。従って、図５の下部において、アカウント別実績件数は、実績値であるが、キュー別合計件数については、実績値ではなく、アカウント別実績件数（実績値）の割当状態を変更して合計した仮定値であり、アカウント・キュー対応関係を変更すれば、そのようになっていたという仮定値である。従って、そのようにアカウント・キュー対応関係を変更すれば、今後は、各キュー４２のキュー別合計件数が均一または略均一になるだろうという意味の計算値である。このため、図５の上部は、格納実績集計手段２８による集計結果を格納実績記憶手段４４に記憶させた状態を示しているが、図５の下部は、アカウント・キュー対応関係変更手段２９により求めた仮定の状態であり、説明の便宜上、図５の上部の格納実績記憶手段４４に合わせて記載したものである。

【0134】

図６の例では、優良顧客のアカウントについての複数のキュー４２への分散割当は行わないものとし、先ず、承認が行われた時刻について時間帯に偏りのあるアカウントについての複数のキュー４２への分散割当から始めるものとする。図５の上部に示すように、時間帯に偏りのあるアカウントは、アカウントＢ，Ｃであるから、これらをアカウント別実績件数の多い順に並べると、図６の上部に示すように、アカウントＣ＝５０件、アカウントＢ＝２０件となる。また、その他のアカウント（時間帯に偏りのあるアカウント以外のアカウント）をアカウント別実績件数の多い順に並べると、図６の上部に示すように、アカウントＧ＝１００件、アカウントＦ＝２０件、アカウントＡ，Ｅ，Ｈ＝各１０件、アカウントＤ＝０件となる。

【0135】

従って、最初に、アカウントＣ＝５０件を第１のキュー４２Ａに割り当て、次に、アカウントＢ＝２０件を第２のキュー４２Ｂに割り当てる。折り返し割当方法を適用しているが、折り返す前に、割り当てるアカウントが無くなったので、折り返していない。この時点で、第１のキュー４２Ａの時点合計＝５０件、第２のキュー４２Ｂの時点合計＝２０件、第３のキュー４２Ｃの時点合計＝０件である。

【0136】

その後、残りのアカウントについて、基本アルゴリズムを適用し、複数のキュー４２への割当を行う。時点合計が一番少ないのは、第３のキュー４２Ｃであるから、第３のキュー４２Ｃに対し、この時点でアカウント別実績件数が一番多いアカウントＧ＝１００件を割り当てる。すると、第１のキュー４２Ａの時点合計＝５０件、第２のキュー４２Ｂの時点合計＝２０件、第３のキュー４２Ｃの時点合計＝１００件となる。

【0137】

続いて、時点合計が一番少ないのは、第２のキュー４２Ｂになったので、第２のキュー４２Ｂに対し、この時点でアカウント別実績件数が一番多いアカウントＦ＝２０件を割り当てる。すると、第１のキュー４２Ａの時点合計＝５０件、第２のキュー４２Ｂの時点合計＝４０件、第３のキュー４２Ｃの時点合計＝１００件となる。

【0138】

それから、時点合計が一番少ないのは、第２のキュー４２Ｂのままなので、第２のキュー４２Ｂに対し、この時点でアカウント別実績件数が一番多いアカウントＡ，Ｅ，Ｈ＝各１０件のうちのいずれかを割り当てる。いずれを割り当ててもよいが、ここでは、元々、第２のキュー４２Ｂに割り当てられていたアカウントＥ＝１０件を選択し、割り当てるものとする。すると、第１のキュー４２Ａの時点合計＝５０件、第２のキュー４２Ｂの時点合計＝５０件、第３のキュー４２Ｃの時点合計＝１００件となる。

【0139】

続いて、時点合計が一番少ないのは、第１のキュー４２Ａ、第２のキュー４２Ｂになったので、これらのいずれかのキュー４２に対し、この時点でアカウント別実績件数が一番多いアカウントＡ，Ｈ＝各１０件のうちのいずれかを割り当てる。いずれのキュー４２に、いずれのアカウント（のアカウント別実績件数）を割り当ててもよいが、ここでは、キュー番号の若い第１のキュー４２Ａに対し、元々、第１のキュー４２Ａに割り当てられていたアカウントＡ＝１０件を選択し、割り当てるものとする。すると、第１のキュー４２Ａの時点合計＝６０件、第２のキュー４２Ｂの時点合計＝５０件、第３のキュー４２Ｃの時点合計＝１００件となる。

【0140】

さらに、時点合計が一番少ないのは、第２のキュー４２Ｂになったので、第２のキュー４２Ｂに対し、この時点でアカウント別実績件数が一番多いアカウントＨ＝１０件を割り当てる。すると、第１のキュー４２Ａの時点合計＝６０件、第２のキュー４２Ｂの時点合計＝６０件、第３のキュー４２Ｃの時点合計＝１００件となる。

【0141】

続いて、時点合計が一番少ないのは、第１のキュー４２Ａ、第２のキュー４２Ｂになったので、これらのいずれかのキュー４２に対し、この時点でアカウント別実績件数が一番多いアカウントＤ＝０件（０件であるが、アカウントＤしか残っていないので、アカウントＤが選択される。）を割り当てる。いずれのキュー４２に割り当ててもよいが、ここでは、元々、アカウントＤが第２のキュー４２Ｂに割り当てられていたので、第２のキュー４２Ｂに対し、アカウントＤ＝０件を割り当てる。すると、第１のキュー４２Ａの最終合計＝６０件、第２のキュー４２Ｂの最終合計＝６０件、第３のキュー４２Ｃの最終合計＝１００件となる。

【0142】

以上のアカウント・キュー対応関係変更手段２９による割当処理により、アカウント・キュー対応関係は、図５の上部に示した状態から、図５の下部に示した状態に変更され、結果的に、アカウントＢの割当が、第１のキュー４２Ａから第２のキュー４２Ｂに変更されるとともに、アカウントＨの割当が、第３のキュー４２Ｃから第２のキュー４２Ｂに変更され、その他のアカウントの割当は変更されていない。割当が変更されたアカウントＢ，Ｈおよびそのアカウント別実績件数は、図５の下部において太線で囲まれている。

【0143】

＜金融機関サーバ２０／処理手段２０Ａ／設定手段３０の構成＞

【0144】

設定手段３０は、金融機関のシステム担当者（但し、申請担当者や承認担当者が兼任してもよい。）により入力されて担当者端末７０からネットワーク２を介して送信されてくる設定情報を受信し、各記憶手段４３，４５，４６に記憶させる処理を実行するものである。

【0145】

具体的には、設定手段３０は、例えば、新規顧客のアカウントが増えた場合や、既存の顧客のアカウントが減った場合等に、設定情報として、システム担当者によるアカウント・キュー対応関係の手動変更を受け付け、アカウント・キュー対応関係記憶手段４３（図４参照）に反映させる。

【0146】

また、設定手段３０は、自社の顧客が増減した場合や、自社の顧客についての優先度（優良顧客か否かの状態）、電話番号、住所等が変化した場合には、それらを設定情報として、顧客情報記憶手段４５（図７参照）に反映させる。

【0147】

さらに、設定手段３０は、承認担当者の優先度（特別な権限を有するか否かの状態）等が変化した場合には、それらを設定情報として、担当者情報記憶手段４６に反映させる。

【0148】

＜金融機関サーバ２０／移転申請データベース４１の構成＞

【0149】

移転申請データベース４１は、図２に示すように、申請番号と関連付けて、移転申請データ（トークンＩＤ、移転元および移転先の各アカウントのアカウント情報（アドレス）、移転数量を含む。）、移転申請の処理状況を示すステータス（「承認待ち」、「処理中」、「移転成功」、「移転失敗」等）、緊急または優良顧客に基づく優先度（本実施形態では、１か０）、承認担当者の特別権限に基づく優先度（本実施形態では、１か０）、申請日時、承認日時、申請担当者の識別情報（社員コードや名前等）、承認担当者の識別情報（社員コードや名前等）等を記憶するものである。

【0150】

＜金融機関サーバ２０／キュー４２の構成＞

【0151】

キュー４２は、図３、図１０に示すように、先に入れた要素（ここでは、承認済リクエスト）を先に出すという先入先出のキューであり、本実施形態では、先入先出の原則に対し、高い優先度が付された要素を、他の要素（優先度の低い要素）よりも先に出すという例外的な処理を行う優先度付きキューである。キュー４２には、既存のキューを採用することができるが、新たに構築してもよい。本実施形態では、一例として、第１のキュー４２Ａ、第２のキュー４２Ｂ、第３のキュー４２Ｃの合計３つのキュー４２が設けられている。但し、キュー４２の個数は、３つに限らず、任意であり、また、複数ではなく、１つのキュー４２としてもよい。

【0152】

＜金融機関サーバ２０／アカウント・キュー対応関係記憶手段４３の構成＞

【0153】

アカウント・キュー対応関係記憶手段４３は、図４に示すように、各アカウントが移転元になっている移転申請データに係る承認済リクエストを複数（本実施形態では、一例として３つ）のキュー４２Ａ，４２Ｂ，４２Ｃのうちのいずれに格納するのかを定めるアカウント・キュー対応関係を示す情報として、各アカウントのアカウント情報（アドレス）と各キューのキュー識別情報（キュー番号）とを対応付けて記憶するものである。図４の例では、アカウントＡ，Ｂ，Ｃが、第１のキュー４２Ａに割り当てられ、アカウントＤ，Ｅ，Ｆが、第２のキュー４２Ｂに割り当てられ、アカウントＧ，Ｈが、第３のキュー４２Ｃに割り当てられている。このアカウント・キュー対応関係は、アカウント・キュー対応関係変更手段２９により変更される。

【0154】

＜金融機関サーバ２０／格納実績記憶手段４４の構成＞

【0155】

格納実績記憶手段４４は、図５の上部に示すように、各キュー４２（キュー４２Ａ，４２Ｂ，４２Ｃ）のキュー識別情報（キュー番号）および各アカウント（アカウントＡ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈ）のアカウント情報（アドレス）と関連付けて、集計期間中の時間帯Ｔ１（午前）のアカウント別実績件数と、集計期間中の時間帯Ｔ１（午前）のキュー別合計件数（実績値）と、集計期間中の時間帯Ｔ２（午後）のアカウント別実績件数と、集計期間中の時間帯Ｔ２（午後）のキュー別合計件数（実績値）と、アカウント別の時間帯の偏り（集中）の有無（０（無）、１（有）の情報に加え、Ｔ１，Ｔ２のどの時間帯に集中しているかという情報を含む。）と、集計期間中のアカウント別実績件数と、集計期間中のキュー別合計件数（実績値）とを記憶するものである。

【0156】

＜金融機関サーバ２０／顧客情報記憶手段４５の構成＞

【0157】

顧客情報記憶手段４５は、図７に示すように、アカウント情報（アドレス）、アカウントの所有者の氏名、優良顧客であるか否かを示す顧客の優先度（本実施形態では、１か０）、電話番号、住所、秘密鍵等を対応付けて記憶するものである。なお、既に詳述したように、アドレスは、秘密鍵から一意に導出されるので、秘密鍵も、アカウント情報（アカウントを特定するための情報）である。

【0158】

＜金融機関サーバ２０／担当者情報記憶手段４６の構成＞

【0159】

担当者情報記憶手段４６は、担当者（申請担当者、承認担当者、システム担当者を含む。）の識別情報（社員コード、役員コード等）、氏名、特別な権限を有する承認担当者であるか否かを示す承認担当者の優先度（本実施形態では、１か０）等を対応付けて記憶するものである。

【0160】

＜金融機関サーバ２０／キュー別案件処理状況記憶手段４７の構成＞

【0161】

キュー別案件処理状況記憶手段４７は、図１１に示すように、キュー識別情報（キュー番号）と、キュー４２から取り出されて処理中の案件の申請番号とを対応させて記憶するものである。ここに記憶される申請番号は、移転申請データ取得手段２３により格納され、確認手段２７により消去されることにより更新される。また、移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合には、１つのキュー４２（キュー識別情報)に対し、複数の案件の申請番号が記憶されている状態となる。

【0162】

＜ノード５０／処理手段５０Ａ／ナンス取得要求応答手段５１の構成＞

【0163】

ナンス取得要求応答手段５１は、金融機関サーバ２０のナンス取得手段２４により通信回線１を介して送信されてくるナンス取得要求信号（移転申請データ取得手段２３により取得した移転申請データに含まれる移転元のアカウントのアカウント情報を含む。）を受信し、分散型台帳記憶手段６０内のステートルート算出用データ保存領域６２（図９参照）の当該移転元のアカウントについてのアカウントステート（Account State）に記憶されているナンス（nonce）の値を参照し、次に送信するトランザクションデータに付すべきナンスの値を、通信回線１を介して金融機関サーバ２０のナンス取得手段２４に送信する処理を実行するものである。この機能は、ブロックチェーンの基本的な機能である。

【0164】

＜ノード５０／処理手段５０Ａ／トランザクション記録手段５２の構成＞

【0165】

トランザクション記録手段５２は、金融機関サーバ２０のトランザクション送信手段２６により通信回線１を介して送信されてくるトランザクションデータ（ここでは、移転データ）を受信し、受信したトランザクションデータを含むブロック６１（図８参照）を生成し、生成したブロック６１をＰ２Ｐネットワーク３内で承認して分散型台帳記憶手段６０に追加するとともに、このトランザクションデータの処理結果の通知を、通信回線１を介して金融機関サーバ２０の確認手段２７に送信する処理を実行するものである。この機能は、ブロックチェーンの基本的な機能である。但し、移転元のアカウントの署名から移転元のアカウントのアドレスを求める処理は、スマートコントラクトにより実現される機能である。

【0166】

また、トランザクション記録手段５２は、受信したトランザクションデータ（移転データ）に含まれるトークンＩＤ、移転元および移転先のアカウントのアカウント情報、並びに移転数量を用いて、分散型台帳記憶手段６０内のステートルート算出用データ保存領域６２（図９参照）に記憶されている移転元および移転先の各アカウントについてのセキュリティトークンの残高データを更新する。この機能は、スマートコントラクトにより実現される機能である。

【0167】

＜ノード５０／分散型台帳記憶手段６０の構成：図８、図９＞

【0168】

分散型台帳記憶手段６０は、図８に示すように、Ｐ２Ｐネットワーク３内の各ノード５０，８０で共有する複数のブロック６１を記憶するとともに、ステートルート算出用データ保存領域６２を備えている。このステートルート算出用データ保存領域６２は、ブロック外の保存領域であり、Ｐ２Ｐネットワーク３内の各ノード５０，８０は同じスマートコントラクトを使用し、同じ機能を有するので、いずれのノード５０，８０も、同じステートルート算出用データ保存領域６２を備えている。

【0169】

ブロック６１内には、ブロックヘッダ（Block Header）と、ブロックボディ（Block Body）とが設けられている。ブロックヘッダには、チェーン形成用情報（本実施形態では、前のブロックのハッシュ値）、ステートルート（stateRoot）、ブロック番号、タイムスタンプ等が含まれる。また、ブロックボディには、トランザクションリスト（transaction list）が含まれ、トランザクションリストには、少なくとも１つのトランザクションデータが含まれている。

【0170】

また、ブロック外の保存領域には、ステートルート算出用データ保存領域６２の他に、ブロック６１内のブロックヘッダに含まれるトランザクションルート（transactionsRoot：不図示）の算出用データの保存領域として、トランザクションツリー（Transactions Trie）があり、また、ブロック６１内のブロックヘッダに含まれるレシートルート（receiptsRoot：不図示）の算出用データの保存領域として、レシートツリー（Receipts Trie）があるが、これらの木構造の保存領域は、本発明の機能説明に必要ないため、図９での図示は省略されている。

【0171】

図９において、ステートルート算出用データ保存領域６２は、ブロック６１内のステートルート（stateRoot）を算出するためのワールドステートツリー（World State Trie）により構成され、この木構造のワールドステートツリーの頂上部分のルートハッシュ値（root hash）が、ステートルート（stateRoot）に格納されるようになっている。

【0172】

ワールドステートツリーの最下層のデータは、アカウントステート（Account State）であり、最下層のアカウントステートから始めて、２つのデータのハッシュ値（hash）を積み上げていくことにより、木構造の頂上部分のルートハッシュ値（root hash）が算出されるようになっている。

【0173】

そして、ワールドステートツリーの最下層のアカウントステート（Account State）の１つ１つも、複数のデータの保存領域であり、最下層には、通常のアカウント（投資家のアカウントＡ，Ｂ，Ｃ，…）のアカウントステートと、セキュリティトークン（トークンＸ，Ｙ，Ｚ，…）用のスマートコントラクトのアカウントステートとが混在している。従って、通常のアカウントＡ，Ｂ，Ｃ，…も、トークンＸ，Ｙ，Ｚ，…用のスマートコントラクトも、独自のデータ保存領域を持ち、両方とも同じ木構造の中で「アカウント」として管理されている。後者のアカウントのことを「コントラクトアカウント」と呼んで区別することもある。

【0174】

セキュリティトークン用のスマートコントラクト（図９の拡大例では、トークンＹ用のスマートコントラクト）のアカウントステート（Account State）は、ナンス（nonce）と、バランス（balance）と、ストーレッジルート（storageRoot）と、コードハッシュ（codeHash）とにより構成される。これらのうちのストーレッジルートには、アカウントストーレッジツリー（Account Storage Trie）のルートハッシュ値（root hash）が格納されるようになっている。また、コードハッシュ（codeHash）には、トークンＹ用のスマートコントラクトのプログラムのハッシュ値が格納されるようになっている。なお、スマートコントラクトのアカウントステート（Account State）のナンス（nonce）は、通常のアカウント（投資家のアカウントＡ，Ｂ，Ｃ，…）についてのナンス（nonce）ではないので、本発明で扱うナンスではない。

【0175】

アカウントストーレッジツリーの最下層のデータは、セキュリティトークン（図９の拡大例では、トークンＹ）の各アカウントＡ，Ｂ，Ｃ，Ｄ，…の残高データであり、最下層の各アカウントＡ，Ｂ，Ｃ，Ｄ，…の残高データから始めて、２つのデータのハッシュ値（hash）を積み上げていくことにより、木構造の頂上部分のルートハッシュ値（root hash）が算出されるようになっている。

【0176】

一方、通常のアカウント（図９の拡大例では、アカウントＣ）のアカウントステート（Account State）も、ナンス（nonce）と、バランス（balance）と、ストーレッジルート（storageRoot）と、コードハッシュ（codeHash）とにより構成される。しかし、コントラクトアカウントではない通常のアカウントは、スマートコントラクトやそれに紐づくデータを持たないので、ストーレッジルート（storageRoot）、コードハッシュ（codeHash）の２つの項目のデータは空の状態となっている。この通常のアカウントについてのナンス（nonce）が、本発明で扱うナンスである。

【0177】

＜移転申請の受付および承認、並びにトランザクション送信の流れ：図１１＞

【0178】

このような本実施形態においては、以下のようにしてトランザクション管理システム１０により、移転申請の受付および承認、並びにトランザクション送信の処理が行われる。

【0179】

図１１において、申請受付手段２１により、担当者端末７０からの金融機関の申請担当者による移転申請、または顧客端末（不図示）からの顧客による移転申請を受け付け、受け付けた移転申請データを、移転申請データベース４１（図２参照）に記憶させる（ステップＳ１）。なお、申請受付手段２１により、売買システムである私設取引システム（ＰＴＳ）から、成立した取引データを取得し、移転申請データとして移転申請データベース４１に記憶させてもよい。

【0180】

続いて、承認処理手段２２により、担当者端末７０からの金融機関の承認担当者による承認（移転申請データベース４１（図２参照）に記憶された移転申請データに対する承認）を受け付け、承認済リクエストをキュー４２に格納する（ステップＳ２）。そして、承認処理手段２２により、移転申請データベース４１（図２参照）における承認された移転申請データのレコードのステータスを「承認待ち」から「処理中」に更新する。

【0181】

この際、本実施形態では、複数のキュー４２が設けられているので、承認処理手段２２により、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されたアカウント・キュー対応関係に従って、格納するキュー４２を決定する。

【0182】

また、承認処理手段２２が、金融機関の承認担当者による複数の移転申請データに対する一括承認を受け付けた場合（図１０参照）には、その中に、同じ移転元のアカウントの複数の移転申請データが含まれていれば、グループ承認済リクエストをキュー４２に格納する。

【0183】

さらに、承認処理手段２２は、特別な権限を有する承認担当者（担当者情報記憶手段４６で定められている。）による承認を受け付けた場合、優良顧客（顧客情報記憶情報４５（図７参照）で定められている。）の移転申請に対する承認を受け付けた場合、緊急で移転する必要のある移転申請に対する承認を受け付けた場合には、高い優先度付きの承認済リクエストをキュー４２に格納する。

【0184】

そして、トランザクション管理システム１０は、以上のステップＳ１，Ｓ２の処理とは独立して、以下の処理を実行する。なお、以下の処理は、キュー４２毎に別々に実行され、キュー別の独立したループ処理となる。

【0185】

先ず、移転申請データ取得手段２３により、キュー４２から１件分の承認済リクエストを取り出し、取り出した承認済リクエストに含まれる申請番号を用いて、承認された移転申請データを、移転申請データベース４１（図２参照）から取得する（ステップＳ３）。グループ承認済リクエストを取り出した場合（図１０参照）には、一括承認された複数の移転申請データを、移転申請データベース４１から取得する。そして、移転申請データ取得手段２３により、キュー別案件処理状況記憶手段４７（図１１参照）における承認済リクエストの取出しを行ったキュー４２に対応する「キュー取出後の処理中の案件の申請番号」に、取り出した承認済リクエストに含まれる申請番号を記憶させる。

【0186】

次に、ナンス取得手段２４により、移転申請データ取得手段２３により取得した移転申請データの移転元のアカウントについてのナンス取得要求信号を、通信回線１を介してノード５０に送信するとともに、ノード５０から通信回線１を介して送信されてくる当該移転元のアカウントについてのナンスの値を受信する（ステップＳ４）。

【0187】

続いて、トランザクション作成手段２５により、移転申請データ取得手段２３により取得した移転申請データ、およびナンス取得手段２４により取得したナンスの値を用いて、このナンスの値を付与したトランザクションデータ（図３参照）を作成し、その後、作成したトランザクションデータに対し、個人情報記憶手段４５（図７参照）から取得した移転元のアカウントの秘密鍵を用いて署名する（ステップＳ５）。前述したステップＳ３で移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合（図１０参照）には、複数のトランザクションデータを作成し、署名する。

【0188】

それから、トランザクション送信手段２６により、トランザクション作成手段２５により作成し、署名したトランザクションデータを、通信回線１を介してノード５０に送信する（ステップＳ６）。前述したステップＳ３で移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合（図１０参照）には、複数のトランザクションデータを送信する。

【0189】

その後、確認手段２７により、トランザクション送信手段２６により送信したトランザクションデータに対する処理結果の通知（トランザクションハッシュ（申請番号の対応情報）を含む。）を、通信回線１を介してノード５０から受信する（ステップＳ７）。そして、確認手段２７により、移転申請データベース４１（図２参照）における処理結果の通知に係る案件（申請番号で特定される。）のレコードのステータスを「処理中」から「移転成功」に更新する。また、確認手段２７により、キュー別案件処理状況記憶手段４７（図１１参照）に記憶された処理結果の通知に係る案件の申請番号を消去して、当該案件の承認済リクエストを取り出したキュー４２に対応する「キュー取出後の処理中の案件の申請番号」を空欄の状態にする。なお、前述したステップＳ３で移転申請データ取得手段２３によりグループ承認済リクエストが取り出された場合（図１０参照）には、そのグループ承認済リクエストに係る全ての案件についてノード５０から処理結果の通知を受け取り、全ての案件の申請番号を消去すると、そのグループ承認済リクエストを取り出したキュー４２に対応する「キュー取出後の処理中の案件の申請番号」が空欄の状態になる。

【0190】

それから、その日の営業がまだ続く場合（ステップＳ８）には、前述したステップＳ３の移転申請データ取得手段２３による処理に戻り、以降、営業終了までステップＳ３～Ｓ８のループ処理を繰り返す。なお、このループ処理は、キュー４２毎に実行されるので、例えば、あるキュー４２についてステップＳ４の処理を実行しているタイミングで、別のキュー４２についてステップＳ６の処理を実行している等のように、キュー４２毎にループ処理の進行状況は異なり、各キュー４２のループ処理は独立して進行する。これにより、キュー４２毎にトランザクションの送信管理を行ってナンスに起因するエラーの発生を回避しつつ、全体としてトランザクションの処理を迅速化することができる。

【0191】

一方、営業終了の場合（ステップＳ８）には、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されているアカウント・キュー対応関係の変更を行う（ステップＳ９）。

【0192】

＜各キュー４２へのアカウントの割当処理の流れ：図１２＞

【0193】

アカウント・キュー対応関係の変更のための各キュー４２へのアカウントの割当処理は、以下のようにして格納実績集計手段２８およびアカウント・キュー対応関係変更手段２９により実行される。

【0194】

図１２において、先ず、格納実績集計手段２８により、移転申請データベース４１（図２参照）に記憶された移転申請データの移転元のアカウントのアカウント情報および処理状況を示すステータス（ここでは、承認待ちの状態か、承認済の状態かがわかればよい。）を用いて、各アカウントが移転元になっている移転申請データに係る承認済リクエストが、集計期間中にキュー４２に実際に格納されたアカウント別実績件数を集計して求めるとともに、求めたアカウント別実績件数をキュー４２毎に合計してキュー別合計件数（実績値）を算出し（図５参照）、求めたアカウント別実績件数、および算出したキュー別合計件数（実績値）を、格納実績記憶手段４４に記憶させる（ステップＳ９０１）。

【0195】

また、格納実績集計手段２８により、承認済リクエストが集計期間中にキュー４２に実際に格納された時間帯毎（午前および午後）のアカウント別実績件数を集計して求め（図５参照）、求めた時間帯毎のアカウント別実績件数を用いて、承認が行われた時刻について時間帯に偏りのあるアカウントを決定し、格納実績記憶手段４４に記憶させる（ステップＳ９０２）。

【0196】

それから、アカウント・キュー対応関係変更手段２９により、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されている使用していたアカウント・キュー対応関係をクリアし、新しいアカウント・キュー対応関係の作成を開始する（ステップＳ９０３）。

【0197】

次に、アカウント・キュー対応関係変更手段２９により、格納実績記憶手段４４（図５参照）に記憶された優良顧客（顧客情報記憶手段４５（図７参照）で定められている。）のアカウントのアカウント別実績件数を用いて、優良顧客のアカウント（のアカウント別実績件数）を複数のキュー４２に分散して割り当てる（ステップＳ９０４）。この際、アカウント別実績件数が多い順に各キュー４２に割り当てていき、全てのキュー４２に割り当てた後に、割り当てていく方向を反転させる折り返し割当方法を適用してもよい。

【0198】

続いて、アカウント・キュー対応関係変更手段２９により、格納実績記憶手段４４（図５参照）に記憶された、承認が行われた時刻について時間帯に偏りのあるアカウントのアカウント別実績件数を用いて、時間帯に偏りのあるアカウント（のアカウント別実績件数）を複数のキュー４２に分散して割り当てる（ステップＳ９０５）。この際、アカウント別実績件数が多い順に各キュー４２に割り当てていき、全てのキュー４２に割り当てた後に、割り当てていく方向を反転させる折り返し割当方法を適用してもよい。

【0199】

その後、残りのアカウントの割当を開始する。先ず、アカウント・キュー対応関係変更手段２９により、基本アルゴリズムによる割当処理を行うために、その時点での割当の合計件数（時点合計）が最も少ないキュー４２を決定する（ステップＳ９０６）。

【0200】

続いて、アカウント・キュー対応関係変更手段２９により、その時点での割当の合計件数（時点合計）が最も少ないキュー４２に対し、その時点で残っているアカウントのうち最もアカウント別実績件数が大きいアカウント（のアカウント別実績件数）を割り当てる（ステップＳ９０７）。

【0201】

それから、アカウント・キュー対応関係変更手段２９により、割当対象のアカウントが残っているか否かを判断し（ステップＳ９０８）、残っている場合には、前述したステップＳ９０６の処理に戻り、以降、割当対象のアカウントが残っていない状態になるまで、ステップＳ９０６～Ｓ９０８のループ処理を繰り返す。

【0202】

一方、上記のステップＳ９０８で割当対象のアカウントが残っていないと判断した場合には、作成した新しいアカウント・キュー対応関係を、アカウント・キュー対応関係記憶手段４３（図４参照）に保存し（ステップＳ９０９）、処理を終了する。

【0203】

＜本実施形態の効果＞

【0204】

このような本実施形態によれば、次のような効果がある。すなわち、トランザクション管理システム１０は、キュー４２を備えているので、キュー４２への承認済リクエストの格納までの処理（申請受付手段２１、承認処理手段２２による処理）と、それ以降の処理（移転申請データ取得手段２３から確認手段２７までのループ処理）とを分離することができる。よって、移転申請データ取得手段２３から確認手段２７までの処理が繰り返し実行されている最中でも、新たな移転申請データの登録、新たな承認、キュー４２への新たな承認済リクエストの格納の処理を実行することができる。そして、キュー４２への格納が行われると、移転申請データ取得手段２３から確認手段２７までの処理により、順次、ナンスを割り当ててトランザクションデータをノード５０に送信することができる。このため、ナンスに起因するエラーの発生を回避することができる。

【0205】

また、「申請」のタイミングと「承認」のタイミングとの間には、タイムラグがあり、その間、移転申請データを保持する必要がある。また、移転元が同じアカウントになっている複数のトランザクションデータがある場合は、ナンスに起因するエラーが発生しないように、それらの複数のトランザクションデータの各々に１つずつ増えるナンスを付して順次ノード５０に送信する管理を行わなければならないので、それらの複数のトランザクションデータのうちの最初のトランザクションデータの送信タイミングと、後続のトランザクションデータの送信タイミングとの間には、タイムラグがあり、その間、後続のトランザクションデータを送信しない状態で保持する必要がある。前者の保持は、移転申請データベース４１（図２参照）により実現され、後者の保持は、キュー４２および移転申請データベース４１により実現される。従って、移転申請データベース４１は、双方の保持に利用されることになるので、ナンスに起因するエラーの発生を、効率的に回避することができる。このため、前述した特許文献１とは異なり、キュー４２にトランザクションデータ（トークンＩＤ、移転元および移転先の各アカウントのアカウント情報、移転数量などのデータ）を入れるのではなく、申請番号を含む承認済リクエストを入れるので、リソースの有効活用を図ることができる。

【0206】

さらに、トランザクション管理システム１０は、複数のキュー４２（本実施形態では、一例として、３つのキュー４２Ａ，４２Ｂ，４２Ｃ）を備え、アカウント・キュー対応関係記憶手段４３（図４参照）に記憶されたアカウント・キュー対応関係を示す情報に従って、承認済リクエストを格納するキュー４２を決める構成とされているので、移転元が同一のアカウントになっている移転申請データに係る承認済リクエストは、予め定められたアカウント・キュー対応関係に従って、同一のキュー４２に格納されるので、ナンスに起因するエラーの発生を回避することができる。

【0207】

また、複数のキュー４２を備えているので、移転元が異なるアカウントになっている移転申請データに係る承認済リクエストは、複数のキュー４２に分散して格納され、それぞれのキュー４２について、並列的に、移転申請データ取得手段２３から確認手段２７までの処理が行われるため、同時期または略同時期に発生した複数のトランザクションデータを早期にノード５０に送信し、早期に分散型台帳記憶手段６０に登録することができる。

【0208】

さらに、トランザクション管理システム１０は、承認処理手段２２により複数の移転申請データに対する承認担当者による一括承認を受け付け、それらの承認済リクエストをグループ化したグループ承認済リクエストをキュー４２に格納することができる。このため、キュー４２に格納された通常の承認済リクエストを１件ずつ取り出し、１件ずつナンスの値を取得し、取得したナンスの値をトランザクションデータに付してノード５０に送信し、その処理結果の通知を受信して次の承認済リクエストの処理に移行するという原則的な処理に対し、ナンスに起因するエラーを発生させない例外的な処理を行って、複数のトランザクションデータの送信処理を迅速に進めることができる。

【0209】

すなわち、一括承認は、一人の承認担当者による一時期の作業であるから、一括承認された複数の移転申請データに係る複数の承認済リクエストをグループ化してまとめて１つのグループ承認済リクエストとして取り扱えば、それらの複数の承認済リクエストの間に、タイミング的に、他の承認担当者による他の承認済リクエストが入り込むことはないので、それらのグループ化された複数の承認済リクエストに係る各トランザクションデータに付すナンスの値を連続させること（１つずつ増やしていくこと）ができる。換言すれば、同じ承認担当者による同時期または略同時期の複数の承認が行われたとしても、それが一括承認でなければ、それらの複数の承認の間に、他の承認担当者による他の承認が入る可能性があり、それらが同じ移転元のアカウントについての移転申請データに対する承認であれば、ナンスの値が１つずつ増えるような管理を行わなければならないので、原則的な処理を行うことになる。しかし、一括承認であれば、キュー４２には、一括承認を行った承認担当者による複数の承認済リクエストが必ず１つのグループとして格納され、他の承認担当者による他の承認済リクエストがそれらの間に入り込むことはないので、ノード５０から１件ずつナンスの値を取得してトランザクションデータに付して送信するという原則的な処理を行わなくても、各トランザクションデータに適切なナンスを付すことができるため、ナンスに起因するエラーの発生を回避しつつ、例外的な処理により効率的にトランザクションデータの送信処理を行うことができる。

【0210】

また、トランザクション管理システム１０は、格納実績集計手段２８、格納実績記憶手段４４（図５参照）、アカウント・キュー対応関係変更手段２９を備えているので、集計期間中の各キュー４２への格納実績を用いてアカウント・キュー対応関係を変更することができる。このため、複数のキュー４２のそれぞれについて行われる処理（移転申請データ取得手段２３から確認手段２７までの処理を繰り返す処理）の負荷を、均等または略均等に分散させることができるため、トランザクションデータのノード５０への送信、分散型台帳記憶手段６０への登録を、より一層迅速に行うことができる。

【0211】

また、トランザクション管理システム１０は、格納実績集計手段２８により、複数の時間帯に分けて格納実績を集計し、承認が行われた時刻について時間帯に偏りのあるアカウントを決定し、アカウント・キュー対応関係変更手段２９により、時間帯に偏りのあるアカウントを複数のキュー４２に分散させて割り当てる構成とされているので、時間帯を考慮せずに１日を通して見たときには、複数のキュー４２のそれぞれに格納される承認済リクエストの件数が均等または略均等に分散しているが、例えば、午前中に申請担当者に手続を依頼することが多い顧客（アカウント）が、同じキューに集まる等により、時間帯で見たときに、複数のキュー４２のそれぞれに格納される承認済リクエストの件数に偏りが生じるといった不都合を未然に防止することができる。このため、トランザクションデータのノード５０への送信、分散型台帳記憶手段６０への登録を、より一層迅速に行うことができる。

【0212】

さらに、トランザクション管理システム１０では、優先度付きキュー４２を用いるので、キュー４２に先に格納された承認済リクエストが、移転申請データ取得手段２３により先に取り出されるという原則的な処理に対し、特別な権限を有する承認担当者による承認を受け付けたとき、あるいは、緊急の移転申請や、優良顧客の移転申請に対する承認を受け付けたときに、他の承認済リクエストよりも先に、それらの優先度の高い優先度付きの承認済リクエストが取り出されるようにする例外的な処理を行うことができる。

【0213】

また、アカウント・キュー対応関係変更手段２９は、優先度の高い優良顧客のアカウントを複数のキュー４３に分散させて割り当てることができるので、優良顧客のアカウントについての承認済リクエストが、同じキュー４２に集まり、優先度の高い優先度付きの承認済リクエストであるにもかかわらず、キュー４２への滞留時間が長くなってしまうという不都合を未然に防止することができる。

【0214】

さらに、アカウント・キュー対応関係変更手段２９は、割当処理途中の各時点でキュー別合計件数が最も小さいキュー４２を求め、そのキュー４２に対し、残っているアカウントのうち割当処理途中の当該時点でアカウント別実績件数が最も大きいアカウントを割り当てるという基本アルゴリズムを採用することができるので、キュー別合計件数を容易に均一または略均一にすることができるとともに、特別な目的を持った割当（時間帯に偏りのある顧客のアカウントの各キュー４２への分散割当や、優良顧客のアカウントの各キュー４２への分散割当）と容易に組み合わせることができる。

【0215】

＜変形の形態＞

【0216】

なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。

【0217】

例えば、前記実施形態では、複数のキュー４２が設けられていたが、本発明は、１つのキュー４２を用いてもよい。しかし、ナンスに起因するエラーの発生を回避しつつ、トランザクションデータの送信、登録の処理を迅速に行うことができるという観点で、複数のキュー４２を用いることが好ましい。

【0218】

また、前記実施形態では、アカウント・キュー対応関係変更手段２９は、集計期間中のキュー別合計件数が均一または略均一になるように、各アカウントのアカウント別実績件数を、複数のキュー４２のいずれかに割り当てる方法として、割当処理途中の各時点でキュー別合計件数が最も小さいキュー４２を求め、そのキュー４２に対し、残っているアカウントのうち割当処理途中の当該時点でアカウント別実績件数が最も大きいアカウントを割り当てる処理を繰り返すという基本アルゴリズムを採用していたが、これに限定されるものではない。

【0219】

例えば、格納実績記憶手段４４（図５参照）に記憶されている全てのキュー４２のキュー別合計件数（実績値）のうち、最も大きい件数のキュー４２のキュー別合計件数（実績値）と、最も小さい件数のキュー４２のキュー別合計件数（実績値）とを求め、これらの差分の半分の件数に一致するか若しくは最も近いアカウント別実績件数のアカウントの割当を、キュー別合計件数（実績値）が最も大きいキュー４２から最も小さいキュー４２に変更する。ここで割当の変更処理を終了してもよいが、その後、さらに変更後の割当で、全てのキュー４２のキュー別合計件数（仮定値）を算出し、算出した全てのキュー４２のキュー別合計件数（仮定値）のうち、最も大きい件数のキュー４２のキュー別合計件数（仮定値）と、最も小さい件数のキュー４２のキュー別合計件数（仮定値）とを求め、これらの差分の半分の件数に一致するか若しくは最も近いアカウント別実績件数のアカウントの割当を、キュー別合計件数（仮定値）が最も大きいキュー４２から最も小さいキュー４２に変更し、以降、このような割当の変更を複数回繰り返してもよい。

【産業上の利用可能性】

【0220】

以上のように、本発明のトランザクション管理システムおよびプログラムは、例えば証券会社等の金融機関が、セキュリティトークンの移転時のブロックチェーンシステムへのトランザクションの送信管理を行う場合に用いるのに適している。

【符号の説明】

【0221】

１ 通信回線
１０ トランザクション管理システム
２２ 承認処理手段
２３ 移転申請データ取得手段
２４ ナンス取得手段
２５ トランザクション作成手段
２６ トランザクション送信手段
２７ 確認手段
２８ 格納実績集計手段
２９ アカウント・キュー対応関係変更手段
４１ 移転申請データベース
４２，４２Ａ，４２Ｂ，４２Ｃ キュー
４３ アカウント・キュー対応関係記憶手段
４４ 格納実績記憶手段
５０ ノード
９０ ブロックチェーンシステム

【要約】

【課題】ナンスに起因するエラーの発生を効率的に回避し、担当者の作業負担の軽減およびトランザクションの早期登録を実現できるトランザクション管理システムを提供する。
【解決手段】トランザクション管理システム１０は、移転申請データベース４１に登録された移転申請データに対する承認を受け付け、申請番号を含む承認済リクエストをキュー４２に格納する。また、このキュー４２への格納処理とは分離された処理として、キュー４２から１件分の承認済リクエストを取り出し、そこに含まれる申請番号を用いて移転申請データベース４１から移転申請データを取得し、移転元のアカウントのナンスをノード５０から取得し、ナンスの値を付したトランザクションデータを作成してノード５０に送信し、処理結果の通知をノード５０から受信した後、次の承認済リクエストを取り出す。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】