JP3267066B2 - ワークフロー支援システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数の情報処理装置が
ネットワークによって接続された分散環境におけるグル
ープワークおよびワークフローの支援を行なうワークフ
ロー支援システムに関するものである。

【０００２】

【従来の技術】一般にワークフローとは、仕事の流れを
指す。例えば、会社の中で、ある人が物品の購入を行な
う場合を考える。その人は、まず、購入伝票を作成し、
上司のもとへ作成した購入伝票を持って行く。上司は購
入伝票をチェックし、承認印を押して経理部門へ購入伝
票を回す。経理部門では、購入伝票に基づき、物品を発
注する。以降、まだまだ仕事は続くが、ここまでの仕事
の流れを見てもわかるように、購入伝票がある人からそ
の上司へ、また、上司から経理部門へと流れ、仕事が進
んで行く。このような仕事の流れをワークフローと呼ん
でいる。

【０００３】ここで、購入伝票を作成する仕事、購入伝
票をチェックして承認印を押す仕事、物品を発注する仕
事などは、それぞれが仕事の単位であり、各仕事の単位
をタスクと呼ぶ。ワークフローは、タスクの列であると
いうことができる。また、各タスクは、さらに複数のタ
スクに分割されることもある。各タスクは、上述の例の
ように人が行なう仕事の場合もあるし、また、例えば、
データベース検索のように、コンピュータが自動的に行
なう仕事の場合もある。

【０００４】近年の情報処理装置の普及から、それぞれ
の仕事を行なう現場に端末などの情報処理装置を配置
し、これらの複数の情報処理装置をネットワークで接続
した分散環境が構成されている。各情報処理装置のユー
ザは、それぞれ受け持ちの仕事を行なうことになる。

【０００５】従来より、このような分散環境において、
複数の情報処理装置のユーザにまたがるワークフローを
支援するシステムの開発が進められている。それらのシ
ステムは、多くの場合、電子メールに基づいている。電
子メールとして送られるドキュメントの配送経路を定義
することによってワークフローを定義する。例えば、上
述の購入伝票の例では、購入伝票の作成者から上司を経
て経理部門へ至る配送経路を定義し、購入伝票を電子メ
ールとして送る。この電子メールに基づくシステムで
は、基本的にドキュメントがユーザ環境を移動し、移動
した先で手続きを実行したり条件を評価することによっ
て、さらに次の行き先を一意に決定する。配送経路にい
くつかの選択肢がある場合には、各々の経路に進む条件
が定義され、ドキュメントの特定の部分などを状態とし
て参照することによって、１つの経路を決定する。この
ような配送経路をグラフィカルユーザインタフェースを
用いて定義するシステムもある。

【０００６】このように、従来のシステムでは、ドキュ
メントの配送経路を自動的に決定することによって、ワ
ークフローを実現するものであり、ドキュメント主導の
システムである。手続の管理については、全てサーバで
管理するものや、各ユーザ環境ごとに管理するもの、あ
るいは配送されるドキュメントに埋め込むものなどがあ
る。

【０００７】しかしながら従来のワークフロー支援シス
テムでは、電子メールが順に送られて行く宛先を最初か
ら決定しておかなければならなかった。また、ワークフ
ローのためにルールが手続的に記述することのできるシ
ステムも開発されているが、やはり一意に宛先が決定す
るように、手続きの記述を行なわなければならない。こ
のとき、例えば、次のタスクに進む前に値が確定しなけ
ればならない変数が各タスクごとに決定されている場合
もあり、記述する手続きは複雑にならざるを得ないとと
もに、ワークフローのルールに記述されたタスクの実行
順序に柔軟性を持たせて実行することができない。

【０００８】また、あらかじめ想定し、ルールに記述し
ておくことができないような例外が発生した場合の対処
が極めて困難であり、例外が発生した時点のみならず、
以降のワークフロー全体に関してシステムの利用が不可
能となるという問題もある。

【０００９】

【発明が解決しようとする課題】本発明は、上述した事
情に鑑みてなされたもので、あるワークフローの全体に
ついてや、厳密にその条件や順序を知らなくても、ユー
ザが、各自の近傍の把握している条件や仕事のやり方を
ルール化するだけで、その部分が自動化でき、また、そ
れらの部分フロー間や、まだルール化されていないため
に人間が行なったタスクとのつながりを管理し、自動的
にフロー全体の実行や、成果物の受け渡しを制御しワー
クフローを支援するワークフロー支援システムを提供す
ることを目的とするものである。

【００１０】

【課題を解決するための手段】本発明は、請求項１に記
載の発明においては、ネットワークによって接続された
分散システムを用いてワークフローを支援するワークフ
ロー支援システムにおいて、発生したタスクに対するル
ールの適用の可否を判定するための条件部とタスク列で
ある実行部からなりあるタスクから次に実行すべきタス
ク列への展開を宣言的に記述したワークフローのための
ルールを格納する複数のルール群格納手段と、該ルール
群格納手段のそれぞれと対応して設けられ対応する前記
ルール群格納手段に格納されたルールに含まれる前記タ
スクを起動するルール解釈実行手段と、起動された前記
タスクに対して適合する条件部を持つルールをタスクの
起動時に選択し選択されたルールを保持する前記ルール
群格納手段と対応して設けられた前記ルール解釈実行手
段に前記タスクを受け渡すルール選択手段を有し、前記
ルール選択手段は、選択されたルールがタスクを起動し
た前記ルール解釈実行手段に対応したルール群格納手段
に存在しないとき他のルール解釈実行手段に前記タスク
を受け渡し、前記ルール解釈実行手段は、前記ルール選
択手段により受け渡されたタスクに適合する条件部を持
つルールの実行部のタスクを順次起動することを特徴と
するものである。

【００１１】また、請求項２に記載の発明においては、
ネットワークによって接続された分散システムを用いて
ワークフローを支援するワークフロー支援システムにお
いて、発生したタスクに対するルールの適用の可否を判
定するための条件部とタスク列である実行部からなりあ
るタスクから次に実行すべきタスク列への展開を宣言的
に記述したワークフローのためのルールを格納する複数
のルール群格納手段と、該ルール群格納手段のそれぞれ
と対応して設けられ対応する前記ルール群格納手段に格
納されたルールに含まれる前記タスクを起動するルール
解釈実行手段と、起動された前記タスクに対して適合す
る条件部を持つルールをタスクの起動時に選択し選択さ
れたルールを保持する前記ルール群格納手段と対応して
設けられた前記ルール解釈実行手段に前記タスクを受け
渡すルール選択手段と、ユーザが入力を行なうユーザイ
ンタフェースを有し、前記ルール解釈実行手段は、前記
ルール選択手段により受け渡されたタスクに適合する条
件部を持つルールの実行部のタスクを順次起動するとと
もに、起動すべきタスクに対して適合する条件部を持つ
ルールを選択する際に前記ルール群格納手段のいずれに
も選択すべきルールが保有されていない場合には該タス
クが起動できなかったことを第１の失敗状態として検出
し、前記ユーザインタフェースは、前記ルール解釈実行
手段において第１の失敗状態が検出されたとき前記起動
できなかったタスクの情報をユーザへ通知するとともに
該通知に応じてユーザが行なう前記起動できなかったタ
スクの実行または実行の成果の入力を行なうことを特徴
とするものである。

