JP6089881B2 - データ検索方法、データ追加更新方法、データ検索プログラムおよび中継装置 - Google Patents

Description

本発明は、データ検索方法などに関する。

近年、作業の効率化から、外部のプラットフォームサービスを利用して、個人情報を含む顧客データなどを保管する企業が増えてきている。このような場合、データを管理する管理者とサービスを利用する利用者とが異なることから、利用者は企業の機密情報の漏洩を防止するため、保管するデータを秘匿化してプラットフォームサービスが提供するプラットフォームに預ける場合が増えている。

そして、データを秘匿化したまま検索する検索装置の技術が開示されている。かかる技術では、検索装置は、テキストデータを、予め作成された辞書を用いて圧縮し、圧縮データを保管する。そして、検索装置は、検索を行う場合、秘匿化された検索キーと辞書とを用いて、検索キーと合致するデータを圧縮データから検索する。

また、サービスの利用者にとって重要なデータをサービス提供装置側に漏洩することなく、当該利用者がサービスを利用することを可能とする技術が知られている。かかる技術では、サービス連携装置が、サービス提供装置に対して、利用者によって入力された利用者データを当該利用者データとは異なる任意の変換データに変換し、変換データを送信する。そして、サービス連携装置は、サービス提供装置から送信された、変換データに対するサービス結果データについて、変換データを利用者データに変換し、変換された利用者データに置き換えて画面に表示する。

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

しかしながら、プラットフォームサービスにより提供されるプラットフォームにおいてデータを秘匿化して保管する場合、検索装置は、秘匿後のデータを柔軟に検索することができないという問題がある。例えば、データを秘匿化したまま検索する検索装置の技術では、検索装置が、検索キーと合致するデータを圧縮データから検索できるが、検索キーを一部に含むデータを検索できない。また、例えば、サービス連携装置は、利用者データそのものを任意に変換した変換データをサービス提供装置に送信しているに過ぎず、利用者データを一部に含むデータを検索できない。したがって、検索装置およびサービス連携装置は、秘匿後のデータを柔軟に検索することができない。

１つの側面では、プラットフォームサービスにより提供されるプラットフォームにおいてデータを秘匿化して保管する場合、秘匿後のデータを柔軟に検索することを目的とする。

本願の開示するデータ検索方法では、中継装置が、第１の情報処理装置から受信したデータに含まれる第１の情報と前記第１の情報を変換した第２の情報とを対応づけて記録する記憶部から、前記第１の情報処理装置から受信した第１の検索キーに少なくとも一部が一致する第１の情報を複数選択し、選択した複数の前記第１の情報に対応付けられた前記第２の情報それぞれを第２の検索キーとして生成し、生成した第２の検索キーを前記第２の情報処理装置に送信する。

本願の開示するデータ検索方法の１つの態様によれば、プラットフォームサービスにより提供されるプラットフォームにおいてデータを秘匿化して保管する場合、秘匿後のデータを柔軟に検索することができる。

図１は、実施例に係るデータ検索システムの構成を示す機能ブロック図である。 図２は、実施例に係る対応テーブルのデータ構造の一例を示す図である。 図３は、顧客ＤＢのデータ構造の一例を示す図である。 図４は、実施例に係るデータ検索処理の具体例を説明する図である。 図５Ａは、検索キー生成処理の具体例を説明する図（１）である。 図５Ｂは、検索キー生成処理の具体例を説明する図（２）である。 図６Ａは、データを追加する場合のリクエストの一例を示す図である。 図６Ｂは、データを更新する場合のリクエストの一例を示す図である。 図６Ｃは、データを検索する場合のリクエストの一例を示す図である。 図７は、データの追加更新処理のフローチャートを示す図である。 図８は、データの検索処理のフローチャートを示す図である。 図９は、データ検索プログラムを実行するコンピュータの一例を示す図である。

以下に、本願の開示するデータ検索方法、データ検索プログラムおよび中継装置の実施例を図面に基づいて詳細に説明する。なお、実施例によりこの発明が限定されるものではない。

［データ検索システムの構成］
図１は、実施例に係るデータ検索システムの構成を示す機能ブロック図である。データ検索システム９は、中継サーバ１と、ウェブブラウザ２と、ウェブサーバ３とを有する。データ検索システム９は、ウェブブラウザ２から中継サーバ１を介してウェブサーバ３で管理されるデータを検索する。なお、ウェブサーバ３は、プラットフォームサービスにより提供されるプラットフォームの一例である。

中継サーバ１は、ウェブブラウザ２とウェブサーバ３との間の通信を中継し、ウェブブラウザ２側に設置される。ウェブブラウザ２は、ウェブサービスを利用する、パーソナルコンピュータなどのユーザ端末で動作するソフトウェアである。ウェブサーバ３は、ユーザの機密データを秘匿したまま管理するウェブサービスを実施するサーバである。本実施例では、ウェブサーバ３は、ユーザによって預けられた顧客情報を管理するウェブサービスを実施するものとする。機密データは、例えば、個人の名前、電話番号、住所などの個人データであるが、公開に制限があるデータであれば良い。なお、データ検索システム９では、ウェブサーバ３は、中継サーバ１およびユーザ端末の外部の装置として異なるネットワーク上に適用した場合であるが、中継サーバ１およびユーザ端末と同一のネットワーク上に適用する場合であっても良い。

ここで、中継サーバ１は、ウェブブラウザ２からのデータの追加またはデータの更新に関する追加更新処理と、ウェブブラウザ２からのデータの検索に関する検索処理とを備える。

中継サーバ１は、追加更新処理では、ウェブブラウザ２からデータを追加する旨のリクエストを取得すると、追加する平文のデータが機密データを含んでいれば、以下の処理を行う。すなわち、中継サーバ１は、平文のデータに含まれる機密データと当該機密データを暗号化した暗号文とを対応付けて後述する対応テーブルに記録する。そして、中継サーバ１は、追加されるデータに含まれる機密データを暗号文に置き換え、置き換えて得られたデータを追加する旨のリクエストをウェブサーバ３に送信する。また、中継サーバ１は、追加更新処理では、ウェブブラウザ２からデータを更新する旨のリクエストを取得すると、データの更新部分が機密データであれば、以下の処理を行う。すなわち、中継サーバ１は、更新部分と当該更新部分を暗号化した暗号文とを対応付けて対応テーブルを更新する。

そして、中継サーバ１は、検索処理では、ウェブブラウザ２からデータを検索する旨のリクエストを取得すると、対応テーブルに記憶された情報に基づいて、リクエスト内の平文の検索文字列の一部または全部を含む機密データを選択する。そして、中継サーバ１は、選択した機密データに対応付けられた暗号文を抽出し、抽出した暗号文を用いて暗号化された検索キーを生成する。そして、中継サーバ１は、暗号化された検索キーを含むリクエストをウェブサーバ３に送信し、ウェブサーバ３から秘匿したままのデータを柔軟に検索する。

中継サーバ１は、データポリシーテーブル４１と、対応テーブル４２と、検索結果テーブル４３とを有する。データポリシーテーブル４１は、公開に制限がある旨のデータポリシーを有する機密データのデータ項目のフォーム属性を記憶する。フォーム属性とは、ウェブブラウザ２に表示されるフォームによって入力可能なデータ項目の属性を意味し、例えば、データ項目が名前を示すデータ項目であれば名前のフォーム属性を「ｎａｍｅ」とする。すなわち、名前が、公開に制限がある旨のデータポリシーを有するデータ項目であれば、データポリシーテーブル４１には、名前のフォーム属性（一例として「ｎａｍｅ」）が記憶される。対応テーブル４２は、平文の機密データと当該機密データを暗号化した暗号文とを対応付けて記憶する。検索結果テーブル４３は、ウェブサーバ３によって検索された検索結果を記憶する。なお、対応テーブル４２のデータ構造の一例は、後述する。

また、中継サーバ１は、リクエスト受付部１１と、リクエスト解析部１２と、機密データ判定部１３と、第１の検索キー生成部１４と、検索キー判定部１５と、第２の検索キー生成部１６と、リクエスト生成部１７と、リクエスト転送部１８とを有する。また、中継サーバ１は、レスポンス受付部１９と、レスポンス解析部２０と、検索結果復元部２１と、キャッシュ書込／読出部２２と、レスポンス生成部２３と、レスポンス転送部２４とを有する。ここで、機密データ判定部１３および第１の検索キー生成部１４は、追加更新処理を実行する追加更新処理部１Ａに含まれる。検索キー判定部１５、第２の検索キー生成部１６、検索結果復元部２１およびキャッシュ書込／読出部２２は、検索処理を実行する検索処理部１Ｂに含まれる。

