実施の形態1.
以下、図面を参照して、本発明の実施形態を詳細に説明する。本実施形態においては、電子化された文書を利用するシステムであって、文書を管理するサーバと、ユーザが文書を閲覧する際のユーザインタフェースとなる情報処理端末とを含むシステムを例として説明する。
図1は、本発明の実施形態に係る検索システムの全体構成を示すブロック図である。図1に示すように、本実施形態に係る検索システムは、検索部101、検索DB102、グループリスト103、タスクスケジューラ104、LDAP(Lightweight Directory Access Protocol)サーバ105、グループウェア106、ファイルサーバ107、クロール部110を含む。また、クロール部110は、文書情報取得部A111、検索用アクセス権情報計算部A112、文書情報取得部B113、検索用アクセス権情報計算部B114及びユーザ・グループ更新チェック部115を含む。
本実施形態に係る検索システムにおける検索対象のデータソースはグループウェア106及びファイルサーバ107に格納された情報である。グループウェア106及びファイルサーバ107へのアクセス権は、LDAPサーバ105において管理されるユーザ名やグループ名に従って認証される。即ち、LDAPサーバ105が、ユーザの検索システムの利用権限を認証する認証部として機能する。ここで、グループウェア106及びファイルサーバ107のアクセス権の具体例について説明する。なお、以下の説明において、文書やファイルのアクセス権としては、作成や更新、削除、読み取りなどさまざまなものがあるが、本発明では、文書やファイルからは情報を読み出すだけであるため、読み取り権のみを扱うものとする。
図2は、ファイルサーバ107に格納された情報を示す。図2において、“aaa.bbb.ccc.com”は、ファイルサーバのネットワーク上のアドレスを示す。また、ファイルサーバ107には、フォルダ1〜フォルダ4の4つのフォルダが含まれ、フォルダ2にファイル3、フォルダ3にファイル2、フォルダ4にファイル1が格納されている。
CIFS(Common Internet File System)のファイルサーバでは、読み取り権はネットワーク共有上の読み取り制御リストと、フォルダやファイル毎の読み取り制御リストの2種類から決定され、2つのうち厳しい方の制限が適用される。図2には、グループ1を“g1”、ユーザ1を“u1”といった値で示した読み取り制御リストが示されている。本実施形態においては、これらの“g1”、“u1”といった文字列がグループを識別するためのグループID、ユーザを識別するためのユーザIDとして用いられる。そして、“許可”や“拒否”は、それぞれ破線で関連付けられているネットワーク共有、フォルダ及びファイルについての読み取り権の有無を示す。
例えば、ネットワーク共有上の読み取り制御リストとしては、“g1”及び“g2”が“許可”であり、“u10”が“拒否”であることが設定されている。また、フォルダ1の読み取り制御リストとして、“g1”が“許可”であることが設定されている。また、ファイル1の読み取り制御リストとして、“u4”が“許可”であることが設定されている。
フォルダ・ファイルの読み取り制御リストは、複数の上位フォルダの読み取り制御リストを継承し、自身の読み取り制御リストとあわせて決定される。そのため、複数個所の読み取り制御リストを評価する必要がある。たとえばファイル1の場合、g1に属するユーザであっても、g4に属するユーザはアクセスが拒否されるが、u4のユーザは読み取りが許可される。
図3は、グループウェア106に格納された情報を示す。図3に示すように、本実施形態に係るグループウェア106は、掲示板1及び掲示板2を含み、破線で関連付けて示すように、それぞれの掲示について固有の読み取り制御リストが設定されている。また、それぞれの掲示板には、投稿文書1〜投稿文書3のように投稿文書が含まれ、それぞれの投稿文書にも読み取り制御リストが設定されている。なお、図3において、“ALL”で示されるグループは、システムにアクセス可能な全メンバーを示す。
図3に示すように、グループウェア106にはファイルサーバ107の場合と異なり、掲示板と文書以外の階層は無く、また、掲示板に対して読み取り権を持たないユーザやグループは、個別の文書に対する読み取り権限の記述によらず、掲示板内の文書を読むことはできない。すなわち、本実施例中のグループウェアは、ファイルサーバ107の仕組みであるCIFSとは異なるアクセス制御の仕組みに従って動作している。
図4は、LDAPサーバ105によるグループ及びユーザの管理態様を示す図である。図4に示すように、組織としてのbbb.ccc.comには、ou=g1及びou=g2の2つの部署があり、ou=g1にはさらに2つの部署ou=g3及びou=g4が含まれる。uid=u1〜u10はそれぞれユニークなユーザである。
検索部101は、ユーザが本実施形態に係る検索システムを利用する際のユーザインタフェースとして機能する。検索部101は、例えば、ウェブブラウザのアプリケーション・プログラムや、本実施形態に係る検索システムを利用するための専用のアプリケーション・プログラムがインストールされたPC(Personal Computer)のような情報処理端末によって構成される。
検索DB102は、検索対象であるグループウェア106及びファイルサーバ107の情報がインデックス化されて格納されたインデックス情報のデータベースである。検索DB102に格納されている情報について図5を参照して説明する。図5に示すように、本実施形態に係る検索DB102は、“文書ID”、“文書URL”、“種別”、“テキスト”、“検索用アクセス権情報”、“計算用アクセス権情報”を含む。
“文書ID”は文字列値であり、検索対象となる個別の投稿文書やファイル(以下、総じて文書とする)をユニークに示す識別子である。“文書URL”は、文字列値であり、不グループウェア106やファイルサーバ107において、文書が格納されている記憶領域をネットワークアドレスとして示す。
“種別”は文書を取得したクローラである文書情報取得部A111、文書情報取得部B113に応じた値であり、ファイルサーバ用であれば“1”、グループウェア用であれば“2”の整数値となる。“テキスト”は文字列値であり、それぞれの文書から抽出したテキストが格納されている。検索DB102内では、この“テキスト”を元にインデックスが作成されている。
“検索用アクセス権情報”には、文書の読み取り権を持つユーザのリストが、文字列の配列として格納されている。このユーザのリストは、図2、図3において説明したようにユーザについて設定された許可/拒否の値に加えて、グループについて設定された許可/拒否の値をグループに含まれるユーザに適用し、アクセス権を有するユーザのリストとして生成された情報である。即ち、本実施形態に係る“検索用アクセス権情報”はデータソースに対するアクセスを許可されたユーザの一覧を示すアクセス許可ユーザ一覧の情報である。
“計算用アクセス権情報”は文字列値である。計算用アクセス権情報には、ファイルサーバ107及びグループウェア106のそれぞれに対応する検索用アクセス権情報計算部A112、検索用アクセス権情報計算部B114が、“検索用アクセス権情報”を再計算するための計算式を示す情報が格納されている。この計算式は、図2、図3において説明したアクセス権の許可/拒否設定に従って格納されている。“計算用アクセス権情報”のフォーマットは自由であるが、ユーザ、グループを示す文字列のみは“[u1]”のように括弧でくくって表現する。換言すると、“計算用アクセス権情報”は、文書に対するアクセス権がグループID及びユーザIDによって記述されたアクセス権記述情報である。
グループリスト103は、図6に示すように、夫々のグループに含まれるユーザのリストを示す情報が格納されたデータベースであり、“グループ名”、“ユーザリスト”、“更新日時”、“ハッシュ値”の情報を含む。“グループ名”は文字列値であり、検索システムが対象とするデータソース群で利用されているグループを示す情報である。グループ名は、図4に示すLDAPサーバの管理態様における“ou”属性である。
“ユーザリストは文字列値の配列であり、そのグループに含まれる複数のユーザを示す情報を格納している。ユーザは、図4に示すLDAPサーバの管理態様における“uid”属性である。“更新日時”は、そのグループのユーザリストが最後に更新された日時を示す。“ハッシュ値”は、ユーザリストから一意に計算されるハッシュ値である。なお、グループ名の欄に“[u1]”のようにユーザ名が格納されているが、これは後述する処理の都合上の格納であり、これらのユーザ名については、ユーザリストを持たない。
タスクスケジューラ104は、クロール部110に含まれるそれぞれの構成を、予め定められたタイミングで起動する。クロール部110は、本実施形態に係る検索システムにおいて、データソースであるグループウェア106及びファイルサーバ107の情報をインデックス化して検索DB102を更新すると共に、アクセス権に応じた検索を可能とするために図5に示す“検索用アクセス権情報”を更新する。クロール部110の処理が本実施形態に係る要旨の1つである。
文書情報取得部A111および文書情報取得部B113は、それぞれファイルサーバ107、グループウェア106を対象としてデータソースである文書情報を取得し、図5に示す“文書ID”、“文書URL”、“種別”、“テキスト”、“計算用アクセス権情報”の情報を生成して格納または更新する。また、その際、文書情報取得部A111および文書情報取得部B113は、“計算用アクセス権情報”に変化のあった文書について、“検索用アクセス権情報”をNull値にすることにより、“検索用アクセス権情報”が更新されるようにする。
ユーザ・グループ更新チェック部115は、グループリスト103における“ユーザリスト”と、LDAPサーバ105中のユーザ・グループの情報との間に不一致が無いかを確認し、両者に不一致があった場合、“ユーザリスト”を更新する。また、“ユーザリスト”の更新に応じて、そのグループに関連する“検索用アクセス権情報”をNull値にすることにより、“検索用アクセス権情報”が更新されるようにする。
検索用アクセス権情報計算部AおよびBは、それぞれ、検索DB内の、ファイルサーバから取得した文書、グループウェアから取得した文書を対象として、“検索用アクセス権情報”がNull値の場合に“検索用アクセス権情報”を計算し、検索DB102を更新する。
このようなシステムにおいて、ユーザは検索部101を操作することによってまずシステムにログインした後に、検索条件等を入力して検索を行う。検索部101は、ユーザのログイン操作に応じて、LDAPサーバ105に対して認証処理を行う。検索処理においては、ユーザの操作に応じて検索条件を受け取り、認証されたユーザ名を条件に用いて検索DB102に問い合わせを行い、結果を取得し、検索結果をユーザに提示するための表示情報を生成して表示装置に表示させる。その結果、表示される検索結果は、当該ユーザがアクセス権を持つ文書だけである。
以下、本実施形態に係るシステムの動作について説明する。なお、本来、データソースから削除された文書を検索DB102から削除する処理が必要であるが、本発明の特徴となる動作を説明するために必須ではないため、以下の説明においては、文書の削除処理について説明を省略する。
まず、定期的に実行されるクロール動作について図7を参照して説明する。図7に示すように、クロール動作は大きく分けてファイルサーバ107のクロール(S701)、グループウェア106のクロール(S702)、ユーザ・グループ更新チェック(S703)、ファイルサーバ107の文書について検索用アクセス権情報計算(S704)、グループウェア106の文書について検索用アクセス権情報計算(S705)の、5つの動作を含む。
ファイルサーバ107のクロールは、文書情報取得部A111が、グループウェア106のクロールは、文書情報取得部B113が、ユーザ・グループ更新チェックはユーザ・グループ更新チェック部115が、ファイルサーバ107の文書についての検索用アクセス権情報計算は、検索用アクセス権情報計算部A112が、グループウェア106の文書についての検索用アクセス権情報計算は、検索用アクセス権情報計算部B114が、それぞれ実行する。これらの動作は、タスクスケジューラ104がクロール部110の各部を定められたスケジュールに従って起動することにより実行される。換言すると、タスクスケジューラ104は、クロール部110の各部を、図7に示すフローに従って起動する。
また、ファイルサーバ107のクロールとグループウェア106のクロールは相互に影響がなく、S701とS702とは順序を入れ替えることが可能である。さらに、検索用アクセス権情報の計算についても、S704とS705との2つの動作の順序を入れ替えることが可能である。
図8は、図7のS701におけるファイルサーバ107のクロール、すなわちタスクスケジューラ104が文書情報取得部A111を起動した際の文書情報取得部A111の動作を示すフローチャートである。図8に示すように、文書情報取得部A111は、起動後に、記憶媒体に記憶されている前回のクロール日時を取得し(S801)、設定情報として、対象ファイルサーバ、クロール用IDとパスワード、対象フォルダ一覧、対象フォルダごとの共有アクセス権を取得する(S802)。
次に、文書情報取得部A111は、取得したIDとパスワードを用いて対象とするファイルサーバにログインし(S803)、個別の対象フォルダについて順次処理を行う。それぞれのフォルダについて、文書情報取得部A111は、まず対象フォルダのファイル一覧を取得する(S804)。ここで、Windows(登録商標)のコマンドが利用可能であれば、たとえば、当該フォルダのパスを引数に「dir /a:−d /b /S」といったコマンドを実行すれば、ファイルの一覧を取得できる。
次に、文書情報取得部A111は、取得した個々の対象ファイルについて、「対象ファイル情報を検索DBに格納/更新/維持」処理、すなわち必要に応じて、検索DBに格納する、格納内容を更新する、あるいは何も更新しないといった処理を行い(S805)、全てのファイルについて処理が完了するまでS805の処理を繰り返す(S806/NO)。S805の処理については後に詳述する。
個別のファイルについての処理が終わると(S806/YES)、文書情報取得部A111は、次の対象フォルダについて、同様の処理を行う(S807/NO)。すべての対象フォルダについて処理が完了すると(S807/YES)、文書情報取得部A111は、現在日時を記憶媒体に格納し(S808)処理を終了する。格納した現在日時は、次回クロール時に上述した前回クロール日時として利用される。
以上の動作は、ファイルサーバをクロールする場合には、ほぼ一般的な動作であるが、図8のS805の詳細に本実施形態の要旨に係る動作が含まれる。図9は、図8のS805の処理の詳細を示すフローチャートである。図9に示すように、文書情報取得部A111は、S804において取得したファイルについて、図5に示す文書ID、文書URLを計算する(S901)。図5に示すように、対象ファイルの文書ID及び文書URLは、ファイルの絶対パスの先頭に“file:”を付加し、‘¥’マークを‘/’に置き換えたものである。
次に、文書情報取得部A111は、夫々の文書、即ちファイルについて、計算用アクセス権情報を生成する(S902)。計算用アクセス権情報は、ファイルサーバ107の場合、2つのアクセス権のセットから生成され、ひとつは共有のアクセス権、もうひとつは、ファイルシステムのアクセス権である。
共有のアクセス権は、クライアントからは、通常の権限で知ることはできないため、ここでは、図2において説明した通り、設定値として事前に設定された値があり、文書情報取得部A111はこれを用いる。また、ファイルシステムのアクセス権は、対象ファイルを右クリックし、“セキュリティ”タブにおいて“詳細設定”を選択した際に得られる値である。検索結果の表示において重要なアクセス権は、当該ユーザが対象ファイルを読むことを許されているか否かであるため、ファイルシステムのアクセス権からは、ユーザ名と、読み取りが可能であるか否かの情報のみを取得する。
読み取りが可能であるか否かを示す値としては、「許可・拒否とも未設定」「許可・拒否とも設定」「許可のみ設定」「拒否のみ設定」が考えられるが、このうち、「許可のみ設定」のケースでは読み取りが可能であり、それ以外は読み取り不可である。なお、読み取りが可能であるか否かの情報は、Windows(登録商標)では、上述したように“詳細設定”を選択して表示された“アクセス許可”タブにおいて、それぞれのユーザやグループを選択した上で“編集”を選択することにより表示することができる。
クロール時には、実際には、上述したようなGUI上の操作ではなく、文書情報取得部A111の機能として上述したような情報を取得するためのコマンドを用意し、文書情報取得部A111が実行する。そして、文書情報取得部A111は、読み取りが可能な場合には“+”を、不可の場合には“−”を付与し、次に、[]で囲んで記述するユーザあるいはグループ名、最後に継承元情報を、それぞれカンマで区切ってアクセス制御の記述として出力し、1つのアクセス制御の記述は{}でくくって示す。ファイルサーバの場合、図5に示すような“計算用アクセス権情報”は、以上のようにして生成される。
次に、文書情報取得部A111は、文書の最終更新日時を取得し(S903)、これを前回クロール日時と比較する(S904)。S904の比較の結果、更新日時が古く(S904/YES)、計算用アクセス権情報の変更が無い文書については(S905、S906/YES)、何も更新動作を行わない。
他方、更新日時が前回クロール日時よりも新しい場合(S904/NO)、即ち、前回クロール日時の後に文書に何らかの変更が加えられている場合、文書情報取得部A111は、文書の本分の情報を取得し(S907)、その情報を検索DB102の“テキスト”に格納する(S908)。
S908の処理の後、若しくは更新日時が前回クロール日時よりも古く、計算用アクセス権情報に変更があった場合(S906/NO)、文書情報取得部A111は、検索DB102の“計算用アクセス権情報”を、S902において生成した情報で更新し(S909)、検索DB102の“検索用アクセス権情報”をNull値とする(S910)。これによって、以降の処理で、検索用アクセス権情報の再計算が行われるようになる。
対象ファイルからテキストを抽出する処理は、doc、pdf、txt、html等の対象ファイルの種類によって様々であるが、例えばApache Tika等の公知の技術があり、これを利用することができる。
図9は、図7のS702におけるグループウェア106のクロール、すなわちタスクスケジューラ104が文書情報取得部B113を起動した際の文書情報取得部B113の動作を示すフローチャートである。グループウェア106のクロールについても、動作はファイルサーバ107の場合と基本的には同じであるが、アクセス権の扱いが異なり、本実施例で扱うグループウェアシステムでは、掲示板単位と、文書単位のアクセス権設定が存在するのみである。
このため、文書情報取得部B113は、各掲示板について、最初に掲示板のアクセス権を取得し(S1004)、その処理において、内容に変更/新規追加のあった文書のみ文書のアクセス権を取得している。図10のS1006における処理は、図9と同様であり、詳細な説明を省略する。ただし、グループウェア106の場合、計算用アクセス権情報Xの生成にあたって、処理の詳細が異なる。
計算用アクセス権情報は掲示板のアクセス権と文書のアクセス権のみから、継承関係も無く生成されるため、計算用アクセス権情報として格納される値は、図5に示すように簡単な形態になる。また、“ALL”というグループのみはLDAPサーバ105において記載のない特別なグループであり、グループウェアシステムに固有である。そのため、文書情報取得部B113は、“ALL”という文字列を“計算用アクセス権情報”には格納するが、図5に示すように[]で括らず、グループとしては扱わない。
以上、述べたような動作のうち、計算用アクセス権情報の生成については、生成された計算用アクセス権情報の文字列は、「グループ名が識別できること」、「検索用アクセス権情報計算部A112、検索用アクセス権情報計算部B114が計算用アクセス権情報とグループリストを用いて検索用アクセス権情報を計算可能であること」が満たされれば、文字列のフォーマットはいかなる形態でも良い。
図11は、図7のS703におけるユーザ・グループ更新チェック動作を示すフローチャートである。ファイルサーバ107及びグループウェア106のクロールが完了すると、タスクスケジューラ104の処理によりユーザ・グループ更新チェック部115が起動し、図11に示す動作が開始される。
ユーザ・グループ更新チェック部115は、まず、前回保存済の前回クロール日時を取得し(S1101)、次に、ユーザ・グループ更新チェック部115は、グループリスト103に新しいグループ名を追加する(S1102)。さらに、ユーザ・グループ更新チェック部115は、追加されたグループ名も含め、LDAPへの問い合わせを行い、グループリスト全体を更新する(S1103)。次いで、ユーザ・グループ更新チェック部115は、更新されたグループリストとつき合わせて、検索DB102をチェックし、検索用アクセス権情報を更新する必要のある文書について、検索用アクセス権情報の値をNull値に設定する(S1104)。最後に、ユーザ・グループ更新チェック部115は、現在日時を格納する(S1105)。
次に、図11のS1102の処理の詳細について、図12を参照して説明する。図12に示すように、ユーザ・グループ更新チェック部115は、検索DB102の個々の文書の計算用アクセス権情報を参照し、[]で囲まれた文字列をグループ名として抽出する(S1201)。そして、ユーザ・グループ更新チェック部115は、抽出したグループ名がグループリスト103中に存在しなければ(S1202/NO)、これをグループリストに追加する(S1203)。
なお、ユーザ・グループ更新チェック部115は、グループ名をグループリスト103に追加する際、更新日時の項目に0(日時にして1970年1月1日0時0分)を、ユーザリストはNull値とし、ハッシュ値には0を格納する。ユーザ・グループ更新チェック部115は、検索DB102に格納されている全ての計算用アクセス権情報について、S1201〜S1203の処理を繰り返し(S1204/NO)、全ての計算用アクセス権情報についてS1201〜S1203の処理が完了したら(S1204/YES)、処理を終了する。
次に、図11のS1103の処理の詳細について、図13を参照して説明する。図13に示すように、ユーザ・グループ更新チェック部115は、グループリスト103中の個々のそれぞれのグループ名“G”について、図4において説明したようなLDAPサーバ105による管理情報からou=“G”となるエントリを抽出し、当該エントリにuidが存在すればこれを次々に取得し、取得したuidのリストをもってユーザ名一覧とする(S1301)。
次に、ユーザ・グループ更新チェック部115は、取得したユーザ名一覧を用いてハッシュ値を計算する(S1302)。この際、ユーザ・グループ更新チェック部115は、ユーザ名一覧がNull値の場合は、ハッシュ値=0とする。この値を、格納済みのハッシュ値と比較し(S1303)、異なっている場合(S1303/NO)、ユーザ・グループ更新チェック部115は、グループリスト103の項目の更新を行う(S1304)。更新処理において、ユーザ・グループ更新チェック部115は、現在の日時、新しいハッシュ値、ユーザ名一覧を用いて、“更新日時”、“ハッシュ値”、“ユーザリスト”を更新する。このS1302〜S1304が、本実施形態において最も重要な処理の1つであり、この処理により、グループに含まれるユーザの一覧に変更があるか否かが確認される。
ユーザ・グループ更新チェック部115は、グループリスト103に格納されている全てのグループ名について、S1301〜S1304の処理を繰り返し(S1305/NO)、全てのグループ名についてS1301〜S1304の処理が完了したら(S1305/YES)、処理を終了する。
次に、図11のS1104の処理の詳細について、図14を参照して説明する。図14に示すように、ユーザ・グループ更新チェック部115は、検索DB102中の個々の文書について、まず、“計算用アクセス権情報”に記載された個々のグループに注目し、グループリスト103を参照して“更新日時”を取得する(S1401)。そして、ユーザ・グループ更新チェック部115は、取得した“更新日時”が、前回クロール日時よりも後であるか否かを判断する(S1402)。
S1402の判断の結果、“更新日時”が前回クロール日時よりも後であれば(S1402/YES)、即ち、グループのメンバーに変化があれば、ユーザ・グループ更新チェック部115は、“検索用アクセス権情報”をNull値とし(S1403)、検索DB102の他の文書について、S1401からの処理を繰り返す(S1405/NO)。
他方、“更新日時”が前回クロール日時よりも前であれば(S1402/NO)、即ち、グループのメンバーに変化がなければ、ユーザ・グループ更新チェック部115は、他のグループ名についてS1401からの処理を繰り返す(S1404/NO)。S1404において、選択中の“計算用アクセス権情報”に記載された個々のグループ全てについてS1401からの処理が完了していれば(S1404/YES)、ユーザ・グループ更新チェック部115は、S1405の処理に進む。
S1405において、検索DB102の全ての文書についてS1401からの処理が完了していれば(S1405/YES)、ユーザ・グループ更新チェック部115は、そのまま処理を終了する。
なお、図7のS701、S702のクロールの時点で、計算用アクセス権情報の文字列に変化がある場合、すでに検索用アクセス権情報は、図9のS910等の処理によってNull値となっている。従って、計算用アクセス権情報のグループや許可/不許可などの設定に変化があるか、あるいは設定は同じでも、グループの構成メンバーに変化があるかした場合、検索用アクセス権情報はNull値とされる。
次に、図7のS704の処理の詳細について、図15を参照して説明する。図15に示すように、検索用アクセス権情報計算部A112は、検索DB102内のすべての文書について、種別=1の文書、即ちファイルサーバ107内の文書を対象とし(S1501/NO)、文書の“検索用アクセス権情報”がNull値である場合(S1502/NO)、検索用アクセス権情報計算部A112は、共有アクセス権を有するユーザ一覧Aを計算すると共に(S1503)、ファイルに対するアクセス権を有するユーザ一覧Bを計算し(S1504)、A及びBの論理積すなわち両方のユーザ一覧に存在するユーザの一覧を“検索用アクセス権情報”として検索DB102に格納する(S1505)。
S1502の処理は、換言すると、図9のS910や図14のS1403においてアクセス権情報がNull値とされたか否かを確認する処理である。即ち、本実施形態に係る検索システムにおいては、一般的なクロール処理であるS701、S702の処理において、“検索用アクセス権情報”の更新が必要であると判断された場合に、即座に更新を実行するのではなく、更新が実行されるためのフラグ処理として“検索用アクセス権情報”をNull値とする。
そして、本実施形態に係る検索システムの特徴的な処理であるS703の処理においても、“検索用アクセス権情報”の更新が必要であると判断された場合、即座に更新を実行するのではなく、更新が実行されるためのフラグ処理として“検索用アクセス権情報”をNull値とする。そして、その後のS704、S705の処理において、上記フラグ処理を確認し、フラグ処理があれば“検索用アクセス権情報”を更新する。
なお、本実施形態においては、上記フラグ処理として、“検索用アクセス権情報”をNull値とするが、これに限らず、1ビットのフラグ情報を格納する等の他の処理でも良く、検索用アクセス権情報計算部A112、検索用アクセス権情報計算部B114が、“検索用アクセス権情報”の更新が必要であると判断可能な処理であれば良い。
このように、フラグ処理によって“検索用アクセス権情報”の更新要否を判断し、後から検索用アクセス権情報計算部A112、検索用アクセス権情報計算部B114が“検索用アクセス権情報”を更新することにより、S701、S702での処理と、S703での処理とで二重の処理が発生してしまうことを回避することができる。
検索用アクセス権情報計算部A112は、S1505の処理を終了すると、検索DB102の全ての文書についてS1501からの処理を繰り返し(S1506/NO)、検索DB102の全ての文書についてS1501からの処理を完了したら(S1506/YES)、処理を終了する。
図15のS1503の処理の詳細について、図16を参照して説明する。図16に示すように、検索用アクセス権情報計算部A112は、文字列で記述された“計算用アクセス権情報”から、まず、共有アクセス権の記述に相当する文字列Sを抽出する(S1601)。S1601の処理は、最初の“(”から、最初の“)”までの間を取り出すことによって実現される。
次に、検索用アクセス権情報計算部A112は、ユーザ一覧Aの初期値をNull値とし(S1602)、文字列Sを、さらにグループ名あるいはユーザ名単位の処理リストに分割して格納する(S1603)。この処理は、“+G”あるいは“−G”(Gはそれぞれ“+”、“−”を含まない不定長の文字列)を単位として文字列Sをサブ文字列に分割することによって実現される。
処理リストは“+G”あるいは“−G”のサブ文字列を含むが、このうち“−G”のパターンは、ユーザの集合のうち、Gに含まれるユーザはアクセスできないことを示す否定のアクセス権であるため、検索用アクセス権情報計算部A112は、“+G”のパターンのみを最初に処理し、まず否定対象となるユーザの集合を作成する。このため、処理リストを“+G”のパターンが最初に処理されるように並べ替える(S1604)。
並べ替えが終わると、検索用アクセス権情報計算部A112は、処理リストを順番に処理し、ユーザ一覧Aを更新していく。検索用アクセス権情報計算部A112は、まず、処理リスト中のグループ名あるいはユーザ名Gについてグループリスト102を参照し、ユーザリスト{g}を取得する(S1605)。{g}が取得できない場合(S1606/YES)、Gはユーザ名であるため、検索用アクセス権情報計算部A112は、ユーザリスト{g}としてメンバーGのみを持つユーザリストを設定する(S1607)。
次に、検索用アクセス権情報計算部A112は、処理リスト中の“+”あるいは“−”の文字を評価し、“+”であれば(S1608/NO)、ユーザ一覧Aに{g}を追加し(S1609)、“−”であれば(S1608/YES)、ユーザ一覧Aから{g}を削除する(S1610)。検索用アクセス権情報計算部A112は、以上の処理を処理リスト中のすべてのグループ名Gについて繰り返し(S1611/NO)、すべてのグループ名Gについて完了すると(S1611/YES)、ユーザ一覧Aが生成されて処理が終了する。
図15のS1504の処理の詳細について、図17を参照して説明する。図17に示すように、検索用アクセス権情報計算部A112は、文字列で記述された“計算用アクセス権情報”から、まず、ファイルのアクセス権の記述に相当する文字列Tを抽出する(S1701)。S1701の処理は、2番目の“(”から、2番目の“)”までの間を取り出すことによって実現される。
次に、検索用アクセス権情報計算部A112は、ユーザ一覧Bの初期値をNull値とし(S1702)、文字列Tを、さらにグループ名あるいはユーザ名単位の処理リストに分割して格納する(S1703)。この処理は、“{”から“}”までを単位として文字列Tをサブ文字列に分割することによって実現される。
処理リストは継承元の情報、“+G”あるいは“−G”のサブ文字列を含むが、このうち継承元の情報は“,”以降の文字列を取得することによって得られる。継承元が対象文書に近いほどアクセス権は優先して適用されるため、検索用アクセス権情報計算部A112は、まず、処理リストを、継承元の文字列が短いもの(対象文書から遠い継承元)から長いもの(対象文書に近い継承元)の順に並べ替える(S1704)。例外として“継承なし”の処理リストは対象文書に直接付与されたアクセス権であるため、並べ替えの末尾に配置する。
さらに共有アクセス権と同様、“−G”のパターンは、ユーザの集合のうち、Gに含まれるユーザはアクセスできないことを示す否定のアクセス権であるため、検索用アクセス権情報計算部A112は、処理リストを、継承元が同じであれば、“+G”のパターンが最初に処理されるように並べ替える。並べ替えが終わると、検索用アクセス権情報計算部A112は、処理リストを順番に処理し、ユーザ一覧Bを更新していく(S1705以降)。S1705以降の処理は、図16に示すS1605以降の処理と同様であるため、説明を省略する。以上の処理によって、ユーザ一覧Bが作成される。
次に、図7のS705の処理の詳細について、図18を参照して説明する。図18に示す動作はグループウェア106内の文書を対象にしているため、種別=2の判断を行っている。動作の概要は、ファイルサーバ内の文書を対象にした際と同様であるが、グループウェアに固有な“ALL”というグループの処理を行う必要があるため、一時グループリストを最初に生成している(S1801、S1802)。
S1805及びS1806のユーザ一覧の計算方法は、掲示板、投稿文書共に変わりがないため、2つで共通に用いる処理を図19に示す。処理は図16に示すファイルサーバ107における共有アクセス権の処理とほぼ同様だが、ALLの処理を行うため、グループリストではなく、一時グループリストを利用している。
このような処理により、定期的に実行されるクロール動作が完了し、図5に示すようにすべての文書について、“検索用アクセス権情報”にユーザのリストが設定される。検索を行う際、ユーザは検索部101を操作して検索システムにログインし、しかる後に検索条件を指定して検索を行う。ユーザは、ログイン時には、検索部101に、LDAPサーバ105が管理するuidおよびuserPasswordを入力する。検索部101は、uidおよびuserPasswordを用いてLDAPサーバ105に対して認証を行う。認証がOKの場合は、ログインが成立し、ユーザは検索を行うことが可能となる。
検索条件は、複数の文字列を空白で区切って入力することにより指定される。検索部101は、空白で区切られた複数の文字列W1、W2、W3・・・およびuid(仮にU1とする)を用いて、検索DB102に対して、“テキスト like ‘%W1%’ AND テキスト like ‘%W2%’ AND・・・AND ‘U1’ in 検索用アクセス権情報[]”のように、すべての文字列を含み、“検索用アクセス権情報”にログインに用いられたユーザ名であるU1があることを条件に検索する。この結果、検索部101が検索結果をユーザに提示する際に表示される検索結果は、当該ユーザがアクセス権を持つ文書だけである。
以上説明したように、本実施形態に係る検索システムによれば、図5に示すように、検索DB102においてそれぞれの文書のインデックス情報が“検索用アクセス権情報”を含むため、検索部101は、“検索用アクセス権情報”がログインに用いられたユーザ名を含むことを条件として検索するのみで、検索結果を表示するのに要する時間の増大や煩雑なアクセス権の運用管理を必要とすることなく、アクセス権に応じた検索結果を得ることが可能となる。
そして、本実施形態に係る検索システムによれば、クロール部110が定期的なクロールを実行する際に、データソースであるファイルサーバ107やグループウェア106におけるアクセス権の情報に基づいて“計算用アクセス権情報”を更新して“検索用アクセス権情報”をNull値にし(図9のS902、S909、S910)、“計算用アクセス権情報”に含まれるグループ名が新規であればグループリスト103に追加してグループリスト103を更新し(図12のS1203、図13のS1303)、更新されたグループリストに基づいて“検索用アクセス権情報”を更新する(図15のS1505、図18のS1807)。
このようなクロール部110の処理により、検索DB102における“検索用アクセス権情報”が最新の情報に保たれるため、検索部101による検索結果が、最新のアクセス権を反映した検索結果となる。また、図6に示すように、グループリスト103が“ユーザリスト”の“ハッシュ値”を含み、クロール部110がLDAPサーバ105からグループ名に対応するユーザ名の一覧を取得してハッシュ値を計算し、グループリスト103の“ハッシュ値”と比較することにより(S1303)、グループに含まれるユーザの変更有無が確認される。これにより、グループに含まれるユーザが変更された場合も“検索用アクセス権情報”が更新されるため、検索部101による検索結果が、最新のアクセス権を反映した検索結果となる。
尚、上記実施形態においては、グループリスト103の“ユーザリスト”の“ハッシュ値”と、LDAPサーバ105から取得されたグループ名に対応するユーザ名の一覧のハッシュ値とを比較することにより、グループに含まれるユーザの変更有無を確認する場合を例として説明した。これにより、比較処理における処理負荷を軽減することが可能である。しかしながら、ハッシュ値ではなく、ユーザ名の一覧そのものを比較しても良いし、ユーザ名の一覧のデータサイズ等を比較することによって、ユーザリストの異同を確認することも可能である。
実施の形態2.
図20は、図1とは異なる実施形態に係る検索システムの全体構成を示す図である。実施の形態1においては、LDAPサーバ105において管理されているユーザ及びグループに従ってアクセス権を管理する場合を例として説明した。本実施形態においては、それぞれの文書についてアクセスが許可されたユーザの組み合わせをグループとして定義することにより、定義されたグループに従ってアクセス権を管理する。
図20に示すように、本実施形態に係る検索システムは、グループリスト103に替えてグループ定義108、検索用アクセス権情報計算部A112に替えてグループ定義計算部A116、検索用アクセス権情報計算部B114に替えてグループ定義計算部B117、ユーザ・グループ更新チェック部115に替えてグループ定義検索部118を含むことが図1の態様とは異なる。
図21は、本実施形態に係る検索DB102に格納されている情報を示す図である、図21に示すように、本実施形態に係る検索DB102は、“検索用アクセス権情報”として、ユーザ名の一覧ではなく、1つのグループ名が格納されている。このため、本実施形態に係る“検索用アクセス権情報”は、配列ではなく、文字列値となる。換言すると、本実施形態に係る“検索用アクセス権情報”は、データソースに対するアクセスを許可されたユーザの一覧を識別するアクセス許可識別情報である。
図22は、本実施形態に係るグループ定義108に格納されている情報を示す図である。図22に示すように、グループ定義108は、“グループ名”、“ユーザリスト”、“種別”、“計算用アクセス権情報”を含む。図22に示す“計算用アクセス権情報”及び“種別”は、それぞれ図5において説明した情報と同様の情報である。また、“ユーザリスト”は、図6の場合と同様に、ユーザの一覧が格納された文字列の配列である。
また、本実施形態に係るタスクスケジューラ104は、図20に示す文書情報取得部111、文書情報取得部113、グループ定義計算部A116、グループ定義計算部B117及びグループ定義検索部118をそれぞれ特定のタイミングで起動する。
次に、本実施形態に係る検索システムにおいて定期的に実行されるクロール動作について図23を参照して説明する。図23に示すように、本実施形態に係るクロール動作は大きく分けてファイルサーバ107のクロール(S2301)、グループウェア106のクロール(S2302)、検索用アクセス権情報の付与(S2303)、ファイルサーバ107の文書についてユーザリストの計算(S2304)、グループウェア106の文書についてユーザリストの計算(S2305)の、5つの動作を含む。
ファイルサーバ107のクロール(S2301)、グループウェア106のクロール(S2302)は、図7のS701、S702とそれぞれ同様の動作である。検索用アクセス権情報の付与(S2303)は、図20中のグループ定義検索部118が、ファイルサーバ107の文書についてユーザリストの計算(S2304)は、グループ定義計算部A116が、グループウェア106の文書についてユーザリストの計算(S2305)は、グループ定義計算部B117が、それぞれ実行する。
図24は、図23におけるS2303の処理の詳細を示すフローチャートである。図24に示すように、グループ定義検索部118は、検索DB102内のそれぞれの文書について、“計算用アクセス権情報”を取得し(S2401)、取得した“計算用アクセス権情報”に基づいてグループ定義108を検索する(S2402)。検索により同じ“計算用アクセス権情報”を持つレコードが見つかった場合は(S2403/YES)、グループ定義検索部118は、そのレコードの“グループ名”を取得して(S2404)検索DB102の当該文書の“検索用アクセス権情報”として格納する(S2407)。
S2402の検索の結果、同一の“計算用アクセス権情報”が見つからなかった場合は(S2403/NO)、グループ定義検索部118は、グループ定義103の既存レコードに存在しないランダム文字列を新しい“グループ名”として生成し(S2405)、グループ定義103に、新しい“グループ名”でレコードを追加すると共に、そのレコードの“計算用アクセス権情報”として検索に利用した値を格納する(S2406)。この際、“ユーザリスト”はNull値とする。さらに、グループ定義検索部118は、生成した“グループ名”を、検索DB102の当該文書の“検索用アクセス権情報”として格納する(S2407)。
グループ定義検索部118は、S2401〜S2407までの処理を、検索DB102内の全ての文書について繰り返し(S2408/NO)、検索DB102内の全ての文書について完了したら(S2408/YES)、処理を終了する。
図23のS2304、S2305において、グループ定義計算部A116、グループ定義計算部B117は、それぞれ、ファイルサーバから取得した文書、グループウェアから取得した文書を対象として、グループ定義108内の“ユーザリスト”を計算し、グループ定義108を更新する。
図25は、図23におけるS2304の処理の詳細を示すフローチャートである。図25に示すように、グループ定義計算部A116によるS2104の処理は、図15の処理とほぼ同様であるが、図15においては、検索DB102内の文書を対象にしていたことに比べ、図25ではグループ定義108を対称にしていることが異なる。また、図15においては“検索用アクセス権情報”の有無を判断していたが、図25では“ユーザリスト”がすでに格納されているか否かによらず、すべてのグループについて“ユーザリスト”を格納している。
図25におけるユーザ一覧A、Bの計算処理は、それぞれ図16、17とほぼ同じである。図16、17では、ユーザリスト{g}の取り出しをグループリスト102から行っていたが、図25では、グループリスト102ではなく、LDAPサーバ105から行う。
図26は、図23におけるS2305の処理の詳細を示すフローチャートである。図26に示すように、グループ定義計算部B117によるS2305の処理は、図17とほぼ同様であるが、図17では検索DB102内の文書を対象にしていたことに比べ、図26ではグループ定義108を対象にしていることが異なる。また、図17では“検索用アクセス権情報”の有無を判断していたが、図26では“ユーザリスト”がすでに格納されているか否かによらず、すべてのグループについて“ユーザリスト”を格納している。また、図17と同じく“ALL”というグループに対応するため、処理のはじめに設定ファイルから、ALLに相当するユーザリストを読み込んでいる。
図26におけるユーザ一覧X1、X2の計算処理を図27に示す。処理は、図19とほぼ同じである。図19では、ユーザリスト{g}の取り出しを、グループリストから行っていたが、図27では、グループリストではなく、LDAPサーバ105から行う。また、LDAPサーバ105にはALLのグループが存在しないため、このグループ名を発見した際は、ユーザリストとして{ALL}を用いる。
このような処理により定期的に実行されるクロール動作が完了し、図21に示すように全ての文書について“検索用アクセス権情報”が設定されると共に、図22に示すように全ての“グループ名”について“ユーザリスト”が設定される。検索を行う際、ユーザは検索部101を操作して検索システムにログインし、しかる後に検索条件を指定して検索を行う。ユーザは、ログイン時には、検索部101に、LDAPサーバ105が管理するuidおよびuserPasswordを入力する。検索部101は、uidおよびuserPasswordを用いてLDAPサーバ105に対して認証を行う。
認証がOKの場合は、ログインが成立し、同時に検索部101は、uidを用いてグループ定義108の検索を行い、当該uidをユーザリスト内に持つグループ名の一覧G[]を取得する。G[]には、uidそのものも含まれる。この後、ユーザは検索を行うことが可能となる。
検索条件は、複数の文字列を空白で区切って入力することにより指定される。検索部101は、空白で区切られた複数の文字列W1、W2、W3・・・およびグループ名の一覧G[]を用いて、検索DB102に対して、“テキスト like ‘%W1%’ AND テキスト like ‘%W2%’ AND・・・AND 検索用アクセス権情報 in G[]”のように、すべての文字列を含み、“検索用アクセス権情報”がG[]に含まれることを条件に検索する。この結果、検索結果をユーザに提示する際に表示される検索結果は、当該ユーザがアクセス権を持つ文書だけである。
尚、実施の形態1、実施の形態2において説明した検索部101、クロール部110、LDAPサーバ105、タスクスケジューラ104並びに検索DB102、グループリスト103、グループウェア106、ファイルサーバ107およびグループ定義108は、PC等の情報処理装置によって実現される。図28を参照して、本実施形態に係る検索システム1を構成する情報処理装置のハードウェア構成について説明する。
図28に示すように、本実施形態に係る情報処理装置は、一般的なサーバやPC(Personal Computer)等と同様の構成を含む。即ち、本実施形態に係る情報処理装置は、CPU(Central Processing Unit)10、RAM(Random Access Memory)20、ROM(Read Only Memory)30、HDD(Hard Disk Drive)40及びI/F50がバス80を介して接続されている。また、I/F50にはLCD(Liquid Crystal Display)60及び操作部70が接続されている。
CPU10は演算手段であり、情報処理装置全体の動作を制御する。RAM20は、情報の高速な読み書きが可能な揮発性の記憶媒体であり、CPU10が情報を処理する際の作業領域として用いられる。ROM30は、読み出し専用の不揮発性記憶媒体であり、ファームウェア等のプログラムが格納されている。HDD40は、情報の読み書きが可能な不揮発性の記憶媒体であり、OS(Operating System)や各種の制御プログラム、アプリケーション・プログラム等が格納される。
I/F50は、バス80と各種のハードウェアやネットワーク等を接続し制御する。LCD60は、ユーザが情報処理装置の状態を確認するための視覚的ユーザインタフェースである。操作部70は、キーボードやマウス、タッチパネル等、ユーザが情報処理装置に情報を入力するためのユーザインタフェースである。なお、LDAPサーバ105やクロール部110等、本実施形態に係る検索システム1の各部はサーバとして運用される場合もあり得る。従って、LCD60及び操作部70等のユーザインタフェースは省略可能である。
このようなハードウェア構成において、ROM30やHDD40若しくは図示しない光学ディスク等の記憶媒体に格納されたプログラムがRAM20に読み出され、CPU10がそれらのプログラムに従って演算を行うことにより、ソフトウェア制御部が構成される。このようにして構成されたソフトウェア制御部と、ハードウェアとの組み合わせによって、本実施形態に係る検索システム1の各部の機能を実現する機能ブロックが構成される。特に、クロール部110の機能を実現するためのプログラムが、インデックス管理プログラムである。
尚、図1及び図20に示す検索システム1は、単一の装置によって構成される場合に限らず、ネットワークを介して接続された複数の情報処理装置によって実現される場合もある。例えば、検索部101として機能する1つのPC、検索DB102、ユーザリスト103(またはユーザ定義108)、タスクスケジューラ104及びクロール部110を含む1つのサーバ、LDAPサーバ105として機能する1つのサーバ、ファイルサーバ107として機能する1つのサーバ、グループウェア106として機能する1つのサーバによって実現される態様が考えられる。