【００１２】請求項３に記載の発明においては、請求項
２に記載のワークフロー支援システムにおいて、前記ル
ール解釈実行手段は、起動したタスクが強制的にあるい
はシステムの定義した条件により第２の失敗状態となっ
たことを検出し、第２の失敗状態となったタスクに対し
てすでに適用したルールとは別のルールであって適用可
能なルールを再選択し、選択されるべきルールが存在し
ない場合にはこれを第１の失敗状態として検出し、該第
１の失敗状態が回復しない場合には第１および第２の失
敗状態となったタスクの起動順序における一つ前のタス
クに後戻りし、該後戻りしたタスクを前記第２の失敗状
態とすることを特徴とするものである。

【００１３】請求項４に記載の発明においては、請求項
１に記載のワークフロー支援システムにおいて、前記ル
ールの条件部および実行部は該ルールの適用時およびタ
スクの起動時に情報の受け渡しを行なうための変数を用
いることが可能であり、起動されたタスクと選択された
ルールとの間で双方向に変数の値の受け渡しを行なうこ
とができることを特徴とするものである。

【００１４】請求項５に記載の発明においては、請求項
４に記載のワークフロー支援システムにおいて、前記ル
ール解釈実行手段は、ルールの実行部のタスク列中にあ
る任意のタスクの実行が終了する前に、該実行中のルー
ルのタスク列中のタスクを並行して起動することが可能
であり、起動されたタスクに対して適合する条件部を持
つルールを選択する際に値が未確定状態の変数の単一化
の情報を一時保持しておき、任意のタスクで未確定状態
の変数の値が確定された場合に、前記単一化の情報に基
づいて全てのタスクにおいて単一化された変数を同一値
に確定することを特徴とするものである。

【００１５】

【作用】請求項１に記載の発明によれば、あるタスクの
ワークフローのルールを、タスクの列に分割して、各々
別のルールとしてルール群格納手段へ格納している。そ
れぞれのルール群格納手段と対応して設けられたルール
解釈実行手段では、対応するルール群格納手段に格納さ
れているルールの実行部のタスクを順次起動する。タス
クが起動されると、ルール選択手段は、そのタスクに対
して適合する条件部を持つルールをタスクの起動時に選
択する。選択されるルールは、タスクが起動されたルー
ル解釈実行手段と対応するルール群格納手段内に存在す
ることもあるし、他のルール群格納手段に存在すること
もある。ルール選択手段は、選択されたルールを有する
ルール群格納手段に対応したルール解釈実行手段に対し
て、起動されたタスクを受け渡す。このとき、例えば選
択されたルールがタスクを起動したルール解釈実行手段
に対応したルール群格納手段に存在しないとき、他のル
ール解釈実行手段に前記タスクを受け渡す。ルール選択
手段によってタスクを受け渡されたルール解釈実行手段
は、選択されたルールの実行部のタスクを順次起動す
る。このようにして、最初のタスクを起動するだけで、
宣言的に記述されたルールに基づいて、順次、タスクの
起動およびタスクの受け渡しが行なわれ、複数のルール
解釈実行手段が協調して動作し、ワークフローが実行さ
れることになる。そのため、従来の電子メールのよう
に、最初からすべての宛先を記述する必要はなく、ルー
ル選択手段がタスクを実行することのできるルール解釈
実行手段へ自動的にタスクを受け渡す。また、タスク実
行時の条件分岐なども、従来のようにユーザが手続的に
明示する必要はなく、いくつかのルールを宣言的に記述
していずれかのルール群格納手段に格納しておくだけで
よい。

【００１６】また、本発明はネットワークによって接続
された分散システム上に構築されているので、複数の端
末装置を利用する複数のユーザあるいは複数のグループ
にまたがったワークフローの実行が可能となる。すなわ
ち、すべてあるいは一部のルール群格納手段および対応
するルール解釈実行手段の組を１人のユーザあるいは複
数のユーザのグループと対応付け、ある時点のタスクの
進行状態から、次のタスクを実行できるユーザあるいは
グループを実行時に見つけ出し、見つけたユーザあるい
はグループに対してタスクを依頼することができる。タ
スクを依頼されたユーザは、そのユーザの環境に定義さ
れている仕事のやり方で、タスクを実行することができ
る。

【００１７】請求項２に記載の発明によれば、起動され
たタスクのためのルールがルール群格納手段のいずれに
も保有されていない場合に、これを第１の失敗状態とし
て検出し、その旨をユーザインタフェースを通じてユー
ザへ通知する。そして、ユーザによる処理を受けること
によってタスクを完了させ、ワークフローを続行するこ
とができる。これにより、例えば、データベースを検索
したり、アプリケーションを起動したりといったコンピ
ュータのみで実行するタスクの他に、人が行なう処理を
も１つのタスクとして実行し、ワークフローを続行する
ことが可能となる。

【００１８】請求項３に記載の発明によれば、起動した
タスクが強制的に、あるいは、例えば、タイムアウトな
どのシステムの定義した条件により第２の失敗状態とな
ったことを検出する。第２の失敗状態が検出された場
合、そのタスクに対してすでに適用したルールとは別の
ルールであって適用可能なルールを再選択して実行す
る。選択されるべきルールが存在しない場合には、請求
項２に記載の発明と同様にこのタスクを第１の失敗状態
として検出し、ユーザによる処理を待つ。これによりタ
スクが完了すれば、ワークフローをそのまま続行するこ
とができる。第１の失敗状態が回復しない場合には、第
１および第２の失敗状態となったタスクの起動順序にお
ける一つ前のタスクにバックトラックし、バックトラッ
クしたタスクを第２の失敗状態とする。すなわち、バッ
クトラックしたタスクについて、別のルールを探索する
ことになる。このバックトラックによって、ルール群格
納手段に格納されているルールのうち適合可能なすべて
のルールについて、その実行を試みるように構成するこ
とができる。そのため、従来のように一意に宛先を指定
する場合に比べ、柔軟なタスクの実行が可能である。ま
た、従来の手続的な記述に比べ、複雑な実行順の制御で
も簡単に記述することが可能である。

【００１９】バックトラックの際には、一度にいくつか
のタスクまたは処理に後戻りすることも可能であり、後
戻りが発生する位置と一度に行なわれる後戻りが終了す
る位置をルールの宣言時および実行中に指定しておけば
よい。これにより、必要以上によけいな再試行をしない
ようにシステムを制御することが可能になる。

【００２０】請求項４に記載の発明によれば、前記ルー
ルの条件部および実行部には、変数を用いることが可能
であり、ルールの適用時およびタスクの起動時に情報の
受け渡しを行なうことができる。また、この情報の受け
渡しは、起動されたタスクと選択されたルールとの間で
双方向に行なうことができ、タスクの実行時に当該ワー
クフローのタスク間で、例えば、返信要求などのような
情報の交換の繰り返しを行なうことが可能となる。

