特開 2024-152693 データ、特に個人データを保存するためのシステムおよび方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024152693

(43)【公開日】2024-10-25

(54)【発明の名称】データ、特に個人データを保存するためのシステムおよび方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20241018BHJP

   G06F 16/2452 20190101ALI20241018BHJP

【ＦＩ】

G06F21/62 354

G06F21/62 318

G06F16/2452

【審査請求】未請求

【請求項の数】14

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2024064217

(22)【出願日】2024-04-11

(31)【優先権主張番号】10 2023 109 178.6

(32)【優先日】2023-04-12

(33)【優先権主張国・地域又は機関】DE

(71)【出願人】

【識別番号】501205108

【氏名又は名称】エフ ホフマン－ラ ロッシュ アクチェン ゲゼルシャフト

(74)【代理人】

【識別番号】110001896

【氏名又は名称】弁理士法人朝日奈特許事務所

(72)【発明者】

【氏名】アイシュワリヤー アレックス ナマシヴァヤム

(72)【発明者】

【氏名】ヨッヘン ブリッツ

(72)【発明者】

【氏名】シュテファン ブシェリ

(72)【発明者】

【氏名】リカルド クリスティーノ

(72)【発明者】

【氏名】スタニスワフ フィンダイゼン

(72)【発明者】

【氏名】アルパー コカデミール

(72)【発明者】

【氏名】スディプト シェカール ロイ

(72)【発明者】

【氏名】ゲルハルト ゾンネンベルク

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175BA01

5B175EA03

5B175GC02

(57)【要約】      （修正有）

【課題】データを保存するための効率的で安全なシステム及び方法を提供する。
【解決手段】システム１００は、インターフェース１０５と、認証モジュール１３０と、データを保存するための少なくとも１つのターゲットデータベース３０，４０と、データアクセスモジュール１１０と、を備える。データアクセスモジュール１１０は、インターフェースによってクライアントコンピュータ１０からリクエストを受信することと、受信したリクエストに応答して、ターゲットデータベース３０、４０からデータをクエリすることと、クライアントコンピュータ及び／又はユーザがクエリを行う権限を有しているかどうかを判定することと、リクエストに応答するために、応答データセットを生成し、該応答データセットをクライアントコンピュータに送信することと、を含む。応答データセットのデータは、制限付き認証が確認された場合に匿名化される。
【選択図】図２

【特許請求の範囲】

【請求項1】

データ、特に個人データを保存するためのシステムであって、
インターフェース（１０５）、特にＲＥＳＴ ＡＰＩと、
認証モジュール（１３０）と、
前記データを保存するための少なくとも１つのターゲットデータベース（３０，４０）と、
データアクセスモジュール（１１０）であって、
ａ）前記インターフェースによってクライアントコンピュータ（１０）からリクエストを受信することと、
ｂ）受信した前記リクエストに応答して、前記少なくとも１つのターゲットデータベース（３０，４０）からデータをクエリすることと、
ｃ）前記クライアントコンピュータおよび／またはユーザがクエリを行う権限を有しているかどうかを判定することと、
ｄ）前記リクエストに応答するために応答データセットを生成することであって、前記応答データセットを前記クライアントコンピュータに送信し、前記応答データセットの少なくとも一部のデータは、制限付き認証が決定された場合に匿名化される、生成することと
を行うように設計されている、データアクセスモジュール（１１０）と
を備える、システム。

【請求項2】

前記インターフェース（１０５）と通信するように構成された、特に少なくとも１つのクライアントコンピュータ（１０）にインストールされたデータベースドライバ（１２）、特に、ＪＤＢＣドライバを備える、請求項１に記載のシステム。

【請求項3】

前記データベースドライバ（１２）がパーサユニットを備え、前記パーサユニットが、フィールド名のうちの少なくとも選ばれたものを使用して前記インターフェース（１０５）に送信するためのクエリを作成するために、ＳＱＬ表現を含む文字列を受信し、前記ＳＱＬ表現から、特にデータベーステーブルから前記フィールド名を抽出するように設計されており、および／または
前記データベースドライバ（１２）は、前記ＳＱＬ表現を例えば文字列としてＲＥＳＴリクエスト内にカプセル化し、前記リクエストを前記インターフェース（１０５）上に出力するように設計されていることを特徴とする、請求項１または２に記載の、特に請求項２に記載のシステム。

【請求項4】

