JP4656671B2 - 画像通信装置およびその制御方法 - Google Patents

Description

本発明は、一般に画像データの通信技術に係り、とりわけ画像データを電子メールに添付して送受信する画像通信技術に関する。

近年、コンピュータが普及し、情報のネットワーク化が進むにつれ、文字情報をネットワークで送受信する電子メールは必須の情報通信ツールへと成長した。

この電子メールには文字情報により構成されるメール本文の他に、さまざまな形式のファイルを添付することが可能である。例えば、現在普及し始めているインターネットＦＡＸ（以降ＩＦＡＸと略す。）では、ＴＩＦＦ（Ｔａｇ Ｉｍａｇｅ ＦｉｌｅＦｏｒｍａｔ）形式の画像ファイルを電子メールに添付して画像データを送受信している。なお、複数のＩＦＡＸ機器間において、電子メールに画像データを添付して送信する処理をＩＦＡＸ送信モードと呼ぶことにする。

ＩＦＡＸは、送信機においてスキャナにより読み取られた画像データをＴＩＦＦ形式の画像データに変換して送信し、受信機において受信された画像データをＴＩＦＦ形式に従って再生、印刷するための技術である。ＴＩＦＦは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ）により策定された規格であり、正式にはＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２３０１と呼ばれている。

このＴＩＦＦ形式の画像は、機器にとって比較的に処理しやすいデータ構成を有している。一方で、パーソナルコンピュータ（ＰＣ）上の汎用アプリケーションではこの規格をサポートしていない場合も多い。そのため、ＩＦＡＸ機器から一般の電子メールアドレスに対してカラーＴＩＦＦ形式の画像データを送信した場合、ＰＣ上の汎用アプリケーションがＴＩＦＦ形式の画像データをサポートしておらず、受信したカラー画像データを表示できないことがあった。

これを解決するには、ＩＦＡＸ機器に、上述のＩＦＡＸモードに加え、一般の電子メールアドレスを宛先として送信するＥｍａｉｌ送信モードを搭載することが考えられる。この関連技術のＥｍａｉｌ送信モードでは、ＰＣアプリケーションとの親和性が高い画像形式へと画像データを変換して送信すればよい。

特開平８−２４２３２６号公報 第５頁ないし第１５頁、段落００３１および図１０など

ＲＦＣ８２１ ＲＦＣ２８２１ ４．４ Ｔｒａｃｅ Ｉｎｆｏｒｍａｔｉｏｎ

ところで、ＩＦＡＸ機能が搭載された送信機から画像データの添付された電子メールを送信する際には、常に機器専用の電子メールアドレスを使用することが前提となっている。従って、送信者が誰であるかを特定することができない。

また、Ｅｍａｉｌ送信モードで送信された電子メールは、基本的にはＰＣ上の電子メールアプリケーションにより受信されることになる。一般に、電子メールアプリケーションは、添付ファイルだけでなく、メールの送信者、件名、時刻などの情報も詳細に表示することができる。よって、ＩＦＡＸ機器から一般の電子メールアドレスに対して画像付きの電子メールを送信すれば、受信側の電子メールアプリケーションにおいて、機器専用の電子メールアドレスが差出人として表示されるとこになるため、送信に使用された機器を特定できるが、送信人物を特定することはできない。

このように、ＩＦＡＸ機器から画像付きの電子メールを送信すると、送信者のメールアドレス（Ｆｒｏｍアドレス）には、機器専用の電子メールアドレスが設定されているため、送信機器を特定することはできるが、肝心の送信人物が誰であるかを特定することはできない。従って、上述の関連技術は、セキュリティの観点から好ましくない。特に、１つのＩＦＡＸ機器を多数の人間が使用するような環境で、この問題は顕在化しよう。

そこで、本発明の一つの目的は、電子メールプロトコルを用いて画像データを送信する画像通信装置において、送信に責任を持つべき本来の送信人物を特定可能な技術を提供することにある。

また、従来は次の技術が知られているに過ぎなかった。一般的な電子メールにおいて、送信者の席にあるＰＣに割り当てられたメールアドレスを発信元メールアドレスに設定して電子メール送信し、もしこの電子メールの送信がエラーとなると、この発信元メールアドレスに対して配信失敗メールを送信していた（特許文献１）。なお、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ）により策定されたＲＦＣ８２１（非特許文献１）によれば、ＭＡＩＬコマンドにより指定された電子メールアドレスに対して、エラーを通知するように義務付けられている。一方、ＲＦＣ８２１の改訂版であるＲＦＣ２８２１（非特許文献２）によれば、受信者のメールボックスを有するメールサーバが、ＭＡＩＬコマンドにより指定された電子メールアドレスを、電子メールのＲｅｔｕｒｎ−ｐａｔｈヘッダに設定するよう義務付けられている。また、ＳＭＴＰ以外の処理においてメール配信にエラーが発生した場合には、このＲｅｔｕｒｎ−ｐａｔｈヘッダに記述されている電子メールアドレスにエラーを通知するよう義務付けられている。

さらに、上述のＩＦＡＸのエラーメールを受信した場合には、何らかの手段により、どの送信メールがエラーになったのかを容易に把握できるようにすることが望ましいだろう。

そこで、本発明の他の目的は、メール配信プロトコルを用いて画像データを送信する画像通信装置において、メール配信の際にエラーが発生した場合には、当該画像通信装置にエラーを通知できるようにすることである。

なお、上述した以外の目的は、明細書の全体から把握できよう。

上記目的を達成するために、本願に係る第１の発明は以下の構成を特徴とする。すなわち本発明に係る画像通信装置は、例えば、画像データを電子メールに添付して送信する画像通信装置であって、前記画像通信装置に対応する第１のメールアドレスを格納する格納手段と、前記電子メールの送信者に対応する第２のメールアドレスを取得する取得手段と、前記取得手段により取得された前記第２のメールアドレスを前記電子メールのヘッダ部に設定する設定手段と、前記取得手段により取得された前記第２のメールアドレスがヘッダ部に設定された前記電子メールを、ＳＭＴＰプロトコルに従ってメールサーバに送信する送信手段と、を備え、前記取得手段により取得された前記第２のメールアドレスがヘッダ部に設定された前記電子メールを前記送信手段が送信するためのセッションにおいて、前記送信手段は、前記格納手段に格納された前記第１のメールアドレスを、ＳＭＴＰプロトコルで用いられるＭＡＩＬコマンドで前記メールサーバに通知することを特徴とする画像通信装置。

本発明によれば、電子メールプロトコルを用いて画像データを送信する画像通信装置において、送信に責任を持つべき本来の送信者に関する情報を付加して画像データを送信するため、画像を送信したことに責任を有すべき人物を特定することが可能となった。

図１は、本発明の実施形態に係るネットワーク接続環境の一例を示す図である。 図２は、ＭＦＰ１００の構成例を示すブロック図である。 図３はＭＦＰ１００が所有するネットワークプログラムの階層構造の一例を示す図である。 図４は認証サーバ１０２に登録されているユーザ情報とその内容を参照・編集するプログラムの編集画面の一例を示す図である。 図５は、ユーザがＭＦＰ１００やＭＦＰ１０１を使用するときの認証処理の一例についてのフローチャートである。 図６は、認証サーバ１０２への認証処理（Ｓ５０３）の一例をより詳細に示した図である。 図７は、画像データを電子メールで送信する際に表示される送信設定画面の一例を示した図である。 図８は、宛先情報を管理するためのアドレス帳の一例を示した図である。 図９は、画像データを電子メールに添付して送信する処理の一例を示したフローチャートである。 図１０は、ＩＦＡＸモードで送信する際に実行される画像ヘッダ付与処理（Ｓ９０４）の一例を説明するための図である。 図１１は、第２の実施形態に係る画像データを電子メールに添付して送信する際の処理例を示したフローチャートである。 図１２は、本実施形態に係る電子メールデータの一例を示す図である。 図１３は、本実施形態に係るＳＭＴＰ送信シーケンスの一例を示す図である。 図１４は、本実施形態に係るＳＭＴＰ受信シーケンスの一例を示す図である。 図１５は、本実施形態に係るメールデータ（図１４の１４１４から１４１６）の一例を示す図である。

以下に本発明の一実施形態を示す。もちろん以下の実施形態は、上位概念として開示される本発明の下位概念にすぎない。すなわち、以下の実施形態は、特許請求の範囲によって確定される本願発明の技術的範囲に含まれるほんの一部の実施形態にすぎないのである。従って、本願の明細書又は図面に開示された上位概念たる発明であって、特許請求の範囲に記載された発明と技術思想が共通すれば、たとえ本願明細書又は図面に直接的に記載されていない実施形態であっても本願発明の技術的範囲に包含される。

なお、以下の実施形態に記載する下位概念の発明について、そのすべてが特許請求の範囲に記載されているとは限らない。ただし、これは特許発明の技術的範囲から意識的に除外したのではなく、特許発明と均等の関係にあるため特許請求の範囲には記載していない場合があることを理解していただきたい。

