JP5247177B2 - 文書管理装置、文書管理方法およびプログラム - Google Patents

Description

本発明は文書管理方法、文書管理装置、情報処理装置および文書管理システムに関する。例えば、ユーザの所属部門や役職などの特性を用いて、文書データの登録時に後で文書データを検索する際に用いるインデックス情報を設定するなどの文書データの管理を行う技術に関するものである。

現在の文書管理システムでは、インデックス情報のうちカテゴリはあらかじめ管理者が設定しておき、文書登録時にインデックス名に対応するインデックス値を設定するものが多い。また、インデックス値に関しては、管理者があらかじめ入力したものから一般ユーザが選択して設定するか、もしくは、一般ユーザが任意に入力した入力値を設定するというシステムが多い。ここで、インデックス情報には、カテゴリ（インデックスの項目／項目名を指す）とインデックス値（インデックスの項目に対して設定する値を指す）とが含まれる、と定義する。

ユーザは、このように文書データに設定したインデックス情報を利用して文書データの検索を行い、所望の文書データを特定することが可能となる。

しかし、上述したような一般ユーザの使い方では、必ずしもユーザが設定するインデックス情報が統一のとれた文字列とは限らない。例えば、類似の文字列で、意味は同じであるが同じ文字列ではない場合（“文書保存”と“文書登録”のような表現の違いなど）は、インデックス情報による検索を行ってもヒットしない文書が存在する場合がある。

また、一般ユーザがインデックス情報による検索を行う際、ユーザには直接関係ない文書（他部門の作成した文書で参照不可に設定された文書など）もヒットするというシステムも存在する。この場合は、ユーザが実際にヒットした文書の中から当文書を開こうとした際に、アクセス権がないことが判明する場合がある。

そこで、上記問題を解決するための従来例として、スキャンデータにＯＣＲ処理を施して、その結果からインデックス情報を取得する際に、適切なインデックス情報を採用するために、次のようなシステムが提案されている。まず、ＯＣＲ処理の結果として得た言葉が、一般的に使用されている言葉であるか否かを“言語データベース”を使用して判断する。次に、過去に採用された言葉であるかを“知識データベース”を使用して判断する。その結果、適切なインデックス情報であると決定した場合に、インデックス情報として採用する（特許文献１を参照）。

また、上記問題を解決するための別の従来例として、ユーザ認証を行い、さらにユーザに検索キーワードとしてインデックス情報を入力させて、その入力されたインデックス情報による検索を行う。その際、ユーザのアクセス権のある文書のみを検索対象にするなどの処理で、ユーザのアクセス権を考慮した検索を提供するシステムが提案されている（特許文献２を参照）。
特開２００６−１７２０８３公報 特開２００１−３４４２４５公報

文書管理システムに文書登録する際のインデックス情報を設定する目的の１つとして、「保存した文書や情報の再利用」が挙げられる。ここで、システム上に登録された文書データなので再利用する対象者は文書の登録者のみでなく、システム利用者の全てである。しかし、システムに登録された文書データは、システム利用者の全てにとって同じ重要性を持つとは限らない。例えば、特に同じ業務に携わり、同じ組織に所属するような登録者が登録した文書データは、登録者とよく似たユーザ特性をもつ他のユーザにとって、業務上とても関連のある文書データであり、再利用が促進されることが望まれる。

しかし、文書に設定するインデックス情報に関して、文書データを登録するユーザによってまちまちな用語が用いられた場合は、検索時にヒットしない文書データがあり、この目的を達成しづらくなってしまう。

さらに、複合機等で紙データをスキャンし、インデックス情報を付与して文書管理システムに保存する場合には、複合機上の小さなユーザインタフェース（ＵＩ）画面でのインデックス情報の設定は非常に手間が掛る。そのため、入力に時間がかかってしまったり、入力ミスの可能性があったりする。

前記特許文献１においては、文書情報から、システムを利用する全てのユーザが過去に使用した履歴がある用語を用いて、インデックス情報の設定を行うことが出来る。しかし、部門やプロジェクトなどの自分に近いユーザに限定した履歴を使用する方法については言及されていないため、担当分野が異なるユーザが過去に使用した用語でもインデックス情報に設定されてしまうことになる。

また、前記特許文献２においては、ユーザのアクセス権に従った検索となるため、登録時に１つ１つの文書にアクセス権を設定しておかなければならない。また、ユーザが複数プロジェクトに関わっていてアクセス権の範囲が広い場合に、特定のプロジェクトや部署などに関連する文書のみを検索したいという場合には、複数ヒットした文書からユーザが欲しい文書を更に探さなければならない。

本発明は、上記課題を解決するために、ユーザの特性を用いて自動的にインデックス候補情報を収集することができる文書管理装置、文書管理方法およびプログラムを提供する。

上記課題を解決するために、本発明の文書管理装置は、文書の登録を指定したユーザを特定するユーザ特性情報を取得するユーザ特性情報取得手段と、前記文書の文書情報を取得する文書情報取得手段と、前記ユーザ特性情報取得手段によって得られたユーザ特性情報と、前記文書情報取得手段によって得られた文書情報と、前記ユーザ特性情報取得手段によって得られたユーザ特性情報と所定の項目が一致するユーザ特性情報を持つ他のユーザの履歴情報とに基づき、前記文書に付与するためのインデックス候補情報を生成するインデックス候補情報生成手段と、前記インデックス候補情報生成手段が生成したインデックス候補情報を出力するインデックス候補情報出力手段と、前記インデックス候補情報出力手段が出力したインデックス候補情報から該ユーザにより選択されたインデックス情報を受信するインデックス情報受信手段と、前記インデックス情報受信手段により受信した前記インデックス情報を前記文書情報取得手段により取得した文書情報に対応する文書に関連づけて登録する文書登録手段とを有することを特徴とする。

本発明により、ユーザの特性を設定しておくことで、ユーザがインデックス情報の統一性を意識する必要が無くとも、自動的にそのユーザに関連するインデックス候補情報を検索して収集することができる。

また、これによって、一般ユーザが検索を行う際に、指定する検索キーワードとして文字列の表現を複数設定する必要がなくなる。

さらに、インデックス候補情報を選択可能にユーザインタフェースとして表示することで、複合機等の小さな画面上でもインデックス情報を１つ１つ入力する必要がなくなる。

以下、本発明の実施形態について、添付図面を用いて説明する。

＜本実施形態の文書管理システムの構成例＞
図１は、本実施形態に係る文書管理システムのシステム構成図である。本発明においては、例えばユーザＡ及びユーザＢに対して文書管理システムの機能を提供するための文書管理アプリケーションを、ウェブサービス（Ｗｅｂアプリケーション）として提供する。

図１では、本実施形態に係る文書管理システムには、以下の機器がネットワークを介して接続されている。ユーザＡがウェブブラウザを介して文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセスするためのＣｌｉｅｎｔＰＣ１０が接続されている。また、本実施形態に係る文書管理システムのＷｅｂアプリケーションを提供するＷｅｂアプリケーションサーバＰＣ２０が接続されている。また、本システムにアクセスするユーザの情報を管理するユーザ管理サービスサーバＰＣ３０が接続されている。また、文書を保存／管理する機能を有する文書管理サービスサーバＰＣ４０が接続されている。また、ユーザＢがＵＩ（本実施形態では、内部的にはブラウザを使用してＵＩを表示していることとする）を介してアクセスするスキャナ機能やプリンタ機能，ファクシミリ機能などを有する画像形成装置である複合機５０が接続されている。

ここで、ＷｅｂアプリケーションサーバＰＣ２０、ユーザ管理サービスサーバＰＣ３０、及び文書管理サービスサーバＰＣ４０は、別々に配置されている構成例を示しているが、これらに機能が１つのＰＣにおいて構成されても構わない。また、ユーザＡがＣｌｉｅｎｔＰＣ１０を操作する構成としているが、前記３つのサーバＰＣのいずれか、もしくは全てと同じＰＣで操作しても構わない。更に、ユーザＢが複合機５０を操作する構成としているが、スキャナがＣｌｉｅｎｔＰＣ１０に接続されている構成であっても構わない。

