特許 6104674 匿名情報配信システム、匿名情報配信方法及び匿名情報配信プログラム

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

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

(11)【特許番号】6104674

(24)【登録日】2017年3月10日

(45)【発行日】2017年3月29日

(54)【発明の名称】匿名情報配信システム、匿名情報配信方法及び匿名情報配信プログラム

(51)【国際特許分類】

   G06Q 30/02 20120101AFI20170316BHJP

   G06Q 50/10 20120101ALI20170316BHJP

【ＦＩ】

   G06Q30/02 470

   G06Q50/10

【請求項の数】5

【全頁数】28

(21)【出願番号】特願2013-74897(P2013-74897)

(22)【出願日】2013年3月29日

(65)【公開番号】特開2014-199589(P2014-199589A)

(43)【公開日】2014年10月23日

【審査請求日】2016年3月18日

(73)【特許権者】

【識別番号】591117192

【氏名又は名称】ニフティ株式会社

(74)【代理人】

【識別番号】100113608

【弁理士】

【氏名又は名称】平川 明

(74)【代理人】

【識別番号】100105407

【弁理士】

【氏名又は名称】高田 大輔

(72)【発明者】

【氏名】小栗 秀暢

(72)【発明者】

【氏名】黒政 敦史

【審査官】 大野 朋也

(56)【参考文献】

【文献】 国際公開第２０１１／１４２３２７（ＷＯ，Ａ１）

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

【文献】 国際公開第２０１２／０６３５４６（ＷＯ，Ａ１）

【文献】 国際公開第２０１２／０６７２１３（ＷＯ，Ａ１）

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

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

Ｇ０６Ｑ １０／００−９９／００

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

【請求項1】

配信ポリシーに基づいて個人情報を匿名化処理した匿名情報を配信する匿名情報配信システムであって、
前記個人情報、前記配信ポリシー又は前記匿名情報の配信状況が変更された場合に、当該変更によって匿名化処理時点の前記配信ポリシーを満たさなくなった情報をフィルタ条件としてフィルタ用記憶部に記憶させるフィルタ設定部と、
匿名情報記憶部から読み出した匿名情報のうち前記フィルタ条件に該当する情報を除外して配信可能な匿名化情報を取得する、又は前記フィルタ条件に該当しない匿名情報を前記匿名情報記憶部にリクエストして配信可能な匿名情報を取得する取得部と、
前記配信可能な匿名情報を配信する配信部と、
を備える匿名情報配信システム。

【請求項2】

特定の属性値に係る利用を拒否するように配信ポリシーが変更された場合に、当該特定の属性値を含む匿名情報の利用を制限する請求項１に記載の匿名情報配信システム。

【請求項3】

前記匿名情報が、属性の情報と、当該属性の情報を持つ個人の人数を含み、
特定の属性値に係る利用を拒否するように配信ポリシーが変更された場合に、当該特定の属性値を含む匿名情報の人数を減算して所定値未満となった場合、当該匿名情報の利用を制限する請求項１に記載の匿名情報配信システム。

【請求項4】

配信ポリシーに基づいて個人情報を匿名化処理した匿名情報を配信する匿名情報配信方法であって、
前記個人情報、前記配信ポリシー又は前記匿名情報の配信状況が変更された場合に、当該変更によって匿名化処理時点の前記配信ポリシーを満たさなくなった情報をフィルタ条件としてフィルタ用記憶部に記憶させるステップと、
匿名情報記憶部から読み出した匿名情報のうち前記フィルタ条件に該当する情報を除外して配信可能な匿名化情報を取得する、又は前記フィルタ条件に該当しない匿名情報を前記匿名情報記憶部にリクエストして配信可能な匿名情報を取得するステップと、
前記配信可能な匿名情報を配信するステップと、
をコンピュータが実行する匿名情報配信方法。

【請求項5】

配信ポリシーに基づいて個人情報を匿名化処理した匿名情報を配信する匿名情報配信プログラムであって、
前記個人情報、前記配信ポリシー又は前記匿名情報の配信状況が変更された場合に、当該変更によって匿名化処理時点の前記配信ポリシーを満たさなくなった情報をフィルタ条件としてフィルタ用記憶部に記憶させるステップと、
匿名情報記憶部から読み出した匿名情報のうち前記フィルタ条件に該当する情報を除外して配信可能な匿名化情報を取得する、又は前記フィルタ条件に該当しない匿名情報を前記匿名情報記憶部にリクエストして配信可能な匿名情報を取得するステップと、
前記配信可能な匿名情報を配信するステップと、
をコンピュータに実行させるための匿名情報配信プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、個人情報を匿名化又は多様化して利用する技術に関する。

【背景技術】

【0002】

情報処理技術の発展に伴い、日常の多くの場面で情報が収集され、この収集された情報を用いた処理が行われている。例えば、消費者が店舗の会員となって商品を購入する場合、会員登録時に消費者の氏名、年齢、性別、住所、メールアドレス等を登録することが多い。そして、消費者が商品を購入すると、店舗側のシステムが、この消費者と購入した商品の情報を対応付けて記録する。このように購入した商品の情報を蓄積して分析すると、当該消費者の嗜好が推定でき、この消費者が好む新商品が発売されたような場合にダイレクトメールを発送するといったサービスを行うことができる。更に、多くの消費者の情報について分析することで、２０代女性の好む商品や関東エリアで好まれる商品といった情報を導くことができ、マーケティング等に利用される。

【0003】

これらの情報は、当該店舗だけでなく、商品を製造するメーカや、他の企業にとっても利用価値が高く、例えば広告やクーポン等のレコメンドに用いたいという要求があった。

【0004】

しかし、店舗が有する消費者の個人情報を各消費者の許諾を得ずに、他者へ提供することはできない。同様に医療機関等で患者が診療を受けた際の情報（診療情報）を利用したいという要求があるが、機微情報でもある診療情報を各患者の許諾を得ずに、他者へ提供することはできない。

【0005】

このため個人から収集した情報を匿名化して他の事業者等に提供し、他の事業者からの広告を各個人へ仲介するシステムが提案されている。例えば、特開２００５−３４６２４８号公報（特許文献５）では、診療情報（個人特定情報及び診断結果情報）から氏名等を除外して匿名化個人情報とし、匿名化個人情報を登録事業者に提供し、登録事業者から前記匿名化個人情報に対する広告メールを受け付け、当該広告メールを匿名化個人情報と対応する各個人のメールアドレス宛てに転送する情報仲介装置が提案されている。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２００３−１９６３９１号公報

【特許文献2】特開２００３−２３３５５１号公報

【特許文献3】特開２００５−１００４０８号公報

【特許文献4】特開２００４−０８６３８３号公報

【特許文献5】特開２００５−３４６２４８号公報

【発明の概要】

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

【0007】

特許文献５のシステムは、氏名等を除外することで、匿名化を行っているが、単に氏名を伏せるだけでは、匿名化が不十分な場合がある。

【0008】

例えば、年齢と病名が記載されているデータに２５歳で病名Ｘの人が一人だけであると、２５歳の知人がその病名Ｘの患者であることを知った時点で、その人を特定できることになる。即ち、２５歳で病名Ｘという属性を持つ人が一人だけであると、他の情報と照らし合わせることで、個人を特定できる可能性が高い。

【0009】

そこで、患者データの年齢の記載を１０歳区切りに抽象化し、２０代で病名Ｘの人が３人のように同じ属性を持つ人が複数人となるようにすれば、３人のうちの誰であるかを特定できなくなる。このように同じ属性を持つ人がｋ人以上いる状態を、「k-匿名性」を満たすと称し、そのようにデータを加工することを「k-匿名化」と称する。

【0010】

このように個人情報を「k-匿名化」を満たすように処理して、匿名化済データとした上で他の事業者等に提供すれば、高い匿名性を確保することができる。

【0011】

しかし、「k-匿名化」を満たすことを条件として匿名化済データを配信する場合、匿名化する個人情報等が変化すると、匿名化処理をやり直さなければならず、匿名化済データを円滑に配信できなくなることがあった。

【0012】

例えば、会員情報を匿名化して、同じ属性を持つ会員がｋ人以上いる状態とした匿名情報を提供するときに、会員が退会して同じ属性を持つ会員がｋ未満となった場合、この匿名情報は配信できなくなってしまう。

【0013】

また、年齢、性別、居住地、病名等の属性からなる個人情報を匿名化し、同じ属性を持つ人がｋ人以上いる状態とした匿名情報を提供するときに、居住地の情報を提供しないようにポリシーの変更があった場合、この居住地の情報を含めて「k-匿名化」の処理を行った匿名情報は配信できなくなってしまう。

