JPH09265408A - ネットワーク上における分散型非同期ワークフロー - Google Patents

Abstract

(57)【要約】 【課題】 ネットワーク上で接続されているサーバおよ
びクライアントを通じて、ワークフローの実行するため
に必要なタスクを分散させることにより、ワークフロー
を自動化するシステムおよび方法を提供する。 【解決手段】 全てのプログラム（ワークフローの実行
を司どるルールを含む）を具体化するワークフロー・ク
ーリエと、ワークフローの段階を完了するためにクライ
アントが必要とする様式とを用いる。実行可能なプログ
ラムは、プラットフォームに依存しないジャバ言語で書
かれているので、ジャバ・ブラウザをインストール済み
のあらゆるコンピュータ上で実行可能である。各段階を
実行した後、当該段階を実行したクライアントは、ワー
クフロー・クーリエを更新し、ワークフロー内の次のス
テップを実行することを許可された、対応するユーザを
有するクライアントに、更新したワークフロー・クーリ
エを送信する。更新した状態情報は、ワークフローの受
信側に、どの段階がまだ残っており完了すべきかを示
す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的にコンピュ
ータ・ネットワークに関し、特に、逐次プロセス即ちワ
ークフロー(workflow)をネットワークの分散ノード上で
実行する際に、ネットワーク・ノードが、実行される逐
次プロセスについて予備知識を必要とせず、固定状接続
(stateful connection)を共用する必要もなくこれを行
う方法およびシステムに関するものである。

【０００２】

【従来の技術】業務の設定において、多くのプロジェク
トまたはタスクは複数の段階で実行されるが、この際タ
スクの各段階は異なる人によって実行され、また、この
ような段階は１組の業務規定によって指定される順序で
行われる。このようなワークフローの１つに、企業の出
張申請／払い戻しプロセス(corporate travel request/
reimbursement process)があり、出張に出かける前に、
従業員は出張申請を彼の上司に提出し、承認を得なけれ
ばならない。一旦承認が得られれば、企業の出張関連部
署に適切な出張の調整を依頼することができ、その後当
該従業員は自由に出張に出かけることができる。出張か
ら戻った後、旅費の払い戻しを受けるために、従業員は
旅費報告書を完成し提出して、彼の上司の承認を得なけ
ればならない。上司がこの旅費報告書を承認すれば、こ
れは通常経理部の適当な人に引き継がれ、当該従業員に
承認された額の支払いを許可する。上司が旅費報告書を
拒絶した場合（恐らく、従業員が必要なサインを忘れた
か、あるいは許可されない出費に対して払い戻しを要求
したような場合）、報告書は修正のために従業員に差し
戻され、再度上司に提出される。このように、このワー
クフロー、およびその他の多くのワークフローでは、通
常、ワークフローの段階の順序付けにいくらかの柔軟性
がある。

【０００３】尚、各段階を実行することを規則によって
許可された実行者(actor)にもいくらかの柔軟性がある
可能性があることにも注意されたい。例えば、旅費の場
合、企業の規則によって、従業員の上司には、１０００
ドル未満の払い戻しの出費を承認することが認められて
いる場合があるが、同一の規則が、更に大きな額につい
ては、上司およびこの上司の上司の承認を要求する場合
がある。これらのワークフローの特徴は、ワークフロー
を自動化するシステムにおいて、ワークフロー実行者間
で動的なルーティング(routing)が必要であることを示
唆している。

【０００４】従来より、ワークフレームは、図１に示す
ものに類似したアーキテクチャを用いて自動化が行われ
ている。このタイプの自動ワークフロー・システムで
は、個人（例えば、出張する従業員）は、サーバに対し
てある固定状の接続を有するクライアント・ワークステ
ーションを使用し、ワークフロー要求を開始する。これ
に応答して、サーバはワークフロー・アプリケーション
を起動し、サーバにクライアントへ様式（例えば、出張
申請書類）を戻させ、要求者がこれに書き込む。一旦要
求者が様式の書き込みを完了したなら、彼はそれをサー
バに送り返し、同一のワークフレーム・アプリケーショ
ンの制御の下で、要求者が入力した情報をデータベース
に記憶する。ワークフロー・アプリケーションは、次に
データベース内の情報を用いて、同一様式または関連様
式（例えば、出張承認様式）を、ワークフローの次の段
階を実行することを許可されている実行者（例えば、出
張を予定している従業員の上司）に送る。ワークフロー
・アプリケーションは組織的なデータベースを参照し
て、要求者の上司を識別する。一旦許可された実行者が
次の段階（例えば、出張を認める）を完了したなら、こ
の様式はサーバに戻され、ワークフロー・アプリケーシ
ョンはデータベースを更新し、追加送信（アクション）
を実行して、ワークフローの残りの段階を完了する。例
えば、完成した出張承認様式を受け取った後、ワークフ
ロー・アプリケーションは、双方の様式を、会社の旅行
事務所に送り、出張の調整を行う。更に、自動化ワーク
フロー・プロセスは、典型的に、従業員のサインや出張
費用の額のような、必要な項目のチェックも行う。

【０００５】このようなタイプの従来の自動化ワークフ
ロー・システムでは、必要なソフトウエア全ての互換性
のあるバージョンが、当該ワークフローのいずれかの段
階を実行する可能性がある人全員のネットワーク・ノー
ドに、予めインストールされていなければならない。こ
のような従来技術のシステムでは、更に、ワークフロー
の実行やワークフロー・データの記憶を司どる業務規則
が全て厳格に調整されていることも必要である。その理
由は、かかるシステムにおける情報の全ては、ネットワ
ーク・ノード上で実行される、調整されたアプリケーシ
ョンに常駐するのであって、ネットワーク内を転送され
る様式に常駐するのではないからである。様式は単なる
データ収容物である。例えば、サーバが要求元に、要求
元のクライアント上のいずれのソフトウエアでも読むこ
とも処理することもできないフォーマットの様式を送っ
た場合、要求元はその様式に書き込むことができず、ワ
ークフローを完成することができない。結果的に、サー
バ上で実行されるワークフロー・アプリケーション、ま
たは従業員または上司のクライアント・ワークステーシ
ョン上で実行され、サーバから送られた様式との双方向
処理をユーザに行わせる関連プログラムのいずれかを更
新または修正すると、調整されたソフトウエアの更新
を、システム全体に渡って行わなければならない。この
ように調整された更新を必要とするということは、この
タイプの自動化システムは、クライアント・ノードに固
定状のネットワーク接続を有する主要データベース・サ
ーバへの集中度が強いことを意味する。勿論、このタイ
プのワークフロー・システムの集中度が強いという性格
は、ネットワーク帯域および計算資源が効率的に利用さ
れていないことを意味する。これよりも更に重要なこと
は、このような自動化ワークフロー・システムが大きな
ネットワーク上で実施されたとき、ワークフローの段階
が実行される多くのネットワーク・ノードを調整するコ
ストが、過度に大きくなる可能性があることである。そ
の理由は、かかる巨大ネットワークは、ダム端末(dumb
terminal)またはクライアントを制御する単一メインフ
レームまたはサーバよりも、かなり多い故障モード(fai
lure mode)を有するからであり、この環境のために、従
来の自動ワークフロー・モデルが考え出されたのであ
る。

【０００６】

【発明が解決しようとする課題】結果的に、ワークフロ
ーにおいて全潜在的実行者のネットワーク・ノード上で
ワークフローを実行するのに必要な全ソフトウエアの事
前インストールを必要としない、改良されたワークフロ
ー自動化システムが必要とされている。また、強力に集
中化されておらず（即ち、従来技術よりもより柔軟で、
複雑度が低く、処理コストが低い）、したがってネット
ワーク帯域および計算資源を効率的に利用する、ワーク
フロー自動化システムも必要とされている。最後に、単
一のデータベース・サーバと、ワークフローの段階を実
行する実行者のネットワーク・ノードとの間に固定状の
接続を必要としないワークフロー自動化システムも必要
とされている。

【０００７】

【課題を解決するための手段】要約すれば、本発明は、
ワークフローにおいて全潜在的実行者のネットワーク・
ノード上でワークフローを実行するのに必要なソフトウ
エアの全てを事前にインストールする必要がない、改良
されたワークフロー自動化システムである。また、本発
明は、ワークフロー自動化タスクの、ネットワーク・ノ
ード間での分散を可能にし、１つのサーバに集中させな
いことによって、ネットワーク帯域および計算資源の効
率的な利用を図るものである。最後に、本発明のワーク
フロー自動化システムは、単一のデータベース・サーバ
と、ワークフローの段階を実行する実行者のネットワー
ク・ノードとの間に固定状の接続を必要としない。

