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

Description

本発明は、文書を管理する文書管理方法、文書管理装置及び文書管理システムに関する。例えば、ユーザの特性/プロファイルに関連付けて文書を保存しておくことで、後から利用するユーザの特性/プロファイルに関連する文書を自動収集する文書管理方法、文書管理装置及び文書管理システムに関する。

現在の文書管理システムでは、階層構造をなすフォルダに文書が格納される、もしくは、階層構造のフォルダに文書が格納されているような見え方をするものが多い。そのような構成を利用するユーザの文書管理の一例として、ユーザが、特定の業務に関する文書の関連性を高めるために、同じフォルダ内に関連する文書を集めたり、文書に同じインデックスやキーワードを設定したりする。

しかし、上述したような一般ユーザの使い方では、必ずしも管理者の意図したフォルダ構成（管理者は形式別や表題別の分類を望む）と一致しないため、管理者にとって煩雑な整理作業や管理作業が発生してしまう場合がある。

そこで、上記問題を解決するための従来例として、特許文献１には次のような提案がされている。すなわち、管理者が分類して管理するフォルダ構成とは独立して、一般ユーザが独自の分類方式を利用できるようにワークスペースという概念を設ける。一般ユーザは、このワークスペースに特定の文書を集めることで、後から文書を利用し易くできる。

また、上記問題を解決するための別の従来例として、特許文献２では、ユーザが任意の検索条件を指定し、その検索結果を表示する仮想的なフォルダ状のビュー（「ユーザ設定トレイ」と言う）を提供している。
特開2006-268700号公報 特開2003-173343号公報

ところで、文書管理システムの目的の一つとしては、「保存した文書や情報の再利用」が挙げられる。ここで、文書や情報を再利用する対象は自分のみでなく、同じ業務に携わったり、同じ組織に所属する他のユーザも含まれることになる。

しかしながら、引用文献１の管理方法においては、あるユーザが作成したワークスペースを如何に他のユーザが利用するかには言及されていない。従って、他のユーザが作成したワークスペースの存在を知らないユーザは、結局、従来のフォルダ階層構造の中から文書を検索することになってしまう。

また、引用文献２の管理方法では、検索するためのキーワードをユーザが指定することになる。従って、実際に文書を検索するためのキーワードは、自分が独自に管理している情報であれば所望の結果を得られるように指定できるが、他人が作成した文書の収集には必ずしも有効な方法ではない。

本発明は、上記課題を解決するために、ユーザの特性を用いて該ユーザに関連する情報を検索して収集する文書管理方法、文書管理装置及び文書管理システムの提供を目的とする。更に、従来煩雑になるフォルダ分けなどの分類分けを行う文書管理方法、文書管理装置及び文書管理システムの提供を目的とする。

上記課題を解決するために、本発明における文書管理装置は、ユーザのログイン情報より当該ユーザを特定するユーザ特性情報を取得するユーザ特性情報取得手段と、文書の文書情報を取得する文書情報取得手段と、文書の属性情報として、ユーザ特性情報を、前記文書情報取得手段によって得られた文書情報に対応づけて保存する保存手段と、前記保存された文書情報で示す文書に対するアクセスがあった際に、該アクセスを指示したユーザのユーザ特性情報を用いて、該アクセスされた文書の属性情報に含まれる属性の重み付けを変更することで、該アクセスされた文書の属性情報を更新する更新手段と、ユーザのログインに応じて、前記ユーザ特性情報取得手段によりログインしたユーザのユーザ特性情報を取得され、当該取得されたユーザ特性情報と前記保存手段に保存された文書の属性情報とに基づき、当該取得されたユーザ特性情報に関連する文書情報を取得する文書取得手段と、前記文書取得手段により取得された文書情報を表示するための表示内容を生成する生成手段とを有することを特徴とする。

本発明により、ユーザの特性を用いることで、該ユーザが検索式を意識することなく、該ユーザに関連する情報を検索して収集することができる。

また、文書の持つ意味を文書属性の重み付けから決定することができ、従来煩雑になるフォルダ分けなどの分類分け作業を行い、分類毎の状態をユーザに提示することができる。

また、ユーザの特性に応じて該ユーザに関連性のある文書やフォルダを検索して収集するため、既に存在するユーザに関連する有用な情報を再利用することを可能とする。

更に、ユーザの特性がある一定のルールにより定義されているので、ユーザの特性に応じたキーワードを用いて文書収集することができる。

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

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

