JP2011008371A - メール送信方法、メール送信プログラム、メール送信装置、およびメールサーバ - Google Patents

Abstract

【課題】送信端末と受信端末のキャリアが異なる場合であっても、メールに含まれる絵文字を受信側で忠実に再現できるようにする。
【解決手段】端末１１は、ユーザの操作に応じて作成された絵文字を含むテキストメール１６の宛先メールアドレスに基づき、当該メールについて受信側で前記絵文字と同一の画像データが表示されるか否かを判断する。前記絵文字と同一の画像データが表示されないと判断された場合、テキストメール１６を当該絵文字の画像データを組み込んだＨＴＭＬメール１７に変換する。このＨＴＭＬメールを当該宛先メールアドレス宛（端末２１）に送信する。
【選択図】図２

Description

本発明は、携帯電話端末をはじめとする携帯端末等のメール送信装置、およびそのメール送信方法、メール送信プログラム、ならびにそのメールを処理するメールサーバに関する。

現在、携帯電話サービスは、複数の携帯電話通信事業者（以下、キャリアという）により提供されている。携帯電話端末を代表とする携帯端末も、そのサービスを提供しているキャリア毎に独自の仕様で提供されている。

そのサービスには電子メール（単にメールともいう）の送受信が含まれる。異なるキャリアの端末間でのメールの送受信において、いわゆる絵文字と呼ばれるような特殊な文字については各キャリアが独自にその文字コードや絵柄を決定しているため、送信側端末で意図したとおりの絵文字のイメージ（絵柄）が受信側で再生されないといういわゆる文字化けの問題が知られている。

この問題を解決するために、キャリア側のサーバ処理によって、あるキャリアにおける絵文字を他のキャリアにおける類似の絵文字（コード）に変換する技術が知られている。

特許文献１には、携帯電話端末で絵文字を含むメールの送信時に、その絵文字について全キャリアの対応する絵文字のコードを当該メールに付加して送信し、受信側で自キャリアに対応するコードを用いて絵文字の表示を行う技術が提案されている。

特許文献２には、特定の絵文字を、その絵文字に対応した文字列装飾タグに変換してＨＴＭＬ（Hyper Text Markup Language）メールを作成する技術が開示されている。

特開２００４−２９５３４４号公報 特開２００４−１５７７２６号公報

しかしながら、キャリア側のサーバ処理によって発信元の絵文字と類似した絵文字に変換する技術は、そのような変換サービスが導入されていないキャリア間では有効に機能しない。

特許文献１に記載の技術では、すべての絵文字について他のキャリアにおける対応する絵文字のコードを端末内に保存する必要があり、限られた記憶スペースを圧迫するという問題がある。

また、異なるキャリアにおいては類似する絵文字が用意されているとは限らず、存在しても全く同じ絵柄ではない。したがって、異なるキャリア間では、受信側で再生される絵文字の再現性はやはり制限されたものとならざるを得ない。

特許文献２に記載の技術は他キャリアの端末における絵文字の文字化けを防止することを目的とするものではない。

本発明はこのような背景においてなされたものであり、その目的は、送信端末と受信端末のキャリアが異なる場合であっても、メールに含まれる絵文字を受信側で忠実に再現できるようにするメール送信方法、メール送信プログラム、メール送信装置、およびメールサーバを提供することにある。

本発明によるメール送信方法は、絵文字の画像データを特定する特殊表示用コードを含むメールを作成する機能を有するメール送信装置におけるメール送信方法であって、ユーザの操作に応じて作成された前記特殊表示用コードを含むテキストメールの宛先メールアドレスに基づき、当該宛先が特定の条件に合致するか否かを判断するステップと、前記特定の条件に合致すると判断された場合、前記テキストメールを、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールに変換するステップと、作成されたマークアップランゲージ形式メールを当該宛先メールアドレス宛に送信するステップとを備えたことを特徴とする。前記特定の条件とは、例えば、前記特殊表示用コードを含むテキストメールについて受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されるか否かであり、前記特定の条件に合致するとは、前記特殊表示用コードを含むテキストメールについて受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されないことである。

前記特定の条件に合致するか否か、あるいは、受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されるか否かは自動的に判断される。前記特定の条件に合致すると判断される場合、あるいは、特殊表示用コードにより特定される絵文字と同一の画像データが表示されないと判断された場合、テキストメールを、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールに変換するので、その送信側での絵文字のイメージが受信側で忠実に再現される。

前記宛先メールアドレスが複数存在する場合、各宛先メールアドレスについて前記特定の条件に合致するか否かを判断し、前記特定の条件に合致する宛先メールアドレスと前記特定の条件に合致しない宛先メールアドレスとが混在するとき、前記特定の条件に合致しない宛先メールアドレスに対してはテキストメールを送信し、前記特定の条件に合致する宛先メールアドレスに対してはマークアップランゲージ形式メールを送信する。これにより、両宛先メールアドレスが混在する場合でも、作成されたメールが宛先メールアドレスに応じて自動的にテキストメールとマークアップランゲージ形式メールに振り分けられる。

この場合、前記テキストメールおよびマークアップランゲージ形式メールにおいて、送信を抑止する宛先メールアドレスに対して、送信抑止属性を付加することができる。これにより、各宛先メールアドレス宛にテキストメールとマークアップランゲージ形式メールの両方が送信されることが防止される。

前記テキストメールまたは前記マークアップランゲージ形式メールを送信履歴として保存する際、前記送信抑止属性を削除して保存することが好ましい。これによりメールの本来の形式で履歴の保存が可能となる。

