JP3758020B2 - 制御処理開始認識プログラムを記録した媒体、制御処理開始認識システムおよび制御処理開始認識方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、周辺機器用に提供される所定のモジュールを起動するための制御処理開始認識プログラムを記録した媒体、制御処理開始認識システムおよび制御処理開始認識方法に関する。
【０００２】
【従来の技術】
プリンタ等コンピュータの周辺機器は、一般にはその周辺機器用のドライバが制御している。周辺機器のメーカーは通常その周辺機器にドライバを同梱し、利用者はドライバをコンピュータにインストールして周辺機器を使用する。ドライバは様々な態様で提供されており、各周辺機器メーカーが独自に作成して提供するものや、デバイスドライバキットとよばれるソフトウェアで作成して提供するものがある。このデバイスドライバキットでドライバを作成する際には周辺機器固有の処理のみを開発するだけでよく短期間での開発が可能であり、また、ユーザインタフェースがある程度標準的なものになるなどの利点がある。
【０００３】
【発明が解決しようとする課題】
上述した従来のデバイスドライバキットによるドライバにおいては、以下の問題があった。すなわち、このようなドライバでは上述のような利点があるものの、その汎用性によって個々の周辺機器に独自の機能に対応することが制限される。例えば周辺機器のステータスを監視するモジュールをドライバと連動させたいとしても、各周辺機器メーカーが独自に作成するのであればドライバを連動させる処理を作成して実現できるが、デバイスドライバキットでは限られた機能のみしか使用できず、実現できない。
【０００４】
本発明は、上記課題にかんがみてなされたもので、デバイスドライバキットで作成したドライバであっても種々の周辺機器用の個別機能に対応することが可能な制御処理開始認識プログラムを記録した媒体、制御処理開始認識システムおよび制御処理開始認識方法の提供を目的とする。
【０００５】
【課題を解決するための手段】
上記目的を達成するため、請求項１にかかる発明は、サーバとクライアントとを双方向通信可能に接続させ、クライアントにて所定の制御処理を開始したことを当該クライアントで認識するための制御処理開始認識プログラムを記録した媒体であって、上記サーバ側において、クライアントで実行される周辺機器ドライバであって、クライアントにおける周辺機器のステータス監視モジュールと連動する機能を備えていない周辺機器ドライバから上記双方向通信によってサーバに周辺機器の制御指示が与えられたことを検出する制御指示検出機能と、同制御指示検出機能がクライアントからの制御指示を検出したときに上記双方向通信によってクライアントに対して当該制御指示に基づく上記周辺機器の制御処理が開始されたことを通知する制御処理開始通知機能とを実現させ、上記クライアント側において、上記双方向通信によって上記制御処理開始通知機能による制御処理開始通知がなされたときに上記周辺機器の制御処理を開始したことを認識し、上記周辺機器のステータスを監視するためのステータス監視モジュールを起動する制御処理開始認識機能とを実現させる構成としてある。
【０００６】
上記のように構成した請求項１にかかる発明においては、サーバとクライアントとは双方向通信可能に接続されており、クライアントにて所定の制御処理を開始したことを当該クライアントで認識するようになっている。このため、サーバにおいては制御指示検出機能と制御処理開始通知機能とが実現されており、クライアントからサーバに所定の制御指示が与えられたことを検出し、当該クライアントに対して制御処理が開始されたことが通知される。クライアントにおいては、制御処理開始認識機能が実現されており、上記双方向通信によって制御処理開始通知を認識する。すなわち、クライアントにて種々の制御指示を与えたときに、当該クライアントはサーバからの通知によって制御処理の開始を認識するので、クライアントにて制御指示を与えるためのモジュール等になんら変更を加える必要がない。
【０００７】
このようにクライアントにて自己の制御指示を認識する場合に好適な構成の一例として、請求項２にかかる発明は、請求項１に記載の制御処理開始認識プログラムを記録した媒体であって、上記サーバは双方向通信を介して周辺機器を制御可能であり、同サーバ側において、上記制御指示検出機能では上記クライアントからの周辺機器の制御指示を検出したときに上記制御指示を与えたクライアントを特定するための情報を抽出可能であり、上記制御処理開始通知機能では上記抽出した情報に基づいて上記制御指示を与えたクライアントに対して上記抽出情報を出力し、上記クライアント側において、上記制御処理開始認識機能では上記出力される抽出情報を受信可能であり、同抽出情報に基づいて上記周辺機器の制御が開始されたことを認識する構成としてある。
【０００８】
上記のように構成した請求項２にかかる発明においては、サーバ側は双方向通信を介して周辺機器を制御可能であり、クライアント側では当該周辺機器に対する制御指示を与えることが可能である。ここで、サーバ側では制御指示検出機能においてクライアントを特定するための情報を抽出し、制御処理開始通知機能においては抽出情報に基づいて制御指示を与えたクライアントに対して当該抽出情報を出力して制御処理開始を通知するようになっている。周辺機器をドライバで制御する場合、汎用的なドライバ作成ツールによって提供されるような周辺機器ドライバや周辺機器メーカーが独自に提供する周辺機器ドライバなど、どのようなドライバであっても所定の処理を行うものである。そこで、サーバの周辺機器ドライバがこのような所定の処理を行ったことを検出することによって、周辺機器メーカー所望の処理を付加することができないドライバであってもクライアント側に制御処理開始を通知するための処理を開始することが可能になる。
【０００９】
また、サーバとクライアントとが双方向通信可能に接続される場合等には複数のクライアントが接続されていることが考えられるため、サーバの処理においては当該制御の開始を指示したクライアントを特定するための情報を抽出して出力する。この結果、クライアントでは自己からの制御指示によって上記周辺機器の制御が開始されたことが認識可能になる。すなわち、クライアントにおいても周辺機器の制御指示を与えるために周辺機器ドライバをインストールすることが考えられるが、このクライアントの周辺機器ドライバを上記汎用的なドライバ作成ツールによって提供する場合には、やはり所望の機能を付加するのは難しい。そこで、サーバから双方向通信によって上記抽出情報が送信されることをもって制御処理開始を認識するように構成した。従って、クライアントの周辺機器ドライバには全く変更を加えることなく、クライアントで制御処理開始が認識される。
【００１０】
また、サーバに制御される周辺機器は種々の態様のものを採用可能である。例えば、上記周辺機器と上記サーバとをネットワーク回線を介して双方向通信可能に接続し、当該周辺機器を周辺機器ドライバによってネットワーク回線を介して制御する構成が考えられる。この場合、周辺機器がサーバとネットワーク回線に接続されているので、この周辺機器はサーバによって所定のプロトコルで制御される。例えば、ネットワーク回線に対して接続されるプリンタやＦＡＸ，スキャナ，コピー機の統合機をサーバからＴＣＰ／ＩＰにて制御するような場合に本発明を適用することができる。むろん、クライアントも同一ネットワーク回線に接続することが可能である。
【００１１】
さらに、上記周辺機器と上記サーバとをローカル接続回線を介して双方向通信可能に接続し、上記周辺機器を周辺機器ドライバによってローカル接続回線を介して制御する構成が考えられる。この場合、周辺機器はサーバに制御され、サーバのパラレルポートにプリンタが接続されている場合や、スキャナがＳＣＳＩ接続されている場合に本発明を適用することができる。
【００１２】
また、クライアントにおいて周辺機器の制御処理の開始を認識することができれば、それに応じてクライアントにおいて種々の処理を行うことが可能となる。そのための好適な一例として、請求項３にかかる発明は、請求項２に記載の制御処理開始認識プログラムを記録した媒体において、上記サーバ側の上記制御指示検出機能では制御対象となっている周辺機器を特定するための情報を抽出し、上記クライアント側の上記制御処理開始認識機能では制御処理開始を認識したときに上記抽出情報に基づいて制御対象となる周辺機器を判別し、判別された制御対象周辺機器用のモジュールを起動する構成としてある。
【００１３】
上記のように構成した請求項３にかかる発明においては、サーバから制御対象の周辺機器を特定するための情報を抽出・出力し、クライアントにて当該制御対象周辺機器を判別する。従って、制御対象周辺機器用のモジュールが提供されている場合に、利用者にその実行開始を何ら意識させることなく、また、通常のクライアントの周辺機器ドライバを何ら変更することなくモジュールを実行することができる。モジュールは周辺機器特有の機能を実現するためのものにすることができるので、汎用的なドライバ作成ツールによって提供されるような周辺機器ドライバを使用していても、クライアントで周辺機器特有の機能を実現可能である。
【００１４】
このような周辺機器特有の機能としては様々なものが考えられ、その一例としては上記周辺機器のステータスを監視するためのステータス監視モジュールが考えられる。この場合、クライアントにおいて周辺機器の制御指示を与えるとステータス監視モジュールが起動するので、利用者は当該制御対象の周辺機器のステータスを知ることができる。むろんステータス監視モジュールがステータスを監視する態様は様々であり、利用者に対するステータスの通知手法も様々である。例えば、ステータス監視モジュールが起動されても通常は利用者に認知されない状態でモジュールを実行しつつ、エラーが発生したときに利用者に対してそのエラー内容を示すようにすることが考えられる。
【００１５】
また、上述のように、サーバにおいては周辺機器ドライバが行う処理に基づいて当該周辺機器の制御が開始されたことを検出することができればよく、種々の態様が採用可能である。その構成の一例として請求項４にかかる発明は、請求項１〜請求項３のいずれかに記載の制御処理開始認識プログラムを記録した媒体において、上記制御指示検出機能は、上記サーバ中の汎用関数実行時の処理情報に基づいて制御指示があったことを検出する構成としてある。
【００１６】
すなわち、クライアントからの制御指示に伴って上記周辺機器ドライバ等が処理を行う際には種々の汎用関数が実行されるが、この汎用関数が所定の情報を処理することを検出すれば上記制御指示があったことを検出したことになる。このように、汎用関数は上記汎用的なドライバ作成ツールによって提供されるような周辺機器ドライバを使用していても実行されるので、かかる構成により簡単に制御指示があったことを検出することができる。
【００１７】
また、請求項５にかかる発明は、請求項４に記載の制御処理開始認識プログラムを記録した媒体において、上記制御指示検出機能は、上記処理情報からユーザ名とマシン名と周辺機器名とポート名とのいずれかまたは組み合わせを抽出する構成としてある。
上記のように構成した請求項５にかかる発明において、ユーザ名およびマシン名は制御指示を与えた利用者やクライアントを知るとき使用することが可能であり、周辺機器名が分かれば起動するモジュールが簡単に判明し、ポート名が分かればその制御対象周辺機器と通信を行うことが可能になって制御対象を知るための情報を直接得ることができる。
【００１８】
より具体的な例としては、ＷＩＮＤＯＷＳ系（ＷＩＮＤＯＷＳはマイクロソフトコーポレイションの登録商標）のＯＳにおいて、ＳｔａｒｔＤｏｃＰｏｒｔ関数が実行されたときの処理情報から上記抽出を行うと好適である。この場合には上記制御指示検出機能においてはＧｅｔＪｏｂ（）関数を実行することでＳｔａｒｔＤｏｃＰｏｒｔ関数からＪｏｂＩＤを基にＪｏｂＩｎｆｏデータを取得して上記制御指示を与えたクライアントを指定するためにユーザ名とマシン名とを抽出し、制御対象となっている周辺機器を特定するために当該周辺機器名あるいはポート名を抽出することが可能である。この一連の処理は同時に制御処理が開始されたことを判別するための処理と言うこともできる。
【００１９】
また、周辺機器を特定するための情報を抽出すると制御処理開始を通知するが、この際に好適な構成の一例として、請求項６にかかる発明は、請求項１〜請求項５のいずれかに記載の制御処理開始認識プログラムを記録した媒体において、上記サーバ側で、上記制御指示検出機能によって上記制御処理開始を検出したときに利用者所望の処理が実行されるように設定する実行処理設定機能を実現させる構成としてある。
【００２０】
上記のように構成した請求項６にかかる発明においては、上記制御処理開始を通知するための処理をはじめとする種々の処理が制御処理開始検出時に実行されるよう設定可能である。例えば、ＷＩＮＤＯＷＳパソコンにおいて、レジストリに利用者所望のモジュール名を登録しておくことにより、制御処理開始検出時に当該登録内容を参照してその登録されたモジュールを実行するように構成することができる。むろんこの場合は、上記制御処理開始を通知するための処理は登録されるモジュールの一つとして提供される。
【００２１】
また、サーバは上記制御処理開始通知機能によってクライアントに対して上記制御処理の開始を通知するが、このための構成は様々であり、請求項７にかかる発明は、請求項２〜請求項６のいずれかに記載の制御処理開始認識プログラムを記録した媒体において、上記制御処理開始通知機能では、上記抽出した所定の情報に基づいて特定のクライアントを通信相手とするパケットの出力と不特定のクライアントを通信相手とするパケットの出力とのいずれかを実行する構成としてある。
【００２２】
上記のように構成した請求項７にかかる発明においては、通信相手を特定して、あるいは特定せずに通信を行うことができる。すなわち、サーバがクライアントと双方向通信を行う際に、相手となるクライアントが特定できればそのクライアントと通信を行い、特定できないときにはクライアントで自己が呼ばれていることを識別可能なデータを通信相手となり得る全てのクライアントに送信する。例えば、前者の場合には宛先特定送信方式で通信を行えばよいし、後者の場合にはブロードキャスト方式で通信を開始し、返答のあったクライアントと通信を行えばよい。
【００２３】
このように、サーバはクライアントにおいて自己が呼ばれていることを認識可能に通信を開始するので、上記クライアントはパケットを受信したときに上記制御処理の開始を認識する。従って、上記制御処理開始認識機能においては、上記通信相手を指定して出力されたパケットを受信したときには当該受信をもって制御処理の開始を認識することができる。上記通信相手を指定せずに出力されるパケットを受信したときには当該受信パケットに含まれる上記抽出情報に基づいて自己に対するパケットか否かを判別し、自己に対するパケットであるときに制御処理の開始を認識することができる。
【００２４】
また、制御処理の開始を認識した後に適切なモジュールを実行するためには、制御対象周辺機器名を判別することができればよく、そのための構成は様々である。その一例として、請求項８にかかる発明は、請求項３〜請求項７のいずれかに記載の制御処理開始認識プログラムを記録した媒体において、上記制御処理開始認識機能では、上記抽出情報に含まれるポート名を使用して制御対象周辺機器と双方向通信を行って同制御対象周辺機器名を判別可能である構成としてある。
【００２５】
上記のように構成した請求項８にかかる発明においては、上記抽出情報に制御対象周辺機器のポート名が含まれる場合に同ポート名で同制御対象周辺機器と通信を行う。そして、制御対象周辺機器のデバイスＩＤを取得してその中のモデルＩＤを判別し、このモデルＩＤとクライアントに登録されているモデルＩＤ名とを比較して一致するものを制御対象周辺機器とすれば、制御対象周辺機器名を判別することができる。むろん上記抽出情報に制御対象周辺機器名が含まれる場合には当該名称を使用すればよい。
【００２６】
むろん、以上述べてきた記録媒体は、磁気記録媒体であってもよいし光磁気記録媒体であってもよいし、今後開発されるいかなる記録媒体においても全く同様に考えることができる。また、一次複製品、二次複製品などの複製段階については全く問う余地無く同等である。その他、供給方法として通信回線を利用して行なう場合であればファイルサーバが本プログラムを記録した媒体となって本発明が利用されていることにはかわりない。
さらに、一部がソフトウェアであって、一部がハードウェアで実現されている場合においても発明の思想において全く異なるものではなく、一部を記録媒体上に記憶しておいて必要に応じて適宜読み込まれるような形態のものとしてあってもよい。
【００２７】
このように、クライアントにおいて操作した周辺機器操作の指示等の制御指示に基づいてサーバが双方向通信によって制御処理開始を通知する手法は実体のあるサーバとクライアントとにおいて実現され、その意味で本発明をそのようなサーバとクライアントとからなる装置としても適用可能であることは容易に理解できる。このため、請求項９〜請求項１６にかかる発明においても、基本的には同様の作用となる。むろん、このようなシステムは単独で実施される場合もあるし、ある機器に組み込まれた状態で他の方法とともに実施されることもあるなど、発明の思想としてはこれに限らず、各種の態様を含むものであって、適宜、変更可能である。
【００２８】
また、このような制御処理開始認識プログラムはかかる制御に従って処理を進めていく上で、その根底にはその手順に発明が存在するということは当然であり、方法としても適用可能であることは容易に理解できる。このため、請求項１７〜請求項２４にかかる発明においても、基本的には同様の作用となる。すなわち、必ずしも実体のある媒体などに限らず、その方法としても有効であることに相違はない。
【００２９】
【発明の効果】
以上説明したように請求項１、請求項９、請求項１７にかかる本発明によれば、クライアントにおいて制御指示を与えるための構成に何ら変更を加えることなく当該クライアントで制御処理の開始を認識することができる。
また、請求項２、請求項１０、請求項１８にかかる発明によれば、汎用的な周辺機器ドライバを使用していてもクライアントにおいて制御処理の開始を認識することができる。
さらに、請求項３、請求項１１、請求項１９にかかる発明によれば、汎用的な周辺機器ドライバを使用していてもクライアントにおいて周辺機器特有の機能を実現することができる。
さらに、請求項４、請求項１２、請求項２０にかかる発明によれば、簡単に制御指示があったことを検出することが可能となる。
【００３０】
さらに、請求項５、請求項１３、請求項２１にかかる発明によれば、通常の制御処理に使用される情報のみに基づいて所定の相手クライアントと通信を行うことができる。
さらに、請求項６、請求項１４、請求項２２にかかる発明によれば、簡単に利用者所望の処理を行わせることが可能になって汎用性が高くなる。
さらに、請求項７、請求項１５、請求項２３にかかる発明によれば、簡単にクライアントに対して制御処理開始通知を受信させることができる。
さらに、請求項８、請求項１６、請求項２４にかかる発明によれば、利用者が何ら意識することなく制御対象周辺機器専用のモジュールを起動することができる。
【００３１】
【発明の実施の形態】
以下、図面にもとづいて本発明の実施形態を説明する。
図１はサーバのハードウェア構成を示しており、図２は制御処理の開始を認識するためのサーバおよびクライアントの構成の要部を示している。尚、本実施形態では周辺機器はプリンタである。図１に示すように、サーバ１０とクライアント５０とプリンタ４０ａとはＵＴＰケーブル３３を介して接続されており、クライアント５０からのプリンタ４０ａの制御指示は一旦サーバ１０に入力され、当該サーバ１０がプリンタ４０ａを制御するようになっている。また、サーバ１０においてはパラレルケーブル３４を介してプリンタ４０ｂをローカル接続することが可能であり、上記と同様にクライアント５０からの制御指示に応じてサーバ１０がプリンタ４０ｂを制御する。
【００３２】
同図において、サーバ１０は演算処理の中枢をなすＣＰＵ１１を備えており、このＣＰＵ１１はシステムバス１２を介してＢＩＯＳなどの記載されたＲＯＭ１３やＲＡＭ１４にアクセス可能となっている。また、システムバス１２には外部記憶装置としてのハードディスクドライブ１５とフロッピーディスクドライブ１６とＣＤ−ＲＯＭドライブ１７とが接続されており、ハードディスクドライブ１５に記憶されたオペレーティングシステム（ＯＳ）２０やアプリケーション（ＡＰＬ）などがＲＡＭ１４に転送され、ＣＰＵ１１はＲＯＭ１３とＲＡＭ１４に適宜アクセスしてソフトウェアを実行する。本実施形態においては、制御処理開始認識プログラムも同様にハードディスクドライブ１５からＲＡＭ１４に転送されて実現されている。
【００３３】
シリアル通信用Ｉ／Ｏ１９ａにはキーボード３１やマウス３２の操作用入力機器が接続され、図示しないビデオボードを介して表示用のディスプレイ１８も接続されている。さらに、プリンタ４０ａおよびクライアント５０とは１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃを介してＵＴＰケーブル３３によって接続可能になっており、プリンタ４０ｂとはパラレル通信用Ｉ／Ｏ１９ｂを介してパラレル接続が可能となっている。尚、本サーバ１０の構成は簡略化して説明しているが、パーソナルコンピュータやワークステーションとして一般的な構成を有するものを採用することができる。
【００３４】
むろん、本発明が適用されるサーバはパーソナルコンピュータに限定されるものではない。この実施例はいわゆるデスクトップ型コンピュータであるが、ノート型であるとか、モバイル対応のものであっても良い。また、サーバ１０とプリンタ４０ａ，ｂとの接続インタフェースもパラレル通信用Ｉ／Ｏ１９ｂや１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃなどに限る必要はなく、通常のシリアルインタフェースやＳＣＳＩ，ＵＳＢ接続など種々の接続態様を採用可能であるし、今後開発されるいかなる接続態様であっても同様である。
【００３５】
また、サーバ１０にはパラレル通信用Ｉ／Ｏ１９ｂと１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃとを介してプリンタ４０が接続可能になっているが、必ずしも両Ｉ／Ｏを必要とするわけではなく、どちらかのインタフェースのみを有する構成であってもよい。すなわち、サーバ１０に対して周辺機器がネットワーク回線を介して接続される構成およびローカル接続回線を介して接続される構成のどちらに対しても本発明を適用することが可能である。
【００３６】
クライアント５０のハードウェア構成も図１に示すサーバのハードウェア構成と略同一である。すなわち、パーソナルコンピュータやワークステーションとして一般的な構成を有するものを採用することが可能である。ここで、本発明に関してはクライアント５０に周辺機器を接続する必要はないのでパラレル通信用Ｉ／Ｏ１９ｂを設ける必要はないが、むろん、パラレル通信用Ｉ／Ｏ１９ｂを介してプリンタ等の周辺機器を接続可能であっても全く問題はない。
【００３７】
この例では制御処理開始認識プログラムを含む各プログラムの類はハードディスクドライブ１５に記憶されているが、記録媒体はこれに限定されるものではない。例えば、フロッピーディスク１６ａであるとか、ＣＤ−ＲＯＭ１７ａであってもよい。これらの記録媒体に記録されたプログラムはフロッピーディスクドライブ１６やＣＤ−ＲＯＭドライブ１７を介してサーバ１０やクライアント５０にて読み込まれ、ハードディスクドライブ１５にインストールされる。そして、ハードディスクドライブ１５を介してＲＡＭ１４上に読み込まれてホストコンピュータを制御することになる。また、記録媒体はこれに限らず、光磁気ディスクなどであってもよい。また、半導体デバイスとしてフラッシュカードなどの不揮発性メモリなどを利用することも可能であるし、モデムや通信回線を介して外部のファイルサーバにアクセスしてダウンロードする場合でもサーバーの記憶部が記録媒体となりうることはいうまでもない。
【００３８】
次に、図２に示すサーバ１０およびクライアント５０の制御系の要部構成を説明する。同図において、サーバ１０のＯＳ２０にはプリンタドライバ（ＰＲＴＤＲＶ）２１が組み込まれており、同プリンタドライバ２１は上記プリンタ４０ａをＴＣＰ／ＩＰで制御する。また、ＯＳ２０にはＳｔａｒｔＤｏｃＰｏｒｔ関数を実行するＴＣＰ／ＩＰ印刷モジュール２１ａが組み込まれている。クライアント５０のＯＳ６０にはプリンタドライバ６１が組み込まれており、また、１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃを介してパケットを受信したか否かを検出するエージェント６２を備えている。ここで、クライアント５０のプリンタドライバ６１はプリンタ４０ａに対して信号を送信して直接的に制御するためのものではなく、利用者のＡＰＬ操作に基づいてサーバ１０に対してプリンタ４０ａの制御指示や印刷イメージやフォント等のデータを送信したりクライアント５０のマシン名等を含むＪｏｂＩｎｆｏデータ等を送信したりするためのものである。
【００３９】
サーバ１０のプリンタドライバ２１はこのクライアント５０から１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃを介して発信されるプリンタ４０ａの制御指示に応じてプリンタ４０ａを制御して所定の印刷等を行うようになっている。また、サーバ１０にはこのプリンタドライバ２１が処理を開始することに応じてクライアント５０に対して制御処理の開始を認識可能にデータを出力するために、印刷通知モジュール２２と起動モジュール２３とからなる通知モジュール群が備えられている。
【００４０】
具体的には、ＴＣＰ／ＩＰ印刷モジュール２１ａにＳｔａｒｔＤｏｃＰｏｒｔ関数を作成して、プリンタドライバ２１にてプリンタ４０ａの制御処理を行う際に同関数が実行されるように構成してある。このＳｔａｒｔＤｏｃＰｏｒｔ関数にはＪｏｂＩＤと呼ばれるユーザ名とマシン名とポート名とを含む印刷情報へのインデックスが渡されるので、このときに印刷開始を検出することになる。従って、このＴＣＰ／ＩＰ印刷モジュール２１ａが上記制御指示検出機能を構成する。また、上記印刷通知モジュール２２はＧｅｔＪｏｂ（）関数を実行してＪｏｂＩｎｆｏとして上記ユーザ名とマシン名とポート名とを取得するようになっている。印刷通知モジュール２２は、これらのユーザ名とマシン名とポート名が出力されたときに予めＯＳ２０のレジストリ２２ａに登録されたモジュールを起動するようになっており、起動モジュール２３は起動されるモジュールの一つとして予め登録されている。従って、印刷通知モジュール２２とレジストリ２２ａとが上記実行処理設定機能を構成する。
【００４１】
ここで、起動モジュール２３は印刷通知モジュール２２から上記ユーザ名とマシン名とポート名の情報を取得して、これらの情報に基づいて後述する判断手順に基づいて通信相手や通信形態を判断し、宛先特定送信やブロードキャストを用いて１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃを介してクライアント５０に対して所定のデータを所定態様のパケットで送信する。従って、印刷通知モジュール２２と起動モジュール２３とが上記制御処理開始通知機能を構成する。クライアント５０のＯＳ６０に組み込まれた上記エージェント６２はこの起動モジュール２３の制御によって出力されるパケットを受信するか否かを監視している。
【００４２】
また、クライアント５０には受信パケットに基づいてサーバ１０における制御処理の開始を認識し、さらにはプリンタ４０ａのステータスを監視するためのモジュールを起動するための認識モジュール群が備えられている。より具体的には、認識モジュール群はＳＴＭ起動モジュール６３とステータスを監視するためのステータスモニタ６４とを備えている。上記エージェント６２が上記起動モジュール２３の制御によって出力されるパケットを受信するとレジストリ６５を参照するなどの後述する所定の判断手順に基づいて、パケットが宛先特定送信，ブロードキャストのいずれの手法で送信されたかを判別する。
【００４３】
そして、この判別結果に応じて必要なときには上記ＳＴＭ起動モジュール６３を起動し、上記ポート名の情報を同ＳＴＭ起動モジュール６３に対して出力する。ＳＴＭ起動モジュール６３はエージェント６２が出力するポート名の情報から、レジストリ６５を参照するなどの後述する手順に基づいて、必要なときはプリンタ４０ａと通信を行って当該クライアント５０中のＳＴＭを起動するか否かを判別し、判別の結果に応じてステータスモニタ６４を起動する。従って、クライアント５０を操作する利用者はプリンタ４０ａにて印刷エラーが生じたときなどにそのステータスを認識することができる。従って、エージェント６２とＳＴＭ起動モジュール６３とが上記制御処理開始認識機能を構成する。
【００４４】
ここで、上記構成によって、クライアント５０にて制御指示を出したプリンタ４０ａに対してサーバ１０が制御を開始したときにクライアント５０上で利用者がプリンタ４０ａのステータスを認識することができるが、サーバ１０上で利用者がプリンタ４０ａの制御指示を出し、ステータスを知りたい場合のためにＳＴＭ起動モジュール６３とステータスモニタ６４とをサーバ１０備える構成にすることもできる。また、ここで起動されるモジュールはステータスモニタ６４に限ることなく、利用者あるいは周辺機器メーカー所望のモジュールを起動可能に構成することができる。
【００４５】
さらに、サーバ１０が制御するプリンタは上述のようにネットワーク回線を介して接続されたものに限られず、ローカル接続回線で接続されるプリンタ４０ｂであってもかまわない。図３はかかる場合のサーバ１０の制御系の要部構成を示しており、同図において、サーバ１０のＯＳ２０にはプリンタドライバ（ＰＲＴＤＲＶ）２１が組み込まれており、また、ＯＳ２０にはＳｔａｒｔＤｏｃＰｏｒｔ関数を実行するランゲージモニタ２１ｂが組み込まれている。この場合は、上記クライアント５０からの制御指示によってプリンタドライバ２１が所定の処理を行う際に、ランゲージモニタ２１ｂのＳｔａｒｔＤｏｃＰｏｒｔ関数にＪｏｂＩＤが渡されることによって印刷開始が検出される。
【００４６】
検出後には上述の処理と同様に印刷通知モジュール２２が起動される等して、最終的にはクライアント５０上でステータスモニタ６４が起動する。尚、この場合はプリンタドライバ２１はプリンタ４０ｂをパラレル通信用Ｉ／Ｏ１９ｂを介して制御するようになっており、ランゲージモニタ２１ｂにてＪｏｂＩｎｆｏとしてユーザ名とマシン名とプリンタ名を取得する。従って、上述の態様とではプリンタ名とポート名という情報内容の相違があるが、いずれにしても後述する手順によってステータスモニタ６４が起動されることになる。
【００４７】
以下、上記構成における上記サーバ１０およびクライアント５０に備える各モジュールによって実行される処理フローを説明する。図４は上記ＴＣＰ／ＩＰ印刷モジュール２１ａあるいはランゲージモニタ２１ｂが行う処理のフローである。同図において、プリンタドライバ２１が印刷を開始すると、ＴＣＰ／ＩＰ印刷モジュール２１ａはステップＳ１００にてＳｔａｒｔＤｏｃＰｏｒｔ関数を実行し、ステップＳ１１０にてＪｏｂＩＤを受領する。そして、ステップＳ１２０においてＧｅｔＪｏｂ（）関数を実行してＪｏｂＩｎｆｏとしてユーザ名とマシン名とポート名（プリンタ名）とを取得して、ステップＳ１３０において当該取得情報を付加しつつ印刷通知モジュール２２を起動する。
【００４８】
すなわち、同フローではＳｔａｒｔＤｏｃＰｏｒｔ関数が実行されてＪｏｂＩＤが処理されることをもってＪｏｂＩｎｆｏ情報の抽出から印刷通知モジュールの起動まで結びつけており、当該処理において印刷開始を検出しているといえる。尚、ここで、ポート名（プリンタ名）と記載したのは、プリンタがネットワーク回線を介して接続されるかローカル接続回線を介して接続されるかによっていずれか一方が抽出されることを示しており、以下の記載においても同様である。
【００４９】
図５は、上記ステップＳ１３０にて起動された印刷通知モジュール２２のフローである。印刷通知モジュール２２はステップＳ２００にて上記ステップＳ１３０にて上記ステップＳ１３０の起動時に付加されているユーザ名とマシン名とポート名（プリンタ名）を取得する。その後、印刷通知モジュール２２はステップＳ２１０にてレジストリ２２ａを参照して当該レジストリ２２ａに記載されているモジュールを実行し、ステップＳ２２０では、同ステップＳ２１０にて実行した全てのモジュールに対して上記ステップＳ２００の取得データを出力する。ここで、レジストリ２２ａには予め起動モジュール２３が登録されており、同起動モジュール２３は上記ステップＳ２１０にて実行される。
【００５０】
すなわち、起動モジュール２３に対してもこれらのユーザ名とマシン名とポート名（プリンタ名）が出力される。ここで、上記ステップＳ２１０において起動モジュール２３のように実行されるモジュールをレジストリに登録しておくのは、モジュールを実行させるに当たり簡単に利用者や周辺機器メーカー所望のモジュールを追加可能にして汎用性を向上させるためである。
【００５１】
図６は、上記ステップＳ２１０にて実行された起動モジュール２３のフローである。同起動モジュール２３は、所望のクライアント５０を通信相手にして双方向通信を行って制御処理開始を認識させるための処理を行う。このため、まずステップＳ３００において、サーバ１０のユーザ名とマシン名をレジストリ２２ａから取得し、上記ステップＳ２２０にて出力されるＪｏｂＩｎｆｏデータとしてユーザ名とマシン名とポート名（プリンタ名）を取得する。
【００５２】
以下のステップにおいて取得したサーバ１０のマシン名等の情報とＪｏｂＩｎｆｏデータのユーザ名等の情報とを比較するが、これは、サーバ１０とクライアント５０のＯＳが異なる場合等にＪｏｂＩｎｆｏデータのユーザ名とマシン名が必ずしもクライアント５０のユーザ名とマシン名になっていないからである。より具体的には、図１３にその一例を示してある。この例は、図１２（ａ）のようにネットワーク回線上にサーバ１０とクライアント５０と他のクライアントを接続し、サーバ１０のユーザ名がＡ，マシン名がＰＣ１であり、クライアント５０のユーザ名がＢ，マシン名がＰＣ２である場合について示してある。
【００５３】
ここで、図１３においてはサーバ１０あるいはクライアント５０のＯＳが、ＷＩＮＤＯＷＳ９５あるいはＷＩＮＤＯＷＳＮＴのいずれかである場合について全ての組み合わせを表にして示している。同図の例においては、サーバ１０のＯＳとクライアント５０のＯＳとが同一である場合にはＪｏｂＩｎｆｏデータ中のユーザ名はＢ，マシン名はＰＣ２であり、これらのデータを使用すれば通信相手のクライアントおよび使用ユーザを特定することができる。しかし、サーバ１０のＯＳとクライアント５０のＯＳとが異なる場合にはＪｏｂＩｎｆｏデータからクライアント５０のユーザ名とマシン名とを取得することができない。
【００５４】
すなわち、サーバ１０のＯＳがＷＩＮＤＯＷＳ９５でクライアント５０のＯＳがＷＩＮＤＯＷＳＮＴである場合には、ＪｏｂＩｎｆｏデータ中のユーザ名はＰＣ２でありマシン名もＰＣ２になってしまう。また、サーバ１０のＯＳがＷＩＮＤＯＷＳＮＴでクライアント５０のＯＳがＷＩＮＤＯＷＳ９５である場合には、ＪｏｂＩｎｆｏデータ中のユーザ名はＢでありマシン名がＰＣ１になってしまう。従って、サーバ１０で通信相手を特定すべく図６に示すステップＳ３２０以降の処理を行っている。
【００５５】
同図ステップＳ３２０においては、上記ステップＳ３００で取得したサーバ１０のマシン名と上記ステップＳ３１０で取得したＪｏｂＩｎｆｏデータ中のマシン名とを比較する。ステップＳ３３０では、当該比較の結果両者が一致しているか否かを判別する。両者が一致していると判別されないときは、上記図１３に示すようにサーバ１０とクライアント５０のＯＳが一致している場合か、あるいはサーバ１０のＯＳがＷＩＮＤＯＷＳ９５でクライアント５０のＯＳがＷＩＮＤＯＷＳＮＴである場合であって、ＪｏｂＩｎｆｏデータ中のマシン名はクライアント５０のマシン名である。
【００５６】
従って通信相手は特定され、ステップＳ３７０にて当該マシン名のクライアント５０に対して１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介して双方向通信によってＪｏｂＩｎｆｏデータに基づくユーザ名とマシン名とポート名（プリンタ名）を出力する。尚、本実施形態においては、このように通信相手を指定して通信を行う際には宛先特定送信方式で通信を行うようになっている。また、ステップＳ３７０に示す（Ｊ）は出力するユーザ名等のデータはＪｏｂＩｎｆｏデータに基づくものであることを示しており、ステップＳ３６０においても同様である。
【００５７】
上記ステップＳ３３０で両者が一致していると判別されたときには、ステップＳ３４０にて上記ステップＳ３００で取得したサーバ１０のユーザ名と上記ステップＳ３１０で取得したＪｏｂＩｎｆｏデータ中のユーザ名とを比較する。ステップＳ３５０では、当該比較の結果両者が一致しているか否かを判別する。両者が一致していると判別されないときは、上記図１３に示すようにサーバ１０のＯＳがＷＩＮＤＯＷＳＮＴでクライアント５０のＯＳがＷＩＮＤＯＷＳ９５である場合のように、マシン名が一致し、ユーザ名が異なる状況である。
【００５８】
そこで、かかる場合にはステップＳ３６０では通信相手はネットワーク回線に接続されるクライアントのいずれかであるとして、ブロードキャスト方式で全てのクライアントに対して１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介してＪｏｂＩｎｆｏデータに基づくユーザ名とマシン名とポート名（プリンタ名）を出力する。この場合は、クライアント５０にログオンしているユーザしか特定できないので、当該ブロードキャスト方式で出力されるパケットを受け取った全てのクライアントは、後述するエージェントの処理で受信データ中のユーザ名によって自己に対する発信か否かを判別するようになっている。
【００５９】
上記ステップＳ３５０で両者が一致していると判別されたときは、図１３に示すいずれの状況でもなく、ＪｏｂＩｎｆｏデータのユーザ名およびマシン名がサーバ１０のユーザ名およびマシン名と一致している状況である。従って、この場合は、クライアントからプリンタ４０ａの制御指示があったのではなく利用者がサーバ１０にてプリンタ４０ａの制御指示を与えたと考えられる。そこで、かかる場合にはステップＳ３８０にてサーバ１０のステータスモニタを起動する。
【００６０】
図７はクライアント５０のＯＳ６０に組み込まれたエージェント６２のフローを示しており、上記起動モジュール２３がステップＳ３６０，Ｓ３７０で出力する情報を取得して、自己がプリンタ４０ａの制御指示を出力したか否かを判別する等の処理を行う。当該エージェント６２はＯＳ６０に常駐し、ステップＳ４００にて上記ステップＳ３６０，Ｓ３７０にてサーバ１０が出力するパケットを受信したか否かを判別する。同ステップＳ４００にてパケットを受信したと判別したときには、ステップＳ４１０にて当該バケット中の所定位置に記載されたフラグによって当該パケットがブロードキャスト方式による送信であるか否かを判別する。
【００６１】
同ステップＳ４１０にて当該パケットがブロードキャスト方式であると判別されないとき、この受信パケットは上記宛先特定送信であって受信クライアントを特定して送信したものである。そこで、ステップＳ４２０にて上記ＳＴＭ起動モジュール６３を起動し、ステップＳ４３０ではＳＴＭ起動モジュール６３が制御対象プリンタ４０ａに関するモジュールを起動できるように受信パケット中に含まれるＪｏｂＩｎｆｏデータに基づくポート名（プリンタ名）を出力する。ステップＳ４１０にて受信パケットがブロードキャスト方式であると判別されたときには、ステップＳ４４０にてクライアント５０のレジストリ６５から当該クライアント５０のユーザ名を取得する。
【００６２】
そして、ステップＳ４５０にて当該クライアント５０のユーザ名と上記パケット中に記載されたＪｏｂＩｎｆｏデータに基づくユーザ名とを比較し、ステップＳ４６０にて両者が一致するか否かを判別する。同ステップＳ４６０にて両者が一致する場合には、プリンタ４０ａに対して制御指示を与えたクライアントが自己であると認識することができるので、上述のステップＳ４２０以降のＳＴＭ起動モジュール６３を起動する一連の処理を行う。ステップＳ４６０にて両者が一致しない場合には、プリンタ４０ａに対して制御指示を与えたクライアントは自己ではないので、ＳＴＭ起動モジュール６３を起動することなく一連の処理を終了する。
【００６３】
ここで、本実施形態においては、サーバ１０とクライアント５０との間でメールスロット方式の双方向通信を採用して、宛先特定送信とブロードキャストとを実現している。また、通信相手においてリプライ用のメールスロットを作成・送信することにより通信の信頼性を向上させている。このために、本実施形態においてサーバ１０が上記ステップＳ３６０，Ｓ３７０にて出力するバケットは図１４に示すような構造体となっている。すなわち、このパケットにはその前半において適正な通信を可能にし、また、信頼性を向上させるためのパケットサイズやカウンタ値等が含まれており、後半にてユーザ名，マシン名，ポート名（プリンタ名）が含まれている。
【００６４】
カウンタ値はある情報を含むパケットを一意に特定するためのものであり、後述するようにサーバ１０がリトライとして同一情報を含むパケットを再送信した際に、クライアント５０にて当該受信パケットがすでに受け取ったものであるか否かを判別することができる。また、パケットの組番号，総数，順序はある情報を複数のパケットに分割して送信する際に、分割されたパケットをクライアント５０側で一つの情報として再現するための処理を行うためのものである。すなわち、一つの情報に対して一意に組番号を付与しておき、パケットの分割数を総数とし、分割したパケットに順序を付与することによりクライアント５０で共通の組番号を付された情報を順序通りに再現する。また、パケットにはブロードキャストか否かを示すフラグも含まれており、当該フラグにてブロードキャストであることが示されている場合には全てのクライアントは自己が処理を行うべきか否かを判別する。
【００６５】
また、メールスロット方式においては送信側と受信側とでやりとりを行うためのメールスロット名を決定し、送信側と受信側とにおいて送信用と受信用のメールスロットを作成する。従って、上記エージェントはそのメールスロットでパケットの受信を待ち、送信側がそのメールスロットへパケットを送信することでやりとりを行う。より具体的には、サーバ１０およびクライアント５０の両方において「￥￥＜コンピュータ名＞￥ｍａｉｌｓｌｏｔ￥＜メールスロット名＞」という形式にてメールスロットを作成する。図１２（ａ）においては、メールスロット名は「ＥＰＳＯＮ￥ＳＴＭ３￥ＳＩＤＭ￥ＡＧＥＮＴ」となっている。さらに、コンピュータ名を「ＰＣ２」とすることによって当該メールスロットは「ＰＣ２」を宛先として特定したメールスロットになり、コンピュータ名を「＊」にすることによって全クライアントにあてたブロードキャスト方式になる。また、「．」は自己であることを示しており、コンピュータ名として当該指定を行うことによって受信用メールスロットとなる。
【００６６】
図８は上述のパケットをサーバ１０が上記ステップＳ３６０，Ｓ３７０にて出力するときの詳細な通信手順を示している。ステップＳ３６１においてサーバ１０はメールスロット送信用スレッドを作成し、ステップＳ３６２では複数のプリンタが連続して印刷開始した場合などにメールスロット等の資源の取り合いを回避するため、ミューテックスを取得する。次にステップＳ３６３で通信の信頼性を向上させるためクライアント５０からのリプライを受信するためのメールスロットを作成し、ステップＳ３６４にて１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介してパケットを出力する。
【００６７】
ここで、上記ステップＳ３６０の場合は、ブロードキャスト方式の送信なので送信用のメールスロットでコンピュータ名を「＊」にしてパケットを出力する。上記ステップＳ３７０の場合は、宛先特定送信なのでコンピュータ名を「ＰＣ２」などとして具体的に指定しつつパケットを出力する。ステップＳ３６５ではクライアント５０からのリプライを待つ時間を計測するためにタイマをセットし、ステップＳ３６６にて１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介してリプライを受信したか否かを判別する。同ステップＳ３６６にてリプライを受信したと判別しないときにはステップＳ３６７にてタイムアウトになっているかを判別して、当該ステップＳ３６７にてタイムアウトと判別されなければステップＳ３６６に戻って処理を繰り返す。
【００６８】
ステップＳ３６６にてリプライを受信したと判別したとき、あるいはステップＳ３６７にてタイムアウトと判別されたときには、ステップＳ３６８にて所定のリトライ回数を行った否かを判別し、所定のリトライ回数を行ったと判別されないときには上記ステップＳ３６４〜Ｓ３６８間でのパケット出力・確認処理を繰り返す。ステップＳ３６８にてリトライを行う必要がないと判別されるかリトライ回数を越えたときにはステップＳ３６９にてミューテックスを開放してパケット送信のためのスレッドを終了する。すなわち、本実施形態においては、メールスロット方式を採用することによって宛先特定送信であってもブロードキャストであっても簡単な変更のみで対応することが可能であり、また、リプライ受信用メールスロットにてリプライを確認することによって通信の信頼性を向上させている。
【００６９】
図９はサーバ１０が出力するパケットをクライアント５０が上記ステップＳ４００にて受信するときの詳細な通信手順を示している。上述のようにエージェント６２はＯＳ６０に常駐しており、当該エージェント６２がステップＳ４０１にてパケット受信したときには、ステップＳ４０２にて送信元のサーバ１０に対してリプライパケットを送信する。そして、ステップＳ４０３にて上記ステップＳ４０１にて受信したパケットのカウンタ値を参照し、すでに何らかのパケットを取得済みであってカウンタ値を保持している場合にはステップＳ４０４にて、取得したパケットのカウンタ値と保持しているカウンタ値とが一致するか否かを判別する。
【００７０】
同ステップＳ４０４にてカウンタ値が一致した場合には当該パケットをすでに取得済みであるので当該パケットに関して処理を続行しない。ステップＳ４０４にてカウンタ値が一致したと判別されないときにはステップＳ４０５にてカウンタ値を保存する。そして、ステップＳ４０６においては上記組番号が指定されているような場合に全てのパケットを受領したか否かを判別し、全てのパケットを受領していない場合にはステップＳ４０１以降の処理を繰り返す。このように、クライアントにおいては、パケット受信に際して通信の信頼性を向上させるための処理や分割パケット復元等の処理を行っている。この結果、上記図７に示すパケット情報に基づくクライアントにおける処理を行うことが可能になる。
【００７１】
図１０は上記ステップＳ４２０で起動されるＳＴＭ起動モジュール６３のフローを示しており、上記ステップＳ４３０で出力されるポート名（プリンタ名）別に所定の判別を行って制御対象プリンタ４０ａ用のステータスモニタ６４を起動する。このため、ステップＳ５００では上記ステップＳ４３０で出力されるポート名（プリンタ名）を取得し、ステップＳ５１０にて当該取得データがプリンタ名であるか否かを判別する。同ステップＳ５１０で取得データがプリンタ名であると判別されたときには、ステップＳ５８０にてそのプリンタ名のステータスを監視するためのステータスモニタ６４を起動する。
【００７２】
上記ステップＳ５１０で取得データがプリンタ名であると判別されないときには取得データはポート名であるので、以降の処理でこのポート名を使用して上記プリンタ４０ａと双方向通信を行って、当該プリンタ４０ａのプリンタ名を取得する。すなわち、ＪｏｂＩｎｆｏデータは元々プリンタ４０ａを制御するためのデータであって、当該ポート名はプリンタ４０ａを指定するものである。そこで、ステップＳ５２０では上記ステップＳ５００で取得したポート名で示されるプリンタ４０ａと上記１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介して双方向通信を開始する。ここで、ポート名は上記図１３に示すように「￥￥Ｅｐｓｏｎ＿ｌｐｒ￥１９２．１６８．ｘ．ｘ」であり、本実施形態においては当該ポート名を使用してプリンタ４０ａと双方向通信を行う図示しないモジュールが組み込まれており、当該モジュールの制御に基づいてプリンタ４０ａと通信を行うようになっている。
【００７３】
この双方向通信において、ステップＳ５３０ではプリンタ４０ａのデバイスＩＤを取得し、同デバイスＩＤ中のモデルＩＤを取得する。一方、上記クライアント５０中のＯＳ６０に組み込まれたレジストリ６５には当該クライアント５０で使用する周辺機器であるプリンタ４０ａのモデルＩＤおよび出力ポート名が記載されている。そこで、ステップＳ５４０ではレジストリ６５を参照し、ステップＳ５５０で上記取得したモデルＩＤおよび出力ポート名がレジストリに記載されたモデルＩＤおよび出力ポート名に一致するものを検出する。
【００７４】
ステップＳ５６０ではこれらのモデルＩＤと出力ポート名との組が一致したか否かを判別し、上記ステップＳ５００で取得したものとレジストリ記載のものとが一致するものがあると判別されたときには、ステップＳ５８０にて該当するモデルＩＤおよび出力ポート名を有するプリンタ４０ａのステータスモニタ６４を起動する。ステップＳ５６０で一致するものがあると判別されないときには、ステップＳ５７０にて上記ステップＳ５００で取得したポート名とレジストリ記載のポート名とが一致するものを検出し、最初に検出されたポート名が一致するプリンタを制御対象と見なしてステップＳ５８０にて該当するプリンタのステータスモニタ６４を起動する。
【００７５】
上記構成によってプリンタ４０ａの制御を開始したときには、利用者が何ら意識することなくステータスモニタ６４が起動し、通常はバックグラウンドでステータスを監視し、印刷エラー等が生じたときにステータスモニタ画面を上記クライアント５０のディスプレイ１８に表示して利用者にプリンタ４０ａのステータスを提示する。一方、利用者が望む時にいつでもステータスモニタ６４を起動可能であれば便利であり、本実施形態では汎用的なドライバ作成ツールによって提供される周辺機器ドライバを使用しつつもステータスモニタ６４を起動可能に構成するため、プリンタのプロパティを起動したときにＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュールを起動するようになっている。
【００７６】
具体的には、プリンタのプロパティを起動したときには、図１５に示すようにＷＩＮＤＯＷＳの本体モジュール７０がプロパティシート７１の画面を生成し、デフォルトで表示するようになっている「全般」「ポート」などのページを追加する。このとき、立ち上げられたプリンタである「ＬＱ−５８０」のドライバＵＩモジュール７２が起動して「ドライバ」ページを追加するようになっている。本実施形態では「ＬＱ−５８０」のドライバは汎用的なドライバ作成ツールで提供されているため、ステータスモニタ６４を起動するためのボタン等を上記ドライバＵＩモジュール７２が追加するページに設けることができない。
【００７７】
そこで、ＷＩＮＤＯＷＳ本体モジュール７０において呼び出すことが可能なＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュール７３にて独自のページを上記プロパティシート７１に追加するように構成してある。このＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュール７３を使用した拡張は、プリンタであればクライアント５０にインストールされている全てのプリンタに対して行われることになり、特定のプリンタのみに対して拡張を行うことはできないようになっている。そこで、本実施形態のＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュールではプリンタをプロパティページの表示内容によっていくつかのタイプに分類し、分類した各タイプ毎にＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュールを用意してある。
【００７８】
各タイプのＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュールは自己のタイプ番号を保持しており、レジストリを参照して最終的には「ＬＱ−５８０」のプロパティシート７１に追加すべきページのＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュールのみが起動し続けるようになっている。すなわち、ＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュール７３が起動すると、当該プロパティのドライバ名を取得する。そして、レジストリに当該ドライバ名が予め登録されていないものは起動する必要が無いとしてそのまま処理を中断する。
【００７９】
また、本手法によるページ追加に対応したプリンタのドライバに対してはレジストリにドライバ毎に予め上記タイプ情報が書き込まれている。そこで、続いて取得したドライバ名のレジストリにタイプ情報が書き込まれているか否かを判別し、タイプ情報が書き込まれていないＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュールも起動する必要が無いとしてそのまま処理を中断する。さらに、ＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュール７３はこのタイプ情報が自己のタイプと一致しているか否かを確認して、一致するもののみ起動し続ける。この結果、所望のタイプに対応したページが上記プロパティシート７１に追加され、上記ドライバＵＩモジュール７２が提供するページに何ら変更を加えることなく所望の機能を追加することが可能になる。
【００８０】
図１１（ｂ）は、このようにして提供されるプリンタプロパティページに対してプリンタ独自の機能を実現するページの一例として、利用者所望にステータスモニタ６４を起動するためのユーティリティページを示している。同図において、ステータスモニタ６４を起動するためのページは、本実施形態においては上記レジストリにタイプ１として登録されており、ステータスモニタ６４を起動するためのＳＴＭボタンと当該ステータスモニタ６４を表示する条件などを設定するモニタ設定ボタンとが設けられている。尚、レジストリにタイプ２として登録されているページにおいては、さらに用紙登録ユーティリティボタンを追加して表示するようになっており、複数の給紙装置を装着可能なプリンタに対する設定を行うことが可能になっている。
【００８１】
むろんここで、タイプはこれらの２つのみである必要はなく、将来のプリンタ機能の拡張に対応させるためなどにタイプを増やすことは可能である。また、ＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュール７３を起動するときにはレジストリを参照することが可能であるので当該レジストリの参照を通じて種々の処理を行うことができる。例えば、各言語に対するローカライズ対応をすることが可能である。すなわち、各言語に対応するリソースをＤＬＬモジュールとして実行モジュールとは別に用意し、ＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュールがレジストリ情報を利用して現在の環境にあったりソースＤＬＬを使用するように構成すればよい。
【００８２】
このように、本実施形態においては、クライアント５０においてプリンタ４０ａの制御指示を出したときおよび利用者がプリンタのプロパティシートのユーティリティページにてＳＴＭボタンをクリックしたときにステータスモニタ６４が起動する。図１１はかかる状況を、主にクライアント５０のディスプレイ１８に表示される画面を示しつつ動作の流れを概念的に示したものである。図１１（ａ）は種々のアプリケーションを使用して文書を作成した後、当該文書を印刷する際に表示される印刷指示画面である。同図（ａ）には印刷文書の書式を決定するマージン値入力ボックスやフォント種，フォントのポイント数等を入力する入力ボックスが設けられているとともに、設定後に印刷開始を指示するための「ＯＫ」ボタンが設けられている。
【００８３】
すなわち、利用者が上記クライアント５０のマウス３２を操作して「ＯＫ」ボタンをクリックすると、上記ステータスモニタ６４はクライアント５０においてバックグラウンドで起動し、エラーが発生するなど利用者にステータスを通知する必要がある時のみに上記クライアント５０のディスプレイ１８に図１１（ｃ）に示すステータスモニタ画面を表示する。一方、利用者がプリンタのプロパティーシートを表示させ、ユーティリティページで「ＳＴＭ」ボタンをクリックすると同図（ｃ）に示すステータスモニタ画面が表示される。
【００８４】
以下、上記図１１（ａ）に示す前者の場合の各部の動作を、サーバ１０のＯＳ２０およびクライアント５０のＯＳ６０の双方がＷＩＮＤＯＷＳ９５である場合（以下（例−１）とする）とサーバ１０のＯＳ２０がＷＩＮＤＯＷＳＮＴであってクライアント５０のＯＳ６０がＷＩＮＤＯＷＳ９５である場合（以下（例−２）とする）とに分けて説明する。また、（例−１）の場合は図１２（ａ）に示すようにＵＴＰケーブル３３にクライアント５０を含む複数のクライアントが接続され、さらにサーバ１０とプリンタ４０ａとがＵＴＰケーブル３３に接続されている。（例−２）の場合は図１２（ｂ）に示すようにＵＴＰケーブル３３にクライアント５０を含む複数のクライアントおよびサーバ１０が接続されているようなネットワーク構成であって、プリンタ４０ｂがサーバ１０に対してローカル接続されている。さらに、いずれの場合もサーバ１０のユーザ名がＡ，マシン名がＰＣ１、クライアント５０のユーザ名がＢ，マシン名がＰＣ２であるとし、ポート名は「￥￥Ｅｐｓｏｎ＿ｌｐｒ￥１９２．１６８．ｘ．ｘ」であり、プリンタ名は「ＬＱ−５８０」であるとする。
【００８５】
（例−１）の場合、上述のように利用者が図１１（ａ）に示す画面で「ＯＫ」ボタンをクリックすると、上記クライアント５０のプリンタドライバ６１が印刷データとともにＪｏｂＩｎｆｏデータ等の所定のデータを上記１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介して双方向通信にてサーバ１０に対して出力する。サーバ１０では当該双方向通信によって印刷データ等を受信するとプリンタドライバ２１がプリンタ４０ａに対して当該印刷データに基づく印刷をするように制御処理を開始する。
【００８６】
このとき、ＴＣＰ／ＩＰ印刷モジュール２１ａは上記ステップＳ１００にてＳｔａｒｔＤｏｃＰｏｒｔ関数が実行されたことに基づいて印刷が開始されたことを検出する。そして、ステップＳ１２０においてＪｏｂＩｎｆｏデータとしてユーザ名とマシン名とポート名とを抽出し、ステップＳ１３０にて印刷通知モジュール２２を起動してこれらのユーザ名とマシン名とポート名とを同印刷通知モジュール２２に出力する。
【００８７】
起動された印刷通知モジュール２２は、ステップＳ２１０でレジストリ２２ａを参照し、同レジストリ２２ａに記載されているモジュールを実行する。ここで、起動モジュール２３には印刷通知モジュール２２がステップＳ２００で取得してステップＳ２２０で出力する上記ユーザ名とマシン名とポート名とが入力される。これらの入力データを用いて起動モジュール２３はクライアント５０にプリンタ４０ａの制御処理開始を通知し認識させるための処理を行う。
【００８８】
ここで、本（例−１）の場合は図１３に示すようにＪｏｂＩｎｆｏのマシン名はＰＣ２でありサーバ１０のマシン名はＰＣ１であって、ステップＳ３３０でマシン名が一致すると判別されない。従って、ステップＳ３７０にてマシン名がＰＣ２であるクライアント５０に対して１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介して双方向通信を行い、ＪｏｂＩｎｆｏデータに基づくユーザ名とマシン名とポート名を出力する。ここでは、通信相手がＰＣ２であると判別されているので、図１２（ａ）に示すようにコンピュータ名を「ＰＣ２」にして宛先特定送信方式で通信を行う。
【００８９】
クライアント５０においては、エージェント６２が常駐しているので、当該宛先特定送信方式にかかるパケットがＵＴＰケーブル３３を介して送信された後に当該パケットの受信を検出する。そして、ステップＳ４１０にて当該パケットがブロードキャストではないことを判別してステップＳ４２０〜ステップＳ４３０でＳＴＭ起動モジュール６３を起動してポート名を出力する。尚、この（例−１）ではサーバ１０のＯＳ２０に組み込まれるモジュールはＴＣＰ／ＩＰ印刷モジュール２１ａであるので、ＪｏｂＩｎｆｏデータに含まれるデータはプリンタ名ではなくポート名である。
【００９０】
従って、ＳＴＭ起動モジュール６３ではステップＳ５１０にてプリンタ名を取得したとは判別せずに、ステップＳ５２０〜Ｓ５８０に示すプリンタ４０ａとの通信処理を行う。すなわち、ＪｏｂＩｎｆｏデータに含まれるポート名は元々プリンタ４０ａを指定したものであるので、当該ポート名「￥￥Ｅｐｓｏｎ＿ｌｐｒ￥１９２．１６８．ｘ．ｘ」を使用して１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介して双方向通信を行うとプリンタ４０ａと通信を行うことになる。この結果、プリンタ４０ａのモデルＩＤが取得される。その後、ステップＳ５４０でクライアント５０のレジストリ６５を参照し、ステップＳ５５０にて通信にて取得したモデルＩＤおよびポート名の組とクライアント５０のレジストリ６５に記載されたモデルＩＤおよびポート名の組で一致するものを検出する。
【００９１】
本（例−１）ではこれらが一致し、その結果、プリンタ４０ａのステータスモニタ６４がバックグラウンドで起動する。従って、上記利用者が図１１（ａ）に示す画面で「ＯＫ」をクリックしたことによって開始した印刷処理でエラーが発生した場合には、同図１１（ｃ）に示すステータスモニタ画面が表示され、エラーの発生やエラー原因等をクライアント５０を操作する利用者に認識させる。
【００９２】
（例−２）の場合、上述のように利用者が図１１（ａ）に示す画面で「ＯＫ」ボタンをクリックすると、上記クライアント５０のプリンタドライバ６１が印刷データとともにＪｏｂＩｎｆｏデータ等の所定のデータを上記１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介して双方向通信にてサーバ１０に対して出力する。サーバ１０では当該双方向通信によって印刷データ等を受信するとプリンタドライバ２１がプリンタ４０ｂに対して当該印刷データに基づく印刷をするように制御処理を開始する。
【００９３】
このとき、ランゲージモニタ２１ｂは上記ステップＳ１００にてＳｔａｒｔＤｏｃＰｏｒｔ関数が実行されたことに基づいて印刷が開始されたことを検出する。そして、ステップＳ１２０においてＪｏｂＩｎｆｏデータとしてユーザ名とマシン名とプリンタ名とを抽出し、ステップＳ１３０にて印刷通知モジュール２２を起動してこれらのユーザ名とマシン名とプリンタ名とを同印刷通知モジュール２２に出力する。
【００９４】
起動された印刷通知モジュール２２は、ステップＳ２１０でレジストリ２２ａを参照し、同レジストリ２２ａに記載されているモジュールを実行する。ここで、起動モジュール２３には、印刷通知モジュール２２がステップＳ２００で取得してステップＳ２２０で出力する上記ユーザ名とマシン名とプリンタ名とが入力される。これらの入力データを用いて起動モジュール２３はクライアント５０にプリンタ４０ｂの制御処理開始を通知し認識させるための処理を行う。
【００９５】
ここで、本（例−２）の場合は図１３に示すようにＪｏｂＩｎｆｏのマシン名はＰＣ１でありサーバ１０のマシン名はＰＣ１であるので、ステップＳ３３０で両者が一致すると判別される。従って、ステップＳ３４０にてＪｏｂＩｎｆｏのユーザ名Ｂとサーバ１０のユーザ名Ａとが比較され、ステップＳ３５０で両者が一致していないと判別される。この結果、全てのクライアントに対して１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ１９ｃ，ＵＴＰケーブル３３を介してブロードキャストパケットが出力される。このブロードキャストパケットは図１２（ｂ）に示すようにサーバ１０の送信用メールスロットのコンピュータ名に「＊」を指定することによって行われ、ＪｏｂＩｎｆｏデータに基づくユーザ名とマシン名とプリンタ名が含まれている。
【００９６】
全てのクライアントにおいてエージェント６２が常駐しており、受信用メールスロットは図１２（ｂ）に示すようにコンピュータ名が「．」である。従って、、当該ブロードキャスト方式にかかるパケットがＵＴＰケーブル３３を介して送信された後には、全てのクライアントで当該パケットを受信する。そして、ステップＳ４１０にて当該パケットがブロードキャストであることが判別されるが、ステップＳ４４０〜ステップＳ４６０の判別によってクライアントのユーザ名がＢであるもの、すなわち、クライアント５０のみがステップＳ４２０以降の処理を行う。すなわち、これらのステップＳ４２０〜ステップＳ４３０でＳＴＭ起動モジュール６３を起動してプリンタ名を出力する。
【００９７】
この（例−２）ではサーバ１０のプリンタドライバ２１に組み込まれるモジュールはランゲージモニタ２１ｂであるので、ＪｏｂＩｎｆｏデータに含まれるデータはポート名ではなくプリンタ名である。従って、ＳＴＭ起動モジュール６３ではステップＳ５１０にてプリンタ名を取得したか否かを判別し、ステップＳ５８０で当該プリンタ名「ＬＱ−５８０」であるプリンタ４０ｂのステータスモニタ６４がバックグラウンドで起動する。従って、上記利用者が図１１（ａ）に示す画面で「ＯＫ」をクリックしたことによって開始した印刷処理でエラーが発生した場合には、同図１１（ｃ）に示すステータスモニタ画面が表示され、エラーの発生やエラー原因等をクライアント５０を操作する利用者に認識させる。
【００９８】
このように、本発明においては、クライアントからサーバに制御指示が与えられたことを検出し、サーバは制御指示を検出したときにクライアントに対して制御処理が開始されたことを通知する。従って、クライアントにおいては当該制御処理開始通知がなされることをもって当該クライアントはサーバにおいて制御処理が開始されたことを認識することができる。このクライアントにおける制御処理開始の認識は、クライアントからサーバに対して制御指示を与える際に行う処理に対して何ら影響を与えない。また、クライアントにおいて上記認識後には任意のモジュールを起動するなどして所望の機能を実行することが可能である。従って、デバイスドライバキットで作成したドライバであっても種々の周辺機器用の個別機能に対応することが可能である。
【図面の簡単な説明】
【図１】サーバのハードウェア構成の概略図である。
【図２】サーバおよびクライアントの構成の要部を示す図である。
【図３】サーバの他の構成における要部を示す図である。
【図４】ＴＣＰ／ＩＰ印刷モジュールあるいはランゲージモニタが行う処理のフローチャートである。
【図５】印刷通知モジュールのフローチャートである。
【図６】起動モジュールのフローチャートである。
【図７】エージェントのフローチャートである。
【図８】起動モジュールが通信を行う際の詳細を示すフローチャートである。
【図９】エージェントが通信を行う際の詳細を示すフローチャートである。
【図１０】ＳＴＭ起動モジュールのフローチャートである。
【図１１】クライアントのディスプレイに表示される画面に基づいて動作の流れを概念的示したである。
【図１２】ネットワーク構成および通信方式を示す図である。
【図１３】ユーザ名，マシン名，ポート名（プリンタ名）のＯＳによる違いを示す図である。
【図１４】パケットの構造体を示す図である。
【図１５】ＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュールの動作を示す図である。
【符号の説明】
１０…サーバ
１１…ＣＰＵ
１２…システムバス
１３…ＲＯＭ
１４…ＲＡＭ
１５…ハードディスクドライブ
１６…フロッピーディスクドライブ
１６ａ…フロッピーディスク
１７…ＣＤ−ＲＯＭドライブ
１７ａ…ＣＤ−ＲＯＭ
１８…ディスプレイ
１９ａ…シリアル通信用Ｉ／Ｏ
１９ｂ…パラレル通信用Ｉ／Ｏ
１９ｃ…１０ＢＡＳＥ−Ｔ用Ｉ／Ｏ
２０…ＯＳ
２１ａ…ＩＰ印刷モジュール
２１ｂ…ランゲージモニタ
２２…印刷通知モジュール
２２ａ…レジストリ
２３…起動モジュール
３１…キーボード
３２…マウス
３３…ＵＴＰケーブル
３４…パラレルケーブル
４０ａ，ｂ…プリンタ
５０…クライアント
６０…ＯＳ
６１…プリンタドライバ
６２…エージェント
６３…ＳＴＭ起動モジュール
６４…ステータスモニタ
６５…レジストリ
７１…プロパティシート
７２…ドライバＵＩモジュール
７３…ＳｈｅｌｌＥｘｔｅｎｓｉｏｎモジュール

