WO2011042969A1 - P2p型のワークフローシステム - Google Patents

Abstract

　本ワークフローシステムは、複数のプロセスサポートツール１０がネットワークを介して協働することによって構成される。あるプロセスサポートツール１０が親となってグループ１００を形成し、グループ１００の各メンバの役割と複数のタスクからなるワークフロー（プロセス５５）とを定義する。そして、当該グループ１００の各メンバは、定義されたメンバの役割に基づき、次タスクの処理者を特定しながら、プロセス５５を処理し、その結果を追記したメッセージ５６を次々とメンバ間で流通させていく。

Description

[規則37.2に基づきISAが決定した発明の名称]　P2P型のワークフローシステム

　この発明は、例えば企業等における、複数の工程からなり、かつ、複数の作業者を経由して処理される一連の作業を支援するためのワークフローシステムに関する。

　パーソナルコンピュータ（ＰＣ）の普及やネットワーク環境の整備等に伴い、多くの企業において、業務の電子化が広く図られている。この電子化によって業務を効率的に進められるように支援するための一手法として、ワークフローシステムが知られている。

　ワークフローシステムは、一般的に、サーバによって、作業の進捗状況等が一元管理され、各工程の作業者は、サーバとネットワーク接続されたＰＣを使って、担当する作業を適時に実施する。そして、このワークフローシステムに関しては、これまでも種々の提案がなされている（例えば特許文献１等参照）。

特開２００８－１１７２５８号公報

　現在一般的なサーバ型のワークフローシステムでは、同一システムに収容されていないユーザ間でプロセス（ワークフロー）を組む場合、同一のシステムに収容し直すか、それぞれが収容されているシステム間を接続することで対応することになるが、収容するシステムの準備、あるいは、システム管理者の調整や接続作業に手間がかかる課題がある。

　また、現在一般的なサーバ型のワークフローシステムでは、サーバにてプロセスやタスクを管理するため、異なったシステムから提供されているプロセス間を接続したり連携するにはそれぞれのシステムの管理者同士が調整のうえでシステム改修などの接続作業が必要であり手間がかかる課題がある（ここでの管理者とは、プロセスの改善に責任を持つ役割も含む）。また、同一システムが提供するプロセスの改善に対してもプロセスの改修のために管理者の手間がかかるのが一般的である。

　この結果、管理コストあたりの効果を最大とするため、システムでのサポート範囲を全体最適の標準プロセスに絞込み、そこから外れた枝葉の業務プロセスはメールや表計算ツールなどシステム外で対応するか、システムの作りに業務を合わせて対応するケースが少なくない。自分の利用している複数のシステム間が繋がっていないと、システムごとにあたかも自分が分身して、跨ったプロセス間に対して二重投入など自分が取り持つことを強いられるケースもある。また、システムでサポートされている業務プロセスであっても、業務をとりまく環境の変化にシステムの改修が追随できず、メールや表計算ツールで業務プロセスをこなして、システムへは事後にデータ投入というケースも少なくない。

　この発明は、このような事情を考慮してなされたものであり、システム管理者への手間をかけることなく、プロセスを改善したい当事者同士で改善できる運用を可能とするワークフローシステム、情報処理装置およびワークフローサポートプログラムを提供することを目的とする。

　前述した目的を達成するために、この発明のワークフローシステムは、複数のタスクからなるプロセスを、１以上のコンピュータ上に搭載され、前記複数のタスクの中の少なくとも１つのタスクが割り当てられた複数のワークフローサポートプログラムによって順次に処理するワークフローシステムであって、前記複数のワークフローサポートプログラムそれぞれが、メンバとして帰属させるワークフローサポートプログラムそれぞれの役割を定義しつつグループを作成するグループ作成手段と、各タスクを担当すべきメンバの役割を指定しつつ複数のタスクからなるプロセスを定義するプロセス定義手段と、前記プロセス定義手段によって定義されたプロセス内のタスクを処理し、当該プロセスについての各タスクの処理結果および進捗状況を示す情報を含むメッセージを、次タスクを担当すべき役割が定義されたワークフローサポートプログラムに転送するプロセス処理手段と、を具備し、前記グループ作成手段によって作成されたグループ内において、前記プロセス定義手段によって定義されたプロセスを、当該プロセスに関するメッセージを前記複数のワークフローサポートプログラム間で順次に転送していくことによって処理することを特徴とする。

　この発明によれば、システム管理者への手間をかけることなく、プロセスを改善したい当事者同士で改善できる運用を可能とする。

本発明の実施形態に係るワークフローシステムの動作環境を示す図。 同実施形態のワークフローシステムにおいて形成されるグループの構成を説明するための図。 同実施形態のワークフローシステムを実現するプロセスサポートツール（ワークフローサポートプログラム）の機能ブロックを示す図。 同実施形態のワークフローシステムで用いられる利用許諾情報の一構成例を示す図。 同実施形態のワークフローシステムで用いられるメンバ情報の一構成例を説明するための第１の図。 同実施形態のワークフローシステムで用いられるメンバ情報の一構成例を説明するための第２の図。 同実施形態のワークフローシステムで用いられるリンク情報の一構成例を説明するための第１の図。 同実施形態のワークフローシステムで用いられるリンク情報の一構成例を説明するための第２の図。 同実施形態のワークフローシステムで用いられる帰属許諾情報の一構成例を示す図。 同実施形態のワークフローシステムで定義されるプロセスの一構成例を説明するための第１の図。 同実施形態のワークフローシステムで定義されるプロセスの一構成例を説明するための第２の図。 同実施形態のワークフローシステムにおいて複数のプロセスサポートツールが協働してプロセスを処理する原理を説明するための概念図。 同実施形態のワークフローシステムにおけるプロセス（メッセージ）の処理手順の一例を示すフローチャート。 同実施形態のワークフローシステムにおいて提示される作業画面の一例を示す図。 同実施形態のワークフローシステムにおけるメッセージに対する処理結果情報の追記手順の一例を説明するための概念図。 同実施形態のワークフローシステムにおいて処理結果情報が追記されていくメッセージの一例を示す図。 同実施形態のワークフローシステムにおいて複数のプロセスを連携させる一例を説明するための図。 同実施形態のワークフローシステムにおいてあるプロセスの編集項目を他のプロセスによって細分化する一例を説明するための図。

　以下、図面を参照して、この発明の一実施形態を説明する。

　図１は、本発明の実施形態に係るワークフローシステムが動作する環境の一例を示す図である。

　本ワークフローシステムは、ＰＣや、サーバ等のコンピュータ２に各々インストールされた複数のプロセスサポートツール１０（ワークフローサポートプログラム）がネットワーク（Ａ，Ｂ）を介して協働することによって実現される。プロセスサポートツール１０は、例えば、コンピュータ２が読み取り可能なＯＤ（Optical disc）等に記録されて頒布され、または、主催者Ｗｅｂサーバ１からのダウンロードにて取得されるプログラムである。

