JP2020187497A - プログラム、サーバ装置および実行順序決定方法 - Google Patents

Abstract

【課題】個人データの利用許可を判定する処理における絞り込み対象数を削減する。【解決手段】認可サーバ１０は、クライアントが個人データの利用要求を行った場合、クライアントが要求する属性を有する個人データの利用許可の同意を確認する同意確認処理と、データ群のうちからクライアントが要求する条件または属性を満たす個人データを抽出するフィルタ処理とを行い、同意確認処理とフィルタ処理との実行順序を判定指標にもとづいて決定する。パターンｐ１において斜線領域を抽出する場合はフィルタ処理を同意確認処理よりも先に行った方が処理効率の向上が見込まれ、パターンｐ２において斜線領域を抽出する場合は同意確認処理をフィルタ処理よりも先に行った方が処理効率の向上が見込まれる。【選択図】図６

Description

本発明は、プログラム、サーバ装置および実行順序決定方法に関する。

近年、企業が保有しているデータを相互に活用して企業間でデータを流通させるデータ流通ネットワークが注目されており、データ流通の促進によって新しいサービスやビジネスの創出が期待されている。

データ流通ネットワークが対象とするデータには、企業が保有する産業データの他に、個人データ（個人情報）が含まれる。個人データを流通させる場合、データの利用者は個人から利用の同意を得る必要があり、個人データの利用許可の判定処理が行われる。

個人データの流通に関連する技術として、例えば、情報提供者の入力によって個人情報の開示制限を設定させ、情報利用者に設定された範囲内で個人情報を提供する技術が提案されている。また、詳細度の高い個人情報と詳細度の低い個人情報を生成して、サービス結果満足条件に応じた個人情報を開示する技術が提案されている。

特開２００２−３２４０６８号公報 国際公開第２００８／１０８１５８号

データ流通ネットワークでは、個人データの利用許可を判定する場合、個人データの利用許可の同意／不同意を確認する同意確認処理と、利用者が要求する条件を満たす個人データを抽出するフィルタ処理とが行われる。

この場合、同意確認処理を先に行ってからフィルタ処理を後に行うか、またはフィルタ処理を先に行ってから同意確認処理を後に行うかによって、対象数を絞り込むときの対象数の削減に差異が生じる。このため、同意確認処理またはフィルタ処理のいずれを先に行うかを適応的に切替えて対象数を削減できる技術の実現が要望されている。

１つの側面では、本発明は、個人データの利用許可を判定する処理における絞り込み対象数の削減を図ったプログラム、サーバ装置および実行順序決定方法を提供することを目的とする。

上記課題を解決するために、コンピュータに、ユーザの個人データが含まれるデータ群のうちから個人データのクライアントによる利用要求を受けて、クライアントが要求する属性を有する個人データの利用許可の同意を確認する同意確認処理と、データ群のうちからクライアントが要求する条件または属性を満たす個人データを抽出するフィルタ処理とを行う場合、判定指標にもとづいて同意確認処理とフィルタ処理との実行順序を決定する処理を実行させるプログラムが提供される。

また、上記課題を解決するために、上記プログラムによって同様の制御を実行するサーバ装置が提供される。
また、上記課題を解決するために、コンピュータが上記プログラムと同様の制御を実行する実行順序決定方法が提供される。

１側面によれば、個人データの利用許可を判定する処理における絞り込み対象数を削減することができる。

サーバ装置の一例を説明するための図である。 データ流通システムの構成の一例を示す図である。 データのフィルタ情報および同意／不同意の関係の一例を示す図である。 認可サーバのハードウェア構成の一例を示す図である。 認可サーバの機能ブロックの一例を示す図である。 同意確認処理とフィルタ処理の実行順序の違いにより処理効率に差異が出るケースの一例を示す図である。 個人データの流通の全体動作シーケンスを示す図である。 個人データ利用許可の判定処理の動作の一例を示すフローチャートである。 絞り込み動作の一例を示すフローチャートである。 辞書テーブルの一例を示す図である。 辞書テーブルの一例を示す図である。 辞書テーブル以外の判定指標にもとづいて実行順序を決定する動作の一例を示すフローチャートである。 辞書テーブル以外の判定指標にもとづいて実行順序を決定する動作の一例を示すフローチャートである。

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態について図１を用いて説明する。図１はサーバ装置の一例を説明するための図である。サーバ装置１は、制御部１ａと記憶部１ｂを備える。また、サーバ装置１は、リソース装置２およびクライアント装置３に接続されている。

リソース装置２は、ユーザの個人データが含まれるデータ群を保有する。クライアント装置３は、リソース装置２に保有されているデータ群のうちから個人データを利用する場合に利用要求をサーバ装置１に送信する。

サーバ装置１は、クライアント装置３からの利用要求にもとづいて、個人データをクライアント装置３に提供するための利用許可判定を行い、判定結果に応じて個人データをクライアント装置３へ送信する中継制御を行う。

制御部１ａは、クライアント装置３が個人データの利用要求を行った場合、利用許可判定処理として同意確認処理とフィルタ処理とを行う。同意確認処理は、クライアント装置３が要求する属性を有する個人データの利用許可の同意を確認する処理である。フィルタ処理は、リソース装置２が保有するデータ群のうちからクライアント装置３が要求する条件（フィルタ条件）または属性を満たす個人データを抽出する処理である。

また、制御部１ａは、同意確認処理およびフィルタ処理を行う場合、判定指標にもとづいて同意確認処理とフィルタ処理との実行順序を決定する。記憶部１ｂは、クライアント装置３が要求する属性に関する情報、クライアント装置３が要求する条件に関する情報、判定指標に関連する情報（後述の辞書テーブル等）および運用制御に関する情報等を格納する。

図１に示す例を用いて動作について説明する。リソース装置２には、個人データＤ１、・・・、Ｄ４が保有されている。また、クライアント装置３から要求されるフィルタ条件には、条件Ａ、・・・、Ｄがあるとする。

個人データＤ１は、クライアント装置３で利用されることに同意のデータであり、条件Ａを満たすデータｄ１１、条件Ｂを満たすデータｄ１２、条件Ｃを満たすデータｄ１３および条件Ｄを満たすデータｄ１４を含む。

個人データＤ２は、クライアント装置３で利用されることに不同意のデータであり、条件Ａを満たすデータｄ２１、条件Ｂを満たすデータｄ２２、条件Ｃを満たすデータｄ２３および条件Ｄを満たすデータｄ２４を含む。

