(58)【調査した分野】(Int.Cl.,DB名)
複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を前記複数のノードの少なくとも一つに送信する手順と、
前記承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順と、
受信した前記承認信号の承認に基づき、前記トランザクション、および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし、前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順とを含む信号処理方法。
前記承認信号を受信する手順において受信される前記承認信号が、前記複数のノードのうちの前記一定割合に満たない場合には、前記トランザクションを破棄する、請求項1に記載の信号処理方法。
複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を、前記複数のノードの一つから前記複数のノードの他の少なくとも一つに送信する手順と、
前記承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順と、
受信した前記承認信号の承認に基づき、前記トランザクション、および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし、前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順を前記複数のノードに実行させるように構成される信号処理プログラム。
【発明を実施するための形態】
【0012】
本明細書、および請求項において、「乃至」は、数量の下限と上限を示し、その中間を省略するために用いる。したがって、例えば1乃至10の自然数、という場合、1と10のみではなく、1から10に至る自然数すべてを含む。
【0013】
本明細書において、複数の構成要素をそれぞれ区別して指す場合、符号の後にアンダーバーと自然数(あるいは自然数を意味する記号)を用いて表記する。複数の構成要素の各々を区別せずに全体、あるいはそのうちの任意に選択される複数を表記する場合には、符号のみを用いる。
【0014】
(第1実施形態)
本実施形態では、データ処理方法に関して説明を行う。
【0015】
[1.構成]
図1に、本発明の実施形態の一つであるデータ処理方法に係るシステム構成例を模式的に示す。このデータ処理方法では、処理する対象となるデータ100は、第1の通信端末110_1乃至第nの通信端末110_nを含む複数の通信端末110(nは2以上の自然数)を介して複数のユーザによって共有、管理される。複数のユーザで構成される集合体は、不特定ユーザの集合体でもよいが、同一の組織に所属する複数のユーザ、あるいは共通の目的を有する複数のユーザで構成される集合体でもよい。例えば家族、同居人、社員、職員、クラスメート、クラブ、サークルなどの集合体が挙げられる。この集合体を、ユーザグループと呼ぶ。ユーザグループが維持される期間に限定は無く、ユーザグループは一時的に存在してもよく、数十年といった長期間維持されてもよい。
【0016】
通信端末110はユーザの管理下に置かれ、通信機能を有する端末であり、据え付け型(デスクトップ型)コンピュータをはじめ、ノート型コンピュータや携帯電話(タブレット、スマートフォンを含む)などの携帯通信端末が例示される。通信端末110は、互いにネットワーク120を通じて通信することができる。ネットワーク120は、インターネットのような外部ネットワークでも良く、LAN(Local Area Network)などの内部ネットワークでもよい。内部ネットワークをネットワーク120として用いる場合、通信端末110のうち少なくとも一つが外部ネットワークと接続される。図示していないが、通信端末110は、その一部あるいは全てが電話回線によって互いに接続されていてもよい。通信端末110はノードとも呼ばれる。
【0017】
データ100はテキストデータ、画像データ、あるいはこれらの複合データであり、電子化されている。例えば文書、表、写真、絵、数値などである。データ100には暗号化を施さず、ユーザグループ内においてパスワードによる保護や閲覧制限に供さなくてもよい。この場合、ユーザグループの全員が通信端末110を介してデータ100を自由に閲覧することができる。
【0018】
データ100は、ネットワーク120に接続されたサーバ150に格納してもよい。サーバ150を直接、あるいは間接的に管理する管理者(以下、単に管理者)は、管理者のサービス内容に応じてデータ100のための様々なプラットフォームを提供する。例えばユーザグループのスケジュールデータを管理するためのプラットフォーム、ユーザの任意入力情報を時系列に表示するためのプラットフォーム、ユーザグループの共有財産に係るデータを表示するためのプラットフォームなどが提供される。ユーザは、扱うデータ100に最適なプラットフォームを選択し、プラットフォームの環境に従ってデータ100を扱う。
【0019】
ネットワーク120にはさらに、ブロックチェーンネットワーク130が接続される。ブロックチェーンネットワーク130は、ネットワーク120を介して互いに接続された複数の通信端末132_1から132_m(mは自然数)で構成される。これらの通信端末132は、スペックの差異は存在し得るものの、権限に関しては対等であり、互いに直接通信することができ、いわゆるP2P(Peer−to−Peer)ネットワークを形成する。通信端末132はノードとも呼ばれる。以下の記載では、通信端末110と区別するため、通信端末132をノードと呼ぶ。通信端末110の少なくとも一つは、ノード132の少なくとも一つとネットワーク120を介して接続される。通信端末110はノード132として機能することも可能であり、逆に、ノード132が通信端末110を兼ねてもよい。この場合、通信端末110の少なくとも一つがノード132として機能すればよい。
【0020】
ノード132は、データの送信処理または受信処理に基づく情報処理の単位であり、不特定の所有者がそれぞれ管理する通信端末であってもよく、この場合、ブロックチェーンネットワーク130はパブリックブロックチェーンネットワークとも呼ばれる。あるいはノード132のすべて、あるいは一部が管理者によって管理されるよう、ブロックチェーンネットワーク130を構成してもよい。例えば管理者と同じ業界内の複数の関係者によってブロックチェーンネットワーク130を構成する。この場合、ブロックチェーンネットワーク130はプライベートブロックチェーンネットワーク、あるいはコンソーシアムブロックチェーンネットワークとも呼ばれる。
【0021】
[2.データ処理]
2.1 概要
本実施形態のデータ処理方法では、データ100に対してユーザが通信端末110を介して何らかの処理を行い、データ100とは異なるデータ102へ変換する(
図1)。データ処理方法のフローチャートを
図2に示す。このデータ処理方法では、最初にユーザグループのうちの一人(以下、便宜上、第1のユーザと記す)が、自己の管理下の通信端末(以下、便宜上、第1の通信端末110_1とする)を用いて処理依頼(トランズアクション、図においてTA)を作成する(S100)。その後トランズアクションに対する承認を他のユーザに要求する(S102)。承認を要求されたユーザはトランズアクションを確認し、承認か非承認かを選択する(S104)。トランズアクションがユーザグループによって最終的に承認されるか否かについては一定の条件が課せられ、この承認条件が満たされない場合には、データ処理は許容されず、トランズアクションは破棄される(S106)。一方、承認条件が満たされた場合、データ処理が開始される。
【0022】
詳細は後述するが、トランズアクションの承認・非承認には、トランズアクションから生成される電子署名が利用される。電子署名の数が規定数を満たしているかどうか、あるいはあらかじめ決められた通信端末110によって電子署名が生成されているか否か、などが承認条件となる。
【0023】
データ処理が開始されると、トランズアクションがブロックチェーンネットワーク130へブロードキャストされ(S110)、ブロックチェーンネットワーク130内でトランズアクションの正当性が検証される。正当性が確認されたのち、トランズアクションが格納されるブロックが生成される(S112)。生成されたブロックが各ノード132に格納されるブロックチェーンに追加されてブロックチェーンの更新が行われると同時に(S114)、トランズアクションが実行される(S116)。以下、このフローを詳細に説明する。
【0024】
2.2 トランズアクションの作成(S100)
最初に第1のユーザは、トランズアクションを作成する。このトランズアクションには、データ処理の内容と、データ処理の開始に必要な承認条件などが含まれる。トランズアクションにはさらに、ユーザグループの通信端末110のアドレスなどが含まれてもよい。
【0025】
トランズアクションは暗号化処理される。暗号化は、例えば公開鍵暗号方式を用いて行うことができる。具体的には
図3(A)に示すように、トランズアクションを送信する第1の通信端末110_1において、暗号化と復号化で用いる二つの鍵を生成する。一つは公開鍵112_1であり、他方は秘密鍵114_1である。秘密鍵114_1と公開鍵112_1は対をなし、秘密鍵114_1で暗号化されたものは公開鍵112_1で復号化できるものの、他の鍵では復号化できない。逆に公開鍵112_1で暗号化されたものは秘密鍵114_1で復号化することができるものの、他の鍵では復号化できない。トランズアクションTAが秘密鍵114_1によって暗号化されると、第1の電子署名(ES1)が生成される。
【0026】
2.3 承認要求(S102)
トランズアクションが作成されたのち、トランズアクションの承認段階へ移行する。具体的には
図4に示すように、第1の通信端末110_1は、承認要求信号をユーザグループ内の他のユーザが保有する通信端末110へ送信する(S120)。承認要求信号には、暗号化される前(すなわち、オリジナル)のトランズアクションTA、および第1の電子署名ES1が含まれる。さらに第1の通信端末110_1は、承認要求信号を送信する際、あるいは承認要求信号の送信前か送信後に公開鍵112_1を、承認要求信号の送信先である通信端末110へ送信する。
図4では、第1の通信端末110_1を除く通信端末110のすべてに承認要求信号が送信される例が示されているが、後述するように、通信端末110のうちの一部に承認要求信号を選択的に送信してもよい。また、第1の通信端末110_1に対して自己送信してもよい。
【0027】
承認要求信号を受け取ったユーザは、通信端末110において公開鍵112_1を用いて電子署名ES1を復号化し、暗号化される前のトランズアクションと電子署名を復号化して生成したトランズアクションとを照合することで検証を行う。照合の結果、これらが同一であれば、トランズアクションが偽造、改ざんされておらず、トランズアクションの正当性が証明される。逆に、オリジナルのトランズアクションと電子署名を復号化して生成されたトランズアクションとが同一でなければ、トランズアクションが偽造、改ざんされていると判断することができる。図示していないが、正当性が証明されない場合、トランズアクションは承認されず、破棄される。
【0028】
2.4 承認(S104)
トランズアクションを受信した通信端末110のユーザは、トランズアクションを承認する、あるいは承認しないという行為のいずれかを選択する(S104)。承認が選択された場合、承認するユーザ(ここでは便宜上、第2のユーザとする)の保有する通信端末(ここでは便宜上、第2の通信端末とする)110_2内で生成される秘密鍵114_2によってトランズアクションが暗号化され、電子署名ES2が生成される(
図3(B))。第2の通信端末110_2は、第1のユーザから送信された承認要求信号に含まれるオリジナルのトランズアクションTAと電子署名ES1、および第2の通信端末110_2によって生成された電子署名ES2を含む承認信号を送信する(S122)。承認要求信号の送信と同様、承認信号の送信前、送信後、あるいは送信と同時に、秘密鍵114_2に対応する公開鍵112_2も送信される。
図4では、第2の通信端末110_1を除く通信端末110のすべてに承認信号が送信される例が示されているが、通信端末110のうちの一部に選択的に承認信号を送信してもよい。また、第2の通信端末110_2に対して承認信号を自己送信してもよい。ここまでのプロセスにより、一つのトランズアクションに対応する二つの電子署名(ES1とES2)が生成される。
【0029】
承認信号を受け取った通信端末110では、二つの電子署名を対応する公開鍵112_1、112_2を用いて復号化し、トランズアクションの検証を行うことができる(
図3(B)参照)。これにより、どのユーザが承認したかを把握することができる。
【0030】
トランズアクションを承認しない場合、第2の通信端末110_2は承認信号を送信しない。あるいは、非承認信号を送信する。非承認信号を送信する場合、第2の通信端末110_2はトランズアクションの暗号化を行わなくてもよい。この場合、第2のユーザの電子署名が生成されないため、非承認信号には第2のユーザの電子署名ES2が含まれない。
【0031】
同様の承認・非承認の選択と承認信号、あるいは非承認信号の送信が他のユーザの通信端末110においても行うことができる(S124、S126)。
【0032】
2.5 承認条件
トランズアクションがユーザグループによって承認される条件は、ユーザグループごとに設定することができる。例えば、ユーザ全員が承認することによってトランズアクションが初めて承認されるよう、条件を設定してもよい。この場合、n個の電子署名が生成されることによってトランズアクションが承認される。
【0033】
あるいは、ユーザグループの一定の割合、例えば2/3や過半数の承認によってトランズアクションが承認されるよう、条件を設定してもよい。すなわち、1よりも大きくn以下の自然数をkとすると、k−1回の承認信号の送信、換言すると、k人のユーザの電子署名の生成によってトランズアクションが初めて承認されるよう承認条件を設定することができる。kは任意に選択される。例えば過半数のユーザの承認が必要な場合には、kはn/2よりも大きい自然数が選択される。
【0034】
一部、あるいは特定のユーザに対してトランズアクションに対する承認権限を与えてもよい。例えばグループユーザのうち一人、あるいは複数に対して承認権限を与え、他のユーザには承認権限を与えない(すなわち、非承認権限を付与する)。トランズアクションの承認は、承認権限を有するユーザの通信端末110によって生成される電子署名(あるいは、承認権限を有するユーザの意図によって生成された電子署名)のすべてが得られることによってトランズアクションが初めて承認される。
【0035】
あるいは上述した承認条件を複合的に用いてもよい。例えば適宜kを設定してk個の電子署名が生成され、かつ、承認権限を有するユーザの電子署名が生成されることを承認条件として設定してもよい。また、承認要求信号を送信するごとに承認権限を適宜割り振ってもよい。
【0036】
特定のユーザに対して承認権限を与える場合、第1の通信端末110_1は承認権限を有するユーザが保有する通信端末110だけに承認要求信号、あるいは公開鍵112_1を選択的に送信してもよい。この場合、承認権限を有するユーザの通信端末110は公開鍵112_1を受け取ったのちに承認信号を送信することになる。あるいは、承認権限を有するユーザの通信端末110を特定するための情報をトランズアクションに付加し、この情報に従って承認の成否を決定してもよい。承認権限を与えないユーザが保有する通信端末110に対しては、暗号化していないトランズアクションのみを送信してもよい。これにより、承認権限を持たないユーザも共有されるデータに対してどのような処理が行われうるかを知ることができる。
【0037】
承認条件は、データ処理の内容に応じてトランズアクションごとに変更してもよい。例えば処理内容がデータに大きな変化を及ぼす場合にはユーザ全員の承認を必要とする一方、処理内容が軽微であれば承認権限を有する一部の者のみ、あるいは第1のユーザの承認のみでトランズアクションが承認されるようにしてもよい。
【0038】
承認条件が満たされない場合、すなわち、承認信号の数が一定の割合に満たない場合、トランズアクションは破棄され、実行されない(S106)。より具体的には、ユーザ数に対する承認信号の数の割合が、複数のユーザが保有する通信端末110の数に対する承認権限を有するユーザが保有する通信端末110の割合に満たない場合、トランズアクションは破棄され、実行されない。トランズアクションの破棄により、データ処理方法は終了する。
【0039】
2.6 ブロードキャスト(S110)
トランズアクションが承認されると、トランズアクションの実行が開始される。具体的には、最初にトランズアクションはネットワーク120を介してブロックチェーンネットワーク130へブロードキャストされる(S110)。
【0040】
例えば第1の通信端末110_1は、受信した承認信号に含まれる電子署名の数が承認条件を満たすか否かを判断する。承認条件が満たされたと判断された場合、トランズアクション、電子署名ES1、および受けとった電子署名をブロックチェーンネットワーク130へブロードキャストする(S128)。なお、ブロードキャストを行う通信端末110は第1の通信端末110_1に限られず、任意に設定することができる。例えば、あらかじめ決められた通信端末110からブロードキャストしても良く、承認条件を満たすために必要な電子署名を最後に生成した通信端末110がブロードキャストを行ってもよい。
2.7 ブロックチェーンの更新
【0041】
ブロードキャストが行われたのち、トランズアクションの検証が行われる。
図5(A)に示すように、ブロックチェーンネットワーク130の各ノード132の記憶装置には、これまでにブロードキャストされた過去のトランズアクションをまとめたブロック140が格納されている。これらのブロック140は生成順に連結されて時系列を作る。新たなトランズアクションはブロックチェーンネットワーク130内で検証され、トランズアクションの正当性が確認されると、このトランズアクションを含む新たなブロック140が生成される。新たにに生成されたブロック(
図5(A)ではブロック140_3)は、これまでに生成されたブロック(ブロック140_1、ブロック140_2)に連結され、これによりブロックチェーンの更新が行われ、トランズアクションが実行される。
【0042】
通信端末110からブロードキャストされた各電子署名は、ノード132において対応する公開鍵を用いて復号化される。復号化されて生成されるトランズアクションとオリジナルのトランズアクションを照合することで、トランズアクションの正当性がノード132によって判断される。またノード132は、承認条件が満たされているかどうかを検証する。例えばブロードキャストされた電子署名の数がトランズアクションに記される承認条件に適合する、すなわち、署名に必要な電子署名の数と同一以上であることを検証する。あるいは、ブロードキャストされた電子署名が、トランズアクションで規定される承認権限者の電子署名であるか否かを検証する。この検証プロセスの結果トランズアクションが正当であり、かつ、承認条件が満たされていると判断されたのち、ブロックチェーンの更新が開始される。
【0043】
各ブロック140には、ブロックヘッダ142とトランズアクション情報144が含まれる(
図5(A))。トランズアクション情報144には、複数のトランズアクションに関する情報が含まれる。ブロックヘッダ142は、前段のブロック140のブロックヘッダ142をハッシュ計算(暗号学的ハッシュ関数を用いる計算)することによって得られるハッシュ値146、およびそのブロック140に格納される複数のトランズアクションを多重にハッシュ計算することによって得られるトランズアクションのハッシュ木ルート(マークルルート)値148を含むことができる(
図5(B))。
【0044】
通信端末110からブロードキャストされたトランズアクションは、他のトランズアクションとともにハッシュ計算に供され、ハッシュ木ルート値148が生成される。得られたハッシュ木ルート値148、および前段のブロックヘッダ(例えば
図5(A)ではブロック140_2のブロックヘッダ142)のハッシュ値146を合わせてハッシュ計算が行われ、新たなブロック140_3が生成される(S112)。
【0045】
新たなブロック140_3が生成されると、ブロックチェーンネットワーク130内でブロック140_3の検証が行われる(S112)。具体的には、前段のブロック140_2とハッシュ計算で用いたナンスをパラメータとしてハッシュ値を求め、ブロックチェーンネットワーク130内で規定される条件を満たしているかどうかが確認される。条件が満たされていれば検証されたと見做され、新たなブロック140_3がノード132の記憶装置内のブロックチェーンに追加される(S114)。これによりよりトランズアクションが確定され、実行される(S116)。
【0046】
上述したブロックチェーンの形成は、PoW(Proof of Work)というコンセンサスアルゴリズムを利用したものであるが、コンセンサスアルゴリズムとしては、PoS(Proof of Stake)やPoI(Proof of Importance)など、様々なアルゴリズムを採用することができる。
【0047】
トランズアクションが実行されると、ブロックチェーンネットワーク130のノード132は通信端末110に報告信号を送信してもよい(S152)。この信号は、承認条件が満たされていると判断されたとき、あるいはトランズアクションが含まれる新たなブロックがブロックチェーンに追加されたときに送信してもよい。
【0048】
以上のプロセスにより、本実施形態のデータ処理が行われる。
【0049】
あるデータをハッシュ計算することで得られるハッシュ値は、元のデータが少しでも変化すると異なる数値となる。したがってハッシュ値を用いることでデータの正当性を検証することができる。上述したように、各ブロック140には前段のブロックヘッダ142から得られるハッシュ値146が含まれるため、あるブロック140の内容を改ざん、偽造すると、次段以降のブロック140に付与されるハッシュ値146が変化する。したがって、改ざん、偽造を成功させるためには、それ以降のブロック140のすべてのハッシュを再計算する必要があり、これにより、改ざん、偽造が事実上不可能となる。
【0050】
複数のユーザによって共有されるデータに対し、ネットワークを介して接続される複数の通信端末を用いて複数のユーザによって処理を行う場合、無制限な処理を許容するとデータの改ざんや偽造、あるいは不適切な変更が行われ、データとしての価値や信頼性が失われる。このため、データ処理に対して何らかの制限を加える必要がある。しかしながら、処理権限が限られたユーザに集中する場合、処理権限を持たないユーザによる処理の提案が承認されたとしても、処理権限を保有するユーザが必ずしも提案に従ってデータ処理するとは限らない。ここにおいて、データが共有されるとは、複数のユーザが同一のデータに対して更新処理権限を有することをいう。
【0051】
しかしながら、本実施形態のデータ処理方法では、データ処理というトランズアクションは、電子署名と公開鍵112とともにブロックチェーンネットワーク130にブロードキャストされ、ブロック140に格納される。ブロック140に格納されたすべてのトランズアクションはノード132によって検証することができる。また、通信端末110もブロックチェーンを閲覧することができる。このため、処理権限を有するユーザ、あるいはユーザグループとは無関係の第三者によるトランズアクションの偽造や改ざんなどの不正を抑止、防止することができる。
【0052】
さらに上述したように、本実施形態のデータ処理方法では、データ100自体には暗号処理を施さず、グループユーザ内での自由な閲覧を許容する。したがって、全てのユーザがデータ100の状況を随時確認、監視することがでる。また、ユーザの全員、あるいは一部のユーザの承認をデータ100に対する処理の承認条件とすることで、データに対する不正処理を防ぐことが可能である。このため、本実施形態を適用することで、データに対する処理権限が分散されてユーザにとって高い利便性が提供できるのみならず、データの健全性を維持可能なデータ処理を実現することができる。
【0053】
(第2実施形態)
本実施形態では、第1実施形態のデータ処理方法とは異なるデータ処理方法に関して説明を行う。第1実施形態と同様の内容に関しては説明を割愛することがある。
【0054】
第1実施形態で述べたデータ処理方法では、承認要求信号と承認信号は、各通信端末110間で送受信される。本実施形態で述べるデータ処理方法は、データ100を格納、あるいは管理するするサーバ150を経由して承認要求信号と承認信号が送受信される点で、第1実施形態のデータ処理方法と異なる。
【0055】
具体的には
図6に示すように、承認要求信号は通信端末110(便宜上、第1の通信端末110_1とする)からサーバ150へ送信される(S140)。サーバ150において電子署名ES1の復号化とオリジナルのトランズアクションとの照合が行われ、トランズアクションの正当性が検証される。正当性が確認されたのち、サーバ150はすべての通信端末110、第1の通信端末110_1を除く通信端末110、あるいは承認権限を有するユーザの通信端末110に対し、承認要求信号を送信する(S142)。承認要求信号を受信した通信端末110は、承認信号、あるいは非承認信号をサーバ150へ送信する(S144)。
【0056】
サーバ150は受信した承認信号に含まれる電子署名を復号化し、上述した照合プロセスを実行する。その後サーバ150は、承認条件が満たされているか否かを受信した電子署名を利用して判断する。例えば、受信した電子署名の数がトランズアクションによって規定される電子署名の数以上であるか否か、承認権限を有するユーザの通信端末110によって生成された電子署名が含まれるかどうかなどを判断する。
【0057】
承認条件が満足されていると判断された場合、トランズアクションの実行が開始される。すなわち、サーバ150はトランズアクション、およびサーバ150の秘密鍵114を用いて生成した電子署名をブロックチェーンネットワーク130へブロードキャストする(S148)。トランズアクションの検証やその後のブロックチェーンの更新は、第1実施形態で述べた方法と同様に行うことができる。また、ブロックチェーンが更新された場合には、その報告信号はブロックチェーンネットワーク130からサーバ150を経由して各通信端末110に送信することができる(S150、S152)。
【0058】
(第3実施形態)
本実施形態では、第1、第2実施形態とは異なるデータ処理方法を説明する。第1実施形態と同様の内容に関しては説明を割愛することがある。本実施形態のデータ処理方法は、承認要求信号が通信端末110から直接ブロックチェーンネットワーク130へブロードキャストされる点で、第1、第2実施形態のデータ処理方法と異なる。
【0059】
具体的には
図7に示すように、トランズアクションを作成する通信端末110(便宜上、第1の通信端末110_1とする)は、トランズアクション、電子署名ES1をブロックチェーンネットワーク130へブロードキャストする(S160)。このトランズアクションは、データに対する処理内容や承認条件とともに、承認を行うユーザの通信端末110のアドレスなどを含むことができる。
【0060】
図示していないが、承認要求信号の送信を行うとともに、第1の通信端末110_1は他の通信端末110に対し、トランズアクションを送信したことを知らせるための信号を送信してもよい。
【0061】
電子署名はブロックチェーンネットワーク130内の各ノード132で復号化され、トランズアクションとともに検証に供される。トランズアクションの正当性が確認されると、このトランズアクションを含むブロック140が生成され、ブロックチェーンが更新される。さらに、トランズアクションに含まれるアドレス、すなわちユーザグループの通信端末110に対し、ノード132から承認要求信号が送信される(S162)。なお、この承認要求信号は必ずしも送信する必要は無い。この場合、各通信端末110がブロックチェーンネットワーク130へアクセスし、自己のアドレスに対する承認要求が含まれるトランズアクションを検索すればよい。該当するトランズアクションが存在している場合、通信端末110はその旨を表示してユーザに承認、あるいは非承認の判断を行うための機会を提供する。
【0062】
その後ユーザは通信端末110を介し、承認信号、あるいは非承認信号をブロックチェーンネットワーク130へ送信する(S164)。ノード132はこれらの信号に含まれる電子署名の復号化、トランズアクションの検証を行う。さらに、トランズアクションに記載れた情報、例えば承認を行うべきユーザの通信端末のアドレスなどに基づいてブロックチェーン内で検索を行い、該当するトランズアクションに含まれる電子署名を特定する。ノード132はさらに、特定された電子署名の数や、電子署名を生成した通信端末のアドレスから承認条件が満たされているかどうかを判断する。承認条件が満たされている場合、第1実施形態と同様、トランズアクションの実行のため、ブロックの生成とブロックチェーンの更新が開始される。承認条件が満たされていると判断されたとき、あるいはブロックチェーンの更新が完了したときに、報告信号を各通信端末110へ送信してもよい(S166)。
【0063】
(第4実施形態)
本実施形態では、複数のユーザによって共有されるデータが、預貯金取扱金融機関(以下、銀行)によって提供されるプラットフォームの環境に従う例を用い、データ処理方法を説明する。具体的には、プラットフォームが口座であり、n人のユーザが通信端末110をそれぞれ介して口座(以下、グループ口座と記す)を共有、管理する場合のデータ処理方法を説明する。第1乃至第3実施形態で述べた内容と同一の内容に関しては説明を割愛することがある。
【0064】
[1.トランズアクションの作成]
最初に、複数のユーザのうち一人(以下、第1のユーザとする)が、グループ口座というデータに対し、トランズアクションを作成する。トランズアクションとしては、例えばユーザからグループ口座への振り込み、グループ口座から他のグループ口座への振り込み、グループ口座からユーザグループ内のユーザが個人管理する口座への入金などが挙げられる。具体的には、一人のユーザ(ここでは、第1のユーザとする)は、保有する通信端末110(ここでは、第1の通信端末110_1とする)を用い、トランズアクションを作成する。第1の通信端末110_1は、トランズアクションを秘密鍵114を用いて暗号化した電子署名を生成する(
図3参照)。
【0065】
なお、このようなグループ口座では、必ずしも法定通貨(現実通貨)を扱う必要は無く、仮想通貨による取引を行ってもよい。仮想通貨を用いることで、プラットフォームを提供する銀行などの金融機関と直接取引を持たないユーザも、容易にグループ口座に関与、参加し、グループ口座を共有、管理することが可能となる。これは、仮想通貨はクレジットカード決済などの簡便な方法で購入することができ、通信端末110内のソフトウェアやアプリケーションを用い、ウォレットとして管理することができるからである。
【0066】
[2.承認要求信号の送受信]
第1のユーザは、第1の通信端末110_1を用い、トランズアクションに対する承認要求信号をユーザグループ内のユーザが保有する通信端末110へ送信する(
図4におけるS120)。これにより、全てのユーザは、第1のユーザによってデータ100に対する処理の提案が行われたことを認識することができる。特定のユーザのみが承認権限を有する場合には、そのユーザの通信端末110のみに承認要求信号を送信してもよい。
【0067】
承認要求信号を受け取った通信端末110は、公開鍵112を用いて電子署名を復号化し、トランズアクションと比較を行い、トランズアクションの検証を行う(
図3参照)。検証の結果、トランズアクションが正当である、すなわち、第1のユーザが作成したトランズアクションであること、トランズアクションに偽造や改ざんが行われていないことが証明される。
【0068】
[3.承認信号の送受信とブロックの生成]
トランズアクションが正当であると検証された場合、承認要求信号を受信した通信端末110は、表示画面上に承認要求信号を受信したことを表示し、トランズアクションの承認、非承認の選択機会をユーザに与える。ユーザによってトランズアクションの承認が選択された場合、通信端末110を介して承認信号が送信される。例えば
図4に示すように、第2のユーザは第2の通信端末110_2を介し、承認信号を第1の通信端末110_1、および第3の通信端末110_3から第nの通信端末110_nへ送信する(S122)。第1実施形態で述べたように、承認信号にはトランズアクション、第1の通信端末110_1によって生成された電子署名ES1、および第2の通信端末110_2によって生成された電子署名ES2が含まれる。これにより、ユーザ全員が第2のユーザがトランズアクションを承認したことを認識することができる。
【0069】
同様に、第3の通信端末110_3乃至第nの通信端末110_nが承認信号を第1の通信端末110_1を含む複数の通信端末110へ送信する(S124、S126)。ユーザがトランズアクションを承認しない場合には、第1の通信端末110_1を含む複数の通信端末110へ非承認信号が送信される。あるいは実施形態1で述べたように、承認しない場合には何ら信号を送信しなくてもよい。
【0070】
第1の通信端末110_1が承認信号を他の通信端末110のすべてから受信した場合、トランズアクションがグループユーザによって承認されたことを意味する。その後、トランズアクションと、承認に係ったユーザの通信端末110から送信された電子署名がブロックチェーンネットワーク130へブロードキャストされ(S128)、第1実施形態で述べたように、ブロック140の生成に供される。
【0071】
ブロック140の生成、検証が完了し、既存のブロックチェーンに新たなブロック140が追加されることでトランズアクションが実行される。この時、ブロックチェーンネットワーク130から通信端末110に対し、トランズアクションが実行されたことを通知するための報告信号を送信してもよい(S130)。
【0072】
[4.プライベートブロックチェーン]
第2実施形態で述べたように、特定のサーバを経由し、承認要求信号や承認信号の送受信を行ってもよい。また、特定のサーバ内でブロックの生成や検証、追加を行ってもよい。特定のサーバとは、例えばデータ100のプラットフォームを提供する管理者が直接、あるいは間接的に管理するサーバ150であり、本実施形態では銀行などの金融機関が直接、あるいは間接的に管理するサーバに相当する。
【0073】
具体的には
図8に示すように、通信端末110がネットワーク120を介してサーバ150と接続される。データ100はサーバ150内に格納される。ここでは、トランズアクションを送信する第1の通信端末110_1は、承認要求信号をサーバ150に送信する(
図6におけるS140)。トランズアクションを受信したサーバ150は、第2の通信端末110_2乃至第nの通信端末110_nに対し、承認要求信号を送信する(S142)。第2の通信端末110_2乃至第nの通信端末110_nの各々は承認信号をサーバ150に対して送信する(S144)。
【0074】
この場合、サーバ150からブロックチェーンネットワーク130へのブロードキャストは行わず、ブロック140の生成とその検証をサーバ150内で行ってもよい。これにより、ブロックチェーンネットワーク130が不特定多数のノード132によって形成されるという不確定要素を排除することができ、ユーザに信頼性の高いサービスを提供することが可能となる。
【0075】
(第5実施形態)
本実施形態では、上述したデータ処理方法を実行するためのデータ処理プログラムに関して説明を行う。本実施形態では、第4実施形態と同様、データプラットフォームとして銀行口座を例に挙げて説明を行う。第1乃至第4実施形態で述べた構成と同様の構成に関しては説明を割愛することがある。
【0076】
データ処理プログラムは、データを共有する複数のユーザが保有する通信端末110に実装される。プログラムは外部記録媒体に記憶された状態で提供してもよく、ネットワーク120を介して提供されてもよい。
【0077】
[1.グループ口座の開設]
最初にグループ口座を開設する。この作業は、複数の通信端末110のうちの一つを用いて行えばよい。ここでは、グループ口座の開設を行うユーザと通信端末を便宜上、それぞれ第1のユーザ、第1の通信端末110_1とする。このプロセスのフローを
図9に示す。
【0078】
最初にプログラムを起動する(S160)。起動の際には、パスワード入力や生体情報認証などにより、プログラムが正当なユーザによって操作されていることを確認するよう、プログラムを構成してもよい。起動後、通信端末110の表示画面上には、例えば
図10(A)に示す表示を行うことができる。具体的には、第1のユーザが現在参加している口座(例えば口座A乃至口座D)のリスト160や、新たに口座を開設するための画面に移行するためのアイコン162を画面上に表示するよう、プログラムを構成することができる。プログラムの初期画面へ移行するためのアイコン164や、前画面へ移行するためのアイコン168などを表示するよう、プログラムを構成してもよい。
【0079】
ユーザがアイコン162を操作することでグループ口座を新規に開設するための画面(
図10(B))に移行し(S162)、第1のユーザは必要な情報を入力する。入力する情報は任意に設定することができる。例えば口座名称や口座機能の選択(S164、S166)、ユーザの選択(S168)、ユーザに対する権限の設定(S170)などが、
図9のフローに従って行われる。入力する順番は
図9に示した順番に限られず、任意に設定すればよい。
【0080】
新規口座開設画面(
図10(B))では、データのプラットフォームの提供者(ここでは銀行)からの注意事項を表示する領域170を表示することができる。同時に、第1のユーザが文字情報を入力するための領域を表示画面上に設けてもよい。例えば口座名や第1のユーザがグループ内のユーザへ周知すべき注意事項を入力するための領域172、174などを表示するよう、プログラムを構成することができる。また、アイコン176を操作することで次の画面へ移動するよう、プログラムが構成される。
【0081】
プラットフォームが機能別に多岐のタイプにわたる場合、
図9のフローS166従い、その機能を第1のユーザが選択できるよう、プログラムが構成される。プラットフォームが複数の階層別に分類されている場合には、
図11(A)、
図11(B)に示すように、階層別にタイプを選択できるようにプログラムを構成すればよい。例えば最初の機能選択画面(
図11(A))では、トランズアクションの承認権限に関する選択が行えるようにすることができる。選択肢としては、ユーザ全員の承認が必要な設定、一部のユーザに承認権限を付与する設定、あるいは口座開設者のみが承認権限を有する設定などが挙げられる。引き続く機能選択画面(
図11(B))では、使用する通貨の選択、口座の有効期間やその後の取り扱い方法などを選択できるようプログラムを構成してもよい。
【0082】
引き続く画面(
図12(A))では、口座に参加するユーザを選択できるよう、プログラムが構成される。この画面では、口座開設者を明示する領域180を表示するとともに、ユーザを追加するためのアイコン182が表示される。アイコン182を操作することで、第1の通信端末110_1内の記憶装置に格納された連絡先情報をリストするよう、プログラムを構成することができる。これにより、追加するユーザの氏名や連絡先を入力することなく、リストからユーザを選択するだけでユーザの追加を行うことができる。
【0083】
領域184は追加されたユーザをリストする領域である。アイコン186はユーザを削除するために使用することができ、例えば領域184にリストアップされたユーザを選択したときに初めて活性化されるよう、プログラムを構成することができる。
【0084】
引き続きアイコン176を操作し、権限の設定を行う画面(
図12(B))へ移行する。なおこの画面は、ユーザ全員に権限(承認権限など)を与える機能を選択している場合にはスキップするようプログラムを構成してもよい。
図12(B)に示すように、権限の設定はスライドボタン形式のアイコン190を用いて行うようにプログラムを構成することができる。図示していないが、この段階でトランズアクションの内容に応じて承認権限が可変できるよう、プログラムを構成してもよい。例えばグループ口座からの出金を伴うか否か、出金額がある一定の額を超えるか否か、振込先が特定の口座であるか否かなど、様々な形態に応じて承認権限を切り替えるための入力画面を提供してもよい。
【0085】
設定が終了した後には、入力内容を確認するため(S172)、
図13(A)に示すような確認画面へ移行する。ここでは、上述したフローにおいて第1のユーザが設定した内容を示す領域192、194などが表示される。また、これらの設定を変更するための画面へ移行するためのアイコン196などが配置される。設定を確認した後、アイコン198を操作することで設定が確定され、設定完了を表示する画面(
図13(B))へ移行するとともに、選択したユーザが保有する通信端末110へ案内通知が送信されるよう、プログラムが構成される(S174)。
【0086】
案内通知を受信したユーザ(ここでは、便宜上第2のユーザとする)の第2の通信端末110_2内に格納されるプログラムは、第2の通信端末110_2の表示画面上に
図14(A)、
図14(B)で示すような表示を行うよう、構成される。例えば口座名や、それに対する第1のユーザの入力内容を示す領域200、202、案内通知が送信されたユーザがリストされる領域204、参加・不参加を選択するためのアイコン206などが表示される。領域204には複数のタブが選択できるよう、プログラムを構成してもよい。例えば
図14(A)、
図14(B)に示すように、すでに参加したユーザ、まだ参加、不参加を決定していないユーザ、不参加を選択したユーザをリストアップするタブをそれぞれ選択できるよう、領域204が構成される。各ユーザは選択・非選択をアイコン206を操作して決定する。これにより、第2の通信端末110_2から第1の通信端末110_1へ応答信号が送信される(S176)。
【0087】
以上のプロセスにより、グループ口座が新規に開設される。なお、グループ口座が新規に開設されたという事実、およびグループ口座に関する情報も一つのトランズアクションと見做すことができる。したがって、このトランズアクション、トランズアクションを公開鍵暗号方式によって暗号化して得られる電子署名、および公開鍵112をブロックチェーンネットワーク130へブロードキャストしてもよい(S178)。これにより、このトランズアクションに係る情報が新たに生成されるブロック140に追加される。
【0088】
詳細は割愛するが、グループ口座に参加するユーザの追加や権限の変更も随時できるよう、プログラムを構成してもよい。また、プラットフォームの変更も可能なよう、プログラムを構成してもよい。例えば
図16の表示224に例示すように、開設した口座を新たな口座へ引き継ぐための選択肢を提供することで、口座の利用形態の変化に即座に対応することも可能であり、必要な都度、口座の開設、変更が可能である。
【0089】
グループ口座が開設された場合、プラットフォームの提供者は、グループ口座を特定するためのID情報(ID番号、アドレスなど)を発行し、通信端末110へ送信してもよい。ID情報は各通信端末110の記憶装置に格納され、データ処理プログラムはID情報を管理するよう構成することができる。
【0090】
[2.グループ口座への入金]
ユーザがグループ口座へ入金する場合のフローを
図15に示す。プログラムが起動されると(S180)、プログラムは、処理を行う口座を選択するための画面を表示する。この画面は、例えば
図10(A)に示すような画面でもよい。この画面においてユーザは、ユーザが参加する口座から処理する口座を選択し(S182)、該当する口座に対応する初期画面へ移行する。以下では、第1のユーザが第1の通信端末110_1を介してグループ口座である口座Dを選択し、この口座Dに仮想通貨としてコイン(図中、単位MC)を入金するプロセスを例として用いて説明する。
【0091】
例えば
図16に示すような画面が初期画面として表示されるようプログラムが構成される。この例では、初期画面は領域210、212、214を表示することができ、それぞれの領域において、選択した口座Dに係る情報、第1のユーザが現有するコイン残高、およびグループの他のユーザに関する情報を表示することができる。領域212には、第1のユーザが自己のウォレットから入金時に使用するウォレットを選択するためのプルダウンメニュー216やウォレット残高が表示されるよう、プログラムを構成してもよい。プログラムはさらに、領域212、あるいは他の領域に、コインを購入する画面に移行するためのアイコン218を表示するよう、通信端末110を制御してもよい。領域214では、他のユーザが過去に入金したコインの総額や承認権限などの情報を表示してもよい。
【0092】
第1のユーザが口座Dにコインを入れるためのアイコン222を表示するよう、プログラムが構成される。このアイコン222を操作することで、入金に必要な情報を入力するための画面へ移行する(
図17(A))。この画面では、第1のユーザのウォレットを選択するためのプルダウンメニュー230やその残高、入金するコインの額(入金額)を入力、表示するための領域232、処理を確定するためのアイコン234などを表示することができる。ウォレットの選択、入金額の入力を行い(S184)、その後アイコン234を第1のユーザが操作することで、処理内容を確認する画面(
図17(B))へ移行する。この画面では、データ100への処理内容、すなわち、第1のユーザが使用するウォレット、入金額、入金先などの情報が表示される(S186)。
【0093】
処理内容に変更が必要であれば、表示画面上に表示されるアイコン235が操作される。この操作に従ってプログラムは、入金の詳細を入力するための画面(
図17(A))を第1の通信端末110_1に再表示させる。処理内容の訂正が不要であることを
図17(B)に示す画面上で確認した後、第1のユーザは処理を確定するための操作を行う。この操作は、アイコンを操作することで行ってもよく、あるいは指紋などの生体情報を第1の通信端末110_1によって認識させることで行ってもよい。
図17(B)で示した例では、プログラムによって指紋を認証するための指紋認識領域236が画像として表示されるが、通信端末110_1に別途搭載される認識装置を用いて生体情報を収集し、確定操作に用いてもよい。
【0094】
図示していないが、承認条件を変更、選択するための画面を表示してもよい。あるいは処理内容に応じて承認条件が自動的に切り替わるよう、プログラムを構成してもよい。
【0095】
処理内容が確定されると、プログラムの命令に従い、処理内容がトランズアクションとして作成され、公開鍵方式を用いて暗号化されて電子署名が生成される。その後プログラムは、トランズアクションとその電子署名、および公開鍵112を含む承認要求信号を他のユーザの保有する通信端末110に送信することを第1の通信端末110_1に実行させる。
【0096】
入金において他のユーザの承認が必要な場合には、プログラムは、第1の通信端末110_1の表示画面上に、承認要求信号が送信されたことを示すための画面を表示させる(
図18(B))。承認を担うユーザが保有する通信端末110は、承認要求信号を受け取ると、通信端末110に搭載されるプログラムの命令に従い、その表示画面に
図19(A)で示すような、処理内容の詳細を示す領域242を表示する。処理内容を承認する場合には、指紋認識領域236などを用いて承認操作を行うことができる。図示していないが、承認しない場合には、非承認信号を送信するためのアイコンなどを表示してもよい。
【0097】
その後プログラムの命令に従い、承認を行うユーザの秘密鍵114を用いてトランズアクションを暗号化して生成される電子署名、第1のユーザの電子署名、およびトランズアクションを含む承認信号が生成される。この承認信号は承認を行ったユーザの通信端末110から他の通信端末110_1へ送信され(S192)、受信される(S194)。第1実施形態で述べた方法に従って承認条件が満たされたと判断された場合、第1の通信端末110_1はその情報を各通信端末110へ送信する(S188)。通信端末110内に格納されているプログラムは、それぞれの通信端末110の表示画面上に、処理内容が承認されたことを表示するための画面を表示する(
図19(B))。
【0098】
なお、特定の承認権限者が設定されている場合には、それ以外のユーザの通信端末110には公開鍵112を含めずに承認要求信号を送信するよう、プログラムを構成してもよい。この場合、承認権限を持たないユーザの通信端末110上においては、承認操作に必要なアイコンや指紋認識領域236などは不活性の状態が維持されるよう、プログラムを構成すればよい。これにより、承認権限を持たないユーザの通信端末110では承認操作は許容されないものの、第1のユーザが作成したトランズアクションの内容を表示することができる。
【0099】
承認条件が満たされなかった場合には、トランズアクションは破棄され(S196)、フローは終了する。
【0100】
入金において他のユーザの承認が不要である場合、処理内容の確認(S186)の終了とともに入金が実行される。この時、プログラムは他のユーザへ入金情報を送信するよう第1の通信端末110_1を制御する(S188)。例えば
図18(A)に示すように、他のユーザの通信端末110の画面上に、処理事実の表示238やその詳細を示す領域(例えば入金日時、入金者、入金額、入金先の口座名など)240が表示されるよう、プログラムが構成される。
【0101】
第1の通信端末110_1を介する入金という取引もデータ処理の一つである。したがって、この取引をトランズアクションとしてブロック140へ格納するために、このトランズアクションをブロックチェーンネットワーク130へブロードキャストするよう、プログラムを構成してもよい(S198)。ブロードキャストは、第1の通信端末110_1に格納されるプログラムの命令に従って行ってもよく、承認権限を有するユーザが保有する通信端末110で行うよう、プログラムを構成してもよい。
【0102】
[3.グループ口座からの入金]
グループ口座から他の口座へ入金する場合のフローを
図20に示す。プログラムが起動されると(S200)、プログラムは、処理を行う口座を選択するための画面を表示する。この画面は、例えば
図10(A)に示すような画面でもよい。この画面においてユーザは、ユーザが参加する口座から処理する口座を選択し(S202)、該当する口座に対応する初期画面へ移行する。以下では、第1のユーザが第1の通信端末110_1を介してグループ口座である口座Dを選択し、この口座Dから他の口座Zへコインを入金するプロセスを例として用いて説明する。
【0103】
グループ口座への入金時と同様、
図16に示す画面が表示されるよう、プログラムが構成される。プログラムは、第1のユーザがグループ口座から他の口座にコインを入れるためのアイコン220を表示するよう構成される。このアイコン220を操作することにより、入金に必要な情報を入力するための画面へ移行する(
図21(A))。
図21(A)に示すように、この画面では、前画面で選択された口座を示す領域250が表示されるとともに、口座残高、入金額を入力、表示するための領域252、入金先口座を選択するためのプルダウンメニュー254、処理を確定するためのアイコン256などを表示することができる。図示しないが、承認か非承認かを選択する期限を入力するための領域を設けてもよい。
【0104】
入金額の入力と入金先の選択を行い(S204)、その後アイコン256を第1のユーザが操作することで、処理内容を確認する画面(
図21(B))へ移行するよう、プログラムが構成される(S206)。なお、入金先の情報はID情報として第1の通信端末110_1の記憶装置内に格納されており、プログラムによって管理される。したがって、新たな入金先を追加する場合には、その口座のID情報をプラットフォーム提供者から取得して記憶装置に格納すればよい。処理内容を確認する画面(
図21(B))では、データ100への処理内容、すなわち、入金元の口座名、入金額、入金先などの情報が表示される。
【0105】
処理内容に変更が必要であれば、表示画面上に表示されるアイコン258が操作される。この操作に従ってプログラムは、入金の詳細を入力するための画面(
図21(A))を第1の通信端末110_1に再表示させる。処理内容の訂正が不要であることを
図21(B)に示す画面上で確認した後、第1のユーザは処理を確定するための操作を行う。この操作は、アイコンを操作することで行ってもよく、生体情報を利用して行ってもよい。グループ口座への入金処理と同様、この段階において承認条件を変更、選択するための画面を表示してもよい。あるいはグループ口座の開設時の設定に従い、処理内容(入金額や入金先など)に応じて承認条件が自動的に切り替わるよう、プログラムを構成してもよい。
【0106】
第1のユーザによる確定操作が終了するとプログラムは、第1乃至第3実施形態で述べたように、入金というデータ処理をトランズアクションと見做し、第1の通信端末110_1に記憶された秘密鍵114を用いて暗号化を行う。その後、トランズアクション、トランズアクションを暗号化して生成される電子署名、および公開鍵112を含む承認要求信号をユーザ全員、あるいは承認権限を有するユーザ、サーバ150、あるいはブロックチェーンネットワーク130へ送信する(S208)。特定のユーザのみに承認権限を与える場合には、そのユーザのみに公開鍵112を送信し、他のユーザに対しては暗号化する前のトランズアクションのみを送信するよう、プログラムを構成してもよい。承認要求信号が送信されると、プログラムの命令に従い、第1の通信端末110_1の表示画面上には、承認要求信号が送信されたことを示すための画面が表示される(
図22(A))。
【0107】
承認を担うユーザが保有する通信端末110が承認要求信号を受け取ると、プログラムの命令に従い、通信端末110は電子署名の復号化を行い、生成されるトランズアクションとオリジナルのトランズアクションとの照合を行う。照合結果によってトランズアクションが検証されると、通信端末110の表示画面には
図22(B)で示すように、処理内容の詳細を示す領域260が表示される。処理内容を承認する場合には、前述した指紋認識領域236、あるいは
図22(B)に示すようなアイコン262などを用いて承認操作を行うことができる。
【0108】
その後プログラムの命令に従い、承認を行ったユーザの通信端末110では、トランズアクション、承認を行うユーザの通信端末110で生成される秘密鍵114を用いて生成される電子署名、および第1の通信端末110_1から送信される電子署名を含む承認信号が生成される。この信号は、第1の通信端末110_1へ送信され(S210)、第1の通信端末110_1によって受信される(S212)。第1、第2実施形態で述べた方法によって承認条件が満たされたと判断された場合、各通信端末110内に格納されているプログラムは、それぞれの通信端末110の表示画面上に、処理内容が承認されたことを表示するための画面を表示する(
図23)。
【0109】
こののち、入金というデータ処理をトランズアクションとしてブロック140へ格納するために、このトランズアクションをブロックチェーンネットワーク130へブロードキャストするよう、プログラムが構成される(S214)。ブロードキャストは、第1の通信端末110_1に格納されるプログラムの命令に従って行ってもよく、承認権限を有するユーザが保有する通信端末110で行うよう、プログラムを構成してもよい。なお、承認条件が満たされない場合、トランズアクションは破棄され(S216)、フローは終了する。
【0110】
詳細は割愛するが、上述したフローは、コインと法定通貨間の換金処理、他の口座からのコインの入金処理などにも応用可能である。
【0111】
上述したように、本発明の実施形態に係るデータ処理方法、データ処理プログラムを活用することにより、グループ口座のような複数のユーザによって共有、管理されるデータのプラットフォームを容易に取得、利用することができる。また、プラットフォームの利用には特別の権限や時期的な制約はなく、通信端末にデータ処理プログラムを搭載することで、何時でも誰でも取得して利用することができる。また、プラットフォームに参加するユーザや承認権限を容易に設定することができ、参加するユーザは時期的制約を受けることなく、プラットフォーム上のデータ(例えば入出金履歴や残高)を閲覧することができる。したがって、ユーザが金融機関に行く労力と時間の浪費を防ぐことができるだけでなく、プラットフォーム提供者のヒューマンリソースも有効活用することが可能となる。
【0112】
さらに、プラットフォーム上のデータ自体には暗号化処理やパスワードによる保護は不要であり、このため参加ユーザは特別の権限を要求されることなく、データとその更新履歴などを閲覧することができる。また、データに対する処理はブロックチェーンに格納されていることから、高いレベルでデータの健全性を維持することが可能である。このように、本発明の実施形態により、ユーザ利便性に優れ、かつ、安全にデータを管理、利用することができる。
【0113】
上述した実施形態を基にして、当業者が適宜構成要素やプロセスの追加、削除もしくは設計変更を行ったものも、本発明の要旨を備えている限り、本発明の範囲に含まれる。
【解決手段】信号処理方法は、複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を複数のノードの少なくとも一つに送信する手順と、承認要求信号を受信した複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順と、受信した承認信号の承認に基づき、トランザクションを実行する手順を含む。