複数のロールおよび／またはユーザを保存するデータベースであって、前記ロール／ユーザにはそれぞれの権限が割り当てられている、データベースを特徴とし、
前記認証モジュール（１３０）は、前記インターフェース（１０５）によって受信された、リクエストのうちの少なくとも選ばれたものを受信し、前記データベースから少なくとも一つのロールまたはユーザに割り当て、割り当てられた前記権限に基づいて、それぞれの前記リクエストに応答して前記インターフェース（１０５）によってどのデータが送信されるかを決定するように設計されている、請求項１から３のいずれか一項に記載のシステム。

【請求項5】

前記システム、特に構成管理モジュール（１２０）は、所定の権限および／または割り当てられた権限に応じて、異なるユーザおよび／またはロール、特にリレーショナルターゲットデータベース（３０，４０）が、少なくとも１つのターゲットテーブルのビュー（３１，３２）を生成および保存するように設計され、前記ビュー（３１，３２）は、前記ターゲットテーブルからの値が匿名化された値で置き換えられるように、好ましくは前記権限に応じて構成されていることを特徴とする、請求項１から４のいずれか一項に記載のシステム。

【請求項6】

前記システムは、前記インターフェース（１０５）上のリクエストに対して、複数のターゲットデータベース（３０，４０）から、前記リクエストに応答するための前記データを含むターゲットデータベースを選択するように設計されており、および／または
前記認証モジュールは、
ａ）前記リクエストにロールおよび／またはユーザを割り当てることと、
ｂ）前記ターゲットデータベースがリレーショナルデータベースであるかどうかを判定することと、
ｃ）前記ターゲットデータベースがリレーショナルデータベース（３０）である場合、前記ロールまたは前記ユーザに関する情報を使用して、前記リクエストに応答するために使用される複数のビュー（３１，３２）からビューを選択することと
を行うように設計されていることを特徴とする、請求項１から５のいずれか一項に記載のシステム。

【請求項7】

前記システム、特に構成管理モジュール（１２０）は、ターゲットデータベースとして使用される（分散された）ターゲットハッシュデータベースに対する所定の権限および／または割り当てられた権限に応じて、異なるユーザおよび／またはロールが、特に、コピーハッシュデータベースの形式でロール固有のコピーを生成および保存するように設計され、前記コピーハッシュデータベースは、前記ターゲットハッシュデータベースからの（選択的な）値が匿名化された値で置き換えられるように、好ましくは前記権限に応じて変更されることを特徴とする、請求項１から６のいずれか一項に記載のシステム。

【請求項8】

前記システムは、前記インターフェース（１０５）上のリクエストに対して、複数のターゲットデータベース（３０，４０）から、前記リクエストに応答するための前記データを含むターゲットデータベースを選択するように設計されており、および／または
前記認証モジュールは、
ａ）前記リクエストにロールおよび／またはユーザを割り当てることと、
ｂ）前記ターゲットデータベースがハッシュデータベースであるかどうかを判定することと、
ｃ）前記ターゲットデータベースがハッシュデータベースである場合、前記ロールまたは前記ユーザに関する情報を使用して、前記リクエストに応答するために使用される複数のコピーハッシュデータベースからコピーハッシュデータベースを選択することと
を行うように設計されていることを特徴とする、請求項１から７のいずれか一項に記載のシステム。

【請求項9】

前記少なくとも１つのターゲットデータベース上のデータセットのうちの少なくとも選ばれたもののデータ収集コンテキスト、例えば、前記データ収集の時間、前記データ収集の目的、前記データの保持期間、前記データ収集の法的根拠、関連付けられた保持ポリシーの詳細を保存するように設計されたデータ収集コンテキストモジュール（１５０）を特徴とする、請求項１から８のいずれか一項に記載のシステム。

【請求項10】

前記システム、特に構成管理モジュール（１２０）は、前記データ収集コンテキストに基づいてデータを選択し、選択された前記データを匿名化された形式で保存するように設計されていることを特徴とする、請求項１から９のいずれか一項に記載の、特に請求項９に記載のシステム。

【請求項11】

前記少なくとも１つのターゲットデータベース（３０，４０）の少なくとも一部のデータは暗号化されており、前記システム、特に認証モジュール（右上）は、セキュリティトークンを受信し、前記セキュリティトークンに基づいて、前記クエリを発行する前記クライアントコンピュータ（３０）が、前記システムと通信することおよび／またはクエリされた前記データを受信することを許可されているかどうかを判定するように設計されていることを特徴とする、請求項１から１０のいずれか一項に記載のシステム。

【請求項12】

