(57)【特許請求の範囲】
【請求項１】
電子メールの送受信が可能であって、電子メールに添付されている画像データを出力可能なインターネットファクシミリ装置において、
受信した電子メールにＭＤＮによる失敗時の受信確認リクエストが含まれている場合、該電子メールが正常受信しても、画像データのデコードが失敗した場合には受信失敗として確認メールを送信するとともに、前記確認メールには、画像データを受信したままの状態で添付する一方、前記電子メールを正常受信し、かつ、画像データのデコードが成功した場合には受信成功として確認メールを送信するとともに、前記確認メールには、受信した画像データの１ページ目を添付し、
受信した電子メールがＭＤＮによる受信確認失敗の確認メールであった場合は、当該電子メールに添付されている画像データの１枚目を取り出して送信結果レポートとして出力し、
受信した電子メールがＭＤＮによる受信確認成功の確認メールであった場合は、電子メールに添付されている画像データを送信結果レポートとして出力することを特徴としたインターネットファクシミリ装置。
【請求項２】
電子メールの送受信が可能であって、電子メールに添付されている画像データを出力可能なインターネットファクシミリ装置の制御方法において、
受信した電子メールにＭＤＮによる失敗時の受信確認リクエストが含まれている場合、該電子メールが正常受信しても、画像データのデコードが失敗した場合には受信失敗として確認メールを送信するとともに、前記確認メールには、画像データを受信したままの状態で添付する一方、前記電子メールを正常受信し、かつ、画像データのデコードが成功した場合には受信成功として確認メールを送信するとともに、前記確認メールには、受信した画像データの１ページ目を添付し、
受信した電子メールがＭＤＮによる受信確認失敗の確認メールであった場合は、当該電子メールに添付されている画像データの１枚目を取り出して送信結果レポートとして出力し、
受信した電子メールがＭＤＮによる受信確認成功の確認メールであった場合は、電子メールに添付されている画像データを送信結果レポートとして出力することを特徴としたインターネットファクシミリ装置の制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電子メールの送受信が可能であって、電子メールに添付されている画像データを出力可能なインターネットファクシミリ装置およびその制御方法に関する。
【０００２】
【従来の技術】
インターネットの普及により、ファクシミリ通信を行う際、網として、従来のようなＰＳＴＮやＩＳＤＮだけを用いるのでなく、インターネットを用いるサービス（インターネットファクス）も徐々に広まりつつある。これはインターネットを用いることによる料金削減のメリットをいかそうとするものである。
画像データをメールとして送る方式は、Store and Forward型インターネットファクス（Ｓ＆Ｆ  ｉｆａｘ）として、ＲＦＣ２３０５／２５３２やＴ.３７などにて標準化されており、対応製品も増加している。
【０００３】
【発明が解決しようとする課題】
メール型の画像通信にて、送信側が受信側に対して、メールによる受信確認応答を要求することがある。受信側は、受信確認をサポートしていれば、要求されると、何らかの確認メールを作成して、送信側に応答を返す。メール型では、送信側は、リアルタイムに、受信側からの確認応答を受け取ることはできない。そのため、送信側は、受信側からの確認応答を受け取った時に、どの通信に対する確認応答かを判断することが容易ではない。そこで、受信側は、送信側から送られてきた画像データの１ページ目を、受信結果とともに、確認応答メールに送り返し、送信側では、その結果とともに、第１ページを、通信に対する結果レポートとして出力し、送信者（ユーザ）は、それを目で見ることにより、どの通信に対する確認応答かを判断することができるようにすることを目的とする。
【０００４】
受信側では、受けた画像がデコードできない場合、例えば、１ページ目だけを取り出すことが保証されない。そのような場合は、受信側は受けたメールをそのまま（全ページ）返し、送信側で１ページだけ取りだし、結果（デコード不可）とともに、第１ページを通信に対する結果レポートとして出力することを目的とする。
【０００５】
インターネット上の電子メールでの受信確認を行う１つの方法として、ＲＦＣ２２９８で規定されているＭＤＮ（Message  Disposition  Notification）がある。メール送信についてはＳＭＴＰを用い、メール受信についてはＰＯＰ３またはＩＭＡＰ４といったメール取得プロトコルを用い、受信確認として、ＭＤＮを用いるとを目的とする。
【００１１】
【課題を解決するための手段】
本発明は、電子メールの送受信が可能であって、電子メールに添付されている画像データを出力可能なインターネットファクシミリ装置において、受信した電子メールにＭＤＮによる失敗時の受信確認リクエストが含まれている場合、該電子メールが正常受信しても、画像データのデコードが失敗した場合には受信失敗として確認メールを送信するとともに、前記確認メールには、画像データを受信したままの状態で添付する一方、前記電子メールを正常受信し、かつ、画像データのデコードが成功した場合には受信成功として確認メールを送信するとともに、前記確認メールには、受信した画像データの１ページ目を添付し、受信した電子メールがＭＤＮによる受信確認失敗の確認メールであった場合は、当該電子メールに添付されている画像データの１枚目を取り出して送信結果レポートとして出力し、受信した電子メールがＭＤＮによる受信確認成功の確認メールであった場合は、電子メールに添付されている画像データを送信結果レポートとして出力するようにしたものである。
【００１２】
また、電子メールの送受信が可能であって、電子メールに添付されている画像データを出力可能なインターネットファクシミリ装置の制御方法において、受信した電子メールにＭＤＮによる失敗時の受信確認リクエストが含まれている場合、該電子メールが正常受信しても、画像データのデコードが失敗した場合には受信失敗として確認メールを送信するとともに、前記確認メールには、画像データを受信したままの状態で添付する一方、前記電子メールを正常受信し、かつ、画像データのデコードが成功した場合には受信成功として確認メールを送信するとともに、前記確認メールには、受信した画像データの１ページ目を添付し、受信した電子メールがＭＤＮによる受信確認失敗の確認メールであった場合は、当該電子メールに添付されている画像データの１枚目を取り出して送信結果レポートとして出力し、受信した電子メールがＭＤＮによる受信確認成功の確認メールであった場合は、電子メールに添付されている画像データを送信結果レポートとして出力するようにしたものである。
【００２０】
【発明の実施の形態】
図１は、本発明における端末の内部構成例を示す図で、ＲＯＭ２やＲＡＭ３上のプログラムにてシステムの制御を行うＣＰＵ１、時間を制御するタイマ制御部４、図示しない操作部とのインターフェースをとるオペポートＩ／Ｆ部５、図示しないハードディスクとインターフェースするハードディスクＩ／Ｆ部６、ファクシミリ通信を制御する通信制御部７、ＧＳＴＮと電気的インターフェースをとる網制御部８、画像情報の圧縮、伸長を行う符号化・復号化部９、図示しないスキャナとインターフェースをとるスキャナＩ／Ｆ部１０、図示しないプロッタ部とインターフェースをとるプロッタＩ／Ｆ部１１、電源ＯＦＦ状態でも情報を保持するＳＲＡＭ１４、文字のフォント情報を保持するキャラクタジェネレータ１２等に加えて、ＬＡＮ通信制御部１３が装着されている。ＬＡＮ通信制御部１３は物理層としてＥｔｈｅｒｎｅｔに対応し、ＣＰＵ１、本発明におけるプログラムやデータが格納されているＲＯＭ２，ＲＡＭ３，ＳＲＡＭ１４とともに、ＬＡＮプロトコル（ＳＭＴＰ／ＰＯＰ３／ＩＭＡＰ４／ＴＣＰ／ＵＤＰ／ＩＰなど）を制御している。ＧＳＴＮファクシミリ通信を行わない場合、端末には通信制御部７及び網制御部８は存在しない。インターネット上の文書送信は、メールの転送プロトコルであるＳＭＴＰを用いている。
【００２１】
図２に、ＳＭＴＰシーケンス例を示す。ＭＤＮによるメールの受信確認要求は、メールのヘッダ中に次のように記述することにより行われる。Disposition-Notification-To:tamura@maple.kei.co.jp受信確認はメールにより行われ、このヘッダで指定されたアドレスに、受信確認メッセージが返信される。
【００２２】
図３は、ＭＤＮによる受信確認メッセージの例であり、
Disposition:manual-action/MDN-sent-manually;displayed
により、受信成功確認がされている。“displayed”の代わりに、“dispatched”が用いられることもある。第１パートのコメント部には、第３パートに第１ページのみ添付されていることが表示されており、第２パートには、X-attached-partsというフィールドにより、第３パートに第１ページのみ添付されていることがわかる。
なお、ここでは、Ｘフィールドいう自由に用いることができるフィールドにより表現されているが、ＩＡＮＡ（Internet  Assigned  Numbers  Authority）により登録された正式のフィールドの可能性もある。また、ここで用いたＸフィールドの名称は一例であり、他の名称の可能性もある。
【００２３】
図４は、失敗時の確認メッセージの例であり、
Disposition:manual-action/MDN-sent-manually;processed/error
により、受信失敗確認がされている。第１パートのコメント部には、第３パートに全メッセージが添付されていることが表示されており、第２パートには、X-attached-partsというフィールドにより、第３パートに全メッセージが添付されていることがわかる。ＤＳＮによるメールの受信確認リクエストは、ＳＭＴＰのコマンドレベルで行われる。図２はＳＭＴＰのシーケンス例である。ＥＨＬＯコマンドに対して、２５０−ＤＳＮレスポンスにより、メールサーバがＤＳＮをサポートしていることがわかる。確認のリクエストは、送信宛先を指定するコマンド
RCPT  TO:    NOTIFY=SUCCESS
などにより指定する。この例は、成功時の受信確認を要求している。
RCPT  TO:    NOTIFY=FAILURE
この例は、失敗時の配達確認を要求している。
また、次のように両者を指定することもできる。
RCPT  TO:NOTIFY=SUCCESS,FAILURE
受信確認はメールにより行われ、“MAIL  FROM:”で指定されたアドレスに返信される。
【００２４】
図５は、成功時の受信確認メッセージの例であり、
Action:  delivered
により、受信成功成功が確認されている。第１パートのコメント部には、第３パートに第１ページのみ添付されていることが表示されており、第２パートには、X-attached-partsというフィールドにより、第３パートに第１ページのみ添付されていることがわかる。
【００２５】
図６は、失敗時の受信確認メッセージの例であり、
Action:  failed
により、受信確認失敗が確認されている。第１パートのコメント部には、第３パートに全メッセージが添付されていることが表示されており、第２パートには、X-attached-partsというフィールドにより、第３パートに全メッセージが添付されていることがわかる。
【００２６】
また、送信側が、受信確認応答として、指定ページ数だけ送り返すように要求するヘッダをメール内にもうける場合、送信メール内に、例えば、次のようなヘッダを設けることにより行われる。
X-request-for-notification:  1st  page  returned
“1st  page  returned”により、第１ページだけを要求するが、他のパラメータ値の指定も可能である。ここでは、Ｘフィールドいう自由に用いることができるフィールドにより表現されているが、ＩＡＮＡにより登録された正式のフィールドの可能性もある。また、ここで用いたＸフィールドの名称は一例であり、他の名称の可能性もある。
【００２７】
また、送信側が、受信確認応答として、指定ページ数だけ送り返すように要求するＳＭＴＰコマンドを用いる場合、ＳＭＴＰコマンドレベルで、指定ページ数だけ送り返す指定を行う。例えば、次のように指定ができる。
MAIL  FROM:    NOTIFY=SUCCESS  RET=1ST
ただし、“1st”というキーワードは、まだ標準化されていない。これは、標準化後に実現可能である。非標準シーケンスとして、例えば、ＥＨＬＯコマンドに対する応答として、“250-RICOHNONSTANDARD”のようなものを返すことにより、送信側と受信側とが、お互いに非標準機能をサポートしていることを知った後に、上記の“MAIL  FROM”コマンドのオプションとして、“RET=1st”を用いることにより、実現できる。
【００２８】
図７は、受信側の画像メール受信時の動作フロー例である。画像データメールを受信すると（Ｓ１）、デコード可能かチェックする（Ｓ２）。可能の場合、紙による出力や画面表示、通信情報データの更新といった正常受信時の所定の動作を行い（Ｓ３）、受信確認要求されているかどうかチェックする（Ｓ４）。要求されている場合は、第３ページへ指定さているページをセットするか（Ｓ５）、第１ページのみをセットし、ＭＤＮまたはＤＳＮを作成し（Ｓ６）、確認メールを送信側に送り返す（Ｓ７）。デコード不可の場合、紙によるエラー発生の出力や画面表示、通信情報データの更新といったエラー受信時の所定の動作を行い（Ｓ８）、受信確認要求されているかどうかチェックする（Ｓ９）。要求されている場合は、全受信メールを第３パートにセットし（Ｓ１０）、ＭＤＮまたはＤＳＮを作成し（Ｓ６）、確認メールを送信側に送り返す（Ｓ７）。
【００２９】
図８は、送信側の確認メール受信時の動作フロー例である。確認メールを受信すると（Ｓ１１）、通信情報データの更新といった所定の動作を行い（Ｓ１２）、画像データを第１ページのみ取り出し（Ｓ１３）、そのページと確認メールの他のフィールド情報とを結果レポートに埋め込み、出力する（Ｓ１４）。
【００３０】
【発明の効果】
インターネットに接続可能で、メール送信に関してはＳＭＴＰをサポートし、メール受信に関してはＳＭＴＰによる直接受信またはＰＯＰ３またはＩＭＡＰ４などのメール取得プロトコルをサポートする端末において、スキャナなどから読みこまれた画像データをメールとして受信し、送信側からのメールによる受信確認応答を要求され、受信確認を返信する際に、確認の結果とともに、送信側から送られてきた画像データの１ページ目を、受信側は受信確認応答として送り返し、送信側では、その結果とともに、第１ページを、通信に対する結果レポートとして出力するので、送信者（ユーザ）は、それを目で見ることにより、どの通信に対する確認応答かを判断することができ、送信側端末は、通信ごとに、確認のための画像データを保存しておく必要がなくなる。また、受信側が、全（複数）ページ送り返してきたとしても、送信側で第１ページだけを取り出して、結果レポートを作成し出力するので、同様の効果が得られる。
【００３１】
受信側では、受けた画像がデコードできない場合、例えば、１ページ目だけを取り出すことが保証されないので、受信側は受けたメールをそのまま（全ページ）返し、送信側で１ページだけ取りだし、結果（デコード不可）とともに、第１ページを通信に対する結果レポートとして出力するので、送信者（ユーザ）は、それを目で見ることにより、どの通信に対する確認応答かを判断することができ、送信側端末は、通信ごとに、確認のための画像データを保存しておく必要がなくなる。
【００３２】
ＭＤＮやＤＳＮを用いて受信確認応答をする場合、第３パートに添付されているページ数を第１パートにテキスト情報として入れ込むことにより、添付ページ数を送信者（ユーザ）に目で伝えることができる。
【００３３】
ＭＤＮやＤＳＮを用いて受信確認応答をする場合、第３パートに添付されているページ数を第２パートにフィールド情報として入れ込むことにより、添付ページ数を端末に正しく伝えることができる。
【００３４】
送信側が、受信確認応答として、指定ページ数だけ送り返すように要求するヘッダをメール内にもうけて、画像を送ることにより、受信側がそのヘッダを理解できれば、確実に応答メールに指定ページ数だけを添付することができる。
【００３５】
送信側が、受信確認応答として、指定ページ数だけ送り返すように要求するＳＭＴＰコマンドを用いることにより、受信側がそのコマンドを理解できれば、確実に応答メールに指定ページ数だけを添付することができる。
【図面の簡単な説明】
【図１】  本発明による端末装置の内部構成例を示す図である。
【図２】  ＳＭＴＰ基本シーケンスの一例を示す図である。
【図３】  ＭＤＮの受信確認メッセージの例を示す図である。
【図４】  ＭＤＮの受信確認メッセージprocessed/errorの例を示す図である。
【図５】  ＤＳＮの受信確認メッセージdeliveredの例を示す図である。
【図６】  ＤＳＮの受信確認メッセージfailedの例を示す図である。
【図７】  受信側の画像メール受信時の動作フローを示す図である。
【図８】  送信側の確認メール受信時の動作フローを示す図である。
【符号の説明】
１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ、４…タイマ制御部、５…オペポートＩ／Ｆ部、６…ハードディスクＩ／Ｆ部、７…通信制御部、８…網制御部、９…符号化・復号化部、１０…スキャナＩ／Ｆ部、１１…プロッタＩ／Ｆ部、１２…キャラクタジェネレータ、１３…ＬＡＮ通信制御部、１４…ＳＲＡＭ。
【図１】
0004060535.tif 000002
【図２】
0004060535.tif 000003
【図３】
0004060535.tif 000004
【図４】
0004060535.tif 000005
【図５】
0004060535.tif 000006
【図６】
0004060535.tif 000007
【図７】
0004060535.tif 000008
【図８】
0004060535.tif 000009