JP2015141642A - 利用同意管理装置 - Google Patents

Abstract

【課題】パーソナルデータの利用同意を適切に管理し、できるだけ多くの情報の利活用に対して同意を得られるようにする。
【解決手段】開示する利用者同意管理装置は、利用者からサービスの利用要求を取得する取得部と、サービスの利活用レベルをサービス毎に記憶する必要データレベル記憶部と、利活用レベル、及びサービス提供会社に提供するパーソナルデータの内容とを対応づけて記憶する利活用レベル定義記憶部と、利活用レベル、及び利用者が受けられる利潤とを対応付けて記憶する利潤記憶部と、利用者から取得したサービスに対応する利活用レベルと、パーソナルデータの内容に基づいて利用者のリスクを算出するリスク評価部と、利用者から取得したサービスに対応する利活用レベルに基づいて、利用者が受けられる利潤を算出する利潤評価部と、利用者のリスクと、利用者が受けられる利潤とを表示する表示部と、を備える。
【選択図】 図１

Description

本発明は、パーソナルデータの利用同意を管理する装置に関する。

個人にまつわる膨大なデータ集積が進む昨今、いわゆる個人情報保護法で保護される個人情報を含む、パーソナルデータ（GPSによる位置情報、ポイントカードプログラムによって蓄積される購買履歴などを含む）の利活用に注目が集まっている。このような場合、情報主体である個人に対してプライバシの配慮を行う必要があり、パーソナルデータを適切に利用するためのプライバシ保護技術が注目を集めている。たとえば、特許文献１では、パーソナルデータを利活用する前に匿名化を行うことを前提に、匿名化されたパーソナルデータのリスク評価を３種の観点から行い、リスクが許容されればデータ開示を行うシステムを提案している。

米国特許第8,316,054号

ところが、特許文献１の技術は、単に匿名化されたパーソナルデータのリスク評価を行うに過ぎず、個々人が自分のパーソナルデータがどのように利用されるのか、納得した上で利用に同意を取得するものではない。特に近年では、パーソナルデータの利活用においては個人の利用同意を個人の意思に従う形で適切に取得することが求められる風潮が国内外で高まっている。そこで、適切に利用同意を取得・管理するシステムが求められる。一方で、オプトイン・オプトアウトを前提とした利用同意管理を行う場合、リスクを偏重するあまり、情報利活用をそもそも拒否されてしまう可能性が高まる。そのため、個人のパーソナルデータ利活用によって、個人が得られる利潤、情報利活用によるリスクを適切に把握した上で個人が提供する情報の粒度を選択できるようなシステムが望まれる。

開示する利用者同意管理装置は、利用者からサービスの利用要求を取得する取得部と、サービスの利活用レベルをサービス毎に記憶する必要データレベル記憶部と、利活用レベル、及びサービス提供会社に提供するパーソナルデータの内容とを対応づけて記憶する利活用レベル定義記憶部と、利活用レベル、及び利用者が受けられる利潤とを対応付けて記憶する利潤記憶部と、利用者から取得したサービスに対応する利活用レベルと、パーソナルデータの内容に基づいて利用者のリスクを算出するリスク評価部と、利用者から取得したサービスに対応する利活用レベルに基づいて、利用者が受けられる利潤を算出する利潤評価部と、利用者のリスクと、利用者が受けられる利潤とを表示する表示部と、を備える。

上記のように、本発明により、利活用する情報の粒度に応じた利潤・リスクを個人が把握した上で、利活用に同意する情報の粒度を選択できるようになる。

さらに、これに伴い増加する事業者の情報管理コストを低減させる。

本発明の実施例１及び２に係る利用同意管理装置が適用された計算機の構成例を示す。 実施例１及び２に係るパーソナルデータテーブル１３１の一例を示す。 実施例１及び２に係る利用データテーブル１３２の一例を示す。 実施例１及び２に係る利活用レベル定義テーブル１３３の一例を示す。 実施例１及び２に係る必要データレベルテーブル１３４の一例を示す。 実施例１及び２に係る利活用同意管理テーブル１３５の一例を示す。 実施例１及び２に係る利活用同意管理テーブル１３５の一例を示す。 実施例１及び２に係る同意取得の処理フローの一例を示す。 実施例１及び２に係る利潤評価部１２２を実現するためのテーブル構成の一例を示す。 実施例１及び２に係る同意取得部１２３が同意取得に際して個人に対して提示する画面の一例を示す。 実施例１及び２に係る同意取得部１２３が同意取得に際して個人に対して提示する画面の一例を示す。 実施例２に係る利潤評価部１２２が個人に対して提示する画面の一例を示す。