図１では、本実施形態に係る文書管理システムには、以下の機器がネットワークを介して接続されている。ユーザＡがウェブブラウザを介してＷｅｂアプリケーションにアクセスするためのＣｌｉｅｎｔＰＣ１０（ユーザ端末とも言う）が接続されている。また、本実施形態に係る文書管理システムのＷｅｂアプリケーションを提供するＷｅｂアプリケーションサーバＰＣ２０が接続されている。また、本システムにアクセスするユーザの情報を管理するユーザ管理サービスサーバＰＣ３０が接続されている。また、文書を保存／管理する機能を有する文書管理サービスサーバＰＣ４０が接続されている。

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

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

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

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

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

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

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

次に、文書管理サービスサーバＰＣ４０にある文書情報操作部４００は、メイン制御部２００からの指示に従い、文書情報記憶部４０１に保存されている文書の実体及びインデックス情報を含む文書属性の登録、保存、抽出、編集などの操作を行う。文書検索部４０２は、メイン制御部２００からの指示に従い、文書を検索するための方法を決定し、文書情報操作部４００を介して文書情報記憶部４０１より検索結果を取得する。比較部４０３は、メイン制御部２００からの指示に従い、文書属性とユーザ特性との比較を行い、更に、必要に応じて文書情報操作部４００を介して文書情報記憶部４０１に保存されている文書の属性の重み付けを変更する。文書分類部４０４は、メイン制御部２００からの指示に従い、文書属性のカウント（重み付け）値から分類分けを実行し、その結果をメイン制御部２００に返す。

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

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

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

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

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

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

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

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

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

各ユーザ名６１に対応するユーザ特性としては、所属部署６２、役職６３、課内担当６４、プロジェクト６５、プロジェクト内での業務６６、その他６７などがある。かかるユーザ特性は、後述する文書自動収集処理において利用される。

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

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

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

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

図７は、本文書管理システムにおける文書登録処理のシステム動作の概要である。図８は、文書処理時の本文書管理システムにおける処理の流れを示すフローチャートである。以下、図７及び図８を用いて詳細に説明する。

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

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

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

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

次に、メイン制御部２００は、ステップＳ２０３において、ステップＳ２０１によりセッション記憶部２０２に保存した文書Ｄｏｃ１を、文書情報操作部４００に指示して文書情報記憶部４０１に保存する（図７のプロセスＰ２１参照）。この時に、前記ステップＳ２０２によりセッション記憶部２０２により取得したユーザ「原口和夫」のユーザ特性を文書「Ｄｏｃ１」の属性情報とする。

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

なお、ここでは文書登録ごとにユーザ情報記憶部３０１に保存する処理を述べている。しかし、メイン制御部２００は、セッション記憶部２０２に保持されている「原口和夫」のユーザ特性を更新し、複数の文書登録が終了した時点でユーザ情報記憶部３０１にまとめて保存しても構わない
（文書属性重み付け処理）
あるユーザが、ＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセス（ログイン）し、更に文書にアクセスする。ここで、アクセスとは閲覧、印刷、もしくはコピーなどの操作を含むが、本実施形態においては、閲覧を例にして説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（実施形態１の文書収集結果の表示画面例）
図１３は、本文書管理システムの機能を提供するためのＷｅｂアプリケーションにログイン後の、本実施形態による文書収集結果を表示するユーザインタフェースの一例（ＵＩ）の一例である。

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

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

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

＜本文書管理システムの実施形態２の処理例＞
本発明の実施形態２の処理例を説明する。上記実施形態１に係る文書管理システムの処理に加えて、実施形態２の処理例では、本文書管理システムに登録された文書を、ユーザ所望の分類分けになるように文書属性の重み付けを変更できることである。なお、文書管理システムの構成や、ユーザ及び文書の登録、重み付け、自動収集などの処理は実施形態１と同様なので、説明は省略する。

（文書属性重み付け変更処理）
図１４は、本実施形態２に係る文書管理システムにおける文書属性重み付け変更処理の流れを示すフローチャートである。かかるフローチャートは、ＷｅｂアプリケーションサーバＰＣ２０にあるメイン制御部２００の処理である。あるユーザが、ＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセス（ログイン）し、特定の文書を指定して、自動的に分類された文書の分類を手動で変更する。以下、図１４を用いて詳細に説明する。

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

次に、ステップＳ５０１において、メイン制御部２００は、ステップＳ５００により表示されたユーザのページにて、ユーザが所望の文書を選択し、他の分類への移動が実行されたか否かを確認する。移動が確認されない場合は処理を終了する。