前記メールについて前記特定の条件に合致するか否かを判断するステップでは、前記宛先メールアドレスのドメイン名に基づいて判断を行うことができる。あるいは、マークアップランゲージ形式メールへの変換を拒否または許可するリストに基づいて判断を行うこともできる。

本発明によるメール送信プログラムは、絵文字の画像データを特定する特殊表示用コードを含むメールを送信するメール送信プログラムであって、ユーザの操作に応じて作成された前記特殊表示用コードを含むテキストメールの宛先メールアドレスに基づき、当該宛先が特定の条件に合致するか否かを判断するステップと、前記特定の条件に合致すると判断された場合、前記テキストメールを、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールに変換するステップと、作成されたマークアップランゲージ形式メールを当該宛先メールアドレス宛に送信するステップとをコンピュータに実行させることを特徴とする。

本発明によるメール送信装置は、絵文字の画像データを特定する特殊表示用コードを含むメールを作成する機能を有するメール送信装置であって、絵文字の画像データを格納した記憶手段と、ユーザによるメールの作成を支援するメール作成支援手段と、ユーザの操作に応じて作成された前記特殊表示用コードを含むテキストメールの宛先メールアドレスに基づき、当該宛先が特定の条件に合致するか否かを判断する判断手段と、前記特定の条件に合致すると判断された場合、前記テキストメールを、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールに変換するメール変換手段と、作成されたマークアップランゲージ形式メールを当該宛先メールアドレス宛に送信するメール送信手段とを備えたことを特徴とする。

本発明によるメールサーバは、受信したメールをそのメールに指定された宛先メールアドレス宛に転送するメールサーバであって、送信端末からメールを受信する手段と、受信したメールの宛先情報に付加された送信抑止属性を削除する手段と、前記受信したメールを、前記送信抑止属性が付加された宛先メールアドレスに対して送信することなく、他の宛先メールアドレス宛に転送する手段とを備えたことを特徴とする。

本発明によれば、ユーザの操作に応じて作成された特殊表示用コードを含むテキストメールの宛先メールアドレスに基づき、当該宛先が特定の条件に合致した場合、例えば前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されないことが予測される場合、当該宛先メールアドレスに対して、そのテキストメールを、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールに変換して送信することにより、異なるキャリア間を転送されても、絵文字は発信側端末におけるイメージを保持し続けることが可能となる。

また、受信端末において送信側と同じ絵文字のイメージが再生されることが保証されるので、送信者は煩わしい絵文字の互換情報に対して考慮する必要がなくなる。また、同報送信時に自キャリア以外の送信先の設定の有無を意識することなく、自由に絵文字を使用することが可能となる。

本発明の実施の形態に係るメールシステム全体の概略構成を示した図である。 本発明の実施の形態における課題解決方法の説明図である。 本発明の実施の形態における携帯端末の概略のハードウェア構成を示した図である。 本発明の実施の形態における携帯端末におけるメール関連画面の例を示した図である。 図４の例に対応したテキストメールのデータ構造の例を示した図である。 図４の例に対応した変換後のＨＴＭＬメールのデータ構造の例を示した図である。 本発明の実施の形態において、宛先メールアドレスが複数の場合の携帯端末におけるメール関連画面の例を示した図である。 本発明の実施の形態において、主として宛先情報について、その本実施の形態での変換前、変換後送信時、および送信後の内容をまとめて示した図である。 本発明の実施の形態において、宛先として２つのメールアドレスを含む絵文字入りメールの送信時の端末とサーバ間のやりとりを示すシーケンス図である。 図９Ａの変形例を示すシーケンス図である。 本発明の実施の形態における携帯端末において作成されたメールを送信するメール送信処理の処理手順の一例を示したフローチャートである。 図１０のステップＳ３２に示した宛先確認の第１の例を示したフローチャートである。 図１０のステップＳ３２に示した宛先確認の第２の例を示したフローチャートである。 本発明の実施の形態におけるチェックリストの構成例を示した図である。 本発明の実施の形態のメールサーバにおける本発明特有の処理を説明するための手順例を示したフローチャートである。 本発明の実施の形態の変形例におけるテキストメールの説明図である。 本発明の実施の形態の変形例におけるＨＴＭＬメールの説明図である。 本発明の実施の形態の変形例におけるサーバの処理手順を示したフローチャートである。

以下、本発明の好適な実施の形態について図面を参照しながら詳細に説明する。

図１は本実施の形態に係るメールシステム全体の概略構成を示したものである。

キャリアＡ携帯メールサーバ１３は、その携帯電話サービスの加入者の携帯端末１１，１２に対してメールサービスを提供する。キャリアＢ携帯メールサーバ２３は、その携帯電話サービスの加入者の携帯端末２１に対してメールサービスを提供する。キャリアＡ携帯メールサーバ１３はキャリアＡのメールゲートウェイ１５を介してインターネット３０に接続され、キャリアＢ携帯メールサーバ２３はキャリアＢのメールゲートウェイ２５を介してインターネット３０に接続される。ＰＣ用メールサーバ４３は、インターネット３０を介してインターネット接続サービスの加入者のパーソナルコンピュータ（ＰＣ）４１などの情報端末に対してメールサービスを提供する。任意の携帯端末は他の携帯端末および情報端末との間で、各メールサーバを介して、電子メール（本明細書では単にメールという）の送受信を行うことができる。