なお、本実施形態に係る文書管理システムは、ユーザＡがブラウザを介してアクセスする構成、および、ユーザＢが複合機のＵＩを介してアクセスする構成としている。しかし、図示しない専用のクライアントアプリケーションをＣｌｉｅｎｔＰＣ１０および複合機５０に配置し、ユーザＡおよびユーザＢがそれを操作する構成であっても構わない。この場合、ＷｅｂアプリケーションサーバＰＣ２０ではなく、文書管理サービスサーバＰＣ４０と専用クライアントアプリケーションが通信する構成でも構わない。

＜本実施形態のＰＣのハードウェア構成例＞
図２は、本実施形態に係る文書管理システムを構成する各ＰＣのハードウェア構成例を示している。図２に示されるハードウェア構成例は、一般的な情報処理装置のハードウェア構成に相当するものとし、本実施形態の各ＰＣには一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ１００は、ＲＯＭ１０２のプログラム用ＲＯＭに記憶された、或いはハードディスク１０９からＲＡＭ１０１にロードされたＯＳやアプリケーション等のプログラムを実行する。ここで、ＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのＯＳの管理の下でのプログラムの実行により実現できる。ＲＡＭ１０１は、ＣＰＵ１００の主メモリ、ワークエリア等として機能する。キーボードコントローラ１０３は、キーボード１０７や図示しないポインティングデバイスからのキー入力を制御する。ディスプレイコントローラ１０４は、各種ディスプレイ１０８の表示を制御する。ディスクコントローラ１０５は、各種データを記憶するハードディスク（ＨＤ）１０９やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ１０６はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

＜本実施形態の文書管理システムのソフトウェア構成例＞
図３は、本実施形態に係る文書管理システムの一例を示すソフトウェア構成例を示す図である。図３は、ＷｅｂアプリケーションサーバＰＣ２０、ユーザ管理サービスサーバＰＣ３０、及び文書管理サービスサーバＰＣ４０内のソフトウェア構成を示している。

図３で、ＷｅｂアプリケーションサーバＰＣ２０にあるメイン制御部２００は、本実施形態に係る文書管理システムの全体を制御し、後述する各部に対する指示及び管理を行う。データ送受信部２０１は、ＣｌｉｅｎｔＰＣ１０および複合機５０においてユーザがブラウザを介して出した命令を受け取り、メイン制御部２００より指示を受けた結果を、ＣｌｉｅｎｔＰＣ１０および複合機５０に返答する。セッション記憶部２０２は、ＣｌｉｅｎｔＰＣ１０および複合機５０においてユーザがブラウザを介して本文書管理システムにアクセスすると、同一ユーザからのアクセスであることを示すためのセッション情報を生成する。更に、ユーザが本文書管理システムへのアクセスをやめる（ログアウト）、もしくは自動タイムアウトなどでセッションが切れるまでの間、繰り返し使用する各種情報をセッション情報と関連付けて保持する。ＷｅｂＵＩ生成部２０３は、メイン制御部２００より指示を受け、状況に応じたＷｅｂＵＩ（ＨＴＭＬ）を生成する。ここで、ＷｅｂＵＩ生成部が生成するＷｅｂＵＩは、ＨＴＭＬだけに限定するものではなく、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔなどのスクリプト言語が埋まっていても構わない。

次に、ユーザ管理サービスサーバＰＣ３０にあるユーザ情報操作部３００は、メイン制御部２００からの指示に従い、ユーザ情報記憶部３０１に保存されている本文書管理システムにアクセス可能なユーザ及びユーザ特性の抽出、編集などの操作を行う。ここで、ユーザ管理に関して、本文書管理システム独自の管理ではなく、既知の技術であるＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙ、ＬＤＡＰなどとユーザ情報操作部３００が連携し、ユーザ情報記憶部３０１においてはユーザ特性のみを保存しても構わない。

次に、文書管理サービスサーバＰＣ４０にある文書情報操作部４００は、メイン制御部２００からの指示に従い、文書情報記憶部４０１に保存されている文書の実体及びインデックス情報を含む文書属性の登録、保存、抽出、編集などの操作を行う。文書検索部４０２は、メイン制御部２００からの指示に従い、文書を検索するための方法を決定し、文書情報操作部４００を介して文書情報記憶部４０１より検索結果を取得する。比較部４０３は、メイン制御部２００からの指示に従い、文書属性とユーザ特性との比較を行い、更に、必要に応じて文書情報操作部４００を介して文書情報記憶部４０１に保存されている文書の属性の重み付けを変更する。文書分類部４０４は、メイン制御部２００からの指示に従い、文書属性のカウント（重み付け）値から分類分けを実行し、その結果をメイン制御部２００に返す。文書情報取得部４０５は、メイン制御部２００からの指示に従い、データ送受信部２０１が受信した文書データに対して、ＯＣＲ処理等の画像処理を行い、文書情報を取得する。インデックス候補情報生成部４０６は、メイン制御部２００からの指示に従い、ユーザ情報操作部３００および文書情報取得部４０５から得られる情報を使用して、インデックス候補情報を生成する。メール生成部４０７は、メイン制御部２００からの指示に従い、ユーザ情報操作部３００および文書情報取得部４０５から得られる情報を使用して、文書登録結果等を通知するためのメールヘッダや本文を生成する。生成したメールは、メイン制御部２００がデータ送受信部２０１を介して送信を行う、または、メール生成部４０７にて送信を行う。

＜本文書管理システムの実施形態１の処理例＞
以下、本発明の実施形態１に係る文書管理システムの各ステップにおける処理について、図１乃至図１９を用いて具体的に説明する。

（ログイン及びユーザ特性登録処理）
ユーザＡが、ＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセス（ログイン）し、初めてログインした際にはユーザ特性を入力し、本文書管理システムにて保存する処理である。

図４は、本文書管理システムにおけるログイン及びユーザ特性登録処理のシステム動作の概要である。図５は、ログイン及びユーザ特性登録処理時の本文書管理システムにおける処理の流れの例を示すフローチャートである。かかるフローチャートは、ＷｅｂアプリケーションサーバＰＣ２０にあるメイン制御部２００による処理である。以下、図４及び図５を用いて、ログイン及びユーザ特性登録処理を詳細に説明する。

ステップＳ１００において、ユーザＡがＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションのトップページにアクセスする。すると、メイン制御部２００は、データ送受信部２０１にて受信したリクエストを受けて、ＷｅｂＵＩ生成部２０３に依頼し、トップページの生成を行う。続いて、データ送受信部２０１を介して、本文書管理システムのトップページをレスポンスとしてＣｌｉｅｎｔＰＣ１０に返し、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上でトップページを表示する。

次に、ステップＳ１０１において、ステップＳ１００により表示されたトップページにてユーザＡがログイン情報を入力すると、メイン制御部２００は、データ送受信部２０１にて受信したユーザＡのログイン情報を受ける。メイン制御部２００は、ユーザ情報操作部３００に問い合わせ、ログインしたユーザＡがユーザ情報記憶部３０１に登録されたユーザか否かを確認する。その結果、ユーザ情報記憶部３０１にユーザＡが存在しない、もしくはパスワードが間違っている場合、メイン制御部２００は、ステップＳ１０２において、ＷｅｂＵＩ生成部２０３に依頼しログイン失敗エラーページの生成を行う。続いて、データ送受信部２０１を介してＣｌｉｅｎｔＰＣ１０にレスポンスとして返し、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上でログイン失敗エラーページを表示する。

ステップＳ１０１の判定によりユーザ情報記憶部３０１にユーザＡが登録済みの場合、メイン制御部２００は、次にステップＳ１０３において、セッション記憶部２０２においてセッション情報を生成する。続いて、ユーザ情報記憶部３００に問い合わせ、ユーザ情報記憶部３０１にユーザＡのユーザ特性が登録されているか否かを確認する。なお、セッション情報を生成するタイミングは、ここに限定しない。