　主催者Ｗｅｂサーバ１は、このプロセスサポートツール１０の頒布元（主催者）が開設するＷｅｂサーバであり、プロセスサポートツール１０の利用希望者（ユーザ）は、その利用許諾を、インターネットＡを介して主催者Ｗｅｂサーバ１に申請し、利用許諾情報を取得する。この利用許諾情報は、プロセスサポートツール１０が、他のプロセスサポートツール１０と協働してワークフローシステムを実現するために必要となる情報を含んでおり、その詳細は後述する。

　本ワークフローシステムは、主催者Ｗｅｂサーバ１から利用許諾情報を取得したプロセスサポートツール１０同士がグループ１００を組むことにより、各プロセスサポートツール１０のユーザ間を経由するプロセス（ワークフロー）を適宜に定義し運用することのできる、Ｐ２Ｐ型のワークフローシステムである。図１の例では、複数のＰＣ同士でインターネットＡを介してグループ１００が組まれており（グループ１）、また、Ｎ社の構内に敷設されたＬＡＮ（Ｂ）上のサーバおよびＰＣによってグループ１００が組まれており（グループ２）、同様に、Ｓ社の構内に敷設されたＬＡＮ（Ｂ）上のサーバおよびＰＣによってグループ１００が組まれている（グループ３）。さらに、Ｎ社およびＳ社双方のサーバ同士でグループ１００が組まれている（グループ４）。このように、プロセスサポートツール１０同士によるグループ１００の形成は、インストール先のコンピュータ２が置かれている状況には全く制限されない。

　なお、図１では、各ユーザがそれぞれコンピュータ２を使用し、各自のコンピュータ２にプロセスサポートツール１０が各々インストールされる例を示したが、本ワークフローシステムは、この形態に限定されず、例えば、１つのコンピュータ２を複数のユーザが共用する場合において、この１つのコンピュータ２に、ユーザ数分のプロセスサポートツール１０を実装させることにより、当該１つのコンピュータ２を共用する複数のユーザ間で本ワークフローシステムを利用することも可能である。

　図２は、本ワークフローシステムを実現する（コンピュータ２に各々インストールされる）複数のプロセスサポートツール１０によって形成されるグループ１００の構成を説明するための図である。

　図２に示すように、本ワークフローシステムにおいて形成されるグループ１００は、それを構成するプロセスサポートツール１０のうち１つが親の役割を担い、それ以外のプロセスサポートツール１０が子の役割を担う。また、各プロセスサポートツール１０は、複数のグループ１００に帰属することができる。図２に示す例では、グループ５に子として参加するプロセスサポートツール１０（図２のａ１）が、親としてグループ６を形成している。つまり、プロセスサポートツール１０は、親としてグループ１００を形成するための親機能と、グループ１００に子として参加するための子機能とをそれぞれが併せ持っている。

　図３は、本ワークフローシステムを実現するプロセスサポートツール１０の機能ブロックを示す図である。

　図３に示すように、プロセスサポートツール１０は、グループメンバ管理部１１、プロセス定義部１２、タスク処理部１３、ユーザインタフェース部１４、通信処理部１５、公開鍵暗号処理部１６等を有している。このうち、グループメンバ管理部１１およびプロセス定義部１２は、親機能を実現するために設けられるモジュールであり、タスク処理部１３、ユーザインタフェース部１４、通信処理部１５、公開鍵暗号処理部１６は、（親または子の役割に関わらない）共通機能を実現するために設けられるモジュールである。

　なお、ユーザインタフェース部１４は、キーボードやポインティングデバイス等を介してユーザからのデータ入力を受け付けると共に、ディスプレイ等を介してユーザへのデータ出力を行うためのモジュールであり、通信処理部１５は、電子メール等のメッセージを他のコンピュータ２との間で送受信するためのモジュールであり、公開鍵暗号処理部１６は、公開鍵暗号方式によるデータの暗号化／復号や電子署名とその検証を行うためのモジュールである。

　また、プロセスサポートツール１０は、データベース５０を有しており、このデータベース５０を利用して、メンバ情報５１、リンク情報５２、帰属許諾情報５３、利用許諾情報５４、プロセス５５、メッセージ５６等の各種情報を管理する。

　利用許諾情報５４の取得は、例えば、主催者の提供する「利用許諾申請」プロセスにより行う。プロセスの動作は、後述するプロセスの動作原理に基づく。これにより取得された利用許諾情報５４はデータベース５０で管理される。図４に、利用許諾情報５４の一構成例を示す。

　利用許諾情報５４は、例えばＸＭＬ(Extensible markup language)で記述されたテキストデータとして作成され、プロセスサポートツール１０に一意に割当てられた「ツールＩＤ」、電子メールアドレス等の「メッセージ交換のための情報」、「ユーザの公開鍵」を含み、これ以外にも「ユーザ名」、「利用期限」等を含み得る。主催者は、これらの情報を、例えばプロセスサポートツール１０のユーザに対する課金管理を行うための情報として利用する。利用許諾情報５４は主催者の電子署名を付してプロセスサポートツール１０に送信される。本実施形態では、公開鍵は、ＣＡ（certificate authority）局発行の証明書の形式で扱われるものと想定する。主催者自身がＣＡ局として、利用許諾情報５４を証明書の形式で発行してもよい。また、この利用許諾情報５４の検証を含め、以下、電子署名を使った各種データの検証は、すべて公開鍵暗号処理部１６を用いて実行されるものとする。各プロセスサポートツール１０は、管理している公開鍵・秘密鍵の情報と、利用許諾情報５４に記載されているツールＩＤ・公開鍵をもとに自己を識別する。

　次に、以上のように各々が利用許諾情報５４を取得した複数のプロセスサポートツール１０が協働して、グループ１００を形成してワークフローを定義・処理する基本原理について説明する。

　プロセスサポートツール１０を用いるユーザ間でグループ１００を形成する場合、前述したように、いずれかのユーザのプロセスサポートツール１０が親となる。親以外のユーザのプロセスサポートツール１０は、親のプロセスサポートツール１０より帰属許諾情報５３を取得する。帰属許諾情報５３の取得は、例えば、主催者の提供する「グループ形成」プロセスにより行う。プロセスの動作は後述するプロセスの動作原理に基づく。

　まず、「グループ形成」プロセスにより当該グループ１００に関するメンバファイルを読み込み、その情報に基づき、グループメンバ管理部１１がメンバ情報５１を作成する。

　図５Ａは、メンバ情報５１の作成用にユーザが作成するメンバファイルの一例を示す図であり、一方、図５Ｂは、メンバ情報５１の一例を示す図である。

