JP2000099417A

JP2000099417A - メール配信装置及びメール配信方法

Info

Publication number: JP2000099417A
Application number: JP10266099A
Authority: JP
Inventors: Toru Watanabe; 亨渡辺
Original assignee: Casio Computer Co Ltd
Current assignee: Casio Computer Co Ltd
Priority date: 1998-09-21
Filing date: 1998-09-21
Publication date: 2000-04-07

Abstract

(57)【要約】【課題】テキスト形式のメールに書式情報等を付加し
て高機能ＭＵＡに配信でき、以って高機能ＭＵＡの表示
能力を充分に発揮させる。【解決手段】着信メール本文に書式情報を付加し、及
び／又は、着信メール本文の背景にイメージ情報を付加
して、要求元のクライアントコンピュータへ配信する。
例えば、メーリングリストのようなテキスト形式のメー
ルであっても、所要の書式情報や背景等を付加して配信
することができる。したがって、受信側のクライアント
コンピュータに高機能ＭＵＡが搭載されていた場合に、
その表示能力を充分に発揮させることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、メール配信装置及
びメール配信方法に関し、詳しくは、ＯＳＩ（開放型シ
ステム間相互接続）基本参照モデルのネットワーク層に
対応したＩＰ（Internet Protocol）プロトコルの一つ
であるメール配信用プロトコル（ＰＯＰ３またはＩＭＡ
Ｐ４）を使用してメールクライアントに電子メールを配
信するメール配信装置及びメール配信方法に関する。な
お、ＰＯＰ３はPost Office Protocol ver.３の略、Ｉ
ＭＡＰ４はInternet Massage Access Protocol ver.４
の略である。

【０００２】

【従来の技術】米国国防総省高等研究企画局（ＤＡＲＰ
Ａ：Defense Advanced Research Project Agency）によ
って構築された広域パケット通信網（ＡＲＰＡＮＥＴ：
Advanced Research Project Agency Network）の目的
は、コンピュータを１個所で集中管理せずに、各地で分
散管理することによってリスクの分散を図るというもの
であり、研究の狙いはもっぱら軍事利用にあったが、そ
の優れた利点（コンピュータのアーキテクチャに左右さ
れることなくネットワーク上の全コンピュータを相互に
接続できる）は、軍事目的以外の様々なネットワークの
構築を自然発生的に促し、当然の成り行きとしてそれら
が相互につなげられていった結果、いわゆる「インター
ネット」と呼ばれる地球的規模の大規模ネットワークの
出現に至っている。

【０００３】インターネットによって実現された有益な
技術の第一は、ＷＷＷ（Word WideWeb）によるシームレ
スな情報閲覧システムであり、第二は電子メール（いわ
ゆるインターネットメール、一般にＥ−ｍａｉｌ）であ
るが、とりわけインターネットメールは、特定のネット
ワークＯＳに依存する旧来型の電子メールに比べて遥か
に普遍性があり、メールアカウントさえ持っていれば如
何なる相手とも情報の伝達が可能である点から、もはや
社会生活上、欠くことのできない意思疎通手段の一つに
位置づけられている。なお、上記のとおり、電子メール
はインターネットメールと旧来型の電子メールの二種類
あるが、以下では特に断りのない限り、電子メールとイ
ンターネットメールを同義語として取り扱うものとす
る。

【０００４】電子メールシステムは、図１０に示すよう
に、ネットワーク１（厳密にはＴＣＰ／ＩＰベースのネ
ットワーク；代表的にはインターネット）、メール送信
サーバ（ＳＭＴＰサーバともいう）２、メール受信サー
バ（ＰＯＰ３サーバともいう）３及びクライアントコン
ピュータ４〜６（図では３台であるが、この台数は一例
である）で構成されており、ＳＭＴＰサーバとＰＯＰ３
サーバの機能はＭＴＡ（Mail Transport Agent）と呼ば
れるソフトで、また、メールクライアントの機能はＭＵ
Ａ（Mail User Agent）と呼ばれるソフトで提供されて
いる。

【０００５】電子メールの送信から受信までの流れを概
説すると、あるクライアントコンピュータ４から送信さ
れた電子メールは、発信者のメールアカウント、例えば
“ａａａ＠ｂｂｂ．ｃｏ．ｊｐ"に対応したドメイン
“ｂｂｂ．ｃｏ．ｊｐ"を持つＳＭＴＰサーバ２に届け
られ、そのＳＭＴＰサーバ２よってネットワーク１上に
再送された後、適切なルーティングを経て最終的に、受
信者のメールアカウント、例えば“ｓａｔｏ＠ｃａｓｉ
ｏ．ｃｏ．ｊｐ"に対応したドメイン“ｃａｓｉｏ．ｃ
ｏ．ｊｐ"を持つＰＯＰ３サーバ３のメールボックス
（注１）に届けられる。注１：メールボックスとは、ＰＯＰ３サーバ３の大規模
記憶媒体に設けられた、アカウント“ｓａｔｏ＠ｃａｓ
ｉｏ．ｃｏ．ｊｐ"専用のメール記憶領域であり、一般
郵便における私書箱に相当するものである。

【０００６】メールボックス内の受信メールは、そのメ
ールのアカウント“ｓａｔｏ＠ｃａｓｉｏ．ｃｏ．ｊ
ｐ"を持つユーザのＰＯＰ３サーバ３への正当なログイ
ンによってメールボックスからクライアントコンピュー
タ５（当該ユーザが操作しているクライアントコンピュ
ータ）にダウンロードされた後、メールボックスから削
除される。なお、削除せずにＰＯＰ３サーバ３に残して
おくことも可能であるが、ＰＯＰ３サーバ３の記憶容量
の圧迫を避けるために、常に削除するのが電子メール利
用のマナーである。