【0014】

このように会員の変動やポリシーの変更によって、「k-匿名化」を満たさなくなった場合や、「k-匿名化」を満たしているか否かが確認できなくなった場合等、個人情報に係る状況が変化した場合には、再演算して「k-匿名化」を確認する必要があるが、一般に匿名化処理には多大な時間を要するため、個人情報に係る状況が変化する毎に匿名化処理の再演算を行ったのでは、匿名化済データを円滑に配信することは困難である。

【0015】

そこで本発明は、個人情報に係る状況が変化した場合でも再演算することなく必要な匿名性を満たした状態で匿名情報を配信可能にする技術を提供する。

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

【0016】

上記課題を解決するため、本発明の匿名情報配信システムは、
配信ポリシーに基づいて個人情報を匿名化処理した匿名情報を配信するシステムであって、
前記個人情報、前記配信ポリシー又は前記匿名情報の配信状況が変更された場合に、当該変更によって匿名化処理時点の前記配信ポリシーを満たさなくなった情報をフィルタ条件としてフィルタ用記憶部に記憶させるフィルタ設定部と、
匿名情報記憶部から読み出した匿名情報のうち前記フィルタ条件に該当する情報を除外して配信可能な匿名化情報を取得する、又は前記フィルタ条件に該当しない匿名情報を前記匿名情報記憶部にリクエストして配信可能な匿名情報を取得する取得部と、
前記配信可能な匿名情報を配信する配信部と、
を備える。

【0017】

前記匿名情報配信システムは、特定の属性値に係る利用を拒否するように配信ポリシーが変更された場合に、当該特定の属性値を含む匿名情報の利用を制限しても良い。

【0018】

前記匿名情報配信システムは、前記匿名情報が、属性の情報と、当該属性の情報を持つ個人の人数を含み、
特定の属性値に係る利用を拒否するように配信ポリシーが変更された場合に、当該特定の属性値を含む匿名情報の人数を減算して所定値未満となった場合、当該匿名情報の利用
を制限しても良い。

【0019】

また、上記課題を解決するため、本発明の匿名情報配信方法は、
配信ポリシーに基づいて個人情報を匿名化処理した匿名情報を配信する方法であって、
前記個人情報、前記配信ポリシー又は前記匿名情報の配信状況が変更された場合に、当該変更によって匿名化処理時点の前記配信ポリシーを満たさなくなった情報をフィルタ条件としてフィルタ用記憶部に記憶させるステップと、
匿名情報記憶部から読み出した匿名情報のうち前記フィルタ条件に該当する情報を除外して配信可能な匿名化情報を取得する、又は前記フィルタ条件に該当しない匿名情報を前記匿名情報記憶部にリクエストして配信可能な匿名情報を取得するステップと、
前記配信可能な匿名情報を配信するステップと、
をコンピュータが実行する。

【0020】

また、本発明は、上記匿名情報配信方法をコンピュータに実行させるためのプログラムであっても良い。更に、前記匿名情報配信プログラムは、コンピュータが読み取り可能な記録媒体に記録されていても良い。

【0021】

ここで、コンピュータが読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータから読み取ることができる記録媒体をいう。このような記録媒体の内コンピュータから取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、CD-ROM、CD-R/W、DVD、DAT、８mmテープ、メモリカード等がある。

【0022】

また、コンピュータに固定された記録媒体としてハードディスクやＲＯＭ（リードオンリーメモリ）等がある。

【発明の効果】

【0023】

本発明は、個人情報に係る状況が変化した場合でも再演算することなく必要な匿名性を満たした状態で匿名情報を配信可能にする技術を提供できる。

【図面の簡単な説明】

【0024】

【図1】図１は匿名化処理の説明図である。

【図2】図２は匿名情報配信システムの機能ブロック図である。

【図3】図３は病院情報サーバのハードウェア構成を示す図である。

【図4】図４は医療情報ＤＢの一例を示す図である。

【図5】図５は配信ポリシーの例を示す図である。

【図6】図６は配信ポリシーの例を示す図である。

【図7】図７は匿名情報ＤＢの一例を示す図である。

【図8】図８はフィルタＤＢに記憶されるフィルタ条件の例を示す図である。

【図9】図９は匿名価値評価システムの概略構成図である。

【図10】図１０は検索情報蓄積ＤＢの一例を示す図である。

【図11】図１１は対象データにおける年齢の項目の一部の例を示す図である。

【図12】図１２は年齢について検索情報蓄積ＤＢから取得する価値データの一例を示す図である。

【図13】図１３は年齢の項目の価値を示す図である。

【図14】図１４は年齢の項目の価値を示す図である。

【図15】図１５は抽象化候補における年齢の項目の一部の例を示す図である。

【図16】図１６は年代について取得する各ワードの価値データの一例を示す図である。

【図17】図１７は年代の項目の価値を示す図である。

【図18】図１８は年代の項目の価値を示す図である。

【図19】図１９は配信情報管理システムの概略構成図である。

【図20】図２０は配信情報管理システムが、他の事業者の端末から受信する要求情報の一例を示す図である。

【図21】図２１は匿名情報配信システムによる匿名化処理の説明図である。

【図22】図２２は候補パターンの説明図である。

【図23】図２３は配信ポリシー等の変更を受け付けた場合にフィルタ条件を設定する処理の説明図である。

【図24】図２４は匿名情報を他の事業者へ配信する処理の説明図である。

【図25】図２５は匿名情報を他の事業者へ配信する処理の説明図である。

【図26】図２６は匿名情報配信システムが患者（ユーザ）に対して配信情報を出力する処理の説明図である。

【図27】図２７は患者側配信ポリシーを変更した例を示す図である。

【図28】図２８はシステム側配信ポリシーを変更した例を示す図である。

【図29】図２９は配信情報の対象に係るシステム側配信ポリシーを変更した例を示す図である。

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

【0025】

以下、図面を参照して本発明を実施するための形態について説明する。以下の実施の形態の構成は例示であり、本発明は実施の形態の構成に限定されない。
〈実施形態１〉
図１は匿名化処理の説明図、図２は匿名情報配信システムの機能ブロック図である。

【0026】

図１（Ａ）は、姓、年齢、性別の項目を含む会員情報から姓の項目を削除した例を示す。図１（Ａ）に示すように年齢が記載されている会員情報に１６歳の女性が一人だけであると、１６歳の女性が、この会員であることが分かった時点で、その人を特定できる。即ち、１６歳・女性という属性を持つ人が一人だけであると、他の情報と照らし合わせることで、個人を特定できる可能性がある。

【0027】

図１（Ｂ）では、会員リストの年齢の記載を抽象化し、０代（１０歳未満）、１０代、２０代のように年代別とした。しかし、この場合でも１０代女性は一人だけであり、図１（Ａ）と同様に個人が特定できてしまい匿名化としては不十分である。

【0028】

そこで、図１（Ｃ）では、更に抽象化し、１０代以下（１９歳以下）と２０代のように年代の区切りを変更した。図１（Ｃ）の場合、１０代以下の女性が２人であり、［１０代以下］及び［女性］という属性が単一では無くなる。このため前述のように１６歳の女性が、この会員であることが分かったとしても、どちらが当該１６歳女性のデータであるかは特定できない。このように同じ属性を持つ人がｋ人（本例では２人）以上いる状態を、「k-匿名性」を満たすと称し、そのようにデータを加工することを「k-匿名化」と称する。

【0029】

図２に示すように匿名情報配信システム１００は、病院情報システム（ＨＩＳ：Hospital Information System）１０や、匿名価値評価システム２０、配信情報管理システム３
０を有する。病院情報システム１０は、病院や健診センター等の医療機関に設けられ、治療や診断を受ける者（以下に患者又はユーザと称す）の医療情報（個人情報）を管理するシステムである。匿名価値評価システム２０は、検索エンジン４０で検索に用いられたキーワードの統計情報に基づいて抽象化した語の価値を求め、この抽象化した語で構成される匿名情報の価値を算出するシステムである。配信情報管理システム３０は、匿名情報を他の事業者（配信情報の発信者）へ提供及び当該事業者から匿名情報に対する配信情報を受信し、各患者に配信するシステムである。

【0030】

本実施形態１の匿名情報配信システム１００は、病院情報システム１０が、医療情報を「k-匿名性」が満たされるように抽象化して複数の抽象化候補データ（以下単に抽象化候補とも称す）とする。また、病院情報システム１０は、この複数の抽象化候補の価値を匿名価値評価システム２０から取得し、この抽象化後の価値に基づいて選択した抽象化候補を匿名情報とし、配信情報管理システム３０を介して他の事業者に提供する。そして、匿名情報配信システム１００は、他の事業者の端末５０から当該匿名情報に対する広告やクーポン等の配信情報を受信して、この配信情報を当該匿名情報に対応する各ユーザ宛てに出力する。