個人データＤ３は、クライアント装置３で利用されることに同意のデータであり、条件Ａを満たすデータｄ３１、条件Ｂを満たすデータｄ３２、条件Ｃを満たすデータｄ３３および条件Ｄを満たすデータｄ３４を含む。

個人データＤ４は、クライアント装置３で利用されることに不同意のデータであり、条件Ａを満たすデータｄ４１、条件Ｂを満たすデータｄ４２、条件Ｃを満たすデータｄ４３および条件Ｄを満たすデータｄ４４を含む。

ここでは、クライアント装置３は、条件Ａ、Ｂ、Ｃ、Ｄのうち条件Ａ、Ｃを満たす個人データを要求するものとする。
〔ステップＳ１〕制御部１ａは、クライアント装置３から送信された個人データの利用要求を受信する。

〔ステップＳ２〕制御部１ａは、判定指標にもとづいて、同意確認処理およびフィルタ処理の実行順序を決定する（判定指標には後述の辞書テーブル等が使用される）。同意確認処理を先にフィルタ処理を後に実行する場合を第１の実行順序、フィルタ処理を先に同意確認処理を後に実行する場合を第２の実行順序とする。このとき、第１の実行順序の方が第２の実行順序よりも処理効率が高くなると判定された場合は、ステップＳ３へ処理が進み、第２の実行順序の方が第１の実行順序よりも処理効率が高くなると判定された場合は、ステップＳ５へ処理が進む。

〔ステップＳ３〕制御部１ａは、同意確認処理を行って、個人データＤ１、・・・、Ｄ４の利用許可の同意を確認する。この例では、個人データＤ１、Ｄ３はクライアント装置３に対する利用許可が同意されており、個人データＤ２、Ｄ４はクライアント装置３に対する利用許可が不同意になっている。このため、制御部１ａは、同意が取れている個人データＤ１、Ｄ３を抽出する。

〔ステップＳ４〕制御部１ａは、フィルタ処理を行って、クライアント装置３が要求する条件を満たす個人データを抽出する。この例では、クライアント装置３は条件Ａ、Ｃを満たすデータを要求している。

このため、制御部１ａは、同意が取れている個人データＤ１、Ｄ３のうちから条件Ａ、Ｃを満たす個人データＤ１（ｄ１１、ｄ１３）、Ｄ３（ｄ３１、ｄ３３）を抽出する。そして、制御部１ａは、抽出した個人データＤ１（ｄ１１、ｄ１３）、Ｄ３（ｄ３１、ｄ３３）をクライアント装置３へ送信する。

〔ステップＳ５〕制御部１ａは、フィルタ処理を行って、クライアント装置３が要求する条件を満たす個人データを抽出する。この例では、クライアント装置３は条件Ａ、Ｃを満たすデータを要求している。

このため、制御部１ａは、個人データＤ１、・・・、Ｄ４のうちから条件Ａ、Ｃを満たす個人データＤ１（ｄ１１、ｄ１３）、Ｄ２（ｄ２１、ｄ２３）、Ｄ３（ｄ３１、ｄ３３）、Ｄ４（ｄ４１、ｄ４３）を抽出する。

〔ステップＳ６〕制御部１ａは、同意確認処理を行って、個人データの利用許可の同意を確認する。この例では、個人データＤ１、Ｄ３はクライアント装置に対する利用許可が同意されており、個人データＤ２、Ｄ４はクライアント装置に対する利用許可が不同意になっている。

このため、制御部１ａは、ステップＳ５で抽出した個人データのうち、同意が取れている個人データＤ１（ｄ１１、ｄ１３）、Ｄ３（ｄ３１、ｄ３３）を抽出する。そして、制御部１ａは、抽出した個人データＤ１（ｄ１１、ｄ１３）、Ｄ３（ｄ３１、ｄ３３）をクライアント装置３へ送信する。

このように、サーバ装置１では、クライアント装置３が要求する属性を有する個人データの利用許可の同意を確認する同意確認処理と、データ群のうちからクライアント装置３が要求する条件を満たす個人データを抽出するフィルタ処理との実行順序を判定指標にもとづいて適応的に決定する。これにより、個人データの利用許可を判定する処理の絞り込み対象数を削減することができ、処理効率を向上させることが可能になる。

［第２の実施の形態］
次に個人データの取引が行われるデータ流通ネットワークに本発明の機能を適用した第２の実施の形態について説明する。図２はデータ流通システムの構成の一例を示す図である。データ流通システム１−１は、同意ポータル１０ａ、データ提供エンティティ２ａ、データ利用エンティティ３ａおよびユーザ端末４０−１、・・・、４０−ｎ（総称する場合はユーザ端末４０）を備える。なお、エンティティとは個人や企業等の活動の主体である。

同意ポータル１０ａは、個人データを転送させる場合の同意確認を行うためのポータルサイトである。データ提供エンティティ２ａは、データを保有し、保有しているデータのうちから要求されたデータを要求元へ提供する。データ利用エンティティ３ａは、データの要求を行って提供されたデータを利用する。

同意ポータル１０ａは、認可サーバ（ＡＳ：Authorization Server）１０を有し、データ提供エンティティ２ａは、リソースサーバ（ＲＳ：Resource Server）２０を有し、データ利用エンティティ３ａは、クライアントサーバ（ＣＳ：Client Server）３０を有する。なお、認可サーバ１０は、図１のサーバ装置１の機能を有する。

認可サーバ１０、リソースサーバ２０、クライアントサーバ３０およびユーザ端末４０は、ネットワーク（例えば、インターネット）５を介して互いに接続されている。
リソースサーバ２０は、データオーナであるユーザのユーザ端末４０から送信されたデータを保有し、保有しているデータのうちから要求されたデータをクライアントサーバ３０に提供する。

クライアントサーバ３０は、リソースサーバ２０にデータを要求し、リソースサーバ２０から提供されたデータを利用する。認可サーバ１０は、リソースサーバ２０からクライアントサーバ３０へデータが提供される際に、個人データの利用許可判定処理を行う。

データ提供エンティティ２ａおよびデータ利用エンティティ３ａは、例えば、企業であって、データ提供エンティティ２ａは自動車会社、データ利用エンティティ３ａは保険会社に対応させることができる。ユーザ端末４０は、企業とは異なる個人のエンティティである。

このようなケースにおいて、例えば、自動車会社は、ユーザの運転データを保有して、保険会社から要求された運転データを保険会社へ提供する。保険会社は、自動車会社に運転データを要求し、提供された運転データを取得して保険査定等の事務に利用する。また、運転データには個人情報が含まれるため、自動車会社から保険会社に運転データが渡される場合には、個人情報のオーナであるユーザの同意が必要になる。