【００２１】この変数の値を未定のまま、タスクを起動
することも可能である。このとき、起動されたタスクの
側で未定状態の変数の値を確定することができる。例え
ば、請求項２に記載の発明のようにユーザがタスクを完
了させる場合には、ユーザは、未完の処理や、自分が処
理し、成果として入力しなければならない内容がどれで
あるかを知ることができ、それに対する処理を行なうこ
とができる。

【００２２】請求項５に記載の発明によれば、任意のタ
スクの実行が終了する前に、該実行中のルールのタスク
列中のタスクを並行して起動することが可能である。こ
のとき、変数が未確定状態のままタスクが起動されるこ
とがある。この値が未確定状態の変数のうち、同じ変数
について単一化の情報を一時保持しておき、任意のタス
クで未確定状態の変数の値が確定された場合に、前記単
一化の情報に基づいて全てのタスクにおいて単一化され
た変数を同一値に確定する。これにより、ワークフロー
のルールに記述されている手順にしたがって実行してい
るタスクにおいて、ユーザがそのタスクを終了していな
い中途の状態であっても、必要に応じてそれ以降のタス
クを起動することができる。また、中途のタスクにおい
て、作成されるべき各成果（文書）が完成するごとに、
すでに起動されている後続のタスクへ前記成果を自動的
に渡すことがルールを変更することなくできる。このよ
うに、ワークフローにおけるタスク列の進行方向と、そ
の間の成果の受け渡しの方向とを一致させる必要がなく
なり、同じワークフローのルールの中で、タスクの実行
順序に柔軟性を持たせることができる。

【００２３】この単一化された変数の確定は、上述の請
求項３に記載の発明のようにバックトラックを行なう場
合には、後戻りの対象となる各タスクにおいて、実行経
歴上そのタスクで確定された変数のみを未定状態に戻す
ように構成すればよい。この過程を監視することによっ
て、無効となる成果と、有効であり続ける成果とが、各
々どれであるかをユーザは容易に知ることが可能とな
る。また、このようなタスクの実行とバックトラックの
過程において、タスクの実行列と変数の確定値を記憶す
るとともに、後戻りによるタスクの冗長部を取り除くこ
とによって、ユーザは、実行されたタスクあるいは処理
の列と、そのワークフローに関係した文書、成果として
有効である文書、関係した人などの情報を一覧すること
が可能になる。

【００２４】

【実施例】図１は、本発明によるワークフロー支援シス
テムの一実施例を示す構成図である。図中、１は個人環
境、２は共有環境、３は転送デーモンプロセス、１１，
１５はデータベース、１２，１６は問い合わせ部、１
３，１７はタプルスペース、１４はユーザインタフェー
スである。図１には、各構成を概念的に示している。物
理的には、ネットワークに複数の端末装置が接続されて
いる。ユーザは、各端末装置を操作する。個人環境１
は、各ユーザに対して設定される環境であり、各端末装
置に固有に設けられる必要はない。また、共有環境２
も、ユーザのグループに対して設定される環境であり、
特定の端末装置に設けられる必要はない。例えば、デー
タベースは、ユーザが使用している端末装置に付属して
いる記憶装置内に実体がある場合でも、実際にはネット
ワークを通じて他の端末装置に付属している記憶装置に
実体が存在し、それらをアクセスする場合でもよい。

【００２５】個人環境１には、その環境で作業を行なう
ユーザのための、個人用のデータベース１１が存在す
る。このデータベースは、論理的に各個人ごとに管理さ
れるものである。データベース１１には、各自の個人用
の情報や、ワークフローのルールなどが格納される。個
人用の情報とワークフローのルールは、別のデータベー
スで管理することも可能であるが、以下の説明では、同
一に管理されるものとして構成している。

【００２６】グループ共有環境２には、複数のユーザを
含むグループのための、共有のデータベース１５が存在
する。このグループは、運用上の都合で決められるもの
であり、システムがグループの決め方に制限を加えるこ
とはない。この共有のデータベース１５には、グループ
で共有できる情報やワークフローのルールなどが格納さ
れる。このデータベース１５も、論理的にグループで共
有して管理されるものである。また、共有のデータベー
ス１５は複数存在して良く、各ユーザが複数のグループ
に含まれていても構わない。

【００２７】ここで、ワークフローのルールとは、タス
クのサブタスク列への展開を、宣言的に記述したもので
ある。このワークフローのルールは、情報の受け渡しを
行なう変数記述を含む条件部と実行部からなる。条件部
が成り立つときに実行部に記述されたタスク列が先頭か
ら順次起動される。実行部の各タスクは、起動されると
実行待ちの状態となり、実行失敗あるいは実行中の状態
を経て、実行終了時に達成あるいは拒否のいずれかの状
態になる。タスクの実行は、別のルールの選択と実行、
および、例えば、データベース１１，１５の検索、アプ
リケーションプログラムの起動などの処理や、ユーザイ
ンタフェース１４を介した人間が行なう処理などが含ま
れる。

【００２８】データベース１１，１５に格納される情報
としては、各個人、各グループ用の情報や、ワークフロ
ーのルールの他に、各個人の属性に関する情報、組織に
関する情報、ワークフローによって処理される文書など
が格納される。

【００２９】グループ共有空間２のデータベース１５
と、個人環境１のデータベース１１に格納される内容
は、特定のユーザのみが利用する個人用の情報と、グル
ープ内の複数ユーザが共有したい情報とを分けて格納し
た方が望ましいというだけであり、運用上の都合によっ
て使い分ければ良く、システムはその利用法になんら制
限を加えない。同じ仕事のやり方が、個人やグループに
よって異なる場合もあり、共有のデータベース１５間や
共有のデータベース１５と個人のデータベース１１で情
報を重複して保持して構わない。すでに共有のデータベ
ース１５に存在するルールについて、個人的な理由によ
って、その一部を変更したルールなどを個人のデータベ
ース１１に保持することもできる。もちろん、一方のデ
ータベースのみで構成することも可能である。

【００３０】問い合わせ部１２，１６は、各データベー
スに対応して設けられ、ルールの起動や検索の指示を受
け、それらを解釈、実行する。例えば、グループ共有環
境２のデータベース１５から、承認者や、経理担当者を
検索したり、購入伝票のフォームを検索するなどといっ
た問い合わせを受け付け、これらの問い合わせに応える
ことができる。データベースの検索は、ワークフローの
ルールと他の情報とが同一のデータベースに格納されて
いる場合には、後述するように、次に適用可能なワーク
フローのルールの検索方法と同様に、導出原理による推
論によって求めることができる。ワークフローのルール
と他の情報とを別のデータベースとして管理している場
合には、ワークフローのルール以外の情報は、例えば、
ＳＱＬ，ＱＢＥなどの通常用いられているデータベース
の問い合わせ言語処理系を用いることによって、効率よ
く検索を行なうことができる。また、問い合わせ部１
２，１６に、決まった動作をするルールをあらかじめ組
み込んでおき、これによってアプリケーションを起動し
たり、各種の情報を検索するように構成することができ
る。

【００３１】問い合わせ部１２，１６としては、具体的
には、ＳＬＤ反駁による計算を行ない、論理型言語Ｐｒ
ｏｌｏｇ言語のインタプリタと同様な方法で実現するこ
とができる。Ｐｒｏｌｏｇの言語仕様については、例え
ば、Ｃｌｏｃｋｓｉｎ，Ｍｅｌｌｉｓｈ，Ｐｒｏｌｏｇ
プログラミング，日本コンピュータ協会等を参照された
い。この場合、ワークフローのルールは、１階述語論理
のホーン節の形式に分割して表現し、データベース１
１，１５に格納しておけばよい。