Claims (24)

1. サーバとクライアントとを双方向通信可能に接続させ、クライアントにて所定の制御処理を開始したことを当該クライアントで認識するための制御処理開始認識プログラムを記録した媒体であって、
   上記サーバ側において、
   クライアントで実行される周辺機器ドライバであって、クライアントにおける周辺機器のステータス監視モジュールと連動する機能を備えていない周辺機器ドライバから上記双方向通信によってサーバに周辺機器の制御指示が与えられたことを検出する制御指示検出機能と、
   同制御指示検出機能がクライアントからの制御指示を検出したときに上記双方向通信によってクライアントに対して当該制御指示に基づく上記周辺機器の制御処理が開始されたことを通知する制御処理開始通知機能とを実現させ、
   上記クライアント側において、
   上記双方向通信によって上記制御処理開始通知機能による制御処理開始通知がなされたときに上記周辺機器の制御処理を開始したことを認識し、上記周辺機器のステータスを監視するためのステータス監視モジュールを起動する制御処理開始認識機能とを実現させることを特徴とする制御処理開始認識プログラムを記録した媒体。
2. 上記請求項１に記載の制御処理開始認識プログラムを記録した媒体であって、
   上記サーバは双方向通信を介して周辺機器を制御可能であり、
   同サーバ側において、
   上記制御指示検出機能では上記クライアントからの周辺機器の制御指示を検出したときに上記制御指示を与えたクライアントを特定するための情報を抽出可能であり、
   上記制御処理開始通知機能では上記抽出した情報に基づいて上記制御指示を与えたクライアントに対して上記抽出情報を出力し、
   上記クライアント側において、
   上記制御処理開始認識機能では上記出力される抽出情報を受信可能であり、同抽出情報に基づいて上記周辺機器の制御が開始されたことを認識することを特徴とする制御処理開始認識プログラムを記録した媒体。
