JPH02278458A - 電子文書承認システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、電気的に生成されてメールされる即ち送信さ
れる文Ｍ（ｄｏｃｕｍｅｎｔ）の内容を承認すること及
びそのような文書を生成し、モニターしそして処理する
システムに関する。

Ｂ、従来の技術 電子メール・システムは、増大する数の会社内で目下用
いられている。そのようなシステムによって、ユーザは
簡単なメモ又はより手の込んだ文書を用いて多くの情報
を非常に迅速に交換することができる。

サイン即ち承認されねばならない文書は、大抵の場合、
古い方法で扱われている。処理のどのステップも人間の
介在を含んでいる。文書の創作者（ｏｒｉｇｉｎａｔｏ
ｒ　）は、フオームのコピーを持ってｌ、Ｎなければな
らない。創作者は、管理されなければならない中央記憶
装置からフオームのコピーを得る。しばしば、創作者は
、後での使用のためにコピーを持ち、フオームの旧式版
を用し）るリスクをおかしている。フオームを埋めたと
き、操作援助（ｈｅｌρ）はほとんど利用できないし、
もちろんエラー・チエツクも何ら行なわれ得ない。フオ
ームはしばしば紛られしくて完成するのが困難なはずで
ある。なぜなら、コストを考えると、全ての場合に用い
ることができる多目的フオームを作成することになるた
めである。システムを満足させるより手の込んだフオー
ムについては、骨組フオームが処理されるヨーロッパ出
願第２６９８７５号を参照されたい。

フオームが一旦完成されると、創作者はそれを承認して
もられなければならない。承認処理は簡単なはずである
（例えば、創作者のマネジャーによる承認）。その場合
には、簡単な電子メールが進行するオペレーションが仕
事を行なうことになる。

しかし、大抵の場合には、要求はもって複雑であり、幾
くつかのレベルの管理即ち職務上の承認が必要となる０
例えば、財政分析者、予算監査室等による承認である。

しばしば、その承認処理は、フオーム中に埋められるデ
ータに依存している。

例えば、購入オーダについては、要求された購入額が所
与の値を越えないなら、１つのレベルの管理で十分であ
るが、そうでないなら、例えば２つのレベルの管理が必
要である。その上、管理上の決定のために、所与のフオ
ームに対する承認ルールはフオーム自体を変更すること
なく、変えられ得る。

通常システムでは、創作者が第１承認者（例えば、その
マネージャ）のサイン（即ち、承認）を得るために第１
承認者へ文書を渡す。第１承認者は、文書がどこに存在
するか又は誰がそれを持っているのか又は文書が手で持
って運ばれたのか或いは社内メールによって転送された
のかどうか定かであるはずがない。このことは、承認処
理におけるどのステップについても当てはまる。第１承
認者は第２承認者等へ文書を転送する際に制御できなく
なる。しばしば、承認者は５次の承認者へ文Ｍを渡す前
に、文書の紙によるコピーを保管していなければならな
い。

例えば、承認が委任（ｄｅｌｅｇａｔｅ）により付与さ
れねばならないが、誰が委任しているのか人々は知らな
いことがある。

その上、承認者リストは承認処理の間に変更される必要
があることもある。承認者がそのマネージャと交代する
こともあるし、承認の順序も変更されることもあり、又
は、より多くの情報が既にサインした他の承認者から承
認者によって要求されることもあり得る。

結局、フオームから発行されて承認された全ての文書が
、処理して要求を実行しなければならない人又は部門に
到達する。まず、チエツクが行なわれなければならない
。即ち、データのチエツク及び承認処理のチエツクであ
る。

それから、全てが正しいなら、データをオペレーション
・システム中ヘキー人力するような行為がとられる。

一般に、創作者へは何ら情報は戻されない。創作者は、
その要求が満されるまで持っていなければならないし、
又は電話或いは手紙で情報を得なければならない。

文書は、関係する承認処理が実行されている時間の間の
みならず、各フオームについて設定された保存期間の間
、保管されなければならない。

Ｃ６発明が解決しようとする課題 全ての公知のシステムは、しかしながら、埋められたフ
オーム（本文中では文書と呼ばれる）をモニタし、埋め
られたときにその内容に基づいて特定のフオームが進む
へき承認経路を動的に且つ電気的に計算し、ユーザの構
成範囲での要求者の職務に基づいて埋められた文書への
アクセス要求をフィルタするばかりでなくそのような経
路を制御するための有効な手段を欠いている。

０９課題を解決するための手段 本発明の目的は、事前記憶されたブランク・フオーム・
ライブラリをアクセスし、フオームを選択し、そのフオ
ームを埋め、埋められたフオームのデータとシステムの
接続されたユーザの母集団の範囲内でユーザの仕事即ち
職務を参照する特定の定義済み承認ルールとに基づいて
承認経路を計算し、対応する承認オペレージコンをモニ
タして制御するようなシステムを提供することである。

本発明の目的には、埋めら九たデータと記憶された更新
可能な承認ルールと要求者の一紋符合とに基づいて、埋
められたフオーム（文書）へのアクセス要求をフィルタ
するシステムを提供することも含まれる。

本発明は、内容が複雑な承認を必要としている文書の処
理に係わる全てのステップの自動化を達成する。

それには、文書の構成、承認者リストの決定、電子的サ
イン（即ち、承認）の確認、終了化オペレーション、記
憶及び処理の一般的な追跡が含まれる。

特に１本発明は、次のような電子メール・システムにお
いて、システムの選択されたユーザによる′に予約な承
認によってサインを必要とするユーザ創作の文書の処理
を制御する承認システムを達成する。即ち、その電子メ
ール・システムは、ディジタル・ネットワークに接続さ
れたターミナルと、計算機手段、メモリ及び個々のユー
ザに割り当てられたソフトウェア・ファシリテイを含む
仮想計算機（ＶＭ）と、ターミナルからユーザへメール
される電子文書を作成し、処理しモニタする手段とを含
む。そして、各ユーザは、システム接続されたユーザの
母集団の範囲内で仕事即ち職務を割り当てられている。

そのような承認システムは５次の手段を含む。即ち。

各システム・ユーザの職務及びアドレスが識別される職
務テーブルを記憶し更新する手段と、文書のフオームを
記憶する手段と、 ユーザの職務の文書のタイプ及び文書のフオームの内容
に基づく定義済み承認ルールを記憶する手段と、 内容が承認を受けることになっているフオームを選択し
９選択されたフオームをアクセスして埋めて処理しメー
ルするためのターミナル制御可能手段と。

上記メールすることに応答して、上記職務子−・プルを
アドレス指定し、上記承認ルールに１ルづき　システム
接続されたユーザ間で承認経路を決定する手段と、 上記承認経路決定に応答し、て５−ヒ記埋められたフオ
ームについてのメール及び処理をモニタする手段と、 である。

Ｅ、実施例 第１図には、アプリケーション資源及び通イａ資源の両
方を含むディジタル・ネッ１−ワーク・ノードが示され
ている。例えば、インテリジェント・デイスプレィのよ
うなターミナルＴ１、Ｔ２・・・・・が、ホストコンピ
ュータに直接に又はコンセントレータ即ち通信制御装置
或いはリモート・ターミナル用のＰＢＸを介して接続さ
れている。幾〈っかの類似ノードが、ネットワークに接
続された丙子ものターミナルへこのようにして通じてい
るディジタル・ネットワークに接続されている。どのタ
ーミナルに居るユーザも、ネットワークのソフトウェア
資源を用いて選択したタスクを実行する。

及びＭ　、！１．なキーボード操作によって昼夜意のま
まに相互に通信することの両方ができる。

ホスト・コンピュータを含むシステムが、ＶＭ／ＳＰ環
境において動作しているとする２各自即ちエンド・ユー
ザは、ネットワークの所与のノート内のコンピュータ・
システムにおいて仮想計算機を割り当てられている。仮
想計算機は、実際時にはユーザのＡ−ディスクとして参
照される所定サイズの記憶場所を意味するし、各々がそ
れ自身のタイプのサービスを含む制御プログラム（ｃｐ
）及び会話型モニター・システム（ＣＭＳ）を本質的に
含む共通のコンピュータ・ハードウェア及びソフトウェ
ア資源を共用することを意図している。

ＣＰは、システムの資源を管理し、システムを用いて各
自に対して個々の作業環境を提供する。ＣＰによって管
理される資源には、プロセッサの機能、プロセッサの記
憶及び入力／出力装置が含まれる。ＣＰは、システムの
作業環境を作成する。

それは、作業セツションの間ユーザが利用できるシステ
ム資源を制御する。

ＣＭＳは、ＶＭ／ＳＰオペレーティング・システムの構
成要素であるが、それ自体、ＣＰ下で動作するオペレー
ティング・システムである。その名前″会話型″が意味
するように、システムのユーザとＣＭＳとの間には両方
向通信が存在する。