リクエスト受付部１１は、ＨＴＴＰ（Hyper Text Transfer Protocol）の各種リクエストを受け付け、受け付けたリクエストをリクエスト解析部１２に引き渡す。各種リクエストには、例えば、データを追加または更新する旨のリクエスト（以降、「追加更新リクエスト」という）またはデータを検索する旨のリクエスト（以降、「検索リクエスト」という）が含まれる。追加更新リクエストには、追加または更新する平文のデータが設定される。なお、「追加」とは、データを新規に登録することを意味する。「更新」とは、データの一部を変更することや、データを削除することを意味する。

リクエスト解析部１２は、リクエスト受付部１１によって受け付けられたリクエストを解析する。

機密データ判定部１３は、リクエスト解析部１２による解析の結果、追加更新リクエストを取得すると、リクエストの平文のデータに機密データが含まれているか否かを判定する。例えば、機密データ判定部１３は、データポリシーテーブル４１に記憶された情報から、公開に制限がある旨のデータポリシーを有するフォーム属性を読み出す。そして、機密データ判定部１３は、取得したリクエストに、読み出したフォーム属性が含まれているか否かを判定する。なお、機密データ判定部１３は、リクエストの平文のデータに機密データが含まれていないと判定した場合、当該リクエストを後述するリクエスト転送部１８に引き渡す。

第１の検索キー生成部１４は、機密データ判定部１３によって追加または更新される平文のデータに機密データが含まれていると判定された場合、当該機密データが対応テーブル４２に記憶されているか否かを判定する。

ここで、対応テーブル４２のデータ構造について、図２を参照して説明する。図２は、対応テーブルのデータ構造の一例を示す図である。図２に示すように、対応テーブル４２は、項番４２ａ、フォーム属性４２ｂ、機密データ４２ｃ、検索キー４２ｄおよび更新日時４２ｅを対応付けて記憶する。項番４２ａは、レコード毎に一意に付けられた番号である。フォーム属性４２ｂは、機密データ４２ｃに対応するフォーム属性である。機密データ４２ｃは、機密データの内容であり、平文の文字列で表される。検索キー４２ｄは、機密データ４２ｃを暗号化した内容であり、暗号化文字列で表される。すなわち、検索キー４２ｄは、後述する検索処理部１Ｂがウェブサーバ３のデータを検索する際の検索キーとなる。更新日時４２ｅは、データの追加更新処理時にアクセスされたタイムスタンプを示す。一例として、項番４２ａが「１」である場合、フォーム属性４２ｂとして「ｎａｍｅ」、機密データ４２ｃとして「山田太郎」、検索キー４２ｄとして「ＸＸＸＸ」、更新日時４２ｅとして「２０１２／１／１」と記憶している。

図１に戻って、機密データが対応テーブル４２に記憶されているか否かの判定は、例えばリクエストがＨＴＴＰのリクエストである場合、リクエストのメッセージボディの、当該機密データに対応するフォーム属性とその属性値とによって判定できる。例えば、第１の検索キー生成部１４は、リクエストのメッセージボディから、機密データに対応するフォーム属性の更新前後の属性値を参照する。そして、第１の検索キー生成部１４は、更新前後の属性値のうちいずれか一方の属性値が対応テーブル４２の同じフォーム属性４２ｂに対応する機密データ４２ｃに記憶されているか否かで判定すれば良い。

第１の検索キー生成部１４は、平文のデータに含まれた機密データが対応テーブル４２に記憶されていないと判定した場合、当該機密データを含むデータが追加されるデータであると判断する。そして、第１の検索キー生成部１４は、機密データから暗号化された文字列を生成する。すなわち、平文の機密データが秘匿化される。そして、第１の検索キー生成部１４は、機密データ、暗号化文字列、フォーム属性および更新日時を示すタイムスタンプを対応テーブル４２に追加する。ここで、機密データから生成された暗号化文字列は、ウェブサーバ３上のデータを検索する検索処理において検索キーとして用いられる。つまり、検索処理は、検索キーを秘匿した状態でウェブサーバ３に送信し、データを秘匿したまま検索する。

また、第１の検索キー生成部１４は、平文のデータに含まれた機密データが対応テーブル４２に記憶されていると判定した場合、当該機密データが更新されるか否かを判定する。平文のデータに含まれた機密データが更新されるか否かは、例えばリクエストがＨＴＴＰのリクエストである場合、リクエストのメッセージボディの、当該機密データに対応するフォーム属性とその属性値とによって判定できる。例えば、第１の検索キー生成部１４は、リクエストのメッセージボディから、機密データに対応するフォーム属性の更新前後の属性値を参照する。そして、第１の検索キー生成部１４は、更新前後の属性値にそれぞれヌル以外の異なる値が設定されていれば、更新前の属性値から更新後の属性値に機密データが更新されると判断すれば良い。また、第１の検索キー生成部１４は、更新前の属性値にヌル以外の値が設定され、更新後の属性値にヌルが設定されていれば、更新前の属性値の機密データが削除更新されると判断すれば良い。また、第１の検索キー生成部１４は、更新前後の属性値にそれぞれヌル以外の同じ値が設定されていれば、機密データが更新されないと判断すれば良い。そして、第１の検索キー生成部１４は、対応テーブル４２に記憶されている機密データが更新されると判定した場合、当該機密データから暗号化された暗号文を生成する。

また、第１の検索キー生成部１４は、対応テーブル４２の機密データが更新されると判定した場合、当該機密データから暗号化された暗号文を生成する。すなわち、平文の機密データが秘匿化される。そして、第１の検索キー生成部１４は、機密データ、暗号化文字列、フォーム属性およびタイムスタンプを対応テーブル４２に更新する。なお、第１の検索キー生成部１４は、対応テーブル４２の機密データが更新されない、すなわち機密データ以外のデータが更新されると判定した場合、対応テーブル４２の、機密データに対応するタイムスタンプのみを更新する。

検索キー判定部１５は、リクエスト解析部１２による解析の結果、検索リクエストを取得すると、リクエストの検索文字列が対応テーブル４２に記憶されたいずれかの機密データ４２ｃと完全一致であるか否かを判定する。そして、検索キー判定部１５は、リクエストの検索文字列がいずれかの機密データ４２ｃと完全一致でないと判定した場合、第２の検索キー生成部１６に新たな検索キーを生成させる。

また、検索キー判定部１５は、リクエストの検索文字列がいずれかの機密データ４２ｃと完全一致であると判定した場合、検索文字列に対応する検索キーが正当であるか否かを検証すべく、以下の処理を行う。検索キー判定部１５は、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列を部分に含む機密データ４２ｃを単数または複数抽出する。そして、検索キー判定部１５は、検索文字列と完全一致した機密データ４２ｃに対応する更新日時４２ｅが、抽出した機密データ４２ｃに対応するいずれかの更新日時４２ｅより古いか否かを判定する。

ここで、検索キー判定部１５は、検索文字列に対応する更新日時４２ｅが、抽出した機密データ４２ｃに対応するいずれかの更新日時４２ｅより古いと判定した場合、検索文字列に対応する検索キーを新たに第２の検索キー生成部１６に生成させる。つまり、リクエストの検索文字列が既に対応テーブル４２に記憶されていても、記憶された日時より後に検索文字列を部分に含む機密データ４２ｃが追加更新される場合があるからである。かかる場合に、検索キー判定部１５は、検索文字列に対応する検索キーを新たに生成させる。

また、検索キー判定部１５は、検索文字列に対応する更新日時４２ｅが、抽出した機密データ４２ｃに対応するいずれの更新日時４２ｅより新しいと判定した場合、後述するキャッシュ書込／読出部２２に検索結果がキャッシュに有るか否かの判定を依頼する。そして、検索キー判定部１５は、キャッシュ書込／読出部２２から検索結果が無い旨の応答を取得した場合、検索キー判定部１５によって取得されたリクエストを後述するリクエスト生成部１７に引き渡す。なお、キャッシュとは、キャッシュメモリのことを意味し、本実施例では、例えば検索結果テーブル４３のことをいう。

