(57)【要約】【課題】アイコンバッチおよびそれに付随する派生データが巨大なデータ群となった場合にそれを管理サーバに集中して管理することによる、検索スピードの劣化およびデータの安全性の低下といった弊害を生じさせない。【解決手段】管理サーバは、所定のデータを分割後に暗号化処理を施して複数のサブデータを生成し、分割した数と同数の異なる記憶サーバに送信し、かつ、所定のデータの取出し要求を受け取ると、複数の記憶サーバに命令を出して記憶サーバそれぞれからサブデータを回収し、暗号化処理に対応する復号化処理を施してこの所定のデータを復元する機能を有し、複数の記憶サーバそれぞれは、管理サーバから送信された各サブデータを格納し、かつ、管理サーバからの命令に係るサブデータを格納している場合にはこのサブデータを管理サーバへ返送する機能を有する。【選択図】図２
2016009030.tif 000002
【特許請求の範囲】
【請求項１】
管理サーバと、
前記管理サーバを含めネットワークを介して相互に接続される複数の記憶サーバと、
を備え、
前記管理サーバは、所定のデータを分割した後に暗号化処理を施して複数のサブデータを生成し、該複数のサブデータそれぞれを該分割した数と同数の異なる前記記憶サーバに送信し、かつ、前記所定のデータの取出し要求を受け取ると、前記複数の記憶サーバに命令を出して当該所定のデータから生成したサブデータそれぞれを格納している前記記憶サーバそれぞれから当該サブデータを回収し、前記暗号化処理に対応する復号化処理を施して前記所定のデータを復元し、
前記複数の記憶サーバそれぞれは、前記管理サーバから送信された前記各サブデータを格納し、かつ、前記管理サーバからの前記命令に係る前記サブデータを格納している場合には当該サブデータを前記管理サーバへ返送する
ことを特徴とするデータ管理システム。
【請求項２】
請求項１記載のデータ管理システムであって、
前記所定のデータは、アイコンバッチ、当該バッチに関する情報および当該バッチを持つユーザに関する情報である
ことを特徴とするデータ管理システム。
【請求項３】
請求項１または２記載のデータ管理システムであって、
前記所定のデータおよび前記複数の各サブデータにはそれぞれ固有のＩＤを付与し、
前記管理サーバは、前記双方のＩＤを関係付けて管理する
ことを特徴とするデータ管理システム。
【請求項４】
請求項３記載のデータ管理システムであって、
前記所定のデータからハッシュ関数に基づいて算出するハッシュ値および前記各サブデータからハッシュ関数に基づいて算出するハッシュ値を、それぞれ前記固有のＩＤとする
ことを特徴とするデータ管理システム。
【請求項５】
請求項４記載のデータ管理システムであって、
前記記憶サーバから回収した前記各サブデータのハッシュ値を算出し、該算出した各サブデータのハッシュ値と前記複数の各サブデータに対応する固有のＩＤとが一致する場合にのみ、該回収した前記各サブデータから前記復号化処理を施して前記所定のデータを復元する
ことを特徴とするデータ管理システム。
【請求項６】
請求項４または５記載のデータ管理システムであって、
前記復元した前記所定のデータのハッシュ値を算出し、該算出した所定のデータのハッシュ値と前記所定のデータに対応する固有のＩＤとが一致する場合にのみ、該復元した前記所定のデータを利用可能にする
ことを特徴とするデータ管理システム。
【請求項７】
請求項４〜６のいずれか記載のデータ管理システムであって、
前記ハッシュ関数として、ＭＤ５またはＳＨＡを用いる
ことを特徴とするデータ管理システム。
【請求項８】
請求項１〜７のいずれか記載のデータ管理システムであって、
前記暗号化処理として、ＤＥＳまたはＡＥＳを用いる
ことを特徴とするデータ管理システム。
【請求項９】
管理サーバと該管理サーバを含めネットワークを介して相互に接続される複数の記憶サーバとを用いて、
前記管理サーバは、所定のデータを分割した後に暗号化処理を施して複数のサブデータを生成する第１ステップと、該複数のサブデータそれぞれを該分割した数と同数の異なる前記記憶サーバに送信する第２ステップを実行し、
前記複数の記憶サーバそれぞれは、前記管理サーバから送信された前記各サブデータを格納する第３ステップを実行し、
前記管理サーバは、前記所定のデータの取出し要求を受け取ると、前記複数の記憶サーバに対して当該取出し要求に対応する命令を送信する第４ステップを実行し、
前記複数の記憶サーバそれぞれは、前記管理サーバからの前記命令に係る前記サブデータを格納している場合には当該サブデータを前記管理サーバへ返送する第５ステップを実行し、
前記管理サーバは、前記記憶サーバそれぞれから返送された前記サブデータを回収する第６ステップと、前記回収したサブデータに対して前記暗号化処理に対応する復号化処理を施して前記所定のデータを復元する第７ステップを実行する、
ことを特徴とするデータ管理方法。
【請求項１０】
請求項９記載のデータ管理方法であって、
前記所定のデータは、アイコンバッチ、当該バッチに関する情報および当該バッチを持つユーザに関する情報である
ことを特徴とするデータ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アイコンバッジを用いて紐付くコンピテンシー（文言、評価等）を可視化するシステムにおけるデータの管理技術に関する。
本発明が対象とするアイコンバッジとは、ＷＷＷ上やシステムプログラム上に構築されたＨＴＭＬ表示部における表示アイコンがその代表例である。そして、本発明に係るシステムは、アイコンバッチと共に、Ｊａｖａ（登録商標）やＰＨＰ等を利用して自動的に動的なチャート表やグラフ等を生成し表示する。
【背景技術】
【０００２】
従来、データベースを利用した複数のアイコンまたはサムネイルの画像データの類似度の度合いを算出して、これらサムネイルをグループ化して表示する画像表示装置（特許文献１）や内容画像による文書検索方法および装置が提案されている（特許文献２）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２３６６４６号公報
【特許文献２】特開２００６−１４６６２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１および２には、サムネイル表示の複数表示方法の合理化および文章検索方法の合理化を解決する方法に関する技術が開示されている。しかしながら、これら技術は、感情表現を表すアイコンクラスタ群の管理とは異なるシステムである。また、ユーザの増加に拘らずデータベースの検索スピードの高速性を維持することは重要な点であるところ、これら技術においては、データベースの検索スピードが低下し期待する動作を保証できなくなる恐れがある。更に、高負荷状態でデータベースを稼働させればメモリリーク等が発生し、システム全体の堅牢性が担保できなく恐れもある。そうすると、安全性を担保できずにハッキングの対象となりやすい。そして、メモリ内部へ格納するデータ群に対して暗号化を施さねば、インターネットを介したハッキング等の脅威に対抗するクラスタリングシステムを構築することは困難であった。
【課題を解決するための手段】
【０００５】
本発明は、管理サーバと、管理サーバを含めネットワークを介して相互に接続される複数の記憶サーバとを備え、管理サーバは、所定のデータを分割した後に暗号化処理を施して複数のサブデータを生成し、この複数のサブデータそれぞれを分割した数と同数の異なる記憶サーバに送信し、かつ、所定のデータの取出し要求を受け取ると、複数の記憶サーバに命令を出してこの所定のデータから生成したサブデータそれぞれを格納している記憶サーバそれぞれからサブデータを回収し、暗号化処理に対応する復号化処理を施してこの所定のデータを復元する機能を有し、複数の記憶サーバそれぞれは、管理サーバから送信された各サブデータを格納し、かつ、管理サーバからの命令に係るサブデータを格納している場合にはこのサブデータを管理サーバへ返送する機能を有するものである。
【発明の効果】
【０００６】
本発明に係るデータ管理システムによれば、管理サーバが、親データを復元するために必要な全ての情報（例えば、親データの名称、その親データを分割したサブデータのＩＤとその格納先）を保持せず、複数の記憶サーバに親データを分散して格納することにより、管理サーバに格納される情報が過失や攻撃等により流出してしまったとしても、親データが復元されデータが漏洩してしまう危険性をなくすことができる。また、分散化により検索スピードの低下を防止することができる。更に、記憶サーバに分散して格納する際に、データＩＤのハッシュ化およびデータの暗号化を施すことにより、データの安全性を十分に高めることができる。
【図面の簡単な説明】
【０００７】
【図１】図１は、アイコンバッチおよび評価グラフの具体的イメージを示す図である。
【図２】図２は、本発明に係るデータ管理システムの概念／概略図である。
【図３】図３は、管理サーバの概略構成を示す図である。
【図４】図４は、ファイル名管理テーブルの１例を示す図である。
【図５】図５は、ＩＤ管理テーブルの１例を示す図である。
【図６】図６は、記憶サーバ６の概略構成を示す図である。
【図７】図７は、データ保管処理のフローチャートを示す図である。
【図８】図８は、親データから分割したサブデータを分割し暗号化する模式図である。
【図９】図９は、データ取出し処理のフローチャートを示した図である。
【図１０】図１０は、分割したサブデータから親データを復元する模式図である。
【図１１】図１１は、管理サーバと複数の記憶サーバとをネットワーク接続した構成図である。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について、まず、データ管理の対象となるデータ対象について説明をし、その後で、実施例について図面を参照しながら説明する。
【０００９】
本発明のデータ管理システムの対象となる代表的な実施形態は、アイコンバッチを感情表現として端末上に表せない言語を代弁するための表現態様で表示するシステムにあって、このアイコンバッチに係るデータ検索の高速化や暗号化を施すためのデータ管理システムである。
【００１０】
ここで、アイコンバッチとは、「喜び」「感謝」「前向き」等の感情表現をコンピュータ上において、グラフィックや音声など人間の五感に訴える形態により表示または出力するものである。そして、その表現は多彩を極め、例えば、「仕事ができた」「他人のためによく働いた」「ありがとう」等を表現するコンピュータグラフィックを複数用意しておくことができる。このアイコンバッチにユーザ情報を付与して感情表現を可視化し、評価グラフと共に表現する手法を用いることによって、第三者が、このユーザはどのような評価をもらい、どのような働きをしたのかを簡易的に知ることができるシステムである。
【００１１】
図１は、アイコンバッチを用いた具体的なイメージ図の一例である。十角形の周囲に並ぶ１０個の円形のアイコンがアイコンバッチであって、それぞれが、下の文字が示す感情やパフォーマンス等を表現している。そして、十角形の中心から各アイコンバッチに向かって様々に伸びている図形が、各アイコンバッチに対する評価の度合い（程度）を示している。
【００１２】
図２は、本発明に係るデータ管理システムの概念および概略を示した図である。
アイコンバッチには、それぞれ固有のＩＤ（アイコンＩＤ）を付与すると共に、そのアイコンバッチを持つユーザの固有ＩＤ（ユーザＩＤ）も関連付けをし、併せて、アイコンバッチに関する情報（アイコン情報）およびユーザに関する情報（ユーザ情報）も付随させる。ここで、アイコンバッチに対応する評価が入力されると、それをアイコン情報やユーザ情報として取り込むこととなる。アイコンＩＤやそのＩＤ毎のデータは、ハッシュ関数および暗号化手段（例えば、ＡＥＳ５１２を使用した暗号化）を使用して、ハッシュ化データまたは暗号化データとしてデータベース（ＤＢ）に登録格納されることになる。
【００１３】
データベース（ＤＢ）への登録形態としては、例えば、図２に示すように、アイコンバッチに関するデータ、ユーザに関するデータ、評価等の表現を多言語に対応させるために言語に関するデータ、および、ユーザが所属するチームに関するデータなどに分けて登録することができる。
その上で、アイコンバッチ用のデータベースストア（格納領域）を自動的に拡張できるように、アイコンクラスタ用のテーブルセットおよびタグクラスタ用のテーブルセットを用意し、関連するデータが各クラスタの対応する項目に格納される。
【００１４】
次に、データの出力時には、データベース（ＤＢ）の格納データを入力時に使用した暗号化手段による復号化（例えば、ＡＥＳ５１２を使用した復号化）を通して復元する。そして、復元したデータを基に、ユーザに対してアイコンバッチのデータを送信（出力）することになる。
【００１５】
ここで、ユーザＩＤについては、ユーザに異動があった場合にも自動的に項番を付与できるように、データベースのテーブルセットを拡張して対応する。例えば、ユーザＡには、ＩＤ＝ａ００１と付与しておくが、異動がある場合には、移動元を特定できるように、ＩＤ＝ａａ００１として自動的にＩＤを付与する処理を行い格納することで対応する。
【００１６】
また、評価等の表現に使用する言語に関しては、ユーザの利便性を図るために、日本語、英語、タイ語、中国語、韓国語、マレー語およびロシア語等の言語テーブルを用意し、例えば母国語を指定することによって自動的に言語変更が行えるように、ユーザＩＤと言語ＩＤをリンク付けておく。
なお、テーブルセットの自動拡張については、各データベース用ソフトウェアの仕様に基づくが、一般的にはＵＮＬＩＭＩＴＥＤという構文を用いて自動的に拡張が行えるように、予めデータベースに関連プログラムを投入しておく必要がある場合もある。
【００１７】
更に、ＡＥＳ５１２等を使用した暗号化に関しては、既存の一般的な暗号化システムの脆弱性への対処を図るために暗号化の強化を図るための対策である。
【実施例】
【００１８】
図３は、管理サーバ１の概略構成を示す図である。管理サーバ１は、ＣＰＵ２、メモリ３、ハードディスクやフラッシュメモリ等の大容量記憶装置から成る記憶部４、および、外部ネットワークに接続するためのネットワークインターフェース５から構成される。また、各構成要素はバス等によって相互に接続されている。
【００１９】
記憶部４には、ＯＳ（図示せず）の他、ファイル名管理テーブル４１、ＩＤ管理テーブル４２および管理サーバ用プログラム４３が格納されている。ファイル名管理テーブル４１およびＩＤ管理テーブル４２の具体的イメージとして、それぞれ図４および図５を示す。また、管理サーバ用プログラム４３は、例えば、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＯＭドライブおよび外部ネットワーク等を介して外部の記憶媒体よりインストールするなどにより取り込むこともできる。
【００２０】
管理サーバ用プログラム４３は、ＣＰＵ２によって実行されることになるが、その内部構成を図３では吹き出しによって示している。すなわち、管理サーバ用プログラム４３は、データ分割部１１、ＩＤ生成部１２、ファイル名管理部１３、ＩＤ管理部１４、分散配置部１５、データ回収命令部１６、親データ復元部１７、データ暗号化部１８およびユーザ認証部１９から構成される。
【００２１】
図６は、記憶サーバ６の概略構成を示す図である。記憶サーバ６は、ＣＰＵ（記憶サーバＣＰＵ）６０、メモリ６１、外部ネットワークに接続するためのネットワークインターフェース６２、および、ハードディスクやフラッシュメモリ等の大容量記憶装置から成る記憶部６３から構成される。また、各構成要素はバス等によって相互に接続されている。
【００２２】
記憶部６３には、ＯＳ（図示せず）の他、サブデータ保存部６４および記憶サーバ用プログラム６５が格納されている。この記憶サーバ用プログラム６５は、例えば、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＯＭドライブおよび外部ネットワーク等を介して外部の記憶媒体よりインストールするなどにより取り込むこともできる。
【００２３】
記憶サーバ用プログラム６５は、ＣＰＵ６０によって実行されることになるが、その内部構成を図６では吹き出しによって示している。すなわち、記憶サーバ用プログラム６５は、格納先情報保持部６６、格納先情報更新部６７、格納先情報暗号化部６８および格納先照合部６９から構成される。
【００２４】
［データの保管］
データを保管する方法について、図７に示すフローチャートに基づいて説明する。図７は、管理サーバ１のＣＰＵ２が管理サーバ用プログラム４３を実行することによるデータ保管処理のフローチャートを示す図である。
まず、データ保管処理を開始するまでの前処理部分を簡単に説明する。ただし、図７には図示していない。
【００２５】
ユーザが、ユーザ端末を操作すること（例えば、所定のアプリケーションプログラムの起動等）によって、管理サーバ１に接続してスタートする。管理サーバ用プログラム４３のユーザ認証部１９は、ユーザ端末からアクセスしたユーザが、このデータ管理システムを利用する権限を有しているか否かを確認する。この時、ユーザが入力したユーザＩＤやパスワードが適切でない場合、ユーザ認証部１９はユーザ端末に対して処理を続行できない旨のメッセージ等を返し、ＣＰＵ２は処理を中止する。
【００２６】
ユーザが入力したユーザＩＤやパスワードが適切である場合には、ＣＰＵ２は処理を続行する。ユーザは保存したいデータ（以下で説明する「親データ」に相当）をそのファイル名と共に管理サーバ１に送信する。この時点が、図３の「開始」（スタート）に相当する。図３においては、保存したいデータ（親データ）のファイル名を「ＭＡＩＮ」とする。その処理内容はアイコンバッチの新規作成処理であり、保存したいデータとしては、イメージ名が「ｈｏｇｅ．ｊｐｇ」、評価内容が「Ｇｏｏｄ」、使用言語が「日本語」で、カウント値が「１」である。
【００２７】
ステップＳ１として、管理サーバ用プログラム４３のＩＤ生成部１２は、親データのファイル名「ＭＡＩＮ」を受け取り、この「ＭＡＩＮ」のＩＤである親ＩＤを生成する。この親ＩＤは、親データの識別子としてユニークとする必要があることから、他の親データが持つ親ＩＤと重複しないようにしなければならない。このＩＤ生成のために、所定の乱数等を利用することができるが、本実施例ではとりわけハッシュ関数（例えば、ＭＤ５、ＭＤ４、ＳＨＡおよびＨＡＶＡＬ等）を用い、親データからハッシュ値に算出して親ＩＤを生成する。図７では、親データからハッシュ関数により算出したハッシュ値「ｂｄ９８２７３ＭＫＤＨＦ」が親ＩＤとなる。
【００２８】
また、ファイル名管理部１３は、記憶部４のファイル名管理テーブル４１に、親ファイル名「ＭＡＩＮ」と、親データのハッシュ値である親ＩＤとを対応づけて格納する。このファイル名管理テーブル４１としては、例えば、図４に示すように表形式のテーブル構造を利用するが、必ずしもその形式である必要はなく、親ファイル名と親ＩＤとが関連づけられていればよい。
【００２９】
次に、ステップＳ２として、データ分割部１１は、親ファイル名「ＭＡＩＮ」のデータを複数のサブデータに分割する。分割方法やサブデータの数（すなわち、分割数）等については特に制限はないが、各サブデータのデータ量を予め設定してそれに応じて分割数を決めることも可能である。この場合、親データのデータ量が多くなると、分割後のサブデータの数も多くすることが考えられる。ここでは、親ＩＤ「ＭＡＩＮ」のデータを、３つのサブデータ「Ａ」、「Ｂ」および「Ｃ」に分割する。具体例として、図７では３つのサブデータとして、「イメージ名」、「評価」および「言語」に分割している。
【００３０】
ステップＳ３として、データ暗号化部１８は、サブデータ「Ａ」、「Ｂ」および「Ｃ」をそれぞれ暗号化する。この暗号化を行うことにより、サブデータが万一漏洩したとしても、そのデータ内容までの漏洩を防ぐことができる。図７では、暗号化手段により、イメージ名のデータは「ａ９８４ｃｂ６７ａａ」に、評価のデータは「ＢＦＤ５５４３ＤＣ」に、および、言語のデータは「４３ａｅ３４ｅｂｄ１９６ｆ６」に、それぞれ暗号化される。
【００３１】
次に、ステップＳ４として、ＩＤ生成部１２は、ステップＳ３において暗号化したサブデータ「Ａ」、「Ｂ」および「Ｃ」それぞれのＩＤとして、サブＩＤを生成する。図７では、サブデータ「イメージ名」、「評価」および「言語」それぞれのサブＩＤは、先のハッシュ関数を用いてハッシュ値に変換することにより、「０８ｃ２ｂ３ｅ０４８５ａ」、「７ｃ５ｆ９ｅ１７ｃ１」および「５ｅ３１５５７７４ｄ３９ｄ９」となる。そして、ＩＤ管理部１４は、親データの親ＩＤとこのサブデータのサブＩＤとを互いに関連づけてＩＤ管理テーブル４２に格納する。なお、ＩＤ管理テーブル４２としては、先のファイル名管理テーブル４１と同様に、例えば、図５に示すように表形式のテーブル構造を利用するが、必ずしもその形式である必要はない。
【００３２】
最後にステップＳ５として、分散配置部１５は、暗号化したサブデータ「Ａ」、「Ｂ」および「Ｃ」に、それぞれステップＳ４で生成したサブＩＤを付与（ラベル付け）する。そして、各々をネットワーク上の複数の記憶サーバに対して送信する。
暗号化した各サブデータはサブＩＤとセットにして、ネットワークを介して受け取った複数の記憶サーバ６の内、任意の異なる記憶サーバ６（この場合は、３つの記憶サーバ）において、自らのサブデータ保存部６４にクラスタとして格納される。
【００３３】
図７では、サブデータの「イメージ名」については、「ａ９８４ｃｂ６７ａａ」とサブＩＤ「０８ｃ２ｂ３ｅ０４８５ａ」をアイコンクラスタとして、ある記憶サーバ６（例えば、図１１の構成では記憶サーバ６ｂ）に格納される。サブデータの「評価」については、「ＢＦＤ５５４３ＤＣ」とサブＩＤ「７ｃ５ｆ９ｅ１７ｃ１」を評価クラスタとして、異なる記憶サーバ６（例えば、図１１の構成では記憶サーバ６ｄ）に格納される。そして、サブデータの「言語」については、「４３ａｅ３４ｅｂｄ１９６ｆ６」とサブＩＤ「５ｅ３１５５７７４ｄ３９ｄ９」を言語クラスタとして、さらに異なる記憶サーバ６（例えば、図１１の構成では記憶サーバ６ｅ）に格納される。
【００３４】
上述したデータ分割およびデータ暗号化の各処理を介して３分割された各サブデータが、異なる記憶サーバのサブデータ保存部に格納される処理イメージを図８に示す。
ここで、サブデータの格納先となる記憶サーバ６は、そのサブデータ保存部６４に十分な空き容量がある限り、管理サーバ１のＣＰＵ２が任意に選択すればよい。また、冗長性を持たせるために、同一のサブデータを複数の記憶サーバに分散して格納してもよい。
【００３５】
ここで、本発明において、親データを分割化し暗号化する点について説明を加える。分割化は、広義でいう「シリンダー化」を行うことである。一つのテーブルからデータ領域を読み込む際は、指定された箇所のデータＩＤを検索し、このデータＩＤに基づいて格納されているデータを読み出すことになる。しかし、このテーブルデータを読み込む際に、読み込む対象となるデータが巨大なデータ群（ビックデータ）であれば、検索時のソート量が膨大になる。この時、目的となるデータに辿り着くために必要となる時間は、物理メモリのＩＯ速度やＣＰＵの演算処理速度に依存することになる。
【００３６】
そこで、好適な実施態様としては、データをある程度のバイト数、例えば１ギガバイト（１ＧＢ）で区切り、かつ３分割することにより、元のデータをあえて３分割したデータと見なす処理を行う。更には、３分割したデータに対してハッシュ化および暗号化を施す。具体的には、各データをＭＤ５やＳＨＡ等のハッシュ関数によりハッシュ値を算出してそのハッシュ値をサブＩＤとして付与する。また、各データ自体はＤＥＳやＡＥＳ等の暗号化手段により暗号化を施した上で、３つのサブデータとしてファイルに格納する。ここで、分割した各データに対してＤＥＳやＡＥＳ等により暗号化するに際しては、暗号化強度として５１２ｂｉｔの暗号化強度を指定することが望ましい。
【００３７】
暗号化したサブデータは、一般のファイル保存と同じように記憶部の指定位置に保存することも想定できるが、あえて分散処理を行い、自動的に分散する格納先を指定する。また、ハッシュ化されたデータは、ハッシュ関数表（ハッシュテーブル）を基にハッシュ化して個別のサブＩＤとして格納する。そして、読み出し指定する箇所を、ヘッダー部とフッター部の７、１４および２８ビット目に定めて識別番号として記憶し、復元（復号）時に備えるものとする。この点については、ＲＦＣ１３２１に従ったものである。ここで、ＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔ）とは、インターネットに関する技術の標準を定める団体であるＩＥＴＦが正式に発行する文書であって、ＲＦＣ１３２１については、ＭＤ５メッセージダイジェストアルゴリズムに関する国際規格である。
【００３８】
また、３分割をしてハッシュ化および暗号化を施す理由は、万が一ハッキング被害を受けても、それぞれが通常とは異なるデータ群であるため、一方を解析されてしまったとしても復元されることがないことによる。３つ同時に解析しデータ展開してハッシュ関数表を元に復元しなければ、完全復元とはならない。すなわち、堅牢性に非常に優れた格納方法であり、これがシリンダー化および暗号化する所以である。
【００３９】
以上のように、本実施例では、親データが複数の記憶サーバにサブデータとして分割して格納される。なお、セキュリティ性を一層高めるために、親データがユーザ端末より送られてきた時点において、つまり親データの分割を行う前に、データ暗号化部１８がその親データに対して暗号化（１段目の暗号化）を施しておいてもよい。
【００４０】
［データの取り出し］
親データを取り出す処理について、図９のフローチャートを参照して説明する。図９は、管理サーバ１のＣＰＵ２が管理サーバ用プログラム４３を実行し、かつ、記憶サーバ６のＣＰＵ６０が記憶サーバ用プログラム６５を実行することによるデータ取出し処理のフローチャートを示した図である。
【００４１】
また、図１１は、管理サーバ１と複数の記憶サーバ６ａ〜６ｆがネットワークを介してリング状に接続される構成を示す図である。管理サーバ１は、ユーザ端末７と例えばインターネットを介するなどによってやり取りを行う。以下においてデータの取り出し処理を説明するに当たり、サブデータ「Ａ」、「Ｂ」および「Ｃ」は、それぞれ順に、記憶サーバ６ｂ、記憶サーバ６ｄおよび記憶サーバ６ｅにそれぞれ格納されているものとする。
【００４２】
まず、ユーザがユーザ端末（図１１では、ユーザ端末７）を操作することによって、管理サーバ１はユーザ認証部１９によるユーザ認証を経た後に、親データのデータ取出し要求を記憶サーバ１に対して送信する。この操作が、図９の「開始」（スタート）に対応する。このデータ取出し要求には、親データのファイル名が含まれる（ここでは、ファイル名「ＭＡＩＮ」）。
ここで、以下に説明する各ステップの内、ステップＳ１１〜Ｓ１３およびステップＳ１４〜Ｓ１６は、管理サーバ１側の管理サーバ用プログラム４３による処理であり、ステップＳ２１は、各記憶サーバ６側の記憶サーバ用プログラム６５による処理である。
【００４３】
ステップＳ１１として、管理サーバ１側のデータ回収命令部１６は、ユーザからのデータ取出し要求を受けると、ファイル名管理部１３を介してファイル名管理テーブル４１を参照する。これにより、ファイル名「ＭＡＩＮ」に対応する親ＩＤを取り出す。
【００４４】
次に、ステップＳ１２として、データ回収命令部１６は、ＩＤ管理部１４を介してＩＤ管理テーブル４２を参照する。それにより、親ＩＤに対応する複数のサブＩＤ「０８ｃ２ｂ３ｅ０４８５ａ」、「７ｃ５ｆ９ｅ１７ｃ１」および「５ｅ３１５５７７４ｄ３９ｄ９」を取得する。
【００４５】
ステップＳ１３として、データ回収命令部１６は、ネットワークに接続されている各記憶サーバ６に対して順々に（例えば、管理サーバ１に最も近い位置にある記憶サーバ６から順次）、サブＩＤとして、「０８ｃ２ｂ３ｅ０４８５ａ」、「７ｃ５ｆ９ｅ１７ｃ１」および「５ｅ３１５５７７４ｄ３９ｄ９」を付与されたサブデータについて、その格納先を問い合わせると共にデータを回収する命令（以下、「データ問合せ回収命令」という）を送信する。
【００４６】
このステップＳ１３で、管理サーバ１から送信されたデータ問合せ回収命令を受信した各記憶サーバ６の格納先照合部６９は、ステップＳ２１として、それぞれが有する格納先情報保持部６６を参照する。それにより、サブＩＤ「０８ｃ２ｂ３ｅ０４８５ａ」、「７ｃ５ｆ９ｅ１７ｃ１」および「５ｅ３１５５７７４ｄ３９ｄ９」それぞれに対応するサブデータ「Ａ」、「Ｂ」および「Ｃ」（「イメージ名」、「評価」および「言語」）を格納する記憶サーバ６ｂ、記憶サーバ６ｄおよび記憶サーバ６ｅから、それぞれ自らが各サブデータの格納先である通知と共にそのサブデータが、管理サーバ１に対して返送される。
【００４７】
ステップ１４として、管理サーバ１の親データ復元部１７は、上記ステップＳ２１において各記憶サーバ６から返送された各サブデータ「Ａ」、「Ｂ」および「Ｃ」（「イメージ名」、「評価」および「言語」）を回収する。
【００４８】
ステップＳ１５として、親データ復元部１７は、回収した各サブデータを復号化する。この復号化に当たり、回収した各サブデータのハッシュ値を算出し、この算出したサブデータのハッシュ値と、予め各サブデータに付与されたサブＩＤまたはＩＤ管理テーブル４２に格納されているサブＩＤとが一致するか否かを判定する。そして、一致した場合にのみ、回収した各サブデータに対して、図７で示したデータ保管時に用いた暗号化に対応する復号化を施すことにより親データを復元する。
【００４９】
続いて、ステップＳ１６として、親データ復元部１７は、復号化した各サブデータから親データ「ＭＡＩＮ」を復元する。この場合においても、親データ復元部１７が、復元した親データのハッシュ値を算出し、この算出した親データのハッシュ値と、前記ファイル名管理テーブル４１またはＩＤ管理テーブル４２に記憶されている親ＩＤとが一致するか否かを判定する。そして、一致した場合にのみ、復元した親データの利用を可能にする。
【００５０】
ここで、ステップＳ１５およびステップＳ１６において、回収した各サブデータからハッシュ値を算出する時に用いるハッシュ関数、および、復元した親データからハッシュ値を算出する時に用いるハッシュ関数、それぞれは、データの保管時（図７）に使用したハッシュ関数と同一であることも云うまでもないことである。
【００５１】
なお、上述の分散された３分割のサブデータから親データが復元される処理イメージを図１０に示す。
最後に、ステップＳ１７として、ＣＰＵ２は、復元が完了した親データ「ＭＡＩＮ」をユーザ端末（図１１では、ユーザ端末７）に送信して処理を終了する。
【００５２】
以上のように、サブデータの回収時および親データの復元時に、ハッシュ値を利用することにより、回収したサブデータおよび復元した親データそれぞれに対する欠損の発生や改竄の発生等を検出確認することが可能となり、よりデータの欠損・改竄の検出効果を高めることができる。
【００５３】
本発明に係るデータ管理システムについて、実施例により説明を行った。しかし、上述した説明は一例に過ぎないことは明らかで、適宜に変更が可能であることはいうまでもない。
【符号の説明】
【００５４】
１              管理サーバ
２、６０        ＣＰＵ
３、６１        メモリ
４、６３        記憶部
５、６２        ネットワークインターフェース
６、６ａ〜６ｆ  記憶サーバ
７              ユーザ端末
【図１】
2016009030.tif 000003
【図２】
2016009030.tif 000004
【図３】
2016009030.tif 000005
【図４】
2016009030.tif 000006
【図５】
2016009030.tif 000007
【図６】
2016009030.tif 000008
【図７】
2016009030.tif 000009
【図８】
2016009030.tif 000010
【図９】
2016009030.tif 000011
【図１０】
2016009030.tif 000012
【図１１】
2016009030.tif 000013