JP2021110861A - 制御方法、制御プログラム、および情報処理装置 - Google Patents

制御方法、制御プログラム、および情報処理装置 Download PDF

Info

Publication number
JP2021110861A
JP2021110861A JP2020003465A JP2020003465A JP2021110861A JP 2021110861 A JP2021110861 A JP 2021110861A JP 2020003465 A JP2020003465 A JP 2020003465A JP 2020003465 A JP2020003465 A JP 2020003465A JP 2021110861 A JP2021110861 A JP 2021110861A
Authority
JP
Japan
Prior art keywords
search
concealment
record
database
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2020003465A
Other languages
English (en)
Inventor
秀暢 小栗
Hidenobu Oguri
秀暢 小栗
武司 下山
Takeshi Shimoyama
武司 下山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2020003465A priority Critical patent/JP2021110861A/ja
Publication of JP2021110861A publication Critical patent/JP2021110861A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

【課題】データ利用者の関心内容の秘匿性を向上させる。【解決手段】情報処理装置２は、データ利用者が利用する第１のレコード群に含まれるレコードの条件として、所定の属性のフィールドに第１の値が設定されていることが指定された利用レコード情報１ａを取得する。次に情報処理装置２は、複数のレコードが格納された第１のデータベース３ａを管理するサーバ３に対して、複数のレコードのうちの、第１のレコード群と第２のレコード群とを格納した第２のデータベースの生成要求を送信する。第１のレコード群は、複数のレコードのうちの、所定の属性のフィールドに第１の値が設定されているレコード群である。第２のレコード群は、所定の属性のフィールドに、第１の値とは異なる第２の値が設定されているレコード群である。【選択図】図１

Description