　メンバファイルは、例えば、表計算ソフトウェアのワークシートのような形式で作成される。図５Ａに示すように、「ツールＩＤ」フィールド、「グループ名」フィールド、「利用可能プロセス」フィールド、「役割」フィールドの値を含む。利用許諾情報５４と異なる「ユーザ名」、「メッセージ交換のための情報」、「ユーザの公開鍵」をこのグループ１００で利用する場合には、これらの情報も含ませる。ここで、プロセスとは、複数の工程からなる一連の作業（ワークフロー）をいい、プロセス内の各工程をタスクと称するものとする。役割の詳細については後述する。

　図５Ａの例では、形成するグループ１００の名称を「Ｂ部」に設定している。また、メンバ「佐藤一郎」は、「決裁」プロセス、「特許」プロセスに関与でき、「決裁」プロセスでは「社員」の役割、「特許」プロセスでは「特許担当」の役割を担う旨が定義されている。メンバ「田中二郎」は、「決裁」プロセスのみに関与でき、「決裁」プロセスにおける役割は「課長」、また、メンバ「鈴木三郎」，「青木四郎」も、「決裁」プロセスのみに関与でき、「決裁」プロセスにおける役割は、「部長」，「部門長」である旨がそれぞれ定義されている。そして、このメンバファイルに基づき、グループメンバ管理部１１は、図５Ｂに示すメンバ情報５１を作成し、データベース５０で管理する。メンバ情報５１は、例えばＸＭＬで記述されたテキストデータとして作成される。図５Ｂ中の「グループＩＤ」は、例えば、親となるユーザのプロセスサポートツール１０の「ツールＩＤ」＋当該プロセスサポートツール１０が親となってグループ１００を形成する毎にインクリメントされる連番など、複数のグループ１００間で重複しないように一意の値が割り当てられる。

　なお、この（親となるユーザのプロセスサポートツール１０の）グループメンバ管理部１１によるメンバ情報５１の作成時、子となる他のユーザのプロセスサポートツール１０では、親からの要求に応じて、自身の利用許諾情報５４を返送し、親は、その内容を確認してメンバの利用に関する正当性の検証やメンバファイルに公開鍵が含まれていない場合の公開鍵取得を行う。なお、「グループ形成」プロセスのように親が能動的にメンバを構成する方法だけでなく、例えば主催者の提供する「グループ加入申請」プロセスにより加入したいユーザから申請しメンバ情報５１を更新する方法もある。

　続いて、「グループ形成」プロセスまたは「グループ加入申請」プロセスにより、当該グループ１００に関するリンクファイルを読み込んでその情報に基づいてグループメンバ管理部１１がリンク情報５２を作成する。図６Ａは、リンク情報５２の作成用にユーザが作成するリンクファイルの一例を示す図であり、一方、図６Ｂは、リンク情報５２の一例を示す図である。

　リンクファイルは、例えば、表計算ソフトウェアのワークシートのような形式で作成される。図６Ａの例では、メンバ「佐藤一郎」（役割「社員」）→メンバ「田中二郎」（役割「課長」）→メンバ「鈴木三郎」（役割「部長」）→メンバ「青木四郎」（役割「部門長」）といった（形成しようとしているグループ１００内における）メンバ間のリンクが定義されている。このリンクファイルでの定義によって、例えば、当該グループ１００内に複数の課長や部長が存在する場合であって、「社員」→「課長」→「部長」という流れのプロセスが、メンバ「佐藤一郎」を起点として発生した場合に、このプロセスを、複数存在する課長や部長の中からメンバ「田中二郎」、メンバ「鈴木三郎」へと的確に流通させることができる。なお、プロセスによって適用するリンクが異なる場合、「適用プロセス」欄にも設定しておく。そして、このリンクファイルに基づき、グループメンバ管理部１１は、図６Ｂに示すリンク情報５２を作成し、データベース５０で管理する。リンク情報５２は、例えばＸＭＬで記述されたテキストデータとして作成される。

　以上のようにグループメンバ管理部１１によって作成されるメンバ情報５１およびリンク情報５２（図３においてハッチングが施されたデータ）は、当該グループ１００を形成した親のプロセスサポートツール１０のデータベース５０で管理される。従って、あるプロセスサポートツール１０が、ｎ個のグループ１００に帰属し、そのうちのｍ個のグループ１００について、親となってそれらのグループ１００を形成・管理する場合、当該プロセスサポートツール１０のデータベース５０には、ｍ個のメンバ情報５１およびリンク情報５２がそれぞれ存在することになる。

　さらに、「グループ形成」プロセスまたは「グループ加入申請」プロセスにより、グループメンバ管理部１１は、以上のように作成したメンバ情報５１とリンク情報５２とに基づき、（自身のものを含む）グループ１００内に帰属するメンバそれぞれの帰属許諾情報５３を作成し、各メンバに配布する。図７に、帰属許諾情報５３の一構成例を示す。

　図７に示す帰属許諾情報５３は、メンバ「佐藤一郎」について作成される帰属許諾情報５３の例である。なお、当該グループ１００は、メンバ「青木四郎」のプロセスサポートツール１０が親となって形成されるものであると想定する。そのために、そのツールＩＤ「００ＱＫＷｋｗｅｏｑ」（図５Ａ参照）＋連番「００１」が当グループ１００のグループＩＤとして割り当てられている。

　グループメンバ管理部１１は、メンバ情報５１に記載された各メンバについて、リンク情報５２を参照して、当該メンバと直接的または間接的にリンクを有する他のメンバを検出する。そして、「親（自身の情報）」、「自己情報（当該メンバの情報）」、「メンバ（検出した他のメンバの情報）」を含み、かつ、これらを範囲とした電子署名を付したデータを当該メンバ用の帰属許諾情報５３として作成する。帰属許諾情報５３は、配布先の各メンバのプロセスサポートツール１０のデータベース５０でそれぞれ管理される。帰属許諾情報５３は、例えばＸＭＬで記述されたテキストデータとして作成される。

　図６Ｂに示したリンク情報５２によれば、メンバ「佐藤一郎」は、メンバ「田中二郎」と（直接的に）リンクを有することが分かり、次いで、このメンバ「田中二郎」は、メンバ「鈴木三郎」と（直接的に）リンクを有することから、さらにメンバ「佐藤一郎」が「鈴木三郎」と（間接的に）リンクを有することが分かる。このように、リンク情報５２を辿ることにより、図７に示したような、メンバ「佐藤一郎」の帰属許諾情報５３が作成される。なお、リンク情報内で適用プロセスが設定されている場合、関連メンバの情報内に「適用プロセス」が設定される。この帰属許諾情報５３には、親の公開鍵および親の電子署名が含まれているので、改ざんされていないことを適宜に検証することができる。あるプロセスサポートツール１０がｎ個のグループ１００に帰属する場合、そのプロセスサポートツール１０のデータベース５０には、（親または子の役割に関わらず）ｎ個の帰属許諾情報５３が存在することになる。

　以上により、「グループ形成」プロセスまたは「グループ加入申請」プロセスに基づいたグループメンバ管理部１１によるグループ１００の形成は完了し、親となるプロセスサポートツール１０は、今度は、当該グループ１００内において処理するプロセス５５の定義を、例えば、主催者の提供する「プロセス定義」プロセスに基づき、プロセス定義部１２によって実行する。図８Ａおよび図８Ｂを参照して、プロセス５５の一構成例について説明する。