第２の検索キー生成部１６は、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列を部分に含む機密データ４２ｃを単数または複数抽出する。そして、第２の検索キー生成部１６は、抽出した機密データ４２ｃに対応付けられた検索キー４２ｄを用いて、新たな検索キーを生成する。例えば、第２の検索キー生成部１６は、検索文字列を部分に含む機密データ４２ｃを単数選択する場合、選択する機密データ４２ｃに対応付けられた検索キー４２ｄを抽出し、抽出した検索キー４２ｄを用いて新たな検索キーを生成する。また、第２の検索キー生成部１６は、検索文字列を部分に含む機密データ４２ｃを複数選択する場合、選択する複数の機密データ４２ｃに対応付けられたそれぞれの検索キー４２ｄを抽出する。そして、第２の検索キー生成部１６は、抽出したそれぞれの検索キー４２ｄを、例えばカンマ（，）で区切る新たな検索キーを生成する。これにより、第２の検索キー生成部１６は、検索の際に、対応テーブル４２を用いて、平文の検索文字列を部分に含む機密データについて、秘匿した検索キーを動的に生成できる。つまり、第２の検索キー生成部１６は、機密データを秘匿した単位に依存しない検索キーを生成できる。

また、第２の検索キー生成部１６は、新たな検索キーを、検索文字列と対応付けて対応テーブル４２に追加する。これにより、第２の検索キー生成部１６は、平文の検索文字列が示す機密データと当該機密データに対応する暗号文（検索キー）とを対応付けた対応テーブル４２を動的に作成できる。

リクエスト生成部１７は、ＨＴＴＰの各種リクエストを生成する。例えば、リクエスト生成部１７は、第１の検索キー生成部１４によって機密データから検索キーが生成されると、リクエストの機密データを、生成された検索キーに置き換える。そして、リクエスト生成部１７は、置き換えて得られたデータを追加または更新する旨の追加更新リクエストを生成する。また、リクエスト生成部１７は、検索キー判定部１５からリクエストを取得すると、リクエストの検索文字列を検索キーに置き換える。そして、リクエスト生成部１７は、置き換えて得られた検索キーに対応するデータを検索する旨の検索リクエストを生成する。また、リクエスト生成部１７は、第２の検索キー生成部１６によって検索文字列から新たな検索キーが生成されると、リクエストの検索文字列を、生成された検索キーに置き換える。そして、リクエスト生成部１７は、置き換えて得られた検索キーに対応するデータを検索する旨の検索リクエストを生成する。つまり、リクエスト生成部１７は、追加または更新する際の平文の機密データや検索する際の平文の検索文字列を暗号文に置き換えたリクエストデータを生成する。

リクエスト転送部１８は、ＨＴＴＰの各種リクエストをウェブサーバ３に転送する。これにより、リクエスト転送部１８は、機密データを秘匿したリクエストデータをウェブサーバ３に送信することができる。

レスポンス受付部１９は、リクエスト転送部１８によって転送されたＨＴＴＰのリクエストに対応するＨＴＴＰのレスポンスを、ウェブサーバ３から受け付ける。例えば、レスポンス受付部１９は、検索リクエストに対応するレスポンスを、ウェブサーバ３から受け付ける。また、レスポンス受付部１９は、追加更新リクエストに対応するレスポンスを、ウェブサーバ３から受け付ける。

レスポンス解析部２０は、レスポンス受付部１９によって受け付けられたレスポンスを解析する。例えば、レスポンス解析部２０は、レスポンス受付部１９から受け付けたレスポンスが検索リクエストに対応するレスポンスである場合、取得したレスポンスを検索結果復元部２１に引き渡す。また、レスポンス解析部２０は、レスポンス受付部１９から受け付けたレスポンスが追加更新リクエストに対応するレスポンスである場合、取得したレスポンスを後述するレスポンス転送部２４に引き渡す。

検索結果復元部２１は、検索リクエストに対応するレスポンスに含まれた検索結果のうち暗号化された部分を復元する。例えば、検索結果復元部２１は、検索リクエストに対応するレスポンスを取得すると、当該レスポンスに含まれた検索結果の中の検索キーに対応する機密データを対応テーブル４２から抽出する。そして、検索結果復元部２１は、検索結果の中の検索キーを、抽出した機密データに置き換えて、検索結果を復元する。そして、検索結果復元部２１は、検索キーと、復元した検索結果とをキャッシュ書込／読出部２２に引き渡す。

キャッシュ書込／読出部２２は、検索結果復元部２１から検索キーと復元した検索結果とを取得する場合、検索キーと復元した検索結果とを対応付けて検索結果テーブル４３に書き込む。

キャッシュ書込／読出部２２は、検索結果の有無の判定依頼を取得する場合、検索結果が検索結果テーブル４３に有るか否かを判定する。ここでいう検索結果とは、復元した検索結果のことをいう。例えば、キャッシュ書込／読出部２２は、検索キー判定部１５から検索キーに対応する検索結果の有無の判定依頼を取得すると、検索結果テーブル４３から検索キーに対応する、復元した検索結果が検索結果テーブル４３に記憶されているか否かを判定する。そして、キャッシュ書込／読出部２２は、検索キーに対応する、復元した検索結果が検索結果テーブル４３に記憶されていないと判定した場合、復元した検索結果が無い旨を検索キー判定部１５に応答する。一方、キャッシュ書込／読出部２２は、検索キーに対応する、復元した検索結果が検索結果テーブル４３に記憶されていると判定した場合、検索キーに対応する、復元した検索結果を検索結果テーブル４３から読み出す。そして、キャッシュ書込／読出部２２は、読み出した検索結果をレスポンス生成部２３に引き渡す。

レスポンス生成部２３は、ＨＴＴＰの各種レスポンスを生成する。例えば、レスポンス生成部２３は、キャッシュ書込／読出部２２から検索キーに対応する、復元した検索結果を取得すると、取得した復元した検索結果をレスポンスに設定することで、検索キーの検索リクエストに対応するレスポンスを生成する。

レスポンス転送部２４は、ＨＴＴＰの各種レスポンスをウェブブラウザ２に転送する。

ウェブサーバ３は、顧客ＤＢ３１および顧客情報管理アプリ３２を有する。

顧客ＤＢ３１は、秘匿化された顧客情報を記憶する。すなわち、顧客ＤＢ３１は、機密データを暗号化した状態で顧客情報を記憶する。ここで、顧客ＤＢ３１のデータ構造について、図３を参照して説明する。図３は、顧客ＤＢのデータ構造の一例を示す図である。図３に示すように、顧客ＤＢ３１は、日時３１ａ、名前３１ｂ、会社３１ｃおよびメモ３１ｄを対応付けて記憶する。日時３１ａは、顧客に対応する該当データが追加または更新された際の日時を示す。名前３１ｂは、顧客の名前である。ここでは、顧客の名前は機密データであるので、名前３１ｂは平文の名前を暗号化した暗号文で記憶されている。会社３１ｃは、顧客の所属する会社名である。メモ３１ｄは、顧客に対応する補助的な内容である。ここでは、会社名およびメモは機密データでないので、会社３１ｃおよびメモ３１ｄはそれぞれ平文で記憶されている。一例として、名前３１ｂが「ＸＸＸＸ」である場合、日時３１ａとして「２０１２／１／１」、会社３１ｃとして「Ａ社」、メモ３１ｄとして「・・・」と記憶している。

顧客情報管理アプリ３２は、顧客情報を管理するアプリケーションである。例えば、顧客情報管理アプリ３２は、データを追加または更新する旨の追加更新リクエストを取得すると、取得したリクエストに応じてリクエスト内に設定されたデータを顧客ＤＢ３１に追加または更新する。また、顧客情報管理アプリ３２は、検索キーに対応するデータを検索する旨の検索リクエストを取得すると、取得したリクエストに応じて顧客ＤＢ３１からデータを検索する。すなわち、顧客情報管理アプリ３２は、リクエストに含まれた暗号化された検索キーを用いて、顧客ＤＢ３１から該当するデータを検索する。そして、顧客情報管理アプリ３２は、レスポンスを送信元のウェブブラウザ２へ中継サーバ１を介して送信する。