ユーザの同意確認は、同意ポータル１０ａ内の認可サーバ１０によって行われる。認可サーバ１０によって、データ要求元である保険会社に対するユーザ本人の提供同意が済みか否かが確認され、同意の確認が取れた場合、保険会社に対して運転データのアクセス権が与えられる。

ここで、クライアントサーバ３０からリソースサーバ２０へのデータ要求には、データ利用エンティティ３ａが所望する個人の属性とフィルタ条件とが示されている。認可サーバ１０では、個人の属性にもとづく同意確認が行われ、リソースサーバ２０では、フィルタ条件（以降ではフィルタ情報と呼ぶ場合がある）にもとづく個人データの抽出（フィルタ処理）が行われる。なお、認可サーバ１０とリソースサーバ２０とでフィルタ情報を授受し、フィルタ処理を分担して実行することもできる。

ここで、保険会社が自動車会社に対して、車種がモデルＡの自動車を所有している年齢が３０代のユーザの運転データを要求するものとする。この運転データは、個人の属性情報として年齢＝３０代が含まれ、フィルタ情報として車種＝モデルＡが含まれる。

年齢＝３０代という個人の属性情報は、認可サーバ１０によって、全利用者から年齢＝３０代の抽出が行われ、また認可サーバ１０によって、年齢＝３０代の同意確認が行われる。さらに、車種＝モデルＡは、個人の属性情報とは異なるフィルタ情報であり、リソースサーバ２０によって、全車種から車種＝モデルＡの抽出が行われることになる。

図３はデータのフィルタ情報および同意／不同意の関係の一例を示す図である。範囲ｃ１は、第３者（例えば、保険会社）に提供されることにユーザが同意しているデータの集合を示し、範囲ｃ１以外は、第３者への提供に対して不同意のデータの集合を示している。

範囲ｃ２は、年齢＝３０代の属性を持つデータの集合を示し、範囲ｃ２以外は、年齢≠３０代のデータの集合を示している。範囲ｃ３は、車種＝モデルＡの自動車のデータの集合を示し、範囲ｃ３以外は、車種＝モデルＡ以外の自動車のデータの集合を示している。

範囲ｃ４は、範囲ｃ１、ｃ２の共通範囲であり、年齢＝３０代で第３者への提供を同意しているデータの集合を示している。範囲ｃ５は、範囲ｃ２、ｃ３の共通範囲であり、年齢＝３０代で車種＝モデルＡの自動車を所有しているデータの集合を示している。範囲ｃ６は、範囲ｃ１、ｃ２、ｃ３の共通範囲であり、年齢＝３０代で車種＝モデルＡの自動車を所有し第３者への提供に同意しているデータの集合を示している。

ここで、車種がモデルＡの自動車を所有している年齢が３０代で利用許可に同意しているユーザの運転データは、範囲ｃ６に含まれるから、範囲ｃ６は、実際のデータ取得範囲である。範囲ｃ６に含まれるデータを取得する場合、範囲ｃ１と範囲ｃ２が共通する範囲ｃ４を求めてから、範囲ｃ４と範囲ｃ３が共通する範囲ｃ６を求める場合がある。

しかし、例えば、年齢＝３０代が１０００万人、車種＝モデルＡが１万人いるとすると、この場合、１０００万人分についての同意確認を行って範囲ｃ４の同意している年齢＝３０代を求め、その後に車種＝モデルＡを所有しているか否かのフィルタリングを行うことになる。

この例の場合、同意確認を先に実行してしまうと、範囲ｃ４に絞り込むまでの処理負荷が高くなり、また判定結果が出力されるまでの時間が増大し、個人データの利用許可の判定処理を効率よく行うことができない。

したがって、この例の場合、年齢＝３０代で車種＝モデルＡを所有しているフィルタリングを先に行って、その後に同意確認を行った方がデータの絞り込み効果が高い。すなわち、範囲ｃ６に含まれるデータを取得する場合、範囲ｃ２と範囲ｃ３が共通する範囲ｃ５を求めてから、範囲ｃ５と範囲ｃ１が共通する範囲ｃ６を求めた方が、絞り込み対象数が削減して処理効率が向上する。

本発明ではこのような点に鑑みて、同意確認処理と、フィルタ処理とのいずれを先に実行するかを適応的に決定して、個人データの利用許可を判定する処理における絞り込み対象数を削減し、処理効率の向上および処理負荷の軽減を図るものである。

＜ハードウェア構成＞
図４は認可サーバのハードウェア構成の一例を示す図である。認可サーバ１０は、プロセッサ（コンピュータ）１００によって装置全体が制御されている。

プロセッサ１００には、バス１０３を介して、メモリ１０１および複数の周辺機器が接続されている。プロセッサ１００は、マルチプロセッサであってもよい。プロセッサ１００は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）である。またプロセッサ１００は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

メモリ１０１は、認可サーバ１０の主記憶装置として使用される。メモリ１０１には、プロセッサ１００に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０１には、プロセッサ１００による処理に要する各種データが格納される。

また、メモリ１０１は、認可サーバ１０の補助記憶装置としても使用され、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。メモリ１０１は、補助記憶装置として、フラッシュメモリやＳＳＤ（Solid State Drive）等の半導体記憶装置やＨＤＤ（Hard Disk Drive）等の磁気記録媒体を含んでもよい。

バス１０３に接続されている周辺機器としては、入出力インタフェース１０２およびネットワークインタフェース１０４がある。入出力インタフェース１０２は、プロセッサ１００からの命令にしたがって認可サーバ１０の状態を表示する表示装置として機能するモニタ（例えば、ＬＥＤ（Light Emitting Diode）やＬＣＤ（Liquid Crystal Display）等）が接続されている。

また、入出力インタフェース１０２は、キーボードやマウス等の情報入力装置を接続可能であって、情報入力装置から送られてくる信号をプロセッサ１００に送信する。
さらにまた、入出力インタフェース１０２は、周辺機器を接続するための通信インタフェースとしても機能する。例えば、入出力インタフェース１０２は、レーザ光等を利用して、光ディスクに記録されたデータの読み取りを行う光学ドライブ装置を接続することができる。光ディスクには、Ｂｌｕ−ｒａｙＤｉｓｃ（登録商標）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）等がある。

また、入出力インタフェース１０２は、メモリ装置やメモリリーダライタを接続することができる。メモリ装置は、入出力インタフェース１０２との通信機能を搭載した記録媒体である。メモリリーダライタは、メモリカードへのデータの書き込み、またはメモリカードからのデータの読み出しを行う装置である。メモリカードは、カード型の記録媒体である。

