JP2008131444A - データ通信装置、データ通信方法、記憶媒体、プログラム - Google Patents

Abstract

【課題】 音声データ通信とファクシミリデータ通信とを同時に実行する場合に、音声データ通信を優先して実行して、音声データの転送遅延による音質の低下を防止した通信処理を効率よく行うことである。
【解決手段】 ＩＰＦＡＸ送信タスクが起動中でないと判断した場合は、Ｓ１６０７で、コントローラ部１３１がネットワークを介して送信すべき送信データが送信バッファ部１３０２−１に一定量以上格納されているかを判断する。ここで、一定量の送信データが格納されていると判断した場合は、Ｓ１６０８で、送話すべき音声データの送信にウエイトをかける。Ｓ１６０７で、一定量の送信データが格納されていないと判断した場合は、Ｓ１６０９で、送信バッファ部１３０２−１に記憶される送信データの送話起動をＯＫとする構成を特徴とする。
【選択図】 図１７

Description

本発明は、画像データおよび音声データとを同時に送受信可能なデータ通信装置における音声データの通信処理に関するものである。

従来、インターネット関連技術により、インターネット網（ＩＰ通信網）を介したパケット通信を利用して音声データと画像データとをやり取り可能なＩＰ通信システムが提案されている。

下記特許文献１には、ＩＰ通信網における音声セッションとファクシミリデータセッションを同時に確率するＨ．３２３環境下でセッションを使い分けることが記載されている。

さらに、下記特許文献２には、テレビ電話において、通信品質を敢えて下げることで通信料金を低くできるシステムが記載されている。この際、オン制御データと映像データとで優先度を付けてデータ通信することが記載されている。

図３４は、この種の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へのデータの流れを説明する図である。 図１０に示したＰＨＹ部から受信バッファメモリへのデータの流れを説明する図である。 図９に示したデータ通信装置によるマルチタスク処理を説明するブロック図である。 本実施形態を示すデータ通信装置における第３のデータ通信処理手順の一例を示すフローチャートである。 本発明の第７実施形態をデータ通信装置の要部構成を説明するブロック図である。 本実施形態を示すデータ通信装置における第４のデータ通信処理手順の一例を示すフローチャートである。 本発明の第８実施形態を示すデータ通信装置の要部構成を説明するブロック図である。 本実施形態を示すデータ通信装置における第５のデータ通信処理手順の一例を示すフローチャートである。 本実施形態を示すデータ通信装置における第６のデータ通信処理手順の一例を示すフローチャートである。 本発明の第１１実施形態を示すデータ処理装置の要部構成を説明するブロック図である。 本発明の第１３実施形態を示すデータ通信装置のＰＰＲ出力手段の動作を説明する図である。 本実施形態を示すデータ通信装置における第７のデータ通信処理手順の一例を示すフローチャートである。 本発明の第１４実施形態を示すデータ通信装置の要部構成を説明するブロック図である。 図２２に示した受信バッファを含む受信バッファ全体の詳細構成を説明するブロック図である。 本実施形態を示すデータ通信装置における第８のデータ通信処理手順の一例を示すフローチャートである。 本発明の第１６実施形態を示すデータ通信装置の要部構成を説明するブロック図である。 本発明の第１７実施形態を示すデータ通信装置の要部構成を説明するブロック図である。 本実施形態を示すデータ通信装置における第９のデータ通信処理手順の一例を示すフローチャートである。 本実施形態を示すデータ通信装置における第１０のデータ通信処理手順の一例を示すフローチャートである。 本実施形態を示すデータ通信装置における第１１のデータ通信処理手順の一例を示すフローチャートである。 本実施形態を示すデータ通信装置における第１２のデータ通信処理手順の一例を示すフローチャートである。 本実施形態を示すデータ通信装置における第１３のデータ通信処理手順の一例を示すフローチャートである。 本実施形態を示すデータ通信装置における第１４のデータ通信処理手順の一例を示すフローチャートである。 本発明に係るデータ通信装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。 この種のＩＰ電話システムの全体構成を説明する図である。 図３４に示したルータのキュー機能を説明するブロック図である。 図３４に示したＶＯＩＰゲートウエイ７のネットワークレイアを説明する図である。

符号の説明

４１ 音声入力手段
４６ ＳＤＲＡＭ
４９ 音声出力手段
６１ ＭＥＭＣ
６２ ＬＡＮＣ
６３ ＰＨＹ

Claims (16)

1. インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置であって、
   前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する受信バッファと、
   前記受信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定手段と、
   前記決定手段により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記受信バッファに記憶された前記音声データの受信処理を優先させる通信制御手段と、
   を有することを特徴とするデータ通信装置。