【０００７】図１１は、クライアントコンピュータとＰ
ＯＰ３サーバの間でやり取りされるＰＯＰ３プロトコル
のタイムラインである。この例では、アカウント“ｓａ
ｔｏ＠ｃａｓｉｏ．ｃｏ．ｊｐ"のユーザがドメイン
“ｃａｓｉｏ．ｃｏ．ｊｐ"のＰＯＰ３サーバにアクセ
スし、自分専用のメールボックスから１番目の電子メー
ルをダウンロードするとともに、それを削除するまでの
一連の流れが示されている。

【０００８】図１１において、まず、サーバのＰＯＰ
３ポート（ＲＦＣ１７００の定義によれば１１０番ポー
ト）にＰＰＰ（Point-to-Point Protocol）接続してク
ライアントコンピュータとＰＯＰ３サーバ間のセッショ
ンを確立した後、ＰＯＰ３プロトコルの “ＵＳＥＲ
ｓａｔｏ" コマンドと、ＰＯＰ３プロトコルの “Ｐ
ＡＳＳａｂｃｄｅ" コマンドを発行する。なお“ＵＳ
ＥＲ"及び“ＰＡＳＳ"はコマンド名、“ｓａｔｏ"は
“ｓａｔｏ＠ｃａｓｉｏ．ｃｏ．ｊｐ"の登録ユーザ
名、“ａｂｃｄｅ"は同登録パスワードである。

【０００９】次に、ＰＯＰ３サーバは、これらユーザ名
とパスワードに基づいて認証を行い、正当なアカウント
であると評価した場合に、そのアカウントのメールボッ
クスを開いて受信メール数とトータルのメールサイズを
調べ、その情報をクライアントコンピュータに通知す
る。なお、図示の通知メッセージは、“＋ＯＫｓａｔ
ｏ‘ｓｍａｉｌｂｏｘｈａｓ２ｍｅｓｓａｇｅ
（Ｓ）（３２０ｏｃｔｅｔｓ）"であり、その意味
は、「ユーザ名“ｓａｔｏ"のメールボックスに２通の
電子メールが届いており、そのトータルサイズは３２０
オクテット（７ビット×３２０バイト）である」という
ものである。

【００１０】クライアントコンピュータは、この通知
メッセージの受信メール数が１以上である場合に、ＰＯ
Ｐ３プロトコルの“ＬＩＳＴ"コマンドを発行し、こ
のコマンドに応答してＰＯＰ３サーバから返送された各
メールごとのサイズリストの先頭番号（１番）を引数ｎ
にセットしてＰＯＰ３プロトコルの“ＲＥＴＲｎ"コマ
ンドを発行する。ＰＯＰ３サーバは、“ＲＥＴＲｎ"コ
マンドに応答してリスト番号ｎのメールヘッダとメッセ
ージボディ（以下「メール実体」という）を配信し、
クライアントコンピュータは、メール実体を受け取る
（ダウンロードする）と、ＰＯＰ３プロトコルの“ＤＥ
ＬＥｎ"コマンドを発行してｎ番目のメールの削除を要
求し、“ＱＵＩＴ"コマンドを発行してセッションを
終了する。

【００１１】図１２は、メール実体の具体例を含むメー
ル配信時のデータリストである。リストにおいて、Ｌ１
〜Ｌ２５は行番号、（Ｓ）はクライアントコンピュータ
から送出されたデータ、（Ｃ）はＰＯＰ３サーバからの
応答データを示す。メールヘッダはＬ１２からＬ１４で
あり、その後に改行コードだけの空白行を１行設けてメ
ッセージボディ（Ｌ１６〜Ｌ２０）が続き、ピリオ
ド（．）だけのダミー行（Ｌ２１）で終わっている。

【００１２】ところで、図示のメッセージボディは半角
のアルファベット（１バイト文字）だけで構成されてい
るため、そのまま意味が通じるが、日本語のような２バ
イト文字やバイナリデータが含まれている場合は意味不
明な記号の羅列になり、判読不可能になる。これは、イ
ンターネットメールの発達環境（英語圏の１バイト文字
環境）によるやむを得ない制限であった。しかし、言語
の垣根を越えてワールドワイドで不特定多数のユーザと
情報をやり取りするという電子メールの特質を考えると
不都合であるから、１９９８年６月のＲＦＣ１４６８の
定義によって、日本語などの２バイト文字やバイナリデ
ータが含まれる場合は、ＪＩＳ漢字コード（iso-2022-j
p）を７ビットで送り、それをクライアント側でデコー
ド（復号）処理して元どおりに再生することが策定され
た。すなわち、ＲＦＣ１４６８では、メールヘッダに
“Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダ"と“Ｃｏｎｔｅｎ
ｔ−Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇヘッダ“を付
加して受信側で使用すべきデコード方式の指定を行う取
り決めになった。