［第１の実施形態］
図１は本発明の実施形態に係るネットワーク接続環境を示す図である。１００、１０１のＭＦＰ（Ｍｕｌｔｉ ＦｕｎｃｔｉｏｎＰｅｒｉｐｈｅｒａｌ）は、スキャナ、プリンタを搭載したマルチファンクション複写機である。このマルチファンクション複写機は、コピー機能、ＦＡＸ送受信機能、及びコンピュータ上で作成されたデータを印刷するプリンタ機能などを備えている。

ＭＦＰ１００、ＭＦＰ１０１はドメイン名ｘｙｚ．ｃｏ．ｊｐというネットワークに接続され、認証サーバ１０２、第１のＭａｉｌ・ＰＯＰサーバ１０３、ＰＣ１０４などの複数のコンピュータ、及び他のネットワーク機器と接続されている。

このネットワークはさらには全世界に広がるインターネット網１１０と接続し、さらにａｂｃ．ｃｏ．ｊｐというネットワークにも接続している。ａｂｃ．ｃｏ．ｊｐというネットワークには、第２のＭａｉｌ・ＰＯＰサーバ１２０、ＰＣ１２１、インターネットＦＡＸ１２２などが接続されている。

ＭＦＰ１００は、ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐというＨＯＳＴ名と、ｉｆａｘ＠ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐという機器の電子メールメールアドレスが付与されている。一方、ＭＦＰ１０１は、ｃｏｐｙ２．ｘｙｚ．ｃｏ．ｊｐというＨＯＳＴ名とｉｆａｘ＠ｃｏｐｙ２．ｘｙｚ．ｃｏ．ｊｐという機器の電子メールアドレスが付与されている。

認証サーバ１０２はこのドメイン内のユーザ認証を行うための認証サーバである。認証サーバ１０２は、このドメイン内で有効なユーザ名、パスワードを記憶している。例えば、クライアントＰＣ１０４の電源が立ち上げられると、クライアントＰＣ１０４はユーザ名、パスワードの入力をユーザに要求する。クライアントＰＣ１０４は、ユーザ名、パスワードが入力されると、認証サーバ１０２に対してユーザ名、パスワードが一致しているかどうか問い合わせる。認証サーバ１０２は、この問い合わせに応じ、入力されたユーザ名、パスワードがユーザデータベースに登録されているか否かを判定する。登録されていれば、ＰＣ１０４に対して認証完了を通知する。ＰＣ１０４は、認証完了通知を受信しことを確認すると、使用できる状態となる。なお、この認証処理は、ＭＦＰを使用する際にも実行される。

ＰＣ１０４には汎用電子メールソフトがインストールされている。ここでは、ｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐというメールアドレスが付与されているものとする。

Ｍａｉｌ・ＰＯＰサーバ１０３及び１２０は、ＭａｉｌサーバとＰＯＰサーバの双方の機能を備えたサーバである。

ＰＣ１０４からｐｃｍａｉｌ＠ａｂｃ．ｃｏ．ｊｐ宛に電子メールを送信する場合、ＰＣ１０４で作成された電子メールデータはＭａｉｌサーバ１０３にＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）プロトコルを用いて送信される。Ｍａｉｌサーバ１０３は、この電子メールデータを宛先情報に従い、Ｍａｉｌサーバ１２０へ向けて送信する。

ＰＣ１２１にも汎用電子メールソフトがインストールされている。ＰＣ１２１上で起動された汎用電子メールソフトは、ＰＯＰ３（Ｐｏｓｔ ＯｆｆｉｃｅＰｒｏｔｏｃｏｌ−Ｖｅｒｓｉｏｎ ３）プロトコルを用いてメールが届いているかチェックする。メールが届いている場合はメールデータを受信する。

ＰＣ１２１のｐｃｍａｉｌ＠ａｂｃ．ｃｏ．ｊｐからＰＣ１０４のｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐにメールを送信する場合は、逆のルートをたどる。すなわち、ＰＣ１２１で作成されたデータはＭａｉｌサーバ１２０を経由し、Ｍａｉｌサーバ１０３に送られる。ＰＣ１０４は、届けられた電子メールデータを、ＰＯＰ３プロトコルを使用して受信する。

ＭＦＰ１００、ＭＦＰ１０１にはＩＦＡＸ受信機能により受信された画像、スキャナで読み取られた白黒画像又はカラー画像を他の通信機器に送信することができる。画像データの送信に関しては複数のモードが存在する。例えば、一般の電子メールアドレスを宛先として送ることを前提としたＥｍａｉｌ送信モードと、ＩＦＡＸ規格に従った装置に送信することを前提としたＩＦＡＸ送信モードなどある。なお、いずれのモードでも送信／受信にはＳＭＴＰ、ＰＯＰ３が使われ、上記説明した送信／受信と同様の動作を行う。

Ｅｍａｉｌ送信モードでは、ＪＰＥＧ（Ｊｏｉｎｔ ＰｈｏｔｏｇｒａｐｈｉｃＥｘｐｅｒｔｓＧｒｏｕｐ）ファイルフォーマットの画像データが作成され、電子メールに添付されて送信される。例えば、ｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐのクライアントＰＣにカラー画像付きの電子メールが送信された場合には、ＰＣ１０４の汎用電子メールソフトがこの電子メールを受信し、汎用画像ビューアでＪＰＥＧ画像を表示することができる。なお、本発明はＪＰＥＧに限定されることはなく、他のフォーマットが用いられてもよい。

一方、ＩＦＡＸ送信モードでは、ＲＦＣ２３０１に従ったＴＩＦＦ形式の画像データが作成され、電子メールに添付されて送信される。ＩＦＡＸ規格に従ったＭＦＰ１００、ＭＦＰ１０１やインターネットＦＡＸ１２２で画像を受信し、出力できる。

このように、カラー画像が扱える機器同士の場合、ＴＩＦＦ形式の画像データを送受信することになるが、汎用画像ビューアではＴＩＦＦ形式の画像データをサポートしていない場合が多い。従って、この画像を誤ってｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐのＰＣ１０４に送った場合には、ＴＩＦＦ形式の画像データをサポートしていない汎用画像ビューワではこの画像を表示することが出来ない。

図２はＭＦＰ１００の構成例を示すブロック図である。ＣＰＵ２３０はＲＯＭ２３１に格納されているプログラムとＲＡＭ２３２のメモリを利用してシステム全体の制御を実施する制御回路である。

操作部２３３は、ＬＣＤ表示パネルとスタートキー、テンキーなどのハードキーを含んでいる。例えば、ＬＣＤ上にソフト的にボタンを表示し、当該ボタンをユーザが指でタッチしたことを検出し、ユーザオペレーションを円滑に実行するための回路が含まれてもよい。

スキャナ２３４は、光電変換により原稿の画像データを電気データに変換する回路である。原稿給送装置（不図示）から原稿がプラテンガラス上へ搬送されると、ランプを点灯し、スキャナユニットの移動を開始させて、原稿を露光走査する。原稿からの反射光は、ミラー、及びレンズによってＣＣＤイメージセンサへ導かれ、そこで電気信号に変換され、Ａ／Ｄ変換回路によってデジタルデータに変換される。原稿の読み取り動作終了後、プラテンガラス上の原稿は排紙される。

プリンタ部２３５は電気的画像データを記録紙に印刷する回路である。電気的画像データに応じたレーザ光がレーザ発光部から出力される。このレーザ光は感光ドラムに照射される。感光ドラム上にはレーザ光に応じた潜像が形成される。

感光ドラムの潜像の部分には現像器によって現像剤が付着される。レーザ光の照射開始と同期したタイミングで、給紙カセットから記録紙を給紙して転写部に搬送し、感光ドラムに付着された現像剤を記録紙に転写する。現像剤が転写された記録紙は、定着部に搬送され、定着部の熱と圧力により現像剤が記像紙に定着される。定着部を通過した記録紙は排出ローラによって排出される。ソータは排出された記録紙をそれぞれのビンに収納して記録紙の仕分けを行う。

画像処理回路２３６は、大容量の画像メモリ、画像回転回路、解像度変倍回路、ＭＨ（Ｍｏｄｉｆｉｅｄ Ｈｕｆｆｍａｎ）、ＭＲ（ＭｏｄｉｆｉｅｄＲＥＡＤ）、ＭＭＲ（Ｍｏｄｉｆｉｅｄ Ｍｏｄｉｆｉｅｄ ＲＥＡＤ）、ＪＢＩＧ（Ｊｏｉｎｔ Ｂｉ−ｌｅｖｅｌ Ｉｍａｇｅ ＥｘｐｅｒｔｓＧｒｏｕｐ）及びＪＰＥＧなどの符号／復号化回路などで構成され、シェーディング、トリミング又はマスキングなどの各種画像処理も実行する。

ハードディスク２３７は、ＳＣＳＩ、ＵＳＢなどのＩ／Ｆで接続されている大容量記録装置である。なお、ハードディスク２３７に代えてＭＯなどの他の記録装置を搭載してもよい。

