JP5247870B2 - 受信装置及びその制御方法、プログラム - Google Patents

Description

本発明は、ネットワークを介して、送信装置と受信装置間で電子メールの送受信を行う通信システムに関するものである。

近年、コンピュータの普及、情報のネットワーク化に伴い、文字情報をネットワークで送受信する電子メールが普及している。

電子メールには文字情報であるメール本文の他に様々な形式のファイルを添付することが可能である。この添付ファイルには、例えば、ＴＩＦＦ（Ｔａｇ Ｉｍａｇｅ Ｆｉｌｅ Ｆｏｒｍａｔ）ファイルを添付することで、画像の送受信を行うインターネットＦＡＸ（以降、ＩＦＡＸと略す）が普及している。

ＩＦＡＸは、送信機のスキャナで読み取った画像をＴＩＦＦ形式の画像に変換した上で宛先へ送信し、受信機が受信データからＴＩＦＦ形式の画像を復元して印刷する、機器間で通信するための技術である。

このような技術において、特許文献１では、電子メールプロトコルを用いて画像データを送信する装置で、メールサーバを中継せずに画像データを直接受信機に送信する構成が開示されている。

また、特許文献２では、電子メールプロトコルを用いて画像データを送信する装置において、アドレス帳の宛先毎にメールサーバを中継せずに画像データを直接受信機に送信するか否かのデータを保持しておく。そして、そのデータに基づいて、直接送信できる宛先にはメールサーバを経由せず直接データを受信機に送信する構成が開示されている。

また、非特許文献１では、ＩＦＡＸのＦｕｌｌ Ｍｏｄｅ規格が規定されている。この規格には、送信機から受信機に画像データが通信された場合、受信機から送信機に対しＭＤＮ（Ｍｅｓｓａｇｅ Ｄｉｓｐｏｓｉｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ）を用いて、送信機に受信結果を通知する構成が規定されている。

特開平２００２−２７１９３号公報

特開２００３−２３３５５８号公報

ＲＦＣ２５３２

Ｆｕｌｌ Ｍｏｄｅ規格に従いメールサーバを経由せずに送信機から受信機に画像データが送信する構成の場合において、特許文献１、特許文献２に開示される構成によれば、送信機から受信機に画像データを直接送信することは可能である。

しかしながら、受信機がＭＤＮの結果を送信機に送信する場合は、ＭＤＮを送信する宛先が直接送信できる宛先であるか、直接は送信できない宛先であるか判断することができない。

このために、ＭＤＮは常にメールサーバを返して通信が行われることになり、メールサーバは必要不可欠な存在となっていた。

しかしながら、メールサーバの設置、運用は容易ではない。ここで、メールサーバを経由することなく通信ができる環境でのみ運用される場合とは、メールサーバを構築することなく画像データを電子メールプロトコルに従って通信を行う場合がある。また、メールサーバが存在しても、大きな画像ファイルが送信されるＩＦＡＸでは、メールサーバの負荷が問題になることから、メールサーバをあえて使わないようにメールサーバの設定を行う場合が増えている。

受信機が電子メールデータの受信に成功しても、受信後に電子メールデータを解析して、その中から画像を抽出するようなシステムでは、必ずしもデータの受信の成功が、受信機でのそのデータによる画像形成の成功とは限らない。例えば、受信機に内蔵されるデータ記憶用の記憶装置が、処理途中で一杯になる等の障害が発生した場合は、受信機での画像形成は失敗に終わってしまう。

従って、最終的に通信が成功したかを確認するためには、ＭＤＮでの確認が必要になる。このようなメールサーバが設置されない、あるいは設定されない環境では、ＭＤＮの通信が行われず、送信した電子メールデータが受信機に正常に届いたのか判断できないという問題が発生している。

本発明は上記の問題点に鑑みてなされたものである。その目的は、装置間の環境に応じて、電子メールの送達確認の送受信経路を適応的に選択して、送達確認を確実に送信することができる受信装置及びその制御方法、プログラムを提供することにある。

上記の目的を達成するための本発明による受信装置は以下の構成を備える。即ち、
電子メールデータを生成する生成手段と、
前記生成手段が生成した電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報とともに、当該電子メールデータを受信装置に送信する送信手段と、
前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信手段と、
を備える。

本発明によれば、装置間の環境に応じて、電子メールの送達確認の送受信経路を適応的に選択して、送達確認を確実に送信することができる受信装置及びその制御方法、プログラムを提供できる。

本発明の実施形態１の通信装置のネットワーク接続構成を示すブロック図である。 本発明の実施形態１のＭＦＰの構成を示す図である。 本発明の実施形態１のＭＦＰが所有するネットワークプログラムの構成を説明する図である。 本発明の実施形態１のＭＦＰの送信宛先情報を格納する宛先表登録画面である。 本発明の実施形態１の電子メールデータの構成例を示す図である。 本発明の実施形態１のＳＭＴＰプロトコルのシーケンスフローを示す図である。 本発明の実施形態１のＳＭＴＰ受信処理を示すフローチャートである。 本発明の実施形態１のＭＤＮデータの構成例を示す図である。 本発明の実施形態１のＭＤＮ送信処理を示すフローチャートである。 本発明の実施形態２のＭＤＮ送信処理を示すフローチャートである。 本発明の実施形態３の電子メールデータの構成例を示す図である。 本発明の実施形態３の電子メールデータ解析処理を示すフローチャートである。

以下、本発明の実施の形態について図面を用いて詳細に説明する。

＜実施形態１＞
図１は本発明の実施形態１の通信装置のネットワーク接続構成を示すブロック図である。

１００、１０１は、ＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）である。ＭＦＰ１００や１０１は、スキャナ、プリンタ等のデバイスを搭載することで、スキャナ機能、コピー機能、ＦＡＸ送受信機能、コンピュータ上で作成されたデータを印刷するプリンタ機能等の複数の機能を備えたマルチファンクション複写機である。

ＭＦＰ１００、ＭＦＰ１０１は、例えば、ドメイン名ｘｙｚ．ｃｏ．ｊｐというネットワークに接続され、サーバ１０３やクライアントＰＣ１０４等の複数のコンピュータ、ネットワーク機器と接続されている。