鍵データベースであって、前記システムは、特に前記少なくとも１つのターゲットデータベース（３０，４０）から、暗号化されたデータを復号化するために使用される鍵を選択するために前記鍵データベースを使用するように設計されている、鍵データベース
を特徴とする、請求項１から１１のいずれか一項に記載の、特に請求項１１に記載のシステム。

【請求項13】

好ましくは請求項１から１２のいずれか一項に記載のシステムを使用して、応答データセットによって少なくとも１つのリクエストに応答するための方法であって、
ａ）インターフェース（１０５）、特にＲＥＳＴ ＡＰＩを介して少なくとも一つのリクエストを受信ステップと、
ｂ）受信した前記リクエストに応答して、少なくとも１つのターゲットデータベース（３０，４０）からデータをクエリするステップと、
ｃ）前記クライアントコンピュータ（１０）および／またはユーザがクエリを行う権限を有しているかどうかを判定するステップと、
ｄ）前記リクエストに応答するために少なくとも１つの応答データセットを送信するステップであって、前記応答データセットの少なくとも一部のデータは、制限付き権限が確認された場合に匿名化される、少なくとも１つの応答データセットを送信するステップと
を含む、方法。

【請求項14】

命令を含むコンピュータ可読メモリであって、前記命令は、少なくとも１つの処理ユニット上で実行されたときには請求項１３に記載の方法を実行する、コンピュータ可読メモリ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、インターフェースと、認証モジュールと、少なくとも１つのターゲットデータベースと、少なくとも１つのデータ・アクセス・モジュールとを備える、データを保存するためのシステムに関する。さらに、本発明は、対応するシステムによって対応するデータを保存するための方法に関する。

【背景技術】

【0002】

医療分野では、データを保存することには非常に問題がある。問題となるデータは、多くの場合、個人的であり、非常に機密性が高い。同時に、対応するデータが様々なグループの人々およびアプリケーションに利用可能である必要がある。信頼性の高いデータは、疾患の正確な診断を行うために、またその後の治療の成功のためにも必要である。医療アルゴリズムのさらなる開発はまた、特に長期にわたってデータが利用可能であることを必要とする。

【0003】

したがって、関連データ、特に個人データを利用可能にする包括的なシステムがヘルスケア分野において開発されている。

【0004】

このような個人データの管理は、このデータを処理するための様々な規則および法律があるため複雑である。これらの規則および法律は、保存の形態、その保持期間および異なる目的のためのその使用に関する。

【0005】

さらに、データを保存するためのこのようなシステムに様々なアプリケーションを接続することは複雑である。既存のアプリケーションおよびシステムの多くでは、ローカルで、すなわちそれぞれのアプリケーションにおいてデータ保護に準拠するために必要なアルゴリズムを実装する試みが行われており、この手法は非常に複雑である。より新しいシステムは中央データ管理に依存しており、既存のアプリケーションの接続は技術的に複雑である。ここで、既存のアプリケーションを完全に再実装する必要があることが多い。

【0006】

米国特許第１０５７２６８４号明細書は、個人データが分散データベース、好ましくはブロックチェーンに保存されるシステムを記載している。欧州特許出願公開第１２２６５２４号明細書は、エンティティ間でデータを共有することができるシステムを記載している。このシステムでは、ヘルスケアシステム用のデータを公開することも可能であり、データセキュリティは暗号化および適切な証明書によって保証される。

【0007】

欧州特許第２６５６２７４号明細書は、文書を交換または利用可能にするためのシステムを記載している。システムは、個人データを保護することを可能にするアクセス制限を実施する。

【発明の概要】

【0008】

この従来技術から進んで、本発明の目的は、データを保存するための効率的で安全なシステムを作成することである。特に、システムは、既存のアプリケーションを容易かつ効率的に統合することを可能にすべきである。

【0009】

この目的は、請求項１に記載のシステムおよび請求項１３に記載の方法によって達成される。

【0010】

特に、この目的は、データ、特に個人データを保存するためのシステムによって達成され、本システムは、
インターフェース、特にＲＥＳＴ ＡＰＩと、
認証モジュールと、
データを保存するための少なくとも１つのターゲットデータベースと、
データ・アクセス・モジュールであって、
ａ）インターフェースによってクライアントコンピュータからリクエストを受信することと、
ｂ）受信したリクエストに応答して少なくとも１つのターゲットデータベースからデータをクエリすることと、
ｃ）クライアントコンピュータおよび／またはユーザがクエリを行う権限を有しているかどうかを判定することと、
ｄ）リクエストに応答するために応答データセットを生成することであって、応答データセットをクライアントコンピュータに送信し、応答データセットの少なくとも一部のデータは、制限付き権限が確認された場合に匿名化される、応答データセットを生成することと
を行うように設計されている、データ・アクセス・モジュールと
を備える。

