JP2011039928A - 文書レビュー作業支援システム - Google Patents

Abstract

【課題】本発明は、文書レビュー作業において、文書作成者およびレビュワーの双方が、特別な操作を行うことなく、互いの作業状況を自動的に把握することを可能とする文書レビュー作業支援システムを提供することを目的とする。
【解決手段】本発明の文書レビュー作業支援システムは、クライアントである複数のパーソナル・コンピュータと該複数のパーソナル・コンピュータにネットワーク接続されたファイルサーバとを備える。本発明の文書レビュー作業支援システムにおいては、各クライアントのローカル・ストレージ上のレビュー対象文書に係るファイルを一意識別子と関連付けて管理した上で、クライアント側でレビュー対象文書ファイルについて発生したイベントを、逐次、ファイルサーバに通知する。ファイルサーバは、クライアント側からのイベント通知に基づいて適宜メッセージを生成し、必要な通知先に送信する。
【選択図】図２

Description

本発明は、文書レビュー作業支援システムに関し、より詳細には、文書レビュー作業において、文書作成者およびレビュワーの双方が、特別な操作を行うことなく、互いの作業状況を自動的に把握することを可能とする文書レビュー作業支援システムに関する。

一般に、文書レビュー作業においては、まず、レビュー対象となる文書が各レビュワーに配布され、各レビュワーは、配付された対象文書に対してのコメントをあらかじめ準備した上で、文書レビュー会議に臨む。そこで各レビュワーは、各自のコメントを発表し、発表されたコメントを集約して最終的なレビュー結果報告書が作成される。

この点につき、近年、レビュー対象となる電子文書をドキュメント共有システムなどを通してレビュワーのパーソナル・コンピュータに配布し、各レビュワーがパーソナル・コンピュータのローカル・ハードディスクに保存された電子文書に対してコメントを追記する文書レビュー方法が知られている。

ここで問題となるのが、文書作成者によるレビュー対象となる電子文書の内容の改変である。文書レビュー作業においては、レビュワーにレビュー作業のための十分な時間を割いてもらうために、文書レビュー会議の開催日に応じて、それよりも前にレビュー文書の原稿が締め切られる。本来であれば、文書作成者は、当該締め切り日までに対象文書の内容を確定した上で、レビュワーにこれを配付するべきであるが、実際には、締め切り日に原稿の十分な推敲が間に合わず、不十分な内容のドラフト版をレビュワーに配付せざるを得ない場合がある。

このような場合、レビュー原稿を配布してから文書レビュー会議までの間に、文書作成者がさらに推敲を重ねた結果、自身のローカル・ハードディスク上で当該レビュー原稿（電子文書）の内容を勝手に改変してしまうことが起こり得る。このような事態が発生すると、先にネットワークを介して配布されたドラフト版を最終稿と信じて添付したレビュワーのコメントが事後的に無効になってしまうことが生じる。

また、対象文書のページ数が膨大な場合、レビュワーによっては、より簡便にレビュー作業を行う目的で、対象文書を印刷し、印刷した紙文書上にコメントを手書きする方法を採る者もいるが、この場合、結果的に、修正前の原稿を大量に印刷することになるため、紙資源の無駄となることに加え、上述したのと同様に紙文書に記載されたレビュワーのコメントが事後的に無効になってしまうという問題があった。
この点につき、特開２００８−２３４０７１号公報（特許文献１）は、ユーザが閲覧している文書に関して他のユーザとメッセージ交換を行うためのメッセージ交換装置を開示する。しかしながら、特許文献１は、上述した問題に対して有効な解決方法を提供するものではない。

本発明は、上記従来技術における課題に鑑みてなされたものであり、本発明は、文書レビュー作業において、文書作成者およびレビュワーの双方が、特別な操作を行うことなく、互いの作業状況を自動的に把握することを可能とする文書レビュー作業支援システムを提供することを目的とする。

本発明者は、文書レビュー作業において、文書作成者およびレビュワーの双方が、特別な操作を行うことなく、互いの作業状況を自動的に把握することを可能とする文書レビュー作業支援システムにつき鋭意検討した結果、クライアントである複数のパーソナル・コンピュータと該複数のパーソナル・コンピュータにネットワーク接続されたファイルサーバとを含む文書レビュー作業支援システムにおいて、各クライアントのローカル・ストレージ上のレビュー対象文書に係るファイルを一意識別子と関連付けて管理した上で、クライアント側でレビュー対象文書ファイルについて発生したイベントを、逐次、ファイルサーバに通知し、ファイルサーバがこのイベント通知に基づいて適宜メッセージを生成して必要な通知先に送信する構成に想到し、本発明に至ったのである。

すなわち、本発明によれば、複数のパーソナル・コンピュータと該複数のパーソナル・コンピュータにネットワーク接続されたファイルサーバとを含む文書レビュー作業支援システムであって、前記パーソナル・コンピュータは、ローカル・ストレージに記録されたレビュー対象の文書ファイルに関するイベントを監視するイベント監視部と、前記イベント監視部のイベントの検出に応答してイベント情報を生成するイベント情報生成部と、前記イベント情報を前記ファイルサーバに送信するイベント情報送信部と、前記ファイルサーバから送信されるメッセージを受信するメッセージ受信部と、受信した前記メッセージを表示するメッセージ表示部とを含み、前記ファイルサーバは、前記パーソナル・コンピュータから送信されるイベント情報を受信するイベント情報受信部と、受信した前記イベント情報を管理するイベント情報管理部と、前記イベント情報管理部が管理する前記イベント情報に基づいて、メッセージを生成するメッセージ生成部であって、受信した前記イベント情報の発信元ユーザの前記文書ファイルに対する役割を判断し、該ユーザの役割が文書作成者である場合には、該文書ファイルのレビュワー用のメッセージを生成し、該ユーザの役割がレビュワーである場合には、該文書ファイルの文書作成者用のメッセージを生成するメッセージ生成部と、前記レビュワー用のメッセージを前記文書ファイルの前記レビュワーのパーソナル・コンピュータに送信し、前記文書作成者用のメッセージを前記文書ファイルの文書作成者のパーソナル・コンピュータに送信するメッセージ送信部とを含む文書レビュー作業支援システムが提供される。

本実施形態の文書レビュー作業支援システムを示す図。 本実施形態の文書レビュー作業支援システムの機能ブロック図。 本実施形態の文書レビュー作業支援システムの処理を示すシーケンス図。 本実施形態の文書レビュー作業支援システムの処理を示すシーケンス図。 本実施形態の文書レビュー作業支援システムの処理を示すシーケンス図。

以下、本発明を、実施形態をもって説明するが、本発明は後述する実施形態に限定されるものではない。なお、以下に参照する各図においては、共通する要素について同じ符号を用い、適宜、その説明を省略するものとする。

