JP2003085345A - 意思決定支援装置、意思決定支援方法、記憶媒体及びコンピュータプログラム - Google Patents

Abstract

(57)【要約】 【課題】 同一文書に複数のユーザが同時にアクセスし
ている場合に、競合文書となることの報知を早期に行
い、競合文書の発生を事前に防いで無駄な入力作業を防
止できるようにする。 【解決手段】 サーバから呼び出した文書に対して意思
決定の入力要求があった場合（ステップＳ３２）、別の
クライアントによる意思決定の結果入力に関する優先処
理の有無を判定し（ステップＳ３４、３７、４０）、優
先処理がないと判定した場合には、意思決定の結果入力
を実行可能として入力された意思決定の結果をサーバに
送信するのに対して（ステップＳ４３）、優先処理があ
ると判定した場合には、意思決定の結果入力を実行可能
とするに先立って、意思決定の入力要求に応じることが
できないことを報知する（ステップＳ３５、３８、４
１）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、意思決定支援装
置、意思決定支援方法、記憶媒体及びコンピュータプロ
グラムに関する。

【０００２】

【従来の技術】近年、クライアント・サーバ・システム
を前提とする情報技術を利用して、意思決定支援のため
の文書回覧システム（グループウエア）が実用化されて
いる。企業内などで用いられているそのような文書回覧
システムの一例としては、クライアント装置において電
子化された文書を作成し、それをサーバ装置に用意され
たデータベースに送信して記憶しておき、その文書に対
してクライアント装置からアクセスするユーザ、例えば
上司の決裁（検印、審査、承認、コメント付与）などを
仰ぐ、というものがある。このような文書回覧システム
では、上司は自らのクライアント装置によってデータベ
ースにアクセスして部下が作成した文書を閲覧し、決裁
などを行う。この意味で、上司が扱うクライアント装置
は、意思決定支援装置として機能することになる。ま
た、文書を作成した部下も、その者のクライアント装置
によってデータベースにアクセスし、決裁後の文書を閲
覧することができる。

【０００３】このような従来の文書回覧システムでは、
文書の回覧時において、例えば決裁処理である意思決定
処理の競合が問題となる。つまり、上述した例でいう
と、ある文書に対して複数人の上司による検印、審査、
承認、コメント付与等の同時回覧が必要であるとする
と、その文書に対して、決裁を実行すべき複数人の上司
が同時にアクセスする場合がある。この場合、ある上司
の決裁処理が完了して文書が更新された後に他の上司が
その文書にアクセスする場合には、そのアクセスした文
書は更新済みの文書であるので何ら問題は生じない。こ
れに対して、同一文書が複数の上司によって同時にアク
セスされて閲覧されている間に、一人の上司が決裁処理
を完了して文書が更新された場合、別の上司が更に決裁
処理を完了して文書が更新されると、最初になされた決
裁処理が上書きされてしまい、これらの文書は競合状態
になってしまうという問題が生じる。

【０００４】そこで、従来、同一文書が複数のユーザに
よって同時にアクセスされて閲覧されている間に一人の
ユーザが決裁処理を完了して文書が更新された場合に
は、同一文書に対する他のユーザによる決裁処理を禁止
するという排他的制御が必要となる。このような排他的
制御として、従来の代表的なグループウエアでは、文書
更新処理を禁止すべき文書更新要求があった場合には、
例えば、「編集中の文書のコピーが保存されています。
競合文書として保存しますか。」というようなメッセー
ジをクライアント装置において表示させ、文書更新要求
に応じない、ということが実行されている。この場合、
「…保存しますか。」という問いに対して「はい」が選
択されると、競合文書として保存し、文書更新が可能に
なった時点での利用に供することができるようになって
いる。

【０００５】

【発明が解決しようとする課題】従来の文書回覧システ
ムでは、ある文書に対して検印、審査、承認、コメント
付与などの入力を行った後に文書更新要求をした場合
に、初めて競合文書があるかどうかを判定し、競合文書
があることのメッセージをクライアント装置に送信して
いる。このため、クライアント装置を利用するユーザ
は、せっかく検印、審査、承認、コメント付与などの入
力を実行しても、サーバ装置が文書更新要求に応じない
場合には、その入力済み文書を競合文書として保存する
か、あるいは、競合文書として保存せずに入力結果を全
く無駄にするしかない。この場合、競合文書として保存
したとしても、これを文書更新が可能になった時点で利
用するには、競合文書を利用するための付加的な処理を
しなければならない。このようなことから、極めて操作
性が悪いという問題がある。

【０００６】本発明の目的は、同一文書に複数のユーザ
が同時にアクセスしている場合に、競合文書となること
の報知を早期に行い、また競合文書の発生を事前に防い
で無駄な入力作業を防止できるようにすることである。

【０００７】

【課題を解決するための手段】請求項１記載の意思決定
支援装置の発明は、意思決定の入力要求を行うことがで
きる電子化された文書をサーバから呼び出し記憶領域に
記憶する手段と、意思決定の入力要求が入力可能なよう
に前記文書を表示装置に表示させる手段と、意思決定の
入力要求があった場合、別のクライアントによる意思決
定の結果入力に関する優先処理の有無を判定する手段
と、前記優先処理がないと判定した場合、意思決定の結
果入力を実行可能とし、入力された意思決定の結果を前
記サーバに送信する処理を実行する手段と、前記優先処
理があると判定した場合、意思決定の結果入力を実行可
能とするに先立って、意思決定の入力要求に応じること
ができないことを報知する手段と、を具備する。

【０００８】したがって、意思決定の入力要求に応じる
ことができないことの報知によって、競合文書の発生を
事前に防いで無駄な入力作業が行われることが防止され
る。

【０００９】請求項２記載の発明は、請求項１記載の意
思決定支援装置において、前記優先処理の有無を判定す
る処理は、その優先処理の有無を前記サーバに問い合わ
せることによって実行される。

【００１０】したがって、サーバに対する問い合わせに
よって優先処理があるかどうかの情報が得られる。

【００１１】請求項３記載の発明は、請求項２記載の意
思決定支援装置において、前記サーバから、同一の前記
文書について別のクライアントが意思決定を入力中であ
ることを示すステータスを受信した場合、前記優先処理
があると判定する。

【００１２】同一の文書について別のクライアントが意
思決定を入力中であることを示すステータスは、サーバ
から容易に得ることができるため、このようなステータ
スをサーバから受信することで、優先処理があると判定
することが可能である。

【００１３】請求項４記載の発明は、請求項３記載の意
思決定支援装置において、同一の前記文書について別の
クライアントが意思決定を入力中であることを示すステ
ータスは、その文書についての編集者に関する情報であ
る。

【００１４】つまり、請求項３記載の発明における同一
の文書について別のクライアントが意思決定を入力中で
あることを示すステータスとして、請求項４記載の発明
では、その文書についての編集者に関する情報を用い
る。その文書についての編集者に関する情報、例えば、
現在編集しているユーザの存在を示唆する情報が得られ
れば、優先処理の有無が容易に判定される。

【００１５】請求項５記載の発明は、請求項２記載の意
思決定支援装置において、前記サーバから、同一の前記
文書について別のクライアントによって意思決定が入力
済みあることを示すステータスを受信した場合、前記優
先処理があると判定する。

【００１６】同一の前記文書について別のクライアント
が意思決定を入力済みであることを示すステータスは、
サーバから容易に得ることができるため、このようなス
テータスをサーバから受信することで、優先処理がある
と判定することが可能である。

【００１７】請求項６記載の発明は、請求項５記載の意
思決定支援装置において、同一の前記文書について別の
クライアントによって意思決定が入力済みあることを示
すステータスは、その文書の更新日時であり、その更新
日時が、予め前記記憶領域に記憶させておいた前記サー
バからの前記文書の呼び出し日時と相違することをもっ
て前記優先処理があると判定する。