【0031】

即ち、本実施形態１の匿名情報配信システム１００は、医療情報を匿名情報とすることで他の事業者への提供を可能とすると共に、当該匿名情報に基づき特定の属性情報を持つ個人、例えば血圧が高い、介護が必要等といった属性情報を持つ個人をターゲットとした配信情報を他の事業者から受信し、この配信情報と対応する属性情報を持つユーザへ仲介することにより、各個人の匿名性を保ったまま配信情報を配信できる。

【0032】

なお、個人情報を匿名化して配信することの許可は、各ユーザや、匿名情報配信システム１００の管理者、病院情報システム１０の管理者が、配信ポリシーとして設定している。即ち、匿名情報配信システム１００は、配信ポリシーに従って、配信に利用できる個人情報を抽出して匿名化を行っている。このため匿名化後、個人情報や、配信ポリシー、匿名情報の配信に係る状況（配信状況）といった配信に係る情報（以下、単に配信ポリシー等とも称す）が変更されると、変更前の条件で匿名化処理を行った匿名情報は配信ポリシーを満たさなくなる可能性があり、配信に利用できなくなってしまう。

【0033】

例えば、変更前に同じ属性を持つユーザがｋ人以上いた場合でも、配信ポリシー等の変更によって一部の医療情報が利用できなくなったことで、同じ属性を持つユーザがｋ未満となる可能性がある。

【0034】

この場合、配信ポリシー等の変更に応じて「k-匿名性」を満たすように再演算することになるが、多量の医療情報を演算処理するためには相応の時間がかかるため、一般に、このような匿名化の演算処理は、個人情報（医療情報）の新規入力や配信ポリシーの変更等のデータ更新が無い夜間や休日を用いた定期的なバッチ処理で行われる。なお、本実施形態の匿名情報配信システム１００は、一日一回の夜間バッチによって匿名化の演算処理を行っている。配信ポリシー等が変更される毎に、次のバッチ処理が終わる翌日まで匿名情報を提供できないのでは、円滑にサービスを実施できないので、本実施形態の匿名情報配信システム１００では、配信ポリシー等の変更によって利用できなくなった情報をフィルタリングして、配信可能な匿名情報を配信する。

【0035】

病院情報システム１０は、患者の来院時に受け付けを行う受付機１０１や、患者に係る医療情報を入出力する入出力端末１０２、入出力端末１０２から入力された医療情報を管理する病院情報サーバ１０３、ウェブサーバ１０４を有する。

【0036】

受付機１０１は、患者の診察券を読み取る読取装置や、受付番号を記載した受付レシートを印刷出力するプリンタを備える情報処理装置である。

【0037】

入出力端末１０２は、パーソナルコンピュータ等の情報処理装置であり、患者のカルテ（診療記録）等の情報を病院情報サーバ１０３から読み出して表示出力する表示部や、医師の診断結果や検査結果、薬の処方、検査のオーダ等の情報を病院情報サーバ１０３へ入力する入力部を有している。

【0038】

また、入出力端末１０２は、会計の処理を行う端末や、調剤の受け付けを行う端末として用いられても良い。

【0039】

ウェブサーバ１０４は、ネットワークを介して患者等の端末７と接続し、端末７からの要求に応じて病院に関する情報をウェブページで提供する。ウェブサーバ１０４は、病院のウェブサイトとして機能し、例えば患者の端末７に予約の入力フォームを提供し、入力フォームに従って入力されたデータを当該端末７から受信して予約を受け付ける。また、ウェブサーバ１０４は、患者の端末７に配信ポリシーの入力フォームを提供し、入力フォームに従って入力されたデータを当該端末７から受信して配信ポリシーの入力を受け付ける。

【0040】

病院情報サーバ１０３は、医療情報ＤＢ（データベース）１９、匿名情報ＤＢ１８、ポリシーＤＢ６８、フィルタＤＢ６９、データ更新部１５、データ受付部１６、出力制御部１７、ポリシー受付部６１、フィルタ設定部６２等の機能部を備えている。

【0041】

データ受付部１６は、個人と対応付けられた複数の項目を含む対象データを医療情報ＤＢ１９から読み出し（受信し）、匿名情報ＤＢ１８に記憶させる。

【0042】

データ更新部１５は、匿名情報ＤＢ１８に記憶させた対象データ（個人情報）の各項目の値を後述の抽象化候補に基づいて抽象化した値に更新することにより、対象データを匿名情報とする。

【0043】

出力制御部１７は、配信情報管理システム３０から受信した配信情報を患者に対して出力させる。ここで、配信情報の出力とは、表示装置による表示出力や、プリンタによる印刷出力、他の装置への送信、記憶媒体への書き込み等である。例えば、出力制御部１７は、配信情報を受付機１０１に送信し、受付機１０１のプリンタによって受付レシートに配信情報を印刷させる。本実施形態において出力制御部１７は、配信情報を患者（個人）へ配信する配信部の一形態である。

【0044】

これに限らず、患者に対する出力は、受付機１０１のコントロールパネル（不図示）への表示出力や、会計時のレシートや予約票への印刷出力、会計を行う端末（不図示）のディスプレイへの表示出力、当該患者のメールアドレス宛てに電子メールを送信することであっても良い。また、患者への出力とは、当該患者が配信情報を受け取ることができれば、当該患者のみに限定して出力することに限らず、患者を含む不特定の人に対して出力することでも良い。

【0045】

例えば、当該患者が会計を待っている間に待合室に設置したデジタルサイネージに広告を表示出力することや、当該患者が薬局で調剤を依頼した際に、薬局内に広告を音声出力することでも良い。なお、配信情報は、上記出力方法によって出力可能な形式のデータであれば良く、例えば、テキスト、画像、動画、音データ等であっても良い。

【0046】

ポリシー受付部６１は、各ユーザや、病院情報システム１０の管理者（担当者）、匿名情報配信システム１００の管理者（担当者）による配信ポリシーの入力を受け付け、ポリシーＤＢ６８に記憶させる。

【0047】

フィルタ設定部６２は、個人情報、配信ポリシー又は匿名情報の配信状況が変更された場合に、当該変更によって匿名化処理時点の配信ポリシーを満たさなくなった情報をフィルタ条件としてフィルタＤＢ６９に記憶させる。

【0048】

配信制御部６３は、匿名情報ＤＢ１８から読み出した匿名情報のうちフィルタＤＢ６９
に設定されたフィルタ条件に該当する情報を除外して配信可能な匿名化情報を取得する、又は前記フィルタ条件に該当しない匿名情報を匿名情報ＤＢにリクエストして配信可能な匿名情報を取得する。本実施形態において配信制御部６３は、配信情報を患者（個人）へ配信する配信部の一形態である。

【0049】

医療情報ＤＢ１９は、入出力端末１０２によって入力された各患者の医療情報を記憶する。この医療情報は、例えば患者の診察時に入出力端末１０２によって読み出され、電子カルテとして利用される。また、医療情報ＤＢ１９の医療情報は、データ受付部１６によって匿名化の対象データとして読み出される。

【0050】

匿名情報ＤＢ１８は、個人情報（対象データ）が入力され、データ更新部１５により抽象化候補に基づいて対象データの各項目の値が、抽象化した値に書き換えられ、匿名情報として保持する。なお、匿名情報ＤＢ１８は、個人情報のうち、メールアドレスやＦＡＸ番号等の宛先情報を匿名情報と対応付けて保持しておき、出力制御部１７が、配信情報の配信先として読み出せるようにしても良い。

【0051】

また、匿名価値評価システム２０は、抽象化部１１、検定部１３、選択部１４、価値データ取得部２１、価値判定部２２、ワードカテゴリ分析部２３、価値計算部２４、検索情報蓄積ＤＢ２５等の機能部を備えている。

【0052】

抽象化部１１は、対象データを匿名化或いは多様化する際に、対象データ中の項目の値であるワード（語）を抽象化したワードに替えて抽象化候補を生成する。本実施形態においてワード（語）は、単語や句など、一まとまりの言葉であり、位置情報や電話番号等の数値、メールアドレスやＩＰアドレス等の識別情報、言葉と同様の意味を持つ記号等を含んでも良い。

【0053】

検定部１３は、抽象化候補の一個人と対応する項目の値の組み合わせが、当該抽象化候補中で単一でないことを条件として検定する。例えば検定部１３は、抽象化候補がｋ−匿名性を満たしているかを検定する。

