特許 6687798 データ管理システムおよびデータ管理方法

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

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

(11)【特許番号】6687798

(24)【登録日】2020年4月6日

(45)【発行日】2020年4月28日

(54)【発明の名称】データ管理システムおよびデータ管理方法

(51)【国際特許分類】

   G06F 16/182 20190101AFI20200421BHJP

   G06F 21/64 20130101ALI20200421BHJP

【ＦＩ】

   G06F16/182

   G06F21/64

【請求項の数】7

【全頁数】23

(21)【出願番号】特願2019-181715(P2019-181715)

(22)【出願日】2019年10月1日

【審査請求日】2019年10月3日

【早期審査対象出願】

(73)【特許権者】

【識別番号】519355529

【氏名又は名称】データテック株式会社

(74)【代理人】

【識別番号】100098729

【弁理士】

【氏名又は名称】重信 和男

(74)【代理人】

【識別番号】100163212

【弁理士】

【氏名又は名称】溝渕 良一

(74)【代理人】

【識別番号】100204467

【弁理士】

【氏名又は名称】石川 好文

(74)【代理人】

【識別番号】100148161

【弁理士】

【氏名又は名称】秋庭 英樹

(74)【代理人】

【識別番号】100156535

【弁理士】

【氏名又は名称】堅田 多恵子

(74)【代理人】

【識別番号】100195833

【弁理士】

【氏名又は名称】林 道広

(72)【発明者】

【氏名】佐々木 隆仁

(72)【発明者】

【氏名】志田 大輔

【審査官】 西村 直史

(56)【参考文献】

【文献】 特開２０１８−１３６６６２（ＪＰ，Ａ）

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

【文献】 米国特許出願公開第２０１８／０１１４２６１（ＵＳ，Ａ１）

【文献】 特表２０２０−５００４８７（ＪＰ，Ａ）

【文献】 特許第６５２１１７０（ＪＰ，Ｂ１）

【文献】 特開２０１８−１３２９３１（ＪＰ，Ａ）

【文献】 特開２０１９−９７６７（ＪＰ，Ａ）

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

Ｇ０６Ｆ １６／００−１６／９５８

Ｇ０６Ｆ ２１／６４

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

【請求項1】

一連の複数ファイルを関連付けて参照可能に保管するデータ管理システムであって、
複数のファイルのそれぞれを受付ける受付手段と、
前記受付手段で受付けた複数のファイルを、プラットフォームの異なる第１ブロックチェーンと第２ブロックチェーンとに振り分けて記録させる振分記録手段と、
各ブロックチェーンから記録の際に取得した各ハッシュ値を、各ファイルを特定する特定情報に関連付けて保管する保管手段と、を備えることを特徴とするデータ管理システム。

【請求項2】

前記振分記録手段における複数のファイルを各ブロックチェーンに振り分ける振分け条件を設定する設定手段を備えることを特徴とする請求項１に記載のデータ管理システム。

【請求項3】

前記振分記録手段は、振分け条件として、所定の指示をユーザから受付けたことに基づき、前記受付手段で受付けたファイルを前記第２ブロックチェーンに振分けることを特徴とする請求項１または２に記載のデータ管理システム。

【請求項4】

前記振分記録手段は、振分け条件として、所定の指示を受付けた場合は、前記受付手段で受付けたファイルを前記第２ブロックチェーンに加えて前記第１ブロックチェーンにも記録させることを特徴とする請求項３に記載のデータ管理システム。

【請求項5】

前記複数のファイルは、過程版の契約書ファイルと最終版ファイルの契約書を含み、
前記振分記録手段は、前記過程版の契約書ファイルを、第１ブロックチェーンに振り分け、前記最終版の契約書ファイルを、第２ブロックチェーンに振り分けて記録させることを特徴とする請求項１ないし４のいずれかに記載のデータ管理システム。

【請求項6】

ユーザがアクセスして前記複数のファイルの参照と該複数のファイルのうち１のファイルの承認作業を行うことができるウェブページを提供し、前記ブロックチェーン上へ前記１のファイルが記録されると、当該ブロックチェーンから返されたハッシュ値を前記ウェブページ上に表示するサービスサーバを備えることを特徴とする請求項１ないし５のいずれかに記載のデータ管理システム。