移動が確認されると、メイン制御部２００は、データ送受信部２０１にて受信したユーザが指定した文書と移動した先の分類の情報とを、一旦セッション情報と関連付けてセッション記憶部２０２に保存する。この際、データ送受信部２０１にて受信したユーザが指定した文書及び移動した先の分類を特定する情報は、名前を特定するものではなく、それらを特定するIDであって構わない。

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

次に、ステップＳ５０３において、メイン制御部２００は、ステップＳ５０２によりセッション記憶部２０２に保存したユーザが指定した文書の文書情報に対し、ユーザが指定した所望の分類分けになるように文書属性の重み付けを変更して保存する。具体的には、ユーザが指定した所望の分類分けになるように、その分類分けに対応する文書属性の項目の重み値を、他の文書属性の項目の重み値より最も大きくなるように加算する。

次に、ステップＳ５０４において、メイン制御部２００は文書情報操作部４００に依頼し、ステップＳ５０３により変更された文書属性の重み値で、文書情報記憶部４０１に保存されている文書の文書属性の重み付けを更新して保存する。

なお、文書情報記憶部４０１に保存されている文書の文書属性の重み付けを変更するのではなく、ユーザのカスタマイズ／パーソナライズ情報として指定された文書の文書属性値を記憶しておいても良い。この場合、メイン制御部２００は、ユーザ情報操作部３００に指示し、ユーザ情報記憶部３０１に指定した文書を示す情報及び文書属性の情報をユーザ情報と関連付けて保持しておく。これにより、次回ユーザが本文書管理システムにログインした際に、自動的にユーザ所望の分類分けが可能となる。

また、ユーザ情報記憶部３０１に文書を示す情報及び文書属性の情報を保存することとしたが、文書属性の情報ではなく、ユーザが所望する文書の分類分けの結果の情報を保存しても良い。

また、本実施形態においては、ユーザが文書の分類を変更した場合の動作について説明したが、ユーザの操作はそれ以外であっても構わない。例えば、ユーザがログインした画面上で文書を削除した場合、次回からそのユーザのログイン画面には削除した文書が表示されないように重み付けを変更しても良い。この際には、その削除指示された文書に非表示にする属性情報を付与するなどして実現することが可能である。また、この手法において一度非表示するように設定された文書であっても、文書自体を削除するわけではないので、全文書を格納するデータベースに対して意図的に検索を行えば、文書を取得することが可能である。

本実施形態２の処理により、ユーザは文書の分類分けを変更することができるため、より適切な分類分けが可能となる。

＜本文書管理システムの実施形態３の処理例＞
本発明の実施形態３の処理例を説明する。実施形態１に係る文書管理システムと異なるのは文書自動収集処理であり、実施形態３では文書自動収集処理の結果としてＣｌｉｅｎｔＰＣ１０のブラウザ上に表示される文書リストが階層的に表示されることである。なお、文書管理システムの構成や、ユーザ及び文書の登録、重み付け、重み付け変更などの処理は実施形態１及び２と同様なので、説明は省略する。

（実施形態３の文書自動収集処理）
図１５は、実施形態３に係る文書管理システムにおける文書自動収集処理の流れを示すフローチャートである。かかるフローチャートは、ＷｅｂアプリケーションサーバＰＣ２０にあるメイン制御部２００の処理である。なお、図１５の特徴ブ部はステップＳ６０８〜Ｓ６１０の処理である。図１６は、実施形態３に係る文書管理システムにおける文書収集結果を表示するユーザインタフェースの一例である。

本実施形態３では、ユーザＡが、ＣｌｉｅｎｔＰＣ１０のブラウザを介して本文書管理システムの機能を提供するためのＷｅｂアプリケーションにアクセス（ログイン）すると、自動的に文書収集処理が走る。そして、ＣｌｉｅｎｔＰＣ１０のウェブブラウザ上で取得した文書リストを階層的に表示する。以下、図１５及び図１６を用いて詳細に説明する。なお、図１５の文書自動収集処理のフローチャートは、ユーザＡが本文書管理システムにログインした後からのステップを示す。

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

次に、ステップＳ６０１において、メイン制御部２００は、ステップＳ６００により取得したユーザ特性による文書の検索を文書検索部４０２に指示する。続いて、文書検索部４０２は、ユーザ特性の各項目の値をキーワードとして“ＯＲ”の条件で文書情報操作部４００に指示して、文書情報記憶部401より条件に一致する文書を検索する。具体的には、ユーザＡの場合、ユーザ特性である“設計1”、“文書管理”、“インストーラ”などをキーワードにして検索を行う。

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

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

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

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