【0011】

本発明の１つの着想は、（中央）ターゲットデータベースにデータを保存することである。ターゲットデータベースは、データへのアクセスを管理する（中央－）アップストリームデータ・アクセス・モジュールを有する。認証モジュールは、どのアプリケーションがどのデータにアクセスできるかを調整する。したがって、本発明では、アプリケーションがデータに直接アクセスすることはもはや不可能である。代わりに、アクセスは、好ましくは事前定義されたインターフェースを介して、例えばクライアントコンピュータからリクエストを受信するデータ・アクセス・モジュールを介して行われなければならない。次いで、リクエストされたデータは、ターゲットデータベースから少なくとも部分的にクエリされ得る。既に説明したように、クエリされたまたはリクエストされたデータにアクセスする権限があるかどうか、およびどの程度まで権限があるかが検証される。対応するアクセス規制は、ユーザおよび／またはロールおよび／またはデバイスに基づくことができ、一般的なオペレーティングシステムでは通例であるように、個々のアプリケーションにユーザアカウントを割り当てることが可能である。本発明によれば、他の既知の認証概念も考えられる。

【0012】

リクエストに応答するために、本発明によれば、データ・アクセス・モジュールは、応答データセットを生成することであって、応答データセットをクライアントコンピュータに送信し、応答データセット内の個々のデータは匿名化される、応答データセットを生成することを行うように設計されている。対応する匿名化は、オンラインで、すなわちクエリの時点で、またはオフラインで、リクエストの前の時点で、例えばデータを収集するときに、または夜間ルーチンの一部として行われ得る。

【0013】

本発明の一実施形態では、データをクエリおよび／または提供するために使用されるインターフェースはＲＥＳＴ（「表現状態転送」ベースのインターフェースである。対応するＲＥＳＴ ＡＰＩは、ウェブサービスとして実装され得て、リクエストを効率的に処理することを可能にする。

【0014】

一実施形態では、システムは、特に少なくとも１つのクライアントコンピュータにインストールされ、インターフェースと通信するように構成されたデータベースドライバを備える。対応するデータベースドライバは、ＪＤＢＣドライバとすることができる。高度に洗練されたデータベース・アクセス・モジュールは、既存のオペレーティングシステムの多くに存在する。これらのデータベース・アクセス・モジュールの多くは、ＯＤＢＣベースである。したがって、クライアントコンピュータ上のアプリケーションは、データソースに直接アクセスするのではなく、インストールされたＯＤＢＣドライバを使用して適切なアクセスを実施する。従来のＯＤＢＣドライバと比較して、ＲＥＳＴ ＡＰＩは比較的新しい。本発明は、ＯＤＢＣドライバ、特にＪＤＢＣドライバを提供することを想定しており、アプリケーションはこれらのドライバを介して本発明によるシステムのインターフェースと通信することができる。したがって、アプリケーションのシステムへのアクセスは明確に構造化されており、既存のアプリケーションは、ＯＤＢＣドライバまたはＪＤＢＣドライバによってシステムと通信することができる。したがって、特に、本発明によるシステムは、認証およびデータ・アクセス・モジュールの追加機能にもかかわらず、従来のターゲットデータベースのように動作することができると考える場合、移行のための出費は極めて低い。

【0015】

一実施形態では、データベース・アクセス・モジュールは、パーサユニットを備え、パーサユニットが、ＳＱＬ表現を含む文字列を受信し、ＳＱＬ表現からフィールド名を抽出するように設計されている。構成は、データベース・アクセス・モジュール内のＳＱＬクエリに依然として適用され得る。

【0016】

ＳＱＬリクエストを、インターフェースに送信されるリクエストにほぼ自動的に変換するように、データベースドライバを実装することが可能である。例えば、一実施形態では、ＳＱＬリクエストはＲＥＳＴ規格に準拠するリクエストに変換される。一実施形態では、このためにパーサユニットが使用され、パーサユニットは、例えば、ＳＱＬ表現またはＯＤＢＣリクエストからテーブル名および／またはカラム名を抽出する。このデータを使用して、インターフェースを介して特定のデータリクエストを作成することができる。例えば、ＨＴＴＰを介してＧＥＴリクエストを送信することができ、テーブル名および／またはカラム名は、クエリされるリソースをアドレス指定する。

【0017】

