JP2002108789A - 回覧承認システム、回覧承認方法および回覧承認プログラムを記録した媒体 - Google Patents

Abstract

(57)【要約】 【課題】 承認に当たり電子メール文書の作成者が電子
メールの転送先を正しく把握していることが必要であっ
た。また、承認中の文書は転送されていくため、文書の
作成者等が当該承認中にその進捗状況を把握することが
できなかった。 【解決手段】 回覧案件データと承認者登録データと承
認順序データとを蓄積し、回覧案件データに対する承認
依頼を行って当該承認依頼に対する返答を承認者から受
け取るという処理を同承認順序データに基づいて所定の
承認順序で行う。ここで、承認順序は予め登録されてお
り、回覧案件を作成するに当たり少なくとも承認内容を
知っていれば回覧案件を作成可能である。また、承認依
頼と返答を集中的に管理することから、承認中に進捗状
況を容易に把握することが可能である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、回覧承認システ
ム、回覧承認方法および回覧承認プログラムを記録した
媒体に関する。

【０００２】

【従来の技術】従来、この種の回覧承認システムとし
て、特開平９−８１４７７号公報に開示されたものが知
られている。同公報に開示された発明においては、承認
を求める文書を電子メールで送信するようになってお
り、承認後の電子メールをメール中の電子承認欄に記載
された上位の承認者に対して転送することによって複数
人での承認を行うものである。また、この電子承認欄に
は承認印が表示されており、承認者は自己の承認印をク
リックすることにより印鑑を押印する感覚で承認を与え
ることができる。

【０００３】

【発明が解決しようとする課題】上述した従来の回覧承
認システムには以下の問題があった。すなわち、承認に
当たり電子メールの転送対象となる者は予め電子承認欄
に記載されている必要があり、当該電子メール文書の作
成者が電子メールの転送先を正しく把握していることが
必要になる。また、承認中の文書は転送されていくた
め、文書の作成者等が当該承認中にその進捗状況を把握
することができなかった。本発明は、上記課題にかんが
みてなされたもので、回覧案件を作成するに当たり少な
くとも承認内容を知っていれば回覧案件を作成可能に
し、また、承認中に進捗状況を容易に把握することが可
能な回覧承認システム、回覧承認方法および回覧承認プ
ログラムを記録した媒体の提供を目的とする。

【０００４】

【課題を解決するための手段】上記目的を達成するた
め、請求項１にかかる発明は、回覧案件を表す回覧案件
データを蓄積する回覧案件データ蓄積手段と、承認者を
特定可能な承認者登録データと回覧案件の承認順序を表
す承認順序データとを蓄積する承認データ蓄積手段と、
上記承認順序に基づいて決定される承認者に対して上記
回覧案件に対する承認依頼を双方向通信を介して出力す
る承認依頼出力手段と、双方向通信を介して外部からの
アクセスを受け付け、同アクセスが上記承認者登録デー
タに登録された登録承認者からのものであるか否かを判
別する登録承認者判別手段と、同登録承認者判別手段に
よって登録承認者であると判別された承認者から双方向
通信を介して上記承認依頼に対する返答を受け付ける承
認返答受付手段とを具備する構成としてある。

【０００５】上記のように構成した請求項１にかかる発
明においては、回覧案件データ蓄積手段と承認データ蓄
積手段とを具備しており、回覧案件データ蓄積手段にて
回覧案件を表す回覧案件データを蓄積し、承認データ蓄
積手段にて承認者を特定可能な承認者登録データと回覧
案件の承認順序を表す承認順序データとを蓄積する。承
認依頼出力手段は上記回覧案件に対する承認依頼を双方
向通信を介して出力するようになっており、この出力先
は上記回覧案件の承認順序に基づいて決定される。本シ
ステムはこの承認依頼に対して返答を受け取るが、返答
の受け取りに当たり正規の承認者であるかを確認するよ
うになっており、登録承認者判別手段が双方向通信を介
して外部からのアクセスを受け付け、同アクセスが上記
承認者登録データに登録された登録承認者からのもので
あるか否かを判別する。そして、承認返答受付手段は、
同登録承認者判別手段によって登録承認者であると判別
された承認者から、双方向通信を介して上記承認依頼に
対する返答を受け付ける。

【０００６】すなわち、承認依頼の出力は予め登録され
ている承認者および承認順序によって管理されているの
で、回覧案件の作成者等が案件を作成するたびに承認順
序を指定したり承認者の連絡先等を確認したりする必要
がない。従って、回覧案件を作成するに当たり少なくと
も承認内容を知っていれば回覧案件を作成できる。ま
た、各承認者からの承認依頼に対する返答は本システム
によって集中的に管理されており、全承認者の承認を待
たなくても各承認者の承認返答が逐次受け付けられるの
で、承認中に進捗状況を容易に把握することができる。

【０００７】ここで、回覧案件データは承認者の承認を
得るために回覧する案件のデータであって承認者が承認
内容を認識可能に蓄積できればよく、そのデータ態様は
様々である。すなわち、文書によって承認内容を示すと
きにはテキスト形式のデータや所定のアプリケーション
で文書表示可能なファイル、例えば、「Ｍｉｃｒｏｓｏ
ｆｔ Ｗｏｒｄ」で扱うファイルである「ｄｏｃ」ファ
イル（Ｍｉｃｒｏｓｏｆｔは米国マイクロソフト社の登
録商標）や「Ａｃｒｏｂａｔ Ｒｅａｄｅｒ」で扱うフ
ァイルである「ｐｄｆ」ファイル（Ａｃｒｏｂａｔは米
国アドビシステムズ社の登録商標）等を蓄積することも
可能である。また、承認依頼出力手段は承認依頼を行う
ことができればよく、承認内容を承認者に対して提示す
るに当たり、承認者が双方向通信を介して本システムに
アクセスしたときに上記回覧案件を表示可能に構成した
り、回覧案件データ自体を承認者に対して送信したりす
ることが可能であり、種々の態様が採用可能である。

【０００８】さらに、上記承認者登録データは承認依頼
出力に際してその出力先を特定し、また登録承認者であ
ることが判別可能なデータであればよく、例えば所定の
ＩＤや承認者のメールアドレス、あるいはこれらの組み
合わせ等種々の態様を採用することができる。承認順序
データは承認を行う順序を規定できればよく、承認順序
としてある承認者が承認を行わないと次の承認者に回覧
がなされないように規定することもでき、この場合には
ある承認者が承認を行わなければ次の承認者に回覧され
ないようになる。承認返答受付手段においては承認依頼
に対する返答を受け付けることができればよく、承認依
頼に対する是認／否認の他、承認内容の修正や種々の提
案等を受け付けるように構成することもできる。

【０００９】また、回覧案件データは承認者が承認内容
を認識可能に蓄積できればよく、上述のように種々のデ
ータ態様が採用可能であるが、かかる回覧案件データを
作成するに当たり作成者の作業負担を低減するのに好適
な構成の一例として、請求項２にかかる発明は、上記請
求項１に記載の回覧承認システムにおいて、上記回覧案
件データは、予め用意された入力項目に対して入力を行
うことによって作成されたデータである構成としてあ
る。

【００１０】上記のように構成した請求項２にかかる発
明においては、予め用意された入力項目に対して入力を
行うことによって回覧案件データが作成される。すなわ
ち、各案件毎に承認内容が異なるとしても、その文体や
文書の必須記載項目など全ての回覧案件に共通に記載さ
れる事項も多い。この場合には、共通記載事項を定型文
書化し、案件毎に異なる事項のみを入力させるように構
成すれば、非常に簡単であり、かつ少ない労力で回覧案
件を作成することができる。かかる構成は、大量の回覧
案件を作成する場合、種々の人員が回覧案件作成に関与
する場合、不慣れな人員が回覧案件を作成する場合等に
特に好適である。

【００１１】さらに、複数の回覧案件が存在する場合に
好適な構成の一例として、請求項３にかかる発明は、上
記請求項１または請求項２のいずれかに記載の回覧承認
システムにおいて、上記承認データ蓄積手段は、上記回
覧案件データ蓄積手段に蓄積される回覧案件データの案
件種類毎に承認順序データを蓄積している構成としてあ
る。上記のように構成した請求項３にかかる発明におい
ては、回覧案件の種類毎に承認順序が対応づけられてい
る。すなわち、本システムにおいては上述のように承認
内容の異なる複数の回覧案件を取り扱うことができる
が、承認内容が異なれば当然に承認を必要とする承認者
が異なってくることが想定される。

【００１２】そこで、回覧案件の種類が同一の場合は同
一の承認順序データを使用することにすれば、全ての回
覧案件に対して承認順序を決定するような作業をしない
でも承認内容毎に承認者が異なる場合に対応することが
できる。ここで、回覧案件の種類としては種々のものが
採用可能であり、回覧案件の標題や回覧案件を保存する
フォルダ、データ形式、案件が回覧される部署等種々の
指針によって種類を分分類することができる。

【００１３】さらに、本システムにおいては登録承認者
判別手段によって登録承認者であるか否かを判別する
が、この判別を行う際に好適な構成の一例として請求項
４にかかる発明は、上記請求項１〜請求項３のいずれか
に記載の回覧承認システムにおいて、上記承認依頼出力
手段は、承認依頼毎に個別の識別ＩＤを付与しつつ承認
依頼を行う構成としてある。上記のように構成した請求
項４にかかる発明においては、承認依頼毎に個別の識別
ＩＤを付与しつつ承認依頼を行うので、登録承認者が本
システムにアクセスする際に同識別ＩＤを使用するよう
に構成すれば、かかる識別ＩＤで登録承認者を判別する
ことができる。