次に、ステップＳ６０８において、メイン制御部２００は、文書分類部４０４に指示し、ステップＳ６０７により分類分けされた文書リストに対して文書属性の項目の値を確認する。次に、ステップＳ６０９において、メイン制御部２００は、ステップＳ６０８により文書リストの各文書に対して文書属性の項目の値を確認し、同じ文書属性の項目としてｎ個以上の値があればかかる項目を新たに分類分けする。

具体的には、ある文書の文書属性のうち最大カウント（重み付け）数の分類分けが“文書管理”で、文書属性の項目“業務”の値として“計画立案”がｎ個以上あったとする。その場合、その文書は担当プロジェクトである“文書管理”の下位の“計画立案”の分類となる（図１６参照）。

なお、ここで、ｎ個は、図示しないユーザインタフェースを介してユーザが指定できても良いし、本文書管理システムとして固定の値であっても構わない。

更に、ステップＳ６０８において単純に文書属性の項目の値を確認するのではなく、ステップＳ６０７により文書属性の最大カウント（重み付け）数となる項目に関連した文書属性の項目に絞って、その後に文書属性の項目の値を確認しても良い。具体的には、ある文書の文書属性のうち最大カウント（重み付け）数の分類分けが“文書管理”であった場合、文書属性の項目“業務”に絞って同じ文書属性の項目の値がｎ個以上存在するか確認しても良い。この方が、ユーザにとって意味のある階層的な分類分けが可能となる。

次に、ステップＳ６１０において、メイン制御部２００は、ステップＳ６０９により分類分けされた文書リストに対して、文書分類部４０４がこれ以下の分類分けが困難か、もしくは不要かを判断する。具体的には、文書リストに対して、ステップＳ６０９において分類分けの判断に用いた同じ文書属性の項目の値がｎ個以上あるか否かを確認し、その条件を満たさない場合、分類分け処理を止め、後述するステップＳ６１１に移る。

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

（実施形態３の文書収集結果の表示画面例）
図１６は、本文書管理システムの機能を提供するためのＷｅｂアプリケーションにログイン後の、実施形態３による文書収集結果を表示するユーザインタフェースの一例である。

文書の表示領域１３０２において、ユーザＡの特性に応じて、分類分けされ文書収集結果が表示される。具体的には、所属部署である“設計１”、担当プロジェクトである“文書管理”、担当プロジェクト内での業務である“インストーラ”といった分類分けされたエリアに自動収集し、分類分けされた文書リストが表示される。そして、“文書管理”に分類された文書リストが更に分類分けがなされた場合、例えば“計画立案”フォルダのように表示し、それを選択することで“計画立案”に分類された文書リストが表示される。更に、図１６においては、新着文書の表示やＵＩのカスタマイズを行う、またはユーザに関連性の高いフォルダリンクの選択などを行うユーザ領域１３０１や、文書の操作やコントロールなどを行うための表示１３０３が表示されている。

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

実施形態３により、分類分け結果をより詳細に階層構造としてみせることができるため、更に整理された状態で所望の文書にアクセスすることができる。

なお、本実施形態のシステム構成は、ＬＡＮに接続されたシステムであっても、有線無線の外部ネットワークを介して接続されたシステムでも同様の処理が可能である。

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

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

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

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

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

本実施形態に係る文書管理システムのシステム概念図である。 本実施形態に係る文書管理システムのＰＣのハードウェア構成図である。 本実施形態に係る文書管理システムのソフトウェア構成図である。 本実施形態に係る文書管理システムにおけるログイン及びユーザ特性登録処理の概要図である。 本実施形態に係る文書管理システムにおけるログイン及びユーザ特性登録処理を示すフローチャートである。 本実施形態に係る文書管理システムにおけるユーザ特性テーブル構成の一例を示す図である。 本実施形態に係る文書管理システムにおける文書登録処理の概要図である。 本実施形態に係る文書管理システムにおける文書登録処理の流れを示すフローチャートである。 本実施形態に係る文書管理システムにおける文書アクセス時の重み付け処理の概要図である。 本実施形態に係る文書管理システムにおける文書アクセス時の重み付け処理の流れを示すフローチャートである。 本実施形態に係る文書管理システムにおけるログイン時の文書収集処理の概要図である。 実施形態１に係る文書管理システムにおけるログイン時の文書収集処理の流れを示すフローチャートである。 実施形態１に係る文書管理システムにおけるログイン後の文書収集結果を表示するユーザインタフェースの一例を示す図である。 実施形態２に係る文書管理システムにおける文書属性の重み付け変更処理の流れを示すフローチャートである。 実施形態３に係る文書管理システムにおけるログイン時の文書収集処理の流れを示すフローチャートである。 実施形態１に係る文書管理システムにおけるログイン後の文書収集結果を表示するユーザインタフェースの一例を示す図である。