ステップＳ１０３においてユーザＡのユーザ特性が登録されていない場合、メイン制御部２００は、ステップＳ１０４において、ＷｅｂＵＩ生成部２０３に依頼してユーザ特性入力ページの生成を行う。続いて、データ送受信部２０１を介して、ユーザ特性入力ページをＣｌｉｅｎｔＰＣ１０にレスポンスとして返し、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上で表示する。次に、ステップＳ１０５において、ステップＳ１０４により表示されたユーザ特性入力ページにてユーザＡがユーザ特性を入力する。メイン制御部２００は、データ送受信部２０１を介してユーザＡのユーザ特性を受信し、ユーザ特性情報取得を行なう（図４のプロセスＰ１１参照）。

続いて、ユーザ情報操作部３００に指示し、ユーザ情報記憶部３０１にユーザＡのユーザ特性として登録する（図４のプロセスＰ１２参照）。この際、メイン制御部２００は、セッション記憶部２０２に対しても、生成済みのセッション情報とともにユーザ特性を保持することを指示する。これにより、毎回ユーザＡのユーザ特性情報をユーザ情報記憶部３０１より取得することがなくなるため、処理速度を向上させることができる。

図６は、ユーザ特性、及びユーザ情報記憶部３０１に保存されているユーザ特性テーブル６０の一例を示す図である。

各ユーザ名６１に対応するユーザ特性としては、所属部署６２、役職６３、課内担当６４、プロジェクト６５、プロジェクト内での業務６６、メールアドレス６７、類似ユーザ６８、ランキング設定６９、インデックス設定履歴７０などがある。かかるユーザ特性は、後述する文書自動収集処理において利用される。ここで、類似ユーザ６８は、類似ユーザの情報を収集する際、どの所定キーをきっかけに類似ユーザを特定するかを指定する。また、ランキング設定６９は、文書情報の例として、ＯＣＲ抽出による文字列での頻出回数を数えた際に、ランキング何位までの情報を保存するかを指定する。また、インデックス設定履歴７０は、得られた文書情報に対応して、その文書に設定されたインデックス情報の履歴情報である。

なお、ユーザ特性としては、これら以外の情報が含まれていても構わない。更に、ユーザ特性の項目として複数の値が含まれていても構わない。例えば、複数のプロジェクトに関わるユーザの場合には、複数選択できるほうが良い。また、前記ユーザ特性入力ページでは、ユーザ特性の項目を自由にユーザが入力できるのではなく、選択できる形状であることが望ましい。このためには、本文書管理システムを導入するユーザ環境に応じて、導入先の管理者などが事前に適切な選択項目を設定しておくことが望ましい。

ステップＳ１０３でユーザ特性が登録済みかあるいはステップＳ１０５でユーザ特性が登録されると、次にステップＳ１０６において、後述するユーザＡのユーザ特性に応じた文書自動収集処理が実行される。次に、メイン制御部２００は、ステップＳ１０７において、ステップＳ１０６によりユーザＡのユーザ特性に応じて収集、分類分けされた表示内容とあわせ、ＷｅｂＵＩ生成部２０３にユーザＡのページを生成させる。続いて、データ送受信部２０１を介してＣｌｉｅｎｔＰＣ１０にレスポンスとして返し、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上でユーザＡのページを表示する。

なお、文書自動収集処理の説明において詳細に示すが、図１３はステップＳ１０７でＣｌｉｅｎｔＰＣ１０に表示されるユーザＡのページの一例を示すものであり、ユーザ特性に応じて収集、分類分けされた表示内容が含まれている。

（文書登録処理）
あるユーザが、ＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセス（ログイン）し、文書を指定して、本文書管理システムに登録する処理である。もしくは、複合機５０のＵＩを介して本文書管理システムのＷｅｂアプリケーションにアクセスし、文書を指定して本文書管理システムに登録する処理である。

図７は、本文書管理システムにおける文書登録処理のシステム動作の概要である。図８は、文書処理時の本文書管理システムにおける処理の流れを示すフローチャートである。また、図１４は、文管理システムに対して、文書データを登録する際の処理の概要を説明したものである。

以下、図７、図８、及び図１４を用いて詳細に説明する。ただし、ここでの説明はＣｌｉｅｎｔＰＣ１０からの文書登録（図７のプロセスＰ２０）についてのみ述べるが、ＣｌｉｅｎｔＰＣ１０からの登録対象文書を複合機５０でスキャンによって得られた画像データの文書に置き換えることが可能である。

ステップＳ２００−Ｓ２０３は、ＷｅｂアプリケーションサーバＰＣ２０にあるメイン制御部２００の処理である。

ステップＳ２００において、ユーザ（ユーザ名を例えば「原口和夫」として以下説明する）がＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにログインする（図１４のプロセスＰ２１）。ログイン処理は、図５を用いて、ログイン及びユーザ特性登録処理時の本文書管理システムにおける処理の流れを示した通りである。

ステップＳ２００により表示されたユーザ「原口和夫」のページにて文書登録を実行すると、メイン制御部２００は、次にステップＳ２０１において、データ送受信部２０１を介して文書（文書名を「Ｄｏｃ１」とする）を受信する（図１４のプロセスＰ２４）。続いて、一旦セッション記憶部２０２においてセッション情報と関連付けて保存する。かかる処理は、クライアントの文書送信処理とサーバの文書受信処理を含む。

メイン制御部２００は、ステップＳ２０２において、ステップＳ２００によりセッション記憶部２０２に保持されているユーザ「原口和夫」のユーザ特性を取得する。なお、図１４のプロセスＰ２２，Ｐ２３に示すように、メイン制御部２００は、ユーザ情報操作部３００に指示し、ユーザ情報記憶部３０１よりユーザ「原口和夫」のユーザ特性と所定キーの一致する類似ユーザのユーザ特性を取得しても良い。

次に、メイン制御部２００は、ステップＳ２０３において、ステップＳ２０１およびＳ２０２で取得した登録文書とユーザ特性をデータ送受信部２０１を介して文書管理サービスサーバ４０へ送信する（図１４のプロセスＰ２５）。ここでは、登録文書とユーザ特性を送信することを想定して説明しているが、図１４に図示しないが、ユーザ管理サービスサーバＰＣ３０から文書管理サービスサーバＰＣ４０へ直接送信する、という実施系でも構わない。

次のステップＳ２０４−Ｓ２０７は、文書管理サービスサーバＰＣ４０にある各部の処理である。

ステップＳ２０４において、文書管理サービスサーバＰＣ４０は、ＷｅｂアプリケーションサーバＰＣ２０から、上記ステップＳ２０１およびＳ２０２で取得した登録文書とユーザ特性を受信する。次に、ステップＳ２０５において、文書情報取得部４０５は、ステップＳ２０１で取得した登録文書からＯＣＲ処理、または、全文検索等により文字列を抽出するなどの画像処理を施し、文書情報を取得する。なお、前述した画像処理に加えて、文書に既に設定されている属性等を取得しても構わない。

次に、ステップＳ２０６において、ステップＳ２０２で取得したユーザ特性とステップＳ２０５で取得した文書情報をもとに、インデックス候補情報を生成する。インデックス候補情報の生成ステップの詳細は、図１６に従い後述する。次に、文書管理サービスサーバＰＣ４０は、ステップＳ２０７において、図１４のプロセスＰ２６に示すように、インデックス候補情報をデータ送受信部２０１を介してメイン制御部２００に送信する。

次のステップＳ２０８−Ｓ２１１は、ＷｅｂアプリケーションサーバＰＣ２０にあるメイン制御部２００の処理である。

ステップＳ２０８において、メイン制御部２００は、文書管理サービスサーバＰＣ４０からインデックス候補情報を受信する。次に、メイン制御部２００は、ステップＳ２０９において、受信したインデックス候補情報を使ってＷｅｂＵＩ生成部２０３にインデックス情報設定ページを生成させる。続いて、データ送受信部２０１を介してＣｌｉｅｎｔＰＣ１０にそのインデックス候補情報に基づくインデックス情報設定ページに関する情報を出力する。ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上でインデックス情報設定ページを表示される（図１４のプロセスＰ２７）。かかる処理は、サーバにおけるインデックス候補情報出力処理またはインデックス候補情報送信処理または表示指示処理、クライアントにおけるインデックス候補情報受信処理及びインデックス候補情報表示処理を含む。

