JP2023005647A - 個人情報管理システムおよび個人情報管理方法 - Google Patents

Abstract

【課題】直接的な個人情報に関る情報と間接的な個人情報に関る情報に関して、合理的に保護するための判断の指標を与え、個人情報の保護とデータの利活用を両立させる。【解決手段】個人情報管理システムは、個人情報アクセスクライアントとそれにネットワークにより接続された個人情報管理サーバを有する。個人情報アクセスクライアントは、個人情報データベースのテーブルのカラムに対して直接の個人情報の保護種類を指定し、個人情報管理サーバは、テーブルのカラムに対して直接の個人情報の保護種類を指定されたテーブルとの関係データベースにおける紐づき関係に基づいて、各々のテーブルに対する個人情報保護の保護クラスを設定する。また、１：１、多：１などのＲＤＢにおける対応関係、対応に関係するレコード数により、保護クラスを調整する。【選択図】 図１２

Description

本発明は、個人情報管理システムおよび個人情報管理方法に係り、特に、直接的な個人情報に関る情報と間接的な個人情報に関る情報に関して、合理的に保護するための判断の指標を与え、個人情報の保護とデータの利活用を両立させるのに好適な個人情報管理システムおよび個人情報管理方法に関する。

欧州のＧＤＰＲ（General Data Protection Regulation：ＥＵ一般データ保護規則）をはじめ、世界各国で個人情報保護に関する法律が整備されつつある。個人情報の収集、保存、参照・更新等の取扱いを行う事業者は、これらの法律の遵守が必要である。国によって細かな要件のずれは存在するものの、個人情報の定義としては、多くの国で、個人を直接識別できる情報、または、他の情報と組合わせて個人を識別できる情報というようなカテゴリーによって定義されている。前者は、例えば氏名等の情報が該当し、後者は、例えばユーザＩＤ等の情報が該当すると考えられる。個人情報については、個人の一意特定につながる可能性のある情報でも、その特定の処理が複雑等、現実的に困難な場合は、運用上は、個人情報と見なさなくてもよい可能性がある。そのため、直接識別できる情報やそれらを組合わせて識別できる情報は、一律に保護する以外に、個人情報としての認識し易さの度合に応じた保護を行うことが考えられる。

個人情報を保護するためのデータベースとしては、関係データベース（ＲＤＢ：Relational DataBase）が広く利用されている。関係データベースを利用したシステムにおいて、ある情報と関係性のある情報の発見を容易にする公知技術としては、例えば、特許文献１がある。この特許文献１によれば、データベース内のレコード間の関係が表示され、あるレコードを選択すると、それと関連のあるレコードのリストが表示される。このようにシステムがＲＤＢのデータを速やかにユーザに表示することにより、ユーザは、データベースのレコードを一つずつブラウジングする手間を省くことができるとしている。

また、個人情報とそれと関連する情報の取扱いを異ならせる技術については、特許文献２に記載がある。特許文献２のシステムでは、個人を特定するための情報を省略して個人情報を関連付けて記憶した個人情報データベースと、個人と連絡先情報を関連付けた連絡先情報データベースを保有する。

特開２００１－３１８８１６号公報 特開２０１７－４９９５８号公報

特許文献１は、単純にＲＤＢ上におけるデータつながりの有無だけを見るようにしているため、個人情報とそれに関連する情報の保護のための判断の指標を与えることについては、記載されていない。というのも、例えばユーザグループとそれに所属するユーザの関係のように、大枠のエンティティ自体は固定であるが、関係性が１対多や１対１にもなり得るようなものにおいて、つながり先に対する適格な判断（つながりがあっても関係しないと見なす、あるいは、つながりがあるので関係すると見なす）を行うことができないためである。この例では、ユーザグループに複数人が所属する場合は、ユーザグループの情報からユーザを一意に識別できないため、状況により、必ずしも個人情報としての保護が必要ではないこともあり得るが、ユーザグループに１人しか所属しない場合は、ユーザグループは実質的にユーザと等価とみなすことができるため、ユーザグループの情報からユーザを識別し得ることになり、個人情報としての保護が必要になる可能性がある。特許文献１の記載されたシステムでは、システムの利用者は、このような判断を行うことができず、ユーザとつながりのあるユーザグループを一律に関係があると見なしてしまう。

また、特許文献２に記載された技術は、個人を特定できない個人情報と、連絡先情報データベースを別々に保管することにより、個人情報の大量流出をさけることができるとしているが、個人を特定できる情報と、それに紐付けられた様々な間接的な情報の保護についての明確な指標を与えることについては記載されていない。

本発明の目的は、直接的な個人情報に関る情報と間接的な個人情報に関る情報に関して、合理的に保護するための判断の指標を与え、個人情報の保護とデータの利活用を両立させることのできる個人情報管理システムおよび個人情報管理方法を提供することにある。

本発明の個人情報管理システムの構成は、好ましくは、個人情報アクセスクライアントと、個人情報アクセスクライアントとネットワークにより接続された個人情報データベースを保持する個人情報管理サーバとを有し、個人情報アクセスクライアントからの要求によって、個人情報管理サーバが、個人情報に関るデータの個人情報保護処理を行う個人情報管理システムであって、個人情報アクセスクライアントは、個人情報データベースのテーブルのカラムに対して直接の個人情報の保護種類を指定し、個人情報管理サーバは、テーブルのカラムに対して直接の個人情報の保護種類を指定されたテーブルとの関係データベースにおける紐づき関係に基づいて、各々のテーブルに対する個人情報保護の保護クラスを設定するようにしたものである。

本発明によれば、直接的な個人情報に関る情報と間接的な個人情報に関る情報に関して、合理的に保護するための判断の指標を与え、個人情報の保護とデータの利活用を両立させることのできる個人情報管理システムおよび個人情報管理方法を提供することができる。

個人情報管理システムの全体構成図である。 個人情報管理サーバのハードウェア・ソフトウェア構成図である。 テーブル定義テーブルの一例を示す図である。 テーブル関係情報テーブルの一例を示す図である。 ＥＲ図の一例を示す図である。 個人情報管理テーブルの一例を示す図である。 保護クラス情報テーブルの一例を示す図である（その一）。 保護クラス情報テーブルの一例を示す図である（その二）。 保護ポリシ管理テーブルの一例を示す図である。 カラムの保護種類として、「直接」の保護を指定されたときに、テーブルに対して、それに伴う保護クラスの設定処理を示すフローチャートである。 参照先テーブルの保護クラス設定処理を示すフローチャートである（その一）。 参照先テーブルの保護クラス設定処理を示すフローチャートである（その二）。 個人情報ＤＢに含まれるテーブルの具体的な紐づき関係の例を示す図である（その一）。 個人情報ＤＢに含まれるテーブルの具体的な紐づき関係の例を示す図である（その二）。 テーブルの紐づき関係とテーブルに付与される保護クラスの具体例を記す図である。 ユーザの個人情報の保護指定を契機とする個人情報管理システムの個人情報の保護処理を示すフローチャートである。 指定された個人情報保護のテーブルと関連テーブルの監視処理を示すフローチャートである。 アラート判定処理を示すフローチャートである。 個人情報の移転リクエストがあったときの処理の一例を示すフローチャートである。