3. 上記請求項２に記載の制御処理開始認識プログラムを記録した媒体において、
   上記サーバ側の上記制御指示検出機能では制御対象となっている周辺機器を特定するための情報を抽出し、
   上記クライアント側の上記制御処理開始認識機能では制御処理開始を認識したときに上記抽出情報に基づいて制御対象となる周辺機器を判別し、判別された制御対象周辺機器用のモジュールを起動することを特徴とする制御処理開始認識プログラムを記録した媒体。
4. 上記請求項１〜請求項３のいずれかに記載の制御処理開始認識プログラムを記録した媒体において、
   上記制御指示検出機能は、上記サーバ中の汎用関数実行時の処理情報に基づいて制御指示があったことを検出することを特徴とする制御処理開始認識プログラムを記録した媒体。
5. 上記請求項４に記載の制御処理開始認識プログラムを記録した媒体において、
   上記制御指示検出機能は、上記処理情報からユーザ名とマシン名と周辺機器名とポート名とのいずれかまたは組み合わせを抽出することを特徴とする制御処理開始認識プログラムを記録した媒体。
6. 上記請求項１〜請求項５のいずれかに記載の制御処理開始認識プログラムを記録した媒体において、
   上記サーバ側で、上記制御指示検出機能によって上記制御処理開始を検出したときに利用者所望の処理が実行されるように設定する実行処理設定機能を実現させることを特徴とする制御処理開始認識プログラムを記録した媒体。