【0054】

選択部１４は、前記検定の条件を満たした抽象化候補を匿名価値評価システム２０の価値判定部２２で算出した価値に基づいて抽象化候補を選択する。例えば、選択部１４は、ｋ−匿名性を満たした複数の抽象化候補から価値が高い順に所定数の抽象化候補を選択する。

【0055】

価値データ取得部２１は、抽象化候補に含まれるワードの価値データを検索情報蓄積ＤＢから取得（受信）する。また、価値データ取得部２１は、検索情報蓄積ＤＢ２５に前記ワードの価値データが登録されていない場合に、他の装置例えば検索エンジン４０にリクエストし、取得した価値データを検索情報蓄積ＤＢ２５に登録する機能（データリクエスト）や、定期的に他の装置を巡回して最新の価値データを取得し、検索情報蓄積ＤＢ２５に登録されている価値データを更新する機能（データクローラ）を有する。

【0056】

本実施形態では、この価値データとして検索エンジン４０から各ワードの統計情報を受信する。ここで、各ワードの統計情報は、例えばＳＥＭの広告単価（クリック単価）や、クリック率、平均掲載順位、１日の表示回数、１日のクリック数等である。なお、価値の取得先は、検索エンジンに限らず、ウェブページやＳＮＳ等であっても良い。この場合、例えばウェブページやＳＮＳにおける各ワードの使用頻度を価値としても良い。

【0057】

価値判定部２２は、抽象化候補に含まれるワードの価値に基づいて当該抽象化候補の価値を求める。また、価値判定部２２は、求めた抽象化候補の価値を病院情報サーバ１０３
に通知しても良い。

【0058】

ワードカテゴリ分析部２３は、ウェブサイト等のデータを分析して、新規のワードや、当該ワードを抽象化したワード（カテゴリ）を求め、検索情報蓄積ＤＢに登録する。

【0059】

価値計算部２４は、価値データ取得部２１で取得したワードの価値に基づき、ワードの価値の年平均や月平均、週平均など、ワードの価値の統計情報を求める。

【0060】

検索情報蓄積ＤＢ２５は、価値データ取得部２１で取得したワードの価値や、ワードカテゴリ分析部２３で求めたワードやカテゴリの情報、価値計算部２４で求めた価値の統計情報などを記憶する。

【0061】

また、図２において、配信情報管理システム３０は、匿名データ出力部３１、配信データ受付部（配信情報受付部）３２を備えている。

【0062】

匿名データ出力部３１は、病院情報サーバ１０３の匿名情報ＤＢ１８から匿名情報を読み出して他の事業者の端末５０へ送信する。ここで端末５０への送信は、各端末５０のアドレス宛てに電子メール等を送信するものでも良いし、匿名情報をウェブページとして提供するものでも良い。

【0063】

例えば、他の事業者が要求する情報の条件（以下、要求条件とも称す）を端末５０から受信した場合に、匿名データ出力部３１が、この要求条件と適合した匿名情報を匿名情報ＤＢ１８から読み出す。このとき匿名データ出力部３１は、匿名情報記憶部から読み出した匿名情報のうち前記フィルタ条件に該当する情報を除外して配信可能な匿名化情報を取得する、又は前記フィルタ条件に該当しない匿名情報を前記匿名情報記憶部にリクエストして配信可能な匿名情報を取得する。そして匿名データ出力部３１は、匿名情報を要求元の端末５０に電子メール等で送信する。

【0064】

また、匿名データ出力部３１は、端末５０からの閲覧要求に対して、匿名情報が記載されたウェブページ、即ちＨＴＭＬ等で記述されたファイルをレスポンスとして返信するものでも良い。このように匿名データ出力部３１は、本実施形態において、匿名情報を配信する配信部の一形態である。

【0065】

配信データ受付部３２は、他の事業者の端末５０から前記匿名情報の特定の属性値に対する配信情報を受信し、この配信情報を病院情報サーバ１０３に送信する。

【0066】

また、図２中、検索エンジン４０は、インターネット等のネットワーク上に存在する情報の検索機能を提供するサイト（コンピュータ）である。即ち、検索エンジン４０は、ユーザ端末から検索するキーワードを受信すると、このキーワードを含むウェブページのＵＲＬ等のリストを検索結果として提供し、ユーザ端末に表示させる。

【0067】

また、検索エンジン４０は、この検索機能を利用し、検索結果にキーワードと連動した広告を表示させることや、キーワードに応じた広告料を支払ったスポンサーサイトへのリンクを表示させることも行う。このため、検索エンジン４０は、検索されたワード毎に、１日の検索回数（表示回数）、検索結果の広告がクリックされた回数（クリック数）、１クリック当たりの広告料（クリック単価）等をワードの統計情報として記憶する。

【0068】

また、これらの情報に基づき、検索エンジン４０は、表示回数をクリック数で除したクリック率や、１日のクリック数にクリック単価を乗じた値（１日の費用）、広告の申し込み時（広告オークション時）に提示した費用に応じた広告の掲載順位等も求める。

【0069】

検索エンジン４０は、匿名価値評価システム２０に対し、上記クリック数、表示回数、掲載順位、１日の費用、クリック率、クリック単価等の情報を提供するデータ出力部４１や、これらワードに関する情報を記憶する検索ワード蓄積ＤＢ４２を備える。

【0070】

図３は病院情報サーバ１０３のハードウェア構成を示す図である。病院情報サーバ１０３は、演算処理部１、通信制御部３、記憶装置４、入出力インタフェース５を有する所謂情報処理装置（コンピュータ）である。

【0071】

演算処理部１は、ＣＰＵやメインメモリを有し、ＣＰＵが、メインメモリに実行可能に展開されたプログラムを実行することで、前述の抽象化部１１、検定部１３、選択部１４、データ更新部１５、データ受付部１６、出力制御部１７、ポリシー受付部６１、フィルタ設定部６２の機能を提供する。

【0072】

メインメモリは、主記憶装置ということもできる。メインメモリは、例えば、ＣＰＵが実行するプログラムや、通信制御部３を介して受信したデータ、記憶装置４から読み出したデータ、その他のデータ等を記憶する。

【0073】

通信制御部３は、ネットワークを介して他の装置、例えば受付機１０１や入出力端末１０２と接続し、当該装置との通信を制御する。

【0074】

入出力インタフェース５は、表示装置やプリンタ等の出力手段や、キーボードやポインティングデバイス等の入力手段、ドライブ装置等の入出力手段が適宜接続される。ドライブ装置は、着脱可能な記憶媒体の読み書き装置であり、例えば、フラッシュメモリカードの入出力装置、ＵＳＢメモリを接続するＵＳＢのアダプタ等である。また、着脱可能な記憶媒体は、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ブルーレイディスク（Blu-ray（登録商標） Disc）等のディスク媒体であってもよい。ドライブ装置は、着脱可能な記憶媒体からプログラムを読み出し、記憶装置４に格納させる。

【0075】

記憶装置４は、外部記憶装置（補助記憶装置）ということもできる。記憶装置４としては、ＳＳＤ（Solid State Drive）やＨＤＤ等であってもよい。記憶装置４は、ドライブ
装置との間で、データを授受する。例えば、記憶装置４は、ドライブ装置からインストールされる情報処理プログラム等を記憶する。また、記憶装置４は、プログラムやデータが演算処理部１により読み出されて、メインメモリに引き渡す。本実施形態では、記憶装置４が前述の医療情報ＤＢ１９や匿名情報ＤＢ１８、ポリシーＤＢ６８、フィルタＤＢ６９を格納している。

【0076】

なお、受付機１０１、入出力端末１０２についても基本的なハードウェア構成は、図３と同様であり、受付機１０１、入出力端末１０２は、演算処理部、通信制御部、記憶装置、入出力インタフェースを有する情報処理装置である。例えば、受付機１０１は、入出力インタフェースに診察券の読取装置が接続され、演算処理部が読取装置を制御して診察券から患者の識別情報（患者ＩＤ）を読み取り、通信制御部を介して病院情報サーバ１０３へ送信する。また、受付機１０１は、入出力インタフェースにプリンタが接続され、受付番号と配信情報を印刷したレシートを出力する。

【0077】

入出力端末１０２は、演算処理部が通信制御部を介して病院情報サーバ１０３から患者の医療情報を読み出して表示装置に表示させると共に、医師がキーボードやマウスを操作して診察の結果を入力し、通信制御部を介して病院情報サーバ１０３へ送信して医療情報ＤＢ１９に記憶させる。

【0078】