以下、本発明に係る一実施形態を、図１ないし図１６を用いて説明する。

先ず、図１および図２を用いて本発明の一実施形態に係る個人情報管理システムの構成について説明する。

個人情報管理システムは、図１に示されるように、一つ以上の個人情報管理サーバ１００（図１では、１００ａ、１００ｂ、…と表記）と、個人情報アクセスクライアント１０が、ネットワーク５により接続された形態である。ネットワーク５は、ＬＡＮ（Local Network）でもよいし、インターネットのようなグルーバルネットワークであってもよい。

個人情報管理サーバ１００は、個人情報に関するデータベースを保持しており、個人情報アクセスクライアント１０からの処理の要請に対して応答し、個人情報の保護の観点から許される場合のみ処理を許可して、要請された処理を行う。

個人情報管理サーバ１００は、クライアント連携部１０１、個人情報管理部１０２、関連テーブル抽出部１０３、保護処理実行部１０４、保護ポリシ管理部１０５、個人情報ＤＢアクセス部１０６、記憶部１１０の機能構成部からなる。

クライアント連携部１０１は、個人情報アクセスクライアント１０からデータや指令を受け付けて、連携動作を行う機能部である。個人情報管理部１０２は、個人情報アクセスクライアント１０からの要求を受けて、個人情報の種類に関する設定（詳細は後述）や、抽出された個人情報の保護レベル（詳細は後述）等の情報の提示を行う機能部である。関連テーブル抽出部１０３は、個人情報の種類に関する設定や、個人情報アクセスクライアント１０からのテーブル抽出要求等を契機として、個人情報と紐づくテーブルの抽出を行う機能部である。保護処理実行部１０４は、保護対象の個人情報に対して暗号化やアクセス禁止、保管場所の別離等の保護処理を行う機能部である。保護ポリシ管理部１０５は、個人情報アクセスクライアント１０からの要求を受けて、有効にする保護ポリシ（詳細は後述）の変更や、新規追加、削除等の更新を行う機能部である。個人情報ＤＢアクセス部１０６は、個人情報ＤＢ（データベース）にアクセスし、データの読み出し、書込み、設定をする機能部である。記憶部１１０は、個人情報管理サーバ１００で使用されるデータを記憶する機能部である。

記憶部１１０には、テーブル定義テーブル２００、テーブル関係情報テーブル２０１、個人情報管理テーブル２０２、保護クラス情報テーブル２０３、保護ポリシ管理テーブル２０４、個人情報ＤＢ２１０が記憶される。
個人情報ＤＢ２１０は、個人情報に関するテーブルを保持するデータベースである。なお、各テーブルの詳細は、後に説明する。

個人情報アクセスクライアント１０は、個人情報に関する処理の要求や設定をするクライアント端末である。個人情報アクセスクライアント１０は、サーバ連携部１１、入出力部１２の機能構成部からなる。

サーバ連携部１１は、データや指令を個人情報管理サーバ１００に送信し、サーバとの連携を行う機能部である。入出力部１２は、ユーザからデータや指令を入力したり、個人情報管理サーバ１００から受信したデータや設定情報などをユーザに出力する機能部である。

次に、図２を用いて個人情報管理サーバ１００のハードウェア・ソフトウェア構成を説明する。

個人情報管理サーバ１００のハードウェア構成としては、例えば、図２に示されるサーバ装置のような一般的な情報処理装置で実現される。
個人情報管理サーバ１００は、ＣＰＵ（Central Processing Unit）３０２、主記憶装置３０４、ネットワークＩ／Ｆ（InterFace）３０６、表示Ｉ／Ｆ３０８、入出力Ｉ／Ｆ３１０、補助記憶Ｉ／Ｆ３１２が、バスにより結合された形態になっている。

ＣＰＵ３０２は、個人情報管理サーバ１００の各部を制御し、主記憶装置３０４に必要なプログラムをロードして実行する。
主記憶装置３０４は、通常、ＲＡＭなどの揮発メモリで構成され、ＣＰＵ３０２が実行するプログラム、参照するデータが記憶される。

ネットワークＩ／Ｆ３０６は、ネットワーク５と接続するためのインタフェースである。

表示Ｉ／Ｆ３０８は、ＬＣＤ（Liquid Crystal Display）などの表示装置３２０を接続するためのインタフェースである。

入出力Ｉ／Ｆ３１０は、入出力装置を接続するためのインタフェースである。図２の例では、キーボード３３０とポインティングデバイスのマウス３３２が接続されている。

補助記憶Ｉ／Ｆ３１２は、ＨＤＤ（Hard Disk Drive）３５０やＳＳＤ（Solid State Drive）などの補助記憶装置を接続するためのインタフェースである。
ＨＤＤ３５０は、大容量の記憶容量を有しており、本実施形態を実行するためのプログラムが格納されている。個人情報管理サーバ１００には、クライアント連携プログラム３６１、個人情報管理プログラム３６２、関連テーブル抽出プログラム３６３、保護処理実行プログラム３６４、保護ポリシ管理プログラム３６５、個人情報ＤＢアクセスプログラム３６６がインストールされている。

クライアント連携プログラム３６１、個人情報管理プログラム３６２、関連テーブル抽出プログラム３６３、保護処理実行プログラム３６４、保護ポリシ管理プログラム３６５、個人情報ＤＢアクセスプログラム３６６は、それぞれクライアント連携部１０１、個人情報管理部１０２、関連テーブル抽出部１０３、保護処理実行部１０４、保護ポリシ管理部１０５、個人情報ＤＢアクセス部１０６の機能を実行するためのプログラムである。

また、ＨＤＤ３５０は、テーブル定義テーブル２００、テーブル関係情報テーブル２０１、個人情報管理テーブル２０２、保護クラス情報テーブル２０３、保護ポリシ管理テーブル２０４、個人情報ＤＢ２１０を格納する。

次に、図３ないし図８を用いて本実施形態の個人情報管理システムで使用されるデータ構造について説明する。

テーブル定義テーブル２００は、個人情報管理サーバ１００が保有する個人情報ＤＢ２１０で使用されているテーブルを定義する情報を格納するテーブルであり、データベース内に存在するテーブルおよびそのカラム構成の把握を可能ならしめるテーブルである。