7. 上記請求項２〜請求項６のいずれかに記載の制御処理開始認識プログラムを記録した媒体において、
   上記制御処理開始通知機能では、上記抽出した所定の情報に基づいて特定のクライアントを通信相手とするパケットの出力と不特定のクライアントを通信相手とするパケットの出力とのいずれかを実行することを特徴とする制御処理開始認識プログラムを記録した媒体。
8. 上記請求項３〜請求項７のいずれかに記載の制御処理開始認識プログラムを記録した媒体において、
   上記制御処理開始認識機能では、上記抽出情報に含まれるポート名を使用して制御対象周辺機器と双方向通信を行って同制御対象周辺機器名を判別可能であることを特徴とする制御処理開始認識プログラムを記録した媒体。
9. サーバとクライアントとを双方向通信可能に接続させ、クライアントにて所定の制御処理を開始したことを当該クライアントで認識するための制御処理開始認識システムであって、
   上記サーバ側において、
   クライアントで実行される周辺機器ドライバであって、クライアントにおける周辺機器のステータス監視モジュールと連動する機能を備えていない周辺機器ドライバから上記双方向通信によってサーバに周辺機器の制御指示が与えられたことを検出する制御指示検出手段と、
   同制御指示検出手段がクライアントからの制御指示を検出したときに上記双方向通信によってクライアントに対して当該制御指示に基づく上記周辺機器の制御処理が開始されたことを通知する制御処理開始通知手段とを具備し、
   上記クライアント側において、
   上記双方向通信によって上記制御処理開始通知手段による制御処理開始通知がなされたときに上記周辺機器の制御処理を開始したことを認識し、上記周辺機器のステータスを監視するためのステータス監視モジュールを起動する制御処理開始認識手段とを具備することを特徴とする制御処理開始認識システム。
