JP2005025578A - ワークフローシステム及びその実現方法 - Google Patents

Abstract

【課題】ユーザ管理やルート管理することなく適切なルーティングを行ことができ、管理者の負荷を最小にできる簡易ワークフローシステムを実現する
【解決手段】通信手段に電子メールシステムを用いるとすると、ワークフローシステム管理者は、公開鍵暗号発生装置１を用いて生成した公開鍵を申請者に渡し秘密鍵を承認者に渡す。申請者はクライアントマシン３で公開鍵により申請文書を暗号化し、電子メールで承認者のクライアントマシン４に送付する。承認者は、送付されたメールから文書を取り出して秘密鍵により復号化し、承認又は否認の操作を行う。この場合、申請者がフローのルートを知らなくても承認者にメールを送付できる方法として、１）ワークフローに関わる全員にメールを送付する。２）承認者の資格をもつ全員にメールを送付する。３）ワークフロー専用のメールアドレスを作成しそこに送付する、という方法がある。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワーク等の電子システム上で電子文書の申請・回覧・承認を行うワークフローシステム及びこのシステムを実現する方法に関するものである。
【０００２】
【従来の技術】
ワークフローシステムにおいては、フローの実行順をルーティングする。ルーティングにおいては、主にルート上で処理を行うユーザ（申請者、承認者、ワークフローシステム管理者、メイルシステム管理者等）の指定を行う。指定されるユーザは、ワークフローシステム内でその役割やアクセス権を管理していることが一般的である。
【０００３】
しかし、会社等の組織においては、退社・移動などの人事異動が頻繁に行われる。このような異動に応じてワークフローシステム内で管理しているユーザ情報やルーティング情報も適切に変更しなくてはならない。この変更は、Ｗｉｎｄｏｗｓ（Ｒ）等のＯＳやＮｏｔｅｓ（Ｒ）等のグループウェアのユーザ管理テーブルの取り込みや、ロールあるいはグループの設定によって多少は容易にはなるが、異動が頻繁だったり大規模だったりした場合には、ユーザ管理に関するワークフローシステム管理者の負荷はかなり高くなる。
【０００４】
また、申請者や承認者が、プリセットのルートを使用するのではなく、申請時や承認時に自らルーティングを行わなくてはならないこともある。人事異動が発生すると、申請者や承認者はそのたびにルート上にいたユーザに変更がないかを確認しなくてはならない。大規模なワークフローシステムでは専任の管理者がいて、システム情報の更新とユーザへの啓蒙を行ってくれるが、それほど複雑でないフローを扱う汎用的なワークフローシステムでは、専任の管理者を置くようなことはコスト的に見て難しい。
【０００５】
従来より、特定の伝票データを特定の担当者に対応する鍵を用いて暗号化、復号化することにより、処理時間を短縮できるようにした電子伝票処理方法が提案されている（例えば、特許文献１参照）。
また、データベースの人事情報をグループウェアのアドレス情報に反映することにより、システム管理者の負担を軽減しようにしたグループウェアのアドレス情報保守方法が提案されている（例えば、特許文献２参照）。
さらに、個人情報がシステムに管理されていない者を、承認者／閲覧者としてワークフローに組み込むことが可能なワークフロー管理システムが提案されている（例えば、特許文献３参照）。
【０００６】
【特許文献１】
特開平１１−１４９５１１号公報
【特許文献２】
特開２０００−２１５１５９号公報
【特許文献３】
特開２００１−２１６２２２号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、特許文献１では、伝票処理のルーティングは依然として管理されている必要があり、各フロー段階の担当者は、次が誰か知っている必要があるという問題があった。
また、特許文献２は、マスタデータベースからのユーザ情報のコピー方法を論じているもので、ユーザ情報管理そのものの簡素化を図るという問題については述べられていない。
また、特許文献３では、管理外とはいえ承認者／閲覧者を指定しなくてはならない、つまり、各段階の作業者がフローの少なくとも次の作業者を知っている必要があり、従って、人事異動によるルーティング変更などを把握しておかなくてはならないという問題があった。
【０００８】
本発明は上記の問題を解決するためのもので、ユーザ管理やルート管理をすることなく適切なルーティングを行うことができ、管理者の負荷が最小で済むような簡易ワークフローシステムを、最低限の構成セットで提供することを目的とするものである。
【０００９】
【課題を解決するための手段】
上記の目的を達成するために本発明によるワークフローシステムは、電子文書の申請・回覧・承認を電子システム上で行うワークフローシステムにおいて、申請電子文書を公開鍵暗号方式を用いて暗号化すると共に、申請電子文書の申請者と承認者間とを相手を特定しない電子的な通信手段で結ぶことを特徴とするものである。
【００１０】
また、本発明によるワークフローシステムは、電子文書の申請・回覧・承認を電子システム上で行うワークフローシステムにおいて、申請者が予め付与された公開鍵を用いて申請電子文書を暗号化する暗号化手段と、承認者が予め付与された秘密鍵を用いて暗号化された申請電子文書を復号化する復号化手段と、暗号化手段から暗号化された申請電子文書を復号化手段を含む１つ以上の宛先に送信する通信手段とを設けたことを特徴とするものである。
【００１１】
また、本発明によるワークフローシステムの実現方法は、電子文書の申請・回覧・承認を電子システム上で行うワークフローシステムの実現に際し、申請者に公開鍵を渡すと共に承認者に秘密鍵を渡すステップと、申請者が申請電子文書を公開鍵を用いて暗号化するステップと、暗号化された申請電子文書を秘密鍵を有する承認者を含む１つ以上の宛先に送信するステップと、承認者が申請電子文書を受け取り、これを秘密鍵を用いて復号化するステップと有することを特徴とするものである。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態を図面と共に説明する。
本実施の形態は、公開鍵暗号と対象を特定しない通信を利用することによって、ワークフローシステム内でユーザ管理をする必要もルート管理をする必要もなく、適切なルーティングを行ことができ、管理者の負荷が最小で済むような、簡易ワークフローシステムを最低限の構成セットでするものである。最低限の構成セットとするのは、システム構成が複雑になると管理者の負担も増えるためである。
【００１３】
また、ワークフローシステムでは、承認後に申請文書等の改竄が行われていないか証明できる方法が求められることがある。本実施の形態は、ユーザ管理に使用する公開鍵暗号をそのまま利用して、この機構を提供するものである。
【００１４】
図１は本発明の実施の形態によるワークフローシステムの構成例を示すブロック図である。
図１において、本ワークフローシステムは、公開鍵暗号発生装置１、サーバマシン２（後述するように、メールマサーバ又はファイルサーバとして用いられる共有サーバである）、申請用のクライアントマシン３、承認用のクライアントマシン４、及びこれらを接続するネットワーク５により構成される。
【００１５】
公開鍵発生装置１は、この図１のようにネットワーク５に接続されていても、接続されていなくてもよい。図２は公開鍵発生装置１がネットワーク５に接続されていないワークフローシステムの構成例を示す。
【００１６】
図３はネットワーク５に接続されている公開鍵発生装置１の構成例を示し、図４はネットワーク５に接続されていない公開鍵発生装置１の構成例を示す。
図３の公開鍵発生装置１は、キーボード等の入力装置１１、ＢＰＧＰソフトウェアのような公開鍵と秘密鍵を発生させる公開鍵暗号発生部１２及びネットワーク５に接続されるネットワークアダプタ１３を積んだマシンである。
【００１７】
図４の公開鍵発生装置１は、ネットワークアダプタ１３に代えて、フロッピー（Ｒ）ディスク等のリムーバブルディスク等を含む記憶媒体６のディスクドライバ、又（Ｒ）はＣＤ−ＲＷドライバ等の外部記憶媒体への書き込み装置１４を備えている。あるいは、両方のドライバを持っていてもよい。
【００１８】
公開鍵発生装置１がネットワーク５に接続されていない図２のワークフローシステムにおいては、図示のように記憶媒体６は、公開鍵発生装置１とサーバマシン２及びクライアントマシン４との間で書き込み装置１４を介して使用される。
【００１９】
申請用クライアントマシン３の構成例を図５に示す。
図５において、クライアントマシン３は、入力用キーボード３１、出力用ディスプレイ３２、ネットワークアダプタ３３、電子文書を編集するエディタ装置３４、暗号化・復号化を行う暗号装置３５、及びメール送受信装置３６又はファイル共有装置３６で構成される。あるいはメール送受信装置とファイル共有装置の両方を備えていてもよい。
尚、承認用クライアントマシン４は、クライアントマシン３と基本的に同じ構成のマシンを用いることができ、申請と承認を（同時にではないが）行うことも可能である。
【００２０】
サーバマシン２の構成を図６に示す。
図６において、サーバマシン２は、ストレージディスク２１、ネットワークアダプタ２２、及びメールサービス装置２３又はファイル共有サービス装置２３で構成される。あるいはメールサービス装置とファイル共有サービス装置の両方を備えていてもよい。サーバマシン２は、クライアントマシン３，４と物理的に必ずしも異なっている必要はない。
従って、サーバマシン２、二種類のクライアントマシン３，４は最低一台のマシンに集約可能である。公開鍵暗号発生装置１についても他のマシンとの集約は不可能ではないが、安全のために別立てとするのが望ましい。
【００２１】
次に、本発明の第１の実施の形態として、ワークフローシステムの通信手段として電子メールシステムを用いる場合の動作について説明する。
この場合は、クライアントマシン３，４では、メール送受信装置３６を主として用い、サーバマシン２では、メールサービス装置２３を主として用いる。このため以下の説明においては、サーバマシン２をメールサーバ２と称する。
また、ユーザは、申請者、承認者、ワークフローシステム管理者、メールシステム管理者の四つの役割に分けられる。ただし、各役割は排他ではなく、一人のユーザが複数の役割を持つ可能性がある。
【００２２】
ワークフローシステム管理者は、公開鍵暗号発生装置１を用いて公開鍵と秘密鍵を生成する。次に、ワークフローシステム管理者はフローのルーティングを設定する。設定は電子的にどこかに保存される必要はなく、ワークフローシステム管理者が申請者と承認者を決めて覚えているだけでよい。
【００２３】
予め申請者には公開鍵を渡し、承認者には秘密鍵を渡す。渡す方法としては、紙、フロッピー（Ｒ）ディスク、ＣＤ−ＲＯＭ等のメディアを使用する方法、共有ディスクや掲示板等の公開の場所に記載する方法、あるいは電子メールに直接記載する等の方法がある。
公開鍵は誰でも知っていて構わず、かついつでも参照できる必要があるので、公開の場所に置くことが望ましい。これに対して秘密鍵は扱いを慎重に行う必要があるので、図２のようにフロッピー（Ｒ）又はＣＤ−ＲＯＭ等のメディアを使用してワークフローシステム管理者から承認者に直接渡されるのが望ましい。
【００２４】
次に、申請者はクライアントマシン３を用いて公開鍵により申請文書を暗号化し、電子メールで承認者のクライアントマシン４に送付する。承認者は、送付されてきたメールから文書を取り出して秘密鍵により復号化し、承認又は否認の操作を行う。承認操作は、承認者の名前と日付、あるいは承認者の印影等を申請文書に記入する。
【００２５】
承認者が人事異動等でフローのルートから外れる場合には、承認者自らが後継者に対して秘密鍵を渡す。従って、承認者は人事異動等の影響を知っている必要があるが、一般的に承認者になるのは組織の長クラスの人間であって、人事異動の詳細とその影響について的確に把握していると考えてよい。また、自分の権限を引き継ぐ人間だけを知っていればよく、他の承認者の異動については考慮する必要がない。このように、承認者が自ら人事異動等のルート要素変更に対応するだけで、ワークフローシステム管理者やメールシステム管理者はユーザ及びルーティングを管理する必要がない。
【００２６】
申請者から承認者へメールを送付する際、承認者のアドレスを直接指定することも可能ではあるが、そのためには申請者がワークフローのルートを知っていなければならない。また人事異動の際にも、異動の影響を申請者自らが判定しなくてはならない。しかし、申請文書は公開鍵で暗号化されているので、秘密鍵を持っている承認者だけしか復号できない。このことを利用すれば、申請者がフローのルートを知らなくても承認者にメールを送付できる。送付する方法は以下の三つが考えられる。
１）ワークフローに関わる全員を宛先としてメールを送付する。
２）承認者の資格をもつ全員を宛先としてメールを送付する。
３）ワークフロー専用のメールアドレスを作成し、そこを宛先として送付する。
【００２７】
１）の方法は、申請者・承認者を問わず、ワークフロー利用者全てに申請者がメールを送付する方法である。承認する資格のないユーザにもメールが送付されるが、秘密鍵を持たないユーザでは復号できないので、承認操作はできない。ワークフロー利用者は部門すべてとか、会社すべてとかである場合が多く、メールアドレスがメールシステム管理者によって適切に管理されている状況であれば送付は簡単に行うことができる。ワークフローシステム管理者の手間は、最初を除けばほとんどない。
しかし、システム全体として見ると、人数が多い場合等にはメールを送る負荷が高くなり、また、申請が数多く発生する場合には、各人に送られるメールの量が多くなって業務の妨げとなる。従って、小規模な利用者で小量のフローに適した方式である。
【００２８】
２）の方法は、申請者がルートを知らないという前提があるので、承認者がすべて含まれるようなグループアドレスが必要になる。グループアドレスの管理はメイルシステム管理者が行うが、そのグループアドレスに含まれるべきユーザの選定はワークフローシステム管理者が行わなくてはならない。すなわち、人事異動のたびにワークフローシステム管理者がその影響を判定し、グループアドレスの作り直しをメールシステム管理者に依頼する必要があるため、メリットは少ない。
【００２９】
３）の方法は、ユーザ全員が参照できるメールアカウントを一つ以上用意し、そこに申請者は暗号化した申請文書を送付する。秘密鍵を持つ承認者がそのアカウントでメールを読み出し、復号化して承認操作を行う。ワークフローシステム管理者は、最初にアカウント作成依頼をメールシステム管理者に送るだけでよく、メールシステム管理者もアカウント作成後は手を入れる必要はあまりない。また、１）で見られるような業務への影響もない。一番望ましい方法である。
【００３０】
次に、３）における実際の操作例について説明する。
ここで、公開鍵暗号発生装置１は、図３のネットワークアダプタ１３と図４の書き込み装置１４によるフロッピー（Ｒ）ディスクドライブを持つものとする。
【００３１】
前準備
１．ワークフローシステム管理者はフローを定義する。ここで定義されるのは
・何をするためのフローか
・申請者は誰か
・承認者は誰か
・申請文書の様式
である。承認操作は一回で済むとは限らないし、各承認操作を行うのが一人だけとも限らない。
【００３２】
２．ワークフローシステム管理者は、公開鍵発生装置１を用いて公開鍵と秘密鍵を作成する。公開鍵は申請者すべてが参照できる共有フォルダの下へ置き、秘密鍵はフロッピー（Ｒ）ディスクに落として承認者に渡す。
３．ワークフローシステム管理者は、メールシステム管理者に依頼して、フロー用のメールアカウントを一つ作成してもらう。このアカウントは、全てのユーザがアクセス可能なように設定する。
【００３３】
申請
４．申請者は申請文書に必要事項を記入する。
５．申請者は公開鍵を取得する。
６．申請者は申請文書を公開鍵で暗号化する。
７．申請者は３．で作成したアカウント宛てに、６．で暗号化した申請文書を添付したメールを送付する。
【００３４】
承認
８．承認者は３．で作成したアカウントでメールサーバ２にアクセスする。
９．承認者はメールが来ている場合には、添付ファイルを取り出す。
１０．承認者は所持している秘密鍵をフロッピー（Ｒ）ディスクから取り出す。
１１．承認者は添付ファイルを復号化して申請文書を取り出す。
１２．承認者は申請文書の内容を確認し、承認か否認かを決定する。
１３．承認者は承認の場合には自らの印影を（電子的に）申請文書に付与する。
１４．承認者は承認されたことを示したメールを、１３．で印影を添付した申請文書（暗号化せずに）添付して申請者に送付する。
１５．承認者は否認の場合には否認されたことを示すメールを申請文書を添付せずに申請者に送付する。
【００３５】
ルートの変更
１６．ルートから外れる全ての承認者は、自らが持つ秘密鍵を後任者に渡す。
申請・承認は１４〜１５を繰り返す。フローを複数定義する場合には、１〜３を繰り返す。公開鍵と秘密鍵のペアは、フローごとに一組用意する必要がある（ただし承認者がまったく同じフローについては同じでもよい）。メールアカウントは一つでも構わないが、フローに応じて複数作成した方が使いやすい。
【００３６】
承認が何段階かある場合、つまり複数の承認者が順番に承認操作を行っていく場合には、１フローにつき公開鍵と秘密鍵のペアを承認者の数だけ用意する。申請者−承認者間の手順を、承認者１−承認者２、承認者２−承認者３、・・・の間にも適用し、それぞれ別の公開鍵・秘密鍵のペアで繋ぐ。この場合、申請者が使う公開鍵と同じように、各公開鍵は全ユーザに公開される。具体的には、以下のようになる。
申請者（公開鍵０）−（秘密鍵０）承認者１（公開鍵１）−（秘密鍵１）承認者２
【００３７】
後ろにまだ承認者がいる場合には、承認者の上記手順１４ は、
１４−１．承認者は１３．で印影を添付した申請文書を公開鍵で暗号化してメールに添付し、自分（ワークフロー専用アカウント）宛てに送付する。
となる。次の承認者は、８〜１４−１（又は１５）を繰り返す。最後の承認者は、８〜１４を実行する。ここで、最後の承認者は、自分が最後だと知っている必要がある。その情報は、ワークフローシステム管理者がルーティング後に秘密鍵を渡す際に該当する承認者に通知する。
さらに、ルートの変更が合った場合には、
１６．ルートから外れる全ての承認者は、自らが持つ秘密鍵と公開鍵を後任者に渡す。
【００３８】
次に、第２の実施の形態として、メールシステムに代えてファイルシステムを使用する場合の、上記メールシステムの場合との相違について説明する。この場合は、クライアントマシン３，４では、ファイル共有装置３６を主として用い、サーバマシン２では、ファイル共有サービス装置２３を主として用いる。このため以下の説明においてはサーバマシン２をファイルサーバ２と称する。
【００３９】
メールシステムで述べた１）、２）、３）のうち、ファイルシステムで実現できるのは２）と３）だが、特徴はメールシステムで述べたものと同じなので、３）のケースについてのみ考える。
ワークフローシステムは、メールサーバ２の代わりにファイルサーバ２が使用される。また、ユーザは、メイルシステム管理者の代わりにファイルシステム管理者となる。
【００４０】
前準備
１．２．は共通だが３．が異なる。
３．ワークフローシステム管理者はファイルシステム管理者に依頼して、フロー用のフォルダを一つ作成してもらう。このフォルダは、全てのユーザがアクセス可能なように設定する。
【００４１】
申請
４〜６は共通だが７．が異なる。
７．申請者は３．で作成したフォルダ宛の下に６．で暗号化した申請文書を置く。
【００４２】
承認
１０〜１３は共通だが、以下が異なる。
８．承認者は３．で作成したフォルダにアクセスする。
９．承認者は暗号化ファイルがフォルダの下にある場合にはファイルを取り出す。
１４．承認者は承認されたことを示すようにファイル名を変更して、１３．で印影を添付した申請書を（暗号化せずに）３．で作成したフォルダに置く。
１５．承認者は否認の場合には否認されたことを示すようにファイル名を変更して、申請書を３で作成したフォルダに置く。
１４−１．承認者は１３．で印影を添付した申請書を公開鍵で暗号化して、３．で作成したフォルダに置く。
【００４３】
次に、本発明の第３に実施の形態を説明する。本実施の形態は改竄を防ぐための電子署名に関するものである。
文書の改竄を防ぐための電子署名は、公開鍵を使用して行うことができる。申請者は公開鍵を、承認者は秘密鍵をすでに持っているので、これを使用して電子署名を行う。
【００４４】
前記第２の実施の形態でのメールシステムの場合で説明すると、承認の項が変わって、
１３．承認者は承認の場合には自らの印影を（電子的に）申請書に付与し、申請書から要約数を作成する。
１４．承認者は承認されたことを示したメールを、１３．で印影を添付した申請文書を（暗号化せずに）添付し、さらに要約数を添付して申請文者に送付する。
となる。
【００４５】
申請者は、この要約数を公開鍵で復号化し、自分ですることによっていつでも
・承認者の署名以来、申請書に変更がないこと
・承認したのは、承認者であること
を確認することができる。
【００４６】
承認が多段階にわたる場合には、以下のようになる。
申請者（公開鍵０）−（秘密鍵０）承認者１（公開鍵１）−（秘密鍵１）承認者２
というルーティングの場合、承認者２は公開鍵０を使って署名が正しいことを確認する。次に、承認者２が申請文書に印影を付けた時点で、承認者１の署名と要約数は無効となる。代わって承認者２が新たな要約数を作成し、これを申請者に送る。申請者は、公開鍵１を使用して署名の正当性を確認する。
【００４７】
次に、本発明と前述した従来の特許文献１，２，３とを比較検討する。
特許文献１は公開鍵方式で、特定の役職の人にそれぞれ復号キーを与えるというところと、伝票処理という一種のワークフローでそれをやっているというところに共通点がある。しかし、公開鍵方式使用の目的が、本発明ではルーティングのためであるのに対して、この特許文献１ではフロー内での情報の隠蔽となっている点が異なる。特許文献１では、伝票処理のルーティングはやはり管理されている必要があり、各フロー段階の担当者は、次が誰か知っている必要があるのに対し、本発明ではその必要はない。
【００４８】
特許文献２のグループウェアのアドレス情報の保守方法は、グループウェアシステム（ワークフローシステムを含む）において、ユーザ情報管理にかかる負荷軽減を目的としており、この目的は本発明と同じである。ただし、特許文献２では、マスタＤＢからのユーザ情報のコピー方法を論じているのに対して、本発明ではユーザ情報管理そのものの簡素化を行っている。
【００４９】
特許文献３のワークフロー管理システムは、ユーザ管理外のユーザをフローに取り込める。本発明との違いは、管理外とはいえ承認／閲覧者を指定しなくてはならないこと。つまり、各段階の作業者がフローの少なくとも次の作業者を知っている必要がある。従って、特許文献３では、人事異動によるルーティング変更などを把握しておかなくてはいけないのに対し、本発明ではその必要がない。
【００５０】
以上説明したように本発明の各実施の形態によれば、図１、図２のワークフローシステムにおいては、ワークフローシステム内でユーザとルーティングを管理する必要がないため、人事異動等のルーティング変更に対応することが容易な簡易ワークフローシステムを、最小限のシステム構成で実現できる。
【００５１】
特に、第１、第２に実施の形態によれば、システム内でユーザとルーティングを管理する必要がないため、人事異動等のルーティング変更に対応することが容易な簡易ワークフローシステムを実現できる。
また、第３に実施の形態によれば、ユーザ管理方法をそのまま電子承認に利用できるため、システムの単純化と管理の軽減が可能となる。
【００５２】
【発明の効果】
本発明によれば、公開鍵暗号方式と対象を特定しない通信手段を利用することにより、ワークフローシステム内でユーザ管理やルート管理することなく適切なルーティングを行ことができ、このため、管理者の負荷を最小にできる簡易ワークフローシステムを、最低限の構成セットで実現することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態によるワークフローシステムの構成例を示すブロック図である。
【図２】本発明の実施の形態によるワークフローシステムの他の構成例を示すブロック図である。
【図３】ワークフローシステムを構成する公開鍵発生装置の構成例を示すブロック図である。
【図４】ワークフローシステムを構成する公開鍵発生装置の他の構成例を示すブロック図である。
【図５】ワークフローシステムを構成するサーバマシンの構成例を示すブロック図である。
【図６】サーバマシンの構成図である。
【符号の説明】
１ 公開鍵発生装置
２ サーバマシン
３ 申請用クライアントマシン
４ 承認用クライアントマシン
５ ネットワーク
６ 記憶媒体
１１ 公開鍵発生部
１２ 入力装置
１３，２２ ネットワークアダプタ
１４ 書き込み装置
２３ メール送受信サービス装置及び／又はファイル共有サービス装置
３６ メール送受信装置及び／又はファイル共有装置

