JP5609215B2 - 通信システム、処理要求装置、処理応答装置、通信方法、及びそのプログラム - Google Patents

Description

本発明は、所定の通信プロトコルで処理要求とそれに対する応答を行う通信システム等に関し、特に、処理要求に含まれる拡張機能部分に不具合が生じた場合に、その発生と内容を適確に応答することができる通信システム等に関する。

従来、ＵＤＰ（User Datagram Protocol）を用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信技術が知られている。当該プロトコルとしては、例えば、ＳＬＰ（Service Location Protocol）がある。

このような通信プロトコルでは、ユーザーやベンダーが独自の拡張機能を付加できる規格となっており、通信パケットの拡張領域に当該拡張機能のコードを付加してその機能を実現している。

例えば、下記特許文献１では、拡張機能を用いて、ＵＤＰで送信可能なデータ長の上限を超えるデータをやり取りすることができる技術について提案されている。

特開２００９−２３２１８０号公報

上述した拡張機能を用いた通信をした場合に、通信プロトコルの規格としては正常な通信であるのに、その拡張機能部分、すなわち、拡張機能を示すコード等に誤りがあった場合には、従来は、その通信プロトコルで用意されているエラーコードを用いて、その不都合を知らせる応答を行うと考えられていた。

しかしながら、このようなエラーの報知では、その不都合が通信プロトコルの規格上のものであるのか、拡張機能に関するものであるのかが判別できず、また、拡張機能に関する不都合である場合にはそのエラーの内容も把握することができない。よって、その後の適確な対応をする上で課題があった。

そこで、本発明の目的は、所定の通信プロトコルで処理要求とそれに対する応答を行う通信システムであって、処理要求に含まれる拡張機能部分に不具合が生じた場合に、その発生と内容を適確に応答することができる通信システム、等を提供することである。

上記の目的を達成するために、本発明の一つの側面は、処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理要求装置と処理応答装置とがネットワークを介して通信する通信システムにおいて、前記処理応答装置は、前記処理要求装置から送信された要求通信の、拡張機能を示す拡張領域にエラーが存在する場合に、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードはエラー無しを意味するコードとし、前記拡張機能に対する応答を行う拡張領域に前記エラーの存在と内容を示すコードを入れた、応答通信を行う、ことである。

更に、上記の発明において、その一つの態様は、前記通信プロトコルはＳＬＰである、ことを特徴とする。

更にまた、上記の発明において、一つの態様は、前記拡張機能は、前記要求に対して前記処理応答装置が応答すべき応答データが、送信可能な所定容量を超える場合には、当該応答データを分割して送信させる機能である、ことを特徴とする。

上記の目的を達成するために、本発明の別の側面は、処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理応答装置とネットワークを介して通信する処理要求装置が、拡張機能を示す拡張領域にエラーが存在する要求通信を行った場合に、前記処理応答装置から、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードはエラー無しを意味するコードとし、前記拡張機能に対する応答を行う拡張領域に前記エラーの存在と内容を示すコードを入れた応答通信を受信する、ことである。

上記の目的を達成するために、本発明の更に別の側面は、処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理要求装置とネットワークを介して通信する処理応答装置が、前記処理要求装置から送信された要求通信の、拡張機能を示す拡張領域にエラーが存在する場合に、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードはエラー無しを意味するコードとし、前記拡張機能に対する応答を行う拡張領域に前記エラーの存在と内容を示すコードを入れた、応答通信を行う、ことである。

上記の目的を達成するために、本発明の更に別の側面は、処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理要求装置と処理応答装置とがネットワークを介して通信する通信方法において、前記処理応答装置が、前記処理要求装置から送信された要求通信の、拡張機能を示す拡張領域にエラーが存在する場合に、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードはエラー無しを意味するコードとし、前記拡張機能に対する応答を行う拡張領域に前記エラーの存在と内容を示すコードを入れた、応答通信を行う、ことである。