図４は医療情報ＤＢ１９の一例を示す図である。図４の医療情報ＤＢ１９は、医療情報として、患者毎に、患者ＩＤ、氏名、年齢、性別、住所、メールアドレス、診療履歴の項目を夫々対応付けて記憶している。

【0079】

患者ＩＤは、患者を一意に識別する情報であり、例えば診察件番号や保険証の番号などである。

【0080】

メールアドレスは、配信情報の配信先となる患者の連絡先を示す情報であり、電話番号やＦＡＸ番号などでも良い。

【0081】

診療履歴は、過去の診療の内容を診療日と共に記録した履歴情報であり、図４では直近の３回分の診療内容を示している。なお、診療履歴は、全ての履歴が記録されたものでも良いし、一部の履歴(例えば所定期間の履歴)を抽出したものでも良い。また、診療の内容は、傷病の名称、傷病の部位、受診した科（内科・外科等）、検査結果、処方された薬の名称などを含んでも良い。

【0082】

図５，図６はポリシーＤＢ６８に記憶される配信ポリシーの例を示す図である。図５の配信ポリシーは、匿名情報の属性値毎の配信の可否を示す。図５の配信ポリシーは、例えば、性別、年齢、住所、診療履歴等の属性値毎に、配信を許可する場合には○、配信を拒否する場合には×といった配信可否が記録される。

【0083】

図６の配信ポリシーは、配信情報毎の配信の可否を示す。図６の配信ポリシーは、例えば、タクシー、医療機器、マッサージ、宗教、クーポン、広告といった配信情報の内容毎に、配信を許可する場合には○、配信を拒否する場合には×といった配信可否が記録される。

【0084】

なお、図５，図６の配信ポリシーは、各患者が自身のポリシーとして設定する患者側ポリシーと、病院情報システム１０又は匿名情報配信システム１００全体のポリシー、即ち全患者に適用するポリシーとして病院情報システム１０又は匿名情報配信システム１００の管理者が設定するシステム側ポリシーがある。

【0085】

図７は匿名情報ＤＢ１８の一例を示す図であり、図７（Ａ）は対象データを書き込んだ直後の例を示す図、図７（Ｂ）は匿名情報の例を示す図、図７（Ｃ）は各患者と匿名情報との対応関係を示す図である。図７（Ｂ）に示すように匿名情報ＤＢ１８では、匿名情報として、属性ＩＤや、属性種類、存在数、許可配信情報を対応付けて記憶している。ここで、属性種類（匿名情報種類）は、匿名性を満たすように抽象化したワードの組み合わせである。属性ＩＤは、属性種類毎に割り当てる識別情報である。存在数は、対応する属性種類を持つユーザの人数を示す情報である。許可配信情報は、配信を許可している配信情報を示す情報である。

【0086】

図７（Ｃ）は、患者ＩＤや、メールアドレス（連絡先）、属性種類を対応付けて記憶している。

【0087】

図８は、フィルタＤＢ６９に記憶されるフィルタ条件の例を示す図である。図８に示すように、フィルタＤＢ６９は、フィルタ条件として被変更者や属性種類の項目を夫々対応付けて記憶している。被変更者は、変更となった患者を示す情報であり、特定の患者の配信ポリシー等が変更となった場合には、当該患者の患者ＩＤが記憶され、システム側配信ポリシーが変更となった場合には、全ての患者であることが記憶される。

【0088】

フィルタＤＢ６９の属性種類は、配信ポリシー等の変更により配信できなくなった属性
種類を示す情報である。

【0089】

図９は匿名価値評価システム２０の概略構成図である。匿名価値評価システム２０は、演算処理部２０１、通信制御部２０３、記憶装置２０４、入出力インタフェース２０５を有する所謂情報処理装置（コンピュータ）である。

【0090】

演算処理部２０１は、ＣＰＵやメインメモリを有し、ＣＰＵが、メインメモリに実行可能に展開されたプログラムを実行することで、前述の抽象化部１１、検定部１３、選択部１４、価値データ取得部２１、価値判定部２２、ワードカテゴリ分析部２３、価値計算部２４の機能を提供する。

【0091】

メインメモリは、主記憶装置ということもできる。メインメモリは、例えば、ＣＰＵが実行するプログラムや、通信制御部２０３を介して受信したデータ、記憶装置２０４から読み出したデータ、その他のデータ等を記憶する。

【0092】

通信制御部２０３は、ネットワークを介して他の装置、例えば病院情報サーバ１０３と接続し、当該装置との通信を制御する。

【0093】

入出力インタフェース２０５は、表示装置やプリンタ等の出力手段や、キーボードやポインティングデバイス等の入力手段、ドライブ装置等の入出力手段が適宜接続される。

【0094】

記憶装置２０４は、外部記憶装置（補助記憶装置）ということもできる。記憶装置２０４としては、ＳＳＤ（Solid State Drive）やＨＤＤ等であってもよい。記憶装置２０４
は、ドライブ装置との間で、データを授受する。例えば、記憶装置２０４は、ドライブ装置からインストールされる情報処理プログラム等を記憶する。また、記憶装置４は、プログラムを読み出し、メモリに引き渡す。本実施形態では、記憶装置２０４が前述の検索情報蓄積ＤＢ２５を格納している。

【0095】

図１０は、検索情報蓄積ＤＢ２５の一例を示す図である。検索情報蓄積ＤＢ２５は、検索エンジン４０から取得したワードとその価格（単価）を対応付けて価値データとして記憶している。この各ワードの価値データに基づいて、各抽象化候補の価値を求め、
次に図１１−図１８を用いて本実施形態におけるデータの価値について説明する。図１１は対象データにおける年齢の項目の一部の例を示す図である。図１１に示すように対象データは、年齢ｓｉ毎に人数ｃｉを有している。例えば、１８歳（ｓ１）の人数（ｃ１）が３０人、１９歳（ｓ２）の人数（ｃ２）が１０人である。

【0096】

図１２は、年齢ｓｉについて検索情報蓄積ＤＢ２５から取得する価値データの一例を示す。図１２の価値データは、年齢ｓｉ毎にＳＥＭ単価ｅｉを有している。図１２の例では、ワードの価値として、検索エンジン４０が広告費等の基準として提供しているＳＥＭ単価ｅｉを用いている。

【0097】

この年齢ｓｉの価値は、ＳＥＭ単価ｅｉに人数ｃｉを乗じた値であり、式１で示される。
ｓｉ＝ｃｉ×ｅｉ ・・・（式１）
そして、図１３に示すように年齢の項目Ｓ（ｅ）の価値は、各年齢ｓｉの総計であり、式２で示される。なお、図１３においてｎは５である。従って、年齢の項目Ｓ（ｅ）の価値は、図１４に示すように、２４４６円である。また、対象データにおける全ての項目の価値を合計したものが対象データの価値である。

【0098】

一方、図１５は抽象化候補における年齢の項目の一部の例を示す図である。図１５に示
すように抽象化候補は、年代ｋｉ毎に人数ｃｉを有している。例えば、１０代（ｋ１）の人数（ｃ１）が４０人、２０代（ｋ２）の人数（ｃ２）が２２人である。

【0099】

図１６は、年代ｋｉについて取得する各ワードの価値データの一例を示す。図１６の価値データは、年代ｋｉ毎にＳＥＭ単価ｅｉを有している。

【0100】

この年代ｋｉの価値は、ＳＥＭ単価ｅｉに人数ｃｉを乗じた値であり、式３で示される。
ｋｉ＝ｃｉ×ｅｉ ・・・（式３）
そして、図１７に示すように年代の項目Ｓ（ｋ）の価値は、各年代ｋｉの総計であり、式４で示される。なお、図１７においてｎは２である。従って、年代の項目Ｓ（ｋ）の価値は、図１８に示すように、２１３４円である。即ち、年齢の項目を年代に抽象化したことにより、価値が３１２円減損したことになる。また、抽象化候補における全ての項目の価値を合計したものが抽象化候補の価値である。

【0101】

そして、ステップＳ１５０で求める抽象化候補の価値として、例えば式５に示すように、抽象化候補の価値を抽象化候補の価値と対象データの価値の合計で除した減損率Ｍ（ｋ）を求める。

【0102】

Ｍ（ｋ）＝Ｓ（ｋ）／（Ｓ（ｋ）＋Ｓ（ｅ）） ・・・（式５）
図１９は配信情報管理システム３０の概略構成図である。配信情報管理システム３０は、演算処理部３０１、通信制御部３０３、記憶装置３０４、入出力インタフェース３０５を有する所謂情報処理装置（コンピュータ）である。

【0103】

演算処理部３０１は、ＣＰＵやメインメモリを有し、ＣＰＵが、メインメモリに実行可能に展開されたプログラムを実行することで、前述の匿名データ出力部３１及び配信データ受付部３２の機能を提供する。