図１は、本実施形態の文書レビュー作業支援システム１０（以下、レビュー支援システム１０として参照する）を示す。レビュー支援システム１０は、ファイル共有サーバの機能を備えるレビュー支援サーバ２０と、そのクライアントである複数のパーソナル・コンピュータ３０（以下、クライアントＰＣ３０として参照する）を含んで構成されており、これらは、いずれも、ローカルエリア・ネットワーク（ＬＡＮ）、ワイドエリア・ネットワーク（ＷＡＮ）、またはインターネットといったネットワーク基盤として構成されるネットワーク４０に接続されている。

本実施形態におけるレビュー支援サーバ２０は、ワークステーションなどによって構成されており、システム・コントローラとして機能するＭＰＵ、アプリケーション・ソフトウェアの実行空間を与えるためのＲＡＭなどのメモリ、ならびに処理を行うためのデータまたはプログラムなどを格納したＲＯＭ等のメモリ、ハードディスク装置や光ディスク装置などの外部記憶装置、およびＮＩＣを含むネットワーク・インターフェースなどの各種インタフェースを含んで構成されており、ネットワーク４０を介して、複数のクライアントＰＣ３０と通信可能に構成されている。なお、図１はあくまで例示であり、本実施形態においてネットワーク４０に接続されるクライアントＰＣの台数に制限を設けるものではない。

また、レビュー支援サーバ２０は、ＷＩＮＤＯＷＳ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、その他の適切なオペレーティング・システム（ＯＳ）の管理下で、Ｃ、Ｃ＋＋、ＶｉｓｕａｌＣ＋＋、ＶｉｓｕａｌＢａｓｉｃ、Ｊａｖａ（登録商標）などのオブジェクト指向のプログラミング言語により記述された各種アプリケーション・プログラムを実行することによって、後述する各機能手段を実現している。なお、本実施形態におけるクライアントＰＣ３０についても、同様のハードウェア構成を備えるものとして参照する。

図１に示す実施形態において、例えば、クライアントＰＣ３０のユーザがある文書を作成し、当該文書のレビューを希望する場合、本実施形態のレビュー作業支援システム１０においては、文書作成者のクライアントＰＣ３０のローカル・ハードディスクに保存された文書ファイルをネットワーク４０を介してレビュー支援サーバ２０にアップロードして、レビューを依頼する。

レビュー支援サーバ２０上で管理された文書ファイルについて、ネットワーク４０上に存在する他のクライアントＰＣ３０のユーザは、そのレビューに参加することができる。この場合、ユーザは、レビュー支援サーバ２０にアクセスして、レビュワーとしての参加を申請し、所望の文書ファイルを指定してダウンロードする。レビュワーは、ダウンロードした文書ファイルについて、ディスプレイ上で閲覧しながらファイルに直接コメントを添付したり、印刷出力した紙文書上にコメントを手書きしたりするなどして、レビュー作業を行なう。

図２は、本実施形態のレビュー支援システム１０を構成するクライアントＰＣ３０およびレビュー支援サーバ２０の機能ブロック図を併せて示す。

クライアントＰＣ３０は、文書レビュー依頼部１０１、レビュワーエントリー申請部１０２、イベント監視部１０３、イベント情報生成部１０４、イベント情報送信部１０５、メッセージ受信部１０６、メッセージ表示部１０７を含んで構成されており、クライアントＰＣ３０のユーザは、レビュー支援システム１０に対して、文書作成者の立場で参加することもでき、レビュワーの立場で参加することもできる。

一方、レビュー支援サーバは、文書レビュー依頼受付部２０１、レビュワーエントリー受付部２０２、レビュー文書送信部２０３、イベント情報受信部２０４、イベント情報管理部２０５、メッセージ生成部２０６、メッセージ送信部２０７を含んで構成されている。

図２を参照しながら、最初に、クライアントＰＣ３０のユーザがレビュー支援システム１０に対して、文書作成者の立場で参加する際の処理について以下説明する。

クライアントＰＣ３０のユーザは、文書のレビューを依頼するに際して、まず、レビュー支援サーバ２０にログインする。すなわち、所定のログイン画面に従って、登録されたユーザＩＤとパスワードを入力してレビュー支援サーバ２０に送信し、ユーザ認証を要求する。レビュー支援サーバ２０は、クライアントＰＣ３０側から送信されるユーザＩＤとパスワードをユーザ情報管理テーブル２０８内の認証情報と照合して、ユーザ認証を実行し、その結果をクライアントＰＣ３０に返す。

下記表１は、ユーザ情報管理テーブル２０８を例示する。表１に示すように、ユーザ情報管理テーブル２０８には、「ユーザＩＤ」および「ログイン・パスワード」の他、「ＩＰアドレス」、「メールアドレス」等、ユーザに対してデータを送信するために必要な送信先情報が格納されている。

クライアントＰＣ３０の文書レビュー依頼部１０１は、レビュー支援サーバ２０へのログインに成功すると、所定のユーザ・インターフェースを使用してユーザに対してローカル・ハードディスク１１０に保存される文書ファイルの一覧を提示し、ユーザが選択した文書ファイルをユーザＩＤと共にレビュー支援サーバ２０に送信してレビューを依頼する。ここでは、クライアントＰＣ３０のユーザＡのユーザＩＤを「ｕｓｅｒ−Ａ」とし、当該ユーザＡが「提案書.doc」というファイル名の文書ファイルのレビューを依頼したものとして以下の説明を行なう。

クライアントＰＣ３０から送信された文書ファイル「提案書.doc」を、レビュー支援サーバ２０の文書レビュー依頼受付部２０１が受信すると、文書ＩＤ発行部２０９が、受信した文書ファイル「提案書.doc」に対して一意の識別子（以下、文書ＩＤとして参照する）を発行して割り当てるとともに、文書レビュー依頼受付部２０１は、受信した文書ファイル「提案書.doc」をレビュー文書保管部２１０に保管する。その際、文書レビュー依頼受付部２０１は、保管した文書ファイルについて、レビュー文書管理テーブル２１１を更新する。下記表２は、レビュー文書管理テーブル２１１を例示する。

