JP7403406B2

JP7403406B2 - データ利活用システムにおけるデータ提供方法

Info

Publication number: JP7403406B2
Application number: JP2020129491A
Authority: JP
Inventors: 健久田; 裕教江丸; 明人金子
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2020-07-30
Filing date: 2020-07-30
Publication date: 2023-12-22
Anticipated expiration: 2040-07-30
Also published as: US11816109B2; US20220035819A1; JP2022026161A

Description

本発明は、データ利活用システムにおけるデータ提供方法に関する。

ブロックチェーンとは、過去に行われたすべての取引データが、ブロックごとにまとめられ、各ブロックが１本の鎖のようにつながった分散型のデータベース（台帳）をいう。ネットワーク上に多数存在するコンピュータによって、この台帳は検証され、全く同じものが共有されており、参加者は誰でも台帳を参照することができる。なお、不特定多数が参加者として認められるパブリックチェーン、あらかじめ決められた参加者のみが参加できるプライベートチェーン、コンソーシアムチェーンがある。ブロックチェーンのブロックには前のブロックによって決まる部分が含まれているため、過去の取引データを改変すると次のブロックとの整合がつかなくなり、かつ新しいブロックをつなげるには複数の参加者の合意が必要であるため、実質的に台帳の内容を改ざんすることは困難となっている。

このような台帳の改ざんが困難であるという特徴を活かして、ブロックチェーンはその用途が広げられ、暗号資産に限られず、複数機関の間での電子データ共有や権利証明、サプライチェーンなどへの幅広い応用が検討されている。特に、複数機関の間で取引の信頼性を確保できる点でデータ共有プラットフォームへの親和性が高く、例えば、特許文献１には、ブロックチェーンを用いたデータ共有プラットフォームが提案されている。

特開２０１９－１７６４５８号公報

特許文献１に開示されるデータ共有プラットフォームでは、データ提供者がデータ保存サーバに保存したデータを、データ使用者が利用料を支払い、該当データをデータ保存サーバから伝送する、というオリジナルデータ単位の取引が想定されている。

しかしながら、データの大容量化や個人情報保護等の観点から、オリジナルデータである大容量データを丸ごと取引するよりも、むしろ、大容量データからの抜粋データや大容量データを加工して得られる特徴量データを取引対象とする需要の方が高まると考えられる。すなわち、ビッグデータを機械学習や統計解析に用いたいデータ利用者にとって、オリジナルデータそのものが必要なわけではなく、オリジナルデータに対して所定の加工を行って、適切なデータ範囲やデータ形式でデータ取得ができれば十分である。

本発明は、オリジナルデータに対してデータ利用者が所望する加工を行った処理データを提供するデータ共有プラットフォームにおいて、データ提供者がデータ利用者に提供する処理データについての信頼性を確保することでデータ利活用を促進可能なデータ利活用システム、データ利活用システムにおけるデータ提供方法を提案するものである。

本発明の一実施の形態であるデータ提供方法は、ネットワークに接続され、第１のユーザの第１のデータ管理サーバ及び第２のユーザの第２のデータ管理サーバを含む複数のデータ管理サーバとデータ処理サーバとを有するデータ利活用システムにおけるデータ提供方法であって、複数のデータ管理サーバはそれぞれ、分散共有台帳を保持しており、第１のデータ管理サーバは、データ登録プログラムを実行することにより、第１データをストレージに保存するとともに、第１データが保存されたことを示す第１のトランザクションを作成し、検証された第１のトランザクションを分散共有台帳の一つであるメタデータ管理テーブルのレコードとして追加し、第２のデータ管理サーバは、第１データを処理する解析処理リクエストを第１のデータ管理サーバに送信し、第１のデータ管理サーバは、解析処理リクエストを受けて解析処理プログラムを実行することにより、解析処理リクエストをデータ処理サーバに転送して第１データを処理して得られた第２データをストレージに保存させるとともに、データ処理サーバから第１データの処理完了通知を受けて、解析処理リクエストにしたがって第１データを処理したことを示す第２のトランザクションを作成し、検証された第２のトランザクションを分散共有台帳の一つである処理／利用証跡管理テーブルのレコードとして追加する。

データ提供者が外部にそのまま提供することを望まないオリジナルデータであっても、その処理データであることを改ざん困難な証跡として残した上で処理データを他者に提供することでデータ利活用を促進する。

その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

データ利活用システムの全体構成図である。データ利活用システムの全体構成図である。データ管理サーバのハードウェア構成図である。データ処理サーバのハードウェア構成図である。クライアントサーバのハードウェア構成図である。オリジナルデータ登録フローチャートである。データ利活用フローチャートである。第１の利用審査フローチャートである。第２の利用審査フローチャートである。データ解析処理フローチャートである。課金フローチャートである。アクセス権限管理テーブルのデータ構造例である。アクセス権限管理テーブルのデータ構造例である。処理／利用証跡管理テーブルのデータ構造例である。メタデータ管理テーブルのデータ構造例である。課金テーブルのデータ構造例である。データ管理テーブルのデータ構造例である。処理実行管理テーブルのデータ構造例である。

以下、本発明を実施するための形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための各図において、同一の機能を有する要素には同一の符号を付し、その繰り返しの説明は省略するものとする。

図１Ａにデータ利活用システムの全体構成図を示す。本システムは、データ管理サーバ２０００、データ処理サーバ３０００、クライアントサーバ４０００を有し、これらはネットワーク１１００によって互いに通信可能に接続されている。ネットワーク１１００は有線ネットワーク、無線ネットワーク、あるいはそれらの混在であってもよい。図１Ａの構成は、本実施例でのデータ利活用システムによるサービスをパブリッククラウド上で実現する場合に好適なシステム構成である。

データ管理サーバ２０００は、データ利活用システムを利用する主体（ユーザ）ごとに設けられる。なお、ユーザごとに一つのデータ管理サーバを割り当てる必要はなく、複数のユーザが一つのデータ管理サーバを共有してもよい。本実施例で説明するデータ利活用サービスの主体には、データ利用者Ａ及びデータ提供者Ｂが含まれる。主体は、個人であってもよいし、企業のような組織であってもよい。また、主体の役割は必ずしも固定的ではなく、データ利用者Ａにもデータ提供者Ｂにもなりうるものであるが、以下では説明を複雑にしないため、データ利用者Ａとデータ提供者Ｂとは特記しない限り、以下の説明ではそれぞれの役割のみを果たす主体として記述する。データ利用者Ａは、オリジナルデータを保有するデータ提供者Ｂに対して、オリジナルデータに対して所定の処理を施した処理データの提供を依頼する。データ提供者Ｂはその依頼を受け付けると、依頼に沿った処理をオリジナルデータに対して実行し、オリジナルデータを加工した処理データをデータ利用者Ａに提供する。本実施例のデータ利活用システムでは、オリジナルデータの登録から処理データの提供及び課金に至るまでの過程における重要な手続き、具体的にはオリジナルデータの登録、オリジナルデータの利用審査、オリジナルデータの処理（加工）、課金をスマートコントラクトにより実行し、改ざん困難な証跡として残す。