【００３２】問い合わせ部１２，１６は、ユーザインタ
フェース１４からの問い合わせ内容、すなわち、指示さ
れたワークフローのルールの条件部をゴールとし、その
ゴールを証明するための導出論理による証明計算を開始
する。問い合わせ部１２，１６においては、ワークフロ
ーのルールの適用と、それによる実行部のタスク列は全
て、最初に与えられたタスクを証明するための証明計算
過程である。ゴールとなるタスクが達成状態になると、
真であると証明されたことであり、拒否状態になると
は、偽であると証明されたことである。

【００３３】また、ゴールとなるタスクの実行中や、以
下に述べるタプルスペースに存在する間は、そのゴール
の真偽値は未定状態である。そして、ゴールの真偽値を
求めることをゴールを解くといい、ゴールの真偽値が決
められない（真とも偽とも証明できない）ときにゴール
が解けない、あるいはゴールの実行に失敗するという。
この証明の記録は、後戻り（バックトラック）などの冗
長部を除外したワークフローの記録となり、変数の値は
実際に当該ワークフローにおいて関与したユーザや文書
となる。この証明の記録を保持することによって、ワー
クフローの一覧を得たり、ワークフローを追跡し、事務
処理の効率化を行なうなど、種々の用途に用いることが
可能である。

【００３４】個人のデータベース１１の中で、あるゴー
ルが失敗した場合、すなわち、そのゴールにマッチする
条件部を持つルールかデータがデータベース１１内に存
在しない場合には、問い合わせ部１２は、後述するよう
に、タプルスペースを通じて、この失敗したゴールの証
明を他の問い合わせ部１２，１６に依頼する。Ｐｒｏｌ
ｏｇ等の論理型言語においては、失敗したゴールは偽で
あることが証明されたと解釈するが、ここでは、その証
明を他の環境あるいはユーザに依頼するものとする。

【００３５】タプルスペース１３，１７は、複数の問い
合わせ部１２，１６から読み書きができる共有空間であ
る。グループ共有空間２のタプルスペース１７には、問
い合わせ部１２において、個人用のデータベース１１の
中であるゴールが失敗した場合、その失敗したゴールが
タプルとして書き込まれる。また、個人空間１のタプル
スペース１３には、例えばグループ共有空間２のタプル
スペース１７に出現したタプルが、転送デーモンによっ
て転送されることにより書き込まれる。タプルスペース
１３，１７に書き込まれたタプルは、問い合わせ部１２
で読み出される。

【００３６】転送デーモンプロセス３は、タプルスペー
ス１３，１７に保持されているタプルを他のタプルスペ
ース１３，１７に転送する。

【００３７】ユーザインタフェース１４は、ユーザから
の仕事の依頼、および、タスクのうち人間が行なう処理
の通知とその処理結果の入力等が行なわれる。ユーザが
仕事を依頼、すなわち、ワークフローを起動するために
は、ユーザインタフェース１４から、例えば個人または
共有のデータベース１１，１５の中にあるワークフロー
のためのルールの条件部と同形のタスクを選択し、それ
をゴールとして個人環境１の問い合わせ部１２に与えれ
ばよい。

【００３８】図２は、本発明のワークフロー支援システ
ムにおける個人環境１の問い合わせ部１２の動作の一例
を示すフローチャートである。問い合わせ部１２は、マ
ルチスレッド処理を行なうように構成することができ
る。すなわち、タスクの実行中であっても、タプルスペ
ース１３に出現したゴールは並列に実行される。

【００３９】Ｓ２１において、スレッドを二つ生成す
る。一方のスレッドは、ユーザから依頼されたワークフ
ローを処理する。また、他方のスレッドは、タプルスペ
ース１３に出現したゴールを処理する。ユーザから依頼
されたワークフローを処理するスレッドでは、Ｓ２２に
おいて、ユーザからの問い合わせの入力を受け取る。そ
して、Ｓ２３においてスレッドを１つ生成し、一方のス
レッドではＳ２４において、受け取った入力をゴールと
してＳＬＤ反駁による計算を行なう。

【００４０】計算によりゴールの実行に失敗した場合に
は、Ｓ２５でこれを検出し、Ｓ２６で失敗したゴールを
グループ共有環境２のタプルスペース１７へ出力する。
そして、Ｓ２７において、失敗したゴールの結果が得ら
れるまで、スレッドの動作を停止する。結果が返される
と、その結果を読み取り、さらにＳＬＤ反駁による計算
を続行する。また、Ｓ２３の他方のスレッドでは、別の
問い合わせ入力に対応するため、Ｓ２２へ戻る。

【００４１】一方、タプルスペース１３に出現したゴー
ルを処理するスレッドは、Ｓ２８においてタプルスペー
ス１３にタプルが書き込まれるのを待つ。タプルがタプ
ルスペース１３に書き込まれると、そのタプルを読み取
り、Ｓ２９においてタプルを処理するためのスレッドを
１つ生成する。一方のスレッドでは、Ｓ３０においてＳ
２４と同様に、読み取ったタプルをゴールとするＳＬＤ
反駁による計算を行なう。このときゴールの実行に失敗
した場合の処理についても、Ｓ２５ないしＳ２７と同様
の処理をＳ３１ないしＳ３３において行なう。計算が終
了すると、タスクの依頼元へ結果を返し、処理を終了す
る。また、他方のスレッドでは、別のタプルがタプルス
ペース１３に書き込まれた場合に対処するため、Ｓ２８
へ戻り、停止状態となる。

【００４２】このようにして、各個人環境１の問い合わ
せ部１２では、ユーザから依頼された複数のワークフロ
ーの処理と、タプルスペース１３に出現したゴールを並
行して処理することができる。

【００４３】グループ共有環境２の問い合わせ部１６の
動作のうち、他のグループ共有環境２の問い合わせ部１
６や個人環境１の問い合わせ部１２からタプルスペース
１７に書き込まれたタプルに対する処理、および、ある
場合にはグループ共有環境２のユーザインタフェース１
４から受けた問い合わせに対する処理は、図２に示した
個人環境１の問い合わせ部１２の処理と同様である。た
だし、グループ共有環境２の問い合わせ部１６から出力
されるタプルは、タプルスペース１７に書き込まれる。
しかし、タプルスペース１７に書き込まれたタプルは、
そのタプルを出力した問い合わせ部１６では処理されな
い。かわりに、以下の２つの方法のどちらかによって処
理される。

【００４４】まず１つめの方法は、そのゴールを解くこ
とができるユーザが、ユーザインタフェース１４を通じ
て自分でそのゴールを取り出し、自分のゴールとして処
理を行ない、結果をユーザインタフェース１４から入力
するという方法である。グループ共有環境２のタプルス
ペース１７に存在するタプルは、基本的にはこのグルー
プのユーザがユーザインタフェース１４を通して、参照
することができる。このとき、余計なものがたくさん見
えると不便であるので、ユーザインタフェース１４にフ
ィルタの機能を持たせることができる。各ユーザがフィ
ルタの条件を設定しておくことにより、各ユーザに関係
するものだけが見えるようにこうせいすることができ
る。あるいは、個人環境１の問い合わせ部１２がグルー
プ共有環境２のタプルスペース１７を常に参照し、解決
可能なゴールを取り出して実行するように構成すること
もできる。

