JPH0816493A - スキャナプリンタサーバーシステムのデータ通信制御方法 - Google Patents

Abstract

(57)【要約】 【目的】 アプリケーションのデッドロック状態を確実
に防止できるとともに、アプリケーションからの入出力
要求を正常に行える通信環境に復帰できる。 【構成】 アプリケーションから入出力要求に応じて前
記クライアントマシンが前記サーバー装置に発行する所
定のパケットに対する応答パケットの発行状態を所定時
間監視し、所定時間内に前記応答パケットが前記サーバ
ー装置より発行されない場合に、アプリケーションに対
して前記サーバー装置の異常状態を応答する構成を特徴
とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ネットワークに接続さ
れた１台以上のプリンタ／スキャナを、複数のコンピュ
ータから利用するためのスキャナプリンタサーバーシス
テムのデータ通信制御方法に関するものである。

【０００２】

【従来の技術】従来、１台のサーバー装置に複数のプリ
ンタ／スキャナを接続して、それにネットワーク経由で
印刷／スキャンをする場合、複数のプリンタ／スキャナ
を利用の都度切り替え選択して使う方法がなかったか、
あっても極めて繁雑な操作が必要であった。

【０００３】従来の一般的なやり方は、たとえ複数のプ
リンタ／スキャナがサーバー装置に接続されていても、
その中の特定のプリンタまたはスキャナに常に接続する
ように設定して使っていた。プリンタ／スキャナを切り
替える場合には、プリンタドライバを切り替えることに
よって行っていた。

【０００４】従来のネットワーク印刷のための通信プロ
トコルは、データ（ファイル）の一括転送が主体であっ
た。データはひとつの塊としてバッチ的に転送され、ジ
ョブがキューに登録されると通信は終了していた。

【０００５】これは、クライアント側のコンピュータを
速やかに印刷の作業から解放するために取った方法であ
るが、処理がバッチ的なのでプリンタ側で何等かのトラ
ブルが発生しても「トラブル記録」ファイルが自動的に
生成されるだけで、クライアント側には何も知らされな
い。また、プリンタを選択するのもドライバの選択によ
っていた。

【０００６】他のコンピュータのオペレーティングシス
テム（ＯＳ）の場合、ローカルプリンタに印刷する手前
のデータを、ＢＩＯＳ部分でストールしてネットワーク
プリンタに伝送する形式のものもある。これらもプリン
タ側で何等かのトラブルが発生しても、クライアント側
には何も知らされない。レーザプリンタの場合、やや改
良された通信機能を持ったプリンタもあり、「紙無し」
等のエラーコードをクライアントに伝送できるものもあ
る。

【０００７】しかし、プリンタを切り替える場合にはプ
リンタドライバの切り替えが必要であった。

【０００８】

【発明が解決しようとする課題】この様に従来のプリン
タサーバー装置においては、１台のサーバー装置に接続
された複数のプリンタ／スキャナを選択するのに、プリ
ンタドライバを切り替えることによって対応していたの
で、サーバー装置とプリンタ／スキャナの接続形態が少
し変わる度に、異なるプリンタドライバを用意しなけれ
ばならないとい問題点があった。

【０００９】また、この種のプリンタサーバー装置は、
１台のサーバー装置に複数のプリンタが接続されている
状態であるから、プリンタドライバを選択しただけで
は、単にサーバー装置が選択されるだけで、そこに接続
されているプリンタを選択したことにはならない。プリ
ンタを選択するためには、プリンタドライバ自身がサー
バー装置におけるプリンタの接続状況を知っている必要
があるが、そのようなコンフィギュレーションをプリン
タドライバに記録することは拡張性を阻害する等の問題
点があった。

【００１０】さらに、通常、クライアントマシンはシン
グルユーザモードで動作させる場合が多く、通信の異常
は即アプリケーションのデッドロックにつながってしま
うという問題点があった。

【００１１】本発明は、上記の問題点を解消するために
なされたもので、本発明に係る第１〜第６の発明の目的
は、アプリケーションからの入出力デバイス要求に基づ
くクライアントマシンとサーバー装置とのパケット通信
において、通信エラーが発生した場合に、アプリケーシ
ョンにパケット通信エラーを通知するとともに、通信エ
ラー回復処理を行うことにより、アプリケーションのデ
ッドロック状態を確実に防止できるとともに、アプリケ
ーションからの入出力要求を正常に行える通信環境に復
帰できるスキャナプリンタサーバーシステムのデータ通
信制御方法を提供することである。

【００１２】

【課題を解決するための手段】本発明に係る第１の発明
は、ネットワーク上に複数のクライアントマシンとスキ
ャナ／プリンタサーバー装置とがパケット通信可能に構
成され、前記スキャナ／プリンタサーバー装置に接続さ
れた複数の入出力デバイスを各クライアントマシンのア
プリケーションが入出力要求を発行して画像入出力処理
を行うスキャナプリンタサーバーシステムのデータ通信
制御方法において、アプリケーションから入出力要求に
応じて前記クライアントマシンが前記サーバー装置に発
行する所定のパケットに対する応答パケットの発行状態
を所定時間監視する監視工程と、この監視工程により前
記所定時間内に前記応答パケットが前記サーバー装置よ
り発行されない場合に、前記アプリケーションに対して
前記サーバー装置の異常状態を応答する応答工程とを有
するものである。

【００１３】本発明に係る第２の発明は、クライアント
マシンは、サーバー装置からの応答パケット発行状態を
タイマにより所定時間監視するように構成したものであ
る。

【００１４】本発明に係る第３の発明は、クライアント
マシンは、応答工程後、サーバー装置に対して異常状態
を回復させるための所定のパケットを発行する回復工程
を有すものである。

【００１５】本発明に係る第４の発明は、クライアント
マシンは、応答工程後、サーバー装置に対して異常状態
を回復させるため異常発生前に発行した同一のパケット
を所定数回発行する再送工程を有するものである。

【００１６】本発明に係る第５の発明は、アプリケーシ
ョンは、クライアントマシンからの異常状態応答に応じ
てクライアントマシンに対してサーバー装置の異常回復
を要求する回復要求工程を有するものである。

【００１７】本発明に係る第６の発明は、クライアント
マシンは、サーバー装置から正常な応答パケットが発行
された場合に、アプリケーションに対して正常応答を通
知する通知工程を有するものである。

【００１８】

【作用】第１の発明においては、アプリケーションから
入出力要求に応じて前記クライアントマシンが前記サー
バー装置に発行する所定のパケットに対する応答パケッ
トの発行状態を所定時間監視し、所定時間内に前記応答
パケットが前記サーバー装置より発行されない場合に、
アプリケーションに対して前記サーバー装置の異常状態
を応答して、アプリケーション側にサーバー装置とクラ
イアントマシン間における通信異常有無を通知して、ア
プリケーションのデッドロック状態が発生しないように
する。

【００１９】第２の発明においては、クライアントマシ
ンは、サーバー装置からの応答パケット発行状態をタイ
マにより所定時間監視して、サーバー装置とクライアン
トマシン間における通信異常有無を判別する。

【００２０】第３の発明においては、クライアントマシ
ンは、アプリケーションに対して前記サーバー装置の異
常状態を応答後、サーバー装置に対して異常状態を回復
させるための所定のパケットを発行して、クライアント
マシンがサーバー装置に対してい正常通信状態への移行
を催促する。

【００２１】第４の発明においては、クライアントマシ
ンは、アプリケーションに対して前記サーバー装置の異
常状態を応答後、サーバー装置に対して異常状態を回復
させるため異常発生前に発行した同一のパケットを所定
数回発行して、異常発生前のパケット通信を正常に再開
する。

【００２２】第５の発明においては、アプリケーション
は、クライアントマシンからの異常状態応答に応じてク
ライアントマシンに対してサーバー装置の異常回復を要
求して、アプリケーション側からクライアントマシンに
対してサーバー装置との正常な通信状態に復帰するため
に必要な所定の回復処理の起動を催促する。

【００２３】第６の発明においては、クライアントマシ
ンは、サーバー装置から正常な応答パケットが発行され
た場合に、アプリケーションに対して正常応答を通知し
て、サーバー装置との通信異常で中断していた入出力処
理を正常に再開する。

【００２４】

【実施例】以下、図示の実施例に基づき詳細に説明す
る。

【００２５】図１は本発明の一実施例を示すスキャナプ
リンタサーバーシステムの構成を説明するブロック図で
ある。

【００２６】図において、１〜４はクライアントコンピ
ュータ（クライアントと呼ぶ場合ある）、５はローカル
エリアネットワーク（ＬＡＮ）、６はカラーＳＰサーバ
ー装置（単にサーバー装置と書く場合もある）、７はプ
リンタＡとしてのプリンタ、８はプリンタＢとしてのプ
リンタ、９はスキャナＣとしてのスキャナである。な
お、７，８，９は後述の説明中、単位にデバイスＡ，
Ｂ，Ｃと略記する場合がある。

【００２７】クライアント１，２，３，４は、ＬＡＮ５
を介してサーバー装置６と接続されており、このＬＡＮ
５を介してデバイス７，８，９に印刷またはスキャンを
することができる。