【０００８】更に特定すれば、本発明は、ネットワーク
に結合された少なくとも１つのサーバと少なくとも１つ
のクライアントとを含み、サーバおよびクライアントが
各々プロセッサとメモリを含み、固有のネットワークＩ
Ｄを有する、ネットワーク上において、逐次プロセスの
ステップを非同期に実行する分散型システムである。こ
の分散型システムは、クライアントのプロセッサ上で実
行可能な要求元プログラムと、サーバのプロセッサ上で
実行可能な提供源プログラムと、提供源から要求元に渡
されるワークフロー・クーリエ(workflow courier)とを
含む。

【０００９】要求元は、ネットワーク上のクライアント
によって発行されたメッセージを制御するように構成さ
れており、メッセージの１つは、サーバの内の特定の１
つに、クライアントのユーザによって要求されたワーク
フロー・クーリエをクライアントに送信するように命令
する、書類要求メッセージである。提供源は、サーバに
向けて発せられたメッセージに応答するように構成され
ており、サーバにワークフロー・クーリエをクライアン
トに送信させることによって、提供源の書類要求メッセ
ージに応答する。このワークフロー・クーリエは、複数
の段階の実行によって完成される１組の様式を含む。複
数の段階が１つのワークフローを構成し、各段階はそれ
ぞれの実行者によって実行可能となっている。本発明の
目的のために、「様式」という用語は、従来の様式も含
めて、ワークフローの実行によって完成される１組のア
クションの提示(manifestation)を意味する。また、ワ
ークフロー・クーリエは、ワークフロー内で実行中の段
階を示す状態データと、少なくとも１つのコード・フラ
グメント参照を含むレジストリ(registry)とを含む。各
コード・フラグメント参照は、実行可能なコード・フラ
グメントを指し示す。

【００１０】ネットワークを通じてワークフロー・クー
リエを受信すると、要求元は様式の１つを表示する。こ
のとき、当該様式および他の表示されている様式に基づ
き、実行すると多数のワークフロー・タスクを実行する
ように構成されている１組の参照コード・フラグメント
(referenced code fragment)を選択的にロードし実行す
る。例えば、可能なワークフロー・タスクは、様式を表
示し、状態データから実行すべき未決段階を決定し、ワ
ークフロー・ルールに基づき未決段階の実行全体にわた
って実行者を案内し、ワークフロー・クーリエ内の様式
および状態データを更新して未決段階の完了を反映し、
更新したワークフロー・クーリエ書類を適切なネットワ
ーク・ノードに送出し、他の実行者によって後続段階を
実行させることを含む。

【００１１】本発明のその他の目的および特徴は、以下
の詳細な説明および特許請求の範囲を添付図面と関連付
けることによって、更に容易に理解できよう。

【００１２】

【発明の実施の形態】

システム・アーキテクチャ 図２を参照すると、本発明によって教示される、ワーク
フロー用非同期分散型システムの好適実施例１００の図
が示されている。

【００１３】好適実施例は、サーバ１１０−１，１１０
−２およびクライアント１１２−１，１１２−２，１１
２−３から成るネットワークを含み、各々固有のネット
ワーク・アドレスを有する。サーバ１１０−１の少なく
とも１つは、ワークフロー・データベース１１４−１に
結合されており、サーバ１１０−１はこれにデータベー
ス・クエリー(database queries)を発行することができ
る。他のサーバ１１０−２もユーザ・ディレクトリ１１
４−２に結合することができる。ユーザ・ディレクトリ
１１４−２は、既知のネットワーク・ユーザに関連する
クライアント１１２のノード・アドレスを纏めたデータ
ベースである。通常、これらのユーザは表示／入力装置
１１３を通じて、彼らの対応するクライアント１１２と
双方向処理を行う。ネットワーク・ノードとして、これ
らをリンクするネットワークを通じて通信が可能でなけ
ればならないことを除いて、サーバ１１０およびクライ
アント１１２間には（ハードウエアまたはオペレーティ
ング・システムの）共通性に対する要求はない。本発明
の目的のために、「通信」とは、あらゆるデータの交換
を意味し、ｅ−ｍａｉｌを含むコンピュータへの連絡、
永久ネットワーク接続を通じた転送、ダイアル・アップ
・アクセス、またはフロッピ・ディスクを用いたスニー
カ・ネット転送(sneaker-net transfer)をも含むものと
する。好適実施例におけるネットワークはインターネッ
トであり、サーバ１１０およびクライアント１１２は、
ＴＣＰ／ＩＰまたはＨＴＴＰ（ハイパーテキスト転送プ
ロトコル）、ＲＰＣ（遠隔手順呼出し：remote procedu
re calls）、またはＳＭＴＰ（単純メール送信プロトコ
ル：simple mail transport protocol）のようなインタ
ーネット・プロトコルを用いて通信を行う。インターネ
ットと共に用いて好適であることに加えて、本発明は、
部署別ローカル・エリア・ネットワーク（ＬＡＮ）、ま
たは企業内エリアネットワーク（ＷＡＮ：corporate wi
de area network）のような、他のタイプのネットワー
クとも使用することができる。

【００１４】ワークフロー・データベース１１４−１
は、ユーザによって起動可能な各ワークフロー（ＷＦ）
１４０ー１，１４０−２に対応する様式１４２およびル
ール１４６を代表するものである。可能なルール１４６
は、（１）どの実行者型が何の要求を承認するのか（こ
の書類の目的のため、「実行者型」という用語は他の実
行者選択基準も含むものとする）、（２）様式１４２に
おけるデータ記入欄のフォーマット設定、（３）１つの
段階が完了したと看做す前に、どのデータ記入欄を埋め
なければならないか、および（４）上位レベルにおいて
ワークフローを記述するメタ−ルール、を含む。また、
ワークフロー・データベース１１４−１は、クライアン
ト１１２上で実行されるとき、クライアントのユーザが
特定のワークフロー１４０のある段階または複数の段階
を完了するのを助ける、コード・フラグメント(code fr
agment)１４４も含む。例えば、コード・フラグメント
１４４は、あるフォーマットで書かれた様式１４２のた
めのハンドラ(handler)とすることができる。様式１４
２は、このハンドラがなければ、クライアント１１２に
よる表示や操作ができないようにすることができる。好
適実施例では、コード・フラグメント１４４は、ジャバ
(Java)のようにプラットフォームに依存しないコンピュ
ータ言語で書かれた実行可能ファイル(executable)であ
る。

【００１５】ジャバ・プログラミング言語の重要な特徴
には、ジャバ言語で書かれたプログラムはアーキテクチ
ャに依存しないことが含まれる。これが意味するのは、
ジャバ・インタープリタを有するあらゆるコンピュータ
・プラットフォーム上で、かかるプログラムは実行可能
であるということである。また、ジャバ・プログラミン
グ言語の重要な特徴には、このようなプログラムの一体
性が確認可能であることも含まれる。これが意味するの
は、ジャバのプログラムの一体性は、その実行前に確認
可能であるということである。ジャバ・プログラム・ベ
リファイア(Java program verifier)は、プログラム
が、予め規定されているストック使用およびデータ使用
規定に準拠しているか否かを判定する。この規定は、確
認されたプログラムが実行中のコンピュータのオペラン
ド・ストックをオーバーフローまたはアンダーフローし
得ないようにすること、および全てのプログラム命令が
既知のデータ・タイプのデータのみを使用することを保
証するものである。その結果、ジャバ言語によるプログ
ラムはオブジェクト・ポインタを作成することができ
ず、通常、ユーザが明示的に使用許可を与えた資源以外
のシステム資源にはアクセスすることができない。結果
的に、１つ以上のコード・フラグメント１４４が、対応
する様式１４２と共に、クライアント１１２にダウンロ
ードされると、クライアント１１２上で実行される、ジ
ャバと互換性のあるブラウザ１６６は、ダウンロードさ
れたコード・フラグメント１４４を確認しかつ実行し、
更に表示を行い、ユーザが対応する様式に記入するのを
助けることができる。勿論、本発明は、クライアント１
１２の各々が既知の構成を有し、プログラムがかかるク
ライアント上で実行される、特定プラットフォーム形態
でも、実施することができる。しかしながら、かかる実
施形態は、柔軟性が大きく失われることになろう。ジャ
バの他の有用な特徴は、ジャバのアプリケーションはク
ライアント・システム上で動的にダウンロードし、イン
ストール可能であることである。

