(57)【要約】【課題】効率的な検索処理を実行することを課題とする。【解決手段】検索サーバは、第１のデータ提供元から提供されたデータと第２のデータ提供元から提供されたデータとを記憶したデータベースに対する検索処理を行う。検索サーバは、第１のデータ提供元からあるワードの検索を受け付けた場合に、第１のデータ提供元に対し第２のデータ提供元のデータの開示が禁止されているか否かを判定する。検索サーバは、禁止されていると判定した場合に第１のデータ提供元から受け付けた検索に応じて出力するデータから第２のデータ提供元のデータを除外する。【選択図】図２
2019128800.tif 000002
【特許請求の範囲】
【請求項１】
第１のデータ提供元から提供されたデータと第２のデータ提供元から提供されたデータとを記憶したデータベースに対する検索処理を行うデータ処理プログラムであって、
前記第１のデータ提供元からあるワードの検索を受け付けた場合に、前記第１のデータ提供元に対し前記第２のデータ提供元のデータの開示が禁止されているか否かを判定し、
禁止されていると判定した場合に前記第１のデータ提供元から受け付けた検索に応じて出力するデータから前記第２のデータ提供元のデータを除外する、
処理をコンピュータに実行させることを特徴とするデータ処理プログラム。
【請求項２】
前記第１のデータ提供元からあるワードの検索を受け付けた場合に、記憶部に記憶された前記第２のデータ提供元のデータにおける前記あるワードの重みづけの情報を取得し、
取得した前記あるワードの重みづけの情報に基づいて、除外する前記第２のデータ提供元のデータを特定する処理をコンピュータに実行させることを特徴とする請求項１に記載のデータ処理プログラム。
【請求項３】
前記第１のデータ提供元に対し前記第２のデータ提供元のデータの開示が禁止されているか否かを前記第２のデータ提供元から入力を受け付けた情報に基づき決定する処理をコンピュータに実行させることを特徴とする請求項１または２に記載のデータ処理プログラム。
【請求項４】
第１のデータ提供元から提供されたデータと第２のデータ提供元から提供されたデータとを記憶したデータベースに対する検索処理を行うデータ処理方法であって、
前記第１のデータ提供元からあるワードの検索を受け付けた場合に、前記第１のデータ提供元に対し前記第２のデータ提供元のデータの開示が禁止されているか否かを判定し、
禁止されていると判定した場合に前記第１のデータ提供元から受け付けた検索に応じて出力するデータから前記第２のデータ提供元のデータを除外する、
処理をコンピュータが実行することを特徴とするデータ処理方法。
【請求項５】
第１のデータ提供元から提供されたデータと第２のデータ提供元から提供されたデータとを記憶したデータベースに対する検索処理を行うデータ処理装置であって、
前記第１のデータ提供元からあるワードの検索を受け付けた場合に、前記第１のデータ提供元に対し前記第２のデータ提供元のデータの開示が禁止されているか否かを判定する判定部と、
禁止されていると判定した場合に前記第１のデータ提供元から受け付けた検索に応じて出力するデータから前記第２のデータ提供元のデータを除外する除外部と
を有することを特徴とするデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理プログラム、データ処理方法およびデータ処理装置に関する。
【背景技術】
【０００２】
近年、歩数や心拍数など個人的に収集されたセンサデータ、医療機関などが収集した医療データ、企業などが収集した管理データなどを含むビッグデータが利用されることから、ビッグデータから所望のデータを検索する技術が個人ユーザや企業などで利用されている。
【０００３】
例えば、検索キーワードに適合する情報のうち、現在ログインしているユーザと関係のある人物が関連付けられた情報について、人間関係を反映した重み付けを行って、情報検索等を実行する技術が知られている。また、検索語をクエリ条件、検索語に対応する動的閾値スコアをフィルタリング条件として、インデックス情報を検索する技術が知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第２００８／１０２７９９号
【特許文献２】特表２０１５−５２８６１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記技術では、データ提供元とデータ利用者の双方の要望に応える効率的な検索処理を実行することが難しい。例えば、ビッグデータを対象とした検索サービスにおいて、ビッグデータの利用者側にはより多くのデータを利用したいという要求がある一方で、ビッグデータの提供元である企業から、例えば同業他社にはデータを提供したくないなどの要求が存在する。
【０００６】
ところが、上記技術では、１つのビッグデータに対して１つの検索用インデックスを用いて検索サービスを提供するので、検索ユーザへのデータ提供を管理することができず、データ提供元の上記要求に応えることができない。なお、検索ユーザ毎に検索対象のビッグデータを用意することも考えられるが、膨大なリソースが必要であり現実的ではない。また、検索ユーザ毎に検索用インデックスを用意することも考えられるが、作業効率が悪く、管理も煩雑になるので、現実的ではない。
【０００７】
一つの側面では、効率的な検索処理を実行することができるデータ処理プログラム、データ処理方法およびデータ処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
第１の案では、データ処理プログラムは、第１のデータ提供元から提供されたデータと第２のデータ提供元から提供されたデータとを記憶したデータベースに対する検索処理をコンピュータに実行させる。データ処理プログラムは、前記第１のデータ提供元からあるワードの検索を受け付けた場合に、前記第１のデータ提供元に対し前記第２のデータ提供元のデータの開示が禁止されているか否かを判定する処理をコンピュータに実行させる。データ処理プログラムは、禁止されていると判定した場合に前記第１のデータ提供元から受け付けた検索に応じて出力するデータから前記第２のデータ提供元のデータを除外する処理をコンピュータに実行させる。
【発明の効果】
【０００９】
一実施形態によれば、効率的な検索処理を実行することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１にかかるシステムの全体構成例を示す図である。
【図２】図２は、実施例１にかかるシステムの機能構成を示す機能ブロック図である。
【図３】図３は、検索ツールＤＢに記憶される情報の例を示す図である。
【図４】図４は、契約情報ＤＢに記憶される情報の例を示す図である。
【図５】図５は、重み情報ＤＢに記憶される情報の例を示す図である。
【図６】図６は、検索用インデックスＤＢに記憶される情報の例を示す図である。
【図７】図７は、検索キーワードの重みの算出例を説明する図である。
【図８】図８は、検索処理を説明する図である。
【図９】図９は、検索用インデックスの生成処理の流れを示すフローチャートである。
【図１０】図１０は、検索処理の流れを示すフローチャートである。
【図１１】図１１は、ビジネスモデルの適用例１を説明する図である。
【図１２】図１２は、ビジネスモデルの適用例２を説明する図である。
【図１３】図１３は、ハードウェア構成例を説明する図である。
【発明を実施するための形態】
【００１１】
以下に、本願の開示するデータ処理プログラム、データ処理方法およびデータ処理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。
【実施例１】
【００１２】
［全体構成］
図１は、実施例１にかかるシステムの全体構成例を示す図である。図１に示すように、このシステムは、ライフログバンク１、データの提供先２、検索サーバ５０を有するクラウドシステムを利用した情報検索システムである。このシステムは、データの保有者とデータの活用者とを仲介し、蓄積して管理した各種データについて、売買等による取引を実現するシステムである。なお、ライフログバンク１、データの提供先２、検索サーバ５０は、有線や無線を問わず、インターネットなどのネットワークを介して接続される。
【００１３】
ライフログバンク１は、個人や企業からの預託により、個人や企業に代わり、文書や画像や動画などのデータを蓄積、管理、活用し、提供元に便益を還元する事業者のサーバ装置の一例である。例えば、ライフログバンク１は、企業や個人がＰＤＳ（Personal  Data  Store）で管理するデータを取得して保存し、第三者へ提供する。例えば、ライフログバンク１は、病院の医療データや大学の学生データを含むビッグデータ、電気・ガス・水道・小売・流通・旅行などの各業界の各企業が管理するビッグデータ、小規模店舗などの販売データであるスモールデータ、個人で収集された歩数・心拍・移動履歴などのセンサデータであるスモールデータを管理して、第三者へ提供する。なお、本実施例では、ライフログバンク１が管理する各データをまとめてビッグデータと記載する場合がある。
【００１４】
検索サーバ５０は、ライフログバンク１が管理するビッグデータをデータの提供先２へ提供するデータ処理装置の一例である。検索サーバ５０は、データの提供先２に対して、検索エンジンやＢＩ（Business  Intelligence）ツールを提供し、ビッグデータを横断的に検索し、それらを分析するツールのクラウドサービスを提供する。また、検索サーバ５０は、キーワードや自然言語などの検索式や画像を提供し、ビッグデータの横断検索および分析の代行サービスを提供する。ここで、データの提供先２は、例えば個人のユーザ、医療機関、各種企業などであり、ライフログバンク１にアクセスできる権利を有する登録ユーザである。また、データの提供先２は、ライフログバンク１へデータを登録してデータ活用を依頼した提供元の登録ユーザやライフログバンク１へデータを登録していない登録ユーザなどを含む。
【００１５】
このようなシステムにおいて、検索サーバ５０は、第１のデータ提供元から提供されたデータと第２のデータ提供元から提供されたデータとを含む複数のユーザのデータを記憶したライフログバンク１のデータベースに対する検索処理を行う。このとき、検索サーバ５０は、第１のデータ提供元からあるワードの検索を受け付けた場合に、第１のデータ提供元ユーザに対し、第２のデータ提供元のデータの開示が禁止されているか否かを判定する。そして、検索サーバ５０は、禁止されていると判定した場合、第１のデータ提供元から受け付けた検索に応じて出力するデータから第２のデータ提供元のデータを除外する。
【００１６】
例えば、検索サーバ５０は、検索ユーザから検索キーワードを受け付けて、当該検索キーワードで検索されるデータを、検索ユーザに提供する場合に、当該検索ユーザと排他関係にあるデータ提供元のデータを、検索されたデータから除外して検索ユーザに提供する。また、検索サーバ５０は、データ提供元が提供先から除外している業種や企業等に該当する検索ユーザに対して、検索されたデータから当該データ提供元のデータを除外して、検索ユーザに提供する。
【００１７】
このように、検索サーバ５０は、同業他社にはデータを提供したくないなどのビッグデータの提供者側の要求を満たしつつ、より多くのデータを利用したいというビッグデータの利用者側の要求を満たした、効率的な検索処理を実行することができる。
【００１８】
［機能構成］
図２は、実施例１にかかるシステムの機能構成を示す機能ブロック図である。ここでは、データ提供先をユーザ端末１０として説明する。なお、ライフログバンク１は、一般的なデータベースサーバなどと同様の構成を有するので、ここでは詳細な説明は省略する。また、実施例１では、ライフログバンク１と検索サーバ５０とが別々の筐体で実現される例を説明するが、これに限定されるものではなく、同じ筐体で実現することもできる。
【００１９】
（ユーザ端末１０の構成）
図２に示すように、ユーザ端末１０は、通信部１１、記憶部１２、制御部１３を有する。通信部１１は、他の装置との間の通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部１１は、検索サーバ５０との間のＷｅｂ通信を確立し、Ｗｅｂページ等による情報の送受信を実行する。
【００２０】
記憶部１２は、データやプログラムを記憶する記憶装置の一例であり、例えばメモリやプロセッサなどである。例えば、記憶部１２は、検索サーバ５０から提供される、検索式やＢＩツールに関する情報を記憶することもできる。
【００２１】
制御部１３は、ユーザ端末１０全体の処理を司る処理部であり、例えばプロセッサなどである。この制御部１３は、検索入力部１４と応答受信部１５を有する。なお、検索入力部１４と応答受信部１５は、例えばプロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。
【００２２】
検索入力部１４は、検索サーバ５０に対して、ライフログバンク１が管理するビッグデータへのインデックス検索を実行する処理部である。具体的には、検索入力部１４は、検索サーバ５０が提供する検索システムのＷｅｂページにアクセスして、ログインＩＤやパスワードなどの入力を受け付けてログイン処理を実行する。ログインが許可されると、検索入力部１４は、検索システムが提供する検索ツールにアクセスして、検索式などをユーザ端末１０に表示する。その後、検索入力部１４は、検索サーバ５０が提供する検索キーワードや検索式などの入力をユーザから受け付けると、受け付けた検索キーワードなどを検索クエリとして、検索サーバ５０に送信する。
【００２３】
応答受信部１５は、検索入力部１４が発行した検索クエリに対応する応答を、検索サーバ５０から受信する処理部である。例えば、応答受信部１５は、検索結果として、文書、画像、動画などのデータやインデックスなどを受信する。また、応答受信部１５は、検索結果をディスプレイ等に表示させることもできる。
【００２４】
（検索サーバ５０の構成）
図２に示すように、検索サーバ５０は、通信部５１、記憶部５２、制御部６０を有する。通信部５１は、他の装置との間の通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部５１は、ユーザ端末１０との間のＷｅｂ通信を確立し、Ｗｅｂページ等による情報の送受信を実行する。また、通信部５１は、ライフログバンク１との間でデータの送受信を行う。
【００２５】
記憶部５２は、データやプログラムを記憶する記憶装置の一例であり、例えばメモリやプロセッサなどである。記憶部５２は、検索ツールＤＢ５３、契約情報ＤＢ５４、重み情報ＤＢ５５、検索用インデックスＤＢ５６を記憶する。なお、記憶部５２は、登録ユーザを識別するためのログインＩＤとパスワードとの対応付けなどを記憶することもできる。
【００２６】
検索ツールＤＢ５３は、検索サーバ５０が提供する検索システムにログインしたユーザに対して提供する検索ツールに関する情報を記憶するデータベースである。具体的には、検索ツールＤＢ５３は、ライフログバンク１が記憶するビッグデータから所望のデータを検索するための検索式、検索キーワード、画像、動画などを記憶する。
【００２７】
図３は、検索ツールＤＢ５３に記憶される情報の例を示す図である。図３に示すように、検索ツールＤＢ５３は、「検索式、画像と当該画像に対応付けられる画像のタグ、動画と当該動画に対応付けられる動画のタグ」を記憶する。
【００２８】
ここで記憶される「検索式」は、ビッグデータの検索用として登録ユーザに提供する、ビッグデータからデータを検索する際の検索キーワードである。「画像」は、ビッグデータの検索用として登録ユーザに提供する画像である。この画像が検索キーワードとして選択された場合、当該画像に対応付けられる「画像のタグ」が検索キーワードに指定される。「動画」は、ビッグデータの検索用として登録ユーザに提供する動画である。この動画が検索キーワードとして選択された場合、当該動画に対応付けられる「動画のタグ」が検索キーワードに指定される。
【００２９】
例えば、ハートマークのついたリンゴの画像が検索対象として選択された場合、「リンゴ、ハート」が検索キーワードとして選択される。また、イチゴタルトの作り方の動画が検索対象として選択された場合、「イチゴ、タルト、作り方」が検索キーワードとして選択される。なお、ここに記憶される情報は、管理者等によって予め設定される情報であり、任意に変更することができる。
【００３０】
契約情報ＤＢ５４は、ライフログバンク１にアクセス可能なユーザに関する情報を記憶するデータベースである。具体的には、契約情報ＤＢ５４は、登録ユーザの情報、登録ユーザと排他関係にある企業などの情報を記憶する。図４は、契約情報ＤＢ５４に記憶される情報の例を示す図である。図４に示すように、契約情報ＤＢ５４は、「社名、業種、ブラックリスト、ホワイトリスト、ＢＤ内の場所」などを記憶する。
【００３１】
ここで記憶される「社名」は、登録ユーザを特定する名称であり、「業種」は、登録ユーザの業種である。「ブラックリスト」は、登録ユーザがライフログバンク１へ登録した自分のデータの提供先から除外する企業等のリストである。「ホワイトリスト」は、登録ユーザがライフログバンク１へ登録した自分のデータの提供先として許可する企業等のリストである。「ＢＤ内の場所」は、ライフログバンク１上で、社名に該当する企業のデータが登録される位置（場所）である。なお、当該登録ユーザが登録したデータの識別子などを対応付けて記憶させることもできる。
【００３２】
図４の例は、Ｄ社に関する契約情報を示す。図４の例では、「Ｄ社」は、業種「流通」に属し、同業種に対してはデータの提供先を許可せず、同業種以外の企業に対してはデータの提供先を許可することを示す。また、「Ｄ社」は、Ｄ社と業務提携している、業種「流通」の「Ｘ社」に対してはデータの提供先を許可する。また、Ｄ社のデータは、ライフログバンク１の記憶部の「.../yyy/」に記憶されることを示す。
【００３３】
重み情報ＤＢ５５は、データ提供元の各社について、キーワードの重みを記憶するデータベースである。図５は、重み情報ＤＢ５５に記憶される情報の例を示す図である。図５に示すように、重み情報ＤＢ５５は、データ提供元の各社について「ＫＷ、重み」を記憶する。「ＫＷ」は、データに含まれるキーワードを示し、「重み」は、データに含まれるＫＷの重みを示す。図５の例では、「Ａ社」のデータにおける「ＫＷ＝イチゴ」の重みが「０．３００」であり、「Ｄ社」のデータにおける「ＫＷ＝イチゴ」の重みが「０．４００」であることを示す。なお、重み情報ＤＢ５５は、各キーワードに対応付けて、当該キーワードを含む文書の文書ＩＤを記憶することもできる。
【００３４】
検索用インデックスＤＢ５６は、ライフログバンク１のビッグデータに対する検索用のインデックスを記憶するデータベースである。図６は、検索用インデックスＤＢ５６に記憶される情報の例を示す図である。図６に示すように、検索用インデックスＤＢ５６は、「単語、重み、場所、文書ＩＤ」を対応付けて記憶する。
【００３５】
ここで記憶される「単語」は、検索キーワードを示し、「重み」は、各単語について算出された重みを示す。「場所」は、各単語を含む文書（データ）が格納される先を示し、「文書ＩＤ」は、各単語を含む文書を識別する識別子である。図６の例では、重みが「０．７８９」である単語「イチゴ」を含む文書は、文書ＩＤが「１３、２５、３６、４７」の各文書であり、ライフログバンク１の「.../xxx/」に記憶されることを示す。また、重みが「０．４００」である単語「イチゴ」を含む文書は、文書ＩＤが「１、３、４」の各文書であり、ライフログバンク１の「.../yyy/」に記憶されることを示す。
【００３６】
制御部６０は、検索サーバ５０全体の処理を司る処理部であり、例えばプロセッサなどである。この制御部６０は、インデックス生成部７０とインデックス検索部８０を有する。なお、インデックス生成部７０とインデックス検索部８０は、例えばプロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。
【００３７】
インデックス生成部７０は、算出部７１と生成部７２を有し、検索用インデックスを生成する処理部である。具体的には、インデックス生成部７０は、データ提供元ごとに、検索キーワードの重みを算出して重み情報ＤＢ５５に格納する。そして、インデックス生成部７０は、データ提供元ごとの検索キーワードの重みをまとめた検索用インデックスを生成して、検索用インデックスＤＢ５６に格納する。ここで、検索キーワードとなる単語は、検索ツールで設定されている各単語である。
【００３８】
算出部７１は、データ提供元ごとに、検索キーワードの重みを算出する処理部である。具体的には、算出部７１は、データが異なれば、同じキーワード（ＫＷ）でもその重みは同じではなく、バラツキが生じることを利用し、提供者のデータの検索用インデックスの作成時に、データのＴＦ（Term  Frequency、索引語頻度）を用いた索引語の重み付けを計算する。
【００３９】
図７は、検索キーワードの重みの算出例を説明する図である。図７の（ａ）は、流通「Ｄ社」の検索キーワードの重みの算出例であり、図７の（ｂ）は、旅行「Ｅ社」の検索キーワードの重みの算出例である。
【００４０】
図７の（ａ）に示すように、算出部７１は、文書ＩＤ（ＸＸ１）と文書ＩＤ（ＸＸ２）と文書ＩＤ（ＸＸ３）の各データから、検索キーワードと出現回数を抽出する。例えば、算出部７１は、文書ＩＤ（ＸＸ１）から検索キーワード「ジュース、リンゴ、イチゴ」を抽出し、文書ＩＤ（ＸＸ２）から検索キーワード「イチゴ、イチゴ、甘い」を抽出し、文書ＩＤ（ＸＸ３）から検索キーワード「今年、イチゴ、リンゴ、豊作」を抽出する。
【００４１】
続いて、算出部７１は、各検索キーワードの登場回数と合計回数を計数する。例えば、算出部７１は、「ジュース、１」、「リンゴ、２」、「イチゴ、４」、「甘い、１」、「今年、１」、「豊作、１」を計数する。また、算出部７１は、各登場回数を加算した「１０」を合計回数と算出する。
【００４２】
その後、算出部７１は、各検索キーワードについて、合計回数に対する出現の割合を算出し、この割合を重みとする。例えば、算出部７１は、「（ジュース）の重み＝１／１０＝０．１００」、「（リンゴ）の重み＝２／１０＝０．２００」、「（イチゴ）の重み＝４／１０＝０．４００」、「（甘い）の重み＝１／１０＝０．１００」、「（今年）の重み＝１／１０＝０．１００」、「（豊作）の重み＝１／１０＝０．１００」を算出する。そして、算出部７１は、算出結果を重み情報ＤＢ５５に格納する。
【００４３】
別例を説明すると、図７の（ｂ）に示すように、算出部７１は、文書ＩＤ（ＹＹ１）と文書ＩＤ（ＹＹ２）と文書ＩＤ（ＹＹ３）の各データから、検索キーワードと出現回数を抽出する。例えば、算出部７１は、文書ＩＤ（ＹＹ１）から検索キーワード「栃木、イチゴ、産地」を抽出し、文書ＩＤ（ＹＹ２）から検索キーワード「アップル、日本語、リンゴ」を抽出し、文書ＩＤ（ＹＹ３）から検索キーワード「バンドＢ、ドラマー、リンゴ」を抽出する。
【００４４】
続いて、算出部７１は、各検索キーワードの登場回数と合計回数を計数する。例えば、算出部７１は、「栃木、１」、「イチゴ、１」、「産地、１」、「アップル、１」、「日本語、１」、「リンゴ、２」、「バンドＢ、１」、「ドラマー、１」を計数する。また、算出部７１は、各登場回数を加算した「９」を合計回数と算出する。
【００４５】
その後、算出部７１は、各検索キーワードについて、合計回数に対する出現の割合を算出し、この割合を重みとする。例えば、算出部７１は、「（栃木）の重み＝１／９≒０．１１１」、「（イチゴ）の重み＝１／９≒０．１１１」、「（産地）の重み＝１／９≒０．１１１」、「（アップル）の重み＝１／９≒０．１１１」、「（日本語）の重み＝１／９≒０．１１１」、「（リンゴ）の重み＝２／９≒０．２２２」、「（バンドＢ）の重み＝１／９≒０．１１１」、「（ドラマー）の重み＝１／９≒０．１１１」を算出する。そして、算出部７１は、算出結果を重み情報ＤＢ５５に格納する。
【００４６】
図２に戻り、生成部７２は、データ提供元ごとの検索キーワードの重みをまとめた検索用インデックスを生成する処理部である。具体的には、生成部７２は、算出部７１によって算出された、各提供者のデータの検索用インデックスと重みを集めて、ビッグデータの検索用インデックスを生成する。
【００４７】
例えば、生成部７２は、重み情報ＤＢ５５を参照し、単語「イチゴ」について、「Ａ社、イチゴ、０．３００」や「Ｄ社、イチゴ、０．４００」などを抽出するとともに、各社の単語「イチゴ」が含まれる文書の文書ＩＤを抽出する。続いて、生成部７２は、契約情報ＤＢ５４を参照して、各社（Ａ社、Ｄ社）のデータ格納位置を特定する。その後、生成部７２は、「単語（イチゴ）、重み、場所（格納位置）、文書ＩＤ」を対応付けて、検索用インデックスＤＢ５６に格納する。生成部７２は、各検索キーワード（単語）について、上記処理を実行する。
【００４８】
インデックス検索部８０は、受付部８１、判定部８２、検索応答部８３を有し、データ検索を実行する処理部である。具体的には、インデックス検索部８０は、登録ユーザから検索キーワードを受け付けて、検索クエリをライフログバンク１に発行してビッグデータ内で該当するデータを検索し、検索結果を登録ユーザに応答する。
【００４９】
受付部８１は、登録ユーザに対して検索ツールを提供し、検索キーワードを受け付ける処理部である。具体的には、受付部８１は、ユーザ端末１０からＷｅｂアクセスを受け付けると、ログイン画面を表示させる。そして、受付部８１は、入力されたログインＩＤとパスワードが登録済みであることからログインを許可すると、検索ツールＤＢ５３に記憶される情報を読み出して、検索ツールをユーザ端末１０に提供する。
【００５０】
例えば、受付部８１は、ログイン済みの登録ユーザのユーザ端末１０に対して、検索式、検索対象の画像、検索対象の動画などを表示して、検索対象の選択を受け付ける。そして、受付部８１は、受け付けた検索対象を検索キーワードとして判定部８２に出力する。なお、受付部８１は、ログインＩＤと社名、ＩＰ（Internet  Protocol）アドレスと社名などを予め対応付けておくことで、ログインした検索ユーザがどの企業かを特定することができる。なお、受付部８１は、特定した検索ユーザの社名なども判定部８２に出力する。
【００５１】
判定部８２は、ログインして検索キーワードを選択した検索ユーザと排他関係にあるデータ提供元が存在するか否かを判定する処理部である。具体的には、判定部８２は、検索ユーザをブラックリストに登録しているデータ提供元が存在するか否かを判定する。
【００５２】
例えば、判定部８２は、契約情報ＤＢ５４を参照して、検索ユーザの社名（Ａ社）から業種（流通）等を特定する。続いて、判定部８２は、契約情報ＤＢ５４に記憶される他の企業の契約情報を参照し、検索ユーザの業種（流通）をブラックリストに登録するデータ提供元を検索する。そして、判定部８２は、該当するデータ提供元が検索された場合、排他関係にある提供元が存在すると判定し、検索キーワードとともに当該データ提供元を検索応答部８３に通知する。なお、検索ユーザの業種（流通）がブラックリストに登録されるが、ホワイトリストで許可されている場合は、排他関係にないと判定し、検索応答部８３へは通知しない。
【００５３】
検索応答部８３は、受付部８１によって受け付けられた検索キーワードに対応するデータをライフログバンク１から検索する処理部であり、排他関係にあるデータ提供元のデータを、検索結果として応答する応答対象から除外する処理部である。具体的には、検索応答部８３は、排他関係にある提供元のデータを応答対象から除外したり、排他関係にある提供元の当該検索キーワードの重みを有するデータを応答対象から除外したりする。
【００５４】
例えば、検索応答部８３は、検索キーワードを検索キーとして、検索用インデックスＤＢ５６を検索して、検索キーワードに対応付けられるデータを特定する。一方で、検索応答部８３は、判定部８２から通知された排他関係にある提供元のデータが記憶される「ＢＤ内の場所」を契約情報ＤＢ５４から検索する。
【００５５】
そして、検索応答部８３は、特定したデータのうち、特定した「ＢＤ内の場所」に記憶されるデータを応答対象から除外し、除外したあとのデータ一覧を検索結果として検索ユーザに応答する。すなわち、検索応答部８３は、検索ユーザと排他関係にある、同業者の企業のデータを検索結果に含めずに、応答することができる。
【００５６】
また、検索応答部８３は、重み情報ＤＢ５５を参照して、提供先と排他関係にある提供元の当該検索キーワード（受け付けられた検索キーワード）の重みを特定する。そして、検索応答部８３は、特定したデータのうち、特定された重みに対応付けられるデータを応答対象から除外し、除外したあとのデータ一覧を検索結果として検索ユーザに応答する。すなわち、検索応答部８３は、提供先と排他関係にある提供元の企業と同様の重みを有するデータを検索結果に含めずに、応答することができる。
【００５７】
ここで、上述した検索処理の一例を説明する。なお、図８で説明する検索処理における各処理は、矛盾のない範囲内で処理順を変更することができる。また、図８では、重みを用いた例で説明する。図８は、検索処理を説明する図である。図８に示すように、検索サーバ５０のインデックス検索部８０は、流通（Ａ社）のユーザ端末からログインを受け付けてログインを許可すると（Ｓ１）、ログイン情報等からログインした検索ユーザの社名「Ａ社」および業種「流通」を特定する（Ｓ２）。
【００５８】
続いて、インデックス検索部８０は、検索ユーザと排他関係にある提供元を検索する（Ｓ３）。例えば、インデックス検索部８０は、契約情報ＤＢ５４を参照し、検索ユーザ「Ａ社、流通」の「流通」をブラックリストに登録する「Ｄ社」および「ＢＤ内の格納先＝.../yyy/」を特定する。
【００５９】
その後、インデックス検索部８０は、検索ユーザから検索式を受け付けると（Ｓ４）、検索式から検索キーワードを抽出する（Ｓ５）。例えば、インデックス検索部８０は、検索式「イチゴよりもリンゴが売れているか」を受け付けると、予め設定したキーワード一覧等に基づいて、検索式「イチゴよりもリンゴが売れているか」から検索キーワードとして「イチゴ」と「リンゴ」を抽出する。
【００６０】
続いて、インデックス検索部８０は、検索ユーザと排他関係にある提供元に対応付けられる各キーワードの重みのうち、検索キーワードに対応する重みを特定する（Ｓ６）。例えば、インデックス検索部８０は、重み情報ＤＢ５５に記憶される「Ｄ社」の重み一覧を参照し、検索キーワード「イチゴ」の重み「０．４００」と検索キーワード「リンゴ」の重み「０．２００」とを特定する。
【００６１】
その後、インデックス検索部８０は、検索キーワードを含むデータをライフログバンク１から検索し、排他関係にある提供元のデータの重みと同一の重みを有するデータを検索結果から除外して（Ｓ７）、検索ユーザに応答する（Ｓ８）。例えば、インデックス検索部８０は、検索キーワード「イチゴ」と対応付けられる重み「０．７８９、０．４００、０．３３３」のうち、排他関係の重み「０．４００」を除外する。そして、インデックス検索部８０は、検索キーワード「イチゴ」と対応付けられる重み「０．７８９、０．３３３」を有する文書を検索ユーザに応答する。同様に、インデックス検索部８０は、検索キーワード「リンゴ」と対応付けられる重み「０．６６６、０．２００、０．１２３」のうち、排他関係の重み「０．２００」を除外する。そして、インデックス検索部８０は、検索キーワード「リンゴ」と対応付けられる重み「０．６６６、０．１２３」を有する文書を検索ユーザに応答する。
【００６２】
［処理の流れ］
次に、上述した各処理部の処理について説明する。ここでは、検索用インデックスの生成処理と検索処理について説明する。
【００６３】
（生成処理）
図９は、検索用インデックスの生成処理の流れを示すフローチャートである。図９に示すように、インデックス生成部７０は、ライフログバンク１が記憶するデータの登録や更新が発生した場合（Ｓ１０１：Ｙｅｓ）、提供者ごとの検索用インデックスを生成する（Ｓ１０２）。例えば、インデックス生成部７０は、提供者の各データから検索用のキーワードを抽出する。
【００６４】
続いて、インデックス生成部７０は、提供者ごとに、検索キーワードの重みを算出して保存する（Ｓ１０３）。そして、インデックス生成部７０は、各提供者の検索キーワードと重みとの対応付けを収集し（Ｓ１０４）、ビッグデータ用の検索用インデックスを生成する（Ｓ１０５）。
【００６５】
（検索処理）
図１０は、検索処理の流れを示すフローチャートである。図１０に示すように、インデックス検索部８０は、検索ユーザがログインを行うと（Ｓ２０１：Ｙｅｓ）、ログイン情報等から検索ユーザを特定し、契約情報ＤＢ５４等を参照して、検索ユーザの業種等を特定する（Ｓ２０２）。
【００６６】
続いて、インデックス検索部８０は、契約情報ＤＢ５４を参照して、データの提供者（提供元）のブラックリストとホワイトリストを参照する（Ｓ２０３）。ここで、インデックス検索部８０は、排他関係が検出されると（Ｓ２０４：Ｙｅｓ）、排他関係にある提供者のデータ保存先を特定する（Ｓ２０５）。なお、インデックス検索部８０は、排他関係が検出されない場合（Ｓ２０４：Ｎｏ）、Ｓ２０５を実行することなく、Ｓ２０６を実行する。
【００６７】
その後、インデックス検索部８０は、検索式などの検索クエリを受信すると（Ｓ２０６：Ｙｅｓ）、検索クエリから検索キーワードを抽出する（Ｓ２０７）。そして、インデックス検索部８０は、排他関係にある提供者が存在しない場合（Ｓ２０８：Ｎｏ）、検索キーワードに対応する文書をビッグデータから検索して、検索ユーザに応答する（Ｓ２０９）。
【００６８】
一方、インデックス検索部８０は、排他関係にある提供者が存在する場合（Ｓ２０８：Ｙｅｓ）、排他関係にある提供者の当該検索キーワードの重みを特定する（Ｓ２１０）。例えば、インデックス検索部８０は、排他関係にある提供者のデータから抽出されたキーワードのうち、検索クエリから抽出された検索キーワードの重みを抽出する。
【００６９】
そして、インデックス検索部８０は、検索キーワードに対応する文書をビッグデータから検索する（Ｓ２１１）。その後、インデックス検索部８０は、検索された文書のうち、排他関係にある提供者の重みと一致する検索キーワードに対応する文書を除外して検索ユーザに応答する（Ｓ２１２）。
【００７０】
［効果］
上述したように、検索サーバ５０は、データ提供者のデータの検索用インデックスの作成時に、データのＴＦを用いた索引語の重み付けを計算する。そして、検索サーバ５０は、各提供者のデータの検索用インデックスと索引語の重みを集めて、ビッグデータの検索用インデックスを作成する。その後、検索サーバ５０は、検索ユーザが検索サービスにログインした際、契約情報から、データ提供者と検索ユーザの排他関係をチェックする。その後、検索サーバ５０は、検索ユーザの検索実行時に、検索キーワードから、排他関係にある提供者の索引語の重みを参照し、ビッグデータの検索用インデックスのアクセス時に、上記のキーワードと重みの組合せはスキップする。
【００７１】
したがって、検索サーバ５０は、１つのビッグデータ、１つの検索用インデックスだけで、検索ユーザへのデータ提供を管理できるため、リソースの効率化を図ることができる。また、検索サーバ５０は、データのキーワードの重みを検索用インデックスに追記することにより、データ提供者を識別するので、どの企業がどのようなデータを保有しているかが分かるような情報をビッグデータのサーバ内に残すことがなく、安全安心を担保できる。
【実施例２】
【００７２】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
【００７３】
［ビジネスモデル］
次に、実施例１で説明した検索サービスを用いたビジネスモデルの一例を説明する。図１１は、ビジネスモデルの適用例１を説明する図である。図１１に示すビジネスモデルは、クラウドサービスが検索エンジン、画像検索エンジン、動画検索エンジンとＢＩツールを、登録ユーザとして契約済みの検索ユーザに提供する。ここで、クラウドサービスが上記検索サーバ５０に対応する。クラウドサービスは、各種検索エンジンを用いて、検索ユーザから受け付けた検索キーワードに対応するデータをＢＤ（ビッグデータ）から検索する。そして、クラウドサービスは、検索結果から同業他社のデータを除外した検索結果を検索ユーザに提供する。このように、検索ユーザは、クラウドサービスにログインして、各種検索エンジンとＢＩツールとを利用することで、データマイニング等を実行する。
【００７４】
図１２は、ビジネスモデルの適用例２を説明する図である。図１２に示すビジネスモデルは、クラウドサービスが検索エンジン、画像検索エンジン、動画検索エンジンとＢＩツールを、登録ユーザとして契約済みの検索ユーザに提供する。また、契約済みの検索ユーザに対しては、検索式や画像などが設定された検索ツールが提供される。検索ユーザは、検索ツールを用いてクラウドサービスにアクセスし、検索キーワードなどを送信する。クラウドサービスは、各種検索エンジンを用いて、検索ユーザから受け付けた検索キーワードに対応するデータをＢＤ（ビッグデータ）から検索する。そして、クラウドサービスは、検索結果から同業他社のデータを除外した検索結果を検索ユーザに提供する。このように、検索ユーザは、クラウドサービスから提供された検索ツールを用いることで、ビッグデータに対してデータ検索を行って、データマイニング等を実行する。
【００７５】
［データ種別、重み計算手法］
上記実施例では、検索対象のデータとして文書を用いた例で説明したが、これに限定されるものではなく、例えばタグが指定された画像や動画などについても同様に処理することができる。また、上記重み計算では、ＴＦを用いた例を説明したが、これに限定されるものではなく、例えば登場回数をそのまま重みに設定するなど、公知の手法を採用することができる。
【００７６】
［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００７７】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、アイテムを表示する処理部と、選好を推定する処理部とを別々の筐体で実現することもできる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【００７８】
［ハードウェア］
図１３は、ハードウェア構成例を説明する図である。なお、図１に示した各装置は同様のハードウェア構成例を有するので、ここでは、検索サーバ５０について説明する。図１３に示すように、検索サーバ５０は、通信インタフェース５０ａ、ＨＤＤ（Hard  Disk  Drive）５０ｂ、メモリ５０ｃ、プロセッサ５０ｄを有する。また、図１３に示した各部は、バス等で相互に接続される。
【００７９】
通信インタフェース５０ａは、ネットワークインタフェースカードなどであり、他のサーバとの通信を行う。ＨＤＤ５０ｂは、図２に示した機能を動作させるプログラムやＤＢを記憶する。
【００８０】
プロセッサ５０ｄは、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ５０ｂ等から読み出してメモリ５０ｃに展開することで、図２等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、検索サーバ５０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ５０ｄは、インデックス生成部７０とインデックス検索部８０等と同様の機能を有するプログラムをＨＤＤ５０ｂ等から読み出す。そして、プロセッサ５０ｄは、インデックス生成部７０とインデックス検索部８０等と同様の処理を実行するプロセスを実行する。
【００８１】
このように検索サーバ５０は、プログラムを読み出して実行することで検索方法を実行する情報処理装置として動作する。また、検索サーバ５０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、検索サーバ５０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【符号の説明】
【００８２】
１  ライフログバンク
２  データの提供先
１０  ユーザ端末
１１  通信部
１２  記憶部
１３  制御部
１４  検索入力部
１５  応答受信部
５０  検索サーバ
５１  通信部
５２  記憶部
５３  検索ツールＤＢ
５４  契約情報ＤＢ
５５  重み情報ＤＢ
５６  検索用インデックスＤＢ
６０  制御部
７０  インデックス生成部
７１  算出部
７２  生成部
８０  インデックス検索部
８１  受付部
８２  判定部
８３  検索応答部
【図１】
2019128800.tif 000003
【図２】
2019128800.tif 000004
【図３】
2019128800.tif 000005
【図４】
2019128800.tif 000006
【図５】
2019128800.tif 000007
【図６】
2019128800.tif 000008
【図７】
2019128800.tif 000009
【図８】
2019128800.tif 000010
【図９】
2019128800.tif 000011
【図１０】
2019128800.tif 000012
【図１１】
2019128800.tif 000013
【図１２】
2019128800.tif 000014
【図１３】
2019128800.tif 000015