　図８Ａは、プロセス５５の定義用にユーザが作成するプロセスファイルの一例を示す図であり、一方、図８Ｂは、このプロセスファイルに基づいてプロセス定義部１２が作成するプロセス５５の一例を示す図である。

　前述したように、プロセスは、一連のタスクによって構成されるものであり、プロセスファイルにより、各タスクの処理内容、各タスクを処理すべきメンバの役割およびタスクの処理順序が定義される。図８Ａの例では、「決裁」プロセスが、「起案」タスク→「起案書整備」タスク→「起案者署名」タスク→「確認」タスク→…「完了」タスクという手順で定義されている。また、「起案」タスクを例に説明すると、この「起案」タスクを処理するのは「社員」の役割を担うメンバであり、その処理内容は、変数「件名」、「決裁内容」、「決裁金額」、「金額単位」および「決裁種別」の編集であることが定義されている。つまり、「タスクＩＤ」フィールドのタスクを、「実施者」フィールドの役割を担うメンバが、「制御構文」フィールドのコマンドを「引数」フィールドの指定に従って実行することによって処理することが順次に行われていく。

　プロセスファイルは、例えば、表計算ソフトウェアのワークシートのような形式で作成される。そして、このプロセスファイルに基づき、プロセス定義部１２は、図８Ｂに示すプロセス５５を作成する。その際、各プロセス５５には、例えば、グループＩＤ（００ＱＫＷｋｅｏｑ００１）＋グループ１００内でプロセス５５を作成する毎にインクリメントされる連番（００１）等の一意な値がプロセスＩＤとして割り当てられる。また、各プロセス５５には、親の電子署名が含まれるので、帰属許諾情報５３に含まれる親の公開鍵を使って、当該プロセス５５が改ざんされていないことを適宜に検証することができる。プロセス５５は、例えばＸＭＬで記述されたテキストデータとして作成される。

　典型的な内容のプロセスを定義したプロセステンプレートを主催者Ｗｅｂサーバ１などから取得できるようにし、このプロセステンプレートにグループ１００としてのプロセスＩＤとプロセス名、親による電子署名を付与してプロセス５５として定義することで、親のプロセス作成の手間を省くことができる。

　プロセス５５は、グループ１００内の少なくとも当該プロセス５５を処理するメンバのプロセスサポートツール１０に配布され、それぞれデータベース５０で管理される。これに代えて、例えば、グループ１００内の全てのメンバのプロセスサポートツール１０からアクセス可能な共有ファイルサーバ等で管理するようにしてもよい。

　次に、以上のように（メンバ情報５１、リンク情報５２および帰属許諾情報５３が作成されることによって）グループ１００が形成され、かつ、プロセス５５が定義された本ワークフローシステムにおいて、当該グループ１００に帰属する複数のメンバのプロセスサポートツール１０が、どのような手順で協働してプロセス５５を処理するのかを、図９乃至図１５を参照しながら説明する。

　図９は、本ワークフローシステムにおいて複数のプロセスサポートツール１０が協働してプロセス５５を処理する原理を説明するための概念図である。

　各プロセスサポートツール１０におけるプロセス５５の処理は、タスク処理部１３によって実行される。いま、メンバ「佐藤一郎」が、決裁書を起票して提出しようと考えているものと想定する。この決裁書に関する一連の作業（ワークフロー）を定義したものが「決裁」プロセスである。

　そこで、メンバ「佐藤一郎」は、プロセスサポートツール１０を使って、（複数のプロセスの中から）「決裁」プロセスを選択する操作を行う。この操作を受けて、タスク処理部１３は、まず、プロセス５５の１つとして管理された「決裁」プロセスが改ざんされていないことを帰属許諾情報５３（親の公開鍵）により検証し、また、メンバ「佐藤一郎」が「決裁」プロセスを立ち上げ可能であることを、同じく帰属許諾情報５３に利用可能プロセスとして「決裁」プロセスが記載され、かつ、最初の「起案」タスクの役割「社員」の役割が記載されていることを調べることによって確認する。正当性が検証でき、立ち上げ可能であることが確認できたら、タスク処理部１３は、メッセージ５６を生成し最初の「起案」タスクを実行する。以降、このメッセージ５６はプロセス５５で定義された各タスクを処理すべき役割を担うプロセスサポートツール１０間を流通していくことになる。メッセージ５６は、各プロセスサポートツール１０上においては、メッセージ管理部としても機能するタスク処理部１３によりデータベース５０で管理される。

　プロセス５５を立ち上げる際、即ち、メッセージ５６を生成する際、タスク処理部１３は、自身の帰属許諾情報５３を当該メッセージ５６内に格納する。この帰属許諾情報５３内には、当該メッセージ５６の流通経路上に介在するメンバの公開鍵が含まれるので、以降、各メンバは、この帰属許諾情報５３を使って、当該メッセージ５６内の各種データの検証を適宜に行えることになる。

　この「決裁」プロセスは、「起案」タスク→「起案書整備」タスク→「起案者署名」タスクという流れで処理されていくが、これらは役割「社員」のメンバによって実行されるべき旨が定義されているので、当該「決裁」プロセスを立ち上げたメンバ「佐藤一郎」のプロセスサポートツール１０によって、タスク処理部１３の制御下において連続して実行される。タスク処理部１３は、対象のタスクを処理する毎に、その処理結果を当該メッセージ５６内に追記し、電子署名を付していく。

　一方、その次の「確認」タスクは、役割「課長」のメンバによって実行されるべき旨が定義されている。そこで、（メンバ「佐藤一郎」のプロセスサポートツール１０の）タスク処理部１３は、帰属許諾情報５３を参照して、メンバ「佐藤一郎」にとっての「課長」がメンバ「田中二郎」であることを認識し、帰属許諾情報５３に含まれる「メッセージ交換のための情報」を用いて、メンバ「田中二郎」のプロセスサポートツール１０に対して当該メッセージ５６を転送する。

　そして、このメッセージ５６を受信した（メンバ「田中二郎」のプロセスサポートツール１０の）タスク処理部１３は、当該メッセージ５６内に追記された、電子署名が付されたそれまでの処理結果を、帰属許諾情報５３に含まれる前タスクのメンバの公開鍵を使って検証し、その正当性が検証されたならば、自身の「確認」タスクの処理を開始する。以下、同様に、メンバ「田中二郎」によるタスクの処理結果が当該メッセージ５６内に追記され、メンバ「田中二郎」にとっての「部長」がメンバ「鈴木三郎」であることが帰属許諾情報５３によって認識されて、当該メッセージ５６がメンバ「鈴木三郎」に転送されていく。

