JP2002358269A - メール通信システム - Google Patents

Abstract

(57)【要約】 【課題】 使い勝手のよいメール通信システムを提供す
る。 【解決手段】 メール通信システムに、電子メールの送
信元となる第１の通信端末と、この第１の通信端末から
送信される電子メールを少なくとも第１の部分と第２の
部分とに分割する分割手段と、前記電子メールの第１の
部分を蓄積する蓄積手段と、この蓄積手段に蓄積された
前記電子メールの前記第１の部分を印刷する印刷手段
と、前記電子メールの第２の部分を受信するとともに、
前記蓄積手段に蓄積されている第１の部分を前記印刷手
段から印刷する要求を出力する第２の通信端末とを備え
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はメール通信システム
に関し、例えば、インターネット接続サービスを実施し
ている携帯電話ネットワーク中の携帯電話機に対しイン
ターネット経由で電子メールを送信する場合などに用い
て好適なものである。

【０００２】

【従来の技術】従来、インターネット接続サービスを実
施している携帯電話ネットワークでは、インターネット
経由で到達した電子メールの内容を携帯電話機のディス
プレイ画面で見ることができる。

【０００３】インターネット上の電子メールと異なり、
携帯電話機で電子メールの内容を受信する場合には、所
定の着信音やバイブレーションによって電子メールの着
信が当該携帯電話機のユーザ（携帯者）に直ちに伝えら
れるため、電子メールは、ほぼリアルタイムな通信手段
となり得る。

【０００４】

【発明が解決しようとする課題】ところが、コンパクト
性に関する要求水準の高い携帯電話機では、そのディス
プレイ画面の大きさには一定の上限があり、電子メール
を読む場合の使い勝手は必ずしも良好ではない。一例と
して、携帯電話機の本体のサイズは、縦１３０ｍｍ程
度、幅４０ｍｍ程度、厚さ２０ｍｍ程度であるため、そ
のディスプレイ画面の大きさは、最も大きく設計したと
しても、自ずとこの程度のサイズに制限され、長文の電
子メールを快適に読むには不十分である。

【０００５】また、電子メールには、その送信者が、テ
キストデータからなるテキストファイルにテキストデー
タ以外のデータ（すなわち、バイナリデータ）からなる
バイナリファイルを添付（アタッチ）して送信する場合
がある。同一の携帯電話ネットワーク内では添付ファイ
ル（バイナリファイル）の送信、受信を認めている携帯
電話事業者もあるが、インターネット経由で添付ファイ
ルを受信することを認めている携帯電話事業者は、現在
のところ皆無である。

【０００６】そして、このような添付ファイル（ワープ
ロ文書ファイル、画像ファイル、音声ファイル、実行形
式ファイルなど）の添付されたインターネット経由の電
子メールに対し、携帯電話事業者は、携帯電話ネットワ
ーク内のメールサーバで当該添付ファイルを削除してし
まうポリシーを取っていることが多い。

【０００７】添付ファイルはテキストファイルよりもサ
イズの大きなものが多いため、このようなポリシーを取
ることで、メールサーバの処理能力にかかる負荷を大幅
に軽減するとともに、搭載している限られた記憶資源の
１携帯電話ユーザ当たりの消費量を低減し、より多くの
携帯電話ユーザへのメール着信に対応することを意図し
たものであると考えられる。

【０００８】また、仮に削除しなかったとしても、携帯
電話機自体の性能が、そのような添付ファイルを取り扱
うには全く不十分である場合が多いことを見越してのポ
リシーであるとも考えられる。

【０００９】しかしながら携帯電話ユーザの立場からす
ると、自身に宛てて送信された電子メールの添付ファイ
ルが、携帯電話ネットワーク内で勝手に削除されては困
ることも多い。

【００１０】

【課題を解決するための手段】かかる課題を解決するた
めに、第１の発明のメール通信システムは、（１）電子
メールの送信元となる第１の通信端末と、（２）この第
１の通信端末から送信される電子メールを少なくとも第
１の部分と第２の部分とに分割する分割手段と、（３）
前記電子メールの第１の部分を蓄積する蓄積手段と、
（４）この蓄積手段に蓄積された前記電子メールの前記
第１の部分を印刷する印刷手段と、（５）前記電子メー
ルの第２の部分を受信するとともに、前記蓄積手段に蓄
積されている第１の部分を前記印刷手段から印刷する要
求を出力する第２の通信端末とからなる。

【００１１】また、第２の発明のメール通信システム
は、（１）電子メールの送信元となる第１の通信端末
と、（２）この第１の通信端末から送信される電子メー
ルを少なくとも第１の部分と第２の部分とに分割する分
割手段と、（３）前記電子メールの第１の部分を蓄積す
る蓄積手段と、（４）この蓄積手段に蓄積された前記電
子メールの前記第１の部分を印刷可能な複数の印刷手段
と、（５）前記電子メールの第２の部分を受信するとと
もに、前記蓄積手段に蓄積されている第１の部分を前記
複数の印刷手段のうちの特定の印刷手段から印刷する要
求を出力する第２の通信端末と、（６）この第２の通信
端末から前記電子メールの前記第１の部分の印刷要求が
出力されたとき、前記蓄積手段に蓄積されている前記電
子メールの前記第１の部分を、前記第２の通信端末から
要求された特定の印刷手段に送信する制御手段とからな
る。

【００１２】さらに、第３のメール通信システムは、
（１）第１の部分とこの第１の部分に関連する第２の部
分からなる電子メールの送信元となる第１の通信端末
と、（２）前記電子メールの第１の部分を蓄積する蓄積
手段と、（３）この蓄積手段に蓄積された前記電子メー
ルの前記第１の部分を印刷する印刷手段と、（４）前記
電子メールの第２の部分を受信するとともに、前記蓄積
手段に蓄積されている第１の部分を前記印刷手段から印
刷する要求を出力する第２の通信端末とからなる。

【００１３】

【発明の実施の形態】（Ａ）実施形態 以下、本発明にかかるメール通信システムの実施形態に
ついて説明する。

【００１４】本実施形態は、携帯電話機（３２など）に
おいてそのディスプレイ部に画面表示できない電子メー
ルのファイル（主として添付ファイル）につき、随所に
配置された遠隔プリンタ端末（３３など）を用いて画面
表示や、印刷出力することを特徴とする。

【００１５】（Ａ−１）第１の実施形態の構成 本実施形態の通信システム１０の全体構成例を図１に示
す。

【００１６】図１において、当該通信システム１０は、
インターネット１１と、携帯電話ネットワーク１２、１
３と、プリンタネットワーク１４とを備えている。

【００１７】このうちインターネット１１には、メール
配送サーバ２０，２１が含まれ、注目する電子メールＭ
Ｅ１の送信元となる送信元端末３０が接続されている。

【００１８】当該送信元端末３０は、例えば、メーラ
（ＭＵＡ）を搭載したパーソナルコンピュータなどであ
ってよい。

【００１９】また、前記携帯電話ネットワーク１２には
メールボックスサーバ２２が含まれ、携帯電話機３１が
接続されている。同様に、携帯電話ネットワーク１３に
はメールボックスサーバ２３が含まれ、携帯電話機３２
が接続されている。

【００２０】これらの携帯電話ネットワーク１２，１３
は、それぞれ異なる携帯電話事業者により、異なるポリ
シーに基づいて運営されている。したがって、各メール
ボックスサーバ２２，２３の機能や携帯電話機３１，３
２の機能も、相違するのが普通である。

【００２１】メールボックスサーバ２２，２３の機能
や、ＭＴＡ、ＭＵＡ等によって決定される各携帯電話ネ
ットワーク１２，１３内の電子メールシステムの内容
は、基本的には各携帯電話事業者が自由に決定すること
ができるが、インターネット１１に接続する以上、あま
りに特異な電子メールシステムを構築してしまうと、イ
ンターネット１１との接続が正常に行えなくなる可能性
が高いため、通常は、インターネット１１と同じか、イ
ンターネット１１に類似した電子メールシステムを構築
することになるものと考えられる。

【００２２】本実施形態の通信システム１０で特徴的な
点は、以上のような構成に加え、プリンタネットワーク
１４が存在することである。当該プリンタネットワーク
１４の電子メールシステムも、携帯電話ネットワーク１
２，１３と同様、インターネット１１に類似したものと
なる。

【００２３】当該プリンタネットワーク１４はメールボ
ックスサーバ２４を含み、遠隔プリンタ端末３３を接続
している。

【００２４】当該遠隔プリンタ端末３３は、基本的に
は、メールボックスサーバ２４から取得したデータを印
刷出力する機能を備えた装置であるが、通常、１つのプ
リンタネットワーク１４中には多数の遠隔プリンタ端末
（その１つが当該遠隔プリンタ端末３３）が存在し、各
遠隔プリンタ端末は、例えば、駅の構内や、コンビニエ
ンスストアなどに、固定的に配置される。

【００２５】高水準のコンパクト性が求められる携帯電
話機３１，３２などと比較すると、当該遠隔プリンタ端
末３３はサイズも大きく、十分なユーザインタフェース
を提供することができる。

【００２６】なお、図１中、Ｕ１は送信元端末３０を操
作して電子メールＭＥ１を送信するユーザを示し、Ｕ２
は携帯電話機３１を携帯するユーザを示し、Ｕ３は携帯
電話機３２を携帯するユーザを示す。

【００２７】図１の各構成要素のうち送信元端末３０の
主要部の構成例は、図１０に示すとおりである。

【００２８】（Ａ−１−１）送信元端末の構成例 図１０において、当該送信元端末３０は、送受信部４５
と、ディスプレイ部４６と、メール処理部４７と、記憶
部４８と、操作部４９とを備えている。

【００２９】このうちディスプレイ部４６は、例えば１
７インチ程度のサイズを持つビットマップディスプレイ
であり、メール処理部４７は、前記メーラを搭載した部
分である。

【００３０】また、記憶部４８は、電子メールＭＥ１
（Ｆ１、Ｆ２）の本体を記憶しているメモリ（またはハ
ードディスク）で、操作部４９は、マウスなどのポイン
ティングデバイスやキーボードなどから構成されてい
る。

【００３１】ここで、「ＭＥ１（Ｆ１、Ｆ２）」の中の
「（Ｆ１、Ｆ２）」部分は、電子メールＭＥ１には、図
１１に示す本文メッセージＰＦ１（このＰＦ１は、Ｆ１
に対応）と、ＰＦ２（このＰＦ２は、Ｆ２に対応）が含
まれていることを示す。

【００３２】ユーザＵ１は、ディスプレイ部４６の表示
画面を目視しながら、当該操作部４９を操作することに
より、所望の電子メールＭＥ１を構成して送信すること
ができる。

【００３３】現在の電子メールのほとんどは、添付ファ
イル（アタッチファイル）を添付するか否かにかかわら
ず、基本的に、ＲＦＣ２０４５〜２０４７に規定されて
いるＭＩＭＥ規格に対応しているので、ここでは、前記
電子メールＭＥ１も、メール処理部４７に搭載している
メーラも、当該ＭＩＭＥ規格にしたがったものであると
する。

【００３４】ＭＩＭＥ規格にしたがう場合、ヘッダおよ
び添付ファイルを含む電子メールＭＥ１の構造は、例え
ば、図１１に示すようになる。電子メールＭＥ１の本文
（ＰＴ１、ＰＴ２）の書式は、ユーザＵ１が自由に決定
し得るが、ヘッダの書式は予め規定されている。

【００３５】図１１において、電子メールＭＥ１のヘッ
ダ（ＭＩＭＥヘッダ）は、「フィールド名：フィールド
本体」の構造を持つフィールド行の連続である。図１１
中には、フィールドＦＤ１０〜ＦＤ２３を示し、基本的
にフィールド本体は省略してある。

【００３６】ただしFromフィールドＦＤ１２のフィール
ド本体には、当該ユーザＵ１（送信元端末３０）を指定
する送信者のメールアドレスとして「ＡＤＤ（Ｕ１）」
が記述され、ToフィールドＦＤ１５のフィールド本体に
は、当該電子メールＭＥ１の送信先であるユーザＵ３
（携帯電話機３２）を指定するメールアドレスとして
「ＡＤＤ（Ｕ３）」が記述され、CcフィールドＦＤ１６
のフィールド本体には、カーボンコピー（電子メールの
電子的なコピー）の送信先となるメールボックスサーバ
２４のメールアドレスとして「ＡＤＤ（２４）」が記述
されている。ドメイン名として当該メールボックスサー
バ２４を含むメールアドレスをCcフィールドなどに収容
した電子メールは、すべて当該メールボックスサーバ２
４に送達されるようにするとよい。

