JP4164479B2 - 印刷制御プログラム、及び、処理方法、及び、記憶媒体、及び、情報処理装置、並びに、印刷システム - Google Patents

Description

本発明は、印刷システムにおいて利用されるプリントサーバの負荷を、クライアントの印刷システムの一定の使い勝手を維持可能にしたまま、軽減することのできる仕組みに関する。

従来から知られている印刷システムにおいてプリントサーバが利用される形態が一般的に行なわれている。そして、印刷システムの安定化のためにも、プリントサーバの負荷を軽減することが望まれる。そして、プリントサーバの処理負荷を軽減する技術として特許文献１が知られている。

この特許文献１には、プリントサーバとクライアントコンピュータ（クライアントと呼ぶ）からなる印刷システムにおいて、プリントサーバによってクライアントからの要求の数をカウントし、要求の数を所定の制限数にし、該制限数を超えていれば要求を受付けれない旨をクライアントに通知し、サーバの処理負荷を抑制することが開示されている。
特開２００２−３５１６２９号

しかしながら特許文献１によれば、印刷システムにおいて、プリントサーバ側でクライアントからの要求を受付けるか否かを判定しているので、あるクライアントが多数の要求を発行した場合に、他のクライアントがプリントサーバを利用できなくなるという問題がある。

また、特許文献１の仕組みにより、クライアントからの要求を拒絶するにしても、クライアント数が多くなり要求が増えるに従い、プリントサーバの拒絶の処理による負荷が増大してしまい、結果として、プリントサーバに、本来の目的とではない処理に多くの負荷をかけてしまうという問題点があった。

また、プリントサーバに高付加価値な各種機能が盛り込まれることによって、クライアントから様々な種類の処理要求が想定されるようになり、プリントサーバの負荷を適切に軽減する必要性が一層でてきた。

特許文献１のように、単にプリントサーバ側で変化する要求数を監視し該要求数を新たな要求を受付けるか否かのパラメータにする場合では、同じ１０個の要求の総負荷を計算しても、その要求の種類によってプリントサーバの処理負荷に大きな差異が生じ、決して適切な負荷評価ではないという問題がある。

そして、上述のような問題点の結果、プリントサーバの動作が不安定になり、信頼性の低い印刷システムになってしまうという問題点がある。

本発明の印刷制御プログラムは、印刷制御装置へ複数種類の処理の要求を発行する情報処理装置において実行される印刷制御プログラムであって、情報処理装置から印刷制御装置に発行され且つ前記印刷制御装置が応答していない要求の各々の負荷を認識する負荷認識ステップと、前記負荷認識ステップにおいて認識された前記要求の各々の負荷に基づき、前記印刷制御装置の総負荷を計算する計算ステップと、前記計算ステップにおいて計算された総負荷に基づいて情報処理装置からの要求の発行を抑制する抑制ステップとを有することを特徴とする。
本発明の処理方法は、印刷制御装置へ複数種類の処理の要求を発行する情報処理装置における処理方法であって、情報処理装置から発行され且つ前記印刷制御装置が応答していない要求の各々の負荷を認識する負荷認識ステップと、前記負荷認識ステップにおいて認識された前記要求の各々の負荷に基づき、前記印刷制御装置の総負荷を計算する計算ステップと、前記計算ステップにおいて計算された総負荷に基づいて情報処理装置からの要求の発行を抑制する抑制ステップとを有することを特徴とする。
本発明の情報処理装置は、印刷制御装置へ複数種類の処理の要求を発行する発行手段を備えた情報処理装置であって、情報処理装置から発行され且つ前記印刷制御装置が応答していない要求の各々の負荷を認識する負荷認識手段と、前記負荷認識手段において認識された前記要求の各々の負荷に基づき、前記印刷制御装置の総負荷を計算する計算手段と、前記計算手段により計算された総負荷に基づいて情報処理装置からの要求の発行を抑制する抑制手段とを有することを特徴とする。
本発明の印刷システムは、印刷制御装置と、該印刷制御装置へ複数種類の処理の要求を発行する情報処理装置とからなる印刷システムであって、情報処理装置から発行され且つ前記印刷制御装置が応答していない要求の各々の負荷を認識する負荷認識手段と、前記負荷認識手段において認識された前記要求の各々の負荷に基づき、前記印刷制御装置の総負荷を計算する計算手段と、前記計算手段により計算された総負荷に基づいて情報処理装置からの要求の発行を抑制する抑制手段とを有することを特徴とする。

或いは、情報処理装置より印刷制御装置に発行された複数の要求で前記印刷制御装置から未応答の複数の要求の個々の負荷を認識し、該認識された前記個々の負荷に基づき複数の要求の負荷を計算する仕組みを提供する。

本発明によって、
情報処理装置と通信可能な印刷制御装置の負荷を適切な評価で抑えつつ、且つ、ユーザの印刷に係る使い勝手の一定のレベルを確保でき、且つ、信頼性高い印刷システムを構築することができる。

（実施例１）
以下、添付の図面を参照して本発明の好適な実施形態について説明する。

図１は、本発明を適用可能な情報処理システムの構成を説明するブロック図である。なお、本システムにおけるクライアントコンピュータは、１台、または複数台接続されていることを仮定している。

図１において、１０２、１０３、１０４はクライアントコンピュータ（クライアント）としての情報処理装置であり、イーサネット（登録商標）などのネットワークケーブルによって、ネットワーク１０６に接続される。クライアント装置１０２〜１０４の各々は、アプリケーションプログラム等の各種のプログラムを実行可能であり、印刷データをプリンタに対応するプリンタ言語に変換する機能を有するプリンタドライバを搭載している。１０１は本実施形態のサーバ（以下、プリントサーバと呼ぶ）であり、ネットワークケーブルによって、ネットワーク１０６に接続される。プリントサーバ１０１は、ネットワークプリンタ１０５に送出する印刷用データを蓄積したり、ネットワーク１０６の使用状態を監視したり、ネットワーク１０６に接続されている複数のプリンタを管理したり、後述の図６において説明するように印刷ジョブのスケジューリング処理を行なったり、印刷制御装置として機能する。

なお、クライアント１０２〜１０４とプリントサーバ１０１は、一般的な情報処理装置にそれぞれ異なる制御を行う印刷制御プログラムを実行可能に格納することにより構成することができる。

また、プリントサーバ１０１として一般的な情報処理装置を用いた場合、クライアント１０２〜１０４の機能を同時に持たせることもできる。本実施形態におけるプリントサーバ１０１は、さらにクライアント１０２、１０３、１０４から出力された印字データを含む印刷ジョブを格納してプリンタに印刷させたり、または、クライアント１０２、１０３、１０４から印字データを含まない印刷ジョブを受け取り、クライアント１０２、１０３、１０４の印刷順序を管理し、印刷順序になったクライアントに対して印字データを含む印刷ジョブの送信許可を通知したり、ネットワークプリンタ１０５のステータスや印刷ジョブの各種情報を取得し、クライアント１０２、１０３、１０４に通知したりする印刷制御装置としての機能を揃えている。