　なお、同一グループ１００内において、当該「決裁」プロセスを、他の課や部、つまりメンバ「田中二郎」、メンバ「鈴木三郎」が「課長」、「部長」ではない（役割「社員」の）メンバが立ち上げた場合、そのメッセージ５６は、当該メンバの帰属許諾情報５３に基づき、当該メンバにとっての「課長」、「部長」が適切に特定されて転送されていくことになる。

　各プロセスサポートツール１０では、タスク処理部１３が、制御構文として予め定義された文法に則って各タスクを処理する。制御構文は、例えば以下のような設定ができる。

　・変数値のユーザへの表示、変数のユーザによる編集、変数への代入、演算、文字列操作
　・ユーザの秘密鍵による電子署名
　・定数定義、変数の階層定義
　・タイムスタンプ（ｅ文書（電子署名が付された電子文書）に対しサービスプロバイダのタイムスタンプを取得）
　・データのファイルやデータベースへの書込、読出。ｅ文書のフォルダやデータベースへの保管。

　・条件分岐（次タスク制御含む）、待機、繰り返し
　・他メッセージ生成（他プロセス起動）
　変数値の編集などユーザの操作が必要な場合以外はタスクで規定された通りに自動処理される。例えば図８Ａにおいて、「起案者署名」タスクは「ｓｉｇｎ」であり、「起案日」や「件名」等からなる「決裁書」を作成し、社員の秘密鍵により電子署名を行うが、変数に対応するアクションが全て「参照」で以前のタスクで設定済の値を引用するだけなので自動処理される。なお、タスク処理部１３は、タスクの制御構文で変数が引用されていた場合、それまでのタスクの処理結果情報を順に遡っていき、最初に検出した処理結果情報内の設定値をその時点の値と見なして処理や表示を行う。

　図１０は、本ワークフローシステムにおけるプロセス５５（メッセージ５６）の処理手順の一例を示すフローチャートである。

　まず、あるグループ１００に帰属するいずれかのプロセスサポートツール１０のタスク処理部１３の制御下において、当該グループ１００で定義されたいずれかのプロセス５５の選択が行われる（ステップＡ１）。この選択が行われた際、タスク処理部１３は、当該プロセス５５の正当性を、当該プロセス５５に付された親の電子署名と、帰属許諾情報５３に含まれる親の公開鍵とから検証し（ステップＡ２）、さらに、帰属許諾情報５３に基づき、当該プロセス５５の立ち上げ可否を確認する（ステップＡ３）。

　このプロセス５５の正当性の検証および立ち上げ可否の確認を経た後、タスク処理部１３は、メッセージ５６を生成する（ステップＡ４）。メッセージ５６は、例えばＸＭＬで記述されたテキストデータとして作成され、メッセージＩＤ、グループＩＤ（プロセスＩＤ内に含まれる場合は不要）、プロセスＩＤ、起票者の帰属許諾情報５３が含まれる。メッセージＩＤは、系全体で一意の値としてこの時点で生成される。例えば、当該のプロセスサポートツール１０のツールＩＤ＋生成時刻情報＋単位生成時刻内でメッセージを生成する毎にインクリメントされる連番値の組合せにより割り当てる。その他に起票者の利用許諾情報５４やプロセス自体を含んでもよい。利用許諾情報５４は後述する一見ユーザ処理などに利用する。

　そして、タスク処理部１３は、プロセス５５で定義される最初のタスクの処理を開始する（ステップＡ５）。

　図８Ａおよび図８Ｂによって例示した「決裁」プロセスに対応するメッセージ５６が生成されたものと想定すると、その最初のタスクは、「起案」タスクであり、その制御構文は「ｅｄｉｔ」、つまり「編集」であるので、タスク処理部１３は、例えば、図１１に示す作業画面を提示して、ユーザに各項目の入力を促す。図８Ａおよび図８Ｂに示したように、この「起案」タスクは、変数「件名」、変数「決裁内容」、変数「決裁金額」、変数「金額単位」および変数「決裁種別」に値を入力するものなので、タスク処理部１３は、これらの入力領域を作業画面に配置して提示する。その際、タスク処理部１３は、ユーザインタフェース部１４を使用する。

　当該タスクの処理が完了すると、タスク処理部１３は、まず、その処理結果（成功/失敗等）や作業画面上での入力値や演算処理結果などを、メッセージ５６に処理結果情報として記録する（ステップＡ６）。また、タスク処理部１３は、同じく処理結果情報として自分のツールＩＤ（処理者情報）をメッセージ５６に記録する（ステップＡ７）。さらに、タスク処理部１３は、例えば作業終了時刻など（その他関連情報）を、同じく処理結果情報としてメッセージ５６に記録する（ステップＡ８）。

　処理結果情報をメッセージ５６へ記録すると、タスク処理部１３は、現タスクが最後のタスク（「完了」；制御構文「ｔｅｒｍｉｎａｔｅ」）か否かを調べる（ステップＡ９）。最後のタスクでなければ（ステップＡ９のＮＯ）、次のタスクを特定し、そのタスクＩＤを（次の）処理結果情報としてメッセージ５６に記録する（ステップＡ１０）。次タスクＩＤは、タスクの処理結果として特定されない場合は、プロセス５５での現タスクの次の行に記述されたタスクが選択される。

　また、タスク処理部１３は、対応するプロセス５５と帰属許諾情報５３とにより、先に特定した次のタスクの処理者を特定して、そのツールＩＤ（処理者情報）を（次の）処理結果情報としてメッセージ５６に記録する（ステップＡ１１）。次タスク処理者は、タスクの処理結果として特定されることもある。当該担当者情報がメッセージ内の帰属許諾情報５３に含まれていなければ、当該担当者の当番の際に、当該担当者の帰属許諾情報５３をメッセージ５６に追記する（処理結果に対する電子署名の検証のため）。

　そして、タスク処理部１３は、メッセージ５６に対して追記したそれまでの記録内容を範囲として電子署名を付加する（ステップＡ１２）。

　ここで、図１２および図１３を参照して、以上のようにプロセスサポートツール１０のタスク処理部１３によって処理結果情報が追記されていくメッセージ５６の一構成を説明する。

　図１２は、メッセージ５６に対する処理結果情報の追記手順の一例を説明するための概念図である。エリアｂ１の情報は、前タスク完了時に、前タスク処理者によって、次タスク情報として設定される。また、エリアｂ２は、最初のタスク処理者が電子署名を付す際の範囲例を示しており、エリアｂ３は、次のタスク処理者が電子署名を付す際の範囲例を示している。一方、図１３は、以上のような手順で処理結果情報が追記されていくメッセージ５６の一例を示す図である。

　次に、タスク処理部１３は、先に特定した次のタスクの処理者が他のユーザか否かを判定する（ステップＡ１３）。そして、他のユーザであれば（ステップＡ１３のＹＥＳ）、タスク処理部１３は、帰属許諾情報５３に基づき、当該他のユーザのプロセスサポートツール１０に対してメッセージ５６を送信する（ステップＡ１４）。