次に、ステップＳ２１０において、メイン制御部２００は、ＣｌｉｅｎｔＰＣ１０のインデックス情報設定ページでユーザにより指定されたインデックス情報を、データ送受信部２０１を介して受信する（図１４のプロセスＰ２８）。かかる処理は、クライアントにおけるインデックス情報送信処理、サーバにおけるインデックス情報受信処理を含む。

次に、ステップＳ２１１において、図１４のプロセスＰ２９に示すように、メイン制御部２００は、ステップＳ２１０で取得したインデックス情報をデータ送受信部２０１を介して文書管理サービスサーバＰＣ４０へ送信する。

次のステップＳ２１２−Ｓ２１４は、文書管理サービスサーバＰＣ４０にある各部の処理である。

ステップＳ２１２において、文書管理サービスサーバＰＣ４０は、ステップＳ２１１でデータ送受信部２０１を介して送信されたインデックス情報を受信する。次に、ステップＳ２１３において、文書情報操作部４００に指示して、前記ステップＳ２０１によりセッション記憶部２０２に保存した文書Ｄｏｃ１を文書情報記憶部４０１に保存する。これは、ステップＳ２０２によりセッション記憶部２０２により取得したユーザ「原口和夫」のユーザ特性、および、ステップＳ２１０により取得したインデックス情報を、文書Ｄｏｃ１の属性として保存するものである。例えば、図７に示すように、文書登録した文書Ｄｏｃ１には、インデックス情報と共にユーザ「原口和夫」のユーザ特性が関連付けられている。

ここで、文書を登録するユーザは、後述する文書自動収集処理により自動的に分類分けがなされるため、本文書管理システムの保存場所を指定する必要はなくなるため、保存場所を決定する作業から解放される。

次に、ステップＳ２１４において、文書管理サービスサーバ４０は、図１４のプロセスＰ３０に示すように、ステップＳ２１３において保存した文書情報とインデックス情報とをメイン制御部２００へ送信する。

次のステップＳ２１５−Ｓ２１６は、ＷｅｂアプリケーションサーバＰＣ２０にあるメイン制御部２００の処理である。

ステップＳ２１５において、メイン制御部２００は、ステップＳ２１４で文書管理サービスサーバＰＣ４０が送信した文書情報とインデックス情報とを受信する。次に、ステップＳ２１６において、受信した文書情報とインデックス情報とを、ステップＳ１０５によりユーザ情報記憶部３０１に保存した「原口和夫」のユーザ特性の一部とする。そして、図１４のプロセスＰ３１に示すように、ユーザ情報操作部３００を介してユーザ情報記憶部３０１に保存する。

なお、ここでは文書登録ごとにユーザ情報記憶部３０１に保存する処理を述べている。しかし、メイン制御部２００は、セッション記憶部２０２に保持されている「原口和夫」のユーザ特性を更新し、複数の文書登録が終了した時点でユーザ情報記憶部３０１にまとめて保存しても構わない。また、ステップＳ２１６において保存する文書情報は、文書中の全てのＯＣＲ抽出文字列、全文検索による抽出文字列などの文書情報全体を保存しても構わない。しかし、必要以上の記憶領域の容量を必要としないため、図６に示すユーザ特性のランキング設定に応じて、文書中のＯＣＲ抽出文字列の頻出回数の上位だけを保存することが望ましい。

（文書属性重み付け処理）
あるユーザが、ＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセス（ログイン）し、文書にアクセスする。ここで、アクセスとは閲覧、印刷、もしくはコピーなどの操作を含むが、本実施形態においては、閲覧を例にして説明する。

図９は、本文書管理システムにおける文書属性重み付け処理のシステム動作の概要である。図１０は、文書属性重み付け処理時の本文書管理システムにおける処理の流れの例を示すフローチャートである。以下、図９及び図１０を用いて詳細に説明する。なお、文書属性重み付け処理は、ＷｅｂアプリケーションサーバＰＣ２０のメイン制御部２００が、文書管理サービスサーバＰＣ４０の各部に処理を指示しながら実行される。しかしながら、図１０には、煩雑さを避けるために上記図８のように指示のやり取りは省略をし、メイン制御部２００の処理のみを図示している。

ステップＳ３００において、ユーザ（このユーザ名を「高沢亜美」とする）がＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにログインする。ログイン処理は、図５を用いて、ログイン及びユーザ特性登録処理時の本文書管理システムにおける処理の流れを示した通りである。

次に、ステップＳ３０１において、ステップＳ３００により表示されたユーザ「高沢亜美」のページにて、所望の文書を選択して閲覧を実行する。すると、メイン制御部２００は、データ送受信部２０１にて受信した文書（文書名を、ユーザ「原口和夫」が上記登録処理で登録した「Ｄｏｃ１」とする）を一旦セッション記憶部２０２においてセッション情報と関連付けて保存する。この際、データ送受信部２０１にて受信したユーザ「高沢亜美」が閲覧するために指定した文書を特定する情報は、文書名を特定するものではなく、文書を特定するＩＤであっても構わない。

次に、メイン制御部２００は、ステップＳ３０２において、ステップＳ３００によりセッション記憶部２０２に保持されているユーザ「高沢亜美」のユーザ特性を取得する。なお、メイン制御部２００は、ユーザ情報操作部３００に指示し、ユーザ情報記憶部３０１よりユーザ「高沢亜美」のユーザ特性を取得しても良い。

次に、ステップＳ３０３において、メイン制御部２００は、ステップＳ３０１によりセッション記憶部２０２に保存した文書Ｄｏｃ１の文書属性を保存する。このとき、メイン制御部２００が、文書情報操作部４００に指示して、文書情報記憶部４０１より文書Ｄｏｃ１の文書属性を取得し、セッション記憶部２０２にセッション情報と関連付けて保存する。

次に、メイン制御部２００は、比較部４０３に指示して、ステップＳ３０４において、文書属性とユーザ「高沢亜美」のユーザ特性との各項目を抽出する。ここで、文書属性は、ステップＳ３０３により取得しセッション記憶部２０２に保存した文書Ｄｏｃ１の文書属性であり、ユーザ特性は、ステップＳ３０２により取得したユーザ「高沢亜美」のユーザ特性である。具体的には、文書Ｄｏｃ１の文書属性の１番目の項目“所属部署”の値は“設計１”であり、ユーザ「高沢亜美」のユーザ特性の１番目の項目“所属部署”の値も“設計１”である。次に、ステップＳ３０５において、ステップＳ３０４により抽出した文書属性とユーザ特性の項目に対して、比較部４０３は、両項目の値が等しいか否かを比較する。

ステップＳ３０６において、ステップＳ３０５により比較部４０３が文書属性とユーザ特性の両項目の値が等しいと判断した場合、ステップＳ３０７の処理を実行する。ステップＳ３０７において、比較部４０３は、文書情報操作部４００に依頼し、文書情報記憶部４０１に保存されている文書Ｄｏｃ１の文書属性の重み付けを更新する。具体的には、図９のように、文書Ｄｏ１の文書属性の項目“所属部署”の重み付けをカウントアップする。なお、本実施形態においては、比較部４０３において比較した結果を、項目毎に文書情報記憶部４０１に保存されている文書属性の重み付けを更新するようにしたが、全項目を比較した結果をまとめて反映するようにしても良い。

次に、ステップＳ３０６により比較部４０３が文書属性とユーザ特性の両項目の値が異なると判断した場合、ステップＳ３０８において、文書属性の次の項目が存在するか確認する。具体的には、文書Ｄｏｃ１の文書属性の２番目の項目として“役職”が存在するため、ステップＳ３０４以降の処理が続行される。