【００１８】サーバにおいて、文書の更新がなされると
その更新日付を記録保存する処理が実行される仕組みを
構築しておけば、その更新日付を問い合わせて得ること
ができる。また、サーバからの文書の呼び出し日時を予
め記憶領域に記憶させておけば、文書の呼び出し日時を
認識することができる。そこで、記憶領域に記憶する文
書の呼び出し日時とサーバから受信した文書の更新日時
とが相違すれば、その文書について別のクライアントに
よって意思決定が入力済みであることが判明するため、
優先処理の有無が容易に判定される。

【００１９】請求項７記載の発明は、請求項１記載の意
思決定支援装置において、前記文書を前記サーバから呼
び出すに際して、前記優先処理に関するデータを前記文
書と共に受信して前記記憶領域に記憶させておき、前記
優先処理の有無を判定する処理は、前記記憶領域に記憶
させた前記優先処理に関するデータを参照して実行す
る。

【００２０】したがって、記憶領域の記憶内容を参照す
ることによって優先処理があるかどうかの情報が得られ
る。

【００２１】請求項８記載の意思決定支援方法の発明
は、プロセッサによって、意思決定の入力要求が入力可
能な電子化された文書をサーバから呼び出すステップ
と、前記プロセッサによって、意思決定の入力要求が入
力可能なように前記文書を表示装置に表示させるステッ
プと、前記プロセッサが、意思決定の入力要求があった
と判断した場合、意思決定の結果入力に関する優先処理
の有無を判定し、その判定結果に基づいて意思決定の入
力要求に応じることができるかどうかを判断するステッ
プと、前記プロセッサが、意思決定の入力要求に応じる
ことができると判断した場合、意思決定の結果入力を実
行可能とし、入力された意思決定の結果を前記サーバに
送信する処理を実行するステップと、前記プロセッサ
が、意思決定の入力要求に応じることができないと判断
した場合、意思決定の結果入力を実行可能とするに先立
って、意思決定の入力要求に応じることができないこと
を報知するステップと、を具備する。

【００２２】したがって、意思決定の入力要求に応じる
ことができないことの報知によって、競合文書の発生を
事前に防いで無駄な入力作業が行われることが防止され
る。

【００２３】請求項９記載の記憶媒体の発明は、コンピ
ュータにインストールされ、このコンピュータに、意思
決定の入力要求が入力可能な電子化された文書をサーバ
から呼び出す手段と、意思決定の入力要求が入力可能な
ように前記文書を表示装置に表示させる手段と、意思決
定の入力要求があった場合、意思決定の結果入力に関す
る優先処理の有無を判定し、その判定結果に基づいて意
思決定の入力要求に応じることができるかどうかを判断
する手段と、意思決定の入力要求に応じることができる
と判断した場合、意思決定の結果入力を実行可能とし、
入力された意思決定の結果を前記サーバに送信する処理
を実行する手段と、意思決定の入力要求に応じることが
できないと判断した場合、意思決定の結果入力を実行可
能とするに先立って、意思決定の入力要求に応じること
ができないことを報知する手段と、を実行させるコンピ
ュータ読み取り可能なプログラムを記憶する。

【００２４】したがって、このプログラムがコンピュー
タにインストールされてそのプログラムに従いコンピュ
ータが動作すると、意思決定の入力要求に応じることが
できないことの報知によって、競合文書の発生を事前に
防いで無駄な入力作業が行われることが防止される。

【００２５】請求項１０記載のコンピュータ読み取り可
能なプログラムの発明は、コンピュータにインストール
され、このコンピュータに、意思決定の入力要求が入力
可能な電子化された文書をサーバから呼び出す手段と、
意思決定の入力要求が入力可能なように前記文書を表示
装置に表示させる手段と、意思決定の入力要求があった
場合、意思決定の結果入力に関する優先処理の有無を判
定し、その判定結果に基づいて意思決定の入力要求に応
じることができるかどうかを判断する手段と、意思決定
の入力要求に応じることができると判断した場合、意思
決定の結果入力を実行可能とし、入力された意思決定の
結果を前記サーバに送信する処理を実行する手段と、意
思決定の入力要求に応じることができないと判断した場
合、意思決定の結果入力を実行可能とするに先立って、
意思決定の入力要求に応じることができないことを報知
する手段と、を実行させる。

【００２６】したがって、このプログラムがコンピュー
タにインストールされてそのプログラムに従いコンピュ
ータが動作すると、意思決定の入力要求に応じることが
できないことの報知によって、競合文書の発生を事前に
防いで無駄な入力作業が行われることが防止される。

【００２７】

【発明の実施の形態】〔システム構成〕図１は、この発
明の一実施の形態である文書回覧システムのシステム構
成を示すブロック図である。図１に示すように、この文
書回覧システム１は、ネットワーク２で互いに接続され
た複数のサーバ３，３，…と、各サーバ３にそれぞれ接
続されているクライアント４，４，…とで構成されるク
ライアント・サーバ・システムである。この文書回覧シ
ステム１は特定の組織（この例では企業）内に設置さ
れ、各サーバ３は例えば各事業部単位に設けられている
（複数の事業部で１台のサーバ３を共有するようにして
もよい）。

【００２８】図２は、サーバ３のシステム構成を示すブ
ロック図である。図２に示すように、サーバ３は、ＣＰ
Ｕ１１と、ＢＩＯＳなどを格納した読み出し専用のメモ
リであるＲＯＭ１２と、各種データを書き換え可能に記
憶するメモリでＣＰＵ１１の作業エリアとなるＲＡＭ１
３とが、バス１４で接続されている。バス１４には、他
のクライアント４や他のサーバ３などと通信を行うため
の通信制御装置１５と、各種プログラムが格納され、後
述のデータベース２１が構築される外部記憶装置である
ＨＤＤ１６と、ＣＤ−ＲＯＭドライブ１７と、ＣＲＴ，
ＬＣＤなどのディスプレイ１８と、マウスおよびキーボ
ードなどの入力装置１９とが、図示しないインターフェ
イスや制御装置を介して接続されている。

【００２９】ＣＤ−ＲＯＭドライブ１７によって読み取
られるＣＤ−ＲＯＭ２０は、各種のプログラムを記憶す
ることができる。本実施の形態では、クライアント・サ
ーバ・システムを文書回覧システム１として機能させる
プログラムがＣＤ−ＲＯＭ２０に記憶され、これがコン
ピュータである各サーバ３にインストールされることに
よってクライアント・サーバ・システムが文書回覧シス
テム１として機能する。

【００３０】図３は、各サーバ３にそれぞれ設けられた
データベース２１，２１，…間の関係を説明する機能ブ
ロック図である。図３に示すように、このデータベース
２１は、事業部決定依頼書データベース２２（以下、決
定依頼書を“Ｄ／Ｆ”、データベースを“ＤＢ”とい
う）と、標準文書ＤＢ２３の２つのＤＢを含んでいる。

【００３１】事業部Ｄ／ＦＤＢ２２は、文書ＤＢとして
機能するもので、クライアント４側の操作で作成したＤ
／Ｆは、当該クライアント４が接続されているサーバ３
内の事業部Ｄ／ＦＤＢ２２に格納される。Ｄ／Ｆは、電
子化された文書で、その作成者が上司など他の担当者
に、当該文書の内容に対する承認、審査などの意思表示
を受けるために作成する文書である。また、事業部Ｄ／
ＦＤＢ２２は、他のサーバ３から送信されてきたＤ／Ｆ
などの文書を受信するメール受信ＤＢとしても機能す
る。