以下，本発明の幾つかの実施例を、図面を参照して詳細に説明する。

なお、以下の説明では「ｘｘｘテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ｘｘｘテーブル」を「ｘｘｘ情報」と呼ぶこともある。

また、以下の説明では、「プログラム」がプロセッサ（たとえばCPU (Central Processing Unit)）によって実行されることで発揮される機能を、処理を意味するものとして説明することがあるが、定められた処理を、適宜に記憶資源（たとえばメモリ）及び／または通信インタフェース装置（たとえば通信ポート）を用いながら行うため、処理の主体がプロセッサとされてもよい。プロセッサは、プロセッサが行う処理の一部または全部を行うハードウェア回路を含んでもよい。コンピュータプログラムは、プログラムソースから各計算機にインストールされてもよい。プログラムソースは、たとえば、プログラム配布サーバまたは記憶メディアであってもよい。

また、以下のすべての実施例は、主に電子的な形態のパーソナルデータを適切に利活用するための利用同意管理技術にある。以下のすべての実施例において、ポイントカード事業を例におき、パーソナルデータとしてUID（個人のID）、氏名、性別、住所、年齢、購買店舗、購買日時、購買物からなるデータをサンプルとして利用する。しかし、本発明の適用できる事業及びパーソナルデータはこれに限られるものではない。

図１は、本発明の実施例１に係る利用同意管理装置が適用された計算機の構成例を示す。

計算機１００は、情報処理装置であり、たとえばPC (Personal Computer) 、サーバ、あるいはワークステーションなどである。計算機１００は、CPU (Central Processing Unit) １０１、メモリ１０２、ストレージ１０３、入力装置１０４、出力装置１０５及び通信装置１０６を有する。これらはすべて、バスなどの内部通信線１０７によって互いに接続されている。

ストレージ１０３は、たとえばCD-R (Compact Disc Recordable) やDVD-RAM (Digital Versatile Disk Random Access Memory)、シリコンディスクなどの記憶メディア及び当該メディアの駆動装置、HDD (Hard Disk Drive)などである。ストレージ１０３は、パーソナルデータテーブル１３１、利用データテーブル１３２，利活用レベル定義テーブル１３３、必要データレベルテーブル１３４、利用同意管理テーブル１３５、利潤テーブル８０１、及びプログラム１５１を記憶する。なお、利潤テーブル８０１は、外部装置が備えても良い。

パーソナルデータテーブル１３１は、個人に関する情報（本実施例では、UID、氏名、性別、住所、年齢、購買店舗、購買日時、購買物から成る）を格納する。

利用データテーブル１３２は、あるサービスに対して利活用を個人が同意したレベルにまで匿名化を行った結果を格納する。すなわち、利用データテーブル１３２に含まれる情報が、あるサービスを事業者が実施する上で利用するデータとなる。また、ここでサービスとは１つである必要は無い。

利活用レベル定義テーブル１３３は、情報利活用レベルの定義を格納する。この情報利活用レベルは、サービス毎に異なる体系であっても、事業者の提供するサービスで一貫したものであっても良い。

必要データレベルテーブル１３４は、あるサービスを実施する上で最低限必要な情報のレベルを格納する。

利用同意管理テーブル１３５は、各個人が利活用を同意した情報利活用のレベルを格納する。

プログラム１５１は後述する機能を実現するためのものである。

入力装置１０４は、たとえばキーボード、マウス、スキャナ、マイクなどである。出力装置１０５は、ディスプレイ装置、プリンタ、スピーカなどである。入力装置１０４及び出力装置が一体になっていてもよい（たとえば、タッチパネル型のディスプレイ装置）。また、実施例ではストレージ１０３に格納された任意のテーブルにCPU１０１が情報を出力することがあるが、この際に同時に出力装置１０４に同じ情報を出力しても良い。

通信装置１０６は、たとえばLAN（Local Area Network）ボードなどであり、通信ネットワーク（図示略）と接続することができる。