【請求項7】

一連の複数ファイルを関連付けて参照可能に保管するデータ管理方法であって、
複数のファイルのそれぞれを受付けるステップと、
受付けた複数のファイルを、プラットフォームの異なる第１ブロックチェーンと第２ブロックチェーンとに振り分けて記録させるステップと、
各ブロックチェーンから記録の際に取得した各ハッシュ値を、各ファイルを特定する特定情報に関連付けて保管するステップと、
を有することを特徴とするデータ管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一連の複数ファイルを関連付けて参照可能に保管するデータ管理システムおよびデータ管理方法に関する。

【背景技術】

【0002】

従来から、様々な業態において一連の業務等記録が紙媒体でファイリングされて利用されており、例えば、医療機関では個人の診療録、金融機関では顧客の取引記録や取引履歴、法律関係機関では判例や契約書、メーカーでは製品の真贋証明等の業務等記録が時系列毎にファイリングされて保管されている。このような業務等記録は、後で参照可能に時系列毎に一連の情報として管理されており、個人単位や事件単位で履歴の参照や比較に用いられ、以降の診察や取引、真贋の判断等に役立ててられている。近年では、これらの業務記録等はコンピュータ等で入力された電子データ化されファイルとして、サーバ等の記憶媒体に集中管理方式にて保管されている。また、企業間や個人間で行われる契約書についても、紙媒体から電子契約に移行され始めており、電子データ化されたファイルとしてサーバ等の記憶媒体に保管されている。

【0003】

近年では、このような電子データ化されたファイルをサーバ等の記憶媒体に集中管理方式にて保管・管理するのに代えてブロックチェーンのような分散型のデータ管理システムを利用したサービスがある。ブロックチェーンは、その性質上、高い改竄防止機能を備えており、厳格な信頼性が求められるような上述したファイルの保管に適しており、近年注目を集めている。電子契約にブロックチェーンを用いた場合を例に取ると、両者間で取り交わされる契約書は、双方の確認作業の過程で改編が行われることが多く、作成された複数の版の契約書（一連の複数ファイル）をブロックチェーンに記録することになる（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】再表２０１７／１０４５５号公報（第９頁、第１図）

【発明の概要】

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

【0005】

ブロックチェーンは多種多様なプラットフォームで構成されており、それぞれに長所と短所がある。例えば、ブロックチェーンを用いたサービスの開発者に広く利用されているＥｔｈｅｒｅｕｍは、利用者数が多いため、ネットワークや動作の安定性に優れているという長所を備える一方で、トランザクションの承認態様や利用者が多数であることなどが要因して、トランザクションの承認に時間を要し、かつ承認にかかる手数料が高額であるという短所がある。また、ブロックチェーンの一つであるＥＯＳにあっては、トランザクションの承認態様や利用者が比較的少ないことが要因して承認時間が短く、かつ承認にかかる手数料が低額であるという長所を備える一方で、Ｅｔｈｅｒｅｕｍと比較してネットワークや動作の安定性の信頼度に欠けるという問題がある。このように、ひとえにブロックチェーンといっても、それぞれのプラットフォームに特徴が異なり、サービスの開発者は、短所を承知の上で択一的に選択する必要があり、ブロックチェーン上に一連のファイルを記録する際の承認に要する時間と安定性とを両立させることはできなかった。

【0006】

本発明は、このような問題点に着目してなされたもので、ブロックチェーン上に一連のファイルを記録する際の承認に要する時間と安定性とを両立しながら、一連のファイルを関連付けて参照可能に保管できるデータ管理システムおよびデータ管理方法を提供することを目的とする。

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

【0007】

前記課題を解決するために、本発明のデータ管理システムは、
一連の複数ファイルを関連付けて参照可能に保管するデータ管理システムであって、
複数のファイルのそれぞれを受付ける受付手段と、
前記受付手段で受付けた複数のファイルを、プラットフォームの異なる第１ブロックチェーンと第２ブロックチェーンとに振り分けて記録させる振分記録手段と、
各ブロックチェーンから記録の際に取得した各ハッシュ値を、各ファイルを特定する特定情報に関連付けて保管する保管手段と、
を備えることを特徴としている。
この特徴によれば、データ管理システムは、受け付けた複数のファイルを必要に応じて複数のブロックチェーンに振り分けて記録させる構成であるため、例えば最終版のファイルをネットワークや動作の安定性に優れるプラットフォームの第２ブロックチェーンに記録し、それ以外の過程版のファイルを承認時間が短く、かつ承認にかかる手数料が低額であるという長所を備えるプラットフォームの第１ブロックチェーンに記録させることができ、ブロックチェーン上にファイルを記録する際の承認に要する時間と安定性とを両立しながら、一連のファイルを関連付けて参照可能に保管することができる。