【００３７】なお、ここでは簡略のために、ＡＤＤ（Ｕ
１）、ＡＤＤ（Ｕ３）、ＡＤＤ（２４）という、実在し
ないメールアドレスを示したが、実際には、通常のメー
ルアドレスの表記（例えば、「ユーザ名＋ドメイン名」
など）にしたがった記述が行われることは当然である。

【００３８】また、図１１の例では、当該電子メールＭ
Ｅ１の主な送信先がユーザＵ３であり、副次的な送信先
がメールボックスサーバ２４であることを示すためにこ
のような記述となったが、必要ならば、ToフィールドＦ
Ｄ１５のフィールド本体にカンマやセミコロンで区切っ
て２つの送信先を記述してもかまわない。

【００３９】すなわち、「To：ＡＤＤ（Ｕ３），ＡＤＤ
（２４）」と記述し、CcフィールドＦＤ１６には有効な
記述を行わないようにしてもかまわない。

【００４０】また、図１１において、ＰＴ１やＰＴ２
は、電子メールＭＥ１の本文メッセージが記述される部
分である。このうちパートＰＴ１は、当該電子メールＭ
Ｅ１の本来的な本文（プレーンテキスト部分）を示し、
パートＰＴ２は、当該本来的本文に添付された添付ファ
イル（ここでは、画像ファイル）を示す。

【００４１】この電子メールＭＥ１の本文メッセージ
（本来的本文および添付ファイルの本文）が複数のパー
ト（ここでは、ＰＴ１、ＰＴ２の２パート）から構成さ
れていることは、Content-TypeフィールドＦＤ１８のフ
ィールド本体に「multipart」と記述されていることに
よっても示される。

【００４２】ここでは特に「multipart/mixed」とある
ことから、ユーザＵ３が当該電子メールＭＥ１を開くと
きには、２つのパートＰＴ１とＰＴ２を混合して開くよ
うに指示していることが分かる。

【００４３】また、当該Content-TypeフィールドＦＤ１
８中の変数boundaryは、本文メッセージの境界を指定す
る部分で、「boundary="ＢＤ１１"」は、当該変数bound
aryに、boundary文字列としてＢＤ１１を格納すること
を意味する。

【００４４】ここで、boundary文字列ＢＤ１１は、イン
ターネット１１上や携帯電話ネットワーク１３上で別個
の電子メールＭＥ１１（Ｆ１）、ＭＥ１２（Ｆ２）、及
びＭＥ２１（Ｆ１）、ＭＥ２２（Ｆ２）として転送され
得る本文メッセージＰＦ１とＰＦ２とを、メールを開く
際、送信先のメーラが正しくつなぎ合わせることができ
るように配置されるユニークな識別子である。

【００４５】すなわちメーラは、メールボックス内にあ
る多数のメールのなかから、当該boundary文字列ＢＤ１
１に着目して、つなぎ合わせるべき分割メール（ここで
は、例えば、ＭＥ１１（Ｆ１）、ＭＥ１２（Ｆ２））を
認識し、分割前のもとの電子メール（ここではＭＥ１
（Ｆ１、Ｆ２））を復元する。

【００４６】当該boundary文字列ＢＤ１１が配置されて
いる位置ＰＳ１、ＰＳ２が、各本文メッセージＰＦ１、
ＰＦ２の開始を示す位置である。

【００４７】メール処理部４７に搭載されているメーラ
は、電子メールＭＥ１のContent-TypeフィールドＦＤ１
８のフィールド本体に「multipart」と記述されている
ことに基づいて、当該電子メールＭＥ１（Ｆ１、Ｆ２）
を、２つの分割メールＭＥ１１（Ｆ１）とＭＥ１２（Ｆ
２）に分割する。

【００４８】また、電子メールＭＥ１のToフィールドＦ
Ｄ１５のフィールド本体に「ＡＤＤ（Ｕ３）」とあるこ
とから、これらの分割メールＭＥ１１（Ｆ１）とＭＥ１
２（Ｆ２）の送信先は、当該「ＡＤＤ（Ｕ３）」とな
る。

【００４９】さらに当該メーラは、当該電子メールＭＥ
１のCcフィールドＦＤ１６のフィールド本体に「ＡＤＤ
（２４）」とあることから、前記分割メールＭＥ１１の
電子的なコピーである分割電子メールＭＥ２１（Ｆ１）
と、分割メールＭＥ１２（Ｆ２）の電子的なコピーであ
る分割電子メールＭＥ２２（Ｆ２）を、当該「ＡＤＤ
（２４）」に宛てて送信する。

【００５０】なお、前記「ＭＥ１１（Ｆ１）」の中の
「（Ｆ１）」部分は、電子メールＭＥ１１が、図１１に
示す本文メッセージＰＦ１の内容を含んでいることを示
す。同様に、「ＭＥ１２（Ｆ２）」は、電子メールＭＥ
１２が、図１１に示す本文メッセージＰＦ２の内容を含
んでいることを示す。ＭＥ２１（Ｆ１）、ＭＥ２２（Ｆ
２）に関しても、これと同様である。

【００５１】したがって、送信元端末３０から送信され
た電子メールは、メール処理部４７に搭載されたＭＩＭ
Ｅ対応のメーラによって、すでに自動的に２つの分割メ
ールＭＥ１１（Ｆ１）およびＭＥ１２（Ｆ２）に分割さ
れており、各分割メールについて１つずつのカーボンコ
ピー電子メールも送信される。

【００５２】すなわち、電子メールＭＥ１１（Ｆ１）の
カーボンコピーがＭＥ２１（Ｆ１）であり、電子メール
ＭＥ２１（Ｆ１）のカーボンコピーがＭＥ２２（Ｆ２）
である。

【００５３】ただしこのとき、前記分割が自動的に行わ
れるものとすれば、当該送信元端末３０を操作するユー
ザＵ１は通常、１つの電子メールＭＥ１（Ｆ１、Ｆ２）
を、ユーザＵ３宛てに、そのカーボンコピーをメールボ
ックスサーバ２４宛てに送ったことしか意識していない
こともあり得る。

【００５４】また、図１１中、Content-Typeフィールド
ＦＤ１９に、「text/plain」とあるのは、本文メッセー
ジＰＴ１の形式が、プレーンテキストであることを意味
し、Content-TypeフィールドＦＤ２１に、「image/gi
f」とあるのは、本文メッセージＰＴ２の形式が、画像
データであることを意味する。

【００５５】ここでは、一例として、本文メッセージＰ
Ｔ２は、携帯電話機３２を携帯している営業担当者に顧
客の所在地までの道順などを示した地図であり、本文メ
ッセージＰＴ１には、当該地図に関する補足説明や当該
顧客の顧客情報などが記載されているものとする。

【００５６】次に、前記メール配送サーバ２０は、ＳＭ
ＴＰプロトコルなどのＭＴＡを搭載したサーバで、その
主要部の構成例は図２に示すとおりである。

【００５７】（Ａ−１−２）メール配送サーバ２０の構
成例 図２において、当該メール配送サーバ２０は、受信部４
０と、記憶部４１と、送信部４２と、ＭＩＭＥヘッダ解
析部４３とを備えている。

【００５８】このうち受信部４０は、インターネット１
１上の伝送路から前記電子メールＭＥ１を受信する部分
である。

【００５９】また、記憶部４１は、当該電子メールＭＥ
１をＭＩＭＥヘッダ解析部４３等の処理に必要な処理時
間だけ、一時的に蓄積する受信バッファメモリである。

【００６０】ＭＩＭＥヘッダ解析部４３は、図１１に示
したＭＩＭＥヘッダの内容を解析する部分である。

【００６１】本実施形態では上述したように、前記メー
ル処理部４７に搭載されているメーラが、電子メールＭ
Ｅ１の分割処理やカーボンコピー処理を実行するように
したが、必要に応じて、当該ＭＩＭＥ解析部４３がこれ
ら処理を実行するようにしてもよい。

【００６２】送信元端末３０から前記４つの分割メール
ＭＥ１１、ＭＥ１２、ＭＥ２１、ＭＥ２２を受信した当
該メール配送サーバ２０内のＭＩＭＥヘッダ解析部４３
は、各分割メールのToフィールドやCcフィールドの記述
をもとに、これらの分割メールを、送信部４２からイン
ターネット１１上の伝送路に送出する。

【００６３】当該メール配送サーバ２０から送出された
あと、通常、各分割メールＭＥ１１、ＭＥ１２、ＭＥ２
１、ＭＥ２２は、それぞれ別個の転送経路（メール配送
サーバ）を辿って送信先に接続されているメールボック
スサーバ（２３、２４）まで送達される。一般に、電子
メールの転送経路上に存在する各メール配送サーバ（例
えば、当該メール配送サーバ２０）は、前記Toフィール
ドやCcフィールドの記述だけでなく、自身に接続されて
いる各伝送路（物理リンク）の輻輳度などの情報やラウ
ンドロビンなどの手順にしたがって、時々刻々と電子メ
ールを送出する伝送路を変化させるため、送信元および
送信先が同じ電子メールであっても、同じ伝送路に送出
されるとは限らないからである。

【００６４】なお、図１上に示したメールサーバ２１
も、ここでは、当該メール配送サーバ２０と同様なメー
ル配送サーバの１つであるものとする。

【００６５】ところで、本実施形態の構成上は、（最終
的に削除される分割メールＭＥ１２の送信は行われず）
前記分割メールＭＥ１１だけがメールボックスサーバ２
３に送達され、（最終的に削除される分割メールＭＥ２
１の送信は行われず）前記分割メールＭＥ２２だけがメ
ールボックスサーバ２４に送達されたほうが、後で実行
する不必要なファイルを削除する処理を省くことができ
て好都合なのであるが、現状の電子メールシステムはそ
のような機能は備えておらず、自動的にこれら４つの分
割メールＭＥ１１、ＭＥ１２、ＭＥ２１、ＭＥ２２が送
信されることになる。

【００６６】もちろん、必要ならば、前述のケースでは
前記分割メールＭＥ１１だけがメールボックスサーバ２
３に送達されるとともに、前記分割メールＭＥ２２だけ
がメールボックスサーバ２４に送達されるような電子メ
ールシステム（しかも、ＭＥ１１とＭＥ２２の対応関係
は保持できる電子メールシステム）を構築するようにし
てもよい。

【００６７】ただし本実施形態では、実現の容易性を確
保するため、現在、インターネット上で実際に運用され
ている電子メールシステムを、できるだけ改変すること
なく使用することとするので、このケースでは、４つの
分割メールＭＥ１１、ＭＥ１２、ＭＥ２１、ＭＥ２２が
送信される。

【００６８】次は、インターネット１１を経由して（必
要ならば携帯電話ネットワーク１３内のメール配送サー
バ（このサーバも、前記メール配送サーバ２０と同じで
あってよい）も経由して）、前記分割メールＭＥ１１と
ＭＥ１２を受け取るメールボックスサーバ２３の主要部
の構成例を図３に示す。

【００６９】（Ａ−１−３）メールボックスサーバ２３
の構成例 図３において、当該メールボックスサーバ２３は、受信
部５１と、添付ファイル削除部５２と、本体ファイル蓄
積部５３と、記憶部５４と、メールボックス処理部５５
と、送信部５６とを備えている。

【００７０】このうち受信部５１は、前記２つの分割メ
ールＭ１１（Ｆ１）とＭＥ１２（Ｆ２）を受信する部分
で、記憶部５４は、前記記憶部４１と同様な受信バッフ
ァメモリである。

【００７１】また、添付ファイル削除部５２は、メッセ
ージ形式がプレーンテキスト以外の電子メール（分割メ
ール）をすべて削除する部分である。したがって、分割
メールＭＥ１１（Ｆ１）とＭＥ１２（Ｆ２）を受信した
場合、分割メールＭＥ１２はそのメッセージ形式が、図
１１に示したContent-TypeフィールドＦＤ２１由来の画
像データ（「image/gif」）であることから、当該添付
ファイル削除部５２によって削除され、分割メールＭＥ
１１（Ｆ１）だけが本体ファイル蓄積部５３に蓄積され
る。

【００７２】本体ファイル蓄積部５３は、前記記憶部４
８と異なり、携帯電話機３２からメールの受信要求が到
来するまで、当該分割メールＭＥ１１（Ｆ１）を保管す
る部分である。当該本体ファイル蓄積部５３は通常、物
理的には記憶部４８よりもかなり大きい記憶容量を備え
た記憶装置であり、論理的には各携帯電話ユーザ（例え
ばユーザＵ３）ごとに区分されたメールボックスを多数
備えている。