このネットワークは、さらには全世界に広がるインターネット網１１０と接続されている。

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

ＰＣ１０４には、汎用電子メールソフトがインストールされており、ｙａｍａｄａ＠ｘｙｚ．ｃｏ．ｊｐというメールアドレスが付与されている。

サーバ１０３は、Ｍａｉｌサーバ（ＳＭＴＰサーバ）機能とＰＯＰサーバ機能の双方の機能を備えるサーバであり、ｐｕｌｓｅｒ．ｘｙｘ．ｃｏ．ｊｐというＨＯＳＴ名が付与されている。また、ＤＮＳサーバ機能を備えている。

尚、Ｍａｉｌサーバ機能を備えるサーバ、ＰＯＰサーバ機能を備えるサーバ、ＤＮＳサーバ機能を備えるサーバをそれぞれ別の端末としてもよいし、適宜統合した端末としてもよい。また、ＤＮＳサーバ機能を備えるサーバを、このようにＭＦＰ１００とは独立した端末として一括管理することにより、ドメイン名とＩＰアドレスとを相互変換する端末を種々のＭＦＰで共用することができる。

また、ドメイン名やＩＰアドレスの変更があった場合、このサーバのみの変更で済む。もちろん、このＤＮＳサーバ機能をＭＦＰ１００に内蔵させるようにしてもよい。この場合は、ネットワークを介した通信を行わないので処理効率の向上が期待できる。

ＭＦＰ１００、ＭＦＰ１０１には、２種類の送信モードが構成されている。１つは、ＦＡＸ／ＩＦＡＸ受信機能にて受信した画像、及びスキャナで読み取った白黒／カラー画像を、一般の電子メール宛先に送信することを前提として送信するＥｍａｉｌ送信モードである。もう１つは、ＩＦＡＸ規格に従った装置に送信することを前提として送信するＩＦＡＸ送信モードが存在する。

尚、データの送信／受信には、例えば、ＳＭＴＰ、ＰＯＰ３プロトコルが使われる。

Ｅｍａｉｌ送信モードでは、スキャナでカラー画像が読み取られる場合は、ＪＰＥＧフォーマットあるいはＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）形式のファイルの画像を電子メールに添付して送信することができる。一方、スキャナで白黒画像が読み込まれた場合は、ＴＩＦＦあるいはＰＤＦの形式の画像を送信することができる。

例えば、ｙａｍａｄａ＠ｘｙｚ．ｃｏ．ｊｐのメールアドレスを有するクライアント１０４に電子メールを送信する場合、サーバ１０３にＳＭＴＰプロトコルで画像データが添付された電子メールが送信される。そして、クライアントＰＣ１０４は、ＰＯＰ３プロトコルにてその電子メールを受信し、汎用画像ビューアで添付されている画像を表示することができる。

ＩＦＡＸ送信モードでは、ＭＦＰのスキャナ機能で読み取られた画像あるいは、ＦＡＸ／ＩＦＡＸ受信機能で受信された画像データは、ＲＦＣ２３０１に従ったＴＩＦＦ形式の画像として送信される。そして、受信された画像データは受信側のＭＦＰのプリンタ機能で印刷される。

次に、ＭＦＰ１００の構成について、図２を用いて説明する。

尚、以下の説明では、ＭＦＰ１００の構成を例に挙げて説明するが、ＭＦＰ１０１についても、ＭＦＰ１００と同様の構成が実現される。

図２は本発明の実施形態１のＭＦＰの構成を示す図である。

ＣＰＵ１３０は、ＲＯＭ１３１に格納されているプログラムと、ＲＡＭ１３２を利用してシステム全体の制御を実行する。

操作部１３３は、ＬＣＤ表示パネルとスタートキー、テンキー等のハードキーから構成され、ＬＣＤ上にソフトボタンを表示し、ユーザが指でそのソフトボタンをタッチすることを検出してユーザオペレーションを実行する。

スキャナ１３４は、原稿の画像データを光電変換により電気データに変換する。スキャナ１３４では、原稿給送装置（不図示）から原稿をプラテンガラス上へ搬送し、原稿がプラテンガラス上に搬送されると、ランプを点灯し、そして、原稿読取ユニットの移動を開始し、原稿を露光走査する。

原稿からの反射光は、ミラー及びレンズによってＣＣＤイメージセンサへ導かれて電気信号に変換され、Ａ／Ｄ変換回路によってデジタルデータに変換される。原稿の読取動作終了後、プラテンガラス上の原稿は排紙される。

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

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

画像処理回路１３６は、大容量の画像メモリ、画像回転回路、解像度変倍回路、ＭＨ、ＭＲ、ＭＭＲ、ＪＢＩＧ、ＪＰＥＧ等の符号／復号化回路等の各種回路で構成され、シェーディング、トリミング、マスキング等の各種画像処理を実行することができる。

ハードディスク１３７は、ＳＣＳＩ、ＩＤＥ等のＩ／Ｆで接続されている大容量記録媒体である。

ネットワークＩ／Ｆ１３８は、１０ＢＡＳＥ−Ｔ、１００ＢＡＳＥ−Ｔを代表とするイーサネット（登録商標）あるいはトークンリング等のネットワーク回線と接続するためのネットワークデータリンクを実現する。

フォーマッタ部１３９は、ＩＥＥＥ１２８４準拠のパラレルインタフェース、ＵＳＢ等のシリアルインタフェースからなるＰＣ Ｉ／Ｆ１４２またはネットワークＩ／Ｆ回路１３８を介して、外部機器（例えば、クライアントＰＣ１０４）からデータを受信する。そして、フォーマッタ部１３９は、受信したデータ（例えば、ＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ））より画像データを作成し、画像処理回路１３６で画像処理を行い、プリンタ１３５で印刷するためのレンダリングを実行する。

ファクス部１４０は、電話回線と接続し、ＮＣＵ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）、ＭＯＤＥＭ（ＭＯｄｕｌａｔｏｒ／ＤＥＭｏｄｕｌａｔｏｒ）等の回路で構成されるファクスＩ／Ｆ回路である。