【００１４】さらに、この識別ＩＤは承認依頼毎に個別
の識別ＩＤであることから、この識別ＩＤは登録承認者
の確認のみならず、いずれの承認依頼に対する返答であ
るかを判別することに使用することもできる。このた
め、正規に登録した承認者が承認依頼を受けていない段
階でアクセスしようとした場合にこれを拒絶することも
できるし、正規の承認者がアクセスしたときにどの回覧
案件に対する返答であるかを明示的に入力させるまでも
なくいずれの承認依頼に対する返答であるかを特定する
ことができる。

【００１５】さらに、承認者登録データの態様として好
適な一例として請求項５にかかる発明は、上記請求項１
〜請求項４のいずれかに記載の回覧承認システムにおい
て、上記承認データ蓄積手段が蓄積する承認者登録デー
タは承認者のメールアドレスである構成としてある。上
記のように構成した請求項５にかかる発明においては、
承認者のメールアドレスを承認者登録データとしてい
る。すなわち、承認依頼をメールで出力する場合には、
承認者登録データである承認者のメールアドレスがその
まま承認依頼の出力先を特定するデータになる。さら
に、メールアドレスは通常プライベートなデータの送受
信にも使用され、第三者に使用させることは少ないので
メールアドレスを明示してアクセスした者は正規の登録
承認者であると期待される。

【００１６】承認者登録データをメールアドレスにする
態様は、上記識別ＩＤと組み合わせると特に好適であ
る。すなわち、上記識別ＩＤと承認者登録データとの組
を判別することによっていずれの回覧案件に対していず
れの登録承認者からアクセスされたかを判別することが
できる。ここで、上記識別ＩＤは承認依頼と同時に個別
の依頼毎に与えられるので、依頼先となる承認者のメー
ルアドレスとの組をチェックすることによって、より確
実に承認者本人からのアクセスであることを確認でき
る。

【００１７】さらに、請求項６にかかる発明は、上記請
求項１〜請求項５のいずれかに記載の回覧承認システム
において、上記承認返答受付手段は上記承認依頼に対す
る返答とともに回覧案件の修正を受け付けることが可能
であり、上記回覧案件データ蓄積手段は受け付けた修正
済回覧案件の回覧案件データを蓄積する構成としてあ
る。上記のように構成した請求項６にかかる発明におい
ては、回覧案件の修正を受け付け、修正を受け付けたと
きには修正済回覧案件の回覧案件データを蓄積する。

【００１８】すなわち、承認者は、承認案件の回覧にあ
たり承認の是非のみならず回覧案件に対して修正を加え
ることもあり得る。このような場合に対応するために修
正済の回覧案件を蓄積可能に構成すれば、回覧案件に対
して種々の態様で返答を行うことが可能である。また、
回覧案件中の誤字脱字等によって回覧が妨げられるのを
防ぐことができる。さらに、元の回覧案件データを含め
修正された回覧案件データを全て蓄積しておくことによ
って、承認中の回覧案件のログとすることもでき、改竄
等がなされた場合であっても容易に経緯を調査すること
ができる。ここで、修正済回覧案件データを入手する方
法は様々であり、承認者に対して修正可能な項目を提示
し修正を入力させることによって修正済データを生成し
たり、修正済回覧案件データ自体を承認者が送信するこ
とが考えられ、種々の構成を採用可能である。

【００１９】さらに、請求項７にかかる発明は、上記請
求項１〜請求項６のいずれかに記載の回覧承認システム
において、上記承認返答受付手段は上記承認依頼に対す
る返答とともに回覧案件に対するコメントを受け付ける
ことが可能であり、上記回覧案件データ蓄積手段は受け
付けたコメントのデータを回覧案件データに対応づけて
蓄積する構成としてある。上記のように構成した請求項
７にかかる発明においては、回覧案件に対するコメント
を受け付け、コメントを受け付けたときには回覧案件デ
ータに対応づけてコメントデータを蓄積し、いずれの回
覧案件に対するコメントであるかを認識できるようにし
ている。

【００２０】すなわち、承認者は、承認案件の回覧に当
たり承認の是非や修正のみならず回覧案件に対して何ら
かのコメントを行いたい場合がある。このような場合に
対応するためにコメントのデータを蓄積可能に構成すれ
ば、回覧案件に対してコメントを付加することが可能に
なる。コメントの付加が可能になると、条件付きの承認
や否認の理由の通知等を容易に行うことができ、種々の
態様の承認返答に対応することが可能になる。

【００２１】さらに、請求項８にかかる発明は、上記請
求項１〜請求項７のいずれかに記載の回覧承認システム
において、上記承認依頼出力手段は、承認依頼を行う回
覧案件の回覧案件データを出力する構成としてある。す
なわち、承認者は承認依頼を受けた回覧案件を自己のコ
ンピュータ等によって受信し、承認内容を確認すること
ができる。従って、承認内容を確認するに当たり本シス
テムに積極的にアクセスする必要はなく、承認依頼に対
する返答を行う場合にのみアクセスすればよい。また、
承認依頼と同時に承認内容を通知することができる。

【００２２】さらに、請求項９にかかる発明は、上記請
求項８に記載の回覧承認システムにおいて、上記承認依
頼出力手段は、承認依頼に当たり修正済回覧案件の回覧
案件データのうち最新のものを出力する構成としてあ
る。すなわち、回覧案件データ蓄積手段に蓄積される回
覧案件に対して承認者が修正を加えた場合に、それ以後
の承認者に対しては修正後の回覧案件を提示することが
できる。

【００２３】さらに、請求項１０にかかる発明は、上記
請求項１〜請求項９のいずれかに記載の回覧承認システ
ムにおいて、上記承認返答受付手段は、回覧案件に対す
る承認の是非を入力させる構成としてある。すなわち、
承認者は本システムにアクセスした際に承認の是非を入
力するのみでよいことから、回覧した回覧案件データを
返信するなどの作業を行う必要が無い。

【００２４】さらに、承認内容によっては承認者の全て
から承認を受けられない場合も想定され、そのような場
合に好適な構成の一例として請求項１１にかかる発明
は、上記請求項１〜請求項１０のいずれかに記載の回覧
承認システムにおいて、上記承認返答受付手段は、承認
依頼に対して否認の返答を受け取ったときに、当該否認
の返答を必要とする者に否認された旨を通知する構成と
してある。上記のように構成した請求項１１にかかる発
明においては、承認依頼に対して否認の返答を受け取っ
たときに、当該否認の返答を必要とする者に否認された
旨を通知するので、否認された旨を遅滞なく知ることが
できる。ここで否認の返答を必要とする者は種々の者が
想定される。例えば、回覧案件を作成した者や所定の承
認を得た後に当該承認にかかる作業や仕事を実施する者
や承認依頼を行う承認管理者等が想定される。

【００２５】さらに、請求項１２にかかる発明は、上記
請求項１〜請求項１１のいずれかに記載の回覧承認シス
テムにおいて、上記承認返答受付手段は、上記承認順序
の最後の承認者から承認依頼に対して是認の返答を受け
取ったときに、当該回覧案件に対する承認を必要とする
者に回覧が終了した旨を通知する構成としてある。すな
わち、全ての承認者が承認依頼に対して是認の返答を行
ったときに、その旨が遅滞なく通知される。ここで、回
覧案件に対する承認を必要とする者は種々の者が想定さ
れる。例えば、回覧案件を作成した者や所定の承認を得
た後に当該承認にかかる作業や仕事を実施する者や承認
依頼を行う承認管理者等が想定される。

【００２６】さらに、請求項１３にかかる発明は、上記
請求項１〜請求項１２のいずれかに記載の回覧承認シス
テムにおいて、回覧の進捗状況を確認する進捗状況確認
者からのアクセスを双方向通信を介して受け付けるアク
セス受付手段と、同アクセス受付手段を介してアクセス
した進捗状況確認者に、当該アクセス時点において承認
返答待ちの承認者と蓄積されている回覧案件データとを
通知する進捗状況通知手段とを具備する構成としてあ
る。

【００２７】上記のように構成した請求項１３にかかる
発明においては、アクセス受付手段によって回覧の進捗
状況を確認する進捗状況確認者からのアクセスを双方向
通信を介して受け付け、進捗状況確認者は進捗状況通知
手段にて当該アクセス時点において承認返答待ちの承認
者と蓄積されている回覧案件データとの通知を受ける。
すなわち、本システムによって回覧されている案件の承
認進捗状況を外部からのアクセスによって確認すること
ができる。ここで、進捗状況確認者は種々の者が想定さ
れる。例えば、回覧案件を作成した者や所定の承認を得
た後に当該承認にかかる作業や仕事を実施する者や承認
依頼を行う承認管理者等が想定される。また、このよう
な回覧案件の承認依頼に対する返答を集中的に管理する
システムにおいてはシステムを構成するコンピュータで
所定のプログラムが実行され、同プログラムは上述の手
段に対応した所定の制御手順に従って処理を進めていく
上で、その根底にはその手順に発明が存在するというこ
とは当然である。従って、本発明は方法としても適用可
能であり、請求項１４にかかる発明においても、基本的
には同様の作用となる。すなわち、必ずしも実体のある
システムに限らず、その方法としても有効である。むろ
ん、請求項２〜請求項１３に記載された装置構成を当該
方法に対応させることが可能であることは言うまでもな
い。

【００２８】さらに、上述のように本システムを構成す
るコンピュータにおいては上記所定のプログラムが実行
されるので、これらのプログラムが記録された媒体とし
て発明を捉えることもできる。従って、請求項１５にか
かる発明においても、基本的には同様の作用となる。む
ろん、請求項２〜請求項１３に記載された装置構成を当
該プログラムが記録された媒体に対応させることが可能
であることは言うまでもない。ここで、コンピュータ読
み取り可能な記録媒体は、磁気記録媒体であってもよい
し光磁気記録媒体であってもよいし、今後開発されるい
かなる記録媒体においても全く同様に考えることができ
る。また、一次複製品、二次複製品などの複製段階につ
いては全く問う余地無く同等である。さらに、上記媒体
とは異なるが、供給方法として通信回線を利用して行な
う場合であれば通信回線が伝送媒体となって本発明が利
用されることになる。