【００７３】そのうち、ユーザＵ３のためのメールボッ
クスをＭＢＵ３とすると、当該電子メールＭＥ１１（Ｆ
１）は、当該メールボックスＭＢＵ３に格納されること
になる。

【００７４】一般的に各携帯電話事業者は、当該メール
ボックスの物理的なサイズ、すなわち記憶容量に、一定
の上限を設定するものと考えられる。

【００７５】また、メールボックス自体のサイズに上限
を設定するだけでなく、各メールボックスに収容する各
電子メールのサイズ（ここでは、電子メールＭＥ１（Ｆ
１）のサイズ）にも物理的な上限を設定している。

【００７６】当該電子メールサイズの上限は広く知られ
ており、例えば、ある携帯電話事業者ＢＡ１では、送
信、受信ともに全角で最大２５０文字までであり、別な
携帯電話事業者ＢＡ２の場合には、受信は全角で最大２
０００文字までで、送信は最大２５０文字程度となって
いる。

【００７７】一般に、電子メールのサイズがこの上限を
超過すると、超過した部分は削除されてしまうため、携
帯電話ユーザ（例えばＵ３）は、超過した部分を読むこ
とはできない。携帯電話ネットワーク１３を運営する携
帯電話事業者がＢＡ１であれば、例えば５００文字の電
子メールを受信した場合、最初の２５０文字までは読む
ことができるが、残りの２５０文字は読むことができな
い。

【００７８】当該本体ファイル蓄積部５３に接続されて
いるメールボックス処理部５５は、携帯電話ユーザが自
身のメールボックスに蓄積された電子メールを取り出す
ためのプロトコル、または、携帯電話機がアベイラブル
であればサーバ主導で着信した電子メールを該当する携
帯電話機に送り付けるためのプロトコルを搭載している
部分である。

【００７９】本体ファイル蓄積部５３に新たな電子メー
ル（例えばＭＥ１１（Ｆ１））が格納されたとき、その
電子メールの送信先となる携帯電話機（例えば３２）に
対し所定の通知信号を送信することで、着信音を発生さ
せたり、バイブレーションを発生させたりして、当該電
子メールの着信をほぼリアルタイムで携帯電話ユーザ
（ここではＵ３）に伝える機能も、当該メールボックス
処理部５５が装備している。

【００８０】また、前記受信部５１を介して、携帯電話
ユーザからの電子メール取出し要求（Ｓ９）を受け取る
と、当該メールボックス処理部５５は、ユーザ認証など
の所定の処理を実行した後、正当なユーザが求める電子
メールを本体ファイル蓄積部５３内の該当メールボック
スから取出し、送信部５６を介して当該ユーザの携帯電
話機に送信する機能をも有する。

【００８１】後述するように、当該メールボックスＭＢ
ＵＸが送信先ユーザＵ３に対応付けられたものである場
合、ユーザ認証は、予め当該送信先ユーザＵ３に付与し
てあるパスワードなどを使用して行うことができるが、
当該メールボックスＭＢＵＸが送信元ユーザＵ１に対応
付けられたものである場合には、そのようなパスワード
を使用することは困難であると考えられる。したがって
その場合には、電子メール（ＭＥ２１、）ＭＥ２２が収
容している図１１に示すToフィールドＦＤ１５の内容
（ユーザＵ３の電子メールアドレス）を利用して、当該
認証を実行するようにするとよい。

【００８２】なお、携帯電話ネットワーク１２に属する
メールボックスサーバ２２の機能も、基本的には当該メ
ールボックスサーバ２３と同じである。

【００８３】当該携帯電話機３１、３２の主要部の構成
例は、例えば、図７または図８に示す通りである。携帯
電話機３２の機能は、当該携帯電話機３２が属する携帯
電話ネットワーク１３の携帯電話事業者に応じても異な
り、同じ携帯電話事業者であっても、携帯電話機メーカ
が相違すること等によっても異なる。

【００８４】また、このような携帯電話機の機能は、メ
ールボックスサーバの機能と対称的な関係を持つことを
要するので、ここでは、図７は携帯電話機３１を示し、
図８は携帯電話機３２を示すものとして説明を進める。

【００８５】また、携帯電話機３１の説明では、前記電
子メールＭＥ１１（Ｆ１）は、メールボックスサーバ２
２を介して、当該携帯電話機３１に着信したものとして
説明する。

【００８６】（Ａ−１−４）携帯電話機３１の構成例 図７において、携帯電話機３１は、送受信部６１と、操
作部６２と、メール処理部６３と、ディスプレイ部６４
とを備えている。

【００８７】このうち送受信部６１は、アンテナや各種
の高周波回路に加え、例えばＣＤＭＡ（符号分割多元接
続）方式の処理回路などを装備した部分で、図示しない
基地局を介して、メールボックスサーバ２２とのあいだ
で上述した電子メール取出し要求Ｓ９の送信や、電子メ
ールＭＥ１１（Ｆ１）の受信などを行う。

【００８８】また、メール処理部６３は、所定の携帯電
話用のメーラを搭載した部分で、ディスプレイ部６４
は、受信した電子メール（例えばＭＥ１１（Ｆ１））の
内容をユーザＵ２が目視するための画面表示を行う部分
で、操作部６２は、電子メールの受信に必要な各種の操
作を行う部分である。

【００８９】この携帯電話機２２は、着信した電子メー
ルＭＥ１１（Ｆ１）の全部を完全に記憶するためのメモ
リを備えていないため、ユーザＵ２は、メールボックス
サーバ２２の本体ファイル蓄積部５３に蓄積されている
電子メールＭＥ１１（Ｆ１）を、少しずつ読み込むこと
により、メールを読むことになる。

【００９０】したがって当該携帯電話機３１では、メー
ルＭＥ１１（Ｆ１）を読んでいるあいだも携帯電話機３
１とメールボックスサーバ２２は通信を継続することが
必要で、その間、通信料金は積算されつづける可能性が
ある。

【００９１】携帯電話機では一般に、コンパクト性の要
求水準が高いため搭載できるメモリ容量の制限が厳しい
上、多機能化しているため、電子メールのために割り振
ることのできるメモリ容量はさらに少ない。したがっ
て、上述した携帯電話事業者ＢＡ２のように、最大２０
００文字までという携帯電話用の電子メールとしては比
較的サイズの大きなメールの受信を可能とする場合に
は、携帯電話機の構成は、当該携帯電話機３１のように
なる。

【００９２】これに対し、携帯電話機３２は図８に示す
ようにメモリ６５を搭載している。

【００９３】（Ａ−１−５）携帯電話機３２の構成例 図８において、携帯電話機３２は、送受信部６１と、操
作部６２と、メール処理部６３と、ディスプレイ部６４
に加え、当該メモリ６５を備えている。

【００９４】ここで、図７と同一の符号を付与した各構
成要素の機能は、基本的に携帯電話機３１と同じであ
る。

【００９５】したがって当該携帯電話機３２が前記携帯
電話機３１と相違する点は、メモリ６５を搭載している
点に限られる。

【００９６】当該メモリ６５は、着信した電子メールＭ
Ｅ１１（Ｆ１）の全部を完全に記憶するためのメモリで
ある。このメモリ６５に電子メールＭＥ１１（Ｆ１）の
内容を完全に読み込んでからユーザＵ３が当該電子メー
ルを読むようにすれば、当該携帯電話機３２では、ユー
ザＵ３が電子メールを読んでいるあいだ、メールボック
スサーバ２３との通信は継続する必要がなく、通信料金
はかからない。

【００９７】ただし当該メモリ６５の容量はわずかであ
るため、電子メールＭＥ１１（Ｆ１）の前半部分などし
か読めないということが起こる可能性は、携帯電話機３
１よりも高い。

【００９８】上述した携帯電話事業者ＢＡ１のように、
送信、受信ともに全角で最大２５０文字までに制限する
ケースでは、携帯電話機の構成は、当該携帯電話機３２
のようになる。

【００９９】一方、プリンタネットワーク１４内のメー
ルボックスサーバ２４の主要部の構成例は、図４に示
す。

【０１００】（Ａ−１−６）メールボックスサーバ２４
の構成例 図４において、当該メールボックスサーバ２４は、受信
部５１と、本体ファイル削除部７０と、添付ファイル蓄
積部７１と、記憶部５４と、メールボックス処理部５５
と、送信部５６とを備えている。

【０１０１】このうち図３と同じ符号を付与した各構成
要素の機能は、基本的にメールボックスサーバ２２と同
じである。したがって、当該メールボックスサーバ２４
が前記メールボックスサーバ２３と相違する点は、本体
ファイル削除部７０と、添付ファイル蓄積部７１に関連
する部分に限られる。

【０１０２】すなわち当該メールボックスサーバ２４で
は、前記メールボックスサーバ２３が削除した添付ファ
イルを削除せずに添付ファイル蓄積部７１に格納し、反
対に、前記メールボックスサーバ２３が蓄積した本体フ
ァイル（Ｆ１等）は削除する。

【０１０３】したがって、当該メールボックスサーバ２
４では、受信したカーボンコピーにかかる分割メールＭ
Ｅ２１（Ｆ１）とＭＥ２２（Ｆ２）のうち、本体ファイ
ル（Ｆ１）に対応する分割メールＭＥ２１（Ｆ１）は本
体ファイル削除部７０で削除され、添付ファイル蓄積部
７１には、添付ファイルに対応する分割メールＭＥ２２
（Ｆ２））だけが蓄積されることになる。

【０１０４】当該分割メールＭＥ２２（Ｆ２）は、添付
ファイル蓄積部７１内に設けられたメールボックスＭＢ
ＵＸに格納される。

【０１０５】当該添付ファイル蓄積部７１には、プレー
ンテキストに比べてサイズの大きいことが多いバイナリ
形式のデータだけが格納されることになるため、もしも
携帯電話ネットワーク１３と同数のユーザを収容するの
なら、当該添付ファイル蓄積部７１の物理的な記憶容量
は、前記本体ファイル蓄積部５３よりも大きくするのが
望ましい。

【０１０６】また、当該添付ファイル蓄積部７１に設け
られるメールボックス（ここではＭＢＵＸ）を送信元ユ
ーザ（ここではＵ１）に対応付けるか、送信先ユーザ
（ここではＵ３）に対応付けるかは、メールボックスに
格納された添付ファイルが必ず取出されるとは限らない
点を考慮すると、課金の問題ともからんでくる。

【０１０７】携帯電話ネットワーク１３の携帯電話ユー
ザ（この場合Ｕ３）に、必ず、プリンタネットワーク１
４を運営する事業者との契約を義務づけるのであれば、
添付ファイル蓄積部７１内のメールボックスは、携帯電
話ユーザに対応付け、添付ファイル（ＭＥ２２（Ｆ
２））の取出しを行うか否かにかかわらず、該当するメ
ールボックスに添付ファイルが格納された時点で課金す
ることができるが、そのような義務づけを行わない場合
には、むしろ送信元ユーザに対応付けたほうが自然であ
ると考えられる。

【０１０８】なぜなら、前述のケースでは、電子メール
ＭＥ１（Ｆ１、Ｆ２）を作成する際、前記Ccフィールド
ＦＤ１６のフィールド本体にカーボンコピーの送信先と
して当該メールボックスサーバ２４のメールアドレス
「ＡＤＤ（２４）」を記述したのは、送信元ユーザＵ１
であり、当該記述によって、メールボックスサーバ２４
の資源が消費されたからである。

【０１０９】なお、ここでは、本体ファイル削除部７０
で本体ファイルを削除して添付ファイルだけを添付ファ
イル蓄積部７１に蓄積するようにしたが、もともと本体
ファイルのサイズは添付ファイルに比べて小さいのであ
るから、当該削除を行わず、本体ファイルと添付ファイ
ルの双方を蓄積するようにしてもよい。

【０１１０】上述したように携帯電話機３１、３２で
は、文字数が２５０文字や２０００文字等に制限されて
いるため、プレーンテキスト形式の本体ファイルでさ
え、最後まで読めないことも多いことを考慮すると、こ
のような構成によって、完全な形の本体ファイルおよび
添付ファイルを読むことができれば、携帯電話ユーザに
とって好ましい。