【００２８】図２は本発明に係るスキャナプリンタサー
バーシステムにおける操作者，アプリケーション，クラ
イアント（Ｃｌｉｅｎｔ），サーバー装置（Ｓｅｒｖｅ
ｒ）およびデバイスとの間でのプリンタ処理手順の一例
を示すコマンドのシーケンスダイヤグラムである。な
お、図中、上から下に時間が流れていくようすを示すと
共に、矢印の方向にコマンドが流れていくようすも示し
ている。

【００２９】操作者がアプリケーションに対し「印刷」
を指示すると、アプリケーションはＣｌｉｅｎｔに対し
て「印刷要求」を送る。Ｃｌｉｅｎｔのプログラム形式
はプリンタドライバである。従って、アプリケーション
とＣｌｉｅｎｔの間には通常ＯＳが介在するが、図面で
は省略してある。 〈プリント〉上記「印刷要求」を受け取ると、Ｃｌｉｅ
ｎｔはＳｅｒｖｅｒとの間にトランスポート接続を張
る。この方法は一般的なので、図面では省略してある。

【００３０】図２におけるＣｌｉｅｎｔとＳｅｒｖｅｒ
間のやり取りは、全てトランスポート層の上のセッショ
ン層について記述しており、セッション層は、後述のよ
うに、内部的に２つのサブレイヤに分かれ、下位レイヤ
をレベル１、上位レイヤをレベル２としている。

【００３１】図２においては、「Ｌｉｎｋ」，「Ｌｉｎ
ｋ＿Ａｃｋ」，「Ｒｅｌｅａｓｅ」，「Ｒｅｌｅａｓｅ
＿Ａｃｋ」がレベル１に属し、他は全てレベル２に属す
る。

【００３２】「印刷要求」の後、トランスポート接続が
確立したら、レベル１の接続を行う。それがＬｉｎｋお
よびその応答のＬｉｎｋ＿Ａｃｋパケットのやり取りで
ある。

【００３３】通常、「印刷要求」の中でデバイス指定を
行うことはないが、オプションでデバイス指定が可能な
ように構成されている。

【００３４】デバイス指定がない場合、Ｃｌｉｅｎｔは
Ｓｅｒｖｅｒに対し「Ｏｐｅｎ」パケットを送る。先ほ
ど述べた通り、これはレベル２のパケットである。それ
を受けてＳｅｒｖｅｒは全てのデバイス（実際にはデバ
イスドライバ）に問い合わせ、電源が入っているかどう
かをチェックする。これが、図２の「問い合わせ」／
「問い合わせ応答」に対応する。

【００３５】このようにして、どのデバイスが使用可能
であるかどうかをリストアップしたパケット「Ｏｐｅｎ
＿Ａｃｋ」がＳｅｒｖｅｒから返されると、Ｃｌｉｅｎ
ｔはデバイスリスト表示ダイアログを開いて操作者にデ
バイスの選択を促す。

【００３６】デバイスが選択されると、Ｃｌｉｅｎｔは
Ｓｅｒｖｅｒに「ＩＮＩＴ」パケットを送って、サーバ
ー装置およびデバイスの初期化を行う。

【００３７】このようにして初期化が成功すると、デバ
イスは「初期化肯定応答」（図示せず）を返すので、直
ちに印刷を開始できる。

【００３８】しかし、通常はデバイスが選択されただけ
では初期化が十分でなく、デバイスはさらに細かなパラ
メータを必要とするので、「初期化否定応答」を返す。
いずれの場合でもＳｅｒｖｅｒはＣｌｉｅｎｔに対して
「ＩＮＩＴ＿Ａｃｋ」を返す。

【００３９】ただし、「初期化否定応答」に対しては同
パケットのｍｏｄｉｆｉｅｒビットをエラーにセットし
て返す。

【００４０】通常は、用紙サイズが適当でない等の書式
エラーが返されるので、アプリケーションは「デバイス
機能」／「デバイス機能応答」コマンドでデバイスの能
力を調べる。

【００４１】それは、Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ間で
は「Ｃａｐａｂｉｌｉｔｙ」／「Ｃａｐａｂｉｌｉｔｙ
＿Ａｃｋ」パケットであり、Ｓｅｒｖｅｒ／デバイス間
では「能力問い合わせ」／「能力問い合わせ応答」コマ
ンドでやり取りされる。

【００４２】デバイスの印刷機能が分かると、アプリケ
ーションは正確な書式指定が可能となりＣｌｉｅｎｔに
対して「書式指定」コマンドを発行する。本発明では、
初期化のためのパケットと書式指定のためのパケットを
同じ「ＩＮＩＴ」で兼用しているので、Ｃｌｉｅｎｔか
らＳｅｒｖｅｒに対して「ＩＮＩＴ」パケットが送出さ
れる。それによってデバイスには「初期化」コマンドが
再び送られるが、今度は適格なパラメータが設定されて
いるので、肯定応答が返される。

【００４３】これにより、書式指定が完了したので、こ
こで初めて印刷が可能となる。アプリケーションから
「印刷開始」コマンドが出て、「Ｐｒｉｎｔ」パケット
としてＳｅｒｖｅｒに送られる。そのレスポンスは「Ｐ
ｒｉｎｔ＿Ａｃｋ」パケットとして返され、「印刷開始
応答」コマンドがアプリケーションに返される。

【００４４】この後、印刷すべきデータが伝送される。
データは、所定サイズに分割して「Ｄａｔａ」パケット
に乗せられる。

【００４５】受信側では、再びそれを元のサイズに結合
して使う。当然「Ｄａｔａ」パケットのヘッダ等の不用
部分も削除される。「Ｄａｔａ＿Ａｃｋ」パケットは、
「Ｄａｔａ」パケットに対する正確なレスポンスを返す
ように定義されており、「Ｄａｔａ」パケットが送れた
のか送れなかったのかが１対１で分かるようになってい
る。それに対して、「データ」コマンドに対する「デー
タ応答」は必ずしもそのようではない。

【００４６】その理由は通常、「データ」コマンドは関
数コール（サブルーチンコール）の形式を取るのに対
し、「データ応答」コマンドは、その関数の戻り値で与
えられる。そのため「Ｄａｔａ＿Ａｃｋ」パケットが何
等かの理由により返されなかった時に、「データ応答」
が返せないのでアプリケーションがデッドロック状態に
なる。

【００４７】これを防止するために、「Ｄａｔａ」パケ
ットを送信してから一定時間以内に「Ｄａｔａ＿Ａｃ
ｋ」パケットが返されなかったら、Ｃｌｉｅｎｔは自分
の責任で「Ｄａｔａ」パケットを再送すると共に、「デ
ータ応答」コマンドの所定ビットをエラーに設定してア
プリケーションに戻してしまう。

【００４８】しかし、本プロトコルはセッション層につ
いて定義しているので、その下位レイヤのトランスポー
ト層が、エンドツーエンドで誤りのない通信を保証して
いるから、やがて「Ｄａｔａ＿Ａｃｋ」パケットが返さ
れる。

【００４９】しかし、この時には既に「データ応答」の
所定ビットをエラーに設定して、関数の戻り値としてア
アプリケーションに返してしまっているので、エラーで
ない「データ応答」を返す手段がない。

【００５０】従って、「データ」コマンドに対する「デ
ータ応答」は所定のビットがエラーに設定されていたと
しても、必ずしもエラーとはいえない。

【００５１】「データ応答」の所定ビットがエラーに設
定されていた場合には、その内容にもよるが、通常は
「進捗」コマンドを発行してＣｌｉｅｎｔ／Ｓｅｒｖｅ
ｒ間の通信の状態を調べる。

【００５２】Ｃｌｉｅｎｔは必要に応じてＳｅｒｖｅｒ
に対して「Ｐｒｏｇｒｅｓｓ」パケットを発行して「Ｐ
ｒｏｇｒｅｓｓ＿Ａｃｋ」パケットを受け取り、通信の
状態を調べ、結果を「進捗応答」コマンドとしてアプリ
ケーションに戻す。

【００５３】アプリケーションは、ファイルの終了（Ｅ
ＯＦ）に到達するまで次の「データ」コマンドを送り続
ける。「進捗応答」の内容は、操作者に分かるように画
面に表示する。

【００５４】このようにしてデータを送り終ったら、ア
プリケーションはＣｌｉｅｎｔに対して印刷の終了を確
認するために「終了」コマンドを発行する。それを受け
てＣｌｉｅｎｔはＳｅｒｖｅｒに「Ｃｌｏｓｅ」パケッ
トを発行するが、印刷が完了するまでは「Ｃｌｏｓｅ＿
Ａｃｋ」パケットは返されない。この間アプリケーショ
ンはデッドロック状態になる。

【００５５】これを防止するために、Ｃｌｉｅｎｔは自
分の責任でＳｅｒｖｅｒに「Ｐｒｏｇｒｅｓｓ」パケッ
トを送出すると共に、「終了応答」コマンドの所定ビッ
トを｛印刷中｝に設定してアプリケーションに戻してし
まう。

【００５６】もし印刷をバックグラウンドで行う場合に
は、｛印刷中｝であっても次のステップに移ってしま
う。そうでない（フォアグランド印刷）場合には、「終
了コマンドを再発行すると共に、「終了応答」コマンド
の所定ビットが｛印刷完了｝となるまでループする。

