(57)【要約】ネットワークを介した情報取得から生じる可能性のある情報漏洩の防止のために、情報処理装置３１０は、取得するべき情報を指定する検索値を含むオリジナル・リクエストを取得するリクエスト取得部３１４と、過去に発行したリクエストに対して現在発行するべきリクエストにより取得するべき情報が統計的に特異的であるか否かを判断する特異性評価部３２４と、取得するべき情報が統計的に特異的ではないと判断されるまで、アクセス・ログのデータマイニング耐性を付与するためのダミー値を含むダミー・リクエストを生成する、拡散リクエスト生成部３１６と、拡散リクエストを検索要求としてネットワーク１４０、２２０を介してデータベースに宛てて発行する検索要求発行部３１８と、拡散リクエストにより取得された情報を検索要求に対するレスポンスから抽出する検索結果抽出部３２０とを含んでいる。
2011013490.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して情報を取得する情報処理装置であって、前記情報処理装置は、
データベースから取得するべき情報を指定する検索値を含むオリジナル・リクエストを取得するリクエスト取得部と、
前記情報処理装置が過去に発行したリクエストに対して現在発行するべきリクエストにより取得するべき前記情報が、前記検索値の履歴を登録するリクエスト・ログに関して特異的であるか否かを判断する特異性評価部と、
前記特異性評価部が前記検索値について特異的であると判断した場合、前記情報処理装置が発行する前記データベースに対する前記検索値に関連したアクセス・ログの特異性を希釈するように、前記取得するべき情報とは異なる情報を要求する検索値を与えるダミー値から生成したダミー・リクエストを含む拡散リクエストを生成する、拡散リクエスト生成部と、
前記拡散リクエストを検索要求として前記ネットワークを介して前記データベースに宛てて発行する検索要求発行部と、
前記拡散リクエストにより取得された情報を前記検索要求に対するレスポンスから抽出する検索結果抽出部と
を含む、情報処理装置。
【請求項２】
前記ダミー値は、ダミー生成情報格納部に格納され、前記検索値の前記リクエスト・ログにおける前記特異性を低下させることで、データマイニング耐性を付与する、請求項１に記載の情報処理装置。
【請求項３】
前記検索要求発行部は、前記取得するべき情報が連続的な属性を有する場合、前記ダミー・リクエストのみを含む前記拡散リクエストを前記検索要求として発行する、請求項２に記載の情報処理装置。
【請求項４】
前記検索要求発行部は、前記取得するべき情報が離散的な属性を有する場合、前記オリジナル・リクエストおよび前記ダミー・リクエストを含む前記拡散リクエストを前記検索要求として発行する、請求項２に記載の情報処理装置。
【請求項５】
前記特異性評価部は、前記オリジナル・リクエストが含む前記検索値について、前記リクエスト・ログを検索し、現在判断している検索値の増加レートから前記検索値の発生数が対応する前記検索値の発生数の平均値に対してしきい値以上増加することを予測して前記拡散リクエスト部に対する前記ダミー・リクエストの生成を開始させる、請求項４に記載の情報処理装置。
【請求項６】
前記オリジナル・リクエストは、異なる情報を取得するための複数の前記検索値を含み、前記特異性評価部は、複数の前記検索値ごとに前記特異性を判定し、前記検索値ごとに前記ダミー・リクエストを生成して、それぞれ情報検索するべき前記データベースに前記拡散リクエストを発行する、請求項５に記載の情報処理装置。
【請求項７】
前記情報処理装置は、前記データベースからのレスポンスを受領して前記オリジナル・リクエストが含む前記検索値にそれぞれ対応するレスポンスを表示する表示領域を生成し、前記レスポンスを表示させる、請求項６に記載の情報処理装置。
【請求項８】
前記情報処理装置は、Web2.0パラダイムで実装されるマッシュアップ・サーバである、請求項７に記載の情報処理装置。
【請求項９】
ネットワークを介して情報を取得する情報処理方法であって、前記情報処理方法は、情報処理装置が、
データベースから取得するべき情報を指定する検索値を含むオリジナル・リクエストを取得するステップと、
前記情報処理装置が過去に発行したリクエストに対して現在発行するべきリクエストにより取得するべき前記情報が、前記検索値の履歴を登録するリクエスト・ログに関して特異的であるか否かを判断するステップと、
前記特異的であるか否かを判断するステップにおいて前記検索値について特異的であると判断された場合、前記情報処理装置が発行する前記データベースに対する前記検索値に関連したアクセス・ログの特異性を希釈するように、前記取得するべき情報とは異なる情報を要求する検索値を与えるダミー値から生成したダミー・リクエストを含む拡散リクエストを生成するステップと、
前記拡散リクエストを検索要求として前記ネットワークを介して前記データベースに宛てて発行するステップと、
前記拡散リクエストにより取得された情報を前記検索要求に対するレスポンスから抽出するステップと
を実行する情報処理方法。
【請求項１０】
前記拡散リクエストを生成するステップは、前記検索値の前記リクエスト・ログにおける前記特異性を低下させるためのダミー値をダミー生成情報格納部から取得し、ダミー・リクエストにセットするステップを含む、請求項９に記載の情報処理方法。
【請求項１１】
前記拡散リクエストを発行するステップは、前記取得するべき情報が連続的な属性を有する場合、前記ダミー・リクエストのみを含む前記拡散リクエストを前記検索要求として発行するステップを含む、請求項１０に記載の情報処理方法。
【請求項１２】
前記拡散リクエストを発行するステップは、前記取得するべき情報が離散的な属性を有する場合、前記オリジナル・リクエストおよび前記ダミー・リクエストを含む前記拡散リクエストを前記検索要求として発行するステップを含む、請求項１１に記載の情報処理方法。
【請求項１３】
前記特異的であるか否かを判断するステップは、前記オリジナル・リクエストが含む前記検索値について、前記リクエスト・ログを検索し、現在判断している検索値の増加レートから前記検索値の発生数が対応する前記検索値の発生数の平均値に対してしきい値以上増加することを予測して前記ダミー・リクエストの生成を開始させるステップを含む、請求項１２に記載の情報処理方法。
【請求項１４】
前記オリジナル・リクエストは、異なる情報を取得するための複数の前記検索値を含み、前記特異的であるか否かを判断するステップは、複数の前記検索値ごとに前記特異性を判定するステップを含み、
前記拡散リクエストを生成するステップは、前記検索値ごとに前記ダミー・リクエストを生成するステップと、
前記拡散リクエストを発行するステップは、それぞれ情報検索するべき前記データベースに前記拡散リクエストを発行するステップを含む、請求項１３に記載の情報処理方法。
【請求項１５】
前記情報処理装置は、Web2.0パラダイムで実装されるマッシュアップ・サーバである、請求項１４に記載の情報処理方法。
【請求項１６】
情報処理装置がネットワークを介して情報を取得する情報処理方法を実行するための装置実行可能なプログラムであって、前記プログラムは、情報処理装置を、
データベースから取得するべき情報を指定する検索値を含むオリジナル・リクエストを取得するリクエスト取得部、
前記情報処理装置が過去に発行したリクエストに対して現在発行するべきリクエストにより取得するべき前記情報が、前記検索値の履歴を登録するリクエスト・ログに関して特異的であるか否かを判断する特異性評価部、
前記特異性評価部が前記検索値について特異的であると判断した場合、前記情報処理装置が発行する前記データベースに対する前記検索値に関連したアクセス・ログの特異性を希釈するように、前記取得するべき情報とは異なる情報を要求する検索値を与えるダミー値から生成したダミー・リクエストを含む拡散リクエストを生成する、拡散リクエスト生成部、
前記拡散リクエストを検索要求として前記ネットワークを介して前記データベースに宛てて発行する検索要求発行部、
前記拡散リクエストにより取得された情報を前記検索要求に対するレスポンスから抽出する検索結果抽出部
として機能させるためのプログラム。
【請求項１７】
前記ダミー値は、ダミー生成情報格納部に格納され、前記検索値の前記リクエスト・ログにおける前記特異性を低下させることで、データマイニング耐性を付与する、請求項１６に記載のプログラム。
【請求項１８】
前記特異性評価部は、前記オリジナル・リクエストが含む前記検索値について、前記リクエスト・ログを検索し、現在判断している検索値の増加レートから前記検索値の発生数が対応する前記検索値の発生数の平均値に対してしきい値以上増加することを予測して前記拡散リクエスト部に対する前記ダミー・リクエストの生成を開始させる、請求項１７に記載のプログラム。
【請求項１９】
ネットワークを介して情報を転送するウェブ・システムであって、前記ウェブ・システムは、
取得するべき情報を指定する検索値を含むオリジナル・リクエストを取得して、前記ネットワークに接続された少なくとも１のウェブ・サーバに対して前記取得するべき情報を検索するための検索要求を発行する情報処理装置と、
前記情報処理装置からの複数の検索値を含む前記検索要求を受領してデータベースを検索し、前記検索要求で指定される情報を前記情報処理装置にレスポンスとして返すウェブ・サーバと
を含み、
前記情報処理装置は、
前記データベースから取得するべき情報を指定する検索値を含むオリジナル・リクエストを取得するリクエスト取得部と、
前記情報処理装置が過去に発行したリクエストに対して現在発行するべきリクエストにより取得するべき前記情報が、前記検索値の履歴を登録するリクエスト・ログに関して特異的であるか否かを判断する特異性評価部と、
前記特異性評価部が前記検索値について特異的であると判断した場合、前記情報処理装置が発行する前記データベースに対する前記検索値に関連したアクセス・ログの特異性を希釈するように、前記取得するべき情報とは異なる情報を要求する検索値を与えるダミー値から生成したダミー・リクエストを含む拡散リクエストを生成する、拡散リクエスト生成部と、
前記拡散リクエストを検索要求として前記ネットワークを介して前記データベースに宛てて発行する検索要求発行と、
を含む、ウェブ・システム。
【請求項２０】
前記拡散リクエスト生成部は、前記取得するべき情報とは関連性がない前記ダミー値をダミー生成情報格納部から取得して追加して前記拡散リクエストを生成し、前記拡散リクエストは、前記取得するべき情報が連続的な場合、前記ダミー・リクエストのみを含み、前記取得するべき情報が離散的である場合、前記オリジナル・リクエストおよび前記ダミー・リクエストを含み、前記特異性評価部は、前記オリジナル・リクエストが含む前記検索値について、前記リクエスト・ログを検索し、現在判断している検索値の増加レートから前記検索値の発生数が対応する前記検索値の発生数の平均値に対してしきい値以上増加することを予測して前記拡散リクエスト部に対する前記ダミー・リクエストの生成を開始させると共に、前記ウェブ・システムは、Web2.0パラダイムとして構成され、前記情報処理装置は、マッシュアップ・サーバである、請求項１９に記載のウェブ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク技術に関し、より詳細には、ネットワークを介した情報取得から生じる可能性のある情報漏洩の防止技術に関する。
【背景技術】
【０００２】
近年、ネットワーク基盤およびコンピュータ技術の進歩により、パーソナル・コンピュータ、ワークステーション、またはサーバ・コンピュータは、ネットワークを介して相互接続され、情報の共有を行っている。情報の共有を行う場合、通常、パーソナル・コンピュータなどのクライアント・コンピュータ（以下、単にクライアントとして参照する。）は、情報を蓄積するウェブ・サーバに対して情報の要求を発行し、当該要求に応答して、ウェブ・サーバが要求に一致する情報をクライアントに送付することにより、クライアントは、要求した情報を取得する。【０００３】
クライアントからサーバに対して送付される要求には、数値データ・セットやキーワードなどの情報を指定する値が含まれ、サーバは、当該値を参照して、データベースなどに対して照会を発行することによって情報をデータベースから抽出する。すなわち、従来の情報検索方法は、クライアントが現在興味を有している情報をサーバに開示することを意味する。【０００４】
ウェブ・サーバが信頼出来る場合には従来の情報検索でも問題は比較的少ないということができる。しかしながら、ウェブ・サーバが信頼できる場合であっても、検索を行う個人または企業などの検索主体は、情報を取得するため検索主体が現在どのような情報に興味を持っているのかを、ウェブ・サーバに通知することが必要である。【０００５】
近年では、ブラウジング技術の進歩により、複数のウェブ・サーバが管理する情報を単一の情報処理装置に集約して情報へのアクセス性を高める、いわゆるマッシュアップ（Mashup)システムが、Web2.0などとして普及している。マッシュアップ・システムは、クライアントと、マッシュアップ・サーバと、複数の情報サーバとを含んで構成されている。【０００６】
マッシュアップ・サーバは、企業などの社内に設置されていてもよいし、また、マッシュアップ処理を専ら実行するため、ＩＳＰ(Internet Service Provider)がインターネット内に設置するウェブ・サーバとされていてもよい。また、情報サーバは、それぞれＩＳＰなどにより提供され、それぞれが管理するデータベースから、クライアントの要求に対応する情報を検索し、検索された情報を、マッシュアップ・サーバに送付している。マッシュアップ・サーバは、取得した情報を適切に配置し、ブラウザ・プログラムなどを介してクライアントに複数の情報サーバから取得した情報を表示させている。【０００７】
マッシュアップ・システムでは、クライアントが要求する情報に対応して複数の情報サーバが、クライアントの発行したリクエストを取得する。リクエストは、取得するべき情報を検索するための検索語や条件式を含む、例えば、ＳＱＬ(Structured Query Language)文として構成される。情報サーバは、受領したリクエストから検索条件を取得し、それぞれが管理するデータベースの検索を実行することで、リクエストに対応する情報を取得する。ここで問題となることは、ネットワークを介して接続された情報サーバは、いずれもが必ずしも信頼できるものと言うことはできないことにある。また、信頼性ある情報サーバであっても、情報サーバに送付されたリクエスト内容によって、情報サーバのログ解析中のデータマイニングにより、リクエストの傾向が分析され、クライアント側の検索目的が暗黙のうちに知られてしまうことになる。【０００８】
すなわち、ネットワーク技術の普及およびネットワーク上に蓄積される情報の高付加価値化が進むにつれて、情報検索プロトコルで発生する、緩やかな情報漏洩が問題とされるようになっていた。なお、本明細書において、用語「緩やかな情報漏洩」とは、ネットワーク上での集団としてのネットワーク・アクセスが、情報サーバによって統計的に分析されること、そしてその結果として集団の意思すなわち、検索意図が緩やかに漏洩することを意味する。【０００９】
これまで情報検索プロトコルを拡張する検討が行われており、例えば、特開平１１−２５９５１２号公報（特許文献１）では、検索条件や検索者の所在などと機密情報として保護するデータ検索システムが開示されている。特許文献１では、検索条件の一部または全部を機密情報としてデータ検索装置に隠蔽または遮蔽して検索を行い、検索結果をデータ検索装置が絞り込むことにより、データ検索が行われる。より詳細には、検索条件を遮蔽または不鮮明にする方法として、入力されたすべての検索条件から、予め登録された遮蔽するべき検索条件を削除するか、または入力された検索条件を類似語や上位概念へ置換したり、余分な検索条件を付加したり、検索条件を分割したりすることにより行われている。【００１０】
特許文献１に記載された情報検索プロトコルでは、データ処理装置に入力された検索条件に対し、データ検索装置側で、削除、上位概念化、検索語の付加などの処理が行われる。この結果、データ処理装置側では、検索条件を加工処理するための追加プログラムおよび類似語辞書などが必要で、検索処理を実行するため検索条件に対する前処理が必要とされる。また、特許文献１のデータ検索装置では、遮蔽された検索条件を使用して、検索条件よりも広い条件でヒットした情報をデータ検索装置が一旦蓄積し、本来の検索条件に一致する情報を再度検索するデータ編集部が必要となる。この結果、データ検索装置は、本来取得するべき情報よりも膨大な情報を取得し、処理することが必要とされ、データ検索装置自体が、副次的なデータベースを実質的に備えていなければならない。このため、特許文献１のデータ検索装置は、ハードウェア資源およびプログラム資源の浪費を伴うので、現在のようにネットワーク上に蓄積される情報量が膨大な場合、検索を効率化することはできない。【００１１】
また、特開２００２−３１２３７７号公報（特許文献２）では、入力された第１の検索条件を、より広範囲を検索する第２の検索条件に変更して検索用サーバに対して情報検索を実行して第１の検索結果を取得し、取得した第１の検索結果を第１の検索条件により再度検索し、第１の検索条件に対応する検索結果を生成させ、利用者のプライバシーといった情報の漏洩を防止する検索装置が開示されている。【００１２】
特許文献２に記載された検索装置も、検索条件を拡張することにより、拡張された検索結果を検索装置に取得させ、当該検索結果を再度検索して本来取得するべき検索結果を生成する。この結果、検索装置自体も副次的なデータベースとして機能することが必要となる。この結果、検索装置は、検索条件の拡張に対応して、そのための記憶空間を確保しなければならず、また検索装置自体についてもある程度の検索能力を含む必要があるなど、検索効率、ハードウェア資源およびソフトウェア資源の浪費という点で、情報漏洩を効率的に防止するものではない。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開平１１−２５９５１２号公報
【特許文献２】特開２００２−３１２３７７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
上述したように、従来技術は検索による情報漏洩を防止するために本来の検索条件を含む修正検索式を生成し、データベースに対して検索要求を発行して拡張検索結果を取得し、当該拡張検索結果を本来の検索条件を使用し、検索装置が再検索することによって本来の検索結果を再度生成するものである。【００１５】
しかしながら、近年のようにネットワークを介してアクセスすることができる情報が膨大となって来ると、拡張検索結果を、クライアントや、検索を実行するためのゲートウェイ・サーバに取得させることは、記憶空間の浪費や再検索処理、データ編集処理などのオーバーヘッドが無視できず、またソフトウェア的にも小規模データベース・システムレベルの実装が必要であり、情報検索システム自体の冗長実装が必要となるなど、大きなハードウェア資源およびソフトウェア資源の修正が必要であった。【００１６】
また、従来の情報漏洩を防止する方法では、本来の検索条件を拡張して上位概念化したり、範囲を広げるように拡張検索条件を生成するものであるが、結局の所、本来の検索条件は、拡張検索条件に含まれていなければならない。しかしながら、特許文献１および特許文献２により生成される拡張検索条件では、クライアント側が検索しようとする検索意図の漏洩を防止するものではなく、情報検索によって生じるクライアント側の検索意図の意図しない漏洩、すなわち緩やかな情報の漏洩を防止するものではない。【００１７】
本発明は、上記従来技術に鑑みて、ネットワークを介した情報取得から生じる可能性のある緩やかな情報漏洩を防止する、情報処理装置、情報処理方法、プログラムおよびウェブ・システムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明は、従来の情報検索では、緩やかな情報漏洩が発生していることに着目してなされたものであり、本発明では、過去のリクエスト・ログを統計解析して、情報を検索するためのリクエストが過去のリクエスト履歴から特異的な場合、ランダムに選択したダミー値を含む複数のダミー・リクエストを生成し、複数のダミー・リクエストを含む拡散リクエストを生成する。【００１９】
拡散リクエストは、検索主体が入力する検索対象が過去のリクエスト・ログから推定して特異的である場合に、検索処理を実行するウェブ・サーバへのアクセス・ログを、データマイニングなどにより特徴的であることが解析できないように蓄積させることで、検索主体の発行するリクエストのデータマイニング耐性を向上する。【００２０】
本発明では、検索対象は、地図データなど数値データ・セットで指定され、同質の情報から演算によって取得できる連続的な属性を有する対象の他、企業名、株価、製品名、性別、年齢、任意の文字列など離散的な属性を有する対象についても適用することができる。【００２１】
本発明によれば、ネットワークを介して情報を取得する情報処理装置であって、前記情報処理装置は、
データベースから取得するべき情報を指定する検索値を含むオリジナル・リクエストを取得するリクエスト取得部と、
前記情報処理装置が過去に発行したリクエストに対して現在発行するべきリクエストにより取得するべき前記情報が、前記検索値の履歴を登録するリクエスト・ログに関して特異的であるか否かを判断する特異性評価部と、
前記特異性評価部が前記検索値について特異的であると判断した場合、前記情報処理装置が発行する前記データベースに対する前記検索値に関連したアクセス・ログの特異性を希釈するように、前記取得するべき情報とは異なる情報を要求する検索値を与えるダミー値から生成したダミー・リクエストを含む拡散リクエストを生成する、拡散リクエスト生成部と、
前記拡散リクエストを検索要求として前記ネットワークを介して前記データベースに宛てて発行する検索要求発行部と、
前記拡散リクエストにより取得された情報を前記検索要求に対するレスポンスから抽出する検索結果抽出部と
を含む、情報処理装置が提供される。【００２２】
本発明の前記ダミー値は、ダミー生成情報格納部に格納され、前記検索値の前記リクエスト・ログにおける前記特異性を低下させることで、前記データマイニング耐性を付与することができる。本発明の前記検索要求発行部は、前記取得するべき情報が連続的な属性を有する場合、前記ダミー・リクエストのみを含む前記拡散リクエストを前記検索要求として発行することができる。本発明の前記検索要求発行部は、前記取得するべき情報が離散的な属性を有する場合、前記オリジナル・リクエストおよび前記ダミー・リクエストを含む前記拡散リクエストを前記検索要求として発行することができる。【００２３】
本発明の前記特異性評価部は、前記オリジナル・リクエストが含む前記検索値について、前記リクエスト・ログを検索し、現在判断している検索値の増加レートから前記検索値の発生数が対応する前記検索値の発生数の平均値に対してしきい値以上増加することを予測して前記拡散リクエスト部に対する前記ダミー・リクエストの生成を開始させることができる。【００２４】
本発明の前記オリジナル・リクエストは、異なる情報を取得するための複数の前記検索値を含み、前記特異性評価部は、複数の前記検索値ごとに前記特異性を判定し、前記検索値ごとに前記ダミー・リクエストを生成して、それぞれ情報検索するべき前記データベースに前記拡散リクエストを発行することができる。本発明の前記情報処理装置は、前記データベースからのレスポンスを受領して前記オリジナル・リクエストが含む前記検索値にそれぞれ対応するレスポンスを表示する表示領域を生成し、前記レスポンスを表示させることができる。【００２５】
本発明の前記情報処理装置は、Web2.0パラダイムで実装されるマッシュアップ・サーバとすることができる。【００２６】
本発明によれば、さらに上記情報処理装置が実行する情報処理方法、プログラムおよび上記情報処理装置を含むウェブ・システムが提供される。
【図面の簡単な説明】
【００２７】
【図１】本発明のウェブ・システム１００の実施形態を示した図。
【図２】本実施形態の第２の実施形態のウェブ・システム２００を示した図。
【図３】本実施形態の拡散リクエストを生成する情報処理システム３００の機能ブロックを示した図。
【図４】本実施形態の情報処理方法のフローチャート。
【図５】オリジナル・リクエストが含む特定の検索対象に対するリクエスト・ログ５００を示した図。
【図６】本実施形態で、特定のタイム・チャンク内での特定の検索対象を含むオリジナル・リクエストの増加レートから、現在リクエスト・ログ５００を蓄積しているタイム・チャンクでの検索対象の特性を判断する処理の実施形態を示した図。
【図７】図５および図６で示されるリクエスト・ログ５００に対し、本実施形態による拡散リクエストを発行した後に例えばウェブ・サーバ１５０が記録するアクセス・ログ７００の実施形態を示した図。
【図８】本実施形態で、特定の数値データに関連付けられた情報を検索する場合の、オリジナル・リクエストの取得からリクエストの発行までの処理の詳細フローチャート。
【図９】図８で説明した処理のうち、Ｓ８０３〜Ｓ８０５の処理の疑似コードを示した図。
【図１０】本実施形態の情報検索方法の第２の実施形態のフローチャート。
【図１１】図１０に示した処理を実行する疑似コードの実施形態。
【図１２】地図データの検索を行う場合の実施形態で生成される拡散リクエストの内容の拡散状態。
【図１３】本実施形態のウェブ・システムが表示する検索画面１３００の実施形態を示した図。
【図１４】本実施形態で、検索対象が離散的な属性を有している場合の実施形態を示した図。
【図１５】本実施形態の情報処理方法による拡散リクエスト発行の結果として生成されるアクセス・ログ１５００の実施形態を示した図。
【発明を実施するための形態】
【００２８】
以下、本発明を実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。図１は、本発明のウェブ・システム１００の実施形態を示す。ウェブ・システム１００は、クライアント１１０〜１１４と、マッシュアップ・サーバ１３０と、ウェブ・サーバ１５０〜１５４とを含んでいる。クライアント１１０〜１１４とマッシュアップ・サーバ１３０は、ＬＡＮ、ＷＡＮまたはインターネットなどのネットワーク１２０を介して相互接続されている。また、マッシュアップ・サーバ１３０は、ネットワーク１４０を介してウェブ・サーバ１５０〜１５４に相互接続されている。ネットワーク１４０は、特に限定されることはないが、インターネットなどの広域ネットワークを使用することができる。
【００２９】
マッシュアップ・サーバ１３０およびウェブ・サーバ１５０〜１５４は、概ね同様のハードウェア構成を採用することができ、PENTIUM（登録商標）、PENTIUM（登録商標）互換チップなど、CISCアーキテクチャのマイクロプロセッサ、または、POWERPC（登録商標）などのRISCアーキテクチャのマイクロプロセッサを、シングルコアまたはマルチコアの形態で実装することができる。また、各サーバは、WINDOWS（登録商標）200X、UNIX（登録商標）、LINUX（登録商標）などのオペレーティング・システムにより制御されていて、C、C++、JAVA（登録商標）、JAVABEANS（登録商標）、PERL、RUBYなどのプログラミング言語を使用して実装される、CGI、サーブレット、APACHE、IIS(Internet Information Server)などのサーバ・プログラムを実行し、クライアント１１０〜１１４から送付される検索要求、すなわちオリジナル・リクエストを処理する。
【００３０】
なお、マッシュアップ・サーバ１３０の特定の実装形態では、マッシュアップ・サーバ１３０を、企業などのゲートウェイ・サーバなどの一部機能として実装することができる。また、他の実施形態では、マッシュアップ・サーバ１３０は、Web2.0などのパラダイムに基づいたサービスを行う、ＩＳＰ(Internet Service Provider)に設置されていてもよい。さらに、ウェブ・サーバ１５０〜１５４は、それぞれ、データベース１６０〜１６４を管理していて、ネットワーク１４０を介したリクエストに対応して情報を提供することが可能とされている。説明する実施形態では、サーバ１５０は、会社情報サービス提供サーバとして実装され、サーバ１５２は、株価情報サービス提供サーバとして実装されている。ウェブ・サーバ１５４は、地図情報サービス提供サーバとして実装されていて、マッシュアップ・サーバ１３０からの個別的な要求を処理し、マッシュアップ・サーバ１３０に送付する。
【００３１】
クライアント１１０〜１１４は、それぞれ複数のアプリケーション・サービスを利用して情報を取得し、例えば、クライアント１１０は、自己が発行したオリジナル・リクエストに対応する情報をマッシュアップ・サーバ１３０を介して取得する。マッシュアップ・サーバ１３０は、複数のウェブ・サーバ１５０〜１５４からの情報をクライアント１１０に対応付けて格納し、複合情報としてクライアント１１０に提示する。
【００３２】
例えば、クライアント１１０が、特定の企業情報、株価情報、および地図情報を同時に取得することを希望する場合、マッシュアップ・サーバ１３０は、例えばクライアント１１０から送付されるオリジナル・リクエストに基づいて、各アプリケーション・サービスを提供するウェブ・サーバ１５０〜１５４に送付するための拡散リクエストを生成し、それぞれのウェブ・サーバ１５０〜１５４に宛てて拡散リクエストを送付し、拡散リクエストに対応して取得した情報からオリジナル・リクエストに対応する結果を取得し、複合情報として例えばウェブ・ページに合成してクライアント１１０に送付する。
【００３３】
本実施形態で参照する用語「拡散リクエスト」とは、クライアントが発行するオリジナル・リクエストが含む検索対象の種類に対応し、検索対象の属性ごとに生成されるウェブ・サーバ１５０〜１５４に宛てて送付されるリクエストを意味する。拡散リクエストは、ウェブ・サーバが、アクセス・ログを利用して統計的にデータマイニングすることで、オリジナル・リクエストの特性を解析することを困難とするように生成される、ダミー値を含む単一のリクエストまたはリクエスト・セットとして生成される。
【００３４】
クライアント１１０〜１１４は、パーソナル・コンピュータまたはワークステーションなどを使用して実装でき、また、そのマイクロプロセッサ（MPU）は、これまで知られたいかなるシングルコア・プロセッサまたはマルチコア・プロセッサを含んでいてもよい。また、クライアント１１０〜１１４は、WINDOWS（登録商標）、UNIX（登録商標）、LINUX（登録商標）、MAC  OSなど、これまで知られたいかなるオペレーティング・システムにより制御されてもよい。また、クライアント１１０〜１１４は、マッシュアップ・サーバ１３０や、ウェブ・サーバ１５０〜１５４にアクセスするため、Internet Explorer（登録商標）、Mozilla（登録商標）、Opera（登録商標）、FireFox（登録商標）などのブラウザ・ソフトウェアを実装することができる。
【００３５】
クライアント１１０〜１１４と、マッシュアップ・サーバ１３０およびマッシュアップ・サーバ１３０と、ウェブ・サーバ１５０〜１５４の間は、TCP／IPなどのトランザクション・プロトコルを使用するHTTP、HTTPSなどのファイル転送プロトコルでテータ送受信が行われる。また、マッシュアップ・サーバ１３０は、ウエブ・サーバ１５０〜１５４のデータベースにアクセスするために、JDBC(Java（登録商標）Database Connectivity)、ODBC(Open Database Connectivity)などを実装し、JDBCなどで定められるアプリケーションレベル・プロトコルで、ウェブ・サーバ１５０〜１５４に接続することができる。
【００３６】
図１に示す実施形態では、クライアント１１０が発行したリクエストは、マッシュアップ・サーバ１３０により一旦インターセプトされる。そして、マッシュアップ・サーバ１３０は、過去のリクエスト・ログを参照して統計処理する。統計処理の結果、マッシュアップ・サーバ１３０は、当該リクエストが含む取得するべき情報を指定するための検索値がリクエストの履歴から判断して特定の検索意図を反映してしまうと判断すると、拡散リクエストを生成し、拡散リクエストを、検索対象の情報を管理するウェブ・サーバ１５０〜１５４に発行する。各ウェブ・サーバ１５０〜１５４は、拡散リクエストを受領して、それぞれが管理するデータベース１６０〜１６４を検索し、リクエストに対応する情報を抽出し、マッシュアップ・サーバにレスポンスとして返す。マッシュアップ・サーバ１３０は、ウェブ・サーバ１５０〜１５４から受領したレスポンスから、当該レスポンスを同時にデスクトップ画面上に表示するための表示領域を有するウェブ・ページを構成し、それぞれのレスポンスを表示領域に割り当てて表示させることによってリクエストの発行元のクライアント１１０にブラウジングさせている。
【００３７】
図２は、本実施形態の第２の実施形態のウェブ・システム２００を示す。図２に示したウェブ・システム２００は、複数のクライアント２１０〜２１４が、ウェブ・ブラウザの、例えばプラグイン・プログラムやアドインプログラムなどの拡張アプリケーションとして実装されるマッシュアップ・アプリケーションを実装する。その代わりに、ウェブ・システム２００では、とりわけマッシュアップ・サーバ１３０といった専用サーバは利用されていない。図２に示す実施形態では、図１のマッシュアップ・サーバ１３０の機能は、クライアント２１０〜２１４の機能として実装され、オリジナル・リクエストから、各ウェブ・サーバ２３０〜２３４へと発行される拡散リクエストを生成し、ウェブ・サーバ２３０〜２３４へと拡散リクエストを発行し、各拡散リクエストに対応する検索結果をフィルタリングして複合情報としてブラウザ・プログラムに表示する。
【００３８】
一方、ウェブ・サーバ２３０〜２３４は、図１で示した実施形態と同様の構成とされていて、クライアント２１０などからの拡散リクエストに応答して、検索した情報をクライアント２１０などに返している。
【００３９】
本実施形態では、拡散リクエストを単一のリクエストとして生成する場合には、ダミー・リクエストの検索対象を指定する検索値を演算子ＯＲで結合して生成する。また拡散リクエストをリクエスト・セットとして生成する場合には、アクセス・ログを統計的に均一化させる、例えば検索対象の発生頻度をホワイトノイズ化させるようにダミー値を含む複数のダミー・リクエストを含むリクエスト・セットを生成する。いずれの場合でも、ダミー・リクエストは、リクエスト・ログを参照し、クライアント側の検索意図がウェブ・サーバでのデータマイニングにより抽出されてしまうことを防止するように、検索の対象ごとのタイムスケールに関して、平均化するようにリクエスト内容を選択する。なお、拡散リクエストは、検索するべき情報の属性に対応して、オリジナル・リクエストを含んでも良いし、オリジナル・リクエストをまったく含まなくともよい。
【００４０】
図３は、本実施形態の拡散リクエストを生成する情報処理システム３００の機能ブロックを示す。図３に示す情報処理システム３００は、図１の実施形態では、マッシュアップ・サーバ１３０に対応し、図２に示す実施形態では、クライアント２１０〜２１４に対応する。各実施形態では、各機能ブロックが、サーバ・アプリケーションとして実装されるか、またはクライアント・アプリケーションとして実装されるかの相違はあるものの、情報処理システム３００の各機能ブロックは、マイクロプロセッサが、情報処理装置を各機能手段として機能させるためのプログラムを実行空間であるＲＡＭに読み込んでプログラムを実行することにより実現されている。
【００４１】
図３に示すように、情報処理システム３００は、情報処理装置３１０と、ディスプレイ装置、キーボードおよびマウスなどを含む入出力装置３３０とを含んで構成されている。情報処理装置３１０は、ネットワーク・アダプタ３１２を介してネットワーク１４０、２２０へと拡散リクエストを送出し、拡散リクエストに対応するウェブ・サーバからのレスポンスを取得している。情報処理装置３１０は、さらに、リクエスト取得部３１４と、拡散リクエスト生成部３１６と、ダミー生成情報格納部３２２とを含んでいる。さらに、情報処理装置３１０は、情報処理装置３１０がウェブ・サーバに送ったリクエストを時系列的に格納するリクエスト・ログ３２８を含んでいる。
【００４２】
リクエスト取得部３１４は、情報処理装置３１０がマッシュアップ・サーバ１３０として実装される実施形態では、ネットワーク１２０を介してクライアント１１０〜１１４からのオリジナル・リクエストを取得する。また、情報処理装置３１０がマッシュアップ・サーバ１３０を介さずにウェブ・サーバ２３０〜２３４に対してアクセスする場合、入出力装置３３０を介してオペレータが入力する検索条件を含むオリジナル・リクエストを取得する。拡散リクエスト生成部３１６は、リクエスト・ログ格納部３２８を参照し、リクエスト取得部３１４が取得したオリジナル・リクエストの内容について、過去のリクエスト・ログにおける特異性を判断する。
【００４３】
拡散リクエスト生成部３１６は、当該判断結果に対応し、拡散リクエストを生成するために使用するダミー値をダミー生成情報格納部３２２から取得し、特異性評価部３２４により特定の検索対象が特異的ではないと判断されるまでダミー値を取得して拡散リクエストに含ませてダミー・リクエストを生成する。なお、オリジナル・リクエストの特異性の判断は、マッシュアップ・サーバ１３０またはクライアント２１０〜２１４が、管理するリクエスト発行に関連して特定のタイムスケールにおける検索対象の出現回数について設定されるしきい値などを使用して行うことができる。さらに、情報処理装置３１０の処理能力に応じてさらに高度な統計処理を行って決定することもできる。
【００４４】
本実施形態では、拡散リクエスト生成部３１６が生成する拡散リクエストは、ウェブ・サーバ１５０、１５２、１５４が処理するべきデータの属性により異なる処理によって作成される。拡散リクエストは、本実施形態では、各ウェブ・サーバ１５０〜１５４が管理するアクセス・ログの特定の対象に関連する時系列的なしきい値的挙動を、統計的に解析困難とするために生成される。検索する対象情報は、特に限定されるものではないが、本実施形態では、検索の対象とする情報を、連続的属性を有する情報と、離散的属性を有する情報とに分類する。
【００４５】
上述した連続的属性を有する情報とは、検索対象とする情報を特徴付けるための値、例えば位置座標、経度、緯度、標高、時間、期間などの値が、検索対象とするデータを除く同質の情報からの外挿、補間、移動などの予め設定された演算によって取得できる属性を有する情報である。より例示的には、連続的属性を有する情報としては、位置座標や緯度・経度データなどを挙げることができる。
【００４６】
一方、上述した離散的属性を有する情報とは、他の同質の情報とは独立してデータが変動する可能性を有し、検索対象のデータに直接アクセスしてデータを取得することが必要な属性を有する情報として定義する。より例示的には、離散的属性を有する情報としては、企業の株価情報、業績情報、Ｍ＆Ａ（Mergers and Acquisitions）情報、その他企業活動や集団の活動に関連する情報を挙げることができる。
【００４７】
ダミー生成情報格納部３２２は、データベースまたはテーブルとして実装でき、リクエストが要求する情報の属性に対応して、例えば、企業名、住所、緯度・経度情報などを対応付けて登録することができる。また、他の実施形態で、取得するべき情報が特定企業の株価、業績、製品、トピックスなど離散的である場合、情報の属性ごとにオリジナル・リクエストの特異性を低下させるため、カテゴリごとにダミー値として利用することができる情報を登録しておくことができる。
【００４８】
特異性評価部３２４は、オリジナル・リクエストを受領してリクエスト・ログの解析を行ない、受領したオリジナル・リクエストがリクエスト・ログのアクセス情報の平均値から逸脱する場合、ダミー生成情報を参照して、オリジナル・リクエストがリクエスト・ログから判断して特異的とはならないようになるまで、拡散リクエスト生成部３１６によるダミー値を含むダミー・リクエストを含む拡散リクエストの生成を実行させる。
【００４９】
情報処理装置３１０は、検索要求発行部３１８と、検索結果抽出部３２０とを含んでいる。検索要求発行部３１８は、オリジナル・リクエストおよびダミー値を含んで生成したダミー・リクエストをそれぞれＳＱＬクエリーにセットし、ネットワーク１４０、２２０を介してウェブ・サーバに発行する。なお、拡散リクエスト生成部３１６は、取得するべき情報が連続的かまたは離散的かの属性に応じて、検索要求発行部３１８に対して、オリジナル・リクエストで指定された値を渡すか否かを判断する。
【００５０】
より具体的には、例えば、オリジナル・リクエストが、数値データ・セット、ベクトルなどとして記述される連続的属性を有する情報を要求する場合、オリジナル・リクエストで指定された値を検索要求にセットせずとも、外挿、補間、または相対差分を利用することにより、オリジナル・リクエストで指定された情報を取得することが可能である。このため、ダミー・リクエストは、連続的属性を有する情報の場合、対象情報ではなく、対象情報に対してウェブ・サーバ１５４がクライアントからの別のリクエストにより到達することができるように生成される。
【００５１】
一方、情報が、株価情報や企業名、団体名、検索文字列などで指定される離散的属性を有する場合、目的とする情報を直接検索しなければ検索の目的を達成できない。このため拡散リクエスト生成部３１６は、オリジナル・リクエストに記述された値を使用して検索対象の情報と同質であって、検索対象とは異なる情報を要求するリクエストを生成し、これらをダミー・リクエストとして取得し、ダミー・リクエストをオリジナル・リクエストとともに検索要求発行部３１８に渡し、拡散リクエストを生成する。このため、検索結果抽出部３２０は、ダミー・リクエストのレスポンスとともにオリジナル・リクエストのレスポンスを受領する。
【００５２】
検索結果抽出部３２０は、ウェブ・サーバから送付される検索結果を必要に応じてフィルタ処理し、入出力インタフェース／ブラウザ３２６を介して入出力装置３３０のディスプレイ装置に検索結果を表示する。また、情報処理装置３１０のオペレータは、検索結果としてマップなどを取得した場合、マウスなどで表示領域や縮尺を調整し、さらに相対移動リクエストなどを追加的に発行し、オリジナル・リクエストとして取得するべき情報にアクセスできるように逐次的に検索結果を更新する。
【００５３】
図４は、本実施形態の情報処理方法のフローチャートである。図４の処理は、ステップＳ４００から開始し、ステップＳ４０１で、オリジナル・リクエストを取得する。なお、オリジナル・リクエストは、図１の実施形態または図２の実施形態に応じて情報処理装置３１０がネットワーク１２０または入出力装置３３０から取得する。例えば、オリジナル・リクエストが企業情報、株価情報、および地図情報の情報取得を検索するための検索対象を、｛Ｃｉ，Ｓｉ，Ｇｉ｝として複合情報を取得するために生成されたものとする。情報処理装置３１０は、オリジナル・リクエストが含む検索要求を分離し、ステップＳ４０２で、特異性評価部３２４を呼び出して、まずオリジナル・リクエストが含む検索要求それぞれについて、時間的経過に関連して拡散されているか否かの判断を実行する。特異性評価部３２４が実行する処理については、より詳細に後述する。
【００５４】
ウェブ・サーバに送るリクエストが、リクエスト・ログを使用した判断により内容的および時間的に拡散されていないと判断される場合（ｎｏ）、ステップＳ４０３で、ダミー生成情報を参照して、拡散リクエストを生成し、再度、処理をステップＳ４０２に戻してリクエストの内容が拡散しているか否かを判断する。
【００５５】
ステップＳ４０２の判断で、リクエストの内容がリクエスト・ログとの比較で拡散している、すなわち特異的ではないと判断された場合（ｙｅｓ）、ステップＳ４０４で、リクエストを送信する。
【００５６】
ステップＳ４０５では、ウェブ・サーバからのレスポンスを受領したか否かを判断し、レスポンスの受領が完了していない場合（ｎｏ）レスポンスの受領が完了するまで処理を反復する。一方、ステップＳ４０５でウェブ・サーバからのレスポンスの受領を完了した場合（ｙｅｓ）、ステップＳ４０６で、情報処理装置３１０は、レスポンスをオリジナル・リクエストに対応してマージして、ブラウザで表示させる。なお、ステップＳ４０６の処理では、受領するデータの属性に応じて、ブラウジングするべきデータをフィルタする処理を含むことができる。クライアントのディスプレイ装置上にブラウジングが完了した段階で、処理は、ステップＳ４０７で終了し、以後のオリジナル・リクエストの入力を待機する。
【００５７】
以下、本実施形態で、特異性評価部３２４が実行する処理の例示的な実施形態を説明する。図５には、例示的な目的で、オリジナル・リクエストが含む特定の検索対象に対するリクエスト・ログ５００を示す。図５で縦軸は、オリジナル・リクエストが含む同一の検索対象に対するｉ（ｉ＝０，．．．，ｐ：ｐは、非負の整数である。）番目のタイム・チャンク内での累積リクエスト数ＳＮｉであり、横軸は、時間経過を示す。なお、タイム・チャンクは、オリジナル・リクエストの特異性を希釈する目的で、例えば、分単位、時間単位、１日単位、週単位、月単位など、適宜設定することができる。また、リクエスト・ログ５００は、リクエスト発行の特定の単位ごとに生成して、蓄積することができ、リクエスト発行元の単位としては、クライアント単位、事業所単位、企業単位とすることができる。
【００５８】
また、オリジナル・リクエストが同一の検索対象を要求しているか否かについては、企業情報であれば、同一の企業名のテキスト一致、株価情報であれば企業名または銘柄コードなどのテキスト一致などを利用して判断することができる。また、地図情報などの数値データで指定される検索対象については、特定の緯度・経度を中心として設定された経度・緯度の数値範囲内で一致することによって判断することができる。なお、地図情報の検索の場合、市街地かまたは非市街地かによって設定された緯度・経度範囲を変更することができる。指定されたに関連して特定範囲内に共通するランドマークが存在するか否かを使用して検索対象の同一性を判断してもよい。
【００５９】
情報処理装置３１０は、リクエスト・ログ５００の記録開始から、特定の検索対象についてオリジナル・リクエストとして発行された検索対象を、適切な処理間隔で与えられるタイム・チャンク単位で、検索対象ごとに発生数Ｎとして登録する。そして、現在リクエスト・ログ５００を蓄積しているタイム・チャンクでは、注目している検索対象を含むオリジナル・リクエストの発生数を、オリジナル・リクエスト単位で検出する。
【００６０】
特異性評価部３２４は、現在蓄積中のタイム・チャンクが終了した段階で、注目している検索対象のリクエストあたりの増加速度を検査し、当該タイム・チャンクが、リクエスト・ログ５００において特異的となるか否かを予測して、現在判断しているタイム・チャンクＴＣｐでの検索対象の特性を判断する。図５に示されるように、リクエスト・ログの記録を開始した直後のタイム・チャンクでは、当該タイム・チャンクで発行されたどのオリジナル・リクエストでも特異的と判断され、拡散リクエストが生成される。
【００６１】
一方、リクエスト・ログ５００の記録の時間経過と共に検索要求の履歴が蓄積されるので、過去の履歴を含めて現在判断中の検索対象が特異的であるか否かを判断することが必要である。過去の履歴を考慮して特性を判断する場合、特定の検索対象について現在のタイム・チャンクＴＣｐまでのリクエストのタイム・チャンクＴＣｉにわたるリクエスト数の平均値Ｎａｖと、現在のタイム・チャンクＴＣｐについて取得されることが予測されるリクエスト数をＳＮｐとして、例えば、下記式（１）で与えられる特異性指標ＳＮｐが、平均値Ｎａｖから、確率誤差以上大きくなったことを使用して判断することができる。
【００６２】
【数１】
2011013490.tif 000003
【００６３】
上記式（１）中、σerrorは、Ｎａｖのタイム・チャンクにわたる検索対象についてのリクエスト数についての確率誤差であり、αは、確率誤差に対して乗じられる正の実数であり、好ましくは、α≧１である。また、Ｎａｖは、下記式（２）で与えられ、現在記録中のタイム・チャンクが終了すると、順次更新される。
【００６４】
【数２】
2011013490.tif 000004
【００６５】
上記式（１）では、タイム・チャンクを識別する値ｐは、リクエスト・ログの記録につれて大きくなるが、特異性評価処理を開始する最初のタイム・チャンクは、特異点を形成する。当該特異点に対応するためｐ＝０の場合については、常に検索値は特異的であるとして処理を開始する。また、現在のタイム・チャンクＴＣｐ以前にまったくリクエストがなされていない場合であって、現在のタイム・チャンクＴＣｐで始めてＳＮｐ個のリクエストが発行されることになる場合、にも常に特異的と判断されるが、ｐ＞０である限り、特異的な処理は行わず、上記式（１）にしたがって判定を行う。一方、過去に同一の検索対象がまったくないという可能性も少ない。このため、特定の検索対象への特定の検索意図を含まないリクエスト・ログは、タイム・チャンクにわたりＮａｖを中心としてホワイトノイズとして近似できるとすれば、上記式（１）、（２）に替えて、ＳＰを２項分布で与えられる確率密度関数および分散を使用して定義することができる。さらに、検索対象間に関連性が想定される場合には、リクエスト・ログ５００が、多次元正規分布となるものと仮定し、多次元正規分布および分散共分散行列などを使用して検索対象の相関的特異性を判断してもよい。
【００６６】
また、本実施形態の特異性評価部３２４は、図５中、最後のタイム・チャンクは、現在リクエスト・ログを記録中のタイム・チャンクであり、現在の時点で、特定の検索対象を指定する検索値は、ＳＮcurrentまで蓄積されている。この増加レートで、タイム・チャンク終了時まで増加すると、ＳＮpredictまで発生数が増加することを予測し、当該予測に基づいて上記式（１）を使用して、特異的であるとして判断する。本実施形態の予測判断の実施形態については、より詳細に後述する。
【００６７】
図６は、本実施形態で、特定のタイム・チャンク内での特定の検索対象を含むオリジナル・リクエストの増加レートから、現在リクエスト・ログ５００を蓄積しているタイム・チャンクでの検索対象の特性を判断する処理の実施形態を示す。図６では、縦軸にオリジナル・リクエストが含む検索対象のタイム・チャンクＴＣｍ（ｍ＝０，２，３，．．．，ｎ）での累積数を示し、横軸が、リクエスト・ログ６００の時間経過を示す。さらにリクエスト・ログ６００は、検索対象Ｃｉ、Ｓｉ、Ｎｉ、Ｏｉとしてそれぞれ個別的に検査されている。各タイム・チャンクでの累積数は、バーで示されており、黒でハッチングされたバーは既に記録が終了しているタイム・チャンクである。
【００６８】
図６中、特定の検索対象に対してリクエスト・ログ６００上で特異的として判断されるタイム・チャンクについては、バー上に黒三角を付して示している。黒三角でマークした検索対象は、過去に要求がなされておらず、黒三角で示したタイム・チャンクで初めて検出されたものである。また、白抜きのバーで示したタイム・チャンクは、現在累積中のタイム・チャンクである。
【００６９】
当該タイム・チャンクの特定の検索要求がタイム・チャンク終了時に特異的であることが判断されたとしても、既にオリジナル・リクエストは発行されているので、ウェブ・サーバ１５０などは、アクセス・ログを解析して、オリジナル・リクエストの発行元の検索意図を判断することが可能となる。
【００７０】
本実施形態では、オリジナル・リクエストをウェブ・サーバ１５０〜１５４に送付する前に特異性評価部３２４がオリジナル・リクエストをインターセプトし、個別の検索要求の内容を判断する。このことは、情報処理装置３１０が取得したオリジナル・リクエストが特定のタイム・チャンク内での検索対象の増加レートを判断することを可能とする。すなわち、特異性評価部３２４は、特定の検索対象を指定する検索値をタイム・チャンク内で積算し、オリジナル・リクエストの全数に対する増加レートを計算し、タイム・チャンクの終了時まで、直線補外、多項式補外、指数補外など適切な方法で補外し、補外した結果を、現在蓄積中のタイム・チャンク内で積分して、発生数を予測する。図６中最終タイム・チャンクで累積中の検索対象Ｏｉは、当該タイム・チャンクが終了した時点では特異的として判断されることを示す目的で白△を付して示している。当該予測に基づいた推定数が上記式（１）を満たすと判断される場合に、拡散リクエストの生成を、拡散リクエスト生成部３１６に指令し、特異性レベルの希釈処理を開始させている。
【００７１】
当該処理は、図６中、検索対象Ｏｉについて、示されており、現在処理中のタイム・チャンク内で、現在までに累積された発生数ＳＮcurrentは、特異的と判断されないものの、現在の増加レートでタイム・チャンクの終了時まで累積されるとすると、ＳＮpredictの値となることが予測され、ＳＮpredictは、特異的と判断されることになることを示す。この結果、現在蓄積中のタイム・チャンク内で特異性レベルを予測評価することになるので、タイム・チャンクのリクエスト・ログ記録中に当該タイム・チャンク内での特異性希釈処理を行うことが可能となり、緩やかな情報漏洩を未然に防止できる。
【００７２】
本実施形態の拡散リクエスト生成部３１６は、オリジナル・リクエストが含む検索対象の特異性を個別的に判断し、検索対象が特異的であると判断した場合、拡散リクエストを生成する。拡散リクエストは、検索対象とする情報が、リクエスト・ログ５００から見て特異的ではなくなるように、オリジナル・リクエストを修正することにより生成される。オリジナル・リクエストの修正は、例示的な実施形態では、下記のように行うことができる。
【００７３】
○地図情報などの数値データでリクエストが発行される場合、検索対象が同一であると判断される数値範囲を超えてランダムに数値データを修正したダミー値を含む単一または複数のダミー・リクエストを生成する。さらに好ましい実施形態では、緯度・経度に関連してフーリエ変換した場合に周波数スペクトルが均等になるように複数のダミー値を選択して、拡散リクエストにセットする。ただし、実際問題としては、周波数スペクトルがある程度均等になっていれば、データマイニングが困難になると考えられるので、必ずしも周波数スペクトルを完全に均等化する必要はない。
【００７４】
○企業情報や株価情報など直接該当する値を取得しなければならない属性の情報の場合、ダミー生成情報格納部３２２から、特異的であると判断された検索対象の企業や、株式銘柄などと同一の業種に区分される企業名、株式銘柄、銘柄コードをランダムに抽出し、区分内で、リクエストの発生数をホワイトノイズ化させるように適切な数のダミー情報を取得し、ダミー・リクエストを生成する。
【００７５】
○ダミー・リクエストは、オリジナル・リクエストと同一の検索値のセットとして構成することもできるが、情報処理装置３１０からは個別的にデータベースにアクセスすることになるため、ダミー・リクエストは、単一の検索値を含む検索要求として生成することができる。生成されたダミー・リクエストは、検索の真の目的となる検索値を含めてランダムに選択され、各別に対応するデータベース１６０〜１６４、２４０〜２４４などに送付される。
【００７６】
図７は、図５および図６で示されるリクエスト・ログ５００に対し、本実施形態による拡散リクエストを発行した後に例えばウェブ・サーバ１５０が記録するアクセス・ログ７００の実施形態を示す。情報処理装置３１０は、特定の検索対象ごとに会社情報提供サーバ１５０に送付されるリクエスト数を、特定のタイム・チャンクごとに検出し、積算しながら、オリジナル・リクエストが含む検索対象の統計的特異性を判定する。検索対象が特異的と判定された場合、情報処理装置３１０は、ダミー・リクエストを発行し、検索対象の特異性を希釈させ、ウェブ・サーバ１５０側で特定の発行元に対してアクセス・ログを解析しても図７のように、特定の検索値が突出した傾向を示すことが無いように、アクセスの特異性を希釈、すなわちホワイトノイズ化させているのが示される。
【００７７】
情報処理装置３１０は、真リクエストＴＲに対するダミー値とされるべき検索対象がオリジナル・リクエストに含まれる場合についても、ウェブ・サーバ１５０が特定の情報処理装置３１０からのアクセス・ログとして蓄積された場合にアクセス・ログをホワイトノイズに近づけるように、ダミー・リクエストが生成されている。なお、真リクエストとは、オリジナル・リクエストに含まれる検索値であって、検索者の特定の意図を反映したリクエストを意味する。情報処理装置３１０は、タイム・チャンクＴＣ１で真リクエストＴＲ１が特異的であると判断すると、特異性が希釈されるような検索対象をダミー生成情報格納部３２２から抽出し、ダミー・リクエストＤＲ(Dummy Request)にセットする。
【００７８】
図８は、本実施形態で、特定の数値データに関連付けられた情報を検索する場合の、オリジナル・リクエストの取得からリクエストの発行までの処理の詳細フローチャートである。例えば、図８が適用される情報は、位置座標などの数値データ・セットに特徴付けられる地図データや、数値データにより指定される情報が連続する情報であれば、適用することができる。図８の実施形態では、入力値は、例えば、経度・緯度などの値として入力することもできるし、企業名、地名などとして入力することができる。オリジナル・リクエストが企業名、地名、住所などとして入力される場合には、ダミー生成情報格納部３２２が格納する緯度経度データに置換して処理を実行することができる。
【００７９】
図８の処理は、図４のステップＳ４０２、Ｓ４０３の詳細を示したもので、ステップＳ４０１でオリジナル・リクエストを取得した後に開始され、ステップＳ８００では、
【００８０】
【数３】
2011013490.tif 000005
【００８１】
を満たすcx、cyを関数rnd()などを使用して生成する。上記式（３）中、（x、y）は、オリジナル・リクエストの指定する数値データであり、w、hは、数値データの範囲を指定する値である。なお、cx、cyは、乱数により生成される数値データであり、経度および緯度の値などに対応する。また、gx、gyは、過去の履歴を含めた座標の重心点(平均座標)である。
【００８２】
ステップＳ８０１では、タイムステール・インデックスtiを０に初期化する。なお、タイムスケール・インデックスtiは、分単位、時間単位、日単位、月単位などで規定され、どの程度過去まで遡ってオリジナル・リクエストが特異的ではないかを判断するタイムスケールを規定する。具体的には、ｔ0が、１分、ｔ1が、１時間、ｔ2が、１日のタイムスケールの間に発行されたリクエスト・ログを参照することを指定する。なお、t3、t4として、月単位または四半期単位でのリクエスト・ログを参照することもできる。
【００８３】
ステップＳ８０２では、tiがta配列の要素数を超えるか否かを判断し、ti＜taの配列の要素数よりも小さい場合（ｙｅｓ）、ステップＳ８０３で、ta[ti]時間分の過去の履歴の履歴座標群と、cx、cyから、新規な中心点gx、gyの座標を、座標群の値の平均値を使用して計算する。ステップＳ８０４では、（x、y）と、（gx、gy）の距離Ｌを計算する。検索値が座標群として与えられる場合、このＬおよびＬについてのリクエストの発生数が、オリジナル・リクエストの特異性の尺度を与え、それぞれ確率誤差などとして統計処理される。なお、本実施形態で使用する距離Ｌは、ユークリッド距離でも良いし、マンハッタン距離でも良いし、さらに特徴座標軸で規定される特徴値の間に定義される適切な位相的距離とすることもできる。
【００８４】
ステップＳ８０５では、距離Ｌがオリジナル・リクエストが特異的でないと想定される値である閾値以下であると判断された場合（ｙｅｓ）、ステップＳ８０６でタイムスケール・インデックスtiを１だけインクリメントした後、処理をステップＳ８０２に戻し、さらに他のタイムスケールでの特異性を判断する。一方、ステップＳ８０５で距離Ｌが閾値以下ではない場合（ｎｏ）、処理をステップＳ８００に戻し、追加のcx′、cy′を生成し、距離Ｌが、閾値以下となるまで、計算を反復する。
【００８５】
ステップＳ８０２で、設定しているタイムスケール・インデックスの計算が終了すると（ｎｏ）、設定するタイムスケールのどの期間についても特異的ではないのでステップＳ４０４に制御を渡し、検索クエリーに、｛（cx、cy）｝のセットとして数値データを設定し、拡散リクエストとして発行する。なお、当該実施形態では、情報は、数値的に連続性を有しているので、オリジナル・リクエストの値である（ｘ，ｙ）には拡散リクエスト内に含まれない。
【００８６】
図８の処理を実行することにより、オリジナル・リクエストとして指定された数値データをウェブ・サーバに送付することなく、オリジナル・リクエストとして取得した情報を情報処理装置３１０が取得することが可能となる。図８の処理は、情報が数値データで指定でき、位相的に連続する属性を有している場合、効果的に適用することができる。図８が適用される好適な実施形態としては、地図検索などを挙げることができる。さらに本実施形態の好ましい他の実施形態として、抽出された（cx、cy）のセット内に、（x、y）ではない特定のランドマークの位置座標に丸められるデータがある場合、当該ランドマークを（w、h）で与えられる領域に配置して検索された情報を表示することができる。
【００８７】
図９は、図８で説明した処理のうち、Ｓ８０３〜Ｓ８０５の処理の疑似コードを示す。疑似コードのブロック９００が、ステップＳ８０４およびＳ８０５の処理に対応し、疑似コードのブロック９１０が、図８のステップＳ８０３の処理に対応する。なおブロック９１０中、変数＝リスト．含まれる要素数（）は、tiで指定されるタイムスケール内に含まれるリクエスト・ログの要素の数である。
【００８８】
図１０は、本実施形態の情報検索方法の第２の実施形態のフローチャートであり、図４のステップＳ４０２〜Ｓ４０５に対応している。図１０の実施形態は、検索対象の情報が離散的な属性を有している場合に好適に適用することができる。図１０の処理は、ステップＳ４０１でオリジナル・リクエストを取得した後、ステップＳ１０００から開始する。なお、図１０で使用する記号は、下記表１の通りに定義される。
【００８９】
【表１】
2011013490.tif 000006
【００９０】
ステップＳ１０００では、配列ｋ[]からknに一致する属性のインデックス値を取得し、変数tiに設定する。ステップＳ１００１では、ダミー・リクエストとして抽出するべきアクセス候補数をｎｕｌｌに初期化し、インデックス値tiに対応するアクセス回数をカウント１に設定し、アクセス候補インデックス配列のインデックス＝０の値として、tiを設定する。その後、アクセス候補数を１インクリメントする。ステップＳ１００２では、d=|{Avg(ac[0],ac[n-1])-ac[ti]|を計算し、アクセス回数の平均値からの差分を計算する。
【００９１】
ステップＳ１００３では、｜ｄ｜が閾値以下であるか否かを判断し、閾値以下でない場合（ｎｏ）ステップＳ１００４で、ダミー・リクエストとして抽出するべき属性名を指定するインデックス値を与え、０≦dc≦N-1、dc≠tiであり、かつ既抽出のものではないという条件を満足する整数値dcをrnd()関数などを使用して生成する。なお、しきい値には、式（１）で説明したリクエスト・ログの確率誤差を使用することができるが、特異性を判断するために異なる基準を使用する場合、対応した適切なしきい値を設定することができる。
【００９２】
ステップＳ１００５では、アクセス回数配列ac[]の、インデックス値dcに対応する値を更新し、アクセス候補インデックス配列c[ci]の値にインデックス値dcを設定し、アクセス候補数のカウンタciを１だけインクリメントし、処理をステップＳ１００２に戻し、ステップＳ１００３の判断で肯定的な値が返されるまで、上述した処理を反復する。
【００９３】
一方、ステップＳ１００３で｜ｄ｜が閾値以下であると判断された場合（ｙｅｓ）、処理をステップＳ１００６に分岐させ、ステップＳ１００６で配列c[]のciこの要素をランダムにソートし、アクセス候補の抽出履歴を消去し、ステップＳ１００７でループインデックスｉを、０に初期化する。その後、ステップＳ１００８で、ループカウンタｉが、ci未満である場合（ｙｅｓ）、ステップＳ１００９でk[c[i]]を拡散リクエストを構成するリクエストの検索文字列に設定し、ウェブ・サーバへのアクセスを実行する。ステップＳ１０１０では、c[i]が、tiに等しいか否かを判断し、c[i]==tiの場合（ｙｅｓ）、ステップＳ１０１２でループカウンタを１だけインクリメントし、処理をステップＳ１００８に分岐させ、ステップＳ１００８で否定的結果が返されるまでダミーアクセスを実行させる。
【００９４】
また、ステップＳ１０１０で、c[i]==tiではない場合（ｎｏ）、ステップＳ１０１１でアクセス結果を保存し、ステップＳ１０１２に処理を分岐させて再度、ステップＳ１００８で否定的な値が返されるまで処理を反復する。ステップＳ１００８で否定的な結果が返された場合（ｎｏ）、制御をステップＳ４０６に渡し、図１０の処理を終了する。なお、図１０の処理では、アクセスしたい目的属性名については図１０の処理以外で行うものとして説明するが、ステップＳ１０１０の処理を省略して、アクセス実行した結果を全部保存することにより、図１０の処理内で、アクセスするべき全部のアクセス候補の処理を完了させてしまうこともできる。
【００９５】
さらに、ステップＳ１００３の判断においても、図８のステップＳ８０３で説明したように平均値を計算するタイムスケール・インデックスを使用して、アクセス履歴を拡散させるタイムスケールにわたり、アクセス履歴を拡散させることができる。
【００９６】
図１１は、図１０に示した処理を実行する疑似コードの実施形態である。ブロック１１００が図１０の処理ステップＳ１００３に対応し、ブロック１１１０が図１０のブロック１０２０の処理に対応する。なお、図１１の疑似コードでは、検索対象の属性名についてのアクセス実行は、ブロック１１１０が終了した後に実行される実施形態として記述されているが、図１０で説明したように、ブロック１１１０の処理ループ内で実行させることにより、さらにデータマイニング耐性を向上させることができる。
【００９７】
図１２は、地図データの検索を行う場合の実施形態で生成される拡散リクエストの内容の拡散状態を示す。図１２の縦軸および横軸は、表示領域のそれぞれ縦横幅ｗ、ｈに相当する。また、図１２（ａ）〜図１２（ｃ）は、それぞれ乱数発生の初期条件が異なる場合の拡散状態の変化を示している。図１２に示すように、拡散リクエストは、オリジナル・リクエストとして与えられる対象座標である（０，０）から充分に離れた位置座標を含み、拡散リクエストを構成するダミー・リクエストのポイントが充分ランダムに分布しているのが示され、リクエストのデータマイニング耐性を向上させることができることを示す。
【００９８】
図１３は、本実施形態のウェブ・システムが表示する検索画面１３００の実施形態を示す。図１３は、本実施形態による情報検索の実施形態を、リクエストの内容が、数値データとして設定され、連続性を有する情報に対して適用する場合の検索を実施形態として示す。図１３に示した実施形態では、ランドマーク１３１２が検索対象である。本実施形態のウェブ・システムでは、情報処理装置３１０のオペレータが、検索対象１３１２の位置座標や会社名などを入力する。当該位置座標や会社名が入力されると、情報処理装置３１０は、当該検索対象１３１２が、リクエスト・ログの履歴解析から特異的なアクセスであるか否かを、図８に示した処理を使用して判断する。
【００９９】
説明する実施形態では、情報処理装置３１０は、検索対象１３１２へのアクセスが特異的であると判断し（｜ｄ｜＞しきい値）、説明する実施形態ではアクセス候補として抽出した位置座標のうち、ランドマーク１３１４として登録されている位置座標に対応するリクエストのレスポンスをフィルタして地図イメージ１３１０を表示させる。なお、情報処理装置３１０が発行する拡散リクエストは、図８の処理にしたがって生成されたリクエスト・セットとして発行され、検索対象１３１２に関連するリクエストのデータマイニング耐性を向上させている。
【０１００】
地図イメージ１３１０を取得したユーザは、マウスなどを使用して地図データをスクロールし、例えば公園などのランドマーク１３１６に移動させ、検索対象１３１２を中心付近に移動させることで地図データ１３２０を表示させる。なお、地図データは、２次元平面上に連続して登録されているので、地図データのスクロールは、リクエストのように検索対象を特定する値を含まず、デフォルトの地図データに対して移動させるための相対値が送信されるので、検索対象１３１２を特定するデータは、ウェブ・サーバに送信されず、データマイニング耐性に影響を与えることはない。
【０１０１】
図１４は、本実施形態で、検索対象が離散的な属性を有している場合の実施形態を示す。図１４に示した実施形態では、マッシュアップ・サーバ１３０が複数のウェブ・サーバから取得した情報がマッシュアップされて、１つのデスクトップ画面１４００として提供されている。図１４に示す実施形態では、検索を行うオペレータは、Los Angelsにある特定企業「ＦＧＨ」の株価情報を取得する意図を持って検索を実行する。図１４に示す実施形態で、オペレータは、ＦＧＨ、株価、地図、トピックスなどの検索文字列を入力するが、マッシュアップ・サーバ１３０は、オペレータの入力するオリジナル・リクエストをそのまま送付しない。その代わりに、マッシュアップ・サーバ１３０は、ダミー生成情報格納部３２２に格納されている企業情報およびリクエスト・ログを参照して検索対象の企業「ＦＧＨ」以外に株価などの情報を取得する企業名をアクセス候補として取得し、拡散リクエストとしてウェブ・サーバに検索要求を発行する。
【０１０２】
上述した処理によって取得された検索結果は、図１４で説明する実施形態では、フィルタされずに全部取得され、表示フレーム１４１０にランダムに送付したリクエストに対応する順の検索結果リストとして表示される。表示フレーム１４１０に示すように、検索対象の企業「ＦＧＨ」についても検索結果が得られているが、他の企業情報の検索リクエストとともに検索結果が得られるので、リクエストにおける検索対象の企業名「ＦＧＨ」について、アクセス・ログにおける相対重みが低下されている。また本実施形態にしたがい、リクエスト・ログの統計的に処理された拡散リクエストがウェブ・サーバに送付されるので、リクエストを受け付けたウェブ・サーバにおけるアクセス・ログの解析のためのデータマイニングに対する耐久性を向上させることができる。
【０１０３】
なお、表示フレーム１４２０、表示フレーム１４３０、表示フレーム１４４０には、表示フレーム１４１０の検索結果リストで、現在オペレータが選択している検索結果に対応する、地図上の位置、株価変動、トピックスが表示されている。オペレータが表示フレーム１４１０の検索結果として他の検索結果を選択することによって、各表示フレーム１４２０、１４３０、１４４０内の表示内容は他の検索結果の選択に連携して変更され、複数のウェブ・サーバからの独立した情報を効率的に提示することが可能とされている。
【０１０４】
図１５は、本実施形態の情報処理方法によって、アクセス・ログからの緩やかな情報漏洩を防止するためのデータマイニング耐性向上の作用効果を説明するため、拡散リクエスト発行の結果として生成されるアクセス・ログ１５００を示す。図１５において、アクセス・ログ１５１０は、本実施形態の拡散リクエストを使用しない場合の特定のウェブ・サーバにおける実施形態であり、アクセス・ログ１５２０は、本実施形態の拡散リクエストを適用する場合の、特定のウェブ・サーバにおける実施形態を示す。なお、縦軸は、特定の期間内でのアクセス・ログを、検索文字列ごとに合計したアクセス数であるものとする。
【０１０５】
また、説明の便宜上、企業名としてＡ社、Ｂ社、Ｃ社、Ｄ社が拡散リクエストに追加される企業名であるものとして説明する。なお、検索対象の企業名は、Ｃ社であるものとする。
【０１０６】
アクセス・ログ１５１０では、オペレータが入力する検索対象の企業名がそのままウェブ・サーバに送信されてしまうので、検索対象の企業名であるＣ社を含むリクエストが突出してアクセス・ログとして記録される。このため、ウェブ・サーバ側では、アクセス・ログを時系列的にデータマイニングすることにより、特定のエンタープライズや個人の検索対象の変遷をトレースすることが可能となる。例えば、特定の日時以後にＣ社へのアクセス数が増加する場合、検索者は、当該特定の日時以後にＣ社に関心を持ったということが、ウェブ・サーバを運営するサイトに漏洩し、例えばＴＯＢ（TakeOver Bid）や合併といった重要な情報が、緩やかに漏洩する可能性を低下させる。
【０１０７】
アクセス・ログ１５２０は、本実施形態の拡散リクエストを使用する場合にウェブ・サーバ側で生成されるアクセス・ログを示す。本実施形態では、リクエスト・ログを統計処理して拡散リクエストを生成し、ウェブ・サーバに対してリクエスト・セットを発行する。この結果、特定の特異性を規定するしきい値｜ｄ｜の範囲に各社へのアクセス頻度がレベリングされ、アクセス・ログに対するデータマイニング耐性を向上させることが示される。図１５では、企業名を例示的に説明するが、本実施形態では、この他にも、地理／地域名、製品名、年齢、性別、集団名、ＳＮＳなどにおける特定文字列など種々の情報について適用でき、それぞれ市場調査、将来動向、企業アクティビティ、ネットワーク・アクティビティに関連する検索意図について、緩やかな情報漏洩を防止することができる。
【０１０８】
なお、本発明を発明の理解を容易にするために各機能手段および各機能手段が実行する処理として説明したが、本発明は、上述した特定の機能手段が特定の処理を実行する他にも、処理効率や実装上のプログラミングなどの効率を考慮して、いかなる機能手段に上述した処理を実行するための機能を割当てることができる。
【０１０９】
本発明の上記機能は、Ｃ＋＋、Ｊａｖａ（登録商標）、ＪａｖａＢｅａｎｓ（登録商標）、ＪａｖａＡｐｐｌｅｔ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｅｒｌ、Ｒｕｂｙなどのオブジェクト指向プログラミング言語、ＳＱＬなどの検索専用言語などで記述された装置実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布または伝送して頒布することができる。
【符号の説明】
【０１１０】
１００…ウェブ・システム、１１０〜１１４…クライアント、１２０…ネットワーク、１３０…マッシュアップ・サーバ、１４０…ネットワーク、１５０〜１５４…ウェブ・サーバ、１６０〜１６４…データベース、２００…ウェブ・システム、２１０〜２１４…クライアント、２２０…ネットワーク、２３０〜２３４…ウェブ・サーバ、２４０〜２４４…データベース、３００…情報処理システム、３１０…情報処理装置、３１２…ネットワーク・アダプタ、３１４…リクエスト取得部、３１６…拡散リクエスト生成部、３１８…検索要求発行部、３２０…検索結果抽出部、３２２…ダミー生成情報格納部、３２４…特異性評価部、３２６…入出力インタフェース／ブラウザ、３２８…リクエスト・ログ格納部、３３０…入出力装置
【図１】
2011013490.tif 000007
【図２】
2011013490.tif 000008
【図３】
2011013490.tif 000009
【図４】
2011013490.tif 000010
【図５】
2011013490.tif 000011
【図６】
2011013490.tif 000012
【図７】
2011013490.tif 000013
【図８】
2011013490.tif 000014
【図９】
2011013490.tif 000015
【図１０】
2011013490.tif 000016
【図１１】
2011013490.tif 000017
【図１２】
2011013490.tif 000018
【図１３】
2011013490.tif 000019
【図１４】
2011013490.tif 000020
【図１５】
2011013490.tif 000021
【国際調査報告】
2011013490.tif 000022
2011013490.tif 000023