【０１１１】次に、当該メールボックスサーバ２４か
ら、添付ファイル（ＭＥ２２（Ｆ２））を取出すために
ユーザ（ここではＵ３）によって操作される遠隔プリン
タ端末３３の主要部の構成例につき、図９に基づいて説
明する。

【０１１２】（Ａ−１−８）遠隔プリンタ端末の構成例 図９において、当該遠隔プリンタ端末３３は、送受信部
７１と、操作部７２と、メール処理部７３と、ディスプ
レイ部７４と、メモリ（あるいはハードディスク）７５
と、印刷処理部７６とを備えている。

【０１１３】このうち送受信部７１は前記携帯電話機３
１などの送受信部６１と同じものであってもよいが、通
常、当該送受信部７１は、有線でメールボックスサーバ
２４に接続されている。

【０１１４】また、メール処理部７３には、遠隔プリン
タ端末用のメーラが搭載されている。

【０１１５】このメーラは、添付ファイルを処理するこ
とのない携帯電話機に搭載されるメーラと異なり、添付
ファイル中の画像データなどを送信元端末３０のメーラ
で使用したＭＩＭＥ対応のエンコード方法（例えばＢＡ
ＳＥ６４など）に基づいてデコードする機能を装備して
いる。

【０１１６】また、前記メールボックスサーバ２４内
で、前記本体ファイルの削除を行わない場合には、上述
したboundary文字列ＢＤ１１をもとに、分割メールＭＥ
２１とＭＥ２２をつなぎ合わせて、送信元ユーザＵ１が
意図した最初の電子メールＭＥ１（Ｆ１、Ｆ２）を復元
する機能も装備する必要がある。

【０１１７】さらに、必要に応じて、添付ファイルのデ
ータをユーザ（Ｕ３）が読むことのできる形式に変換す
るためのワープロソフトなども、当該メール処理部７３
に搭載される。

【０１１８】操作部７２は、携帯電話ユーザ（ここでは
Ｕ３）の操作に応じて、上述した電子メール取出し要求
Ｓ９に対応する電子メール取出し要求Ｓ１９を、送受信
部７１からメールボックスサーバ２４へ送信したり、受
信され、デコードされた（必要な場合には、つなぎ合わ
せも実行して復元された）電子メール（例えばＭＥ２２
（Ｆ２））の内容をディスプレイ部７４で画面表示した
り、あるいは印刷処理部７６から印刷出力したりするた
めの部分である。

【０１１９】当該遠隔プリンタ端末３３の構成は、印刷
処理部７６が存在する点を除くと、図面上、ほとんど前
記携帯電話機３２などと相違しないが、実際の機械的、
電子的な仕様は大きく異なる。

【０１２０】例えば、ディスプレイ部７４は、通常のデ
スクトップタイプのパーソナルコンピュータと同程度の
サイズ（例えば１７インチ程度）の画面を備え、その画
面サイズは携帯電話機３１や３２の画面よりもはるかに
大きいので、電子メールに含まれるテキストや画像など
を目視する場合にも、携帯電話機よりも、簡単、かつ詳
細に目視することができ、使い勝手のよいユーザインタ
フェースを備えている。

【０１２１】また、印刷処理部７６から出力される印刷
出力は、例えば、用紙サイズとしてＢ５やＡ４を用い
て、テキストや画像を、ユーザの読み取りやすい大きさ
で印刷表示することができる。

【０１２２】画面表示だけで済ませたり、画面表示した
あと印刷出力したりすることは、ユーザ（Ｕ３）が操作
部７２を操作することによって、自由に選択することが
できる。

【０１２３】また、当該遠隔プリンタ端末３３は固定的
に配置されるものであるため、十分に大きな容量を持つ
メモリ７５を搭載することが可能である。これにより、
電子メール取出し要求Ｓ１９に応じてメールボックスサ
ーバ２４から取出された電子メールの内容は、完全に当
該メモリ７５に格納することが容易となり、電子メール
を読む際には、メールボックスサーバ２４と通信する必
要はない。

【０１２４】ところで、前記メールボックスサーバ２０
の添付ファイル蓄積部７１内には、通常、多数の添付フ
ァイルが蓄積されているが、ユーザＵ３が目的の添付フ
ァイルＭＥ２２（Ｆ２）を指定するには、例えば、自身
のメールアドレスである前記「ＡＤＤ（Ｕ３）」や送信
元ユーザのメールアドレスである前記「ＡＤＤ（Ｕ
１）」を使用するようにするとよい。

【０１２５】また、該当するメールボックス（ＭＢＵ
Ｘ）内に、同じ送信元ユーザＵ１から自身に宛てて送信
された添付ファイルが複数存在する場合には、これらの
メールアドレスだけでは目的の添付ファイルを絞り込む
ことができないので、例えば、前記Message-IDフィール
ドＦＤ１０に記述されるメッセージＩＤや、boundary文
字列ＢＤ１１をもとに特定するようにしてもよい。

【０１２６】当該メッセージＩＤは、メールサーバが自
動的に付与するユニークなメール番号である。

【０１２７】以下、上記のような構成を有する本実施形
態の動作について説明する。

【０１２８】（Ａ−２）第１の実施形態の動作 いま、送信元端末３０を操作するユーザＵ１が添付ファ
イル（Ｆ２）を添付した図１１に示す電子メールＭＥ１
（Ｆ１、Ｆ２）を送信するよう、送信元端末３０を操作
したとする。

【０１２９】これを受けて送信元端末３０内のメール処
理部４７に搭載されたメーラは、本体ファイルＰＦ１と
添付ファイルＰＦ２の本文メッセージをエンコードし、
前記分割メールＭＥ１１（Ｆ１）とＭＥ１２（Ｆ２）、
およびそのカーボンコピーである分割メールＭＥ２１
（Ｆ１）とＭＥ２２（Ｆ２）を送信する。

【０１３０】これらの４つの電子メールは、各個に、イ
ンターネット１１上のメール配送サーバ（例えば２０）
によって配送されるが、最終的には、分割メールＭＥ１
１（Ｆ１）とＭＥ１２（Ｆ２）は、メールボックスサー
バ２３に到達し、カーボンコピーである分割メールＭＥ
２１（Ｆ１）とＭＥ２２（Ｆ２）は、メールボックスサ
ーバ２４に到達する。

【０１３１】分割メールＭＥ１１（Ｆ１）とＭＥ１２
（Ｆ２）を受け取って、添付ファイルＭＥ１２（Ｆ２）
は削除し、電子メールＭＥ１１（Ｆ１）を本体ファイル
蓄積部５３に蓄積すると、直ちに、当該メールボックス
サーバ２３は、当該電子メールＭＥ１１（Ｆ１）のＭＩ
ＭＥヘッダのToフィールドの情報から当該電子メールが
携帯電話機３２を携帯するユーザＵ３に宛てたものであ
ることを認識し、当該携帯電話機３２に所定の通知信号
を送信して、着信音等の発生を行わせる。

【０１３２】これにより電子メールの着信を認識したユ
ーザＵ３は、携帯電話機３２を操作してメールボックス
サーバ２３から当該電子メールＭＥ１１を取り出す。

【０１３３】このとき、当該電子メールＭＥ１１の本文
メッセージＰＴ１が２５０文字以内であれば、ユーザＵ
３は完全に当該電子メールを読むことができるが、２５
０文字を超えていると、超えた分は読むことができな
い。

【０１３４】当該電子メールＭＥ１１に削除された添付
ファイルＭＥ１２が存在していたことは、当該電子メー
ルの本文メッセージＰＴ１の意味内容などからも、ユー
ザＵ３に分かると考えられるが、もしも必要と考えた場
合には送信元ユーザＵ１は、当該携帯電話機３２に電話
をかけること等の方法でも、添付ファイルの存在を携帯
電話ユーザＵ３に知らせることもできる。

【０１３５】ユーザＵ３が、削除された当該添付ファイ
ルＭＥ１２を見る必要性を認めた場合（あるいは、本文
メッセージＰＴ１の前記２５０文字を超えた部分を読む
必要性を認めた場合）には、近くのコンビニエンススト
アや駅などに立ち寄り、そこに設置されている遠隔プリ
ンタ端末（例えば３３）を操作する。

【０１３６】ユーザＵ３が当該遠隔プリンタ端末３３を
操作しようとするときには、すでにカーボンコピーであ
る分割メールＭＥ２１（とＭＥ２２）は、メールボック
スサーバ２４によって処理され、添付ファイル蓄積部７
１に蓄積されている。

【０１３７】自身の電子メールアドレスを入力すること
等により、ユーザ認証を済ませたユーザＵ３は遠隔プリ
ンタ端末３３を操作して、メールボックスサーバ２４か
ら添付ファイルＦ２（と本体ファイルＦ１）を取出す。

【０１３８】取出された添付ファイルＦ２は、メール処
理部７３の処理を受け、操作部７２の操作内容に応じ
て、印刷処理部７６から印刷出力されたり、ディスプレ
イ部７４から表示出力されたりする。

【０１３９】これにより、ユーザＵ３は、顧客の所在地
までの道順などを示した地図を取得することができる。

【０１４０】また、本体ファイルＦ１も取出すようにし
た場合には、携帯電話機３２では途中までしか読むこと
ができなかった、前記２５０文字以降の文章も読むこと
が可能になる。

【０１４１】なお、遠隔プリンタ端末３３のメモリ７５
に記憶された添付ファイルＦ２（と本体ファイルＦ１）
の内容は、印刷出力（表示出力）後ただちに消去され得
るが、メールボックスサーバ２４の本体ファイル蓄積部
５３のメールボックス（ここではＭＢＵＸ）に格納され
ている添付ファイルＦ２（と本体ファイルＦ１）は、そ
の後も一定期間保存され、その期間内であれば、プリン
タネットワーク１４内のいずれかの遠隔プリンタ端末か
ら何度でも取出し可能である。

【０１４２】必要に応じて、メールボックス（ＭＢＵ
Ｘ）における保存は、このように期間で限定せず、取出
し回数で限定するようにしてもよい。

【０１４３】（Ａ−３）第１の実施形態の効果 以上のように、本実施形態によれば、携帯電話機（３２
など）においてそのディスプレイ部に画面表示できない
電子メールの添付ファイルにつき、随所に配置された遠
隔プリンタ端末（３３など）を用いて画面表示させた
り、印刷出力させたりすることが可能であり、使い勝手
のよい通信システムを提供することができる。

【０１４４】また、本実施形態は、インターネット上や
携帯電話ネットワーク上に実装された既存の電子メール
システムをほとんどそのまま利用することができるた
め、実現性に優れている。

【０１４５】（Ｂ）第２の実施形態 以下では、本実施形態が上述した第１の実施形態と相違
する点についてのみ説明する。

【０１４６】本実施形態では、電子メールＭＥ１（Ｆ
１，Ｆ２）において稟議書を取り扱い、当該稟議書に対
応した電子決済を実行する。

【０１４７】電子メールで稟議書を送信する場合には、
「詳細は添付の通り。」などと記載して、稟議書の全内
容は、ワープロ文書などで記述することが多い。ワープ
ロ文書などは、上述したバイナリデータであるため、添
付ファイルの形式で送信される。

【０１４８】したがってこの場合、「詳細は添付の通
り。」などの記述は、図１１に示す前記本文ＰＴ１に配
置され、稟議書の全内容は前記本文ＰＴ２に配置される
ことになる。このため稟議書の全内容は、前記分割メー
ルＭＥ２２（Ｆ２）として、メールボックスサーバ２４
内のメールボックスＭＢＵＸに蓄積される。

【０１４９】本実施形態では、図１において、電子メー
ルが遠隔プリンタ端末を操作する受信者（送信先ユー
ザ）によって受信されたか否かを、当該電子メールの送
信者が希望するときにいつでも確認することができるよ
うに、送信者側からの確認要求メールが届いた場合に
は、すでに電子メールが受信者によって受信されたか否
かを示す受信確認メールを送信する受信確認サーバ２５
を設けてある。

【０１５０】また、図１に示す決済サーバ３４も本実施
形態のための構成要素である。

【０１５１】なお、本実施形態では、メールボックスサ
ーバ２４内のメールボックスＭＢＵＸは送信先ユーザＵ
３に対応付けられたものであり、前記ＡＤＤ（２４）は
当該メールボックスを指定するものとする。

【０１５２】（Ｂ）第２の実施形態の構成および動作 本実施形態の通信システム８０も、その全体構成は図１
に示す第１の実施形態の通信システム１０とほぼ同じで
あり、図１に示した各構成要素１１〜１４、２２〜２
４、３１〜３３の機能も基本的に第１の実施形態と同じ
である。