レビュー文書管理テーブル２１１は、「文書ＩＤ」フィールド、「ファイル名」フィールド、「ユーザ名」フィールド、「ユーザＩＤ」フィールド、および「ユーザ・ロール」フィールドを備えている。本実施形態における文書ＩＤは、汎用一意識別子(ＵＵＩＤ)を使用する。レビュー支援システム１０を利用する複数のクライアントＰＣ３０のユーザは、自身のローカル・ハードディスク１１０に保存する文書ファイルのファイル名を自由に決定することができるため、同一のファイル名を有する文書ファイルがレビュー文書保管部２１０に保管されることが想定される。そのような場合であっても、各文書ファイルに対して一意な識別子である文書ＩＤが割り当てられるため、当該文書ＩＤによって、各文書ファイルの実体データは適切に区別される。なお、実際のＵＵＩＤは、１６バイトの２進数値であるが、表２においては、説明の便宜上、「ＵＵＩＤ−＊」として表すものとする。なお、表２は、文書ファイル「提案書.doc」に対し文書ＩＤ「ＵＵＩＤ-２」が付与されたことを示している。

一方、レビュー文書管理テーブル２１１における「ユーザ・ロール」とは、文書ファイルに対するユーザの役割を表す情報として定義されるものであり、端的に言えば、そのユーザが当該文書ファイルの「文書作成者」であるのか、「レビュワー」であるのかを示す情報をいう。したがって、この場合、文書レビュー依頼受付部２０１は、「ユーザ・ロール」フィールドに、「文書作成者」を格納する。なお、上記表２は、文書ファイル「提案書.doc」がアップロードされる前に、ユーザＢを文書作成者とするファイル「貸借参照表.xls」に対し文書ＩＤ「ＵＵＩＤ-１」が付与されてレビュー文書保管部２１０に既に保管されていることを示している。

さらに、文書レビュー依頼受付部２０１は、文書ファイル「提案書.doc」に対して割り当てた文書ＩＤ「ＵＵＩＤ−２」をクライアントＰＣ３０の文書レビュー依頼部１０１に返す。レビュー支援サーバ２０から文書ＩＤ「ＵＵＩＤ−２」を受信したクライアントＰＣ３０の文書レビュー依頼部１０１は、自身がレビューを依頼した文書ファイル「提案書.doc」について、監視ファイル管理テーブル１０８を更新する。下記表３は、更新された監視ファイル管理テーブル１０８を示す。

監視ファイル管理テーブル１０８は、「ファイル名」フィールド、「文書ＩＤ」フィールド、および「ユーザ・ロール」フィールドを備えている。この場合、クライアントＰＣ３０の文書レビュー依頼部１０１は、監視ファイル管理テーブル１０８の「文書ＩＤ」フィールドには受信した「ＵＵＩＤ−２」を、「ユーザ・ロール」フィールドには「文書作成者」をそれぞれ格納する。以上、クライアントＰＣ３０のユーザＡがレビュー支援システム１０に対して、文書作成者の立場で参加する際の処理について説明してきたが、次に、再び図２を参照して、クライアントＰＣ３０のユーザＡがレビュー支援システム１０に対して、レビュワーの立場で参加する際の処理について以下説明する。

ユーザＡは、レビュワーとしてレビュー支援システム１０に参加するに際して、まず、レビュー支援サーバ２０に対して、上述したのと同様の手順を経てログインする。レビュー支援サーバ２０のレビュワーエントリー受付部２０２は、クライアントＰＣ３０のログインが成功すると、レビュー文書保管部２１０に保管されているレビュー文書ファイルの一覧を所定のユーザ・インターフェースを使用してクライアントＰＣ３０のユーザに提示する。クライアントＰＣ３０のユーザは、提示されたレビュー文書ファイルの一覧の中から、レビュー参加を申請したい文書ファイルを選択する。ここでは、ユーザＡが提示された一覧の中から「貸借参照表.xls」というファイル名の文書ファイルを選択したものとして以下の説明を行なう。

ユーザＡによって文書ファイル「貸借参照表.xls」が選択されると、レビュワーエントリー受付部２０２は、レビュー文書送信部２０３に対して、選択された文書ファイル「貸借参照表.xls」の送信を指示する。指示を受けたレビュー文書送信部２０３は、レビュー文書保管部２１０から指定された文書ファイル「貸借参照表.xls」を取得する。さらに、レビュー文書管理テーブル２１１を参照して「貸借参照表.xls」の文書ＩＤ「ＵＵＩＤ-２」を取得して、これを文書ファイル「貸借参照表.xls」とともにクライアントＰＣ３０のレビュワーエントリー申請部１０２に送信する。

加えて、レビュワーエントリー受付部２０２は、レビュー文書管理テーブル２１１を更新する。下記表４は、更新されたレビュー文書管理テーブル２１１を示す。下記表４に示すレビュー文書管理テーブル２１１は、ユーザＢを文書作成者とする文書ファイル「貸借参照表.xls」に対して、ユーザＡがレビュワーとして参加していることを示している。

一方、クライアントＰＣ３０のレビュワーエントリー申請部１０２は、レビュー支援サーバ２０から送信された文書ファイル「貸借参照表.xls」を受信すると、これをローカル・ハードディスク１１０に保存すると共に、監視ファイル管理テーブル１０８を更新する。下記表５は更新された監視ファイル管理テーブル１０８を例示する。具体的には、レビュワーエントリー申請部１０２は、下記表５に示されるように、「文書ＩＤ」フィールドに「ＵＵＩＤ−１」を、「ファイル名」フィールドに「貸借参照表.xls」を、「ユーザ・ロール」フィールドに「レビュワー」を、それぞれ格納する。下記表５に示す監視ファイル管理テーブル１０８は、クライアントＰＣ３０のローカル・ハードディスク１１０に、自身が作成し、レビューを依頼した文書ファイル「提案書.doc」と、レビュワーとして参加申請している文書ファイル「貸借参照表.xls」が保存されており、これらの文書ファイルを監視対象とすることを示している。

以上説明したように、本実施形態のレビュー支援システム１０によれば、ユーザは、自身の作成した文書ファイルをレビュー支援サーバ２０にアップロードしてレビューを依頼したり、他人の作成した文書ファイルをレビュー支援サーバ２０からダウンロードしてレビューしたりすることができる。しかしながら、レビュー依頼者は、レビュー文書をアップロードした後、文書レビュー会議の開催前に、その内容について修正したい場合がある。このような修正は認められることが好ましいが、当該修正について、レビュワー側に何も知らせないとすれば、レビュワーは、既に削除された内容について、そうとは知らずにコメントするなど、自身のレビュー作業が無駄になる虞がある。

この点について、本実施形態のレビュー支援システム１０によれば、レビュー依頼者のクライアントＰＣでレビュー対象文書ファイルについて各種操作がなされたことを、その都度、当該文書ファイルのレビュワーのクライアントＰＣに対して通知し、レビュワーに注意を喚起することができる。以下、クライアントＰＣ３０のユーザがローカル・ハードディスク１１０に保存される文書ファイルについて各種操作を行なった場合に実行される処理について再び図２を参照して説明する。

