(57)【要約】【課題】データベースを構成する個々の情報の取扱いをコントロールする技術に関し、従来技術では当該情報の取扱態様を登録の際に決めておかなければならず、柔軟かつ機動的な取扱をすることが困難だった。【解決手段】被検索の可否を示す検索可否属性を付与された被検索データ群を格納したデータ群格納部と、データ群格納部に格納された被検索データ群に対する検索クエリを取得する検索クエリ取得部と、データ群格納部の被検索データ群を検索する場合に、データ権限者端末から検索可否情報をあらかじめ取得する検索可否情報取得部と、検索可否情報に基づいて被検索データの検索可否属性を書き換えて、その書き換えられた検索可否属性と、前記取得した検索クエリと、に基づいてデータ群格納部の全体の検索を実行する検索実行部と、を有する被検索拒否可能データベース等を提供する。【選択図】図１
2015138540.tif 000002
【特許請求の範囲】
【請求項１】
被検索の可否を示す検索可否属性を付与された被検索データ群を格納したデータ群格納部と、
前記データ群格納部に格納された被検索データ群に対する検索クエリを取得する検索クエリ取得部と、
データ群格納部の被検索データ群を検索する場合に、被検索データ群を構成する被検索データの一又は二以上をその検索の対象とするか否かを定めうるデータ権限を有するデータ権限者の利用するデータ権限者端末から前記検索の実行に際して被検索データを検索対象とするか否を定めるための情報である検索可否情報をあらかじめ取得する検索可否情報取得部と、
検索可否情報に基づいて被検索データの検索可否属性を書き換えて、その書き換えられた検索可否属性と、前記取得した検索クエリと、に基づいてデータ群格納部の全体の検索を実行する検索実行部と、
を有する被検索拒否可能データベース。
【請求項２】
前記検索クエリ取得部は、検索クエリをクエリ属性と関連付けて取得する属性付検索クエリ取得手段を有し、
検索可否情報取得部は、検索の実行に際して検索クエリに関連付けられたクエリ属性に応じて被検索データを検索対象とするか否かを定める情報である属性依存検索可否情報を取得する属性依存検索可否情報取得手段を有する
請求項１に記載の被検索拒否可能データベース。
【請求項３】
検索クエリとして取得すべき検索クエリを登録する検索クエリ登録部と、
登録された検索クエリに関連する情報を含む検索可否問合情報を前記データ権限者に送信する検索可否問合情報送信部と、
前記送信された検索可否問合情報に応じた検索可否情報を含む返信を受信する返信受信部と、
受信した返信に含まれる検索可否情報を検索可否情報取得部に出力する返信出力部と、をさらに有する請求項１又は２に記載の被検索拒否可能データベース。
【請求項４】
検索可否情報取得部は所定の被検索データについて複数のデータ権限者からの複数の検索可否情報を取得する複数取得手段を有し、
検索実行部は、前記複数の検索可否情報に基づいて当該被検索データが検索可とできるか判断する複数時判断手段を有し、複数時判断手段によって当該被検索データが検索可能と判断された場合のみ当該検索を実行する請求項１から３のいずれか一に記載の被検索拒否可能データベース。
【請求項５】
データ群格納部に格納されている検索可能な被検索データと検索不能な被検索データとの差分情報を出力する差分情報出力部をさらに有する請求項１から４のいずれか一に記載の被検索拒否可能データベース。
【請求項６】
前記差分情報と検索実行可・不可を定める可・不可テーブルを保持する可・不可テーブル保持部と、
前記差分情報と前記可・不可テーブルとに基づいて検索実行部を制御する制御部とをさらに有する請求項５に記載の被検索拒否可能データベース。
【請求項７】
被検索の可否を示す検索可否属性を付与された被検索データ群を格納するデータ群格納ステップと、
前記データ群格納ステップに格納された被検索データ群に対する検索クエリを取得する検索クエリ取得ステップと、
データ群格納ステップの被検索データ群を検索する場合に、被検索データ群を構成する被検索データの一又は二以上をその検索の対象とするか否かを定めうるデータ権限を有するデータ権限者の利用するデータ権限者端末から前記検索の実行に際して被検索データを検索対象とするか否を定めるための情報である検索可否情報をあらかじめ取得する検索可否情報取得ステップと、
検索可否情報に基づいて被検索データの検索可否属性を書き換えて、その書き換えられた検索可否属性と、前記取得した検索クエリと、に基づいて被検索データ群全体の検索を実行する検索実行ステップと、
を有する被検索拒否可能データベースの検索方法。
【請求項８】
前記検索クエリ取得ステップは、検索クエリをクエリ属性と関連付けて取得する属性付検索クエリ取得サブステップを有し、
検索可否情報取得ステップは、検索の実行に際して検索クエリに関連付けられたクエリ属性に応じて被検索データを検索対象とするか否かを定める情報である属性依存検索可否情報を取得する属性依存検索可否情報取得サブステップを有する
請求項７に記載の被検索拒否可能データベースの検索方法。
【請求項９】
検索クエリとして取得すべき検索クエリを登録する検索クエリ登録ステップと、
登録された検索クエリに関連する情報を含む検索可否問合情報を前記データ権限者に送信する検索可否問合情報送信ステップと、
前記送信された検索可否問合情報に応じた検索可否情報を含む返信を受信する返信受信ステップと、
受信した返信に含まれる検索可否情報を出力する返信出力ステップと、をさらに有する請求項７又は８に記載の被検索拒否可能データベースの検索方法。
【請求項１０】
検索可否情報取得ステップは所定の被検索データについて複数のデータ権限者からの複数の検索可否情報を取得する複数取得サブステップを有し、
検索実行部ステップは、前記複数の検索可否情報に基づいて当該被検索データが検索可とできるか判断する複数時判断サブステップを有し、複数時判断サブステップによって当該被検索データが検索可能と判断された場合のみ当該検索を実行する請求項７から９のいずれか一に記載の被検索拒否可能データベースの検索方法。
【請求項１１】
データ群格納ステップの実行により格納されている検索可能な被検索データと検索不能な被検索データとの差分情報を出力する差分情報出力ステップをさらに有する請求項７から１０のいずれか一に記載の被検索拒否可能データベースの検索方法。
【請求項１２】
前記差分情報と検索実行可・不可を定める可・不可テーブルを保持する可・不可テーブル保持部と、
前記被検索データ差分情報と前記可・不可テーブルとに基づいて検索実行ステップを制御する制御ステップとをさらに有する請求項１１に記載の被検索拒否可能データベースの検索方法。
【請求項１３】
被検索拒否可能データベースと、このデータベースとのネットワークを介した通信により検索クエリの入力をおこない又は／及び検索結果を表示する外部端末と、からなるデータベース検索システムであって、
前記被検索拒否可能データベースは、
被検索の可否を示す検索可否属性を付与された被検索データ群を格納したデータ群格納部と、
前記データ群格納部に格納された被検索データ群に対する検索クエリを取得する検索クエリ取得部と、
データ群格納部の被検索データ群を検索する場合に、被検索データ群を構成する被検索データの一又は二以上をその検索の対象とするか否かを定めうるデータ権限を有するデータ権限者の利用するデータ権限者端末から前記検索の実行に際して被検索データを検索対象とするか否を定めるための情報である検索可否情報をあらかじめ取得する検索可否情報取得部と、
検索可否情報に基づいて被検索データの検索可否属性を書き換えて、その書き換えられた検索可否属性と、前記取得した検索クエリと、に基づいてデータ群格納部の全体の検索を実行する検索実行部と、を有し、
前記外部端末は、
前記検索クエリの入力を受付け前記被検索拒否データベースに送信する検索クエリ送信部と、
前記検索実行部にて行われた検索結果を表示する検索結果表示部と、を有する
データベース検索システム。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、構成する個々の被検索データに関し被検索の可否を決定する権限を有するデータ権限者が存在するデータベースや、当該データベースを用いた検索方法、および当該データベースを用いた検索システムなどに関する。
【背景技術】
【０００２】
従来から、特定の目的のもと集積された情報をデータベース化して保持し、検索者によるキーワードや日付等の検索クエリの入力に応じて当該データベース中に格納された被検索データを提供するシステムに関する技術が知られている。当該技術のもとでは、データベースに格納される多種多様かつ膨大な量の被検索データ群のうち、検索者の意図に沿った内容の被検索データのみを抽出し出力することが可能である。
【０００３】
ただし、当該データベースに格納される被検索データ群が個人等番号（マイナンバー）と紐づけられうる個人情報や商店・企業の営業秘密（以下、まとめて「個人情報等」ということがある）に関する情報から構成されている場合、当該データベースの利用者や利用方法によっては、重大なプライバシー侵害・営業秘密の漏えいが生じうる。データベースに格納されるデータ量が大量になり、ビッグデータとしてその利用価値に注目が集まれば集まるほど、情報の流出や流用の懸念はますます高まっている。
【０００４】
そこで従来から、データベースに格納されたデータが、第三者によって容易に検索されたり、利用されたりしないようにするための種々の技術が開示されてきた。特に特許文献１には、データベースに個人情報を格納する際に所定の情報を付与することにより、当該個人情報を検索を経ずに閲覧することは可能だが検索対象からは外すようにするための技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−３５５３３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１記載の従来技術では、対象となるデータを検索対象とするか否かを当該データの登録格納時に判断しなければならず、登録後の事情の変化への対応が困難だった。
【０００７】
また、検索対象とするか否かという二者択一でしか判断することが出来なかったため、例えば、特定の検索クエリを用いた検索に対してだけ検索対象としない、といったようなよりデータ権限者の具体的な意向を酌んだ対応をとることは困難だった。
【課題を解決するための手段】
【０００８】
以上のような課題を解決するために、本発明は、検索可否を属性として付与可能な被検索データを格納するとともにその被検索データに対する検索クエリを取得し、前記格納されたデータを検索対象とする場合には、被検索データを検索母集団に含めるか否かを定めうるデータ権限を有するデータ権限者から、前記データに関する検索の実行に際して当該データを検索母集団に含めるか否を定める情報である検索可否情報を取得し、この検索可否情報に基づいて検索可である母集団のデータに対して前記検索クエリに基づいた検索を実行する被検索拒否可能データベースなどを提案する。
【発明の効果】
【０００９】
主に上記のような構成をとる本発明によって、データベースを構成する情報に一定の権限を有する者が当該各情報の取扱いを主体的かつ機動的にコントロールすることが可能になる。
【図面の簡単な説明】
【００１０】
【図１】実施形態１の被検索拒否可能データベースの概念図
【図２】実施形態１の被検索拒否可能データベースの機能ブロックの一例を示す図
【図３】データ群格納部にて格納されるデータ一覧の一例を示す図
【図４】被検索データ格納時にデータ権限者が特定のデータ権限者による検索を拒否する内容の検索可否情報を送信する場合のデータ権限者端末のインターフェースの一例を示す図
【図５】従来技術のデータベースにて検索を実行した場合の検索結果表示の一例を示す図
【図６】実施形態１のデータベース検索システムにて検索を実行した場合の検索結果表示の一例を示す図
【図７】実施形態１の被検索拒否可能データベースの機能的な構成をハードウェアとして実現した際の構成の一例を示す概略図
【図８】実施形態１の外部端末の機能的な構成をハードウェアとして実現した際の構成の一例を示す概略図
【図９】実施形態１のデータベース検索システムにおける処理の流れの一例を示す図
【図１０】実施形態１のデータベース検索システムにおける処理の流れの別の一例を示す図
【図１１】実施形態２の被検索拒否可能データベースの機能ブロックの一例を示す図
【図１２】検索クエリ登録の具体的な態様の一例を示す図
【図１３】実施形態２の被検索拒否可能データベースにおける処理の流れの一例を示す図
【図１４】実施形態３の被検索拒否可能データベースの機能ブロックの一例を示す図
【図１５】1
【図１６】実施形態３の被検索拒否可能データベースにおける処理の流れの一例を示す図
【図１７】実施形態４の被検索拒否可能データベースの機能ブロックの一例を示す図
【図１８】実施形態４の被検索拒否可能データベースにおける処理の流れの一例を示す図
【図１９】実施形態５の被検索拒否可能データベースの機能ブロックの一例を示す図
【図２０】実施形態５の被検索拒否可能データベースにおける処理の流れの一例を示す図
【図２１】実施形態６の被検索拒否可能データベースの機能ブロックの一例を示す図
【図２２】実施形態６の被検索拒否可能データベースの可・不可テーブル保持部に保持される可・不可テーブルの一例を示す図
【図２３】実施形態６の被検索拒否可能データベースにおける処理の流れの一例を示す図
【発明を実施するための形態】
【００１１】
以下、本発明の各実施形態について図面と共に説明する。実施形態と請求項の相互の関係は、以下のとおりである。まず、実施形態１は、主に請求項１、７、１３などに対応する。実施形態２は、主に請求項２、８などに対応する。実施形態３は、主に請求項３、９などに対応する。実施形態４は、主に請求項４、１０などに対応する。実施形態５は、主に請求項５、１１などに対応する。実施形態６は、主に請求項６、１２などに対応する。なお、本発明はこれらの実施形態に何ら限定されるものではなく、その要旨を逸脱しない範囲内において、様々な態様で実施し得る。
【００１２】
<<実施形態１>>
<概要>
【００１３】
図１は、本実施形態のデータベース検索システムの概念図である。同図では、検索者Ｑが「外部端末」０１１０を用いて「被検索拒否可能データベース」０１０１に格納された被検索データ群の検索を行う様子が示されている。検索者が外部端末への入力を通じて被検索拒否可能データベースに対し所定の検索クエリを送信すると、データベースでは各データ権限者から取得した検索可否情報に基づいて被検索データに付与された検索可否属性を書き換え、その書き換えられた検索可否属性と前記送信された検索クエリとに基づいて検索を実行する。
【００１４】
<機能的構成>
図２は、本実施形態のデータベース検索システムの機能ブロックの一例を示す図である。この図にあるように、本実施形態のデータベース検索システムは、「被検索拒否可能データベース」０２１０と、「外部端末」０２２０と、からなり、被検索拒否可能データベースは、「データ群格納部」０２１１と、「検索クエリ取得部」０２１２と、「検索可否情報取得部」０２１３と、「検索実行部」０２１４と、を有する。外部端末は、「検索クエリ送信部」０２２１と、「検索結果表示部」０２２２と、を有する。
【００１５】
なお、以下に記載するデータベース検索システムを構成する各装置の機能ブロックは、いずれもハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの両方として実現され得る。具体的には、コンピュータを利用するものであれば、ＣＰＵやメインメモリ、ＧＰＵ、画像メモリ、グラフィックボード、バス、あるいは二次記憶装置（ハードディスクや不揮発性メモリ、ＣＤやＤＶＤなどの記憶媒体とそれらの媒体の読取ドライブなど）、情報入力に利用される入力デバイス、タッチパネル、スキャナ装置、プリンタ、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインターフェース、通信用インターフェース、それらハードウェアを制御するためのドライバプログラムやその他アプリケーションプログラムなどが挙げられる。そして、メインメモリ上に展開したプログラムに従ったＣＰＵの演算処理によって、入力デバイスやその他インターフェースなどから入力されメモリやハードウェア上に保持されているデータなどが加工、蓄積されたり、前記各ハードウェアやソフトウェアを制御するための命令が生成されたりする。ここで、上記プログラムは、モジュール化された複数のプログラムとして実現されてもよいし、２以上のプログラムを組み合わせて一のプログラムとして実現されてもよい。
【００１６】
なお、本発明は一または複数の装置との組み合わせによりシステムとして実現可能である。そして、このような装置の一部をソフトウェアとして構成することも可能である。さらに、そのようなソフトウェアが記録された記憶媒体も当然に本発明の技術的な範囲に含まれる（本実施形態に限らず、本明細書の全体を通じて同様である。）。
【００１７】
（被検索拒否可能データベースの機能的構成）
「データ群格納部」０２１１は、被検索の可否を示す検索可否属性を付与された被検索データ群を格納するように構成される。「被検索の可否を示す」とは当該被検索データを検索対象に含めるかどうかを示す情報であり、「検索可否属性を付与された」とあるように、検索実行の有無とは別に予め被検索データと紐づけられている。すなわち、検索可否属性は検索実行の際に取得される検索クエリとは異なる内容の情報である。上記特徴を備える検索可否属性を被検索データに付与する構成を採用することにより、各被検索データの取り扱われ方につき、後記データ権限者の意向を明確に反映させることが可能になる。
【００１８】
被検索データ群を構成する各被検索データには様々な属性が付与されてよい。具体的には、あらゆる検索における被検索の可否を示すほか、特定検索者からの被検索の可否を示す特定検索者検索可否属性や、特定の検索クエリに基づく被検索の可否を示す特定クエリ検索可否属性、特定の時間帯における被検索の可否を示す特定時間検索可否属性などが考えられる。これら所定条件を満たす場合の検索可否についての情報を検索可否属性として被検索データに付与することにより、例えば、特定の検索者による検索のみを拒否したり、特定の検索クエリによる検索のみを拒否したりすることができるといったように、被検索データの取扱につきデータ権限者の意向をダイナミックに反映させることが可能になる。
【００１９】
なお、データ群格納部に格納される被検索データ群を構成する各被検索データの内容に特段の限定はない。一例を挙げると、在校生や卒業生の名簿記載情報や学術論文の書誌情報、特許発明の書誌情報、取引関係にある顧客情報などが考えられる。
【００２０】
ここで図３は、データ群格納部にて格納されるデータ群の一例を示す図である。この例は、ある事業者における商取引の概要を示したデータ群が格納されている。同図で示されているのは、検索可否属性や請求者名称、請求先名称、請求金額、請求書発行日、支払期日、支払方法などが各情報のデータ権限者のＩＤであるオーナーＩＤによって相互に紐づけられたデータの一群である。検索可否属性のうち「○」は検索対象とすることを可とするデータであり、「×」は検索対象とすることを不可とするデータである。同図で示した例の場合は、データ権限者を全て請求先の事業者としているが、データ権限者は請求者であってもそれ以外の第三者であってもよい。また、株式会社ミカサ商事がデータ権限者（オーナーＩＤ：Ａ）である被検索データ群のように、一のデータ権限者に対して検索対象とすることを可とする被検索データと不可とする被検索データとが混在していてもよい。当該構成をとることにより、個々の事情に応じた柔軟な被検索データの取扱が可能になる。
【００２１】
被検索データは、各データ権限者から個別入力を受付けて格納してもよいし、他のサーバに格納された被検索データ群をネットワークを介して取得し格納してもよい。データ権限者からの個別のデータ登録を受付ける場合であれば、当該入力の際に検索可否属性の入力も受付けるようにすればよく、他のサーバから被検索データ群を取得する場合であれば、当該取得時点において、各被検索データのデータ権限者に検索可否属性について問い合わせる処理を行うことが考えられる。いずれにしても検索可否属性は、少なくとも検索の実行時点において被検索データに付与されていればよい。
【００２２】
「検索クエリ取得部」０２１２は、前記データ群格納部に格納された被検索データ群に対する検索クエリを取得するように構成される。具体的には、検索者が端末を通じて入力した検索クエリをネットワークインターフェースを介して取得する。図３に示した商取引に関する各種情報が被検索データ群として格納されたデータベースの例においては、例えば「山上」などの文字列と一致する請求者名称を含む被検索データ群を取得せよとの内容の検索クエリを取得したり、「〜２０１３．１０．３１」などの支払期日にて限定される被検索データ群を取得せよとの内容の検索クエリを取得したりする場合が想定される。
【００２３】
「検索可否情報取得部」０２１３は、データ群格納部の被検索データ群を検索する場合に、被検索データ群を構成する被検索データの一又は二以上をその検索の対象とするか否かを定めうるデータ権限を有するデータ権限者の利用するデータ権限者端末から前記検索の実行に際して被検索データを検索対象とするか否を定めるための情報である検索可否情報をあらかじめ取得するように構成される。「データ群格納部の被検索データ群を検索する場合」とは、端的には、外部端末からの検索要求があった場合であり、さらに具体的にいえば、外部端末の検索クエリ送信部から送信された検索クエリを検索クエリ取得部にて取得した場合である。
ただし、検索可否情報は検索の実行に際して予め取得されていればよく、例えば、被検索データ群が格納され検索の対象となりうる状態になれば、それ以降は「データ群格納部の被検索データ群を検索する場合」である。当該構成をとれば、検索クエリの取得前段階で検索可否情報を取得することができ、検索クエリ取得から検索の実行までの処理を短時間で完了させ、迅速に検索結果を出力することが可能になる。
【００２４】
「被検索データ群を構成する被検索データの一又は二以上をその検索の対象とするか否かを定めうるデータ権限を有するデータ権限者」とは通常、当該被検索データに自身の個人情報や信用情報、自身の営業秘密等が含まれている者のように、当該被検索データを管理する者である。図３を用いて説明した例の場合は、請求先事業者をデータ権限者と定めたが、それ以外の者であってもよいことは既に説明したとおりである。データ権限者は、効率的な情報の検索を可能とするデータベースの機能性を生かしつつ、検索可否情報の送信を通じた検索可否属性の書き換えを可能とすることで、自身に関連する被検索データの流通を臨機応変にコントロールすることが可能になる。
【００２５】
「検索の実行に際して被検索データを検索対象とするか否を定めるための情報である検索可否情報をあらかじめ取得する」とは、検索可否情報が検索の実行時よりも前に取得されていることを指しており、検索の実行前のどの時点で取得するかどうかまでは問わない。検索クエリの取得前に取得してもよいし、検索クエリの取得後検索の実行前の時点に取得してもよい。具体的にいえば、検索クエリの取得前であれば、例えば被検索データ格納の際、当該被検索データの検索可否情報をもあわせて取得したり、その後の事情の変化に応じ任意のタイミングで格納済みの検索可否属性を書き換えるための検索可否情報を取得したりする構成が考えられる。また、検索クエリの取得後であれば、例えば各データ権限者端末に対し当該検索クエリに関連する検索可否情報の送信を促す信号を送信し、当該信号を受信したデータ権限者端末から検索可否情報を受信する構成が考えられる。
【００２６】
以上で説明したデータ権限者端末における検索可否情報の送信形態の一例を具体的に説明するために、図４を示す。同図は、被検索データの格納時にデータ権限者が特定の検索者からの被検索を拒否する内容の検索可否情報を送信する場合のデータ権限者端末のインターフェースの一例を示す図である。同図に示した例の場合、検索者がＱである場合、Ｗは自身がデータ権限を有する被検索データをＱによる検索の場合には検索対象に含めることを拒否する内容の検索可否情報を送信している。このようにデータ権限者は、特定の検索者からの検索や特定の検索クエリに基づく検索について被検索データを検索対象としないことを内容とする検索可否情報を検索可否情報取得部に対して送信することができる。なお、検索可否情報は検索実行中以外であれば任意のタイミングで変更することができ、当該変更のためインターフェースとして「編集」タブなどを設けている。当該構成をとれば、データ権限者は検索可否情報の送信を通じ、被検索データの検索可否属性を書き換え、当該被検索データの流通をコントロールすることが可能になる。
【００２７】
なお、「検索可否情報をあらかじめ取得する」とは、必ずしもデータ権限者端末から積極的に送信された検索可否情報を受信することを意味しない。例えば、被検索データ格納時に検索可否情報が入力されなかった場合や、前記検索可否情報の送信を促す信号に対する所定時間内の応答がなかった場合であっても、当該入力あるいは応答がなかったという状態をもって検索可否情報の取得処理を行ってもよい。この場合に被検索データを検索対象とするか否かは任意に設定することが可能である。当該構成をとることにより、不定のタイミングで行われ得る検索要求に対し、データ権限者においていちいち検索可否判断を行う煩雑さや不確実性を回避することが可能になる。
【００２８】
「検索実行部」０２１４は、検索可否情報に基づいて被検索データの検索可否属性を書き換えて、その書き換えられた検索可否属性と、前記取得した検索クエリと、に基づいてデータ群格納部の全体の検索を実行するように構成される。「検索可否情報に基づいて被検索データの検索可否属性を書き換えて」とは、データ群格納部に格納されている被検索データに付与された検索可否属性の内容をデータ管理権限者端末から送信された検索可否情報の内容と整合させることを意味しており、実際の情報の書き換えを必須とするものではない。すなわち、従前から特定の検索者からの被検索を拒否する旨の検索可否属性が格納されている場合、当該被検索データにつき改めて同内容の検索可否情報を取得した場合には、検索可否属性を変更する処理を行う必要はない。
【００２９】
「書き換えられた検索可否属性と、取得した検索クエリと、に基づいて」とは、具体的には、データ群格納部に格納された全被検索データ群のうち検索を可とするように書き換えられた検索可否属性を有する被検索データ群を対象として、取得した検索クエリの要求を充たす検索を実行することを意味している。すなわち、取得した検索クエリに基づいて全被検索データ群の検索を実行し、その後に当該実行の結果得られた情報のうち検索を可とする被検索データ群を抽出する処理は、ここでいう「書き換えられた検索可否属性と、取得した検索クエリと、に基づいて」には含まれない。当該構成をとることにより、検索結果が出力されるか否かに関わらず、検索対象に含めることを拒否するデータ権限者の意向をより反映させることが可能になる。なお、検索クエリを利用した種々の検索処理については、いずれも従来技術を用いて実現可能である。
【００３０】
（外部端末の機能的構成）
「検索クエリ送信部」０２２１は、検索クエリの入力を受付け前記被検索拒否可能データベースの検索クエリ取得部に送信するように構成されている。検索クエリの入力態様については、任意のキーワード入力のほか、予め設定された複数のタブやコマ、プルダウンメニュー等の選択入力などが考えられる。
【００３１】
「検索結果表示部」０２２２は、前記検索実行部にて行われた検索結果を表示するように構成されている。ここでいう「検索結果」とは、検索実行の結果抽出される被検索データ群そのもののほか、当該被検索データ群を構成する被検索データの数、各被検索データの被検索回数など検索を行うことにより抽出可能な情報をも含む。当該構成をとることにより、検索クエリに対応する被検索データ群を把握することのみならず、当該被検索データ群を構成する被検索データが多いか少ないか、多くの検索者によって検索されているのか、自身以外にも検索している者がいるのか、などの付随的な情報をも取得し、分析の対象とすることが可能になる。
【００３２】
なお、特定の被検索データが検索対象に含まれていない旨の情報を当該検索者に対して通知する必要はないが、検索結果を表示するに際し、図６にて「この検索結果は被検索を望まないデータの存在を反映していません」とあるように一部の被検索データ群が検索対象に含まれなかった旨の情報は出力してもよい。当該構成をとることにより、検索結果が必ずしもデータベースに含まれる全ての被検索データを網羅した検索結果ではないことを把握させるとともに、当該被検索データ群の取扱が慎重になされるべき性質のものであることを認識させることが可能になる。
【００３３】
なおここで、図１や図３、図５、図６などを用いて本実施形態のデータベース検索システムの各機能を説明する。図５は従来技術のデータベースにて検索を実行した場合の検索結果表示の一例を示す図であり、図６は本実施形態の被検索拒否可能データベースにて検索を実行した場合の検索結果表示の一例を示す図である。
【００３４】
まず複数のデータ権限者が権限を有する複数の被検索データ群が格納された商取引に関する被検索拒否可能データベースに対して、検索者が端末への入力を通じ、請求者名称のなかに「山上」の文字列を含む被検索データ群を検索するよう要求するための検索クエリを送信する。このとき、被検索拒否可能データベースには図３記載のような被検索データ群が格納されている。このとき、もし検索可否情報ないし検索可否属性を用いず検索クエリにのみ基づいて検索を実行すると、当該検索結果として表示出力されるのは図５に示されたような内容となる。すなわち、データ権限者がＡ、Ｃ、Ｄ、Ｐ、Ｗである計８つの被検索データからなる被検索データ群が表示される。
【００３５】
前記検索者から送信された検索クエリを取得した被検索拒否可能データベースは、データ権限者の端末に対し当該検索クエリに対する検索可否情報の送信を促す信号を送信する。具体的には、Ａ、Ｃ、Ｄ、ＰおよびＷの５名のデータ権限者に対し、上記信号を送信する。これに対し、データ権限者ＡおよびＤは検索対象とすることを可とする検索可否情報を送信し、データ権限者ＣおよびＷは検索対象とすることを拒否する検索可否情報を送信した。なおデータ権限者Ｐは所定時間内に何らの検索可否情報も送信しなかった。ここで、データ権限者から検索可否情報が所定時間内に送信されなかった場合には、別途当該データ権限者端末からは検索対象とすることを可とする検索可否情報が送信されるものとする。
【００３６】
本実施形態のデータベース検索システムにおいては、上記検索可否情報を受信したことにより一部のデータにおける検索可否属性が「可（○）」から「不可（×）」に書き換えられる。検索可否属性が「×」に書き換えられた被検索データは検索対象とならない。すなわち、検索クエリ及び上記書き換えられた検索可否属性に応じた検索を実行すると、検索結果として表示されるのは、図６に示されたような内容となる。すなわち、データ権限者がＡであり被検索データ群のうち請求金額が１７８，５００円である被検索データとデータ権限者がＤ、Ｐである被検索データ群が表示される。すなわち、データ権限者がＡであり被検索データ群のうち請求金額が３１，５００円である被検索データとデータ権限者がＣ、Ｗである被検索データ群は検索対象とならず、よって表示されない。
【００３７】
<具体的な構成>
図７及び８は、本実施形態のデータベース検索システムを構成する各装置の機能的な各構成をハードウェアとして実現した際の構成の一例を示す概略図である。この図を利用して、それぞれのハードウェア構成部の働きについて説明する。
【００３８】
<被検索拒否可能データベースの具体的な構成>
図７は、本実施形態の被検索拒否可能データベースの機能的な各構成をハードウェアとして実現した際の構成の一例を示す概略図である。この図にあるように、本実施形態の被検索拒否可能データベースは、各種演算処理を実行するための「ＣＰＵ」０７０１と、「記憶装置（記憶媒体）」０７０２と、「メインメモリ」０７０３と、「出力インターフェース」０７０４と、「入力インターフェース」０７０５と、「インターネット通信インターフェース」０７０６と、を備え、入出力インターフェースを介して、例えば「キーボード」０７０７や「ディスプレイ」０７０８、などの外部周辺装置と情報の送受信を行う。また、インターネット通信インターフェースを介して「外部端末」０７８０や「データ権限者端末」０７９０と情報の送受信を行う。このインターネット通信インターフェースの具体的な態様は有線、無線を問わず、よって本実施形態の被検索拒否可能データベースをいわゆるクラウドコンピューティングの形式にて提供することが可能である。なお、記憶装置には以下で説明するような各種プログラムが格納されており、ＣＰＵはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」０７０９などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
【００３９】
（データ群格納部の具体的な処理）
ＣＰＵは、記憶装置から「データ格納プログラム」０７１０をメインメモリに読み出して実行し、検索可否を属性として付与可能な被検索データを受信し、メインメモリにおいてデータベースに適した所定の格納構造にて格納する。
【００４０】
（検索クエリ取得部の具体的な処理）
ＣＰＵは、記憶装置から「検索クエリ取得プログラム」０７２０をメインメモリに読み出して実行し、前記データ格納プログラムの実行により得られた被検索データ群に対する検索クエリを受信する処理を行う。
【００４１】
（検索可否情報取得部の具体的な処理）
ＣＰＵは、記憶装置から「検索可否情報取得プログラム」０７３０をメインメモリに読み出して実行し、データ権限者端末から検索の実行に際して被検索データを検索対象とするか否かを定めるための情報である検索可否情報を取得し、当該情報をメインメモリの所定のアドレスに格納する処理を行う。
【００４２】
（検索実行部の具体的な処理）
ＣＰＵは、記憶装置から「検索実行プログラム」０７４０をメインメモリに読み出して実行し、検索可否情報と検索クエリとを読み出して、両情報に基づいてデータベースの検索を実行する処理を行う。
【００４３】
<外部端末の具体的な構成>
図８は、本実施形態の外部端末の機能的な各構成をハードウェアとして実現した際の構成の一例を示す概略図である。この図にあるように、本実施形態の外部端末は、各種演算処理を実行するための「ＣＰＵ」０８０１と、「記憶装置（記憶媒体）」０８０２と、「メインメモリ」０８０３と、「出力インターフェース」０８０４と、「入力インターフェース」０８０５と、「インターネット通信インターフェース」０８０６と、を備え、入出力インターフェースを介して、例えば「キーボード」０８０７や「マウス」０８０８、「ディスプレイ」０８０９、などの外部周辺装置と情報の送受信を行う。また、インターネット通信インターフェースを介して「被検索拒否可能データベース」０８９０と情報の送受信を行う。このインターネット通信インターフェースの具体的な態様は有線、無線を問わず、よって本実施形態の被検索拒否可能データベースをいわゆるクラウドコンピューティングの形式にて提供することが可能である。なお、記憶装置には以下で説明するような各種プログラムが格納されており、ＣＰＵはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」０８１０などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
【００４４】
（検索クエリ送信部の具体的な処理）
ＣＰＵは、記憶装置から「検索クエリ送信プログラム」０８５０をメインメモリに読み出して実行し、入力を受付けた検索クエリをネットワークを介して検索クエリ取得部に送信する処理を行う。
【００４５】
（検索結果表示部の具体的な処理）
ＣＰＵは、記憶装置から「検索結果表示プログラム」０８６０をメインメモリに読み出して実行し、検索実行プログラムの実行により得られた情報を受信し、当該受信結果を表示出力する処理を行う。
【００４６】
<処理の流れ>
図９は、本実施形態のデータベース検索システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０９０１では、被検索の可否を示す検索可否属性を付与された被検索データ群を格納する（データ群格納ステップ）。次にステップＳ０９０２では、データ権限者端末より当該データ権限者がデータ権限を有する被検索データを検索対象とするか否かを定めるための情報である検索可否情報を取得する（検索可否情報取得ステップ）。ステップＳ０９０３では、外部端末より検索クエリが送信されたかどうかを判断する。ここでの判断結果が送信されたとの内容であれば、ステップＳ０９０４として当該送信された検索クエリを取得する（検索クエリ取得ステップ）。判断結果が送信されていないとの内容であれば、送信されたとの判断結果になるまでステップＳ０９０３の処理を続ける。
【００４７】
ステップＳ０９０５では、検索可否情報に基づいて検索可否属性を書き換え、当該書き換えられた検索可否属性と、検索クエリと、に基づいて格納された全被検索データ群の検索を実行する（検索実行ステップ）。そしてステップＳ０９０６では、外部端末にて検索実行ステップの結果得られた検索結果を表示する（検索結果表示ステップ）。
【００４８】
図１０は、本実施形態のデータベース検索システムにおける処理の流れの別の一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ１００１では、被検索の可否を示す検索可否属性を付与された被検索データ群を格納する（データ群格納ステップ）。ステップＳ１００２では、外部端末より検索クエリが送信されたかどうかを判断する。ここでの判断結果が送信されたとの内容であれば、ステップＳ１００３として当該送信された検索クエリを取得する（検索クエリ取得ステップ）。判断結果が送信されていないとの内容であれば、送信されたとの判断結果になるまでステップＳ１００２の処理を続ける。
【００４９】
次にステップＳ１００４では、データ権限者端末より当該データ権限者がデータ権限を有する被検索データを検索対象とするか否かを定めるための情報である検索可否情報を取得する（検索可否情報取得ステップ）。ステップＳ１００５では、検索可否情報に基づいて検索可否属性を書き換え、当該書き換えられた検索可否属性と、検索クエリと、に基づいて格納された全被検索データ群の検索を実行する（検索実行ステップ）。そしてステップＳ１００６では、外部端末にて検索実行ステップの結果得られた検索結果を表示する（検索結果表示ステップ）。
【００５０】
<効果>
以上の構成を有する被検索拒否可能データベースと外部端末を用いたデータベース検索システムを利用することにより、データベースを構成する情報に一定の権限を有する者が当該各情報の利用を主体的かつ機動的にコントロールすることが可能になる。
【００５１】
<<実施形態２>>
<概要>
【００５２】
本実施形態の被検索拒否可能データベースは、基本的に実施形態１のデータベース検索システムの被検索拒否可能データベースと同様であるが、検索クエリ取得の際にクエリ属性と関連付けて取得するとともに、検索可否情報取得の際に、検索の実行に際して検索クエリに関連付けられたクエリ属性に応じて被検索データを検索対象とするか否かを定めうる情報である属性依存検索可否情報を取得する点をさらなる特徴として備えている。当該構成を採用することにより、データ権限者の詳細なニーズに応じた被検索データ利用のコントロールが実現可能になる。
【００５３】
<機能的構成>
図１１は、本実施形態の被検索拒否可能データベースの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「被検索拒否可能データベース」１１１０は、「データ群格納部」１１１１と、「検索クエリ取得部」１１１２と、「検索可否情報取得部」１１１３と、「検索実行部」１１１４と、を有し、「検索クエリ取得部」は「属性付検索クエリ取得手段」１１１５を、「検索可否情報取得部」は「属性依存検索可否情報取得手段」１１１６を、それぞれ有する。基本的な構成は実施形態１の図２を用いて説明した被検索拒否可能データベースと共通するため、以下では相違点である「属性付検索クエリ取得手段」および「属性依存検索可否情報取得手段」の機能について説明する。
【００５４】
「属性付検索クエリ取得手段」１１１５は、検索クエリ取得部において検索クエリをクエリ属性と関連付けて取得するように構成される。「クエリ属性」とは、検索クエリと検索対象となり得る被検索データとの間の関連性を示すための属性情報で、具体的には、検索クエリの入力回数や検索者数、入力時間帯、被検索データの検索拒否率の高低その他検索クエリの利用態様を示す少なくとも一の情報からなる。クエリ属性は検索拒否可能データベースにおいて保持されるところ、検索クエリを取得する都度あるいは一定時間間隔ごとに更新され、より直近に実行された検索が反映されて保持されることが望ましい。当該構成をとることにより、取得した検索クエリに誤字があったり、曖昧な文言であった場合であっても、検索者の意に沿った好適な検索を実行することが可能になる。
【００５５】
上記好適な検索を実行するため、クエリ属性は一の検索クエリに対し複数関連付けられていることが好ましく、さらに言えば、複数のクエリ属性を一のグループにまとめ、それぞれのグループを検索クエリと関連付けてもよい。図１２は、本実施形態の被検索拒否可能データベースにて検索クエリと関連付けて取得されるクエリ属性の一例を示した図である。同図においては、「ドリーム」「木上工務店」という架空の事業者名を検索クエリとして明示している。当該各検索クエリに対応して、「クエリ属性１」では業者の事業形態や事業内容、事業の規模や歴史など当該取引業者に関する情報を、「クエリ属性２」では月末払いや銀行振込みなど取引代金の支払状況に関する情報がそれぞれクエリ属性として取得される。また、「クエリ属性３」には当該検索クエリにより検索される被検索データを検索対象に含めるか否かにつき、データ権限者による拒否の割合の高低がクエリ属性として示されている。当該構成を採用することにより、複合的な検索クエリによって検索される被検索データのもつ様々な側面に応じた検索結果を抽出することが可能になる。
【００５６】
「属性依存検索可否情報取得手段」１１１６は、検索可否情報取得部において、検索の実行に際して検索クエリに関連付けられたクエリ属性に応じて被検索データを検索対象とするか否かを定める情報である属性依存検索可否情報を取得するように構成される。「クエリ属性に応じて」とは、検索可否情報の取得にあたりクエリ属性との関係を参照することを意味している。図１２を用いて説明した上記例の場合であれば、特定の検索クエリに対応した検索可否情報を取得する際であっても、クエリ属性に応じて検索対象とするか否かを区別するような場合が考えられる。検索クエリがクエリ属性１との関係において取得された場合には検索対象とすることを可とし、クエリ属性２との関係において取得された場合には検索対象とすることを拒否することが考えられる。当該構成をとることにより、データ権限者は、データベースの有効性を過度に損なうことなく自身の守りたい分野においてのみ被検索データの利用を制限することができる。
【００５７】
<具体的な構成>
本実施形態の被検索拒否可能データベースを構成する各装置のハードウェア構成は、基本的には図７を用いて説明した実施形態１の被検索拒否可能データベースを構成するハードウェア構成と同様である。そこで以下では、これまで説明していない「属性付検索クエリ取得手段」および「属性依存検索可否情報取得手段」の具体的な処理について説明する。
【００５８】
（属性付検索クエリ取得手段の具体的な処理）
ＣＰＵは、記憶装置から「属性付検索クエリ取得サブプログラム」をメインメモリに読み出し検索クエリ取得プログラムとともに実行し、被検索データに対する検索クエリを受信する際、あわせてクエリ属性情報も受信して前記両情報を関連付ける処理を行い、当該処理結果をメインメモリの所定のアドレスに格納する。
【００５９】
（属性依存検索可否情報取得手段の具体的な処理）
ＣＰＵは、記憶装置から「属性依存検索可否情報取得サブプログラム」をメインメモリに読み出し検索可否情報取得プログラムとともに実行し、前記クエリ属性に応じた属性依存検索可否情報を取得し、当該情報をメインメモリの所定のアドレスに格納する。
【００６０】
<処理の流れ>
図１３は、本実施形態の被検索拒否可能データベースの処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ１３０１では、被検索の可否を示す検索可否属性を付与された被検索データ群を格納する（データ群格納ステップ）。ステップＳ１３０２では、外部端末より検索クエリが送信されたかどうかを判断する。ここでの判断結果が送信されたとの内容であれば、ステップＳ１３０３として当該送信された検索クエリをクエリ属性とともに取得する（属性付検索クエリ取得ステップ）。判断結果が送信されていないとの内容であれば、送信されたとの判断結果になるまでステップＳ１３０２の処理を続ける。
【００６１】
次にステップＳ１３０４では、データ権限者端末より当該データ権限者がデータ権限を有する被検索データを検索対象とするか否かを定めるための情報である検索可否情報をクエリ属性と関連付けて取得する（属性依存検索可否情報取得ステップ）。ステップＳ１３０５では、ステップＳ１３０４で取得した属性依存検索可否情報に基づいて検索可否属性を書き換え、当該書き換えられた検索可否属性と、検索クエリと、に基づいて格納された全被検索データ群の検索を実行する（検索実行ステップ）。
【００６２】
<効果>
以上の構成を有する被検索拒否可能データベースを利用することにより、データ権限者の詳細なニーズに応じた被検索データ利用のコントロールが実現可能になる。
【００６３】
<<実施形態３>>
<概要>
【００６４】
本実施形態の被検索拒否可能データベースは、基本的に実施形態１又は２の被検索拒否可能データベースと同様であるが、検索クエリとして取得すべき検索クエリを登録し、登録された検索クエリに関連する情報を含む検索可否問合情報を前記データ権限者に送信するとともに、前記送信された検索可否問合情報に応じた検索可否情報を含む返信を受信すると当該返信に含まれる検索可否情報を検索可否情報取得部に出力する点をさらなる特徴として備えている。当該構成を採用することにより、データ権限者は検索クエリを通じた検索者の意図をある程度把握可能な状態で検索対象とするか否かを検討することができるので、よりデータ権限者の意向を反映させた検索を実行することが可能になる。
【００６５】
<機能的構成>
図１４は、本実施形態の被検索拒否可能データベースの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「被検索拒否可能データベース」１４１０は、「データ群格納部」１４１１と、「検索クエリ取得部」１４１２と、「検索可否情報取得部」１４１３と、「検索実行部」１４１４と、「検索クエリ登録部」１４１５と、「検索可否問合情報送信部」１４１６と、「返信受信部」１４１７と、「返信出力部」１４１８と、を有する。基本的な構成は実施形態１の図２を用いて説明した被検索拒否可能データベースと共通するため、以下では相違点である「検索クエリ登録部」、「検索可否問合情報送信部」、「返信受信部」、そして「返信出力部」について説明する。
【００６６】
「検索クエリ登録部」１４１５は、検索クエリとして取得すべき検索クエリを登録するように構成される。誤字や脱字のように、検索クエリが常に内容把握が十分な形式にて入力されるとは限らないため、入力された検索クエリに対応し、その内容が十分に把握可能な文言を「検索クエリとして取得すべき検索クエリ」として登録しておく。このような構成をとることによって、検索者のニーズを漏らすことなく抽出し、好適な検索結果を抽出することを可能にする。
【００６７】
なおここで、図１５を用いて検索クエリ登録の具体的な一例を説明する。同図においては、取得すべき検索クエリとして「山上商店」と取得され得る検索クエリ「山上」「やまがみ」「やまうえ」等を関連付けて登録している。検索クエリ相互が所定割合（例えば８０％）以上一致していれば、当該入力された検索クエリを「検索クエリとして取得すべき検索クエリ」として処理する。
【００６８】
「検索可否問合情報送信部」１４１６は、登録された検索クエリに関連する情報を含む検索可否問合情報を前記データ権限者に送信するように構成される。「登録された検索クエリに関連する情報」とは、登録された検索クエリのほか、当該検索クエリを入力した検索者のユーザＩＤ、当該検索クエリが入力された日時、検索者が検索クエリを入力した目的（当該目的が把握可能な場合）等検索クエリの入力に関する情報のほか、過去に当該検索クエリを入力したことのある他の検索者のユーザＩＤや、当該他の検索者に対する検索可否情報の内容等、他の検索者に対する検索可否情報に関連する情報などが考えられる。これらの情報をあわせて受信したデータ権限者は、当該情報を検索可否情報を送信する際の判断材料とすることが可能になる。
【００６９】
「返信受信部」１４１７は、前記送信された検索可否問合情報に応じた検索可否情報を含む返信を受信するように構成される。ここでいう「返信」は検索可否情報のほか、同情報が送信された日時など当該検索可否情報を他の検索可否情報と識別するための情報を含む。当該構成をとることにより、一の被検索データに対し複数の検索可否情報を受信した場合に、検索可否情報相互の優劣関係を明確にすることが可能になる。
【００７０】
「返信出力部」１４１８は、受信した返信に含まれる検索可否情報を検索可否情報取得部に出力するように構成される。当該構成をとることにより、事前に検索可否情報を送信していなかったとしても、特定の検索クエリを用いた検索に関し、適宜検索対象に含むか否かの判断を行うことができるようになるため、検索時期や検索者の属性を吟味したうえで柔軟に検索の可否を判断することが可能になる。
【００７１】
<具体的な構成>
本実施形態の被検索拒否可能データベースを構成する各装置のハードウェア構成は、基本的には図７を用いて説明した実施形態１の被検索拒否可能データベースを構成するハードウェア構成と同様であるので、以下では、これまで説明していない「検索クエリ登録部」、「検索可否問合情報送信部」、「返信受信部」、そして「返信出力部」の具体的な処理について説明する。
【００７２】
（検索クエリ登録部の具体的な処理）
ＣＰＵは、記憶装置から「検索クエリ登録プログラム」をメインメモリに読み出して実行し、所定のキーワードの入力を受付け、他のキーワードを当該所定のキーワードとして取得するための文言の一致率とともにこれを検索クエリとして登録し、それぞれメインメモリの所定のアドレスに格納する。
【００７３】
（検索可否問合情報送信部の具体的な処理）
ＣＰＵは、記憶装置から「検索可否問合情報送信プログラム」をメインメモリに読み出して実行し、前記登録された検索クエリに関連する情報を含む検索可否問合情報を生成し、データ権限者側端末に対し、当該検索可否問合情報を送信する。
【００７４】
（返信受信部の具体的な処理）
ＣＰＵは、記憶装置から「返信受信プログラム」をメインメモリに読み出して実行し、前記送信した検索可否問合情報に応じた検索可否情報を含む返信を受信する。
【００７５】
（返信出力部の具体的な処理）
ＣＰＵは、記憶装置から「返信出力プログラム」をメインメモリに読み出して実行し、前記返信受信プログラムの実行により得られた検索可否情報を、検索可否情報出力部に対し出力する処理を行う。
【００７６】
<処理の流れ>
図１６は、本実施形態の被検索拒否可能データベースの処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ１６０１では、被検索の可否を示す検索可否属性を付与された被検索データ群を格納する（データ群格納ステップ）。ステップＳ１６０２では、外部端末より検索クエリが送信されたかどうかを判断する。ここでの判断結果が送信されたとの内容であれば、ステップＳ１６０３として当該送信された検索クエリを取得する（検索クエリ取得ステップ）。判断結果が送信されていないとの内容であれば、送信されたとの判断結果になるまでステップＳ１６０２の処理を続ける。なおこのとき、ステップＳ１６０４として、検索クエリとして取得すべき検索クエリを登録する（検索クエリ登録ステップ）。
【００７７】
次にステップＳ１６０５では、登録された検索クエリに関連する情報を含む検索可否問合情報をデータ権限者に送信する（検索可否問合情報送信ステップ）。そしてステップＳ１６０６にて検索可否情報を受信するとステップＳ１６０７ではデータ権限者端末より検索可否情報を取得する（検索可否情報取得ステップ）。ステップＳ１６０８では、検索可否情報に基づいて検索可否属性を書き換え、当該書き換えられた検索可否属性と、検索クエリと、に基づいて格納された全被検索データ群の検索を実行する（検索実行ステップ）。
【００７８】
<効果>
以上の構成を有する被検索拒否可能データベースを利用することにより、実施形態１あるいは２において説明した効果のほか、よりデータ権限者の意向を的確に反映させた母集団のもとで検索を行うことが可能になる。
【００７９】
<<実施形態４>>
<概要>
【００８０】
本実施形態の被検索拒否可能データベースは、基本的に実施形態１から３のいずれか一の被検索拒否可能データベースと同様であるが、所定のデータについて複数のデータ権限者からの複数の検索可否情報を取得し、前記複数の検索可否情報に基づいて当該データが検索可とできるか判断する点をさらなる特徴として備えている。当該構成を採用することにより、複数人にとって関心のあるデータを適切に管理することが可能になる。
【００８１】
<機能的構成>
図１７は、本実施形態の被検索拒否可能データベースの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「被検索拒否可能データベース」１７１０は、「データ群格納部」１７１１と、「検索クエリ取得部」１７１２と、「検索可否情報取得部」１７１３と、「検索実行部」１７１４と、を有し、「検索可否情報取得部」は「複数取得手段」１７１５を、「検索実行部」は「複数時判断手段」１７１６を有する。基本的な構成は実施形態１の図２を用いて説明した被検索拒否可能データベースと共通するため、以下では相違点である「複数取得手段」および「複数時判断手段」の機能について説明する。
【００８２】
「複数取得手段」１７１５は、所定の被検索データについて複数のデータ権限者からの複数の検索可否情報を取得するように構成される。ここでいう「所定の被検索データ」にはデータ群格納部に格納される全ての被検索データが含まれ、そのデータ量の多寡は特に問わない。したがって、複数のデータ権限者が一の被検索データに対してのみデータ権限を有していることもあれば、複数のデータ権限者が複数の被検索データ群のそれぞれについてデータ権限を有していることもある。
一例を挙げると、家族のプロフィールに関するデータが被検索データ群として格納されている場合、未成年の子どもに関する被検索データについては、当該子どもに加え両親の計３名がデータ権限者となることが考えられる。子ども以外の両親２名のみがデータ権限者になってもよい。当該構成をとることにより、より保護の要請が強いといえるような被検索データに対し、当該被検索データの属性や検索者の需要に応じた保護を行うことが可能になる。
【００８３】
「複数時判断手段」１７１６は、前記複数の検索可否情報に基づいて当該被検索データが検索可とできるか判断するように構成される。「前記複数の検索可否情報に基づいて」とは、被検索データに付与された検索可否属性を書き換えるか否かの判断を複数の検索可否情報の内容に応じておこなうことを意味しており、必ずしも複数の検索可否情報が全て「検索可とする」旨の情報である必要はない。家族のプロフィールに関するデータの場合であれば、両親双方から所定時間内に「検索可とする」旨の情報を受信しない限り、子ども本人から「検索可とする」旨の情報を受信していても、検索可否属性を書き換えて当該子どもに関するデータは検索対象から外すように構成してもよい。
【００８４】
<具体的な構成>
本実施形態の被検索拒否可能データベースのハードウェア構成は、基本的には図７を用いて説明した実施形態１の被検索拒否可能データベースのハードウェア構成と同様であるので、以下では、これまで説明していない「複数取得手段」および「複数時判断手段」の具体的な処理について説明する。
【００８５】
（複数取得手段の具体的な処理）
ＣＰＵは、記憶装置から「複数取得サブプログラム」をメインメモリに読み出し検索可否情報取得プログラムとともに実行し、対応する所定の被検索データと関連付けられた複数のデータ権限者から送信された検索可否情報を受信し、当該各情報を前記所定の被検索データと関連付けてメインメモリの所定のアドレスに格納する。
【００８６】
（複数時判断手段の具体的な処理）
ＣＰＵは、記憶装置から「複数時判断サブプログラム」をメインメモリに読み出して検索実行プログラムとともに実行し、前記取得した複数の検索可否情報を所定のテーブルに適用し、検索可と判断できる被検索データ群を対象とし、検索クエリ取得プログラムの実行により得られた検索クエリに基づいた検索処理を実行する。
【００８７】
<処理の流れ>
図１８は、本実施形態の被検索拒否可能データベースの処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ１８０１では、被検索の可否を示す検索可否属性を付与された被検索データ群を格納する（データ群格納ステップ）。ステップＳ１８０２では、外部端末より検索クエリが送信されたかどうかを判断する。ここでの判断結果が送信されたとの内容であれば、ステップＳ１８０３として当該送信された検索クエリを取得する（検索クエリ取得ステップ）。判断結果が送信されていないとの内容であれば、送信されたとの判断結果になるまでステップＳ１８０２の処理を続ける。
【００８８】
次にステップＳ１８０４では、各データ権限者端末より各データ権限者がデータ権限を有する被検索データを検索対象とするか否かを定めるための検索可否情報を複数取得する（複数検索可否情報取得ステップ）。ステップＳ１８０５では、複数の検索可否情報に基づいて検索可否属性を書き換え、当該書き換えられた検索可否属性と、検索クエリと、に基づいて格納された全被検索データ群の検索を実行する（複数時判断検索実行ステップ）。
【００８９】
<効果>
以上の構成を有する被検索拒否可能データベースを利用することにより、実施形態１、２あるいは３において説明した効果のほか、複数人にとって関心のあるデータを適切に管理することが可能になる。
【００９０】
<<実施形態５>>
<概要>
【００９１】
本実施形態の被検索拒否可能データベースは、基本的に実施形態１から４のいずれか一に記載の被検索拒否可能データベースと同様であるが、格納されている検索可能な被検索データと検索不能な被検索データとの被検索データ差分情報を出力する点をさらなる特徴として備えている。当該構成を採用することにより、被検索データの検索者のみならず、データ権限者の属性などを別のデータとして抽出し利用することも可能になる。
【００９２】
<機能的構成>
図１９は、本実施形態の被検索拒否可能データベースの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「被検索拒否可能データベース」１９１０は、「データ群格納部」１９１１と、「検索クエリ取得部」１９１２と、「検索可否情報取得部」１９１３と、「検索実行部」１９１４と、「差分情報出力部」１９１５と、を有する。基本的な構成は実施形態１の図２を用いて説明した被検索拒否可能データベースと共通するため、以下では相違点である「差分情報出力部」について説明する。
【００９３】
「差分情報出力部」１９１５は、データ群格納部に格納されている検索可能な被検索データと検索不能な被検索データとの被検索データの差分情報を出力するように構成される。検索可能な被検索データと検索不能な被検索データとの関連を示す情報であれば、ここでいう「データ群格納部に格納されている検索可能な被検索データと検索不能な被検索データとの差分情報」に含まれる。従って例えば、上記両被検索データのデータ量の差分や検索対象となり得る被検索データ群に対する各被検索データ群の差分などのほか、検索対象となり得る被検索データ群に対する各被検索データ群の割合、各検索可否情報を送信したデータ権限者の数などもここでいう差分情報に含まれる。さらに詳細に、検索可能な被検索データ群と検索不能な被検索データ群とを構成する各被検索データの属性に応じて生成される情報もここでいう差分情報に含まれうる。例えば、検索可能な被検索データと検索不能な被検索データの割合を、各被検索データの更新日時毎やデータ権限者の年齢層ごと、性別、地域別、職業別などに区分してもよい。当該差分情報はデータ検索そのものには利用することはできないが、個々のデータの内容に焦点を当てるのではなく、あくまで統計値として生成されるに過ぎない。そのため、当該構成をとることにより、被検索データを検索不可とするデータ権限者の意向を酌みつつ、全く別個の性質を有する統計的情報を需要者に対して提供することが可能になる。
【００９４】
<具体的な構成>
本実施形態の被検索拒否可能データベースのハードウェア構成は、基本的には図７を用いて説明した実施形態１の被検索拒否可能データベースを構成するハードウェア構成と同様であるので、以下では、これまで説明していない「差分情報出力部」の具体的な処理について説明する。
【００９５】
（差分情報出力部の具体的な処理）
ＣＰＵは、記憶装置から「差分情報出力プログラム」をメインメモリに読み出して実行し、データ格納プログラムの実行により得られた全ての被検索データ群と、検索可否情報取得プログラムの実行により得られた検索可否情報に基づいて検索対象に含めないとされた被検索データとの差分情報を生成し、当該差分情報を出力する。
【００９６】
<処理の流れ>
図２０は、本実施形態の被検索拒否可能データベースの処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ２００１では、被検索の可否を示す検索可否属性を付与された被検索データ群を格納する（データ群格納ステップ）。ステップＳ２００２では、外部端末より検索クエリが送信されたかどうかを判断する。ここでの判断結果が送信されたとの内容であれば、ステップＳ２００３として当該送信された検索クエリを取得する（検索クエリ取得ステップ）。判断結果が送信されていないとの内容であれば、送信されたとの判断結果になるまでステップＳ２００２の処理を続ける。
【００９７】
次にステップＳ２００４では、データ権限者端末より当該データ権限者がデータ権限を有する被検索データを検索対象とするか否かを定めるための情報である検索可否情報を取得する（検索可否情報取得ステップ）。ステップＳ２００５では、データ群格納部に格納された検索可能な被検索データと検索不能な被検索データとの差分情報を出力する（差分情報出力ステップ）。そしてステップＳ２００６では、検索可否情報に基づいて検索可否属性を書き換え、当該書き換えられた検索可否属性と、検索クエリと、に基づいて格納された全被検索データ群の検索を実行する（検索実行ステップ）。なおここで、差分情報出力ステップと検索実行ステップの順番は相互に入れ替わっていてもよい。
【００９８】
<効果>
以上の構成を有する被検索拒否可能データベースを利用することにより、実施形態１ないし４において説明した効果のほか、検索者に対し検索の実効性を把握させることができる。
【００９９】
<<実施形態６>>
<概要>
【０１００】
本実施形態の被検索拒否可能データベースは、基本的に実施形態５の被検索拒否可能データベースと同様であるが、差分情報と検索実行可・不可を定める可・不可テーブルを保持し、前記差分情報と前記可・不可テーブルとに基づいて検索実行部を制御する点をさらなる特徴として備えている。当該構成を採用することにより、検索可否情報の内容如何によって、当該データベース利用の実効性が失われる事態を回避することが可能になる。
【０１０１】
<機能的構成>
図２１は、本実施形態の被検索拒否可能データベースの機能ブロックの一例を示す図である。この図にあるように、本実施形態の「被検索拒否可能データベース」２１１０は、「データ群格納部」２１１１と、「検索クエリ取得部」２１１２と、「検索可否情報取得部」２１１３と、「検索実行部」２１１４と、「差分情報出力部」２１１５と、「可・不可テーブル保持部」２１１６と、「制御部」２１１７と、を有する。基本的な構成は実施形態５の図１９を用いて説明した被検索拒否可能データベースと共通するため、以下では相違点である「可・不可テーブル保持部」および「制御部」の機能について説明する。
【０１０２】
「可・不可テーブル保持部」２１１６は、前記差分情報と検索実行可・不可を定める可・不可テーブルを保持するように構成される。ここでいう「検索実行可・不可を定める可・不可テーブル」は、検索を実行するか否かを判断するためのテーブルであり被検索データ群を検索対象に含めるか否かの判断とは関連しない。
【０１０３】
可・不可テーブルは前記差分情報との関係において構成される。具体的なテーブルの構成例としては、差分情報に含まれる検索不能な被検索データのデータ量が所定量以上であれば「検索実行不可」、すなわち検索を実行しないとの処理を行い、所定量を下回るようであれば「検索実行可」、すなわち検索を実行するとの処理を行うような構成とすることが考えられる。
【０１０４】
本実施形態の検索拒否可能データベースを利用する際、あまりに検索不能となる被検索データ群が多くなると、検索を実行した結果得られる情報が有用な内容とならない可能性もある。このことは、多種多様な情報を管理し好適な情報収集のツールとしての機能を期待されるデータベースに対する検索者の信頼性を損なうことにつながる。そのような場合、本実施形態の構成をとることにより、敢えて検索結果を出力するのではなく、一定の場合に検索の実行自体を行わないことにより、結果としてデータベース全体の信頼性を確保することが一定程度可能になる。
【０１０５】
ここで、図２２を示して可・不可テーブルの一例を説明する。同図に示されているのは、検索対象となりうる全ての被検索データ群のうち検索不能な被検索データ群の割合と、当該割合に応じた検索実行可・不可を定める可・不可テーブルの一例である。同図にあるように、例えば、検索対象となりうる全ての被検索データ群のうち検索不能な被検索データ群の割合が２５％程度であればそのまま検索を実行し、２５〜５５％程度になると、検索を実行した結果得られる情報に一定の疑義が生じうるような内容を警告する表示を行い、それでも検索者から検索を実行するとの指示入力を受けた場合に限り検索を実行する。ただ、上記割合が５５％を超えるような事態になれば、検索実行の結果得られる情報に対する信頼性に疑義が生じる可能性が極めて高いとして、検索を実行しない（検索を不可とする）。
【０１０６】
「制御部」２１１７は、前記差分情報と前記可・不可テーブルとに基づいて検索実行部を制御するように構成される。ここでいう「前記差分情報と前記可・不可テーブルとに基づいて」とは、既に説明したように、差分情報の内容を可・不可テーブルに対応させることによって検索実行部にて検索を実行するか否かの判断処理を行うことを意味している。
【０１０７】
<具体的な構成>
本実施形態の被検索拒否可能データベースのハードウェア構成は、基本的には図７を用いて説明した実施形態５の被検索拒否可能データベースのハードウェア構成と同様であるので、以下では、これまで説明していない「可・不可テーブル保持部」および「制御部」の具体的な処理について説明する。
【０１０８】
ＣＰＵは、記憶装置から「可・不可テーブル格納プログラム」をメインメモリに読み出して実行し、検索実行の可否を制御するための判断を行う際に用いるテーブルの入力を受付ける処理を行い、当該処理結果をメインメモリの所定のアドレスに格納する。
【０１０９】
（制御部の具体的な処理）
ＣＰＵは、記憶装置から「制御プログラム」をメインメモリに読み出して実行し、前記差分情報出力プログラムの実行により得られた差分情報を可・不可テーブルに適用する処理を行い、当該処理結果に応じて検索実行プログラムの制御処理を実行する。
【０１１０】
<処理の流れ>
図２３は、本実施形態の被検索拒否可能データベースの処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ２３０１では、被検索の可否を示す検索可否属性を付与された被検索データ群を格納する（データ群格納ステップ）。ステップＳ２３０２では、外部端末より検索クエリが送信されたかどうかを判断する。ここでの判断結果が送信されたとの内容であれば、ステップＳ２３０３として当該送信された検索クエリを取得する（検索クエリ取得ステップ）。判断結果が送信されていないとの内容であれば、送信されたとの判断結果になるまでステップＳ２３０２の処理を続ける。
【０１１１】
次にステップＳ２３０４では、データ権限者端末より当該データ権限者がデータ権限を有する被検索データを検索対象とするか否かを定めるための情報である検索可否情報を取得する（検索可否情報取得ステップ）。ステップＳ２３０５では、データ群格納部に格納された検索可能な被検索データと検索不能な被検索データとの差分情報を出力する（差分情報出力ステップ）。そしてステップＳ２３０６では、差分情報と可・不可テーブルとに基づいて検索を実行するか否かを判断する。ここでの判断結果が検索実行を可とする内容である場合には、ステップＳ２３０７として検索可否情報とに基づいて検索可否属性を書き換え、当該書き換えられた検索可否属性と、検索クエリと、に基づいて格納された全被検索データ群の検索を実行する（検索実行ステップ）。検索実行を不可とする内容である場合には、検索実行が不可である旨の情報を出力し、その後の処理を行わない。
【０１１２】
<効果>
以上の構成を有する被検索拒否可能データベースを利用することにより、実施形態５において説明した効果のほか、検索可否情報の内容如何によって、当該データベース利用の信頼性・実効性が失われる事態を回避することが可能になる。
【符号の説明】
【０１１３】
０２１０…被検索拒否可能データベース、０２１１…データ群格納部、０２１２…検索クエリ取得部、０２１３…検索可否情報取得部、０２１４…検索実行部、０２２０…外部端末、０２２１…検索クエリ送信部、０２２２…検索結果表示部
【図１】
2015138540.tif 000003
【図２】
2015138540.tif 000004
【図３】
2015138540.tif 000005
【図４】
2015138540.tif 000006
【図５】
2015138540.tif 000007
【図６】
2015138540.tif 000008
【図７】
2015138540.tif 000009
【図８】
2015138540.tif 000010
【図９】
2015138540.tif 000011
【図１０】
2015138540.tif 000012
【図１１】
2015138540.tif 000013
【図１２】
2015138540.tif 000014
【図１３】
2015138540.tif 000015
【図１４】
2015138540.tif 000016
【図１５】
2015138540.tif 000017
【図１６】
2015138540.tif 000018
【図１７】
2015138540.tif 000019
【図１８】
2015138540.tif 000020
【図１９】
2015138540.tif 000021
【図２０】
2015138540.tif 000022
【図２１】
2015138540.tif 000023
【図２２】
2015138540.tif 000024
【図２３】
2015138540.tif 000025