(57)【要約】【課題】  音声データ通信とファクシミリデータ通信とを同時に実行する場合に、音声データ通信を優先して実行して、音声データの転送遅延による音質の低下を防止した通信処理を効率よく行うことである。【解決手段】  ＩＰＦＡＸ送信タスクが起動中でないと判断した場合は、Ｓ１６０７で、コントローラ部１３１がネットワークを介して送信すべき送信データが送信バッファ部１３０２−１に一定量以上格納されているかを判断する。ここで、一定量の送信データが格納されていると判断した場合は、Ｓ１６０８で、送話すべき音声データの送信にウエイトをかける。Ｓ１６０７で、一定量の送信データが格納されていないと判断した場合は、Ｓ１６０９で、送信バッファ部１３０２−１に記憶される送信データの送話起動をＯＫとする構成を特徴とする。【選択図】  図１７
2008131444.tif 000002
【特許請求の範囲】
【請求項１】
インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置であって、
前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する受信バッファと、
前記受信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定手段と、
前記決定手段により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記受信バッファに記憶された前記音声データの受信処理を優先させる通信制御手段と、
を有することを特徴とするデータ通信装置。
【請求項２】
前記通信制御手段は、前記受信バッファに記憶された前記ファクシミリデータの処理開始を遅延させて、前記受信バッファに記憶された前記音声データの受信処理を優先させることを特徴とする請求項１記載のデータ通信装置。
【請求項３】
前記受信バッファは、優先順位の異なるバッファ部を複数備え、
受信する前記音声データを前記優先順位の高いいずれかのバッファ部に転送する転送制御手段を備え、
前記通信制御手段は、前記優先順位の高いいずれかのバッファ部に転送された音声データの受信処理を優先させることを特徴とする請求項１記載のデータ通信装置。
【請求項４】
前記決定手段は、前記インターネット網を介して相手装置から受信するパケットを解析して、受信した音声データを前記優先順位の高いいずれかのバッファ部に転送することを特徴とする請求項１または３のいずれかに記載のデータ通信装置。
【請求項５】
インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置であって、
前記インターネット網を介して相手装置との通信により音声通信に基づく音声データまたはファクシミリ通信に基づくファクシミリデータを記憶する受信バッファと、
前記受信バッファにファクシミリデータが一定量記憶された状態に遷移しているかどうかを判別する判別手段と、
前記判別手段により前記受信バッファに前記ファクシミデータが一定量記憶されていると判別した場合に、前記音声データの通話要求の起動を制限させる通信制御手段と、
を有することを特徴とするデータ通信装置。
【請求項６】
前記判別手段により前記受信バッファに前記ファクシミデータが一定量記憶されていると判別した場合に、通話要求を待機させるメッセージを表示する表示手段を有することを特徴とする請求項１〜５のいずれかに記載のデータ通信装置。
【請求項７】
インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置であって、
前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する送信バッファと、
前記送信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定手段と、
前記決定手段により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記送信バッファに記憶された前記音声データの送信処理を優先させる通信制御手段と、
を有することを特徴とするデータ通信装置。
【請求項８】
インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置におけるデータ通信方法であって、
前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する受信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定工程と、
前記決定工程により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記受信バッファに記憶された前記音声データの受信処理を優先させる通信制御工程と、
を有することを特徴とするデータ通信方法。
【請求項９】
前記通信制御工程は、前記受信バッファに記憶された前記ファクシミリデータの処理開始を遅延させて、前記受信バッファに記憶された前記音声データの受信処理を優先させることを特徴とする請求項８記載のデータ転送方法。
【請求項１０】
優先順位の異なるバッファ部を複数備える受信バッファは、
優先順位の異なるバッファ部を複数備える受信バッファのうち、受信する前記音声データを前記優先順位の高いいずれかのバッファ部に転送する転送制御工程を備え、
前記通信制御工程は、前記優先順位の高いいずれかのバッファ部に転送された音声データの受信処理を優先させることを特徴とする請求項８記載のデータ通信方法。
【請求項１１】
前記決定工程は、前記インターネット網を介して相手装置から受信するパケットを解析して、受信した音声データを前記優先順位の高いいずれかのバッファ部に転送することを特徴とする請求項８または１０のいずれかに記載のデータ通信方法。
【請求項１２】
インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置におけるデータ通信方法であって、
前記インターネット網を介して相手装置との通信により音声通信に基づく音声データまたはファクシミリ通信に基づくファクシミリデータを記憶する受信バッファにファクシミリデータが一定量記憶された状態に遷移しているかどうかを判別する判別工程と、
前記判別工程により前記受信バッファに前記ファクシミデータが一定量記憶されていると判別した場合に、前記音声データの通話要求の起動を制限させる通信制御工程と、
を有することを特徴とするデータ通信方法。
【請求項１３】
前記判別工程により前記受信バッファに前記ファクシミデータが一定量記憶されていると判別した場合に、通話要求を待機させるメッセージを表示手段に表示する表示工程を有することを特徴とする請求項１２に記載のデータ通信方法。
【請求項１４】
インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置におけるデータ通信方法であって、
前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する送信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定工程と、
前記決定工程により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記送信バッファに記憶された前記音声データの送信処理を優先させる通信制御工程と、
を有することを特徴とするデータ通信方法。
【請求項１５】
請求項８〜１４のいずれかに記載のデータ通信方法をコンピュータに実行させるためのプログラムを格納したことを特徴とするコンピュータが読み取り可能な記憶媒体。
【請求項１６】
請求項８〜１４のいずれかに記載のデータ通信方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像データおよび音声データとを同時に送受信可能なデータ通信装置における音声データの通信処理に関するものである。
【背景技術】
【０００２】
従来、インターネット関連技術により、インターネット網（ＩＰ通信網）を介したパケット通信を利用して音声データと画像データとをやり取り可能なＩＰ通信システムが提案されている。
【０００３】
下記特許文献１には、ＩＰ通信網における音声セッションとファクシミリデータセッションを同時に確率するＨ．３２３環境下でセッションを使い分けることが記載されている。
【０００４】
さらに、下記特許文献２には、テレビ電話において、通信品質を敢えて下げることで通信料金を低くできるシステムが記載されている。この際、オン制御データと映像データとで優先度を付けてデータ通信することが記載されている。
【０００５】
図３４は、この種のIP電話システムの全体構成を説明する図である。以下、図３４を参照して、ＩＰ電話通信における音の劣化の要因について説明する。
【０００６】
図３４において、３はインターネットプロトコルネットワーク（IPネットワーク）で、相互にルータ２，４を介してＩＰ電話機１、５と通話可能に接続する。また、IPネットワーク３は、ルータ８、９を介してＶＯＩＰゲートウエイ７、１０を介していわゆるアナログ電話機６、１１と通信可能に接続する。
【０００７】
ここで、アナログ電話機６、１１は、公衆電話回線（PSTN（Public Switched telephone Network））とも通話可能である。
【０００８】
どのデータ処理が必要であるが、これらの処理の遅れに起因する遅延が発生する場合がある。
【０００９】
特に、図３４のように構成されたＩＰ電話システムにおいて、ネットワーク上の伝送遅延が発生する。具体的には、ルータ２，４，８，９を介するため、データ通信において内部遅延が発生する。すなわち、詳細は後述するキューイングによりデータ通信において遅延が発生する。
【００１０】
また、VOIPゲートウエイ７，１０あるいはＩＰ電話機１，５との受話処理では、音声復号化処理で生じる遅延、ゆらぎ吸収バッファによる遅延が発生する。
【００１１】
ここで、従来技術としてある網側の優先制御と端末装置側の音声データの優先制御との違いについて説明する。
【００１２】
網側の優先制御は、入力してくるパケットを解析して、優先するキューに入れる。入力してくるパケットを止めるわけではない。その様子を図３５に示す。
【００１３】
図３５は、図３４に示したルータ２，４，８、９のキュー機能を説明するブロック図である。なお、網側での優先制御では、優先制御に必要となるルータ、スイッチでの要素が存在する。以下これに関して説明する。
【００１４】
図３５において、２２〜２５はキューで、音声データを保持する。現在キュー２２は、音声データ２６〜２８を保持している。また、現在キュー２３は、音声データ２９を保持している。さらに、現在キュー２４は、音声データ３０を保持している。また、現在キュー２５は、音声データ３１を保持している。
【００１５】
２１はパケット入力インタフェースである。３２は出力インタフェースである。
【００１６】
図３５に示すように、ルータ２，４，８、９は、図３５のように入力するパケットを識別するパケット識別手段を備える。さらに、図中２１のパケット入力インタフェースでのパケット識別手段と入力パケットを参照して各キューに振り分ける手段と複数のキューが必要である。
【００１７】
ルータ２，４，８、９は、キュー２２〜２５を備える。ここでは、各キュー２２〜２５に対して、この順で優先度１〜４が割り当てられているものとする。なお、優先度を区別する数だけキューも必要である。
【００１８】
また、キューイングアルゴリズムも必要であり、各キュー２２〜２５に振り分けられたパケットを出力する方法も必要である。
【００１９】
さらに、優先制御をもつルータ、LANスイッチは、先に到着したWEBアクセスのパケットを破棄しても音声パケットを優先させる手段を有するものもある。
【００２０】
ただし、音声データが第１優先のキュー２２に示すように、同じ優先順位の音声データ２６〜２８が複数溜まる場合、データ転送遅延あるいはデータの破棄が起こり得る状態となる。つまり、網側で遅延、データ破棄の発生する箇所としては、トラフィックが集中するところでは、多くのインタフェースから入力されたトラフィックで出力が限られているため、いくら優先制御をしても限界がある。
【特許文献１】特開２００４−９６３２６号公報
【特許文献２】特開平６−１４１５１号公報
【発明の開示】
【発明が解決しようとする課題】
【００２１】
図３６は、図３４に示したＶＯＩＰゲートウエイ７のネットワークレイアを説明する図である。
【００２２】
図３６において、レイヤ７１のフィールド７２においては、音声パケットを識別するのにＣＯＳフィールを使用する。ここで、ＣＯＳは、CLASS OF SERVICEの略である。正式には、USER PRIORITYと呼ばれる。３ビットのデータである。この値が大きい方が優先的に扱われる。
【００２３】
レイヤ７３のフィールド７４においては、IPアドレスで音声とデータを区別するのにTOS（TYPE OF SERVICE）を使用する。RFC1349により定義されるIPプレ全素フィールドでは、上位３ビットを優先度を示すフィールドに使用する。又、RFC2474で定義されるDSCP（DIFFERENTIATED SERVICES CODE POINT）では、TOSフィールドの上位６ビットを優先度の指定に用いる。
【００２４】
レイヤ７５のフィールド７６では、TCP,UDPのポート番号を使う。代表的なアプリケーションを特定できる。ポート番号が５０６０ならばSIPなのでIP電話の制御信号を優先的に処理できる。
【００２５】
ただし、IP電話ではRTPパケットを優先する必要があるが、RTPでは、通話毎にUDPのポート番号がダイナミックに割り当てられるので難しい。
【００２６】
次に、揺らぎ吸収バッファに関して述べる。
【００２７】
ＩＰ電話機１等あるいはＶＯＩＰゲートウエイ７等では、受話データのジッタを吸収するための揺らぎ吸収バッファが必要である。
【００２８】
なお、図３４に示すデータ通信装置には、受信側IP電話機には揺らぎ吸収バッファ（ジッタバッファ）が用意されている。アナログ電話の場合はゲートウエイ内に揺らぎ吸収バッファが存在する。
【００２９】
これは、受信した音声パケットを一時的に溜めて不規則なパケット間隔を等間隔に補正できるようにする。RTPヘッダのタイムスタンプをみて本来のパケット間隔でアナログ信号に戻す。
【００３０】
このように、揺らぎ吸収バッファは、受信パケットのパケット間隔を統計的に計算しその計算結果から動的にバッファリングするパケット数を変える。そのため、揺らぎが大きい状態が続くとバッファで発生する遅延も大きくなる。バッファで救済できない大きな揺らぎが発生するとパケットを破棄する。
【００３１】
一般的には１００ｍｓ程度のバッファを用意していて、図３４に示す例では、そろったところでＶＯＩＰゲートウエイ７の場合は、アナログ電話機６にデータをおくる。その時間を過ぎると破棄する。このバッファ量が大きいと破棄は少なくなるが遅延が大きくなり違和感が大きくなる。
【００３２】
なお、IP電話の規格では、トータルの遅延時間を150ms以内にするように求めている。
【００３３】
従って、仮にゆらぎ吸収バッファテで100msの遅延が発生すると、それ以外のところでの遅延を５０ｍS以内に抑えないといけない。音声データは20mS間隔で送出される。
【００３４】
したがって、ここでも最大２０ｍSの遅延が発生する。それを差し引くと、それ以外の遅延は、３０ｍS以内に抑えないといけない。この場合、３０ｍｓを超えるとデータは破棄され，音声の音とびの原因となる。
【００３５】
従来のデータ通信装置は上記のように構成されているので、特に音声データ通信（ＩＰ電話）と、ファクシミリデータ通信（Ｔ．３８）とを同時に処理する場合、データ処理負荷が高まることで、音声データの通信を正常に行えない状態に遷移するという問題点があった。なお、Ｔ．３８とは、ＩＴＵ−Ｔ勧告Ｔ．３８に従ったリアルタイム型インターネットファクシミリ通信のことを示す。
【００３６】
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、音声データ通信とファクシミリデータ通信とを同時に実行する場合に、音声データ通信を優先して実行できる仕組みを提供することである。
【課題を解決するための手段】
【００３７】
上記目的を達成する本発明のデータ通信装置は以下に示す構成を備える。
【００３８】
インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置であって、前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する受信バッファと、前記受信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定手段と、前記決定手段により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記受信バッファに記憶された前記音声データの受信処理を優先させる通信制御手段とを有することを特徴とする。
【００３９】
上記目的を達成する本発明のデータ通信方法は以下に示す構成を備える。
【００４０】
インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置におけるデータ通信方法であって、前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する受信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定工程と、前記決定工程により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記受信バッファに記憶された前記音声データの受信処理を優先させる通信制御工程とを有することを特徴とする。
【発明の効果】
【００４１】
本発明によれば、音声データ通信とファクシミリデータ通信とを同時に実行する場合に、音声データ通信を優先して実行して、音声データの転送遅延による音質の低下を防止した通信処理を効率よく行える。
【発明を実施するための最良の形態】
【００４２】
次に本発明を実施するための最良の形態について図面を参照して説明する。
【００４３】
＜システム構成の説明＞
〔第１実施形態〕
図１は、本発明の第１実施形態を示すデータ通信装置を適用する複合機の構成を説明するブロック図である。本例は、複合機のうち、画像入力部と、画像出力部、画像入力部と、画像出力部を制御するコントローラ部については、省略してある。また、本例のデータ通信装置は、ＩＰ網を介して音声データ通信と、ファクシミリデータ通信とを同時に行う機能を備える。なお、この際、ファクシミデータ通信は、Ｔ．３８プロトコルによるものである。また、このＴ．３８プロトコルによるファクシミリデータ通信は、図示しないゲートウエアを介して、Ｇ３ファクシミ装置と通信可能な場合も含む。
【００４４】
図１において、４１は音声を入力する音声入力手段で、例えばハンドセットあるいはマイクにより構成される。なお、入力される音声データは、ＩＰ網にパケット送信するために、音声符号化処理が行われる。
【００４５】
４２は音声符号器で、入力した音声を、G.７１１等の音声符号化データに変換する。４３はRTPを付加あるいは解析するRTP手段である。ここで、RTPとは、Real-Time Transport Protocolである。４４はバッファで、音声符号器４２からの符号化データを一旦蓄えて、RTPを付加してSDRAM６へ送る。
【００４６】
４５はゆらぎ吸収バッファで、RTP情報の付加された相手通話装置からの音声符号化データを、RTP情報に基づいて並べ替え音声復号器５０へ送る。
【００４７】
なお、ゆらぎ吸収バッファ４５を備えず、ＳＤＲＡＭ４６の受信バッファに通信データを記憶する構成であってもよい。
【００４８】
４６はSDRAMで、メモリコントローラ２１へ送るデータあるいはメモリコントローラ２１からのデータを蓄積する。SDRAM４６は、シングルのＳＤＲＡＭでもよいし、ＤＤＲ，ＤＤＲ２等のスループットを上げたメモリでも良い。
【００４９】
また、SDRAM４６は、クロック同期式入出力であり、コマンド、データの入出力が、クロック信号に同期して行われるため、クロック信号以外の信号を考慮する必要はない。又、クロックの周波数でメモリアクセスのパフォーマンスがきまる。さらに、ＳＤＲＡＭ４６のアクセスは、バースト転送も可能である。例えばリードライトコマンドでスタートアドレスを与えたあとは、自動的にアドレスをインクリメントしてデータを連続的に出力することによりバスの負荷を下げ、より高速なデータ転送が可能となる。
【００５０】
ここで、コマンドは、/RAS,CAS, /WE  の３本の信号の組み合わせと/CS、/CSEの選択により各種コマンドにより動作が制御される。独立バンク構造も取ることが可能である。独立バンク構造は、複数のDRAMが内部に存在するかの様にふるまう。ただし、共有している回路の関係で一部制限事項がある。
【００５１】
４７は送信データ群で、SDRAM４６内に蓄積され、ネットワークへと送出される。４８は受信データ群で、ネットワークから受信したデータであってSDRAM４６内に蓄積される。
【００５２】
４９は音声出力手段で、ハンドセットやスピーカ等により構成される。５０は音声複号機で、G.７１１等の符号化された音声データを複号化する。
【００５３】
５１はJBIGデータで、画像メモリ５２に記憶される。なお、画像メモリ５２は、ハードディスクあるいは、SDRAM等の半導体メモリにより構成される。
【００５４】
５３は複号器で、JBIGデータ５１をRAWデータあるいは中間データに複号化する。５４は符号化ブロックで、画像データを相手ファクシミリ装置の符号化方式、例えばＭＭＲに合わせて符号化する。
【００５５】
５５は符号化ブロックで、自機のメモリ蓄積方式,例えば、ＪＢＩＧに符号化する。５６は複号化ブロックで、相手送信ファクシミリ装置からの例えばＭＨ符号化された画像データを複号化する。５７はＭＭＲデータで、相手受信ファクシミリ装置に合わせた符号化方式に基づく送信データである。
【００５６】
５８は送信データで、ＭＭＲデータ５７に、ネットワークを介して相手受信機に画像データを送るための各種ヘッダを付加された送信データである。
【００５７】
５９はＭＨデータ、相手受信機から受信した画像データである。６０は受信データで、画像データ１９に各種ヘッダが付加されたデータである。
【００５８】
６１はメモリコントローラ（ＭＥＭＣ）で、ＳＤＲＡＭ４６のメモリアクセスを制御する。画像メモリ５２がＳＤＲＡＭの場合、ＭＥＭＣ６１によりアクセスが制御可能である。
【００５９】
また、バッファ４４，ゆらぎ吸収バッファ４５、バッファメモリ６５，６６がSDRAM４６内に格納される場合、ＭＥＭＣ６１がこれらのメモリ資源に対するアクセスを制御することも可能である。
【００６０】
なお、画像メモリ５２，バッファ４４，ゆらぎ吸収バッファ４５，バッファメモリ６５，６６は、物理的に一つの場合も考えられる。
【００６１】
このように複数の機能に使用されるメモリは、他の機能のバス占有率、あるいはメモリコントローラ６１の影響により、すなわち、SDRAM４６のクロックでパフォーマンスする。
【００６２】
６２はネットワークコントローラで、ネットワークにパケットを送り、あるいは受けネットワークアクセスを制御する。
【００６３】
６３はネットワークの物理層を制御するPHYである。６４はプロトコル制御手段で、SIPとT.38のプロトコルを制御する。６５はバッファメモリで、復号器５３で一旦複号化されたデータを一時蓄える。６６はバッファメモリで、復号器５６で一旦複号化されたデータを一時蓄える。
【００６４】
復号器５３〜５６は、例えば、送信側ハードコーデック、受信側ソフトコーデックであったり、送受共にソフトコーデックであったりと、装置によってソフト／ハードコーデックのバリエーションがある。ソフトコーデックの場合は，特に多重処理時のCPUの負荷が増える。
【００６５】
このように構成された画像形成装置において、ゆらぎ吸収バッファ４５が受話データのジッタを吸収するデバイスとして機能する。
【００６６】
このように構成されたデータ通信装置は、音声信号を符号化し、該音声符号化データをネットワークを介して相手装置に伝送し、該相手装置でリアルタイムに再生することを可能とする。
【００６７】
そして、該相手装置からの符号化された音声データを、該ネットワークを介して受信し、リアルタイムに再生する。
【００６８】
また、本実施形態に示すデータ通信装置は、該音声符号化データの通信と同時に該ネットワークを介してのファクシミリ通信が可能である。
【００６９】
そこで、例えばファクシミリ送信のための送信データをネットワークに送信するためのメモリに、該ファクシミリデータが待行列（以下キュー）として蓄積されている状態が発生する。そのような時に、該符号化された音声データを一定間隔でネットワークに送出できない場合は、該音声信号の符号化および音声データをネットワーク送信するための該メモリへの転送動作を起動しないように制御する。なお、本制御は、図６に示すフローチャートを参照して詳述する。
【００７０】
なお、本実施形態を示すデータ通信装置は、ネットワークを介した通信プロトコルは、ＳＩＰで、ファクシミリ送信のプロトコルは、ＩＴＵ−Ｔ  Ｔ．３８も可能に構成されているものとする。
【００７１】
図２は、本実施形態を示すデータ通信装置を適用する画像形成装置のデータ通信制御部の構成を説明するブロック図である。本例は、データ通信装置におけるSIPによるIP電話とT.38  FAX通信の多重化したデータ通信例である。
【００７２】
図２において、２００１は相手複合機すなわちMFPであり、２のT.38のFAX機能処理部２００２とIPによるIP電話機能処理部２００３を有する。
【００７３】
２００４，２００５はSIPプロキシである。SIPはプロキシを立てないで通信することも可能である。ここでは、SIPプロキシ２００４，２００５を立てている。
【００７４】
２００６は画像形成装置で、例えば複合機（MFP）で構成される例である。なお、画像形成装置２００６は、ネットワークコントローラを備え、ネットワークを介して相手機である外部の画像形成装置やファクシミ装置と多重の通信あるいは通話を行うことが可能である。２００７はプロトコル群で、画像形成装置２００６と画像形成装置２００１がSIP通話を行う場合のSIPのセッション例である。
【００７５】
ここで、プロトコル群２００７において、INVITEは、呼出を要求する信号である。TRYINGは、処理中であることを伝える信号である。RINGINGは、呼出音を要求する信号である。OKは、受話器を取ったことを伝える信号である。ACKは、了解したことを伝える信号である。通話セッションは、ITU-T  G.711のPCM符号化方式など則った音声符号化データをやり取りするセッションである。
【００７６】
２００８はSIPプロトコル群で、プロトコル群２００７と同時に画像形成装置２００１とT.３８プロトコルに基づいたネットワークFAX通信を行う為のプロトコルで構成される。
【００７７】
実際には、INVITE等のプロトコル信号は、SIPプロキシを経由して通信しているが、細かいところは省略している。
【００７８】
SIPプロトコル群２００８において、INVITEは、呼出を要求する信号である。OKは、受話器を取ったことを伝える信号である。ACKは、了解したことを伝える信号である。T.38  FAXセッションは、MH（モディファイド  ハフマン）、MR(モディファイドリード)等の符号化データを、ITU-T  T.38に基づいて通信するファクシミリセッションである。なお、T.38  FAXセッションは、MH（モディファイド  ハフマン）、MR(モディファイドリード)等の符号化データを、ITU-T  T.38に基づいて通信するファクシミリセッションである。
【００７９】
２００９はT.38  ファクシミリ装置で、T.38プロトコルに基づいてネットワークを介してファクシミリ通信する。
【００８０】
２０１０はSIPプロトコル群で、T.38  ファクシミリ装置２００９とT.３８に基づいたFAX通信を行う為のプロトコルである。
【００８１】
SIPプロトコル群２０１０において、INVITEは、呼出を要求する信号である。RINGINGは、呼出音を要求する信号である。OKは、受話器を取ったことを伝える信号である。ACKは、了解したことを伝える信号である。T.38  FAXセッションは、MH（モディファイド  ハフマン）、MR(モディファイドリード)等の符号化データを、ITU-T  T.38に基づいて通信するファクシミリセッションである。
【００８２】
２０１１はプロトコル群で、プロトコル群２００７のセッションを切断する為のプロトコルある。プロトコル群２０１１において、BYEは、通話終了の意思を伝える信号である。OKは,了解したことを伝える信号である。
【００８３】
２０１２はプロトコル群で、プリンタとプロトコル群２００８のセッションを切断する為のプロトコル群である。プロトコル群２０１１において、BYEは、通話終了の意思を伝える信号である。OKは,了解したことを伝える信号である。
【００８４】
２０１３はプロトコル群で、SIPプロトコル群２０１０のセッションを切断する。プロトコル群２０１３において、BYEは、通話終了の意思を伝える信号である。OKは,了解したことを伝える信号である。  
このように本発明複合機では、SIPによる音声通話と同時にＴ．３８プロトコルに基づく複数のファクシミリ通信が可能である。
【００８５】
図３は、図１に示したデータ通信装置の送信バッファの状態を説明するブロック図である。本例は、図１に示したＳＤＲＡＭ４６上に確保される送信バッファに送話以外の送信タスクデータが溜まり、送話データが送出されるまでに遅延が生じる状態例である。なお、図１と同一のものには同一の符号を付してある。
【００８６】
図３において、１０１は送信バッファで、複数のキューＣ１〜Ｃ７に別タスク送信データがフルに保持されている状態である。１０２は通話に関わる送話データである。
【００８７】
図４は、図１に示したデータ通信装置の送信バッファと受信バッファの構成を説明するブロック図である。
【００８８】
図４において、１１１〜１１５はバッファメモリである。また、バッファメモリ１１１は、内部バッファ１１１−１、１１１−２を備える。１１１−３は制御メモリで、バッファメモリ１１１を制御するための情報、例えば、ＤＭＡのバースト転送のバースト長やメモリが空かどうか、読み出されたかどうかを示す情報を格納する。
【００８９】
同様に、バッファメモリ１１２は、内部バッファ１１２−１、１１２−２を備える。１１２−３は制御メモリで、バッファメモリ１１２を制御するための情報、例えば、ＤＭＡのバースト転送のバースト長やメモリが空かどうか、読み出されたかどうかを示す情報を格納する。
【００９０】
同様に、バッファメモリ１１３は、内部バッファ１１３−１、１１３−２を備える。１１３−３は制御メモリで、バッファメモリ１１３を制御するための情報、例えば、ＤＭＡのバースト転送のバースト長やメモリが空かどうか、読み出されたかどうかを示す情報を格納する。
【００９１】
同様に、バッファメモリ１１４は、内部バッファ１１４−１、１１４−２を備える。１１４−３は制御メモリで、バッファメモリ１１４を制御するための情報、例えば、ＤＭＡのバースト転送のバースト長やメモリが空かどうか、読み出されたかどうかを示す情報を格納する。
【００９２】
同様に、バッファメモリ１１５は、内部バッファ１１５−１、１１５−２を備える。１１５−３は制御メモリで、バッファメモリ１１５を制御するための情報、例えば、ＤＭＡのバースト転送のバースト長やメモリが空かどうか、読み出されたかどうかを示す情報を格納する。
【００９３】
なお、本実施形態において、複数のバッファで構成されるのは、片方でデータを受けながら、他方で受ける準備をするなどの動作をするためである。
【００９４】
なお、物理的には、これらのバッファメモリは一つのメモリを分割した構成で考えても良いし、分割して構成しても良い。
【００９５】
また、本実施形態では、それぞれのバッファメモリはリングバッファの形態でチェイン状に繋がれている。
【００９６】
図５は、本実施形態を示すデータ通信装置を適用するネットワークシステムの一例を示すブロック図である。本例は、ネットワークを介してデータ通信装置を備えるＭＦＰと多数のIPFAXまたはIP電話機が接続されているシステム例である。また、本システム例では、IP電話機で通話するのと同時に多数のIP  FAXと通信することが可能に構成されている。
【００９７】
図５において、１２１は複合機（ＭＦＰ）で、図示しないスキャナ部、プリンタ部、通信制御部を備える。なお、通信制御部は、本実施形態のデータ通信装置の機能を実行するデバイスである。
【００９８】
１２２はネットワークで、ＦＡＸ受信機１２３〜１２６、ＦＡＸ送信機１２７、IP電話機１３０と接続されている。なお、ＦＡＸ受信機１２３〜１２６は、符号化方式がMMRであるＦＡＸ受信機である。また、ＦＡＸ送信機１２７は、符号化方式がMHであるＦＡＸ送信機である。
【００９９】
１２８はSIPにて通話を行うことができる電話機手段で、ＭＦＰ１２１に内蔵されている。１２９はFAX手段で、ＦＡＸ受信機１２３〜１２６やＦＡＸ送信機１２７などのうち、複数の装置と並行して通信が可能に構成されている。IP電話機１３０は、電話機手段１２８とSIPにて通話が可能に構成されている。１３１はコントローラ部で、ＭＦＰ１２１のスキャナ機能、プリント機能、ファクシミリ通信機能、ＩＰ通話機能等を総括的に制御する。コントローラ部１３１は、図示しないＣＰＵ、ＲＯＭ、ＳＤＲＡＭと等を備える。なお、ＳＤＲＡＭは、図１に示したＳＤＲＡＭ４６に対応し、受信バッファ、送信バッファとして機能する。
【０１００】
図６は、本実施形態を示すデータ通信装置における第１のデータ通信処理手順の一例を示すフローチャートである。本例は、ユーザが送話を希望し、ＩＰ通話が起動されるまでの処理例である。なお、Ｓ５１〜Ｓ６３は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０１０１】
まず、ユーザからＩＰ通話要求があると、例えばハンドセットのダイヤル通話ボタン等を押下すると、コントローラ部１３１は、Ｓ５１で、現在ＩＰＦＡＸ送信タスク中かどうかを判断する。この場合、コントローラ部１３１は、図３に示したＬＡＮＣ６３の状態から判別することができる。
【０１０２】
ここで、コントローラ部１３１が、現在ＩＰＦＡＸ送信タスク中でないと判断した場合は、Ｓ５２で、現在ＬＡＮ送信データキューとして機能する図３に示したキューＣ１〜Ｃ７に一定量以上のデータが有るかを判断する。ここで、コントローラ部１３１が一定量以上のデータがあると判断した場合は、送話をウエイトさせるウエイトをかけ（Ｓ５８）、Ｓ５２へ戻る。
【０１０３】
一方、Ｓ５２で、一定量以上のデータがないと判断した場合は、Ｓ５３で、電話機手段１２８による送話起動をＯＫとする。
【０１０４】
そして、Ｓ５４で、コントローラ部１３１が送話に伴い相手先からの通話データを受信する受信バッファの使用状態から受話を起動可能か否かを判断する。ここで、受話バッファの使用状態から受話起動できないと判断した場合は、Ｓ５９で、送話をウエイトさせるウエイトをかけ、Ｓ６０で、その旨を示すメッセージ、例えば「ネットワーク通話が混み合っています。しばらくお待ち下さい」等をＭＦＰ１２１の操作部のディスプレイに表示して、Ｓ５４へ戻る。
【０１０５】
一方、Ｓ５４で、受話起動ＯＫと判断した場合は、コントローラ部１３１は、Ｓ５５で、通話起動のＯＫを確認にし、Ｓ５６で、「ネットワーク通話が混み合っています。しばらくお待ち下さい」等の表示を消灯する。そして、通話起動処理へ移行する。
【０１０６】
一方、Ｓ５１で、現在ＩＰＦＡＸ送信タスク中であると判断した場合は、Ｓ５７で、「ネットワーク通話が混み合っています。しばらくお待ち下さい」等を表示するとともに、その内容を音声出力する。
【０１０７】
そして、Ｓ６１で、送信データの復号化処理による負荷が送信データの符号化処理による負荷を上回っているかどうかを判断する。ここで、ＹＥＳと判断した場合は、Ｓ６２で、送信タスクにウエイトかけ、Ｓ６３で、コントローラ部１３１は、別の多重送信タスクが起動中であるかどうかを判断する。ここで、別の多重送信タスクが起動中でないと判断した場合は、Ｓ５２へ戻り、別の多重送信タスクが起動中であると判断した場合は、Ｓ６１へ戻る。
【０１０８】
一方、Ｓ６１で、ＮＯと判断した場合は、Ｓ６４で、送信データの復号化処理による負荷と送信データの符号化処理による負荷が同等かどうかを判断する。ここで、ＹＥＳと判断した場合は、Ｓ６２へ戻り、ＮＯと判断した場合は、Ｓ６３へ戻る。
【０１０９】
図１に示すデータ通信装置は、ユーザがＩＰ通話を開始しようとしたときに，図に示したように、送信バッファ１０１に別タスク送信データがキューＣ１〜Ｃ７に溜まっているときに，その影響を受ける。そして、ＩＰ通話データを送信バッファに送信した場合でも、ＩＰ通話開始までにここで遅延が発生する。
【０１１０】
例えば，送信バッファ１０１は、図４に示すように構成されているため、ＬＡＮＣ６３へ送られるデータが、送信バッファ１１２＞送信バッファ１１３＞送信バッファ１１４＞送信バッファ１１５のような順番で処理される。この時、空のバッファである送信バッファ１１１に通話データを入れてもなかなか処理されない。
【０１１１】
つまり、データ通信装置は、例えば図５に示すように多くのＦＡＸとの通信が可能であり，多重通信数が多いほど，このような状態が起こりうる。
【０１１２】
そこで、ユーザが希望しても、図６に示した制御手順に基づいて、ＩＰ通話要求を制御する。すなわち、他の送信データがキューに残っている場合に、そのキューが少なくなった状態で通話可能とする。
【０１１３】
これにより、送話要求時に、ファクシミリデータ通信等で送信バッファ等にデータが蓄積されている場合には、本ファクシミリデータ通信と同時的なＩＰ通話の起動を制限して、ＩＰ通話の遅延や音切れ発生を防止することができる。
【０１１４】
このように構成されたインターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置は、以下の特徴的な機能を備える。まず、ＤＲＡＭ４６上にインターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する受信バッファまたは送信バッファが確保される。そして、受信バッファあるいは送信に記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定機能を備える。この決定機能は、ＬＡＮＣ６２あるいはＭＦＰのコントローラ部に実行させてもよい。
【０１１５】
そして、受信バッファ音声通信による音声データを優先させると決定した場合に、ファクシミリデータの通信を維持させる。これと並行して、受信バッファあるいは送信バッファに記憶された音声データの受信あるいは送信処理を優先させる制御を後述する実施形態に示すように行う。
【０１１６】
なお、ここで、処理状態とは、受信バッファを利用する音声データ通信要求時における受信バッファを使用するファクシミリデータ通信情報等に応じて変動する。また、図６に示したように、通話要求時に、受信バッファや送信バッファに一定量のファクシミリ通信データが記憶されている場合には、そもそも通話要求を制限して、その旨をユーザに明示する。これにより、ユーザは、通話する際の音声劣化を伴う通信を制限できる。
【０１１７】
〔第２実施形態〕
上記実施形態では、ＩＰ電話機による送話開始時に送信バッファの状態を判別して、ＩＰ通話を制限する場合について説明した。しかし、同様のデータ通信遅延は、送話時のみならず、受話時にも起こりうる。そこで、以下、その実施形態について説明する。
【０１１８】
なお、データ通信装置のハードウエアの構成については、図１に示したデータ通信装置と同様の資源を備えるものとし、その説明は割愛する。
【０１１９】
また、本実施形態を示すデータ通信装置は、ネットワークを介した通信プロトコルは、ＳＩＰで、ファクシミリ送信のプロトコルは、ＩＴＵ−Ｔ  Ｔ．３８も可能に構成されているものとする。
【０１２０】
図７は、本実施形態を示すデータ通信装置の受信バッファの状態を説明するブロック図である。なお、図３と同一のものには同一の符号を付している。本例は、図１に示したＳＤＲＡＭ４６上に確保される受信バッファに受話以外の送信タスクデータが溜まり、受話データが送出されるまでに遅延が生じる状態例である。なお、図１と同一のものには同一の符号を付してある。
【０１２１】
図７において、１０４は受信バッファで、複数のキューＣ１〜Ｃ７に別タスク受話データがフルに保持されている状態である。１０５は通話に関わる受話データである。
【０１２２】
図７に示すようにデータ通信装置において、ユーザが通話を開始しようとしたときに，別タスクの受信データがキューＣ１〜Ｃ７が溜まっているときに，その影響を受けて、通話データを受信バッファに受信した場合でも、ここで遅延が発生してしまう。
【０１２３】
例えば，受信バッファは、図４のように構成されており、ＨＯＳＴ側へ送られるデータが、バッファ１１２＞バッファ１１３＞バッファ１１４＞バッファ１１５のような順番で処理される。この時、空のバッファであるバッファ１１１に通話データが入ってもなかなか処理されない。特に、図５の様に多くのＦＡＸとの通信が可能であり，多重通信数が多いほど，このような状態が起こりうる。そこで、図８に示すように、通話データの受話を制限する。
【０１２４】
図８は、本実施形態を示すデータ通信装置における第２のデータ通信処理手順の一例を示すフローチャートである。本例は、ユーザが送話を希望し、ＩＰ通話が起動されるまでの処理例である。なお、Ｓ７１〜Ｓ８５は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０１２５】
まず、ユーザからＩＰ受話要求があると、例えばハンドセットのダイヤル通話ボタン等を押下すると、コントローラ部１３１は、Ｓ７１で、現在ＩＰＦＡＸ受信タスク中かどうかを判断する。この場合、コントローラ部１３１は、図３に示したＬＡＮＣ６２の状態から判別することができる。
【０１２６】
ここで、コントローラ部１３１が、現在ＩＰＦＡＸ受信タスク中でないと判断した場合は、Ｓ７２で、現在ＬＡＮ受信データキューとして機能する図７に示したキューＣ１〜Ｃ７に一定量以上のデータが有るかを判断する。ここで、コントローラ部１３１が一定量以上のデータがあると判断した場合は、Ｓ７８で、受話をウエイトさせるウエイトをかけ、Ｓ７９で、例えば「ネットワーク通話が混み合っています。しばらくお待ち下さい」等をＭＦＰ１２１の操作部のディスプレイに表示して、Ｓ７２へ戻る。
【０１２７】
一方、Ｓ７２で、一定量以上のデータがないと判断した場合は、Ｓ７３で、電話機手段１２８による受話起動をＯＫとする。
【０１２８】
そして、Ｓ７４で、コントローラ部１３１が受話に伴い相手先に通話データを送信する送信バッファの使用状態から送話を起動可能か否かを判断する。ここで、送信バッファの使用状態から送話起動できないと判断した場合は、Ｓ８０で、受話をウエイトさせるウエイトをかけ、Ｓ７４へ戻る。
【０１２９】
一方、Ｓ７４で、送話を起動可能であると判断した場合は、Ｓ７５で、通話起動ＯＫを確認して、Ｓ７６で、その旨を示すメッセージ、例えば「ネットワーク通話が混み合っています。しばらくお待ち下さい」等をＭＦＰ１２１の操作部のディスプレイに表示して、通話起動処理へ移行する。
【０１３０】
一方、Ｓ７１で、現在ＩＰＦＡＸ受信タスク中であると判断した場合は、Ｓ７７で、「ネットワーク通話が混み合っています。しばらくお待ち下さい」等を表示するとともに、その内容を音声出力する。
【０１３１】
そして、Ｓ８１で、送信データの復号化処理による負荷が送信データの符号化処理による負荷を上回っているかどうかを判断する。ここで、ＹＥＳと判断した場合は、Ｓ８２で、受話タスクにウエイトかける。そして、Ｓ８３で、コントローラ部１３１は、別の多重受信タスクが起動中であるかどうかを判断する。ここで、別の多重送信タスクが起動中でないと判断した場合は、Ｓ７２へ戻り、別の多重受信タスクが起動中であると判断した場合は、Ｓ８１へ戻る。
【０１３２】
一方、Ｓ８１で、ＮＯと判断した場合は、Ｓ８５で、送信データの復号化処理による負荷と送信データの符号化処理による負荷が同等かどうかを判断する。ここで、ＹＥＳと判断した場合は、Ｓ８２へ戻り、ＮＯと判断した場合は、Ｓ８３へ戻る。
【０１３３】
本実施形態では、ユーザが希望しても他受信データが図７に示したようにキューＣ１〜Ｃ７に残っている場合に、そのキューが少なくなった状態で通話可能とする。
【０１３４】
つまり、上記のように構成されたデータ通信装置において、ファクシミリ通信のための受信データが該ネットワークから受信したデータ蓄積するためのメモリに、キューとして蓄積されている状態は発生する。このような時に、該相手装置からの該符号化された音声データを一定間隔で再生できない場合は、該音声データをネットワークから受信する動作を起動しない制御を行う。
【０１３５】
これにより、受話要求時に、ファクシミリデータ通信等で受信バッファ等にデータが蓄積されている場合には、本ファクシミリデータ通信と同時的なＩＰ通話の起動を制限して、ＩＰ通話の遅延や音切れ発生を防止することができる。
【０１３６】
〔第３実施形態〕
図９は、本発明の第３実施形態を示すデータ通信装置を適用可能な画像形成装置の一例を示すブロック図である。なお、本実施形態で、画像形成装置は、プリント機能、スキャナ機能、データ通信機能を備えるＭＦＰの例を示す。なお、図１、図５と同一のものには同一の符号を付してある。
【０１３７】
図９において、９０２は、ＣＰＵコアで、各デバイスを総括的に制御する。６１はメモリをコントロールするメモリコントローラである。９０４は外部バスコントロール部で、外部バスに接続されるＲＯＭ９１９、ＳＲＡＭ９２０、ＦＲＡＭ９２１やモデム９１８とのアクセスを制御する。
【０１３８】
９０５はＵＳＢデバイスインタフェース部で、デジタルカメラ９３３と接続される。９０６はホストインタフェースで、ホストＰＣ９３２と接続される。９０７はイメージプロセッサで、画像処理を行うＣＯＤＥＣ９０８〜９１２を備える。９１３はＬＣＤＣで、表示デバイスであるＬＣＤ９２７の表示を制御する。９２８はキーインタフェースで、操作部等に設けられるキー入力手段９２８からの入力を処理する。
【０１３９】
９３０はハードディスク制御手段で、ハードディスク（ＨＤ）９３１とのアクセスを制御する。９２２はスキャナ部で、図示しない光学走査部を制御して、ＣＣＤ等の結像素子に結像された画像情報をコントローラ部１３１に出力する。９２３はプリンタ部で、図示しないプリンタエンジンを備えている。
【０１４０】
９２４はＰＴＰ（Real-time Transport Protocol）手段で、データ部と、コントローラ部とから構成されて、インタラクティブな音声、ビデオ、データのリアルタイムは配信処理を可能とする。また、ＲＴＰだ９２４はパケットが順番通りに到着しているかを判断し、タイムスタンプ情報を使って到着するまでのジッタを判断する機能を備える。９２５は音声入出力手段で、ヘッドセット等で構成される。９２６は音声ＣＯＤＥＣで、音声データに所定の信号処理を施して符号化、復号化処理を行う。
【０１４１】
図１０は、図９に示したＳＤＲＡＭ４７に確保される送信バッファメモリからPHY６３へのデータの流れを説明する図である。
【０１４２】
図１０において、６３はPHY（physical layer）部で、物理層ICで構成される。２はメディアアクセスコントロールブロック（ＭＡＣＴＡＸ）で、LANC６２に内蔵される。９５３はFIFOメモリである。９５４はＤＭＡマスタで、ダイレクトメモリアクセスの調停を行う。９５５はバッファメモリで、送信データを保持する。
【０１４３】
このように送信データは、バッファメモリ９５５からＤＭＡで、該物理的に同じあるいは別のFIFOメモリ９５３に送られた後に、転送されその後ＭＡＣ９５２に送られ、ＰＨＹ部６３を経由してネットワークへと流れていく。
【０１４４】
図１１は、図１０に示したＰＨＹ部６３から受信バッファメモリへのデータの流れを説明する図である。なお、図１０と同一の機能部には同一の符号を付してある。
【０１４５】
図１１に示すように、ネットワークからの受信データは、ＰＨＹ部６３、ＭＡＣ９５２を経由して、物理的に同じあるいは別のFIFOメモリ９５３に送られた後に、受信側のバッファメモリ９５５へとDMAで転送されていく。
【０１４６】
図１２は、図９に示したデータ通信装置によるマルチタスク処理を説明するブロック図である。
【０１４７】
図１２において、１１０１は送話タスクである。１１０２〜１１０４は符号変換を伴なう送信データ生成タスクである。１１０５は符号変換を伴なう受信データ蓄積タスクである。１１０６は受話タスクである。
【０１４８】
本実施形態では、送信データ生成タスク１１０２〜１１０４と、受信データ蓄積タスク１１０５のいずれかのタスクにウエイトをかけて、送信用のバッファメモリ９５５に対する転送を止める制御をコントローラ部１３１が行う。
【０１４９】
図１３は、本実施形態を示すデータ通信装置における第３のデータ通信処理手順の一例を示すフローチャートである。本例は、音声符号化データの送信中は、該ファクシミリ通信のための送信データをネットワークに送信するためのバッファメモリに転送する動作に、Ｔ．３８プロトコルに準拠してウエイトをかける処理例である。なお、Ｓ１２０１〜Ｓ１２１５は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０１５０】
まず、Ｓ１２０１で、コントローラ部１３１は、ウエイト指定された送信タスクかどうかを判断する。つまり、ファクシミリ通信のための送信データを転送するタスクかどうかを判断する。ここで、ウエイト指定された送信タスクでないと判断した場合は、Ｓ１２１６へ進み、他の処理へ移行する。
【０１５１】
一方、Ｓ１２０１で、ウエイト指定された送信タスクであると判断した場合は、Ｓ１２０２で、コントローラ部１３１は、相手機にＴＮＲ送信可能かどうかを判断する。ここで、ＴＮＲ送信可能であると判断した場合は、さらに、Ｓ１２１７で、コントローラ部１３１がＴＮＲ送信できるタイミングかどうかを判断する。ここで、ＴＮＲ送信可能なタイミングであると判断した場合は、Ｓ１２１８で、相手機にＴＮＲ送信処理を行う。そして、Ｓ１２１９で、次の処理に移行する。
【０１５２】
一方、Ｓ１２１７で、ＴＮＲ送信可能なタイミングでないと判断した場合は、Ｓ１２０５へ進む。
【０１５３】
また、Ｓ１２０２で、相手機にＴＮＲ送信可能でないと判断した場合は、Ｓ１２０３で、図示しないタイマをスタートする。そして、Ｓ１２０４で、送信用のバッファメモリ９５５への送信をストップする。
【０１５４】
次に、Ｓ１２０５で、コントローラ部１３１は、相手機と蓄積されたデータの符号化方式が違うかどうかを判断する。ここで、符号化方式が違うと判断した場合は、Ｓ１２０６で、復号処理、符号化処理を停止して、Ｓ１２０７へ進む。
【０１５５】
一方、Ｓ１２０５で、コントローラ部１３１が符号化方式が一致すると判断した場合は、Ｓ１２０７で、コントローラ部１３１は、Ｓ１２０３においてタイマに設定されたタイマ値を超えたかどうかを判断する。ここで、タイマ値を超えていないと判断した場合は、Ｓ１２０８で、別の処理を実行して、Ｓ１２０７へ戻る。
【０１５６】
一方、Ｓ１２０７で、コントローラ部１３１が設定されたタイマ値を超えたと判断した場合は、Ｓ１２０９で、バッファメモリ９５５に対する送信処理を再開させる。これで、バッファメモリ９５５に蓄積されたファクシミ送信データの送信を遅延させるが、送信切断には至らない状態に遷移させて、音声データ処理を可能とする。
【０１５７】
次に、Ｓ１２１０で、コントローラ部１３１が相手機とバッファメモリ９５５に蓄積されたデータの符号化方式が違うかどうかを再度判断する。ここで、符号化方式が違うと破断した場合はＳ１２１１で、復号処理、符号化処理を再開して、Ｓ１２１２へ進む。
【０１５８】
一方、Ｓ１２１０で、コントローラ部１３１がバッファメモリ９５５に蓄積されたデータの符号化方式と一致すると判断した場合は、Ｓ１２１２で、相手機のＴ．３８プロトコルのタイマ内でデータ送信を行う。
【０１５９】
次に、Ｓ１２１３で、１ブロック分の送信データを送信し終えたかどうかを判断する。ここで、１ブロック分の送信データの送信をし終えていないと判断した場合は、Ｓ１２１４で、別の処理を行い、Ｓ１２１２へ戻る。
【０１６０】
一方、Ｓ１２１１３で、１ブロック分の送信を終了していると判断した場合は、Ｓ１２１５で、コントローラ部１３１がバッファメモリ９５５に対して記憶される全ての送信データの送信を終了しているかどうかを判断する。ここで、終了していると判断した場合は、通信終了フェーズへ移行する。
【０１６１】
一方、Ｓ１２１５で、送信データの送信を全て終了していないと判断した場合は、Ｓ１２０１へ戻る。
【０１６２】
本実施形態では、送信のためのバッファメモリ９５５への転送を中断させ、相手機のタイマ内で通信断とならない最小限の送信データを送るべく転送を再開しながら、相手機と通信を確保しつつ通話を行うことができる。
【０１６３】
ここで、送信データとしては、最小限の１ブロック分のデータしか送らないので、通話に対する影響は、最小限ですむ。
【０１６４】
このように本実施形態では、データ通信装置が音声符号化データの送信中は、ファクシミリ通信のための送信データをネットワークに送信するためのバッファメモリ９５５に転送する動作に、ウエイトをかけることができる。
【０１６５】
〔第４実施形態〕
なお、上記第３実施形態では、送信のためのバッファメモリ９５５への転送を中断させ、相手機のタイマ内で通信断とならない最小限の送信データを送るべく転送を再開しながら、相手機と通信を確保しつつ通話を行う場合を説明した。
【０１６６】
一方、上記第１実施形態に示したデータ処理装置では、相手機と自機とのメモリ蓄積方式が異なる符号化方式データ通信を行う必要が生じる。
【０１６７】
このようなデータ通信状態に遷移した場合に、データ通信を制御するコントローラ部１３１を構成するＣＰＵの能力、バス占有率では対応できない負荷が生じる。そこで、図１３に示すように、符号変換処理である符号化処理、復号化処理を音声データ通信中に停止させたり、再開させたりする制御を行う。
【０１６８】
具体的には、図５に示したように相手機とのデータ通信時に多重通信を行う場合、相手機と自機のメモリ蓄積方式と違う符号化方式で通信を行う場合が多い。その場合、その符号変換のシステムに対する影響が大きい。
【０１６９】
そして、このようなデータ変換処理が、ＣＰＵの能力、バス占有率などのシステムにあたえる負荷が高くなる状態に遷移する。
【０１７０】
そこで、上記負荷を高めてしまう符号変換処理を止める事により、データ通信システムの破綻を防ぐ制御を図１３に示すように介入させる。
【０１７１】
これにより、データ通信に伴うデータ処理の負荷が変動しても、音声データ通信に対する影響を低減できる。
【０１７２】
〔第５実施形態〕
上記第１実施形態に示したデータ処理装置において、符号変換処理手段は、図１に示す例では、符号器５４、５５、復号器５３、５６で、符号化方式を合わせている。これらの符号器５４、５５、復号器５３、５６は、ハードウエアで構成される場合もあるが、ソフトウエアで構成される場合もある。
【０１７３】
この符号化、復号化処理が、コントローラ部１３１のＣＰＵの能力、バス占有率などのシステムに与える負荷が大きくなる状態に遷移する場合がある。
【０１７４】
例えば、図１に示したバッファメモリ６５、６６は、ＳＤＲＡＭ４６などの他の用途で使用されるメモリと物理的に同じものを使用しているケースも多い。
【０１７５】
その場合、メモリリソースは有限であることから、これが多重に使用されると、この影響がシステムの破綻を招く可能性もある。
【０１７６】
そこで、図１３に示すように、音声データの通信と、ファクシミリデータ通信を同時に行う場合に、コントローラ部１３１が符号化、復号化の処理を止める事により、システムの破綻を防ぐ制御を加える。
【０１７７】
これにより、データ通信に伴うデータ処理のリソースの取得が制限される場合でも、音声データ通信に対する影響を低減できる。
【０１７８】
〔第６実施形態〕
上記実施形態では、図９に示したデータ通信装置によるマルチタスク処理を説明した。具体的には、送信データ生成タスク１１０２〜１１０４と、受信データ蓄積タスク１１０５のいずれかのタスクにウエイトをかけて、送信用のバッファメモリ９５５に対する転送を止める制御をコントローラ部１３１が行う場合について説明した。
【０１７９】
しかしながら、自機のメモリ蓄積方式がＪＢＩＧで、相手機がＪＢＩＧの場合のように符号変換を伴わない通信が存在する場合には、何らウエイトをかける必要がない場合もある。以下、その実施形態について説明する。
【０１８０】
本実施形態では、図１２に示したマルチタスク処理のうち、自機と相手機とのメモリ蓄積方式が同じかどうかをコントローラ部１３１が判別する。
【０１８１】
そして、コントローラ部１３１が、自機のメモリ蓄積方式がＪＢＩＧで、相手機がＪＢＩＧの場合のように符号変換を伴わない通信が存在する場合は、その通信タスクを止めないように制御する。そして、コントローラ部１３１が自機と相手機とのメモリ蓄積方式が異なるタスクに対して優先的にウエイトをかける制御を行う。
【０１８２】
これにより、音声通信と同時に少なくとも２つ以上の送信動作が同時に動作している時、蓄積した画像データと同じ符号化方式で符号変換が必要ない場合は、画像データ通信に無駄なウエイトをかけることなくなる。
【０１８３】
〔第７実施形態〕
図１４は、本発明の第７実施形態をデータ通信装置の要部構成を説明するブロック図である。なお、図１、図９と同一のものには同一の符号を付してある。
【０１８４】
以下、受信バッファ残っている受信データを復号器に転送せずに一時格納メモリに格納し、ＩＴＵ−Ｔ  Ｔ．３０のＲＮＲ信号を送出する動作について説明する。
【０１８５】
図１４において、１３０１は受信バッファで、例えばＳＤＲＡＭ４７内に確保される。本実施形態では、受信バッファ部１３０１−１、１３０１−２を備え、受信画像データを保持する。１３０２は送信バッファで、例えばＳＤＲＡＭ４７内に確保され、ITU-T  T.30のRNR信号を保持する。
【０１８６】
１３０３は符号器で、画像メモリに蓄積するために、例えばJBIGデータに変換する。１３０４は復号器で、受信したデータを一旦復号化する。１３０２は一時格納メモリで、受信したデータを一時格納し、復号器１３０４へと送ることを一時ストップする。
【０１８７】
なお、物理的に送信バッファ１３０２と受信バッファ１３０１とを共通化する構成としてもよい。
【０１８８】
また、本実施形態では、図１０、図１１に示す経路でデータの受信、送信が行われるものとする。
【０１８９】
本実施形態では、図１４に示すように受信データを復号器１３０４、符号器１３０３にはダイレクトに転送せず、一時格納メモリ１３０３に格納する制御を行う。以下、図１５に示すフローチャートを参照して、本実施形態のデータ通信処理について説明する。
【０１９０】
図１５は、本実施形態を示すデータ通信装置における第４のデータ通信処理手順の一例を示すフローチャートである。本例は、ウエイト指定受信タスクの例である。なお、Ｓ１４０１〜Ｓ１４１２は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０１９１】
まず、Ｓ１４０１で、コントローラ部１３１は、受信バッファ１３０１に保持される受信データに対する受信タスクがウエイト指定されたタスクであるかどうかを判別する。ここで、ウエイト指定されているタスクでないと判断した場合は、Ｓ１４０２で、別の処理へ移行する。
【０１９２】
一方、Ｓ１４０１で、ウエイト指定されているタスクであると判断した場合は、Ｓ１４０３で、相手機と受信バッファ１３０１に蓄積されたデータの符号化方式が違うかどうかをコントローラ部１３１が判断する。ここで、コントローラ部１３１が蓄積されたデータの符号化方式が違うと判断した場合は、Ｓ１４０４で、符号化、復号化処理を停止して、Ｓ１４０５へ進む。
【０１９３】
一方、Ｓ１４０３で、蓄積されたデータの符号化方式が一致すると判断した場合には、受信バッファ１３０１に蓄積した受信データを一時格納メモリ１３０３へ格納する。
【０１９４】
そして、Ｓ１４０６で、コントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＲＮＲ信号を送信可能かどうかを判断する。ここで、送信可能であると判断した場合は、Ｓ１４０７で、さらにコントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＲＮＲ信号を送信可能なタイミングかどうかを判断する。ここで、送信可能なタイミングであると判断した場合は、Ｓ１４０８で、コントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＲＮＲ信号を送信する。そして、Ｓ１４０９で、次の処理に移行する。一方、Ｓ１４０６で、コントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＲＮＲ信号を送信可能でないと判断した場合、Ｓ１４１０へ進む。同様に、Ｓ１４０７で、コントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＲＮＲ信号を送信可能なタイミングでないと判断した場合は、Ｓ１４１０へ進む。
【０１９５】
そして、Ｓ１４１０で、１ブロック分の受信処理を終了しているかどうかを判断する。ここで、１ブロック分とは、あらかじめ決定されているものとする。
【０１９６】
ここで、１ブロック分のデータ受信を終了していないと判断した場合は、Ｓ１４１１で、受信バッファ部１３０１−１に格納された受信バッファデータを一時格納メモリ１３０３に格納して、Ｓ１４１０へ戻る。
【０１９７】
一方、Ｓ１４１０で、１ブロック分の受信を終了していると判断した場合は、Ｓ１４１２で、１頁分のデータの受信を終了しているかどうかをコントローラ部１３１が判断する。ここで、１頁分のデータの受信を終了していると判断した場合は、通信終了処理へ移行し、１頁分のデータの受信を終了していないと判断した場合は、Ｓ１４０６へ戻る。
【０１９８】
これにより、ファクシミリ通信のための受信データがネットワークから受信したデータ蓄積させるための受信バッファ１３０１に、キューとして蓄積されている。この時に、該蓄積された受信データを一時格納メモリ１３０３に一時格納し、そこから下流の復号器１３０４に復号化処理にウエイトをかけることができる。つまり、一時格納メモリ１３０３を介することで、いわゆるタイマ処理に代えて、一時格納メモリ１３０３をデータ通信の遅延メモリとして機能させることでウエイトをかけることができる。
【０１９９】
そして、この遅延メモリ機能を使用することで、データ通信に伴うデータ処理のリソースの取得が制限される場合でも、音声データ通信に対する影響を低減できる。
【０２００】
〔第８実施形態〕
図１６は、本発明の第８実施形態を示すデータ通信装置の要部構成を説明するブロック図であり、図１４と同一のものには同一の符号を付してある。以下、残っている送信データをネットワークに送出した後に、ＩＴＵ−Ｔ  Ｔ．３０のＴＮＲ信号を送出する処理について説明する。ここで、ＴＮＲとは、TNR（Transmitter Not Ready）を意味する。
【０２０１】
図１６において、１３０２−１で、送信バッファ部１３０２−１には送信データがキューに残っている状態を示している。１３０２−２は送信バッファ部で、ＩＴＵ−Ｔ  Ｔ．３０のＴＮＲ信号を保持している。なお、送信バッファ部１３０２−１、１３０２−２とを１つの送信バッファとを共通化する構成してもよい。
【０２０２】
本実施形態を示すデータ通信装置では、図１６に示すようにＴＮＲ送出処理を行う。例えばユーザが通話起動時に、後述するようなタイミングを計りながらＴＮＲ信号を送出する。
【０２０３】
これは、送信データをネットワークに送信するための送信バッファ部１３０２−１に、該ファクシミリデータが待行列（以下キュー）として蓄積されている。この時に、送信バッファ部１３０２−１に蓄積されたキューを減らす目的で、相手受信機にITU-T  T.30で定められたTNR（Transmitter Not Ready）を送出する。
【０２０４】
これにより、データ通信装置における送信バッファ部１３０２−１に格納されたファクシミリ送信データの転送処理に、タイマ処理以外の処理でウエイトをかけることができる。
【０２０５】
図１７は、本実施形態を示すデータ通信装置における第５のデータ通信処理手順の一例を示すフローチャートである。本例は、ウエイト指定送信タスクの例である。なお、Ｓ１６０１〜Ｓ１１６１は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０２０６】
まず、Ｓ１６０１で、コントローラ部１３１は、ＩＰＦＡＸ送信タスクが起動中かどうかを判断する。ここで、ＩＰＦＡＸ送信タスクが起動中であると判断した場合は、Ｓ１６０２で、コントローラ部１３１は、音声通信のためのウエイト指定の送信タスクであるかどうかを判断する。ここで、ウエイト指定の送信タスクでないと判断した場合は、Ｓ１６０６に進み、送信バッファ１４０２上でウエイトしていないウエイト指定の別送信タスクの状態を検知して、Ｓ１６０２へ戻る。
【０２０７】
一方、Ｓ１６０２で、ウエイト指定の送信タスクであると判断した場合は、Ｓ１６０３で、１ブロック分のデータを送信し終えたかどうかを判断する。ここで、１ブロック分のデータを送信し終えたと判断した場合は、Ｓ１６０４で、送信バッファ部１３０２に格納されたＴＮＲ信号をネットワーク上に送信して、Ｓ１６０５へ進む。
【０２０８】
一方、Ｓ１６０３で、１ブロック分の送信データの送信を終了していると判断した場合は、Ｓ１６０５で、すべてのウエイト指定された送信タスクはウエイト中かどうかを判断する。ここで、ウエイト中でないと判断した場合は、Ｓ１６０６で、ウエイトしていないウエイト指定の別送信タスクの状態を検知して、Ｓ１６０２へ戻る。
【０２０９】
一方、Ｓ１６０１で、ＩＰＦＡＸ送信タスクが起動中でないと判断した場合は、Ｓ１６０７で、コントローラ部１３１がネットワークを介して送信すべき送信データが送信バッファ部１３０２−１に一定量以上格納されているかを判断する。ここで、一定量の送信データが格納されていると判断した場合は、Ｓ１６０８で、送話すべき音声データの送信にウエイトをかけて、Ｓ１６０７へ戻る。
【０２１０】
一方、Ｓ１６０７で、一定量の送信データが格納されていないと判断した場合は、Ｓ１６０９で、送信バッファ部１３０２−１に記憶される送信データの送話起動をＯＫとする。そして、Ｓ１６１１で、ネットワークを介して相手機から受話データを受信するため、コントローラ部１３１が受話起動がＯＫかどうかを判断する。ここで、受話起動がＯＫでないと判断した場合は、Ｓ１６１０で、送話にウエイトをかえて、Ｓ１６１１へ進む。
【０２１１】
一方、Ｓ１６１１で、受話起動がＯＫでないと判断した場合は、Ｓ１６１２で、通話起動をＯＫとする。
【０２１２】
これにより、データ通信装置における送信バッファ部１３０２−１に格納されたファクシミリ送信データの転送処理に、タイマ処理以外の処理でウエイトをかけることができる。
【０２１３】
〔第９実施形態〕
上記第７実施形態では、一時格納メモリ１３０３を介することで、いわゆるタイマ処理に代えて、一時格納メモリ１３０３をデータ通信の遅延メモリとして機能させることでウエイトをかける場合について説明した。
【０２１４】
しかしながら、符号化変換が必要でない場合は、受信画像データを、例えば、ハードディスクドライブすなわちＨＤＤ等に、そのまま蓄積してしまうことで、システムに対する負荷は軽減するように制御してもよい。これにより、第７実施形態と同様の効果が期待できる。
【０２１５】
〔第１０実施形態〕
上記第８実施形態では、図１７に示すＳ１６０４で、送信バッファ部１３０２に格納されたＴＮＲ信号をネットワーク上に送信して、送信データに対するウエイト処理を実行する場合について説明した。本実施形態では、相手機からの受信データを受信バッファに格納する場合のウエイト処理について説明する。
【０２１６】
なお、相手機から受信する受信データの処理経路は、図１１に示す例と同一である。
【０２１７】
図１８は、本実施形態を示すデータ通信装置における第６のデータ通信処理手順の一例を示すフローチャートである。本例は、ウエイト指定受信タスクの例である。なお、Ｓ１７０１〜Ｓ１７１２は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０２１８】
また、本実施形態では、受信データに対するウエイト処理として、相手送信機にＩＴＵ−Ｔ  Ｔ．３０で規定されたＲＮＲ（Receive Not Ready）信号を送出する例である。
【０２１９】
まず、Ｓ１７０１で、コントローラ部１３１は、ＩＰＦＡＸ受信タスクが起動中かどうかを判断する。ここで、ＩＰＦＡＸ受信タスクが起動中であると判断した場合は、Ｓ１７０２で、コントローラ部１３１は、音声通信のためのウエイト指定の受信タスクであるかどうかを判断する。ここで、ウエイト指定の受信タスクでないと判断した場合は、Ｓ１７０６に進み、ＤＲＡＭ６４内の受信バッファ上でウエイトしていないウエイト指定の別受信タスクの状態を検知して、Ｓ１７０２へ戻る。
【０２２０】
一方、Ｓ１７０２で、ウエイト指定の受信タスクであると判断した場合は、Ｓ１７０３で、１ブロック分のデータを受信し終えたかどうかを判断する。ここで、１ブロック分のデータを受信し終えたと判断した場合は、Ｓ１７０４で、受信バッファに格納されたＲＮＲ信号をネットワーク上に送信して、Ｓ１７０５へ進む。
【０２２１】
一方、Ｓ１７０３で、１ブロック分の受信データの受信を終了していると判断した場合は、Ｓ１７０５で、すべてのウエイト指定された受信タスクはウエイト中かどうかを判断する。ここで、ウエイト中でないと判断した場合は、Ｓ１７０６で、ウエイトしていないウエイト指定の別受信タスクの状態を検知して、Ｓ１７０２へ戻る。
【０２２２】
一方、Ｓ１７０１で、ＩＰＦＡＸ受信タスクが起動中でないと判断した場合は、Ｓ１７０７で、コントローラ部１３１がネットワークを介して受信すべき受信データが受信バッファに一定量以上格納されているかを判断する。ここで、一定量の受信データが格納されていると判断した場合は、Ｓ１７０８で、受話すべき音声データの受信にウエイトをかけて、Ｓ１７０７へ戻る。
【０２２３】
一方、Ｓ１７０７で、一定量の受信データが格納されていないと判断した場合は、Ｓ１７０９で、受信バッファに記憶される受信データの受話起動をＯＫとする。そして、Ｓ１７１０で、ネットワークを介して相手機から送話データを受信するため、コントローラ部１３１が送話起動がＯＫかどうかを判断する。ここで、送話起動がＯＫでないと判断した場合は、Ｓ１７１２で、受話にウエイトをかえて、Ｓ１７１０へ進む。
【０２２４】
一方、Ｓ１７１０で、送話起動がＯＫであると判断した場合は、Ｓ１７１１で、通話起動をＯＫとする。
【０２２５】
これにより、データ通信装置における受信バッファに格納されたファクシミリ受話データの転送処理に、タイマ処理以外の処理でウエイトをかけることができる。
【０２２６】
〔第１１実施形態〕
図１９は、本発明の第１１実施形態を示すデータ処理装置の要部構成を説明するブロック図である。本例は、LANC６２内のMACブロック１８０１にパケットチェックブロックを設けてフィルタリングし、パケットを破棄する例である。なお、図９と同一のものには同一の符号を付してある。
【０２２７】
図１９において、１８０１はＭＡＣブロックで、パケットチェックブロック１８０２と、制御ブロック１８０３を備え、パケット破棄手段１８０４でＰＨＹ６３からの受信したパケットを破棄する。なお、パケット破棄手段１８０４は、特定の受信パケット、例えばファクシミリデータを検出し、破棄する。ここで、ＰＨＹ部６３は、ネットワークの物理層を制御する物理層ICである。
【０２２８】
１８０７はＰＰＲ出力手段で、相手機にITU-T  T.30のPPR信号を送る。
【０２２９】
なお、パケット破棄手段１８０４は、MACブロック１８０１内あるいはLANC６２内である必要はない。例えばMACブロック１８０１あるいはLANC６２からバッファに転送する時点、あるいは、バッファから転送する時点にパケットを破棄する構成としてもよい。同様に、転送せずに破棄あるいは、バッファに転送するが無視する等のいろいろな手法でも同様の効果が期待できる。
【０２３０】
なお、ネットワークを介したデータの受信経路、並びにデータの送信経路は、図１０、図１１に示す経路と同様である。
【０２３１】
例えば、ファクシミリ通信では、フロー制御が一般的に用いられており、受信データを，相手機に再送してもらう事も可能である。
【０２３２】
ＰＨＹ部６３を介してＭＡＣブロック１８０１で受信したパケットを下流で処理することが、システムに与える負荷が大きく、システムの破綻を招く可能性がある。このような場合には、パケット破棄手段１８０４で受信したパケット破棄する。
【０２３３】
本実施形態によれば、ネットワークインターフェースコントローラを有するデータ通信装置、LANC６２で受信したパケットをチェックし受信した特定のファクシミリデータパケットを破棄する。これにより、データ通信装置におけるネットワークを介した音声データ処理に対する負担を軽減することができる。
【０２３４】
〔第１２実施形態〕
上記実施形態では、ネットワークインターフェースコントローラを有するデータ通信装置、LANC６２で受信したパケットをチェックし受信した特定のファクシミリデータパケットを破棄する場合について説明した。本実施形態では、破棄した特定のファクシミリデータパケットに対する再送を要求することで、ファクシミリ受信処理を回復させることができる。以下、その実施形態について説明する。なお、本実施形態のハードウエアの構成は、図１９に示した構成と同様である。
【０２３５】
つまり、図１９に示したパケット破棄手段１８０４で、ネットワークインターフェースコントローラを有するデータ通信装置、LANC６２で受信したパケットをチェックし受信した特定のファクシミリデータパケットを破棄する。その後、パケットを破棄した後に、相手送信装置に対して、再送を促す信号をＰＰＲ出力手段１８０５から送出する。
【０２３６】
このようにして、前もって定められた一定量のブロックデータを受信後に、相手送信機に対して該ブロックデータの再送を促す信号を送出することで、ファクシミリ受信処理を正常に回復させることができる。
【０２３７】
〔第１３実施形態〕
図２０は、本発明の第１３実施形態を示すデータ通信装置のＰＰＲ出力手段の動作を説明する図である。なお、ＰＰＲ出力手段は、図１９に示したものと同様の機能を備える。
【０２３８】
本例は、ＰＰＲ出力手段がデータ通信装置が相手装置と通話を開始する際に、音声データの通信タスクとは別タスクのデータにウエイトをかける例に対応する。
【０２３９】
図２１は、本実施形態を示すデータ通信装置における第７のデータ通信処理手順の一例を示すフローチャートである。本例は、ＰＰＲ出力手段がデータ通信装置が相手装置と通話を開始する際に、音声データの通信タスクとは別タスクのデータにウエイトをかける処理例である。なお、Ｓ２００１〜Ｓ２０１３は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０２４０】
まず、Ｓ２００１で、コントローラ部１３１は、受信バッファ１３０１に保持される受信データに対する受信タスクがウエイト指定されたタスクであるかどうかを判別する。ここで、ウエイト指定されているタスクでないと判断した場合は、Ｓ２００２で、別の処理へ移行する。
【０２４１】
一方、Ｓ２００１で、ウエイト指定されているタスクであると判断した場合は、Ｓ２００３で、相手機と受信バッファ１３０１に蓄積されたデータの符号化方式が違うかどうかをコントローラ部１３１が判断する。ここで、コントローラ部１３１が蓄積されたデータの符号化方式が違うと判断した場合は、Ｓ２００４で、符号化、復号化処理を停止して、Ｓ２００５へ進む。
【０２４２】
一方、Ｓ１４０３で、蓄積されたデータの符号化方式が一致すると判断した場合には、受信バッファ１３０１に蓄積した受信データを一時格納メモリ１３０３へ格納する。
【０２４３】
そして、Ｓ２００６で、コントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＰＰＲ信号を送信可能かどうかを判断する。ここで、送信可能であると判断した場合は、Ｓ２００７で、さらにコントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＰＰＲ信号を送信可能なタイミングかどうかを判断する。ここで、送信可能なタイミングであると判断した場合は、Ｓ２００８で、ＰＰＲ送出手段１８０５が相手機に、送信バッファ１３０２に格納されているＰＰＲ信号を送信する。そして、Ｓ２００９で、次の処理に移行する。
【０２４４】
一方、Ｓ２００６で、コントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＰＰＲ信号を送信可能でないと判断した場合、Ｓ２０１０へ進む。同様に、Ｓ２００７で、コントローラ部１３１が相手機に、送信バッファ１３０２に格納されているＰＰＲ信号を送信可能なタイミングでないと判断した場合は、Ｓ２０１０へ進む。
【０２４５】
そして、Ｓ２０１０で、１ブロック分の受信処理を終了しているかどうかを判断する。ここで、１ブロック分とは、あらかじめ決定されているものとする。
【０２４６】
ここで、１ブロック分のデータ受信を終了していないと判断した場合は、Ｓ２０１１で、受信バッファ部１３０１−１に格納された受信バッファデータを一時格納メモリ１３０３に格納して、Ｓ２０１０へ戻る。
【０２４７】
一方、Ｓ２０１０で、１ブロック分の受信を終了していると判断した場合は、Ｓ２０１２で、１頁分のデータの受信を終了しているかどうかをコントローラ部１３１が判断する。ここで、１頁分のデータの受信を終了していると判断した場合は、Ｓ２０１３で、通信終了処理へ移行し、１頁分のデータの受信を終了していないと判断した場合は、Ｓ２００６へ戻る。
【０２４８】
これにより、ファクシミリ通信のための受信データがネットワークから受信したデータ蓄積させるための受信バッファ１３０１に、キューとして蓄積されている。この時に、該蓄積された受信データを一時格納メモリ１３０３に一時格納し、そこから下流の復号器１３０４に復号化処理にウエイトをかけることができる。つまり、一時格納メモリ１３０３を介することで、いわゆるタイマ処理に代えて、一時格納メモリ１３０３をデータ通信の遅延メモリとして機能させることでウエイトをかけることができる。
【０２４９】
そして、この遅延メモリ機能を使用することで、データ通信に伴うデータ処理のリソースの取得が制限される場合でも、音声データ通信に対する影響を低減できる。
【０２５０】
さらに、ウエイトさせている、ファクシミリ通信のためのデータ受信をＰＰＲ信号の送信により再開することができる。
【０２５１】
〔第１４実施形態〕
図２２は、本発明の第１４実施形態を示すデータ通信装置の要部構成を説明するブロック図である。本例は、MACブロック１８０１内にパケットチェック機能を設けて、通話データである場合には優先処理する例である。なお、図１９と同一のものには同一の符号を付してある。
【０２５２】
図２２において、１８０５はパケットチェックブロックで、MACブロック１８０１に設けられ、通話データを検出した場合に、その通話データの処理を優先させる処理を行う。２１０１は受信バッファメモリで、例えばＳＤＲＡＭ４７内に設けられる。また、２１０２は優先処理バッファで、パケットチェックブロック１８０４でチェックされた通話データが記憶される。つまり、パケットチェックブロック１８０４は、音声パケットをチェックし、優先処理される特定の受信バッファとして機能する優先処理バッファ２１０２に転送される。
【０２５３】
図２３は、図２２に示した受信バッファメモリ２１０２を含む受信バッファ全体の詳細構成を説明するブロック図である。なお、図４と同一のものには同一の符号を付してある。また、本実施形態では、通話データ以外のデータは、バッファメモリ１１２〜１１５に格納され、バッファメモリ１１２〜１１５でリングバッファが構成される。
【０２５４】
図２３において、制御メモリ２１０２−３には、データ通信を優先させることを示す優先フラグが立てられており、音声データは他の受信画像データよりも優先して、ジッタ吸収バッファあるいは音声復号器へと転送される。なお、データ通信処理において、優先処理バッファ２１０２が優先処理されるように固定されていてもよい。
【０２５５】
本実施形態によれば、LANC６２で、ネットワークを介して受信したデータが、音声データかいなかを判断し、音声データであった場合には、受信した音声データを特定のエリアである優先処理バッファ２１０２に転送する。そして、優先処理バッファ２１０２の音声データは、ファクシミリデータ受信データよりも、優先してジッタ吸収バッファあるいは複号器へ転送することができる。
【０２５６】
なお、優先処理するバッファメモリに音声データを蓄積して優先処理する場合に、優先処理するバッファメモリは、固定領域、例えば優先処理バッファ２１０２を用いもよい。また、制御メモリ２１０２の特定のフラグにより、優先順位を決めるようにしてもよい。
【０２５７】
さらに、その他の通信のバッファの転送が行われているときに、音声バッファにデータが格納された場合に、他のバッファの転送にウエイトをかける制御を実行してもよい。これにより、音声データをさらに優先的に転送することができる。
【０２５８】
この場合の具体的なデータ通信処理は、音声データを格納するバッファエリアにデータが蓄積されている場合は、その他のバッファエリアに蓄積されているバッファの転送にウエイトをかける。そして、該音声バッファの転送が終了した後に他のバッファの転送を再開する制御となる。
【０２５９】
〔第１５実施形態〕
上記実施形態では、図２３に示す制御メモリ２１０２−３にデータ通信を優先させることを示す優先フラグを記憶することで、音声データの通信を優先処理する場合について説明した。以下、上記優先フラグの情報に代えて、図３６に示したネットワークレイアにおけるレイヤ７１のフィールド７２に設定されるＣＯＳフィールドの情報を利用する場合について説明する。
【０２６０】
図２４は、本実施形態を示すデータ通信装置における第８のデータ通信処理手順の一例を示すフローチャートである。本例は、レイヤ７１のフィールド７２に設定されるＣＯＳフィールドの情報に基づいて通話データでの処理を優先処理指定する例である。なお、Ｓ２３０１〜Ｓ２３０４は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０２６１】
まず、コントローラ部３１３は、音声符号化データあるいは音声符号化データを示す優先度情報がメモリ中に設定されているかどうかを判断する。ここで、ＳＤＲＡＭ４７中に設定されていないと判断した場合は、Ｓ２３０２に進む。
【０２６２】
そして、Ｓ２３０３で、音声データを優先処理するための情報は、ネットワークレイヤ中の情報により優先処理を指定して、Ｓ２３０４で、次に処理に移行する。
【０２６３】
なお、ネットワークレイヤ中の情報の例としては、ＳＩＰポート番号、ＣＯＳ、ＴＯＳのいずれかである。
【０２６４】
具体的には、図３６のネットワークレイアの例で対応づけると、レイヤ７１のフィールド７２においては、音声パケットを識別するのにＣＯＳフィールを使用する。
【０２６５】
また、レイヤ７３のフィールド７４においては、IPアドレスで音声とデータを区別するのにTOS（TYPE OF SERVICE）を使用する。RFC1349により定義されるIPプレ全素フィールドでは、上位３ビットを優先度を示すフィールドに使用する。又、RFC2474で定義されるDSCP（DIFFERENTIATED SERVICES CODE POINT）では、TOSフィールドの上位６ビットを優先度の指定に用いる。
【０２６６】
さらに、レイヤ７５のフィールド７６では、TCP,UDPのポート番号を使う。代表的なアプリケーションを特定できる。ポート番号が５０６０ならばSIPなのでIP電話の制御信号を優先的に処理できる。
【０２６７】
さらには、IP電話の制御信号を優先的に処理に利用可能な情報として、ＲＴＰ情報、音声符号化方式の情報、G.711を含有する、音声符号化方式の情報等が好適である。
【０２６８】
なお、データ通信装置は、ネットワーク通信を行うTCP/IP,UDP、RTPを含有するプロトコル制御手段を含むネットワークコントローラを有する。そして、送信バッファメモリに蓄積された音声符号化データを抽出して優先的に処理し、COS,TOS,SIPのポート番号５０６０を付加してネットワークへと送出する。
【０２６９】
〔第１６実施形態〕
図２５は、本発明の第１６実施形態を示すデータ通信装置の要部構成を説明するブロック図である。本例は、プロトコル信号の制御、パケットのヘッダの制御等も含めて制御するネットワークコントローラを搭載し、バッファメモリに蓄積された音声データを優先して処理する例である。なお、図２２と同一のものには同一の符号を付してある。
【０２７０】
図２５において、２４００は送信バッファ部で、音声パケット２４０１が格納された状態である。２４０２はネットワーク制御部で、ネットワークコントローラの機能と、ＭＡＣブロック１８０１の機能とを兼ねている。なお、ネットワークコントローラは、ホスト側のＣＰＵとは、別のＣＰＵを備えてデータ通信を制御しても良い。
【０２７１】
本実施形態では、送信バッファ部２４００に格納された情報が音声パケット２４０１であることをパケットチェックブロック１８０５が検出したら、ネットワーク制御部が音声パケットを優先してネットワーク上に送信する制御を行う。
【０２７２】
具体的には、送信すべきパケットが生成された後に、パケットチェックブロック１８０５がその内容をチェックして優先して、ＰＨＹ部６３へと送る制御を行うことで実現する。
【０２７３】
〔第１７実施形態〕
図２６は、本発明の第１７実施形態を示すデータ通信装置の要部構成を説明するブロック図である。本例は、ヘッダの生成等をホスト側のＣＰＵコアではなくて、ネットワークコントロールユニットが行う例である。また、音声データを優先して処理する場合に、ＣＯＳ情報、ＴＯＳ情報、ＳＩＰを表すポート番号５０６０を使用する例である。なお、図２２と同一のものには同一の符号を付してある。
【０２７４】
図２６において、２５０１はコントローラ部２５０１で、ＣＰＵ等を備える。４７−１は送信データブロックで、優先データ４７−３を記憶可能に構成されている。４７−２は受信データブロックで、優先データブロック４７−４が確保されている。
【０２７５】
２５０２はインテリジェントなネットワークコントロールユニットで、データ解析部２５０２−１、２５０２−３、ＣＰＵ２５０２−２を備える。つまり、２５１０は送信パケットである。２５２０は受信パケットである。
【０２７６】
本実施形態では、データ解析部２５０２−１が優先データ４７−３を解析することで、音声データの優先処理を制御する。なお、優先データ４７−３として使用する情報は、ＣＯＳ情報、ＴＯＳ情報、ＳＩＰを表すポート番号５０６０、ＲＴＰ情報、音声符号化方式の情報を使用する例のいずれでもよい。
【０２７７】
〔第１８実施形態〕
第１５実施形態では、データ通信装置はネットワーク通信を行うTCP/IP,UDP、RTPを含有するプロトコル制御手段を含むネットワークコントローラを備えている。そして、このネットワークコントローラが送信バッファメモリに蓄積された音声符号化データを抽出して優先的に処理し、COS,TOS,SIPのポート番号５０６０を付加してネットワークへと送出する場合について説明した。以下、受信側のデータ通信装置におけるパケット処理について説明する。
【０２７８】
図２７は、本実施形態を示すデータ通信装置における第９のデータ通信処理手順の一例を示すフローチャートである。本例は、ネットワークを介して受信する通話データの優先処理例である。なお、Ｓ２６０１〜Ｓ２６０７は各ステップを示す。また、各ステップは、ＭＦＰ１２１のネットワークコントローラ部がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０２７９】
なお、ＭＡＣブロック１８０１は、ＰＨＹ部６３を介して受信したパケットを受け取りと、その受信したパケットをパケットチェックブロック１８０２で音声データを優先処理するための情報が付加されているかどうかを判断する。
【０２８０】
まず、Ｓ２６０１で、パケットチェックブロック１８０２は、受信パケットがＲＴＯデータであるか否かを判断する。ここで、受信パケットがＲＴＯデータであると判断した場合は、Ｓ２６０７へ進み、ＲＴＯデータを優先処理情報として、受信バッファメモリ２１０１の優先処理バッファ２１０２へ転送する。
【０２８１】
一方、Ｓ２６０１で、受信パケットがＲＴＯデータでないと判断した場合は、Ｓ２６０２へ進み、パケットチェックブロック１８０２は、受信パケットがＳＩＰのポート番号５０６０であるか否かを判断する。ここで、受信パケットがＳＩＰのポート番号５０６０であると判断した場合は、Ｓ２６０７へ進み、ＳＩＰのポート番号５０６０を優先処理情報として、受信バッファメモリ２１０１の優先処理バッファ２１０２へ転送する。
【０２８２】
一方、Ｓ２６０２で、受信パケットがＳＩＰのポート番号５０６０でないと判断した場合は、Ｓ２６０３へ進み、パケットチェックブロック１８０２は、受信パケットがＣＯＳ情報であるか否かを判断する。ここで、受信パケットがＣＯＳ情報であると判断した場合は、Ｓ２６０７へ進み、ＣＯＳ情報を優先処理情報として、受信バッファメモリ２１０１の優先処理バッファ２１０２へ転送する。
【０２８３】
一方、Ｓ２６０３で、受信パケットがＣＯＳ情報でないと判断した場合は、Ｓ２６０４へ進み、パケットチェックブロック１８０２は、受信パケットがＴＯＳ情報であるか否かを判断する。ここで、受信パケットがＴＯＳ情報であると判断した場合は、Ｓ２６０７へ進み、ＴＯＳ情報を優先処理情報として、受信バッファメモリ２１０１の優先処理バッファ２１０２へ転送する。
【０２８４】
一方、Ｓ２６０４で、受信パケットがＴＯＳ情報でないと判断した場合は、Ｓ２６０５へ進み、パケットチェックブロック１８０２は、受信パケットがＧ．７１１等の音声符号化データであるか否かを判断する。ここで、受信パケットがＧ．７１１等の音声符号化データであると判断した場合は、Ｓ２６０７へ進み、Ｇ．７１１等の音声符号化データを優先処理情報として、受信バッファメモリ２１０１の優先処理バッファ２１０２へ転送する。
【０２８５】
一方、Ｓ２６０５で、パケットチェックブロック１８０２は、受信パケットがＧ．７１１等の音声符号化データでないと判断した場合は、Ｓ２６０６で次の処理に移行する。
【０２８６】
本実施形態によれば、ネットワーク通信を行うTCP/IP,UDP、RTPを含有するプロトコル制御手段を含むネットワークコントローラは、ネットワークからのパケットのCOS,TOS,RTP、SIPのポート番号５０６０をピックアップする。そして、ピックアップしたてCOS,TOS,RTP、SIPのポート番号５０６０を解析して優先的に処理して概受信データを格納するメモリに優先して格納することができる。
【０２８７】
〔第１９実施形態〕
以下、本実施形態を示すデータ通信装置における送話データに対する優先処理について説明する。
【０２８８】
図２８は、本実施形態を示すデータ通信装置における第１０のデータ通信処理手順の一例を示すフローチャートである。本例は、ネットワークを介して受信する通話データの第１の優先処理例である。なお、Ｓ２７０１〜Ｓ２７０６は各ステップを示す。また、各ステップは、ＭＦＰ１２１のＬＡＮＣ６２がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０２８９】
まず、ＬＡＮＣ６２は、Ｓ２７０１で、符号化された送話データにＲＴＰ信号を付加する。そして、Ｓ２７０２で、ＬＡＮＣ６２は、送信バッファ部１３０２−１に格納されているITU-T  T.37送信データよりも優先した、優先バッファ１３０２−２に送話データを転送する。
【０２９０】
次に、Ｓ２７０３で、ＬＡＮＣ６２は、ITU-T  T.37送信データよりも優先して、送信バッファ部１３０２に転送された送話データをＰＨＹ部６３に転送する。
【０２９１】
そして、Ｓ２７０４で、例えばタイマ制御で２０ｍｓ経過を待機し、２０ｍｓ経過したら、Ｓ２７０５で、ＬＡＮＣ６２は、送話データが終了しているかどうかを判断する。ここで、終了していないと判断した場合は、Ｓ２７０１へ戻る。
【０２９２】
一方、Ｓ２７０５で、送話データが終了していると判断した場合は、Ｓ２７０６で、次処理へ移行する。
【０２９３】
ついて説明する。
【０２９４】
図２９は、本実施形態を示すデータ通信装置における第１１のデータ通信処理手順の一例を示すフローチャートである。本例は、ネットワークを介して受信する通話データの第２の優先処理例である。なお、Ｓ２８０１〜Ｓ２８０６は各ステップを示す。また、各ステップは、ＭＦＰ１２１のＬＡＮＣ６２がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０２９５】
まず、ＬＡＮＣ６２は、Ｓ２８０１で、符号化された送話データにＲＴＰ信号を付加する。そして、Ｓ２８０２で、ＬＡＮＣ６２は、送信バッファ部１３０２−１に格納されているITU-T  T.38送信データよりも優先した、優先バッファ１３０２−２に送話データを転送する。
【０２９６】
次に、Ｓ２８０３で、ＬＡＮＣ６２は、ITU-T  T.38送信データよりも優先して、送信バッファ部１３０２に転送された送話データをＰＨＹ部６３に転送する。
【０２９７】
そして、Ｓ２８０４で、例えばタイマ制御で２０ｍｓ経過を待機し、２０ｍｓ経過したら、Ｓ２８０５で、ＬＡＮＣ６２は、送話データが終了しているかどうかを判断する。ここで、終了していないと判断した場合は、Ｓ２８０１へ戻る。
【０２９８】
一方、Ｓ２８０５で、送話データが終了していると判断した場合は、Ｓ２８０６で、次処理へ移行する。
【０２９９】
図３０は、本実施形態を示すデータ通信装置における第１２のデータ通信処理手順の一例を示すフローチャートである。本例は、ネットワークを介して受信する通話データの第３の優先処理例である。なお、Ｓ２９０１〜Ｓ２９０６は各ステップを示す。また、各ステップは、ＭＦＰ１２１のＬＡＮＣ６２がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０３００】
まず、ＬＡＮＣ６２は、Ｓ２９０１で、符号化された送話データにＲＴＰ信号を付加する。そして、Ｓ２９０２で、ＬＡＮＣ６２は、送信バッファ部１３０２−１に格納されているＭＦＰのスキャナ部が読み取ったスキャンデータデータよりも優先した、優先バッファ１３０２−２に送話データを転送する。
【０３０１】
次に、Ｓ２９０３で、ＬＡＮＣ６２は、スキャンデータデータよりも優先して、送信バッファ部１３０２に転送された送話データをＰＨＹ部６３に転送する。
【０３０２】
そして、Ｓ２９０４で、例えばタイマ制御で２０ｍｓ経過を待機し、２０ｍｓ経過したら、Ｓ２９０５で、ＬＡＮＣ６２は、送話データが終了しているかどうかを判断する。ここで、終了していないと判断した場合は、Ｓ２９０１へ戻る。
【０３０３】
一方、Ｓ２９０５で、送話データが終了していると判断した場合は、Ｓ２９０６で、次処理へ移行する。
【０３０４】
図３１は、本実施形態を示すデータ通信装置における第１３のデータ通信処理手順の一例を示すフローチャートである。本例は、ネットワークを介して受信する通話ジョブに対する第１の優先処理例である。なお、Ｓ３００１〜Ｓ３００６は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。なお、本実施形態では、ＩＰ電話ジョブ、コピージョブ、ＵＳＢスキャンジョブ、ＵＳＢプリントジョブ、インターネットスキャンジョブ、インターネットプリントジョブを処理例である。
【０３０５】
まず、コントローラ部１３１は、並列処理可能なジョブがある場合は、Ｓ３００１で、ＩＰ電話ジョブ（ＩＰ電話ＪＯＢ）を優先実行する。次に、Ｓ３００２で、コントローラ部１３１は、コピージョブを優先実行する。次に、Ｓ３００３で、ＵＳＢスキャンジョブを優先実行する。次に、Ｓ３００４で、ＵＳＢプリントジョブを優先実行する。次に、Ｓ３００５で、インターネットスキャンジョブを優先実行する。次に、Ｓ３００６で、インターネットプリントジョブを優先実行する。
【０３０６】
このように属性の異なるジョブが競合する場合に、データ通信装置を備えるＭＦＰは、ＩＰ電話ジョブ（ＩＰ電話ＪＯＢ）を優先実行することで、音声データ通信に負担がかかるのを回避することができる。
【０３０７】
図３２は、本実施形態を示すデータ通信装置における第１４のデータ通信処理手順の一例を示すフローチャートである。本例は、ネットワークを介して受信する通話ジョブに対する第２の優先処理例である。なお、Ｓ３１０１〜Ｓ３１０４は各ステップを示す。また、各ステップは、ＭＦＰ１２１のコントローラ部１３１がＲＯＭ等より制御プログラムをＳＤＲＡＭ上にロードして実行することで実現される。
【０３０８】
まず、コントローラ部１３１は、並列処理可能なジョブがある場合は、Ｓ３１０１で、ＩＰ電話ジョブ（ＩＰ電話ＪＯＢ）を優先実行する。次に、Ｓ３１０２で、コントローラ部１３１は、インターネットプリントジョブを優先実行する。そして、Ｓ３１０２で、コントローラ部１３１は、インターネットＦＡＸジョブを優先実行する。そして、Ｓ３１０３で、コントローラ部１３１は、インターネットスキャンジョブを優先実行する。
【０３０９】
これにより、ネットワークを介してプリントデータを受信し印刷することが可能な通信装置で、プリントデータよりも音声データを優先処理することが可能となる。
【０３１０】
同様に、デジタルカメラからＵＳＢインタフェースを介してプリントデータを受信し印刷することが可能なデータ通信装置において、プリントデータよりも音声データを優先的にメモリから転送する、あるいはメモリに転送することができる。
【０３１１】
また、ホストＰＣからＵＳＢインタフェースを介してプリントデータを受信し印刷することが可能なデータ通信装置で、プリントデータよりも音声データを優先的にメモリから転送する、あるいはメモリに転送することができる。
【０３１２】
さらに、  ホストＰＣからＵＳＢインタフェースを介してスキャンデータを転送することが可能なデータ通信装置で、スキャンデータよりも音声データを優先的にメモリから転送する、あるいはメモリに転送することができる。
【０３１３】
また、コピー機能が可能なデータ通信装置で、コピーデータよりも音声データを優先的にメモリから転送する、あるいはメモリに転送することができる。
【０３１４】
〔第２０実施形態〕
以下、図３３に示すメモリマップを参照して本発明に係るデータ通信装置で読み取り可能なデータ処理プログラムの構成について説明する。
【０３１５】
図３３は、本発明に係るデータ通信装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【０３１６】
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０３１７】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０３１８】
本実施形態における図６、図８、図１３、図１５、図１７、図１８、図２１、図２４、図２７、図２８、図２９、図３０に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０３１９】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０３２０】
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０３２１】
従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０３２２】
プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【０３２３】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０３２４】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバやｆｔｐサーバ等も本発明の請求項に含まれるものである。
【０３２５】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０３２６】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。例えばそのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０３２７】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０３２８】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から排除するものではない。
【０３２９】
本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。
【図面の簡単な説明】
【０３３０】
【図１】本発明の第１実施形態を示すデータ通信装置を適用する複合機の構成を説明するブロック図である。
【図２】本実施形態を示すデータ通信装置を適用する画像形成装置のデータ通信制御部の構成を説明するブロック図である。
【図３】図１に示したデータ通信装置の送信バッファの状態を説明するブロック図である。
【図４】図１に示したデータ通信装置の送信バッファと受信バッファの構成を説明するブロック図である。
【図５】本実施形態を示すデータ通信装置を適用するネットワークシステムの一例を示すブロック図である。
【図６】本実施形態を示すデータ通信装置における第１のデータ通信処理手順の一例を示すフローチャートである。
【図７】本実施形態を示すデータ通信装置の受信バッファの状態を説明するブロック図である。
【図８】本実施形態を示すデータ通信装置における第２のデータ通信処理手順の一例を示すフローチャートである。
【図９】本発明の第３実施形態を示すデータ通信装置を適用可能な画像形成装置の一例を示すブロック図である。
【図１０】図９に示したＳＤＲＡＭに確保される送信バッファメモリからPHYへのデータの流れを説明する図である。
【図１１】図１０に示したＰＨＹ部から受信バッファメモリへのデータの流れを説明する図である。
【図１２】図９に示したデータ通信装置によるマルチタスク処理を説明するブロック図である。
【図１３】本実施形態を示すデータ通信装置における第３のデータ通信処理手順の一例を示すフローチャートである。
【図１４】本発明の第７実施形態をデータ通信装置の要部構成を説明するブロック図である。
【図１５】本実施形態を示すデータ通信装置における第４のデータ通信処理手順の一例を示すフローチャートである。
【図１６】本発明の第８実施形態を示すデータ通信装置の要部構成を説明するブロック図である。
【図１７】本実施形態を示すデータ通信装置における第５のデータ通信処理手順の一例を示すフローチャートである。
【図１８】本実施形態を示すデータ通信装置における第６のデータ通信処理手順の一例を示すフローチャートである。
【図１９】本発明の第１１実施形態を示すデータ処理装置の要部構成を説明するブロック図である。
【図２０】本発明の第１３実施形態を示すデータ通信装置のＰＰＲ出力手段の動作を説明する図である。
【図２１】本実施形態を示すデータ通信装置における第７のデータ通信処理手順の一例を示すフローチャートである。
【図２２】本発明の第１４実施形態を示すデータ通信装置の要部構成を説明するブロック図である。
【図２３】図２２に示した受信バッファを含む受信バッファ全体の詳細構成を説明するブロック図である。
【図２４】本実施形態を示すデータ通信装置における第８のデータ通信処理手順の一例を示すフローチャートである。
【図２５】本発明の第１６実施形態を示すデータ通信装置の要部構成を説明するブロック図である。
【図２６】本発明の第１７実施形態を示すデータ通信装置の要部構成を説明するブロック図である。
【図２７】本実施形態を示すデータ通信装置における第９のデータ通信処理手順の一例を示すフローチャートである。
【図２８】本実施形態を示すデータ通信装置における第１０のデータ通信処理手順の一例を示すフローチャートである。
【図２９】本実施形態を示すデータ通信装置における第１１のデータ通信処理手順の一例を示すフローチャートである。
【図３０】本実施形態を示すデータ通信装置における第１２のデータ通信処理手順の一例を示すフローチャートである。
【図３１】本実施形態を示すデータ通信装置における第１３のデータ通信処理手順の一例を示すフローチャートである。
【図３２】本実施形態を示すデータ通信装置における第１４のデータ通信処理手順の一例を示すフローチャートである。
【図３３】本発明に係るデータ通信装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【図３４】この種のＩＰ電話システムの全体構成を説明する図である。
【図３５】図３４に示したルータのキュー機能を説明するブロック図である。
【図３６】図３４に示したＶＯＩＰゲートウエイ７のネットワークレイアを説明する図である。
【符号の説明】
【０３３１】
４１  音声入力手段
４６  ＳＤＲＡＭ
４９  音声出力手段
６１  ＭＥＭＣ
６２  ＬＡＮＣ
６３  ＰＨＹ
【図１】
2008131444.tif 000003
【図２】
2008131444.tif 000004
【図３】
2008131444.tif 000005
【図４】
2008131444.tif 000006
【図５】
2008131444.tif 000007
【図６】
2008131444.tif 000008
【図７】
2008131444.tif 000009
【図８】
2008131444.tif 000010
【図９】
2008131444.tif 000011
【図１０】
2008131444.tif 000012
【図１１】
2008131444.tif 000013
【図１２】
2008131444.tif 000014
【図１３】
2008131444.tif 000015
【図１４】
2008131444.tif 000016
【図１５】
2008131444.tif 000017
【図１６】
2008131444.tif 000018
【図１７】
2008131444.tif 000019
【図１８】
2008131444.tif 000020
【図１９】
2008131444.tif 000021
【図２０】
2008131444.tif 000022
【図２１】
2008131444.tif 000023
【図２２】
2008131444.tif 000024
【図２３】
2008131444.tif 000025
【図２４】
2008131444.tif 000026
【図２５】
2008131444.tif 000027
【図２６】
2008131444.tif 000028
【図２７】
2008131444.tif 000029
【図２８】
2008131444.tif 000030
【図２９】
2008131444.tif 000031
【図３０】
2008131444.tif 000032
【図３１】
2008131444.tif 000033
【図３２】
2008131444.tif 000034
【図３３】
2008131444.tif 000035
【図３４】
2008131444.tif 000036
【図３５】
2008131444.tif 000037
【図３６】
2008131444.tif 000038