【００５７】印刷が完了した後は、Ｃｌｉｅｎｔは「Ｒ
ｅｌｅａｓ」パケットを発行し、Ｓｅｒｖｅｒから「Ｒ
ｅｌｅａｓｅ＿Ａｃｋ」パケットを受け取ったら、レベ
ル１以下の接続を切断する。

【００５８】Ｓｅｒｖｅｒ側も「Ｒｅｌｅａｓｅ」パケ
ットを受信したら「Ｒｅｌｅａｓｅ＿Ａｃｋ」パケット
を送信後レベル１以下の接続を切断する。 〈スキャン〉原稿をスキャンする場合には、印刷時とほ
とんど同じシーケンスで処理がなされる。大きな違いは
データの流れる向きが印刷の時と逆であるという点であ
る。スキャンのシーケンスダイヤグラムを図３に示す。

【００５９】図３は本発明に係るスキャナプリンタサー
バーシステムにおける操作者，アプリケーション，クラ
イアント（Ｃｌｉｅｎｔ），サーバー装置（Ｓｅｒｖｅ
ｒ）およびデバイスとの間でのスキャン処理手順の一例
を示すコマンドのシーケンスダイヤグラムである。

【００６０】同図に示すように、「Ｄａｔａ」パケット
と「Ｄａｔａ＿Ａｃｋ」パケットの向きは印刷時と逆で
あるが、「データ要求」コマンドと「データ要求応答」
コマンドの向きは変化がない。これは、関数を呼ぶ側
（アプリ）と呼ばれる側（ＯＳ）の立場は変わらないか
らである。スキャンされたデータは、「データ要求応
答」コマンドに乗って来る。バックグラウンドスキャン
は、バックグラウンド印刷と同様に可能であるが、図３
の実施例では入れていない。

【００６１】図４は本発明に係るスキャナプリンタサー
バー装置の第１のデータ通信制御方法の一実施例を示す
フローチャートであり、特に、データ通信中における中
断シーケンスに対応する。

【００６２】アプリケーションから「印刷」要求があっ
た場合、Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ間で「Ｌｉｎ
ｋ」，「Ｌｉｎｋ＿Ａｃｋ」，「Ｏｐｅｎ」，「Ｏｐｅ
ｎ＿Ａｃｋ」等のパケットのやり取りは順調に推移した
ものとする。

【００６３】今、Ｃｌｉｅｎｔが「ＩＮＩＴ」を発行し
たらその応答「ＩＮＩＴ＿Ａｃｋ」がＳｅｒｖｅｒから
なかなか戻らない場合を想定する。

【００６４】通常のシーケンスでは、「ＩＮＩＴ＿Ａｃ
ｋ」がなかなか帰らないと、その間アプリケーションは
デッドロック状態となる。これを防止するためにタイマ
をセットし、例えば数秒待ってもサーバー装置から応答
がこない場合には、応答待ち状態を強制的に抜け出して
中断／回復／再送処理を行う。

【００６５】タイマのセットは、例えばＯＳに対してタ
イマシグナルを発行する。タイマがカウント満了すると
ＯＳは、シグナル発行時にセットした処理ルーチンに制
御を戻すので、その中で例えば疑似的に「エラーパケッ
ト」を自分自身（この場合はクライアント）に発行する
ことにより、パケット解析ルーチンで統一的に「デー
タ」，「コマンド」，「エラー」パケットの解析が行え
る。

【００６６】この図の例では、ＩＮＩＴ＿Ａｃｋが所定
時間以内に戻らなかった場合に、クライアントは「印刷
要求応答」をエラーにしてアプリケーションにその旨の
メッセージを戻すことにより、アプリケーションに異常
事態に対する次のアクションを促している。

【００６７】ここでは、アプリケーションは「中断」パ
ケットをクライアントに送り、それ以降の処理を中断さ
せている。

【００６８】ただし、中断とはいってもそこでシーケン
スを突然やめてしまう訳にはいかない。サーバー装置や
デバイスに余計な「シーケンス的ストレス」を与えない
ために、「中断」パケットを発行した後のシーケンス
も、中断なりに正常に終了させる必要がある。さもなけ
れば、１つの異常が原因で連鎖反応的にエラーが拡大し
てしまうからだ。

【００６９】そこで、本実施例では、通信プロトコルの
パケット送出時にソフト的なタイマを起動し、タイマが
満了した場合には、異常終了シーケンスに移行すること
により、アプリケーションのデッドロックを防止する。

【００７０】なお、タイマが満了した場合の取り得るア
クションは、例えば「中断」「回復」「再送」である。
また、タイマの処理方法にも工夫が必要である。タイマ
ルーチンは、通常のパケット受信ルーチンとは本来無関
係の独立ルーチンで、ＯＳに対してタイマをセットして
それをＯＮすると、タイマが満了した場合には、単にタ
イマをセットした時に登録した処理ルーチンが１回コー
ルされるだけなので、パケットの受信待ちになっている
受信ルーチンはタイマを検知できなくなる。

【００７１】そこで、本実施例では、該タイマルーチン
の中で、自分自身にタイマパケットを送信することによ
り、受信ルーチンにタイマの満了を知らせている。そし
て、タイマパケットを受信した受信ルーチンは、単に１
つの状態変化として捉えることができ、デッドロックを
確実に防止できるとともに、状態遷移表の設計が極めて
容易になる。

【００７２】図５は本発明に係るスキャナプリンタサー
バー装置の第２のデータ通信制御方法の一実施例を示す
フローチャートであり、特に、データ通信中における回
復シーケンスに対応する。なお、図４と異なるのは、ク
ライアントが「印刷要求応答」をエラーとして帰した時
に、アプリケーションは「中断」の代わりに「回復」パ
ケットを発行する。

【００７３】クライアントは、今度は回復パケットなの
で、サーバー装置に対して異常の回復を要求するためＩ
ＮＩＴパケットを再発行して再度サーバー装置からの応
答「ＩＮＩＴ＿Ａｃｋ」を待つ。

【００７４】図６は本発明に係るスキャナプリンタサー
バー装置の第３のデータ通信制御方法の一実施例を示す
フローチャートであり、特に、データ通信中における再
送シーケンスに対応する。

【００７５】本実施例では、クライアントがサーバー装
置からＩＮＩＴ＿Ａｃｋが帰らない時、クライアントが
ループによって最大５回まで同一のＩＮＩＴパケットを
サーバー装置に再送する。

【００７６】以下、本実施例と第１〜第６の発明の各工
程との対応及びその作用について図４〜図６を参照して
説明する。

【００７７】第１の発明は、ネットワーク５上に複数の
クライアントマシン（クライアントコンピュータ１〜
４）とスキャナ／プリンタサーバー装置６とがパケット
通信可能に構成され、前記スキャナ／プリンタサーバー
装置６に接続された複数の入出力デバイス（プリンタ
７，８，スキャナ９）を各クライアントマシンのアプリ
ケーションが入出力要求を発行して画像入出力処理を行
うスキャナプリンタサーバーシステムのデータ通信制御
方法において、図４等のアプリケーションＡＰから入出
力要求に応じて前記クライアントマシンＣＭが前記サー
バー装置ＳＲに発行する所定のパケットに対する応答パ
ケットの発行状態を所定時間監視する監視工程（図４の
通信処理Ｓ１）と、この監視工程により前記所定時間内
に前記応答パケットが前記サーバー装置より発行されな
い場合に、前記アプリケーションに対して前記サーバー
装置の異常状態を応答する応答工程（図４の処理Ｓ２）
とを実行して、アプリケーション側にサーバー装置とク
ライアントマシン間における通信異常有無を通知して、
アプリケーションのデッドロック状態が発生しないよう
にする。

【００７８】第２の発明は、クライアントマシンは、サ
ーバー装置からの応答パケット発行状態をタイマ（図４
等のタイマＴＭ１〜ＴＭ５）により所定時間監視して、
サーバー装置とクライアントマシン間における通信異常
有無を判別する。

【００７９】第３の発明は、クライアントマシンＣＭ
は、応答工程後、サーバー装置ＳＲに対して異常状態を
回復させるための所定のパケットを発行する回復工程
（図５の処理Ｓ３）を実行して、クライアントマシンＣ
Ｍがサーバー装置に対してい正常通信状態への移行を催
促する。

【００８０】第４の発明は、クライアントマシンＣＭ
は、応答工程後、サーバー装置ＳＲに対して異常状態を
回復させるため異常発生前に発行した同一のパケットを
所定数回発行する再送工程（図６の処理Ｓ４）を実行し
て、異常発生前のパケット通信を正常に再開する。

【００８１】第５の発明は、アプリケーションＡＰは、
クライアントマシンＣＭからの異常状態応答に応じてク
ライアントマシンＣＭに対してサーバー装置の異常回復
を要求する回復要求工程（図５の処理Ｓ５）を実行し
て、アプリケーションＡＰ側からクライアントマシンＣ
Ｍに対してサーバー装置との正常な通信状態に復帰する
ために必要な所定の回復処理の起動を催促する。