クライアントＰＣは、前提として、ローカル・ハードディスク１１０に保存された文書ファイルに対応する各種アプリケーションを実行するためのアプリケーション部１０９を備えている。通常、ユーザは、文書ファイルを指定した上で、アプリケーション部１０９に対して所望のプロセスの実行を命令する。アプリケーション部１０９は、当該命令に応答してローカル・ハードディスク１１０にアクセスし、指定された文書ファイルについて、閲覧、修正、編集、メール添付、印刷などの各種プロセスを実行する。

本実施形態においては、クライアントＰＣ３０のイベント監視部１０３は、レビュー作業に関係するファイルについて実行される各プロセスを監視し、指定されたイベントの発生を検出する。ここで、レビュー作業に関係するファイルとは、ローカル・ハードディスク１１０に記録された各種ファイルのうち、ユーザがレビュー支援サーバ２０に対してレビューを依頼した文書ファイル、ならびに、レビュワーとして参加を申請した文書ファイルである。また、本実施形態は、文書ファイルがハードディスクに記録される態様をもって説明するが、これに限定するものではなく、大容量ストレージであればよい。

本実施形態においては、クライアントＰＣ３０は、先に説明した監視ファイル管理テーブル１０８を参照することによって、監視対象となるファイルを特定するように構成されている。具体的には、イベント監視部１０３は、常に監視ファイル管理テーブル１０８を参照しており、監視ファイル管理テーブル１０８に格納されている「ファイル名」に基づいて、アプリケーション部１０９で実行される各プロセスを監視し、イベントの発生を検出するように構成されている。イベント監視部１０３に監視させるイベントについては、予め指定することができ、例えば、閲覧、修正、編集、印刷、メール添付などの処理に関連する各種イベントを監視対象として設定することができる。

イベント監視部１０３は、イベントの発生を検出すると、当該イベントの発生をレビュー支援サーバ２０に通知するようイベント情報送信部１０５に依頼する。依頼を受けたイベント情報送信部１０５は、発生したイベントに係る文書ファイルの「文書ＩＤ」、クライアントＰＣ３０の「ユーザＩＤ」、「ユーザ・ロール」、「イベントの内容」、およびイベントの「発生時刻」を含んで構成されるイベント情報を生成する。イベント情報送信部１０５は、生成した上記イベント情報をレビュー支援サーバ２０に対して速やかに送信する。

クライアントＰＣ３０から送信されたイベント情報は、レビュー支援サーバ２０のイベント情報受信部２０４によって受信される。イベント情報受信部２０４は、イベント情報を受信すると、当該イベント情報をイベント情報管理部２０５に送り、イベント情報管理テーブル２１２の更新を指示する。表６は、本実施形態におけるイベント情報管理テーブル２１２を例示する。イベント管理テーブル２１２は、「文書ＩＤ」フィールド、「ユーザＩＤ」フィールド、「ユーザ・ロール」フィールド、「イベントの内容」フィールド、および「発生時刻」フィールドを備えている。イベント情報管理部２０５は、クライアントＰＣ３０からイベント情報が送信される度に、当該イベント情報に含まれる「文書ＩＤ」、「ユーザＩＤ」、「ユーザ・ロール」、「イベントの内容」、「発生時刻」のデータをイベント情報管理テーブル２１２の各フィールドに格納して更新する。その結果、レビュー支援サーバ２０は、レビュー支援システム１０にログインしているクライアントＰＣのうち、どのクライアントＰＣにおいて、いつ、どのようなイベントが発生しているかについてリアルタイムで把握することができる。

加えて、イベント情報受信部２０４は、クライアントＰＣ３０からイベント情報を受信すると、メッセージ生成部２０６に対してこれを送り、メッセージの生成を指示する。メッセージ生成部２０６は、イベント情報の「ユーザ・ロール」フィールドを参照し、イベント情報の送信元ユーザの当該文書に対する役割が「文書作成者」であるか「レビュワー」であるかを判断する。

イベント情報の送信元ユーザの当該文書に対する役割が「文書作成者」である場合には、メッセージ生成部２０６は、イベント情報に含まれる「文書ＩＤ」に基づいて、レビュー文書管理テーブル２１１を検索し、当該「文書ＩＤ」に関連付けられている「レビュワー」の「ユーザＩＤ」を特定するとともに、イベント情報に含まれる「イベントの内容」に基づいて当該レビュワー用のメッセージを作成する。メッセージの作成が完了すると、メッセージ生成部２０６は、特定したレビュワーの「ユーザＩＤ」と作成したレビュワー用のメッセージをメッセージ送信部２０７に送り、クライアントＰＣに対するメッセージの送付を指示する。

一方、イベント情報の送信元が「レビュワー」である場合には、メッセージ生成部２０６は、イベント情報に含まれる「文書ＩＤ」に基づいて、レビュー文書管理テーブル２１１を検索し、当該「文書ＩＤ」に関連付けられている「文書作成者」の「ユーザＩＤ」を特定するとともに、イベント情報に含まれる「イベントの内容」に基づいて当該文書作成者用のメッセージを作成する。メッセージの作成が完了すると、メッセージ生成部２０６は、特定した文書作成者の「ユーザＩＤ」と作成した文書作成者用のメッセージをメッセージ送信部２０７に送り、クライアントＰＣに対するメッセージの送付を指示する。なお、上述した各メッセージ（レビュワー用／文書作成者用）の詳しい内容、および、その生成・送信のタイミング等については、後に詳細に説明する。

メッセージ生成部２０６からメッセージの送付依頼を受けたメッセージ送信部２０７は、送られてきた「ユーザＩＤ」に基づいてユーザ情報管理テーブル２０８を検索してメッセージの送付先情報を取得し、当該情報に基づいて所定のクライアントＰＣに対して作成したメッセージを送信する。

レビュー支援サーバ２０から送信されたメッセージは、クライアントＰＣ３０のメッセージ受信部１０６によって受信される。メッセージを受信したメッセージ受信部１０６は、メッセージ表示部１０７に対してメッセージの表示を指示し、メッセージ表示部１０７はこれを所定のユーザ・インタフェースを使用して表示する。

以上、本実施形態のレビュー支援システム１０が実行する処理について、クライアントＰＣ３０およびレビュー支援サーバ２０の機能ブロック図に基づいて説明してきたが、次に、図３〜図５に示すシーケンス図を参照しながら、本実施形態のレビュー支援システム１０が実行する処理を更に詳細に説明する。

まず、本実施形態のレビュー支援システム１０において、ユーザＡが文書レビュワーを公募し、これに対してユーザＢがレビュワーとして参加するまでに実行される処理について、図３に示すシーケンス図を参照しながら以下説明する。