上記の目的を達成するために、本発明の更に別の側面は、処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理要求装置とネットワークを介して通信する処理応答装置に、応答処理を実行させるプログラムが、前記処理要求装置から送信された要求通信の、拡張機能を示す拡張領域にエラーが存在する場合に、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードはエラー無しを意味するコードとし、前記拡張機能に対する応答を行う拡張領域に前記エラーの存在と内容を示すコードを入れた応答通信を、前記処理応答装置に実行させる、ことである。

本発明を適用した通信システムの本実施の形態例に係る構成図である。 ユーザーエージェントＵＡの概略構成図である。 サービスエージェントＳＡ１の概略構成図である。 要求／応答に係る通信メッセージの概略内容を示した説明図である。 属性要求メッセージの具体例を説明するための図である。 属性応答メッセージの具体例を説明するための図である。 エラー応答の具体例を説明するための図である。

以下、図面にしたがって本発明の実施の形態について説明する。ただし、本発明の技術的範囲はこれらの実施の形態に限定されず、特許請求の範囲に記載された事項とその均等物まで及ぶものである。

図１は、本発明を適用した通信システムの本実施の形態例に係る構成図である。図１に示す通信システム２０が本実施の形態例に係るシステムであり、ユーザーエージェントＵＡからの処理要求に含まれる拡張機能部分にエラーがあった場合に、サービスエージェントＳＡ１、ＳＡ２が、拡張機能部分にエラーの存在とその内容を示すコードを書き込んだ、通信規格上は正常である旨の応答を行い、拡張機能部分のエラー報知を適確に行なおうとするものである。

図１に示すように、本通信システム２０は、ユーザーエージェントＵＡと、サービスエージェントＳＡ１、ＳＡ２とがローカルエリアネットワークＬＡＮを介して接続されている、構成となっている。そして、ユーザーエージェントＵＡとサービスエージェントＳＡ１、ＳＡ２とは、一例として、ＳＬＰで通信を行う。ユーザーエージェントＵＡは、所定のプログラムがインストールされた汎用のパーソナルコンピューターであり、サービスエージェントＳＡ１は、いわゆる複合機のプリンター、ＳＡ２は、いわゆる単独機のプリンターである。なお、通信システム２０を構成するユーザーエージェントまたはサービスエージェントの数は、本例に限定されるものではなく、任意の数を設定可能である。

図２は、ユーザーエージェントＵＡの概略構成図である。ユーザーエージェントＵＡは、上述の通り、所定のプログラムがインストールされた汎用のパーソナルコンピューターであり、ＣＰＵ３０、ハードディスクドライブ４１、ＲＯＭ４２、ＲＡＭ４３、入力機構４５、ディスプレイ４６、インターフェース４９等を備えている。そして、当該ユーザーエージェントＵＡが通信システム２０の処理要求装置である。

ＣＰＵ３０は、ハードディスクドライブ４１やＲＯＭ４２に記憶されたプログラムやＯＳをＲＡＭ４３に展開して実行することで、ユーザーエージェントＵＡの制御処理を司る。そして、当該ＣＰＵ３０の処理により、サービスエージェントＳＡ１、ＳＡ２への所定の処理要求を行う通信コードが生成され、また、サービスエージェントＳＡ１、ＳＡ２からの応答通信が解釈される。

入力機構４５は、キーボード及びポインティングデバイス（ここではマウス）等からなる。ディスプレイ４６は、液晶式のディスプレイである。インターフェース４９は、ユーザーエージェントＵＡをローカルエリアネットワークＬＡＮに接続するためのインターフェースである。

図３は、サービスエージェントＳＡ１の概略構成図である。サービスエージェントＳＡ１は、上述の通り、複合機のプリンターであり、ＣＰＵ５０、ＥＥＰＲＯＭ６１、ＲＯＭ６２、ＲＡＭ６３、入力機構６５、印刷機構６６、スキャナ６７、ＦＡＸ送信機構６８、インターフェース６９を備えている。なお、サービスエージェントＳＡ２は、スキャナ６７、ＦＡＸ送信機構６８を有していない点を除き、サービスエージェントＳＡ１と同様の構成であるため、その説明は省略する。

