(57)【要約】【課題】電子文書にその電子文書に関連する情報を検索する検索条件を対応づけ、その検索条件は指定された語と情報毎に関与するユーザに基づいて生成したものとする。【解決手段】文書管理装置１０の文書ＤＢ１００、タスクＤＢ１０２、及びＷｉｋｉＤＢ１０４は、それぞれ、文書に関連する関連情報の候補となる文書、タスク、及びＷｉｋｉを記憶する。文書管理部１３０の検索式生成部１３２は、キーワードを用いて文書ＤＢ１００、タスクＤＢ１０２及びＷｉｋｉＤＢ１０４を検索した結果として得られた文書、タスク、及びＷｉｋｉの内容に関与するユーザの中から、予め定められた規則に従って、処理対象の文書の関係者を選択する。さらに、検索式生成部１３２は、キーワード及び関係者に基づく条件を含む検索式を生成し、生成した検索式を処理対象の文書に対応づけて文書管理情報ＤＢ１１０に登録する。【選択図】図１
2011054019.tif 000002
【特許請求の範囲】
【請求項１】
処理対象の電子文書である対象文書に関連する関連情報の候補となる候補情報を記憶した候補情報記憶手段であって前記候補情報のそれぞれに関与するユーザを表す関与ユーザ情報をさらに記憶した候補情報記憶手段から、指定された語を含む候補情報を検索する第一検索ステップと、
前記第一検索ステップの結果として得られた候補情報の前記関与ユーザ情報が表すユーザの中から、予め定められた規則に従ってユーザを選択する選択ステップと、
前記指定された語及び前記選択ステップにおいて選択されたユーザに基づく条件を含む検索条件を生成する生成ステップと、
前記生成ステップで生成した前記検索条件を前記対象文書に対応づけて文書管理情報記憶手段に登録する第一登録ステップと、
をコンピュータに実行させるための文書管理プログラム。
【請求項２】
前記候補情報記憶手段に記憶された前記候補情報のうち、前記対象文書に対応づけて前記文書管理情報記憶手段に記憶された前記検索条件を満たす候補情報を検索する第二検索ステップ、
を前記コンピュータにさらに実行させるための、請求項１に記載の文書管理プログラム。
【請求項３】
前記第二検索ステップの結果として得られた候補情報を、前記第二検索ステップにおける検索に用いた検索条件に対応づけられた対象文書の関連情報として、当該対象文書に対応づけて前記文書管理情報記憶手段に登録する第二登録ステップと、
を前記コンピュータにさらに実行させるための、請求項２に記載の文書管理プログラム。
【請求項４】
前記候補情報記憶手段は、前記候補情報それぞれについて当該候補情報の内容に変更が生じた時期を表す情報を含む変更情報をさらに記憶し、
前記第一検索ステップの結果として得られた候補情報の前記変更情報により表される時期に基づいて、前記対象文書の関連情報が変化し得る期間を予測する期間予測ステップ、を前記コンピュータにさらに実行させ、
前記期間予測ステップで予測された期間内に前記第二検索ステップを前記コンピュータに実行させるための、請求項３に記載の文書管理プログラム。
【請求項５】
前記生成ステップは、さらに、前記期間予測ステップで予測された期間に基づく条件を含む検索条件を生成する、
ことを特徴とする請求項４に記載の文書管理プログラム。
【請求項６】
前記選択ステップにおいて、前記第一検索ステップの結果として得られた候補情報のそれぞれについて、前記対象文書の作成又は更新の時期と、当該候補情報の前記変更情報により表される時期と、に基づいて当該候補情報の重みを求め、この重みが予め設定された閾値以上である候補情報の前記関与ユーザ情報が表すユーザの中から、ユーザを選択する、
ことを特徴とする請求項４又は５に記載の文書管理プログラム。
【請求項７】
前記変更情報は、さらに、前記候補情報それぞれの内容の変更を指示したユーザを表す情報を含み、
前記選択ステップにおいて、前記関与ユーザ情報が表すユーザのそれぞれについて、前記変更情報を参照して当該ユーザが前記候補情報の内容の変更を指示した回数を求め、求めた回数に基づいて当該ユーザの重みを求め、この重みが予め設定された閾値以上であるユーザを選択する、
ことを特徴とする請求項４から６のいずれか１項に記載の文書管理プログラム。
【請求項８】
前記候補情報記憶手段は、さらに、前記候補情報のそれぞれの前記関与ユーザの当該候補情報に対する役割を表す情報を記憶し、
前記選択ステップにおいて、前記関与ユーザが表すユーザのそれぞれの重みを、さらに、当該ユーザの前記候補情報に対する役割に基づいて求める、
ことを特徴とする請求項７に記載の文書管理プログラム。
【請求項９】
前記選択ステップにおいて、各ユーザが所属する組織及び複数の組織が構成する階層構造を表す情報を記憶した組織情報記憶手段を参照し、前記関与ユーザが表すユーザのそれぞれの重みを、さらに、当該ユーザが所属する組織と前記対象文書の作成又は更新を指示したユーザが所属する組織との間の前記階層構造における関係に基づいて求める、
ことを特徴とする請求項７又は８に記載の文書管理プログラム。
【請求項１０】
前記第二登録ステップにおいて、前記第二検索ステップの結果として得られた候補情報のそれぞれについて、予め定められた方針に従って検索スコアを決定し、決定した検索スコアが予め設定された閾値以上である候補情報を前記対象文書の関連情報として前記対象文書に対応づけて前記文書管理情報記憶手段に登録し、
前記予め定められた方針は、前記第二検索ステップの結果として得られた候補情報の内容、当該候補情報の前記変更情報、及び前記文書管理情報記憶手段の少なくともいずれかを参照して、前記対象文書に関連する可能性の高い候補情報ほど前記検索スコアの値がより大きくなるように前記検索スコアの値を決定する方針である、
ことを特徴とする請求項４から９のいずれか１項に記載の文書管理プログラム。
【請求項１１】
前記候補情報記憶手段は、複数の異なる種類の前記候補情報を記憶し、
前記候補情報の種類ごとに、前記第一検索ステップ、前記選択ステップ、前記生成ステップ、前記期間予測ステップ、及び前記第二検索ステップを前記コンピュータに実行させるための、請求項４から１０のいずれか１項に記載の文書管理プログラム。
【請求項１２】
前記対象文書の特徴を表す語を当該対象文書から抽出する抽出ステップ、
を前記コンピュータにさらに実行させ、
第一検索ステップにおいて、前記抽出ステップにおいて抽出された語を含む候補情報を検索する、
ことを特徴とする請求項１から１１のいずれか１項に記載の文書管理プログラム。
【請求項１３】
処理対象の電子文書である対象文書に関連する関連情報の候補となる候補情報を記憶した候補情報記憶手段であって前記候補情報のそれぞれに関与するユーザを表す関与ユーザ情報をさらに記憶した候補情報記憶手段から、指定された語を含む候補情報を検索する検索手段と、
前記検索手段の検索の結果として得られた候補情報の前記関与ユーザ情報が表すユーザの中から、予め定められた規則に従ってユーザを選択する選択手段と、
前記指定された語及び前記選択手段において選択されたユーザに基づく条件を含む検索条件を生成する生成手段と、
前記生成手段が生成した前記検索条件を前記処理対象の文書に対応づけて文書管理情報記憶手段に登録する登録手段と、
を備えることを特徴とする文書管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書管理プログラム及び文書管理装置に関する。
【背景技術】
【０００２】
特許文献１には、図面や文書などのドキュメントの検索や編集を行うシステムにおいて、ドキュメントを検索したときにその属性情報を検索キーワード集合として保存し、この保存した検索キーワードを用いてさらにドキュメントを検索できるようにするシステムが開示されている。
【０００３】
特許文献２には、業務において利用される文書を管理する技術が開示されている。特許文献２に記載の技術では、管理対象となる各文書について、業務におけるユーザの文書操作内容を採取して履歴を管理し、業務における文書の使われ方を属性として付加することにより文書と業務を関連づけて管理する。特許文献２に記載の技術では、文書から業務、又は業務から文書の検索が可能である。
【０００４】
また、特許文献３には、文書の更新内容の変遷を把握することが可能な文書管理システムが開示されている。特許文献３に記載のシステムでは、複数のファイルから構成される文書をフォルダに分類して管理し、それぞれの文書が更新された際に更新前の文書を旧バージョンとして文書管理データベースに保存しておき、指定したフォルダ内に存在している最新バージョン及び、それぞれの文書の旧バージョンを検索対象に含めて検索する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平１０−２３２８７９号公報
【特許文献２】特開平１１−３９３２０号公報
【特許文献３】特開２００３−１６７９１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、電子文書にその電子文書に関連する情報を検索する検索条件を対応づけ、その検索条件は指定された語と情報毎に関与するユーザに基づいて生成したものとする文書管理プログラム及び文書管理装置を提供することである。
【課題を解決するための手段】
【０００７】
請求項１に係る発明は、処理対象の電子文書である対象文書に関連する関連情報の候補となる候補情報を記憶した候補情報記憶手段であって前記候補情報のそれぞれに関与するユーザを表す関与ユーザ情報をさらに記憶した候補情報記憶手段から、指定された語を含む候補情報を検索する第一検索ステップと、前記第一検索ステップの結果として得られた候補情報の前記関与ユーザ情報が表すユーザの中から、予め定められた規則に従ってユーザを選択する選択ステップと、前記指定された語及び前記選択ステップにおいて選択されたユーザに基づく条件を含む検索条件を生成する生成ステップと、前記生成ステップで生成した前記検索条件を前記対象文書に対応づけて文書管理情報記憶手段に登録する第一登録ステップと、をコンピュータに実行させるための文書管理プログラムである。
【０００８】
請求項２に係る発明は、請求項１に係る発明において、前記候補情報記憶手段に記憶された前記候補情報のうち、前記対象文書に対応づけて前記文書管理情報記憶手段に記憶された前記検索条件を満たす候補情報を検索する第二検索ステップ、を前記コンピュータにさらに実行させる。
【０００９】
請求項３に係る発明は、請求項２に係る発明において、前記第二検索ステップの結果として得られた候補情報を、前記第二検索ステップにおける検索に用いた検索条件に対応づけられた対象文書の関連情報として、当該対象文書に対応づけて前記文書管理情報記憶手段に登録する第二登録ステップと、を前記コンピュータにさらに実行させる。
【００１０】
請求項４に係る発明は、請求項３に係る発明において、前記候補情報記憶手段は、前記候補情報それぞれについて当該候補情報の内容に変更が生じた時期を表す情報を含む変更情報をさらに記憶し、前記第一検索ステップの結果として得られた候補情報の前記変更情報により表される時期に基づいて、前記対象文書の関連情報が変化し得る期間を予測する期間予測ステップ、を前記コンピュータにさらに実行させ、前記期間予測ステップで予測された期間内に前記第二検索ステップを前記コンピュータに実行させる。
【００１１】
請求項５に係る発明は、請求項４に係る発明において、前記生成ステップは、さらに、前記期間予測ステップで予測された期間に基づく条件を含む検索条件を生成する。
【００１２】
請求項６に係る発明は、請求項４又は５に係る発明において、前記選択ステップにおいて、前記第一検索ステップの結果として得られた候補情報のそれぞれについて、前記対象文書の作成又は更新の時期と、当該候補情報の前記変更情報により表される時期と、に基づいて当該候補情報の重みを求め、この重みが予め設定された閾値以上である候補情報の前記関与ユーザ情報が表すユーザの中から、ユーザを選択する。
【００１３】
請求項７に係る発明は、請求項４から６のいずれか１項に係る発明において、前記変更情報は、さらに、前記候補情報それぞれの内容の変更を指示したユーザを表す情報を含み、前記選択ステップにおいて、前記関与ユーザ情報が表すユーザのそれぞれについて、前記変更情報を参照して当該ユーザが前記候補情報の内容の変更を指示した回数を求め、求めた回数に基づいて当該ユーザの重みを求め、この重みが予め設定された閾値以上であるユーザを選択する。
【００１４】
請求項８に係る発明は、請求項７に係る発明において、前記候補情報記憶手段は、さらに、前記候補情報のそれぞれの前記関与ユーザの当該候補情報に対する役割を表す情報を記憶し、前記選択ステップにおいて、前記関与ユーザが表すユーザのそれぞれの重みを、さらに、当該ユーザの前記候補情報に対する役割に基づいて求める。
【００１５】
請求項９に係る発明は、請求項７又は８に係る発明において、前記選択ステップにおいて、各ユーザが所属する組織及び複数の組織が構成する階層構造を表す情報を記憶した組織情報記憶手段を参照し、前記関与ユーザが表すユーザのそれぞれの重みを、さらに、当該ユーザが所属する組織と前記対象文書の作成又は更新を指示したユーザが所属する組織との間の前記階層構造における関係に基づいて求める。
【００１６】
請求項１０に係る発明は、請求項４から９のいずれか１項に係る発明において、前記第二登録ステップにおいて、前記第二検索ステップの結果として得られた候補情報のそれぞれについて、予め定められた方針に従って検索スコアを決定し、決定した検索スコアが予め設定された閾値以上である候補情報を前記対象文書の関連情報として前記対象文書に対応づけて前記文書管理情報記憶手段に登録し、前記予め定められた方針は、前記第二検索ステップの結果として得られた候補情報の内容、当該候補情報の前記変更情報、及び前記文書管理情報記憶手段の少なくともいずれかを参照して、前記対象文書に関連する可能性の高い候補情報ほど前記検索スコアの値がより大きくなるように前記検索スコアの値を決定する方針である。
【００１７】
請求項１１に係る発明は、請求項４から１０のいずれか１項に係る発明において、前記候補情報記憶手段は、複数の異なる種類の前記候補情報を記憶し、前記候補情報の種類ごとに、前記第一検索ステップ、前記選択ステップ、前記生成ステップ、前記期間予測ステップ、及び前記第二検索ステップを前記コンピュータに実行させる。
【００１８】
請求項１２に係る発明は、請求項１から１１のいずれか１項に係る発明において、前記対象文書の特徴を表す語を当該対象文書から抽出する抽出ステップ、を前記コンピュータにさらに実行させ、第一検索ステップにおいて、前記抽出ステップにおいて抽出された語を含む候補情報を検索する。
【００１９】
請求項１３に係る発明は、処理対象の電子文書である対象文書に関連する関連情報の候補となる候補情報を記憶した候補情報記憶手段であって前記候補情報のそれぞれに関与するユーザを表す関与ユーザ情報をさらに記憶した候補情報記憶手段から、指定された語を含む候補情報を検索する検索手段と、前記検索手段の検索の結果として得られた候補情報の前記関与ユーザ情報が表すユーザの中から、予め定められた規則に従ってユーザを選択する選択手段と、前記指定された語及び前記選択手段において選択されたユーザに基づく条件を含む検索条件を生成する生成手段と、前記生成手段が生成した前記検索条件を前記処理対象の文書に対応づけて文書管理情報記憶手段に登録する登録手段と、を備えることを特徴とする文書管理装置である。
【発明の効果】
【００２０】
請求項１又は１３に係る発明によると、電子文書にその電子文書に関連する情報を検索する検索条件を対応づけ、その検索条件は指定された語と情報毎に関与するユーザに基づいて生成したものとすることができる。
【００２１】
請求項２に係る発明によると、電子文書に対応づけられた検索条件を用いて、その電子文書に関連する情報を検索することができる。
【００２２】
請求項３に係る発明によると、電子文書に対応づけられた検索条件を用いて検索された関連情報をその電子文書に対応づけることができる。
【００２３】
請求項４に係る発明によると、電子文書に関連する情報が変化し得る期間内に検索された情報を対象文書に対応づけることができる。
【００２４】
請求項５に係る発明によると、電子文書に関連する情報が変化し得る期間に基づく条件を含む検索条件を用いて、その電子文書に関連する情報を検索できる。
【００２５】
請求項６に係る発明によると、電子文書の作成又は更新の時期とその電子文書に関連する情報の候補の内容に変更が生じた時期とを考慮して、検索条件の生成に反映させるユーザを選択できる。
【００２６】
請求項７に係る発明によると、各ユーザが関連する情報の候補の内容の変更を指示した回数を考慮して、検索条件の生成に反映させるユーザを選択できる。
【００２７】
請求項８に係る発明によると、関連する情報の候補に対する各ユーザの役割を考慮して、検索条件の生成に反映させるユーザを選択できる。
【００２８】
請求項９に係る発明によると、複数の組織が構成する階層構造における、各ユーザの所属する組織と対象文書の作成者又は更新者の所属する組織との間の関係を考慮して、検索条件の生成に反映させるユーザを選択できる。
【００２９】
請求項１０に係る発明によると、関連する情報の候補のうち電子文書に関連する可能性のより高い候補を電子文書に関連する情報として、その電子文書に対応づけられる。
【００３０】
請求項１１に係る発明によると、関連する情報の候補の種類ごとに生成した検索式条件を用いて、その種類ごとに電子文書に関連する情報を検索できる。
【００３１】
請求項１２に係る発明によると、電子文書から検索条件の生成に反映させる語を抽出できる。
【図面の簡単な説明】
【００３２】
【図１】文書管理装置の構成の例を示すブロック図である。
【図２】文書管理情報ＤＢのデータ内容の例を示す図である。
【図３】組織が構成する階層構造の例を示す図である。
【図４】検索式生成処理の手順の例を示すフローチャートである。
【図５】関係者取得処理の手順の例を示すフローチャートである。
【図６】関連期間予測処理の手順の例を示すフローチャートである。
【図７】関連情報の候補の変更回数の時間変化の例を示す図である。
【図８】関連情報登録処理の手順の例を示すフローチャートである。
【図９】文書管理装置が表示させる表示画面の例を示す図である。
【図１０】文書管理装置が表示させる表示画面の他の例を示す図である。
【図１１】文書管理装置が表示させる表示画面のさらに他の例を示す図である。
【図１２】コンピュータのハードウエア構成の例を示す図である。
【発明を実施するための形態】
【００３３】
図１は、本発明の実施形態による文書管理装置の構成の例を示すブロック図である。図１の例の文書管理装置１０は、企業や自治体などの組織における業務で利用される文書を管理する。また、文書管理装置１０は、インターネット又はＬＡＮなどの図示しないネットワークを介して、クライアント端末及びサーバ装置などの他の装置（図示しない）と接続されていてよい。
【００３４】
文書管理装置１０は、文書ＤＢ１００、タスクＤＢ１０２、ＷｉｋｉＤＢ１０４、文書管理情報ＤＢ１１０、ユーザ情報ＤＢ１２０、文書管理部１３０、タスク管理部１４０、Ｗｉｋｉ管理部１５０、及びユーザ情報管理部１６０を備える。
【００３５】
文書ＤＢ１００は、文書管理装置１０が管理する対象の文書を記憶するデータベースである。文書ＤＢ１００は、例えば、階層構造を構成するフォルダ（ディレクトリ）に文書のファイルを格納する形式のデータベースであってよい。
【００３６】
タスクＤＢ１０２は、電子掲示板の情報を記憶するデータベースである。電子掲示板とは、インターネット又はＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などのネットワークを通じて、複数のユーザによる情報の書き込み（投稿）及び閲覧を可能とするシステムである。本実施形態の例では、電子掲示板は、業務における作業の課題あるいは目標である「タスク」ごとに設定され、当該タスクについてのユーザ間の情報交換に用いられる。したがって、以下の説明では、電子掲示板を「タスク」と呼ぶ。
【００３７】
ＷｉｋｉＤＢ１０４は、Ｗｉｋｉのシステムに従ったｗｅｂページの情報を記憶するデータベースである。Ｗｉｋｉとは、ｗｅｂブラウザ上でユーザによる編集が可能なｗｅｂページを提供するシステムである。ＷｉｋｉＤＢ１０４は、ｗｅｂページを表すファイルを記憶する。以下では、Ｗｉｋｉのシステムに従ったｗｅｂページを単に「Ｗｉｋｉ」と呼ぶ。
【００３８】
後に詳述するが、文書管理装置１０において、文書ＤＢ１００に登録された文書に関連する関連情報として、他の文書、タスク、及びＷｉｋｉの少なくともいずれかの種類の情報が文書ＤＢ１００、タスクＤＢ１０２、及びＷｉｋｉＤＢ１０４から取得される。したがって、本実施形態の例において、文書ＤＢ１００、タスクＤＢ１０２、及びＷｉｋｉＤＢ１０４を、文書の関連情報の候補となる情報を記憶した記憶手段であると捉えてもよい。
【００３９】
文書管理情報ＤＢ１１０は、文書ＤＢ１００に登録された文書の管理に用いられる情報を記憶するデータベースである。本例の文書管理情報ＤＢ１１０は、各文書の属性情報及び各文書の関連情報を特定するための情報を記憶する。図２に、文書管理情報ＤＢ１１０のデータ内容の一例を示す。
【００４０】
図２の例の表では、各文書の識別情報である文書ＩＤに対応づけて、ファイル名、改訂番号、検索式、関連期間、関連文書ＩＤ、関連タスクＩＤ、及び関連ＷｉｋｉＩＤの各項目の値が登録されている。このうち、ファイル名及び改訂番号は文書の属性情報であり、その他の項目は文書の関連情報を特定するための情報である。ファイル名は、対応する文書のファイルの名称である。改訂番号は、対応する文書のバージョン（版）を表す。図２の例では、ファイル名と改訂版号との組によって特定される文書のそれぞれに対して文書ＩＤが付与されている。検索式は、対応する文書の関連情報の検索に用いられる検索条件を表す。文書の関連情報とは、対応する文書自体とは異なる情報であって、対応する文書の内容などに関連する情報である。本実施形態の例において、文書の関連情報として、他の文書、タスク、及びＷｉｋｉの少なくともいずれかの種類の情報が存在し得る。図２の例の表では、文書、タスク、及びＷｉｋｉの３種類の関連情報のそれぞれについて検索式が登録されている。関連期間は、対応する文書の関連情報に変化の生じ得る期間として求められた期間を表す。図２の例において、関連期間についても、検索式と同様、３種類の関連情報のそれぞれについて登録されている。図２の例の表の関連文書ＩＤ、関連タスクＩＤ、及び関連ＷｉｋｉＩＤの各項目は、それぞれ、対応する文書の関連情報として文書ＤＢ１００、タスクＤＢ１０２、及びＷｉｋｉＤＢ１０４から検索された文書、タスク、及びＷｉｋｉの識別情報を表す。関連情報の検索は、対応する文書の検索式に従って行われる。検索式の生成、関連期間の決定、及び関連情報の検索の詳細は後述する。
【００４１】
文書管理情報ＤＢ１１０において、各文書とその関連情報を特定するための情報とが対応づけられて登録されていれば、属性情報の登録は省略してもよい。また、登録される項目及び各項目の値の具体的な態様は、図２の例の表に限定されない。例えば、各文書の属性情報として、アクセス権、文書ＤＢ１００における格納位置を表す情報、作成者、更新者、文書ＤＢ１００への登録時期、及び文書の更新時期などの項目の少なくともいずれかを登録しておいてもよい。
【００４２】
図１の説明に戻り、ユーザ情報ＤＢ１２０は、文書管理装置１０が管理する文書のユーザに関する情報を記憶するデータベースである。ユーザ情報ＤＢ１２０は、例えば、各ユーザのユーザＩＤ及び認証情報を記憶する。また、本例のユーザ情報ＤＢ１２０は、さらに、各ユーザが所属する組織（グループ）の情報を記憶する。例えば、各組織の構成員であるユーザを表す情報と、複数の組織の間の関係を表す情報と、を記憶する。組織の間の関係とは、例えば、組織が構成する階層構造における上位／下位の関係である。例えば、文書管理装置１０で管理される文書を利用する複数の組織が図３に例示する階層構造（ツリー構造）を構成する場合に、ユーザ情報ＤＢ１２０は、各組織Ａ，Ｂ，Ｃ，Ｄのツリー構造における親又は子に該当する組織を表す情報を記憶する。
【００４３】
再び図１を参照し、文書管理部１３０は、文書ＤＢ１００に登録される文書を管理する処理を行う。文書管理部１３０は、検索式生成部１３２及び関連情報登録部１３４を備える。文書管理部１３０は、例えば、新規文書を文書ＤＢ１００に登録したり、文書ＤＢ１００に登録済みの文書を更新あるいは削除したりする処理を行う。また例えば、文書管理部１３０は、文書ＤＢ１００に登録された文書のアクセス制限を行うこともある。また、文書管理部１３０は、文書ＤＢ１００における文書の登録又は更新など、文書ＤＢ１００のデータ内容を変更する処理を行うと、その処理対象の文書の管理に用いる情報を文書管理情報ＤＢ１１０に登録する。例えば、新規文書を文書ＤＢ１００に登録した場合、文書管理部１３０は、当該新規文書に対して文書ＩＤを付与して、その文書ＩＤに対応づけて当該新規文書の属性情報を文書管理情報ＤＢ１１０に登録する。また例えば、文書ＤＢ１００に登録済みの文書が更新された場合、その更新後の文書に対して新たに文書ＩＤを付与して、その文書ＩＤに対応づけて当該更新後の文書の属性情報を文書管理情報ＤＢ１１０に登録する。
【００４４】
以下、文書管理情報ＤＢ１１０において図２に例示する項目を各文書について保持する場合を例にとり、文書管理情報ＤＢ１１０への新規文書又は更新後の文書の登録処理の例を説明する。文書管理部１３０は、文書管理情報ＤＢ１１０において新規レコード（図２の例の表の１行に対応）を１つ生成し、生成したレコードの文書ＩＤの項目の値として新規文書又は更新後の文書に付与した文書ＩＤを設定する。そして、生成したレコードのファイル名の項目に新規文書又は更新後の文書のファイル名を設定する。改訂番号の項目には、新規文書の場合は最初のバージョンであることを示す値（例えば、「１」，「０」など）を設定し、更新後の文書の場合は更新前の文書の１つ後のバージョンであることを示す値を設定する。なお、この時点では、生成したレコードの検索式、関連期間、及び関連情報の識別情報の各項目の値は空である。検索式及び関連期間の項目の値は、検索式生成部１３２によって生成されて登録され、関連情報の各項目の値は、関連情報登録部１３４によって求められて登録される。
【００４５】
検索式生成部１３２は、文書の関連情報を検索するための検索式を生成する。検索式生成部１３２は、さらに、文書の関連期間を求める。検索式生成部１３２は、文書管理情報ＤＢ１１０の各レコードに対応する文書であって未だ検索式の値が設定されていない文書を処理対象として検索式を生成する。また、処理対象の文書の関連期間も求める。検索式及び関連期間の値は、文書管理情報ＤＢ１１０において処理対象の文書に対応するレコードの検索式及び関連期間の項目に登録される（図２参照）。
【００４６】
関連情報登録部１３４は、検索式生成部１３２が生成した検索式を用いて文書の関連情報を検索し、検索結果を文書管理情報ＤＢ１１０に登録する。関連情報登録部１３４は、文書ＤＢ１００、タスクＤＢ１０２、及びＷｉｋｉＤＢ１０４のそれぞれを検索し、検索結果の文書、タスク、及びＷｉｋｉの識別情報を処理対象の文書に対応づけて文書管理情報ＤＢ１１０に登録する（図２参照）。なお、本例において、関連情報登録部１３４は、タスクＤＢ１０２及びＷｉｋｉＤＢ１０４に対し、それぞれ後述のタスク管理部１４０及びＷｉｋｉ管理部１５０を介してアクセスする。
【００４７】
以上で説明した文書管理部１３０によると、新規文書だけでなく、文書ＤＢ１００において文書が更新された場合の更新後の文書に対しても文書ＩＤが付与されて、その属性情報、検索式、関連期間、及び関連情報のＩＤが文書管理情報ＤＢ１１０に登録される。したがって、更新前の文書と更新後の文書とのそれぞれについて属性情報及び関連情報のＩＤなどの登録が行われる。これにより、文書ＤＢ１００において、更新後の文書で更新前の文書が上書きされ、文書ＤＢ１００内に更新前の文書が存在しない状態になったとしても、文書管理情報ＤＢ１１０は、更新前の文書の属性情報及び関連情報を保持したままになる。このことから、文書管理情報ＤＢ１１０を、管理対象の文書の更新の履歴を記憶するデータベースであると捉えてもよい。
【００４８】
タスク管理部１４０は、タスクＤＢ１０２に登録されるタスクを管理する。タスク管理部１４０は、例えば、図示しないクライアント端末などの装置からタスクの生成の要求を受け付けると、新規タスクを生成し、生成したタスクに識別情報（タスクＩＤ）を付与してタスクＤＢ１０２に登録する。また、タスク管理部１４０は、タスクＤＢ１０２に登録済みのタスクについて、情報の投稿及び閲覧を管理する。また、タスク管理部１４０は、文書管理部１３０からの要求に応じて、タスクＤＢ１０２に登録されたタスクの情報を文書管理部１３０に渡すこともある。
【００４９】
Ｗｉｋｉ管理部１５０は、ＷｉｋｉＤＢ１０４に登録されるＷｉｋｉを管理する。Ｗｉｋｉ管理部１５０は、例えば、図示しないクライアント端末などの装置からＷｉｋｉの生成の要求を受け付けると、新規Ｗｉｋｉを生成し、生成したＷｉｋｉに識別情報（ＷｉｋｉＩＤ）を付与してタスクＤＢ１０２に登録する。また、Ｗｉｋｉ管理部１５０は、文書管理部１３０からの要求に応じて、ＷｉｋｉＤＢ１０４に登録されたＷｉｋｉの情報を文書管理部１３０に渡すこともある。
【００５０】
ユーザ情報管理部１６０は、ユーザ情報ＤＢ１２０に登録されるユーザに関する情報を管理する。例えば、ユーザ情報管理部１６０は、クライアント端末などの装置を用いて文書管理装置１０が備える各種のデータベースの利用を要求するユーザのユーザ認証処理を行う。また例えば、ユーザ情報管理部１６０は、文書管理部１３０、タスク管理部１４０、及びＷｉｋｉ管理部１５０からの要求に応じて、ユーザ情報ＤＢ１２０に登録された情報を要求元の各部に渡すこともある。
【００５１】
以上、文書管理装置１０の構成の例を説明した。以下、文書管理装置１０で行われる処理の例を説明する。
【００５２】
図４は、文書管理部１３０の検索式生成部１３２が行う検索式生成処理の手順の例を示すフローチャートである。検索式生成部１３２は、例えば、文書ＤＢ１００に新規文書が登録されるか、又は、文書ＤＢ１００に登録済みの文書が更新された場合に、その新規文書又は更新後の文書を処理対象（対象文書）として図４の例の手順の処理を実行する。すなわち、図４の例の手順の処理は、文書管理情報ＤＢ１１０において新たなレコードが登録される場合に実行される。
【００５３】
図４を参照し、まず、検索式生成部１３２は、対象文書からキーワードを抽出する（ステップＳ１０）。ステップＳ１０の処理は、文書の特徴を表すキーワードの抽出において一般的な技術を用いて行えばよい。例えば、対象文書に含まれるすべての単語それぞれについて重みを計算し、予め設定された閾値以上の重みを有する単語をキーワードとして抽出する。あるいは、対象文書に含まれるすべての単語ではなく、対象文書の特定の部分に含まれる単語のそれぞれについて重みを計算してもよい。例えば、対象文書が文書ＤＢ１００に新規登録された文書ではなく更新された文書である場合、更新に関わる部分の単語について重みを計算する。更新に関わる部分の単語の例として、更新前の単語、更新後の単語、更新において変更があった章又は節に含まれる単語、変更があった章又は節のタイトルに含まれる単語などが挙げられる。
【００５４】
なお、ある単語ｗの重みＷＴ（ｗ）は、例えば、次の式（１）に従って計算すればよい。
【００５５】
ＷＴ（ｗ）＝ｔｆ（ｗ）×ｉｄｆ（ｗ）×α（ｗ）          （１）
【００５６】
式（１）において、ｔｆ（ｗ）は、対象文書における単語ｗの出現頻度であり、ｉｄｆ（ｗ）は、単語ｗの逆出現頻度と呼ばれる値であり、α（ｗ）は、補正係数である。
【００５７】
逆出現頻度ｉｄｆ（ｗ）は、文書ＤＢ１００に登録された文書の全体にわたって出現する単語の重みを小さくするための項である。ｉｄｆ（ｗ）は、文書ＤＢ１００に登録された文書のうち単語ｗを含む文書の数が多いほど小さな値となる。ｉｄｆ（ｗ）は、例えば、文書ＤＢ１００に登録された文書のうち単語ｗを含む文書の数をｄｆ＿ｗとし、文書ＤＢ１００に登録された文書の総数をＮとして、次の式（２）によって求められる。
【００５８】
ｉｄｆ（ｗ）＝ｌｏｇ（Ｎ／ｄｆ＿ｗ）          （２）
【００５９】
補正係数α（ｗ）は、単語ｗが予め設定された条件を満たす場合の補正値である。補正係数αの値は、例えば、単語ｗが一般語として予め登録された単語である場合に、重みＷＴ（ｗ）を小さくするように（α（ｗ）＜１．０など）設定される。また例えば、対象文書の節又は章のタイトルなど、対象文書の特徴を表すと考えられる部分に単語ｗが出現する場合に重みＷＴ（ｗ）を大きくするように補正係数αの値が設定される（α（ｗ）＞１．０など）。補正係数αの値は、以上のような例の条件ごとに予め決定される。なお、単語ｗが補正係数αに関して設定されている条件のいずれも満たさない場合は、例えば、α（ｗ）＝１．０として式（１）の計算が行われる。
【００６０】
検索式生成部１３２は、上述のように計算した重みが予め設定された閾値以上である単語をキーワードとして対象文書から抽出する。
【００６１】
検索式生成部１３２は、抽出したキーワードによって、関連情報を検索する（ステップＳ１２）。ステップＳ１２で、検索式生成部１３２は、文書ＤＢ１００、タスクＤＢ１０２、及びＷｉｋｉＤＢ１０４の各データベースに対して、ステップＳ１０で抽出したキーワードをキーとする検索を実行する。この検索の結果、関連情報として、キーワードを含む文書、タスク、及びＷｉｋｉが各ＤＢ１００，１０２，１０４から取得される。また、取得された文書、タスク、及びＷｉｋｉのそれぞれに対して、予め設定されたアルゴリズムに従って検索スコアが決定される。検索スコアは、検索結果の優先順位を表す値であり、本例では、優先順位が高い検索結果ほど大きな検索スコアを有するものとする。検索スコアは、例えば、キーワードを含む文書、タスク、又はＷｉｋｉにおいて、キーワードの出現する位置、出現回数、フォントや文字サイズなど、当該キーワードと当該文書、タスク、又はＷｉｋｉと、の間の関係を表す要素に応じて決定される値であってよい。検索スコアを決定するアルゴリズムは、前述の例のような各要素をどのように考慮してどのように検索スコアを決定するかを表す方針に従った処理手順を表す。このようなアルゴリズムとしては、キーワードを用いた情報の検索の技術で一般的に用いられるアルゴリズムを採用すればよい。また、検索スコアを決定するアルゴリズムは、文書、タスク、及びＷｉｋｉの３種類の関連情報についてそれぞれ異なるものであってよい。
【００６２】
次に、検索式生成部１３２は、ステップＳ１２の検索結果を用いて、対象文書の関係者を取得する（ステップＳ１４）。対象文書の関係者とは、ユーザ情報ＤＢ１２０に登録されたユーザのうち対象文書の関連情報の作成又は更新などを行う可能性が比較的高いと考えられるユーザを表す。ステップＳ１４の関係者取得処理の詳細手順の例を図５に示す。ステップＳ１４が開始されると、図５の例の手順の処理が開始される。
【００６３】
図５を参照し、検索式生成部１３２は、図４のステップＳ１２の検索結果の関連情報それぞれの重みを算出する（ステップＳ１４０）。ステップＳ１４０で、検索式生成部１３２は、ステップＳ１２の検索結果として取得された文書、タスク、及びＷｉｋｉのそれぞれの重みを算出する。各関連情報の重みは、ステップＳ１２で決定された当該関連情報の検索スコアと、当該関連情報の内容が変更された時期に関する情報と、を用いて算出される。
【００６４】
以下、ステップＳ１４０の重みの算出法の例として、タスクの重みを算出する場合の例を説明する。本例では、次の式（３）に従ってタスクＴの重みＷＴ（Ｔ）を算出する。
【００６５】
ＷＴ（Ｔ）＝Ｓ（Ｔ）×β（Ｔ）        （３）
【００６６】
式（３）で、Ｓ（Ｔ）は、図４のステップＳ１２で決定されたタスクＴの検索スコアである。β（Ｔ）は、タスクＴの活性時期と対象文書の登録（又は更新）時期との近さの程度を表す値である。ここでは、β（Ｔ）をタスクＴの対象文書に対する「同期度」と呼ぶ。タスクＴの「活性時期」とは、他の時期と比較して頻繁にタスクＴの内容に変化があった時期を意味する。本例では、タスクＴの電子掲示板に対する情報の投稿（メッセージ又はコメントの書き込みなど）が他の時期よりも頻繁に行われていた時期を活性時期とする。同期度β（Ｔ）の値は、タスクＴの活性時期と対象文書の登録（又は更新）時期とが近いほど大きな値になるような方針に従って決定される。以下の［例１］は、同期度β（Ｔ）の値の決定の方針の例である。
【００６７】
［例１］
（１）「対象文書の登録（又は更新）時期以前の半年間のタスクＴにおける投稿回数がＸ（＞１）以上」かつ「その半年間の投稿回数  ＞  その半年間よりも前の投稿回数の合計」  →  β（Ｔ）＝１．２  （同期度大）
（２）「対象文書の登録（又は更新）時期以前の半年間のタスクＴにおける投稿回数がＸ以上」  →  β（Ｔ）＝１．０
（３）「対象文書の登録（又は更新）時期以前の半年間のタスクＴにおける投稿回数が１回以上」  →  β（Ｔ）＝０．８
（４）「対象文書の登録（又は更新）時期以前の一年間のタスクＴにおける投稿回数が１回以上」  →  β（Ｔ）＝０．５
（５）「対象文書の登録（又は更新）時期以前の一年間のタスクＴにおける投稿回数が０回」  →  β（Ｔ）＝０．３
（６）「対象文書の登録（又は更新）時期以前の三年間のタスクＴにおける投稿回数が０回」  →  β（Ｔ）＝０．１
【００６８】
［例１］の方針に従う場合、検索式生成部１３２は、［例１］の（１）〜（６）の条件をタスクＴが満たすか否かを番号順に確認していき、条件を満たせば、その条件の場合のβ（Ｔ）の値をタスクＴの同期度β（Ｔ）の値とする。なお、タスクＴに対する情報の投稿の回数及び時期の情報は、タスク管理部１４０を介してタスクＤＢ１０２から取得される。
【００６９】
以上で説明したようなタスクＴの重みＷＴ（Ｔ）（式（３））は、図４のステップＳ１２の検索結果としてタスクＤＢ１０２から取得されたすべてのタスクのそれぞれについて算出される。
【００７０】
タスクの他の種類の関連情報である文書及びＷｉｋｉについても、上述と同様の考え方に従って重みを算出してよい。つまり、検索結果の文書Ｄの重みＷＴ（Ｄ）は、文書Ｄの検索スコアＳ（Ｄ）と文書Ｄの対象文書に対する同期度β（Ｄ）との積であってよく、検索結果のＷｉｋｉ：Ｗｋの重みＷＴ（Ｗｋ）は、Ｗｉｋｉ：Ｗｋの検索スコアＳ（Ｗｋ）とＷｉｋｉ：Ｗｋの対象文書に対する同期度β（Ｗｋ）との積であってよい。文書Ｄの同期度β（Ｄ）については、例えば、文書Ｄの更新回数及び更新時期によって文書Ｄの活性時期を定義して求める。文書Ｄの更新回数は、例えば、文書管理情報ＤＢ１１０において、文書Ｄと同一のファイル名を有し、異なる改訂番号を有するレコードの個数を求めることで求められる。上記の［例１］においてタスクＴの「投稿回数」を文書Ｄの「更新回数」として文書Ｄの同期度β（Ｄ）を求めてもよい。Ｗｉｋｉ：Ｗｋの同期度β（Ｗｋ）は、例えば、Ｗｉｋｉ：Ｗｋの編集回数及び編集時期によってＷｉｋｉ：Ｗｋの活性時期を定義して求める。例えば、上記の［例１］においてタスクＴの「投稿回数」をＷｉｋｉ：Ｗｋの「編集回数」としてＷｉｋｉ：Ｗｋの同期度β（Ｗｋ）を求めてもよい。なお、Ｗｉｋｉ：Ｗｋの編集回数及び編集時期は、Ｗｉｋｉ管理部１５０を介してＷｉｋｉＤＢ１０４から取得される。
【００７１】
ステップＳ１４０で関連情報それぞれの重みを求めた後、検索式生成部１３２は、予め設定された閾値以上の重みを有する関連情報の内容に関与するユーザ（以下、「関与ユーザ」と呼ぶ）のユーザＩＤを取得する（ステップＳ１４２）。ここで、関与ユーザとは、関連情報が文書であれば当該文書の作成者及び更新者であってよい。文書の作成者及び更新者のユーザＩＤは、当該文書の属性情報から取得される。また、当該文書に対する編集（更新）権限のあるユーザが文書の属性情報に明示的に設定されていれば、これらのユーザも文書の属性情報から取得して関与ユーザとしてよい。関連情報がタスクであれば、当該タスクに情報を投稿したことのあるユーザを関与ユーザとすればよい。当該タスクに情報を投稿する権限のあるユーザが明示的に設定されていれば、これらのユーザも関与ユーザに含まれていてよい。タスクへの情報の投稿者や投稿権限のあるユーザのユーザＩＤは、タスク管理部１４０を介してタスクＤＢ１０２から取得される。関連情報がＷｉｋｉであれば、当該Ｗｉｋｉを編集したことのあるユーザを関与ユーザとしてよく、当該Ｗｉｋｉに対する編集権限のあるユーザが明示的に設定されていれば、これらのユーザも関与ユーザとしてよい。また、Ｗｉｋｉの編集者や編集権限のあるユーザのユーザＩＤは、Ｗｉｋｉ管理部１５０を介してＷｉｋｉＤＢ１０４から取得される。
【００７２】
そして、検索式生成部１３２は、ステップＳ１４２で取得した関与ユーザそれぞれの重みを算出する（ステップＳ１４４）。本例において、関与ユーザの重みは、関連情報の種類ごとに求められる。
【００７３】
以下、タスクの関与ユーザの重みを求める場合を例にとりステップＳ１４４の処理の例を説明する。本例では、タスクの関与ユーザＵｔの重みＷＴ（Ｕｔ）は、次の式（４）に従って算出される。
【００７４】
ＷＴ（Ｕｔ）＝Σ（Ｐ＿Ｔｉ（Ｕｔ）×ρ＿Ｔｉ（Ｕｔ））×γ（Ｕｔ）      （４）
【００７５】
式（４）の第一項のΣは、ｉ＝１，２，・・・，Ｋについて計算され、Ｋは、ステップＳ１４０で算出されたタスクの重みＷＴ（Ｔ）が予め設定された閾値以上であるタスクの個数である。また、式（４）で、Ｐ＿Ｔｉ（Ｕｔ）は、タスクＴｉでの関与ユーザＵｔの投稿回数を表し、ρ＿Ｔｉ（Ｕｔ）は、タスクＴｉでの関与ユーザＵｔのロールに基づく補正係数を表す。タスクにおけるユーザのロールは、当該タスクにおいてユーザに対して設定された役割であり、タスク管理部１４０を介してタスクＤＢ１０２から取得される。ロールの種類の例として、「リーダー」、「メンバー」、及び「オブザーバー」などが挙げられる。ロールに基づく補正係数ρ＿Ｔｉ（Ｕｔ）は、例えば、ユーザＵｔが「リーダー」であれば１．２、「メンバー」であれば１．０、「オブザーバー」であれば０．８、ロールの設定がなければ０．５などのように、予め設定しておく。式（４）のγ（Ｕｔ）は、関与ユーザＵｔと対象文書を作成又は更新したユーザとの間の組織上の関係に基づく補正係数を表す。この組織上の関係は、ユーザ情報管理部１６０を介してユーザ情報ＤＢ１２０から取得すればよい。γ（Ｕｔ）は、組織が構成するツリー構造（図３参照）において、関与ユーザＵｔの所属する組織と対象文書の作成者又は更新者の所属する組織とが近いほど大きな値となるように決定される。例えば、次の［例２］の方針に従ってγ（Ｕｔ）の値を決定してもよい。
【００７６】
［例２］
・関与ユーザＵｔと対象文書の作成者又は更新者とが同一の組織に所属する。
→  γ（Ｕｔ）＝１．０
・関与ユーザＵｔの所属する組織が対象文書の作成者又は更新者の所属する組織に対してツリー構造において１親等又は２親等の関係である。
→  γ（Ｕｔ）＝０．８
・関与ユーザＵｔの所属する組織が対象文書の作成者又は更新者の所属する組織に対してツリー構造において３親等又は４親等の関係である。
→  γ（Ｕｔ）＝０．５
・関与ユーザＵｔの所属する組織が対象文書の作成者又は更新者の所属する組織に対してツリー構造において５親等以上離れている。
→  γ（Ｕｔ）＝０．３
【００７７】
以上の説明のとおりにタスクの関与ユーザＵｔの重みＷＴ（Ｕｔ）を算出する場合の具体例を以下に述べる。例えば、ステップＳ１４０で算出されたタスクＴの重みＷＴ（Ｔ）が予め設定された閾値以上であるタスクがＴ１，Ｔ２，Ｔ３の３つであったとする。そして、タスクＴ１，Ｔ２，Ｔ３のそれぞれにおいて、関与ユーザＵｔのロールがそれぞれ「メンバー」、「メンバー」、及び「オブザーバー」であり、関与ユーザＵｔの投稿回数がそれぞれ１０回、５回、及び５回であったとする。さらに、関与ユーザＵｔが図３の例の組織のツリー構造における組織Ｄに所属し、対象文書の作成者又は更新者が図３の例の組織Ｃに所属するとする。このとき、関与ユーザＵｔの重みＷＴ（Ｕｔ）は、式（４）に従って、次のように算出される。
【００７８】
ＷＴ（Ｕｔ）＝｛１０（＝Ｐ＿Ｔ１（Ｕｔ））×１．０（＝ρ＿Ｔ１（Ｕｔ））
＋５（＝Ｐ＿Ｔ２（Ｕｔ））×１．０（＝ρ＿Ｔ２（Ｕｔ））
＋５（＝Ｐ＿Ｔ３（Ｕｔ））×０．８（＝ρ＿Ｔ３（Ｕｔ））｝
×０．８（＝γ（Ｕｔ））
＝１５．２
【００７９】
タスクの他の種類の関連情報である文書及びＷｉｋｉの関与ユーザについても、上述と類似の考え方に従って重みを算出してよい。例えば、文書の関与ユーザＵｄの重みＷＴ（Ｕｄ）について、ステップＳ１４０で算出された文書の重みＷＴ（Ｄ）が予め設定された閾値以上であるＫ個の文書Ｄｉ（ｉ＝１，・・・，Ｋ）に関して、関与ユーザＵｄの文書Ｄｉの更新回数の和を求め、この和と、組織上の関係に基づく補正係数γ（Ｕｄ）と、の間の積を求める。文書について、ユーザの文書に対するロール（作成者、更新者、承認者など）が設定されている場合は、タスクの例と同様にロールに基づく補正係数ρを用いてもよい。なお、組織上の関係に基づく補正係数γ（Ｕｄ）は、タスクの関与ユーザＵｔに関して説明した補正係数γ（Ｕｔ）と同様に求められる。また、Ｗｉｋｉの関与ユーザＵｗｋの重みＷＴ（Ｕｗｋ）については、例えば、ステップＳ１４０で算出されたＷｉｋｉの重みＷＴ（Ｗｋ）が予め設定された閾値以上であるＫ個の文書Ｗｉｋｉ：ｉ（ｉ＝１，・・・，Ｋ）に関して、関与ユーザＵｗｋのＷｉｋｉ：ｉの編集回数の和を求め、この和と、組織上の関係に基づく補正係数γ（Ｕｗｋ）と、の間の積を求める。Ｗｉｋｉについても、ユーザのロールが設定されていれば、タスクの例と同様の補正係数ρを用いてもよい。また、組織に関する補正係数γ（Ｕｗｋ）は、タスクの例の補正係数γ（Ｕｔ）と同様に求められる。
【００８０】
関与ユーザのそれぞれについて重みを算出した後、検索式生成部１３２は、算出した重みが予め設定された閾値以上である関与ユーザを対象文書の関係者として選択する（ステップＳ１４６）。本例では、文書、タスク、及びＷｉｋｉの３種類の関連情報のそれぞれに対して、関係者の選択の閾値として異なる値が予め設定されており、対象文書の関係者は、文書、タスク、及びＷｉｋｉの各種類について選択される。ステップＳ１４６の後、図５の例の手順の処理は終了し、処理は図４のステップＳ１６に進む。
【００８１】
図４のステップＳ１６で、検索式生成部１３２は、ステップＳ１２の検索結果を用いて、対象文書の関連情報が変化し得る期間である関連期間を予測する（ステップＳ１６）。ステップＳ１６の関連期間予測処理の詳細手順の例を図６に示す。ステップＳ１６が開始されると、図６の例の手順の処理が開始される。
【００８２】
図６を参照し、検索式生成部１３２は、図４のステップＳ１２の検索結果の関連情報それぞれの変更時期情報を取得する（ステップＳ１５０）。ここで、変更時期情報とは、関連情報が文書であれば、文書の更新が行われた回数及び各更新の時期を意味する。関連情報がタスクであれば、タスクに対する投稿が行われた回数及び各投稿が行われた時期を意味する。また、関連情報がＷｉｋｉであれば、Ｗｉｋｉに対する編集が行われた回数及び各編集が行われた時期を意味する。
【００８３】
次に、文書、タスク、及びＷｉｋｉのそれぞれについて、検索結果の関連情報のすべての変更時期情報を用いて、変更回数の時間変化を求める（ステップＳ１５２）。例えば、各種類の関連情報について、横軸を時間とし、縦軸を変更の回数とするヒストグラムを生成する。図７（ａ）に、ステップＳ１５２で生成されるヒストグラムの一例を示す。図７（ａ）において、時間軸上の「作成／更新日」は、対象文書が作成又は更新された日を表す。ヒストグラムの縦軸の変更回数の値は、文書については、図４のステップＳ１２の検索結果として得られたすべての文書に関する、該当期間内に行われた更新の回数の和を表す。タスクについては、図４のステップＳ１２の検索結果として得られたすべてのタスクに関する、該当期間内に行われた投稿の回数の和を表す。Ｗｉｋｉについては、図４のステップＳ１２の検索結果として得られたすべてのＷｉｋｉに関する、当該期間内に行われた編集の回数の和を表す。
【００８４】
ステップＳ１５２で求めた変更回数の時間変化に基づいて、検索式生成部１３２は、対象文書の関連期間を予測する（ステップＳ１５４）。この予測は、統計的な手法を用いて行えばよい。例えば、文書、タスク、及びＷｉｋｉのそれぞれについて、各ＤＢへの登録の時点から変更（更新、投稿、及び編集）が行われなくなるまでの変更回数の時間変化を実際に観測し、変更回数のヒストグラムの形状のパターンを予め生成して保持しておく。ヒストグラムの形状のパターンは、例えば、複数の観測結果における変更回数の平均を取って求める。また、複数の種類の形状のパターンを生成しておいてもよい。図７（ｂ）に、予め生成されるヒストグラムの形状のパターンの一例を示す。検索式生成部１３２は、ステップＳ１５２で求めた変更回数のヒストグラムの形状と、保持しておいたパターンの形状と、を比較することで、ステップＳ１５２で求めたヒストグラムにおいて変更回数が０（又は、予め設定された閾値以下）に収束する時期を予測する。この予測した収束時期が関連期間の終期となる。例えば、図７（ａ）及び図７（ｂ）を参照し、予め生成されたパターン（図７（ｂ））のピーク時期Ｐから収束時期Ｅまでの期間ｘを求め、ステップＳ１５２で生成したヒストグラムのピーク時期から、求めた期間ｘだけ経過した時点を関連期間の終期として予測する。
【００８５】
ステップＳ１５４の後、図６の例の手順の処理は終了し、処理は、図４のステップＳ１８に進む。
【００８６】
再び図４を参照し、関連期間の予測が終了すると、検索式生成部１３２は、ステップＳ１２で抽出したキーワード及びステップＳ１４で取得した関係者を用いて検索式を生成する（ステップＳ１８）。本例において、ステップＳ１４では、３種類の関連情報のそれぞれについて関係者が求められるため、ステップＳ１８では、３種類の関連情報のそれぞれの関係者を用いて、３種類の関連情報のそれぞれについての検索式が生成される。ステップＳ１８で生成される検索式は、例えば、抽出したキーワードに関する条件と関係者に関する条件とを論理式のＡＮＤ演算子で結合した式により表される。キーワードに関する条件の例として、関連情報が「特定のキーワードを含む」、「特定のキーワードを特定の部分（タイトル等）に含む」、及び、「特定のキーワードを含まない」などが挙げられる。また、関係者に関する条件の例として、関連情報が「関係者によって作成された」、「関係者によって更新（又は編集）された」、及び「関係者を関与ユーザに含む」などが挙げられる。また、ステップＳ１８で、検索式生成部１３２は、キーワード及び関係者だけでなく、ステップＳ１６で予測された関連期間についての条件を含む検索式を生成してもよい。関連期間を用いる条件の例としては、関連情報が「関連期間内に関係者によって作成された」、及び、「関連期間内に関係者によって更新（又は編集）された」などが考えられる。
【００８７】
検索式を生成すると、検索式生成部１３２は、生成した検索式及びステップＳ１６で求めた関連期間を対象文書に対応づけて文書管理情報ＤＢ１１０に登録する（ステップＳ２０）。
【００８８】
以上で説明した図４の例の手順において、ステップＳ１０で対象文書からキーワードを抽出する代わりに、ユーザ又は管理者などによるキーワードの指定を受け付けてもよい。この場合、図４のステップＳ１０で、図示しない入力装置を介して、ユーザ又は管理者が指定するキーワードの入力を受け付け、入力されたキーワードを用いてステップＳ１２以下の処理を上述と同様に実行する。
【００８９】
以上、図４〜図７を参照して説明した処理によって生成されて文書管理情報ＤＢ１１０に登録された検索式を用いて、文書管理部１３０の関連情報登録部１３４は、文書の関連情報を検索する。この検索結果の関連情報は、対応する文書の関連情報として文書管理情報ＤＢ１１０に登録される。
【００９０】
図８は、関連情報登録部１３４が行う関連情報登録処理の手順の例を示すフローチャートである。関連情報登録部１３４は、文書管理情報ＤＢ１１０の各文書について、図８の例の手順の処理を実行する。
【００９１】
図８を参照し、関連情報登録部１３４は、対象文書について関連情報の検索を実行するか否かを判定する（ステップＳ３０）。この判定のための条件は、例えばシステムの管理者などにより予め設定される。例えば、関連期間内に一定の時間間隔で定期的に行うように条件を設定しておく。あるいは、例えば、関連期間の終了時以降に１回だけ検索を行うように条件を設定しておいてもよい。なお、本実施形態の例では、文書管理情報ＤＢ１１０中の各文書に対して、文書、タスク、及びＷｉｋｉの３種類の関連情報のそれぞれについて関連期間が設定されるため、ステップＳ３０で、３種類すべてではなく、１種類又は２種類の関連情報の検索を実行することが判定される場合もある。
【００９２】
ステップＳ３０で検索を実行しないと判定した場合は、ステップＳ３０の判定を繰り返し、検索を実行すると判定した場合は、ステップＳ３２に進む。
【００９３】
ステップＳ３２で、関連情報登録部１３４は、文書管理情報ＤＢ１１０から対象文書の検索式を取得する。このとき、関連情報登録部１３４は、ステップＳ３０で決定した種類の関連情報に対する検索式を取得する。
【００９４】
次に、取得した検索式に従って関連情報を検索する（ステップＳ３４）。ステップＳ３０で検索を実行すると判定された種類の関連情報のそれぞれに対して、文書ＤＢ１００、タスクＤＢ１０２、及びＷｉｋｉＤＢ１０４のうち該当するデータベースの中から、ステップＳ３２で取得した検索式を用いて検索を実行する。この検索結果の関連情報には、それぞれ、予め設定されたアルゴリズムに従って検索スコアが決定される。検索スコアは、検索式に適合する度合いを表す値である。検索スコアは、例えば、検索式に含まれるキーワードや関係者と、検索結果の関連情報と、の間の関係を表す要素に応じて決定される値であってよい。キーワードや関係者と関連情報との間の関係を表す要素の例として、キーワードの出現回数、出現位置、フォント、文字サイズ、関係者が関連情報に対して行った操作、又は、関係者と関連情報の関与ユーザとの間の包含関係などが挙げられる。検索スコアを決定するアルゴリズムは、前述の例のような各要素をどのように考慮してどのように検索スコアを決定するかを表す方針に従った処理手順を表し、情報を検索する技術において一般的なアルゴリズムを用いてよい。
【００９５】
次に、関連情報登録部１３４は、ステップＳ３４の検索結果として得られる関連情報の検索スコアを補正する（ステップＳ３６）。検索スコアの補正は、例えば、上述の検索式生成処理で考慮されない情報を用いて行ってよい。以下、文書、タスク、及びＷｉｋｉの各種類について、検索スコアの補正の例を述べる。
【００９６】
文書の検索スコアの補正の一例は、「対象文書の関連タスクとなり得るタスク（ステップＳ３４の検索結果のタスクのうち検索スコアが比較的高いタスク）を関連タスクとして有する他の文書は、対象文書の関連文書である可能性が高い」という考え方に基づいて行われる。この例で、関連情報登録部１３４は、ステップＳ３４の検索結果のタスクのうち検索スコアが上位であるタスク又は検索スコアが予め設定された閾値以上であるタスクについて、そのタスクＩＤが関連タスクＩＤとして登録されたレコードを文書管理情報ＤＢ１１０から取得する。そして、取得したレコードに対応する文書がステップＳ３４の検索結果の文書の中に存在すれば、該当する文書の検索スコアをより大きくする補正を行う。例えば、該当する文書の検索スコアに一定の値を加算したり、該当する文書の検索スコアに対して１より大きい一定の値を乗算したりする。
【００９７】
タスクの検索スコアの補正の一例では、ステップＳ３４の検索結果のタスクのうち、すでに対象文書との関連づけがユーザによって示されているタスクについて、検索スコアをより大きくするよう補正する。例えば、電子掲示板（タスク）に対する情報の投稿の１つの態様として、文書のアップロードが可能である場合がある。この場合、タスクにアップロードされた文書は、文書管理装置１０において、タスク管理部１４０から文書管理部１３０に渡され、文書管理部１３０によって文書ＤＢ１００に登録される。このとき、文書管理部１３０は、タスクにおいて当該文書がアップロードされた旨を表す情報と当該タスクのタスクＩＤとを、例えば当該文書の属性情報として文書ＤＢ１００に登録する。あるいは、例えば、文書を文書管理装置１０に登録するときに、ユーザが、当該文書に関連するタスクを明示的に指示する場合もある。このような指示を文書の登録時に受け付けると、文書管理部１３０は、例えば当該文書の属性情報の一部として、指示されたタスクのタスクＩＤを文書ＤＢ１００に登録する。以上の例のようにして登録された文書は、ユーザによってタスクに関連づけられている。このような文書が対象文書である場合に、ステップＳ３４の検索結果のタスクの中に、ユーザによって対象文書に関連づけられているタスクが存在すれば、関連情報登録部１３４は、そのタスクの検索スコアをより大きくする補正を行う。
【００９８】
タスクの検索スコアの補正の他の一例では、ステップＳ３４の検索結果のタスクのうち、検索スコアが上位であるタスク又は検索スコアが予め設定された閾値以上であるタスクと類似した構造を有するタスクの検索スコアをより大きくする。タスクの構造とは、例えば、タスクに投稿された情報をタスク内で整理するためのデータ構造（ツリー構造など）を意味する。タスク間の構造が類似しているか否かは、タスク管理部１４０に依頼して判定させる。
【００９９】
タスクの検索スコアの補正のさらに他の一例では、ステップＳ３４の検索結果のタスクのうち、その活性時期が対象文書の登録時期又は更新時期に近いタスクの検索スコアをより大きく補正する。タスクの活性時期と対象文書の登録時期又は更新時期との間の近さの尺度としては、図５のステップＳ１４０を参照して説明した、タスクの対象文書に対する同期度βを用いればよい。例えば、上記の［例１］に従って決定した同期度が大きい程、タスクの検索スコアがより大きくなるように補正を行う。
【０１００】
次に、Ｗｉｋｉの検索スコアの補正の例を述べる。Ｗｉｋｉの検索スコアの補正の一例では、「対象文書の関連文書となり得る文書（ステップＳ３４の検索結果の文書のうち検索スコアが比較的高い文書）の関連Ｗｉｋｉは、対象文書の関連Ｗｉｋｉである可能性が高い」という考え方に基づいて行われる。本例で、関連情報登録部１３４は、ステップＳ３４の検索結果の文書のうち検索スコアが上位である文書又は検索スコアが予め設定された閾値以上である文書について、その文書に対応するレコードを文書管理情報ＤＢ１１０から取得する。そして、取得したレコードの関連ＷｉｋｉＩＤの項目に登録されているＷｉｋｉＩＤを有するＷｉｋｉがステップＳ３４の検索結果のＷｉｋｉの中に存在すれば、該当するＷｉｋｉの検索スコアをより大きくする補正を行う。
【０１０１】
Ｗｉｋｉの検索スコアの補正の他の一例では、ステップＳ３４の検索結果のＷｉｋｉのうち、検索スコアが上位であるＷｉｋｉ又は検索スコアが予め設定された閾値以上であるＷｉｋｉと類似した構造を有するＷｉｋｉの検索スコアをより大きくする。Ｗｉｋｉの構造とは、例えば、Ｗｉｋｉに含まれる情報のデータ構造（ツリー構造など）を意味する。Ｗｉｋｉ間の構造が類似しているか否かは、Ｗｉｋｉ管理部１５０に依頼して判定させる。
【０１０２】
以上、各種の検索スコアの補正の例を述べた。ステップＳ３６では、関連情報の種類のそれぞれについて、以上で述べたうちの１つの例の補正を行ってもよいし、複数の例を組み合わせてもよい。また、上述の例と異なる方針に従って検索スコアを補正してもよい。
【０１０３】
検索スコアの補正の後、関連情報登録部１３４は、検索スコアが閾値以上である関連情報を対象文書の関連情報として文書管理情報ＤＢ１１０に登録する（ステップＳ３８）。文書、タスク、及びＷｉｋｉの種類に応じて、文書管理情報ＤＢ１１０における対象文書のレコードの関連文書ＩＤ、関連タスクＩＤ、及び関連ＷｉｋｉＩＤの項目に、検索スコアが閾値以上である候補のＩＤの値を登録する。
【０１０４】
図８の例の手順の処理により、文書管理情報ＤＢ１１０には、図２の例のように、各文書の関連情報が登録される。
【０１０５】
以上で説明した処理の例では、関連情報の種類ごとに、検索式が生成され、関連期間が求められ、対応するデータベースにおいて関連情報の検索が行われる。他の例では、関連情報の種類に関わらず１つの検索式を生成し、１つの関連期間を求めてもよい。この例の場合、関連情報の検索は文書ＤＢ１００、タスクＤＢ１０２、及びＷｉｋｉＤＢ１０４のそれぞれについて行われるが、用いられる検索式及び関連期間は３種類の関連情報で共通である。
【０１０６】
以下、以上で説明したように文書管理情報ＤＢ１１０に登録された関連情報の利用の態様の例を説明する。例えば、文書管理装置１０は、文書管理情報ＤＢ１１０のデータ内容を参照し、文書管理装置１０の表示装置（図示しない）、又は文書管理装置１０に接続されたクライアント端末などの表示装置に各種の表示を行わせる。
【０１０７】
図９に、文書管理装置１０が文書管理情報ＤＢ１１０に登録された情報を用いて表示装置に表示させる表示画面の一例を示す。図９の例は、文書ＤＢ１００におけるフォルダＡに含まれる文書のファイルの一覧と共に、各ファイルの関連タスクを表示した表示画面の例である。文書管理装置１０が図９の例の表示画面を生成する手順の例を以下に述べる。文書管理装置１０は、まず、文書ＤＢ１００からフォルダＡに含まれるファイルを取得し、取得したファイルの一覧Ｌ１を生成する。そして、ファイル一覧Ｌ１と、表示する関連情報の種類の選択を受け付ける選択メニューＭと、を共に表示装置に表示させる。選択メニューＭにおいて、「関連ドキュメント」は、以上の説明における「関連文書」を意味する。図９の例では、選択メニューＭにおいて、ユーザがマウスなどの入力装置を用いて「関連タスク表示」を選択する。この選択を表す情報を受け付けると、文書管理装置１０は、ファイル一覧Ｌ１に含まれる各ファイルに対応づけて文書管理情報ＤＢ１１０に登録された関連タスクＩＤを取得する。そして、取得した関連タスクＩＤのタスクの名称をタスクＤＢ１０２から読み出し、読み出したタスクの名称をファイル一覧Ｌ１の各ファイルに対応づけて表示させる。例えば、図９において、ファイル名「Ａ機能仕様書」のファイルに対応づけて関連タスクの名称「Ａ機能  Ｌ版  開発」及び「Ａ機能  Ｌ版  ＵＩ検討」が表示されている。
【０１０８】
図１０は、文書管理装置１０が表示させる表示画面の他の例を示す。図１０は、１つの文書の改訂番号ごとの関連タスクを表示した表示画面の例である。文書管理装置１０は、例えば、文書ＤＢ１００に登録された「Ａ機能仕様書」のファイルを指定して変更履歴を表示するよう指示する入力を受け付けた場合に、文書管理情報ＤＢ１１０に登録されたレコードのうち、ファイル名が「Ａ機能仕様書」であるレコードを文書管理情報ＤＢ１１０から抽出する。図１０を参照する本例では、ファイル名が「Ａ機能仕様書」であり、改訂番号がそれぞれ「１」，「２」，「３」，「４」である４つのレコードが文書管理情報ＤＢ１１０から抽出される。これらの各レコードは、「Ａ機能仕様書」の各バージョンの属性情報及び関連情報のＩＤを含む。文書管理装置１０は、「Ａ機能仕様書」の各改訂番号のバージョン一覧Ｌ２を生成し、図９の例と同様の選択メニューＭと共に表示装置に表示させる。図１０では、図９と同様、選択メニューＭにおいて、表示する関連情報の種類として「関連タスク表示」が選択されている。この選択指示を受け付けた文書管理装置１０は、前述のように文書管理情報ＤＢ１１０から抽出した各改訂番号のレコードに含まれる関連タスクＩＤの値を取得し、取得した関連タスクＩＤのタスクの名称をバージョン一覧Ｌ２中の各改訂番号に対応づけて表示装置に表示させる。例えば図１０では、改訂番号「１」の関連タスクとして「Ａ機能  Ｈ版  メニュー検討」が表示されている。
【０１０９】
図１１は、文書管理装置１０が表示させる表示画面のさらに他の例を示す。図１１は、タスクＤＢ１０２に登録されたタスクの一覧と共に、各タスクの関連文書を表示した表示画面の例である。ここで、タスクの関連文書とは、文書管理情報ＤＢ１１０に登録された文書のうち、当該タスクを関連タスクとする文書を意味する。文書管理装置１０は、例えば、あるユーザが関与するタスクの一覧を表示するよう指示された場合に、当該ユーザが関与ユーザであるタスクをタスクＤＢ１０２から取得してタスク一覧Ｌ３を生成する。タスク一覧Ｌ３は、図９及び図１０の例と同様の選択メニューＭと共に表示装置に表示される。図１１の例では、選択メニューＭにおいて、「関連ドキュメント表示」が選択されている。この選択指示を受け付けると、文書管理装置１０は、文書管理情報ＤＢ１１０を参照し、タスク一覧Ｌ３中の各タスクのタスクＩＤを関連タスクＩＤの項目に含むレコードを抽出する。そして、これらのレコードに含まれる文書のファイル名を、各タスクの関連文書としてタスク一覧Ｌ３中の各タスクに対応づけて表示装置に表示させる。
【０１１０】
以上、図９〜図１１の各例の表示画面において、関連タスク又は関連文書として表示された名称は、当該関連タスクあるいは関連文書へのリンク機能を有していてもよい。つまり、マウスなどの入力装置によって関連タスク又は関連文書の名称が選択された場合に、文書管理装置１０は、その関連タスク又は関連文書の内容をタスクＤＢ１０２又は文書ＤＢ１００から読み出して表示装置に表示させてもよい。
【０１１１】
以上に例示した文書管理装置１０は、典型的には、汎用のコンピュータにて上述の文書管理装置１０の各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図１２に示すように、ＣＰＵ（中央演算装置）８０、メモリ（一次記憶）８２、各種Ｉ／Ｏ（入出力）インタフェース８４等がバス８６を介して接続された回路構成を有する。また、そのバス８６に対し、例えばＩ／Ｏインタフェース８４経由で、ハードディスクドライブ（ＨＤＤ）８８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ９０が接続される。このようなドライブ８８又は９０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ＨＤＤ８８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。
【０１１２】
なお、以上では、文書管理装置１０を１台のコンピュータにより実現する例の実施形態を説明したが、文書管理装置１０の上述の例の各種の機能を複数のコンピュータに分散させて実現してもよい。
【符号の説明】
【０１１３】
１０  文書管理装置、８０  ＣＰＵ、８２  メモリ、８４  Ｉ／Ｏインタフェース、８６  バス、８８  ＨＤＤ、９０  ディスクドライブ、１００  文書ＤＢ、１０２  タスクＤＢ、１０４  ＷｉｋｉＤＢ、１１０  文書管理情報ＤＢ、１２０  ユーザ情報ＤＢ、１３０  文書管理部、１３２  検索式生成部、１３４  関連情報登録部、１４０  タスク管理部、１５０  Ｗｉｋｉ管理部、１６０  ユーザ情報管理部。
【図１】
2011054019.tif 000003
【図２】
2011054019.tif 000004
【図３】
2011054019.tif 000005
【図４】
2011054019.tif 000006
【図５】
2011054019.tif 000007
【図６】
2011054019.tif 000008
【図７】
2011054019.tif 000009
【図８】
2011054019.tif 000010
【図９】
2011054019.tif 000011
【図１０】
2011054019.tif 000012
【図１１】
2011054019.tif 000013
【図１２】
2011054019.tif 000014