CPU１０１は、メモリ１０２上にプログラム１５１をロードし、実行することにより、リスク評価部１２１、利潤評価部１２２、同意取得部１２３、匿名化部１２４を実現する。

リスク評価部１２１は、同意取得部１２３より依頼をうけた際に、パーソナルデータテーブル１３１、利活用レベル定義テーブル１３３を入力とし、ある個人のパーソナルデータを各利活用レベルに匿名化を行った場合のリスクを算出し、これを同意取得部１２３に受け渡す。

利潤評価部１２２は、同意取得部１２３より依頼をうけた際に、パーソナルデータテーブル１３１、利活用レベル定義テーブル１３３、必要データレベルテーブル１３４などを入力とし、個人に各利活用レベルを同意してもらったときに個人に還元される利潤を算出し、同意取得部１２３に受け渡す。

同意取得部１２３は、パーソナルデータテーブル１３１、利活用レベル定義テーブル１３３、必要データレベルテーブル１３４、利活用同意管理テーブル１３５を入力とし、リスク評価部１２１と利潤評価部１２２を内部で利用しつつ、個人に対し同意を取得するアクションを起こす。たとえば、インターネットを通じたweb画面を通して、個人に対しどの情報利活用レベルでどういった利潤が得られ、そのリスクがどのくらいあるのかを分かりやすく提示することで、個人が意思を持って情報利活用に同意を示すことができるようにする。同意取得部１２１はさらに、個人の選択を受け取り、利活用同意管理テーブル１３７にこれを出力する。

匿名化部１２４は、パーソナルデータテーブル１３１、利用同意管理テーブル１３７を入力とし、同意を取得した利活用レベルに対する匿名化を実行し、利用データテーブル１３２に出力する。

すなわち、利用者同意管理装置は、利用者からサービスの利用要求を取得する取得部と、サービスの利活用レベルをサービス毎に記憶する必要データレベル記憶部と、利活用レベル、及びサービス提供会社に提供するパーソナルデータの内容とを対応づけて記憶する利活用レベル定義記憶部と、利活用レベル、及び利用者が受けられる利潤とを対応付けて記憶する利潤記憶部と、利用者から取得したサービスに対応する利活用レベルと、パーソナルデータの内容に基づいて利用者のリスクを算出するリスク評価部と、利用者から取得したサービスに対応する利活用レベルに基づいて、利用者が受けられる利潤を算出する利潤評価部と、利用者のリスクと、利用者が受けられる利潤とを表示する表示部と、を備える。

次に、上述した各テーブルの詳細を説明する。

図２はパーソナルデータテーブル１３１の一例を示す。パーソナルデータは、上述のように、UID、氏名、性別、住所、年齢、購買店舗、購買日時、購買物で構成されるものを例として示す。パーソナルデータテーブル１３１では、UID、氏名性別、住所、年齢という非履歴データテーブル２０１と、購買店舗、購買日時、購買物という履歴データテーブル２０２を分離して格納しているが、必ずしも分離の必要は無い。なお、テーブル２０１と２０２の間で個人の購買をひもづけるため、UIDをテーブル２０２に格納している。UIDはたとえばポイントカードのIDである。

図３は利用データテーブル１３２の一例を示す。SIDはサービスIDを意味しており、ここではS1という１つのサービスを扱っている。一般には、事業者が複数のサービスを展開していることも多く、サービスを１つに限定する必要は無い。本実施例では、各々サービス実現のために収集したデータを、他事業者にて二次利用するモデルも視野にいれる。即ち、各々のサービスに対して、データの一次利用とは別に、データの提供先が0個以上存在する。利用データテーブル１３２の例ではイロハ社にデータ提供することを前提としている。各々の（サービス、提供先）の組に対して、個人が利活用を同意したレベルまで匿名化部１２４が匿名化を行った結果がテーブル３０１、３０２である。ここで、P-UIDは疑似UIDを意味する。UIDは個人を容易に特定しうるので、サービス毎、提供先毎に異なったIDを利用することが望ましい。そのために、利用データテーブル１３２では（SID、提供先）の組で一貫したP-UIDを付与した匿名化データを格納している。同様に、氏名についても個人を容易に特定しうるため、利活用データから排除している。ここでは、一次利用についても氏名を排除しているが、同意を取得した上で氏名を利用しても良い。