本発明は、制御方法、制御プログラム、および情報処理装置に関する。
機微な内容のデータが格納されたデータベース（対象ＤＢ：Database）に対して、データの内容を秘匿したままそのデータへの外部からの検索（秘匿検索）を可能とするシステムがある。秘匿検索は、例えば対象ＤＢを持つデータ提供者（ＤＰ：Data Provider)と、検索内容（クエリ）を秘匿したまま対象ＤＢを検索したいデータ利用者（ＤＵ：Data User）と、処理を仲介する信頼できる第三者（ＴＴＰ：Trusted Third Party）が関与する。
ＤＰが有する対象ＤＢを管理するサーバ（ＤＰサーバ）は、対象ＤＢを暗号化したＤＢ（秘匿化ＤＢ）をＴＴＰが有するサーバ（ＴＴＰサーバ）に登録する。またＤＵが有する端末装置（ＤＵ端末）は、ＤＵから入力された検索条件を示すクエリを暗号化して、ＴＴＰサーバに送信する。さらに、ＤＰサーバとＤＵサーバとは、それぞれ照合に用いる鍵をＴＴＰサーバに送信する。ＴＴＰサーバは、照合用の鍵を用いて、秘匿化ＤＢ内のデータから、クエリに示される検索条件を満たすレコードを検索する。そしてＴＴＰサーバは、例えばクエリに示される検索条件を満たすレコード数をＤＵ端末に送信する。このようにして、対象ＤＢ内のデータとクエリの内容とを互いに開示せずに、クエリに一致するレコード数が得られる。
データを秘匿化したままデータの検索を可能とする技術としては、プライバシィを保護した生体認証システムが提案されている。また、リレーショナル暗号化を利用して同等性を確認する同等性確認方法も提案されている。さらにデータを暗号化して鍵を持たないシステム管理者に隠蔽した状態でデータを保存する秘匿化データベースシステムも提案されている。
特開２０１５−２２５３４３号公報 特開２０１７−２２６９７号公報 国際公開第２０１７／１６８５３５号
暗号化したデータの検索では、高度な暗号技術が用いられており、クエリとデータとの照合にかかる処理負荷が、一般のデータ検索よりも格段に大きくなる。そのため、対象ＤＢのデータ量が大きくなると、検索負荷が過大となる。
そこで、ＤＰサーバにおいて、ＤＵが利用を希望するデータを対象ＤＢから抽出し、小規模のＤＢを生成しておくことが考えられる。しかしＤＰサーバでＤＢの小規模化を行うには、ＤＵが利用を希望するデータをＤＰに伝えることになり、ＤＵの関心のあるデータがＤＰ側に推定されるおそれがある。例えば製薬会社が、データ項目や取得期間などを具体的に指定して、病院が有する対象ＤＢの小規模化を、病院に要望する場合が考えられる。この場合、病院では、製薬会社からの指定内容に基づいて、どのような種別の薬品を開発しようとしているのかをある程度推定できる。
１つの側面では、本件は、データ利用者の関心内容の秘匿性を向上させることを目的とする。
１つの案では、情報処理装置による制御方法が提供される。当該制御方法では、情報処理装置は、データ利用者が利用する第１のレコード群に含まれるレコードの条件として、所定の属性のフィールドに第１の値が設定されていることが指定された利用レコード情報を取得する。そして情報処理装置は、複数のレコードが格納された第１のデータベースを管理するサーバに対して、複数のレコードのうちの、所定の属性のフィールドに第１の値が設定されている第１のレコード群と、所定の属性のフィールドに、第１の値とは異なる第２の値が設定されている第２のレコード群とを格納した第２のデータベースの生成要求を送信する。
１態様によれば、データ利用者の関心内容の秘匿性を向上させることができる。
第１の実施の形態に係る制御方法の一例を示す図である。 名寄せを伴う場合の制御方法の一例を示す図である。 第２の実施の形態に係る秘密情報管理システムの一例を示す図である。 ＴＴＰサーバのハードウェアの一例を示す図である。 秘密情報管理システムの各装置の機能を示すブロック図である。 ＤＢの一例を示す図である。 拡張分類マップとデータ分割基準情報との生成処理の一例を示す図である。 部分ＤＢの生成例を示す図である。 対照表の一例を示す図である。 部分ＤＢへのレコードの分類例を示す図である。 秘匿化ＤＢの生成例を示す図である。 秘匿化ＤＢ内の暗号化されたレコードの一例を示す図である。 秘匿検索処理の概要を示す図である。 秘匿検索の一例を示す図である。 秘匿検索の具体例を示す図である。 検索目的のかく乱の第１の例を示す図である。 名寄せを伴う秘匿検索の一例を示す図である。 検索目的のかく乱の第２の例を示す図である。 検索目的のかく乱の第３の例を示す図である。 ダミークエリを用いた検索目的かく乱の一例を示す第１の図である。 ダミークエリを用いた検索目的かく乱の一例を示す第２の図である。 検証ＤＢの検証結果の一例を示す図である。 クロス集計表の生成例を示す図である。 クロス集計表の生成を担うことでＤＰサーバが知り得る情報の一例を示す図である。 秘匿検索処理の手順を示すシーケンス図である。 名寄せを伴う秘匿検索処理の手順を示すシーケンス図である。 拡張分類マップ生成処理の手順の一例を示すフローチャートである。 真の分類マップの大きさの判断例を示す図である。 拡張分類マップの生成例を示す図である。 図５の検索支援部にて実施される名寄せ処理の手順の一例を示すフローチャートである。 名寄せ処理の一例を示す図である。
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず、第１の実施の形態について説明する。
図１は、第１の実施の形態に係る制御方法の一例を示す図である。図１には、当該制御方法を実現するためのシステムが示されている。このシステムには、端末装置１、情報処理装置２、およびサーバ３が含まれる。端末装置１は、サーバ３が保持するデータを利用するユーザ（ＤＵ）が使用する装置である。情報処理装置２は、データの利用を支援する信頼できる第三者（ＴＴＰ）が使用する装置である。サーバ３は、データの提供者（ＤＰ）が使用する装置である。サーバ３は、提供するデータを格納する第１のデータベース（ＤＢ）３ａを有している。例えばＤＰが病院の場合、第１のＤＢ３ａには、患者の氏名、治療などの行為の日付、投薬量、病名などのフィールドを含むレコードが登録される。
端末装置１、情報処理装置２、およびサーバ３それぞれは、例えばコンピュータである。すなわち情報処理装置２は、記憶部２−１と処理部２−２とを有する。記憶部２−１は、例えば情報処理装置２が有するメモリ、またはストレージ装置である。処理部２−２は、例えば情報処理装置２が有するプロセッサ、または演算回路である。図１では省略しているが、端末装置１とサーバ３も情報処理装置２と同様に記憶部と処理部とを有する。
端末装置１、情報処理装置２、およびサーバ３が連係動作することで、データ利用者の関心内容の秘匿性を向上可能な制御方法が実現される。端末装置１、情報処理装置２、およびサーバ３の各装置は、例えば制御方法を実現するためのその装置の機能に応じた処理手順が記述された制御プログラムを実行することにより、当該機能を実施する。
次に、端末装置１、情報処理装置２、およびサーバ３の協働による、データ利用者の関心内容の秘匿性を向上可能な制御方法について説明する。
端末装置１は、ＤＵから利用レコード情報１ａの入力を受け付ける。利用レコード情報１ａには、データ利用者が利用する第１のレコード群に含まれるレコードの条件として、所定の属性のフィールドに第１の値が設定されていることが指定されている。図１の例では、利用レコード情報１ａにおいて、属性として「日付」と「投薬量」とが示されている。第１のレコード群に含まれるレコードの条件は、属性「日付」の第１の値が「１月」または「２月」であり、かつ属性「投薬量」の第１の値が「５０ｍｇ」のレコードである。
第１の属性が複数ある場合、利用レコード情報１ａを、表形式の分類マップで表すことができる。例えば端末装置１は、利用レコード情報１ａとして、第１の属性（日付）の値（１月、２月）を列のラベルとし、第２の属性（投薬量）の値（５０ｍｇ）を行のラベルとする表形式の第１の分類マップ１ｂを生成する。端末装置１は、第１の分類マップ１ｂに対し、第１のレコード群における第１の属性の第１の値に対応する行と第１のレコード群における第２の属性の第１の値に対応する列とが交わる位置に、第１のレコード群内のグループを示す第１の分類識別子「ｋｍ１，ｋｍ２」を設定する。
情報処理装置２は、利用レコード情報１ａを、端末装置１から取得する。例えば端末装置１がＤＵから利用レコード情報１ａの入力を受け付け、利用レコード情報１ａを生成したときに、端末装置１が、情報処理装置２に利用レコード情報１ａを送信する。
情報処理装置２は、利用レコード情報１ａを取得すると、複数のレコードが格納された第１のＤＢ３ａを管理するサーバ３に対して、複数のレコードのうちの第１のレコード群と第２のレコード群とを格納した第２のＤＢ３ｂ〜３ｄの生成要求を送信する。第１のレコード群は、所定の属性のフィールドに第１の値が設定されているレコードの集合である。第２のレコード群は、所定の属性のフィールドに、第１の値とは異なる第２の値が設定されているレコードの集合である。第２のレコード群に含まれるレコードは、ＤＵによるデータの利用目的を秘匿するために追加されるレコードであり、ダミーレコードと呼ぶこともできる。
利用レコード情報１ａが第１の分類マップ１ｂで表されている場合、情報処理装置２は、第２の分類マップ２ａを生成する。情報処理装置２は、第２の分類マップ２ａを生成した場合、その第２の分類マップ２ａを含む生成要求をサーバ３に送信する。
第２の分類マップ２ａは、第１の分類マップ１ｂにおける第１の分類識別子「ｋｍ１，ｋｍ２」が設定されていない位置に第２のレコード群内のグループを示す第２の分類識別子「ｋｄ１〜ｋｄ４」を追加した表形式のデータである。
例えば情報処理装置２は、第１の分類マップ１ｂにおいて第１の分類識別子が設定された領域を包含する四角形を、端末装置１からの分類拡張要求に応じて拡大し、拡大された四角形内において第１の分類識別子「ｋｍ１，ｋｍ２」が設定されていない位置に第２の分類識別子「ｋｄ１〜ｋｄ４」を設定する。図１の例では、第１の属性の値「１月〜２月」、第２の属性の値「５０ｍｇ」を囲う四角形が拡大される。図１に示す第２の分類マップ２ａは、第１の分類マップ１ｂの第１の属性の値「３月」を含み、第２の属性の値「１０ｍｇ」を含むように拡大されている。
また情報処理装置２は、複数の第２のＤＢ３ｂ〜３ｄの生成の指示、第１のレコード群と第２のレコード群それぞれの複数のグループへの分類の指示、およびグループごとの格納先となる第２のＤＢの指定を含む生成要求を送信することができる。図１の例では、生成要求において、名称が「ＤＢ１」、「ＤＢ２」、「ＤＢ３」の３つの第２のＤＢ３ｂ〜３ｄの生成が指示されている。また生成要求において、第１の分類識別子「ｋｍ１，ｋｍ２」および第２の分類識別子「ｋｄ１〜ｋｄ４」それぞれに対応するグループへの、第１のレコード群および第２のレコード群の分類が指示されている。さらに生成要求において、第１の分類識別子「ｋｍ１」に対応するレコードと第２の分類識別子「ｋｄ１」に対応するレコードとの格納先は、「ＤＢ１」の第２のＤＢ３ｂに指定されている。第１の分類識別子「ｋｍ２」に対応するレコードと第２の分類識別子「ｋｄ２」に対応するレコードとの格納先が「ＤＢ２」の第２のＤＢ３ｃに指定されている。第２の分類識別子「ｋｄ３」に対応するレコードと第２の分類識別子「ｋｄ４」に対応するレコードとの格納先が「ＤＢ３」の第２のＤＢ３ｄに指定されている。
サーバ３は、情報処理装置２からの生成要求に応じて、第１のＤＢ３ａから第１のレコード群と第２のレコード群とを抽出し、第１のレコード群と第２のレコード群とを含む第２のＤＢ３ｂ〜３ｄを生成する。次にサーバ３は、第２のＤＢ３ｂ〜３ｄを暗号化して秘匿化ＤＢ２ｂ〜２ｄを生成する。そしてサーバ３は、秘匿化ＤＢ２ｂ〜２ｄの照合用の第１の鍵３ｅを生成する。サーバ３は、例えば複数の秘匿化ＤＢ２ｂ〜２ｄごとに異なる第１の鍵３ｅを生成する。サーバ３は、生成した秘匿化ＤＢ２ｂ〜２ｄと第１の鍵３ｅとを、情報処理装置２に送信する。
端末装置１は、ＤＵから検索条件が入力されると、秘匿化ＤＢ２ｂ〜２ｄを検索対象とする検索条件を示すクエリを暗号化し、暗号化されたクエリ１ｃを用いた照合用の第２の鍵１ｄを生成する。端末装置１は、暗号化されたクエリ１ｃの第２の鍵１ｄを、情報処理装置２に送信する。
情報処理装置２は、サーバ３から秘匿化ＤＢ２ｂ〜２ｄと第１の鍵３ｅとを取得すると共に、端末装置１から暗号化されたクエリ１ｃと第２の鍵１ｄとを取得する。そして情報処理装置２は、第１の鍵３ｅと第２の鍵１ｄとを用いて、クエリ１ｃに示される検索条件を満たすレコードを、秘匿化ＤＢ２ｂ〜２ｄから検索する。この検索では、例えばデータを暗号化したままで検索可能な秘匿検索を行うことができる。そして情報処理装置２は、検索結果１ｅを端末装置１に送信する。
このように情報処理装置２が、サーバ３に対して、第１のレコード群と第２のレコード群とを格納した第２のＤＢ３ｂ〜３ｄの生成要求を送信することで、第２のＤＢ３ｂ〜３ｄにダミーレコードを含めることができる。その結果、ＤＵが第１のＤＢ３ａ内のどのようなデータに関心があるのかについて、サーバ３を管理するＤＰによる推定が困難となる。すなわち、ＤＵの関心内容の秘匿性が向上している。
また情報処理装置２は、複数の第２のＤＢ３ｂ〜３ｄの生成の指示、第１のレコード群と第２のレコード群それぞれの複数のグループへの分類の指示、およびグループごとの格納先となる第２のＤＢの指定を含む生成要求を送信することができる。これにより、サーバ３では、複数の第２のＤＢ３ｂ〜３ｄが生成され、さらに複数の秘匿化ＤＢ２ｂ〜２ｄが生成される。その結果、秘匿化ＤＢ２ｂ〜２ｄに対する秘匿検索を行う場合の処理負荷を低減できる。すなわち、秘匿検索は、平文に対する検索よりも処理負荷が高いため、秘匿化ＤＢ２ｂ〜２ｄにダミーレコードを含めると、検索の処理負荷がさらに高くなってしまう。そこで複数の秘匿化ＤＢ２ｂ〜２ｄを生成し、ＤＵは、利用したいレコードを含む秘匿化ＤＢを検索対象として検索要求を入力することで、処理負荷の増加を抑止できる。
また複数の秘匿化ＤＢ２ｂ〜２ｄが生成された場合、端末装置１がダミーのクエリを送信することで、ＤＵの関心内容の秘匿性を向上させることもできる。
例えば端末装置１は、第１の秘匿化ＤＢを検索対象とするクエリを暗号化すると共に、第１の秘匿化ＤＢとは別の第２の秘匿化ＤＢを検索対象とする、ダミーの検索条件を示すダミークエリを暗号化する。そして端末装置１は、暗号化したクエリと、暗号化したダミークエリとを情報処理装置２に送信する。
情報処理装置２は、サーバ３から第１の秘匿化ＤＢと第１の秘匿化ＤＢの第１の鍵３ｅ、および第２の秘匿化データベースと第２の秘匿化データベースの第１の鍵３ｅとを取得する。また情報処理装置２は、端末装置１から、暗号化されたクエリと暗号化されたダミークエリと第２の鍵１ｄとを取得する。
情報処理装置２は、第１の秘匿化ＤＢと第１の秘匿化ＤＢの第１の鍵３ｅとを用いて、クエリに示される検索条件を満たすレコードを、第１の秘匿化ＤＢから検索する。また情報処理装置２は、第２の秘匿化ＤＢと第２の秘匿化ＤＢの第１の鍵３ｅとを用いて、ダミークエリに示されるダミーの検索条件を満たすレコードを、第２の秘匿化ＤＢから検索する。
このように、ＤＵが入力した検索条件に応じたクエリによる検索とは別にダミークエリによる検索を行う場合、情報処理装置２は、サーバ３から、第１の秘匿化ＤＢと第２の秘匿化ＤＢそれぞれの第１の鍵３ｅを取得することとなる。するとサーバ３を管理するＤＰでは、ＤＵの検索の目的となるレコードが、第１の秘匿化ＤＢに含まれるのか、あるいは第２の秘匿化ＤＢに含まれるのかが不明となる。その結果、ＤＵの関心内容の秘匿性が向上する。
なおサーバ３は、第２のＤＢ３ｂ〜３ｄを生成する際に、第１のＤＢ３ａ内の互いに関連するレコードに設定された第１の識別子を、第２の識別子に変換することもできる。例えば第１のＤＢ３ａ内のレコードに氏名のフィールドがあるとき、特定の人物の氏名が設定された複数のレコードは、互いに関連するレコードである。サーバ３は、レコードの内の氏名（第１の識別子）を例えば仮名（第２の識別子）に変換して、その仮名を含むレコードを第２のＤＢ３ｂ〜３ｄに格納する。これにより、ＤＵによる、レコードに示される情報に対応する個人の特定が困難となる。
第１の識別子を第２の識別子に変換する際、サーバ３は、１つの第１の識別子を、複数の第２のＤＢ３ｂ〜３ｄそれぞれで異なる第２の識別子に変換することもできる。これにより、レコードに示される情報に対応する個人の特定の困難性をさらに高めることができる。ただし、ＤＵは、２以上の秘匿化ＤＢにおいて、第１の識別子（氏名）が同じレコードの有無を調査したい場合がある。図１の例であれば、１月に５０ｍｇの薬を投与した患者に対して、２月にも同じ５０ｍｇの薬を投与したか否かを調査したい場合である。この場合、氏名「Ａ氏」が第２のＤＢ３ｂ〜３ｃごとに異なる仮名「ＥＦＧ」、「ＥＥＥ」に変換されていると、１月に５０ｍｇの薬を投与した患者と２月に５０ｍｇの薬を投与した患者とが同じ患者なのかが分からない。この場合、情報処理装置２は、サーバ３に名寄せを依頼することができる。
図２は、名寄せを伴う場合の制御方法の一例を示す図である。サーバ３は、第２のＤＢ３ｂ〜３ｄを生成する際に、第１のＤＢ３ａ内の互いに関連する複数の関連レコードに共通に設定された第１の識別子を、複数の関連レコードそれぞれの格納先の第２のＤＢ３ｂ〜３ｄごとに異なる第２の識別子に変換する。次にサーバ３は、第２の識別子を有する複数の関連レコードを複数の第２のＤＢ３ｂ〜３ｄに格納する。さらにサーバ３は、第１の識別子と第２の識別子との対応関係を示す対照表３ｆを生成する。
端末装置１は、２以上の第２のＤＢを検索対象とするクエリを暗号化し、情報処理装置２に送信する。
情報処理装置２は、暗号化された第１のクエリに示される検索条件を満たすレコードの、検索対象の秘匿化ＤＢ２ｂ〜２ｄからの検索を行う。次に情報処理装置２は、検索対象の秘匿化ＤＢ２ｂ〜２ｄ内の検索条件を満たすレコードに含まれる第２の識別子のリストである識別子リスト２ｅ，２ｆを、検索対象の秘匿化ＤＢ２ｂ〜２ｄごとに生成する。そして情報処理装置２は、識別子リスト２ｅ，２ｆをサーバ３に送信する。
サーバ３は、対照表３ｆに基づいて、識別子リスト２ｅ，２ｆに示される第２の識別子を、対応する第１の識別子に変換することで、検索対象の秘匿化ＤＢ２ｂ〜２ｄごとの第１の識別子のリストを生成する。次にサーバ３は、検索対象の秘匿化ＤＢ２ｂ〜２ｄごとの第１の識別子のリスト間の和集合または積集合を求める。そしてサーバ３は、求めた和集合または積集合に含まれる第１の識別子の数を検索結果１ｆとして情報処理装置２に送信する。情報処理装置２は、検索結果１ｆを端末装置１に転送する。
このように名寄せを行うことで、ＤＵによる個人の情報の特定の困難性を高めながら、２以上の秘匿化ＤＢにおける第１の識別子が同じレコードの有無の検索が可能となる。すなわち、個人情報の秘匿性を高めることによるＤＵの利便性の低下を抑止することができる。
なお、名寄せを伴う場合においても、端末装置１がダミーのクエリを送信することで、ＤＵの関心内容の秘匿性を向上させることができる。
例えば端末装置１は、第１の秘匿化ＤＢと第２の秘匿化ＤＢとを検索対象とする複数のクエリを暗号化すると共に、第１の秘匿化ＤＢと第２の秘匿化ＤＢとを検索対象とする、複数のダミークエリを暗号化する。そして端末装置１は、暗号化された複数のクエリと暗号化された複数のダミークエリとを情報処理装置２に送信する。
情報処理装置２は、複数のクエリそれぞれに示される検索条件を満たすレコードを、第１の秘匿化ＤＢまたは第２の秘匿化ＤＢから検索する。また情報処理装置２は、複数のダミークエリそれぞれに示されるダミーの検索条件を満たすレコードを、第１の秘匿化ＤＢまたは第２の秘匿化ＤＢから検索する。
このようにダミークエリを送信することにより、名寄せの際の和集合または積集合の演算対象となる識別子リストの組み合わせ数が多くなる。その結果、ＤＵの関心内容の秘匿性が向上する。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ＤＵにおけるデータ利用目的の推定を困難にしながらも、ＤＵ側に検索結果からの対象ＤＢの再現の意図がある場合に、ＤＰ側においてその意図を検知できるようにした秘密情報管理システムである。
図３は、第２の実施の形態に係る秘密情報管理システムの一例を示す図である。第２の実施の形態では、患者データ収集活用基盤１２がクラウドによって構築されている。患者データ収集活用基盤１２はＴＴＰサーバ１００を有している。ＴＴＰサーバ１００は、患者データを暗号文のままで管理するコンピュータである。ＴＴＰサーバ１００は、ネットワーク２０を介して、病院１３のＤＰサーバ２００と製薬企業１５のＤＵ端末３００に接続されている。
病院１３のＤＰサーバ２００は、病院１３で受診した患者の電子カルテなどの患者データを蓄積し、その患者データを暗号化してＴＴＰサーバ１００に提供するコンピュータである。製薬企業１５のＤＵ端末３００は、ＴＴＰサーバ１００で管理されている患者データを検索するために、製薬企業１５の社員が使用するコンピュータである。
なおＴＴＰサーバ１００は、第１の実施の形態に示した情報処理装置２の一例である。ＤＰサーバ２００は、第１の実施の形態に示したサーバ３の一例である。ＤＵ端末３００は、第１の実施の形態に示した端末装置１の一例である。
このような秘密情報管理システムは、例えば医療情報を活用した新薬開発の効率化に有用である。例えば、製薬企業１５が、治験を行う場合、対象疾患の患者がどの程度存在するか等を考慮して計画を立案することで、治験の成功率を向上させることができる。そこで、患者データ収集活用基盤１２において多数の病院１３に分散する患者の電子カルテから抽出した患者データを集中管理することで、目的の疾患を有する患者の情報を容易に得ることが可能となる。
図４は、ＴＴＰサーバのハードウェアの一例を示す図である。ＴＴＰサーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
メモリ１０２は、ＴＴＰサーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。
バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。
ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。
グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＢＤ（Blu-ray（登録商標） Disc）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
機器接続インタフェース１０７は、ＴＴＰサーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
ＴＴＰサーバ１００は、以上のようなハードウェアによって、第２の実施の形態の処理機能を実現することができる。ＤＰサーバ２００とＤＵ端末３００も、ＴＴＰサーバ１００と同様のハードウェアにより実現することができる。また、第１の実施の形態に示した端末装置１、情報処理装置２、およびサーバ３も、図４に示したＴＴＰサーバ１００と同様のハードウェアにより実現することができる。
ＴＴＰサーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。ＴＴＰサーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、ＴＴＰサーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またＴＴＰサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
図５は、秘密情報管理システムの各装置の機能を示すブロック図である。ＴＴＰサーバ１００は、分析目的かく乱部１１０、秘匿化ＤＢ取得部１２０、秘匿化ＤＢ記憶部１３０、および検索部１４０を有する。
分析目的かく乱部１１０は、ＤＵ端末３００からの分類要求に応じて、分類マップの拡張およびデータ分割基準情報の生成を行う。データ分割基準情報は、生成する複数の部分ＤＢそれぞれに格納するレコードの種別を示す情報である。例えば分析目的かく乱部１１０は、ＤＵ端末３００から、分類マップを含む分類要求を取得する。分類要求に含まれる分類マップ（真の分類マップ）には、ＤＵが検索対象とすることを希望するレコード内の属性の値（例えば属性「投薬量」の値「５０ｍｇ」）が指定されている。分析目的かく乱部１１０は、真の分類マップにダミーのレコード内の属性の値を追加した拡張分類マップを生成する。そして分析目的かく乱部１１０は、拡張分類マップに示される各属性の値を有するレコードについて、複数の部分ＤＢのどのＤＢに格納するのかを決定し、決定内容を示すデータ分割基準情報生成する。そして分析目的かく乱部１１０は、拡張分類マップとデータ分割基準情報とを含む分類要求をＤＰサーバ２００に送信する。また分析目的かく乱部１１０は、拡張分類マップとデータ分割基準情報とを、ＤＵ端末３００に送信する。
なお真の分類マップは、第１の実施の形態に示した第１の分類マップ１ｂの一例である。また拡張分類マップは、第１の実施の形態に示した第２の分類マップ２ａの一例である。
秘匿化ＤＢ取得部１２０は、ＤＰサーバ２００で暗号化された複数の部分ＤＢをＤＰサーバ２００から取得し、秘匿化ＤＢ記憶部１３０に格納する。
秘匿化ＤＢ記憶部１３０は、暗号化されたデータを記憶するデータベースである。例えばＴＴＰサーバ１００のメモリ１０２またはストレージ装置１０３の記憶領域の一部が、秘匿化ＤＢ記憶部１３０として使用される。
検索部１４０は、ＤＵ端末３０からの検索要求に応じて、秘匿化ＤＢ内のデータ検索を行う。検索要求には、例えば暗号化されたクエリが含まれる。検索部１４０は、暗号化されたクエリと秘匿化ＤＢ内のデータとを暗号化されたまま照合し、クエリに示される検索条件を満たすレコードを抽出する。暗号データ間の照合を行うため、検索部１４０は、例えばＤＵ端末３００とＤＰサーバ２００とのそれぞれから照合鍵を取得する。検索部１４０は、２つの照合鍵を用いて、クエリおよびデータを復号せずに照合を行う。暗号データのままでの検索技術としては、例えば、前述の特許技術文献１，２に開示された、リレーショナル暗号化（Relational Encryption）を用いた秘匿検索技術がある。
また検索部１４０は、検索要求に、複数の秘匿化ＤＢの検索結果の名寄せ指示が含まれる場合、秘匿化ＤＢごとの検索結果をＤＰサーバ２００に送信する。名寄せとは、異なる秘匿化ＤＢの検索結果に含まれるレコードのうち、互いに関連するレコードを同じ要素とみなし、秘匿化ＤＢごとの検索結果に示される集合の和集合または積集合内の要素の数を計数する処理である。互いに関連するレコードとは、例えば同じ患者に関するレコードである。検索部１４０は、ＤＰサーバ２００による名寄せ後の検索結果を、ＤＵ端末３００に送信する。
ＤＰサーバ２００は、ＤＢ２１０、分類部２２０、対照表記憶部２３０、暗号化部２４０、および検索支援部２５０を有する。
ＤＢ２１０は、患者の診療履歴など、秘匿性の高いデータを格納するデータベースである。例えばＤＰサーバ２００が有するストレージ装置の記憶領域の一部が、ＤＢ２１０として使用される。
分類部２２０は、ＴＴＰサーバ１００からデータ分割基準情報を含む分類要求を取得すると、データ分割基準情報に従って、ＤＢ２１０から抽出したデータを複数の部分ＤＢに分類する。例えば分類部２２０は、データ分割基準情報に示される数の部分ＤＢを生成する。次に分類部２２０は、データ分割基準情報に基づいて、各部分ＤＢに対応する属性のデータをＤＢ２１０から抽出し、抽出したデータを対応する部分ＤＢに格納する。分類部２２０は、生成した複数の部分ＤＢを暗号化部２４０に送信する。
なおＤＢ２１０は、第１の実施の形態に示した第１のＤＢ３ａの一例である。また部分ＤＢは、第１の実施の形態に示した第２のＤＢ３ｂ〜３ｄの一例である。
また分類部２２０は、部分ＤＢにデータを格納する際、人名を含むデータについては、人名を仮の名前（仮名）に変換する。分類部２２０は、人名の仮名への変換を行った場合、人名と仮名との対応関係を示す対照表を生成する。分類部２２０は、生成した対照表を対照表記憶部２３０に格納する。
暗号化部２４０は、分類部２２０が生成した部分ＤＢを、それぞれ異なる鍵で暗号化する。暗号化部２４０は、暗号化した後の部分ＤＢ（秘匿化ＤＢ）を、ＴＴＰサーバ１００に送信する。また暗号化部２４０は、各秘匿化ＤＢ内のデータの照合に用いる照合鍵を、検索支援部２５０に送信する。
検索支援部２５０は、ＴＴＰサーバ１００による秘匿化ＤＢ内のデータ検索を支援する。例えば検索支援部２５０は、暗号化部２４０から取得した各秘匿化ＤＢの照合鍵を、対応する秘匿化ＤＢの識別子に対応付けて記憶する。そして検索支援部２５０は、ＴＴＰサーバ１００からの要求に応じて、データ検索に使用する照合鍵をＴＴＰサーバ１００に送信する。
また検索支援部２５０は、ＴＴＰサーバ１００から名寄せ対象の検索結果を取得した場合、対照表に基づいて名寄せを行う。そして検索支援部２５０は、名寄せ後の検索結果をＴＴＰサーバ１００に送信する。
ＤＵ端末３００は、分類要求部３１０、分類マップ記憶部３２０、および検索要求部３３０を有する。
分類要求部３１０は、ＤＵにより入力された分析対象を示す真の分類マップを含む分類要求を、ＴＴＰサーバ１００に送信する。そして分類要求部３１０は、ＴＴＰサーバ１００から拡張分類マップとデータ分割基準情報とを取得する。分類要求部３１０は、取得した拡張分類マップとデータ分割基準情報とを、分類マップ記憶部３２０に格納する。
分類マップ記憶部３２０は、拡張分類マップとデータ分割基準情報とを記憶する。例えばＤＵ端末３００が有するメモリまたはストレージ装置の記憶領域の一部が、分類マップ記憶部３２０として使用される。
検索要求部３３０は、ＤＵが入力した検索条件に応じたクエリを暗号化し、暗号化されたクエリ（秘匿化クエリ）を含む検索要求をＴＴＰサーバ１００に送信する。また検索要求部３３０は、検索要求に、秘匿化クエリを用いたデータの照合に使用する照合鍵を含める。なお検索要求部３３０は、検索条件が入力されると、データ分割基準情報を参照し、検索対象の属性のデータを含む秘匿化ＤＢを、検索対象として特定する。そして検索要求部３３０は、検索要求において、複数の秘匿化ＤＢのうちの検索対象とする秘匿化ＤＢを指定する。
検索要求部３３０は、ＴＴＰサーバ１００から検索結果を受け取ると、検索結果をモニタなどに出力する。
検索要求部３３０は、２以上の秘匿化ＤＢへの検索要求の検索結果の名寄せ指示を検索要求に含めることもできる。さらに検索要求部３３０は、入力された検索条件に対応する検索要求を送信する際に、ダミーのクエリを暗号化した秘匿ダミークエリを含む検索要求をＴＴＰサーバ１００に送信してもよい。この場合、検索要求部３３０は、入力された検索条件に対応する検索要求と秘匿化クエリに対応する検索要求との送信の順番をランダムに決定する。
なお、図５に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図５に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
次に、ＤＰが病院の場合にＤＢ２１０に格納されるデータの例を説明する。
図６は、ＤＢの一例を示す図である。ＤＢ２１０には、例えば氏名、日時、投薬量、病名、血圧などの項目を有する複数のレコードが登録されている。氏名の項目には、患者の氏名が設定される。日時の項目には、該当患者に対して投薬などの治療を行った日時が設定される。図６の例では、日時のうちの日と時刻は省略されている。投薬量の項目には、患者に投薬された薬の量が設定される。病名の項目には、該当患者の病名が設定される。血圧の項目には、該当患者の投薬時の血圧が設定される。
次に、分類マップ記憶部３２０に格納される拡張分類マップとデータ分割基準情報との生成例について説明する。
図７は、拡張分類マップとデータ分割基準情報との生成処理の一例を示す図である。ＤＵ端末３００の分類要求部３１０は、ＤＵからの分析対象の入力に応じて真の分類マップ３１を生成する。図７の例では、ＤＵは、薬５０ｍｇを１ヶ月ごとに３ヶ月間投与した患者の数を知りたいものとする。この場合、ＤＵは、分析対象として、例えば２０１９年１月に５０ｍｇの薬を投与された患者、２０１９年２月に５０ｍｇの薬を投与された患者、および２０１９年３月に５０ｍｇの薬を投与された患者を指定する入力を行う。すると分類要求部３１０は、分析対象を示す真の分類マップ３１を生成する。
真の分類マップ３１は、表形式のデータである。真の分類マップ３１の一方のラベル（列のラベル）には日付に関する属性の値が設定され、他方のラベル（行のラベル）には投薬量に関する属性の値が設定されている。列と行との交わる位置（セル）には、その位置に対応する属性の値の組み合わせを有するデータが分析対象である場合に、該当するレコードの分類識別子が設定されている。図７の例では、属性の値の組「２０１９年１月、５０ｍｇ」のデータの分類識別子は「ｋｍ１」である。属性の値の組「２０１９年２月、５０ｍｇ」のデータの分類識別子は「ｋｍ２」である。属性の値の組「２０１９年３月、５０ｍｇ」のデータの分類識別子は「ｋｍ３」である。真の分類マップ３１において、分析対象の属性に対応する位置以外には、分類識別子は設定されていない。
このような真の分類マップ３１を例えばＤＰに開示すると、ＤＵの分析の意図がＤＰに推定されてしまう。例えば真の分類マップ３１では、１月から３月までの３ヶ月の期間内に薬を５０ｍｇだけ投与した患者のデータのみが分析対象となっている。この場合において真の分類マップ３１がＤＰに開示されてしまうと、ＤＰでは、薬５０ｍｇを継続して３ヶ月投薬した場合の効果の調査が目的であることが推定できる。
分類要求部３１０は、真の分類マップ３１を含む分類要求を、ＴＴＰサーバ１００に送信する。するとＴＴＰサーバ１００の分析目的かく乱部１１０は、ＤＵの分析目的を隠ぺいするために、真の分類マップ３１にかく乱用の分類識別子を追加した拡張分類マップ３２を生成する。以下、かく乱用の分類識別子を、特にダミー分類識別子と呼ぶことがある。
例えば分析目的かく乱部１１０は、各属性の値の数（列数と行数）が、ｄ個（ｄは、１以上の整数）以上となるように、拡張分類マップ３２を生成する。図７には、ｄ＝３の場合の拡張分類マップ３２の例が示されている。拡張分類マップ３２では、日付の属性の値として「２０１９年４月」が追加されている。また拡張分類マップ３２では、投薬の属性の値として「１０ｍｇ」が追加されている。
そして拡張分類マップ３２で分析対象の範囲として設定された各属性の値の組み合わせのうち、分類識別子が未設定のセルに、ダミー分類識別子が設定されている。例えば属性の値の組「２０１９年１月、１０ｍｇ」に対応するセルには、ダミー分類識別子「ｋｄ１」が設定されている。属性の値の組「２０１９年２月、１０ｍｇ」に対応するセルには、ダミー分類識別子「ｋｄ２」が設定されている。属性の値の組「２０１９年３月、１０ｍｇ」に対応するセルには、ダミー分類識別子「ｋｄ３」が設定されている。属性の値の組「２０１９年４月、１０ｍｇ」に対応するセルには、ダミー分類識別子「ｋｄ４」が設定されている。属性の値の組「２０１９年４月、５０ｍｇ」に対応するセルには、ダミー分類識別子「ｋｄ５」が設定されている。
拡張分類マップ３２を生成後、分析目的かく乱部１１０は、データ分割基準情報３３を生成する。データ分割基準情報３３には、分類識別子に対応するレコードの格納先とする部分ＤＢの識別子が設定されている。例えばデータ分割基準情報３３は、拡張分類マップ３２と同様のラベルを有する表で表される。その場合、データ分割基準情報３３における属性の値の組に対応するセルには、拡張分類マップ３２内の同じ位置のセルに設定された分類識別子に対応するレコードの格納先となる部分ＤＢの識別子（部分ＤＢ識別子）が設定される。
なお分析目的かく乱部１１０は、データ分割基準情報３３において、例えば１つの部分ＤＢ内にｎ個（ｎは２以上の整数）以上の分類識別子またはダミー分類識別子を対応付ける。図７の例では、ｎ＝２である。この場合、各部分ＤＢ内に、属性の値の２種類の組み合わせパターンそれぞれに対応するレコードが格納される。
図７の例では、部分ＤＢ識別子「ＤＢ１」の部分ＤＢには、分類識別子「ｋｍ１」に対応する属性の値の組を有するレコードと、ダミー分類識別子「ｋｄ１」に対応する属性の値の組を有するレコードとが格納される。部分ＤＢ識別子「ＤＢ２」の部分ＤＢには、分類識別子「ｋｍ２」に対応する属性の値の組を有するレコードと、ダミー分類識別子「ｋｄ２」に対応する属性の値の組を有するレコードとが格納される。部分ＤＢ識別子「ＤＢ３」の部分ＤＢには、分類識別子「ｋｍ３」に対応する属性の値の組を有するレコードと、ダミー分類識別子「ｋｄ３」に対応する属性の値の組を有するレコードとが格納される。部分ＤＢ識別子「ＤＢ４」の部分ＤＢには、ダミー分類識別子「ｋｄ４」に対応する属性の値の組を有するレコードと、ダミー分類識別子「ｋｄ５」に対応する属性の値の組を有するレコードとが格納される。
分析目的かく乱部１１０は、拡張分類マップとデータ分割基準情報とを含む分類要求をＤＰサーバ２００に送信する。また分析目的かく乱部１１０は、拡張分類マップ３２とデータ分割基準情報３３とを、ＤＵ端末３００に送信する。拡張分類マップ３２とデータ分割基準情報３３とを受信したＤＵ端末３００では、分類要求部３１０が、拡張分類マップ３２とデータ分割基準情報３３とを分類マップ記憶部３２０に格納する。
データ分割基準情報３３を受信したＤＰサーバ２００では、分類部２２０が、データ分割基準情報３３に従って部分ＤＢを生成する。
図８は、部分ＤＢの生成例を示す図である。ＤＰサーバ２００の分類部２２０は、まずデータ分割基準情報３３に示される部分ＤＢ識別子それぞれに対応する部分ＤＢ４１〜４４を生成する。次に分類部２２０は、データ分割基準情報３３において各部分ＤＢ４１〜４４に対応付けられた分類識別子に対応するレコードをＤＢ２１０から抽出し、該当する部分ＤＢに格納する。例えば分類部２２０は、分類識別子「ｋｍ１」に対応するレコードとダミー分類識別子「ｋｄ１」に対応するレコードとを部分ＤＢ４１に格納する。分類部２２０は、分類識別子「ｋｍ２」に対応するレコードとダミー分類識別子「ｋｄ２」に対応するレコードとを部分ＤＢ４２に格納する。分類部２２０は、分類識別子「ｋｍ３」に対応するレコードとダミー分類識別子「ｋｄ３」に対応するレコードとを部分ＤＢ４３に格納する。分類部２２０は、ダミー分類識別子「ｋｄ４」に対応するレコードとダミー分類識別子「ｋｄ５」に対応するレコードとを部分ＤＢ４４に格納する。
図８の例では、部分ＤＢ４１〜４４それぞれには、属性の値の２種類の組み合わせパターンそれぞれに対応するレコードが格納される。そのため、ＤＵ端末３００がいずれかの部分ＤＢ内を検索したことをＤＰが認識しても、ＤＰでは、どのような属性の値を有するレコードが分析目的となっているのかを一意に特定することはできない。すなわち、真の分析目的の推定の尤度が１／ｎ（図８の例では１／２）となるようにかく乱されている。
分類部２２０は、部分ＤＢ４１〜４４に登録された各レコードに患者の氏名が含まれる場合、部分ＤＢ４１〜４４内の各レコードの氏名を仮名に変換する。この際、分類部２２０は、１人の氏名について、部分ＤＢごとに異なる仮名に変換する。そして分類部２２０は、氏名と仮名との対応関係を示す対照表２３１を生成する。
図９は、対照表の一例を示す図である。対照表２３１には、氏名の欄と仮名の欄とが設けられている。氏名の欄には、部分ＤＢ４１〜４４のいずれかに格納されたレコードに含まれる氏名が設定される。仮名の欄は、部分ＤＢ識別子ごとの欄に分けられている。そして対照表２３１では、部分ＤＢ識別子で示される部分ＤＢ内のレコードに示される仮名が、その部分ＤＢ識別子の列の、その仮名に対応する氏名の行に設定されている。
例えばＤＢ２１０において、氏名「Ｙ田Ｔ郎」のレコードは２つある。そのうちの１つめのレコード（日時「２０１９年１月」、投薬量「５０ｍｇ」）の格納先は、部分ＤＢ識別子「ＤＢ１」の部分ＤＢ４１である。もう一方のレコード（日時「２０１９年２月」、投薬量「５０ｍｇ」）の格納先は、部分ＤＢ識別子「ＤＢ２」の部分ＤＢ４２である。対照表２３１では、氏名「Ｙ田Ｔ郎」のレコードの部分ＤＢ４１内での仮名は「ＡＢＣ」であり、部分ＤＢ４２内での仮名は「ＡＡＡ」であることが示されている。同様に、他の氏名に対応する部分ＤＢごとの仮名も、対照表２３１に設定されている。
図１０は、部分ＤＢへのレコードの分類例を示す図である。部分ＤＢ４１〜４４には、ＤＢ２１０内のレコードに分類識別子のフィールドを追加したレコードが登録されている。追加された分類識別子のフィールドには、該当するレコードの拡張分類マップ３２における分類識別子が設定される。また部分ＤＢ４１〜４４に設定された各レコードの氏名のフィールドは仮名に変換されている。
分類部２２０は、部分ＤＢ４１〜４４内のレコードをフィールドごとに暗号化して、秘匿化ＤＢを生成する。
図１１は、秘匿化ＤＢの生成例を示す図である。例えば分類部２２０は、部分ＤＢ４１〜４４それぞれを、部分ＤＢ４１〜４４それぞれに対応する鍵で暗号化する。例えば分類部２２０はＤＢ暗号鍵群４５を生成する。ＤＢ暗号鍵群４５は、部分ＤＢ４１〜４４それぞれに対応するプレ照合鍵（各プレ照合鍵のコードを「Ｋ１〜Ｋ４」とする）を含む。分類部２２０は、ＤＢ暗号鍵群４５に含まれる複数の照合鍵で部分ＤＢ４１〜４４の暗号化を行う。分類部２２０は、暗号化によって生成された秘匿化ＤＢ１３１〜１３４をＴＴＰサーバ１００に送信する。ＴＴＰサーバ１００では、秘匿化ＤＢ取得部１２０が秘匿化ＤＢ１３１〜１３４を受け取り、それらの秘匿化ＤＢ１３１〜１３４を秘匿化ＤＢ記憶部１３０に格納する。
ＴＴＰサーバ１００では、秘匿化ＤＢ１３１〜１３４それぞれに識別子（秘匿化ＤＢ識別子）が付与されている。図１１の例では、秘匿化ＤＢ１３１の秘匿化ＤＢ識別子は「Ｅｖａｌ１」である。秘匿化ＤＢ１３２の秘匿化ＤＢ識別子は「Ｅｖａｌ２」である。秘匿化ＤＢ１３３の秘匿化ＤＢ識別子は「Ｅｖａｌ３」である。秘匿化ＤＢ１３４の秘匿化ＤＢ識別子は「Ｅｖａｌ４」である。
図１２は、秘匿化ＤＢ内の暗号化されたレコードの一例を示す図である。秘匿化ＤＢ１３１〜１３４では、各レコードのフィールドのうち、分類識別子と氏名とのフィールド以外のフィールドに設定された値が、その値ごとに暗号化されている。図１２の例では、暗号鍵（Ｋ１〜Ｋ４）の右の括弧内に示される値が、その暗号鍵で暗号化された値である。
なお分類識別子のフィールドの値は管理用に追加した情報であるため、暗号化は不要である。また氏名のフィールドの値は仮名への変換によって元の名前が既に秘匿化されているため、暗号化は不要である。
ＤＵ端末３００は、ＤＵから入力された検索条件に基づいて、秘匿化ＤＢ１３１〜１３４内のデータの秘匿検索を行う。
図１３は、秘匿検索処理の概要を示す図である。ＤＵ端末３００の検索要求部３３０は、検索条件を示すクエリ５１を生成する。次に検索要求部３３０は、クエリ用の暗号鍵５３を用いてクエリを暗号化する（暗号鍵５３のコードを「Ｑ」とする）。そして検索要求部３３０は、暗号化によって生成された秘匿化クエリ５２を含む検索要求をＴＴＰサーバ１００に送信する。検索要求には、検索対象の秘匿化ＤＢの識別子が含まれる。この際、検索要求部３３０は、暗号鍵５３をプレ照合鍵５４に変換する（プレ照合鍵５４のコードを「ｐｋｑ」とする）。プレ照合鍵５４は、秘匿検索における照合に用いる鍵である。検索要求部３３０は、プレ照合鍵５４をＴＴＰサーバ１００に送信する。
検索要求を受信したＴＴＰサーバ１００では、検索部１４０が検索要求に従った検索を行う。例えば検索部１４０は、ＤＰサーバ２００に対して、検索対象の秘匿化ＤＢの照合鍵を要求する。ＤＰサーバ２００の検索支援部２５０は、ＴＴＰサーバ１００からの要求に応じて、検索対象の秘匿化ＤＢの暗号化に用いた暗号鍵をプレ照合鍵に変換する。そして検索支援部２５０は、変換によって生成されたプレ照合鍵をＴＴＰサーバ１００に送信する。なお検索支援部２５０は、予めＤＢ暗号鍵群４５内の複数の暗号鍵それぞれをプレ照合鍵に変換し、複数のプレ照合鍵を含むプレ照合鍵群４６を生成しておいてもよい。
ＴＴＰサーバ１００の検索部１４０は、ＤＵ端末３００とＤＰサーバ２００とのそれぞれから取得したプレ照合鍵を用いて、秘匿化クエリ５２に示される検索条件にヒットするレコードを、検索対象の秘匿化ＤＢから検索する。検索部１４０は検索結果５５をＤＵ端末３００に送信する。検索結果５５には、例えば検索でヒットしたレコードの件数が示されている。
図１４は、秘匿検索の一例を示す図である。ＤＰサーバ２００の暗号化部２４０は、部分ＤＢ４７内のデータを暗号鍵４５ａで暗号化し、秘匿化ＤＢ４８を生成する。例えば部分ＤＢ４７に登録されているレコードの各フィールドには、「Ａ薬」、「Ｂ薬」などの薬剤名と、「胃痛」、「がん」などの病名が含まれる。暗号化部２４０は、レコード内のフィールドごと、そのフィールド内に設定されている文字列を暗号化する。その結果、秘匿化ＤＢ４８には、フィールド内の文字列ごとの暗号文（「ＸＹＺ」、「ＹＺＡ」など）が含まれる。
暗号化部２４０は秘匿化ＤＢ４８をＴＴＰサーバ１００に送信する。ＴＴＰサーバ１００の秘匿化ＤＢ取得部１２０は、秘匿化ＤＢ４８を秘匿化ＤＢ記憶部１３０に格納する。
ＤＵ端末３００の検索要求部３３０は、秘匿化ＤＢ４８を検索対象とするクエリ５６を暗号鍵５７で暗号化し、秘匿化クエリ５８を生成する。図１４の例では、クエリ５６内に「Ａ薬」と「胃痛」という２つの単語が含まれている。この場合、検索要求部３３０は単語ごとに暗号化する。その結果、秘匿化クエリ５８には、単語ごとの暗号文「ＡＢ１」と「ＣＤ２」が含まれる。
また検索要求部３３０は、暗号鍵５７をプレ照合鍵５９に変換する。そして検索要求部３３０は、秘匿化クエリ５８とプレ照合鍵５９とをＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００の検索部１４０は、秘匿化ＤＢ４８のプレ照合鍵をＤＰサーバ２００に要求する。ＤＰサーバ２００の検索支援部２５０は、部分ＤＢ４７の暗号化に用いた暗号鍵４５ａをプレ照合鍵４６ａに変換し、プレ照合鍵４６ａをＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００の検索部１４０は、秘匿化ＤＢ４８内の各暗号文と、秘匿化クエリ５８の各暗号文との総当たりの組み合わせを生成し、検証ＤＢ１４１に登録する。検証ＤＢ１４１は、例えばメモリ１０２またはストレージ装置１０３に格納される。図１４の例では、検証ＤＢ１４１には、「Ａ薬」の暗号文「ＡＢ１」と秘匿化ＤＢ４８内の暗号文それぞれとの組み合わせ、および「胃痛」の暗号文「ＣＤ２」と秘匿化ＤＢ４８内の暗号文それぞれとの組み合わせとが含まれる。
検索部１４０は、検証ＤＢ１４１内のすべての組み合わせを検証対象として、暗号文の元の平文が一致するか否かを検証する。例えば検索部１４０は、リレーショナル暗号化技術を用いれば、ＤＵ端末３００から取得したプレ照合鍵５９とＤＰサーバ２００から取得したプレ照合鍵４６ａを用いて、２つの暗号文が一致するか否かを、その暗号文を復号せずに照合できる。なお検索部１４０は、プレ照合鍵として復号鍵を取得した場合、各暗号文を復号して、復号後の平文で照合することも可能である。
図１４の例では、クエリ５６に示される「Ａ薬」を含むレコードとして、１つ目と２つ目のレコードが検出される。またクエリ５６に示される「胃痛」を含むレコードとして、１つ目のレコードが検出される。その結果、検索部１４０からＤＵ端末３００へ、該当する患者が「１名」であることを示す検索結果６０が送信される。
図１５は、秘匿検索の具体例を示す図である。図１５は、２０１９年１月に薬５０ｍｇを投与した心臓病の患者の数を検索する例が示されている。ＤＵ端末３００の検索要求部３３０は、検索の文字列として「心臓病」を含むクエリ６１を生成する。検索要求部３３０は、生成したクエリ６１を暗号鍵で暗号化し、秘匿化クエリ６２を生成する。検索要求部３３０は、日時「２０１９年１月」と投薬量「５０ｍｇ」との属性の値の組に対応するレコードを含む秘匿化ＤＢ１３１を検索対象として指定し、秘匿化クエリ６２を含む検索要求をＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００の検索部１４０は、ＤＵ端末３００から秘匿化クエリ６２に対応するプレ照合鍵５９を取得すると共に、ＤＰサーバ２００から、秘匿化ＤＢ１３１に対応するプレ照合鍵４６ｂを取得する。次に、検索部１４０は、秘匿化ＤＢ１３１内の日時、投薬量、病名、血圧それぞれの暗号文と、秘匿化クエリ６２に示される暗号文との組み合わせを有する検証ＤＢ１４２を生成する。そして検索部１４０は、２つのプレ照合鍵５９，４６ｂを用いて、検証ＤＢ１４２における暗号文の組ごとに、暗号文の元の平文同士の同一性を検証する。図１５の例では、検証ＤＢ１４２の２つ目のレコードの「病名」のフィールドの暗号文と、秘匿化クエリ６２の暗号文と検証結果のみが一致となる。
検索部１４０は、例えば、レコード内の各フィールドの値の検証結果を示す検証結果表６３を生成する。検証結果表６３では、検証によって一致と判定されたレコードのフィールドに対応する位置に、一致を示すフラグ「１」が設定されている。また検証結果表６３では、検証によって不一致と判定されたレコードのフィールドに対応する位置に、不一致を示すフラグ「０」が設定されている。
そして、検索部１４０は、検証結果表６３において、少なくとも１つのフィールドに一致を示すフラグ「１」が設定されたレコードの数を計数する。そして検索部１４０は、計数した結果を、検索結果６４（検索条件に合致する患者数）としてＤＵ端末３００に送信する。
このような秘匿検索では、秘匿化ＤＢ４８のフィールドごとの暗号文それぞれと、クエリに示された単語ごとの暗号文それぞれとの総当たりの組み合わせすべてについて、検証処理を行うこととなる。そのため、検索対象のＤＢ内のデータ量が膨大になると、ＴＴＰサーバ１００における検索処理の負荷が過大となる。第２の実施の形態では、ＤＵからの要求に応じて予め部分ＤＢ４７を生成し、部分ＤＢ４７を暗号化した秘匿化ＤＢ４８のみを検索対象とすることができる。その結果、検証ＤＢ１４１内に登録される検証対照の暗号文の組み合わせ数が抑止され、検索処理負荷が軽減されている。
さらに、図１３に示すように多数の秘匿化ＤＢ１３１〜１３４が生成され、秘匿化ＤＢ１３１〜１３４それぞれが異なる暗号鍵で暗号化されている。そのため、ＤＵがすべての秘匿化ＤＢ１３１〜１３４についての網羅的な検索を試みる場合には、ＤＵ端末３００は、秘匿化ＤＢ１３１〜１３４ごとに異なるプレ照合鍵をＤＰサーバ２００から取得することとなる。網羅的な検索とは、ＤＢ内に含まれる可能性のあるすべてのキーワードを用いて、すべての秘匿化ＤＢ１３１〜１３４を検索するような検索である。網羅的な検索は、例えばＤＢ２１０の内容全体を推定することを目的として行われる場合がある。
網羅的な検索が行われると、ＤＰサーバ２００に対するプレ照合鍵の取得要求が頻発し、ＤＰサーバ２００において、ＤＵ端末３００が網羅的に検索を試みていることを検知できる。ＤＰサーバ２００では、網羅的な検索を検知した場合、その後の検索に対するプレ照合鍵の送信を抑止することができる。プレ照合鍵の送信を抑止することで、ＤＢ２１０の内容が推定されることを抑止できる。
また各秘匿化ＤＢ１３１〜１３４には、ｎ個以上の種類のデータが含まれている。そのため、ＤＵの検索目的がかく乱されている。
図１６は、検索目的のかく乱の第１の例を示す図である。図１６では、図１５に示した検索におけるかく乱状況を示している。この例では、検索対象は秘匿化ＤＢ１３１である。ＴＴＰサーバ１００がこの検索を実施するには、ＤＰサーバ２００から秘匿化ＤＢ１３１用のプレ照合鍵４６ｂを取得することとなる。するとＤＰ側では、ＤＵの検索目的に応じた検索対象が、ダミー分類識別子「ｋｄ１」に対応するレコードまたは分類識別子「ｋｍ１」に対応するレコードのいずれかであることしか分からない。すなわちＤＰ側では、ＤＵが２０１９年１月に薬を５０ｍｇ投薬した患者数を知りたいのか、あるいは２０１９年１月に薬を１０ｍｇ投薬した患者数を知りたいのかが分からない。
秘匿化ＤＢ１３１〜１３４は、ｎ個の以上の種類のデータが含まれているため、少なくとも１／ｎかく乱が達成できている。
なおＤＵは、複数のキーワードの論理積または論理和を検索条件として入力することができる。このとき検索条件に含まれる複数のキーワードに応じた検索対象の秘匿化ＤＢが異なる場合がある。秘匿化ＤＢ１３１〜１３４のレコードでは氏名の値として秘匿化ＤＢ１３１〜１３４ごとに異なる仮名が用いられているため、氏名の欄の値を参照しても、同一の人物に関するレコードが秘匿化ＤＢ１３１〜１３４それぞれのどのレコードなのかを判別できない。そこで検索部１４０は、２以上の秘匿化ＤＢが検索対象となった場合、ＤＰサーバ２００に名寄せ要求を行う。
図１７は、名寄せを伴う秘匿検索の一例を示す図である。ＤＵ端末３００の検索要求部３３０が、３つの秘匿化ＤＢ１３１〜１３３を検索対象とするクエリ７１を生成したものとする。検索要求部３３０は、クエリ７１をプレ照合鍵５９で暗号化し、秘匿化ＤＢ１３１〜１３３を検索対象として、秘匿化クエリ７２を含む検索要求をＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００の検索部１４０は、秘匿化ＤＢ１３１〜１３３それぞれを検索対象として、秘匿化クエリ７２による秘匿検索を行う。そして検索部１４０は、秘匿化ＤＢ１３１〜１３３それぞれにおいて検索でヒットしたレコードの氏名のフィールドの値を取得し、対象者ＩＤリスト７３を生成する。対象者ＩＤリスト７３には、例えば秘匿化ＤＢ１３１〜１３３それぞれの秘匿化ＤＢ識別子（Ｅｖａｌ１，Ｅｖａｌ２，Ｅｖａｌ３）に対応付けて、秘匿化ＤＢでヒットしたレコードに示される仮名が設定されている。
検索部１４０は、生成した対象者ＩＤリスト７３を含む名寄せ要求をＤＰサーバ２００に送信する。ＤＰサーバ２００の検索支援部２５０は、対照表２３１を参照し、名寄せを行う。すなわち検索支援部２５０は、検索対象の秘匿化ＤＢ１３１〜１３３ごとに、対象者ＩＤリスト７３において、その秘匿化ＤＢに対応付けて仮名が登録されている氏名の集合を生成する。そして検索支援部２５０は、秘匿化ＤＢ１３１〜１３３ごとの集合の積集合または和集合を生成する。積集合とするのか和集合とするのかは、ＤＵ端末３００が送信する名寄せの指示に示され、ＴＴＰサーバ１００からＤＰサーバ２００に伝えられる。
例えば積集合を求める場合、検索支援部２５０は、対照表２３１に登録されている氏名ごとに、その氏名の仮名が、対象者ＩＤリスト７３の秘匿化ＤＢ１３１〜１３３それぞれに対応付けて登録されているか否かを判断する。検索支援部２５０は、検索対象となっている秘匿化ＤＢ１３１〜１３３のすべてに対応付けて仮名が登録されている氏名を抽出し、積集合に含める。図１７例では「Ｙ岡Ｔ司」のみが積集合に含められる。
なお和集合を求める場合、検索支援部２５０は、検索対象となっている秘匿化ＤＢ１３１〜１３３うちの少なくとも１つに対応付けて仮名が登録されている氏名を抽出し、和集合に含める。
検索支援部２５０は、名寄せによって得られた集合（積集合または和集合）に含まれる氏名の件数を検索結果７４としてＤＵ端末３００に送信する。
このように、検索対象が複数の部分ＤＢに小分けにされているため、ＤＵ端末３００は、複数の部分ＤＢそれぞれでヒットしたレコードの連結状態を確認しないと知見が得られない。すなわち検索状況をＤＰサーバ２００で監視可能となる。ＤＰサーバ２００では、例えば、多量のクエリ送付によるデータ復元攻撃を検知した場合には、名寄せを抑止することで、その攻撃に対する防御が可能となる。
さらにＤＵは、秘匿化ＤＢの検証方法が知られたくない場合は、ＤＵ端末３００により、ダミークエリをＴＴＰサーバ１００に送信することで、さらにかく乱することもできる。
図１８は、検索目的のかく乱の第２の例を示す図である。例えばＤＵ端末３００の検索要求部３３０は、検索条件が入力されると、その検索条件に応じたクエリ７５と検索条件とは無関係のダミークエリ７７とを生成する。ダミークエリ７７は、例えばクエリ７５とは別の秘匿化ＤＢを検索対象とするクエリである。図１８の例では、クエリ７５の検索対象は、秘匿化ＤＢ１３１であり、ダミークエリ７７の検索対象は秘匿化ＤＢ１３４である。
次に検索要求部３３０は、クエリ７５とダミークエリ７７とを暗号化し、秘匿化クエリ７６，７８を生成する。そして検索要求部３３０は、秘匿化クエリ７６，７８それぞれを含む検索要求をＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００の検索部１４０は、秘匿化クエリ７６，７８に応じて秘匿検索を行う。その際、検索部１４０は、検索対象となっている秘匿化ＤＢ１３１，１３４それぞれのプレ照合鍵４６ｂ，４６ｃをＤＰサーバ２００から取得する。検索部１４０は、秘匿化クエリ７６，７８それぞれの検索結果７９ａ，７９ｂをＤＵ端末３００に送信する。ＤＵ端末３００の検索要求部３３０は、秘匿化クエリ７６の検索結果７９ａのみを採用し、秘匿化クエリ７８の検索結果７９ｂは破棄する。
この場合、ＤＰサーバ２００では、分析目的が、ダミー分類識別子「ｋｄ１」、分類識別子「ｋｍ１」、ダミー分類識別子「ｋｄ４」、ダミー分類識別子「ｋｄ５」のいずれかに対応するレコードの検索であることしか把握できない。従ってＤＰサーバ２００でＤＵ側の分析目的を推定しようとしても、１／４（＝１／２ｎ）の尤度までしか絞り込みができない。すなわち分析目的を推定の尤度が１／２ｎとなるようにかく乱が達成されている。
名寄せを行う際には、さらに大きくかく乱することも可能である。
図１９は、検索目的のかく乱の第３の例を示す図である。例えばＤＵ端末３００の検索要求部３３０は、複数の秘匿化ＤＢを検索対象とする検索条件が入力されると、検索対象の秘匿化ＤＢごとのクエリ８１，８５とダミークエリ８２，８６とを生成する。図１９の例では、クエリ８１とダミークエリ８２との検索対象は、秘匿化ＤＢ１３１である。クエリ８５とダミークエリ８６との検索対象は、秘匿化ＤＢ１３２である。
クエリ８１は、例えば分類識別子「ｋｍ１」に対応するレコードのうち、２０才の女性のデータを検索するクエリである。ダミークエリ８２は、例えばダミー分類識別子「ｋｄ１」に対応するレコードのうち、２０才の女性のデータを検索するクエリである。クエリ８５は、例えば分類識別子「ｋｍ２」に対応するレコードのうち、２０才の女性のデータを検索するクエリである。ダミークエリ８６は、例えばダミー分類識別子「ｋｄ２」に対応するレコードのうち、２０才の女性のデータを検索するクエリである。
この検索の目的は、例えば２０１９年１月から２０１９年２月にかけて連続で入院している２０才の女性の患者の数の調査であるものとする。また秘匿化ＤＢ１３１には、２０１９年１月の入院患者のデータが含まれており、秘匿化ＤＢ１３２には、２０１９年２月の入院患者のデータが含まれているものとする。この場合、該当者の人数を調査するには、秘匿化ＤＢ１３１，１３２の両方で条件に合致する人物の人数を調査することとなる。
検索要求部３３０は、クエリ８１，８５とダミークエリ８２，８６それぞれを暗号化して、秘匿化クエリ８３，８４，８７，８８を生成する。そして検索要求部３３０は、秘匿化クエリ８３，８４，８７，８８をＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００の検索部１４０は、プレ照合鍵を用いて、秘匿化クエリ８３，８４，８７，８８それぞれに応じた秘匿検索を行う。なお図１９では、プレ照合鍵の図示は省略されている。そして検索部１４０は、検索にヒットしたレコードの氏名として登録されている仮名を含む対象者ＩＤリスト９１ａ，９１ｂ，９２ａ，９２ｂを生成する。例えば秘匿化クエリ８３，８４による秘匿検索の結果が対象者ＩＤリスト９１ａ，９１ｂに示されており、秘匿化クエリ８７，８８による秘匿検索の結果が対象者ＩＤリスト９２ａ，９２ｂに示されている。検索部１４０は、対象者ＩＤリスト９１ａ，９１ｂ，９２ａ，９２ｂをＤＰサーバ２００に送信し、名寄せ（積集合の生成）を要求する。
ＤＰサーバ２００の検索支援部２５０は、秘匿化クエリ８３，８４に応じた対象者ＩＤリスト９１ａ，９１ｂのうちの１つと、秘匿化クエリ８７，８８に応じた対象者ＩＤリスト９２ａ，９２ｂのうちの１つとの組み合わせごとに名寄せを行う。例えば検索支援部２５０は、対象者ＩＤリストの組み合わせごとに、積集合に含まれる氏名の数を集計する。そして検索支援部２５０は、集計結果を含む検索結果９３をＤＵ端末３００に送信する。検索結果９３のうち、ＤＵ端末３００において使用するのは、秘匿化クエリ８３による分類識別子「ｋｍ１」のレコードの検索結果と、秘匿化クエリ８７による分類識別子「ｋｍ２」のレコードの検索結果との積集合の数「２」だけである。
図１９の例では、ＤＰサーバ２００において検索目的を推定しても、検索結果９３に示される検索対象となったデータの組み合わせのうち、本当の検索目的がどの組み合わせなのかは不明となる。名寄せが行われる組み合わせはｎ2個となるため、尤度が１／ｎ2になるようなかく乱が達成されている。
以下、図２０と図２１とを参照し、ダミークエリを用いた検索目的のかく乱例について具体的に説明する。
図２０は、ダミークエリを用いた検索目的かく乱の一例を示す第１の図である。図２０には、２０１９年の１月と２月とに薬５０ｍｇを投与した患者の患者数を調査する場合の例が示されている。この場合、ＤＵ端末３００の検索要求部３３０は、検索のキーワード「心臓病」を含むクエリ４０１を生成する。また検索要求部３３０は、例えば検索のキーワード「肺炎」を含むダミークエリ４０２を生成する。
検索要求部３３０は、生成したクエリ４０１を暗号化し、秘匿化クエリ４０３を生成する。また検索要求部３３０は、ダミークエリ４０２を暗号化し、秘匿化ダミークエリ４０４を生成する。
検索要求部３３０は、データ分割基準情報３３（図７参照）に基づいて、２０１９年１月に薬５０ｍｇを投与したことを示すレコードは、部分ＤＢ識別子「ＤＢ１」の部分ＤＢ４１に格納されていることを認識する。また検索要求部３３０は、データ分割基準情報３３に基づいて、２０１９年２月に薬５０ｍｇを投与したことを示すレコードは、部分ＤＢ識別子「ＤＢ２」の部分ＤＢ４２に格納されていることを認識する。
そこで検索要求部３３０は、部分ＤＢ４１に対応する秘匿化ＤＢ１３１と部分ＤＢ４２に対応する秘匿化ＤＢ１３２とを検索対象として、秘匿化クエリ４０３を含む検索要求をＴＴＰサーバ１００に送信する。検索要求では、例えば、秘匿化ＤＢ１３１，１３２それぞれの秘匿化ＤＢ識別子「Ｅｖａｌ１」、「Ｅｖａｌ２」によって、検索対象が指定される。
検索要求を受信したＴＴＰサーバ１００では、検索部１４０が、秘匿化ＤＢ１３１，１３２それぞれに対応する検証ＤＢ１４３，１４４を生成する。検証ＤＢ１４３，１４４では、各レコードの分類識別子と氏名以外のフィールドの値それぞれと、検索要求に示される秘匿化クエリ４０３との組が設定されている。
図２１は、ダミークエリを用いた検索目的かく乱の一例を示す第２の図である。検索要求部３３０は、部分ＤＢ４１に対応する秘匿化ＤＢ１３１と部分ＤＢ４２に対応する秘匿化ＤＢ１３２とを検索対象として、秘匿化ダミークエリ４０４を含む検索要求をＴＴＰサーバ１００に送信する。検索要求では、例えば、秘匿化ＤＢ１３１，１３２それぞれの秘匿化ＤＢ識別子「Ｅｖａｌ１」、「Ｅｖａｌ２」によって、検索対象が指定される。
検索要求を受信したＴＴＰサーバ１００では、検索部１４０が、秘匿化ＤＢ１３１，１３２それぞれに対応する検証ＤＢ１４５，１４６を生成する。検証ＤＢ１４５，１４６では、各レコードの分類識別子と氏名以外のフィールドの値それぞれと、検索要求に示される秘匿化ダミークエリ４０４との組が設定されている。
検索部１４０は、生成した検証ＤＢ１４３〜１４６に設定された暗号化された値の組について、プレ照合鍵を用いて元の平文の同一性を検証する。
図２２は、検証ＤＢの検証結果の一例を示す図である。検証ＤＢ１４３の検証結果が検証結果表４１１に示されている。図２０に示したような検証ＤＢ１４３では、２つ目のレコードの病名のフィールドのみが平文一致と判定される。そこで検証結果表４１１では、２つ目のレコードの病名のフィールドに一致を示す値「１」が設定され、他のフィールドにはすべて「０」が設定されている。
検証ＤＢ１４４の検証結果が検証結果表４１２に示されている。図２０に示したような検証ＤＢ１４４では、３つ目のレコードの病名のフィールドのみが、平文一致と判定される。そこで検証結果表４１２では、３つ目のレコードの病名のフィールドに一致を示す値「１」が設定され、他のフィールドにはすべて「０」が設定されている。
検証ＤＢ１４５の検証結果が検証結果表４１３に示されている。図２１に示したような検証ＤＢ１４５では、すべてのフィールドについて平文不一致と判定される。そこで検証結果表４１３では、すべてのレコードのすべてのフィールドに「０」が設定されている。
検証ＤＢ１４６の検証結果が検証結果表４１４に示されている。図２１に示したような検証ＤＢ１４６では、２つ目のレコードの病名のフィールドのみが、平文一致と判定される。そこで検証結果表４１４では、２つ目のレコードの病名のフィールドに一致を示す値「１」が設定され、他のフィールドにはすべて「０」が設定されている。
検索部１４０は、検証結果表４１１〜４１４それぞれから、少なくとも１つのフィールドに「１」が設定されたレコードの分類識別子と氏名との値の組を抽出する。そして検索部１４０は、検証結果表４１１〜４１４それぞれに対応する対象者ＩＤリスト４２１〜４２４を生成する。対象者ＩＤリスト４２１〜４２４には、部分ＤＢ識別子と分類識別子との組に対応付けて、その分類識別子を有するレコードから抽出された氏名の値（仮名）が設定されている。
検索部１４０は、対象者ＩＤリスト４２１〜４２４に基づいて、クロス集計表を生成する。
図２３は、クロス集計表の生成例を示す図である。検索部１４０は、検証結果表４１１〜４１４ごとに生成された対象者ＩＤリスト４２１〜４２４をマージする。例えば検索部１４０は、異なる対象者ＩＤリストにおける同じ分類識別子の仮名のリストを、１つのリストに纏める。図２３の例ではマージ処理により、部分ＤＢ４１に設定されたレコードから抽出された仮名一覧を示す対象者ＩＤリスト４３１と、部分ＤＢ４２に設定されたレコードから抽出された仮名一覧を示す対象者ＩＤリスト４３２とが生成されている。
検索部１４０は、マージ後の対象者ＩＤリスト４３１，４３２をＤＰサーバ２００に送信する。ＤＰサーバ２００では、検索支援部２５０が、対照表２３１に基づいてクロス集計表４３３を生成する。
例えば検索支援部２５０は、対象者ＩＤリスト４３１に示される部分ＤＢ識別子と分類識別子との組を行のラベルに設定し、対象者ＩＤリスト４３２に示される部分ＤＢ識別子と分類識別子との組を列のラベルに設定したクロス集計表４３３を生成する。クロス集計表４３３の各セルの値の初期値は「０」である。
次に検索支援部２５０は、対象者ＩＤリスト４３１に示される分類識別子と、対象者ＩＤリスト４３２に示される分類識別子との組を生成する。さらに検索支援部２５０は、対象者ＩＤリスト４３１，４３２に登録されている仮名に対応する氏名を、対照表２３１から取得する。そして分類識別子の組ごとに、対象者ＩＤリスト４３１，４３２内に両方の分類識別子に対応付けて仮名が設定されている氏名の数を求め、集計結果をクロス集計表４３３の対応する位置に設定する。
図２３の例では、対象者ＩＤリスト４３１の分類識別子「ｋｍ１」に設定されている仮名「ＥＦＧ」に対応する氏名は「Ｙ岡Ｔ司」である。また対象者ＩＤリスト４３２の分類識別子「ｋｍ２」に設定されている仮名「ＥＥＥ」に対応する氏名も「Ｙ岡Ｔ司」である。従って氏名「Ｙ岡Ｔ司」に対応する仮名が、分類識別子「ｋｍ１」と分類識別子「ｋｍ２」との両方に登録されていることとなる。そこで検索支援部２５０は、クロス集計表４３３の分類識別子「ｋｍ１」の行と分類識別子「ｋｍ２」の列とが交わる位置のセルに「１」を設定する。
検索支援部２５０は、生成したクロス集計表４３３をＴＴＰサーバ１００に送信する。ＴＴＰサーバ１００の検索部１４０は、そのクロス集計表４３３をＤＵ端末３００に検索結果として送信する。
このようなクロス集計表４３３の生成処理がＤＰサーバ２００で行われることで、ＤＢ２１０の秘匿性を高めることができる。なお検索処理の一部がＤＰサーバ２００で行われているものの、ＤＰサーバ２００において知り得る情報は少なく、ＤＰ側ではＤＵ側の検索目的を知ることはできない。
図２４は、クロス集計表の生成を担うことでＤＰサーバが知り得る情報の一例を示す図である。対象者ＩＤリスト４３１，４３２と対照表２３１は、クロス集計表４３３の生成に使用するため、ＤＰ側でその内容を参照することも可能である。また、秘匿化ＤＢ１３１，１３２はＤＰサーバ２００で生成されており、生成後もＤＰサーバ２００がストレージ装置などに保存しておくことで、ＤＰ側でその内容を参照することが可能である。
ＤＰサーバ２００において、これらの情報を組み合わせて知り得る情報は、対象者ＩＤリスト４３１，４３２に示される仮名に対応するレコードが検索でヒットしたことである。図２４の例は、秘匿化ＤＢ１３１の２つ目のレコード、および秘匿化ＤＢ１３２の２つ目と３つ目のレコードがヒットしたことが分かる。またＤＰサーバ２００では、対照表２３１を参照し、秘匿化ＤＢ１３１，１３２内の該当レコードの氏名に設定されている仮名を、元の氏名に戻すことができる。
しかしＤＰにおいて知り得る情報には、投薬量「１０ｍｇ」、病名「肺炎」の患者のレコードが含まれている。そのためＤＰが知り得る情報だけでは、２０１９年１月と２月に薬５０ｍｇを投与した心臓病の患者数を検索していることまでは理解できない。従って、ＤＵの分析目的が適切にかく乱されている。
次に、秘匿検索処理の手順について、シーケンス図を参照して説明する。
図２５は、秘匿検索処理の手順を示すシーケンス図である。ＤＵ端末３００は、ＤＵからの入力に基づいて真の分類マップを生成する（ステップＳ１１）。ＤＵ端末３００は、生成した分類マップをＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００は、ＤＵ端末３００から取得した分類マップにダミー分類識別子を追加することで、拡張分類マップを生成する（ステップＳ１２）。このとき、ＴＴＰサーバ１００は、拡張分類マップに示される分類識別子それぞれに対応するレコードの格納先を示すデータ分割基準情報を生成する。ＴＴＰサーバ１００は、拡張分類マップとデータ分割基準情報とをＤＰサーバ２００に送信する。
ＤＰサーバ２００は、拡張分類マップとデータ分割基準情報とに基づいて１以上の部分ＤＢ（ＤＢｍ）を生成する（ステップＳ１３）。部分ＤＢ（ＤＢｍ）は、元のＤＢの部分集合である（ＤＢｍ∈ＤＢ）。生成された部分ＤＢ（ＤＢｍ）の氏名は、部分ＤＢ（ＤＢｍ）ごとに異なる仮名（Ｐｍ）に置き換えられている。そのため、複数の部分ＤＢ（ＤＢｍ）から特定の人物のレコードを抽出することはできない。
ＤＰサーバ２００は、氏名と仮名との対応関係を示す対照表Ｒ（ＤＢｍ）を生成する（ステップＳ１４）。次にＤＰサーバ２００は、ＤＢの暗号化に使用する暗号鍵Ｋｍを生成する（ステップＳ１５）。さらにＤＰサーバ２００は、生成した暗号鍵Ｋｍで部分ＤＢ（ＤＢｍ）を暗号化する（ステップＳ１６）。ＤＰサーバ２００は、暗号化によって生成された秘匿化ＤＢ（ＥｎｃKm（ＤＢｍ））をＴＴＰサーバ１００に送信する。
他方、ＤＵ端末３００は、検索条件の入力に応じて、その検索条件を示すクエリを生成する（ステップＳ１７）。次にＤＵ端末３００は、クエリ暗号鍵Ｑを生成する（ステップＳ１８）。そしてＤＵ端末３００は、クエリ暗号鍵Ｑを用いてクエリを暗号化し、秘匿化クエリ（ＥｎｃQ（Ｑｕｅｒｙ））を生成する（ステップＳ１９）。ＤＵ端末３００は、生成した秘匿化クエリ（ＥｎｃQ（Ｑｕｅｒｙ））をＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００は、秘匿化ＤＢ（ＥｎｃKm（ＤＢｍ））内の暗号データと秘匿化クエリ（ＥｎｃQ（Ｑｕｅｒｙ））との組を登録した検証ＤＢを生成する（ステップＳ２０）。そしてＴＴＰサーバ１００は、ＤＰサーバ２００とＤＵ端末３００とにプレ照合鍵を要求する（ステップＳ２１）。
ＤＵ端末３００は、クエリ暗号鍵Ｑに基づいてプレ照合鍵ｐｋｑを生成する（ステップＳ２２）。そしてＤＵ端末３００は、生成したプレ照合鍵ｐｋｑをＴＴＰサーバ１００に送信する。同様にＤＰサーバ２００は、ＤＢの暗号鍵Ｋｍに基づいてプレ照合鍵ｐｋｍを生成する（ステップＳ２３）。そしてＤＰサーバ２００は、生成したプレ照合鍵ｐｋｍをＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００は、２つのプレ照合鍵を用いて、検証ＤＢ内の暗号データそれぞれと秘匿化クエリとを照合し、暗号データの元の平文が秘匿化クエリの生成元となったクエリの検索条件に合致するか否かを判断する（ステップＳ２４）。ＴＴＰサーバ１００は、合致したレコードの件数を、検索結果としてＤＵ端末３００に送信する。ＤＵ端末３００は、検索結果を表示する（ステップＳ２５）。
図２５に示したのは、ＤＰサーバ２００における名寄せが不要な場合の例である。名寄せを行う場合、図２５のステップＳ１７以降の処理が異なる。
図２６は、名寄せを伴う秘匿検索処理の手順を示すシーケンス図である。なお秘匿化ＤＢを生成しＴＴＰサーバ１００に送信するまでの処理は、図２５のステップＳ１１〜Ｓ１６と同様である。
ＤＵ端末３００は、検索条件の入力に応じて、その検索条件を示すクエリを生成する（ステップＳ３１）。例えば２以上の秘匿化ＤＢに格納されているレコードを対象とする検索条件が入力された場合、ＤＵ端末３００は、検索対象の秘匿化ＤＢごとのクエリを生成する。次にＤＵ端末３００は、クエリ暗号鍵Ｑを生成する（ステップＳ３２）。そしてＤＵ端末３００は、検索対象の秘匿化ＤＢごとのクエリそれぞれを、クエリ暗号鍵Ｑを用いて暗号化し、秘匿化クエリ（ＥｎｃQ（Ｑｕｅｒｙ））を生成する（ステップＳ３３）。ＤＵ端末３００は、検索対象の秘匿化ＤＢごとに生成した秘匿化クエリ（ＥｎｃQ（Ｑｕｅｒｙ））を含む検索要求を、ＴＴＰサーバ１００に送信する。この際、ＤＵ端末３００は、検索要求に、名寄せ依頼と検索対象の秘匿化ＤＢの秘匿化ＤＢ識別子とを含める。
ＴＴＰサーバ１００は、秘匿化ＤＢ（ＥｎｃKm（ＤＢｍ））内の暗号データと秘匿化クエリ（ＥｎｃQ（Ｑｕｅｒｙ））との組を登録した検証ＤＢを、検索対象の秘匿化ＤＢごとに生成する（ステップＳ３４）。そしてＴＴＰサーバ１００は、ＤＰサーバ２００とＤＵ端末３００とにプレ照合鍵を要求する（ステップＳ３５）。
ＤＵ端末３００は、クエリ暗号鍵Ｑに基づいてプレ照合鍵ｐｋｑを生成する（ステップＳ３６）。そしてＤＵ端末３００は、生成したプレ照合鍵ｐｋｑをＴＴＰサーバ１００に送信する。同様にＤＰサーバ２００は、ＤＢ暗号鍵Ｋｍに基づいてプレ照合鍵ｐｋｍを生成する（ステップＳ３７）。そしてＤＰサーバ２００は、生成したプレ照合鍵ｐｋｍをＴＴＰサーバ１００に送信する。
ＴＴＰサーバ１００は、２つのプレ照合鍵を用いて、検証ＤＢ内の暗号データそれぞれと秘匿化クエリとを照合し、暗号データの元の平文が秘匿化クエリの生成元となったクエリの検索条件に合致するか否かを判断する（ステップＳ３８）。ＴＴＰサーバ１００は、検索対象の秘匿化ＤＢごとの対象者ＩＤリストを生成する（ステップＳ３９）。そしてＴＴＰサーバ１００は、生成した対象者ＩＤリストを含む名寄せ要求を、ＤＰサーバ２００に送信する。名寄せ要求には、名寄せの内容（例えば仮名の積集合の生成）が示されている。
ＤＰサーバ２００は、名寄せ要求に応じて名寄せを行い、クロス集計表を生成する（ステップＳ４０）。そしてＤＰサーバ２００は、生成したクロス集計表をＴＴＰサーバ１００に送信する。ＴＴＰサーバ１００は、クロス集計表を、検索結果としてＤＵ端末３００に送信する（ステップＳ４１）。ＤＵ端末３００は、検索結果を表示する（ステップＳ４２）。
このようにして、名寄せを伴う秘匿検索が行われる。名寄せを行うこととなっても、仮名に対応する氏名の情報は、ＤＰサーバ２００内で秘匿しておくことができ、開示された情報に基づいて個人が特定されることが抑止されている。
次に、拡張分類マップ生成処理の手順について詳細に説明する。
図２７は、拡張分類マップ生成処理の手順の一例を示すフローチャートである。以下、図２７に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］分析目的かく乱部１１０は、真の分類マップＭの大きさＭ（ｘ，ｙ）を取得する。分類マップの大きさは、分類識別子が設定されたセルのｘ軸方向の幅ｘ（列数）とｙ軸方向の幅ｙ（行数）である。例えば分析目的かく乱部１１０は、分類マップＭ内の分類識別子が設定されたセル間の距離が最も遠い分類識別子対を求め、その分類識別子対が設定された二点を対角とする四角形を作る。分析目的かく乱部１１０は、生成した四角形の大きさをＭ（ｘ，ｙ）とする。なお分類マップＭは，Ｍ（ｘ，ｙ）より大きく作られており，Ｍ（ｘ，ｙ）は常に分類マップＭの中に存在する。
図２８は、真の分類マップの大きさの判断例を示す図である。分類マップ５０１には、３行目の１列目から３列目までのセルに、分類識別子が設定されている。また１行目と２行目それぞれの３列目のセルにも分類識別子が設定されている。この例では、３行目の１列目のセルの分類識別子「ｋｍ１」と、１行目の３列目のセルの分類識別子「ｋｍ５」との対が、最も遠い分類識別子対となる。この分類識別子対を対角として含む四角形は、１〜３行目と１〜３列目との交わる範囲である。この範囲の大きさは、３行３列である。従って、真の分類マップ５０１ｎ大きさは、ｋｍ（３，３）となる。
以下、図２７の説明に戻る。
［ステップＳ１０２］分析目的かく乱部１１０は、（ｘ＋ｉ＞ｄ，ｙ＋ｊ＞ｄ）となる（ｉ，ｊ）を求める（ｉ，ｊは１以上の整数）。ｄは、予め設定された拡張分類マップの縦または横の最小サイズである。分析目的かく乱部１１０は、例えばｉ，ｊの最大値を予め設定しておき、（ｘ＋ｉ＞ｄ，ｙ＋ｊ＞ｄ）を満たす最大値以下のランダムな値を、ｉ，ｊに決定する。なおｉ，ｊそれぞれが１以上であることにより、拡張分類マップに、ダミー分類識別子を常に追加することができる。
［ステップＳ１０３］分析目的かく乱部１１０は、ｋｄ（ｘ＋ｉ，ｙ＋ｊ）の領域内の分類識別子が未設定のセルにダミー分類識別子を設定する。
［ステップＳ１０４］分析目的かく乱部１１０は、データ分割基準情報を取得する。
［ステップＳ１０５］分析目的かく乱部１１０は、データ分割基準情報にｋｄ（ｘ＋ｉ，ｙ＋ｊ）を当てはめる。これによりｋｄ（ｘ＋ｉ，ｙ＋ｊ）に設定されている分類識別子に対応するレコードの格納先となる部分ＤＢが特定される。
［ステップＳ１０６］分析目的かく乱部１１０は、各部分ＤＢにｎ個以上の分類識別子が分類されているか否かを判断する。例えば分析目的かく乱部１１０は、ｎ個未満の分類識別子しか分類されていない部分ＤＢが少なくとも１つある場合、処理をステップＳ１０２に進める。また分析目的かく乱部１１０は、すべての部分ＤＢに対して、ｎ個以上の分類識別子が分類されている場合、分類マップ生成処理を終了する。
このようにして、真の分類マップにダミー分類識別子を追加した拡張分類マップが生成される。この際、生成した拡張分類マップをデータ分割基準情報に当てはめることで、すべての部分ＤＢについて、その部分ＤＢに分類されるレコードの分類識別子数がｎ個以上となるかを調査することができる。ｎ個以上の分類識別子が分類されていない部分ＤＢがある場合、拡張分類マップを生成しなおすことで、１つの部分ＤＢ当りでｎ種類以上のレコードを格納することによるかく乱条件を満たすことができる。
図２９は、拡張分類マップの生成例を示す図である。例えば真の分類マップ５１１には、１行３列の表に３つの分類識別子「ｋｍ１」〜「ｋｍ３」が設定されている。真の分類マップ５１１の大きさはｋｍ（３，１）である。
ここで、ｉ＝１、ｊ＝１であるものとする。その場合、ｋｄ（４，２）となる。具体的には、真の分類マップ５１１では、投薬量の行のラベルが「５０ｍｇ」だけであったのが、拡張分類マップ５１２では、投薬量の行のラベルが「１０ｍｇ」と「５０ｍｇ」とになっている。また真の分類マップ５１１では、日付の列のラベルが「２０１９年１月」、「２０１９年２月」、「２０１９年３月」であったのが、拡張分類マップ５１２では、投薬量の列のラベルに「２０１９年４月」が追加されている。
拡張分類マップ５１２にデータ分割基準情報５１３を適用すると、拡張分類マップ５１２に設定されている分類識別子のレコードは、データ分割基準情報５１３において同じ位置のセルに設定された部分ＤＢ識別子を有する部分ＤＢに分類される。例えば分類識別子「ｋｄ１」と「ｋｍ１」に対応するレコードは、部分ＤＢ識別子「ＤＢ１」の部分ＤＢに分類される。
以上が真の分類マップに基づく拡張分類マップの生成処理である。次に、ＤＰサーバ２００における名寄せ処理について詳細に説明する。
図３０は、図５の検索支援部２５０にて実施される名寄せ処理の手順の一例を示すフローチャートである。以下、図３０に示す処理をステップ番号に沿って説明する。
［ステップＳ１１１］検索支援部２５０は、名寄せ対象の対象者ＩＤリストを取得する。例えば検索支援部２５０は、ＴＴＰサーバ１００から、検索対象の部分ＤＢごとにマージされた複数の対象者ＩＤリストを取得する。
［ステップＳ１１２］検索支援部２５０は、対象者ＩＤリストから未取得の仮名を１つ取得する。
［ステップＳ１１３］検索支援部２５０は、取得した仮名に対応する氏名を対照表２３１から取得する。
［ステップＳ１１４］検索支援部２５０は、仮ＤＢに、取得した仮名と氏名との対応関係を格納する。
［ステップＳ１１５］検索支援部２５０は、対象者ＩＤリストに、未取得の仮名が存在するか否かを判断する。検索支援部２５０は、未取得の仮名が存在すれば、処理をステップＳ１１１に進める。また検索支援部２５０は、未取得の仮名が存在しなければ、処理をステップＳ１１６に進める。
［ステップＳ１１６］検索支援部２５０は、仮ＤＢを参照し、各氏名の出現回数を計数する。
［ステップＳ１１７］検索支援部２５０は、出現回数が所定のしきい値以下の氏名があるか否かを判断する。検索支援部２５０は、該当する氏名がある場合、処理をステップＳ１１８に進める。また検索支援部２５０は、該当する氏名がない場合、処理をステップＳ１１９に進める。
［ステップＳ１１８］検索支援部２５０は、出現回数がしきい値以下の氏名を仮ＤＢから削除する。
［ステップＳ１１９］検索支援部２５０は、仮ＤＢに基づいてクロス集計表を生成する。
このようにして名寄せを行い、名寄せの結果を示すクロス集計表を生成することができる。名寄せでは、出現回数が予め定めたしきい値以下である氏名が存在する場合、該当する氏名が仮ＤＢから削除される。これにより、特定の個人の情報を推定できるような検索が行われた場合に、検索結果から該当する個人に関するレコードの存在を隠ぺいすることができる。
例えば、検索結果に該当数が１名しか存在しない場合、この病院にその病状の人間は１名しかいないことが判明してしまう。この場合、個人が特定されるおそれがあり、その個人の情報を盗取される可能性もある。そこで名寄せの段階でＤＰサーバ２００において、しきい値以下の出現回数の氏名に対応するデータに関しては削除する。なおＤＰサーバ２００は、出現回数が少ない氏名に対応するデータの削除に替えて、ノイズを加える（出現回数の値にランダムな数値を加算）などの処理を行うこともできる。このようにして、プライバシー侵害が起きない患者群に関するクロス集計表を生成することができる。
図３１は、名寄せ処理の一例を示す図である。図３１に示す対象者ＩＤリスト４３１，４３２を取得した検索支援部２５０は、対照表２３１に基づいて、仮ＤＢ６０１を生成する。仮ＤＢ６０１には、部分ＤＢ識別子と分類識別子との組に対応付けて、対象者ＩＤリスト４３１，４３２において該当する分類識別子に設定された仮名と、その仮名に対応する氏名とが登録されている。
検索支援部２５０は、仮ＤＢ６０１に登録されている氏名について出現回数を計数し、出現回数を出現回数表６０２に設定する。検索支援部２５０は、出現回数がしきい値以下の氏名の情報を仮ＤＢ６０１から削除する。例えばしきい値が「１」であれば、出現回数が「１」の氏名「Ｓ中 智」に関する情報が、仮ＤＢ６０１から削除される。
その後、検索支援部２５０は、仮ＤＢに基づいてクロス集計表６０３を生成する。例えば検索支援部２５０は、仮ＤＢ６０１において、異なる部分ＤＢ識別子に対応付けて同じ氏名の２つのレコードが登録されている場合、それらのレコードを抽出する。検索支援部２５０は、抽出したレコードそれぞれにおける部分ＤＢ識別子と分類識別子との組に対応するクロス集計表６０３内のセルの値に１を加算する。
図３１の例では、氏名「Ｙ岡 Ｔ司」が「ＤＢ１−ｋｍ１」の検索結果と「ＤＢ２−ｋｍ２」の検索結果とに出現している。そこで検索支援部２５０は、クロス集計表６０３における「ＤＢ１−ｋｍ１」の行と「ＤＢ２−ｋｍ２」の列が交差する位置のセルに１を加算する。
なお図３１の例では、処理手順を分かりやすくするため、対象者ＩＤリストに４３１，４３２に設定されている仮名の数が少ない。そのためクロス集計表６０３においても、最大の値が「１」となっている。しかし一般には、対象者ＩＤリストに４３１，４３２にはもっと多くの仮名が設定される。その場合、クロス集計表６０３に設定される値も、もっと大きな値となる。そのような状況下で、クロス集計表６０３の一部のセルの値が「１」のように極めて小さい値の場合、特定の患者に関する情報が特定できてしまう可能性がある。そこで検索支援部２５０は、クロス集計表６０３において所定値以下の値は「０」に修正してもよい。また検索支援部２５０は、クロス集計表６０３において所定値以下の値は、その所定値よりも大きな値に修正してもよい。
〔その他の実施の形態〕
第２の実施の形態では、ＴＴＰサーバ１００は、照合鍵を用いた秘匿検索を行っているが、ＴＴＰの信頼性が高く、ＴＴＰサーバ１００による復号を許容できる場合、照合鍵に替えて復号鍵を用いることも可能である。その場合、ＴＴＰサーバ１００は、ＤＵ端末３００とＤＰサーバ２００から取得した復号鍵で、クエリとレコードのフィールド内の値とをそれぞれ復号し、照合する。
また第２の実施の形態では、拡張分類マップ３２をＴＴＰサーバ１００が生成しているが、ＤＵ端末３００において拡張分類マップ３２を生成することも可能である。
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
１ 端末装置
１ａ 利用レコード情報
１ｂ 第１の分類マップ
１ｃ クエリ
１ｄ 第２の鍵
１ｅ 検索結果
２ 情報処理装置
２−１ 記憶部
２−２ 処理部
２ａ 第２の分類マップ
２ｂ〜２ｄ 秘匿化ＤＢ
３ サーバ
３ａ 第１のＤＢ
３ｂ〜３ｄ 第２のＤＢ
３ｅ 第１の鍵