通常、インターネットを介したメールの送信はＳＭＴＰ（Simple Mail Transfer Protocol）と呼ばれるプロトコルに従って行われる。メールの受信はＰＯＰ３（Post Office Protocol version3）またはＩＭＡＰ４（Internet Message Access Protocol 4）と呼ばれるプロトコルに従って行われる。また、同じキャリアに属する端末間のメールの送受信は当該携帯メールサーバとの間で独自のプロトコルに従って行われる。

メールゲートウェイ１５，２５は、仲介する相互の間のプロトコルの変換およびフォーマットの変換を行う。

このようなシステムにおいて、各キャリアは、イラストなどの絵柄を文字と同等に扱うことができる絵文字の画像データを独自に用意し、各キャリアに共通の文字コードセットの空き領域に、その絵文字の画像データを特定する特殊表示用コードを独自に割り当てている。そのため、上述したように、自キャリアの端末同士間での送受信では各絵文字は正しく再現されるが、他のキャリアの端末では文字化けの状態となるという問題がある。

図２は、このような問題に対する本実施の形態における解決方法の説明図である。本実施の形態では、図２に示すように、あるキャリアＡの端末１１においてユーザの操作に応じて作成された絵文字入りのテキストメール１６を同キャリアの端末１２に送信する場合にはテキストメール１６としてそのまま送信する。しかし、他のキャリアＢの端末２１に対して送信する場合には、テキストメール１６を、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールの一例であるＨＴＭＬメール１７に変換して端末２１に送信する。ここに、ＨＴＭＬメールとは、ＭＩＭＥ(Multipurpose Internet Mail Extensions encoding)による、ＨＴＭＬなどで記載されたドキュメントの集合を組み込んだ電子メールをいう。ＭＩＭＥとは、一通の電子メールに異なる種類のデータを混在させるための技術をいう。ＨＴＭＬ文書も広義にはテキスト文書であるが、単に「テキスト」というときはプレーンテキストのことを指すものとする。

本実施の形態では、絵文字を含むテキストメールについては、その宛先メールアドレスに基づき、その宛先が、予め定めた特定の条件に合致するか否かを判断する。より具体的には、当該メールについて何らかの対処がなければ受信側で絵文字の文字化けが発生する（特殊表示用コードにより特定される絵文字と同一の画像データが表示されない）か否かを判断する。例えば、この判断は、宛先メールアドレスの中に含まれているドメイン名（aaa.ne.jp、bbb.ne.jp、ccc.com等）に基づいて行うことができる。絵文字の文字化けが発生すると判断された場合、テキストメール１６を、当該絵文字の画像データを組み込んだＨＴＭＬメール１７に変換する。

宛先は携帯端末である場合のみならず、ＰＣ（ユーザ）である場合にも同様である。

図３に、携帯端末１１，１２の代表として、携帯端末１１の概略のハードウェア構成を示す。

携帯端末１１は、ＣＰＵ１０１、記憶部１０２、表示制御部１０４と、表示部１０５、通信部１０６、操作部１０７、時計部１０９、音声処理部１１３、マイク１１４、およびスピーカ１１５を有している。

ＣＰＵ１０１、記憶部１０２、表示制御部１０４、通信部１０６、操作部１０７、時計部１０９、および音声処理部１１３はバス１１０に接続されており、このバス１１０を介して相互にデータの授受、コマンドの送受などが行われるようになっている。

ＣＰＵ１０１は、記憶部１０２から後述する所定のプログラムを読み取り、プログラムに従って所定の処理を実行することにより、各部の制御および必要な処理を行う。ＣＰＵ１０１は、本発明によるメール作成支援手段、判断手段、メール変換手段等を構成する。

記憶部１０２は、オペレーティングシステム（ＯＳ）や各種アプリケーション等のプログラム、ＣＰＵ１０１の演算結果や外部から取得したデータを一時的に保持格納するメモリ等の記憶手段である。特に、プログラムとしては、メールの作成支援および送受信を行うためのメーラー、ＨＴＭＬメールの表示に利用されるブラウザ、本実施の形態におけるテキストからＨＴＭＬへの変換を行うメール変換プログラム、等を含む。メール変換プログラムはメーラー内に組み込まれてもよい。また、データとしては、メールデータ、絵文字画像データを含む。メールデータとしては、送信されたメール、受信されたメール等を含み、それぞれが区分して保存されるメールボックスが用意されている。記憶部１０２は、さらに、メールアドレス、メール、ＵＲＬ（Uniform Resource Locator）、アドレス帳（電話帳）などの情報を保存する。記憶部１０２の少なくとも一部は、データを不揮発的に記憶する記憶領域またはメモリを有してもよい。

通信部１０６は、インターネット３０等の通信ネットワークとの接続を確立し、その通信ネットワークを介した他の装置とのデータの送受信を行う機能を有する。通信部１０６は、ＣＰＵ１０１とともに、本発明によるメール送信手段を構成する。

操作部１０７は、テンキーや各種指示キー等を有し、ユーザの入力インタフェースを提供する。

表示制御部１０４は、ＣＰＵ１０１からテキストや画像等の表示情報を受け取り、これに基づいて表示部１０５を駆動する機能を有する。表示部１０５は、液晶デバイス、有機ＥＬデバイス等の任意の表示デバイスを含み、表示制御部１０４からの駆動信号に従って画像を光学的に表示する機能を有する。

時計部１０９は、リアルタイムクロックを含み、カレンダーや時計、タイマーの機能を提供する。

図３に示した各種サーバの内部構成は、特に図示しないが、いずれもコンピュータ装置であり、ＣＰＵ、通信部、記憶装置、各種入出力装置を有する。

