JP4444998B2 - 電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法 - Google Patents

電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法 Download PDF

Info

Publication number
JP4444998B2
JP4444998B2 JP2007266064A JP2007266064A JP4444998B2 JP 4444998 B2 JP4444998 B2 JP 4444998B2 JP 2007266064 A JP2007266064 A JP 2007266064A JP 2007266064 A JP2007266064 A JP 2007266064A JP 4444998 B2 JP4444998 B2 JP 4444998B2
Authority
JP
Japan
Prior art keywords
information
signature
mail
header
feature amount
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007266064A
Other languages
English (en)
Other versions
JP2009093576A (ja
Inventor
孝司 吉岡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2007266064A priority Critical patent/JP4444998B2/ja
Priority to US12/208,068 priority patent/US8832202B2/en
Publication of JP2009093576A publication Critical patent/JP2009093576A/ja
Application granted granted Critical
Publication of JP4444998B2 publication Critical patent/JP4444998B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Description

本発明は、電子メール情報を管理し、電子メール情報が正しく送られたものであることを容易に認証することができる電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法に関するものである。
インターネット時代を迎え、電子メールは新しい社会基盤（インフラ）となっている。現在、電子メールは企業（ビジネス）や学校（教育）、知人へ私的連絡等、あらゆる場面でのコミュニケーションツールとして、欠かせない存在となっている。
電子メールの普及の背景として、送受信コストが既存手段よりも圧倒的に安価であることが挙げられ、電子メールを利用する情報機器も従来のPC（パソコン）環境のみならず、携帯電話やPDA（Personal Digital Assistant：携帯情報端末装置）等の移動端末にもメール機能が搭載され、電子メールは、近年、爆発的に利用・普及している電子情報と言える。
一方で、電子メールの内容保証に関する問題や、メールの大量配信（スパムメール）が社会問題にもなっている。この内容保証による対策として、S/MIME（Secure Multipurpose Internet Mail Extensions、電子メールの暗号化方式の標準）方式を用いる方法や、電子メール文書の原本性保証装置に関する技術が知られている（例えば下記特許文献１参照）。
具体的には、S/MIME方式では、メール本文に対して暗号化や電子署名を施すことにより、盗聴やなりすまし、改ざん等を防いでいる。また、特許文献１では、電子メールの本文とそれに添付されたファイルに対して、メール送信時に電子署名を付加し、メール受信時に改ざんの検知を行うための原本性保証装置を設け、該装置内に電子メールの本文と添付ファイルを暗号化して保存、更にアクセス制限をかけることで電子メールの機密性の要件を満たしている。
更に、迷惑メール対策として、一般的な文書の保存と同様、電子メールにも電子署名を用いて保証する事例が増えている。スパムメールとは、メール送信者が自分の身元を隠蔽するために、送信元に関する情報を詐称して送信されるもので、例えば、メールヘッダ中の差出人（From:メールアドレス部分）を他人のメールのヘッダ中からメールアドレスを引用し、あたかも自分の身元のように偽り送信するものである。
この対策として、近年、偽造メールアドレスの特定に焦点を当てたスパム対策技術（送信ドメイン認証技術）が開発されている。送信ドメイン認証技術には、IPアドレスを利用するものと、電子署名を利用するものの２種類があり、電子署名を利用するタイプの送信ドメイン認証の代表としては、DKIM（DomainKeys Identified Mail）という方式がある。
DKIM方式では、受信者側でメールを送信したサーバを特定したりチェックすることが可能である。具体的には、メールヘッダと本文を一括してSMTPサーバ（送信者側メールサーバ）の電子署名を生成し、その情報をDKIM-Signature:ヘッダとして追加する。
DKIM-Signature:ヘッダには、各種情報を格納する属性が存在し、主な属性としては、電子署名を付加した送信ドメインの名前を示すd属性（例: d=xx.com）、署名の生成に利用したアルゴリズムを格納するためのa属性（例: a=rsa-sha1）、どの項目を署名対象にするかを示すh属性（例: h=From:To:Subject:Content-type）、送信ドメインによって生成された電子署名情報を格納するためのb属性（例: b=tfx8cgksw92）等がある。
以上のような属性を含むDKIM-Signature:ヘッダを追加後、受信者へ送信することで、受信者側では、そのDKIM-Signature:ヘッダの内容（各属性:電子署名等）を検証することにより送信されたメールサーバの特定が可能になるという仕組みである。
加えて、ヘッダと本文を一括して電子署名するため、ヘッダ（差出人（From））部分の引用等による詐称を防止することができ、安全なメール送信を実現することが可能である。現在、このような仕組みを持つDKIM方式に対して、複数の関連ベンダーによって標準化（RFC化）が急速に進められている。
特開２００５−１０１８８３号公報
しかしながら、上述した S/MIME方式、特許文献１、DKIM方式の3つの従来技術に関する課題を以下に示す。
まず、S/MIME方式では、差出人（From）、宛先（To）、件名（Subject）等のメールヘッダ情報に関して電子署名を施すことはしていないため、スパムメールの対策にはなっていなかった。
特許文献１では、電子メール文書原本性保証装置にて電子メールを安全に管理することに注力している点、およびメール本文と添付ファイルを示す「コンテンツ情報」のみの保証に着眼したものである。従って、差出人（From）、宛先（To）、件名（Subject）等のメールヘッダ情報の変更や追加等がなされても、差出人（From）や件名（Subject）、メール本文の内容を個別に確認できるものではなかった。
DKIM方式では、メールヘッダの一部や本文（ボディ）の領域を自動的に変更するようなメーリングリスト（以降、MLと略）による同報メールには不向きであることが知られている。
メーリングリストとは、一群の読者にだけ送りたいメッセージを自動的に電子メールで届けることができるようにするための、電子メールアドレスのリストである。ある読者がリストに送ったメッセージは、すべて他の読者にも届く。メーリングリストに読者登録している人同士でメッセージを送ったり、それに返事をしたり、読んだりすることが可能である。
メーリングリストでは、MLアドレスで投稿されたメールは、一旦、MLサーバへ送られ処理される。この時、MLサーバは、電子署名の対象になる本文やヘッダを再配送する際に自動的に変更する場合が多く、投稿時に作成した電子署名が破壊されてしまい、受信者側で検証ができなくなってしまうという課題があった。
例えば、MLの名称とナンバリングをSubject:ヘッダに挿入することが多いため、DKIM をMLへ適用するには格段の注意が必要となっていた。
実際、標準化においてもMLへの適用は詳細に検討されており、例えば、MLのドメインにおいて送信ドメインの認証を行い、認証に成功した場合に、MLに関する新しいヘッダを追加した上で電子署名を生成し、DKIM-Signature:ヘッダを置き換える（つまり、先に格納された送信ドメインの電子署名を削除する）ことを推奨している。
この場合、送信ドメインの署名が削除されてしまうため、1つ手前の送信ドメイン認証しか行われない仕様となっており、どのような経路で配送されてきたか（送信元メールサーバの特定）の確認（送信から受信まで全ての経路認証）が行うことが不可能であった。
更に、無償でMLサーバを提供しているものの中には、メール本文（ボディ）の一部に広告を挿入するものもあり、従来のDKIMの仕様では、メール本文（ボディ）の書き換えに対応することができなかった。
本発明は、上述した課題を解決するためになされたものであり、電子メール、特に同報メール（例えば、メーリングリストで送信されるメール）に対する電子署名付加方法、および検証方法に関するものであり、送信ドメイン認証における経路認証、およびメール本文の内容保証を両立させて電子メール情報が正しく送られたことを容易に認証することができる電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法を得ることを目的とする。
上述した課題を解決するため、電子メール情報管理プログラムは、電子メール情報を管理するコンピュータに、メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップとを実行させる。
また、電子メール情報を管理するための電子メール情報管理装置であって、メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得部と、前記情報取得部により取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成部と、前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成部と、前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報と、前記電子署名データ生成部により生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納部とを備える。
また、電子メール情報を管理するコンピュータにより行われる電子メール情報管理方法であって、メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップとを備える。
以上の態様において、前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納ステップ又はヘッダ情報格納部は、前記電子メールのヘッダ部に前記他のネットワークにおいて既に格納されているヘッダ情報に対し、前記署名ヘッダ情報を追加的に格納することができる。
また、前記情報取得ステップまたは前記情報取得部により取得される署名関連情報には、前記電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることができる。
また、前記情報取得ステップまたは前記情報取得部により取得される署名関連情報には、前記電子署名に使用したアルゴリズムがそれを示す属性タグとともに含まれることができる。
また、前記情報取得ステップまたは前記情報取得部により取得される署名関連情報には、署名情報作成時の時間情報がそれを示す属性タグとともに含まれることができる。
前記情報取得ステップまたは前記情報取得部により取得される前記署名対象情報は選択指定可能とすることができる。
また、電子メール情報管理方法において、前記電子メールが他のネットワークに送信され、該他のネットワークにおいて受信された場合に、前記他のネットワーク系内において、前記署名ヘッダ情報に基づいて、該電子メールの検証を行う検証ステップが備えられることを特徴とする。
さらに、この電子メール情報管理方法において、前記検証ステップの結果、該電子メールが正当なものと判断された場合、前記他のネットワーク系内において、前記情報取得ステップと、前記特徴量情報生成ステップと、前記電子署名データ生成ステップと、前記ヘッダ情報格納ステップとが実行されることを特徴とする。
なお、本実施の形態においては、以下の項目が実行されている。
（１）電子情報のヘッダとボディに分割し、更に細かくヘッダ／ボディを項目毎に分割し、署名対象とする項目を決定する。
（２）決定した署名対象項目に対して、その内容の特徴量情報をそれぞれ算出する。
（３）事後、「誰が、どの項目を、どのように変更したか」の確認、および署名付加順序の正当性を担保するための情報を含む属性群を記録し、これら属性群に対する署名情報を生成・付加する。
（４）更に証明力を高めるため、生成した署名情報に対して、タイムスタンプ情報を付加してもよい。
（５）事後、「誰が、どの項目を、どのように変更したか」の確認、および署名付加順序の正当性を担保するための情報を含む属性群と生成した署名情報を内容とする署名ヘッダ情報を追加する。
（６）ヘッダ項目の一部、もしくはボディの変更が行われると、前記と同様の方法、記述により、新たな署名ヘッダ情報を生成・追加する。この時、先に記録されている署名ヘッダ情報は削除せず、上書きされない版数管理を行う。
（７）検証時には、ヘッダに付加された全ての署名ヘッダ情報の内容を検証することで、「誰が、どの項目を、どのように変更したか」を確認することが可能である。追記されている署名ヘッダ情報の順序の正当性については、各署名ヘッダ情報内に記録された署名付加順序の正当性を担保するための情報で確認することが可能である。
（８）ボディの書き換え時には、本文領域と添付領域を識別する項目を確認することで、それぞれの特徴値の算出・記録を行う。
本発明によれば、送信元メールサーバの正当性確認とメールコンテンツ（差出人、宛先、件名、本文等を含む）の内容保証を両立させることが可能になる。最終的な受信側において、具体的には、どのような経路を辿って配送されてきたか（送信元メールサーバの特定）確認（経路情報）が可能で、かつ配送過程でヘッダ情報や本文情報を変更・追加されても、項目単位で確認することが可能で、その操作事実の正当性証明を第三者に行うことが可能である。
その結果、受信者は、送信者、経路情報、変更・追加等の操作を項目単位で確認できるようになるため、安心してメールを受信したり閲覧することが可能となる。
以下、本発明の実施の形態を図を用いて説明する。
実施の形態１．
図１は、本発明の原理を示すブロック説明図である。図２は、その処理フローチャートを示している。
図２に示す全体動作は、電子メール情報１が作成され、他のネットワーク系へ送信する場合に開始される。まず、差出人（From）、宛先（To）、件名（Subject）等を含むヘッダ情報１ａと、メール本文の内容を表す本文情報１ｂに区分し（ＳＴ−１）、更にヘッダ情報１ａは、事後、原本保証（内容保証）を必要対象としない署名非対象ヘッダ情報群１ａ−１と、必要対象とする署名対象ヘッダ情報群１ａ−２に分離、区分される。本文情報はその内容により適宜本文情報１〜Ｎに区分される。
また、MIME（Multipurpose Internet Mail Extensions）-multipartメールの場合、各本文情報を区別可能な識別子の参照により、各本文情報の区分が行われる（ＳＴ−２）。
ここで、分離・区分された前記署名対象ヘッダ情報群に対する特徴量情報１０ａを生成するヘッダ情報特徴量生成部１０（ＳＴ−３）と本文情報群の特徴量情報２０ｂを生成する本文情報特徴量生成部２０（ＳＴ−４）を備える。
更に、前記署名対象ヘッダ情報群の特徴量情報、および本文情報群の特徴量情報を一体化し、署名対象ヘッダ情報群および本文情報の特徴量情報２ａを生成する特徴量集合生成部３０−１と、署名付加順序の正当性を担保するための情報２ｂを取得し付加する署名付加順序情報取得部３０−２と、署名情報２ｃを生成し付加する署名情報生成部３０−３とを備える。
そして、署名関連情報２ｄ、署名対象ヘッダおよび本文情報２ｅ、署名対象ヘッダ情報群および本文情報２ｆ、及びそれらの特徴量情報２ａ、署名付加順序情報２ｂ、これら内容に対する署名者の「署名情報」を付加した署名ヘッダ情報２の生成を行う署名ヘッダ情報生成部３０が備えられる（ＳＴ−５）。署名ヘッダ情報２は、署名ヘッダ情報格納部４０によって、電子メール情報１内のヘッダ情報内に追記・格納される（ＳＴ−６）。
そして、この電子メールが配送経路中に他のネットワーク（第２ネットワーク）へ配送されるごとに、上記動作が繰り返される。このとき先に格納した署名ヘッダ情報２は上書きされず、版数管理により追記されて格納される。
そして、この電子メールが他のネットワーク（異なるドメイン名を有するネットワーク）で受信されると（ＳＴ-７）、後述するように署名ヘッダ情報の検証が行われ（ＳＴ−８）、更に他のネットワーク（第３ネットワーク）に送信される場合（例えば同報メール送信の場合）（ＳＴ−９，ＹＥＳ）、ステップＳＴ−２に戻り、上述したと、同様に第２ネットワークにおいて、再度ヘッダ情報特徴量生成部１０、本文情報特徴量生成部２０、署名ヘッダ情報生成部３０を用いて新たな署名ヘッダ情報２が生成され、署名ヘッダ情報格納部４０によって、電子メール情報１内のヘッダ情報内に追記・格納される。この時、先に格納した署名ヘッダ情報２は上書きされず、版数管理により順次格納されて記録がなされていく。
上述した署名ヘッダ情報の検証処理（ＳＴ−８）においては、格納された署名ヘッダ情報２が改ざんされていないことの検証を行う機能を有する署名ヘッダ情報改ざん検証部５０−１を備え、また、電子メール情報１内のヘッダ情報、および本文情報から特徴量情報を生成し、署名ヘッダ情報２に格納された該特徴量情報と比較を行い、変更有無の確認を行う機能を有する項目特徴量情報検証部５０−２を備え、更に、検証対象となるすべての署名ヘッダ情報２を比較・検証し、項目毎に変更有無の確認を行う機能を有する署名ヘッダ情報検証部５０−３（ＳＴ−８）を備える電子情報検証部５０を備える。
本実施の形態の詳細な一例を示すために、図３のような登場エンティティ、メール配送環境を設定し、ユーザＡ（送信者）から送られた同報メールが、ドメイン１（第１ネットワーク系）からドメイン３（第３ネットワーク系）を経由してユーザＢ（受信者）までメール配送されるシーンを想定して説明する。
具体的には、ユーザＡ（送信者）により、「差出人（From）：userA@xx.com」、「宛先（To）：ml@zz.com」、「件名（Subject）：hello」を含むヘッダ情報を、メール本文情報として、「こんにちは、お元気ですか」という内容のメッセージを記載する場面を想定して同報メールが送信され、ユーザＢ（受信者）により、各配送時点での変更者の確認、どのような経路を辿って配送されてきたかの経路情報の確認、およびメール情報（ヘッダ情報、本文情報）の内容確認が行われる場面を想定する。
同報メール（ml@zz.com）はユーザＢ（受信者）も閲覧・受信できる状況となっていることを前提とする。また、ドメイン２のMLサーバによるヘッダ情報の追加・変更が行われる事例として、第１の実施の形態では、件名（Subject）のみが書き換わる場面、第２の実施の形態では、件名（Subject）が書き換わり、本文への広告追加が行われる場面の２つの実施形態例を採り上げて説明する。
第１の実施の形態．
まず、第１の実施形態として、ドメイン２のMLサーバにより、件名（Subject）のみが書き換わる場面を想定して説明する。なお、本実施形態では、メール情報中のすべての項目を署名対象とすることを前提に説明する。
図４は、第１の実施形態におけるＳＭＴＰサーバ１による署名付加の様子を示している。
ユーザＡ（送信者）により、メール作成、およびメール送信の実行ボタンを押下されると、まず、SMTPサーバ１により、ヘッダ情報と本文情報の区分（ＳＴ-ＳＭＴＰ１−１）、および署名対象のヘッダ情報群と本文情報の抽出（ＳＴ-ＳＭＴＰ１−２）が行われる。本例の場合、メール情報中のすべての項目を署名対象とすることを前提にしているため、署名対象ヘッダ情報群は、差出人（From）、宛先（To）、件名（Subject）、本文情報（Content-Type）とする。この選択は、あらかじめメールシステム内で定義されるか、送信者自身が保証したい項目を指定し、選択することで実現できる。
次に、ＳＴ-ＳＭＴＰ１−２で抽出された署名対象ヘッダ情報群の特徴量情報の生成（ＳＴ-ＳＭＴＰ１−３）、および本文情報の特徴量情報の生成（ＳＴ-ＳＭＴＰ１−４）を行う。
続けて、署名対象ヘッダ情報群の特徴量情報と本文情報の特徴量情報を一体化し、署名ヘッダ情報（PIAT-Signature:ヘッダ）の属性値として記録する（ＳＴ-ＳＭＴＰ１−５−１）。本例では、From:ヘッダの特徴量として、“0xf81dca2e22”が、To:ヘッダの特徴量として、“0x31dca9ba12”が、Subject:ヘッダの特徴量として、“0x5243cd2a8b”が、Content-Type:ヘッダの特徴量として、“0xf91d38aac1”がそれぞれ算出されている様子を示している。
また、一体化することの一例として、署名対象ヘッダを格納するためのh属性（h:属性タグ）を設け、該属性内にコロン（:）を境界として署名対象としてヘッダ情報を格納して列挙する。
更に、署名対象ヘッダ情報群、および本文情報の特徴量情報を格納するためのh-hash属性を設け、h属性同様、該属性内にコロン（:）を境界として各特徴量を格納し、列挙する。
これにより、それぞれのヘッダに格納される情報の順序を統一的に対応付けることが可能となる。PIAT-Signature:ヘッダのその他の属性としては、署名関連情報の属性として、署名を行ったドメイン名（ネットワーク情報）を格納するためのｄ属性（d：属性タグ）（例: d=xx.com）、署名の生成に利用したアルゴリズムを格納するためのa属性（ａ：属性タグ）（例: a=rsa-sha1）等があり、本例では、d属性、およびa属性が記録される様子を示している。
a属性で署名の生成に利用したアルゴリズムを格納することにより、事後確認を行い、その正当性を判断できるようにしている。これにより、次回以降の署名生成時、および検証時で使用する署名アルゴリズムを容易に検索可能となる。
更に、オリジナルのヘッダ情報、および本文情報を格納するためのh-org属性、署名付加順序の正当性を担保するための情報（いわゆる、署名情報の時系列性を確保するための情報）を格納するt属性（ｔ:属性タグ）（例: t=20070801154256）を記録している。
t属性は予め署名付加順序情報を取得し、本例では日時情報を用いており、2007年8月1日15時42分56秒が格納されている様子を示している（ＳＴ-ＳＭＴＰ１−５−２）。
なお、日時情報を用いる場合、日時の改変が不可能な第三者機関が発行する正当な情報が取得できることが望まれることは容易に推測できる。日時情報の他に、１から順に加算していく、インクリメンタルカウンタ方式を用いてもよい。
以上の各属性の格納が完了すると、続けて、署名ヘッダ情報全体を対象とし、署名情報の生成を行う（ＳＴ-ＳＭＴＰ１−５−３）。本例では、PIAT-Signature:ヘッダの内容すべて（「PIAT-Signature:〜t=20070801154256;」）を署名対象としてハッシュ値を生成し、更に、SMTPサーバ１の秘密鍵を用いて署名情報を生成し、該署名情報を格納するためのb属性を設け、該属性に生成した署名情報を格納している。
ここで、秘密鍵を用いて署名情報の生成を行うには、予めSMTPサーバ１内にて、秘密鍵と公開鍵のペアを生成しておき、署名情報の生成時には本秘密鍵を用いる。ペアとなる公開鍵はSMTPサーバ１上で公開し、受信側にて取得できるようにしておく。
図４では、PIAT-Signature:ヘッダの最後の属性として、b=8ffkadalo1lRDI2jsdl82が格納されている様子を示している。このように、PIAT-Signature:ヘッダ（本例では、b属性:署名情報部分は含まない）を署名対象とすることにより、該署名を付加したドメイン以外がPIAT-Signature:ヘッダを変更させない仕組みとすることができ、PIAT-Signature:ヘッダの改ざん防止対策とすることができる。
更に署名情報の他に、確定時刻を保証するための技術である、タイムスタンプを利用し、付加することにより証明力を高めることも可能であるが、本例では必ずしもタイムスタンプの付加は必須としていない。
また、本例では、h-org属性を設け、オリジナルのヘッダ情報、および本文情報を格納している。
本属性にオリジナルの内容が格納されていない場合、事後配送過程で変更がなされた場合、変更の事実は確認できるが、どのような状態から変更が行われたかの確認を行うことができない。その確認を可能とするためにh-org属性を設けているが、少なくとも、本文情報に関しては、情報量が大きくなる可能性が高いため、該情報をヘッダ中に格納としておくのは、情報量の膨大の観点から、更に安全性の観点からあまり好ましくない。格納するか否かの選択は管轄するSMTPサーバのポリシーに従う、および検証サービスの充実度に影響するものとし、このh-org属性はオプション的役割を持つことをひとつ付け加えておく。
SMTPサーバ１による署名ヘッダ情報の生成が完了すると、署名ヘッダ情報格納部４０によって、電子メール情報のヘッダ内に該情報が格納される（ＳＴ-ＳＭＴＰ１−６）。
本実施形態では、署名ヘッダ情報をヘッダ情報の一部として、ヘッダ情報内に格納したが、別サーバで一括管理する方法もあり得る。その場合、どのメールに対する署名ヘッダ情報かを別に管理する必要が生じるため、該電子メール情報のヘッダ情報内に順次格納され、配送されていくのが望ましい。
SMTPサーバ１による署名ヘッダ情報の生成が完了し、電子メール情報のヘッダ内に該情報が格納されると、SMTPサーバ１からドメイン２のPOPサーバ１に対してメールが送信される。
図５は、ドメイン２内のPOPサーバ１における署名検証処理の様子を示している。まず、SMTPサーバ１からの正しい送信情報であることを確認するため、署名ヘッダ情報に付加されたPIAT-Signature:ヘッダの検証を行う。
具体的には、まず、署名情報の生成時に使われた秘密鍵に対する公開鍵をSMTPサーバ１から取得する。このSMTPサーバ１の取得情報は、PIAT-Signature:ヘッダ内に格納されている必要があることは容易に推測できる。続けて、PIAT-Signature:ヘッダ（本例では署名情報を示すb属性は含まない）の内容からハッシュ値を生成し、署名情報を生成する（ＳＴ−ＰＯＰ１−１）。ここで署名情報の生成アルゴリズムには、a属性に格納されている、rsa-sha1を用いる。
次に、先に取得した公開鍵を利用して、PIAT-Signature:ヘッダ内のb属性に格納された署名情報からハッシュ値を取り出し、受信した電子メール情報から生成したハッシュ値を比較する（ＳＴ−ＰＯＰ１−２）。
これは、署名ヘッダ情報改ざん検証部５０−１を用いて比較が可能である。これらハッシュ値が同じであれば検証（認証）成功となる。次の配送先に検証に成功したことを示すため、検証結果を格納するヘッダを追加してもよい。ここで検証に失敗した場合、途中なんらかの改変が行われていることを示しているため、ユーザＡ（送信者）に対してその旨、通知を行う。
正しい送信情報であることが確認できれば、宛先（To）: ml@zz.comが指定された同報メールは、一旦、管理するMLサーバへ送信される。該同報メールを受信したMLサーバは、ヘッダ情報中の件名（Subject）にMLの項番を表す“[ml:001]”を元の件名の前に追加する（ＳＴ−ＭＬ−１）。
図６は、件名（Subject）にMLの項番を表す“[ml:001]”が追加された様子を示している。この行為は、MLサーバがヘッダ情報を変更する一般的な（標準的な）動作である。件名（Subject）を変更したMLサーバはSMTPサーバ２に対して、該電子メール情報を送信する。
図７は、本実施形態におけるＳＭＴＰサーバ２による署名付加の様子を示している。まず、SMTPサーバ２における署名対象ヘッダ情報群抽出のための項目選択に関して、SMTPサーバ１の署名ヘッダ情報内を参照し、どの項目が署名対象となっているかの確認、および署名情報の生成方法に関する情報を取得する（ＳＴ−ＳＭＴＰ２−１）。
本例の場合、h属性に格納された情報から、差出人（From）、宛先（To）、件名（Subject）、本文情報（Content-Type）が署名対象であることが確認でき、a属性に格納された情報から、署名情報の生成方法（生成アルゴリズム）として、rsa-sha1を使用して生成することが確認できる。次に、確認した署名対象ヘッダ情報群の特徴量情報の生成（ＳＴ−ＳＭＴＰ２−２）、および本文情報の特徴量情報の生成（ＳＴ−ＳＭＴＰ２−３）を行う。
続けて、署名対象ヘッダ情報群の特徴量情報と本文情報の特徴量情報を一体化し、署名ヘッダ情報（PIAT-Signature:ヘッダ）の属性値として記録する（ＳＴ−ＳＭＴＰ２−４−１）。
本例では、From:ヘッダの特徴量として、“0xf81dca2e22”が、To:ヘッダの特徴量として、“0x31dca9ba12”が、Subject:ヘッダの特徴量として、“0xa8bdc1238c”が、Content-Type:ヘッダの特徴量として、“0xf91d38aac1”がそれぞれ算出されている様子を示している。
PIAT-Signature:ヘッダのその他の属性としては、署名関連情報の属性として、署名を行ったドメイン名を格納するためのd属性（例: d=zz.com）、署名の生成に利用したアルゴリズムを格納するためのa属性（例: a=rsa-sha1）等がある。
ここで、d属性はSMTPサーバ１と違い、SMTPサーバ２のドメイン名が格納され、a属性はそのまま継承される。更に、オリジナルのヘッダ情報、および本文情報を格納するためのh-org属性、署名付加順序の正当性を担保するための情報（いわゆる、署名情報の時系列性を確保するための情報）を格納するt属性（例: t=20070801154501）も同様に記録している（ＳＴ−ＳＭＴＰ２−４−２）。
以上の各属性の格納が完了すると、続けて、署名ヘッダ情報全体を対象とし、署名情報の生成を行う（ＳＴ−ＳＭＴＰ２−４−３）。本例では、PIAT-Signature:ヘッダの内容すべて（「PIAT-Signature:〜t=20070801154501;」）を署名対象としてハッシュ値を生成し、更に、SMTPサーバ２の秘密鍵を用いて署名情報を生成し、該署名情報を格納するためのb属性を設け、該属性に生成した署名情報を格納している。
ここで、秘密鍵を用いて署名情報の生成を行うには、予めSMTPサーバ２内にて、秘密鍵と公開鍵のペアを生成しておき、署名情報の生成時には本秘密鍵を用いる。ペアとなる公開鍵はSMTPサーバ２上で公開し、受信側にて取得できるようにしておく。
図７では、PIAT-Signature:ヘッダの最後の属性として、b=jf987a3bdFHaiq13291bdが格納されている様子を示している。このように、PIAT-Signature:ヘッダ（本例では、b属性:署名情報部分は含まない）を署名対象とすることにより、該署名を付加したドメイン以外がPIAT-Signature:ヘッダを変更させない仕組みとすることができ、PIAT-Signature:ヘッダの改ざん防止対策とすることができる。更に署名情報の他に、確定時刻を保証するための技術である、タイムスタンプを利用・付加することにより証明力を高めることも可能であるが、本例では必ずしもタイムスタンプの付加は必須としていない。
SMTPサーバ２による署名ヘッダ情報の生成が完了すると、署名ヘッダ情報格納部４０によって、電子メール情報のヘッダ内に該情報が格納される（ＳＴ−ＳＭＴＰ２−５）。
この時、ヘッダ情報内には、SMTPサーバ１の署名ヘッダ情報が格納されているため、先に格納された該署名ヘッダ情報は上書きされず、版数管理により順次格納し記録がなされていく。また先に格納されたSMTPサーバ１の署名ヘッダ情報との時系列性に関しては、署名ヘッダ情報内に記録されたt属性にて事後確認可能である。
各t属性は、それを包含した署名情報の検証により、その正当性が担保されれば、本時系列性についても同様に正当性を確保することが可能となる。また、署名情報に対して、タイムスタンプが付加されているならば、該情報でも事後確認可能である。
SMTPサーバ２による署名付加が完了し、電子メール情報のヘッダ内に該情報が格納されると、SMTPサーバ２からドメイン３のPOPサーバ２に対してメールが送信される。
図８は、ドメイン３内のPOPサーバ２における署名検証処理の様子を示している。まず、SMTPサーバ１、およびSMTPサーバ２からの正しい送信情報であることを確認するため、署名ヘッダ情報に付加されたPIAT-Signature:ヘッダの検証を行う。
具体的には、まず、署名情報の生成時に使われた秘密鍵に対する公開鍵をSMTPサーバ１、およびSMTPサーバ２からそれぞれ取得する。続けて、PIAT-Signature:ヘッダ（本例では署名情報を示すb属性は含まない）の内容からハッシュ値を生成し、署名情報を生成する（ＳＴ−ＰＯＰ２−１）。
ここで署名情報の生成には、各a属性に格納されている、rsa-sha1を用いる。次に、先に取得した公開鍵を利用して、PIAT-Signature:ヘッダ内のb属性に格納された署名情報からハッシュ値を取り出し、受信した電子メール情報から生成したハッシュ値を比較する（ＳＴ−ＰＯＰ２−２）。
これは、署名ヘッダ情報改ざん検証部５０−１を用いて比較が可能である。これらハッシュ値が同じであれば検証（認証）成功となる。次の配送先に検証に成功したことを示すため、検証結果を格納するヘッダを追加してもよい。ここで検証に失敗した場合、途中なんらかの改変が行われていることを示しているため、ユーザＢ（受信者）に対してその旨、通知を行う。
正しい送信情報であることが確認できれば、続けて、各ヘッダ情報、および本文情報の内容を取り出し、ヘッダ情報特徴量生成部１０、および本文情報特徴量生成部２０を用いて、各ヘッダ情報、および本文情報の特徴量を生成し、SMTPサーバ２の署名ヘッダ情報のh-hash属性に記録された各ヘッダ情報、および本文情報の特徴量と比較を行う（ＳＴ−ＰＯＰ２−３、ＳＴ−ＰＯＰ２−４）。
図９は、その検証の様子を示している。具体的には、From:ヘッダの“userA@xx.com”からヘッダ情報特徴量生成部１０を用いて、From:ヘッダの特徴量を生成し（ＳＴ−ＰＯＰ２−３）、SMTPサーバ２の署名ヘッダ情報のh-hash属性に記録されているFrom:ヘッダの特徴量（“0xf81dca2e22”）と比較を行う（ＳＴ−ＰＯＰ２−４）。
これは、項目特徴量情報検証部５０−２を用いて比較が可能である。続けて、To:ヘッダ、Subject:ヘッダ、Content-Type（本文情報）も同様の方法で比較を行い、同一かどうか確認する。上記比較の結果、異なる場合は、途中なんらかの改変が行われていることを示しているため、ユーザＢ（受信者）に対してその旨、通知を行う。
同一であれば、SMTPサーバ１の署名ヘッダ情報、およびSMTPサーバ２の署名ヘッダ情報の各特徴量情報の比較及び検証を行う。
図１０は、その検証の様子を示している。具体的には、SMTPサーバ１の署名ヘッダ情報、およびSMTPサーバ２の署名ヘッダ情報のh-hash属性を確認し、署名ヘッダ情報検証部５０−３を用いて、それぞれの署名対象ヘッダ情報、および本文情報の特徴量を比較する（ＳＴ−ＰＯＰ２−５）。
例えば、h-hash属性の一番初めに記録されている“0xf81dca2e22”は、From:ヘッダの特徴量である。一番初めに記録されているのがFrom:ヘッダであることを確認するには、h属性を確認すればわかる。From:ヘッダの場合、SMTPサーバ1の署名ヘッダ情報、およびSMTPサーバ２の署名ヘッダ情報共に“0xf81dca2e22”が記録されており、同一のため、From:ヘッダは、SMTPサーバ1の時点から変更が加えられていないことを確認できる。
同様に、To:ヘッダも共に“0x31dca9ba12”で同一で変更なし、Content-Type（本文情報）についても共に“0xf91d38aac1”で同一で変更がないことを確認できる。一方、Subject:ヘッダにおいては、SMTPサーバ1のSubject:ヘッダの特徴量は、“0x5243cd2a8b”で、SMTPサーバ２のSubject:ヘッダの特徴量は、“0xa8bdc1238c”で異なる値が格納されている。これは、唯一、配送経路途中で変更となったヘッダ情報であることを示しており、かつ該署名ヘッダ情報内のb属性（SMTPサーバ２の署名情報）からSMTPサーバ２により変更がなされたことを確認できる。
更に、SMTPサーバ１の署名ヘッダ情報、およびSMTPサーバ２の署名ヘッダ情報の各h-org属性内のSubject:ヘッダ部分を確認すれば、どのように変更がなされたかも確認できる。
本例では、“hello”から“[ml:001] hello”に変更がなされたことが確認できる。h-org属性はこのために利用するものであり、記録を行うことでより検証サービスの充実度を向上させることが可能となる。
以上の比較・検証の結果をまとめると、POPサーバ２は、ユーザＢ（受信者）に対して、（１）SMTPサーバ１からSMTPサーバ２の経路を辿って配送されてきたこと、（２）SMTPサーバ２が、件名（Subject）に対して[ml001]を追加したこと、（３）差出人（From）、宛先（To）、本文情報（Content-Type）の内容は配送中、変更が加えられていないことを通知可能となる。
このように第１の実施形態では、すべてのヘッダ情報、および本文情報に関して特徴量を記録、署名ヘッダ情報を追加していくことで、上記のような検証をユーザＢ（受信者）で行うことが可能となる。
第２の実施形態．
続けて、第２の実施形態では、本文情報への追加が伴う事象について採り上げ、特に件名（Subject）が書き換わり、本文情報への広告追加が行われる場面を想定して説明する。
本文情報への広告が追加される場合の一例として、例えば、無償でMLサーバを提供しているものの中には、メール本文（ボディ）の一部に広告を挿入するものもある。
また、複数の本文情報を持ち、各本文情報を区別可能な識別子を有するものとしての代表例として、MIME-multipartメールがある。
MIME-multipartとは、一通の電子メールに複数の異なる種類のデータを格納する方式で、電子メールにASCII文字以外のデータを格納するための「MIME」規格の拡張仕様である。インターネットの技術仕様の標準化にあたっているIETF（Internet Engineering Task Force）により、RFC 2112として規格化されている。添付ファイルとして画像を送ったりするのに使われる。
従来、電子メールはヘッダ情報と本文情報という2つの部分しか持てなかったが、multipart仕様により、「区切り文字」を境に任意の数の部分（パート）に分割することが可能となった。これにより、例えば1つの電子メールに本文、画像、ワープロ文書、音声をまとめて送受信することができる。
MIME-multipartメールには、Content-Type:ヘッダが設けられ、「メディアタイプ」と呼ばれる本文情報（ボディ）部分の属性を示すヘッダ情報がある。
図１１は、MIME-multipartメールの一例を示している。まず、ヘッダ情報で、multipartであることを宣言おり（図１１中、MIME-1）、ヘッダ情報と本文情報の境界には、空行（CR（0x0d）+LF（0x0a）のみの行））が存在する（図１１中、MIME-2）。
本文情報は、複数の「MIMEヘッダ情報＋本文情報」から構成される「ミニ・メッセージ」、すなわち「パート」になっている（図１１中、MIME-4）。同様に、MIMEヘッダ情報と本文情報の境界には、空行が存在する。この「ミニ・メッセージ」、すなわち「パート」が１つの添付ファイルやメール本文に該当する。
多くのメーラーでは、メール本文にテキストを記載してファイルを添付すると、このmultipart形式となる。１つのパートの境界は、「バウンダリ：boundary」と呼ばれる任意の文字列の行で示される（図１１中、MIME-3）。これはContent-Type:ヘッダのboundaryパラメータで、あらかじめヘッダに示されている（図１１中、MIME-6）。
図１１中、MIME-3で示される、「--boundary_str」は、これで、1つのパートの開始を示している。また、図１１中、MIME-5で示される、「--boundary_str--」は、全体のmultipartの終了を示している。
次に、このMIME-multipartメールを想定した署名ヘッダ情報の生成方法について説明する。図１２は、本実施形態におけるＳＭＴＰサーバ1による署名付加の様子を示している。署名ヘッダ情報の生成方法は、図４の手順で示したとおりであり、ここでは説明を割愛するが、本文情報（Content-Type）の特徴量は、本文情報内の「MIMEヘッダ+本文情報」、つまり、“--boundary_str〜こんにちは、お元気ですか”を対象として、本文情報特徴量生成部２０を用いて生成されていることを付け加えておく。
更に、図１３では、本実施形態におけるＳＭＴＰサーバ２による署名付加の様子を示している。これは、先に説明のとおり、ドメイン２内のMLサーバにより、Subject:ヘッダを変更し、本文情報に広告（“安心と安全の○△プロバイダ”という内容）を追加した場面を想定しており、これも署名ヘッダ情報の生成方法については、図７の手順で示したとおりであり、ここでは説明を割愛するが、本文情報（Content-Type）の特徴量は、本文情報内の「MIMEヘッダ+本文情報」、つまり、“--boundary_str〜安心と安全の○△プロバイダ”を対象として、本文情報特徴量生成部２０を用いて生成されていることを付け加えておく。
また、SMTPサーバ２が付加した署名ヘッダ情報内のh属性の最後に、本文情報を示すContent-Typeが追加され、同様に、h-hash属性の最後にも、本文情報（広告）の内容に対する特徴量が格納される。
検証時には、図９で示したとおり、各本文情報から本文情報特徴量生成部２０を用いて特徴量を生成し、h-hash属性に格納されている該特徴量と比較することで確認を行っていたが、図１３で示した例の場合、h属性に格納された本文情報を示す名前が共に“Content-Type”であるため、h-hash属性に格納された各特徴量は、どの本文情報に対する特徴量なのか識別することができない。
図１３で示した例の場合では、まず、送信者（SMTPサーバ１）によって、本文情報が記録され、それを受信したMLサーバ（SMTPサーバ２）は続けて、広告を示す本文情報を送信者が記録した本文情報より後に追記することを前提にすれば、最初のContent-Typeは、送信者（SMTPサーバ１）が記録した情報、2つ目のContent-Typeは、MLサーバ（SMTPサーバ２）が記録した情報と認識することが可能である。
また、別の手段では、図９で説明したとおり、本文情報から本文情報特徴量生成部２０を用いて特徴量を生成し、h-hash属性に格納されている該特徴量と比較し、一致することを確認することで、どちらの本文情報の特徴量かを判断することが可能である。
更に、図１０で説明したとおり、SMTPサーバ１が付加した署名ヘッダ情報と、SMTPサーバ２が付加した署名ヘッダ情報を参照し、署名ヘッダ情報検証部５０−３を用いて各特徴量を比較することで、追加となった本文情報（広告）の特徴量は、SMTPサーバ１の署名ヘッダ情報には存在せず、SMTPサーバ２の署名ヘッダ情報に新たに追加されていることが確認できるため、追加された特徴量は、本文情報（広告）であることを判断することが可能である。
更に、別の手段として、図１４で示すように、本文情報内の「MIMEヘッダ」に、本文情報の内容を示す“X-Content-Type-body”、“X-Content-Type-Advertisement”のように識別する情報を追加し、署名ヘッダ情報内のh属性にも該情報を示す内容を格納することで、各本文情報の特徴量を容易に識別・確認することが可能である。
この“X-”が先頭に付くヘッダ情報は、SMTPサーバ１、およびMLサーバが独自につける項目であることを示している。
本例の場合、共に“Content-Type: text/plain; charset="ISO-2022-JP"”であることを想定したが、当然、画像ファイル（例:GIFファイル）が添付される場合の構文は、“Content-Type image/gif”になるため、“X-Content-Type-body”のような追加による識別は必要ない。ただし、例えば、画像ファイルが添付されているメールの場合においては、署名ヘッダ情報内のh属性に格納する内容は、“Content-Type”だけでなく、“Content-Type image/gif”のような形式で記録されていることが望ましい。この場合、同様に、画像ファイルが2つ添付されているような場合、“Content-Type image/gif”だけでは識別できない可能性があるため、“X-Content-Type-gif1”、“X-Content-Type-gif2”のような書き方がより適切である。
上述した本発明の実施の形態において、各フローチャートに示したステップを電子メール情報管理プログラムとして、コンピュータにより読取り可能な記録媒体に記憶させることによって、構造解析方法をコンピュータに実行させることが可能となる。なお、本発明において、上記コンピュータにより読取り可能な記録媒体は、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
以上に詳述した実施の形態において、更に下記付記が追記される。
（付記１）
電子メール情報を管理するコンピュータに、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、
前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップと
を実行させる電子メール情報管理プログラム。
（付記２）
付記１に記載の電子メール情報管理プログラムであって、
前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納ステップは、前記電子メールのヘッダ部に前記他のネットワークにおいて既に格納されているヘッダ情報に対し、前記署名ヘッダ情報を追加的に格納することを特徴とする電子メール情報管理プログラム。
（付記３）
付記１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される署名関連情報には、前記電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理プログラム。
（付記４）
付記１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される署名関連情報には、前記電子署名に使用したアルゴリズムがそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理プログラム。
（付記５）
付記１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される署名関連情報には、署名情報作成時の時間情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理プログラム。
（付記６）
付記１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される前記署名対象情報は選択指定可能であることを特徴とする電子メール情報管理プログラム。
（付記７）
電子メール情報を管理するための電子メール情報管理装置であって、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得部と、
前記情報取得部により取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成部と、
前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成部と、
前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報と、前記電子署名データ生成部により生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納部と
を備える電子メール情報管理装置。
（付記８）
付記７に記載の電子メール情報管理装置において、
前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納部は前記電子メールのヘッダ部に前記署名ヘッダ情報を追加的に格納することを特徴とする電子メール情報管理装置。
（付記９）
付記７に記載の電子メール情報管理装置において、
前記情報取得部により取得される署名関連情報には、電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理装置。
（付記１０）
付記７に記載の電子メール情報管理装置において、
前記情報取得部により取得される署名関連情報には、前記電子署名に使用したアルゴリズムがそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理装置。
（付記１１）
付記７に記載の電子メール情報管理装置において、
前記情報取得部により取得される署名関連情報には、署名情報作成時の時間情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理装置。
（付記１２）
付記７に記載の電子メール情報管理装置において、
前記情報取得部により取得される前記署名対象情報は選択指定可能であることを特徴とする電子メール情報管理装置。
（付記１３）
電子メール情報を管理するコンピュータにより行われる電子メール情報管理方法であって、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、
前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップと
を備える電子メール情報管理方法。
（付記１４）
付記１３に記載の電子メール情報管理方法において、
前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納ステップは、前記電子メールのヘッダ部に前記他のネットワークにおいて既に格納されているヘッダ情報に対し、前記署名ヘッダ情報を追加的に格納することを特徴とする電子メール情報管理方法。
（付記１５）
付記１３に記載の電子メール情報管理方法において、
前記情報取得ステップにより取得される署名関連情報には、前記電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理方法。
（付記１６）
付記１３に記載の電子メール情報管理方法において、
前記情報取得ステップにより取得される署名関連情報には、前記電子署名に使用したアルゴリズムがそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理方法。
（付記１７）
付記１３に記載の電子メール情報管理方法において、
前記情報取得ステップにより取得される署名関連情報には、署名情報作成時の時間情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理方法。
（付記１８）
付記１３に記載の電子メール情報管理方法において、
前記情報取得ステップにより取得される前記署名対象情報は選択指定可能であることを特徴とする電子メール情報管理方法。
（付記１９）
付記１３に記載の電子メール情報管理方法において、
前記電子メールが他のネットワークに送信され、該他のネットワークにおいて受信された場合に、
前記他のネットワーク系内において、前記署名ヘッダ情報に基づいて、該電子メールの検証を行う検証ステップが備えられることを特徴とする電子メール情報管理方法。
（付記２０）
付記１９に記載の電子メール情報管理方法において、
前記検証ステップの結果、該電子メールが正当なものと判断された場合、前記他のネットワーク系内において、前記情報取得ステップと、前記特徴量情報生成ステップと、前記電子署名データ生成ステップと、前記ヘッダ情報格納ステップとが実行されることを特徴とする電子メール情報管理方法。
本発明の実施の形態全体の原理説明ブロック図である。 本発明の実施の形態の原理説明を示す処理フローチャートである。 本発明の第１の実施の形態（登場エンティティ、環境）を示す図である。 第１の実施形態におけるＳＭＴＰサーバ１による署名付加処理を示す図である。 第１の実施形態におけるドメイン２内のPOPサーバ１による署名検証処理を示す図である。 第１の実施形態におけるドメイン２内のMLサーバによるヘッダ変更処理を示す図である。 第１の実施形態におけるＳＭＴＰサーバ２による署名付加処理を示す図である。 第１の実施形態におけるPOPサーバ２による署名ヘッダ情報改ざん検証処理を示す図である。 第１の実施形態におけるPOPサーバ２による項目特徴量情報検証処理を示す図である。 第１の実施形態におけるPOPサーバ２による署名ヘッダ情報検証処理を示す図である。 MIME-multipart電子メール情報の一例を示す図である。 第２の実施形態におけるＳＭＴＰサーバ１による署名付加後のMIME-multipart電子メール情報を示す図である。 第２の実施形態におけるＳＭＴＰサーバ２による署名付加後のMIME-multipart電子メール情報を示す図である。 第２の実施形態におけるＳＭＴＰサーバ２による署名付加後のMIME-multipart電子メール情報（X-Content-Type付加時）を示す図である。
符号の説明
１ 電子情報、２ 署名ヘッダ情報、１０ ヘッダ情報特徴量生成部、２０ 本文情報特徴量生成部、３０ 署名ヘッダ情報生成部、３０−１ 特徴量集合生成部、３０−２ 署名付加順序情報取得部、３０−３ 署名情報生成部、４０ 署名ヘッダ情報格納部、５０ 電子情報検証部、５０−１ 署名ヘッダ情報改ざん検証部、５０−２ 項目特徴量情報検証部、５０−３ 署名ヘッダ情報検証部。

Claims (7)

  1. 電子メール情報を管理するコンピュータに、
    メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報と、署名情報の時系列性を確保するための署名付加順序情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、
    前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、
    前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、
    前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップと
    を実行させる電子メール情報管理プログラム。
  2. 請求項１に記載の電子メール情報管理プログラムであって、
    前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納ステップは、前記電子メールのヘッダ部に前記他のネットワークにおいて既に格納されているヘッダ情報に対し、前記署名ヘッダ情報を追加的に格納することを特徴とする電子メール情報管理プログラム。
  3. 請求項１に記載の電子メール情報管理プログラムにおいて、
    前記情報取得ステップにより取得される署名関連情報には、前記電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理プログラム。
  4. 電子メール情報を管理するための電子メール情報管理装置であって、
    メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報と、署名情報の時系列性を確保するための署名付加順序情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得部と、
    前記情報取得部により取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成部と、
    前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成部と、
    前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報と、前記電子署名データ生成部により生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納部と
    を備える電子メール情報管理装置。
  5. 電子メール情報を管理するコンピュータにより行われる電子メール情報管理方法であって、
    メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報と、署名情報の時系列性を確保するための署名付加順序情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、
    前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、
    前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、
    前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップと
    を備える電子メール情報管理方法。
  6. 請求項５に記載の電子メール情報管理方法において、
    前記電子メールが他のネットワークに送信され、該他のネットワークにおいて受信された場合に、
    前記他のネットワーク系内において、前記署名ヘッダ情報に基づいて、該電子メールの検証を行う検証ステップが備えられることを特徴とする電子メール情報管理方法。
  7. 請求項６に記載の電子メール情報管理方法において、
    前記検証ステップの結果、該電子メールが正当なものと判断された場合、前記他のネットワーク系内において、前記情報取得ステップと、前記特徴量情報生成ステップと、前記電子署名データ生成ステップと、前記ヘッダ情報格納ステップとが実行されることを特徴とする電子メール情報管理方法。
JP2007266064A 2007-10-12 2007-10-12 電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法 Expired - Fee Related JP4444998B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007266064A JP4444998B2 (ja) 2007-10-12 2007-10-12 電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法
US12/208,068 US8832202B2 (en) 2007-10-12 2008-09-10 E-mail information management apparatus, and E-mail information management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007266064A JP4444998B2 (ja) 2007-10-12 2007-10-12 電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法

Publications (2)

Publication Number Publication Date
JP2009093576A JP2009093576A (ja) 2009-04-30
JP4444998B2 true JP4444998B2 (ja) 2010-03-31

Family

ID=40535229

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007266064A Expired - Fee Related JP4444998B2 (ja) 2007-10-12 2007-10-12 電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法

Country Status (2)

Country Link
US (1) US8832202B2 (ja)
JP (1) JP4444998B2 (ja)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7162035B1 (en) 2000-05-24 2007-01-09 Tracer Detection Technology Corp. Authentication method and system
US8171567B1 (en) 2002-09-04 2012-05-01 Tracer Detection Technology Corp. Authentication method and system
BRPI0800633A2 (pt) * 2008-03-13 2009-10-27 Coppe Ufrj método para formação de comunidades virtuais espontáneas baseadas em interesses comuns utilizando faixas de interesse
US7995196B1 (en) 2008-04-23 2011-08-09 Tracer Detection Technology Corp. Authentication method and system
US9473437B1 (en) 2012-02-13 2016-10-18 ZapFraud, Inc. Tertiary classification of communications
JP5983008B2 (ja) * 2012-05-10 2016-08-31 富士通株式会社 不正メールの検知方法，その検知プログラム及びその検知装置
JP6044323B2 (ja) * 2012-12-20 2016-12-14 富士通株式会社 不正メールの検知方法，その検知プログラム及びその検知装置
KR102058635B1 (ko) * 2012-12-24 2019-12-24 삼성전자주식회사 파일 이름 제어 방법 및 그 전자 장치
JP6085978B2 (ja) * 2013-01-31 2017-03-01 富士通株式会社 メール処理方法、メール処理プログラム及びメール処理装置
US10277628B1 (en) 2013-09-16 2019-04-30 ZapFraud, Inc. Detecting phishing attempts
US10694029B1 (en) 2013-11-07 2020-06-23 Rightquestion, Llc Validating automatic number identification data
US10721195B2 (en) 2016-01-26 2020-07-21 ZapFraud, Inc. Detection of business email compromise
US10805314B2 (en) 2017-05-19 2020-10-13 Agari Data, Inc. Using message context to evaluate security of requested data
US10805270B2 (en) 2016-09-26 2020-10-13 Agari Data, Inc. Mitigating communication risk by verifying a sender of a message
US10880322B1 (en) 2016-09-26 2020-12-29 Agari Data, Inc. Automated tracking of interaction with a resource of a message
US11936604B2 (en) 2016-09-26 2024-03-19 Agari Data, Inc. Multi-level security analysis and intermediate delivery of an electronic message
US11722513B2 (en) 2016-11-30 2023-08-08 Agari Data, Inc. Using a measure of influence of sender in determining a security risk associated with an electronic message
US11044267B2 (en) 2016-11-30 2021-06-22 Agari Data, Inc. Using a measure of influence of sender in determining a security risk associated with an electronic message
US10715543B2 (en) 2016-11-30 2020-07-14 Agari Data, Inc. Detecting computer security risk based on previously observed communications
US11019076B1 (en) 2017-04-26 2021-05-25 Agari Data, Inc. Message security assessment using sender identity profiles
US11102244B1 (en) 2017-06-07 2021-08-24 Agari Data, Inc. Automated intelligence gathering
US11757914B1 (en) 2017-06-07 2023-09-12 Agari Data, Inc. Automated responsive message to determine a security risk of a message sender
US11818276B1 (en) * 2022-10-07 2023-11-14 Uab 360 It Optimized header information to enable access control

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5005200A (en) * 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5465299A (en) * 1992-12-03 1995-11-07 Hitachi, Ltd. Electronic document processing system and method of forming digital signature
US7966372B1 (en) * 1999-07-28 2011-06-21 Rpost International Limited System and method for verifying delivery and integrity of electronic messages
US20040073617A1 (en) * 2000-06-19 2004-04-15 Milliken Walter Clark Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail
US7251728B2 (en) * 2000-07-07 2007-07-31 Message Secure Corporation Secure and reliable document delivery using routing lists
US20030050981A1 (en) * 2001-09-13 2003-03-13 International Business Machines Corporation Method, apparatus, and program to forward and verify multiple digital signatures in electronic mail
US20060168006A1 (en) * 2003-03-24 2006-07-27 Mr. Marvin Shannon System and method for the classification of electronic communication
US20050015455A1 (en) * 2003-07-18 2005-01-20 Liu Gary G. SPAM processing system and methods including shared information among plural SPAM filters
JP2005101883A (ja) 2003-09-25 2005-04-14 Hitachi Ltd 電子メール文書原本性保証装置
US7698558B2 (en) * 2003-11-21 2010-04-13 Rpost International Limited System for, and method of, providing the transmission, receipt and content of an e-mail message
US7437558B2 (en) * 2004-06-01 2008-10-14 Cisco Technology, Inc. Method and system for verifying identification of an electronic mail message
US20070005702A1 (en) * 2005-03-03 2007-01-04 Tokuda Lance A User interface for email inbox to call attention differently to different classes of email
WO2006130772A2 (en) * 2005-06-01 2006-12-07 Goodmail Systems, Inc. E-mail stamping with from-header validation
JP2009512082A (ja) * 2005-10-21 2009-03-19 ボックスセントリー ピーティーイー リミテッド 電子メッセージ認証
US7904725B2 (en) * 2006-03-02 2011-03-08 Microsoft Corporation Verification of electronic signatures
US8126971B2 (en) * 2007-05-07 2012-02-28 Gary Stephen Shuster E-mail authentication
US20090006860A1 (en) * 2007-06-26 2009-01-01 John Gordon Ross Generating multiple seals for electronic data
US20090031135A1 (en) * 2007-07-27 2009-01-29 Raghunathan Kothandaraman Tamper Proof Seal For An Electronic Document
US20090037340A1 (en) * 2007-07-30 2009-02-05 Avoco Secure Digital certification method and apparatus

Also Published As

Publication number Publication date
US20090100079A1 (en) 2009-04-16
US8832202B2 (en) 2014-09-09
JP2009093576A (ja) 2009-04-30

Similar Documents

Publication Publication Date Title
JP4444998B2 (ja) 電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法
US6640301B1 (en) Third-party e-mail authentication service provider using checksum and unknown pad characters with removal of quotation indents
US7650383B2 (en) Electronic message system with federation of trusted senders
US8868916B2 (en) Self-contained electronic signature
US7644280B2 (en) Method and system for linking certificates to signed files
CN1767507B (zh) 用于确认入站消息的方法和系统
US20110231645A1 (en) System and method to validate and authenticate digital data
WO2013008778A1 (ja) 識別名管理方法およびシステム
US7966492B1 (en) System and method for allowing an e-mail message recipient to authenticate the message
JP2009503661A (ja) 正規受信者への安全なファイル配信のためのシステムおよび方法
CN101711472A (zh) 验证网页的真实性
JP6880055B2 (ja) メッセージ偽造防止実施方法及びデバイス
JP4727627B2 (ja) 電子メールの検証情報生成プログラム、及びその装置、ならびにその方法、電子メールの検証プログラム、及びその装置
TWI579795B (zh) 電子郵件投遞認證方法
US20050183142A1 (en) Identification of Trusted Relationships in Electronic Documents
JP2005223560A (ja) 署名検証ログを作成する検証結果記録方法とその装置
JP4608845B2 (ja) 署名記録の公開方法
CA2975787A1 (en) Apparatus, method and system to verify meta data of a person
US9391774B1 (en) Strauss greenmail system and method
US7730297B1 (en) Automated public key certificate transfer
TWM587314U (zh) 電子郵件真實性確認系統
JP2007288546A (ja) 署名つき名刺検証方法及びこれを利用した暗号通信方法
US11582044B2 (en) Systems and methods to timestamp and authenticate digital documents using a secure ledger
CN113051625B (zh) 一种基于区块链的数据存证方法及装置
JP4401892B2 (ja) メッセージ配送システム、メッセージ配送方法およびメッセージ配送プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090319

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090811

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090901

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091030

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100112

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100114

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130122

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130122

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140122

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees