特許 7568087 情報流通装置、情報流通方法、及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-10-07

(45)【発行日】2024-10-16

(54)【発明の名称】情報流通装置、情報流通方法、及びプログラム

(51)【国際特許分類】

   G06Q 10/10 20230101AFI20241008BHJP

【ＦＩ】

G06Q10/10

【請求項の数】 7

(21)【出願番号】P 2023526689

(86)(22)【出願日】2021-06-08

(86)【国際出願番号】 JP2021021783

(87)【国際公開番号】W WO2022259377

(87)【国際公開日】2022-12-15

【審査請求日】2023-11-29

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】張 一凡

【審査官】樋口 龍弥

(56)【参考文献】

【文献】国際公開第２０２０／２０４００４（ＷＯ，Ａ１）

【文献】特開２０１９－１５３２６０（ＪＰ，Ａ）

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

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

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

【請求項1】

提供対象のデータと、ローカルチェーンを保持する記憶部と、
前記ローカルチェーンに前記データの提供条件を登録するとともに、前記データに関する情報を外部システムに登録する登録部と、
情報利用者からのデータ要求に含まれる利用内容と前記提供条件とに基づいて、前記データの提供が可能であると判断された場合において、前記データを前記情報利用者に送信するとともに、送信開始と送信完了を前記ローカルチェーンに記録するデータ送信部と、を備え、
前記登録部は、前記ローカルチェーンのコピーを、外部に備えられるストレージに格納し、公開させる
情報流通装置。

【請求項2】

ローカルチェーンを保持する記憶部と、
情報提供者から受信したデータのメタ情報に基づいて、前記データの利用が可能であると判断された場合において、前記データを情報提供者から受信するとともに、受信開始と受信完了を前記ローカルチェーンに記録するデータ受信部と、
前記データに対する対価の支払いを前記情報提供者に対して実行する支払い処理部と
を備える情報流通装置であって、
前記情報流通装置は、前記情報提供者の端末に保持されるローカルチェーンのコピーが格納されるストレージにアクセスすることで、前記情報提供者のローカルチェーンを参照する
情報流通装置。

【請求項3】

秘密計算を用いてスマートコントラクトを実行するスマートコントラクト処理部
を備える請求項１又は２に記載の情報流通装置。

【請求項4】

前記ローカルチェーンにおいて、トランザクションの発行と受信のいずれも存在しない期間をダウンタイムとして管理するダウンタイム管理部
を備える請求項１ないし３のうちいずれか１項に記載の情報流通装置。

【請求項5】

キープアライブとして補助承認トランザクションを発行するトランザクション処理部
を備える請求項１ないし４のうちいずれか１項に記載の情報流通装置。

【請求項6】

情報利用者端末と情報提供者端末による情報流通方法であって、
前記情報提供者端末は、提供対象のデータと、自身のローカルチェーンを保持しており、前記ローカルチェーンに前記データの提供条件を登録するとともに、前記データに関する情報を外部システムに登録し、
前記情報利用者端末からのデータ要求に含まれる利用内容と前記提供条件とに基づいて、前記データの提供が可能であると判断された場合において、前記情報提供者端末は、前記データを前記情報利用者端末に送信するとともに、送信開始と送信完了を前記ローカルチェーンに記録し、
前記情報利用者端末は、前記データを前記情報提供者端末から受信するとともに、受信開始と受信完了を自身のローカルチェーンに記録し、前記データに対する対価の支払いを実行する情報流通方法であり、
前記情報提供者端末は、前記情報提供者端末が保持するローカルチェーンのコピーを、外部に備えられるストレージに格納し、公開させ、
前記情報利用者端末は、前記情報提供者端末に保持されるローカルチェーンのコピーが格納されるストレージにアクセスすることで、前記情報提供者端末のローカルチェーンを参照する
情報流通方法。

【請求項7】

コンピュータを、請求項１ないし５のうちいずれか１項に記載の情報流通装置における各部として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報流通のためのプラットフォームを実現するための技術に関連するものである。

【背景技術】

【0002】

既存の情報流通の仕組みとして、サーバクライアント型でサーバにより情報流通を制御・追跡する技術が広く使われている。しかし、サーバによる制御では、下記のような課題がある。

【0003】