【００３２】標準文書ＤＢ２３は、Ｄ／Ｆを作成するた
めの各種の文書雛型（テンプレート）である標準文書が
格納され、文書雛型データベースとして機能する。標準
文書ＤＢ２３は、それが設けられている同一のサーバ３
の事業部Ｄ／ＦＤＢ２２とペアで運用される。

【００３３】複数のサーバ３のうち１台は、この文書回
覧システム１が設置されている企業の本部に設けられ、
その事業部Ｄ／ＦＤＢ２２は、トップＤ／ＦＤＢ２４と
して機能する。トップＤ／ＦＤＢ２４は、この企業で所
定以上の地位にある者、すなわち、この例では、各事業
部の部長より上の地位にある者（社長など）から決裁な
どの意思表示を受けようとするＤ／Ｆを、各事業部のサ
ーバ３から受信するための専用のメール受信ＤＢとなる
ものである。

【００３４】複数のサーバ３のうち１台には、宛先リス
トＤＢ２５が設けられている（図１も参照）。この宛先
リストＤＢ２５は、Ｄ／Ｆをネットワーク２内で送信す
る際の宛先情報を蓄積したＤＢである。すなわち、宛先
リストＤＢ２５には、各サーバ３が担当している事業部
の名称、各サーバ３のメール受信データベースとなる事
業部Ｄ／ＦＤＢ２２の名称、Ｄ／Ｆ管理者（各事業部Ｄ
／ＦＤＢ２２においてＤ／Ｆを管理する者）などの情報
が格納されている。この宛先リストＤＢ２５は、各サー
バ３で利用することができる。

【００３５】各サーバ３には、そのサーバ３が管理する
事業部または本部内で、Ｄ／Ｆに審査、承認を与えるこ
ととなる者の氏名、所属、電子メールアドレスなどを登
録した審査承認テーブルが用意されている。

【００３６】各サーバ３の事業部Ｄ／ＦＤＢ２２、トッ
プＤ／ＦＤＢ２４には、初期設定として、所定の登録情
報を登録することができる。すなわち、各サーバ３が担
当している事業部などの名称、Ｄ／Ｆ管理者、メール受
信ＤＢとなる事業部Ｄ／ＦＤＢ２２やトップＤ／ＦＤＢ
２４の名称などの情報である。

【００３７】図４は、事業部Ｄ／ＦＤＢ２２に格納され
た電子化された文書であるＤ／Ｆと、このＤ／Ｆの属性
情報とを示す模式図である。図４に示すように、Ｄ／Ｆ
には、文書であるＤ／Ｆを特定する文書Ｎｏ．３１、そ
の文書の最終更新日時３２、その文書の編集者３３、そ
のＤ／Ｆの書込み権限者３４及び未審査の書込み権限者
３５のフィールドが設定されおり、各フィールドには該
当する情報が記憶され、Ｄ／Ｆとリンク付けられてい
る。

【００３８】文書Ｎｏ．３１は、その文書を特定するた
めのＩＤとして機能するもので、各Ｄ／Ｆについて、そ
の作成時に自動付番や手入力付番等の手法で付番され
る。最終更新日時３２は、そのＤ／Ｆが更新される毎に
更新される日時情報であり、各サーバ３又はクライアン
ト４の計時機能に基づいて計時された日時が設定され
る。編集者３３は、現在編集中の編集者がいるかどう
か、それが誰なのか、あるいは、現在編集中の編集者が
いない場合には最終編集者が誰なのかというような情報
を設定している。この場合の編集者は、そのＤ／Ｂに対
して編集権限を持つ者、つまり、Ｄ／Ｆに審査、承認を
与えることとなる者であり、その者は各サーバ３が備え
る審査承認テーブルと同一の規則に従い特定される。そ
の文書の書込み権限者３４は、各Ｄ／Ｆについて設定さ
れる書込み権限者、つまり、Ｄ／Ｆに審査、承認を与え
ることとなる者についての情報である。そして、このよ
うな書込み権限者３４によって特定されるユーザは、そ
のＤ／Ｆに対して次々と審査し、承認を与えることにな
るが、この場合、書込み権限者３４によって特定される
ユーザのうち、どのユーザが審査及び承認を終了したか
は、サーバ３において容易に判定可能である。そこで、
未審査の書込み権限者３５には、書込み権限者３４によ
って特定されるユーザのうち、未だ審査を終了していな
いユーザについての情報を記憶する。

【００３９】このような文書Ｎｏ．３１等のような各Ｄ
／Ｆの属性情報は、各種の手法によってＤ／Ｆとリンク
させることが可能である。例えば、属性情報をＤ／Ｆの
プロパティーとして同一文書として管理したり、属性情
報をＤ／Ｆとは別個に作成してこれをアンカーによって
Ｄ／Ｆとリンク付けたり、その他、公知のあらゆる手法
によってＤ／Ｆとその属性情報とのリンク付けが可能で
ある。

【００４０】図５は、クライアント４のシステム構成を
示すブロック図である。図５に示すように、クライアン
ト４は、ＣＰＵ４１と、ＢＩＯＳなどを格納した読み出
し専用のメモリであるＲＯＭ４２と、各種データを書き
換え可能に記憶するメモリ（記憶領域）であってＣＰＵ
４１の作業エリアとなるＲＡＭ４３とが、バス４４で接
続されている。バス４４には、他のクライアント４や他
のサーバ３などと通信を行うための通信制御装置４５
と、各種プログラム等を格納するＨＤＤ４６と、ＣＤ−
ＲＯＭドライブ４７と、ＣＲＴ，ＬＣＤなどの表示装置
としてのディスプレイ４８と、マウスおよびキーボード
などの入力装置４９とが、図示しないインターフェイス
や制御装置を介して接続されている。

【００４１】ＣＤ−ＲＯＭドライブ４７によって読み取
られるＣＤ−ＲＯＭ５０は、各種のプログラムを記憶す
ることができる。本実施の形態では、クライアント・サ
ーバ・システムを文書回覧システム１として機能させ、
自らをそのような文書回覧システム１の一部である意思
決定支援装置として機能させるプログラムがＣＤ−ＲＯ
Ｍ５０に記憶され、これがコンピュータである各クライ
アント４にインストールされることによってクライアン
ト・サーバ・システムが文書回覧システム１として機能
し、自らが意思決定支援装置として機能する。

【００４２】図６は、サーバ３の事業部Ｄ／ＦＤＢ２２
からクライアント４に呼び出した電子化された文書であ
るＤ／Ｆと、このＤ／Ｆにリンク付けられる情報とを示
す模式図である。図６に示すように、Ｄ／Ｆには、文書
であるＤ／Ｆを特定する文書Ｎｏ．６１、その文書の呼
び出し日時６２及びその文書の編集者６３のフィールド
が設定されおり、各フィールドには該当する情報が記憶
され、Ｄ／Ｆとリンク付けられている。

【００４３】文書Ｎｏ．６１は、サーバ３の事業部Ｄ／
ＦＤＢ２２に格納されているそのＤ／Ｆの属性情報とし
ての文書Ｎｏ．３１と同一の番号情報である。つまり、
そのＤ／ＦのＩＤとして機能する番号情報である。呼び
出し日時６２は、そのＤ／Ｆがサーバ３の事業部Ｄ／Ｆ
ＤＢ２２からクライアント４に呼び出された時点で設定
される日時情報であり、そのクライアント４の計時機能
に基づいて計時された日時が設定される。編集者６３
は、サーバ３の事業部Ｄ／ＦＤＢ２２に格納されている
そのＤ／Ｆの属性情報としての編集者３３と同一の情報
であり、このＤ／Ｆの属性情報としての編集者３３は、
そのＤ／Ｆがクライアント４に呼び出された時点での編
集者３３に関する情報である。