【０１５３】ただし本実施形態のプリンタネットワーク
１４が備えるメールボックスサーバ２４は、遠隔プリン
タ端末３３から電子メールを取出すためのプロトコルと
して、例えばＩＭＡＰ４などの多機能なプロトコルを装
備している。

【０１５４】周知のように、通信速度の制約が厳しく、
携帯電話機自体の性能に制約が多い携帯電話機（例えば
３２）では、携帯電話機がアベイラブルであればサーバ
主導で着信した電子メールを該当する携帯電話機に送り
付ける前述のプロトコルなどを採用していることも多
い。

【０１５５】しかしながらプリンタネットワーク１４内
にはこのような制約はなく、通常のパーソナルコンピュ
ータでメールボックスに着信した電子メールを取出す場
合に使用するＰＯＰ３やＩＭＡＰ４などの一般的なプロ
トコルを使用可能である。

【０１５６】このうちＰＯＰ３プロトコルは受信者が電
子メールを取出して読むための必要最小限の機能しか備
えていないが、ＩＭＡＰ４プロトコルは豊富な機能を備
えた多機能プロトコルである。

【０１５７】ただし本実施形態ではＩＭＡＰ４の豊富な
機能（コマンド）のうち、着信した電子メールの未読／
既読のステータス情報を調べるＳＴＡＴＵＳコマンド
（ステータスコマンド）と、ヘッダ内の一部のフィール
ドのフィールド本体（ToフィールドＦＤ１５のフィール
ド本体である送信者メールアドレスと、必要に応じてSu
bjectフィールドＦＤ１７またはDateフィールドＦＤ１
１のフィールド本体）を取出すＦＥＴＣＨコマンドしか
使用しないため、メールボックスサーバ２４に未読／既
読のステータス情報やヘッダ情報を蓄積し、受信確認サ
ーバ２５がＦＥＴＣＨコマンドやＳＴＡＴＵＳコマンド
などのコマンドを供給すると、未読／既読のステータス
情報やＦＥＴＣＨコマンドで指定したヘッダ情報を反す
機能を備えたプロトコルであれば、どのようなプロトコ
ルを使用することも可能である。このようなプロトコル
を、本実施形態では、受信確認プロトコルと呼ぶ。

【０１５８】本実施形態ではこの受信確認プロトコル
が、少なくともメールボックスサーバ２４と受信確認サ
ーバ２５間で使用される。

【０１５９】当該受信確認サーバ２５の主要部の構成例
は、図１３に示す通りである。

【０１６０】図１３において、当該受信確認サーバ２５
は、受信部９０と、記憶部９１と、確認情報抽出部９２
と、受信確認メーラ部９３と、送信部９４とを備えてい
る。

【０１６１】このうち受信部９０は、確認要求受付時に
はプリンタネットワーク２５上の伝送路から、インター
ネット１１経由で配送されてきた確認要求メールＭＡ１
を受信し、受信確認時にはメールボックスサーバ２４か
ら前記ヘッダ情報やステータス情報を受信する部分であ
る。前記送信元端末３０が送信する電子メールであるか
ら、当該確認要求メールＭＡ１も当然、前記ＭＩＭＥ規
格に対応している。

【０１６２】当該確認要求メール（例えばＭＡ１（ＡＴ
１））は、送信済みの電子メール（例えば、前記ＭＥ１
（Ｆ１，Ｆ２）、ただし遠隔プリンタ端末３３がメール
ボックスサーバ２４から添付ファイルだけを取出す場合
には、ＭＥ２１（Ｆ２））がメールボックスから取出さ
れて遠隔プリンタ端末（例えば３３）に受信されたか否
かの確認を求める電子メールである。

【０１６３】当該確認要求メールＭＡ１（ＡＴ１）はそ
の本文メッセージに、基本属性情報として、送信済み電
子メール（ＭＥ１）のToフィールドＦＤ１５に記載して
あった電子メールアドレス（ここでは、前記ＡＤＤ（２
４）によって指定されるメールボックスＭＢＵＸのアド
レス）を含む。

【０１６４】当該基本属性情報を用いることにより、受
信確認サーバ２５は、メールボックスサーバ２５中の多
数のメールボックスのなかから、求めるメールボックス
（ここでは、ＭＢＵＸ）を特定することができる。

【０１６５】さらに、当該メールボックス（ここではＭ
ＢＵＸ）中に複数の電子メールが蓄積されている場合に
は、確認要求メールＭＡ１のFromフィールドＦＤ１２に
記述されたメールアドレス（ここではＡＤＤ（Ｕ１））
と合致するメールアドレスを持つ電子メールを探索する
ことによって目的の電子メールを特定することができ
る。

【０１６６】ところが、同じ送信者（Ｕ１）から同じ受
信者（Ｕ３）に送信された電子メールが当該メールボッ
クスに複数蓄積されていることも起こり得るため、この
ようなケースにも対応するためには、これらのメールア
ドレスだけでは不十分である。

【０１６７】そのような場合には付加的な属性情報（こ
こではＡＴ１）も確認要求メール内に記述するようにし
て、受信確認を求める送信済みの電子メールを一義的に
識別するようにするとよい。

【０１６８】一般的に当該付加属性情報としては、受信
確認を求める送信済みの電子メールを一義的に識別する
ことのできる識別子であればどのようなものを使用して
もかまわないが、例えば、当該送信済み電子メール中の
DateフィールドＦＤ１１に記述された日付（および時
刻）情報や、SubjectフィールドＦＤ１７に記述したメ
ールの題名を使用することができる。

【０１６９】ただし日付情報を付加属性情報として使用
する場合には、送信者が何らかの方法で送信済みの電子
メールを作成した日付や時刻を記録しておく必要がある
（このような記録を行う機能は、メーラ等に装備しても
よい）。また、メールの題名を付加属性情報として使用
する場合には、同じ宛先に送信する各電子メールにはユ
ニークな題名（ここでは例えば、「稟議書について」な
どと記述する）を付与するように注意する必要がある。

【０１７０】確認要求メール（例えばＭＡ１）において
これらの付加的属性情報を記述する場所は、本文メッセ
ージ中であってもよいが、それに限定する必要はない。
例えば、SubjectフィールドＦＤ１７に当該付加的属性
情報を記述するように決めておいてもよい。

【０１７１】当該確認要求メールは、基本属性情報と必
要な付加属性情報だけを備えた極めて小さなサイズの電
子メールで、前記ToフィールドＦＤ１５には、当該受信
確認サーバ２５に割り当てられている電子メールアドレ
ス（ここでは、ＡＤＤ（２５））を収容している。

【０１７２】受信確認サーバ２５は、自身宛ての電子メ
ールであって、本文メッセージに基本属性情報らしき情
報が収容された電子メールを受信すると、当該電子メー
ルを、確認要求メールとして取り扱う。

【０１７３】なお、一般に付加属性情報の要否（メール
ボックスサーバ２４の該当するメールボックス（例え
ば、ユーザＵ３のメールボックスＭＢＵＸ）内に送信者
Ｕ１から送信された電子メールが１つしか存在しない場
合には当該付加属性情報を用いなくても電子メールは一
義的に特定できる）については、送信者（例えばＵ１）
はこれまでの自身の電子メール送信履歴をもとに、ある
程度予測することが可能であると考えられるので、その
記述を行うか否かは送信者に委任することとし、付加属
性情報が含まれていなくても、それを理由として受信確
認サーバ２５が確認要求メールとして取り扱わないとい
うことはないようにするとよい。

【０１７４】ところで当該確認要求メール（例えばＭＡ
１）は、受信確認サーバ２５と送信者Ｕ１にとっては特
別な意味を持つが、それ以外のメール配送サーバ（例え
ば２０）などにとっては、ＳＭＴＰプロトコルなどのメ
ール配送用プロトコルにしたがって配送するただのサイ
ズの小さな電子メールにすぎず、何ら特別な処理を要す
るものではない。

【０１７５】当該確認要求メールＭＡ１はまた、添付フ
ァイルも添付されておらず、サイズも十分に小さいた
め、通常は、分割されることなく送信される。

【０１７６】図１３において、前記受信部９０に接続さ
れている記憶部９０は、当該確認要求メールを確認情報
抽出部９２で行う処理に必要な処理時間だけ、一時的に
蓄積する受信バッファメモリである。

【０１７７】確認情報抽出部９２は、受信確認を実行す
るために必要な情報を確認要求メールから抽出する部分
である。

【０１７８】ここでは、前記確認要求メールＭＡ１を受
信し、そのFromフィールドＦＤ１２から送信者のメール
アドレスとして前記ＡＤＤ（Ｕ１）を抽出し、本文ＰＴ
１から前記基本属性情報としてＡＤＤ（２４）を抽出
し、SubjectフィールドＦＤ１７からは前記付加属性情
報ＡＴ１として例えば「稟議書について」などを意味す
るコード（このコードを、ＣＯＤ１とする）を取出す
（これは上述したように、SubjectフィールドＦＤ１７
に当該付加的属性情報を記述するように決めてある場合
に対応する処理）。

【０１７９】なお、SubjectフィールドＦＤ１７に日本
語を記述した場合、送信元端末３０が装備するメール処
理部４７がＭＩＭＥ対応のメーラであれば自動的にＢＡ
ＳＥ６４でエンコードするので、確認要求メールＭＡ１
のSubjectフィールドＦＤ１７から抽出される付加属性
情報ＡＴ１は、「稟議書について」に対応するコードＣ
ＯＤ１になる。

【０１８０】次に、当該確認情報抽出部９２で抽出され
た送信者メールアドレスＡＤＤ（Ｕ１）と付加属性情報
ＡＴ１（すなわちコードＣＯＤ１）は、信号Ｓ４８とし
て前記受信確認メーラ部９３内のメール情報受信部９５
に供給され、基本属性情報ＡＤＤ（２４）は信号Ｓ４２
としてコマンド生成部９６に供給される。

【０１８１】当該受信確認メーラ部９３は当該コマンド
生成部９６のほか、メール情報受信部９５と、受信確認
メール生成部９７とを備え、前記受信確認プロトコルを
搭載したメーラである。

【０１８２】すなわち当該受信確認メーラ部９３は基本
的にメーラであり、メールボックスサーバ２４に対して
は、遠隔プリンタ端末３３のメール処理部７３が搭載し
ているメーラと同じインタフェースを提供する。

【０１８３】ただし当該受信確認メーラ部９３はもっぱ
ら受信確認のためだけに機能する特殊なメーラであるた
め、通常のパーソナルコンピュータ（例えば３０）に搭
載されているメーラのように、任意の内容の本文メッセ
ージを収容したり、添付ファイルを添付したりする機能
は持っていない。

【０１８４】また、メールボックスサーバ２４内の必要
なメールボックス（例えばＭＢＵＸ）にアクセスするた
めに不可欠なパスワードなどは予め当該受信確認メーラ
部９３内に格納されていて、送信者（例えばＵ１）から
求められた任意のメールボックス（例えばＭＢＵＸ）に
アクセスすることができる。

【０１８５】ただしアクセスすることができるのは受信
確認に必要な電子メールのヘッダ情報とステータス情報
（未読／既読の情報）だけであり、メールボックス内の
その他の情報（電子メールの本文メッセージの内容やＦ
ＥＴＣＨコマンドで指定しないヘッダ情報など）に対す
るアクセスは実行することができないように構成されて
いる。

【０１８６】また、ＦＥＴＣＨコマンドで送信者のメー
ルアドレスを取出したとしても、当該メールアドレスは
受信確認メーラ部９３内部の処理に使用されるだけであ
り、確認要求を送信した送信者Ｕ１に当該メールアドレ
スがそのまま通知されることはない。受信用メールボッ
クス内にどのような送信者メールアドレスから送信され
た電子メールが蓄積されているかは、一般的に、受信者
（例えばＵ３）のプライバシーに属する事象と考えられ
るからである。

【０１８７】このような受信確認メーラ部９３内に設け
られているコマンド生成部９６は、予め格納されている
前記パスワードなどを使用して、メールボックスサーバ
２４の前記添付ファイル蓄積部７１内に設けられている
ユーザＵ３のメールボックスＭＢＵＸにアクセスして、
ヘッダ情報（送信者情報）やステータス情報を問い合わ
せる部分である。

【０１８８】当該アクセスによって開始されたメールボ
ックスサーバ２４とのセッションでは、まずＦＥＴＣＨ
コマンドでヘッダ情報を取り出し、次いで必要ならば、
当該ＦＥＴＣＨコマンドで付加属性情報を取り出し、最
後にＳＴＡＴＵＳコマンドを用いてステータス情報の検
査を行う。