ＣＰＵ５０は、ＥＥＰＲＯＭ６１やＲＯＭ６２に記憶されたプログラムやＯＳをＲＡＭ６３に展開して実行することで、サービスエージェントＳＡ１全体の制御を司る。そして、当該ＣＰＵ５０の処理により、ユーザーエージェントＵＡから送信される処理要求の通信コードが解釈され、その応答の通信コードが生成される。

入力機構６５は、キーボードとＵＩを表示するディスプレイ等からなる。印刷機構６６は、本実施例においては、一例として、インクジェット式の印刷機構である。インターフェース６９は、サービスエージェントＳＡ１をローカルエリアネットワークＬＡＮに接続するためのインターフェースである。

以上のような構成を有する本通信システム２０では、上述の通り、ＳＬＰでの拡張機能を用いた通信時に、その拡張機能部分に不具合があった場合の処理に特徴を有し、以下、その内容について説明する。

図４は、要求／応答に係る通信メッセージの概略内容を示した説明図である。ユーザーエージェントＵＡは、サービスエージェントＳＡ１、ＳＡ２に対して所定の属性値を応答するように要求をする場合に、ＳＬＰに則って属性要求メッセージを生成し、サービスエージェントＳＡ１、ＳＡ２に対して、マルチキャスト又はユニキャストで送信する。

図４の（ａ）は、その属性要求メッセージの概略の内容を示している。当該図中の「属性タグ」の領域には、応答してほしい属性値の項目を示すコード（属性タグ）が入る。また、右端の「拡張機能用タグ」の領域は、ユーザーやベンダーが独自に定義したタグにより拡張機能を実行する拡張領域であり、その拡張機能を示す拡張機能用タグが入る。

サービスエージェントＳＡ１、ＳＡ２は、上記属性要求の通信を受信すると、それに応答する属性応答メッセージを生成して、ユーザーエージェントＵＡにユニキャストで送信する。この場合、受信した属性要求メッセージに不都合がない場合（エラーがない場合）には、要求された属性の値を当該属性応答メッセージで返信する。

図４の（ｂ）は、その正常な属性応答メッセージの概略の内容を示している。当該図中の「エラーコード」の領域は、ＳＬＰの規格で用意されたエラーコードが収められる領域であり、この場合には、正常な応答であるので、例えば「０」のコードが入る。また、「属性値」及び「拡張機能用属性値」の領域には、それぞれ、上記属性要求メッセージの「属性タグ」及び「拡張機能用タグ」で問われた各属性値のコードが入る。

また、上記受信した属性要求メッセージに不都合がある場合（エラーがある場合）には、サービスエージェントＳＡ１、ＳＡ２は、その旨を知らせる応答メッセージを返信する。図４の（ｃ）は、プロトコル標準の（ＳＬＰの規格で用意された）エラーコードを用いた場合のエラー応答メッセージを示している。この場合、上記「エラーコード」の領域には、発生したエラーにより所定のコードが入れられる。

但し、上記不都合が前述した「拡張機能用タグ」の領域で発生した場合には、サービスエージェントＳＡ１、ＳＡ２は、このエラー応答を用いずに、図４の（ｄ）に示すようなエラー応答メッセージを生成して返信する。すなわち、ＳＬＰの規格上は図４の（ｂ）に示したような正常応答とし、「拡張機能用属性値」の領域（すなわち、拡張領域）にエラーを報知するコードを入れた応答をする。

具体的には、図４の（ｄ）に示すように、ＳＬＰの規格上の「エラーコード」には正常応答を示す「０」のコードが入り、「拡張機能用属性値」には、拡張機能に関するエラーの発生とその種別（内容）を表すコード（例えば、「ＥＲＲＯＲ＝Ｘ」）が入る応答メッセージを生成して返信する。すなわち、拡張機能に関するエラーの報知は拡張機能用属性値で行われる。

なお、このようなエラーの応答は、属性要求がユニキャストで行われた場合に実行され、属性要求がマルチキャストで行われた場合には実行されない。