【００１３】例えば、テキスト文書をＪＩＳ漢字コード
（iso-2022-jp）の７ビットで送るときは、 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit を付加し、または、ＨＴＭＬ（Hyper Text Markup Lang
uage）形式で送るときは、 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit を付加する。両者の違いは“Ｃｏｎｔｅｎｔ−Ｔｙｐｅ
ヘッダ"にある。すなわち、純粋なテキスト文書の場合
は“ｔｅｘｔ／ｐｌａｉｎ"であり、ＨＴＭＬ形式の場
合は“ｔｅｘｔ／ｈｔｍｌ"である。特に、ＨＴＭＬ形
式で送った場合は、文字のサイズや色及びフォントの種
類を自由に選ぶことができ、見栄えがよくデザイン性に
優れた文書を送ることができるので、純粋なテキスト文
書だけのものに比べて遥かに表現力のあるメールを配信
することができる。

【００１４】なお、ＭＩＭＥ（Multipurpose Internet
Mail Extensions）の拡張仕様として“ｔｅｘｔ／ｅｎ
ｒｉｃｈｅｄ"タイプが提案されている。このタイプに
対応したＭＵＡは、ＨＴＭＬ形式に加えてリッチテキス
ト（ＲＴＦ）形式のメールも作成することができる。

【００１５】

【発明が解決しようとする課題】しかしながら、上述の
ＲＦＣ（Request For Comments）は、インターネットの
研究開発機関であるＩＥＴＦ（Internet Engineering T
ask Force）が取りまとめている文書群（ＴＣＰ／ＩＰ
の規格書）であり、インターネット関連の技術開発に欠
かせない文書であるが、その記載内容に強制力がないた
め、全てのＭＵＡが最新のＲＦＣをサポートしていると
は限らず、例えば、受信側のＭＵＡでＨＴＭＬ形式やリ
ッチテキスト形式をサポートしていない場合には、文字
情報だけのメール（テキスト形式のメール）しか送るこ
とができなかった。

【００１６】このため、メーリングリストや同報送信の
ように同一のメールを複数の人に送信する際には、宛先
の中にＨＴＭＬ形式やリッチテキスト形式をサポートし
ていないＭＵＡ（以下便宜的に「低機能ＭＵＡ」とい
う）があることを想定してテキスト形式のメールを送る
というマナーになっているが、このマナーは、低機能Ｍ
ＵＡにとっては都合がよいものの、ＨＴＭＬ形式やリッ
チテキスト形式をサポートしているＭＵＡ（以下便宜的
に「高機能ＭＵＡ」という）にとっては、その表示能力
を全く発揮できないという問題点があった。

【００１７】そこで本発明は、テキスト形式のメールに
書式情報等を付加して高機能ＭＵＡに配信でき、以って
高機能ＭＵＡの表示能力を充分に発揮させることを目的
とする。

【００１８】

【課題を解決するための手段】請求項１記載のメール配
信装置は、メールアカウントごとの着信メールを保持す
る第１保持手段と、メールアカウントごとの変換条件を
保持する第２保持手段と、任意のメールアカウントから
の要求に応答して当該メールアカウントの変換条件を検
索する検索手段と、任意のメールアカウントからの要求
に応答して当該メールアカウントの着信メールを読み出
すとともに、前記検索手段で当該メールアカウントの変
換条件が検索された場合は、該変換条件に従って該着信
メールを変換処理して当該メールアカウント宛てに配信
する配信手段と、を備えたメール配信装置であって、前
記変換処理は、着信メール本文に書式情報を付加し、及
び／又は、着信メール本文の背景にイメージ情報を付加
するものであることを特徴とする。請求項２記載のメー
ル配信装置は、任意のメールアカウントからの要求を受
け付ける二つのポートと、メールアカウントごとの着信
メールを保持する保持手段と、任意のメールアカウント
からの要求を前記二つのポートの一方で受け付けると該
要求に応答して当該メールアカウントの保持手段から着
信メールを読み出し、当該メールアカウント宛てに配信
する第１配信手段と、任意のメールアカウントからの要
求を前記二つのポートの他方で受け付けると該要求に応
答して当該メールアカウントの保持手段から着信メール
を読み出すとともに、所定の変換条件に従って着信メー
ルを変換処理して当該メールアカウント宛てに配信する
第２配信手段と、を備えたメール配信装置であって、前
記変換処理は、着信メール本文に書式情報を付加し、及
び／又は、着信メール本文の背景にイメージ情報を付加
するものであることを特徴とする。請求項３記載のメー
ル配信装置は、請求項１又は請求項２記載のメール配信
装置において、前記書式情報及びイメージ情報は、ＨＴ
ＭＬ形式で付加されることを特徴とする。請求項４記載
のメール配信装置は、請求項１又は請求項２記載のメー
ル配信装置において、前記書式情報及びイメージ情報
は、リッチテキスト形式で付加されることを特徴とす
る。請求項５記載のメール配信装置は、請求項１記載の
メール配信装置において、前記変換条件を設定するため
のＨＴＭＬドキュメントをネットワーク上に公開するＷ
ＷＷサーバを含むことを特徴とする。請求項６記載のメ
ール配信方法は、メールアカウントごとの着信メールを
保持する第１ステップと、メールアカウントごとの変換
条件を保持する第２ステップと、任意のメールアカウン
トからの要求に応答して当該メールアカウントの変換条
件を検索する第３ステップと、任意のメールアカウント
からの要求に応答して当該メールアカウントの着信メー
ルを読み出すとともに、前記第３ステップで当該メール
アカウントの変換条件が検索された場合は、該変換条件
に従って該着信メールを変換処理して当該メールアカウ
ント宛てに配信する第４ステップと、を含むメール配信
方法において、前記変換処理は、メール本文に書式情報
を付加し、及び／又は、メール本文の背景にイメージ情
報を付加するものであることを特徴とする。請求項７記
載のメール配信方法は、任意のメールアカウントからの
要求を二つのポートの何れかで受け付ける第１ステップ
と、メールアカウントごとの着信メールを保持手段に保
持する第２ステップと、任意のメールアカウントからの
要求を前記二つのポートの一方で受け付けると該要求に
応答して当該メールアカウントの保持手段から着信メー
ルを読み出し、当該メールアカウント宛てに配信する第
３ステップと、任意のメールアカウントからの要求を前
記二つのポートの他方で受け付けると該要求に応答して
当該メールアカウントの保持手段から着信メールを読み
出すとともに、所定の変換条件に従って着信メールを変
換処理して当該メールアカウント宛てに配信する第４ス
テップと、を含むメール配信方法であって、前記変換処
理は、着信メール本文に書式情報を付加し、及び／又
は、着信メール本文の背景にイメージ情報を付加するも
のであることを特徴とする。請求項８記載の記憶媒体
は、請求項１記載の第１保持手段、第２保持手段、検索
手段及び配信手段を実現するためのプログラムを格納し
たことを特徴とする。請求項９記載の記憶媒体は、請求
項２記載の保持手段、第１配信手段及び第２配信手段を
実現するためのプログラムを格納したことを特徴とす
る。