【００４４】〔Ｄ／Ｆを作成後の処理〕次に、Ｄ／Ｆを
作成して、このＤ／Ｆに対して審査、承認を受けて、Ｄ
／Ｆの起案者の元に戻ってくるまでの具体的な処理につ
いて説明する。

【００４５】（Ａ）他の事業部にＤ／Ｆの審査、承認を
求める場合の処理手順 まず、社員が他の事業部にＤ／Ｆの審査、承認を求める
場合の処理手順について、図７のフローチャートを参照
して説明する。ここで、図７に示すフローチャートは、
クライアント４のＣＰＵ４１が文書回覧システム構築用
のプログラムに従い実行する処理と、サーバ３のＣＰＵ
１１が文書回覧システム構築用のプログラムに従い実行
する処理とを区別することなく記述している。その意味
で、図７に示すフローチャートは、ＣＰＵ４１やＣＰＵ
１１として実現されているプロセッサにおけるプロセス
処理を記述するわけではなく、文書回覧システム１の全
体処理を概略的に記述していることになる。

【００４６】社員が自己の所属する事業部のサーバ３に
用意されているクライアント４で、このサーバ３の事業
部Ｄ／ＦＤＢ２２を開くと、所定の初期画面がクライア
ント４のディスプレイ４８に表示される。この初期画面
上のボタンをクリックすることにより、前記の初期設定
や、Ｄ／Ｆの作成など各種の作業を行うことができる。

【００４７】この初期画面でＤ／Ｆ作成ボタンをクリッ
クすると、Ｄ／Ｆの作成が可能となる（ステップＳ
１）。この場合に、図８に例示するような画面をクライ
アント４のディスプレイ４８に表示することが可能であ
る。図８の画面は、アクセスしている事業部Ｄ／ＦＤＢ
２２とペアで運用されている標準文書ＤＢ２３に格納さ
れている標準文書のタイトルを列挙して表示するもので
ある。図８の例では、“一般費用の支払”、“固定資産
の取得”、…のように、案件ごとの標準文書のタイトル
が列挙されている（なお、図８の例は、ＣＤ−ＲＯＭ２
０からインストールした各種プログラムがWindows上で
動作するアプリケーションソフトである場合の例で示し
ている（“Windows”は、マイクロソフト社の商標であ
る））。これにより、タイトル表示手段、タイトル表示
工程を実現している。各標準文書のタイトルの冒頭には
案件ボタン７１が表示され、その案件ボタン７１をクリ
ックすることにより、そのタイトルの標準文書を選択す
ることができる。この選択がなされると、選択された標
準文書を標準文書ＤＢ２３から読み込み、Ｄ／Ｆの作成
に用いる文書雛型として設定し、その標準文書をディス
プレイに表示する。

【００４８】Ｄ／Ｆの作成は、選択した文書雛型にタイ
トルや本文などを書き込みすることで行われる。このよ
うにして作成したＤ／Ｆには、前記のように初期設定し
た事業部Ｄ／ＦＤＢ２２内の登録情報が自動書き込みさ
れる。

【００４９】以上のようにして、Ｄ／Ｆを作成すると
（ステップＳ１）、次に、検印者の設定を行う（ステッ
プＳ２）。すなわち、作成したＤ／Ｆに対して電子的に
検印をもらうべき人物を設定する。これは、事業部Ｄ／
ＦＤＢ２２に予め用意されている検印者テーブルに登録
されているので、その中から選択して設定する。

【００５０】検印者の設定（ステップＳ２）を行った後
に、作成したＤ／Ｆの宛先を設定する（ステップＳ
３）。これは、宛先リストＤＢ２５から所望の宛先情報
を選択することで設定することができる。

【００５１】宛先を設定すると（ステップＳ３）、作成
したＤ／Ｆは検印者に自動回覧される（ステップＳ
４）。すなわち、検印者に検印を行うべきＤ／Ｆがある
旨の電子メールが送信される。検印者が事業部Ｄ／ＦＤ
Ｂ２２を開いて当該Ｄ／Ｆを閲覧し、Ｄ／Ｆに検印を完
了すると（ステップＳ５のＹ）、宛先となっている事業
部の事業部Ｄ／ＦＤＢ２２にＤ／Ｆが送信され、また、
そのＤ／Ｆを送信した旨の電子メールがその事業部のＤ
／Ｆ管理者に送信され、Ｄ／Ｆの作成者が所属する事業
部の事業部Ｄ／ＦＤＢ２２にＤ／Ｆが格納されて（ステ
ップＳ６）、処理を終了する。

【００５２】（Ｂ）本部にＤ／Ｆの審査、承認を求める
場合の処理手順 次に、社員が本部にＤ／Ｆの審査、承認を求める場合の
処理手順について、図９のフローチャートを参照して説
明する。ここで、図９に示すフローチャートは、クライ
アント４のＣＰＵ４１が文書回覧システム構築用のプロ
グラムに従い実行する処理と、サーバ３のＣＰＵ１１が
文書回覧システム構築用のプログラムに従い実行する処
理とを区別することなく記述している。その意味で、図
９に示すフローチャートは、ＣＰＵ４１やＣＰＵ１１と
して実現されているプロセッサにおけるプロセス処理を
記述するわけではなく、文書回覧システム１の全体処理
を概略的に記述していることになる。

【００５３】社員が本部に送る稟議書をＤ／Ｆとして、
ステップＳ１の場合と同様の手順で作成すると（ステッ
プＳ１１）、ステップＳ２と同様の手順で検印者が設定
される（ステップＳ１２）。この場合、Ｄ／Ｆとして作
成した稟議書は本部に送られるものとして予め宛先が設
定されているので、ステップＳ３のような宛先の設定を
行うことなく、ステップＳ４と同様に検印者に自動回覧
され（ステップＳ１３）、検印者がＤ／Ｆに検印を完了
すると（ステップＳ１４のＹ）、トップＤ／ＦＤＢ２４
に稟議書のＤ／Ｆが送信され、また、そのＤ／Ｆを送信
した旨の電子メールが本部のＤ／Ｆ管理者に送信され、
稟議書のＤ／Ｆの作成者が所属する事業部の事業部Ｄ／
ＦＤＢ２２にＤ／Ｆが格納されて（ステップＳ１５）、
処理を終了する。

【００５４】社員が自己の所属する事業部でＤ／Ｆの審
査、承認を求める場合の処理手順も、基本的にステップ
Ｓ１〜Ｓ６の処理と同様であるが、宛先が自己の所属す
る事業部の事業部Ｄ／ＦＤＢ２２であるので、宛先部門
の設定（ステップＳ３）を省略することもできる。ま
た、宛先が自己の所属する事業部の事業部Ｄ／ＦＤＢ２
２であるため、検印完了後のＤ／ＦはＤ／Ｆの作成者が
所属する事業部の事業部Ｄ／ＦＤＢ２２にＤ／Ｆが格納
されるだけであり、自己の所属する事業部のＤ／Ｆ管理
者に対し、事業部Ｄ／ＦＤＢ２２にＤ／Ｆが格納した旨
の電子メールが送信される。

【００５５】（Ｃ）審査、承認の処理手順 次に、他の事業部から受け取ったＤ／Ｆに対して審査、
承認を与える場合の処理手順について、図１０のフロー
チャートを参照して説明する。ここで、図１０に示すフ
ローチャートは、クライアント４のＣＰＵ４１が文書回
覧システム構築用のプログラムに従い実行する処理と、
サーバ３のＣＰＵ１１が文書回覧システム構築用のプロ
グラムに従い実行する処理とを区別することなく記述し
ている。その意味で、図１０に示すフローチャートは、
ＣＰＵ４１やＣＰＵ１１として実現されているプロセッ
サにおけるプロセス処理を記述するわけではなく、文書
回覧システム１の全体処理を概略的に記述していること
になる。