Claims (18)

1. ユーザのログイン情報より当該ユーザを特定するユーザ特性情報を取得するユーザ特性情報取得手段と、
   文書の文書情報を取得する文書情報取得手段と、
   文書の属性情報として、ユーザ特性情報を、前記文書情報取得手段によって得られた文書情報に対応づけて保存する保存手段と、
   前記保存された文書情報で示す文書に対するアクセスがあった際に、該アクセスを指示したユーザのユーザ特性情報を用いて、該アクセスされた文書の属性情報に含まれる属性の重み付けを変更することで、該アクセスされた文書の属性情報を更新する更新手段と、
   ユーザのログインに応じて、前記ユーザ特性情報取得手段によりログインしたユーザのユーザ特性情報を取得され、当該取得されたユーザ特性情報と前記保存手段に保存された文書の属性情報とに基づき、当該取得されたユーザ特性情報に関連する文書情報を取得する文書取得手段と、
   前記文書取得手段により取得された文書情報を表示するための表示内容を生成する生成手段と
   を有することを特徴とする文書管理装置。
   
2. 前記保存手段は、文書の属性情報として前記ユーザ特性情報に含まれる複数の項目と、前記文書との関連性を表わす重み度を当該項目ごとに対応づけてさらに保存し、
   前記生成手段は、前記文書取得手段により取得された文書情報を、前記保存手段により保存された前記項目の重み度に基づき分類して表示するための表示内容を生成することを特徴とする請求項１に記載の文書管理装置。
3. 前記生成手段は、前記文書取得手段により取得された文書情報を、前記保存手段により保存された前記項目の重み度に基づき、複数の項目により階層的に分類して表示するための表示内容を生成することを特徴とする請求項２に記載の文書管理装置。
4. 前記生成された表示内容による表示に基づく、前記ログインしたユーザによる文書の削除指示を受信した場合、当該削除指示された文書自体を削除することなく、前記生成手段は当該ログインしたユーザのために、当該削除指示された文書の文書情報を含まない表示内容を生成することを特徴とする請求項１乃至３のいずれか１項に記載の文書管理装置。
5. 前記文書に対するアクセスとは、当該文書の閲覧操作であることを特徴とする請求項１乃至４のいずれか１項に記載の文書管理装置。
6. 前記文書に対するアクセスとは、当該文書の印刷操作であることを特徴とする請求項１乃至４のいずれか１項に記載の文書管理装置。
7. 前記文書に対するアクセスとは、当該文書のコピー操作であることを特徴とする請求項１乃至４のいずれか１項に記載の文書管理装置。
8. ユーザ特性情報取得手段が、ユーザのログイン情報より当該ユーザを特定するユーザ特性情報を取得するユーザ特性情報取得工程と、
   文書情報取得手段が、文書の文書情報を取得する文書情報取得工程と、
   保存手段が、文書の属性情報として、ユーザ特性情報を、前記文書情報取得工程で得られた文書情報に対応づけて保存部に保存する保存工程と、
   更新手段が、前記保存された文書情報で示す文書に対するアクセスがあった際に、該アクセスを指示したユーザのユーザ特性情報を用いて、該アクセスされた文書の属性情報に含まれる属性の重み付けを変更することで、該アクセスされた文書の属性情報を更新する更新工程と、
   文書取得手段が、ユーザのログインに応じて、前記ユーザ特性情報取得工程でログインしたユーザのユーザ特性情報を取得され、当該取得されたユーザ特性情報と前記保存部に保存された文書の属性情報とに基づき、当該取得されたユーザ特性情報に関連する文書情報を取得する文書取得工程と、
   生成手段が、前記文書取得工程で取得された文書情報を表示するための表示内容を生成する生成工程と
   を有することを特徴とする文書管理方法。
   