このような拡張機能に関するエラーの応答処理に本通信システム２０の特徴があり、以下、一例として、拡張機能が分割送受信機能である場合について具体的な内容を説明する。まず、分割送受信機能を用いた送受信処理について説明する。

分割送受信処理とは、ユーザーエージェントＵＡとサービスエージェントＳＡ１との間で、ＵＤＰを用いて、ＳＬＰの通信を行う際に、データを分割して送受信することで、ＵＤＰにより送信可能な容量を超えるデータのやり取りを可能にする処理である。

ユーザーエージェントＵＡにおいて、ユーザーが、ＳＬＰプログラムを起動させ、ディスプレイ４６に示されたＵＩと入力機構４５とを用いて、サービス検索条件を入力し、ユーザーエージェントＵＡのＣＰＵ３０が、この検索指示を受け付けることで開始される。

検索指示を受け付けると、ＣＰＵ３０は、ＳＬＰの属性要求メッセージＲｑ１を作成し、ＵＤＰを用いて送信する。図５は、属性要求メッセージの具体例を説明するための図である。図示する属性要求メッセージＲｑ１は、ＵＤＰデータグラムからＵＤＰヘッダを除いたデータ部分であり、ＳＬＰヘッダとメッセージ部分からなる。図示するように、属性要求メッセージＲｑ１のタグリストには、ベンダ拡張機能による特殊タグが付加されている（図中の射線で示される拡張領域）。この特殊タグは、ＣＰＵ３０が付加するものであり、属性要求メッセージＲｑ１に対する属性応答メッセージＲｐがＵＤＰにより送信可能な容量（ここでは１４００オクテット）を超える場合には、応答データを分割して送信させる分割指示を伝えるパラメータとしての役割を果たす。

サービスエージェントＳＡ１が、当該属性要求メッセージＲｑ１を受信すると、ＣＰＵ５０は、属性要求メッセージＲｑ１を解釈して、これに対する属性リストＡｔを作成し、属性リストＡｔを含む属性応答メッセージＲｐのＳＬＰヘッダ以下のデータ長が１４００オクテットよりも大きいか否かを判断する。

その結果、１４００オクテット以下であれば、属性応答メッセージＲｐは、ＵＤＰで一度に送信できるデータサイズ以下であるということであり、ＣＰＵ５０は、作成した属性リストＡｔを全て含む属性応答メッセージＲｐ１を、ＵＤＰを用いて、ユーザーエージェントＵＡに対してユニキャストで送信する。なお、この際、サービスエージェントＳＡ１は、属性リストＡｔの全てを送信するため、ＳＬＰヘッダのＯＶＥＲＦＬＯＷフラグは「ＯＦＦ」となっている。

一方、１４００オクテットよりも大きければ、属性応答メッセージＲｐは、ＵＤＰで一度に送信できるデータサイズを超えているということであり、ＣＰＵ５０は、受信した属性要求メッセージＲｑ１内に特殊タグが含まれているか否かを判断する。その結果、特殊タグが含まれていなければ、属性リストＡｔを分割して送信する必要はないということである。そこで、ＣＰＵ５０は、作成した属性リストＡｔの一部を基に、属性応答メッセージＲｐのサイズが１４００オクテットに収まる範囲で、属性応答メッセージＲｐ１を作成して、ＵＤＰを用いて、ユーザーエージェントＵＡに対してユニキャストで送信する。なお、この際、サービスエージェントＳＡ１は、属性リストＡｔの一部しか送信できないため、ＳＬＰヘッダのＯＶＥＲＦＬＯＷフラグは「ＯＮ」となっている。