【００１６】サーバ１１０−０１，１１０−２は、プロ
セッサ１２０とメモリ１２２とを含む。メモリ１２２
は、ランダム・アクセス・メモリ（ＲＡＭ）のような高
速メモリ、ハード・ディスクのような遅い二次的メモ
リ、または双方とすることができる。各メモリ１２２に
記憶されるのは、プロセッサ１１０上で実行されるオペ
レーティング・システム１２４、ワークフロー・クーリ
エ１１８、およびワークフロー・エージェント１２６で
ある。ワークフロー・クーリエ１１８は、ＨＴＭＬ（ハ
イパーテキスト作成言語）と同様に構成され、様式１２
８、状態情報１３２、プログラム１３０、および要求さ
れたワークフローの１段階または複数の段階を実行する
ためにクライアント１１２が必要とするプログラム参照
１３４を具体化する。ワークフロー・クーリエ１１８
は、クライアント１１２の１つによって発行されたワー
クフロー要求１１６に応答して、ワークフロー・エージ
ェント１１２６によって動的に形成される。ワークフロ
ー・エージェント１２６は、要求されたワークフローに
関連するワークフロー・データベース１１４−１内に含
まれている情報、および任意として、要求１１６と共に
含まれている要求元ユーザについての具体的な情報を用
いて、ワークフロー・クーリエ１１８を構築する。

【００１７】例えば、クライアント１１２−１のユーザ
が出張申請ワークフロー・メッセージ１１６を発行しよ
うとする場合、ワークフロー・データベース・エントリ
１４０−１が出張申請ワークフローに対応すると仮定す
ると、ワークフロー・エージェント１２６−１は様式１
４２−１、コード・フラグメント１４４−１およびルー
ル１４６−１からワークフロー・クーリエ１１８を構築
する。また、ワークフロー・エージェント１２６−１
は、要求元のネットワークＩＤ、部署、要求の日時のよ
うな既知の情報を利用して、様式１４２−１の記入箇所
のいくつかを埋める。このユーザ情報は、要求元からの
メッセージ１１６またはユーザ・ディレクトリ１１４−
２において見出すことができよう。ワークフロー・クー
リエ１１８を構築する際、ワークフロー・エージェント
１２６は、コード・フラグメント１４４−１およびルー
ル１４６−１をジャバ言語１３０−１に封入する(encap
sulate)。これは、様式１２８−１を表示しこれに記入
する知識を含み、ワークフロー１４０−１の段階を完了
する、汎用的に実行可能なエキスパート・システムとし
て考えることができる。様式１２８−１は、様式１４２
−１のコピーとして、ワークフロー・エージェント１２
６−１によって作成されるが、様式１４２−１の記入欄
に対応するハイパーリンク(hyperlink)が、当該記入欄
に対応するコード・フラグメント（群）の絶対アドレス
（例えば、ＵＲＬ、即ち、ユニバーサル・リソース・ロ
ケータ）を参照すること、ワークフロー・エージェント
１２６−１が、対応するプログラム１３０−１の絶対ア
ドレスを含むレジストリ１３４−１内のエントリのロー
カル・アドレスに、そのハイパーリンクをリセットする
ことが異なる。レジストリ１３４−１については、以下
で更に言及する。しかしながら、レジストリ１３４−１
は、ワークフロー・クーリエ１１８−１内に埋め込まれ
ている、またはその他のネットワーク・ノードのメモリ
１２２に記憶されている、プログラム１３０−１のアド
レスまたは名称を記憶することを注記しておく。レジス
トリ１３４−１のエントリへのアクセスは、ローカル・
ポインタ(local pointer)を通じて得ることができる。
ローカル・ポインタは、個々のレジストリのエントリと
の結合によって、意味のあるネットワーク名（例えば、
実際のプログラムＵＲＬ）に変形され、これを用いて、
参照プログラムが検索される。蓄積された状態１３２−
１については、これはデータ構造であり、そのエントリ
がワークフロー内の完了した段階についての情報を記憶
する。これは、ワークフロー・エージェント１２６−１
によって作成された初期状態では空である。

【００１８】好適実施例では、クライアント１１２の各
々は、プロセッサ１６０と、メモリ１６２（高速の主メ
モリ、低速の二次的メモリ、または双方）とを含み、こ
のメモリ１６２上に、オペレーティング・システム１６
４、ブラウザ１６６およびダウンロードされたワークフ
ロー・クーリエ１１８が記憶される。ブラウザ１６６
は、ワークフロー・クーリエ１１８によって表わされる
ワークフローを部分的に構成する様式１２８との双方向
処理をユーザに行わせる形式で、ダウンロードされたワ
ークフロー・クーリエ１１８を表示するように構成され
たプログラムである。また、ブラウザ１６６は、ダウン
ロードされたワークフロー・クーリエ１１８において参
照されるまたは埋め込まれているプログラム１３０を、
ダウンロードし実行することもできる。上述のように、
好適実施例では、プログラム１３０はジャバで書かれて
いるので、ブラウザ１６６は、ホットジャバ(HotJava)
のようなウエブ・ブラウザ(web browser)である。最後
に、クライアント１１２の内少なくともいくつかは、各
表示／入力装置１１３に結合され、一旦サーバ１１０か
らダウンロードされたなら、ユーザまたは複数のユーザ
にワークフロー・クーリエ１１８との双方向処理を行わ
せる。

【００１９】図３を参照すると、ワークフロー・クーリ
エ１１８が、どのようにしてネットワーク環境において
ワークフローの分散型非同期実行を可能にするかを示
す、フロー・チャートがある。好適実施例では、クライ
アント１１２−１のユーザが、ワークフロー要求１１６
を、ワークフローの実行を担当するサーバ１１０−１に
発行することによって、ワークフローを起動する（２１
０）。このワークフロー要求１１６は、ユーザが力装置
１１３−１から明示的に入力するか、あるいは、表示装
置１１３−１上でクライアント１１２−１によって提示
されるワークフロー選択肢のリストから選択することが
できる。例えば、上述の出張申請の例では、ワークフロ
ー要求１１６は、「クライアント１１２−１が、サーバ
１１０−１による出張ワークフローの起動を要求する」
と等価なＨＴＴＰとすることができる。

【００２０】このワークフロー要求１１６を受信する
と、サーバ１１０−１上で実行中のワークフロー・エー
ジェント１２６−１は、ワークフロー・クーリエ１１８
−１を構築する（２１２）。上述のように、ワークフロ
ー・クーリエ１１８−１は、ユーザ１１１−１によって
起動されたワークフローの段階をクライアントが実行す
るために必要な、様式１２８−１、状態情報１３２−
１、プログラム１３０−１、およびレジストリ１３４−
１を具体化したものである。ワークフロー・エージェン
ト１２６は、ワークフロー・データベース１１４−１か
らこの情報を得る。この情報は、多数のワークフロー１
４０について、関連する様式１４２、基礎となるルール
１４６（例えば、だれがどの要求を承認するか、様式の
中のデータ記入欄のフォーマット、どのデータ記入欄を
埋めなければならないか、および上位レベルにおいてフ
ローを記述するメタ−ルール）、および、クライアント
１１２上で実行されると、受信側クライアント１１２を
使用する実行者がワークフロー段階を完了するのを助け
る、コード・フラグメント１４４を表わす。