Claims (11)

  1. 情報処理装置が、
    データ利用者が利用する第１のレコード群に含まれるレコードの条件として、所定の属性のフィールドに第１の値が設定されていることが指定された利用レコード情報を取得し、
    複数のレコードが格納された第１のデータベースを管理するサーバに対して、前記複数のレコードのうちの、前記所定の属性のフィールドに前記第１の値が設定されている前記第１のレコード群と、前記所定の属性のフィールドに、前記第１の値とは異なる第２の値が設定されている第２のレコード群とを格納した第２のデータベースの生成要求を送信する、
    制御方法。
  2. 複数の前記第２のデータベースの生成の指示、前記第１のレコード群と前記第２のレコード群それぞれの複数のグループへの分類の指示、およびグループごとの格納先となる前記第２のデータベースの指定を含む前記生成要求を送信する、
    請求項１記載の制御方法。
  3. 前記利用レコード情報は、第１の属性の値を列のラベルとし、第２の属性の値を行のラベルとする表形式の第１の分類マップであり、前記第１の分類マップには、前記第１のレコード群における前記第１の属性の前記第１の値に対応する行と前記第１のレコード群における前記第２の属性の前記第１の値に対応する列とが交わる位置に、前記第１のレコード群内のグループを示す第１の分類識別子が設定されており、
    前記第１の分類マップにおける前記第１の分類識別子が設定されていない位置に前記第２のレコード群内のグループを示す第２の分類識別子を追加した第２の分類マップを生成し、前記第２の分類マップを含む前記生成要求を送信する、
    請求項２記載の制御方法。
  4. 前記第１の分類マップにおいて前記第１の分類識別子が設定された領域を包含する四角形を生成し、前記四角形を拡大し、拡大された前記四角形内において前記第１の分類識別子が設定されていない位置に前記第２の分類識別子を追加した前記第２の分類マップを生成する、
    請求項３記載の制御方法。
  5. 前記サーバが、
    前記生成要求に応じて、前記第１のデータベースから前記第１のレコード群と前記第２のレコード群とを抽出し、前記第１のレコード群と前記第２のレコード群とを含む前記第２のデータベースを生成し、
    前記第２のデータベースを暗号化して秘匿化データベースを生成し、
    前記秘匿化データベースの照合用の第１の鍵を生成し、
    前記データ利用者が使用する端末装置が、
    前記秘匿化データベースを検索対象とする検索条件を示すクエリを暗号化し、
    前記クエリを用いた照合用の第２の鍵を生成し、
    前記情報処理装置が、
    前記サーバから前記秘匿化データベースと前記第１の鍵とを取得し、
    前記端末装置からの暗号化された前記クエリと前記第２の鍵とを取得し、
    前記第１の鍵と前記第２の鍵とを用いて、前記クエリに示される前記検索条件を満たすレコードを、前記秘匿化データベースから検索する、
    請求項１ないし４のいずれかに記載の制御方法。
  6. 前記情報処理装置が、
    複数の前記第２のデータベースの生成、前記第１のレコード群と前記第２のレコード群それぞれの複数のグループへの分類、およびグループごとの格納先となる前記第２のデータベースの指定を含む前記生成要求を送信し、
    前記サーバが、
    前記生成要求に応じて、前記第２のデータベースを複数生成し、前記第１のレコード群と前記第２のレコード群それぞれを前記複数のグループに分類し、前記第１のレコード群と前記第２のレコード群とをグループごとに複数の前記第２のデータベースのいずれかに格納し、
    複数生成された前記第２のデータベースそれぞれを暗号化して、複数の前記秘匿化データベースを生成し、
    複数の前記秘匿化データベースごとに異なる前記第１の鍵を生成する、
    請求項５に記載の制御方法。
  7. 前記サーバが、
    前記第１のデータベース内の互いに関連する複数の関連レコードに共通に設定された第１の識別子を、前記複数の関連レコードそれぞれの格納先の前記第２のデータベースごとに異なる第２の識別子に変換し、前記第２の識別子を有する前記複数の関連レコードを複数生成された前記第２のデータベースに格納し、前記第１の識別子と前記第２の識別子との対応関係を示す対照表を生成し、
    前記端末装置が、
    ２以上の前記第２のデータベースを検索対象とする前記クエリを暗号化し、
    前記情報処理装置が、
    暗号化された前記クエリに示される前記検索条件を満たすレコードの、検索対象の前記秘匿化データベースからの検索を行い、検索対象の前記秘匿化データベース内の前記検索条件を満たすレコードに含まれる前記第２の識別子のリストである識別子リストを、検索対象の前記秘匿化データベースごとに生成し、
    前記サーバが、
    前記対照表に基づいて、前記識別子リストに示される前記第２の識別子を、対応する前記第１の識別子に変換することで、検索対象の前記秘匿化データベースごとの前記第１の識別子のリストを生成し、
    検索対象の前記秘匿化データベースごとの前記第１の識別子のリスト間の和集合または積集合を求める、
    請求項６に記載の制御方法。
  8. 前記端末装置は、
    第１の秘匿化データベースを検索対象とする前記クエリを暗号化すると共に、前記第１の秘匿化データベースとは別の第２の秘匿化データベースを検索対象とする、ダミーの検索条件を示すダミークエリを暗号化し、
    前記情報処理装置は、
    前記サーバから前記第１の秘匿化データベースと前記第１の秘匿化データベースの前記第１の鍵、および前記第２の秘匿化データベースと前記第２の秘匿化データベースの前記第１の鍵とを取得し、
    前記端末装置から、暗号化された前記のクエリと暗号化された前記ダミークエリと前記第２の鍵とを取得し、
    前記第１の秘匿化データベースと前記第１の秘匿化データベースの前記第１の鍵とを用いて、前記クエリに示される前記検索条件を満たすレコードを、前記第１の秘匿化データベースから検索すると共に、前記第２の秘匿化データベースと前記第２の秘匿化データベースの前記第１の鍵とを用いて、前記ダミークエリに示される前記ダミーの検索条件を満たすレコードを、前記第２の秘匿化データベースから検索する、
    請求項６または７のいずれかに記載の制御方法。
  9. 前記端末装置は、
    前記第１の秘匿化データベースと前記第２の秘匿化データベースとを検索対象とする複数の前記クエリを暗号化すると共に、前記第１の秘匿化データベースと前記第２の秘匿化データベースとを検索対象とする、複数の前記ダミークエリを暗号化し、
    前記情報処理装置は、
    複数の前記クエリそれぞれに示される前記検索条件を満たすレコードを、前記第１の秘匿化データベースまたは前記第２の秘匿化データベースから検索すると共に、複数の前記ダミークエリそれぞれに示される前記ダミーの検索条件を満たすレコードを、前記第１の秘匿化データベースまたは前記第２の秘匿化データベースから検索する、
    請求項８記載の制御方法。
  10. コンピュータが、
    データ利用者が利用する第１のレコード群に含まれるレコードの条件として、所定の属性のフィールドに第１の値が設定されていることが指定された利用レコード情報を取得し、
    複数のレコードが格納された第１のデータベースを管理するサーバに対して、前記複数のレコードのうちの、前記所定の属性のフィールドに前記第１の値が設定されている前記第１のレコード群と、前記所定の属性のフィールドに、前記第１の値とは異なる第２の値が設定されている第２のレコード群とを格納した第２のデータベースの生成要求を送信する、
    制御プログラム。
  11. データ利用者が利用する第１のレコード群に含まれるレコードの条件として、所定の属性のフィールドに第１の値が設定されていることが指定された利用レコード情報を取得し、複数のレコードが格納された第１のデータベースを管理するサーバに対して、前記複数のレコードのうちの、前記所定の属性のフィールドに前記第１の値が設定されている前記第１のレコード群と、前記所定の属性のフィールドに、前記第１の値とは異なる第２の値が設定されている第２のレコード群とを格納した第２のデータベースの生成要求を送信する処理部、
    を有する情報処理装置。