【００８２】第６の発明は、クライアントマシンＣＭ
は、サーバー装置ＳＲから正常な応答パケットが発行さ
れた場合に、アプリケーションＡＰに対して正常応答を
通知する通知工程（図５の処理Ｓ６）を実行して、サー
バー装置ＳＲとの通信異常で中断していた入出力処理を
正常に再開する。 〈Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ通信プロトコル〉以下
に、ＣｌｉｅｎｔとＳｅｒｖｅｒと間の通信プロトコル
の詳細を図７を参照して説明する。

【００８３】図７は本発明に係るスキャナプリンタサー
バー装置におけるクライアントとサーバーとの間の通信
プロトコルの詳細を説明する概念図である。

【００８４】Ｃｌｉｅｎｔ通信プログラムは、大きく分
けて、図７のように３つの部分に分かれます。すなわ
ち、ドライバインタフェース，クライアントプロトコル
本体，ＴＣＰ／ＩＰインタフェースです。

【００８５】以下、プリンタ言語としてＣａＰＳＬ（Ｃ
ａｎｏｎ Ｐｒｉｎｔｉｎｇ Ｓｙｓｔｅｍ Ｌａｎｇ
ｕａｇｅ（商品名：開発元：キヤノン株式会社）を使用
する場合を例として説明するが、他のプリンタ言語（例
えばポストスクリプト（商品名））等であってもよい。

【００８６】Ｃｌｉｅｎｔは、Ｓｅｒｖｅｒに接続され
ているスキャナ／プリンタにＣａＰＳＬコードを伝送し
たり、スキャンしたりするための通信制御プログラムで
あり、ＴＣＰ／ＩＰおよびＥｔｈｅｒｎｅｔを介して通
信する。Ｃｌｉｅｎｔの基本機能は以下の通りである。

【００８７】機能（１）は、ＴＣＰ／ＩＰを介してＳｅ
ｒｖｅｒとＥｎｄ−ｔｏ−Ｅｎｄのリンクを張る機能で
あり、機能（２）は、ＰｒｉｎｔＴＣＰから受け取った
ＣａＰＳＬデータを、Ｓｅｒｖｅｒに送る機能であり、
機能（３）は、Ｓｅｒｖｅｒに原稿のスキャンをさせ、
それを受信し、アプリケーションに送る。

【００８８】Ｓｅｒｖｅｒは、サーバー装置上でデーモ
ンとして常に走っており、クライアントからの受信を待
機する。Ｃｌｉｅｎｔの基本機能は以下の通りである。

【００８９】機能（１）は、Ｃｌｉｅｎｔから受け取っ
たＣａＰＳＬデータを、ＣａＰＳＬインタプリンタに渡
す機能であり、機能（２）は、原稿スキャンプログラム
を起動し、受け取ったデータをＣｌｉｅｎｔに送る。 ＜Ｃｌｉｅｎｔ通信ソフトの機能＞Ｃｌｉｅｎｔ通信ソ
フトの基本機能のうち、機能（１）は、Ｓｅｒｖｅｒと
の間に、ネットワークを介してＥｎｄ−ｔｏ−Ｅｎｄの
呼を張り、通信サービスを提供する機能であり、Ｓｅｒ
ｖｅｒとの間に、ネットワークを介してＥｎｄ−ｔｏ−
Ｅｎｄの呼を張る時、下位プロトコルとしてＴＣＰ／Ｉ
Ｐを用いる。Ｃｌｉｅｎｔは、ＳｅｒｖｅｒとのＥｎｄ
−ｔｏ−Ｅｎｄの呼が張られた状態では、見掛け上、Ｃ
ｌｉｅｎｔとＳｅｒｖｅｒが直接交信しているかのよう
に振舞うが、実際には全てのパケットは下位レイヤのＴ
ＣＰ／ＩＰとやり取りされる。

【００９０】なお、アプリケーションから見たＣｌｉｅ
ｎｔは、ローカルに接続されているスキャナ／プリンタ
のように振舞う。すなわち、Ｃｌｉｅｎｔは「ネットワ
ークを介してスキャナ／プリンタをエミュレートするプ
ログラムである」と言える。

【００９１】機能（２）は、Ｓｅｒｖｅｒ側の印刷／ス
キャン機能をＣｌｉｅｎｔ側からリモート制御する機能
であり、Ｓｅｒｖｅｒ側の印刷／スキャン機能は、当然
Ｃｌｉｅｎｔ側からリモート制御されなければならな
い。所定のプロトコルに従いプリンタ／スキャナの受け
入れ体制を整えた後、原稿データを伝送する。データの
伝送完了後、次の印刷／スキャンに備えてプリンタ／ス
キャナをアイドル（待機）状態まで持っていき、呼を切
る。

【００９２】機能（３）は、所定の手順（プロトコル）
に従い、文書データを伝送する機能であり、（３）所定
の手順（プロトコル）に従い、文書データを伝送する。
なお、以下の説明において、Ｈ＿Ｌｉｎｋ，Ｌ＿Ｌｉｎ
ｋ，ＨＬ＿Ｌｉｎｋのように先頭にＨ＿，Ｌ＿やＨＬ＿
が付いた同一名称のパケットが説明されているが、説明
の都合でこのように表現しているだけなので、同一パケ
ットであるものとする。

【００９３】補助機能のうち、機能（４）は、ネットワ
ークに関する各種パラメータの設定機能であり、機能
（５）は、Ｓｅｒｖｅｒに関する各種パラメータの設定
機能であり、機能（６）はファイルの伝送機能である。 〈パケットの形状〉以下、図８を参照しながらパケット
の形状について説明する。

【００９４】図８は本発明に係るスキャナプリンタサー
バー装置におけるＳＰサーバー装置／クライアントプロ
トコルの一般的パケットの形状を説明する図である。

【００９５】ＳＰサーバー装置／クライアントプロトコ
ルの一般的パケットの形状は、図５に示す通りであり、
太い線で囲んだ部分の左側の数字はバイト数である。

【００９６】図において、ｐａｃｋｅｔ＿ｉｄは、パケ
ットのＩＤコードを示し、ｓｏｕｒｃｅ＿ｉｄは、パケ
ットがどこからきたのかを示すコードを示し、ｐｋ＿ｓ
ｉｚｅは、パケット全体の長さ（バイト数）を示し、ｃ
ｏｎｔｅｎｔｓは文字通り、送るべき情報の中身であ
る。 〈コンテンツ（ｃｏｎｔｅｎｔｓ）〉上記Ｓ／Ｐパケッ
トのコンテンツの部分はさらに、ｓｕｂ＿ｃｏｍｍａｎ
ｄ＿ｉｄ，ｌｅｎｇｔｈ，ｃｏｎｔｅｎｔの３つの要素
が繰り返しで構成される。これが１セットで１つの意味
を表現します。

【００９７】特に、ｓｕｂ＿ｃｏｍｍａｎｄ＿ｉｄはサ
ブコマンドコードで、これが受信側に対する特定のサブ
コマンドを示し、ｌｅｎｇｔｈは引き続くｃｏｎｔｅｎ
ｔの長さ（バイト）を示す。なお、ｃｏｎｔｅｎｔは、
ｓｕｂ＿ｃｏｍｍａｎｄ＿ｉｄの付加情報を伝えるのに
用い、ファイル名とかのテキストストリングのような、
１バイトに収まり切れない情報が入る。 〈各パケットの機能〉以下、各パケットの機能について
説明する。 ＜ＬＥＶＥＬ＿１パケット＞ＬＥＶＥＬ＿１パケットに
は、ＬＥＶＥＬ＿１プロトコル接続要求を意味するＬ＿
Ｌｉｎｋパケット，ＬＥＶＥＬ＿１プロトコル接続確認
を意味するＬ＿Ｌｉｎｋ＿ａｃｋパケット，ＬＥＶＥＬ
＿１プロトコル切断を意味するＬ＿ｒｅｌｅａｓｅパケ
ット，ＬＥＶＥＬ＿１プロトコル切断確認を意味するＬ
＿ｒｅｌｅａｓｅ＿ａｃｋパケット，状態確認要求を意
味するＬ＿ｓｔａｔｕｓパケット，状態確認応答を意味
するＬ＿ｓｔａｔｕｓ＿ａｃｋパケット，Ｓｅｖｅｒ制
御要求を意味するＬ＿ｃｏｎｔｒｏｌパケット，Ｓｅｖ
ｅｒ制御確認を意味するＬ＿ｃｏｎｔｒｏｌ＿ａｃｋパ
ケット，強制切断要求を意味するＬ＿ａｂｏｒｔパケッ
ト，強制切断確認を意味するＬａｂｏｒｔ＿ａｃｋ等の
パケットがある。 ＜ＬＥＶＥＬ＿２パケット＞ＬＥＶＥＬ＿２パケットに
は、Ｌ＿ｏｐｅｎ，Ｌ＿ｏｐｅｎ＿ａｃｋ，Ｌ＿ｃｌｏ
ｓｅ，Ｌ＿ｃｌｏｓｅ＿ａｃｋ，Ｌ＿ｉｎｉｔ，Ｌ＿ｉ
ｎｉｔ＿ａｃｋ，Ｌ＿ｓｔａｒｔ，Ｌ＿ｓｔａｒｔ＿ａ
ｃｋ，Ｌ＿ｅｎｄ，Ｌ＿ｅｎｄ＿ａｃｋ，Ｌ＿ｄａｔ
ａ，Ｌ＿ｄａｔａ＿ａｃｋ，Ｌ＿ｐｒｏｇｒｅｓｓ，Ｌ
＿ｐｒｏｇｒｅｓｓ＿ａｃｋ，Ｌ＿ｃａｐａｂｉｌｉｔ
ｙ，Ｌ＿ｃａｐａｂｉｌｉｔｙ＿ａｃｋ，Ｌ＿ｃａｎｃ
ｅｌ，Ｌ＿ｃａｎｓｅｌ＿ａｃｋ等の各種のパケットＩ
Ｄが定義可能に構成されている。以下、図９〜図２５等
のを照しながら各パケットの内容について説明する。