ＣＰ及びＣＭ　Ｓについての詳細は、以下に示すＩＢＭ
社の文書を参照されたい。

Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ／５ｙｓｔｅＩＩＰｒ
ｏｄｕｃｔ　（ＶＭ／５Ｐ）Ｇｅｎｅｒａｌ　ｉｎｆｏ
ｒｍａｔｉｏｎ、　ＧＣ２０−１８３８゜Ｖｉｒｔｕａ
ｌ　　阿ａｃｈｉｎ／Ｓｙｓｔｅｍ　　Ｐｒｏｄｕｃｔ
　　：　　ＣＭＳＵＳＥＲ’ｓ　Ｇｕｉｄｅ、５Ｃ１９
−６２１０゜Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ／Ｓｙｓ
ｔｅｍ　Ｐｒｏｄｕｃｔ　　：　ＳｙｓｔｅｍＰｒｏｄ
ｕｃｔ　Ｅｄｉｔｏｒ　Ｕｓｅｒ’ｓ　Ｇｕｉｄｅ、５
Ｃ２４−５２２０゜第２図に示されているように、ユー
ザは、ネットワークに接続されたターミナルを用いてセ
ツションを開始し、ログ・オン手順を経て計算機に到達
することが可能である。ログ・オンすることは、ＣＰソ
ファリティに到達するためにキーボードから割込みコマ
ンドを送り、それがら暗証コード（ユーザ識別子）及び
大抵の場合にはパスワードをタイプすることによってシ
ステムに対しユーザを識別させることを意味する。パス
ワードの使用によって、計算機の′″オーナ即支所有者
″以外の者がその所与の″計算機″にアクセスすること
を禁止することができる。パスワードは秘密にされただ
オーナのみが知っている。ＣＭ、Ｓ資源乃至は他のソフ
トウェア資源（例えば、ＩＢＭ社のＰＲＯＦＳアプリケ
ーション・プログラム）乃至は他の特定ソフトウェアは
１本発明に対して考えられている″シーリング（ＳＥＡ
Ｌ　ＩＮＧ）”により指定されるもののように、要求し
てアクセスされることも、又は直接にアクセスされるこ
とも可能である。このことは、ユーザのＰＲＯＦＩ　Ｌ
ＥＥＸＥＣルーチン中で定義される。このルーチンは、
ユーザの計算機を本来定義するときに特定のユーザに割
当てられた（即ち、利用可能にされた）利用可能な資源
を識別するように調整されている。

ＩＢＭ社のＰＲＯＦＳについての詳細は、次のＩＢＭ社
の文書を参照されたい。

Ｕｓｉｎｇ　ｔｈｅ　Ｐｒｏｆｅｓｓｉｏｎａｌ　０ｆ
ｆｉｃｅ　Ｓｙｓｔｅｍ（Ｏｒｄｅｒ　Ｎｏ、５１１２
０−５６０４）更に、本発明のために、特定の環境が第
３図に示されているようにシステム内で調整されている
。

この第３図は、いわゆる“シーリング（ＳＥＡＬＩＮＧ
）”環境の詳細を示している。そのような環境には、デ
ータ・ベース計算機（ＳＥＡＬＤＢＡ）及びシステム計
算機（ＳＥＡＬＳＹＳＴ）が、ユーザのＶＭ計算機の他
に含まれている。

５ＥＡＬＤＢＡは、ＳＱＬ／ＤＳデータ・ベース管理計
算機として切断モードで動作する仮想計算機である。読
取り／書込み（Ｒ／Ｗ）モードで動作する幾つかのミニ
・ディスクが、５ＥＡＬＤＢＡ計算機に接続されている
。

−保守オペレーション用の作業ディスクとしてのみ用い
られるＡ−ディスク。

データ・ベース・ディレクトリを含むディレクトリ・デ
ィスク。

−全ての作業ユニットのロギングを支援して問題の場合
にロールパックを与えるログ・ディスク。

幾つかのデータ・ディスク：共通システム・テーブル用
の少なくとも１つのディスクと、支援された種々のフオ
ームにより必要とされるだけの数のディスク。（ドキュ
メント／フオームの意味はさらに定義されるであろう。

） ＳＥＡＬＤＢＡ計算機は、ＳＱＬフオーム中にデータ・
ベースを本質的に含むＳＱＬ計算機とみなすことも可能
である。

５ＥＡＬＳＹＳＴは、５ＥＡＬＩＮＧシステムの仮想計
算機である。この計算機には幾つかのミ二・ディスクが
接続されでいる。

保守オペレーション用の作業ディスクとしてのみ用いら
れるＡ−ディスク。

バッチ・オペレーションを支援するバッチ・ディスク。

全てのプログラムのソースを含むソース・ディスク。

ユーザが５ＥＡＬＩＮＧアプリケーシヨンを実行するの
に必要な全てのルーチン、即ち、承認アプリケーション
によって必要とされ、この記述において更に定義される
ルーチンを含むシステム・ディスク。ユーザがアプリケ
ーションの実行を希望するときには、このミニ・ディス
クへの読取専用リンクを作る必要がある。

ユーザの仮想計算機は、２メガの記憶サイズでユーザの
Ａ−ディスクを有する標準のＶＭ計算機である。Ａ−デ
ィスクは、主として文書原稿を記憶したり印刷オペレー
ションを支援するのに用いられる６ ユーザの標準ＶＭ計算機及び５ＥＡＬＳＹＳＴ計算機の
両方とも、相互ユーザ通信伝達手段（■ＵＣＶリンク）
を介してＳ　Ｑ　Ｌ／Ｄ　Ｓデータ・ベース管理計算機
と通信することが可能である。

このようなシステム構成によって、以下の説明より明ら
かになるような幾つかの利点がもたらされる。承認プロ
セスへより高いセキコリティ・レベルを提供するのにそ
れが貢献することは、既に言われていることでもある。

そのために、エンド・ユーザが使用することがあるＳＱ
Ｌコマンドのみは、５ＥＡＬＤＢＡ計算機付加ディスク
中へ記憶されているアクセス・モジュール内に予め定め
られている。ＩＵＣＶリンクによって、ユーザのターミ
ナルからこれらのモジュールにアクセスして実行させる
ことができる。

好実施例の詳細な説明の理解を平易にするために、まず
次のような仮定に注意されたい７空（ブランク）のフオ
ームが、本発明を用いて処理される（例えば、承認され
る）ことになっている文書へ更に使用して変換するため
に、システム（ＳＥＡＬＳＹＳＴ）において設計され記
憶されている。

承認者は、通常、夫々の職務を参照すること、例えば部
門番号××の第１、第２、・・・・・・等のラインのマ
ネージャによって指定されている。″行為（ａｃｔｉｎ
）　’″者がその職務の最初の選任者（肩書のある者）
とは異なるような場合には、その職務は委任されること
もある。

システムのユーザ（考慮される文書の創作者）が適切な
承認のために文書の転送を希望するときには、文書内の
特定データ・フィールドの内容を用いて動的に承認経路
が計算されて、承認ルールが予め定められる。続く実行
の際に、承認者は２つの項類即ち″許可者（ａｕｔｈｒ
ｉｚｅｒ）　”と″評価者（ｒｅνｉｓｗｅｒ）　”と
に分けられたのかも知れない。

許可者のみが文書を受入れる（同意する）又は拒絶する
ことが可能である。評価者は、助盾を与えることのみが
できる。否定的な評価者の意見では、文書が先に進むの
には次の許可者の承認を必要とする。

最終的に、最後の承認者によって進められた後は、文書
は終了させるＶＭ；：ｉ算機へ自動的に転送される。こ
の計算機は、通常のオペレーションを実行する。例えば
、更新したり、フォーマット化したり、必要なら暗号化
たり、ネットワークを介して別のネットワークのノード
へ送ったり、本発明のために、承認システムに対するよ
り高いセキュリティ・レベルを確かめるように調整され
た制御動作を実行したりする。

上記のようなオペレーションは、ユーザのＶＭ計算機の
他に５ＥＡＬＤＢＡ、５ＥＡＬＳＹＳＴを介して利用で
きるようになったファシリティを用いて、第４図に要約
されている。

承認に必要な情報（例えば、職務）と共に文書はある承
認者から次の承認者へ転送されないことに注意すべきで
ある。それらは、汎用データ・ベースから動的にアクセ
スされる。このような構成によって、会社の社員（ユー
ザー）の移動即ち再選任に対し承認経路を常に更新する
ことができる。

機能の点からみて、ソフトウェアの構成がまとめられて
第５図に示されている。承認システムへのアクセスは、
ＲＥＸＸｇ語のソフトウェア・ツ−ルによって与えられ
る。これらのツール（プログラム）は、ダイアログ・マ
ネージャ（ＤｉａｌｏｇＭａｎａｇｅｒ　）即ち対話管
理プログラムをアクセスすると共に５ＥＡＬＩＮＧ汎用
プログラムのライブラリをアクセスする。ｌ５ＰＦ言語
のダイアログ・マネージャは、次のような機能を制御す
る。即ち、ユーザのターミナルにおける画面表示、メモ
リ中のテーブル及びメツセージ生成である。ダイアピグ
・マネージャは、ユーザ・インタフェースのタスクを実
行する。ｒｓＰＦについては、ＩＢＭ社のｌ５ＰＦ　　
　Ｖｅｒｓｉｏｎ　　２　　Ｄｉａｌｏｇ　　Ｍａｎａ
ｇｅｍｅｎｔ　　５ｅｒｖｉｃｅｓＳＣ３４−２１７３
を参照されたい。そのようなダイアログ・マネージャへ
のアクセスは、エントリＲＥＸＸユニットによって、そ
して汎用プログラム・ユニットによって実行される。デ
ィスクに記憶されているデータ・ベース（ＤＡＴＡ　　
ＢＡＳＥ）からデータを選択、更新、挿入又は削除する
ＳＱＬ／ＤＳツールを含むデータ・ベース・アトミニス
トレータが提供されている。このようなデータ・ベース
・アトミニストレータは、ＳＱＬオーダを用いる汎用プ
ログラムによってアクセスされる。

ＳＱＬについては、次のものを参照されたい。