テーブル定義テーブル２００は、個人情報を格納する個人情報ＤＢ２１０のテーブルに関する構造の定義情報を保持するテーブルであり、図３に示されるように、テーブルカラムＩＤ２００ａ、テーブル名２００ｂ、カラム名２００ｃ、カラムタイプ２００ｄ、リンク先２００ｅの各カラムから構成される。

テーブルカラムＩＤ２００ａには、このレコードの格納情報を一意に識別するＩＤが格納される。テーブル名２００ｂには、定義に関する個人情報ＤＢ２１０のテーブルの名称が格納される。カラム名２００ｃには、定義に関するテーブルにおけるカラムの名称が格納される。カラムタイプ２００ｄには、該当するカラムのタイプが格納される。例えば、ＲＤＢにおける概念を使用して、主キー（レコードの一意識別に使用されるキー）、外部キー（他のテーブルのカラムの参照に使用されるキー）、ユニークキー（他のレコードとの値の重複が許されない（主キーは、テーブルの中に一つのみ定義されるが、ユニークキーは、複数定義されることもあり得る））などのカラムのタイプが格納される。リンク先２００ｅには、当該カラムが、主キー、外部キー、ユニークキー等のタイプに該当するとき、そのカラムの値によって他のテーブルのカラムを参照する際に、その参照先のカラムのテーブルカラムＩＤ２００ａの値が格納される。

テーブル関係情報テーブル２０１は、テーブル定義テーブル２００に定義されたテーブルの参照、被参照の関係に関する情報を格納するためのテーブルであり、図４に示されように、テーブル関係ＩＤ２０１ａ、参照元テーブル名２０１ｂ、参照先テーブル名２０１ｃ、紐づき関係２０１ｄ、紐付きカラム２０１ｅの各カラムから構成される。

テーブル関係ＩＤ２０１ａには、このレコードの格納情報を一意に識別するＩＤが格納される。参照元テーブル名２０１ｂには、紐づけ関係において参照元となる該当するテーブルの名称が格納される。参照先テーブル名２０１ｃには、紐づけ関係において参照元テーブル名２０１ｂのテーブルが参照している参照先のテーブルの名称が格納される。紐づき関係２０１ｄには、参照元テーブル名２０１ｂのテーブルと、参照先テーブル名２０１ｃのテーブルの参照関係が、１対１、１対多、多対１、多対多のいずれかであるか（詳細は、後述）を示す情報が格納される。紐づきカラム２０１ｅには、このレコードの示す対応関係で、参照している方のカラムを示すテーブル定義テーブル２００におけるテーブルカラムＩＤ２００ａが格納される。例えば、テーブル関係ＩＤ２０１ａの値が「１」の紐づき関係については、テーブル名「ユーザ」の「所属グループＩＤ」のカラムによって、テーブル名「グループ」の「グループＩＤ」のカラム（テーブルカラムＩＤの値は、「２－１」）の値を格納することにより紐づいていることを示している。

ここで、図５を用いて紐づき関係の具体例について説明する。
図５は、いわゆるＥＲ図（Entity Relationship Diagram）で本実施形態のモデルとするＲＤＢのテーブルの関係を図示したものである。ＥＲ図とは、「エンティティ＝モノ」と「リレーションシップ＝関係」の組み合わせにより、システムのデータやデータ間の処理構造を示す図である。

この例では、ユーザテーブルとデバイステーブルは、デバイスＩＤを介して１対１で紐づいている。これは一つのユーザＩＤには、一つのデバイスＩＤのみが紐づくことを意味する。一方で、ユーザテーブルとパスワード履歴テーブルは１対多で紐づいている。これは一つのユーザＩＤに複数のシーケンスＩＤが紐づく、すなわち、一人のユーザが複数の旧パスワードを保有し得ることを意味する。また、ユーザテーブルとグループテーブルは、多対１で紐づいている。これは一つのユーザＩＤには、一つのグループＩＤにのみ紐づくが、多数のユーザが同じグループに属する可能性があることを意味している。

個人情報管理テーブル２０２は、個人情報を管理するための情報を保持するためのテーブルであり、図６に示されるように、個人情報ＩＤ２０２ａ、テーブル名２０２ｂ、カラム名２０２ｃ、保護種類２０２ｄ、段数２０２ｅ、保護レベル２０２ｆの各カラムから構成される。

個人情報ＩＤ２０２ａには、このレコードの格納情報を一意に識別するＩＤが格納される。テーブル名２０２ｂには、該当するテーブルの名称が格納される。カラム名２０２ｃには、テーブル名２０２ｂのテーブルの該当するカラムが格納される。保護種類２０２ｄには、個人情報として保護の種類が格納される。例えば、保護種類２０２ｄの値が「直接」であれば、当該カラムによって直接個人を特定し得る情報（氏名等）であることを示し、「間接」であれば、当該カラムは他のカラムとの組み合わせによって個人を特定し得る可能性がある間接的な個人情報であることを示している。段数２０２ｅには、そのカラムが紐づき関係において、「直接」と指定されたカラムからどれほど隔たっているかの情報が格納される。例えば、そのカラムが「直接」と指定されたカラムである、または、「直接」と指定されたカラムと同じテーブルに属するときには、段数２０２ｅに「０」が格納され、そのカラムが段数「０」のカラムを有するテーブルと紐づき関係にあるときは、段数２０２ｅに「１」が格納される。

以下、同様に、そのカラムが段数「ｉ」（ｉ≧０なる整数）のカラムを有するテーブルと紐づき関係にあるときは、段数２０２ｅに「ｉ＋１」が格納される。保護レベル２０２ｆには、該当するカラムの個人情報保護における保護のレベルが格納される。本実施形態の例では、値が小さいものを保護レベルが強いものとし、例えば、段数４０５の値が「０」のカラムは、保護レベル「１」が設定され、そのカラムの情報は、強い保護、例えば強度の高い暗号化の実施や厳密なアクセス制御やログ取得等が施されるのに対し、段数４０５の値が「１」以上のカラムについては、その段数に応じて、保護レベルの値が「２、３、…」と設定され、保護レベルの値が大きくなるにつれて、ゆるい保護、例えば、個人情報保護システムにおいて、簡易なアクセス制御のみを行う等の設定が施される。なお、上記の保護情報の設定の仕方は一例であり、他にも保管場所を隔離する、二段階認証等の高度な認証を採用する等、様々な方法が存在し得る。

保護クラス情報テーブル２０３（タイプＩ）は、テーブルに対しての本システムで設定された保護クラスに関する情報を格納するテーブルであり、図７Ａに示されるように、保護クラスＩＤ２０３ａ、テーブル名２０３ｂ、保護クラス２０３ｃ、段数２０３ｄ、起点テーブル名２０３ｅの各カラムから構成される。