以下、本実施の形態における動作について具体例を挙げて説明する。

図４は、携帯端末におけるメール関連画面の例を示している。図４（ａ）は、メール作成時の宛先リスト画面を示し、同図（ｂ）はメール編集画面、同図（ｃ）は送信メール画面を示している。今、この例では送信者のメールアドレスは携帯端末に割り当てられたtaro@aaa.ne.jpであるとする。また、宛先メールアドレスは、同図（ａ）に示すように、他のキャリアの携帯端末に割り当てられたjiro@bbb.ne.jpであるとする。この図から分かるように、メールの本文にはひよこの絵柄を有する絵文字が含まれている。この場合、送信端末と受信端末のキャリアが異なるので、同図（ｂ）のように作成された絵文字入りのテキストメールは、送信前に同図（ｃ）に示すような対応するＨＴＭＬメールに変換され、宛先メールアドレス宛に送信される。この例では、同図（ｃ）のような送信履歴としてのＨＴＭＬメールの本文は、同図（ｂ）のような作成時のテキストメールの本文と外見上同じであるが、絵文字を文字データとして組み込んだことにより、本文およびメール全体のデータサイズが増加している。また同図（ｃ）に示すように、添付ファイル欄には、添付された画像ファイルのファイル名（Hiyoko.gif）が示されている。但し、図示したメール画面の表示例はあくまで例示であり、本発明はこれに限定されるものではなく、その表示内容や形式は受信側の仕様に依存する。

図５および図６に、図４の例に対応したテキストメールおよび変換後のＨＴＭＬメールのデータ構造の例を示す。

図５はテキストメールの一般的な構造を示しており、本文のテキスト５０中には絵文字コードを示す文字列５１が含まれている。

図６は本実施の形態におけるＨＴＭＬメールの構成例を示している。この構成は、標準仕様ＲＦＣ２１４１に準じ、ＭＩＭＥのマルチパートという形式でシンプルテキスト部６２、ＨＴＭＬテキスト部６３、画像部６４等の各部を含んでいる。ＨＴＭＬテキスト部６３には、挿入する画像ＩＤをＩＭＧタグで指定した部分６３ａを含み、この画像ＩＤの内容が画像部６４に対応している。画像部６４には、その画像ファイル形式、ファイル名、エンコード方式、画像ＩＤ（Content-ＩＤ）、および、埋め込まれた絵文字の画像ファイルのバイナリ値、ここではＢａｓｅ６４形式で符号化した文字列（詳細図示省略）が含まれている。

なお、シンプルテキスト部６２は、必須ではないが、受信端末がＨＴＭＬの処理ができない場合に代替的に表示されるテキストのみの内容を示している。この場合は絵文字が欠けて（図の例では半角スペースで）表示されることになる。

次に、宛先情報として複数の宛先メールアドレスを含む同報通信において、送信端末と同一キャリアの宛先メールアドレスおよび非同一キャリアの宛先メールアドレスが混在する場合について説明する。

図７に、宛先メールアドレスが複数の場合の携帯端末におけるメール関連画面の例を示す。図７（ａ）は、メール作成時の宛先リスト画面を示し、同図（ｂ）はメール編集画面、同図（ｃ）は送信メール画面を示している。

前記と同様、送信者のメールアドレスは携帯端末に割り当てられたtaro@aaa.ne.jpであるとする。また、宛先メールアドレスは、同図（ａ）に示すように、他のキャリアの携帯端末に割り当てられたjiro@bbb.ne.jpの他、Ｃｃ（カーボンコピー）としてhanako@aaa.ne.jpを含み、Ｂｃｃ（ブラインドカーボンコピー）としてsaburo@ccc.comを含んでいる。hanako@aaa.ne.jpは同一キャリアの宛先メールアドレスであるが、jiro@bbb.ne.jpとsaburo@ccc.comは非同一キャリアの宛先メールアドレスである。メールの本文は上記と同じである。saburo@ccc.comはＰＣ用のメールアドレスであり、端末に割り当てられるものではなくユーザに割り当てられるものである。

本実施の形態では、このような場合、同一キャリアのhanako@aaa.ne.jpへはテキストメールを送信し、非同一キャリアのjiro@bbb.ne.jpとsaburo@ccc.comへはＨＴＭＬメールを送信するものとする。送信履歴によるＨＴＭＬメールは図７（ｃ）のようになる。

図８は、メールのヘッダ情報のうち主として宛先情報について、その本実施の形態での変換前、変換後送信時、および送信後のそれぞれの内容をまとめて示した図である。テキストメールは同一キャリアの宛先メールアドレス宛にのみ送信する。しかし、このテキストメールのヘッダから他の宛先メールアドレスを完全に削除するのは妥当でない。Ｔｏ、Ｃｃについて、同報通信の受信者は自分以外の誰に送付されているかの情報は残す必要があるからである。ＨＴＭＬメールについても非同一キャリアの宛先メールアドレス宛にのみ送信するが、同様の要請がある。

そこで本実施の形態では、端末は、テキストメールおよびＨＴＭＬメールにおいて、ヘッダ情報の修正を行う。すなわち、送信を抑止する宛先メールアドレスに対して、送信抑止属性として特定の文字列からなる送信抑止フラグを付加する。送信抑止のためには、そのアドレスを削除するのではなく、予め定めた特定の文字列を（ここでは文字列"Ｅｘｃ"）を、宛先情報Ｔｏ、Ｃｃ、Ｂｃｃに付加する。ここでの「特定の文字列」はExclusion（除外）の省略形を採用しているが、これに限るものではない。また、必ずしも複数の文字である必要もない。