ＳＱＬ／Ｄａｔａ　　Ｓｙｓｔｅｍ　　Ｇｅｎｅｒａｌ
　　Ｉｎｆｏｒｍａｔｉｏｎ　　ＧＨ２４ＳＱＬ／Ｄａ
ｔａ　Ｓｙｓｔｅｍ　Ｔｅｒｍｉｎａｌ　Ｕｓｅｒ’ｓ
　Ｇｕｉｄｅ　５Ｈ第６図には、処理の間読取り／書込
みに基づいてアクセス可能なＳＱＬ／ＤＳデータ・ベー
スに集中される承認システムの代表的な例を示している
。文書準備のためのエントリ（後に説明されるが）は、
そのデータ・ベースへの読取り／書込みオペレーション
を含む。この処理の後にステップ文書準備しているユー
ザから又は承認者から直接にトリガされ得る承認ステッ
プが続く。−旦承認されると、文書は更に先へ進められ
、追求され、必要なら実行される。そのために、ＳＱＬ
／ＤＳばかりでなく、例えば、さもなければ利用可能な
ＶＭディレクトリのような外部システムもアクセスされ
る必要がある。文書は最終的には記憶装置に転送される
。その上、承認処理にとって特に有用な″′職務（ｆａ
ｎｃｔｉｏｎ）　”データを更新する手段及び例えば統
計演算を実行するのに用いられるべき助言（ｃｏｎｓｕ
ｌｔｉｎｇ）　／分析手段も利用できる。

第７図には、５ＥＡＬＤＢＡ計算機のＳＱＬ関連データ
・ベースのデータ・ディスク中へ記憶される入きシステ
ム・データの配置が示されている。

システム・データは、承認処理により必要とされるとき
にはアクセスされたり発生される特定テーブルとそのシ
ステムとを実行させるのに必要な汎用テーブル中へ分割
される６明らかに、そのようなテーブルの内容は、予め
選択された承認基準に基づいている。これらの基準は、
変更可能であり、それ故に限られていない。好実施例に
おいて実施される基僧について次の説明を参考にされた
い。

（Ａ）汎用テーブル中では次のものが見出される。

１、ユーザの識別データを含むＬＯＧＯＮテーブル（例
えば、ノード識別子（ｎｏｄｅ　ｉｄ）　、ユーザ識別
子（ｕｓｅｒ　１ｄ） ２、職務に関連したテーブル：承認システムのユーザが
承認ルールを支配する特定機能を割当てられる（例えば
、支配構成）、このようなテーブルは、次のものを含む
。

ＦＵＮＣＴＩＯＮテーブル。これらのテーブルは、現存
する職務を定義し、各職務について行為者及び肩書のあ
る者の識別子を与える。

ＰＲＥＶＩＤＥＬテーブル。これらのテーブルは、委任
予知を表示する。ただし、承認権限がある者から他の者
へ委譲されることを仮定している。

ＨＩＳＴＦＵＮＣは、監査のために職務テーブル即ちＦ
ＵＮＣＴＩＯＮテーブル中に生じる変更を追跡する（新
しい職務、委任、肩書のある者の変更）。

３、承認処理に関連したテーブル。

ＡＰＰＦＵＴＵ、ＡＰＰＷＡＩＴ及びＡＰＰＤＯＮＥは
、進行中の文書に関係する。

ＡＰＰＦＵＴＵは、承認処理に必要となる（将来）ＩＩ
！務を各文書について含む。

ＡＰＰＷＡＩＴは１文書についての実行を持っている職
務を各文書について含む。

ＡＰＰＤＯＮＥは、文書について既に実行した職務、そ
の実行した者そして異なるなら肩書きのある者について
の決定及び識別子を各文書について含む。

ＡＰＰＨＩＳＴは、もはや進行しない文書を扱う。即ち
、それらは、終了させられたり、拒絶されたり又は取消
されたりする。それは、ＡＰＰＤＯＮＥと同じ構造を有
する。

４６文書に関連するテーブル 埋められたフオームは、承認処理を受けることになって
いる言わゆる文書を提供する。各文書は、少なくともそ
の文書を定義するデータを有する■ＩＥＡＤＥＲを含む
。全てのヘッダは、ＨＥＡＤＥＲＳテーブル中に動的に
記憶される。

ＣＯＭＭＥＮＴＳテーブルは、承認者が文書について実
行するとき承認処理の間に承認者によって付加されるコ
メントを各文書について含む。

（Ｂ）特定テーブル中では次のものが見出される。

１、職務を扱うテーブル 職務テーブルの符号化されたＦ島ｆｕｎｃＤｎの決定職
務テーブルの符号化されたＦａｆｕｎｃＣｎの特性（ｆ
ｕｎｃは職務のタイプについての符号であり。

Ｃｎ及びＤｎ中のｎは、整数の順序番号である。）２、
文書についてのテーブル Ｔｙｐｄｏｃａｎは、特定文書データを含む必要がある
ｎ個のテーブルのセットを所与のフオーム（文書のタイ
プ／１ｙｐｄｏｅ）について表わす。

Ｃ０ＮＴＲ０Ｌ　　ＴＡＢＬＥＳ即ち制御テーブルは、
文書を準備するために、又は承認処理の間にこれらのデ
ータを変更するために、入力されるデータを制御するの
に必要なことが時にはある。

−旦定義され更新されると、それらは、幾つかの異なる
タイプの文書についても用いられ得る。

ＦＯＬＬＯＷ−ＵＰ　　ＴＡＢＬＥＳ即ち追求テーブル
は、確定的に承認された文書についての追求情報を与え
るのに時には必要である。

職務テーブルの１例が以下に示されている。

職務テーブル システムの重要な概念は、″職務″の概念である。承認
システムが動作することを必要とされる範囲内の会社又
は人々のグループにおいては、例えば承認権限のような
特権が、ここでは″￥ｒ１務゛′と称されている仕事の
選任即ち肩書きに基づいて割当てられる。

承認処理では、必要とされるのは、特定の人のサインで
はなくて、必要な職務を現在割当てられている人のサイ
ンである。

職務とは、会社によって認められ人に割当てられた特権
の大要として定義できるものである。逆に言えば、それ
を与えられた人は、幾つかの異なる職務を有することが
ある。

本発明の承認システムは、人よりもむしろ割当てられる
職務を考慮している。一般的にはｌ！務の方が人よりも
より安定しているので、この基準を用いる利点は大いに
ある。例えば、会社で定義される承認ルールは、通常、
会社内での人のレベルに関係している。

そのようなシステムでは、“職務″は次のように完全に
定義される。即ち、 職務のタイプ（ｔｙｐｆｕｎ）　　：ここでは４文字で
コード化される。

マネージャ（ＭＡＮＡ） 予算監査室 財政分析者 購入者（ＰｔＪＲＣ） 職務の参照（Ｒｅｆｆｕｎ）　　：ここでは６文字でコ
ード化される。

マネージャの管理部１７番号 財政分析者についてのコード 購入者についてのコード 職務が唯一のものであるときには、参照は必要でない。

例えば、４計画管理（Ｐｌａｎｓ　＆　Ｃｏｎｔｒｏｌ
ｓ）”の職務は、唯一のものである。

職務′″従業員″′は、会社の従業員のうちの１人であ
ることの基本的な職務を意味する。その参照は、雇用時
に各人に割当てられた通し番号であり得る。

職務のタイプは、４文字でコード化される。即ち、 Ｉ　Ｎ　Ｄ　Ｉは、゛′従業員″についてのものである
。

ＭＡＮＡは、“マネージャ″についてのものである。

ＰＵＲＣは、′購入者″についてのものである。

ＣＴＬ’Ｇは、“監査官″についてのものである。

ｌ５ＰＣは、″計画管理″についてのものである。

ユーザ識別子及びノード識別子によって、ＶＭ計算機と
その結果として唯一の人とが識別される。

“ＴＩＴＵＬＡＲ”が所有者、即ち、職務を割当てられ
る人を指定し、一方、”ＡＣＴＩＮＧ”が、現在仕事を
実際に行なっている人を指定するのに用いられる。

例えば、ＭＡＲＴＩＮＳは、参照番号（Ｒｅｆｆｕｎ）
が０７９９５４ラインテーブルの参照ラインである従成
員である。彼はまた１部門番号０７９３のマネージャで
ある。彼は、従業員番号０７１３２８（ライン２）であ
るＤＡＶＩＥＳ　（ライン５）の委任によって部門０８
３０のマネージャとして代理する。

ＨＡＣＫＥＲ３は、従業員番号が０５５４１３（ライン
３）であり、また購入者コードが４５（ライン７）であ
る。

ＤＡＶ　Ｉ　Ｅ　Ｓは、マネージャとしての彼の職務を
他のマネージャＭＡＲＴＩＮＳに委任しているが、計画
管理の彼の職務は、マネージャでないＪ○ＨＮＳＯＮ　
（ライン６）に委任している。

ＲＯＯＶＥＲ（ライン８及び９）は欠勤している（誰も
彼の代理をしていない）。

Ｓ　ＣＨＭ　Ｉ　Ｄ　Ｔは、同じノードには存在せず、
電子的なサイン・システムを有していない。それで、Ａ
ＮＤＥＲ８ＯＮがシステムに彼の決定を入れることを担
当している。彼は、ＳＣＨＭＩＤＴの“代行（ｓｕｂｓ
ｔｉｔｕｔｅ）　”　　（委任指標はＳ）として働く。

幾つかの職務は、ネットワークに接続された特定のシス
テムにおいて既に管理されている。その場合、その特定
のシステムへのリンクが、職務テーブル維持の困難を除
去可能にする。例えば、会社では、人事部門のシステム
が次のような職務についての肩書きを有する者を指示す
る。即ち、従業員（その従業員の通し番号により参照さ
れる。） 部門マネージャ（管理される部門の番号により参照され
る。） 他の職務が承認処理において必要になるやいなや、シス
テムは、その職務を管理する会話型手段を提供する。

第７図に関連する承認テーブルの例が、以下に表わされ
る。

ＡＰＰＨ丁ＳＴ　：　ＡＰＰＤＯＮＥと同じ構成ＡＰＰ
ＦＵＴＵ：これは、承認処理における各文書について、
後に文書を扱わなければならなくなる職務のリストを含
んでいる。