JP2020003465A 2020-01-14 2020-01-14 制御方法、制御プログラム、および情報処理装置 Pending JP2021110861A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2020003465A JP2021110861A (ja) 2020-01-14 2020-01-14 制御方法、制御プログラム、および情報処理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020003465A JP2021110861A (ja) 2020-01-14 2020-01-14 制御方法、制御プログラム、および情報処理装置

Publications (1)

Publication Number Publication Date
JP2021110861A true JP2021110861A (ja) 2021-08-02

Family

ID=77059748

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020003465A Pending JP2021110861A (ja) 2020-01-14 2020-01-14 制御方法、制御プログラム、および情報処理装置

Country Status (1)

Country Link
JP (1) JP2021110861A (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03156677A (ja) * 1989-11-15 1991-07-04 Nippon Telegr & Teleph Corp <Ntt> 複合データベースシステム
JP2006185096A (ja) * 2004-12-27 2006-07-13 Fujitsu Ltd データ保護プログラムおよびデータ保護方法
JP2010061103A (ja) * 2008-05-30 2010-03-18 Nec (China) Co Ltd 高速検索可能な暗号化のための方法、装置およびシステム
JP5166439B2 (ja) * 2007-11-19 2013-03-21 インターナショナル・ビジネス・マシーンズ・コーポレーション データベースに対するアクセスを制御する技術
JP2013513834A (ja) * 2009-12-15 2013-04-22 マイクロソフト コーポレーション 信頼できるコンピューティングおよびデータサービスのための信頼できる拡張マークアップ言語
JP2016042663A (ja) * 2014-08-18 2016-03-31 富士通株式会社 プログラム、情報処理方法、コンピュータ及び情報処理システム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03156677A (ja) * 1989-11-15 1991-07-04 Nippon Telegr & Teleph Corp <Ntt> 複合データベースシステム
JP2006185096A (ja) * 2004-12-27 2006-07-13 Fujitsu Ltd データ保護プログラムおよびデータ保護方法
JP5166439B2 (ja) * 2007-11-19 2013-03-21 インターナショナル・ビジネス・マシーンズ・コーポレーション データベースに対するアクセスを制御する技術
JP2010061103A (ja) * 2008-05-30 2010-03-18 Nec (China) Co Ltd 高速検索可能な暗号化のための方法、装置およびシステム
JP2013513834A (ja) * 2009-12-15 2013-04-22 マイクロソフト コーポレーション 信頼できるコンピューティングおよびデータサービスのための信頼できる拡張マークアップ言語
JP2016042663A (ja) * 2014-08-18 2016-03-31 富士通株式会社 プログラム、情報処理方法、コンピュータ及び情報処理システム

Similar Documents

Publication Publication Date Title
US10013574B2 (en) Method and apparatus for secure storage and retrieval of encrypted files in public cloud-computing platforms
JP6419633B2 (ja) 検索システム
Grolinger et al. Data management in cloud environments: NoSQL and NewSQL data stores
US8918895B2 (en) Prevention of information leakage from a document based on dynamic database label based access control (LBAC) policies
US8201216B2 (en) Techniques for database structure and management
US7539682B2 (en) Multilevel secure database
US9881164B1 (en) Securing data
US11562812B2 (en) Computer implemented method for secure management of data generated in an EHR during an episode of care and a system therefor
Zhao et al. Research on electronic medical record access control based on blockchain
US8504590B2 (en) Methods of encapsulating information in records from two or more disparate databases
Al Sibahee et al. Efficient encrypted image retrieval in IoT-cloud with multi-user authentication
JP6250497B2 (ja) 情報管理システム
US20110219235A1 (en) Digital signature device, digital signature method, and non-transitory storage medium storing digital signature program
Trivedi et al. Enhancing relational database security by metadata segregation
Rahunathan et al. Efficient and Secure Interoperable Healthcare Information System Using Keyword Searchable and Role-Based Access Control in Cloud Environment
JP2006189925A (ja) 個人情報管理システム、個人情報管理プログラムおよび個人情報保護方法
JP2021110861A (ja) 制御方法、制御プログラム、および情報処理装置
Elmeleegy et al. Preserving privacy and fairness in peer-to-peer data integration
Huang et al. Intellectual property protection for FPGA designs using the public key cryptography
JP7132506B2 (ja) 秘密情報検索システム、秘密情報検索プログラム、および秘密情報検索方法
Bkakria et al. Preserving Multi-relational Outsourced Databases Confidentiality using Fragmentation and Encryption.
Hansen et al. HDI: integrating health data and tools
Clark et al. Computer vision for locating buried objects
JP2008140202A (ja) 情報提供制御装置、情報提供制御方法、及び、プログラム
JP2007249622A (ja) 公開／非公開項目を含む情報の提供方法、情報提供システム、プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220908

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230428

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230606

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20231205