図４は、利活用レベル定義テーブル１３３の一例を示す。例では、各項目毎に、個人に選択を促す利活用許諾レベル（提供レベル）を数段階定義している。すなわち、個人は利活用レベル定義テーブル１３３に格納された情報粒度から、利活用を許諾する情報粒度を選択することになる。

図５は必要データレベルテーブルの例を示す。テーブル１３４ａとテーブル１３４ｂは異なる２つの例である。テーブル１３４ａは属性毎に最低限必要レベルを規定している例である。図４の利活用レベル定義テーブル１３３を参照すれば、たとえば一次利用目的には性別は全て提供されることが必要、住所は少なくとも市まで提供されることが必要、年齢は少なくとも10歳刻みまで提供されることが必要というような意味を有する。利活用レベルに全く制約がない場合には、全ての項目のレベルを0とすれば良い。

テーブル１３４ｂの例では、属性毎に必要レベルを指定するのではなく、k-匿名性の概念を用いて、属性の組み合わせに対して必要利活用レベルを規定した例である。すなわち、ここで規定されたｋの値と同じか、それよりも小さい値となる匿名度（情報粒度）での提供を受けなければならないことを意味する。特に制約がなければ、ｋ＝十分に大きな数に設定すれば良い。なお、テーブル１３４ｂのようにk-匿名性を用いて必要データレベルテーブル１３４を規定する場合には、利活用レベル定義テーブル１３３はなくてもよい（ｋ値によって暗黙的に利活用レベルが定義できる）。また、特に、最低限必要な利活用レベルがない場合（任意のレベルでの提供で良い場合）には、特に必要データレベルテーブル１３４を用意する必要はない。

図６Ａと図６Ｂは利活用同意管理テーブル１３５の異なる２つの例を示す。図６Ａの利用同意管理テーブル１３５ａは必要データレベルテーブル１３４ａに対応する例である。個人が各項目に対して利活用に同意したレベルを格納している。格納されている各利活用レベル値は、必要データレベルテーブル１３４ａに格納されている各項目に対応した必要データレベルの数値よりも大きくなっている。即ち、事業者のサービス提供に必要な粒度よりも細かい情報の利活用に同意していることになるので、サービス提供が可能である。図６Ｂの利活用同意管理テーブル１３５ｂは必要データレベルテーブル１３４ｂに対応する例である。格納されている各利活用レベル値（k値）は、必要データレベルテーブル１３４ｂに格納されている各項目に対応した必要データレベルの数値（k値）よりも小さくなっている。即ち、事業者のサービス提供に必要な粒度よりも細かい情報の利活用に同意していることになるので、サービス提供が可能である。

図７は同意取得部１２３が個人に対して同意取得を行う処理の一例をシーケンス図を用いて示す。図７では、個人が事業者からサービスを享受するためのフローを包含して記載している。また、本実施例では、簡単のためにあらかじめパーソナルデータを事業者に対して登録している前提で記載をしているが、サービス利用申込時に同時にパーソナルデータを登録するのでも良い。また、本実施例ではオプトインを前提とした処理例を記載しており、個人のサービス利用申込時に同意取得を明示的に取るケースを想定しているが、本処理は少し変更することで個人が同意したデータ利活用レベルを変更したい際の処理としても活用できる。さらに、このことから、オプトアウトを前提とした処理にも活用できる。この場合、個人のサービス利用申込時には、包括的同意を取得しておき、前記のデータ利活用レベル変更処理をオプトアウトの手段として活用すればよい。以下で、サービス提供部７０２は、事業者のある１つのサービスを実現するものである。以下に、フローを示す。