このテーブルでは５文書は文書のタイプ（ｔｙｐｄｏｃ
）によって識別される。その文書のタイプは、実際、そ
の文書が導出されるフオームについて及びこのタイプ内
の参照（ｒｅｆｄｏｃ）についてのコードである。この
アプリケーションでは。

″文書″という表記は、通常環められたフオームを意味
し、幾つの事前記憶されたフオームが利用できることに
注意されたい。

職務は、職務のタイプ（Ｔｙｐｆｕｎ）及び参照番号（
例えば、サービス又は部門番号（Ｒｅｆｆｕｎ）　）に
よって、ＦＵＮＣＴＩＯＮテーブル中で先に述へたよう
に識別される。承認者リストへの変更が何ら生じていな
いとすると、順序番号１．２，３、・・・・・・は、ど
の職務が次に承認する必要があるのかを示す。幾つかの
職務は、同じ順序番号を有し得る。

承認者のタイプ（Ａｐｐｔｙｐ）は、その職務が許可者
（Ａｕｔｈｏｒｉｚｅｒ）　　（Ａ）として又は評価者
（Ｒ）としてリスト中に存在しているのかどうかを示す
。

許可者の行為は、“許可すること（Ａｕｔｈｏｒｉｚｅ
）　”又は″拒絶すること（Ｒｅｊｅｃｔ）　”であり
、一方、評価者の行為は、パ承認すること（Ａｐｐｒｏ
ｖｅ　）　”又は１１否認すること（Ｄｉｓａｐｐｒｏ
ｖｅ）　”である。

指標は、その職務が承認者リストにおいて必須であるの
か又はそうでないのかを示す。このことは、承認者リス
ト中で変更するのに重要となる。

職務が必須でないなら、どの承認者もそれを禁止する（
ｓｕｐｐｒｅｓｓ　）ことができる。しかし、職務が必
須なら、それを禁止することはできない、即ち他の職務
がそれに代わらなければならない。

ＡＰＰＷＡＩＴは、承認処理における各文書について、
その文書を実際に待っている（即ち、行為に次ぐ）ｌ！
務を含んでいる。

ＡＰＰＦＵＴＵとして、それは、文書識別子、職務識別
子、承認者のタイプ及び必須標識を含む。

それはまた、前承認者の名前、前承認者からの１行の個
人コメン１〜、前行為の日付及び時間を含む。

ＡＰＰＤＯＮＥ　：これは、各文書に対して、その文書
につき既に行なわれた職務、行為考及び異なるときには
肩書を有する者についての決定及び識別子を含む。

ＡＰＰＦＵＴＵ及びＡＰＰＷＡＩＴとしては、それは、
文書識別、職務識別、承認者のタイプ及び必須標識を含
む。それはまた、承認者の決定も含む。即ち、許可する
こと又は承認することについてはＹ、拒絶すること又は
否認することについてはＮである。それはさらに、承認
者、その名前及び従業貫通し番号についての識別、その
職務の肩書を有する者、その名前及び従業員番号につい
ての識別、委任標識１行為の日付及び時間を含む。

既に述べたように、本発明の最良モードについての承認
システムは、予め設計されたフオームを用いるように作
られる。承認オペレーションについての要求を開始する
ことを望むユーザは、文書フオーム（ブランク）をアク
セスして埋める。フオームは、埋められるときに、他の
ものとの間で１′ヘツダ（ＨＥＡＤＥＲ８）”テーブル
を含むテーブルの組へ記憶される定義済みフィールドを
含む。

ＨＥＡＤＥＲ３ このテーブルは、文書に必要なヘッダ・データを含む。

このテーブルの重要な点は、文書の識別、即ち文書のタ
イプ及び参照である。各文書には、次のような状況情報
（１文字）が割当てられている。即ち。

Ｐ：文書が承認処理において進行中である。

Ｆ：文書が終了させられて、承認処理が終わる。

Ｓ：文書がオペレーショナル・システムに送られている
。

Ｔ二文書が行為（オペレーショナル・システムから受取
った肯定応答）のために転送されている。

Ｆ■：含まれる行為が終了させられる。

Ｒ：文書が許可者によって拒絶されている。

Ｃ：文書が創作者によって取消されている。

対応する文書が現在誰かによって処理されていることを
示すために、フラッグが用いられる。フラッグがＹ（イ
エス）に設定されているなら、システムは、文書への他
の者のアクセスを妨げる。

創作者は、その人の職務（例えば、従業員についてのＩ
ＮＤＩ）、従業貫通し番号及び名前によって、ＨＥＡＤ
ＥＲＳテーブルにおいて識別される。

そのテーブルはまた、承認処理へ提示された要求の主題
（文書）と創作の日付及び時間とを含む。

既に述べた職務テーブルの他に、システムは、フオーム
・ユーザの会社によって選択された承認ルールを定義す
るために用いられることになっているデータを記憶した
特定の職務テーブルを用いる。

特定の職務テーブル するのに“ｆｕｎｃ”が用いられる。

ＣＡＲＡＣＴＥＲＩＳＴＩＣテーブル：　（Ｃ）”Ｆａ
ｆｕｎｃＣｎこれらのテーブルによって、パラメータか
ら職務基準を導出することができる。それらは、承認者
リスト決定の間に用いられる。

その例は、文書化された定常業務に対して責任を有する
マネージャを定めるのに有用ないわゆるＤＥＴＥＲＭＩ
ＮＡＴＩＯＮテーブル即ち決定テーブルを示している。

職務のＣＨＡＲＡＣＴＥＲＩＳＴＩＣテーブル即ち特性
テーブルによって、所与のタイプの職務についての基準
からパラメータを決定することができる。それらは、承
認者のサイン検証の間に用いられる。言い換えれば、こ
れらのテーブルは定義済み承認ルールを記憶する。

その例は、考慮されるマネージャの職務に基づいて許可
されている支出の額及び支出のしきい値を設定する会社
の被選択ルールを示している。

上記のような考慮すべきことから、承認ルールと結合し
て考慮されるときに承認パスを決定するシステムによっ
て、どの埋められたフオーム（文書）の内容も動的に用
いられることを理解されたい。さらに、システムは、相
当簡単な方法で必要とされるようにフオームを付加した
り又は変更したりすることができるように設計されてい
る。それ故に、種々のタイプの情報フィールドの内容が
それらのフィールドの便利な処理を可能にするように構
成されるへきである。そのために、全ての埋められたフ
オームについての各フィールドの内容は、文書テーブル
中に記憶され、そして、これらの種々のテーブルは、定
義済み木構造（第８図参照）に従って互いに関係するよ
うになされている。

フオームが簡単なら、文書（ＴＯＰ）データ・テーブル
についての単一のテーブルｔｙｐｄｏｃΔ１中にそのデ
ータは含まれ得る（　１１　ｔ　ｙＰｄＯＣＩ＋が文書
のタイプ及び対応するフオーム・コートを指示するため
に用いられることに注意されたい。）フオームがより複
雑なら、テーブルｔｙｐｄｏｃＡ　２、ｔｙｐｄｏｃ、
ｌ１３、・・・・・・・・・、ｊｙｐｄｏｃ５　ｎは、
従属関係にあって可変数の発生セグメン１へを有するデ
ータを含むように定義され得る。これらのテーブルは、
言及した本構造に従って互いに関係付けられる。

上に述へたことを説明するために、特定の例（一般支出
購入要求）が以下に示される。

キーでない変数： ＲＯＦＩ ＡＵＴＯ ＣＩＩＡＲ（７） ＤＥＣ（１１，０） キー：　　　ＫＥＹＩ ＥＹ２ キーでない変数： ＴＤＥＭ Ｆｌ）ＵＨＴ ＥＳＣ ＣＩＩＡＲ（５） ＳＭＡＬＬＩＮＴ ＤＥＣ（７） ＤＥＣ（９，２） ＣＨＡＲ（３０） 変更されるプロジェクト 最大量 要求の参照 項目番号 要求量 見積もり単価 項目の主記述 ＫＥＹ２　　　ＳＭＡＬＬＩＮＴ　　　項目番号ＫＥＹ
３　　　ＳＭＡＬＬＩＮＴ　　　ライン番号システム構
成を定義したので、もはや文書へのユーザのアクセスに
ついて用いられる原則を理解することができる（第９図
のフローチャート参照）。まず、登録ユーザに割当てら
れた″サイン（ｓｉｇｎａｔｕｒｅ　）　”　　（承認
）計算機としてシステムが知っている仮想計算機におい
てログオンされている間、ユーザは認識される。

ＦＵＮＣＴＩＯＮテーブルは、文書をアクセスするため
の主フィルタである。このテーブルは、ネットワークに
接続された全てのユーザの実際の糧務を反映するように
絶えず更新されている。

旦そのフィルタによってアクセスが許可されると。

システムによって用いられるべきテーブルは、ユーザが
何をしたいかによって異なる。

ＡＰＰＷＡＩＴが、行為を待っている文書を決定するた
めに用いられる。

ＨＥ　Ａ　Ｄ　Ｅ　ＲＳが、文書の起源を見つけるのに
用いられる。

ＡＰＰＤＯＮＥ又はＡＰＰＨＩＳＴは、行為が既にとら
れた文書を見つけるために用いられる。

部分的に承認された文書は、テーブルＡＰＰＤＯＮＥ中
に記憶され、一方、全ての必要な承認者によって承認さ
れた（又は拒絶された）文書は、ＡＰＰＨＩＳＴ又は履
歴テーブル中に記憶される。

システムをオペレーションの観点から魅力のあるものに
そしてエンド・ユーザに親しみのあるものにするために
、パネルが設定されそして機能キー　（ＰＦキー）が特
定のタスクに割当てられる。