ファクス部１４０は、スキャナ１３４で読み取った画像データを画像処理回路１３６で画像処理を行い、電話回線経由にて他のＦＡＸ装置に送信する。一方、ファクス部１４０は、他のＦＡＸ装置から送信されたデータを受信して、画像処理回路１３６で画像処理を行ってプリンタ１３５で印刷する。

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

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

また、スキャナ１３４で読み取った画像データを画像処理回路１３６で画像処理を行い、ネットワークＩ／Ｆ１３８からネットワーク上に送信することで、Ｓｅｎｄ（データ転送／ファイル転送）機能が実現される。更には、画像処理回路１３６でＲＦＣ２３０１に従った画像を作成し、電子メールプロトコルでデータを送受信することで、ＩＦＡＸ機能が実現される。

次に、ＭＦＰ１００が所有するネットワークプログラムの構成について、図３を用いて説明する。

図３は本発明の実施形態１のＭＦＰが所有するネットワークプログラムの構成を説明する図である。

ネットワークプログラムの構成は、ＩＰ層２００、ＴＣＰ／ＵＤＰ層２０１、アプリケーション層２０２の３階層に大別して構成されている。

ここで、ＩＰは「Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ」、ＴＣＰは「Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ」、ＵＤＰは「Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ」の略称である。

ＩＰ層２００は、発信ホストから宛先ホストヘルータ等の中継ノードと連携しながらメッセージを送り届けるサービスを提供するインターネットのプロトコル階層である。

ＩＰ層２００では、データを送信する発信先のアドレス、データを受信する宛先のアドレスを管理し、データをアドレス情報に従ってネットワーク内をどのような経路で宛先ホストまで届けるかを管理するルーティング機能を実行している。

ＴＣＰ／ＵＤＰ層２０１は、発信アプリケーションプロセスから受信アプリケーションプロセスにメッセージを送り届けるサービスを提供するトランスポート階層である。

ＴＣＰはコネクション型サービスであり、通信の高度な信頼性を保証する。一方、ＵＤＰはコネクションレス型のサービスであり、信頼性の保証を行わない。

アプリケーション層２０２は、複数のプロトコルを規定し、このプロトコルには、例えば、以下のようなものがある。

ファイル転送サービスであるＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）がある。また、ネットワーク管理プロトコルであるＳＮＭＰがある。また、プリンタ印刷用のサーバプロトコルであるＬＰＤがある。また、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバのプロトコルであるＨＴＴＰｄがある。

また、電子メール送受信プロトコルであるＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）がある。また、メールダウンロードプロトコルＰＯＰ３（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ−Ｖｅｒｓｉｏｎ ３）がある。また、ユーザの電子メールアドレス等を管理しているディレクトリデータベースにアクセスするためのプロトコルであるＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）がある。また、ＲＦＣ１５１０で規定されているＫｅｒｂｅｒｏｓ認証プログラムがある。

次に、ＭＦＰ１００の操作部１３３の操作画面例について、図４を用いて説明する。

図４は本発明の実施形態１のＭＦＰの送信宛先情報を格納する宛先表登録画面である。

尚、この宛先表登録画面では、例えば、ＭＦＰ１０１のＩＦＡＸ宛先等の各種宛先を登録することが可能である。

宛先表登録画面において、送信種別フィールド２５０は、送信宛先にどのような手法で送信するかを決定する項目である。これは、例えば、プルダウンメニューで構成され、ＦＡＸ、ＩＦＡＸ、Ｅｍａｉｌ、Ｆｉｌｅから１つを選択することができる。ここでは、送信種別フィールド２５０には、ＩＦＡＸが選択されている。

ＩＦＡＸが選択されると、アドレス、サーバ経由、解像度、用紙サイズ、圧縮方式の情報が表示される。

アドレスフィールド２５１は、アドレスを入力するための項目である。ここでは、アドレスフィールド２５１には、ＭＦＰ１０１の電子メールアドレスであるｉｆａｘ＠ｃｏｐｙ２．ｘｙｚ．ｃｏ．ｊｐが入力されている。

サーバ経由指定フィールド２５２は、送信時にデータをメールサーバに送り、メールサーバから目的の宛先であるＭＦＰ１０１に送信するか、直接ＭＦＰ１０１に送信するかを選択するスイッチである。ここでは、メールサーバを経由しないことを示す「しない」が設定されている。一方、メールサーバを経由する場合には、「する」が設定される。

送信宛先がインターネット経由の宛先である場合では、ファイアウォール等の中継ノードが存在するので、直接送信することはできないが、同一ネットワーク上の宛先である場合はメールサーバに負荷をかけることなく送信することができる。

解像度指定フィールド２５３〜２５６は、ＭＦＰ１０１が受信することができる解像度を指定することができるスイッチである。

解像度２００×１００ｄｐｉと２００×２００ｄｐｉは、通常は、どの機器でもＩＦＡＸによる受信を行うことができる解像度であるため、選択することはできない。一方、他の解像度に関しては、該当するフィールドを操作する毎に、その表示状態が白黒に反転し、黒表示されているフィールドは、その解像度が選択されていることを示している。

図４では、解像度指定フィールド２５４と、解像度指定フィールド２５５が選択されていて、２００×４００ｄｐｉと４００×４００ｄｐｉの解像度はＭＦＰ１０１が受信できることを示している。

ここで、例えば、スキャン時に、６００×６００ｄｐｉでスキャンされた画像はこのままではＭＦＰ１０１は受信することができない。そのため、この場合は、スキャンされた画像は、ＭＦＰ１０１が受信できる最高解像度である４００×４００ｄｐｉに解像度変換される。

用紙サイズ指定フィールド２５７及び２５８は、ＭＦＰ１０１が受信できる用紙サイズを指定するためのスイッチである。ここで、用紙サイズＡ４は、通常、どの機器でも受信できる解像度であるため選択できない。

ここで、ＭＦＰ１０１は、Ｂ４、Ａ３サイズの画像を受信することができるため、用紙サイズ指定フィールド２５７及び２５８は選択されている。

ここで、例えば、スキャン時に、Ａ３サイズで読み込まれた画像は、ＭＦＰ１０１にはＡ３サイズの画像で送信するが、受信側がＡ３サイズの画像を受信できない場合は受信側が受信できる最大サイズの用紙サイズに変倍してから送信する。