・サーバがデータに対するアクセス権を管理するため、サーバを完全に信頼する必要がある。

【0004】

・データ流通に対する対価と取り扱いもサーバ依存になる。

【0005】

上記のような課題があるため、データ流通においてはプラットフォームを信頼しなくてもデータを流通できる仕組みが望ましいと考えられる。

【0006】

このような仕組みとして、暗号通貨の流通を国などの組織に一極集中させずに行う分散台帳があげられる。分散台帳では非集中（特定組織に依存せず）に流通のコンセンサス形成とそのログ（トランザクション）保管手法が実用されている。

【0007】

ここで、分散台帳の変遷と課題について説明する。

【0008】

（１）２０１０～第１、第２世代
分散台帳として知名度の高いブロックチェーンでは、チェーン構造にトランザクション情報を固めたブロックをつないでいくことで過去の合意内容への改ざん耐性を実現し、分散コンセンサスにより信頼できる第三者を設けずに最終状態の合意生成を行う。

【0009】

しかし、この手法では分散環境でのデータ保管、分散コンセンサスにかかる運用コスト（マイニング対価）は高価であり、性能も制限される副作用があった。

【0010】

（２）２０１８～第３世代
第１、第２世代の課題を解決するために、有向非巡回グラフ（ＤＡＧ）を用いた新たな手法が登場した（例えば非特許文献１）。ＤＡＧではブロックの生成にかかるコストをブロックに記載されるコンセンサス形成者が代行することで、サービスコストを低減できる。コンセンサス形成者がバラバラにデータを投入してもＤＡＧが成立するので性能の制限も同時に回避できるようになった。

【0011】

しかし、データの保管については依然ｆｕｌｌ－Ｎｏｄｅと呼ばれるノードで全ＤＡＧ情報の分散保管を行い、管理コストがかかるものや、暗号通貨の送金に特化したものなどが主となっており、多量のトランザクションが発行される情報流通利用には運用費などの面で課題が残されている。

【先行技術文献】

【非特許文献】

【0012】

【文献】Colin LeMahieu, " Nano: A Feeless Distributed Cryptocurrency Network"

【発明の概要】

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

【0013】

上記のとおり、分散台帳技術を利用することで、非集中な制御が可能であるが、従来技術では情報流通への利用は難しかった。

【0014】

本発明は上記の点に鑑みてなされたものであり、分散台帳技術を利用して、適切に情報流通を行うことを可能とする技術を提供することを目的とする。

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

【0015】

開示の技術によれば、提供対象のデータと、ローカルチェーンを保持する記憶部と、
前記ローカルチェーンに前記データの提供条件を登録するとともに、前記データに関する情報を外部システムに登録する登録部と、
情報利用者からのデータ要求に含まれる利用内容と前記提供条件とに基づいて、前記データの提供が可能であると判断された場合において、前記データを前記情報利用者に送信するとともに、送信開始と送信完了を前記ローカルチェーンに記録するデータ送信部と、を備え、
前記登録部は、前記ローカルチェーンのコピーを、外部に備えられるストレージに格納し、公開させる
情報流通装置が提供される。

【発明の効果】

【0016】

開示の技術によれば、分散台帳技術を利用して、適切に情報流通を行うことを可能とする技術が提供される。

【図面の簡単な説明】

【0017】

【図1】本実施の形態に係るシステムの全体構成例を示す図である。

【図2】データフローのシーケンス図である。

【図3】デバイスダウンタイムを想定した動作を説明するための図である。

【図4】スマートコントラクトの実行環境を説明するための図である。

【図5】ローカルチェーンの例を示す図である。

【図6】端末の機能構成例を示す図である。

【図7】装置のハードウェア構成例を示す図である。

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

【0018】

以下、図面を参照して、分散台帳技術を情報流通プラットフォームの実現を目指す本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

【0019】

（実施の形態の概要）
まず、本実施の形態の概要を説明する。本実施の形態では、トランザクションの発行者が関連トランザクションを保管し、コンセンサス処理に参加することで、トランザクション発行に伴うコストを削減し、データ流通における送信、受信、利用の関係を管理する。これにより、情報の流通管理を最適化する。

【0020】