ステップ１０１で、文書作成者であるユーザＡ（ユーザＩＤ「user-A」）は、クライアントＰＣ３０ａからレビュー支援サーバ２０にログインしたのち、ステップ１０２で、クライアントＰＣ３０ａは、ユーザＡが作成した文書ファイル（ファイル名「提案書.doc」）をレビュー支援サーバ２０にアップロードする。アップロードされた「提案書.doc」は、レビュー文書保管部２１０に保管される。

ステップ１０３で、レビュー支援サーバ２０は、クライアントＰＣ３０ａから送信された「提案書.doc」に対して文書ＩＤ「ＵＵＩＤ−２」を発行し、ステップ１０４で、発行した「ＵＵＩＤ−２」をクライアントＰＣ３０ａに送信する。

ステップ１０５で、レビュー支援サーバ２０から「ＵＵＩＤ−２」を受信したクライアントＰＣ３０ａは、監視ファイル管理テーブル１０８ａを更新する。下記表７は、更新後の監視ファイル管理テーブル１０８ａを示す。

さらに、ステップ１０６で、レビュー支援サーバ２０は、レビュー文書管理テーブル２１１を更新する。下記表８は、更新後のレビュー文書管理テーブル２１１を示す。上述した一連の処理が終了すると、本実施形態のレビュー支援システム１０は、ユーザＡの「提案書.doc」に対するレビューの公募がスタンバイされた状態になる。

レビュー支援サーバ２０上でユーザＡの「提案書.doc」に対するレビューの公募がスタンバイされた状態において、ステップ１０７で、レビュー支援システム１０にユーザ登録しているユーザＢ（ユーザＩＤ「user-Ｂ」）が、クライアントＰＣ３０ｂからレビュー支援サーバ２０にログインした後、レビュー文書保管部２１０に保管されている「提案書.doc」を指定し、レビュワーとしての参加を申請すると、ステップ１０８で、レビュー支援サーバ２０から文書ファイル「提案書.doc」と文書ＩＤ「ＵＵＩＤ−２」がクライアントＰＣ３０ｂダウンロードされる。

ステップ１０９で、クライアントＰＣ３０ｂは、レビュー支援サーバ２０から受信したファイル名「提案書.doc」および文書ＩＤ「ＵＵＩＤ−２」に基づいて監視ファイル管理テーブル１０８ｂを更新する。下記表９は、更新後の監視ファイル管理テーブル１０８ｂを示す。

一方、レビュー支援サーバ２０は、ステップ１１０で、レビュー文書管理テーブル２１１を更新する。下記表１０は、更新後のレビュー文書管理テーブル２１１を示す。表１０に示すレビュー文書管理テーブル２１１は、ユーザＡがレビュー公募した文書ファイル「提案書.doc」に対して、ユーザＢがレビュワーとして参加している状態を示している。

次に、本実施形態のレビュー支援システム１０において、文書作成者あるいはレビュワーが、それぞれのローカル・ハードディスクに保存されるレビュー文書に対して所定の操作を行なった場合に実行される処理について、図４に示すシーケンス図を参照しながら以下説明する。

最初に、文書作成者であるユーザＡがローカル・ハードディスク１１０ａに保存されるレビュー文書に対して所定の操作を行なった場合に実行される処理について説明する。ステップ２００で、ユーザＡの操作により、クライアントＰＣ３０ａのローカル・ハードディスクに保存された文書ファイル「提案書.doc」を修正する処理が実行される。

ステップ２０１で、「提案書.doc」に対する修正処理に関連するイベントを検出したことを受けて下記表１１に例示するイベント情報を生成し、ステップ２０２で、レビュー支援サーバ２０に対して生成したイベント情報を送信する。

ステップ２０３で、イベント情報を受信したレビュー支援サーバ２０は、イベント情報管理テーブル２１２を下記表１２に示すように更新する。

ステップ２０４で、レビュー支援サーバ２０は、受信したイベント情報の内容に基づいて、その発信元が「文書作成者」であることを判定し、この判定結果を受けて「レビュワー」向けのメッセージを生成する。生成するメッセージの具体的構成については、イベント情報内のテキストデータをそのまま提示する態様の他、種々の態様を想定することができる。例えば、イベント情報内のデータに基づいて、予め用意されたレビュワー用テンプレートを使用し、
｛ CAUTION!! Ａさんの「提案書.doc」は修正されました！ ｝
というような、ユーザが直感的に理解できるメッセージを生成することもできる。

ステップ２０５で、レビュー支援サーバ２０は、「提案書.doc」の文書ＩＤ「ＵＵＩＤ-２」に基づいて上記表１０に示したレビュー文書管理テーブル２１１を参照し、文書ＩＤ「ＵＵＩＤ-２」に対応付けられた「レビュワー」であるユーザＢを生成したメッセージの送信先として特定し、ユーザＢのユーザＩＤ「user-Ｂ」に基づいてユーザ情報管理テーブル２０８を検索してクライアントＰＣ３０ｂのＩＰアドレスやメールアドレス等の送付先情報を所得する。

ステップ２０６で、レビュー支援サーバ２０は、取得した送信先情報を使用して、生成したメッセージをクライアントＰＣ３０ｂに送信する。クライアントＰＣ３０ｂは、レビュー支援サーバ２０からメッセージを受信すると、ステップ２０７で、受信したメッセージの内容を所定のユーザ・インターフェースを使用して表示し、ユーザＢに注意喚起する。

レビュー支援サーバ２０からクライアントＰＣ３０ｂへのメッセージの送付は、メールによって行なうこともできる、この場合、メールを受信したクライアントＰＣ３０ｂは、メールチェック・モジュールが備えるポップアップウィンドウ等のユーザ・インターフェースを使用して、メッセージ・メールを受信した旨をユーザＢに表示したり、その内容（メッセージ）を表示したりすることができる。以上、文書作成者がレビュー文書に対して所定の操作を行なった場合に実行される処理について説明してきたが、次に、レビュワーがローカル・ハードディスクに保存されるレビュー文書に対して所定の操作を行なった場合に実行される処理について図４を再び参照して説明する。

ステップ２０８で、レビュワーであるユーザＢの操作により、クライアントＰＣ３０ｂのローカル・ハードディスクに保存された文書ファイル「提案書.doc」にコメントを添付する処理が実行されると、これに関連するイベントが検出される。イベントの検出を受けて、ステップ２０９で、下記表１３に示す内容のイベント情報を生成し、ステップ２１０で、レビュー支援サーバ２０に対して生成したイベント情報を送信する。

ステップ２１１で、イベント情報を受信したレビュー支援サーバ２０は、イベント情報管理テーブル２１２を下記表１４に示すように更新する。