【0008】

前記振分記録手段における複数のファイルを各ブロックチェーンに振り分ける振分け条件を設定する設定手段を備えることを特徴としている。
この特徴によれば、設定手段で振分け条件を任意に設定することができるため、例えば、最終版のファイルのみをネットワークや動作の安定性に優れる第１プラットフォームのブロックチェーンに振分けて記録させるように設定しておき、他のファイルについては、承認時間が短く、かつ承認にかかる手数料が低額であるという長所を備えるプラットフォームの第２ブロックチェーンに振分けて記録させるようにすることができ、状況に応じた振分け条件を設定することができる。

【0009】

前記振分記録手段は、振分け条件として、所定の指示をユーザから受付けたことに基づき、前記受付手段で受付けたファイルを前記第２ブロックチェーンに振分けることを特徴としている。
この特徴によれば、所定の指示を受付けたことに基づき、ファイルの記録先を振分け条件により自動的に決定して振り分けするため、人為的なミスを防止でき、確実に所望のブロックチェーン上にファイルを記録させることができ、かつ記録の際の承認に要する時間と安定性とを両立できる。また、所定の指示を受付けた際のファイルは所定の第２プラットフォームのブロックチェーン上に統一して記録されるため、後に参照する際にデータ管理が容易となる。

【0010】

前記振分記録手段は、振分け条件として、所定の指示を受付けた場合は、前記受付手段で受付けたファイルを前記第２ブロックチェーンに加えて前記第１ブロックチェーンにも記録させることを特徴としている。
この特徴によれば、所定の指示を受付けた際のファイルは、第１ブロックチェーンと第２ブロックチェーンの双方に記録されるため、当該ファイルの破損による滅失の虞が少なくかつ参照の際のアクセス先が複数選択可能となる。

【0011】

前記複数のファイルは、過程版の契約書ファイルと最終版ファイルの契約書を含み、
前記振分記録手段は、前記過程版の契約書ファイルを、第１ブロックチェーンに振り分け、前記最終版の契約書ファイルを、第２ブロックチェーンに振り分けて記録させることを特徴としている。
この特徴によれば、契約書ファイルは複数の担当者により条項等の内容が検討され、最終版に至るまでに複数の版が形成されることが多く、このような過程版の契約書ファイルについては、承認時間が短く、かつ承認にかかる手数料が低額であるという長所を備えるプラットフォームのブロックチェーンに記録させ、最終版の契約書ファイルのみをネットワークや動作の安定性に優れるプラットフォームのブロックチェーンに記録させることで、承認に要する時間と安定性とを両立しやすい。

【0012】

ユーザがアクセスして前記複数のファイルの参照と該複数のファイルのうち１のファイルの承認作業を行うことができるウェブページを提供し、前記ブロックチェーン上へ前記１のファイルが記録されると、当該ブロックチェーンから返されたハッシュ値を前記ウェブページ上に表示するサービスサーバを備えることを特徴としている。
この特徴によれば、ブロックチェーン上にファイルの記録が完了したことをユーザ自身が確認することができ、データ管理システムの信頼度を高めることができる。

【0013】

前記課題を解決するために、本発明のデータ管理方法は、
一連の複数ファイルを関連付けて参照可能に保管するデータ管理方法であって、
複数のファイルのそれぞれを受付けるステップと、
受付けた複数のファイルを、プラットフォームの異なる第１ブロックチェーンと第２ブロックチェーンとに振り分けて記録させるステップと、
各ブロックチェーンから記録の際に取得した各ハッシュ値を、各ファイルを特定する特定情報に関連付けて保管するステップと、
を有することを特徴としている。
この特徴によれば、データ管理システムは、受け付けた複数のファイルを必要に応じて複数のブロックチェーンに振り分け、例えば、最終的なバージョンのファイルをネットワークや動作の安定性に優れるプラットフォームのブロックチェーンに記録し、それ以外の過程版の証明データを承認時間が短く、かつ承認にかかる手数料が低額であるという長所を備えるプラットフォームのブロックチェーンに記録させることができ、ブロックチェーン上にファイルを記録する際の承認に要する時間と安定性とを両立しながら、一連のファイルを関連付けて参照可能に保管することができる。