【０１８９】図４に示したメールボックスサーバ２４の
添付ファイル蓄積部７１内に設けられている当該メール
ボックスＭＢＵＸは論理的に、例えば、図１２に示すよ
うな構成を備えている。

【０１９０】図１２において、電子メールエリアＥＢＦ
には、当該メールボックスＭＢＵＸ内に蓄積されている
各電子メールの本体（ここでは添付ファイルの本体）と
してＭＬ１〜ＭＬＮが格納され、ステータス情報エリア
ＳＵＦにはこれら電子メールにつき未読または既読の別
を示すステータス情報が格納され、属性エリアＡＴＦに
はこれら電子メールにつき上述した付加属性情報が格納
され、送信者情報エリアＳＩＦにはこれら電子メールに
つき送信者情報（各電子メールの前記FromフィールドＦ
Ｄ１２内に収容されている各送信者のメールアドレス）
が格納されている。

【０１９１】図示の状態において、当該メールボックス
ＭＢＵＸ内にはＮ個の電子メールＭＬ１〜ＭＬＮが蓄積
されており、前記送信者Ｕ１が送信した電子メールは、
送信者情報エリアＳＩＦ内にＡＤＤ（Ｕ１）と記載され
ているＭＬ１とＭＬ２の２つで、他の電子メールＭＬ３
はメールアドレスＡＤＤ（ＵＸ）の送信者からユーザＵ
３に送信されたもので、電子メールＭＬＮはメールアド
レスＡＤＤ（ＵＹ）の送信者からユーザＵ３に送信され
たものである。

【０１９２】また、ステータス情報エリアＳＵＦ内に
「未」とあることから、電子メールＭＬ１、ＭＬ２、Ｍ
ＬＮは未読であり、「既」とあることから電子メールＭ
Ｌ３は既読であることが分かる。

【０１９３】なお、厳密には電子メールを「読む」こと
と「受信」することとは必ずしも同じではなく、「受
信」することと「印刷」することも、必ずしも同じでは
ないが、本実施形態ではこれらを区別せず、「既読」の
場合は「受信した」ことを意味すると同時に「印刷出
力」したことを意味するものとする。反対に、「未読」
の場合は「受信していない」ことを意味すると同時に
「印刷していない」ことを意味する。

【０１９４】「読む」こと、「受信」すること、「印
刷」することの異同は、実質的に遠隔プリンタ端末３３
の機能との関連で異なってくる。例えば、遠隔プリンタ
端末３３が受信した電子メールを開封しなくてもよい
（すなわち、読まなくてもよい）構成になっているか否
かに依存して、「読む」ことと「受信」することが同じ
であるかどうかが変わる。すなわち、遠隔プリンタ端末
３３が、受信した電子メールは必ず（あるいは自動的
に）開封される構成になっていれば、受信したことは読
んだこと（開封したこと）に等しい。

【０１９５】「受信」と「印刷」の関係についてもこれ
と同様で、受信した電子メールが必ず（あるいは自動的
に）印刷出力されるように遠隔プリンタ端末３３が構成
されていれば、受信したことは印刷したことに等しい。

【０１９６】図１２中においては、付加属性情報が前記
ＡＴ１であることから、電子メールＭＬ１が前記稟議書
を収容した前記分割メールＭＥ２２（Ｆ２）と同じもの
であることがわかる。本実施形態で当該分割メールＭＥ
２２（Ｆ２）に、ワープロ文書として上述した稟議書の
全内容が収容されている。

【０１９７】コマンド生成部９６が前記ＦＥＴＣＨコマ
ンドでメールボックスＭＢＵＸ内の送信者情報ＡＤＤ
（Ｕ１）〜ＡＤＤ（ＵＹ）を取り出すと、当該送信者情
報は前記受信部９０を介してメール情報受信部９５に受
信される。

【０１９８】メール情報受信部９５は、取り出した送信
者情報ＡＤＤ（Ｕ１）〜ＡＤＤ（ＵＹ）のなかから確認
要求メールＭＡ１の送信者メールアドレスＡＤＤ（Ｕ
１）と一致するものを検索する部分である。この検索に
より、図１２のケースでは一致するものが２つ存在する
（すなわち、ＭＬ１とＭＬ２）ことがわかる。

【０１９９】ここでもしも１つしか一致するものが検出
されなければ、次に行う付加属性情報の取り出しは省略
してもよい（もちろん、必要ならば、信頼性を高めるた
めに実行してもかまわない）が、図１２の例では一致す
るものが２つ存在するため、ＦＥＴＣＨコマンドによる
付加属性情報の取り出しは不可欠となる。

【０２００】この取り出しのために、前記コマンド生成
部９６は再びＦＥＴＣＨコマンドを前記メールボックス
サーバ２４に供給して今度は当該２つの電子メールＭＬ
１とＭＬ２に関し、付加属性情報である送信済みメール
のSubjectフィールドＦＤ１７のフィールド本体を取り
出す。

【０２０１】これにより、メール情報受信部９５は確認
要求メールＭＡ１に収容されている付加属性情報（コー
ドＣＯＤ１）と一致する唯一の電子メールがＭＬ１であ
ることを特定できるので、コマンド生成部９６に対し当
該電子メールＭＬ１のステータス情報を調べるように指
示し、コマンド生成部９６はＳＴＡＴＵＳコマンドを生
成して当該電子メールＭＬ１のステータス情報を取り出
す。

【０２０２】図示の例では当該電子メールＭＬ１のステ
ータス情報は未読を示す「未」なので、まだ１度も、受
信（印刷出力）されていないことがわかる。

【０２０３】コマンド生成部９６が生成し送信部９４か
ら送信したＳＴＡＴＵＳコマンドによって取り出された
ステータス情報は、受信部９０を介してメール情報受信
部９５に受信されてから、前記信号Ｓ４２として既に受
信されていた送信者メールアドレスＡＤＤ（Ｕ１）とと
もに、信号Ｓ４６として受信確認メール生成部９７に渡
される。

【０２０４】受信確認メール生成部９７は、信号Ｓ４６
として受信した各情報を用いて受信確認メールＭＫ１を
生成し、送信部９４を介してプリンタネットワーク１４
に送出する。

【０２０５】すなわち、当該受信確認メールＭＫ１は、
ToフィールドＦＤ１４に前記ＡＤＤ（Ｕ１）を、Fromフ
ィールドにＡＤＤ（２５）を収容し、例えば、本文ＰＴ
１に「未読」を示す情報を記述した電子メールである。
もし必要ならば、「未読」を示す当該情報は、Subject
フィールドＦＤ１７などに記述してもよい。これによ
り、送信者Ｕ１は着信した受信確認メールＭＫ１を開封
しなくても一覧を画面表示するだけで、受信確認の結果
を知ることが可能になる。

【０２０６】いずれにしても当該受信確認メールＭＫ１
は、前記確認要求メールＭＡ１と同様、受信確認サーバ
２５と送信者Ｕ１にとっては特別な意味を持つが、それ
以外のメール配送サーバ（例えば２１）などにとって
は、ＳＭＴＰプロトコルなどのメール配送用プロトコル
にしたがって配送するただのサイズの小さな電子メール
にすぎず、何ら特別な処理を要するものではない。

【０２０７】このため、プリンタネットワーク２４内の
メール配送サーバ（図示せず）は、ＳＭＴＰプロトコル
などのメール配送用プロトコルにしたがって通常の電子
メールと同様に、当該受信確認メールＭＫ１を配送して
インターネット１１に送出する。

【０２０８】インターネット１１上のメール配送サーバ
（例えば２１）も、通常の電子メールと同様に、当該受
信確認メールＭＫ１を、前記送信元端末３０のための受
信メールボックスを搭載したメールボックスサーバ（図
示せず）まで届けるので、ユーザＵ１は、いつでも望む
ときに、送信済みメール（ここではＭＥ１（の添付ファ
イルＭＥ２２））が、送信先のユーザ（ここではＵ３）
に読まれたか否か（印刷出力されたか否か）を確認する
ことができる。

【０２０９】なお、必要に応じて、送信元端末３０が搭
載しているメーラに、当該受信確認メール（例えばＭＫ
１）を、着信した他の一般的な電子メールと異なる特別
なメールとして画面表示する機能を持たせてもよい。

【０２１０】このあと再び確認要求メールを送信して
「既読」を示す受信確認メールが返送されてくれば、ユ
ーザＵ１は、ユーザＵ３が前記稟議書を認識済みである
ことを確認できる。

【０２１１】通常は、携帯電話機３２に前記分割メール
ＭＥ１１が着信したあとで、ユーザＵ３が遠隔プリンタ
端末（例えば３３）を操作して、当該分割メールＭＥ１
１に対応する内容を持つ分割メールＭＥ２２（すなわ
ち、添付ファイル（稟議書））を印刷出力することにな
るので、分割メールＭＥ２２が印刷出力されていれば、
携帯電話機３２に対する分割メールＭＥ１１の着信も正
常に行われたことが推測できる。

【０２１２】稟議書がユーザＵ３に認識されると、処理
は、ユーザＵ３による決済処理に進む。決済権を持って
いる重役など（ここではＵ３）は非常に多忙で会社内に
いないことが多いため、重要事項の主管者（ここではＵ
１）が早期の決済承認を受けるには、このように携帯電
話機３２や遠隔プリンタ端末３３を利用する必要が生じ
る。

【０２１３】決済処理は遠隔プリンタ端末３３を用いて
行うようにしてもよいが、ここでは携帯電話機３２を用
いて行うものとする。

【０２１４】本実施形態において決済処理を行うために
は、携帯電話機３２は携帯電話ネットワーク１３、イン
ターネット１１を経由して、前記決済サーバ３４と通信
する。なお、当該決済サーバ３４は、必要に応じて、携
帯電話ネットワーク１３やプリンタネットワーク１４上
に配置してもよいが、ネットワークの規模等から、イン
ターネット１１上に配置するのが一般的であると考えら
れる。

【０２１５】当該決済サーバ３４の主要部の構成例は、
図１４に示す通りである。

【０２１６】図１４において、当該決済サーバ３４は、
送受信部１００と、認証部１０１と、データベース処理
部１０２と、第１〜第３データ処理部１０３〜１０５
と、データベース１０８と、受付部１０９とを備えてい
る。

【０２１７】なお、前記携帯電話機３２のメール処理部
６３にはメーラを搭載しているため、ここでは電子メー
ルシステムを用いて電子決済を行うことになるが、携帯
電話機の性能により、必要ならばハイパーテキストシス
テムやＰＢ（プッシュボタン）信号と音声ガイダンスの
やり取りに応じて電子決済を行う機能も、当該決済サー
バ３４は装備している。

【０２１８】決済サーバ３４の構成要素のうち送受信部
１００は、携帯電話機３２から電子決済にかかる電子メ
ール（決済メールＤＭ１）を受信する部分である。ただ
しハイパーテキストシステムや音声ガイダンスを用いた
電子決済を実行する場合には、ハイパーテキスト形式の
データや音声ガイダンスのデータを、当該送受信部１０
０を介して送受信することになる。

【０２１９】決済メールＤＭ１には少なくとも、稟議書
を特定するための稟議書識別子、携帯電話ユーザＵ３を
示すためのユーザ識別子（社員ＩＤ）、稟議書を承認す
るか否かを示す認否情報からなる必須決済事項が含まれ
ている。このような識別子や情報としては、どのような
数字や記号列、文字列を使用してもかまわない。

【０２２０】当該送受信部４０に接続された認証部４１
は、決済メールＤＭ１に含まれる情報のうち、主として
前記ユーザ識別子を検査すること等により、当該決済メ
ールＤＭ１が正当なユーザによって送信されたものであ
るか否かを検証する。検証結果が肯定的な場合には、そ
の旨の電子メールを携帯電話機３２に返送するようにし
てもよい。

【０２２１】データベース処理部１０２は、データベー
ス１０８内に蓄積されているデータ（稟議書なども含ま
れていてよい）を検索したり書き換えたりする場合に動
作する部分である。

【０２２２】ここでは、前記決済メールＤＭ１の認証が
肯定的であった場合、データベース１０８内の前記ユー
ザＩＤおよび稟議書識別子に対応する場所に、前記認否
情報を書き込む処理を、前記受付部１０９からの指示に
基づいて、当該データベース処理部１０２が実行するこ
とになる。