10. 上記請求項９に記載の制御処理開始認識システムであって、
    上記サーバは双方向通信を介して周辺機器を制御可能であり、
    同サーバ側において、
    上記制御指示検出手段では上記クライアントからの周辺機器の制御指示を検出したときに上記制御指示を与えたクライアントを特定するための情報を抽出可能であり、
    上記制御処理開始通知手段では上記抽出した情報に基づいて上記制御指示を与えたクライアントに対して上記抽出情報を出力し、
    上記クライアント側において、
    上記制御処理開始認識手段では上記出力される抽出情報を受信可能であり、同抽出情報に基づいて上記周辺機器の制御が開始されたことを認識することを特徴とする制御処理開始認識システム。
11. 上記請求項１０に記載の制御処理開始認識システムにおいて、
    上記サーバ側の上記制御指示検出手段では制御対象となっている周辺機器を特定するための情報を抽出し、
    上記クライアント側の上記制御処理開始認識手段では制御処理開始を認識したときに上記抽出情報に基づいて制御対象となる周辺機器を判別し、判別された制御対象周辺機器用のモジュールを起動することを特徴とする制御処理開始認識システム。
12. 上記請求項９〜請求項１１のいずれかに記載の制御処理開始認識システムにおいて、
    上記制御指示検出手段は、上記サーバ中の汎用関数実行時の処理情報に基づいて制御指示があったことを検出することを特徴とする制御処理開始認識システム。