ステップ２１２で、レビュー支援サーバ２０は、受信したイベント情報の内容に基づいて、その発信元が「レビュワー」であることを判定し、この判定結果を受けて「文書作成者」向けのメッセージを生成する。生成するメッセージの態様については、上述した「レビュワー」向けのメッセージと同様に、種々の態様を想定することができ、例えば、予め用意された文書作成者用テンプレートを使用して
｛ CAUTION!! 「提案書.doc」にＢさんがコメントしました！ ｝
というようなメッセージを生成したりすることもできる。

ステップ２１３で、レビュー支援サーバ２０は、「提案書.doc」の文書ＩＤ「ＵＵＩＤ-２」に基づいて上記表１０に示したレビュー文書管理テーブル２１１を参照し、文書ＩＤ「ＵＵＩＤ-２」に対応付けられた「文書作成者」であるユーザＡを生成したメッセージの送信先し、ユーザＡのユーザＩＤ「user-Ａ」に基づいてユーザ情報管理テーブル２０８を検索してクライアントＰＣ３０ａのＩＰアドレスやメールアドレス等の送付先情報を所得した後、ステップ２１４で、当該送信先情報を使用して、生成したメッセージをクライアントＰＣ３０ａに送信する。

クライアントＰＣ３０ａは、レビュー支援サーバ２０からメッセージを受信すると、ステップ２０７について上述したのと同様に、ステップ２１５で、受信したメッセージの内容をクライアントＰＣ３０ａの所定のユーザ・インターフェースを使用して表示し、ユーザＡに注意喚起する。メッセージの送信・表示については、上述したのと同様にメールを使用して実行することもできる。

以上、本実施形態のレビュー支援システム１０において、文書作成者あるいはレビュワーが、それぞれのローカル・ハードディスクに保存されるレビュー文書に対して所定の操作を行なった場合に実行される処理について説明してきたが、上述した説明においては、理解の用意のため、レビュー支援サーバ２０があるクライアントＰＣ３０からイベント情報の受信したことをトリガーとして、これに即時応答する形で、しかるべき送信先である他のクライアントＰＣ３０にメッセージを送信する態様について示したが、メッセージを送信するためのトリガーについては、適宜、設定することができる。

例えば、他の実施形態によれば、レビュー支援サーバ２０が所定の単位時間毎にメッセージを生成し、これを送信するように構成することもできる。その場合、メッセージ生成部２０６が所定の単位時間毎にイベント情報管理テーブル２１２を参照するように構成する。本実施形態におけるメッセージ生成部２０６は、イベント情報管理テーブル２１２の「発生時刻」フィールドに格納されている時刻情報を参照し、単位時間内に受信した複数のイベント情報を抽出した後、送信先毎（文書作成者／レビュワー）にこれら複数のイベント情報を整理する。すなわち、文書作成者が送信元のイベント情報については、これを対応するレビュワー毎に仕分けしたのち、仕分けされた情報に基づいて各レビュワー向けのメッセージを作成する。また、レビュワーが送信元のイベント情報については、これを対応する文書作成者毎に仕分けしたのち、仕分けされた情報に基づいて各文書作成者向けのメッセージを作成する。

さらに、他の実施形態によれば、レビュー支援サーバ２０が、レビュワー側で実行される所定のイベントをトリガーとして、メッセージを生成し、これをレビュワー側に返信するように構成することもできる。この場合の処理について、図５に示すシーケンス図を参照して以下説明する。

最初に、ステップ３００で、文書作成者であるユーザＡの操作により、クライアントＰＣ３０ａのローカル・ハードディスクに保存された文書ファイル「提案書.doc」の（００１０）段落を修正する処理が実行される。

ステップ３０１で、「提案書.doc」に対する修正処理に関連するイベントを検出したことを受けて下記表１５に示す内容のイベント情報を生成し、ステップ３０２で、レビュー支援サーバ２０に対して生成したイベント情報を送信する。

ステップ３０３で、イベント情報を受信したレビュー支援サーバ２０は、イベント情報管理テーブル２１２を下記表１６に示すように更新する。

上記更新と同時に、レビュー支援サーバ２０は、メッセージの送信先として想定される文書ファイル「提案書.doc」のレビュワーを送信元とするイベント情報の待機を開始する。具体的には、文書ＩＤ「ＵＵＩＤ-２」、ユーザ・ロール「レビュワー」を含むイベント情報を待機する。待機開始後、さらに、ステップ３０４で、ユーザＡの操作により、文書ファイル「提案書.doc」の（００５２）段落を修正する処理が実行されると、ステップ３０５で、下記表１７に示す内容のイベント情報を生成し、ステップ３０６で、レビュー支援サーバ２０に対して生成したイベント情報を送信する。

ステップ３０７で、イベント情報を受信したレビュー支援サーバ２０は、イベント情報管理テーブル２１２を下記表１８に示すように更新した後、引き続き、ユーザＢを送信元とするイベント情報の待機を継続する。

ステップ３０８で、レビュワーであるユーザＢの操作により、クライアントＰＣ３０ｂのローカル・ハードディスクに保存された文書ファイル「提案書.doc」の印刷命令が発行されると、これを受けてステップ３０９で、下記表１９に示す内容のイベント情報を生成し、ステップ３１０で、レビュー支援サーバ２０に対して生成したイベント情報を送信する。なお、本実施形態におけるクライアントＰＣ３０ｂは、印刷処理の実行ではなく、印刷命令の発行をその監視対象イベントとしていることに留意されたい。

上記イベント情報の送信と同時に、クライアントＰＣ３０ｂは、レビュー支援サーバ２０から返信されるメッセージを所定時間待機するように構成されており、タイムアウトするまでの間、アプリケーション部１０９ｂに対して印刷処理をペンディング状態にするよう指示する。

一方、クライアントＰＣ３０ｂからイベント情報を受信したレビュー支援サーバ２０は、ステップ３１１で、イベント情報管理テーブル２１２を更新する。下記表２０は、更新後のイベント情報管理テーブル２１２を示す。

レビュー支援サーバ２０は、文書ＩＤ「ＵＵＩＤ-２」、ユーザ・ロール「レビュワー」、イベント内容「印刷命令」を含むイベント情報を受信したことに応答して、ステップ３１２で、メッセージ生成部がレビュワー向けのメッセージを生成する。すなわち、本実施形態におけるレビュー支援サーバ２０は、クライアントＰＣ３０ｂ側の「印刷命令」イベントをトリガーとして、メッセージを生成・送信するように構成されている。具体的には、本実施形態におけるメッセージ生成部２０６は、イベント情報管理テーブル２１２の「発生時刻」フィールドに格納されている時刻情報を参照し、印刷命令の発生時刻（07/01/14：00）以前の発生時刻が記録された２つのイベント情報を抽出する。この場合、「（００１０）段落を修正」「（００５２）段落を修正」という２つのイベント内容が抽出される。メッセージ生成部は、当該イベント情報に基づいてイベント情報の送信元であるユーザＢ（ユーザＩＤ「user-Ｂ」/レビュワー）に向けて、例えば、
｛ CAUTION!! この文書は（００１０）段落および（００５２）段落が修正されています。このまま印刷しますか？ ｝
といったメッセージを生成し、ステップ３１３で、クライアントＰＣ３０ｂに送信する。