保護クラスＩＤ２０３ａには、このレコードの格納情報を一意に識別するＩＤが格納される。テーブル名２０３ｂには、該当するテーブルの名称が格納される。保護クラス２０３ｃには、個人情報保護システムにおけるが該当するテーブルの保護クラスが格納される。保護クラスとは、個人情報の保護対象となるテーブルごとに定義される情報であり、「ｍｕｓｔ保護」クラスと「ｍａｙ保護」クラスの二種類がある。ｍｕｓｔ保護が設定されるテーブルは、個人情報の保護が必須であることを意味し、ｍａｙ保護クラスが設定されるテーブルは、個人情報の保護については、状況によって保護が必要になる可能性があり、その属する保護クラスの等級に従って、個人情報の保護をすることを意味する。保護クラスの保護の強度としては、ｍｕｓｔ保護＞ｍａｙ１保護＞ｍａｙ２保護＞ｍａｙ３保護＞…とする。

本実施形態では、後に説明するように、保護種類として「直接」を指定されたカラムを有するテーブルの保護クラスは、「ｍｕｓｔ保護」となり、参照先のテーブルの保護クラスは、参照元のテーブルの保護クラスは同じであるか、あるいは、そのテーブルの段数が大きくなるにつれて、参照元のテーブルの保護クラスの強度は弱くなるように設定する。なお、保護クラスの設定の仕方は、後に詳説する。段数２０３ｄには、該当するテーブルが、保護種類が「直接」としたカラムと紐づき関係の段数が格納される。そのようなテーブルが複数あるときには、最小の段数が格納される。起点テーブル名２０３ｅには、段数を算出した紐づき関係の最初のテーブルの名称が格納される。該当するテーブル自体が、「直接」としたカラムがないときには、空欄となる。

保護クラス情報テーブル２０３（タイプＩＩ）は、保護クラス情報テーブル２０３（タイプＩＩ）に加えて、個人情報保護を行うときの時間情報を格納するテーブルであり、図７Ｂに示されるように、保護クラスＩＤ２０３ａ、テーブル名２０３ｂ、保護クラス２０３ｃ、段数２０３ｄ、起点テーブル名２０３ｅ、開始期間２０３ｆ、終了期間２０３ｇ、監視契機２０３ｈの各カラムから構成される。

保護クラスＩＤ２０３ａ、テーブル名２０３ｂ、保護クラス２０３ｃ、段数２０３ｄ、起点テーブル名２０３ｅについては、保護クラス情報テーブル２０３（タイプＩＩ）と同様である。

開始期間２０３ｆ、終了期間２０３ｇには、それぞれ該当するテーブルに対して、テーブルについて個人情報保護を有効とする開始期間と、終了期間が格納される。図７Ｂの例では、日にち単位で設定しているが、より詳細に、分単位、秒単で設定するようにしてもよい。監視契機２０３ｈには、個人情報を監視する契機を示す識別子か文字列が格納される。例えば、監視契機２０３ｈの値が、「１」であれば、定期的な監視を行う、「２」であればリアルタイムにテーブルのデータの変動を監視する、「３」であればユーザからの要求を契機に個人情報の監視を行うことにする。

保護ポリシ管理テーブル２０４は、個人情報管理システムにおいて、何に対してどのように個人情報の保護を行うかのポリシに関する情報を格納するテーブルであり、図８に示されように、保護ポリシＩＤ２０４ａ、保護ポリシ内容２０４ｂ、設定２０４ｃの各カラムから構成される。

保護ポリシＩＤ２０４ａには、このレコードの格納情報を一意に識別するＩＤが格納される。保護ポリシ内容２０４ｂには、このレコードで設定される保護ポリシの具体的な内容が格納される。保護ポリシとは、個人情報管理システムが何に対してどのように個人情報の保護を行うかの具体的な内容を指示する指針となる情報である。例えば、保護種類が「直接」のカラムの個人情報は保護対象とする、ｍｕｓｔ保護クラスの設定されたテーブルの主キーのカラムのデータについては保護対象とする、保護種類が「直接」のカラムからの段数の値が、５未満のテーブルのみ保護する等のポリシである。設定２０４ｃには、このレコードが示す保護ポリシを現在有効とするか否かのフラグが格納され、設定２０４ｃの値が、「ｏｎ」の保護ポリシが適用され、「ｏｆｆ」の保護ポリシが適用されないことを示している。なお、特定の保護ポリシ、例えば、保護ポリシＩＤ２０４ａの値「１」のポリシが有効にならなければ、他のポリシを有効化できない等の制御を行ったり、推奨のポリシセットを提供する等の処理を組込んでもよい。

次に、図９ないし図１６を用いて個人情報管理システムの処理について説明する。

先ず、図９を用いてカラムの保護種類として、「直接」の保護を指定されたときに、テーブルに対して、それに伴う保護クラスの設定処理について説明する。
先ず、ユーザが個人情報アクセスクライアント１０から、個人情報ＤＢ２１０に含まれるテーブルのカラムに対して、保護種類として「直接」を指定したとする。保護種類として「直接」が指定されるカラムの情報は、個人情報に直接に関連し、秘匿性の高い情報であることを意味し、例えば、テーブル名がユーザのテーブルの「氏名」が指定されたとする。
それを受けて、個人情報管理サーバ１００のクライアント連携部１０１は、個人情報アクセスクライアント１０からの「直接」の個人情報の設定の要求を受付ける（Ｓ１０１）。

これにより、個人情報管理部１０２は、指定されたテーブルのカラムの保護種類を「直接」に設定し、指定されたテーブルの保護クラスを「ｍｕｓｔ保護」に設定する（Ｓ１０２）。具体的には、図６に示す個人情報管理テーブル２０２の当該指定されたカラムに対応する保護種類２０２ｄの値が「直接」に設定される。例えば、テーブル名がユーザのテーブルの「氏名」のカラムの情報を「直接」の個人情報とする指定を受けた場合は、該当するレコードにおける保護種類２０２ｄ値が「直接」と設定される。また、図７Ａの保護クラス情報テーブル２０３において、保護クラスＩＤ２０３ａの値「１」のレコードのように、テーブル名２０３ｂに「ユーザ」が登録され、保護クラス２０３ｃのカラムに「ｍｕｓｔ保護」の値が設定される。

次に、Ｔ←（カラムの保護種類を「直接」に設定したテーブル名）、Ｃ←「ｍｕｓｔ保護」とする（Ｓ１０３）。
次に、Ｔの全てのカラムに対して、Ｓ１０５の処理を行う（Ｓ１０４－Ｓ１０７）。
Ｓ１０４－Ｓ１０７のループの中で、図４のテーブル関係情報テーブル２０１を参照し、そのカラムに紐づけカラムがあるときには（Ｓ１０５：ＹＥＳ）、パラメータ（Ｔ，カラム，Ｃ）に対して、参照先テーブルの保護クラス設定処理（Ｔ，カラム，Ｃ）を行う（Ｓ１０６）。参照先テーブルの保護クラス設定処理は、後に詳説する。