１０５はネットワークプリンタであり、不図示のネットワークインタフェースを介してネットワーク１０６と接続されている。ネットワークプリンタ１０５は、クライアントコンピュータ１０２〜１０４から送信される印字データを含む印刷ジョブを解析して１ページずつドットイメージに変換して、１ページ毎に印刷する。またネットワークプリンタ１０５は、ＩＳＯ１０１７５（ＤＰＡ：Ｄｏｃｕｍｅｎｔ Ｐｒｉｎｔｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ）で規定されている印刷ジョブの管理機能をプリントサーバ１０１或いはクライアント１０２〜１０４へ提供する事が可能である。

また、プリントサーバ１０１で実施される機能或いはその一部のサーバ機能を、ネットワークプリンタ１０５或いはそのネットワークインタフェースカード上に持たせる構成としても良い。つまり、以下に説明するプリントサーバ１０１とは、特に図１のようなネットワークプリンタ１０５とは別体形態に限定されるものではなく、ネットワークプリンタ１０５の一部（ネットワークインタフェースカード）であっても良い。

１０６はネットワークであり、クライント１０２、１０３、１０４、サーバ１０１、ネットワークプリンタ１０５等を接続するものであり、無線でも優先でも良い。

また、図中ではネットワークプリンタ１０５は１台しか示されていないが実際には複数台のネットワークプリンタが接続されていてもよい。更に、このネットワークプリンタ１０５は、後述するデバイス６１４に相当するものであるが、このデバイス６１４には、電子写真方式のレーザービームプリンタ／複写機／デジタル複合機／ファクシミリや、インクジェット方式のプリンタ／デジタル複合機など様々な記録方式の画像形成装置が適用されることはいうまでもない。

図２は、本実施形態のクライアント１０２〜１０４及びプリントサーバ１０１として利用可能な情報処理装置の構成を説明するブロック図である。上述したように、クライント１０２、１０３、１０４及びプリントサーバ１０１は同様のハードウェア構成を有した情報処理装置によって実現可能である。以下、図２をクライアントとサーバの構成を説明するブロック図として説明する。

図２において、２００は情報処理装置の制御手段であるＣＰＵであり、ハードディスク（ＨＤ）２０５に格納されているアプリケーションプログラム、プリンタドライバプログラム、ＯＳや本発明のネットワークプリンタ制御プログラム等を実行し、ＲＡＭ２０２にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。

２０１はＲＯＭであり、内部には、基本Ｉ／Ｏプログラム等のプログラム、文書処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。２０２は一時記憶手段を提供するＲＡＭであり、ＣＰＵ２００の主メモリ、ワークエリア等として機能する。２０３はフレキシブルディスク（ＦＤ）ドライブであり、後述する図５に示すようにＦＤドライブ２０３を通じて記憶媒体としてのＦＤ２０４に記憶されたプログラム等を本コンピュータシステムにロードすることができる。２０４は記憶媒体としてのフレキシブルディスク（ＦＤ）であり、コンピュータが読み取り可能なプログラムが格納された記憶媒体である。なお、記憶媒体としては、ＦＤに限らず、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＰＣカード、ＤＶＤ、ＩＣメモリカード、ＭＯ、メモリスティック等、任意の媒体を利用できる。

２０５は外部記憶装置の一つであり、大容量メモリとして機能するハードディスク（ＨＤ）である。ＨＤ２０５には、アプリケーションプログラム、プリンタドライバプログラム、ＯＳ、ネットワークプリンタ制御プログラム、関連プログラム等が格納されている。また、スプール手段であるスプーラはこのＨＤ２０５に確保される。なお、スプール手段は、クライアント１０２〜１０４ではクライアントスプーラのことであり、プリントサーバ１０１ではサーバスプーラのことである。また、プリントサーバ１０１では、クライアント１０２〜１０４から受けたジョブ情報を格納し、順序制御を行うためのテーブルもこの外部記憶装置（ＨＤ２０５）に生成されて格納される。

２０６は指示入力を行なうためのキーボードである。キーボード２０６を用いることにより、ユーザがクライアントコンピュータに対して、或いは、オペレータや管理者がプリントサーバに対して、デバイスの制御コマンドの命令等を入力指示する。なお、指示入力を行なうためにポインティングデバイス（不図示）を備えてもよい。

２０７はディスプレイであり、キーボード２０６から入力したコマンドや、プリンタの状態等を表示したりする。２０８はシステムバスであり、クライアントやプリントサーバであるコンピュータ内のデータの流れを司る。２０９はインタフェースであり、該インタフェース２０９を介して情報処理装置はネットワーク１０６と接続され、外部装置とのデータのやり取りを行うことが可能となる。

図３は、図２に示したＲＡＭ２０２のメモリマップの一例を示す図である。図３には、ＦＤ２０４に格納されている上記ネットワークプリンタ制御プログラムがＲＡＭ２０２にロードされ、実行可能となった状態のメモリマップが示されている。

本実施形態では、ＦＤ２０４からネットワークプリンタ制御プログラムおよび関連データを直接ＲＡＭ２０２にロードして実行させる例を示すが、これ以外にも、ＦＤ２０４からネットワークプリンタ制御プログラムを動作させる度に、既にネットワークプリンタ制御プログラムがインストールされているＨＤ２０５からＲＡＭ２０２にロードするようにしてもよい。また、本ネットワークプリンタ制御プログラムを記憶する媒体は、ＦＤ以外にＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＰＣカード、ＤＶＤ、ＩＣメモリカード等であってもよい。さらに、本ネットワークプリンタ制御プログラムをＲＯＭ２０１に記憶しておき、これをメモリマップの一部となすように構成し、直接ＣＰＵ２００で実行することも可能である。また、以上の各装置と同等の機能を実現するソフトウェアをもって、ハードウェア装置の代替として構成することもできる。

また、本ネットワークプリンタ制御プログラムのことを、簡単に印刷制御プログラムと呼ぶこともある。印刷制御プログラムは、クライアント１０２〜１０４において印刷ジョブの印刷先の変更を指示したり、印刷順序の変更を指示するための制御を行うプログラムを含む。また、印刷制御プログラムは、プリントサーバ１０１において、印刷ジョブの順序制御を行ったり、印刷ジョブの印刷終了や印刷先変更要求などを通知するためのプログラムを含んでいる。また、このような制御を行う本実施形態の印刷制御プログラムは、クライアント１０２〜１０４にインストールされるモジュールと、プリントサーバ１０１にインストールされるモジュールを別々に分けてもよい。或いは、一つの印刷制御プログラムが、実行される環境によりクライアント用として機能したり、またはプリントサーバ用として機能するようにしてもよい。あるいは一台のコンピュータに、クライアント用の機能を持つモジュールと、プリントサーバ用として機能するモジュールをともにインストールし、同時に、あるいは時分割で擬似的に平行動作させる構成をとることも可能である。