クライアントＰＣ３０ｂは、レビュー支援サーバ２０から上記メッセージを受信すると、ステップ２０７について上述したのと同様の方法で、ステップ３１４で、上記メッセージの内容をクライアントＰＣ３０ｂの所定のユーザ・インターフェースを使用して表示し、ユーザＢに注意喚起する。

なお、万が一、イベント情報管理テーブル２１２内に印刷命令の発生時刻以前の発生時刻に対応するイベント情報がない場合には、メッセージ生成部２０６は、メッセージを生成しない。その結果、クライアントＰＣ３０ｂ側では、タイムアウト期間が経過し、アプリケーション部１０９ｂのペンディング状態が解消されて印刷が実行される。

なお、イベント情報管理テーブル２１２に記録された各イベント情報のうち、メッセージの生成に使用したものについては、当該メッセージ送信完了と同時にこれを削除したり、あるいは、送信済みのフラグを立てたりすることによって、繰り返し同じ内容のメッセージが生成・送信されないようにする。

以上、レビュー支援サーバ２０が、レビュワー側で実行される印刷命令イベントをトリガーとして、レビュワー側にメッセージを返信して注意喚起する実施形態について説明したが、本実施形態におけるトリガー・イベントはこれに限定されるものではなく、メール添付等に関連するイベントをトリガー・イベントとして適宜設定することができる。

また、他の実施形態においては、図５について上述したのと同様の構成をもって、レビュー支援サーバ２０が、文書作成者側で実行される所定のイベントをトリガーとして、所定のメッセージを生成して文書作成者側に返信するように構成することもできる。この場合、例えば、文書作成者のクライアントＰＣの「文書を開く」というイベントをトリガーとして、その時点で当該文書に対して添付された全てのレビュワーからの全てのコメントを内容とするメッセージを生成し、当該クライアントＰＣに対してこのメッセージを返信するような実施形態を想定することができるであろう。

以上、本発明を上述した実施形態をもって説明してきたが、上述した実施形態の各機能は、アセンブリ言語、Ｃ、Ｖｉｓｕａｌ Ｃ、Ｃ＋＋、Ｖｉｓｕａｌ Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなど、レガシープログラミング言語やオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現することができ、装置可読な記録媒体に格納して頒布することができる。

また、本発明は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１０…文書レビュー作業支援システム、２０…レビュー支援サーバ、３０…パーソナル・コンピュータ、４０…ネットワーク、１０１…文書レビュー依頼部、１０２…レビュワーエントリー申請部、１０３…イベント監視部、１０４…イベント情報生成部、１０５…イベント情報送信部、１０６…メッセージ受信部、１０７…メッセージ表示部、１０８…監視ファイル管理テーブル、１０９…アプリケーション部、１１０…ローカル・ハードディスク、２０１…文書レビュー依頼受付部、２０２…レビュワーエントリー受付部、２０３…レビュー文書送信部、２０４…イベント情報受信部、２０５…イベント情報管理部、２０６…メッセージ生成部、２０７…メッセージ送信部、２０８…ユーザ情報管理テーブル、２０９…文書ＩＤ発行部、２１０…レビュー文書保管部、２１１…レビュー文書管理テーブル

特開２００８−２３４０７１号公報

Claims (10)

1. 複数のパーソナル・コンピュータと該複数のパーソナル・コンピュータにネットワーク接続されたファイルサーバとを含む文書レビュー作業支援システムであって、
   前記パーソナル・コンピュータは、
   ローカル・ストレージに記録されたレビュー対象の文書ファイルに関するイベントを監視するイベント監視部と、
   前記イベント監視部のイベントの検出に応答してイベント情報を生成するイベント情報生成部と、
   前記イベント情報を前記ファイルサーバに送信するイベント情報送信部と、
   前記ファイルサーバから送信されるメッセージを受信するメッセージ受信部と、
   受信した前記メッセージを表示するメッセージ表示部と
   を含み、
   前記ファイルサーバは、
   前記パーソナル・コンピュータから送信されるイベント情報を受信するイベント情報受信部と、
   受信した前記イベント情報を管理するイベント情報管理部と、
   前記イベント情報管理部が管理する前記イベント情報に基づいて、メッセージを生成するメッセージ生成部であって、受信した前記イベント情報の発信元ユーザの前記文書ファイルに対する役割を判断し、該ユーザの役割が文書作成者である場合には、該文書ファイルのレビュワー用のメッセージを生成し、該ユーザの役割がレビュワーである場合には、該文書ファイルの文書作成者用のメッセージを生成するメッセージ生成部と、
   前記レビュワー用のメッセージを前記文書ファイルの前記レビュワーのパーソナル・コンピュータに送信し、前記文書作成者用のメッセージを前記文書ファイルの文書作成者のパーソナル・コンピュータに送信するメッセージ送信部と
   を含む文書レビュー作業支援システム。
2. 前記ファイルサーバは、
   前記パーソナル・コンピュータからアップロードされた文書ファイルに対して一意識別子を割り当て、該一意識別子に関連付けて該文書ファイルを保管するとともに、該一意識別子を前記パーソナル・コンピュータに送信する、文書レビュー依頼受付部と、
   前記パーソナル・コンピュータからのレビュワーエントリー申請を受けて、文書ファイルを該文書ファイルの一意識別子とともに前記パーソナル・コンピュータに送信する、レビュワーエントリー受付部とを含み、
   前記パーソナル・コンピュータは、
   ローカル・ストレージに記録された文書ファイルを前記ファイルサーバにアップロードするとともに、前記ファイルサーバから送信される該文書ファイルの一意識別子を受信する、文書レビュー依頼部と、
   前記ファイルサーバから文書ファイルを該文書ファイルの一意識別子とともにダウンロードして、該文書ファイルに対するレビュワーエントリーを申請する、レビュワーエントリー申請部とを含む、
   請求項１に記載の文書レビュー作業支援システム。