システムは、技術的知識即ち専門的技術知識のレベルを
何ら仮定していない。しかしながら、ユーザが現在利用
可能な文書処理手段、例えば、よりＭ　　ＰＲＯＦＳ又
は同様のオフィス・システムにともかくも通じているこ
とを仮定している。概して、システムは実施例について
以下に示されるようにメニュー駆動される。

まず、システムは、ユーザのターミナルを介してＣＭＳ
コマンドをタイプする（例えば”　Ｓ　Ｅ　ＡＬＩＮＧ
”をタイプする）ことによりアクセス可能である。これ
により、ユーザのＶＭ計算機は５ＥＡＬＳＹＳＴ　　Ｖ
Ｍシステムのディスクに連係される。ＩＢＭ　　ＰＲＯ
ＦＳシステムが利用できるとすると、ＰＦキーは、シス
テムへの直接アクセスのために特別仕様にされている。

両方の例において、システムは、文書を準偏し、処理し
又は助言したりし、そしてユーザのデイスプレィに次の
ようなメニューを表示するプログラムをロードする。

ユーザは、そのようなオプションのうちの１つをそのオ
プションに関係するＰＦキーを押すことにより選択する
ことができる。例えば、文書を準備するために、ユーザ
はＰＦＩを押すべきである。

ユーザは、操作援助（ｈｅｌｐ）画面を得るためにＰＦ
９を押すことができる。それは、システム中で表示され
る全てのパネルについて当てはまる。

ＰＦＩ２によってシステムを終了することができる。

ユーザが使用しないＰＦキー例えばＰＦ４を押すと、エ
ラー・メツセージが画面の下、ＰＦキーの説明ラインの
直ぐ上に表示される。

明らかに、ユーザが実行する必要のある最初の操作は、
事前記憶されたフオームを選択しそのフオームを埋めて
、埋められたフオーム即ち文書を作成することである。

メニュー１でＰＦＩを押すことにより、ＰＲＥＰＡＲＥ
　　ＥＸＥＣを呼び出す。（第１０図参照。

この図は、承認処理に提示されるべき文書を作成する処
理の高レベル・フロー・チャートである。）このＥＸＥ
Ｃによって、“Ｃｈｏｏｓｅ　ａ　ＦｏｒｍＣａｔｅｇ
ｏｒｙ　（フオームの種類の選択）″メニュー中でユー
ザにとって利用可能なフオームのリストを表示すること
が開始される。″購入についての（ｐｕｒｃｈａｓｉｎ
ｇ）　”オーダ（ＡＰＰＲ）、“財政についての（ｆｉ
ｎａｎｃｉａｌ）　”オーダ（Ｆ　Ｉ　ＮＡ）、新しい
ユーザへＶＭ計算機をしつらえる承認を得る要求（ＬＯ
Ｇ○）等のような種々の種類のフオームを処理するよう
にシステムが成されていることに注意されたい。

例えば、”Ｐｕｒｃｈｏｓｉｎｇ　Ｆｏｒｎ＋　（購入
フオーム）”が選択されると、次のような“Ｃｈｏｏｓ
ｅ　ａ　Ｆｏｒｎ＋（フオーム選択）″メニューが表示
される。

余りにも多くの種類が存在して１つの画面におさまりき
れないなら、ユーザは、適切な種類を見つけるためにＰ
ＦＩＯ及びＰＦＩＩを用いてリスト中を夫々スクロール
アップ及びスクロールダウンすることができる。−旦種
類が選択されると、その種類内の利用可能なフオームの
リストが表示される。

ユーザは、その現在の要求に合うフオームを選択するこ
とが可能である。操作援助画面は、ユーザの要求で表示
され、各フオームを用いなければならない状況で説明を
することが可能である。

ユーザはこのメニューでＰＦＩを押すとする。

すると以下のメニューが示される（要求者はその職務の
所有者であり、それ故に、その職務はこの種のフオーム
へのアクセスが許可されると仮定しでいる）。

ユーザは、文書を作成する３つの方法のうちの１つを選
択することができる。

ＰＦＩ　　ブランク・フオームを用いて文書を作成する
。埋められるべき又はユーザが随意に変更可能な“省略
時（ｄｅｆａｕｌｔ）　”データによって既に埋められ
ているブランク・フィールドを含む入力ゾーンを予め設
計されたフオームは有している。

ＰＦ２　　原稿を変更する。ユーザは、予め埋められた
又はちょうど埋められ始めて文書を送ることなく記憶し
たそのフオームの原稿のリストを示される。

ＰＦ３　　既存の文書を作成する。ユーザは、アクセス
を許された文書の参照をタイプしなければならず、シス
テムは、新しい原稿を作成する。この原稿は、その文書
をコピーしている。参照がデータ・ベースに存在してユ
ーザが創作者か又は承認者の１人であるような場合には
、システムはチエツクする。こうして、その既存文書へ
のアクセスをフィルタする。

ユーザに表示する画面のレイアウトは、最初のフオーム
設計者の選択に依存する。

例えば、フオーム″一般支出購入要求″が選択されると
、以下の画面が示される。

ユーザは、ここではフオームへの″ヘッダ″部分を埋め
ることできる。

全てのフオームは、５ＵＢＪＥＣＴフイールドをＬｒす
る。本発明の’５ＥＡＬＩＮＧ”システムは、文書のリ
ス１〜に文書を示しているときには。

このフィールドを用いる。例えば、文書のリス１へを示
しているときには、誰かの行為を待っている。

何らかのデータが既に埋められていて（省略時）、その
データは変更可能である。

受信人（創作者）及びその部門 −フラッグ”Ｃｏｎｆｉｄｅｎｔｉａｌ　Ｉｎｆｏｒｍ
ａｔｉｏｎ”は、機密情報が供給者へ与えられることに
なっていることを示す。

フラッグ”ＰＣｐａｒｔｓ　ｏｒ　ｓｏｆｔｗａｒｅｓ
’は、要求がそのような部分を含んでいるかどうかを示
す。

フラッグＮｅｗ　ｃｈｅｍｉｃａｌ　ｐｒｏｄｕｃｔ”
は、要求が新しい化学製品を含んでいるかどうかを示す
。

幾つかのデータは必須である。例えば、主題、及び請求
されるべきプロジェクトである。

ユーザの便宜のために、幾つかのデータがシステムによ
って検索可能である。それは、例えば。

関係するシステム・ユーザが属する会社の部門により実
行されるプロジェクトのリストを調べることを可能にす
るなど役立つ。従って、探索がプロジェクト″フィール
ド″のために利用できる。

ユーザがこのフィールドにカーソルを設定してＰＦＩを
押すと、部門番号を尋ねられ、システムはその部門につ
いてのプロジェクト・リストを表示する。ユーザはこれ
らのうちから１つを選択することができ、要求のフィー
ルドは選択されたプロジェクトで自動的に埋められる。

ヘッダが埋められるとき、ユーザは残りの項目を埋めな
ければならない。ユーザはＰＦＩＯを押して項目パネル
を得ることができる。１以上の項目が入力されるとき、
項目パネルの前でＸをタイプすることにより１つの項目
を選択することができるし、又はＲ，Ｄ或いはＡをタイ
プしてそれを繰り返したり削除したり或いは新しい項目
を付加したりすることができる。

Ｅ　Ｎ　Ｔ　Ｅ　Ｒキー又はＰＦキーを押すことにより
、トリビアル・データ・チエツクキングをトリガするこ
とができる。チエツクキングが失敗すると。

要求された行為が実行されず、エラー・メツセージが表
示され、カーソルはエラーが検出されたフィールドに位
置し、そのフィールドは逆映像で強調表示される。

第２画面（ＰＦＩＯを押すと表示される）では、ユーザ
が購入要求の特定項目についてのデータを全て埋める。

幾つかのデータは必須である。例えば、購入者コード、
配達の週、量、少なくとも１行の記述又は部品番号であ
る。

幾つかのデータはオプションとなっている。例えば価格
要求参照、部品番号、項目単価、測定単位、　Ｅ　Ｃ（
Ｅｎｇｉｎｅｅｒｉｎｇ　Ｃｈａｎｇｅ）即ち技術変更
のレベル、ヘッダと異なる場合のみ埋められなければな
らない項目プロジェクト及び相補記述ラインである。

カーソルを被選択フィールドに設定したＰＦＩを押すこ
とにより、次の項目について探索プロシジャが利用でき
る。即ち１価格要求参照、購入者コード、部品番号、配
達の週、又はプロジェクトである。

ユーザは１項目についての相補記述の何ラインをタイプ
することができる。コマンド領域によって、ラインを加
えたり、繰り返したり又は削除したりすることができる
。ＰＦ７及びＰＦ８によってスクローリングができる。

他のＰＦキーも用いられる。即ち、 ＰＦ２　　ヘッダ画面へ行く。

ＰＦ３　　表示された項目を繰り返して新しいものを作
成する。

ＰＦ４　　ブランク項目を加える。

ＰＦ５　　承認において送信する前の全てのオペレーシ
ョン（以下参照）。

ＰＦＩＯ存在するなら次の項目を表示する。

ＰＦＩＩ　　存在するなら前の項目を表示する。

ユーザがＰＦＩ　２を押すると、システムは次の画面を
示す。

ユニから、ユーザは次のことができる。即ち、ＰＦＩ：
全ての承認者が後に見ることができるように文書を見る
。

ＰＦ２　：文書データを変更する。

ＰＦ４：全ての承認者が見るであろうフリー・コメント
を加える。

ＰＦ５　：承認において送信の準備をする（以下参照）
。

ＰＦ６：原稿文書として入力されたデータをセーブする
（そして後にそれを検索する）。