Ｓ１０４－Ｓ１０６のループを抜けて、クライアント連携部１０１は、個人情報アクセスクライアント１０に結果（成功ｏｒ失敗）を送信する（Ｓ１０８）。

次に、図１０Ａおよび図１０Ｂを用いて参照先テーブルの保護クラス設定処理について説明する。
これは、図９のＳ１０５に該当する処理である。

先ず、個人情報管理サーバ１００の個人情報管理部１０２は、図４に示したテーブル関係情報テーブル２０１を参照し、パラメータのＴに該当するレコードの被参照テーブル名３０３ｃの値を取得し、Ｔ１←（被参照テーブル名３０３ｃの値）とする（Ｓ２０１）。

次に、Ｃ１←（Ｔ１のテーブルに設定されている保護クラス）とする（Ｓ２０２）なお、Ｔ１のテーブルに設定されている保護クラスが設定されていないとには、Ｃ１←ＮＵＬＬとし、このときの保護クラスの強度は最弱と定義する。
次に、パラメータのＴに該当するレコードの紐づき関係２０１ｄの値を取得する（Ｓ２０３）。

そして、Ｓ２０２で取得した紐づき関係２０１ｄの値により、参照元テーブルと参照先テーブルの対応関係を判定し（Ｓ２０４）、１：１のときには、Ｓ２０５に行き（Ｓ２０４：（１：１））、その他のときには（Ｓ２０４：Ｏｔｈｅｒ）、Ｓ２０７に行く。

参照元テーブルと参照先テーブルの対応関係が１：１のときには、Ｃの保護クラスの強度と、Ｃ１の保護クラスの強度を比較し（Ｓ２０５）、Ｃの保護クラスの強度＞Ｃ１の保護クラスの強度のときには（Ｓ２０５：ＹＥＳ）、Ｃ１←Ｃ、参照先テーブルであるＴ１の保護クラス←Ｃとし（Ｓ２０６）、Ｓ２１１に行く。

参照元テーブルと参照先テーブルの対応関係が１：１以外のときには、参照先テーブルの紐づきカラムの値と同一の値を有する参照元テーブルのレコード数のそれぞれの紐づきカラムの値にわたる最小値が所定の閾値以上であるか否かを判定し（Ｓ２０７）、所定の閾値以上であるときには（Ｓ２０７：ＹＥＳ）、Ｓ２０８に行き、所定の閾値未満であるときには（Ｓ２０７：ＮＯ）、Ｓ２０５に行く。なお、Ｓ２０７の判定条件は、後に具体例により詳説する。

Ｓ２０７で所定の閾値以上のときには、Ｃ２←（Ｃより強度の弱い保護クラス）とする。例えば、Ｃ＝「ｍｕｓｔ保護」ときには、Ｃ２＝「ｍａｙ１保護」、Ｃ＝「ｍａｙ１保護」ときには、Ｃ２＝「ｍａｙ２保護」とする。

次に、Ｃ２の保護クラスの強度と、Ｃ１の保護クラスの強度を比較し（Ｓ２０５）、Ｃ２の保護クラスの強度＞Ｃ１の保護クラスの強度のときには（Ｓ２０９：ＹＥＳ）、Ｃ１←Ｃ２、参照先テーブルであるＴ１の保護クラス←Ｃ２とし（Ｓ２１０）、Ｓ２１１に行く。

次に、Ｔ１の全てのカラムに対して、Ｓ２１２の処理を行う（Ｓ２１１－Ｓ２１４）。
Ｓ２１１－Ｓ２１４のループの中で、図４のテーブル関係情報テーブル２０１を参照し、そのカラムに紐づけカラムがあるときには（Ｓ２１２：ＹＥＳ）、パラメータ（Ｔ１，カラム，Ｃ１）に対して、参照先テーブルの保護クラス設定処理（Ｔ１，カラム，Ｃ１）を行う（Ｓ２１３）。この参照先テーブルの保護クラス設定処理は、再帰処理呼出になっていることに留意する。

次に、図１１Ａおよび図１１Ｂを用いて、Ｓ２０６における判定処理の具体例について説明する。
この例では、参照元テーブルのテーブル名が「ユーザ」であり、参照先テーブルのテーブル名が「グループ」のテーブルである。

「ユーザ」のテーブルの主キーのカラムは、「ユーザＩＤ」であり、外部キーの「所属グループＩＤ」に「グループ」のテーブルのグループＩＤの値が設定されることより、「グループ」のテーブルに紐づけられている。

また、「ユーザ」のテーブルの「氏名」のカラムには、保護種類として「直接」が指定されているとする。

「ユーザ」のテーブルの「所属グループＩＤ」には、一つの値のみ格納が許されているとすると、「ユーザ」のテーブルから見ると、多：１の対応関係になる。

ここで、図１１Ａに示されるように、「ユーザＩＤ」が「Ｕ００１」、「Ｕ００２」、「Ｕ００３」のユーザの「所属グループＩＤ」が全て「Ｇ００１」であり、「ユーザＩＤ」が「Ｕ０１１」、「Ｕ０１２」のユーザの「所属グループＩＤ」が全て「Ｇ００２」となっているとする。

この場合には、「ユーザ」のテーブルの紐づきカラムの値の「Ｇ００１」と同一の値を有する参照元テーブル（「ユーザ」のテーブル）のレコード数は、３であり、「ユーザ」のテーブルの紐づきカラムの値の「Ｇ００２」と同一の値を有する参照元テーブルのレコード数は、２である。

したがって、最小値は、２であり、所定の閾値以上が２とすると、「ユーザ」のテーブルには、「ｍｕｓｔ保護」が設定され、「グループ」のテーブルには、それより保護強度が低い「ｍａｙ１保護」が設定される。

一方、図１１Ｂに示されるように、「ユーザＩＤ」が「Ｕ００４」、「Ｕ００５」、「Ｕ００６」、「Ｕ０２１」、「Ｕ０２２」のユーザの「所属グループＩＤ」が、それぞれ「Ｇ００１」、「Ｇ００２」、「Ｇ００３」、「Ｇ００４」、「Ｇ００５」、であるときには、同じ値を有する参照元テーブル（「ユーザ」のテーブル）のレコード数は、全て１であるため、所定の閾値を２としたときに、所定の閾値未満となる。

そのため、このときには、「グループ」のテーブルにも、「ユーザ」のテーブルと同様の「ｍｕｓｔ保護」が設定される。

すなわち、本実施形態の個人情報管理システムの個人情報の取扱いは、所定の閾値（上の例では、２としたが実際には、個人情報を保護されるための十分大きな数値が望ましい）より、参照元のテーブルが参照先テーブルの関連において、十分に大きなレコード数を有するときには、個人情報の保護は、氏名などの直接の個人情報に比べて、個人情報の保護の保護強度を弱めて扱ってもよいという思想にたつものである。