【００１９】

【発明の実施の形態】以下、本発明の実施の形態を、イ
ンターネットに接続されたメール配信システムを例にし
て図面を参照しながら説明する。図１において、１０は
インターネット、１１はＷＷＷサーバ、１２はＭＴＡを
搭載したメールサーバ（ＳＭＴＰサーバ兼ＰＯＰ３サー
バ）、１３はデータベース（第２保持手段）、１４〜１
６はそれぞれＭＵＡを搭載した第１〜第３クライアント
コンピュータである。なお、言うまでもなくクライアン
トコンピュータの台数は一例である。

【００２０】図２は、ＷＷＷサーバ１１とメールサーバ
１２に共通のブロック図である。便宜的にＷＷＷサーバ
１１として説明すると、１１ａはＣＰＵ、１１ｂはＣＰ
Ｕ１１ａのワーキングメモリとして働くＲＡＭ、１１ｃ
はＯＳやＷＷＷサーバプログラム（メールサーバ１２の
場合はＳＭＴＰ／ＰＯＰ３サーバプログラム）などを収
めた第１記憶部、１１ｄはＨＴＭＬ形式のＷｅｂドキュ
メントを収めた公開記憶領域（メールサーバ１２の場合
はメールアカウントごとの着信メールを収めたメールボ
ックス）を有する第２記憶部、１１ｅはインターネット
１０との間のデータ交信を行う通信インターフェース
部、１１ｆは各部間を接続するバスである。なお、メー
ルサーバ１２のＣＰＵ１１ａは発明の要旨に記載の検索
手段及び配信手段として機能し、メールサーバ１２の第
１記憶部１１ｃは同第１保持手段として機能する。

【００２１】ここで、第１及び第２クライアントコンピ
ュータ１４、１５には冒頭の高機能ＭＵＡが搭載されて
おり、第３クライアントコンピュータ１６には低機能Ｍ
ＵＡが搭載されているものと仮定する。すなわち、第１
クライアントコンピュータ１４や第２クライアントコン
ピュータ１５はＨＴＭＬ形式又はＲＴＦ形式のメールを
送受信できるが、第３クライアントコンピュータ１６は
テキスト形式のメールしか送受信できないと仮定する。

【００２２】この仮定において、第１〜第３クライアン
トコンピュータ１４〜１６で、例えば、同一のメーリン
グリストからのメール配信を受け取る場合を考えると、
冒頭でも述べたように、メーリングリストのメールは低
機能ＭＵＡの存在を考慮して文字情報だけの形式（テキ
スト形式）で送られてくるから、第１〜第３クライアン
トコンピュータ１４〜１６は、その何れも配信メールを
支障なく読むことができる。

【００２３】しかしながら、高機能ＭＵＡを搭載した第
１及び第２クライアントコンピュータ１４，１５に着目
すると、これらは、ＨＴＭＬ形式やＲＴＦ形式といった
せっかくの表現力豊かな機能を備えているにもかかわら
ず、その機能を全く活用していないから、無味乾燥なテ
キスト文字だけの羅列となって見た目の美しさに乏しい
という点で改善の余地がある。

【００２４】そこで、本実施の形態では、以下の技術的
事項を備えることにより、テキスト形式のメールに書式
情報等を付加して高機能ＭＵＡ（第１及び第２クライア
ントコンピュータ１４，１５）に配信でき、以って高機
能ＭＵＡの表示能力を充分に発揮させることを課題とし
ている。

【００２５】（１）メールサーバ１２：既述のとおり、
ＳＭＴＰサーバとＰＯＰ３サーバを兼務するサーバであ
る。メールサーバ１２と同じドメイン（例えば、“ｃａ
ｓｉｏ．ｃｏ．ｊｐ"）のクライアントコンピュータか
ら送信された電子メールは、このメールサーバ１２（の
ＳＭＴＰサーバ）を介して宛先のＰＯＰ３サーバ（宛先
のドメインが“ｃａｓｉｏ．ｃｏ．ｊｐ"の場合はメー
ルサーバ１２のＰＯＰ３サーバ）に送出され、また、例
えば、“ｓａｔｏ＠ｃａｓｉｏ．ｃｏ．ｊｐ"宛ての電
子メールは、メールサーバ１２の（ＰＯＰ３サーバの）
メールボックスに届けられる。