このため、データ管理サーバ２０００は、スマートコントラクトを実行する共通機能を有し、データ利活用における各種トランザクションを記録する分散共有台帳を保有している。

各主体（ユーザ）は端末１０００からクライアントサーバ４０００を通じて、データ利活用システムにアクセスする。端末１０００からの入力は、クライアントサーバ４０００を介して自己のデータ管理サーバ２０００に送られる。例えば、ユーザがデータ利用者Ａであれば、入力はデータ利用者Ａのデータ管理サーバ２０００Ａに、ユーザがデータ提供者Ｂであれば、入力はデータ提供者Ｂのデータ管理サーバ２０００Ｂに送られる。端末１０００は、ＰＣ（Personal Computer）でもよく、スマートフォン、タブレットでもよい。

データ処理サーバ３０００は、データ提供者Ｂの保有するオリジナルデータに対して、データ利用者Ａの依頼にしたがった処理を実行する。データ処理サーバ３０００は、データ利活用システムの主体間で共有されるサーバであってもよいし、データ提供者Ｂが占有するサーバであってもよい。さらに、データ利活用システムの主体として、データ加工者Ｃが存在する場合には、データ加工者Ｃが占有するサーバであってもよい。データ処理サーバ３０００はデータ利活用システムに複数あってもよく、またデータ加工者が複数いても構わない。

図１Ｂは、データ利活用システムの別の全体構成図である。本システムは、サブネット１１００によって互いに通信可能とされたデータ管理サーバ２０００、データ処理サーバ３０００、クライアントサーバ４０００を有するサブシステムを複数有し、複数サブシステムがさらに共通ネットワーク１２００によって互いに通信可能に接続されている。サブシステムは、データ利活用システムを利用する主体ごとに設けられ、データ処理サーバ３０００も主体に占有される形でサブシステム上に設けられている。共通ネットワーク１２００は有線ネットワーク、無線ネットワーク、あるいはそれらの混在であってもよい。図１Ｂの構成は、本実施例でのデータ利活用サービスを各主体のプライベートクラウド上で実現する場合に好適なシステム構成である。

なお、図１Ａ、図１Ｂの全体構成図はそれぞれ典型例であって、様々な変形が許容される。例えば、図１Ａのシステムに対して、図１Ｂのサブシステムを接続するような全体構成、図１Ｂのシステムにおいて共通ネットワーク１２００上にデータ利活用システムの主体間で共有されるデータ処理サーバが配置されるような全体構成等、さまざまな変形例が考えられる。

次に、各サーバのハードウェア構成について説明する。

図２にデータ管理サーバ２０００のハードウェア構成図を示す。データ管理サーバ２０００は、プロセッサ２１２０、入出力デバイス２１３０、メモリ２１４０、ストレージメディア２１５０、ネットワークインタフェース２１６０を含み、これらはバス２１７０により通信可能に結合されている。入出力デバイス２１３０は、外部装置との情報の入出力を行うためのデバイスであり、ネットワークインタフェース２１６０はネットワーク１１００と接続するためのインタフェースである。なお、以下では、データ管理サーバ２０００及びその構成について、データ管理サーバ２０００を使用する主体（ユーザ）を明示する場合、符号の後に主体を示す符号を付して示す。例えば、データ提供者Ａのデータ管理サーバ２０００であることを明示する場合には、データ管理サーバ２０００Ａと表示する。

ストレージメディア２１５０は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などの不揮発性記憶装置であって、データ管理サーバ２０００が実行するプログラムやプログラムが処理するデータなどを保存する。データには利活用対象となる対象データと対象データの管理情報である管理データが含まれる。図２は、データ提供者Ｂのデータ管理サーバを例示するものであり、対象データとしてオリジナルデータとその加工データである処理データとを保存している。ただし、対象データがビッグデータのような大規模データである場合には、データのコンテンツそのものをストレージメディア２１５０に保存する必要はなく、例えば、クラウド上のオブジェクトストレージに保存し、対象データにアクセスするためのデータパスを保存すればよい。管理データには、対象データを管理するデータ管理テーブル１４０００、証跡として記録される各種分散共有台帳が含まれる。本実施例では、対象データとしてオリジナルデータを保存しているのは、データ提供者Ｂのデータ管理サーバのみである。

メモリ２１４０はＲＡＭ（Random Access Memory）で構成され、プロセッサ２１２０の命令により、プログラムやプログラムの実行に必要なデータ等をストレージメディア２１５０から一時的に記憶する。プロセッサ２１２０は、ストレージメディア２１５０からメモリ２１４０にロードしたプログラムを実行する。

ストレージメディア２１５０に格納されたプログラム、データの内容については後述する。データ管理サーバ２０００の機能は、ストレージメディア２１５０に格納されたプログラムがプロセッサ２１２０によって実行されることで実現される。

図３にデータ処理サーバ３０００、図４にクライアントサーバ４０００のハードウェア構成図を示す。ハードウェア構成そのものは図２のデータ管理サーバと同じであるため、説明を省略する。

以下では、本実施例のデータ利活用システムの利用例として、気象データを蓄積するデータ提供者Ｂに対して、データ利用者Ａが特定地域、特定期間での気象予測の提供を依頼する例を用いて、本データ利活用システムのデータ提供方法について説明する。

例えば、データ提供者Ｂは、日本全国における観測された気象に関するメッシュデータを蓄積しているものとする。メッシュデータとは、所定の大きさのエリア、例えば１ｋｍ四方単位ごとに、所定時間間隔での気象に関する観測データや予報データをまとめたものである。気象に関するデータには、天気、気温、降水量、気圧、風速・風向、ＰＭ２．５（微小粒子状物質）濃度などが含まれているものとする。データ利用者Ａが、データ提供者Ｂに対し、データ提供者Ｂが蓄積する気象観測データ（オリジナルデータ）を元に、翌週の東京２３区でのＰＭ２．５分布予測データの提供を依頼する場合を例にして説明する。

（オリジナルデータ登録フロー）
データ利活用に先立ち、図５にデータ提供者Ｂが自己のデータ管理サーバ２０００Ｂにオリジナルデータ（ここでは、気象データ）を登録するフローを示す。データ提供者Ｂはクライアントサーバ４０００を介して、データ管理サーバ２０００Ｂにオリジナルデータを登録する。