１つの（さらなる）実施形態では、ＳＱＬリクエストは、インターフェースに送信されるＲＥＳＴリクエストまたはＲＥＳＴコールにおいて文字列としてカプセル化される。

【0018】

一実施形態では、システムは、複数のロールおよび／またはユーザを保存するデータベースを備え、権限がロール／ユーザのそれぞれに割り当てられる。システム、特に認証モジュールがアクセスを管理できるようにするために、個々のターゲットデータベースの認証概念を使用することが可能である。好ましい実施形態では、（別個の）データベースを使用して、ターゲットデータベース全体にわたってロールおよび／またはユーザを管理し、それらに権限を割り当てる。

【0019】

認証モジュールは、インターフェースによって受信されたリクエストのうちの少なくとも選ばれたものを、データベースからの少なくとも１つのロールまたはユーザに割り当てることと、割り当てられた権限に基づいて、それぞれのリクエストに応答してインターフェースによってどのデータが送信されるかを決定することとを行うように設計され得る。

【0020】

一実施形態では、認証モジュールは、特定のデータへのユーザまたはロールのアクセスを完全に拒否することを決定してよい。１つの（さらなる）実施形態では、権限は、どのターゲットデータベースおよび／または特定のターゲットデータベースのどのサブコンポーネント（例えば、テーブルおよび／またはビュー）がクエリされるかに影響を及ぼす。本発明によれば、ターゲットデータベース（オンライン）から特定のデータを匿名化するために、権限に基づいて少なくとも１つの匿名化された機能を選択することも可能である。

【0021】

一実施形態では、システム、特に構成管理モジュールは、事前定義されたおよび／または割り当てられた権限に応じて、異なるユーザおよび／またはロールのためのターゲットデータベースおよび／またはビュー（例えば、いわゆるＳＱＬビュー）を生成し、保存するように設計される。一実施形態では、元のデータセットに対して複数のターゲットデータベースおよび／またはビューが存在し、個々のターゲットデータベースおよび／またはビューは、それらが異なる程度に匿名化されるという点で異なる。例えば、第１のビューは、構成管理モジュールによって最初に記録されたデータを出力することができ、第２のビューは、最初に記録されたデータの一部のみを示し、例えば、データセットが削除されており、および／またはエントリが匿名化されている。

【0022】

したがって、この実施形態ではオフライン匿名化が実行され、データは、異なるビューに基づいて異なるように複製または出力される可能性がある。この手法には、リクエストに非常に効率的に応答することができるという利点がある。個々のテーブル／ビュー／フィールドの状態、したがって様々な匿名化の度合いを記録し、したがって文書化することも可能である。

【0023】

既に説明したように、システムは、インターフェース上のリクエストのために複数のターゲットデータベースからターゲットデータベースを選択するように設計することができ、このデータベースは、リクエストに応答するためのデータを含む。

【0024】

一実施形態では、認証モジュールは、
ａ）リクエストにロールおよび／またはユーザを割り当てることと、
ｂ）ターゲットデータベースがリレーショナルデータベースであるかどうかを判定することと、
ｃ）ターゲットデータベースがリレーショナルデータベースである場合、ユーザに関するロールまたは情報を使用して、複数のビューからビューを選択することと、
ｄ）選択されたビューを使用してリクエストに応答することと
を行うように設計されている。

【0025】

ビューの使用は、少なくともＳＱＬデータベースに関して、データが自由に複製されず、同時に効果的なアクセス概念を実装できるという利点を有する。

【0026】

一実施形態では、システム、特に構成管理モジュールは、事前定義されたおよび／または割り当てられた権限に応じて、ターゲットデータベースとして使用される（分散された）ターゲットハッシュデータベースの異なるユーザおよび／またはロールのコピーを生成し、保存するように設計されている。このようにして作成されたコピーハッシュデータベースは、既に説明されたビューまたはＳＱＬテーブルに匹敵する、様々な匿名化の度合いを有することができる。

【0027】

一実施形態では、異なる権限と異なるターゲットハッシュデータベースとの間に相関関係がある。一実施形態では、異なるロールとコピーハッシュデータベースとの間に相関関係がある。したがって、これらはロール固有のコピーである。

【0028】

非ＳＱＬベースのデータベースは、本発明の意味の範囲内でハッシュデータベースと呼ばれる。これは、キーと値のペアを保存するデータベースとすることができる。ハッシュデータベースは、ＡｍａｚｏｎのＤｙｎａｍｏＤＢ（登録商標）などの分散されたデータベースであってもよい。対応するハッシュデータベースは、リクエストへの応答に関して非常に性能が高い。この性能は、コピーの作成によって影響を受けない。個々のコピーを異なるサーバに巧みに分散させることによってシステムの性能をさらに向上させることができる。