【００２９】

【発明の効果】以上説明したように本発明によれば、回
覧案件を作成するに当たり少なくとも承認内容を知って
いれば回覧案件を作成でき、承認依頼に対する返答の集
中的管理によって承認中に進捗状況を容易に把握するこ
とが可能な回覧承認システムを提供することができる。
また、請求項２にかかる発明によれば、非常に簡単かつ
少ない労力で回覧案件を作成することができる。さら
に、請求項３にかかる発明によれば、全ての回覧案件に
対して承認順序を決定するような作業をしないでも承認
内容毎に承認者が異なる場合に対応することができる。

【００３０】さらに、請求項４にかかる発明によれば、
登録承認者の確認といずれの承認依頼に対する返答であ
るかの判別が容易になる。さらに、請求項５にかかる発
明によれば、正規の登録承認者であるか否かを容易に判
別することができる。さらに、請求項６にかかる発明に
よれば、回覧案件に対して種々の態様で返答を行うこと
が可能であり、回覧案件中の誤字脱字等によって回覧が
妨げられるのを防ぐことができ、容易に承認中の回覧案
件のログを作成することができる。

【００３１】さらに、請求項７にかかる発明によれば、
条件付きの承認や否認の理由の通知等を容易に行うこと
ができ、種々の態様の承認返答に対応することが可能に
なる。さらに、請求項８にかかる発明によれば、承認者
に対して簡単に承認内容を認知させることができる。さ
らに、請求項９にかかる発明によれば、修正があったと
しても容易に最新の回覧案件を提示することができる。

【００３２】さらに、請求項１０にかかる発明によれ
ば、本システムに対してアクセスすることによって容易
に承認依頼に対する返答を行うことが可能になる。さら
に、請求項１１にかかる発明によれば、回覧案件の作成
者は否認された旨を遅滞なく知ることができる。さら
に、請求項１２にかかる発明によれば、全ての承認者が
承認依頼に対して是認の返答を行ったときに、その旨が
遅滞なく通知される。さらに、請求項１３にかかる発明
によれば、回覧されている案件の承認進捗状況を外部か
らのアクセスによって確認することができる。

【００３３】さらに、請求項１４にかかる発明によれ
ば、回覧案件を作成するに当たり少なくとも承認内容を
知っていれば回覧案件を作成でき、承認依頼に対する返
答の集中的管理によって承認中に進捗状況を容易に把握
することが可能な回覧承認方法を提供することができ
る。さらに、請求項１５にかかる発明によれば、回覧案
件を作成するに当たり少なくとも承認内容を知っていれ
ば回覧案件を作成でき、承認依頼に対する返答の集中的
管理によって承認中に進捗状況を容易に把握することが
可能な回覧承認プログラムを記録した媒体を提供するこ
とができる。

【００３４】

【発明の実施の形態】以下、図面にもとづいて本発明の
実施形態を説明する。図１は、本発明の一実施形態にか
かる回覧承認システムを含むネットワークを概略図によ
り示している。本実施形態においては回覧案件の承認依
頼やその返答がサーバ４０にて集中的に管理されてお
り、回覧案件の作成者あるいは承認者はインターネット
網１０を介して回覧案件の作成や承認依頼に対する返答
を行うことができる。すなわち、図１において、インタ
ーネット網１０には種々のコンピュータが接続可能であ
り、それらの一つとして作成者クライアント２０ａ，２
０ｂや承認者クライアント３０ａ，３０ｂやサーバ４０
が接続されている。むろん、サーバ４０がインターネッ
ト網１０に接続されていることから、作成者と承認者と
は種々のネットワークからサーバ４０にアクセスするこ
とが可能である。すなわち、本実施形態においては作成
者クライアント２０ａ，２０ｂや承認者クライアント３
０ａ，３０ｂはＰＣを想定しているが、他の端末、例え
ば、携帯電話やゲーム機などであってもよい。

【００３５】図２は作成者クライアントの概略構成を示
している。同図は作成者クライアント２０ａの構成の一
例であり、作成者がインターネット網１０に接続するこ
とができる任意のコンピュータが作成者クライアント２
０ａとなり得る。同図において、作成者クライアント２
０ａは通信インタフェース（Ｉ／Ｆ）２１とハードディ
スク２３とディスプレイ２２ａと入力装置２２ｂとを備
えている。かかる構成および図示しないＣＰＵ等によっ
てオペレーティングシステム（ＯＳ）２２が実行され、
作成者がディスプレイ２２ａを視認しつつ入力装置２２
ｂで所定の入力操作を行い、ハードディスク２３に格納
された種々のアプリケーション（ＡＰＬ）を実行するこ
とが可能である。本実施形態においては当該ＡＰＬとし
て、確認用ＩＤをメールにて受信するためのメーラー２
４と所定のウェブページにアクセスしつつ必要項目を入
力することによって回覧案件を作成するブラウザ２５が
格納されている。

【００３６】また、通信Ｉ／Ｆ２１はＴＣＰ／ＩＰによ
って上記インターネット網１０にアクセスして双方向通
信を行うことが可能であり、インターネット網１０を介
して種々のデータやファイル等の授受がなされる。すな
わち、作成者は入力装置２２ｂにて所定の操作を行いメ
ーラー２４を起動することによってメールの送受信を行
うことが可能であり、メーラー２４は作成者の操作に応
じてＳＭＴＰとＰＯＰとによってインターネット網１０
を介してメールの送受信を行う。さらに、作成者は入力
装置２２ｂにて所定の操作を行うことによってブラウザ
２５を起動することが可能であり、ブラウザ２５を利用
してサーバ４０にアクセスし、同サーバ４０が出力する
案件作成画面をウェブページの一つとして閲覧すること
ができる。

【００３７】図３は承認者クライアント３０ａの概略構
成を示している。同図は承認者クライアント３０ａの構
成の一例であり、承認者がインターネット網１０に接続
することができる任意のコンピュータが承認者クライア
ント３０ａとなり得る。同図において、承認者クライア
ント３０ａは通信Ｉ／Ｆ３１とハードディスク３３とデ
ィスプレイ３２ａと入力装置３２ｂとを備えている。か
かる構成および図示しないＣＰＵ等によってＯＳ３２が
実行され、承認者がディスプレイ３２ａを視認しつつ入
力装置３２ｂで所定の入力操作を行い、ハードディスク
３３に格納された種々のＡＰＬを実行することが可能で
ある。本実施形態においては当該ＡＰＬとして、承認依
頼および識別ＩＤをメールにて受信するためのメーラー
３４と所定のウェブページにアクセスしつつ承認依頼に
対する返答等を行うブラウザ３５が格納されている。ま
た、承認依頼の際に添付される種々のファイルを開くた
めに所定のワープロソフト等種々のＡＰＬを搭載可能で
ある。

【００３８】また、通信Ｉ／Ｆ３１はＴＣＰ／ＩＰによ
って上記インターネット網１０にアクセスして双方向通
信を行うことが可能であり、インターネット網１０を介
して種々のデータやファイル等の授受がなされる。すな
わち、承認者は入力装置３２ｂにて所定の操作を行いメ
ーラー３４を起動することによってメールの送受信を行
うことが可能であり、メーラー３４は承認者の操作に応
じてＳＭＴＰとＰＯＰとによってインターネット網１０
を介してメールの送受信を行う。さらに、承認者は入力
装置３２ｂにて所定の操作を行うことによってブラウザ
３５を起動することが可能であり、ブラウザ３５を利用
してサーバ４０にアクセスし、同サーバ４０が出力する
返答入力画面をウェブページの一つとして閲覧すること
ができる。

【００３９】図４はサーバ４０の概略構成を示してい
る。同図において、サーバ４０は通信Ｉ／Ｆ４１とハー
ドディスク４３とを備えており、図示しないＣＰＵ等に
よって実行されるＯＳ４２の制御下において承認順序の
認識や承認依頼の出力、回覧案件の作成／蓄積等を実行
可能に構成される。通信Ｉ／Ｆ４１はＴＣＰ／ＩＰによ
って上記インターネット網１０にアクセスし、双方向通
信を行うことが可能であり、作成者クライアント２０ａ
や承認者クライアント３０ａにメールを送信したり、所
定のウェブページを表示させるためのｈｔｍｌファイル
５０ａを出力可能であり、作成者がウェブブラウザによ
って進捗状況を確認したり承認者が承認返答を行うこと
を可能にしている。

【００４０】ハードディスク４３には回覧承認ＡＰＬ５
０とｈｔｍｌファイル５０ａと承認データ４４と回覧案
件データ４５と作成者データ４６と案件フォームデータ
４７とが格納されており、回覧案件データ４５や作成者
データ４６等は後から追加することもできる。承認デー
タ４４としては案件種別リスト４４ａと承認者データ４
４ｂと承認者リスト４４ｃとが備えられており、これら
のデータによって承認者を特定し、また、各回覧案件に
対する承認順序を認識することが可能である。図５は案
件種別リスト４４ａの構成の一例を示している。同案件
種別リスト４４ａは回覧案件の種類と承認者リストとを
対応づけるテーブルであり、後述する回覧案件の種類毎
に、いずれの種類がいずれの承認者リストに従うべきか
が規定されている。

【００４１】図６は、承認者データ４４ｂの構成の一例
を示している。同承認者データ４４ｂは承認者を特定す
るためのデータを蓄積しているものであり、本実施形態
においては各承認者のメールアドレスが登録される。す
なわち、本システムにおいては承認者を特定し、メール
を使用して承認依頼を行うので、当該メールアドレスが
承認者を特定するとともに承認依頼の送信先をも明らか
にしている。むろん、メールアドレスを蓄積する他、承
認者の住所や会社における部署，地位等を同時に登録し
ておくこともできる。