次に、図１２を用いてテーブルの紐づき関係とテーブルに付与される保護クラスの具体例について説明する。尚、ここでは、保護ポリシＩＤ２０４aの値が「１」、「２」、「３」、「４」のレコードの設定２０４ｃが全て「ｏｎ」になっている場合を例に説明する。
Ｔａｂｌｅ１のカラム１０に保護種類として「直接」が設定されたとする。Ｔａｂｌｅ１の保護クラスは、「ｍｕｓｔ保護」である。

Ｔａｂｌｅ２は、参照先テーブルとして、カラム２１で、Ｔａｂｌｅ１のカラム１１に、１：１で紐づいているとする。このときのＴａｂｌｅ２の保護クラスは、Ｔａｂｌｅ１と同様の「ｍｕｓｔ保護」である。

Ｔａｂｌｅ３は、参照先テーブルとして、カラム３１で、Ｔａｂｌｅ１のカラム１３に、多：１で紐づいており、カラム３１の値と同一の値を有するＴａｂｌｅ１内のレコード数の最小値が所定の閾値未満であるとする。このときのＴａｂｌｅ３の保護クラスは、Ｔａｂｌｅ１と同様の「ｍｕｓｔ保護」である。

Ｔａｂｌｅ４は、参照先テーブルとして、カラム４１で、Ｔａｂｌｅ１のカラム１２に、多：１で紐づいており、カラム４１の値と同一の値を有するＴａｂｌｅ１内のレコード数の最小値が所定の閾値以上であるとする。このときのＴａｂｌｅ４の保護クラスは、Ｔａｂｌｅ１より保護強度が弱い「ｍａｙ１保護」である。

Ｔａｂｌｅ５は、参照先テーブルとして、カラム４２で、Ｔａｂｌｅ４のカラム４２に、１：１で紐づいているとする。このときのＴａｂｌｅ５の保護クラスは、Ｔａｂｌｅ４と同様の「ｍａｙ１保護」である。

Ｔａｂｌｅ６は、参照先テーブルとして、カラム６１で、Ｔａｂｌｅ４のカラム４３に、多：１で紐づいており、カラム６１の値と同一の値を有するＴａｂｌｅ４内レコード数の最小値が所定の閾値以上であるとする。このときのＴａｂｌｅ６の保護クラスは、Ｔａｂｌｅ４より保護強度が弱い「ｍａｙ２保護」である。尚、例えば、保護ポリシＩＤ２０４aの値が「１」、「２」、「３」、「４」のレコードのうち、値が「１」の設定２０４ｃのみ「ｏｎ」になっている場合は、「直接」が設定されたカラムを含むテーブルの参照先テーブルに保護クラスが設定され、「直接」が設定されたカラムまたは、当該カラムを含むテーブルの主キーを外部から参照しているテーブルに保護クラスが設定される。当該カラムを含むテーブルの中の当該カラムでもなく主キーでもないカラムのみ外部から参照しているテーブルには、前述の場合とは異なり、保護クラスは設定されない。

次に、図１３を用いてユーザの個人情報の保護指定を契機とする個人情報管理システムの個人情報の保護処理について説明する。
個人情報管理サーバ１００の保護処理実行部１０４は、個人情報アクセスクライアント１０からの図６の個人情報管理テーブル２０２のカラムに対する保護種類の「直接」の指定の要求や、図７Ａの保護クラス情報テーブル２０３で示した保護クラスの更新や、図８の保護ポリシ管理テーブル２０４の保護ポリシの更新等の要求を契機として、関係するテーブルやカラムの個人情報に関する保護の情報を更新する（Ｓ３０１）。

具体的には、当該要求に関係するテーブルやカラムについて、個人情報管理テーブル２０２の保護レベル２０２ｆや保護クラス情報テーブル２０３の保護クラス２０３ｃの値が更新される。例えば、新規の個人情報の登録する場合であれば、新たな個人情報の保護に関する情報の値が登録される。有効にする保護ポリシ内容２０４ｂの変更であれば、登録済みのカラムの保護レベル２０２ｆの値が、「１」から「２」へ変更されたり、保護クラス情報テーブル２０３の保護クラス２０３ｃの値が「ｍａｙ２保護」から登録なし（保護対象にしない）にするといった変更が行われる。保護処理実行部１０４は、更新したカラムやテーブルについて、更新された個人情報に関する保護の情報に応じた保護処理を実施する（Ｓ３０２）。個人情報に関する保護の情報に応じた保護処理とは、例えば、カラムに対する保護レベルが「１」であれば、そのカラムに格納された情報に対して、強度の高い暗号化の実施や厳密なアクセス制御やログ取得等の強い保護を施すのに対し、保護レベルが「２」であれば、簡易なアクセス制御のみ実施等の緩い保護を施す等である。

なお、上記の保護方法は一例であり、他にも保管場所を隔離する、二段階認証等の高度な認証を採用する等、様々な方法や組合わせが存在し得る。

そして、クライアント連携部１０１は、個人情報アクセスクライアント１０に対して処理結果（成功ＯＲ失敗）を送信する（Ｓ３０３）。

次に、図１４を用いて指定された個人情報保護のテーブルと関連テーブルの監視処理について説明する。
この処理は、指定された個人情報保護のテーブルが参照するテーブルで、ｍａｙ１保護クラスやｍａｙ２保護クラスといった、ｍｕｓｔ保護以外のフラグが設定されたテーブルに対して、個人情報保護を監視するときに有用な処理である。

また、この例では、図７Ｂに示されるように、テーブル監視に関して、開始期間と終了期間が定められているものとする。

先ず、ユーザは、個人情報アクセスクライアント１０から、個人情報保護について監視したいテーブルを指定する。
次に、個人情報管理サーバ１００のクライアント連携部１０１は、監視したいテーブルの指定を個人情報アクセスクライアント１０から受信する（Ｓ４０１）。
次に、Ｔ←（監視したいテーブルのテーブル名）とする（Ｓ４０２）。

次に、個人情報管理サーバ１００の保護処理実行部１０４は、監視期間内であるか否かを判定し（Ｓ４０３）、監視期間内であるときには（Ｓ４０３：ＹＥＳ）、Ｓ４０４に行き、監視期間内でないときには（Ｓ４０３：ＮＯ）、Ｓ４１２に行く。
Ｔの全てのカラムについて、Ｓ４０５－Ｓ４０７、Ｓ４０９－Ｓ４１１の処理を行う（Ｓ４０４－Ｓ４０８）。

Ｓ４０４－Ｓ４０８のループの中で、そのカラムに紐づけカラムがあるときには（Ｓ４０５：ＹＥＳ）、アラート判定処理（Ｔ，カラム）を呼び出す（Ｓ４０６）。アラート判定処理の詳細は、後に説明する。

