知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-07-17
(45)【発行日】2024-07-25
(54)【発明の名称】情報処理システム
(51)【国際特許分類】
G06F 16/182 20190101AFI20240718BHJP
G06Q 20/38 20120101ALI20240718BHJP
H04L 9/32 20060101ALI20240718BHJP
G06F 16/23 20190101ALI20240718BHJP
【ＦＩ】
G06F16/182
G06Q20/38 310
H04L9/32 200Z
G06F16/23
【請求項の数】
5
(21)【出願番号】P 2023535068
(86)(22)【出願日】2022-10-28
(86)【国際出願番号】 JP2022040532
(87)【国際公開番号】W WO2023074878
(87)【国際公開日】2023-05-04
【審査請求日】2023-06-08
(31)【優先権主張番号】P 2021176068
(32)【優先日】2021-10-28
(33)【優先権主張国・地域又は機関】JP
【早期審査対象出願】
(73)【特許権者】
【識別番号】518307846
【氏名又は名称】株式会社ナンバーワンソリューションズ
(74)【代理人】
【識別番号】100126000
【弁理士】
【氏名又は名称】岩池 満
(74)【代理人】
【識別番号】100154748
【弁理士】
【氏名又は名称】菅沼 和弘
(72)【発明者】
【氏名】面来 哲雄
(72)【発明者】
【氏名】高橋 直太
【審査官】原 秀人
(56)【参考文献】
【文献】特開２０１５－１６２１４６（ＪＰ，Ａ）
【文献】特開２０２０－１９０８７４（ＪＰ，Ａ）
【文献】国際公開第２０１９／２４４９４９（ＷＯ，Ａ１）
【文献】山崎 重一郎 外，ブロックチェーン技術概論 理論と実践 ，第1刷，日本，株式会社講談社，2021年06月25日，pp. 221-224
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １６／００－１６／９５８
Ｇ０６Ｑ ２０／３８
Ｈ０４Ｌ ９／３２
(57)【特許請求の範囲】
【請求項1】
所定サービス内の複数のユーザのうち所定ユーザについての最大Ｎ個（Ｎは１以上の整数値）のトランザクションの履歴を含むファイルを、当該所定ユーザの単位ファイルとし前記複数のユーザ毎に夫々生成又は更新する単位ファイル生成手段と、前記所定ユーザが関わった１つのトランザクションの内容を含むファイナリトランザクションファイルをトランザクション実行毎に生成するファイナリトランザクションファイル生成手段と、
前記所定ユーザの前記単位ファイルを他ユーザの前記単位ファイルとは独立して記憶させて管理する制御を、前記所定サービス内の前記複数のユーザ毎に実行すると共に、前記所定ユーザの前記単位ファイルとは別に、前記ファイナリトランザクションファイルをトランザクション毎に管理する制御を実行する管理制御手段と、
を備え、
前記単位ファイル生成手段は、
所定単位についてＮ＋１個目のトランザクションが実行された場合、当該所定単位の新たな前記単位ファイルを作成し、
前記管理制御手段は、
作成された前記所定単位の前記新たな単位ファイルを、前記所定単位の前記単位ファイルと対応付けて記憶させて管理させる制御を実行し、
さらに、前記管理制御手段は、
前記単位ファイルをブロックとして、複数の前記単位ファイルをブロックチェーンとして記憶させて管理させる制御を実行する、
情報処理システム。
【請求項2】
前記単位ファイル生成手段は、前記所定単位に関する所定事項が暗号化された暗号化所定事項をさらに含む、前記所定単位の前記単位ファイルを生成する、
請求項１に記載の情報処理システム。
【請求項3】
前記所定事項が第１鍵で暗号化された第１暗号化所定事項を取得し、当該第１暗号化所定事項を、第２鍵で暗号化して、第２暗号化所定事項を生成する暗号化手段をさらに備え、前記単位ファイル生成手段は、前記第２暗号化所定事項をさらに含む、前記所定単位の前記単位ファイルを生成して、前記管理制御手段は、当該所定単位の当該単位ファイルを記憶させると共に、前記第１鍵を外部に記憶させ、かつ、前記第２鍵を内部に記憶させる制御を実行する、
請求項２に記載の情報処理システム。
【請求項4】
情報処理装置が実行する情報処理方法において、所定サービス内の複数のユーザのうち所定ユーザについての最大Ｎ個（Ｎは１以上の整数値）のトランザクションの履歴を含むファイルを、当該所定ユーザの単位ファイルとし前記複数のユーザ毎に夫々生成又は更新する単位ファイル生成ステップと、
前記所定ユーザが関わった１つのトランザクションの内容を含むファイナリトランザクションファイルをトランザクション実行毎に生成するファイナリトランザクションファイル生成ステップと、
前記所定ユーザの前記単位ファイルを他ユーザの前記単位ファイルとは独立して記憶させて管理する制御を、前記所定サービス内の前記複数のユーザ毎に実行すると共に、前記所定ユーザの前記単位ファイルとは別に、前記ファイナリトランザクションファイルをトランザクション毎に管理する制御を実行する管理制御ステップと、
を含み、
前記単位ファイル生成ステップとして、
所定単位についてＮ＋１個目のトランザクションが実行された場合、当該所定単位の新たな前記単位ファイルを作成し、
前記管理制御ステップとして、
作成された前記所定単位の前記新たな単位ファイルを、前記所定単位の前記単位ファイルと対応付けて記憶させて管理させる制御を実行し、
さらに、前記管理制御ステップとして、
前記単位ファイルをブロックとして、複数の前記単位ファイルをブロックチェーンとして記憶させて管理させる制御を実行する、
情報処理方法。
【請求項5】
コンピュータに、所定サービス内の複数のユーザのうち所定ユーザについての最大Ｎ個（Ｎは１以上の整数値）のトランザクションの履歴を含むファイルを、当該所定ユーザの単位ファイルとし前記複数のユーザ毎に夫々生成又は更新する単位ファイル生成ステップと、
前記所定ユーザが関わった１つのトランザクションの内容を含むファイナリトランザクションファイルをトランザクション実行毎に生成するファイナリトランザクションファイル生成ステップと、
前記所定ユーザの前記単位ファイルを他ユーザの前記単位ファイルとは独立して記憶させて管理する制御を、前記所定サービス内の前記複数のユーザ毎に実行すると共に、前記所定ユーザの前記単位ファイルとは別に、前記ファイナリトランザクションファイルをトランザクション毎に管理する制御を実行する管理制御ステップと、
を含む制御処理を実行させ、
前記単位ファイル生成ステップとして、
所定単位についてＮ＋１個目のトランザクションが実行された場合、当該所定単位の新たな前記単位ファイルを作成する制御処理を実行させ、
前記管理制御ステップとして、
作成された前記所定単位の前記新たな単位ファイルを、前記所定単位の前記単位ファイルと対応付けて記憶させて管理させる制御を実行し、
さらに、前記管理制御ステップとして、
前記単位ファイルをブロックとして、複数の前記単位ファイルをブロックチェーンとして記憶させて管理させる制御処理を実行させる、
プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理システムに関する。
【背景技術】
【0002】
従来より、ブロックチェーンや分散型台帳を用いて、仮想通貨等の権利の変動のトランザクションを管理する技術が存在する（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１８－０５５２０３号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上述の特許文献１を含む従来技術のブロックチェーンや分散型台帳には、スケーラビリティ問題、ファイナリティ問題、確定後の削除の問題等が存在していた。
即ち、スケーラビリティ問題として、トランザクションの量の拡張性が低かった。具体的には例えば、トランザクションの量が増加すると、トランザクションの承認に時間がかかったり、システム全体としての電力消費が激しくなるという問題があった。
また、ファイナリティ問題として、分散処理されたブロックのうちいずれのブロックを正とするかが定まりづらく、取引のファイナリティの判断が困難であった。
また、多くのノードによりトランザクションやそのトランザクションを含むブロックが承認された場合、そのトランザクションやブロックは、いわば確定された状態となり、削除（取消）等はできない性質のものであった。
即ち、スケーラビリティ問題として、トランザクションの量の拡張性が低かった。具体的には例えば、トランザクションの量が増加すると、トランザクションの承認に時間がかかったり、システム全体としての電力消費が激しくなるという問題があった。
また、ファイナリティ問題として、分散処理されたブロックのうちいずれのブロックを正とするかが定まりづらく、取引のファイナリティの判断が困難であった。
また、多くのノードによりトランザクションやそのトランザクションを含むブロックが承認された場合、そのトランザクションやブロックは、いわば確定された状態となり、削除（取消）等はできない性質のものであった。
【0005】
また、仮想通貨等の権利のみならず、世の中の各種各様なデータ（例えば、個人情報や医療の生データ）についても、改ざん等をされないよう、ブロックチェーンや分散型台帳を用いて管理したいという要望があった。
このように、従来のブロックチェーンや分散型台帳を用いた情報の管理の利便性の向上がもとめられていた。
このように、従来のブロックチェーンや分散型台帳を用いた情報の管理の利便性の向上がもとめられていた。
【0006】
本発明は、ブロックチェーンや分散型台帳を用いた情報の管理の利便性を向上させることを目的とする。
【課題を解決するための手段】
【0007】
上記目的を達成するため、本発明の一態様の情報処理システムは、
所定サービス内の複数の単位のうち所定単位に関わるトランザクションの履歴を含む単位ファイルを生成又は更新する単位ファイル生成手段と、
前記単位ファイルを他の単位とは独立して記憶させて管理する制御を、前記所定サービス内の前記複数の単位毎に実行する管理制御手段と、
を備える。
所定サービス内の複数の単位のうち所定単位に関わるトランザクションの履歴を含む単位ファイルを生成又は更新する単位ファイル生成手段と、
前記単位ファイルを他の単位とは独立して記憶させて管理する制御を、前記所定サービス内の前記複数の単位毎に実行する管理制御手段と、
を備える。
【発明の効果】
【0008】
本発明によれば、ブロックチェーンや分散型台帳を用いた情報の管理の利便性を向上させることができる。
【図面の簡単な説明】
【0009】
【図1】本発明の一実施形態に係るサービス提供サーバ群が適用される情報処理システムにより実現可能となる本第１サービスの概要を示す図である。
【図10】個人情報や医療に関する生データを管理する本第２サービスの概要を示す図である。
【発明を実施するための形態】
【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】
”ｆｒｏｍ＿ｈａｓｈ”は、送金元のパーソナルブロックチェーンＰＢを特定する識別子（ハッシュ値）である。また、”ｔｏ＿ｈａｓｈ”は、送金先のパーソナルブロックチェーンＰＢを特定する識別子（ハッシュ値）である。
”ｔｒａｎｓａｃｔｉｏｎ＿ｎｕｍ”は、ｕｓｅｒ＿ｃｏｄｅがトランザクションを実行した回数である。
”ｔｏｔａｌ＿ｔｒａｎｓａｃｔｉｏｎ＿ｎｕｍ”は、管理者のトランザクションを実行した回数である。
ユーザの復号鍵は、ファイルサーバにアップロードされる。
システム側の秘密鍵は、暗号化された暗号カギと複合鍵を作り、非公開領域で管理される。
また、ブロック最大保持は１年とすることができる。保持期限を過ぎたブロックは、バッチでＰＩＮ止めが解除され削除される。
”ｔｒａｎｓａｃｔｉｏｎ＿ｎｕｍ”は、ｕｓｅｒ＿ｃｏｄｅがトランザクションを実行した回数である。
”ｔｏｔａｌ＿ｔｒａｎｓａｃｔｉｏｎ＿ｎｕｍ”は、管理者のトランザクションを実行した回数である。
ユーザの復号鍵は、ファイルサーバにアップロードされる。
システム側の秘密鍵は、暗号化された暗号カギと複合鍵を作り、非公開領域で管理される。
また、ブロック最大保持は１年とすることができる。保持期限を過ぎたブロックは、バッチでＰＩＮ止めが解除され削除される。
【0050】
ここで、完全暗号化を実施してｂａｌａｎｃｅが暗号化されたものが、暗号化された残高ＥＮＣとして記録がなされる。
”ｂａｌａｎｃｅ（ｅｎｃ１）”とは、その口座の持ち主たるユーザＵが保有する暗号化鍵を用いて暗号化した残高の情報（文字列）である。
”ｂａｌａｎｃｅ（ｅｎｃ２）”とは、”ｂａｌａｎｃｅ（ｅｎｃ１）”を、管理者Ｇが保有する暗号化鍵を用いて暗号化した残高の情報（文字列）である。このように、多重暗号化された文字列（暗号文）が記録される。
これにより、”ｂａｌａｎｃｅ（ｅｎｃ２）”は、承認ノードで承認されたブロックデータであることが保証される。
”ｂａｌａｎｃｅ（ｅｎｃ１）”とは、その口座の持ち主たるユーザＵが保有する暗号化鍵を用いて暗号化した残高の情報（文字列）である。
”ｂａｌａｎｃｅ（ｅｎｃ２）”とは、”ｂａｌａｎｃｅ（ｅｎｃ１）”を、管理者Ｇが保有する暗号化鍵を用いて暗号化した残高の情報（文字列）である。このように、多重暗号化された文字列（暗号文）が記録される。
これにより、”ｂａｌａｎｃｅ（ｅｎｃ２）”は、承認ノードで承認されたブロックデータであることが保証される。
【0051】
【0052】
ステップＳ１において、ユーザ端末４－Ｆは、サービス提供サーバ群１に送金リクエストを送信する。
【0053】
ステップＳ２において、サービス提供サーバ群１は、ファイルサーバ群２に対して送金元台帳ＰＢ－Ｆ－ｆ（ｆは、パーソナルブロックチェーンＰＢ－Ｆの更新回数に対応する１以上の整数値）を要求する。
ステップＳ３において、ファイルサーバ群２は、送金元台帳ＰＢ－Ｆ－ｆを返送する。
ステップＳ３において、ファイルサーバ群２は、送金元台帳ＰＢ－Ｆ－ｆを返送する。
【0054】
ステップＳ４において、サービス提供サーバ群１は、送金元台帳ＰＢ－Ｆ－ｆの残高等を確認する。送金リクエストを実行してよいと判定された場合、ステップＳ５の処理にすすむ。
【0055】
ステップＳ５において、サービス提供サーバ群１は、ファイルサーバ群２に対して送金先台帳ＰＢ－Ｔ－ｔ（ｔは、パーソナルブロックチェーンＰＢ－Ｔの更新回数に対応する１以上の整数値）を要求する。
ステップＳ６において、ファイルサーバ群２は、送金先台帳ＰＢ－Ｔ－ｔを返送する。
ステップＳ６において、ファイルサーバ群２は、送金先台帳ＰＢ－Ｔ－ｔを返送する。
【0056】
ステップＳ７において、サービス提供サーバ群１は、送金元台帳ＰＢ－Ｆ－（ｆ＋１）及び送金先台帳ＰＢ－Ｔ－（ｔ＋１）を作成（生成又は更新）する。
ステップＳ８において、サービス提供サーバ群１は、ファイルサーバ群２に対して送金元台帳ＰＢ－Ｆ－（ｆ＋１）及び送金先台帳ＰＢ－Ｔ－（ｔ＋１）を登録する。
ステップＳ８において、サービス提供サーバ群１は、ファイルサーバ群２に対して送金元台帳ＰＢ－Ｆ－（ｆ＋１）及び送金先台帳ＰＢ－Ｔ－（ｔ＋１）を登録する。
【0057】
ステップＳ９において、ファイルサーバ群２は、Ｐ２Ｐで各ノードにファイルを記憶させる。
ステップＳ１０において、サービス提供サーバ群１は、ユーザ端末４－Ｆに最新の送金元台帳ＰＢ－Ｆ－（ｆ＋１）のハッシュ値を送信する。
ステップＳ１１において、サービス提供サーバ群１は、ユーザ端末４－Ｔに最新の送金先台帳ＰＢ－Ｔ－（ｔ＋１）のハッシュ値を送信する。
これにより、ユーザ端末４－Ｆやユーザ端末４－Ｔは、自身のパーソナルブロックチェーンの情報をファイルサーバ群２から取得したり、確認することが可能となる。
このように、送金リクエストが実行される。
ステップＳ１０において、サービス提供サーバ群１は、ユーザ端末４－Ｆに最新の送金元台帳ＰＢ－Ｆ－（ｆ＋１）のハッシュ値を送信する。
ステップＳ１１において、サービス提供サーバ群１は、ユーザ端末４－Ｔに最新の送金先台帳ＰＢ－Ｔ－（ｔ＋１）のハッシュ値を送信する。
これにより、ユーザ端末４－Ｆやユーザ端末４－Ｔは、自身のパーソナルブロックチェーンの情報をファイルサーバ群２から取得したり、確認することが可能となる。
このように、送金リクエストが実行される。
【0058】
以上、図１乃至図６を用いて、本第１サービスにおける各種リクエスト（トランザクション）の処理について説明した。以下、本第１サービスを提供するための情報処理システムの構成などについて図７乃至図９を用いて説明する。
【0059】
図７は、図１乃至図６の本発明の一実施形態に係るサービス提供サーバ群が適用される情報処理システムの構成例を示す図である。
図７に示す情報処理システムは、サービス提供サーバ群１と、ファイルサーバ群２と、管理者端末３と、Ｍ（Ｍは１以上の整数値）のユーザ端末４－１乃至４－Ｍとが、インターネットＮＷ等の所定のネットワークを介して相互に接続されることで構成される。
図７に示す情報処理システムは、サービス提供サーバ群１と、ファイルサーバ群２と、管理者端末３と、Ｍ（Ｍは１以上の整数値）のユーザ端末４－１乃至４－Ｍとが、インターネットＮＷ等の所定のネットワークを介して相互に接続されることで構成される。
【0060】
上述したように、サービス提供サーバ群１は、本第１サービスにおけるトランザクションの要望（例えば、送金のリクエストや口座開設のリクエスト）に基づいて、後述する各種ファイルを生成又は更新することで、本第１サービスの提供を行う情報処理システムである。
図１の説明において、サービス提供サーバ群１は、複数のサーバ（例えば、プロキシサーバと、真贋サーバと、認証サーバと、鍵ＤＢ）を含んで構成されているものとしたが、特にこれに限定されない。即ち例えば、サービス提供サーバ群１は、１つの情報処理装置により構成されていてもよい。また例えば、サービス提供サーバ群１を構成する複数のサーバの一部又は全部は、１つの情報処理装置上でエミュレートされた仮想的なサーバとして実装されていてもよい。
図１の説明において、サービス提供サーバ群１は、複数のサーバ（例えば、プロキシサーバと、真贋サーバと、認証サーバと、鍵ＤＢ）を含んで構成されているものとしたが、特にこれに限定されない。即ち例えば、サービス提供サーバ群１は、１つの情報処理装置により構成されていてもよい。また例えば、サービス提供サーバ群１を構成する複数のサーバの一部又は全部は、１つの情報処理装置上でエミュレートされた仮想的なサーバとして実装されていてもよい。
【0061】
また、上述したように、ファイルサーバ群２は、本第１サービスにおける各種ファイルを記憶して管理する複数のサーバ（ノード）からなる情報処理システムである。
なお、ファイルサーバ群２も、サービス提供サーバ群１と同様に、１つの情報処理装置により構成されていてもよい。
以下、図７乃至図９の説明においては、サービス提供サーバ群１及びファイルサーバ群２は、夫々１つの情報処理装置により実現されているものとして説明する。
なお、ファイルサーバ群２も、サービス提供サーバ群１と同様に、１つの情報処理装置により構成されていてもよい。
以下、図７乃至図９の説明においては、サービス提供サーバ群１及びファイルサーバ群２は、夫々１つの情報処理装置により実現されているものとして説明する。
【0062】
管理者端末３は、管理者Ｇにより利用される情報処理装置である。管理者Ｇは、管理者端末３を介してユーザＵの口座開設などのリクエストをする。
【0063】
ユーザ端末４－１乃至４－Ｍは、本第１サービスのユーザＵ－１乃至Ｕ－Ｍの夫々により利用される情報処理装置である。以下、ユーザ端末４－１乃至４－Ｍを個々に区別する必要がない場合、これらをまとめて「ユーザ端末４」と呼ぶ。
【0064】
【0065】
サービス提供サーバ群１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、入力部１６と、出力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。
【0066】
ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。
【0067】
ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、入力部１６、出力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。
【0068】
入力部１６は、各種ハードウェア鉛等で構成され、各種情報を入力する。
出力部１７は、各種液晶ディスプレイ等で構成され、各種情報を出力する。
記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークを介して他の装置との間で行う通信を制御する。
出力部１７は、各種液晶ディスプレイ等で構成され、各種情報を出力する。
記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークを介して他の装置との間で行う通信を制御する。
【0069】
ドライブ２０は、必要に応じて設けられる。ドライブ２０には磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３１が適宜装着される。ドライブ２０によってリムーバブルメディア３１から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。またリムーバブルメディア３１は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。
【0070】
なお、図示はしないが、ファイルサーバ群２、管理者端末３、ユーザ端末４も図８に示すハードウェア構成を有している。
【0071】
図９は、図８のサービス提供サーバ群の機能的構成の概要を示す機能ブロック図である。
図９に示すように、サービス提供サーバ群１においては、パーソナルブロックチェーン生成部５１と、ファイナリティトランザクションファイル生成部５２と、管理制御部５３と、リクエスト処理部５４とが機能する。
ファイルサーバ群２には、パーソナルブロックチェーン記憶部６１と、ファイナリティトランザクションファイル記憶部６２とが設けられている。
図９に示すように、サービス提供サーバ群１においては、パーソナルブロックチェーン生成部５１と、ファイナリティトランザクションファイル生成部５２と、管理制御部５３と、リクエスト処理部５４とが機能する。
ファイルサーバ群２には、パーソナルブロックチェーン記憶部６１と、ファイナリティトランザクションファイル記憶部６２とが設けられている。
【0072】
パーソナルブロックチェーン生成部５１は、サービス内の複数の口座のうち所定口座に関わるトランザクションの履歴を含むパーソナルブロックチェーンを生成又は更新する。
【0073】
ファイナリティトランザクションファイル生成部５２は、所定口座が関わるトランザクションが終了したとき、当該トランザクションの内容を含むファイルを生成する。
【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】
１・・・サービス提供サーバ群、２・・・ファイルサーバ群、３・・・管理者端末、４・・・ユーザ端末、５１・・・パーソナルブロックチェーン生成部、５２・・・ファイナリティトランザクションファイル生成部、５３・・・管理制御部、５４・・・リクエスト処理部、６１・・・パーソナルブロックチェーン記憶部、６２・・・ファイナリティトランザクションファイル記憶部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】