圧縮方式指定フィールド２５９及び２６０は、ＭＦＰ１０１が受信できる圧縮画像フォーマットを選択するスイッチである。ここでは、ＭＲ、ＭＭＲ方式を指定することが可能である。尚、文字等による文書画像であれば、ＭＨ＜ＭＲ＜ＭＭＲの順番で圧縮率が高い。

また、ＭＨ方式は、通常、どの機器でも受信することができるため選択できない。

ここで、ＭＦＰ１０１は、ＭＲ、ＭＭＲ方式の画像を受信することができるため、圧縮方式指定フィールド２５９及び２６０は選択されている。

ＭＦＰ１０１には、圧縮率が高いＭＭＲ方式の画像で送信するが、受信機がＭＭＲ方式の画像を受信できない場合は、受信側が受信できる最大の圧縮率の圧縮方式に圧縮して、画像を送信する。

そして、この宛先表登録画面において、各種設定が完了して、その設定を確定する場合には、ＯＫボタン２７０を操作することで、各種設定値が宛先表として、例えば、ＲＡＭ１２３に記憶される。一方、設定操作をキャンセルする場合には、キャンセルボタン２７１を操作することで、各種設定値をリセットすることができる。

次に、実施形態１の電子メールデータの構成例について、図５を用いて説明する。

図５は本発明の実施形態１の電子メールデータの構成例を示す図である。

ここでは、ＭＦＰ１００でスキャンした画像を電子メールに添付してＭＦＰ１０１に送信する際の電子メールデータの構成を示している。

Ｄａｔｅフィールド３００には、ＭＦＰ１００が送信した時間情報が入力されている。Ｆｒｏｍフィールド３０１には、ＭＦＰ１００の電子メールアドレスが入力されている。Ｔｏフィールド３０２には、ＭＦＰ１０１の電子メールアドレスが入力されている。Ｓｕｂｊｅｃｔフィールド３０３には、「ｉｍａｇｅ」という文字列が入力されている。

Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールド３０４は、ＭＦＰ１００が送達確認を要求し、送達確認メール（ＭＤＮデータ）を送信してもらうメールアドレスを指定するフィールドである。ここでは、ＭＦＰ１００のメールアドレスが入力されている。

Ｍｅｓｓａｇｅ−Ｉｄフィールド３０５は、メール固有のＩＤを示す番号である。これは、同一番号のメールが存在しないようにメールアドレスと時間データを含むデータから構成されている。ＭＩＭＥ−Ｖｅｒｓｉｏｎフィールド３０６は、ＭＩＭＥのバージョン番号が入力されている。

Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールド３０７は、文字列「−−−−−−＿４２２Ｅ５１Ｅ５４ＦＦ７０４Ｄ７５ＥＦ８＿」により、電子メールデータが複数のブロックに分割されていることを示している。

フィールド３１０〜３１６が１つのブロックである。フィールド３１１よりこの部分が日本語ＪＩＳコードで書かれた文字列であることが示され、フィールド３１４がデータ文字列、つまり、電子メールデータの本文である。

フィールド３１６〜３３０の部分がもう一つのブロックであり、フィールド３１７〜３１９の情報より、この部分が「ＧＳ２００５．ｔｉｆ」というファイル名のＴＩＦＦ画像ファイルであることが示されている。また、フィールド３２１〜３２８のデータは、このファイルをＢＡＳＥ６４エンコードしたデータであることを示している。

次に、本発明の実施形態１の図５の電子メールデータをＭＦＰ１００からＭＦＰ１０１に直接送信する際のＳＭＴＰプロトコルによるシーケンスフロー、図６を用いて説明する。

図６は本発明の実施形態１のＳＭＴＰプロトコルのシーケンスフローを示す図である。

図４で示したように、ＭＦＰ１００の宛先表には、ＭＦＰ１００からＭＦＰ１０１に送信する場合は、サーバ経由指定フィールド２５２には、メールサーバを経由せずに直接送信ができることを示す「サーバを経由しない」の情報が設定されている。

このため、ＭＦＰ１００ではＭＦＰ１０１に送信する場合、ＭＦＰ１０１に直接ＳＭＴＰ接続（４００）を行う。

ＳＭＴＰ接続されたＭＦＰ１０１は、ドメイン名情報を含む文字列（４０１）を返答する。

ＭＦＰ１００より、ＥＨＬＯコマンド（４０２）を投げかけると、ＭＦＰ１０１では自機が対応しているＳＭＴＰ拡張コマンドを「２５０−」から始まる文字列とともに通知する（４０３）。

具体的なＳＭＴＰ拡張コマンド（ＭＦＰ１０１が有する機能を示すコマンド）は、４０４から４０６に対応する。ここでは、ＭＦＰ１０１は、８ｂｉｔの電子メールデータを受信する受信機能、ＴＬＳ暗号により通信路を暗号化する暗号化機能、ＭＤＮを直接返答する直接返答機能を有しているものとする。

そこで、この場合、ＭＦＰ１０１は、８ｂｉｔの電子メールデータの受信機能を示す８ＢＩＴＭＩＭＥコマンド（４０４）、ＴＬＳ暗号による通信路の暗号化機能を示すＳＴＡＲＴＴＬＳコマンド（４０５）をＭＦＰ１００に送信する。更には、ＭＦＰ１０１は、ＭＤＮの直接返答機能（返答方法）を示すＤＩＲＥＣＴＭＤＮコマンド（４０６）をＭＦＰ１００に送信する。

尚、ＭＦＰ１０１には、機器設定として「ＭＤＮを直接返答する／しない」のスイッチがある。従って、ＭＤＮの直接返答機能を有している場合には、「する」に設定されている場合にのみ、ＭＦＰ１００からのＤＩＲＥＣＴＭＤＮコマンド（４０７）に対して、ＭＤＮの直接返答を実行する。一方、「しない」に設定されている場合、ＭＦＰ１００からのＤＩＲＥＣＴＭＤＮコマンド（４０７）に対して、ＭＤＮの直接返答は実行しない。