図３において、３０１は基本Ｉ／Ｏプログラムであり、本制御装置の電源がＯＮされたときに、ＨＤ２０５からＯＳがＲＡＭ２０２に読み込まれ、ＯＳの動作を開始させるＩＰＬ（イニシャルプログラムローデイング）機能などを有しているプログラムが入っている領域である。３０２はオペレーティングシステム（ＯＳ）、３０３はネットワークプリンタ制御プログラムであり、それぞれＲＡＭ２０２上に確保された領域に記憶される。３０４は関連データで、ＲＡＭ２０２上に確保される領域に記憶される。３０５はワークエリアで、ＣＰＵ２００が本実施形態のプリンタ制御プログラム（３０３）等を実行する際に利用される作業領域が確保されている。

図４は、図２に示したＦＤ２０４のメモリマップの一例を示す図である。図４において、４００は上記ＦＤ２０４のデータ内容であり、４０１はデータの情報を示すボリューム情報であり、４０２はディレクトリ情報、４０３は本実施形態で説明する印刷制御プログラムであるネットワークプリンタ制御プログラム、４０４はその関連データである。４０３のネットワークプリンタ制御プログラムは、実施形態で説明するフローチャートに基づいてプログラム化したものであり、本実施例では、クライアント、サーバ共、同様の構成をとっている。

図５は、図２に示したＦＤドライブ２０３に対して挿入されるＦＤ２０４との関係を示す図であり、図２と同一のものには同一の符号を付してある。図５において、ＦＤ２０４には、図４で説明したように本実施形態で説明するネットワークプリンタ印刷制御プログラムおよび関連データが格納されている。

次に上に述べてきた各構成に基づき動作する印刷制御処理についての説明を行う。

次に、本プリントシステムのクライアントのネットワークプリンタ１０５へ印刷ジョブを送出するためのソフトウェア構成の一例について説明する。図６（ａ）は、クライアント１０２〜１０４におけるソフトウェア構成の一例を示す図である。夫々の構成間の矢印は、アプリケーションから発行された描画コマンドを含む印刷ジョブが、どのように処理されるかを示したものである。また、各ブロックで示されたソフトウェア構成は、図２のＣＰＵ２００によって実行され、所望の機能を実現する。

通常、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ（登録商標）などの一般的なアプリケーションプログラム６５１は印刷の指示を受け付けると、一連の描画コマンドをＯＳを介して生成する。ＯＳを介して生成された描画コマンドを受け取ったＰＤＬドライバ６５２は、生成した印刷ジョブを一連の描画コマンドに基づいてネットワークプリンタ１０５で解釈可能なＰＤＬファイルを含む印刷ジョブを生成する。なお、以下の説明ではＰＤＬドライバを例に説明を行うが、これに限定されるものではなく、例えば、ＢＤＬ（Ｂａｎｄ ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）や、圧縮ビットマップを作成するプリンタドライバ、或いは、アプリケーション及びＯＳによりプリンタドライバを介さずに印刷データを生成する形態などにも適用可能であることはいうまでもない。

ＰＤＬドライバ６５２は、プリントデバイスへ印刷ジョブを送信するためにスプーラ６５３に渡す。

ここではＯＳをＷｉｎｄｏｗｓ（登録商標）と仮定しているのでスプーラ６５３はウィンドウズ（登録商標）スプーラである。ただし、本発明を適用するコンピュータのＯＳはＷｉｎｄｏｗｓ（登録商標）に限定されるものではなく、描画命令を備えるものであれば他のＯＳも適用可能であることは言うまでもない。

スプーラ６５３は、ユーザがユーザインタフェースを介して選択し指示したポートモニタ６５４に印刷ジョブを渡して、ネットワークプリンタ１０５等のプリントデバイスに送信させる手順をとる（矢印ａ）。

ここでは、ユーザはあらかじめジョブ制御プリントサービス６５５に印刷データを転送するよう設定されたポートモニタ６５４（以降、ジョブ制御ポートモニタと略記）を指定して印刷を指示したものとして説明を進める。

また、プリンタドライバインタフェースを介して設定された用紙サイズ、ステープル指示等の印刷設定情報も、ジョブ制御ポートモニタ６５４に送信される。ジョブ制御ポートモニタ６５４はプリントサービス６５５（以降、ジョブ制御プリントサービスと称する）に送信する（矢印ｂ）。

ジョブ制御プリントサービス６５５は、転送された印刷ジョブ及びデバイスの状態を管理する機能を備える。また、プリントデバイスから通知されるデバイス状態やジョブの状態などの情報を管理したり、また、プリントデバイスに対して所定の命令をする機能も備える。これは、ネットワークプリンタ１０５を含む不図示の複数のネットワークプリンタのデバイス情報やジョブ情報を管理する機能に相当する。

そして、印刷データをネットワークプリンタ１０５に送信する前に、ネットワークプリンタ１０５が持つ印刷ジョブの順序管理機能に印刷の要求を発行し（矢印ｃ）、順序管理機能に基づき順番が到来した場合には、印刷制御装置（ネットワークプリンタ１０５或いはプリントサーバ１０１）からの印刷指示（矢印ｄ）により、ネットワークプリンタ１０５に印刷データを送信する（矢印ｅ）。

ネットワークプリンタ１０５は、印刷データの完了を確認すると印刷完了の通知をジョブ制御プリントサービス６５５に通知（矢印ｆ）したり、また、ネットワークプリンタ１０５の状態を通知する（矢印ｆ）。

プリントマネージャ６５７は、ユーザが、ジョブ制御プリントサービス６５５内部でプリントジョブがどのような状態にあるかを調べたり、プリントジョブを操作したりするためのユーザインタフェースを提供するプログラムである。プリントマネージャ６５７は、ジョブ制御プリントサービス６５５のソフトウェアのインタフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を介して、ジョブ制御プリントサービス６５５と情報・指示をやり取りしている。

そして、主に、ジョブ制御プリントサービス６５５が管理するネットワークプリンタ１０５の状態情報をイベントとして取得する機能を備える。イベントの通知の種別としては、トナー残量が少なくなった警告、クライアントとデバイスとの通信障害、メモリ不足、排紙トレイ満載などのエラー／警告情報の通知や、エラー状態から正常状態に復帰した正常情報の通知などが想定される。ここでのジョブ制御プリントサービス６５５はネットワークを介して通信可能な各デバイス（印刷装置）の印刷実行中、電力制御状態、障害情報（紙ジャム）等のステータスの通知を受け付ける機能を備える。