【００４２】図７は、承認者リスト４４ｃの構成の一例
を示している。同承認者リスト４４ｃは各承認者の承認
順序が登録されており、複数のリストが存在するととも
にそれぞれにおいて承認者が承認順に記載されたテーブ
ルが構成されている。これらの承認データ４４は承認依
頼の実行時にて上記回覧承認ＡＰＬ５０に参照される。
例えば、回覧案件の種類が図５に示す「新規取引承認の
件」であれば、承認者リスト１に基づいて承認者を決定
する旨が規定されている。承認者リスト１においては図
７に示すように「承認者１，承認者２，承認者３，承認
者４．．．」として承認順序が規定されているので、ま
ず承認者１に承認依頼がなされる。このとき、承認者デ
ータ４４ｂを参照すれば「承認者１」のメールアドレス
が判明するのでかかるメールアドレスに承認依頼を送信
する。この後、承認者１から承認依頼に対する返答があ
れば、さらに「承認者２」のメールアドレスを参照して
承認依頼を送信することとなる。

【００４３】本実施形態においては、このような承認デ
ータ４４の構造によって承認者等の追加／変更時に行う
作業が低減されている。すなわち、本システムの運営に
当たり回覧案件種類，承認者，承認順序の変更は当然に
予測される。ここで、例えば、案件種類を新たに追加す
る場合は案件種別リストに当該案件を追加し、承認者リ
ストを対応づけるのみでよい。むろん、当該追加案件の
承認順序が今までにないものであるときには承認者リス
トも作成して追加する必要があるが、すでに存在する承
認者リストと同一の承認順序であれば当該承認者リスト
を対応づければよく、実質的な作業は案件種別の追加の
みである。また、既存の案件種類に対して承認順序を変
更するときでも、承認者リストの一つを変更するのみで
よい。このように、承認データ４４が案件種別リスト４
４ａ，承認者データ４４ｂ，承認者リスト４４ｃからな
る構造であることから、追加／変更時に全ての回覧案件
について全ての承認順序および承認者のメール送信先を
指定する必要が無くなっている。

【００４４】案件フォームデータ４７は回覧案件を作成
するに当たり、回覧案件の作成者に対して必要入力項目
を提示するためのデータであり、上記回覧承認ＡＰＬ５
０は同案件フォームデータ４７を参照して必要入力項目
を示す案件作成画面を表示するためのｈｔｍｌファイル
５０ａを生成する。作成者は上記ブラウザ２５にて当該
ｈｔｍｌファイル５０ａによって案件作成画面を表示さ
せ、必要入力項目に対するデータ入力を行い、回覧承認
ＡＰＬ５０はこのデータ入力に基づいて回覧案件データ
４５を作成する。また、作成者はブラウザ２５を介して
所定のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌ
ｏｃａｔｏｒ）にアクセスし、図示しない画面上で当該
作成した回覧案件についての承認依頼を行うことが可能
になっており、この承認依頼によって回覧案件データ４
５は承認者に対して送信され、承認者が回覧案件の承認
内容を視認することができる。

【００４５】図８は、上記ｈｔｍｌファイル５０ａによ
ってブラウザ２５実行下で表示される案件作成画面の一
例を示している。同図において、案件作成画面２５ａに
は最初に案件種別選択エリア２５ｂが表示されるように
なっており、同案件種別選択エリア２５ｂにて作成者所
望の案件種別を選択すると、各案件種別の必要項目入力
エリア２５ｃが表示される。同図に示す例においては、
案件種別選択エリア２５ｂにて回覧案件種類として「新
規取引承認の件」が選択されており、必要項目入力エリ
ア２５ｃにて必要入力項目「取引先，取引種類，支払条
件，登録先，作成者」が表示されている。また、必要項
目入力エリア２５ｃにおいては必要項目の入力完了を指
示する「ＯＫ」ボタンも表示されている。

【００４６】本例のように必要項目入力エリア２５ｃに
データを入力し「ＯＫ」ボタンをクリックすると、これ
らのデータは作成者クライアント２０ａからサーバ４０
に送信され、サーバ４０の回覧承認ＡＰＬ５０は受信デ
ータに基づいて図９に示すような回覧案件データ４５を
作成する。同図においては回覧案件データ４５は「新規
承認．ｄｏｃ」という名前のファイル名であり、「Ｍｉ
ｃｒｏｓｏｆｔ Ｗｏｒｄ」で開くことのできるファイ
ルである。このファイル生成に当たっては、ｄｏｃファ
イルに記載する文言の一部は定型化されており、上記受
信したデータ内容を所定位置に追加することによって回
覧案件データを生成する。

【００４７】例えば、上記図８では案件種別選択エリア
２５ｂにて「新規取引承認の件」が選択されており、こ
の選択に基づいて図９の回覧案件文書４５ａの標題に
「新規取引承認の件」と記載する。さらに、当該回覧案
件文書４５ａにて「今般、ａと新規に取引を開始するに
当たり、下記のとおり承認を求めます。」という定型文
が用意されており、上記必要項目入力エリア２５ｃの
「取引先」項目の「名称」に入力された「××株式会
社」というデータに基づいて当該定型文の「ａ」部分に
「××株式会社」という文言を挿入する。以下、同様に
して上記必要項目入力エリア２５ｃに入力されたデータ
に基づいて回覧案件文書の文言を作成し、上記回覧案件
データ４５として「新規承認．ｄｏｃ」というファイル
を作成、蓄積することとなる。

【００４８】尚、本実施形態において、上記回覧案件の
作成者のメールアドレスは予め作成者データ４６として
ハードディスク４３に格納されており、同メールアドレ
スによって適正な作成者であるか否かが確認されるよう
になっている。また、同作成者は自己が作成した回覧案
件の承認依頼中にその進捗状況を確認することが可能に
なっており、確認に当たり当該作成者であるか否かを識
別するための確認用ＩＤが各案件毎に付与されるように
なっており、上記メールアドレスに対して送信して同確
認用ＩＤが通知される。

【００４９】回覧承認ＡＰＬ５０はさらに、このように
してハードディスク４３に格納された承認データ４４や
回覧案件データ４５等に基づいて回覧承認に対する承認
依頼を行ったり、承認依頼に対する返答を受け付けた
り、進捗状況の確認を受け付けたりする。図１０は同回
覧承認ＡＰＬ５０の構成を示すブロック図である。同図
において、回覧承認ＡＰＬ５０は上述のようにして回覧
案件の作成を司る回覧案件作成部と承認依頼を司る承認
依頼処理部と進捗状況の確認を司る進捗状況確認部とか
ら構成されている。承認依頼出力部５１は上記承認デー
タ４４を参照して承認順序を判断するとともに、該当す
る順序の承認者のメールアドレスを送信先として上記回
覧案件データ４５を添付したメールを送信する。また、
このメールには承認依頼毎の識別ＩＤが記載されるとと
もに、承認者の便宜を図るために承認依頼に対する返答
を行う際のアクセス先を示すＵＲＬが記載される。この
ＵＲＬは承認者の便宜を図るために念のため記載される
ものであり、むろん単一のＵＲＬを使用する実施形態で
あってＵＲＬが自明な場合にまでＵＲＬの記載を必要と
するわけではない。

【００５０】図１１はかかるメールの一例を示してお
り、承認者クライアント３０ａを利用する承認者はメー
ラー３４を介して受信メッセージ３４ａに示すようなメ
ールを受信する。本例においては識別ＩＤが「１２３４
５」であり、ＵＲＬが「ｈｔｔｐ：／／ｓｅｒｖｅ
ｒ．．．」である。同図において受信メッセージ３４ａ
のサブジェクトは「承認依頼の件」となっており、承認
者はこのサブジェクトによって自己に対して承認依頼が
なされていることを認識する。そして、承認者は添付フ
ァイルである「新規承認．ｄｏｃ」を開き、承認内容を
確認した上で承認依頼に対する返答を行う。承認依頼に
対する返答を行う時にはブラウザ３５を起動し、上記Ｕ
ＲＬにアクセスする。

【００５１】このような承認者からのアクセスは上記回
覧承認ＡＰＬ５０の登録承認者判別部５２が受け付ける
ようになっており、承認者データ４４ｂに基づいてアク
セスした者が登録承認者であるか否かを判別する。すな
わち、上記識別ＩＤは承認依頼毎に付与されるため各回
覧案件毎および承認者毎にユニークである。そこで、当
該識別ＩＤ「１２３４５」と承認者のメールアドレスの
組が適正であるか否かによって登録承認者であるか否か
を判別する。さらに、識別ＩＤ「１２３４５」のみによ
っていずれの回覧案件に対する返答であるか否かも判別
される。

【００５２】登録承認者であることが判別されると、承
認返答受付部５３は返答入力画面用のｈｔｍｌファイル
５０ａを作成し、上記ブラウザ３５にて図１２に示すよ
うな返答入力画面３５ａを表示させる。ここで、上述の
ように識別ＩＤによっていずれかの回覧案件であるかが
判別しているので対象となっている案件の標題も併せて
表示される。この返答入力画面３５ａにおいては、「是
認」，「否認」，「修正」を選択するためのチェックボ
ックスが用意されており、いずれかにチェックを入れて
「実行」ボタンをクリックすると選択内容が承認返答受
付部５３にて受け付けられる。

【００５３】また、「承認」チェックボックスの下には
「コメント入力」を行うためのチェックボックスが設け
られており、上記「是認」，「否認」，「修正」のいず
れかをチェックした状態で「コメント入力」にチェック
を入れると、コメント入力ボックス３５ｂにコメントを
入力することができる。かかる場合には当該コメント内
容も併せて上記承認返答受付部５３にて受け付けられ
る。同承認返答受付部５３は「是認」を受け付けると次
の承認順序の承認者に対する承認依頼を実行し、「否
認」受け付けるとその旨を作成者に通知し、「修正」を
受け付けると修正にかかる回覧案件データを蓄積して次
の承認順序の承認者に対する承認依頼を実行する。ま
た、「コメント入力」を受け付けている場合には、コメ
ントが付された回覧案件データにコメントデータを付加
して蓄積する。従って、「是認」を行うにしても「条件
付きでの是認」を行うことができるし、「否認」あるい
は「修正」を行うにしてもその理由を明確にできる。ま
た、内容を大幅に変更したい場合に変更内容をコメント
にすることもできる。