端末は、送信完了後に、送信履歴として残す目的で当該メールの宛先から当該フラグ（文字列"Ｅｘｃ"）を削除する。端末における送信履歴として、テキストメールとＨＴＭＬメールのいずれを残すか、両方を残すかは任意に決定することができる。ユーザが選択的に設定できるようにしてもよい。送信抑止フラグの付加処理のため、メール作成時の宛先書式では、複数の宛先メールアドレスを「,」で区切らずに、個々に「To 」などを設定するようにすることが好ましい。ただし、後述する変形例では複数の宛先メールアドレスを「，」で区切る形式で問題ない。

このように宛先に送信抑止フラグの付加されたメールを受信したメールサーバにおいては、当該送信抑止フラグの付加された宛先メールアドレスは送信対象から除外される。Ｂｃｃについては、従来どおり、宛先情報全部を削除する。

図９Ａは、宛先として２つのメールアドレスを含む絵文字入りメールの送信時の端末とサーバ間のやりとりを示すシーケンス図である。いま、キャリアＡに属する端末１１から、同じくキャリアＡに属する端末１２およびキャリアＢに属する端末２１に同報通信される場合を例とする。

端末１１はそのユーザの操作に応じて、端末１２，２１宛の絵文字入りメール（テキストメール）を作成する（Ｓ１１）。ついで、このテキストメールは同一キャリアと非同一キャリアの宛先メールアドレスが混在するものなので、このテキストメールのヘッダの修正を行う（Ｓ１２）。本実施の形態におけるこのヘッダの修正は、上述したような宛先情報の修正（すなわち送信抑止属性の付加）である。修正後のテキストメールはキャリアＡのメールサーバ１３へ送信される（Ｓ１３）。

このテキストメールを受信したキャリアＡのメールサーバ１３は、当該宛先情報を元に戻す修正（すなわち送信抑止属性の除去）を行い（Ｓ１８）、その後端末１２へメール着信があったことを知らせる着信通知を行う（Ｓ１９）。さらに、メールサーバ１３は、端末１２からのメールの送信を要求する送信要求に応じて（Ｓ２０）、当該修正後のテキストメールを端末１２へ送信する（Ｓ２１）。ステップＳ２０の要求は、通常、着信通知を受けた端末により自動で行われる。

端末１１は、また、ステップＳ１１で作成されたテキストメールを、上述したように、対応するＨＴＭＬメールに変換する（Ｓ１４）。ついで、そのヘッダの修正を行う（Ｓ１５）。本実施の形態におけるこのヘッダの修正は上述したような宛先情報の修正（すなわち送信抑止属性の付加）である。修正後のＨＴＭＬメールはキャリアＡのメールサーバ１３を介して（Ｓ１６）キャリアＡのメールゲートウェイ１５へ転送される（Ｓ２２）。このＨＴＭＬメールを受信したキャリアＡのメールゲートウェイ１５は、当該宛先情報を元に戻す修正（すなわち送信抑止属性の除去）を行う（Ｓ２３）。さらに、キャリアＢのメールゲートウェイ２５を経由して（Ｓ２４）、キャリアＢのメールサーバ２３へＳＭＴＰ通信される（Ｓ２５）。その後、端末１１は送信履歴を保存する（Ｓ１７)。この際、端末１１はその保存対象のメールに付加された送信抑止属性の除去を行ってもよい。

キャリアＢのメールゲートウェイ２５からＨＴＭＬメールを受信したキャリアＢのメールサーバ２３は、キャリアＢの端末２１へ着信通知を行う（Ｓ２６）。メールサーバ２３は、端末２１からの要求に応じて（Ｓ２７）、当該修正後のＨＴＭＬメールを端末２１へ送信する（Ｓ２８）。

この例では、ステップＳ１３の後にステップＳ１４を行うものとしたが、ステップＳ１４をステップＳ１３の前に実行してもよい。また、ステップＳ１３とＳ１５の順序も逆であってもよい。

図９Ｂに、図９Ａのシーケンスの変形例を示す。図９Ａと同一の処理には同一の参照符号を付して、重複した説明は省略する。この変形例では、キャリアＡのメールゲートウェイ１５で実行したヘッダ修正ステップ（Ｓ２３）と同じ処理を、ヘッダ修正ステップＳ２３ａとして、キャリアＡメールサーバ１３が実行する。キャリアＡメールサーバ１３はこの修正後のＨＴＭＬメールをキャリアＡのメールゲートウェイ１５へ転送する（Ｓ２２ａ）。メールゲートウェイ１５はそのＨＴＭＬメールをそのままキャリアＢのメールゲートウェイ２５へＳＭＴＰ通信する（Ｓ２４）。以後の処理は、図９Ａと同じである。

次に、図１０に端末において作成されたメールを送信するメール送信処理の処理手順の一例を示す。この処理は端末の制御部を構成するＣＰＵ１１（図３）が記憶部１０２内の上述したメーラーおよびメール変換プログラムを読み出して実行することにより実現される。

制御部は、作成されたメール（テキストメール）に絵文字（絵文字コード）が含まれているかどうかをチェックする（Ｓ３１）。含まれていなければ、後述するステップＳ３４へ移行する。

絵文字が含まれていれば、そのメールの宛先（Ｔｏ，Ｃｃ，Ｂｃｃ）を確認する（Ｓ３２）。これは、送信端末のキャリアと宛先メールアドレスのキャリアが一致するか否かを確認するキャリア判定である。宛先が同一キャリア宛のみの場合（Ｓ３３，Ｙｅｓ）、そのテキストメールをメールサーバへ送信する（Ｓ３４）。