ＰＦ８　：文書を印刷する６文書の印刷イメージは、゛
′印刷ファイルパと呼ばれるファイル中に付加される。

ユーザは、セツションの終了時にこのファイルを印刷す
ることができる。

堤供されたフィールド中で”　Ｄ　Ｅ　Ｌ　Ｅ　Ｔ　Ｅ
　”をタイプして、処理中の原稿を消去する。

上記のように定義されたＰＦキー機能の幾つかは、自明
である６他のものは多少の説明を必要とする。例えば、
ＰＦ４のキーを押すことにより、ユーザは画面に次のよ
うな項目を得る。

ユーザはフリー・コメントをタイプして、ＰＦキーを以
下に記述されるように用いることができる。

ＰＦ２　　カーソル位置の下にブランク・ラインを付加
する。

ＰＦ３　　最後の変更をセーブすることなく残す。

ＰＦ８　　カーソルが存在するラインを削除する。

ＰＦＩＯ及びＰＦＩＩ　　コメント・ファイルを通って
前及後にスクロールする。

ＰＦ１２　　コメント・エントリをセーブして残す。

上記のようなオペレーションは、第１０図の自明なフロ
ーチャートに要約されている。

この時点まで至ると、承認処理に提示される準備の整っ
た十分に作成された文書へ処理は移る。

それ故に、ユーザがデータ・エントリ・パネルからか又
は“Ｐｒｏｃｅｓｓ　ｐｒｅｐａｒｅｄ　ｄｏｃｕｍｅ
ｎｔ　（準備された文書を処理する）″からＰＦ５を押
すと、システムは以下のオペレーションを実行する。

まず、それは文書データを全てチエツクする（チエツク
を完了する）。エラーが見つかると。

システムは再びデータ・エントリ・パネルを表示する。

このパネルでは、エラー・データを有するフィールドが
カーソルによって示されている。それから、それは、関
係する職務、関係する文書のタイプについて割当てられ
た特定のルール、及び文書データ（第１４図参照）に基
づいて承認経路を決定する。

エラーが見つかると、メツセージ“Ｕｎａｂｌｅ　ｔ。

ｄｅｔｅｒｍｉｎｅ　ａｐｐｒｏｖａｌ　ｐｒｏｃｅｓ
ｓ　（承認処理を決定することができない）”が表示さ
れ、何ら行為は実行されない。

最後に、それは、承認処理の各職務について。

現時点の行為者及び肩書を有する者を決定する。

その結果が、評価のために以下に示されるように、考慮
されるユーザ（創作者）に表示される（第１５図参照）
。

ユーザがＰＦＩ　２を押すと、　　”Ｐｒｏｃｅｓｓ　
ｔｈｅｄｏｃｕｍｅｎｔ　（文書の処理）″メニューに
戻る。

さもなければ、ＰＦＩを押すことにより、ユーザは幾つ
かの制御及び制限を伴なって承認リストを変更すること
ができる（第１５図及び第１６図を参照して以下に示す
）。

ユーザがＰＦ７を押すと、文書が作成され、承認処理に
おける最初の職務の行為を待つ（第１５図及び第１６図
参照）。

第１１図には、既に埋められた文書において達成可能な
オペレーションを要約したフローチャートが示されてい
る。ユーザは、５ＥＡＬＩＮＧのメイン・メニュー中で
ＰＦ２を押すことにより又はコマンドとして５ＥＡＬＩ
ＮＧ　　ＡＣＴ　　ＯＮと直接タイプすることにより、
ユーザの行為を待っている文書を実行することができる
。

５ＥＡＬＩＮＧがＩＢＭ　　ＰＲＯＦＳのアプリケーシ
ョンとリンクしているときには、５ＥＡＬＩＮＧの文書
が待ち行為にあるとすると、機能キーを押したとき、ユ
ーザは”０ｐｅｎむｈｅ　Ｍａｉｌ　（メールを開ける
）″とラベルされたメツセージを得る。そのメツセージ
は次のようなものである。即ち、 それからシステムは、まず、以下に示されているように
文書の種類リストを示す。

第１１図のフローチャートに示されているように、ユー
ザは適切なＰＦキーを押すことにより種類を選択しなけ
ればならない。ユーザが種類を選択したときには、シス
テムは選択された種類におけろ文書のリス１−を表示す
る。文書の種類がただ１つのみであるなら、最初の画面
は回避される。

る。結局は５追加画面をスクロールすることが必要とな
ることもある。ユーザは、ＰＦＩＯ及びＰＦｉｌを夫々
用いてスクロールアップ及びスクロールダウンを行なう
ことができる。

１つの文書を選択することは、次のような画面を表示す
る対応するＰＦキー（ＰＦＩ乃至ＰＦ８）を押すことに
より達成される。

文書のリストは、要求行為の日付によって記憶され、よ
り最近のものがリストの一番上に位置すユーザは、この
画面上で、文書のタイプ及び参照、主題創作者の名前、
誰がすぐ前の承認者であったかということ、及びこのす
ぐ前の承認者からのパーソナル・コメントを見ることが
できる。また、現ユーザが勤めるように頼まれている職
務が述べられ、そのユーザが委任されているなら結局そ
の職務についての所有者も述べられる。

ＰＦＩを押すことにより、ユーザは文書についての全て
の情報を見ることができる。即ち、文書自体、その文書
を既に実行した承認者の決定を伴なう承認者リスト及び
あれば承認者のコメントである。

ＰＦ４を押すことによって、ユーザは、文書全実行した
後で自分のコメントを他の承認者のコメントに付加する
ことができる。

ＰＦ５は、全ての承認者には利用できない。このＰＦキ
ーは、文書が元来その職務にデータを付加又は変更する
権限を持たせるように適合されているなら、そのような
ときにのみアクティブになる。この場合には、ユーザは
、データ変更パネルを示されて、文書中にデータを付加
又は変更することができる。これらの変更は、承認経路
処理に影響を及ぼし得る。

ＰＦ７は、文書を実行するのに用いられなければならな
い。

ユーザが許可者なら、ユーザは次のような画面を見るこ
とができる。

られる）。

ユーザはＰＦＩで文書を許す（承認する）ことができる
。システムは、以下のような確認パネルを表示する。

ユーザは、ＰＦ７を押すことによって承認者リストを変
更することができる（画面の後の方に見次の画面は１次
の承認者を示し、ユーザが上記のような次の承認者の注
意用のパーソナル・コメントのラインをタイプできるよ
うにする。

ユーザが最後の承認者なら、確認パネルは、異なってい
て１次のようである。即ち。

許可によって文書の終了が意図される。

許可者は文書を拒絶することもできる。システムは、次
のような確認パネルを表示する。

システムは、確認のない場合には文書が拒絶され、情報
が創作者と文書を既に実行した各承認者とに送信される
であろうことを示しながら、ユーザにその決定を確認し
てくる。

ユーザはまた、他の承認者からの付加情報を要求するた
めにＰＦ３を選択することも可能である。

この場合には、ユーザは次のような画面において承認者
を選択しなければならない。

ユーザは、創作者、文書を既に実行した承認者。

又は文書をまだ見ていない承認者を選択することができ
、次のような確認パネルを得る。

ユーザが確認するなら１文書は選択された承認者のため
に利用できるし、ユーザは、この承認がその文書を実行
した後で再びそれを取戻す。ユーザが承認処理において
受信者なら、ユーザは次の画面を示される。

認が必要とされる。システムは、次の承認者のリストに
許可が存在するかどうかを決定する。次の承認者のリス
１へに許可者が存在しないなら、システムは、既に文書
を実行した許可者の中からユーザに選択するように尋ね
て、文書を選択された許可者はへ送り戻すことになる。

この選択された許可者は、自分の先の許可を確認するか
又は文書を拒絶しなければならないであろう。

文書が情報のためにのみ受取られるなら、ユーザは次の
画面を示される。

たとえユーザが最後の承認者であってもなくても、２つ
の異なる確認パネルが存在することになる。追加情報の
オペレーションの要求は、許可行へ要求されるのと全く
同じである。評価者は文書を拒絶することができないこ
とを注意すべきである。評価者は、文書をただ不承認す
ることができるだけである。その場合には、さらに許可
者の承ユーザは、幾つかの例においてそのような情報を
受取ることができる。ユーザは創作者であることもあり
、文書は受諾されている。従って、行為は目下実行の途
中にある。さもなければ１文書は、許可者によって拒絶
されているか又は創作者によって取消されている。そし
て、ユーザは、創作者か既に文書を実行した承認者のい
ずれかである。

ＰＦ４は、上記文書への参照覚え書きを取消すような効
果を有している。ユーザは、コンサルテーション（ｃｏ
ｎｓｕｌｔａｔｉｏｎ）ファシリティを用いて常に文書
をアクセスすることができる。

ＰＦ５は１文書が拒絶されたときにのみこの画面上で利
用できる。それによって、創作者は文書データの全てを
検索して、何らかの修正をし、−希望するなら迅速に送
り戻す（新しい参照で）ことができる。

明らかに、ユーザは、メイン・メニュー中でＰＦ３を押
すことにより又は直接コマンドとして５ＥＡＬＩＮＧ　
　Ｃ０Ｎ５ＵＬＴとタイプすることにより、創作した又
は実行した文書を調べることができるべきである。

それから、次のようなメニューがユーザに示される。

ユーザは、幾つかの代替方法を用いて文書をアクセスす
ることができる（第１２図参照）。

ＰＦＩ　：ユーザが創作して目下承認処理にある文書に
ユーザをアクセスさせる。

ユーザにより１は、人が対応する職務を割当てたことを
意味する。

ＰＦ２　：ユーザが処理して目下承認処理にある文書に
ユーザをアクセスさせる。