ネットワークＩ／Ｆ２３８は、ネットワークデータリンク処理を実行する回路である。例えば、１０ＢＡＳＥ−Ｔ、１００ＢＡＳＥ−Ｔを代表とするイーサネット(登録商標）やトークンリングなどのネットワーク回線と接続するための処理を実行する。

フォーマッタ部２３９は、ＩＥＥＥ１２８４準拠のパラレルインタフェース、ＵＳＢなどのＰＣ Ｉ／Ｆ回路を備え、これらのＰＣＩ／Ｆ回路あるいはネットワークＩ／Ｆ２３８で受信したパソコンからのＰＤＬ（Ｐａｇｅ ＤｅｓｃｒｉｐｔｉｏｎＬａｎｇｕａｇｅ）データに基づいて画像データを作成するレンダリング回路である。この画像データは、画像処理回路２３６で画像処理が行われ、プリンタ２３５から印刷出力される。

ファクス部２４０は、電話回線と接続するためのＮＣＵ（Ｎｅｔｗｏｒｋ ＣｏｎｔｒｏｌＵｎｉｔ）やＭＯＤＥＭ（ＭＯｄｕｌａｔｏｒ／ＤＥＭｏｄｕｌａｔｏｒ）などの回路で構成されるファクスＩ／Ｆ回路である。例えば、スキャナ２３４により読み取られた画像データを画像処理回路２３６で画像処理を行い、電話回線を経由して他のＦＡＸ機器に送信する。あるいは他のＦＡＸから送信されたデータを受信して画像処理回路２３６により画像処理を行ってプリンタ２３５で印刷する。

スキャナ２３４、プリンタ２３５、画像処理回路２３６、フォーマッタ部２３９及びファクス部２４０は、ＣＰＵ２３０からのＣＰＵバスとは別の高速ビデオバスで接続され、画像データを高速に転送できるように構成されている。

スキャナ２３４により読み取られた画像データを、画像処理回路２３６で画像処理を行い、プリンタ２３５で印刷することで、上述のコピー機能が実現される。

ＭＦＰ１００にはスキャナ２３４により読み取られた画像データを、画像処理回路２３６で画像処理を行い、ネットワークＩ／Ｆからネットワーク上に送信するＳｅｎｄ機能や、画像処理回路２３６でＲＦＣ２３０１に従った画像データを作成し、電子メールプロトコルでデータを送受信するＩＦＡＸ機能が搭載されている。

図３はＭＦＰ１００が所有するネットワークプログラムの階層構造を示す図である。図からわかるように、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）３００、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ ＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）３０１、アプリケーション階層のプログラム３０２の３階層から構成されている。

ＩＰ３００はインターネットのプロトコル階層である。具体的には、ＩＰ３００は、ルータなどの中継ノードと連携しながらメッセージを発信ホストから宛先ホストヘと転送するサービスを提供する。ＩＰ３００は、データを送信する発信元のアドレス、データを受信する宛先のアドレスを管理し、さらにアドレス情報に従って送信元ホストから宛先ホストまでのネットワーク経路を選択して転送するルーティング処理を担当している。

ＴＣＰ／ＵＤＰ３０１は、トランスポート階層に相当する。具体的には、発信側のアプリケーションプロセスから受信側のアプリケーションプロセスへとメッセージを送り届けるサービスを提供している。ＴＣＰはコネクション型サービスを提供するプロトコルであり、通信の高度な信頼性を保証している。ＵＤＰはコネクションレス型のサービスを提供するプロトコルであり、信頼性の保証を行わない。

アプリケーション階層のプロトコル３０２は、複数のプロトコルが規定されている。例えば、このプロトコルには、ファイル転送サービスであるＦＴＰ（Ｆｉｌｅ ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）、ネットワーク管理プロトコルであるＳＮＭＰ、プリンタ印刷用のサーバプロトコルであるＬＰＤ、ＷＷＷ（Ｗｏｒｌｄ ＷｉｄｅＷｅｂ）サーバのプロトコルであるＨＴＴＰｄ、電子メール送受信プロトコルであるＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）、メールダウンロードプロトコルであるＰＯＰ３（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ−Ｖｅｒｓｉｏｎ ３）などが存在する。

またＲＦＣ１５１０で規定されているＫｅｒｂｅｒｏｓ認証プログラムも搭載されている。

図４は、認証サーバ１０２に登録されているユーザ情報とその内容を参照・編集するプログラムの編集画面を示している。また、認証サーバ１０２には、ユーザ情報を管理するユーザデータベースを備えている。ユーザ情報としては、例えば、ユーザ名４３０、パスワード４３１及び電子メールアドレスが含まれている。

ユーザ名４３０は、認証サーバ１０２が受け持つｘｙｚ．ｃｏ．ｊｐというドメイン・プリンシパル内に接続されたコンピュータを操作可能なユーザのユーザ名が格納されている。図３に示す例では、ｓｙａｉｎ１〜ｓｙａｉｎ５のユーザが登録されている。パスワード４３１は、各ユーザ名に対応するパスワードが登録されている。なお、容易に見えないように＊＊＊＊＊でマスク表示されている。電子メールアドレス４３２は、登録されているユーザが使用できる電子メールアドレスが登録されている。第１のユーザであるｓｙａｉｎ１の電子メールアドレスはｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐである。また、ｓｙａｉｎ２〜５についても、同様にユーザ名と対応付けて電子メールアドレスが登録されている。

編集画面に含まれる追加キー４４０は、新規にユーザ登録する時に使用するキーであり、削除キー４４１は登録ユーザを削除するためのキーである。プロパティキー４４２を押すと、登録されている内容が表示され、表示された登録内容を修正することができる。

図５は、ユーザがＭＦＰ１００やＭＦＰ１０１を使用するときの認証処理に関するフローチャートである。すなわち、ＭＦＰ１００やＭＦＰ１０１は認証処理に成功した正規のユーザだけが使用できるようになっている。

ステップＳ５００において、ＭＦＰ１００、ＭＦＰ１０１の主電源が投入されると、ＣＰＵ２３０は、メモリ、Ｉ／Ｏポートの初期化などのイニシャライズ動作を実行する。このとき、システムユーザの設定において「ユーザ認証」を「する」に設定されていると、ＣＰＵ２３０は、操作部２３３のＬＣＤにログイン画面を表示する。なお、ログイン画面にはユーザ名を入力するための欄が設けられている。なお、ユーザ認証が完了するまでは、ユーザのオペレーションが介在するコピーなどの処理は、ＣＰＵ２３０が禁止しているものとする。

ステップＳ５０１において、操作部２３３からユーザ名が入力されると、ＣＰＵ２３０は、パスワードの入力画面を操作部２３３に表示し、入力待ちとなる。

ステップＳ５０２において、操作部２３３からパスワードが入力されると、ＣＰＵ２３０は、認証処理を開始する。

ステップＳ５０３において、ＣＰＵ２３０は、入力されたユーザ名、パスワードとともに認証要求を認証サーバ１０２に送信する。認証サーバ１０２は、認証要求を受信すると認証の対象となっているユーザ名、パスワードがユーザデータベースに登録されているものと同一であるかを判定し、認証結果を返信する。

ステップＳ５０４において、ＣＰＵ２３０は、認証サーバ１０２から受信した認証結果が認証ＯＫであるかを判定する。ユーザ認証した結果、認証ＯＫである場合は、ステップＳ５０５に進む。認証ＮＧであれば、ステップＳ５０１に戻る。

ステップＳ５０５において、ＣＰＵ２３０は、ログインしたユーザの電子メールアドレスなどのユーザ情報を認証サーバ１０２から取得する。なお、このユーザ情報は、認証結果に含まれていてもよいし、認証ＯＫを確認した後に、ユーザ情報を送信するよう認証サーバ１０２に要求してもよい。

ステップＳ５０６において、ＣＰＵ２３０は、取得したユーザ情報をＲＡＭ２３２に記憶し、ログイン処理を終了する。ユーザ認証が正常終了するとコピー、ＳＥＮＤなどユーザオペレーションが介在する処理が実施できるようになる。

上述の説明では、ユーザ名とパスワードとを用いたユーザ認証方法を説明した。しかしながら本発明は認証方法に限定されるものではなく、例えば、指紋や眼球などによる生体認証方法を用いてもよいし、非接触又は接触型のコントロールカードを利用したユーザ認証方法を用いてもよいことは明らかであろう。

図６は、認証サーバ１０２への認証処理（Ｓ５０３）をより詳細に示した図である。認証サーバ１０２への認証処理は、ネットワークアプリケーション階層プログラム３０２のＫｅｒｂｅｒｏｓを用いて実行することができる。

Ｓ６００において、クライアントであるＭＦＰ１００から、ＫＥＢ＿ＡＳ＿ＲＥＱ（Ｋｅｒｂｅｒｏｓ認証サービスリクエスト）が認証サーバ１０２に送信される。ステップＳ６０１において、認証サーバ１０２は、ＫＥＢ＿ＡＳ＿ＲＥＰ（Ｋｅｒｂｅｒｏｓ認証サービス返信）をＭＦＰ１０１に送信する。このＫＥＢ＿ＡＳ＿ＲＥＰは、暗号化されたログオンセッションキー、クライアント認証データが含まれている。

ステップＳ６０２において、ＭＦＰ１０１は、受信したデータに基づいて、資格情報をリクエストするためのＫＥＢ＿ＴＲＧ＿ＲＥＱ（Ｋｅｒｂｅｒｏｓチケット認可サービスリクエスト）を作成し、認証サーバ１０２に送信する。ステップＳ６０３において、認証サーバ１０２は、ＫＥＢ＿ＴＲＧ＿ＲＥＰ（Ｋｅｒｂｅｒｏｓチケット認可サービス返信）する。これには、暗号化されたクライアント認証データ含まれている。

ステップＳ６０４において、ＭＦＰ１０１は、受信したデータに基づき、サービス利用許可を求めるためのＫＥＢ＿ＡＰ＿ＲＥＱ（Ｋｅｒｂｅｒｏｓアプリケーションリクエスト）を作成し、認証サーバ１０２に送信する。ステップＳ６０５において、認証サーバ１０２は、ＫＥＢ＿ＡＰ＿ＲＥＰ（Ｋｅｒｂｅｒｏｓアプリケーション返信）を返信する。ＭＦＰ１０１は、返信されたデータが正常で、かつ、返信データ内の時刻データが同一である場合は認証ＯＫと決定する。

なお、３つのリクエストを同一の認証サーバで行った例を用いて説明したが、ネットワークの構成などにより複数の認証サーバを使用してもよい。また、認証方式もＤＨ（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）認証など他の認証方式を採用してもよい。

図７は、画像データを電子メールで送信する際に表示される送信設定画面の例を示した図である。読み取りサイズの設定欄７００は、スキャナ２３４により読み込まれる原稿サイズを指定するための欄である。この欄に触れることで、設定変更画面が現れ、例えば、Ａ３、Ａ４、Ａ５、Ｂ４、Ｂ５、１１＊１７、ＬＴＲ、ＳＴＭＴなどの用紙サイズとその向きを指定することができる。自動を選択することもできる。自動と設定されている場合は、スキャナ２３４に搭載されている原稿検知センサーが検知した原稿サイズに従って、原稿が読み込まれる。

解像度の欄７０１は、スキャナ２３４が画像を読み込む際の読取解像度を指定するための欄である。この欄に触れることで、設定変更画面が現れ、例えば、２００＊１００、２００＊２００、２００＊４００、３００＊３００、４００＊４００、６００＊６００ｄｐｉなどの値を指定することができる。現在はデフォルト値の２００＊２００が設定されている。

詳細設定ボタン７０２が押されると、スキャン時の濃度設定、原稿タイプ指定、両面読み込み、ページ連写指定、画質調整など、スキャン処理のについて詳細動作を指定することができる。

宛先の欄７０３は、電子メールの宛先を指定することための欄であり、詳細は後述する。Ｓｕｂｊｅｃｔの欄７０４、電子メールに付ける件名を入力するための欄である。本文の欄７０５は、メール本文を入力するための欄である。これらの設定欄がタッチされると、ソフトキーボードが表示され、文字列を入力することができる。

図８は、宛先情報を管理するためのアドレス帳の例とともに宛先設定画面を示した図である。このアドレス帳には、電子メールアドレス８０２と、画像データの添付された電子メールを送信する際の送信モード８０１と、電子メールを送信するか否かを選択するための選択欄８００とが含まれている。

なお、アドレス帳はハードディスク２３７に記憶されている、アドレス帳編集画面を呼び出すことにより編集できる。編集画面では、電子メールアドレスと送信モードとを対応付けて入力できる。なお、アドレス帳は、各ＭＦＰごとに記憶されていてもよいし、いずれかのサーバに記憶しておくことで複数のＭＦＰが共有してもよい。

図８の宛先設定画面において、いずれかの電子メールアドレスを宛先として指定するには、当該電子メールアドレスに対応する選択欄をタッチすればよい。ＣＰＵ２３０は、操作部２３３からの検知信号に基づいて、タッチされた欄を、選択されたことを表す情報に変更する。また、選択された電子メールアドレスを、電子メールのＴｏ：フィールドに記載する。なお、送信が完了した場合には、選択欄はすべてクリアされる。

送信モード８０１としては、宛先が一般の電子メールアドレスであることを前提として送信するためのＥｍａｉｌ送信モードと、ＩＦＡＸ機能に対応している同種の装置に送信することを前提としたＩＦＡＸ送信モードのいずれかを指定することができる。なお、Ｅｍａｉｌ送信モードは、ＭＦＰ１００やＭＦＰ１０１とは異なり、ＩＦＡＸ機能に対応していない異種の装置に送信するためのモードと観念してもよい。

図８の宛先設定画面によれば、ｐｃｍａｉｌ＠ａｂｃ．ｃｏ．ｊｐと、ｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐとは、Ｅｍａｉｌ送信モードに設定されている。一方、ｉｆａｘ＠ａｂｃ．ｃｏ．ｊｐは、ＩＦＡＸ送信モードが指定されている。

図９は、画像データを電子メールに添付して送信する際の処理例を示したフローチャートである。

ステップＳ９００において、ＣＰＵ２３０は、操作部２３３において送信開始ボタンが操作されたことを検知する。

ステップＳ９０１において、ＣＰＵ２３０は、ハードディスク２３７に記憶されているアドレス帳を参照し、送信先として選択され電子メールアドレスの送信モードを読み出し、読み出された送信モードがＩＦＡＸ送信モードであるかを判定する。ＩＦＡＸであれば、ステップＳ９０２へ進み、そうでなければステップＳ９０５へ進む。

ステップＳ９０２において、ＣＰＵ２３０は、機器に割り当てられている電子メールアドレスをＲＯＭ２３１から読み出し、電子メールのＦｒｏｍフィールド（差出人フィールド）に設定する。

ステップＳ９０３において、ＣＰＵ２３０は、予め認証サーバ１０２から取得しＲＡＭ２３２に記憶しておいたユーザの電子メールアドレスを読み出して、読み出された電子メールアドレスをＳｅｎｄｅｒフィールド（送信者フィールド）に設定する。例えば、ｓｙａｉｎ１でログインしている場合は、ｓｙａｉｎ１に対応する電子メールアドレスであるｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐがＳｅｎｄｅｒフィールドに設定されることになる。このようにしてＦｒｏｍ、Ｓｅｎｄｅｒフィールドの設定が完了する。

ステップＳ９０４において、オプションの画像ヘッダの付与が指定されているときには、画像ヘッダの付与処理を実行する。この画像ヘッダ付与処理は、画像の上部などの目立たない場所に、送信者を特定するための情報などを埋め込む処理である。

ステップＳ９０５において、Ｅｍａｉｌ送信モードが指定されていた場合に、ＣＰＵ２３０は、ＲＡＭ２３２に記憶しておいたユーザの電子メールアドレスを読み出して、Ｆｒｏｍフィールドに設定する。なお、Ｓｅｎｄｅｒフィールドは未設定でもよいし、Ｆｒｏｍフィールドと同一のアドレスを設定してもよい。

ステップＳ９０６において、ＣＰＵ２３０は、ＭＩＭＥ情報を付与して、メール本文と添付ファイルとを分け、ＢＡＳＥ６４を用いて添付ファイルを符号化し、電子メールデータを作成する。なお、バイナリーデータの添付方法はこれに限られることはなく、uｕｅｎｃｏｄｅやＢｉｎＨｅｘなどの他のデータ変換方法を使用してもよい。

ステップＳ９０７において、ＳＭＴＰプロトコルを使用してＭａｉｌサーバ１０３に作成された電子メールデータを送信する。

ステップＳ９０８において、ＣＰＵ２３０は、ログイン時に指定されたユーザ名、送信宛先情報、送信日付、送信時間、送信枚数及びその結果をログファイルに書き込む。なお、ログファイルを作成することで、誰が送信したのかを容易に把握することができる。このログファイルは、送信結果を知らせるための送信結果レポートとして出力されてもよいし、送信件数が閾値を超えたときに送信管理レポートとして出力されてもよい。あるいは、操作部２３３からの操作に応じて随時表示できるようにしてもよい。

ステップＳ９０９において、ログファイルへの書き込みが終了すると送信動作を終了する。

図１０は、ＩＦＡＸモードで送信する際に実行される画像ヘッダ付与処理（Ｓ９０４）を説明するための図である。

この画像ヘッダは、例えば、送信日付１０００、送信時間１００１、送信ユーザ名１００２、送信者電子メールアドレス１００３、送信宛先の電子メールアドレス１００４、ページ番号１００５などの情報から構成することができる。

送信ユーザ名１００２には、ログインしたユーザの名称（例：ｓｙａｉｎ１）と同一である。よって、この画像ヘッダを参照することで、画像の受信者は、画像の送信責任者を把握することができる。

送信者電子メールアドレス１００３は、電子メールのＦｒｏｍフィールドに記載された電子メールアドレスと同一であり、機器の電子メールアドレスが設定される。これにより、この画像ヘッダを参照することにより画像の受信者は、送信機の電子メールアドレスを容易に把握できる。そして、原稿をスキャンして、この送信機の電子メールアドレスを宛先として設定してスキャン画像を送信すれば、従来のＦＡＸにおける操作体系を概ね維持しつつ、スキャン画像を返信できることになる。

宛先の電子メールアドレス１００４は、アドレス帳から選択された電子メールアドレスとなる。

ＣＰＵ２３０は、内蔵時計から送信日付１０００と送信時間１００１に関する情報を取得し、ＲＡＭ２３２に記憶されている送信者のユーザ名１００２を読み出し、ＲＯＭ２３１に記憶されている機器の電子メールアドレス１００３を読み出し、アドレス帳から宛先として選択されている電子メールアドレス１００４を読み出す。ＣＰＵ２３０は、これらの情報を画像ヘッダとして画像データに合成するだけでなく、ステップＳ９０８においてログファイルに書き込む。なお、情報の読み出し順序はどのような順序であってもよい。

以上説明した実施形態に基づいて本発明の種々の観点を説明する。本発明の第１の観点によれば、画像データを取得し電子メールに添付して通信する画像通信装置（例：ＭＦＰ１０１など）であって、前記電子メールに添付するための画像データを取得する取得手段（例：ＣＰＵ２３０、スキャナ２３４、フォーマッタ部２３９、ファクス部２４０又はネットワークＩ／Ｆ２３８など）と、前記画像通信装置と異種形態の装置（例：汎用の電子メールソフトをインストールしているＰＣ１２１など）に対して前記電子メールを送信する際には、前記電子メールを送信するユーザを特定可能な第１の電子メールアドレスを送信元アドレス（例：Ｓｅｎｄｅｒフィールド）として設定し、前記画像通信装置と同種形態の装置（例：ＩＦＡＸ機能を備えたインターネットＦＡＸ１２２など）に対して前記電子メールを送信する際には、前記第１の電子メールアドレスと、前記画像通信装置に関連する第２の電子メールアドレス（例：機器に割り当てられた電子メールアドレス）とを送信元アドレス（例：ＳｅｎｄｅｒフィールドとＦｒｏｍフィールド）として設定する電子メールアドレス設定手段（例：ＣＰＵ２３０）と、前記取得された画像データが添付された電子メールを前記設定された送信元アドレスを用いて送信する送信手段（例：ＣＰＵ２３０、ＳＭＴＰプロトコルなど）とを含む画像通信装置が提供される。

このように、ＩＦＡＸ機能を備えた複数の画像通信装置間で、画像データを添付して電子メールを送受信する際には、送信者であるユーザの電子メールアドレスをＳｅｎｄｅｒ（送信者）フィールドに記載してから電子メールを送信するため、受信者は送信者が誰であるかを特定しやすくなる。

また、本発明の第２の観点によれば、画像データを取得し電子メールに添付して通信する画像通信装置であって、前記画像通信装置と異種形態の装置に対して前記電子メールを送信する第１のモード（例：Ｅｍａｉｌ送信モード）と、前記画像通信装置と同種形態の装置に対して前記電子メールを送信する第２のモード（例：ＩＦＡＸ送信モード）と、前記電子メールに画像データを添付して送信する際に、前記第１のモード又は第２のモードのいずれで送信するかを選択する選択手段（例：ＣＰＵ２３０、Ｓ９０１）と、前記第２のモードが選択された場合には、前記電子メールを送信するユーザを特定可能な第１の電子メールアドレスと、前記画像通信装置に関連する第２の電子メールアドレスとを送信元アドレスとして設定する電子メールアドレス設定手段（例：ＣＰＵ２３０、Ｓ９０２及びＳ９０３など）と、前記取得された画像データが添付された電子メールを、前記設定された送信元アドレスを用いて送信する送信手段（例：ＣＰＵ２３０、Ｓ９０７など）とを含む画像通信装置が提供される。

このように、ＭＦＰ１０１などの画像通信装置が、Ｅｍａｉｌ送信モードとＩＦＡＸ送信モードなどの複数の送信モードを有しており、しかもＩＦＡＸ送信モードが選択された場合には、送信者であるユーザの電子メールアドレスをＳｅｎｄｅｒ（送信者）フィールドに記載してから電子メールを送信するため、受信者は送信者が誰であるかを特定しやすくなる。

本発明の第３の観点によれば、前記電子メールアドレス設定手段は、前記選択手段により前記第１のモード（例：Ｅｍａｉｌ送信モード）が選択された場合には、前記電子メールを送信するユーザを特定可能な第１の電子メールアドレスを送信元アドレス（例：Ｓｅｎｄｅｒフィールド）として設定するようにしてもよい。

すなわち、ＩＦＡＸ機能を備えたＭＦＰ１０１などから、一般の電子メールアドレスに対して画像データが送信されたときにも、送信者であるユーザの電子メールアドレスをＳｅｎｄｅｒ（送信者）フィールドに記載してから電子メールを送信するため、受信者は送信者が誰であるかを特定しやすくなる。なお、機器の電子メールアドレスも送信元アドレスに記載しておいてもよい。このようにすれば、一般の電子メールアドレスを通じて画像データを受信したユーザは、機器の電子メールアドレスに基づいてＩＦＡＸ機能を備えた機器から画像データが送信されたことを認識できよう。

本発明の第４の観点によれば、画像データを取得し電子メールに添付して通信する画像通信装置であって、前記画像通信装置の操作を許可されたユーザについての認証情報及び該ユーザを特定可能な電子メールアドレスを管理する認証サーバと連携して前記ユーザを認証する認証手段（例：ＣＰＵ２３０、Ｓ５０１〜Ｓ５０４など）と、前記認証手段により認証されたユーザに対応する電子メールアドレスを前記認証サーバから取得し（例：Ｓ５０５）、該取得された電子メールアドレスを前記電子メールの差出人フィールド又は送信者フィールドに設定する電子メールアドレス設定手段（例：ＣＰＵ２３０、Ｓ９０２又はＳ９０５）と、前記取得された画像データが添付された電子メールを、前記設定された送信元アドレスを用いて送信する送信手段（例：ＣＰＵ２３０、Ｓ９０７など）とを含む画像通信装置が提供される。

このように、認証されたユーザだけが画像データを送信でき、しかも、認証されたユーザの電子メールアドレスがＳｅｎｄｅｒフィールドに自動で記入されるため、上述の効果に加え、他人へのなりすましなども抑制でき、セキュリティも向上しよう。

なお、上述の第１乃至第３の観点に係る発明においても、前記ユーザが前記画像通信装置を利用する際に認証情報の入力を要求する要求手段（例：ＣＰＵ２３０、Ｓ５０１及びＳ５０２など）と、前記入力された認証情報に対応する電子メールアドレスを認証サーバから受信する受信手段（例：ＣＰＵ２３０、Ｓ５０５）とをさらに備え、前記電子メール設定手段は、前記認証サーバから受信した電子メールアドレスを送信元アドレスとして設定するようにしてもよい。

上記いずれかの画像通信装置は、前記ユーザを特定可能な情報と、前記画像通信装置を特定可能な情報のうち少なくとも一方を前記画像データに対して付加する付加手段（例：ＣＰＵ２３０、Ｓ９０４）をさらに備え、前記送信手段は、前記ユーザを特定可能な情報と、前記画像通信装置を特定可能な情報のうち少なくとも一方が付加された画像データを前記電子メールに添付して送信するようにしてもよい。

このように、画像データ自体にもユーザの名称や機器の電子メールアドレスが付加されていれば、古典的なＦＡＸ機器と同様の使い勝手を実現できる。さらに、送信者を特定できるため、セキュリティも向上しよう。

［第２の実施形態］
また、上述の画像通信装置において、前記第２のモードが選択された場合に、送信者の電子メールアドレスを送信元アドレスに設定する構成に代えて、前記電子メールを送信するユーザを特定可能な情報（例：ユーザ名１００２やユーザの電子メールアドレスなど）と、前記画像通信装置を特定可能な情報（例：機器の電子メールアドレス１００３など）とのうち少なくとも一方を前記画像データに付加する付加手段（例：ＣＰＵ２３０、Ｓ９０４）を備えてもよい。

この場合は、上述のステップＳ９０４が省略されることになるが、画像ヘッダには送信責任者を特定可能な情報が付加されているため、上述の目的を達成することができる。

［第３の実施形態］
図１１は、第２の実施形態に係る電子メールに画像データを添付して送信する際の処理例を示したフローチャートである。ここでは、図５に示したユーザ認証フローにおいて、ｓｙａｉｎ２というユーザ名にて認証が成功し、さらに、図７に示した送信設定が実施されているものとして説明する。

Ｓ１１００において、ＣＰＵ２３０は、操作部２３３に存在するスタートキー（図示せず）の押し下げを検知すると、送信処理を起動し、スキャナ２３４にセットされている送信原稿を読み取る。

Ｓ１１０１において、ＣＰＵ２３０は、送信宛先としてＩＦＡＸ宛先が設定されているかどうかを判定する。送信宛先がＩＦＡＸ宛先であれば、ステップＳ１１０２に進む。一方、送信宛先がＩＦＡＸ宛先ではない場合は、ステップＳ１１０４に進む。

ステップＳ１１０２において、ＣＰＵ２３０は、電子メールのＦｒｏｍフィールドに、ＩＦＡＸ機器（ＭＦＰ１００）に割り当てられている電子メールアドレスを設定する。例えば、ＩＦＡＸ機器の電子メールアドレスとして、ｉｆａｘ＠ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐという電子メールアドレスが設定されている場合は、ＩＦＡＸ宛先に送信する場合のＦｒｏｍフィールドには、ｉｆａｘ＠ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐが設定される。

ステップＳ１１０３において、ＣＰＵ２３０は、スキャナ２３４で読み取った画像に画像ヘッダ（図１０）を付与する。

ステップＳ１１０４において、ＣＰＵ２３０は、送信対象の電子メールのＦｒｏｍフィールドに、認証されたユーザの電子メールアドレス４３２を設定する。例えば、ユーザ名ｓｙａｉｎ２がログインしている場合は、Ｅｍａｉｌ宛先に送信する場合のＦｒｏｍフィールドには、ｓｙａｉｎ２＠ｘｙｚ．ｃｏ．ｊｐが設定される。

ステップＳ１１０５において、ＣＰＵ２３０は、電子メールのメールヘッダに電子メールの送信者を示すＸ−Ｓｅｎｄｅｒという拡張フィールドを追加し、その値として、ログインしているユーザの電子メールアドレス（図４に例示した電子メールアドレス４３２）を設定する。図４から明らかなように、ｓｙａｉｎ２がログインしている場合は、Ｘ−Ｓｅｎｄｅｒフィールドにはｓｙａｉｎ２＠ｘｙｚ．ｃｏ．ｊｐが設定される。

ステップＳ１１０６において、ＣＰＵ２３０は、電子メールのＳｕｂｊｅｃｔに“Ｆｒｏｍ ”という文字列と、ログインしているユーザのユーザ名４３０を設定する。例えば、ｓｙａｉｎ２がログインしている場合は、Ｓｕｂｊｅｃｔに“Ｆｒｏｍｓｙａｉｎ２”という文字列が設定される。

ステップＳ１１０７において、ＣＰＵ２３０は、電子メールの本文の先頭行に“Ｍｅｓｓａｇｅ Ｆｒｏｍ ”という文字列と、ユーザ名４３０を追加する。例えば、ｓｙａｉｎ２がログインしている場合は、メール本文の先頭行には“Ｍｅｓｓａｇｅ Ｆｒｏｍｓｙａｉｎ２”という文字列が挿入されることになる。

ステップＳ１１０８において、ＣＰＵ２３０は、電子メールに添付される送信ファイル名として、“Ｆｒｏｍ−”という文字列と、ユーザ名４３０とを適宜組み合わせて設定する。例えば、ｓｙａｉｎ２がログインしている場合は、送信ファイル名として、“Ｆｒｏｍ−ｓｙａｉｎ２．ｔｉｆ”という文字列が設定される。

ステップＳ１１０９において、ＣＰＵ２３０は、上述の各設定を反映させた送信対象の電子メールデータを作成する。

ステップＳ１１１０において、ＣＰＵ２３０は、作成した電子メールデータを、ＳＭＴＰプロトコルに従って送信する。

ステップＳ１１１１において、ＣＰＵ２３０は、上述した電子メールの各種設定などの送信管理情報をログファイルに書き込む。送信完了情報としては、例えば、ユーザ名４３０「ｓｙａｉｎ２」、送信結果、送信開始時刻、送信時間、送信ページ数、Ｓｕｂｊｅｃｔ情報、送信ファイル名、送信データサイズ、送信宛先の電子メールアドレス、ＩＦＡＸ／Ｅｍａｉｌの送信区別の情報などがある。ログファイルは、ＲＡＭ２３２などの記憶装置に記憶される。

また、ＣＰＵ２３０は、操作部２３３から通信管理レポートの出力を指示されると、ログファイルを読み出し、プリンタ部２３５から印刷出力したり、操作部２３３に表示したりする。

また、ＣＰＵ２３０は、ログファイルに登録されているデータをＨＴＴＰｄプログラムの稼動しているＷＥＢサーバにおいて公開するために、ＨＴＭＬ形式のデータを作成し、ＷＥＢサーバにわたしてもよい。このようにすれば、ＰＣ１０４などのクライアントＰＣにインストールされているＷＥＢブラウザによって、当該通信管理レポートを表示することができる。なお、ＨＴＴＰｄプログラムは、ＣＰＵ２３０が実行してもよいし、外部のサーバ上で実行されていてもよい。

このようにして本実施形態は、誰が、いつ、誰宛に電子メールを送信したかを判定する際に役立つであろう。

図１２は、本実施形態に係る電子メールデータの一例を示す図である。この例では、Ｅｍａｉｌ送信宛先として、ｓｙａｉｎ１の電子メールアドレスであるｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐが指定されている。

図中の行番号１２００から１２０７は、メールヘッダ部分であり、１２０８の空行で区切られている。１２００は、電子メールの送信Ｄａｔｅフィールドであり、電子メール送信時の曜日、日付、時間が設定されている。１２０１は、電子メールの送信者情報を示すＦｒｏｍフィールドであり、Ｓ１１０４にて設定される。上述の例では、ｓｙａｉｎ２がログインしているので、ｓｙａｉｎ２＜ｓｙａｉｎ２＠ｘｙｚ．ｃｏ．ｊｐ＞というデータが設定されている。１２０２は、メールの表題であるＳｕｂｊｅｃｔフィールドであり、Ｓ１１０６にて設定される。上述の例ではｓｙａｉｎ２がログインしているので、Ｆｒｏｍｓｙａｉｎ２というデータがセットされている。１２０３は、電子メールの送信宛先を表すＴｏフィールドであり、たとえば、図８に示したアドレス帳からｓｙａｉｎ１を選択すると、このＴｏフィールドが作成される。１２０４は、Ｍｅｓｓａｇｅ−Ｉｄであり、電子メール固有のＩＤである。例えば、送信時刻と送信した機器の電子メールアドレスを設定することで、同一ＩＤのメールは世の中に存在しないようになる。１２０５は、Ｓ１１０５で設定されたＸ−Ｓｅｎｄｅｒフィールドであり、ログインしたユーザの電子メールアドレスが設定される。上述の例では、ｓｙａｉｎ２がログインしているので、ｓｙａｉｎ２＠ｘｙｚ．ｃｏ．ｊｐというデータがセットされる。１２０６には、ＭＩＭＥのバージョン情報が設定される。

１２０７には、メールのデータが複数のブロックに別けられていることが示され、その区切り文字列が” ＡＨＭＯＡＬＢＪＤＡＤＡＤＡＤＣＤＡＤＡＡＡＡＯＢＨＢＫ”であることが示されている。１２０９から１２１７までは、電子メールの１つのブロックである。１２０６で指定された区切り文字の先頭に“−−”が追加されているので、電子メールの１つのブロックと判断できる。１２１０により区切られた部分がテキストであることが示され、文字コードとしてＪＩＳコードが使われていることが示されている。１２１２は、Ｓ１１０７で追加されたメール本文の先頭行である。ｓｙａｉｎ２がログインしている場合は、Ｍｅｓｓａｇｅ Ｆｒｏｍ ｓｙａｉｎ２という行が追加されている。

１２１３から１２１５までは、図７の本文欄７０５に入力された８ビットコード（例：ＳＪＩＳコード）の文字列を７Ｂｉｔコード（例：ＪＩＳコード）に文字コード変換して生成された本文データが挿入されている。

１２１７から１２３１までは、電子メールのもう１つのブロックである。１２１７には、１２０６で指定された区切り文字の先頭に“−−”が追加されているので、もう一つのブロックの開始であることがわかる。また、１２３１には区切り文字の最後に“−−”が追加されているので、最後のメールパートであることがわかる。

１２１８は、当該ブロックが、ＴＩＦＦ画像ファイルで構成されていることを示している。ｓｙａｉｎ２がログインしている場合は、上述のステップＳ１１０８において決定されたファイル名であるＦｒｏｍ−ｓｙａｉｎ２．ｔｉｆが設定される。

１２１９は、ＴＩＦＦ画像ファイルがＢＡＳＥ６４デコードによって７Ｂｉｔの文字コードに変換されていることを示している。１２２０は、Ｆｒｏｍ−ｓｙａｉｎ２．ｔｉｆというファイル名を有するファイルが、添付ファイル形式でメールに追加されていることを示している。

１２２２から１２２９までは、ＴＩＦＦ画像ファイルをＢＡＳＥ６４エンコードしたデータである。ＢＡＳＥ６４エンコードでは、３Ｂｙｔｅの８Ｂｉｔデータを４Ｂｙｔｅの６Ｂｉｔデータに変換するため、変換後のデータサイズは４／３倍となる。

図１３は、本実施形態に係るＳＭＴＰ送信シーケンスの一例を示す図である。なお、以下のシーケンスの実行主体は、ＭＦＰ１００、メールサーバ１０３およびＰＣ１０４などのＣＰＵである。当該ＣＰＵが、ＲＯＭ、ＲＡＭやハードディスクドライブに記憶されているプログラムに従って通信回路等を制御し、以下のシーケンスに沿った処理を実行することは言うまでもない。また、データの作成、受信、および送信など処理においては、ＲＡＭなどの記憶装置が作業領域として利用されることはいうまでもない。

電子メールクライアントであるＭＦＰ１００がメールサーバ１０３に接続（１３００）をすると、メールサーバ１０３はＳＭＴＰセッションの初期化処理を実行する。初期化処理が終了すると、メールサーバ１０３は、”２２０”の応答コードから始まる接続応答メッセージ（１３０１）を返信する。

ＭＦＰ１００がＥＨＬＯコマンド（１３０２）を送信すると、メールサーバ１０３は、ＭＦＰ１００からコマンドを受け取ったことを、”２５０”の応答コード（１３０３）により通知する。この際に、メールサーバ１０３が所有しているＳＭＴＰ拡張コマンドを含めて返信してもよい。

１３０４は、メールサーバ１０３がＤＳＮ（Ｄｅｌｉｖｅｒｙ ＳｔａｔｕｓＮｏｔｉｆｉｃａｔｉｏｎｓ）サービスをサポートしていることを示すコマンドである。１３０５は、メールサーバがＳＭＴＰＡＵＴＨをサポートし、認証アルゴリズムとしてＣＲＡＭ−ＭＤ５に対応していることを示すコマンドである。

１３０６は、ＳＭＴＰプロトコル上のＭＡＩＬコマンドであり、このコマンドでＭＦＰ１００の電子メールアドレス（ｉｆａｘ＠ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐ）を指定する。

ＳＭＴＰを用いて電子メールがバケツリレー式に配信される際に、その途中で電子メールの配信がエラーとなった場合は、このアドレスに対してエラーメールが通知される。エラーメールの送信は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ）が策定したＲＦＣ８２１を利用して実行することができる。例えば、電子メールデータのＦｒｏｍフィールドにＩＦＡＸ宛先が設定された場合は、機器（例：ＭＦＰ１００）のメールアドレス（ｉｆａｘ＠ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐ）をＭＡＩＬコマンドのアドレスにセットして送信する。一方、Ｅｍａｉｌ宛先に電子メールデータを送信する場合は、ユーザ認証の際に得られた電子メールアドレスをＦｒｏｍフィールドに設定したが、ＭＡＩＬコマンドのアドレスには、常に、機器（例：ＭＦＰ１００）のメールアドレス（ｉｆａｘ＠ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐ）を設定する。このためＳＭＴＰ配信途中でエラーが発生した場合、常にエラーメールが当該機器に送られるように動作することになるため、当該機器は、エラーメールを受信し、印刷または表示できるようになる。

また、送信側の機器（例：ＭＦＰ１００）でエラーメールを受信することにより、当該エラーメールに基づいて、当該機器で管理されているログファイルを参照することにより、どの送信ジョブがエラーとなったのかを判断しやすくなる。

メールサーバ１０３は、このＭＡＩＬコマンド（１３０６）を正常に受信すると、２５０から始まる応答コード（１３０７）を返信する。

次に、ＭＦＰ１００は、電子メールの受信者のメールアドレスを指定するＲＣＰＴＴＯコマンド（１３０８）を送信する。このコマンドには電子メールデータのＴＯフィールドに記述されているアドレス（ｓｙａｉｎ１＠ｘｙｚ．ｃｏ．ｊｐ）が設定される。メールサーバ１０３は、このコマンドを受信し、受信したコマンドに応じた処理が終了すると、”２５０”から始まる応答コード（１３０９）を返信する。

ＭＦＰ１００は、送信宛先の指定が終わると、電子メールデータを送信することを知らせるＤＡＴＡコマンド（１３１０）をメールサーバ１０３に送信する。メールサーバ１０３は、電子メールデータの受信準備が整うと、”３５４”から始まる応答コード（１３１１）を返信する。

メールサーバ１０３から送信許可コマンド（１３１１）を受信すると、ＭＦＰ１００は、図１２で説明した電子メールデータ（１３１２〜１３１４）を送信する。ＭＦＰ１００は、全てのデータを送信した後で、データの終了を示す文字“．”（１３１５）を送信する。メールサーバ１０３は、メールデータを正常に受信できた場合に、”２５０”から始まる応答コード（１３１６）を返信する。

ＭＦＰ１００は、メールデータを送信した後、ｑｕｉｔコマンド（１３１７）を送信する。メールサーバ１０３は、”２２１”から始まる応答コード（１３１８）を返信すると、一連のＳＭＴＰ送信処理が終了する。

図１４は、本実施形態に係るＳＭＴＰ受信シーケンスの一例を示す図である。より具体的には、ＳＭＴＰによって送信された電子メールデータがＰＯＰサーバとしてのメールサーバ１０３に配信され、ＰＣ１０４にインストールされている電子メールアプリケーションがＰＯＰ３プロトコルに従ってこの電子メールデータを受信するシーケンスを示している。

ＰＯＰクライアントであるＰＣ１０４がＰＯＰサーバ１０３に接続（１４００）すると、ＰＯＰサーバ１０３は、ＰＯＰ３セッションの初期化処理を実行する。初期化処理が終了すると、ＰＯＰサーバ１０３は、”＋ＯＫ”の応答コードから始まる接続応答メッセージ（１４０１）を返信する。この接続応答によりＰＯＰサーバ１０３は、ＡＵＴＨＯＲＩＺＡＴＩＯＮ状態となる。

ＰＣ１０４は、ＰＯＰサーバ１０３にログインすべく、ＵＳＥＲコマンド（１４０２）を用いてログインユーザ名（ｓｙａｉｎ１）を送信すると、ＰＯＰサーバ１０３は、”＋ＯＫ”の返答コード（１４０３）を返信する。

続いてＰＣ１０４は、ｓｙａｉｎ１のパスワード（ｓｙａｉｎ１ｐａｓｓ）をＰＡＳＳコマンド（１４０４）を用いて送信すると、ＰＯＰサーバ１０３は、登録されているｓｙａｉｎ１のパスワードと、受信したパスワード（ｓｙａｉｎ１ｐａｓｓ）とを比較する。双方が一致する場合、ＰＯＰサーバ１０３は、”＋ＯＫ”の応答コードから始まる接続応答メッセージ（１４０５）を返信する。この返信によりＰＯＰサーバ１０３は、ＡＵＴＨＯＲＩＺＡＴＩＯＮ状態からＴＲＡＮＳＡＣＴＩＯＮ状態に移行するため、取り扱うことができるＰＯＰ３コマンドが変化することになる。

ＰＣ１０４は、ＳＴＡＴコマンド（１４０６）を用いて、ｓｙａｉｎ１のメールボックスの状態をＰＯＰサーバ１０３に問い合わせる。このコマンドを受信したＰＯＰサーバ１０３は、ｓｙａｉｎ１のメールボックスを調べ、メールボックス内のメール数とメールスプールサイズを調べ、”＋ＯＫ”のコマンドに続いてｓｙａｉｎ１のメールボックス内のメール数（１）とトータルメールスプールサイズ（１５４９５９）とからなるメッセージ（１４０７）を返信する。

ＰＣ１０４は、メッセージ（１４０７）により、メールボックス内に１つのメールが存在することを認識し、このメールに対してユニークに割り当てられた番号を取得するため、ＵＩＤＬコマンド（１４０８）とメールボックス番号である１を通知する。

このコマンドを受信したＰＯＰサーバ１０３は、”＋ＯＫ”の応答メッセージ（１４０９）を返信するとともに、１番目のメールのユニークＩＤを調べ、メール番号の１の後にユニークＩＤを付加してなるメッセージ（１４１０）を返信し、続いて、リストの終了を示す“．”（ドット）データ（１４１１）を返信する。このユニークＩＤは、メール毎にユニークであることが保証されているので、同じ番号が割り振られたメールは存在しない。

ＰＣ１０４は、取得したユニークＩＤに基づいて、この１番目のメールが既に受信済みであるかを調べる。受信済みではない場合、ＲＥＴＲコマンド（１４１２）を用い、１番目のメールを指定して、メールボックス内の１番目のメールデータを送信するようＰＯＰサーバ１０３に依頼する。

ＰＯＰサーバ１０３は、”＋ＯＫ”から始まるメッセージ（１４１３）を返信し、続いて、メールボックス内の１番目のメールデータ（１４１４から１４１６）を送信する。全てのメールデータの送信が終了すると、メールデータの終了を示す“．”（ドット）からなる応答コード（１４１７）を返信する。

ＰＣ１０４は、メールデータを取得した後で、ＤＥＬＥコマンド（１４１８）を用いて、ｓｙａｉｎ１のメールボックスに存在する１番目のメールを削除するようにＰＯＰサーバ１０３に命令する。ＰＯＰサーバ１０３は、１番目のメールに削除フラグを立て、＋ＯＫから始まるメッセージ（１４１９）を返信する。

ＰＣ１０４は、全ての処理が終了したのでＰＯＰサーバ１０３に対してＱＵＩＴコマンド（１４２０）を送信する。ＰＯＰサーバ１０３は、削除フラグが立っている１番目のメールを削除し、”＋ＯＫ”から始まるメッセージ（１４２１）を返信することで、全てのＰＯＰ３受信処理が終了する。

図１５は、本実施形態に係るメールデータ（図１４の１４１４から１４１６）の一例を示す図である。図１２において説明済みの個所には同一の参照符号を付すことにより説明を省略する。図１２に示した電子メールデータは、ＭＦＰ１００から送信された後、途中のメールサーバ１０３を経由する際に、１５００、１５０１および１５０２のデータが追加される。１５００および１５０１は、Ｒｅｃｅｉｖｅｄヘッダである。これらは、メールサーバ１０３がメールデータを受信した際に、当該メールサーバ１０３に設定されているＨＯＳＴ名などの経路情報と、受信した曜日、日付および時刻などのタイムスタンプデータなどからなる。

また、送信宛先は、メールサーバ１０３内のｓｙａｉｎ１というメールボックスであるから、メールサーバ１０３は、ＳＭＴＰによる最終目的地となる。そこで、メールサーバ１０３は、Ｒｅｔｕｒｎ−Ｐａｔｈヘッダのデータ（１５０２）を電子メールデータに追加する。また、Ｒｅｔｕｒｎ−Ｐａｔｈヘッダの追加については、ＩＥＴＦが策定したＲＦＣ２８２１において義務付けられている。

１５０２のＲｅｔｕｒｎ−Ｐａｔｈヘッダのデータには、図１３を用いて説明したＳＭＴＰプロトコルのＭＡＩＬコマンド（１３０６）に付随して受信された電子メールアドレスがそのまま代入される。この電子メールアドレスは、元々は、メール差出情報の一種であるＦＲＯＭフィールドに記述されていたものである。

ＰＯＰ３などのＳＭＴＰプロトコル以外でこのメールデータを受信した際に、ＰＣ１０４がエラーを（例えば、受信側の装置で扱えない画像データであった等）検出すると、Ｒｅｔｕｒｎ−Ｐａｔｈヘッダに記述されているメールアドレス（上述の例では送信側機器のアドレス）に対して、エラーが発生したことを通知する。受信側の装置で扱えない画像データか否かは、例えば、ＰＣ１０４のＣＰＵは、取り扱い可能な画像データの拡張子（．ｔｉｆや．ｊｐｇなど）についてリストやテーブルなどを作成して記憶装置に記憶しておく。そして、当該ＣＰＵは、受信した画像データの拡張子が当該リスト等に含まれているかどうかを検索し、検索により見つかれば取り扱い可能と判定でき、見つからなければ取り扱い不可能と判定できよう。

このようにエラーが発生した場合は、送信機であるＭＦＰ１００のメールアドレス（ｉｆａｘ＠ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐ）にエラーが通知されることになり、ＭＦＰ１００は、当該エラーメールを受信して、プリンタ部２３５から印刷したり、あるいは操作部２３３から表示したりすることができる。

また、ＭＦＰ１００は、送信／受信についてログファイルを作成しているので、受信したエラーメールに基づいて、このログファイルを参照することにより、どの送信ジョブがエラーとなったのかを、プリンタ部２３５から印刷したり、あるいは操作部２３３から表示したりすることができる。

［他の実施形態］
以上、様々な実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。例えば、プリンタ、スキャナ、ＰＣ及びインターネットワークファクシミリを実現するためのプログラムによって上述のＭＦＰを実現してもよい。また、上述の実施形態では、ネットワーク上に認証サーバ１０２を設置し、複数のＰＣ、ＭＦＰから認証する例を説明したが、もちろんＭＦＰの内部に認証サーバの機能を搭載しても同様の効果が得られることはいうまでもない。このように複数の機器を単一の機器に統合して提供してもよいのである。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（本実施形態では図５、図９および図１１に示すフローチャートや、図１２および図１３示したシーケンスに対応するプログラム）を、システム若しくは装置に対して直接又は遠隔から供給し、そのシステム若しくは装置に含まれるコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、例えば、フロッピー(登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明の構成要件となる場合がある。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。

Claims (9)

1. 画像データを電子メールに添付して送信する画像通信装置であって、
   前記画像通信装置に対応する第１のメールアドレスを格納する格納手段と、
   前記電子メールの送信者に対応する第２のメールアドレスを取得する取得手段と、
   前記取得手段により取得された前記第２のメールアドレスを前記電子メールのヘッダ部に設定する設定手段と、
   前記取得手段により取得された前記第２のメールアドレスがヘッダ部に設定された前記電子メールを、ＳＭＴＰプロトコルに従ってメールサーバに送信する送信手段と、を備え、
   前記取得手段により取得された前記第２のメールアドレスがヘッダ部に設定された前記電子メールを前記送信手段が送信するためのセッションにおいて、前記送信手段は、前記格納手段に格納された前記第１のメールアドレスを、ＳＭＴＰプロトコルで用いられるＭＡＩＬコマンドで前記メールサーバに通知することを特徴とする画像通信装置。
2. 前記設定手段は、前記取得手段により取得された前記第２のメールアドレスを前記電子メールのヘッダ部に含まれるＦｒｏｍフィールドに設定することを特徴とする請求項１に記載の画像通信装置。
3. 前記設定手段は、前記取得手段により取得された前記第２のメールアドレスを前記電子メールのヘッダ部に含まれるＳｅｎｄｅｒフィールドに設定することを特徴とする請求項１に記載の画像通信装置。
4. 前記送信手段は、前記格納手段に格納された前記第１のメールアドレスを前記ＭＡＩＬコマンドで前記メールサーバに通知した後に、前記電子メールを前記メールサーバに送信することを特徴とする請求項１から３のいずれか１項に記載の画像通信装置。
5. インターネットＦＡＸ規格に則った形式以外の形式の画像データを送信することが可能な第１送信モード及びインターネットＦＡＸ規格に則った形式の画像データを送信するための第２送信モードのいずれかを選択する選択手段を更に備え、
   前記設定手段は、前記選択手段により前記第１送信モードが選択された場合に、前記取得手段により取得された前記第２のメールアドレスを前記電子メールのヘッダ部に含まれるＦｒｏｍフィールドに設定し、前記選択手段により前記第２送信モードが選択された場合は、前記格納手段に格納された前記第１のメールアドレスを前記電子メールのヘッダ部に含まれるＦｒｏｍフィールドに設定することを特徴とする請求項１に記載の画像通信装置。
6. 前記送信手段による電子メールの送信でエラーが発生した場合に前記ＭＡＩＬコマンドで通知した前記第１のメールアドレス宛てに送信されるエラーメールを受信する受信手段と、
   前記受信手段が受信したエラーメールを印刷する印刷手段と、
   を備えることを特徴とする請求項１から５のいずれか１項に記載の画像通信装置。
7. 原稿上の画像を読み取って画像データを生成する読取手段を更に備え、
   前記送信手段は、前記読取手段が生成した画像データが添付された前記電子メールを送信することを特徴とする請求項１から６のいずれか１項に記載の画像通信装置。
8. 画像データを電子メールに添付して送信する画像通信装置の制御方法であって、
   前記画像通信装置に対応する第１のメールアドレスを格納手段に格納する格納工程と、前記電子メールの送信者に対応する第２のメールアドレスを取得する取得工程と、
   前記取得工程により取得された前記第２のメールアドレスを前記電子メールのヘッダ部に設定する設定工程と、
   前記取得工程により取得された前記第２のメールアドレスがヘッダ部に設定された前記電子メールを、ＳＭＴＰプロトコルに従ってメールサーバに送信する送信工程と、を備え、
   前記取得工程により取得された前記第２のメールアドレスがヘッダ部に設定された前記電子メールを前記送信工程で送信するためのセッションにおいて、前記格納手段に格納された前記第１のメールアドレスを、ＳＭＴＰプロトコルで用いられるＭＡＩＬコマンドで前記メールサーバに通知することを特徴とする画像通信装置の制御方法。
9. 請求項８に記載の画像通信装置の制御方法が備える各工程をコンピュータに実行させることを特徴とするプログラム。

Images