【００２１】一旦ワークフロー・クーリエ１１８ー１を
構築したなら、ワークフロー・エージェント１２６−１
は、このワークフロー・クーリエ１１８−１を、ワーク
フローの第１段階を実行することを許可された実行者
（この実行者は通常要求元である）であるユーザが対応
付けられているクライアント１１２−１に送信する（即
ち、ｅ−ｍａｉｌ、ＲＰＣ、ＨＴＴＰ等を用いて）（２
１４）。次に、実行者は、プログラム１３０−１の制御
の下に、様式１２８−１の適切な記入欄を満たすことに
よって、第１段階を実行する（２１６）。プログラム１
３０−１は、第１段階が実行されている間に、クライア
ント１１２−１によって実行される。この書類の目的の
ために、ステップ（２１６）において実行されるアクシ
ョンのことを、「ワークフロー・クーリエの実行」とい
う表現で呼ぶことにする。ユーザが第１段階を完了した
後、クーリエ１１８はそれ自体を更新し（２１８）（即
ち、様式および状態情報を更新する）、次いでワークフ
ローが完了したか否かを判定する（２２０）。ワークフ
ローが完了していない場合（２２０−ＮＯ）、ワークフ
ロー・クーリエ１１８−１はそれ自体を更新済みワーク
フロー・クーリエ１１８−１’として（図１）、ワーク
フローの次の段階を実行することを許可されている実行
者のクライアントに送信し、更に、任意としてデータベ
ース・サーバにステータス更新１１７（図１）を送る
（２２２）。一旦ワークフロー・クーリエ１１８−１’
が次のクライアントによって受信されると、ワークフロ
ーの最終段階が実行されるまで（２２０−ＹＥＳ）、同
一ステップ（２１６〜２２２）が繰り返される。ワーク
フローの最終段階では、完了したワークフロー・クーリ
エがあらゆる最終アクションを行う。その中には、ワー
クフローを開始したデータベース・サーバ１１０−１へ
最終通知を送信することが含まれる。完成した様式は、
サーバ１１０−１にも返送され、最終実行者のクライア
ント１１０に保持するか、あるいは他のデータ・レポジ
トリ(data repository)に送信することも可能である。

【００２２】以上、本発明の好適実施例の基本構成物お
よび方法について説明したが、次にワークフロー・クー
リエ１１８の構成物について、更に詳しく説明する。

【００２３】ワークフロー・クーリエ 図４を参照すると、本発明のワークフロー・クーリエ書
類１１８のデータ構造を示すことを目的とした図が示さ
れている。図２および図３を参照して先に述べたよう
に、ワークフロー・クーリエ書類１１８は、クライアン
ト１１２のユーザによって当該クライアント１１２から
発行されたワークフロー要求１１６に応答して、サーバ
１１０によってその主メモリまたは二次的メモリ１１２
において組み立てられる。ワークフロー・クーリエ１１
８のコピーが、ワークフローの第１段階を完了すべき第
１クライアント（例えば、クライアント１１２−１（図
１））のメモリ１６２にダウンロードされる。次に、ワ
ークフローの段階が完了すると、ワークフロー・クーリ
エ１１８のコピーを更新し、クライアント１１２（それ
ぞれ、１１２−１および１１２−３（図１））のメモリ
に記憶する（更新済みワークフロー・クーリエ１１８’
および１１８”として（図１））。図４に示すように、
各ワークフロー・クーリエ１１８は、様式１２８を含む
複数のデータ構造、プログラム１３０、蓄積状態情報１
３２、およびレジストリ１３４を含む。尚、図４は、ワ
ークフロー・クーリエ１１８が、クライアント１１２−
１のメモリ１６２−１にダウンロードされた後で、第１
実行者によって何等かのアクションがなされる前の状態
を示すことを注記しておく。図４のデータ構造における
情報は、先に論じた要求ワークフロー１４０−１（即
ち、出張申請ワークフロー）から引き出した仮説的値を
表わす。

【００２４】様式データ構造１２８は、要求ワークフロ
ー１４０−１の間に記入しなければならない様式または
複数の様式を表わす。好適実施例では、様式データ構造
１２８における各様式１２８−ｉは、ヘッダ情報３１０
−ｉと、完了すべきワークフローのために埋めなければ
ならない記入欄に対応する、記入欄３１２−ｉｊ（ｉお
よびｊは異なる指標を表わす）とを含む。図４におい
て、様式データ構造１２８は、２種類の様式１２８−１
および１２８−２を含み、これらは各々、多数の記入欄
３１２−１ａ，３１２−１ｂ，３１２−１ｃおよび３１
２−２ａ，３１２−２ｂ，３１２−２ｃ，３１２−２ｄ
をそれぞれ有する。

【００２５】ヘッダ３１０−ｉは、様式１２８−ｉが表
わされるフォーマット全体を規定し（例えば、当該様式
がＨＴＭＬ書類、デルリーナ・フォーム(Delrina Form
s)のような所有権のあるフォーマット(propretary form
at)、またはポストスクリプト・ファイルとして表わさ
れているのかを規定する。他にもいくつか例をあげるこ
とはできる）、更に任意に、クライアント１１２上で様
式を表示するために用いられるハンドラのＵＲＬ（ユニ
バーサル・リソース・ロケータ）を規定する。例えば、
図４において、様式１２８−２（様式１）は、ポストス
クリプト（「Ｐｏｓｔ」）フォーマットであり、ＵＲＬ
がレジストリ１３４のＣＦ３＿ｒｅｆエントリによって
与えられる、ポストスクリプト・ハンドラを必要とす
る。ハンドラ情報は、特定の様式１２８−ｉに対応する
フォーマットに含まれている可能性があるので、これは
ときとして任意となる。これは、ジャバでイネーブルさ
れるブラウザ１６６−１は、特定の様式または書類を処
理すべきクライアント上に互換性のあるハンドラが常駐
していない場合は、当該様式または書類のフォーマット
に基づくハンドラをネットワークから取り込こむように
構成することができるからである。尚、ファイル・フォ
ーマットは、ファイル・ハンドラが、当該様式を構成す
る記入欄３１２−ｉ全てを表示できることを必ずしも意
味するものではない。これは、個々の記入欄３１２−ｉ
はフォーマットが異なる可能性があるためである。例え
ば、項目の中には、それらが埋め込まれている様式とは
異なるグラフィック・フォーマットを有する場合があ
る。これはジャバ書類の設計と一貫している。即ち、Ｈ
ＴＭＬ複合書類は、埋め込まれたフラット・ファイルを
有することができ、かかるフラット・ファイルは属性を
有し、当該フラット・ファイルによって参照される、ま
たは当該フラット・ファイルの属性に含まれている、ハ
ンドラによってのみ表示可能である。

【００２６】好適実施例では、様式１２８の１つはマス
タ・ファイル１２８−１（「Ｍａｓｔｅｒ」）であり、
クライアント１１２がワークフロー・クーリエ書類１１
８を受信すると、これを自動的に表示する。これが可能
なのは、マスタ・ファイル１２８−１が常にＨＴＭＬ／
ジャバ書類としてフォーマットされており、クライアン
ト１１２の各々によって表示可能であるからである。あ
らゆる最上レベルのジャバ複合書類の場合と同様に、マ
スタ・ファイル１２８−１は、各段階の共通起動書類／
様式としての役割を果たす。

【００２７】様式１２８−ｉの各記入欄３１２−ｉｊ
は、データ３２０と、コード・フラグメント参照に対す
るポインタ３２２（例えば、「＊ＣＦ２＿ｒｅｆ」）と
を含む。データ３２０は、実行者またはプログラム１３
０の１つによって記入欄に入力された情報を保持する。
この情報は、ワークフレームが実行されている間、保持
される。尚、図４は、アクションが行われる前のワーク
フロー・クーリエ１１８−１を示すので、データ３２０
は全て空白となっていることに注意されたい。

【００２８】ＣＦ＿ｒｅｆポインタ３２２−ｉは、対応
する記入欄３１２−ｉと関連があるプログラム１３０へ
のポインタを含む、レジストリ１３４内のエントリのア
ドレスを記憶する（即ち、各記入欄は、レジストリ１３
４を通じて、あるプログラムと間接的に関連付けられて
いる）。先に述べたように、プログラム１３０として
は、特定の記入欄に記憶されているデータのためのハン
ドラ、ある記入欄に記入する際に実行者を助ける小型エ
キスパート・システム、またはワークフローをいかにし
て実行すべきかについて精通しているより大きな範囲の
エキスパート・システム等が考えられる。実際の実行可
能プログラム１３０は、プログラム・キャッシュ１３０
内のワークフロー・クーリエの中に記憶したり、または
ワークフロー・クーリエ１１８が常駐しているクライア
ント１１２またはサーバ１１０から離れて記憶すること
ができる。例えば、プログラム・キャッシュ１３０は、
それぞれプログラム１３０−１ａ〜１３０−１ｄに対応
する、４つの局所的に記憶されているプログラムｐｒｏ
ｇ１，２，４，６を含む。これらは、初期状態ではサー
バ１１０−１に記憶されていた。これらのプログラム＊
ｐｒｏｇ１，２，４，６の各ＵＲＬは、レジストリ１３
４の中に記憶されている。また、レジストリ１３４は、
プログラム１３０−２ａのような、ワークフロー・クー
リエ１１８の一部としてそれらの各サーバ１１０からク
ライアント１１２にはダウンロードされない、遠くに記
憶されているプログラムのＵＲＬも記憶する。ワークフ
ローの段階を実行中に、遠くにあるプログラムが必要と
なったとき、それをダウンロードし、他のプログラムと
共にプログラム・キャッシュ１３０に記憶する。例え
ば、図４において、プログラム３（１３０−２ａ）がプ
ログラム・キャッシュ１３０にダウンロードされてい
る。遠くに記憶されているプログラムをダウンロードす
るとき、レジストリ１３４内のプログラムのポインタ
は、線１３５によって示されるように、ダウンロードさ
れたプログラムにリセットされる。レジストリ１３４に
よって提供されるこの間接的な手法(indirection)は、
記入欄の多くが同じプログラムを必要とする可能性があ
る場合（例えば、記入欄３１２−１ａないし３１２−１
ｃおよび３１２−２ｄは全てプログラム１を参照する）
に有用であり、ある共有するプログラムに対するＵＲＬ
を全て記憶する１つのレジストリエントリに、多数のロ
ーカル・ポインタ３２２を記憶すれば、各ＣＦ＿ｒｅｆ
ポインタ３２２内に同じプログラムＵＲＬを記憶するよ
りも、遥かに効率的である。