ここで、ＭＦＰ１００からのＤＩＲＥＣＴＭＤＮコマンド（４０７）は、ＭＤＮの直接返答を要求するコマンドである。また、ＭＤＮの直接返答とは、メールサーバを経由せずに、送信先にＭＤＮを直接返答することを意味するものである。

また、ＭＦＰ１０１内の宛先表に、ＭＦＰ１００の宛先表が登録されている場合には、その宛先表からサーバ経由指定フィールド２５２（図４）の設定内容（「サーバ経由する／しない」）を取得可能である。そこで、このような場合には、その設定内容に従って、ＭＤＮの直接返答の実行の可否を判定するようにしても良い。つまり、設定内容に「サーバ経由しない」が設定されている場合には、ＭＤＮの直接返答を実行するようにしても良い。

図５の説明に戻る。

ＭＦＰ１０１より、ＤＩＲＥＣＴＭＤＮコマンド（４０７）を正常受信すると、ＭＦＰ１０１から、「２５０」から始まる正常応答メッセージ（４０８）が返信される。

次に、ＭＦＰ１００からメール送信者を示すＭＡＩＬコマンド（４０９）をＭＦＰ１０１に送信する。これをＭＦＰ１０１が正常に受信すると、ＭＦＰ１０１から、「２５０」から始まる正常応答メッセージ（４１０）が返信される。次に、ＭＦＰ１００から、メール受信者を示すＲＣＰＴコマンド（４１１）を送信する。これをＭＦＰ１０１が正常に受信すると、ＭＦＰ１０１から、「２５０」から始まる正常応答メッセージ（４１２）が返信される。

次に、ＭＦＰ１００から、これから電子メールデータを送信することを示すＤＡＴＡコマンド（４１３）を送信後、電子メールデータ（図５の３００から３２９）を送信する。その後、電子メールデータの終了を示す「．」（４１４）を送信する。

ＭＦＰ１００から正常に電子メールデータを受信すると、ＭＦＰ１０１は、「３５４」から始まる正常応答メッセージ（４１５）を返信する。

次に、ＭＦＰ１００から、接続を切るためのＱＵＩＴコマンド（４１６）を送信する。これに対して、ＭＦＰ１０１から、「２２１」から始まるメッセージ（４１７）を返信する。

以上の処理によって、ＭＦＰ１００とＭＦＰ１０１間のＳＭＴＰ接続は終了する。

次に、ＭＦＰ１０１によるＳＭＴＰ受信機能によるＳＭＴＰ受信処理について、図７を用いて説明する。

図７は本発明の実施形態１のＳＭＴＰ受信処理を示すフローチャートである。

尚、ここでのＳＭＴＰ受信は、例えば、ＭＦＰ１００やクライアントＰＣ１０４からのＳＭＴＰ送信される電子メールデータを受信する場合がある。

電源が供給されると、ＳＭＴＰ受信機能が起動し、ステップＳ５０１で、接続待ち状態となる。

ＳＭＴＰ接続が開始されると、ステップＳ５０１からステップＳ５０２に処理が移行し、ＳＭＴＰ接続応答を返答する接続応答返信処理（図６の４０１）が動作する。

接続応答返信後、受信したコマンドを調べ、ステップＳ５０３で、ＥＨＬＯコマンドであるか否かを判定する。ＥＨＬＯコマンドある場合（ステップＳ５０３でＹＥＳ）、ステップＳ５０６に進む。一方、ＥＨＬＯコマンドでない場合（ステップＳ５０３でＮＯ）、ステップＳ５０４で、ＨＥＬＯコマンドであるか否かを判定する。

ＨＥＬＯコマンドである場合（ステップＳ５０４でＹＥＳ）、ステップＳ５１５に進む。一方、ＨＥＬＯコマンドでない場合（ステップＳ５０４でＮＯ）、ステップＳ５０５に進み、コマンドエラーとして新たなコマンド受信を待機する。

ステップＳ５０４において、受信したコマンドがＨＥＬＯコマンドである場合、ステップＳ５１５で、ＨＥＬＯコマンドの応答返信処理を実行し、ステップＳ５１６へと処理を進める。

ステップＳ５０３において、受信したコマンドがＥＨＬＯコマンドである場合、ステップＳ５０６で、自機が備えるＳＭＴＰ拡張機能を含むメッセージをＥＨＬＯコマンド応答としてＥＨＬＯコマンドの応答返信処理を実行する。

ここでのメッセージは、図６の４０４〜４０６に示される、８ＢＩＴＭＩＭＥ、ＳＴＲＴＴＬＳ、ＤＩＲＥＣＴＭＤＮ等である。

次に、自機が備えるＳＭＴＰ拡張機能で生成可能なコマンドを調査する。まず、ステップＳ５０７で、８ＢＩＴＭＩＭＥコマンドであるか否かを判定する。８ＢＩＴＭＩＭＥコマンドでない場合（ステップＳ５０７でＮＯ）、ステップＳ５０９に進む。８ＢＩＴＭＩＭＥコマンドである場合（ステップＳ５０７でＹＥＳ）、ステップＳ５０８に進み、「２５０ ＯＫ」の文字列を返答するＯＫ返信処理を実行する。

ステップＳ５０９で、ＤＩＲＥＣＴＭＤＮコマンドであるか否かを判定する。ＤＩＲＥＣＴＭＤＮコマンドでない場合（ステップＳ５０９でＮＯ）、ステップＳ５１２に進む。一方、ＤＩＲＥＣＴＭＤＮコマンドである場合（ステップＳ５０９でＹＥＳ）、ステップＳ５１０に進み、「２５０ ＯＫ」の文字列を返答するＯＫ返信処理を実行する。ステップＳ５１１で、接続要求を発行した発行元のＩＰアドレスをＲＡＭ１３２に記憶する。

ステップＳ５１２で、ＳＴＲＴＴＬＳコマンドであるか否かを判定する。ＳＴＲＴＴＬＳコマンドでない場合（ステップＳ５１２でＮＯ）、ステップＳ５１６に進む。一方、ＳＴＲＴＴＬＳコマンドである場合（ステップＳ５１２でＹＥＳ）、ステップＳ５１３に進み、「２５０ ＯＫ」の文字列を返答するＯＫ返信処理を実行する。ステップＳ５１４で、ＴＬＳ暗号化処理を実行する。

