(57)【要約】【課題】複数の文書が関連していることを示す関連情報を、各文書の秘匿性を維持したまま複数のユーザー間において共有できるようにする。【解決手段】変換処理部２２は関連文書グループごとに秘匿関連情報を生成する。秘匿関連情報は、複数の文書に対応する複数の秘匿識別データ（複数の秘匿識別値セット）で構成される。各秘匿識別値セットは、関連文書から生成された複数のハッシュ値により構成される。データベース３２上に複数の秘匿関連情報が登録される。注目文書のハッシュ値又はハッシュ値セットを検索キーとして検索が実行され、注目文書に関連する関連文書についてのハッシュ値又はハッシュ値セットが特定される。それが検索結果として要求元クライアントへ返され、要求元クライアントで関連文書が特定される。【選択図】図１
2009211603.tif 000002
【特許請求の範囲】
【請求項１】
関連する複数の文書で構成される関連文書グループごとに、当該関連文書グループを構成する複数の文書に基づいて、それらの文書を秘匿しつつ識別するための複数の秘匿識別データからなる秘匿関連情報を生成する生成手段と、
複数のユーザー間で各秘匿関連情報を共有するために複数の秘匿関連情報が登録されるデータベースと、
注目文書に関連する関連文書を検索する要求が要求元ユーザーから発行された場合に、前記注目文書についての秘匿識別データを用いて前記データベースを検索することにより、前記関連文書についての秘匿識別データを検索結果として特定する検索手段と、
前記検索結果としての秘匿識別データにより識別される関連文書に対する前記要求元ユーザーのアクセス権限に応じて、当該要求元ユーザーに対して当該関連文書に関する情報を提供する提供手段と、
を含むことを特徴とする文書検索システム。
【請求項２】
請求項１記載の文書検索システムにおいて、
前記秘匿関連情報を構成する各秘匿識別データは、基礎となった文書に対してコード変換処理を施すことにより生成される少なくとも１つのコードで構成され、
前記コードは、当該コードから前記基礎となった文書の所在及び内容を特定できない不可逆性を有するものである、
ことを特徴とする文書検索システム。
【請求項３】
請求項２記載の文書検索システムにおいて、
前記生成手段は、
前記基礎となった文書の実体部分及び属性部分の両方を識別する第１コードを生成する機能と、
前記基礎となった文書の実体部分及び属性部分の一方を識別する第２コードを生成する機能と、
を具備し、
前記秘匿関連情報を構成する各秘匿識別データが前記第１コード及び前記第２コードを含む、
ことを特徴とする文書検索システム。
【請求項４】
請求項１−３のいずれか１項に記載の文書検索システムにおいて、
前記提供手段は、前記要求元ユーザーが前記関連文書に対するアクセス権限を有する場合に、当該要求元ユーザーに対して当該関連文書についての詳細情報を提供する、
ことを特徴とする文書検索システム。
【請求項５】
請求項４記載の文書検索システムにおいて、
前記提供手段は、前記要求元ユーザーが前記関連文書に対するアクセス権限を有しない場合に、当該要求元ユーザーに対して当該関連文書に関する一切の情報を提供しない、
ことを特徴とする文書検索システム。
【請求項６】
請求項４記載の文書検索システムにおいて、
前記提供手段は、前記要求元ユーザーが前記関連文書に対するアクセス権限を有しない場合に、当該要求元ユーザーに対して当該関連文書の管理権限を有するユーザーへの問い合わせに利用される情報を提供する、
ことを特徴とする文書検索システム。
【請求項７】
サーバー装置又はユーザーによって使用される各クライアント装置に設けられ、関連する複数の文書で構成される関連文書グループごとに、当該関連文書グループを構成する複数の文書に基づいて、それらの文書を秘匿しつつ識別するための複数の秘匿識別データからなる秘匿関連情報を生成する生成手段と、
前記サーバー装置に設けられ、複数のユーザー間で各秘匿関連情報を共有するために複数の秘匿関連情報が登録されるデータベースと、
前記サーバー装置又は前記各クライアント装置に設けられ、注目文書に関連する関連文書を検索する要求が要求元ユーザーから発行された場合に、前記注目文書についての秘匿識別データを用いて前記データベースを検索することにより、前記関連文書についての秘匿識別データを検索結果として特定する検索手段と、
前記サーバー装置又は前記各クライアント装置に設けられ、前記検索結果としての秘匿識別データにより識別される関連文書に対する前記要求元ユーザーのアクセス権限に応じて、当該要求元ユーザーに対して当該関連文書に関する情報を提供する提供手段と、
を含むことを特徴とする文書検索システム。
【請求項８】
情報処理装置において実行される文書検索用のプログラムであって、
関連する複数の文書で構成される関連文書グループごとに、当該関連文書グループを構成する複数の文書に基づいて、それらの文書を秘匿しつつ識別するための複数の秘匿識別データからなる秘匿関連情報を生成する機能と、
注目文書に関連する関連文書を検索する要求が要求元ユーザーから発行された場合に、前記注目文書についての秘匿識別データを用いて、複数のユーザー間で各秘匿関連情報を共有するために複数の秘匿関連情報が登録されるデータベースを検索することにより、前記関連文書についての秘匿識別データを検索結果として特定する機能と、
を含み、
前記検索結果としての秘匿識別データにより識別される関連文書に対する前記要求元ユーザーのアクセス権限に応じて、当該要求元ユーザーに対して当該関連文書に関する情報が提供される、
ことを特徴とする文書検索用のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は文書検索システムに関する。
【背景技術】
【０００２】
電子的な文書の検索処理においては、例えば、検索の基礎をなす文書（以下、注目文書という）が指定され、多数の文書の中から、注目文書に関連する１又は複数の文書（以下、関連文書という）が選び出される。例えば、特許文献１には、注目文書中の語句（キーワード）を検索キーとして利用し、同じ語句を有する文書が関連文書として特定されている。その他にも従来から多様な検索技術が提案されている。
【０００３】
一方、相互に関連する複数の文書を特定する「関連情報」（複数文書間の関連情報）が事前にあるいは必要な時点で生成されるならば、その関連情報を活用して関連文書の検索を円滑に遂行できる。例えば、文書Ａと文書Ｂが相互に関連していることを示す関連情報が事前に登録されている場合、当該関連情報に基づいて、注目文書である文書Ａから関連文書である文書Ｂを直ちに特定することができる。逆の場合も同様である。そのような関連情報は、複数のユーザーが管理する多数の文書にわたってグローバルに作成されることもあるが、個々のユーザーごとにローカルで作成されることもある。例えば、各ユーザーが専用のワークスペース（文書配置空間）を使って文書処理を遂行している過程で、ワークスペースごとに１又は複数の関連情報がユーザー入力によりあるいは自動的に生成されることもあり得る。そのようなローカルワークスペースを基礎として生成された関連情報は、通常、各ユーザーによって管理、支配される情報であり、あるいは、他のユーザーをして積極的に利用困難な情報である。
【０００４】
【特許文献１】特開平１１−５３３９２号公報
【特許文献２】特開２００１−３４４２４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記の関連情報は一種の情報財であり、特定のユーザーを超えて他のユーザーにおいても利用価値があるといえる場合が多い。そこで、関連情報の利用促進つまり共用化を図ることが望まれる。
【０００６】
しかしながら、各ユーザーの管理下にあった関連情報をみだりに共有あるいは公開すると、情報の安全性（セキュリティ）の観点から見て、大きな問題が生じるおそれがある。例えば、関連情報が複数の文書の内容や所在を特定可能な記述として構成されている場合であって、いずれかの文書が機密文書又はそれに準ずるような文書であるとき、当該関連情報を無造作に公開してしまうと、他人に対して秘匿しておきたい文書又はそれに関する情報が、その文書の管理者の意に反して流出してしまうおそれがある。そこまでの機密性が求められていない文書であっても、一般に、文書の管理者（通常、作成者）の意図を確認することなく、文書の内容あるいは所在情報を公開することには慎重でなければならない。
【０００７】
もっとも、個々の関連情報あるいは個々の文書について、個別的に公開の可否あるいは公開条件をきめ細かく設定しておけば、上記のような安全面での問題を回避できるかも知れない。しかしながら、そのような設定はユーザーにとって非常に煩雑であり、そのような仕組みでは、結局、関連情報の共有を促進することはできない。特許文献２には、ユーザーから検索要求が出された場合に、当該ユーザーについてのアクセス権をチェックした上で検索を実行する技術が記載されているが、アクセス権の事前の個別的な設定が必要である。
【０００８】
本発明の目的は、文書検索システムにおいて、文書についての安全性を確保しつつも関連情報の利用の促進を図ることにある。
【課題を解決するための手段】
【０００９】
本発明は、関連する複数の文書で構成される関連文書グループごとに、当該関連文書グループを構成する複数の文書に基づいて、それらの文書を秘匿しつつ識別するための複数の秘匿識別データからなる秘匿関連情報を生成する生成手段と、複数のユーザー間で各秘匿関連情報を共有するために複数の秘匿関連情報が登録されるデータベースと、注目文書に関連する関連文書を検索する要求が要求元ユーザーから発行された場合に、前記注目文書についての秘匿識別データを用いて前記データベースを検索することにより、前記関連文書についての秘匿識別データを検索結果として特定する検索手段と、前記検索結果としての秘匿識別データにより識別される関連文書に対する前記要求元ユーザーのアクセス権限に応じて、当該要求元ユーザーに対して当該関連文書に関する情報を提供する提供手段と、を含む文書検索システムに関する。
【発明の効果】
【００１０】
本発明によれば、文書検索システムにおいて、文書についての安全性を確保しつつも関連情報の利用の促進を図れる。
【発明を実施するための最良の形態】
【００１１】
（１）実施形態の概要
まず、本発明に係る好適な実施形態の概要について説明する。本実施形態に係る文書検索システムは、秘匿関連情報を生成する生成手段と、複数の秘匿関連情報が登録されるデータベースと、データベースの検索により関連文書についての秘匿識別データを特定する検索手段と、要求元ユーザーのアクセス権限に応じて、特定された秘匿識別データに対応する関連文書に関する情報を提供する提供手段と、を含むものである。
【００１２】
上記構成によれば、生成手段によって、関連文書グループごとに、複数の文書に基づいて複数の秘匿識別データが生成され、それらによって秘匿関連情報が構成される。個々の秘匿関連情報は、基礎となった文書を秘匿しつつそれを識別するデータである。生成された秘匿識別データは、複数のユーザーによって利用し得るデータベース上に登録される。注目文書に関連する関連文書の検索が必要となった場合、検索手段が、注目文書についての秘匿識別データを用いてデータベースを検索する。その際、望ましくは、まず注目文書についての秘匿識別データに該当する秘匿識別データがデータベース上で見出され、次にそれに関連付けた（関連文書の）秘匿識別データが特定される。検索結果としての秘匿識別データそれ自体から直ちに関連文書を特定できるものではないが、例えば、検索結果としての秘匿識別データを、要求元ユーザーがアクセス権限を有している個々の文書の秘匿識別データにつき合わせることにより、検索結果から関連文書を容易に特定できる。これに関し、各ユーザーの管理下にある個々の文献について秘匿識別データを事前に作成、保存しておいて、それが必要になった段階で直ちに当該秘匿識別データをつき合わせに利用するようにしてもよいし、あるいは、そのような秘匿識別データが必要となった時点で、基礎となる文献から秘匿識別データを生成するようにしてもよい。検索要求を発行したユーザー（要求元ユーザー）が、検索結果から特定された関連文書に対してアクセス権限を有する場合に（例えば当該関連文書が自己において管理又は保有している文書である場合に）、提供手段によって、当該関連文書に関する情報が当該ユーザーに提供されるので、そのような情報を媒介として関連文書の利用が促進される。一方、アクセス権限を有していない場合には文書の秘匿性を完全に（場合によっては、部分的にあるいは条件付きで）維持するための措置がとられるのが望ましい。
【００１３】
以上のように、本実施形態の文書検索システムによれば、各ユーザーが保有あるいは管理している関連情報を、文書を秘匿可能な形式をもった特別な関連情報として共有することにより、今まで埋もれていた情報財をユーザー間にわたって共有して、各ユーザーにおいて利便性や作業性を向上できる。しかも個々の文書自体の秘匿性を確保できる。
【００１４】
ちなみに、複数の文書間の関連性は従来から提案されているあるいは今後提案される様々な手法を用いて特定できる。データベースへの各秘匿関連情報の登録に当たっては、ユーザーに対応付けつつ各秘匿関連情報が登録されるのが望ましい。この構成によれば、複数のユーザー側から収集された複数の秘匿関連情報それ全体を検索範囲としつつも、検索結果を提供する際に、アクセス権限に応じたフィルタリングを容易に行える。また、そのような構成によれば、検索範囲をユーザー単位で絞ることも容易である。ここで、ユーザーはユーザーグループを含む概念である。但し、データベース上において、個々の秘匿関連情報へのユーザーの対応付けを必ずしも行わなくてもよい。文書作業を行う装置（例えばクライアント装置）とユーザーとが一対一に対応付けられていてもよいし、一対多又は多対一に対応付けられてもよい。ユーザー以外の他の属性を更に個々の秘匿関連情報に対応付けるようにしてもよい。アクセス権限の判断に当たっては様々な手法を利用でき、例えば、その判断が、単に自己が保有している文書であるか否かの判断であってもよいし、アクセス権限が定義されたテーブルの参照によってアクセス権限を判断してもよい。アクセス権限が肯定された場合、関連文書に関する情報として、例えば、当該関連文書の詳細情報が提供されるのが望ましい。当該関連文書の名称が表示されれば直感的にそのカテゴリーや内容を認識でき、当該関連文書の所在が表示されれば当該関連文書へのアクセスを迅速に行える。勿論、それらに代えて、あるいは、それらと共に、他の情報が表示されてもよい。例えば、検索一致度の度合い又は類型を示す情報を表示するようにしてもよい。もちろん、検索の前提として様々な検索条件を付加するようにしてもよい。
【００１５】
上記の各手段は望ましくは実質的にソフトウエアの機能として実現される。そのような文書検索システム用のソフトウエアは、文書検索プログラムとして提供され、具体的には、記憶媒体又はネットワークを介して情報処理システムに組み込まれる。文書検索システムが、単体の装置ではなく、サーバー（検索装置）と複数のクライアント（文書作業装置）で構成される場合、上記の生成手段は各クライアントにあってもよいが、それがサーバーにあってもよい。データベースは基本的にサーバー側に設けられるが、いずれかの文書作業装置が実質的にサーバーとして機能してもよい。上記の検索手段はサーバーにあってもよいが、各クライアントにあってもよい。上記の提供手段についても同様である。
【００１６】
望ましくは、ユーザーごとに（あるいはクライアントごとに）ワークスペース（文書配置空間）が管理されるシステムに上記構成が設けられる。その場合、個々のユーザーのローカルワークスペースごとに生成される秘匿関連情報が共有されることになる。つまり、個々のワークスペースの枠組み内において従来同様に各文書の管理を行いつつも、関連情報についてはそのような枠組みを超えて複数のユーザー間で共有することが可能となる。そのようなワークスペースは個々のクライアントで管理されてもよいし、サーバーにおいて一括管理されてもよい。複数のユーザーが並行して文書作業を行っているような場合に、それぞれのユーザーにおいて関連文書を迅速かつ容易にしかも広く特定できれば、その作業性を著しく向上できる。なお、個々の文書は各クライアントに保存されてもよいし、サーバーに保存されてもよい。あるいは、別の装置上に個々の文書が保存されてもよい。いずれの場合にも上記構成を適用することができる。
【００１７】
望ましくは、各秘匿識別データが、基礎となった文書に対してコード変換処理を施すことにより生成される少なくとも１つのコードで構成され、そのコードが、当該コードから文書の所在及び内容を特定できない不可逆性を有する。上記コード変換処理は、基礎となった文書を対象として行われるものであり、それがダイジェスト作成、暗号化処理、等に相当してもよい。特に望ましくは公知のハッシュ関数を利用した変換処理をあげることができる。秘匿関連情報としてハッシュ値を利用すれば、基礎となった文書についてのセキュリティを完全に保証しつつ、文書間の一致を正確に判断できる。しかも情報量が少ないので、データベース構築上有利である。更に、文書の実体部分についてのハッシュ値が利用されるならばファイル名が変更されても、あるいはアノテーションが付加されても、そのような実体間での一致を判断できるという利点がある。文書間の一致は以下のように様々なレベルあるいはカテゴリーにおいて判断することができる。
【００１８】
望ましくは、前記生成手段は、前記基礎となった文書の実体部分及び属性部分の両方を識別する第１コードを生成する機能と、前記基礎となった文書の実体部分及び属性部分の一方を識別する第２コードを生成する機能と、を具備する。この構成において、前記秘匿関連情報を構成する各秘匿識別データは、前記第１コード及び前記第２コードを含む。この構成によれば、少なくとも、コンテンツに相当する実体部分と、それに付属するアノテーションやコンテキスト等の属性部分と、の両方又は一方を区別して検索処理を遂行できる。文書がテキスト等からなる電子的ドキュメントであれば、ページ単位で一致判断を行うようにしてもよい。かかる構成によれば一致と認定されたページ数や分量から類似度を評価することも可能となる。いずれにしても、全体的な一致と部分的な一致の両者に対応できるように構成しておけば、関連文書の検索に当たっての多様なニーズに応えることができ、システムの利便性を向上できる。
【００１９】
望ましくは、前記提供手段は、前記要求元ユーザーが前記関連文書に対するアクセス権限を有する場合に、当該要求元ユーザーに対して当該関連文書についての詳細情報を提供する。ここで、詳細情報としては、例えば、名称、所在（ＵＲＬ）等をあげることができる。その他に作成日時、所有者、等の情報が表示されてもよい。表示内容及び表示形態をカスタマイズできるように構成してもよい。検索の際に判断される一致度又は類似度に応じて検索結果についての表示優先度を変えるようにしてもよい。例えば、一致度又は類似度がより高いものについてはより上位に表示されるようにしてもよいし、一致度又は類似度が一定以下のものについては表示されないようにしてもよい。表示条件をユーザーが適宜変更できるように構成するのが望ましい。
【００２０】
望ましくは、前記提供手段は、前記要求元ユーザーが前記関連文書に対するアクセス権限を有しない場合に、当該要求元ユーザーに対して当該関連文書に関する一切の情報を提供しない。この構成によれば、秘匿化関連情報も表示されないので、関連文書を完全に秘匿できる。もっとも、秘匿関連情報だけをユーザーに提供するようにしてもよいし、関連文書が存在している事実だけをユーザーに提供するようにしてもよい。
【００２１】
望ましくは、前記提供手段は、前記要求元ユーザーが前記関連文書に対するアクセス権限を有しない場合に、当該要求元ユーザーに対して当該関連文書の管理権限を有するユーザーへの問い合わせに利用される情報を提供する。この構成によれば、関連文書を管理するあるいは保有するユーザーに対する問い合わせを促して、関連文書の利用の機会を増やせる。また、自動的な処理と人為的な判断とを併用して、安全で利便性の高いシステムを構築できる。問い合わせに利用される情報としては、管理者を秘匿したまま単に問い合わせの要否を選択させるものであってもよいし、管理者の名称やイニシャル等までを表示して問い合わせの要否や問い合わせ方法を判断させるものであってもよい。
【００２２】
本願明細書において、文書は、通常、情報処理装置上において処理される電子的なデータ単位である。その概念には、テキスト、静止画像、動画像、音声情報、その他が含まれる。多くの場合、文書は、上記のように、テキスト等の文書実体と、アノテーションや管理情報等の文書属性と、により構成され、それら全体として１つのファイルが構成される。もっとも、文書実体を構成する個々のページ単位でファイルが構成されることもある。
【００２３】
（２）実施形態の詳細な説明
次に、図面に基づいて実施形態を詳述する。
【００２４】
図1には、本実施形態の文書検索システムがブロック図として示されている。文書検索システムは、図1に示す例において、文書検索装置としてのサーバー１０と、サーバー１０に対してネットワークを介して接続された文書作業装置あるいは文書処理装置としての複数のクライアント１２，１４，１６と、によって構成されている。図１においては、３つのクライアント１２，１４，１６がサーバー１０に対して接続されている。但し、クライアントの台数は任意である。図１に示す例において、クライアント１２はユーザーＸによって使用される装置であり、クライアント１４はユーザーＹによって使用される装置であり、クライアント１６はユーザーＺによって使用される装置である。もちろん、一つのクライアントが複数のユーザーによって使用されてもよく、あるいは一人のユーザーが複数のクライアントを使用するものであってもよい。ちなみに、ユーザーはユーザーグループを含む概念であってもよい。一般に、各ユーザー単位で個々の文書が管理されており、あるユーザーが保有あるいは管理している文書に対する他のユーザーからのアクセスは制限される。もっとも、複数のユーザーによって共有される文書が存在していてもよい。いずれにしても、図示の例では、ユーザー（ユーザーグループ）単位で個々の文書に対するアクセス制限がかけられている。
【００２５】
各クライアント１２，１４，１６について説明する。それらのクライアント１２，１４，１６は、上述したように文書の処理を行なうための装置であり、それぞれのクライアント１２，１４，１６ごとに、より具体的にはユーザーごとに、後に説明するワークスペース（文書配置空間）が管理されている。ワークスペースは文書の取り扱いあるいは作業を行なうための仮想的な管理空間である。図１に示す例において、クライアント１２，１４，１６はそれぞれ同一の構成を有しているため、以下に、クライアント１２を代表してその構成について説明する。
【００２６】
クライアント１２は、複数のソフトウエア機能を有しており、それぞれの機能が図１においてブロックとして示されている。具体的に説明すると、文書管理部１８はワークスペースを管理するモジュールであり、このワークスペースについては後に図２等を用いて説明する。各文書の実体はシステム内のどこにあってもよく、各クライアントにおいて保有されていてもよいし、サーバー側あるいは他の装置上に存在していてもよい。関連情報生成部２０は、関連文書グループごとにそれを構成する複数の文書が関連していることを表す関連情報を生成するモジュールである。関連情報は様々な手法を利用して生成することができる。後に説明するワークスペース上においては、例えば、文書間の距離に基づいて関連文書グループが定義される。その場合においては、例えば、一定の距離以内に存在する複数の文書が相互に関連するものであるとみなされる。また、各文書に含まれるキーワードや各文書のダイジェストを基準として複数の文書間における一致度あるいは類似度を判断し、その判断結果に基づいて関連文書グループを定義するようにしてもよい。本実施形態においては、以下に説明するように、関連情報それ自体が共有されるのではなく、それに代わる秘匿関連情報が共有される。関連情報及び秘匿関連情報も相互に関連する複数の文書を特定（識別）する情報である点においては同じであるが、秘匿関連情報は、その名称が示す通り、文書それ自体を秘匿するための特別な形式をもった関連情報であるという点において、一般的な関連情報とは相違する。
【００２７】
そのような秘匿関連情報を生成するのが変換処理部２２である。本実施形態において、変換処理部２２は、基礎となる文書に対してハッシュ関数に基づく変換処理を適用することによりハッシュ値を求めるモジュールである。本実施形態では、一つの文書に対して多面的な変換が実行されており、具体的には、文書全体についてのハッシュ値、文書の中身すなわちコンテンツについてのハッシュ値、文書の属性（コンテキスト）についてのハッシュ値、等の複数のハッシュ値が得られている。それらのハッシュ値の要素として後に説明する秘匿識別値セット（秘匿識別データセット）が構成される。変換処理部２２は、関連情報生成部２０によって生成された関連情報を参考に変換処理を行なうものであるが、ハッシュ値の生成は文書それ自体が基礎となっている。もちろん、関連情報を変換対象とすることも考えられる。
【００２８】
登録処理部２６は、互いの関連する複数の文書から生成された複数の秘匿識別値からなる秘匿識別値セットとしての秘匿関連情報をサーバー１０に登録する処理を実行するモジュールである。具体的には、各クライアントにおいて生成された各秘匿関連情報は、符号１００で示されるように、後に説明する秘匿関連情報データベース（ＤＢ）３２上に登録される。関連情報及び秘匿関連情報の生成タイミング、並びに、登録処理タイミングについては任意に定めることができ、ワークスペース上の構成に変化があったことを自動的に検知し、それをトリガとして生成処理、変換処理及び登録処理の一連の過程が自動的に実行されてもよい。一般には、新しく関連情報が生成されたタイミングで自動的に秘匿関連情報を生成した上で、それが秘匿関連情報ＤＢ上に登録されるように構成するのが望ましい。
【００２９】
要求発行部２８は、サーバー１０上に登録されたシステム全体にわたるすなわち複数のユーザー間にわたる複数の秘匿関連情報を対象として、関連文書の検索を行なう要求を発行するモジュールである。その場合、検索条件を付加することができ、検索条件としては検索範囲や一致判定条件等があげられる。これについては後に説明する。要求発行部２８から発行される検索要求が符号１０２で表されており、その検索要求はサーバー１０内における検索処理部３４で受領され、また処理される。
【００３０】
結果処理部３０は、検索処理部３４から出力される検索結果を表す情報に基づいてユーザーに対して関連文書のリストを提供するモジュールである。そのリストには検索の基礎となった注目文書に関連する１又は複数の文書を特定する情報が含まれる。ただし、後に説明するように、本実施形態では、各文書の秘匿性を担保するため、自己がアクセス権限を有する（具体的には自己が保有又は管理している）関連文書だけがリスト上に反映される。他のユーザーにおいて管理されている関連文書については、その利用を促進するために必要な措置がとられるのが望ましいが、これについては後に説明する。検索処理部３４から結果処理部３０へ渡される情報の流れが符号１０４で表されている。関連文書の秘匿性を担保するために検索結果に対するフィルタリングが必要な場合、そのフィルタリングは検索処理部３４において実行され、あるいは検索処理部３４において実行される。
【００３１】
管理テーブル２４上には、関連情報生成部２０において生成された関連情報が登録され、また、変換処理部２２において生成された秘匿関連情報が登録される。具体的には、本実施形態において、管理テーブル２４上に、各文書について求められた１又は複数のハッシュ値からなる秘匿識別値セットが登録される。このような構成によれば、検索結果としてハッシュ値が渡された場合に、当該ハッシュ値からその生成の基礎となった関連文書を迅速に特定することができる。もちろん、一旦生成されたハッシュ値を保存することなく、必要なタイミングで再度ハッシュ値の計算を行なって、ハッシュ値同士のつき合わせ等を行なうようにしてもよい。このように、管理テーブル２４上において、各文書に関する情報が管理されており、詳しくは、文書ごとにファイル名やその所在（ＵＲＬ）等も管理されている。管理テーブル２４上に管理されている情報がサーバー１０において管理されてもよい。ただし、各文書と各ハッシュ値との対応付けを表す情報については、セキュリティの観点から見て各クライアントにおいてローカルで管理されるのが望ましい。あるいは、そのような情報がサーバー１０上において管理される場合には、当該情報へのアクセス制限を厳格に課すのが望ましい。
【００３２】
以上のように、クライアント１２には、文書管理部１８、関連情報生成部２０、変換処理部２２、等の構成が設けられているが、クライアント１２を例えばシンクライアント構成とし、クライアント１２におけるインテリジェンス機能を実質的にサーバー１０において実現するようにしてもよい。あるいは、関連文書の検索に関わる機能だけがサーバー１０上に搭載されてもよい。
【００３３】
サーバー１０は、上述の通り、秘匿関連情報ＤＢ３２及び検索処理部３４を備えている。他の機能については図示省略されている。秘匿関連情報ＤＢ３２上には各クライアントから送られる秘匿関連情報が登録される。この場合において、ユーザー単位で個々の秘匿情報が管理されてもよいし、そうでなくてもよい。後に説明する図４には秘匿関連情報ＤＢ３２内の構成が例示されている。検索処理部３４は、あるクライアントすなわちあるユーザーから検索要求が発行された場合に、その検索要求に含まれる注目文書の秘匿識別値セット（すなわち、１又は複数のハッシュ値）を検索キーとし、秘匿関連情報ＤＢ３２を検索することにより、注目文書に関連する関連文書の秘匿識別値セットを特定するものである。通常、複数の関連文書に対応する複数の秘匿識別値セットが検索結果として特定されることになる。その中に、注目文書自体の秘匿識別値セットが存在するならば、それについては除外するようにしてもよい。検索処理部３４の具体的な処理内容については図４以降の各図を用いて詳述することにする。
【００３４】
図２には、クライアントの表示画面上に表示されるワークスペースの一例が示されている。図示されるワークスペース３６はユーザーＸによって管理されるものである。ワークスペース３６は、文書の作業空間に相当し、ワークスペース３６上には各文書を表すシンボルとしてのオブジェクトが表示される。各オブジェクトはサムネイル画像（低解像度縮小画像）やアイコン等である。ワークスペース３６上に表示される各オブジェクトとそれが表す各文書とは本来区別されるべきものであるが、以下においては便宜上、それらを区別することなく説明することにする。
【００３５】
図２に示されるワークスペース３６上には、文書Ａ、文書Ｂ、文書Ｃ、文書Ｄが存在しており、それらは文書間距離の基準に基づいて相互に関連する文書であるとみなされている。すなわち、それらは符号３８で示されるように相互に関連する文書グループを構成している。もっとも、文書間距離ではなく他の基準、例えばキーワードやダイジェストの一致度あるいは類似度等を判断基準として関連文書グループを定義するようにしてもよい。複数の判断基準を組み合わせるようにしてもよい。このように関連文書グループが定義されると、各関連文書グループについて関連情報が生成される。
【００３６】
図３には、関連情報と秘匿関連情報との関連が示されている。まず、図３に示される関連情報４０について説明する。図示の例では、文書Ａ−文書Ｄの４つの文書が関連しているという前提の下で、関連情報４０として、複数の識別子４０ａの組み合わせが構成されており、具体的には、文書Ａ識別子、文書Ｂ識別子、文書Ｃ識別子、文書Ｄ識別子によって関連情報４０が構成されている。各識別子は例えばＵＲＬ等によって構成されてもよい。従来において、このような関連情報４０それ自体を検索用のデータベース上に登録すると、他のユーザーによってそれぞれの文書の所在が特定されてしまい、文書のセキュリティ面あるいは秘匿性の面で問題が生じていた。そこで、本実施形態においては上述したように、秘匿関連情報４１がデータベース上に登録される。
【００３７】
秘匿関連情報４１は、図示されるように関連情報４０に対応したものであり、それは４つの文書に対応した４つの秘匿識別値セット４２によって構成される。個々の秘匿識別値セット４２は、複数のハッシュ値からなる秘匿識別データである。具体的には、基礎となった文書の全体についてのハッシュ値４２ａと、文書におけるコンテンツ部分についてのハッシュ値４２ｂと、文書のコンテキスト（属性）についてのハッシュ値４２ｃと、の３つのハッシュ値の組み合わせとして構成されている。もちろん、いずれかのハッシュ値だけによって文書Ａが特定されてもよい。一方、このように多面的にハッシュ値を用意しておくことにより、関連文書の検索ニーズに応じて適切な検索を行なえるという利点がある。ちなみに、文書Ｂ及び文書Ｄに対応する秘匿識別値セットにおいてはコンテキストによるハッシュ値は生成されていない。これは基礎となった文書についてコンテキストの情報が付加されていなかったためである。このように各文書について任意のハッシュ値の組み合わせを適用することが可能である。
【００３８】
ハッシュ値は、ハッシュ関数の実行によって得られたコードあるいは記号列であり、そこからは元の文書のファイル名や所在をまったく特定することができない非可逆性を有するものである。そのような性質を本実施形態においては文書セキュリティの保全に役立てるものである。オリジナルの関連情報そのものを各ユーザー間において共有することはセキュリティ面で問題があるが、複数のハッシュ値によって構成される秘匿関連情報４１を複数のユーザー間において共有することにより、個々の文書の秘匿性を維持したまま文書間の関連性を表す情報の共有、すなわち情報材の共有を図ることが可能となる。
【００３９】
ちなみに、各クライアントにおいては複数の関連情報が生成され、それぞれの関連情報ごとに秘匿関連情報が生成される。そして、それらがデータベース上に登録される。そのような一連の流れが図３に概念図として示されている。なお、ハッシュ変換と同等な作用を発揮するものであれば、他の変換処理を利用することも可能である。例えば様々な暗号化処理を利用するようにしてもよい。ただし、ハッシュ値であれば文書の秘匿性を完全に担保できると共に、正確な検索を行なうことができ、しかもハッシュ値自体のデータ量は少ないので、データ取り扱い上も有利である。本実施形態のように多面的あるいは多段階的な変換によって複数種類のハッシュ値を用意しておくことにより、例えばファイル名が異なっても実体が同一の文書を関連文書として特定することが可能となるという利点を得られる。
【００４０】
図４には、図１に示した秘匿関連情報データベースの構成が概念図として示されている。図４においては、そのような構成の他、検索処理結果についての取り扱いも図解されている。
【００４１】
秘匿関連情報ＤＢ３２には、本実施形態において、ユーザーごとに登録テーブル４４Ｘ，４４Ｙ，４４Ｚが構成されている。すなわち、各ユーザーを単位として情報が管理されている。もっとも、そのような属性付けを行なわずに、複数のユーザー間にわたって一連の秘匿関連情報の一元管理を行なうようにしてもよい。ここで、ユーザーＸについて生成されたテーブル４４Ｘに着目すると、当該テーブル４４Ｘには複数の秘匿関連情報４１が登録されている。各秘匿関連情報４１には図４に示す例において識別番号４１ａが付加されている。個々の秘匿関連情報４１は、上述したように、相互に関連する複数の秘匿識別値セットにより構成され、それぞれのセットは、１又は複数のハッシュ値により構成される。
【００４２】
ここで、関連情報の検索プロセスの一例について説明する。あるクライアントから検索要求が発行された場合、その検索要求に含まれるハッシュ値が認識される。そのハッシュ値は注目文書についてのハッシュ値である。通常、注目文書についての複数のハッシュ値が検索要求の中に含まれるが、ここでは一つのハッシュ値が含まれるものとする。サーバーにおける検索処理部は、そのハッシュ値を検索キーとして秘匿関連情報ＤＢに対する検索を実行する。すると、例えば符号４６で示すように、特定のハッシュ値との間に一致が判定される。もちろん、更に他の秘匿関連情報内のハッシュ値との間において一致が判定されることもある。そのような一致判定は、注目文書に関連する関連文書の特定に相当する。ただし、この段階では、関連文書それ自体が直ちに特定されるのではなく、当該関連文書に対応付けられた秘匿識別データ（つまり１又は複数の秘匿識別子としての１又は複数のハッシュ値）が特定される。図４に示す例では、例えば３つの関連文書に対応する３つのハッシュ値セット（符号４１参照）が特定され、それらが検索結果あるいは検索結果の候補とされる。
【００４３】
関連文書を特定する情報４１は、図示の例では、符号１０６Ａで示すプロセスあるいは符号１０６Ｂで示すプロセスに従って処理される。各プロセスは選択的に利用されるものである。符号１０６Ａで示すプロセスでは、符号５０で示されるように、まずサーバー上において情報４１に対するフィルタリングが実行され、それによって検索結果としてのリストが生成される。そのフィルタリングには、検索要求を発行したユーザーがアクセス権限を有する関連文書のみを絞り込む処理に相当する。すなわち他のユーザーにおいて保有あるいは管理されている文書が関連文書として直ちに特定されないようにするマスク処理としてフィルタリング処理が位置づけられる。本実施形態においては、データベース３２上において各秘匿関連情報がユーザー単位で管理されているため、そのような管理体系を利用して上記のフィルタリング処理を行なうことが可能である。すなわち、上記の情報４１に含まれるハッシュ値あるいはハッシュ値セットが検索要求元のユーザーに対応付けられている場合に限り、当該ハッシュ値又はハッシュ値セットが検索結果に含まれるように処理される。符号５２で示す処理には、サーバーにおいて生成されたリストが、要求元であるクライアントに提供され、そのリストが当該クライアント上において表示されることになる。
【００４４】
一方、符号１０６Ｂで示すプロセスにおいては、符号５４で示すように、サーバー上において抽出された情報が検索結果としてそのまま要求元クライアントへ提供される。そして、符号５６で示されるように、当該クライアント上においてサーバーから提供された情報に対するフィルタリング処理が施される。これによって、当該ユーザーに提供可能なリストが構成され、それが画面上に表示されることになる。プロセス１０６Ｂにおいては、結果として、ユーザー側にすべてのハッシュ値が提供されることになるが、上述したように、ハッシュ値それ自体から文書を特定することは不可能であるため、プロセス１０６Ｂを採用する場合においても文書の秘匿性を保全できる。ただし、ハッシュ値それ自体の提供を行いたくないような場合には、プロセス１０６Ａを選択するのが望ましい。プロセス１０６Ａについては後に図８を用いて詳述する。
【００４５】
次に、関連文書の検索について具体例を説明する。その前提は以下の通りである。
[ＤＢ内容]
・ユーザーＸからの秘匿関連情報（図３）が登録済み
[ユーザーＹ側の状況]
・文書Ａ：ユーザーＹのワークスペース上に存在
・文書Ｂ：ユーザーＹのワークスペースからかなり離れた別の空間に存在
（それ故、文書Ａ及び文書Ｂの関連性は認識されていない）
・文書Ｂ’:文書Ｂに対してアノテーションを付加したもの
ユーザーＹのワークスペース上において文書Ａから少し離れて存在
・文書Ｃ：ユーザーＹのワークスペースに近い別の空間に存在
・文書Ｄ：不存在
上記前提において、ユーザーＹ側から、注目文書Ａに関連する関連文書の検索要求が発行されると、図５又は図６に示す検索結果がリスト表示される。
【００４６】
図５に示す例では、文書Ａの関連文書として文書Ｂ´及び文書Ｃが検索結果として表示される。図示の例では、各関連文書について、文書名５８、文書の所在（場所）６０及び一致種別６２の情報が表示され、それらの情報によって、それぞれの関連文書の詳細を把握できる。特に、一致種別の情報が併せて表示されるので、どのような条件の下で一致が判断されたのかを直ちに理解することができ、関連文書の利用にあたって当該情報を参考とすることができる。一致種別６２は、検索キーとしてのハッシュ値がどのレベル（どのカテゴリー）において一致したかを示すものであり、図４の例においては符号４６で示したように文書Ｂ´についてコンテンツレベルでハッシュ値一致が認められている。一方、ファイル全体についてハッシュ値一致が認められた場合には、図５において文書Ｃについて示すように、全体一致と表示される。コンテンツレベルにおいてハッシュ値の一致が認められた場合にはコンテンツ一致と表示される。例えば、コンテンツ一致の場合には、アノテーションの付加及び内容等によらずに実体間の一致をもって、関連文書を特定できるので、関連文書の探索に当たってその利便性を向上できる。
【００４７】
図６に示すリストも基本的に図５に示したリストと同様の構成を有しているが、図６に示すリスト上においては各文書ごとにそれを保有しているユーザーに関する情報４６が付加されている。このような情報はサーバー側から提供されるのが望ましい。すなわち、サーバー側において各秘匿識別値セットごとにそれに対応付けてユーザー情報を管理しておけば、検索結果としてリストを表示する段階において各文書を保有しているユーザーに関する情報を提供することが可能である。
【００４８】
図６に示すリスト上においては、検索要求を発行したユーザーＹ以外のユーザーが管理、保有している文書に相当する項目も含まれる（符号６６参照）。当該項目においては、文書が存在すること自体を認識できるものの、文書名、場所、一致種別といった情報については秘匿されている。一方、それを保有しているユーザーの情報だけが符号６４ａで示すように提供されている。このような構成によれば、不明な文書ではあるもののそれを保有しているユーザーへ問合せを行って、その保有者から必要な文書の提供を受けることが可能となる。その場合、保有しているユーザーが提供を拒否すれば当該文書についての秘匿性をそのまま維持できる。このように自動処理とユーザー判断とを組み合わせれば、秘匿性及び情報利用性の相反する２つのニーズを満たすことができる。保有ユーザーへの問合せにあたっては、その中に、対象となる関連文書についての秘匿識別データ（つまり１又は複数のハッシュ値）を含めるようにすればよい。かかる構成によれば、問い合わせを受けたユーザーにおいて、関連文書を確実に特定することが可能となる。ちなみに、そのような問合せの便宜を図るために、上記の項目６６をクリックすることにより、保有ユーザーへ所定の問い合わせが自動的に発行されるようにしてもよい。その場合においては、問い合わせ元のユーザーから文書を保有しているユーザーへ問合せが直接的に発行されるようにしてもよいし、サーバー経由でそのような問合せが伝送されるようにしてもよい。また、項目６６に示すような情報に代えて、保有ユーザー名も隠蔽し、単に問合せのボタンだけを表示するようにしてもよい。
【００４９】
検索結果の表示にあたって、関連文書の特定をより容易にするために、例えば図７に示すような態様を採用することもできる。図７には、ユーザーＹが管理しているワークスペース６８が示されており、上述した前提状況がそのワークスペース６８上において生じている。すなわち、注目文書Ａ７０から少し離れた位置に関連文書としての文書Ｂ´７２が存在している。ユーザーＹ装置上、文書Ａと文書Ｂ´との関連性は認識されていないが、図２に示したユーザーＸのワークスペース上において生成された関連情報、具体的にはユーザーＸの秘匿関連情報を使って、ユーザーＹにおいて文書Ｂ´が文書Ａ７０の関連文書であることを特定することが可能となる。その際、図７の符号７４に示されるようにポップアップあるいは吹き出しの形態で特定の文書が関連文書であることを明らかにするようにしてもよい。符号７４で示される吹き出しにおいては、注目文書である文書Ａが特定されており、更に上述した一致種別の情報もそこに含まれている。更に、関連文書をめくるための２つのボタン７６が表示されており、ユーザーはそのようなボタンをクリックすることにより、リスト上において順番に関連文書を特定することができ、しかもその特定を行なうと、次に特定されている文章へ吹き出しが移動し、ユーザーは、そのような一連の表示を見ながら、必要な関連文書を容易に且つ迅速に選び出せるから、ユーザーにとって非常に便利である。
【００５０】
上記実施形態においては、ファイル全体、コンテンツ、及びコンテキストといった３つのレベルあるいはカテゴリーを用いて検索を行えるようにしたが、それに加えてあるいはそれらに代えてページ単位での検索管理を行なうようにしてもよい。すなわちページごとにハッシュ値をもたせるものである。そして、ハッシュ値が一致した頁数あるいは分量に応じて関連度を評価するようにしてもよい。
【００５１】
次に、図８を用いて図１に示した構成の動作例を説明する。図８には検索処理プロセスがフローチャートとして示されている。図８において、Ｓ１０１では、あるクライアントにおいて注目文書が指定され、Ｓ１０２では当該クライアントにおいてユーザーにより検索条件が指定される。検索条件には、カテゴリーの指定、検索範囲の指定、が含まれてよい。Ｓ１０３では、クライアント（要求元クライアント）から検索要求が発行される。その検索要求には、本実施形態において、注目文書を特定する１又は複数のハッシュ値が含まれる。
【００５２】
Ｓ１０４は図４の符号１０６Ａで示したプロセスに相当する。もちろん、図４の符号１０６Ａに示したプロセスあるいは他のプロセスが実行されてもよい。
【００５３】
具体的には、Ｓ１０５において、サーバー側において、検索要求に対応した検索処理が開始される。各秘匿関連情報を順番に参照していく過程において、Ｓ１０６で、ハッシュ値が同一のものが発見された場合には、処理がＳ１０７以降へ移行する。
【００５４】
Ｓ１０７では、一致が認められたハッシュ値を含む秘匿関連情報の中で、注目文書とは異なる文書（関連文書）に対応するハッシュ値セットが１つ取り出される。Ｓ１０８では、アクセス権限の有無が判断される。例えば、データベース上において、当該取り出されたハッシュ値セットに対応付けられている１又は複数のユーザーの中に要求元ユーザーが含まれている場合にアクセス権限ありと判断される。アクセス権限が肯定されれば、処理がＳ１０８からＳ１０９へ処理が移行し、Ｓ１０９において当該ハッシュ値セットが検索結果としてのリストに反映される。アクセス権限の有無の判断に当たっては各種の手法を利用可能である。
【００５５】
一方、Ｓ１０８において、要求元ユーザーがアクセス権限を有していないと判断された場合には、Ｓ１１０において、秘匿形式（秘匿モード）が判断され、秘匿形式として完全なる非公開が選択されている場合には、Ｓ１１１において上記において取り出されたハッシュ値セットはリストには反映されずに破棄される。一方、Ｓ１１０において条件付公開が設定されていると判断された場合には、Ｓ１１２において上記Ｓ１０７で取り出されたハッシュ値セットが一定条件下で（つまり公開制限された状態で）リストに反映される。例えば図６に示したように複数のブランク情報を含む項目として関連文書が表現されることになる。
【００５６】
Ｓ１１３では、現在認識されている関連文書グループ内に、まだ検索対象となっていない他の関連文書(正確には他のハッシュ値セット)が残っているか否かが判断され、残っていれば上記のＳ１０７以降の各工程が繰り返し実行される。一方、残っていなければ処理がＳ１１３からＳ１１４へ移行し、Ｓ１１４ではさらに検索を続行するか否かが判断され、続行する場合には（すなわちまだ検索していない部分があれば）Ｓ１０６以降の各工程が繰り返し実行される。一方、データベースの最後まで、あるいは検索範囲の最後まで検索が進行した場合には、処理がＳ１１４からＳ１１５へ移行し、Ｓ１１５では、以上のようにユーザーを基準としてフィルタリング処理が実行された後のリストが、要求元ユーザーすなわち要求元クライアントへ提供される。Ｓ１１６では要求元クライアントにおける画面上にリストが表示されることになる。その際、要求元クライアントでは、管理テーブルが参照され、検索結果として送られてきた各ハッシュ値（又は各ハッシュ値セット）に対応する文書が特定され、それが関連文書として表示される。具体的には、関連文書に関してファイル名、所在、等の情報が表示される。他のユーザーが管理するハッシュ値を受領した場合、問い合わせを促すための処理が実行される。これについては既に説明した通りである。管理テーブル上に自己が保有している各文書についてのハッシュ値が格納されていない場合にはハッシュ値の再計算を行った上でつき合わせを行うようにすればよい。
【００５７】
上記図８のフローチャートにおいては、サーバー側においてフィルタリング処理が実行されていたが、図４を用いて説明したようにクライアント側においてフィルタリング処理その他の加工処理が行なわれてもよい。検索結果のリスト表示に当たっては、優先度に応じて順位付けを行ってもよい。例えば、カテゴリー、一致度合い、等の指標に基づいて、関連文書間における優劣を決定し、上位所定個の関連文書だけをリスト表示するようにしてもよい。また、その際に、ユーザーに表示条件を選択させるようにしてもよい。例えば、コンテンツ一致となった関連文書だけがリスト表示されるようにするものである。データベースの更新は、各ユーザーにおける状況、例えば文書配置、文書内容、等が変化したタイミングで行うようにしてもよいし、定期的に実行されるようにしてもよい。
【００５８】
以上説明したように、本実施形態のシステムによれば、関連文書グループごとに秘匿関連情報がデータベース上に登録され、それが複数のユーザーにおいて共有されることになる。その場合において、文書それ自体の秘匿性を保ったままそれらの関連性を示す情報を共有できるので、個々のユーザーにおいて埋もれていた情報財を広く安全に活用できるという利点がある。上記実施形態においては、文書に対して多面的な観点からハッシュ値への変換を行なって、それぞれのハッシュ値を検索対象にすることができるので、検索における多様なニーズに応えることができ、ユーザーの利便性を極めて向上できるという利点がある。
【図面の簡単な説明】
【００５９】
【図１】本発明の実施形態を表すブロック図である。
【図２】ユーザーＸによって管理されるワークスペースの例を示す図である。
【図３】秘匿関連情報の構成及び生成過程を説明するための図である。
【図４】データベースの構造及び検索処理結果の取り扱いを説明するための図である。
【図５】検索結果の一例を示す図である。
【図６】検索結果の他の例を示す図である。
【図７】ユーザーＹによって管理されるワークスペースを示す図である。
【図８】検索処理のプロセスを説明するためのフローチャートである。
【符号の説明】
【００６０】
１０  サーバー、１２，１４，１６  クライアント、１８  文書管理部（ワークスペース管理部）、２０  関連情報生成部、２２  変換処理部、２４  管理テーブル、２６  登録処理部、２８  要求発行部、３０  結果処理部、３２  秘匿関連情報データベース、３４  検索処理部、４０  関連情報、４１  秘匿関連情報、４２  秘匿識別値セット（秘匿識別データ）。
【図１】
2009211603.tif 000003
【図２】
2009211603.tif 000004
【図３】
2009211603.tif 000005
【図４】
2009211603.tif 000006
【図５】
2009211603.tif 000007
【図６】
2009211603.tif 000008
【図７】
2009211603.tif 000009
【図８】
2009211603.tif 000010