宛先が非同一キャリア宛のみである場合（Ｓ３６，Ｙｅｓ）、当該絵文字の画像ファイルを組み込んだＨＴＭＬメールを作成し（Ｓ３７）、上記ステップＳ３４へ移行する。

宛先が同一キャリア宛のみでなく、非同一キャリア宛のみでもない、すなわち、同一キャリア宛と非同一キャリア宛が混在する場合、ステップＳ３８へ移行する。ステップＳ３８では、上述のとおり、特定の宛先メールアドレスに対して送信抑止属性を付加することにより、送信対象のテキストメールのヘッダを修正する（Ｓ３８）。ついで、この修正後のテキストメールをメールサーバへ送信する（Ｓ３９）。さらに、テキストメールから対応するＨＴＭＬメールを作成し（Ｓ４０）、そのヘッダを修正する（Ｓ４１）。ついで、この修正後のＨＴＭＬメールをメールサーバへ送信する（Ｓ４２）。その後、通信履歴として保存する対象となるメール（テキストメールおよびＨＴＭＬメールの少なくとも一方）のヘッダを元に戻し（Ｓ４３）、ステップＳ３５へ移行する。

ステップＳ３５では送信されたメールを送信履歴として保存する。テキストメールとＨＴＭＬメールの両方を送信した場合に、いずれを保存するか両方を保存するかは予め設定しておくことができる。ユーザが選択可能に設定できるようにしてもよい。

図１１は、図１０のステップＳ３２に示した宛先確認の第１の例を示したフローチャートである。

制御部は、まず、宛先メールアドレスのドメイン名に自キャリアのドメイン名を含むかどうかをチェックする（Ｓ５１）。宛先メールアドレスが複数存在する場合には、その一つを取り出してチェックする。自キャリアのドメイン名を含む場合には、「同一キャリア」と判定する（Ｓ５２）。自キャリアのドメイン名を含まない場合には、「非同一キャリア」と判定する（Ｓ５３）。すべての宛先メールアドレスについて（Ｓ５４）、このような処理を繰り返して実行する。

図１２は、図１０のステップＳ３２に示した宛先確認の第２の例を示したフローチャートである。

同一キャリアか否かは、宛先メールアドレスが自キャリアのドメイン名を含むか否かのみでは判断できない場合もありうる。例えば、キャリアの合併や吸収などでドメイン名が変わったが、メールシステムが引き継がれる場合等である。また、テキストメールとＨＴＭＬメールのいずれを送信するかを、宛先メールアドレスのドメイン名だけでなく、サブドメイン名、あるいは、メールアドレス全体も含めて、判断したい場合もある。例えば、ある宛先ユーザがＨＴＭＬメールを受信することを嫌っていることを送信者が知っている場合に、そのような宛先メールアドレスについてＨＴＭＬメールの送信を行わないようにすることができれば好ましい。また、特定の宛先（親しい友人アド）にだけはＨＴＭＬメールに変換し、他の宛先のユーザには文字化けしても気にしないというような場合もありうる。サブドメイン名やメールアドレス全体も含めた判断は、厳密な意味では「キャリア判定」ではないが、便宜上、キャリアの判定と同視する。

そこで、図１２の処理では、図１３に例示するようなチェックリスト７０を用いる。このチェックリスト７０は、絵文字入りテキストメールをＨＴＭＬメールに変換して送信することをデフォルトとすることを前提として、ＨＴＭＬメールへの変換を拒否する個別のドメイン名やメールアドレス等を設定する拒否フィルタ（Deny Filter）７１と、処理されたドメイン名についてＨＴＭＬメールへの変換を許可する個別のメールアドレスを設定する許可フィルタ（Allow Filter）７２とを含んでいる。チェックリスト７０は端末の記憶部１０２内に追加、更新可能に保存される。このようなチェックリスト７０の機能は、端末内のアドレス帳（電話帳）において、通信相手毎に個別に設定できるようにしてもよい。

図１２の処理では、まず、宛先メールアドレスをチェックリスト７０の拒否フィルタ７１内に指定された変換処理対象のドメイン名等の項目と比較する（Ｓ６１）。宛先メールアドレスが複数存在する場合には、その一つを取り出してチェックする。宛先メールアドレスが拒否フィルタ７１内のいずれかの項目と一致した場合（Ｓ６２，Ｙｅｓ）、「同一キャリア」と判定する（Ｓ６３）。一致する項目が存在しなかった場合、その宛先メールアドレスをチェックリスト７０内の許可フィルタ７２内の変換許可対象と比較する（Ｓ６４）。一致する項目が存在しなければ、ステップＳ６３へ移行し、当該宛先メールアドレスは「同一キャリア」と判定する。一致する項目が存在した場合、当該宛先メールアドレスは「非同一キャリア」と判定する（Ｓ６６）。すべての宛先メールアドレスについて（Ｓ６７）、このような処理を繰り返して実行する。

図１４は、図９Ｂの処理に関して、自キャリアの端末から送信メールを受信したメールサーバにおける本発明特有の処理を説明するための手順例を示している。図９Ａに示した処理に関するメールゲートウェイの処理も同様である。