3. 前記イベント監視部は、前記文書レビュー依頼部がアップロードした文書ファイル、ならびに、前記レビュワーエントリー申請部がダウンロードした文書ファイルに関するイベントを監視し、
   前記イベント情報は、少なくとも、発生したイベントに係る文書ファイルの前記一意識別子、送信元ユーザのユーザ識別子、送信元ユーザの該文書ファイルに対する役割、イベントの内容、および該イベントの発生時刻を含み、
   前記メッセージ生成部は、前記イベント情報に含まれるユーザの前記役割が文書作成者である場合には、前記イベント情報管理部が管理するイベント情報の中から、該イベント情報に含まれる前記一意識別子に関連付けられた文書作成者から送信されたイベント情報を抽出して該文書ファイルのレビュワー用のメッセージを生成し、ユーザの前記役割がレビュワーである場合には、前記イベント情報管理部が管理するイベント情報の中から、該イベント情報に含まれる前記一意識別子に関連付けられたレビュワーから送信されたイベント情報を抽出して該文書ファイルの文書作成者用のメッセージを生成する、
   請求項２に記載の文書レビュー作業支援システム。
4. 前記メッセージ生成部は、メッセージの送信先として想定されるパーソナル・コンピュータから受信した所定のイベント情報をトリガーとして、該パーソナル・コンピュータを送信先とするメッセージを生成する、請求項１〜３のいずれか１項に記載の文書レビュー作業支援システム。
5. ネットワークを介してファイルサーバに接続されるパーソナル・コンピュータであって、
   ローカル・ストレージに記録された文書ファイルを前記ファイルサーバにアップロードするとともに、前記ファイルサーバから該文書ファイルの一意識別子を受信する、文書レビュー依頼部と、
   前記ファイルサーバから文書ファイルを該文書ファイルの一意識別子とともにダウンロードして、該文書ファイルに対するレビュワーエントリーを申請する、レビュワーエントリー申請部と、
   ローカル・ストレージに記録された文書ファイルであって、前記文書レビュー依頼部がアップロードした文書ファイル、ならびに、前記レビュワーエントリー申請部がダウンロードした文書ファイルに関するイベントを監視するイベント監視部と、
   前記イベント監視部のイベントの検出に応答して、少なくとも、文書ファイルの前記一意識別子、送信元ユーザのユーザ識別子、送信元ユーザの該文書ファイルに対する役割、イベントの内容、および該イベントの発生時刻を含むイベント情報を生成するイベント情報生成部と、
   前記イベント情報を前記ファイルサーバに送信するイベント情報送信部と、
   前記ファイルサーバから送信されるメッセージを受信するメッセージ受信部と、
   受信した前記メッセージを表示するメッセージ表示部と
   を含む、
   パーソナル・コンピュータ。
6. ネットワークを介してファイルサーバに接続されるパーソナル・コンピュータのユーザの文書レビュー作業を支援する方法であって、該パーソナル・コンピュータが、
   ローカル・ストレージに記録された文書ファイルを前記ファイルサーバにアップロードするとともに、前記ファイルサーバから該文書ファイルの一意識別子を受信するステップと、
   前記ファイルサーバから文書ファイルを該文書ファイルの一意識別子とともにダウンロードして、該文書ファイルに対するレビュワーエントリーを申請するステップと、
   ローカル・ストレージに記録された文書ファイルであって、前記ファイルサーバにアップロードした前記文書ファイル、ならびに、前記ファイルサーバからダウンロードした前記文書ファイルに関するイベントを監視するステップと、
   前記イベントの検出に応答して、少なくとも、文書ファイルの前記一意識別子、送信元ユーザのユーザ識別子、送信元ユーザの該文書ファイルに対する役割、イベントの内容、および該イベントの発生時刻を含むイベント情報を生成するステップと、
   前記イベント情報を前記ファイルサーバに送信するステップと、
   前記ファイルサーバから送信されるメッセージを受信するステップと、
   受信した前記メッセージを表示するステップと、
   を実行する方法。
7. 請求項６に記載の方法の各ステップを前記パーソナル・コンピュータに実行させるための、コンピュータ実行可能なプログラム。
8. 複数のパーソナル・コンピュータにネットワーク接続されたファイルサーバであって、
   前記パーソナル・コンピュータからアップロードされた文書ファイルに対して一意識別子を割り当て、該一意識別子に関連付けて該文書ファイルを保管するとともに、該一意識別子を前記パーソナル・コンピュータに送信する、文書レビュー依頼受付部と、
   前記パーソナル・コンピュータからのレビュワーエントリー申請を受けて、文書ファイルを該文書ファイルの一意識別子とともに前記パーソナル・コンピュータに送信する、レビュワーエントリー受付部と、
   前記パーソナル・コンピュータからのイベント情報を受信するイベント情報受信部と、
   受信した前記イベント情報を管理するイベント情報管理部と、
   前記イベント情報管理部が管理する前記イベント情報に基づいて、メッセージを生成するメッセージ生成部であって、受信した前記イベント情報の発信元ユーザの前記文書ファイルに対する役割を判断し、該ユーザの役割が文書作成者である場合には、該文書ファイルのレビュワー用のメッセージを生成し、該ユーザの役割がレビュワーである場合には、該文書ファイルの文書作成者用のメッセージを生成するメッセージ生成部と、
   前記レビュワー用のメッセージを前記文書ファイルの前記レビュワーのパーソナル・コンピュータに送信し、前記文書作成者用のメッセージを前記文書ファイルの文書作成者のパーソナル・コンピュータに送信するメッセージ送信部とを含む、
   ファイルサーバ。
9. 複数のパーソナル・コンピュータにネットワーク接続されたファイルサーバが該パーソナル・コンピュータのユーザの文書レビュー作業を支援する方法であって、該ファイルサーバが、
   前記パーソナル・コンピュータからアップロードされた文書ファイルに対して一意識別子を割り当て、該一意識別子に関連付けて該文書ファイルを保管するとともに、該一意識別子を前記パーソナル・コンピュータに送信するステップと、
   前記パーソナル・コンピュータからのレビュワーエントリー申請を受けて、文書ファイルを該文書ファイルの一意識別子とともに前記パーソナル・コンピュータに送信するステップと、
   前記パーソナル・コンピュータからのイベント情報を受信するステップと、
   受信した前記イベント情報を管理するステップと、
   管理された前記イベント情報に基づいて、メッセージを生成するステップであって、受信した前記イベント情報の発信元ユーザの前記文書ファイルに対する役割を判断し、該ユーザの役割が文書作成者である場合には、該文書ファイルのレビュワー用のメッセージを生成し、該ユーザの役割がレビュワーである場合には、該文書ファイルの文書作成者用のメッセージを生成するステップと、
   前記レビュワー用のメッセージを前記文書ファイルの前記レビュワーのパーソナル・コンピュータに送信し、前記文書作成者用のメッセージを前記文書ファイルの文書作成者のパーソナル・コンピュータに送信するステップと、
   を実行する方法。
10. 請求項９に記載の方法の各ステップを前記ファイルサーバに実行させるための、コンピュータ実行可能なプログラム。