【0104】

メインメモリは、主記憶装置ということもできる。メインメモリは、例えば、ＣＰＵが実行するプログラムや、通信制御部３０３を介して受信したデータ、記憶装置２０４から読み出したデータ、その他のデータ等を記憶する。

【0105】

通信制御部３０３は、ネットワークを介して他の装置、例えば病院情報サーバ１０３や他の事業者の端末５０と接続し、当該装置との通信を制御する。

【0106】

入出力インタフェース３０５は、表示装置やプリンタ等の出力手段や、キーボードやポインティングデバイス等の入力手段、ドライブ装置等の入出力手段が適宜接続される。

【0107】

記憶装置３０４は、外部記憶装置（補助記憶装置）ということもできる。記憶装置３０４としては、ＳＳＤ（Solid State Drive）やＨＤＤ等であってもよい。記憶装置３０４
は、ドライブ装置との間で、データを授受する。例えば、記憶装置３０４は、ドライブ装置からインストールされる情報処理プログラム等を記憶する。

【0108】

図２０は、配信情報管理システム３０が、他の事業者の端末５０から受信する要求情報の一例を示す図である。図２０の要求情報は、事業者名、アドレス、適合条件、単価を夫々対応付けて記憶している。

【0109】

事業者名は、事業者を識別する情報であり、名称に限らずＩＤ等であっても良い。

【0110】

アドレスは、匿名情報の送信先を示す情報であり、メールアドレスの他、ＩＰアドレス
、ＦＡＸ番号など、送信先を特定できる情報であれば良い。

【0111】

適合条件は、配信情報をリコメンドする匿名情報の属性の条件であり、図２０の例では傷病名やその部位等を示すワードである。

【0112】

単価は、配信情報を患者へ配信した場合に事業者から匿名情報配信システム１００側に支払われる１件あたりの価格(対価)である。

【0113】

配信情報の概要は、配信情報の対象や種別などを示す情報である。図２０の例では、タクシーや血圧計、食事指導、宗教等を対象とし、クーポンや広告、情報提供等の種別を示す。

【0114】

上記のように本実施形態１では、病院情報システム１０、匿名価値評価システム２０、配信情報管理システム３０を別の情報処理装置で構成したが、これら病院情報システム１０、匿名価値評価システム２０、配信情報管理システム３０を一つの情報処理装置で構成しても良い。

【0115】

図２１は、匿名情報配信システム１００による匿名化処理の説明図である。病院情報サーバ１０３は、夜間のバッチ処理など、所定のタイミングでプログラムを起動し、図２１の処理を開始する。

【0116】

病院情報サーバ１０３は、先ずポリシーＤＢ６８を参照し、配信情報の配信への利用が許可された対象データを病院医療情報ＤＢ１９から読み出す（ステップＳ１０）。即ち、ＣＰＵが記憶装置４から対象データを取得する。なお、病院情報サーバ１０３は、対象データを内部の記憶装置４から読み出す構成に限らず、外部のファイルサーバ等から対象データを受信する構成であっても良い。対象データは、１日、１カ月、１年など、所定期間内の医療情報を抽出したものでも良いし、内科、外科、循環器科など、所定の属性値を持つデータを抽出したものでも良い。

【0117】

次に病院情報サーバ１０３は、読み出した対象データの表記の揺れや各項目のデータ長、順序などが所定形式となるよう正規化して、匿名情報ＤＢ１８に登録し、匿名価値評価システム２０に通知する（ステップＳ２０）。

【0118】

匿名価値評価システム２０は、匿名情報ＤＢ１８から対象データを読み出し（ステップＳ３０）、対象データ中の各ワードについて、価値データが検索情報蓄積ＤＢ２５に存在するか否かを判定する（ステップＳ４０）。匿名価値評価システム２０は、全てのワードの価値データが検索情報蓄積ＤＢ２５に存在する場合にはステップＳ６０へ移行し（ステップＳ４０，Ｙｅｓ）、足りない価値データがある場合（ステップＳ４０，Ｎｏ）、当該ワードの価値データを外部の装置、本例では検索エンジン４０から取得する（ステップＳ５０）。なお、検索エンジンから取得した価値データ以外、即ち検索情報蓄積ＤＢ２５に存在したワードの価値情報は、検索情報蓄積ＤＢ２５から取得する（ステップＳ６０）。

【0119】

また、匿名価値評価システム２０は、匿名性を満たすため対象データの各項目を抽象化したワード（カテゴリ）に置き換えて抽象化候補を作成する（ステップＳ７０）。なお、抽象化可能な項目が複数存在する場合には、各項目を抽象化した場合と抽象化しない場合の全てのパターンを作成する。例えば対象データに三つの項目Ａ，Ｂ，Ｃが含まれ、全項目について抽象化が可能で、抽象化した項目をＡ´，Ｂ´，Ｃ´とした場合、図２２に示すように、項目Ａだけを抽象化した場合Ａ´，Ｂ，Ｃ、項目Ａ，Ｂを抽象化した場合Ａ´，Ｂ´，Ｃなど、七つの候補パターンが作成できる。また、全項目を用いるものに限らず、Ａ´，ＢやＢ´，Ｃなど、一部の項目を用いた候補パターンを作成しても良い。

【0120】

次に匿名価値評価システム２０は、抽象化候補に含まれる各ワードの価値データに基づいて各パターンの抽象化候補の価値を算出し（ステップＳ８０）、この抽象化候補の価値に基づいて検定の順番を決定する（ステップＳ９０）。例えばこの価値が高い順（降順）に検定の順番を決定する。なお、全ての候補パターンについて検定を行うことが望ましいが、この抽象化候補の価値に基づき、価値の低過ぎる抽象化候補を順番から外しても良い。例えば、価値の高い順番で、所定番目以降或いは半分未満など所定割合未満の抽象化候補を外しても良い。また、抽象化候補の価値が対象データの価値に対して所定割合未満となった抽象化候補を外しても良い。これにより検定数が少なくなり、処理時間の短縮化が図れる。

【0121】

この検定の順番に従い、匿名価値評価システム２０は、抽象化候補の匿名性を検定する（ステップＳ１００）。例えば、ｋ−匿名性を検定するため、一個人と対応付けられた異なる項目の値の組み合わせが当該抽象化候補中に存在する数（存在数）を求める。或いは、ｌ多様性を検定するため、一個人と対応付けられた同じ項目の値の組み合わせが当該抽象化候補中に存在する数（存在数）を求める。そして、この存在数のうち最小のものを最低出現数（ｋ値）として求め（ステップＳ１１０）、この最低出現数が１を超えているか否かを判定する（ステップＳ１２０）。即ち、ここでｋ値が１を超えていればｋ−匿名性を満たし、１であればｋ−匿名性を満たさない。同様にｌ値が１を超えていればｌ−多様性を満たし、１であればｌ−多様性を満たさない。

【0122】

最低出現数（ｋ値／ｌ値）が１を超えていない場合（ステップＳ１２０，Ｎｏ）、匿名価値評価システム２０は、抽象化候補のうち、少なくとも一つの項目の値を更に抽象化する、即ち抽象化したワードに置き換え（ステップＳ１３０）、ステップＳ１００に戻る。例えば、「足骨折、１５歳、男」という属性値を持つ患者が一人であった場合、「足傷病、１５歳、男」のように抽象化する。

【0123】

一方、最低出現数（ｋ値／ｌ値）が１を超えている場合（ステップＳ１２０，Ｙｅｓ）、匿名価値評価システム２０は、当該抽象化候補の価値と元の対象データの価値との差分を求め（ステップＳ１４０）、この差分や、この差分に基づく値、例えば対象データの価値に対する差分の割合、対象データの価値に対する抽象化候補の価値の割合を当該抽象化候補の価値として決定する（ステップＳ１５０）。

【0124】

また、匿名価値評価システム２０は、検定していない候補パターンがあるか否かを判定し（ステップＳ１６０）、検定していない候補パターンがあれば（ステップＳ１６０，Ｙｅｓ）、ステップＳ９０で決定した順番に従って、次の順番の抽象化候補を特定し（ステップＳ１７０）、ステップＳ１００に戻って次の抽象化候補について検定を行う。

【0125】

このように各パターンの抽象化候補について検定を繰り返し、次の候補パターンが無くなった場合（ステップＳ１６０，Ｎｏ）、匿名価値評価システム２０は、ステップＳ１５０で求各抽象化候補の価値に基づいて、採用すべき抽象化候補を選択し、病院情報サーバ１０３に通知する（ステップＳ１８０）。

【0126】