ステップＳ３０４からＳ３０８までの処理を繰り返し、文書Ｄｏｃ１の文書属性の項目を最後まで抽出し、ユーザ特性の全項目と比較をし終えると、文書属性重み付け処理は終了する。

図９において、文書Ｄｏｃ１を登録した直後の文書属性の重み付け９１と、ユーザ「高沢亜美」、「横尾俊樹」及び「幸田新」が文書Ｄｏｃ１を閲覧した後の、文書Ｄｏｃ１の文書属性の重み付け９２の変化結果とを示している。この結果、文書属性の項目“所属部署”の重み値より、“プロジェクト”の重み値の方が上回ることになる。つまり、文書Ｄｏｃ１は、所属部署である“設計１”よりも、プロジェクトである“文書管理”に関連性が高くなる。従って、後述する文書自動収集処理の分類分け時に、“プロジェクト”もしくはプロジェクトである“文書管理”との関連性が高いと自動的に判断できるようになる。

このように、文書管理システムを利用するユーザの文書閲覧などの文書に対するアクセスによって、文書に付与されている各属性のうち、より文書自体と関連度の高いと思われる属性に重み付けする。これにより、ユーザとの関連性のある文書の自動収集（検索）が可能となる。

（文書自動収集処理）
ユーザＡが、ＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセス（ログイン）する（図１１のプロセスＰ３１）。すると、自動的に文書収集処理が走り、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上に取得した文書リストを表示する。図１１は、本文書管理システムにおける文書自動収集処理のシステム概要であり、図１２は、文書自動収集処理時の本文書管理システムにおける処理の流れを示すフローチャートである。以下、図１１及び図１２を用いて詳細に説明する。なお、図１２の文書自動収集処理のフローチャートは、ユーザＡが本文書管理システムにログインした後からのステップを示す。なお、文書自動収集処理は、ＷｅｂアプリケーションサーバＰＣ２０のメイン制御部２００が、文書管理サービスサーバＰＣ４０の各部に処理を指示しながら実行される。しかしながら、図１２には、煩雑さを避けるために上記図８のように指示のやり取りは省略をし、メイン制御部２００の処理のみを図示している。

ステップＳ４００において、セッション記憶部２０２に保持されているユーザＡのユーザ特性を、メイン制御部２００は取得する。なお、図１１のプロセスＰ３２に示すように、メイン制御部２００は、ユーザ情報操作部３００に指示し、ユーザ情報記憶部３０１よりユーザＡのユーザ特性を取得しても良い。

次に、ステップＳ４０１において、ステップＳ４００により取得したユーザ特性により、メイン制御部２００は文書検索部４０２に文書検索を指示する（図１１のプロセスＰ３３）。続いて、文書検索部４０２は、ユーザ特性の各項目の値をキーワードとして“ＯＲ（論理和）”の条件で、文書情報操作部４００に指示して、文書情報記憶部４０１より条件に一致する文書を検索する。具体的には、ユーザＡ（「原口和夫」）の場合、ユーザ特性である“設計１”、“文書管理”、“インストーラ”などをキーワードにして検索を行う。かかる文書抽出処理では、更に類似のユーザに関連する文書を検索結果として抽出してもよい。

次に、ステップＳ４０２において、ステップＳ４０１により文書検索部４０２が条件に一致する文書を発見できなかった場合、ステップＳ４０３を実行する。ステップＳ４０３において、メイン制御部２００は、ＷｅｂＵＩ生成部２０３に依頼し、ユーザ特性に一致する文書が見つからなかったことを通知するエラーページを生成する。続いて、データ送受信部２０１を介して、ＣｌｉｅｎｔＰＣ１０にレスポンスとして返し、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上でエラーページを表示する。

ステップＳ４０２により文書検索部４０２が条件に一致する文書を発見できた場合、ステップＳ４０４において、メイン制御部２００は検索結果の文書リストを取得する。続いて、文書情報操作部４００を介して、文書情報記憶部４０１より検索結果の文書リストのうち、ユーザＡがアクセス可能な文書のみを抽出する。

次に、ステップＳ４０５において、ステップＳ４０４によりユーザＡがアクセス可能な文書を抽出できなかった場合、ステップＳ４０３を実行する。ステップＳ４０３において、メイン制御部２００は、ＷｅｂＵＩ生成部２０３に依頼し、ユーザがアクセス可能な文書リストが見つからなかったことを通知するエラーページを生成する。続いて、データ送受信部２０１を介して、ＣｌｉｅｎｔＰＣ１０にレスポンスとして返し、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上でエラーページを表示する。

ステップＳ４０５によりユーザ特性に従った検索により発見され、かつユーザＡがアクセスできる文書リストを抽出できた場合、ステップＳ４０６に進む。ステップＳ４０６において、メイン制御部２００は、文書分類部４０４に指示し、文書リストにおける全文書に対して、各文書の文書属性のうち最大カウント（重み付け）数となる項目を確認する。

次に、ステップＳ４０７において、文書分類部４０４にて、確認された文書リストの各文書に対して、文書属性の最大カウント（重み付け）数となった項目毎に分類分けを行う。具体的には、ある文書の文書属性のうち、“所属部署”が最大カウント（重み付け）数となった場合、その文書は所属部署である“設計１”の分類となる。

次に、ステップＳ４０８において、ステップＳ４０７で文書分類部４０４により分類分けされた文書リスト（図１１の１１０１参照）をメイン制御部２００が受ける（図１１のプロセスＰ３４）。次に、ＷｅｂＵＩ生成部２０３に依頼し、ユーザ特性に応じて自動的に収集されて分類分けされた文書リストを表示するページを生成する（図１１の１１０２参照）。続いて、データ送受信部２０１を介して、ＣｌｉｅｎｔＰＣ１０にレスポンスとして返し、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上で各ユーザのログイン後のページとして表示する（図１１のプロセスＰ３５）。

（文書収集結果の表示画面例）
図１３は、本文書管理システムにおけるＣｌｉｅｎｔＰＣ１０のログイン後の文書収集結果を表示するユーザインタフェースの一例（ＵＩ）の一例である。

文書の表示領域１２０２において、ユーザＡの特性に応じて、分類分けされ文書収集結果が表示されている。具体的には、所属部署である“設計１”、担当プロジェクトである“文書管理”、担当プロジェクト内での業務である“インストーラ”のエリアに自動収集し、分類分けされた文書リストが表示される。

図１３においては、新着文書の表示やＵＩのカスタマイズを行う、またはユーザに関連性の高いフォルダリンクの選択などを行うユーザ領域１２０１や、文書の操作やコントロールなどを行うための表示１２０３が表示されている。

なお、図１３でユーザインタフェースの一例として示したＷｅｂＵＩ（ＨＴＭＬ）に関して、その形態、構成、およびコントロールは限定されたものではない。更に、必要となる機能を実現するためＨＴＭＬが生成されればどのような形態であっても構わない。

（インデックス候補情報生成処理）
図８に示すように、ユーザＡが、ＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセス（ログイン）し、文書登録を実行する。すると、自動的にインデックス候補情報生成処理（図８のステップＳ２０６参照）が走る。これにより、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上で登録対象文書に設定するためのインデックス候補情報を表示することが可能となる（図１４のプロセスＰ２７参照）。

図１５は、本文書管理システムにおけるインデックス候補情報生成の際に使用するデータの一例である。また、図１６、図１７および図１８は、本文書管理システムにおける文書登録時のインデックス候補情報生成処理の流れを示すフローチャートである。本実施形態においては、文書管理サービスサーバＰＣ４０において処理が行われている。

以下、図１６を用いて図８のステップＳ２０６の処理を詳細に説明する。なお、図１６は、図８の処理において、ユーザ特性情報および文書情報は取得していることを前提としている。かかるインデックス候補情報生成処理は、主に文書管理サービスサーバＰＣ４０のインデックス候補情報生成部４０６で実行される。