【００４５】もう１つの方法は、転送デーモンプロセス
３を用いて、タプルを他のタプルスペース１３，１７に
移動させる方法である。この方法は、データベース１５
内のデータから、そのゴールを解くとができるユーザ
か、解くことができるユーザが存在する他のグループを
一意に特定できた場合や、そのデータベースを参照でき
るユーザが誰も解くことができない場合、あるいは解く
ことができるユーザが複数存在するにもかかわらず、一
定時間経っても誰もそれを実行しようとしない場合など
に行なわれる。

【００４６】この場合は、転送デーモンプロセス３は、
タプルを実行すべきユーザを調べ、そのユーザのタプル
スペース１３，１７にタプルを移動させる。あるいは、
データベース１５内の情報から、実行が可能であるユー
ザが複数存在することが判明し、なおかつ一定時間経っ
ても誰もそれを実行しようとしない場合は、実行可能な
ユーザの誰かのタプルスペースにそのゴールを移動さ
せ、実行を促す。

【００４７】以下、具体例を用いて上述の動作の一例を
説明する。ここでは、ある人が物品の購入処理を行なう
場合の例を取り上げる。物品を購入する際には、購入伝
票を作成し、承認者の承認印を受けた後、経理部門が発
注するものとする。すなわち、「ある人１が物品購入を
行なう場合には、購入伝票を作成し、承認処理を承認者
に依頼し、経理担当に発注処理してもらう。」ことをワ
ークフローのルールとして定義しておけばよい。これを
ワークフローのルールとしてグループ共有環境２のデー
タベース１５に格納しておけばよい。

【００４８】ここでは、次の４つのワークフローのルー
ルが宣言的に記述され、グループ共有環境２のデータベ
ース１５に格納されているものとする。これらのワーク
フローのルールは、例えば、ユーザインタフェース１４
を用いて定義することができる。 タスク（？人１，物品購入処理）← タスク（？人１，購入伝票作成，？購入伝票）， タスク（？人１，承認処理依頼，？購入伝票，？承認印）， タスク（？人１，発注処理依頼，？購入伝票，？承認印）． タスク（？人１，承認処理依頼，？購入伝票，？承認印）← 承認者（？人１，？人２）， タスク（？人２，承認処理，？購入伝票，？承認印）， タスク（？人１，発注処理依頼，？購入伝票，？承認印）． タスク（？人１，発注処理依頼，？購入伝票，？承認印）← 経理担当（？人２）， タスク（？人２，発注処理，？購入伝票，？承認印）． タスク（？人１，購入伝票作成，？購入伝票）← フォーム取り出し（購入伝票作成，？フォーム）， タスク（？人１，記載，？フォーム，？購入伝票）．

【００４９】上述の各ルールにおいて、‘←’の左辺が
条件部、右辺が実行部である。各ルール中の‘？’が先
頭についている文字列は変数である。なお、ルールの表
記上、変数のスコープは、その変数が出現する１つのル
ール内のみである。そのため、上述の４つに分割された
ルールは、各々独立に格納し、管理することができる。

【００５０】例えば、上述の購入伝票処理をＨ氏が起動
すると、Ｈ氏の個人用のデータベース１１に対して、
「タスク（Ｈ，物品購入処理）」をゴールとする問い合
わせが発生する。

【００５１】Ｈ氏の個人環境１の問い合わせ部１２は、
変数の確定に関して、双方向性を持つパターンマッチン
グによって、ゴールにマッチする条件部を持つルールを
検索し、そのルールを適用し、実行部を新たなゴールと
して展開しようとする。これによって、実行時に適用さ
れるルールが定まり、ワークフローが実現される。

【００５２】ここで、Ｈ氏のデータベースに物品購入処
理のルールが存在しないものとすると、ゴール「タスク
（Ｈ，物品購入処理）」は失敗する。この場合、このゴ
ールはグループ共有環境２のタプルスペース１７にタプ
ルとして出力される。

【００５３】グループ共有環境２の問い合わせ部１６
は、タプルスペース１７に書き込まれたタプルを取り出
し、データベース１５内のルールを検索する。グループ
共有環境２のデータベース１５には、上述した物品購入
処理の４つのルールが格納されている。そのため、その
ルールのうちからマッチするルールを取り出す。この場
合には、 タスク（？人１，物品購入処理）← タスク（？人１，購入伝票作成，？購入伝票）， タスク（？人１，承認処理依頼，？購入伝票，？承認印）， タスク（？人１，発注処理依頼，？購入伝票，？承認印）． のルールがマッチする。すなわち、変数「？人１」の値
は「Ｈ」となり、条件部「タスク（？人１，物品購入処
理）」と「タスク（Ｈ，物品購入処理）」がマッチす
る。ルールの検索は、登録されている順序に従って行な
われる。

【００５４】取り出されたルールが適用され、実行部の
各タスクが順に実行される。まず、「タスク（Ｈ，購入
伝票作成，？購入伝票）」を実行する。ここでさらに、
このゴールにマッチするルールを検索し、適用する。こ
こでは、 タスク（？人１，購入伝票作成，？購入伝票）← フォーム取り出し（購入伝票作成，？フォーム）， タスク（？人１，記載，？フォーム，？購入伝票）． のルールとマッチし、このルールが適用される。このと
き、変数「？人１」の値は「Ｈ」となる。このルールの
実行部の各タスクが順次実行される。

【００５５】まず、「フォーム取り出し（購入伝票作
成，？フォーム）」が実行される。このタスクは、文書
データベースから購入伝票フォームの抽出を行なう処理
を示している。システムは、文書データベースから購入
伝票フォームを取り出し、この購入伝票フォームを変数
「？フォーム」の値として、「フォーム取り出し（購入
伝票作成，購入伝票フォーム）」が返される。

【００５６】次に、「タスク（？人１，記載，？フォー
ム，？購入伝票）」を実行しようとする。この時、変数
「？人１」の値は「Ｈ」、「？フォーム」の値は「購入
伝票フォーム」であるので、「タスク（Ｈ，記載，購入
伝票フォーム，？購入伝票）」を実行しようとする。し
かし、このタスクについてのデータはグループ共有環境
２のデータベース１５には存在しない。上述のように、
失敗したゴールはタプルとしてグループ共有環境２のタ
プルスペース１７に出力される。そのため、「タスク
（Ｈ，記載，購入伝票フォーム，？購入伝票）」がタプ
ルスペース１７に出力される。この例の場合、タスクの
実行者となるユーザは第１引数の「Ｈ」氏であることが
システムにより認識され、このタプルはＨ氏の個人用の
タプルスペース１３に移される。この移動は、グループ
共有環境２の問い合わせ部１６、あるいは、転送デーモ
ンプロセス３によって行なわれる。