【００５４】一方、図１０の進捗状況確認部は作成者か
らのアクセスに応じて承認依頼の進捗状況を通知する。
同図においてアクセス受付部５４は、上記作成者が作成
者クライアント２０ａのブラウザ２５を起動しつつ行う
アクセスを受け付ける。ここで、上記承認者の確認と同
様に作成者データ４６に基づいて作成者のメールアドレ
スと上記確認用ＩＤとの組によって登録作成者であるか
否かを判別する。かかる判別によって登録作成者である
と認められると、進捗状況通知部５５は確認用ＩＤに基
づいて当該確認依頼のあった回覧案件はいずれであるか
を判別し、当該回覧案件の進捗状況確認画面用のｈｔｍ
ｌファイル５０ａを作成し、上記ブラウザ３５にて図１
３に示すような進捗状況確認画面２５ｄを表示させる。
尚、確認用ＩＤは各案件毎に付与されるので同ＩＤにて
案件をも判別することができる。

【００５５】同進捗状況確認画面２５ｄにおいては、当
該回覧案件の承認者が承認順序に従って上から記載され
ており、承認者ステータス表示エリア２５ｅにおいては
各承認者についてのステータスが「是認」，「検討
中」，「未検討」などと記載されている。ここで、「検
討中」は現在承認依頼に対する返答待ち、すなわち、サ
ーバ４０が承認依頼をメールで送信したが、まだ承認返
答のアクセスを受け取っていない承認者である。また、
承認者ステータス表示エリア２５ｅの下部は、回覧案件
表示エリア２５ｆであり、現在の回覧案件、すなわち、
回覧案件データ４５として蓄積されたもののうち、最新
のものの内容を表示するようになっている。さらに、当
該回覧案件について上記コメントデータが付加されてい
るときには、同回覧案件表示エリア２５ｆに当該コメン
ト内容が表示される。尚、本実施形態においては上述の
回覧承認ＡＰＬ５０の各部が上記クレームの各手段に対
応しており、また、承認データ４４と回覧案件データ４
５とが蓄積されるハードディスク４３が上記クレームの
回覧案件データ蓄積手段と承認データ蓄積手段を構成し
ている。

【００５６】以下、上記構成における本システムの処理
フローを説明する。図１４はサーバ４０にて常時起動さ
れる回覧承認ＡＰＬ５０のフローチャートである。同図
ステップＳ１００においてサーバ４０は外部コンピュー
タがブラウザを利用してインターネット網１０を介して
アクセスすることを待機しており、これらのアクセスは
各外部コンピュータが所定のＵＲＬを指定したり、予め
張られたリンクを使用するなどして行うものである。ス
テップＳ１１０，Ｓ１３０においては、このアクセス時
に指定されたＵＲＬによって対応する処理を行うように
なっており、回覧案件の作成である場合にはステップＳ
１１０の判別を経てステップＳ１２０の回覧案件作成処
理を実行する。この回覧案件作成処理は上記回覧承認Ａ
ＰＬの回覧案件作成部によって実行される処理であり、
作成者クライアント２０ａを介して作成者が行う処理に
応じて回覧案件を作成する。

【００５７】さらに、アクセス時に指定されたＵＲＬが
承認依頼のものである場合であって、回覧案件の承認依
頼が実行されたと判別されたときには、ステップＳ１４
０にて上記承認依頼出力部５１が承認者リストの最初の
者から順に承認依頼出力処理を行う。ステップＳ１５０
においては、登録承認者判別部５２とアクセス受付部５
４が承認依頼に対する返答と進捗状況の受付を行うため
に外部コンピュータからのアクセスを待ち受けており、
アクセス内容に応じて承認返答受付部５３と進捗状況通
知部５５とが対応する処理を行い、ステップＳ１６０に
て上記承認者リストの全員が返答を終了したと判別され
るまで上記ステップＳ１４０以降の処理を繰り返す。ス
テップＳ１６０にて承認者リストの全員が返答を終了し
たと判別されると、承認返答受付部５３がステップＳ１
７０にて当該回覧案件の作成者に対して回覧が完了した
旨のメールを送信する。尚、上記コメントが付加されて
いるときには当該メールに同コメント内容が記載され、
条件付き承認がなされた場合であっても作成者はその旨
を知ることができる。また、本実施形態においては上記
ステップＳ１００や後述するステップＳ４００にて各処
理毎のＵＲＬに対するアクセスを受け付けているが、む
ろん、外部からのアクセスを単一のＵＲＬにて受け付
け、同単一のＵＲＬにて表示する画面にて適宜承認返答
や進捗状況確認等の処理に移行するように構成すること
もできる。

【００５８】図１５は上記ステップＳ１２０の回覧案件
作成処理を示している。同回覧案件作成処理において
は、ステップＳ２００で上記作成者クライアント２０ａ
のブラウザ２５において図示しない入力画面を表示し、
作成者に自己のメールアドレスを入力させる。当該入力
によってメールアドレスのデータをサーバ４０が受信す
ると、ステップＳ２１０にて上記作成者データ４６を参
照して受信したメールアドレスがすでに作成者データ４
６に登録済であるか否かを判別する。同ステップＳ２１
０にてメールアドレスが作成者データ４６に登録済であ
ると判別されないときには、ステップＳ２２０にて上記
ブラウザ２５にて視認可能にエラーメッセージを表示さ
せる。ステップＳ２１０にてメールアドレスが作成者デ
ータ４６に登録済であると判別されたときには、ステッ
プＳ２３０にて上記案件フォームデータ４７を参照す
る。

【００５９】ステップＳ２４０では、同案件フォームデ
ータ４７に基づいて上記図８に示すような案件作成画面
２５ａを表示するとともに、ブラウザ２５を介して作成
者が必要項目にデータを入力することを受け付ける。こ
のとき、上記案件種別に応じた必要項目を表示させつつ
ステップＳ２５０にて必要項目の全てが入力されて「Ｏ
Ｋ」ボタンがクリックされたか否かを判別しており、同
ステップＳ２５０にて「ＯＫ」ボタンがクリックされた
と判別されるまでステップＳ２４０以降の処理を繰り返
す。ステップＳ２５０にて「ＯＫ」ボタンがクリックさ
れたと判別したときには、ステップＳ２６０にて上記案
件作成画面２５ａに入力されているデータに基づいて上
記図９に示すような回覧案件データ４５を生成し、上記
ハードディスク４３に蓄積する。また、ステップＳ２７
０では、作成者が進捗状況を確認する際に使用する確認
用ＩＤを当該案件に対して付与し、ステップＳ２８０に
て確認用ＩＤを明示したメールを上記作成者クライアン
ト２０ａに対して送信する。ここで、送信先のメールア
ドレスは上記作成者データ４６に登録されており、同デ
ータが参照される。また、確認用ＩＤは当該作成者のメ
ールアドレスと組でハードディスク４３に蓄積される。

【００６０】図１６は上記ステップＳ１４０の承認依頼
出力処理を示している。同図においては、ステップＳ３
００にて承認依頼毎の識別ＩＤを付与する。ここで、承
認依頼毎というのは上述のように回覧案件毎、承認者毎
にということであり、上記ステップＳ１４０〜Ｓ１６０
のループにおいてステップＳ３００が実行されることに
よって、同じ回覧案件でも異なる承認者に対しては異な
る識別ＩＤが与えられる。また、同ステップＳ３００に
おいては、当該識別ＩＤがどの回覧案件でどの承認者に
与えられたかを認識可能にするべく、承認者データと識
別ＩＤとを組にして承認データ４４として蓄積される。
ステップＳ３１０では、承認順序を把握するためにまず
上記案件種別リスト４４ａを参照し、当該承認依頼にか
かる回覧案件の標題からいずれの承認者リストを参照す
べきであるかを認識する。

【００６１】承認者リストが判明すると、ステップＳ３
２０にて当該承認者リストを参照し、ステップＳ３３０
にて承認者の順序を確認する。このステップＳ３３０が
始めて実行された時にはむろん承認者リストの先頭の承
認者の順番である旨が確認されるし、後述するステップ
Ｓ１５０の処理によってステップＳ１４０〜Ｓ１６０の
ループが繰り返される毎に、承認者の順番は一人ずつ承
認者リスト中の後の承認者へと繰り下がるようになって
いる。同ステップＳ３３０にて順序が確認されるとステ
ップＳ３４０にて承認者データ４４ｂを参照し、当該承
認者のメールアドレスを確認する。そして、ステップＳ
３５０にて同確認した承認者のメールアドレスを宛先と
し、上記回覧案件データ４５のうち最新のものを添付
し、上記図１１のように上記ステップＳ３００で付与し
た識別ＩＤとＵＲＬを明記してメールを送信する。

【００６２】図１７は上記ステップＳ１５０のアクセス
受付処理を示している。同アクセス受付処理において
は、ステップＳ４００にて所定のＵＲＬに対する外部コ
ンピュータからのアクセスを受け付けており、図示しな
い入力画面を表示して「進捗状況の確認」と「承認依頼
に対する返答」とのいずれかの処理を選択させる。ステ
ップＳ４０５では当該アクセス時の選択内容を判別して
おり、上記作成者クライアント２０ａのブラウザ２５か
らのアクセスによって同ステップＳ４０５にて「進捗状
況の確認」が選択されたことを判別したときにはステッ
プＳ４１０の進捗状況確認処理を実行する。上記承認者
クライアント３０ａのブラウザ３５からのアクセスによ
ってステップＳ４０５にて「承認依頼に対する返答」が
選択されたことを判別したときにはステップＳ４１５に
てさらに図示しない入力画面を表示し、上記ステップＳ
３００にて付与した識別ＩＤと当該承認者のメールアド
レスを入力させる。