【００９８】上記パケットＩＤとしてのＬ＿ｏｐｅｎ
は、サーバー／クライアント間でリンクを張り、その後
のサービス（印刷／スキャン）の接続を確保するための
オープン要求するパケットに対応し、パケット定義例を
図９に示す。

【００９９】図９に示す、ｐａｃｋｅｔ＿ｔｙｐｅには
ＬＥＶＥＬ＿２を、ｐａｃｋｅｔ＿ＩＤにはＨ＿ｏｐｅ
ｎをセットする。その他のヘッダパラメータのセットの
仕方は後述する。

【０１００】また、ｍｏｄｉｆｉｅｒのパラメータにｍ
＿ｐｒｉｎｔ（印刷），ｍ＿ｓｃａｎ（スキャン），ｍ
＿ＦＴＡＭ（ファイル転送）のいずれかでジョブ指定す
ることによって、その後のシーケンスが「印刷」なのか
「スキャン」なのかが決まる。

【０１０１】さらに、ｈｏｓｔ＿ｎａｍｅとｕｓｅｒ＿
ＩＤには、それぞれクライアント側のホスト名とユーザ
ＩＤをセットする。これらはともにＣストリングであ
り、ＮＵＬＬターミネータを必要とする。３２バイトと
いうのは、ターミネータを含んだ長さである。将来サー
バー装置側で利用者に限定する時にこのパラメータを参
照するためである。

【０１０２】上記パケットＩＤとしてのＬ＿ｏｐｅｎ＿
ａｃｋは、サービス（印刷／スキャン）の接続を確認す
るためのパケットに対応し、パケット定義例を図１０に
示す。

【０１０３】当該確認の結果がＯＫならｍｏｄｉｆｉｅ
ｒにＮｏＥｒｒｏｒを返します。

【０１０４】一方、何等かの障害により、要求されたサ
ービスを提供できない場合には、ｍｏｄｉｆｉｅｒのエ
ラーフラグを「１」にセットし、ｅｒｒｏｒにエラーコ
ードを書き、ｍｓｇで障害の理由を送る。

【０１０５】なお、ｅｒｒｏｒとｍｓｇは、デバイスリ
ストｄｅｖ１−ｄｅｖ６と同じ部分が共用される。

【０１０６】また、図１０に示すホスト名にはサーバー
装置のホスト名、ユーザＩＤにはサーバー装置のユーザ
ＩＤを返す。通常、サーバー装置のユーザＩＤはｒｏｏ
ｔです。同一ネットワーク上にサーバー装置が複数存在
するようなシステムを構築する時に、このパラメータを
使う。

【０１０７】さらに、図１０に示すファイル名には、サ
ーバー装置が内部でキューにセーブするファイル名を返
します。クライアントがこのファイル名を指定してキュ
ーのクリア等を行う。メモリ受信の場合は何もセットさ
れない場合がある。

【０１０８】サーバー装置に接続されるスキャナ／プリ
ンタは、いつ、どんな物が接続されるか分からないし、
電源が入っているかも分からないので、クライアントは
印刷／スキャンの都度サーバー装置に問い合わせる。

【０１０９】その結果が使用可能デバイスリストで返さ
れるので、Ｌ＿ｉｎｉｔでひとつを選んで接続を要求し
ます。ｄｅｖ１からｄｅｖ６には、クライアント／サー
バー装置間で識別可能なデバイスのコード（最大４バイ
ト）が、ｄｅｖ＿ｉｎｆｏ１からｄｅｂ＿ｉｎｆｏ６に
は、クライアントで表示可能な製品名（最大１５バイト
＋ＮＵＬＬ）が入る。

【０１１０】例えばｄｅｖ＝”ＣＬＣ５”，ｄｅｖ＿ｉ
ｎｆｏｌ＝”ＰＩＸＥＬＤＵＯ（商品名）”，ｄｅｖ
＝”ＣＬＣ３”，ｄｅｖ＿ｉｎｆｏｌ＝”ＰＩＸＥＬＥ
ＰＯ（商品名）”，ｄｅｖ＝”ＣＪ１０”，ｄｅｖ＿ｉ
ｎｆｏｌ＝”ＰＩＸＥＬＪＥＴ（商品名）”等である。

【０１１１】なお、通常はデフォルト値のままでよい
が、１台のサーバーに同じ形式のデバイスが複数台接続
されている場合には、Ｎａｍｅプロトコルにより、ｄｅ
ｖ＿ｉｎｆｏを変更する必要がある。そこで、クライア
ントとサーバー間で、サービスを開始し、デバイスリス
トをクライアントに提示して、クライアントからデバイ
スを指定させ、指定されたデバイスの指定を確認し、サ
ービスを終了することにより、サーバーば指定されたデ
バイス名を、デフォルトデバイス名として記憶する。

【０１１２】上記パケットＩＤとしてのＬ＿ｃｌｏｓｅ
は、サービス（印刷／スキャン）の終了を要求する場合
のパケットに対応し、上記パケットＩＤとしてのＬ＿ｃ
ｌｏｓｅ＿ａｃｋは、サービス（印刷／スキャン）の終
了の確認するパケットに対応する。

【０１１３】上記パケットＩＤとしてのＬ＿ｉｎｉｔ
は、サーバー初期化要求に対応するパケットであり、パ
ケット定義例を図１１に示し、該Ｌ＿ｉｎｉｔにサブコ
マンド例を図１２，図１３に示す。

【０１１４】図１１に示すようにクライアントは、Ｌ＿
ｉｎｉｔでサーバー装置／デバイスの機能を選択しま
す。サーバー装置は、ここで指定されたパラメータを記
憶しておく。なお、該パケット自体がオプションなの
で、これを送らずに印刷／スキャンも可能となる。

【０１１５】しかし、その場合、パケットＩＤとしての
Ｌ＿ｃａｐａｂｉｌｉｔｙで現在セットされているパラ
メータが何であるかを調べてから実行する方が望まし
い。

【０１１６】なお、パラメータの大部分が〔オプショ
ン〕指定になっているのは、Ｌ＿ｉｎｉｔの使い方の自
由度を増すためである。例えば、Ｌ＿ｉｎｉｔのパラメ
ータは何回かに分けて送ってもよいので、解像度のみを
変更しその他のパラメータは現在セットされている値を
そのまま使う場合には、ＲＥＳＯＬＵＴＩＯＮだけをセ
ットし、それ以外のパラメータはセットせずに送る。

【０１１７】その場合のＬ＿ｉｎｉｔのパケットサイズ
は、非常に小さくなります。パケットサイズが可変なの
は、Ｌ＿ｉｎｉｔとＬ＿ｄａｔａのみである。なお、サ
ンプルプログラムは可変になっていないので、例えば解
像度のみを変更する場合には、その他のパラメータには
ＮＵＬＬをセットする必要がある。

【０１１８】さらに、パケットＩＤとしての上記Ｌ＿ｉ
ｎｉｔ＿ａｃｋはサーバー初期化確認用のパケットに対
応し、Ｌ＿ｓｔａｒｔはサービス（印刷／スキャン等）
実行開始要求のパケットに対応し、Ｌ＿ｓｔａｒｔ＿ａ
ｃｋは（印刷／スキャン等）実行開始応答のパケットに
対応し、Ｌ＿ｅｎｄは（印刷／スキャン等）終了要求の
パケットに対応し、Ｌ＿ｅｎｄ＿ａｃｋは終了確認のパ
ケットに対応し、Ｌ＿ｄａｔａはデータパケットに対応
し、Ｌ＿ｄａｔａ＿ａｃｋはデータ送達確認のパケット
に対応する。