抽象化候補の選択は、例えば、全候補パターンの中で価値の高い順に所定数の抽象化候補を選択する。即ち、匿名化情報は、１パターンに限らず、複数パターン作成しても良い。

【0127】

また、匿名価値評価システム２０は、配信情報管理システム３０から、要求情報を取得し、要求情報と合致する候補パターンの中で価値の高い順に所定数の抽象化候補を選択しても良い。更に、匿名価値評価システム２０は、全候補パターンの中から価値の高い順に
複数の抽象化候補を出力し、この出力された抽象化候補の中から操作者が適切だと思う抽象化候補を指定し、この指定された抽象化候補を選択しても良い。

【0128】

病院情報サーバ１０３は、選択された抽象化候補を匿名情報として匿名情報ＤＢ１８に記憶させ、匿名情報ＤＢ１８を更新する（ステップＳ１９０）。なお、本実施形態では、図７（Ｂ）のように匿名情報が、属性種類毎に、その存在数や許可配信情報と対応付けて記憶される。

【0129】

図２３は、配信ポリシー等の変更を受け付けた場合にフィルタ条件を設定する処理の説明図である。

【0130】

病院情報サーバ１０３は、患者や、病院情報システム１０の管理者、他の事業者から配信ポリシー等の入力を受けると図２３の処理を開始し、先ず、配信ポリシー等を受け付ける(ステップＳ２１０)。例えば、患者が端末７を操作してウェブサーバ１０４に接続し、患者ＩＤやパスワード等の認証情報を入力して病院のウェブサイトにログインし、配信ポリシーの設定を選択すると、ウェブサーバ１０４が患者側配信ポリシーの入力フォームを端末７へ送信する。端末７が入力フォームを表示し、患者が図５，図６に示すように属性や配信情報毎に配信可否を入力してウェブサーバ１０４に送信すると、ウェブサーバ１０４が病院情報サーバ１０３へ送り、ポリシー受付部６１が受け付けてポリシーＤＢ６８に記憶させる。

【0131】

また、病院情報システム１０の管理者が、入出力端末１０２からシステム側配信ポリシーを入力し、病院情報サーバ１０３へ送り、ポリシー受付部６１が受け付けてポリシーＤＢ６８に記憶させる。

【0132】

更に病院の医師や検査担当者が、入出力端末１０２から診療内容や検査結果等の診療履歴を入力した場合や、病院情報システム１０の管理者が、入出力端末１０２から患者の住所や生活習慣等を入力した場合、入出力端末１０２が、これら診療履歴や住所、生活習慣等の医療情報を病院情報サーバ１０３へ送り、ポリシー受付部６１が受け付けてポリシーＤＢ６８に記憶させる。

【0133】

また、他の事業者の端末５０から、要求情報が配信情報管理システム３０に送られた場合に、配信情報管理システム３０が、この配信情報の対象や種別、事業者名等の情報を配信状況（匿名情報の利用目的を示す情報）として病院情報サーバ１０３へ送り、ポリシー受付部６１が受け付けてポリシーＤＢ６８に記憶させる。

【0134】

次にフィルタ設定部６２が、ステップＳ２１０で受け付けた配信ポリシー等と、前回の匿名化処理時点の配信ポリシー等とを比較して配信ポリシー等の変更箇所を求める（ステップＳ２２０）。

【0135】

また、フィルタ設定部６２は、ステップＳ２２０で求めた配信ポリシーの変更によって匿名化処理時点の配信ポリシーを満たさなくなった情報をフィルタ条件としてフィルタＤＢ６９に記憶させる（ステップＳ２３０）。

【0136】

例えば、フィルタ設定部６２は、患者ＩＤ＝１０１００１の配信ポリシーのうち、年齢の項目（属性値）が許可から拒否に変更された場合、図７（Ｃ）の対応データから患者ＩＤと対応する属性ＩＤを求め、この属性ＩＤと対応する属性種類のうち、変更された属性値（本例では年齢）を含む属性種類を図７（Ｂ）に示す匿名情報から抽出する。フィルタ設定部６２は、この抽出した属性種類の属性ＩＤと患者ＩＤとを対応付けてフィルタ条件とし、フィルタＤＢ６９に登録する。

【0137】

また、フィルタ設定部６２は、システム側配信ポリシーのうち、住所の項目が許可から拒否に変更された場合、変更された属性値（本例では住所）を含む属性種類を図７（Ｂ）に示す匿名情報から抽出する。フィルタ設定部６２は、この抽出した属性種類の属性ＩＤと被変更者が全患者であることを対応付けてフィルタ条件とし、フィルタＤＢ６９に登録する。

【0138】

なお、変更された属性値を含む属性種類を抽出する場合、変更された属性値（ワード）と一致する属性値に限らず、抽象化した属性値（ワード）が含まれている場合にも抽出する。例えば、変更された属性値が年齢の場合、１５歳、４５歳のような年齢に限らず、１０代、２０代、若年、中年、未成年、成年、幼児、中人、大人など、年齢を抽象化したワードが含まれている属性種類を抽出しても良い。

【0139】

更に、配信状況として医療機器や食事指導について許可する配信ポリシーに基づいて匿名化を行った場合に、配信状況の異なる要求情報を受信した場合、例えば配信情報の対象が「宗教」である要求を受けた場合、フィルタ設定部６２は、先ずポリシーＤＢ６８から「宗教」について配信を拒否している患者ＩＤを抽出する。そしてフィルタ設定部６２は、図７（Ｃ）の対応データから抽出した患者ＩＤと対応する属性ＩＤを求め、この属性ＩＤと患者ＩＤとを対応付けてフィルタ条件とし、フィルタＤＢ６９に登録する。

【0140】

図２４は、匿名情報を他の事業者へ配信する処理の説明図である。配信情報管理システム３０は、他の事業者の端末５０から要求情報を受信した場合、この要求情報を記憶部３０４に記憶すると共に、配信状況として病院情報サーバ１０３へ送信する（ステップＳ３１０）。

【0141】

次に配信情報管理システム３０は、ステップＳ３１０で受信した要求情報に適合する匿名情報を匿名情報ＤＢ１８から読み出す（ステップＳ３２０）。ここで匿名情報と要求情報との適合は、足の傷病、高血圧など匿名情報が有する属性値と要求情報の条件に含まれるワードが一致した場合に適合としても良い。また、匿名情報が有する属性値と要求情報の条件に含まれるワードが完全に一致した場合に限らず、部分的に一致した場合や、シソーラス等を参照して、匿名情報の属性値と要求情報のワードが、上位/下位関係、部分/全体関係、同義関係、類義関係などの所定の関係にある語であった場合に適合と判定しても良い。

【0142】

また、配信情報管理システム３０は、病院情報サーバ１０３のフィルタＤＢ６９からフィルタ条件を取得する（ステップＳ３３０）。

【0143】

そして、配信情報管理システム３０は、ステップＳ３２０で読み出した匿名情報から、フィルタ条件に該当する情報を除外する（ステップＳ３４０）。

【0144】

ステップＳ３４０の除外後、匿名情報の属性種類毎の存在数が所定数（ｋ）以上か否かを判定する（ステップＳ３５０）。ここで、存在数が所定値未満であった場合（ステップＳ３５０，Ｎｏ）、即ちｋ匿名性を満たさなくなった場合、当該匿名情報の属性種類を除外する（ステップＳ３６０）。

【0145】

このフィルタリング後、配信情報管理システム３０は、配信可能な匿名情報があるか否かを判定し（ステップＳ３７０）、配信可能な匿名情報が無ければ（ステップＳ３７０，Ｎｏ）、処理を終了し、配信可能な匿名情報があれば（ステップＳ３７０，Ｙｅｓ）、この配信可能な匿名情報を要求元の端末５０へ配信する（ステップＳ３８０）。

【0146】

なお、図２４の例では、匿名情報を読み出した後、フィルタ条件に該当する情報を除去して配信可能な匿名情報を得る例を示したが、これに限らず、図２５に示すようにフィルタ条件を取得し（ステップＳ３２５）、このフィルタ条件に該当しない匿名情報を匿名情報ＤＢから取得する（ステップＳ３３５）処理としても良い。なお、図２５の処理において、この他のステップは、図２４の処理と同じである。

【0147】

他の事業者は、配信された匿名情報に基づいて、広告などの配信対象とする属性値を指定して配信情報を配信情報管理システム３０へ送信する。ここで配信情報は、配信対象を示す属性値と、患者に対して出力する広告やクーポン等の配信内容とを有している。例えば、属性値が「足傷病」、配信内容が「タクシークーポン」である配信情報を端末５０が送信し、この配信情報を配信情報管理システム３０が受信する。