その際に、トランザクションの共有・管理手法としてスマートホンなどの常時接続されることが期待される汎用ユーザ端末をベースとして用いることで、可用性を確保しつつ、トランザクション数の制御を可能にし、攻撃者による偽装トランザクションの影響を減らすことを可能としている。

【0021】

また、利用者が継続的にデータ・トランザクションの管理リソースを提供することを可能にするために、システムの負荷低減やスマートホンなどの不安定なデバイスによるリソース提供手法についても提案している。

【0022】

本実施の形態におけるキーポイントとして、例えば、下記の点も挙げられる。

【0023】

・データの価値に利用可能性（可用性）を考慮する金額体系を用いる。

【0024】

・既存のマイニングの代わりに端末間での相互可用性監視（補助承認トランザクション発行）を実施することで台帳の改ざんに対する安全性を担保する。

【0025】

・データを流通させたい端末は自身のデータ価値を高めるために相互可用性監視を実施する。

【0026】

・各端末での相互可用性監視とローカルデータ保管を行うため、マイニング、スマートコントラクトコストに相当するトランザクションフィーは不要である。

【0027】

＜実施の形態の効果＞
本実施の形態に係る技術により、分散台帳技術を利用した情報流通プラットフォームを実現することができる。すなわち、安全に情報を流通・売買でき、その対価の確認・保証・追跡を行うことのできる運用コストの低いプラットフォームを実現できる。

【0028】

より具体的には、上述した特徴により、スマートホンなどの汎用ユーザ端末で演算・ストレージのリソースを提供するので、無料で安全なトランザクション管理システムを実現可能にし、公開・検証可能でありながら改ざん不可なログ管理が可能となる。

【0029】

以下、本実施の形態の詳細動作について説明する前に、まず、より具体的な課題、その課題に対する対策、及び、その対策に対する実装方法の概要を説明する。

【0030】

（具体的な課題）
既存の分散台帳（ブロックチェーン）を用いたコンセンサス形成においては以下のような課題がある。

【0031】

課題（１）０コストプラットフォームの実現：ＤＡＧを用いた第３世代分散台帳では、トランザクション発行のコストを０にする方法が提案されている。しかし、これらの手法では暗号通貨の送金に特化して設計されており、情報流通のプラットフォームへの応用に最適化されていないため、より効率の良いトランザクション発行、コンセンサス手法が必要である。

【0032】

課題（２）セキュリティ：ＤＡＧを用いた第３世代分散台帳（ＩｏＴａなど）ではトランザクション発行によって他のトランザクションを承認するコンセンサスアルゴリズムを用いるが、系全体としてのトランザクション数が少なくなると、攻撃者がトランザクション発行数の過半数を占める可能性が高まる。これにより、データの信憑性をそこねるリスクがあり、このセキュリティリスクの解消が必要である。

【0033】

課題（３）汎用性：プラットフォームを、暗号通貨ではなく、情報流通に利用可能とする必要がある。

【0034】

（提案手法での対策）
以下、上記課題に対する本提案手法での対策について説明する。下記の対策の説明において、括弧「」で囲んだ内容については、その内容についての課題と提案実装を後述する。

【0035】

課題（１）に対して、本実施の形態では、既存のメッセンジャーツールや情報交換ツールをもとに「トランザクションデータをユーザのスマートホン端末などで保管」する。これにより、コストのかかる専用のＦｕｌｌ－Ｎｏｄｅなどのサーバを動かすことなく維持できるデータストアを実現する。また、課題（３）に対して、情報流通における「送信・受信・対価支払・再利用を考慮したトランザクション設計」を行う。

【0036】

課題（２）に対して、本実施の形態では、トランザクション情報がユーザの端末（スマートホンなど）にプッシュされるため、トランザクション量の増減をリアルタイムに把握できる。これにより、トランザクション量が、系として想定するトランザクション量よりも下回った際に、エンドポイントの「補助承認トランザクション」発行により攻撃者が発行できるトランザクション数が正常トランザクション数より多くなることを防ぐことができる。

【0037】

（提案手法での課題）
以下、提案手法での課題について説明する。

【0038】

・「トランザクションデータをユーザのスマートホン端末などで保管」
（ａ）非特許文献１に示すようなBlock-latticeベースの手法を利用することで実現可能になる。しかし、スマートホンの通信や電池の持ちを考えると常時接続できるとは考えられず、各スマートホンにおけるダウンタイムを想定する必要がある。