【0029】

一実施形態では、システムは、インターフェース上のリクエストのために複数のターゲットデータベースからターゲットデータベースを選択するように設計されており、このデータベースは、リクエストに応答するためのデータを含む。これに関連して、認証モジュールはまた、
ａ）リクエストにロールおよび／またはユーザを割り当てることと、
ｂ）ターゲットデータベースがハッシュデータベースであるかどうかを判定することと、
ｃ）ターゲットデータベースがハッシュデータベースである場合、ロールまたはユーザに関する情報を使用して、リクエストに応答するために使用されるコピーハッシュデータベースを複数のコピーハッシュデータベースから選択することと
を行うように設計され得る。

【0030】

１つの（好ましい）実施形態では、ＳＱＬデータベースおよび非ＳＱＬデータベース、特にハッシュデータベースが並列に共存する。これに関連して、ＳＱＬデータベースの匿名化は、異なる手法に従って行われる。例えば、ＳＱＬデータベースは異なるビューを提供することによって匿名され得て、非ＳＱＬデータベースは個々のデータを複製することによって匿名され得る（コピーハッシュデータベースを参照）。システムは、少なくともこれら２つの匿名化手法を知っており、リクエストに応答するとき、所与の権限で使用されるエンティティ（ビューまたはコピー）を決定する。したがって、必要な匿名化にもかかわらず、異なるデータベース実装を使用することができる。特に、異なるデータベース実装は、データをどのように保存し、最も効率的にクエリできるかに合わせて調整されてもよい。したがって、必要なデータ保護は、それぞれのデータベースの特定の実装とは無関係に実装され得る。それぞれのデータベースを実装するために使用される特定の技術は、（インターフェースを介した）外部アクセスに対して透過的ではないため、均一なアクセスを行うことができる。

【0031】

一実施形態では、システムは、少なくとも１つのターゲットデータベース上のデータセットのうちの少なくとも選ばれたもののデータ収集コンテキストを保存するように設計されたデータ収集コンテキストモジュールを備える。データ収集コンテキストは、例えば、データが収集された時間、データ収集の目的、データの保持期間、データ収集の法的根拠、関連付けられた保持ポリシーに関する情報などとすることができる。データ収集コンテキストを決定することにより、このデータに基づいて異なる形式の匿名化を開始することが可能である。部分的または完全に自動化された保持ポリシーも、個々のデータに対して実施され得る。この目的のために、システム、特に構成管理モジュールは、データ収集コンテキストに基づいてデータを選択することと、選択されたデータを匿名形式で保存することとを行うように設計され得る。

【0032】

一実施形態では、少なくとも１つのターゲットデータベースのデータの少なくとも一部は暗号化され、システムは、セキュリティトークンを受信することと、セキュリティトークンに基づいて、クエリを発行するクライアントコンピュータがシステムと通信することを許可されているかどうか、および／またはクエリされたデータを受信することを許可されているかどうかを判定することと、を行うように設計される。この目的のために鍵データベースを提供することができ、システムは、特に少なくとも１つのターゲットデータベースから、暗号化されたデータを復号化するために使用される鍵を選択するために鍵データベースを使用するように設計される。

【0033】

したがって、本発明によるシステムは、鍵管理機能を実行することもでき、クエリを行うクライアント－コンピュータ／ユーザがシステム上で認証され、システムは、それ自体の認証概念に応じてターゲットデータベース内の個々の暗号化データにアクセスするための鍵を選択する。したがって、上述のドライバおよび本発明によるシステムによって、すべてのアクセスリクエストにわたって一様に実装される、クライアントコンピュータ上で実行されているより古いアプリケーションのための認証システムを実装することも可能である。

【0034】

冒頭で述べた目的は、応答データセットによって少なくとも１つのリクエストに応答するための方法によっても達成され、本方法は、以下のステップ、すなわち、
ａ）インターフェース、特にＲＥＳＴ ＡＰＩを介して少なくとも１つのリクエストを受信するステップと、
ｂ）受信したリクエストに応答して、少なくとも１つのターゲットデータベースからデータをクエリするステップと、
ｃ）クライアントコンピュータおよび／またはユーザがクエリする権限を有するかどうかを判定するステップと、
ｄ）リクエストに応答するために少なくとも１つの応答データセットを送信するステップであって、応答データセットの少なくとも一部のデータが、制限付き権限が確認された場合に匿名化される、少なくとも１つの応答データセットを送信するステップと
を含む。