図６の（ｂ）は本発明を適用した情報処理装置上の制御プログラム３０３及び、関連データ３０４の論理構造を示すブロック図であり、上に説明した図６の（ａ）のジョブ制御プリントサービス６５５の機能の一部を示す図に相当する。

図６の（ｂ）において、６０１は要求管理部であり、サーバへ送信すべき要求と、サーバへ送信し応答を待っている要求を後述する図１０の管理情報を用いて識別可能に管理している。６０２は要求負荷取得部であり、要求管理部６０１からの指示に従い、個々の要求に応じた負荷を決定する機能を有する。

６２０は要求負荷テーブルであり、個々の要求に応じた負荷を決定するためのデータを提供する。要求負荷取得部６０２が要求負荷テーブル６２０を用いて要求に応じた負荷値を決定（認識）する方法については、図８を用いて後述する。

６０３は要求送信部である。実際にはＯＳのソケットライブラリーが呼び出されて、その後、ネットワークカードなどの通信制御部から要求のデータが送信される。本何れの実施例においても要求の送信とは、要求を送信させるよう上記ソケットライブラリーや通信制御部に送信を行なわせる処理を指すものとする。

また、本発明の実施例においては、サーバへ送信し応答を待っている要求のリストを送信済み要求情報６４０（図１１を用いて後述）として管理し、これら要求の数或いはその総負荷と、送信閾値情報６３０に保存されている閾値及びその適用条件（図９を用いて後述）に応じてサーバへの送信を停止即ち抑制するか、或いは、抑制されていた要求の送信再開を行う機能を有している。詳細については、図１６から図１９を用いて後述する。

尚、以下では抑制処理のことを停止の言葉を用いて説明する。この停止とは送信しようとした場合に送信を行なわない概念、送信自体を初めから行なわないようにする概念など、結果として要求が送信されないようにする様々な処理を含む。６０４は応答受信部であり、サーバからの応答或いはイベント通知を受信し、送信済み要求情報６４０を更新し、要求管理部６０１へ受信したデータをディスパッチする機能を有する。これについては図１８及び図１９を用いて後述する。

図７は、本発明の情報処理システムにおいいてクライアント１０２〜１０４及びプリントサーバ１０１或いはネットワークプリンタ１０５の間でやり取りされるメッセージの形式の一例を説明したものであり、要求を具体的に示したものである。

図においてｓｉｚｅ７０１はメッセージ全体のサイズを定義する。ｍａｇｉｃ ｎｕｍｂｅｒ７０２は、誤ってメッセージを受信した際などにサービスを識別するために利用される。ｔｙｐｅ７０３は、メッセージのタイプを規定する。本発明の実施例においては、少なくとも、「要求」、「応答」、の２種類があればよく、「イベント」や、その他のタイプを追加しても良い。

ここで、「要求」とはクライアントからプリントサーバへ処理を依頼するメッセージであり、「応答」とは、前記要求に応じてプリントサーバが処理をした結果を返すメッセージである。

「イベント」とは、プリントサーバからクライアントへ、プリントサーバで管理している情報の変更を非同期に通知するためのメッセージである。ｒｅｑｕｅｓｔＩＤ７０４は、各クライアントから発せられる全ての要求において各々識別可能に設定されるＩＤであり、「応答」或いは「イベント」受信時に、対応する「要求」と一致させるために利用される。

ａｐｉ７０５は、ネットワークプリンタ１０５に対するステータス応答要求などの、具体的な処理の内容（コマンド）を示す識別子であり、この番号に応じて実行する処理は事前にクライアントとプリントサーバの間で合意がされているものとする。ｐａｒａｍｅｔｅｒ７０６は処理の内容（コマンド）に応じた引数や応答されたデータを格納する領域であり、ａｐｉ毎に書式が規定され、メッセージ毎にその内容は異なる。

図８は、本発明を適用する情報処理システムにおける要求負荷テーブル６２０の一例を示す図であり、負荷総数（総負荷とも呼ぶ）を計算する上で、複数の要求の個々の負荷を認識するために用いられる。本テーブルは、後述のプログラム初期化処理（図１２〜図１４）において、ハードディスク２０５からＲＡＭ２０２に読み込まれる。本発明における要求負荷テーブル６２０はａｐｉ（コマンド）毎に負荷の値を定義する事が可能であり、また、全体としてのデフォルト値を設定する事ができる。

図８によれば、デフォルトが１ポイントであり、イベントの要求の予約を指示するＳｕｂｓｃｒｉｂｅＥｖｅｎｔ ａｐｉ（番号１）８０１が２ポイントと定義されている。複数のジョブの状態及び属性を個々に又はまとめて取得するＬｉｓｔＪｏｂｓ ａｐｉ（番号３）８０３は負荷が高いため１０ポイント、イベントの要求をキャンセルまたは停止するＵｎｓｕｂｓｃｒｉｂｅＥｖｅｎｔ ａｐｉ（番号２）８０２は０ポイントと定義されている。ＵｎｓｕｂｓｃｒｉｂｅＥｖｅｎｔ ａｐｉ（番号２）８０２を処理する事によりプリントサーバ側でイベントを通知する必要が無くなる効果があるため、要求の負荷は０ポイントとして定義されている。また、プリントサーバ側の要求に対する応答処理が減るので、ＵｎｓｕｂｓｃｒｉｂｅＥｖｅｎｔ ａｐｉ（番号２）８０２のキャンセル対象となる要求が行なわれる場合に認識される負荷の大きさにマイナス１を乗じた値をＵｎｓｕｂｓｃｒｉｂｅＥｖｅｎｔ ａｐｉ（番号２）８０２に対する負荷の大きさとしても良い。

要求負荷取得部６０２では、要求管理部６０１からａｐｉ番号を引数とした負荷取得要求を受けると、図８に定義されたテーブルを検索及び認識し、一致するａｐｉ番号が存在すれば、その負荷値を応答し、一致した番号が存在しなければデフォルトで定義された１ポイントを応答するものとする。

この図８の機能（構成）を備えることにより、要求数のみから、クライアントからの要求を受けつけるか否かをプリントサーバ側で判定する形態に較べて、クライアント側で個々の要求の負荷を加味し、発行された複数の要求の総負荷を計算するので、適切な要求に対する負荷評価を行なうことができる。

例えば、印刷ジョブの完了通知イベントの登録と、印刷装置で管理されている複数の印刷ジョブのリスト要求とでは、プリントサーバの負荷が大幅に異なるが、このような場合に負荷を適切に評価できる。

図９は、送信閾値情報６３０の一例を示す図である。本テーブルは後述のプログラム初期化処理（図１２〜図１３）において、ハードディスク２０５からＲＡＭ２０２に読み込まれる。