ネットワークインタフェース１０４は、ネットワーク５とのインタフェース制御を行い、例えば、ＮＩＣ（Network Interface Card）、無線ＬＡＮ（Local Area Network）カード等を使用することもできる。ネットワークインタフェース１０４で受信されたデータは、メモリ１０１やプロセッサ１００に出力される。

以上のようなハードウェア構成によって、認可サーバ１０の処理機能を実現することができる。例えば、認可サーバ１０は、プロセッサ１００がそれぞれ所定のプログラムを実行することで本発明の制御を行うことができる。

認可サーバ１０は、例えば、コンピュータで読み取り可能な記録媒体に記録されたプログラムを実行することにより、本発明の処理機能を実現する。認可サーバ１０に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。

例えば、認可サーバ１０に実行させるプログラムを補助記憶装置に格納しておくことができる。プロセッサ１００は、補助記憶装置内のプログラムの少なくとも一部を主記憶装置にロードし、プログラムを実行する。

また、光ディスク、メモリ装置、メモリカード等の可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えば、プロセッサ１００からの制御により、補助記憶装置にインストールされた後、実行可能となる。またプロセッサ１００が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。なお、リソースサーバ２０およびクライアントサーバ３０についても、図４と同様なハードウェアで構成することができる。

＜機能ブロック＞
図５は認可サーバの機能ブロックの一例を示す図である。認可サーバ１０は、制御部１１、記憶部１２およびインタフェース部１３を備える。制御部１１は、同意確認処理部１１ａ、フィルタ処理部１１ｂおよび実行順序決定処理部１１ｃを含む。

同意確認処理部１１ａは、クライアント装置３が要求する属性を有する個人データの利用許可の同意を確認する処理を行う。フィルタ処理部１１ｂは、リソース装置２が保有するデータ群のうちからクライアント装置３が要求する条件を満たす個人データを抽出する処理を行う。また、フィルタ処理部１１ｂは、フィルタ情報の一部をリソースサーバ２０に送信して、フィルタ処理をリソースサーバ２０と分担して行うこともできる。

実行順序決定処理部１１ｃは、判定指標にもとづいて、同意確認処理とフィルタ処理との実行順序を決定する。記憶部１２は、例えば、判定指標を含む辞書テーブル１２ａを記憶する（辞書テーブル１２ａの詳細は後述する）。インタフェース部１３は、ネットワーク５との通信インタフェース制御を行う。

なお、制御部１１は図４のプロセッサ１００によって実現され、記憶部１２は図４のメモリ１０１によって実現される。また、インタフェース部１３は図４のネットワークインタフェース１０４（または入出力インタフェース１０２）によって実現される。

＜処理効率に差異が出るケース＞
図６は同意確認処理とフィルタ処理の実行順序の違いにより処理効率に差異が出るケースの一例を示す図である。パターンｐ１、ｐ２において、範囲Ｐは属性情報を有するデータの集合、範囲Ｑはフィルタ情報を有する商品データの集合、範囲Ｒは第３者への提供に同意が示されているデータの集合を示している。

ここで、範囲Ｐ、Ｑ、Ｒの共通部分（斜線部）のデータを抽出するものとする。パターンｐ１は、フィルタ処理を同意確認処理よりも先に行った方が、処理効率（絞り込み効果）が高くなる場合を示している。

範囲Ｐと範囲Ｒの共通部分の集合を求めてから、その共通部分と範囲Ｑとの共通部分（斜線部）を求めるよりも、範囲Ｐと範囲Ｑの共通部分の集合を求めてから、その共通部分と範囲Ｒとの共通部分（斜線部）を求めた方が、絞り込み効果が高い。

したがって、パターンｐ１のような状態では、フィルタ処理を同意確認処理よりも先に行った方が、処理効率が高くなることが見込まれ、処理負荷が軽減することになる。なお、この例では、フィルタ処理は、範囲Ｐと範囲Ｑの共通部分の集合を求める処理に相当し、同意確認処理は、フィルタ処理で求めた共通部分と範囲Ｒとの共通部分を求める処理に相当する。

一方、パターンｐ２は、同意確認処理をフィルタ処理よりも先に行った方が、絞り込み対象数が削減して処理効率が高くなる場合を示している。範囲Ｐと範囲Ｑの共通部分の集合を求めてから、その共通部分と範囲Ｒとの共通部分（斜線部）を求めるよりも、範囲Ｐと範囲Ｒの共通部分の集合を求めてから、その共通部分と範囲Ｑとの共通部分（斜線部）を求めた方が、絞り込み効果が高い。

したがって、パターンｐ２のような状態では、同意確認処理をフィルタ処理よりも先に行った方が、絞り込み対象数が削減して処理効率が高くなることが見込まれ、処理負荷が軽減することになる。なお、この例では、同意確認処理は、範囲Ｐと範囲Ｒの共通部分の集合を求める処理に相当し、フィルタ処理は、同意確認処理で求めた共通部分と範囲Ｑとの共通部分を求める処理に相当する。

＜全体動作シーケンス＞
図７は個人データの流通の全体動作シーケンスを示す図である。ユーザＸは、同意ポータル１０ａを介して、データ利用エンティティ３ａ（例えば、保険会社）のサービスに契約を行う。この場合、ユーザＸは、データ提供エンティティ２ａ（例えば、自動車会社）が保有するデータ（例えば、運転データ）がデータ利用エンティティ３ａに提供されることの同意または不同意の意思表示を行っておく。

〔ステップＳ１１〕ユーザ端末４０は、同意ポータル１０ａに属する認可サーバ１０に対してメッセージｍ１を送信する。メッセージｍ１には、上記のような、データ利用エンティティ３ａのサービスに契約する旨およびデータ利用エンティティ３ａにデータが提供されることの同意または不同意の意思表示が設定されている。

なお、ユーザＸは、データの一部をデータ利用エンティティ３ａへ提供したくない場合、そのポリシをあらかじめ同意ポータル１０ａを介してデータ利用エンティティ３ａに登録することができる。例えば、あるエリアの運転データや週末の運転データは提供しない等のポリシを登録できる。メッセージｍ１には、このようなポリシも設定される。

〔ステップＳ１２〕データ利用エンティティ３ａに属するクライアントサーバ３０は、データ要求依頼メッセージｍ２をデータ提供エンティティ２ａに属するリソースサーバ２０へ送信する。