【００２６】（２）ＷＷＷサーバ１１：ＷＷＷサーバ１
１の基本的な機能は、インターネット１０に接続された
クライアントコンピュータにＨＴＭＬドキュメントを公
開するというＷＷＷサービスの提供である。ＷＷＷサー
ビスは静的なＨＴＭＬドキュメントの公開と、クライア
ントの操作に応答してその内容が動的に変化するいわゆ
るアクティブなＨＴＭＬドキュメントの公開の二種類あ
るが、本実施の形態のＷＷＷサーバ１１は、後者のサー
ビス（便宜的に「動的サービス」という）を提供する。

【００２７】図３は、本実施の形態における動的サービ
スの概念図であり、クライアントコンピュータのＷＷＷ
プラウザ２０でＷＷＷサーバ１１のＵＲＬ（Uniform Re
source Location）をアクセスすると、ＷＷＷサーバソ
フト２１は、まず、所定のルートドキュメント（いわゆ
るホームページ）をＷＷＷプラウザ２０に送信し、その
ルートドキュメント内に適当に張られたリンク個所のク
リックに応答して、例えば、図４に示すような「メール
配信オプションの設定ページ」を送信するようになって
いる。

【００２８】メール配信オプションの設定ページには、
ＨＴＭＬ表記法で設計された幾つかの入力項目が設けら
れており、同項目は、例えば、本文の形式（図ではテキ
スト形式、ＨＴＭＬ形式、ＲＴＦ形式）を選択するため
のオプショングループボタン３１、本文の文字色を選択
するためのコンボボックス３２、本文の文字サイズを選
択するためのコンボボックス３３、本文の背景イメージ
を選択するためのコンボボックス３４、添付画像を選択
するためのコンボボックス３５、登録者のメールアドレ
ス（メールアカウント）を入力するためのテキストボッ
クス３６などである。なお、オプショングループボタン
３１の入力値はテキスト形式を選択すると“０"、ＨＴ
ＭＬ形式を選択すると“１"、ＲＴＦ形式を選択すると
“２"となり、コンボボックス３２〜３５の入力値はあ
らかじめ登録されたリストデータの中の任意の選択値
（図示の選択値は、色；“黒"、サイズ；“大"、背景；
“格子模様"、画像；“なし"）であり、テキストボック
ス３６の入力値はキーボードから入力された任意の値で
ある。

【００２９】なお、ページ下側の送信ボタン３７は、い
わゆるサブミットボタン（ＨＴＭＬ表記：＜ＩＮＰＵＴ
ＴＹＰＥ＝“ｓｕｂｍｉｔ" ＶＡＬＵ＝“送信"）で
あり、このボタンを押すと、上記の各項目の入力データ
がＷＷＷサーバソフト２１を介してＣＧＩ（Common Gat
eway Interface）２２に送信されるようになっている。
また、ページ下側の中止ボタン３８は、いわゆるリセッ
トボタン（ＨＴＭＬ表記：＜ＩＮＰＵＴＴＹＰＥ＝
“ｒｅｓｅｔ" ＶＡＬＵ＝“中止"）であり、このボタ
ンを押すと、上記の各項目の入力データがクリアされる
ようになっている。

【００３０】ＣＧＩ２２は、ＷＷＷサーバプログラム２
１とデータベース１３とのインターフェースを取るため
の専用プログラムであり、本実施の形態のＣＧＩ２２
は、ＷＷＷプラウザ２０からの送信データ（送信ボタン
３７を押したときの送信データ）を受け取って、それを
データベース１３のテーブルに格納する。

【００３１】図５は、データベース１３のテーブル概念
図である。このテーブルは、便宜的に、“ＡＤＲＳ"、
“本文"、“文字（色）"、“文字（サイズ）"、“背景"
及び“画像"と命名した６個のフィールドを持つ多数の
レコード（図ではそのうちの一つのレコードを示す）で
構成されており、各フィールドに格納されるデータは、
以下のとおりである。

【００３２】（Ａ）ＡＤＲＳフィールド：テキストボッ
クス３６の入力データ（登録者のメールアドレス）が格
納される。（Ｂ）本文フィールド：オプショングループボタン３１
の値（テキスト形式の場合は“０"、ＨＴＭＬ形式の場
合は“１"、ＲＴＦ形式の場合は“２"）が格納される。（Ｃ）文字（色）フィールド：コンボボックス３２の値
が格納される。（Ｄ）文字（サイズ）フィールド：コンボボックス３３
の値が格納される。（Ｅ）背景フィールド：コンボボックス３４の値が格納
される。（Ｆ）画像フィールド：コンボボックス３５の値が格納
される。

【００３３】例えば、図４の入力状態で送信ボタン３７
を押すと、データベース１３のテーブルには、図５に示
す各値（ＡＤＳＲＳ＝“ｓａｔｏ＠ｃａｓｉｏ．ｃｏ．
ｊｐ"、本文＝“１"、文字（色）＝“黒"、文字（サイ
ズ）＝“大"、背景＝“格子模様"、画像＝“なし"）が
格納されることになる。