【００６３】この識別ＩＤとメールアドレスとを受け付
けると、ステップＳ４２０において上記承認データ４４
を参照し、上記ステップＳ３００にて蓄積された識別Ｉ
Ｄと承認者のメールアドレスとの組と、当該ステップＳ
４１５にて入力された識別ＩＤとメールアドレスとの組
が一致するか否かを判別する。同ステップＳ４２０にて
識別ＩＤとメールアドレスとの組が正しいと判別されな
いときには、ステップＳ４２５にて上記ブラウザ３５に
て視認可能にエラーメッセージを表示させる。ステップ
Ｓ４２０にて識別ＩＤとメールアドレスとの組が正しい
と判別された時には、ステップＳ４３０にて当該識別Ｉ
Ｄから回覧案件を認識する。そして、ステップＳ４３５
にて図１２に示す返答入力画面３５ａを表示し、当該回
覧案件に対する返答を入力させる。

【００６４】ステップＳ４３７においては、承認者が同
返答入力画面３５ａにて「コメント入力」をチェックし
たか否かを判別しており、同ステップＳ４３７にて「コ
メント入力」がチェックされていたと判別したときに
は、ステップＳ４３８にて上記コメント入力ボックス３
５ｂに入力されている内容のコメントデータをこの時点
の回覧案件データに対応づけて蓄積する。さらに、ステ
ップＳ４４０においては、承認者が上記返答入力画面３
５ａにていずれの返答を入力したか判別しており、同ス
テップＳ４４０にて「是認」が入力されたと判別したと
きには、ステップＳ４５０にて上記承認者リスト４４ｃ
中の承認者を次の順番の承認者へと繰り下げる。すなわ
ち、この処理の後に上記図１４に示すループに戻ってス
テップＳ１４０以降の処理を繰り返すことにより、ある
承認者の返答を受信してから次の承認者に対する承認依
頼を行うこととなる。上記ステップＳ４４０にて「否
認」が入力されたと判別したときには、ステップＳ４４
５にて上記作成者データ４６を参照し、当該回覧案件が
「否認」された旨を作成者にメールで送信する。作成者
は作成者クライアント２０ａのメーラー２４を介して当
該メールを開封することによって当該回覧案件が「否
認」された旨を遅滞なく知ることができる。尚、この時
点で上記コメントデータが蓄積されているときには、当
該コメント内容が当該メールに記載されて送信される。

【００６５】一方、上記ステップＳ４４０にて「修正」
が入力されたと判別したときには、承認者が入力する回
覧案件の修正を受け付ける。このため、ステップＳ４５
５においては、案件フォームデータ４７を参照し、ステ
ップＳ４６０において上記図８と略同内容の修正入力画
面を表示する。この画面においては、案件種別選択エリ
ア２５ｂと同様な画面によって案件種別を選択させ、さ
らに必要項目入力エリア２５ｃと同様な画面によって修
正事項を入力させる。ただし、この画面においては修正
事項のみの入力で十分であることから、表示項目のうち
一つ以上の項目にデータを入力し「ＯＫ」ボタンをクリ
ックすればよい。

【００６６】ステップＳ４６５では「ＯＫ」ボタンがク
リックされたか否かを判別しており、同ステップＳ４６
５にて「ＯＫ」ボタンがクリックされたと判別されたと
きには、ステップＳ４７０にて上記修正入力画面にて入
力されている修正データに基づいて上記図９に示すよう
な「新規承認．ｄｏｃ」というファイルを一部修正し、
新たな「新規承認１．ｄｏｃ」というファイルとして上
記ハードディスク４３に蓄積する。この後、ステップＳ
４５０以降の処理が実施されることによって、当該承認
者は上記修正を行った上で「是認」をしたということと
なる。尚、このように「修正」が選択された場合であっ
て上記ステップＳ４３８にてコメントデータを蓄積して
いるときには、当該蓄積したコメントデータを当該修正
済の「新規承認１．ｄｏｃ」というファイルに対応づけ
る。

【００６７】図１８は上記ステップＳ４１０の進捗状況
確認処理を示している。同進捗状況確認処理において
は、上記作成者クライアント２０ａのブラウザ２５から
のアクセスによって上記ステップＳ４０５にて「進捗状
況の確認」が選択されたと判別したことに続いて、ステ
ップＳ５００にてさらに図示しない入力画面を表示し、
上記ステップＳ２７０にて付与した確認用ＩＤと当該作
成者のメールアドレスを入力させる。この確認用ＩＤと
作成者のメールアドレスとを受け付けると、ステップＳ
５１０において上記作成者データ４６を参照し、上記ス
テップＳ２７０にて蓄積された確認用ＩＤと作成者のメ
ールアドレスとの組と、当該ステップＳ５００にて入力
された確認用ＩＤとメールアドレスとの組が一致するか
否かを判別する。

【００６８】同ステップＳ５１０にて確認用ＩＤとメー
ルアドレスとの組が正しいと判別されないときには、ス
テップＳ５２０にて上記ブラウザ２５にて視認可能にエ
ラーメッセージを表示させる。ステップＳ５１０にて確
認用ＩＤとメールアドレスとの組が正しいと判別された
時には、ステップＳ５３０にて当該確認用ＩＤから回覧
案件を認識し、図１３に示す進捗状況確認画面２５ｄを
表示し、当該回覧案件にの進捗状況を作成者に認識させ
る。

【００６９】以下、上記構成およびフローチャートにお
いて実現される本発明の動作を説明する。本発明におい
て回覧案件の承認依頼を行うには、まず作成者が回覧案
件を作成する必要がある。この前提として、作成者はサ
ーバ４０の作成者データ４６に自己のメールアドレスを
予め登録しておく。また、承認者も予め決められてお
り、承認者データ４４ｂにそのメールアドレスが登録さ
れる。さらに、承認順序も決められており、案件種別リ
スト４４ａと承認者リスト４４ｃとも登録されている。
かかる状況において作成者は作成者クライアント２０ａ
の入力装置２２ｂ等を操作してブラウザ２５を起動し、
通信Ｉ／Ｆ２１，インターネット網１０を介してサーバ
４０にアクセスする。

【００７０】このとき、サーバ４０はステップＳ１１０
の判別を経てステップＳ１２０の回覧案件作成処理を行
う。ここで、作成者はサーバ４０のステップＳ２００の
処理においてメールアドレスの入力を促されるので、ブ
ラウザ２５の表示画面を視認しつつ入力装置２２ｂにて
自己のメールアドレスを入力する。このメールアドレス
のデータがブラウザ２５の処理によってサーバ４０に送
信されると、サーバ４０はステップＳ２１０において当
該メールアドレスが上記作成者データ４６として登録済
であるか否かを判別する。ステップＳ２１０においてメ
ールアドレスが登録済であると判別されると、ステップ
Ｓ２３０，Ｓ２４０の処理によって所定のｈｔｍｌファ
イル５０ａが生成され、作成者はブラウザ２５において
図８に示す案件作成画面を視認する。

【００７１】作成者が図８に示すように案件種別選択エ
リア２５ｂにおいて「新規取引承認の件」を選択する
と、当該選択を示すデータがサーバ４０に送信され、さ
らに、必要項目入力エリア２５ｃに図８に示すような
「新規取引承認の件」を作成する際に必要となる入力項
目が表示される。作成者が入力装置２２ｂを使用してブ
ラウザ２５の表示画面たる案件作成画面２５ａにて「取
引先」の「名称」に「××株式会社」，住所に「○○県
○○市」等と入力していき、「ＯＫ」ボタンをクリック
すると、各入力項目のデータがサーバ４０に対して送信
される。この結果、サーバ４０は図９に示すような「新
規承認．ｄｏｃ」ファイルを作成し、回覧案件データ４
５としてハードディスク４３に蓄積する。この後、サー
バ４０はステップＳ２７０にて確認用ＩＤを付与し、メ
ールにて送信するので、作成者が作成者クライアント２
０ａのメーラー２４にて当該メールを受信して開封する
と、作成者は確認用ＩＤを認識することができる。

【００７２】このようにして回覧案件を作成／蓄積する
と、当該回覧案件の承認依頼を行うことができる。ここ
で、回覧案件に対する承認順序や承認者は予め上記承認
データ４４として格納されたデータによって案件種別毎
に規定されているので、作成者は承認順序や承認者を指
定する必要はない。作成者が上記ブラウザ２５において
サーバ４０にアクセスし、当該回覧案件「新規承認．ｄ
ｏｃ」に対する承認依頼を実行すると、サーバ４０にお
いてはステップＳ１３０の判別を経てステップＳ１４０
の承認依頼出力処理を実行する。同承認来出力処理にお
いてはステップＳ３００にて識別ＩＤを付与し、「新規
承認．ｄｏｃ」の標題から案件種別を把握するとともに
ステップＳ３１０〜Ｓ３３０の処理にて承認順序を把握
する。そして、ステップＳ３４０にて送信先を把握する
とともにステップＳ３５０にて当該承認順序の承認者に
対して図１１に示すようなメールを送信する。

【００７３】承認者は承認者クライアントのメーラー３
４によってメールを受信した旨を認識し、当該受信メー
ルのサブジェクトによって自己に対して承認依頼がなさ
れた旨を認識する。承認者がメーラー３４にて受信メー
ルを開封するとその内容から自己に付与された識別ＩＤ
と承認返答用のＵＲＬを知ることができる。さらに、当
該メールには回覧案件を表示するための「新規承認．ｄ
ｏｃ」ファイルが添付されているので、同「新規承認．
ｄｏｃ」ファイルを開くことによって当該承認者は承認
内容を知ることができる。承認者は同「新規承認．ｄｏ
ｃ」ファイルの承認内容を検討した上で、その承認を行
うために入力装置３２ｂ等によってブラウザ３５を起動
し、上記ＵＲＬにアクセスする。