【０２２３】前記第１データ処理部４３はＣＧＩを搭載
したＷｅｂサーバとしての機能を持つ部分で、パーソナ
ルコンピュータのブラウザを用いて電子決済を行うため
のＨＴＭＬファイル、携帯電話機のブラウザを用いて電
子決済を行うためのコンパクトＨＴＭＬファイル（また
はＨＤＭＬファイルなど）を閲覧要求に応じて端末のブ
ラウザに送信する機能や、ブラウザから送り返された記
入済みの決済フォームの内容を解析して、正常な受付が
行えれば、受付完了を示す確認メッセージをＨＴＭＬ形
式（コンパクトＨＴＭＬ形式（またはＨＤＭＬ形式））
で返す機能を装備している。

【０２２４】決済フォームはどのような構成を備えてい
てもかまわないが、少なくとも、前記必須決済事項に相
当する情報を、各種のボタン、コントロール、ボックス
を使用して特定できるものとする必要がある。例えば、
決済の承認、非承認などは、排他的な選択を示すラジオ
ボタンによって特定することができる。

【０２２５】現在のインターネット１１を前提とする
と、会社内の機密事項などに関する電子決済のために
は、ＳＳＬなどの暗号技術が普及しているハイパーテキ
ストシステムを利用するほうが、電子メールシステムを
利用するよりも安全で、セキュリティ性が高いものと考
えられる。

【０２２６】これに対し第２データ処理部４４は、メー
ラとしての機能を持つ部分で、パーソナルコンピュータ
のメーラを用いて電子決済を行うためのメーラ、携帯電
話機のメーラを用いて電子決済を行うためのメーラ（こ
のメーラが上述した決済メールＭＫ１を処理する）を備
えているほか、形態素解析や構文解析、意味処理などの
自然言語処理を実行する自然言語処理部を搭載してい
る。

【０２２７】すなわち、第２データ処理部４４内のメー
ラが、受け取った電子メールをデコードし、当該デコー
ド結果を自然言語処理部が処理することで、定型的な事
項、すなわち、前記必須決済事項に対応する情報を取得
するものである。

【０２２８】定型的な前記決済フォームを用いて電子決
済を行う場合には、通常、このような自然言語処理は不
要であるが、電子決済が電子メール（決済メールＭＫ
１）で行われた場合には記述内容が不定形であるために
自然言語処理が必要になる。自然言語処理を実行するた
めには、決済サーバ３４の処理能力にかなり大きな負荷
がかかるものと考えられるので、効率を重視する場合に
は電子メールによる電子決済を行わないようにしてもよ
い（その場合、第２データ処理部４４は省略できる）。

【０２２９】ただしここでは、様々な機能の携帯電話機
を持つ携帯電話ユーザ（例えばＵ３）が正常に電子決済
を行うことができるようにするために、電子メールによ
る電子決済にも対応するものとした。

【０２３０】次に第３データ処理部１０５は、ＩＶＲ
（インタラクティブ・ボイス・レスポンス（双方向性音
声応答））部や、ＣＴＩ（コンピュータ・テレフォニ・
インテグレーション）部を搭載する部分で、携帯電話機
ユーザ（ここではＵ３）に音声ガイダンスを聴取させ、
当該音声ガイダンスにしたがったＰＢ信号の送信を促す
ことで、前記社員ＩＤ、稟議書識別子、認否情報を取得
するものである。

【０２３１】前記第２データ処理部４４と同様に、必要
に応じて、音声ガイダンスやＰＢ信号を用いた電子決済
は受け付けず、当該第３データ処理部４５を省略するよ
うにしてもよい。

【０２３２】本実施形態においてこれら３つのデータ処
理部４３〜４５に接続されている受付部４９は、認証が
行われ、正常に前記必須決済事項に対応する情報が取得
できた場合に、前記データベース１０２に指示して、デ
ータベース１０８に対する認否情報の書き込み等を行わ
せる部分である。

【０２３３】なお、前記携帯電話機３２はブラウザを搭
載していなかったが、最近の多くの携帯電話機はブラウ
ザを搭載しているため、ハイパーテキストシステムを利
用し、上述した第１データ処理部１０３を介した電子決
済を実行可能である。

【０２３４】また、当該決済サーバ３４は例えばユーザ
Ｕ１の会社のイントラネットなどに配置されており、ユ
ーザＵ１はユーザＵ３による決済の内容（認否）を、前
記データベース１０８に読み出しアクセスすることによ
って、いつでも確認することが可能である。

【０２３５】以上のように、本実施形態では、ユーザＵ
１は稟議書の添付ファイルを添付した電子メールＭＥ１
を携帯電話ユーザＵ３宛てに送信することで、いつでも
決済承認を求めることができる。

【０２３６】パーソナルコンピュータなどに対して電子
メールを送信した場合には、当該パーソナルコンピュー
タのメーラを起動しないと電子メール受信者（例えばＵ
３）は、当該電子メールの着信を認識することができな
いが、携帯電話機３２の場合には、電子メールの着信は
所定の着信音やバイブレーションによって直ちに認識で
きる利点がある。

【０２３７】さらに、先に稟議書の添付ファイルを添付
した電子メールＭＥ１を携帯電話ユーザＵ３宛てに送信
したユーザＵ１は、受信確認サーバ２５に確認要求メー
ルＭＡ１を送信することによって、いつでも、ユーザＵ
３が当該添付ファイルを印刷出力したか否かを確認する
ことができる。

【０２３８】なお、本実施形態では、通信の品質が保証
されていないインターネット１１を経由する以上、電子
メール（例えばＭＥ１（あるいはその添付ファイルに対
応する分割メールＭＥ２２））が宛先のメールボックス
（例えばＭＢＵＸ）まで送達されないことも起こり得る
が、前記受信確認サーバ２５に、当該送達の確認を行う
機能を装備すれば、ユーザＵ１は、ユーザＵ３と通信す
ることなく送達確認を実行することも容易である。

【０２３９】また、携帯電話ユーザＵ３は、携帯電話機
３２を用いて読む電子メールＭＥ１（正確には、ＭＥ１
１）の本文中に「詳細は添付の通り。」などの記述を認
めると、添付ファイルにかかる稟議書を近くのコンビニ
エンスストアなどに設置されている遠隔プリンタ端末
（例えば３３）を用いて印刷出力することができる。そ
して稟議書の内容を確認したのち、当該ユーザＵ３は、
携帯電話機３２などを操作し前記決済サーバ３４を介し
て電子決済を行うことができる。

【０２４０】なお、ここでは稟議書を例に説明したが、
本実施形態は、添付ファイルを利用する必要があるケー
スに広く適用することができる。

【０２４１】（Ｂ−２）第２の実施形態の効果 本実施形態によれば、第１の実施形態の効果と同等な効
果を得ることができる。

【０２４２】加えて、本実施形態では、例えば、添付フ
ァイルとして稟議書を添付した電子メール（ＭＥ１）の
送信者（Ｕ１）は、いつでも決済権限者（ユーザＵ３）
に対して決済承認を求めることができるとともに、当該
添付ファイルが印刷出力されたか否か等を確認すること
もできるので、使い勝手がよく、通信の信頼性が向上す
る。

【０２４３】また、本実施形態では、モバイル環境でユ
ーザ（Ｕ３）が電子決済を行うことができるので、例え
ば、稟議書の決済承認を早期に取得したいのに、決裁権
限者（ユーザＵ３）が近くにいない場合などには非常に
効率的である。

【０２４４】しかも本実施形態では、このような利点
を、インターネット上や携帯電話ネットワーク上に実装
された既存の電子メールシステムやハイパーテキストシ
ステムをほとんどそのまま利用して獲得することができ
るため、実現性にも優れている。

【０２４５】（Ｃ）他の実施形態 上記実施形態において、図３に示したメールボックスサ
ーバ２３（２２）は、図５に示すメールボックスサーバ
２３（２２）に置換することが可能である。

【０２４６】図５のメールボックスサーバ２３では、携
帯電話機（例えば３２）からの指示に応じて、添付ファ
イル（ＭＥ１２（Ｆ２））をプリンタネットワーク２４
上のメールボックスサーバ２４に転送する転送処理部８
０を備えた点が、図３のメールボックスサーバと相違す
る。

【０２４７】添付ファイル（ＭＥ１２（Ｆ２））の転送
経路は、図１に点線で示した経路ＲＴ１のようにインタ
ーネット１１を経由するものであってもよく、一点鎖線
で示した経路ＲＴ２のように、携帯電話ネットワーク１
３とプリンタネットワーク１４を接続する伝送路を経由
するものであってもよい。

【０２４８】この場合、メールボックスサーバ２３の負
荷は増加するが、カーボンコピー（ＭＥ２１、ＭＥ２
２）の送信は不要となり、インターネット上のトラヒッ
クは軽減する。

【０２４９】また、メールボックスサーバ２３の負荷が
増加するといっても、その負荷は、添付ファイルを長時
間蓄積する場合に比べるとはるかに小さい。

【０２５０】さらに、上記実施形態において、図３に示
したメールボックスサーバ２３（２２）は、図６に示す
メールボックスサーバ２３（２２）に置換することも可
能である。

【０２５１】図６のメールボックスサーバ２３（２２）
は、全ファイル蓄積部８１に本体ファイルと添付ファイ
ルの双方を蓄積し、携帯電話機（例えば、３２）からの
指示に応じて、必要ならば本体ファイルと添付ファイル
の双方を、プリンタネットワーク１４内のメールボック
スサーバ２４に転送することができる点が、図５のメー
ルボックスサーバと相違する。

【０２５２】この場合、メールボックスサーバ２３にか
かる負荷は増大するが、カーボンコピー（ＭＥ２１、Ｍ
Ｅ２２）の送信が不要となってインターネット上のトラ
ヒックが軽減するだけでなく、メールボックスサーバ２
４に蓄積するファイルを、添付ファイルだけにするか、
本体ファイルだけにするか、あるいは添付ファイルと本
体ファイルの双方にするかを、携帯電話ユーザ（Ｕ３）
が動的に変更することが可能である。

【０２５３】一方、上記実施形態ではもとの電子メール
（ＭＥ１）を、本体ファイルを主体とする電子メールと
添付ファイルを主体とする電子メールの２つに分割した
が、分割は、ファイルサイズをもとに実行してもよい。
インターネットのメール配送サーバのなかには、受け取
った電子メールのサイズが大きすぎると、送り返してし
まうものもあるため、１つの電子メールのサイズは例え
ば５０Ｋバイト未満にしておくほうが安全である。

【０２５４】このような観点から、もとの電子メール
（ＭＥ１）は、必要に応じて、３つ以上に分割されるこ
ともある。

【０２５５】以上の説明では分割メールを利用したが、
本発明において分割メールの使用は必須の要件ではな
い。

【０２５６】分割メールを使用しない場合、添付ファイ
ルと本体ファイルの区別は、図１１に示したContent-Ty
peフィールドＦＤ１９の内容をもとに、text/plainであ
れば本体ファイル、それ以外なら添付ファイルと判断す
ることにより行う。これにより携帯電話ネットワーク内
のメールボックスサーバ（例えば、２３）は、添付ファ
イルを削除することが可能であり、プリンタネットワー
ク内のメールボックスサーバ（例えば２４）は、本体フ
ァイルを削除することが可能である。

【０２５７】また、上記実施形態では、ＭＩＭＥ規格と
ＢＡＳＥ６４を例に説明したが、本発明の適用範囲はこ
れに限定されるものではない。

【０２５８】例えば、uuencode方式や、BinHex方式を使
用することもできる。

【０２５９】さらに、上記実施形態におけるインターネ
ット（１１）はイントラネットなど、他のネットワーク
に置換可能であり、携帯電話機（３１，３２など）はＰ
ＨＳ端末、ＰＤＡ端末など他の携帯通信端末に置換可能
である。

【０２６０】ＰＨＳ端末やＰＤＡ端末などに対しても、
インターネット経由で電子メールをやり取りするサービ
スは現に行われており、上述した携帯電話機の場合と同
様な問題を有するからである。

【０２６１】また、上記第２の実施形態では、受信確認
サーバ２５をプリンタネットワーク１４の内部に配置し
たが、当該受信確認サーバ２５は、携帯電話ネットワー
ク１２，１３やインターネット１１上に配置することも
可能である。電子メールの受信確認等を送信者側が望む
ときに行うことができれば、送信者にとって、携帯電話
ネットワーク１２，１３上やインターネット１１上の電
子メールシステムの使い勝手が向上する。