【００５７】タプルがＨ氏のタプルスペース１３に転送
されると、問い合わせ部１２がこれを検知して、タプル
を読み取り、実行しようとする。Ｈ氏の個人用のデータ
ベース１１には、次のようなルールが存在するものとす
る。 タスク（？人１，記載，？文書フォーム，？文書実体）← コピー（？文書フォーム，？文書実体）， ワープロ起動（？文書実体）． 上述の「タスク（Ｈ，記載，購入伝票フォーム，？購入
伝票）」は、このルールとマッチする。このとき、変数
「？人１」の値は「Ｈ」、「？文書フォーム」の値は
「購入伝票フォーム」である。また、変数「？文書実
体」は「？購入伝票」と対応づけられる。「タスク
（Ｈ，記載，購入伝票フォーム，？文書実体）」のルー
ルが適用され、その実行部が順に実行される。まず、
「コピー（購入伝票フォーム，？文書実体）」が実行さ
れ、続いて「ワープロ起動（？文書実体）」が実行され
る。これらの実行は問い合わせ部１２によって、システ
ムのコマンドやアプリケーションの起動に置き換えられ
て実行される。

【００５８】一方、このようなルールをＨ氏が用意して
おらず、適合するルールが存在しない場合には、このゴ
ールはＨ氏の個人環境１の問い合わせ部１２において必
ず失敗する。しかし、このゴールは、転送デーモンプロ
セス３によってＨ氏の個人環境１に要求されたタスクで
あるので、再びグループ共有環境２のタプルスペース１
７に戻されることはなく、代わりにユーザインタフェー
ス１４を通じてこの失敗したゴールをユーザであるＨ氏
に通知する。このとき、ユーザインタフェース１４は、
変数になっている部分、すなわち、「？購入伝票」の部
分を作成されるべき文書としてユーザに通知する。この
例の場合は、Ｈ氏はユーザインタフェース１４を通じ
て、まず、購入伝票の文書実体を作成し、記載しなけれ
ばならないことを知ることができる。そして、購入伝票
の文書実体を作成する作業をＨ氏自身が行ない、その成
果物である購入伝票がどの文書であるかをユーザインタ
フェース１４を通じて入力し、ルールが存在した場合と
同様の処理に戻ることができる。購入伝票の文書実体
は、例えば、ワープロで購入伝票フォームに所定事項を
記載すればよい。

【００５９】Ｈ氏が起動したワープロで「購入伝票文
書」の記載を終了し、その文書をユーザインタフェース
１４から入力すると、問い合わせ部１２は、「タスク
（Ｈ，記載，購入伝票フォーム，？文書実体）」は証明
されたと解釈し、真であると結論する。そして、このタ
スクの証明の終了とともに、もともとのゴール「タスク
（Ｈ，物品購入処理）」を直接展開した最初のゴール
「タスク（Ｈ，購入伝票作成，？購入伝票）」が証明さ
れたことにもなり、これも真となる。さらに変数の確定
値として、Ｈ氏が記載した「購入伝票文書」が変数「？
購入伝票」の値となる。

【００６０】また、変数は再び変数を部分的に含む値で
あっても、それを値として確定できる。例えば、変数
「？購入伝票」の値を確定する際に、ユーザインタフェ
ース１４を通じて「購入伝票文書」ではなく「購入伝票
文書，返信要求（？返信文書）」などを値とすることに
より、「購入伝票文書」を以降のタスクに送るだけでは
なく、「返信要求（？返信文書）」により受け取ったこ
との返信を要求することもできる。このとき、ルールを
変更する必要はない。そして、確定した変数の値は、そ
の変数を持つタスク全てに伝わるので、その返信を「？
返信文書」に受け取ることができる。

【００６１】続いて、もともとのゴール「タスク（Ｈ，
物品購入処理）」を直接展開した次の「タスク（Ｈ，承
認処理依頼，購入伝票文書，？承認印）」、および、
「タスク（Ｈ，発注処理依頼，購入伝票文書，？承認
印）の処理を行なう。この場合にも、グループ共有環境
２のデータベース１５を検索して適合するルールを実行
する。適合するルールがない場合には、上述のように、
グループ共有環境２のタプルスペース１７にタプルが出
力され、Ｈ氏の個人用のデータベース１１や他の共有あ
るいは個人用のデータベースを検索する。検索できなか
った場合は、Ｈ氏あるいはタスクを解決可能なユーザに
対してタスクの解決を依頼することになる。また、ルー
ル中の例えば「承認者（Ｈ，？人２）」などのデータベ
ース検索についても、やはり個人データベースで検索で
きなかった場合は、同様にグループ共有環境２のタプル
スペース１７に出力され、共有のデータベース１５上で
同様の検索が行なわれる。このような動作が繰り返し行
なわれることにより、ワークフローが実行される。

【００６２】ここで、例えば、この物品購入処理を行な
う際に、急いでいるにもかかわらず、承認者が出張中で
不在であった場合を考える。このような場合には、タス
クの記述されている順序に従って実行されるので、承認
処理でストップしてしまい、発注処理が遅れてしまうこ
とがある。本発明のワークフロー支援システムでは、実
行順序に関して柔軟性を持たせている。以下、この実行
順序の柔軟性の実現手段について説明する。ここでは、
取りあえず承認印のないまま経理部門まで購入伝票を先
に送り、発注処理に必要な情報収集や伝票の作成などを
あらかじめ処理しておいて欲しいとする。

【００６３】この場合は、ユーザインタフェース１４を
通じて、強制的に次のタスクへ進めることができる。こ
れは、問い合わせ部１２に対して、仮に「タスク（？人
１，承認処理依頼，？購入伝票，？承認印）」か証明さ
れたという入力を与えればよい。問い合わせ部１２は、
このゴールが証明されたので、以降の計算を実行し、購
入伝票を経理部門に回す。すなわち、タスク列の次のタ
スクを実行する。

【００６４】後に承認者が出張から戻り、ユーザインタ
フェース１４を通じてこのタスクの承認処理を拒否した
い場合には、承認処理の状態を拒否状態とすれば良い。
タスクが拒否状態となると、このタスクのゴールが偽で
あると証明されたと解釈し、以降の証明を無効として、
ここより後に確定された変数を未定状態に戻し、後戻り
する。

【００６５】一方、後から承認者が購入伝票を承認した
ときには、変数「？承認印」の値が「承認印」に確定さ
れる。本発明においては、ルールの変数は全て論理変数
として扱われ、変数どうしの単一化も管理している。そ
のため、変数「？承認印」の値が「承認印」に確定され
ることによって、すでに実行中の発注処理のタスクの中
で変数「？承認印」と単一化されている全ての変数の値
も「承認印」に確定される。したがって、このようにタ
スクの起動と、成果物のシステムへの入力順序が入れ替
わっても、ルールを変更する必要がなく、同じルールを
用いることができる。また、このようにルールの実行順
序を入れ替えて実行させることが可能である。