一方、特殊タグが含まれていれば、属性リストＡｔを分割して送信する必要があるということであり、ＣＰＵ５０は、属性応答メッセージＲｐが１４００オクテットに収まるように、属性リストＡｔをｎ個に分割する。そして、ＣＰＵ５０は、ｎ個に分割した分割属性リストＡｔｉ（ｉ＝１〜ｎ）のうち、属性リストＡｔの先頭を構成する分割属性リストＡｔ１を基に、属性応答メッセージＲｐ１を作成し、ＵＤＰを用いて、ユーザーエージェントＵＡに対してユニキャストで送信する。なお、この際、サービスエージェントＳＡ１は、分割属性リストＡｔ１の全てを送信するため、ＳＬＰヘッダのＯＶＥＲＦＬＯＷフラグは「ＯＦＦ」となっている。

図６は、属性応答メッセージの具体例を説明するための図である。属性応答メッセージＲｐ１は、ＵＤＰデータグラムからＵＤＰヘッダを除いたデータ部分であり、ＳＬＰヘッダとメッセージ部分からなる。図示するように、属性応答メッセージＲｐ１の属性リストのうちベンダ拡張領域には、属性要求メッセージＲｑに含まれていた特殊タグ、サービスエージェントＳＡ１の識別情報、分割属性リストＡｔｉの並び順を示すシーケンスナンバーＳＮが付加されている。

これらの情報は、ＣＰＵ５０が付加するものである。特殊タグは、分割属性リストＡｔ１に続き受け取るべき分割属性リストが他に存在するか否かを示すフラグビットを有している。ここでは、分割属性リストＡｔ１に続き受け取るべき分割属性リストが他に存在するので、フラグは、そのことを示す「ＯＮ」となっている。シーケンスナンバーＳＮは、順序情報として、分割属性リストＡｔ１に対応する「１」となっている。識別情報は、一例として、サービスエージェントＳＡ１のＭＡＣアドレスである。

属性応答メッセージＲｐ１を送信すると、ＣＰＵ５０は、属性要求メッセージＲｑｉの受信を待機する。この属性要求メッセージＲｑｉは、ユーザーエージェントＵＡが、属性要求メッセージＲｑ１を送信した後に更に送信し、属性リストＡｔを構成するｉ番目の分割属性リストＡｔｉの送信を要求するものである。

そして、属性要求メッセージＲｑｉを受信すると、ＣＰＵ５０は、属性要求メッセージＲｑｉに含まれるシーケンスナンバーＳＮ（＝ｉ）を参照し、ＳＮが、属性リストＡｔの分割数であるｎに等しいか否かを判断する。その結果、シーケンスナンバーＳＮがｎでなければ、属性要求メッセージＲｑｉは、属性リストＡｔを構成する最後の分割属性リストＡｔｎを要求するものではないということである。

属性要求メッセージＲｑｉに含まれるシーケンスナンバーＳＮ「ｉ」に対応するｉ番目の分割属性リストＡｔｉに、識別情報とシーケンスナンバーＳＮ「ｉ」とを付加すると共に、送信する分割属性リストＡｔｉに続きがあることを示すために、特殊タグのフラグを「ＯＮ」として、属性応答メッセージＲｐｉを作成し（図６の（ｂ））、ＵＤＰを用いて、ユーザーエージェントＵＡに対してユニキャストで送信する。

その後、受信した属性要求メッセージＲｑｉのシーケンスナンバーＳＮがｎとなるまで同様の応答処理を繰り返す。

そして、シーケンスナンバーＳＮがｎになれば、属性要求メッセージＲｑｉは、属性リストＡｔを構成する最後の分割属性リストＡｔｎを要求するものであるということであるので、分割属性リストＡｔｎに、識別情報と、シーケンスナンバーＳＮ「ｎ」とを付加すると共に、送信する分割属性リストＡｔｎに続きがないことを示すために、特殊タグのフラグを「ＯＦＦ」として、属性応答メッセージＲｐｎを作成し（図６の（ｃ））、ユーザーエージェントＵＡに対してユニキャストで送信する。

