トップ :: H 電気 :: H04 電気通信技術




【発明の名称】 画像通信装置及び画像通信装置の制御方法並びに記憶媒体
【発明者】 【氏名】菅原 一浩
【要約】 【課題】インターネットファクシミリ装置において、受信電子メールに既読確認要求がなされていることを受信機側のユーザへ伝えるための有効な手段を提供することを目的とする。

【構成】画像ファイルが添付された電子メールに既読確認を要求する情報が含まれていることを検出した場合、電子メールを受信した画像通信装置のユーザへ通知を行う。
【特許請求の範囲】
【請求項１】
ネットワークに接続された画像通信装置であって、
画像ファイルが添付された電子メールを受信する電子メール受信手段と、
前記電子メール受信手段が受信した電子メールから、前記電子メールを前記画像通信装置がどのように処置したかを示す情報を含む応答電子メールを要求する制御情報を検出する検出手段と、
前記検出手段が前記制御情報を検出したことを前記画像通信装置のユーザへ通知する通知手段と、
前記応答電子メールを前記電子メールの送信元へ送信する送信手段と、
を備えることを特徴とする画像通信装置。
【請求項２】
前記通知手段は、前記制御情報が検出された電子メールの内容が可視出力される前に通知を行うことを特徴とする請求項１に記載の画像通信装置。
【請求項３】
前記応答電子メールは、Ｍｅｓｓａｇｅ Ｄｉｓｐｏｓｉｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎであることを特徴とする、請求項１または請求項２のいずれか１項に記載の画像通信装置。
【請求項４】
ネットワークに接続された画像通信装置の制御方法であって、
画像ファイルが添付された電子メールを受信する電子メール受信工程と、
前記電子メール受信工程で受信した電子メールから、前記電子メールを前記画像通信装置がどのように処置したかを示す情報を含む応答電子メールを要求する制御情報を検出する検出工程と、
前記検出工程にて前記制御情報を検出したことを前記画像通信装置のユーザへ通知する通知工程と、
前記応答電子メールを前記電子メールの送信元へ送信する送信工程と、
を備えることを特徴とする画像通信装置の制御方法。
【請求項５】
請求項４の制御方法を画像通信装置に実行させるためのプログラムを格納した記憶媒体。
【発明の詳細な説明】【技術分野】
【０００１】
本発明は、インターネット等のネットワークを介して電子メールを送受信することが可能な画像通信装置に関し、特に、電子メールにより送信した画像の既読確認に関するものである。
【背景技術】
【０００２】
近年、インターネット等のネットワークを介して電子メールを送受信することが可能な画像通信装置として、インターネットファクシミリ装置が提案されている。このインターネットファクシミリ装置では、読み取った画像データをファイルとして電子メールに添付する方式で受信機へ画像を送信する。
【０００３】
ここで、送信された電子メールは、ネットワーク上の１以上のメールサーバを介してストア・アンド・フォワード方式で宛先の受信機へ送信される。そのため、上記インターネットファクシミリ装置における画像データの送信結果については、単にメールサーバに対しての送信結果に過ぎず、通信管理レポート、若しくは、送信結果レポートの記載内容から画像データが正しく受信機で処理されたか否かを確認することはできなかった。
【０００４】
一方、電子メール通信において既読確認を行うための技術が提案されている。
【０００５】
非特許文献１（ＲＦＣ２２９８）によれば、送信側のＵＡ（ｍａｉｌ ｕｓｅｒ ａｇｅｎｔ）と受信側ＵＡは次のように動作することにより、既読確認（Ｍｅｓｓａｇｅ Ｄｉｓｐｏｓｉｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ、以下単にＭＤＮと称す）が実現される。
【０００６】
（１）送信側ＵＡは、既読確認を行う場合、“Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏ：＜返信メールアドレス＞”をメールのヘッダに付加してメールを送信する。
【０００７】
（２）受信側のＵＡは、このメールを受信したら、送信者が既読確認を要求している事を表示し、送信者に既読確認の返信メールを送るかどうかを問い合わせ、返信メールを送る場合は、既読確認用のヘッダを付加して返信メールを送信し、返信メールを送らない場合は、このヘッダを無視する。
【０００８】
（３）送信側のＵＡは、既読確認の返信メールを受信したら、既読確認済みのメールを表示する。
【０００９】
しかし、インターネットファクシミリ装置の場合、装置の前に常にユーザがいるわけではないので、既読確認を要求する情報がヘッダに付された電子メールを受信したことをユーザが気づかない、あるいいは気づくのが遅れる場合があり、既読確認を返信しなかったり返信するのが遅れてしまうことがあった。
【００１０】
また、インターネットファクシミリの場合、受信した電子メールの添付画像ファイルを正しく可視出力可能であることが確認できて初めて当該送信が正しく完了したものとして取り扱うべきであり、それ以前に既読確認を返信してしまうことにより、既読確認の信頼性が低下してしまうことがあった。
【非特許文献１】ＲＦＣ２２９８（Ａｎ Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｅ Ｆｏｒｍａｔ ｆｏｒ Ｍｅｓｓａｇｅ Ｄｉｓｐｏｓｉｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎｓ、ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２９８．ｔｘｔ）
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかし、インターネットファクシミリを受信する受信機側の画像通信装置において、受信電子メールに既読確認要求がなされていることを受信機側のユーザへ伝えるための有効な手段が無かった。
【課題を解決するための手段】
【００１２】
本発明は上述の課題を鑑みてなされたものであり、その目的は受信機側の画像通信装置において、受信電子メールに既読確認要求がなされていることを受信機側のユーザへ伝えるための有効な手段を提供することである。
【００１３】
上記目的を達成するために本発明の画像通信装置は、ネットワークに接続された画像通信装置であって、画像ファイルが添付された電子メールを受信する電子メール受信手段と、前記電子メール受信手段が受信した電子メールから、前記電子メールを前記画像通信装置がどのように処置したかを示す情報を含む応答電子メールを要求する制御情報を検出する検出手段と、前記検出手段が前記制御情報を検出したことを前記画像通信装置のユーザへ通知する通知手段と、前記応答電子メールを前記電子メールの送信元へ送信する送信手段と、を備えることを特徴とする。
【発明の効果】
【００１４】
本発明の画像通信装置によれば、既読確認を要求している電子メールを受信したことを確実に受信機側のユーザに通知することが出来る。
【発明を実施するための最良の形態】
【００１５】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００１６】
まず、本実施形態のインターネットファクシミリ装置の構成を説明する。
【００１７】
図１は、本発明の実施形態におけるインターネットファクシミリ装置の構成を示すブロック図である。
【００１８】
図１において、１−１は、ファクシミリを制御するためのＣＰＵである。
１−２は、ファクシミリの操作部で、ＬＣＤと入力用のキーパネルなどで構成され、ファクシミリの通信・記録などの入力操作を可能にする。またアラームを鳴動するためのスピーカ等の音源手段も配置されている。
１−３は、送信するファクシミリ原稿の画像を読み取る読取部である。
１−４は、受信した画像データや電子メールの本文、各種レポートなどを出力するための記録部である。
１−５は、本発明の実施形態に係るファクシミリの制御用のプログラムとデータを格納した記憶媒体としてのＲＯＭであり、ファクシミリ送信・受信、電子メールの送信・受信、レポート生成、記録・読取、ユーザＩ／Ｆなどを制御するためのプログラムを格納している。
１−６は、ファクシミリの各種情報を格納するためのＲＡＭで、送信・受信時に生成される通信管理情報や画像データなどを格納している。
１−７は、ＭＯＤＥＭで公衆回線（ＰＳＴＮまたはＩＳＤＮ）１−９に対してファクシミリの送受信を行うための変復調回路である。
１−８は、ＰＳＴＮ１−９に対するネットワーク制御回路（ＮＣＵ）である。
１−９は、ローカルエリアネットワーク（ＬＡＮ）１−１０に接続するためのＩ／Ｆユニットである。
１−１１は、電子メールデータの交換が可能なＬＡＮまたはインターネットである。ＬＡＮの場合は、ファイアウオールやサービスプロバイダ等を介してインターネットへとつながっている。
１−１１は、ＬＡＮまたはインターネットを介して接続されているメールサーバである。
【００１９】
本願クレームにおけるインターネットファクシミリ装置を用いた電子メール送信は、ＦＡＸ操作部１−２により宛先を指定し、読取装置１−３により送信原稿の画像を読み取り、Ｅ−ｍａｉｌ送信制御プログラムにより電子メールに読み取った画像を添付して送信される。尚、電子メールの形式および添付画像の圧縮方法などの詳細に関しては、ＩＴＵ−Ｔ Ｔ．３７（インターネットを介したファクシミリ送信の勧告）に基づくものとする。
【００２０】
以下、第１の実施形態として、既読確認付きのインターネットファクシミリデータを送信する送信機側の動作を説明し、第２の実施形態として既読確認付きインターネットファクシミリデータを受信する受信機側の動作を説明する。
【００２１】
＜第１の実施形態＞
第１の実施形態として、既読確認付きのインターネットファクシミリデータを送信する送信機（以下、第１の実施形態のインターネットファクシミリ装置と称する）側の動作を説明する。
【００２２】
まず、第１の実施形態のインターネットファクシミリ装置における通信結果情報の管理方法を説明する。
【００２３】
本実施形態のインターネットファクシミリ装置では、ファクシミリ送受信、および、電子メール送受信の結果を通信管理情報として記憶・管理する。
【００２４】
図２は、第１の実施形態におけるファクシミリの通信管理情報のデータ構成を示している。
２−１は、ファクシミリの送信・受信、または電子メールによる送信・受信を実行するごとに作成される通信管理情報を格納するための通信管理情報テーブルである。通信管理情報テーブル２−１の個々の通信管理情報には２−２〜２−１２に示す情報が格納される。２−２には、通信管理番号で送信時に１〜４９９９、受信時に５００１〜９９９９までの通番が割り振られる。
【００２５】
２−３には、ユーザＩＤでファクシミリの送信時のユーザ略称、発信人名称、電子メールの送信時のＦｒｏｍ：フィールド欄に記述される情報を格納する。
【００２６】
２−４には、送信・受信、Ｇ３やＥＣＭなどのファクシミリ送信・受信モード、Ｉ−ＦＡＸ（電子メールによるファクシミリ送信）などの通信モードを確認する。
【００２７】
２−５には、通信時間を格納する。ＬＡＮを介した送信、受信の場合は、サーバとの接続時間になる。
【００２８】
２−６には、通信を開始した時間を格納する、送信・受信原稿の枚数を格納する。画像無しの電子メールを受信した場合は、枚数情報な無いものとして格納される。
２−８には、相手先電話番号または相手先のメールアドレスを格納する。
２−９には、電子メール送信時にメールヘッダの“Ｍｅｓｓａｇｅ−ＩＤ：”に記述したメッセージＩＤと、受信時メールヘッダの“Ｍｅｓｓａｇｅ−ＩＤ：”に記述されているメッセージＩＤを格納する。
【００２９】
この“Ｍｅｓｓａｇｅ−ＩＤ”に記述されたＩＤは、電子メールをインターネット上で一意に識別するために、送信側のＩＰアドレスやドメイン名、送信時刻、通信管理番号などを組み合わせて作成される。
【００３０】
２−１０には、通信結果を示す情報を格納する。ＰＳＴＮ経由のＧ３通信であればその結果を格納し、インターネットファクシミリ送信であれば、デフォルトのメールサーバまでの通信結果を格納する。
【００３１】
２−１１には、送信した電子メールのＭＤＮステータスを格納する。このＭＤＮステータスとしては、例えば次のようなものがある。
【００３２】
「ＭＤＮ無し」は、既読確認が要求されなかったことを示す。「ＭＤＮ要求中」は既読確認が要求され、その確認中であることを示す。「ＭＤＮ確認済み」は、要求した既読確認に応じた電子メールを受信したことを示す。
【００３３】
２−１２には、ＭＤＮ通信結果情報、すなわち既読確認を要求した場合のＭＤＮに対する受信側の応答結果を示す。
【００３４】
尚、図２に示した例では、送信／受信や、Ｇ３ファクシミリ通信／インターネットファクシミリ通信といった異なる通信モードの通信を１つのテーブルにより管理しているが、各通信モードごとに異なるテーブルにより管理するものであってもよい。
【００３５】
次に本実施形態のインターネットファクシミリ装置における電子メール送信処理を説明する。
【００３６】
図３は、第１の実施形態のインターネットファクシミリ装置における電子メール送信処理を示すフローチャートである。
【００３７】
まずステップＳ３−１では、送信の開始で通信管理テーブルより通信管理情報を格納するための領域を１つ確保する。領域が空いていない場合には、一番古い通信管理情報を上書きして確保する。また、確保した領域の通信管理情報に対して、通信管理番号２−２を付与する。
【００３８】
ステップＳ３−２では、送信メールに対する通信管理情報を生成する。具体的には送信メールを識別するための唯一のＩＤとしてメッセージＩＤを生成し、通信モードをインタネットファクシミリ送信を示すＩ−ＦＡＸ送信とし、通信開始時間・ページ数・相手先メールアドレス・エラーコード（通信結果：未定）を設定する。
【００３９】
ステップＳ３−３では、既読確認（ＭＤＮ）を行うか否か、すなわち、既読確認要求ヘッダを付けるか否かを判断し、付ける場合はステップＳ３−３に、付けない場合はステップＳ３−５に進む。
【００４０】
ここで、既読確認を行うか否かの設定は、ステップＳ３−３の判断以前に、ユーザがＦＡＸ操作部１−２により設定されているものとする。
【００４１】
ステップＳ３−４では、既読確認要求ヘッダ（“Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏ：＜送信元アドレス＞”）を付けたメールヘッダを作成する。
【００４２】
ステップＳ３−５では、通信管理情報のＭＤＭステータス２−１１に、「ＭＤＮ要求中」ステータスを書き込む。
【００４３】
ステップＳ３−６では、ＭＤＮ要求ヘッダなしで送信メールのヘッダを作成する。
【００４４】
ステップＳ３−７では、通信管理情報のＭＤＮステータス２−１１に、「ＭＤＮ要求無し」の情報を書き込む。
【００４５】
ステップＳ３−８では、メールサーバに対して、送信するための画像ファイルを添付した電子メールの送信処理を実行する。
【００４６】
ステップＳ３−９では、メールサーバに対して、メールの送信が完了したら、通信管理情報のＭＤＮステータスの値を読み出して、「ＭＤＮ要求中」ならステップＳ３−９に進み、「ＭＤＮ要求中」でないならステップＳ３−１０に進む。
【００４７】
ステップＳ３−１０では、ＭＤＮ受信待ちを送信結果に書き込み、通信管理情報を更新する。
【００４８】
ステップＳ３−１１では、送信結果に正常終了を書き込み、通信管理情報を更新する。
【００４９】
以上の処理により、電子メール送信の通信管理情報が、通信管理情報テーブル２−１にセットされる。
【００５０】
次に本実施形態のインターネットファクシミリ装置における電子メール受信処理を説明する。
【００５１】
本実施形態における電子メールの受信処理は、装置側の設定により一定周期にメールサーバへ受信メールの確認を行うことで行う。
【００５２】
図４は、第１の実施形態のインターネットファクシミリ装置における受信電子メールの処理を示すフローチャートである。メールサーバから受信した各電子メールについて図４のフローチャートに基づく処理が実行される。
【００５３】
ステップＳ４−１では、受信メール用に通信管理情報を格納するための領域を確保し、通信管理番号を取得する。
【００５４】
ステップＳ４−２では、受信メールのヘッダ部よりメッセージＩＤを取得し、ステップＳ３−２と同様に通信管理情報を生成する。
【００５５】
ステップＳ４−３では、通信管理情報テーブル２−１をサーチしてＭＤＮ受信待ちの通信管理情報があるかを判定し、ある場合はステップＳ４−４に進み、ない場合はステップＳ４−８に進む。
【００５６】
ステップＳ４−４では、受信電子メールが既読確認要求に応答するＭＤＮであるか否かを判定し、肯定判断の場合はステップＳ４−５に移行し、否定判断の場合はステップＳ４−６に移行する。
【００５７】
ステップＳ４−５では、受信したＭＤＮの解析処理を実行し、受信したＭＤＮに対応する送信電子メールの通信管理情報の更新を行う。尚、このステップＳ４０５の処理の詳細については後に図５を参照して詳述する。
【００５８】
ステップＳ４−６は、ＭＤＮ受信待ちのメールがあるにもかかわらず、受信メールがＭＤＮで無かった場合であり、このステップではＭＤＮ受信待ちの通信管理情報の待ち時間がオーバーしたか否かを判断する。肯定判断の場合はステップＳ４−７に進み、否定判断の場合はステップＳ４−８に進む。
【００５９】
ステップＳ４−７では、ＭＤＮ要求を行った送信メールに関する通信管理情報の通信結果として、「ＭＤＮ未受信」を書き込む。
【００６０】
ステップＳ４−８では、ＭＤＮメールでないのため、所定の処理を実行する。この所定の処理としては、例えば受信電子メールに添付された画像データを印刷したり、他の装置へ転送したりする処理等がある。
【００６１】
ステップＳ４−９では、ステップＳ４−８により処理された結果に基づいて受信メールの通信管理情報を更新する。
【００６２】
以上の処理により、受信電子メールの通信管理情報の更新処理が実行される。
【００６３】
次に、ステップＳ４−５における受信したＭＤＮの解析処理の詳細を図５参照して説明する。
【００６４】
ステップＳ５−１では、受信した電子メールより１ラインのデータを取得する。
【００６５】
ステップＳ５−２では、先頭文字列が、ＭＤＮに対応する送信電子メールのメッセージＩＤを示すためのヘッダである“Ｏｒｉｇｉｎａｌ−Ｍｅｓｓａｇｅ−ＩＤ：”か否かを判断し、否定判断の場合はステップＳ５−１に戻って次のデータラインを取得し、肯定判断の場合はステップＳ５−３に進む。
【００６６】
ステップＳ５−３では、送信メールの通信管理情報のメッセージＩＤから（Ｓ５−２）に示されたメッセージＩＤがあるかどうかを検索する。
【００６７】
ステップＳ５−４では、該当するメッセージＩＤが検索された場合は、その通信管理情報のエリアをポインタ等で特定しステップＳ５−５に進み、検索されなかった場合は、ステップＳ５−１０に進む。
【００６８】
ステップＳ５−５では、さらに受信メールから１ライン取得し、ステップＳ５−６で取得したラインの先頭文字列が“Ｄｉｓｐｏｓｉｔｉｏｎ：”であるか否かを判断する。この判断が肯定判断の場合には、ステップＳ５−７に進み、否定判断の場合にはステップＳ５−５に戻って次の１ラインを取得する。
【００６９】
ステップＳ５−７では、Ｄｉｓｐｏｓｉｔｉｏｎ：のヘッダの内容に基づいて、ステップＳ５−４において特定した通信管理情報の通信結果２−１２の内容を更新する。
【００７０】
ここで、Ｄｉｓｐｏｓｉｔｉｏｎ：のヘッダにセットされるパラメータはＲＦＣ２２９８に定義されている。
【００７１】
アクションモード（ａｃｔｉｏｎ−ｍｏｄｅ）は、ＭＤＮに関する処理が、自動で行われたのか、手動で行われたのかを示す（“ｍａｎｕａｌ−ａｃｔｉｏｎ”／“ａｕｔｏｍａｔｉｃ−ａｃｔｉｏｎ”）。
【００７２】
送信モード（ｓｅｎｄｉｎｇ−ｍｏｄｅ）は、ＭＤＮの送信が手動で行われたか、自動で行われたかを示す（“ＭＤＮ−ｓｅｎｔ−ｍａｎｕａｌｌｙ”／“ＭＤＮ−ｓｅｎｔ−ａｕｔｏｍａｔｉｃａｌｌｙ”）。
【００７３】
処置タイプ（ｄｉｓｐｏｓｉｔｉｏｎ−ｔｙｐｅ）は、送信された電子メールが受信側ＵＡにおいてどのように処置されたかを示す。具体的には、「表示された（“ｄｉｓｐｌａｙｅｄ”）」、「印刷や転送等の何らかの処理がなされた（“ｄｉｓｐａｔｃｈｅｄ”）」、「決められた処理を実行した（“ｐｒｏｃｅｓｓｅｄ”）」、「削除された（“ｄｅｌｅｔｅｄ”）」、「拒否された（“ｄｅｎｉｅｄ”）」、「失敗した（“ｆａｉｌｅｄ”）」がある。
【００７４】
このようにＲＦＣ２２９８には、受信側の電子メールの処理に応じたパラメータが、Ｄｉｓｐｏｓｉｔｉｏｎヘッダにセットされるので、予め定めたルールに基づいて送信した電子メールの既読確認がされたか否かを判断し、その結果をＭＤＮ通信結果２−１２に反映する。
【００７５】
ステップＳ５−８では最終ラインか否かを判断し、肯定判断の場合はステップＳ５−９に進み、否定判断の場合はステップＳ５−５に戻って次のラインについて最終ラインか否かの判断を行う。
【００７６】
ステップＳ５−９では、ＭＤＮにて“Ｄｉｓｐｏｓｉｔｉｏｎ：”フィールドがない場合は、受信したＭＤＮのメールが正常でないことを示しており、ＭＤＮ受信メールのＭＤＮ通信結果２−１２に受信エラーを示す情報をセットする。送信電子メールのアドレスが誤っていたために、メールサーバからエラーを通知する電子メールが返ってきた場合等は、この処理が実行されることになる。
【００７７】
ステップＳ５−１０では、該当メッセージＩＤが無いため、ＭＤＮ受信メールのＭＤＮ通信結果２−１２に受信エラーを示す情報をセットする。
【００７８】
ここで、図４のステップＳ４−９の処理、図５のステップＳ５−９の処理、ステップＳ５−１０の各処理は、それぞれ異なる要因でＭＤＮ返信メールが受信できずに通信管理情報にエラーをセットする処理であるが、それぞれのエラー要因を識別するためのエラーコードをセットしてレポート等で可視出力する。これにより、電子メールの送信者は、エラーを詳細に検証することが可能となる。
【００７９】
図６は、第１の実施形態のインターネットファクシミリ装置における通信管理レポートの出力例を示す図であり、この通信管理レポートは、通信管理情報２−１に記憶されている内容に基づいて出力される。同図の例では、電子メールでファクシミリ送信をした場合（すなわちインターネットファクシミリ送信をした場合）、通信モードの欄に“送信 Ｉ−ＦＡＸ”と記述し、この例では、３件の“送信 Ｉ−ＦＡＸ”が記述されている。
【００８０】
最初のＮｏ．０００２の件は、通信モードに「ＭＤＮ未」と表示することにより未だ既読確認を受信していないことを示し、通信結果の欄に「−−」を表示することにより結果不明であることを示している。
【００８１】
次のＮｏ．０００３の件は、通信モードに「ＭＤＮ済」と表示することにより既に既読確認済みであることを示し、通信結果の欄にＯＫを記述している。
【００８２】
最後のＮｏ．０００４の件は、通信モードの欄にＭＤＮに関する表示をしないことによりＭＤＮの要求がされなかったことを示しており、通信結果の欄にＯＫのみを記述している。
【００８３】
このように通信管理レポートを出力する際に、既読確認の要求の有無、および、その出力時点における既読確認状況を各通信ごとに表示するので、ユーザは各通信ごとの既読確認の状況を把握することができるようになる。
【００８４】
尚、図６の例では、インターネットファクシミリ送信の通信結果の欄にセットされるＯＫ／ＮＧは、メールサーバまでの送信結果とＭＤＮ通信結果を合わせて１つの通信結果として印字している。すなわち、メールサーバまでの送信結果とＭＤＮ通信結果がともに正常終了の場合のみＯＫとしている。
【００８５】
そこで、変形例として、メールサーバまでの送信結果とＭＤＮ通信結果とを別個の欄に印字するようにしてもよい。
【００８６】
図７及び図８は、既読確認要求付きのインターネットファクシミリ送信した場合の送信結果レポートの出力例である。図７が通信結果がＯＫで既読確認済みの場合の例であり、図８が通信結果がＮＧで既読確認済みの場合の例である。
【００８７】
図７の例では、図５のＭＤＮ解析処理にて“Ｄｉｓｐｏｓｉｔｉｏｎ：”ヘッダの内容から送信結果をＯＫとして通信管理情報を更新し（ステップＳ５−７）、送信結果レポートとして出力する。
【００８８】
送信結果を出力時期については、既読確認のメールを受信するまで送信結果レポートの出力を行わないものとする。既読確認メールの受信待ちで決められた時間経過後（ステップＳ４−６）は、既読確認未受信とし、送信エラーとして送信結果レポートを出力する。
【００８９】
図８の例では、図５のＭＤＮ解析処理にて“Ｄｉｓｐｏｓｉｔｉｏｎ：”ヘッダの内容から送信結果をＮＧとして通信管理情報を更新し（ステップＳ５−７）、送信結果レポートとして出力している。
【００９０】
このように第１の実施形態によれば、既読確認付きのインタネットファクシミリ送信を行った場合に、その既読確認に対する応答状況を通信管理情報に詳細に反映して印字または表示することが可能となった。
【００９１】
これにより、インターネットファクシミリの送信者は、インターネットファクシミリ送信の通信状況・通信結果の内容を正確に把握することが可能となり、ユーザにとって分かり易く親切なインターネットファクシミリ装置を提供できる。
【００９２】
尚、上記第１の実施形態では、受信機からのＭＤＮ応答状況を反映した通信管理情報をレポート出力という形で送信者に通知する例を示したが、この通信管理情報をＦＡＸ操作部１−２に表示するような形態にしてもよい。
【００９３】
更に、図１で示したインターネットファクシミリ装置の構成に、ＬＡＮ１−１１上のＷｅｂクライアントに対して各種データを公開するためのＷｅｂサーバ機能を持たせ、通信管理情報をＸＭＬ或いはＨＴＭＬ形式に変換してＷｅｂサーバ機能によりＬＡＮ１−１１上のユーザに公開するような形態にしてもよい。
【００９４】
＜第２の実施形態＞
第２の実施形態として既読確認付きインターネットファクシミリデータを受信する受信機側の動作を説明する。
【００９５】
ここで、受信機側のインタネットファクシミリ装置（以下、第２の実施形態のインターネットファクシミリ装置と称する）は、図２で示した第１の実施形態のインターネットファクシミリ装置と同様の通信管理情報２−１により各受信を管理するものとする。
【００９６】
図９は、第２の実施形態のインターネットファクシミリ装置における既読確認の要求ヘッダ有りで電子メールを受信した時の動作を示すフローチャートである。
【００９７】
まず、通信管理情報２−１のエリアを確保し、確保したエリアに当該受信電子メールに関する情報（図２の２−２〜２−１２の情報）をセットする。その際、ＭＤＮステータス２−１１には、ＭＤＮ要求無しを示す情報をセットする。
【００９８】
ステップＳ９−１では、既読確認の要求があるか否かを判断する。この判断は、ＲＦＣ２２９８に基づくＭＤＮ要求ヘッダ（“Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏ：＜送信元アドレス＞”）を付けたメールヘッダがあるか否かで判断し、ＭＤＮ要求ヘッダがある場合はステップＳ９−２に進み、ＭＤＮ要求ヘッダが無い場合はステップＳ９−３に進む。
【００９９】
ステップＳ９−２では、受信メールの通信管理情報２−１にてＭＤＮ要求有りの情報をＭＤＮステータス２−１０にセットする。
【０１００】
ステップＳ９−３では、ＲＡＭ１−６に予め登録されている「既読確認要求有りの電子メールを受信した場合の処理」を示すユーザ登録情報に基づいて、アラームを鳴動するか否かを判断する。アラームを鳴らす場合はステップＳ９−４に進み、アラームを鳴らさない場合は、ステップＳ９−５に進む。
【０１０１】
ステップＳ９−４では、既読確認要求有りのアラームを操作部１−２に配置されたスピーカにより鳴動する。
【０１０２】
ステップＳ９−５では、ＲＡＭ１−６に予め登録されている「既読確認要求有りの電子メールを受信した場合の処理」を示すユーザ登録情報に基づいて、受信結果レポートを出力するか否かを判断する。受信結果レポートを出力する場合はステップＳ９−６に進み、受信結果レポートを出力しない場合はステップＳ９−７に進む。
【０１０３】
ステップＳ９−６では、ＭＤＮ要求有りの情報を付した受信結果レポートを出力する。この受信結果レポートの出力例については後述する。
【０１０４】
ステップＳ９−７では、「既読確認要求有りの電子メールを受信した場合の処理」を示すユーザ登録情報に基づいて、ＭＤＮを自動で返信するか否かを判断する。ＭＤＮを自動で返信する場合はステップＳ９−８に進み、ＭＤＮを自動で返信しない場合はステップＳ９−１３に進む。
【０１０５】
ステップＳ９−８では、ＭＤＮの返信メールを作成して「Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｈｅａｄｅｒ」にセットされているＭＤＮ通知先アドレスに送信する。
【０１０６】
ステップＳ９−９送信後はＭＤＮステータス２−１１にＭＤＮ返信メールを送信したことを、すなわち既読確認の電子メールを送信済みであることを示す情報をセットする。
【０１０７】
ステップＳ９−１３では、操作部１−２のＬＥＤまたはＬＣＤ表示にてＭＤＮ要求有りを表示し、メモリ受信画像有りとしてＬＥＤを点灯し、メモリに受信メールを蓄積して受信メールの処理を終了する。
【０１０８】
ステップＳ９−１０では、受信した電子メールに添付されている画像にＭＤＮ要求有りを示すマークをヘッダに付加して出力する。一般に受信したファクシミリ画像に所定のマークを合成して出力する技術は周知であり、本実施形態でも同様の技術により実現される。尚、この画像の出力例については後述する。
【０１０９】
ステップＳ９−１１では、受信した電子メールに添付されている画像にＭＤＮ要求有りを示すマークを付けないヘッダを付加して出力する。
【０１１０】
以上のフローチャートが、既読確認の要求ヘッダ有りで電子メールを受信した時の動作である。
【０１１１】
ここで着目すべきは、受信電子メールの内容、および、受信電子メールに添付された画像が可視出力する前、すなわち、ステップＳ９−４、ステップＳ９−６、ステップＳ９−１０若しくは、ステップＳ９−１３において、ＭＤＮ要求が付されていることをユーザに報知している点である。
【０１１２】
これにより、ユーザは受信電子メールの内容を確認することなくＭＤＮ要求が付されていることを判別でき、送信者に対していち早く既読確認を返信することが可能となる。
【０１１３】
尚、図９に示したフローチャートを種々変形することも可能であり、その変形例として、以下、第１の変形例と第２の変形例を図１２のフローチャート（図９のフローチャートを変形したもの）を参照して説明する。
【０１１４】
（第１の変形例）
上記の例では、図９のステップＳ９−７の判断が否定判断の場合に、ステップＳ９−９でＭＤＮ要求有りと表示した後、ステップＳ９−１０で受信画像を出力するようにした。
【０１１５】
第１の変形例では、図１２のステップＳ１２−７の判断が否定判断の場合のＳ１２−９の表示の後、受信画像を出力せずにいったん処理を終了する。その後、ユーザによる所定の操作に応じて、受信画像を出力するとともに、ＭＤＮ返信メールを送信する。
【０１１６】
（第２の変形例）
上記の例では、図９のステップＳ９−７の判断が肯定判断の場合に、まずステップＳ９−８でＭＤＮ返信メールを送信し、ステップＳ９−１０で受信画像を出力した。
【０１１７】
第２の変形例では、図１２のステップＳ１２−７が肯定判断の場合に、ステップＳ１２−８で先に受信画像の出力を行った後、ステップＳ１２−１０で正常に出力された否かを判断する。この判断が肯定判断の場合にはステップＳ１２−１３でＭＤＮ返信メールを送信する（ＭＤＮステータス２−１１にＭＤＮ返信メールを送信した旨をセットする）。一方、否定判断の場合には、ステップＳ１２−１２に進み、Ｓ１２−１０で出力しようと試みた受信画像に対応するＭＤＮ返信メールの送信を自動から手動に切り替える。その後、ユーザによる所定の操作に応じて、受信画像を出力するとともに、該受信画像に対応するＭＤＮ返信メールを送信する。
【０１１８】
上記第１の変形例によれば、ユーザによる所定の手動操作に連動して受信画像の出力動作と該出力画像に対応するＭＤＮ返信メールの送信とが自動的に実行されるので、ＭＤＮ返信メールの信頼性が向上する。
【０１１９】
また、上記第２の変形例によれば、ＭＤＮ返信メールを自動的に送信する場合でも、受信画像が正常に出力されないにもかかわらず、ＭＤＮ返信メールが自動的に送信されてしまうことを防止することができる。
【０１２０】
次に第２の実施形態における受信結果レポートおよび受信画像の出力例を説明する。
【０１２１】
図１０は、第２の実施形態のインターネットファクシミリ装置において、受信電子メール１件ごとに出力される受信結果レポートの出力例を示す図である。同図の例では、ＭＤＮ要求が付された受信電子メールに対する受信結果レポートの出力例を示している。通信管理番号２−２に対応する「受付番号」（１００１）、及び、送信元の電子メールアドレスを示す「相手のアドレス」（１００２）とともに、通信結果の欄にてＭＤＮ要求が付されていたことを示す「既読確認要求有り」（１００３）が印字されている。
【０１２２】
この１００３の表示により受信者は、その受信画像が添付されていた電子メールにＭＤＮ要求が付されていたことを認知することが可能となる。
【０１２３】
図１１は、第２の実施形態のインターネットファクシミリ装置における受信電子メールに添付されていた画像の出力例を示す図である。同図の例では、ＭＤＮ要求が付された受信電子メールに添付されていた画像の出力例を示している。そのヘッダ部には、送信元の電子メールアドレス１１０１とともに、ＭＤＮ要求が付されていたことを示す情報１１０２が印字されている。
【０１２４】
この１１０２の表示により受信者は、その受信画像が添付されていた電子メールにＭＤＮ要求が付されていたことを認知することが可能となる。
【０１２５】
一方、ＭＤＮ要求が付されていない受信電子メールに添付されていた画像を出力する場合には１１０２のエリアは空欄となる。
【０１２６】
尚、図１１に示した例ではヘッダ部に既読確認有りを示す情報を印字するようにしたが、これをフッタ部に印字してもよいし、既読確認の有無が判別可能であれば、その他の態様で表示してもよい。
【０１２７】
次に、ユーザが出力された受信結果レポートや受信画像により既読確認要求を認知して、その既読確認に対する応答を行う動作を説明する。
【０１２８】
第２の実施形態のインターネットファクシミリ装置の傍を通りかかったユーザは、ステップＳ９−９で表示されたＬＣＤまたはＬＥＤの状態からＭＤＮ要求付きの電子メールが受信されたことを認知する。
【０１２９】
また、ステップＳ９−６で出力された受信結果レポート、または、ステップＳ９−１０で出力された受信画像を手にしたユーザは、そこに付されたＭＤＮ要求有りを有りを示す情報から、ＭＤＮ要求があったことを認知する。
【０１３０】
そして、ＭＤＮ要求があったことを認知したユーザは、操作部１−２のボタンにより所定の操作を行うことにより、ステップＳ９−８で示した処理によりＭＤＮ返信メールを送信する。
【０１３１】
その際、“送信者が既読確認を要求しています。返信メールを出しますか、ＹＥＳ／ＮＯ”と表示し、既読確認をするＹＥＳを選択した場合は、既読確認用の返信メールを送信するようにしてもよい。
【０１３２】
このように第２の実施形態によれば、既読確認（ＭＤＮ）を要求した電子メールを受信したとき、その旨をＬＥＤ／ＬＣＤ表示、アラーム、レポー、更には出力した受信受信などで示すことにより、既読確認の操作をユーザに促すことが可能になる。
【０１３３】
尚、図１で示したインターネットファクシミリ装置の構成に、ＬＡＮ１−１１上のＷｅｂクライアントに対して各種データを公開するためのＷｅｂサーバ機能を持たせ、通信管理情報や受信画像をＸＭＬ或いはＨＴＭＬ形式に変換してＷｅｂサーバ機能によりＬＡＮ１−１１上のユーザに公開するような形態にしてもよい。
【０１３４】
＜第３の実施形態＞
第３の実施形態として、上記第２の実施形態のインターネットファクシミリ装置に、受信した電子メールに対する既読確認電子メールを送信済みか否かの情報をユーザに通知する手段を更に設けた実施形態を説明する。
【０１３５】
上記第２の実施形態で説明したように、通信管理情報２−１の受信電子メールのＭＤＮステータスには、既読確認要求の有無を示す情報、および、既読確認要求に対する応答電子メールを送信済みであることを示す情報が、各受信電子メールごとにセットされている。
【０１３６】
したがって、受信電子メールに対応するＭＤＮステータス２−１１を読み出すことにより、その受信電子メールに対する既読確認要求の有無、および、既読確認要求に対する応答電子メールの送信の有無を判別することが可能となる。
【０１３７】
図１６は、受信電子メールに添付された画像ファイルを管理する方式を示した模式図である。画像管理情報１６０１は画像ファイル１６０３の格納先情報、送信元の情報（電子メールアドレス等）、受信時刻情報、添付されていた電子メールのメッセージＩＤ、更には画像ファイルのフォーマットに関する情報等が記憶されている。画像ファイルを出力する際は、この画像管理情報から必要な情報を読み出し、画像の出力制御を行う。
【０１３８】
また、画像管理情報１６０１に記憶されている電子メールのメッセージＩＤ等から、画像ファイルが添付されていた受信電子メールの通信管理情報１６０２を特定することも可能である。したがって、画像ファイルから特定された通信管理情報のＭＤＮステータス２−１２を読み出すことにより、当該画像ファイルが添付されていた電子メールに対する既読確認要求の有無、および、既読確認要求に対する応答電子メールの送信の有無を判別することが可能となる。
【０１３９】
図１５に第３の実施形態のインターネットファクシミリ装置の添付画像ファイルの出力動作を示すフローチャートを示す。
【０１４０】
まず、ステップＳ１５０１では、出力対象の画像ファイルが添付されていた受信電子メールに対応する通信管理情報を特定し、特定された通信管理情報のＭＤＮステータス２−１１を読み出す。
【０１４１】
ステップＳ１５０２、および、ステップＳ１５０４では、ステップＳ１５０１で読み出したＭＤＮステータス２−１１の値を評価する。
【０１４２】
ステップＳ１５０２が肯定判断、すなわち、受信電子メールに対するＭＤＮ要求がなければ、ステップＳ１５０３に進み、既読確認に関するマークを付加せずに画像ファイルを出力する。
【０１４３】
ステップＳ１５０４が肯定判断、すなわち、受信電子メールに対するＭＤＮ要求があり、かつその要求に対してＭＤＮ応答電子メールを送信済みならば、ステップＳ１５０５に進む。ステップＳ１５０２では、図１３に示すようにＭＤＮ応答電子メールを送信済みであることを示すマーク１３０１を付加して画像ファイルを出力する。
【０１４４】
ステップＳ１５０４が否定判断、すなわち、受信電子メールに対するＭＤＮ要求があり、かつその要求に対してＭＤＮ応答電子メールをまだ送信していない場合には、その旨を示すマークを付加して画像ファイルを出力する。
【０１４５】
以上が、第３の実施形態のインターネットファクシミリ装置の添付画像ファイルの出力動作である。
【０１４６】
このようにＭＤＮ要求の有無、および、ＭＤＮ要求に対する応答の有無が画像ファイルの出力画像に付加されるので、出力画像を見たユーザは既読確認行動をとるべきか否かを把握することが容易となる。
【０１４７】
また、上記実施形態で説明したように通信管理情報２−１の受信電子メールのＭＤＮステータスには、既読確認要求の有無を示す情報、および、既読確認要求に対する応答電子メールを送信済みであることを示す情報が、各受信電子メールごとにセットされている。
【０１４８】
したがって、通信管理レポートを出力する際に、受信電子メールについて既読確認要求に関する情報を付加するようにしておもよい。
【０１４９】
図１４は、第３の実施形態の通信管理レポートの出力例を示した図である。同図の例によれば、Ｎｏ．５００２の受信電子メールについてはその通信モードの欄に「ＭＤＮ未」を表示することにより、既読確認要求が付加されていたが未だ応答していないことを示している。Ｎｏ．５００３の受信電子メールについてはその通信モードの欄に「ＭＤＮ済」を表示することにより、既読確認要求が付加されていて、既に応答済みであることを示している。Ｎｏ．５００５の受信電子メールについては、その通信モードの欄に「ＭＤＮ無」を表示することにより、既読確認要求が付加されていないことを示している。
【０１５０】
このように、複数の受信電子メールについて既読確認要求の有無および既読確認要求の応答の有無を一覧リストとして出力することにより、既読確認の漏れをチェックすることが可能となる。
【０１５１】
＜他の実施形態＞
上記第１の実施形態のインタネットファクシミリ装置が有する機能と上記第２の実施形態のインタネットファクシミリ装置が有する機能は１の装置で実現されてもよいことは言うまでもない。
【０１５２】
上記実施形態では、インタネットファクシミリ装置という１つの機器について説明したが、コンピュータ装置、スキャナ装置、プリンタ装置等の複数の機器から構成される画像通信システムに対しても本発明は適用される。
【０１５３】
また、本実施の形態で説明した機能を実現するためのプログラムは、ＲＯＭ１−５に格納されているが、この機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のＣＰＵが記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることはいうまでもない。
【０１５４】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０１５５】
また、ＣＰＵが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはいうまでもない。
【０１５６】
さらに、記憶媒体から読出されたプログラムコードが、装置に挿入された機能拡張ボードや装置に接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはいうまでもない。
【図面の簡単な説明】
【０１５７】
【図１】本発明の実施形態におけるインターネットファクシミリ装置の構成を示すブロック図
【図２】第１の実施形態におけるファクシミリの通信管理情報のデータ構成を示す図
【図３】第１の実施形態のインターネットファクシミリ装置における電子メール送信処理を示すフローチャート
【図４】第１の実施形態のインターネットファクシミリ装置における受信電子メールの処理を示すフローチャート
【図５】第１の実施形態のインターネットファクシミリ装置における受信したＭＤＮの解析処理を示すフローチャート
【図６】第１の実施形態のインターネットファクシミリ装置の通信管理レポートの出力例を示す図
【図７】第１の実施形態のインターネットファクシミリ装置の送信結果レポートの出力例を示す図
【図８】第１の実施形態のインターネットファクシミリ装置の送信結果レポートの出力例を示す図
【図９】第２の実施形態のインターネットファクシミリ装置における既読確認の要求ヘッダ有りで電子メールを受信した時の動作を示すフローチャート
【図１０】第２の実施形態のインターネットファクシミリ装置の受信結果レポートの出力例を示す図
【図１１】第２の実施形態のインターネットファクシミリ装置の受信画像の出力例を示す図
【図１２】第２の実施形態のインターネットファクシミリ装置における既読確認の要求ヘッダ有りで電子メールを受信した時の動作を示すフローチャート
【図１３】第３の実施形態のインターネットファクシミリ装置の受信画像の出力例を示す図
【図１４】第３の実施形態のインターネットファクシミリ装置の通信管理レポートの出力例を示す図
【図１５】第３の実施形態のインターネットファクシミリ装置の添付画像ファイルの出力動作を示すフローチャート
【図１６】受信電子メールに添付された画像ファイルを管理する方式を示した模式図
【符号の説明】
【０１５８】
１−１ ＣＰＵ
１−２ 操作部
１−３ 読取部
１−４ 記録部
１−５ ＲＯＭ
１−６ ＲＡＭ
１−７ ＭＯＤＥＭ
１−８ ＮＣＵ
１−９ ＬＡＮ
１−１１ ＬＡＮ（インターネット）
１−１２ メールサーバ
【出願人】 【識別番号】０００００１００７
【氏名又は名称】キヤノン株式会社
【出願日】 平成１９年８月２３日（２００７．８．２３）
【代理人】 【識別番号】１０００９０５３８
【弁理士】
【氏名又は名称】西山 恵三

【識別番号】１０００９６９６５
【弁理士】
【氏名又は名称】内尾 裕一
【公開番号】 特開２００８−１７５１２（Ｐ２００８−１７５１２Ａ）
【公開日】 平成２０年１月２４日（２００８．１．２４）
【出願番号】 特願２００７−２１７０２２（Ｐ２００７−２１７０２２）