例えば、データ利用エンティティ３ａが現在の会員の運転データや新規会員の運転データを取得したい場合、データ要求依頼メッセージｍ２がクライアントサーバ３０からリソースサーバ２０へ送信される。

データ要求依頼メッセージｍ２には、リソースサーバ２０で管理されているデータのフォーマットや、データ利用エンティティ３ａが要求する属性情報（例えば、３０代の男性）や、フィルタ情報（例えば、ある日のドライブレコードデータ）が含まれる。

〔ステップＳ１３〕リソースサーバ２０は、データ要求依頼メッセージｍ２を受信すると、データ要求依頼メッセージｍ２を認可サーバ１０へ送信する。
〔ステップＳ１４〕認可サーバ１０は、データ要求依頼メッセージｍ２に含まれる属性情報およびフィルタ情報の解析・保持を行い、アクセス権限を規定しているチケット（アクセスチケット）を発行して、リソースサーバ２０へ送信する。

〔ステップＳ１５〕リソースサーバ２０は、チケットを受信すると、メッセージｍ３をクライアントサーバ３０に送信して応答する。メッセージｍ３には、同意ポータル１０ａのＵＲＩ（Uniform Resource Identifier）およびチケットが少なくとも含まれる。

〔ステップＳ１６〕クライアントサーバ３０は、メッセージｍ３に含まれている同意ポータル１０ａのＵＲＩを使用して、同意ポータル１０ａに属する認可サーバ１０にアクセスする。そして、メッセージｍ３に含まれているチケットを使用して、認可サーバ１０に対してアクセスの認証に使用されるトークン（認証トークン）を要求する。

〔ステップＳ１７〕認可サーバ１０は、チケットを受信すると、チケットの正当性を検証し、正当なチケットの場合は、リソースサーバ２０と通信を行って、個人データの利用許可判定処理を実行する（詳細フローは後述）。

〔ステップＳ１８〕認可サーバ１０は、利用許可判定処理で取得した個人データとトークンとを関連付け、そのトークンをクライアントサーバ３０に送信する。
〔ステップＳ１９〕クライアントサーバ３０は、認可サーバ１０から送信されたトークンをリソースサーバ２０へ送信して、そのトークンで個人データを要求する。

〔ステップＳ２０〕リソースサーバ２０は、クライアントサーバ３０から送信されたトークンの正当性を検証するため、認可サーバ１０へトークンを送信する。
〔ステップＳ２１〕認可サーバ１０は、リソースサーバ２０から送信されたトークンを受信すると、トークンの正当性を検証し、トークンが正当な場合、そのトークンに関連付けられている個人データをリソースサーバ２０へ送信する。

〔ステップＳ２２〕リソースサーバ２０は、認可サーバ１０から送信された個人データを受信し、クライアントサーバ３０に対して個人データを送信する。なお、個人データとしては、例えば、ＩＤリスト（個人の属性およびフィルタ情報を満たすデータ等から構成される情報）がある。

＜フィルタ処理＞
次に認可サーバ１０およびリソースサーバ２０で行われるフィルタ処理について説明する。データ利用エンティティ３ａが要求した個人データ（ＩＤリスト）を取得する場合、認可サーバ１０がリソースサーバ２０にフィルタ情報を送信して、リソースサーバ２０にフィルタ処理を実施させることができる。または、認可サーバ１０とリソースサーバ２０との間でフィルタ情報の授受を行って、フィルタ処理を分担して実施することができる。

なお、個人の属性情報（年齢等）に関するデータ抽出は認可サーバ１０で行われ、個人の属性情報の抽出以外のフィルタ処理は認可サーバ１０またはリソースサーバ２０で行われる。また、フィルタ処理の最終結果は、認可サーバ１０が取得する。

（フィルタ処理の例１）
認可サーバ１０は、リソースサーバ２０へフィルタ情報を送信し、フィルタ情報を含むＩＤリストを要求する。例えば、認可サーバ１０は、場所＝都内、日付＝２月１日というフィルタ情報をリソースサーバ２０へ送信する。

リソースサーバ２０は、認可サーバ１０から送信されたフィルタ情報を受信すると、自身が有するＩＤのうちから、受信したフィルタ情報を含むＩＤを抽出するフィルタ処理を行って該当するＩＤリストを返送する。

例えば、リソースサーバ２０は、場所＝都内および日付＝２月１日のフィルタ情報にもとづくフィルタ処理によって、ＩＤ＝［１００、１０１、１０３、１０５］を抽出した場合、ＩＤ＝［１００、１０１、１０３、１０５］を認可サーバ１０へ返送する。

認可サーバ１０は、返送されたＩＤリストを受信すると、そのＩＤリストのうちから所定の属性情報を有するＩＤを抽出する。例えば、認可サーバ１０は、ＩＤ＝［１００、１０１、１０３、１０５］のうちから年齢＝３０代の属性情報を有するＩＤ＝［１０１、１０５］を抽出する。

このような処理によって、場所＝都内、日付＝２月１日および年齢＝３０代の個人データの抽出結果として、ＩＤ＝［１０１、１０５］が認可サーバ１０で取得されることになる。

（フィルタ処理の例２）
認可サーバ１０は、自身が有するＩＤのうちから、属性情報およびフィルタ情報を含むＩＤを抽出する。そして、認可サーバ１０は、抽出結果であるＩＤリストと、リソースサーバ２０でフィルタ処理を実行させる際のフィルタ情報とをリソースサーバ２０へ送信する。

例えば、認可サーバ１０は、ＩＤ＝［１０１、１０５、１０６、１０７、１０８］のうちから年齢＝３０代のＩＤ＝［１０１、１０５、１０７、１０８］を抽出し、さらに場所＝都内のフィルタ処理を行ってＩＤ＝［１０１、１０５、１０８］を抽出する。そして、認可サーバ１０は、ＩＤ＝［１０１、１０５、１０８］と、日付＝２月１日のフィルタ情報とをリソースサーバ２０へ送信する。

リソースサーバ２０は、認可サーバ１０から送信されたＩＤリストと、フィルタ情報とを受信すると、該ＩＤリストのうちから該フィルタ情報を含むＩＤを抽出するフィルタ処理を行って、その結果を認可サーバ１０へ返送する。

この場合、リソースサーバ２０は、ＩＤ＝［１０１、１０５、１０８］のうちから日付＝２月１日のフィルタ情報を含むＩＤ＝［１０１、１０５］を抽出する。そして、リソースサーバ２０は、ＩＤ＝［１０１、１０５］を認可サーバ１０へ返送する。