【図面の簡単な説明】

【0014】

【図1】本発明の実施例におけるデータ管理システムおよびデータ管理方法を構成するネットワークを示す概念図である。

【図2】パソコンに表示される初期画面を示す図である。

【図3】同じくユーザーページを示す図である。

【図4】同じく契約書作成画面を示す図である。

【図5】同じく契約書作成画面に表示された本文入力表示を示す図である。

【図6】同じく暗号化キー入力画面を示す図である。

【図7】同じく契約書作成画面に表示された暗号化完了表示を示す図である。

【図8】同じく契約参加者追加画面を示す図である。

【図9】同じく契約参加者追加画面に一覧表示された契約参加者を示す図である。

【図10】同じくＥＯＳブロックチェーンへの記録の進捗状況を示す図であり、（ａ）は記録の進捗を示すポップアップ表示を示す図であり、（ｂ）は記録が完了した状態を示す図である。

【図11】契約参加者が受信した招待メールを示す図である。

【図12】パソコンに表示されるアクセスコード確認画面を示す図である。

【図13】同じく自社内の契約参加者向けの契約書確認画面に表示された暗号化キーの入力を促す表示を示す図である。

【図14】同じく自社内の契約参加者向けの契約書確認画面に契約書ファイルのテキストデータが表示された状態を示す図である。

【図15】同じく相手の契約参加者向けの契約書確認画面を示す図である。

【図16】同じく相手の契約参加者向けの契約書確認画面に、作成された複数の契約書ファイルの一覧表示が表示された状態を示す図である。

【図17】同じく契約書確認要請画面を示す図である。

【図18】同じく自社内の契約参加者向けの契約書承認画面を示す図である。

【図19】同じく相手の契約参加者向けの契約書承認画面を示す図である。

【図20】同じくＥｔｈｅｒｅｕｍのブロックチェーンに記録する際の進捗状況を示す図である。

【図21】同じく担当者である自社内の契約参加者向けの契約書確認画面に表示される締結完了表示を示す図である。

【図22】契約書確認処理を示すフローチャートである。

【図23】契約書承認処理を示すフローチャートである。

【図24】最終版記録処理を示すフローチャートである。

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

【0015】

本発明に係るデータ管理システムおよびデータ管理方法を実施するための形態を実施例に基づいて以下に説明する。

【実施例】

【0016】

実施例に係るデータ管理システムおよびデータ管理方法につき、図１から図２４を参照して説明する。

【0017】

データ管理システムは、様々な業態においてサービスの提供者と被提供者間でのやり取り、例えば、医療機関では個人の診療録、金融機関では顧客の取引記録や取引履歴、法律関係機関では判例や遺言や不動産取引等の法務に関わる契約書類、メーカーでは製品の真贋証明、の管理資料が電子データ化され、後に参照できるようにサーバで管理するシステムである。本実施例では、契約書類を管理することを例に取り説明する。本実施例におけるデータ管理システムでは、契約書類作成の主体となるクライアント（以下、「自社」ともいう。）と、その契約書類による契約の相手方のクライアント（以下、「相手」という。）とが、後述するサービスサーバ１のＡＰＩサーバ７を介して、契約書ファイルを適宜更新していくことができる。その際の過程版の契約書ファイルと、最終的に締結される最終版の契約書ファイルとは、プラットフォームの異なる第１ブロックチェーン（例えばＥＯＳ）と第２ブロックチェーン（例えばＥｔｈｅｒｅｕｍ）とに振り分けて記録され、各ブロックチェーンから記録の際に取得した各ハッシュ値を、各契約書ファイルを特定する特定情報に関連付けて保管することで、一連の契約書ファイルとして保管・管理される。例えば、自社内において、契約書の素案を担当者が作成し、作成した契約書の第１版として保管された後に、自社内の上司が契約書の第１版を閲覧後、必要に応じて修正して修正版がその都度保管され、その後上司により承認された契約書が承認版として保管される。また、相手方の担当者や上司によっても修正されて修正版がその都度保管され、その後上司により承認された契約書が承認版として保管される。ここまでの契約書ファイルは、第１ブロックチェーン（例えばＥＯＳ）に保管され、最終的に両者で承認を得たことにより所定の指示を受付けると最終版の契約書は第２ブロックチェーン（例えばＥｔｈｅｒｅｕｍ）に保管される。