13. 上記請求項１２に記載の制御処理開始認識システムにおいて、
    上記制御指示検出手段は、上記処理情報からユーザ名とマシン名と周辺機器名とポート名とのいずれかまたは組み合わせを抽出することを特徴とする制御処理開始認識システム。
14. 上記請求項９〜請求項１３のいずれかに記載の制御処理開始認識システムにおいて、
    上記サーバ側で、上記制御指示検出手段によって上記制御処理開始を検出したときに利用者所望の処理が実行されるように設定する実行処理設定手段を具備することを特徴とする制御処理開始認識システム。
15. 上記請求項１０〜請求項１４のいずれかに記載の制御処理開始認識システムにおいて、
    上記制御処理開始通知手段では、上記抽出した所定の情報に基づいて特定のクライアントを通信相手とするパケットの出力と不特定のクライアントを通信相手とするパケットの出力とのいずれかを実行することを特徴とする制御処理開始認識システム。
16. 上記請求項１１〜請求項１５のいずれかに記載の制御処理開始認識システムにおいて、
    上記制御処理開始認識手段では、上記抽出情報に含まれるポート名を使用して制御対象周辺機器と双方向通信を行って同制御対象周辺機器名を判別可能であることを特徴とする制御処理開始認識システム。
17. サーバとクライアントとを双方向通信可能に接続させ、クライアントにて所定の制御処理を開始したことを当該クライアントで認識するための制御処理開始認識方法であって、
    クライアントで実行される周辺機器ドライバであって、クライアントにおける周辺機器のステータス監視モジュールと連動する機能を備えていない周辺機器ドライバから上記双方向通信によってサーバに周辺機器の制御指示が与えられたことを検出する制御指示検出工程と、
    同制御指示検出工程がクライアントからの制御指示を検出したときに上記双方向通信によってクライアントに対して当該制御指示に基づく上記周辺機器の制御処理が開始されたことを通知する制御処理開始通知工程と、
    上記双方向通信によって上記制御処理開始通知工程による制御処理開始通知がなされたときに上記周辺機器の制御処理を開始したことを認識し、上記周辺機器のステータスを監視するためのステータス監視モジュールを起動する制御処理開始認識工程とを具備することを特徴とする制御処理開始認識方法。