【0035】

システムに関連して既に説明したように、本方法には利点がある。本方法は、既に説明したシステムで実行され得る。システムの説明により、本発明による方法の暗黙的な方法ステップが得られ、本発明は、異なる実施形態においてこれらの方法ステップをより詳細に定義する。

【0036】

冒頭で述べた目的は、命令を含むコンピュータ可読メモリであって、特に命令が、少なくとも１つの処理ユニット上で実行されたときには上述の方法を実施する、コンピュータ可読メモリによっても達成される。ここでも、本発明によるシステムに関連して既に説明したものと同様の利点がある。

【0037】

さらなる有利な実施形態は、従属請求項から得られる。
本発明は、いくつかの例示的な実施形態によって以下に説明され、これらは、例示を参照してより詳細に説明される。

【図面の簡単な説明】

【0038】

【図1】インターネットを介してクライアントコンピュータに通信可能に接続された本発明によるシステムの概略図である。

【図2】図１による本発明によるシステムの詳細な概略図である。

【図3】様々に匿名化されたデータの概略図である。

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

【0039】

なお、以下の説明において、同一に作用する部分には同一の符号が用いられている。

【0040】

図１は、インターネット１を介して本発明によるシステム１００の例示的な実施形態に通信可能に接続されたクライアントコンピュータ１０を示す。図示されている抽象化のレベルでは、システム１００は、リレーショナルデータベース３０と、ハッシュデータベース、例えばＡｍａｚｏｎのＤｙｎａｍｏＤＢ（登録商標）データベースとを含む。

【0041】

様々なアプリケーションをクライアントコンピュータ１０にインストールすることができ、クライアントコンピュータは通常、ＯＤＢＣインターフェースを介してデータベースと通信する。図示されている例示的な実施形態では、アプリケーションがＪＤＢＣドライバを介してシステム１００のＲＥＳＴ ＡＰＩ１０５（図２を参照されたい）と通信することができるようにするデータベースドライバ１２が提供されている。

【0042】

図２は、システム１００を示し、一部のソフトウェアコンポーネントが概略的に強調表示されている。これらのソフトウェアコンポーネントには以下が含まれる。

【表1】

【0043】

本発明の一態様は、クライアントコンピュータ１０がＲＥＳＴ ＡＰＩ１０５を介してデータ・アクセス・モジュール１１０と通信することである。データ・アクセス・モジュールは、システム１００の中心的なコンポーネントを表し、クライアントコンピュータ１０によって発行されるリクエストに対する応答を本質的に編成する。説明された例示的な実施形態では、ＲＥＳＴ ＡＰＩ１０５とデータ・アクセス・モジュール１１０との間にデータベース接続モジュールまたはデータベースプロキシがある。これらを使用して、ターゲットデータベース固有の方法でデータ・アクセス・モジュール１１０にクエリを転送することができる（リレーショナルデータベース３０またはＳＱＬデータベースまたはハッシュデータベース４０を参照）。図示された例示的な実施形態では、左のモジュールはＳＱＬ固有のデータベース接続モジュール１４０であり、右のコンポーネントは非ＳＱＬターゲットデータベース用のデータベース接続モジュールである。

【0044】

図２では、一例として、データクエリが元々クライアントコンピュータ１０からではなく、その上で実行されているアプリケーションから来ることが示されている。

【0045】

一実施形態では、アプリケーションは、典型的には、ＯＤＢＣインターフェースを介して適切なターゲットデータベースと通信するアプリケーションである。既に説明したように、本発明によれば、クライアントコンピュータ１０は、提出されたＳＱＬリクエストをＲＥＳＴリクエストに変換するデータベースドライバ１２を有する。これを行うために、アドレス指定されたテーブル名がリクエストから解析され、具体的なフィールド情報が解明される。ワイルドカード記号（「＊」）などの不特定のフィールド情報も、ターゲットデータベースが既知である限り、個々のフィールド名に変換することができる。また、特定のリクエスト（キーワード：「ＷＨＥＲＥ」）に対して設定されたＳＱＬの典型的な条件も変換することができる。基本的に、データベースドライバ１２は、ＳＱＬクエリからＲＥＳＴリクエストを生成し、このＲＥＳＴリクエストをインターフェース１０５を介してシステム１００に送信する。クエリは、とりわけ、データ・アクセス・モジュール１１０によってそこで処理される。

【0046】

データ・アクセス・モジュール１１０は、例えば、データベース接続モジュール１４０によって提供されたデータに基づいて、ターゲットデータベース、例えばリレーショナルデータベース３０を選択する。

