JP2004179763A

JP2004179763A - 通信装置及び通信方法

Info

Publication number: JP2004179763A
Application number: JP2002341085A
Authority: JP
Inventors: Tetsuya Shibata; 哲也柴田; Takeshi Nakamura; 武志中村
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2002-11-25
Filing date: 2002-11-25
Publication date: 2004-06-24

Abstract

【課題】電子メールで画像データを送信するにあたって、相手側装置の受信能力を予め確認しておき、それに基づいた画像データを送信することで、相手側装置が画像データを良好に受信できるようにする。
【解決手段】画像データを添付ファイルとする電子メールを相手側装置に送信する際、ＭＤＮ機能を利用して、相手側装置が受信可能なファイル形式や圧縮形式を問い合わせるための能力通知要求メールを送信する。相手側装置から能力通知メールが返信された後、その能力に応じて画像データのファイル形式や圧縮形式を変換した後、この相手側装置に対して電子メールを送信する。
【選択図】図５

Description

【０００１】
【発明の属する技術分野】
本発明は、例えばインターネットファクシミリ装置等に代表される通信装置及びその通信装置によって実行される通信方法に係る。特に、本発明は、データ送信先の装置（相手側装置）が画像データを良好に受信できるようにするための手法の改良に関する。
【０００２】
【従来の技術】
近年、通信機器のネットワーク化の進展に伴い、インターネット等のネットワークを介して電子メール（Ｅ−ｍａｉｌ）を送受信するネットワーク通信装置が種々の用途に用いられるようになってきている。
【０００３】
そして、スキャナ機能を備え、読取った画像情報を電子メールの添付ファイルとして、ネットワークに接続されたコンピュータ等の装置へ送信することのできるネットワーク通信装置も開発されている。
【０００４】
このような装置の一例として、ＳｃａｎｔｏＥｍａｉｌという機能を備えたネットワークスキャナ装置（ネットワーク通信装置）が開発されている。これは、スキャンした原稿画像データを所定のフォーマットデータに変換して電子メール用の添付ファイルを作成し、電子メールと共にその添付ファイルをインターネット上の所定のアドレス（ホストコンピュータ）に送信するものである。
【０００５】
また、上記スキャナ機能に加えて、さらに印刷機能や電話機能をも備えた、ファクシミリ／電子メール装置も開発されている。
【０００６】
このファクシミリ／電子メール装置を利用したネットワークの概略構成を図１に示す。この図１に示すように、本ネットワークは、各ファクシミリ／電子メール装置１，５がそれぞれメールサーバ装置２，４に接続されて個別のＬＡＮを構築しており、各ＬＡＮ同士の間、つまり、各ファクシミリ／電子メール装置１，５の相互間で画像データ等の各種データや電子メールの送受信が可能な構成となっている。
【０００７】
具体的に、電子メールの送信形態について説明すると、送信側端末となるファクシミリ／電子メール装置１から送信側のメールサーバ装置２に投函された電子メールは、ＳＭＴＰ（ＳｉｍｐｌｅＭａｉｌＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）等の所定の電子メール転送プロトコルでネットワーク（インターネット）３を介して受信側のメールサーバ装置４に転送され、その受信側のメールサーバ装置４に蓄積される。受信側端末となるファクシミリ／電子メール装置５は、定期的に上記受信側のメールサーバ装置４に、ＰＯＰ３プロトコル（ＰｏｓｔＯｆｆｉｃｅｐｒｏｔｏｃｏｌ３）、ＩＭＡＰ（ＩｎｔｅｒｎｅｔＭｅｓｓａｇｅＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）等のメール受信プロトコルを用いてアクセスして、蓄積されている電子メールを取得する。
【０００８】
また、この受信側のファクシミリ／電子メール装置５にあっては、電子メールを受信し、添付されている画像情報を受信原稿として記録出力した際には、この電子メール及び添付画像情報が重複して再転送されないように、受信した電子メールをメールサーバ装置４上から削除するように構成されている。
【０００９】
ここで、上述のようにネットワークファクシミリとして電子メールを用いて情報の送信をする場合には、たとえば通常のファクシミリ装置で情報を送信する場合とは異なり、受信側において正常に受信されたかどうか、または受信側において処理が適切になされたかどうかが、送信側において判別できないという問題があった。
【００１０】
すなわち、ＰＳＴＮ（ＰｕｂｌｉｃＳｗｉｔｃｈｅｄＴｅｌｅｐｈｏｎｅＮｅｔｗｏｒｋ：公衆電話網）を介して互いにリアルタイムで通信を行う通常のファクシミリ装置とは異なり、ネットワークファクシミリでは、上記受信側端末５が常時メールサーバ装置４に接続されているとは限らないために、受信側の受信状況を送信側において判別できない。
【００１１】
また、受信側端末５が受信不能であっても、送信側端末１からメールサーバ装置２への送信は可能であるので、送信の時点では、前述のように正常に受信できたか、また適切に処理されたかなどについて、送信側で認識することはできない。
【００１２】
そのため、従来では、上記ファクシミリ／電子メール装置から送信した情報の送達の確認を行う必要がある場合には、結局、操作者が電話によって相手側に確認しなければならないという不便さがあった。このため、互いにリアルタイムで対話をする必要がないという電子メール特有の通信の利点が損なわれてしまうという課題があった。
【００１３】
そこで、このような不具合を解消するための技術として、電子メールを受信した場合に、受信側端末が送達確認の応答を送信側に返信することによって送達確認を行う方法が、ＲＦＣ２２９８で規定されるＭＤＮ（ＭｅｓｓａｇｅＤｉｓｐｏｓｉｔｉｏｎＮｏｔｉｆｉｃａｔｉｏｎ）の方法により実現されている。
【００１４】
これは、送信メールの受信側における受信結果／経過を、所定形式の送達確認メールにより送信元に通知して確認させる方法である。
【００１５】
ここで、ＲＦＣ（ＲｅｑｕｅｓｔＦｏｒＣｏｍｍｅｎｔ）とは、インターネットに関する技術の標準を定める団体であるＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）が正式に発行する文書を指す。ＲＦＣとして、たとえばＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）などのインターネットで利用されるプロトコルや、その他インターネットに関わるさまざまな技術の仕様・要件などが、上記ＲＦＣ２２９８のような通し番号を付けて公開されている。
【００１６】
上記ＭＤＮにおいては、電子メールのヘッダ部に「Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏ：」フィールドを新たに設けている。送信側および受信側の端末がＭＤＮの仕様を満たしている場合には、上記フィールドを用いて送達の確認が行われる。すなわち、具体的には、送信側において、上記フィールドに送達確認メールの送付を希望するアドレスを指定して送信し、受信側において、上記フィールドで指定されるアドレスに送達確認メールを返信する。
【００１７】
ところで、インターネットを使用したファクシミリ通信（以下、インターネットＦＡＸと呼ぶ）には、ＥメールでＴＩＦＦファイルを送受信するＳｉｍｐｌｅＭｏｄｅと、このＳｉｍｐｌｅＭｏｄｅの機能に加えて送信機と受信機の間で機能の通知を行う能力交換および画像データの到達確認ができるＦｕｌｌＭｏｄｅと、ＴＣＰパケットでリアルタイムにパケットの送受信を行うＲｅａｌＴｉｍｅＭｏｄｅとがある。
【００１８】
しかし、インターネットＦＡＸのモードはそれぞれのモードに固有の制限がある。
【００１９】
例えば、上記ＳｉｍｐｌｅＭｏｄｅは、送信できる画像がＡ４サイズ、２００ＤＰＩ、ＭＨに制限されてしまう。
【００２０】
一方、ＦｕｌｌＭｏｄｅは、送信できる画像に制限は無いが、受信側がＦｕｌｌＭｏｄｅに対応していない場合には、この受信側において画像データを開けることができないおそれがあるため、実際に送信する前に相手機（受信側）の能力を別の手段で取得しておく必要がある。
【００２１】
これまでの技術では、例えば、受信機がＦＡＸ機能として、記録解像度４００ＤＰＩ、Ｂ４サイズの記録紙が使用可能であること、カラー受信機能を持つことなどについて、送信機側では知ることができなかったために、送信側で原稿が４００ＤＰＩ、Ｂ４サイズ、カラーで読取られたとしても、読取った画像データを２００ＤＰＩ、Ａ４サイズに変換（ＳｉｍｐｌｅＭｏｄｅへ変換）してからでないと送信出来ないといった不具合があった。
【００２２】
このような、従来の課題を解決する方法として、下記の特許文献１に開示されているように、送信機で受信機の能力通知要求をＳＭＴＰで送信し、受信機が能力通知をＳＭＴＰで応答することにより、送信機で最適な画像をＳＭＴＰで送信する方法が開示されている。
【００２３】
【特許文献１】
特開平１１−２６１６２８号公報
【００２４】
【発明が解決しようとする課題】
しかし、上述した特許文献１に開示されている技術においては、ＭＤＮの能力通知時に、特殊コマンドを用いてＴ．３０のＤＩＳ情報を通知することで、能力確認を行っている。そして、ＤＩＳ情報には、インターネットＦＡＸ特有の情報（ＴＩＦＦファイル形式や、符号混在情報（ＭＲＣ）等の情報）が含まれていないと言う問題点がある。
【００２５】
また、ＤＩＳの情報は、多くの情報を少ないｂｉｔを複数使用して表している点と、ファクシミリ機能が向上する度にｂｉｔを末尾に追加して行っているため、通常の電子メールの情報を解析するのに比べて、処理が煩雑になると言う問題点もある。
【００２６】
本発明は、かかる点に鑑みてなされたものであり、その目的とするところは、電子メールで画像データを送信するにあたって、相手側装置の受信能力を予め確認しておき、それに基づいた画像データを送信することで、相手側装置が画像データを良好に受信できるようにすることにある。
【００２７】
【課題を解決するための手段】
−発明の概要−
上記の目的を達成するために、本発明は、先ず、画像データを送信しようとする送信先の装置（相手側装置）に対して受信能力を予め確認するための通信を行う。そして、相手側装置の応答によってその受信能力を確認し、相手側装置が受信可能な形態に画像データを変換して送信するようにしている。
【００２８】
−解決手段−
具体的には、画像データを相手側装置に向けて送信可能な通信装置を前提とする。この通信装置に対し、相手側装置の受信能力の問い合わせを行う問い合わせ手段と、この問い合わせに応じて相手側装置が発信する受信能力情報を受信する能力受信手段と、この能力受信手段により取得した相手側装置の受信能力に応じて画像データを変換し、その変換後の画像データを相手側装置に向けて送信する送信手段とを備えさせている。
【００２９】
より具体的には、本装置がＭＤＮ機能を備え、この機能によって相手側装置の受信能力を問い合わせることが掲げられる。具体構成は以下のとおりである。
【００３０】
データ圧縮処理した画像データを電子メールにより相手側装置に向けて送信可能な通信装置を前提とする。この通信装置に対し、相手側装置が受信可能なデータ圧縮形式の問い合わせを行う問い合わせ手段と、この問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する能力受信手段と、この能力受信手段により取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信手段とを備えさせている。
【００３１】
また、問い合わせ手段の機能として、相手側装置が受信可能なデータ圧縮形式の問い合わせを行うと共に、その発信情報の中に問い合わせのための発信である旨の情報を包含するようにしてもよい。
【００３２】
これらの特定事項により、先ず、画像データを送信しようとする送信先である相手側装置に対して、受信可能なデータ圧縮形式等の受信能力を予め確認するための通信を行う。そして、相手側装置の応答によってその受信能力を確認し、相手側装置が受信可能な形態に画像データを変換（相手側装置の受信可能圧縮形式での画像データの圧縮処理）してデータ送信することになる。
【００３３】
このため、送信側の通信装置にあっては、相手側装置において画像データが正常に受信されたかどうか、または受信側において処理が適切になされたかどうかを送信後に確認する必要が無くなる。つまり、この確認をしなくても、相手側装置において正常な受信及び処理が行われたことを確信できる。
【００３４】
また、上述した如く電子メールにより相手側装置に向けて画像データを送信するものに適用した場合には、リアルタイムで対話をする必要がないという電子メールによる通信の利点を損うことなしに、相手側装置において正常な受信及び処理が行われたことを送信側の通信装置において確信することができる。
【００３５】
図２は、上記解決手段の如く発信情報の中に問い合わせのための発信である旨の情報を包含させた場合と、包含させない場合との通信形態を比較するための概念図である。図２（ａ）は発信情報の中に問い合わせのための発信である旨の情報を包含させた場合の通信形態を示しており、図２（ｂ）はその情報を包含させない場合の通信形態を示している。先ず、インターネットＦＡＸデータと共に送達確認及び能力通知要求のメールが送信された場合（図２（ａ）及び（ｂ）の上から３番目の通信）、何れの通信形態においても受信データの印字及びメモリへのデータ蓄積が可能であり、また、送達確認応答及び能力通知を送信側の装置に発信することになる。
【００３６】
一方、インターネットＦＡＸデータが無い状態で、送達確認及び能力通知要求のメールを送信した場合（図２（ａ）及び（ｂ）の最上段の通信）、問い合わせのための発信である旨の情報を包含させたものでは、受信側の装置では、データが無いにも拘わらず、エラー判定は行わず、送達確認応答及び能力通知を送信側の装置に発信することになる。これに対し、問い合わせのための発信である旨の情報を包含させないものでは、データが無いためにエラー判定が行われ、受信印字の不可及びメモリへの蓄積不可となる。つまり、発信情報の中に問い合わせのための発信である旨の情報を包含させた場合の方が良好な通信状態を得ることができる。
【００３７】
また、問い合わせ手段が、相手側装置が受信可能なデータ圧縮形式の問い合わせをＲＦＣ２２９８及びＲＦＣ２８７９に基づく送達確認要求を用いて行い、能力受信手段が、上記問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する構成とした場合には、ＲＦＣで規定されている方法を用いることによって容易に通信を行うことが可能となり、本通信装置を使用した通信形態の実用性の向上を図ることができる。
【００３８】
また、相手側装置に向けて画像データを送信しようとする送信モードがシンプルモードではない場合に限って、問い合わせ手段が、相手側装置が受信可能なデータ圧縮形式の問い合わせを行うようにしている。つまり、相手側装置に向けて画像データを送信しようとする送信モードがシンプルモードである場合には相手側装置に受信能力の問い合わせを行わないようにしている。これによれば、無駄な問い合わせメールの送信による待ち時間が発生することを防止することが可能となる。何故なら、シンプルモードであれば、通常の通信装置の全てが受信可能であるため、このシンプルモードで画像データを送信する場合には相手側装置は確実に受信でき、相手側装置の受信能力を予め確認しておく必要はない。このため、上記問い合わせのメールの送信を実行する必要がない。
【００３９】
更に、予め相手側装置の受信能力情報を記憶しておくことが可能な相手側情報記憶手段を備えさせておき、画像データを送信しようとする相手側装置が上記相手側情報記憶手段に記憶されている相手側装置ではない場合に限って、問い合わせ手段が、相手側装置が受信可能なデータ圧縮形式の問い合わせを行うようにしている。つまり、画像データを送信しようとする相手側装置が上記相手側情報記憶手段に記憶されている場合には、相手側装置が受信可能なデータ圧縮形式の問い合わせを行わないようにしている。これによれば、予め記憶されている情報から相手側装置の受信能力情報を取得することができ、この情報に基づいて画像データを変換して相手側装置に向けて送信することで、この相手側装置では画像データを良好に受信することができる。この場合にも、無駄な問い合わせのメールの送信による待ち時間が発生することを防止できる。
【００４０】
上述した各解決手段において、問い合わせ手段による問い合わせが実行された後、所定時間が経過しても能力受信手段が相手側装置からの情報を受信しない場合、送信手段は、画像データを変換することなく画像データを相手側装置に向けて送信するようにしている。これによれば、受信側が、ＭＤＮの機能を備えていない場合であっても、無駄な応答待ちの状態を防ぐことが可能となる。つまり、受信側がＭＤＮの機能を備えていないために問い合わせに対する応答ができない状況であっても、所定時間の経過後には画像データを相手側装置に向けて送信することが可能となる。
【００４１】
また、予め相手側装置の受信能力情報を記憶しておくことが可能な相手側情報記憶手段を備えさせ、問い合わせ手段による問い合わせが実行された後、所定時間が経過しても能力受信手段が相手側装置からの情報を受信しない場合、画像データを送信しようとする相手側装置が相手側情報記憶手段に記憶されている相手側装置であるときには、送信手段は、その記憶情報に基づいて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信するようにしている。これによれば、電子電話帳等の管理テーブル（相手側情報記憶手段）に登録されている相手側装置の受信能力に応じた送信条件の中から最も近い条件で送信することにより、受信側の受信能力が判らない状況であっても、確実に画像データを送信することが可能となる。
【００４２】
更に、問い合わせ手段による問い合わせが実行された後、所定時間が経過しても能力受信手段が相手側装置からの情報を受信しない場合、送信手段は、シンプルモードで画像データを相手側装置に向けて送信するようにしている。
【００４３】
このようにシンプルモードで送信することにより、受信側の受信能力が判らない状況であっても、この画像データを送信することで、相手側装置にあっては確実に画像データを受信することができる。
【００４４】
また、問い合わせ手段が、問い合わせ情報の中に自己装置の受信能力情報を包含させるようにしている。これによれば、今回の通信では送信側装置及び受信側装置としてそれぞれ機能していた各通信機器が、将来的に、送受信が逆転した際、送信側装置（以前の通信では受信側となっていた装置）は受信側装置（以前の通信では送信側となっていた装置）の受信能力を既に取得していることになり、この一対の装置間では、画像データを送信する度に問い合わせを実行するといったことは必要なくなり、短時間で良好な画像データの送受信を実行することが可能となる。
【００４５】
また、上述した各解決手段に係る通信装置によって実行される通信方法も本発明の技術的思想の範疇である。つまり、相手側装置の受信能力の問い合わせを行う問い合わせ動作と、この問い合わせに応じて相手側装置が発信する受信能力情報を受信する能力受信動作と、取得した相手側装置の受信能力に応じて画像データを変換し、その変換後の画像データを相手側装置に向けて送信する送信動作とを備えた通信方法である。
【００４６】
また、相手側装置が受信可能なデータ圧縮形式の問い合わせを行う問い合わせ動作と、この問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する能力受信動作と、取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信動作とを備えた通信方法も掲げられる。
【００４７】
また、これら通信方法において、発信情報の中に問い合わせのための発信である旨の情報を包含させておく場合には問い合わせ動作中にこの情報（問い合わせのための発信である旨の情報）の書き込み動作が実行される。また、送信モードがシンプルモードである場合には問い合わせ動作は実行されない（問い合わせ非実行）。また、予め相手側装置の受信能力情報を記憶しておく場合には、この情報を記憶するための記憶動作が予め行われている。
【００４８】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００４９】
−ネットワーク通信装置の構成説明−
本実施形態に係るネットワーク通信装置は、所定の送信設定によって、ネットワークを介したデータの送信を行うものである。上記ネットワーク通信装置は、データの送信と共に、送信先へ応答を要求し、その応答の有無を確認する応答確認機能を有している。尚、このネットワーク通信装置によって構築されるネットワークは、上記図１を用いて説明したものと同様であるので、ここでの説明は省略する。また、図１における各ネットワーク通信装置１（１１），５（１１’）は共に同一構成であるので、ここでは一方のネットワーク通信装置１（１１）について代表して説明する。
【００５０】
以下、ネットワーク通信装置の構成について、図３および図４に基づいて説明する。
【００５１】
図３は、本実施形態に係るネットワーク通信装置であるファクシミリ／電子メール装置１１の電気的構成を示すブロック図である。このファクシミリ／電子メール装置１１は、データを記録媒体に印刷するプリンタ／コピーや、電話回線を利用した通常のファクシミリ（ＦＡＸ）としての機能の他に、インターネットなどのネットワークを経由して、電子メール（Ｅ−ｍａｉｌ）の送受信やサーバとファイルの送受信を行う電子メール（Ｅ−ｍａｉｌ／ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ））装置、およびインターネットファクシミリ装置としての機能を有する。インターネットファクシミリ装置としての機能については、後に詳述する。
【００５２】
このファクシミリ／電子メール装置１１は、メイン制御部１２、パネル制御部１３、制御用メモリ１４、画像用バッファ１５、制御用バッファ１６、画像記憶部１７、電子メール作成部１８、読取部１９、記録部２０、符号／復号化制御部２１、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）制御部２２、モデム２３、網制御部（ＮＣＵ：ＮｅｔｗｏｒｋＣｏｎｔｒｏｌＵｎｉｔ）２４、送達確認送受信制御部２５、時計部２６、時間管理部２７を備えて構成されている。以下、各部について説明する。
【００５３】
メイン制御部１２は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）などを備えて構成され、該ファクシミリ／電子メール装置１１の全体を統括的に制御する。パネル制御部１３は、原稿の読込み、相手先入力などの指示を行うためのものであり、詳細は後述する。
【００５４】
制御用メモリ１４は、ＲＯＭなどの不揮発性のメモリや、バックアップされた揮発性のメモリなどから成り、制御プログラムや相手先情報（送信先の電話番号、短縮番号等）が格納されているとともに、これらの制御プログラムを実行するのに必要なシステムデータや各種データが記憶されている。また、この制御用メモリ１４は、本発明でいう相手側情報記憶手段を構成するものであり、予め相手側装置の受信能力情報（相手側装置が受信可能なファイル形式や圧縮形式等）を記憶している。この記憶動作については後述する。
【００５５】
画像用バッファ１５は、ＲＡＭ等から成り、送受信される画像データの圧縮や伸長にあたっての一時記憶に使用される。制御用バッファ１６は、ＲＡＭ等から成り、制御プログラムを動作させる上で必要なデータを格納する。画像記憶部１７は、符号化された画像データを記憶するとともに、後述する読取部１９から読込んだデータ、または受信したデータ、復号化後のデータなどを記憶する。
【００５６】
電子メール作成部１８は、符号化された画像データにヘッダ情報を付加し、電子メールのフォーマットに変換する。また、この電子メール作成部１８では、必要に応じて相手側装置の受信能力の問い合わせを行う問い合わせ情報を作成して電子メールに付加するようになっている。つまり、この電子メール作成部１８は、本発明でいう問い合わせ手段を構成するものである。
【００５７】
読取部１９は、原稿読取り手段としての光電変換素子（ＣＣＤ；ＣｈａｒｇｅＣｏｕｐｌｅｄＤｅｖｉｃｅ）を利用したスキャナで、原稿を所定の解像度で読取る。そして、読取った結果、ドットイメージデータを出力する。記録部２０は、電子写真方式のプリンタ装置を備え、通信によって受信した原稿画像や読取部１９で読取った原稿画像等のデータをハードコピー（プリントアウト）する。また、サーマル素子を利用したサーマル記録装置として構成されていてもよい。
【００５８】
符号／復号化制御部２１は、読込んだ原稿画像のデータの符号化や画像データ受信時の復号化を行う。すなわち、この符号／復号化制御部２１は、読取部１９で読取った原稿画像のデータを符号化圧縮するとともに、符号化圧縮されている受信画像データを元のデータに復号化する。この符号／復号化制御部２１では、ファクシミリ通信で一般に使用されている、ＭＨ（ＭｏｄｉｆｉｅｄＨｕｆｆｍａｎ）、ＭＲ（ＭｏｄｉｆｉｅｄＲＥＡＤ）およびＭＭＲ（ＭｏｄｉｆｉｅｄＭｏｄｉｆｉｅｄＲＥＡＤ）などの符号化方式を用いることができる。
【００５９】
ＬＡＮ制御部２２は、インターネット経由による電子メールの送受信通信およびインターネットファクシミリの通信を行うように、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）と接続するためのものである。
【００６０】
モデム２３は、通常のファクシミリ通信を行うためのものであり、ファクシミリ通信が可能なファクシミリモデムから構成されている。このモデム２３は、網制御部２４を介して公衆電話回線と接続されている。網制御部２４は、アナログの公衆電話回線網（ＰＳＴＮ）との回線の閉結及び開放の回線制御動作を行うハードウェアであり、必要に応じてモデム２３を公衆電話回線網と接続する。
【００６１】
上記送達確認送受信制御部２５は、本発明でいう送信手段及び能力受信手段を構成するものであり、上記ＭＤＮ機能による送達確認（送達確認応答）の要求、および受信した送達確認応答の管理などを行い、上記電子メール作成部１８が付加する情報を用いて制御を行う。また、この送達確認送受信制御部２５は、相手側装置１１’が発信する受信可能圧縮形式情報を受信して、ＲＦＣ２２９８及びＲＦＣ２８７９の識別が可能となっている。
【００６２】
そして、送達確認送受信制御部２５は、データの送信における送信エラーを検出する機能を有していると共に、送信エラーを検出した場合にデータを再送する再送機能をも有している。
【００６３】
ここで、この送信エラーとは、後述する送達確認において、送信が正常に完了していないという結果が得られた場合に相当する。
【００６４】
さらに、送達確認送受信制御部２５は、上記のパネル制御部１３と組み合わせて、所定の送信設定を変更する設定変更機能、および送信設定を変更する際の確認をするための確認機能を有している。
【００６５】
上記時計部２６は、上記送達確認の要求（能力通知要求）を送信してから、送達確認応答を受信するまでの経過時間を計測する計測手段であり、たとえば後述するタイムアウト時間などをカウントする。上記時間管理部２７は、上記時計部２６で計測された送達確認応答を受信するまでの時間を記憶し、また後述するようにその時間に基づいて、タイムアウトエラーの判定を行う待ち時間を設定する変更手段である。
【００６６】
次に、パネル制御部１３の構成について、図４に基づいて説明する。
【００６７】
このパネル制御部１３は、表示部３１および操作部３２を備え、それらを一体としたタッチパネル型に構成される。そして、ファクシミリ送信にあたっては、相手先の設定が行われ、設定された相手先情報は、上記制御用メモリ１４に格納される。上記表示部３１は、液晶表示装置（ＬＣＤ：ＬｉｑｕｉｄＣｒｙｓｔａｌＤｉｓｐｌａｙ）やＣＲＴ（ブラウン管：ＣａｔｈｏｄｅＲａｙＴｕｂｅ）ディスプレイなどから成り、動作状態や送信先の情報など、数字や記号だけでなく、画像を表示することができる。上記操作部３２は、本ファクシミリ／電子メール装置１１に対する設定や条件または処理動作などの入力操作に必要な各種のキー（入力手段）を備えている。
【００６８】
上記操作部３２は、テンキー３３、クリアキー３４、スタートキー３５、全解除キー（ＣＡキー）３６、モード選択キー３７、およびジョブステータス表示キー３８、ユーザ設定キー３９等を備えている。また、上記表示部３１は、タッチパネルとなっており、設定などにあたって各種のキーを表示し、入力を受付けるようになっている。
【００６９】
上記テンキー３３は、画像形成枚数や部数などを入力するためのものである。上記クリアキー３４は、テンキー３３から入力された情報などをクリアするためのものである。上記スタートキー３５は、記録媒体への画像出力動作を開始するためのキーである。全解除キー３６は、設定された条件を全てクリアするためのキーである。
【００７０】
また、モード選択キー３７は、たとえばインターネットを介して受信したデータなどを出力するプリンタとしてのプリンタモード、電話回線やインターネットを介して他の装置にデータを送信するファクシミリとしてのファクシミリモード、および原稿から読取った画像データを記録媒体に印刷する複写機としての複写（コピー）モードなどに対応するキー（プリンタキー・ファックス／イメージ送信キー・コピーキー）を有する。操作者は、これらのキーの中からいずれかを選択することで、本ファクシミリ／電子メール装置１１の機能を選択する。上記ジョブステータス表示キー３８は、現在の画像形成ジョブの状況を選択表示するためのキーである。
【００７１】
−インターネットファクシミリ機能の説明−
以下、本ファクシミリ／電子メール装置１１におけるインターネットファクシミリ装置としての機能について説明する。本ファクシミリ／電子メール装置１１は、インターネットファクシミリ装置としてファクシミリ文書データ（画像データ）を送信する場合、符号／復号化制御部２１において符号化されたファクシミリ文書データには、電子メール作成部１８において、ヘッダ情報が付加され、電子メールのフォーマットに変換される。
【００７２】
すなわち、本ファクシミリ／電子メール装置１１は、ファクシミリ文書データの送信先である電子メールアドレスにファクシミリ文書データを添付ファイルとして付加して電子メール化する。そして、公衆電話回線等を通じてインターネットプロバイダに接続し、そのホストを介してインターネットに接続するか、または直接インターネットに接続して、ネットワーク上のメールサーバにその電子メールを転送する。
【００７３】
そして、送信側の本ファクシミリ／電子メール装置１１（上記図１における送信側端末１に相当）および受信側のファクシミリ／電子メール装置１１’（上記図１における受信側端末５に相当）が共にインターネットに接続されることで、電子メールの送受信を行うことができる。
【００７４】
そして、本ファクシミリ／電子メール装置１１は、配信成功後にメッセージで処理状況を通知する上記ＭＤＮ機能を有する。ＭＤＮ機能とは、前述のように、電子メールを受信した場合に、受信側のファクシミリ／電子メール装置１１’が送達確認応答を送信側のファクシミリ／電子メール装置１１に返信することによって送達確認を行うことができる機能である。
【００７５】
そこで、本ファクシミリ／電子メール装置１１では、電子メール作成部１８において、電子メールのヘッダ部に、送達確認送受信制御部２５が用いるためのＭＤＮフィールドを付加し、そのＭＤＮフィールドに確認メールを送付するアドレス（送信側のファクシミリ／電子メール装置１１のアドレスまたは番号）を記述し、送達確認応答要求（能力通知要求）を行う。具体的な通信動作については後述する。
【００７６】
−電子メール通信動作の説明−
次に、上記構成のファクシミリ／電子メール装置１１において、画像データが添付された電子メールを送信機側から送信する場合の通信動作について説明する。
【００７７】
図５は送信側のファクシミリ／電子メール装置１１における制御手順を示すフローチャート図であり、図６及び図７はこの制御手順の一部分についての詳細動作を示すフローチャート図である。一方、図９は受信側のファクシミリ／電子メール装置１１’における制御手順を示すフローチャート図である。
【００７８】
＜送信側の制御動作＞
先ず、送信側のファクシミリ／電子メール装置１１における制御手順について図５〜図８を用いて説明する。
【００７９】
ファクシミリ／電子メール装置１１から電子メールを送信する場合、前もって、相手側のファクシミリ／電子メール装置１１’の受信能力を問い合わせるための通信を必要に応じて行う。つまり、先ず、ステップＳＴ１で送信開始の処理を行う。この送信開始の処理の詳細（図６）については後述する。その後、ステップＳＴ２でメールサーバ装置２への接続を実行し、ステップＳＴ３で上記問い合わせのためのメール（能力通知要求メール）を必要に応じて送信する。ここで能力通知要求メールを送信するのか、または通常の電子メール（画像データが添付されたもの）を送信するのかは、後述する送信開始処理により決定される。
【００８０】
次に、上記ステップＳＴ１における送信開始の処理について図６に沿って説明する。この送信開始の処理の開始時には、本ファクシミリ／電子メール装置１１の読取部に原稿がセットされており（ステップＳＴ２１）、相手先情報による送信であるか否かが判定される（ステップＳＴ２２）。つまり、制御用メモリ（相手側情報記憶手段）１４に予め登録されている相手先に対する送信であるか否かが判定される。
【００８１】
図８は、この制御用メモリ１４に予め登録されている相手先情報の一覧を示している。このように、複数の相手先に対して、短縮番号（ワンタッチＮｏ）、Ｅ−ｍａｉｌアドレス、読み込み可能なファイル形式、受信及び復号化可能な圧縮形式等が記憶されている。
【００８２】
上記ステップＳＴ２２のおける判定がＹＥＳである場合には、ステップＳＴ２３に移り、ワンタッチキーもしくは短縮番号が入力され、送信相手先がユーザにより特定された後、ステップＳＴ２６に移る。
【００８３】
一方、上記ステップＳＴ２２における判定がＮＯである場合には、ステップＳＴ２４において送信相手先のＥ−ｍａｉｌアドレスを、ステップＳＴ２５において送信条件をユーザがそれぞれ入力した後、ステップＳＴ２６に移る。この送信条件とは、原稿のファイル形式及び圧縮形式等である。
【００８４】
ステップＳＴ２６においてユーザがスタートキー３５を押すことにより、原稿の読取り動作が開始される（ステップＳＴ２７）。
【００８５】
この読取り動作の開始後、ステップＳＴ２８において、送信モードがシンプルモードに設定されているか否かを判定し、シンプルモードであるＹＥＳの場合にはそのまま送信開始処理動作を終了して、上記ステップＳＴ２（図５）以降の動作に移る。つまり、この場合には、能力通知要求メールを作成することなしに相手側装置１１’に対して電子メールを送信することになる。この場合には、能力通知要求メールを送信することなしに通常の電子メールが相手側装置１１’に送信されることになる。これによれば、無駄な能力通知要求メール（問い合わせメール）の送信による待ち時間が発生することを防止できる。
【００８６】
一方、送信モードがシンプルモードでないＮＯの場合には、ステップＳＴ２９に移り、受信能力が予め登録されている相手先への送信であるか否かを判定する。つまり、上記制御用メモリ１４に登録されている相手先への送信であるか否かを判定する。
【００８７】
この判定がＮＯである場合には、ステップＳＴ３０に移り、入力された送信内容については送信待ちとして登録すると共に、相手側への受信能力の問い合わせメールを作成して送信開始処理動作を終了する。
【００８８】
一方、ステップＳＴ２９の判定がＹＥＳである場合には、送信しようとする画像データが登録されている受信能力に一致しているときにはそのまま送信開始処理動作を終了するが、送信しようとする画像データが登録されている受信能力に一致していないときにはステップＳＴ３０に移り、上記と同様に、入力された送信内容については送信待ちとして登録すると共に、相手側への受信能力の問い合わせメールを作成して送信開始処理動作を終了する。つまり、問い合わせメールの送信に対する相手先からの返信メールを待って画像データを変換すべきか否かを判定した後に通常の電子メールによる画像データの送信が実行できるようにしている。
【００８９】
このようにして必要に応じ、上記ステップＳＴ３０において相手側装置１１’に対して能力問い合わせのためのメールを作成し、これをステップＳＴ３において送信し、それに応じた返信を待つことになる。この際の相手側装置１１’による返信動作については後述する。尚、問い合わせメールを送信しない場合には、このステップＳＴ３における送信は通常の電子メール（画像データが添付されたもの）の送信となる。
【００９０】
図５に戻り、ステップＳＴ５において、相手側装置１１’に対して受信能力の問い合わせ設定（問い合わせメールの送信）がなされなかった場合（ＮＯ判定の場合）には、そのまま通信動作を終了する。一方、相手側装置１１’に対して受信能力の問い合わせ設定（問い合わせメールの送信）がなされている場合には、ステップＳＴ６に移り、上記時計部２６による待ち時間計測を開始する。
【００９１】
その後、本ファクシミリ／電子メール装置１１は、メールサーバ装置２への接続を実行し（ステップＳＴ７）、新着メールの有無を確認する（ステップＳＴ８）。新着メールが存在する場合にはステップＳＴ９においてそのメールを受信してステップＳＴ１０に移ってメールサーバ装置２との接続を終了する一方、新着メールが存在しない場合にはそのままメールサーバ装置２との接続を終了する。
【００９２】
その後、ステップＳＴ１１に移り、新着メールは受信能力の問い合わせに対する返信メールであるか否かを判定し、この判定がＹＥＳである場合には、ステップＳＴ１２において上記待ち時間計測を終了し、ステップＳＴ１３において、相手先の能力に応じて画像データの変換処理が必要であるか否かを判定する。ここで画像変換処理が必要であると判断された場合にはステップＳＴ１４において画像変換処理（ファイル形式及び圧縮形式等の変換処理）を実行した後にステップＳＴ２に戻って、相手側装置１１’に対して電子メールを送信する。一方、画像変換処理が必要でないと判断された場合には画像変換処理を実行することなくステップＳＴ２に戻って、相手側装置１１’に対して電子メールを送信する。
【００９３】
また、上記ステップＳＴ１１において、受信能力の問い合わせに対する返信メールが存在しないと判定された場合には、ステップＳＴ１５に移り、上記待ち時間計測がタイムアウトしたか否かを判定する。この待ち時間計測がタイムアウトするまで上記ステップＳＴ７〜ステップＳＴ１１の動作を繰り返す。
【００９４】
このステップＳＴ１５でタイムアウトが判定されると、ステップＳＴ１６において待ち時間計測を終了し、ステップＳＴ１７において送信条件変更処理（詳細は後述）を実行した後、ステップＳＴ２に戻って、相手側装置１１’に対して電子メールを送信する。
【００９５】
次に、このステップＳＴ１７において実行される送信条件変更処理について図７に沿って説明する。この送信条件変更処理が開始されると、先ず、ステップＳＴ４１において、既に設定されている条件で送信するか否かが判定される。この判定がＹＥＳである場合にはステップＳＴ４２においてその設定条件で相手側装置１１’に対する送信が実行される。つまり、登録されている相手側装置１１’の能力に適合した画像データに変更して送信を行う。
【００９６】
一方、上記ステップＳＴ４１でＮＯに判定された場合には、ステップＳＴ４３に移り、送信しようとする相手先の能力情報が上記制御用メモリ１４に登録されているか否かを判定し、この判定がＹＥＳの場合には、ステップＳＴ４４において、登録されている能力情報に変更するか否かが判定され、この判定がＹＥＳの場合には、ステップＳＴ４５において能力を変更した後に相手側装置１１’に対する送信が実行される。
【００９７】
一方、上記ステップＳＴ４３またはステップＳＴ４４においてＮＯに判定された場合にはステップＳＴ４６に移って送信モードをシンプルモードに変更して送信を行う。つまり、制御用メモリ１４に登録されていない相手先に対して電子メールを送信しようとしている場合であって、この相手先から能力通知の返信メールが送信されないままにタイムアウトしてしまったため、この相手先が確実に受信できる送信モードであるシンプルモードに変更して送信を行う。
【００９８】
＜受信側の制御動作＞
次に、受信側のファクシミリ／電子メール装置１１’における制御手順について図９を用いて説明する。
【００９９】
先ず、メールサーバ装置４への接続を実行し（ステップＳＴ５１）、受信メールの有無を確認する（ステップＳＴ５２）。受信メールが存在しない場合にはそのまま通信動作を終了する。
【０１００】
一方、受信メールが存在する場合には、ステップＳＴ５３において、その受信メールに画像データが存在しているか否かを判定する。そして、画像データが存在しているＹＥＳの場合にはその受信データをメモリに格納（ステップＳＴ５４）すると共に、その画像データの印刷動作を実行し（ステップＳＴ５５）、その通信結果を表示（通知）する（ステップＳＴ５６）。つまり、受信メールに画像データが存在しているということは、能力通知要求メール（問い合わせメール）でないので、そのメールに対する返信を返すことなく通信動作を終了する。
【０１０１】
一方、上記ステップＳＴ５３において、受信メールに画像データが存在していないと判定された場合には、ステップＳＴ５７に移って、その受信メール中に能力通知要求の情報があるか、つまり、その受信メールは能力通知要求メールであるか否かを判定する。能力通知要求の情報があるＹＥＳの場合には、ステップＳＴ５８において送信側の装置１１の能力通知情報が含まれているか否かを判定し、この判定がＹＥＳの場合には、ステップＳＴ５９において送信側の装置１１の能力通知情報を登録しておく。
【０１０２】
このように送信側の装置１１の能力通知情報を登録しておけば、今回の通信では送信側装置１１及び受信側装置１１’としてそれぞれ機能していた各通信機器が、将来的に、送受信が逆転した際、送信側装置１１’（以前の通信では受信側となっていた装置）は受信側装置１１（以前の通信では送信側となっていた装置）の受信能力を既に取得していることになり、この一対の装置間では、画像データを送信する度に問い合わせを実行するといったことは必要なくなり、短時間で良好な画像データの送受信を実行することが可能となる。
【０１０３】
その後、ステップＳＴ６０において、上記能力通知要求に応えるべく、自己装置（受信側装置）の受信能力情報を書き込んだ能力通知メールを作成し、ステップＳＴ６１において、その能力通知メールの送信処理を実行する。
【０１０４】
一方、上記ステップＳＴ５７において、受信メール中に能力通知要求の情報がないＮＯに判定された場合には、ステップＳＴ６２に移って通信エラーや異常データ受信を通知する。つまり、画像データが無く、能力通知要求の情報も無いメールであり、通信不良が生じている可能性があるため、通信エラーや異常データ受信を通知することになる。
【０１０５】
−電子メールの具体例−
次に、上述の各動作において送受信される電子メールの具体的な内容の一例について説明する。
【０１０６】
図１０は、上記ステップＳＴ３において相手側装置に送信される「能力通知要求メール」である。図１１は、上記ステップＳＴ６１において送信側装置１１に返信される能力通知要求に対する「応答メール」である。図１２は、この応答メールを受信した後に画像データを送信するための「送信メール」である。
【０１０７】
「能力通知要求メール」は、図１０に示すように、（ａ）に示すヘッダ部及び（ｂ）に示す本文を含んでいる。なお、電子メールは実際には（ａ）、（ｂ）のように分割されている訳ではないが、ここでは簡単のために分割した状態で説明する。
【０１０８】
図１０中の（ａ）に示すヘッダ部は、電子メールの送受信およびインターネット中での配信などに関する情報を表示する領域である。ここで、ヘッダ部中の各行は、送受信などで用いるそれぞれ異なる固有の情報を記している。以下では、この各行のことをフィールドと呼ぶ。例えば、Ｔｏフィールドには電子メールの送信先が表示されている。また、Ｆｒｏｍフィールドには「能力通知要求メール」の発信元が表示されている。更に、Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールド（ＭＤＮフィールド）を用いて、返信メール（応答メール）を送付するべき返信先を設定するようになっている。また、Ｄｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｏｐｔｉｏｎｓフィールドを用いて、本メールが「能力通知要求メール」である旨及び受信能力をリクエストしていることを示している。また、Ｍｅｓｓａｇｅ−ＩＤフィールドは、個々のメールを識別するためのフィールドであり、ここでは、Ｍｅｓｓａｇｅ−ＩＤ：＜１１１＠ＳＨＡＲＰ＿Ｄ１＞を付与して送信している。
【０１０９】
このように、本メールが「能力通知要求メール」である旨の情報を包含させておくことにより、画像データが無い場合であっても受信側ではエラー判定は行われず良好な通信状態を得ることができる。
【０１１０】
更に、（ｂ）の本文には、この「能力通知要求メール」の発信元のファクシミリ／電子メール装置１１の能力についての情報が書き込まれている。
【０１１１】
「応答メール」は、図１１に示すように、（ａ）に示すヘッダ部及び（ｂ）に示す本文を含み、さらには、（ｃ）に示すＭＤＮ情報を含んでいる。なお、電子メールは実際には（ａ）〜（ｃ）のように分割されている訳ではないが、ここでは簡単のために分割した状態で説明する。
【０１１２】
図１１中の（ａ）に示すヘッダ部は、電子メールの送受信およびインターネット中での配信などに関する情報を表示する領域である。ここで、ヘッダ部中の各行は、送受信などで用いるそれぞれ異なる固有の情報を記している。例えば、Ｔｏフィールドには先に受信した電子メールのＤｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏで示された電子メールの返信先が表示されている。ここでは、図示するように、Ｓｈａｒｐ＿Ｄｏｃ＿ＩｎｔｅｒｎｅｔＦＡＸ＠ｓｈａｒｐ．ｃｏ．ｊｐに設定されている。
【０１１３】
また、Ｍｅｓｓａｇｅ−ＩＤフィールドは、個々のメールを識別するためのフィールドである。例えば、送信時に送信メールに対してＭｅｓｓａｇｅ−ＩＤ：＜ＡＡＡ＠ＳＨＡＲＰ＿Ｄ１＞を付与して送信する。これにより、ＭＤＮの応答メールとして、そのＭｅｓｓａｇｅ−ＩＤ：＜ＡＡＡ＠ＳＨＡＲＰ＿Ｄ１＞が結果情報のＯｒｉｇｉｎａｌ−Ｍｅｓｓａｇｅ−ＩＤフィールドに付与された応答メールを受信することができ、これによってメールを識別することができる。
【０１１４】
また、（ｂ）に示す本文は、いわゆる電子メールの本体に相当する。本実施形態は、画像情報を送信するインターネットファクシミリ通信の場合であるので、本文は簡単なメッセージの送受信のために補助的に用いられている。尚、図１１（ｂ）の本文においては、送信が成功もしくは、失敗（エラー）した旨のメッセージが記述される。
【０１１５】
また、（ｃ）に示すＭＤＮ情報はＭＤＮに用いるための情報である。図示する各フィールドは、それぞれ次の情報を表す。
【０１１６】
Ｆｉｎａｌ−Ｒｅｃｉｐｉｅｎｔのフィールドは、ＭＤＮを返信した受け取りアドレスを示す。
【０１１７】
Ｏｒｉｇｉｎａｌ−Ｍｅｓｓａｇｅ−ＩＤは、電子メールを識別するためのＩＤである。例えば図１１（ａ）に示すＭｅｓｓａｇｅ−ＩＤフィールドに対応する送達確認の応答であることを示すために用いる。また、Ｄｉｓｐｏｓｉｔｉｏｎフィールドは、上記Ｍｅｓｓａｇｅ−ＩＤに対応する電子メールの処理が成功したか否かなどの状態を示す。図１１（ｃ）においては、処理が成功した、もしくは失敗した旨が示される。
【０１１８】
また、Ｍｅｄｉａ−Ａｃｃｅｐｔ−Ｆｅａｔｕｒｅｓフィールドは、電子メールの送信先における受信能力を示すフィールドである。
【０１１９】
例えば、図１１（ｃ）に示すように、本実施形態の送信先の受信能力は、カラー表示であり（ｃｏｌｏｒ＝ｆｕｌｌ）、Ｔｉｆｆフォーマットのみ読取ることができ（ｉｍａｇｅ−ｆｉｌｅ−ｓｔｒｕｃｔｕｒｅ＝ＴＩＦＦ−ｌｉｍｉｔｅｄ）、２００ｄｐｉの解像度であり（ｄｐｉ＝２００）、縦横比が２００：１００かまたは２００：２００であり（ｄｐｉ−ｘｙｒａｔｉｏ＝［２００／１００，２００／２００］）、符号化方法はＭＨかＭＲかＭＭＲかＪＰＥＧが可能であり（ｉｍａｇｅ−ｃｏｄｉｎｇ＝［ＭＨ，ＭＲ，ＭＭＲ，ＪＰＥＧ］）、ＭＲＣ（ＭｉｘｅｄＲａｓｔｅｒＣｏｎｔｅｎｔ）モードは０であり（０の場合においては、１頁内に異なる符号化方式や、解像度を許可しない）（ＭＲＣ−ｍｏｄｅ＝０）、用紙サイズはＡ４かＢ４かＡ３である（ｐａｐｅｒ−ｓｉｚｅ＝［Ａ４，Ｂ４，Ａ３］）。
【０１２０】
「送信メール」は、図１２に示すように、（ａ）に示すヘッダ部及び（ｂ）に示す本文を含み、さらには、（ｃ）に示す添付ファイルを含んでいる。なお、電子メールは実際には（ａ）〜（ｃ）のように分割されている訳ではないが、ここでは簡単のために分割した状態で説明する。
【０１２１】
図１２中の（ａ）に示すヘッダ部は、電子メールの送受信およびインターネット中での配信などに関する情報を表示する領域である。ここで、ヘッダ部中の各行は、送受信などで用いるそれぞれ異なる固有の情報を記している。例えば、Ｔｏフィールドには電子メールの宛先が表示されている。
【０１２２】
ここで、本実施形態においては、図１２（ａ）に記載のＭＤＮ（ＲＦＣ２２９８）で規定されるＤｉｓｐｏｓｉｔｉｏｎ−Ｎｏｔｉｆｉｃａｔｉｏｎ−Ｔｏフィールド（ＭＤＮフィールド）を用いて、送達確認メールを送付するべき送信先を設定するようになっている。すなわち、この宛先は、図示するように、Ｓｈａｒｐ＿Ｄｏｃ＿ＩｎｔｅｒｎｅｔＦＡＸ＠ｓｈａｒｐ．ｃｏ．ｊｐに設定されている。
【０１２３】
また、Ｍｅｓｓａｇｅ−ＩＤフィールドは、個々のメールを識別するためのフィールドである。例えば、送信時に送信メールに対してＭｅｓｓａｇｅ−ＩＤ：＜２２２＠ＳＨＡＲＰ＿Ｄ１＞を付与して送信する。すると、ＭＤＮの応答メールとして、そのＭｅｓｓａｇｅ−ＩＤ：＜２２２＠ＳＨＡＲＰ＿Ｄ１＞が結果情報のＯｒｉｇｉｎａｌ−Ｍｅｓｓａｇｅ−ＩＤフィールドに付与された応答メールを受信することができ、これによってメールを識別することができる。
【０１２４】
また、（ｂ）に示す本文は、いわゆる電子メールの本体に相当する。本実施形態は、画像情報を送信するインターネットファクシミリ通信の場合であるので、本文は簡単なメッセージの送受信のために補助的に用いられている。
【０１２５】
また、（ｃ）に示す添付ファイルは、符号化した画像ファイルを電子メールの本文に添付したものである。この添付ファイルの形式は、ＭＩＭＥ（ＭｕｌｔｉｐｕｒｐｏｓｅＩｎｔｅｒｎｅｔＭａｉｌＥｘｔｅｎｓｉｏｎｓ）として定められている。
【０１２６】
尚、各図に示した電子メールの内容は、これに限られるものではない。
【０１２７】
以上説明したように、本形態では、電子メールの添付ファイルとして画像データを送信するに際し、先ず、この画像データを送信しようとする送信先である相手側装置１１’に対して、受信可能なデータ圧縮形式等の受信能力を予め確認するための通信を行っている。このため、送信側の装置１１にあっては、相手側装置１１’において画像データが正常に受信されたかどうか、または受信側において処理が適切になされたかどうかを送信後に確認する必要が無くなる。つまり、この確認をしなくても、相手側装置において正常な受信及び処理が行われたことを確信できる。
【０１２８】
−その他の実施形態−
上述した実施形態では、通常のファクシミリ装置としての機能、電子メール装置としての機能、インターネットファクシミリ装置としての機能等を共に有するファクシミリ／電子メール装置１１に本発明を適用した場合について説明した。本発明はこれに限らず、インターネットファクシミリ装置としての機能のみを備えた装置に対して適用することも可能である。
【０１２９】
【発明の効果】
以上のように、本発明では、先ず、画像データを送信しようとする送信先の装置（相手側装置）に対して受信能力を予め確認するための通信を行う。そして、相手側装置の応答によってその受信能力を確認し、相手側装置が受信可能な形態に画像データを変換して送信するようにしている。このため、送信側の通信装置にあっては、相手側装置において画像データが正常に受信されたかどうか、または受信側において処理が適切になされたかどうかを送信後に確認する必要が無くなる。つまり、この確認をしなくても、相手側装置において正常な受信及び処理が行われたことを確信でき、通信動作の信頼性の向上を図ることができる。
【０１３０】
また、上述した如く電子メールにより相手側装置に向けて送信するものに適用した場合には、リアルタイムで対話をする必要がないという電子メールによる通信の利点を損うことなしに、相手側装置において正常な受信及び処理が行われたことを送信側の通信装置において確信することもできる。
【図面の簡単な説明】
【図１】ファクシミリ／電子メール装置によって構築されたネットワークの概略構成を示す図である。
【図２】発信情報の中に問い合わせのための発信である旨の情報を包含させた場合と、包含させない場合との通信形態を比較するための概念図である。
【図３】実施形態に係るファクシミリ／電子メール装置の電気的構成を示すブロック図である。
【図４】パネル制御部の構成を示す図である。
【図５】送信側のファクシミリ／電子メール装置における制御手順を示すフローチャート図である。
【図６】図５における「送信開始処理」の手順の詳細を示すフローチャート図である。
【図７】図５における「送信条件変更処理」の手順の詳細を示すフローチャート図である。
【図８】登録されている相手先情報の一覧を示す図である。
【図９】受信側のファクシミリ／電子メール装置における制御手順を示すフローチャート図である。
【図１０】「能力要求メール」の具体内容を示す図である。
【図１１】「応答メール」の具体内容を示す図である。
【図１２】「送信メール」の具体内容を示す図である。
【符号の説明】
１送信側端末（通信装置）
５受信側端末（相手側装置）
１４制御用メモリ（相手側情報記憶手段）
１８電子メール作成部（問い合わせ手段）
２２ＬＡＮ制御部（送信手段、能力受信手段）