ステップＳ５００において、ステップＳ２０２およびＳ２０３において取得したユーザ特性情報と文書情報とを比較し、一致するものがあるか否かを判断する。ここでは、ユーザ「原口和夫」が文書登録を実行したとして、ステップＳ５００での比較処理について具体例を用いて説明する。ステップＳ５００の比較処理は、ユーザ「原口和夫」のユーザ特性情報と登録対象文書から得られた文書情報とを単純比較する。「設計１」、「文書管理」というキーワードがそれに当する。例えば、図１５の（ａ）の例は、ステップＳ２０５で取得した、登録文書から取得した文書情報１５０１である。図６に示すユーザ「原口和夫」のユーザ特性の中で、文書情報と一致するものは、「設計１」、「文書管理」である。

ステップＳ５００において一致する情報があると判断した場合、ステップＳ５０１において、その情報をインデックス候補情報に追加する処理を実行する。インデックス候補情報に追加する処理は、図１７において後述する。

次に、ステップＳ５０２において、インデックス候補情報生成部４０６は、ユーザ情報操作部３００に指示して、ステップＳ２０２で取得したユーザ特性と所定キーが一致する類似のユーザ特性を持つユーザ情報を取得する（図１４のプロセスＰ２３）。ここでは、類似のユーザと判断する基準は、図６のユーザ特性テーブルの“類似ユーザ”キー（複数設定可能）に設定された所定キーを基準に“ＯＲ”で比較する。そして、一致したユーザが類似ユーザ特性をもつユーザ（以下、類似ユーザ）であると判断している。

なお、ここで挙げているのは一例であり、他のキーワードを使用して類似ユーザを特定しても構わない。また、直接ユーザを指定して、ユーザＢのユーザ特性は参照する（類似ユーザとみなす）が、ユーザＣのユーザ特性は参照しない（類似ユーザとみなさない）、という指定をしても構わない。

図６及び図１５の例では、ユーザ「原口和夫」の類似ユーザの検索キーは「プロジェクト」であり、プロジェクトキーがユーザ「原口和夫」と一致するユーザ「高沢亜美」および「横尾俊樹」が類似ユーザであると判断される。

次に、ステップＳ５０３において、インデックス候補情報生成部４０６はユーザ情報操作部３００に指示して、ステップＳ５０２で取得した類似ユーザのユーザ特性を検索し、インデックス設定履歴を保持しているか否かを判断する。インデックス設定履歴情報（図１５の（ｂ）の１５０２／１５０３参照）を保持している場合、ステップＳ５０４において、その履歴情報を取得してセッション記憶部２０２に保存する。

この際、参照する履歴情報が大量の場合、絞り込んでも構わない。例として、類似ユーザのユーザ特性に関して、インデックス設定履歴情報の保存された日付を元に、期間や季節に応じて参照するインデックス設定履歴情報の絞込みを行うことがあげられる。また、あらかじめ文字列を指定しておくことでＯＣＲ処理や全文検索により、前記あらかじめ指定された文字列が抽出された場合など、ある特定の文書情報が検出された場合に、インデックス候補情報から排除してもよい。もしくは、インデックス候補情報における優先度を変更するとしても構わない。

次に、ステップＳ５０５において、ステップＳ２０２で取得した文書情報と、ステップＳ５０４で取得した類似ユーザのインデックス設定履歴情報とを比較し、一致するものがあるか否かを判断する。この比較により、ステップＳ５０２で取得した特性ユーザをさらに絞り込むことになる。

図１５の（ｂ）の例では、ユーザ「原口和夫」の文書情報で“議事録”が、ユーザ「横尾俊樹」のインデックス設定履歴情報の文書情報と一致しているが、ユーザ「高沢亜美」のインデックス設定情報には一致するキーワードがない。つまり、ユーザ「原口和夫」のインデックス候補情報生成処理において、参考とするべき類似ユーザは「横尾俊樹」である。ここでは、参考とするべき類似ユーザを１人として説明しているが、複数人いても構わない。

次に、ステップＳ５０６（図１７において後述）において、ステップＳ５０５で取得した類似ユーザのインデックス設定履歴情報を、インデックス候補情報に追加する。

なお、図１５の（ｃ）の例では、図１９において表示されているＵＩにおいて、ユーザによってインデックス情報１５０４が指定される。図８のステップＳ２１０及びＳ２１１では、この指定されたインデックス情報が取得され、文書管理サービスサーバＰＣ４０に送信されることになる。

（インデックス候補情報の追加処理）
図１７を用いて、図１６のＳ５０１およびＳ５０６のインデックス候補情報の追加処理を説明する。

ステップＳ６０１において、インデックス候補情報生成部４０６は、文書登録処理においてインデックス候補情報を一時的に管理するためのリストが既にインデックス候補情報生成部４０６の備えるリスト記憶部（不図示）に保持されているかを判断する。保持されていないと判断した場合、リスト記憶部に空のインデックス候補情報を管理するためのリストを作成する等、新規にインデックス候補情報を作成するための準備を行う（Ｓ６０２）。その後、ステップＳ６０３に移行する。

次に、ステップＳ６０３において、リスト記憶部に保持されたインデックス候補情報のリストにこれから追加しようとしているインデックス候補情報が、既に存在するか否かを確認する。存在していない場合に限り、ステップＳ６０４において、インデックス候補情報をインデックス候補情報のリストに追加する。

（インデックス設定履歴情報の保存処理）
図１８は、図８のステップＳ２１６でのインデックス設定履歴情報をユーザ特性テーブルに保存する処理のフローチャートである。保存先は、セッション記憶部２０２でも構わないし、ユーザ情報操作部３００を介してユーザ情報記憶部３０１でも構わない。かかる処理は、主にＷｅｂアプリケーションサーバＰＣ２０のメイン制御部２００で実行される。

ステップＳ７００において、メイン制御部２００は、ステップＳ２１０においてインデックス情報を取得したか否かを判断する。取得した場合に限り、ステップＳ７０１において、セッション記憶部３００に保持されたユーザ特性のうちからランキング設定情報を取得する（図６参照）。次に、ステップＳ７０２において、ステップＳ７０１において取得したランキング設定に応じて、セッション記憶部３００乃至ユーザ情報記憶部３０１に保持するための文書情報を特定する。

なお、本実施形態では、ランキング設定を、登録文書から取得できた文書情報の一部に限定して履歴を保持することを目的に利用している。しかし、別の限定方法を用いて、文書情報の履歴を保持しても構わないし、文書情報の全てを保持しても構わない。

（文書の登録およびインデックス情報の設定画面例）
図１９は、図１３の操作／コントロール領域１２０３に表示された「登録」ボタンを押下された際に表示する、文書の登録およびインデックス情報の設定を行うためのユーザインタフェース（ＵＩ）の一例である。

ユーザ領域１３０１のユーザが、文書登録領域１３０２にＷｉｎｄｏｗｓ（登録商標）フォルダ等からのファイルのドラック＆ドロップを行うと、ＣｌｉｅｎｔＰＣ１０は内部的に文書をＷｅｂアプリケーションサーバ２０に送信する。その後、ステップＳ２０４にて生成したインデックス候補情報を取得し、インデックス情報の設定領域１３０３の選択肢としてユーザに提示する。ユーザはこの選択肢のリストから所望のキーワードを指定して文書登録を行う。１３０４は操作／コントロール領域であるが、ここでは詳説しない。

ここでは、選択文書のフォーカスが移った場合、または、ユーザがログアウトした場合に指定したインデックス情報を保存することを想定しているが、ボタン等を用意して保存するタイミングをユーザが意識的に指示しても構わない。また、ユーザが設定可能なインデックス情報として、ここでは選択肢からの指定する例しか挙げていないが、ユーザが所望する選択肢には存在しないキーワードを入力するための手段を提供していても構わない。

（インデックス情報による検索の条件設定／検索指示画面例）
図２０は、図１３の操作／コントロール領域１２０３に表示された「絞込み検索」ボタンを押下された際に表示する、インデックス情報による検索の条件設定／検索を実行するためのユーザインタフェース（ＵＩ）の一例である。

検索条件の設定領域１４０２において、ユーザのアクセス可能な文書に設定されたインデックス情報を表示する。