【０１１９】また、パケットＩＤとしての上記Ｌ＿ｐｒ
ｏｇｒｅｓｓはサーバー／クライアントの状態を問い合
わせるパケットに対応し、ｐａｋｅｔ＿ｔｙｐｅはＬ＿
ｐｒｏｇｒｅｓｓで、ｍｏｄｉｆｉｅｒはＮＵＬＬであ
る。また、ｃｏｍｍａｎｄは、サーバー状態を調べるＳ
ＥＲＶＥＲ，クライアントの状態を調べるＣＬＩＥＮ
Ｔ，スキャナ／プリンタの状態を調べるＤＥＶＩＣＥ，
クライアント側のホストコンピュータの状態を調べるＨ
ＯＳＴ，スプーラの状態を調べるＳＰＰＬＥＲ，ネット
ワークの状態を調べるＮＥＴＷＯＲＫ，第２のサーバー
の状態を調べるＲＯＵＴＥ，サーバー／クライアントの
状態を調べるＮＵＬＬ等のオプションコマンドを有し、
これらの機能をサポートしないサーバーは、ＳＥＲＶＥ
Ｒコマンドの受信と同じ動作をし、これらのコマンド要
求オプションが設定されていた場合には、正しくそのサ
ービスを実行するか、さもなければエラーを返す。な
お、ｏｂｊｅＰＲＩＮＴＥＲ，ＳＣＡＮＮＥＲ，ＤＩＳ
Ｋ，ＳＥＲＶＥＲで、ｄｉｒｅｃｔｉｏｎの種類は、印
刷，ファイル書込み，ループバック等のためのＣＬＩＥ
ＮＴ＿ＴＯＳＥＲＶＥＲと、スキャン，ファイル読み込
み等のためのＳＥＶＥＲ＿ＴＯ＿ＣＬＩＥＮＴである。

【０１２０】さらに、パケットＩＤとしての上記Ｌ＿ｐ
ｒｉｇｒｅｓｓ＿ａｃｋはＬ＿ｐｒｉｇｒｅｓｓｎｉ対
する返事に対応し、Ｌ＿ｃａｐａｂｉｌｉｔｙは機能リ
スト要求に対応し、Ｌ＿ｃａｐａｂｉｌｉｔｙ＿ａｃｋ
はデバイスの有する能力を示すパラメータリストの回答
のための機能リスト応答に対応する。その応答例を図１
４に示し、そのサブコマンドの内容を図１７〜図１８に
示す。

【０１２１】また、パケットＩＤとしての上記Ｌ＿ｃａ
ｎｃｅｌは、キャンセル要求のためのパケットに対応
し、Ｌ＿ｃａｎｃｅｌ＿ａｃｋはキャンセル確認のため
のパケットに対応する。 〈Ｓ／Ｐプロトコル〉図１９は本発明に係るスキャナプ
リンタサーバー装置における基本シーケンス一例を示す
プロトコルを説明する図である。

【０１２２】サーバー装置／クライアント間でのパケッ
トのやり取りは、図１９に示すように通常１対１で対応
しており、サーバー装置からコマンドパケットを発行す
れば、必ずＡｃｋパケットが返ってくるのを基本として
いる。この基本から外れる動作をするパケットは、Ｌ＿
ａｂｏｒｔ，Ｌ＿ａｂｏｒｔ＿ａｃｋで、Ｌ＿ａｂｏｒ
ｔは、動作がおかしくなった時に発行されるパケットな
ので、いつでも発行され得る。

【０１２３】図２０，図２１は本発明に係るスキャナプ
リンタサーバー装置における初期化処理の一例を示すプ
ロトコルを説明する図である。

【０１２４】Ｓ／Ｐサーバー装置の初期化は、図２０に
示すように、最短コースでは、Ｏｐｅｎとｉｎｉｔパケ
ットのやり取りで完了する。

【０１２５】また、ｉｎｉｔの要求に対して、サーバー
装置側の機能が欠けている場合、その返事ｉｎｉｔ＿ａ
ｃｋにエラーが含まれて返される。その場合、ｃａｐａ
ｂｉｌｉｔｙパケットによってサーバー装置側の能力を
調べ、パラメータを変更の後、再度ｉｎｉｔを発行して
初期化を行う。今度は、相手の能力に合った要求を出し
たので、ｉｎｉｔ＿ａｃｋはエラーとなることはなくな
る。

【０１２６】コンピュータ側から印刷する場合の代表的
な処理手順における〈ネットワークの設定〉，〈印刷〉
は以下のようになる。 〈ネットワークの設定〉（１）で、コントロールパネル
のネットワークアイコンを選択し、「ＰｒｉｎｔＴＣＰ
ダイアログ」を表示させる。（２−１）で、ＴＣＰ／Ｉ
Ｐ上のプリンタのホスト名（または、ＩＰアドレス）を
設定する。次いで、（２−２）で、印刷／（スキャン）
サービスのポート番号の設定する。次いで、（２−３）
で、デバイス（スキャナ／プリンタ）の選択する。次い
で、（２−４）で、リトライタイマ値（Ｔ１）と、タイ
ムアウトタイマ値（Ｔ２）の設定を行い、（２−５）で
「ＯＫ」をクリックする。

【０１２７】図２２は本発明に係るスキャナプリンタサ
ーバー装置におけるネゴシエーション処理におけるデバ
イス選択処理に対応するプロトコルを説明する図であ
る。

【０１２８】この図に示すように、上記（２−３）での
デバイス（スキャナ／プリンタ）の選択は、実際にＴＣ
Ｐ／ＩＰのリンクを張って、サーバー装置に何が接続さ
れているかを調べた上で、ダイアログに表示する。
（３）で「ＰｒｉｎｔＴＣＰダイアログ」が消える。 〈印刷〉（４）で、「印刷」メニューの選択し、（５）
でプリンタドライバが「Ｐｒｉｎｔｅｒ Ｄｒａｉｖｅ
ｒ Ｄｅｖｉｃｅ Ｍｏｄｅ］のダイアログを表示す
る。

【０１２９】（６−１）で、印刷するページの範囲を指
定（デフォルトは全ページ）し、（６−２）で、１ペー
ジ当りの印刷枚数を設定（デフォルトは１枚／頁）し、
（６−３）で、用紙サイズの選択（デフォルトはレター
サイズ）し、（６−４）で、用紙方向の選択（デフォル
トはポートレイト）し、（６−５）で、解像度の選択
（デフォルトは４００ｄｐｉ）する。

【０１３０】そして、（６−６）で、色指定（デフォル
トはＲＧＢ）し、（６−７）で、ページ記述言語の選択
（デフォルトはＣａＰＳＬ）し、（６−８）でプリンタ
の選択する。

【０１３１】この中で、解像度に４００ｄｐｉの選択メ
ニューがない場合には、ＨｉｇｈＲｅｓｏｌｕｔｉｏｎ
の３６０ｄｐｉを選択し、プリンタの選択はやる必要が
ないので、例えば「Ｐ６９２」を選択しておく。

【０１３２】これらの設定値は（Ｗｉｎｄｏｗｓの場
合）ＷＩＮ．ＩＮＩファイルにセーブされる。将来は、
プリンタドライバとネットワークドライバが、直接通信
するようになると思われるが、現在はＷｉｎｄｏｗｓの
ＰｒｉｎｔｅｒＤｒｉｖｅｒが介在するため、これらの
パラメータをネットワークドライバに直接渡す方法は無
いのではないかと思われる。

【０１３３】そのため、ネットワークドライバはＷＩ
Ｎ．ＩＮＩファイルを自分で見に行くか、さもなければ
デフォルト値を決め打ちでセットすることなる。

【０１３４】図２３は本発明に係るスキャナプリンタサ
ーバー装置における印刷の正常通信シーケンスを示すプ
ロトコルを説明する図である。

【０１３５】図２４は本発明に係るスキャナプリンタサ
ーバー装置における印刷機能のネゴシエーション処理を
示すプロトコルを説明する図である。

【０１３６】以下、本発明に係るスキャナプリンタサー
バー装置における状態遷移について説明する。 〈状態遷移〉Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒプロトコル
は、通信中に、以下、ＤＭ（Ｄｉｓｃｏｎｎｅｃｔ Ｍ
ｏｄｅ），ＣＭ（Ｃｏｎｎｅｃｔ Ｍｏｄｅ），ＳＭ
（Ｓｅｒｖｉｃｅ Ｍｏｄｅ），ＴＭ（Ｔｒａｎｓｍｉ
ｓｓｉｏｎ Ｍｏｄｅ）の４つの動作状態のいずれかを
取り得る。

【０１３７】先ず、ＤＭ（Ｄｉｓｃｏｎｎｅｃｔ Ｍｏ
ｄｅ）状態は、電源を入れた直後の状態で、ＴＣＰ／Ｉ
Ｐのリンクが切り放されている状態をいう。ＣＭ（Ｃｏ
ｎｎｅｃｔ Ｍｏｄｅ）状態は、サーバー装置とクライ
アントとの間でＴＣＰ／ＩＰのリンクが張られ、いつで
も通信可能な状態にある。

【０１３８】ＳＭ（Ｓｅｒｖｉｃｅ Ｍｏｄｅ）状態
は、サーバー装置とクライアントとの間で具体的な通信
サービス（例えば「印刷サービス」）を開始した状態を
いう。ＴＭ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｍｏｄｅ）状
態は、データが転送されている状態をいう。

【０１３９】ＳＰサーバー装置／クライアントプロトコ
ルには、ＬＥＶＥＬ＿１パケット群とＬＥＶＥＬ＿２パ
ケット群とがあり、ＬＥＶＥＬ＿１は、ＯＳＩのセッシ
ョンレイヤに相当するレイヤで、ＬＥＶＥＬ＿２は、Ｏ
ＳＩのドキュメントレイヤに相当するレイヤである。