アラート判定処理でアラート要と判定されたときには（Ｓ４０７：ＹＥＳ）、個人情報アクセスクライアント１０にアラートを通知する（Ｓ４０９）。
そして、個人情報アクセスクライアント１０から保護処理の要求があるか否かを判定し（Ｓ４１０）、保護処理の要求があったときには（Ｓ４１０：ＹＥＳ）、個人情報管理サーバ１００の保護処理実行部１０４は、システム所定の、あるいは、ユーザが指定した保護処理を実施し（Ｓ４１１）、保護処理の要求がなかったときには（Ｓ４１０：ＮＯ）、次のカラムに行く。

なお、監視の契機としては、例えば、図７Ｂの保護クラス情報テーブルの監視契機２０３ｈの値が「１」であれば、月毎等定期的に監視し、値が「２」であればリアルタイムで常時監視し、値が「３」であればユーザからの要求があったときに、随時監視する。定期的な監視やリアルタイムでの監視の場合は、開始期間２０３ｆや終了期間２０３ｇの期間が設定されている場合は、その期間での監視とし、期間終了後はまた新たな保護クラスの設定や監視を行う。

Ｓ４０４－Ｓ４０８のループを抜け、クライアント連携部１０１は、個人情報アクセスクライアント１０に結果（成功ｏｒ失敗）を送信する（Ｓ４１２）。

次に、図１５を用いてアラート判定処理について説明する。
これは、図１４のＳ４０６に該当する処理である。

先ず、参照元テーブル←Ｔとし（Ｓ５０１）、図４のテーブル関係情報テーブル２０１を参照し、カラムについての紐づき関係を判定し（Ｓ５０２）、参照元テーブルと参照先テーブルの関係が、１：１のときには（Ｓ５０２：（１：１））、Ｓ５０３に行き、その他のときは（Ｓ５０２：Ｏｔｈｅｒ）、Ｓ５０４に行く。

参照元テーブルと参照先テーブルの関係が、１：１のときには、アラート判定要をＲｅｔｕｒｎにする（Ｓ５０３）。

参照元テーブルと参照先テーブルの関係が、１：１以外のときには、参照先テーブルの紐づきカラムの値と同一の値を有する参照元テーブルのレコード数のそれぞれの紐づきカラムの値にわたる最小値が所定の閾値以上であるか否かを判定し（Ｓ５０４）、所定の閾値以上であるときには（Ｓ５０４：ＹＥＳ）、アラート判定不要をＲｅｔｕｒｎし（Ｓ５０５）、所定の閾値未満であるときには（Ｓ５０４：ＮＯ）、Ｓ５０３に行く。

なお、以上例では、当該テーブルの個人情報に関する保護を行うかのクライアント問い合わせ結果に基づいて保護を行うことにしたが、それ以外に、アラート通知後に、自動的にシステムが個人情報の保護を行うようにしてもいい。

次に、図１６を用いて個人情報の移転リクエストがあったときの処理について説明する。
個人情報の移転リクエストとは、例えば、図１に示したある個人情報管理サーバ１００ａから別の個人情報管理サーバ１００ｂへ移転する処理である。

ここで、ユーザは、個人情報の移転リクエストに関して、「安全なデータのみ」移転をリクエストできることとする。「安全なデータのみ」移転とは、システムが定めた個人情報に関する保護強度が低い、例えば、図６の個人情報管理テーブル２０２のテーブルのカラムに対する保護レベル２０２ｆの強度が低い（値が大きい）データのみを移転することである。

先ず、個人情報管理サーバ１００のクライアント連携部１０１は、個人情報アクセスクライアント１０から、データの移転要求を受け付ける（Ｓ６０１）。

そして、個人情報管理サーバ１００は、要求内容が「安全なデータのみ」の移転であるか否かを判定する（Ｓ６０２）。「安全なデータのみ」の移転要求の場合には（Ｓ６０２：ＹＥＳ）、個人情報管理サーバ１００は、個人情報ＤＢ２１０のテーブルに格納されているデータの要求されたもののうちで、カラムに付与されている保護レベル（個人情報管理テーブル２０２の保護レベル２０２ｆ）の強度が所定の閾値より低いデータのみを収集し（Ｓ６０３）、収集したデータを個人情報アクセスクライアント１０に返信してデータの移転を行わせる（Ｓ６０４）。なお、データの移転は、クライアント経由で行う以外に、移転先の情報も同時に受け付けて、データの移転要求を受けた個人情報管理サーバ１００が、直接、他の個人情報管理サーバ１００ｂ等にデータを送信して行ってもいい。「安全なデータのみ」の移転要求で無かった場合には（Ｓ６０２：ＮＯ）、個人情報管理サーバ１００は、データの保護レベルによらず要求されたデータを収集し（Ｓ６０４）、収集したデータを個人情報アクセスクライアント１０に返信してデータの移転を行わせる（Ｓ６０４）。

最後に、クライアント連携部１０１は、個人情報アクセスクライアント１０に結果（成功ｏｒ失敗）を送信する（Ｓ６０５）。

以上、本実施形態の個人情報管理システムによれば、個人情報の保護が必要なデータに対して、個人の「氏名」などのように、ユーザが個人情報保護が必須とみなすデータに対して、保護種類として「直接」を指定させる。

そして、保護種類として「直接」の情報を有するテーブルとのＲＤＢの紐づき関係の段数により、テーブルのカラムごとの保護レベルを設定する。また、ＲＤＢの紐づき関係の段数、１：１や多：１などのＲＤＢの紐づき関係の形態、紐づきに関係するテーブルのレコード数により、テーブルに対して保護クラスとして、「ｍｕｓｔ保護」、「ｍａｙ保護」の設定を行なう。

これらによって、本実施形態の個人情報管理システムによれば、個人情報としての識別が困難な情報を含めて、合理的に保護するための判断の指標を与え、個人情報の抽出を容易にし、個人情報の保護とデータの利活用を両立させることができ、個人情報に留意したデータの受渡し等を容易に行えるようになる。

５…ネットワーク、
１０…個人情報アクセスクライアント、１１…サーバ連携部、１２…入出力部、
１００…個人情報管理サーバ、１０１…クライアント連携部、１０２…個人情報管理部、１０３…関連テーブル抽出部、１０４…保護処理実行部、１０５…保護ポリシ管理部、１０６…個人情報ＤＢアクセス部、１１０…記憶部、
２００…テーブル定義テーブル、２０１…テーブル関係情報テーブル、２０２…個人情報管理テーブル、２０３…保護クラス情報テーブル、２０４…保護ポリシ管理テーブル、２１０…個人情報ＤＢ

Claims (12)