　一方、次のタスクの処理者であるユーザのプロセスサポートツール１０では、タスク処理部１３が、前タスクまでの処理者が付した電子署名と、帰属許諾情報５３に含まれる前タスクまでの処理者の公開鍵とから、当該メッセージ５６の正当性を検証すると共に（ステップＡ１５）、当該メッセージ５６に対応するプロセス５５の正当性を、当該プロセス５５に付された親の電子署名と、帰属許諾情報５３に含まれる親の公開鍵とから検証する（ステップＡ１６）。そして、このメッセージ５６の正当性および当該メッセージ５６に対応するプロセス５５の正当性の検証を経た後、タスク処理部１３は、前タスクの処理者によってメッセージ５６に追記された現タスクの処理を開始する（ステップＡ１７）。

　以下、前タスクの処理者（のタスク処理部１３）と同様、タスク処理部１３は、ステップＡ６からの処理を実施して、メッセージ５６への処理結果情報の追記等を実行する。そして、現タスクが最後のタスクであった場合（ステップＡ９のＹＥＳ）、タスク処理部１３は、処理結果情報に対して電子署名を付して、当該メッセージ５６に関する処理を終了させる（ステップＡ１８）。

　タスク処理部１３は、ユーザインタフェース部１４によって、メッセージ５６の一覧や、メッセージ５６の処理結果情報や進捗状況を、ユーザに提示することができる。

　メッセージ５６にはプロセスの処理結果の成果物としてｅ文書が生成される。図８Ａに示す「決裁」プロセスの場合、「起案者署名」タスクの「sign」で、佐藤一郎の電子署名した「起案日」、「件名」、「起案者」等からなるｅ文書「決裁書」が図１２の「（成果物であるｅ文書）」の場所に生成される。そして、この「決裁」プロセスでは、社員が電子署名した決裁書に課長、部長が電子署名を重ね、その後のタスクにより「件名」を付したファイル名としてタスク内で指定されたフォルダに格納される。

　流通する情報（利用許諾情報５４、帰属許諾情報５３、プロセス５５、メッセージ５６）は、全て電子署名により改ざんがないか検証され、正当な署名のないものや正しくないものに対しては処理を行わずエラーメッセージをユーザに通知する。

　ところで、図２に示したように、本ワークフローシステムにおいては、１つのプロセスサポートツール１０が複数のグループ１００に帰属することが可能である。そこで、本ワークフローシステムでは、メッセージ連携や他メッセージ生成により、異なるグループ１００間も含め、プロセスの連携を実現する。

　即ち、本ワークフローシステムでは、（自身が許可されている範囲内で）プロセス５５の立ち上げ（メッセージ５６の生成）をタスク処理部１３がプロセス５５内の１タスクとして行うための制御構文を設ける。また、自分が当番のメッセージ５６に対して、グループＩＤ、プロセスＩＤ、タスクＩＤ、メッセージＩＤ、変数の値等をもとに該当のメッセージ５６を検索またはメッセージ５６が到着するのを監視し、検出した場合に特定の処理を行うように制御構文に設定することもできる。

　検出対象のメッセージ５６がユーザ編集待ちのタスクの場合、当該タスクの編集対象変数への代入を自動処理するように制御構文に記述することも可能である。

　また、検出対象のメッセージ５６に対して、編集対象の変数を細分化するよう制御構文に設定することもできる。

　図１に示した例では、Ｓ社のＸ部サーバはグループ３、Ｎ社のＹ部サーバはグループ２にそれぞれ帰属し、これと同時に、各サーバは、グループ４にも帰属している。このような状況下で、この３つのグループ１００に属する各サーバ上において、グループ４のプロセス５５、グループ３のプロセス５５、グループ２のプロセス５５を連携させる一例を、図１４を参照しながら説明する。

　まず、Ｓ社（Ｘ部）－Ｎ社（Ｙ部）間のグループ４において「受発注」プロセスを定義したと想定する。この「受発注」プロセスは、Ｘ部のプロセスサポートツール１０、Ｙ部のプロセスサポートツール１０に対し、各社の担当者が編集項目を直接入力してタスクをすすめることもできるが、各社で独自のプロセスを連携させて、人手の介在する場所を減らすように改善している。即ち、Ｓ社ではグループ３で発注のための「発注管理」プロセスと「決裁」プロセスとを連携させ、Ｎ社ではグループ２で「受注処理」プロセスを連携させている。結果的に、Ｓ社での発注決裁起案から会社間の「受発注」プロセスを経てＮ社の「受注処理」プロセスまでグループ１００を跨ってプロセスが連携されている。

　この場合、Ｓ社Ｘ部は、グループ３において、（Ｓ社内における）発注のための決裁案件を管理する役割を担い、かつ、これを受けて、グループ４において、（Ｎ社に対して）発注書を発行する役割を担っており、一方、Ｎ社Ｙ部は、グループ４において、（Ｓ社からの）発注書を受領する役割を担い、かつ、これを受けて、グループ２において、（Ｎ社内における）「受注処理」プロセスを立ち上げる役割を担っている。

　まず、Ｓ社の社員Ｃが「発注管理」プロセスを立ち上げると、最初の「決裁プロセス生成」タスクが「決裁」プロセスを立ち上げる。これは社員Ｃの「決裁」プロセス立ち上げの許可が帰属許諾情報５３内に記載されていることが前提となる。

　次に、「編集項目細分化」タスクにより「決裁」プロセスの「起案」タスクにおけるユーザ編集項目「決裁内容」を、「契約目的」、「契約件名」、「契約金額」、「成果物」、「納期」、「甲」、「乙」、「契約先選定理由」に細分化する。この処理後の「決裁」プロセスの起案画面例は図１５の通りであり、図１１と同じプロセス、同じタスクにも関わらず、「決裁内容」が細分化されている（図１５のｃ１）。

　このように、基幹プロセス自体を変更することなく、「発注管理」プロセスのような枝プロセスを連携させることにより、プロセス全体を改善することができる。

　その後、「発注管理」プロセスはＸ部において「決裁書監視」タスクで、メッセージＩＤと決裁書内の変数値をキーにして当該決裁が承認されるのを監視する。決裁承認されたことを検出すると、「受発注プロセス生成」タスクで「受発注」プロセスを生成し、「発注書記入」タスクで決裁書から発注書へ必要な項目を転記する。なお、図１４では一定時間決裁書が検出されなかった場合の処理など、例外処理タスクは全て省略している。

　「受発注」プロセスは、「発注管理」プロセスに自動生成され、最初のタスクである「発注書発行」タスクに対して編集の必要な項目を全て「発注書記入」タスクにより自動設定されたことでタスクを完了し、「請書発行」タスクとしてＮ社Ｙ部へ転送される。