【００３４】次に、作用を説明する。図６は、メールサ
ーバ１２におけるメール受信時（ａ）と配信時（ｂ）の
フローチャートを示す図である。この図において、受信
時には、メールを受信する度に（Ｓ１０）該当するアカ
ウントのメールボックスに格納する（Ｓ１１）だけであ
るが、配信時には、そのメールアカウントからのメール
配信要求があると（Ｓ２０）、該当するメールボックス
を開いてメールを取り出す（Ｓ２１）とともに、そのメ
ールアカウントでデータベース１３を検索して変換条件
の有無を調べ（Ｓ２２）、変換条件が設定されていた場
合には、その変換条件に従ってメールの変換処理を実行
（Ｓ２３）した後、要求元のクライアントコンピュータ
へ配信するという処理を実行するようになっている。

【００３５】ここで、変換条件とは、メール受信側のク
ライアントコンピュータのＭＵＡの機能を充分に引き出
すための、以下の各条件をいう。（ａ）第１変換条件：テーブルの本文フィールドの値が
“１"の場合（ＨＴＭＬ形式）又は“２"の場合（ＲＴＦ
形式）に“有"となる変換条件である。この変換条件が
“有"の場合は、着信メールの本文を該当形式に変換す
るとともに、以下の第２〜第4の変換条件を適用して、
その書式情報等を整える。（ｂ）第２変換条件：テーブルの文字（色）フィールド
の値が“黒"以外の場合に“有"となる変換条件である。
この変換条件が“有"の場合は、着信メールの本文の文
字色をその色に変換する（例えば、ＨＴＭＬ形式であれ
ば＜ＦＯＮＴＣＯＬＯＲ＝ｃｏｌｏｒｎａｍｅ＞タグ
を埋め込む；ｃｏｌｏｒｎａｍｅは色の名前）。（ｃ）第３変換条件：テーブルの文字（サイズ）フィー
ルドの値が標準値以外の場合に“有"となる変換条件で
ある。この変換条件が“有"の場合は、着信メールの本
文の文字サイズをその大きさに変換する（例えば、ＨＴ
ＭＬ形式であれば＜ＦＯＮＴＳＩＺＥ＝ｎ＞タグを埋
め込む；ｎは１〜７）。

【００３６】（ｄ）第４の変換条件：テーブルの背景フ
ィールドの値が“なし"以外の場合に“有"となる変換条
件である。この変換条件が“有"の場合は、着信メール
の本文の背景に指定の色又はイメージを表示する（例え
ば、色指定の場合、ＨＴＭＬ形式であれば＜ＢＯＤＹＢ
ＧＣＯＬＯＲ＝ｃｏｌｏｒｎａｍｅ＞タグを埋め込
む）。（ｅ）第５の変換条件：テーブルの画像フィールドの値
が“なし"以外の場合に“有"となる変換条件である。こ
の変換条件が“有"の場合は、着信メールの本文中に指
定の画像を表示する（例えば、ＨＴＭＬ形式であれば＜
ＩＭＧＳＲＣ＝ｆｎａｍｅ＞タグを埋め込む；ｆｎａ
ｍｅは画像ファイルのファイル名）。

【００３７】図７は、着信メールの変換処理結果を示す
ソースリストであり、この例は、ＨＴＭＬ形式で、且
つ、本文の文字サイズを“大"にしたときの例を示して
いる。Ｘ−ＨＴＭＬタグはＭＩＭＥ拡張仕様のＨＴＭＬ
形式を表しており、ＨＴＭＬタグ及びＢＯＤＹタグはＨ
ＴＭＬの３．０／３．２におけるドキュメント構造定義
タグである。図において、ＢＯＤＹタグの“ｂａｃｋｇ
ｒｏｕｎｄ＝ｉｍａｇｅ１．ｇｉｆ"は本文の背景オプ
ションであり、この例では、“ｉｍａｇｅ１．ｇｉｆ"
という名前のＧＩＦ（ジフ）形式ファイルを背景画像に
指定している。また、「○○株式会社は・・・・予定だ。」
という本文には、ＦＯＮＴタグのサイズオプションの
“４"が指定されている。これらのオプション設定は、
上記第１変換条件、第３変換条件及び第4の変換条件に
対応している。

【００３８】図８は、変換処理を実行しなかったとき
（ａ）と実行したとき（ｂ）の着信メールの表示状態を
示す図であり、図からも理解されるように、変換処理を
実行したとき（ｂ）の本文の文字サイズが大きくなって
いる。

【００３９】以上説明したとおり、本実施の形態によれ
ば、インターネットに接続可能な任意のクライアントコ
ンピュータからＷＷＷサーバ１１にアクセスして、図４
の「メール配信オプションの設定ページ」をＷＷＷプラ
ウザ２０で開き、そのページの各項目に所要のデータを
入力して送信ボタン３７を押すことにより、特定のメー
ルアカウントに関するオプション設定、すなわち、着信
メール本文をテキスト形式、ＨＴＭＬ形式又はＲＴＦ形
式にする同本文の文字色を選択する同本文の文字サイズを選択する同本文の背景イメージを選択する図像の添付ファイルを選択するをデータベース１３に登録することができる。

【００４０】そして、当該メールアカウント宛てのメー
ルの配信を要求されたメールサーバ１２は、データベー
ス１３を検索して上記オプション設定の有無を調べ、設
定有りの場合に所要の変換処理を実行してから配信する
ので、受信側のクライアントコンピュータには、上記オ
プション設定に応じて変換されたメールが届けられる。