1. 個人情報アクセスクライアントと、前記個人情報アクセスクライアントとネットワークにより接続された個人情報データベースを保持する個人情報管理サーバとを有し、前記個人情報アクセスクライアントからの要求によって、前記個人情報管理サーバが、個人情報に関るデータの個人情報保護処理を行う個人情報管理システムであって、
   前記個人情報アクセスクライアントは、前記個人情報データベースのテーブルのカラムに対して直接の個人情報の保護種類を指定し、
   前記個人情報管理サーバは、前記テーブルのカラムに対して直接の個人情報の保護種類を指定されたテーブルとの関係データベースにおける紐づき関係に基づいて、各々のテーブルに対する個人情報保護の保護クラスを設定することを特徴とする個人情報管理システム。
2. 前記保護クラスは、前記テーブルのカラムに対して直接の個人情報の保護種類を指定されたテーブルとの紐づき関係のテーブルの段数から各々のテーブルに対する個人情報の保護の強度を異ならしめることを特徴とする請求項１記載の個人情報管理システム。
3. 前記個人情報管理サーバは、前記テーブルのカラムに対して直接の個人情報の保護種類を指定されたテーブルに対して、保護の強度が一番強い「ｍｕｓｔ保護」を設定し、
   関係データベースにおける参照元テーブルと参照先テーブルの紐づき関係において、前記参照先テーブルは、前記参照元テーブルの保護クラスと同じ保護クラスか、または、前記参照元テーブルの保護クラスよりも保護の強度の弱い保護クラスを設定されることを特徴とする請求項１記載の個人情報管理システム。
4. 前記参照元テーブルと前記参照先テーブルの関係データベースにおける対応関係が１：１のときには、前記参照先テーブルは、前記参照元テーブルの保護クラスと同じ保護クラスが設定され、
   前記参照先テーブルの紐づきカラムの値と同一の値を有する参照先テーブルのレコード数のそれぞれの紐づきカラムの値にわたる最小値が所定の閾値未満のときには、前記参照先テーブルは、前記参照元テーブルの保護クラスと同じ保護クラスが設定され、
   前記参照先テーブルの紐づきカラムの値と同一の値を有する参照元テーブルのレコード数のそれぞれの紐づきカラムの値にわたる最小値が所定の閾値以上であるときには、前記参照先テーブルは、前記参照元テーブルの保護クラスよりも保護の強度の弱い保護クラスを設定されることを特徴とする請求項３記載の個人情報管理システム。
5. 前記個人情報管理サーバは、各々のテーブルに対する保護クラスに対しての個人情報保護の内容を定めた保護ポリシを保持することを特徴とする請求項１記載の個人情報管理システム。
6. 前記個人情報管理サーバは、前記テーブルのカラムに対して個人情報の保護レベルを設定することを特徴とする請求項１記載の個人情報管理システム。
7. 前記個人情報アクセスクライアントは、前記個人情報管理サーバに対して、「安全なデータのみ」の移転要求を受信し、
   前記個人情報管理サーバは、前記テーブルのカラムに対して個人情報の保護レベル示す保護強度の低いカラムのデータのみを移転要求の対象とすることを特徴とする請求項６記載の個人情報管理システム。
8. 個人情報アクセスクライアントと、前記個人情報アクセスクライアントとネットワークにより接続された個人情報データベースを保持する個人情報管理サーバとを有し、前記個人情報アクセスクライアントからの要求によって、前記個人情報管理サーバが、個人情報に関るデータの個人情報保護処理を行う個人情報管理システムであって、
   前記個人情報アクセスクライアントは、前記個人情報データベースのテーブルに対して個人情報に関して監視するテーブルを指定し、
   前記個人情報管理サーバは、前記監視するテーブルを参照元テーブルとした前記監視するテーブルの関係データベースにおける紐づき関係を判定し、
   前記監視するテーブルと前記監視するテーブルの参照先テーブルの関係データベースにおける対応関係が１：１のとき、または、前記参照先テーブルの紐づきカラムの値と同一の値を有する参照先テーブルのレコード数のそれぞれの紐づきカラムの値にわたる最小値が所定の閾値未満のときには、前記監視するテーブルの参照先テーブルについて、個人情報保護処理を行うことを特徴とする個人情報管理システム。
9. 個人情報管理システムにより、個人情報に関るデータの個人情報保護処理を行う個人情報管理方法であって、
   前記個人情報管理システムは、
   個人情報アクセスクライアントと、
   前記個人情報アクセスクライアントとネットワークにより接続された個人情報データベースを保持する個人情報管理サーバとを有し、
   前記個人情報アクセスクライアントが、前記個人情報データベースのテーブルのカラムに対して直接の個人情報の保護種類を指定するステップと、
   前記個人情報管理サーバが、前記テーブルのカラムに対して直接の個人情報の保護種類を指定されたテーブルとの関係データベースにおける紐づき関係に基づいて、各々のテーブルに対する個人情報保護の保護クラスを設定するステップとを有することを特徴とする個人情報管理方法。
10. 各々のテーブルに対する個人情報保護の保護クラスを設定するステップにおいて、前記保護クラスは、前記テーブルのカラムに対して直接の個人情報の保護種類を指定されたテーブルとの紐づき関係のテーブルの段数から各々のテーブルに対する個人情報の保護の強度を異ならしめることを特徴とする請求項９記載の個人情報管理システム。
11. 前記個人情報管理サーバは、各々のテーブルに対する個人情報の保護の強度を異ならしめる保護クラスを設定するステップにおいて、
    前記テーブルのカラムに対して直接の個人情報の保護種類を指定されたテーブルに対して、保護の強度が一番強い「ｍｕｓｔ保護」を設定し、
    関係データベースにおける参照元テーブルと参照先テーブルの紐づき関係において、前記参照先テーブルは、前記参照元テーブルの保護クラスと同じ保護クラスか、または、前記参照元テーブルの保護クラスよりも保護の強度の弱い保護クラスを設定することを特徴とする請求項９記載の個人情報管理方法。
12. 各々のテーブルに対する個人情報保護の保護クラスを設定するステップにおいて、
    前記個人情報管理サーバは、前記参照元テーブルと前記参照先テーブルの関係データベースにおける対応関係が１：１のときには、前記参照先テーブルは、前記参照元テーブルの保護クラスと同じ保護クラスを設定し、
    前記参照先テーブルの紐づきカラムの値と同一の値を有する参照先テーブルのレコード数のそれぞれの紐づきカラムの値にわたる最小値が所定の閾値未満のときには、前記参照先テーブルは、前記参照元テーブルの保護クラスと同じ保護クラスを設定し、
    前記参照先テーブルの紐づきカラムの値と同一の値を有する参照元テーブルのレコード数のそれぞれの紐づきカラムの値にわたる最小値が所定の閾値以上であるときには、前記参照先テーブルは、前記参照元テーブルの保護クラスよりも保護の強度の弱い保護クラスを設定することを特徴とする請求項１１記載の個人情報管理方法。

Images