［データ検索処理の具体例］
次に、データ検索処理の具体例について、図４を参照して説明する。図４は、実施例に係るデータ検索処理の具体例を説明する図である。図４では、ウェブブラウザ２（利用者）から、名前が「山田」のデータを検索する旨のＨＴＴＰの検索リクエストが送信される場合について説明する。ここでは、検索リクエストの検索文字列は平文の「山田」である。なお、対応テーブル４２には、項番４２ａ「１」について、機密データ４２ｃ「山田 太郎」と検索キー４２ｄ「ＸＸＸＸ」とが対応付けて記憶されている。項番４２ａ「２」について、機密データ４２ｃ「山田 花子」と検索キー４２ｄ「ＹＹＹＹ」とが対応付けて記憶されている。

図４に示すように、中継サーバ１では、リクエスト受付部１１が、ウェブブラウザ２から送信された検索リクエストを受け付ける。そして、検索キー判定部１５は、検索リクエストの検索文字列が対応テーブル４２に記憶されたいずれかの機密データ４２ｃと完全一致であるか否かを判定する。ここでは、対応テーブル４２には、検索文字列「山田」と完全一致である機密データ４２ｃがないので、検索キー判定部１５は、検索リクエストの検索文字列「山田」がいずれかの機密データ４２ｃと完全一致でないと判定する。

そして、第２の検索キー生成部１６は、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列を部分に含む機密データ４２ｃを抽出する。ここでは、検索文字列「山田」を部分に含む機密データ４２ｃとして「山田 太郎」、「山田 花子」が抽出される。

そして、第２の検索キー生成部１６は、機密データ４２ｃに対応付けられた検索キー４２ｄを用いて、新たな検索キーを生成する。ここでは、検索文字列を部分に含む機密データ４２ｃが複数選択されるので、第２の検索キー生成部１６は、選択される複数の機密データ４２ｃに対応付けられたそれぞれの検索キー４２ｄを抽出する。そして、第２の検索キー生成部１６は、抽出したそれぞれの検索キー４２ｄを「，」で区切る新たな検索キーを生成する。すなわち、新たな検索キーとして「ＸＸＸＸ，ＹＹＹＹ」が生成される。これにより、第２の検索キー生成部１６は、検索文字列「山田」を部分に含む機密データ「山田 太郎」、「山田 花子」を秘匿する検索キー「ＸＸＸＸ，ＹＹＹＹ」を動的に生成できる。つまり、第２の検索キー生成部１６は、秘匿した機密データの単位（「山田 太郎」、「山田 次郎」）に依存しないで検索させることが可能となる。

そして、第２の検索キー生成部１６は、新たな検索キーを、検索文字列と対応付けて対応テーブル４２に追加する。ここでは、第２の検索キー生成部１６は、新たな検索キー「ＸＸＸＸ，ＹＹＹＹ」を、平文の検索文字列「山田」と対応付けて対応テーブル４２に追加する。これにより、第２の検索キー生成部１６は、平文の検索文字列「山田」が示す機密データと当該機密データに対応する暗号文（検索キー）「ＸＸＸＸ，ＹＹＹＹ」とを対応付けた対応テーブル４２を動的に作成できる。

中継サーバ１では、リクエスト転送部１８が、リクエストの検索文字列を、暗号化された検索キーに置き換えた検索リクエストをウェブサーバ３に転送する。

ウェブサーバ３では、顧客情報管理アプリ３２が、暗号化された検索キーに対応するデータを顧客ＤＢ３１から検索する。ここでは、顧客情報管理アプリ３２は、検索キー「ＸＸＸＸ，ＹＹＹＹ」に対応するデータを検索する。すなわち、顧客情報管理アプリ３２は、検索キー「ＸＸＸＸ」に対応するデータおよび検索キー「ＹＹＹＹ」に対応するデータを検索する。そして、顧客情報管理アプリ３２は、検索結果を含むレスポンスを、中継サーバ１を介してウェブブラウザ２に送信する。

中継サーバ１では、検索結果復元部２１が、レスポンスに含まれた検索結果のうち暗号化された部分を、対応テーブル４２を用いて復元する。ここでは、検索結果復元部２１は、検索結果のうち暗号化された検索キー「ＸＸＸＸ」の部分を「山田 太郎」に、「ＹＹＹＹ」の部分を「山田 花子」に復元する。そして、レスポンス転送部２４は、暗号化された検索結果を、復号化された検索結果に置き換えたレスポンスをウェブブラウザ２に転送する。

［検索キー生成処理の具体例］
ここで、検索キー生成処理の具体例について、図５Ａおよび図５Ｂを参照して説明する。図５Ａおよび図５Ｂは、検索キー生成処理の具体例を説明する図である。

図５Ａに示すように、ウェブブラウザ２側の秘匿前のデータが追加更新処理によってウェブサーバ３側の顧客ＤＢ３１に秘匿後のデータとして記憶される。ここでは、名前が機密データであるものとし、顧客ＤＢ３１には、名前の内容が秘匿化されている。そして、中継サーバ１には、対応テーブル４２に機密データ４２ｃが「山田 太郎」、「山田 花子」に対応付けられる検索キー４２ｄおよび更新日時４２ｅが記憶されている。

このような状況の下、ウェブブラウザ２（利用者）から、名前が「山田」のデータを検索する旨のＨＴＴＰの検索リクエストが送信されると、検索キー判定部１５は、検索文字列「山田」と完全一致である機密データ４２ｃがないと判定する。そして、第２の検索キー生成部１６は、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列を部分に含む機密データ４２ｃを抽出する。ここでは、「山田 太郎」、「山田 花子」が抽出される。

そして、第２の検索キー生成部１６は、機密データ４２ｃに対応付けられた検索キー４２ｄを用いて、新たな検索キーを生成する。ここでは、新たな検索キーとして「ＸＸＸＸ，ＹＹＹＹ」が生成される。そして、第２の検索キー生成部１６は、新たな検索キーを、検索文字列と対応付けて対応テーブル４２に追加することになる。ここでは、項番４２ａ「３」が示すレコードに、機密データ４２ｃとして「山田」、検索キー４２ｄとして「ＸＸＸＸ，ＹＹＹＹ」、更新日時４２ｅとして「２０１２／０３／０１」が追加される。

図５Ｂに示すように、項番４２ａ「３」が示すレコードに新たな機密データおよび検索キーが追加された状態の下、ウェブブラウザ２（利用者）から、データａ１を追加する旨の追加更新リクエストが送信されるとする。すると、中継サーバ１では、ウェブブラウザ２側の秘匿前のデータａ１に対応するレコードが追加更新処理によって対応テーブル４２に追加される。ここでは、項番４２ａ「４」が示すレコードｂ１に、機密データ４２ｃとして「山田 次郎」、検索キー４２ｄとして「ＺＺＺＺ」、更新日時４２ｅとして「２０１２／０４／０１」が追加されている。そして、ウェブブラウザ２側の秘匿前のデータａ１が追加更新処理によってウェブサーバ３側の顧客ＤＢ３１に秘匿後のデータｃ１として記憶される。

このような状況の下、ウェブブラウザ２（利用者）から、名前が「山田」のデータを検索する旨のＨＴＴＰの検索リクエストが送信されると、検索キー判定部１５は、検索文字列「山田」と完全一致である機密データ４２ｃが項番４２ａ「３」にあると判定する。そして、検索キー判定部１５は、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列「山田」を部分に含む機密データ４２ｃを抽出する。ここでは、「山田 太郎」、「山田 花子」、「山田 次郎」が抽出される。

さらに、検索キー判定部１５は、検索文字列「山田」と完全一致した機密データ４２ｃに対応する更新日時４２ｅが、抽出した機密データ４２ｃに対応するいずれかの更新日時４２ｅより古いか否かを判定する。ここでは、検索文字列「山田」と完全一致した機密データ４２ｃに対応する更新日時４２ｅは、「２０１２／０３／０１」である。抽出した機密データ４２ｃ「山田 太郎」、「山田 花子」、「山田 次郎」に対応する更新日時４２ｅは、それぞれ「２０１２／０１／０１」、「２０１２／０２／０１」、「２０１２／０４／０１」である。したがって、検索文字列「山田」に対応する更新日時４２ｅは、「山田 次郎」に対応する更新日時４２ｅより古いと判定される。