【0039】

・「情報流通における送信・受信・対価支払・再利用を考慮したトランザクション設計」
（ｂ）既存のBlock-latticeベースの手法では、スマートコントラクトの実装が規定されていない。情報流通におけるアクセス制御・開示判断では双方の開示ポリシーと利用ポリシーを信頼できる環境で演算する必要があり、Block-latticeベースの手法に対する改善が必要である。

【0040】

（ｃ）既存のBlock-latticeベースの手法では、二重支払いへの対策など暗号通貨を対象としたトランザクション設計を行っているが、情報流通ではそれ以外にも送信の完了・受信の完了・対価支払・受信情報の再利用などのデータフローに着目したトランザクション設計が必要となる。

【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】

秘密計算とは、データを暗号化したまま計算することである。秘密計算の方法は特定の方法に限定されないが、例えば、完全準同型暗号を用いる方法、ＴＥＥ（Trusted Execution Environment）を用いる方法、ＭＰＣ（Multi-Party Computation）を用いる方法等を利用できる。これらから選択可能としてもよい。

【0089】

図４に、情報提供者端末１００－１、情報利用者端末１００－２、補助承認者端末１００－３が存在する場合において、秘密計算を行う場合のイメージを示す。

【0090】

秘密計算の方法として、ＭＰＣを使用する場合、情報提供者端末１００－１と情報利用者端末１００－２との２者間での秘密計算が可能である。また、情報提供者端末１００－１と情報利用者端末１００－２と補助承認者端末１００－３との間での３者間での秘密計算も可能である。２者間での秘密計算と、３者間での秘密計算を選択可能としてもよい。

【0091】

ＴＥＥを使用する場合、例えば、補助承認者端末１００－３でのＴＥＥを利用して秘密計算を行うこととしてもよいし、第三者環境でのＴＥＥを利用して秘密計算を行うこととしてもよい。また、例えば、情報提供者端末１００－１のローカルチェーン又は情報利用者端末１００－２のローカルチェーンの最終ブロックから算出される情報を用いて、ＴＥＥでの秘密計算を行う環境（端末）を選択してもよい。

【0092】

なお、スマートコントラクトによる演算結果は、秘密計算の実行環境による電子署名を付して、情報提供者端末１００－１のローカルチェーンと情報利用者端末１００－２のローカルチェーンのそれぞれに保管される。

【0093】

上記の仕組みにより、下記のような効果を得ることができる。

【0094】

データの売り買いの判断などで用いられるスマートコントラクトではデータ提供者、データ利用者の一方の環境を信用せず、かつ高価な外部システムを必要としない判定が必要となるが、上述したようにスマートコントラクトを秘密計算環境で実行することで、データ流通の一方で悪意を持ってコードを実行しようとしても実行できないため実行環境の安全性を担保できる。

【0095】

また、スマートコントラクトの結果に第三者の証明が必要となる場合は、３者間秘密計算を選定できるものとし、補助承認トランザクション発行者による署名を第三者の証明として用いることができる。また、スマートコントラクトの結果をチェーン上に相互補完することで実行結果の改ざん耐性を確保することができる。

【0096】

＜考えられる攻撃と対策＞
上述した秘密計算の手法において、３者間で２者を同一主体で提供することでスマートコントラクト内のデータ参照や改ざんが可能になる可能性がある。

【0097】

上記のような攻撃に対しては、情報提供者端末１００－１と情報利用者者端末１００－２の双方に依存する乱数から補助承認者端末１００－３を選定することで、意図的な補助承認者の選定に加担することが難しくなるようにすることができる。

【0098】

上記攻撃は、補助承認者の総数が少ない場合に成功する可能性はあるが、補助承認者数の制限による、ＴＥＥと、複数パーティによる秘密計算との選定制御ロジックを入れることで対策することも可能である。例えば、補助承認者の総数が閾値以下であればＴＥＥを利用する。

【0099】

（（ｃ）トランザクション設計）
前述したとおり、情報流通時のデータフローに着目したトランザクション設計が必要である。それに対して、本実施の形態では、図２のシーケンスに対応した各流通での情報の記録箇所をトランザクションとして定義する。例えば、送信開始／受信開始、送信完了／受信完了等の記録の際にトランザクションを発行している。

