通信装置
【課題】 受信データの処理中にセッション確立要求を受けたとしても、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能な通信装置を提供する。
【解決手段】 ネットワーク複合機１を構成するＬＡＮインターフェース１０は、先に受信したデータの処理中にＰＣ３１からセッション確立要求信号を受信した場合、ＰＣ３１との間にセッションを確立するとともに、ＰＣ３１から受信したデータの種類を解析し、処理中のデータと同じ種類の場合には、セッションを張った状態でＰＣ３１に対してデータの送信を禁止する持続接続制御を実行し、異なる種類の場合にはＰＣ３１に対してデータの送信を許可する。また、ＬＡＮインターフェース１０は、先のデータ処理が終了した時点で持続接続制御を終了し、ＰＣ３１に対してデータの送信を許可する。
【解決手段】 ネットワーク複合機１を構成するＬＡＮインターフェース１０は、先に受信したデータの処理中にＰＣ３１からセッション確立要求信号を受信した場合、ＰＣ３１との間にセッションを確立するとともに、ＰＣ３１から受信したデータの種類を解析し、処理中のデータと同じ種類の場合には、セッションを張った状態でＰＣ３１に対してデータの送信を禁止する持続接続制御を実行し、異なる種類の場合にはＰＣ３１に対してデータの送信を許可する。また、ＬＡＮインターフェース１０は、先のデータ処理が終了した時点で持続接続制御を終了し、ＰＣ３１に対してデータの送信を許可する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置に関し、特に、ネットワークを介して接続される通信端末との間にセッションを形成してコネクション型のデータ通信を行なう通信装置に関する。
【背景技術】
【０００２】
従来から、呼制御プロトコルを用いて画像データの通信を行なう画像通信装置が知られている。このような画像通信装置として、特許文献１には、並行して複数の機器と通信が可能な画像通信装置が記載されている。この画像通信装置によれば、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）呼接続中に他の機器からＳＩＰ呼接続を要求された場合、先のＳＩＰ呼接続が終了した後で他の機器からのＳＩＰ呼接続要求に応答する。すなわち、最初のＳＩＰプロトコル処理が終了し、メディアセッションに移行することにより、一時的に中断していた他の機器との呼制御通信が再開される。他の機器は、画像通信装置がデータ受信可能になったことで、画像通信装置に対して直接ＡＣＫ信号を送信し、これからデータを送信することを伝える。そして、メディアセッションに移行し、画像データを画像通信装置に送信する。最初の機器から画像通信装置へのメディアセッションと他の機器から画像通信装置へのメディアセッションとが重なる間、画像通信装置は複数の機器からの画像データを同時に並行して受信する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−２０５６１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ここで、複数の機器からの画像データを同時に受信するためには、受信された画像データに対してデータ処理が実行される間、該画像データを記憶しておくための大容量のメモリが必要となる。特に、同時に並行して受信される複数の画像データを処理するリソースが１つだけの場合には、複数の画像データを同時に処理することができないため、より大容量のメモリを設けることが要求される。
【０００５】
一方、メモリの大容量化を回避するためには、複数のデータを並行して受信しない構成、すなわち、例えば１つの通信端末とのセッションが確立されている間は他の通信端末とのセッションを張らない構成とすることも考えられる。しかしながら、このような構成にした場合、他の通信端末は所定の時間を空けてセッション確立要求を繰り返し送出することとなる。そのため、先にセッションが張られていた通信端末から受信されたデータの処理が終了し、他の通信端末とセッションを張ることが可能な状態になったとしても、他の通信端末からセッション確立要求が再送されるまではセッションを張ることができない。そのため、リソースが使用可能になっていているにもかかわらず、受信処理及び受信データのデータ処理を開始することができず、処理の開始が遅れるという問題が生じ得る。さらに、一定時間以上応答が無くタイムアウトした場合には、セッションを確立することができないと判断され、他の通信端末側でエラーとなるおそれがある。
【０００６】
本発明は、上記問題点を解消する為になされたものであり、ネットワークを介して接続される通信端末との間にセッションを形成してデータ通信を行なう通信装置において、受信データの処理中にセッション確立要求を受けたとしても、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能な通信装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る通信装置は、ネットワークを介して通信端末と接続され、該通信端末との間にセッションを形成してデータ通信を行なう通信装置において、通信端末との間でデータの送受信を行なう通信手段と、通信手段により受信されたデータを、該データの種類及び／又はジョブの種類に応じて処理する処理手段とを備え、通信手段が、セッション確立要求信号を受信した場合、該セッション確立要求信号を送信した通信端末との間にセッションを確立するとともに、該通信端末から受信したデータを解析し、処理手段による該データの処理が行えない場合には、セッションを張った状態で該通信端末に対してデータの送信を禁止する持続接続制御を実行し、処理手段による該データの処理が可能な場合には、持続接続制御を実行することなく該通信端末に対してデータの送信を許可することを特徴とする。
【０００８】
本発明に係る通信装置によれば、セッション確立要求信号を受信したときに、受信したデータを処理手段で処理することができない場合、すなわちデータ処理を行なうリソースが空いていない場合には、セッションを張った状態を保持しつつセッション確立要求信号を送信した通信端末によるデータ送信が禁止される。そのため、リソースが利用可能になるまでデータを格納しておく必要がなく、メモリの容量を増大する必要がない。一方、受信したデータを処理手段で処理することができる場合には、すなわちデータ処理を行うリソースが空いているときには、データの送信が許可され、迅速に処理を進めることができる。また、先のデータの処理中に、セッションが張られた状態で後のデータ送信が禁止される持続接続制御が行なわれることにより、先のデータ処理が終了し持続接続制御が終了する時点では既にセッションが張られているため、迅速にデータ受信に移行することができる。さらに、セッション確立要求が受信されたときにセッションが確立されるため、タイムアウトによるセッション確立エラーの発生を防止することができる。以上により、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能となる。
【０００９】
本発明に係る通信装置では、上記通信手段が、通信端末から受信したデータの種類を解析し、該データと同じ種類のデータが、処理手段によって処理されているときには、持続接続制御を実行し、処理手段によって処理されていない場合には、通信端末に対してデータの送信を許可することが好ましい。
【００１０】
このようにすれば、通信端末から受信したデータの種類を解析するとともに、該データと同じ種類のデータが処理手段で処理されているか否かを判断することによって、データ処理を行なうためのリソースが空いているか否かを判断することができる。よって、上述した持続接続制御を実行する必要があるかどうかを適切に判断することができる。
【００１１】
また、本発明に係る通信装置では、上記通信手段が、通信端末から受信したデータのジョブの種類を解析し、該ジョブと同じ種類のジョブのデータが、処理手段によって処理されているときには、持続接続制御を実行し、処理手段によって処理されていない場合には、通信端末に対してデータの送信を許可することが好ましい。
【００１２】
このようにすれば、通信端末から受信したデータのジョブの種類を解析するとともに、該データと同じ種類のジョブのデータが処理手段で処理されているか否かを判断することによって、データ処理を行なうためのリソースが空いているか否かを判断することができる。よって、上述した持続接続制御を実行する必要があるかどうかを適切に判断することができる。
【００１３】
本発明に係る通信装置では、上記通信手段が、持続接続制御を実行した場合に、処理手段によるデータ処理が終了した時点で持続接続制御を終了し、上記セッション確立要求信号を送信した通信端末に対してデータの送信を許可することが好ましい。
【００１４】
この場合、先に実行されていたデータ処理が終了した時点で持続接続制御が終了され、後からセッション確立要求信号を送信した通信端末に対してデータの送信が許可される。すなわち、リソースが利用可能になったときにデータの送信が許可される。よって、処理待ちのデータを一時的に格納するための大容量のメモリを備える必要がない。また、持続接続制御が終了される時点では、既にセッションが張られているため、迅速にデータ通信を開始することが可能となる。
【００１５】
本発明に係る通信装置では、上記通信手段が、通信端末から受信される受信データを一時的に格納する受信バッファを有し、該受信バッファの空き容量に応じた受信可能データ量を所定の通信プロトコルに従って通信端末へ送信するとともに、セッション確立要求信号を送信した通信端末から受信したデータの処理手段による処理が行えない場合には、受信可能データ量が該通信端末の最小送信可能データ量よりも小さくなるように、受信バッファから読み出すデータ量を非持続接続制御時よりも少なくすることが好ましい。
【００１６】
このようにすれば、後からセッション確立要求信号を送信した通信端末から受信したデータの処理を行うことができない場合に、受信可能データ量が該通信端末の最小送信可能データ量よりも小さくなるように、受信バッファから読み出されるデータ量が非持続接続制御時（すなわち通常制御時）よりも少なくされる。よって、該通信端末から受信されるデータ量よりも受信バッファから読み出されるデータ量が少なくなるため、受信バッファの空き容量が減少し、受信可能データ量として該通信端末の最小送信可能データ量よりも小さな値（典型的にはゼロ）が該通信端末に対して送信される。その結果、セッションを張った状態で該通信端末による送信データの送出を抑制すること、すなわち持続接続制御を実現することが可能となる。
【００１７】
また、本発明に係る通信装置では、上記通信手段が、持続接続制御を終了して上記セッション確立要求信号を送信した通信端末に対してデータの送信を許可する場合、受信可能データ量が該通信端末の最小送信可能データ量よりも大きくなるように、受信バッファから読み出すデータ量を持続接続制御時よりも多くすることが好ましい。
【００１８】
この場合、持続接続制御を終了するときに、受信バッファから読み出されるデータ量が持続接続制御時よりも増やされ、受信バッファの空き容量（すなわち受信可能データ量）が通信端末の最小送信可能データ量よりも大きくされる。そして、その空き容量に応じたサイズが受信可能データ量として後からセッション確立要求信号を送信した通信端末に送信される。そのため、該通信端末が送信データを送出することができるようになり、よって、持続接続制御から通常制御に円滑に移行することが可能となる。
【００１９】
なお、本発明に係る通信装置では、上記通信プロトコルとして、ＴＣＰ／ＩＰが好適に利用される。
【発明の効果】
【００２０】
本発明によれば、ネットワークを介して接続される通信端末との間にセッションを形成してコネクション型のデータ通信を行なう通信装置において、受信データの処理中にセッションの確立要求を受けたとしても、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能となる。
【図面の簡単な説明】
【００２１】
【図１】実施形態に係る通信装置が搭載されたネットワーク複合機の全体構成を示すブロック図である。
【図２】ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が異なる場合のネットワーク複合機１によるＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順を示すフローチャートである。
【図３】ネットワーク複合機とＰＣとの間の通信手順を示すシーケンス図である。
【図４】ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が同じ場合のネットワーク複合機１によるＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順を示すフローチャートである。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。なお、各図において、同一要素には同一符号を付して重複する説明を省略する。なお、ここでは、実施形態に係る通信装置をネットワーク複合機（ＭＦＰ）に適用した場合を例にして説明する。また、ネットワーク複合機がＬＡＮを介して２台のパーソナルコンピュータ（以下「ＰＣ」という。特許請求の範囲に記載の通信端末に相当）と接続されているネットワーク構成を例にして説明する。なお、例示するネットワークシステムは、理解を容易にするためにその構成を簡略化したものである。まず、図１を用いて、ネットワーク複合機１の全体構成について説明する。図１は、ＬＡＮ５１に接続されたネットワーク複合機１の全体構成を示すブロック図である。
【００２３】
ネットワーク複合機１は、原稿を読み取り画像データを生成するスキャナ機能、読み取り生成した画像データを用紙に記録する機能（コピー機能）、及びファクシミリ通信により受信した画像データを用紙に記録する機能（ＦＡＸ受信機能）に加え、ＬＡＮ５１を介して接続されているＰＣ３０、ＰＣ３１から受信した画像データを用紙に記録する機能（以下「ＰＣプリント機能」という）を備えている。また、ネットワーク複合機１は、読み取った画像データをファクシミリ送信するＦＡＸ送信機能に加え、外部のＰＣ３０、ＰＣ３１から受信した画像データをファクシミリ送信する機能（以下「ＰＣ−ＦＡＸ機能」という）を備えている。さらに、ネットワーク複合機１は、電子メールを利用してＩＰ網経由で画像データを送受信するインターネットＦＡＸ（以下「ＩＦＡＸ」という）機能等も有している。これらの各機能を実現するためにネットワーク複合機１は、ＬＡＮインターフェース１０、制御部１１、記録部１２、操作部１３、表示部１４、読取部１５、コーデック１６、画像記憶部１７、モデム１８、ＮＣＵ１９、ＩＦＡＸ制御部２０、及び、Ｗｅｂサーバ２１等を備えている。なお、上記各部は通信線２３で相互に通信可能に接続されている。
【００２４】
ＬＡＮインターフェース１０は、各種通信プロトコルの送受信制御処理、及び各種通信プロトコル上のデータ解析処理及びデータ作成処理を行なうネットワークインターフェースである。外部のＰＣ３０、ＰＣ３１とのデータ通信はこのＬＡＮインターフェース１０を通して行われる。ＬＡＮインターフェース１０は、ＬＡＮ５１を介してＰＣ３０、ＰＣ３１に接続されており、ＰＣ３０、ＰＣ３１との間で、例えばＴＣＰ／ＩＰポート９１００番やＬｐｒ等を使用してデータの通信を行なう。すなわち、ＬＡＮインターフェース１０は、ＴＣＰ／ＩＰに従い、ＰＣ３０、ＰＣ３１との間に仮想的に通信路（セッション）を形成して、複数の種類が異なるデータ、例えばＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）データからなるＰＣプリントジョブデータ、ＰＣ−ＦＡＸジョブデータ、及びＧＤＩ（Ｇｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）データからなるＰＣ−ＦＡＸジョブデータ、ＰＣプリントジョブデータを単一のポート又は複数のポートを通して受信できるように構成されている。
【００２５】
また、ＬＡＮインターフェース１０は、受信データの処理中（セッション確立中）にさらに例えばＰＣ３１からセッション確立要求信号を受信した場合、該セッション確立要求信号を送信したＰＣ３１との間にセッションを確立する。そして、ＬＡＮインターフェース１０は、ＰＣ３１から送られてくるデータの種類及びジョブの種類を解析し、その解析結果に基づいて、該データの処理を行うことができるかどうか（すなわち処理を行うリソースが空いているかどうか）を判断し、処理を行うことができない場合（すなわちリソースが空いていない場合）には、セッションを張った状態でＰＣ３１に対してデータの送信を禁止する持続接続制御（キープアライブ）を実行する。一方、処理を行うことができるとき（すなわちリソースが空いているとき）には、持続接続制御を実行することなくＰＣ３１に対してデータの送信を許可する。より詳細には、ＬＡＮインターフェース１０は、ＰＣ３１からジョブデータを受信した場合、該ジョブデータを構成する制御データに含まれるジョブ指令を参照してジョブの種類（例えばＰＣプリント、ＰＣ−ＦＡＸ等）を判別する。また、制御データに含まれるデータ種別からデータの種類（例えばＰＤＬデータ、ＧＤＩデータ等）を判別する。ただし、ジョブの種類に対してデータの種類が一義的に決まる場合、例えば、提供されるドライバーによって、ジョブの種類毎にデータの種類が一義的に定められているような場合には、ジョブの種類を判別することによりデータの種類を認識することができるため、データの種類の判別を省略してもよい。そして、ＬＡＮインターフェース１０は、同じ種類のジョブ、及び／又は、同じ種類のデータが現在処理中であるか否かによって、リソースが空いているか否かを判断し、その判断結果に基づいて持続接続制御を実行するか否かを決定する。
【００２６】
ここで、ＬＡＮインターフェース１０は、９１００番やＬｐｒ等のポートを通して受信される受信データを一時的に格納する、例えば８Ｋバイトの容量を持つ受信バッファ１０Ａを有し、該受信バッファ１０Ａの空き容量に応じた受信可能データ量をＳｔａｎｄａｒｄ ＴＣＰ／ＩＰに従ってＰＣ３０、ＰＣ３１へ送信する。なお、受信バッファ１０Ａの空き容量が所定値以下（例えば半分以下）になった場合には、受信可能データ量としてゼロを送信する構成としてもよい。また、ＬＡＮインターフェース１０は、ＰＣ３１から受信したデータの処理を行うことができない場合（すなわちリソースが空いていない場合）には、受信可能データ量がＰＣ３１の最小送信可能データ量よりも小さくなるように、受信バッファ１０Ａから読み出すデータ量を非持続接続制御時（すなわち通常制御時）よりも少なく（例えば数バイト〜数十バイト）することにより持続接続制御を実現する。
【００２７】
また、ＬＡＮインターフェース１０は、持続接続制御を実行した場合に、先に受信したデータの処理が終了したとき（すなわちリソースを利用可能になったとき）に持続接続制御を終了し、後からセッション確立要求信号を送信したＰＣ３１に対してデータの送信を許可する。ここで、ＬＡＮインターフェース１０は、持続接続制御を終了してＰＣ３１に対してデータの送信を許可する場合、受信可能データ量がＰＣ３１の最小送信可能データ量よりも大きくなるように、受信バッファ１０Ａから読み出すデータ量を持続接続制御時よりも多くする（例えば数百〜数Ｋバイト）ことにより通常制御（非持続接続制御）に移行させる。このように、ＬＡＮインターフェース１０は、特許請求の範囲に記載の通信手段として機能する。
【００２８】
制御部１１は、演算を行なうマイクロプロセッサ、マイクロプロセッサに各処理を実行させるためのプログラム等を記憶するＲＯＭ、受信バッファ１０Ａから読み出された受信データや演算結果等の各種データを一時的に記憶するＲＡＭ、及びバックアップデータを記憶するバックアップＲＡＭ等により構成されている。制御部１１は、ＲＯＭに記憶されているプログラムを実行することにより、ＰＣプリント機能、ＰＣ−ＦＡＸ機能、及び以下に説明するネットワーク複合機１を構成する各部の機能を実現するとともに、ネットワーク複合機１を構成するハードウェアを統合的に制御する。
【００２９】
また、制御部１１は、入力されたＰＤＬデータを解釈・展開してラスターデータを生成するプリンタコントローラとしての展開部１１Ａを有している。展開部１１Ａで生成されたラスターデータは、通信線２３を介して記録部１２に出力される。より詳細には、制御部１１は、ＰＣ３０、ＰＣ３１から制御データとプリントデータとで構成されたＰＣプリントジョブデータを受信した場合、制御データに含まれるＰＣプリントジョブ指令等のジョブの種類を示すデータを参照してジョブの種類（この場合はＰＣプリント）を判別する。また、制御データに含まれるデータの種類を示すデータから受信したプリントデータがＰＤＬデータであるかＧＤＩデータであるかを判別する。そして、ＰＤＬデータである場合は、プリントデータを展開部１１Ａでラスタライズ処理してラスターデータを生成したのち記録部１２に出力し、ＧＤＩデータである場合は、該データをそのまま記録部１２に出力する。ただし、ＧＤＩデータが符号化圧縮されている場合には、コーデック１６において復号された後、記録部１２に出力される。
【００３０】
さらに、制御部１１は、ＰＣ−ＦＡＸジョブデータを受信すると、上述したようにジョブの種類を判別するとともに、制御データに含まれるファクシミリ送信先電話番号を抽出する。さらに制御部１１は、制御データに含まれるデータ種別を参照して、データ種別がＧＤＩデータである場合には、プリントデータをコーデック１６で符号化圧縮して送信データを生成し、モデム１８、ＮＣＵ１９を介してＦＡＸ送信する。なお、コーデック１６、モデム１８、及びＮＣＵ１９の詳細については後述する。一方、データ種別がＰＤＬデータである場合には、ＰＤＬデータを展開部１１Ａでラスタライズした後コーデック１６で符号化圧縮して送信データを生成しＦＡＸ送信する。展開部１１Ａ、コーデック１６、モデム１８、及びＮＣＵ１９は、特許請求の範囲に記載の処理手段に相当する。
【００３１】
記録部１２は、電子写真方式のプリンタであり、外部のＰＣ３０、ＰＣ３１から受信された画像データ（ＧＤＩデータ又はＰＤＬデータから展開されたラスターデータ）を用紙にプリントアウトする。また、記録部１２は、読取部１５により読み取られ生成された画像データ、及びＦＡＸ、ＩＦＡＸ等で受信された画像データを用紙にプリントアウトする。この記録部１２も特許請求の範囲に記載の処理手段に相当する。
【００３２】
操作部１３は、ネットワーク複合機１の各機能を利用するために用いられる複数のキー、例えば、テンキー、短縮キー、スタートキー、ストップキー、及び各種のファンクションキー等を備えている。表示部１４は、ＬＣＤ等を用いた表示装置であり、ネットワーク複合機１の動作状態及び／又は各種設定内容等を表示する。読取部１５は、光源及びＣＣＤ等によって構成されており、紙文書等の原稿を設定された副走査線密度に応じてライン毎に読み取り、画像データを生成する。
【００３３】
コーデック１６は、読取部１５で読み取られた画像データを符号化圧縮するとともに符号化圧縮されている画像データを復号する。画像記憶部１７は、ＤＲＡＭ等で構成されており、コーデック１６で符号化圧縮された画像データ、ＦＡＸ受信された画像データ、及び、外部のＰＣ３０、ＰＣ３１から受信されて符号化圧縮された画像データ等を記憶する。
【００３４】
モデム（変復調器）１８は、ディジタル信号とアナログ信号との間の変復調を行なう。また、モデム１８は、ディジタル命令信号（ＤＣＳ）等の各種機能情報の発生及び検出を行なう。ＮＣＵ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１９は、モデム１８と接続されており、モデム１８と公衆交換電話網（ＰＳＴＮ）５０との接続を制御する。また、ＮＣＵ１９は、送信先のファクシミリ番号に対応した呼出信号の送出、及びその着信を検出する機能を備えている。
【００３５】
ＩＦＡＸ制御部２０は、インターネット環境を利用したＩＦＡＸ機能を司る。ＩＦＡＸ制御部２０は、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に従って電子メールを送信する機能、及び、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）に従って電子メールを受信する機能を有している。ＩＦＡＸ制御部２０は、送信原稿をＴＩＦＦ形式等の画像データとして電子メールに添付し、メールアドレス（ＳＭＴＰサーバ）宛てに送信する。また、ＩＦＡＸ制御部２０は、設定された時間毎にＰＯＰサーバから電子メールを受信して添付ファイルをプリントアウトする。Ｗｅｂサーバ２１は、例えばＨＴＭＬで記述されたホームページ、ログインページ、及びファクシミリ操作ページ等のデータに対して、ＰＣ３０、ＰＣ３１からアクセスして所定のＨＴＴＰタスクを実行することを可能にする。
【００３６】
次に、図２及び図３を併せて参照しつつ、ネットワーク複合機１によるＰＣプリント処理及びＰＣ−ＦＡＸ処理について説明する。図２は、ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が異なる場合のＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順を示すフローチャートである。なお、ここでは、ＰＣプリントデータとしてＰＤＬデータが使用され、ＰＣ−ＦＡＸデータとしてＧＤＩデータが使用される（すなわちジョブの種類に対してデータの種類が一義的に定まる）場合を例にして説明する。また、図３は、ネットワーク複合機１とＰＣ３１との間の通信手順を示すシーケンス図である。
【００３７】
ステップＳ１００では、ＰＣプリントジョブ及びＰＣ−ＦＡＸジョブを受け付けるソケットとローカルアドレスとが関連付けられる（すなわちｂｉｎｄされる）。ここで、ローカルアドレスは、ＩＰアドレスとポート番号とから構成され、本実施形態では、ポート番号として９１００番が割り当てられる。すなわち、ポート番号９１００番でｂｉｎｄされる。続いて、ステップＳ１０２では、ｌｉｓｔｅｎ処理によりステップＳ１００においてｂｉｎｄされたソケットでセッション確立要求（接続要求）を待ち受ける。
【００３８】
続くステップＳ１０４では、Ｓｅｌｅｃｔ処理で指定ポート（９１００番）へのセッション確立要求（図３に示されるＳＹＮ信号）があるか否かの判断が行われる。セッション確立要求がある場合は、ステップＳ１０６に処理が移行する。一方、セッション確立要求がないときには、ステップＳ１０２に処理が移行し、セッション確立要求があるまでステップＳ１０２，Ｓ１０４が繰り返し実行される。
【００３９】
セッション確立要求があった場合、ステップＳ１０６では、ａｃｃｅｐｔ処理でセッション確立要求を受け付けることにより、セッションが確立する。より具体的には、図３に示されるように、ＳＹＮ信号に対してＡＣＫ／ＳＹＮ信号を返すことによりセッションが確立する。以下、ＰＣ３１との間でセッションが確立されたと仮定して説明する。なお、ＡＣＫ／ＳＹＮ信号が返されない場合、セッション確立要求を送ったＰＣは、６秒、１２秒、２４秒、４８秒、７２秒と送信間隔を徐々に大きくしてセッション確立要求を繰り返し送信する。そして、７２秒経過した時点でＡＣＫ／ＳＹＮ信号が返ってこないときには、セッション確立要求処理を打ち切る。
【００４０】
セッションが確立した後、ステップＳ１０８では、ＰＣ３１から送られてきた第１番目のパケット（図３において、ＰＣ３１からＡＣＫ信号に続いて送られるＤａｔａ（ｗｉｎ＝ａａａａ））の受信処理が行われる。なお、ＰＣ３１から送られる１パケット当たりのデータ量（ａａａａ）は、ネットワーク複合機１の受信可能データ量より小さくなるように設定される。
【００４１】
続くステップＳ１１０では、ステップＳ１０８で受信された第１パケットのＰＪＬ（Ｐｒｉｎｔｅｒ Ｊｏｂ Ｌａｎｇｕａｇｅ）を解析し、要求されているサービスがＰＣプリントジョブ（ＰＤＬデータ）であるか否かについての判断が行われる。ここで、要求されているサービスがＰＣプリントジョブであると判断された場合には、ステップＳ１１２に処理が移行する。一方、要求されているサービスがＰＣプリントジョブではないと判断されたとき、すなわちＰＣ−ＦＡＸジョブが要求されているときには、ステップＳ１２６に処理が移行する。
【００４２】
ステップＳ１１２では、ＰＣプリントの処理状態を示すフラグに基づいてＰＣプリント処理が既に実行中であるか否かについての判断が行われる。ここで、ＰＣプリント処理が実行中である場合、すなわち上述した展開部１１Ａ、記録部１２等のリソースを利用できない場合には、ステップＳ１１４に処理が移行する。一方、ＰＣプリント処理が実行中ではないとき、すなわち展開部１１Ａ、記録部１２等のリソースを利用可能なときには、ステップＳ１１６に処理が移行する。なお、ステップＳ１１２では、記録部１２の状態にかかわらず、展開部１１Ａが利用できるか否かのみによって分岐判断を行ってもよい。その場合には、展開部１１Ａのみが特許請求の範囲に記載の処理手段に相当する。
【００４３】
ＰＣプリント処理が実行中である場合、ステップＳ１１４では、受信バッファ１０Ａから１０バイトずつ受信データが読み出される。また、受信バッファ１０Ａの空き容量に応じた受信可能データ量がＴＣＰ／ＩＰに従ってＰＣ３１へ送信される（図３に示されるＡＣＫ（ｗｉｎ＝ｘｘｘｘ），ＡＣＫ（ｗｉｎ＝ｙｙｙｙ）、ここでｘｘｘｘ，ｙｙｙｙは受信可能データ量を表し、ｘｘｘｘ＞ｙｙｙｙである）。その後、ステップＳ１１２に処理が移行し、先に実行中のＰＣプリント処理が終了するまでステップＳ１１２、Ｓ１１４が繰り返し実行される。その間、ＰＣ３１から受信されるデータ量よりも受信バッファ１０Ａから読み出されるデータ量が少なくなるため、受信バッファ１０Ａの空き容量が時間経過に伴って次第に減少し、所定時間経過後に、ＰＣ３１に対して受信可能データ量としてゼロ（又はゼロに近い値）が送信される（図３に示されるＡＣＫ（ｗｉｎ＝０））。より詳細には、ネットワーク複合機１側で受信データの読み出しが実行されることに伴ってＰＣ３１に対してＡＣＫが帰される。ＰＣ３１はＡＣＫを受信すると、次のデータを（１回又は複数回に分けて）送信する。その際、ＰＣ３１は、受信した受信可能データ量より小さいパケットサイズを設定してデータを送信する。よって、読み出しが１回実行されれば、（1回又は複数回）データが受信される。そのため、ステップＳ１１４では、１回の読み出し量が、ＡＣＫ１回あたりの受信データ量よりも小さくなるように受信データの読み出しが行われる。その結果、セッションを張った状態でＰＣ３１による送信データの送出が抑制される持続接続制御に移行し、先に実行中のＰＣプリント処理が終了するまで、持続接続制御が継続して実行される。
【００４４】
より具体的には、図３に示されるように、ネットワーク複合機１がｗｉｎｄｏｗｓ ｓｉｚｅがゼロのＡＣＫ（ｗｉｎ＝０）を返すと、ＰＣ３１は、受信バッファ１０Ａが空いたか否かを問い合わせる信号ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ（ｗｉｎ＝０）を定期的に送出する。この信号に対して、持続接続制御が継続されている間、ネットワーク複合機１は、受信バッファ１０Ａに空き容量がないことを示す信号ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ ＡＣＫ（ｗｉｎ＝０）を返す。すなわち、持続接続制御が維持されている間、ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ（ｗｉｎ＝０）に対してＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ ＡＣＫ（ｗｉｎ＝０）が返信される。より詳細には、受信バッファ１０Ａの空き容量が所定値（例えば、受信バッファ容量の半分）より少ない場合には、正確な空き容量を受信可能データ量として送信するのではなく、受信可能データ量としてゼロを送信する。従って、持続接続制御から通常制御に移行した直後においても、空き容量が所定値に達するまでは、受信可能データ量としてゼロが送信され、空き容量が所定値に達した後、正確な空き容量が受信可能データ量として送信される。なお、受信可能データ量として、ゼロの代わりに、ＰＣ３１の最小送信可能データ量よりも小さい値を設定してもよい。
【００４５】
ＰＣ３１からのＰＣプリントジョブが実行可能な場合、又は実行可能になった場合には、ＰＣ３１からのＰＣプリントジョブが受け付けられ、ステップＳ１１６において、ＰＣプリントの処理状態を示すフラグが「実行中」に設定される。その後、ステップＳ１１８において通常の受信処理（受信バッファ１０Ａから数Ｋバイトずつ受信データを読み出す処理）が実行される。そのため、これまで持続接続制御が行われていたときには、受信バッファ１０Ａの空き容量が急激に増大することにより、持続接続制御が解除され、ＰＣ３１に対してデータの送信が許可される。より具体的には、持続接続制御を解除するときには、受信バッファ１０Ａからの読み出し量が持続接続制御よりも大幅に増大されることにより、図３に示されるように、ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ（ｗｉｎ＝０）に対し、（ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ ＡＣＫ（ｗｉｎ＝０）に代えて）受信可能データ量を示すＡＣＫ（ｗｉｎ＝ｘｘｘｘ）が返信される。これにより、ＰＣ３１によるデータ送信が開始される。
【００４６】
続くステップＳ１２０では、受信されたＰＤＬデータがラスタライズされて生成されたラスターデータが記録部１２に転送され、記録部１２により用紙にプリントアウトされる。続いて、ステップＳ１２２では、セッションを終了させるためのＦＩＮ信号が受信されたか否かについての判断が行われる（図３に示されるＦＩＮ信号参照）。ここで、ＦＩＮ信号が受信された場合には、ステップＳ１２４に処理が移行する。一方、ＦＩＮ信号が受信されていないときには、ステップＳ１１８に処理が移行し、ＦＩＮ信号が受信されるまで上述したステップＳ１１８〜Ｓ１２２が繰り返し実行される。
【００４７】
ＦＩＮ信号が受信された場合、ステップＳ１２４では、図３に示されるようにＰＣ３１に対してＡＣＫ／ＦＩＮ信号が返され、セッションが終了されるとともに、ＰＣプリントの処理状態を示すフラグが「未実行中」に設定される。その後、本処理から一旦抜ける。
【００４８】
ステップＳ１１０において、要求されているサービスがＰＣプリントジョブではないと判断されたとき、すなわちＰＣ−ＦＡＸジョブが要求されているときには、ステップＳ１２６において、ＰＣ−ＦＡＸの処理状態を示すフラグに基づいてＰＣ−ＦＡＸ処理が既に実行中であるか否かについての判断が行われる。ここで、ＰＣ−ＦＡＸ処理が実行中である場合、すなわち上述したコーデック１６、モデム１８、ＮＣＵ１９等のリソースを利用できない場合には、ステップＳ１２８に処理が移行する。一方、ＰＣ−ＦＡＸ処理が実行中ではないとき、すなわちコーデック１６、モデム１８、ＮＣＵ１９等のリソースを利用可能なときには、ステップＳ１３０に処理が移行する。なお、ステップＳ１２６では、モデム１８、ＮＣＵ１９の状態にかかわらず、コーデック１６が利用できるか否かのみによって分岐判断を行ってもよい。その場合には、コーデック１６のみが特許請求の範囲に記載の処理手段に相当する。
【００４９】
ＰＣ−ＦＡＸ処理が実行中である場合、ステップＳ１２８では、受信バッファ１０Ａから１０バイトずつ受信データが読み出される。また、受信バッファ１０Ａの空き容量に応じた受信可能データ量がＴＣＰ／ＩＰに従ってＰＣ３１へ送信される。その後、ステップＳ１２６に処理が移行し、先に実行中のＰＣ−ＦＡＸ処理が終了するまでステップＳ１２６、Ｓ１２８が繰り返し実行される。その間、ＰＣ３１から受信されるデータ量よりも受信バッファ１０Ａから読み出されるデータ量が少なくなるため、受信バッファ１０Ａの空き容量が減少し、ＰＣ３１に対して受信可能データ量としてゼロ（又はゼロに近い値）が送信される。その結果、セッションを張った状態でＰＣ３１による送信データの送出が抑制される持続接続制御に移行し、先に実行中のＰＣ−ＦＡＸ処理が終了するまで、持続接続制御が継続して実行される。
【００５０】
ＰＣ３１からのＰＣ−ＦＡＸジョブが実行可能な場合、又は実行可能になった場合には、ＰＣ３１からのＰＣ−ＦＡＸジョブが受け付けられ、ステップＳ１３０において、ＰＣ−ＦＡＸの処理状態を示すフラグが「実行中」に設定される。その後、ステップＳ１３２において通常の受信処理（受信バッファ１０Ａから数Ｋバイトずつ受信データを読み出す処理）が実行される。そのため、これまで持続接続制御が行われていたときには、受信バッファ１０Ａの空き容量が増大することにより、持続接続制御が解除され、ＰＣ３１に対してデータの送信が許可される。
【００５１】
続くステップＳ１３４では、受信されたＧＤＩデータがコーデック１６により符号化圧縮されて送信データが生成され、モデム１８、ＮＣＵ１９を介して送信される。続いて、ステップＳ１３６では、セッションを終了させるためのＦＩＮ信号が受信されたか否かについての判断が行われる。ここで、ＦＩＮ信号が受信された場合には、ステップＳ１３８に処理が移行する。一方、ＦＩＮ信号が受信されていないときには、ステップＳ１３２に処理が移行し、ＦＩＮ信号が受信されるまで上述したステップＳ１３２〜Ｓ１３６が繰り返し実行される。
【００５２】
ＦＩＮ信号が受信された場合、ステップＳ１３８では、セッションが終了されるとともに、ＰＣ−ＦＡＸの処理状態を示すフラグが「未実行中」に設定される。その後、本処理から一旦抜ける。
【００５３】
本実施形態によれば、データ処理中にさらにセッション確立要求信号を受信したときに、送られてくるジョブの種類が処理中のジョブと同じ種類（ＰＣプリント（ＰＤＬデータ）同士又はＰＣ−ＦＡＸ（ＧＤＩデータ）同士）である場合、すなわちデータ処理を行なうリソースが同じ場合には、セッションを張った状態を保持しつつセッション確立要求信号を送信した例えばＰＣ３１に対してデータ送信が禁止される。そのため、リソースが利用可能になるまでＰＣ３１からの受信データを格納しておくために大容量のメモリを設ける必要がない。一方、処理中のジョブと種類が異なり、利用するリソースが競合しない場合には、データの送信が許可され、迅速に処理を進めることができる。また、先のデータの処理中に、セッションを張った状態で後のデータ送信を禁止する持続接続制御を行なうことにより、先のデータ処理が完了し持続接続制御が解除される時点では既にセッションが張られているため、迅速にデータ受信に移行することができる。さらに、セッション確立要求が受信されたときにセッションが確立されるため、タイムアウトによるセッション確立エラーの発生を防止することができる。以上により、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能となる。
【００５４】
また、本実施形態によれば、先に実行されていたデータ処理が完了した時点で持続接続制御が解除され、後からセッション確立要求信号を送信した例えばＰＣ３１に対してデータの送信が許可される。すなわち、リソースが利用可能になったときにデータの送信が許可される。よって、処理待ちのデータを一時的に格納するための大容量のメモリを設ける必要がない。また、持続接続制御が終了される時点では、既にセッションが張られているため、迅速にデータ受信に移ることが可能となる。
【００５５】
さらに、本実施形態によれば、後からセッション確立要求信号を送信したＰＣ３１から受信したジョブの種類が処理中のジョブと同じ種類の場合に、受信可能データ量がＰＣ３１の最小送信可能データ量よりも小さくなるように、受信バッファ１０Ａから読み出すデータ量が非持続接続制御時（すなわち通常制御時）よりも少なくされる。よって、ＰＣ３１から受信されるデータ量よりも受信バッファ１０Ａから読み出されるデータ量が少なくなるため、受信バッファ１０Ａの空き容量が減少し、ＰＣ３１に対して受信可能データ量としてゼロ（又はゼロに近い値）が送信される。その結果、セッションを張った状態でＰＣ３１による送信データの送出を抑制すること、すなわち持続接続制御を実現することが可能となる。
【００５６】
また、本実施形態によれば、持続接続制御を終了するときに、受信バッファ１０Ａから読み出されるデータ量が持続接続制御時よりも増やされ、受信バッファ１０Ａの空き容量（すなわち受信可能データ量）がＰＣ３１の最小送信可能データ量よりも大きくされる。そして、その空き容量に応じたサイズが受信可能データサイズとして後からセッション確立要求信号を送信したＰＣ３１に送信される。そのため、ＰＣ３１が送信データを送出することができるようになり、よって、持続接続制御から通常制御に円滑に移行することが可能となる。
【００５７】
上記実施形態ではＰＣプリントデータとＰＣ−ＦＡＸデータの種類が異なる場合のＰＣプリント処理及びＰＣ−ＦＡＸ処理について説明したが、ＰＣプリントデータとＰＣ−ＦＡＸデータとは同じ種類であってもよい。次に、図４を参照しつつ、ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が同じ場合のＰＣプリント処理及びＰＣ−ＦＡＸ処理について説明する。ここで、図４は、ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が同じ場合のネットワーク複合機１によるＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順を示すフローチャートである。なお、図４に示した処理手順において、図２に示した処理手順と同一の処理を行なうステップについては図２と同一の符号を付した。また、ここでは、ＰＣプリントデータ及びＰＣ−ＦＡＸデータとしてＰＤＬデータが使用される（すなわちジョブの種類に対してデータの種類が一義的に定まる）場合を例にして説明する。
【００５８】
図４に示されるＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順は、上述したステップＳ１１２に代えてステップＳ２１２が実行されるとともに、ステップＳ１２６に代えてステップＳ２２６が実行される点で上述した図２に示される処理手順と異なる。その他の処理手順は同一であるので、ここではこれらの異なる点について説明し、同一の処理手順については重複する説明を省略する。
【００５９】
ステップＳ２１２では、ＰＣプリントの処理状態を示すフラグ及びＰＣ−ＦＡＸの処理状態を示すフラグに基づいて、ＰＣプリント処理及びＰＣ−ＦＡＸ処理それぞれが既に実行中であるか否かについての判断が行われる。ここで、ＰＣプリント処理及びＰＣ−ＦＡＸ処理のいずれか一方が実行中である場合、すなわち上述した展開部１１Ａを利用できない場合には、ステップＳ１１４に処理が移行し、持続接続制御が行われる。一方、ＰＣプリント処理及びＰＣ−ＦＡＸ処理が実行中ではないとき、すなわち展開部１１Ａを利用可能なときには、ステップＳ１１６に処理が移行し、ＰＣプリント処理が行われる。
【００６０】
一方、ステップＳ２２６では、ＰＣ−ＦＡＸの処理状態を示すフラグ及びＰＣプリントの処理状態を示すフラグに基づいてＰＣ−ＦＡＸ処理及びＰＣプリント処理が既に実行中であるか否かについての判断が行われる。ここで、ＰＣ−ＦＡＸ処理及びＰＣプリント処理のいずれか一方又は双方が実行中である場合、すなわち上述した展開部１１Ａを利用できない場合には、ステップＳ１２８に処理が移行し、持続接続制御が行われる。一方、ＰＣ−ＦＡＸ処理及びＰＣプリント処理の双方が実行中ではないとき、すなわち展開部１１Ａを利用可能なときには、ステップＳ１３０に処理が移行し、ＰＣ−ＦＡＸ処理が行われる。
【００６１】
本実施形態によれば、ＰＣプリントとＰＣ−ＦＡＸとで同じ種類のデータを利用する場合であっても、上述した実施形態と同一又は同様の効果を奏することが可能となる。
【００６２】
以上、本発明の実施の形態について説明したが、本発明は、上記実施形態に限定されるものではなく種々の変形が可能である。例えば、用いる通信プロトコル、ポート、データ形式、リソース、及び要求処理内容等は上記実施形態には限られない。また、上記実施形態では本発明に係る通信装置をネットワーク複合機に適用したが、ネットワーク複合機以外の装置に適用してもよい。
【００６３】
また、上記実施形態では、ＰＣプリントデータにＰＤＬデータを用い、ＰＣ−ＦＡＸデータにＧＤＩデータ又はＰＤＬデータを用いたが、ＰＣプリントデータ、ＰＣ−ＦＡＸデータとしてＰＤＬデータ、ＧＤＩデータ双方を用いる構成としてもよい。さらに、上記実施形態では、持続接続制御に移行する際、及び持続接続制御を維持する際に、受信バッファ１０Ａから１０バイトずつ受信データを読み出したが、１度に読み出される受信データ量は１０バイトには限られない。
【００６４】
また、上記実施形態では、通信端末がＰＣであり、処理内容例がＰＣプリント、ＰＣ−ＦＡＸである場合を例にして説明したが、通信端末や処理内容はこれらに限られない。すなわち、例えば、通信端末がネットワーク複合機であり、処理内容がダイレクトＳＭＴＰによる電子メール送信であってもよい。この場合、受信側のネットワーク複合機（本願の通信装置）は、ダイレクトＳＭＴＰによって受信した電子メールについて、ＭＩＭＥデコード処理を行う。また、一般的に、受信した電子メールの添付ファイル（画像データ）は、ＭＭＲ方式等で圧縮符号化されているため、そのデコード処理（復号処理）も行う。従って、これらのデコード処理を行うためのリソースが使用可能状態であるか否かによって、通常制御又は持続接続制御のいずれかが実行される。
【００６５】
上記実施形態では、ＰＣ３１とセッションが形成されると仮定し、このＰＣ３１よりも先にセッションを形成しているＰＣに付いては言及していないが、このＰＣは、ＰＣ３０であってもよいし、ＰＣ３１であってもよい。すなわち、異なるＰＣから２つ以上のジョブ受信が連続して発生してもよいし、同一のＰＣから２つ以上のジョブ受信が連続して発生してもよい。
【符号の説明】
【００６６】
１ ネットワーク複合機
１０ ＬＡＮインターフェース
１０Ａ 受信バッファ
１１ 制御部
１１Ａ 展開部
１２ 記録部
１３ 操作部
１４ 表示部
１５ 読取部
１６ コーデック
１７ 画像記憶部
１８ モデム
１９ ＮＣＵ
２０ ＩＦＡＸ制御部
２１ Ｗｅｂサーバ
３０，３１ パーソナルコンピュータ
５１ ＬＡＮ
【技術分野】
【０００１】
本発明は、通信装置に関し、特に、ネットワークを介して接続される通信端末との間にセッションを形成してコネクション型のデータ通信を行なう通信装置に関する。
【背景技術】
【０００２】
従来から、呼制御プロトコルを用いて画像データの通信を行なう画像通信装置が知られている。このような画像通信装置として、特許文献１には、並行して複数の機器と通信が可能な画像通信装置が記載されている。この画像通信装置によれば、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）呼接続中に他の機器からＳＩＰ呼接続を要求された場合、先のＳＩＰ呼接続が終了した後で他の機器からのＳＩＰ呼接続要求に応答する。すなわち、最初のＳＩＰプロトコル処理が終了し、メディアセッションに移行することにより、一時的に中断していた他の機器との呼制御通信が再開される。他の機器は、画像通信装置がデータ受信可能になったことで、画像通信装置に対して直接ＡＣＫ信号を送信し、これからデータを送信することを伝える。そして、メディアセッションに移行し、画像データを画像通信装置に送信する。最初の機器から画像通信装置へのメディアセッションと他の機器から画像通信装置へのメディアセッションとが重なる間、画像通信装置は複数の機器からの画像データを同時に並行して受信する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−２０５６１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ここで、複数の機器からの画像データを同時に受信するためには、受信された画像データに対してデータ処理が実行される間、該画像データを記憶しておくための大容量のメモリが必要となる。特に、同時に並行して受信される複数の画像データを処理するリソースが１つだけの場合には、複数の画像データを同時に処理することができないため、より大容量のメモリを設けることが要求される。
【０００５】
一方、メモリの大容量化を回避するためには、複数のデータを並行して受信しない構成、すなわち、例えば１つの通信端末とのセッションが確立されている間は他の通信端末とのセッションを張らない構成とすることも考えられる。しかしながら、このような構成にした場合、他の通信端末は所定の時間を空けてセッション確立要求を繰り返し送出することとなる。そのため、先にセッションが張られていた通信端末から受信されたデータの処理が終了し、他の通信端末とセッションを張ることが可能な状態になったとしても、他の通信端末からセッション確立要求が再送されるまではセッションを張ることができない。そのため、リソースが使用可能になっていているにもかかわらず、受信処理及び受信データのデータ処理を開始することができず、処理の開始が遅れるという問題が生じ得る。さらに、一定時間以上応答が無くタイムアウトした場合には、セッションを確立することができないと判断され、他の通信端末側でエラーとなるおそれがある。
【０００６】
本発明は、上記問題点を解消する為になされたものであり、ネットワークを介して接続される通信端末との間にセッションを形成してデータ通信を行なう通信装置において、受信データの処理中にセッション確立要求を受けたとしても、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能な通信装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る通信装置は、ネットワークを介して通信端末と接続され、該通信端末との間にセッションを形成してデータ通信を行なう通信装置において、通信端末との間でデータの送受信を行なう通信手段と、通信手段により受信されたデータを、該データの種類及び／又はジョブの種類に応じて処理する処理手段とを備え、通信手段が、セッション確立要求信号を受信した場合、該セッション確立要求信号を送信した通信端末との間にセッションを確立するとともに、該通信端末から受信したデータを解析し、処理手段による該データの処理が行えない場合には、セッションを張った状態で該通信端末に対してデータの送信を禁止する持続接続制御を実行し、処理手段による該データの処理が可能な場合には、持続接続制御を実行することなく該通信端末に対してデータの送信を許可することを特徴とする。
【０００８】
本発明に係る通信装置によれば、セッション確立要求信号を受信したときに、受信したデータを処理手段で処理することができない場合、すなわちデータ処理を行なうリソースが空いていない場合には、セッションを張った状態を保持しつつセッション確立要求信号を送信した通信端末によるデータ送信が禁止される。そのため、リソースが利用可能になるまでデータを格納しておく必要がなく、メモリの容量を増大する必要がない。一方、受信したデータを処理手段で処理することができる場合には、すなわちデータ処理を行うリソースが空いているときには、データの送信が許可され、迅速に処理を進めることができる。また、先のデータの処理中に、セッションが張られた状態で後のデータ送信が禁止される持続接続制御が行なわれることにより、先のデータ処理が終了し持続接続制御が終了する時点では既にセッションが張られているため、迅速にデータ受信に移行することができる。さらに、セッション確立要求が受信されたときにセッションが確立されるため、タイムアウトによるセッション確立エラーの発生を防止することができる。以上により、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能となる。
【０００９】
本発明に係る通信装置では、上記通信手段が、通信端末から受信したデータの種類を解析し、該データと同じ種類のデータが、処理手段によって処理されているときには、持続接続制御を実行し、処理手段によって処理されていない場合には、通信端末に対してデータの送信を許可することが好ましい。
【００１０】
このようにすれば、通信端末から受信したデータの種類を解析するとともに、該データと同じ種類のデータが処理手段で処理されているか否かを判断することによって、データ処理を行なうためのリソースが空いているか否かを判断することができる。よって、上述した持続接続制御を実行する必要があるかどうかを適切に判断することができる。
【００１１】
また、本発明に係る通信装置では、上記通信手段が、通信端末から受信したデータのジョブの種類を解析し、該ジョブと同じ種類のジョブのデータが、処理手段によって処理されているときには、持続接続制御を実行し、処理手段によって処理されていない場合には、通信端末に対してデータの送信を許可することが好ましい。
【００１２】
このようにすれば、通信端末から受信したデータのジョブの種類を解析するとともに、該データと同じ種類のジョブのデータが処理手段で処理されているか否かを判断することによって、データ処理を行なうためのリソースが空いているか否かを判断することができる。よって、上述した持続接続制御を実行する必要があるかどうかを適切に判断することができる。
【００１３】
本発明に係る通信装置では、上記通信手段が、持続接続制御を実行した場合に、処理手段によるデータ処理が終了した時点で持続接続制御を終了し、上記セッション確立要求信号を送信した通信端末に対してデータの送信を許可することが好ましい。
【００１４】
この場合、先に実行されていたデータ処理が終了した時点で持続接続制御が終了され、後からセッション確立要求信号を送信した通信端末に対してデータの送信が許可される。すなわち、リソースが利用可能になったときにデータの送信が許可される。よって、処理待ちのデータを一時的に格納するための大容量のメモリを備える必要がない。また、持続接続制御が終了される時点では、既にセッションが張られているため、迅速にデータ通信を開始することが可能となる。
【００１５】
本発明に係る通信装置では、上記通信手段が、通信端末から受信される受信データを一時的に格納する受信バッファを有し、該受信バッファの空き容量に応じた受信可能データ量を所定の通信プロトコルに従って通信端末へ送信するとともに、セッション確立要求信号を送信した通信端末から受信したデータの処理手段による処理が行えない場合には、受信可能データ量が該通信端末の最小送信可能データ量よりも小さくなるように、受信バッファから読み出すデータ量を非持続接続制御時よりも少なくすることが好ましい。
【００１６】
このようにすれば、後からセッション確立要求信号を送信した通信端末から受信したデータの処理を行うことができない場合に、受信可能データ量が該通信端末の最小送信可能データ量よりも小さくなるように、受信バッファから読み出されるデータ量が非持続接続制御時（すなわち通常制御時）よりも少なくされる。よって、該通信端末から受信されるデータ量よりも受信バッファから読み出されるデータ量が少なくなるため、受信バッファの空き容量が減少し、受信可能データ量として該通信端末の最小送信可能データ量よりも小さな値（典型的にはゼロ）が該通信端末に対して送信される。その結果、セッションを張った状態で該通信端末による送信データの送出を抑制すること、すなわち持続接続制御を実現することが可能となる。
【００１７】
また、本発明に係る通信装置では、上記通信手段が、持続接続制御を終了して上記セッション確立要求信号を送信した通信端末に対してデータの送信を許可する場合、受信可能データ量が該通信端末の最小送信可能データ量よりも大きくなるように、受信バッファから読み出すデータ量を持続接続制御時よりも多くすることが好ましい。
【００１８】
この場合、持続接続制御を終了するときに、受信バッファから読み出されるデータ量が持続接続制御時よりも増やされ、受信バッファの空き容量（すなわち受信可能データ量）が通信端末の最小送信可能データ量よりも大きくされる。そして、その空き容量に応じたサイズが受信可能データ量として後からセッション確立要求信号を送信した通信端末に送信される。そのため、該通信端末が送信データを送出することができるようになり、よって、持続接続制御から通常制御に円滑に移行することが可能となる。
【００１９】
なお、本発明に係る通信装置では、上記通信プロトコルとして、ＴＣＰ／ＩＰが好適に利用される。
【発明の効果】
【００２０】
本発明によれば、ネットワークを介して接続される通信端末との間にセッションを形成してコネクション型のデータ通信を行なう通信装置において、受信データの処理中にセッションの確立要求を受けたとしても、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能となる。
【図面の簡単な説明】
【００２１】
【図１】実施形態に係る通信装置が搭載されたネットワーク複合機の全体構成を示すブロック図である。
【図２】ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が異なる場合のネットワーク複合機１によるＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順を示すフローチャートである。
【図３】ネットワーク複合機とＰＣとの間の通信手順を示すシーケンス図である。
【図４】ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が同じ場合のネットワーク複合機１によるＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順を示すフローチャートである。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。なお、各図において、同一要素には同一符号を付して重複する説明を省略する。なお、ここでは、実施形態に係る通信装置をネットワーク複合機（ＭＦＰ）に適用した場合を例にして説明する。また、ネットワーク複合機がＬＡＮを介して２台のパーソナルコンピュータ（以下「ＰＣ」という。特許請求の範囲に記載の通信端末に相当）と接続されているネットワーク構成を例にして説明する。なお、例示するネットワークシステムは、理解を容易にするためにその構成を簡略化したものである。まず、図１を用いて、ネットワーク複合機１の全体構成について説明する。図１は、ＬＡＮ５１に接続されたネットワーク複合機１の全体構成を示すブロック図である。
【００２３】
ネットワーク複合機１は、原稿を読み取り画像データを生成するスキャナ機能、読み取り生成した画像データを用紙に記録する機能（コピー機能）、及びファクシミリ通信により受信した画像データを用紙に記録する機能（ＦＡＸ受信機能）に加え、ＬＡＮ５１を介して接続されているＰＣ３０、ＰＣ３１から受信した画像データを用紙に記録する機能（以下「ＰＣプリント機能」という）を備えている。また、ネットワーク複合機１は、読み取った画像データをファクシミリ送信するＦＡＸ送信機能に加え、外部のＰＣ３０、ＰＣ３１から受信した画像データをファクシミリ送信する機能（以下「ＰＣ−ＦＡＸ機能」という）を備えている。さらに、ネットワーク複合機１は、電子メールを利用してＩＰ網経由で画像データを送受信するインターネットＦＡＸ（以下「ＩＦＡＸ」という）機能等も有している。これらの各機能を実現するためにネットワーク複合機１は、ＬＡＮインターフェース１０、制御部１１、記録部１２、操作部１３、表示部１４、読取部１５、コーデック１６、画像記憶部１７、モデム１８、ＮＣＵ１９、ＩＦＡＸ制御部２０、及び、Ｗｅｂサーバ２１等を備えている。なお、上記各部は通信線２３で相互に通信可能に接続されている。
【００２４】
ＬＡＮインターフェース１０は、各種通信プロトコルの送受信制御処理、及び各種通信プロトコル上のデータ解析処理及びデータ作成処理を行なうネットワークインターフェースである。外部のＰＣ３０、ＰＣ３１とのデータ通信はこのＬＡＮインターフェース１０を通して行われる。ＬＡＮインターフェース１０は、ＬＡＮ５１を介してＰＣ３０、ＰＣ３１に接続されており、ＰＣ３０、ＰＣ３１との間で、例えばＴＣＰ／ＩＰポート９１００番やＬｐｒ等を使用してデータの通信を行なう。すなわち、ＬＡＮインターフェース１０は、ＴＣＰ／ＩＰに従い、ＰＣ３０、ＰＣ３１との間に仮想的に通信路（セッション）を形成して、複数の種類が異なるデータ、例えばＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）データからなるＰＣプリントジョブデータ、ＰＣ−ＦＡＸジョブデータ、及びＧＤＩ（Ｇｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）データからなるＰＣ−ＦＡＸジョブデータ、ＰＣプリントジョブデータを単一のポート又は複数のポートを通して受信できるように構成されている。
【００２５】
また、ＬＡＮインターフェース１０は、受信データの処理中（セッション確立中）にさらに例えばＰＣ３１からセッション確立要求信号を受信した場合、該セッション確立要求信号を送信したＰＣ３１との間にセッションを確立する。そして、ＬＡＮインターフェース１０は、ＰＣ３１から送られてくるデータの種類及びジョブの種類を解析し、その解析結果に基づいて、該データの処理を行うことができるかどうか（すなわち処理を行うリソースが空いているかどうか）を判断し、処理を行うことができない場合（すなわちリソースが空いていない場合）には、セッションを張った状態でＰＣ３１に対してデータの送信を禁止する持続接続制御（キープアライブ）を実行する。一方、処理を行うことができるとき（すなわちリソースが空いているとき）には、持続接続制御を実行することなくＰＣ３１に対してデータの送信を許可する。より詳細には、ＬＡＮインターフェース１０は、ＰＣ３１からジョブデータを受信した場合、該ジョブデータを構成する制御データに含まれるジョブ指令を参照してジョブの種類（例えばＰＣプリント、ＰＣ−ＦＡＸ等）を判別する。また、制御データに含まれるデータ種別からデータの種類（例えばＰＤＬデータ、ＧＤＩデータ等）を判別する。ただし、ジョブの種類に対してデータの種類が一義的に決まる場合、例えば、提供されるドライバーによって、ジョブの種類毎にデータの種類が一義的に定められているような場合には、ジョブの種類を判別することによりデータの種類を認識することができるため、データの種類の判別を省略してもよい。そして、ＬＡＮインターフェース１０は、同じ種類のジョブ、及び／又は、同じ種類のデータが現在処理中であるか否かによって、リソースが空いているか否かを判断し、その判断結果に基づいて持続接続制御を実行するか否かを決定する。
【００２６】
ここで、ＬＡＮインターフェース１０は、９１００番やＬｐｒ等のポートを通して受信される受信データを一時的に格納する、例えば８Ｋバイトの容量を持つ受信バッファ１０Ａを有し、該受信バッファ１０Ａの空き容量に応じた受信可能データ量をＳｔａｎｄａｒｄ ＴＣＰ／ＩＰに従ってＰＣ３０、ＰＣ３１へ送信する。なお、受信バッファ１０Ａの空き容量が所定値以下（例えば半分以下）になった場合には、受信可能データ量としてゼロを送信する構成としてもよい。また、ＬＡＮインターフェース１０は、ＰＣ３１から受信したデータの処理を行うことができない場合（すなわちリソースが空いていない場合）には、受信可能データ量がＰＣ３１の最小送信可能データ量よりも小さくなるように、受信バッファ１０Ａから読み出すデータ量を非持続接続制御時（すなわち通常制御時）よりも少なく（例えば数バイト〜数十バイト）することにより持続接続制御を実現する。
【００２７】
また、ＬＡＮインターフェース１０は、持続接続制御を実行した場合に、先に受信したデータの処理が終了したとき（すなわちリソースを利用可能になったとき）に持続接続制御を終了し、後からセッション確立要求信号を送信したＰＣ３１に対してデータの送信を許可する。ここで、ＬＡＮインターフェース１０は、持続接続制御を終了してＰＣ３１に対してデータの送信を許可する場合、受信可能データ量がＰＣ３１の最小送信可能データ量よりも大きくなるように、受信バッファ１０Ａから読み出すデータ量を持続接続制御時よりも多くする（例えば数百〜数Ｋバイト）ことにより通常制御（非持続接続制御）に移行させる。このように、ＬＡＮインターフェース１０は、特許請求の範囲に記載の通信手段として機能する。
【００２８】
制御部１１は、演算を行なうマイクロプロセッサ、マイクロプロセッサに各処理を実行させるためのプログラム等を記憶するＲＯＭ、受信バッファ１０Ａから読み出された受信データや演算結果等の各種データを一時的に記憶するＲＡＭ、及びバックアップデータを記憶するバックアップＲＡＭ等により構成されている。制御部１１は、ＲＯＭに記憶されているプログラムを実行することにより、ＰＣプリント機能、ＰＣ−ＦＡＸ機能、及び以下に説明するネットワーク複合機１を構成する各部の機能を実現するとともに、ネットワーク複合機１を構成するハードウェアを統合的に制御する。
【００２９】
また、制御部１１は、入力されたＰＤＬデータを解釈・展開してラスターデータを生成するプリンタコントローラとしての展開部１１Ａを有している。展開部１１Ａで生成されたラスターデータは、通信線２３を介して記録部１２に出力される。より詳細には、制御部１１は、ＰＣ３０、ＰＣ３１から制御データとプリントデータとで構成されたＰＣプリントジョブデータを受信した場合、制御データに含まれるＰＣプリントジョブ指令等のジョブの種類を示すデータを参照してジョブの種類（この場合はＰＣプリント）を判別する。また、制御データに含まれるデータの種類を示すデータから受信したプリントデータがＰＤＬデータであるかＧＤＩデータであるかを判別する。そして、ＰＤＬデータである場合は、プリントデータを展開部１１Ａでラスタライズ処理してラスターデータを生成したのち記録部１２に出力し、ＧＤＩデータである場合は、該データをそのまま記録部１２に出力する。ただし、ＧＤＩデータが符号化圧縮されている場合には、コーデック１６において復号された後、記録部１２に出力される。
【００３０】
さらに、制御部１１は、ＰＣ−ＦＡＸジョブデータを受信すると、上述したようにジョブの種類を判別するとともに、制御データに含まれるファクシミリ送信先電話番号を抽出する。さらに制御部１１は、制御データに含まれるデータ種別を参照して、データ種別がＧＤＩデータである場合には、プリントデータをコーデック１６で符号化圧縮して送信データを生成し、モデム１８、ＮＣＵ１９を介してＦＡＸ送信する。なお、コーデック１６、モデム１８、及びＮＣＵ１９の詳細については後述する。一方、データ種別がＰＤＬデータである場合には、ＰＤＬデータを展開部１１Ａでラスタライズした後コーデック１６で符号化圧縮して送信データを生成しＦＡＸ送信する。展開部１１Ａ、コーデック１６、モデム１８、及びＮＣＵ１９は、特許請求の範囲に記載の処理手段に相当する。
【００３１】
記録部１２は、電子写真方式のプリンタであり、外部のＰＣ３０、ＰＣ３１から受信された画像データ（ＧＤＩデータ又はＰＤＬデータから展開されたラスターデータ）を用紙にプリントアウトする。また、記録部１２は、読取部１５により読み取られ生成された画像データ、及びＦＡＸ、ＩＦＡＸ等で受信された画像データを用紙にプリントアウトする。この記録部１２も特許請求の範囲に記載の処理手段に相当する。
【００３２】
操作部１３は、ネットワーク複合機１の各機能を利用するために用いられる複数のキー、例えば、テンキー、短縮キー、スタートキー、ストップキー、及び各種のファンクションキー等を備えている。表示部１４は、ＬＣＤ等を用いた表示装置であり、ネットワーク複合機１の動作状態及び／又は各種設定内容等を表示する。読取部１５は、光源及びＣＣＤ等によって構成されており、紙文書等の原稿を設定された副走査線密度に応じてライン毎に読み取り、画像データを生成する。
【００３３】
コーデック１６は、読取部１５で読み取られた画像データを符号化圧縮するとともに符号化圧縮されている画像データを復号する。画像記憶部１７は、ＤＲＡＭ等で構成されており、コーデック１６で符号化圧縮された画像データ、ＦＡＸ受信された画像データ、及び、外部のＰＣ３０、ＰＣ３１から受信されて符号化圧縮された画像データ等を記憶する。
【００３４】
モデム（変復調器）１８は、ディジタル信号とアナログ信号との間の変復調を行なう。また、モデム１８は、ディジタル命令信号（ＤＣＳ）等の各種機能情報の発生及び検出を行なう。ＮＣＵ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１９は、モデム１８と接続されており、モデム１８と公衆交換電話網（ＰＳＴＮ）５０との接続を制御する。また、ＮＣＵ１９は、送信先のファクシミリ番号に対応した呼出信号の送出、及びその着信を検出する機能を備えている。
【００３５】
ＩＦＡＸ制御部２０は、インターネット環境を利用したＩＦＡＸ機能を司る。ＩＦＡＸ制御部２０は、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に従って電子メールを送信する機能、及び、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）に従って電子メールを受信する機能を有している。ＩＦＡＸ制御部２０は、送信原稿をＴＩＦＦ形式等の画像データとして電子メールに添付し、メールアドレス（ＳＭＴＰサーバ）宛てに送信する。また、ＩＦＡＸ制御部２０は、設定された時間毎にＰＯＰサーバから電子メールを受信して添付ファイルをプリントアウトする。Ｗｅｂサーバ２１は、例えばＨＴＭＬで記述されたホームページ、ログインページ、及びファクシミリ操作ページ等のデータに対して、ＰＣ３０、ＰＣ３１からアクセスして所定のＨＴＴＰタスクを実行することを可能にする。
【００３６】
次に、図２及び図３を併せて参照しつつ、ネットワーク複合機１によるＰＣプリント処理及びＰＣ−ＦＡＸ処理について説明する。図２は、ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が異なる場合のＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順を示すフローチャートである。なお、ここでは、ＰＣプリントデータとしてＰＤＬデータが使用され、ＰＣ−ＦＡＸデータとしてＧＤＩデータが使用される（すなわちジョブの種類に対してデータの種類が一義的に定まる）場合を例にして説明する。また、図３は、ネットワーク複合機１とＰＣ３１との間の通信手順を示すシーケンス図である。
【００３７】
ステップＳ１００では、ＰＣプリントジョブ及びＰＣ−ＦＡＸジョブを受け付けるソケットとローカルアドレスとが関連付けられる（すなわちｂｉｎｄされる）。ここで、ローカルアドレスは、ＩＰアドレスとポート番号とから構成され、本実施形態では、ポート番号として９１００番が割り当てられる。すなわち、ポート番号９１００番でｂｉｎｄされる。続いて、ステップＳ１０２では、ｌｉｓｔｅｎ処理によりステップＳ１００においてｂｉｎｄされたソケットでセッション確立要求（接続要求）を待ち受ける。
【００３８】
続くステップＳ１０４では、Ｓｅｌｅｃｔ処理で指定ポート（９１００番）へのセッション確立要求（図３に示されるＳＹＮ信号）があるか否かの判断が行われる。セッション確立要求がある場合は、ステップＳ１０６に処理が移行する。一方、セッション確立要求がないときには、ステップＳ１０２に処理が移行し、セッション確立要求があるまでステップＳ１０２，Ｓ１０４が繰り返し実行される。
【００３９】
セッション確立要求があった場合、ステップＳ１０６では、ａｃｃｅｐｔ処理でセッション確立要求を受け付けることにより、セッションが確立する。より具体的には、図３に示されるように、ＳＹＮ信号に対してＡＣＫ／ＳＹＮ信号を返すことによりセッションが確立する。以下、ＰＣ３１との間でセッションが確立されたと仮定して説明する。なお、ＡＣＫ／ＳＹＮ信号が返されない場合、セッション確立要求を送ったＰＣは、６秒、１２秒、２４秒、４８秒、７２秒と送信間隔を徐々に大きくしてセッション確立要求を繰り返し送信する。そして、７２秒経過した時点でＡＣＫ／ＳＹＮ信号が返ってこないときには、セッション確立要求処理を打ち切る。
【００４０】
セッションが確立した後、ステップＳ１０８では、ＰＣ３１から送られてきた第１番目のパケット（図３において、ＰＣ３１からＡＣＫ信号に続いて送られるＤａｔａ（ｗｉｎ＝ａａａａ））の受信処理が行われる。なお、ＰＣ３１から送られる１パケット当たりのデータ量（ａａａａ）は、ネットワーク複合機１の受信可能データ量より小さくなるように設定される。
【００４１】
続くステップＳ１１０では、ステップＳ１０８で受信された第１パケットのＰＪＬ（Ｐｒｉｎｔｅｒ Ｊｏｂ Ｌａｎｇｕａｇｅ）を解析し、要求されているサービスがＰＣプリントジョブ（ＰＤＬデータ）であるか否かについての判断が行われる。ここで、要求されているサービスがＰＣプリントジョブであると判断された場合には、ステップＳ１１２に処理が移行する。一方、要求されているサービスがＰＣプリントジョブではないと判断されたとき、すなわちＰＣ−ＦＡＸジョブが要求されているときには、ステップＳ１２６に処理が移行する。
【００４２】
ステップＳ１１２では、ＰＣプリントの処理状態を示すフラグに基づいてＰＣプリント処理が既に実行中であるか否かについての判断が行われる。ここで、ＰＣプリント処理が実行中である場合、すなわち上述した展開部１１Ａ、記録部１２等のリソースを利用できない場合には、ステップＳ１１４に処理が移行する。一方、ＰＣプリント処理が実行中ではないとき、すなわち展開部１１Ａ、記録部１２等のリソースを利用可能なときには、ステップＳ１１６に処理が移行する。なお、ステップＳ１１２では、記録部１２の状態にかかわらず、展開部１１Ａが利用できるか否かのみによって分岐判断を行ってもよい。その場合には、展開部１１Ａのみが特許請求の範囲に記載の処理手段に相当する。
【００４３】
ＰＣプリント処理が実行中である場合、ステップＳ１１４では、受信バッファ１０Ａから１０バイトずつ受信データが読み出される。また、受信バッファ１０Ａの空き容量に応じた受信可能データ量がＴＣＰ／ＩＰに従ってＰＣ３１へ送信される（図３に示されるＡＣＫ（ｗｉｎ＝ｘｘｘｘ），ＡＣＫ（ｗｉｎ＝ｙｙｙｙ）、ここでｘｘｘｘ，ｙｙｙｙは受信可能データ量を表し、ｘｘｘｘ＞ｙｙｙｙである）。その後、ステップＳ１１２に処理が移行し、先に実行中のＰＣプリント処理が終了するまでステップＳ１１２、Ｓ１１４が繰り返し実行される。その間、ＰＣ３１から受信されるデータ量よりも受信バッファ１０Ａから読み出されるデータ量が少なくなるため、受信バッファ１０Ａの空き容量が時間経過に伴って次第に減少し、所定時間経過後に、ＰＣ３１に対して受信可能データ量としてゼロ（又はゼロに近い値）が送信される（図３に示されるＡＣＫ（ｗｉｎ＝０））。より詳細には、ネットワーク複合機１側で受信データの読み出しが実行されることに伴ってＰＣ３１に対してＡＣＫが帰される。ＰＣ３１はＡＣＫを受信すると、次のデータを（１回又は複数回に分けて）送信する。その際、ＰＣ３１は、受信した受信可能データ量より小さいパケットサイズを設定してデータを送信する。よって、読み出しが１回実行されれば、（1回又は複数回）データが受信される。そのため、ステップＳ１１４では、１回の読み出し量が、ＡＣＫ１回あたりの受信データ量よりも小さくなるように受信データの読み出しが行われる。その結果、セッションを張った状態でＰＣ３１による送信データの送出が抑制される持続接続制御に移行し、先に実行中のＰＣプリント処理が終了するまで、持続接続制御が継続して実行される。
【００４４】
より具体的には、図３に示されるように、ネットワーク複合機１がｗｉｎｄｏｗｓ ｓｉｚｅがゼロのＡＣＫ（ｗｉｎ＝０）を返すと、ＰＣ３１は、受信バッファ１０Ａが空いたか否かを問い合わせる信号ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ（ｗｉｎ＝０）を定期的に送出する。この信号に対して、持続接続制御が継続されている間、ネットワーク複合機１は、受信バッファ１０Ａに空き容量がないことを示す信号ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ ＡＣＫ（ｗｉｎ＝０）を返す。すなわち、持続接続制御が維持されている間、ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ（ｗｉｎ＝０）に対してＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ ＡＣＫ（ｗｉｎ＝０）が返信される。より詳細には、受信バッファ１０Ａの空き容量が所定値（例えば、受信バッファ容量の半分）より少ない場合には、正確な空き容量を受信可能データ量として送信するのではなく、受信可能データ量としてゼロを送信する。従って、持続接続制御から通常制御に移行した直後においても、空き容量が所定値に達するまでは、受信可能データ量としてゼロが送信され、空き容量が所定値に達した後、正確な空き容量が受信可能データ量として送信される。なお、受信可能データ量として、ゼロの代わりに、ＰＣ３１の最小送信可能データ量よりも小さい値を設定してもよい。
【００４５】
ＰＣ３１からのＰＣプリントジョブが実行可能な場合、又は実行可能になった場合には、ＰＣ３１からのＰＣプリントジョブが受け付けられ、ステップＳ１１６において、ＰＣプリントの処理状態を示すフラグが「実行中」に設定される。その後、ステップＳ１１８において通常の受信処理（受信バッファ１０Ａから数Ｋバイトずつ受信データを読み出す処理）が実行される。そのため、これまで持続接続制御が行われていたときには、受信バッファ１０Ａの空き容量が急激に増大することにより、持続接続制御が解除され、ＰＣ３１に対してデータの送信が許可される。より具体的には、持続接続制御を解除するときには、受信バッファ１０Ａからの読み出し量が持続接続制御よりも大幅に増大されることにより、図３に示されるように、ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ（ｗｉｎ＝０）に対し、（ＴＣＰ Ｚｅｒｏ Ｗｉｎｄｏｗ Ｐｒｏｂｅ ＡＣＫ（ｗｉｎ＝０）に代えて）受信可能データ量を示すＡＣＫ（ｗｉｎ＝ｘｘｘｘ）が返信される。これにより、ＰＣ３１によるデータ送信が開始される。
【００４６】
続くステップＳ１２０では、受信されたＰＤＬデータがラスタライズされて生成されたラスターデータが記録部１２に転送され、記録部１２により用紙にプリントアウトされる。続いて、ステップＳ１２２では、セッションを終了させるためのＦＩＮ信号が受信されたか否かについての判断が行われる（図３に示されるＦＩＮ信号参照）。ここで、ＦＩＮ信号が受信された場合には、ステップＳ１２４に処理が移行する。一方、ＦＩＮ信号が受信されていないときには、ステップＳ１１８に処理が移行し、ＦＩＮ信号が受信されるまで上述したステップＳ１１８〜Ｓ１２２が繰り返し実行される。
【００４７】
ＦＩＮ信号が受信された場合、ステップＳ１２４では、図３に示されるようにＰＣ３１に対してＡＣＫ／ＦＩＮ信号が返され、セッションが終了されるとともに、ＰＣプリントの処理状態を示すフラグが「未実行中」に設定される。その後、本処理から一旦抜ける。
【００４８】
ステップＳ１１０において、要求されているサービスがＰＣプリントジョブではないと判断されたとき、すなわちＰＣ−ＦＡＸジョブが要求されているときには、ステップＳ１２６において、ＰＣ−ＦＡＸの処理状態を示すフラグに基づいてＰＣ−ＦＡＸ処理が既に実行中であるか否かについての判断が行われる。ここで、ＰＣ−ＦＡＸ処理が実行中である場合、すなわち上述したコーデック１６、モデム１８、ＮＣＵ１９等のリソースを利用できない場合には、ステップＳ１２８に処理が移行する。一方、ＰＣ−ＦＡＸ処理が実行中ではないとき、すなわちコーデック１６、モデム１８、ＮＣＵ１９等のリソースを利用可能なときには、ステップＳ１３０に処理が移行する。なお、ステップＳ１２６では、モデム１８、ＮＣＵ１９の状態にかかわらず、コーデック１６が利用できるか否かのみによって分岐判断を行ってもよい。その場合には、コーデック１６のみが特許請求の範囲に記載の処理手段に相当する。
【００４９】
ＰＣ−ＦＡＸ処理が実行中である場合、ステップＳ１２８では、受信バッファ１０Ａから１０バイトずつ受信データが読み出される。また、受信バッファ１０Ａの空き容量に応じた受信可能データ量がＴＣＰ／ＩＰに従ってＰＣ３１へ送信される。その後、ステップＳ１２６に処理が移行し、先に実行中のＰＣ−ＦＡＸ処理が終了するまでステップＳ１２６、Ｓ１２８が繰り返し実行される。その間、ＰＣ３１から受信されるデータ量よりも受信バッファ１０Ａから読み出されるデータ量が少なくなるため、受信バッファ１０Ａの空き容量が減少し、ＰＣ３１に対して受信可能データ量としてゼロ（又はゼロに近い値）が送信される。その結果、セッションを張った状態でＰＣ３１による送信データの送出が抑制される持続接続制御に移行し、先に実行中のＰＣ−ＦＡＸ処理が終了するまで、持続接続制御が継続して実行される。
【００５０】
ＰＣ３１からのＰＣ−ＦＡＸジョブが実行可能な場合、又は実行可能になった場合には、ＰＣ３１からのＰＣ−ＦＡＸジョブが受け付けられ、ステップＳ１３０において、ＰＣ−ＦＡＸの処理状態を示すフラグが「実行中」に設定される。その後、ステップＳ１３２において通常の受信処理（受信バッファ１０Ａから数Ｋバイトずつ受信データを読み出す処理）が実行される。そのため、これまで持続接続制御が行われていたときには、受信バッファ１０Ａの空き容量が増大することにより、持続接続制御が解除され、ＰＣ３１に対してデータの送信が許可される。
【００５１】
続くステップＳ１３４では、受信されたＧＤＩデータがコーデック１６により符号化圧縮されて送信データが生成され、モデム１８、ＮＣＵ１９を介して送信される。続いて、ステップＳ１３６では、セッションを終了させるためのＦＩＮ信号が受信されたか否かについての判断が行われる。ここで、ＦＩＮ信号が受信された場合には、ステップＳ１３８に処理が移行する。一方、ＦＩＮ信号が受信されていないときには、ステップＳ１３２に処理が移行し、ＦＩＮ信号が受信されるまで上述したステップＳ１３２〜Ｓ１３６が繰り返し実行される。
【００５２】
ＦＩＮ信号が受信された場合、ステップＳ１３８では、セッションが終了されるとともに、ＰＣ−ＦＡＸの処理状態を示すフラグが「未実行中」に設定される。その後、本処理から一旦抜ける。
【００５３】
本実施形態によれば、データ処理中にさらにセッション確立要求信号を受信したときに、送られてくるジョブの種類が処理中のジョブと同じ種類（ＰＣプリント（ＰＤＬデータ）同士又はＰＣ−ＦＡＸ（ＧＤＩデータ）同士）である場合、すなわちデータ処理を行なうリソースが同じ場合には、セッションを張った状態を保持しつつセッション確立要求信号を送信した例えばＰＣ３１に対してデータ送信が禁止される。そのため、リソースが利用可能になるまでＰＣ３１からの受信データを格納しておくために大容量のメモリを設ける必要がない。一方、処理中のジョブと種類が異なり、利用するリソースが競合しない場合には、データの送信が許可され、迅速に処理を進めることができる。また、先のデータの処理中に、セッションを張った状態で後のデータ送信を禁止する持続接続制御を行なうことにより、先のデータ処理が完了し持続接続制御が解除される時点では既にセッションが張られているため、迅速にデータ受信に移行することができる。さらに、セッション確立要求が受信されたときにセッションが確立されるため、タイムアウトによるセッション確立エラーの発生を防止することができる。以上により、大容量のメモリを設けることなく、受信処理の待ち時間を短縮することができ、かつ、タイムアウトによるセッション確立エラーの発生を防止することが可能となる。
【００５４】
また、本実施形態によれば、先に実行されていたデータ処理が完了した時点で持続接続制御が解除され、後からセッション確立要求信号を送信した例えばＰＣ３１に対してデータの送信が許可される。すなわち、リソースが利用可能になったときにデータの送信が許可される。よって、処理待ちのデータを一時的に格納するための大容量のメモリを設ける必要がない。また、持続接続制御が終了される時点では、既にセッションが張られているため、迅速にデータ受信に移ることが可能となる。
【００５５】
さらに、本実施形態によれば、後からセッション確立要求信号を送信したＰＣ３１から受信したジョブの種類が処理中のジョブと同じ種類の場合に、受信可能データ量がＰＣ３１の最小送信可能データ量よりも小さくなるように、受信バッファ１０Ａから読み出すデータ量が非持続接続制御時（すなわち通常制御時）よりも少なくされる。よって、ＰＣ３１から受信されるデータ量よりも受信バッファ１０Ａから読み出されるデータ量が少なくなるため、受信バッファ１０Ａの空き容量が減少し、ＰＣ３１に対して受信可能データ量としてゼロ（又はゼロに近い値）が送信される。その結果、セッションを張った状態でＰＣ３１による送信データの送出を抑制すること、すなわち持続接続制御を実現することが可能となる。
【００５６】
また、本実施形態によれば、持続接続制御を終了するときに、受信バッファ１０Ａから読み出されるデータ量が持続接続制御時よりも増やされ、受信バッファ１０Ａの空き容量（すなわち受信可能データ量）がＰＣ３１の最小送信可能データ量よりも大きくされる。そして、その空き容量に応じたサイズが受信可能データサイズとして後からセッション確立要求信号を送信したＰＣ３１に送信される。そのため、ＰＣ３１が送信データを送出することができるようになり、よって、持続接続制御から通常制御に円滑に移行することが可能となる。
【００５７】
上記実施形態ではＰＣプリントデータとＰＣ−ＦＡＸデータの種類が異なる場合のＰＣプリント処理及びＰＣ−ＦＡＸ処理について説明したが、ＰＣプリントデータとＰＣ−ＦＡＸデータとは同じ種類であってもよい。次に、図４を参照しつつ、ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が同じ場合のＰＣプリント処理及びＰＣ−ＦＡＸ処理について説明する。ここで、図４は、ＰＣプリントデータとＰＣ−ＦＡＸデータの種類が同じ場合のネットワーク複合機１によるＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順を示すフローチャートである。なお、図４に示した処理手順において、図２に示した処理手順と同一の処理を行なうステップについては図２と同一の符号を付した。また、ここでは、ＰＣプリントデータ及びＰＣ−ＦＡＸデータとしてＰＤＬデータが使用される（すなわちジョブの種類に対してデータの種類が一義的に定まる）場合を例にして説明する。
【００５８】
図４に示されるＰＣプリント処理及びＰＣ−ＦＡＸ処理の処理手順は、上述したステップＳ１１２に代えてステップＳ２１２が実行されるとともに、ステップＳ１２６に代えてステップＳ２２６が実行される点で上述した図２に示される処理手順と異なる。その他の処理手順は同一であるので、ここではこれらの異なる点について説明し、同一の処理手順については重複する説明を省略する。
【００５９】
ステップＳ２１２では、ＰＣプリントの処理状態を示すフラグ及びＰＣ−ＦＡＸの処理状態を示すフラグに基づいて、ＰＣプリント処理及びＰＣ−ＦＡＸ処理それぞれが既に実行中であるか否かについての判断が行われる。ここで、ＰＣプリント処理及びＰＣ−ＦＡＸ処理のいずれか一方が実行中である場合、すなわち上述した展開部１１Ａを利用できない場合には、ステップＳ１１４に処理が移行し、持続接続制御が行われる。一方、ＰＣプリント処理及びＰＣ−ＦＡＸ処理が実行中ではないとき、すなわち展開部１１Ａを利用可能なときには、ステップＳ１１６に処理が移行し、ＰＣプリント処理が行われる。
【００６０】
一方、ステップＳ２２６では、ＰＣ−ＦＡＸの処理状態を示すフラグ及びＰＣプリントの処理状態を示すフラグに基づいてＰＣ−ＦＡＸ処理及びＰＣプリント処理が既に実行中であるか否かについての判断が行われる。ここで、ＰＣ−ＦＡＸ処理及びＰＣプリント処理のいずれか一方又は双方が実行中である場合、すなわち上述した展開部１１Ａを利用できない場合には、ステップＳ１２８に処理が移行し、持続接続制御が行われる。一方、ＰＣ−ＦＡＸ処理及びＰＣプリント処理の双方が実行中ではないとき、すなわち展開部１１Ａを利用可能なときには、ステップＳ１３０に処理が移行し、ＰＣ−ＦＡＸ処理が行われる。
【００６１】
本実施形態によれば、ＰＣプリントとＰＣ−ＦＡＸとで同じ種類のデータを利用する場合であっても、上述した実施形態と同一又は同様の効果を奏することが可能となる。
【００６２】
以上、本発明の実施の形態について説明したが、本発明は、上記実施形態に限定されるものではなく種々の変形が可能である。例えば、用いる通信プロトコル、ポート、データ形式、リソース、及び要求処理内容等は上記実施形態には限られない。また、上記実施形態では本発明に係る通信装置をネットワーク複合機に適用したが、ネットワーク複合機以外の装置に適用してもよい。
【００６３】
また、上記実施形態では、ＰＣプリントデータにＰＤＬデータを用い、ＰＣ−ＦＡＸデータにＧＤＩデータ又はＰＤＬデータを用いたが、ＰＣプリントデータ、ＰＣ−ＦＡＸデータとしてＰＤＬデータ、ＧＤＩデータ双方を用いる構成としてもよい。さらに、上記実施形態では、持続接続制御に移行する際、及び持続接続制御を維持する際に、受信バッファ１０Ａから１０バイトずつ受信データを読み出したが、１度に読み出される受信データ量は１０バイトには限られない。
【００６４】
また、上記実施形態では、通信端末がＰＣであり、処理内容例がＰＣプリント、ＰＣ−ＦＡＸである場合を例にして説明したが、通信端末や処理内容はこれらに限られない。すなわち、例えば、通信端末がネットワーク複合機であり、処理内容がダイレクトＳＭＴＰによる電子メール送信であってもよい。この場合、受信側のネットワーク複合機（本願の通信装置）は、ダイレクトＳＭＴＰによって受信した電子メールについて、ＭＩＭＥデコード処理を行う。また、一般的に、受信した電子メールの添付ファイル（画像データ）は、ＭＭＲ方式等で圧縮符号化されているため、そのデコード処理（復号処理）も行う。従って、これらのデコード処理を行うためのリソースが使用可能状態であるか否かによって、通常制御又は持続接続制御のいずれかが実行される。
【００６５】
上記実施形態では、ＰＣ３１とセッションが形成されると仮定し、このＰＣ３１よりも先にセッションを形成しているＰＣに付いては言及していないが、このＰＣは、ＰＣ３０であってもよいし、ＰＣ３１であってもよい。すなわち、異なるＰＣから２つ以上のジョブ受信が連続して発生してもよいし、同一のＰＣから２つ以上のジョブ受信が連続して発生してもよい。
【符号の説明】
【００６６】
１ ネットワーク複合機
１０ ＬＡＮインターフェース
１０Ａ 受信バッファ
１１ 制御部
１１Ａ 展開部
１２ 記録部
１３ 操作部
１４ 表示部
１５ 読取部
１６ コーデック
１７ 画像記憶部
１８ モデム
１９ ＮＣＵ
２０ ＩＦＡＸ制御部
２１ Ｗｅｂサーバ
３０，３１ パーソナルコンピュータ
５１ ＬＡＮ
【特許請求の範囲】
【請求項１】
ネットワークを介して通信端末と接続され、該通信端末との間にセッションを形成してデータ通信を行なう通信装置において、
前記通信端末との間でデータの送受信を行なう通信手段と、
前記通信手段により受信されたデータを、該データの種類及び／又はジョブの種類に応じて処理する処理手段と、を備え、
前記通信手段は、セッション確立要求信号を受信した場合、該セッション確立要求信号を送信した通信端末との間にセッションを確立するとともに、該通信端末から受信したデータを解析し、前記処理手段による該データの処理が行えない場合には、セッションを張った状態で該通信端末に対してデータの送信を禁止する持続接続制御を実行し、前記処理手段による該データの処理が可能な場合には、持続接続制御を実行することなく該通信端末に対してデータの送信を許可することを特徴とする通信装置。
【請求項２】
前記通信手段は、前記通信端末から受信したデータの種類を解析し、該データと同じ種類のデータが、前記処理手段によって処理されているときには、前記持続接続制御を実行し、前記処理手段によって処理されていない場合には、前記通信端末に対してデータの送信を許可することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記通信手段は、前記通信端末から受信したデータのジョブの種類を解析し、該ジョブと同じ種類のジョブのデータが、前記処理手段によって処理されているときには、前記持続接続制御を実行し、前記処理手段によって処理されていない場合には、前記通信端末に対してデータの送信を許可することを特徴とする請求項１に記載の通信装置。
【請求項４】
前記通信手段は、前記持続接続制御を実行した場合に、前記処理手段によるデータ処理が終了した時点で持続接続制御を終了し、前記セッション確立要求信号を送信した通信端末に対してデータの送信を許可することを特徴とする請求項１〜３のいずれか１項に記載の通信装置。
【請求項５】
前記通信手段は、通信端末から受信される受信データを一時的に格納する受信バッファを有し、該受信バッファの空き容量に応じた受信可能データ量を所定の通信プロトコルに従って前記通信端末へ送信するとともに、前記セッション確立要求信号を送信した通信端末から受信したデータの前記処理手段による処理が行えない場合には、前記受信可能データ量が該通信端末の最小送信可能データ量よりも小さくなるように、前記受信バッファから読み出すデータ量を非持続接続制御時よりも少なくすることを特徴とする請求項１〜４のいずれか１項に記載の通信装置。
【請求項６】
前記通信手段は、前記持続接続制御を終了して前記セッション確立要求信号を送信した通信端末に対してデータの送信を許可する場合、前記受信可能データ量が該通信端末の最小送信可能データ量よりも大きくなるように、前記受信バッファから読み出すデータ量を前記持続接続制御時よりも多くすることを特徴とする請求項５に記載の通信装置。
【請求項７】
前記通信プロトコルは、ＴＣＰ／ＩＰであることを特徴とする請求項５又は６に記載の通信装置。
【請求項１】
ネットワークを介して通信端末と接続され、該通信端末との間にセッションを形成してデータ通信を行なう通信装置において、
前記通信端末との間でデータの送受信を行なう通信手段と、
前記通信手段により受信されたデータを、該データの種類及び／又はジョブの種類に応じて処理する処理手段と、を備え、
前記通信手段は、セッション確立要求信号を受信した場合、該セッション確立要求信号を送信した通信端末との間にセッションを確立するとともに、該通信端末から受信したデータを解析し、前記処理手段による該データの処理が行えない場合には、セッションを張った状態で該通信端末に対してデータの送信を禁止する持続接続制御を実行し、前記処理手段による該データの処理が可能な場合には、持続接続制御を実行することなく該通信端末に対してデータの送信を許可することを特徴とする通信装置。
【請求項２】
前記通信手段は、前記通信端末から受信したデータの種類を解析し、該データと同じ種類のデータが、前記処理手段によって処理されているときには、前記持続接続制御を実行し、前記処理手段によって処理されていない場合には、前記通信端末に対してデータの送信を許可することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記通信手段は、前記通信端末から受信したデータのジョブの種類を解析し、該ジョブと同じ種類のジョブのデータが、前記処理手段によって処理されているときには、前記持続接続制御を実行し、前記処理手段によって処理されていない場合には、前記通信端末に対してデータの送信を許可することを特徴とする請求項１に記載の通信装置。
【請求項４】
前記通信手段は、前記持続接続制御を実行した場合に、前記処理手段によるデータ処理が終了した時点で持続接続制御を終了し、前記セッション確立要求信号を送信した通信端末に対してデータの送信を許可することを特徴とする請求項１〜３のいずれか１項に記載の通信装置。
【請求項５】
前記通信手段は、通信端末から受信される受信データを一時的に格納する受信バッファを有し、該受信バッファの空き容量に応じた受信可能データ量を所定の通信プロトコルに従って前記通信端末へ送信するとともに、前記セッション確立要求信号を送信した通信端末から受信したデータの前記処理手段による処理が行えない場合には、前記受信可能データ量が該通信端末の最小送信可能データ量よりも小さくなるように、前記受信バッファから読み出すデータ量を非持続接続制御時よりも少なくすることを特徴とする請求項１〜４のいずれか１項に記載の通信装置。
【請求項６】
前記通信手段は、前記持続接続制御を終了して前記セッション確立要求信号を送信した通信端末に対してデータの送信を許可する場合、前記受信可能データ量が該通信端末の最小送信可能データ量よりも大きくなるように、前記受信バッファから読み出すデータ量を前記持続接続制御時よりも多くすることを特徴とする請求項５に記載の通信装置。
【請求項７】
前記通信プロトコルは、ＴＣＰ／ＩＰであることを特徴とする請求項５又は６に記載の通信装置。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１０−２５８６９２（Ｐ２０１０−２５８６９２Ａ）
【公開日】平成２２年１１月１１日（２０１０．１１．１１）
【国際特許分類】
【出願番号】特願２００９−１０５３６４（Ｐ２００９−１０５３６４）
【出願日】平成２１年４月２３日（２００９．４．２３）
【出願人】（０００００６２９７）村田機械株式会社 (4,916)
【Ｆターム（参考）】
【公開日】平成２２年１１月１１日（２０１０．１１．１１）
【国際特許分類】
【出願日】平成２１年４月２３日（２００９．４．２３）
【出願人】（０００００６２９７）村田機械株式会社 (4,916)
【Ｆターム（参考）】
[ Back to top ]