データ提供者Ｂはクライアントサーバ４０００のデータ登録プログラム４２００を起動し、オリジナルデータと対応するメタデータ（説明は後述する）をデータ提供者Ｂのデータ管理サーバ２０００Ｂに転送する（５０１０）。データ登録にあたっては、オリジナルデータは、生データからあらかじめ定められた形式にデータ形式が整えられているものとする。メタデータは、オリジナルデータのデータ形式に基づき、オリジナルデータの概要を示すデータをオリジナルデータから切り出すことで生成される。または、データ提供者Ｂがオリジナルデータの内容に基づき、メタデータを手入力することも可能である。

データ管理サーバ２０００Ｂのデータ登録プログラム２２００Ｂは、クライアントサーバ４０００からオリジナルデータとそのメタデータを受信する（５１１０）と、当該オリジナルデータに対してデータＩＤを発行し（５１２０）、ストレージメディア２１５０に保存する（５１３０）。ここで、ステップ５１２０で発行するデータＩＤは本システム全体で一意のデータＩＤとする。本実施例においては、データの登録や加工といったデータ履歴を耐改ざん性の高い証跡として分散共有台帳に記録するため、データ提供者Ｂが取得した新たなオリジナルデータは分散共有台帳に記録される。このため、分散共有台帳においてデータＩＤが重複しないよう、データＩＤは本システム全体で一意とされる必要がある。分散共有台帳の各レコードに対するＩＤの割り付けは、一般的なブロックチェーンの台帳作成と同様の処理であるため、詳しい説明は省略する。または、ステップ５１２０では、データ管理サーバ２０００Ｂにおいて一意なローカルデータＩＤを発行し、分散共有台帳において当該オリジナルデータについて割り当てられるデータＩＤとの変換テーブルを別途保持する構成としてもよい。

データ登録プログラム２２００Ｂは、オリジナルデータのストレージメディア２１５０への保存が完了すると受領通知を発行する。クライアントサーバ４０００のデータ登録プログラム４２００が受領通知を受信する（５０２０）と、データ登録プログラム４２００は終了する。

一方、データ管理サーバ２０００Ｂのデータ登録プログラム２２００Ｂは、新規登録したオリジナルデータについてのレコードをデータ管理テーブル１４０００に追加する（５１４０）。

図１４にデータ管理テーブル１４０００のデータ構造例を示す。データ管理テーブル１４０００は、データＩＤカラム１４００１、データパスカラム１４００２、親データＩＤカラム１４００３、登録者ＩＤカラム１４００４、登録時刻カラム１４００５を含む。カラム１４００１には登録するデータのデータＩＤ、カラム１４００２にはデータの保存アドレス（データパス）、カラム１４００３には、登録されたデータが別のデータから加工された処理データである場合にその元となったデータ（親データを呼ぶ）のデータＩＤ、カラム１４００４にはデータを登録したユーザＩＤ、カラム１４００５にはデータがデータ管理サーバ２０００Ｂに登録された時刻が記録される。

レコード１４０１１がステップ５１３０で保存されたオリジナルデータについてのレコードであるとすると、カラム１４００１には、ステップ５１２０で割り当てられたデータＩＤが、カラム１４００３には、本データは加工されたデータではないので「－（Null）」が、カラム１４００４にはデータ提供者Ｂを示す「100」が登録される。なお、データ管理テーブル１４０００を登録されたデータのメタデータも保存できるように拡張してもよい。

続いて、データ登録プログラム２２００Ｂは、システムへの新規データ登録を示すトランザクション（メタデータ登録ＴＸ）を作成する（５１５０）。作成されたトランザクションは、分散共有台帳を保有する他のデータ管理サーバによって検証が行われた後に、分散処理台帳への書き込み処理を行い（５１６０）、トランザクションはメタデータ管理テーブルの１つのレコードとして追加される（５１７０）。

図１２に分散共有台帳であるメタデータ管理テーブル１２０００のデータ構造例を示す。メタデータ管理テーブル１２０００は、トランザクションＩＤカラム１２００１、データＩＤカラム１２００２、提供者ＩＤカラム１２００３、メタデータカラム１２００４、トランザクション時刻カラム１２００５、利用者署名カラム１２００６、提供者署名カラム１２００７、検証時刻カラム１２００８、検証者署名カラム１２００９を含む。カラム１２００１にはトランザクション（履歴）を一意に特定するＩＤ（ＴＸＩＤ）、カラム１２００２にはデータＩＤ、カラム１２００３にはデータを提供したユーザＩＤ、カラム１２００４にはデータのメタデータ、カラム１２００５～１２００９はトランザクションの検証情報、具体的にはカラム１２００５には、トランザクションが作成された時刻、カラム１２００６にはデータ利用者の署名、カラム１２００７にはデータ提供者の署名、カラム１２００８にはトランザクションが検証者によって検証された時刻、カラム１２００９にはトランザクションを検証した検証者の署名が記録される。なお、メタデータカラム１２００４にはデータのメタデータが登録され、データのデータ形式の他、データ形式ごとの項目を含む。

ＴＸＩＤ「A1001」がステップ５１３０で保存されたオリジナルデータについてのレコードであるとすると、カラム１２００２には、ステップ５１２０で割り当てられたデータＩＤが、カラム１２００４には、ステップ５１１０で受信されたメタデータが、カラム１２００６には、新しいオリジナルデータの登録であるので「－」が、カラム１２００７にはデータ提供者Ｂの署名が登録されている。

以上の処理によりデータ提供者Ｂが登録したオリジナルデータは、メタデータ管理テーブルに登録されることによって、データ利活用システムのユーザが利用可能な状態となる。

（データ利活用フロー）
続いて、図６にデータ利用者Ａがデータ提供者Ｂに対して、データ提供者Ｂの保有するオリジナルデータ（気象観測／予報データ）を加工した処理データの提供を依頼し、処理データ（ＰＭ２．５分布予測データ）を受け取り、課金するまでのデータ利活用フローを示す。

データ利用者Ａはクライアントサーバ４０００のリクエスト対応プログラム４３００を起動し、データリクエストをデータ利用者Ａのデータ管理サーバ２０００Ａに発出する（６０１０）。データリクエストは、依頼する処理データの情報、例えば、データ形式（ＰＭ２．５）、期間（翌週）、地域（東京２３区）を含む。

クライアントサーバ４０００から、データリクエストがデータ利用者Ａのデータ管理サーバ２０００Ａに送信されると、リクエスト対応プログラム２３００Ａは、リクエストを実現するために必要なデータをピックアップする（６１１０）。例えば、データリクエストから、必要なデータとして「東京２３区の先月のアメダス計測データ」、「東京２３区の先月のＰＭ２．５計測データ」、「東京２３区のこの先１か月の天気予報データ」をピックアップしたとする。