【００４１】したがって、上記オプション設定を、例え
ば、ＨＴＭＬ形式、文字サイズ“大"、背景イメージ
“格子模様"にしておけば、メーリングリストのような
テキスト形式のメールを配信する場合でも当該メールを
上記設定に基づいて変換処理してからクライアントコン
ピュータへ送信できるので、そのクライアントコンピュ
ータ上では、文字サイズが“大"で背景イメージが“格
子模様"のＨＴＭＬ形式のメールを受け取ることがで
き、無味乾燥なテキスト形式のメールを表現力豊かに表
示することができるという格別な効果が得られる。

【００４２】なお、以上の例では、ＷＷＷサーバ１１に
アクセスして変換条件を設定しているが、これに限らな
い。例えば、図９に示すように、メールサーバ１２に二
つのポート（第１ポート１２ａ、第２ポート１２ｂ）を
設け、一方のポートからＰＯＰサーバ１２ｄにアクセス
した場合に、あらかじめ設定された高機能ＭＵＡ用の変
換条件を適用するようにしてもよい。第１及び第２ポー
ト１２ａ、１２ｂとしては、例えば、ダイアルアップポ
ート、ＯＳＩ基本参照モデルのセッション層とトランス
ポート層の間のポート（例えばＲＦＣ１７００に規定さ
れたＰＯＰ３ポートは１１０番）、または、イーサネッ
ト用のポートを利用できる。

【００４３】図９において、４０は公衆回線網を含むネ
ットワーク、４１は第１クライアントコンピュータ１４
とネットワーク４０の間を接続する信号線、４２は第３
クライアントコンピュータ１６とネットワーク４０の間
を接続する信号線、４３は第１ポート１２ａとネットワ
ーク４０の間を接続する信号線、４４は第２ポート１２
ｂとネットワーク４０の間を接続する信号線、１２ｃは
ＳＭＴＰサーバ、１２ｅはメールボックス（保持手
段）、１２ｆは形式変換部（第１配信手段、第２配信手
段）である。

【００４４】今、第１ポート１２ａを高機能ＭＵＡ用と
すると、高機能ＭＵＡを搭載した第１クライアントコン
ピュータ１４からＰＯＰサーバ１２ｄをアクセスする場
合は第１ポート１２ａを介してアクセスし、一方、低機
能ＭＵＡを搭載した第３クライアントコンピュータ１６
からＰＯＰサーバ１２ｄをアクセスする場合は第２ポー
ト１２ｂを介してアクセスする。

【００４５】形式変換部１２ｆは、第１ポート１２ａを
介してアクセスされた場合はデータベース１３から変換
条件を取り出し、その変換条件に従ってメールボックス
１２ｅ内のメールを変換処理した後、変換後のメールを
アクセス元のコンピュータに配信するが、第２ポート１
２ｂを介してアクセスされた場合はメールボックス１２
ｅ内のメールをそのままアクセス元のコンピュータに配
信する。

【００４６】したがって、クライアントのＭＵＡの機能
に適合した形式でメールを配信できるとともに、ＷＷＷ
サーバを要しないのでシステムの運営コストを低減でき
ると言うメリットが得られる。

【００４７】なお、以上の実施例では、メールの変換条
件の設定をもっぱらそのメールを受け取るユーザ側で全
て行っていたが、これに限らない。ユーザ側で基本的な
設定を行い、具体的な設定はサーバ側で任意に（所定の
規則性に基づいて若しくはランダムに）行ってもよい。
例えば、ユーザ側でＨＴＭＬ形式を指定するとともに、
サーバ側で任意の背景イメージ（又は背景色）の選択や
画像ファイルの添付を行うようにすれば、メールの表示
状態を予測できなくなり、面白味が増すという効果が得
られる。

【００４８】上記実施の形態の主要な機能〔（第１保持
手段、第２保持手段、検索手段及び配信手段）又は（保
持手段、第１配信手段及び第２配信手段）〕は、マイク
ロコンピュータを含むハードウェア資産と、ＯＳや各種
プログラムなどのソフトウェア資産との有機的結合によ
って機能的に実現されるものであるが、ハードウェア資
産は汎用のものを利用できるから、本発明にとって欠く
ことのできない必須の事項は、実質的に、ＯＳや各種プ
ログラムに集約されているということがいえる。したが
って、本発明は、ＯＳ及び各種プログラムのすべて又は
その要部を格納した、フロッピーディスク、ＭＯ、Ｃ
Ｄ、ハードディスク、半導体メモリなどの記録媒体（そ
れ自体が流通経路に乗るものはもちろん、ネットワーク
上にあって記録内容だけを提供するものも含む）を包含
するものである。

【００４９】

【発明の効果】請求項１又は請求項６記載の発明によれ
ば、着信メール本文に書式情報を付加し、及び／又は、
着信メール本文の背景にイメージ情報を付加して、要求
元のクライアントコンピュータへ配信するので、例え
ば、メーリングリストのようなテキスト形式のメールで
あっても、所要の書式情報や背景等を付加して配信する
ことができる。したがって、受信側のクライアントコン
ピュータに高機能ＭＵＡが搭載されていた場合に、その
表示能力を充分に発揮させることができる。請求項２又
は請求項７記載の発明によれば、ＷＷＷサーバ等を運営
せずに、請求項１又は請求項６記載の発明と同等の効果
を得ることができ、システムコストを低減できる。請求
項３記載の発明によれば、前記書式情報及びイメージ情
報は、ＨＴＭＬ形式で付加されるので、同形式をサポー
トしたＭＵＡに適用することができる。請求項４記載の
発明によれば、前記書式情報及びイメージ情報は、リッ
チテキスト形式で付加されので、同形式をサポートした
ＭＵＡに適用することができる。請求項５記載の発明に
よれば、ＷＷＷサーバにアクセスするだけで、場所や時
間を問わずに変換条件の設定を行うことができる。