ステップＳ５１６で、ＭＡＩＬコマンド処理を実行する。これは、ＭＦＰ１０１に設定されている送信者のメールアドレス情報をＭＡＩＬコマンド（図６の４０９）にて受信すると共に、「２５０」から始まる文字列であるＭＡＩＬコマンドの応答（図６の４１０）を送信する。

ステップＳ５１７で、ＲＣＰＴコマンド処理を実行する。これは、送信宛先のメールアドレス情報が含まれるＲＣＰＴコマンド（図６の４１１）を受信し、「２５０」から始まる文字列からなるＲＣＰＴコマンド応答（図６の４１２）を送信する。

ステップＳ５１８で、ＤＡＴＡコマンド処理を実行する。これは、図５の電子メールデータをこれから送信することを示すＤＡＴＡコマンド（図６の４１３）を受信する。その後、次に送られてくる電子メールデータ（図６の３００、３２９、４１４）を受信し、「３５４」から始まる文字列であるＤＡＴＡコマンドの応答を送信する（図６の４１５）。

尚、電子メールデータの終了は、「．」だけからなる文字列４１４を検出することにより判断し、一連の動作が終了する。
ステップＳ５１９で、ＱＵＩＴコマンド処理を実行する。これは、送信を終了し、接続を切るＱＵＩＴコマンド（図６の４１６）を受信し、「２２１」の文字列から始まるＱＵＩＴコマンド（図６の４１７）を返答し、ＳＭＴＰ接続を切断する
以上の処理が完了すると、ＳＭＴＰ受信が終了する。

これにより、ＭＦＰ１０１では、例えば、図５に示す電子メールデータを受信することになる。そして、この電子メールデータ中の、メール本文のデータ（３１４）はＪＩＳコードからＳＪＩＳコードのテキスト情報に変換し、その後、ラスタライズ処理を施して画像データに変換する。

また、この電子メールデータ中の画像データ部分（３２１から３２８）は、ＢＡＳＥ６４形式でデコードして、ＴＩＦＦファイルに変換する。次に、ＴＩＦＦファイルから１ページ単位の画像データを切り出し、切り出したデータに対して画像デコード処理を行う。そして、すべてのページに対する、画像デコード処理が正常に完了した場合、図８に示すＭＤＮデータを作成する。

次に、実施形態１のＭＤＮデータの構成例について、図８を用いて説明する。

図８は本発明の実施形態１のＭＤＮデータの構成例を示す図である。

図８の６００から６０７の部分がこのメールのメールヘッダである。

Ｄａｔｅフィールド６００には、データ送信時の時間情報が入力されている。Ｆｒｏｍフィールド６０１は、メールを送信する送信元であるＭＦＰ１０１の電子メールアドレスが入力されている。Ｓｕｂｊｅｃｔフィールド６０２には、「Ｍｅｓｓａｇｅ Ｄｉｓｐｏｓｉｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ」という文字列が入力されている。

Ｔｏフィールド６０３には、図５で説明した画像が添付されているメールの、Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールド３０４で設定されている宛先が設定される。これにより、ＭＤＮデータは、この宛先に送信が行われることになる。

Ｍｅｓｓａｇｅ−ＩＤフィールド６０４は、送信時刻、ホスト名、ドメイン名、ユーザ名情報を含む文字列であり、同一のＩＤのデータは他に存在しないように作成される。

ＭＩＭＥ−Ｖｅｒｓｉｏｎフィールド６０５は、ＭＩＭＥのバージョン番号が入力されている。Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールド６０６は、このメールがレポートタイプの通知メールであることが入力されている。

フィールド６０７は、メールが「ｘｉＳＣｚｋＷＩ５ｑｃＯ＋ｕｉＷＩ６ｑａＭ＋ｕｅＴＩＢ６」というバウンダリで区切られていることが入力されている。ここでは、フィールド６０９、６１５、６２２にて区切られている。そして、フィールド６１０〜６１４でメールの第１の部分、フィールド６１６〜６２１でメールの第２の部分に分割されている。

フィールド６１０は、第１の部分がテキスト形式のデータであることを示し、フィールド６１２、６１３はそのデータ文字列である。

フィールド６１６は、第２の部分が通知メッセージであることを示し、フィールド６１８は、このメッセージを作成したＭＦＰ１０１のホスト名、ドメイン名が記述される。

Ｏｒｉｇｉｎａｌ−Ｍｅｓｓａｇｅ−ＩＤフィールド６１９は、図５で説明した画像が添付されているメールのＭｅｓｓａｇｅ−Ｉｄ３０４が入力され、どのメールに対する通知メールなのかを判断することができる。

Ｄｉｓｐｏｓｉｔｉｏｎフィールド６２０は、この通知メールが自動的に応答されたものであり、その結果は正常に処理されたことを示している。

次に、ＭＦＰ１０１によるＭＤＮデータを送信するＭＤＮ送信処理について、図９を用いて説明する。

図９は本発明の実施形態１のＭＤＮ送信処理を示すフローチャートである。

この処理は、ＭＤＮを送信する際に動作を開始する。

ステップＳ７０１で、ＤＩＲＥＣＴＭＤＮコマンド（図４の４０７）の内容を参照して、送信者から「ＭＤＮＤＩＲＥＣＴ」が指定されているか否かを判定する。「ＭＤＮＤＩＲＥＣＴ」が指定されている場合（ステップＳ７０１でＹＥＳ）、ステップＳ７０２に進み、ステップＳ５１１で記憶したＩＰアドレスに対応する宛先に、図８のＭＤＮデータを送信し、処理を終了する。

一方、「ＭＤＮＤＩＲＥＣＴ」が指定されていない場合（ステップＳ７０１でＮＯ）、ステップＳ７０３に進み、メールサーバ（例えば、サーバ１０３）にＭＤＮデータを送信して、処理を終了する。メールサーバに送信されたＭＤＮデータは、メールサーバを経由して最終的には、図５で説明した画像が添付されているメールのＤｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏの宛先に送信される。