本発明における送信閾値情報は、送信を可能とする要求数６３１、送信可能負荷の閾値６３２及びその適用方法６３３が指定可能である。これらの値は図１４で説明する要求送信処理において参照される。なお、送信可能要求数６３１及び、送信可能負荷の閾値６３２にそれぞれ０が指定された場合には、それぞれの値は適用されない。つまり、送信可能要求数、送信可能負荷の閾値６３２に０Ｒｅｑｕｅｓｔが指定された場合、送信済み要求数による送信制御は行われず、負荷値による制御のみが実施される。

また、送信可能負荷の閾値の適用方法には、送信済みの各要求負荷を合計した負荷総数が「閾値を超えないように停止」する方法と「閾値以上になったら停止」する方法の２通りがあり、図９では、「閾値以上になったら停止」する方法が現在の設定として選択されている様子をあらわしている。また、閾値以上、閾値以下の解釈としては、閾値と同じ値で要求送信を停止するとい解釈、総負荷が閾値よりも上または下になった場合に、要求送信を停止するという解釈のどちらでも良い。

「閾値を超えないように停止」する方法においては、送信済み且つ未応答の要求の総負荷と、既に発行され且つこれから送信しようとする未送信の要求の負荷値を足した値が、設定されている送信可能負荷の閾値６３２を超える場合には、その要求の送信は許可されない。また、「閾値以上になったら停止」する方法では、これから送信しようとする要求の負荷値は関係なく、現在の負荷の値が送信可能負荷の閾値６３２の値以上であれば、新たな要求送信は行われないものとする。

この図９及び上に説明した図８の双方の構成を備えることにより、例えば、印刷ジョブの完了通知イベント登録は複数個行なえるようにし、印刷ジョブのリスト要求は１つだけ行なえるという動作を各クライアントに対して保証でき、プリントサーバの負荷を適切に評価するのみに留まらず、各クライアントにおいて一定の印刷システムの使い勝手を確保することができるという、ユーザビリティーの面でも格別の効果を得ることができる。

図１０は、ある時間に要求管理テーブル６１０において管理されている要求リストの一例を示したものである。図では６個の要求が存在し、ＲｅｑｕｅｓｔＩＤ１００、１０１の２個の要求がサーバへ転送済みであり、ＲｅｑｕｅｓｔＩＤ１０２、１０３、１０４、１０５の４個の要求が転送待ちである事が分かる。この図１９に示されるテーブルを基づいて、クライアントから既に発行され、プリントサーバからの未応答の複数の要求の個々の負荷が認識され、該認識された個々の負荷に基づき複数の要求の総負荷が計算され、該計算された総負荷に基づきクライアント側で、要求の発行の抑制が行なわれる。

要求管理テーブル６１０では、個々の要求の状態のほか、サーバへ転送するメッセージ（図７）を作成するために必要となる情報、及び、個々の要求における負荷の値を管理している。なお本発明の実施例においては、要求を受け付ける都度要求の負荷が決定され管理テーブルにエントリが追加される事を想定しているが、図１０の要求管理テーブル６１０には負荷の値を持たず、図８で示される要求負荷テーブル６２０を直接参照する事により、送信済み要求の総負荷を計算するように構成しても良い。

また、図１０に示される要求管理テーブル６１０により、プリントサーバへの送信済みの要求と未送信の要求を識別可能に管理することができ、図１１に示されるような、未送信の要求を除く送信済み且つ未応答の要求に基づきより正確な負荷総数を計算することができる。

図１１は、図１０と同一のタイミングにおける送信済み要求情報６４０の一例を示す図である。送信済み負荷管理テーブル６４２にはＲｅｑｕｅｓｔＩＤ１００及び１０１の２個の要求がその負荷値と共に記録されている。また、計算を容易にするため６４２に含まれる要求の総数とそれらの要求の総負荷を送信済み要求現在値６４１として保持している。

送信済み負荷管理テーブル６４２にはＲｅｑｕｅｓｔＩＤ１００及び１０１のエントリがあるため、送信済み要求現在値６４１の送信済み要求数は２Ｒｅｑｕｅｓｔであり、送信済み負荷総数は４ポイントである事を示している。このデータは後述の要求送信処理、応答受信処理及び要求キャンセル処理によって更新される。

図１２は、本発明における情報処理システムにおける要求制御プログラムの動作概要を示すフローチャートである。なお、本フローチャートは本発明の論旨に関係のあるところのみ抜粋している為、図示されていない処理が含まれていても本発明を逸脱することなく適用できる事は言うまでもない。

先ず始めにステップＳ１２０１において要求管理部６０１の初期化処理が行われる。これについては図１３及び図１４を用いて後述する。

続くステップＳ１２０２、Ｓ１２０３において、要求送信部６０３、応答受信部６０４の初期化処理が行われ、ステップＳ１２０４のイベント待ちのループに入る。

ステップＳ１２０５において、プログラム終了のイベントを受け取る事による本プログラムは終了する。一方ステップＳ１２０５の要求管理部６０１による判定において、入力されたイベントが終了以外であると判定された場合には、ステップＳ１２０６において、要求管理部６０１によりそのイベントが送信要求受付イベントか否かが判定される。ＹＥＳであると判定された場合には、ステップＳ１２０７において後述の要求受け付け処理（図１５）を行い、イベント待ちステップＳ１２０４へと移る。

一方ステップＳ１２０６の判定においてＮＯと判定された場合には、ステップＳ１２０８において要求管理部６０１により該イベントがキャンセル要求か否かが判定される。ＹＥＳと判定された場合には、ステップＳ１２０９のキャンセル処理（図２１）を行い、ステップＳ１２１３へと移る。

一方ステップＳ１２０８の判定においてＮＯと判定された場合には、ステップＳ１２１０において、該イベントが応答受信部６０４からの応答受信イベント（図１８、ステップＳ１８０７に対応）であるか否かが判定される。ＮＯの場合には、ステップＳ１２１３へジャンプする。ＹＥＳの場合には、受信したメッセージが「応答」であるか「イベント」であるかが判定され、「応答」であり、かつ、「イベント待ち」へ遷移しない要求であれば、ステップＳ１２１１において、図１０で示された要求管理テーブルから該当する要求のエントリを削除し、続いてステップＳ１２１２で該応答に対するその他の処理を行う。

その他の処理とは例えばＧＵＩの更新や、上位システムへの応答への送信、本発明の情報処理システムで管理し、かつ、本発明とは関係の無い内部データの更新処理等が含まれる。

続いてステップＳ１２１３において未送信の要求があるか否かが判定される。ＹＥＳの場合、具体的には図１０では未送信の要求が４個（ＲｅｑｕｅｓｔＩＤ１０２〜１０５）存在するため、続くステップＳ１２１４において、クライアントからの要求の発行、即ち、要求送信処理が要求送信部６０３を介して行われる。要求送信処理は図１６を用いて後述する。

ここでステップＳ１２１４が実行されるタイミングとしては、ステップＳ１２１３で図１０に示される管理情報により、未送信の要求がある場合であるが、これに限定されるものではなく、イベントの入力にかかわらず、定期的に図１２に示されるフローチャートを実行させるようにしても良い。