一方、ユーザーエージェントＵＡ側では、上記属性要求メッセージＲｑ１を送信した後、サービスエージェントＳＡ１からの属性応答メッセージＲｐｉの受信を待機し、属性応答メッセージＲｐｉ（最初はＲｑ１）を受信すると、ＣＰＵ３０は、属性応答メッセージＲｐｉに含まれる特殊タグのフラグが「ＯＮ」であるか否かを判断する。その結果、フラグが「ＯＦＦ」であれば、サービスエージェントＳＡ１が応答すべき属性リストには、続きがないということであり、ＣＰＵ３０は、分割要求処理を終了する。そして、ＣＰＵ３０は、複数の分割属性リストＡｔｉを受信した場合には、これらを合成して属性リストＡｔを生成する。ＣＰＵ３０は、こうして得られた属性リストＡｔの内容を、ディスプレイ４６に表示させる。

一方、フラグが「ＯＮ」であれば、受信した属性応答メッセージＲｐｉに含まれる分割属性リストＡｔｉには続きがあるということであるので、ＣＰＵ３０は、属性応答メッセージＲｐｉに含まれるシーケンスナンバーＳＮを１インクリメント（ＳＮ：ｉ→ｉ＋１）して、当該シーケンスナンバーＳＮを付加したＳＬＰの属性要求メッセージＲｑ（ｉ＋１）を作成し（図５の（ｂ）、（ｃ））、ＵＤＰを用いて送信する。

こうして、属性要求メッセージＲｑ（ｉ＋１）を送信すると、ＣＰＵ３０は、受信した特殊タグのフラグが「ＯＦＦ」になるまで、すなわち、分割された分割属性リストＡｔｉを全て受け取るまで、同様の要求処理を繰り返す。

以上説明したように、分割送受信処理が拡張機能として行われる場合に、属性要求メッセージのこの拡張機能中にエラーがあった場合には、サービスエージェントＳＡ１、ＳＡ２は、図４の（ｄ）に基づいて説明した前述の方法でエラー応答を行う。

図７は、かかるエラー応答の具体例を説明するための図である。例えば、属性要求メッセージの拡張領域に、上記分割送受信処理のセッション中でないのに上記シーケンスナンバーＳＮが指定されている場合には、図７の（ａ）に示すような応答メッセージを生成して送信する。具体的には、前述したプロトコル上のエラーコードはエラーがない旨のコードとし、拡張領域に、分割セッション中ではないのにシーケンスナンバーＳＮが指定されたことを意味するエラーコード（ＥＲＲＯＲ＝１）を入れた応答コードが生成されて送信される。

図７の（ｂ）に示す例は、属性要求メッセージの拡張領域に示されるシーケンスナンバーＳＮが無効な値である場合である。例えば、属性値が５分割されている場合に（ｎ＝５である場合に）、ＳＮ＝６というコードが指定されたような場合である。かかる場合は、図示されるように、プロトコル上のエラーコードはエラーがない旨のコードとし、拡張領域に、分割のシーケンスナンバーＳＮが無効であることを意味するエラーコード（ＥＲＲＯＲ＝２）を入れた応答コードが生成されて送信される。

このようなエラー応答メッセージが送信されると、ユーザーエージェントＵＡは、当該メッセージの拡張領域に含まれる上記エラーコードを解釈して、エラーのない属性要求メッセージを再送するなどの対応を行う。

なお、以上説明した例では拡張機能が分割送受信機能であったが、他の拡張機能であっても、本通信システム２０の特徴であるエラー応答の方法を適用できることは言うまでもない。また、上述の例では通信プロトコルがＳＬＰであったが他のプロトコルを用いることもできる。

以上説明したように、本実施の形態例に係る通信システム２０では、ＳＬＰなどの通信プロトコルにより拡張機能を用いた要求を行った場合に、その拡張機能部分にエラーが存在した場合には、その拡張機能部分の属性値として当該エラーの存在と内容を示すコードが応答されるので、要求側は、従来よりもエラーの内容を適確に把握することができるようになり、エラーに対する適確な対処が可能となる。

なお、本発明は上記実施形態に限られるものではなく、本発明の要旨を脱しない範囲において、種々なる態様で実施できることは勿論である。例えば、本発明は、ユーザーエージェントとしてのパーソナルコンピューター、サービスエージェントとしてのプリンターとしての構成を例示したが、ユーザーエージェント及びサービスエージェントは、携帯電話、デジタルカメラ、ＦＡＸ、ルータなど、種々のネットワーク機器として実現することができる。