このような処理によって、場所＝都内、日付＝２月１日および年齢＝３０代の個人データの抽出結果として、ＩＤ＝［１０１、１０５］が認可サーバ１０で取得されることになる。

フィルタ処理の例２の場合、認可サーバ１０とリソースサーバ２０とがフィルタ情報の授受を行って、互いに連携しながらフィルタ処理を分担して行うことにより、どちらか一方に負荷が偏ることなく負荷を分散させてフィルタ処理を実行することができる。なお、フィルタ処理の例１のように、すべてのフィルタ処理をリソースサーバ２０に実施させることで認可サーバ１０の処理負荷の軽減を図ることもできる。

＜個人データ利用許可の判定処理＞
図８は個人データ利用許可の判定処理の動作の一例を示すフローチャートである。図７のステップＳ１７の詳細フローを示している。

〔ステップＳ３１〕認可サーバ１０内の制御部１１は、リソースサーバ２０から送信されたチケットを受信すると、チケットの正当性を検証する。
〔ステップＳ３２〕制御部１１は、判定指標にもとづいて、利用許可判定処理のうち同意確認処理とフィルタ処理のいずれを先に行うかを判定する。同意確認処理を先にフィルタ処理を後に行ってデータを絞り込む場合はステップＳ３３ａへ処理が進み、フィルタ処理を先に同意確認処理を後に行ってデータを絞り込む場合はステップＳ３３ｂへ処理が進む。

〔ステップＳ３３ａ〕制御部１１は、属性情報にもとづいて個人データの同意確認処理を行う。同意確認済みの場合はステップＳ３４ａへ処理が進み、不同意の場合はステップＳ３５ａへ処理が進む。

〔ステップＳ３４ａ〕制御部１１は、同意確認済みのデータに対してリソースサーバ２０と連携してフィルタ処理を行う。ステップＳ３６へ処理が進む。
〔ステップＳ３５ａ〕制御部１１は、不同意のユーザをＩＤリストから削除する。ステップＳ３６へ処理が進む。

〔ステップＳ３３ｂ〕制御部１１は、リソースサーバ２０と連携してフィルタ処理を行う。
〔ステップＳ３４ｂ〕制御部１１は、フィルタ処理で抽出したデータに対して同意確認処理を行う。同意確認済みの場合はステップＳ３６へ処理が進み、不同意の場合はステップＳ３５ｂへ処理が進む。

〔ステップＳ３５ｂ〕制御部１１は、不同意のユーザをＩＤリストから削除する。ステップＳ３６へ処理が進む。
〔ステップＳ３６〕制御部１１は、ポリシが登録されている場合、登録ポリシのマッチング処理を行って登録ポリシに該当するデータを削除する。

〔ステップＳ３７〕制御部１１は、ＩＤリストを抽出し、トークンを発行する。
図９は絞り込み動作の一例を示すフローチャートである。なお、データ利用エンティティ３ａは、３０代で２０１８年の積雪日に都内で運転した人の運転データを要求するものとする。

〔ステップＳ４０〕認可サーバ１０は、自身が有する辞書テーブルを参照して、個人の属性情報（この例では「年齢＝３０代」）にもとづき同意確認処理を行った場合の同意確認処理絞り込み効果と、フィルタ情報（この例では「２０１８年の積雪日」）にもとづきフィルタ処理を行った場合のフィルタ処理絞り込み効果とを検索する。

フィルタ処理絞り込み効果の方が同意確認処理絞り込み効果よりも高い場合はステップＳ４１へ処理が進み、同意確認処理絞り込み効果の方がフィルタ処理絞り込み効果よりも高い場合はステップＳ４６へ処理が進む。

〔ステップＳ４１〕認可サーバ１０は、同意確認処理よりもフィルタ処理を先に実行する。すなわち、認可サーバ１０は、フィルタ情報「２０１８年の積雪日」をリソースサーバ２０へ送信し、フィルタ情報「２０１８年の積雪日」を含むＩＤのリストを要求する。

〔ステップＳ４２〕リソースサーバ２０は、認可サーバ１０から送信されたフィルタ情報「２０１８年の積雪日」を受信すると、自身が有するＩＤのうちから、フィルタ情報「２０１８年の積雪日」を含むＩＤを抽出するフィルタ処理を行って該当するＩＤのリストを返送する。

〔ステップＳ４３〕認可サーバ１０は、返送されたＩＤのリストを受信すると、そのリストのうちから属性情報「年齢＝３０代」のＩＤを抽出する。すなわち、属性情報「年齢＝３０代」かつフィルタ情報「２０１８年の積雪日」を含むＩＤリストが抽出される。

〔ステップＳ４４〕認可サーバ１０は、ステップＳ４３で抽出したＩＤリストに該当する各ユーザの同意確認処理を行う。
〔ステップＳ４５〕認可サーバ１０は、ユーザの同意確認が取れたＩＤリストを抽出する。なお、ここでのＩＤリストは、フィルタ情報「年齢＝３０代」、「２０１８年の積雪日」を含み、同意確認も取れているものである。認可サーバ１０は、このＩＤリストにトークンを関連付ける。なお、ＩＤリストは、図７に示したように、認可サーバ１０からリソースサーバ２０へ送信され、リソースサーバ２０からクライアントサーバ３０へ送信される。

〔ステップＳ４６〕認可サーバ１０は、フィルタ処理よりも同意確認処理を先に実行する。すなわち、認可サーバ１０は、属性情報「年齢＝３０代」のユーザの同意確認処理を行って同意確認が取れたＩＤリストを抽出する。

〔ステップＳ４７〕認可サーバ１０は、同意確認が取れたＩＤリストおよびフィルタ情報「２０１８年の積雪日」をリソースサーバ２０へ送信する。
〔ステップＳ４８〕リソースサーバ２０は、認可サーバ１０から送信されたＩＤリストおよびフィルタ情報「２０１８年の積雪日」を受信すると、フィルタ情報「２０１８年の積雪日」を含むＩＤを抽出するフィルタ処理を行って該当するＩＤのリストを返送する。

〔ステップＳ４９〕認可サーバ１０は、返送されたＩＤのリストを受信する。ここでのＩＤリストは、フィルタ情報「年齢＝３０代」、「２０１８年の積雪日」を含み、同意確認も取れているものである。認可サーバ１０は、このＩＤリストにトークンを関連付ける。なお、ＩＤリストは、図７に示したように、認可サーバ１０からリソースサーバ２０へ送信され、リソースサーバ２０からクライアントサーバ３０へ送信される。