端末７０１からサービスの利用申し込みを受けたサービス提供部７０２は、同意取得部１２３にパーソナルデータの利活用に関する同意取得処理を委譲する（Ｓ７００１、Ｓ７００２）。同意取得部１２３は、当該端末７０１のパーソナルデータと、その利活用レベルに応じたリスクの評価処理と、その利活用レベルに応じたパーソナルデータの利活用によって個人が享受する利潤の評価処理をそれぞれリスク評価部１２１と利潤評価部１２２に委譲する（Ｓ７００３、Ｓ７００５）。処理の委譲を受けたリスク評価部１２１と利潤評価部１２２は、リスク及び利潤を算出し同意取得部１２３に返却する（Ｓ７００４、Ｓ７００６）。同意取得部１２３は、返却されたリスク値及び利潤値を用いて同意取得画面を生成し、端末７０１に提示する（Ｓ７００７）。ここでは、画面を用いた同意取得処理を想定しているが、書面などの他の方法であってもよい。また、Ｓ７００７の処理を行う前に、匿名化部１２４に各情報利活用レベルで匿名化を行った際のデータ提供を依頼し、この返却値をサンプルとして同意取得画面に開示しても良い。さらに、Ｓ７００７より以前にＳ７００３〜Ｓ７００６などで各種情報を取得しているが、これらの処理は同意取得画面提示後、非同期的に計算を行うことで、同意取得画面をダイナミックに変更させる仕組みであってもよい。端末７０１は各情報提供（事業者にとっては利活用）レベルに応じたリスクと利潤のトレードオフを探りながら、受け入れ可能な同意レベルを選択する（Ｓ７００８）。受け入れ可能な同意レベルが存在しない場合、端末７０１は当該サービスを享受できない。同意取得部１２３は、端末７０１から取得した同意レベルを利用同意管理テーブル１３５に保管した後、端末７０１とサービス提供部７０２に対して同意取得の終了を通知する（Ｓ７００９）。また、端末７０１に同意取得終了を通知すると同時に、個人から取得した同意レベルから個別にカスタマイズされた個別同意書を送付しても良い。同意取得処理が終了した後、サービス提供部７０２がサービス提供の準備が整い次第、端末７０１に、サービスを提供する（Ｓ７０１０、Ｓ７０１１）。

すなわち、利用者同意管理装置（計算機１００）は、必要データレベル記憶部（必要データレベルテーブル１３４）に、サービスの利活用レベルをサービス毎に記憶し、利活用レベル定義記憶部（利活用レベル定義テーブル１３３）に、利活用レベル、及びサービス提供会社に提供するパーソナルデータの内容とを対応づけて記憶し、利潤記憶部（利潤テーブル８０１）に、利活用レベル、及び前記利用者が受けられる利潤とを対応付けて記憶する。そして、利用者同意管理装置の取得部が、利用者からサービスの利用要求を取得し、リスク評価部１２１が、利用者から取得したサービスに対応する利活用レベルと、パーソナルデータの内容に基づいて利用者のリスクを算出し、利潤評価部１２２が、利用者から取得したサービスに対応する利活用レベルに基づいて、利用者が受けられる利潤を算出し、表示部が、利用者のリスクと、利用者が受けられる利潤とを表示する。

また、必要データレベル記憶部、利活用レベル定義記憶部及び利潤記憶部は、項目ごとに前記利活用レベルを記憶し、リスク評価部は、項目ごとに算出された利活用レベルに基づいてリスク値を算出し、利潤評価部は、項目ごとに算出された利活用レベルに基づいて利潤値を算出しても良い。

（オプションの処理）
以上に、同意取得部１２３が同意取得を行う処理の一例を示した。さらに、事業者が個人から、同意したことを否定する訴訟を受けるリスクを減らす対策を行うため、以下のような処理をオプションで行うこともできる。

［１］ダブルオプトイン
Ｓ７００７、Ｓ７００８で端末７０１にパーソナルデータの利活用への同意を取得する時に、端末７０１を所有する個人が内容を良く確認することなく同意をすることがある。これを防ぐために、Ｓ７００８の後、たとえば電子メールなどで端末７０１から取得した利活用レベルを連絡し、電子メール内部に記載されたＵＲＬをクリックすることで初めて同意取得処理を完了するようにすることで、端末７０１を所有する個人が内容を確認する機会を増やすことができる。

［２］電子署名による証跡管理
端末７０１が個別に行った情報利活用レベルへの同意を、きちんと同意を取得したという証跡を残したい場合には、電子署名などの技術を利用すればよい。たとえば、変更不能な状態で閲覧でき、電子署名を付与可能な文書フォーマットで上記の個別同意書を、Ｓ７００８の後、同意取得部１２３から端末７０１に送付し、端末７０１が電子署名を付与した個別同意書を同意取得部１２３に返却した後で同意取得処理を終了すれば良い。このとき、返却された電子署名付き個別同意書を保管すれば証跡管理が可能である。