リクエスト対応プログラム２３００Ａは、データ利活用システムに処理データを得るために必要なデータが登録されているかどうかを確認するため、メタデータ管理テーブル１２０００を検索する（６１２０）。検索により、必要なデータをそれぞれ含む「東京２３区の先月のアメダス計測データ」、「関東地方の先月のＰＭ２．５計測データ」、「日本全国のこの先１か月の天気予報データ」を、データ提供者Ｂが保有していることが確認されたとする。

リクエスト対応プログラム２３００Ａは、分散共有台帳であるアクセス権限管理テーブル１００００を検索し、アクセス権限の有無を確認する（６１３０）。本実施例では、データの利用審査履歴を記録するアクセス権限管理テーブル１００００において、当該データについて、過去にアクセス権限ありの履歴があれば、アクセス権限ありと判断するものとし、そうでなければアクセス権限の有無は不明（または、なし）とする。なお、ステップ６１３０でのアクセス権限チェック方法は、システムにおけるアクセス権限管理方法に従って行えばよく、例えば、メタデータ管理テーブル１２０００においてデータごとにアクセス権限を有する主体を特定して記録している場合には、メタデータ管理テーブル１２０００を参照してアクセス権限を確認することができる。逆に、システムに登録されているデータに対して、システムの主体はアクセス権限があることを前提とするようなシステムの場合は、ステップ６１３０を省略できる。

リクエスト対応プログラム２３００Ａは、データ利用者Ａのデータリクエストに対するメタデータ管理テーブル１２０００の検索結果とアクセス権限チェックの結果とを含むデータリクエスト結果通知をクライアントサーバ４０００に送付する（６１４０）。クライアントサーバ４０００のリクエスト対応プログラム４３００は、データ管理サーバ２０００Ａからデータリクエスト結果通知を受信する（６０２０）。データ利用者Ａはリクエスト対応プログラム４３００により、データリクエスト結果通知からリクエストを実現するために必要なデータの一覧とそれらのデータに対してそれぞれ利用審査が必要であるかを確認する。その後、オリジナルデータを加工して処理データを得るために必要なデータ処理の仕様（計算リソース）を指定する（６０３０）。使用するアルゴリズムやパラメータ、あるいは使用するデータ処理サーバの演算能力によって処理データである予測の精度や予測を入手するまでの時間が変わってくるためである。データ処理の仕様を指定した後に、データ利用者Ａはリクエスト対応プログラム４３００により、データ提供者Ｂに対する対象データの利用審査リクエストを作成する（６０４０）。クライアントサーバ４０００から、利用審査リクエストがデータ利用者Ａのデータ管理サーバ２０００Ａに送信されると、リクエスト対応プログラム２３００Ａは利用審査プログラム２４００Ａを呼び出す（６１５０）。

後述する利用審査の結果、すべてのデータについてアクセス権限が付与された場合（ステップ６１６０でYes）には、リクエスト対応プログラム２３００Ａは、データ提供者Ｂに対する解析処理リクエストを作成する（６１７０）。すべてのデータについてアクセス権限が付与されたのでなければ（ステップ６１６０でNo）、リクエスト対応プログラム２３００Ａは終了する。また、利用審査結果は、データ管理サーバ２０００Ａからクライアントサーバ４０００に送信され、データ利用者Ａに通知される（６０５０）。

なお、データリクエスト結果通知の受信（６０２０）時にすべてのデータについてアクセス権限が既にある場合には、ステップ６０４０で作成した利用審査リクエストは後述する利用審査において自動承認されるものとし、リクエスト対応プログラム２３００Ａは、データ提供者Ｂに対する解析処理リクエストを作成する（６１７０）。

この例では、データ利用者Ａのデータ管理サーバ２０００Ａにおいて利用するデータが特定された後に、クライアントサーバ４０００を介して、データ利用者Ａにデータ処理の仕様を指定させている（６０３０）。これに対して、データ利用者Ａにデータ処理の仕様を指定させないシステムであれば、データ管理サーバ２０００Ａのリクエスト対応プログラム２３００Ａが自動的に、データ提供者Ｂのデータ管理サーバ２０００Ｂに対して、利用審査リクエストの作成（６０４０）、及び解析処理リクエストの作成（６１７０）を実行するようにしてもよい。データ処理の仕様を指定しないシステムにおいては、後述する中間処理データを有効に活用する機会の増加が期待される。

データ管理サーバ２０００Ａから、解析処理リクエストがデータ提供者Ｂのデータ管理サーバ２０００Ｂに送信されると、データ管理サーバ２０００Ｂのリクエスト対応プログラム２３００Ｂは解析処理プログラム２５００Ｂを呼び出し（６２１０）、解析処理リクエストに沿った処理を実行し、処理データを作成する。オリジナルデータの解析処理については後述する。

解析処理によって得られた処理データをデータ利用者Ａに提供する（６２２０）。処理データのデータ利用者Ａへの提供方法は、処理データそのものをデータ管理サーバ２０００Ａに送ってもよいし、処理データのデータパスをデータ管理サーバ２０００Ａに送ってもよい。処理データが大容量である場合は、データ転送量を抑制するためデータパスを送ることが望ましい。なお、図６のフローでは明示的には示されないが、ステップ６２２０は、ステップ６２１０に係る処理のトランザクションの分散共有台帳への書き込みが完了した後に実行される。これはトランザクションの検証段階でエラーが生じたり、トランザクションがキャンセルされたりした場合に、分散共有台帳への書き込みがなされることなく、データ提供者Ｂからデータ利用者Ａに処理データが提供されてしまうことを防止するためである。

データ管理サーバ２０００Ａのリクエスト対応プログラム２３００Ａは処理データを受領する（６１８０）ことにより終了する。

データ管理サーバ２０００Ｂのリクエスト対応プログラム２３００Ｂは、引き続きデータ利用者Ａへのデータ提供に係る課金のため、課金リクエストを作成し（６２３０）、課金プログラム２６００Ｂを呼び出す（６２４０）。課金処理については後述する。課金処理が終了することにより、リクエスト対応プログラム２３００Ｂは終了し、処理データの提供手続きはすべて完了する。

（利用審査フロー）
図６のフローチャートにおけるステップ６１５０に係る利用審査について説明する。図７Ａに利用審査の第１のフロー例を示す。

データ管理サーバ２０００Ａの利用審査プログラム２４００Ａは、図６のフローチャートにおけるステップ６０４０にて作成された利用審査リクエストを、データ提供者Ｂのデータ管理サーバ２０００Ｂに転送する（７０１０）。

データ管理サーバ２０００Ｂの利用審査プログラム２４００Ｂは、利用審査リクエストを受信し（７１１０）、利用審査を実施する（７１２０）。審査方法については特に限定せず、例えば、ホワイトリスト方式でも、ブラックリスト方式であってもよい。審査が終了すると、データごとに審査依頼時刻、審査実施時刻、審査結果等を含む審査終了通知をデータ管理サーバ２０００Ａに送付する（７１３０）。

