(57)【要約】      （修正有）【課題】メーラシステムとスケジューラシステムとを連動させる技術に関し、メールやスケジューラによるスケジュール訂正内容を、そのスケジュールを生成した元メールの表示時に把握できるようにする。【解決手段】受信されたメールメッセージは、メッセージＤＢ１０４に記憶されると共に、スケジュール情報が抽出され、メールメッセージと紐付けてスケジュールＤＢ１０３に記憶される。記憶されたスケジュール情報が訂正されたときに、そのスケジュール情報に紐付けられて記憶されているメールメッセージが示すスケジュール情報との差分情報が、メッセージ更新情報としてメッセージ更新情報ＤＢ１０５に記憶される。メッセージＤＢ１０４からメールメッセージが読み出されて表示される場合に、対応するメッセージ更新情報が読み出され、そのメッセージ更新情報に基づく訂正情報がそのメールメッセージと共にＷｅｂブラウザ部１１６に送信され表示される。【選択図】図１
2010282415.tif 000002
【特許請求の範囲】
【請求項１】
受信したメールメッセージをメッセージデータベースに記憶すると共に、該メールメッセージからスケジュール情報を抽出し、該スケジュール情報を前記メッセージデータベースに記憶されたメールメッセージと紐付けてスケジュールデータベースに記憶し、該スケジュール情報及び該メールメッセージを連動して表示するメール管理方法において、
前記スケジュールデータベースに記憶されるスケジュール情報が訂正されたときに、該スケジュール情報に紐付けられて前記メッセージデータベースに記憶されているメールメッセージが示すスケジュール情報と該訂正されたスケジュール情報との差分情報をメッセージ更新情報としてメッセージ更新情報データベースに記憶し、
前記メッセージデータベースから前記メールメッセージを読み出して表示する場合に、該メールメッセージに対応するメッセージ更新情報を前記メッセージ更新情報データベースから読み出し、該メッセージ更新情報に基づく訂正情報を該メールメッセージと共に表示する、
ことを特徴とするスケジュール情報連動メール管理方法。
【請求項２】
前記メールメッセージの表示は、指定された１つのメールメッセージの表示である、
ことを特徴とする請求項１に記載のスケジュール情報連動メール管理方法。
【請求項３】
前記メールメッセージの表示は、複数のメールメッセージの一覧表示である、
ことを特徴とする請求項１に記載のスケジュール情報連動メール管理方法。
【請求項４】
前記メールメッセージの受信時に、該受信されたメールメッセージの内容と、前記スケジュールデータベースに記憶されているスケジュール情報の内容及び該スケジュール情報に紐付けられて前記メッセージデータベースに記憶されているメールメッセージの内容とを比較することにより、該受信されたメールメッセージが訂正依頼メールであるか否かを判断し、
前記受信されたメールメッセージが訂正依頼メールであると判断した場合に、該受信されたメールメッセージの内容に基づいて、前記スケジュールデータベースに記憶されているスケジュール情報の内容を訂正すると共に、該スケジュール情報に紐付けられて前記メッセージデータベースに記憶されているメールメッセージが示すスケジュール情報と該訂正されたスケジュール情報との差分情報をメッセージ更新情報としてメッセージ更新情報データベースに記憶する、
ことを特徴とする請求項１乃至３に記載のスケジュール情報連動メール管理方法。
【請求項５】
前記受信されたメールメッセージが訂正依頼メールであるか否かの判断は、前記受信されたメールメッセージの内容と、前記スケジュールデータベースに記憶されているスケジュール情報の内容及び該スケジュール情報に紐付けられて前記メッセージデータベースに記憶されているメールメッセージの内容とで一致する部分があるか否かを判断する処理である、
ことを特徴とする請求項４に記載のスケジュール情報連動メール管理方法。
【請求項６】
前記受信されたメールメッセージが訂正依頼メールであるか否かの判断は、前記受信されたメールメッセージの内容と、前記スケジュールデータベースに記憶されているスケジュール情報の内容及び該スケジュール情報に紐付けられて前記メッセージデータベースに記憶されているメールメッセージの内容とで類似する部分があるか否かを判断する処理である、
ことを特徴とする請求項４又は５に記載のスケジュール情報連動メール管理方法。
【請求項７】
受信したメールメッセージをメッセージデータベースに記憶すると共に、該メールメッセージからスケジュール情報を抽出し、該スケジュール情報を前記メッセージデータベースに記憶されたメールメッセージと紐付けてスケジュールデータベースに記憶し、該スケジュール情報及び該メールメッセージを連動して表示するコンピュータに、
前記スケジュールデータベースに記憶されるスケジュール情報が訂正されたときに、該スケジュール情報に紐付けられて前記メッセージデータベースに記憶されているメールメッセージが示すスケジュール情報と該訂正されたスケジュール情報との差分情報をメッセージ更新情報としてメッセージ更新情報データベースに記憶し、
前記メッセージデータベースから前記メールメッセージを読み出して表示する場合に、該メールメッセージに対応するメッセージ更新情報を前記メッセージ更新情報データベースから読み出し、該メッセージ更新情報に基づく訂正情報を該メールメッセージと共に表示する、
処理を実行させるためのプログラム。
【請求項８】
前記メールメッセージの受信時に、該受信されたメールメッセージの内容と、前記スケジュールデータベースに記憶されているスケジュール情報の内容及び該スケジュール情報に紐付けられて前記メッセージデータベースに記憶されているメールメッセージの内容とを比較することにより、該受信されたメールメッセージが訂正依頼メールであるか否かを判断し、
前記受信されたメールメッセージが訂正依頼メールであると判断した場合に、該受信されたメールメッセージの内容に基づいて、前記スケジュールデータベースに記憶されているスケジュール情報の内容を訂正すると共に、該スケジュール情報に紐付けられて前記メッセージデータベースに記憶されているメールメッセージが示すスケジュール情報と該訂正されたスケジュール情報との差分情報をメッセージ更新情報としてメッセージ更新情報データベースに記憶する、
処理を実行させるための請求項７に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
Ｗｅｂシステム上等においてメーラシステムとスケジューラシステムとを連動させる技術に関する。
【背景技術】
【０００２】
インターネットやイントラネット等を介して接続されるクライアントコンピュータのＷｅｂブラウザ等から、サーバコンピュータのＷｅｂメーラやＷｅｂスケジューラ等のシステムを利用する技術が広く利用されている。
【０００３】
このとき、Ｗｅｂメーラ（以下単に「メーラ」と呼ぶ）にて送受信されるメールをそのままスケジュールとしてＷｅｂスケジューラ（以下単位「スケジューラ」と呼ぶ）に登録可能な連動技術も広く利用されている。
【０００４】
この連動技術では、スケジューラ上のスケジュールとそのスケジュールを生成したメーラ上のメールとが紐付けられ、スケジュール画面と関連メール画面との間で相互の行き来ができるようになっている。
【０００５】
ここで、スケジューラ上で、スケジュールの設定（日付・場所等）が変更された場合において、スケジュールの日付が変更されているにもかかわらず関連メールの本文の「古い」情報を見て間違った日付等で行動してしまう、というトラブルがよく発生する。
【０００６】
具体的な事例を以下に示す。
1)Ａさんが、メーラで開催者Ｂさんから「９：００から東京で会議」というメールＭを受信し、それをスケジューラに登録する。
2)Ａさんは、「会議を１３：００から大阪に変更」という連絡を受け、スケジューラ上のスケジューラを変更するが、そのことを忘れてしまう。
3)Ａさんは、後に詳細を確認するためにメーラ上で受信メールＭを閲覧した際、「９：００から東京で会議」という間違った情報を見て行動してしまう。
【０００７】
特に、スケジュールと関連するメールを一覧表示できるようなシステムでは、予定の詳細を確認するために「スケジュールと紐付いたメール」を閲覧する機会が多いため、このような間違いが発生しやすい。
【０００８】
また、「Ａさんのスケジュールデータを他人（開催者など）が変更できる」ようなシステムの場合、上述のような事例は更に発生しやすいと考えられる。
そこで、メール本文閲覧時に、予定が変更されたことがわかるような仕組みが求められる。
【０００９】
このような課題を解決するための従来技術として、訂正依頼メールを受信したとき、対象メールを特定し、該当箇所を修正したメールデータを新たに作成するという技術が知られている。
【００１０】
本出願が開示する技術に関連する従来技術として、下記先行技術文献が開示されている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００５−１２８７６７号公報
【特許文献２】特開２００８−１２３１４号公報
【特許文献３】特開平１１−１５０５５８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかし、上述の従来技術では、訂正依頼メールが特定のフォーマットでなければならないという制限がある。また、この従来技術は、訂正メール以外の手段でスケジュールが変更されたときに機能しないという問題点も有していた。
【００１３】
そこで、本発明の１つの側面では、通常フォーマットの訂正依頼メールやスケジューラによるスケジュール訂正に基づいて、そのスケジュールを生成した元メールの表示時に訂正内容を把握できるようにすることを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、態様の一例では、受信したメールメッセージをメッセージデータベースに記憶すると共に、該メールメッセージからスケジュール情報を抽出し、該スケジュール情報を前記メッセージデータベースに記憶されたメールメッセージと紐付けてスケジュールデータベースに記憶し、該スケジュール情報及び該メールメッセージを連動して表示するメール管理方法として実現され、以下の構成を有する。
【００１５】
まず、スケジュールデータベースに記憶されるスケジュール情報が訂正されたときに、そのスケジュール情報に紐付けられてメッセージデータベースに記憶されているメールメッセージが示すスケジュール情報とその訂正されたスケジュール情報との差分情報をメッセージ更新情報としてメッセージ更新情報データベースに記憶される。
【００１６】
そして、メッセージデータベースからメールメッセージが読み出されて表示される場合に、そのメールメッセージに対応するメッセージ更新情報がメッセージ更新情報データベースから読み出され、そのメッセージ更新情報に基づく訂正情報がそのメールメッセージと共に表示される。
【発明の効果】
【００１７】
開示する技術によれば、メールに書かれた古い日付情報を見てしまうことによる、スケジュールのトラブルの低減が期待できる。
また、スケジューラ経由又は訂正依頼メール経由、その他どのような方法によってスケジュール情報が訂正されても、それに紐付けられているメールメッセージの閲覧時に、常に最新のスケジュール情報を表示することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】メール・スケジュール連動システムの実施形態の構成図である。
【図２】実施形態におけるメール本文の表示動作を示す動作フローチャートである。
【図３】実施形態におけるメール一覧の表示動作を示す動作フローチャートである。
【図４】実施形態における訂正依頼メールの受信によるスケジュール制御処理を示す動作フローチャートである。
【図５】実施形態で使用されるデータベースのデータ構成例を示す図である。
【図６】実施形態におけるメール一覧の表示動作を示す動作説明図である。
【図７】実施形態の全体動作の説明図である。
【図８】実施形態を実現できるハードウェアシステムの構成例を示す図である。
【発明を実施するための形態】
【００１９】
以下、実施形態について詳細に説明する。
図１は、メール・スケジュール連動システムの実施形態を示す構成図である。
実施形態のシステムは例えば、クライアントコンピュータ１１５からインターネット又は社内ネットワーク（ローカルエリアネットワークや専用線ネットワークで構成されるイントラネット等）であるネットワーク１１７を介してアクセスされるサーバコンピュータ１００上で実現される。
【００２０】
サーバコンピュータ１００において、メール制御部１０１は、Ｗｅｂメーラの機能を実現する。スケジュール制御部１０２は、Ｗｅｂスケジューラの機能を実現する。
スケジュールデータベース（以下「スケジュールＤＢ」と呼ぶ）１０３は、スケジュール制御部１０２が使用するスケジュールデータ（以下単に「スケジュール」と呼ぶ）を蓄積する。
【００２１】
メッセージデータベース（以下「メッセージＤＢ」と呼ぶ）１０４は、メール制御部１０１が送受信するメールデータ（以下単に「メール」と呼ぶ）を蓄積する。
メッセージ更新情報データベース（以下「メッセージ更新情報ＤＢ１０５」と呼ぶ）１０５は、メール制御部１０１が送受信する訂正依頼メール又はスケジュール制御部１０２によるスケジュール訂正で訂正されたスケジュールメッセージの更新情報を蓄積する。
【００２２】
ＷＷＷサーバ部１１３は、クライアントコンピュータ１１５内のＷｅｂブラウザ部１１７からのＷｅｂアクセスリクエストを、メール制御部１０１又はスケジュール制御部１０２に通知する。また、ＷＷＷサーバ部１１３は、メール制御部１０１又はスケジュール制御部１０２からのＷｅｂアクセス応答を、クライアントコンピュータ１１５のＷｅｂブラウザ部１１６に返信する。
【００２３】
メール転送エージェント部１１４は、ネットワーク１１７を介して送受信されるメールを、メール制御部１０１との間で通信するメール転送サーバである。
メール制御部１０１は、メール表示・編集制御部１０６、最新スケジュール表示制御部１０７、メール送受信制御部１０８、訂正依頼メール解析部１０９、及び最新スケジュール更新部１１０を含む。
【００２４】
メール表示・編集制御部１０６は、クライアントコンピュータ１１５内のＷｅｂブラウザ部１１６からＷＷＷサーバ部１１３を介して受信されるリクエストに基づいて、メッセージＤＢ１０４に蓄積されているメールの表示及び編集を制御する。ここで、メールの編集とは、新規／返信／転送メールの作成、メールの削除、メール保存フォルダの管理等をいう。
【００２５】
最新スケジュール表示制御部１０７は、メール表示・編集制御部１０６がメッセージＤＢ１０４に蓄積されているメールを表示するときに、メッセージ更新情報ＤＢ１０５から対応するメッセージ更新情報を読み出す。そして、最新スケジュール表示制御部１０７は、同制御部１０６にて本文表示又は一覧表示されるメールに、更新情報を重ねて表示させる。
【００２６】
メール送受信制御部１０８は、メール転送エージェント部１１４から転送されてくる受信メールを受信し、それをメッセージＤＢ１０４に蓄積すると共に、訂正依頼メール解析部１０９に引き渡す。また、メール送受信制御部１０８は、メール表示・編集制御部１０６にて作成された送信メールを、メール転送エージェント部１１４に転送して送信しメッセージＤＢ１０４に蓄積する。また、メール送受信制御部１０８は、その送信メールを、訂正依頼メール解析部１０９に引き渡す。なお、メール送受信制御部１０８によるメールの送受信の制御動作及びメール表示・編集制御部１０６によるメールの作成の制御動作は、一般的なＷｅｂメーラシステムの場合と同様のため、その詳細な説明は省略する。
【００２７】
訂正依頼メール解析部１０９は、メール送受信制御部１０８から引き渡されたメールを取得し、そのメールの内容を、スケジュールＤＢ１０３内のスケジュール及びメッセージＤＢ１０４内のメールと比較する。これにより、メール送受信制御部１０８は、取得メールが、スケジュールの訂正依頼メールであるか否かを解析する。
【００２８】
最新スケジュール更新部１１０は、上記取得メールが訂正依頼メールであった場合に、スケジュールＤＢ１０３内の対応するスケジュールを、最新の内容に訂正する。また、最新スケジュール更新部１１０は、メッセージ更新情報ＤＢ１０５に、訂正内容を登録する。
【００２９】
スケジュール制御部１０２は、スケジュール表示・編集制御部１１１及び最新スケジュール更新部１１２を含む。
スケジュール表示・編集制御部１１１は、クライアントコンピュータ１１５内のＷｅｂブラウザ部１１６からＷＷＷサーバ部１１３を介して受信されるリクエストに基づいて、スケジュールＤＢ１０３に蓄積されているスケジュールの表示及び編集を制御する。ここで、スケジュールの編集とは、新規スケジュールの作成、訂正、削除等をいう。
【００３０】
最新スケジュール更新部１１２は、スケジュール表示・編集制御部１１１においてスケジュールが訂正されたときに、メッセージ更新情報ＤＢ１０５に、訂正内容を登録する。
以上の構成を有するメール・スケジュール連動システムの実施形態の動作について、以下に詳細に説明する。
【００３１】
図２は、メール本文表示動作を示す動作フローチャートである。この処理は、図１のサーバコンピュータ１００内のメール制御部１０１内のメール表示・編集制御部１０６及び最新スケジュール表示制御部１０７、並びに、クライアントコンピュータ１１５内のＷｅｂブラウザ部１１６が協調して動作することにより実現される。
【００３２】
まず、図１のクライアントコンピュータ１１５内のＷｅｂブラウザ部１１６において、Ｗｅｂメーラが操作されており、そこからの表示要求によって或るメールメッセージの本文の表示要求が発行される（図２のステップＳ２０１）。
【００３３】
次に、この本文表示要求は、図１のネットワーク１１７からサーバコンピュータ１００内のＷＷＷサーバ部１１３で受信され、メール制御部１０１へ転送される。この結果、メール制御部１０１内のメール表示・編集制御部１０６が、メッセージＤＢ１０４にアクセスすることにより、メッセージの本文情報を取得し、それをＷＷＷサーバ部１１３を介してＷｅｂブラウザ部１１６へ送信する。この結果、Ｗｅｂブラウザ部１１６は、上記メッセージの本文情報を取得し表示する（以上、図２のステップＳ２０２）。図５（ｂ）は、メッセージＤＢ１０４のデータ構成例を示す図である。各行がそれぞれ１件のメールメッセージに対応するレコードを示している。各レコードにおいて、「メッセージＩＤ」項目には、各メールメッセージを識別するための値が格納される。「ユーザＩＤ」項目には、そのメールを受信したユーザを識別するための値が格納される。「受信日時」項目には、そのメールの受信日時の値が格納される。「Ｆｒｏｍ」項目には、そのメールのＦｒｏｍフィールドに設定されているメールアドレス、即ちそのメールの送信者のメールアドレスが格納される。「Ｔｏ」項目には、そのメールのＴｏフィールドに設定されているメールアドレス、即ちそのメールの受信者のメールアドレスが格納される。「Ｃｃ」項目には、そのメールのＣｃフィールドに設定されているメールアドレス、即ちそのメールがコピーされて転送される宛先のメールアドレスが格納される。「件名」項目には、そのメールのＳｕｂｊｅｃｔフィールドに設定されている文字列、即ちメールの件名の文字列が格納される。「本文」項目には、そのメールの本文に設定されている文字列が格納される。図１のＷｅｂブラウザ部１１６上でＷｅｂメーラを操作するユーザは、各メールを、メッセージＩＤ及びユーザＩＤによって特定することができる。メール表示・編集制御部１０６は、メッセージＤＢ１０４にアクセスして、Ｗｅｂブラウザ部１１６から指定されたメッセージＩＤ及びユーザＩＤに対応するレコードを抽出する。そして、メール表示・編集制御部１０６は、そのレコードの「本文」項目内の文字列を読み出し、それをメッセージの本文情報としてＷｅｂブラウザ部１１６へ送信する。
【００３４】
次に、メール制御部１０１内の最新スケジュール表示制御部１０７が、メッセージ更新情報ＤＢ１０５に、ステップＳ２０２にて取得されたメッセージに対応するメールの本文の更新情報データが存在するか否かを検索する（図２のステップＳ２０３）。図５（ｃ）は、メッセージ更新情報ＤＢ１０５のデータ構成例を示す図である。各行がそれぞれ１件の訂正内容に対応するレコードを示している。各レコードにおいて、「メッセージＩＤ」項目には、訂正対象となるメールメッセージを識別するための値が格納される。この項目と、図５（ｂ）に示されるデータ構成例を有するメッセージＤＢ１０４の「メッセージＩＤ」項目とによって、メールメッセージとその訂正内容とが紐付けられることになる。なお、訂正内容は、本文及び件名それぞれについて複数存在することができる。図５（ｃ）において、「更新対象領域」項目には、訂正されるメールメッセージの対象が本文なのか件名なのか（図５（ｂ）参照）を識別するための文字列（「本文」又は「件名」の何れか又は両方）が格納される。「スケジュールの更新項目名」項目には、訂正内容が後述するデータ構成例（図５（ａ））を有するスケジュールＤＢ１０３上の「日時」項目なのか「場所」項目なのかを識別する文字列（「日時」又は「場所」）が格納される。「更新前文字列」項目には、メールメッセージにおいて訂正対象となる更新前の文字列部分を正規表現にて指定した文字列が格納される。「更新後文字列」項目には、メールメッセージにおいて訂正対象となる更新後の文字列が格納される。「更新日時」項目には、訂正が行われた日時の値が格納される。最新スケジュール表示制御部１０７は、メッセージ更新情報ＤＢ１０５において、「メッセージＩＤ」項目にステップＳ２０３で検索されたメッセージＩＤと同じ値が格納され、「更新対象領域」項目に文字列「本文」が格納されているレコードを検索する。
【００３５】
メールの本文の更新情報データが存在せずステップＳ２０３の判定がＮＯならば、図２の動作フローチャートの処理が終了する。この結果、Ｗｅｂブラウザ部１１６には、通常のメールメッセージの本文表示が行われる。
【００３６】
メールの本文の更新情報データが存在しステップＳ２０３の判定がＹＥＳならば、最新スケジュール表示制御部１０７は、図２のステップＳ２０４の動作を実行する。即ち、最新スケジュール表示制御部１０７は、検索された各レコードの「更新前文字列」項目と「更新後文字列」項目の各文字列の組合せを、ＷＷＷサーバ部１１３を介してＷｅｂブラウザ部１１６に送信する。
【００３７】
Ｗｅｂブラウザ部１１６は、ＷＷＷサーバ部１１３から取得したメールの本文の更新情報データのそれぞれの組に対して、順次以下の表示処理を実行する（図２のステップＳ２０５からＳ２０８までのループ処理）。
【００３８】
まず、Ｗｅｂブラウザ部１１６は、「更新前文字列」項目と「更新後文字列」項目の各文字列の組合せを取得する。そして、Ｗｅｂブラウザ部１１６は、「更新前文字列」項目で指定されている正規表現文字列にて、ステップＳ２０２で表示を行っているメール本文中の置換対象文字を検索する（図２のステップＳ２０６）。
【００３９】
次に、Ｗｅｂブラウザ部１１６は、検索された置換対象文字の上に重ねて、取消線と、「更新後文字列」項目の文字列である置換後文字列を描画する（図２のステップＳ２０７）。なお、この訂正内容の表示形態は、このような重ねての表示のほか、ポップアップ表示や、完全に置換しての表示であってもよい。
【００４０】
以上の描画処理が、図２のステップＳ２０５とＳ２０８の繰返し制御によって、各訂正対象の組合せ毎に繰返し実行されることにより、例えば図７の７０４として示されるような形態で、メール本文中の日時や場所が訂正された表示が行われる。これにより、ユーザは、スケジュールを生成した元のメールにおいて訂正された項目を容易に判断することが可能となる。
【００４１】
図２のステップＳ２０５からＳ２０８までの繰返し処理の終了により、メール本文の描画処理が終了する。
次に図３は、メール一覧表示動作を示す動作フローチャートである。この処理は、図１のサーバコンピュータ１００内のメール制御部１０１内のメール表示・編集制御部１０６及び最新スケジュール表示制御部１０７、並びに、クライアントコンピュータ１１５内のＷｅｂブラウザ部１１６が協調して動作することにより実現される。
【００４２】
まず、図１のクライアントコンピュータ１１５内のＷｅｂブラウザ部１１６において、Ｗｅｂメーラが操作されており、そこからの表示要求によってメールメッセージの一覧の表示要求が発行される（図３のステップＳ３０１）。
【００４３】
次に、この一覧表示要求は、図１のネットワーク１１７からサーバコンピュータ１００内のＷＷＷサーバ部１１３で受信され、メール制御部１０１へ転送される。この結果、メール制御部１０１内のメール表示・編集制御部１０６が、メッセージＤＢ１０４にアクセスすることにより、メッセージの一覧情報を取得し、それをＷＷＷサーバ部１１３を介してＷｅｂブラウザ部１１６へ送信する。この結果、Ｗｅｂブラウザ部１１６は、上記メッセージの一覧情報を取得し表示する（以上、図３のステップＳ３０２）。より具体的には、Ｗｅｂブラウザ部１１６からは、一覧表示されるべきメールメッセージ群の受信日時の範囲などが指定される。この結果、メール表示・編集制御部１０６は、メッセージＤＢ１０４にアクセスして、「受信日時」項目の値が、Ｗｅｂブラウザ部１１６から指定された受信日時の範囲に対応するレコード群を抽出する。そして、メール表示・編集制御部１０６は、それらのレコード群の各「件名」項目、各「Ｆｒｏｍ」項目（送信者項目）、各「受信日時」項目の各内容を読み出し、それらをメッセージの一覧情報としてＷｅｂブラウザ部１１６へ送信する。
【００４４】
次に、メール制御部１０１内の最新スケジュール表示制御部１０７が、メッセージ更新情報ＤＢ１０５に、ステップＳ３０２にて取得されたメッセージ群に対応するメールの件名の更新情報データが存在するか否かを検索する（図３のステップＳ３０３）。より具体的には、最新スケジュール表示制御部１０７は、メッセージ更新情報ＤＢ１０５において、「メッセージＩＤ」項目にステップＳ３０３で検索された各レコードのメッセージＩＤの何れかと同じ値が格納され、「更新対象領域」項目に文字列「件名」が格納されているレコード群を検索する。
【００４５】
メールの件名の更新情報データが存在せずステップＳ３０３の判定がＮＯならば、図３の動作フローチャートの処理が終了する。この結果、Ｗｅｂブラウザ部１１６には、通常のメールメッセージの一覧表示が行われる。
【００４６】
メールの件名の更新情報データが存在しステップＳ３０３の判定がＹＥＳならば、最新スケジュール表示制御部１０７は、図３のステップＳ３０４の動作を実行する。即ち、最新スケジュール表示制御部１０７は、検索された各レコードの「メッセージＩＤ」項目と「更新前文字列」項目と「更新後文字列」項目の各文字列の組合せを、ＷＷＷサーバ部１１３を介してＷｅｂブラウザ部１１６に送信する。
【００４７】
Ｗｅｂブラウザ部１１６は、ＷＷＷサーバ部１１３から取得したメールの件名の更新情報データのそれぞれの組に対して、順次以下の表示処理を実行する。
Ｗｅｂブラウザ部１１６は、ステップＳ３０５からＳ３１０までの繰返し処理として、「メッセージＩＤ」の値が同じ組群を選択し、ステップＳ３０２で表示しているメッセージ一覧上で、選択された組に対応する行の件名の文字列に対し以下の処理を実行する。
【００４８】
Ｗｅｂブラウザ部１１６は、「メッセージＩＤ」の値が同じ組群から、ステップＳ３０６からＳ３０９までの繰返し処理として各組のメッセージ更新情報を選択し、以下の一連の処理を実行する。
【００４９】
まず、Ｗｅｂブラウザ部１１６は、「更新前文字列」項目と「更新後文字列」項目の各文字列の組合せを取得する。そして、Ｗｅｂブラウザ部１１６は、「更新前文字列」項目で指定されている正規表現文字列にて、ステップＳ３０５で読み込んだ件名文字列中の置換対象文字を検索する（図３のステップＳ３０７）。
【００５０】
次に、Ｗｅｂブラウザ部１１６は、検索された置換対象文字の上に重ねて、取消線と、「更新後文字列」項目の文字列である置換後文字列を描画する（図３のステップＳ３０８）。なお、この訂正内容の表示形態は、このような重ねての表示のほか、ポップアップ表示や、完全に置換しての表示であってもよい。
【００５１】
以上の描画処理が、図３のステップＳ３０６とＳ３０９の繰返し制御によって、１つのメッセージの件名の各訂正対象の組合せ毎に繰返し実行され、更に、ステップＳ３０５とＳ３１０の繰返し制御によって、各メッセージの件名毎に繰返し実行される。この結果、例えば図６として示されるような形態で、メッセージ一覧中の各件名の日時や場所が訂正された表示が行われる。これにより、ユーザは、スケジュールを生成した元のメールの一覧においても、訂正された項目を容易に判断することが可能となる。
【００５２】
図３のステップＳ３０５からＳ３１０までの繰返し処理の終了により、メッセージ一覧の描画処理が終了する。
次に、上記訂正表示の契機となるスケジュールの訂正方法について、以下に説明する。
【００５３】
まず、スケジュールの第１の訂正方法として、スケジューラ上で、日時や場所を直接訂正する方法が考えられる。この場合には、クライアントコンピュータ１１５内のＷｅｂブラウザ部１１６からの要求により、サーバコンピュータ１００部のスケジュール制御部１０２内のスケジュール表示・編集制御部１１１がスケジューラを起動する。スケジュール表示・編集制御部１１１は、スケジュールＤＢ１０３にアクセスして、スケジュール情報を取得し、Ｗｅｂブラウザ部１１６に送信する。そして、ユーザが、Ｗｅｂブラウザ部１１６に表示されるスケジューラ上で、特定のスケジュールの日時や場所を修正する。この結果、スケジュール表示・編集制御部１１１が、スケジュールＤＢ１０３の登録内容を修正する。これと共に、最新スケジュール更新部１１２が、Ｗｅｂブラウザ部１１６から修正指示された日時や場所に基づくメッセージ更新情報を、メッセージ更新情報ＤＢ１０５に登録する。
【００５４】
図５（ａ）は、スケジュールＤＢ１０３のデータ構成例を示す図である。各行がそれぞれ１件のスケジュールに対応するレコードを示している。各レコードにおいて、「予定ＩＤ」項目には、各スケジュールを識別するための値が格納される。「メッセージＩＤ」項目には、各スケジュールと紐付けられているメールメッセージのメッセージＩＤが格納される。これにより、スケジュールＤＢ１０３上のスケジュールレコードとそのスケジュールレコードを生成したメッセージＤＢ１０４上のメールメッセージレコードとが紐付けられ、スケジュール画面と関連メール画面との間で相互の行き来ができるようになっている。「ユーザＩＤ」項目には、そのスケジュールを作成したユーザを識別するための値が格納される。「予定名」項目には、スケジュールの名称の文字列が格納される。「予定名単語」項目には、「予定名」項目の文字列が形態素解析等されることにより取得された、予定名を構成する単語の文字列が格納される。「日時」項目には、スケジュールの日時を示す値が格納される。「場所」項目には、スケジュールの場所を示す文字列が格納される。図１のスケジュール表示・編集制御部１１１は、これらの項目にアクセスしながら、Ｗｅｂブラウザ部１１６からの要求に従って、スケジュールの表示・編集を制御する。ここで、Ｗｅｂブラウザ部１１６から日時や場所が修正指示されると、スケジュールＤＢ１０３上の該当するレコードの「日時」項目と「場所」項目の内容が修正される。
【００５５】
これと共に、図１の最新スケジュール更新部１１２は、図５（ｃ）のデータ構成例を有するメッセージ更新情報ＤＢ１０５に、新たなメッセージ更新情報のレコードを登録する。具体的には、登録されるレコードの「メッセージＩＤ」項目には、スケジュールＤＢ１０３上の対象レコードの「メッセージＩＤ」項目と同じメッセージＩＤが格納される。また、登録されるレコードの「更新対象領域」には「件名」と「本文」の両方の文字列が格納ｓあれる。また、登録されるレコードの「スケジュールの更新項目」項目には、「日時」又は「場所」のうち修正されたスケジュール項目の文字列が格納される。登録されるレコードの「更新前文字列」には、修正されたスケジュールの更新前の文字列を指示する正規表現の文字列が格納される。登録されるレコードの「更新後文字列」には、修正されたスケジュールの更新後の文字列が格納される。「更新日時」項目には、スケジュールの修正日時の値が格納される。
【００５６】
このようにして、スケジューラ上でのスケジュールの修正に対応して、メッセージ更新情報ＤＢ１０５にメッセージ更新情報が登録されることにより、そのスケジュールに対応するメールメッセージの表示時に、前述した図２又は図３の動作フローチャートの制御によって、適切な訂正表示を行うことが可能となる。
【００５７】
次に、スケジュールの第２の訂正方法として、訂正依頼メールの受信による方法が考えられる。
従来、メールの受信を契機としてスケジュールを変更するには、ある特定のフォーマットのメールを送信しなければならなかった。以下に説明する方法では、通常のメールから抽出されるヘッダ情報、本文情報が分析され、「訂正依頼メール」と判定される。これにより、送信者は何も意識することなく、通常通り「スケジュールが変更になった旨のメール」を送るだけで、受信者のスケジュールを変更することができる。
【００５８】
訂正依頼メールの一般的な形態としては、以下の２つの形態が考えられる。
訂正依頼メール形態１：開催通知メールが引用されて送信される場合
自分が送信した開催通知メールを引用又は転送し、その上に新日程を追記する方式であり、ビジネスメールとしては一般的な方式である。
【００５９】
この時、以下のように訂正依頼メールかどうかを判定することができる。
1)「本文から抽出した情報」と「登録済みスケジュール情報（紐づいているメールメッセージ情報を含む）」が合致する。
2)新日付情報が存在する。
3)両方とも未来の予定である。
【００６０】
訂正依頼メール形態２：開催通知メールの引用なしで、同じような内容のメールがもう一度送信される場合
「自分の送信メールボックス内の開催通知メールを再編集する」などの方法で、開催通知メールと類似した内容でメールを送信する方式である。
【００６１】
多くの場合、Ｆｒｏｍ，Ｔｏ，Ｃｃ，Ｂｃｃフィールドが同一であり、件名・本文ともに類似度が高い。
よって、「本文から抽出した情報」と「登録済みスケジュール情報（紐づいているメールメッセージ情報を含む）」のうち、Ｆｒｏｍ，Ｔｏ，Ｃｃ，Ｂｃｃが同一で、かつ件名・本文ともに類似度が高い場合、訂正依頼メールと判断することができる。
【００６２】
図４は、上述の判定基準に基づく、訂正依頼メールの受信によるスケジュール制御処理を示す動作フローチャートである。この処理は、図２のサーバコンピュータ１００内のメール制御部１０１内のメール送受信制御部１０８、訂正依頼メール解析部１０９、及び最新スケジュール更新部１１０が協調して動作することにより実現される。
【００６３】
まず、メール送受信制御部１０８が、メールを受信し、受信したメールデータをメッセージＤＢ１０４に登録する（図４のステップＳ４０１）。
次に、訂正依頼メール解析部１０９が、受信したメールの本文中の日付文字列を探索する（図４のステップＳ４０２）。
【００６４】
次に、訂正依頼メール解析部１０９は、日付文字列が探索できたか否かを判定する（図４のステップＳ４０３）。
日付文字列が探索できずステップＳ４０３の判定がＮＯならば、訂正依頼メール解析部１０９は、そのままスケジュール訂正処理を終了する。
【００６５】
日付文字列が探索できステップＳ４０３の判定がＹＥＳならば、訂正依頼メール解析部１０９は、メール本文中から、日付文字列、場所、参加者、詳細情報などを抽出することにより、スケジュール情報を抽出する（図４のステップＳ４０４）。以下、この情報を、スケジュール情報（Ｃ）と呼ぶ。
【００６６】
次に、訂正依頼メール解析部１０９は、スケジュール情報（Ｃ）に基づき、スケジュールＤＢ１０３及びメッセージＤＢ１０４上で、旧スケジュール（以下、これをスケジュール（Ｅ）と呼ぶ）と関連メール情報（Ｆｒｏｍ，Ｔｏ等から判断）を検索する（図４のステップＳ４０５）。具体的には、この検索においては、スケジュールＤＢ１０３上の「予定名単語」、「日時」、「場所」等の項目が検索される。また、メッセージＤＢ１０４上の「Ｆｒｏｍ」「Ｔｏ」「件名」「本文」項目が検索れる。
【００６７】
次に、訂正依頼メール解析部１０９は、Ｆｒｏｍ，Ｔｏ，Ｃｃ，日付文字列、場所等が一致するデータがあったか否かを判定する（図４のステップＳ４０６）。
ステップＳ４０６の判定がＹＥＳの場合は、以下の処理が実行される。これは、前述の訂正依頼メール形態１に対応し、例えば返信メールなどのように、開催通知メールの情報が本文にそのまま含まれているような場合である。この場合には、図１の最新スケジュール更新部１１０は、受信されているメールの本文中に含まれる情報のうち、スケジュール情報（Ｃ）以外のスケジュール情報（Ｄ）で、スケジュールＤＢ１０３中の該当するレコードのスケジュールデータを更新する。また、最新スケジュール更新部１１０は、新スケジュール（Ｄ）と旧スケジュール（Ｅ）の差分の情報を、メッセージ更新情報ＤＢ１０５に新たなレコードとして登録する。更に、最新スケジュール更新部１１０は、新たに受信したメールのメッセージＩＤを、スケジュールＤＢ１０３中の対象レコードの「メッセージＩＤ」項目（図５（ａ）参照）に追加する（以上、図４のステップＳ４０７）。なお、複数のスケジュールデータが存在する場合には、例えば情報量が最も多いスケジュールデータが優先されて新スケジュール（Ｄ）とされる。
【００６８】
一方、ステップＳ４０６の判定がＮＯの場合は、訂正依頼メール解析部１０９は更に、Ｆｒｏｍ，Ｔｏ，Ｃｃが一致し、件名・本文の類似度が所定の閾値以上のデータがあったか否かを判定する（図４のステップＳ４０８）。
【００６９】
ステップＳ４０８の判定がＹＥＳの場合は、以下の処理が実行される。これは、前述の訂正依頼メール形態２に対応し、再編集メールの場合メールの内容が似ていることを利用する場合である。ここで、件名・本文の類似度の比較方法としては例えば、形態素解析にて得られるスケジュールＤＢ１０３の各レコード中の「予定名単語」に登録されている単語同士の比較が行われ、類似度の高い予定データが抽出される。類似度は例えば、一致する単語の割合として算出される。この場合には、図１の最新スケジュール更新部１１０は、受信されているメールの本文中に含まれるスケジュール情報（Ｃ）でスケジュールＤＢ１０３中の該当するレコードの内容を更新する。また、最新スケジュール更新部１１０は、新スケジュール（Ｃ）と旧スケジュール（Ｅ）の差分の情報を、メッセージ更新情報ＤＢ１０５に新たなレコードとして登録する。更に、最新スケジュール更新部１１０は、新たに受信したメールのメッセージＩＤを、スケジュールＤＢ１０３中の対象レコードの「メッセージＩＤ」項目（図５（ａ）参照）に追加する（以上、図４のステップＳ４０９）。
【００７０】
ステップＳ４０８の判定がＮＯならば、最新スケジュール更新部１１０は、受信されているメールの本文中に含まれるスケジュール情報（Ｃ）を、スケジュールＤＢ１０３に新規スケジュールのレコードとして登録する。また、最新スケジュール更新部１１０は、新たに受信したメールのメッセージＩＤを、スケジュールＤＢ１０３中の対象レコードの「メッセージＩＤ」項目（図５（ａ）参照）に追加する（図４のステップＳ４１０）。
【００７１】
図４のステップＳ４０７、Ｓ４０９、又はＳ４１０の処理の後、訂正依頼メールの受信によるスケジュール制御処理を終了する。
このようにして、訂正依頼メールが自動的に判断されて、メッセージ更新情報ＤＢ１０５にメッセージ更新情報が登録されることにより、そのスケジュールに対応するメールメッセージの表示時に、前述した図２又は図３の動作フローチャートの制御によって、適切な訂正表示を行うことが可能となる。
【００７２】
図７は、上述の本実施形態の一連の制御動作を説明するための動作説明図である。
まず、Ｗｅｂメーラ上で、７０１として示されるような形態で受信メールが表示される。ここで、自動的に或いはユーザが表示メール上の日付文字列をクリックすることによって、そのメールが紐付けられて、スケジュールが７０２として示されるような形態で自動登録される（図４のステップＳ４１０）。
【００７３】
ここで受信メールが訂正メールと判断されれば、７０３として示されるように、該当するスケジュールが自動的に訂正される（図４のステップＳ４０７、Ｓ４０９）。以上の訂正内容は、前述しようにメッセージ更新情報ＤＢ１０５に登録される（図４のステップＳ４０７、Ｓ４０９）。また、スケジュールの変更は、前述したように、ユーザがスケジューラから実行してもよい。
【００７４】
Ｗｅｂメーラ上でのメールの表示時には、それが紐付けられているスケジュールの訂正内容に合わせて、前述した図２又は図３の動作フローチャートの制御によって、７０４として示されるような適切な訂正表示が行われる。このとき、図７に示されるように、例えば自動的に「訂正メールへジャンプ」ボタンが表示されるようにしてもよく、これにより訂正依頼メールも表示させることが可能となる。
【００７５】
以上説明した実施形態では、スケジュールの訂正は、スケジューラ経由又は訂正依頼メール経由によって実行されているが、その他、掲示板やＲＳＳ配信など、メーラやスケジューラ意外のシステムによって訂正されるように構成されてもよい。
【００７６】
図８は、図１のサーバコンピュータ１００のシステムを実現できるコンピュータのハードウェア構成の一例を示す図である。
図８に示されるコンピュータは、ＣＰＵ８０１、メモリ８０２、入力装置８０３、出力装置８０４、外部記憶装置８０５、可搬記録媒体８０９が挿入される可搬記録媒体駆動装置８０６、及びネットワーク接続装置８０７を有し、これらがバス８０８によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。
【００７７】
ＣＰＵ８０１は、当該コンピュータ全体の制御を行う。メモリ８０２は、プログラムの実行、データ更新等の際に、外部記憶装置８０５（或いは可搬記録媒体８０９）に記憶されているプログラム又はデータを一時的に格納するＲＡＭ等のメモリである。ＣＵＰ８０１は、プログラムをメモリ８０２に読み出して実行することにより、全体の制御を行う。
【００７８】
入力装置８０３は、例えば、キーボード、マウス等及びそれらのインタフェース制御装置とからなる。入力装置８０３は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をＣＰＵ８０１に通知する。
【００７９】
出力装置８０４は、表示装置、印刷装置等及びそれらのインタフェース制御装置とからなる。出力装置８０４は、ＣＰＵ８０１の制御によって送られてくるデータを表示装置や印刷装置に出力する。
【００８０】
外部記憶装置８０５は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。
可搬記録媒体駆動装置８０６は、光ディスクやＳＤＲＡＭ、コンパクトフラッシュ等の可搬記録媒体８０９を収容するもので、外部記憶装置８０５の補助の役割を有する。
【００８１】
ネットワーク接続装置８０７は、例えばＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）の通信回線を接続するための装置である。
前述した図１のサーバコンピュータ１００の各部分を実現するシステムは、それに必要な機能を搭載したプログラム（スクリプトを含む）をＣＰＵ８０１が実行することで実現される。そのプログラムは、例えば外部記憶装置８０５や可搬記録媒体８０９に記録して配布してもよく、或いはネットワーク接続装置８０７によりネットワークから取得できるようにしてもよい。
【符号の説明】
【００８２】
１００  サーバコンピュータ
１０１  メール制御部
１０２  スケジュール制御部
１０３  スケジュールＤＢ（スケジュールデータベース）
１０４  メッセージＤＢ（メッセージデータベース）
１０５  メッセージ更新情報ＤＢ（メッセージ更新情報データベース）
１０６  メール表示・編集制御部
１０７  最新スケジュール表示制御部
１０８  メール送受信制御部
１０９  訂正依頼メール解析部
１１０、１１２  最新スケジュール更新部
１１１  スケジュール表示・編集制御部
１１３  ＷＷＷサーバ部
１１４  メール転送エージェント部
１１５  クライアントコンピュータ
１１６  Ｗｅｂブラウザ部
１１７  ネットワーク
【図１】
2010282415.tif 000003
【図２】
2010282415.tif 000004
【図３】
2010282415.tif 000005
【図４】
2010282415.tif 000006
【図５】
2010282415.tif 000007
【図６】
2010282415.tif 000008
【図８】
2010282415.tif 000009
【図７】
2010282415.tif 000010