図１３は、要求管理部６０１の初期化処理を示したフローチャートであり図１２のステップＳ１２０１に対応するものである。要求管理部６０１の初期化処理では、要求管理テーブル６１０及び送信済み要求情報６４０が初期化されると共に、送信閾値情報６３０が作成される。

先ず、ステップＳ１３０１で送信可能負荷の閾値６３２に対して初期値をセットする。続いてステップＳ１３０２において、送信可能要求数６３１に対して初期値をセットする。

続いて、送信可能負荷の閾値の適用方法６３３に対して初期値をセットする。続いてステップＳ１３０４において、送信閾値の設定ファイルがあるか否かが判定される。ＹＥＳと判定された場合には、ステップＳ１３０５において、送信可能負荷の閾値６３２に対する設定があるか否かが判定される。ＹＥＳと判定された場合にはステップＳ１３０６において、送信可能負荷の閾値６３２が更新（変更）される。

続いてステップＳ１３０７において、送信可能要求数６３１に対する設定があるか否かが判定される。ＹＥＳの場合にはステップＳ１３０８において送信可能要求数６３１が更新され、図８で説明したような、各要求に対応する負荷の大きさの変更される。

続いてステップＳ１３０９において、送信可能負荷の閾値の適用方法６３３に対する設定があるか否かが判定される。ＹＥＳの場合にはステップＳ１３１０において、送信可能負荷の閾値の適用方法６３３が更新（変更）される。続いてステップＳ１３１１において後述の要求負荷取得部６０２の初期化が行われ、要求管理部初期化処理は終了する。

図１３のフローチャートが実行されることにより、要求の送信の抑制の条件（送信可能負荷の閾値や、送信可能要求数など）に係る設定を変更することができ、例えば、他のクライアントに較べて印刷ジョブの投入をはじめ、各種要求を多く発行するクライアントについては、抑制しにくいように条件を変更することができる。また、抑制の条件としては、図９において説明した、６３１乃至６３３の何れか１つ、或いは、複数を含める場合が想定される。

図１４は要求負荷取得部６０２のフローチャートであり、図１３のステップＳ１３１１に対応するものである。要求負荷取得部６０２の初期化処理においては、要求負荷テーブル６２０が作成される。

先ず、ステップＳ１４０１において要求負荷テーブルに対して初期値を設定する。続いてステップＳ１４０２において要求負荷設定ファイルがあるか否かが判定され、ＹＥＳと判定された場合には、ステップＳ１４０３において、ファイルで指定されたＡＰＩを指定された負荷値で更新（変更）し、要求負荷取得部６０２の初期化処理が終了する。尚、ファイルで指定されるＡＰＩの種類は任意に指定可能とする。

この図１４の処理により、個々の要求に対応する負荷の大きさを変更することができるので、例えば、ある要求（ＡＰＩ）に対する負荷の大きさが実際の印刷システムの運用上適切でない場合に、適宜変更することができ、よりよい印刷環境を実現することができる。

図１５は要求受付処理の概要を示すものであり、図１２のステップＳ１２０７に対応するものである。ユーザのプリントマネージャ６５７を介しての指示や、内部的なアプリケーション指示に応じて要求送信イベントが発生するとステップＳ１５０１で要求負荷取得部６０２からＡＰＩに応じた負荷値が取得され、続くステップＳ１５０２において、該要求を示すエントリが作成され、前述の要求管理テーブル６１０（図１０）に該エントリが追加される。

図１６は、要求送信処理の詳細を示すフローチャートであり、図１２のステップ１２１４に対応する。ここでは要求管理テーブル６１０におけるＲｅｑｕｅｓｔＩＤ１０２のエントリが送信されるものとして詳細を説明する。

要求送信処理においては、先ずステップＳ１６０１において、送信する要求に対する情報が入力（図１０のうち未送信の先頭の要求が取り出される）される。ステップＳ１６０１では、図８において説明した様々な要求が入力（図１０のうち未送信の先頭の要求が取り出される）されることとなるが、図中では説明を分かりやすくするために、負荷値＝１０、ａｐｉ＝３、Ｐａｒａｍｅｔｅｒ＝（Ｓｔａｒｔ＝１、Ｃｏｕｎｔ＝１００）が入力（図１０のうち未送信の先頭の要求が取り出される）されるものとして、以下説明を行なう。

続くステップＳ１６０２において、送信閾値情報６３０内の送信可能要求数６３１が取得される。続くステップＳ１６０３において、送信可能負荷の閾値６３２と送信可能負荷の閾値の適用方法６３３が取得される。

続くステップＳ１６０４において、送信可能要求数が０以上か否かが判定される。ここでＮＯの場合には送信可能要求数の判定は行われずステップＳ１６０７へジャンプする。

ステップＳ１６０４の判定においてＹＥＳと判定された場合には、ステップＳ１６０５において送信済み要求現在値６４１が取得される（図１１では２Ｒｅｑｕｅｓｔ）。ステップＳ１６０６の判定において、送信済み且つ応答未受信の要求数が送信可能要求数以上であると判定された場合には、送信処理は行われずステップＳ１６１２でエラー応答が作成され送信処理は終了する。

一方、送信数の判定を行わなかった場合、或いは、送信数判定の結果ＯＫと判定された場合には、ステップＳ１６０７において送信可能負荷の閾値６３２が０より大きいか否かが判定される。０以下である場合には、負荷による判定は行われずに、ステップＳ６１３〜ステップＳ１６１８に記載された送信処理が行われる。負荷を考慮しない形態をとることにより、管理者など、要求を多数発行する必要性のあるユーザに対応することができる。

ステップＳ１６０７の判定においてＹＥＳと判定された場合には、ステップＳ１６０８において、送信済み負荷総数６４１（図１１では４Ｐｏｉｎｔ）が取得される。ここで負荷総数６４１と送信可能負荷の閾値６３２の判定は、送信可能負荷の閾値の判定方法６３３に応じて異なるが、いずれにしても、既にクライアントから送信された要求で、プリントサーバから未応答の複数の要求の個々の負荷を、図９の送信閾値情報６３０により認識でき、該認識された個々の負荷に基づき計算した結果がステップＳ１６０８で取得される負荷総数となる。

ステップＳ１６０９において送信可能負荷の閾値の判定方法６３３が「閾値以上になったら停止」が選択されていない場合には、ステップＳ１６１０において送信済み負荷総数６４１（４ポイント）とこれから送信しようとする要求（ステップＳ１６０１における１０ポイント）の負荷の合計が、送信可能負荷の閾値６３２（図１０における１２ポイント）よりも大きいか否かが判定される。大きいと判定された場合には、ステップＳ１６１２に遷移し送信処理は行われない。