そこで、検索キー判定部１５は、第２の検索キー生成部１６に、検索文字列「山田」に対応する検索キーを新たに生成させる。すなわち、第２の検索キー生成部１６は、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列を部分に含む機密データ４２ｃを抽出する。ここでは、「山田 太郎」、「山田 花子」、「山田 次郎」が抽出される。

そして、第２の検索キー生成部１６は、機密データ４２ｃに対応付けられた検索キー４２ｄを用いて、新たな検索キーを生成する。ここでは、新たな検索キーとして「ＸＸＸＸ，ＹＹＹＹ，ＺＺＺＺ」が生成される。そして、第２の検索キー生成部１６は、新たな検索キーを、検索文字列と対応付けて対応テーブル４２に更新することになる。ここでは、項番４２ａ「３」が示す機密データ４２ｃ「山田」に対応するレコードｂ２に、検索キー４２ｄとして「ＸＸＸＸ，ＹＹＹＹ，ＺＺＺＺ」、更新日時４２ｅとして「２０１２／０４／０２」が更新される。

［リクエストの具体例］
次に、データを追加、更新および検索する場合のリクエストについて、図６Ａ〜図６Ｃを参照して説明する。図６Ａは、データを追加する場合のリクエストの一例を示す図である。図６Ｂは、データを更新する場合のリクエストの一例を示す図である。図６Ｃは、データを検索する場合のリクエストの一例を示す図である。なお、図６Ａ〜図６Ｃでは、機密データを名前とし、名前のフォーム属性を「ｎａｍｅ」とする。

図６Ａ上図には、中継サーバ１がウェブブラウザ２から受け取る、データを追加する場合のリクエストが表されている。図６Ａ上図に示すように、データを追加する場合のリクエストには、リクエストラインｒ１とリクエストヘッダーｒ２とメッセージボディｒ３とが含まれる。メッセージボディｒ３に、データのフォーム属性とその属性値とが設定される。そして、機密データに関して、更新前後のフォーム属性とその属性値とが設定される。

ここでは、機密データである名前の更新前のフォーム属性「ｆｒｏｍ＿ｎａｍｅ」の属性値としてヌルが設定されている。機密データである名前の更新後のフォーム属性「ｔｏ−ｎａｍｅ」の属性値として「山田 太郎」が設定されている。会社のフォーム属性「ｃｏｍｐａｎｙ」の属性値として「Ａ社」が設定されている。日時のフォーム属性「ｄａｔｅ」の属性値として「２０１２−０１−０１」が設定されている。メモのフォーム属性「ｍｅｍｏ」の属性値として「＊＊＊＊＊＊＊＊＊＊」が設定されている。すなわち、かかるリクエストは、機密データとして示される名前「山田 太郎」に関するデータを追加する旨のリクエストである。

図６Ａ下図には、中継サーバ１がウェブサーバ３に送信する、データを追加する場合のリクエストが表されている。図６Ａ下図に示すように、メッセージボディｒ３１に、機密データである名前の更新後のフォーム属性「ｔｏ＿ｎａｍｅ」の属性値として「ＸＸＸＸ」が設定されている。すなわち、中継サーバ１は、リクエストを中継サーバ１からウェブサーバ３に送信する場合、機密データである「山田太郎」から暗号化された「ＸＸＸＸ」に置き換えて送信する。

図６Ｂには、中継サーバ１がウェブブラウザ２から受け取る、データを更新する場合のリクエストが表されている。図６Ｂに示すように、データを更新する場合のリクエストには、リクエストラインｒ１とリクエストヘッダーｒ２とメッセージボディｒ３２とが含まれる。メッセージボディｒ３２に、データのフォーム属性とその属性値とが設定される。そして、機密データに関して、更新前後のフォーム属性とその属性値とが設定される。

ここでは、機密データである名前の更新前のフォーム属性「ｆｒｏｍ＿ｎａｍｅ」の属性値として「山田 太郎」が設定されている。機密データである名前の更新後のフォーム属性「ｔｏ＿ｎａｍｅ」の属性値として「山田 花子」が設定されている。すなわち、かかるリクエストは、機密データとして示される名前「山田 太郎」に関するデータについて、「山田 太郎」を「山田 花子」に更新する旨のリクエストである。

なお、中継サーバ１がウェブサーバ３に送信する、データを更新する場合のリクエストは、「山田 太郎」および「山田 花子」をそれぞれ暗号化した暗号化文字列に置き換えて送信される。

図６Ｃには、中継サーバ１がウェブブラウザ２から受け取る、データを検索する場合のリクエストが表されている。図６Ｃに示すように、データを検索する場合のリクエストには、リクエストラインｒ１とリクエストヘッダーｒ２とメッセージボディｒ３３とが含まれる。メッセージボディｒ３３に、データのフォーム属性とその属性値とが設定される。そして、機密データに関して、検索に関わるフォーム属性とその属性値とが設定される。検索に関わるフォーム属性の属性値が検索文字列となる。

ここでは、検索に関わるフォーム属性「ｎａｍｅ＿ｑｕｅｒｙ１」の属性値として「山田太郎」が設定されている。検索に関わるフォーム属性「ｎａｍｅ＿ｑｕｅｒｙ２」の属性値として「山田花子」が設定されている。「山田 太郎」および「山田 花子」が検索文字列となる。すなわち、かかるリクエストは、「山田 太郎」および「山田 花子」に関するデータについて検索する旨のリクエストである。

なお、中継サーバ１がウェブサーバ３に送信する、データを検索する場合のリクエストは、「山田 太郎」および「山田 花子」をそれぞれ暗号化した暗号化文字列に置き換えて送信される。

［データの追加更新処理の手順］
次に、図７を参照して、データの追加更新処理の手順を説明する。図７は、データの追加更新処理のフローチャートを示す図である。なお、データを追加または更新する旨のリクエスト（追加更新リクエスト）がウェブブラウザ２から送信されたものとする。リクエストには、平文のデータが設定されている。

まず、中継サーバ１では、リクエスト受付部１１が、ウェブブラウザ２から送信されたリクエストを受け取る（ステップＳ１１）。

そして、機密データ判定部１３は、受け取ったリクエストの平文のデータに機密データが含まれているか否かを判定する（ステップＳ１２）。例えば、機密データ判定部１３は、データポリシーテーブル４１に記憶された情報から、データポリシーを有するフォーム属性を読み出す。そして、機密データ判定部１３は、読み出したフォーム属性がリクエストのメッセージボディに含まれているか否かを判定する。

リクエストの平文のデータに機密データが含まれていないと判定した場合（ステップＳ１２；Ｎｏ）、機密データ判定部１３は、リクエストをそのまま送信すべく、ステップＳ２０に移行する。

一方、リクエストの平文のデータに機密データが含まれていると判定した場合（ステップＳ１２；Ｙｅｓ）、第１の検索キー生成部１４は、当該機密データが対応テーブル４２に記憶されているか否かを判定する（ステップＳ１３）。例えば、第１の検索キー生成部１４は、リクエストのメッセージボディから、機密データに対応するフォーム属性の更新前後の属性値を参照する。そして、第１の検索キー生成部１４は、更新前後の属性値のうちいずれか一方の属性値が対応テーブル４２の同じフォーム属性４２ｂに対応する機密データ４２ｃに記憶されているか否かを判定する。

機密データが対応テーブル４２に記憶されていないと判定した場合（ステップＳ１３；Ｎｏ）、第１の検索キー生成部１４は、当該機密データを含むデータが追加されるデータであると判断する。そして、第１の検索キー生成部１４は、機密データを秘匿（暗号化）する（ステップＳ１４）。すなわち、第１の検索キー生成部１４は、機密データから暗号化された暗号化文字列を生成する。

そして、第１の検索キー生成部１４は、機密データ、暗号化文字列、フォーム属性および更新日時を示すタイムスタンプを対応テーブル４２に新規追加する（ステップＳ１５）。そして、第１の検索キー生成部１４は、機密データを暗号化文字列に置き換えたリクエストを送信すべく、ステップＳ２０に移行する。