【００７４】サーバ４０は当該承認者からのアクセスを
ステップＳ１５０のアクセス受付処理にて受け付けてお
り、ステップＳ４００にて図示しない画面によって「進
捗状況の確認」と「承認依頼に対する返答」とのいずれ
かの処理を選択させる。承認者がブラウザ３５を視認し
つつ入力装置３２ｂによって「承認依頼に対する返答」
を選択すると、当該選択を示すデータがサーバ４０に送
信され、サーバ４０はステップＳ４１５にて図示しない
入力画面にて識別ＩＤとメールアドレスとを入力させ
る。図１１に示すメールを受け取った承認者は、当該入
力画面にて識別ＩＤ「１２３４５」とメールアドレス
「ａｐｐｒｏｖａｌ１＠＊＊＊＊．ｎｅ．ｊｐ」を入力
する。

【００７５】これらの入力データはブラウザ３５の処理
によってサーバ４０に送信され、サーバ４０はステップ
Ｓ４２０にてこれらの組が正しいことを判別する。その
結果、ステップＳ４３０にて識別ＩＤに基づいて当該返
答が上記「新規承認．ｄｏｃ」に対するものであると認
識し、ステップＳ４３０にて図１２に示す返答入力画面
３５ａを表示する。承認者がブラウザ３５にて当該返答
入力画面を視認して「是認」である旨を選択すると、ス
テップＳ４５０にて承認者リストの順序が繰り下げら
れ、ステップＳ１４０以降の処理を繰り返す。このよう
にしてステップＳ１４０〜Ｓ１６０のループを実行し、
承認者リストに記載された全ての承認者から「是認」の
返答を受けると、ステップＳ１７０にて作成者データを
参照し、当該「新規承認．ｄｏｃ」に対する回覧が終了
した旨のメールを作成者に対して送信する。作成者が作
成者クライアント２０ａのメーラー２４にて当該メール
を開封すると、同メールに回覧案件の承認が完了した旨
が記載されているので、作成者は回覧完了を遅滞なく知
ることができる。

【００７６】一方、承認者が「新規承認．ｄｏｃ」に対
して修正を加えた上で「是認」する場合には、上記ステ
ップＳ４３５の処理において承認者は承認者クライアン
ト３０ａのブラウザ３５を視認しつつ「修正」をする旨
を選択する。この結果、ステップＳ４５５，Ｓ４６０の
処理によってブラウザ３５の画面が上記図８と略同様の
修正入力画面に切り替わる。そこで、承認者が所望の項
目に対して例えば、支払条件の支払日を「翌月１５日」
に修正するなどして「ＯＫ」ボタンをクリックする。そ
の結果、図９に示す「新規承認．ｄｏｃ」ファイルの支
払日が「翌月１５日」に修正された「新規承認１．ｄｏ
ｃ」ファイルが蓄積され、当該修正後に本案件を「是
認」したとしてステップＳ４５０以降の処理を実行す
る。

【００７７】これ以後は、上記ステップＳ３５０におい
てこの修正された「新規承認１．ｄｏｃ」ファイルを添
付して承認依頼を行うようになる。さらに、いずれかの
承認者が上記ステップＳ４３５の処理においてブラウザ
３５を視認しつつ「否認」をする旨を選択すると、サー
バ４０はステップＳ４４５にて作成者に対して否認され
た旨のメールを送信する。従って、作成者は作成者クラ
イアント２０ａのメーラー２４にて当該メールを開封す
ることにより、自己が作成した回覧案件が「否認」され
た旨を遅滞なく知ることができる。

【００７８】作成者はこのようにして承認依頼をし、承
認の完了あるいは否認の旨の返答を待ち受けている状態
において、いつでもその進捗状況を確認することができ
る。このためには、作成者は作成者クライアント２０ａ
にて入力装置２２ｂを使用してブラウザ２５を起動し、
サーバ４０にアクセスする。サーバ４０は当該承認者か
らのアクセスをステップＳ１５０のアクセス受付処理に
て受け付けており、ステップＳ４００にて図示しない画
面によって「進捗状況の確認」と「承認依頼に対する返
答」とのいずれかの処理を選択させる。作成者がブラウ
ザ２５を視認しつつ入力装置２２ｂによって「進捗状況
の確認」を選択すると、当該選択を示すデータがサーバ
４０に送信され、サーバ４０はステップＳ４１０の進捗
状況確認処理を行う。

【００７９】すなわち、続いてブラウザ２５にて図示し
ない入力画面を表示させ、確認用ＩＤとメールアドレス
とを入力させる。作成者が回覧案件の作成後に受け取っ
た確認用ＩＤと自己のメールアドレスを入力すると、こ
れらの入力データはブラウザ２５の処理によってサーバ
４０に送信され、サーバ４０はステップＳ５１０にてこ
れらの組が正しいことを判別する。その結果、ステップ
Ｓ５３０にて確認用ＩＤに基づいて当該確認が上記「新
規承認．ｄｏｃ」に対するものであると認識し、ステッ
プＳ５３０にて図１３に示す進捗状況確認画面２５ｄを
表示する。この結果、承認者３が現在検討中であること
を知ることができ、さらに、現在の回覧案件を視認する
ことによって回覧案件に修正があった場合にはその修正
事項も知ることができる。このステップＳ５３０におい
ては、上記ステップＳ４３８にて入力されたコメントが
ある場合に当該コメントも表示する。従って、回覧案件
について条件付き承認がなされた場合等にその条件を認
識することができる。

【００８０】以上説明したように、本発明においては承
認データ４４にて案件種別リスト４４ａと承認者データ
４４ｂと承認者リスト４４ｃとを蓄積し、これらのデー
タを参照して各案件別の承認順序とその承認者のメール
送信先を判別しているが、承認データにおいては所定の
回覧案件に対する承認順序とその承認者とを特定するこ
とができればよく、必ずしもかかる構成に限られること
はない。例えば、各社員の部署等を明示したテーブルを
作成し、当該テーブルにおいて承認資格の有無を明示し
て、当該承認資格を有するもののうちテーブルに記載さ
れた順番に承認依頼を行うことなどが可能である。

【００８１】また、上述のように承認に当たり回覧案件
を修正する資格も修正資格としてテーブルに記載するこ
とによって、承認者の一部のみが修正を行うことができ
るように構成することもできる。さらに、通常の会社に
おいては各社員は何らかの部署に配属されるとともにそ
れぞれに役職があり、いずれの社員が承認を与えるのか
はその役職によって決定されることも多い。そこで、所
定の役職以上の者を承認者あるいは修正資格を有する承
認者とすることもできる。この場合、すでに社員名簿を
データ化して蓄積しているような会社は、当該名簿のデ
ータを本システムに流用することができて好適である。

【００８２】また、上記実施形態においては作成者が回
覧案件を作成するに当たり、必要入力項目を入力するよ
うに構成していた。かかる構成においては、回覧案件の
作成に当たり必要最低限の項目を入力するのみで足りる
点で、回覧案件作成に不慣れな作成者であっても簡単に
案件を作成できて好適であるが、他の構成を採用するこ
とも可能である。例えば、上記回覧案件の作成に当たり
上記図９に示すような回覧案件の雛形を表示し、作成者
がブラウザ画面上で所定の位置をクリックすることによ
って当該クリック位置の文面を修正可能に構成し、かか
る修正後の内容を回覧案件データとして蓄積することも
できる。

【００８３】このような場合、上記雛形の修正に先立っ
てアクセス時には作成者を特定するために部署名・氏名
・メールアドレス等を入力して、サーバヘのアクセスを
完了し、順次選択項目を表示して最終的に図９に示す雛
形を表示するように構成すると、案件作成を簡単に行う
ことができて好適である。すなわち、作成すべき回覧案
件の案件種類を画面上に一覧表示し、作成者が所望の案
件種類をクリックすることにより上記図９に示すような
回覧案件の雛形が表示されるようにすると容易に回覧案
件を選択できる。

【００８４】さらに、案件種類の一覧表示においては選
択可能な案件種類の全てを一度に表示する必要があるわ
けではなく、階層的に表示すればより便利である。すな
わち、案件種類の選択においては回覧案件データ４５の
保存してあるフォルダを視認できるように構成すれば案
件種類を階層的に表示することができる。この階層表示
においては、例えば、回覧案件をまず「承認文書」，
「依頼書」，「稟議書」，「掲示文書」等の大きな分類
で分けるとともに対応する「承認文書フォルダ」等のフ
ォルダを作成し、これらのフォルダの中に「新規取引契
約の締結に関する承認の件」，「新規設備投資に関する
承認の件」等といった個別の承認案件の雛形ファイルを
保存する。そして、かかるフォルダをブラウザにて視認
可能にすれば、作成者は自己の作成したい回覧案件を素
早く見つけることができる。

【００８５】また、上述のようにアクセス時に入力した
部署名等によってより利便性の高いインタフェースを提
供することもできる。すなわち、作成者によっては特定
種類の回覧案件しか作成しない場合もあり、かかる場合
に案件種類の全てを表示するのは煩雑である。そこで、
上記入力された作成者の部署および氏名によって選択可
能な案件種別を限定すると好適である。さらに、これら
の部署名・氏名等のデータは、入力された雛形の表示に
当たり前もって雛形に挿入し、図９の下部に示すような
署名等を入力する必要がないように構成すると好適であ
る。

【００８６】さらに、上述の実施形態においては承認依
頼に対して「否認」がなされた場合および回覧完了時に
その旨を回覧案件の作成者に対して通知していたが、こ
の通知相手は必ずしも作成者である必要はない。例え
ば、ある部署に新規プロジェクト開始の依頼等を行うた
めにその依頼書を回覧承認した場合、回覧完了時には当
該依頼先の部署に回覧案件を転送すると好適であるし、
上司の命令によって部下が稟議書を作成した場合であっ
て、その稟議結果を当該上司に伝達する必要がある場合
には「否認」と回覧完了時にはその旨を上司に対して通
知するように構成すると好適である。さらに、上述の実
施形態においては作成者が進捗状況を確認するように構
成していたが、かかる確認者も作成者に限られず上司や
依頼先等種々の者が実行可能に構成することができる。