【００５６】Ｄ／Ｆ管理者が自己の所属する事業部の事
業部Ｄ／ＦＤＢ２２を開いて、他の事業部からＤ／Ｆを
送信した旨の電子メールの受信を確認したときは（ステ
ップＳ２１）、自己の所属する事業部のサーバ３に用意
されている審査承認テーブルから必要な人物を選択する
ことで、Ｄ／Ｆを審査、承認する者を設定する（ステッ
プＳ２２）。この設定がなされると、審査、承認をする
者に自動回覧される（ステップＳ２３）。すなわち、審
査、承認する者に設定された者のクライアント４に、審
査、承認をすべきＤ／Ｆが届いている旨の電子メールを
自動送信する（審査承認テーブルのメールアドレスが自
動設定される）。この電子メールには、Ｄ／Ｆが届いて
いる旨の文面と共に、当該Ｄ／Ｆにリンクするための文
書リンクを含める。

【００５７】クライアント４では、ディスプレイ４８に
受信した電子メールのタイトルの一覧を表示することが
できる。そして、クライアント４が、Ｄ／Ｆが届いてい
る旨の電子メールを受信すると、その電子メールのタイ
トルの冒頭部分などには、他の種類の電子メールと識別
するための標識（例えば、“□□□”）を表示する。

【００５８】そこで、ユーザがクライアント４を通じて
事業部Ｄ／ＦＤＢ２２にアクセスし、この標識が付され
た電子メールを開き、文書リンクをクリックすると、該
当するＤ／Ｆが事業部Ｄ／ＦＤＢ２２から送信されて自
らのクライアント４の記憶領域として機能するＲＡＭ４
３に記憶される。ここに、意思決定の入力要求を行うこ
とができる電子化された文書であるＤ／Ｆをサーバ３か
ら呼び出しＲＡＭ４３という記憶領域に記憶する手段
（ステップ）が実行される。これにより、ユーザは、ク
ライアント４のディスプレイ４８を通じてそのＤ／Ｆを
閲覧することができ、そのＤ／Ｆに対する意思表示の付
加として、審査、承認を書き込むことができる（ステッ
プＳ２４のＹ）。ここに、意思決定の入力要求が入力可
能なようにＤ／Ｆをディスプレイ４８に表示させる手段
（ステップ）が実行される。

【００５９】審査、承認が完了（ステップＳ２４のＹ）
したＤ／Ｆは、審査、承認の依頼元である事業部の事業
部Ｄ／ＦＤＢ２２に自動で返信される（Ｄ／Ｆに書き込
まれている事業部Ｄ／ＦＤＢ２２の登録情報が自動返信
の宛先の手がかりとなる）。また、当該事業部Ｄ／ＦＤ
Ｂ２２のＤ／Ｆ管理者には、審査、承認が完了した旨の
電子メールが自動で送信され（Ｄ／Ｆに書き込まれてい
る登録情報が宛先の手がかりとなる）、審査、承認が完
了したＤ／Ｆは、審査、承認を行った事業部の事業部Ｄ
／ＦＤＢ２２にも格納される（ステップＳ２５）。審
査、承認が完了した旨の電子メールを受け取ったＤ／Ｆ
管理者は、所定の操作を行うだけで、Ｄ／Ｆの起案元で
ある社員にＤ／Ｆの審査、承認が完了した旨の電子メー
ルを発信することができる（Ｄ／Ｆにメールアドレス情
報が最初から自動書込されている）。

【００６０】他の事業部からＤ／Ｆを受け取ったのが本
部の場合も、ステップＳ２１〜Ｓ２５と同様の手順で処
理される。同一の事業部内でＤ／Ｆを受け取った場合
も、ステップＳ２１〜Ｓ２５の手順に準じるが、ステッ
プＳ２５では、審査、承認が完了した旨の電子メール
を、同一事業部のＤ／Ｆ管理者に送信するだけである。

【００６１】（Ｄ）意思決定支援処理 電子化された文書であるＤ／Ｆについて、図７における
検印者への自動回覧処理（ステップＳ４）後の検印終了
判定まで（ステップＳ５）の処理、図９における検印者
への自動回覧処理（ステップＳ１３）後の検印終了判定
まで（ステップＳ１４）の処理、及び図１０における審
査承認者への自動回覧処理（ステップＳ２３）後の審査
承認完了まで（ステップＳ２４）の処理においては、同
一のＤ／Ｆが複数のクライアント４によって同時に開か
れて検印や承認等の意思決定が求められる可能性がある
ことを考慮し、排他的制御が実行される。つまり、同一
のＤ／Ｆが複数のクライアント４によって同時に開かれ
ている場合、一のクライアント４から検印や承認等のよ
うなそのＤ／Ｆを更新する意思決定が求められると、他
のクライアント４によるそのＤ／Ｆの更新を禁止する、
という処理が実行される。この際、本実施の形態では、
各クライアント４において、各クライアント４にインス
トールされている意思決定援用のプログラムに従い、図
１１に示す処理が実行される。以下、このような意思決
定支援処理について、この処理に伴い遷移するクライア
ント４のディスプレイ４８に表示される図１２ないし図
１８に例示する画面表示例を参照しながら説明する。

【００６２】図１１に示す処理は、図１０における審査
承認者への自動回覧処理（ステップＳ２３）後の審査承
認完了まで（ステップＳ２４）の処理の詳細である。ま
ず、各クライアント４において電子化された文書である
Ｄ／Ｆが開かれると（ステップＳ３１）、そのクライア
ント４のディスプレイ４８に指定されたＤ／Ｆが表示さ
れる。図１２及び図１３は、いずれも、この場合の初期
画面表示例を例示する模式図である。

【００６３】この際、指定されたＤ／Ｆは、サーバ３が
管理する事業部Ｄ／ＦＤＢ２２から送信され、この際、
そのＤ／Ｆの属性情報である編集者３３の情報もクライ
アント４に送信される。そこで、クライアント４におい
ては、そのＤ／Ｆにリンクさせて、編集者６３のフィー
ルドに、そのＤ／Ｆの属性情報である編集者３３の情報
を設定する。この編集者６３のフィールドに設定された
情報は、そのＤ／Ｆを特定する文書Ｎｏ．６１のフィー
ルドの情報に対応付けられており、この文書Ｎｏ．６１
のフィールドに設定された情報には、他に、呼び出し日
時６２のフィールドに記憶されるべき呼び出し日時も対
応付けられて記憶されている。

【００６４】ここで、編集者６３のフィールドに設定さ
れる情報は、対応するＤ／Ｆを開いた時点で、既に他の
クライアント４がそのＤ／Ｆについて編集中であるかど
うかを判定する材料を提供する。そこで、本実施の形態
では、編集者６３のフィールドに設定される情報が、Ｄ
／Ｆを表示する初期画面に影響を与えるような処理を実
行する。

【００６５】図１２は、現在開いているＤ／Ｆについ
て、サーバ３が管理する事業部Ｄ／ＦＤＢ２２に格納さ
れた編集者３３のフィールドの設定がＮｕｌｌ値であ
り、したがって、クライアント４における編集者６３の
フィールドに何も設定されない場合にディスプレイ４８
に表示される初期画面表示例を示している。これに対し
て、図１３は、現在開いているＤ／Ｆについて、サーバ
３が管理する事業部Ｄ／ＦＤＢ２２に格納された編集者
３３のフィールドに編集者が設定されており、したがっ
て、クライアント４における編集者６３のフィールドに
もその編集者が設定されている場合にディスプレイ４８
に表示される初期画面表示例を示している。