2. 前記通信制御手段は、前記受信バッファに記憶された前記ファクシミリデータの処理開始を遅延させて、前記受信バッファに記憶された前記音声データの受信処理を優先させることを特徴とする請求項１記載のデータ通信装置。
3. 前記受信バッファは、優先順位の異なるバッファ部を複数備え、
   受信する前記音声データを前記優先順位の高いいずれかのバッファ部に転送する転送制御手段を備え、
   前記通信制御手段は、前記優先順位の高いいずれかのバッファ部に転送された音声データの受信処理を優先させることを特徴とする請求項１記載のデータ通信装置。
4. 前記決定手段は、前記インターネット網を介して相手装置から受信するパケットを解析して、受信した音声データを前記優先順位の高いいずれかのバッファ部に転送することを特徴とする請求項１または３のいずれかに記載のデータ通信装置。
5. インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置であって、
   前記インターネット網を介して相手装置との通信により音声通信に基づく音声データまたはファクシミリ通信に基づくファクシミリデータを記憶する受信バッファと、
   前記受信バッファにファクシミリデータが一定量記憶された状態に遷移しているかどうかを判別する判別手段と、
   前記判別手段により前記受信バッファに前記ファクシミデータが一定量記憶されていると判別した場合に、前記音声データの通話要求の起動を制限させる通信制御手段と、
   を有することを特徴とするデータ通信装置。
6. 前記判別手段により前記受信バッファに前記ファクシミデータが一定量記憶されていると判別した場合に、通話要求を待機させるメッセージを表示する表示手段を有することを特徴とする請求項１〜５のいずれかに記載のデータ通信装置。
7. インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置であって、
   前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する送信バッファと、
   前記送信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定手段と、
   前記決定手段により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記送信バッファに記憶された前記音声データの送信処理を優先させる通信制御手段と、
   を有することを特徴とするデータ通信装置。
8. インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置におけるデータ通信方法であって、
   前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する受信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定工程と、
   前記決定工程により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記受信バッファに記憶された前記音声データの受信処理を優先させる通信制御工程と、
   を有することを特徴とするデータ通信方法。
9. 前記通信制御工程は、前記受信バッファに記憶された前記ファクシミリデータの処理開始を遅延させて、前記受信バッファに記憶された前記音声データの受信処理を優先させることを特徴とする請求項８記載のデータ転送方法。
10. 優先順位の異なるバッファ部を複数備える受信バッファは、
    優先順位の異なるバッファ部を複数備える受信バッファのうち、受信する前記音声データを前記優先順位の高いいずれかのバッファ部に転送する転送制御工程を備え、
    前記通信制御工程は、前記優先順位の高いいずれかのバッファ部に転送された音声データの受信処理を優先させることを特徴とする請求項８記載のデータ通信方法。
11. 前記決定工程は、前記インターネット網を介して相手装置から受信するパケットを解析して、受信した音声データを前記優先順位の高いいずれかのバッファ部に転送することを特徴とする請求項８または１０のいずれかに記載のデータ通信方法。
12. インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置におけるデータ通信方法であって、
    前記インターネット網を介して相手装置との通信により音声通信に基づく音声データまたはファクシミリ通信に基づくファクシミリデータを記憶する受信バッファにファクシミリデータが一定量記憶された状態に遷移しているかどうかを判別する判別工程と、
    前記判別工程により前記受信バッファに前記ファクシミデータが一定量記憶されていると判別した場合に、前記音声データの通話要求の起動を制限させる通信制御工程と、
    を有することを特徴とするデータ通信方法。
13. 前記判別工程により前記受信バッファに前記ファクシミデータが一定量記憶されていると判別した場合に、通話要求を待機させるメッセージを表示手段に表示する表示工程を有することを特徴とする請求項１２に記載のデータ通信方法。
14. インターネット網を介して相手装置との間で音声通信と、ファクシミリ通信とを行うデータ通信装置におけるデータ通信方法であって、
    前記インターネット網を介して相手装置との音声通信に基づく音声データまたは相手装置とのファクシミリ通信に基づくファクシミリデータを記憶する送信バッファに記憶される音声データまたはファクシミリデータの処理状態を判別して音声データの処理を優先させるかどうかを決定する決定工程と、
    前記決定工程により前記受信バッファに前記音声通信による音声データを優先させると決定した場合に、前記ファクシミリデータの通信を維持させながら、前記送信バッファに記憶された前記音声データの送信処理を優先させる通信制御工程と、
    を有することを特徴とするデータ通信方法。
15. 請求項８〜１４のいずれかに記載のデータ通信方法をコンピュータに実行させるためのプログラムを格納したことを特徴とするコンピュータが読み取り可能な記憶媒体。
16. 請求項８〜１４のいずれかに記載のデータ通信方法をコンピュータに実行させることを特徴とするプログラム。

Images