(57)【要約】【課題】送受信メッセージの内容を元に既存のタスク状態を変化させたい場合でも、新たなタスクとしてシステムに登録されてしまうことがなくユーザがタスク状態の更新を行える。【解決手段】メール送受信サービスサーバとクライアントPCとの間に挿入され、クライアントPCが送受信する電子メールのメッセージを解析し、その電子メールに関連したタスク情報を取得するか、またはタスク情報のテンプレートを作成し、タスク情報を使って、タスク管理サービスサーバに対して、新規タスクの作成及び既存タスクの情報更新を行うメッセージ解析サービスサーバを備えた。【選択図】図１
2011048532.tif 000002
【特許請求の範囲】
【請求項１】
クライアントPCと、該クライアントPCの電子メールの送受信を行うメール送受信サービスサーバと、前記クライアントPCのタスク管理を行うタスク管理サービスサーバと、を有する電子メール及びタスク管理システムであって、
前記メール送受信サービスサーバと前記クライアントPCとの間に挿入され、前記クライアントPCが送受信する電子メールのメッセージを解析し、その電子メールに関連したタスク情報を取得するか、またはタスク情報のテンプレートを作成し、前記タスク情報を使って、前記タスク管理サービスサーバに対して、新規タスクの作成及び既存タスクの情報更新を行うメッセージ解析サービスサーバを備えたことを特徴とする電子メール及びタスクの管理システム。
【請求項２】
前記クライアントPCは、
前記メール送受信サービスサーバとは、前記メッセージ解析サービスサーバを介して間接的に通信するメール処理部と、
前記メッセージ解析サービスサーバに、タスクの更新／作成のリクエスト、および、メッセージIDを送るタスク提示部と、
新規タスクを作成し、関連するタスクを編集するタスク管理部と、
を備えたことを特徴とする請求項１記載の電子メール及びタスクの管理システム。
【請求項３】
前記メッセージ解析サービスサーバは、
前記タスク情報とそのタスク情報に関連するメッセージIDとの対応付けを管理するタスク/メッセージＩＤ管理部を有し、
前記メールに関連したタスク情報もしくは前記テンプレートを前記タスク提示部に送信することを特徴とする請求項２記載の電子メール及びタスクの管理システム。
【請求項４】
前記メッセージ解析サービスサーバと前記タスク提示部との間のデータの授受は、前記タスク提示部が待ち受け状態で、前記メッセージ解析サービスサーバが関連タスク／タスクキーワードを送信するPUSH方式を用いたことを特徴とする請求項３記載の電子メール及びタスクの管理システム。
【請求項５】
メッセージ解析サービスサーバが前記タスク管理サービスサーバから取得した関連タスクまたはタスクキーワードを保存し、前記タスク提示部が定期的に前記メッセージ解析サービスサーバに問い合わせ、ユーザに提示すべき関連タスク／タスクキーワードがあるか否かをチェックし、前記関連タスク／タスクキーワードがある場合には前記関連タスクを前記メッセージ解析サービスサーバから取得して表示するPULL方式を用いたことを特徴とする請求項３記載の電子メール及びタスクの管理システム。
【請求項６】
クライアントPCの電子メール及びタスクを管理する電子メール及びタスクの管理システムの管理方法であって、
前記クライアントPCが送受信する電子メールのメッセージを解析し、その電子メールに関連したタスク情報を取得するか、またはタスク情報のテンプレートを作成し、前記タスク情報を使って、新規タスクの作成及び既存タスクの情報更新を行うことを特徴とする電子メール及びタスクの管理方法。
【請求項７】
クライアントPCと、該クライアントPCの電子メールの送受信を行うメール送受信サービスサーバと、前記クライアントPCのタスク管理を行うタスク管理サービスサーバと、を有する電子メール及びタスクの管理システムの制御用のプログラムであって、
前記メール送受信サービスサーバと前記クライアントPCとの間に挿入されたメッセージ解析サービスサーバが、
前記クライアントPCが送受信する電子メールのメッセージを解析する手段、
その電子メールに関連したタスク情報を取得するか、またはタスク情報のテンプレートを作成する手段、
前記タスク情報を使って、前記タスク管理サービスサーバに対して、新規タスクの作成及び既存タスクの情報更新を行う手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メール及びタスクの管理システム、方法、並びにプログラムに関する。
【背景技術】
【０００２】
個人のスケジュールやToDo(やるべきこと)、アクションアイテム(To-Doリスト)などを管理するスケジューラ／グループウェアは広く利用されており、それらToDo／アクションアイテムなどは、人と人とのコミュニケーションの結果として、各自に発生する場合が多い。前述のスケジュールやToDo、アクションアイテムを発生させるコミュニケーションは、近年では、口頭だけでなく、証拠残しの役割も兼ねて電子メールメッセージを介して行われるケースが多い。
【０００３】
そこで、電子メールメッセージの内容を解析して、自動でスケジューラ等に登録するシステムが考えられ既に知られている。
【０００４】
図８は、電子メール及びタスクの管理システムの一般的な概要図である。
図８に示すシステムは、電子メールシステム（クライアントPC(Personal Computer)１のメール処理部１ａと、メール送受信サービスサーバ２とを含むシステムである。）と、タスク管理システム（クライアントPC１のタスク管理部１ｃと、タスク管理サービスサーバ３とを含むシステムである。）と、を有するシステムである。
【０００５】
メール送受信サービスサーバ２は一般に、送信側がSMTP(Simple Mail Transfer Protocol)サービスサーバ、及び受信側がPOP3(Post Office Protocol 3)サービスサーバ）を含み、タスク管理システム（タスク管理サービスサーバ３、及びクライアントPC１のタスク管理部１ｃ、『グループウェア』と総称される）とは基本的には独立している。
【０００６】
クライアントPC１は、メール処理部１ａ及びタスク管理部１ｃを有する。ネットワーク４上にはメール送受信サービスサーバ２、及びタスク管理サービスサーバ３を有する。
【０００７】
電子メールの受信時のユーザ操作としては、ユーザはクライアントPC１のメール処理部１ａを操作して、メール送受信サービスサーバ２に届いた電子メール５−１をユーザ自身が操作するクライアントPC１上にダウンロードして閲覧する。
同様に電子メールの送信時も、ユーザがクライアントPC１のメール処理部１ａを操作することにより、電子メール５−２を作成した後に、メール送受信サービスサーバ２に対して作成した電子メール５−２を送り、それを受けとったメール送受信サービスサーバ２が電子メール５−２のメッセージに記載された宛先に送信する。
【０００８】
また、タスクの管理に関しては、ユーザは、自身の作業の結果や電子メール５−２を含むコミュニケーションの結果に発生したタスク６を、クライアントPC１のタスク管理部１ｃを操作することでタスク管理サービスサーバ３へ登録する。
つまり、２つのシステム（電子メールシステム及びタスク管理システム）間で情報の整合性を取るのは、クライアントPC１のメール処理部１ａやクライアントPC１のタスク管理部１ｃを実際に操作するユーザ自身であり、その送受信した電子メールのメッセージの内容により、新たなスケジュールやタスクの設定／スケジュール（開始または終了日時）の変更／タスク状態（問い合わせ中／返信受信済みetc）の変更などが必要となった場合は、ユーザ自身がクライアントPC１のタスク管理部１ｃを操作して、その内容にあったタスク６の新規作成や検索などを行い、その結果提示されたタスク情報を作成／更新するようタスク管理サービスサーバ３にリクエストを送信する。
【０００９】
また、図８に示したシステムの他、特許文献１には、受信メールの自動転送と個人タスク情報への自動登録とを行うことを目的とした電子メールシステムについて開示され、メッセージ転送の要否の判定に受信した電子メールメッセージ本文に記述されたスケジュール情報やToDo情報、キーワードなどを利用することができる。また、特許文献１には、ヘッダ情報だけで判定するよりも詳細かつ正確な判定を行うことができ、メールサーバが個人情報管理手段および個人情報データベースを具備しているので、電子メール本文に記述された上記の情報を自動的に個人情報データベースに登録することができるとともに、個人情報データベースを参照することによってメール転送時の転送先を決定することができる構成が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかし、上述したような一般的なシステムでは、電子メールメッセージの内容を解析して、新規のスケジュールやToDo、アクションアイテム（以下、『タスク』と記述する。）などを追加することが出来るに過ぎなかった。具体的に説明すると、人が行った作業や他人とのコミュニケーション（この場合は電子メールメッセージを介したコミュニケーション）の結果によって、そのタスクの状態は変化する。
このような状況では、タスクの新規追加機能のみでは、例えば受信メッセージの内容から考えて現在進行中の既存のタスクの状態を変えたい（例えば『完了』状態にしたい、など）場合のように、「送受信メッセージの内容を元に既存のタスク状態を変化させたい場合でも、新たなタスクとしてシステムに登録されてしまう」という問題があった。
【００１１】
そこで、本発明は、送受信メッセージの内容を元に既存のタスク状態を変化させたい場合でも、新たなタスクとしてシステムに登録されてしまうことがなくユーザがタスク状態の更新を行える電子メール及びタスクの管理システム、方法、並びにプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するため、請求項１記載の発明は、クライアントPCと、該クライアントPCの電子メールの送受信を行うメール送受信サービスサーバと、前記クライアントPCのタスク管理を行うタスク管理サービスサーバと、を有する電子メール及びタスク管理システムであって、前記メール送受信サービスサーバと前記クライアントPCとの間に挿入され、前記クライアントPCが送受信する電子メールのメッセージを解析し、その電子メールに関連したタスク情報を取得するか、またはタスク情報のテンプレートを作成し、前記タスク情報を使って、前記タスク管理サービスサーバに対して、新規タスクの作成及び既存タスクの情報更新を行うメッセージ解析サービスサーバを備えたことを特徴とする。
【００１３】
請求項２記載の発明は、請求項１記載の発明において、前記クライアントPCは、前記メール送受信サービスサーバとは、前記メッセージ解析サービスサーバを介して間接的に通信するメール処理部と、前記メッセージ解析サービスサーバに、タスクの更新／作成のリクエスト、および、メッセージIDを送るタスク提示部と、新規タスクを作成し、関連するタスクを編集するタスク管理部と、を備えたことを特徴とする。
【００１４】
請求項３記載の発明は、請求項２記載の発明において、前記メッセージ解析サービスサーバは、前記タスク情報とそのタスク情報に関連するメッセージIDとの対応付けを管理するタスク/メッセージＩＤ管理部を有し、前記メールに関連したタスク情報もしくは前記テンプレートを前記タスク提示部に送信することを特徴とする。
【００１５】
請求項４記載の発明は、請求項３記載の発明において、前記メッセージ解析サービスサーバと前記タスク提示部との間のデータの授受は、前記タスク提示部が待ち受け状態で、前記メッセージ解析サービスサーバが関連タスク／タスクキーワードを送信するPUSH方式を用いたことを特徴とする。
【００１６】
請求項５記載の発明は、請求項３記載の発明において、メッセージ解析サービスサーバが前記タスク管理サービスサーバから取得した関連タスクまたはタスクキーワードを保存し、前記タスク提示部が定期的に前記メッセージ解析サービスサーバに問い合わせ、ユーザに提示すべき関連タスク／タスクキーワードがあるか否かをチェックし、前記関連タスク／タスクキーワードがある場合には前記関連タスクを前記メッセージ解析サービスサーバから取得して表示するPULL方式を用いたことを特徴とする。
【００１７】
請求項６記載の発明は、クライアントPCの電子メール及びタスクを管理する電子メール及びタスクの管理システムの管理方法であって、前記クライアントPCが送受信する電子メールのメッセージを解析し、その電子メールに関連したタスク情報を取得するか、またはタスク情報のテンプレートを作成し、前記タスク情報を使って、新規タスクの作成及び既存タスクの情報更新を行うことを特徴とする。
【００１８】
請求項７記載の発明は、クライアントPCと、該クライアントPCの電子メールの送受信を行うメール送受信サービスサーバと、前記クライアントPCのタスク管理を行うタスク管理サービスサーバと、を有する電子メール及びタスクの管理システムの制御用のプログラムであって、前記メール送受信サービスサーバと前記クライアントPCとの間に挿入されたメッセージ解析サービスサーバが、前記クライアントPCが送受信する電子メールのメッセージを解析する手段、その電子メールに関連したタスク情報を取得するか、またはタスク情報のテンプレートを作成する手段、前記タスク情報を使って、前記タスク管理サービスサーバに対して、新規タスクの作成及び既存タスクの情報更新を行う手段、として機能させるためのプログラムであることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、新規タスクを登録する際に、送受信電子メールメッセージを一意に特定するID(IDentify)や電子メールメッセージヘッダ／電子メールメッセージ本文等を、タスクに関連付けて管理しておくことで、次回の電子メールメッセージの送受信時には、同様に電子メールメッセージヘッダおよび電子メールメッセージ本文等をキーワードとして登録済みタスクを検索することができるので、送受信メッセージの内容を元に既存のタスク状態を変化させたい場合でも、新たなタスクとしてシステムに登録されてしまうことがなくユーザがタスク状態の更新を行える電子メール及びタスクの管理システム、方法、並びにプログラムの提供を実現することができる。
【図面の簡単な説明】
【００２０】
【図１】本発明に係る電子メールとタスクの管理システムの一実施の形態を表す概要図である。
【図２】一般的な電子メールの構造と、メッセージ解析サービスサーバでの処理対象を表した模式図の一例である。
【図３】本発明に係る管理システムを使用した際のメール送受信時のシーケンス図での一例である。
【図４】（ａ）〜（ｃ）は、タスク提示部１ｂの説明図である。
【図５】メッセージ解析サービスサーバ内で保持するメッセージIDとタスクとの関連を管理するテーブルを表した模式図の一例である。
【図６】（ａ）、（ｂ）は、メッセージ送受信時のメッセージ解析サービスの動作を表したフローチャートの一例である。
【図７】メッセージ解析サービスサーバ３とクライアントPCのタスク提示部１ｂとの間で送受信されるタスク情報のデータフォーマットの一例である。
【図８】電子メールとタスクの管理システムの一般的な概要図である。
【発明を実施するための形態】
【００２１】
図１は、本発明に係る電子メールとタスクの管理システムの一実施の形態を表す概要図である。尚、図８に示した部材と同様の部材には共通の符号を用いた。
図１に示す管理システムは、クライアントPC１、メール送受信サービスサーバ２、タスク管理サービスサーバ３、及びネットワーク４に加え、メッセージ解析サービスサーバ７と、ユーザが操作するクライアントPC１上にタスク提示部１ｂが加わり、今までユーザが手動で行っていた、タスク管理サービスサーバ３上でのタスクの新規作成や検索などを、送受信電子メール５−１のメッセージのヘッダ／内容をキーとして使用して自動で行い、ユーザによる確認／修正の後にタスク管理サービスサーバ３上に登録／更新される。
【００２２】
図２は、一般的な電子メールのメッセージの構造と、メッセージ解析サービスサーバでの処理対象とを表した模式図の一例である。
電子メールのメッセージ（以下『メッセージ』）は、一般的にヘッダ部とボディ部とに分けられ、ヘッダ部には通信に関する情報（いつ/誰から/どういう経路で/誰に対して送られたか、など）が収められており、ボディ部にはメッセージの本文が収められている。
特にヘッダ部内の『Message-ID』（図中、枠Ｌ１〜Ｌ５の部分）に関しては、RFC(Request For Comments)2822（各電子メールクライアントはこれに従って実装される）によると、「Though optional, every message SHOULD have a "Message-ID:" field.」とあり、任意ではあるが、全てのメッセージ（図中、枠Ｌ１〜Ｌ７の部分）は“Message-ID:"フィールドを持つことが推奨されている。
実際に、このフィールドがあることを前提にして、返信メッセージと元メッセージ等との関係を表すスレッドツリーの表示を行っている。
【００２３】
メッセージ解析サービスでは、ヘッダ部から、そのメッセージ固有の情報（Subject／Message−IDフィールドなど）や他のメッセージとの関係を表す情報（In-Reply-To／Referencesフィールド。以下『関連メッセージID』）を抽出する。またボディ部からは、メール本文テキストを解析し、場所や日時を表すキーワードを抽出する。キーワード抽出には、形態素解析を行い、『日時』、『日程』、『納期』、『期日』など時間を表す単語や、『月』、『日』、『時』、『分』等の時間の単位を表す単語を中心に抽出する。
これらの抽出したキーワードを用いて、タスク管理サービスサーバ３に対し、同様のキーワードを保持するタスク取得を要求する。またメッセージに電子ファイルが添付されていれば、それも併せて抽出し、メッセージ解析サービスサーバ内で保持する。
【００２４】
ここで、メッセージ解析サービスサーバ７がどのようにして、クライアントPC１から送信されるメール、及びクライアントPC１に送信されるメールを取得できるのかについて詳述する。
まず比較のために、従来のクライアントPCのメール処理部とメール送受信サービスサーバとの関係について述べる。
従来のクライアントPCのメール処理部とメール送受信サービスサーバとの関係では、ユーザがクライアントPC１のメール処理部１aに対し、メール送受信サービスサーバ２のアドレス（およびポート番号等。以降「サービス情報」と表記する。）を入力すると、クライアントPC１のメール処理部１aはその設定情報として保存しておく。以降は、ユーザが送受信操作を行ったときに、保存されたサービス情報を使用して、メール送受信サービスサーバ２に接続することで、メールの送受信を行う。
【００２５】
本実施形態において、ユーザが使用するクライアントPC１のメール処理部１aには、予め設定するサービス情報をメッセージ解析サービスサーバ７のアドレス、ポート番号等に設定しておく。このように設定することで、ユーザが送受信操作を行ったときには、メール処理部１aは、最初にメッセージ解析サービスサーバ７へ接続する。メール処理部１aから送受信要求を受け取ったメッセージ解析サービスサーバ７は、クライアントPC１のメール処理部１aの代理としてメール送受信サービスサーバ２と接続し、メール処理部１aからの要求が送信要求であれば、メール処理部１aから受け取ったメールを送信し、受信要求であれば、メール送受信サービスサーバ２に未読メールがないか否かをチェックする。つまり、メッセージ解析サービスサーバ７は、常にメール送受信サービスサーバ２とメール処理部１aとの間に立つことで、それらの間を行き来する送受信メールにアクセスすることが可能になる。
【００２６】
次に、メッセージ解析サービスサーバ７がどのようにしてタスク提示部１ｂを特定できるのかについて述べる。
基本的にはクライアントPC１のメール処理部１aがメッセージ解析サービスサーバ７と接続する関係と同様であるが、タスク提示部１ｂ側にもメッセージ解析サービスサーバ７のサービス情報を保存しておく必要があり（メール処理部１aの情報と共有してもよい。）、起動時にサービス情報に基づいてメッセージ解析サービスサーバ７に接続する。
【００２７】
図３の中ほどにあるメッセージ解析サービスサーバ７−タスク提示部１ｂ間のシーケンスについて、図ではメッセージ解析サービスサーバ７からタスク提示部１ｂへの矢印になっているが、厳密には、最初にタスク提示部１ｂからメッセージ解析サービスサーバ７に接続することで、擬似的にメッセージ解析サービスサーバ７からタスク管理サービスサーバ３へデータを送信する。
擬似的にサービスサーバからクライアント（本実施形態の場合、メッセージ解析サービスサーバ７からタスク提示部１ｂ）へデータ（本実施形態の場合、関連タスク情報）をリアルタイムに送信する仕組みとして、Comet方式が一般的である。
【００２８】
このComet方式では、最初にクライアントPCからサービスサーバに接続要求すると、クライアントPCへ送るデータがある場合は、即座にサービスサーバはクライアントPCへ応答としてデータを返す。これとは逆にサービスサーバからクライアントPCへ送るデータがない場合、サービスサーバは一定時間応答するのを保留し、その一定時間の間にクライアントPCへ送るデータが発生した場合は、即座にクライアントPCへ応答としてデータを返すようになっている。
【００２９】
また一定時間経過してもクライアントPCへ送るデータが発生しない場合、サービスサーバはクライアントPCに対し「要求はタイムアウトした」と応答する。クライアントPCは、サービスサーバから応答を受け取ったいずれの場合（データを受け取った、接続がタイムアウトした）でも、サービスサーバに対して即座に次の接続要求を行い、再びデータを受け取るかタイムアウトすると、サービスサーバから応答が返ってくる。以下この処理を繰り返す。
つまり、メッセージ解析サービスサーバ７がクライアントPC１上で動作するタスク提示部１bを特定しているわけではなく、まずタスク提示部１ｂがメールサービスサーバ２に接続し、その応答としてメッセージ解析サービスサーバ７からタスク提示部１ｂへ関連タスク情報を送信する、という流れになる。
【００３０】
次に、クライアントPC１のタスク提示部１ｂとメッセージ解析サービスサーバ７との関係及びタスク管理サービスサーバ３等について詳述する。
タスク提示部１ｂは、メッセージ解析サービスサーバ７で発生した、電子メールに基づいた新着タスクをユーザに提示するプログラムであるため、タスク提示部１ｂだけを有する状況は意味がないと考えられる。またタスク提示部１ｂ上で新着タスクを編集した際に、その編集結果をタスク管理サービスサーバ７に格納しなければならない。本実施の形態では、メッセージ解析サービスサーバ７がタスク提示部１ｂからのタスク登録要求を仲介し、タスク管理サービスサーバ７にタスク登録を行う流れになっている。つまり提示部１ｂが直接タスク管理サービスサーバ７に接続して、新規タスクの登録を実行しても効果としては変わらない（メッセージ解析サービスサーバ７を経由するか否か、だけである）。
【００３１】
またタスクは、基本的にタスク管理サービスサーバ３で一元管理されることを想定しているが、タスク提示部１ｂで提示された新着タスクを、ユーザに提示された時に編集するために、タスク管理部１ｃを起動／操作するのは好ましくない（新着タスクを提示しているUI／プログラムでタスクの編集をさせるのが好ましい。）ため、タスクの編集機能を持たせている。
【００３２】
ただし、タスク管理部１ｃの機能として、タスク提示部１ｂを内包する場合は（その場合、タスク管理部１ｃは、メッセージ解析サービスサーバ７とタスク管理サービスサーバ３との両サービスサーバと通信する）、メッセージ解析サービスサーバ７が存在しなくても成り立つ構成にはなるが、その場合は単純なグループウェア（Notes（登録商標）のドミノサーバとクライアントなど）の関係と同様である。
【００３３】
図３は、本発明に係る管理システムを使用した際のメール送受信時のシーケンス図の一例である。
図の左からユーザ、クライアントPC１上のプログラム（メールクライアント：メール処理部１ａ、タスク提示プログラム：タスク提示部１ｂ、タスク管理クライアント：タスク管理部１ｃ）、ネットワーク４上のサービスサーバ群（メッセージ解析サービスサーバ７、メール送受信サービスサーバ２、タスク管理サービスサーバ３）の順に並んでいる。クライアントPC１上のプログラムとネットワーク上のサービスサーバ群との違いは、ユーザインターフェースを持ち、ユーザが直接操作できるか否か、である。
【００３４】
最初にユーザは、メールクライアントPC１を操作することによりメール送受信処理を実行する（ステップＰ１）。
本実施形態では、送受信時の両方においてメール処理部１aは、メール送受信サービスサーバ２とは直接的に通信せずに、メッセージ解析サービスサーバ７を介して間接的に通信する。
メッセージ解析サービスサーバ７は、メール処理部１aから受け取ったメッセージ送受信リクエストをメール送受信サービスサーバ２に送ることによりメール送受信代理処理要求を行う（ステップＰ２）。メール送受信サービスサーバ２は、メール送受信代理処理を行う（ステップＰ３）。メール送受信サービスサーバ２は、レスポンスをメッセージ解析サービスサーバ７に送り（ステップＰ４）、メッセージ解析サービスサーバ７は、そのレスポンスをメール処理部１aに送り（ステップＰ５）、レスポンスを送った後に、送受信両メッセージ（送信時はメール処理部１aからの送信メッセージを解析し、受信時はメール送受信サービスサーバ２からの受信メッセージ）のヘッダ／内容を解析し（ステップＰ６）、関連メッセージID自身が持つタスク/メッセージIDテーブルから関連タスクを特定する。
【００３５】
また、メッセージ解析サービスサーバ７は、メッセージの本文から抽出したタスクキーワード（タスク名、時間、場所、依頼／開催案内などの関連メール）を抽出し、そのタスクキーワードから関連したタスクをタスク管理サービスサーバ３に検索要求を行う（ステップＰ７）。タスク管理サービスサーバ３はタスク検索処理を行い（ステップＰ８）、メッセージ解析サービスサーバ７は、タスク検索処理結果をタスク管理サーバ３から取得する（ステップＰ９）。さらに、メッセージ解析サービスサーバ７は、タスクキーワードからタスク情報の雛形（以下『タスクテンプレート』）を作成し、タスクテンプレートをタスク提示部に送る（ステップＰ１０）。
【００３６】
取得した関連タスク／タスクキーワード、および、メッセージ解析に使用したメッセージを一意に特定できるID（前述のMessage-id）は、クライアントPC１上で動作するタスク提示部１ｂによりユーザに提示される（ステップＰ１１）。
【００３７】
ここで、メッセージ解析サービスサーバ７とタスク提示部１ｂとの間のやりとりは２つ方法がある。
第一の方法は、タスク提示部１ｂが待ち受け状態で、メッセージ解析サービスサーバ７が関連タスク／タスクキーワードを送信するPUSH方式である。
第二の方法は、メッセージ解析サービスサーバ７がタスク管理サービスサーバ３から取得した関連タスクまたはタスクキーワードを保存し、タスク提示部１ｂが定期的にメッセージ解析サービスサーバ７に問い合わせ、ユーザに提示すべき関連タスク／タスクキーワードがあるか否かをチェックし、関連タスク／タスクキーワードがある場合には関連タスクをメッセージ解析サービスから取得して表示するPULL方式である。図２は前者のPUSH方式で記述している。
【００３８】
ユーザは、タスク提示部１ｂに提示されたタスクの修正、または新規タスクの作成、編集を実行すると（ステップＰ１２）、タスク提示部１ｂは、メッセージ解析サービスサーバ７に、タスクの更新／作成のリクエスト、および、メッセージIDを送る（ステップＰ１３）。
メッセージ解析サービスサーバ７は、タスクの更新の場合は、タスク提示部１ｂから受け取ったメッセージIDを使って更新すべきタスクを特定し、タスク管理サービスサーバ３に対して、更新のリクエストを要求する（ステップＰ１４）。
メッセージ解析サービスサーバ７は、タスクの新規作成の場合は、タスク管理サービスサーバ３に対して、タスクの新規作成リクエストを送り、作成されたタスクのIDと、送られたメッセージIDの対応テーブル（後述）に追加する（ステップＰ１５）。タスク管理サービスサーバ３は、タスクの更新を行い（ステップＰ１６）、タスク更新処理結果をメッセージ解析サービスサーバ７に送り（ステップＰ１７）、メッセージ解析サービスサーバ７は、その処理結果をタスク提示部１ｂに送る（ステップＰ１８）。
タスク管理部１ｂは、ユーザによる新規タスク作成や関連タスク編集が行われると（ステップＰ１９）、タスク管理サービスサーバ３にタスクの更新もしくは作成を要求すると（ステップＰ２０）、タスク管理サービスサーバ３は、タスク更新もしくは作成処理を行い（ステップＰ２１）、タスク管理部１ｃに処理結果を送り（ステップＰ２２）、タスク管理部１ｃは、処理結果をユーザに表示する。
【００３９】
またメール送受信とは関わらないタスクの作成／更新時は、ユーザは通常通り、タスク管理部１ｃを操作して、タスク管理サービスサーバ３に対して、タスクの新規作成／更新のリクエストを行う。
【００４０】
図４（ａ）〜（ｃ）は、タスク提示部１ｂの説明図である。
タスク提示部１ｂは、前述のとおり、クライアントPC１上で動作しており、メッセージ解析サービスサーバ７が送受信メッセージから抽出した関連タスクの情報を表示する（ステップＰ１１）。
メッセージ解析サービスサーバ７から関連タスク情報を受け取ると、図４（ａ）のようなユーザインターフェースをユーザのクライアントPC１上に表示する。ユーザインターフェース上には、そのタスクの名前や状態の詳細、タスク期間の開始／終了日時が表示され、ユーザは、その内容を確認し、必要であればキーボードを使用してその内容を訂正することができる（ステップＰ１９）。またそのタスクが完了したときには、「完了にする」と書かれたラベル横にあるチェックボックスをクリックしてチェックをすることで、このタスクの状態を「完了」にする、ユーザによる確認・訂正が終了する。ユーザにより『更新』のボタンが押されると、タスク管理部１ｃはタスク管理サービスサーバ３へ関連タスクの更新を要求する（ステップＰ２１）。
【００４１】
また、タスク名の表示エリアは、ドロップダウンのリスト形式になっており、メッセージ解析サービスサーバ７からの関連タスク情報が複数ある場合は、図４（ｂ）のように、ユーザはリストから選択したタスクに関して編集が出来る。
メッセージ解析サービスサーバ７からの関連タスク情報の全てが更新すべきタスクではなかった場合、ユーザはリストの最下段にある『新規作成』を選択することで、図４（ｃ）のような新規作成用のユーザインターフェースに切り替わる。
この画面では、ユーザが任意のタスク情報（タスク名／状態／期間等）を入力し「登録」ボタンを押すことにより、メッセージ解析サービスサーバ７を介して、タスク管理サービスサーバ３上に新規タスクが作成される。タスク登録を中止したい場合は、『取消』を押すことにより、入力した内容を取り消し、ユーザインターフェースを閉じる。
【００４２】
また、メッセージ解析サービスサーバ７からタスクキーワードを受け取った場合（タスク管理サービスサーバ３上に関連タスクがなかった場合）でも、図４（ｃ）のユーザインターフェースを、タスク名／期限等を予め入力された状態（受け取ったタスクキーワードを使用）で表示する。
【００４３】
図５は、メッセージ解析サービスサーバ７内で保持するメッセージIDとタスクとの関連を管理するテーブルを表した模式図の一例である。
このテーブルでは、タスク管理サービスサーバ３が保持する各タスクのIDと、そのタスクを登録（または更新）した際に解析された送受信メールのメッセージIDとの対応付けを行う。本実施の形態では、タスク管理部１ｃがwebブラウザ、つまりタスク管理サービスサーバ３がwebアプリケーションであると想定しており、各「タスクID」の列には「http://」で始まるURL(Uniform Resource Locator)が格納されている。
【００４４】
また一般に、タスク管理サービスサーバ３ではそのタスクの状態を「完了」もしくは「未完」の二者択一で表現する場合が多いため、より詳細なタスクの状態を入力／閲覧するために、「状態の詳細」の列には、タスク状態の詳細な情報が格納される。「メッセージID」の列には、このタスクと関連する送受信メッセージ（タスク作成時や更新時に元になったメッセージ）のメッセージIDヘッダの値が格納される。「関連ファイル」の列には、各メッセージに添付されていた電子ファイルのIDが格納される。
【００４５】
図６（ａ）、（ｂ）は、メッセージ送受信時のメッセージ解析サービスの動作を表したフローチャートの一例である。
図６（ａ）は、メール送受信処理から、タスク提示部１ｂへのタスク情報送信処理までを記述したフローチャートである。
最初にメッセージ解析サービスサーバ７は、送受信メッセージの内部を解析し、メールヘッダからはMessage-IDヘッダに記述されたメッセージIDやIn-Reply-To／Referencesヘッダに記述された関連メッセージID、Subjectヘッダに記述されたメールタイトルを抽出し、メール本文からはタスクキーワードを抽出する（ステップＳ１）。
【００４６】
次に、メッセージ解析サービスサーバ７は、タスク/メッセージIDテーブル（図５参照）から、抽出した関連メッセージIDが含まれるエントリを検索する（ステップＳ２）。
メッセージ解析サービスサーバ７は、エントリがあるか否かを判断し（ステップＳ３）、エントリが無い場合（ステップＳ３／ない）にはステップＳ６に進み、エントリがある場合のみ（ステップＳ３／ある）、そのエントリのタスクIdを取得し（ステップＳ４）、タスク管理サービスサーバ３から『関連タスク情報』を取得する（ステップＳ５）。
【００４７】
次に、メッセージ解析サービスサーバ７は、抽出したタスクキーワードを使用して、タスク管理サービスサーバ３で疑似タスクの検索を行う（ステップＳ６）。
メッセージ解析サービスサーバ７は、疑似タスクがあるか否かを判断し（ステップＳ７）、疑似タスクがない場合（ステップＳ７／ない）にはステップＳ９に進み、タスク検索の結果が１件以上あった場合（ステップＳ７／ある）、それらを『類似タスク情報』として取得する（ステップＳ８）。
【００４８】
次に、メッセージ解析サービスサーバ７は、タスクキーワードから『タスクテンプレート』を生成する（ステップＳ９）。
【００４９】
最後に、メッセージ解析サービスサーバ７は、タスク管理サービスサーバ３から取得した『関連タスク情報』／『類似タスク情報』、メッセージから生成した『タスクテンプレート』／メッセージから抽出したメッセージIDをタスク提示部１ｂへ送信する（ステップＳ１０）。
【００５０】
ここで、『関連タスク情報』と『類似タスク情報』との違いは、どの検索処理の結果であるか、のみであるが、『類似タスク情報』はタスク管理サービス上のキーワード検索の結果であるのに対し、『関連タスク情報』は解析したメッセージに含まれる関連メッセージIDが一致するもののみを抽出しているので、情報の信頼度に関しては関連タスク情報のほうが高い。
【００５１】
一方、『タスクテンプレート』は、他の２つとは異なり、メッセージの内容からメッセージ解析サービスサーバ７が推測して作成したタスクであるので、新規作成時にユーザがゼロから作成せずに済むことを想定して、予めユーザインターフェースに入力しておく値である。
【００５２】
次に図６（ｂ）は、クライアントPC１のタスク提示部１ｂからのタスク情報受信からタスク管理サービスサーバ３への登録／更新処理を記述したものである。
タスク管理サービスサーバ３は、最初にタスク情報を受信する（ステップＳ２１）。
タスク管理サービスサーバ３は、タスク情報を受信にタスクIDがあるか否かを判定し（ステップＳ２２）、以降の処理はステップＳ２２から分岐する。
タスク管理サービスサーバ３は、タスクIDがある場合（ステップＳ２２／ある）は、タスクの更新処理を行い、タスクIDがない場合（ステップＳ２２／ない）は、新規登録の処理を行う。
タスク管理サービスサーバ３は、新規登録の場合、タスク提示部１ｂから受信したタスク情報を使って、タスク管理サービスサーバ３上に新規タスクを作成する（ステップＳ２７）。
【００５３】
次に、作成した新規タスクを示すタスクIDをタスク管理サービスサーバ３から取得し、タスク/メッセージIDテーブルに新規エントリとして追加する（ステップＳ２８）。
また、タスク管理サービスサーバ３は、更新処理の場合、タスク/メッセージIDテーブルからタスクIDが一致する該当エントリを取得する（ステップＳ２３）。
次に、タスク管理サービスサーバ３は、エントリがあるか否かを判定し（ステップＳ２４）、該当エントリがない場合（ステップＳ２４／ない）は、新規登録の処理になる。すなわち、ステップＳ２７の後、作成した新規タスクのタスクIDをタスク管理サービスサーバ３から取得し（ステップＳ２８）、該当エントリがあった場合（ステップＳ２４／ある）は、受信したメッセージIDを該当エントリに追加し（ステップＳ２５）、該当エントリのタスクIDを使用して、タスク管理サービスサーバ３上のタスク情報を更新する（ステップＳ２６）。
タスク管理サービスサーバ３は、新規登録／更新のどちらの処理でも、タスク情報の送信元であるタスク提示部１ｂに対し、処理結果を送信する（ステップＳ３０）。
【００５４】
図７は、メッセージ解析サービスサーバ３とクライアントPC１のタスク提示部１ｂとの間で送受信されるタスク情報のデータフォーマットの一例である。
本実施形態ではタスク情報のデータフォーマットにXML(extensible markup language)を用いているが、それ以外を用いても良い。
タスク情報のデータは大きく分類して、タスク管理サービスサーバ上で管理されており、且つタスク/メッセージID上で管理されている『関連タスク情報』、タスクキーワードを用いてタスク管理サービスから取得した『類似タスク情報』、タスク管理サービスサーバ上で管理されておらず、メッセージ解析サービスサーバがタスクキーワードから独自に生成した『タスクテンプレート』の３つがある。
【００５５】
『関連タスク情報』と『類似タスク情報』とは、情報の構造に違いは特になく、両者ともタスクID、タスク名、詳細情報、期間の情報などを持つ。
一方『タスクテンプレート』は、タスク管理サービス上で管理されていないので、タスクIDは持たない。『関連タスク情報』と『類似タスク情報』とは複数あっても良い。
【００５６】
＜プログラム及び記憶媒体＞
以上で説明した本発明にかかるシステムは、コンピュータで処理を実行させるプログラムによって実現されている。コンピュータとしては、例えばパーソナルコンピュータやワークステーションなどの汎用的なものが挙げられるが、本発明はこれに限定されるものではない。よって、一例として、プログラムにより本発明を実現する場合の説明を以下で行う。
【００５７】
クライアントPC１と、クライアントPC１の電子メールの送受信を行うメール送受信サービスサーバ２と、クライアントPC１のタスク管理を行うタスク管理サービスサーバ３と、を有する電子メール及びタスクの管理システムの制御用のプログラムであって、
メール送受信サービスサーバ２とクライアントPC１との間に挿入されたメッセージ解析サービスサーバ７が、
クライアントPC１が送受信する電子メールのメッセージを解析する手段、
その電子メールに関連したタスク情報を取得するか、またはタスク情報のテンプレートを作成する手段、
タスク情報を使って、タスク管理サービスサーバ３に対して、新規タスクの作成及び既存タスクの情報更新を行う手段、
として機能させるためのプログラムが挙げられる。
【００５８】
これにより、プログラムが実行可能なコンピュータ環境さえあれば、どこにおいても本発明にかかる電子メールとタスクの管理システムを実現することができる。
このようなプログラムは、コンピュータに読み取り可能な記憶媒体に記憶されていてもよい。
【００５９】
ここで、記憶媒体としては、例えば、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（CD Recordable）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記憶媒体、フラッシュメモリ、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＦｅＲＡＭ（強誘電体メモリ）等の半導体メモリやＨＤＤ（Hard Disc Drive）が挙げられる。
【００６０】
なお、上述した実施の形態は、本発明の好適な実施の形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【００６１】
＜その他＞
特許文献１に記載の発明は、本発明とは一見すると受信メールの内容から個人のタスク情報を管理するシステム／DBに登録する点では類似しているように見られる。
しかし、特許文献１に記載の発明は、送受信メールの内容を元に既存のタスク状態を変化させたい場合でも、新たなタスクとしてシステムに登録されてしまうという欠点は解消できていない。
【符号の説明】
【００６２】
１    クライアントPC
１ａ    メール処理部
１ｂ    タスク提示部
１ｃ    タスク管理部
２    メール送受信サービスサーバ
３    タスク管理サービスサーバ
４    ネットワーク
５−１、５−２、５−３    電子メール
６−１、６−２    タスク
７    メッセージ解析サービスサーバ
【先行技術文献】
【特許文献】
【００６３】
【特許文献１】特許第３５２５０４２号公報
【図１】
2011048532.tif 000003
【図２】
2011048532.tif 000004
【図３】
2011048532.tif 000005
【図４】
2011048532.tif 000006
【図５】
2011048532.tif 000007
【図６】
2011048532.tif 000008
【図７】
2011048532.tif 000009
【図８】
2011048532.tif 000010