【００２９】また、ワークフロー・クーリエ１１８は、
蓄積状態データベース１３２も含む。これは、ワークフ
ローの段階が完了した際に、ワークフロー・クーリエ１
１８−１のプログラム要素１３０によって更新される。
これによって、ワークフロー・クーリエ１１８は、送信
されクライアント１１２−２および１１２−３（図２）
のような他のクライアントに非同期で処理される際に、
その状態を保持することが可能となる。次いで、各クラ
イアントにおいて実行されるとき、ワークフロー・クー
リエ１１８は、どの段階を実行するのかを決定する前
に、その蓄積状態１３２を調べる。

【００３０】ワークフロー・クーリエ処理方法 図５を参照すると、本発明がワークフローの１段階を実
行する方法のフロー・チャートが示されている。このフ
ロー・チャートのステップは、対応するユーザがワーク
フローの１段階を実行することを許可されたクライアン
ト１１２にワークフロー・クーリエ１１８が送信された
後に開始する。第１ステップとして、クライアント１１
２上で実行されているブラウザ１６６が、段階に適した
様式１２８−ｉを表示し、この表示の中でユーザは多数
の基本選択肢即ち記入欄から、記入すべきものを選択す
ることができる（４５０）。例えば、この様式は、全て
の段階に共通なマスタ様式１２８−１（図４）とするこ
とができ、「進む」、「待つ」および「キャンセル」の
３つの選択肢がある。実行者はこの中から選択すること
によって、適切な段階を実行する、その段階を後で実行
する、またはその段階の実行を拒否する、という彼の意
志をそれぞれ示すことができる。

【００３１】一旦実行者が段階に適した様式から１つの
記入欄即ち選択肢を選択したなら、ブラウザ１６６は、
選択された記入欄にリンクされたプログラムを取り込
み、実行する（４５２）。リンクされたプログラムは、
クライアント１１２上のプログラム・キャッシュ１３
０、または他のネットワーク・ノード上に記憶されてい
る可能性があることを注記しておく。例えば、実行者が
マスタ様式１２８−１（図４）から「進む」という選択
肢を選択した場合、これは「＊ＣＦ１＿ｒｅｆ」という
コード・フラグメント参照ポインタ値にリンクされてお
り、ブラウザ１６６−１はポインタ「＊ＣＦ１＿ｒｅ
ｆ」にしたがって、レジストリ１３４−１内の「＊ＣＦ
１＿ｒｅｆ」エントリに至る。一方、このエントリは、
ローカル・プログラム・キャッシュ１３０内の「ｐｒｏ
ｇ１」（ワークフロー・エキスパート３１０−１ａ）を
指定する。ブラウザ１６６−１は、次にワークフロー・
エキスパート３１０−１ａをロードし実行する。

【００３２】一旦プログラムが実行されると、このプロ
グラムは、それが封入しているルールおよび蓄積状態１
３２に基づいて、そのタスクを達成するためにアクセス
する必要がある様式１２８およびプログラム１３０を決
定する。次に、実行中のプログラムは、これら必要な様
式１２８およびプログラム１３０の全てへの局所的アク
セス(local access)を有するか否かを判断する。有して
いない場合（４５４−ＮＯ）、実行中のプログラムは、
局所的に入手不可能な書類／様式およびプログラムで必
要なもの全てを、ネットワークから引き込むよう、ブラ
ウザ１６６に命令し（４５６）、これらのプログラムを
プログラム・キャッシュ１３０に、またはワークフロー
・クーリエ１１８の中の様式データベース１２８に追加
する（４５８）。必要な様式およびプログラムが全て局
所的に入手可能になったなら（４５４−ＹＥＳ）、実行
中のプログラムは必要な様式１２８を表示し、これらの
記入欄にリンクされているプログラム（群）の制御の下
で、これらの様式の適切な記入欄との双方向処理（即
ち、選択および記入）を、実行者に行わせる（４６
２）。これらリンクされたプログラムは、実行者が各記
入欄を埋める際にガイダンスを与え、実行者が入力した
情報をチェックし、あるいは実行者が入力した情報に基
づいて、更に必要なアクションがあるか否か判断するこ
とができる。例えば、あるリンクされたプログラムは、
出張申請ワークフローにおいて、所望の出張日をＭＭ／
ＤＤ／ＹＹというフォーマットで入力するように要求元
に助言し、また、要求元が入力した全ての値が、その標
準に準拠しているかチェックすることができる。

【００３３】ユーザの双方向処理の後、実行中のプログ
ラム、即ち、リンクされたプログラムの１つは、ワーク
フロー・クーリエ１１８および表示されている様式を更
新し、ユーザの最新の双方向処理を反映し、再びルール
に基づいて、実行者がこの段階を完了したか否か判断を
行う（４６０）。完了していない場合（４６０−Ｎ
Ｏ）、実行中のプログラムは再度、最後の双方向処理に
おいてユーザが選択した記入欄（があれば）にリンクさ
れたプログラム１３０を取り込み実行する。実行者がこ
の段階を完了したと、実行中のプログラムが判断した場
合（４６０−ＹＥＳ）、実行中のプログラムは蓄積状態
１３２を更新して、現段階が完了したことを示し、更新
したワークフロー・クーリエ１１８を、ワークフローの
次の段階を実行することを許可されたユーザのクライア
ントに送信する（４６４）。

【００３４】更新したワークフロー・クーリエを送信す
る前に、状態更新ステップの一部として、ワークフロー
・クーリエ内のローカル・プログラム・キャッシュ１３
０から、次の段階では不要なプログラム全て（Ａ）、あ
るいはワークフロー・クーリエの永久部分として指定さ
れていないプログラム全て（Ｂ）を、実施形態に応じ
て、除去する。

【００３５】好適実施例では、次の段階を許可された実
行者の識別は、この場合もルールに基づいて判定され
る。このルールは、次の実行者を決定するための静的プ
ロセスを記述することができる（例えば、「段階１が終
了したとき、要求元の上司：Bill Smith @ ###.comに、
更新したワークフロー・クーリエを送る」）。しかしな
がら、本発明のワークフロー・クーリエは、ルール内に
規定されている任意の基準に基づいて、実行者に対して
役割を動的に変形することも可能である。

【００３６】例えば、出張申請の例では、次のように仮
定する。

【００３７】（１）ワークフロー・エキスパートは、
「一旦段階１が完了したなら、出張申請を要求元の上司
に送り承認を得る」（即ち、更新された出張申請を、実
行者型が「要求元上司」である実行者に送る）ことを記
述するルールを有する。

【００３８】（２）ワークフロー・エキスパートは、要
求元が従業員番号１を有し、部署１の従業員であり、ノ
ード１１２−２を使用することを知っている。

【００３９】（３）組織情報を、データベース・サーバ
１１０−２（図２参照）に結合されている、ユーザのデ
ータベース１１４−２から得ることができる。