メールサーバは、メールの送信端末から、宛先に送信抑止属性の付加されたメール（シンプルメールまたはＨＴＭＬメール）を受信した場合（Ｓ７１）、それらの宛先（Ｔｏ，Ｃｃ，Ｂｃｃ）については送信対象から除外する（Ｓ７２）。ついで、送信用メールのヘッダ内の宛先に付加された送信抑止属性としてのフラグを削除する（Ｓ７３）。また、従来通り、送信用メールにＢｃｃ欄があればその全体を削除する（Ｓ７４）。このようにして修正された後の送信用メールを、ステップＳ７２で除外された以外の送信対象の宛先のすべてに対して順次、当該受信側のメールサーバへ送信する（Ｓ７５）。

図１５〜図１７により、本実施の形態における送信抑止属性の変形例を説明する。図１５，図１６は、宛先にＣｃ５６、Ｂｃｃ５７を含むテキストメールおよびＨＴＭＬメールのデータ構造例を示している。図１５，図１６において、それぞれ図５，図６に示したと同じ要素には同じ参照符号を付して、重複した説明は省略する。上記の説明において、送信抑止属性は送信端末において作成された送信メールのヘッダ内の個々の宛先メールアドレスに対して付加する例を説明した。これに対して、図１５，図１６に示すように、送信端末では、作成したテキストメールおよびＨＴＭＬメールにおいて、ヘッダ内の宛先情報自体は変更することなく、宛先情報で指定された宛先（To,Cc,Bcc）に対して、テキストメールの送信を抑止する宛先メールアドレスをまとめて指定する新たなヘッダ情報５４、および、ＨＴＭＬメールの送信を抑止する宛先メールアドレスをまとめて指定する新たなヘッダ情報５５を追加する。すなわち、送信端末では、テキストメールにもＨＴＭＬメールにも同じヘッダ情報５４，５５を付加して、サーバへ送信する。

これらを受信したサーバは、テキストメールについては、ヘッダ情報５４で指定されたメールアドレスについてその送信を抑止する。また、ＨＴＭＬメールについては、ヘッダ情報５５で指定されたメールアドレスについてその送信を抑止する。

なお、テキストメールとＨＴＭＬメールの送信は排他的なので、送信抑止のためのヘッダ情報５４，５５は一方のみを利用することも考えられる。例えば、ヘッダ情報５４のみを利用する場合、ヘッダ情報５４に指定されたメールアドレスについてはテキストメールの送信を抑止し、それ以外のメールアドレスについてはＨＴＭＬメールの送信を抑止する。

図１７に、この変形例に関して、自キャリアの端末から送信メールを受信したメールサーバにおける処理を説明するための手順例を示す。図９Ａに示した処理に関するメールゲートウェイの処理も同様である。

メールサーバは、メールの送信端末から、宛先に送信抑止属性としてのヘッダ情報５４，５５の付加されたメール（シンプルメールまたはＨＴＭＬメール）を受信した場合（Ｓ８１）、それぞれのメール種別について送信抑止属性の付加された宛先（Ｔｏ，Ｃｃ，Ｂｃｃ）についてはその送信対象から除外する（Ｓ８２）。ついで、送信用メールのヘッダに付加された送信抑止属性としてのヘッダ情報５４，５５を削除する（Ｓ８３）。また、従来通り、Ｂｃｃ欄があればその全体を削除する（Ｓ８４）。このようにして修正された後の送信用のテキストメールおよびＨＴＭＬメールを、それぞれについてステップＳ８２で除外された以外の送信対象の宛先のすべてに対して順次、当該受信側のメールサーバへ送信する（Ｓ８５）。

なお、この変形例では、送信抑止属性のヘッダ情報５４，５５はステップＳ８３で削除したが、宛先情報自体は何ら変更していないので、ヘッダ情報５４，５５はそのまま残していても受信側で特に問題はない。すなわちステップＳ８３は必須の処理ではない。

以上、本発明の好適な実施の形態について説明したが、上記で言及した以外にも種々の変形、変更を行うことが可能である。例えば、テキストメールからＨＴＭＬメールへの変換の要否の判定およびＨＴＭＬメールへの変換処理は、メールの送信端末側で行うようにしたが、メールサーバ側で行うようにしてもよい。また、ＨＴＭＬメールへの変換処理は送信側のメールゲートウェイで行ってもよい。

絵文字の画像ファイルとしては、ＧＩＦ、ＪＰＥＧ等、そのファイル形式は問わない。静止画を想定したが、動画（例えばアニメーションGIF）ファイルであってもよい。

上記実施の形態で説明した機能をコンピュータで実現するためのコンピュータプログラムおよびプログラムをコンピュータ読み取り可能に格納した記録媒体も本願発明に含まれる。プログラムを供給するための「記録媒体」としては、例えば、磁気記憶媒体（フレキシブルディスク、ハードディスク、磁気テープ等）、光ディスク（ＭＯやＰＤ等の光磁気ディスク、ＣＤ、ＤＶＤ等）、半導体ストレージなどを挙げることができる。

１１，１２，２１…携帯端末
１３，２３…携帯メールサーバ
１５，２５…メールゲートウェイ
１６…テキストメール
１７…ＨＴＭＬメール
３０…インターネット
４３…ＰＣ用メールサーバ
５０…テキスト
５１…文字列
６２…シンプルテキスト部
６３…テキスト部
６４…画像部
７０…チェックリスト

Claims (18)