【００６６】上述の具体例において、先の場合と同様
に、この物品購入処理を行なう際に、急いでいるにもか
かわらず、承認者が出張中で不在であった場合、今度
は、別の承認者に代わって承認処理を行なってもらう場
合も考えられる。このような場合には、承認処理のタス
クを偽として例外処理を実行させることにより実現する
ことができる。ここでいう例外処理は、単に別の選択肢
を選び直す処理にしか過ぎない。この意味で、通常のシ
ステムにおいて、システムに記述してある条件分岐によ
る選択肢の中から、通常は選ばれない選択肢が選ばれた
場合の処理のことを例外処理と呼ぶのとは相違する。

【００６７】通常の承認者が不在で承認が受けられずに
処理が滞っている場合、承認処理のルールの実行部に記
述されているタスクのうち、「タスク（？人２，承認処
理，？購入伝票，？承認印）」が実行中となっている。
この状態において、ユーザインタフェース１４を通じ
て、この「タスク（？人２，承認処理，？購入伝票，？
承認印）」が偽であると証明されたという入力を与え
る。あるいは一定時間たってもこのタスクが受理され
ず、真であるとも偽であるとも証明されない場合はシス
テムが自動的に偽であると証明する。

【００６８】問い合わせ部１２は、論理型言語と同様の
手法によりバックトラックし、タスク列の１つ前の「承
認者（？人１，？人２）」の別の可能性を検索する。す
なわち、後戻りして別の承認者の検索をやり直し、新た
な承認者に依頼する。

【００６９】このような後戻りが発生するとき、本発明
のワークフロー支援システムでは、後戻りする位置を指
定することができる。例えば、上述した承認処理の依頼
のルールを次のようにも記述することができる。 タスク（？人１，承認処理依頼，？購入伝票，？承認印）← 承認者（？人１，？人２）， ｜， タスク（？人２，承認処理，？購入伝票，？承認印）． ここで、‘｜’はコミットオペレータと呼ぶものである
が、その働きはＰｒｏｌｏｇ言語におけるカットオペレ
ータに等価である。このオペレータの右側まで実行が進
んだ後、何処かでゴールが拒否状態となり、後戻りによ
って再びこのオペレーターの位置へ戻ってきた場合に
は、このルールが適用される原因となったタスクの拒否
状態が確定し、このタスクをゴールとして呼び出した１
つ前のゴールの再試行に後戻りする。すなわち、上述の
例では、最初の承認者が承認しないといえば、他の承認
者を探すことなく、その決定が確定される。そして、
「タスク（？人１，承認処理依頼，？購入伝票，？承認
印）」の別の可能性が試行されることになる。他に適合
するルールが存在しない場合には、「タスク（？人１，
購入伝票作成，？購入伝票）」の別の可能性が試行され
る。この際に、変数「？購入伝票」の値の確定は最初の
このゴールの実行前に戻されるので、未定状態になる。
すなわちＨ氏は購入伝票の書き直しを要求されることに
なる。

【００７０】ただし、論理型言語などの場合とは異な
り、本発明による問い合わせ部１２，１６においては、
通常、このコミットオペレータはルールには記述しなく
てもよい。ルールはその同じルールによって起動される
全ての実行例のひな型となるものである。そのため、ル
ール中にコミットオペレータを記述することは、全ての
実行例に対して、規定してしまうので、コミットオペレ
ータをルールに記述しなくてもよいように構成してい
る。

【００７１】コミットオペレータは、ルールに記述され
ていなくても、ユーザが実行時あるいは実行中にユーザ
インタフェース１４を通じて、起動した具体的なワーク
フローごとに必要に応じて動的に挿入することができ
る。上述の例では、ルールにコミットオペレータがない
ほうが望ましく、最初の承認者がいないために一定時間
経っても処理されない場合には、１つ後戻りして他の承
認者に転送できるようにルールを定義しておくことが望
ましい。承認者がそのタスクを処理し、関与したときに
はコミットオペレーターが挿入され、そして承認を与え
ない場合は、承認処理そのものが拒否状態となるように
すればよい。

【００７２】このように、本発明のワークフロー支援シ
ステムによれば、仕事の進み具合のある同じ状態から、
以降のワークフローが数通り考えられる場合に、それら
全てのルールをデータベース１１，１５に格納しておく
ことができる。そして、選択したワークフローによるタ
スクが拒否状態になった場合にはバックトラック機構に
よる後戻りによって、別の選択肢を選び直すことができ
る。したがって、あらかじめ想定できる例外についての
ルールは、通常のルールと全く同等な形式で定義するこ
とができる。すなわち、この意味での例外は、本発明に
よるシステムにおいて、単に別の選択肢を選び直す処理
にしかすぎない。

【００７３】もちろん、システムに記述していない事態
が発生した場合の例外も発生する。ここで、システムに
記述していないということは、処理が記述されていない
だけでなく、ある条件の場合の選択肢そのものの記述が
ないことをいう。従来のシステムでは、このような状態
はあってはならない状態であり、システムはエラーを起
こして停止する。従来のシステムでは、このような意味
での例外は、システム全体を閉じた系として実現してい
るために、記述されていない状態の発生は異常事態とな
る。本発明によるシステムにとっては、開放系が前提と
なっているので、これらは単に別の環境へ処理を依頼す
れば済む処理であるに過ぎない。

【００７４】例えば、通常行なわれているワークフロー
のあるゴールが拒否状態となり、それに代わる選択肢も
存在しない場合、すなわちシステム全体に格納されてい
るデータやルール以外の処理が必要となる場合、例外が
発生する。このような例外が発生した場合には、その例
外が発生したタスクはユーザである人間が対処しなけれ
ばならないタスクである。本発明のワークフロー支援シ
ステムでは、すでに上述したように、このような例外発
生の場合には、人間の対処を取り込み、以降のワークフ
ローを継続することができる。

【００７５】上述したように、本発明における問い合わ
せ部１２，１６は、ここでいう例外処理であるか否かに
かかわらず、通常の処理においても、対応するデータベ
ース１１，１５の検索で失敗したゴールは、グループ共
有環境２のタプルスペース１７に出力し、そのゴールの
証明を他の環境に依頼している。人間が対処しなければ
ならなかった例外処理は、どのデータベース１１，１５
でも失敗し、タプルスペース１７に残ってしまったゴー
ルである。そして、人間が行なった対処は、そのゴール
を真であると証明するための証明過程であったことにな
る。

【００７６】通常の処理においても、ゴールをタプルス
ペース１７へ出力した側の問い合わせ部１２は、そのゴ
ールの真偽の結果が判明するのを待っているだけで、ど
の環境でどのように証明されたかについては、知る必要
がない。すなわち、人間にとっての例外に対する処理
は、システムにとっては全く例外ではなく、そのゴール
を解いた他の環境のデータベースとその問い合わせ部が
たまたまユーザである人間であったというだけのことに
過ぎない。

【００７７】このように、ルールが記述されていないこ
とによって発生する例外に対しても、他のデータベース
や、ユーザである人間の処理をも含めることによって、
柔軟に対応することができる。また、これによって、人
間の行なう処理をも含めたワークフローの管理および支
援を可能としている。

【００７８】

【発明の効果】以上の説明から明らかなように、本発明
によれば、ユーザは最初のタスクを起動するだけで、宣
言的に記述されたルールに基づいて、順次、タスクの起
動およびタスクの分割が行なわれ、ワークフローを実
行、管理することができる。実行時に、分割されたワー
クフローのルールの中から次に適用可能なルールを検索
し、適用することにより、従来の電子メールのように、
最初からすべての宛先を記述したり、条件判断による分
岐命令等を含む明示的な手続きを記述する必要はない。