　Ｎ社Ｙ部では、予め立ち上げておいた「受注処理」プロセスが、「発注監視」タスクで「受発注」プロセスの到着を監視し、検出すると、「受注処理プロセス生成」タスクにより、後続の「受発注」プロセス監視のために別の「受注処理」プロセスを立ち上げ、自身は次の「発注内容転記」タスクで発注書から必要な情報を取得し変数に格納し、「請書発行」タスクで自分の担当する「受発注」プロセスの「請書発行」タスクに対し必要な編集項目を設定し、「受注処理」タスクに進む。

　なお、上記の流れにおいて、Ｎ社で「受発注」プロセスに「受注処理」プロセスを生成させず、「受発注」プロセスの到着を監視し検出した場合に「受注処理」のプロセスが流れるようにしているが、これは「受発注」プロセスがＮ社、Ｓ社にとどまらず多数の会社間で利用されており、仕様の変更ができない前提のためである。このような状況においても、基幹プロセスである「受発注」プロセスに枝プロセスである「受注処理」プロセスを連携でき、プロセス全体を改善できている。

　プロセス連携のしくみを説明する。メッセージ生成する旨記述されたタスクにより生成されたメッセージ５６や、制御構文に設定された条件で検出されたメッセージ５６は、そのメッセージＩＤが処理結果情報に標的メッセージとして記録され、以後のタスクで新たな標的メッセージが検出されるまで、または、実施者が変わるまで、タスク制御の際に標的メッセージとして扱われる。標的メッセージは＜標的メッセージ１＞、＜標的メッセージ２＞のように複数の標的メッセージを扱うことができる。

　制御構文内で、「標的メッセージ１（変数１）」のように指定することにより、自プロセス５５内の変数と同様に代入処理することができる。なお、代入処理が可能なのは、標的メッセージがユーザ編集待ちのタスクの場合である。

　他のメッセージ５６の標的となり必要な項目全てに値を設定された場合、設定されたらすぐそのタスクを完了とするのか、ユーザの再編集の余地を残すため完了にはユーザの能動的な意思表示を必要とするのかは、例えばプロセス５５の制御構文内にその旨記述することにより制御される。

　編集対象の変数を細分化するよう制御構文に設定されていたタスクを実行すると、細分化対象の変数（図１５の例では「決裁内容」）と子変数（図１５の例では「契約目的」、「契約件名」など）の定義情報が標的メッセージ側のその時点のタスクの処理結果情報に記録され、それ以降のタスクでユーザに編集を促したり設定された情報を表示する際は細分化された子変数が扱われる。

　検出された標的メッセージ側では検出した側のメッセージＩＤおよび「発火済」フラグがメッセージ内に設定され、再発火されない、即ち再度標的メッセージとして扱われることがないように制御される。

　検出する側のプロセス５５の制御構文に発火種別を設定し、それを「発火済」フラグとして記録することにより、当該プロセス５５の該当タスクに対しては再発火しないが、異なるプロセス５５やタスクからの発火は受けることも可能である。また、「発火済」フラグを設定しないで何度も再発火するような指定も可能である。

　なお、検出した側の標的メッセージの管理、および、検出された標的メッセージ側での発火元メッセージＩＤ、「発火済」フラグの管理は当番のユーザだけが管理しておけばいい情報なので、メッセージ内に記録するのでなく、メッセージ管理の付属情報として、プロセスサポートツール１０内で別途管理するようにしてもよい。

　このように、本ワークフローシステムでは、自分の担当するタスクをメッセージとして自分で管理しているため、現在一般的なサーバ型のワークフローシステムで必要であったシステム管理者への調整を図ることなく、担当する範囲において、プロセス連携による改善を自らの裁量で行うことができる。

　例えば、自分が親となって業務を分担させるメンバとグループを組み、自分の担当するタスクを実現するためのプロセスを新たに定義し連携させることで、タスクの細分化と委譲を図ることができる。これにより、例えば、本社で基幹プロセスを定義し、事業内容や事業展開している国情に応じて事業部で枝プロセスを追加定義し、取り扱っている業務内容や担当者の特性・スキルに応じて葉プロセスを追加定義するといったように、実際の組織構造や役割に対応してプロセスを階層化して定義し、連携させることで、全体として最適なプロセスを形成することができる。

　特定の担当者や部署で局所的なプロセス改善が行われ、よいプロセスであれば隣の部署へと次々と転用され、ついには「事業部の標準プロセスに組み込もう」「全社プロセスに組み込もう」という流れを日常業務に組み込むことができる。これにより、環境の変化にあわせたプロセスの進化が図れる。

　また、本ワークフローシステムは、Ｐ２Ｐ型でワークフローシステムを実現することにより、繋がりたいユーザ同士が当事者の裁量でグループを組んでプロセスを定義、連携できる。繋がりたい主体同士で次々と繋がることができることから、系全体として無限の収容能力を持ち無限のプロセス連携が可能と見なすこともできる。

　さらに、本ワークフローシステムでは、プロセスの処理結果や成果物をｅ文書として生成することもできるので、証憑・証跡の確認が容易となり、プロセス改善が格段に容易になる。また、証憑・証跡の階層化、転々流通が可能となり、他者の発行した保証書を添付して申請書を提出するなど、紙を利用してリアルの世界で行っていた転送・押印・添付・保管などのプロセスを同じ形態にて電子上で実現することができる。

　なお、本ワークフローシステムは、前述の実施形態で説明した内容に限定されず、種々の変形が可能である。

　ディレクトリサーバの利用等で必要な際に必要なメンバの公開鍵が容易に取得できる環境であれば、メンバ情報５１や帰属許諾情報５３でのメンバの公開鍵の保持は必須ではない。メッセージサイズとメッセージ処理時間のどちらを優先するかで選択してよい。

　メッセージ５６に加え、制御メッセージの送受信により、メッセージ送達確認や進捗通知、ユーザ制御情報伝達（プロセス中止、取り戻しなど）などが可能となる。

　メッセージ送信にあたっては、メッセージ５６内の全情報を送信する方式に加え、メッセージ５６本体は関連メンバからのアクセスが可能なサーバの共有フォルダやデータベースで管理し、保存場所とメッセージＩＤを含んだ当番通知のみ制御メッセージとして送信する方式もとれる。

　複数の類似プロセス５５内で、同一の「業務種別」を設定し、帰属許諾情報５３内では「業務種別」単位で許可プロセスを設定することも可能である。

　また、帰属許諾情報５３とプロセス５５とに、それぞれ世代番号、有効期間情報等を含めてもよい。情報に更新があった場合に、世代番号を大きくする。予約変更の場合、現情報に「終了時期」を追記した版と最新情報の版（開始時期を明記）との２情報を配布する。