1. 絵文字の画像データを特定する特殊表示用コードを含むメールを作成する機能を有するメール送信装置におけるメール送信方法であって、
   ユーザの操作に応じて作成された前記特殊表示用コードを含むテキストメールの宛先メールアドレスに基づき、当該宛先が特定の条件に合致するか否かを判断するステップと、
   前記特定の条件に合致すると判断された場合、前記テキストメールを、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールに変換するステップと、
   作成されたマークアップランゲージ形式メールを当該宛先メールアドレス宛に送信するステップと
   を備えたことを特徴とするメール送信装置におけるメール送信方法。
2. 前記宛先メールアドレスが複数存在する場合、各宛先メールアドレスについて前記特定の条件に合致するか否かを判断し、前記特定の条件に合致する宛先メールアドレスと前記特定の条件に合致しない宛先メールアドレスとが混在するとき、前記特定の条件に合致しない宛先メールアドレスに対してはテキストメールを送信し、前記特定の条件に合致する宛先メールアドレスに対してはマークアップランゲージ形式メールを送信する請求項１に記載のメール送信方法。
3. 前記特定の条件とは、前記特殊表示用コードを含むテキストメールについて受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されるか否かであり、前記特定の条件に合致するとは、前記特殊表示用コードを含むテキストメールについて受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されないことである請求項１または２に記載のメール送信方法。
4. 前記テキストメールおよびマークアップランゲージ形式メールにおいて、送信を抑止する宛先メールアドレスに対して、当該宛先に対して送信抑止属性を付加する請求項２に記載のメール送信方法。
5. 前記テキストメールまたは前記マークアップランゲージ形式メールを送信履歴として保存する際、前記送信抑止属性を削除して保存する請求項４に記載のメール送信方法。
6. 前記メールについて受信側で前記特定の条件に合致するか否かを判断するステップでは、前記宛先メールアドレスのドメイン名に基づいて判断を行う請求項３に記載のメール送信方法。
7. 前記メールについて受信側で前記特定の条件に合致するか否かを判断するステップでは、マークアップランゲージ形式メールへの変換を拒否または許可するリストに基づいて判断を行う請求項１に記載のメール送信方法。
8. 絵文字の画像データを特定する特殊表示用コードを含むメールを送信するメール送信プログラムであって、
   ユーザの操作に応じて作成された前記特殊表示用コードを含むテキストメールの宛先メールアドレスに基づき、当該宛先が特定の条件に合致するか否かを判断するステップと、
   前記特定の条件に合致すると判断された場合、前記テキストメールを、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールに変換するステップと、
   作成されたマークアップランゲージ形式メールを当該宛先メールアドレス宛に送信するステップと
   をコンピュータに実行させるメール送信プログラム。
9. 前記特定の条件とは、前記特殊表示用コードを含むテキストメールについて受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されるか否かであり、前記特定の条件に合致するとは、前記特殊表示用コードを含むテキストメールについて受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されないことである請求項８に記載のメール送信プログラム。
10. 絵文字の画像データを特定する特殊表示用コードを含むメールを作成する機能を有するメール送信装置であって、
    絵文字の画像データを格納した記憶手段と、
    ユーザによるメールの作成を支援するメール作成支援手段と、
    ユーザの操作に応じて作成された前記特殊表示用コードを含むテキストメールの宛先メールアドレスに基づき、当該宛先が特定の条件に合致するか否かを判断する判断手段と、
    前記特定の条件に合致すると判断された場合、前記テキストメールを、当該絵文字の画像データを組み込んだマークアップランゲージ形式メールに変換するメール変換手段と、
    作成されたマークアップランゲージ形式メールを当該宛先メールアドレス宛に送信するメール送信手段と
    を備えたことを特徴とするメール送信装置。
11. 前記判断手段は、前記宛先メールアドレスが複数存在する場合、各宛先メールアドレスについて前記特定の条件に合致するか否かを判断し、
    前記メール送信手段は、前記特定の条件に合致する宛先メールアドレスと前記特定の条件に合致しない宛先メールアドレスとが混在するとき、前記特定の条件に合致しない宛先メールアドレスに対してはテキストメールを送信し、前記特定の条件に合致する宛先メールアドレスに対してはマークアップランゲージ形式メールを送信する請求項１０に記載のメール送信装置。
12. 前記特定の条件とは、前記特殊表示用コードを含むテキストメールについて受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されるか否かであり、前記特定の条件に合致するとは、前記特殊表示用コードを含むテキストメールについて受信側で前記特殊表示用コードにより特定される絵文字と同一の画像データが表示されないことである請求項１０または１１に記載のメール送信装置。
13. 前記テキストメールおよびマークアップランゲージ形式メールにおいて、送信を抑止する宛先メールアドレスに対して、送信抑止属性を付加する送信抑止属性付加手段を備えた請求項１０に記載のメール送信装置。
14. 前記テキストメールまたは前記マークアップランゲージ形式メールを送信履歴として保存する際、前記送信抑止属性を削除して保存する請求項１１に記載のメール送信装置。
15. 前記判断手段は、前記宛先メールアドレスのドメイン名に基づいて判断を行う請求項１２に記載のメール送信装置。
16. 前記判断手段は、ＨＴＭＬメールへの変換を拒否または許可するリストに基づいて判断を行う請求項１０に記載のメール送信装置。
17. 受信したメールをそのメールに指定された宛先メールアドレス宛に転送するメールサーバであって、
    送信端末からメールを受信する手段と、
    前記受信したメールを、前記送信抑止属性が付加された宛先メールアドレスに対して送信することなく、他の宛先メールアドレス宛に転送する手段と
    を備えたメールサーバ。
18. 前記受信したメールのヘッダ情報に付加された送信抑止属性を削除する手段をさらに備えた請求項１７に記載のメールサーバ。

Images