18. 上記請求項１７に記載の制御処理開始認識方法であって、
    上記サーバは双方向通信を介して周辺機器を制御可能であり、
    上記制御指示検出工程では上記クライアントからの周辺機器の制御指示を検出したときに上記制御指示を与えたクライアントを特定するための情報を抽出可能であり、
    上記制御処理開始通知工程では上記抽出した情報に基づいて上記制御指示を与えたクライアントに対して上記抽出情報を出力し、
    上記制御処理開始認識工程では上記出力される抽出情報を受信可能であり、同抽出情報に基づいて上記周辺機器の制御が開始されたことを認識することを特徴とする制御処理開始認識方法。
19. 上記請求項１８に記載の制御処理開始認識方法において、
    上記制御指示検出工程では制御対象となっている周辺機器を特定するための情報を抽出し、
    上記制御処理開始認識工程では制御処理開始を認識したときに上記抽出情報に基づいて制御対象となる周辺機器を判別し、判別された制御対象周辺機器用のモジュールを起動することを特徴とする制御処理開始認識方法。
20. 上記請求項１７〜請求項１９のいずれかに記載の制御処理開始認識方法において、
    上記制御指示検出工程は、上記サーバ中の汎用関数実行時の処理情報に基づいて制御指示があったことを検出することを特徴とする制御処理開始認識方法。
21. 上記請求項２０に記載の制御処理開始認識方法において、
    上記制御指示検出工程は、上記処理情報からユーザ名とマシン名と周辺機器名とポート名とのいずれかまたは組み合わせを抽出することを特徴とする制御処理開始認識方法。
22. 上記請求項１７〜請求項２１のいずれかに記載の制御処理開始認識方法において、
    上記制御指示検出工程によって上記制御処理開始を検出したときに利用者所望の処理が実行されるように設定する実行処理設定工程を具備することを特徴とする制御処理開始認識方法。
23. 上記請求項１８〜請求項２２のいずれかに記載の制御処理開始認識方法において、
    上記制御処理開始通知工程では、上記抽出した所定の情報に基づいて特定のクライアントを通信相手とするパケットの出力と不特定のクライアントを通信相手とするパケットの出力とのいずれかを実行することを特徴とする制御処理開始認識方法。
24. 上記請求項１９〜請求項２３のいずれかに記載の制御処理開始認識方法において、
    上記制御処理開始認識工程では、上記抽出情報に含まれるポート名を使用して制御対象周辺機器と双方向通信を行って同制御対象周辺機器名を判別可能であることを特徴とする制御処理開始認識方法。

Images