【0047】

一実施形態では、データ・アクセス・モジュール１１０はまた、リクエストに応答して元のデータまたは部分的に匿名化されたデータを提供することができる範囲を判定する。例えば、システム１００内の特定のロールを、識別情報に基づいてクライアントコンピュータ１０上のリクエストアプリケーションに割り当てることができる。このロールは、特定のリレーショナルデータベース３０のビューに関連付けられ得る。

【0048】

図３は、２つの異なるビュー、すなわち完全なデータベースビュー３１および少なくとも部分的に匿名化されたデータベースビュー３２を示す。例として、図示されている表またはビューは、患者データであり得る。完全なデータベースビュー３１では、名前、正確な生年月日、および血液型が与えられているが、匿名化されたデータベースビュー３２には、名前に加えて、生年月日のみがあり、血液型に関する情報はない。匿名化されたデータベースビュー３２を生成するために、血液型は単にヌル値「ＮＵＬＬ」に設定された。

【0049】

これらのビューのうちの１つが選択されると、適切なデータが、データ・アクセス・モジュール１１０からＲＥＳＴ ＡＰＩ１０５を介してクライアントコンピュータ１０上のアプリケーションに返され得る。この点で、明確に構造化され匿名化された形態でデータを提供することが容易に可能である。

【0050】

様々なビューによって図３に示す手法は、データセットがリレーショナルデータベース３０に一度だけ存在すればよく、必要な匿名化機能がデータセットをクエリするときにオンラインで実行されるという利点を有する。

【0051】

非ＳＱＬベースのデータベースには、明確に異なる手法を使用することができる。一例としてハッシュデータベース４０を使用すると、元のハッシュデータベースのコピーを作成し、そこに特定の値を恒久的に上書きすることが可能である。したがって、割り当てられたロールに応じて、ハッシュデータベース４０に向けられたクエリに対して、データ・アクセス・モジュール１１０は、クエリアプリケーションのユーザロールに関連付けられたハッシュデータベースを選択する。この手法は、高い性能が達成されるという利点を有する。

【0052】

説明された例示的な実施形態では、それぞれのターゲットデータベースの技術的実施態様に応じて、両方の手法が並行して追求される。しかしながら、本発明によれば、システム１００においてこれらの手法のうちの一方のみを実施することも考えられる。

【0053】

一実施形態では、システム１００は、データ収集コンテキストモジュール１５０を備える。このデータ収集コンテキストモジュールは、データを収集し、それをターゲットデータベース、例えばリレーショナルデータベース３０またはハッシュデータベース４０に保存するように設計され得る。この収集プロセスの一部として、データ収集のコンテキストを識別する追加情報が保存されてもよい。この目的のために、別個のデータベースを提供することができる。コンテキストデータまたはデータ収集コンテキストは、以下を含む。
データ収集コンテキストの一意の識別子
データ収集の範囲
データ収集の目的
データ収集の持続時間
データ収集の法的根拠
適用可能なデータ保護コンプライアンス規制

【0054】

このコンテキストデータを使用して、保存されたデータの最初に必要な匿名化ステップを決定することができる。また、時系列に応じてターゲットデータベースの内容を変更することができる。例えば、特定のデータを、特定の期間だけ保持することができることが考えられる。この点において、本発明によるシステム１００は、特定の時点におけるコンテキストに基づいてデータを削除することを可能にする。加えて、または代替として、特定のデータを特定の時点の後に一般大衆または特定のアプリケーションが利用できるようにすることができる。この点で、匿名化の程度が経時的に増加することは必ずしも必要ではない。理論的には、後の時点で匿名化情報が少ないシナリオも考えられる。

【0055】

記載されたメカニズムはまた、純粋に時間的な情報に限定されない。例えば、コンテキストは、特定のデータが収集された目的を示すことができ、したがって、どのアクセスロールが特定のデータをクエリすることを許可されるかに影響を及ぼす。

【符号の説明】

【0056】

１ インターネット
１０ クライアントコンピュータ
１２ データベースドライバ
３０ リレーショナルデータベース
３１ 完全なデータベースビュー
３２ 匿名化されたデータベースビュー
４０ ハッシュデータベース
１００ システム
１０５ ＲＥＳＴ ＡＰＩ
１１０ データ・アクセス・モジュール
１２０ 構成管理モジュール
１３０ 認証モジュール
１４０ データベース接続モジュール
１５０ データ収集コンテキストモジュール

【図1】

【図2】

【図3】

【外国語明細書】