【００８７】以上説明したように、本発明においては回
覧案件データと承認者登録データと承認順序データとを
蓄積し、回覧案件データに対する承認依頼を行って当該
承認依頼に対する返答を承認者から受け取るという処理
を同承認順序データに基づいて所定の承認順序で行う。
ここで、承認順序は予め登録されており、回覧案件を作
成するに当たり少なくとも承認内容を知っていれば回覧
案件を作成可能である。また、承認依頼と返答を集中的
に管理することから、承認中に進捗状況を容易に把握す
ることが可能である。

【図面の簡単な説明】

【図１】本発明の一実施形態にかかる回覧承認システム
を含むネットワーク構成の概略図である。

【図２】作成者クライアントの概略構成図である。

【図３】承認者クライアントの概略構成図である。

【図４】サーバの概略構成図である。

【図５】案件種別リストの一例を示す図である。

【図６】承認者データの一例を示す図である。

【図７】承認者リストの一例を示す図である。

【図８】案件作成画面の一例を示す図である。

【図９】回覧案件データの一例を示す図である。

【図１０】回覧承認ＡＰＬの構成を示すブロック図であ
る。

【図１１】承認依頼時に送信されるメールの一例を示す
図である。

【図１２】返答入力画面の一例を示す図である。

【図１３】進捗状況確認画面の一例を示す図である。

【図１４】回覧承認ＡＰＬのフローチャートである。

【図１５】回覧案件作成処理のフローチャートである。

【図１６】承認依頼出力処理のフローチャートである。

【図１７】アクセス受付処理のフローチャートである。

【図１８】進捗状況確認処理のフローチャートである。

【符号の説明】

１０…インターネット網 ２０ａ，２０ｂ…作成者クライアント ２１…通信Ｉ／Ｆ ２２…オペレーティングシステム（ＯＳ） ２２ａ…ディスプレイ ２２ｂ…入力装置 ２３…ハードディスク ２４…メーラー ２５…ブラウザ ２５ａ…案件作成画面 ２５ｂ…案件種別選択エリア ２５ｃ…必要項目入力エリア ２５ｄ…進捗状況確認画面 ２５ｅ…承認者ステータス表示エリア ２５ｆ…回覧案件表示エリア ３０ａ，３０ｂ…承認者クライアント ３１…通信Ｉ／Ｆ ３２ａ…ディスプレイ ３２ｂ…入力装置 ３３…ハードディスク ３４…メーラー ３４ａ…受信メッセージ ３５…ブラウザ ３５ａ…返答入力画面 ４０…サーバ ４１…通信Ｉ／Ｆ ４２…ＯＳ ４３…ハードディスク ４４…承認データ ４４ａ…案件種別リスト ４４ｂ…承認者データ ４４ｃ…承認者リスト ４５…回覧案件データ ４５ａ…回覧案件文書 ４６…作成者データ ４７…案件フォームデータ ５０…回覧承認ＡＰＬ ５０ａ…ｈｔｍｌファイル ５１…承認依頼出力部 ５２…登録承認者判別部 ５３…承認返答受付部 ５４…アクセス受付部 ５５…進捗状況通知部

Claims (15)

【特許請求の範囲】
1. 【請求項１】 回覧案件を表す回覧案件データを蓄積す
   る回覧案件データ蓄積手段と、 承認者を特定可能な承認者登録データと回覧案件の承認
   順序を表す承認順序データとを蓄積する承認データ蓄積
   手段と、 上記承認順序に基づいて決定される承認者に対して上記
   回覧案件に対する承認依頼を双方向通信を介して出力す
   る承認依頼出力手段と、 双方向通信を介して外部からのアクセスを受け付け、同
   アクセスが上記承認者登録データに登録された登録承認
   者からのものであるか否かを判別する登録承認者判別手
   段と、 同登録承認者判別手段によって登録承認者であると判別
   された承認者から双方向通信を介して上記承認依頼に対
   する返答を受け付ける承認返答受付手段とを具備するこ
   とを特徴とする回覧承認システム。
2. 【請求項２】 上記請求項１に記載の回覧承認システム
   において、 上記回覧案件データは、予め用意された入力項目に対し
   て入力を行うことによって作成されたデータであること
   を特徴とする回覧承認システム。
3. 【請求項３】 上記請求項１または請求項２のいずれか
   に記載の回覧承認システムにおいて、 上記承認データ蓄積手段は、上記回覧案件データ蓄積手
   段に蓄積される回覧案件データの案件種類毎に承認順序
   データを蓄積していることを特徴とする回覧承認システ
   ム。
4. 【請求項４】 上記請求項１〜請求項３のいずれかに記
   載の回覧承認システムにおいて、 上記承認依頼出力手段は、承認依頼毎に個別の識別ＩＤ
   を付与しつつ承認依頼を行うことを特徴とする回覧承認
   システム。
5. 【請求項５】 上記請求項１〜請求項４のいずれかに記
   載の回覧承認システムにおいて、 上記承認データ蓄積手段が蓄積する承認者登録データは
   承認者のメールアドレスであることを特徴とする回覧承
   認システム。
6. 【請求項６】 上記請求項１〜請求項５のいずれかに記
   載の回覧承認システムにおいて、 上記承認返答受付手段は上記承認依頼に対する返答とと
   もに回覧案件の修正を受け付けることが可能であり、上
   記回覧案件データ蓄積手段は受け付けた修正済回覧案件
   の回覧案件データを蓄積することを特徴とする回覧承認
   システム。
7. 【請求項７】 上記請求項１〜請求項６のいずれかに記
   載の回覧承認システムにおいて、 上記承認返答受付手段は上記承認依頼に対する返答とと
   もに回覧案件に対するコメントを受け付けることが可能
   であり、上記回覧案件データ蓄積手段は受け付けたコメ
   ントのデータを回覧案件データに対応づけて蓄積するこ
   とを特徴とする回覧承認システム。
8. 【請求項８】 上記請求項１〜請求項７のいずれかに記
   載の回覧承認システムにおいて、 上記承認依頼出力手段は、承認依頼を行う回覧案件の回
   覧案件データを出力することを特徴とする回覧承認シス
   テム。
9. 【請求項９】 上記請求項８に記載の回覧承認システム
   において、 上記承認依頼出力手段は、承認依頼に当たり修正済回覧
   案件の回覧案件データのうち最新のものを出力すること
   を特徴とする回覧承認システム。
10. 【請求項１０】 上記請求項１〜請求項９のいずれかに
    記載の回覧承認システムにおいて、 上記承認返答受付手段は、回覧案件に対する承認の是非
    を入力させることを特徴とする回覧承認システム。
11. 【請求項１１】 上記請求項１〜請求項１０のいずれか
    に記載の回覧承認システムにおいて、 上記承認返答受付手段は、承認依頼に対して否認の返答
    を受け取ったときに、当該否認の返答を必要とする者に
    否認された旨を通知することを特徴とする回覧承認シス
    テム。
12. 【請求項１２】 上記請求項１〜請求項１１のいずれか
    に記載の回覧承認システムにおいて、 上記承認返答受付手段は、上記承認順序の最後の承認者
    から承認依頼に対して是認の返答を受け取ったときに、
    当該回覧案件に対する承認を必要とする者に回覧が終了
    した旨を通知することを特徴とする回覧承認システム。
13. 【請求項１３】 上記請求項１〜請求項１２のいずれか
    に記載の回覧承認システムにおいて、 回覧の進捗状況を確認する進捗状況確認者からのアクセ
    スを双方向通信を介して受け付けるアクセス受付手段
    と、 同アクセス受付手段を介してアクセスした進捗状況確認
    者に、当該アクセス時点において承認返答待ちの承認者
    と蓄積されている回覧案件データとを通知する進捗状況
    通知手段とを具備することを特徴とする回覧承認システ
    ム。
14. 【請求項１４】 回覧案件を表す回覧案件データと承認
    者を特定可能な承認者登録データと回覧案件の承認順序
    を表す承認順序データとを蓄積し、回覧案件の承認依頼
    に対する返答を集中的に管理する回覧承認方法であっ
    て、 上記承認順序に基づいて決定される承認者に対して上記
    回覧案件に対する承認依頼を双方向通信を介して出力す
    る承認依頼出力工程と、 双方向通信を介して外部からのアクセスを受け付け、同
    アクセスが上記承認者登録データに登録された登録承認
    者からのものであるか否かを判別する登録承認者判別工
    程と、 同登録承認者判別工程によって登録承認者であると判別
    された承認者から双方向通信を介して上記承認依頼に対
    する返答を受け付ける承認返答受付工程とを具備するこ
    とを特徴とする回覧承認方法。
15. 【請求項１５】 回覧案件の承認依頼に対する返答を集
    中的に管理する回覧承認プログラムを記録した媒体であ
    って、 回覧案件を表す回覧案件データを蓄積する回覧案件デー
    タ蓄積機能と、 承認者を特定可能な承認者登録データと回覧案件の承認
    順序を表す承認順序データとを蓄積する承認データ蓄積
    機能と、 上記承認順序に基づいて決定される承認者に対して上記
    回覧案件に対する承認依頼を双方向通信を介して出力す
    る承認依頼出力機能と、 双方向通信を介して外部からのアクセスを受け付け、同
    アクセスが上記承認者登録データに登録された登録承認
    者からのものであるか否かを判別する登録承認者判別機
    能と、 同登録承認者判別機能によって登録承認者であると判別
    された承認者から双方向通信を介して上記承認依頼に対
    する返答を受け付ける承認返答受付機能とをコンピュー
    タに実現させることを特徴とする回覧承認プログラムを
    記録した媒体。