(57)【要約】【課題】画情報通信時の処理負担を軽減することができる通信端末装置を提供すること目的とする。【解決手段】ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行う通信端末装置であって、画像送信時、送信する画像データの総パケット数を相手端末に通知する通知手段と、画像受信時、相手端末より画像データの総パケット数が通知された場合、画像データの受信時、当該画像データの最初のパケットから前記通知された総パケット数のパケットを受信すると、その受信したパケットの所定箇所の内容のデコードを行わない受信手段を備えた。【選択図】        図１
2010035123.tif 000002
【特許請求の範囲】
【請求項１】
ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行う通信端末装置であって、
画像送信時、送信する画像データの総パケット数を相手端末に通知する通知手段と、
画像受信時、相手端末より画像データの総パケット数が通知された場合、画像データの受信時、当該画像データの最初のパケットから前記通知された総パケット数のパケットを受信すると、その受信したパケットの所定箇所の内容のデコードを行わない受信手段を備えたことを特徴とする通信端末装置。
【請求項２】
画像通信に先立って、相手端末との間で通信機能のネゴシエーションを行い、
画像送信時、相手端末が画像データの受信パケットの所定箇所の内容のデコードを行わない機能を備えていることが判明した場合、前記画像データを運ぶパケットのうち、前記所定箇所の内容として適宜なビット列を挿入する送信画データ生成手段をさらに備えたことを特徴とする請求項１記載の通信端末装置。
【請求項３】
画像通信に先立って、相手端末との間で通信機能のネゴシエーションを行い、
画像送信時、相手端末が画像データの受信パケットの所定箇所の内容のデコードを行わない機能を備えていることが判明した場合、前記画像データを運ぶパケットのうち、前記所定箇所の内容としてデータ長が０のビット列を挿入する送信画データ生成手段をさらに備えたことを特徴とする請求項１記載の通信端末装置。
【請求項４】
画像受信時、受信した総パケット数よりも、前記受信手段が受信した画像データの総パケット計数値が多い場合、相手端末に、画像データの総パケット数を再送要求する再送要求手段と、
画像送信時、相手端末より画像データの総パケット数の再送要求を受信すると、送信終了した画像データの総パケット数を、相手端末へ通知する総パケット数再送手段をさらに備えたことを特徴とする請求項１乃至３のいずれかに記載の通信端末装置。
【請求項５】
画像受信時、受信した総パケット数よりも、前記受信手段が受信した画像データの総パケット計数値が少ない場合、相手端末に、画像データの総パケット数を再送要求する再送要求手段と、
画像送信時、相手端末より画像データの総パケット数の再送要求を受信すると、送信終了した画像データの総パケット数を、相手端末へ通知する総パケット数再送手段をさらに備えたことを特徴とする請求項１乃至３のいずれかに記載の通信端末装置。
【請求項６】
画像受信時、相手端末より再送された総パケット数と、前記総パケット計数値が相違する場合、相手端末に画像データの再送を要求する画像データ再送要求手段と、
画像送信時、相手端末より画像データの再送が要求された場合には、画像データを再度送信する画像再送手段をさらに備えたことを特徴とする請求項４または請求項５記載の通信端末装置。
【請求項７】
画像通信に先立って、相手端末との間で通信機能のネゴシエーションを行い、
画像送信時、相手端末が画像データの受信パケットの所定箇所の内容のデコードを行わない機能を備えていることが判明した場合、登録されているアドレス帳情報に、当該機能を備えている旨を記憶することを特徴とする請求項１乃至６のいずれかに記載の通信端末装置。
【請求項８】
ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行う通信端末装置であって、
画像送信時、送信する画像データのページ毎の総パケット数を相手端末に通知する通知手段と、
画像受信時、相手端末より画像データのページ毎の総パケット数が通知された場合、各ページの画像データの受信時、当該画像データの最初のパケットから前記通知された総パケット数のパケットを受信すると、その受信したパケットの所定箇所の内容のデコードを行わない受信手段を備えたことを特徴とする通信端末装置。
【請求項９】
ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行う通信端末装置であって、
ＥＣＭモードの画像送信時、送信する画像データのブロック毎の総パケット数を相手端末に通知する通知手段と、
ＥＣＭモードの画像受信時、相手端末より画像データのブロック毎の総パケット数が通知された場合、各ブロックの画像データの受信時、当該画像データの最初のパケットから前記通知された総パケット数のパケットを受信すると、その受信したパケットの所定箇所の内容のデコードを行わない受信手段を備えたことを特徴とする通信端末装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行う通信端末装置に関する。
【背景技術】
【０００２】
従来、ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行うＴ．３８リアルタイム型ＦＡＸ（以下、「ＩＰ−ＦＡＸ」という）は、基本的に、ＩＴＵ−Ｔ勧告Ｔ．３０のグループ３ファクシミリ手順をＩＰネットワーク上で実現して、画像通信を行う。また、このＩＰ−ＦＡＸでは、画データをパケット化してＩＰネットワークを介して送受信を行う。
【０００３】
ここで、このパケット化された情報の内部構造は、以下の２つに分けることができる。
Ａ：パケットの順序番号、データ内容等、画データというくくりの中で各パケットでユニークなもの
Ｂ：メッセージ種別、データ種別等、画データというくくりの中では複数パケットで同じ値が格納されているもの
【０００４】
例えば、ＩＰ−ＦＡＸで１ページの画像を送信する場合、画データは通常数百パケット以上に分割して送信される。このうち順序番号、データ内容は各パケットで異なる情報が格納されているが、メッセージ種別（例えば、「ｖ１７−１４４００」を表すビット列）や、データ種別（例えば、「ｔ４−ｎｏｎ−ｅｃｍ−ｄａｔａ」を表すビット列）は、全ての画データパケットで同一の値が格納されている。
【特許文献１】特許第４０３３８１２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
以上がＩＴＵ−Ｔ勧告Ｔ．３８で定められているが、数百パケット（複数ページになると数千パケット、数万パケットに及ぶ）で変わらない情報をエンコード、デコードすることは、通信端末装置側の処理負担が大きくなり、その結果、通信速度向上の妨げとなり、場合によってはネットワーク回線の能力を十分に発揮できないという問題を生じるおそれがある。
【０００６】
本発明は、かかる実情に鑑みてなされたものであり、画情報通信時の処理負担を軽減することができる通信端末装置を提供すること目的とする。
【課題を解決するための手段】
【０００７】
本発明は、ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行う通信端末装置であって、画像送信時、送信する画像データの総パケット数を相手端末に通知する通知手段と、画像受信時、相手端末より画像データの総パケット数が通知された場合、画像データの受信時、当該画像データの最初のパケットから前記通知された総パケット数のパケットを受信すると、その受信したパケットの所定箇所の内容のデコードを行わない受信手段を備えたものである。
【０００８】
また、画像通信に先立って、相手端末との間で通信機能のネゴシエーションを行い、画像送信時、相手端末が画像データの受信パケットの所定箇所の内容のデコードを行わない機能を備えていることが判明した場合、前記画像データを運ぶパケットのうち、前記所定箇所の内容として適宜なビット列を挿入する送信画データ生成手段をさらに備えたものである。
【０００９】
また、画像通信に先立って、相手端末との間で通信機能のネゴシエーションを行い、画像送信時、相手端末が画像データの受信パケットの所定箇所の内容のデコードを行わない機能を備えていることが判明した場合、前記画像データを運ぶパケットのうち、前記所定箇所の内容としてデータ長が０のビット列を挿入する送信画データ生成手段をさらに備えたものである。
【００１０】
また、画像受信時、受信した総パケット数よりも、前記受信手段が受信した画像データの総パケット計数値が多い場合、相手端末に、画像データの総パケット数を再送要求する再送要求手段と、画像送信時、相手端末より画像データの総パケット数の再送要求を受信すると、送信終了した画像データの総パケット数を、相手端末へ通知する総パケット数再送手段をさらに備えたものである。
【００１１】
また、画像受信時、受信した総パケット数よりも、前記受信手段が受信した画像データの総パケット計数値が少ない場合、相手端末に、画像データの総パケット数を再送要求する再送要求手段と、画像送信時、相手端末より画像データの総パケット数の再送要求を受信すると、送信終了した画像データの総パケット数を、相手端末へ通知する総パケット数再送手段をさらに備えたものである。
【００１２】
また、画像受信時、相手端末より再送された総パケット数と、前記総パケット計数値が相違する場合、相手端末に画像データの再送を要求する画像データ再送要求手段と、
【００１３】
画像送信時、相手端末より画像データの再送が要求された場合には、画像データを再度送信する画像再送手段をさらに備えたものである。
【００１４】
また、画像通信に先立って、相手端末との間で通信機能のネゴシエーションを行い、画像送信時、相手端末が画像データの受信パケットの所定箇所の内容のデコードを行わない機能を備えていることが判明した場合、登録されているアドレス帳情報に、当該機能を備えている旨を記憶するようにしたものである。
【００１５】
また、ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行う通信端末装置であって、画像送信時、送信する画像データのページ毎の総パケット数を相手端末に通知する通知手段と、画像受信時、相手端末より画像データのページ毎の総パケット数が通知された場合、各ページの画像データの受信時、当該画像データの最初のパケットから前記通知された総パケット数のパケットを受信すると、その受信したパケットの所定箇所の内容のデコードを行わない受信手段を備えたものである。
【００１６】
また、ＩＴＵ−Ｔ勧告Ｔ．３８通信による画像通信を行う通信端末装置であって、ＥＣＭモードの画像送信時、送信する画像データのブロック毎の総パケット数を相手端末に通知する通知手段と、ＥＣＭモードの画像受信時、相手端末より画像データのブロック毎の総パケット数が通知された場合、各ブロックの画像データの受信時、当該画像データの最初のパケットから前記通知された総パケット数のパケットを受信すると、その受信したパケットの所定箇所の内容のデコードを行わない受信手段を備えたものである。
【発明の効果】
【００１７】
したがって、本発明によれば、複数ページ通信時、および、ＥＣＭモードの通信時を含めて、送信側が受信側に送信する画データの総パケット数を通知することにより、受信端末が複数パケットで同じ値が格納されている領域をデコードすることなく画データパケットを処理できるようにすることにより、装置の処理負担を軽減することができるという効果を得る。
【発明を実施するための最良の形態】
【００１８】
以下、添付図面を参照しながら、本発明の実施の形態を詳細に説明する。
【００１９】
図１は、本発明の一実施例にかかる通信システムの一例を示している。
【００２０】
この通信システムでは、送信側のＴ３８端末装置ＴＸと受信側のＴ３８端末装置が、インターネットなどのＩＰ網からなるネットワークＮＷを介して接続されており、Ｔ３８端末装置ＴＸは、ネットワークＮＷを介してＴ３８端末装置ＲＸへ発呼し、Ｔ３８端末装置ＲＸとの間に通信パスを設定し、Ｔ３８通信を行って、送信画情報を送信する。
【００２１】
ここで、Ｔ３８端末装置ＴＸ，ＲＸは、それぞれＩＴＵ−Ｔ勧告Ｔ．３８に規定されている通信プロトコルを適用して、画情報通信を行う機能を備えている。周知のように、呼設定手順については、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）またはＩＴＵ−Ｔ勧告Ｈ．３２３が適用されるとともに、設定された通信パスを用いた通信手順は、ＩＴＵ−Ｔ勧告Ｔ．３８が適用される。なお、ＳＩＰ、勧告Ｈ．３２３および勧告Ｔ．３８などの各勧告等の通信手順や使用される信号等については、周知技術であるので、具体的な説明は省略する。
【００２２】
図２は、Ｔ３８端末装置ＴＸ，ＲＸの構成例を示している。
【００２３】
同図において、システム制御部１は、このＴ３８端末装置ＴＸ，ＲＸの各部の制御処理、および、Ｔ３８通信手順手順処理などの各種制御処理を行うものであり、システムメモリ２は、システム制御部１が実行する制御処理プログラム、および、処理プログラムを実行するときに必要な各種データなどを記憶するとともに、システム制御部１のワークエリアを構成するものであり、パラメータメモリ３は、このＴ３８端末装置ＴＸ，ＲＸに固有な各種の情報（例えば、アドレス帳情報など）を記憶するためのものであり、時計回路４は、現在時刻情報を出力するものである。
【００２４】
スキャナ５は、所定の解像度で原稿画像を読み取るためのものであり、プロッタ６は、所定の解像度で画像を記録出力するためのものであり、操作表示部７は、このＴ３８端末装置ＴＸ，ＲＸを操作するためのもので、各種の操作キー、および、各種の表示器からなる。
【００２５】
符号化復号化部８は、画信号を符号化圧縮するとともに、符号化圧縮されている画情報を元の画信号に復号化するためのものであり、画像蓄積装置９は、符号化圧縮された状態の画情報を多数記憶するためのものである。
【００２６】
ネットワークインターフェース回路１０は、このＴ３８端末装置ＴＸ，ＲＸをネットワークＮＷに接続するためのものであり、ネットワーク伝送制御部１１は、ネットワークＮＷを介して、他のデータ端末装置との間で種々のデータをやりとりするための各種所定のプロトコルスイートの通信制御処理を実行するためのものである。ここで、ネットワークインターフェース回路１０およびネットワーク伝送制御部１１は、上述したＳＩＰ、勧告Ｈ．３２３および勧告Ｔ．３８の各通信手順を実現する手段を構成している。
【００２７】
これらの、システム制御部１、システムメモリ２、パラメータメモリ３、時計回路４、スキャナ５、プロッタ６、操作表示部７、符号化復号化部８、画像蓄積装置９、および、ネットワーク伝送制御部１１は、内部バス１２に接続されており、これらの各要素間でのデータのやりとりは、主としてこの内部バス１２を介して行われている。
【００２８】
図３は、通信パスが設定された後に、設定された通信パスを介して送信側のＴ３８端末装置ＴＸから受信側のＴ３８端末装置ＲＸへ画情報データを送信する際に用いられるＴ３８パケットの構成の一例を示している。なお、同図は、ＵＤＰを用いて通信する場合のＴ３８パケットの構成であるが、ＴＣＰを用いて通信する場合でもＩＦＰパケットは同一構成である。
【００２９】
この場合、画情報データは、数百以上のＩＦＰパケット（インターネットファクシミリプロトコルパケット）に分割して送信される。このＩＦＰパケットは、シーケンス番号（順序番号）、メッセージ種別、データ種別、データなどから構成されている。このうち、シーケンス番号とデータ内容は各パケットで異なる情報が格納されているが、メッセージ種別（例えば、「ｖ１７−１４４００」を表すビット列）や、データ種別（例えば、「ｔ４−ｎｏｎ−ｅｃｍ−ｄａｔａ」を表すビット列）は、全てのＩＦＰパケットで同一の値が格納されている。
【００３０】
このように、画情報データを運ぶ数百のＩＦＰパケットで変わらない情報をエンコード、デコードすることは、Ｔ３８端末装置ＴＸ，ＲＸの処理負担が大きくなり、通信速度に影響を及ぼすことがある。
【００３１】
そこで、本実施例では、送信側のＴ３８端末装置ＴＸから受信側のＴ３８端末装置ＲＸに対して、送信するＩＦＰパケットの総パケット数を通知することで、受信側のＴ３８端末装置ＲＸの処理負担を軽減できるようにしている。
【００３２】
図４は、Ｔ３８端末装置ＴＸからＴ３８端末装置ＲＸにパケット数を通知する際の一例を示している。
【００３３】
この場合、呼制御プロトコルにＳＩＰを用いていており、したがって、ＳＩＰのＩＮＦＯメッセージを利用して、送信側のＴ３８端末装置ＴＸは、受信側のＴ３８端末装置ＲＸに、画情報データを運ぶＩＦＰパケットの総数の通知を行っている。
【００３４】
なお、この画情報データを運ぶＩＦＰパケットの総数の通知は、Ｔ．３８データ送受信手順の中で行ってもよい。
【００３５】
図５は、この場合の受信側のＴ３８端末装置ＲＸの処理の一例を示している。
【００３６】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理１０１）、画データの受信前に送信側のＴ３８端末装置ＴＸから画情報データを運ぶＩＦＰパケットの総パケット数が通知されている場合（判断１０２の結果がＹＥＳ）、Ｔ３８端末装置ＲＸは、２つ目以降、通知されたパケット数番目までの画データパケットに対して、画データパケット内のメッセージ種別とデータ種別が格納されている箇所のデコードを行わない（処理１０３）。
【００３７】
一方、画データの受信前に送信側のＴ３８端末装置ＴＸから画情報データを運ぶＩＦＰパケットの総パケット数が通知されていない場合で、判断１０２の結果がＮＯになるときには、勧告Ｔ．３８どおり画情報データを運ぶＩＦＰパケット内を全てデコード対象とする（処理１０４）。
【００３８】
したがって、この場合、受信側のＴ３８端末装置ＲＸは、ＩＦＰパケットの総パケット数が通知されている場合、１番目のＩＦＰパケットについては、メッセージ種別とデータ種別についてデコードを行うが、２番目以降のＩＦＰパケットについては、メッセージ種別とデータ種別についてデコードを行わないようにしているので、受信側のＴ３８端末装置ＲＸの処理負担を大幅に軽減することができる。
【００３９】
ところで、受信側のＴ３８端末装置ＲＸが、図５に示した機能を備えている場合、送信側のＴ３８端末装置ＴＸは、受信側のＴ３８端末装置ＲＸでデコード処理されないデータ部分について、エンコード処理によりデータを生成するのではなくて、必要な長さの適当なビット列を挿入するようにすると、送信側のＴ３８端末装置ＴＸの処理負担も軽減することができる。
【００４０】
その場合の送信側のＴ３８端末装置ＴＸの処理の一例を図６に示す。
【００４１】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理２０１）、相手端末との間で、本機能の方法に対応しているか否かをネゴシエーションする（処理２０２）。なお、このネゴシエーション手順は、呼制御手順としてＳＩＰを用いる場合、例えば、ＩＮＦＯメッセージのやりとりにより実現することができる。
【００４２】
受信側が本機能の方法に対応している場合には（判断２０２の結果がＹＥＳ）、画情報データを運ぶＩＦＰパケットのうち、１番目については、メッセージ種別とデータ種別をエンコード処理して、その処理結果のデータをセットするとともに、２番目から通知した（総パケット数）番目までのＩＦＰパケットに対しては、ＩＦＰパケット内のメッセージ種別とデータ種別が格納されている箇所のエンコードを行わず、例えば全て０のビット列を挿入する（処理２０４）。
【００４３】
一方、受信側が本機能の方法に対応していない場合で、判断２０２の結果がＮＯになるときには、勧告Ｔ．３８どおり、ＩＦＰパケット内のメッセージ種別とデータ種別が格納されている箇所のエンコードを行う（処理２０５）。
【００４４】
ところで、上述した実施例では、受信側のＴ３８端末装置ＲＸが、図５に示した機能を備えている場合、送信側のＴ３８端末装置ＴＸは、受信側のＴ３８端末装置ＲＸでデコード処理されないデータ部分について、エンコード処理によりデータを生成するのではなくて、必要な長さの適当なビット列を挿入するようにしているが、受信側のＴ３８端末装置ＲＸでデコード処理されないデータ部分については、長さ０のデータを配置する、すなわち、当該データ部分については、何もデータを挿入しないようにすることができる。
【００４５】
この場合、画情報データを運ぶＩＦＰパケットの２番目から最終番目までのＩＦＰパケットのデータ長が、メッセージ種別とデータ種別の分だけ短くなるので、送信側のＴ３８端末装置ＴＸから受信側のＴ３８端末装置ＲＸ４へ送信される画情報データを運ぶＩＦＰパケットのデータ量を大幅に削減することができ、ネットワークＮＷのトラフィックを軽減することができることとなる。
【００４６】
その場合の送信側のＴ３８端末装置ＴＸの処理の一例を図７に示す。
【００４７】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理３０１）、相手端末との間で、本機能の方法に対応しているか否かをネゴシエーションする（処理３０２）。なお、このネゴシエーション手順は、呼制御手順としてＳＩＰを用いる場合、例えば、ＩＮＦＯメッセージのやりとりにより実現することができる。
【００４８】
受信側が本機能の方法に対応している場合には（判断３０２の結果がＹＥＳ）、画情報データを運ぶＩＦＰパケットのうち、１番目については、メッセージ種別とデータ種別をエンコード処理して、その処理結果のデータをセットするとともに、２番目から通知した（総パケット数）番目までのＩＦＰパケットに対しては、ＩＦＰパケット内のメッセージ種別とデータ種別にはデータ長０のデータを挿入する（処理３０４）。
【００４９】
一方、受信側が本機能の方法に対応していない場合で、判断３０２の結果がＮＯになるときには、勧告Ｔ．３８どおり、ＩＦＰパケット内のメッセージ種別とデータ種別が格納されている箇所のエンコードを行う（処理２０５）。
【００５０】
ところで、送信側のＴ３８端末装置ＴＸから実際に送出する画データパケットが、最初にＴ３８端末装置ＴＸから受信側のＴ３８端末装置ＲＸに通知した画データの総パケット数よりも、多くなってしまった場合、Ｔ３８端末装置ＲＸはそのことを知ることができず、エラーにするべきかどうかが判断できない。
【００５１】
そこで、最初に通知された画データの総パケット数よりも多くの画データパケットをＴ３８端末装置ＲＸが受信した場合、Ｔ３８端末装置ＲＸからＴ３８端末装置ＴＸにもう一度画データの総パケット数を通知するように指示を送り、再度、Ｔ３８端末装置ＴＸからＴ３８端末装置ＲＸに画情報データの総パケット数を通知し、画情報データの総パケット数が変更されたことをＴ３８端末装置ＲＸが検知できるようにすることが好ましい。
【００５２】
この場合の受信側のＴ３８端末装置ＲＸの処理の一例を図８に示す。
【００５３】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理４０１）、画データの受信前に送信側のＴ３８端末装置ＴＸから画情報データを運ぶＩＦＰパケットの総パケット数が通知されていない場合（判断４０２の結果がＮＯ）、勧告Ｔ．３８どおり画情報データを運ぶＩＦＰパケット内を全てデコード対象とする（処理４０３）。
【００５４】
また、画データの受信前に送信側のＴ３８端末装置ＴＸから画情報データを運ぶＩＦＰパケットの総パケット数が通知されている場合で、判断４０２の結果がＹＥＳになるときには、Ｔ３８端末装置ＲＸは、２つ目以降、通知されたパケット数番目までの画データパケットに対して、画データパケット内のメッセージ種別とデータ種別が格納されている箇所のデコードを行わない（処理４０４）。
【００５５】
次いで、（総パケット数＋１）番目のパケットのデコード結果が画データのパケット（ＩＦＰパケット）であったかどうかを調べる（判断４０５）。（総パケット数＋１）番目のパケットのデコード結果がＩＦＰパケットであり、判断４０５の結果がＹＥＳになるときには、Ｔ３８端末装置ＲＸは、受信端末は最初に通知された画データパケットの総数よりも、実際に受信した画データパケットの数の方が多いと判断する。
【００５６】
この場合には、実際に受信した画データのパケットの総数を記憶し（処理４０６）、送信側のＴ３８端末装置ＴＸに対して、画データパケットの総パケット数を再送するように要求し（処理４０７）、Ｔ３８端末装置ＴＸより、総パケット数を再度受信する（処理４０８）。
【００５７】
そして、再通知された総パケット数と、処理４０６で得た実際に受信した画データのパケット数とを比較して、それらが一致するかどうかを調べる（判断４０９）。判断４０９の結果がＹＥＳになるときには、この画情報受信動作を正常終了する。一方、判断４０９の結果がＮＯになるときには、この画情報受信動作をエラー終了する（処理４１０）。
【００５８】
また、（総パケット数＋１）番目のパケットのデコード結果が画データのパケットではなかった場合で、判断４０５の結果がＮＯになるときには、最初に通知された画データの総パケット数と、実際に受信した画データの総パケット数が一致する場合であるので、この画情報受信動作を正常終了する。
【００５９】
このようにして、この場合には、受信側のＴ３８端末装置ＲＸが受け取った画データのパケットの総数が、最初に通知された数よりも多かった場合には、Ｔ３８端末装置ＲＸは、Ｔ３８端末装置ＴＸに対して画データのパケット総数の再送を要求し、再送されてきたパケット数と実際に受信した画データのパケット数とを比較して、画情報通信が正常に行われたか否かを判断できるので、画情報通信の信頼性を向上することができる。
【００６０】
図９は、画データパケットの総数を再度通知するシーケンス例を示す。この場合は呼制御プロトコルにＳＩＰを用いていており、したがって、ＳＩＰのＩＮＦＯメッセージを利用して、画データパケットの総数の再送要求と、画データパケットの総数の再通知を行っているが、Ｔ．３８パケット通信手順を用いて総パケット数の再通知を行ってもよい。
【００６１】
ところで、送信側のＴ３８端末装置ＴＸから実際に送出する画データパケットが、最初にＴ３８端末装置ＴＸから受信側のＴ３８端末装置ＲＸに通知した画データの総パケット数よりも、少なくなってしまった場合、Ｔ３８端末装置ＲＸはそのことを知ることができず、エラーにするべきかどうかが判断できない。
【００６２】
そこで、最初に通知された画データの総パケット数よりも少ない数の画データパケットをＴ３８端末装置ＲＸが受信した場合、Ｔ３８端末装置ＲＸからＴ３８端末装置ＴＸにもう一度画データの総パケット数を通知するように指示を送り、再度、Ｔ３８端末装置ＴＸからＴ３８端末装置ＲＸに画情報データの総パケット数を通知し、画情報データの総パケット数が変更されたことをＴ３８端末装置ＲＸが検知できるようにすることが好ましい。
【００６３】
この場合の受信側のＴ３８端末装置ＲＸの処理の一例を図１０に示す。
【００６４】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理５０１）、画データの受信前に送信側のＴ３８端末装置ＴＸから画情報データを運ぶＩＦＰパケットの総パケット数が通知されていない場合（判断５０２の結果がＮＯ）、勧告Ｔ．３８どおり画情報データを運ぶＩＦＰパケット内を全てデコード対象とする（処理５０３）。
【００６５】
また、画データの受信前に送信側のＴ３８端末装置ＴＸから画情報データを運ぶＩＦＰパケットの総パケット数が通知されている場合で、判断５０２の結果がＹＥＳになるときには、Ｔ３８端末装置ＲＸは、２つ目以降、通知された（総パケット数−１）番目までの画データパケットに対して、画データパケット内のメッセージ種別とデータ種別が格納されている箇所のデコードを行わない（処理５０４）。
【００６６】
次いで、（総パケット数）番目のパケットのデコード結果が画データのパケット（ＩＦＰパケット）であったかどうかを調べる（判断５０５）。（総パケット数）番目のパケットのデコード結果がＩＦＰパケットではなく、判断５０５の結果がＮＯになるときには、Ｔ３８端末装置ＲＸは、受信端末は最初に通知された画データパケットの総数よりも、実際に受信した画データパケットの数の方が少ないと判断する。
【００６７】
この場合には、実際に受信した画データのパケットの総数を記憶し（処理５０６）、送信側のＴ３８端末装置ＴＸに対して、画データパケットの総パケット数を再送するように要求し（処理５０７）、Ｔ３８端末装置ＴＸより、総パケット数を再度受信する（処理５０８）。
【００６８】
そして、再通知された総パケット数と、処理５０６で得た実際に受信した画データのパケット数とを比較して、それらが一致するかどうかを調べる（判断５０９）。判断５０９の結果がＹＥＳになるときには、この画情報受信動作を正常終了する。一方、判断５０９の結果がＮＯになるときには、この画情報受信動作をエラー終了する（処理５１０）。
【００６９】
また、（総パケット数）番目のパケットのデコード結果が画データのパケットであり、判断５０５の結果がＮＯになるときには、最初に通知された画データの総パケット数と、実際に受信した画データの総パケット数が一致する場合であるので、この画情報受信動作を正常終了する。
【００７０】
このようにして、この場合には、受信側のＴ３８端末装置ＲＸが受け取った画データのパケットの総数が、最初に通知された数よりも少なかった場合には、Ｔ３８端末装置ＲＸは、Ｔ３８端末装置ＴＸに対して画データのパケット総数の再送を要求し、再送されてきたパケット数と実際に受信した画データのパケット数とを比較して、画情報通信が正常に行われたか否かを判断できるので、画情報通信の信頼性を向上することができる。
【００７１】
ところで、上述したように、受信側のＴ３８端末装置ＲＸが受信したＩＰＦパケット数が、送信側のＴ３８端末装置ＴＸより通知されたパケット総数と一致しなかった場合、Ｔ３８端末装置ＲＸは、Ｔ３８端末装置ＴＸより再度パケット総数を受信するようにしているが、再送されたパケット総数と実際に受信したパケット総数が不一致になって通信エラーを判定したとき、Ｔ３８端末装置ＲＸは、Ｔ３８端末装置ＴＸに対して画情報の再送を要求するようにすることで、通信の信頼性をより向上することができる。
【００７２】
その場合のシーケンス例を図１１に示す。
【００７３】
受信側のＴ３８端末装置ＲＸは、再度通知された画データパケットの総数と、実際に受信した画データパケットの数を比較して数が異なる場合、送信側のＴ３８端末装置ＴＸに対して、再度画データパケットの送信を要求する。
【００７４】
さて、Ｔ３８端末装置ＴＸは、相手端末を指定する際に、あらかじめ登録されているアドレス帳情報（図示略）を参照し、登録された宛先の一覧をユーザに提示して、ユーザがその一覧表示から宛先を簡便な操作で指定することができるアドレス機能を備えている。
【００７５】
そこで、送信側のＴ３８端末装置ＴＸは、受信端末が本機能の方法に対応していることを検知すると、当該宛先のアドレス帳情報についてその旨を登録することで、次回以降の通信時に、本機能の方法に対応しているか否かのネゴシエーションを省略することができるようにすることができる。
【００７６】
このときの処理の一例を図１２に示す。
【００７７】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理６０１）、相手端末との間で、本機能の方法に対応しているか否かをネゴシエーションする（処理６０２）。なお、このネゴシエーション手順は、呼制御手順としてＳＩＰを用いる場合、例えば、ＩＮＦＯメッセージのやりとりにより実現することができる。
【００７８】
受信側が本機能の方法に対応している場合には（判断６０２の結果がＹＥＳ）、そのときの受信側の宛先情報に、本機能の方法に対応している旨の情報を保存する（処理６０３）。
【００７９】
これにより、それ以降、呼制御手順を行う前の段階で、相手端末が本機能の方法に対応していることを確認できるので、次回以降の通信ではネゴシエーション手順を省くことができるため、効率性を向上することができる。
【００８０】
図１３は、Ｔ３８端末装置ＴＸからＴ３８端末装置ＲＸに、ページ毎のパケット数を通知する際の一例を示している。この例では呼制御プロトコルにＳＩＰを用いているが、呼制御プロトコルＨ．３２３や他のプロトコルを用いてもよい。
【００８１】
Ｔ．３８通信フェーズでは、最初に能力交換を行うＤＩＳやＤＣＳの伝送手順信号のやり取りが行われた後、最初のページの画情報（ＰＩＸ）を送信し、その後、最初のページの送受信結果のやり取りを行う（ＭＰＳ，ＭＣＦ）。その後、２ページ目の画情報を送信する。
【００８２】
この例では、画情報を送信する最初のパケットを用いてページ内の総パケット数を通知する。例えば、画情報を送信する最初のパケット内に存在するＩＦＰパケット内の、画情報格納部分の最初の１バイトに、後続する画データの総パケット数を格納して通知する。
【００８３】
なお、上述した例では、画情報パケットを用いてページ内の総パケット数を通知するが、他の信号（ＤＣＳ，ＥＯＭ，ＭＰＳなどの非標準信号等）を用いてページ内の総パケット数を通知してもよい。また、ＥＣＭモードなどのファクシミリ通信モードの詳細、各伝送手順信号の詳細等については、勧告Ｔ．３８（またはＩＴＵ−Ｔ勧告Ｔ．３０）を参照のこと。
【００８４】
図１４に、受信端末が画像データの受信パケットの所定箇所の内容のデコードを行わない機能を備えていることを、ＳＩＰ呼制御メッセージを用いて宣言する場合の一例を示す。
【００８５】
この例に示すように、ＳＩＰメッセージヘッダのＵｓｅｒ−Ａｇｅｎｔヘッダ中に”ｓｐｅｃｉａｌ”という文字列を付加することによって宣言を行う。このヘッダを含めたＳＩＰのＩＮＶＩＴＥメッセージを送信端末から受信端末に送信し、受信端末がＳＩＰの２００  ＯＫメッセージのヘッダを含めることにより、本発明の機能を用いることを確定する。
【００８６】
図１５は、この場合の受信側のＴ３８端末装置ＲＸの処理の一例を示している。
【００８７】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理７０１）、本機能の方法に対応した端末であることを、ネゴシエーションにより確定した場合（判断７０２の結果がＹＥＳ）、Ｔ３８端末装置ＲＸはページ内の１つ目の画データパケットの所定箇所から該当ページの総パケット数を取得し、２つ目以降、通知されたパケット数番目までの画データパケットに対して、画データパケット内のメッセージ種別とデータ種別が格納されている箇所のデコードを行わない。複数ページある場合は、ページ数分、同様の処理を行う（処理７０３，７０４、判断７０５のループ）。
【００８８】
一方、送信側のＴ３８端末装置ＴＸが本機能の方法に対応した端末ではない場合（判断７０２の結果がＮＯ）は、勧告どおり画データパケット内を全てデコード対象とする（処理７０６）。
【００８９】
図１６は、ＥＣＭモードで画像通信する場合の受信側のＴ３８端末装置ＲＸの処理の一例を示している。なお、ＥＣＭモードでは、所定データ長のブロック（ＥＣＭブロック）単位でデータをやりとりする（勧告Ｔ．３８を参照のこと）。
【００９０】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理８０１）、本機能の方法に対応した端末であることを、ネゴシエーションにより確定した場合（判断８０２の結果がＹＥＳ）、Ｔ３８端末装置ＲＸはブロック（ＥＣＭブロック）内の１つ目の画データパケットの所定箇所から該当ブロックの総パケット数を取得し、２つ目以降、通知されたパケット数番目までの画データパケットに対して、画データパケット内のメッセージ種別とデータ種別が格納されている箇所のデコードを行わない。複数ブロックある場合は、ブロック数分、同様の処理を行う（処理８０３，８０４、判断８０５のループ）。
【００９１】
ネゴシエーションの結果、本機能の方法を実施する旨が確定しなかった場合（判断８０２の結果がＮＯ）は、勧告どおり画データパケット内を全てデコード対象とする（処理８０６）。
【００９２】
図１７は、複数ページの通信を行う場合の送信側のＴ３８端末装置ＴＸの処理の一例を示している。
【００９３】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理９０１）、本機能の方法に対応した端末であることを、ネゴシエーションにより確定した場合（判断９０２の結果がＹＥＳ）、送信側のＴ３８端末装置ＴＸは、ページ内の最初の画データパケット内に、そのページで送信予定の画データの総パケット数を格納して送信する（処理９０３）。
【００９４】
そして、２つ目以降、通知した総パケット数番目までの画データパケットに対して画データパケット内のメッセージ種別とデータ種別が格納されている箇所はエンコードを行わず、例えば全て０のビット列を挿入する（処理９０４）。
【００９５】
以上の処理９０３，９０４を、全てのページについて実行する（判断９０５のＮＯループ）。
【００９６】
一方、ネゴシエーションの結果、本機能の方法を実施する旨が確定しなかった場合（判断９０２の結果がＮＯ）は、勧告Ｔ．３８どおり画データパケット内のメッセージ種別とデータ種別が格納されている箇所のエンコードを行う（処理９０６）。
【００９７】
図１８は、ＥＣＭモードで通信を行う場合の送信側のＴ３８端末装置ＴＸの処理の一例を示している。
【００９８】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理１００１）、本機能の方法に対応した端末であることを、ネゴシエーションにより確定した場合（判断１００２の結果がＹＥＳ）、送信側のＴ３８端末装置ＴＸは、ブロック（ＥＣＭブロック）内の最初の画データパケット内に、そのブロックで送信予定の画データの総パケット数を格納して送信する（処理１００３）。
【００９９】
そして、２つ目以降、通知した総パケット数番目までの画データパケットに対して画データパケット内のメッセージ種別とデータ種別が格納されている箇所はエンコードを行わず、何も情報を挿入しない（処理１００４）。
【０１００】
以上の処理１００３，１００４を、全てのページについて実行する（判断１００５のＮＯループ）。
【０１０１】
一方、ネゴシエーションの結果、本機能の方法を実施する旨が確定しなかった場合（判断１００２の結果がＮＯ）は、勧告Ｔ．３８どおり画データパケット内のメッセージ種別とデータ種別が格納されている箇所のエンコードを行う。
【０１０２】
ところで、送信側のＴ３８端末装置ＴＸから実際に送出する画データパケットが、最初にＴ３８端末装置ＴＸから受信側のＴ３８端末装置ＲＸに通知した画データの総パケット数よりも、多くなってしまった場合、Ｔ３８端末装置ＲＸはそのことを知ることができず、エラーにするべきかどうかが判断できない。
【０１０３】
そこで、最初に通知された画データの総パケット数よりも多くの画データパケットをＴ３８端末装置ＲＸが受信した場合、Ｔ３８端末装置ＲＸからＴ３８端末装置ＴＸにもう一度画データの総パケット数を通知するように指示を送り、再度、Ｔ３８端末装置ＴＸからＴ３８端末装置ＲＸに画情報データの総パケット数を通知し、画情報データの総パケット数が変更されたことをＴ３８端末装置ＲＸが検知できるようにすることが好ましい。
【０１０４】
この場合の受信側のＴ３８端末装置ＲＸの処理の他の例を図１９に示す。
【０１０５】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理１１０１）、本機能の方法に対応した端末でないことをネゴシエーションにより確定した場合（判断１１０２の結果がＮＯ）、勧告どおり画データパケット内を全てデコード対象とする（処理１１０３）。
【０１０６】
一方、本機能の方法に対応した端末であることを、ネゴシエーションにより確定した場合（判断１１０２の結果がＹＥＳ）、Ｔ３８端末装置ＲＸはページ内の１つ目の画データパケットの所定箇所から該当ページの総パケット数を取得し、２つ目以降、通知されたパケット数番目までの画データパケットに対して、画データパケット内のメッセージ種別とデータ種別が格納されている箇所のデコードを行わない。複数ページある場合は、ページ数分、同様の処理を行う（処理１１０４）。
【０１０７】
そして、その次のパケットのデコード結果が、画データパケットである場合（判断１１０５の結果がＹＥＳ）、受信端末は最初に通知された画データパケットの総数よりも、実際に受信した画データパケットの数の方が多いと判断する。
【０１０８】
この場合には、実際に受信した画データのパケットの総数を記憶し（処理１１０６）、送信側のＴ３８端末装置ＴＸに対して、画データパケットの総パケット数を再送するように要求し（処理１１０７）、Ｔ３８端末装置ＴＸより、総パケット数を再度受信する（処理１１０８）。
【０１０９】
そして、再通知された総パケット数と、処理１１０６で得た実際に受信した画データのパケット数とを比較して、それらが一致するかどうかを調べる（判断１１０９）。判断１１０９の結果がＹＥＳになるときには、この画情報受信動作を正常終了する。一方、判断１１０９の結果がＮＯになるときには、この画情報受信動作をエラー終了する（処理１１１０）。
【０１１０】
また、（総パケット数＋１）番目のパケットのデコード結果が画データのパケットではなかった場合で、判断１１０５の結果がＮＯになるときには、最初に通知された画データの総パケット数と、実際に受信した画データの総パケット数が一致する場合であるので、この画情報受信動作を正常終了する。
【０１１１】
このようにして、この場合には、受信側のＴ３８端末装置ＲＸが受け取った画データのパケットの総数が、最初に通知された数よりも多かった場合には、Ｔ３８端末装置ＲＸは、Ｔ３８端末装置ＴＸに対して画データのパケット総数の再送を要求し、再送されてきたパケット数と実際に受信した画データのパケット数とを比較して、画情報通信が正常に行われたか否かを判断できるので、画情報通信の信頼性を向上することができる。
【０１１２】
なお、画データパケットの総数を再度通知する手順については、図９を参照のこと。
【０１１３】
ところで、送信側のＴ３８端末装置ＴＸから実際に送出する画データパケットが、最初にＴ３８端末装置ＴＸから受信側のＴ３８端末装置ＲＸに通知した画データの総パケット数よりも、少なくなってしまった場合、Ｔ３８端末装置ＲＸはそのことを知ることができず、エラーにするべきかどうかが判断できない。
【０１１４】
そこで、最初に通知された画データの総パケット数よりも少ない数の画データパケットをＴ３８端末装置ＲＸが受信した場合、Ｔ３８端末装置ＲＸからＴ３８端末装置ＴＸにもう一度画データの総パケット数を通知するように指示を送り、再度、Ｔ３８端末装置ＴＸからＴ３８端末装置ＲＸに画情報データの総パケット数を通知し、画情報データの総パケット数が変更されたことをＴ３８端末装置ＲＸが検知できるようにすることが好ましい。なお、その場合のシーケンス例は、図１１を参照のこと。
【０１１５】
この場合の受信側のＴ３８端末装置ＲＸの処理の一例を図２０に示す。
【０１１６】
呼制御メッセージのやりとりを行って、呼設定が終了した後（処理１１０１）、本機能の方法に対応した端末でないことをネゴシエーションにより確定した場合（判断１１０２の結果がＮＯ）、勧告どおり画データパケット内を全てデコード対象とする（処理１１０３）。
【０１１７】
一方、本機能の方法に対応した端末であることを、ネゴシエーションにより確定した場合（判断１１０２の結果がＹＥＳ）、Ｔ３８端末装置ＲＸは、２つ目以降、通知された（総パケット数−１）番目までの画データパケットに対して、画データパケット内のメッセージ種別とデータ種別が格納されている箇所のデコードを行わない（処理１２０４）。
【０１１８】
次いで、（総パケット数）番目のパケットのデコード結果が画データのパケット（ＩＦＰパケット）であったかどうかを調べる（判断１２０５）。（総パケット数）番目のパケットのデコード結果がＩＦＰパケットではなく、判断１２０５の結果がＮＯになるときには、Ｔ３８端末装置ＲＸは、受信端末は最初に通知された画データパケットの総数よりも、実際に受信した画データパケットの数の方が少ないと判断する。
【０１１９】
この場合には、実際に受信した画データのパケットの総数を記憶し（処理１２０６）、送信側のＴ３８端末装置ＴＸに対して、画データパケットの総パケット数を再送するように要求し（処理１２０７）、Ｔ３８端末装置ＴＸより、総パケット数を再度受信する（処理１２０８）。
【０１２０】
そして、再通知された総パケット数と、処理１２０６で得た実際に受信した画データのパケット数とを比較して、それらが一致するかどうかを調べる（判断１２０９）。判断１２０９の結果がＹＥＳになるときには、この画情報受信動作を正常終了する。一方、判断１２０９の結果がＮＯになるときには、この画情報受信動作をエラー終了する（処理１２１０）。
【０１２１】
また、（総パケット数）番目のパケットのデコード結果が画データのパケットであり、判断１２０５の結果がＮＯになるときには、最初に通知された画データの総パケット数と、実際に受信した画データの総パケット数が一致する場合であるので、この画情報受信動作を正常終了する。
【０１２２】
このようにして、この場合には、受信側のＴ３８端末装置ＲＸが受け取った画データのパケットの総数が、最初に通知された数よりも少なかった場合には、Ｔ３８端末装置ＲＸは、Ｔ３８端末装置ＴＸに対して画データのパケット総数の再送を要求し、再送されてきたパケット数と実際に受信した画データのパケット数とを比較して、画情報通信が正常に行われたか否かを判断できるので、画情報通信の信頼性を向上することができる。
【０１２３】
なお、上述した実施例では、呼制御手順（呼設定手順）として、ＳＩＰを適用した場合について説明したが、ＩＴＵ−Ｔ勧告Ｈ．３２３を適用した場合であっても、本発明を同様にして適用することができる。また、実施の形態で説明したものに限定されず、これらと均等な手法も本発明の技術的範囲に含まれる。
【図面の簡単な説明】
【０１２４】
【図１】本発明の一実施例にかかる通信システムの一例を示したブロック図。
【図２】Ｔ３８端末装置ＴＸ，ＲＸの構成例を示したブロック図。
【図３】通信パスが設定された後に、設定された通信パスを介して送信側のＴ３８端末装置ＴＸから受信側のＴ３８端末装置ＲＸへ画情報データを送信する際に用いられるＴ３８パケットの構成の一例を示した概略図。
【図４】Ｔ３８端末装置ＴＸからＴ３８端末装置ＲＸにパケット数を通知する際の一例を示したシーケンス図。
【図５】Ｔ３８端末装置ＲＸの処理の一例を示したフローチャート。
【図６】Ｔ３８端末装置ＴＸの処理の一例を示したフローチャート。
【図７】Ｔ３８端末装置ＴＸの処理の他の例を示したフローチャート。
【図８】Ｔ３８端末装置ＲＸの処理の他の例を示したフローチャート。
【図９】画データパケットの総数を再度通知する手順の一例を示したシーケンス図。
【図１０】Ｔ３８端末装置ＲＸの処理のさらに他の例を示したフローチャート。
【図１１】画データパケットの総数を再度通知した後、画データパケットを再送する手順の一例を示したシーケンス図。
【図１２】Ｔ３８端末装置ＴＸの処理の別の例を示したフローチャート。
【図１３】Ｔ３８端末装置ＴＸからＴ３８端末装置ＲＸに、ページ毎のパケット数を通知する際の一例を示したシーケンス図。
【図１４】ＳＩＰメッセージヘッダの一例を示した概略図。
【図１５】Ｔ３８端末装置ＲＸの処理の別の例を示したフローチャート。
【図１６】Ｔ３８端末装置ＲＸの処理のさらに別の例を示したフローチャート。
【図１７】Ｔ３８端末装置ＴＸの処理の別の例を示したフローチャート。
【図１８】Ｔ３８端末装置ＴＲＸの処理のさらに別の例を示したフローチャート。
【図１９】Ｔ３８端末装置ＲＸの処理のまたさらに別の例を示したフローチャート。
【図２０】Ｔ３８端末装置ＲＸの処理のまたさらに別の例を示したフローチャート。
【符号の説明】
【０１２５】
ＴＸ，ＲＸ  Ｔ３８端末装置
【図１】
2010035123.tif 000003
【図２】
2010035123.tif 000004
【図３】
2010035123.tif 000005
【図４】
2010035123.tif 000006
【図５】
2010035123.tif 000007
【図６】
2010035123.tif 000008
【図７】
2010035123.tif 000009
【図８】
2010035123.tif 000010
【図９】
2010035123.tif 000011
【図１０】
2010035123.tif 000012
【図１１】
2010035123.tif 000013
【図１２】
2010035123.tif 000014
【図１３】
2010035123.tif 000015
【図１４】
2010035123.tif 000016
【図１５】
2010035123.tif 000017
【図１６】
2010035123.tif 000018
【図１７】
2010035123.tif 000019
【図１８】
2010035123.tif 000020
【図１９】
2010035123.tif 000021
【図２０】
2010035123.tif 000022