次に、Ｓ７００３、Ｓ７００４でリスク評価部１２１がリスクを算出する処理の詳細の一例について説明する。リスクの指標はk-匿名性、母集団一意性、l-多様性など様々なものがあり、このうち１個以上の複数のいずれを用いても良い。ここでは、一例としてk-匿名性をリスクの評価値として選択した場合の処理を示す。まず、リスク評価部１２１は、各利活用レベルにパーソナルデータテーブル１３１の匿名化を行う。この処理は、あらかじめ行われ、結果を別途保存しておいても良い。次にリスク評価部１２１は、この匿名化データ上において、当該端末７０１の情報の組と同じ情報の組を持つ個人の数を計数し、これをリスク値として同意取得部１２３に返却する。一例を挙げれば、図２でＵＩＤが１である個人について、性別＝男性・住所＝神奈川県・年齢＝１０代である個人は２０人、などである。

次に、Ｓ７００５、Ｓ７００６で利潤評価部１２２が利潤を算出する処理の詳細の一例について説明する。個人に還元する利潤（本実施例のポイントカード事業の例ではポイント）は、そのサービスの事業性に応じて決められるものであるため、各々固有の手法を用いているものであることが多い。そこで、ここでは別途利潤が決定されている例を示す。

図８のテーブル８０１は端末７０１から取得したレベルについて、ポイント還元率を定義する定義表の一例である。これを用いて、利潤評価部１２２は、たとえば個人が同意した利活用レベルが、図６Ａで「一次利用：性別＝１、住所＝１、年齢＝１、購買店舗＝２、購買日時＝３、購買物＝２、イロハ社への提供：性別＝１，住所＝０、年齢＝３、購買店舗＝１、購買日時＝１、購買物＝１」のＵＩＤ＝１の個人の場合、１．３％のポイント還元率上昇といった利潤の算出ができる。

次に、Ｓ７００７で同意取得部１２３が端末７０１に対して提示する同意取得画面９００の一例を図９Ａと図９Ｂに示す。同意取得画面９００では、タブ９０１を用いて情報利活用先（情報提供先）毎の同意取得を実現する。エリア９０２では、各項目についての利活用同意レベルの入力をスライダーを用いて要求する。なお、k-匿名性を用いた同意取得の場合などには、必ずしも項目毎の同意取得とする必要はない。また、エリア９０３では、その利活用レベルで同意した際にどのような形式のデータが利用されるのかを端末７０１に提示する。エリア９０４では、その利活用レベルで同意した際にどれくらいの個人特定リスクが潜在しているのかを定量的に表示している。エリア９０５では、その利活用レベルで同意した際にどれくらいの利潤を端末７０１が得ることができるのかを提示している。これらにより、端末７０１がリスクと利潤のトレードオフを探りやすいシステムを構築できる。

タブ９０１の「イロハ社への情報提供」を選択すると、図９Ｂに記載の画面へと推移する。図９Ｂでは、チェックボックス９０６が図９Ａとは異なる。チェックボックス９０６は、サービスで収集したパーソナルデータの提供先が複数となった際に、端末７０１の入力の手間を削減するためのものである。チェックボックス９０６では、一例として、イロハ社と同業者への情報提供は同じポリシで実施することを選択できるようにしている。この機能は、情報提供先をクラスタリングすることで実現でき、このクラスタリングはＳ７００７以前にサービス提供事業者で行われていれば良い。これにより、同業者での入力削減の他にも、提供先の信頼度に応じたクラスタリングや、利潤の多さに関するクラスタリング、情報提供先の必要データレベルについてのクラスタリングなどによる入力削減が実現できる。

次に、Ｓ７００９で利用同意の取得が完了した後に、匿名化部１２４が匿名化を行う処理の詳細について説明する。