【0100】

データ提供制御や代金の支払いなど、情報提供者と情報利用者の２者の合意を証跡として残すべき場面でのみスマートコントラクトにより演算を実施し、２者ともに事後の否認をできないようにしている。

【0101】

上記の仕組みにより、情報流通において発生する開示合意、開示結果の合意とそれに対する対価の支払いの管理・確認が可能になり、多様な合意を伴った情報流通が可能になる。

【0102】

また、データ提供制御や代金の支払いなどの合意はスマートコントラクトにて実施するので、２者ともに事後の否認ができないようになる。

【0103】

＜考えられる攻撃と対策＞
ローカルチェーンで都合の悪い情報を故意に削除することが考えられる。これについては、Block Lattice等の既存手法で防止することが可能である。

【0104】

また、偽の情報を販売することも考えれる。これについては、情報利用者端末及び情報提供者端末それぞれのローカルチェーンでの売買実績（＝レピュテーション）が各ローカルチェーンに保管・公開されるので、購入時に売買実績を確認することで、偽装情報購入時のリスクを制御できる。

【0105】

また、情報利用者が、購入後の支払いを逃れることも考えられる。これについては、スマートコントラクトでの支払確定と、各ローカルチェーンへのスマートコントラクト名義の署名払い出しによる支払い完了管理によりデータ受領後の支払い拒否を防ぐことが可能である。

【0106】

（（ｄ）補助承認トランザクション）
本実施の形態では、各端末がオンライン時は承認ノードとして振る舞う。また、承認ノードが時間あたりに発行すべき承認トランザクション数は自律的に制御する。このような制御において、以下の点を考慮する必要がある。以下、考慮事項１～３とそれぞれについての対策である対策１～３について説明する。

【0107】

＜考慮事項１＞
補助承認を行うときに補助承認ノードはＣＰＵやネットワークリソースを消費されるので、できるだけ補助承認を行いたくない。

【0108】

＜対策１＞
端末ａのダウンタイム管理として端末ａで発行された補助承認トランザクションを加味する。すなわち、例えば、端末ａからの情報提供がなされる場合には、端末ａの補助承認トランザクション発行数に応じて、情報売買に対するインセンティブ（＝非発行者にペナルティ）を与える。例えば、補助承認トランザクション発行数の増加に応じて、情報提供に対する対価を増加させる等である。

【0109】

上記制御には、提案実装（ａ）のダウンタイム管理、及び提案実装ｂのダウンタイムペナルティを考慮したスマートコントラクトを利用することができる。これにより、当システムを利用するユーザに補助承認ノードとしての参加を促すことができる。

【0110】

＜考慮事項２＞
補助承認トランザクションの不足により、オンライン証明（ダウンタイム証明）が不足することが考えられる。

【0111】

＜対策２＞
端末が発行する補助承認トランザクションは、ダウンタイムを管理するＫｅｅｐＡｌｉｖｅとしての役割を有する。端末内のローカルチェーンに対して時間あたりに発行される補助承認トランザクション数が乱数の確率により不足する場合は、自端末からの発行トランザクション数を増加させることで補助承認トランザクション数の不足を防ぐことができる。

【0112】

＜考慮事項３＞
運用開始時や繁盛時などで接続端末数が大きく変化するときに、各端末で発行する承認トランザクション／期間（単位期間あたりの承認トランザクション数）が一定値でない場合、システム全体として発行される総承認トランザクション／期間が変化し、システム信頼性への影響が生じることが考えられる。

【0113】

＜対策３＞
各端末で発行する承認トランザクション／期間を一定値とすることで、受信する端末数と発行する端末数が一致するので各端末のローカルチェーンでのトランザクション頻度が維持される。その期間の系としてのシビルアタックなどに対する安全性は補助承認トランザクションを発行するノード間の重複によって事後検証できる。

【0114】

上述した仕組みにより、補助承認トランザクション生成に参加しない（＝系の維持に参加しない）ノードがなくなり、処理負荷が公平なシステムを実現できる。また、システム全体（系）としての補助承認トランザクション不足を回避できる。また、各端末は、利用者の増減を意識せずにトランザクションを発行するだけでよく、端末プログラムを単純化できる。