以上説明したように、実施形態１によれば、メールサーバを経由しなくても電子メールプロトコルによる通信が可能な環境では、送達確認のＭＤＮデータもメールサーバを返さずに通信を行う。一方、メールサーバを経由しなければ通信ができない環境ではメールサーバを経由して送達確認のＭＤＮデータの通信を行う。

このように、装置間の環境に応じて、ＭＤＮデータの送受信経路を適応的に選択して、ＭＤＮデータを確実に送信することができる。また、送信したメール及びそれに添付される画像データが、受信側に正常に届いたか否かを送信側で判断することができる。

＜実施形態２＞
実施形態２では、実施形態１のＭＤＮ送信処理の応用例について説明する。

図１０は本発明の実施形態２のＭＤＮ送信処理を示すフローチャートである。

この処理は、ＭＤＮを送信する際に動作を開始する。

ステップＳ８０１で、ＤＩＲＥＣＴＭＤＮコマンド（図４の４０７）の内容を参照して、送信者から「ＭＤＮＤＩＲＥＣＴ」が指定されているか否かを判定する。「ＭＤＮＤＩＲＥＣＴ」が指定されている場合（ステップＳ８０１でＹＥＳ）、ステップＳ８０２に進む。ステップＳ８０２で、図５で説明した画像が添付されているメールのＤｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏの宛先を、ＤＮＳサーバ（サーバ１０３）に問い合わせて、送信すべき宛先のＩＰアドレスを取得する。

この際、ＤＮＳサーバには、ＨＯＳＴ名のＡレコードまたはメール配信専用のＭＸ（Ｍａｉｌ ｅＸｃｈａｎｇｅ）レコードを用いて宛先のＩＰアドレスを取得する。

ステップＳ８０３で、図８のＭＤＮデータを、ステップＳ８０２で取得したＩＰアドレスに対応する宛先にＳＭＴＰプロトコルを用いて送信し、処理を終了する。

一方、「ＭＤＮＤＩＲＥＣＴ」が指定されていない場合（ステップＳ８０１でＮＯ）、ステップＳ８０４に進み、メールサーバ（例えば、サーバ１０３）にＭＤＮデータを送信して、処理を終了する。メールサーバに送信されたＭＤＮデータは、メールサーバを経由して最終的には、図５で説明した画像が添付されているメールのＤｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏの宛先に送信される。

以上説明したように、実施形態２によれば、ＭＤＮデータの送信先を、ＤＮＳサーバに問い合わせることで、ＭＤＮデータの送信先を特定する。これにより、電子メールデータから、ＭＤＮデータの送信先を特定できない場合でも、確実にＭＤＮデータを正しい宛先へ送信することが可能となる。

＜実施形態３＞
実施形態１では、ＭＤＮデータの要求は、ＳＭＴＰプロトコルに従って送信先に送信する構成としているが、これに限定されない。例えば、電子メールデータ中に、ＭＤＮデータの要求を示す情報を記述する構成であっても良い。

そこで、実施形態３では、このＭＤＮデータの要求を示す情報が記述された電子メールを用いる場合の構成について説明する。

図１１は本発明の実施形態３の電子メールデータの構成例を示す図である。

ここでは、ＭＦＰ１００でスキャンした画像を電子メールに添付してＭＦＰ１０１に送信する際の電子メールデータの構成を示している。

Ｄａｔｅフィールド９００には、ＭＦＰ１００が送信した時間情報が入力されている。Ｆｒｏｍフィールド９０１には、ＭＦＰ１００の電子メールアドレスが入力されている。Ｔｏフィールド９０２には、ＭＦＰ１０１の電子メールアドレスが入力されている。Ｓｕｂｊｅｃｔフィールド９０３には、「ｉｍａｇｅ」という文字列が入力されている。

Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールド９０４は、ＭＦＰ１００が送達確認を要求し、送達確認メール（ＭＤＮデータ）を送信してもらうメールアドレスを指定するフィールドである。ここでは、ＭＦＰ１００のメールアドレスが入力されている。

Ｘ−ＭＤＮＤＩＲＥＣＴフィールド９０５は、送信者が送達確認メールをメールサーバを介さず、送信機であるＭＦＰ１００に直接送信してもらうことを希望していることを示している。

Ｍｅｓｓａｇｅ−Ｉｄフィールド９０６は、メール固有のＩＤを示す番号である。これは、同一番号のメールが存在しないようにメールアドレスと時間データを含むデータから構成されている。ＭＩＭＥ−Ｖｅｒｓｉｏｎフィールド９０７は、ＭＩＭＥのバージョン番号が入力されている。

Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールド９０８は、文字列「−−−−−−＿４２２Ｅ５１Ｅ５４ＦＦ７０４Ｄ７５ＥＦ８＿」により、電子メールデータが複数のブロックに分割されていることを示している。

フィールド９１１〜９１６が１つのブロックであり、フィールド９１１よりこの部分が日本語ＪＩＳコードで書かれた文字列であることが示され、フィールド９１５がデータ文字列である。

フィールド９１７〜９３１の部分がもう一つのブロックであり、フィールド９１７〜９２０の情報より、この部分が「ＧＳ２００５．ｔｉｆ」というファイル名のＴＩＦＦ画像ファイルであることが示されている。また、フィールド９２２〜９２９のデータは、このファイルをＢＡＳＥ６４エンコードしたデータであることを示している。

実施形態３の電子メールデータでは、実施形態１の電子メールデータの構成に加えて、送達確認メールの要求を明示的に記述している。

次に、ＭＦＰ１０１で、図１１の電子メールデータを受信する際の電子メールデータ解析処理について、図１２を用いて説明する。

図１２は本発明の実施形態３の電子メールデータ解析処理を示すフローチャートである。

電子メールデータを受信すると、ステップＳ９５１で、画像抽出処理を実行する。ここでは、メール本文のデータ（図１１の９１５）はＪＩＳコードからＳＪＩＳコードのテキスト情報に変換し、その後、ラスタライズ処理を施して画像データに変換する。

