"ワークフロー処理を実行するワークフローサーバと、メールの送受信にかかる制御を行うメールサーバとがネットワークを介して通信可能な情報処理システムであって、クライアント端末から電子メールを受信するメール受信手段と、前記メール受信手段により受信された電子メールの送信先のうち、コピーメールを送信する宛先に指定されているメールアドレスを抽出する抽出手段と、コピーメールを送信する宛先に指定されているメールアドレスに対して承認依頼を行う指定がされているかを判定する判定手段と、前記判定手段により、承認依頼を行う指定がされていると判定した場合、承認依頼を行うメールアドレスを指定して、前記ワークフローサーバへ承認処理の要求を行う要求手段と、前記要求手段に応じて、前記ワークフローサーバからの承認処理の結果を受信する結果受信手段と、前記結果受信手段により受信した結果に応じて、メール送信にかかる制御を行うメール制御手段とを備えることを特徴とする情報処理システム。ワークフロー処理を実行するワークフローサーバとネットワークを介して通信可能な情報処理装置であって、クライアント端末から電子メールを受信するメール受信手段と、前記メール受信手段により受信された電子メールの送信先のうち、コピーメールを送信する宛先に指定されているメールアドレスを抽出する抽出手段と、コピーメールを送信する宛先に指定されているメールアドレスに対して承認依頼を行う指定がされているかを判定する判定手段と、前記判定手段により、承認依頼を行う指定がされていると判定した場合、承認依頼を行うメールアドレスを指定して、前記ワークフローサーバへ承認処理の要求を行う要求手段と、前記要求手段に応じて、前記ワークフローサーバからの承認処理の結果を受信する結果受信手段と、前記結果受信手段により受信した結果に応じて、メール送信にかかる制御を行うメール制御手段とを備えることを特徴とする情報処理装置。前記メール制御手段は、前記結果受信手段により受信した結果が承認された旨の結果である場合、前記メール受信手段により受信された電子メールを当該電子メールに指定されている宛先へ送信する制御を行い、一方、前記結果受信手段により受信した結果が否認された旨の結果である場合、前記メール受信手段により受信された電子メールを当該電子メールに指定されている宛先への送信を中止する制御を行うことを特徴とする請求項2に記載の情報処理装置。前記メール制御手段は、前記メール受信手段により受信された電子メールを当該電子メールに指定されている宛先へ送信する制御を行った場合、当該電子メールの送信元アドレスへ電子メールが送信された旨の電子メールを送信する制御を行い、一方、前記メール受信手段により受信された電子メールを当該電子メールに指定されている宛先への送信を中止する制御を行った場合、当該電子メールの送信元アドレスへ電子メールの送信が中止された旨の電子メールを送信する制御を行うことを特徴とする請求項2または3に記載の情報処理装置。前記判定手段は、前記メール受信手段により受信した電子メールの送信元アドレスについてコピーメールを送信する宛先に対して承認依頼を行う指定がされているかを判定することを特徴とする請求項2乃至4のいずれか1項に記載の情報処理装置。メールの送受信にかかる制御を行うメールサーバとネットワークを介して通信可能な情報処理装置であって、前記メールサーバを介してクライアント端末からメール本文と、メール本文の確認を依頼する確認者のメールアドレスと、確認者により確認が取れた後に送信するメールアドレスとを含む電子メールを受信するメール受信手段と、前記メール受信手段により受信された電子メールから、メール本文の確認を依頼する宛先に指定されているメールアドレスを抽出する抽出手段と、前記抽出手段により抽出されたメールアドレスに対して、前記メール本文と共に返信先のメールアドレスを含む電子メールを送信する第一の送信手段と、前記第一の送信手段により送信された電子メールに対して、確認者から前記返信先のメールアドレスに対して返信された電子メールを受信する返信メール受信手段と、前記返信メール受信手段により受信された電子メールの受信状況に応じて、メール本文の確認が取れた場合、前記確認者により確認が取れた後に送信するメールアドレスに、確認が取れたメール本文を送信する第二の送信手段とを備えることを特徴とする情報処理装置。ワークフロー処理を実行するワークフローサーバとネットワークを介して通信可能な情報処理装置における情報処理方法であって、クライアント端末から電子メールを受信するメール受信ステップと、前記メール受信ステップにより受信された電子メールの送信先のうち、コピーメールを送信する宛先に指定されているメールアドレスを抽出する抽出ステップと、コピーメールを送信する宛先に指定されているメールアドレスに対して承認依頼を行う指定がされているかを判定する判定ステップと、前記判定ステップにより、承認依頼を行う指定がされていると判定した場合、承認依頼を行うメールアドレスを指定して、前記ワークフローサーバへ承認処理の要求を行う要求ステップと、前記要求ステップに応じて、前記ワークフローサーバからの承認処理の結果を受信する結果受信ステップと、前記結果受信ステップにより受信した結果に応じて、メール送信にかかる制御を行うメール制御ステップとを備えることを特徴とする情報処理方法。メールの送受信にかかる制御を行うメールサーバとネットワークを介して通信可能な情報処理方法であって、前記メールサーバを介してクライアント端末からメール本文と、メール本文の確認を依頼する確認者のメールアドレスと、確認者により確認が取れた後に送信するメールアドレスとを含む電子メールを受信するメール受信ステップと、前記メール受信ステップにより受信された電子メールから、メール本文の確認を依頼する宛先に指定されているメールアドレスを抽出する抽出ステップと、前記抽出ステップにより抽出されたメールアドレスに対して、前記メール本文と共に返信先のメールアドレスを含む電子メールを送信する第一の送信ステップと、前記第一の送信ステップにより送信された電子メールに対して、確認者から前記返信先のメールアドレスに対して返信された電子メールを受信する返信メール受信ステップと、前記返信メール受信ステップにより受信された電子メールの受信状況に応じて、メール本文の確認が取れた場合、前記確認者により確認が取れた後に送信するメールアドレスに、確認が取れたメール本文を送信する第二の送信ステップとを備えることを特徴とする情報処理方法。ワークフロー処理を実行するワークフローサーバとネットワークを介して通信可能な情報処理装置において実行可能なプログラムであって、クライアント端末から電子メールを受信するメール受信手段、前記メール受信手段により受信された電子メールの送信先のうち、コピーメールを送信する宛先に指定されているメールアドレスを抽出する抽出手段、コピーメールを送信する宛先に指定されているメールアドレスに対して承認依頼を行う指定がされているかを判定する判定手段、前記判定手段により、承認依頼を行う指定がされていると判定した場合、承認依頼を行うメールアドレスを指定して、前記ワークフローサーバへ承認処理の要求を行う要求手段、前記要求手段に応じて、前記ワークフローサーバからの承認処理の結果を受信する結果受信手段、前記結果受信手段により受信した結果に応じて、メール送信にかかる制御を行うメール制御手段ととして前記情報処理装置を機能させることを特徴とするプログラム。請求項9に記載のプログラムをコンピュータ読み取り可能に記録した記憶媒体。メールの送受信にかかる制御を行うメールサーバとネットワークを介して通信可能な情報処理装置において実行可能なプログラムであって、前記メールサーバを介してクライアント端末からメール本文と、メール本文の確認を依頼する確認者のメールアドレスと、確認者により確認が取れた後に送信するメールアドレスとを含む電子メールを受信するメール受信手段、前記メール受信手段により受信された電子メールから、メール本文の確認を依頼する宛先に指定されているメールアドレスを抽出する抽出手段、前記抽出手段により抽出されたメールアドレスに対して、前記メール本文と共に返信先のメールアドレスを含む電子メールを送信する第一の送信手段、前記第一の送信手段により送信された電子メールに対して、確認者から前記返信先のメールアドレスに対して返信された電子メールを受信する返信メール受信手段、前記返信メール受信手段により受信された電子メールの受信状況に応じて、メール本文の確認が取れた場合、前記確認者により確認が取れた後に送信するメールアドレスに、確認が取れたメール本文を送信する第二の送信手段として前記情報処理装置を機能させることを特徴とする情報処理装置。請求項11に記載のプログラムをコンピュータ読み取り可能に記録した記憶媒体。しかしながら、特許文献1に記載の技術では、稟議メールを受信して稟議の内容を確認すべきユーザの順番を指定する必要があるため、通常のメール操作の手順とは別に、承認を受けるユーザの指定を行うという新たな操作負担が増えることとなる。そこで、本発明は、上記課題を解決するものであり、簡易な操作手順で、メール内容について承認依頼を可能とする技術を提供する。本発明は、ワークフロー処理を実行するワークフローサーバと、メールの送受信にかかる制御を行うメールサーバとがネットワークを介して通信可能な情報処理システムであって、クライアント端末から電子メールを受信するメール受信手段と、前記メール受信手段により受信された電子メールの送信先のうち、コピーメールを送信する宛先に指定されているメールアドレスを抽出する抽出手段と、コピーメールを送信する宛先に指定されているメールアドレスに対して承認依頼を行う指定がされているかを判定する判定手段と、前記判定手段により、承認依頼を行う指定がされていると判定した場合、承認依頼を行うメールアドレスを指定して、前記ワークフローサーバへ承認処理の要求を行う要求手段と、前記要求手段に応じて、前記ワークフローサーバからの承認処理の結果を受信する結果受信手段と、前記結果受信手段により受信した結果に応じて、メール送信にかかる制御を行うメール制御手段とを備えることを特徴とする。本発明によれば、簡易な操作手順で、メール内容について承認依頼が可能となる。以下、本発明の実施形態について図面を基に説明する。図1は、本発明における電子メールシステムウェブメールシステムの構成の一例を表す図である。図1において電子メールシステムは、ウェブメールサーバ101と、ワークフローサーバ102と、メールを送信するユーザが使用するクライアント端末103がネットワーク100を介して接続可能な状態にある。本発明でいうウェブメールとは、クライアント端末103のウェブブラウザで利用することができる電子メールシステムのことを指す。受信したメールの閲覧や、新規メッセージの作成送信などをウェブブラウザのみで行なうことができる。クライアント端末にメールソフトをインストールしてメールの送受信を管理する電子メールシステムとは異なり、すべてのメール送受信をサーバ側で管理するため、ユーザは、ウェブブラウザを用いることでどこにいてもメールの作成、受信、閲覧を行うことが可能である。ウェブメールサーバ101は、ユーザアカウント毎のメール使用を記憶管理する。ワークフローサーバ102は、電子メールから起案された案件をワークフローの流れに乗せて処理するサーバである。クライアント端末103は、ユーザ操作によりウェブブラウザを用いて本発明の電子メールシステムへアクセスをする。本図1では、ウェブメールサーバ101及びワークフローサーバ102が別個の筐体で示されているが、同一筐体内に構成することも可能であり、本発明に係る電子メールシステムを運用する形態に応じて各種構成をとることが可能である。次に、図2を用いて、図1に示したウェブメールサーバ101ワークフローサーバ102を含む。のハードウェア構成について説明する。図2は、ウェブメールサーバ101に適用可能な情報処理装置のハードウェア構成例を示すブロック図である。なお、図2のブロック図はワークフローサーバ102及び、クライアント端末103にも適用可能である。図2に示すように、ウェブメールサーバ101は、システムバス204を介してCPUCentralProcessingUnit201、RAMRandomAccessMemory203、ROMReadOnlyMemory202、入力コントローラ205、ビデオコントローラ207、メモリコントローラ207、通信I/Fコントローラ208等が接続された構成を採る。CPU201は、システムバス204に接続される各デバイスやコントローラを統括的に制御する。また、ROM202あるいは外部メモリ211には、CPU201の制御プログラムであるBIOSBasicInput/OutputSystemやOSOperatingSystemや、各サーバあるいは各PCが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。RAM203は、CPU201の主メモリ、ワークエリア等として機能する。CPU201は、処理の実行に際して必要なプログラム等をROM202あるいは外部メモリ211からRAM203にロードし、ロードしたプログラムを実行することで各種動作を実現する。また、入力コントローラ205は、キーボードKB209や不図示のマウス等のポインティングデバイス等からの入力を制御する。ビデオコントローラ206は、ディスプレイ210等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。メモリコントローラ207は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置ハードディスクHDや、フレキシブルディスクFD、あるいは、PCMCIAPersonalComputerMemoryCardInternationalAssociationカードスロットにアダプタを介して接続されるコンパクトフラッシュ登録商標メモリ等の外部メモリ211へのアクセスを制御する。通信I/Fコントローラ208は、ネットワーク例えば、図1に示したネットワーク100を介して外部機器と接続通信し、ネットワークでの通信制御処理を実行する。例えば、TCP/IPTransmissionControlProtocol/InternetProtocolを用いた通信等が可能である。尚、CPU201は、例えばRAM203内の表示情報用領域へアウトラインフォントの展開ラスタライズ処理を実行することにより、ディスプレイ210上に表示することが可能である。また、CPU201は、ディスプレイ210上のマウスカーソル図示しない等によるユーザ指示を可能とする。本発明を実現するための後述する各種プログラムは、外部メモリ211に記録されており、必要に応じてRAM203にロードされることによりCPU201によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイルおよび各種情報テーブル等も、外部メモリ211に格納されており、これらについての詳細な説明についても後述する。次に、一般ユーザが通常のメール送信を行う一連の操作において、メールの内容について承認を受ける処理の流れを図3~7を用いて説明する。図3は、本発明の実施の形態における承認ワークフローを経てメールを送信する処理の流れを示すフローチャートである。まず、一般ユーザは、クライアント端末を操作し、メールを送信する操作を行う。S301において、クライアント端末は、ユーザの指示に従って、ウェブブラウザを起動する。S302において、クライアント端末は、ウェブメールサーバへメール作成画面を要求する。なお、ユーザを識別する場合は、ログイン処理を行った後、この処理が実行される。S303において、ウェブメールサーバは、要求を受け付ける。S304において、ウェブメールサーバは、メール作成画面情報を送信する。S305において、クライアント端末は、メール作成画面情報を受信する。S306において、クライアント端末は、メール作成画面情報を用いて、メール作成画面をブラウザに表示する図4。図4は、メール作成画面の例を示す図である。ユーザは、宛先401に送信先のアドレスを入力する。また、必要に応じて、Cc欄402、Bcc欄403にアドレスの指定を行う。その他、ユーザは、件名404にメールのタイトルを、本文405にメールの本文を入力するS307。最後に、送信ボタン406を押下することで、クライアント端末へ、メールの送信指示を行うS308。なお、通常のメールの仕組みにおいて、宛先は、本来メールを送る宛先Toを示すものであり、CcCarbonCopyやBccBlindCarbonCopyは、本来メールを送る宛先以外に、同じ内容のメールを送りたい場合に指定する宛先である。本実施の形態では、このCcやBccに指定したアドレスに対して、承認依頼を送ることができるため、ユーザが新たな操作を覚える必要がなくなる。そこで、本実施の形態において、承認がなされた後にメールが送信されることとなるToに指定する宛先を第一の宛先と呼び、一方、Toに指定された宛先に送る前に、メール本文の内容について承認依頼を送ることとなるCcやBccに指定する宛先を第二の宛先と呼ぶものとする。通常、第二の宛先は、第一の宛先へ送信するメール本文のコピーメール控えメールともいうを送信する宛先として使われるが、本実施の形態では、直ちに、メールを送信するのではなく、第二の宛先に対する承認ワークフローが開始され、承認後に第一の宛先にメールが送信されることとなる。例えば、ユーザは、Bccに指定したアドレスに承認メールが送信されることを知っていれば、Bccに上司のメールアドレスを設定してメールを送信するだけで承認のワークフローが流れることとなる。S309において、ウェブメールサーバは、クライアント端末から、送信メールを受信する。S310において、ウェブメールサーバは、CcまたはBccの宛先指定がなされているか判定する。Yesの場合、S311へ進み、Noの場合、S319へ進む。S311において、ウェブメールサーバは、ワークフロー指定があるか判定する。Yesの場合、S312へ進み、Noの場合、S319へ進む。ここで、ワークフロー指定を判定する方法として、ウェブメールサーバにおいて、予め設定ファイルを用意しておき、その設定ファイルの内容に従って判定する方法と、クライアント端末から送信されるメールにワークフロー指定がなされているかにより判定する方法の2つの方法がある。まず、ウェブメールサーバにおいて、予め設定ファイルを用意しておき、その設定ファイルの内容に従って判定する方法を説明する。設定ファイルは、管理者が用意するものであり、例えば、図5に設定ファイルの一例を示す。設定ファイル501は、全てのユーザのメールに対して適用可能な設定ファイルの例である。この例では、bccに指定されている宛先に承認依頼を送るという内容となっている。従って、CcとBccに宛先指定されている場合、Bccに宛先のみ、承認依頼を送ることとなる。なお、上述した通り、承認がなされた後にメールが送信されることとなるToに指定する宛先を第一の宛先と、承認依頼を送ることとなるCcやBccに指定する宛先を第二の宛先と呼ぶものとしたが、この設定では、Bccの宛先のみに、承認依頼が送られることとなるため、Bccに指定された宛先が第二の宛先となる。一方、設定ファイル502は、任意のユーザのメールに対して適用可能な設定ファイルの例である。この例では、送信元アドレスがsuzukikannon-js.comというユーザから送信されたメールについて、CcとBccに指定されている宛先に承認依頼を送るという内容となっている。ここでは、CcとBccに指定されている宛先に承認依頼を送ることなるため、CcとBccに指定されている宛先は、第二の宛先となる。いずれの設定ファイルを利用するかは、ウェブメールサーバを利用するユーザのセキュリティポリシー等に従って自由に決めることができる。次に、クライアント端末から送信されるメールにワークフロー指定がなされているかにより判定する方法を説明する。これは、ユーザがメールを作成する際、明示的に、CcやBccの宛先に承認依頼を送る指定がなされているかにより判定を行うものである。実現方法として、例えば、CcやBccを指定する際に、承認依頼を送るかユーザに確認する画面で指定を促したり、メール送信時に、CcやBccに指定されている宛先から承認依頼を行う任意のアドレスを指定させてもよい。また、指定された内容は、メールのヘッダ情報に埋め込むことで、ウェブメールサーバは、指定された内容を識別することが可能となる。この実現方法の場合、承認依頼先として指定された宛先が第二の宛先となる。続いて、ウェブメールサーバからワークフローサーバへ承認依頼を送る流れを説明する。S312において、ウェブメールサーバは、ワークフローサーバへワークフロー処理を要求する。この際、承認依頼を行うCcやBccに指定されたアドレス情報も通知する。S313において、ワークフローサーバは、ワークフロー処理要求を受け付ける。S314において、ワークフローサーバは、ワークフロー処理を実行する。本処理の詳細は、図6のフローチャートを用いて説明する。図6は、ワークフロー処理の詳細な処理の流れを示すフローチャートである。S601において、ワークフローサーバは、ワークフローの登録を行う。具体的には、ウェブメールサーバから承認依頼を受けたメールをワークフロー案件としてデータベースへ登録を行う。S602において、ワークフローサーバは、承認者を抽出する。具体的には、承認依頼を行う、承認者のメールアドレスを抽出する。このメールアドレスは、ウェブメールサーバからの承認依頼時に通知されているものである。S602において、ワークフローサーバは、抽出された宛先に対して、承認依頼のメールを送信する。ここで、抽出された宛先へ送信する方法として、複数の方法を取ることができる。1指定された順番に送信する方法例えば、Bccに、宛先a、宛先b、宛先cの順に指定されている場合、a→b→cの順に送信する。また、CcとBccの両方に承認依頼を送る場合は、さらにCc→Bccの順に送信する。この方法は、全ての人から承認を得る必要がある場合に有効である。2指定された宛先に同時に送信する方法例えば、承認先に、宛先a、宛先b、宛先cの指定がされている場合、a、b、cへ同時に送信する。この方法は、同じ承認権限を持つa、b、cの中の誰かに承認を得ることができればよい場合に有効である。31と2を組み合わせた方法例えば、Ccの宛先は、同時に送信し、Bccの宛先は、順番に送信する。1と2を組み合わせることで、より高度な承認依頼を実現することが可能となる。承認依頼方法は、管理者がワークフローサーバへ予め設定しておいても良いし、メール送信者がメール送信時に指定をしても良い。メール送信時に指定する場合、メールのヘッダに指定内容を埋め込むことで、ウェブメールサーバを介してワークフローサーバは指定内容を知ることができる。さらに、ウェブメールサーバに指定方法を設定しておくことで、S312の処理において、ワークフローサーバへ指定しても良い。次に、承認依頼を受けたユーザの操作の流れを説明する。S604において、ウェブメールサーバは、承認依頼メールを受信する。承認依頼を受けたユーザは、メール受信画面から承認依頼メールを確認することができる。図7は、承認依頼メールの一例を示す図である。承認依頼メールは、受信トレイ701に通常のメールと共に受信している702。そして、承認依頼メールを選択すると703のような文面が表示される。この例では、送信日時2010年11月11日14時45分に差出人suzukikannon-js.comにより送信されたメールについての承認依頼であることを示している。また、送信しようとしている内容は、件名お見積りの件として、宛先yamdaabc.co.jpへ、見積りについてのメールを送ることを確認することができる。承認依頼を受けたユーザは、内容について承認する場合は、704の宛先へ、否認する場合は705の宛先へメールを返信することにより、承認依頼に対する応答をするS605。S606において、ワークフローサーバは、承認依頼をしたユーザからのメールを受信する。S607において、ワークフローサーバは、結果が承認であるかを判定する。Yesの場合、S608へ進み、Noの場合、S610へ進む。ここで、判定は、受信したメールの宛先が承認用の宛先で受信したか、否認用の宛先で受信したかにより判定を行う。S608において、ワークフローサーバは、承認依頼をすべき全てのユーザに対して承認依頼メールを送信したかを判断する。Yesの場合、S609へ進み、Noの場合、S602へ戻る。なお、承認依頼をすべきユーザは、S602において、承認依頼者を抽出する際に、決定されている。また、送信する順序は、任意の方法を取ることができる。S609において、ワークフローサーバは、承認処理を行う。具体的には、ウェブメールサーバへ通知する承認である旨の通知の準備と、データベースへ登録したワークフロー案件において承認依頼者毎に承認または否認である旨が追記される。また、S609において、ワークフローサーバは、否認処理を行う。具体的には、ウェブメールサーバへ通知する否認である旨の通知の準備と、データベースへ登録したワークフロー案件において承認依頼者毎に承認または否認である旨が追記される。以上、図6を用いて、ワークフロー処理の詳細な処理の流れを説明した。ここで、図3の説明へ戻る。S315において、ワークフローサーバは、結果承認もしくは否認をウェブメールサーバへ通知する。S316において、ウェブメールサーバは、結果を受信する。S317において、ウェブメールサーバは、受信した結果が承認であるかを判定する。Yesの場合、S319へ進み、Noの場合、S318へ進む。S318において、ウェブメールサーバは、メールの送信を中止する。この際、本メールの送信者に、送信しようとしていたメールの送信が否認された旨の内容が記載される否認メールを送っても良い。否認メールを受信することで、ユーザは、送信メールが送信されなかったことを知ることができる。一方、S319において、ウェブメールサーバは、指定された宛先へメールを送信する処理を行う。この際、宛先として指定されている全ての宛先CcやBcc含むへメールを送信しても良いし、ワークフロー処理により承認依頼を行ったCcやBccに指定されていた宛先を除いて送信しても良い。さらに、本メールの送信者に、送信しようとしていたメールの送信が承認された旨の内容が記載される承認メールを送っても良い。承認メールを受信することで、ユーザは、送信メールが実際に送信されたことを確認することができる。以上、図3~7を用いて、一般ユーザが通常のメール送信を行う一連の操作において、メールの内容について承認を受ける処理の流れを説明した。上述した通り、本発明によれば、簡易な操作手順で、メール内容について承認依頼が可能となる。つまり、ユーザは、通常のメール操作と同じように、CcやBccに宛先を指定してメール送信をするだけで、メール内容についての承認ワークフローが流れるため、ユーザの操作負担が増えることはない。また、承認依頼を受けたユーザも、承認依頼メールに記載の承認または否認の宛先へメールを送信するだけで済むため、こちらも新たなユーザの操作負担が増えることもない。次に、本発明の第二の実施の形態を、図8~14を用いて説明する。第一の実施の形態においては、通常のメール操作と同様に、CcやBccに宛先を指定してメール送信をするだけで、メール内容についての承認ワークフローが流れるため、ユーザの操作負担が増えることはないという効果はあった。しかしながら、CcやBccに宛先を指定するのではなく、ユーザに明示的に確認を求める人確認者を指定させる方がよい場合もある。例えば、CcやBccに宛先を指定してワークフローを開始させる方法に慣れていないユーザにとっては、明示の指定をさせた方が分かり易いこともある。そこで、第二の実施の形態では、ユーザに明示的に確認者を指定させ、第一の実施の形態と同様に確認ワークフローを流し、その確認ワークフローが終了し場合に、確認がなされたメールを所定のメールアドレスに送信させることとする。従って、本発明の第二の実施の形態は、ワークフローサーバが、確認者として指定されたユーザに対して確認依頼のメールを送付し、確認が取れた場合に、指定された宛先にメールを送付するというものである。また、確認依頼中に、確認の依頼を行った者は、ワークフローサーバで管理されている確認の進捗状況を参照することができる。更には、確認の依頼を撤回したり消去したりすることもできる。図8は、本発明の第二の実施の形態における確認依頼を行う画面の一例である。本実施の形態では、通常のメール作成画面とは別の画面として用意されているものとしている。ユーザは、確認依頼801を選択することで確認依頼画面を表示することになる。そして、確認依頼を行いたいユーザの宛先を選択する。具体的には、確認者ボタン802が選択されると宛先指定画面が表示され、その画面を介して確認依頼者の宛先が選択される。ここでは、宛先としてメールアドレスが選択される。依頼者欄803には、確認依頼を行うユーザのメールアドレスが指定されている。また、確認者欄804には、選択された確認依頼を行うユーザのメールアドレスが指定されている。件名805には、確認を行ってもらいたいメールの件名が記載されている。本文欄806には、確認を行ってもらいたいメール本文が記載されている。この例では、依頼者suzukikannon-js.comが、確認者takahashikannon-js.comに対して、件名お見積りの件、本文○○会社ヤマダ様の内容を確認してもらいたいことを示している。次に、依頼者をするユーザは、確認を依頼するボタン807を押下する。すると、図9に示すウィンドウが表示されることとなる。このウィンドウにおいて、依頼者は、確認後、自動的に以下の宛先へ送信する901のオプションを指定することができる。このオプションを指定することで、宛先欄902へアドレスの入力が可能となる。この例では、yamdaabc.co.jpが指定されている。従って、確認を依頼する高橋太郎takahashikannon-js.comによりメール本文の内容の確認がなされた場合は、件名本文の内容をyamdaabc.co.jpに送信することとなる。最後に、ユーザは、依頼する場合、依頼するボタン903を、キャンセルする場合、戻るボタン904を押下する。依頼するボタンが押下されることにより処理が開始されることとなる。次に、図10を用いて、依頼者が確認の依頼を行った確認の進捗状況を確認する画面を説明する。依頼を行ったユーザは、進捗状況の管理を行っているサーバへログインする。本実施の形態では、ワークフローサーバにおいて管理されているものとしているためワークフローサーバへログインする。ここでは、ブラウザを介してログインする例で説明を行う。1001は、ログイン後のブラウザの一例である。1002に、進捗状況の画面が表示される。この例では、件名1003、更新日1004、返信1005、確認者1006を参照することができる。1レコード目は、件名お見積りの件が、更新日2011-05-1212:00の時点で、返信が1件のうち0件であることを示している。2レコード目は、件名ご都合はいかがでしょうかが、更新日2011-04-2115:30の時点で、返信が2件のうち2件あり、確認者が渡辺花子、他1名であることを示している。なお、それぞれの件名は、ハイパーリングにより詳細な内容を参照でいるようになっているため、ユーザは、参照したい件名を、マウス等を用いてクリックする。図11は、詳細内容を参照する画面の一例である。詳細内容が1102の画面内に表示される。1103に件名が表示される。この例では、図10において件名お見積りの件が選択されたものを示している。1103には、更新状況1104、返信状況1105、自動送信1106、撤回ボタン1107、消去ボタン1108が表示される。更新状況1104は、いつこの情報が更新されたかが示される。返信状況1105は、何件のうち何件の返信があったかの状況が示される。自動送信1106は、図9に示す画面で、確認後、自動的に以下の宛先へ送信する901のオプションが指定されている場合、ありと表示されるものである。撤回ボタン1107は、この確認メールの回覧を中止する場合に押下するボタンである。なお、回覧は中止されるが、データの消去は行わないため、後から内容の確認をすることができる。消去ボタン1108は、この確認メールを消去する場合に押下するボタンである。このボタンが押下されるとデータが消去されるため、後から内容の確認をすることができなくなってしまう。また、1109に本文の内容が、1110に添付ファイルの内容が、1111に確認を依頼した者の名前が表示されることを示している。次に、図12~14を用いて、図8~11の画面が表示される処理の流れを説明する。図12~13は、図8~9の画面が表示され、メールが送信されるまでの処理の流れを示すフローチャートである。図12において、図3と同じ処理については、同じステップ番号を付している。なお、そのステップについては説明を省略する。S1201から説明を行う。S1201において、クライアント端末は、確認依頼画面を表示する。具体的には、図8に示す画面において、ユーザに確認依頼タブ801が選択されることにより、図8に示す画面が表示されるものである。S1202において、クライアント端末は、確認文の作成を受け付ける。具体的には、図8に示す本文欄806に文書が入力されることである。S1203において、クライアント端末は、確認者の指定を受け付ける。具体的には、図8に示す確認者802を介して、確認者欄804に指定を受け付けることである。S1204において、クライアント端末は、ワークフローサーバに対して、確認依頼を行う。具体的には、図9に示す依頼するボタン903が押下されることにより、この依頼が行われる。S1205において、ワークフローサーバは、確認依頼を受け付ける。S1206において、ワークフローサーバは、ワークフロー処理を行う。ここで行う、ワークフロー処理は、確認者として指定されたユーザに対して確認メールを送信し、確認がとれたかどうかの結果を得る処理である。この処理の詳細を、図13を用いて説明する。S1301において、ワークフローサーバは、ワークフロー登録を行う。具体的にはワークフローサーバが管理する記録媒体に、新たなワークフローとして登録を行う。ワークフローの登録が行われることで、依頼を行ったユーザは、図10~11に示す画面で進捗状況の確認が行えるようになる。S1302において、ワークフローサーバは、確認者の抽出を行う。複数存在する場合は、その数だけ抽出を行う。ここでは、確認者として指定されたメールアドレスの抽出を行う。S1303において、ワークフローサーバは、確認依頼のメールを送信する。確認依頼のメールは、図7に示すメールのように、確認をしてもらいたい本文の内容と共に、内容に問題がない場合に返信するメールアドレス返信先アドレス1と、内容に問題があった場合に返信するメールアドレス返信先アドレス2が記載されているものとする。S1304において、WEBメールサーバは、確認依頼メールを受信する。ここで、確認の依頼がなされたユーザは、自分のクライアント端末のブラウザを介してこの確認依頼のメールを一度受信して記載されているメールアドレスに対して返信する操作を行う。S1305において、WEBメールサーバは、確認者から送信された返信メールをワークフローサーバへ送信する。S1306において、ワークフローサーバは、メールを受信する。そして、返信メールの内容に応じて、ワークフロー登録した状況の更新を行う。つまり、確認OKの場合の更新と、確認NGの場合の更新である。S1307において、ワークフローサーバは、メールを送信したすべての確認者から返信メールを受信したかを判定する。Yesの場合、終了し、Noの場合、S1308へ進む。S1308において、ワークフローサーバは、ワークフロー変更処理を行い、S1307へ戻る。ここで、ワークフロー変更処理とは、具体的には、図11に示す、撤回ボタン1107か、消去ボタン1108が押下された場合に行われる処理である。いずれも選択されない場合は、このステップでは何もなされずにS1307へ戻ることとなる。ワークフロー変更処理を、図14を用いて説明する。図14は、図10~11の確認画面が表示され、撤回、消去が選択された場合の処理の流れを示すフローチャートである。S1401において、クライアント端末は、確認メールの一覧画面図10の要求がなされたかを判定する。Yesの場合、S1402へ進み、Noの場合、終了する。つまり、クライアント端末から一覧画面の要求がなされない場合、本フローチャートはパスされることとなる。S1402において、クライアント端末は、確認メールの一覧画面を要求する。S1403において、ワークフローサーバは、確認メール一覧画面の要求を受け付ける。S1404において、ワークフローサーバは、要求元ユーザが参照可能なワークフローとして登録されている内容を抽出する。具体的には、図10に示す件名1003、更新日1004、返信1005へ表示する内容が抽出される。S1405において、ワークフローサーバは、確認メール一覧画面を送信する。S1406において、クライアント端末は、確認メール一覧画面を受信する。S1407において、クライアント端末は、確認メール一覧画面を表示する図10。S1408において、クライアント端末は、一覧から件名が選択されたかを判定する。Yesの場合、S1410へ進み、Noの場合、S1409へ進む。具体的には、件名が選択されたかにより判定する。S1409において、クライアント端末は、一覧画面の閲覧が終了されたかを判定する。Yesの場合、終了し、Noの場合、S1408へ戻る。S1410において、クライアント端末は、選択された確認メールの状況を確認するための画面を要求する。S1411において、ワークフローサーバは、選択された確認メールの状況を確認するための画面要求を受け付ける。S1412において、ワークフローサーバは、ワークフローとして登録されている内容から対応する確認メールの状況を確認するための情報を抽出する。具体的には、図11に示す各内容を表示可能な内容が抽出される。S1413において、ワークフローサーバは、選択された確認メールの状況を確認するための画面を送信する。S1414において、クライアント端末は、選択された確認メールの状況を確認するための画面を受信する。S1415において、クライアント端末は、選択された確認メールの状況を確認するための画面を表示する図11。S1416において、クライアント端末は、撤回ボタン1107が押下されたかを判定する。Yesの場合、S1417へ進み、Noの場合、S1420へ進む。S1417において、クライアント端末は、撤回処理を要求する。S1418において、ワークフローサーバは、撤回処理要求を受け付ける。S1419において、ワークフローサーバは、撤回処理を行って処理を終了する。ここで、撤回処理とは、この確認メールの回覧を中止することをいう。ただし、後から閲覧可能とするためデータは残した状態とする。S1420において、クライアント端末は、消去ボタン1108が押下されたかを判定する。Yesの場合、S1422へ進み、Noの場合、S1421へ進む。S1421において、クライアント端末は、一覧画面の閲覧が終了されたかを判定する。Yesの場合、終了し、Noの場合、S1416へ戻る。S1422において、クライアント端末は、消去処理を要求する。S1423において、ワークフローサーバは、消去処理要求を受け付ける。S1424において、ワークフローサーバは、消去処理を行って処理を終了する。ここで、消去処理とは、この確認メールを消去することをいう。以上、図14を用いて、ワークフロー変更処理を説明した。また、上述した通り、図13の処理の説明もしたため、図12の説明に戻る。S1207において、ワークフローサーバは、確認がとれたかどうかを判定する。Yesの場合、S1208へ進み、Noの場合、S1214へ進む。ここでは、確認者として指定されたすべてのユーザから確認OKのメールを受け取ったかにより判定がなされる。S1208において、ワークフローサーバは、確認後、送信先宛先の指定があるかを判定する。Yesの場合、S1209へ進み、Noの場合、S1214へ進む。具体的には、図9に示す画面で、確認後、自動的に以下の宛先へ送信する901のオプションが選択されていたかにより判定を行う。S1209において、ワークフローサーバは、確認された内容を本文としてメールを図9に示す宛先欄902に指定されたアドレスへ送信する。複数指定されている場合は、複数に送信する。S1210において、WEBメールサーバは、ワークフローから送信されたメールを受信する。S1211において、WEBメールサーバは、受信したメールを、指定されている宛先に送信する処理を行う。S1212において、WEBメールサーバは、メールを送信した旨の連絡を行う。S1213において、ワークフローサーバは、メールを送信した旨の連絡を受信する。S1214において、ワークフローサーバは、ワークフロー登録内容した内容を更新する。なお、S1213において、メールを送信した旨の連絡を受信した場合は、ワークフロー登録から消去する。ただし、後から送信したメールを参照したい場合も存在するので、このような運用をする場合は、消去することなく閲覧可能にデータを残すことができるものとする。このワークフロー更新は運用により様々な形態をとることができる。上述した通り、第二の実施の形態の本発明によれば、確認者として指定されたユーザに対して確認依頼のメールを送付し、確認が取れた場合に、指定された宛先にメールを送付することができる。以上、本発明の第二の実施の形態を、図8~14を用いて説明した。なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。また、本発明におけるプログラムは、図の処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図3の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図3の各装置の処理方法ごとのプログラムであってもよい。以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータまたはCPUやMPUが記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク,ハードディスク,光ディスク,光磁気ディスク,CD-ROM,CD-R,DVD-ROM,磁気テープ,不揮発性のメモリカード,ROM,EEPROM,シリコンディスク等を用いることができる。また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOSオペレーティングシステム等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。さらに、本発明を達成するためのプログラムをネットワーク上のサーバ,データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。"