(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-12-02
(45)【発行日】2022-12-12
(54)【発明の名称】データ管理システム
(51)【国際特許分類】
G06F 21/62 20130101AFI20221205BHJP
G06F 16/00 20190101ALI20221205BHJP
H04L 9/32 20060101ALI20221205BHJP
G06F 21/64 20130101ALI20221205BHJP
【FI】
G06F21/62 345
G06F16/00
H04L9/32 200Z
G06F21/64
(21)【出願番号】P 2018220141
(22)【出願日】2018-11-26
【審査請求日】2021-05-20
【前置審査】
(73)【特許権者】
【識別番号】517307061
【氏名又は名称】リーガルテック株式会社
(74)【代理人】
【識別番号】100098729
【氏名又は名称】重信 和男
(74)【代理人】
【識別番号】100204467
【氏名又は名称】石川 好文
(74)【代理人】
【識別番号】100148161
【氏名又は名称】秋庭 英樹
(74)【代理人】
【識別番号】100195833
【氏名又は名称】林 道広
(72)【発明者】
【氏名】佐々木 隆仁
(72)【発明者】
【氏名】志田 大輔
【審査官】小林 秀和
(56)【参考文献】
【文献】特開2017-195627(JP,A)
【文献】特開2018-156293(JP,A)
【文献】特開2007-257527(JP,A)
【文献】特開2015-130010(JP,A)
【文献】特開2018-133080(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 21/62
G06F 16/00
H04L 9/32
G06F 21/64
(57)【特許請求の範囲】
【請求項1】
受付けた入力データ
のうちのテキストデータを
、項目ごとに
該項目を示す文字データを含むタグで
挟んでタグ分けされた形式で表示させ、該
テキストデータのうちの一部の
文字データであって、秘匿を所望するキーデータの選択を促す選択手段と、
前記選択手段により選択された
前記タグで挟まれた項目の
文字データであるキーデータを暗号化した文字列に変換する秘匿化手段と、
前記秘匿化手段により
前記入力データのうちの暗号化された文字列と
、前記入力データのうちの暗号化されていない
文字データと
、これら文字列および前記文字データに対応する項目を示す暗号化されていない文字データを含む前記タグを配し
てブロックチェーン上に保管させる保管指示手段と、
を備えることを特徴とするデータ管理システム。
【請求項2】
データ管理システムを提供するインターネット上のサービスサーバを備え、前記サービスサーバは、前記入力データの秘匿化されたキーデータを復号させる復号情報とユーザ識別情報とを対応付けて保持可能であり、
前記ユーザ識別情報に基づいて、ブロックチェーン上に保管されている入力データの秘匿化されているキーデータを復号させて出力可能な出力手段を備えることを特徴とする請求項1に記載のデータ管理システム。
【請求項3】
前記選択手段により選択された入力データに含まれる文字列であるキーデータ
をタグ分けした暗号化されていない文字データを含む前記タグに対して、秘匿化されていることを示すタグを付与可能であることを特徴とする請求項1または2に記載のデータ管理システム。
【請求項4】
入力データに含まれる
文字データに対して所定の付与条件に基づいて
文字データを含むタグを付与する付与手段を備え、前記選択手段では、前記付与手段により付与されタグ
の文字データを
暗号化可能とされるキーデータとして選択できることを特徴とする請求項1ないし3のいずれかに記載のデータ管理システム。
【請求項5】
前記入力データ内にイメージデータとテキストデータとがいずれも含まれているか否かを判定する判定手段と、
前記判定手段の判定に基づき、前記イメージデータを抽出し保管サーバに保管させるイメージ保管指示手段と、を備え、
前記保管指示手段は、前記イメージデータの保管に関する関連データを前記テキストデータと対応付けてブロックチェーン上に保管させるようになっており、
前記選択手段では、前記イメージデータをキーデータとして選択できることを特徴とする請求項1ないし4のいずれかに記載のデータ管理システム。
【請求項6】
前記入力データ内にイメージデータとテキストデータとがいずれも含まれているか否かを判定する判定手段と、
前記判定手段の判定に基づき、前記イメージデータを抽出し保管サーバに保管させるイメージ保管指示手段と、を備え、
前記保管指示手段は、前記イメージデータの保管に関する関連データを前記テキストデータと統合してブロックチェーン上に保管させるようになっており、
前記選択手段では、前記イメージデータの保管に関する関連データをキーデータとして選択できることを特徴とする請求項1ないし4のいずれかに記載のデータ管理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、入力データを解析可能に保管するデータ管理システムおよびデータ管理方法に関する。
【背景技術】
【0002】
従来から、様々な業態においてサービスの提供者と被提供者間でのやり取り、例えば、医療機関では個人の診療録、金融機関では顧客の取引記録や取引履歴、法律関係機関では判例等が管理されている。このような管理資料は、後に参照可能に管理されており、個人単位や事件単位で履歴の参照や比較に用い、以降の診察や取引、裁判等に役立ててられている。近年では、これらの管理資料はコンピュータ等で入力されて電子データ化され、RDB形式でサーバ等の記憶媒体に集中管理方式にて保管されている。
【0003】
また近年では、取引記録である入力データの改竄を防ぎやすい、例えばブロックチェーンのような分散型のデータ管理システムが現れている。このように高い改竄防止機能を備えたブロックチェーン上には、仮想通貨の取引記録以外の入力データも保管することができる。例えば、特許文献1では、取引記録である入力データをブロックチェーン上に保管することが提案されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2018-515833号公報(段落0006、第1図)
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献1のデータ保管サーバは、入力データをブロックチェーン上に保管し、これらの入力データの承認を複数のノードで行うことで、当該入力データの信憑性を保障可能としている。その一方で、複数のノードで入力データの承認を行うということは、入力データを入力した本人以外も、この入力データにアクセスし、その内容を閲覧可能となってしまう。そのため、例えば患者の診療録や契約情報のように、入力データの一部に個人情報等が含まれるような場合には、このようなブロックチェーン上に入力データを保管する管理システムの利用が適さないという問題があった。
【0006】
本発明は、このような問題点に着目してなされたもので、入力データをブロックチェーン上に保管するシステムにおいて、入力データのうち、所望する一部の内容を秘匿することができるデータ管理システムおよびデータ管理方法を提供することを目的とする。
【課題を解決するための手段】
【0007】
前記課題を解決するために、本発明のデータ管理システムは、
受付けた入力データのうちのテキストデータを、項目ごとに該項目を示す文字データを含むタグで挟んでタグ分けされた形式で表示させ、該テキストデータのうちの一部の文字データであって、秘匿を所望するキーデータの選択を促す選択手段と、
前記選択手段により選択された前記タグで挟まれた項目の文字データであるキーデータを暗号化した文字列に変換する秘匿化手段と、
前記秘匿化手段により前記入力データのうちの暗号化された文字列と、前記入力データのうちの暗号化されていない文字データと、これら文字列および前記文字データに対応する項目を示す暗号化されていない文字データを含む前記タグを配してブロックチェーン上に保管させる保管指示手段と、
を備えることを特徴としている。
この特徴によれば、データ管理システムは、秘匿を所望するキーデータを選択させ、この選択されたキーデータのみを秘匿化した状態でブロックチェーン上に保管させる。このため、ブロックチェーン上の入力データは、入力データ内の一部のキーデータについて秘匿化されたデータを復号する鍵情報としての復号情報を有する者、サーバ、アプリ等の解読可能なもの例えば入力した本人(以下、本人等という。)以外に秘匿化された状態としながら、その他の内容は、入力した本人等以外にも閲覧可能とでき、秘匿を所望する内容を含んだ入力データについても、秘匿化されたデータを除いたデータについては第三者もアクセス可能でありデータ解析時等においてその内容を有効に活用することが可能となる。
【0008】
データ管理システムを提供するインターネット上のサービスサーバを備え、前記サービスサーバは、前記入力データの秘匿化されたキーデータを復号させる復号情報とユーザ識別情報とを対応付けて保持可能であり、
前記ユーザ識別情報に基づいて、ブロックチェーン上に保管されている入力データの秘匿化されているキーデータを復号させて出力可能な出力手段を備えることを特徴としている。
この特徴によれば、秘匿化されているキーデータについては、入力データを入力した本人のユーザ識別情報に基づいてのみ復号させることができ、かつユーザは秘匿化を解除する鍵情報としての復号情報を意識することなく入力データを復号して利用することができる。
【0009】
前記選択手段により選択された入力データに含まれる文字列であるキーデータをタグ分けした暗号化されていない文字データを含む前記タグに対して、秘匿化されていることを示すタグを付与可能であることを特徴としている。
この特徴によれば、秘匿化されているキーデータを検索したい場合に、タグに基づいて検索が可能となる。
【0010】
入力データに含まれる文字データに対して所定の付与条件に基づいて文字データを含むタグを付与する付与手段を備え、前記選択手段では、前記付与手段により付与されタグの文字データを暗号化可能とされるキーデータとして選択できることを特徴としている。
この特徴によれば、タグに挟まれたテキストが何に対応するのかを判別不能にでき、秘匿性が高い。
【0011】
前記入力データ内にイメージデータとテキストデータとがいずれも含まれているか否かを判定する判定手段と、
前記判定手段の判定に基づき、前記イメージデータを抽出し保管サーバに保管させるイメージ保管指示手段と、を備え、
前記保管指示手段は、前記イメージデータの保管に関する関連データを前記テキストデータと対応付けてブロックチェーン上に保管させるようになっており、
前記選択手段では、前記イメージデータをキーデータとして選択できることを特徴としている。
この特徴によれば、入力データ内にイメージデータとテキストデータとがいずれも含まれている場合には、イメージデータを秘匿化した状態で保管できるため、入力した本人以外がイメージデータの保管に関する関連データからイメージデータを参照した場合、イメージデータから秘匿化を所望された内容は漏洩しない。
【0012】
前記入力データ内にイメージデータとテキストデータとがいずれも含まれているか否かを判定する判定手段と、
前記判定手段の判定に基づき、前記イメージデータを抽出し保管サーバに保管させるイメージ保管指示手段と、を備え、
前記保管指示手段は、前記イメージデータの保管に関する関連データを前記テキストデータと統合してブロックチェーン上に保管させるようになっており、
前記選択手段では、前記イメージデータの保管に関する関連データをキーデータとして選択できることを特徴としている。
この特徴によれば、イメージデータの保管に関する関連データを秘匿化することで、入力した本人以外等は保管サーバからテキストデータに対応するイメージデータを検索することができず、秘匿性が高い。
【図面の簡単な説明】
【0014】
【
図1】本発明の実施例におけるデータ管理システムおよびデータ管理方法を示す概念図である。
【
図2】APIサーバから提供されてパソコンに表示される初期画面を示す図である。
【
図6】タグの付与が完了したXML形式のファイルを示す図である。
【
図7】データ管理システムの保管までのフローを示す概念図である。
【
図8】契約書類から変換されたXML形式のファイルを示す図である。
【
図9】任意の文字列に暗号化を設定できる表示画面を示す図である。
【
図11】電子契約の契約書類を保管する際のクライアント側のパソコンに表示される入力画面を示す図であり、契約者情報の入力を促すステップを示す。
【
図12】同じく契約内容の入力を促すステップを示す図である。
【
図13】同じく電子署名と印章の入力を促すステップを示す図である。
【
図14】同じく弁護士の選択を促すステップを示す図である。
【発明を実施するための形態】
【0015】
本発明に係るデータ管理システムおよびデータ管理方法を実施するための形態を実施例に基づいて以下に説明する。
【実施例】
【0016】
実施例に係るデータ管理システムおよびデータ管理方法につき、
図1から
図14を参照して説明する。
【0017】
データ管理システムは、様々な業態においてサービスの提供者と被提供者間でのやり取り、例えば、医療機関では個人の診療録(カルテ)、金融機関では顧客の取引履歴、法律関係機関では判例、遺言や不動産取引等の法務に関わる電子契約書類等を電子データ化し、後に参照できるようにサーバで管理するシステムである。本実施例では、診療録を病院単位で管理することを例に取り説明する。
【0018】
図1は、本発明のデータ管理システムに係る実施形態を実現するための全体システム図を示し、符号1は管理会社(管理者)がデータ管理システムを提供するためのサービスサーバであり、符号2はクライアント及び出力手段としてのパーソナルコンピュータ(以下「パソコン」と略称する)、であり、これらはインターネットを通じて相互通信可能に接続されている。パソコン2には、入力手段としてのスキャナー3、キーボード4、マウス5等がそれぞれ接続されている。その他、入力手段としてはペンタブレットとスタイラスペン等も利用できる。
【0019】
そして、上記各パソコン2は、ハードディスク等の図示省略の記録手段やRAM等に加え、電子化処理部を備えている。スキャナー3により撮像された紙媒体の管理書類は、電子化処理部にて記載された文字情報が文字認識され、文字情報がテキストに変換されたドキュメントが生成される。尚、管理書類に写真や図や動画等がある場合、これらはPNGやJPEGやAVI等のイメージデータとしてテキストとともにドキュメントを構成する。
【0020】
サービスサーバ1は、後述するブロックチェーンプラットフォームの動作環境及び分散型ファイルシステムの動作環境である複数のコンピュータ(記録手段)6とAPI(Application Program Interface)サーバ(記録手段)7と利用者管理サーバ(記録手段)8と処理サーバ(記録手段)9がネットワークで接続されて構成されており、クライアント側のパソコン2から管理書類のテキストデータである入力データを受信し、この入力データの管理を行う。
【0021】
本実施例におけるデータ管理システムでは、入力データはブロックチェーンの技術を利用して保管される。サービスサーバ1を構成する複数のコンピュータ6は、ブロックチェーンのブロックを生成する複数のノードであり、分散型ファイルシステムを構成する分散サーバとしてのノードでもある。
【0022】
APIサーバ7は、データ管理システムを提供する管理会社が運用するサーバであり、クライアント側のパソコン2から受信した入力データをブロックチェーン上に保管するために必要なデータの変換や後に詳述するタグの付与をブロックチェーンや分散型ファイルシステムの知識を有していないクライアントでも簡単に利用することができるAPIを提供するインターネット上のサーバである。尚、APIサーバ7にて実装されてAPIは、クライアント側のパソコン2で起動したウェブブラウザ上で動作する。
【0023】
データ管理システムを利用するユーザは、データ管理システムの管理会社が公開するホームページにて、予め固有のユーザID(ユーザ識別情報)とパスワードとを登録しておく。利用者管理サーバ8は、ホームページにて入力されたユーザIDとパスワードと当該ユーザIDのユーザに割り当てられたブロックチェーンへのリンク情報との対応関係を保有する対応テーブルを備えている。
【0024】
図7は、データ管理システムにおける入力データのアップロードからブロックチェーン上、分散型ファイルシステム上での保管までのフローを示す概念図であり、以下、要所に
図7の矢印に付された番号を説明に用いることがある。
【0025】
ユーザがデータ管理システムに入力データを入力する際には、まずパソコン2で起動したウェブブラウザを用いて管理会社が公開するホームページにアクセスする。
図2に示されるように、ホームページの初期画面10には、ユーザIDの入力欄11とパスワードの入力欄12と、ログインボタン13とが表示され、アクセスしてきたユーザに対して、ユーザIDとパスワードの入力が求められる。
【0026】
ユーザは、これらユーザIDの入力欄11とパスワードの入力欄12に入力し、ログインボタン13を選択する。ログインボタン13が選択されると、入力されたユーザIDとパスワードとは利用者管理サーバ8(
図1参照)に送られ、入力されたユーザIDとパスワードとの組み合わせが対応テーブルを参照して正しいことが判断できたことに基づき、
図3に示されるユーザーページ14が表示される。
【0027】
ユーザーページ14には、データ入力ボタン15とデータ参照ボタン16とが選択可能に表示される。ユーザは新たに診療録のドキュメントをアップロードする際には、データ入力ボタン15を選択し、既に管理されている診療録の電子データを参照する際には、データ参照ボタン16を選択する。
【0028】
データ入力ボタン15が選択されると、
図4に示されるデータ入力ページ17が表示される。データ入力ページ17には、ファイル選択ボタン18とアップロードボタン19とが表示される。ユーザがファイル選択ボタン18を選択すると、クライアント側のパソコン2の記憶媒体に記憶された診療録のドキュメントを選択可能なウィンドウが表示され、アップロードボタン19の選択(
図7矢印1参照)により、当該選択した診療録の電子データが処理サーバ9に送信される(
図7矢印2参照)。
【0029】
処理サーバ9では、まず診療録のドキュメントをファイル形式に基づく判断材料やそのデータの中身を読み込むことで、当該ドキュメントが全文検索可能なテキストのみのファイルであるか否か判定する(判定手段)。テキストのみのファイルであれば、タグを付与するステップ(付与手段)に移る。一方、テキストに加えてイメージデータ等のテキストデータに比べて大きなファイルサイズのデータが貼り込まれている場合には、タグを付与するステップの前に、ドキュメントを当該大きなファイルサイズのデータとテキストデータとに分ける分割処理に移る。テキストデータに比べて大きなファイルサイズのデータは、本実施例ではCT画像20(イメージデータ・
図5参照)として説明する。
【0030】
分割処理では、分けられたテキストデータとイメージデータとに共通するメタデータをそれぞれ付与し、後の処理の準備状態として保持する。
【0031】
処理サーバ9は、複数のコンピュータ6にて動作する分散型ファイルシステムに対して、入力データから取り出したイメージデータを保管するように指示を行う(
図7矢印3参照)。この分散型ファイルシステムはIPFS(Inter Planetary File System)であり、イメージデータが保管されるノードをネットワーク上で参照にするハッシュ値を処理サーバ9に返す(
図7矢印4参照)。
【0032】
分散型ファイルシステムからイメージデータのハッシュ値を受信した処理サーバ9は、イメージデータと分けられた後のテキストデータを全文検索し、予め設定した所定の付与条件で名詞等の文字データ(例えば、項目名である既往歴等)をテキストデータから発見し、これらテキストデータの文字列にタグを付与したXML形式のファイルに変換する。
【0033】
例えば、
図5の診療録の電子データから項目を示す「既往歴」という単語の文字データと、この「既往歴」という単語の近傍の単語である「インフルエンザ」と「硬膜下血腫」という文字データとが発見されると、「インフルエンザ」と「硬膜下血腫」とが「既往歴」に該当するものと判断する。そして、
図6のXML形式のファイルにおいて、<既往歴>と</既往歴>の間に「インフルエンザ」と「硬膜下血腫」の文字データをそれぞれ配置する。
【0034】
このように、「既往歴」「インフルエンザ」「硬膜下血腫」等の単語を認識することと、これら「インフルエンザ」「硬膜下血腫」が「既往歴」に対応することは、所定のタグの付与条件として、予め管理会社とユーザとで処理サーバ9に設定されている。
【0035】
加えて、本実施例におけるAPIは、タグの付与条件として、「インフルエンザ」という文字データが「呼吸器」の疾患であり、「硬膜下血腫」という文字データが「脳」の疾患であると判定することができる付与条件も備えている。そして、XML形式のファイルにおいて「インフルエンザ」を挟むように<呼吸器>と</呼吸器>のタグを、「硬膜下血腫」を挟むように<脳>と</脳>のタグを、それぞれ配置する。つまり、「インフルエンザ」という文字データには、下位のサブタグである<呼吸器></呼吸器>のタグと、上位のメインタグである<既往歴></既往歴>というタグが付与され、これら複数のタグが階層で分けられて判定可能となっている。なお、一つの文字データに複数のタグが付与されるようになっていてもよい。例えば「インフルエンザ」という文字列に「呼吸器」と「ウィルス」という2つのタグが付与されるようになっていてもよい。
【0036】
更に処理サーバ9は、分散型ファイルシステムから返されたハッシュ値(関連データ)を、XML形式のファイル内に記入する。詳しくは、イメージデータに関連するハッシュ値は、その文字列がイメージデータのハッシュ値であることを示すタグ情報<img></img>の間に記入される。尚、XML形式のファイルには、イメージデータの位置情報を示すタグ情報やイメージデータの配置及び表示サイズ等の情報を配置してもよい。
【0037】
処理サーバ9は、イメージデータに関連するハッシュ値とテキストデータとが統合されたXML形式のファイルを、複数のコンピュータ6にて動作するブロックチェーンプラットフォームにて保管するように指示を行うステップ(保管指示手段)に移る(
図7矢印5参照)。ブロックチェーンプラットフォームはイーサリアムであり、統合されたXML形式のファイルは、ハッシュ値に変換されてブロックチェーン上で保管される。
【0038】
すなわち、XML形式のファイルは、サービスサーバ1を構成するいずれかのコンピュータ6にてブロックチェーンの形式に沿ってハッシュ値化(
図7矢印6参照)され、前述の対応テーブルにて照会されたユーザIDに対応するブロックチェーンへのリンクを用いて複数のブロックチェーンの中から該当するブロックチェーンを特定し、サービスサーバ1を構成する複数のノードとして機能するコンピュータ6の環境において動作するブロックチェーン上に保管される。また、利用者管理サーバ8の対応テーブルでは、ブロックチェーン上に保管されたハッシュ値とユーザIDとの対応関係を保持しており、後述する出力時には、ユーザはログイン時に表示される複数のハッシュ値から任意のものを選択することで、入力データ単位で内容を確認可能に出力できる。処理サーバ9は、ブロックチェーンへの入力データの保管が完了したことをAPIの表示等を用いてクライアント側のパソコン2に対して通知する(
図7矢印7,8参照)。
【0039】
また、
図8に示される契約書類のように、クレジットカード番号等の秘匿性の高い文字列がXML形式のファイルに記載されている場合がある。サービスサーバ1が提供するデータ管理システムでは、XML形式のファイルにおいて、ユーザが必要に応じてテキストデータの暗号化を行うことができる機能を備えている。
【0040】
処理サーバ9はXML形式のファイルのタグの付与が完了すると、秘匿処理ステップを行う。詳しくは、APIを用いて
図9に示されるような任意の文字列に暗号化を設定できる表示画面を表示させる。ユーザは、マウス5等を用いて文字列をドラッグ(選択)することで、秘匿したい部分を指定できる(
図9では2箇所を指定する例を示している。)。APIはドラッグされた文字列を認識し、表示画面では当該文字列にマスキングを掛け、かつ処理サーバ9に当該文字列の暗号化を指示する。
【0041】
処理サーバ9は、選択された文字列を変数にて一見して内容が判断できない文字列に変換(暗号化)する。このとき処理サーバ9は、暗号化に用いた変数を対応テーブル(
図1参照)にてユーザIDに紐づけて保存する。
【0042】
また、処理サーバ9は、暗号化を行った部分を判別できるようにタグをXML形式のファイルに付与する。
図9では、<クレジットカード番号></クレジットカード番号>がタグ付けされた文字列と、<img></img>がタグ付けされた文字列、すなわちイメージデータのハッシュ値の文字列とに暗号化を行うため、最下端に<Enc></Enc>のタグで<クレジットカード番号></クレジットカード番号>と<img></img>のタグを挟んで記載している。これによれば、<Enc></Enc>のタグに基づいて検索を行うことで、処理サーバ9は暗号化された部分があることと、その暗号化された部分を迅速に検知でき、後述する出力時の復号を高速で処理することができる。
【0043】
尚、処理サーバ9は、タグに基づき秘匿すべきと判断した文字列を、暗号化を設定できる表示画面においてフリッカ表示、ハイライト表示等の強調表示をする等してユーザに示すアシスト機能を備えていてもよい。
【0044】
また、文字列の暗号化に限らず、各タグを選択してタグ自体を暗号化できる仕様としてもよい。これによれば、タグに挟まれた文字列が何に対応するのかを判別不能にできる。また、タグとタグに挟まれた文字列を共に暗号化することも可能である。
【0045】
また、イメージデータについても、暗号化可能な仕様としてもよい。これによれば、入力データ内にイメージデータとテキストデータとがいずれも含まれている場合には、イメージデータを秘匿化した状態で保管できるため、入力した本人以外がイメージデータのハッシュ値を用いてイメージデータを参照した場合でも、イメージデータから秘匿化を所望された内容は漏洩しない。
【0046】
処理サーバ9は、ブロックチェーン上に保管された複数の入力データを参照する機能(出力手段)を有する。ユーザは、パソコン2で起動したウェブブラウザを用いて管理会社が公開するホームページにアクセスしログインを行う。
【0047】
ユーザは、ログイン後にクライアント側のパソコン2に表示されるユーザーページ14(
図3参照)のデータ参照ボタン16を選択する。処理サーバ9は、データ参照ボタン16の選択に基づき、入力データを参照するステップを開始する。
【0048】
詳しくは、処理サーバ9はユーザがログイン時に受信したユーザIDを対応テーブルで参照し、対応するブロックチェーンへのリンクを用いて、入力データ保管されている当該ブロックチェーンを特定し、当該ブロックチェーンプラットフォームに該ユーザID対応するハッシュ値を送信する。
【0049】
ついでブロックチェーンプラットフォームは、ハッシュ値をXML形式のファイルに復号し、処理サーバ9にXML形式のファイルを返信する。更に、処理サーバ9はXML形式のファイルを読み込み、内部にイメージデータに関連するハッシュ値があるか否かを判定する。イメージデータに関連するハッシュ値があることが判定されると、処理サーバ9は分散型ファイルシステムにて当該ハッシュ値を用いて当該ハッシュ値に対応するイメージデータを分散ファイルシステムからダウンロードする。
【0050】
そして、処理サーバ9によって、XML形式のファイル内のイメージデータに関連するハッシュ値以外のテキストデータとダウンロードしたイメージデータを用いて、
図10に示されるように、クライアント側のパソコン2のディスプレイに対して、XML形式のファイル中のテキストデータとイメージデータとを同時に閲覧できる出力画面を表示する。
【0051】
このとき、処理サーバ9は、利用者管理サーバ8の対応テーブルから暗号化に用いた解読用の鍵としての変数(復号情報)を抽出し、当該変数を用いてXML形式のファイル中の暗号化された文字列を復号して表示する。
【0052】
このように、所定の検索条件によって抽出されたテキストと、当該テキストに付与されたタグを用いることで、事業活動に有益な知識を得るためのデータ解析に利用することができる。例えば、医療の分野では、ユーザである一の病院の患者全ての診療録の入力データを解析することで、近似する既往歴の患者同士の診療録の入力データから、疾患傾向や有効な治療法の研究等に役立つ知識を得られる可能性がある。
【0053】
以上説明したように、本発明のデータ管理システムは、処理サーバ9は入力データを受付けて表示させ、入力データのうちの一部のデータであって秘匿を所望するキーデータであるテキスト、タグ、イメージデータのいずれを任意に選択できる入力画面(選択手段)を表示する。そして、入力画面で選択されたキーデータを秘匿化した状態の入力データをブロックチェーン上に保管させる仕様となっている。これによれば、ブロックチェーン上の入力データは、入力データ内の一部のキーデータについて入力した本人以外に秘匿化された状態としながら、その他の内容は、入力した本人以外も閲覧可能にでき、秘匿を所望する内容を含んだ入力データについても、データ解析時等においてその内容を有効に活用することが可能となる。
【0054】
また、処理サーバ9は、利用者管理サーバ8の対応テーブルから暗号化に用いた変数を抽出し、当該変数を用いてXML形式のファイル中の暗号化された文字列を復号して表示する。即ち秘匿化されているキーデータについては、入力データを入力した本人のユーザIDに基づいてのみ復号させることができ、かつユーザは秘匿化を解除する鍵情報を意識することなく入力データを復号して利用することができる。
【0055】
また、上記したように、イメージデータのハッシュ値の文字列を秘匿化することで、入力した本人以外は保管サーバからテキストデータに対応するイメージデータを検索することができず、秘匿性が高い。
【0056】
尚、データ管理システムにて管理できる書類は、前記実施例にて説明した診療録や契約書類に限らず、データ解析等のデータ活用には基本的に利用しないもの、例えば、遺言や不動産取引等の法務に関わる電子契約書類であってもよい。このような遺言書等の電子契約書類をブロックチェーン上で保管する場合には、弁護士のように公的に法律的な遺言書の効力を証明できる第三者の承認が必要となる。
【0057】
このように弁護士の承認を必要とする入力データを保管するサービスを提供する場合について、
図11から
図14を用いて説明する。データ管理システムを提供するサービスサーバは、この承認作業を行う弁護士の承認ステップが実装されている。尚、ここでは不動産取引の電子契約について説明する。
【0058】
図11に示されるように、契約書類はAPIが提供する入力画面がクライアント側のパソコン2に表示され、ユーザはこの入力画面から直接内容を入力することができる。入力画面のステップ1として、ユーザには契約書類のタイトルと契約者情報として契約者氏名、住所の入力が要求される。次いでステップ2として、ユーザには契約内容を入力する入力欄が表示され(
図12参照)、内容の入力が完了するとマウス等を用いて行う電子署名と、印章のアップロードが促される(
図13参照)。ユーザによる契約書類の入力が完了すると、クライアント側のパソコン2には
図14に示されるような、契約書類の入力データの承認を依頼する弁護士の選択を促す画面が表示される。
【0059】
ユーザが弁護士を選択し認証依頼ボタンが操作されると、サービスサーバ1は予め連絡先が登録されている、選択された弁護士に対して入力データの内容確認の依頼を示すメッセージを送信する。弁護士は、ネットワークに接続されたパソコン等の端末を用いて、当該入力データを確認し、確認完了のメッセージをサービスサーバ1に送信する。この確認完了のメッセージとしては、例えば弁護士による電子署名であってもよい。
【0060】
サービスサーバ1は、この承認完了のメッセージの受信に基づき、当該入力データの承認作業が完了したと見なし、当該入力データを上記したタグの付与及び署名、印章のイメージデータの抽出、ハッシュ値への変換等の作業を行い、ブロックチェーン上に保管する指示を行う。
【0061】
このように、弁護士による承認が完了した入力データのみがブロックチェーン上に保管されるため、ユーザは別途に電子証明書等を用意する必要がなく、またサービスサーバ1が提供するホームページから弁護士への承認要請を行うことができ、面倒な手続きを省略して、信憑性の高い電子契約の管理を行うことができる。
【0062】
以上、本発明の実施例を図面により説明してきたが、具体的な構成はこれら実施例に限られるものではなく、本発明の要旨を逸脱しない範囲における変更や追加があっても本発明に含まれる。
【0063】
例えば、前記実施例では、サービスサーバ1はAPIサーバ7を備え、APIを用いることで、視覚において直感的な操作によりブロックチェーン技術に関する知識を有していないユーザでも簡単にシステムを利用できるようになっているが、これに限らず、処理サーバ9への指示信号を送信できるウェブブラウザ上で動作するAPIとは別のプログラムを利用する等してもよい。
【0064】
また、前記実施例では、データ管理システムはサービスサーバ1により提供される構成で説明したが、これに限らず、例えばクライアント側のパソコン2上で、APIを備えるAPIサーバ7と、対応テーブルを備える利用者管理サーバ8と処理サーバ9の機能を備えたアプリケーションを動作させる構成としてもよく、この場合、パソコン2がデータ管理システムを構成することになる。
【0065】
また、前記実施例において、イメージデータは分散型ファイルシステムであるIPFSを用いて保管されているが、これに限らず、例えばテキストデータを保管するブロックチェーン以外の保管環境であれば、分散型ファイルシステムが用いられなくてもよいし、サーバやローカルサーバ等に保管されてもよい。また、この場合、イメージデータが保存されているURLやローカルドメイン等がイメージデータの保管に関する関連データとして、テキストデータと対応付けて保管される。
【0066】
また、分散型ファイルシステムから返されたハッシュ値は、テキストデータに統合される仕様に限らず、例えばテキストデータはイメージデータのハッシュ値とは別途ハッシュ値化されてブロックチェーン上にそれぞれ別ブロックとして保管し、イメージデータのハッシュ値に対応するテキストデータの保管に関する関連データを付与した上で、ブロックチェーン上に別の単位で保管される仕様としてもよい。
【0067】
また、前記実施例においてデータ管理システムは、処理サーバ9はクライアント側のパソコン2から受信した入力データを判定手段により判定し、テキストデータと大容量のデータであるイメージデータとが混在している場合には、イメージデータを抽出して分散型ファイルシステムにて保管させ、分散型ファイルシステムから返されたイメージデータの保管に関する関連データであるハッシュ値のみをテキストデータに対応付けてブロックチェーン上に保管させる構成としているが、これに限らない。例えば、データ管理システムを提供するサービスサーバ1はイメージデータの保管場所としての分散型ファイルシステムを備えていなくてもよく、この場合、処理サーバ9はイメージデータを抽出する機能、イメージデータのハッシュ値とテキストデータとを対応付ける機能を備えていなくてよい。
【0068】
また、前記実施例において、XML形式のファイル内の任意の文字列を秘匿する際に暗号化に利用した変数は、ユーザID毎に設定され保管される仕様で説明したが、これに限らず、例えばXML形式のファイル毎に変数が設定され保管される仕様とすることで秘匿性を更に高める仕様としてもよい。
【0069】
また、前記実施例におけるブロックチェーンは、管理会社が提供するサービスサーバ1を構成する複数のコンピュータ6上の環境で動作する、所謂プライベートチェーンで説明したが、パブリックチェーンの仕様であってもよい。分散型ファイルシステムの動作環境についても同様にプライベートな環境とパッブリックな環境のいずれであってもよい。
【0070】
また、管理会社が提供するサービスサーバ1を構成するAPIを備えるAPIサーバ7と、対応テーブルを備える利用者管理サーバ8と処理サーバ9とは、それぞれの機能を兼ねる一台のコンピュータで構成されていてもよい。
【0071】
また、ユーザが利用するクライアント側の端末は、パソコンに限らず、タブレットやスマートフォンでもよい。
【0072】
また、ブロックチェーンで変換されたハッシュ値やブロックチェーンへのリンクは、対応テーブルで管理されずに、直接ユーザに送信される構成であってもよい。
【符号の説明】
【0073】
1 サービスサーバ
2 パソコン
3 スキャナー
4 キーボード
5 マウス
6 コンピュータ(保管サーバ)
7 APIサーバ
8 利用者管理サーバ
9 処理サーバ
10 初期画面
14 ユーザーページ
15 データ入力ボタン
16 データ参照ボタン
17 データ入力ページ
18 ファイル選択ボタン
19 アップロードボタン
20 CT画像(イメージデータ)