(57)【特許請求の範囲】
【請求項１】
電子郵便付加サービスのために選択されたドメイン接尾語（.suffix ）が付け加えられたUSERID＠DOMAIN.suffix 形式の受信者メールアドレスの構文構造とその意味に対する一連の定義とからなり、前記ドメイン接尾語は、インターネットに公式登録されたドメイン名から選択された主ドメイン接尾語と、主ドメイン接尾語に代表される付加サービスを限定する補助ドメイン接尾語との２つの要素からなることを特徴とする、ドメイン接尾語電子郵便アドレスの表記体系と；
ドメインネームがDOMAIN.suffix 類型のインターネットホスト上に設けられることと、電子郵便受信者アドレスがUSERID＠DOMAIN.suffix 類型のメッセージを受信し、ドメイン接尾語.suffix に明記された主ドメイン接尾語と補助ドメイン接尾語の内容に応じて前記ドメイン接尾語電子郵便アドレスの表記体系で定義された付加サービス処理及び付加サービスのオプション事項を前記メッセージに適用し新しいメッセージを生成した後、元来の受信者アドレスUSERID＠DOMAINに再伝送することを特徴とする、リレーモード付加サービスメールサーバ；及び
DOMAIN.suffix 類型のドメイン名と、このドメイン部分に対して.suffix が指定する特定付加サービスを担当するリレーモードメールサーバホストのIPアドレスとの対応関係を示すメタドメインネームデータベース、及び付加サービスを提供するためのドメインネームサーバソフトウェアとからなる、メタドメインネームシステムと；
からなることを特徴とする電子郵便付加サービスシステム。
【請求項２】
前記ドメイン接尾語電子郵便アドレスの表記体系において、補助ドメイン接尾語が付加サービスのオプション事項を修飾するために、可変パラメーターを含む構文構造を有することを特徴とし、
前記メタドメインネームシステムが、可変パラメーターを含む構文構造を含むメタドメインネームデータベースとメタドメインネームサーバとからなることを特徴とする、請求項１記載の電子郵便付加サービスシステム。
【請求項３】
前記ドメイン接尾語電子郵便アドレスの表記体系が、.to と.cc を最上位ドメインとする同一名の一対の２次ドメインを主ドメイン接尾語として使用し、このうち、.to を含む主ドメイン接尾語は、送信者のみに受信確認通報を伝達するサービスを代表し、.cc を含む主ドメイン接尾語は、送信者及び受信者を除く他の受信者に受信確認通報を伝達するサービスを代表するものと定義し、
前記メタドメインネームシステムが、前記一対のドメイン接尾語にそれぞれ関係し、
前記電子郵便付加サービスシステムが、更に、HTMLタグをメッセージ本文に追加し、メールメッセージ別受信状況データベースを維持するメッセージ修正型リレーモードメールサーバを含み；そして、
前記電子郵便付加サービスシステムが、更に、受信者側メールクライアントよりの受信状況の報告に対するHTTP要求を受信し、受信確認通報を受領対象者に伝送するウェッブサーバを含むことを特徴とする、請求項１記載の電子郵便付加サービスシステム。
【請求項４】
更に、受信者に発行されたか、または発行される宝くじに対する情報を含んだHTMLタグをメッセージ本文に追加し、メールメッセージ別宝くじ当たり状況データベースを維持するメッセージ修正型リレーモードメールサーバを含むことを特徴とする、請求項１記載の電子郵便付加サービスシステム。
【請求項５】
更に、送信者が受信者アドレスの後ろに付け加えたドメイン接尾語により指定された絵葉書様式を選択し、メールメッセージへの絵葉書様式を適用することによりメールメッセージを修正するメッセージ修正型リレーモードメールサーバを含むことを特徴とする、請求項１記載の電子郵便付加サービスシステム。
【請求項６】
更に、送信者が受信者アドレスの後ろに付け加えたドメイン接尾語により指定された言語翻訳指示に基づき、メールメッセージを指定された言語に翻訳し書き直すことによりメールメッセージを修正するメッセージ修正型リレーモードメールサーバを含むことを特徴とする、請求項１記載の電子郵便付加サービスシステム。
【発明の詳細な説明】
（発明の属する技術分野）
本発明は、普遍的な電子郵便の基本機能と見做されない、メッセージの別の自然言語への翻訳、電子郵便の受信確認・通報サービス、宝くじメール発送サービス、またはクリスマス絵葉書伝送サービス等の電子郵便付加サービス（Email Add −On Service）を構築するためのシステムと方法に関する。
【０００１】
（従来技術）
本明細書において言及する電子郵便付加サービス（Email Add −On Service）を、インターネット電子郵便に係わるサービスのうち、普遍的な電子郵便の基本機能と見做されないサービスと定義する。かかるサービスとしては、メッセージの別の自然言語への翻訳、電子郵便の受信確認・通報サービス、宝くじメール発送サービス、またはクリスマス絵葉書伝送サービス等が挙げられる。電子郵便受信確認サービスは、IETFにより国際標準（RFC2298 ）が既に設けられているが、この標準を支援するメールクライアントソフトウェアを送信者及び受信者側のいずれも使用している時にのみ使用することができるため、その使用率が未だ低調な方である。宝くじメール伝送またはクリスマス絵葉書のメール伝送サービスのように、標準化の必要性がないか、若しくは標準化が不可能であって、メールクライアントソフトウェアやサーバソフトウェアに基本機能として搭載される見込みがないものもある。普通、クリスマス絵葉書の伝送の場合は、ウェッブ（WWW ）サービスにより提供される。
【０００２】
管理権限の分散を特徴としているインターネット上における特定の電子郵便付加サービスの全世界的な提供のために、送信者及び受信者側のメールサーバソフトウェア及びメールクライアントソフトウェアの取り替えを強いることができる権限は、いかなるサービス主体(provider)にも存在しない。
【０００３】
（発明の開示）
そこで、本発明は、インターネットを構成している普遍化された電子郵便インフラストラクチャとの並立が可能であり、普遍化された電子郵便インフラストラクチャとの相互連動を通じて送信者が指定した特定付加機能をインターネットの全体にわたってサービスすることができる、独立した電子郵便付加サービスシステムを構築することを目的とする。
【０００４】
既に多くの時間とお金が投資されており、その管理権限さえ分散されている電子郵便クライアントソフトウェア及びサーバソフトウェアの全世界的なインフラストラクチャの取り替えを必要としてはいけないという条件は、いずれかのサービス主体が独立して全世界的な同時サービスを提供するうえで、必要十分条件でもある。
【０００５】
この条件を満たし得るための方法として、本発明は、送信者側メールサーバと受信者側メールサーバとの間の中間伝送経路に挿入され、付加サービスに必要なメッセージの処理を遂行するリレーモードメールサーバ（relay-mode mail server）を使用する。
【０００６】
一般に、送信者がメールクライアントを使用して伝送したメッセージは、SMTP(Simple Mail Transfer Protocol) を通じて、メールクライアントの設置の際に指定した受信者側メール伝送サーバ（SMTPサーバ）内の伝送待機行列（queue ）に格納される。その後、この受信者側SMTPサーバは、メッセージ内に指定された受信者アドレスUSERID＠DOMAINのDOMAIN部分を基にし、メッセージをどのインターネットホストに伝送するかを決める（IETFのRFC822、RFC821参照）。
【０００７】
つまり、このDOMAIN部分は、付加サービス処理を遂行するリレーモードメールサーバが、既存のメール伝送経路の間に挿入され得る唯一の部分である。このとき、送信者が受信者メールアドレスのDOMAIN部分を、前記リレーモードメールサーバが設置されたインターネットホスト名(DOMAIN −NEW)に代替し、新しい受信者メールアドレスを使用すべきである。また、DOMAIN−NEW は、元来の受信者メールアドレスのDOMAIN部分をいずれかの方法にて区分可能な形態で含むことにより、付加サービス処理されたメッセージが、元来の受信者メールサーバに伝達（relay ）できる最小限の情報を維持しなければならない。
【０００８】
このために、本発明は、付加サービス及びそのオプションによってドメイン接尾語（domain Suffix 、以下、.suffix と略する）を定義する。本発明では、これを受信者メールアドレスのDOMAINの後ろに付け加え、DOMAIN部分をその前の部分にそのまま含んでいるDOMAIN.suffix を生成し、このDOMAIN.suffix をリレーモードメールサーバのインターネットホスト名とする方式を採択した。
【０００９】
このアイデアに基づき、電子郵便付加サービスシステムの体系的構築方法を、以下の最良の実施の形態に基づいて詳細に説明する。
【００１０】
本発明と類似する分野で既に登録されている国際特許ＷＯ９８１８２４９Ａ１を参照することができる。
【００１１】
本発明の好ましい実施形態のこれら、ならびに、他の特徴、見地、および利点は、以下の詳細な説明、添付の図面においてより完全に記載している。
【００１２】
（発明を行うためのベストモード）
本発明の電子郵便付加サービスシステムは、次の３つの要素からなる。
【００１３】
［要素１. ］
付加サービス別ドメイン接尾語が付け加えられたUSERID＠DOMAIN.suffix 形式のメールアドレスの構文構造とその意味に対する一連の定義で構成されるドメイン接尾語電子郵便アドレスの表記体系（domain suffix email address representation system ）。ドメイン接尾語電子郵便アドレスの表記体系は、ドメイン接尾語を付け加えることにより、付加サービスの種類を明示し、その処理を担当するサービスホストを指定する。
【００１４】
［要素２. ］
受信者アドレスがUSERID＠DOMAIN.suffix となっているメールメッセージを受信し、.suffix が指定する付加サービスの種類及びオプションにより、電子郵便メッセージを加工した後、元来の受信者アドレスUSERID＠DOMAINにその加工したメールメッセージを再伝送するメッセージ修正型（message modifying ）のリレーモード付加サービスメールサーバ（relay mode add-on service mail server ）。
【００１５】
［要素３. ］
前記DOMAIN.suffix を、DOMAINに対する付加サービスを担当するリレーモードメールサーバホストのインターネットIPアドレスに対応づけるメタドメインネームシステム（Meta domain name system ）。
【００１６】
次の内容は、前記３つの各発明要素に対する詳細な説明と共に、この汎用システムのサブシステム（Subsystem ）として具現可能な４つの特化されたインターネット付加サービスサブシステムのそれぞれに関する記述である。
【００１７】
［１．ドメイン接尾語電子郵便アドレスの表記体系］
［要素１. ］
本発明のアドレス表記体系は、受信者電子郵便アドレスの後ろにドメイン接尾語を付け加えることを特徴とする。この特徴は、付加サービスの種類の明示とその処理を担当するサービスホストの指定という２つの目標を同時に成し遂げることができるという点がその核心である。付加サービスの使用者の観点では、この表記法は、電子郵便付加サービスの使用法と同一のように認識される。
【００１８】
付加サービス別ドメイン接尾語は、常に主ドメイン接尾語（root domain suffix）と補助ドメイン接尾語（suplimentary domain suffix）部分からなる。主ドメイン接尾語は、必ずインターネット上における公式登録された１つの独立したドメインであるか、そのドメインの下位ドメイン(child domain)でなければならない。
【００１９】
理解を助けるために、メール受信確認付加サービスのための主ドメイン接尾語を.confirm.to とし、.addに始まる補助ドメイン接尾語部分を使用する実例を２つ挙げてみる。先ず、apple.com.add.startec.advertizement.confirm.toの場合、apple.com がDOMAIN部分で、add.startec.advertizement が補助ドメイン接尾語で、.confirm.to が主ドメイン接尾語である。次に、apple.com.confirm.toの場合には、補助ドメイン接尾語が空白文字列（null string ）値を有しているものと見做す。参考として、.confirm.to の.to ドメインは、トンガ王国（the kingdom of Tonga）の国家最上位ドメイン（country top-level domain）であって、.com、.netと同様に国際的に登録可能である。
【００２０】
補助ドメイン接尾語は、主ドメイン接尾語と元来のメールアドレスドメイン名との間に付いて、付加サービスの機能を修飾するか制限する。補助ドメイン接尾語が有し得る文字列の値の範囲は、付加サービス別に異なると定義することができる。可変的なパラメーター（variable parameter）を含む構文構造（syntax）を有する補助ドメイン接尾語の場合、無限個の文字列の値を有することができる。
【００２１】
microsoft.com.add.*.photo.post-card.to.IN A 202.30.244.18
［２．リレーモード付加サービスメールサーバ］
リレーモード付加サービスメールサーバは、受信者アドレスがUSERID＠DOMAIN.suffix となっているメールメッセージを受信し処理するサーバであって、その構成において、次の３つの特徴を有する。
【００２２】
一つ目に、上記サーバは、ドメインネームがDOMAIN.suffix 類型のインターネットホスト上に設けられる。
【００２３】
二つ目に、上記サーバは、送信者メールサーバから受信者メールサーバへのメールメッセージ伝送過程中に挿入され、メッセージを処理後、伝達（relay ）することにより、両メールサーバに代わって、付加サービスを適用する、つまりリレーモード（relay mode）である。
【００２４】
三つ目に、上記サーバは、受信者アドレスUSERID＠DOMAIN.suffix に明記された主ドメイン接尾語と補助ドメイン接尾語の内容を基に、該当付加サービスが必要とするメッセージ変形を加えるメッセージ修正型（message modifying ）メールサーバの特徴を有する。
【００２５】
［２. １. リレーモード付加サービスメールサーバ構造の長所］
一つ目の長所は、上記サーバが、既存の送受信者メールサーバの交替が不要という点である。送信者メールサーバ及び受信者メールサーバとの間の伝送経路に挿入され、送信者と受信者との両メールサーバの機能を自然に拡張させることができる。
【００２６】
二つ目の長所は、リレーモード付加サービスメールサーバは、送受信者メールDOMAINのメールサーバと運営及び管理において独立しているため、送受信者DOMAIN管理者側の協調なしに、付加サービス側の用意のみで独自的な全世界的な同時サービスの施行が可能であるということである。
【００２７】
三つ目の長所は、DOMAIN.suffix サーバを一次メール受信サーバと明示的に指定したのは送信者であるため、リレーモード付加サービスメールサーバは、DOMAINを担当する管理者よりいかなる干渉や法的制約なしに、DOMAIN内の使用者を受信者とする電子郵便付加サービスの提供が可能であるという点である。
【００２８】
四つ目の長所は、全てのDOMAINに対し、DOMAIN.suffix が１つのリレーサーバマシンのIPアドレスに対応づけられるようにメタドメインネームシステムを構成すると、１つのサーバでも全世界的に同時付加サービスを提供できるという点である。リレーモードメールサーバは、受信されたメッセージの受信者アドレスDOMAIN.suffix のDOMAINの範囲値に係わらず、.suffix に基づいて要求された処理を遂行した後、受信メールサーバに最終メッセージを伝達できるようにセットアップすることができる。更に、負荷分散次元または保安管理目的の次元で、ドメインの各階層単位に専担(resposible)リレーサーバの分枝式の段階的設置が可能である。
【００２９】
［２. ２. メッセージ付加サービスの処理過程］
送信者がUSERID＠DOMAINにメールを送る時の電子郵便の流れと、USERID＠DOMAIN.suffix にメールを送る時の電子郵便の流れとを比較して示す図面が、図１に示されており、その図面の各細部過程についての解説は、次の通りである。
【００３０】
先ず、送信者がどの受信者アドレスを指定してもそのメールメッセージは、一旦は、送信者側メールサーバの待機行列に追加され、実際の外部への伝送を待つ（図１の過程１）。
【００３１】
そのメッセージが処理される順番になると、メールサーバは、DOMAIN.suffix のIPアドレスを見出すために、.suffix ドメインの主ドメインネームサーバ（ns.suffix と記す；メタドメインネームサーバ）に質疑を送る（図１の過程２）。
【００３２】
DOMAIN.suffix に対応するIPアドレスにSMTPプロトコルを使用してメッセージを伝達する（図１の過程３）。このメッセージを受けたDOMAIN.suffix サーバは、付加サービスの特性に応じてメッセージの内容を修正または追加し、新しいメッセージを生成する（図１の過程４）。
【００３３】
受信者電子郵便アドレスUSERID＠DOMAIN.suffix から元来の受信者アドレスUSERID＠DOMAINとドメイン接尾語である.suffix 部分とを一旦分離した後、ドメイン接尾語は、再度主ドメイン接尾語部分と補助ドメイン接尾語部分とに分けられ、送信者が意図していた付加サービスの類型とその内容を決定するのに使用される。
【００３４】
付加サービスをメッセージに適用して修正された新しいメッセージを生成しつつ、付加サービスを必要とすれば、各メッセージ別に状態情報データレコードをサーバ内のデータベースに書き込む。このために、各メッセージ毎に固有一連番号(serial number) を生成してメッセージIDを与える。
【００３５】
元来の受信者電子郵便アドレスUSERID＠DOMAINを最終受信者として新しいメッセージを伝送する（図１の過程５）。
【００３６】
受信者は、受信者側電子郵便サーバに格納された自分のメールメールクライアントを使用して自分のパーソナルコンピュータ（ＰＣ）に読み込む（図１の過程６）。
【００３７】
［２. ３. メッセージ修正型サーバのメッセージデータベース］
付加サービスに係わるメールメッセージ別状態情報は、DOMAIN.suffix ホスト内に格納され得るが、これは、単にサービス処理の記録残しを目的とするか、または受信者メールクライアントとの相互作用を通じて、付加サービスの特定目的を達成するためである。
【００３８】
受信者がメールを受信した後、インターネットを介するDOMAIN.suffix サーバとの一連の相互作用を通じてはじめて、付加サービスが実現される相互作用型付加サービス（interactive add-on service）類型があるが、この場合には、状態情報データベースレコードのキーとなるメッセージIDについての情報が、いかなる形式であれ、受信者に最終伝達されたメール本文またはメールヘッダに、付加サービスの目的に符合する方式にて付記されなければならない。
【００３９】
［３．メタドメインネームシステム(Meta Domain Name System) の詳細な説明］
［３. １. 背景説明］
ドメインネーム（domain name ）とは、インターネットの階層的な名前空間（hierarchical name space ）内におけるホストやネットワーク名（identifier）で構成された各階層の固有名前を最上位階層から最下位階層まで.(dot)で区分し、右側から左側方向に順番に表記した名前である。即ち、www.microsoft.com 、netscape.net、www.nic.go.kr 等がその例である。ここで、.com、.net、.kr 等は、最上位ドメイン（top-level domain；以下、TLD と略する）と称し、microsoft.com 、netscape.net、go.kr は、次上位ドメイン（second-level domain ）と称する。
【００４０】
ドメインネームシステム（Domain Name System、以下、DNS と略する）は、つまり、これらのドメインネームとそのIPアドレスとを対応づけるための、分散された全世界的なデータベースシステムである。DNS は、インターネットドメインネームとIPアドレスとの間の対応関係データベース（A-typeレコードで構成）及びインターネット電子郵便伝送経路データベース（MX type レコードで構成）とからなっている。DNS は、全てのインターネットtcp/ip通信を含み、電子郵便の送信者側から受信者側への電子郵便伝送の流れと経路を決定する（関連文書 IETF のRFC1034 、RFC1035 ）。
【００４１】
ドメインネームの各階層別に主ドメインネームサーバ（primary domain name server）が指定され、サーバに対する各ドメイン及びその下位ドメインに対するIPアドレスの対応づけを担当している。例えば、www.cs.uiuc.edu の場合、最上位ドメインの.eduは、ns.internic.net に指定されているが、uiuc.eauは、ns.uiuc.edu （イリノイ大学）に主ドメインネームサーバと指定されている。このような役割分担は、ns.internic.net のドメインネームデータベースにuiuc.eduに対する主ドメインネームサーバ管理権限をns.uiuc.edu に委ねる（delegation）内容（NS type レコードという）を加えることにより行われる。
【００４２】
cs.uiuc.edu とwww.cs.uiuc.edu がそれぞれの下位ドメイン(sub-domain)に対する実の主ドメインネームサーバ権限を有するか否かは、ns.uiuc.edu 管理者が決定する。
【００４３】
ここで、本論に戻り、DOMAIN.suffix も同じくsuffixという特定ドメインの下位ドメイン名であるため、.suffix の主ドメインネームサーバの構築が必要である。どころが、ドメインネームの生成と削除がダイナミックに起こるインターネット上において、可能な全てのDOMAINに対し、DOMAIN.suffix に対するデータベースレコードを作るということは、インターネットの分散管理の特性とその規模からして不可能である。とりわけ、その可変パラメーターを含む補助ドメイン接尾語を含む場合においては特に不可能である。
【００４４】
本発明のメタドメインネームシステム（Meta Domain Name System ）は、つまり、このような特徴を有しているDOMAIN.suffix 類型のドメインネーム管理のために特別なデータベース（これを、メタドメインデータベースと称する）有しているドメインネームシステムを指す。このシステムは、主ドメイン接尾語の独立ドメイン名を管轄する主ドメインネームサーバ（primary domain name server）ホスト上に先ず構築されるべきである。このメタドメインネームデータベースをサービスするサーバソフトウェアをメタドメインネームサーバと称する。
【００４５】
［３. ２. メタドメインネームシステムの特徴］
メタドメインネームサーバは、外部とのDNS プロトコル相互作用において一般のドメインネームサーバと同様に動作するが（関連文書 IETF のRFC1034 、RFC1035 ）、そのデータベースの構成において、次のような３つの特徴を有している。
【００４６】
一つ目に、メタドメインネームサーバが管理する全てのドメインネームデータベースのリソースレコード（Resource Record ）は、基本的にワイルドカード属性（Wildcard attribute）を有する。
【００４７】
二つ目に、リソースレコードのうち、より一層明示的（specific）であるものが、IPアドレス質疑結果選定過程で優先順位を有する。
【００４８】
三つ目に、パラメーター化された（parameterized ）補助ドメイン接尾語を使用する付加サービスの場合、可変パラメーター（parameter ）表現を含むリソースレコードの解釈をドメインネームデータベースが支援する。
【００４９】
メタドメインネームサーバの核心は、つまり、このデータベースの構成方法にある。ドメインネームサーバソフトウェアは、単にこのデータベースをサービスするための手段であって、以下、広く公知され使用されている最新のネームサーバソフトウェアが、このような類型のデータベースを直接的に、若しくは間接的に支援する。
【００５０】
［３. ３. 各特徴別解説］
第１の特徴の意味を例示するために例を挙げると、主ドメイン接尾語が.confirm.to の場合、ドメインネームデータベースリソースレコード（resource record ）は、apple.com.confirm.toに対して次のような形態を有するとする（実際は、データベースレコード入力内容がこれと同一である必要はなく、これを使用するドメインネームサーバソフトウェアにより異なる）。
【００５１】
apple.com.confirm.to.IN A 202.30.244.15
この際、apple.com.confirm.toレコードがワイルドカード(wildcard)属性を有するということは、apple.com 下位ドメインの全ては、常にapple.com.confirm.toのIPアドレスと同一の値が対応づけられるということである。即ち、UNIXシェルコマンドのワイルドカード文字 *(asterisk)が前に省略されているように（*.apple.com.confirm.to）見做す方式である。従って、host1.marketing.apple.com.confirm.toとhost2.korea.international.apple.com.confirm.toは、いずれも同一の*.apple.com.confirm.toに符合（match ）できるため、apple.com.confirm.toのように202.30.244.15 のIPアドレス値を対応づけられる。
【００５２】
第２の特徴の意味を例示するために、usa.apple.com.confirm.toとその下位ドメインのみのための別途のリレーモードメールサーバが必要となり、リソースレコードを分離しなければならないと仮定する。この仮定に備え、次のようにリソースレコードを明示することができるようにする。
【００５３】
usa.apple.com.confirm.to.IN A 202.30.244.16
apple.com.confirm.to.IN A 202.30.244.15
この際、usa.apple.com が、apple.com のことより優先順位をもたなければ意味がないはずである。両方のレコードとも前に* が省略されているものと見做されるため、形式上*.usa.apple.com が*.apple.com に含まれているものと見做され得るという曖昧さ(ambiguity) が存在する。これを解決するために、任意ドメインネーム質疑に対し、両リソースレコードのうち、どれを優先して適用するかを明らかにすべきである。
【００５４】
この際、usa.apple.com.confirm.toが、apple.com.confirm.toよりは一層明示的（specific）であると定義し、この一層明示的なリソースレコードによるIPアドレス質疑結果が優先順位をもつように、メタドメインネームサーバを構築する。
【００５５】
一方、付加サービスの初期に、いずれのDOMAINに対する付加サービスをただ１つのリレーメールサーバホストで処理するとすれば、次の１つのリソースレコードでも十分なはずである。
【００５６】
confirm.to.IN A 202.30.244.15
第３の特徴を例示するために、パラメーター化された（parameterized ）補助ドメイン接尾語を使用するクリスマス郵便絵葉書のメール送り付加サービス(Christimas picture post-card sending add-on service) を仮定してみる。主ドメイン接尾語は、.post-card.to とし、補助ドメイン接尾語のBNF 構文は、add.* （midi｜photo ）とする。.*部分は、実際の文字列‘*'でなく、送信者が任意に単語を選択し、代替できる可変パラメーター（parameter ）を表現したものと約束しておく。
【００５７】
１)bill ＠microsoft.com.post-card.to、
２)bill ＠microsoft.com.add.yosemite.park.photo.post-card.to、
３)bill ＠microsoft.com.add.christmas.carol.song.midi.post-card.to
３つの受信者メールアドレスに対し、例１）のように、送信者が補助ドメイン接尾語を空白文字列にすると（即ち、補助ドメイン接尾語を指定しなければ）、サーバが任意に指定した内容が選択され、葉書として送られ得るはずである。例２）では、yosemite.park.photo が可変パラメーターとなり、例３）では、christmas.carol.song.midi が可変パラメーターとなる。
【００５８】
結局、メタドメインネームデータベースは、パラメーター化された補助ドメイン接尾語を含むリソースレコードを支援すべきであるという点は、次のようなリソースレコードをメタドメインネームデータベースで指定できなければならないということを意味する。
【００５９】
microsoft.com.add.*.midi.post-card.to.IN A 202.30.244.15
microsoft.com.add.*.girl.photo.post-card.to.IN A 202.30.244.16
microsoft.com.add.*.park.photo.post-card.to.IN A 202.30.244.17
［４. 電子郵便受信確認サービスシステム］
［４. １. 背景説明］
電子郵便受信確認サービス（Mail Read Confirmation Notification Service ）は、電子郵便を受信者側が受信し読んだ事実を送信者側に返信してくれるサービスであって、その方法と手続が、IETFにより標準（RFC2298 、http://www.inc.org/rfc2298）化されている。ところが標準では、送受信者側の電子郵便サーバ及びクライアントソフトウェアの取り替えを必要とし、電子郵便受信確認サービスの拡散が遅延されており、全世界において例外なく同時的にサービスするには無理がある。
【００６０】
本発明のインターネット電子郵便付加サービスシステムの１つの特化された発明で構築されるこの電子郵便受信確認サービスは、前記のインターネットの標準と関係なく、送信者が、ただ受信者の電子郵便アドレスの後ろに.confirm.to.または.confirm.cc のドメイン接尾語を付けて送信することにより、受信確認付加サービスを提供できるようにした点にその特徴がある。
【００６１】
［４. ２. 電子郵便受信確認サービスシステムの構成］
過程１）本発明の［要素１. ］の付加サービスメタメールアドレスの表記体系に基づき、電子郵便受信確認サービスのための主ドメイン接尾語として.to と.cc を最上位ドメインとする同一名の一対の２次ドメインを選択し、公式インターネット２次ドメインとして登録する。
【００６２】
例えば、‘confirm.to' と‘confirm.cc' というインターネットドメイン名を確保したならば、各ドメイン接尾語に対する付加サービスの意味を次のように定める。.confirm.to ドメイン接尾語をメールアドレスの後ろに付けて送信すると、電子郵便受信の際、送信者にのみ受信確認通報(mail read confirmation notification) が伝達される。受信者が少なくとも２人の時には、ドメイン接尾語.confirm.cc を付けることができるが、メール受信の際、送信者のみならず、他の受信者にも（もし、いれば）受信通報事実が伝達されるようにする。.confirm. の代わりに、recepit 、notice等の別のドメインも確保可能であれば、代替することができる。
【００６３】
toは、電子郵便の送信者を指す標準化されたメールヘッダー名であるため、使用者に認識され易い。cc（carbon copy 、写しという意味）も同じく標準化されたメールヘッダー名であって、送信者に送るメール受信確認通報の写しを他の受信者に送るという意味を客観的(objectively) に伝達することができる。.to は、トンガ王国（the kingdom of Tonga）の国家最上位ドメイン（country top-level domain）であり、.cc は、コッカスキリング群島（The island of Cocus Keeling ）の国家最上位ドメインである。
【００６４】
過程２）本発明の［要素３. ］のメタドメインネームシステムに基づき、前記２つのドメイン名をそれぞれ主ドメイン接尾語とする２つのメタドメインネームデータベースを構築する。DOMAIN.confirm.to とDOMAIN.confirm.cc 類型のドメインネームに対してサービスを担当するメールホストマシンを確保した後、そのIPアドレスを登録する。
【００６５】
過程３）本発明の［要素２. ］のリレーモード付加サービスメールサーバに基づき、メール受信確認付加サービスを具現するメッセージ修正型電子郵便リレーサーバシステムを構築する。電子郵便受信確認サービスは、受信者メールクライアントとリレーサーバとの相互作用が必要である。このために、メッセージ処理時、リレーサーバにメッセージ別受信状態データベースレコードを共に生成管理する。また、修正されたメッセージには、自動的に受信状況報告のためのhttp(Hypertext Transfer Protocol) 要求がリレーサーバに伝達されるように、適切なHTMLタグが本文に挿入される。このサーバシステムを過程２）でデータベースに登録された各リレーメールサーバホストマシンに設ける。
【００６６】
過程４）受信者メールクライアントとリレーサーバとの相互作用を通じて、電子郵便受信確認サービスが具現できるように、リレーサーバ内にウェッブサーバを設ける。ウェッブサーバは、受信者のメールクライアントから送られる受信状況報告のhttp要求を受け、メッセージ別受信状況データベースに要求を反映し、受信確認通報を受領対象者に伝送するようにする。
【００６７】
送信者が.confirm.to ドメイン接尾語を後ろに付けて送信してから、最終受信者に付加サービスで修正された電子郵便が到着するまでの過程において、メタドメインネームサーバと付加サービスメールサーバ及びウェッブサーバとが如何に相互作用するかを例示するフローチャートが図２に示されている。
【００６８】
図３は、受信者がオンライン状態で受けたメールを読む時、図２の過程４で追加されたHTMLタグにより、リレーサーバ内のウェッブサーバとの相互作用を通じて、受信確認通報が送信者に送られる過程の流れを示す図面である。
【００６９】
この際、受信者メールクライアントは、インターネットにオンライン接続されている状態で、且つHTMLタグを画面に表示することができる普遍的な機能を有しているものと仮定する（例えば、Microsoft 社のoutlook express 、Netscape社のNetscape Messenger、EudoraのEudora Pro等）。
【００７０】
［４. ３. 付加サービスのためのメッセージ修正過程の詳細な説明］
各電子郵便メッセージ毎に固有一連番号を与え、この一連番号をキーとして、受信状況データを格納することができる受信状態データベースレコードを生成する。メッセージ本文のHTMLバージョンに、前記与えられた固有一連番号と受信者電子郵便アドレス等の情報を含蓄しているURL(Uniform Resource Locator) を含んでいるHTML文書を挿入する。
【００７１】
最終受信者が同メッセージを受信し、画面上にそのメッセージをディスプレイする時、挿入されたHTMLタグにより自動的にまたは受信者の認知された行動により、そのURLがリレーサーバのウェッブサーバとHTTPプロトコルによる相互作用を起こし、適切なHTMLタグを選択する。
【００７２】
例えば、＜img src=http://microsoft.com.confirm.to/read/MESSAGE(ID/bill＠microsoft.com width=１ height=１＞のようなタグを本文の後ろに挿入することができる。このタグは、横と縦の大きさが、それぞれ１ドットのイメージタグであって、受信者の目に見え難い。このタグは、http要求が指定されたリレーサーバ内のウェッブサーバに受信状況情報を含むURL 要求を送り、受信状況情報を更新可能にすることができる。
【００７３】
HTMLタグの本文追加のためには、メールメッセージ本文がHTML形式でなければならない。このため、本文が一般テキスト（MIME(Multi-purpose Internet Mail Extension) 類型がtext/plain形式）のみになっている場合、メッセージ本文をHTML形式に自動変換させた後、HTMLタグを追加する。
【００７４】
ウェッブサーバは、受信事実を該当データベースレコードに反映し、受信確認通報メッセージを生成し、レコード内に書き込まれている元来の送信者アドレスに受信確認通報メッセージ伝送する。受信者アドレスに.confirm.cc がドメイン接尾語として付いていたら、ウェッブサーバは、送信者のみならず、電子郵便メッセージに明示された他の受信者にも確認メッセージを伝送する。
【００７５】
［５．宝くじメール送信付加サービスシステム］
本発明のインターネット電子郵便付加サービスシステムの１つの特化された発明で構築されるこの宝くじメール送信付加サービスシステムの構築過程は、次の通りである。
【００７６】
過程１）本発明の［要素１. ］の付加サービスメールアドレスの表記体系に基づき、宝くじメール送信付加サービスのための主ドメイン接尾語としてインターネットに公式的に登録されたインターネット２次ドメインを選択し登録する。
【００７７】
このために、‘loto.to'というインターネットドメイン名を確保したとすれば、付加サービスの意味を、次の通りに定める。.loto.toドメイン接尾語をメールアドレスの後ろに付けて送信すると、受信者のために発給されたオンライン宝くじがメッセージに付加されて伝達されるようになる。.loto.toの代わりに、別のドメインも確保できれば代替することができる。補助ドメイン接尾語を指定することもできる。この際、補助ドメインの構文形式をadd.*.とし、* （asterisk）には、送信者に公知の宝くじの種類に対応する記号を入れるようにする。例えば、apple.com.add.motorola.loto.toのようなドメインが可能である。
【００７８】
過程２）本発明の［要素３. ］のメタドメインネームシステムに基づき、.loto.toを主ドメイン接尾語とし、前記補助ドメイン接尾語構文を支援するメタドメインネームデータベースを構築する。DOMAIN.loto.toに対してサービスを担当するメールホストマシンを確保した後、そのIPアドレスを登録する。
【００７９】
過程３）本発明の［要素２. ］のリレーモード付加サービスメールサーバに基づき、宝くじ送信付加サービスを具現するメッセージ修正型電子郵便リレーサーバシステムを構築する。宝くじが当たった受信者に対するメール受信状態データベース管理が必要なサービスであるため、リレーサーバにメッセージ別宝くじ当たり状態データベースレコードを共に生成管理する。また、受信者がメールを開いてみる時、受信者に発給されたオンライン宝くじに対する情報がわかるように、修正されたメッセージにHTMLタグが挿入される。このサーバシステムを過程２）でデータベースに登録された各リレーメールサーバホストマシンに設ける。
【００８０】
［６. 絵葉書送信付加サービスシステム］
本発明のインターネット電子郵便付加サービスシステムの１つの特化された発明で構築されるこの絵葉書送信付加サービスシステムの構築過程は、次の通りである。
【００８１】
過程１）本発明の［要素１. ］の付加サービスメールアドレスの表記体系に基づき、インターネットに公式的に登録されたインターネット２次ドメインを選択し登録する。
【００８２】
このために、‘post-card.to' というインターネットドメイン名を確保したとすれば、付加サービスの意味を、次の通りに定める。.post-card.to ドメイン接尾語をメールアドレスの後ろに付けて送信すると、絵葉書が背景を装飾したHTML類型のメッセージが伝達される。.post-card.to.の代わりに別のドメインも確保できれば、代替することができる。補助ドメイン接尾語を指定することもできる。この際、補助ドメイン接尾語の構文形式をadd.*.とし、* （asterisk）には、送信者に公知の絵葉書の種類に対応する記号を入れる。例えば、apple.com.add.yosemite-park.post-card.toのような補助ドメイン接尾語が付いたアドレスが可能である。
【００８３】
過程２）本発明の［要素３. ］のメタドメインネームシステムに基づき、.post-card.to を主ドメイン接尾語とし、前記補助ドメイン接尾語構文を支援するメタドメインネームデータベースを構築する。DOMAIN.post-card.to に対するサービスを担当するメールホストマシンを確保した後、そのIPアドレスを登録する。
【００８４】
過程３）本発明の［要素２. ］のリレーモード付加サービスメールサーバに基づき、絵葉書送信付加サービスを具現するメッセージ修正型電子郵便リレーサーバシステムを構築する。リレーサーバは、絵葉書の記号とその内容を収容したデータベースを有していなければならない。また、補助ドメイン接尾語に明示された絵葉書の種類を分析し、修正されたメッセージの本文背景に絵葉書が入れるように、HTMLタグを挿入する。このサーバシステムを過程２）でデータベースに登録された各リレーメールサーバホストマシンに設ける。
【００８５】
［７. メール翻訳送信付加サービスシステム］
本発明のインターネット電子郵便付加サービスシステムの１つの特化された発明で構築されるこのメール翻訳送信付加サービスの構築過程は、次の通りである。
【００８６】
過程１）本発明の［要素１. ］の付加サービスメールアドレスの表記体系に基づき、インターネットに公式的に登録されたインターネット２次ドメインを選択し登録する。
【００８７】
このために、‘interpret.to' というインターネットドメイン名を確保したとすれば、付加サービスの意味を、次の通りに定める。.interpret.to ドメイン接尾語と.from.LANG1.to.LANG2のような補助ドメイン接尾語を共にメールアドレスの後ろに付けて送信すると、指定した言語への翻訳作業を経た新しいメッセージが受信者に送られるサービスである。.interpret.to.の代わりに別のドメイン接尾語も確保できれば、代替することができる。補助ドメイン接尾語の構文形式は、from.*.to.* とし、* （asterisk）には、送信者に公知の翻訳に対応する言語に対する記号を入れる。例えば、apple.com.from.english.to.french.interpret.to のような補助ドメイン接尾語が付いたアドレスが可能である。
【００８８】
過程２）本発明の［要素３. ］のメタドメインネームシステムに基づき、interpret.toをドメイン接尾語とし、前記補助ドメイン接尾語構文を支援するメタドメインネームデータベースを構築する。DOMAIN.interpret.to に対してサービスを担当するメールホストマシンを確保した後、そのIPアドレスを登録する。
【００８９】
過程３）本発明の［要素２. ］のリレーモード付加サービスメールサーバに基づき、メール翻訳送信付加サービスを具現するメッセージ修正型電子郵便リレーサーバシステムを構築する。このサーバシステムを過程２）でデータベースに登録された各リレーメールサーバホストマシンに設ける。
【００９０】
本発明のインターネット電子郵便付加サービスシステムを使用すると、送信者は、付加サービスを使用するのに、単に受信者電子郵便アドレスの後ろに付加サービスに関連するドメイン接尾語を付ける。付加サービス主体側の少なくとも１つのサービスホストの使用により、ドメイン接尾語に指定された付加サービスが自動遂行される。
【００９１】
従って、送信者側電子郵便サーバ及びクライアントソフトウェアの取り替えを必要とせず、サービス主体側の準備のみで全世界的な同時付加サービスが可能となり、電子郵便付加サービスの新規登場と共に、早期に全世界に新規付加サービスを拡散させるのに有利である。これは、電子郵便サービスの相互間の競争及び革新（innovation）を誘導するはずである。
【図面の簡単な説明】
【図１】  送信者がUSERID＠DOMAINに手紙を送る時の電子郵便の流れと、USERID＠DOMAIN.suffix に送る時の電子郵便の流れとを示す図である。
【図２】  電子郵便受信確認サービスシステムの構成要素であるメタドメインネームサーバ、付加サービスメールサーバ及びウェッブサーバ間の相互作用を示すフローチャートである。
【図３】  電子郵便受信確認サービスシステムにおけるメッセージ受信を確認する過程のフローチャートである。
【図１】
0003766966.tif 000002
【図２】
0003766966.tif 000003
【図３】
0003766966.tif 000004