(57)【要約】【課題】複数の利用者が情報にアクセスする際に情報を適切に選択して提供でき、メンテナンスが容易である蓄積情報アクセス制御方法およびそのプログラムを提供する。【解決手段】本発明の蓄積情報アクセス制御方法は、複数の個人Xiの様々な情報Ii,kが蓄積され、異なる種別の複数の利用者Upがアクセスする蓄積装置Tを有するシステムの蓄積情報アクセス制御方法であって、第1記憶部5に、個人Xiの様々な情報Ii,kがアクセスレベルALlが付けられ、アクセスレベルALlごとに情報Ii,kが蓄積される、第2記憶部4に、利用者Upの種別によって分類した単系列もしくは複数系列の利用者クラスUCqが設定され、利用者クラスUCqに対するアクセスレベルALlの対応付け情報MIを有し、インターフェース部1は、アクセス要求ARjに対し、対応付け情報MIを用いて利用者クラスUCに対応するアクセスレベルALlを判別し、検索部2は、そのアクセスレベルALに対応した情報にアクセスする。【選択図】図4
2016115997.tif 000002
【特許請求の範囲】
【請求項１】
複数の個人（Xi）に関する様々な情報（Ii,k）が蓄積され、異なる種別の複数の利用者（Up）が前記情報にアクセスする蓄積装置（T）を有し、前記蓄積装置（T）は、第1記憶部（5）と第2記憶部（4）とインターフェース部（1）と検索部（2）とを有するシステムの蓄積情報アクセス制御方法であって、
前記第1記憶部（5）に、前記個人（Xi）に関する様々な情報（Ii,k）がその内容によってアクセスレベル（ALl）が付けられ、前記アクセスレベル（ALl）ごとに前記情報（Ii,k）が蓄積されるとともに、
前記第2記憶部（4）に、前記利用者（Up）の前記種別によって分類した単系列もしくは複数系列の利用者クラス（UCq）が設定され、前記利用者クラス（UCq）に対する前記アクセスレベル（ALl）の対応付け情報（MI）を有し、
前記インターフェース部（1）は、認証した前記利用者（Up）からのアクセス要求（ARj）に対し、前記対応付け情報（MI）を用いて前記利用者クラス（UCq）に対応する前記アクセスレベル（ALl）を判別し、
前記検索部（2）は、前記アクセスレベル（ALl）に対応した前記情報（Ii,k）にアクセスする
ことを特徴とする蓄積情報アクセス制御方法。
【請求項２】
前記第1記憶部（5）には、前記情報（Ii,k）が前記アクセスレベル（ALl）ごとの暗号鍵（Kl）により暗号化（E）されて暗号済情報（EIi,k）として蓄積され、
前記インターフェース部（1）は、認証した前記利用者（Up）からのアクセス要求（ARj）に対し、前記対応付け情報（MI）を用いて前記利用者クラス（UCq）に対応する前記アクセスレベル（ALl）を判別し、
前記検索部（2）は、判別された前記アクセスレベル（ALl）に対応した前記暗号鍵（Kl）を用いて、当該アクセスレベル（ALl）の前記暗号済情報（EIi,k）にアクセスする
ことを特徴とする蓄積情報アクセス制御方法。
【請求項３】
前記第1記憶部（5）には、前記アクセスレベル（ALl）に関する情報（AIl）と前記暗号済情報（EIi.k）とを組にして蓄積される
ことを特徴とする請求項2に記載の蓄積情報アクセス制御方法。
【請求項４】
前記利用者クラス（UCq）は、
前記利用者（Up）の種別といったパブリックな単系列もしくは複数系列のオープン利用者クラス（UCoq）と、前記利用者（Up）と蓄積された前記個人（Xi）との私的なまたは個人的な関係の関連性（R）から定められる単系列もしくは複数系列のクローズ利用者クラス（UCcq）とを有する
ことを特徴とする請求項1から請求項3の何れか一項に記載の蓄積情報アクセス制御方法。
【請求項５】
前記クローズ利用者クラス（UCcq）の前記アクセスレベルの対応付けは、個々の情報に対して前記関連性（R）に対応する前記アクセスレベルとその関連性（R）の許容適用回数を含む関連性情報（RIc）を有する
ことを特徴とする請求項4に記載の蓄積情報アクセス制御方法。
【請求項６】
前記第1記憶部（5）には、前記情報（Ii,k）が前記アクセスレベル（ALl）ごとの暗号鍵（Kl）により暗号化（E）されて暗号済情報（EIi,k）として蓄積され、
前記第1記憶部（5）には、前記アクセスレベルに関する情報（AIl）とともに、前記利用者と前記個人（Xi）の前記関連性（R）の適用に関する関連性情報（RIc）が前記暗号済情報（EIi,k）と組になって蓄積される
ことを特徴とする請求項5に記載の蓄積情報アクセス制御方法。
【請求項７】
前記蓄積装置（T）は、第3記憶部を有し、
前記インターフェース部は、
前記個人の前記関連性（R）とその適用に関する関連性情報（RIc）によって、前記個人（Xi）からの到達可否を予め計算するとともにその計算結果（I）を前記第３記憶部に蓄積し、利用者(Up)が検索可能であるかどうかを前記計算結果（I）で判定する
ことを特徴とする請求項5または請求項6に記載の蓄積情報アクセス制御方法。
【請求項８】
前記第1記憶部（5）には、前記情報（Ii,k）が前記アクセスレベル（ALl）ごとの暗号鍵（Kl）により暗号化（E）されて暗号済情報（EIi,k）として蓄積され、
前記暗号済情報（EIi,k）と組にして蓄積された前記アクセスレベルに関する情報（AIl）と前記関連性に対応する前記関連性情報（RIc）、または、
前記アクセスレベルに関する情報（AIl）と前記関連性に対応する前記関連性情報（RIc）から対応づけられる暗号鍵（Kl）の適用の方法
のうちの少なくとも何れかが変更可能である
ことを特徴とする請求項5から請求項7のいずれか一項に記載の蓄積情報アクセス制御方法。
【請求項９】
前記暗号化（E）の方式として、前記個人に関する情報（Ii,k）と前記暗号鍵（Kl）に対して前記暗号済情報（EIi,k）が一意に決定する暗号化方式（EM）を用いられ、
前記利用者（Up）の検索アクセスの条件（Cp）のリテラル部分が、前記暗号化方式（EM）で暗号済条件（ECp）に暗号化され、
前記検索部（2）は、
前記暗号済条件（ECp）と前記暗号済情報（EIi,k）とを暗号化したままで同一性を判定する検索を行う
ことを特徴とする請求項2または請求項3に記載の蓄積情報アクセス制御方法。
【請求項１０】
前記暗号化方式（EM）公開鍵方式の暗号が用いられ、
前記利用者（Up）の前記検索アクセスの条件（C）が前記利用者（Up）が持つ公開鍵（PKup）で暗号化され利用者公開鍵暗号条件（ECup）とされ、
前記インターフェース部（1）は、前記利用者（Up）を認証した後、その前記オープン利用者クラス（UCoq）に前記対応付け情報（MI）によって前記アクセスレベル（ALl）に対応づけられる公開鍵（PKal）で前記利用者公開鍵暗号条件（ECup）をアクセスレベル公開鍵暗号条件（ECal）に再暗号化（RE）し、
前記検索部（2）は、
前記アクセスレベル（ALl）で暗号化したアクセスレベル公開鍵暗号条件（ECal）と前記暗号済情報（EIi,k）との同一性を判定して暗号化された暗号化検索結果（EAal）を得、
前記インターフェース部（1）は、前記検索結果（EAal）を前記利用者（Up）の公開鍵（PKup）で再暗号化して利用者公開鍵検索結果（EAup）として前記利用者（Up）に返す
ことを特徴とする請求項9に記載の蓄積情報アクセス制御方法。
【請求項１１】
前記システムは、前記蓄積装置（T2）とは別にプロキシ（P）が設けられ、
前記利用者（Up）の認証と、前記対応付け情報（MI）を用いた前記利用者公開鍵暗号条件（ECup）から前記アクセスレベル公開鍵暗号条件（ECal）への前記再暗号化（RE）、および前記暗号化検索結果（EAal）から利用者公開鍵検索結果（EAup）への前記再暗号化（RE）を、前記プロキシ（P）で行う
ことを特徴とする請求項10に記載の蓄積情報アクセス制御方法。
【請求項１２】
前記蓄積される情報（Ii,k）の形式がRDF (Resource Description Framework)で表現されている
ことを特徴とする請求項1から請求項11のいずれか一項に記載の蓄積情報アクセス制御方法。
【請求項１３】
請求項1から請求項12のいずれか一項に記載のアクセス制御方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多数の個人の情報に多数のユーザがアクセスする際に情報を選択して提供する手法に係る蓄積情報アクセス制御方法およびそのプログラムに関する。
【背景技術】
【０００２】
例えば、大規模な災害時等に、被災者の様々な情報を用いて医師が何かをする場合、性別や年齢だけでなく、妊娠しているといった情報や病状の情報も必要となる。一方、地方自治体の職員には被災者が妊娠していることは知らせる必要がないかも知れない。さらに、災害現場に出向いたボランティアには、被災者の年齢も知らせる必要はない。
【０００３】
このように、情報にアクセスする利用者の立場によって、アクセスできる範囲が異なるのが通例である。一方、これらの情報から、災害現場に必要な医薬品や食料品、物資等の情報を抽出することが重要となる。
【０００４】
上記のような個人に関する情報を蓄積する場合、プライバシー保護の観点から、秘匿性確保のためにデータを匿名化（anonymization）、あるいは暗号化（encryption）して、データベースに蓄積することが行われる。匿名化の場合、秘匿性確保のために、仮名化処理、統計化処理、あるいは属性削除等が行われる。そのような匿名化する技術をグラフ構造やRDF(Resource Description Framework)(詳細は後記)に適用する技術は既に存在する。
【０００５】
非特許文献1には、グラフ構造のクラスに匿名化を行う研究の例が示されている。
非特許文献2には、RDFに対する仮名化や属性削除等による匿名化の研究の例が示されている。
【０００６】
このような匿名化のアプローチは、特定の利用者に対して統計処理のみを行ってデータを提供する場合等には有効であるが、前述したような異なる立場の利用者に対して、場合によっては匿名化していない情報も提供しなければならない場合には必ずしも十分ではない。つまり、匿名化のアプローチは、本発明が対象とする状況、すなわち多数の個人の情報に多数のユーザがアクセスする際に情報を選択して提供する状況には向いていない。
【０００７】
一方、暗号化して、利用者の立場で使い分けることで、上記のような立場によって正確なデータを提供するといった要求にも対処することができる。データを暗号化してデータベースに格納する技術や、RDFを部分に分けて暗号化する技術も既に存在する。
【０００８】
非特許文献3には、データを暗号化してデータベースに格納する最近の研究の例が示されている。
【０００９】
非特許文献4には、RDFの部分を暗号化する研究の例が示されている。
例えば、RDF記述の場合、「私の性は女性(female)です」、「私の歳は32です」、「私は妊娠(pregnant)しています」、「私はコミュニティセンター(community center)にいます」の各Subject(主語)、Predicate(述語)、Object (目的語)を別々に暗号化し、female、32、pregnant、community center といったそれぞれの内容に関して異なる暗号鍵（以降単純に鍵と呼ぶ）を割り当て、医者や自治体職員やボランティアといった利用者（Up）に渡す。これによって、それぞれの鍵を使って、対象とするデータにアクセスすることは可能である。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開2005-124149号公報
【非特許文献】
【００１１】
【非特許文献１】Bhagat, S., Cormode, G., Krishnamurthy, B., & Srivastava, D. Class-based graph anonymization for social network data. Proceedings of the VLDB Endowment, 2(1), pp.766-777, 2009.
【非特許文献２】Rachapalli, J., Khadilkar, V., Kantarcioglu, M., & Thuraisingham, B. Towards fine grained RDF access control. In Proceedings of the 19th ACM symposium on Access control models and technologies, pp. 165-176, ACM. 2014.
【非特許文献３】Popa, R. A., Redfield, C., Zeldovich, N., & Balakrishnan, H. “Cryptdb: protecting confidentiality with encrypted query processing.” In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. pp. 85-100. ACM. 2011.
【非特許文献４】Giereth, Mark. On partial encryption of RDF-graphs. In: The Semantic Web-ISWC 2005. pp. 308-322. Springer, 2005.
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかし、本発明が対象としているような多数の人物（Xi）の情報が蓄積され、該情報にアクセスする利用者（Up）も増えた場合、各人物（Xi）の情報の鍵（K）の管理は煩雑となる。以下に、考えられる Case1、2を示す。
【００１３】
Case 1： 人物Xiと人物Xjといったように、対象人物毎に鍵を割り当てると、対象人物の数とその情報の種類kを掛けた数の鍵が必要となり、非常に多数の鍵をもって使い分ける必要が生じる。特に、災害時の避難民などを対象とすると、人数は大きくなる。つまり、人物Xiのどの情報をアクセスする鍵は、利用者（Up）の中の誰と誰が持つかということを全員分管理する必要がある。さらに、利用者（Up）の権限を変更したい場合にはどうするかということも個々に扱う必要あり、鍵の管理コストは膨大となる。
【００１４】
Case 2：各個人ではなく、医師がアクセスする鍵、自治体職員がアクセスする鍵といった形で、アクセスを許可するグループごとに同一の鍵を割り当てると、例えばボランティアを辞めた場合には、そのボランティアに渡した鍵を無効化するため、新たな鍵によってデータを再暗号化して、新しい鍵を該当する利用者に配布する必要が生じる（このような処理はリボケーションと呼ばれる）。さらに、災害時等を想定すると、家族や友人といった個人的関係者にだけ情報を提供する場合も想定できるが、それらと上述した鍵を同一にして渡してしまうと、本来アクセス権限の無いデータにアクセスができてしまうという問題が発生する。また、グループの自由度もない。
【００１５】
非特許文献1〜4を含め、これまでにこれらの問題点を解決する手法は提案されていない。特許文献1は、ユーザをグループ化しているが、メンバーが変更した場合には、同様に、メンバー取り消しを行うリボケーションにおいてデータの再暗号化と鍵の再配布の必要性が発生する。
【００１６】
以上、まとめると、個人情報のアクセスに関しては、匿名化や暗号化によりプライバシーを保護しているが、利用を広げるには暗号化が望ましい。暗号化方式では、利用者の立場に応じてアクセス許可を与え復号化キーを提供する。そのため、利用者ごとに暗号化、復号化の管理が必要で階層が多くなると複雑となる。
一方、利用者の立場が変化した場合、暗号化しなおす処理が必要となる欠点がある。また、利用者と蓄積データとの相対的な関係を持ちこむことができない。
【００１７】
本発明は上記実状に鑑み創案されたものであり、複数の個人の情報に複数の利用者がアクセスする際に情報を適切に選択して提供できるとともにメンテナンスが容易である蓄積情報アクセス制御方法およびそのプログラムの提供を目的とする。
【課題を解決するための手段】
【００１８】
前記課題を解決するため、第1の本発明のアクセス制御方法は、複数の個人（Xi）に関する様々な情報（Ii,k）が蓄積され、異なる種別の複数の利用者（Up）が前記情報にアクセスする蓄積装置（T）を有し、前記蓄積装置（T）は、第1記憶部（5）と第2記憶部（4）とインターフェース部（1）と検索部（2）とを有するシステムの蓄積情報アクセス制御方法であって、前記第1記憶部（5）に、前記個人（Xi）に関する様々な情報（Ii,k）がその内容によってアクセスレベル（ALl）が付けられ、前記アクセスレベル（ALl）ごとに前記情報（Ii,k）が蓄積されるとともに、前記第2記憶部（4）に、前記利用者（Up）の前記種別によって分類した単系列もしくは複数系列の利用者クラス（UCq）が設定され、前記利用者クラス（UCq）に対する前記アクセスレベル（ALl）の対応付け情報（MI）を有し、前記インターフェース部（1）は、認証した前記利用者（Up）からのアクセス要求（ARj）に対し、前記対応付け情報（MI）を用いて前記利用者クラス（UCq）に対応する前記アクセスレベル（ALl）を判別し、前記検索部（2）は、前記アクセスレベル（ALl）に対応した前記情報（Ii,k）にアクセスすることを特徴としている。
【００１９】
第2の本発明のプログラムは、第1の本発明のアクセス制御方法をコンピュータに実行させるためのプログラムである。
【発明の効果】
【００２０】
本発明によれば、複数の個人の情報に複数の利用者がアクセスする際に情報を適切に選択して提供できるとともにメンテナンスが容易である蓄積情報アクセス制御方法およびその制御プログラムを提供することができる。
【図面の簡単な説明】
【００２１】
【図１】情報のRDF形式での表現をグラフ構造で表わした図。
【図２】UCoとUCcとALとそれらの対応付けの例を示す図。
【図３】本発明に係る実施形態1の蓄積情報アクセスシステムのハードウェアの構成図。
【図４】実施形態1の蓄積情報アクセスシステムの処理を示す概念図。
【図５】実施形態1の蓄積情報アクセスシステムの手順を示すフローチャート。
【図６】本発明に係る実施形態２の蓄積情報アクセスシステムのハードウェアの構成図。
【図７】実施形態2の蓄積情報アクセスシステムの処理を示す概念図。
【図８】実施形態2の蓄積情報アクセスシステムの手順を示すフローチャート。
【発明を実施するための形態】
【００２２】
以下、本発明の実施形態について、適宜図面を参照しながら詳細に説明する。
＜本発明の概要＞  
本発明は、個人情報へのアクセス制御の手法に関する。
本発明では、情報の利用者は、上下に順序付けされる利用者クラスに分類される。一方、蓄積される情報は上下に順序付けされるアクセスレベルに分類される。
そして、利用者クラスとアクセスレベル間のマッピング(関連付け)が行われる。
【００２３】
利用者は、利用者クラスに対応付けられた(マッピングされた)情報のアクセスレベルに応じて情報へのアクセスが制限される。蓄積される情報は、アクセスレベルごとの暗号鍵により暗号化され、復号化される。
【００２４】
利用者クラスとしては、相互関係がない利用者の種別を表現するオープンクラスと、プライベートなどの相互関係があるクローズクラスとを持つ。
オープンクラスでは、医師、自治体職員、ボランティアなどの種別や属性によりアクセスレベルが定められる。一方、クローズクラスでは、上司、部下や家族関係などがネットワークにて表現され、利用者の私的な関係、個人的な関係などの属性に応じてアクセス可否が変化する。
【００２５】
＜RDF＞
個人に関するような情報の場合、RDF(Resource Description Framework)の形式で格納するとよい。そこで、対象とする個人（Xｉ）(i番目の個人)に関する情報は、以下ではRDFで記述される。しかし、XMLや他の記述手法によって表現されていてもよい。
【００２６】
RDF は、主語（Subject）、述語（Predicate）、目的語（Object）のトリプルで表現される。以降、このトリプルを {Subject, Predicated, Object} のように記述する。
例えば「X1の名前はaliceである」の主語は「X1」、述語は「名前」、目的語は「alice」であり、{X1、name、alice}と記述される。
【００２７】
同様に、「X1の性別（gender）は女性（female）」、「X1の年齢（age）は27」、「X1は妊娠（pregnant）している」、「X1は公民館（community-center）にいる」、「X1の識別子(id)はalice@x.jp」等は、それぞれ
{X1, gender, female}
{X1,  age, 27}
{X1, condition, pregnant}
{X1, stay at, community-center}
{X1, id, alice@x.jp}
のように記述される。
【００２８】
また、Subject(主語)間で「X2はX1の親（parent of）」ということも、
{X2, parent of, X1}
のように記述できる。
これらにより人物の情報は、図1に示すようなグラフ構造が対応する。なお、図1は、情報のRDF形式での表現をグラフ構造で表わしたものである。
【００２９】
＜発明手法＞
まず、医師、自治体職員、ボランティア、あるいは家族、友人という利用者（Up）をクラス（UC: User Class）に分ける。
また、蓄積された情報を、該情報へのアクセスのレベル（AL: Access Level）に分ける。
次に、UCと AL間の対応付け（M:Mapping）を行い、その対応付け情報（MI: Mapping Information）をシステムで保持する。
【００３０】
ここで、前記のCase 2 と異なるのは、UC（User Class）毎に暗号鍵を持つのではなくAL（Access Level）毎に暗号鍵を持ち、利用者の認証後にUCとALを対応付ける。これにより、利用者や情報に係る人物のメンバーの変更といったリボケーションにおいて対応付けM（ Mapping）を変えるだけで、再暗号化と新しい暗号鍵の配布が不要となる。なお、上記クラスは、非特許文献1が対象とするグラフ構造のクラスとは、利用者のクラスという点で全く異なる。
【００３１】
さらに、医師、自治体職員、ボランティアといったUC（ User Class）は、図1に示す個々のデータのグラフ上の接続関係には関係のなくパブリックなオープン利用者クラスUCO  として扱う。
【００３２】
一方、利用者の家族、友人、あるいは教師、クラスメート、上司や部下といったUC（User Class）は、図1に示す各個人のグラフ上の接続関係によりアクセスの可否が変化するプライベートなクローズ利用者クラス UCc として分別する。クローズ利用者クラス UCc とは、いわば私的なまたは個人的な接続関係があることを意味する。つまり、UCo は、グラフ全体のアクセスに対する利用のレベルを規定するクラスであるのに対して、UCc は、グラフの中で関係者のみに対して利用のレベルを規定するクラスであり、UCoもUCcも複数種類が想定可能である。
【００３３】
図2にUCoとUCcとALとそれらの対応付けの例を示す。
図2に示すように、AL（Access Level）、 UCo（オープン利用者クラス）、UCc （クローズ利用者クラス）の中の各要素の間には半順序関係（PartialOrder）があり、それぞれのクラスとして束 (Lattice) を構成している。
束において、上界 (Top) に近い要素は、その下の要素がアクセス可能な情報にアクセスできることを意味する。例えば、UCoのボランティアやUCcの友人は利用者のクラスが“2”であり、L（レベル）2である氏名（Name）や性別（Gender）の他に、ALがその下であるL1の避難場所（Location）の情報を得ることもできる。
【００３４】
一方、UCoで、ボランティアの下の利用者のクラスの一般市民（Citizen）や、UCc の他人は、ALがL2である情報は得られず、対応付けMで示されるように、ALがL1である避難場所（Location）の情報のみ得られる。
なお、UCと階層関係やUCとALの対応付け情報（MI：Mapping Information）は変更可能であり、それ自体をRDF等で記述して蓄積しておくこともできる。
【００３５】
＜RDFでのデータの記述＞
RDFで記述する場合、例えば、UCの階層関係については、
{Medical Person, higher of, Public Officer}（医者は自冶体職員より上）
{Public Officer, higher of, Voluntary Helper}(自冶体職員はボランティアより上)  ………  と記述できる。
【００３６】
UCとALの対応付けについては、
{Medical Person, mapping to, 4}(医者はALのL4と対応付けられる)
{Public Officer, mapping to, 3}(自冶体職員はALのL3と対応付けられる)  ………  と記述できる。
【００３７】
また、典型的なPredicated に対応するALのレベル情報としては、
{Physical Condition, access lever, 4}(体の状態はアクセスレベルが4)
{Age, access level, 3}(年齢はアクセスレベルが3)  ………  等と記述できる。これは、個人情報にAL（Access Level）を対応付ける場合に指針として使うことができる。
【００３８】
UCcについても同様であり、更に付加情報として、親や兄弟は家族の一種であるといった
{Parent of, a kind of, Family of}
{Brother of, a kind of, Family of}
という情報も保持できる。これらは、データベース全体で静的な対応付けであるが、対応付け自体は状況によって、例えば地方自治体職員（Public Officer）のレベルを上げる等の変化をさせることもできる。
【００３９】
＜暗号＞
あるAL（Access Level）以下に対応する UC（利用者クラス） の利用者に対する秘匿性を確保するために暗号を用いる。
以下、個人（Xi）に関する情報（Ii,k）（i目の個人のk番目の情報）とALのl（エル）番目のレベル（ALl）に対応づけられる暗号鍵（Kl）を用いて情報（Ii,k）を暗号化した暗号済情報（EIi,k）が一意に定まる決定性暗号化手法を前提とする。これは、検索のアクセスを考えた時、検索条件（C）を同じ鍵（Kl）で暗号化して、暗号化したもの同士で同一性の判定を行い、検索結果を探し出すための前提である。しかし、サーバの蓄積装置S(図3、図4参照)内で復号化してから検索する等の場合には、この決定性暗号化手法は必ずしも必要ない。
【００４０】
また、秘匿性を高めるために、別のサーバであるプロキシP(図6、図7参照)を用いて、プロキシP上で再暗号化を行う場合を想定して、決定性を持つ公開鍵暗号方式を前提として以下説明を行う。
しかし、蓄積装置Sやその管理者が十分信頼できる場合には、秘密鍵暗号方式でも同様にUCとALを対応づけたアクセス管理は可能である。
【００４１】
一方、検索条件として、同一性の比較だけでなく、年齢が何歳以上というような大小の  比較を行う場合には、決定性だけでなく比較処理が可能な暗号化方式を用いる必要がある。さらに、必要な医薬品や物資の数を算出することを前提とする場合には、暗号化したまま加算、乗算が可能な準同型暗号を用いることが必要となる場合が想定される。以下では、決定性を持つ公開鍵暗号方式で、必要に応じで大小比較可能性があり、或いは暗号化したまま加算、乗算する準同型演算が可能という前提で説明を行うが、主発明としては暗号化方式については特に規定しない。
【００４２】
また、以下では説明のため、蓄積されるデータの形式としては、RDFを前提とし、関係データベースを利用してタプル（行）として蓄積するとして説明を行うが、個人の情報が個々に表現できるものであれば、RDF形式に限られるものでも、関係データベースに限られるものでもない。
【００４３】
RDF形式で記述された全てのデータは、ALのl（エル）番目のレベル (ALl) に対応した公開鍵 (PKal) で暗号化されて関係データベースに格納される。人物（Xi）のk番目の情報Ii,kは、それぞれに暗号化された Si,k (Subject)、Pi,k (Predicate)、Oi,k (Object) を組として関係データベースの1つのタプルに保存される。
【００４４】
そして、同一タプル内に、その暗号済情報（EIi,k）にアクセス可能なオープン利用者クラスに対応する最上位のALのレベルの情報（AIl）と、クローズ利用者クラスの関連性からアクセス許可に関する情報（RIc）を格納する。RIcの表現方式としては、UCcに対応するALと、友人の友人といった関連性の繰り返し回数の組で示すことが考えられる。
【００４５】
なお、繰り返しは同一の関連性のみの場合と、異なる関連性も許す場合が考えられる。これらのAIlとRIc、Si,k、Pi,k、Oi,k は、個人（Xi）に関する情報（Ii,k）それぞれに対して提示すべきものである。
それと同時に、個人（Xi）に関する情報（Ii,k）は、暗号化されることが望ましく、ここではシステム共通の公開鍵（PKs）で暗号化する前提とする。
【００４６】
なお、AIlとRIcについては、暗号化されていなくても、直接データ漏洩にはつながらない。公開鍵PKx で暗号化された情報Iをe(PKx, I)で表わすと、関係データベースに格納される１つのタプル（行）は、
[e(PKs,(AIl1,RIc1)), e(PKal1,Si,k), e(PKs,(AIl2,RIc2)), e(PKal2,Pi,k), e(PKs,(AIl3,RIc3)), e(PKal3,Oi,k)]
という形でデータベース中に蓄積されることを想定する。
【００４７】
あるいは、AP部分のe(PKs,(AIl1,RIc1)), e(PKs,(AIl2,RIc2)), e(PKs,(AIl3,RIc3))をまとめて、
[e(PKs,(AIl1,RIc1,AIl2,RIc2,AIl3,RIc3)), e(PKal1,Si,k), e(PKal2,Pi,k), e(PKal3,Oi,k)]
のような形で、蓄積装置Sに蓄積することも想定できる。実際には、それぞれの部分は暗号化されているため、
[110…01, 1010…01, 1110…10, 0101…11] のように、それだけでは判別できない「1」または「0」のビット列で蓄積される。なお、公開鍵(PKx)で暗号化されたものは、対応する秘密鍵SKxで復号できる。
【００４８】
例えば、前記したRDFが以下のようにALとUCcを指定されて暗号化されているとする。ここで、pk1はAL（Access Level）のアクセスレベル1に対応した公開鍵を意味する。
[e(pks,(1,[0],3,[2-3,3-3,4-3],3,[2-3,3-3,4-3])), e(pk1, X1), e(pk3, name), e(pk3, Alice)]         1行目
[e(pks,(1,[0],2,[2-2,3-3,4-3],2,[2-2,3-3,4-3])), e(pk1, X1), e(pk2, gender), e(pk2, female)]        2行目
[e(pks,(1,[0],3,[3-1,4-2],3,[3-1,4-2])), e(pk1, X1), e(pk3, age), e(pk3, 27)]                      3行目
[e(pks,(1,[0],4,[4-1],4,[4-1])), e(pk1, X1), e(pk4, condition), e(pk4, pregnant)]                   4行目
[e(pks,(1,[0],1,[0],1,[0])), e(pk1, X1), e(pk1, stay-at), e(pk1, community-center)]                 5行目
[e(pks,(1,[0],4,[4-1],4,[4-1])), e(pk1, X1), e(pk4, id), e(pk4, alice@x.jp)]
[e(pk3,(1,[0],3,[4-3],3,[4-3]])), e(pk1, X2), e(pk3, parent-of), e(pk3, X1)]
【００４９】
これらのタプルが示しているイメージとしては、X1 （ここではアリスを例示する）という人物が（名前や性別等は分からないが） 公民館（community center）にいるということは、上記の5行目のタプルから、アクセスレベル1に対応するオープン利用者クラス“1”およびクローズ利用者クラス“1”の誰でもアクセスすることができる。例えば、アクセスレベル1の誰でもX1の情報を取得して、カウントして人数集計等に使える。そのため、利用者との関係は用いないため、[0]となっている。
【００５０】
また、X1という人物の年齢“27”については、上記の3行目のタプルから、アクセスレベル３に対応する自治体職員（Public Officer）のクラスにはアクセス可能としている。また、年齢“27”については、X1のクローズ利用者クラス“3”の教師（Teacher of）や、ALが“4”のクローズ利用者クラス“3”の家族（Family of）あるいは叔父叔母といった家族からの2段階の繰り返しの人物にもアクセスできるとしている。例えば、図1に示すX1から2段階の繰り返しの人物である。
【００５１】
一方、X1という人物が妊娠（pregnant）していることは、上記の4行目のタプルから、最上位のAL“4”のアクセス可能なオープン利用者クラス“4”の医療メンバー（Medical Person）のクラス、または、ALが“4”に対応するアクセス可能なクローズ利用者クラス“4”のその家族しかアクセスできないことを示している。
【００５２】
このような情報に対する問い合わせとして、RDFに対する問い合わせで一般的に用いられる SPARQL を想定する。SPARQL は、変数を用いてグラフとパターンマッチングを行うWHERE部分と、出力する変数を指定する SELECT 部分を主としている。読みやすさのために PREFIX 部分で簡略形を記述できるが、あくまでも記述の簡略化のためのため、ここでは省略する。
【００５３】
例として、公民館（community-center）に避難している女性（female）の名前（name）と年齢（age）を尋ねる以下のような SPARQL問い合わせを想定する。SPARQL問い合わせは、以下のように記述される。
SELECT ?b, ?c
WHERE {?a, stay at, community center}∧{?a, gender, female}∧{?a, name, ?b}∧{?a, age, ?c}
【００５４】
ここで 、?a、?b、?c はそれぞれ変数を表わす。この問い合わせのWHERE 部分とデータベース中のRDFとでパターンマッチングを行い、SELECT 部分で示す求める変数 ?b、?cに対応するデータを出力する。
【００５５】
もし、この問い合わせを行ったのがボランティア (Voluntary Helper) で、個人的関係のある女性が公民館（community center）にいない場合には、ボランティアのUCoに対応するAL（Access Level）が“2”であるため、nameやgender にはアクセスできるが、ALが“3”のageの属性にはアクセスできず、答えは返ってこない。
【００５６】
一方、利用者がオープン利用者クラスが“4”の自治体職員 (Public Officer) の場合には、対応するALが“3”のため、ALが“2”のnameやgender の他に ALが“3”のageにもアクセスでき、年齢 27 という情報が帰ってくる。
【００５７】
あるいは、利用者が alice と同じ場所に避難している場合には図2からクローズ利用者クラスが“2”である。そのため、前記タプルの3行目よりageにアクセスできるのはALが“3”または“4”のために、nameやgenderにはアクセスできるが、ageにはアクセスできない。
【００５８】
しかし、利用者が aliceの家族である場合には、図2からクローズ利用者クラスが“4”でありALが“4”であるので、オープン利用者クラスが“1”の一般市民 (citizen) であっても答えが帰ってくる。
【００５９】
以下、本発明の実施形態を示す。
＜＜実施形態1＞＞
図3は、本発明に係る実施形態1の蓄積情報アクセスシステムのハードウェアの構成図である。
実施形態1の蓄積情報アクセスシステムSは、蓄積装置Tであるサーバが外部からのアタックに対して十分堅牢で、サーバの管理者が信頼できる場合のものである。サーバあるいはその管理者が完全には信頼できない場合については、実施形態2で述べる。
【００６０】
蓄積情報アクセスシステムSは、複数の利用者U(U１、………、UP、………、Unｕ)のパソコンが、ネットワークを介して、蓄積装置Tに接続されている。
複数の利用者とは、前記したように、蓄積装置Tに蓄積される個人情報にアクセスして取得しようとする人々である。
蓄積装置Tは、利用者インターフェース部1と、検索処理部2と、利用者情報DB3と、対応付情報DB4と、暗号済個人情報DB5とを備えている。但し、図3において、DB（データベース）の文言は不記載とする。これは他の図4，6，7においても同様とする。
【００６１】
図4は、実施形態1の蓄積情報アクセスシステムの処理を示す概念図である。
全利用者Upは、システム上、利用者のクラスUC1、…、UCr、…、UCnqにクラス分けされている。
利用者情報DB3には、個人情報にアクセスする利用者の情報（利用者情報UI）が記憶されている。例えば、利用者UpのUC0（ オープン利用者クラス）とUCC（クローズ利用者クラス）のクラス分けされた情報や、図1に示す利用者UpのUCC（クローズ利用者クラス）の関連性の情報が記憶されている。
【００６２】
対応付情報DB4には、利用者のクラス(オープン利用者クラス、クローズ利用者クラス)がアクセスできる個人情報のAL（Access Level）とが関連付けられ、対応付け情報MIとして記憶されている。換言すれば、利用者のクラスがアクセスできる個人情報のALに対応付け（マッピング）されている。例えば、利用者UpはAL2（アクセスレベル2）にクラス分けされる。
【００６３】
暗号済個人情報DB5は、個人情報のAL毎にAL毎の暗号鍵K1、……、Kｎで暗号化された個人情報（暗号済情報EI）が、AL毎（AL1、AL2、……ALn）にクラス分けされ記憶されている。
【００６４】
詳細には、暗号済個人情報DB5には、個人（X１）の情報I1、1、I1、2、Ｉ1、3がそれぞれALｎ（Access Levelがn）、AL1、AL2、……、ALnにクラス分けされ、暗号鍵Kｎ、K１、K２を用いて暗号化され蓄積されている。同様に、個人（Xｍ）の情報Im、1、Im、3、Im、4がそれぞれAL（Access Level）に区分けされ、AL毎の暗号鍵Kで暗号化されて蓄積されている。
【００６５】
利用者インターフェース部1は、ログインされる利用者(利用者端末で入力された利用者Upでのログイン情報）の認証を、例えば乱数、公開鍵、利用者情報DB3、対応付情報DB4の各情報等を用いて行う。
【００６６】
まず、利用者インターフェース部1は、利用者のログイン情報に対して乱数を発生し、その乱数を公開鍵によって暗号化して、利用者端末に送る。利用者端末では、受けた暗号文を利用者の秘密鍵を用いて復号化し、その乱数を複合化したことが分かるように問い合わせ文に組み込み、その問い合わせを利用者インターフェース部1の公開鍵によって暗号化して利用者インターフェース部1に送る。利用者インターフェース部1では、利用者インターフェース部1が持つ秘密鍵でその暗号化された問い合わせを復号化し、その中に利用者に送った乱数が含まれているかどうかによって、アクセスの可否を判定する。送った乱数と異なる場合には、アクセス否となり、利用者は蓄積情報アクセスシステムSの利用はできない。一方、アクセス可の場合、利用者インターフェース部1は、利用者情報DB3、対応付情報DB4の各情報を用いて、利用者がアクセスできる個人情報がどの個人情報のALであるかを取得する。そして、利用者インターフェース部1は、利用者からの暗号化された要求の利用者暗号条件ECupの暗号化されたリテラルを、オープン利用者クラスUCoqに対応するALr以下のレベルのALの公開鍵で再暗号化し、アクセスレベル公開鍵暗号条件ECalとして蓄積装置Tに送る。
【００６７】
蓄積装置Tの検索処理部2は、利用者の要求のアクセスレベル公開鍵暗号条件ECalを用いて、暗号済個人情報DB5を検索する。検索後、検索処理部2は、暗号検索結果EAa1を利用者インターフェース部1に送る。利用者インターフェース部1は、当該利用者の公開鍵で暗号検索結果EAalを再暗号化REして暗号検索結果EAupを得る。その後、利用者インターフェース部1は、暗号検索結果EAapを利用者Upのパソコンに送る。利用者UPは、パソコンで利用者暗号検索結果EAapを秘密鍵で解読する。
【００６８】
＜蓄積情報アクセスシステムSの手順＞
図5は、実施形態1の蓄積情報アクセスシステムの手順を示すフローチャートである。
以下の手順は、プログラム言語で記述され、処理が実行される。
まず、m人の個人（Xi, 1≦i≦m）に関する複数の情報（Ii,k、任意のk個の情報）に対して、その情報にアクセス可能なレベル（ALl, 1≦l≦nl）を設定し、ALl 毎に暗号鍵（Kl）を用意する。
【００６９】
そして、ALl 毎にそれぞれの暗号鍵（Kl）で暗号化して暗号化した情報（EIi,k）とする。その暗号化した情報（EIi,k）とアクセスレベルの情報（AIl）を、蓄積装置（T）の暗号済個人情報DB5に蓄積しておく（図5のステップS1）。
また、個人情報にアクセスするnｑ人の利用者（Up, 1≦p≦nq）の情報（UI）を利用者情報DB3に蓄積しておく。
【００７０】
また、nq人の利用者（Up, 1≦p≦nq）の情報（UI）、およびALが“ｌ”である個人情報Allにアクセスできる利用者（Up）のクラス（UCq, 1≦q≦nｑ）の対応付け情報（MI：Mapping Information）を、対応付情報DB4に蓄積しておく。この利用者（Up）のクラスは、医療関係者、自治体職員、ボランティアといった利用者（Up）の種別によるパブリックな(種別で括った)オープン利用者クラス（UCoq）と、利用者と蓄積された個人（Xi）との関連性（R）からのプライベートな(私的なまたは個人的な関係がある)クローズ利用者クラス（UCcr, 1≦r≦nr）とからなることも許す。或いは、利用者（Up）のクラスは、オープン利用者クラス（UCoq）とクローズ利用者クラス（UCcr, 1≦r≦nr）との何れかをもつ構成としてもよい。
【００７１】
この場合、関連性に関する情報（RIc）も、暗号化された個人情報EIi,k、そのALのAIlと一緒に、暗号済個人情報DB5に蓄積しておく（図5のステップS2）。これらの蓄積される全ての情報は、ステップS2以降が行われた後も、適宜更新されることを許す。つまり、適宜更新されてもよい。
【００７２】
続いて、利用者（Up）からの検索要求があるか否か判定される（ステップS3）。
利用者（Up）からの検索要求がないと判定される場合（ステップS3でNo）、ステップS3に移行する。
【００７３】
一方、利用者（Up）からの検索要求があると判定される場合（ステップS3でYes）、Upのセッションを開始する前に、利用者（Up）は、蓄積装置Tから自分の公開鍵で暗号化された乱数(Rx)を取得する。利用者（Up）は、利用者インターフェース部1から示された乱数で取得した公開鍵で暗号化されたものを自分の秘密鍵で平文に復号し、自分のid（識別情報）を含む構造情報の中に復号した乱数を含めた形で、問い合わせ内容とともに蓄積装置Tに送る。
【００７４】
なお、ネットワークの通信路の秘匿性を確保するためにSSL（Secure Sockets Layer）を利用することも可能である。蓄積装置Tは、利用者（Up）から受け取った利用者に対応する公開鍵で復号化し、その構造を解析して、乱数を取り出し、利用者が本人であることを確認する（ステップS4）。或いは、インターフェース部1から示された乱数と問い合わせ内容を利用者の秘密鍵で暗号化して送り、インターフェース部1側で利用者に対応した公開鍵で復号化することで、利用者が本人か確認する方法としてもよい。
【００７５】
ステップS4は、利用者（Up）の認証のためのステップである。秘密鍵は利用者（Up）本人しか知らないため、問い合わせをしたのが利用者（Up）本人であることを示している。乱数を用いずに、単に利用者が自分の秘密鍵で暗号化した問い合わせを、インターフェース部1の持つ公開鍵で復号して認証することも可能である。
【００７６】
続いて、蓄積装置Tは、認証した利用者（Up）から送られて来る問い合わせを解析し、MI（利用者（Up）のクラスがアクセスできるALの対応付け情報）を用いて利用者（Up）のオープン利用者クラス（UCoq）に対応するALのレベルALrを導出し、ALrで検索できるデータを対象に検索を行い、その結果を図示しない一時記憶部または記憶部に保存する。
【００７７】
蓄積されているデータの形式が、前記のRDFで、利用者（Up）からの問い合わせ言語がSPARQLであった場合には、SPARQLの WHERE 部分と合致するデータを検索する。その際、UCoq に対応する ALr が、蓄積された情報の ALlより低い場合には検索されないようにする。
WHERE 部分との合致するデータを検索する手法はいくつか想定することができる。そこで、第1の検索手法と、第2の検索手法とについて説明する。
【００７８】
第1の検索手法は、利用者（Up）の秘密鍵（SKup）で暗号化されたSPARQL内容を利用者の公開鍵（PKup）で復号化する。そして、対応付情報DB4のALのレベルに関する情報（AIl）を用いて、UCoq に対応するALrレベル以下の情報を暗号済個人情報DB5から検索し、ALr以下の情報を全て復号化する。そして、WHERE部分のデータと平文で比較を行い、合致したものを利用者（Up）の公開鍵（PKup）で暗号化して保存する。蓄積装置Tや蓄積装置Tの管理者が少しでも信頼できない場合には、処理中に平文が出現するために情報漏洩のおそれがあり、この手法はセキュリティという点では好ましくない。
【００７９】
そこで、第2の検索手法は、利用者（Up）の秘密鍵（SKup）で暗号化する対象をSPARQL中のリテラルのみとし、平文が発生しない再暗号化方式を用いて、利用者インターフェース部1が、利用者（Up）のオープン利用者クラス（UCoq）に対応するALr以下のレベルのALの公開鍵（PKal、l≦r）で検索条件のリテラルを再暗号化する。マルチユースなプロキシ暗号等を使うことで、平文を介さずに再暗号化が可能である。そして、検索処理部2が、暗号済個人情報DB5の暗号済情報EIi,kと暗号化されたもの同士でマッチングを行う。そして、合致したものを再び平文が発生しない再暗号化方式を用いてALlに対応した公開鍵（PKal）で暗号化されたものから、利用者インターフェース部1が、利用者の公開鍵（PKup）で暗号化されたものに再暗号化し、検索結果として保存する。
【００８０】
例えば、ALのレベルが“3”の自治体職員が前出のSPARQLの問い合わせを行った場合、問い合わせのWHERE部分
{?a, stay at, community-center} ∧ {?a, gender, female} ∧ {?a, name, ?b}∧ {?a, age, ?c}
のstay at、community-center、gender、female、name、ageといったリテラルは、図2に示すように、AL3に対応する公開鍵（pk3）の他に、AL2に対応する公開鍵（pk2）、AL1に対応する公開鍵（pk1）でも暗号化される。一方、データベースの暗号済個人情報DB5の中で、AL3に対応する公開鍵（pk3）で暗号化して蓄積されているageはそのまま同一性で検索対象となる。
【００８１】
また、同様に暗号済個人情報DB5中のname、gender、femaleは、AL2に対応する公開鍵（pk2）で暗号化されており、stay at、community centerはAL1に対応する公開鍵（pk1）でそれぞれ暗号化されているので、検索対象となる。それらの検索対象中で、変数がWHERE部分に示された条件を満たすものが検索結果となる。
【００８２】
暗号化したまま検索する第2の検索手法は、このままだと同一性の判定しかできないことと、問い合わせ中の全リテラルに対して、利用者（Up）のオープン利用者クラス（UCoq）に対応する ALr以下のすべのレベルで再暗号化する必要がある。最悪、リテラル数×nl（nl：アクセス可能なレベルの一番大きいもの）の再暗号化が必要である。そのため、再暗号化の時間がかかることが短所となる。
【００８３】
比較可能暗号や準同型暗号を用いると同一性判定の短所は解消されるが、時間はさらにかかる可能性がある。ただし、再暗号化の回数はUCo（オープン利用者クラス）に対するALのレベルに対応するもので、蓄積されるデータ数（m×平均k）（m人の個人の平均k個のデータ）には依存しない。
【００８４】
一方、平文にしてから検索する第１の検索手法は、秘匿性の面で問題があることと、データ数が多く検索結果が少ない場合でも多くのデータを復号化する必要が生じる点が短所となるが、比較可能暗号や準同型暗号を用いなくとも、大小比較や統計演算等を行うことが可能となる。また、復号化のコストは、蓄積されるデータ数（m×平均k）（m人の個人の平均k個のデータ）に依存することになる。このため、被災者人数等の蓄積されるデータ数が増えた場合には、第2の検索手法が有利である（ステップS5）。
【００８５】
図5のステップS5では、オープン利用者クラス（UCo）のみ考慮して検索したため、次の図5のステップS6では、クローズ利用者クラス（UCc）を考慮した検索を行う。そのため、利用者（Up）のid（識別情報）を用いて、利用者（Up）に対応する人物情報が蓄積された情報の中にあるかどうかを、利用者情報DB3、対応付情報DB4、暗号済個人情報DB5等を用いて、まず調べる。もし無かった場合にはクローズ利用者クラス（UCc）に係る検索情報はないので、それ以上の検索は行わない。
【００８６】
もし有った場合には、その利用者の人物情報と接続関係にある人物の情報のUCc（クローズ利用者クラス）の許可範囲の情報 (RIc)を調べ、その中で条件と合致したものを検索結果として保存する。
この場合も、図5のステップS5と同様、一旦復号化して検索する手法と暗号化したまま検索する手法がある。何れの場合にも、関係（R）の適用の回数に従って、検索を繰り返す必要がある。
【００８７】
例えば、図1のグラフ構造を前提に、bobが、
{?a, stay at, community-center} ∧ {?a, name, alice} ∧ {?a, condition, ?b}
という WHERE部分を持つ問い合わせをした場合、bob のオープン利用者クラス（UCop）がcitizen でALrが1であっても、X1のcondition とUCC（クローズ利用者クラス）のRIc（アクセス許可に関する情報）が[4-1]となっているため、parent（父親） のbobには、pregnant （妊娠）という情報が返されなければならない。このため、まず利用者bobが検索対象のデータベースの利用者情報DB3にあるか調べ、次に、図1に示す 利用者（Up）のUCC（クローズ利用者クラス）の関連性の情報から、bob と alice の接続関係を調べる。この場合には、1段であるために、1回の検索で終わる。
【００８８】
一方、bobが、
{?a, stay at, community-center} ∧ {?a, name, ?b}
という WHERE部分を持つ問い合わせをした場合、図1に示すように、bob と alice の間には、family of の関係があり、alice と carol の間には Staying Same Place の関係がある。もし、carol の name とUCC（クローズ利用者クラス）のRIc に [2-2] となっていて異なる関係性の繰り返しも許す場合には、bob は carol の名前を得ることができる。そのためには、まず上と同様に利用者bobが検索対象のデータベースの利用者情報DB3にあることを調べ、次にbobが クローズ利用者クラスUCCとして検索可能なデータを対応付情報DB4を用いて、暗号済個人情報DB5から取得し、その中で更に検索可能なデータを暗号済個人情報DB5から取得するということを繰り返す。
【００８９】
この繰り返しはコストがかかるため、グラフを作成あるいは更新した時点で、それぞれの個人（Xi）からの許可範囲の到達可否を計算してインデックスとしてその情報を予め利用者情報DB3、対応付情報DB4や図示しないテーブル等の記憶部（第3記憶部）に記憶し、利用者（Up）がその到達可能な点に入っているかどうかを調べることで判定することもできる。或いは、アクセスがあった利用者（Up）のアクセス可能な範囲を、アクセス時、特に最初のアクセス時に随時利用者情報DB3、対応付情報DB4や図示しないテーブル等の記憶部（第3記憶部）に記憶することとしてもよい（図5のステップS6）。
【００９０】
また、図5のステップS5、ステップS6の暗号鍵の適用に関してはルール等で記述して変更可能にもできる。
続いて、ステップS5、ステップS6で一時保存された検索結果をまとめて利用者（Up）に返す。利用者（Up）は、自分の持つ秘密鍵（SKup）によって復号化することで、検索結果を見ることができる（ステップS7）。
【００９１】
実施形態１(本発明)によれば、下記の効果を奏する。
1．従来のやり方では暗号鍵の管理が非常に煩雑になることが予想される多数の人物の情報（個人情報）を蓄積して、異なる種別の利用者がそれぞれアクセス可能な範囲でアクセスする場合に、個人情報の内容に従ってアクセスレベルと、それに対してアクセス可能な利用者の種別との対応関係を設定する。
これにより、暗号鍵の管理が格段に容易になる。特に、利用者とクラスの関係が変更になった場合等にその効果が大である。例えば、利用者のメンバーが変わってもキーを変える必要がない。
【００９２】
2．利用者クラスをもつことにより、利用者の立場の変化(解約、昇格など)に容易に対応できる。また、利用者と蓄積された個人情報との相対的な関係よりアクセス制御が可能である。
【００９３】
3．アクセスレベル（ALl）に関する情報（AIl）と暗号済情報（EIi.k）とを組にして蓄積するので、管理が容易である。
【００９４】
4．利用者のクラス（UC：利用者クラス）は、全てのデータに対して適用されるオープン利用者クラスUCoだけでなく、蓄積された個人との関係性を考慮したプライベートな（私的なまたは個人的な）クローズ利用者クラスUCcも組み合わせて適用することが可能である。これにより、様々な利用者の状況に応じた個人情報へのアクセスを適切にかつ容易に管理することができる。
このような、利用者クラスUCに基づく多数の人物情報データへのアクセス制御はこれまでになく、様々な面での利用が想定される。例えば、災害における被害者の情報等に対してプライバシーを考慮して秘匿性を保ちながらアクセスを制御することが可能となる。
【００９５】
5．クローズ利用者クラスUCcｑのアクセスレベルの対応付けは、個々の情報に対して関連性Rに対応する前記アクセスレベルとその関連性の許容適用回数を含む関連性情報RIcを有するので、クローズ利用者クラスUCcqでの取り扱いが柔軟性をもって行える。
【００９６】
6．暗号済個人情報DB5には、アクセスレベルに関する情報AIlとともに、前記利用者と個人の前記関連性Rの適用に関する関連性情報RIcを前記暗号済情報（EIi,k）と組にして蓄積されるので、検索が容易に行える。
【００９７】
7．利用者インターフェース部1は、個人の関連性（R）とその適用に関する関連性情報（RIc）によって、前記個人（Xi）からの到達可否を予め計算するとともにその計算結果（I）をDB、テーブル等に蓄積し、利用者(Up)が検索可能であるかどうかを前記計算結果（I）で判定するので、情報検索の処理が容易化できる。
【００９８】
8．蓄積される情報（Ii,k）の形式がRDF (Resource Description Framework)で表現されるので、本システムの記述や容易に円滑に表現でき、処理が記述形式に適合して行える。
【００９９】
9．以上より、複数の個人の情報に複数の利用者がアクセスする際に情報を適切に選択して提供できるとともにメンテナンスが容易である蓄積情報アクセス制御方法およびそのプログラムを実現できる。
【０１００】
＜＜実施形態2＞＞
図6は、本発明に係る実施形態2の蓄積情報アクセスシステムのハードウェアの構成図である。図7は、実施形態2の蓄積情報アクセスシステムの処理を示す概念図である。
実施形態2の蓄積情報アクセスシステム2Sは、実施形態1と異なり、蓄積装置であるサーバ或いはその管理者を完全には信頼できない場合に、利用者とサーバである蓄積装置T2との間に、独立したサーバであるプロキシPを置いたものである。
これ以外の構成は、実施形態1と同様であるから、同様な構成要素には同一の符号を付して示し、詳細な説明は省略する。
【０１０１】
蓄積情報アクセスシステム2Sは、複数の利用者U(U1、………、UP、………、Unu)の各パソコンが、ネットワークを介して、蓄積装置T2とプロキシPとに接続されている。
プロキシPには、利用者インターフェース部1と、利用者情報DB3と、対応付情報DB4とが格納されている。なお、利用者情報DB3と対応付情報DB4とは、一つのDBとしたり、他の記憶媒体の形式で構成してもよい。
蓄積装置T2には、検索処理部2と暗号済個人情報DB5とが格納されている。
【０１０２】
そして、サーバの蓄積装置T2には公開鍵で暗号化されたデータが蓄積され、個人情報を復号化するための秘密鍵を保持しない。そのため、データベースが格納される蓄積装置T2の管理者には内容が漏洩せず、サーバの蓄積装置T2が乗っ取られても解読可能なデータが流出することはない。
【０１０３】
一方、プロキシPは、全利用者（Up）の各公開鍵と各AL（Access Level）に対応する各公開鍵を持つが、ALに対する秘密鍵をそのまま保持せず、再暗号化にのみ利用できる形態とする。これにより、再暗号化の際に平文は現れないようにすることができることから、実施形態1と比較すると堅牢性が高い。
ただし、プロキシPにおけるALに対する秘密鍵の保持には留意が必要である。何故なら、秘密鍵が流出した場合、個人情報が意図せね人物に流出してしまうからである。秘密鍵の流出を抑えるために、信頼された第三者の秘密鍵生成局（Private Key Generator: PKG）を置く方法も考えられる。
以下、プロキシPを用いた場合の蓄積情報アクセスシステム2Sのアクセスの流れについて説明する。
【０１０４】
＜蓄積情報アクセスシステム2Sの手順＞
図8は、実施形態2の蓄積情報アクセスシステムの手順を示すフローチャートである。
以下の手順は、プログラム言語で記述され、処理が実行される。
【０１０５】
蓄積装置T2の暗号済個人情報DB5に蓄積される情報は実施形態1と同様に各ALに対応したそれぞれの公開鍵（PKal）で暗号化される（図8のステップS21）。手順は実施形態1と同様であるため、ここでは省略する。ただし、データの初期導入、更新にもプロキシPを利用することは可能である。 
【０１０６】
続いて、利用者インターフェース部1は、各利用者（UP）のオープン利用者クラス（UCoq）とクローズ利用者クラス（UCcr）とを設定し、利用者情報（UI）は利用者情報DB3に蓄積しておく。また、各利用者（Up）の利用者クラスUCoqとクローズ利用者クラスUCcrとに対応するALの情報Alｌとの対応付け情報（MI）、関連情報RICは、プロキシPの対応付情報DB4に蓄積しておく（図8のステップS22）。
【０１０７】
続いて、利用者（Up）からの検索要求があるか否か判定される（ステップS23）。
利用者（Up）からの検索要求がないと判定される場合（ステップS23でNo）、ステップS23に移行する。
【０１０８】
一方、利用者（Up）からの検索要求があると判定される場合（ステップS23でYes）、利用者の認証に関しても、実施形態1と同様であるが、実施形態1では認証を行うのが、蓄積装置T2であるサーバであったが、ここでは、プロキシPの利用者インターフェース部1で公開鍵を用いて認証を行う。認証の手順自体は実施形態1と同じであるため、これもここでは省略する（ステップS24）。
【０１０９】
図8のステップS25でも、実施形態1の蓄積装置T2のステップS25の処理の大部分をプロキシPの利用者インターフェース部1が行う。ただし、プロキシPを利用する場合には、実施形態1における第1の検索手法のような平文をプロキシP中に展開するのは好ましくないため、第2の検索手法のように検索条件を暗号化する方式を前提とする。
【０１１０】
まず、プロキシPの利用者インターフェース部1は利用者（UP）の認証を行い、対応情報（MI）を用いて利用者（UP）のオープン利用者クラスUCoqに対応するALのレベルALrを導出する。利用者（UP）はSPARQL問い合わせ中のリテラルのみ利用者（UP）の秘密鍵（Skup）で暗号化し、利用者公開鍵暗号条件（ECup）としてプロキシPに送る。
【０１１１】
プロキシPは送られて来るECupのSPARQL問い合わせを解析し、検索条件中の暗号化されたリテラルを平文が発生しない再暗号化方式を用いて、利用者（Up）のオープン利用者クラス（UCoq）に対応するALr以下のレベルのALの公開鍵（PKal、l≦r）で再暗号化し、アクセスレベル公開鍵暗号条件（ECal）として蓄積装置T2に送る。
【０１１２】
蓄積装置T2の検索処理部2は、プロキシPから送られた公開鍵PKalで暗号化された検索条件であるアクセスレベル公開鍵暗号条件ECalを用いて、データ間の同一性比較によって暗号済個人情報DB5の検索を行い、合致した結果を暗号化された暗号検索結果（EAal）としてプロキシPに返す。プロキシPは、受け取った結果を再び平文が発生しない再暗号化方式を用いてALlに対応した公開鍵（PKal）で暗号化されたものから、利用者の公開鍵（PKup）で暗号化されたものに再暗号化し、利用者公開鍵検索結果（EAup）として保存しておく（ステップS25）。
【０１１３】
次に、プロキシPを用いてクローズ利用者クラス（UCc）を考慮した検索を行う。そのため、プロキシPに利用者（Up）のid（識別情報）を一時蓄積し、そのid（識別情報）を最も高いALから最も低い AL までに対応する公開鍵（PKal）で暗号化し、蓄積装置T2に送る。蓄積装置T2の検索処理部2は利用者Upに対応する人物情報が暗号済個人情報DB5に蓄積された情報の中にあるかどうかを調べる。もし、蓄積装置T2からの結果が、利用者（Up）に対応する人物情報が無いことを示している場合には、それ以上の検索は行わない。
【０１１４】
もし、有ることを示していた場合には、その利用者の人物情報と接続関係にある人物の情報のUCc の許可範囲の情報 (RIｃ）を調べ、関係Rの適用の回数に従って、検索を繰り返し、その中で条件と合致したものを利用者公開鍵で暗号化された検索結果（EAup）としてプロキシPに保存する。繰り返しを避けるための到達可能インデックス（各利用者毎の許可範囲の情報）を予めプロキシPにDBやテーブル等の記憶部に保持することも可能である。また、実施形態1と同様に、ステップS25、ステップS26における暗号鍵の適用をルールで記述することも可能である（ステップS26）。 
【０１１５】
続いて、ステップS25およびステップS26でプロキシPに一時保存された利用者公開鍵検索結果（EAup）を、利用者インターフェース部1がまとめて利用者に返す（ステップS27）。利用者は、自分の持つ秘密鍵（SKup）によって復号化することで、暗号化されていない検索結果を見ることができる。
【０１１６】
実施形態2によれば、利用者とサーバの蓄積装置T2との間に、独立したサーバであるプロキシPを設けるので、蓄積装置T2或いはその管理者を完全には信頼できない場合に、セキュリティを高く保持することができる。
その他、実施形態1の効果は同様に奏する。
【０１１７】
＜＜その他の実施形態＞＞
1．前記実施形態1、2では、個人情報を暗号化して暗号済個人情報DB5に蓄積する場合を例示したが、暗号化しないで個人情報をDB等の記憶部に蓄積する構成としてもよい。
【０１１８】
2．前記クローズ利用者クラスUCcは、蓄積された個人との関係性を考慮したプライベートなものを説明したが、クローズ利用者クラスUCcは、適宜蓄積された個人との私的な関係性、個人的な関係性等を任意に定義して、前記クローズ利用者クラスUCcを形成してもよい。
【０１１９】
3．前記実施形態1、2のクローズ利用者クラスUCcおよびオープン利用者クラスUCoは、それぞれ複数設定してもよい。
【０１２０】
4．暗号済情報（EIi,k）と組にして蓄積されたアクセスレベルに関する情報（AIl）と関連性に対応する情報（RIc）、または／および、アクセスレベルに関する情報（AIl）と関連性に対応する情報（RIc）から対応づけられる暗号鍵（Kl）の適用の方法を変更可能としてもよい。
【０１２１】
5．前記実施形態1の図5のフローチャートと、前記実施形態2の図8のフローチャートとは、本発明の一例を説明したものであり、他の手順で構成してもよい。
6．前記実施形態1、2で説明した構成は、本発明の一例を説明したものであり、特許請求の範囲内で様々な具体的形態が可能である。
【符号の説明】
【０１２２】
1      利用者インターフェース部（インターフェース部）
2      検索処理部（検索部）
4      対応付情報DB（第2記憶部）
5      暗号済個人情報DB（第1記憶部）
AIl    アクセスレベルに関する情報
ALl    アクセスレベル
ARj    アクセス要求
C      利用者の前記検索アクセスの条件
Cp  利用者の検索アクセスの条件
EAal   暗号化された検索結果
EAup   利用者公開鍵検索結果
ECal   アクセスレベル公開鍵暗号条件
ECp    暗号済条件
ECup   利用者公開鍵暗号条件
EIi,k  暗号済情報
EM     個人に関する情報と暗号鍵に対して暗号済情報が一意に決定する暗号化方式
I      計算結果
Ii,k   情報（個人情報）
Kl     暗号鍵
MI     対応付け情報
PKup   利用者公開鍵暗号条件
PKal   公開鍵
P      プロキシ
R      関連性
RDF    Resource Description Framework
RIｃ   関連性情報
S、2S  蓄積情報アクセスシステム（システム）システム
T、T2  蓄積装置
UCcq   クローズ利用者クラス
UCoq   オープン利用者クラス
UCq    利用者クラス
Up     利用者
Xｉ  個人
【図１】
2016115997.tif 000003
【図２】
2016115997.tif 000004
【図３】
2016115997.tif 000005
【図４】
2016115997.tif 000006
【図５】
2016115997.tif 000007
【図６】
2016115997.tif 000008
【図７】
2016115997.tif 000009
【図８】
2016115997.tif 000010