【図面の簡単な説明】

【図１】実施の形態のネットワーク構成図である。

【図２】サーバ（ＷＷＷサーバ又はメールサーバ）のブ
ロック図である。

【図３】ＷＷＷプラウザとデータベース間の情報伝達模
式図である。

【図４】実施の形態のＷＷＷ設定画面の表示状態図であ
る。

【図５】データベースのテーブル構造図である。

【図６】実施の形態のメール配信時のフローチャートで
ある。

【図７】実施の形態のメールソースリスト図である。

【図８】実施の形態のメール表示状態図である。

【図９】他の実施の形態のシステム構成図である。

【図１０】従来のネットワーク構成図である。

【図１１】メール配信時のタイムラインである。

【図１２】メールヘッダ及びメッセージボディを含む電
子メールのソースリストである。

【符号の説明】

１１ａＣＰＵ（検索手段、配信手段）１１ｄ第２記憶部（第１保持手段）１２ａ、１２ｂポート１２ｅメールボックス（保持手段）１２ｆ形式変換部（第１配信手段、第２配信
手段）１３データベース（第２保持手段）

Claims

【特許請求の範囲】

【請求項１】メールアカウントごとの着信メールを保
持する第１保持手段と、メールアカウントごとの変換条件を保持する第２保持手
段と、任意のメールアカウントからの要求に応答して当該メー
ルアカウントの変換条件を検索する検索手段と、任意のメールアカウントからの要求に応答して当該メー
ルアカウントの着信メールを読み出すとともに、前記検
索手段で当該メールアカウントの変換条件が検索された
場合は、該変換条件に従って該着信メールを変換処理し
て当該メールアカウント宛てに配信する配信手段と、を
備えたメール配信装置であって、前記変換処理は、着信メール本文に書式情報を付加し、
及び／又は、着信メール本文の背景にイメージ情報を付
加するものであることを特徴とするメール配信装置。
【請求項２】任意のメールアカウントからの要求を受
け付ける二つのポートと、メールアカウントごとの着信メールを保持する保持手段
と、任意のメールアカウントからの要求を前記二つのポート
の一方で受け付けると該要求に応答して当該メールアカ
ウントの保持手段から着信メールを読み出し、当該メー
ルアカウント宛てに配信する第１配信手段と、任意のメールアカウントからの要求を前記二つのポート
の他方で受け付けると該要求に応答して当該メールアカ
ウントの保持手段から着信メールを読み出すとともに、
所定の変換条件に従って着信メールを変換処理して当該
メールアカウント宛てに配信する第２配信手段と、を備
えたメール配信装置であって、前記変換処理は、着信メール本文に書式情報を付加し、
及び／又は、着信メール本文の背景にイメージ情報を付
加するものであることを特徴とするメール配信装置。
【請求項３】前記書式情報及びイメージ情報は、ＨＴ
ＭＬ形式で付加されることを特徴とする請求項１又は請
求項２記載のメール配信装置。
【請求項４】前記書式情報及びイメージ情報は、リッ
チテキスト形式で付加されることを特徴とする請求項１
又は請求項２記載のメール配信装置。
【請求項５】前記変換条件を設定するためのＨＴＭＬ
ドキュメントをネットワーク上に公開するＷＷＷサーバ
を含むことを特徴とする請求項１記載のメール配信装
置。
【請求項６】メールアカウントごとの着信メールを保
持する第１ステップと、メールアカウントごとの変換条件を保持する第２ステッ
プと、任意のメールアカウントからの要求に応答して当該メー
ルアカウントの変換条件を検索する第３ステップと、任意のメールアカウントからの要求に応答して当該メー
ルアカウントの着信メールを読み出すとともに、前記第
３ステップで当該メールアカウントの変換条件が検索さ
れた場合は、該変換条件に従って該着信メールを変換処
理して当該メールアカウント宛てに配信する第４ステッ
プと、を含むメール配信方法において、前記変換処理は、メール本文に書式情報を付加し、及び
／又は、メール本文の背景にイメージ情報を付加するも
のであることを特徴とするメール配信方法。
【請求項７】任意のメールアカウントからの要求を二
つのポートの何れかで受け付ける第１ステップと、メールアカウントごとの着信メールを保持手段に保持す
る第２ステップと、任意のメールアカウントからの要求を前記二つのポート
の一方で受け付けると該要求に応答して当該メールアカ
ウントの保持手段から着信メールを読み出し、当該メー
ルアカウント宛てに配信する第３ステップと、任意のメールアカウントからの要求を前記二つのポート
の他方で受け付けると該要求に応答して当該メールアカ
ウントの保持手段から着信メールを読み出すとともに、
所定の変換条件に従って着信メールを変換処理して当該
メールアカウント宛てに配信する第４ステップと、を含
むメール配信方法であって、前記変換処理は、着信メール本文に書式情報を付加し、
及び／又は、着信メール本文の背景にイメージ情報を付
加するものであることを特徴とするメール配信方法。
【請求項８】請求項１記載の第１保持手段、第２保持
手段、検索手段及び配信手段を実現するためのプログラ
ムを格納したことを特徴とする記憶媒体。
【請求項９】請求項２記載の保持手段、第１配信手段
及び第２配信手段を実現するためのプログラムを格納し
たことを特徴とする記憶媒体。