【００６６】図１２に示すＤ／Ｆの初期画面表示例と、
図１３に示すＤ／Ｆの初期画面表示例とを比較すると、
いずれにも、「アクションバー上の「編集切替」ボタン
をクリックして下さい。審査承認ができます。」という
アンダーライン付きの審査オブジェクト８１が出現する
ことは共通していながら、図１３に示す初期画面表示例
だけには、「○○さんが編集中です」というような報知
情報としてのメッセージ８２が表示されている。ここ
に、優先処理があると判定した場合、意思決定の結果入
力を実行可能とするに先立って、意思決定の入力要求に
応じることができないことを報知する手段（ステップ）
の機能が実行される。

【００６７】次いで、図１２に示すＤ／Ｆの初期画面表
示例にも、図１３に示すＤ／Ｆの初期画面表示例にも、
いずれにも表示されている「アクションバー上の「編集
切替」ボタンをクリックして下さい。審査承認ができま
す。」というアンダーライン付きの審査オブジェクト８
１は、審査承認を実行するためのサーバ３に対する意思
決定入力要求であり、その審査オブジェクト８１が指定
されることで、サーバ３に対する意思決定入力要求のコ
マンドが実行されることになる。

【００６８】そこで、審査オブジェクト８１が指定され
ると（ステップＳ３２）、まず、編集者６３の有無、つ
まり、優先処理の有無がチェックされる（ステップＳ３
３）。このチェックは、クライアント４のＲＡＭ４３に
格納されている編集者６３のフィールドに設定された情
報に従い行われる。つまり、クライアント４は、自らの
セルフチェックによって、開いているＤ／Ｆについて現
在編集中の者の有無を判定する（ステップＳ３４）。こ
こに、意思決定の入力要求があった場合、別のクライア
ント４による意思決定の結果入力に関する優先処理の有
無を判定する手段（ステップ）の機能が実行される。

【００６９】このような判定の結果、現在編集中の者が
あれば、その旨が報知される（ステップＳ３５）。ここ
に、優先処理があると判定した場合、意思決定の結果入
力を実行可能とするに先立って、意思決定の入力要求に
応じることができないことを報知する手段（ステップ）
の機能が実行される。この場合の報知は、図１１のフロ
ーチャートに例示するように、「○○さんが編集中 暫
くしてから再度審査してください」というようなもので
も良く、図１４の報知ダイアログ８３に例示するような
「作成状態は○○さんが編集中のため操作は出来ませ
ん。お手数ですが、操作を中止してください。」という
ようなものでも良い。

【００７０】特に、「○○さんが編集中です」というよ
うな報知情報としてのメッセージ８２が表示されている
図１３に示すＤ／Ｆの初期画面表示例では、そのような
メッセージ８が表示されているにも拘らず、出現してい
る審査オブジェクト８１が指定された場合には、そのよ
うなメッセージ８２に次いで、「○○さんが編集中 暫
くしてから再度審査してください」「作成状態は○○さ
んが編集中のため操作は出来ません。お手数ですが、操
作を中止してください。」というような意思決定の入力
要求に応じることができないことの報知がなされる。

【００７１】これに対して、ステップＳ３４での判定の
結果、現在編集中の者がないとの結果が得られた場合に
は、そのクライアント４においてそのＤ／Ｆを開いてい
る間に編集中となっていないかどうかのチェックがなさ
れる（ステップＳ３６）。このチェックは、サーバ３へ
の問い合わせ照合によって実現される。サーバ３では、
そのＤ／Ｆの属性情報である編集者３３のフィールドを
参照し、その結果をクライアント４に返信する。

【００７２】クライアント４は、サーバ３からの返信を
参照し、開いているＤ／Ｆについて編集中となった者の
有無を判定する（ステップＳ３７）。ここに、意思決定
の入力要求があった場合、別のクライアント４による意
思決定の結果入力に関する優先処理の有無を判定する手
段（ステップ）の機能が実行される。

【００７３】このような判定の結果、編集中となった者
があれば、その旨が報知される（ステップＳ３８）。こ
こに、優先処理があると判定した場合、意思決定の結果
入力を実行可能とするに先立って、意思決定の入力要求
に応じることができないことを報知する手段（ステッ
プ）の機能が実行される。この場合の報知は、図１１の
フローチャートに例示するように、「○○さんが編集中
暫くしてから再度審査してください」というようなも
のでも良く、図１４の報知ダイアログ８３に例示するよ
うな「作成状態は○○さんが編集中のため操作は出来ま
せん。お手数ですが、操作を中止してください。」とい
うようなものでも良い。

【００７４】これに対して、ステップＳ３７での判定の
結果、編集中となった者がないとの結果が得られた場合
には、そのクライアント４においてそのＤ／Ｆを開いて
いる間にＤ／Ｆが更新されていないかどうかのチェック
がなされる（ステップＳ３９）。このチェックは、サー
バ３への問い合わせ照合及びクライアント４自らの問い
合わせ照合によって実現される。つまり、サーバ３で
は、そのＤ／Ｆの属性情報である最終更新日時３２のフ
ィールドを参照し、その結果をクライアント４に返信す
る。また、クライアント４では、そのＤ／Ｆに対応付け
られた呼び出し日時６２を参照し、その結果をクライア
ントからの返信と比較する。つまり、最終更新日時と呼
び出し日時とが同一である場合には、Ｄ／Ｆの更新がな
されていないことになり、最終更新日時と呼び出し日時
とが相違する場合には、Ｄ／Ｆの更新がなされたことに
なる。そこで、クライアント４は、サーバ３から返信さ
れた最終更新日時とＲＡＭ４３が記憶する呼び出し日時
とを参照し、開いているＤ／Ｆの更新の有無を判定する
（ステップＳ４０）。ここに、意思決定の入力要求があ
った場合、別のクライアント４による意思決定の結果入
力に関する優先処理の有無を判定する手段（ステップ）
の機能が実行される。

【００７５】このような判定の結果、開いているＤ／Ｆ
の更新があったと判定された場合、その旨が報知される
（ステップＳ４１）。ここに、優先処理があると判定し
た場合、意思決定の結果入力を実行可能とするに先立っ
て、意思決定の入力要求に応じることができないことを
報知する手段（ステップ）の機能が実行される。この場
合の報知は、図１１のフローチャートに例示するよう
に、「開いている間に文書が更新されました 一旦文書
を閉じて再度審査してください」というようなものでも
良く、図１５の報知ダイアログ８４に例示するような
「開いている間に文書が保存されました。お手数です
が、戻って再度文書を開いてください。」というような
ものでも良い。

【００７６】これに対して、ステップＳ４０での判定の
結果、開いているＤ／Ｆが更新されていないと判定され
た場合には、そのＤ／Ｆを自動編集する処理が実行され
る（ステップＳ４２）。この処理は、サーバ３に対し
て、該当するＤ／Ｆの編集者３３のフィールドに、その
クライアント４の使用者を設定することを依頼する、と
いうものである。

【００７７】ここに到り、本実施の形態では、初めて審
査フローを実施することができる（ステップＳ４３）。
この時、クライアント４のディスプレイ４８には、図１
６の審査表示画面に例示されるように、「審査（Ｏ
Ｋ）」、「審査者が良ければ承認」、「承認保留」、
「作成者に訂正依頼」及び「非承認」という５つの審査
結果オブジェクト８５が出現し、これらの所望の審査結
果オブジェクト８５が操作入力され、その結果がサーバ
３に送信されることで、審査が完了する。ここに、優先
処理がないと判定した場合、意思決定の結果入力を実行
可能とし、入力された意思決定の結果をサーバ３に送信
する処理を実行する手段（ステップ）の機能が実行され
る。

【００７８】その後の処理としては、サーバ３に対し
て、未審査者へ審査可能通知メールを送信するために、
未審査である書込み権限者３５のフィールド情報の送信
を依頼し、サーバ３からその情報を受信することで、未
審査者へ審査可能通知メールを発信する（ステップＳ４
４）。なお、サーバ３では、未審査の書込み権限者３５
のフィールドを参照して未審査者を見出す。