【００４０】この情報に基づいて、ワークフロー・エキ
スパートは、ユーザのデータベース１１４−２に従業員
１の上司の身分を判定するよう問い合せることをサーバ
１１０−２に依頼するメッセージを、サーバ１１０−２
に送る。回答を受信すると（例えば、「従業員番号２＠
ネットワーク・ノード１１２−２」）、ワークフロー・
エキスパートは、更新したワークフロー・クーリエ１１
８−１”（図２）を当該ノードに送信し、上司はその出
張申請を検討することができる。勿論、他のルールに基
づいて、「要求元の上司」という表現の意味を変えるこ
とも可能である。例えば、国内出張の要求の場合、この
表現は要求者の第１レベルの上司を意味し、これに対し
て海外出張の要求の場合、「要求元の上司」は第２レベ
ルの上司となる可能性がある。このように、ワークフロ
ー・クーリエは実行時にルールを変形することが可能で
ある。

【００４１】プログラム１３０内には情報が埋め込まれ
ているので、段階を完了した後に、更新したワークフロ
ー・クーリエを、ワークフローの中の他の実行者に送出
する際に、他の要因（即ち、他の実行者選択基準）を、
最上レベルのプログラムによって検討することができ
る。例えば、ヘルプ・デスク・アプリケーション(helpd
esk application)においては、終了時間後に１つのヘル
プ・デスクで受信した通話は、後の時間にまたは別の時
間帯に、他の事務所にいる適任者に中継することができ
る。この情報は、ワークフロー・プログラム１３０にア
クセス可能なディレクトリから、容易に得ることができ
る。あるいは、許可された実行者のノードを、ワークフ
ロー・プログラム１３０において、ハード・コード化(h
ard-coded)することも可能である。この構成は、常に短
い時間枠以内で実行される単純なワークフローや、実行
者の全てが単一ＬＡＮに接続されたクライアントを使用
するような場合に最適である。

【００４２】これまで本発明のステップについて説明し
てきたが、これらのステップを出張申請ワークフローに
応用した場合を示す具体例について、図６を参照しなが
ら以下に説明する。

【００４３】図６を参照すると、ワークフロー１４０−
１（即ち、出張申請ワークフロー）のいくつかの段階を
実行する、ワークフロー・クーリエ１１８およびネット
ワーク・ノード１１０，１１２のデータ構造の相互アク
ションを示す、フロー・チャートが示されている。この
図において、データ構造および表示画面を矩形ボックス
として示し、画面上のデータまたは表示に対する処理を
行うプログラムを菱形で示してある。多くの場合、ネッ
トワーク・ノードＩＤおよび図示のステップを担当する
プログラムは、ホスト／プログラム対として示されてい
る。例えば、菱形の中の「１１２／１１６」は、当該ス
テップが、ネットワーク・クライアント１１２上で実行
されているブラウザ１６６によって実行されることを示
す。即ち、図６は、ワークフロー１４０−１の第１段階
（即ち、出張申請ワークフロー）の実行を示し、この場
合、マスタ書類（「Ｍａｓｔｅｒ」）が３つの選択肢
（「進む」、「待つ」および「取消し」）を提供し、他
の様式（「Ｆｏｒｍ１」）が、ユーザにその目的地
（「Ｄｅｓｔ」）、出張日（「Ｄａｔｅ」）、出張目的
（「Ｐｕｒｐ」）を記入し、次いで、それらが終了した
なら、「Ｄｏｎｅ」をクリックするように要求する。

【００４４】ワークフロー１４０−１を開始するため
に、要求元は、クライアント１１２−１に結合されてい
る、表示／入力装置１１３−１上に表示されている、出
張申請ワークフロー選択肢を選択する。その結果、クラ
イアント１１２−１は出張申請メッセージ１１６をサー
バ１１０−１に送り、サーバ１１０−１はワークフロー
・クーリエ１１８−１を構築し、次いでクライアント１
１２−１に送信する。ワークフロー・クーリエ１１８−
１は、ワークフロー１４０−１を完了するために必要
な、様式およびプログラム参照の全てを含む。ワークフ
ロー・クーリエ１１８−１を受信すると、クライアント
１１２上で実行中のブラウザ１６６は、ＨＴＭＬフォー
マットのマスタ様式を表示する。マスタ様式は、ユーザ
が選択可能な３つの選択肢を指定する。それらは、ユー
ザが適切な段階に移行することを選択する「進む」、ユ
ーザが後に処理するためにワークフロー・クーリエを記
憶することを選択する「待つ」、および選択するとワー
クフローを中断する「取り消し」である。この例では、
ユーザは「進む」を選択し、その結果、ブラウザはワー
クフロー・エキスパート（ｐｒｏｇ１）を取り込んで実
行する。ワークフロー・エキスパート（ｐｒｏｇ１）
は、レジストリ１３４の中のＣＦ１＿ｒｅｆエントリの
＊ＣＦ１＿ｒｅｆポインタを通じて、「進む」フィール
ドにリンクされている。

【００４５】プログラム１３０−１ａ（ｐｒｏｇ１）、
即ち、ワークフロー１４０−１のワークフロー・エキス
パートは、ワークフローの段階を実行すべき順序、およ
び各段階においてどの様式および記入欄を埋めなければ
ならないかについての全ての知識を含んでいる。蓄積状
態１３２が空であるという事実に基づいて、ワークフロ
ー・エキスパート１３０−１ａは、段階１を完了する必
要があり、そのためには、クライアント１１２−１を使
用する実行者によって様式１を埋める必要があると判断
する。その結果、ワークフロー・エキスパート１３０１
は、ｐｒｏｇ３（様式１にリンクされているポストスク
リプト・ハンドラ）の助けを借りて、表示装置１１３−
１上に様式１を表示する。この様式は、要求元に出張の
目的地を尋ねる「目的地？」、要求元が出張日を入力す
る「日付？」、要求元に、要求する出張の目的を教える
ように尋ねる「目的？」、および要求者が様式に記入し
終えたと思ったときに選択する「終了」の４つの選択可
能な選択肢を提供する。

【００４６】本例では、ユーザはまず表示された様式１
から「日付？」欄を選択する。その結果、ワークフロー
・エキスパート１３０−１ａは、ブラウザ１６６に、日
付欄にリンクされたプログラム（即ち、ｐｒｏｇ４）を
取り込ませる。先に述べたように、このリンクされたプ
ログラムは、要求元に、所望の出張日を、月／日／年、
即ち、ＭＭ／ＤＤ／ＹＹというフォーマットで入力する
ように助言を与え、要求元が入力した全ての値がその標
準に準拠しているかについてチェックを行う。一旦ｐｒ
ｏｇ４が、ユーザが正しく日付を入力したと判断したな
ら、この情報を様式１２８−２内の適切な欄に適切なフ
ォーマットで入力し、制御をワークフロー・エキスパー
トに戻す。

【００４７】ユーザが適切な様式に適切に記入したと仮
定すると、次にユーザは「終了」選択肢を選択すること
ができる。図６に示す例では、この選択肢はワークフロ
ー・エキスパート（ｐｒｏｇ１）にリンクされている。
何故なら、この選択肢が選択されると、ワークフロー・
エキスパート（ｐｒｏｇ１）は、その中に封入されてい
るルールにしたがって、当該段階が要求元によって完了
されたか否かを判断しなければならないからである。ユ
ーザが正しく第１段階を完了したと仮定すると、ワーク
フロー・エキスパートは蓄積状態１３２を更新して、第
１段階が完了したことを示し、ワークフローの次の段階
を実行することを許可されている実行者のネットワーク
・ノードを決定し、次いで、更新したクーリエをそのノ
ードに送信する。この例では、ワークフロー・エキスパ
ートがブラウザ１６６に、更新したクーリエを、要求元
の上司に関連するネットワーク・ノードである、クライ
アント１１２−２に送信するように要求することを意味
する。

【００４８】本発明の代替実施例の１つにおいては、単
体のウエブ・ブラウザに画像を提示する代わりに、種々
のプログラム１３０を構成して、データおよび様式をＯ
ＬＥオブジェクトとして与え、種々のアプリケーション
において、そしてＯＬＥオブジェクトの共有に対応する
あらゆる環境で、これらを使用可能とすることができる
（注記：ＯＬＥアプリケーションは、他のＯＬＥアプリ
ケーションとデータを共有したり、データを他のＯＬＥ
アプリケーションに埋め込むことができるので、例え
ば、ユーザはワード・プロセッサの書類の中にスプレッ
ドシートを挿入することができ、更にスプレッドシート
のウインドウ内で単にカーソルを動かすだけで、埋め込
み書類の中からスプレッドシート・プログラムの特徴を
用いて、スプレッドシートを編集することができる。）
このような構成では、業務／ワークフロー・ルールを封
入した汎用的に実行可能なプログラムは、多くの共通の
ワード・プロセシング、スプレッドシート、およびデー
タベース・アプリケーションに、データを提供すること
ができる。同様の意味で、プログラム１３０を変更し
て、ワークフローを実行しているネットワーク環境にお
いて標準である、種々のアプリケーション・プログラム
・インターフェースのいずれかに対応するようにするこ
とも可能である。勿論、あらゆる状況において、ワーク
フロー段階を実行すべき、ネットワーク・コンピュータ
の全ては、ワークフロー・クーリエに埋め込まれた、お
よび／またはそれによって参照されるプログラムを処理
し実行できなければならない。