ＰＦ３　：ユーザが変更できる２つの日付の間でユーザ
が創作した全ての文書を、それらの状況がどのようであ
ろうと（進行中であったり、終了させられたり、拒絶さ
れたり、取消されたり・・・）。

ユーザにアクセスさせる。

ＰＦ４：ユーザが変更できる２つの日付の間でユーザが
実行した全ての文書を（それらの状況がどのようであろ
うと）ユーザにアクセスさせる。

ＰＦ５：フオーム特有の基準で発行された文書をユーザ
にアクセスさせる。

どんなＰＦキーが選択されても、その結果は、”ｎｏ　
ｄｏｃｕｍｅｎｔ　ｆｏｕｎｄ　（文書が見つからない
）″というメツセージか又は以後示されるような見出さ
れた文書のリストのいずれかになる。

ユーザがＰＦＩ乃至ＰＦ４を選択すると、１以上の種類
が用いられているときにはいつでも、見出されるフオー
ム種類のリストが表示される。さもなければ、”Ｌｉ５
ｔ　ｏｆ　Ｄｏｃｕｍｅｎｔｓ　Ｆｏｕｎｄ　（見出さ
れる文書のリスト）”が表示される。

クロールすることができる。見出される各文書に対して
、表示される情報は次のものを含む。即ち、主題、状況
、ユーザが文書をアクセスすることができるための職務
、行為の日付である。

ユーザがＰＦ５を選択するなら、ユーザは、まず種類間
で選択をしてからその１つの種類内のフオームをアクセ
スしなければならないであろう。

照会において更に正確さを要求する基準エントリ・パネ
ルが表示される。ユーザは一般支出購入要求を選択して
いるので、次のような画面が表示される。

見出される文書が８つ以上存在するなら、ユーザはＰ　
Ｆ　１．　Ｏ及びＰＦＩＩを用いてリスト中をスユーザ
は探索用の基準を入力しなければならばい。ユーザがブ
ランクを残すと、システムは最も大きな照会と解釈する
。例えば、量が埋められていないと、システムはＯから
９まで探索する。システムは、ユーザが入カキ−を押す
ときは探索を始める。

ユーザが文書を選択するとき、表示される画面は文書の
状況によって変わる。

その状況がパ丁ｎ　ｐｒｏ（Ｈｒｅｓｓ　（進行中）″
であるなら、ユーザは次のような画面を表示される。

ユーザは。

文書（データ、承認者リスト及びコメント）を見ること
ができる。

文書をコピーして原稿を作成することができる。

文書を印刷することができる。

ユーザが創作者なら、ユーザはまた文書を取消すことも
できる。この場合には、ユーザは次のような確認パネル
を表示される。

”Ｐｒｏｃｅｓｓ　ｔｈｅ　ｄｏｃｕｍｅｎｔ　ｆｏｕ
ｎｄ　（見出される文書を処理する）”メニュー中でＰ
Ｆ７を押すことにより、文書を既に実行している創作者
又は承認者は、文書を創作したとき又は文書を実行した
ときに行なうことができるように承認者リストを変更す
ることができる。

変更が準備されたとき、システムは次のパネルを表示す
る。

変更が全て正しいなら、ユーザはＰＦＩを押して、文書
を新しい承認者リストで進めることができる。

ＰＦ１２は全ての変更を取消す。

文書の状況が″進行中″でないなら、利用できる行為は
、以下に示されるように異なっている。

ユーザは、 文書（データ、承認者リスト及びコメント）を見ること
ができる。

文書をコピーして原稿を作成することができる。

文書を印刷することができる。

追跡情報もまた、ユーザがＰＦ４を押すと与えられ得る
。これらの情報は、文書を処理しなければならない者に
よってどの行為がとられているのかを示す。例えば、購
入要求に対して、システムは、供給者へ送られるオーダ
について追跡して報告し続け、供給者の配達日、既に受
取っている量等を示す。

上記に説明されたコンサルティング・オペレーションの
全てが、第１２図の自明なフローチャートに要約されて
いる。

５ＥＡＬＩＮＧメイン・メニュー上でＰＦ５を押すこと
により、ユーザは、誰か他の者の行為を待っている文書
のリストをアクセスすることができる。次のような画面
が表示される。

条件下で一方のユーザから他方へ委任され得る２ユーザ
は、５ＥＡＬＩＮＧメイン・メニュー上でＰＦ７を押す
ことにより又は直接コマンドとして５ＥＡＬＩＮＧ　　
ＤＥＬＥＧＡＴＥをタイプすることにより、システムの
この部分をアクセスすることができる。

ユーザは、次のような画面を示される。

ユーザは、ユーザ識別子フィールドを埋めて入カキ−を
押さなければならない。ユーザ識別子がわかっていない
なら、エラー・メツセージが表示される。ユーザ識別子
がわかっているなら、システムは、行為を待っている文
書を捜して参照を与える。明白な安全保護のために、文
書についての更に情報は何ら得ることはできない。

承認者の指定は、既に述べたように、定義済み画面は、
上記ユーザが目下肩書きを有する職務のリストを含む。

各職務に示されたユーザ識別子が、この職務についての
実際の行為者のユーザ識別子である。だれでもこのユー
ザ識５３１子を変更して、委任を示したり又は自分自身
のユーザ識別子を設定することができ、そして自分の権
限を検索することができる。

ある職務に対しては、委任は許されないことがあり得る
。ユーザは委任のためにこの画面を用いることはできな
い、ユーザは責任ある職務（例えば、財政部門）に委任
を登録するように尋ねなければならない。しかしながら
、ユーザはどの職務についても自分の権限を検索するこ
とができる。

ユーザ識別子フィールドをブランクにすることもできる
。この場合には、システムはユーザを不在であるとみな
す。この特徴は、例えば承認者が文書を実行していると
きに文書へのアクセスを妨げるために用いられる。それ
で、創作者及び承認者は、通知されてこのような状態に
対応することができる。

ユーザのエントリを確認するために、ユーザは入カキ−
を押さなければならない。ＰＦＩを用いることにより、
ユーザがその名前又はニックネームによってのみ知る誰
かのユーザ識別子を検索することができる。ユーザはＰ
Ｆ５を押して委任の予知（ｄｅｌｅｇａｔｉｏｎ　ｐｒ
ａｖｉｓｉｏｎ）を入力することができる。ユーザは、
ユーザが自分の委任について予知の日付をタイプするこ
とができる画面を示される。

この場合に、委任は直ちには有効とはならず、選択され
た日にシステムによって自動的に設定される。上記のよ
うに説明した委任処理は、第１３図のフローチャートに
要約されている。

大会社のような環境では、−時的な汎用計算機の委任が
、休暇のため又はその他の理由で不在の誰かに取って代
わるのに必要となることがある。

これらの事情のもとでは、記憶データ及びあるユーザに
属するどの情報も、他のユーザ（選任者）に転送される
必要がある。これは、ＶＭ環境において、ＶＭ計算機を
ある個人から他の人へ転送する二泊により達成される。

これらの事情のもとでは、しかしながら、サインの委任
は正式に要求されないなら、妨げられるべきである。

ニー＋ｌ’ｌｉ、５ＥＡＬＩＮＧのメイン・メニュー中
でＰＦ８を押すことにより又は直接コマンドとして５Ｅ
ＡＬＩＮＧ　　ＥＡＳＰＲＥＴをタイプすることにより
、このアプリケーションをアクセスすることができる。

そして、次の画面が表示される。

ユーザは、受信者（選任者）の通し番号を埋めなければ
ならない。必要なら、ＰＦＩが操作援助を提供すること
ができる。受信者の正しい識別子が与えられると、次の
ような画面が表示される。

ユーザが５ＥＡＬＩＮＧのメイン・メニュー上でＰＦ８
を押すか又はコマンド・ライン上で５ＥＡＬＩＮＧ　　
ＥＡＳＰＲＥＴをタイプしたとき、そしてＶＭが予め転
送されていると宣言されたときには、次の画面がユーザ
に示される。

ユーザは、被選択者の完全な識別子を見ることができる
。ユーザは、オプションのコメントをタイプして、タイ
プされたときには現われない保護コードを２度タイプし
なければならない。このコードは、計算機転送を取消す
のに必要となる。

ユーザの転送を取消すために、ユーザは、転送を登録し
ているときには、選択した保護コードをタイプしなけれ
ばならない。

機能的な観点からばかりでなく技術的な観点からも本発
明に含まれる手段は説明されたので、承認システムのオ
ペレーションは十分に理解できる。

第１４図乃至第１７図に承認システムのオペレーション
が要約されており、第１８図に職務管理が要約されてい
る。

第１４図乃至第１６図には、承認者のリス１−の決定に
含まれる手段が表示されている。明らかに、オペレーシ
ョンを説明するのを簡単にするために、システムは簡単
な場合に制限されている。埋められた文書（例えば、購
入オーダ）は、プロジェクト・コー１−と、購入者コー
ドと、購入要求ユーザにより設定された支出額とを含ん
でいるとする。

ソフトウェア手段は、プロジェクト・コード参照を用い
て、第１の特定職務テーブル（Ｆ　ａ　Ｍ　Ａ　ＮＡＤ
ｌ）をアドレス指定し、北記プロジェクトに関与してい
る会社の部門の参照をそこから取り出す。更に、講入値
がしきい値（１００００）を賊えるなら、第２テーブル
（ＦａＭＡＮＡＤ２）がアドレス指定される必要がある
。その上、支出を含む文書のタイプのために、ロジック
は、投資責任（ＩＮＶＴ）を必要な承認者のリストに加
える。