9. 前記保存工程では、文書の属性情報として前記ユーザ特性情報に含まれる複数の項目と、前記文書との関連性を表わす重み度を当該項目ごとに対応づけてさらに保存し、
   前記生成工程では、前記文書取得工程で取得された文書情報を、前記保存部に保存された前記項目の重み度に基づき分類して表示するための表示内容を生成することを特徴とする請求項８に記載の文書管理方法。
10. 前記生成工程では、前記文書取得工程で取得した文書を特定する情報を、前記保存部に保存された前記項目の重み度に基づき、複数の項目により階層的に分類して表示するための表示内容を生成することを特徴とする請求項９に記載の文書管理方法。
11. 前記生成された表示内容による表示に基づく、前記ログインしたユーザによる文書の削除指示を受信した場合、当該削除指示された文書自体を削除することなく、前記生成工程では当該ログインしたユーザのために、当該削除指示された文書の文書情報を含まない表示内容を生成することを特徴とする請求項８乃至１０のいずれか１項に記載の文書管理方法。
12. 前記文書に対するアクセスとは、当該文書の閲覧操作であることを特徴とする請求項８乃至１１のいずれか１項に記載の文書管理方法。
13. 前記文書に対するアクセスとは、当該文書の印刷操作であることを特徴とする請求項８乃至１１のいずれか１項に記載の文書管理方法。
14. 前記文書に対するアクセスとは、当該文書のコピー操作であることを特徴とする請求項８乃至１１のいずれか１項に記載の文書管理方法。
15. 請求項８乃至１４のいずれか１項に記載の文書管理方法の各工程をコンピュータに実行させるためのプログラム。
16. 文書の登録及び閲覧を行うユーザ端末と登録された文書を管理する文書管理装置とを備える文書管理システムであって、
    前記文書管理装置が、
    前記ユーザ端末から受信するユーザのログインに基づくログイン情報より、当該ユーザを特定するユーザ特性情報を取得するユーザ特性情報取得手段と、
    文書の文書情報を取得する文書情報取得手段と、
    文書の属性情報として、ユーザ特性情報を、前記文書情報取得手段によって得られた文書情報に対応づけて保存する保存手段と、
    前記保存された文書情報で示す文書に対するアクセスがあった際に、該アクセスを指示したユーザのユーザ特性情報を用いて、該アクセスされた文書の属性情報に含まれる属性の重み付けを変更することで、該アクセスされた文書の属性情報を更新する更新手段と、
    ユーザのログインに応じて、前記ユーザ特性情報取得手段によりログインしたユーザのユーザ特性情報を取得され、当該取得されたユーザ特性情報と前記保存手段に保存された文書の属性情報とに基づき、当該取得されたユーザ特性情報に関連する文書情報を取得する文書取得手段と、
    前記文書取得手段により取得された文書情報を表示するための表示内容を生成する生成手段と
    を有することを特徴とする文書管理システム。
    
17. 前記ユーザ端末と前記文書管理装置とはネットワークを介して通信を行い、
    前記ユーザ端末は、ウェブブラウザによりユーザに対して文書の登録及び閲覧を行うための文書管理アプリケーションにログインさせ、前記生成手段により生成された表示内容を、前記ウェブブラウザ上で表示することを特徴とする請求項１６に記載の文書管理システム。
18. 文書の登録及び閲覧を行うユーザ端末と登録された文書を管理する文書管理装置とを備える文書管理システムにおける文書管理方法であって、
    ユーザ特性情報取得手段が、ユーザのログイン情報より当該ユーザを特定するユーザ特性情報を取得するユーザ特性情報取得工程と、
    文書情報取得手段が、文書の文書情報を取得する文書情報取得工程と、
    保存手段が、文書の属性情報として、ユーザ特性情報を、前記文書情報取得工程で得られた文書情報に対応づけて保存部に保存する保存工程と、
    更新手段が、前記保存された文書情報で示す文書に対するアクセスがあった際に、該アクセスを指示したユーザのユーザ特性情報を用いて、該アクセスされた文書の属性情報に含まれる属性の重み付けを変更することで、該アクセスされた文書の属性情報を更新する更新工程と、
    文書取得手段が、ユーザのログインに応じて、前記ユーザ特性情報取得工程でログインしたユーザのユーザ特性情報を取得され、当該取得されたユーザ特性情報と前記保存部に保存された文書の属性情報とに基づき、当該取得されたユーザ特性情報に関連する文書情報を取得する文書取得工程と、
    表示手段が、前記文書取得工程で取得された文書情報を表示する表示工程と
    を有することを特徴とする文書管理方法。
    

Images