また、電子メールデータ中の画像データ部分（図１１の９２２から９２９）は、ＢＡＳＥ６４形式でデコードして、ＴＩＦＦファイルに変換する。次に、ＴＩＦＦファイルから、１ページ単位の画像データを切り出し、切り出したデータに対して画像デコード処理を行う。

次に、ステップＳ９５２で、Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールド（図１１の９０４）中に宛先が存在するか否かを判定する。

宛先が存在する場合（ステップＳ９５２でＹＥＳ）、ステップＳ９５３に進み、ＭＤＮデータを送信する宛先情報（ここでは、ｉｆａｘ＠ｃｏｐｙ１．ｘｙｚ．ｃｏ．ｊｐ）を抽出する。そして、ステップＳ９５４で、その宛先情報に対するＭＤＮデータを作成し、送信する。

一方、宛先が存在しない場合（ステップＳ９５２でＮＯ）、ステップＳ９５５に進み、Ｘ−ＭＤＮＤＩＲＥＣＴフィールド（図１１の９０５）が存在するか否かを判定する。

尚、ステップＳ９５２で、Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールドに宛先が存在しないと判断してステップＳ９５５に進んだ場合、ステップＳ９５９に進む。なぜなら、Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールドがない場合はＭＤＮを要求していないため、原則Ｘ−ＭＤＮＤＩＲＥＣＴフィールドが存在しないためである。逆に言えば、ＭＤＮ要求を行う場合はＤｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールドを付す。

Ｘ−ＭＤＮＤＩＲＥＣＴフィールドが存在する場合（ステップＳ９５５でＹＥＳ）、ステップＳ９５６に進み、Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏの宛先を、ＤＮＳサーバに問い合わせて、送信すべき宛先のＩＰアドレスを取得する。

この際、ＤＮＳサーバには、ＨＯＳＴ名のＡレコードまたはメール配信専用のＭＸ（Ｍａｉｌ ｅＸｃｈａｎｇｅ）レコードを用いてＤｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−ＴｏのＩＰアドレスを取得する。ステップＳ９５７で、ＭＤＮデータを、ステップＳ９５６で取得したＩＰアドレスに対応する宛先にＳＭＴＰプロトコルを用いて送信する。

一方、Ｘ−ＭＤＮＤＩＲＥＣＴフィールドが存在しない場合（ステップＳ９５５でＮＯ）、ステップＳ９５８で、ＭＤＮデータをメールサーバ（例えば、サーバ１０３）に送信する。

ステップＳ９５９で、受信した電子メールデータより抽出した画像データに対して印刷設定の有無を判定する。印刷設定がある場合（ステップＳ９５９でＹＥＳ）、ステップＳ９６０に進み、その印刷設定に従って印刷を実行する。一方、印刷設定がない場合（ステップＳ９５９でＮＯ）、ステップＳ９６１に進み、転送設定の有無を判定する。

転送設定がある場合（ステップＳ９６１でＹＥＳ）、ステップＳ９６２に進み、その転送設定に従って転送を実行する。尚、この転送設定による転送先としては、ＦＡＸ、ＩＦＡＸや、ＦＴＰ、ＳＭＢ等のファイル転送の宛先がある。

一方、転送設定がない場合（ステップＳ９６１でＮＯ）、処理を終了する。

尚、ステップＳ９５９やステップＳ９６１における印刷設定及び転送設定の有無の判定は、例えば、電子メールデータの受信時に、電子メールデータに設定されている属性情報に従って行う。

また、電子メールの受信方法としては、ＳＭＴＰ、ＰＯＰ受信を用いて説明したが、ＩＭＡＰ等の他の予め定められた通信プロトコルを用いて、電子メールを受信する構成であっても良い。

以上説明したように、実施形態３によれば、ＭＤＮデータの要求をＳＭＴＰプロトコルに従って送信するのではなく、電子メールデータ中に、ＭＤＮデータの要求を示す情報を記述する構成とする。

この構成によれば、例えば、ＭＤＮデータの要求をＳＭＴＰプロトコル中に従って直接送信先へ送信しようとして、誤ってメールサーバ経由で送信してしまった場合に、そのＭＤＮデータの要求が消失してしまう可能性を防止することが可能となる。

以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (9)

1. 電子メールデータを生成する生成手段と、
   前記生成手段が生成した電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報とともに、当該電子メールデータを受信装置に送信する送信手段と、
   前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信手段と、
   を備えることを特徴とする送信装置。
2. 前記送信手段は、前記生成手段が生成した電子メールデータをメールサーバを経由させずに前記受信装置に送信する場合に、前記情報を送信する
   ことを特徴とする請求項１に記載の送信装置。
3. 前記送信手段は、前記生成手段が生成した電子メールデータを送信するために用いる通信プロトコルのコマンドの１つとして、前記情報を送信する
   ことを特徴とする請求項１または２に記載の送信装置。
4. 前記通信プロトコルとは、ＳＭＴＰプロトコルである
   ことを特徴とする請求項３に記載の送信装置。
5. 電子メールデータを受信装置に送信する送信装置であって、
   前記電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報を含む、前記電子メールデータを生成する生成手段と、
   前記生成手段が生成した電子メールデータを前記受信装置に送信する送信手段と、
   前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信手段と、
   を備えることを特徴とする送信装置。
6. 前記情報は、前記電子メールデータのヘッダフィールドに含まれる
   ことを特徴とする請求項５に記載の送信装置。
7. 電子メールデータを生成する生成工程と、
   前記生成工程で生成した電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報とともに、当該電子メールデータを受信装置に送信する送信工程と、
   前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信工程と、
   を備えることを特徴とする送信装置の制御方法。
8. 電子メールデータを受信装置に送信する送信装置の制御方法であって、
   前記電子メールデータに関する送達確認結果をメールサーバを経由させずに送信することを要求する情報を含む、前記電子メールデータを生成する生成工程と、
   前記生成工程で生成した電子メールデータを前記受信装置に送信する送信工程と、
   前記情報に基づいて前記受信装置によりメールサーバを経由させずに送信された前記送達確認結果を受信する受信工程と、
   を備えることを特徴とする送信装置の制御方法。
9. 請求項７または８に記載の送信装置の制御方法をコンピュータに実行させるためのプログラム。

Images