【０１４０】これらのパケットの内で、特定のパケット
を送受信した時に、上記のモードが変わ。例えばＨＬ＿
ｌｉｎｋ／ＨＬ＿ｌｉｎｋ＿ａｃｋは、ＤＭからＣＭに
モードが変わり、ＨＬ＿ｒｅｌｅａｓｅ／ＨＬ＿ｒｅｌ
ｅａｓｅ＿ａｃｋはＣＭからＤＭにモードが変わり、Ｈ
Ｌ＿ｏｐｅｎ／ＨＬ＿ｏｐｅｎ＿ａｃｋは、ＣＭからＳ
Ｍにモードが変わり、ＨＬ＿Ｃｌｏｓｅ／ＨＬ＿Ｃｌｏ
ｓｅ＿ａｃｋはＳＭからＣＭにモードが変わる。 〈ＤＭ状態〉以下、サーバー装置側の動作を中心にＤＭ
状態について説明します。

【０１４１】図８に示したように、サーバー装置の基本
シーケンスの状態は遷移するが、サーバー装置は電源Ｏ
Ｎ後、〈ＤＭ〉の状態で着信信号を待ち続ける。そし
て、クライアントがＴＣＰ／ＩＰのリンクを張り、クラ
イアントからＨＬ＿Ｌｉｎｋパケットが到着すると、サ
ーバー装置はＨＬ＿ｌｉｎｋ＿ａｃｋを返すと共に〈Ｃ
Ｍ〉の状態に移行する。 〈ＣＭ状態〉図２５は本発明に係るスキャナプリンタサ
ーバー装置におけるサーバー−クライアント間のシーケ
ンスの一例を示すプロトコルを説明する図である。

【０１４２】本実施例のるスキャナプリンタサーバー装
置においては、ＣＭ状態において、Ｌｅｖｅｌ＿１のパ
ケットの全てがやり取りできるようになる。

【０１４３】例えば図２５に示すようにクライアントか
らＨＬ＿ｓｔａｓｕｓパケットを受信したら、ＨＬ＿ｓ
ｔａｔｕｓ＿ａｃｋパケットにサーバー装置の現在の状
態を乗せて送り返します。また、ＨＬ＿ｐｉｎｇパケッ
トを受信したら、全く同じデータを乗せて、ＨＬ＿ｐｉ
ｎｇ＿ａｃｋパケットを返す。

【０１４４】この状態でＨＬ＿ｒｅｌｅａｓｅパケット
を受信すれば、サーバー装置は結局なんのサービスもせ
ずにＴＣＰ／ＩＰの接続を切ることになる。これは、サ
ーバー装置に何もさせずにサーバー装置の状態だけを調
べる時に利用できます。

【０１４５】通常は、ネットワーク印刷かネットワーク
スキャンを行うので、クライアントからＨＬ＿ｏｐｅｎ
パケットが送られてきます。印刷かスキャンかの切り分
けはＨＬ＿ｏｐｅｎパケットのｍｏｄｉｆｉｅｒバイト
にｍ＿ｐｒｉｎｔかｍ＿ｓｃａｎが書かれているのをチ
ェックして行う。印刷の場合には、図の左の矢印を上っ
て〈ＳＭ状態〉に移行する。 〈ＳＭ状態〉このＳＭ状態から上で、Ｌｅｖｅｌ＿２の
パケットが全て使用できます（ただし、Ｌｅｖｅｌ＿１
のパケットも来る場合がある。その場合は、Ｌｅｖｅｌ
＿１のパケットが優先する）。

【０１４６】また、ＨＬ＿ｏｐｅｎパケットによって、
送信されるファイル名とウインドサイズが知らされる。
これはクライアントからの要求であって、サーバー装置
はそれを使う義務はない。サーバー装置側で（もしファ
イルにセーブする場合には）実際にセーブに使われるフ
ァイル名は、ＨＬ＿ｏｐｅｎ＿ａｃｋの中に記載されて
クライアントに知らされる。

【０１４７】ウインドサイズは、サーバー装置がＨＬ＿
ｏｐｅｎで要求されたサイズをサポートしていれば、必
ずＨＬ＿ｏｐｅｎ＿ａｃｋの中でそのサイズでデータを
やり取りする旨を示す必要がある。

【０１４８】もし、サポートしていない時は、要求され
たサイズよりも小さいウインドサイズを使うことを宣言
する必要がある。この状態でもしクライアントからＨＬ
＿ｃｌｏｓｅパケットを受信すれば、サーバー装置は受
信バッファファイルをクローズして、ＨＬ＿ｃｌｏｓｅ
＿ａｃｋを返し、直ちに〈ＣＭ〉に戻る。これは、オペ
レータが印刷を開始前にキャンセルした場合に起こる。

【０１４９】もしキャンセルされずに、印刷開始の「Ｏ
Ｋ」ボタンがクリックされた場合には、クライアントは
サーバー装置を初期化しようとしてＨＬ＿ｉｎｉｔパケ
ットを発行する。ここでは、プリンタの選択，ページ記
述言語の選択，用紙サイズの選択，用紙の送り方向の選
択，解像度の選、，色空間の選択等が行われる。

【０１５０】なお、ＨＬ＿ｉｎｉｔはオプションであ
り、サーバー装置のデフォルト値で構わない場合には省
略可能である。また、ページ記述言語の中で十分な情報
が送れる場合にも省略可能である。ＨＬ＿ｉｎｉｔで受
け取った数値はクライアントからの要求であり、サーバ
ー装置がこの要求に応えられない場合には、適当なデフ
ォルト値がセットされてＨＬ＿ｉｎｉｔ＿ａｃｋが返さ
れる。ＨＬ＿ｉｎｉｔでは、状態の変化はない。クライ
アントの要求に１つでも応えられない項目があった時
は、サーバー装置はＨＬ＿ｉｎｉｔ＿ａｃｋのｍｏｄｉ
ｆｉｅｒバイトをｍ＿ｆａｉｌにして返す。クライアン
トは、ｍ＿ｆａｉｌの乗ったＨＬ＿ｉｎｉｔ＿ａｃｋの
設定値に満足できれば、ＨＬ＿ｉｎｉｔによるネゴシエ
ーションを終了して、データ転送を開始しても良い。

【０１５１】もし、満足できない時は、値を変えて再度
ＨＬ＿ｉｎｉｔを発行するか、ＨＬ＿ｃａｐａｂｉｌｉ
ｔｙパケットによって具体的にサーバー装置がサポート
する機能を調べることができます。ＨＬ＿ｃａｐａｂｉ
ｌｉｔｙでも状態の変化はない。

【０１５２】なお、本実施例において、ＨＬ＿ｉｎｉｔ
とＨＬ＿ｃａｐａｂｉｌｉｔｙは、何回でも受け付ける
が、最後に受信したＨＬ＿ｉｎｉｔが有効となる。

【０１５３】また、ＨＬ＿ｉｎｉｔによるネゴシエーシ
ョンに満足できれば、クライアントはＨＬ＿ｓｔａｒｔ
パケットを発行してデータ転送を開始しようとする。サ
ーバー装置はＨＬ＿ｓｔａｒｔ＿ａｃｋを返して〈ＴＭ
状態〉に移行する。 〈ＴＭ状態〉ＨＬ＿ｓｔａｒｔとＨＬ＿ｅｎｄは、互い
に対になって用いられるパケットで、印刷の開始と終了
を意味します。印刷すべきデータ（ジョブ）がクライア
ントのキューに沢山たまっている時は、わざわざＴＣＰ
／ＩＰの接続を切る必要はなく、ＨＬ＿ｅｎｄの後ただ
ちに次のＨＬ＿ｓｔａｒｔを続けても良い。

【０１５４】これができるのは、データが単なるＡＳＣ
IIキャラクタで構成されている場合で、かつ、ＨＬ＿ｉ
ｎｉｔの再度ネゴが不用な場合に限られ、通常は〈Ｃ
Ｍ〉まで下りてからＨＬ＿ｏｐｅｎをやり直す。

【０１５５】印刷時とスキャン時とでは、データの流れ
る方向が逆になる。データの送信側がＨＬ＿ｄａｔａパ
ケットを発行し、受信側がＨＬ＿ｄａｔａ＿ａｃｋパケ
ットを返す。

【０１５６】上記実施例によれば、通信プロトコルを改
良し、１個のプリンタドライバからサーバー装置に接続
された任意のプリンタ／スキャナにアクセスできるよう
にした。すなわち、選択されたサーバー装置と実際に通
信を試みて、そこに接続されているプリンタの種類と状
態をクライアント側から把握することにより、容易に所
定のプリンタを選択可能となった。

【０１５７】データをパケット化し、全てのパケットに
制御用のヘッダ情報を付加し、パケットを受け取った側
で再びデータと制御情報に分離できるようにした。これ
によって制御情報が別々に正確に送れるようになった。

【０１５８】データの伝送に先立って、クライアントか
らサーバー装置に対し、どのようなデバイス（スキャナ
／プリンタ）が利用可能か問い合わせるシーケンスを用
意した。これによってクライアント側からデバイスの選
択ができるようになった。

【０１５９】また、それぞれのデバイスの特性や能力を
問い合わせるシーケンスも用意した。これによってプリ
ンタの能力（紙サイズ等）に合わせて、アプリケーショ
ン側でデータを整えて送ることができるようになった。