データ管理サーバ２０００Ａの利用審査プログラム２４００Ａは、データ管理サーバ２０００Ｂから審査終了通知を受信する（７０２０）と、データへのアクセス審査履歴を示すトランザクション（利用審査登録ＴＸ）を作成する（７０３０）。作成されたトランザクションは、分散共有台帳を保有する他のデータ管理サーバによって検証が行われた後に、分散処理台帳への書き込み処理を行い（７０４０）、トランザクションはアクセス権限管理テーブルの１つのレコードとして追加される（７０５０）。

図１０Ａに、図７Ａのフローチャートに対応する分散共有台帳であるアクセス権限管理テーブル１００００ａのデータ構造例を示す。アクセス権限管理テーブル１００００ａは、トランザクションＩＤカラム１０００１、データＩＤカラム１０００２、利用者ＩＤカラム１０００３、提供者ＩＤカラム１０００４、審査時刻カラム１０００５、ステータスカラム１０００６、トランザクション時刻カラム１０００７、利用者署名カラム１０００８、提供者署名カラム１０００９、検証時刻カラム１００１０、検証者署名カラム１００１１を含む。カラム１０００１にはトランザクション（履歴）を一意に特定するＩＤ（ＴＸＩＤ）、カラム１０００２にはデータＩＤ、カラム１０００３にはデータの利用審査依頼者、すなわちデータを利用するユーザＩＤ、カラム１０００４にはデータの利用審査依頼審査者、すなわちデータを提供したユーザＩＤ、カラム１０００５には利用審査が行われた時刻（この例では、審査依頼時刻と審査実施時刻）、カラム１０００６には、データの利用許否（利用審査結果）、カラム１０００７～１００１１はトランザクションの検証情報が記録される。なお、カラム１０００６にはデータの利用審査依頼が許諾された場合には１、利用審査依頼が拒否された場合には０が登録されるものとする。

ＴＸＩＤ「B1001」がステップ７１１０で受信された利用審査リクエストに含まれる、ある１つのオリジナルデータの利用審査についてのトランザクションであるとすると、カラム１０００２には、利用審査対象であるデータのデータＩＤが、カラム１０００３には、データ利用者ＡのユーザＩＤが、カラム１０００４には、データ提供者ＢのユーザＩＤが、カラム１０００６には、利用審査リクエストが当該データについて許諾されたことを示す「１」が登録されている。

図７Ｂに利用審査の第２のフロー例を示す。利用審査において、利用審査依頼者の身元確認が必要になるような場合に、審査に時間を要する場合がある。このような場合、第２のフロー例では、利用審査依頼と利用審査とを分離することによって、データ管理サーバ２０００Ａの利用審査プログラム２４００Ａが長時間にわたってデータ管理サーバ２０００Ｂからの応答待ちになることを防止することができる。図７Ｂのフローチャートでは、図７Ａのフローチャートと同じステップについては同じ符号を付し、説明を省略する。

データ管理サーバ２０００Ｂの利用審査プログラム２４００Ｂは、利用審査リクエストを受信する（７１１０）と、審査依頼を受理したことをデータ管理サーバ２０００Ａに通知する（７１４０）。利用審査プログラム２４００Ｂは、この段階ではデータの利用許否の審査を行わないので、遅滞なく受理通知をデータ管理サーバ２０００Ａに通知することができる。

データ管理サーバ２０００Ａの利用審査プログラム２４００Ａは、データ管理サーバ２０００Ｂから審査依頼受理通知を受信する（７０６０）と、データへのアクセス審査依頼の履歴を示すトランザクション（利用審査依頼ＴＸ）を作成する（７０７０）。作成されたトランザクションは、分散共有台帳を保有する他のデータ管理サーバによって検証が行われた後に、分散処理台帳への書き込み処理を行い（７０８０）、トランザクションはアクセス権限管理テーブルの１つのレコードとして追加される（７０９０）。

データ管理サーバ２０００Ｂの利用審査プログラム２４００Ｂは、利用審査が終了すると審査終了通知をデータ管理サーバ２０００Ａに送付する（７１３０）。これ以降のフローは、図７Ａのフローと同様である。

図１０Ｂに、図７Ｂのフローチャートに対応する分散共有台帳であるアクセス権限管理テーブル１００００ｂのデータ構造例を示す。アクセス権限管理テーブル１００００ｂには、利用審査依頼トランザクションと利用審査登録トランザクションの両方とその対応付けが記録される。図１０Ａと異なるカラムは、トランザクション種別カラム１００２１、親トランザクション１００２２である。カラム１００２１には、利用審査依頼トランザクションと利用審査登録トランザクションとを識別する情報が、カラム１００２２には、利用審査登録トランザクションに対応する利用審査依頼トランザクションのＴＸＩＤが登録されている。

ＴＸＩＤ「B1001」がステップ７１１０で受信された利用審査リクエストに含まれる、ある１つのオリジナルデータの利用審査依頼についてのトランザクションであり、ＴＸＩＤ「B1002」がその利用審査依頼の利用審査についてのトランザクションであるとする。この場合、ＴＸＩＤ「B1001」のカラム１００２１には、利用審査依頼トランザクションであることを示す「Ａ」が、カラム１００２２及びカラム１０００６には、利用審査依頼トランザクションであるので「－」が、カラム１０００５には、利用審査依頼時刻が登録されている。ＴＸＩＤ「B1002」のカラム１００２１には、利用審査登録トランザクションであることを示す「Ｂ」が、カラム１００２２には、対応する利用審査依頼トランザクションのＴＸＩＤ「B1001」が、カラム１０００５には、利用審査実施時刻が、カラム１０００６には、利用申請リクエストが当該データについて許諾されたことを示す「１」が登録されている。

（データ解析処理フロー）
図６のフローチャートにおけるステップ６２１０に係るデータ解析処理について説明する。図８にデータ解析処理のフロー例を示す。

データ利用者Ａのデータ管理サーバ２０００Ａから、解析処理リクエストがデータ提供者Ｂのデータ管理サーバ２０００Ｂに送信されると、解析処理プログラム２５００Ｂは、受信した解析処理リクエストに対して、解析処理を実行するために必要な項目を追加する（８０１０）。追加される項目には、例えば、処理対象となるオリジナルデータ（この例では、「東京２３区の先月のアメダス計測データ」、「関東地方の先月のＰＭ２．５計測データ」、「日本全国のこの先１か月の天気予報データ」）のデータパス、処理データのデータＩＤ、処理データの出力先とするデータパス（「処理データパス」という）、解析処理を行うデータ加工者のユーザＩＤを含む。以下の例では、データ提供者Ｂ自身が、自己のリソースであるデータ処理サーバ３０００を用いて解析処理を行うものとするが、データ加工者Ｃに依頼して解析処理を行わせることも可能である。この場合は、解析処理はデータ加工者Ｃのリソースであるデータ処理サーバを用いて行われる。