【0148】

配信情報管理システム３０は、受信した配信情報、即ち配信対象の属性値と配信内容を記憶部３０４に記憶すると共に、病院情報サーバ１０３に送信する。

【0149】

図２６は、匿名情報配信システム１００が患者（ユーザ）に対して配信情報を出力する処理の説明図である。

【0150】

病院情報サーバ１０３は、各患者の来院時等の所定のタイミングで図２６の処理を開始し、まず、配信情報を出力する患者の患者ＩＤを取得する（ステップＳ４１０）。

【0151】

例えば、患者が診察券を受付機１０１に読み取らせて受付を行った場合に、受付機１０１が読み取った患者ＩＤ（診察券番号）を病院情報サーバ１０３に送信することで、病院情報サーバ１０３が患者ＩＤを取得する。

【0152】

また、患者が端末７を操作し、ウェブサーバ１０４に接続し、患者ＩＤやパスワードを入力して病院のウェブサイトにログインした場合に、ウェブサーバ１０４がこの患者ＩＤを病院情報サーバ１０３に送信することで、病院情報サーバ１０３が患者ＩＤを取得する。

【0153】

病院情報サーバ１０３は、匿名情報ＤＢ１８を参照し、ステップＳ４１０で取得した患者ＩＤに対する属性ＩＤを図７（Ｃ）のデータから求める（ステップＳ４２０）。

【0154】

また、病院情報サーバ１０３は、ステップＳ４１０で求めた属性ＩＤに対応する匿名情報の属性種類を図７（Ｂ）のデータから求め、当該属性種類に適合する配信情報を配信情報管理システム３０から取得する（ステップＳ４３０）。例えば、属性種類に含まれる属性値を有する配信情報を取得する。ここで属性種類と配信情報との適合は、足の傷病、高血圧など配信情報が有する属性値と属性種類に含まれるワードが一致した場合に適合としても良い。また、配信情報が有する属性値と属性種類に含まれるワードが完全に一致した場合に限らず、部分的に一致した場合や、シソーラス等を参照して、匿名情報の属性値と要求情報のワードが、上位/下位関係、部分/全体関係、同義関係、類義関係などの所定の関係にある語であった場合に適合と判定しても良い。

【0155】

次に病院情報サーバ１０３は、フィルタＤＢ６９からフィルタ条件を取得する（ステップＳ４４０）。

【0156】

そして、病院情報サーバ１０３は、ステップＳ４４０で読み出した属性種類から、フィルタ条件に該当する情報を除外する（ステップＳ４５０）。

【0157】

ステップＳ４５０の除外後、匿名情報の属性種類毎の存在数が所定数（ｋ）以上か否か
を判定する（ステップＳ４６０）。ここで、存在数が所定値未満であった場合（ステップＳ４６０，Ｎｏ）、即ちｋ匿名性を満たさなくなった場合、当該匿名情報の属性種類を除外する（ステップＳ４７０）。

【0158】

このフィルタリング後、病院情報サーバ１０３は、配信可能な情報があるか否かを判定し（ステップＳ４８０）、配信可能な情報が無ければ（ステップＳ４８０，Ｎｏ）、処理を終了し、配信可能な匿名情報があれば（ステップＳ４８０，Ｙｅｓ）、この配信可能な匿名情報に対する配信情報の配信内容を前記患者が操作している受付機１０１や端末７などの装置へ配信する、即ち配信内容を患者に対して出力する（ステップＳ４９０）。

【0159】

例えば、病院情報サーバ１０３の出力制御部１７は、配信内容を受付機１０１へ送信し、当該患者の受付シートに配信内容を印刷させる。また、ウェブサーバ１０４は、配信内容をウェブページ内のバナー等として端末７へ送信して表示させる。

【0160】

更に、患者に対する出力は、これに限らず、会計用の入出力端末で診察券番号を読み取り会計処理を行う際に、入出力端末１０２から病院情報サーバ１０３へ診察券番号を送信し、病院情報サーバ１０３の出力制御部１７が、受信した診察券番号（患者ＩＤ）と対応する配信内容を入出力端末１０２へ返信し、入出力端末１０２の表示装置に会計金額と共に配信情報を表示して当該患者に提示しても良い。

【0161】

また、患者に対する出力は、会計用の入出力端末１０２で診察券番号を読み取って会計処理を行う際に、会計の待合室に設置したデジタルサイネージに配信内容を出力し、当該患者を含む不特定の人に対して配信情報を出力することでも良い。
《具体例１》
図２７は、患者側配信ポリシーを変更した例を示す図である。図２７の表８Ａが変更前の配信ポリシーを示し、表８Ｂが変更後の配信ポリシーを示す。本例では、表８Ａ，８Ｂに示されるように、住所の項目が許可から拒否に変更されている。

【0162】

このため、当該患者と対応付けられた匿名情報の属性種類のうち、住所を含むものを除外するようにフィルタ条件をフィルタＤＢ６９に設定する。

【0163】

なお、当該患者と対応付けられた匿名情報を表８Ｃに示した。

【0164】

表８Ｃの匿名情報のうち、属性ＩＤ＝１の属性種類は、住所を含まないため、フィルタリングされない。

【0165】

属性ＩＤ＝２の属性種類は、住所＝新宿区を含むため、存在数から当該患者一人分を減算（除外）する。この結果、存在数が所定値（例えばｋ＝２）を下回り、匿名性が保たれなくなったので、この属性ＩＤ＝２の匿名情報は、配信されない。

【0166】

一方、属性ＩＤ＝３，４の属性種類は、住所＝東京都，関東を含むため、存在数から当該患者一人分を減算（除外）するが、存在数が所定値（例えばｋ＝２）を下回らないため、この属性ＩＤ＝３，４の匿名情報は、配信に利用可能である。
《具体例２》
図２８は、システム側配信ポリシーを変更した例を示す図である。図２８の表８Ｄが変更前のシステム側配信ポリシーを示し、表８Ｅが変更後のシステム側配信ポリシーを示す。本例では、表８Ｄ，８Ｅに示されるように、住所の項目が許可から拒否に変更されている。このため、住所の項目を含む匿名情報は、全て除外するようにフィルタ条件をフィルタＤＢ６９に設定する。

【0167】

表８Ｃの匿名情報のうち、属性ＩＤ＝１の属性種類は、住所を含まないため配信可能である。

【0168】

一方、属性ＩＤ＝２〜４の属性種類は、住所＝新宿区，東京都，関東を含むため、フィルタリングされ、配信に利用されない。
《具体例３》
図２９は、配信情報の対象に係るシステム側配信ポリシーを変更した例を示す図である。図２９の表８Ｆが変更前のシステム側配信ポリシーを示し、表８Ｇが変更後のシステム側配信ポリシーを示す。本例では、表８Ｆ，８Ｇに示されるように、宗教の項目が許可から拒否に変更されている。このため、宗教に係る配信情報の配信には利用されないようにフィルタ条件をフィルタＤＢ６９に設定する。

【0169】

表８Ｈの要求情報のうち、ＩＤ＝１，２，４の情報は、許可された配信情報のため配信可能である。

【0170】

一方、ＩＤ＝３の情報は、宗教に係る情報のため、フィルタリングされ、配信に利用されない。

【0171】

以上のように本実施形態の匿名情報配信システム１００は、配信ポリシー等が変更された場合でも、匿名化の再演算を行うことなく、配信可能な匿名情報を配信に利用することができる。

【0172】

〈その他〉
本発明は、上述の図示例にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。

【符号の説明】

【0173】

１ 演算処理部
３ 通信制御部
４ 記憶装置
５ 入出力インタフェース
７ 端末
１０ 病院情報システム
１１ 抽象化部
１３ 検定部
１４ 選択部
１５ データ更新部
１６ データ受付部
１７ 出力制御部
２０ 匿名価値評価システム
２１ 価値データ取得部
２２ 価値判定部
２３ ワードカテゴリ分析部
２４ 価値計算部
３０ 配信情報管理システム
３１ 匿名データ出力部
３２ 配信データ受付部
４０ 検索エンジン
４１ データ出力部
５０ 端末
６１ ポリシー受付部
６２ フィルタ設定部
６３ 配信制御部
１００ 匿名情報配信システム
１０１ 受付機
１０２ 入出力端末
１０３ 病院情報サーバ
１０４ ウェブサーバ
２０１ 演算処理部
２０３ 通信制御部
２０４ 記憶装置
２０５ 入出力インタフェース
３０１ 演算処理部
３０３ 通信制御部
３０４ 記憶装置
３０４ 記憶部
３０５ 入出力インタフェース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】