【０１６０】また、印刷やスキャンの途中で処理を中断
させたり、進捗状況を問い合わせたりできるようにし
た。これによって、時間のかかる複雑な原稿の印刷等を
行って処理を待っている場合、さらに待つべきなのか中
断すべきなのかの判断が正しくできるようになった。

【０１６１】次に、上記プリンタドライバのＡＰＩ（ア
プリケーションプログラムインタフェース）を改良し
て、アプリケーションからサーバー装置／プリンタの選
択情報をもらえた時には、その情報を元に通信を試み、
該情報がもらえない場合にはプリンタドライバ自身がダ
イアログ等を表示してユーザにデバイスの選択を可能な
らしめた。

【０１６２】

【発明の効果】以上説明したように、本発明に係る第１
の発明によれば、アプリケーションから入出力要求に応
じて前記クライアントマシンが前記サーバー装置に発行
する所定のパケットに対する応答パケットの発行状態を
所定時間監視し、所定時間内に前記応答パケットが前記
サーバー装置より発行されない場合に、アプリケーショ
ンに対して前記サーバー装置の異常状態を応答するの
で、アプリケーション側にサーバー装置とクライアント
マシン間における通信異常有無を通知して、アプリケー
ションのデッドロック状態が発生しないようにすること
ができる。

【０１６３】第２の発明によれば、クライアントマシン
は、サーバー装置からの応答パケット発行状態をタイマ
により所定時間監視するので、サーバー装置とクライア
ントマシン間における通信異常有無を判別することがで
きる。

【０１６４】第３の発明によれば、クライアントマシン
は、アプリケーションに対して前記サーバー装置の異常
状態を応答後、サーバー装置に対して異常状態を回復さ
せるための所定のパケットを発行するので、クライアン
トマシンがサーバー装置に対してい正常通信状態への移
行を催促することができる。

【０１６５】第４の発明によれば、クライアントマシン
は、アプリケーションに対して前記サーバー装置の異常
状態を応答後、サーバー装置に対して異常状態を回復さ
せるため異常発生前に発行した同一のパケットを所定数
回発行するので、異常発生前のパケット通信を正常に再
開することができる。

【０１６６】第５の発明によれば、アプリケーション
は、クライアントマシンからの異常状態応答に応じてク
ライアントマシンに対してサーバー装置の異常回復を要
求するので、アプリケーション側からクライアントマシ
ンに対してサーバー装置との正常な通信状態に復帰する
ために必要な所定の回復処理の起動を催促することがで
きる。

【０１６７】第６の発明によれば、クライアントマシン
は、サーバー装置から正常な応答パケットが発行された
場合に、アプリケーションに対して正常応答を通知する
ので、サーバー装置との通信異常で中断していた入出力
処理を正常に再開することができる。

【０１６８】従って、アプリケーションのデッドロック
状態を確実に防止できるとともに、アプリケーションか
らの入出力要求を正常に行える通信環境に復帰できる等
の効果を奏する。

【図面の簡単な説明】

【図１】本発明の一実施例を示すスキャナプリンタサー
バーシステムの構成を説明するブロック図である。

【図２】本発明に係るスキャナプリンタサーバーシステ
ムにおけるプリンタ処理手順の一例を示すコマンドのシ
ーケンスダイヤグラムである。

【図３】本発明に係るスキャナプリンタサーバーシステ
ムにおけるスキャン処理手順の一例を示すコマンドのシ
ーケンスダイヤグラムである。

【図４】本発明に係るスキャナプリンタサーバー装置の
第１のデータ通信制御方法の一実施例を示すフローチャ
ートである。

【図５】本発明に係るスキャナプリンタサーバー装置の
第２のデータ通信制御方法の一実施例を示すフローチャ
ートである。

【図６】本発明に係るスキャナプリンタサーバー装置の
第３のデータ通信制御方法の一実施例を示すフローチャ
ートである。

【図７】本発明に係るスキャナプリンタサーバー装置に
おけるクライアントとサーバーとの間の通信プロトコル
の詳細を説明する概念図である。

【図８】本発明に係るスキャナプリンタサーバー装置に
おけるＳＰサーバー装置／クライアントプロトコルの一
般的パケットの形状を説明する図である。

【図９】本発明に係るスキャナプリンタサーバー装置に
おけるパケット定義例を示す図である。

【図１０】本発明に係るスキャナプリンタサーバー装置
におけるパケット定義例を示す図である。

【図１１】本発明に係るスキャナプリンタサーバー装置
におけるパケット定義例を示す図である。

【図１２】図１１に示したパケット定義例におけるサブ
コマンドの内容を説明する図である。

【図１３】図１１に示したパケット定義例におけるサブ
コマンドの内容を説明する図である。

【図１４】本発明に係るスキャナプリンタサーバー装置
におけるパケット定義例を示す図である。

【図１５】図１４に示したパケット定義例におけるサブ
コマンドの内容を説明する図である。

【図１６】図１４に示したパケット定義例におけるサブ
コマンドの内容を説明する図である。

【図１７】図１４に示したパケット定義例におけるサブ
コマンドの内容を説明する図である。

【図１８】図１４に示したパケット定義例におけるサブ
コマンドの内容を説明する図である。

【図１９】本発明に係るスキャナプリンタサーバー装置
における基本シーケンス一例を示すプロトコルを説明す
る図である。

【図２０】本発明に係るスキャナプリンタサーバー装置
における初期化処理の一例を示すプロトコルを説明する
図である。

【図２１】本発明に係るスキャナプリンタサーバー装置
における初期化処理の一例を示すプロトコルを説明する
図である。

【図２２】本発明に係るスキャナプリンタサーバー装置
におけるネゴシエーション処理におけるデバイス選択処
理に対応するプロトコルを説明する図である。

【図２３】本発明に係るスキャナプリンタサーバー装置
における印刷の正常通信シーケンスを示すプロトコルを
説明する図である。

【図２４】本発明に係るスキャナプリンタサーバー装置
における印刷機能のネゴシエーション処理を示すプロト
コルを説明する図である。

【図２５】本発明に係るスキャナプリンタサーバー装置
におけるサーバー−クライアント間のシーケンスの一例
を示すプロトコルを説明する図である。

【符号の説明】

１ クライアントコンピュータ ２ クライアントコンピュータ ３ クライアントコンピュータ ４ クライアントコンピュータ ５ ローカルエリアネットワーク（ＬＡＮ） ６ カラーＳＰサーバー装置 ７ プリンタＡ ８ プリンタＢ ９ スキャナＣ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 戸田 ゆかり 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 齋藤 和浩 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 宍塚 順一 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 山田 修 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 福田 康男 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 杉山 光正 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 高岡 真琴 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 三田 良信 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 (72)発明者 杉浦 進 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内

Claims (6)

【特許請求の範囲】
1. 【請求項１】 ネットワーク上に複数のクライアントマ
   シンとスキャナ／プリンタサーバー装置とがパケット通
   信可能に構成され、前記スキャナ／プリンタサーバー装
   置に接続された複数の入出力デバイスを各クライアント
   マシンのアプリケーションが入出力要求を発行して画像
   入出力処理を行うスキャナプリンタサーバーシステムの
   データ通信制御方法において、アプリケーションから入
   出力要求に応じて前記クライアントマシンが前記サーバ
   ー装置に発行する所定のパケットに対する応答パケット
   の発行状態を所定時間監視する監視工程と、この監視工
   程により前記所定時間内に前記応答パケットが前記サー
   バー装置より発行されない場合に、前記アプリケーショ
   ンに対して前記サーバー装置の異常状態を応答する応答
   工程とを有することを特徴とするスキャナプリンタサー
   バーシステムのデータ通信制御方法。
2. 【請求項２】 クライアントマシンは、サーバー装置か
   らの応答パケット発行状態をタイマにより所定時間監視
   することを特徴とする請求項１記載のスキャナプリンタ
   サーバーシステムのデータ通信制御方法。
3. 【請求項３】 クライアントマシンは、応答工程後、サ
   ーバー装置に対して異常状態を回復させるための所定の
   パケットを発行する回復工程を有することを特徴とする
   請求項１記載のスキャナプリンタサーバーシステムのデ
   ータ通信制御方法。
4. 【請求項４】 クライアントマシンは、応答工程後、サ
   ーバー装置に対して異常状態を回復させるため異常発生
   前に発行した同一のパケットを所定数回発行する再送工
   程を有することを特徴とする請求項１記載のスキャナプ
   リンタサーバーシステムのデータ通信制御方法。
5. 【請求項５】 アプリケーションは、クライアントマシ
   ンからの異常状態応答に応じてクライアントマシンに対
   してサーバー装置の異常回復を要求する回復要求工程を
   有することを特徴とする請求項１記載のスキャナプリン
   タサーバーシステムのデータ通信制御方法。
6. 【請求項６】 クライアントマシンは、サーバー装置か
   ら正常な応答パケットが発行された場合に、アプリケー
   ションに対して正常応答を通知する通知工程とを有する
   ことを特徴とする請求項１記載のスキャナプリンタサー
   バーシステムのデータ通信制御方法。