解析処理プログラム２５００Ｂは、項目が追加された解析処理リクエストをデータ処理サーバ３０００に転送し（８０２０）、データ処理サーバ３０００の解析処理プログラム３２００が当該リクエストを受信する（８１１０）。

解析処理プログラム３２００は、受信した解析処理リクエストに対してリクエストＩＤ及びタスクＩＤを割り当てる。タスクＩＤは、最終的に処理データを得るために複数のタスクを実行する必要がある場合に、各タスクに対して割り当てられるＩＤである。ステップ８１２０で発行するリクエストＩＤは本システム全体で一意のリクエストＩＤである。本実施例においては、データの登録や加工といったデータ履歴を耐改ざん性の高い証跡として分散共有台帳に記録するため、データ利用者Ａからの解析処理リクエストは分散共有台帳に記録される。このため、分散共有台帳においてリクエストＩＤが重複しないよう、リクエストＩＤは本システム全体で一意とされる必要がある。タスクＩＤはリクエストＩＤに紐づけられて設定される。

この例では、データ処理サーバ３０００は、「東京２３区の先月のアメダス計測データ（オリジナルデータ、データＩＤ：00011）」、「関東地方の先月のＰＭ２．５計測データ（オリジナルデータ、データＩＤ：00022）」、「日本全国のこの先１か月の天気予報データ（オリジナルデータ、データＩＤ：00033）」から、「翌週の東京２３区でのＰＭ２．５分布予測データ（処理データ、データＩＤ：00044）」を得るための解析処理リクエスト（リクエストＩＤ：XYZ）につき、４つのタスク（タスクＩＤ：XYZ-1～4）を実行する。

タスク１（XYZ-1）は、関東地方のデータ（00022）から東京２３区のデータ（00022-1）を抽出する。ここで、タスクごとの処理データを中間処理データといい、中間処理データのデータＩＤは、その元になったデータのデータＩＤに紐づけられて設定される。複数の元データから１つの中間処理データが得られる場合には、中間処理データのデータＩＤは、いずれか１つの元データのデータＩＤに紐づけて設定すればよい。

タスク２（XYZ-2）は、日本全国におけるこの先１か月のデータ（00033）から東京２３区における翌週のデータ（00033-1）を抽出する。

タスク３（XYZ-3）は、アメダス計測データ（00011）とＰＭ２．５計測データ（00022-1）との関係（00011-1）を解析する。

タスク４（XYZ-4）は、アメダス計測データとＰＭ２．５計測データとの関係（00011-1）と翌週の天気予報（00033-1）とに基づき、翌週のＰＭ２．５予測データ（00044）を算出する。

また、以上のタスクについて、解析処理プログラム３２００は、データ利用者Ａによって指定されたデータ処理の仕様（図６のフローチャートのステップ６０３０）に基づいて、各タスクについて計算リソースを指定する。計算リソースは、使用するソフトウェアのバージョン、パラメータを設定することで行える。このように解析処理リクエストについて設定されたタスクの内容は、データ処理サーバ３０００の処理実行管理テーブル１５０００に登録される。

図１５に処理実行管理テーブル１５０００のデータ構造例を示す。処理実行管理テーブル１５０００は、リクエストＩＤカラム１５００１、タスクＩＤカラム１５００２、親データＩＤカラム１５００３、データパス（親）カラム１５００４、子データＩＤカラム１５００５、データパス（子）カラム１５００６、利用者ＩＤカラム１５００７、提供者ＩＤカラム１５００８、加工者ＩＤカラム１５００９、利用範囲カラム１５０１０、計算リソースカラム１５０１１、処理時間カラム１５０１２を含む。カラム１５００１にはリクエストＩＤ、カラム１５００２にはタスクＩＤ、カラム１５００３には加工される元データ（親データという）のデータＩＤ、カラム１５００４には親データの保存アドレス（データパス）、カラム１５００５には加工により得られる中間処理データまたは処理データ（子データという）のデータＩＤ、カラム１５００６には子データの保存アドレス（データパス）、カラム１５００７には解析依頼者であるデータ利用者のユーザＩＤ、カラム１５００８には親データのデータ提供者のユーザＩＤ、カラム１５００９にはデータ処理を実行するデータ加工者のユーザＩＤ、カラム１５０１０には、親データの利用範囲、カラム１５０１１には設定された計算リソース、カラム１５０１２には、データ処理サーバ３０００が解析処理を実行した時間が記録される。なお、子データの保存先は、オリジナルデータの場合と同様に、データのコンテンツそのものをデータ処理サーバ３０００のストレージメディア３１５０に保存してもよく、クラウド上のオブジェクトストレージに保存してもよい。

ステップ８１３０においては、各タスクについて、それぞれカラム１５００１～１５０１１までの内容が登録される。

解析処理プログラム３２００は、親データのデータパスに示されるデータの保存アドレスにアクセスし、処理対象となるデータを取り出し（８１４０）、設定された計算リソースを用いて処理を実行し（８１５０）、得られた子データを子データのデータパスに示されるデータの保存アドレスに保存する（８１６０）。

続いて、解析処理プログラム３２００は処理実行管理テーブル１５０００のカラム１５０１２に、各タスクの解析処理を実行した時間を記録する（８１７０）。また、データ処理サーバ３０００のデータ管理テーブル１４０００’に処理データを登録する（８１８０）。データ管理テーブル１４０００’のデータ構造は図１４に示したものと同様である。レコード１４０１２は処理データについてのレコードであり、カラム１４００１には、処理データのデータＩＤが、カラム１４００３には、親データのデータＩＤ（中間処理データのデータＩＤであってもよい）が登録される。なお、カラム１４００４にはデータ加工者のユーザＩＤを登録するものとする。この例では、データ加工者であり、データ提供者Ｂでもある「100」が登録されることになるが、データ加工者Ｃが解析処理を行った場合には、データ加工者ＣのユーザＩＤが登録される。

以上で、データ処理サーバ３０００における解析処理を終了し、解析処理プログラム３２００は実行完了通知をデータ管理サーバ２０００Ｂに行う（８１９０）。この実行完了通知には、リクエストＩＤに紐づく処理実行管理テーブル１５０００のレコードが添付される。添付する処理実行管理テーブル１５０００のレコードにおいて、データパスの情報（カラム１５００４、カラム１５００６）については除いてよい。