【0018】

図１は、本発明のデータ管理システムに係る実施形態を実現するためのシステム及びネットワークを示し、符号１は管理会社（管理者）がデータ管理システムを提供するためのサービスサーバであり、符号２はクライアント及び出力手段としてのパーソナルコンピュータ（以下「パソコン」と略称する）、であり、これらはインターネットを通じて相互通信可能に接続されている。パソコン２には、入力手段としてのスキャナー３、キーボード４、マウス５等がそれぞれ接続されている。その他、入力手段としてはペンタブレットとスタイラスペン等も利用できる。

【0019】

サービスサーバ１は、ＡＰＩ（Application Program Interface）サーバ７と利用者管理サーバ８と処理サーバ９がネットワークで接続されて構成されており、クライアント側のパソコン２から契約書類にかかるファイルを受信し、このファイルの管理を行う。また、サービスサーバ１は、契約書類にかかるファイルを、後述するブロックチェーンプラットフォームの動作環境及び分散型ファイルシステムの動作環境である複数のコンピュータ群２０，２１，２２に対して記録させる構成となっている。

【0020】

ブロックチェーンプラットフォームの動作環境及び分散型ファイルシステムの動作環境である複数のコンピュータ群２０，２１，２２のうち、コンピュータ群２０はＩＰＦＳ（Inter Planetary File System）なる分散型ファイルシステムを構成する分散サーバとしてのノードである。コンピュータ群２１は、ＥＯＳなるプラットフォームのブロックチェーンのブロックを生成する複数のノードであり、分散型ファイルシステムを構成する分散サーバとしてのノードでもある。コンピュータ群２２は、Ｅｔｈｅｒｅｕｍなるプラットフォームのブロックチェーンのブロックを生成する複数のノードであり、分散型ファイルシステムを構成する分散サーバとしてのノードでもある。

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

１ サービスサーバ
２ パソコン
７ ＡＰＩサーバ
８ 利用者管理サーバ
９ 処理サーバ
１０ 初期画面
１４ ユーザーページ
１９ 通知アイコン
１９ａ 通知ウィンドウ
２０，２１，２２ コンピュータ群
２５ 契約書作成画面
３０ エディタ
３３ ステータス表示
３７ 暗号化キー入力画面
４１ 契約参加者追加画面
４６ 生成ボタン
４８ メール送信ボタン
４９ 記録ボタン
５１ 招待メール
５２ ＥＯＳハッシュ値
５４ アクセスコード確認画面
５８，７０ 契約書確認画面
７４ コメントボタン
７５ 契約書バージョン表示
７６ 一覧表示
７８ 契約書確認要請画面
８０ アクションボタン
８１ 確認完了ボタン
８２，８６ 契約書承認画面
８３，８７ 署名領域
８４，８８ 印章領域
８５，８９ 承認完了ボタン
９０ 記録進捗画面
９２ 締結完了表示
９３ Ｅｔｈｅｒｅｕｍハッシュ値
９４ ＥＯＳハッシュ値
９５ バージョン表示

【要約】

【課題】ブロックチェーン上に一連のファイルを記録する際の承認に要する時間と安定性とを両立しながら、一連のファイルを関連付けて参照可能に保管できるデータ管理システムおよびデータ管理方法を提供する。
【解決手段】一連の複数ファイルを関連付けて参照可能に保管するデータ管理システムであって、複数のファイルのそれぞれを受付ける受付手段と、受付手段で受付けた複数のファイルを、プラットフォームの異なる第１ブロックチェーンと第２ブロックチェーンとに振り分けて記録させる振分記録手段と、各ブロックチェーンから記録の際に取得した各ハッシュ値を、各ファイルを特定する特定情報に関連付けて保管する保管手段と、を備える。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】