一方、機密データが対応テーブル４２に記憶されていると判定した場合（ステップＳ１３；Ｙｅｓ）、第１の検索キー生成部１４は、当該機密データが更新されるか否かを判定する（ステップＳ１６）。例えば、第１の検索キー生成部１４は、リクエストのメッセージボディから、機密データに対応するフォーム属性の更新前後の属性値を参照する。そして、第１の検索キー生成部１４は、更新前後の属性値に異なる値が設定されているか否かを判定する。なお、更新前後の属性値にそれぞれヌル以外の異なる値が設定されていれば、更新前の属性値から更新後の属性値に機密データが更新されると判断される。更新前の属性値にヌル以外の値が設定され、更新後の属性値にヌルが設定されていれば、更新前の属性値の機密データが削除されると判断される。更新前後の属性値にヌル以外の同じ値が設定されていれば、機密データが更新されないと判断される。

機密データが更新されると判定した場合（ステップＳ１６；Ｙｅｓ）、第１の検索キー生成部１４は、機密データを秘匿（暗号化）する（ステップＳ１７）。すなわち、第１の検索キー生成部１４は、機密データから暗号化された暗号化文字列を生成する。

そして、第１の検索キー生成部１４は、機密データ、暗号化文字列、フォーム属性および更新日時を示すタイムスタンプを対応テーブル４２に更新する（ステップＳ１８）。そして、第１の検索キー生成部１４は、機密データを暗号化文字列に置き換えたリクエストを送信すべく、ステップＳ２０に移行する。

一方、機密データが更新されないと判定した場合（ステップＳ１６；Ｎｏ）、第１の検索キー生成部１４は、更新日時を示すタイムスタンプのみを対応テーブル４２に更新する（ステップＳ１９）。そして、第１の検索キー生成部１４は、リクエストをそのまま送信すべく、ステップＳ２０に移行する。

ステップＳ２０では、リクエスト転送部１８は、ウェブサーバ３にリクエストを送信する（ステップＳ２０）。これにより、中継サーバ１は、機密データを秘匿したままデータを追加更新するリクエストをウェブサーバ３に送信できる。

［データの検索処理の手順］
次に、図８を参照して、データの検索処理の手順を説明する。図８は、データの検索処理のフローチャートを示す図である。なお、データを検索する旨のリクエスト（検索リクエスト）がウェブブラウザ２から送信されたものとする。リクエストには、平文のデータが設定されている。

まず、中継サーバ１では、リクエスト受付部１１が、ウェブブラウザ２から送信されたリクエストを受け取る。そして、検索キー判定部１５は、リクエストの検索文字列（平文）を受け取る（ステップＳ３１）。

そして、検索キー判定部１５は、対応テーブル４２に、受け取った検索文字列と完全一致する機密データがあるか否かを判定する（ステップＳ３２）。検索文字列と完全一致する機密データがないと判定した場合（ステップＳ３２；Ｎｏ）、検索キー判定部１５は、検索文字列から検索キーを生成すべく、ステップＳ３８に移行する。

一方、検索文字列と完全一致する機密データがあると判定した場合（ステップＳ３２；Ｙｅｓ）、検索キー判定部１５は、対応テーブル４２から、検索文字列と完全一致する機密データ４２ｃに対応する更新日時４２ｅを取得する（ステップＳ３３）。ここでは、検索文字列と完全一致する機密データ４２ｃに対応する更新日時４２ｅを「Ａ」とする。検索キー判定部１５は、対応テーブル４２から、検索文字列を含む機密データ４２ｃに対応する更新日時４２ｅを取得する（ステップＳ３４）。ここでは、検索文字列を含む機密データ４２ｃに対応する更新日時４２ｅを「Ｂ」とする。検索文字列を含む機密データ４２ｃは、検索文字列を部分に含む機密データ４２ｃのみならず、検索文字列を全体に含む機密データ４２ｃを含む。

そして、検索キー判定部１５は、検索文字列に対応する更新日時４２ｅ（Ａ）が検索文字列を含む機密データ４２ｃに対応する更新日時４２ｅ（Ｂ）以上であるか否かを判定する（ステップＳ３５）。すなわち、検索キー判定部１５は、検索文字列に対応する更新日時４２ｅ（Ａ）が検索文字列を含む機密データ４２ｃに対応するいずれかの更新日時４２ｅ（Ｂ）より古くないか否かを判定する。検索文字列に対応する更新日時４２ｅ（Ａ）が検索文字列を含む機密データ４２ｃに対応する更新日時４２ｅ（Ｂ）未満であると判定した場合（ステップＳ３５；Ｎｏ）、検索キー判定部１５は、検索文字列から検索キーを生成すべく、ステップＳ３８に移行する。

検索文字列に対応する更新日時４２ｅ（Ａ）が検索文字列を含む機密データ４２ｃに対応する更新日時４２ｅ（Ｂ）以上であると判定した場合（ステップＳ３５；Ｙｅｓ）、キャッシュ書込／読出部２２は、以下の処理を行う。すなわち、キャッシュ書込／読出部２２は、検索文字列に対応する検索キー４２ｄの数が検索結果テーブル４３に記憶された同じ検索キーに対応するデータの数と一致するか否かを判定する（ステップＳ３６）。例えば、検索文字列に対応する検索キー４２ｄが「ＸＸＸＸ、ＹＹＹＹ」である場合、キャッシュ書込／読出部２２は、検索結果テーブル４３に「ＸＸＸＸ」と「ＹＹＹＹ」に対応する２個のデータがあるか否かを判定する。

検索キー４２ｄの数が同じ検索キーに対応するデータの数と一致しないと判定した場合（ステップＳ３６；Ｎｏ）、検索キー判定部１５は、検索文字列から検索キーを生成すべく、ステップＳ３８に移行する。

一方、検索キー４２ｄの数が同じ検索キーに対応するデータの数と一致すると判定した場合（ステップＳ３６；Ｙｅｓ）、キャッシュ書込／読出部２２は、検索キー４２ｄに対応する検索結果を検索結果テーブル４３から読み出す。そして、レスポンス転送部２４は、検索結果テーブル４３から読み出した検索結果をウェブブラウザ２に返却する（ステップＳ３７）。そして、データの検索処理は終了する。

ステップＳ３８では、第２の検索キー生成部１６は、検索文字列から検索キーを生成する（ステップＳ３８）。例えば、第２の検索キー生成部１６は、対応テーブル４２から、検索文字列を含む機密データ４２ｃを選択する。検索文字列を含む機密データ４２ｃは、検索文字列を部分に含む機密データ４２ｃのみならず、検索文字列を全体に含む機密データ４２ｃを含む。そして、第２の検索キー生成部１６は、機密データ４２ｃを単数選択した場合、選択した機密データ４２ｃに対応付けられた検索キー４２ｄを抽出し、抽出した検索キー４２ｄを用いて新たな検索キーを生成する。第２の検索キー生成部１６は、機密データ４２ｃを複数選択した場合、選択した機密データ４２ｃに対応付けられたそれぞれの検索キー４２ｄを抽出し、抽出した検索キー４２ｄを「，」で区切る新たな検索キーを生成する。

そして、第２の検索キー生成部１６は、生成した検索キーを、検索文字列と対応付けて対応テーブル４２に追加する（ステップＳ３９）。そして、リクエスト転送部１８は、検索文字列を検索キーに置き換えたリクエストをウェブサーバ３に送信する（ステップＳ４０）。これにより、中継サーバ１は、検索キーを秘匿したままデータを検索するリクエストをウェブサーバ３に送信できる。

その後、レスポンス受付部１９は、リクエストに対応するレスポンスを、ウェブサーバ３から受け付ける。そして、検索結果復元部２１は、レスポンスの検索結果を受け取り（ステップＳ４１）、検索結果を復元する（ステップＳ４２）。例えば、検索結果復元部２１は、検索結果の中の検索キーに対応する機密データを対応テーブル４２から抽出する。そして、検索結果復元部２１は、検索結果の中の検索キーを、抽出した機密データに置き換えて、検索結果を復元する。

そして、キャッシュ書込／読出部２２は、復元した検索結果を検索キーとともに検索結果テーブル４３にキャッシュする（ステップＳ４３）。そして、レスポンス転送部２４は、復元した検索結果をウェブブラウザ２に返却する（ステップＳ４４）。そして、データの検索処理は終了する。

