JP4429619B2 - 情報提供装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
この発明は、分散型データベースシステムに関する。また、ネットワークを通じて情報を提供する情報提供装置に関する。例えば、個人情報を送信する分散型データベースシステムに関する。また、例えば、ネットワークを通じて個人情報を提供する情報提供装置に関する。
【０００２】
【従来の技術】
実社会では、組織ごとに、さまざまな個人情報を収集し、保有・管理している。これら個人情報の多くはプライバシーに関わる情報を含んでいる。したがって、情報を保有・管理する組織は、個人情報に対する守秘義務を負っている。そのため、個人情報を含まない情報さえも開示できない状況にある。しかしながら、個人情報は、組み合せて分析等を行うことで新たな意味や価値を持ち、経済効果、学術的進歩を生む可能性を有する。
しかし、実データの入手にともなう守秘義務は情報提供者と利用者間の信頼関係に負う部分が大きい。また、個人情報を保護する法により、個人情報の取り扱いに規制がなされ、各組織が蓄積した情報の開示が停滞することも生じ得る。そのため、個人情報の有効な活用がなされていない。
【０００３】
従来の技術（例えば、特許文献１）では、個人情報を有するデータ提供者（データプロバイダ）が信託機関に個人情報の一部である個人識別情報を送り、個人識別情報を受け取った信託機関が識別子を生成し、信託機関が生成した識別子をもとに個人情報を「非個人化された形式」（個人の身元を明らかにすることのない形式）で個人情報を利用する技術が開示されている。
しかし、データ提供者が第三者である信託機関に個人情報を送るとすれば、個人の匿名性（プライバシー）を確保できない可能性が高くなる。
また、第三者である信託機関を別途設立するとなれば、その維持、管理等の必要が生じる。
【０００４】
【特許文献１】
特開２０００−３２４０９４号公報
【特許文献２】
特開２００２−１７５４３２号公報
【特許文献３】
特開平５−６３６９６号公報
【特許文献４】
特開平１０−２５４８０７号公報
【０００５】
【発明が解決しようとする課題】
本発明は、個人情報に関してプライバシーを高度に確保して、個人情報の有効な利用を可能とする分散データベースシステムの提供を目的とする。
また、本発明は、複数のデータベースシステムに格納された個人の情報を関連付けることにより、個人情報の有効な利用を可能とするデータベースシステムの提供を目的とする。
また、本発明は、第三者の介在を必要とすることなく、個人情報を提供する情報提供者と、個人情報を利用する情報利用者との２者間における個人情報の有効な利用を可能とするデータベースシステムの提供を目的とする。
【０００６】
【課題を解決するための手段】
この発明に係る情報提供装置は、
ネットワークを介してアクセス装置と通信可能であり、アクセス装置からの要求に基づきアクセス装置に情報提供を行う情報提供装置において、
個人に関する個人情報を記憶する個人情報記憶部と、
前記アクセス装置から個人情報を検索する検索条件を含む個人情報送信要求を受信する受信部と、
前記受信部が受信した個人情報送信要求に含まれる検索条件を確認し、前記個人情報送信要求に含まれる検索条件の中に個人を特定可能な条件が含まれるときは前記個人を特定可能な条件を削除し前記個人を特定可能な条件を削除した検索条件を確認後検索条件として出力し、前記個人情報送信要求に含まれる検索条件の中に個人を特定可能な条件が含まれないときは前記個人情報送信要求に含まれる検索条件をそのまま確認後検索条件として出力する検索条件確認部と、
前記検索条件確認部の出力した確認後検索条件を入力し入力した確認後検索条件に基づいて前記個人情報記憶部を検索し個人情報を抽出する個人情報抽出部と、
前記個人情報抽出部の抽出した個人情報を用いて、前記抽出した個人情報を識別するためのデータＩＤを所定の規則により生成し、生成したデータＩＤを前記抽出した個人情報に付与するデータＩＤ生成部と、
前記個人情報抽出部が抽出しデータＩＤが付与された個人情報から個人の特定が可能か否かを所定の規則により判断し、個人の特定が不可能と判断したときは前記データＩＤが付与された個人情報を前記アクセス装置に送信する検索結果判断部とを備えたことを特徴とする。
【０００７】
【発明の実施の形態】
実施の形態１．
実施の形態１は、個人情報を格納しているデータベースシステムに対して、外部システムから個人情報の送信を要求するアクセスがあったときに、前記データベースシステムは、格納する個人情報をアノニマス化（匿名化）し、および、データＩＤを生成し、匿名化した個人情報に生成したデータＩＤを付与してアクセスしてきた外部システムに返信するシステムに関する。
【０００８】
実社会では、勤務している会社やかかりつけの病院、健康保険組合等が、さまざまな個人情報を「組織ごと」に収集し、保有・管理している。これら情報の多くはプライバシーに関わる個人情報を含んでいるため、情報を保有・管理する組織は個人情報に対する守秘義務を負っており、個人情報を含まない情報についても効果的に外部へ開示できない状況にある。しかしながら、各組織が保有する情報は、「組み合せ」て分析等を行うことにより新たな意味や価値を持ち、情報を保有・管理する組織が想定していなかった経済効果や学術的進歩を生む可能性を秘めている。
しかし、学術・研究的な分野では実世界のデータをサンプルデータとして匿名性を確保した形態で取り扱っているが、実データの入手にともなう守秘義務は情報提供者（個人・組織）と利用者間の信頼関係に負う部分が大きい。しかし、個人情報を保護する法により、個人情報の取り扱いに規制がなされ、各組織が蓄積した情報の開示が停滞することも生じ得る。
各組織が持つ情報の開示を促進するためには、プライバシーの確保を技術的に保証するプラットフォームを実現するとともに、このようなプラットフォームが社会的に認知されることが必要である。そうすることにより、新たなサービス事業の展開が期待でき、当該環境そのものが新たなサービスになりうる。
以下の実施の形態１は、プライバシーの確保を個人データに対する匿名性の保証ととらえ、プライバシーを確保しながら、複数のデータベースシステムに格納された個人の情報を関連付けるデータベースシステムを構築するためのものである。
【０００９】
以下に示す実施の形態１におけるシステムでは、「プライバシーの確保」と「複数データベースに格納されている個人情報の関連付け」の２つを同時に実現することを目的とする。
まず、「プライバシーの確保」について説明する。
以下に示す実施の形態１におけるシステムでは、プラットフォームが各データの匿名性を保証することによりプライバシーの確保を図る。データの匿名性は、「個人の特定」に繋がる情報を外部システムに引き渡す情報から削除することにより保証する。個人を特定する情報の削除は各データベースシステム側装置で実施し、基本ルールは予め用意するものの、どの情報を「個人の特定」に繋がると位置付けるか否かについては、各データベースシステム側装置にパラメータ設定できる機能を付与する。
大きくは下記３つの機能からなる。
第１に、データベースシステムへのデータ検索条件から「個人の特定」に繋がる検索条件を削除する機能である。
第２に、検索結果から「個人の特定」に繋がる情報を削除する機能である。
第３に、検索結果が少数（絶対数が少数、あるいは比率が少数）の場合に、データを返送しない機能である。
次に、「データの関連付け」について説明する。各データベースシステムに蓄積されているデータを有意に分析するためには、複数データベースに格納されているデータを関連付ける必要がある（例えば、データベースシステム１に格納されている個人Ａの情報と、データベースシステム２に格納されている個人Ａの情報を組み合せることを実施する必要がある）。ただし、複数データベースシステム間のデータ関連付けは、前述の「プライバシーの確保」と同時に実現する必要がある。
実施の形態１におけるシステムでは、関連付けるべきデータにそのデータを生み出した個人を特定する識別子（以下、データＩＤともいう。）を付与する。データＩＤは、「個人」を特定することが目的ではなく、同じ個人から発生した「データ」であることを特定することが目的である。よって、データＩＤから個人を特定できる情報が生成できる必要はなく、むしろ出来てはならない。
データＩＤの生成手段として、各データベースシステムが等しく保持している個人名、性別、生年月日、住所等から所定の規則にしたがって生成する手段を想定している。
【００１０】
実施の形態１におけるシステムの構成例を以下に説明する。
図１は、実施の形態１の対象となるシステムの構成例を示す。複数のデータベースシステム３１０、３２０、３３０と、これらデータベースシステムにアクセスするアクセス装置３４０がデータを相互にやり取り可能なネットワーク３５０上に接続されている。ここで、図１のデータベースシステム３１０、３２０、３３０は、組織が管理・運営するシステムそのもの、あるいはその一部であり、各組織にとってはデータベースシステム単体で情報、および、機能が充足している。例えばデータベースシステムは、データベースシステム３１０のように、アクセス端末３１１と、データベース３１３と、もう一つのデータベース３１４と、ネットワーク３１２とによりネットワークシステムを形成したデータベースシステムでもよい。各データベースシステム３１０、３２０、３３０には、その組織内において有用な情報が個人情報を含んだ形式で蓄積されている。従来は、このような各データベースシステムを有する複数の事業者間で個人情報を含むデータの連携を行うような活用は出来なかった。
ここで、各データベースシステム３１０、３２０、３３０とアクセス装置３４０が接続されるネットワーク３５０には想定される制約は特になく、専用回線、公衆回線、インターネットＷＡＮ／ＬＡＮ等が考えられる。さらに、それぞれのネットワーク３５０に対して有線／無線の形態が想定可能である。
【００１１】
図２は、実施の形態１におけるシステムの実装の概要を示す図である。図２において、各データベースシステム３１０、３２０、３３０に外部システムからのアクセス用インタフェース３６０を定義し、他システムに対して公開するとともに、当該アクセス用インタフェース３６０を介してのみ外部システムからのアクセスを許すものとする（後述するエージェント方式においても、エージェント４４０が当該アクセス用インタフェース３６０を利用する）。当該アクセス用インタフェース３６０は下記機能を有する。
第１に、プライバシーに関わる検索条件の排除機能を有する。
第２に、データＩＤ（匿名性を保持しながらデータ所有者を特定するＩＤ）の生成、および、付与機能を有する。
第３に、検索結果にプライバシーに関わる情報が含まれているかのチェック、および、該当データ項目削除機能（特異点の削除機能を含む）を有する。
第４に、アクセス装置３４０やアクセス者の認証機能（必要に応じて）を有する。
第５に、通信データの暗号化・復号化機能（検索条件の暗号化・復号化機能含む）を有する。例えば、通信データを公開鍵、秘密鍵等で暗号化し、公開鍵、秘密鍵等で復号する。
第６に、データＩＤから個人を特定可能な情報生成機能（データベースシステム側装置のみ搭載）を有する。以下に、これら第１から第６の機能について説明する。
【００１２】
まず、前記第１の機能について説明する。外部システムから個人情報を要求するアクセスがあった場合に、アクセス用インタフェース３６０は、氏名や生年月日、住所等、個人やその家族を特定可能な条件が、外部システムからの検索条件に含まれているかどうかを、データベースシステム３１０、３２０、３３０の側の装置にてチェックする。検索条件に個人やその家族を特定可能な条件が含まれていた場合、アクセス用インタフェース３６０は、その条件を削除、あるいは、緩やかな条件に変更する。どのような条件を削除し、どのような条件をどのような条件に変換するかについては、各データベースシステム３１０、３２０、３３０の側にて予め設定しておくものとする（各データベースシステム３１０、３２０、３３０の側にて規則を変更可）。
プライバシーに関わる検索条件の排除機能の例を以下として、次のようなものが挙げられる。
例えば、「名字が田中」と言う検索条件があれば当該条件を削除する。また、「住所が神戸市兵庫区○○町△△丁目□□番地」と言う検索条件があれば、当該条件を削除、あるいは、「神戸在住」等の予め定められた規則に従って、検索条件を変換する。
【００１３】
次に、アクセス用インタフェース３６０の第２の機能である、データＩＤ（匿名性を保持しながらデータ所有者を特定するＩＤ）の生成、および、付与機能について説明する。
アクセス用インタフェース３６０は、データの発生源である個人を特定するためのデータＩＤを所定の規則に従って生成し、該当するデータに付与する。データＩＤの生成手段については、前記の「データの関連付け」において説明したように、個人名、性別、生年月日、住所等から所定の規則にしたがって生成する。
【００１４】
次に、アクセス用インタフェース３６０の第３の機能である、検索結果からプライバシーに関わる情報が含まれているかのチェック機能と該当データ項目の削除機能について説明する。
検索結果には、検索キーとして使用された項目以外にも個人のプライバシーに関連する情報が含まれている可能性が高い。このため、アクセス用インタフェース３６０は、検索結果に個人を特定可能な情報項目が含まれているかをチェックし、該当する情報項目を各データベースシステム側装置にて検索結果から削除する。
さらに、検索結果が所定件数（あるいは、比率）以下である場合は、当該検索結果に対応する個人は特異点であり、個人の推測が可能となる場合のあることを考慮し、アクセス用インタフェース３６０は、当該検索結果を返答しない仕組みを備える。
どのような情報項目を対象とするか、どのような検索結果を特異点とするかについては、各データベースシステム側にて予め設定しておくものとする（各データベースシステム３１０、３２０、３３０の側にて変更可）。
【００１５】
次に、アクセス用インタフェース３６０の第４の機能である、アクセス装置３４０やアクセス者の認証機能について説明する。
認証機能により、データベースシステムへのアクセス者管理を適切に実施する。アクセス者管理の目的は、主に下記２点がある。
第１に、許可してないアクセス装置３４０、アクセス者の排除を行うことである。
第２に、アクセス者の権限管理を行うことである。
【００１６】
次に、アクセス用インタフェース３６０の第５の機能である、通信データの暗号化・復号化機能（検索条件の暗号化・復号化機能含む）について説明する。
アクセス用インタフェース３６０では、データの「盗聴」に対する防御を実現するために、データの匿名性を確保した上で他システムにデータを送付する場合は暗号化する。データの盗聴は、ネットワーク３５０を流れるデータ、アクセス装置３４０内に保存されているデータ、他データベースシステム３１０、３２０、３３０内に処理の関係上「一時」保存されるデータが対象となる。また、盗聴のみでなく、データの「改ざん」に対する防御についても考慮する。
当該暗号化の特徴としては、下記２点がある。
第１に、検索条件を暗号化し、検索対象のデータベースシステムでのみ検索条件を参照可能な仕組みを付与する。
第２に、データフィールド毎に暗号化キーを変更し、データを受信したアクセス装置３４０においても操作者の権限にしたがって参照可能な情報を制御できる仕組みを付与する。
【００１７】
次に、アクセス用インタフェース３６０の第６の機能であるデータＩＤから個人を特定可能な情報を生成する機能（データベースシステム側装置のみ搭載）について説明する。
各データベースシステム３１０、３２０、３３０では、コンサルティング会社等から分析結果としてデータＩＤを渡される状況が想定できる。この際にデータベースシステム３１０、３２０、３３０側では、データＩＤから個人を特定したい場合があり、当該機能が必要となる。本実施の形態１は、データＩＤから個人を特定する情報に変換できないと想定する。よって、所定規則にしたがって、全データからデータＩＤを生成し、逐次比較するなどの手段を用いることが考えられる。
ただし、当該機能はアクセス装置３４０上に搭載してはならず、データ検索を行うためのアクセス装置３４０の備えるアクセス用インタフェース３６１と、当該機能が共存できない仕組みを埋め込む。
【００１８】
図３は、実施の形態１に係る情報提供装置１００の構成を示す。実施の形態１における各データベースシステム３１０、３２０、３３０等は、情報提供装置１００を備える。各データベースシステム３１０、３２０、３３０等は、情報提供装置１００の機能により、前記アクセス用インタフェース３６０の機能を実現することができる。
情報提供装置１００は、受信部１０と、検索条件確認部２０と、個人情報抽出部３０と、個人情報記憶部４０と、データＩＤ生成部５０と、検索結果判断部６０と、規則記憶部７０と、課金部８０とを備える。
さらに、受信部１０は認証部１１と復号部１２とを備える。データＩＤ生成部５０は対比ＩＤ生成部５１を備える。検索結果判断部６０は暗号作成部６１と送信部６２とを備える。
【００１９】
図４は、アクセス装置３４０から情報提供装置１００が個人情報の送信要求を受けた場合のフローを示す図である。以下、図４を用いて、図２におけるデータベースシステム３１０、３２０等が個人情報の送信要求を受けた場合の情報提供装置１００の動作について説明する。例えば、データベースシステム３１０の備える情報提供装置１００が個人情報の送信要求を受信した場合を想定する。
Ｓ１０において、情報提供装置１００の受信部１０が、アクセス装置３４０からの個人情報の送信要求（個人情報送信要求）を受信する。アクセス装置３４０は、個人情報の送信要求に個人情報を検索するための複数の検索条件を含めることができる。そして、含めた検索条件のそれぞれを異なる暗号化手段で暗号化して送信することができる。暗号化の手段としては、検索条件ごとに異なるアルゴリズムを用いることや、異なる暗号鍵を用いる。
Ｓ２０において、認証部１１は個人情報の送信要求の認証を行う。認証した場合はＳ３０に進む。
Ｓ３０において、データ受信の処理を開始する。受信したデータ（個人情報送信要求）が署名、暗号化されている場合は、復号部１２は公開鍵、秘密鍵等を用いて受信データの復号を行う。
Ｓ４０において、認証部１１は、外部システムからのアクセスかどうかを確認する。外部システムからのアクセスのときは、Ｓ５０に進む。
Ｓ５０において、検索条件確認部２０は、プライバシーに関わる検索条件の有無を確認する。すなわち、個人情報の送信要求に含まれる個人情報の検索条件の中に、個人を特定可能な検索条件があるかどうかを確認する。個人を特定可能な検索条件がある場合は、検索条件確認部２０は、その検索条件を削除する。この場合、特定できない条件に変更する場合も削除に含むものとする。いかなる検索条件を削除するかという規則は、予め規則記憶部７０に記憶されているものとする。プライバシーに関わる削除するべき検索条件がない場合、あるいは検索条件確認部２０が検索条件のうちプライバシーに関わる条件を削除した場合は、Ｓ６０に進む。
Ｓ６０において、個人情報抽出部３０は個人情報記憶部４０を参照して検索条件にしたがって個人情報を抽出する。
Ｓ７０において、検索結果判断部６０は、検索結果に対して個人ＩＤ（データＩＤ）が生成されているかを確認し、生成されていなければデータＩＤを生成する（Ｓ８０）。そして、抽出された個人情報に個人ＩＤ（データＩＤ）を付与する（Ｓ９０）。さらに、検索結果判断部６０は、抽出された個人情報の中にプライバシーに関わる情報が含まれていないかどうか（個人を特定可能な情報が含まれていないかどうか）を確認する（Ｓ１００）。データＩＤは、データＩＤ生成部５０が、個人情報抽出部３０の抽出した個人情報に基づいて生成する。データＩＤを作成する規則は、規則記憶部７０が記憶しており、データＩＤ生成部５０は当該規則を参照するものとする。また、検索結果判断部６０がプライバシーに関わる情報を確認するに際して、いかなる情報が該当するかということも予め規則記憶部７０が記憶しているものとする。検索結果判断部６０は、抽出された個人情報から個人の特定が不可能であると判断したときは、前記データＩＤを付して個人情報をアクセス装置３４０に送信する。このとき、暗号作成部６１は、必要があれば、送信する個人情報を暗号化する（Ｓ１１０）。送信するべき匿名化された個人情報が複数のデータ項目より形成されている場合、検索結果判断部６０の暗号作成部６１は、データ項目ごとに異なる暗号手段を用いて、データ項目のそれぞれを暗号化することが可能である。異なる暗号化の手段としては、異なるアルゴリズムを用いることや、データ項目ごとに異なる暗号鍵を用いて暗号化することが考えられる。
また、検索結果判断部６０は、抽出された個人情報から個人の特定が可能であると判断したときは、個人の特定が可能なデータを削除してアクセス装置３４０へ送信する。あるいは、個人の特定が可能なデータが存在する場合は、アクセス装置３４０へ送信を行わないものとする。いかなる処理を行うかは、予め規則として規則記憶部７０に記憶しておくことができる。
Ｓ１１０において個人情報をアクセス装置３４０に送信すると、Ｓ１２０で処理が終了する。
【００２０】
前記ではアクセス装置３４０と一つのデータベースシステムとが通信する場合を説明した。以下では、図２において、アクセス装置３４０がデータベースシステム３１０、３２０、３００の複数とやりとりした場合における、前記データベースシステム３１０、３２０、３３０から受けとった複数の各個人情報の関連付けについて説明する。
各データベースシステム３１０、３２０、３３０は、情報提供装置１００を備ている。そして、各データベースシステム３１０、３２０、３３０に備えられた情報提供装置１００のデータＩＤ生成部５０は、同一の生成規則によりデータＩＤを生成する。各データベースシステム３１０、３２０、３３０は、同一の生成規則により生成されたデータＩＤを匿名化した個人情報に付して、アクセス装置３４０に送信する。アクセス装置３４０は、各データベースシステム３１０、３２０、３３０から送信された個人情報について、付与されているデータＩＤにより、同じ個人から発生した個人情報であることを知ることができる。このように、各データベースシステム３１０、３２０、３３０において同一の生成規則により生成されたデータＩＤによって、アクセス装置３４０は、複数の個人情報の関連付けをすることが可能となる。
ここで、同一の生成規則により生成されるデータＩＤは、それぞれが同一であってもよいし、また、同じ個人から発生した個人情報であることがわかるものであれば、同一でなくとも構わない。
なお、図３の情報提供装置１００の対比ＩＤ生成部は、アクセス装置３４０からデータＩＤが送信された場合は、個人情報記憶部４０の記憶する個人情報を用いて対比ＩＤを生成する。「対比ＩＤ」とは、前記アクセス装置３４０から送信されたデータＩＤと対比するために生成されるＩＤである。データＩＤと対比ＩＤとは同じ規則で生成されるので、データＩＤと対比ＩＤとを対比すれば、アクセス装置３４０より送信されたデータＩＤから個人を特定することができる。通常データＩＤと対比ＩＤは同一であるが、データＩＤと対比ＩＤとが同一人に係ることがわかるものであれば、同一でなくとも構わない。
また、情報提供装置１００は、課金部８０を備えている。例えば、課金部８０は、アクセス装置３４０からの検索履歴を保存し、アクセス回数、検索結果のデータ量等からアクセス側に対して課金の処理を行う。
【００２１】
次に、データ（個人情報）を収集する場合のデータ収集方式について説明する。
システム実装時における各データベースシステム３１０、３２０、３３０からのデータ収集方式について述べる。
システムの実装概要を示す図２において、各データベースシステム３１０、３２０、３３０からアクセス装置３４０がデータを収集する代表的な方式として下記２方式が考えられる。
第１に、データベースシステム３１０、３２０等とアクセス装置３４０が１対１で収集する方式である。
第２に、エージェント方式（収集対象の情報を指示するとエージェントが各データベースシステムを周って、情報を集めアクセス装置３４０に帰ってくる）が考えられる。なお、エージェントについては、実施の形態４で詳述する。
エージェント方式を採用した場合、各データベースシステム３１０、３２０、３３０において検索結果を得た時点で、当該データベースシステム３１０、３２０、３３０に対する検索条件を破棄する等の処理により、前段のデータベースシステムで得られた検索結果が、どのような検索条件で抽出されたかを伝達しないようにしてセキュリティ度を向上する処理を行うことも可能である。
【００２２】
図２に示したシステムは、次のような事業への適用が考えられる。
例えば、環境提供サービスである。匿名性を保証するプラットフォームの運用、販売、リース、保守等のサービスを提供する。
また、介入サービスである。医療機関、健康保険組合、個人が所属する会社等を接続し、健康保険組合、個人等の特定集団に対して健康に関するアドバイスを実施するサービスを提供する。
また、介入サービス評価である。複数の介入サービスを適用した集団単位や個人単位でその介入サービスの適用効果を評価するサービスを提供する。
【００２３】
図５は、図２に示す実装概要を、前記に述べたサービス事業のうち、介入サービスに適用した具体例を示すものである。
前記適用例のうち、図５を用いて、より具体的に、ある集団の健康に対する介入サービス、および、介入サービスに対するコンサルティングサービスを例に説明する。
図５において、健康保険組合は、コンサルティング会社に「どのような個人に（誰にではない）」、「どのような介入サービス」を実施すればよいかを分析・調査するよう依頼する。その分析・調査のために、健康保険組合データベースシステム３７０の保有する情報（レセプト情報（診療報酬情報）等）と会社の人事データベースシステム３８０の保有する情報（勤怠情報等）と産業医データベースシステム３９０の保有する情報（身長、体重、血圧等の健診情報、疾病履歴、問診情報等）をコンサルティング会社（アクセス装置３４０）に開示する。
当該例の登場者は、コンサルティング会社、介入サービス委託の主体者である健康保険組合、情報の提供者である会社（人事）、産業医である。
当該システムを適用することにより、特定集団に対して、医療費と勤務時間と肥満の関係等を調査することが可能となるとともに、問診結果の情報とも比較することにより生活習慣病や成人病の予備軍を洗い出す等の分析が期待できる。
実施の形態１は、このようなシステムの構築に有効である。実施の形態１を適用することにより、コンサルティング会社ではデータの所有者個人を特定できないことは当然であるが、あるデータベースシステムの保有する情報が他のデータベースシステムにおいて参照できない仕組みを構築することができる（例えば、健康保険組合データベースシステム３７０のレセプト情報が人事データベースシステム３８０や産業医データベースシステム３９０から参照できない）。さらに、組織全体の傾向等を分析するために、各組織が保有する情報を「発生源」である個人を軸に関連付けることが可能となる。
【００２４】
以下に、前記介入サービスに適用した場合の処理の過程を説明する。
各データベースシステム３７０、３８０、３９０、および、コンサルティング会社にあるアクセス装置３４０に実施の形態１のシステムを適用する。例えば、コンサルティング会社（アクセス装置３４０）から人事データベースシステム３８０に対して、図６に示すような、「東京都在住の３０歳以上の三菱さん（人の氏）で、取得休暇日数が１０日以下の人」という検索要求が発行された場合を仮定する。アクセス装置３４０から各データベースシステム３７０、３８０、３９０への（検索条件を含む）検索依頼送信時に依頼情報も暗号化することが想定される。
認証やアクセス経路に問題が無ければ（図４におけるＳ１０〜Ｓ４０）、プライバシーに関わる検索条件の削除を行う（Ｓ５０）。氏名を特定することはプライバシーの侵害にあたるため、実施の形態１の適用により検索条件は、図７に示すように、「東京都在住の３０歳以上の社員で、休暇を１０日以上取得した人」と変更され、当該検索条件を用いて人事データベースシステム３８０を検索（Ｓ６０）することとなる。プライバシーに関わる検索条件の排除が発生した場合の要求依頼者への通知は、当該検索結果返送時、あるいは、別途手段により行うものとする。また、プライバシーに関わる検索条件には、氏名、誕生日、住所、電話番号は当然当てはまると考えられるが、特別疾病、賞罰等も当該範疇であると考えている。どのような情報をプライバシーに関わる情報ととらえるかは、データを提供する各データベースシステム側で設定（変更）可能とする。
その結果、図８のような情報が検索されたとする。
次にデータＩＤを生成（Ｓ８０，Ｓ９０）し、各データに付与する。図９に、データＩＤを付与した場合を示す。データＩＤは数字（１０進、１６進等には依存しない）であっても、アルファベット等の文字であっても、数字、文字の組み合せであってもかまわない。データＩＤの生成手段については、前記の「データの関連付け」で述べた手段等が考えられる。
次に、検索結果に対して、プライバシーに関わる情報を削除する（Ｓ１００）。図１０に、プライバシーに関わる情報を削除した場合を示す。ここで、前述した通りどのような情報をプライバシーに関わる情報ととらえるかは、データを提供する各データベースシステム側で設定（変更）可能とするとするが、当該指定のない情報は検索依頼者へ返送される。
図１０に示す情報をコンサルティング会社（アクセス装置３４０）に対して人事データベースシステム３８０が検索結果として返送する（Ｓ１１０）こととなる。ここで、アクセス装置３４０では、データＩＤである「Ｄａｓｆ１０４」から「三菱太郎」という名前は生成できない。ただし、「三菱太郎」の情報が他データベースシステム（例えば、産業医データベースシステム３９０）から検索結果として返される場合は、データＩＤとして「Ｄａｓｆ１０４」が付与されて返されるため、異なるデータベースシステムに格納されている同一個人から発生したデータを関連づけることが可能となる。この際、コンサルティング会社（アクセス装置３４０）から人事データベースシステム３８０等のデータベースシステム側にデータを返送した場合、権限のないデータ項目は内容を見ることが出来ないようにすることもできる。データは各フィールド単位で暗号化可能であり、例えば、人事データベースシステムでは、返送データに疾病情報が入っていても観る権限がないので、復号化できない。
データの返送時には、データの暗号化を行う。ここでいう暗号化は、ネットワーク３５０を介してデータの授受を行うために第三者がデータの参照を行うことを排除するためにデータ全体に施す暗号化と、アクセス装置３４０と操作者のそれぞれに許可（あるいは、その組み合せにより許可）された情報のみを参照可能とする暗号化を想定する。例えば、当該例では、人事データベースシステム３８０では、暗号化を性別、所得休暇数、職級等の項目ごとに施し、コンサルティング会社（アクセス装置３４０）に返送する。
例えば、人事データベースシステム３８０からのデータが故意の有無に関わらず、健康保険組合データベースシステム３７０に送付された場合でも暗号キーが異なるために健康保険組合の端末からはデータの参照ができない。さらに、コンサルティング会社にあるアクセス装置３４０へ適切に返送された場合でもログイン者の権限に従って参照可能なデータ項目を制限する仕組みを加える。
各データベースシステム３７０、３８０、３９０上では、データＩＤから個人を特定することが可能である。
当該例では、各データベースシステム３７０、３８０、３９０の内容からコンサルティング会社が介入サービス委託の主体である健康保険組合に対して、生活習慣病の予備軍となる組合員を指定し、その改善案を提示する等の手順が想定できる。しかし、コンサルティング会社が健康保険組合に提示可能な情報はあくまでデータＩＤであり、個人を特定するものではない。ここで、データＩＤを提示された健康保険組合は、保持する各個人のデータから対比ＩＤを生成し（図３の対比ＩＤ生成部５１が生成する）、コンサルティング会社から提示されたデータＩＤと対比ＩＤとを比較する等により、コンサルティング会社から提示されたデータＩＤから個人を特定することが可能である。例えば、コンサルティング会社は、「Ｄａｓｆ１０４」のデータＩＤを持つ個人が生活習慣病の予備軍であると健康保険組合に通知するとともに、その改善対策案を提示する。コンサルティング会社では「三菱太郎」ではなく、「Ｄａｓｆ１０４」である。しかし、健康保険組合において「Ｄａｓｆ１０４」では誰に介入サービスを実施すればよいか不明である。そこで、自らのデータベースシステム３７０を検索し、対比ＩＤを生成し、コンサルティング会社からのデータＩＤと生成した対比ＩＤとを対比して、「Ｄａｓｆ１０４」が「三菱太郎」であると特定する。これにより、「三菱太郎」に対して介入サービスを実施すればよいことを把握する。必要に応じて、健康保険組合は、介入サービスを提供するサービス提供業者に対して業務の委託を行い、サービス提供業者を介して健康保険組合に所属する個人に介入サービスを実施する場合もある。
ただし、コンサルティング会社は、データ参照する組織と守秘契約等を結び、守秘義務を負うことにより、他データベースシステム（例えば、人事データベースシステム３８０）から入手したデータを健康保険組合へは開示できないものとする。さらに、他データベースシステムの内容に関連する検索条件についても開示してはならない（後述するエージェントにより各データベースシステムからデータを取出す場合、検索条件を暗号化することは勿論であるが、あるデータベースシステムで使用した検索条件はそのデータベースシステムにおいて破棄し、他データベースシステムへは検索結果のみを送付するような実装手段を用いる）。コンサルティング会社は、何故「三菱太郎」が生活習慣病の予備軍であると推測されたかについては、「三菱太郎」に関する他データベースシステムの登録情報が推測できるため検索条件を健康保険組合へ開示してはならない。
【００２５】
図１１は、以上に述べた、実施の形態１におけるシステムの機能を示す図である。
実施の形態１の適用により、複数のデータベースシステム３１０、３２０、３３０とアクセス装置３４０との間において、匿名性を確保しながら、複数データベースシステム間の検索結果の関連付けを行うシステムの構築が容易である。また、各データベースシステムでは、コンサルティング会社等のアクセス装置３４０から指定されたデータＩＤに対応する個人の特定も可能となる（なお、個人が特定できるのは、各データベースシステム内においてのみである）。
【００２６】
本実施の形態１によれば、匿名化により匿名性を保証（個人のプライバシーを確保）して個人情報の有効活用を図ることができる。また、各データベースシステムに存在する同一人の個人情報に関して互いに関連付けるとともに、アノニマス化（匿名化）により匿名性を保証するので、個人情報を有効に活用することができる。
【００２７】
本実施の形態１に係る情報提供装置１００は、個人を特定可能なデータ項目を削除するので、個人情報の利用において匿名性を保証することができる。また、個人を特定可能なデータ項目を削除した検索条件で個人情報を抽出するので、匿名性を保証したうえで個人情報の利用を図ることができる。
【００２８】
本実施の形態１に係る情報提供装置１００は、個人を特定可能なデータ項目の内容を削除するので、個人情報の利用において匿名性を保証することができる。また、個人を特定可能なデータ項目の内容以外は利用されるので、個人情報の利用を図ることができる。
【００２９】
本実施の形態１に係る情報提供装置１００は、個人情報のデータ項目の内容が個人を特定可能と判断したときは、当該個人情報を送信しないので、個人情報について匿名性を保証することができる。
【００３０】
本実施の形態１に係る情報提供装置１００は、抽出した個人情報が所定の数以下のときは送信しないので、いわゆる特異点に該当する者が特定されることを防止することができ、匿名化を保証することができる。
【００３１】
本実施の形態１に係る情報提供装置１００は、抽出した所定の集団に属する個人情報に関する人数の比率が所定の値のときは当該個人情報を送信しないので、所定の集団に属するいわゆる特異点に該当する者が特定されることを防止することができ、匿名化を保証することができる。
【００３２】
本実施の形態１に係る情報提供装置１００は、対比ＩＤ生成部５１を備えたので、アクセス装置３４０から送信されたデータＩＤに相当する個人を特定することができるので、個人情報を用いた分析結果を有効に活用することができる。
【００３３】
本実施の形態１に係る情報提供装置１００は、課金部８０を備えたので、匿名化個人情報を用いた新たなサービス、新たなビジネスを展開することができる。
【００３４】
本実施の形態１は、各データベースシステムが同一の生成規則によりデータＩＤを生成することにより、同一人について異なるデータベースシステムに存在する個人情報を関連付けることができるので、個人情報の利用価値を高めることができる。
【００３５】
本実施の形態１は、各データベースシステムの外部に出力あるいは送信される個人情報は匿名化されているので、匿名化を保証することができる。また、データベースシステム外部へ送信される匿名化された個人情報は、複数のデータ項目からなるときはデータ項目ごとに暗号化できるので、個人情報の匿名性を高めることができる。
【００３６】
本実施の形態１は、信託機関のごとき第三者の介在を必要とすることなく、個人情報を提供する情報提供者（個人・組織）と、個人情報を利用する情報利用者（アクセス装置３４０）との２者間における匿名化された個人情報のやりとりを可能とすることができる。
【００３７】
本実施の形態１では、アクセス装置３４０が検索条件ごとに暗号化し、検索対象のデータベースシステムのみが復号することができるため、匿名化した個人情報の匿名性の確保を高めることができる。
【００３８】
実施の形態２．
実施の形態２は、データベースシステムにおいて、予めアノニマス化（匿名化）処理を行い、アノニマス化したデータを格納していく方式を示す（後述の実現案１）。
すなわち、予め匿名化した個人情報を格納しているので、アクセス装置３４０からのアクセスに迅速に応答することが可能である。また、匿名化した個人情報を予め格納しているため、アクセス装置３４０へ定期的に、あるいは不定期的に匿名化した個人情報を送信することが可能である。
【００３９】
図１２は、実施の形態２が想定するシステム構成概要を示す。複数のデータベースシステム３１０、３２０、３３０とこれらデータベースシステム３１０、３２０、３３０にアクセスするアクセス装置３４０がデータを相互にやり取り可能なネットワーク３５０上に接続されている。各データベースシステムとアクセス装置３４０が接続されるネットワーク３５０には想定される制約は特になく、専用回線、公衆回線、インターネットＷＡＮ／ＬＡＮ等が考えられる。さらに、それぞれに対して有線／無線の形態が想定できる。ここで、図１２中ではアクセス装置３４０と各データベースシステム３１０、３２０、３３０を別装置として記述しているが、いずれかのデータベースシステムを構成する装置がアクセス装置３４０であってもかまわない。
【００４０】
図１３は、実施の形態２における実現案１を示す図である。図１３は、アクセス装置３４０と、データベースシステム４００とがネットワークを介して接続されている。
実現案１は、データベースシステム４００において予めアノニマス化処理を行い、アノニマス化したデータを格納していく方式を示すものである。
データベースシステム４００において、アクセス装置３４０からのアクセス用データベースを用意し、当該データベースにアノニマス化したデータを適宜格納する実現案である。
ここで、各データをアノニマス化する方式については、特に制限はない。
異なるデータベースシステムにおいて、同じ基準を持つデータから同じデータＩＤを生成できる生成方式であれば、データＩＤの生成方式は、特に制限はない。
内部システム向けデータベースと外部システムからのアクセス用データベースが、同一装置内にあるか否か、同一データベース内にあるか否かについては特に制限はない（実際には、当該実装案を選択する場合、セキュリティの観点から内部システム向けと外部システムからのアクセス用データベースは別装置、別データベースとすることが望ましい。）。
外部システムであるアクセス装置３４０からのアクセス用データベースの更新タイミングは、内部システム向けデータベースの更新時処理や定時処理等が想定できるが、特に制限はない。
図１３におけるアクセス装置３４０やアクセス者の認証機能の有無や実現方式については、特に制限はない。
図１３におけるアクセス装置３４０とデータベースシステム４００、あるいはデータベースシステム間（データベースシステム４００が複数あるような場合）の通信において、検索依頼情報、および、検索条件や検索結果等に対する暗号化・復号化処理の有無、および、暗号化の方式については、特に制限はない。
【００４１】
図１４は、本実施の形態２に係る前記実現案１に使用する情報提供装置２００の構成を示すブロック図である。
図１３に示した実施の形態２におけるデータベースシステム４００は、この情報提供装置２００を備える。データベースシステム４００は、情報提供装置２００の機能により、匿名化した個人情報を図１３のアクセス装置３４０に送ることができる。
データベースシステム４００は、図１４に示す情報提供装置２００を構成している。情報提供装置２００は装置であってもよいし、また、データベースシステム４００のようにネットワークの形態であっても構わない。
【００４２】
情報提供装置２００は、個人情報記憶部１１０と、匿名化処理部１２０と、匿名化個人情報記憶部１３０と、受信部１４０と、送信部１５０とを備えている。さらに匿名化処理部１２０はデータＩＤ生成部１２１を備えている。
【００４３】
以下、情報提供装置２００の動作について説明する。
情報提供装置２００は、、予め匿名化個人情報記憶部１３０に匿名化した個人情報を適宜格納する構成である。
そして、情報提供装置２００は、アクセス装置３４０から個人情報の送信要求があったときには、すでに匿名化し匿名化個人情報記憶部１３０に格納している匿名化した個人情報をアクセス装置３４０に送信する。また、アクセス装置３４０からの送信要求にかかわらず、アクセス装置３４０に定期的、あるいは不定期的に匿名化した個人情報を送信できる。
個人情報記憶部１１０は匿名化していない個人情報（未アノニマス化データ）を格納している。匿名化処理部１２０は、個人情報記憶部１１０の記憶している未アノニマス化データを用いて匿名化を施した匿名化個人情報を生成する。匿名化個人情報記憶部１３０は、匿名化処理部１２０の生成した匿名化個人情報を記憶し格納する。そして、情報提供装置２００は、例えば、受信部１４０がアクセス装置３４０からの個人情報の送信要求を受けた場合には、匿名化個人情報記憶部１３０の格納する匿名化個人情報を送信部１５０を介してアクセス装置３４０に送信する。
また、匿名化処理部１２０のデータＩＤ生成部１２１は、個人情報を匿名化するときに個人情報を識別するデータＩＤを生成して匿名化個人情報に生成したデータＩＤを付与する。図１２の複数のデータベースシステム３１０、３２０、３３０のそれぞれがデータＩＤ生成部１２１を備え、それぞれのデータＩＤ生成部１２１は、同一の生成規則にしたがってデータＩＤを生成する。これは実施の形態１における情報提供装置１００のデータＩＤ生成部５０の機能と同様である。
【００４４】
図１５は、実施の形態２における別の例である関連付け分散データベースシステム５００を示す図である。図１５の関連付け分散データベースシステム５００は、第１プライベートデータベース装置６００と、第２プライベートデータベース装置７００と、データベースアクセス装置８００とを備える。なお、関連付け分散データベースシステム５００は、図１２において、前記の第１プライベートデータベース装置６００はデータベースシステム３１０に相当し、第２プライベートデータベース装置７００はデータベースシステム３２０に相当し、データベースアクセス装置８００はアクセス装置３４０に相当すると見ることができる。
【００４５】
第１プライベートデータベース装置６００は、第１識別子を生成する第１識別子生成部６１０と、第１組み合わせデータ作成部６２０と、第１記憶部６３０とを備える。そし第１組み合わせデータ作成部６２０は第１組み合わせデータ６２１を作成する。
第１記憶部６３０は第１プライベートデータ６３１を記憶する。第１プライベートデータ６３１は第１個人識別情報と第１個人データ情報からなる。
第２プライベートデータベース装置７００は、第１プライベートデータベース装置６００と同様の構成であり、第２プライベートデータ７３１の処理をおこなう。
データベースアクセス装置８００は、識別子照合部８１０と、関連データ記憶部８２０とを備える。関連データ記憶部８２０は関連記憶情報８２１を記憶する。
【００４６】
次に、関連付け分散データベースシステム５００の動作について説明する。
第１プライベートデータベース装置６００の動作をまず説明する。
第１記憶部６３０は、第１個人識別情報と第１個人データ情報とを第１のプライベートデータとして記憶している。ここで、個人識別情報とは、特定の個人を識別できる情報、あるいは特定の個人を識別できる可能性の大きい情報をいう。特定の個人を識別できる情報としては、保険証番号、運転免許免許番号や住民票コードがある。特定の個人を識別できる可能性の大きい情報としては、氏名（同姓同名も存在するので）や住所がある。
また、個人データ情報とは、例えば健康診断を受けた結果をデータベースに記憶し保存してある場合は、体重や血圧等が考えられる。その他、学歴や病歴、歯の治療歴等さまざまなものがある（個人識別、あるいは、識別可能性のある情報は除く）。
第１識別子生成部６１０は、第１の個人識別情報から所定の規則に基づいて個人を識別することができない第１識別子を生成する。ここで識別子とは前述したデータＩＤがその一例である。
第１組み合わせデータ作成部６２０は、第１識別子生成部６１０の生成した第１識別子と、第１記憶部６３０の記憶する第１個人データ情報とを組み合わせて、第１組み合わせデータ６２１として出力する。第１組み合わせデータ作成部６２０は、第１組み合わせデータ６２１を出力する場合に、第１の個人データ情報を暗号化して出力しても構わない。また、第１の個人データ情報が複数のデータ項目で形成されている場合は、データ項目ごとに異なる暗号化手段で暗号化しても構わない。データ項目ごとの異なる暗号化の手段としては、異なるアルゴリズムを用いることや、データ項目ごとに異なる暗号鍵を用いて暗号化する。以上のことは、後述する第２組み合わせデータ作成部７２０が、第２組み合わせデータ７２１を出力する場合も同様である。
第２プライベートデータベース装置７００も、同様に動作するが、その特徴点を説明する。
第２記憶部７３０は、第２個人識別情報と第２個人データ情報を記憶する。ここに、第２個人識別情報は第１個人識別情報と同じ内容である。一方、第２個人データ情報は第１個人データ情報とは異なる内容である。例えば、第１個人データ情報は、会社の人事における勤怠情報であり、第２個人データ情報が産業医における健康診断情報のような場合である。
第２識別子生成部７１０は、第２個人識別情報を用いて第１識別子生成部６１０と同じ規則に基づいて第２識別子を生成する。
第２組み合わせデータ作成部７２０は、第２識別子生成部７１０が生成した第２識別子と、第２記憶部７３０が記憶する第２個人データ情報とを組み合わせて、第２組み合わせデータ７２１を作成して出力する。
データベースアクセス装置８００は、前記第１プライベートデータベース装置６００が出力した第１組み合わせデータ６２１を入力し、また、第２プライベートデータベース装置７００が出力した第２組み合わせデータ７２１を入力する。
識別子照合部８１０は、第１組み合わせデータ６２１の第１識別子と第２組み合わせデータ７２１の第２識別子とが一致するかどうかを参照する。そして、一致した第１組み合わせデータ６２１の第１個人データ情報と第２組み合わせデータ７２１の第２個人データ情報とを関連付ける。
関連データ記憶部８２０は、識別子照合部８１０が関連付けたデータを記憶する。
【００４７】
前記実現案１とは別の例として、実現案２を示す。
図１６に、実施の形態２に係る実現案２を示す。実現案２は、前記「外部システムからアクセスがあったときに匿名化した個人情報を返信する方式」と「予めアノニマス化処理を行い、アノニマス化したデータを格納しておく方式」とを兼ね備える実現案である。これは、実施の形態１と、実施の形態２の実現案１とを混合させたシステムである。図１６（ａ）にその関係を示す。
「外部システムからアクセスがあったときに匿名化した個人情報を返信する方式」は、図１６（ｂ）のアクセス用インタフェース３６０及びデータベースシステム４１６で実現する。また、「予めアノニマス化処理を行いアノニマス化したデータを格納しておく方式」は、図１６（ｂ）のアノニマス化データベースシステム４１５により実現する。アノニマス化データベースシステム４１５は図１３のデータベースシステム４００と同様である。
【００４８】
以上、実施の形態２における実現案１では、予め匿名化した個人情報を格納しているので、アクセス装置３４０からのアクセスに迅速に応答することが可能である。また、予め匿名化した個人情報を格納しているので、アクセスの有無と関係なくアクセス装置３４０へ定期的に、あるいは不定期的に匿名化した個人情報を送信することができる。
【００４９】
実施の形態２にかかる情報提供装置２００は、データＩＤ生成部によりデータＩＤを生成し、匿名化した個人情報に生成したデータＩＤを付与するので、当該データＩＤをもとに匿名化した個人情報を利用することができる。
【００５０】
実施の形態２に係る関連付け分散データベースシステム５００は、同一人についての異なる内容の個人情報に関して匿名性を保証した上で前記異なる内容の個人情報を関連付けすることができるので、個人情報の利用価値を高めることができる。
【００５１】
実施の形態２に係る関連付け分散データベースシステム５００は、個人データ情報が複数のデータ項目で形成されている場合に、第１組み合わせデータ作成部６２０と第２組み合わせデータ作成部７２０とは、それぞれ出力する第１の個人データ情報と第２の個人情報データとのそれぞれのデータ項目を異なる暗号化手段で暗号化するので、個人情報の匿名性を確保した上で、異なるデータベースシステムの保有するそれぞれの個人情報を関連付けて有効に活用することができる。
【００５２】
実施の形態３．
実施の形態３は、実施の形態１及び実施の形態２で示したシステムについて、利便性を向上させるため、検索装置（管理装置の一例）を備えた構成である。すなわち、実施の形態３は実施の形態１及び実施の形態２に対して、新たな機能を付加した構成であるので、前記実施の形態２の実現案２に続き、実現案３として説明を続ける。
【００５３】
以下に実施の形態３に係る実現案３について説明する。
図１７は、実施の形態３に係る分散データシステムの実現案３を示す。なお、図１７は、実現案４及び実現案５をも示す図である。まず、図１７を用いて実現案３を説明する。
図１７は、どのデータベースシステムに、検索者が必要とする情報が格納されているかを示す「種別情報」を管理する検索装置４２０（管理装置の一例）を備えている。ここで、「種別情報」とは、例えば、データベースシステム３１０の有する個人情報は個人の医療費に関するものであり、データベースシステム３２０の有する個人情報は会社の人事管理における勤怠情報に関するものであるという情報を意味する。
アクセス者（アクセス装置３４０）は、いずれのデータベースシステム内にどのようなデータが格納されているかを示す前記の種別情報をすべて把握することは困難である。このような問題に対処するために、いずれのデータベースシステムに検索者の必要な情報が格納されているかを管理する検索装置４２０（管理装置の一例）を当該分散データベースシステム内に設置する。アクセス装置３４０が検索したい情報（データ）を検索装置４２０に指定すれば、いずれのデータベースシステムに検索したい情報が格納されているかを当該検索装置４２０がアクセス装置３４０に返す。ここで、検索装置４２０が検索対象データがいずれのデータベースシステムに格納されているかを管理する手段として、アドレス帳のような検索（したい）内容とそのデータを格納しているデータベースシステムの対応表を管理することにより実現することができる。
ここで、システム内に複数個の検索装置４２０を設置してもかまわないものとする。
【００５４】
次に別の例として、実現案４について説明する。
実現案３では、検索装置４２０が前記の対応表を有する場合は、対応表のメンテナンスが困難になることが想定される。そこで、実現案４では、このような問題に対応するため、図１７に示すシステムにおいて、アクセス装置３４０から検索装置４２０にデータベースシステム３１０、３２０、３３０の検索依頼があった際に、検索装置４２０は各データベースシステムに対して検索対象のデータ有無を問い合わせ、その結果をアクセス装置３４０に返す。
【００５５】
次に別の例として、実現案５について説明する。
実現案４では、アクセス装置３４０から検索装置４２０にデータベースシステム３１０、３２０、３３０への検索依頼が発行された時点で、検索装置４２０が各データベースシステム３１０、３２０、３３０へ問い合わせを行うため、検索装置４２０によるデータベースシステムの検索処理に時間を要することが想定される。
このため、図１７において、実現案５では、データベースシステム３１０、３２０、３３０の検索依頼がアクセス装置３４０より発行された場合、まず、検索装置４２０は、検索装置４２０内に備える内部テーブルを参照し、「検索したい内容とそのデータを格納しているデータベースシステムの対応」が内部テーブルに登録されていれば登録内容をアクセス装置３４０に返す。内部テーブルに登録されていない場合、検索装置４２０は各データベースシステム３１０、３２０、３３０へ問い合わせを行い、問い合わせ結果をアクセス装置３４０へ返すとともに、検索装置４２０の有する内部テーブルを更新する。前記手順により、データベースシステム３１０、３２０、３３０の検索処理を高速化するとともに、検索装置４２０の有する内部テーブルのメンテナンス作業を効率化する。
【００５６】
次に別の例として、実現案６について説明する。
実現案６（図示しない）は、対象システムが実現案２（実施の形態１と実現案１との混在（図１６（ａ）））の形態である場合、対象となるデータベースシステム３１０、３２０、３３０がどのようなインタフェース（特定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を使用してアクセスするか、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）等汎用なＡＰＩを使用してアクセスするか等）を公開しているかをアクセス装置３４０側が意識するシステムである。アクセス装置３４０の当該負荷を軽減することを目的に、実現案６は、実現案３〜実現案５に対してデータベースシステム３１０、３２０、３３０のインタフェース情報の管理機能を付加する。
【００５７】
次に別の例として、実現案７について説明する。
図１８に実現案７を示す。実現案７は、実現案３〜実現案６の検索装置４２０にデータ検索機能を付加し、ポータル装置４３０（管理装置の一例）として位置付ける。すなわち、ポータル装置４３０は、データ検索機能を備えるとともに、データベースシステム３１０、３２０、３３０がどのような種別の個人情報を有しているかの種別情報を備えている。
アクセス装置３４０は、ポータル装置４３０に検索依頼（第１の個人情報送信要求の一例）を送信する。前記検索依頼を受けたポータル装置４３０は、自己の有する種別情報と、アクセス装置３４０から受信した検索依頼（第１の個人情報送信要求の一例）とに基づき、所定のデータベースシステムに検索依頼（第２の個人情報送信要求の一例）を送信する。図１８では、ポータル装置４３０は、所定のデータベースシステムとしてデータベースシステム３１０に検索依頼を送信している。これは、ポータル装置４３０の有する種別情報によれば、該当する情報をデータベースシステム３１０が所有していることが判明したからである。データベースシステム３１０では、例えば、図３の情報提供装置１００を備えている。情報提供装置１００は、ポータル装置４３０からの検索依頼（第２の個人情報送信要求）を受信する。情報提供装置１００は、検索依頼に応答して、個人情報記憶部４０に記憶する個人情報を抽出する。データＩＤ生成部５０は、データＩＤを生成して抽出した個人情報に付与する。そして、送信部６２は、匿名化個人情報を前記ポータル装置４３０に送信する。前記ポータル装置４３０は分散データベースシステム内に複数個設置してもかまわない。
以上のように、ポータル装置４３０はアクセス装置３４０から受信した検索依頼に対して、対象データを格納しているデータベースシステム３１０、３２０、３３０を検索するとともに、対象データの検索を行い、データベースシステム３１０、３２０、３３０から検索結果の返信を受けアクセス装置３４０に検索結果を返送する。
以上のように、ポータル装置４３０は、データ検索機能を備えるとともに、種別情報を記憶したので、どのデータベースシステムにいかなる個人情報が保有されているかを迅速に知ることができるので、効率的に個人情報を収集することができる。
【００５８】
次に別の例として、実現案８について説明する。
実現案８（図示しない）は、実現案７において、１度に複数個のデータベースシステム３１０、３２０、３３０に問い合わせが必要となるデータの検索依頼が行われた場合、検索結果に対してデータＩＤによるマージ処理をポータル装置４３０内の処理として付与することを特徴とするアノニマスな分散データベースシステムである。
【００５９】
実施の形態３では、検索装置４２０（管理装置の一例）を備えたので、アクセス装置３４０からデータベースシステムへの個人情報の検索を効率化することができる。
【００６０】
実施の形態４．
実施の形態４は、実施の形態１〜実施の形態３に関して、利便性を向上させるため、各データベースシステム３１０、３２０、３３０を自立的に巡回するエージェント機能を付加した形態である。したがって、実施の形態１〜実施の形態３に付加的機能を追加したものであるため、前記の実施の形態３の実現案８に続き、実現案９として説明を続ける。
【００６１】
以下に、実施の形態４における実現案９について説明する。
図１９は、実施の形態４に係る実現案９の分散データベースシステムを示している。以下では、実施の形態４として実現案９〜実現案１３を説明するが、実現案９〜実現案１３の分散データベースシステムは、アノニマスなデータに対する検索を自立的に巡回するエージェント４４０により実現することを特徴とする。
エージェント４４０が異常（対象データベースシステム３１０、３２０、３３０への経路異常や対象データベースダウン等）を検出した場合の処理については、特に制限はない。
エージェント４４０による検索処理が所定時間を超過した場合の処理については、特に制限はない。
【００６２】
次に、実施の形態４の別の例として実現案１０について説明する。
図２０は、実施の形態４における別の例である実現案１０を示す。
前記の実現案９では、エージェント４４０は（最悪）全データベースシステムを巡回する必要がある。このような問題を解決するため、図２０では、いずれのデータベースシステムに検索者の必要な情報が格納されているかを管理（前記「種別情報」を管理している）する機能、および、当該機能を利用してエージェント４４０の巡回経路計画の立案機能を付与したポータル装置４３０を当該システム内に設置する。
ここで、アクセス装置３４０とポータル装置４３０間の通信はエージェント４４０であるか否かは、特に制限はない。
【００６３】
次に別の例として、実現案１１について説明する。
実現案１１（図示しない）は、前記の実現案１０に対して、検索対象のデータとデータベースシステム３１０、３２０、３３０のみから経路計画を立案するのではなく、対象データベースシステム３１０、３２０、３３０への経路異常やデータベースダウン等の検索時のシステム状態（異常）を加味した巡回経路立案機能をポータル装置４３０に付与することを特徴とするアノニマスな分散データベースシステムである。ただし、構成制御情報の検出・更新機能の手段について、特に制限はない。
【００６４】
次に別の例として、実現案１２について説明する。
実現案１２（図示しない）は、実現案１０、および、実現案１１に対して、１度に複数個のデータベースシステム３１０、３２０、３３０に問い合わせが必要となるデータの検索依頼が行われた場合、検索結果に対してデータＩＤによるマージ処理をエージェント４４０が行うことを特徴とするアノニマスな分散データベースシステムである。
【００６５】
次に別の例として、実現案１３について説明する。
実現案１３（図示しない）は、実現案１０、あるいは、実現案１１の機能をエージェント４４０に持たせることを特徴とするアノニマスな分散データベースシステムである。
【００６６】
本実施の形態４においては、以上のようにエージェント方式を採用するので、アクセス装置３４０から個人情報を検索する効率を高めることができる。
【００６７】
以上、実施の形態１〜実施の形態４において種々機能を述べたが、「アノニマス（匿名化）・データベースシステムを構築するにあたり、実現が必要になると思われる機能、および、実現することにより便利になる機能、効率化につながる機能」について、以下にまとめ、実施の形態１〜実施の形態４において実現可能な機能として列挙する。
【００６８】
１．アノニマス・データの管理手段
各データベースシステム３１０、３２０、３３０が多段階の匿名化レベルを意識してデータを管理・制御することを特徴とするアノニマスな分散データベースシステムである。例えば、図１４における匿名化処理部１２０は、下記の規則に基づいて、個人情報記憶部１１０に記憶する個人情報を、レベルに分けて匿名化し、匿名化個人情報記憶部１３０に記憶して管理する。なお、下記の場合「匿名化」には、匿名化しない場合も含む。
すなわち、アクセス装置３４０やアクセス者の権限、および、使用目的等から匿名化レベルを制御する。ここで、データベースシステム３１０、３２０、３３０が同じ匿名化のレベルで個人情報を管理する必要はない。例えば、下記３つの匿名化の管理レベルが考えられる。
レベル１として、各データベースシステム３１０、３２０、３３０内で使用するデータであり、匿名化処理は施されていない。
レベル２として、外部システムにて処理されることを前提とすれば匿名化済みデータであるが、内部システムにおいてはデータＩＤから個人の特定が可能なデータである。
レベル３として、外部システムで処理されることを前提に匿名化を施したデータである。この匿名化したデータは、内部システムにおいても個人を特定することはできないデータである（例えば、統計処理を行うためのデータとして使用すること等を想定している。）。なお、例として匿名化のレベルを、レベル１〜レベル３に分けたが、これに限ることなく、匿名化のレベルは自由に設定できるものである。
前記のように、個人情報を匿名化のレベルに分けることにより、匿名性の確保を図るとともに、個人情報の利用性を高めることができる。
【００６９】
２．匿名性確保の確認
複数のアクセス装置３４０がある場合には、すべてのアクセス装置３４０、あるいは、アクセス者からの検索履歴（検索条件と検索結果）を保存し、アクセス履歴をルールベースにてチェックすることにより、当該システムの匿名性が確保されているかを確認することを特徴とするアノニマスな分散データベースシステムである。
ここで、検索履歴の保存期間やアクセス履歴のチェック期間（定期・不定期）について、特に制限はない。
【００７０】
３．課金システム
複数のアクセス装置３４０、あるいは、アクセス者からの検索履歴（検索条件と検索結果）を保存し、各データベースシステム３１０、３２０、３３０へのアクセス回数、あるいは、検索結果のデータ量からアクセス側の課金計算を行うことを特徴とするアノニマスな分散データベースシステムである。
同様に、検索履歴を情報提供者（個人・組織）（各データベースシステム３１０、３２０、３３０）への情報提供料の計算にも用いる。
【００７１】
４．セキュリティ
当該システムを構成する各機器は認証機能を有するとともに、ネットワーク３５０上を流れるデータを暗号化することを特徴とするアノニマスな分散データベースシステムである。例えば、通信データを公開鍵、秘密鍵等で暗号化し、公開鍵、秘密鍵等で復号する。
【００７２】
５．匿名性確保のための機能１
データの検索条件から「個人の特定」につながる検索条件を排除する機能を付与することを特徴とするアノニマスな分散データベースシステムである。どのような条件を排除するかを定義したルールベースをアクセス装置３４０のアクセス用インタフェース３６１やポータル装置４３０内、データベースシステム３１０、３２０、３３０内の機能として配置する。
【００７３】
６．匿名性確保のための機能２
各データベースシステム３１０、３２０、３３０から返送されるデータに対して、データ項目ごとに異なるキー、あるいは、異なる暗号化手段を用いて暗号化し、当該データに対するアクセス装置３４０やアクセス者の権限、データの利用目的にしたがって、参照可能なデータ項目を制御する仕組みを付与することを特徴とするアノニマスな分散データベースシステムである。例えば、異なるアルゴリズムや、異なる暗号鍵である。
当該機能の実現には、システム内にアクセス装置３４０、および、アクセス者に対する認証機能が必要となる。
【００７４】
７．匿名性確保のための機能３
各データベースシステム３１０、３２０、３３０に固有のキーを与え、アクセス装置３４０からデータベースシステム３１０、３２０、３３０へ送付する検索依頼情報（検索条件等）（個人情報送信要求の一例）を暗号化することにより、検索対象のデータベースシステム３１０、３２０、３３０でのみ暗号化した検索条件を前記の固有キーを用いて復号化できる仕組みを付与することを特徴とするアノニマスな分散データベースシステムである。検索条件が複数ある場合は、それぞれの条件を異なる暗号化手法で暗号化する。例えば、異なるアルゴリズムや、異なる暗号鍵である。なお、暗号化する場合は、前記のように検索条件ごとに暗号化してもよいし、また、データベースシステムごとに異なる暗号化としても構わない。
暗号化・復号化に使用する技術については、特に制限はない。
【００７５】
８．匿名性確保のための機能４
エージェント方式にてデータの収集を行う場合に、データ検索結果（個人情報）と引き換えにデータ検索条件をエージェント４４０内に保持する情報から削除する仕組みを付与することを特徴とするアノニマスな分散データベースシステムである。図１９を用いて説明する。図１９において、アクセス装置３４０は、個人情報を検索する複数の検索依頼（検索条件の一例）を設定する。そして、アクセス装置３４０は、データベースシステム３１０、３２０、３３０（複数の情報提供装置の一例）を巡回し個人情報を収集するエージェント４４０を生成し、生成したエージェント４４０に前記複数の検索依頼を付与してエージェント４４０を出力する。そして、アクセス装置３４０は、出力したエージェントにデータベースシステム３１０、３２０、３３０のいずれかから個人情報を収集させる。エージェント４４０がデータベースシステムから個人情報を収集したときは、エージェント４４０は、当該データベースシステムの個人情報の収集に用いた検索条件を消去する。
以上により、エージェント４４０に個人情報を収集させることで効率的に個人情報を収集することができる。また、ポータル装置４３０は、個人情報を収集した場合にエージェント４４０に当該個人情報を収集した検索条件を消去させるので、エージェント４４０は検索結果と当該検索結果に使用した検索条件とを同時に所有することはないので、エージェント４４０に個人情報を収集させる場合でも、匿名性を確保することができる。
【００７６】
９．匿名性確保のための機能５
検索結果のデータ数を判定し、所定数以下、あるいは、所定数に満たない場合は、匿名性が保証できない可能性があるため、検索結果を返送しないことを特徴とするアノニマスな分散データベースシステムである。
所定数は、各データベースシステム３１０、３２０、３３０において設定する。
【００７７】
１０．匿名性確保のための機能６
検索結果のデータ比率を判定し、所定比率以下、あるいは、所定比率に満たない場合は、匿名性が保証できない可能性があるため、検索結果を返送しないことを特徴とするアノニマスな分散データベースシステムである。
ここで、比率のベースとなる母集団の設定や所定比率は、各データベースシステム３１０、３２０、３３０において設定することができる。
【００７８】
１１．匿名性確保のための機能７
前記の「９．匿名性確保のための機能５」、および、「１０．匿名性確保のための機能６」を同時にデータベースシステム３１０、３２０、３３０に付与することを特徴とするアノニマスな分散データベースシステムである。
【００７９】
１２．匿名性確保のための機能８
前記の、「９．匿名性確保のための機能５」〜「１１．匿名性確保のための機能７」の機能を持つデータベースシステム３１０、３２０、３３０が混在することを特徴とするアノニマスな分散データベースシステムである。
【００８０】
１３．匿名性確保のための機能９
検索結果の所定データ項目にあらかじめ定めた特定データが含まれる場合は、匿名性が保証できない可能性があるため、検索結果そのものを返送しないことを特徴とするアノニマスな分散データベースシステムである。例えば、病歴のデータ項目として「白血病」が含まれる場合には返送しない等が想定できる。
ここで、どのようなデータ項目にどのようなデータが含まれていた場合に排除するかは各データベースシステム３１０、３２０、３３０において設定する。
【００８１】
１４．匿名性確保のための機能１０
検索結果の所定データ項目にあらかじめ定めた特定データが含まれる場合は、匿名性が保証できない可能性があるため、検索結果から該当するデータを削除した上で匿名化データを返送することを特徴とするアノニマスな分散データベースシステムである。
ここで、どのようなデータ項目にどのようなデータが含まれていた場合に排除するかは各データベースシステム３１０、３２０、３３０において設定する。
【００８２】
１５．匿名性確保のための機能１１
図１８を用いて説明する。本機能は、実現案７で説明したポータル装置４３０の機能についての付加的機能である。本機能は、図１８において、ポータル装置４３０がデータベースシステム３１０、３２０、３３０それぞれから送られてきた検索結果（匿名化された個人情報）に対して、それぞれの検索結果について匿名性が確保できているかどうかを判断する機能である。
具体的には、図１８のポータル装置４３０（管理装置の一例）は、前記の「９．匿名性確保のための機能５」〜「１４．匿名性確保のための機能１０」の各機能を備えている。ポータル装置４３０は、データベースシステム３１０、３２０、３３０等から検索結果（匿名化された個人情報）を受信した場合に、前記の各機能を用いて、それぞれのデータベースシステム３１０、３２０、３３０から受信したそれぞれの検索結果について、匿名性が保証できるかどうかを所定の基準に基づいて判断する。ポータル装置４３０は、匿名性が保証できると判断した場合に、検索結果をアクセス装置３４０へ送信する。以上を特徴とするアノニマスな分散データベースシステムである。以上の機能により、ポータル装置４３０が複数のデータベースシステム３１０、３２０、３３０等からの複数の検索結果（匿名化個人情報）を受信した場合に、それぞれのデータベースシステムからの個人情報の匿名性を確保することができる。
なお、以上説明したポータル装置４３０の機能である「データベースシステム３１０、３２０、３３０それぞれから送られてきた検索結果（匿名化された個人情報）に対して、それぞれの検索結果について匿名性が確保できているかどうかを判断する」ことは、前記に説明した実現案９〜実現案１３のエージェント４４０に持たせることも可能である。すなわち、エージェント４４０は、データベースシステム３１０、３２０、３３０等から検索結果（匿名化された個人情報）を収集した場合に、前記の「９．匿名性確保のための機能５」〜「１４．匿名性確保のための機能１０」の各機能を用いて、それぞれのデータベースシステム３１０、３２０、３３０から収集したそれぞれの検索結果について、匿名性が保証できるかどうかを所定の基準に基づいて判断する。エージェント４４０は、匿名性が保証できると判断した場合に、検索結果をアクセス装置３４０へ送信する。
【００８３】
１６．匿名性確保のための機能１２
図１８を用いて説明する。本機能は、前記の「１５．匿名性確保のための機能１１」と同様に、実現案７におけるポータル装置４３０の付加的機能である。図１８において、ポータル装置４３０は、複数のデータベースシステム３１０、３２０、３３０からの検索結果（匿名化された個人情報）を関連付け、関連付けた結果なお匿名性が確保できるかどうかチェックする。これは、例えば、データベースシステム３１０のみの検索結果であれば匿名性が確保できるが、データベースシステム３１０とデータベースシステム３２０との検索結果という複数の検索結果を関連付けると匿名性が確保できなくなる場合のあることを想定した機能である。
匿名性が確保できない場合には、ポータル装置４３０は検索結果をアクセス装置３４０に返送しないことを特徴とするアノニマスな分散データベースシステムである。どのような検索結果、あるいはデータ項目の組み合せを匿名性が確保できないとするかについては、自由に設定できるものとする。
以上の機能により、複数のデータベースシステムからの検索結果（匿名化個人情報）の匿名性を確保しつつ個人情報を互いに関連付けて、個人情報を効率的に利用することができる。
なお、以上説明したポータル装置４３０の機能である「複数のデータベースシステム３１０、３２０、３３０からの検索結果（匿名化された個人情報）を関連付け、関連付けた結果なお匿名性が確保できるかどうかチェックする」ことは、前記に説明した実現案９〜実現案１３のエージェント４４０に持たせることも可能である。
【００８４】
１７．匿名性確保のための機能１３
本機能も、図１８に示した実現案７におけるポータル装置４３０の付加的機能である。前記の「１６．匿名性確保のための機能１２」は、ポータル装置４３０が各データベースシステム３１０、３２０、３３０から得たそれぞれの検索結果を関連付けてチェックするものであった。この「１７．匿名性確保のための機能１３」は、ポータル装置４３０が、データベースシステム３１０等から時間を前後して得た検索結果を関連付けて匿名性の確保をチェックする機能である。すなわち、ポータル装置４３０（管理装置の一例）は、データベースシステム３１０等から過去に受信した検索結果（匿名化個人情報）を履歴として記憶している。そして、履歴としていない新たな検索結果をデータベースシステム３１０等から受信した場合、履歴としていない検索結果を履歴と関連付ける。そして、関連付けることによっても新たに受信した検索結果の匿名性が確保できると判断した場合に、ポータル装置４３０は、検索依頼（第１の個人情報送信要求）を受けたアクセス装置に新たに受信した検索結果（匿名化個人情報）を送信する。例えば、前記の「１６．匿名性確保のための機能１２」で述べたように、データベースシステム３１０、３２０、３３０の検索結果を関連付けることにより匿名性が確保できない場合が想定できるのと同様に、データベースシステム３１０のみの検索結果であっても過去の検索結果（検索履歴）と関連付けることにより、匿名性が確保できない場合も想定できるからである。
以上により、ポータル装置４３０は過去に受信した検索結果を履歴として記憶し新しく受信した検索結果と関連付けて匿名性が確保できるかどうか判断するので、過去の検索履歴をも含めて匿名性を確保することができる。
【００８５】
１８．データＩＤの生成手段１
データＩＤは、データ発生源等のある基準でデータを特定するためのＩＤであり、複数データベースシステム３１０、３２０、３３０から検索されたデータを関連付けるためのキーとなる。したがって、データＩＤから個人が特定可能な情報が生成できてはならない。ここで、各データベースシステム３１０、３２０、３３０が等しく保持している情報（個人名、性別、生年月日、住所等）を所定規則にしたがって変換し、データＩＤを生成することを特徴とするアノニマスな分散データベースシステムである。
【００８６】
１９．データＩＤの生成手段２
データＩＤの変換対象項目（および、その１項目）、あるいは、データの変換キー（および、その１項目）として、何らかの時刻情報（データ検索依頼時刻を想定している。特有情報の一例）を含むことを特徴とするアノニマスな分散データベースシステムである。
【００８７】
２０．データＩＤの生成手段３
データＩＤの変換対象項目（および、その１項目）、あるいは、データの変換キー（および、その１項目）として、データの検索依頼端末（アクセス送信者ＩＤの一例）、あるいは、検索依頼者のＩＤ（アクセス送信者ＩＤの一例）が含まれることを特徴とするアノニマスな分散データベースシステムである。
【００８８】
２１．データＩＤの生成手段４
前記データＩＤの生成手段２、および、前記データＩＤの生成手段３を組み合せたデータＩＤの生成手段を特徴とするアノニマスな分散データベースシステムである。
【００８９】
２２．データＩＤの生成手段５
１つのシステム内に複数のデータＩＤの生成手段が存在することを特徴とするアノニマスな分散データベースシステムである。
物理的に１つの分散型データベースシステムであるが、複数個の論理的なサブシステムとして扱う等により実現する。
【００９０】
２３．個人情報の他目的利用の許諾有無が混在する場合の処理手段１
個人情報の他目的利用に関する許諾を必須とし、許諾のない個人情報はすべて（匿名化している場合でも）返送しないことを特徴とするアノニマスな分散データベースシステムである。ここで「他目的利用」とは、当初予定した利用とは異なる、他の目的に利用する場合を意味する。例えば、集団の医療費の推移をみるために利用しようと予定していた個人情報を、個人の保健指導という他の目的に利用するような場合である。
【００９１】
２４．個人情報の他目的利用の許諾有無が混在する場合の処理手段２
個人情報の他目的利用に関する許諾の有無により、アクセス装置３４０へ返送する匿名化レベル（「１．アノニマス・データの管理手段」における匿名化レベル）を制御することを特徴とするアノニマスな分散データベースシステムである。例えば、図１４における情報提供装置２００の個人情報記憶部１１０は、個人情報の利用について利用許諾を受けている個人情報と利用許諾を受けていない個人情報との双方の個人情報を記憶している。匿名化処理部１２０は、利用許諾の有無により、所定のレベルの匿名化処理を行なう。利用許諾を受けているものであれば、前記の「１．アノニマス・データの管理手段」における、レベル２のような匿名化処理を行なう。あるいは、何の制限もなく自由に利用してよい旨の利用許諾を受けている個人情報であれば、前記の「１．アノニマス・データの管理手段」のレベル１のように、匿名化処理を施すことなくアクセス装置３４０に送信しても構わない。一方、利用許諾を受けていない場合は匿名化のレベルを高め、例えば、前記の「１．アノニマス・データの管理手段」におけるレベル３のように、統計情報としてのみ利用する。この点、許諾のない個人情報は返送しないとする、前記の「２３．個人情報の他目的利用の許諾有無が混在する場合の処理手段１」とは異なる。
以上のように、個人情報の利用許諾の有無により匿名化処理のレベルを変えることにより、個人情報の匿名性を確保した上で、個人情報の幅広い有効活用をすることができる。
【００９２】
２５．データＩＤから個人の特定を行う手段
各データベースシステム３１０、３２０、３３０において、データＩＤから個人を特定する仕組みを有することを特徴とするアノニマスな分散データベースシステムである。
データＩＤの生成処理をデータベースシステムに格納しているデータに対し、与えられたデータＩＤと等しいデータＩＤ生成できるデータを検索する手段により個人を特定する。
【００９３】
２６．許可者以外がデータＩＤから個人を特定できないための手段１
データＩＤから個人を特定する機能をデータ検索機能と同一機器に設置できないことを特徴とするアノニマスな分散データベースシステム（前記の「２５．データＩＤから個人の特定を行う手段」の拡張機能）である。
【００９４】
２７．許可者以外がデータＩＤから個人を特定できないための手段２
検索依頼時刻（特有情報の一例）や、検索依頼者を識別する識別子（特有情報の一例）等、各データベースシステム３１０、３２０、３３０には存在しない項目を用いてデータＩＤを生成する手段を選択するとともに、これらデータＩＤ生成時に必須となるデータ項目を暗号化してデータベースシステムへ送信することを特徴とするアノニマスな分散データベースシステムである。アクセス装置３４０側のみが有する特有の情報、例えば、「検索依頼時刻」、あるいは「検索依頼者を識別する識別子」などを加えることにより、所定のデータベースシステム、あるいは、データベースシステムにおける所定の操作者以外は、データＩＤから個人の特定をできないようにする。
すなわち、各データベースシステム３１０、３２０、３３０等において、データＩＤの生成に用いる個人情報のデータ項目としては、個人名、性別、生年月日、住所等があるが、さらにこれらの個人情報のデータ項目に加えて、検索依頼時刻のようなアクセス装置３４０のみが有する情報をデータＩＤ生成のデータ項目として追加する。
具体的な適用について、実施の形態１において述べた「介入サービスへの適用における処理の過程」を例にとり、説明する。以下では、図３と図５とを用い、データＩＤ生成と対比ＩＤ生成を中心に説明する。
（１）図５において、健康保険組合は、コンサルティング会社（アクセス装置３４０）に、どのような個人に、どのような健康促進のための介入サービスを実施すれば良いかの分析、調査を依頼する。コンサルティング会社は、この依頼に基づき、健康保険組合データベースシステム３７０に、例えばレセプト情報のような個人情報の個人情報送信要求を送信する。この個人情報送信要求には、個人情報を検索する検索条件と送信時の検索依頼時刻（特有情報の一例）が含まれている。
（２）健康保険組合データベースシステム３７０の情報提供装置１００（図３）は、前記個人情報送信要求を受信すると個人情報を抽出し、データＩＤ生成部５０がデータＩＤを生成する。このデータＩＤ生成部５０によるデータＩＤ生成において、アクセス装置３４０から受信した検索依頼時刻（特有情報の一例）はデータＩＤ生成の必須のデータ項目である。情報提供装置１００は、個人情報（図５ではレセプト情報）にデータＩＤを付与してアクセス装置３４０へ送信する。送信した個人情報のうちには、「三菱太郎」をデータＩＤ化した「Ｄａｓｆ１０４」のレセプト情報が含まれている。
（３）アクセス装置３４０は、健康保険組合データベースシステム３７０から収集した匿名化したレセプト情報と関連付けて分析、調査するため人事データベースシステム３８０へ勤怠情報の検索依頼を送信する。人事データベースシステム３８０は、この検索依頼に応答して、匿名化した勤怠情報をアクセス装置３４０へ送信する。人事データベースシステム３８０が送信した匿名化した勤怠情報の中には、「Ｄａｓｆ１０４」の勤怠情報が存在する。
（４）アクセス装置３４０は、健康保険組合データベースシステム３７０のレセプト情報と、人事データベースシステム３８０の勤怠情報とを分析する。そして生活習慣病予備軍として、「Ｄａｓｆ１０４」を決定する。アクセス装置３４０は、この分析結果を分析情報として保有する。そして、コンサルティング会社（アクセス装置３４０）は、健康保険組合からの分析、調査依頼に回答するべく分析情報（アクセス装置情報の一例）を健康保険組合データベースシステム３７０へ送信する。この分析情報には、以前にアクセス装置３４０から健康保険組合データベースシステム３７０への検索依頼時に送信した検索依頼時刻を含める。
（５）健康保険組合データベースシステム３７０の情報提供装置１００においては、アクセス装置３４０から受信した「Ｄａｓｆ１０４」が、いかなる個人であるかを特定するため、対比ＩＤ生成部５１が個人情報記憶部４０の記憶する個人情報と、分析情報（アクセス装置情報の一例）に含まれる検索依頼時刻とを用いて、「Ｄａｓｆ１０４」と対比して個人を特定するための対比ＩＤを生成する。この場合、分析情報に含まれる検索依頼時刻は、対比ＩＤを生成するための必須のデータであり、検索依頼時刻がなければ対比ＩＤを生成することはできない。例えば、「三菱太郎」の個人情報と検索依頼時刻とにより対比ＩＤが「Ｄａｓｆ１０４」と求められることで、介入の必要のある個人が、「三菱太郎」であることが判明する。
以上のように、本手段により、所定のデータベースシステムまたは所定の操作者以外はデータＩＤから個人の特定はできないようにして、個人情報の匿名性を確保することができる。
【００９５】
２８．許可者以外がデータＩＤから個人を特定できないための手段３
許可者以外がデータＩＤから個人を特定できないための前記の「２６．許可者以外がデータＩＤから個人を特定できないための手段１」と「２７．許可者以外がデータＩＤから個人を特定できないための手段２」とを組み合せた手段であることを特徴とするアノニマスな分散データベースシステムである。
【００９６】
２９．許可者以外がデータＩＤから個人を特定できないための手段４
アクセス装置３４０からの検索依頼以外でデータＩＤの生成を実施する場合、個人情報の他目的利用を許諾していない個人の情報はデータＩＤ生成ができないことを特徴とするアノニマスな分散データベースシステムである。
【００９７】
実施の形態５．
図２１〜図２５を用いて実施の形態５を説明する。実施の形態５では、実施の形態１〜実施の形態４に説明したシステムを具体的な事業におけるシステムに適用した、５つの適用例について説明する。
【００９８】
実施の形態１〜実施の形態４の適用例として、まずサンプルデータ提供システムについて以下に説明する。図２１は、サンプルデータ提供システムの概要を示す図である。
図２１は、情報収集者４５４が蓄積した実社会の個人情報を、匿名化した上で研究機関やコンサルティング会社等の情報利用者４５３へ提供するモデルである。サンプルデータ提供システムには、情報利用者４５３、情報収集者４５４、情報提供者４５５（使用許諾者）（個人・組織）、企業４５２、システム運営（構築）者４５１の５者が登場する。
情報利用者４５３は、研究等を進めるにあたり実社会のデータを欲する個人や組織を想定する。情報利用者４５３は、図２１に示すように、情報を入手する対価として、情報収集者４５４へ情報提供料、および、システム運営（構築）者４５１へシステム使用料を支払う。それぞれの費用として、従量制、定額制が考えられる。
情報収集者４５４は、本来、各自の業務を進めるためだけに個人の情報を収集、蓄積している。これら蓄積した情報に実施の形態１〜実施の形態４を適用することにより匿名化を保証し、他組織へ匿名化した個人情報を提供することが可能となる。情報収集者４５４は情報を提供する対価として、情報利用者４５３から情報提供料を受領することができる。ここで、情報提供料の算出手段として、提供データの情報量やアクセス者から検索された回数等による従量制と当該システムへの接続そのものに対しての定額制が考えられる。また、間接的なメリットとして、情報利用者４５３との関係強化や情報利用者４５３への情報提供そのものを商業的な宣伝に利用できる等が考えられる。
情報提供者４５５（使用許諾者）である個人、および、個人が所属する組織が何らかの社会活動を行うことにより、情報収集者４５４により個人情報が蓄積される。本例の場合は、実施の形態１〜実施の形態４の適用により個人情報の匿名化を保証するため、データの目的使用に関する個人の承諾は不要となると考える。また、サンプルデータ提供システムでは、情報提供者４５５（使用許諾者）（個人・組織）への明示的なリターンはない。
サンプルデータ提供システムにおける企業４５２は、情報利用者４５３に関連する機器やサービス等を提供する営利団体を想定している。検索画面や検索結果表示画面、メール等に企業広告を載せることにより、拡販の機会を提供する。企業４５２はその対価として広告料を支払う。情報収集者４５４、情報提供者４５５に対しても同様の広告を行ってもよい。
システム運営（構築）者４５１は、当該プラットフォームを前記４者へ提供する。その対価としてシステム使用料を徴収する。また、企業４５２に対して拡販の機会を提供することにより、広告料を徴収する。また、情報提供料を情報利用者４５３から徴収し、情報収集者４５４へ分配する。交付金、補助金、委託金等の公的な資金を利用して当該プラットフォームを構築することも想定する。
【００９９】
以上、サンプルデータ提供システムの適用例では、個人情報の保護については、実施の形態１〜実施の形態４の適用により解決可能である。
また、課金機能の構築については、課金ルールを作る。それに必要な場合は、ポータル装置４３０で各データベースシステム３１０等へのアクセス回数をカウントする仕組みを構築したり、また、ポータル装置４３０で各データベースシステム３１０等から検索したデータ量をカウントする仕組みを構築したりすることも可能である。
また、広告等の情報提示手段については、検索依頼画面にバーナーとして広告を表示（Ｗｅｂ画面イメージ）する機能や、検索結果ダウンロード画面にバーナーとして広告を表示（Ｗｅｂ画面イメージ）する機能等により実現することができる。
【０１００】
次に、実施の形態１〜実施の形態４の第２の適用例として、２種類のヘルスケアシステムを以下に説明する。まず、第１の適用例としてヘルスケアシステム例１を説明する。図２２は、ヘルスケアシステム例１の概要を示す図である。
図２２を用いて、ヘルスケアシステムの第１の例であるヘルスケアシステム例１について説明する。
図２２は、個人、および、個人が所属する組織の各種情報を分析することにより、個人、および、組織の健康状態を評価するとともに、個人や組織に対して健康を増進するため、あるいは、健康を保つための介入サービスを実施するためのモデルを示す。また、ヘルスケアシステム例１では、健康保険組合等の情報収集者４５４が中心となり、健康保険組合等の集団の健康を増進させることが主たる目的である。
図２１で述べたサンプル提供システムとは異なり、個人に対して分析結果を何らかの形態でフィードバックするため、個人情報の他目的利用、および、介入サービスの提供に関して各個人の許諾が必要となる。
ヘルスケアシステム例１には、情報利用者４５３（コンサルティング会社）、情報収集者４５４、情報提供者４５５（使用許諾者）（個人・組織）、情報提供者４５７（使用不許諾者）、サービス提供会社４５８、システム運営者４５１の６者が登場する。
ヘルスケアシステム例１の情報収集者４５４として、健康保険組合、企業（人事）、産業医等を想定している。介入サービスが軌道に乗ることにより、情報収集者４５４である健康保険組合は医療費の削減、企業は作業の効率化等の恩恵を得ることができる。各情報収集者４５４は、ヘルスケアシステム例１の運用をするにあたり、全情報提供者４５５（使用許諾者）（個人）から個人情報の他目的利用（ただし、情報の利用はヘルスケア関連に限る）、および、介入サービスの実施について許諾を得る必要がある。情報収集者４５４は、第三者であるコンサルティング会社（情報利用者４５３）に匿名化したデータを送付するとともに、データの分析を依頼する。分析内容の代表としては、個人、および、企業内組織単位の健康評価とその傾向、および、疾病予備軍の調査である。ここで、個人情報の他目的利用について許諾を得られない個人情報については、統計情報としてのみ使用する。
情報収集者４５４（例えば、健康保険組合を想定）は、情報利用者４５３であるコンサルティング会社（組織）から疾病予備軍である者のデータＩＤが送信されてきた場合に、このデータＩＤがいかなる個人を示すものか特定するために、自己の保有する個人情報をもとにデータＩＤを生成し、生成したデータＩＤと前記送信されたデータＩＤとを照合し、一致した個人を特定する。そして、特定した個人には、疾病予備軍に関する改善策を講じるために、疾病予備軍（不許諾者は除く）として健康増進サービスを提供する。ここで、健康増進サービスをサービス提供会社４５８に委託することもあり、その際には疾病予備軍に関する情報をサービス提供会社４５８へ提供する。
すなわち、情報利用者４５３であるコンサルティング会社（組織）は情報収集者４５４（当面は健康保険組合を想定）からの依頼に基づき、匿名化したデータの分析を行う。分析結果として、組織の健康評価と個人の健康評価を情報収集者４５４へ返送する。つまり、コンサルティング会社（組織）は、生活習慣病、成人病等の疾病予備軍の有無を検討し、疾病予備軍がいると判断したときは、その対象者をデータＩＤにて情報収集者４５４へ報告する。ここで、匿名化の保証ができなくなる恐れがあることを考慮し、コンサルティング会社（組織）は、依頼元（この事例では健康保険組合）に対して疾病予備軍の選定理由等を開示してはならないものとする。
ここで、コンサルティング会社（組織）と情報収集者４５４のいずれかが一致する場合は、分析を行う担当組織、あるいは（および）、担当者に対して契約等により守秘義務を科す必要がある。コンサルティング会社（組織）は、情報収集者４５４からの分析依頼に対する対価が収入となる。
情報収集者４５４から委託を受けるサービス提供会社４５８は情報収集者４５４より入手した対象者情報に従い、個人、および、個人の所属する組織に対して介入サービスを実施する。介入サービスには、運動指導や栄養指導、禁煙指導等が想定され、提供サービスの内容に応じて個人からも費用を徴収する場合がある。また、介入サービスの一環として、運動ジムの斡旋や配膳業者の斡旋等を行い、これら企業からのキックバックも収入源として想定できる。
また、健康保険の医療費抑制や作業効率の向上が明らかな場合は、その削減額の所定割合を成果報酬とすることを想定できる。
システム運営者４５１は、情報収集者４５４、あるいは、サービス提供会社４５８から委託を受け、個人情報の匿名化等を実施するシステムの運営を行う。ただし、システム運営者４５１は、情報収集者４５４、あるいは、サービス提供会社４５８と同一であってもかまわない。
情報提供者４５５（使用許諾者）（個人・組織）は、個人情報の他目的利用、および、介入サービスの提供を許諾した個人を想定する。ヘルスケアシステム例１における情報提供者４５５（使用許諾者）である組織は、情報収集者４５４（あるいはその一部）と一致すると想定しているため、組織が不許諾とすることはほぼないと考えられる。個人は健康向上・維持に関する情報が安価（あるいは、無償）で入手できるとともに、介入サービスにより斡旋を受けた運動ジムや配膳業者等の割引や健康保険組合等による費用の一部負担が期待できる。
情報提供者４５７（使用不許諾者）は、個人情報の他目的利用、および、介入サービスの提供を許諾しなかった個人を想定する。
【０１０１】
以上、ヘルスケアシステムの例１の適用例では、情報収集者４５４が提供する実データに対する匿名性保証については、実施の形態１〜実施の形態４の適用により解決可能である。
また、複数の情報収集者４５４からの匿名化したデータを関連付ける手段については、実施の形態１〜実施の形態４の適用により解決可能である。
また、データＩＤから個人を特定するための機能、および、その際の匿名性の確保手段については、実施の形態４で述べた「アノニマス（匿名化）・データベースシステムを構築するにあたり、実現が必要になると思われる機能、および、実現することにより便利になる機能、効率化につながる機能」における、「２５．データＩＤから個人の特定を行う手段」、「２６．許可者以外がデータＩＤから個人を特定できないための手段１」、「２７．許可者以外がデータＩＤから個人を特定できないための手段２」、「２８．許可者以外がデータＩＤから個人を特定できないための手段３」、「２９．許可者以外がデータＩＤから個人を特定できないための手段４」等の手段を利用することにより解決可能である。
また、健康評価手段については、個人に対する健康評価手段として「健康度」があり、当該健康度の適用を想定している。集団へ健康度を適用する場合については、個人の健康度を集積したものを想定している。
また、介入サービス適用効果の評価手段については、定期的にコンサルティング会社（組織）に組織の健康度分析を依頼する。また、介入サービスの提供履歴を管理する（サービス提供会社４５８からの報告義務、および、その蓄積）。当該情報を含めコンサルティング会社（組織）にて分析する。
また、情報提供に関する承諾をしない個人データの取り扱い、および、混在したデータの取り扱い機能の構築については、実施の形態４で述べた「アノニマス（匿名化）・データベースシステムを構築するにあたり、実現が必要になると思われる機能、および、実現することにより便利になる機能、効率化につながる機能」における「２３．個人情報の他目的利用の許諾有無が混在する場合の処理手段１」や「２４．個人情報の他目的利用の許諾有無が混在する場合の処理手段２」を利用することにより解決可能である。
また、医療費の削減や生産性向上等の間接的なメリットに対する評価手段については、特に制限しない。
【０１０２】
以下に、実施の形態１〜実施の形態４をヘルスケアに適用した第２の場合である、ヘルスケアシステム例２について説明する。図２３は、ヘルスケアシステム例２のシステムを示す図である。ヘルスケアシステム例２は、個人がコンサルティング会社へ依頼する場合を想定する。当該例では、従来はコンサルティング会社が保有するノウハウにて個人に対する介入方針等を決定していたが、それに加え個人が所属する組織の特性や個人の病歴等の情報を入手することが可能となり、コンサルティング会社（情報利用者４５３に該当する。以下同じ。）は、これら情報を加味して、詳細なアドバイスが可能となる。同一組織に所属する集団としての健康状態を分析することにより、個人にとって往々に注意外である外的要因の有無をコンサルティング会社が調査し、これまでは気が付かなかった要因を発見できる機会を広げる。
ヘルスケアシステム例２には、依頼者４６０、情報利用者４５３（コンサルティング会社）、情報収集者４５４、情報提供者４５５（使用許諾者）（個人・組織）、システム運営者４５１の５者が登場する。
依頼者４６０は、コンサルティング会社（組織）に健康等に関するサービス提供を依頼する。ここで、依頼者４６０は、情報提供者４５５（使用許諾者）（個人・組織）の構成員であることが前提である。
情報利用者４５３であるコンサルティング会社（組織）は依頼者４６０からの依頼に基づいて、依頼者個人、および、依頼者４６０の所属する組織について分析を行う。分析結果にしたがって、依頼者４６０への介入、あるいは、アドバイスの方針を決定する。
ヘルスケアシステム例２を利用する場合、コンサルティング会社はシステム運営者４５１へのシステム使用料支払い、情報収集者４５４への情報提供料支払い等、コストアップにつながる要因もあるが、過去に遡った詳細な個人情報など分析対象となる有意な情報を入手可能となるため、コンサルティング会社として保有するノウハウの精度を向上させることが期待でき、ひいては、医療費削減等が期待される。
システム運営者４５１は、コンサルティング会社（組織）からシステム使用料を徴収し、システムの運用・保守を行う。システム運営者４５１の位置付けは、前記サンプルデータ提供システムと大きな差異はない。
情報収集者４５４はコンサルティング会社へ匿名化した情報の提供を行う対価として、情報提供料を徴収する。ここで、コンサルティング会社へ提供する情報は、実データを匿名化し統計データとして使用、および、依頼者４６０本人の情報であり、情報提供者４５５（使用許諾者）（全員）に対する他目的利用許諾は不要であると考えている。
情報提供者４５５（使用許諾者）は情報収集者４５４が通常業務として行っているサービスを受けることにより、情報収集者４５４に個人情報が蓄積される。
【０１０３】
以上、ヘルスケアシステム例２の適用例では、情報収集者４５４が提供する実データに対する匿名性保証は、実施の形態１〜実施の形態４の適用により解決可能である。
また、複数の情報収集者４５４からの匿名化したデータを関連付ける手段は、実施の形態１〜実施の形態４の適用により解決可能である。
また、課金機能の構築は、前記サンプルデータ提供システムと同様である。すなわち、課金機能の構築については、課金ルールを作る。それに必要な場合は、ポータル装置４３０で各データベースシステム３１０等へのアクセス回数をカウントする仕組みを構築したり、また、ポータル装置４３０で各データベースシステム３１０等から検索したデータ量をカウントする仕組みを構築したりすることも可能である。
【０１０４】
次に、実施の形態１〜実施の形態４の別の適用例として２種類の介入サービス評価システムを説明する。まず、第１の例である介入サービス評価システム例１について説明する。図２４は、介入サービス評価システム例１の概要を示す。
集団又は個人の健康状態（健康の評価結果）の履歴を管理することにより、介入サービス等の有効度を評価する。介入サービスを評価するためのデータ取得に実施の形態１〜実施の形態４を使用する。図２４に示す介入サービス評価システム例１は、サービス提供会社４５８、情報収集者４５４（委託元）、情報提供者４５５（使用許諾者）（個人・組織）、システム運営者４５１、サービス評価会社４６１の５者が登場する。
ヘルスケアシステム例１と同様に、情報収集者４５４は、個人に対する介入サービスをサービス提供会社４５８へ委託する。さらに、情報収集者４５４は、サービス評価会社４６１に対して、当該サービス提供会社４５８が提供するサービスを評価するよう依頼する。サービス評価会社４６１へは、情報提供者４５５（使用許諾者）（個人・組織）の匿名化したデータを提供する。当該データから個人を特定する必要はないため、情報提供者４５５（使用許諾者）（個人）に対して個人情報の他目的利用の許諾は不要であると考える。
情報提供者４５５（使用許諾者）（個人・組織）は、サービス提供会社４５８よりサービスの提供を受ける。
サービス提供会社４５８は、情報収集者４５４からの委託に従い、個人に対して介入サービスを提供する。
サービス評価会社４６１は、情報収集者４５４より情報提供者４５５（使用許諾者）（個人・組織）の匿名化した情報を定期的に入手し、集団又は個人としての健康状態のトレンドを分析・評価する。その結果をサービス提供会社４５８の評価として情報収集者４５４へ提示する。
システム運営者４５１は、情報収集者４５４とサービス評価会社４６１との間のデータ通信において、匿名化するためのプラットフォームを提供する。システムの運用・保守の対価としてサービス評価会社４６１からシステム使用料を徴収する。
【０１０５】
以上、介入サービス評価システム例１の適用例では、情報収集者４５４が提供する実データに対する匿名性保証は、実施の形態１〜実施の形態４の適用により解決可能である。
また、複数の情報収集者４５４からの匿名化したデータを関連付ける手段は、実施の形態１〜実施の形態４の適用により解決可能である。
また、集団に対する健康度の評価機能の構築は、個人に対する健康評価手段として「健康度」があり、当該健康度の適用を想定している。集団の健康度については、個人の健康度を集積したものを想定している。
また、介入サービス適用効果の評価手段は、集団の健康度を蓄積し、トレンドを評価する。
【０１０６】
実施の形態１〜実施の形態４を適用した第２の介入評価サービスのシステムについて以下に説明する。
図２５は、介入サービス評価システム２のしくみの一例を示す。図２５において、サービス評価会社４６１は、サービス提供会社４５８の評価のみでなく、サービス提供会社４５８に対するコンサルティングをも行う。介入サービス評価システム２に必要となる基本的な仕組みは、図２４における前記介入サービス評価システム１と同様である。
サービス評価会社４６１は、サービス提供会社４５８のサービス提供先集団の健康状態（健康の評価結果）、および、その履歴を管理することにより介入サービス等の有効度を評価する。サービス評価会社４６１は、その結果から効果のあがっていない項目の有無、および、内容をサービス提供会社４５８に提示するとともに、その対策についてアドバイスする。
介入サービスを評価するためのデータ取得に実施の形態１〜実施の形態４を使用する。介入サービス評価システム２には、サービス提供会社４５８、情報収集者４５４（委託元）、情報提供者４５５（使用許諾者）（個人・組織）、システム運営者４５１、サービス評価会社４６１の５者が登場する。
情報収集者４５４は、サービス評価会社４６１に対して、情報提供者４５５（使用許諾者）（個人・組織）の匿名化したデータを提供する。その対価として、情報提供料を徴収することが可能となる。当該データから個人を特定する必要はないため、情報提供者４５５（使用許諾者）（個人）に対して個人情報の他目的利用の許諾は不要であると考える。
情報提供者４５５（使用許諾者）（個人・組織）は、サービス提供会社４５８よりサービスの提供を受ける。
サービス提供会社４５８は、個人に対して介入サービスを提供する。サービス提供会社４５８は、自社が提供するサービスに対するコンサルティングをサービス評価会社４６１に依頼する。
サービス評価会社４６１は、情報収集者４５４より情報提供者４５５（使用許諾者）（個人・組織）の匿名化した情報を定期的に入手し、集団としての健康状態のトレンドを分析・評価する。ここで、情報入手の対価として情報提供料を情報収集者４５４へ支払う。その結果からサービス提供会社４５８へコンサルティングを実施する。
システム運営者４５１は、情報収集者４５４からサービス評価会社４６１間とのデータ通信において、匿名化するためのプラットフォームを提供する。システムの運用・保守の対価としてサービス評価会社４６１からシステム使用料を徴収する。
【０１０７】
以上、介入サービス評価システム例２の適用例では、情報収集者４５４が提供する実データに対する匿名性保証については、実施の形態１〜実施の形態４の適用により解決可能である。
また、複数の情報収集者４５４からの匿名化したデータを関連付ける手段については、実施の形態１〜実施の形態４の適用により解決可能である。
また、集団に対する健康度の評価機能の構築については、個人に対する健康評価手段として「健康度」があるが、当該健康度の適用を想定している。ただし、集団の健康度については、個人の健康度を集積したものを想定している。
また、介入サービス適用効果の評価手段については、集団の健康度を蓄積し、トレンドを評価する。
【０１０８】
実施の形態５では、匿名化を保証するとともに個人情報を関連付けすることにより、個人情報の利用促進を図ることができるシステムを事業へ適用することによって、個人情報の利用に基づいた新たなサービス、新たなビジネスを提供することができる。
【０１０９】
【発明の効果】
本発明によれば、個人情報に関してプライバシーを高度に確保して、個人情報を有効に利用することができる。また、複数のデータベースシステムに格納された同一人についての個人情報を関連付けることにより、個人情報の有効利用を可能とすることができる。
【図面の簡単な説明】
【図１】 実施の形態１のシステム構成例を示す図である。
【図２】 実施の形態１の実装の概要を示す図である。
【図３】 実施の形態１に係る情報提供装置１００の構成を示す図である。
【図４】 個人情報の送信要求を受けた場合のフローを示す図である。
【図５】 実施の形態１を介入サービスに適用したシステム適用例を示す図である。
【図６】 検索条件の例を示す図である。
【図７】 検索条件の一部を削除した図である。
【図８】 データベースからの検索結果を示す図である。
【図９】 データＩＤの付与を示す図である。
【図１０】 プライバシーに関わる情報の削除の様子を示す図である。
【図１１】 実施の形態１におけるシステムの機能を示す図である。
【図１２】 実施の形態２におけるシステム構成概要を示す図である。
【図１３】 実現案１を示す図である。
【図１４】 情報提供装置２００の構成を示す図である。
【図１５】 関連付け分散データベースシステム５００の構成を示す図である。
【図１６】 実現案２を示す図である。
【図１７】 実現案３〜実現案５を示す図である。
【図１８】 実現案７を示す図である。
【図１９】 実現案９を示す図である。
【図２０】 実現案１０を示す図である。
【図２１】 サンプルデータ提供システムの構成を示す図である。
【図２２】 ヘルスケアシステム例１の構成を示す図である。
【図２３】 ヘルスケアシステム例２の構成を示す図である。
【図２４】 介入サービス評価システム例１の構成を示す図である。
【図２５】 介入サービス評価システム例２の構成を示す図である。
【符号の説明】
１０ 受信部、１１ 認証部、１２ 復号部、２０ 検索条件確認部、３０ 個人情報抽出部、４０ 個人情報記憶部、５０ データＩＤ生成部、５１ 対比ＩＤ生成部、６０ 検索結果判断部、６１ 暗号作成部、６２ 送信部、７０ 規則記憶部、８０ 課金部、１００ 情報提供装置、１１０ 個人情報記憶部、１２０ 匿名化処理部、１２１ データＩＤ生成部、１３０ 匿名化個人情報記憶部、１４０ 受信部、１５０ 送信部、２００ 情報提供装置、３１０，３２０，３３０ データベースシステム、３４０ アクセス装置、３５０ ネットワーク、３６０，３６１ アクセス用インタフェース、３７０ 健康保険組合データベースシステム、３８０ 人事データベースシステム、３９０ 産業医データベースシステム、４００，４１０ データベースシステム、４１５ アノニマス化データベースシステム、４１６ データベースシステム、４２０ 検索装置、、４３０ ポータル装置、４４０ エージェント、４５０ 国、４５１ システム運営者、４５２ 企業、４５３ 情報利用者、４５４ 情報収集者、４５５ 情報提供者、４５７ 情報提供者（使用不許諾者）、４５８ サービス提供会社、４６０ 依頼者、４６１ サービス評価会社、５００ 関連付け分散データベースシステム、６００ 第１プライベートデータベース装置、６１０ 第１識別子生成部、６２０ 第１組み合わせデータ作成部、６３０ 第１記憶部、７００第２プライベートデータベース装置、７１０ 第２識別子生成部、７２０ 第２組み合わせデータ作成部、７３０ 第２記憶部、８００ データベースアクセス装置、８１０ 識別子照合部、８２０ 関連データ記憶部。