一方ステップＳ１６０９においてＹＥＳと判定された場合には、ステップＳ１６１１において、送信済み且つプリントサーバから未応答の要求が示す負荷総数６４１が送信可能負荷の閾値６３２以上或いは超えているか否かが判定され、ＮＯであれば、ステップＳ１６１２へ遷移し送信処理は行われない。

前述の判定の結果、送信可能条件を満たしていると判断された場合には、実際の送信処理が行われる。尚、ステップＳ１６０９の判定を省略し、ステップＳ１６０８からステップＳ１６０９の判定を行なうことなく、ステップＳ１６１１に移行するようにしても良い。

ステップＳ１６１３ではデータ形式の変換が行われ、データストリームがホスト形式から図７で示したネットワーク形式へ変換される。続くステップＳ１６１４において要求メッセージが要求送信部６０３を介してネットワーク上へ発行される。

続くステップＳ１６１５で送信済み負荷管理テーブル６４０が更新され、エントリが一つ追加される。続いてステップＳ１６１６、Ｓ１６１７で送信済み要求現在値６４１が更新され、ステップＳ１６１８で成功応答共に送信処理は終了する。送信処理が終了すると要求管理テーブル６１０における該要求のステータスがＷａｉｔからＳｅｎｔへと遷移する。

図１６のフローチャートによれば、プリントサーバ側でクライアントからの要求を受付けるか否かを判定する形態に較べて、プリントサーバ側での判定処理負荷を軽減できる。特にプリントサーバ側が複数のクライアントと共有される場合に、クライアントからの要求の発行の許可の判定処理を分散するという効果を得ることができる。

さらに、プリントサーバ側でクライアントからの要求を受付けるか否かを判定する形態では、要求を拒否する場合に、プリントサーバの判定処理負荷が増大するばかりか、プリントサーバからクライアントへの拒否通知、及び、拒否受信に連動するクライアントからの要求発行のリトライが発生してしまい、トラフィック量を増大させてしまうという問題があるが、図１６のフローチャートにより、この問題を解消することができる。

要求送信処理完了後の送信済み要求情報６４０の変化を図１７に示す。図１０と比較して、送信済み要求現在値６４１´における送信済み負荷総数が１４Ｐｏｉｎｔ（１０Ｐｏｉｎｔ増加）、送信済み要求数が３Ｒｅｑｕｅｓｔ（１Ｒｅｑｕｅｓｔ増加）し、送信済み負荷管理テーブル６４２’には、ＲｅｑｕｅｓｔＩＤ１０２のエントリが追加されている。

図１８は、応答受信部６０４における応答受信処理の概要を示すフローチャートである。図１２で説明したステップＳ１２１１及びステップＳ１２１２の処理の詳細を示す。

ステップＳ１８０１においてプリントサーバ１０１から送信されたメッセージ（構造を図７に記載）が受信されるとステップＳ１８０２においてメッセージからＲｅｑｕｅｓｔＩＤが抽出され、ステップＳ１８０３において抽出されＲｅｑｕｅｓｔＩＤに基づく送信済み負荷テーブル６４２が検索される。

ステップＳ１８０４において一致したリクエストが検索され、かつ、該リクエストがイベントタイプ（サーバからレスポンス以外に１回以上のイベントメッセエージを非同期に受け取るタイプの要求）ではない場合には、ステップＳ１８０５において、該検索されたテーブルが、送信済み負荷管理テーブル６４２から削除され、負荷管理テーブル６４２は更新される。

続いてステップＳ１８０６、ステップＳ１８０７において送信済み要求現在値における送信済み要求数と送信済み負荷総数が該削除されたテーブルに応じた値だけ減ぜられ送信済み要求現在値６４１も更新される。このように、ステップＳ１８０６、Ｓ１８０７の処理により、プリントサーバから応答のあった要求に対応する負荷を負荷総数から減算することができる。

続いてステップＳ１８０８において、応答受信イベントが要求管理部６０１へ通知される。

そして、図１８のフローチャートが実行されることにより、計算された負荷総数が所定の閾値以上或いは閾値より上である場合から、閾値未満或いは閾値以下になる場合があり（Ｓ１６１０、１６１１でＮＯと判定される）、その場合には、未送信で抑制されていた要求の送信（再送信）が要求送信部６０３により行なわれる（Ｓ１６１４）。そして、クライアント側に予約された未送信の要求が、順次プリントサーバ１０１に対して送られることとなる。

図１９は、クライアントからサーバへの要求送信をキャンセルする際の処理の詳細を示したフローチャートであり、図１２のステップＳ１２０９に対応するものである。

先ずステップＳ１９１０において、キャンセルすべき要求を識別するためのＩＤ（ＲｅｑｕｅｓｔＩＤ）が入力される。続いてステップＳ１９０２において、要求管理テーブル６１０から該当するリクエストが検索される。

ステップＳ１９０３において一致するリクエストがあると判定された場合には、ステップＳ１９０４において該当するリクエストを要求管理テーブル６１０から削除する。続いて送信済み要求情報６４０の更新を行う。また要求管理テーブル６１０から要求を削除した場合に、対応してクライアントからプリンタ側に既に送信された要求を削除する命令（例えば、ＵｎｓｕｂｓｃｒｉｂｅＥｖｅｎｔ ａｐｉ（番号２）や、キャンセルリクエスト）を送り、プリンタ側の負荷を軽減する。

ステップＳ１９０５において、送信済み負荷テーブル６４２からリクエストＩＤに一致するテーブルが存在するかを検索する。

ステップＳ１９０６で一致するテーブルがあったと判定された場合には、ステップＳ１９０７において送信済み要求現在値６４１の送信済み要求数を１減ずる。続いてステップＳ１９０８において送信済み要求６４１の送信済み負荷総数をステップＳ１９０５で検索されたエントリの負荷値だけ減ずる。

続いてステップＳ１９０９において送信済み負荷テーブルから該当するリクエストを削除し、キャンセル処理は終了する。

（実施例２）
実施例１においては、クライアントから発行された複数の要求でプリントサーバ１０１から未応答の要求の総負荷を計算し、該計算された総負荷に応じて
クライアントからの要求の発行を抑制するよう説明してきたが、これに限定されるものではない。

クライアントよりプリントサーバ１０１に発行された複数の要求でプリントサーバから未応答の複数の要求の個々の負荷を認識し、該認識された個々の負荷に基づき複数の要求の総負荷を計算する点においては、プリントサーバ或いは他の装置で実行するようにしても良い。

つまり、プリントサーバ１０１が、実施例１の図６、図８で説明した機能を備え、さらに、図９、図１０、図１１、図１７で説明した機能を要求発行元の各クライアントに対応して監理及び管理し、さらに、図１５、図１６、図１８、図１９のフローチャートの処理を実行する形態も想定される。この形態の場合には、図１５、図１６、図１８の各フローチャートは各クライアントに対して個別に行なわれることとなる。また、図１６のステップＳ１６１４の処理はプリントサーバ１０１がクライアントから要求を受信する処理に置き換えることにより実現される。