【００７９】なお、ステップＳ３２における審査オブジ
ェクト８１の指定が複数のクライアント４において全く
同時に実行されることがある。この場合には、サーバ３
は、クライアント４から送信される時間情報又は自ら計
時する時間情報が少しでも速い方のクライアント４に編
集権限を付与する。図１７は、このような場合に編集権
限が与えられたクライアント４のディスプレイ４８に表
示される画面表示例であり、図１８は、そのような場合
に編集権限が与えられなかったクライアント４のディス
プレイ４８に表示される画面表示例である。

【００８０】

【発明の効果】請求項１記載の意思決定支援装置の発明
は、意思決定の入力要求を行うことができる電子化され
た文書をサーバから呼び出し記憶領域に記憶する手段
と、意思決定の入力要求が入力可能なように前記文書を
表示装置に表示させる手段と、意思決定の入力要求があ
った場合、別のクライアントによる意思決定の結果入力
に関する優先処理の有無を判定する手段と、前記優先処
理がないと判定した場合、意思決定の結果入力を実行可
能とし、入力された意思決定の結果を前記サーバに送信
する処理を実行する手段と、前記優先処理があると判定
した場合、意思決定の結果入力を実行可能とするに先立
って、意思決定の入力要求に応じることができないこと
を報知する手段と、を具備するので、意思決定の入力要
求に応じることができないことの報知によって、競合文
書の発生を事前に防いで無駄な入力作業が行われること
を防止することができる。

【００８１】請求項２記載の発明は、請求項１記載の意
思決定支援装置において、前記優先処理の有無を判定す
る処理は、その優先処理の有無を前記サーバに問い合わ
せることによって実行されるので、サーバに対する問い
合わせによって優先処理があるかどうかの情報を容易に
得ることができる。

【００８２】請求項３記載の発明は、請求項２記載の意
思決定支援装置において、前記サーバから、同一の前記
文書について別のクライアントが意思決定を入力中であ
ることを示すステータスを受信した場合、前記優先処理
があると判定するので、同一の文書について別のクライ
アントが意思決定を入力中であることを示すステータス
は、サーバから容易に得ることができるため、このよう
なステータスをサーバから受信することで、優先処理が
あるかどうかを容易に判定することができる。

【００８３】請求項４記載の発明は、請求項３記載の意
思決定支援装置において、同一の前記文書について別の
クライアントが意思決定を入力中であることを示すステ
ータスは、その文書についての編集者に関する情報であ
るので、その文書についての編集者に関する情報、例え
ば、現在編集しているユーザの存在を示唆する情報を得
ることで、優先処理の有無を容易に判定することができ
る。

【００８４】請求項５記載の発明は、請求項２記載の意
思決定支援装置において、前記サーバから、同一の前記
文書について別のクライアントによって意思決定が入力
済みあることを示すステータスを受信した場合、前記優
先処理があると判定するので、同一の文書について別の
クライアントが意思決定を入力済みであることを示すス
テータスは、サーバから容易に得ることができるため、
このようなステータスをサーバから受信することで、優
先処理があるかどうかを容易に判定することができる。

【００８５】請求項６記載の発明は、請求項５記載の意
思決定支援装置において、同一の前記文書について別の
クライアントによって意思決定が入力済みあることを示
すステータスは、その文書の更新日時であり、その更新
日時が、予め前記記憶領域に記憶させておいた前記サー
バからの前記文書の呼び出し日時と相違することをもっ
て前記優先処理があると判定するので、記憶領域に記憶
する文書の呼び出し日時とサーバから受信した文書の更
新日時とが相違すれば、その文書について別のクライア
ントによって意思決定が入力済みであることが判明する
ため、優先処理の有無を容易に判定することができる。

【００８６】請求項７記載の発明は、請求項１記載の意
思決定支援装置において、前記文書を前記サーバから呼
び出すに際して、前記優先処理に関するデータを前記文
書と共に受信して前記記憶領域に記憶させておき、前記
優先処理の有無を判定する処理は、前記記憶領域に記憶
させた前記優先処理に関するデータを参照して実行する
ので、サーバに対する問い合わせることなく、優先処理
があるかどうかの情報を容易に得ることができ、したが
って、ネットワークに負担をかけることなく優先処理有
無の判定を迅速に行うことができる。

【００８７】請求項８記載の意思決定支援方法の発明
は、プロセッサによって、意思決定の入力要求が入力可
能な電子化された文書をサーバから呼び出すステップ
と、前記プロセッサによって、意思決定の入力要求が入
力可能なように前記文書を表示装置に表示させるステッ
プと、前記プロセッサが、意思決定の入力要求があった
と判断した場合、意思決定の結果入力に関する優先処理
の有無を判定し、その判定結果に基づいて意思決定の入
力要求に応じることができるかどうかを判断するステッ
プと、前記プロセッサが、意思決定の入力要求に応じる
ことができると判断した場合、意思決定の結果入力を実
行可能とし、入力された意思決定の結果を前記サーバに
送信する処理を実行するステップと、前記プロセッサ
が、意思決定の入力要求に応じることができないと判断
した場合、意思決定の結果入力を実行可能とするに先立
って、意思決定の入力要求に応じることができないこと
を報知するステップと、を具備するので、意思決定の入
力要求に応じることができないことの報知によって、競
合文書の発生を事前に防いで無駄な入力作業が行われる
ことを防止することができる。

【００８８】請求項９記載の記憶媒体の発明は、コンピ
ュータにインストールされ、このコンピュータに、意思
決定の入力要求が入力可能な電子化された文書をサーバ
から呼び出す手段と、意思決定の入力要求が入力可能な
ように前記文書を表示装置に表示させる手段と、意思決
定の入力要求があった場合、意思決定の結果入力に関す
る優先処理の有無を判定し、その判定結果に基づいて意
思決定の入力要求に応じることができるかどうかを判断
する手段と、意思決定の入力要求に応じることができる
と判断した場合、意思決定の結果入力を実行可能とし、
入力された意思決定の結果を前記サーバに送信する処理
を実行する手段と、意思決定の入力要求に応じることが
できないと判断した場合、意思決定の結果入力を実行可
能とするに先立って、意思決定の入力要求に応じること
ができないことを報知する手段と、を実行させるコンピ
ュータ読み取り可能なプログラムを記憶するので、この
プログラムがコンピュータにインストールされてそのプ
ログラムに従いコンピュータが動作すると、意思決定の
入力要求に応じることができないことの報知によって、
競合文書の発生を事前に防いで無駄な入力作業が行われ
ることを防止することができる。

【００８９】請求項１０記載のコンピュータ読み取り可
能なプログラムの発明は、コンピュータにインストール
され、このコンピュータに、意思決定の入力要求が入力
可能な電子化された文書をサーバから呼び出す手段と、
意思決定の入力要求が入力可能なように前記文書を表示
装置に表示させる手段と、意思決定の入力要求があった
場合、意思決定の結果入力に関する優先処理の有無を判
定し、その判定結果に基づいて意思決定の入力要求に応
じることができるかどうかを判断する手段と、意思決定
の入力要求に応じることができると判断した場合、意思
決定の結果入力を実行可能とし、入力された意思決定の
結果を前記サーバに送信する処理を実行する手段と、意
思決定の入力要求に応じることができないと判断した場
合、意思決定の結果入力を実行可能とするに先立って、
意思決定の入力要求に応じることができないことを報知
する手段と、を実行させるので、このプログラムがコン
ピュータにインストールされてそのプログラムに従いコ
ンピュータが動作すると、意思決定の入力要求に応じる
ことができないことの報知によって、競合文書の発生を
事前に防いで無駄な入力作業が行われることを防止する
ことができる。

【図面の簡単な説明】