　また、帰属許諾情報５３内で許諾しなくてもグループメンバの誰もが起票したり、グループメンバ以外のユーザが起票やタスクを担当できる一見ユーザ処理プロセスを定義することも可能である。その場合、該当タスクの処理の中で必要に応じて、当該メンバに対して当該プロセス５５内での役割を付与する。メンバ以外ユーザの場合、メッセージ５６へは、帰属許諾情報５３の代わりに利用許諾情報５４を添付する。これは処理結果情報への署名の検証用の公開鍵情報を流通するためである。ディレクトリサーバの利用等で必要な際に必要なユーザの公開鍵が容易に取得できる環境の場合やユーザの公開鍵が必要ない場合なども利用許諾情報５４の添付は必須ではない。処理結果への署名を不要とするプロセスを定義することも可能である。

　プロセス定義において役割の代わりに特定プロセスサポートツール１０のツールＩＤを設定することも可能である。

　図１におけるＸ部などの組織用のプロセスサポートツール１０へは、組織内の複数ユーザがログイン可能である。通常は最大でも１名がタスクの実行権限を与えられ、他のユーザは参照のみ可能である。参照権のみ与えられたユーザが作業を必要とする場合は、自分用のプロセスサポートツール１０で作業を行い、結果をプロセス連携するようなプロセスを定義して運用することにより内部統制を適切に保つことができる。

１…主催者Ｗｅｂサーバ、２…コンピュータ、１０…プロセスサポートツール、１１…グループメンバ管理部、１２…プロセス定義部、１３…タスク処理部、１４…ユーザインタフェース部、１５…通信処理部、１６…公開鍵暗号処理部、５０…データベース、５１…メンバ情報、５２…リンク情報、５３…帰属許諾情報、５４…利用許諾情報、５５…プロセス、５６…メッセージ、１００…グループ、Ａ…インターネット、Ｂ…ＬＡＮ。

Claims (11)

1. 　複数のタスクからなるプロセスを、１以上のコンピュータ上に搭載され、前記複数のタスクの中の少なくとも１つのタスクが割り当てられた複数のワークフローサポートプログラムによって順次に処理するワークフローシステムであって、
   　前記複数のワークフローサポートプログラムそれぞれが、
   　メンバとして帰属させるワークフローサポートプログラムそれぞれの役割を定義しつつグループを作成するグループ作成手段と、
   　各タスクを担当すべきメンバの役割を指定しつつ複数のタスクからなるプロセスを定義するプロセス定義手段と、
   　前記プロセス定義手段によって定義されたプロセス内のタスクを処理し、当該プロセスについての各タスクの処理結果および進捗状況を示す情報を含むメッセージを、次タスクを担当すべき役割が定義されたワークフローサポートプログラムに転送するプロセス処理手段と、
   　を具備し、
   　前記グループ作成手段によって作成されたグループ内において、前記プロセス定義手段によって定義されたプロセスを、当該プロセスに関するメッセージを前記複数のワークフローサポートプログラム間で順次に転送していくことによって処理することを特徴とするワークフローシステム。
2. 　前記グループ作成手段は、グループに帰属するメンバ毎に、そのメンバの当該グループ内におけるプロセスの処理に関する動作可能範囲および関連する他のメンバとの繋がりを定義した帰属情報を作成し、メンバとなったグループ内の他のワークフローサポートプログラムにそれぞれ提供する手段を含み、
   　前記プロセス処理手段は、前記帰属情報に基づき、前記プロセス内のタスクの処理の実行可否を判断し、かつ、前記メッセージの転送先を特定する手段を含む、
   　ことを特徴とする請求項１記載のワークフローシステム。
3. 　前記プロセス処理手段は、各タスクの処理結果および進捗情報を示す情報を前記メッセージ内に追記する手段を含むことを特徴とする請求項１または２記載のワークフローシステム。
4. 　前記プロセス定義手段は、定義したプロセスに関する情報を、前記グループ作成手段によってメンバとなったグループ内の他のワークフローサポートプログラムにそれぞれ提供する手段を含み、
   　前記プロセス処理手段は、前記プロセスに関する情報に基づき、前記プロセス内のタスクを処理する手段を含む、
   　ことを特徴とする請求項１、２または３記載のワークフローシステム。
5. 　前記複数のワークフローサポートプログラムそれぞれは、複数のグループにメンバとして帰属可能であり、かつ、他のワークフローサポートプログラムが前記グループ作成手段によって作成したグループにメンバとして帰属した状態において、自身の前記グループ作成手段によって新たなグループを作成可能であることを特徴とする請求項１記載のワークフローシステム。
6. 　前記プロセス定義手段は、１つのワークフローサポートプログラム上において、第１のプロセス内のタスクの処理として第２のプロセスを生成するための、異なるプロセスを生成するタスクを含むプロセスを定義可能であることを特徴とする請求項１記載のワークフローシステム。
7. 　前記プロセス定義手段は、１つのワークフローサポートプログラム上において、第１のプロセス内のタスクの処理として第２のプロセスにおいて実行されるべき処理を代行するための、異なるプロセスに関するメッセージを検出し、当該検出したメッセージに対する処理を実行するタスクを含むプロセスを定義可能であることを特徴とする請求項１記載のワークフローシステム。
8. 　前記プロセス処理手段は、前記プロセスの処理結果または成果物を、電子署名が付された電子文書として前記メッセージに添付する手段を含むことを特徴とする請求項１記載のワークフローシステム。
9. 　前記複数のワークフローサポートプログラムそれぞれは、
   　前記帰属情報、前記プロセスに関する情報、前記メッセージ内に追記する各タスクの処理結果および進捗情報を示す情報の少なくとも１つに対して電子署名を付し、または、他のワークフローサポートプログラムから受信したこれらの情報が改ざんされていないことをこれらの情報に付された電子署名によって検証する改ざん対策手段をさらに具備することを特徴とする請求項３記載のワークフローシステム。
10. 　ネットワークを介して接続される他の情報処理装置と協働して、複数のタスクからなるプロセスを処理する情報処理装置において、
    　メンバとして帰属させる情報処理装置それぞれの役割を定義しつつグループを作成するグループ作成手段と、
    　各タスクを担当すべきメンバの役割を指定しつつ複数のタスクからなるプロセスを定義するプロセス定義手段と、
    　前記プロセス定義手段によって定義されたプロセス内のタスクを処理し、当該プロセスについての各タスクの処理結果および進捗状況を示す情報を含むメッセージを、次タスクを担当すべき役割が定義された情報処理装置に転送するプロセス処理手段と、
    　を具備することを特徴とする情報処理装置。
11. 　ネットワークを介して接続される他の情報処理装置と協働して、複数のタスクからなるプロセスを処理するコンピュータを、
    　メンバとして帰属させるコンピュータそれぞれの役割を定義しつつグループを作成するグループ作成手段、
    　各タスクを担当すべきメンバの役割を指定しつつ複数のタスクからなるプロセスを定義するプロセス定義手段、
    　前記プロセス定義手段によって定義されたプロセス内のタスクを処理し、当該プロセスについての各タスクの処理結果および進捗状況を示す情報を含むメッセージを、次タスクを担当すべき役割が定義された情報処理装置に転送するプロセス処理手段、
    　として機能させるためのワークフローサポートプログラム。

Images