Claims (10)

1. 電子文書の申請・回覧・承認を電子システム上で行うワークフローシステムにおいて、
   申請電子文書を公開鍵暗号方式を用いて暗号化すると共に、申請電子文書の申請者と承認者間とを相手を特定しない電子的な通信手段で結ぶことを特徴とするワークフローシステム。
2. 前記申請者が公開鍵を持ち、承認者が秘密鍵を持ち、申請者は申請電子文書を公開鍵を用いて暗号化し、暗号化された申請電子文書を前記通信手段により送信し、承認者は通信手段から暗号化された申請電子文書を受け取り、これを秘密鍵を用いて復号化することを特徴とする請求項１記載のワークフローシステム。
3. 電子文書の申請・回覧・承認を電子システム上で行うワークフローシステムにおいて、
   申請者が予め付与された公開鍵を用いて申請電子文書を暗号化する暗号化手段と、
   承認者が予め付与された秘密鍵を用いて暗号化された申請電子文書を復号化する復号化手段と、
   暗号化手段から暗号化された申請電子文書を復号化手段を含む１つ以上の宛先に送信する通信手段とを設けたことを特徴とするワークフローシステム。
4. 前記承認者は、前記復号化された申請電子文書を承認する際、前記秘密鍵を用いて申請電子文書に電子署名を行い、前記申請者は、前記公開鍵を用いて承認後の申請電子文書書の電子署名を検証することを特徴とする請求項１から３のいずれか１項に記載のワークフローシステム。
5. 前記通信手段が、電子メールシステムであることを特徴とする請求項１から４のいずれか１項記載のワークフローシステム。
6. 前記通信手段が、電子ファイルシステムであることを特徴とする請求項１から４のいずれか１記載のワークフローシステム。
7. 前記通信手段は、ワークフローに関わる全員に前記暗号化された申請電子文書を送信することを特徴とする請求項１から６のいずれか１項記載のワークフローシステム。
8. 前記通信手段は、ワークフローに関わる承認者全員に前記暗号化された申請電子文書を送信することを特徴とする請求項１から６のいずれか１項記載のワークフローシステム。
9. 前記通信手段は、ワークフローにおける特定の宛先に前記暗号化された申請電子文書を送信することを特徴とする請求項１から６のいずれか１項記載のワークフローシステム。
10. 電子文書の申請・回覧・承認を電子システム上で行うワークフローシステムの実現に際し、
    申請者に公開鍵を渡すと共に承認者に秘密鍵を渡すステップと、
    申請者が申請電子文書を公開鍵を用いて暗号化するステップと、
    暗号化された申請電子文書を秘密鍵を有する承認者を含む１つ以上の宛先に送信するステップと、
    承認者が申請電子文書を受け取り、これを秘密鍵を用いて復号化するステップと有することを特徴とするワークフローシステムの実現方法。

Images