【図１】この発明の一実施の形態である文書回覧システ
ムのシステム構成を示すブロック図である。

【図２】前記文書回覧システムを構成するサーバのシス
テム構成を示すブロック図である。

【図３】前記各サーバに設けられている各データベース
の関係を説明する機能ブロック図である。

【図４】電子化された文書であるＤ／ＦとこのＤ／Ｆの
属性情報とを示す模式図である。

【図５】前記文書回覧システムを構成するクライアント
のシステム構成を示すブロック図である。

【図６】電子化された文書であるＤ／ＦとこのＤ／Ｆに
リンクする情報とを示す模式図である。

【図７】前記文書回覧システムで他の事業部に決定依頼
書の審査、承認を求める場合の処理手順について説明す
るフローチャートである。

【図８】前記文書回覧システムで標準文書ベースに格納
されている標準文書のタイトルを列挙して表示するクラ
イアントでのディスプレイの画面表示例を示す模式図で
ある。

【図９】前記文書回覧システムで本部に決定依頼書の審
査、承認を求める場合の処理手順について説明するフロ
ーチャートである。

【図１０】前記文書回覧システムで他の事業部から受け
取った決定依頼書に対する審査、承認を与える場合の処
理手順について説明するフローチャートである。

【図１１】意思決定支援処理での処理手術について説明
するフローチャートである。

【図１２】Ｄ／Ｆを開いた場合のクライアントでの初期
画面表示例を示す模式図である。

【図１３】既に編集者が存在するＤ／Ｆを開いた場合の
クライアントでの初期画面表示例を示す模式図である。

【図１４】クライアントにおいて意思決定の入力要求を
したのに対して、そのＤ／Ｆを開いた後にそのＤ／Ｆに
編集者が設定されてしまっている場合の拒否画面表示例
を示す模式図である。

【図１５】クライアントにおいて意思決定の入力要求を
したのに対して、そのＤ／Ｆを開いた後にそのＤ／Ｆが
更新されてしまった場合の拒否画面表示例を示す模式図
である。

【図１６】クライアントにおいて意思決定の入力要求を
した場合の承認画面表示例を示す模式図である。

【図１７】複数のクライアントが同時に意思決定の入力
要求をした場合に、優先権が与えられるクライアントの
承認画面表示例を示す模式図である。

【図１８】複数のクライアントが同時に意思決定の入力
要求をした場合に、優先権が与えられなかったクライア
ントの拒否画面表示例を示す模式図である。

【符号の説明】

３ サーバ ４ クライアント ４３ 記憶領域（ＲＡＭ） ４８ 表示装置

Claims (10)

【特許請求の範囲】
1. 【請求項１】 意思決定の入力要求を行うことができる
   電子化された文書をサーバから呼び出し記憶領域に記憶
   する手段と、 意思決定の入力要求が入力可能なように前記文書を表示
   装置に表示させる手段と、 意思決定の入力要求があった場合、別のクライアントに
   よる意思決定の結果入力に関する優先処理の有無を判定
   する手段と、 前記優先処理がないと判定した場合、意思決定の結果入
   力を実行可能とし、入力された意思決定の結果を前記サ
   ーバに送信する処理を実行する手段と、 前記優先処理があると判定した場合、意思決定の結果入
   力を実行可能とするに先立って、意思決定の入力要求に
   応じることができないことを報知する手段と、を具備す
   る意思決定支援装置。
2. 【請求項２】 前記優先処理の有無を判定する処理は、
   その優先処理の有無を前記サーバに問い合わせることに
   よって実行される請求項１記載の意思決定支援装置。
3. 【請求項３】 前記サーバから、同一の前記文書につい
   て別のクライアントが意思決定を入力中であることを示
   すステータスを受信した場合、前記優先処理があると判
   定する請求項２記載の意思決定支援装置。
4. 【請求項４】 同一の前記文書について別のクライアン
   トが意思決定を入力中であることを示すステータスは、
   その文書についての編集者に関する情報である請求項３
   記載の意思決定支援装置。
5. 【請求項５】 前記サーバから、同一の前記文書につい
   て別のクライアントによって意思決定が入力済みあるこ
   とを示すステータスを受信した場合、前記優先処理があ
   ると判定する請求項２記載の意思決定支援装置。
6. 【請求項６】 同一の前記文書について別のクライアン
   トによって意思決定が入力済みあることを示すステータ
   スは、その文書の更新日時であり、その更新日時が、予
   め前記記憶領域に記憶させておいた前記サーバからの前
   記文書の呼び出し日時と相違することをもって前記優先
   処理があると判定する請求項５記載の意思決定支援装
   置。
7. 【請求項７】 前記文書を前記サーバから呼び出すに際
   して、前記優先処理に関するデータを前記文書と共に受
   信して前記記憶領域に記憶させておき、前記優先処理の
   有無を判定する処理は、前記記憶領域に記憶させた前記
   優先処理に関するデータを参照して実行する請求項１記
   載の意思決定支援装置。
8. 【請求項８】 プロセッサによって、意思決定の入力要
   求が入力可能な電子化された文書をサーバから呼び出す
   ステップと、 前記プロセッサによって、意思決定の入力要求が入力可
   能なように前記文書を表示装置に表示させるステップ
   と、 前記プロセッサが、意思決定の入力要求があったと判断
   した場合、意思決定の結果入力に関する優先処理の有無
   を判定し、その判定結果に基づいて意思決定の入力要求
   に応じることができるかどうかを判断するステップと、 前記プロセッサが、意思決定の入力要求に応じることが
   できると判断した場合、意思決定の結果入力を実行可能
   とし、入力された意思決定の結果を前記サーバに送信す
   る処理を実行するステップと、 前記プロセッサが、意思決定の入力要求に応じることが
   できないと判断した場合、意思決定の結果入力を実行可
   能とするに先立って、意思決定の入力要求に応じること
   ができないことを報知するステップと、を具備する意思
   決定支援方法。
9. 【請求項９】 コンピュータにインストールされ、この
   コンピュータに、 意思決定の入力要求が入力可能な電子化された文書をサ
   ーバから呼び出す手段と、 意思決定の入力要求が入力可能なように前記文書を表示
   装置に表示させる手段と、 意思決定の入力要求があった場合、意思決定の結果入力
   に関する優先処理の有無を判定し、その判定結果に基づ
   いて意思決定の入力要求に応じることができるかどうか
   を判断する手段と、 意思決定の入力要求に応じることができると判断した場
   合、意思決定の結果入力を実行可能とし、入力された意
   思決定の結果を前記サーバに送信する処理を実行する手
   段と、 意思決定の入力要求に応じることができないと判断した
   場合、意思決定の結果入力を実行可能とするに先立っ
   て、意思決定の入力要求に応じることができないことを
   報知する手段と、を実行させるコンピュータ読み取り可
   能なプログラムを記憶する記憶媒体。
10. 【請求項１０】 コンピュータにインストールされ、こ
    のコンピュータに、 意思決定の入力要求が入力可能な電子化された文書をサ
    ーバから呼び出す手段と、 意思決定の入力要求が入力可能なように前記文書を表示
    装置に表示させる手段と、 意思決定の入力要求があった場合、意思決定の結果入力
    に関する優先処理の有無を判定し、その判定結果に基づ
    いて意思決定の入力要求に応じることができるかどうか
    を判断する手段と、 意思決定の入力要求に応じることができると判断した場
    合、意思決定の結果入力を実行可能とし、入力された意
    思決定の結果を前記サーバに送信する処理を実行する手
    段と、 意思決定の入力要求に応じることができないと判断した
    場合、意思決定の結果入力を実行可能とするに先立っ
    て、意思決定の入力要求に応じることができないことを
    報知する手段と、を実行させるコンピュータ読み取り可
    能なプログラム。