【００４９】図７に示す別の代替実施例では、ワークフ
ロー・クーリエは、ルート・データベース５１０および
／またはルール・データベース５１２と共に構成するこ
とができる。ルート・データベース５１０は、各段階お
よび当該段階の実行を許可された実行者のノードを順番
に纏めたリストを含む。種々のワークフロー・エキスパ
ート１３０がルート５１０にアクセスして、次の実行者
の身分を判定し、更新したワークフロー・クーリエ１１
８を受信する。この手法は、好適実施例の柔軟性に幾ら
か欠けるものであるが、実施の複雑性も少なく、非常に
直接的なワークフローには最適である。この代替実施例
では、適当なところに、許可された実行者の役割を記述
し、許可された実行者の内その役割に合った者のノード
・アドレスを見つけることができる、従業員データベー
スのＵＲＬを提供することによって、柔軟性を更に高め
ることができる。例えば、 段階１ 従業員番号３２１ ノード１１２−１ 段階２ 従業員番号４４７ ノード１１２−２ というようなルートを指定する代わりに、ルートを以下
のように指定することも可能である。

【００５０】 段階１ 従業員番号３２１ ノード１１２−１ 段階２ 要求元の上司 ディレクトリ１１４−２ ＠ ノード１１０−２ 要求元の上司に対するノード情報は、要求元の上司のノ
ードおよび身分はディレクトリ１１４−２において見つ
けることができ、このディレクトリには、データベース
・サーバ１１０−２を通じてアクセスできることを示
す。ルール・データベース５１２は、起動されたワーク
フローに関連するワークフロー・ルール１４６のコピー
である。プログラム１３０は、必要に応じて、これらの
ルールを処理する。

【００５１】更に別の代替実施例では、データベース１
１４内の要約インデックス（例えば、一般的概念につい
て構築されたインデックス）を用いて、具体的な名称の
リストを配置する。各名称は、インデックスされた概念
の一態様に関連する、ルール、データ構造、コード参照
等を含む、具体的なオブジェクト（例えば、ワークフロ
ー１４０）に結び付けられている。この名称リストはユ
ーザに戻され、ユーザは、それらの名称の内１つを選択
するか、あるいはそれらの名称の内１つにリンクし、そ
の点において参照にアクセスしロードする。例えば、ユ
ーザは、「釣に興味が有ります。」というような非常に
一般的なクエリーをデータベース・サーバ１１０に与え
ることによって、ワークフローを起動することができ
る。次いで、サーバはそのデータベース１１４を検索し
て釣に関連するワークフローを捜し出し、例えば、 １）釣の休暇の予約 ２）釣のタックルの注文 ３）釣用ボートの購入 ４）釣用衣服の購入、等 のような種々の選択肢を纏めた書類をユーザに戻す。

【００５２】これらの選択肢からのユーザの１つ以上の
選択に基づいて、クライアント１１０は適切なワークフ
ロー要求メッセージ１１６を提出し、サーバ１１０−２
は上述のように、ワークフロー・クーリエ１１８を構築
し送信する。

【００５３】以上、本発明をいくつかの特定実施例を参
照しながら記載したが、この記載は本発明の例示であっ
て、本発明の限定と解釈すべきではない。特許請求の範
囲に規定した本発明の真の精神および範囲から逸脱する
ことなく、種々の変更が当業者には想起しよう。

【図面の簡単な説明】

【図１】従来技術のワークフロー処理環境のアーキテク
チャを示す図。

【図２】本発明によって教示されたワークフロー用分散
型非同期システムの好適実施例を示す図。

【図３】本発明がネットワークを通じてワークフローの
段階を非同期的に実行する際のステップを示すフローチ
ャート。

【図４】本発明のフローワーク・クーリエのデータ構造
を示すための図。

【図５】本発明のワークフロー・クーリエを用いて、ネ
ットワーク内のクライアントがワークフローの１段階を
完了する方法を示すフローチャート。

【図６】本発明によるワークフローの１段階の実行例を
示す図。

【図７】本発明のワークフロー・クーリエの他の代替実
施例を示す図。

【符号の説明】

１１０−１，１１０−２ サーバ １１２−１，１１２−２，１１２−３ クライアント １１４−１ ワークフロー・データベース １１４−２ ユーザ・ディレクトリ １１６ ワークフロー要求 １１８ ワークフロー・クーリエ １２０ プロセッサ １２２ メモリ １２４ オペレーティング・システム １２６ ワークフロー・エージェント １２８ 様式 １３０ プログラム １３２ 状態情報 １３４ プログラム参照 １３４−１ レジストリ １４０−１，１４０−２ ワークフロー １４２ 様式 １４４ コード・フラグメント １４６ ルール １６０ プロセッサ １６２ メモリ １６４ オペレーティング・システム １６６ ブラウザ

Claims (13)

【特許請求の範囲】
1. 【請求項１】ネットワークに結合された少なくとも１つ
   のサーバと少なくとも１つのクライアントとを含む前記
   ネットワークにおいて、前記少なくとも１つのサーバお
   よび前記少なくとも１つのクライアントの少なくとも部
   分集合の各々と対応付けられたコンピュータ読み取り可
   能なメモリであって、前記各コンピュータ読み取り可能
   メモリは、対応する数の前記部分集合に、ワークフロー
   を構成する複数の段階の内少なくとも１段階を実行し、
   前記部分集合の他のメンバと協同するように指令するこ
   とにより、前記ワークフローの前記全段階が前記メンバ
   によって実行されるようにするものであり、前記コンピ
   ュータ読み取り可能なメモリの１つは、 各々前記メンバの１つと対応付けられた許可された各実
   行者によって実行可能な、前記複数の段階の内少なくと
   も１つの実行によって、完了する１組のアクションの提
   示を表わすデータと、 前記ワークフローにおいて実行された段階を示す状態デ
   ータと、 前記ネットワーク上に記憶されている実行可能なコード
   ・フラグメントを指し示す少なくとも１つのコード・フ
   ラグメント参照を含むレジストリであって、前記実行可
   能なコード・フラグメントの各々は、前記メンバのいず
   れかにおいて実行可能であり、前記メンバの１つにおい
   て実行される際、前記実行可能コード・フラグメントの
   適切な部分集合が、前記１つのメンバに、前記実行者の
   アクション、前記データ状態および前記提示を表わすデ
   ータに基づいて前記ワークフローの適切な段階に関連す
   るワークフローのタスクを実行するように指令し、次い
   で前記提示および前記状態データを更新して、前記適切
   な段階の実行を示すようにした前記レジストリと、から
   成ることを特徴とするコンピュータ読み取り可能メモ
   リ。
2. 【請求項２】請求項１において、前記実行可能コード・
   フラグメントは、プラットフォームに依存しないコンピ
   ュータ言語で書かれ、前記メンバの各々は、更に、前記
   実行可能コード・フラグメントをロードし実行するブラ
   ウザを含むことを特徴とするメモリ。
3. 【請求項３】請求項１において、前記コード・フラグメ
   ントは、前記段階をどのように実行するかを規定する１
   組のワークフロー・ルールを内蔵することを特徴とする
   メモリ。
4. 【請求項４】請求項２において、前記更新された提示、
   前記更新された状態データ、前記アクションおよび前記
   ワークフローに基づいて、前記実行可能コード・フラグ
   メントの部分集合は、実行すべき前記ワークフローの後
   続段階、および該後続段階を実行することを許可された
   実行者の型を決定することを特徴とするメモリ。