同様に、購入者（ＰＵＲＣ）にも適用される。ＦＵ　Ｔ
　Ｕ及びＤＯＮＥとして夫々指定された文書創作者ＶＭ
ユーザの計算機メモリ中に位置する２つの別々のテーブ
ル中に、システムは情報をロードする。ＤＯＮＥテーブ
ルは、システムが対応する文書へ読取り専用のアクセス
を可能にさせるいわゆるパ陰の（ｓｈａｄｏｉｉ）　”
承認者即ち仮想承認者を含む、既に述べたように、−旦
承認処理を開始すると、定義済みルールに基づいて創作
者はある程度まで承認者のリストを修正することは可能
である。例えば、承認者のリストから第１ラインのマネ
ージャを削除することは、第２ラインのマネージャの自
動的な挿入をトリガすることになる。以下同様に行なわ
れる。

決定を送る創作者は、ＦＵＴｔＪテーブルからＮＥＸＴ
ＷＡ　ＩＴ子テーブル第１承認者の参照をアンロードす
る効果を及ぼす。一方、その他は事前設定で順序付けら
れたリスト中のＮＥＸＴＦｔＪＴＵテーブル中にロード
される。両テーブルＮＥＸ′「は、ユーザのＶＭ計算機
中に存在する。陰の承認者はＮＥＸＤＯＮＥテーブル中
にロードされる。

上記のテーブルは、対応するＳＱＬデータ・ペース・テ
ーブル、即ち、５ＥＡＬＢＤＡ計算機のＡＰＰＦＵＴＵ
、ＡＰＰＷＡＩＴ及びＡＰＰＤＯＮＥを作成して更新す
るためのシステムによって用いられる。

５ＥＡＬＩＮＧシステムはまた、行為が第１６図中に表
わされたように制御される指定された承認者への承認要
求を送信することも制御する。

ＮＥＸＴＷＡＩＴ中の指定された承認者は、自分自身の
ＶＭ計算機中の対応するＳＱ［、／ＤＳテーブルからＦ
ＵＴｔＪ、ＷＡＩＴ及びＤＯＮＥのテーブルにおけるデ
ータへのアクセスを得る。それから、ＮＥＸＴＦＵＴＵ
、ＮＥＸＴＷＡＩＴ及びＮ　Ｅ　Ｘ　Ｔ　Ｄ　ＯＮ　Ｅ
が、ＦＵＴＵ、ＷＡＩＴ及びＤＯＮ　Ｅのテーブルから
夫々設定される。これらのテーブルの内容は１次のよう
なオペレーションを実行して記録するために、現承認者
によって用いられる。

承認者リストの変更。承認者は、創作者ができたように
リストを修正することが可能である。

承認処理に対する変更。現承認者のために文書のデータ
への修正により制御されるシステムは承認経路を修正す
る。

承認者の妥当性検査。承認者指定ルールを有する承諾（
ｃｏｎｐｌｉａｎｓｅ）テストが実行される。

テーブルの更新が実行される。即ち、−旦現承認が実行
されると、次の承認者によってシフトが行なわれ、ＮＥ
ＸＴＦＵＴＵがＮＥＸＴＷＡＩＴヘシフトされる。

一旦進められると、現承認データが用いられて。

付加、変更、又は削除のオペレーションを介してＳ　Ｑ
　Ｌ　／　Ｄ　Ｓテーブルが更新される。それらのデー
タは、次の承認者の行為等に利用できる。

人為的エラー又は任意オペレーションのいずれかのため
による誤承認を制限するかなり高度な機密保護レベルが
、本発明では提供されている。まず、承認、即ち考慮さ
れる文書を特徴付ける所定フィールド中へ“Ｙ”又はＩ
Ｉ　Ｎ　ＩＩのフラッグを挿入することが、ＳＱＬ／Ｄ
ＳのテーブルＡＰＰＤＯＮＥ中へ行なわれ、このテーブ
ルは、さもなければ読取り専用でユーザへアクセス可能
であることは、注意すべきである（第１６図のＭＹＳＩ
ＧＮＡＴ参照）。次に、サイン妥当性チエツクを含む所
定のＳＱＬコマンドの実行の際にのみ、上記″サイン（
ｓｉｇｎａｔｕｒｅ　）　”即ち承認の挿入が行なわれ
る。そのようなサイン妥当性オペレーションのフローチ
ャートが第１７図に示されている。ＭＹＳＩＧＮＡＴ順
にトリガーされるＳＱＬコマンドにより、種々のＳＱＬ
テーブルがアクセスされ。

そこに記憶されているデータを集める。これは、目下承
認又は不承認しようとしているユーザが確実にそうする
権利を与えられるようにするためである。第１のＡＰＰ
ＷＡＩＴテーブルは、　ｔｙｐｄｏｃ／ｒｅｆｄｏｃに
より定められる考慮される文書が確実にそこで待ってい
るようにするために、アクセスされる。Ｔｙｐｆｕｎ／
Ｒｅｆｆｕｎにより定められる職務は、ユーザの職務と
もまた適合すべきであり、ＦＵＮＣＴＩＯＮテーブルに
より提供されるように職務参照及び実行の資格取得（ａ
ｃｔｉｎｇ　ｈａｂｉｌｉｔａｔｉｏｎ）でクロスチエ
ツクされるべきである。その上、ＶＭ計算機があるユー
ザから他へ転送される（そして、ＩＮＰＲＥＴテーブル
中に記録される）こともあるので、ユーザ識別子／ノー
ド識別子と現ユーザとの一致がチエツクされる。ＡＰＰ
ＤＯＮＥテーブル中への挿入は、データ及び時間だ一緒
に、肯定的なサイン妥当性テストの結果によって可能に
なる。

同じ承認システムに接続されたユーザの母集団が、第１
８図に表わされているように、固有なＳＱＬテーブル、
即ち、ＦＵＮＣＴＩＯＮテーブル中で管理されている。

各職務に対して、即ち、マネージャ、購入者等に対して
、ユーザがアクセスを“許可されている（ｇｒａｎｔｅ
ｄ）”　（ＳＱＬ用語）とすると、対応する職務へのユ
ーザのアクセスを制限するようにＳＱＬビューが定義さ
れる。システムは、各職務内で肩書きを有する者の指定
を作成して管理する責任のある職務の″オーナ（ｏｗｎ
ｅｒ）　”へのアクセスを許可されている。幾つかの職
務及び肩書きを有する者は、既に他のシステムにはわか
っていることもある（例えば、通常の人事部門のデータ
・ベース内では）。その場合には、ｌ！務テーブルの更
新は、両方の関係するデータ・ベースを連続するプログ
ラムにより直接実行される。同様のアプローチもまた、
いわゆる特定の特性テーブルを設定して維持するために
用いられる。

Ｆ１発明の効果 本発明により、事前記憶されたブランク・フオーム・ラ
イブラリをアクセスし、フオームを選択し、そのフオー
ムを埋め、埋められたフオームのデータとシステムの接
続されたユーザの母集団の範囲内でユーザの仕事即ち職
務を参照する特定の定義済み承認ルールとに基づいて承
認経路を計算し、対応する承認オペレーションをモニタ
して制御するようなシステムが、達成された。

【図面の簡単な説明】

第１図は、本発明が実施されるディジタル・ネットワー
クを示す説明図、第２図は、第１図のネットワークの１
部分を示す説明図、第３図は、本発明を実施するための
基本的なシステム構成を示す説明図、第４図は、本発明
を実施するためのフローチャート、第５図は、本発明の
ソフトウェア構成を示す説明図、第６図は、本発明を概
念的に示した説明図、第７図は、本発明に用いられるシ
ステム・テーブルのマツピングを示す説明図、第８図は
、文書の構造を示す説明図、第９図は、本発明で処理さ
れる文書をアクセスするためのフローチャート、第１０
図乃至第１３図は、本発明を実施するためのフローチャ
ート、第１４図乃至第１７図は、本発明を実施するため
の詳細なフローチャート、第１８図は、本発明で用いら
れるテーブルを示す説明図である。 代理人　　弁理士　　山　　本　　仁　　朗他のノード
へ ｌｌｌｌ図 ホスト・コンピュータ ターミナル １１１２図 第４図 エントリ 第５図 第６図 第１５図 文書へのアクセス １１１９図 入力 １１１Ｎ図 第＋ＯｖＡ 第」２図 承ＩＩ者実行期間中の承認テーブル処理第１６図 文書創作期間中の承認テーブル処理 サイン妥当性検量 第１７図

Claims (1)

1. 【特許請求の範囲】 ディジタル・ネットワークに接続されたターミナルと、
   計算機手段、メモリ及び個々のユーザに割り当てられた
   ソフトウェア・ファシリテイを含む仮想計算機と、ター
   ミナルからユーザへメールされる電子文書を作成し、処
   理し、モニタする手段とを含み、各ユーザがシステム接
   続されたユーザの母集団の範囲内で少なくとも１つの職
   務を割り当てられている電子メール・システムにおいて
   、システムの選択されたユーザによる電子的な承認によ
   ってサインを必要とするユーザ創作の文書の処理を制御
   する承認システムであって、 各システム・ユーザの職務及びアドレスが識別される職
   務テーブルを記憶し、更新する手段と、文書のフォーム
   を記憶する手段と、 ユーザの職務及び文書のフォームの内容に基づく定義済
   み承認ルールを記憶する手段と、 内容が承認を受けることになっているフォームを選択し
   、選択されたフォームをアクセスして埋めて処理し、メ
   ールするターミナル制御可能手段と、 上記メールすることに応答して、上記職務テーブルをア
   ドレス指定し、上記承認ルールに基づき、システム接続
   されたユーザ間で承認経路を決定する手段と、 上記承認経路決定に応答して、上記埋められたフォーム
   についてのメール及び処理をモニタする手段と、 を含む電子文書承認システム。