検索結果の表示領域１４０３は、検索条件の設定領域１４０２で指定したインデックス情報による検索を実行した場合に、それらが設定された文書を検索結果として表示する領域である。

ユーザ領域１４０１および操作／コントロール領域１４０１については、詳説しない。

＜本文書管理システムの実施形態２の処理例＞
本発明の実施形態２を、図１乃至図１８、さらに図２１に基づき説明する。

実施形態１に係る文書管理システムの処理と異なるのは、図１に図示しないメールサーバからＣｌｉｅｎｔＰＣ１０または複合機５０に添付ファイル付きのメールが送信された場合である。このとき、自動的にインデックス候補情報からインデックス情報が選択され、かつ、添付された文書に対するインデックス情報として付与された状態で文書管理システムに自動的に保存されることである。

（メール受信後の自動インデックス情報付与処理）
図２１は、本発明の実施形態２に係る文書管理システムにおける添付ファイル付きメールを受信した際に、添付ファイルをインデックス情報付きで自動保存する時の本文書管理システムにおける処理の流れを示すフローチャートである。

以下、図２１を用いて詳細に説明する。また、ここでの説明は、ＣｌｉｅｎｔＰＣ１０を用いて行うが、複合機５０に置き換えた構成としても構わない。

ステップＳ８００において、データ送受信部２０１が有する電子メール機能（不図示）により、ＣｌｉｅｎｔＰＣ１０または複合機５０からの図示しないメールサーバを経由した、添付ファイル付きのメールを受信する。このメール受信の際に、メイン制御部２００は、データ送受信部２０１を介して、ＣｌｉｅｎｔＰＣ１０または複合機５０からの受信メールの送信元アドレスと添付ファイルを取得する。

ここでは、取得する情報を送信元アドレスとしているが、ユーザが特定できる情報があれば、メールヘッダ、メール本文の情報等のそのほかの情報であっても構わない。

ステップＳ８０１−Ｓ８０２の処理は、ＷｅｂアプリケーションサーバＰＣ２０で実行される。

次にステップＳ８０１では、ステップＳ８００により取得した送信元アドレスを用いて、メイン制御部２００が、ユーザ情報操作部３００に検索を指示して、送信元アドレスを有するユーザを特定する。ここで特定されたユーザのユーザ特性情報を、メイン制御部２００が取得する。

ステップＳ８０２では、メイン制御部２００は、ステップＳ８００およびＳ８０１で取得した登録文書（添付ファイル）とユーザ特性を、データ送受信部２０１を介して文書管理サービスサーバＰＣ４０へ送信する。

ステップＳ８０３−Ｓ８０９の処理は、文書管理サービスサーバＰＣ４０で実行される。

ステップＳ８０３において、文書管理サービスサーバＰＣ４０は、ＷｅｂアプリケーションサーバＰＣ２０から登録文書とユーザ特性を受信する。次に、ステップＳ８０４において、文書情報取得部４０５は、登録文書からＯＣＲ処理、または、全文検索等により文字列を抽出するなどの画像処理を施し、文書情報を取得する。なお、前述した画像処理に加えて、文書に既に設定されている属性等を取得しても構わない。また、文書情報を取得する処理の対象は、ステップＳ８００で受信した添付ファイルを想定しているが、メール本文でも構わないし、メールヘッダやその他の情報を含んでいても構わない。

次に、ステップＳ８０５において、受信したユーザ特性とステップＳ８０４で取得した文書情報をもとに、インデックス候補情報を生成する。インデックス候補情報の生成ステップの詳細は、図１６などを参照して前述したとおりである。

次に、ステップＳ８０６において、インッデクス候補情報生成部４０６がインッデクス候補情報の中からインデックス情報を決定する。本ステップＳ８０６においては、インデックス候補情報の中から任意にインデックス情報を選択することになる。その決定の際には、何らかの重み付けをして優先度を決定し、それに従ったインデックス情報を選択する。本実施形態においては、例えば、図１６のステップＳ５０４〜ステップＳ５０６で追加されるインッデクス候補情報をインデック情報として選択する。これにより、文書に対して過去に用いられたことのあるインデックス情報を自動付与でき、文書登録者以外であっても後で文書の検索がされやすい、さらに再利用がされやすいインデックス付与が行えることになる。尚、全てのインデックス候補情報をインデックス情報として決定する、ということでも構わない。かかる処理は、インデックス情報生成処理あるいはインデックス情報選択処理を含む。

次に、ステップＳ８０７において、文書情報操作部４００は、ステップＳ８０３で受信した登録する文書（添付ファイル）にステップＳ８０４で決定したインデックス情報を属性として設定し、文書情報記憶部４０１に保存する。

ステップＳ８０８において、メール生成部４０７は、上述の送信元アドレスに対して、添付ファイルを登録した旨が本文に記載された電子メールを作成する。ここで、メール本文に記載する文書情報としては、登録した添付ファイルのファイル名、保存フォルダ、保存日時、インデックス情報の設定値などが挙げられる。また、メール本文に限らず、情報をメール添付するということでも構わない。次に、ステップＳ８０９において、文書管理サービスサーバ４０は、文書情報とインデックス情報と作成された電子メールの情報を、メイン制御部２００へ送信する。

ステップＳ８１０−Ｓ８１２の処理は、ＷｅｂアプリケーションサーバＰＣ２０のメイン制御部２００が実行する。

ステップＳ８１０において、メイン制御部２００は、文書情報とインデックス情報と作成された電子メールの情報を受信する。次に、ステップＳ８１１において、受信した文書情報とインデックス情報を送信元アドレスで特定したユーザのユーザ特性情報の一部とする。そして、メイン制御部２００は、このユーザ特性情報をユーザ情報操作部３００に指示してユーザ情報記憶部３０１に保存する。

ステップＳ８１２において、メイン制御部２００は、データ送受信部２０１を介して、ステップＳ８１０で受信した電子メールをメール機能を用いて、送信元アドレスへ文書登録完了のメールとしてメール送信する。

ここで、メール本文に記載する情報として、更には、ステップＳ８０６において生成されたインッデクス候補情報もメール本文の情報に含めても良い。これにより、ユーザが後日、既に登録された文書のインデックス情報を変更しようとした際に、その設定の参考情報として有用な情報が提供されることになる。

本実施形態２の処理により、ユーザは添付ファイル付きのメールを受信しただけで、自動的にインデックス候補情報の中からインデックス情報が付与された文書として文書管理システムに文書登録ができる。このため、より手間のかからない文書登録が可能となる。特に、複合機５０に添付ファイル付きメールが送信された場合、一度ＣｌｉｅｎｔＰＣ１０に転送したり、複合機５０内の記憶装置に保存したりすることなく、文書登録を行うことが可能となる。

また、本発明は、複数の機器（例えばホストコンピュータ、インターフェース機器、プリンタなど）から構成されるシステムあるいは統合装置に適用しても、ひとつの機器からなる装置に適用してもよい。

又、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはｕ ＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

又、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行う。このような処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