【0115】

図５を参照してより具体的に説明する。図５は、Block Latticeベース（非特許文献１）のシステムにおける、端末ａと端末ｂそれぞれのローカルチェーンの例を示している。図５に示すチェーンにおける各四角が、１つのトランザクション（発行トランザクションあるいは受信トランザクション）を示している。

【0116】

図５には、端末ａ、端末ｂのそれぞれについて、ローカルチェーンが時間とともに伸びる様子が示されている。端末ａのローカルチェーンにおけるＡに示す期間では、トランザクションの発行も受信もなかったことが示されており、この期間はダウンタイムとして管理される。例えば、Ｂにおいて受信した補助承認トランザクションに基づき、端末ａは、自身のローカルチェーンに記録するダウンタイムを更新する。

【0117】

また、端末ｂのローカルチェーンにおいて、Ｃで示す時点において、端末ｂは、チェーンの最終ブロックをもとにランダムに補助承認トランザクション発行先端末を選択し、補助承認トランザクションを発行する。

【0118】

Ｄで示す付近において、端末ｂは、受信トランザクションが少なくなれば，自信の発行トランザクションを増やすことで自端末でのダウンタイム監視に必要なトランザクション数を確保することができる。

【0119】

Ｅに示す線は、データ（情報）の提供を示している。例えば、ダウンタイムの長い端末（例：端末ａ）からの情報提供の対価に対するペナルティ（あるいは、ダウンタイムの短いデバイスからの情報提供の対価に対するインセンティブ）を売買時に考慮することができる。ペナルティの付与（インセンティブの付与）はスマートコントラクトで実現することができる。例えば、スマートコントラクトにより、ダウンタイムの長い端末から提供される情報の対価を、ダウンタイムの短い端末から提供される情報の対価よりも低くすることができる。

【0120】

なお、図５に示したようなシステムにおける補助承認トランザクションは、端末間でやり取りするため、ランダムの２者がいればよく，系としての接続対数を考慮する必要はない。

【0121】

（端末の機能構成例）
図６に、端末１００の機能構成例を示す。端末１００は、情報提供者端末、情報利用者端末、補助承認端末のいずれにもなることができる。端末１００を情報流通装置と呼んでもよい。

【0122】

図６に示すように、端末１００は、通信部１１０、登録部１２０、トランザクション処理部１３０、スマートコントラクト処理部１４０、記憶部１５０、データ送信部１６０、データ受信部１７０、ダウンタイム管理部１８０を有する。

【0123】

なお、端末１００は、情報提供者端末として動作するときには情報提供者端末として必要な機能のみを持てばよく、情報利用者端末として機能する場合には情報利用者端末として必要な機能のみを持てばよく、補助承認端末として動作するときには補助承認端末として必要な機能のみを持てばよいが、全ての機能を持ってもよい。

【0124】

通信部１１０はネットワークを介した通信を実行する。記憶部１５０は、データ、ローカルチェーン等を保持する。登録部１２０は、ローカルチェーンにデータの提供条件を登録するとともに、データに関する情報を外部システムに送信し、外部システムから公開させる。また、登録部１２０は、ローカルチェーンのコピーを、外部に備えられるストレージに格納し、公開させる。

【0125】

データ送信部１２０は、情報利用者からのデータ要求に含まれる利用内容と提供条件とに基づいて、データの提供が可能であると判断された場合において、データを情報利用者端末に送信するとともに、送信開始と送信完了をローカルチェーンに記録する。

【0126】

データ受信部１７０は、情報提供者端末から受信したデータのメタ情報に基づいて、データの利用が可能であると判断された場合において、データを情報提供者端末から受信するとともに、受信開始と受信完了を自身のローカルチェーンに記録する。また、データ受信部１７０はデータに対する対価の支払いを情報提供者に対して実行する支払い処理部の機能を含んでいてもよい。

【0127】

ダウンタイム管理部１８０は、ローカルチェーンにおいて、トランザクションの発行と受信のいずれも存在しない期間をダウンタイムとして把握し、管理する。

【0128】

スマートコントラクト処理部１４０は、例えば、データ提供可否判断、データ利用可否判断、インセンティブやペナルティを考慮した対価提示及び支払い処理等を自動的に、スマートコントラクトのコードを実行することで行うことができる。また、スマートコントラクト処理部１４０は、秘密計算を利用してスマートコントラクトのコードを実行することも可能である。