実行完了通知後において、すべての中間処理データを保存する必要はないとしても、使用頻度が高い中間処理データあるいは、中間処理データの作成に計算リソース負荷の大きい中間処理については保存しておくことで、再利用が可能になる。保存不要と判断した中間処理データについてはデータパスから削除する。中間処理データの保存要否については、タスクごとにデータ加工者が判断する。中間処理データを保存しておくことで、別の解析処理リクエストを受けた場合において、処理実行管理テーブル１５０００を検索し、ストレージに保存された中間処理データを利用することにより、再度中間処理データを得るための計算リソースと計算時間を省略することができる。

データ管理サーバ２０００Ｂの解析処理プログラム２５００Ｂは、データ処理サーバ３０００からの実行完了通知を受信すると（８０３０）、処理データを自己のデータ管理テーブル１４０００に登録する（８０４０）。図１４に示したデータ管理テーブル１４０００のレコード１４０１２が処理データのレコードである。レコードの内容は、データ管理テーブル１４０００’と同様であるので省略する。

続いて、解析処理プログラム２５００Ｂは、解析処理リクエストの処理がなされたことを示すトランザクション（リクエスト処理ＴＸ）を作成する（８０５０）。作成されたトランザクションは、分散共有台帳を保有する他のデータ管理サーバによって検証が行われた後に、分散処理台帳への書き込み処理を行い（８０６０）、トランザクションは処理／利用証跡管理テーブルの１つのレコードとして追加される（８０７０）。

図１１に分散共有台帳である処理／利用証跡管理テーブル１１０００のデータ構造例を示す。処理／利用証跡管理テーブル１１０００は、トランザクションＩＤカラム１１００１、リクエストＩＤカラム１１００２、タスクＩＤカラム１１００３、親データＩＤカラム１１００４、子データＩＤカラム１１００５、利用者ＩＤカラム１１００６、提供者ＩＤカラム１１００７、加工者ＩＤカラム１１００８、利用範囲カラム１１００９、計算リソースカラム１１０１０、処理時間カラム１１０１１、生成データ形式カラム１１０１２、トランザクション時刻カラム１１０１３、提供者署名カラム１１０１４、検証時刻カラム１１０１５、検証者署名カラム１１０１６を含む。カラム１１００２～１１０１１には、実行完了通知に添付された処理実行管理テーブル１５０００のレコードの該当カラムの内容が登録される。カラム１１０１２には、タスクで得られた子データのデータ形式が登録されている。カラム１１０１３～１１０１６には、トランザクションの検証情報が登録されている。

続いて、解析処理プログラム２５００Ｂは、解析処理リクエストによって得られた処理データのシステムへの登録がなされたことを示すトランザクション（メタデータ登録ＴＸ）を作成する。作成されたトランザクションは、分散共有台帳を保有する他のデータ管理サーバによって検証が行われた後に、分散処理台帳への書き込み処理を行い、トランザクションはメタデータ管理テーブルの１つのレコードとして追加される（８０８０）。

図１２に示したメタデータ管理テーブル１２０００のＴＸＩＤ「C2001」のレコードが処理データのレコードである。処理データであるので、カラム１２００６にはデータ利用者Ａの署名が含まれている。処理データについてもメタデータ管理テーブル１２０００に登録されることにより、処理データについてもオリジナルデータと同様に、データ利活用システムにおいて利用可能となる。

以上により、解析処理プログラム２５００Ｂの処理が終了し、上述のように、データ管理サーバ２０００Ｂのリクエスト対応プログラム２３００Ｂは、解析処理によって得られた処理データをデータ利用者Ａに提供する（６２２０）。

（課金処理フロー）
図６のフローチャートにおけるステップ６２４０に係る課金処理について説明する。図９に課金処理のフロー例を示す。

データ管理サーバ２０００Ｂの課金プログラム２６００Ｂは、データ利活用に伴う課金についてのトランザクション（課金ＴＸ）を作成する（９０１０）。作成されたトランザクションは、分散共有台帳を保有する他のデータ管理サーバによって検証が行われた後に、分散処理台帳への書き込み処理を行い（９０２０）、トランザクションは課金テーブルの１つのレコードとして追加される（９０３０）。課金トランザクションが確定後、確定したトランザクションに規定される所定の通貨量が取引される。

図１３に分散共有台帳である課金テーブル１３０００のデータ構造例を示す。課金テーブル１３０００は、トランザクションＩＤカラム１３００１、請求元ＩＤカラム１３００２、請求先ＩＤカラム１３００３、対象トランザクションＩＤカラム１３００４、通貨量カラム１３００５、トランザクション時刻カラム１３００６、利用者署名カラム１３００７、提供者署名カラム１３００８、検証時刻カラム１３００９、検証者署名カラム１３０１０を含む。

例えば、例として説明した処理データの提供がＴＸＩＤ「D1001」のレコードとして記録されているとすると、カラム１３００２にはデータ提供者ＢのユーザＩＤ「100」が、カラム１３００３にはデータ利用者ＡのユーザＩＤ「200」が記録され、処理データの提供についての請求額が通貨量1500であったことが分かる。また、ＴＸＩＤ「D1003」のレコードのように請求元に複数の主体が存在する場合には、通貨量を寄与率により分配すればよい。寄与率は、オリジナルデータのデータ量や処理に使用した計算リソース量に応じて、複数の請求元間で取り決めればよい。

以上説明した実施例は、本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、多様な変更を加え、種々の形態で実施することが可能である。

１０００：端末、１１００：ネットワーク、１２００：共通ネットワーク、２０００：データ管理サーバ、３０００：データ処理サーバ、４０００：クライアントサーバ、２１２０，３１２０，４１２０：プロセッサ、２１３０，３１３０，４１３０：入出力デバイス、２１４０，３１４０，４１４０：メモリ、２１５０，３１５０，４１５０：ストレージメディア、２１６０，３１６０，４１６０：ネットワークインタフェース、２１７０，３１７０，４１７０：バス、２２００：データ登録プログラム、２３００：リクエスト対応プログラム、２４００：利用審査プログラム、２５００：解析処理プログラム、２６００：課金プログラム、３２００：解析処理プログラム、４２００：データ登録プログラム、４３００：リクエスト対応プログラム、１００００：アクセス権限管理テーブル、１１０００：処理／利用証跡管理テーブル、１２０００：メタデータ管理テーブル、１３０００：課金テーブル、１４０００，１４０００’：データ管理テーブル、１５０００：処理実行管理テーブル。

Claims