そして、この実施例２においても、要求数のみからクライアントからの要求を受けつるか否かを判定する形態に較べて、個々の要求の負荷を加味し、発行された複数の要求の総負荷を計算するので、適切な要求に対する自装置の負荷評価を行なうことができる。

例えば、印刷ジョブの完了通知イベントの登録と、プリンタで管理されている複数の印刷ジョブのリスト要求とでは、プリントサーバ側の負荷が大幅に異なるが、このような場合に負荷を適切に評価できという点では、実施例１と同様の格別の効果を得ることもできる。

本発明の情報処理システムの構成を示すブロック図である。 図１に示した情報処理装置の構成を説明するブロック図である。 図２に示したＲＡＭ２０２のメモリマップの一例を示す図である。 図２に示したＦＤ２０４のメモリマップの一例を示す図である。 図２に示したＦＤドライブ２０３に対して挿入されるＦＤ２０４との関係を示す図である。 本発明の印刷システムの機能概要を示す図である。 図１に示したクライアント１０２とサーバコンピュータ１０１或いはネットワークプリンタ１０５中のサーバプログラムとの間で送受信されるメッセージ構成の一例を示す図である。 図６に示した要求負荷テーブル６２０の一例を示す図である。 図６に示した送信閾値情報６３０の一例を示す図である。 図６に示した要求管理テーブル６１０の一例を示す図である。 図６に示した送信済み要求情報６４０の一例を示す図である。 要求送信処理の一例を示すフローチャートである。 図１２に示した管理部の初期化処理の詳細を示すフローチャートである。 図１３に示した管理部の初期化処理における、要求負荷取得部の初期化処理の詳細を示すフローチャートである。 図１２に示した要求受付処理の詳細を示すフローチャートである。 図１２に示した要求送信処理の詳細を示すフローチャートである。 図１６に示した要求送信処理が実行された後の、送信済み要求情報６４０の一例を示す図である。 図６に示した応答受信部６０４の処理を示すフローチャートである。 図１２に示した要求キャンセル処理の詳細を示したフローチャートである。

符号の説明

１０１ サーバコンピュータ
１０２ クライアント
１０５ サーバプログラムが動作するネットワークプリンタ
３０３ 本発明を実施したプリンタ制御プログラム
３０４ 本発明を実施したネプリンタ制御プログラムの関連データ
６０１ 要求管理部
６０２ 要求負荷取得部
６０３ 要求送信部
６０４ 応答受信部
６０５ 未応答要求管理部
６１０ 要求管理テーブル
６２０ 要求負荷取得部
６３０ 送信閾値情報
６４０ 送信済み要求情報

Claims (12)

1. 印刷制御装置へ複数種類の処理の要求を発行する情報処理装置において実行される印刷制御プログラムであって、
   情報処理装置から印刷制御装置に発行され且つ前記印刷制御装置が応答していない要求の各々の負荷を認識する負荷認識ステップと、
   前記負荷認識ステップにおいて認識された前記要求の各々の負荷に基づき、前記印刷制御装置の総負荷を計算する計算ステップと、
   前記計算ステップにおいて計算された総負荷に基づいて情報処理装置からの要求の発行を抑制する抑制ステップとを有することを特徴とする印刷制御プログラム。
2. 前記印刷制御装置が応答していない要求の個数に基づいて情報処理装置からの要求の発行を抑制する第２抑制ステップを有し、前記第２抑制ステップは前記計算ステップにより計算される総負荷に関わらずに情報装置からの要求の発行を抑制することを特徴とする請求項１に記載の印刷制御プログラム。
3. 前記抑制ステップは、前記計算ステップにおいて計算された負荷が所定の閾値以上或いは閾値より上である場合に、前記印刷制御装置への要求の送信を抑制することを特徴とする請求項１または２の何れかに記載の印刷制御プログラム。
4. 前記印刷制御装置からの応答のあった要求に対応する負荷を前記負荷から減算する減算ステップを有することを特徴とする請求項１乃至３の何れかに記載の印刷制御プログラム。
5. 前記計算ステップにおいて計算された負荷が所定の閾値以上或いは閾値より上である場合から、前記減算ステップにより前記負荷が閾値未満或いは閾値以下になった場合に、未送信で抑制されていた要求の送信を行わせる要求送信制御ステップを有することを特徴とする請求項４に記載の印刷制御プログラム。
6. 前記印刷制御装置への送信済みの要求と未送信の要求とを識別可能にした管理情報を管理する要求管理ステップを有し、前記負荷認識ステップは、前記印刷制御装置に前記要求管理ステップで管理される未送信の要求を除く送信済みの要求の各々の負荷を認識することを特徴とする請求項１乃至５の何れかに記載の印刷制御プログラム。
7. 各要求に対応する負荷の大きさを変更する第１変更ステップを有することを特徴とする請求項１乃至６の何れかに記載の印刷制御プログラム。
8. 前記抑制の条件を変更する第２変更ステップを有することを特徴とする請求項１乃至７の何れかに記載の印刷制御プログラム。
9. 印刷制御装置へ複数種類の処理の要求を発行する情報処理装置における処理方法であって、
   情報処理装置から発行され且つ前記印刷制御装置が応答していない要求の各々の負荷を認識する負荷認識ステップと、
   前記負荷認識ステップにおいて認識された前記要求の各々の負荷に基づき、前記印刷制御装置の総負荷を計算する計算ステップと、
   前記計算ステップにおいて計算された総負荷に基づいて情報処理装置からの要求の発行を抑制する抑制ステップとを有することを特徴とする処理方法。
10. 請求項１乃至９の何れかに記載の印刷制御プログラムをコンピュータが読み取り可読な形態で記憶した記憶媒体。
11. 印刷制御装置へ複数種類の処理の要求を発行する発行手段を備えた情報処理装置であって、
    情報処理装置から発行され且つ前記印刷制御装置が応答していない要求の各々の負荷を認識する負荷認識手段と、
    前記負荷認識手段において認識された前記要求の各々の負荷に基づき、前記印刷制御装置の総負荷を計算する計算手段と、
    前記計算手段により計算された総負荷に基づいて情報処理装置からの要求の発行を抑制する抑制手段とを有することを特徴とする情報処理装置。
12. 印刷制御装置と、該印刷制御装置へ複数種類の処理の要求を発行する情報処理装置とからなる印刷システムであって、
    情報処理装置から発行され且つ前記印刷制御装置が応答していない要求の各々の負荷を認識する負荷認識手段と、
    前記負荷認識手段において認識された前記要求の各々の負荷に基づき、前記印刷制御装置の総負荷を計算する計算手段と、
    前記計算手段により計算された総負荷に基づいて情報処理装置からの要求の発行を抑制する抑制手段とを有することを特徴とする印刷システム。

Images