匿名化部１２４は、パーソナルデータテーブル１３１と利活用同意管理テーブル１３５を参照し、匿名化を行い、結果を利用データテーブル１３２に格納する。この匿名化の方法の実施の一例は以下の通りである。利活用同意を、利活用同意管理テーブル１３５ａのように、項目別で取得した場合には、同意を取得したレベルにまで情報を落とすよう匿名化を行えば良い。また、利活用同意を、利活用同意管理テーブル１３５ｂのように、k-匿名性をベースとした同意取得である場合には、k-匿名化を行えば良い。一般的なk-匿名化はテーブル全体で一意なｋ値に対して匿名化を実施するのに対し、ここでは個人個人で異なるｋ値に対してk-匿名化を行う必要がある。そのため、段階的に曖昧化を実施し、曖昧化の順序立てて行われるような貪欲的手法（複数の曖昧化候補の中から、情報損失が最も小さいなどの指標を用いて１つ曖昧化対象を選択して曖昧化を実施し、k-匿名性の評価を行うことを最終的にk-匿名性を満足するまで繰り返す手法）を用いて、利活用同意管理テーブル１３５に含まれる最大のｋ値でk-匿名化を行い、その各曖昧化の段階で各個人が指定のk値を初めて満足したところを、当該個人の匿名化結果とすれば良い。なお、匿名化部１２４がパーソナルデータテーブル１３１の匿名化を実施するタイミングは一定期間毎に行うのが良い（たとえば日に一回など）。これは、本実施例で扱った購買履歴データのような履歴データに対応できることと、個人のパーソナルデータの変更や、利活用同意レベルの変更などに柔軟に対応できるためである。

以上のように、本実施例に係る計算機１００の１つの特徴は、個人がパーソナルデータ利活用のレベル選択できるようにすることと、その情報利活用のリスクと利潤のトレードオフを探ることを可能にすることで、個人と事業者の間で納得感の高いサービスを実現することである。言い換えれば、個人の同意を得た上で利活用（一次利用、二次利用）できる情報の量を増やすことができる。

以下、本発明の実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略あるいは簡略する。具体的には、例えば、実施例２を説明する場合、上述の実施例１と重複する構成に対しては同じ符号を付与して説明を省略する。また、実施例１と同じ動作に対しては、同じ符号を付与して説明を省略する。

実施例２の１つの特徴は、利潤評価部１２２が用いる利潤の定義を柔軟に行うことで、利活用同意を得る情報の粒度をさらに細かくすることである。これを実現するための、利潤評価部１２２の３つの例を示す。

１つ目の例の利潤評価部１２２は、サービス開始から時間がそれほど経過していないときに、評価利潤値を優遇する。具体的には、計算機１００のストレージ１０３は、サービス開始時刻を記憶するサービス開始時刻記憶部と、経過時間に伴い優遇される利潤値を記憶する優遇度記憶部を更に備え、利潤評価部１２２は、サービス開始時刻記憶部に記憶されたサービスの開始時刻と現在時刻にもとづいて、経過時間を算出し、優遇度記憶部に記憶された利潤値に基づいて利潤値を算出する。これにより、利活用可能なパーソナルデータを蓄積しやすくする効果を期待できる。たとえば、本実施例で例として用いているポイントカード事業の場合には、許諾を得られる個人の総数が10,000人を超えるまではポイント還元率を1%上昇させるといった利潤評価部１２２の実現例が挙げられる。

２つ目の例の利潤評価部１２２は、実際に活用されたパーソナルデータの量に応じて、実績ベースで利潤値を評価する。具体的には、計算機１００のストレージ１０３は、実際に活用された実績データを記憶する実績データ記憶部と、実績に対応する利潤値を記憶する優遇度記憶部を更に備え、利潤評価部１２２は、実績データ記憶部に記憶された実績データに基づいて利潤値を算出する。情報利活用を行う事業者（提供先）は、情報の粒度が細かい方が利活用対象とすることが多いと考えられるため、これにより個人が細かい情報の利活用に対してオプトインをする可能性が高くなると考えられる。例えば、固定の還元率に基づく購買に対するポイント付与とは別に、二次利用目的で情報提供が行われた実績数から、ポイントを追加で付与するといった形態が考えられる。この場合、実施例１の図９Ａ、図９Ｂのようなオプトイン時の利潤評価が厳密にできないが、オプトイン時には実績ベースで追加のインセンティブが付与されることを明記し、実績・及びその結果の確認を個人が行うための方法を準備すれば良い。これはインターネットを通じてのwebの画面でも良いし、毎月通知書を送付するのでも、任意の方法で良い。

図１０は、その一例を示す。画面１０００は、ある個人が自分のパーソナルデータが利活用を行われた提供先、ポイントカード事業者が提供先に提供したその個人に関する情報の詳細、それに対して付与されるポイントを個人に対して提示している。