【０２６２】なお、上記第２の実施形態では、受信確認
サーバ２５の機能によって電子メールの受信確認を行う
ようにしたが、受信通信端末（例えば、遠隔プリンタ端
末３３や携帯電話機３２など）に搭載しているメーラの
機能によって、当該受信確認を行うことができるように
してもよい。

【０２６３】当該メーラは、添付ファイルを印刷（また
は開封）したときに、当該添付ファイルが印刷（または
開封）されたことを示す電子メールである印刷確認メー
ル（前記受信確認メールＭＫ１に対応）を、前記送信元
へ返送する印刷確認通知部（または開封確認通知部）を
備えることになる。

【０２６４】ただしその場合には、送信者（Ｕ１）が望
むときに受信確認を行うことはできず、受信者（Ｕ３）
が当該電子メールを受信し、受信確認メールを送信した
ときにはじめて、当該受信確認メールが送信者のメール
ボックスに宛てて送信され、受信確認が可能となる。

【０２６５】また、受信者（Ｕ３）のメールボックス
（ＭＢＵＸ）に「仕事用」、「私用」などの区別を設
け、私用のメールボックスについては受信確認サーバ
（２５）がアクセスできないようにすることで、電子メ
ール受信者（Ｕ３）のプライバシーに配慮するようにす
るとよい。

【０２６６】さらに、上記第２の実施形態では携帯電話
機３２を用いて電子決済を行うようにしたが、遠隔プリ
ンタ端末３３を使用して電子決済を行うことも可能であ
る。

【０２６７】遠隔プリンタ端末３３を使用して電子決済
を行う場合、遠隔プリンタ端末３３は、電子決済を受け
付ける電子決済受付部を備え、当該電子決済受付部から
電子決済を実行することになる。当該電子決済受付部
は、例えばＷｅｂブラウザによって構成することができ
る。

【０２６８】

【発明の効果】以上に説明したように、本発明によれ
ば、メール通信システムの使い勝手を良くすることがで
きる。

【図面の簡単な説明】

【図１】第１、第２の実施形態に係る通信システムの主
要部の構成例を示す概略図である。

【図２】第１、第２の実施形態で使用するメール配送サ
ーバの主要部の構成例を示す概略図である。

【図３】第１、第２の実施形態で使用する携帯電話ネッ
トワーク内のメールボックスサーバの主要部の構成例を
示す概略図である。

【図４】第１、第２の実施形態で使用するプリンタネッ
トワーク内のメールボックスサーバの主要部の構成例を
示す概略図である。

【図５】他の実施形態で使用する携帯電話ネットワーク
内のメールボックスサーバの主要部の構成例を示す概略
図である。

【図６】他の実施形態で使用する携帯電話ネットワーク
内のメールボックスサーバの主要部の構成例を示す概略
図である。

【図７】第１の実施形態で使用する携帯電話機の主要部
の構成例を示す概略図である。

【図８】第１、第２の実施形態で使用する携帯電話機の
主要部の構成例を示す概略図である。

【図９】第１、第２の実施形態で使用する遠隔プリンタ
端末の主要部の構成例を示す概略図である。

【図１０】第１、第２の実施形態で使用する送信元端末
の主要部の構成例を示す概略図である。

【図１１】第１、第２の実施形態で使用するヘッダの構
成例を示す概略図である。

【図１２】第２の実施形態で使用する受信用メールボッ
クスの論理的構成例を示す概略図である。

【図１３】第２の実施形態で使用する受信確認サーバの
主要部の構成例を示す概略図である。

【図１４】第２の実施形態で使用する決済サーバの主要
部の構成例を示す概略図である。

【符号の説明】

１０、８０…通信システム、１１…インターネット、１
２，１３…携帯電話ネットワーク、１４…プリンタネッ
トワーク、２０，２１…メール配送サーバ、２２〜２４
…メールボックスサーバ、２５…受信確認サーバ、３０
…送信元端末、３４…決済サーバ、４３…ＭＩＭＥヘッ
ダ解析部、５２…添付ファイル削除部、５３…本体ファ
イル蓄積部、５５…メールボックス処理部、７０…本体
ファイル削除部、７１…添付ファイル蓄積部、４７、６
３、７３…メール処理部、７６…印刷出力部、ＭＥ１、
ＭＥ１１、ＭＥ１２、ＭＥ２１、ＭＥ２２、ＭＡ１、Ｍ
Ｋ１、ＤＭ１…電子メール、ＭＢＵＸ…受信用メールボ
ックス、ＦＤ１０〜ＦＤ２３…フィールド。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 河野 光明 東京都港区芝公園２−４−１ 東芝テック 株式会社芝事業所内 (72)発明者 レオンハルト・ゲルブリッヒ 東京都港区芝公園２−４−１ 東芝テック 株式会社芝事業所内 (72)発明者 原田 寛史 東京都港区芝公園２−４−１ 東芝テック 株式会社芝事業所内 (72)発明者 猪口 綾 東京都港区芝公園２−４−１ 東芝テック 株式会社芝事業所内 (72)発明者 新谷 宏志 東京都港区芝公園２−４−１ 東芝テック 株式会社芝事業所内 (72)発明者 山口 浩志 東京都港区芝公園２−４−１ 東芝テック 株式会社芝事業所内 (72)発明者 小倉 一泰 神奈川県川崎市幸区柳町70番地 東芝テッ ク株式会社柳町事業所内 (72)発明者 岩瀬 章則 神奈川県川崎市幸区柳町70番地 東芝テッ ク株式会社柳町事業所内 (72)発明者 稲葉 美穂 東京都目黒区青葉台４−７−７ 東芝オ ー・エー・コンサルタント内 Ｆターム(参考） 5K030 GA18 HA06 HC01 JT09 LE14 5K067 AA21 BB04 DD51 EE02 FF02 HH23 KK15

Claims (17)

【特許請求の範囲】
1. 【請求項１】 電子メールの送信元となる第１の通信端
   末と、 この第１の通信端末から送信される電子メールを少なく
   とも第１の部分と第２の部分とに分割する分割手段と、 前記電子メールの第１の部分を蓄積する蓄積手段と、 この蓄積手段に蓄積された前記電子メールの前記第１の
   部分を印刷する印刷手段と、 前記電子メールの第２の部分を受信するとともに、前記
   蓄積手段に蓄積されている第１の部分を前記印刷手段か
   ら印刷する要求を出力する第２の通信端末と、からなる
   メール通信システム。
2. 【請求項２】 請求項１に記載のメール通信システムで
   あって、 前記第１の通信端末から送信される電子メールのサイズ
   を検知する検知手段をさらに具備してなり、 前記分割手段は、この検知手段の検知結果に応じて前記
   電子メールを少なくとも第１の部分と第２の部分とに分
   割することを特徴とするメール通信システム。
3. 【請求項３】 請求項１に記載のメール通信システムで
   あって、 前記第１の通信端末から送信される電子メールの構成を
   検知する検知手段をさらに具備してなり、 前記分割手段は、この検知手段の検知結果に応じて前記
   電子メールを少なくとも第１の部分と第２の部分とに分
   割することを特徴とするメール通信システム。
4. 【請求項４】 請求項３に記載のメール通信システムで
   あって、 前記検知手段は前記電子メールが本文と添付ファイルと
   によって構成されていることを検知することを特徴とす
   るメール通信システム。
5. 【請求項５】 請求項１に記載のメール通信システムで
   あって、 前記蓄積手段に蓄積された前記電子メールの前記第１の
   部分を、前記印刷手段が印刷可能な形態に変換した後前
   記印刷手段に送信する変換手段をさらに具備したことを
   特徴とするメール通信システム。
6. 【請求項６】 請求項１に記載のメール通信システムで
   あって、 前記蓄積手段に前記電子メールの前記第１の部分が蓄積
   されていることを前記第２の通信端末に対して報知する
   報知手段をさらに具備したことを特徴とするメール通信
   システム。
7. 【請求項７】 電子メールの送信元となる第１の通信端
   末と、 この第１の通信端末から送信される電子メールを少なく
   とも第１の部分と第２の部分とに分割する分割手段と、 前記電子メールの第１の部分を蓄積する蓄積手段と、 この蓄積手段に蓄積された前記電子メールの前記第１の
   部分を印刷可能な複数の印刷手段と、 前記電子メールの第２の部分を受信するとともに、前記
   蓄積手段に蓄積されている第１の部分を前記複数の印刷
   手段のうちの特定の印刷手段から印刷する要求を出力す
   る第２の通信端末と、 この第２の通信端末から前記電子メールの前記第１の部
   分の印刷要求が出力されたとき、前記蓄積手段に蓄積さ
   れている前記電子メールの前記第１の部分を、前記第２
   の通信端末から要求された特定の印刷手段に送信する制
   御手段と、からなるメール通信システム。
8. 【請求項８】 請求項７に記載のメール通信システムで
   あって、 前記第１の通信端末から送信される電子メールのサイズ
   を検知する検知手段をさらに具備してなり、 前記分割手段は、この検知手段の検知結果に応じて前記
   電子メールを少なくとも第１の部分と第２の部分とに分
   割することを特徴とするメール通信システム。
9. 【請求項９】 請求項７に記載のメール通信システムで
   あって、 前記第１の通信端末から送信される電子メールの構成を
   検知する検知手段をさらに具備してなり、 前記分割手段は、この検知手段の検知結果に応じて前記
   電子メールを少なくとも第１の部分と第２の部分とに分
   割することを特徴とするメール通信システム。
10. 【請求項１０】 請求項９に記載のメール通信システム
    であって、 前記検知手段は前記電子メールが本文と添付ファイルと
    によって構成されていることを検知することを特徴とす
    るメール通信システム。
11. 【請求項１１】 請求項７に記載のメール通信システム
    であって、 前記蓄積手段に蓄積された前記電子メールの前記第１の
    部分を、前記印刷手段が印刷可能な形態に変換した後、
    前記第２の通信端末により特定された印刷手段に送信す
    る変換手段をさらに具備したことを特徴とするメール通
    信システム。
12. 【請求項１２】 請求項７に記載のメール通信システム
    であって、 前記蓄積手段に前記電子メールの前記第１の部分が蓄積
    されていることを前記第２の通信端末に対して報知する
    報知手段をさらに具備したことを特徴とするメール通信
    システム。
13. 【請求項１３】 第１の部分とこの第１の部分に関連す
    る第２の部分からなる電子メールの送信元となる第１の
    通信端末と、 前記電子メールの第１の部分を蓄積する蓄積手段と、 この蓄積手段に蓄積された前記電子メールの前記第１の
    部分を印刷する印刷手段と、 前記電子メールの第２の部分を受信するとともに、前記
    蓄積手段に蓄積されている第１の部分を前記印刷手段か
    ら印刷する要求を出力する第２の通信端末と、からなる
    メール通信システム。
14. 【請求項１４】 請求項１３のメール通信システムにお
    いて、 前記第２の通信端末は携帯通信端末であり、 前記印刷手段から印刷される第１の部分の内容に応じ
    て、当該携帯通信端末から電子決済を実行することを特
    徴とするメール通信システム。
15. 【請求項１５】 請求項１３のメール通信システムにお
    いて、 前記印刷手段は、 電子決済を受け付ける電子決済受付部を備え、 前記印刷手段から印刷される第１の部分の内容に応じ
    て、当該電子決済受付部から電子決済を実行することを
    特徴とするメール通信システム。
16. 【請求項１６】 請求項１４または１５のメール通信シ
    ステムにおいて、 前記印刷手段は、 前記第１の部分を印刷したときに、当該第１の部分が印
    刷されたことを示す電子メールである印刷確認メール
    を、前記送信元へ返送する印刷確認通知部を備えること
    を特徴とするメール通信システム。
17. 【請求項１７】 印刷手段と蓄積手段が多機能プロトコ
    ルによって接続されている場合の請求項１４または１５
    のメール通信システムにおいて、 前記蓄積手段は、 前記多機能プロトコルによって前記第１の部分が印刷手
    段に受信されたことを記録する受信記録部を備え、 当該蓄積手段には、当該蓄積手段に対して前記印刷手段
    と同等なインタフェースを有する受信確認手段が接続さ
    れ、 当該受信確認手段は、前記送信元から受信確認要求メー
    ルがもたらされると、前記受信記録部の内容を読み出し
    て、当該内容を収容した電子メールである受信確認メー
    ルを自動的に生成し、当該送信元に宛てて送信する受信
    確認通知部を備えることを特徴とするメール通信システ
    ム。