(57)【要約】【課題】  同一スレッドのウェブメールのデータを連鎖的に共通鍵として用いることにより、外部のネットワークに送出されるウェブメールによる情報漏洩を防止すること。【解決手段】  返信ではない新規のウェブメールを送信する場合は、当該新規のウェブメールを暗号化及び復号するための共通鍵データとなるルートメールを生成し、該ルートメールから得られる共通鍵データを用いて前記新規のウェブメールを暗号化する。また、返信のウェブメールを送信する場合は、返信元メールから得られる共通鍵データを用いて前記返信のウェブメールを暗号化し、暗号化メールスレッド中のルートメール及びウェブメールに含まれる前記共通鍵データを用いて、前記暗号化されて外部から送信されてくるウェブメールを連鎖的に復号する。【選択図】図５
2011097480.tif 000002
【特許請求の範囲】
【請求項１】
ウェブメールのサービスを提供するウェブメールサーバと通信可能であり、該ウェブメールの暗号化と復号化を制御するメール暗号復号制御装置であって、
返信ではない新規のウェブメールを送信する場合に、当該新規のウェブメールを暗号化及び復号化するための共通鍵データとなるルートメールを生成するルートメール生成手段と、
前記ルートメール生成手段で生成されるルートメールから得られる共通鍵データを用いて、前記新規のウェブメールを暗号化する第１暗号化手段と、
返信のウェブメールを送信する場合に、返信元メールから得られる共通鍵データを用いて、前記返信のウェブメールを暗号化する第２暗号化手段と、
前記ルートメール生成手段により生成されたルートメールを記憶する記憶手段と、
前記第１暗号化手段で暗号化された前記新規のウェブメールと前記第２暗号化手段で暗号化されたウェブメールとが記憶されたウェブメールサーバから暗号化されて送信されてくるウェブメールを表示する場合に、当該ウェブメールの親となるウェブメールを、前記ルートメールまで、前記記憶手段に記憶されたルートメールと前記ウェブメールサーバに記憶されたウェブメールの中から特定して暗号化メールスレッドを抽出する抽出手段と、
前記抽出手段により抽出された暗号化メールスレッド中のルートメール及びウェブメールに含まれる前記共通鍵データを用いて、前記暗号化されて送信されてくるウェブメールを復号する復号手段と、
を備えることを特徴とするメール暗号復号制御装置。
【請求項２】
前記返信のウェブメールを送信する場合に、前記返信元メールの宛先及び送信元に設定されていないメールアドレスが、当該返信のウェブメールの宛先に新規に追加されたかを判定する判定手段と、
前記判定手段で、返信のウェブメールの宛先に当該メールアドレスが追加されたと判定された場合に、当該追加された宛先に対して、前記抽出手段により抽出される暗号化メールスレッドを送信する送信手段と、
を更に備えることを特徴とする請求項１に記載のメール暗号復号制御装置。
【請求項３】
前記抽出手段で抽出される暗号化メールスレッド中のウェブメールの削除指示を受け付けた場合に、前記復号手段は、更に、当該暗号化メールスレッド中の最終日時に送信又は受信されたウェブメールを、当該暗号化メールスレッド中のルートメール及びウェブメールに含まれる前記共通鍵データを用いて復号し、
前記記憶手段は、更に、前記復号手段で復号された前記最終日時に送信されたウェブメールを記憶することを特徴とする請求項１又は２に記載のメール暗号復号制御装置。
【請求項４】
前記抽出手段で抽出される暗号化メールスレッド中のウェブメールの削除指示を受け付けた場合に、当該削除指示されたウェブメール以降に送信及び／又は受信した電子メールを、前記暗号化メールスレッドの中から特定する特定手段と、
前記特定手段で、当該削除指示されたウェブメール以降に送信及び／又は受信した電子メールが特定された場合に警告を出力する警告手段と、
を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載のメール暗号復号制御装置。
【請求項５】
ウェブメールのサービスを提供するウェブメールサーバと通信可能であり、該ウェブメールの暗号化と復号化を制御するメール暗号復号制御装置における制御方法であって、
ルートメール生成手段が、返信ではない新規のウェブメールを送信する場合に、当該新規のウェブメールを暗号化及び復号化するための共通鍵データとなるルートメールを生成するルートメール生成工程と、
第１暗号化手段が、前記ルートメール生成工程で生成されるルートメールから得られる共通鍵データを用いて、前記新規のウェブメールを暗号化する第１暗号化工程と、
第２暗号化手段が、返信のウェブメールを送信する場合に、返信元メールから得られる共通鍵データを用いて、前記返信のウェブメールを暗号化する第２暗号化工程と、
記憶手段が、前記ルートメール生成工程により生成されたルートメールを記憶する記憶工程と、
抽出手段が、前記第１暗号化工程で暗号化された前記新規のウェブメールと前記第２暗号化工程で暗号化されたウェブメールとが記憶されたウェブメールサーバから暗号化されて送信されてくるウェブメールを表示する場合に、当該ウェブメールの親となるウェブメールを、前記ルートメールまで、前記記憶工程で記憶されたルートメールと前記ウェブメールサーバに記憶されたウェブメールの中から特定して暗号化メールスレッドを抽出する抽出手段と、
復号手段が、前記抽出工程により抽出された暗号化メールスレッド中のルートメール及びウェブメールに含まれる前記共通鍵データを用いて、前記暗号化されて送信されてくるウェブメールを復号する復号工程と、
を備えることを特徴とするメール暗号復号制御装置における制御方法。
【請求項６】
ウェブメールのサービスを提供するウェブメールサーバと通信可能であり、該ウェブメールの暗号化と復号化を制御するメール暗号復号制御装置において実行可能なプログラムであって、
前記メール暗号復号制御装置を、
返信ではない新規のウェブメールを送信する場合に、当該新規のウェブメールを暗号化及び復号化するための共通鍵データとなるルートメールを生成するルートメール生成手段と、
前記ルートメール生成手段で生成されるルートメールから得られる共通鍵データを用いて、前記新規のウェブメールを暗号化する第１暗号化手段と、
返信のウェブメールを送信する場合に、返信元メールから得られる共通鍵データを用いて、前記返信のウェブメールを暗号化する第２暗号化手段と、
前記ルートメール生成手段により生成されたルートメールを記憶する記憶手段と、
前記第１暗号化手段で暗号化された前記新規のウェブメールと前記第２暗号化手段で暗号化されたウェブメールとが記憶されたウェブメールサーバから暗号化されて送信されてくるウェブメールを表示する場合に、当該ウェブメールの親となるウェブメールを、前記ルートメールまで、前記記憶手段に記憶されたルートメールと前記ウェブメールサーバに記憶されたウェブメールの中から特定して暗号化メールスレッドを抽出する抽出手段と、
前記抽出手段により抽出された暗号化メールスレッド中のルートメール及びウェブメールに含まれる前記共通鍵データを用いて、前記暗号化されて送信されてくるウェブメールを復号する復号手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メール暗号復号制御装置及びその制御方法、プログラムに関し、特にウェブメールにおける暗号化管理技術に関するものである。
【背景技術】
【０００２】
近年のネットワーク技術の発達により、情報のやりとりにかかるコストが格段に低下する中、個人や各企業では電子メールやウェブサービスといったインターネットを利用した各種サービスを利用することにより、効率的な情報伝達ができるようになった。
【０００３】
２００５年の個人情報保護法の施行を始めとして、特に企業を始めとした組織では情報管理について厳格な対応を求められることになり、例えば、情報漏洩対策として、社外へ外部送信する電子メールの内容チェックを行うなど、組織が予め定めた基準に合致した場合のみ、外部への情報送信を許可するといった送信制御システムを導入することが一般的になっている。
【０００４】
さらに最近では、ＳａａＳ（Ｓｏｆｔｗａｒｅ  Ａｓ  Ａ  Ｓｅｒｖｉｃｅ）といったネットワークコンピューティング形態を利用する組織もある。Ｓａａｓを利用したいと考える組織は、メールシステム等の情報システムを組織内に持たないことによる管理・運用コストの削減を主目的としており、従来の電子メールの代わりにウェブブラウザを利用したウェブメールを利用することが多い。
【０００５】
ウェブメールを利用する場合においても、前述した情報漏洩対策は必要である。情報漏洩の原因として、利用者による誤送信や、ウェブメールサービスの脆弱性（例えば、ログインアカウントの漏洩など）による侵入、内部犯行による意図的なウェブメールの閲覧・改ざんなどが考えられる。このような状況に対応する情報漏洩防止の方法のひとつに、暗号化メールがある。
【０００６】
現在、暗号化メールとして利用可能な技術として、Ｓ／ＭＩＭＥ、ＰＧＰ（Ｐｒｅｔｔｙ  Ｇｏｏｄ  Ｐｒｉｖａｃｙ）などが存在するが、運用コストの増加等の理由により、あまり積極的に利用されている状況とは言いがたい。このような現状において、パスワード保護されたＺＩＰアーカイブを利用する人が、近年多くなってきた。この手法は、重要な文書はパスワード保護されたＺＩＰアーカイブ内に保存し、前記ＺＩＰアーカイブを第一のメールに添付して送信してから、第二のメールに前記ＺＩＰアーカイブのパスワードを記述して同じ宛先へ送信するという手法である。この手法では、
・別経路でパスワードを送付する等しない限り、盗聴や改ざんの可能性がある
・利用者が注意深く第二のメールを送信しないと、誤送信する可能性が高い
【０００７】
という特徴があり、本質的に安全とは言えない。しかしながら、前述したような暗号化メールの仕組みを導入するよりも安易に実現できることから、ウェブメールにおいても積極的に利用されている。
【０００８】
また、情報漏洩防止の観点から鑑みて、暗号化メールを利用している場合においても、正しい権限を持った人物が情報監視（内容監査）を実施できる必要もある。
【０００９】
このようなメール本文を暗号化するように、コンテンツを暗号化して送信する手法として、特許文献１に開示されている手法がある。この手法では、予め受信して蓄積した複数コンテンツに組み込まれた複数鍵を使用してコンテンツの復号を実施する方法を開示している。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００８−１６５４８６号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ウェブメールにおいて暗号化メールを利用するにあたって、情報保護（暗号化）と情報監視（内容監査）という、相反する要求あり、更には、公開鍵暗号方式の認証局のような鍵管理コスト（運用コスト）を可能な限り抑えたいという課題がある。
【００１２】
更に、スレッド単位でウェブメールの改ざんがされていないことを確かめることが困難であった（スレッド単位でウェブメールの原本性を保証することが困難であった）。即ち、暗号化メールシステムの運用コストを抑えつつ情報監視が可能であり、第三者への誤送信が発生しても容易に情報漏洩させない仕組みを提供することが困難であった。
更に、ウェブメールの内容を、ウェブメールサービスを提供している者に容易に閲覧できないようにすることにより、情報漏洩を防止することが困難であった。
【００１３】
本発明の目的は、同一スレッドのウェブメールのデータを共通鍵として用いることにより、外部ネットワークに送出されるウェブメールによる情報漏洩を防止する仕組みを提供することである。
【課題を解決するための手段】
【００１４】
本発明は、ウェブメールのサービスを提供するウェブメールサーバと通信可能であり、該ウェブメールの暗号化と復号化を制御するメール暗号復号制御装置であって、返信ではない新規のウェブメールを送信する場合に、当該新規のウェブメールを暗号化及び復号化するための共通鍵データとなるルートメールを生成するルートメール生成手段と、前記ルートメール生成手段で生成されるルートメールから得られる共通鍵データを用いて、前記新規のウェブメールを暗号化する第１暗号化手段と、返信のウェブメールを送信する場合に、返信元メールから得られる共通鍵データを用いて、前記返信のウェブメールを暗号化する第２暗号化手段と、前記ルートメール生成手段により生成されたルートメールを記憶する記憶手段と、前記第１暗号化手段で暗号化された前記新規のウェブメールと前記第２暗号化手段で暗号化されたウェブメールとが記憶されたウェブメールサーバから暗号化されて送信されてくるウェブメールを表示する場合に、当該ウェブメールの親となるウェブメールを、前記ルートメールまで、前記記憶手段に記憶されたルートメールと前記ウェブメールサーバに記憶されたウェブメールの中から特定して暗号化メールスレッドを抽出する抽出手段と、前記抽出手段により抽出された暗号化メールスレッド中のルートメール及びウェブメールに含まれる前記共通鍵データを用いて、前記暗号化されて送信されてくるウェブメールを復号する復号手段と、を備えることを特徴とする。
【００１５】
また、本発明は、ウェブメールのサービスを提供するウェブメールサーバと通信可能であり、該ウェブメールの暗号化と復号化を制御するメール暗号復号制御装置における制御方法であって、ルートメール生成手段が、返信ではない新規のウェブメールを送信する場合に、当該新規のウェブメールを暗号化及び復号化するための共通鍵データとなるルートメールを生成するルートメール生成工程と、第１暗号化手段が、前記ルートメール生成工程で生成されるルートメールから得られる共通鍵データを用いて、前記新規のウェブメールを暗号化する第１暗号化工程と、第２暗号化手段が、返信のウェブメールを送信する場合に、返信元メールから得られる共通鍵データを用いて、前記返信のウェブメールを暗号化する第２暗号化工程と、記憶手段が、前記ルートメール生成工程により生成されたルートメールを記憶する記憶工程と、抽出手段が、前記第１暗号化工程で暗号化された前記新規のウェブメールと前記第２暗号化工程で暗号化されたウェブメールとが記憶されたウェブメールサーバから暗号化されて送信されてくるウェブメールを表示する場合に、当該ウェブメールの親となるウェブメールを、前記ルートメールまで、前記記憶工程で記憶されたルートメールと前記ウェブメールサーバに記憶されたウェブメールの中から特定して暗号化メールスレッドを抽出する抽出手段と、復号手段が、前記抽出工程により抽出された暗号化メールスレッド中のルートメール及びウェブメールに含まれる前記共通鍵データを用いて、前記暗号化されて送信されてくるウェブメールを復号する復号工程と、を備えることを特徴とする。
【００１６】
また、本発明は、ウェブメールのサービスを提供するウェブメールサーバと通信可能であり、該ウェブメールの暗号化と復号化を制御するメール暗号復号制御装置において実行可能なプログラムであって、前記メール暗号復号制御装置を、返信ではない新規のウェブメールを送信する場合に、当該新規のウェブメールを暗号化及び復号化するための共通鍵データとなるルートメールを生成するルートメール生成手段と、前記ルートメール生成手段で生成されるルートメールから得られる共通鍵データを用いて、前記新規のウェブメールを暗号化する第１暗号化手段と、返信のウェブメールを送信する場合に、返信元メールから得られる共通鍵データを用いて、前記返信のウェブメールを暗号化する第２暗号化手段と、前記ルートメール生成手段により生成されたルートメールを記憶する記憶手段と、前記第１暗号化手段で暗号化された前記新規のウェブメールと前記第２暗号化手段で暗号化されたウェブメールとが記憶されたウェブメールサーバから暗号化されて送信されてくるウェブメールを表示する場合に、当該ウェブメールの親となるウェブメールを、前記ルートメールまで、前記記憶手段に記憶されたルートメールと前記ウェブメールサーバに記憶されたウェブメールの中から特定して暗号化メールスレッドを抽出する抽出手段と、前記抽出手段により抽出された暗号化メールスレッド中のルートメール及びウェブメールに含まれる前記共通鍵データを用いて、前記暗号化されて送信されてくるウェブメールを復号する復号手段として機能させることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、同一スレッドのウェブメールのデータを共通鍵として用いることにより、外部ネットワークに送出されるウェブメールによる情報漏洩を防止することができる効果を奏する。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施形態に係るシステムの構成例を示す図である。
【図２】本発明の実施形態のウェブメールクライアント装置１００のハードウェア構成を示す図である。
【図３】本発明の実施形態に係るブラウザの拡張機能を示すブロック図である。
【図４】本発明の実施形態のメールサマリの一例を示す図である。
【図５】本発明の実施形態の暗号化メールスレッドの構成例を示す図である。
【図６】本発明の実施形態の転送処理を含む暗号化メールスレッドの構成例を示す図である。
【図７】返信ではない新規のウェブメールを暗号化して送信するときの一例を示すシーケンス図である。
【図８】本発明の実施形態のブラウザ拡張機能の初期化処理を示すフローチャートである。
【図９】本発明の実施形態のウェブメール送信処理を示すフローチャートである。
【図１０】本発明の実施形態の親メール検出処理を示すフローチャートである。
【図１１】本発明の実施形態の親メール検索条件選定処理を示すフローチャートである。
【図１２】本発明の実施形態のルートメール作成処理を示すフローチャートである。
【図１３】本発明の実施形態のメール暗号化処理を示すフローチャートである。
【図１４】本発明の実施形態のルートメール送信処理を示すフローチャートである。
【図１５】本発明の実施形態のルートメール削除処理を示すフローチャートである。
【図１６】本発明の実施形態の全親スレッド送信処理を示すフローチャートである。
【図１７】本発明の実施形態の親メール集合作成処理を示すフローチャートである。
【図１８】本発明の実施形態のウェブメール表示処理を示すフローチャートである。
【図１９】本発明の実施形態のメール復号処理を示すフローチャートである。
【図２０】本発明の実施形態のウェブメール削除処理を示すフローチャートである。
【図２１】本発明の実施形態の検索条件選定処理を示すフローチャートである。
【図２２】本発明の実施形態のルール管理部３０１の一例である。
【図２３】本発明の実施形態のルートメール情報の一例を示す図である。
【図２４】本発明の実施形態のルートメール情報の実施例を示す図である。
【図２５】本発明の実施形態のメールスレッドの実施例を示す図である。
【図２６】本発明の実施形態の暗号化メールスレッドの実施例を示す図である。
【発明を実施するための形態】
【００１９】
以下、添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。  
【００２０】
図１は、本発明の一実施形態を示すウェブメール管理装置について、システムの構成例を示す図である。  
【００２１】
図１において、１００及び１１０はウェブメールクライアント装置を表す。広域ネットワーク網１２０は、インターネットを始めとするネットワークである。１３０はウェブメールサービスを提供するウェブメールサーバを表す。  
【００２２】
ウェブメールクライアント装置１００は、ウェブブラウザ１０１と、ウェブブラウザ拡張機能１０２とを備える。ウェブメールクライアント装置１１０も同様に、ウェブブラウザ１１１と、ウェブブラウザ拡張機能１１２とを備える。  
【００２３】
ウェブメールクライアント装置１００を使用してウェブメールサービスを利用する場合、利用者はウェブブラウザ１０１を使用して、ウェブメールサーバ１３０へアクセスする。従来の電子メール（ＳＭＴＰ方式）との違いは、ウェブメールサービスにおいて送受信したメール本体は、ウェブメールクライアント装置１００内に保存されるのではなく、ウェブメールサーバ１３０内に保存されることである。ウェブブラウザ１０１は、ウェブブラウザ拡張機能１０２を必要に応じて呼び出しながら、ウェブメールサーバ１３０にアクセスする。ウェブブラウザ拡張機能１０２の詳細については、後述する。  
【００２４】
なお、図１に示す実施形態に、人事情報に基づいた認証用サーバーや設定情報保存サーバーをイントラネット（即ち、広域ネットワーク網１２０よりウェブメールクライアント装置１００及び１１０側）に設置することで、ウェブメールクライアント装置１００及び１１０の設置場所等に制限されることなく、利用者は使用していないウェブメールクライアント装置を適宜利用することが可能となる。  
【００２５】
図２は、ウェブメールクライアント装置１００のハードウェア構成を示すブロック図である。  
【００２６】
図２において、２０１はＣＰＵで、ＲＡＭ２０２やＲＯＭ２０４に格納されているプログラムやデータを用いてウェブメールクライアント装置１００全体の制御を行うと共に、ウェブメールクライアント装置１００が行う後述の各処理を実施する。  
【００２７】
ＲＡＭ２０２は、ＨＤＤ（ハードディスクドライブ）２０４や記憶媒体ドライブ２０６からロードされたプログラムやデータ、ネットワークＩ／Ｆ（インターフェース）２０５を介して外部から受信したプログラムやデータなどを一時的に記憶するためのエリアや、ＣＰＵ２０１が各種の処理を実行する際に用いるワークエリアなど、各種のエリアを適宜提供することができる。  
【００２８】
ＲＯＭ２０３は、ウェブメールクライアント装置１００の設定データや、ブートプログラムなどを格納する。  
【００２９】
ＨＤＤ２０４は、ＯＳ（オペレーティングシステム）や、ウェブメールクライアント装置１００が行う後述の各処理をＣＰＵ２０１に実行させるためのプログラムやデータなどを保存するためのものであり、これらはＣＰＵ２０１による制御に従って適宜ＲＡＭ２０２にロードされ、ＣＰＵ２０１による処理対象となる。  
【００３０】
ネットワークＩ／Ｆ２０５は、ウェブメールクライアント装置１００を広域ネットワーク網１２０に接続するためのものであり、ウェブメールクライアント装置１００はこのネットワークＩ／Ｆ２０５を介して、広域ネットワーク網１２０に接続されている各装置とのデータ通信を行うことができる。  
【００３１】
記憶媒体ドライブ２０６は、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＡＭ等の記憶媒体に記録されているプログラムやデータを読み出し、ＲＡＭ２０２やＨＤＤ２０４に出力する。なお、ＲＡＭ２０２やＨＤＤ２０４が保持している情報のうち一部をこの記憶媒体に記録させておいてもよい。  
【００３２】
キーボード２０７、及びマウスやジョイスティック等により構成されているポインティングデバイス２０８は、ウェブメールクライアント装置１００の操作者が操作することで、各種の指示をＣＰＵ２０１に対して入力することができる。  
【００３３】
表示部２０９は、ＣＲＴや液晶画面等により構成されており、ＣＰＵ２０１による処理結果を画像や文字等をもって表示することができる。  
【００３４】
外部機器接続Ｉ／Ｆ２１０は、周辺機器をウェブメールクライアント装置１００に接続させるためのインターフェースである。ウェブメールクライアント装置１００は、この外部機器接続Ｉ／Ｆ２１０を介して、この周辺機器とのデータ送受信を行う。外部機器接続Ｉ／Ｆ２１０は、ＵＳＢやＩＥＥＥ１３９４等により構成されており、通常複数の外部機器接続Ｉ／Ｆを有する。周辺機器との接続形態は有線／無線を問わない。  
【００３５】
バス２１１は、上述した各部（２０１〜２１０）を通信可能に接続するものである。  
【００３６】
なお、ウェブメールクライアント装置１００のハードウェア構成は図２に示した構成を有するとして説明するが、必ずしも同図の構成を有することに限定するものではなく、ウェブメールクライアント装置１００が行う処理として説明する以下の処理が実行可能な構成であれば、ウェブメールクライアント装置１００の構成は適宜変形してもよい。  
【００３７】
また、ウェブメールクライアント装置１１０及びウェブメールサーバ１３０のハードウェア構成については、これらには一般のコンピュータを適用するので、周知の如く、概ね図２に示した構成を有する。  
【００３８】
図３は、ウェブブラウザ拡張機能１０２を示すブロック図である。ウェブブラウザ拡張機能１０２は、ウェブブラウザ１０１から必要に応じて呼び出され、ウェブメールの暗号化や復号化、スレッドの管理等を実施する。  
【００３９】
ウェブブラウザ拡張機能１０２は、メール本文変更部３００と、ルール管理部３０１と、スレッド検索部３０２と、スレッド暗号・復号部３０３と、判定部３０４と、ブラウザ接続部３０５と、メール保存部３０６と、ルートメール作成部３０７とを備える。また、ブラウザ接続部３０５を介して、ブラウザ３０８（ウェブブラウザ１０１）と接続する。  
【００４０】
ブラウザ３０８でメールの送信が実施されると、ブラウザ接続部３０５がメール暗号化の指示を受け、判断部３０４で暗号化するべきメールであるかどうかを、ルール管理部３０１に保存されているルールを参照して判断する。暗号化すべきメールであると判断した場合、新規作成のメールであれば、ルートメール作成部３０７で作成したルートメールに基づいて、スレッド暗号・復号部３０３においてメール本文が暗号化される。暗号化されたメール本文は、メール本文変更部３００で差し替えられてブラウザ接続部３０５を経由してブラウザ３０８へ送られる。これら一連のメールスレッド暗号化処理の詳細については、後述する。  
【００４１】
ブラウザ３０８で暗号化メールの表示が実施されると、ブラウザ接続部３０５がメール復号の指示を受ける。判断部３０４で復号に必要なメールスレッドを取得するために、ブラウザ接続部３０５を介して、ブラウザ３０８にウェブメールサーバ１３０から必要なメールスレッドデータを取得するように指示を出し、更に、スレッド暗号・復号部３０３を介して、スレッド検索部３０２にメール保存部３０６で保存している当該ルートメールを取得するように指示を出す。スレッド暗号・復号部３０３は、取得したメールスレッドデータから暗号化メールの本文を復号し、メール本文変更部３００で差し替えられてブラウザ接続部３０５を経由してブラウザ３０８へ送られる。これら一連のメールスレッド復号処理の詳細については、後述する。  
【００４２】
ブラウザ３０８で暗号化メールの削除が実施されると、ブラウザ接続部３０５がメール削除の指示を受ける。削除処理によって影響を受けるメールを取得するために、判断部３０４は、ブラウザ接続部３０５を介して、ブラウザ３０８にウェブメールサーバ１３０から必要なメールスレッドデータを取得するように指示を出す。また、メールスレッド全体の削除指示である場合は、スレッド暗号・復号部３０３を介して、スレッド検索部３０２にメール保存部３０６で保存している当該ルートメールを取得するように指示を出す。判断部３０４は、削除すべきメールのリストを作成した後、ブラウザ接続部３０５を介して利用者に削除に伴う警告を表示し、利用者の承諾を得た後に削除処理を実施する。これら一連のメールスレッド削除処理の詳細については、後述する。  
【００４３】
次に、メールスレッドについて、図４及び図２５を用いて説明する。  
【００４４】
図４はメールサマリの一例を示す図である。メールサマリ４００は、ウェブメールサーバ１３０に保存されているウェブメールの一部を表示したものである。また、ひとつの話題について差出人及びメール受信者の間でやりとりされた複数のメールを時系列に並べたものを、メールスレッドと呼ぶ。  
【００４５】
メールサマリ４００において、メール４０１を基点としたメール４０２、メール４０３、メール４０４及びメール４０５が第一のメールスレッドを構成している。メール４０２、メール４０３、メール４０４及びメール４０５は、すべて直前のメールへの返信処理であることを示している。  
【００４６】
また、メール４０６を基点としてメール４０７及びメール４０８は第二のメールスレッドを構成している。なお、メール４０８については、メール４０７の返信処理ではなく、メール４０６を差出人ｈａｙａｓｈｉが宛先ｕｍｅｄａへ転送したことを示している。  
【００４７】
このように、複数のメールからなるメールスレッドの構成を判断する第一の手法として、ＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）２８２２に記述されている、Ｍｅｓｓａｇｅ−ＩＤ、Ｉｎ−Ｒｅｐｌｙ−ＴｏもしくはＲｅｆｅｒｅｎｃｅの各ヘッダ情報を参照する手法がある。  
【００４８】
第一の手法について、図２５を用いて詳しく説明する。メール２５０１はメールの一例であり、ＲＦＣ２８２２に記述されているように、メール２５０１が唯一のものであると識別するために、Ｍｅｓｓａｇｅ−ＩＤヘッダ２５０２を有している。また、メール２５０３は返信メールの一例であり、メール２５０１に対する返信処理を実施したものである。  
【００４９】
ＲＦＣ２８２２に記述されているように、返信処理において、返信元となるメールの識別情報をＩｎ−Ｒｅｐｌｙ−Ｔｏヘッダに記載すべきであるとされており、メール２５０３において、Ｉｎ−Ｒｅｐｌｙ−Ｔｏヘッダ２５０４が付与されており、その値としてメール２５０１のＭｅｓｓａｇｅ−ＩＤヘッダ２５０２の値が記載されている。  
【００５０】
メール２５０１を送信しメール２５０３を受信したウェブメールサーバ１３０では、これらのヘッダ情報を参照することで、メール２５０１の返信メールがメール２５０３であるとわかることから、メール２５０１とメール２５０３がメールスレッドを構成すると判断することができる。  
【００５１】
同様に、メール２５０６においても、Ｉｎ−Ｒｅｐｌｙ−Ｔｏヘッダ２５０８の値は、メール２５０３のＭｅｓｓａｇｅ−ＩＤヘッダ２５０５の値となっている。従って、メール２５０６も前記メールスレッドを構成するメールの一部であると判断できる。  
【００５２】
メールスレッドを構成するメールであると判断する第二の手法として、任意につけられたタグと呼ばれるものを使用する手法がある。タグは、ウェブメールの利用者が任意に付与することもあれば、ウェブメールサーバ１３０で自動的に付与する場合もある。システムで自動化する場合は、例えば、複数の差出人をグループ化したものを利用する場合や、ある特定のヘッダ情報が同一のものに対して付与する場合がある。  
【００５３】
メールスレッドの構成を判断する第三の手法として、件名が同じものを集めるという手法がある。返信メールや転送メールの場合、基になるメールの件名に返信を示す「Ｒｅ：」や、転送を示す「Ｆｗ：」といった形式的な文字列を付与する。従って、このような文字列を除いた件名を持つ同一の
メールがメールスレッドを構成すると判断する手法である。  
【００５４】
なお、前記第二及び前記第三の手法では、条件に該当する複数通のメールが検出されるため、時系列で並べるために各メールにおける送信時刻が参照される。  
【００５５】
メールサマリ４１０は、メールサマリ４００を別形式で表示した一例であり、メールスレッド単位で表示している。メールスレッド４１１は、件名「明細書送付の件」でまとめられたメールスレッドであり、メール４０１、メール４０２、メール４０３、メール４０４及びメール４０５から構成された表示である。メールスレッド４１２は、メール４０６、メール４０７及びメール４０８から構成された表示である。なお、件名に付与されている数字は、そのメールスレッドを構成しているメールの通数を示すものである。即ち、メールスレッド４１１は５通、メールスレッド４１２は３通のメールから構成されていることがわかる。  
【００５６】
以上、メールスレッドの構成判断手法について説明したが、以降の例では、第一の手法（ＲＦＣ２８２２）を主体として説明する。  
【００５７】
次に、メールスレッド構造を利用したメールスレッド暗号の概要について、図５及び図６を用いて説明する。  
【００５８】
図４におけるメール４０１を基点とした第一のメールスレッドが暗号化メールスレッドである場合の構成例の一部を、図５に示す。暗号化メール構造５０２はメール４０１に相当し、暗号化メール構造５０５はメール４０２に相当する。このとき、メール本文部は暗号化された状態（５０３及び５０６）にある。  
【００５９】
メールスレッド暗号化方式における復号処理は、当該メールの親メールの本文部を共通鍵ファイル（共通鍵データ）として使用する特徴を持つ。従って、暗号化本文５０６の復号鍵は、親メールにあたる暗号化メール構造５０２の暗号化本文５０３を復号したメール本文５０４である。即ち、メール本文５０４を共通鍵ファイルとして暗号化本文５０６を復号し、メール本文５０７を得る。  
【００６０】
このとき、共通鍵ファイルであるメール本文５０４を得るためには、暗号化本文５０３を復号しなければならない。この復号鍵（共通鍵データ）となるのが、ルートメール構造５００のルートメール本文５０１である。ルートメールの詳細については、後述する。  
【００６１】
図４におけるメール４０３を基点とした第二のメールスレッドが暗号化メールスレッドである場合の構成例の一部を、図６に示す。暗号化メール構造６０２はメール４０６に相当し、暗号化メール構造６０５はメール４０７に相当し、暗号化メール構造６０８はメール４０８に相当する。暗号化メール構造６０８は、暗号化メール構造６０２と転送処理関係にある。従って、暗号化メール構造６０８の暗号化本文６０９を復号する共通鍵ファイルは、暗号化メール構造６０２の復号したメール本文６０４であり、暗号化メール構造６０５の暗号化本文６０６を復号する共通鍵ファイルと同一である。  
【００６２】
このようにメールスレッド暗号化方式では、暗号化された本文部を復号するために親メールを連鎖的に復号していく必要がある。従って、ルートメールを含むメールスレッドを構成するすべてのメールを所持していない限り、暗号化本文を復号できない構造を特徴としている。  
【００６３】
次に、メールスレッド暗号化方式において、ウェブメールサーバ１３０への接続から、メールの新規作成及び送信処理までの一連の流れについて、図７を用いて説明する。  
【００６４】
利用者がウェブメールクライアント装置１００のウェブブラウザ１０１を起動すると、ウェブブラウザ１０１はウェブブラウザ拡張機能１０２を初期化する（ステップＳ７０１）。ウェブブラウザ拡張機能１０２は初期化処理として、ウェブブラウザ１０１にイベントハンドラーを登録する（ステップＳ７０２）。イベントハンドラーとは、ウェブブラウザ１０１内の任意のイベント（例えば、マウスをクリックした、新しいホームページを読み込んだ、画面描画が終了した、等）に対して、ウェブブラウザ拡張機能１０２を呼び出すように設定する項目である。  
【００６５】
ウェブブラウザ１０１の初期化処理が終了し、利用者がウェブメールサーバ１３０に接続すると、ウェブメールサービスへのログイン処理が実施される（ステップＳ７０３）。ウェブメールサーバ１３０は、利用者のログインＩＤ及びログインパスワード等を認証し、ログイン成功をウェブブラウザ１０１に返す（ステップＳ７０４）。ログインに成功すると、一般的なウェブメールサービスでは、ウェブメールサーバ１３０に保存されているメールの一覧を取得する（ステップＳ７０５及びステップＳ７０６）。このとき、図４で示したメールサマリ４００、あるいはメールサマリ４１０のようなメール一覧が、ウェブブラウザ１０１に表示される。  
【００６６】
利用者はメールサマリ４００あるいはメールサマリ４１０の任意のメールを選択することで、当該メールの内容をウェブブラウザ１０１に表示することができる（ステップＳ７０７）。このとき、当該メールが、メールスレッド暗号化方式で暗号化されたメールであれば、ウェブブラウザ拡張機能１０２は、当該メールの本文部を復号してウェブブラウザ１０１に表示する（ステップＳ７０８）。復号処理の詳細については、後述する。  
【００６７】
また、利用者が返信ではない新規のメール（第一メールと呼ぶ）を作成したい場合、ウェブブラウザ１０１を操作してウェブメールサーバ１３０に新規メール作成の指示を出し（ステップＳ７０９）、メール作成画面を表示する（ステップＳ７１０）。メール作成画面で第一メールを作成し（ステップＳ７１１）、作成を完了してウェブブラウザ１０１がウェブメールサーバ１３０に送信指示を出すときに、ステップＳ７０１で設定したイベントハンドラーが呼び出され、ウェブブラウザ拡張機能１０２に処理が移行する（ステップＳ７１２）。  
【００６８】
第一メールの送信指示を受信したウェブブラウザ拡張機能１０２は、ルートメールの作成及び保存を実施する（ステップＳ７１３）。ルートメールの詳細については、後述する。ウェブブラウザ拡張機能１０２は、作成したルートメールに対する送信指示をウェブメールサーバ１３０へ出し（ステップＳ７１４）、ウェブメールサーバ１３０は送信完了を返す（ステップＳ７１５）。ここで、ウェブブラウザ拡張機能１０２は、ルートメールを共通鍵ファイルとして利用し、前記第一メールの本文を暗号化し（ステップＳ７１６）、ウェブブラウザ１０１上の第一メールを暗号化された本文に差し替える（ステップＳ７１７）。  
【００６９】
暗号化本文に差し替えられた前記第一メールは、ウェブメールサーバ１３０へ送信され（ステップＳ７１８）、送信完了を受信する（ステップＳ７１９）。  
【００７０】
次に、ウェブブラウザ拡張機能１０２における各処理について、詳細に説明する。  
【００７１】
図８は、ウェブブラウザ拡張機能１０２の初期化処理を示す。ウェブブラウザ１０１が起動すると、本初期化処理が呼び出される。ステップＳ８０１でウェブブラウザ拡張機能１０２の初期化処理を実施する。具体的には、設定情報の読込みや内部データの初期化を示す。前述したように、イントラネット内に設定情報を保存したサーバー等を設置していれば、ウェブメールクライアント装置１００内に保存されている設定ファイルを読み込む方法に限らず、前記設定情報保存サーバーから各種設定情報を取得する方法も可能である。続くステップＳ８０２において、ウェブブラウザ１０１のイベントリスナーに、ウェブブラウザ拡張機能１０２への接続先を登録する。登録するポイントは、ウェブメールの送信、表示及び削除である。以上の処理をもって、ウェブブラウザ拡張機能１０２の初期化処理を終了する。  
【００７２】
次に、前記イベントリスナーへ登録した接続先の処理について、詳細に説明する。図９〜図１７及び図２２を用いて、ウェブメール送信について説明する。ウェブメール送信処理は、大きく分けて２種類の送信がある。ひとつは返信ではない新規作成されたウェブメールの送信処理であり、もうひとつは返信や転送に伴うウェブメールの送信処理である。最初に、図９を用いて、返信ではない新規作成メール（以下、第一メールと呼ぶ）の送信処理について、詳しく説明する。  
【００７３】
図９に、メールスレッド暗号化方式におけるウェブメール送信の処理フローを示す。ステップＳ９０１において、予め登録されているＨＴＴＰリクエストかどうかの確認を行う。確認方法は、例えば、送信先ＵＲＬが予め登録されているものであるかどうか、或いは現在ウェブブラウザ１０１が表示しているＨＴＭＬのＤＯＭ構造が予め登録されているものと一致するかどうか、等を確認する、という方法である。ここで、登録されていない動作であると判断した場合（ステップＳ９０１で「いいえ」の場合）は、ステップＳ９１６に進み、暗号化処理を実施せずに第一メールを送信する。  
【００７４】
ステップＳ９０１で「はい」の場合は、ステップＳ９０２に進み、暗号化対象のメールであるかどうかを判断する。図２２に、判断のための動作ルールの一例を示す。動作ルールとは、作成されたメールの内容や宛先などの各種条件に応じて、システムがどのような動作を行うかを記述した管理テーブルである。例えば、動作ルール２２０１は「宛先が組織外を含む場合は暗号化する」を示し、動作ルール２２０２は「キーワード検査の結果に“社外秘”を含む場合は暗号化する」を示し、動作ルール２２０３は「添付ファイルがある場合は暗号化する」を示す。  
【００７５】
図９に戻って、ステップＳ９０２で「いいえ」の場合、即ち、暗号化対象外のメールであると判断した場合は、ステップＳ９１６に進み、暗号化処理を実施せずに第一メールを送信する。  
【００７６】
第一メールが暗号化対象であると判断した場合（ステップＳ９０２で「はい」の場合）、ステップＳ９０３に進み、第一メールを検索メールに定義し、続くステップＳ９０４で親メール検出処理を行う。図１０に親メール検出処理を、図１１に親メール検索条件選定のフローを示す。  
【００７７】
図１０のステップＳ１００１において、親メールの検索条件を選定する。図１１に移って、ステップＳ１１０１において、検索メールに設定した第一メールにＩｎ−ｒｅｐｌｙ−ｔｏヘッダ情報が存在するかを確認する。第一メールの場合、返信元を示すＩｎ−ｒｅｐｌｙ−ｔｏヘッダ情報は存在しないため、ステップＳ１１０１は「いいえ」となり、ステップＳ１１０３へ進む。ステップＳ１１０３において、タグが設定されているかどうかを確認する。第一メールの場合、タグも指定されていないため、ステップＳ１１０３も「いいえ」となり、ステップＳ１１０５に進む。ステップＳ１１０５で検索キーを「件名」に検索範囲を「時間（過去）」に設定する。  
【００７８】
図１０に戻って、前記親メール検索条件選定で設定した親メール検索条件で、メール検索を実施する（ステップＳ１００２）。メール検索の対象となる範囲は、メール保存部３０６に記憶されているルートメール及びウェブメールサーバ１３０に保存されているウェブメールである。前述のように第一メールの場合、検索キーが「件名」となるが、第一メールでは該当する検索結果がないものとして説明する（検索結果がある場合のフローの説明は、返信メールの送信を具体例として後述する）。ステップＳ１００２の親メールの検索処理は、ウェブメールサーバに対して当該条件での検索指示を行い、ウェブメールサーバから検索結果を取得する処理でもよいし、ウェブメールサーバから取得した各ウェブメールのヘッダ情報（Ｍｅｓｓａｇｅ−ＩＤやＩｎ−Ｒｅｐｌｙ−ｔｏ等）から、親メールを検索する処理でもよい。どちらの処理を実行するかは、ウェブメールサービスを提供するウェブメールサーバに応じて決定する構成を備えてもよい。ここでは、ウェブメールサーバから取得した各ウェブメールのヘッダ情報（Ｍｅｓｓａｇｅ−ＩＤやＩｎ−Ｒｅｐｌｙ−ｔｏ等）から、親メールを検索する処理で説明する。  
【００７９】
ステップＳ１００２のメール検索の結果、該当するメールが存在しない
ため、即ち、ステップＳ１００３において「いいえ」であるため、親メール検出処理に失敗する。図９に戻って、検出に失敗している（ステップＳ９０５で「いいえ」の場合）ため、ステップＳ９０６に進む。  
【００８０】
ステップＳ９０６において、第一メールを作成した利用者に新規スレッド作成許可があるかを動作ルール２２００で確認する。例えば、図２２において、動作ルール２２０４は「利用者ｈａｙａｓｈｉ及びｔａｎａｋａには新規作成許可がある」ことを示している。当該利用者に新規スレッド作成許可がない場合（ステップＳ９０６で「いいえ」の場合）、その旨を利用者に通知し、送信禁止として送信処理を終了する。  
【００８１】
ステップＳ９０６で「はい」の場合、即ち、当該利用者に新規スレッド作成許可がある場合、ステップＳ９０７に進み、ルートメール作成処理を実施する。ルートメールとは、前記暗号化メール構造５００及び前記暗号化メール構造６００に示したように、暗号化メールスレッドの基点となる特殊なメールであり、第一メールの本文部の暗号及び復号処理における共通鍵ファイルとなるメールである。  
【００８２】
図１２にルートメール作成処理（ルートメール生成処理）を示す。ステップＳ１２０１において、ルートメールを作成する。ルートメールの詳細については後述する。続くステップＳ１２０２において、前記ルートメールはメール保存部３０６に保存される。  
【００８３】
図９に戻って、ステップＳ９０８でルートメール送信を実施する。図１４にルートメール送信処理、図１５にルートメール削除処理のフローを示す。  
【００８４】
図１４のステップＳ１４０１において、当該ウェブメールサービスでウェブメールの自動送信が可能かどうかを確認する。自動送信が可能な場合（ステップＳ１４０１で「はい」の場合）、ステップＳ１４０２に進み、作成した前記ルートメールを送信する。自動送信の方法として、ウェブメールサービスが公開しているＡＰＩを利用する方法や、ＳＭＴＰサーバーが公開されている場合はＳＭＴＰサーバーを利用する方法等がある。このような自動送信の方法や自動送信が可能かどうかの情報は、前記管理テーブルに記述されていることが望ましい。  
【００８５】
自動送信が不可能な場合（ステップＳ１４０１で「いいえ」の場合）、ステップＳ１４０４に進み、手動で前記ルートメールを送信してもらうよう、ウェブブラウザ１０１上に指示を出す。具体的には、宛先、件名、暗号化本文を別画面に表示させて、ＯＳ（オペレーティング・システム）のコピー＆ペースト機能を利用してウェブメール送信画面から手動で前記ルートメールを送信する等の方法である。  
【００８６】
前記ルートメールの送信が完了すると、ステップＳ１４０３に進み、送信した前記ルートメールをウェブメールサーバ１３０から削除する。ここでは、ウェブメールクライアント装置がウェブメールサーバ１３０に対して削除指示を行うことで、当該ルートメールを削除する。前記ルートメールは、第一メールの共通鍵ファイルであり、これをウェブメールサーバ１３０上に残すことは、暗号化された第一メールが第三者によって復号可能になることを意味する。従って、前記ルートメールをウェブメールサーバ１３０より削除しなければならない。なお、前述のように、前記ルートメールは図１２のステップＳ１２０２において、メール保存部３０６に保存されている。  
【００８７】
図１５のステップＳ１５０１において、当該ウェブメールサービスでウェブメールの自動削除が可能かどうかを確認する。自動削除が可能な場合（ステップＳ１５０１で「はい」の場合）、ステップＳ１５０２に進み、前記ルートメールを削除する。ここでは、ウェブメールクライアント装置がウェブメールサーバに対して、削除指示を行うことで削除する。自動削除の方法として、ウェブメールサービスが公開しているＡＰＩを利用する方法や、削除指令をシミュレートしたＨＴＴＰリクエストを送信する方法等がある。このような自動削除の方法や自動削除が可能かどうかの情報は、前記管理テーブルに記述されていることが望ましい。  
【００８８】
自動削除が不可能な場合（ステップＳ１５０１で「いいえ」の場合）、ステップＳ１５０３に進み、手動で前記ルートメールを削除してもらうよう、ウェブブラウザ１０１上に指示を出す。具体的には、宛先、件名、本文内容等を別画面に表示させて、該当する送信済みメール一覧を利用者が確認する等の方法である。  
【００８９】
前記ルートメールの送信処理、及びルートメールの削除処理が完了すると、図９に戻って、ステップＳ９０９において、前記ルートメールを共通鍵として第一メールを暗号化する。図１３にメール暗号化の処理を示す。  
【００９０】
ステップＳ１３０１において、前記第一メールの暗号化対象となるメール本文を抽出する。続くステップＳ１３０２において、前記ルートメールを共通鍵ファイル（ルートメール本文１３０４）として抽出したメール本文を暗号化する。このとき、ルートメールの作成時にパスフレーズ１３０６の利用を指定することで、利用者がパスフレーズを入力し、暗号化強度を向上することもできる。パスフレーズを始めとしたルートメールの詳細については後述する。  
【００９１】
続くステップＳ１３０３において、暗号化されたメール本文はメールサーバーで処理できるようにテキスト文字列に変換され、前記第一メールの本文と差し替えられる。また、第一メールのヘッダ部には、前記ルートメールから連鎖していることを示すために、ＲＦＣ２８２２に基づいたＩｎ−ｒｅｐｌｙ−ｔｏ（もしくはＲｅｆｅｒｅｎｃｅヘッダ）が付与される。付与される値は、前記ルートメールに付与したＭｅｓｓａｇｅ−ＩＤ識別子である。  
【００９２】
なお、ウェブメールサービスによっては、本文の差替えは可能であっても、前述のようなヘッダ情報の付与が困難な場合がある。このような場合は、付与するべきヘッダ情報をテキストファイルとして用意し、前記第一メールの添付ファイルとして送信する方法を用いる。このとき、添付ファイル名を一定のものとし（例えば、ＣｒｙｐｔＴｈｒｅａｄＨｅａｄｅｒ．ｄａｔ）、受信側のウェブブラウザ拡張機能で処理することが望ましい。これらルートメールを基点とした連鎖関係の詳細については、後述する。  
【００９３】
図９に戻って、ステップＳ９１０で暗号化された第一メールを、ウェブブラウザ１０１を介して送信し、返信ではない新規作成メールのウェブメール送信処理を終了する。  
【００９４】
ここで、図１２のステップＳ１２０１で生成するルートメールについて、説明する。  
【００９５】
前述のようにルートメールはメールスレッド暗号化方式の基点となるものであり、第一メールの作成時等において自動的に作成される。ルートメール作成時において当該ルートメールには、以下の何れか一つ以上の情報が記載される。（１）   メール識別子に関する情報（２）   暗号化用の補助情報（３）   メールスレッド管理方法に関する情報（４）   第一メールの送信情報を証明する情報このようなルートメール情報について、図２３を用いて詳しく説明し、図２４に実施例を示す。  
【００９６】
図２３におけるルートメール情報２３００は、ルートメールに記載されるルートメール情報の一例を示している。ルートメール識別子２３０１、及び第一メール識別子２３０２はメール識別子に関する情報である。ルートメール識別子２３０１は当該ルートメールを唯一のものであると判断するための任意の文字列情報であり、ＲＦＣ２８２２のＭｅｓｓａｇｅ−ＩＤに相当する。また、第一メール識別子２３０２は、例えば、ウェブブラウザ１０１で作成した前記第一メールのＭｅｓｓａｇｅ−ＩＤを示す。  
【００９７】
図２４において、ルートメール２４００はルートメールの実施例を示す。ヘッダ情報２４０１（Ｍｅｓｓａｇｅ−ＩＤ）が前記ルートメール識別子２３０１の実施例であり、ヘッダ情報２４０２（Ｘ−ＣｒｙｐｔＴｈｒｅａｄ−Ｍａｉｌ）が前記第一メール識別子２３０２の実施例である。  
【００９８】
暗号化補助文字列２３０３は、ルートメール自体を共通鍵ファイルとするときの暗号強度を強化させるために、ランダムな文字列を予め記載しておくものである。図２４において、暗号化補助文字列２４０３が前記暗号化補助文字列２３０３の実施例である。暗号化補助文字列２３０３は、メール本文領域に記述される。  
【００９９】
ルートメール識別子２３０１、第一メール識別子２３０２、及び暗号化補助文字列２３０３はルートメール情報として必須項目である。  
【０１００】
メールスレッド管理情報として、公開範囲２３０４、失効時間２３０５、及びパスフレーズ２３０６がある。これらの情報は、前記第一メールを基点としたメールスレッドの管理に関する情報であり、任意項目である。公開範囲２３０４は、予め指定した範囲外へのメール送信を制限するものである。後述する暗号化メールスレッドからの返信や転送処理において利用される。失効時間２３０５は、暗号化メールスレッドの失効時間を指定するものである。  
【０１０１】
パスフレーズ２３０６は、メールの暗号化及び復号処理において、利用者にパスフレーズの入力を強要するものである。例えば、前記ステップＳ１３０２におけるメール本文の暗号化処理において、当該暗号化メールスレッドのルートメールにパスフレーズの記載がある場合、パスフレーズの入力が強要され、入力したパスフレーズとルートメールに記載されたパスフレーズが一致しないと、暗号化処理に失敗することとなる。なお、パスフレーズ２３０６には、入力すべきパスフレーズかそのまま記載されるのではなく、例えば、ＳＨＡ（Ｓｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍ）を始めとしたハッシュ関数の値を記載しておき、入力されたパスフレーズのハッシュ値と比較する方式が望ましい。  
【０１０２】
第一メールの送信情報を証明する情報として、証明書２３０７及び送信時刻２３０８がある。証明書２３０７は第一メールの送信者を証明するものであり、送信時刻２３０８は、第一メールの送信時刻を証明する情報（タイムスタンプ）を示す。これらの証明情報は、前述のように管理コストの増大を招くため、暗号化システムの安全性や信頼性とのバランスを考慮して利用できるよう、任意項目である。  
【０１０３】
図２４において、領域２４０４に前記メールスレッド管理情報及び前記証明書に関する情報の実施例である。領域２４０４はメール本文であり、前記暗号化補助文字列２４０３と空行を挟んで区別される。図２４の実施例では、公開範囲を＊＠ｅｘａｍｐｌｅ．ｃｏ．ｊｐに制限し、パスフレーズを有効にし、失効時間や送信者証明及び送信時刻証明は設定されていない。即ち、ルートメール２３００を基点とする暗号化メールスレッドは、暗号化／復号処理に際してパスフレーズの入力が必要であり、且つｅｘａｍｐｌｅ．ｃｏ．ｊｐドメイン以外への送信ができない、という管理がなされている。  
【０１０４】
ここで、ルートメール２３００を基点とする暗号化メールスレッドの例を、図２６に示す。メール２６０１はルートメール２３００である。メール２６０１にはメール識別子であるヘッダ情報２６０２（Ｍｅｓｓａｇｅ−ＩＤ）が付与されている。メール２６０１はルートメールであるため、第一メール識別子を示すヘッダ情報２６０３が付与されており、その値はメール２６０４のメール識別子であるヘッダ情報２６０５の値と同一である。  
【０１０５】
さらに、メール２６０４はルートメール２６０１を基点としたメールスレッドを示すためのヘッダ情報２６０６（Ｉｎ−ｒｅｐｌｙ−ｔｏ）を持つ。ヘッダ情報２６０６の値は、ルートメール識別子２６０２の値と同一である。以下、同様にして、メール２６０７、メール２６０８と暗号化メールスレッドを構成している。  
【０１０６】
また、ヘッダ情報２６０９（Ｃｏｎｔｅｎｔ−ｔｙｐｅ）は、その値がａｐｐｌｉｃａｔｉｏｎ／ｘ−ｃｒｙｐｔｔｈｒｅａｄ−ｍａｉｌである場合、暗号化メールスレッドを構成する暗号化メールであることを示すものである。  
【０１０７】
なお、前述したように、ウェブメールサービスによっては、本
文の差替えは可能であっても、このようなルートメールのヘッダ情報の付与や変更が困難な場合がある。このような場合は、付与するべきヘッダ情報をテキストファイルとして用意し、前記ルートメールの添付ファイルとして送信する方法を用いる。このとき、添付ファイル名を一定のものとし（例えば、ＣｒｙｐｔＴｈｒｅａｄＨｅａｄｅｒ．ｄａｔ）、受信側のウェブブラウザ拡張機能で処理することが望ましい。  
【０１０８】
次に、返信や転送に伴うメールの送信について、図９におけるフローを説明する。  
【０１０９】
返信や転送に伴うメールの送信においても、ステップＳ９０１、ステップＳ９０２及びステップＳ９０３までは、前記第一メールの場合と同じであるため、説明を省略する。続くステップＳ９０４で親メール検出処理を行う。図１０に親メール検出処理を、図１１に親メール検索条件選定のフローを示す。  
【０１１０】
図１０のステップＳ１００１において、親メールの検索条件を選定する。図１１に移って、ステップＳ１１０１において、検索メールに設定した返信元メールにＩｎ−ｒｅｐｌｙ−ｔｏヘッダ情報が存在するかを確認する。返信に伴うメールの場合、返信元を示すＩｎ−ｒｅｐｌｙ−ｔｏヘッダ情報が存在するため、ステップＳ１１０１で「はい」となり、ステップＳ１１０２へ進み、検索キーに親メールのＭｅｓｓａｇｅ−ＩＤ値を示すＩｎ−ｒｅｐｌｙ−ｔｏ値を設定する。この場合、返信元メールが一意に特定されるため、検索範囲の指定はない。  
【０１１１】
また、転送に伴うメールの場合、転送元を示すＩｎ−ｒｅｐｌｙ−ｔｏヘッダ情報は存在しないため、ステップＳ１１０１は「いいえ」となり、ステップＳ１１０３へ進む。ステップＳ１１０３において、タグが設定されているかどうかを確認する。転送メールの場合、タグが設定されていれば（即ち、ステップＳ１１０３で「はい」の場合）、ステップＳ１１０４に進み、検索キーを「タグ」に、検索範囲を「時間（過去）」に設定する。タグが設定されていない場合（ステップＳ１１０３で「いいえ」の場合）、ステップＳ１１０５に進む。ステップＳ１１０５で検索キーを「件名」に検索範囲を「時間（過去）」に設定する。  
【０１１２】
図１０に戻って、ステップＳ１００２において、設定した親メール検索条件でメール検索を実施する。メール検索の対象は、メール保存部３０６及びウェブメールサーバ１３０に保存されているウェブメールである。  
【０１１３】
ステップＳ１００２のメール検索の結果、返信元或いは転送元メールの検索に成功した場合（ステップＳ１００３で「はい」の場合）、ステップＳ１００４に進む。返信に伴うメールの場合、検索キーがＩｎ−ｒｅｐｌｙ−ｔｏ値であるため、ステップＳ１００４で「はい」となり、親メール検出に成功する。転送に伴うメールの場合は、検索キーはＩｎ−ｒｅｐｌｙ−ｔｏ値ではないため、ステップＳ１００４で「いいえ」となり、ステップＳ１００５に進む。このとき、検索結果には複数の候補が含まれている可能性があるため、ステップＳ１００５において、検索結果で最新のものを選択し、これを親メールとして、親メール検出処理を成功する。  
【０１１４】
図９に戻って、ステップＳ９０４で親メールの検出に成功した場合、ステップＳ９０５で「はい」となり、ステップＳ９１１に進み、検出した親メールで当該返信（或いは転送）メールを暗号化する。図１３にメール暗号化の処理を示す。  
【０１１５】
ステップＳ１３０１において、前記返信（或いは転送）メールの暗号化対象となるメール本文を抽出する。続いて、ステップＳ１３０２において、前記親メールを共通鍵ファイル（親メール本文１３０５）として抽出したメール本文を暗号化する。なお、親メール本文１３０５を得るためには、図１９に示すメール復号処理を実施する必要がある。メール復号処理については、後述する。このとき、親メールを含む暗号化メールスレッドのルートメールに記録されているパスフレーズ１３０６の利用を指定することで（メール復号処理を実施することで、暗号化メールスレッドのルートメールを特定することができる。詳細については後述する）、利用者がパスフレーズを入力し、暗号化強度を向上することもできる。パスフレーズを始めとしたルートメールの詳細については後述する。  
【０１１６】
続くステップＳ１３０３において、暗号化されたメール本文はメールサーバーで処理できるようにテキスト文字列に変換され、前記返信（或いは転送）メールの本文と差し替えられる。なお、転送メールの場合、ヘッダ部には前記親メールから連鎖していることを示すためのＩｎ−ｒｅｐｌｙ−ｔｏ（もしくはＲｅｆｅｒｅｎｃｅヘッダ）は存在しない。前述したようにタグや件名を利用することで親メールを特定することは可能であるが、より正確に親メールを指定したい場合は、意図的にＩｎ−ｒｅｐｌｙ−ｔｏヘッダを付与することや、一意の特定ヘッダ情報を付与すること、或いは転送メール本文中に記述されている参照情報の一部から親メールを判断する、等で対応することができる。  
【０１１７】
図９に戻って、ステップＳ９１１で前記返信（或いは転送）メールを暗号化した後、ステップＳ９１２に進む。ここで、前記返信（或いは転送）メールの宛先が、返信元或いは転送元メールの宛先、即ち、親メールに記載されている宛先から増えていないかを確認する。宛先に変更がない場合（ステップＳ９１２で「いいえ」の場合）、ステップＳ９１５に進み、ウェブブラウザ１０１より暗号化された前記返信（或いは転送）メールを送信して、処理を終了する。  
【０１１８】
宛先に変更がある場合（ステップＳ９１２で「はい」の場合）、ステップＳ９１３に進み、全親スレッド送信処理を実施する。本発明における暗号化メールスレッドは、ルートメールから連鎖的にメール本文を暗号化していく特徴を持っている。従って、暗号化メールスレッドの途中から追加された宛先は、暗号化されたメールだけを受け取っても、それ以前のルートメールを含めた暗号化メールスレッドを所持していない限り、受け取った暗号化メールを復号することができない。全親スレッド送信処理は、このような状況に対応する処理である。図１６に全親スレッド送信処理のフローを示す。  
【０１１９】
まず、ステップＳ１６０１からステップＳ１６０３において、追加された宛先に対して動作ルールの確認を行う。ステップＳ１６０２では、暗号化対象の宛先であるかどうかを判断する。暗号化対象の宛先でない場合（ステップＳ１６０２で「いいえ」の場合）、全親スレッド送信処理に失敗する。  
【０１２０】
暗号化対象の宛先である場合（ステップＳ１６０３で「はい」の場合）、ステップＳ１６０３に進む。ステップＳ１６０３で、全親スレッドが送信可能であるかどうかを判断する。全親スレッド送信が禁止されている場合（ステップＳ１６０３で「いいえ」の場合）、全親スレッド送信処理に失敗する。  
【０１２１】
以上の判断で参照する動作ルール２２００の一例を、前述したように、図２２に示す。本ステップでの実施例として、動作ルール２２０６を説明する。動作ルール２２０６は「利用者ｈａｙａｓｈｉとｔａｎａｋａとｕｍｅｄａは全親スレッド受信が許可されている」を示す。従って、前記追加された宛先が前記動作ルール２２０６に含まれている宛先である場合、全親スレッド送信ができる。  
【０１２２】
すべての追加された宛先の確認を完了すると、ステップＳ１６０４に進む。ここで、検索メールに前記返信（或いは転送）メールを設定し、続くステップＳ１６０５で親メール集合作成処理を実施する。図１７に親メール集合作成のフローを示す。  
【０１２３】
親メール集合作成処理とは、任意のメールを基点として、そのメールが属する暗号化メールスレッドにおいて、ルートメールから親メールまでのすべてのメール（即ち、今までにそのメールスレッドでやりとりしたすべてのメール）を検出する処理である。ステップＳ１７０１で親メール集合を保存するスタックの初期化処理を実施する。続くステップＳ１７０２で検索メールに設定している前記返信（或いは転送）メールの親メールを検出する。親メール検出処理のフローは図１０に示しており、図９のステップＳ９０４で説明しているので、ここでの説明は省略する。  
【０１２４】
親メールが検出できない場合（ステップＳ１７０３で「いいえ」の場合）、親メール集合作成処理を失敗する。親メールの検出に成功した場合（ステップＳ１７０３で「はい」の場合）、ステップＳ１７０４に進み、メールスタックに検出した親メールをＰｕｓｈする。続くステップＳ１７０５で検出した親メールがルートメールであるかどうかを確認する。ルートメールであった場合（ステップＳ１７０５で「はい」の場合）、すべての親メールを検出できたので、親メール集合作成処理を成功する。ルートメールでない場合（ステップＳ１７０５で「いいえ」の場合）、ステップＳ１７０６に進み、検索メールに検索結果である親メールを設定し、ステップＳ１７０２に戻り、再帰的に親メールを検出する処理を実施する。  
【０１２５】
図１６に戻って、親メール集合作成処理が失敗した場合（ステップＳ１６０６で「いいえ」の場合）、全親スレッド送信処理を失敗する。親メール集合作成処理に成功した場合（ステップＳ１６０６で「はい」の場合）、ステップＳ１６０７に進み、追加された宛先に親メール集合処理で検出したすべてのメールを送信する。  
【０１２６】
図９に戻って、全親スレッド送信処理に失敗した場合（ステップＳ９１４で「いいえ」の場合）、ウェブメール送信処理を送信禁止として終了する。全親スレッド送信処理に成功した場合（ステップＳ９１４で「はい」の場合）、ステップＳ９１５に進み、ウェブブラウザ１０１より暗号化された前記返信（或いは転送）メールを送信して、処理を終了する。  
【０１２７】
次に、前記イベントリスナーへ登録した接続先の処理であるウェブメール表示について、図１８及び図１９を用いて、詳細に説明する。
【０１２８】
メールスレッド暗号化方式でウェブメールサーバ１３０に保存されているウェブメールを閲覧する場合、前述したように、当該メールスレッドをルートメールまで辿り、連鎖的に復号する必要がある。図１８にウェブメール表示のフローを示す。
【０１２９】
ウェブメールサーバ１３０が保存しているウェブメールの種類には、以下の３種類がある。（１）   利用者が宛先となっているルートメール（２）   暗号化メール（３）   通常メール（暗号化されていない通常のメール）  
【０１３０】
ウェブメール表示処理は、ウェブブラウザ１０１がウェブメールの本文表示を実施する際に呼び出され、上述した３種類のウェブメールの種類に対応した処理を実施する。
【０１３１】
ステップＳ１８０１で、表示する当該ウェブメールがルートメールかどうかを判断する。具体的には、ヘッダ情報に一意の項目名（図２４におけるヘッダ情報２４０２：Ｘ−ＣｒｙｐｔＴｈｒｅａｄ−Ｍａｉｌ等）が存在するかどうかで判断する。もしくは、前述したように一定の添付ファイル名を持つ添付ファイルから同等の情報を含むがどうかで判断してもよい。  
【０１３２】
ルートメールは前述したように、新たにメールスレッドを作成したときに、第一メールに先駆けて送信されて、利用者のローカルファイルにのみ存在するメールである。従って、ウェブメールサーバ１３０上にルートメールが存在するということは、他人から利用者宛にルートメールが送信されてきたことを意味する。表示しようとするメールがルートメールであると判断した場合（ステップＳ１８０１で「はい」の場合）、ステップＳ１８０２へ進み、当該ルートメールをローカルファイルとしてメール保存部３０６に保存する。続いて、ウェブメールサーバ１３０上に保存されている前記ルートメールを削除し（ステップＳ１８０３）、ステップＳ１８０４で、利用者にルートメールの保存完了の通知を表示する。なお、ルートメールはメールスレッド暗号化方式における制御情報であって可読性は必要ないため、通知を行わずにウェブメール表示処理を終了してもよい。  
【０１３３】
表示する当該ウェブメールがルートメールでない場
合（ステップＳ１８０１で「いいえ」の場合）、ステップＳ１８０５に進み、暗号化メールであるかどうかを判断する。具体的には、前記ルートメールと同様に、ヘッダ情報に一意の項目名（図２６におけるヘッダ情報２６０９：Ｃｏｎｔｅｎｔ−ｔｙｐｅ等）とその値（ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｃｒｙｐｔｔｈｒｅａｄ−ｍａｉｌ）が、暗号化メールを示すものであるかどうかで判断する。もしくは、前述したように一定の添付ファイル名を持つ添付ファイルから同等の情報を含むがどうかで判断してもよい。  
【０１３４】
表示しようとするメールが暗号化メールであると判断した場合（ステップＳ１８０５で「はい」の場合）、ステップＳ１８０６に進み、検索メールに当該ウェブメールを設定し、メール復号処理を実施する（ステップＳ１８０７）。メール復号処理については、詳しく後述する。  
【０１３５】
ステップＳ１８０７のメール復号処理に成功した場合（ステップＳ１８０８で「はい」の場合）、ステップＳ１８０９に進み、復号したウェブメールがウェブブラウザ１０１に表示される。メール復号処理に失敗した場合は（ステップＳ１８０８で「いいえ」の場合）、ステップＳ１８１０に進み、復号に失敗した旨を利用者に表示する。  
【０１３６】
当該ウェブメールが暗号化メールと判断しなかった場合（ステップＳ１８０５で「いいえ」の場合）、当該ウェブメールは通常メールであると判断しているため、ステップＳ１８１１に進み、通常通り、該ウェブメールの表示を行う。  
【０１３７】
ここで、ウェブメールの復号処理について、図１９を用いて、詳細に説明する。図１８のステップＳ１８０７から呼び出されるメール復号処理は、暗号化メールスレッドをルートメールまで再帰的に辿り、その後、ルートメールの本文部から連鎖的に当該ウェブメールまで連鎖的に復号処理を実施していく。  
【０１３８】
ステップＳ１９０１において、検索メールに復号対象となるメールを設定し、親メール集合作成処理を実施して、当該メールの暗号化メールスレッド全体を取得する（ステップＳ１９０２）。親メール集合作成処理に失敗した場合（ステップＳ１９０３で「いいえ」の場合）、メール復号処理を失敗する。親メール集合作成処理に成功した場合（ステップＳ１９０３で「はい」の場合）、ステップＳ１９０４において、前記親メール集合作成処理で作成したメールスレッドからルートメールを取り出し（前記メールスタックはスタック構造なのでＰｏｐ操作で最後にＰｕｓｈしたルートメールが最初に取り出せる）、続くステップＳ１９０５において、該ルートメールに記載している暗号化条件（公開範囲、失効時間等）が有効であるかどうかを確認する。暗号化条件が無効である場合（ステップＳ１９０５で「いいえ」の場合）、メール復号処理を失敗する。暗号化条件が有効である場合（ステップＳ１９０５で「はい」の場合）、続くステップＳ１９０６において、共通鍵ファイルにステップＳ１９０４で抽出した該ルートメールの本文部を設定し、ステップＳ１９０７からステップＳ１９１１にかけて、連鎖的に暗号化メールスレッドを復号する。  
【０１３９】
ステップＳ１９０７において、前記親メール集合処理で作成した前記メールスタックを確認し、前記メールスタックにメールがあれば、それを取り出す（ステップＳ１９０８）。続くステップＳ１９０９で前記メールスタックから取り出した該メールの本文復号処理を実施する。このとき、復号のための共通鍵ファイルは、ステップＳ１９０６で設定したルートメール本文１９１２である。また、前記ルートメールでパスフレーズ入力が有効である場合は、パスフレーズ１９１４を入力する。復号に失敗した場合（ステップＳ１９１０で「いいえ」の場合）、メール復号処理を失敗する。  
【０１４０】
復号に成功した場合（ステップＳ１９１０で「はい」の場合）、復号した該メールの本文部を共通鍵ファイルに設定し（ステップＳ１９１１）、ステップＳ１９０７に戻る。以降、同様に、前記メールスタックからメールを取り出し、共通鍵ファイルに設定した情報を元に、メール本文を復号していく（ステップＳ１９０９における共通鍵ファイルは親メール本文１９１３になる）。  
【０１４１】
ステップＳ１９０７において、前記メールスタックが空になった場合、即ち、復号対象のメールの親メールまで復号処理が完了した場合、ステップＳ１９１５に進み、復号対象メールを復号する。このとき使用する共通鍵ファイルは、復号対象メールが第一メールである場合はルートメール１９１２であり、そうでない場合は親メール１９１３となる。ステップＳ１９１５における復号処理が成功した場合（ステップＳ１９１６で「はい」の場合）、復号対象のメールが正常に復号できたとして処理を終了する。復号処理に失敗した場合（ステップＳ１９１６で「いいえ」の場合）、復号失敗として処理を終了する。  
【０１４２】
次に、前記イベントリスナーへ登録した接続先の処理であるウェブメール削除について、図２０及び図２１を用いて、詳細に説明する。  
【０１４３】
メールスレッド暗号化方式でウェブメールサーバ１３０に保存されているウェブメールを削除する場合、当該メールを削除すると暗号化メールスレッドの連鎖的な特徴から、当該メール以降の暗号化メールの復号が不可能となり、当該メール以降のメール閲覧や返信処理等ができなくなる。従って、ウェブメール削除処理においては、当該メール削除実行時における利用者への警告表示と利用者承諾、或いは暗号化メールスレッド全体削除の選択実行及び利用者への警告表示と利用者承諾処理が必要となる。  
【０１４４】
まず、ステップＳ２００１において、検索メールに削除対象となるメールを設定する。続くステップＳ２００２において、削除対象のメールのみ削除する場合（ステップＳ２００２で「いいえ」の場合）、ステップＳ２００３に進み、検索条件選定処理を実施する。  
【０１４５】
図２１に検索条件選定処理のフローを示す。検索条件選定処理とは、前述した親メール集合作成処理があるメールの親メール集合を作成したのに対して、あるメールの子メール集合を抽出するため処理である。  
【０１４６】
図２１のステップＳ２１０１において、当該メール（この場合、削除対象メールとなる）にＭｅｓｓａｇｅ−ＩＤ識別子が存在するかどうかを確認する。Ｍｅｓｓａｇｅ−ＩＤ識別子が存在する場合（ステップＳ２１０１で「はい」の場合）、ステップＳ２１０２に進む。検索キーにＭｅｓｓａｇｅ−ＩＤ値を設定し、検索範囲は設定せず、検索条件選定処理を終了する。  
【０１４７】
Ｍｅｓｓａｇｅ−ＩＤ識別子が存在しない場合（ステップＳ２１０１で「いいえ」の場合）、ステップＳ２１０３に進み、当該メールにタグが設定されているかどうかを確認する。タグが設定されている場合（ステップＳ２１０３で「はい」の場合）、ステップＳ２１０４に進む。検索キーにタグを設定し、当該メールの持つ時刻情報よりも未来の範囲を検索範囲として、検索条件選定処理を終了する。  
【０１４８】
タグが存在しない場合（ステップＳ２１０３で「いいえ」の場合）、ステップＳ２１０５に進み、当該メールの件名（返信を表す「Ｒｅ：」や転送を表す「Ｆｗ：」等の接頭辞を除いたもの）を検索キーに設定し、タグの場合と同様に、当該メールの持つ時刻情報よりも未来の範囲を検索範囲として、検索条件選定処理を終了する。  
【０１４９】
図２０に戻って、ステップＳ２００４において、前記検索条件選定処理で設定した検索キーと検索範囲を用いて、メール検索を実施する。メール検索は、メール保存部３０６及びウェブメールサーバ１３０に保存されているウェブメールが対象となる。ステップＳ２００４の検索処理も、ステップＳ１００２と同様に、ウェブメールサーバに対して当該条件（検索キー）での検索指示を行い、ウェブメールサーバから検索結果を取得する処理でもよいし、ウェブメールサーバから取得した各ウェブメールのヘッダ情報（Ｍｅｓｓａｇｅ−ＩＤやＩｎ−Ｒｅｐｌｙ−ｔｏ等）から、親メールを検索する処理でもよい。どちらの処理を実行するかは、ウェブメールサービスを提供するウェブメールサーバに応じて決定する構成を備えてもよい。  
【０１５０】
検索の結果、前記検索条件に該当するメールが存在しなかった場合（ステップＳ２００５で「いいえ」の場合）、削除対象であるメールの削除後に影響を受ける暗号化メール（子メール）が存在しないということを意味するため、ステップＳ２００８へ進む。前記検索条件に該当するメールが存在する場合（ステップＳ２００５で「はい」の場合）、削除対象後に影響を受ける暗号化メール（子メール）が存在することを意味するため、「当該メール削除を実施すると、復号不可能な暗号化メールを含めて削除する」ことを利用者に警告する（ステップＳ２００６）。利用者が該削除処理を実施したくない場合（ステップＳ２００７で「いいえ」の場合）、ウェブメール削除処理を失敗して終了する。利用者が該削除処理を承諾した場合（ステップＳ２００７で「はい」の場合）、ステップＳ２００８へ進む。  
【０１５１】
ステップＳ２００８では、前記メール検索で獲得した削除対象となるメールのリストを作成する。続くステップＳ２００９において、当該削除メールが第一メールを示しているかどうかを判断する（具体的には、図２６を用いて前述したように、当該メールのＩｎ−ｒｅｐｌｙ−ｔｏ値と一致するＭｅｓｓａｇｅ−ＩＤ識別子を持つメールがルートメールである、即ち、Ｘ−ＣｒｙｐｔＴｈｒｅａｄ−Ｍａｉｌヘッダ情報を持つこと、が分かればよい）。第一メールであると判断した場合（ステップＳ２００９で「はい」の場合）、当該削除メールを含む暗号化メールスレッドのルートメールを削除リストに追加する必要がある（ステップＳ２０１０）。これは、第一メールを削除メールに指定した場合、暗号化メールスレッドすべてを削除することを意味するが、第一メールの親メールであるルートメールのみ、削除対象に含まれていないからである。なお、ステップＳ２００９において、当該削除メールが第一メールでないと判断した場合は、ステップＳ２０１０をスキップする。  
【０１５２】
この時点で、削除対象のメールリストが作成されており、利用者の承諾も得ているので、削除処理を実施できるが、削除対象の暗号化メールスレッドを持つ他の受信者が、さらに当該暗号化メールスレッドを利用して、返信メールを送信してくる可能性がある。ここで、利用者が当該暗号化メールスレッドを削除していると、送信されてきた返信メールの復号ができない。このような場合を想定して、ステップＳ２０１１では削除リストにおける終端メール（即ち、最も新しいメール）（メールスレッドの中で最終日時に送信及び／又は受信したメール）について、メール保存領域３０６へ復号した状態で保存（記憶）する。このとき、保存期間を別途設定し、ある一定期間を過ぎた終端メールについては、メール保存領域３０６から削除してもよい。  
【０１５３】
続いて、ステップＳ２０１２において、当該削除リストに記載されているメールを、メール保存領域３０６及びウェブメールサーバ１３０から削除し、ウェブメール削除処理を終了する。ここで、当該削除リストに記載されているメールの削除指示（削除依頼）をウェブメールサーバ１３０に送信することにより削除する。  
【０１５４】
一方で、ステップＳ２００２で「はい」の場合、即ち、暗号化メールスレッド全体の削除の場合について、説明する。  
【０１５５】
ステップＳ２０１３において、検索メールを削除対象メールとした親メール集合作成処理を実施する。作成処理に失敗した場合（ステップＳ２０１４で「いいえ」の場合）、ウェブメール削除処理を失敗して終了する。作成処理に成功した場合（ステップＳ２０１４で「はい」の場合）、前記親メール集合作成処理で取得した親メールを削除リストに追加する（ステップＳ２０１５）。続いて、検索メールに削除対象メールを設定し（ステップＳ２０１６）、検索条件選定処理を実施する（ステップＳ２０１７）。選定された検索キー及び検索範囲でメール検索を実施して（ステップＳ２０１８）、取得したメールを削除リストに追加する
（ステップＳ２０１９）。この段階で、削除対象メールを含む暗号化メールスレッド全体のメールが、前記削除リストに登録されていることになる。  
【０１５６】
ステップＳ２０２０において、利用者に「暗号化メールスレッド全体の削除である」ことを警告表示し、削除処理に対して承諾を得た場合（ステップＳ２０２１で「はい」の場合）、ステップＳ２０１１に進み、前述したように、暗号化メールスレッドの終端メールを保存し、メール削除処理を実施して（ステップＳ２０１２）、ウェブメール削除処理を終了する。利用者の承諾が得られない場合（ステップＳ２０２１で「いいえ」の場合）、ウェブメール削除処理を失敗して終了する。  
【０１５７】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様を取ることが可能であり、具体的には、ウェブブラウザ拡張機能としてではなく、専用システムとして適用してもよいし、複数の機器から構成されるシステムに適用してもよい。  
【０１５８】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な内容で構成されることは言うまでもない。  
【０１５９】
また、本発明は、システム或いは装置にプログラムを供給することにとって達成される場合にも適用できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システム或いは装置に読み出すことによって、そのシステム或いは装置が、本発明の効果を享受することが可能となる。  
【０１６０】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバー、データーベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステム或いは装置が、本発明の効果を享受することが可能となる。
【０１６１】
なお、上述した各実施形態及びその変形例を組み合わせた構成もすべて本発明に含まれるものである。  
【０１６２】
本発明によれば、ウェブメールはメールスレッド暗号化方式によって、連鎖的に本文部を暗号化することができ、更にメールスレッド単位の原本保障性を確保できる。また、誤送信が発生した場合では、誤送信先がメールスレッド全体を所持していない限り、内容の閲覧はできないため、情報セキュリティを確保できる。更に、メールスレッド暗号化方式はウェブメールの本文部が共通鍵ファイルとなるため、鍵管理コストが軽減される。更に、ルートメールのみローカルファイルとして管理することで、ウェブメールサービス上に保存しているウェブメール本体の復号が不可能となり、ウェブメールサービスを安全に利用することができる。また、ルートメールに記載される情報によって、メールスレッド単位でウェブメールの送受信を含めた情報管理が可能となる、等の効果を奏する。
【符号の説明】
【０１６３】
１００  ウェブメールクライアント装置
１０１  ウェブブラウザ
１０２  ウェブブラウザ拡張機能
１１０  ウェブメールクライアント装置
１１１  ウェブブラウザ
１１２  ウェブブラウザ拡張機能
１２０  広域ネットワーク網
１３０  ウェブメールサーバ
２０１  ＣＰＵ
２０２  ＲＡＭ
２０３  ＲＯＭ
２０４  ＨＤＤ
２０５  ネットワークＩ／Ｆ
２０６  記憶媒体ドライブ
２０７  キーボード
２０８  ポインティングデバイス
２０９  表示部
２１０  外部機器接続Ｉ／Ｆ
２１１  バス
【図１】
2011097480.tif 000003
【図２】
2011097480.tif 000004
【図３】
2011097480.tif 000005
【図４】
2011097480.tif 000006
【図５】
2011097480.tif 000007
【図６】
2011097480.tif 000008
【図７】
2011097480.tif 000009
【図８】
2011097480.tif 000010
【図９】
2011097480.tif 000011
【図１０】
2011097480.tif 000012
【図１１】
2011097480.tif 000013
【図１２】
2011097480.tif 000014
【図１３】
2011097480.tif 000015
【図１４】
2011097480.tif 000016
【図１５】
2011097480.tif 000017
【図１６】
2011097480.tif 000018
【図１７】
2011097480.tif 000019
【図１８】
2011097480.tif 000020
【図１９】
2011097480.tif 000021
【図２０】
2011097480.tif 000022
【図２１】
2011097480.tif 000023
【図２２】
2011097480.tif 000024
【図２３】
2011097480.tif 000025
【図２４】
2011097480.tif 000026
【図２５】
2011097480.tif 000027
【図２６】
2011097480.tif 000028