Claims

画像データを相手側装置に向けて送信可能な通信装置において、
相手側装置の受信能力の問い合わせを行う問い合わせ手段と、
上記問い合わせに応じて相手側装置が発信する受信能力情報を受信する能力受信手段と、
上記能力受信手段により取得した相手側装置の受信能力に応じて画像データを変換し、その変換後の画像データを相手側装置に向けて送信する送信手段とを備えていることを特徴とする通信装置。
データ圧縮処理した画像データを電子メールにより相手側装置に向けて送信可能な通信装置において、
相手側装置が受信可能なデータ圧縮形式の問い合わせを行う問い合わせ手段と、
上記問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する能力受信手段と、
上記能力受信手段により取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信手段とを備えていることを特徴とする通信装置。
データ圧縮処理した画像データを電子メールにより相手側装置に向けて送信可能な通信装置において、
相手側装置が受信可能なデータ圧縮形式の問い合わせを行うと共に、その発信情報の中に問い合わせのための発信である旨の情報を包含させておく問い合わせ手段と、
上記問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する能力受信手段と、
上記能力受信手段により取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信手段とを備えていることを特徴とする通信装置。
データ圧縮処理した画像データを電子メールにより相手側装置に向けて送信可能な通信装置において、
相手側装置が受信可能なデータ圧縮形式の問い合わせをＲＦＣ２２９８及びＲＦＣ２８７９に基づく送達確認要求を用いて行う問い合わせ手段と、
上記問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信可能な能力受信手段と、
上記能力受信手段により取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信手段とを備えていることを特徴とする通信装置。
データ圧縮処理した画像データを電子メールにより相手側装置に向けて送信可能な通信装置において、
相手側装置に向けて画像データを送信しようとする送信モードがシンプルモードではない場合に限って、相手側装置が受信可能なデータ圧縮形式の問い合わせを行う問い合わせ手段と、
上記問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する能力受信手段と、
上記能力受信手段により取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信手段とを備えていることを特徴とする通信装置。
データ圧縮処理した画像データを電子メールにより相手側装置に向けて送信可能な通信装置において、
予め相手側装置の受信能力情報を記憶しておくことが可能な相手側情報記憶手段と、
画像データを送信しようとする相手側装置が上記相手側情報記憶手段に記憶されている相手側装置ではない場合に限って、相手側装置が受信可能なデータ圧縮形式の問い合わせを行う問い合わせ手段と、
上記問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する能力受信手段と、
上記能力受信手段により取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信手段とを備えていることを特徴とする通信装置。
請求項１〜６のうち何れか一つに記載の通信装置において、
問い合わせ手段による問い合わせが実行された後、所定時間が経過しても能力受信手段が相手側装置からの情報を受信しない場合、送信手段は、画像データを変換することなく画像データを相手側装置に向けて送信するよう構成されていることを特徴とする通信装置。
データ圧縮処理した画像データを電子メールにより相手側装置に向けて送信可能な通信装置において、
予め相手側装置の受信能力情報を記憶しておくことが可能な相手側情報記憶手段と、
相手側装置が受信可能なデータ圧縮形式の問い合わせを行う問い合わせ手段と、
上記問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する能力受信手段と、
上記能力受信手段により取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信手段とを備えており、
問い合わせ手段による問い合わせが実行された後、所定時間が経過しても能力受信手段が相手側装置からの情報を受信しない場合、画像データを送信しようとする相手側装置が相手側情報記憶手段に記憶されている相手側装置であるときには、送信手段は、その記憶情報に基づいて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信するよう構成されていることを特徴とする通信装置。
請求項１〜６のうち何れか一つに記載の通信装置において、
問い合わせ手段による問い合わせが実行された後、所定時間が経過しても能力受信手段が相手側装置からの情報を受信しない場合、送信手段は、シンプルモードで画像データを相手側装置に向けて送信するよう構成されていることを特徴とする通信装置。
請求項１〜９のうち何れか一つに記載の通信装置において、
問い合わせ手段は、問い合わせ情報の中に自己装置の受信能力情報を包含させるよう構成されていることを特徴とする通信装置。
請求項１〜１０のうち何れか一つに記載の通信装置によって実行される通信方法であって、
相手側装置の受信能力の問い合わせを行う問い合わせ動作と、
上記問い合わせに応じて相手側装置が発信する受信能力情報を受信する能力受信動作と、
取得した相手側装置の受信能力に応じて画像データを変換し、その変換後の画像データを相手側装置に向けて送信する送信動作とを備えていることを特徴とする通信方法。
請求項１〜１０のうち何れか一つに記載の通信装置によって実行される通信方法であって、
相手側装置が受信可能なデータ圧縮形式の問い合わせを行う問い合わせ動作と、
上記問い合わせに応じて相手側装置が発信する受信可能圧縮形式情報を受信する能力受信動作と、
取得した相手側装置の受信可能圧縮形式に応じて画像データを圧縮処理し、その処理後の画像データを相手側装置に向けて送信する送信動作とを備えていることを特徴とする通信方法。