【００７９】また、ワークフローのルールに記述されて
いる手順にしたがって実行してるタスクにおいて、ユー
ザがそのタスクを終了していない中途の状態であって
も、必要に応じてそれ以降のタスクを起動することがで
きる。そして、中途のタスクにおいて、作成されるべき
各成果が完成するごとに、すでに起動されている後続の
タスクへその成果を自動的に渡すことがルールを変更す
ることなくできる。これによって同じワークフローのル
ールの中で、タスクの実行順序に柔軟性を持たせること
ができる。

【００８０】さらに、システムが解決できない例外がい
ずれのタスクで発生した場合においても、その例外に対
する人間の対処による結果をシステムに取り込むことが
でき、その結果に基づいて、以降のワークフローを継続
して実行できる。これにより、人間の対処をも含めたワ
ークフロー全体の柔軟な管理および支援を行なうことが
可能となるという効果がある。

【図面の簡単な説明】

【図１】 本発明によるワークフロー支援システムの一
実施例を示す構成図である。

【図２】 本発明のワークフロー支援システムにおける
個人環境１の問い合わせ部１２の動作の一例を示すフロ
ーチャートである。

【符号の説明】

１…個人環境、２…共有環境、３…転送デーモンプロセ
ス、１１，１５…データベース、１２，１６…問い合わ
せ部、１３，１７…タプルスペース、１４…ユーザイン
タフェース。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 申 吉浩 神奈川県横浜市保土ヶ谷区神戸町134番 地 横浜ビジネスパークイーストタワー 富士ゼロックス株式会社内 (56)参考文献 Ｂｕｓｓｌｅｒ，Ｃ．ｅｔ ａｌ，Ｉ ｍｐｌｅｍｅｎｔｉｎｇ Ａｇｅｎｔ Ｃｏｏｒｄｉｎａｔｉｏｎ ｆｏｒ Ｗ ｏｒｋｆｌｏｗ Ｍａｎａｇｅｍｅｎ ｔ，Ｐｒｏｃ．ｏｆ ｔｈｅ ４ｔｈ Ｉｎｔ．Ｗｏｒｋｓｈｏｐ ｏｎ Ｒｅ ｓｅａｒｃｈ Ｉｓｓｕｅｓ ｉｎ Ｄ ａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ，米 国，1994年 ２月14日，Ｐ．53−59 「情報処理学会研究報告」（93−ＧＷ −４−７）Ｖｏｌ．93，Ｎｏ．95（1993 −10) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/44 G06F 15/16

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】 ネットワークによって接続された分散シ
   ステムを用いてワークフローを支援するワークフロー支
   援システムにおいて、発生したタスクに対するルールの
   適用の可否を判定するための条件部とタスク列である実
   行部からなりあるタスクから次に実行すべきタスク列へ
   の展開を宣言的に記述したワークフローのためのルール
   を格納する複数のルール群格納手段と、該ルール群格納
   手段のそれぞれと対応して設けられ対応する前記ルール
   群格納手段に格納されたルールに含まれる前記タスクを
   起動するルール解釈実行手段と、起動された前記タスク
   に対して適合する条件部を持つルールをタスクの起動時
   に選択し選択されたルールを保持する前記ルール群格納
   手段と対応して設けられた前記ルール解釈実行手段に前
   記タスクを受け渡すルール選択手段を有し、前記ルール
   選択手段は、選択されたルールがタスクを起動した前記
   ルール解釈実行手段に対応したルール群格納手段に存在
   しないとき他のルール解釈実行手段に前記タスクを受け
   渡し、前記ルール解釈実行手段は、前記ルール選択手段
   により受け渡されたタスクに適合する条件部を持つルー
   ルの実行部のタスクを順次起動することを特徴とするワ
   ークフロー支援システム。
2. 【請求項２】 ネットワークによって接続された分散シ
   ステムを用いてワークフローを支援するワークフロー支
   援システムにおいて、発生したタスクに対するルールの
   適用の可否を判定するための条件部とタスク列である実
   行部からなりあるタスクから次に実行すべきタスク列へ
   の展開を宣言的に記述したワークフローのためのルール
   を格納する複数のルール群格納手段と、該ルール群格納
   手段のそれぞれと対応して設けられ対応する前記ルール
   群格納手段に格納されたルールに含まれる前記タスクを
   起動するルール解釈実行手段と、起動された前記タスク
   に対して適合する条件部を持つルールをタスクの起動時
   に選択し選択されたルールを保持する前記ルール群格納
   手段と対応して設けられた前記ルール解釈実行手段に前
   記タスクを受け渡すルール選択手段と、ユーザが入力を
   行なうユーザインタフェースを有し、前記ルール解釈実
   行手段は、前記ルール選択手段により受け渡されたタス
   クに適合する条件部を持つルールの実行部のタスクを順
   次起動するとともに、起動すべきタスクに対して適合す
   る条件部を持つルールを選択する際に前記ルール群格納
   手段のいずれにも選択すべきルールが保有されていない
   場合には該タスクが起動できなかったことを第１の失敗
   状態として検出し、前記ユーザインタフェースは、前記
   ルール解釈実行手段において第１の失敗状態が検出され
   たとき前記起動できなかったタスクの情報をユーザへ通
   知するとともに該通知に応じてユーザが行なう前記起動
   できなかったタスクの実行または実行の成果の入力を行
   なうことを特徴とするワークフロー支援システム。
3. 【請求項３】 前記ルール解釈実行手段は、起動したタ
   スクが強制的にあるいはシステムの定義した条件により
   第２の失敗状態となったことを検出し、第２の失敗状態
   となったタスクに対してすでに適用したルールとは別の
   ルールであって適用可能なルールを再選択し、選択され
   るべきルールが存在しない場合にはこれを第１の失敗状
   態として検出し、該第１の失敗状態が回復しない場合に
   は第１および第２の失敗状態となったタスクの起動順序
   における一つ前のタスクに後戻りし、該後戻りしたタス
   クを前記第２の失敗状態とすることを特徴とする請求項
   ２に記載のワークフロー支援システム。
4. 【請求項４】 前記ルールの条件部および実行部は該ル
   ールの適用時およびタスクの起動時に情報の受け渡しを
   行なうための変数を用いることが可能であり、起動され
   たタスクと選択されたルールとの間で双方向に変数の値
   の受け渡しを行なうことができることを特徴とする請求
   項１に記載のワークフロー支援システム。
5. 【請求項５】 前記ルール解釈実行手段は、ルールの実
   行部のタスク列中にある任意のタスクの実行が終了する
   前に、該実行中のルールのタスク列中のタスクを並行し
   て起動することが可能であり、起動されたタスクに対し
   て適合する条件部を持つルールを選択する際に値が未確
   定状態の変数の単一化の情報を一時保持しておき、任意
   のタスクで未確定状態の変数の値が確定された場合に、
   前記単一化の情報に基づいて全てのタスクにおいて単一
   化された変数を同一値に確定することを特徴とする請求
   項４に記載のワークフロー支援システム。