【0129】

トランザクション処理部１３０は、各種のトランザクションの発行及び受信を行い、トランザクションをローカルチェーンに記録する。また、トランザクション処理部１３０は、ダウンタイムを管理するキープアライブとして補助承認トランザクションを発行することも可能である。

【0130】

（ハードウェア構成例）
端末１００（情報流通装置）は、例えば、コンピュータにプログラムを実行させることにより実現できる。この「コンピュータ」は、スマートホン等であってもよい。

【0131】

すなわち、端末１００は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、端末１００で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

【0132】

図７は、上記コンピュータのハードウェア構成例を示す図である。図７のコンピュータは、それぞれバスＢＳで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。

【0133】

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0134】

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、端末１００に係る機能を実現する。インタフェース装置１００５は、ネットワークや各種計測装置、運動介入装置等に接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。

【0135】

（実施の形態のまとめ）
本明細書には、少なくとも下記各項の情報流通装置、情報流通方法、及びプログラムが開示されている。
（第１項）
提供対象のデータと、ローカルチェーンを保持する記憶部と、
前記ローカルチェーンに前記データの提供条件を登録するとともに、前記データに関する情報を外部システムに登録する登録部と、
情報利用者からのデータ要求に含まれる利用内容と前記提供条件とに基づいて、前記データの提供が可能であると判断された場合において、前記データを前記情報利用者に送信するとともに、送信開始と送信完了を前記ローカルチェーンに記録するデータ送信部と、
を備える情報流通装置。
（第２項）
前記登録部は、前記ローカルチェーンのコピーを、外部に備えられるストレージに格納し、公開させる
第１項に記載の情報流通装置。
（第３項）
ローカルチェーンを保持する記憶部と、
情報提供者から受信したデータのメタ情報に基づいて、前記データの利用が可能であると判断された場合において、前記データを情報提供者から受信するとともに、受信開始と受信完了を前記ローカルチェーンに記録するデータ受信部と、
前記データに対する対価の支払いを前記情報提供者に対して実行する支払い処理部と
を備える情報流通装置。
（第４項）
秘密計算を用いてスマートコントラクトを実行するスマートコントラクト処理部
を備える第１項ないし第３項のうちいずれか１項に記載の情報流通装置。
（第５項）
前記ローカルチェーンにおいて、トランザクションの発行と受信のいずれも存在しない期間をダウンタイムとして管理するダウンタイム管理部
を備える第１項ないし第４項のうちいずれか１項に記載の情報流通装置。
（第６項）
キープアライブとして補助承認トランザクションを発行するトランザクション処理部
を備える第１項ないし第５項のうちいずれか１項に記載の情報流通装置。
（第７項）
情報利用者端末と情報提供者端末による情報流通方法であって、
前記情報提供者端末は、提供対象のデータと、自身のローカルチェーンを保持しており、前記ローカルチェーンに前記データの提供条件を登録するとともに、前記データに関する情報を外部システムに登録し、
前記情報利用者端末からのデータ要求に含まれる利用内容と前記提供条件とに基づいて、前記データの提供が可能であると判断された場合において、前記情報提供者端末は、前記データを前記情報利用者端末に送信するとともに、送信開始と送信完了を前記ローカルチェーンに記録し、
前記情報利用者端末は、前記データを前記情報提供者端末から受信するとともに、受信開始と受信完了を自身のローカルチェーンに記録し、前記データに対する対価の支払いを実行する
情報流通方法。
（第８項）
コンピュータを、第１項ないし第６項のうちいずれか１項に記載の情報流通装置における各部として機能させるためのプログラム。

【0136】

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0137】

１００ 端末
１１０ 通信部
１２０ 登録部
１３０ トランザクション処理部
１４０ スマートコントラクト処理部
１５０ 記憶部
１６０ データ送信部
１７０ データ受信部
１８０ ダウンタイム管理部
２００ 外部システム
３００ ネットワーク
４００ ストレージ
１０００ ドライブ装置
１００１ 記録媒体
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インタフェース装置
１００６ 表示装置
１００７ 入力装置
１００８ 出力装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】