本実施形態に係る文書管理システムのシステム概念図である。 本実施形態に係る文書管理システムのＰＣのハードウェア構成図である。 本実施形態に係る文書管理システムのソフトウェア構成図である。 本実施形態に係る文書管理システムにおけるログイン及びユーザ特性登録処理の概要図である。 本実施形態に係る文書管理システムにおけるログイン及びユーザ特性登録処理を示すフローチャートである。 本実施形態に係る文書管理システムにおけるユーザ特性テーブル構成の一例を示す図である。 本実施形態に係る文書管理システムにおける文書登録処理の概要図である。 実施形態１に係る文書管理システムにおける文書登録処理の流れを示すフローチャートである。 本実施形態に係る文書管理システムにおける文書アクセス時の重み付け処理の概要図である。 本実施形態に係る文書管理システムにおける文書アクセス時の重み付け処理の流れを示すフローチャートである。 本実施形態に係る文書管理システムにおけるログイン時の文書収集処理の概要図である。 本実施形態に係る文書管理システムにおけるログイン時の文書収集処理の流れを示すフローチャートである。 本実施形態に係る文書管理システムにおけるログイン後の文書収集結果を表示するユーザインタフェースの一例を示す図である。 本実施形態に係る文書管理システムにおける文書登録処理の概要図である。 本実施形態に係る文書管理システムにおけるインデックス候補情報生成の一例を示す図である。 本実施形態に係る文書管理システムにおける文書登録時のインデックス候補情報生成処理の流れを示すフローチャートである。 本実施形態に係る文書管理システムにおけるインデックス候補情報生成時のインデックス候補情報の追加処理の流れを示すフローチャートである。 本の実施形態に係る文書管理システムにおける文書登録時のインデックス設定履歴情報の保存処理の流れを示すフローチャートである。 本実施形態に係る文書管理システムにおける文書登録／インデックス情報登録を行うユーザインタフェースの一例を示す図である。 本実施形態に係る文書管理システムにおける登録文書のインデックス情報の検索による絞込みを行うユーザインタフェースの一例を示す図である。 実施形態２に係る文書管理システムにおける添付ファイル付きメールを受信した際に、添付ファイルをインデックス情報付きで自動保存する時の処理の流れを示すフローチャートである。

Claims (13)

1. 文書の登録を指定したユーザを特定するユーザ特性情報を取得するユーザ特性情報取得手段と、
   前記文書の文書情報を取得する文書情報取得手段と、
   前記ユーザ特性情報取得手段によって得られたユーザ特性情報と、前記文書情報取得手段によって得られた文書情報と、前記ユーザ特性情報取得手段によって得られたユーザ特性情報と所定の項目が一致するユーザ特性情報を持つ他のユーザの履歴情報とに基づき、前記文書に付与するためのインデックス候補情報を生成するインデックス候補情報生成手段と、
   前記インデックス候補情報生成手段が生成したインデックス候補情報を出力するインデックス候補情報出力手段と、
   前記インデックス候補情報出力手段が出力したインデックス候補情報から該ユーザにより選択されたインデックス情報を受信するインデックス情報受信手段と、
   前記インデックス情報受信手段により受信した前記インデックス情報を前記文書情報取得手段により取得した文書情報に対応する文書に関連づけて登録する文書登録手段と
   を有することを特徴とする文書管理装置。
2. 前記文書情報取得手段は、文書中のＯＣＲ抽出文字列のうちから頻出回数の上位のＯＣＲ抽出文字列を文書情報として取得することを特徴とする請求項１に記載の文書管理装置。
3. 前記インデックス候補情報生成手段は、前記ユーザ特性情報取得手段によって得られたユーザ特性情報の項目と前記文書情報取得手段によって得られた文書情報の項目とを比較して、一致した項目を前記インデックス候補情報に追加し、更に、前記ユーザ特性情報取得手段によって得られたユーザ特性情報と所定の項目が一致するユーザ特性情報を持つ他のユーザの履歴情報から文書の登録時に設定したインデックス情報を取得し、前記取得したインデックス情報を前記インデックス候補情報に追加することにより、前記インデックス候補情報を生成することを特徴とする請求項１に記載の文書管理装置。
4. 前記インデックス候補情報出力手段は、前記インデックス候補情報を選択可能なユーザインタフェースとしてユーザの情報処理装置に表示させる表示指示手段を有することを特徴とする請求項１に記載の文書管理装置。
5. 前記文書登録手段は、さらに、前記インデックス情報に関連づけて前記ユーザ特性情報取得手段によって得られた前記ユーザ特性情報を前記文書に設定して登録することを特徴とする請求項１に記載の文書管理装置。
6. 前記ユーザ特性情報取得手段によって得られたユーザ特性情報と前記文書登録手段により登録した前記文書に前記インデックス情報に関連づけて設定したユーザ特性情報とを比較し、所定の項目が一致するユーザ特性情報を有する文書を前記ユーザに関連する文書として抽出する文書抽出手段を更に有することを特徴とする請求項５に記載の文書管理装置。
7. 文書管理システムのユーザ特性情報取得手段が、文書の登録を指定したユーザを特定するユーザ特性情報を取得するユーザ特性情報取得工程と、
   前記文書管理システムの文書情報取得手段が、前記文書の文書情報を取得する文書情報取得工程と、
   前記文書管理システムのインデックス候補情報生成手段が、前記ユーザ特性情報取得工程で得られたユーザ特性情報と、前記文書情報取得工程で得られた文書情報と、前記ユーザ特性情報取得工程で得られたユーザ特性情報と所定の項目が一致するユーザ特性情報を持つ他のユーザの履歴情報とに基づき、前記文書に付与するためのインデックス候補情報を生成するインデックス候補情報生成工程と、
   前記文書管理システムのインデックス候補情報出力手段が、前記インデックス候補情報生成工程で生成したインデックス候補情報を出力するインデックス候補情報出力工程と、
   前記文書管理システムのインデックス情報受信手段が、前記インデックス候補情報出力工程で出力したインデックス候補情報から該ユーザにより選択されたインデックス情報を受信するインデックス情報受信工程と、
   前記文書管理システムの文書登録手段が、前記インデックス情報受信工程で受信した前記インデックス情報を前記文書情報取得工程で取得した文書情報に対応する文書に関連づけて登録する文書登録工程とを有することを特徴とする文書管理方法。
8. 前記文書情報取得工程では、文書中のＯＣＲ抽出文字列のうちから頻出回数の上位のＯＣＲ抽出文字列を文書情報として取得することを特徴とする請求項７に記載の文書管理方法。
9. 前記インデックス候補情報生成工程では、前記ユーザ特性情報取得工程で得られたユーザ特性情報の項目と前記文書情報取得工程で得られた文書情報の項目とを比較して、一致した項目を前記インデックス候補情報に追加し、更に、前記ユーザ特性情報取得工程で得られたユーザ特性情報と所定の項目が一致するユーザ特性情報を持つ他のユーザの履歴情報から文書の登録時に設定したインデックス情報を取得し、前記取得したインデックス情報を前記インデックス候補情報に追加することにより、前記インデックス候補情報を生成することを特徴とする請求項７に記載の文書管理方法。
10. 前記インデックス候補情報出力工程では、前記インデックス候補情報を選択可能なユーザインタフェースとしてユーザの情報処理装置に表示させる表示指示工程を有することを特徴とする請求項７に記載の文書管理方法。
11. 前記文書登録工程では、さらに、前記インデックス情報に関連づけて前記ユーザ特性情報取得手段によって得られた前記ユーザ特性情報を前記文書に設定して登録することを特徴とする請求項７に記載の文書管理方法。
12. 前記ユーザ特性情報取得工程で得られたユーザ特性情報と前記文書登録工程で登録した前記文書に前記インデックス情報に関連づけて設定したユーザ特性情報とを比較し、所定の項目が一致するユーザ特性情報を有する文書を前記ユーザに関連する文書として抽出する文書抽出工程を更に有することを特徴とする請求項１１に記載の文書管理方法。
13. コンピュータを、
    文書の登録を指定したユーザを特定するユーザ特性情報を取得するユーザ特性情報取得手段、
    前記文書の文書情報を取得する文書情報取得手段、
    前記ユーザ特性情報取得手段によって得られたユーザ特性情報と、前記文書情報取得手段によって得られた文書情報と、前記ユーザ特性情報取得手段によって得られたユーザ特性情報と所定の項目が一致するユーザ特性情報を持つ他のユーザの履歴情報とに基づき、前記文書に付与するためのインデックス候補情報を生成するインデックス候補情報生成手段、
    前記インデックス候補情報生成手段が生成したインデックス候補情報を出力するインデックス候補情報出力手段、
    前記インデックス候補情報出力手段が出力したインデックス候補情報から該ユーザにより選択されたインデックス情報を受信するインデックス情報受信手段、
    前記インデックス情報受信手段により受信した前記インデックス情報を前記文書情報取得手段により取得した文書情報に対応する文書に関連づけて登録する文書登録手段、
    として機能させるためのプログラム。

Images