Claims (3)

1. アクセス装置と、
   ネットワークを介して前記アクセス装置と通信可能であり、前記アクセス装置からの要求に基づき前記アクセス装置に情報提供を行う複数の情報提供装置と
   を備えた分散データベースシステムに属する前記情報提供装置において、
   個人に関する個人情報を記憶する個人情報記憶部と、
   前記アクセス装置から個人情報を検索する検索条件を含む個人情報送信要求を受信する受信部と、
   前記受信部によって受信された前記個人情報送信要求に含まれる前記検索条件に基づいて前記個人情報記憶部を検索し個人情報を抽出する個人情報抽出部と、
   同一人の個人情報であれば前記複数の情報提供装置のどの前記情報提供装置によっても前記同一人の個人情報から同一の値として生成される識別子を示すデータＩＤの生成規則であって、同一人の個人情報については前記複数の情報提供装置のどの前記情報提供装置においても同じ所定の項目を使用する生成規則が定義されたデータＩＤ生成規則と、どのような情報が個人を特定可能な情報に該当するかという規則であって、個人を特定可能な項目が予め定義された特定可能規則とを記憶する規則記憶部と、
   前記個人情報抽出部の抽出した個人情報から前記データＩＤ生成規則に基づいて前記データＩＤを生成し、生成したデータＩＤを前記抽出した個人情報に付与するデータＩＤ生成部と、
   前記個人情報抽出部が抽出しデータＩＤが付与された個人情報の中に個人の特定が可能な項目が含まれているかどうかを前記規則記憶部に記憶されている前記特定可能規則により判断し、個人の特定が可能な項目が含まれていないと判断したときは前記データＩＤが付与された個人情報をそのまま前記アクセス装置に送信し、個人の特定が可能な項目が含まれていると判断したときはデータＩＤが付与された前記個人情報から該当する項目を削除してから前記個人情報を前記アクセス装置に送信する検索結果判断部と
   を備えると共に、
   前記受信部は、
   前記検索結果判断部によって前記データＩＤが付与された前記個人情報を送信された前記アクセス装置から前記データＩＤを受信し、
   前記データＩＤ生成部は、
   前記受信部によって前記データＩＤが受信された場合に、受信された前記データＩＤと対比するための対比ＩＤを前記個人情報記憶部に記憶されている前記個人情報から前記データＩＤ生成規則に基づいて生成し、
   前記情報提供装置は、さらに、
   前記対比ＩＤ生成部によって前記対比ＩＤが生成されると前記対比ＩＤと前記受信されたデータＩＤとが一致するかどうかを判定し、一致と判定すると、前記対比ＩＤの生成元となった個人情報からその個人を特定する手段を
   備えたことを特徴とする情報提供装置。
2. 前記検索結果判断部は、
   前記個人情報抽出部が複数人の個人情報を抽出したときに、抽出した複数人の個人情報の数が所定の数以下のときは前記アクセス装置へ前記抽出した複数人の個人情報を送信しないことを特徴とする請求項１記載の情報提供装置。
3. 前記個人情報記憶部は、
   所定の集団に属する個人に関する個人情報を記憶し、
   前記検索結果判断部は、
   前記個人情報抽出部が複数人の個人情報を抽出したときに、抽出した複数人の個人情報の数を前記複数人が属する集団の総人数に対する比率に換算し、換算した換算値が所定の値以下のときは前記アクセス装置へ前記抽出した複数人の個人情報を送信しないことを特徴とする請求項１または２のいずれかに記載の情報提供装置。

Images