これにより、中継サーバ１は、検索の際に、平文の検索文字列を部分に含む機密データを秘匿する検索キーを動的に生成できる。この結果、利用者は、ウェブサーバ３から秘匿後のデータを秘匿したまま柔軟に検索することができる。

［実施例の効果］
上記実施例によれば、中継サーバ１は、ウェブブラウザ２から受信したデータに含まれる機密情報を暗号化し、暗号化した機密情報である暗号情報をウェブサーバ３に送信する。そして、中継サーバ１は、機密情報と暗号情報とを対応付けて対応テーブル４２に記録する。さらに、中継サーバ１は、ウェブブラウザ２から受信した秘匿前の検索キーに少なくとも一部が一致する機密情報を対応テーブル４２から選択し、選択した機密情報に対応付けられた暗号情報それぞれを暗号化された検索キーとして生成する。そして、中継サーバ１は、生成した暗号化された検索キーをウェブサーバ３に送信する。かかる構成によれば、中継サーバ１は、検索の際に、対応テーブル４２に記憶された情報に基づいて、秘匿前の検索キーを部分に含む秘匿後の検索キーを動的に生成できる。この結果、中継サーバ１は、ウェブサーバ３がデータを秘匿して保管する場合、秘匿後のデータを柔軟に検索することが可能となる。

また、上記実施例によれば、中継サーバ１は、ウェブブラウザ２からデータの更新を所望する機密情報を受信すると、受信した機密情報を暗号化し、暗号化した機密情報である暗号情報をウェブサーバ３に送信する。そして、中継サーバ１は、更新を所望する機密情報と暗号情報とを対応付けて対応テーブルを更新する。かかる構成によれば、中継サーバ１は、機密情報が更新された場合であっても、ウェブサーバ３の秘匿後のデータを柔軟に検索することが可能となる。

また、上記実施例によれば、中継サーバ１は、ウェブブラウザ２から取得された秘匿前の検索キーが対応テーブル４２に記憶された情報内のいずれかの機密情報と完全一致であるか否かを判定する。そして、中継サーバ１は、秘匿前の検索キーが対応テーブル４２に記憶された情報内のいずれの機密情報とも完全一致でないと判定した場合、対応テーブル４２に記憶された情報内の機密情報のうち秘匿前の検索キーを部分に含む機密情報を単数または複数選択する。そして、中継サーバ１は、選択した機密情報に対応付けられた暗号情報を抽出し、抽出した暗号情報を用いて暗号化された検索キーを生成する。かかる構成によれば、中継サーバ１は、機密情報を秘匿した単位に依存しない秘匿後の検索キーを生成できる。この結果、中継サーバ１は、ウェブサーバ３の秘匿後のデータを柔軟に検索することが可能となる。

また、上記実施例によれば、中継サーバ１は、検索キーを生成する処理によって生成された、暗号化された検索キーを、秘匿前の検索キーと対応付けて対応テーブル４２に記録する。かかる構成によれば、中継サーバ１は、検索キーを生成する処理によって生成された秘匿後の検索キーを秘匿前の検索キーと対応付けて対応テーブル４２に記録するので、対応テーブル４２を動的に生成できる。

また、上記実施例によれば、中継サーバ１は、対応テーブル２４に記録した際の記録日時を対応付けて対応テーブル４２に記録する。そして、中継サーバ１は、秘匿前の検索キーが対応テーブル４２に記憶された情報内のいずれかの機密情報と完全一致であると判定した場合、対応テーブル４２に秘匿前の検索キーを部分に含む機密情報があれば当該機密情報を単数または複数選択する。そして、中継サーバ１は、秘匿前の検索キーに対応する記録日時が、選択した機密情報に対応するいずれかの記録日時より古ければ、秘匿前の検索キーに対応する暗号化された検索キーを新たに生成する。かかる構成によれば、中継サーバ１は、新しく記録された機密情報を考慮したうえで、秘匿後の検索キーを動的に生成できる。さらに、中継サーバ１は、新たに生成した暗号化された検索キーを秘匿前の検索キーと対応付けて対応テーブル４２を更新することで、対応テーブル４１を学習させることが可能となる。

［プログラムなど］
なお、上記実施例では、第２の検索キー生成部１６は、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列を部分に含む機密データ４２ｃを抽出すると説明した。そして、図４等で示すように、第２の検索キー生成部１６は、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列と前方一致する機密データ４２ｃを抽出する場合を説明した。しかしながら、第２の検索キー生成部１６は、これに限定されず、対応テーブル４２に記憶された機密データ４２ｃのうち検索文字列と後方一致する機密データ４２ｃを抽出しても良いし、中間一致する機密データ４２ｃを抽出しても良い。この結果、第２の検索キー生成部１６は、機密データを秘匿する検索キーを柔軟に生成でき、ひいてはウェブサーバ３から秘匿後のデータを秘匿したまま柔軟に検索させることができる。

また、中継サーバ１は、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記した追加更新処理部１Ａおよび検索処理部１Ｂなどの各機能を搭載することによって実現することができる。

また、図示した装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、機密データ判定部１３と第１の検索キー生成部１４とを１個の部として統合しても良い。検索キー判定部１５と第２の検索キー生成部１６とを１個の部として統合しても良い。一方、第１の検索キー生成部１４を機密データを含むデータを追加する場合の検索キー生成部と機密データを含むデータを更新する場合の検索キー生成部と機密データを含まないデータを更新する場合の検索キー生成部とに分散しても良い。また、データポリシーテーブル４１、対応テーブル４２および検索結果テーブル４３を中継サーバ１の外部装置としてネットワーク経由で接続するようにしても良い。

また、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１に示した中継サーバ１と同様の機能を実現するデータ検索プログラムを実行するコンピュータの一例を説明する。図９は、データ検索プログラムを実行するコンピュータの一例を示す図である。

図９に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９を制御する表示制御部２０７とを有する。また、コンピュータ２００は、記憶媒体からプログラムなどを読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信制御部２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示制御部２０７、ドライブ装置２１３、入力装置２１５、通信制御部２１７は、バス２１９で接続されている。

ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、データ検索プログラム２０５ａおよびデータ検索関連情報２０５ｂを記憶する。

ＣＰＵ２０３は、データ検索プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスは、中継サーバ１の各機能部に対応する。データ検索関連情報２０５ｂは、データポリシーテーブル４１、対応テーブル４２および検索結果テーブル４３に対応する。そして、例えばリムーバブルディスク２１１が、データ検索プログラム２０５ａなどの各情報を記憶する。

なお、データ検索プログラム２０５ａについては、必ずしも最初からＨＤＤ２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらからデータ検索プログラム２０５ａを読み出して実行するようにしても良い。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）中継装置が、
第１の情報処理装置から受信したデータに含まれる第１の情報と前記第１の情報を変換した第２の情報とを対応づけて記録する記憶部から、前記第１の情報処理装置から受信した第１の検索キーに少なくとも一部が一致する第１の情報を複数選択し、
選択した複数の前記第１の情報に対応付けられた前記第２の情報それぞれを第２の検索キーとして生成し、
生成した第２の検索キーを前記第２の情報処理装置に送信する、
処理を実行することを特徴とするデータ検索方法。

（付記２）前記中継装置が、
前記第１の情報処理装置から前記データの更新を所望する第３の情報を受信すると、前記更新データに含まれる第３の情報を他の第２の情報に変換し、変換した第２の情報を前記第２の情報処理装置に送信し、
前記更新データに含まれる第３の情報と他の前記第２の情報とを対応付けて前記記憶部を更新する
ことを特徴とする付記１に記載のデータ検索方法。

（付記３）前記中継装置が、
該第２の検索キーを生成する処理は、
前記第１の情報処理装置から受信した第１の検索キーが前記記憶部に記憶された情報内のいずれかの第１の情報と完全一致であるか否かを判定し、
該判定する処理の結果、前記第１の検索キーが前記記憶部に記憶された情報内のいずれの第１の情報とも完全一致でないと判定した場合、前記記憶部に記憶された情報内の第１の情報のうち前記第１の検索キーに少なくとも一部が一致する前記第１の情報を選択し、選択した前記第１の情報に対応付けられた前記第２の情報それぞれを用いて前記第２の検索キーを生成する
ことを特徴とする付記１または付記２に記載のデータ検索方法。