＜辞書テーブル＞
次に辞書テーブルの構成例について図１０、図１１を用いて説明する。図１０は辞書テーブルの一例を示す図である。辞書テーブル１２ａ−１は、項目として、属性、個人データ数および効率値を有する。属性情報は個人の属性であり例えば、年齢である。個人データ数は、該属性を有する個人データの数である。

効率値は、同意確認処理がフィルタ処理よりも先に行われた場合に、同意確認処理によって個人データが、リソースサーバ２０が保有するデータ群のうちから絞り込まれるときの絞り込み処理の効率を数値化したものである。効率値は、例えば、過去の履歴にもとづいて、認可サーバ１０、リソースサーバ２０またはクライアントサーバ３０（の運用管理者）のいずれかで適宜設定することができる。

ここで、認可サーバ１０は、クライアントサーバ３０から年齢＝３０代の属性を含むデータ要求を受信したとする。例えば、認可サーバ１０は、年齢＝３０代のデータが５万件あることを認識した場合、年齢＝３０代の属性と５万件の個人データ数とで辞書テーブル１２ａ−１を検索して効率値ａを取得する。

認可サーバ１０は、取得した効率値ａを判定指標とし、あらかじめ設定している閾値（閾値Ｔｈとする）と比較する。このとき、認可サーバ１０は、ａ＜Ｔｈの場合、フィルタ処理を先に行って同意確認処理を後に行うと判定し、Ｔｈ≦ａの場合、同意確認処理を先に行ってフィルタ処理を後に行うと判定する。

このように、認可サーバ１０では、属性と該属性を有する個人データの数とに関連付けて効率値が設定されている辞書テーブルを参照して取得した効率値を判定指標とする。これにより、同意確認処理とフィルタ処理との実行順序として、処理効率が高い方の実行順序を適切かつ容易に決定することが可能になる。

図１１は辞書テーブルの一例を示す図である。辞書テーブル１２ａ−２は、項目として、クライアント要求情報および実行順序（フィルタ処理優先）を有する。クライアント要求情報には、例えば、年齢等の属性情報、また都道府県や日付等のフィルタ情報が記載される。

実行順序は、同意確認処理およびフィルタ処理のいずれを先に実行するかの順序を示す情報が記載される。図１１の例では、フィルタ処理を同意確認処理よりも先に行うか否かの情報が記載されており、例えば、Ｔｒｕｅの場合はフィルタ処理を同意確認処理よりも先に実行し、Ｆａｌｓｅの場合は同意確認処理をフィルタ処理よりも先に実行する。

辞書テーブル１２ａ−２のエントリＬ１において、居住都道府県の指定が全国であり、フィルタ情報で抽出する際の条件式が示されている（“residential prefecture”=“ALL” AND q＿rs＿subexpr）。この場合、実行順序としてフィルタ処理優先はＴｒｕｅとなっており、フィルタ処理を同意確認処理よりも先に行うことが判定される。

エントリＬ２において、年齢指定が８０歳以上と示されている（“age”≧［89］［0-9］）。この場合、実行順序としてフィルタ処理優先はＦａｌｓｅとなっており、同意確認処理をフィルタ処理よりも先に行うことが判定される。

エントリＬ３において、データエントリの日付指定が示されている（“date”）。この場合、実行順序としてフィルタ処理優先はＴｒｕｅとなっており、フィルタ処理を同意確認処理よりも先に行うことが判定される。

エントリＬ４において、データエントリの種類が「通常」と指定されている（“data＿type”=“normal”）。この場合、実行順序としてフィルタ処理優先はＦａｌｓｅとなっており、同意確認処理をフィルタ処理よりも先に行うことが判定される（特殊エントリは少ないと想定でき同意確認処理を先に実行した方が効果は高いと推定される）。なお、クライアント要求情報と実行順序との対応関係は、例えば、過去の履歴にもとづいて、認可サーバ１０、リソースサーバ２０またはクライアントサーバ３０（の運用管理者）のいずれかで適宜設定することができる。

このように、認可サーバ１０では、属性またはフィルタ情報を含むクライアント要求情報と、クライアント要求情報に関連付けた実行順序とを対応させた辞書テーブルを参照し、クライアント要求情報を判定指標にして辞書テーブルから実行順序を検出する。これにより、同意確認処理とフィルタ処理との実行順序として、処理効率が高い方の実行順序を適切かつ容易に決定することが可能になる。なお、辞書テーブル１２ａの他の例としては以下のようなものがある。

認可サーバ１０は、属性情報・フィルタ情報の条件式と、その条件式を過去に適用したときの結果とを辞書テーブルに記憶する。そして、結果と閾値とを比較して、結果が閾値よりも低い場合はフィルタ処理を先に行う。

例えば、条件式として、（年齢＝５０代）∧（積雪日に運転記録あり）であり、この条件式を過去に適用した場合、年齢＝５０代では１００万件が１０万件に絞られ、積雪日に運転記録ありで１０万件から１００件に絞られたとする。この結果は１００件であり、閾値を２００とした場合、結果が閾値よりも低いのでフィルタ処理を同意確認処理よりも先に行うことになる。この場合、フィルタ処理後の１００件に対して同意確認処理が行われるため、フィルタ処理を先に行って１００件に絞ってから同意確認処理を行った方が、処理効率が高くなる。

＜辞書テーブル以外の判定指標＞
上記では、辞書テーブルを使用して実行順序を決定する場合について説明したが、以降の図１２、図１３では、辞書テーブルを使用せずに判定する場合の例を示している。

図１２は辞書テーブル以外の判定指標にもとづいて実行順序を決定する動作の一例を示すフローチャートである。
〔ステップＳ５１〕認可サーバ１０は、クライアントサーバ３０が要求する属性を有する個人データをリソースサーバ２０が保有するデータ群から抽出する。

〔ステップＳ５２〕認可サーバ１０は、抽出した個人データの数を判定指標とする。
〔ステップＳ５３〕認可サーバ１０は、抽出した個人データの数と閾値とを比較する。個人データ数が閾値以上の場合はステップＳ５４へ処理が進み、個人データ数が閾値未満の場合はステップＳ５５へ処理が進む。

〔ステップＳ５４〕認可サーバ１０は、フィルタ処理を先に行って同意確認処理を後に行う。
〔ステップＳ５５〕認可サーバ１０は、同意確認処理を先に行ってフィルタ処理を後に行う。

例えば、データ群のデータ総数が１００００件あり、クライアントから要求される属性を３０代とし、１００００件の中から３０代の個人データが１０００件抽出されたとする。閾値＝４０００とした場合、個人データ数は閾値未満となる。したがって、この場合は、認可サーバ１０は、同意確認処理を先に行ってフィルタ処理を後に行う実行順序を決定する。