5. 【請求項５】請求項４において、更に、 各々許可された実行者に対応するネットワーク・ノード
   のアドレスを含む実行者ディレクトリに対して、少なく
   とも１つのネットワーク参照を含む実行者インデックス
   を含み、 前記ワークフローの前記実行すべき後続段階と、前記後
   続段階を実行することを許可された前記実行者型との決
   定にしたがって、前記実行中の部分集合は、前記１つの
   メンバに、前記参照された実行者ディレクトリにアクセ
   スし、前記実行者ディレクトリから、前記後続段階の実
   行に適したメンバとして、前記実行者型を有するものと
   してその中に表わされている実行者のネットワーク・ノ
   ードを選択するように指令し、前記実行中の部分集合
   は、その後、前記１つのメンバに、前記適切なメンバ、
   前記ルール、前記コード参照、前記更新された提示、お
   よび前記更新された状態データと通信するように指令す
   ることにより、前記適切なメンバの前記メモリが、前記
   適切なメンバに前記後続段階を実行するよう指令するよ
   うに構成可能である、ことを特徴とするメモリ。
6. 【請求項６】請求項２において、更に、 前記段階のシーケンスを規定し、前記シーケンス内の各
   段階を、当該段階を実行することを許可された実行者に
   対応する前記メンバの１つのネットワーク・ノード識別
   子と関連付けるルートを含み、 前記段階の１つの実行に続いて、かつ前記更新された状
   態データと前記ルートとに基づいて、前記実行可能コー
   ド・フラグメントの部分集合は、実行すべき後続段階を
   決定し、前記１つのメンバに、前記前記段階を実行する
   ことを許可された前記実行者、前記ルート、前記コード
   参照、前記更新された提示および前記更新された状態デ
   ータと通信することを指令することにより、前記適切な
   メンバの前記メモリが、前記適切なメンバに前記後続段
   階を実行するよう指令するように構成可能である、こと
   を特徴とするメモリ。
7. 【請求項７】請求項２において、前記提示を表わす前記
   データは、前記ワークフローを構成する前記複数の段階
   の実行によって完成する１組の様式から成り、前記コー
   ド・フラグメントの実行中の部分集合は、前記メンバ
   に、前記１組の様式の内適切なものを表示し、実行者に
   前記様式との双方向処理を可能にするように指令する、
   ことを特徴とするメモリ。
8. 【請求項８】ネットワーク上で逐次プロセスのステップ
   を非同期で実行するコンピュータ・システムであって、
   前記ネットワークは当該ネットワークに結合された少な
   くとも１つのサーバと少なくとも１つのクライアントと
   を含み、前記サーバと前記クライアントは、各々、プロ
   セッサとメモリとを含み、更に固有のネットワークＩＤ
   を有し、前記コンピュータ・システムは、 前記クライアントのプロセッサ上で実行可能な要求元で
   あって、前記ネットワーク上で前記クライアントによっ
   て発行され、前記サーバの内特定の１つに、前記クライ
   アントのユーザによって要求されたワークフロー・クー
   リエを前記クライアントに送信するように命令する要求
   メッセージを含むメッセージを制御するように構成され
   た前記要求元と、 前記サーバのプロセッサ上で実行可能な提供源であっ
   て、前記サーバに向けられた前記メッセージに応答する
   ように構成され、前記サーバに前記ワークフロー・クー
   リエを前記クライアントに送信させることによって、前
   記要求メッセージに応答するように構成された前記提供
   源と、から成り、 前記ワークフロー・クーリエは、 ワークフローを構成し、各実行者によって各々実行可能
   な、複数の段階の実行によって完成する１組の様式と、 前記ワークフローにおいて実行された段階を示す状態デ
   ータと、 各々実行可能コード・フラグメントを指し示す少なくと
   も１つのコード・フラグメント参照を含むレジストリ
   と、から成り、 前記ネットワークを通じて前記ワークフロー・クーリエ
   を受信したとき、前記クライアントは前記様式の１つを
   表示し、前記様式とユーザとの双方向処理およびその他
   の表示された様式に基づいて、実行されると、前記様式
   を表示すること、前記状態から実行すべき未決段階を決
   定すること、ワークフロー・ルールに基づいて、前記未
   決段階の実行の間実行者を案内すること、および前記ワ
   ークフロー・クーリエ内の前記様式および前記状態を更
   新して前記未決段階の完了を反映することを含む、１つ
   以上のある数のワークフロー・タスクを実行するように
   構成された１組の参照コード・フラグメントを選択的に
   ロードしかつ実行する、ことを特徴とするコンピュータ
   ・システム。
9. 【請求項９】請求項８において、前記実行可能コード・
   フラグメントは、プラットフォームに依存しないコンピ
   ュータ言語で書かれ、前記クライアントは、更に、前記
   実行可能コード・フラグメントをロードし実行するブラ
   ウザを含むことを特徴とするコンピュータ・システム。
10. 【請求項１０】請求項９において、前記提供源も、広い
    ユーザ・ワークフロー要求に含まれる検索語を満足す
    る、複数のワークフロー選択肢を前記要求元に供給する
    ことによって、前記要求元から発行された前記広いユー
    ザ・ワークフロー要求に応答するように構成され、前記
    ワークフロー選択肢の各々は、特定のワークフローにリ
    ンクされ、前記ユーザが前記複数のワークフロー選択肢
    の１つを選択したとき、前記要求元は前記ネットワーク
    上で、前記リンクされたワークフローに対するワークフ
    ロー要求を発行するように構成されていることを特徴と
    するコンピュータ・システム。
11. 【請求項１１】ネットワーク上でワークフローを実行す
    るためにコンピュータ上で実施する方法であって、 （１）前記ネットワーク上にワークフロー要求を発行す
    るステップと、 （２）前記ワークフロー要求に応答して、サーバがワー
    クフロー・クーリエを構築するステップであって、前記
    ワークフロー・クーリエは、（ａ）各実行者によって各
    々実行可能な、前記ワークフローを構成する複数の段階
    の内少なくとも１つの実行によって完了する、１組のア
    クションの提示を表わす１組のデータと、（ｂ）前記ワ
    ークフローにおいて実行された段階を示す状態データ
    と、（ｃ）各々前記ノードのいずれかにおいて実行可能
    であり、前記いずれかのノードの一体性および安全性に
    悪影響を与えない、実行可能なコード・フラグメントを
    指し示す少なくとも１つのコード・フラグメント参照を
    含むレジストリと、から成る前記ワークフロー・クーリ
    エを構築するステップと、 （３）前記サーバが、前記ワークフロー・クーリエと、
    前記ワークフローの適切な段階とに応じて、実行を許可
    された実行者に対応する選択されたネットワーク・ノー
    ドに、前記ワークフロー・クーリエを送信するステップ
    と、から成ることを特徴とするコンピュータに実施する
    方法。
12. 【請求項１２】請求項１１において、更に、 （１）前記ネットワークを通じて前記ワークフロー・ク
    ーリエを受信したとき、前記選択されたネットワーク・
    ノードが前記ネットワーク・クーリエを実行することに
    より、前記実行者が前記実行中のワークフロー・クーリ
    エの制御の下で、前記適切な段階を実行し、前記ワーク
    フロー・クーリエは、前記実行者が、前記提示を表わす
    前記１組のデータと、前記状態データと、前記段階をど
    のように実行するかを規定するワークフロー・ルールと
    にしたがって、前記段階を実行することを保証するステ
    ップと、 （２）前記適切な段階の完了時に、前記ワークフロー・
    クーリエがそれ自体を更新し、前記適切な段階の完了時
    における前記ワークフローのステータスを反映するステ
    ップと、を含むことを特徴とするコンピュータに実施す
    る方法。
13. 【請求項１３】請求項１２において、前記ワークフロー
    ・クーリエを実行する前記ステップは、更に、 前記提示を表わす１組のデータの少なくとも部分集合を
    表示するステップと、 前記表示された部分集合とのユーザの双方向処理に基づ
    いて、１組の参照コード・フラグメントを選択的にロー
    ドし、実行するステップと、から成り、 前記参照コード・フラグメントは、実行されると、１つ
    以上のある数のワークフロー・タスクを実行し、前記ワ
    ークフロー・タスクは、 １組のアクションの提示を表わす前記１組のデータを表
    示することと、 前記状態から、実行すべき未決段階を決定することと、 ワークフロー・ルールに基づいて、前記未決段階の実行
    の間実行者を案内することと、 前記ワークフロー・クーリエ内の前記１組のアクション
    および前記状態データの提示を表わす前記１組のデータ
    を更新して前記未決段階の完了を反映することと、 他の実行者による後続段階の実行のために、更新したワ
    ークフロー・クーリエを適切なネットワーク・ノードに
    送出すること、を含むコンピュータに実施する方法。