ネットワークに接続され、第１のユーザの第１のデータ管理サーバ及び第２のユーザの第２のデータ管理サーバを含む複数のデータ管理サーバとデータ処理サーバとを有するデータ利活用システムにおけるデータ提供方法であって、
前記複数のデータ管理サーバはそれぞれ、分散共有台帳を保持しており、
前記第１のデータ管理サーバは、データ登録プログラムを実行することにより、第１データをストレージに保存するとともに、前記第１データが保存されたことを示す第１のトランザクションを作成し、検証された前記第１のトランザクションを前記分散共有台帳の一つであるメタデータ管理テーブルのレコードとして追加し、
前記第２のデータ管理サーバは、前記第１データを処理する解析処理リクエストを前記第１のデータ管理サーバに送信し、
前記第１のデータ管理サーバは、前記解析処理リクエストを受けて解析処理プログラムを実行することにより、前記解析処理リクエストを前記データ処理サーバに転送して前記第１データを処理して得られた第２データをストレージに保存させるとともに、前記データ処理サーバから前記第１データの処理完了通知を受けて、前記解析処理リクエストにしたがって前記第１データを処理したことを示す第２のトランザクションを作成し、検証された前記第２のトランザクションを前記分散共有台帳の一つである処理／利用証跡管理テーブルのレコードとして追加するデータ提供方法。
請求項１において、
前記第１のデータ管理サーバは、前記解析処理プログラムを実行することにより、前記第２データがストレージに保存されたことを示す第３のトランザクションを作成し、検証された前記第３のトランザクションを前記メタデータ管理テーブルのレコードとして追加するデータ提供方法。
請求項２において、
前記第１のデータ管理サーバは、検証された前記第２のトランザクションが前記処理／利用証跡管理テーブルに追加され、検証された前記第３のトランザクションが前記メタデータ管理テーブルに追加された後、前記第１のデータ管理サーバは前記第２のデータ管理サーバに前記第２データを提供するデータ提供方法。
請求項１において、
前記メタデータ管理テーブルは、ストレージに保存される保存データを特定するデータＩＤ、前記保存データの提供者を特定する提供者ＩＤ、前記保存データの概要を示すメタデータ、及びトランザクションの検証情報を含み、
前記データＩＤは、データ利活用システムにおいて一意に割り当てられており、
前記メタデータは、前記保存データのデータ形式に応じて定められるデータ提供方法。
請求項１において、
前記処理／利用証跡管理テーブルは、被処理データを処理して処理データを得る解析処理リクエストを特定するリクエストＩＤ、前記被処理データを特定する親データＩＤ、前記処理データを特定する子データＩＤ、前記解析処理リクエストの依頼者を特定する利用者ＩＤ、前記被処理データの提供者を特定する提供者ＩＤ、前記被処理データを処理する加工者ＩＤ、前記被処理データの処理に使用する計算リソース、前記被処理データの処理を行った時間、及びトランザクションの検証情報を含み、
前記リクエストＩＤは、データ利活用システムにおいて一意に割り当てられているデータ提供方法。
請求項１において、
前記データ処理サーバは、前記第１のデータ管理サーバから前記解析処理リクエストの転送を受けて、前記第１データの処理を複数のタスクに分けて実行し、前記タスクの実行により得られる中間処理データをストレージに保存し、前記第１データの処理についての情報を処理実行管理テーブルに保存し、
前記処理実行管理テーブルは、前記解析処理リクエストを特定するリクエストＩＤ、前記タスクを特定するタスクＩＤ、前記タスクの被処理データを特定する親データＩＤ、前記中間処理データを特定する子データＩＤ、前記中間処理データの保存アドレスを示すデータパス、前記解析処理リクエストの依頼者を特定する利用者ＩＤ、前記被処理データの提供者を特定する提供者ＩＤ、前記被処理データを処理する加工者ＩＤ、前記被処理データの処理に使用する計算リソース、前記被処理データの処理を行った時間を含み、
前記リクエストＩＤは、データ利活用システムにおいて一意に割り当てられ、前記タスクＩＤは前記リクエストＩＤに紐づけられて割り当てられるデータ提供方法。
請求項６において、
前記データ処理サーバは、前記第１のデータ管理サーバから前記解析処理リクエストとは別の解析処理リクエストの転送を受けて、前記別の解析処理リクエストにしたがって前記被処理データを処理するとき、前記処理実行管理テーブルを検索し、ストレージに保存された前記解析処理リクエストの前記中間処理データを利用するデータ提供方法。
請求項１において、
前記第２のデータ管理サーバは、前記第２のユーザからの前記第２データのデータリクエストを受けて、前記メタデータ管理テーブルを検索して前記第２データを得るために必要な前記第１データを特定し、
前記第２のデータ管理サーバは、利用審査プログラムを実行することにより、前記第１データの利用審査リクエストを前記第１のデータ管理サーバに送信するとともに、前記第１のデータ管理サーバからの審査終了通知を受けて、前記第１データについて利用審査がなされたことを示す第４のトランザクションを作成し、検証された前記第４のトランザクションを前記分散共有台帳の一つであるアクセス権限管理テーブルのレコードとして追加するデータ提供方法。
請求項８において、
前記第４のトランザクションは、前記第１データを特定するデータＩＤ、前記第２のユーザを特定する利用者ＩＤ、前記第１のユーザを特定する提供者ＩＤ、前記利用審査リクエストの審査が行われた審査実施時刻、及び前記第１データの前記第２のユーザへの利用許否を示すステータスを含むデータ提供方法。
請求項９において、
前記第２のデータ管理サーバは、前記利用審査プログラムを実行することにより、前記第１のデータ管理サーバからの審査依頼受理通知を受けて、前記第１データについて利用審査依頼が受理されたことを示す第５のトランザクションを作成し、検証された前記第５のトランザクションを前記アクセス権限管理テーブルのレコードとして追加するデータ提供方法。
請求項１０において、
前記第５のトランザクションは、前記第１データを特定するデータＩＤ、前記第２のユーザを特定する利用者ＩＤ、前記第１のユーザを特定する提供者ＩＤ、及び前記利用審査リクエストが受理された審査依頼時刻を含むデータ提供方法。
請求項１１において、
前記アクセス権限管理テーブルは、前記第４のトランザクションと前記第４のトランザクションの検証情報、前記第５のトランザクションと前記第５のトランザクションの検証情報、及び前記第４のトランザクションと前記第５のトランザクションとの対応付けを含むデータ提供方法。
請求項８において、
前記第１データの利用審査リクエストにおいて、前記第１データを処理するための計算リソースが前記第２のユーザにより指定されているデータ提供方法。
請求項３において、
前記第１のデータ管理サーバは、前記第１のデータ管理サーバに前記第２データを提供した後、課金プログラムを実行することにより、前記第２データの提供についての課金を示す第６のトランザクションを作成し、検証された前記第６のトランザクションを前記分散共有台帳の一つである課金テーブルのレコードとして追加するデータ提供方法。
請求項１４において、
前記課金テーブルは、課金の請求元を特定する請求元ＩＤ、課金の請求先を特定する請求先ＩＤ、課金の対象を特定する対象トランザクションＩＤ、請求額を示す通貨量、及びトランザクションの検証情報を含むデータ提供方法。