このように、認可サーバ１０は、クライアントが要求する属性を有する個人データをデータ群から抽出し、個人データの数を判定指標にして閾値と比較して実行順序を決定する。これにより、同意確認処理とフィルタ処理との実行順序として、処理効率が高い方の実行順序を適切かつ容易に決定することが可能になる。

図１３は辞書テーブル以外の判定指標にもとづいて実行順序を決定する動作の一例を示すフローチャートである。
〔ステップＳ６１〕認可サーバ１０は、属性情報およびフィルタ情報を受信する。

〔ステップＳ６２〕認可サーバ１０は、属性情報またはフィルタ情報に判定指標となるフラグが付加されているか否かを確認する。属性情報にフラグが付加されている場合はステップＳ６３へ処理が進み、フィルタ情報にフラグが付加されている場合はステップＳ６４へ処理が進む。

〔ステップＳ６３〕認可サーバ１０は、同意確認処理を先に行ってフィルタ処理を後に行う。
〔ステップＳ６４〕認可サーバ１０は、フィルタ処理を先に行って同意確認処理を後に行う。

例えば、３０代の属性情報と２月１日のフィルタ情報を満たす個人データが要求された際に、３０代の属性情報にフラグが設定されている場合、認可サーバ１０は、同意確認処理を先に行いフィルタ処理を後に行う。また、２月１日のフィルタ情報にフラグが設定されている場合、認可サーバ１０は、フィルタ処理を先に行い同意確認処理を後に行う。なお、フラグ設定は、例えば、過去の履歴にもとづいて、認可サーバ１０、リソースサーバ２０またはクライアントサーバ３０（の運用管理者）のいずれかで適宜設定することができる。

このように、認可サーバ１０は、属性情報またはフィルタ情報に設定されているフラグにもとづいて実行順序を決定する。これにより、同意確認処理とフィルタ処理との実行順序として、処理効率が高い方の実行順序を適切かつ容易に決定することが可能になる。

上記で説明した本発明のサーバ装置１および認可サーバ１０の処理機能は、コンピュータによって実現することができる。この場合、サーバ装置１および認可サーバ１０が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。

処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等がある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷ等がある。光磁気記録媒体には、ＭＯ（Magneto Optical disk）等がある。

プログラムを流通させる場合、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。

また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。また、上記の処理機能の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤ等の電子回路で実現することもできる。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ サーバ装置
１ａ 制御部
１ｂ 記憶部
２ リソース装置
３ クライアント装置
Ｄ１、・・・、Ｄ４、ｄ１１、・・・、ｄ１４、ｄ２１、・・・、ｄ２４、ｄ３１、・・・、ｄ３４、ｄ４１、・・・、ｄ４４、 個人データ
Ａ、Ｂ、Ｃ、Ｄ 条件

Claims (8)

1. コンピュータに、
   ユーザの個人データが含まれるデータ群のうちから前記個人データのクライアントによる利用要求を受けて、前記クライアントが要求する属性を有する前記個人データの利用許可の同意を確認する同意確認処理と、前記データ群のうちから前記クライアントが要求する条件または前記属性を満たす前記個人データを抽出するフィルタ処理とを行う場合、判定指標にもとづいて前記同意確認処理と前記フィルタ処理との実行順序を決定する、
   処理を実行させるプログラム。
2. 前記処理は、
   前記同意確認処理が前記フィルタ処理よりも先に行われた場合に前記同意確認処理によって前記個人データが前記データ群のうちから絞り込まれるときの絞り込み処理の効率値を含み、前記属性と前記属性を有する前記個人データの数とに関連付けて前記効率値が設定されている辞書テーブルを生成し、
   前記クライアントから要求された前記属性と、前記属性を有する前記個人データの数とで前記辞書テーブルを検索して前記効率値を取得し、
   取得した前記効率値を前記判定指標とし、前記効率値と閾値とを比較して、前記効率値が前記閾値未満の場合に前記フィルタ処理を先に行って前記同意確認処理を後に行い、前記効率値が前記閾値以上の場合に前記同意確認処理を先に行って前記フィルタ処理を後に行う、
   請求項１記載のプログラム。
3. 前記処理は、前記属性または前記条件を含む要求情報と、前記要求情報に関連付けた前記実行順序とを対応させた辞書テーブルを生成し、前記要求情報を前記判定指標にして前記辞書テーブルから前記実行順序を検出する請求項１記載のプログラム。
4. 前記処理は、
   前記クライアントが要求する前記属性を有する前記個人データを前記データ群から抽出し、
   抽出した前記個人データの数を前記判定指標とし、抽出した前記個人データの数と閾値とを比較して、抽出した前記個人データの数が閾値未満の場合に前記同意確認処理を先に行って前記フィルタ処理を後に行い、抽出した前記個人データの数が前記閾値以上の場合に前記フィルタ処理を先に行って前記同意確認処理を後に行う、
   請求項１記載のプログラム。
5. 前記処理は、
   前記属性または前記条件に設定されているフラグを前記判定指標とし、前記属性に前記フラグが設定されている場合に前記同意確認処理を先に行って前記フィルタ処理を後に行い、前記条件に前記フラグが設定されている場合に前記フィルタ処理を先に行って前記同意確認処理を後に行う、
   請求項１記載のプログラム。
6. 前記処理は、前記データ群を保持している装置との間で前記条件を授受し、前記フィルタ処理を前記装置と分担して実行する請求項１記載のプログラム。
7. ユーザの個人データが含まれるデータ群のうちから前記個人データのクライアントによる利用要求にもとづいて、前記クライアントが要求する属性と、前記クライアントが要求する条件と、判定指標とを保持する記憶部と、
   前記属性を有する前記個人データの利用許可の同意を確認する同意確認処理と、前記データ群のうちから前記条件または前記属性を満たす前記個人データを抽出するフィルタ処理とを行う場合、前記判定指標にもとづいて前記同意確認処理と前記フィルタ処理との実行順序を決定する制御部と、
   を有するサーバ装置。
8. コンピュータが、
   ユーザの個人データが含まれるデータ群のうちから前記個人データのクライアントによる利用要求を受けて、前記クライアントが要求する属性を有する前記個人データの利用許可の同意を確認する同意確認処理と、前記データ群のうちから前記クライアントが要求する条件または前記属性を満たす前記個人データを抽出するフィルタ処理とを行う場合、判定指標にもとづいて前記同意確認処理と前記フィルタ処理との実行順序を決定する、
   実行順序決定方法。

Images