（付記４）前記中継装置が、
該第２の検索キーを生成する処理によって生成された前記第２の検索キーを、前記第１の情報処理装置から受信した前記第１の検索キーと対応付けて前記記憶部に記録する
ことを特徴とする付記３に記載のデータ検索方法。

（付記５）前記中継装置が、
前記記憶部に記録する処理は、さらに、前記記憶部に記録した際の記録日時を前記第１の検索キーと対応付けて前記記憶部に記録し、
該判定する処理の結果、前記第１の検索キーが前記記憶部に記憶された情報内のいずれかの第１の情報と完全一致であると判定した場合、前記記憶部に記憶された情報内の第１の情報のうち前記第１の検索キーに少なくとも一部が一致する前記第１の情報があれば当該第１の情報を選択し、前記第１の検索キーに対応する記録日時が、選択した前記第１の情報に対応付けられたいずれかの記録日時より古ければ、前記第１の検索キーに対応する第２の検索キーを新たに生成する
ことを特徴とする付記４に記載のデータ検索方法。

（付記６）前記中継装置が、
前記第２の情報処理装置から受信した前記第２の検索キーに対応する検索結果をキャッシュメモリに記録し、
前記第１の情報処理装置から第１の検索キーを受信すると、該第２の検索キーを生成する処理によって生成される第２の検索キーに対応する検索結果が前記キャッシュメモリにあれば、前記第２の検索キーを前記第２の情報処理装置に送信しないで前記キャッシュメモリに記憶された検索結果を前記第１の情報処理装置に送信する
ことを特徴とする付記１から付記５のいずれか１つに記載のデータ検索方法。

（付記７）コンピュータに、
第１の情報処理装置から受信したデータに含まれる第１の情報と前記第１の情報を変換した第２の情報とを対応づけて記録する記憶部から、前記第１の情報処理装置から受信した第１の検索キーに少なくとも一部が一致する第１の情報を複数選択し、
選択した複数の前記第１の情報に対応付けられた前記第２の情報それぞれを第２の検索キーとして生成し、生成した第２の検索キーを前記第２の情報処理装置に送信する、
各処理を実行させることを特徴とするデータ検索プログラム。

（付記８）第１の情報処理装置から受信したデータに含まれる第１の情報と前記第１の情報を変換した第２の情報とを対応づけて記憶する記憶部と、
前記記憶部から、前記第１の情報処理装置から受信した第１の検索キーに少なくとも一部が一致する第１の情報を複数選択し、選択した複数の前記第１の情報に対応付けられた前記第２の情報それぞれを第２の検索キーとして生成する生成部と、
前記生成部によって生成された第２の検索キーを前記第２の情報処理装置に送信する第２の送信部と、
を有することを特徴とする中継装置。

１ 中継サーバ
２ ウェブブラウザ
３ ウェブサーバ
９ データ検索システム
１１ リクエスト受付部
１２ リクエスト解析部
１３ 機密データ判定部
１４ 第１の検索キー生成部
１５ 検索キー判定部
１６ 第２の検索キー生成部
１７ リクエスト生成部
１８ リクエスト転送部
１９ レスポンス受付部
１Ａ 追加更新処理部
１Ｂ 検索処理部
２０ レスポンス解析部
２１ 検索結果復元部
２２ キャッシュ書込／読出部
２３ レスポンス生成部
２４ レスポンス転送部
３１ 顧客ＤＢ
３２ 顧客情報管理アプリ
４１ データポリシーテーブル
４２ 対応テーブル
４３ 検索結果テーブル

Claims (6)

1. 中継装置が、
   第１の情報処理装置から検索リクエストを受信すると、前記第１の情報処理装置から受信したデータに含まれる第１の情報と前記第１の情報を暗号化した第２の情報とを対応付けて記憶する記憶部を参照して、前記検索リクエストに含まれる第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されているか否かを判定し、
   前記第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されている場合には、該第１の情報が最新の情報であるか否かを判定し、該第１の情報が最新の情報である場合には、前記第１の検索キーと完全一致する前記第１の情報を選択し、該第１の情報が最新の情報でない場合、または、前記第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されていない場合には、前記検索リクエストに含まれる第１の検索キーに少なくとも一部が一致する第１の情報を１つ以上選択し、
   選択した１つ以上の前記第１の情報に対応する前記第２の情報に基づいて、第２の検索キーを生成し、
   生成した前記第２の検索キーを第２の情報処理装置に送信する、
   処理を実行することを特徴とするデータ検索方法。
2. 前記第１の情報は、さらに、該第１の情報が前記記憶部に記憶された際の記録日時を対応付けて前記記憶部に記憶され、
   前記選択する処理は、前記第１の情報が最新の情報であるか否かの判定の際に、前記記録日時に基づいて、該第１の情報が最新の情報であるか否かを判定する、
   ことを特徴とする請求項１に記載のデータ検索方法。
3. 前記生成する処理は、前記第１の検索キーおよび生成した前記第２の検索キーを、前記第１の情報および該第１の情報に対応する前記第２の情報として、前記記憶部に記憶する、
   ことを特徴とする請求項１または２に記載のデータ検索方法。
4. 中継装置が、
   第１の情報処理装置から追加更新リクエストを受信すると、受信した前記追加更新リクエストに含まれる第１の情報が、前記第１の情報処理装置から受信したデータに含まれる第１の情報と該第１の情報を暗号化した第２の情報とを対応付けて記憶する記憶部に記憶されているか否かを判定し、
   前記追加更新リクエストに含まれる第１の情報が前記記憶部に記憶されている場合には、前記追加更新リクエストに含まれる第１の情報を暗号化して第２の情報を生成し、該第１の情報と生成した該第２の情報とを用いて、前記記憶部に記憶された第１の情報および該第１の情報に対応する第２の情報を更新し、前記追加更新リクエストに含まれる第１の情報が前記記憶部に記憶されていない場合には、前記追加更新リクエストに含まれる第１の情報を暗号化して第２の情報を生成し、該第１の情報と生成した該第２の情報を前記記憶部に記憶し、
   前記追加更新リクエストに含まれる第１の情報を、生成した前記第２の情報に置き換えた追加更新リクエストを第２の情報処理装置に送信する、
   処理を実行することを特徴とするデータ追加更新方法。
5. コンピュータに、
   第１の情報処理装置から検索リクエストを受信すると、前記第１の情報処理装置から受信したデータに含まれる第１の情報と前記第１の情報を暗号化した第２の情報とを対応付けて記憶する記憶部を参照して、前記検索リクエストに含まれる第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されているか否かを判定し、
   前記第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されている場合には、該第１の情報が最新の情報であるか否かを判定し、該第１の情報が最新の情報である場合には、前記第１の検索キーと完全一致する前記第１の情報を選択し、該第１の情報が最新の情報でない場合、または、前記第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されていない場合には、前記検索リクエストに含まれる第１の検索キーに少なくとも一部が一致する第１の情報を１つ以上選択し、
   選択した１つ以上の前記第１の情報に対応する前記第２の情報に基づいて、第２の検索キーを生成し、
   生成した前記第２の検索キーを第２の情報処理装置に送信する、
   各処理を実行させることを特徴とするデータ検索プログラム。
6. 第１の情報処理装置から受信したデータに含まれる第１の情報と前記第１の情報を暗号化した第２の情報とを対応付けて記憶する記憶部と、
   前記記憶部を参照して、前記第１の情報処理装置から受信した検索リクエストに含まれる第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されているか否かを判定する判定部と、
   前記第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されている場合には、該第１の情報が最新の情報であるか否かを判定し、該第１の情報が最新の情報である場合には、前記第１の検索キーと完全一致する前記第１の情報を選択し、該第１の情報が最新の情報でない場合、または、前記第１の検索キーと完全一致する前記第１の情報が前記記憶部に記憶されていない場合には、前記検索リクエストに含まれる第１の検索キーに少なくとも一部が一致する第１の情報を１つ以上選択し、選択した１つ以上の前記第１の情報に対応する前記第２の情報に基づいて、第２の検索キーを生成する生成部と、
   前記生成部によって生成された前記第２の検索キーを第２の情報処理装置に送信する送信部と、
   を有することを特徴とする中継装置。

Images