ＵＡ ユーザーエージェント（処理要求装置）、 ＳＡ１、ＳＡ２ サービスエージェント（処理応答装置）、 ２０ 通信システム、 ３０ ＣＰＵ、 ４１ ＨＤＤ、 ４２ ＲＯＭ、 ４３ ＲＡＭ、 ４５ 入力機構、 ４６ ディスプレイ、 ４９ Ｉ／Ｆ、 ５０ ＣＰＵ、 ６１ ＥＥＰＲＯＭ、 ６２ ＲＯＭ、 ６３ ＲＡＭ、 ６５ 入力機構、 ６６ 印刷機構、 ６７ スキャナ、 ６８ ＦＡＸ送信機構、 ６９ Ｉ／Ｆ

Claims (7)

1. 処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理要求装置と処理応答装置とがネットワークを介して通信する通信システムであって、
   前記処理応答装置は、前記処理要求装置から送信された要求通信の、前記通信プロトコルにおける拡張機能を示す拡張領域にエラーが存在する場合に、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードの領域ではエラー無しを意味するコードを入れ、前記拡張機能に対する応答を行う拡張領域に、前記拡張機能で問われた応答値として前記エラーの存在と内容を示すコードを入れた、応答通信を行う
   ことを特徴とする通信システム。
2. 請求項１において、
   前記通信プロトコルはＳＬＰである
   ことを特徴とする通信システム。
3. 請求項１あるいは請求項２において、
   前記拡張機能は、前記要求に対して前記処理応答装置が応答すべき応答データが、送信可能な所定容量を超える場合には、当該応答データを分割して送信させる機能である
   ことを特徴とする通信システム。
4. 処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理応答装置とネットワークを介して通信する処理要求装置あって、
   前記通信プロトコルにおける拡張機能を示す拡張領域にエラーが存在する要求通信を行った場合に、
   前記処理応答装置から、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードの領域ではエラー無しを意味するコードを入れ、前記拡張機能に対する応答を行う拡張領域に、前記拡張機能で問われた応答値として前記エラーの存在と内容を示すコードを入れた応答通信を受信する
   ことを特徴とする処理要求装置。
5. 処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理要求装置とネットワークを介して通信する処理応答装置であって、
   前記処理要求装置から送信された要求通信の、前記通信プロトコルにおける拡張機能を示す拡張領域にエラーが存在する場合に、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードの領域ではエラー無しを意味するコードを入れ、前記拡張機能に対する応答を行う拡張領域に、前記拡張機能で問われた応答値として前記エラーの存在と内容を示すコードを入れた、応答通信を行う
   ことを特徴とする処理応答装置。
6. 処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理要求装置と処理応答装置とがネットワークを介して通信する通信方法において、
   前記処理応答装置が、前記処理要求装置から送信された要求通信の、前記通信プロトコルにおける拡張機能を示す拡張領域にエラーが存在する場合に、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードの領域ではエラー無しを意味するコードを入れ、前記拡張機能に対する応答を行う拡張領域に、前記拡張機能で問われた応答値として前記エラーの存在と内容を示すコードを入れた、応答通信を行う
   ことを特徴とする通信方法。
7. 処理要求装置が送信した要求に対して処理応答装置が応答する通信プロトコルにより、処理要求装置とネットワークを介して通信する処理応答装置に、応答処理を実行させるプログラムであって、
   前記処理要求装置から送信された要求通信の、前記通信プロトコルにおける拡張機能を示す拡張領域にエラーが存在する場合に、当該要求通信に対して、前記通信プロトコルで用意されたエラーコードの領域ではエラー無しを意味するコードを入れ、前記拡張機能に対する応答を行う拡張領域に、前記拡張機能で問われた応答値として前記エラーの存在と内容を示すコードを入れた応答通信を、前記処理応答装置に実行させる
   ことを特徴とするプログラム。

Images