(57)【要約】１組のソフトウェアツールを利用してトップダウン型ワークフロープロセスモデルをグラフィカル定義するためのシステムおよび方法を提示する。本発明は３つの主要な構成要素、すなわちプロセスデザイナ（３００）、プロセスサーバ（５００）、およびプロセスクライアントを有する。該プロセスデザイナ（３００）は、ユーザがプログラミング無しで、トップダウン方式でビジネスプロセスを定義することを可能にする。プロセス定義は、タスクおよびサブプロセスなどの構成要素から形成される。本発明のタスクは、エンドユーザ（６０２）がタスクを完了するために必要な全てのＧＵＩパネルを組み込んでいる。プロセスモデルはまた役割、エンドユーザ（６０２）、ビジネス論理、および他の構成要素をも含む。アダプタは、本発明の外部のビジネスデータおよび論理をプロセスモデルに組み込むことを可能にする。次いで該プロセスモデル定義は、タスクをエンドユーザ（６０２）に提示するプロセスサーバ（５００）にインストールされる。エンドユーザ（６０２）はプロセスクライアントを通してタスクにアクセスし、実行する。【選択図】図１０
2005502928.tif 000002
【特許請求の範囲】
【請求項１】
ビジネスプロセスを定義して実現するための方法であって、
ａ）ユーザ対話を必要とする少なくとも１つのタスクを含め、構成要素をプロセス定義に追加するステップと、
ｂ）前記タスクのインタフェース要素を定義するステップと、
ｃ）前記プロセス定義の構成要素間の制御フローを定義するステップと、
ｄ）制御フローの実行のため、および定義されたインタフェース要素を介してエンドユーザ用の少なくとも１つのタスクの提出のために、プロセスサーバにプロセスモデルを提出するステップと、を含む方法。
【請求項２】
ｅ）プロセス定義の構成要素間のデータフローを定義するステップをさらに含む、請求項１に記載の方法。
【請求項３】
構成要素の少なくとも幾つかが動作または結果のいずれかとなり得るイベントを持ち、かつさらに１つの構成要素の結果を第２構成要素の動作にリンクすることによって制御フローが少なくとも部分的に定義される、請求項２に記載の方法。
【請求項４】
特定の構成要素が他の構成要素内に包含される、請求項３に記載の方法。
【請求項５】
前記構成要素が属性を有する、請求項４に記載の方法。
【請求項６】
データフローを定義するプロセスが、別の構成要素を包含する構成要素の属性を包含される構成要素の属性に関連付けるステップを含む、請求項５に記載の方法。
【請求項７】
企業アプリケーションを生成する方法であって、
（ａ）各ビルディングブロックはワークフロープロセスにおける１ステップを表わしており、ワークフロープロセスを定義する複数のビルディングブロックを識別するステップと、
（ｂ）前記複数のビルディングブロックを順序付け、かつつなぎ合わせて、ワークフロープロセスモデルを作成するステップと、
（ｃ）少なくとも１つのビルディングブロック内で達成すべき少なくとも１つのタスクを定義するステップと、
（ｄ）データを前記少なくとも１つのタスクに関連付けるステップと、
（ｅ）ワークフロープロセスモデルでプロセスサーバにロードするステップと、
（ｆ）プロセスサーバ上でユーザがアクセス可能なクライアントアプリケーションを生成するステップと、を含む方法。
【請求項８】
各ビルディングブロックが構成要素およびリソースのうちの少なくとも１つから構成される、請求項７に記載の方法。
【請求項９】
各ビルディングブロックがコンテナおよび要素のうちの少なくとも１つから構成される、請求項８に記載の方法。
【請求項１０】
前記コンテナがプロセス、タスク、ルータ、およびコントローラのうちの少なくとも１つから構成される、請求項９に記載の方法。
【請求項１１】
前記要素が、ビュー、ジョイン、コンパレータ、タイマ、アサイナ、ノーティファイア、処置ランチャー、アダプタ、およびロッカのうちの少なくとも１つから構成される、請求項９に記載の方法。
【請求項１２】
前記リソースがビジネスエンティティ、役割、ユーザ、カレンダ、決定基準、およびデータコントローラのうちの少なくとも１つから構成される、請求項８に記載の方法。
【請求項１３】
ステップ（ｂ）がビルディングブロックを図形的に表示することを含む、請求項７に記載の方法。
【請求項１４】
前記タスクがコンピュータプログラムによって実行される１単位の作業を含む、請求項７に記載の方法。
【請求項１５】
トップダウン型ワークフロープロセスを定義して実現する方法であって、
（ａ）ワークフロープロセスにおける最上位プロセスステップを識別するステップと、
（ｂ）最上位プロセスステップの各々を表わす、図形的に表示されたビルディングブロックを選択するステップと、
（ｃ）前記ビルディングブロックを配設し接続して最上位ワークフロープロセスモデルを作成するステップと、
（ｄ）最上位ワークフロープロセスモデルにおける最上位プロセスステップのうちのどれがサブプロセスステップを受け入れやすいかを決定するステップと、
（ｅ）ステップ（ｄ）で識別された各最上位プロセスステップについて、サブプロセスステップを表わすさらなるビルディングブロックを選択し、このように選択されたビルディングブロックをステップ（ｄ）で識別されたそれぞれの最上位プロセスステップに関連付けるステップと、
（ｆ）非制御データをビルディングブロックの少なくとも一部分に関連付けるステップと、
（ｇ）ビルディングブロックおよび非制御データの少なくとも一部分をプロセスサーバにロードするステップと、
（ｈ）関連付けられたサブプロセスステップを含めて最上位ワークフロープロセスモデルを実行するステップと、を含む方法。
【請求項１６】
各ビルディングブロックが構成要素およびリソースのうちの少なくとも１つから構成される、請求項１５に記載の方法。
【請求項１７】
前記構成要素がコンテナおよび要素のうちの少なくとも１つから構成される、請求項１６に記載の方法。
【請求項１８】
前記コンテナがプロセス、タスク、ルータ、およびコントローラのうちの少なくとも１つから構成される、請求項１６に記載の方法。
【請求項１９】
前記要素がビュー、ジョイン、コンパレータ、タイマ、アサイナ、ノーティファイア、処置ランチャー、アダプタ、およびロッカのうちの少なくとも１つから構成される、請求項１７に記載の方法。
【請求項２０】
前記リソースがビジネスエンティティ、役割、ユーザ、カレンダ、決定判断、およびデータコントローラのうちの少なくとも１つから構成される、請求項１６に記載の方法。
【請求項２１】
ビルディングブロックが図形的に線でひとつ結び合わされる、請求項１５に記載の方法。
【請求項２２】
ステップ（ｆ）がデータのマッピングを含む、請求項１５に記載の方法。
【請求項２３】
接続されたビルディングブロック内のサブプロセスステップを変更するステップをさらに含む、請求項１５に記載の方法。
【請求項２４】
プロセスデザインサーバを介してビルディングブロックをユーザに利用可能にするステップをさらに含む、請求項１５に記載の方法。
【請求項２５】
サブプロセスの１つまたはそれ以上について特定の知識を持つ者に、それを表わすビルディングブロックの選択および配設を支援するように要求するステップをさらに含む、請求項１５に記載の方法。
【請求項２６】
ビジネスプロセスを設計して実現するためのシステムであって、
（ａ）ビジネスプロセスモデルをトップダウン方式で定義するためにグラフィカルユーザインタフェースを有するプロセスデザイナツールを含み、前記ビジネスプロセスモデルは、
（ｉ）少なくとも２つの構成要素間で定義された制御フローを有する少なくとも１つのプロセス、
（ｉｉ）タスクを実行し、かつタスクを完成するために必要なビジネスデータへのアクセスを定義するためにユーザインタフェースを各々に組み込んでいるタスク定義を有する少なくとも１つのタスク、を有しており、
（ｂ）前記プロセスで定義された制御フローに従い、かつユーザインタフェースを介して前記定義されたタスクを少なくとも１人のエンドユーザに提示することによって、プロセスモデルを配置することのできるプロセスサーバをさらに備えたシステム。
【請求項２７】
企業のためのプロセスモデルを作成して実現するためのシステムであって、
構成要素およびリソースを作成するため、および前記構成要素およびリソースの間でプロセスフローおよびデータフローを定義するために使用されるグラフィカルユーザインタフェースを備えており、前記構成要素およびリソースのうちの少なくとも１つに関連付けられる少なくとも１つの手順を定義することのできるプロセスデザイナと、
前記少なくとも１つの手順を実行し、かつ前記プロセスデザイナで定義された優先順位方式に従ってタスクを割り当てるためのプロセスサーバと、
エンドユーザがログオンし、プロセスサーバに接続し、いずれかの割り当てられたタスクにアクセスし、かつ前記割り当てられたタスクを実行することを可能にするように動作可能なグラフィカルユーザインタフェースを備えたプロセスクライアントと、を備えているシステム。
【請求項２８】
前記プロセスデザイナが複数のビルディングブロックをユーザに提示する、請求項２７に記載のシステム。
【請求項２９】
前記プロセスサーバに接続されたシステム管理者をさらに備えている、請求項２７に記載のシステム。
【請求項３０】
前記割り当てられたタスクがコンピュータによって実行される、請求項２７に記載のシステム。
【請求項３１】
前記プロセスデザイナが作成された構成要素およびリソースを他のプロセスモデルで使用するために利用可能にする、請求項２７に記載のシステム。
【請求項３２】
構成要素およびリソースの間で共通ユーザインタフェースを定義するための手段をさらに備えている、請求項２７に記載のシステム。
【請求項３３】
構成要素間、リソース間、および構成要素とリソースとの間でデータをマップするために手段をさらに備えている、請求項２７に記載のシステム。
【発明の詳細な説明】
【０００１】
本願は、２０００年３月２０日に出願した米国仮特許出願第６０／１９１，１６６号の利益を主張する。
【０００２】
【技術分野】
本発明は、ビジネスプロセスのトップダウン型の定義付けおよび実現のための方法およびコンピュータシステムに関する。
【０００３】
【発明の背景】
本発明は、トップダウン方式でビジネスプロセスを定義して実現することによって、１つのソフトウェアアプリケーションがビジネス全体のプロセスを調整することを可能にする。ビジネスプロセスとは、簡単に言うと、会社が運営を行うために会社が実行しなければならないプロセスである。例えば、製品を販売する事業を行っている企業は、これらの製品の注文を受け付けることができなければならない。注文を受け付けて製品を出荷する行為全体をビジネスプロセスと考えることができる。より小規模の場合、電話注文を会社のデータベースに入力することもビジネスプロセスである。
【０００４】
トップダウン手法でビジネスプロセスを分析するということは、企業の最高レベルから始めながらプロセスを定義していくことを意味する。この手法を用いる分析は、製品を販売するプロセスから始めることができるかもしれない。製品を販売するプロセスは、顧客の注文の受付、顧客の注文に応じて製品を出荷するなど、より小さいサブプロセスに分解することができる。これらのさらなるサブプロセスの各々は、全ての従業員のタスクがビジネスプロセスモデルに示されるまで、さらに小さくすることができる。
【０００５】
トップダウン方式でビジネスプロセスを定義するという概念は新しいものではない。トップダウン型ビジネスプロセスモデルの作成を支援する先行技術のグラフィックフトウェアツールが存在する。これらの先行技術ツールを使用する最終結果は、ビジネスのプロセスの詳細なトップダウン型定義である。ビジネスのプロセスをこの方法で明示的に定義すると無駄、非効率、および重複が明らかになるので、経営幹部および分析者はそのような詳細な定義が有用であることを知る。次いで該ツールはビジネスプロセスを再定義し合理化することを可能にし、ビジネスは新しいトップダウン型ビジネスプロセスを採用すると、いっそう収益を多くすることができると期待される。
【０００６】
残念ながら、新たに定義されたビジネスプロセスは次いで実世界で実現しなければならない。どんな経営幹部も知る通り、紙の上にのみ存在する新しいプロセスを実現することは決して容易ではない。第一にビジネスプロセスの説明が一般的にコンピュータソフトウェア開発者に与えられ、次いで開発者はその理解の及ぶ限りそれを実現しようと努める。その結果が、ビジネス分析者が開発したプロセスとぴったり一致することはほとんど無い。これは、ビジネス分析者がソフトウェアを直接開発することができず、プロセスを実現するために代わりにソフトウェアプログラマに頼らなければならないという事実の本質的な結果である。
【０００７】
克服すべき別の困難な問題は、単一のビジネスプロセスでさえ実現するために必要なコンピュータ資源の調整である。全ての大会社には、多数の非互換性コンピュータプラッとフォーム、オペレーティングシステム、ネットワーキングプロトコル、データベース、およびカスタムアプリケーションが共存している。そのような非互換性を無くしてしまうことは不可能であるので、新しいビジネスプロセスを実現するためには、様々な環境を統合しなければならない。
【０００８】
近年、異種のコンピュータシステムの統合を支援するために、多くの会社がメッセージ指向ミドルウェア（ＭＯＭ）製品に目を向けるようになった。一般的に、そのようなミドルウェア製品は、「ビジネスイベント」を介して情報を捕獲し、分析し、交換することによって、アプリケーションとのインタフェースを提供する。このメカニズムは、ビジネス分析者が多くの多様なアプリケーションプラットフォームを統合して一緒に作動させることを可能にする。
【０００９】
残念ながら、ミドルウェア製品はビジネスアプリケーションが互いにやりとりを行なうことを可能にするが、新しいビジネスプロセスを自動化するタスクを容易にはしない。ミドルウェア製品はアプリケーション間のビジネス構造またはビジネス知識の再使用を考慮していない。代わりに、そのようなビジネス構造または知識を再使用しなければならないときに、新しいアプリケーションを初めから形成しなければならない。
【００１０】
ミドルウェア解決策は構造または知識を再使用しなければならないときに役立つことができないが、多くの会社はこの要求を満たすためにオブジェクト指向開発環境に目を向けるようになった。オブジェクト指向パラダイムでは再使用可能性が重要な要素であるので、この手法は、以前のアプリケーションで作成されたオブジェクトを再使用することによって、新しいアプリケーションを開発することができなければならない。残念ながら、オブジェクトの作成、定義付け、および改善の技術的性質のため、オブジェクト指向パラダイムの再使用可能性の利点の多くは、一般的なビジネスプロセス分析者にはアクセス不能である。
【００１１】
これらの難点のため、新しく設計されたトップダウン型ビジネスプロセスはほとんど常に、延々と時間のかかるイベントである。実際、新しいビジネスプロセスの実現に関わる努力および時間が非常に大きいので、新しいプロセスは、プロセスの完全な実現が達成される前にしばしば改善され、あるいは廃棄されることさえある。
【００１２】
必要とされているものは、ソフトウェアプログラマではなく実業家によって作成されかつ所有されるビジネスモデルの実際の定義付けの結果として、定義されたビジネスモデルを実現する実行可能なソフトウェアが得られる、トップダウン型ビジネスプロセスモデルを単一ステップで定義して実現する能力である。さらに必要とされているものは、既存のモードインタフェースを利用することによって、あるいは企業アプリケーションおよびデータベースに直接リンクするインタフェースを使用することによって、新たに定義されたビジネスモデルを既存の企業アプリケーションと統合する能力である。求められるアプリケーションは、高レベルの抽象化の容易に再使用可能なオブジェクトを形成して、使用のたびに完全な再定義付けを行なうことなくオブジェクトを企業全体で使用できるようにする能力を持たなければならない。最後に、同じく必要とされているものは、予め定義されたプロセスを配備して、組織内の従業員または既存のアプリケーションによる完成のためにタスクを割り当てるプロセスサーバでもある。
【００１３】
【発明の概要】
本発明は、トップダウン型ワークフロープロセスモデルの図形定義を可能にする１組のソフトウェアを統合することによって、これらの目的を達成する。ひとたび定義されると、これらのモデルは、現行のビジネス運営を中断することなく、実時間で配備することのできる完全に使用可能な企業アプリケーションとなる。
【００１４】
本発明では、ビジネスプロセスは、プログラミングを必要としないグラフィカルインタフェースを使用して定義される。プロセスモデルの構成要素は設計者に視覚的に提示され、設計者は構成要素を互いにリンクしてワークフローおよびビジネス論理を形成することができる。ビジネスワークフローは、個人または既存のビジネスプログラムによって達成される１単位の作業であるビジネスタスクのレベルまで定義することができる。実際、本発明では、タスクの完成のためにエンドユーザに提示されるユーザインタフェースを含めて、タスク自体が完全に定義される。複数のハードウェア構成要素用のインタフェースを開発して、ジャバ実行時アプリケーション、ウェブブラウザ、またはパーム社（カリフォルニア州サンタクララ）によるパームＯＳなどのＰＤＡインタフェースさえも通してタスクを完成させることができる。
【００１５】
本発明は３つの主要な構成要素すなわちプロセス設計者、プロセスサーバ、およびプロセスクライアントを持つ。プロセス設計者は利用者がトップダウン方式でビジネスプロセスを定義することを可能にする。プロセス定義はタスクおよびサブプロセスなどの構成要素から作られる。タスクは、人間によってまたは自動的に既存のシステムによって実行される作業項目である。プロセスモデルは、サービスの並列処理、同期化、およびタイミングを可能にする役割、エンドユーザ、ビジネス論理、および他の構成要素をも含む。ビジネスデータはデータベースからだけでなく、既存の企業アプリケーションからも得られる。
【００１６】
完成した企業プロセス定義はプロセスサーバに配備され、そこで実行される。利用者はプロセスサーバにログインし、次いでプロセスサーバは彼らにそのタスク割当てを提示する。彼らの割当てと共に、利用者は彼らのタスクを達成するために必要なビジネスデータおよび必要ならばタスクを実行するために要求されるＧＵＩインタフェースをも提示される。プロセスサーバはワークフローに優先順位を付け、タスク待ち行列監視のための管理インタフェースを提供する。
【００１７】
プロセスクライアントは、エンドユーザがプロセスサーバにログオンして接続し、タスクリストにアクセスし、彼らに割り当てられたタスクを実行することを可能にするＧＵＩベースのアプリケーション、ウェブブラウザ、またはＰＤＡインタフェースでもある。エンドユーザは、割り当てられたタスクを完成するのに必要な情報および資源に自動的にアクセスする。
【００１８】
【発明の実施の形態】
「プロセスモデル１００」
図１に示す通り、プロセスモデル１００は企業、部署、または何らかの他の種類のエンティティまたは事業単位に存在する事業活動の表現またはモデルである。各プロセスモデル１００は１つまたはそれ以上のプロセス１２０を含み、その各々が特定の実世界事業活動を表わす。プロセス例１２０は「購買注文の受入れ」および「請求書の支払い」を含む。
【００１９】
各プロセス１２０は、１つまたはそれ以上のサブプロセス１２２、もしくは１つまたはそれ以上のタスク１３０を含むことができる。タスク１３０とは一般的に、プロセス１２０内の１ステップとして人間または自動コンピュータプログラムによって実行される１単位の作業である。コンピュータ端末への購入注文の入力、および印字する小切手をプリンタに送信することは、タスク例１３０である。プロセス１２０内にサブプロセス１２２が囲まれていることは、囲んでいるプロセス１２０が完了したとみなされるには、サブプロセス１２２を完了させなければならないことを示す。単一プロセス１２０が複数のサブプロセス１２２を含むことができるが、直接的には単一のタスク１３０しか含むことができない。
【００２０】
本発明では、サブプロセス１２２は、それを含むプロセス１２０の一部を構成するので、そのプロセス１２０の「構成要素」とみなされる。プロセス１２０は、１つまたはそれ以上の構成要素を含んでいるので、それ自体「コンテナ」とみなされる。プロセス１２０はまた、それ自体をより大きいコンテナに含めることができるので、構成要素ともみなされる。
【００２１】
各プロセス１２０はイベント１０２によってトリガされる。例えば、「購買注文の受入れ」プロセス１２０のトリガイベント１０２は、購買注文の受取りとすることができる。イベント１０２によってトリガされることに加えて、各プロセス１２０はまた、プロセス１２０が完了したときに新しいイベント１０２を形成する。例えば、購買注文受入れプロセス１２０後の新しいイベント１０２は、「購買注文受入れ済み」と呼ぶことができるかもしれない。プロセス１２０をトリガするイベント１０２は動作１０４と呼ばれる。完了したプロセス１２０によって形成されるイベント１０２は結果１０６と呼ばれる。実世界イベントが発生したときに、それは一般的に第１プロセス１２０の結果および別のプロセスの動作１０４として表わされる。図１では各プロセス１２０に単一の動作１０４および結果１０６しか示していないが、１つの構成要素が複数の動作１０４および結果１０６を持つことが可能である。
【００２２】
完全なプロセスモデル１００を形成するには２つの重要なステップがある。第一に、プロセスモデル１００の制御フローを形成しなければならない。制御フローは、企業におけるプロセス１２０およびタスク１３０の順序を記述する。ユーザは、既知のプロセス１２０を取り、１つのプロセス１２０の結果１０６を別のプロセス１２０の動作１０４に接続することによって、制御フローモデルを作成する。
【００２３】
イベント１０２を介するプロセス１２０のリンキングは、それ自体で完全なプロセスモデル１００を形成しない。これは、ビジネスデータも企業内を流れるからである。ビジネスデータの動きを示すことなくプロセスおよびイベントを示すモデル１００は不完全である。例えば「処理済み請求」結果１０６を生じる「請求処理」プロセス１２０は、誰の請求が処理されたかに関する情報が無ければ無意味である。したがって、プロセスモデル１００は制御フローおよびデータフローの両方を含まなければならない。図１に示したプロセスモデル１００は制御フローのみを示し、データフローを示していないので、プロセスモデル１００の完全な表現ではない。
【００２４】
図２の概念図はより完全なプロセスモデル１００を示す。この図は請求処理プロセス１２０を示す。請求処理プロセス１２０内に配置されているのは、請求承認サブプロセス１２２であり、それが今度は単一の承認獲得タスク１３０から成る。請求処理プロセス１２０、請求承認サブプロセス１２２、および承認獲得タスク１３０は各々１つの動作１０４および１つの結果１０６を有する。請求処理プロセス１２０をトリガする動作１０４の一例は、「請求受付」動作１０４であろう。駆動処理プロセス１２０が完了すると、プロセス１２０は結果１０６を「請求承認」または「請求拒否」など残りの制御フローモデル１００に提供する。本結果１０６は次いで、さらなるプロセス１２０をトリガすることができる。
【００２５】
駆動を承認すべきか拒否すべきかを決定するために、承認獲得タスク１３０を実行する者は、請求に関連する特定のデータを検討する必要がある。本発明では、この種のデータは請求処理プロセス１２０内の変数または属性１０８に格納される。図２には３つの属性１０８、すなわち顧客名、請求金額、および請求の承認状態が示されている。請求処理プロセス１２０は、顧客の住所および電話番号、顧客ＩＤ、請求の理由、製品の製造番号等々のような、より多くの属性１０８を持つことができる。図２に示す属性１０８は例示を目的とするものであり、実際の実現のためには充分ではない。同様の属性１０８が請求承認サブプロセス１２２および承認獲得タスク１３０に示されている。
【００２６】
本発明のデータマッピングの目的は、制御フローが実行されるときに、１つの構成要素の属性１０８から次の構成要素の属性１０８にデータを移動させることである。コンテナは、コンテナの属性１０８を構成要素の属性１０８にマップすることによって、含まれる構成要素内にデータを渡し、かつそこからデータを受け取ることが両方ともできる。例えば、請求処理プロセス１２０の顧客名および請求金額属性１０８は、点線で示すように、請求承認サブプロセス１２２の属性にマップされる。この方法で、請求処理プロセス１２０の顧客名および請求金額属性１０８の値は、請求承認サブプロセス１２２の同様の名前の属性１０８に転送される。
【００２７】
同様に、サブプロセス１２２はこれらの値を、包含された承認獲得タスク１３０の属性に転送する。承認獲得タスク１３０が完了するときに、「承認するか？」属性１０８は、タスク１３０の完了中に割り当てられた値を持つ。この値は次いで、コンテナの属性値を構成要素の属性１０８に関連付けるデータマッピングを通して、サブプロセス１２２の「承認するか？」属性にマップされる。最後に、「承認するか？」属性値は、請求処理プロセス１２０の適切な属性１０８にマップされる。
【００２８】
「構成要素１１０」
プロセスモデル１００を形成するために、本発明は定義された１組のビルディングブロックを使用する。これらのビルディングブロックは、図３に示すように構成要素１１０と資源２５０との間で分けることができる。構成要素１１０は、プロセスモデル１００の制御フローを図形的に構成するために使用される基本ビルディングブロックである。資源２５０は企業のビジネスデータのプレースホルダであり、プロセスモデル１００における情報フローのモデリングをサポートする。
【００２９】
全ての構成要素１１０は、動作１０４、結果１０６、および属性１０８をはじめ、それらに関連付けられる基本的プロパティ１０９を有する。上記のように、動作１０４および結果１０６は、制御フローおよび情報フローの両方で使用されるビジネスイベント１０２である。属性１０８は、構成要素１１０に有用なビジネス情報を格納するために使用される。構成要素１１０自体と同様に、イベント１０２も、１つの構成要素１１０から別の構成要素にデータを移動するための属性１０８を有する。
【００３０】
幾つかの構成要素、すなわちプロセス１２０、タスク１３０、およびコントローラ１５０は、プロセスモデルにおける複数の場所で同時に使用することができる。適切に設計された購買注文プロセス１２０は、企業の異なる領域で使用される場合に変更がほとんどまたは全く不要なはずであるので、これが可能である。再使用可能な構成要素１１０の変化に適応するために変更が必要である場合（売上税または同様の地方の法律のための変更など）、構成要素１１０を複製することができ、新たに形成された構成要素１１０に変更を施すことができる。構成要素１１０のコピーを作成するこの同じ技術を、再使用可能とみなされない構成要素１１０にも使用することができる。複製の作成においては、使用の都度構成要素１１０の新しいインスタンスが形成されるので、構成要素１１０は再使用されない。
【００３１】
動作１０４、結果１０６、および属性１０８に加えて、構成要素１１０は構成要素の名前および記述などの追加プロパティ１０９をも有する。大域プロパティおよび文脈依存プロパティの２種類のプロパティ１０９がある。大域プロパティは、構成要素１１０がどこで使用されるかに関係なく、構成要素１１０の全てのインスタンスに適用される。例えばプロセス１２０の名前および記述はどちらも大域プロパティである。その結果、名前を変更すると結果的に、そのプロセス１２０が使用される全ての場所でその名前は変更される。文脈依存プロパティは、構成要素１１０の個々の繰返しの間で異なり、したがって、再使用可能な構成要素１１０によってのみ使用される。例えば何回も使用される特定のタスク１３０は、繰返しの都度異なる優先順位を持つことができる。したがって、優先順位は文脈依存プロパティである。属性１０８もまた文脈依存プロパティである。
【００３２】
「コンテナ１１２」
図３に示す通り、２つの主要な型の構成要素１１０、すなわちコンテナ１１２および要素１６０がある。コンテナ１１２とは、他の構成要素１１０を包含することのできる型の構成要素１１０である。本発明は、プロセス１２０、タスク１３０、ルータ１４０、およびコントローラ１５０の４つのコンテナを利用する。要素１６０とは、他の構成要素１１０を含まない、プロセスモデル定義の部分である。
【００３３】
コンテナ１１２は定義上、他の構成要素１１０を包含することができるが、それらは全ての型の構成要素１１０を包含することはできない。図４の表は、各型のコンテナ１１２の有効な構成要素１１０を示す。図４に注記する通り、一部のコンテナ１１２は特定の型の被包含構成要素１１０の１つだけの存在をサポートする。例えば、各プロセス１２０は１つのタスク１３０しか包含できない。プロセス１２０は別個のタスク１３０を各々包含する複数のサブプロセス１２２を利用することができるので、この特定の限界は対処することができる。図４は、アステリスクで排他的構成要素１１０をリストすることによって、どの構成要素がコンテナ内に単独でしか発生しえないかを示す。
【００３４】
「プロセス１２０」
上記の通り、プロセス１２０は、特定のビジネス活動を一緒に達成する１つまたはそれ以上のサブプロセス１２２、タスク１３０、または他の構成要素１１０の組である。プロセス１２０および他のコンテナ１１０のデフォルト動作１０４、結果１０６、および他のプロパティ１０９を図５の図表に示す。図５の図表は、各コンテナ１１２のプロパティを大域プロパティと文脈プロパティに分割する。当該図表に示す通り、プロセス１２０の唯一のデフォルト動作１０４は開始である。本動作は明らかに、プロセス１２０が起動するする一般的動作１０４である。本動作１０４は通常、そのビジネス目的をより正確に反映するようにその名前を変更させる。一般的な第２の動作は取消し動作１０４であるかもしれない。取消し動作がトリガされると、以前に開始されたプロセスは取り消される。
【００３５】
図５はまた、プロセス１２０の単一のデフォルト結果１０６が「完了」であることをも示す。本結果１０６は明らかに、プロセスモデル１００の残部にプロセス１２０が完了したことを示す。再び、本結果１０６は通常名前を変更される。プロセス１２０からの異なる結果を示すために、複数の結果１０６を利用することができる。例えば１つの結果１０６は請求の承認を示すことができ、第２の結果１０６は請求の却下を示すことができよう。
【００３６】
プロセス１２０の大域プロパティ１０９は名前、検査状態、および記述である。該プロセス１２０は、その名前によりプロセスモデル１００の構造において識別することができる。該記述プロパティ１０９は定義されたプロセス１２０の記述を含む。各プロセス１２０は単に図形的定義手段を利用するだけで部分的に自己文書化しているが（以下参照）、プロセス１２０自体のプロパティ１０９に記述を埋め込むと、プロセス１２０はいっそうよく自己文書化される。
【００３７】
検査状態プロパティ１０９は、開発中に、プロセス１２０が現在開発者に検査されているかどうかを決定するために使用される。
【００３８】
プロセス１２０の唯一の文脈プロパティ１０９はリンクプロパティである。該リンクプロパティは、プロセス１２０の特定のインスタンスが接続された他の構成要素１１０を全部追跡する。
【００３９】
プロパティ１０９、デフォルト動作１０４およびデフォルト結果１０６に加えて、各プロセス１２０は属性１０８、カスタマイズイベント１０２、およびそのプロセス１２０を定義してそれを全ての他のプロセス１２０から区別するのに役立つ、包含されリンクされた構成要素１１０をも有する。プロセス１２０のこれらの要素を定義するステップを以下で説明する。
【００４０】
「タスク１３０」
上記の通り、各タスク１３０は特定のタスクを完了するために個人またはプログラムへの作業割当を含む。作業の単純な割当に加えて、各タスク１３０はまた、割り当てられた作業要素を実際に達成するために必要なビジネス論理およびビジネスデータを全て具現する。例えば、タスク１３０が保険請求を承認するためにエンドユーザに割り当てられる場合、タスク１３０は、ｉ）エンドユーザがその請求を承認するために必要なビジネスデータを組み込み、ｉｉ）請求を承認するために使用されるビジネス論理を提供し、ｉｉｉ）この情報をカスタマイズＧＵＩインタフェースでエンドユーザに提示する。この情報を全てインタフェースに組み込むためのプロセスは、タスクエディタの説明に関連して以下で説明する。
【００４１】
タスク１３０は、図５に示す通り、２つのデフォルト動作１０４（開始および取消）および１つのデフォルト結果１０６（完了）を含む。タスク１３０はまた、プロセス１２０と同じ３つの大域プロパティ１０９、すなわち名前、検査状態、および説明プロパティを含む。デフォルト動作１０４、結果１０６、および大域プロパティ１０９の形式および機能は、プロセス１２０の説明で上記に示した。該タスク１３０がアドホック開始プロパティ１０９を共用しないという事実は、本発明がタスク１３０をアドホックに開始できないことを示す。好適な実施形態では、タスク１３０をアドホックに開始する前にプロセス１２０に組み込む必要があるという決定が下されたが、本決定は異なるように下すことができ、これは本発明の範囲に対する限定と取るべきではない。
【００４２】
タスク１３０は３つの異なる文脈プロパティ１０９、すなわちリンク、役割および優先順位を持つ。該リンクプロパティ１０９は、それがタスク１３０の特定のインスタンスにリンクされる他の構成要素１１０を示すという点で、プロセス１２０のリンクプロパティ１０９と同じである。
【００４３】
役割プロパティ１０９は、どのユーザがタスク１３０を完了するかを示す。本発明はタスク１３０を個々のユーザにではなく、むしろ役割２７０と呼ばれるユーザのグループに割り当てる。次いでサーバは個々のユーザを１つまたはそれ以上の役割２７０に割り当てる。該役割２７０は、プロセスモデル１００における全ての予め定められた役割２７０のリストから選択される。
【００４４】
デフォルトでは、タスク１３０は役割内の全ユーザに割り当てられ、１人のユーザがタスクを完了したときに完了したとみなされる。タスクが完了する前に２人以上のユーザが該タスク１３０を終了しなければならないと指定することが可能である。また、該タスク１３０を役割内のユーザにどのように割り当てるかを管理することも可能である。例えば、タスク１３０は、順序パターンに従って１人のユーザに割り当てることができる（最初にユーザ番号１、次にユーザ番号２等々）。また、役割属性１０８の値によって（以下でより詳細に説明する）役割２７０へのタスク１３０の割当を制限することも可能である。例えば、販売員役割の場合、タスク１３０は、米国内で働く販売員だけに適用することができる。
【００４５】
複数の役割２７０に単一のタスク１３０を関連付けることができる。例えば、顧客サービス部門では、「顧客電話処理」タスク１３０は、２つの役割２７０すなわち「顧客代表」および「顧客代表管理者」に関連付けることができる。本タスク１３０を２つの役割２７０に関連付けることによって、該システムは管理者および顧客代表の両方が顧客の電話を処理することができる。
【００４６】
別のタスク配分オプションは、該プロセス１２０で前のタスク１３０を完了した者に該タスク１３０を割り当てることである。例えばビジネス規則は該請求承認タスク１３０を、請求検討タスク１３０を実行したのと同じ者が実行するように要求しているかもしれない。
【００４７】
優先順位プロパティ１０９は実行時に、所定のエンドユーザに提示される作業の優先順位を付けるために使用される。該優先順位プロパティ１０９は単に、ユーザに提示される利用可能なタスク１３０のリストを分類するためにだけ使用することができ、あるいはユーザが達成するための次のタスク１３０を自動的に選択するために使用することができる。
【００４８】
タスク１３０の優先順位は、１（低）から１０（高）までの数値に設定することができる。本割当ては静的に行なうことができ、文脈から動的に導出するか、あるいは該プロセス１２０の前タスク１３０から受け継ぐことができる。優先順位が動的に設定される場合、優先順位決定ツリーは条件文形式となるか（すなわち、もし顧客＝「ＩＢＭ」であるならば優先順位＝１０、そうでなければ優先順位＝１）、または後述する制御フローツリーと同様の決定ツリーが採用される。
【００４９】
「ルータ１４０」
ルータ１４０は、ビジネスプロセス１２０の制御フローを設計するときに使用される。ルータ１４０は制御フローを特定の条件または決定に基づいて異なる分岐に分割する。一般的に分岐は、属性１０８に格納されたビジネスデータ値に基づいて行われる。例えば、提案を検討するなどのタスク１３０の完了後、該制御フローは、タスク結果１０６の属性１０８に格納することのできる提案検討タスク１３０の結果に基づいて、３つの分岐：
提案を承認し、次のタスク１３０を開始する；
提案活動を拒絶して終了する；または
提案に意見を付けて、改訂のためにその起案者に返送する
に分割することができる。
【００５０】
図５に示す通り、ルータ１４０は単一のデフォルト動作１０４（開始）と、複数の相互に排他的な結果１０６（デフォルトでは分岐１および分岐２）とを有する。ルータ１４０のプロパティ１０９は、ルータ１４０がアドホックプロパティを持たないことを除いては、プロセス１２０の大域プロパティと同じである。
【００５１】
「コントローラ１５０」
コントローラ１５０は２つの有用な属性を有する。第一に、コントローラ１５０は他のプロジェクトで再使用可能である。第二に、コントローラ１５０は他の構成要素１１０、特にアダプタ２４０のコンテナ１１２として使用される。
【００５２】
下記で説明する通り、アダプタ２４０は、該プロセスモデル１００の外部に存在するビジネスデータへのアクセスを提供する。残念ながら、アダプタ２４０の使用はプログラミングの知識を必要とする。ビジネスデータに直接アクチュエータするためにアダプタ２４を利用しなければならないことからビジネス分析をシールドするために、プログラマはアダプタ２４０をコントローラ１４０に埋め込む。次いでビジネス分析者は、アダプタ２４０の基礎をなす技術的詳細を知ること無く、コントローラ１５０を使用してプロセスモデルを定義することができる。
【００５３】
アドホック開始プロパティ１０９の欠如以外に、コントローラ１５０は、図５に示すプロセス１２０と同じデフォルトイベント１０２およびプロパティ１０９を有する。
【００５４】
「要素１６０」
要素１６０とは、他の構成要素１１０を包含しないプロセスモデル１００の部分である。図３に示す通り、本発明の好適な実施形態は８種類の要素１６０、すなわち、ビュー１７０、結合１８０、コンパレータ１９０、タイマ２００、アサイナ２１０、動作ランチャー２２０、ノーティファイア２３０、およびアダプタ２４０を利用する。図６は、要素１６０の各々およびそれらのデフォルト動作１０４、結果１０６、および大域プロパティ０９を示す。要素１６０は再使用できないので、要素１６０に文脈プロパティ１０９は無い。これらの要素１６０を以下でさらに詳しく述べる。
【００５５】
「ビュー１７０」
各タスク１３０は、エンドユーザがタスク１３０を完了するために必要なビジネスデータ、論理、およびインタフェース要素を含む。本情報は、タスク１３０のビュー１７０によって定義されるユーザインタフェースを通してユーザに提示される。本発明は様々なオペレーティングシステム環境を通してユーザと対話するように設計されるので、該ビュー１７０はこれらの異なるプラットフォームを扱うように形成しなければならない。好適な実施形態では、サポートされるプラットフォーム環境はジャバ、ＨＴＭＬ、およびパームＯＳを含む。他の動作環境をサポートすることは充分に本発明の範囲内である。
【００５６】
これらの環境の各々に別個のインタフェースを生成する必要があるので、本発明はタスク１３０でサポートされる各環境に対して別個のビュー１７０を使用する。特定のタスク１３０内に含まれる全てのビュー１７０は集合的にビューセット１７２と呼ばれる。タスク割当を受け取る役割２７０を介してタスク１３０を完了するためにどのビュー１７０を利用するかを定義することが可能である。例えば、自分の会社で購買注文関係タスクを実行するエンドユーザは、デスクトップコンピュータでジャバ（さもなければ「スウィング」として知られる）を使用することができるのに対して、証券取引フロアの株式仲買人はワイヤレスインタフェースを有するパームコンピュータ上でパームＯＳインタフェースを使用する方を好むかもしれない。
【００５７】
各ビュー１７０は１つまたはそれ以上のパネル１７４を含み、各パネルはエンドユーザに情報画面を提示する。該パネル１７４は、テキスト、グラフィックス、データフィールド、ボタン、およびチェックボックスなど、従来のインタフェース要素を含む。本発明は、タスクエディタに関連してさらに詳しく説明する通り、そのようなパネル１７４を図形的に設計するためのツールを提供する。ＧＵＩパネルをひとつにリンクし、洗練された最新のパネル１７４を提供するために、本発明はタスクコントローラ１７６を利用する。タスクコントローラ１７６は、１つまたはそれ以上のパネル１７４に関連付けられ、パネル１７４の制御を使用可能または使用不能にし、データ検証を実行し、あるいは複数のパネル１７４間の対話を制御するなどの管理機能のために使用される。
【００５８】
「結合１８０」
結合１８０は複数のプロセス１２０またはタスク１３０を同期化し、さらなる処理を可能にする前に各プロセス１２０またはタスク１３０からの結果１０６を受け取ることを必要とする。その結果、結合１８０は、２つまたはそれ以上の並行プロセス１２０またはタスク１３０が１つスレッドの制御に集まってくるときに使用される。例えば、結合１８０は、予備ステップが全て達成された後でだけローンを承認するためのプロセス１２０を開始するために使用することができる。
【００５９】
図７は、このように使用される結合１８０を利用するモーゲージ申請を受理するためのプロセス１２０の略図を含む。本図は、構成要素１１０のアイコンが以下で説明する制御フローエディタ３４０で使用される方法と同様にアイコンを使用する。本図で、モーゲージ要求を処理するためのプロセスを開始する動作１０４は、緑ランプが点灯した停止信号灯のアイコンとして示される。本動作１０４は、３つの追加プロセス１２０を同時に開始するために使用される。すなわち、１つは申請書に記入することであり、１つは給与情報を検証することであり、１つはクレジットレポートを入手することである。これらのプロセス１２０は各々、小さいフローチャートを含むアイコンで示される。該結合要素１８０は、これらの３つのプロセス１２０の結果を集め、３つのプロセス１２０が全部完了しないうちに最後のプロセス１２０（「検討および承認」）が開始するのを防止するために使用される。ひとたびこの最後のプロセス１２０が完了すると、結果「完了」１０６が起動され、それは停止ランプが点灯したアイコンによって表わされる。
【００６０】
図６に示す通り、結合１８０は、分岐１および分岐２として予め定義された複数の入力動作１０２のみならず、完了と呼ばれる単一のデフォルト結果１０６をも有する。該結合１８０は、該完了結果１０６が起動される前に全ての動作１０４を受け取るのを待つことによって、その機能を達成する。図６に示す結合１８０の該プロパティ１０９は、図５に関して説明した同様の名前プロパティと同じである。
【００６１】
「タイマ２００」
タイマ２００は、時間の経過が発生した後、ビジネス結果１０６を生成することによって、プロセスモデル１００の流れを制御するために使用される。タイマ２００は、警告を発生し、プロセス１２０およびタスク１３０に組込み遅延を提供し、プロセス１２０およびタスク１３０の完了の期限を形成するために使用することができる。
【００６２】
タイマ２００が制御フロー内に直列に配置される場合、該タイマ２００は遅延要素として働く。設定された時間が経過するまで、流れは先に進まない。タイマー２００が制御フローと並列に配置される場合、該タイマ２００は、該プロセス１２０またはタスク１３０の実行が設定された時間を超えた場合に、通知イベントを提供するために使用することができる。タイマ２００を使用するときは、通知の必要がなくなった（すなわち時間を設定したプロセス１２０またはタスク１３０が完了した）ときにタイマ２００が解除されることを確実にするように注意を払わなければならない。
【００６３】
図８は、タイマ２００を並列に使用する略図を示す。該タイマ２００は、該プロセス１２０を完了するまでの時間が時限を超える場合に、時間満了結果１０６をトリガする。該プロセス１２０およびタイマ２００は両方とも開始動作１０４によってトリガされることに注意されたい。該プロセス１２０が完了すると、プロセス１２０は完了結果１０６をトリガし、かつタイマ２００によって取消動作１０４として処理される結果１０６を送る（図８の線２０２によって示される）ことによってタイマ２００を取り消す。
【００６４】
図６に示す通り、タイマ２００は２つのデフォルト動作１０４、すなわち開始および取消を有する。タイマ２００はまた単一の結果１０６、すなわち「完了」をも有する。開始動作１０４が生じると、タイマ２００は作動し始め、次いで定義された時間間隔が完了すると、完了結果１０６を起動する。時間の満了前に取消動作１０４を受け取ると、満了イベントの起動が防止される。
【００６５】
タイマ２００は図６に示すように５つのプロパティ１０９を有する。該リンクプロパティ１０９は、タイマ２００を接続する他の構成要素１１０を示す。該カレンダプロパティ１０９は、どのカレンダ２９０を使用して時間を追跡するかを示す。後でより詳しく説明する通り、カレンダ２９０は、「計数可能な」作業時間として何を計数するかを決定するために使用されるリソース２５０である。例えば、４時間の時間は４絶対時間を意味する、あるいは勤務時間が月曜日から金曜日まで９時から５時までである場合の４勤務時間を意味することができる。勤務時間の定義はカレンダ２９０に維持される。
【００６６】
該型プロパティ１０９は、タイマが絶対時間（東部標準時間２００３年１月１日午後４時）、相対時間（開始時間から３時間）、または導出時間（隔月の第１火曜日）のどれを利用するかを示す。プロパティ１０９はまた、適切な時間データ（選択された絶対または相対時間、または相対時間を決定するための論理）を格納するためにも存在する。本情報は絶対時間、相対時間、および導出時間プロパティに格納される。
【００６７】
「コンパレータ１９０」
コンパレータ１９０は、１組の演算子を使用して２つの値を比較し、真または偽のブール結果を生成する。コンパレータ１９０は、２つの結果だけが必要なときにプロセス１２０で直接使用することができ、あるいはより複雑な決定ツリーが必要な場合にルータ１４０内で組み合わせることができる。
【００６８】
２つのコンパレータ１９０を利用したルータ１４０の定義付けの一例が図９に示されている。本ルータは、特定の量（「Ａｍｔ１」）を２つの他の量（「Ａｍｔ２」および「Ａｍｔ３」）と比較しようとしている。Ａｍｔ１がＡｍｔ２より小さい場合、分岐１と称する結果１０６をトリガしなければならない。Ａｍｔ１がＡｍｔ２より大きいか等しいが、Ａｍｔ３より小さい場合、分岐２をトリガしなければならない。Ａｍｔ１がＡｍｔ３より大きいか等しい場合、分岐３と称する結果１０６がトリガされる。
【００６９】
数値属性の場合、コンパレータ１９０は次の標準型の比較、すなわちより小さい、より小さいか等しい、等しい、より大きい、より大きいか等しい、等しくないを使用することができる。文字列属性の場合、コンパレータ１９０は等式（同一文字列の場合は真）または不等式（異なる文字列の場合は真）を実行することができる。本発明の好適な実施形態には組み込まれないが、より小さいかまたはより大きいテキスト英字などの追加演算が当業者には明らかであり、充分に本発明の範囲内である。
【００７０】
図６に示す通り、コンパレータ１９０は単一の動作１０４、すなわち入力を有する。該入力動作１０４はコンパレータ１９０を始動し、比較すべき値をコンパレータ１９０の属性に転送する。コンパレータ１９０の３つの可能なデフォルト結果１０６は真、偽、および失敗である。最後に、コンパレータ１９０は２つの追加プロパティ、すなわちリンクおよび異オペランドを有する。リンクプロパティ１０９はこのコンパレータ１９０を接続する構成要素を示す。オペランドプロパティは、どの値に演算を行なうかを示す。これらの値は文脈データまたはハードコード化された値とすることができる。
【００７１】
「アサイナ２１０」
アサイナ２１０は、値を属性１０８に割り当てるために使用される。図６に示す通り、アサイナ２１０は単一の入力動作１０４を有する。アサイナ２１０の可能な結果１０６は完了（割当成功）または失敗（割当失敗）のいずれかである。コンパレータ１９０と同様に、アサイナ２１０はその唯一のプロパティ１０９としてリンクおよびオペランドを有する。
【００７２】
「動作ランチャー２２０」
動作ランチャー要素２２０は、プロセス１２０またはタスク１３０内で、新しいプロセス１２０またはタスク１３０を非同期開始するために使用される。起動されたプロセス１２０またはタスク１３０は、それを開始させたプロセス１２０またはタスク１３０の文脈外で開始する。これは、親プロセス１２０が完了したとみなされる前に埋め込まれたプロセス２０が完了するのを親プロセス１２０が待たなければならない場合の埋め込まれたプロセス１２０とは異なる。
【００７３】
動作ランチャー２２０の単一の動作１０４は、新しいプロセス１２０またはタスク１３０を起動させるために使用される開始動作である。動作ランチャー２２０は独立プロセス１２０またはタスク１３０を形成し、結果１０６は返されないので、図６には結果１０６はリストされていない。
【００７４】
動作ランチャー２２０の２つのプロパティ１０９は型（プロセス１２０またはタスク１３０のどちらが起動されたかを示す）、および起動された構成要素の名前を示す起動された名前である。
【００７５】
「ノーティファイア２３０」
ノーティファイア２３０は、イベントの発生の非同期メッセージをエンドユーザに提供するために使用される。ノーティファイア２３０がトリガされると、本発明のプロセスサーバ５００を介してアドレス指定されたユーザのインボックスにテキストメッセージが送られるか、または代替的にｅメールメッセージが指定されたユーザのｅメールアドレスに送られる。ノーティファイア２３０は動作ランチャー２２０の様に通常プロセス１２０またはタスク１３０の文脈外で開始するので、ノーティファイアと関連付ける理由はない。
【００７６】
ノーティファイア２３０の唯一の動作は送信であり、それはメッセージを起動して、関連属性をノーティファイア２３０に転送する。名前プロパティ１０９は、インボックスにメッセージのタイトルとして、またはｅメールの件名の行に現れる名前である。アドレスプロパティ１０９は、この通知を受け取るべき役割２７０またはｅメールアドレスのいずれかを定義することができる。
【００７７】
優先順位プロパティ１０９は、プロセスサーバインボックを通すメッセージにのみ使用され、タスク１３０でセットされた優先順位と同様にしてセットされる。メッセージプロパティ１０９はメッセージのテキスト本体である。該配布型はプロセスサーバメッセージとｅメールとを区別する。最後に、説明はノーティファイア２３０の目的および使用法のテキスト文書である。
【００７８】
「アダプタ２４０」
アダプタ２４０は、既存の企業アプリケーション、ミドルウェア、およびデータベースなど、ビジネスデータまたは論理の既存のソースにアクセスする手段を提供する。ビジネスデータにアクセスすることに加えて、アダプタ２４０は外部プログラムを開始するため、別個に定義されたビジネスプロセス１００を開始するため、またはミドルウェアイベントにアクセスするかそれを生成するために使用することができる。アダプタ２４０がビジネスデータまたはプログラミング論理自体を含まないことを認識することが重要である。むしろ、アダプタ２４０は外部ソースへのインタフェースを提供する。
【００７９】
これらの様々なタスクを達成するために、アダプタ２４０は、プロセス１２０およびタスク１３０が使用可能なフォーマットで外部データまたはコントロールをカプセル化する。プロセス１２０およびタスク１３０はアダプタ２４０を直接利用することができるが、アダプタ２４０は一般的にコントローラ１５０内に組み込まれる。これは、既存のデータまたはコントロールをカプセル化するプロセスが複雑になり得るためである。アダプタ２４０がコントローラ１５０に組み込まれるときに、これらの複雑な詳細は隠蔽され、代わりに情報は、コントローラ１５０の簡素化されたインタフェースを通して、プロセスモデル１００の設計者に提示される。
【００８０】
本発明は、アダプタ２４０の様々な予め定められたフォーマットを持つ。第１フォーマットは、新しいまたは既存のジャバクラスとインタフェースするために使用される。第２フォーマットはアダプタ２４０が、コンピュータ・ネットワーク・テクノロジーズ（ミネソタ州ミネアポリス）からのエンタープライズ／アクセス・ミドルウェアまたはアクティブ・ソフトウェア（カリフォルニア州サンタクララ）からのアクティブ・ワークス・ミドルウェアなど、既存のミドルウェア製品へのインタフェースとして働くことを可能にする。
【００８１】
アダプタ２４０のフォーマットに関係なく、外部ソースへのアダプタ２４０の特定のインタフェースは、本発明のアダプタエディタで指定する。このインタフェースを定義することに加えて、アダプタエディタはアダプタ２４０の標準動作１０４および結果１０６を定義する。アダプタエディタは、異なるビジネスデータおよび論理を統合するのにも役立つ先行技術のミドルウェア製品に使用されるインタフェースと同様に機能する。
【００８２】
「ＤＢ構成要素２４２」
ＤＢ構成要素２４２は、ＤＢ構成要素２４２が産業標準データベース管理システム用のインタフェースを提供することを除いては、アダプタとよく似ている。例えばＤＢ構成要素２４２は、データにアクセスしてデータを変更するためにＳＱＬの使用をサポートするどんな数のデータベースにも照会を可能にするＳＱＬインタフェースを提供することができる。
【００８３】
「ＢＥファクトリ２４４」
後述する通り、ビジネスエンティティ２６０は論理的に構成された情報グループである。ＢＥファクトリ２４４は、タスク１３０の実行中にタスク１３０にビジネスエンティティ２６０を生成させる要素１６０である。例えば、タスク１３０はユーザが新しい請求に入ることができるように定義することができる。請求は、単一のビジネスエンティティ２６０にグループ化された複数の情報を備える。本タスク１３０のユーザインタフェースは、ユーザが新しい請求を形成するために選択するボタンを含めることができる。本ボタンは、請求ビジネスエンティティ２６０の新しいインスタンスを形成するＢＥファクトリ２４４に関連付けられる。
【００８４】
「ロッカ２４６」
ロッカ２４６は、ビジネスエンティティ２６０でデータをキーとして使用して、プロセス１２０をロックまたはアンロックするために使用される。例えば通信販売プロセス１２０は、顧客に請求書を送付するタスク１３０が完了した後、顧客注文ビジネスエンティティ２６０をキーとして使用して、それ自体をロックすることができる。通信販売プロセス１２０と並行して、顧客によって出された注文の支払を受領する支払受領プロセス１２０を実行することができる。該支払受領プロセス１２０は、同じ顧客注文ビジネスエンティティ２６０をキーとして使用して、通信販売プロセス１２０をアンロックすることができる。ひとたびアンロックされると、次いで通信販売プロセス１２０は実行を再開し、次いでその制御フローにおける次のタスクである注文出荷タスク１３０を実行するであろう。
【００８５】
「リソース２５０」
リソース２５０は、プロセスモデル１００を定義するために使用される別の型のビルディングブロックである。特にリソース２５０は、プロセスモデル１００で使用される基本的ビジネスデータを定義する。言い換えると、該リソース２５０は、ビジネス情報を格納するために使用されるデータ構造およびこれらの構造のインスタンスを構成する。例えば、イベント１０２、構成要素１１０、または要素１６０の属性１０８を最初に定義する場合、属性を特定の型のリソース２５０に関連付ける必要がある。本発明では、リソース２５０はビジネスエンティティ２６０、役割２７０、ユーザ２８０、カレンダ２９０、決定基準２９２、およびデータコントローラ２９４を含む。
【００８６】
「ビジネスエンティティ２６０」
ビジネスエンティティ２６０は、ビジネスで使用されるエンティティを表わす、論理的に集められた情報片である。ビジネスエンティティ２６０の構造は、プロセスモデル１００の設計者に有用なほとんどどんな型のものでもよい。一般的に、該ビジネスエンティティ２６０は１つまたはそれ以上の属性（データ構造のデータフィールド）１０８を作成することによって定義され、各属性１０８は標準的な予め定義された可変型（テキスト／文字列、整数、ｌｏｎｇ等のような）または別のビジネスエンティティ２６０のいずれかである。例えば、ビジネスエンティティ２６０は、町アドレス、市、州、郵便番号のための別個の属性１０８（すなわちテキストフィールド）から構成された住所に対して形成することができる。住所ビジネスエンティティ２６０が今度は、「顧客」と称する異なるビジネスエンティティ２６０の属性１０８となることができる。これは、ビジネスエンティティ２６０が有用なフォーマットでビジネス情報を捕獲するレコード構造を表わすことを可能にする。
【００８７】
「役割２７０」
役割２７０は、企業のジョブ機能を捕捉するために予め定義されたリソース２５０である。実際には、役割２７０は予め定義されたビジネスエンティティ２６０であり、役割名など特定の必須属性１０８を持つ。役割２７０の使用法は、タスク１３０の割当の説明で上述した。タスク１３０を個々のユーザ２８０の代わりに役割２７０に割り当てることによって、本発明は、タスク１３０の完成におけるいっそうの柔軟性を可能にする。これは、高い従業員の転職率および頻繁な仕事の割当変更を抱えた今日の急速に変化するビジネス環境では特に有用である。
【００８８】
役割２７０は充分に柔軟であり、プロセスモデル１００の設計者が追加属性１０８を各役割に付け加えることが可能である。例えば、「販売員」の役割２７０は地域、テリトリ、割当等の属性を持つことができる。役割属性の値は、配備中にまたは実行時に割り当てることができる。
【００８９】
「ユーザ２８０」
役割２７０と同様に、ユーザ２８０は、特定の必須属性１０８を持つ予め定義されたビジネスエンティティ２６０である。該ユーザ２８０リソースは、タスク１３０を実行し、ビジネスモデル１００を定義し、あるいはその他の方法で本発明と対話する実際の人間のユーザを表わす。タスク１３０を実行するユーザ２８０に複数の役割２７０を割り当てることができる。本発明におけるユーザ２８０の定義は、名前、ユーザＩＤ、パスワード、監督者、およびユーザ２８０が割り当てられる役割２７０の必須属性を含む。各ユーザ２８０はまた、男性従業員または株式所有プランに参加している従業員を定義するグループ２８２など、複数のユーザグループ２８２に割り当てることもできる。ユーザ２８０はこれらの属性を予め定義されているが、各企業はそのビジネスに適した、より多くのユーザレベル属性を追加することができる。
【００９０】
「カレンダ２９０」
カレンダ２９０は別の型の予め定義されたビジネスエンティティ２６０である。タイマ２００に関連して上記の通り、カレンダ２９０は、時間の予め定義された設定を定義するための手段を提供する。大半の企業では、労働時間、実時間、残業時間等、様々なカレンダを使用して時間を追跡する必要がある。該カレンダ２９０リソースは、そのような時間を特定の企業の慣行に従って予め定義することができる。例えば、労働時間カレンダ２９０は、標準労働時間を含み、週末および休日を除外するように定義することができる。次いで労働時間カレンダ２９０は、全ての注文が受注から３営業日で出荷されることを確実にするように設計されたタイマ２００に関連して、時間の経過を追跡するために使用することができる。
【００９１】
「決定基準２９２」
決定基準２９２は、特定の値を表わすために使用される特殊ビジネスエンティティ２６０である。決定基準２９２は単なるビジネスエンティティ２６０であるので、決定基準はビジネスエンティティ２６０データが使用されるどんな場所でも使用することができる。
【００９２】
決定基準２９２の例は、それ以上は払戻しまたは請求について上司の承認を必要とする特定のドル制限を含む。そのようなドル制限は企業全体で、または部門毎、もしくは地理的領域毎に指定することができる。このドル制限を表わすためにビジネスエンティティ２６０よりむしろ決定基準２９２を使用する選択は、制限が安定しており、かつ典型的なビジネスエンティティ２６０のように実行中に変化しないので行われる。決定基準２９２は、後日値を変更することが必要になるかもしれず、またハードコード化された値の全てのインスタンスを位置決めするより、決定基準２９２を変更する方が容易であるため、プロセスモデル１００内に値をハードコード化する代わりに使用される。
【００９３】
決定基準２９２の別の適切な使用法は、現在のビジネス条件に応じて異なるプロセスモデル１００に切り換えるために使用されるフラッグであろう。そのようなフラッグを使用することによって、ビジネスのプロセスフローは、実行中に単にフラッグを変更するだけで、定義された制御フローを定義変更することなく、変えることができる。
【００９４】
「データコントローラ２９４」
該データコントローラ２９４は特殊型のリソース２５０であり、単なる特殊型のビジネスエンティティ２６０ではない。むしろ、データコントローラ２９４は、ビジネスエンティティ２６０における全てのデータだけでなく、データコントローラ２９４がその中にあるタスク１３０の属性１０８およびプロパティ１０９も含めて、プロセスモデル１００に利用可能な完全な組のビジネスデータを表わすオブジェクトである。タスクエディタ３８０に関連して後述するように、タスク１３０の定義付けを容易にするのを助けるために、このデータは全てデータコントローラ２９４内の一か所に集められる。
【００９５】
「ソフトウェアツール」
図１０に示すように、本発明はプロセスモデル１００を作成して実現するために、３つのソフトウェアツールすなわちプロセスデザイナ３００、プロセスサーバ５００、およびプロセスクライアント６００を使用する。該プロセスデザイナ３００は、該プロセスモデル１００を実際に定義するソフトウェアツールである。プロセスデザイナ３００は、ビジネス分析者、設計者、または開発者３０２と呼ばれるユーザ２８０が彼らの企業のプロセスモデル１００を定義することを可能にする。これを行なうために、該プロセスデザイナ３００は開発者にＧＵＩインスタンスを与えて構成部品１１０およびリソース２５０の開発を支援し、かつ構成要素１１０間のプロセスおよびデータフローの定義付けを可能にする。アダプタ２４０の作成を除き、これは全て、従来のプログラミングを行なう必要無く、プロセスデザイナ３００のグラフィカルインスタンスを通して達成することができる。
【００９６】
完了後、企業のプロセスモデル１００は次いで、本発明のワークフローエンジンとして役立つプロセスサーバ５００に配備される。該プロセスサーバ５００はプロセスモデル１００にあるプロシージャを実行し、タスク１３０を適切な役割２７０に提示する。該プロセスサーバ５００は、個々のタスク１３０の優先順位プロパティ１０９を通して、タスク１３０の割当を調整する。該プロセスサーバ５００はまた管理インスタンスをも提供して、管理者５０２として知られるユーザ２８０にビジネスプロセス１２０に対する制御を付与する。管理者５０２はプロセスサーバ５００に直接ログオンして、企業の毎日の業務に対する洞察を得る。タスク１３０の優先順位付けおよび割当は必要に応じて監視し調整することができ、量または遅延しきい値を超えると警報が発生する。
【００９７】
該プロセスクライアント６００は、エンドユーザ６０２がプロセスサーバ５００にログオンして接続し、彼らに割り当てられたタスク１３０にアクセスし、それらの優先順位に従ってタスク１３０を実行することを可能にする、ＧＵＩに基づくアプリケーションである。該エンドユーザ６０２は、該タスク１３０用に設計されたビュー１７０を通して必要な情報およびリソースに自動的にアクセスを得る。
【００９８】
「プロセスデザイナ３００」
「リポジトリ３１０」
該プロセスデザイナ３００は、プロセスモデル１００の定義付けが達成される場所である。該プロセスデザイナ３００は、プロセスモデル１００を構成するオブジェクトをデータベースまたはリポジトリ３１０と呼ばれるオブジェクトに格納することによって、複数の設計者３０２が共同して作業することを可能にする。図１１に示す通り、リポジトリ３１０自体がリポジトリオブジェクト３１２を含む。該リポジトリオブジェクト３１２は現在定義されている構成要素１１０と、厳密にではなく、大まかに１対１で対応する。これは、リポジトリが、再使用できるオブジェクト３１２、すなわちプロセス１２０、タスク１３０、およびコントローラ１５０、ならびにアダプタ２４０だけを含むからである。再使用できないコンテナ１１２（すなわちルータ１４０）およびアダプタ２４０以外の要素１６０は、他のリポジトリオブジェクト３１２内に埋め込まれるオブジェクトとしてのみ、リポジトリ３１０に存在する。
【００９９】
該リポジトリ３１０は１つまたはそれ以上のプロジェクト３１４に編成される。該プロジェクト３１４の目的は、プロセスモデル１００を形成するジョブを、各々が予め定められた期限付きで限定された目標に取り組む限定された設計者３０２の組を持つ、別個のより管理しやすい仕事に分割することである。複数の設計者３０２が同じプロジェクト３１４で同時に作業することができる。リポジトリオブジェクト３１２は、それらが修正されるときには１人の設計者３０２にチェックアウトされる。同一プロジェクト３１２で作業する他の設計者３０２は、オブジェクト３１２がチェックインされて戻されるまで修正を見ない。設計者３０２が別の設計者３０２によってチェックアウトされたオブジェクト３１２を修正しようとすると、該オブジェクト３１２はすでに使用中であることが彼らに通知され、どの設計者３０２がオブジェクト３１２をチェックアウトしたかについて通知される。
【０１００】
オブジェクト３１２がチェックインされて戻されると、新しいバージョンのオブジェクト３１２が形成される。その新しいバージョンはその後、そのプロジェクト３１４のオブジェクト３１２の唯一のバージョンとなる。同じオブジェクト３１２を利用する他のプロジェクト３１４はこの新しいバージョンを利用せず、代わりに、使用されていたオブジェクト３１２の同じバージョンを使用し続ける。このようにして、各プロジェクト３１４は、リポジトリ３１０のオブジェクト３１２にそれ自体のバージョン依存ビューを持つ。異なるプロジェクト３１４で改訂されたオブジェクト３１２のバージョンが現行プロジェクト３１４で所望される場合、そのバージョンを現行プロジェクト３１４にインポートすることができる。
【０１０１】
プロジェクト３１４は次の属性すなわち名前、クリエータ、説明、期限、設計者、および割当を含む。名前、クリエータ、および説明属性１０８は、プロジェクト３１４の名前、クリエータ、および説明をそれぞれ記録する。該期限属性１０８は、プロジェクト３１４の完了の実世界期限を記録する。該設計者属性１０８は、このプロジェクト３１４で作業する実際の設計者３０２を指定する。プロジェクト３１４内のバージョン付きオブジェクト３１２へのアクセスは通常、プロジェクトに割り当てられた設計者３０２に限られる。該割当属性１０８は、プロジェクト３１４を構成するバージョン付きオブジェクト３１２を特定の設計者３０２に割り当てる。該割当属性１０８はまた、割り当てられたオブジェクト３１２が完了しなければならない期限、およびオブジェクト３１２が実際に完了したかどうかをも追跡する。
【０１０２】
割当を追跡することによって、図１２に示すようなプロジェクト管理インスタンス３１８を形成することが可能である。このプロジェクト管理インスタンス３１８を使用して、プロジェクト内の全てのオブジェクト３１２、オブジェクト３１２を割り当てられた設計者３０２、ならびにオブジェクト３１２の期限日および完成状態を、１つのスクリーン上で追跡することが可能である。
【０１０３】
「ユーザインタフェース３２０」
図１３は、プロセスデザイナ３００のユーザインタフェース３２０を示す。該インタフェースの最上部に、編集されるプロジェクト３１４の名前を含むＩＤバナー３２２がある。ＩＤバナーの下にはメニューバー３２４およびツールバー３２６がある。これらのバー３２４、３２６は標準インタフェース設計であり、設計者３０２がプロセスデザイナ３００のプログラムコマンドにアクセスするために使用される。プログラムコマンドはまた、同じく先行技術で標準であるポップアップメニューおよびホットキーを通してアクセスすることもできる。
【０１０４】
ユーザインタフェース３２０はまた３つのパネルすなわち選択パネル３２８、エディタパネル３３０、およびプロパティパネル３３２をも含む。これらのパネルは、関心のあるパネルにリアルエステートを与えるためにサイズ変更することができる。該選択パネル３２８は、本プロジェクト３１４で利用可能な全てのリポジトリオブジェクト３１２を、オブジェクト型別に編成してリストする。該選択パネル３２８のビジュアルインジケータは、リストされたオブジェクト３１２がチェックアウトされたか、変更されたか、プロセスデザイナ３００がオブジェクト３１２を編集することができるかどうかを示す。該エディタパネル３３０は、構成要素１１０が設計される場所である。該エディタパネル３３０の外観および操作は、現在編集されているオブジェクトによって異なる。該プロパティパネル３３０は、エディタパネル３３０で選択されたオブジェクト３１２のプロパティ１０９を表示し、その編集を可能にする。タブパネルは、各オブジェクト型のために様々な型のプロパティ１０９を編成するために使用することができる。
【０１０５】
「制御フローエディタ３４０」
該ユーザインタフェース３２０を介してプロセス１２０、ルータ１４０、またはコントローラ１５０を編集する場合、該エディタパネル３３０は図１４に示す制御フローエディタ３４０を含む。制御フローエディタ３４０の主たる目的は、制御フローを編集し、データマッピングを達成し、様々な構成要素１１０のプロパティ１０９を調整することである。
【０１０６】
「エディタ要素」
該制御フローエディタ３４０を使用しながら、該設計者３０２は選択パネル３２８からリポジトリオブジェクト３１２を選択し、個々の構成要素１１０を編集するためにそれにズームインもしくはズームアウトすることができる。構成要素１１０は、構成要素１１０を表わすアイコンをダブルクリックするなど、様々な方法でズームインすることができる。該設計者３０２が構成要素１１０にズームインするときに、選択パネル３２８は変わらない。代わりに、選択パネル３２８上の選択されたリポジトリオブジェクト３１２とエディタスタック３３４の組合せが、エディタパネル３３０に表示されている構成要素１１０を一意に識別する。該選択パネル３２８から直接新しい選択が行なわれると、スタック３３４の文脈がリセットされる。該スタック３３４は選択パネル３２８と同じものを示すので、図１４が請求処理プロセス１２０の定義付けを示すことが明らかである。エディタスタックに「＜＜請求処理＜＜請求検討」と示された場合、これは、請求検討サブプロセス１２２が請求処理プロセス１２０からズームインされた後で編集されていることを示す。
【０１０７】
該制御フローエディタ３４０は、定義されているプロセス１２０を構成する複数の構成要素１１０を表わすアイコン３４２を含む。該アイコン３４２はプロセス１２０を構成する構成要素１１０だけでなく、該プロセス１２０自体のイベント１０２をも表わすことに注意することが重要である。したがって、図１４は単一動作１０４（「進め」の交通信号灯を示す）、２つの結果１０６（「停止」交通信号灯を示す）、およびサブプロセス１２２（小さいフローチャートを示す）のアイコン３４２を示す。アイコン３４２間の矢印３４４は、プロセス１２０の制御フローを示す。該エディタパネル３３０に示されるアイコン３４２は設計者３０２に認識可能かつ理解可能であることが好ましいが、好適な実施形態で使用する実際のアイコン３４２は、本発明の重大な部分ではない。アイコン３４２の変形例は充分に本発明の範囲内である。
【０１０８】
「コマンド」
制御フローエディタ３４０内で実行できる操作の幾つかを、次の表１に示す。
【０１０９】
【表１】
2005502928.tif 000003
【０１１０】
プロセス１２０を定義するために、設計者３０２は最初に該プロセス１２０の構成要素１１０の一部または全部を形成する。新しい構成要素１１０は、メニューバー３２４、ツールバー３２６、またはポップアップメニューから所望の構成要素の型を形成するコマンドを選択することによって形成される。図４に示した構成要素階層によって許可された構成要素１１０だけを形成することができる。各構成要素１１０が形成されると、該構成要素１１０を表わすアイコン３４２がエディタパネル３３０に示される。該選択パネル３２８にリストされたリポジトリオブジェクト３１２から構成要素１１０を選択することによって、選択されたプロセス１２０の定義に、事前に存在している再使用可能な構成要素１１０を追加することもできる。
【０１１１】
図１４の請求書処理システム１２０が最初に作成されたときに、制御フローエディタ３４０はデフォルト動作１０４「開始」およびデフォルト結果１０６「完了」を示した。示された該プロセス１２０を形成するために、該設計者３０２は第２結果１０６を追加し、該動作１０４および結果１０６をそれぞれ「請求データ受領」、「請求承認」および「請求拒絶」に名前変更した。該設計者３０２は次いで新しいサブプロセス１２２を形成し、それを「請求検討」と命名した。該設計者３０２はまた、図４のプロパティパネル３３２を精査することによって分かるように、請求処理プロセス１２０の「決定基準」、「顧客」、および「請求」属性１０８を定義した。これは、単に「属性定義」コマンドを実行することにより達成される。該決定基準属性１０８は決定基準２９２リソースであり、顧客および請求属性は定義されたビジネスエンティティ２６０である。該顧客ビジネスエンティティ２６０はデータフィールド、ならびに名前、顧客ＩＤ、住所、および電話番号など他の予め定義されたビジネスエンティティ２６０から形成される。同様に、「請求」ビジネスエンティティ２６０は、請求の理由、請求金額、および請求が承認されたかそれとも拒絶されたかを記述するフィールドを含むことができる。
【０１１２】
請求検討サブプロセス１２２を、サブプロセス１２２にズームインすることなく選択すると、該サブプロセス１２２はハイライトされ、次いで、図１５に示すように、請求検討サブプロセス１２２の属性１０８、動作１０４、および結果１０６がプロパティパネル３３２に示される。この方法で、スタック３３４の文脈を変えることなく、構成要素１１０の属性１０８およびイベント１０２を見ることができる。この図に示す通り、請求検討サブプロセス１２２は３つの属性１０８（「顧客ＩＤ」、「請求の理由」、「請求金額」）、単一の動作１０４（「請求受付」）、および２つの結果１０６（「承認」または「拒絶」）を有する。図１５には示されていないが、請求検討サブプロセス１２２は、請求を拒絶すべきか承認すべきかをエンドユーザ６０２に決定させるタスク１３０を含む可能性がある。
【０１１３】
「制御フローの結線」
請求処理プロセス１２０のために制御フローは、制御フローエディタ３４０Ａ上のアイコンを「線で結び」合わせることによって形成される。結線の一部として、本発明は結果１０６を動作１０４とリンクし、包囲するコンテナ１１２から包囲された構成要素１１０にデータをマッピングし、データマッピングを可能にするために必要な属性１０８を形成する。これらのステップが図１６のフローチャート３５０に示されている。
【０１１４】
フローチャート３５０の第１ステップ３５２は、単に１つのアイコン（ソース要素）から別のアイコン（ターゲット要素）までカーソルをドラッグすることであり、これにより制御フローエディタ３４０のソースからターゲットアイコン３４２まで矢印３４４が引かれる。本矢印３４４は、ソース要素の結果１０６からターゲット要素の動作１０４へのリンクを表わす。ソース要素は複数の結果１０６を持つことがあり、ターゲット要素は複数の動作１０４を持つことがあるので、このリンクで利用するイベント１０２を設計者に選択させることが重要である。これはステップ３５４で、可能なイベント１０２を選択のためにユーザに提示するポップアップウィンドウを通して行われる。そのようなウィンドウ３４６の一例が図１７に示されている。この場合、本ウィンドウ３４６は、請求検討サブプロセス１２２（２つの結果１０６すなわち承認および拒絶を有する）と請求処理プロセス１２０の請求承認結果１０６との間のリンクを示す。設計者３０２がこのウィンドウで適切なイベント１０２を選択した後、アイコン３４２間の矢印３４４に、ソース要素の選択された結果１０６がラベル表示される。通常、ターゲット要素の選択された動作１０４も制御フローエディタ３４０上で識別される。
【０１１５】
制御フローエディタ３４０のグラフィカルインタフェースでは非常に多くの情報が伝達されるので、アイコン３４２および矢印３４４を精査することによって、請求処理プロセス１２０の制御フローに関して多くのことを学習することができる。例えば、図１４で、定義されるプロセス１２０が１つの動作１０４および２つの結果１０６を持つことが明らかである。該動作１０４は「請求データ受付」と命名され、請求検討サブプロセス１２２をトリガする。このサブプロセスからは２つの可能な結果１０６、すなわち「承認」または「拒絶」がある。承認結果１０６を受け取った場合には、請求処理プロセス１２０の「請求承認」結果がトリガされる。サブプロセス１２２から拒絶結果１０６を受け取った場合には、「請求拒絶」結果１０６がトリガされる。
【０１１６】
請求データ受付動作１０４が請求検討サブプロセス１２２の動作１０４にリンクされることは妙だと思われるかもしれない。リンクは通常、２つの動作１０４の間ではなく、結果１０６と動作１０４の間で行われる。この謎に対する答えは、定義される構成要素のイベント１０２が制御フローエディタ３４０で処理される仕方にある。動作１０４および結果１０６は技術的に請求処理プロセス１２０の構成要素ではないが、制御フローの結線およびデータマッピングの目的では、それらは制御フローエディタ３４０でそのように取り扱われる。例えば、請求データ受付動作１０４は、それがあたかも単一イベント１０２すなわち「請求データ受付」と命名された結果１０６を有する包含された構成要素１１０であるかのように取り扱われる。動作１０４が１つだけの結果１０６を持つ構成要素として取り扱われることは珍しいと思われるが、請求データ受付動作１０４の「結果」が請求検討サブプロセス１２２の請求受付動作１０４とリンクするために必要である。同様に、請求承認結果１０６および請求拒絶結果１０６は、各々唯一の単一イベント１０２、すなわち同じ名前を持つ動作１０４を持つ包含された構成要素１１０として取り扱われる。
【０１１７】
「データマッピング」
データマッピングは、図１６に記載した手順の最後のステップ３５６であり、その後、手順はステップ３５８で終了する。データマッピングは、包含された構成要素１１０の属性１０８の、構成要素１１０が含まれているコンテナ１１２の属性１０８への割当と定義される。図１５に示す通り、請求検討サブプロセス１２２は請求処理プロセス１２０に包含される。したがって、その例では、請求検討サブプロセス１２２の属性１０８を請求書処理プロセス１２０の属性１０８（すなわち図１４に示した「決定基準」、「顧客」、および「請求」）にマップすることによって達成することができる。
【０１１８】
一般的に、このマッピングは、図１５に示した請求検討サブプロセス１２２の「顧客ＩＤ」属性１０８など、包含された構成要素１１０の動作の１つでダブルクリックするだけで行われる。これにより、図１８に示すようなデータマッピングウィンドウ３４７が開く。ウィンドウ３４７の左側３４８は、請求検討サブプロセス１２２の「顧客ＩＤ」属性１０８など、現在マッピング中の属性１０８を識別する。図１８には示されていないが、ドロップダウンメニューまたは他のユーザインタフェース装置を使用するなど、左側３４８に示されている構成要素１１０（現在マッピングされている構成要素１１０）の全ての属性１０８からユーザに選択させることが可能であろう。
【０１１９】
右側３４９は、マッピング中の構成要素１１０を包含するコンテナ１１２、すなわち請求処理プロセス１２０の属性をリストする。この例で、請求書処理プロセス１２０の３つの属性１０８は、決定基準、顧客、および請求属性１０８である。該顧客属性１０８は、名前、顧客ＩＤ、家の住所、会社の住所、および会社の電話番号から形成される定義されたビジネスエンティティ２６０構成である。右側３４９から属性１０８を選択し、ＯＫボタンを押すと、構成要素１１０の属性１０８と構成要素１１０を包含するコンテナ１１２との間でデータがマップされる。図１８で、請求検討サブプロセス１２２の顧客ＩＤ属性１０８は、請求処理プロセス１２０の顧客属性１０８の顧客ＩＤフィールドにマップされる。
【０１２０】
言うまでもなく、依然として本発明の範囲内で、他の方法およびユーザインタフェースを使用して、構成要素１１０とそれらを包含するコンテナ１１２との間で属性１０８のマッピングを完了することができる。例えば、構成１１０の属性とコンテナ１１２を直接関連付けるのではなく、属性１０８をイベント１０２に割り当てることが可能である。この場合、第１構成要素１１０の属性１０８を、第１構成要素１１０を第２構成要素１１０にリンクするイベント１０２の属性１０８に割り当てることによって、第１構成要素１１０の属性１０８を第２構成要素１１０に受け渡すことができる。データマッピングおよび制御フローは両方ともイベント１０２の使用により排他的に発生するので、おそらくは、イベント１０２の属性１０８を通して構成要素の属性１０８を受け渡すことは理論的にはよりきれいな方法である。しかし、実際には、エンドユーザは構成要素１１０の属性１０８をそのコンテナ１１２の属性１０８に直接割り当てる、より簡単な方法を好む傾向がある。
【０１２１】
「タスクエディタ３８０」
タスク１３０を編集するときに、該エディタパネル３３０は図１９に示すようにタスクエディタモード３８０に入る。タスク１３０は、該選択パネル３２８からタスク１３０を選択することによって、または制御フローエディタモード３４０でタスク１３０にズームすることによって編集される。タスク１３０の定義付けはユーザインタフェースの定義付けおよび外部ビジネスデータおよび論理の使用を往々必要とするので、タスク１３０の編集はプロセス１２０の編集より複雑である。したがって、該タスクエディタ３８０は設計者３０２に、プログラミング無しでユーザインタフェースを図形的に形成する手段を提供する。該タスクエディタ３８０はまた、アダプタ２４０およびコントローラ１５０の使用を通して、ユーザインタフェース構成要素とデータリソース２５０を接続し、追加ビジネス論理または外部システムとの統合を組み込む。
【０１２２】
該タスクエディタ３８０はエディタスタック３８２、ビュー選択インタフェース３８４、パネル構成要素選択領域３８６、パネル設計領域３９０、およびオブジェクトウェル３９２を含む。タスクエディタ３８０のエディタスタック３８２は、制御フローエディタ３４０のエディタスタック３３４と同じように機能する。該ビュー選択インタフェース３８４は現在編集しているビュー１７０を設計者３０２に選択させる。上記の通り、各タスク１３０はそのタスク１３０のための全てのビュー１７０を含むビューセット１７２を持ち、各ビュー１７０は単一の動作環境でのみ作動し、１つまたはそれ以上のパネル１７４から構成される。該タスクエディタ３８０のパネル構成要素選択領域３８６は、個々のＧＵＩ構成要素３８８（テキストフィールド、ラジオボタン、チェックボックス等）を現行パネル１７４用に選択することを可能にする。図１９では、スウィング（またはジャバ）構成要素３８８だけが表示され、現行ビュー１７０がジャバで作動していることを示す。該パネル設計領域３９０は、設計者３０２は構成要素選択領域３８６で選択した構成要素３８８を、エンドユーザ６０２用のパネル１７４に結合する場所である。
【０１２３】
オブジェクトウェル３９２はデータコントローラ２９４を含む。上記の通り、データコントローラ２９４は、パネル構成要素とのデータ結線に利用可能な全てのデータを提示する。特に、データコントローラ２９４は、定義されるタスク１３０の属性１０８のみならず、アダプタ２４０およびコントローラ１５０を通してアクセスされる大域データをも含む。該データコントローラ２９４に加えて、該オブジェクトウェル３９２は、そのタスク１３０に定義された全ての動作１０４および結果１０６のみならず、そのタスク１３０に定義されたパネル１７４、タスクコントローラ１７６、コントローラ１５０、ノーティファイア２３０、およびアダプタ２４０を含む。
【０１２４】
ある意味で、タスク１３０を定義するプロセスは、プロセス１２０を定義することに似ている。該タスク１３０は、それを包含するプロセス１２０内で、制御フローエディタ３４０を通して作成することができる。制御フローエディタ内で該タスク１３０を、それに「ズームイン」することなく選択することによって、該タスク１３０の動作１０４、結果１０６、および属性１０８を、制御フローエディタ３４０のプロパティパネル３３２内で定義することができる。該タスク１３０はまた、上記の通りプロセス１２０内の他の構成要素１１０とリンクすることもできる。該プロセス１２０の属性１０８からタスクイベント１０２の属性１０８へデータをマップすることもできる。
【０１２５】
タスク１３０を制御フローエディタ３４０からズームインするか、あるいは選択パネル３２８から選択すると、該タスクエディタ３８０が起動する。次いでタスクエディタ３８０を使用してビュー１７０を作成し、ビュー１７０用のパネル１７４およびタスクコントローラ１７６を設計し、パネル構成要素３８８を実ビジネスデータおよびタスクイベント１０２とリンクするために必要なデータ結線を実行する。該プロパティパネル３３２は、タスク１３０自体のプロパティ１０９だけでなく、構成要素３８８、パネル１７４、またはビュー１７０など、タスク１３０を定義するために使用されるオブジェクトのプロパティ１０９にも値を割り当てるために使用される。
【０１２６】
タスク１３０のためのビュー１７０およびそのパネル１７４を作成するためのプロセスが、図２０のフローチャート４００に示されている。新しいビュー１７０を形成するには、設計者３０２は単に、新しいビュー１７０を形成するためのコマンドを選択するだけであり、それは設計者３０２にこのビュー１７０のためのオペレーティングシステムを選択するように要求する（ステップ４０２）。次いで該設計者３０２は、ステップ４０４に示すように「新パネル」コマンドを選択することによるなど、本ビュー１７０のための新しいパネル１７４を形成する。該パネル１７４が作成されると、それはそのビュー１７０のためのオブジェクトウェル３９２に追加される。
【０１２７】
該パネル１７４を編集するには、オブジェクトウェル３９２から該パネル１７４を選択する（ステップ４０６）。次いで該設計者３０２は、パネル構成要素選択領域３８６からパネル構成要素３８８を選択し、構成要素をパネル設計領域３９０に図形的に配設する。様々なパネル構成要素３８８の属性１０８は、構成要素３８８を選択し、プロパティパネル３３２に表示される属性を変更することによって定義される（ステップ４０８）。
【０１２８】
これらの構成要素３８８がエンドユーザ６０２との会話に適したパネル１７４に配設された後、データ関連構成要素３８８を本発明のリソース２５０に関連付ける（または「結線する」）必要がある。このデータ結線はステップ４１０で、オブジェクトウェル３９２からデータコントローラ２９４を選択し、配線するデータ構成要素３８８までカーソルをドラッグすることによって達成される。該データ構成要素３８８をいずれかの属性１０８に、またはデータコントローラ２９４で定義された外部データに関連付けることを可能にするウィンドウが開く。結線すると、該データ構成要素３８８はデータコントローラ２９４内のデータに直接関連付けられ、エンドユーザ６０２による外部データの表示および更新が可能になる。該データコントローラ２９４が形成されたのは、パネル構成要素３８８のこの型の結線を容易にするためである。
【０１２９】
データ構成要素３８８が結線された後、「提出」または「ＯＫ」ボタンが押されたときに特定の結果１０６を実行するなど、パネル７４上で制御指向構成要素３８８に意味を与えることがまだ必要である。また、該動作１０４の発生時に特定のパネル１７４が開き、エンドユーザ６０２に表示されるように、該動作１０４をパネル１７４にリンクすることも必要である。これらの要件はステップ４１２で達成される。該オブジェクトウェル３９２は現行タスクの動作１０４のみならず、現行ビューのパネル１７４も示すので、動作１０４をパネルにリンクする行為は簡単である。必要なことは、動作１０４でクリックし、所望のスタートアップパネル１７４にカーソルをドラッグするだけである。ひとたびこれが行われると、ウィンドウが開き、該設計者３０２は動作１０４がパネル１７４を表示させるか隠蔽させるかを選択することができる。ボタンまたは他のパネル構成要素３８８を結果１０６にリンクするには、該設計者３０２はパネル設計領域３９０で構成要素３８８を選択し、所望の結果１０６にカーソルをドラッグするだけである。次いでポップアップウィンドウが、構成要素３８８と結果１０６との間の所望のリンクを確認する。
【０１３０】
また、制御指向構成要素３８８にビジネスエンティティ２６０の新しいインスタンスを作成させることも必要であるかもしれない。そうするために、ＢＥファクトリと呼ばれるオブジェクトがオブジェクトウェル３９２に作成され、ビジネスエンティティ２６０と関連付けられる。次いでＢＥファクトリは制御構成要素３８８に結線されるので、エンドユーザが制御構成要素３８８を（パネル１７４上のボタン構成要素３８８を押すなどによって）選択すると、ビジネスエンティティ２６０の新しいインスタンスが形成される。
【０１３１】
設計者３０２がビューで複数のパネル１７４を使用したい場合、ステップ４１４は制御をステップ４０４に返して、追加パネルを追加する。それ以上パネル１７４を希望しない場合、該ユーザはタスクコントローラ１７６を作成する選択肢を付与される。タスクコントローラ１７６は、特定のビュー１７０のために作成された様々なパネル１７４を調整するのを助けるために使用されるオブジェクトである。タスクコントローラ１７６を作成するには、該設計者３０２はステップ４１６で新しいタスクコントローラ１７６を作成するコマンドを利用する。ひとたび作成されると、該タスクコントローラ１７６がＧＵＩ設計パネルのオブジェクトウェル３９２に表示される。設計者３０２は必要なだけ多くのタスクコントローラ１７６を追加することができる。
【０１３２】
タスクコントローラ１７６は、ユーザが複数のパネルビュー１７０を形成し、パネル１７４におけるより高レベルの対話性を一般的に調整することを可能にする。複数のパネルインタフェースまたは高レベルの対話性を作成するために必要な要素およびステップは、当該技術分野で周知である。本発明におけるタスクコントローラ１７６の唯一の独自の要素は、タスクコントローラ１７６におけるイベント１０２および属性１０８の利用である。タスクコントローラ１７６にイベント１０２および属性１０８を与えることによって、タスクコントローラ１７６を本発明の制御フローおよびデータマッピング機構に容易にリンクすることができる。
【０１３３】
ステップ４１６でタスクコントローラが定義されると、ビュー１７０を作成するための手順がステップ４１８で完了する。言うまでもなく、ビュー４１６を作成するためのステップは、この直線的なやり方に従う必要はない。実際、設計者３０２はビュー１７０の定義付けに戻り、変更を希望する場合にいつでもパネル１７４、タスクコントローラ１７６、およびデータ結線に更新を行なうことが予想される。
【０１３４】
タスクエディタ３８０の上記説明は、タスクを完了するためにエンドユーザ６０２との幾つかの対話が必要であると想定したものであることに注意されたい。ミドルウェアアダプタ２４０を使用して単に外部アプリケーションを始動してタスク１３０を完了することが可能である。そのような場合、ビュー１７０、パネル１７４、またはタスクコントローラ１７６を作成する必要は無い。必要なことは、適切な該アダプタ２４０を作成し、アダプタのイベント１０２とタスク１３０のイベント１０２をリンクし、データマッピングを行なうだけである。このようにして、制御フローは外部アプリケーションに受け渡され、データはプロセスモデル１００と外部アプリケーションとの間を流れることができる。
【０１３５】
「プロセスサーバ５００」
該プロセスモデル１００が定義されたとき、該プロセスデザイナ３００は配備パッケージを生成し、それをプロセスサーバ５００にインストールする。該配備パッケージは、コンパイル済みプロセスモデル１００、関連クラスおよびオブジェクト、ならびにミドルウェアアダプタ２４０を含め、実行時アプリケーションを実行するために必要な情報を全て含む。配備パッケージはまた、プロセス１２０の定義の一貫性および完全性、ならびにリポジトリオブジェクト３１２のチェックイン状態を検証する。
【０１３６】
更新されたプロセスモデル配備パッケージのインストールは、サーバ５００が起動され実行している間に実行することができる。本メカニズムにより、更新されたか新しいプロセスモデル１００を実行中のサーバ５００に実時間で重ねることができる。更新されたプロセスモデル１００が配備されている間、すでに進行中のタスク１３０はタスク１３０の古い定義に従って実行することができる。
【０１３７】
配備パッケージがプロセスサーバ５００にインストールされると、プロセスサーバ５００のランタイムシステムが引き継ぐ。ランタイムシステムはランタイムモデルに含まれるプロセスデータを解釈し、反応して入力を処理し、エンドユーザ６０２によってピックアップされるようにタスク割当をディスパッチする。ランタイムシステムはまた、ユーザおよびグループに関する情報も維持し、プロセスサーバ５００にログインするユーザを認証し、サーバ５００のアクセス制御ポリシーを維持する。この情報は、プロセスサーバ５００で実行しているユーザ管理アプリケーションを通して、１人またはそれ以上のシステム管理者５０２によって制御され管理される。
【０１３８】
プロセスサーバ５００は各プロセス１２０およびタスク１３０の状態を維持しなければならない。各プロセス１２０は次の状態、すなわち非活動、活動中、中断、完了、または打切りの１つとすることができる。タスク１３０は、タスク１３０内の役割プロパティ１０９によって決定される通り、役割２７０に割り当てられる。割当準備ができたタスク１３０があるとき、それはタスク１３０を取り扱うことのできる各役割２７０の待ち行列に入れられる。次いでプロセスクライアント６００は実行のために待ち行列からタスク１３０を取り出す。上記の通り、割り当てられたタスク１３０を完了しなければならないエンドユーザ６０２の人数および分布を定義することができる。該プロセスサーバ５００は、タスク１３０が完了したとみなされるときを知るために、それがエンドユーザ６０２に割り当てるタスク１３０の完了状態を追跡する。正しい数に達すると、該タスク１３０は完了のためにそれ以上プロセスクライアント６００に提示されなくなる。
【０１３９】
「プロセスクライアント６００」
該プロセスクライアント６００は、エンドユーザ６０２がプロセスサーバ５００にログインしてタスクを表示し、取り出し、実行するためのフロントエンドアプリケーションである。ひとたびプロセスサーバ５００に接続されると、該プロセスクライアント６００は、ログインしたユーザ６０２の役割および属性に基づいて、プロセスサーバ待ち行列にある利用可能なタスクを通知される。これらのタスク１３０は、図２１に示すように、タスクリスト６０４の形で提示される。該タスクリスト６０４はタスク１３０の名前、役割２７０、優先順位、および割当時間を示す。
【０１４０】
タスクリスト６０４内のタスク１３０は受け入れ、返し、完了し、あるいは打ち切ることができる。タスク１３０が受け入れられると、該プロセスサーバ５００は割当を記録し、同一役割２７０内の他のユーザ６０２に割当のことを通知する。タスク１３０を受け入れたエンドユーザ６０２はタスク１３０を未完了状態でプロセスサーバ５００に返すことができるので、タスクはこの時点ではプロセスサーバ５００のタスク１３０の待ち行列から除去されない。タスク１３０がこのようにして返された場合、該プロセスサーバ５００は割当を除去し、該タスク１３０を割り当てられた役割２７０の全ユーザ６０２に再び利用可能にする。ユーザ６０２がタスク１３０を完了すると、該プロセスサーバ５００はタスク１３０を不完全タスク１３０の待ち行列から除去する。
【０１４１】
また、タスク１３０が割り当てられた後、システム管理者５０２がタスク１３０を打ち切ることも可能である。タスク１３０が打ち切られると、該プロセスサーバ５００はタスク１３０を待ち行列から除去する。
【０１４２】
本発明は、発明の精神または範囲から逸脱することなくその変化および変形を施すことができるので、その詳細の全てに限定されると受け取るべきではない。例えば、追加的またはより少数の構成要素１００を使用して、本発明のプロセスモデル１００を実現することが可能である。また、１つの動作環境しかサポートしないビュー１７０を持ち、あるいはタスク１３０を役割２７０に対してではなくユーザ２８０に直接割り当てることも、充分に本発明の範囲内である。本発明の範囲内で特徴および要素の多くの可能な組合せが考えられ、したがってその範囲は請求の範囲の記載によってのみ限定されるべきである。
【図面の簡単な説明】
【図１】
本発明で定義することのできる２つのプロセスの代表図である。
【図２】
タスクを有するサブプロセスを有するプロセスによる本発明のデータマッピングを示す代表図である。
【図３】
本発明のプロセスモデルの要素の階層を示す組織図である。
【図４】
本発明の各コンテナ内の許容構成要素の階層規則を示す図である。
【図５】
本発明のコンテナのデフォルト動作、結果、およびプロパティを示す図である。
【図６】
本発明の要素のデフォルト動作、結果、およびプロパティを示す図である。
【図７】
本発明の結合要素のフロー制御を示す代表図である。
【図８】
本発明のタイマ要素のフロー制御を示す代表図である。
【図９】
本発明のルータの定義におけるコンパレータ要素のフロー制御を示す代表図である。
【図１０】
本発明のソフトウェアツールの代表図である。
【図１１】
本発明のリポジトリの代表図である。
【図１２】
本発明のプロジェクト管理インタフェースを示すＧＵＩオペレーティングシステムウィンドウの図である。
【図１３】
本発明のプロジェクト設計者のユーザインタフェースを示すＧＵＩオペレーティングシステムウィンドウの図である。
【図１４】
制御フローエディタモードで作動する図１３のユーザインタフェースの図である。
【図１５】
サブプロセス１２２が選択されたときの図１４のユーザインタフェースの図である。
【図１６】
本発明の制御フローおよびデータフローの要素を結合するプロセスを示すフローチャートの図である。
【図１７】
本発明の新リンクダイアログボックスを示すＧＵＩオペレーティングシステムウィンドウの図である。
【図１８】
本発明のイベントマッピングダイアログボックスを示すＧＵＩオペレーティングシステムウィンドウの図である。
【図１９】
タスクエディタモードで作動する図１３のユーザインタフェースの図である。
【図２０】
本発明で図を定義付けるプロセスを示すフローチャートの図である。
【図２１】
本発明でエンドユーザに提示されるタスクリストを示すＧＵＩオペレーティングシステムウィンドウの図である。
【図１】
2005502928.tif 000004
【図２】
2005502928.tif 000005
【図３】
2005502928.tif 000006
【図４】
2005502928.tif 000007
【図５】
2005502928.tif 000008
【図６】
2005502928.tif 000009
【図７】
2005502928.tif 000010
【図８】
2005502928.tif 000011
【図９】
2005502928.tif 000012
【図１０】
2005502928.tif 000013
【図１１】
2005502928.tif 000014
【図１２】
2005502928.tif 000015
【図１３】
2005502928.tif 000016
【図１４】
2005502928.tif 000017
【図１５】
2005502928.tif 000018
【図１６】
2005502928.tif 000019
【図１７】
2005502928.tif 000020
【図１８】
2005502928.tif 000021
【図１９】
2005502928.tif 000022
【図２０】
2005502928.tif 000023
【図２１】
2005502928.tif 000024
【国際公開パンフレット】
2005502928.tif 000025
2005502928.tif 000026
2005502928.tif 000027
2005502928.tif 000028
2005502928.tif 000029
2005502928.tif 000030
2005502928.tif 000031
2005502928.tif 000032
2005502928.tif 000033
2005502928.tif 000034
2005502928.tif 000035
2005502928.tif 000036
2005502928.tif 000037
2005502928.tif 000038
2005502928.tif 000039
2005502928.tif 000040
2005502928.tif 000041
2005502928.tif 000042
2005502928.tif 000043
2005502928.tif 000044
2005502928.tif 000045
2005502928.tif 000046
2005502928.tif 000047
2005502928.tif 000048
2005502928.tif 000049
2005502928.tif 000050
2005502928.tif 000051
2005502928.tif 000052
2005502928.tif 000053
2005502928.tif 000054
2005502928.tif 000055
2005502928.tif 000056
2005502928.tif 000057
2005502928.tif 000058
2005502928.tif 000059
2005502928.tif 000060
2005502928.tif 000061
2005502928.tif 000062
2005502928.tif 000063
2005502928.tif 000064
2005502928.tif 000065
2005502928.tif 000066
2005502928.tif 000067
2005502928.tif 000068
2005502928.tif 000069
2005502928.tif 000070
2005502928.tif 000071
2005502928.tif 000072
2005502928.tif 000073
2005502928.tif 000074
2005502928.tif 000075
2005502928.tif 000076
2005502928.tif 000077
2005502928.tif 000078
2005502928.tif 000079
2005502928.tif 000080
2005502928.tif 000081
2005502928.tif 000082
2005502928.tif 000083
2005502928.tif 000084
2005502928.tif 000085
2005502928.tif 000086
2005502928.tif 000087
2005502928.tif 000088
2005502928.tif 000089
2005502928.tif 000090
2005502928.tif 000091
2005502928.tif 000092
2005502928.tif 000093
2005502928.tif 000094
2005502928.tif 000095
2005502928.tif 000096
2005502928.tif 000097
2005502928.tif 000098
2005502928.tif 000099
2005502928.tif 000100
2005502928.tif 000101
【国際公開パンフレット（コレクトバージョン）】
2005502928.tif 000102
2005502928.tif 000103
2005502928.tif 000104
2005502928.tif 000105
2005502928.tif 000106
2005502928.tif 000107
2005502928.tif 000108
2005502928.tif 000109
2005502928.tif 000110
2005502928.tif 000111
2005502928.tif 000112
2005502928.tif 000113
2005502928.tif 000114
2005502928.tif 000115
2005502928.tif 000116
2005502928.tif 000117
2005502928.tif 000118
2005502928.tif 000119
2005502928.tif 000120
2005502928.tif 000121
2005502928.tif 000122
2005502928.tif 000123
2005502928.tif 000124
2005502928.tif 000125
2005502928.tif 000126
2005502928.tif 000127
2005502928.tif 000128
2005502928.tif 000129
2005502928.tif 000130
2005502928.tif 000131
2005502928.tif 000132
2005502928.tif 000133
2005502928.tif 000134
2005502928.tif 000135
2005502928.tif 000136
2005502928.tif 000137
2005502928.tif 000138
2005502928.tif 000139
2005502928.tif 000140
2005502928.tif 000141
2005502928.tif 000142
2005502928.tif 000143
2005502928.tif 000144
2005502928.tif 000145
2005502928.tif 000146
2005502928.tif 000147
2005502928.tif 000148
2005502928.tif 000149
2005502928.tif 000150
2005502928.tif 000151
2005502928.tif 000152
2005502928.tif 000153
2005502928.tif 000154
2005502928.tif 000155
2005502928.tif 000156
2005502928.tif 000157
2005502928.tif 000158
2005502928.tif 000159
2005502928.tif 000160
2005502928.tif 000161
2005502928.tif 000162
2005502928.tif 000163
2005502928.tif 000164
2005502928.tif 000165
2005502928.tif 000166
2005502928.tif 000167
2005502928.tif 000168
2005502928.tif 000169
2005502928.tif 000170
2005502928.tif 000171
2005502928.tif 000172
2005502928.tif 000173
2005502928.tif 000174
2005502928.tif 000175
2005502928.tif 000176
【国際調査報告】
2005502928.tif 000177
2005502928.tif 000178
2005502928.tif 000179
2005502928.tif 000180