３つ目の例の利潤評価部１２３は、上記の２つ目の例のオプションである。個人が同意を行った利活用レベルに対して、仮にそれよりも粒度の細かい情報利活用に同意を行っていたら、どれだけのインセンティブが得られていたかを例えば画面１０００に表示する。すなわち、利潤評価部は、個人が実際に同意したレベルに対応する情報粒度よりも細かい情報粒度で同意を行っていた場合の利潤を更に算出し、表示部は、更に算出された利潤を表示する。
これにより、個人が利活用同意レベルをより細かい方向に変更する可能性が増加すると考えられる。

以上、本発明のいくつかの実施例を説明したが、これらは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、ほかの種々の形態でも実施することが可能である。例えば、上記した実施例は本発明をわかりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、ほかの構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段などはそれらの一部または全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。また、上記の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）などの記憶装置、またはＩＣカード、ＳＤカード、ＤＶＤなどの記憶媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際にはほとんどすべての構成が相互に接続されているものと考えてもよい。

１００：計算機、１０１：CPU、１０２：メモリ、１２１：リスク評価部、１２２：利潤評価部、１２３：同意取得部、１２４：匿名化部、１０３：ストレージ、１３１：パーソナルデータテーブル、１３２：利用データテーブル、１３３：利活用レベル定義テーブル、１３４：必要データレベルテーブル、１３５：利活用同意管理テーブル、１５１：プログラム、１０４：入力装置、１０５：出力装置、１０６：通信装置、１０７：内部通信線

Claims (6)

1. 利用者からサービスの利用要求を取得する取得部と、
   前記サービスの利活用レベルをサービス毎に記憶する必要データレベル記憶部と、
   前記利活用レベル、及びサービス提供会社に提供するパーソナルデータの内容とを対応づけて記憶する利活用レベル定義記憶部と、
   前記利活用レベル、及び前記利用者が受けられる利潤とを対応付けて記憶する利潤記憶部と、
   前記利用者から取得した前記サービスに対応する前記利活用レベルと、前記パーソナルデータの内容に基づいて前記利用者のリスクを算出するリスク評価部と、
   前記利用者から取得した前記サービスに対応する前記利活用レベルに基づいて、前記利用者が受けられる利潤を算出する利潤評価部と、
   前記利用者のリスクと、前記利用者が受けられる利潤とを表示する表示部と、
   を備えることを特徴とする利用者同意管理装置。
2. 請求項１に記載の利用者同意管理装置であって、
   前記必要データレベル記憶部、前記利活用レベル定義記憶部及び利潤記憶部は、項目ごとに前記利活用レベルを記憶し、
   前記リスク評価部は、項目ごとに算出された前記利活用レベルに基づいてリスク値を算出し、
   前記利潤評価部は、項目ごとに算出された前記利活用レベルに基づいて利潤値を算出する
   ことを特徴とする利用者同意管理装置。
3. 請求項１又は２に記載の利用者同意管理装置であって、
   前記必要データレベル記憶部に記憶された前記利活用レベルとは、予め定められた値である
   ことを特徴とする利用者同意管理装置。
4. 請求項３に記載の利用者同意管理装置であって、
   サービス開始時刻を記憶するサービス開始時刻記憶部と、
   経過時間に伴い優遇される利潤値を記憶する優遇度記憶部を更に備え、
   前記利潤評価部は、サービス開始時刻記憶部に記憶されたサービスの開始時刻と現在時刻にもとづいて、経過時間を算出し、優遇度記憶部に記憶された利潤値に基づいて利潤値を算出する
   ことを特徴とする利用者同意管理装置。
5. 請求項３に記載の利用者同意管理装置であって、
   実際、個人に活用された実績データを記憶する実績データ記憶部と、
   実績に対応する利潤値を記憶する優遇度記憶部を更に備え、
   利潤評価部は、実績データ記憶部に記憶された実績データに基づいて利潤値を算出する
   ことを特徴とする利用者同意管理装置。
6. 請求項３に記載の利用者同意管理装置であって、
   前記利潤評価部は、個人が実際に同意したレベルに対応する情報粒度よりも細かい情報粒度で同意を行っていた場合の利潤を更に算出し、
   前記表示部は、更に算出された前記利潤を表示する
   ことを特徴とする利用者同意管理装置。

Images