JP2006155578A - 情報管理装置、情報管理システム及び情報管理方法 - Google Patents

Abstract

【課題】 許容範囲以上の負荷をかけることなく、クライアント装置からのリクエストを当該リクエストが指示された順序で処理できるようにする。
【解決手段】 各クライアント装置１０２からリクエストを受信した場合に、指示された順序に基づいてリクエストを管理するスケジュールテーブル２０５ａに登録できるか否かを判断し（ステップＳ４０２）、スケジュールテーブル２０５ａに登録できると判断された場合に、当該リクエストをスケジュールテーブル２０５ａに登録し（ステップＳ４０３）、スケジュールテーブル２０５ａに登録できないと判断された場合に整理券を発行し、当該整理券を当該リクエストの送信元のクライアント装置１０２に対して送信するようにする（ステップＳ４０５）。
【選択図】 図４

Description

本発明は、情報管理装置、当該情報管理装置とクライアント装置を有する情報管理システム、情報管理方法及び当該情報管理方法をコンピュータに実行させるためにプログラムに関するものである。

近年、インターネットやローカルエリアネットワーク（ＬＡＮ）等のネットワークが普及しており、これらネットワークを介してクライアント装置は、アプリケーションサーバやデバイスに対して、リソースやサービスの利用をリクエストする。アプリケーションサーバやデバイスは、クライアント装置からのリクエストを受け付け様々な処理を実行している。

このようなアプリケーションサーバやデバイスは、ＣＰＵの処理能力や記憶容量が限られているため、一度に実行できる処理の量には物理的な限界が存在する。そのため、ネットワークプリントシステムのように、多くのクライアント装置から一度にアプリケーションサーバや印刷デバイスに対して多量の印刷リクエストである印刷ジョブが送信されてしまい、アプリケーションサーバや印刷デバイスにおける処理の許容量を超えてしまうと、処理に想定した以上の時間がかかってしまったり、処理が正常に行われなかったり、アプリケーションサーバや印刷デバイスが起動停止してしまったりすることがある。

そこで、近年、アプリケーションサーバや印刷デバイス側において、クライアント装置からの印刷リクエストである印刷ジョブは受け付けず、印刷ジョブの描画データ等の実体を含まない印刷リクエストを受け付けることで、保管するデータ量を制限し、印刷順序になった印刷リクエストに対する印刷ジョブを印刷デバイスにクライアントから送信する仕組みが考えられている（例えば特許文献１）。この方法により、アプリケーションサーバやデバイスは、処理の許容範囲内での動作を確保することができ、常に正常な処理能力を発揮することができる。

しかし、特許文献１のシステムでは、サーバが印刷要求のジョブ情報を管理することになり、システムとしてサーバが必要になってしまい、小さなオフィスにはコストが高くなってしまうという問題がある。そこで、近年、印刷装置側にジョブの順序管理機能を備えることが要求されている。しかし、印刷装置に大容量の記憶装置（ＨＤＤ）を備えてしまうと、それにより印刷装置自体のコストアップになってしまうという問題がある。

この問題を解決するために、印刷装置に装着されるネットワークボード（情報管理装置）に２５６Ｍ程度のＲＡＭを設け、このメモリを用いて印刷ジョブの描画データを含まない印刷リクエストを受け付け、コストを抑えて印刷順序管理を行う仕組みが考えられている。しかしながら、印刷ジョブの描画データを含まない印刷リクエストを管理するだけでも、印刷属性など、管理する情報が多くなってきており、ネットワークボードのメモリの管理領域では、印刷リクエストは２５６個程度で制限を設けなければならず、制限を超えた印刷リクエストは拒否するといったような処理を行わなければならないと考えられる。

この方法では、印刷リクエストを拒否されたクライアント装置は、再度印刷リクエストを繰り返し行うことが通常であるが、その場合、ネットワークボードに相当する情報管理装置の受け付けに空きができるタイミングによって、後から指示されたクライアント装置の印刷リクエストが先に受け付けられてしまうことがあり、印刷リクエストの順序を正確に守れないことが考えられる。

また、従来、スケジューラを用いてクライアント装置からのリクエストの順序を管理したり、アプリケーションサーバやデバイスの処理の許容量を超えないように、リクエストの量を管理したりする技術が存在している。例えば、下記に示した特許文献２では、あるアプリケーションサーバの接続及び接続数を管理するスケジューラ（受け付けサーバ）を準備し、クライアント装置がアプリケーションサーバに接続を要求する場合は、まずスケジューラに接続要求を行う。クライアント装置からの第１回目の接続要求の際にスケジューラは整理番号を付与した整理券を発行し、この整理券の整理番号に基づいてアプリケーションサーバへの接続優先順位をスケジュールテーブルに登録して管理する。そして、クライアント装置からの第２回目の接続要求の際にスケジューラは、管理している接続優先順位を参照し接続可能であれば接続許可する。この方法によってアプリケーションサーバへの接続数及びクライアント装置の接続要求の順序を制御することができる。

特開平１０−２４０４６９号公報 特開２００２−２２２１２３号公報

しかしながら、近年、ＴＣＯ（Total Cost of Ownership）の削減を目的として、サーバレス化や当該機能のデバイスへの組み込み化が進んでいる。そのため、サーバとして必要十分な処理能力や信頼性を確保することが難しくなっている。

上述した特許文献１のスケジューラでは、クライアント装置のリクエストを管理するスケジュールテーブルが必要となる。しかし、印刷装置に装着されるネットワークボードのようなエンベデッドサーバ（情報管理装置）では、例えば製品コスト削減による記憶容量の制限が大きいため、クライアント装置のリクエスト数に対して十分な大きさのテーブルを用意することが難しいなどが想定される。そのため、例えば多数のクライアント装置から多数のリクエストが発行されると、スケジュールテーブルの許容範囲を超えてしまい、スケジューラが正常な処理を行えずにリクエストの順序を厳密に守ることができないという問題があった。他方、スケジュールテーブルの許容範囲を超えてしまい、スケジューラが起動停止してしまったりするという問題が考えられる。

さらに、例えば、デバイスへの組み込みサーバでは、デバイスが電源遮断されると同時に電源遮断されるのが通常であり、従来の印刷デバイスとは独立したサーバよりも電源遮断されやすい環境にある。しかしながら、組み込みサーバでは二次記憶装置（不揮発性記憶媒体）を持っていないことが多く、一度、電源遮断されてしまうと、再起動の度にスケジュールテーブルがリセットされてしまい、電源遮断からの復旧時に、それまで受け付けていたリクエストの順序を守ることができないという問題がある。

本発明は前述の問題点にかんがみてなされたものであり、許容範囲以上の負荷をかけることなく、クライアント装置からの各リクエストを当該各リクエストが指示された順序で処理を行うことを実現する情報管理装置、情報管理システム、情報管理方法及びプログラムを提供することを目的とする。

本発明の情報管理装置は、クライアント装置からリクエストを受信する受信手段と、前記クライアント装置から送信された各リクエストを、その指示された順序に基づいて管理する管理テーブルを記憶する管理テーブル記憶手段と、前記受信手段でリクエストを受信した場合に、前記管理テーブルに登録できるか否かを判断する判断手段と、前記判断手段により前記管理テーブルに登録できると判断された場合に、当該リクエストを前記管理テーブルに登録する登録手段と、前記判断手段により前記管理テーブルに登録できないと判断された場合に整理券を発行し、当該リクエストの送信元のクライアント装置に対して前記整理券を送信する整理券発行手段とを有する。

本発明によれば、許容範囲以上の負荷をかけることなく、クライアント装置からの各リクエストを当該各リクエストが指示された順序で処理を行うことができる。また、情報管理装置の起動が停止して管理テーブルが初期化された場合でも、起動停止前に登録されていたリクエストの順序で処理を行うことができる。

以下、本発明の実施形態を添付図面を参照しながら説明する。

（第１の実施形態）
図１は、第１の実施形態における情報管理システムの概略構成図である。
図１に示すように、本実施形態の情報管理システムは、インターネットやＬＡＮ等のネットワーク１０１と、ユーザが利用するクライアント装置１０２と、複数のクライアント装置１０２からのリクエストを受けて所定の処理を実行するアプリケーションサーバもしくはデバイス（以下、アプリケーションサーバ１０３とする）と、複数のクライアント装置１０２からリクエストを受信し、当該リクエスト等を管理する情報管理装置であるスケジューラ１０４を含み構成されている。また、これらの各装置は、相互に情報をやり取りできるようにネットワーク１０１を介して接続されている。

各クライアント装置１０２は、一般的な情報処理装置であり、ネットワーク１０１を介してアプリケーションサーバ１０３やスケジューラ１０４と接続する手段や、データを送受信する手段を備えている。また、アプリケーションサーバ１０３とスケジューラ１０４とは、１０５で示したローカルなネットワークでも接続されている。

ここで、スケジューラ１０４は、一般的な情報処理装置であってもよいが、本実施形態では、エンベデッドサーバと呼ばれる印刷デバイスへの組み込みサーバとして動作するものであり、本実施形態におけるスケジュール管理プログラムが実行可能に格納されている。

図２は、スケジューラ１０４の内部構成を示した概略図である。
図２に示すように、スケジューラ１０４は、クライアント装置１０２からの接続要求をネットワーク１０１を介して受けて接続の管理を行ったりデータの送受信を行ったりするリクエスト管理部２０１と、発行した整理券の管理を行う整理券管理部２０２と、クライアント装置１０２からのリクエストを待ち行列として管理する管理テーブルであるスケジュールテーブル２０５ａを記憶するスケジュールテーブル記憶部２０５と、スケジュールテーブル２０５ａに登録できるリクエストの最大数を保持する最大リクエスト数カウンタ２０３と、現在、スケジュールテーブル２０５ａで管理しているリクエスト数カウンタ２０４と、アプリケーションサーバ１０３の状態を管理するアプリケーションサーバ管理部２０６と、発行された整理券の暗号化を行う整理券暗号化部２０７と、暗号化された整理券の復号化を行う整理券復号化部２０８を備えている。本実施形態では、スケジューラ１０４には、通常状態と順番整理状態との２つの状態がある。それぞれの状態の移行条件については後述する。

図３は、クライアント装置１０２からリクエストを受信した際のスケジューラ１０４における処理を示したフローチャートである。
スケジューラ１０４が起動すると、まず、ステップＳ３０１では、スケジューラの復旧処理を行う。この復旧処理の処理の詳細は後述する。このステップＳ３０１の復旧処理の結果によってスケジューラは、通常状態もしくは順番整理状態に移行する。そして、この復旧処理が終了すると、スケジューラ１０４は、リクエスト受信の待ち状態となる。

続いて、ステップＳ３０２においてクライアント装置１０２からリクエストを受信すると、ステップＳ３０３に進み、現在の自機器の状態が通常状態であるか、順番整理状態であるかを判断する。この判断の結果、通常状態であると判断された場合には、ステップＳ３０４に進んで、後述する通常状態時のリクエストとして受信処理を行う。一方、ステップＳ３０３での判断の結果、順番整理状態であると判断された場合には、ステップＳ３０５に進んで、後述する順番整理状態時のリクエストとして受信処理を行う。そして、それぞれの処理が終了すると、スケジューラ１０４は、ステップＳ３０２のリクエスト受信待ち状態に戻る。

図４は、スケジューラ１０４において、図３のステップＳ３０４に示す通常状態時のリクエスト受信処理を示すフローチャートである。
スケジューラ１０４は、通常状態時にクライアント装置１０２からリクエストを受信すると、まず、ステップＳ４０１では、整理券管理部２０２において、整理券を発行する。続いて、ステップＳ４０２では、当該リクエストの受け付けが可能であるか否かを判断する。この際、ステップＳ４０２における判断は、最大リクエスト数カウンタ２０３とリクエスト数カウンタ２０４とを比較して、現在スケジュールテーブル２０５ａに未だ空きがあり、登録可能であるか否かを判断する。

ステップＳ４０２での判断の結果、リクエストの受け付けが可能であると判断された場合には、ステップＳ４０３に進む。続いて、ステップＳ４０３では、受信した当該リクエストをスケジュールテーブル２０５ａに登録する。続いて、ステップＳ４０４では、スケジュールテーブル２０５ａに登録済みであることを示す識別子をステップＳ４０１で発行された整理券に付与して登録済整理券とし、リクエストを発行したクライアント装置１０２に対して送信する。

一方、ステップＳ４０２での判断の結果、リクエストの受け付けが不可能であると判断された場合には、ステップＳ４０５に進む。続いて、ステップＳ４０５では、スケジュールテーブル２０５ａに未登録であることを示す識別子をステップＳ４０１で発行された整理券に付与して未登録整理券とし、リクエストを発行したクライアント装置１０２に対して送信する。続いて、ステップＳ４０６では、スケジューラ１０４は、自機器の状態を通常状態から順番整理状態に移行させる。続いて、ステップＳ４０７では、整理券管理部２０２に対して、後述する未登録整理券有効期限タイマーの開始を指示する。

図５は、スケジュールテーブル２０５ａの管理内容を示した概略図である。
スケジュールテーブル２０５ａには、リクエストＩＤ２０５１、当該リクエストの処理状態２０５２、当該リクエストを指示したクライアント情報２０５３が登録されている。クライアント情報２０５３には、例えばクライアント装置を識別するためのクライアント名やクライアント装置と通信するためのＩＰアドレス等が登録される。

リクエストの処理状態２０５２には、例えば本実施形態では、既にアプリケーションサーバ１０３で処理を行っているリクエストであれば「処理中」とし、アプリケーションサーバ１０３での処理を待っている状態であれば「処理待ち」とする。また、図５に示すスケジュールテーブル２０５ａでは、リクエストの処理状態２０５２について、「処理中」と「処理待ち」の２つの状態を１つの管理テーブルで管理しているが、当該２つの状態を別々の管理テーブルで管理するようにしてもよい。また、リクエストの処理状態２０５２において、「処理中」に移行できるリクエストの数は１個以上であればよく、アプリケーションサーバ１０３の処理能力に合わせて設定するのが理想的である。

図６は、クライアント装置１０２でのリクエスト処理の終了通知を受信した際のスケジューラ１０４における処理を示したフローチャートである。
まず、アプリケーションサーバ管理部２０６は、アプリケーションサーバ１０３からリクエスト処理の終了通知を受信すると、リクエスト管理部２０１に対して、処理が終了したリクエストを特定するための情報、例えば整理番号を送信する。そして、当該情報を受信したリクエスト管理部２０１は、スケジュールテーブル２０５ａから一致するリクエストを特定し、当該リクエストを指示したクライアント装置１０２に対して、当該リクエスト処理の終了を通知する。続いて、ステップＳ６０１では、リクエスト管理部２０１は、スケジュールテーブル２０５ａから当該リクエストを削除する。また、現在アプリケーションサーバ１０３で自己のリクエスト処理を行っているクライアント装置１０２から、当該リクエスト処理の終了通知を受信した場合についても同様に、リクエスト管理部２０１によりスケジュールテーブル２０５ａから該当するリクエストが削除される。

続いて、ステップＳ６０２では、リクエスト数カウンタ２０４の値から「１」を減算する。続いて、ステップＳ６０３では、スケジュールテーブル２０５ａに登録されているリクエストの中に、処理状態２０５２が「処理待ち」のリクエストがあるか否かを判断する。この判断の結果、「処理待ち」の状態のリクエストがあると判断された場合には、ステップＳ６０４に進み、スケジュールテーブル２０５ａに登録されている「処理待ち」のリクエストの中で最も早く登録されているリクエストを指示したクライアント装置１０２に対して、当該リクエスト処理の開始を通知するとともに、当該リクエストの処理状態を「処理中」として、スケジュールテーブル２０５ａに登録する。そして、ステップＳ６０４の処理が終了した後、あるいはステップＳ６０３での判断の結果、「処理待ち」の状態のリクエストがないと判断された後に、スケジューラ１０４におけるクエスト処理終了通知の受信後の処理が終了する。

図６に示した処理により、スケジューラ１０４は、複数のクライアント装置１０２からの複数のリクエストを正確な順序で処理することが可能となるとともに、アプリケーションサーバ１０３の処理負荷を調整することができる。

図７は、整理券管理部２０２で発行される整理券７０１の好適な一例を示した図である。
整理券７０１には、リクエストの順序を示す整理番号７０２と、当該整理券を発行した日時を示す発行日時７０３と、当該整理券がスケジュールテーブル２０５ａに登録されているか否かを示す識別子７０４を含み構成されている。ここで、整理番号７０２は、リクエストの順序が識別できるものであれば形式は問わない。本実施形態では、連続した整数の組み合わせで実現している。

また、発行日時７０３、識別子７０４は、スケジュールに必要以上の負荷をかけず、且つリクエストに対する適切なスケジュール処理を行うという観点では、必ずしも必要ではない。発行日時７０３、識別子７０４は、後述の図１２のフローチャートに示される有効期限判断処理、図１３のフローチャートに示される復旧処理を実行する上で有用となる。また、整理券のデータ形式としては、マークアップ言語記述でも良いし、独自に規定したバイナリーデータでも良い。

また、整理券７０１は、他者に偽造されないように整理券暗号化部２０７で暗号化することが可能である。この暗号化の方法としては、例えば、自装置のみで解読できる独自方式の暗号化方法や、クライアント装置１０２でも解読できる暗号化方法などがある。前者の場合は、識別子７０４のみクライアント装置１０２で解読できればよい。整理券７０１を暗号化した場合には、整理券復号化部２０８で暗号化された整理券を復号することができる。

また、スケジューラ１０４において、整理券内の発行日時７０３によってクライアント装置１０２から送信された整理券が有効かどうかを判断する整理券有効判定手段を設けることも可能である。この整理券有効判定手段では、クライアント装置１０２から送信された整理券の発行日時と、現在発行している最も古い整理券の発行日時と比較し、当該最も古い整理券の発行日時よりも古い整理券は全て無効と判断するようにする。このようにすることで、過去に発行していた整理券におけるリクエストを誤って受諾することを避けるようにすることができる。

図８は、スケジューラ１０４から自己のリクエストに対する整理券を受信した際のクライアント装置１０２における処理を示したフローチャートである。
まず、ステップＳ８０１において、クライアント装置１０２は、リクエスト結果を受信すると、スケジューラ１０４から送信された整理券を保存する。続いて、ステップＳ８０２では、当該整理券がスケジュールテーブル２０５ａに登録された登録済整理券であるか否かを判断する。ここで、この登録済整理券であるかの判断は、整理券７０１における識別子７０４を検出して行う。

ステップＳ８０２での判断の結果、スケジューラ１０４から送信された整理券が登録済整理券であると判断された場合には、ステップＳ８０３に進み、スケジューラ１０４からアプリケーションサーバ１０３へのリクエスト処理の要求を許可し、スケジュールテーブル２０５ａの登録更新の通知がされるまで待機する。

一方、ステップＳ８０２での判断の結果、スケジューラ１０４から送信された整理券が未登録整理券であると判断された場合には、ステップＳステップＳ８０４に進む。続いて、ステップＳ８０４では、予め定められているリトライ間隔の期間だけ待機する。ステップＳ８０４において、リトライ間隔の期間待機した後、続いて、ステップＳ８０５では、スケジューラ１０４に対して再度リクエストを行う。この際、取得した未登録整理券を当該リクエストに添付して送信する。

図９は、スケジューラ１０４において、図３のステップＳ３０５に示す順番整理状態時のリクエスト受信処理を示すフローチャートである。
スケジューラ１０４は、順番整理状態時にクライアント装置１０２からリクエストを受信すると、まず、ステップＳ９０１では、当該リクエストに未登録整理券が添付されているか否かを判断する。この判断の結果、未登録整理券が添付されていないと判断された場合には、ステップＳ９０２に進み、整理券管理部２０２は、新たに整理券を発行し、ステップＳ９０３に進む。続いて、ステップＳ９０３では、ステップＳ９０２で発行した整理券に未登録である識別子を付与して未登録整理券とし、リクエストを発行したクライアント装置１０２に対して送信する。

一方、ステップＳ９０１での判断の結果、未登録整理券が添付されていると判断された場合には、ステップＳ９０４に進む。ステップＳＳ９０４では、当該リクエストに添付されている未登録整理券を整理券管理部２０２に送信し、当該未登録整理券が登録可能な整理券であるか否かを判断する。この判断の結果、登録可能な整理券でないと判断された場合には、ステップＳ９０５に進み、受信した未登録整理券をそのままリクエストを指示したクライアント装置１０２に対して送信する。

一方、ステップＳ９０４での判断の結果、登録可能な整理券であると判断された場合には、ステップＳ９０６に進み、受信したリクエストをスケジュールテーブル２０５ａに登録し、リクエスト数カウンタ２０４の値に「１」を加算する。続いて、ステップ９０７では、未登録整理券の識別子を未登録から登録済に変更して登録済整理券とし、リクエストを発行したクライアント装置１０２に対して送信する。続いて、ステップＳ９０８では、整理券管理部２０２において、未登録整理券の最小整理券番号の更新を行う。

続いて、ステップＳ９０９では、整理券管理部２０２において、未登録整理券が残っているか否かを判断する。この判断の結果、未登録整理券が残っていると判断された場合には、当該順番整理状態時のリクエスト受信処理を終了する。一方、ステップＳ９０９での判断の結果、未登録整理券が残っていないと判断された場合には、ステップＳ９１０に進み、整理券管理部２０２において、未登録整理券の有効期限タイマーを停止した後、当該順番整理状態から通常状態へ処理を移行する。

図１０は、整理券管理部２０２の内部構成を示した概略図である。
図１０に示すように、整理券管理部２０２は、未登録整理券の管理を行う未登録整理券管理部１００１と、発行した最大整理番号を記憶する最大整理番号カウンタ１００２と、現在有効な整理券の最小番号を記憶する最小整理番号カウンタ１００３と、スケジューラ１０４が順番整理状態のときに起動するとともに、順番整理状態から通常状態に移行したときに停止して、未登録整理券の有効期限を管理する未登録整理券有効期限タイマー１００４と、未登録整理券有効期限タイマー１００４のタイマー値が「０」になる度に、どこまでの整理券を無効対象とするかを記憶する次順整理番号カウンタ１００５とを含み構成されている。

整理券発行時には、最大整理番号カウンタ１００２を更新される。また、図９のステップＳ９０４においてリクエスト管理部２０１から受け付け可能な最小整理券の問い合わせがあったときや、リクエスト管理部２０１から受け取った整理番号が最小整理番号カウンタ１００３と一致し、リクエスト管理部２０１に受け付け可能であることを通知したとき、或いは、未登録整理券有効期限タイマー１００４のタイマー値が「０」となって、整理券が無効とされたときに、最小整理番号カウンタ１００３が更新される。

図１１は、スケジューラ１０４の整理券管理部２０２において、未登録整理券が登録可能な整理券であるか否かを問われた際の処理を示したフローチャートである。
まず、ステップＳ１１０１では、スケジュールテーブル２０５ａに空きがあるか否か、即ち登録可能な状態であるか否かを判断する。この判断の結果、スケジュールテーブル２０５ａに空きがあると判断された場合には、ステップＳ１１０２に進む。一方、ステップＳ１１０１での判断の結果、スケジュールテーブル２０５ａに空きがないと判断された場合には、ステップＳ１１０５に進む。

ステップＳ１１０１でスケジュールテーブル２０５ａに空きがあると判断された場合、続いて、ステップＳ１１０２では、問い合わせのあった整理券の整理番号と最小整理番号カウンタ１００３のカウンタ値とを比較して、当該整理番号が最小整理番号カウンタ１００３のカウンタ値以下であるか否かを判断する。この判断の結果、当該整理番号が最小整理番号カウンタ１００３のカウンタ値よりも大きいと判断された場合には、ステップＳ１１０５に進む。一方、ステップＳステップＳ１１０２での判断の結果、当該整理番号が最小整理番号カウンタ１００３のカウンタ値以下であると判断された場合には、ステップＳ１１０３に進む。

続いて、ステップＳ１１０３では、最小整理番号カウンタ１００３のカウンタ値を更新する。続いて、ステップＳ１１０４では、リクエスト管理部２０１に対して整理券が登録可能であることを通知する。

一方、ステップＳ１１０１でスケジュールテーブル２０５ａに空きがないと判断された場合、或いは、ステップＳ１１０２で問い合わせのあった整理券の整理番号が最小整理番号カウンタ１００３のカウンタ値よりも大きいと判断された場合、続いて、ステップＳ１１０５では、問い合わせがあった整理券の整理番号と次順整理番号カウンタ１００５のカウンタ値とを比較し、当該整理番号が次順整理番号カウンタ１００５のカウンタ値よりも小さいか否かを判断する。この判断の結果、当該整理番号が次順整理番号カウンタ１００５のカウンタ値よりも小さいと判断された場合には、ステップＳ１１０６に進む。一方、ステップＳ１１０５での判断の結果、当該整理番号が次順整理番号カウンタ１００５のカウンタ値以上であると判断された場合には、ステップＳ１１０７に進む。

続いて、ステップＳ１１０６では、次順整理番号カウンタ１００５のカウンタ値を問い合わせがあった整理券の整理番号に更新する。続いて、ステップＳ１１０７では、リクエスト管理部２０１に対して、問い合わせがあった整理券におけるリクエストの登録不可を通知する。

このような整理券を用いた管理を行うことによって、スケジュールテーブル２０５ａに空きが無い状態においても、クライアント装置１０２からのリクエストの順序の管理を行うことが可能となる。

ここで、整理券の管理方法としては、上述した管理方法に限定されるわけではなく、例えば、スケジューラ１０４の記憶領域がある限り整理券管理用のテーブルを用いてもよいし、また、最小整理番号を複数有し、スケジュールテーブル２０５ａに空きがある限り登録許可する管理方法も考えられる。

図１２は、整理券管理部２０２の未登録整理券有効期限タイマー１００４を使用した整理券の無効処理を示したフローチャートである。
整理券管理部２０２では、スケジューラ１０４が順番整理状態に移行した段階で未登録整理券有効期限タイマー１００４を開始する。この未登録整理券有効期限タイマー１００４は、クライアント装置１０２の再リクエストまでの待機時間と同期した時間ごとにタイムアップ、即ちタイマー値が「０」になるように設定されている。

未登録整理券有効期限タイマー１００４において、設定時間が経過して、タイムアップとなると、まず、ステップＳ１２０１では、最小整理番号カウンタ１００３のカウンタ値から次順整理番号カウンタ１００５のカウンタ値までの整理券を全て無効整理券として無効とする。続いて、ステップＳ１２０２では、最小整理番号カウンタ１００３のカウンタ値を次順整理番号カウンタ１００５のカウンタ値で更新する。このような処理を行うことにより効率よく無効な整理券を検知して破棄することが可能となる。

続いて、ステップＳ１２０３では、未登録整理券があるか否かを判断する。ここでの判断としては、ステップＳ１２０２で更新された最小整理番号カウンタ１００３のカウンタ値と、最大整理番号カウンタ１００２のカウンタ値とを比較して、両者のカウンタ値が異なる否かで判断される。両者のカウンタ値が異なれば未登録整理券があることになり、両者のカウンタ値が等しければ未登録整理券がないことになる。

ステップＳ１２０３の判断の結果、未登録整理券がある、即ちステップＳ１２０２で更新された最小整理番号カウンタ１００３のカウンタ値と、最大整理番号カウンタ１００２のカウンタ値とが異なるものであると判断された場合には、ステップＳ１２０１に戻って、未登録整理券がないと判断されるまでステップＳ１２０１〜ステップＳ１２０３の処理を繰り返す。一方、ステップＳ１２０３の判断の結果、未登録整理券がない、即ちステップＳ１２０２で更新された最小整理番号カウンタ１００３のカウンタ値と、最大整理番号カウンタ１００２のカウンタ値とが等しいと判断された場合には、ステップＳ１２０４に進んで、未登録整理券有効期限タイマー１００４を停止させた後、順番整理状態から通常状態に移行させて処理を終了する。

また、整理券管理部２０２では、図９のステップＳ９０９において、スケジューラ１０４から未登録整理券が存在するか否かを問い合わせられると、前述した図１２のステップＳ１２０３からの処理を行う。

次に、スケジューラ１０４の起動停止から復旧した際の動作について以下に説明する。
図１３は、スケジューラ１０４において、起動停止から復旧した際の処理を示したフローチャートである。ここで、スケジューラ１０４の起動停止としては、人為的なもの、或いは障害によるものが考えられる。

スケジューラ１０４が起動停止から復旧すると、まず、スケジューラ１０４から各クライアント装置１０２に対して復旧の通知がされる。そして、ステップＳ１３０１では、この復旧の通知後の予め設定されている時間、クライアント装置１０２からのリクエストを受信する。続いて、ステップＳ１３０２では、ステップＳ１３０１で受信したリクエストを仮登録する。

続いて、ステップＳ１３０３では、設定時間が経過したか否かを判断する。この判断の結果、設定時間が経過していないと判断された場合には、ステップＳ１３０１に戻り、設定時間が経過するまでステップＳ１３０１〜ステップＳ１３０３の処理を繰り返す。一方、ステップＳ１３０３での判断の結果、設定時間が経過していると判断された場合には、ステップＳ１３０４に進む。

続いて、ステップＳ１３０４では、仮登録したリクエストを整理券の整理番号順に並べ替える。また、ステップＳ１３０４で並べ替えた整理券の末尾に、リクエストを受け付けた順に整理券がないリクエストを挿入する。

続いて、ステップＳ１３０５では、ステップＳ１３０４で並べ替えた仮登録のリクエストテーブルの先頭から順にスケジュールテーブル２０５ａに登録可能であるか否かを判断する。ここでの判断としては、最大リクエスト数カウンタ２０３とリクエスト数カウンタ２０４を参照することにより行われる。この判断の結果、登録可能であると判断された場合には、ステップＳ１３０６に進み、スケジュールテーブル２０５ａに本登録し、リクエスト数カウンタ２０４を登録したリクエスト数分だけカウントアップし、登録済整理券を新規に発行してリクエストを発行したクライアント装置１０２に対して送信する。

一方、ステップＳ１３０５での判断の結果、登録可能でないと判断された場合には、ステップＳ１３０７に進み、仮登録したリクエストの削除を行うとともに、未登録整理券を新規に発行してリクエストを発行したクライアント装置１０２に対して送信する。続いて、ステップＳ１３０８では、整理券管理部２０２に対して未登録整理券有効期限タイマー１００４の開始を指示する。このとき、スケジューラ１０４は順番整理状態に移行する。また、全ての仮登録リクエストの処理が完了した時点で、全てのリクエストがスケジュールテーブル２０５ａに本登録できた場合は、スケジューラ１０４は通常状態となる。このスケジューラ復旧の処理以降の処理は、前述したリクエストの受付処理を行う。

前述した処理を行うことによって、本実施形態のスケジューラ１０４は、起動停止してスケジュールテーブル２０５ａが初期化されたとしても、復旧後に起動停止前のクライアント装置１０２から受けていたリクエストの順序を再構築することができる。

また、本実施形態のスケジューラ１０４は、クライアント装置１０２からリクエストを受けると、整理券の整理番号について、スケジューラの負荷を軽減しつつクライアント装置からのリクエストの順序管理を厳密に行うことが可能となり、また、スケジューラが起動停止した場合も、起動停止前のリクエスト順序を復旧することが可能となり、より厳密にクライアント装置からのリクエストの順序管理を行うことが可能となる。

（第２の実施形態）
第２の実施形態では、印刷デバイスへスケジュール管理プログラムを組み込んだ場合の、スケジュール処理の具体的な例を説明する。
図１４は、第２の実施形態における情報管理システム（印刷情報管理システム）の概略構成図である。図１と同様の構成には同じ符号を付してある。よって詳しい説明は省略する。以下、図１と異なる構成を中心に説明を行う。

スケジューラ１０４Ａは、印刷デバイス１０３Ａ内に組み込まれており、第１の実施形態の図２で説明したスケジューラ１０４と同等の各種機能を備える。また、印刷デバイス１０３Ａには、例えば、画像形成エンジンとして、電子写真方式、インクジェット方式などを採用したプリンタを適用することができる。

また、本実施形態におけるスケジューラ１０４Ａが管理する各種リクエストは、例えば印刷デバイス１０３Ａでの印刷リクエストや、印刷ジョブリスト取得リクエスト、印刷ジョブの削除や一時停止などのオペレーションリクエスト、接続、切断リクエストなどが考えられる。なお、リクエストの種類は上記リクエストに限らず、複数のクライアントから受け付けるリクエスト処理に順序性が必要なものであれば、本発明による効果を得ることができる。

次に、印刷デバイス１０３Ａに組み込まれているスケジューラ１０４Ａによる、印刷リクエストの制御手順を、図１５のフローチャートを用いて説明する。

図１５では、複数のクライアント装置１０２と、スケジューラ１０４Ａ及びアプリケーションサーバ機能が組み込まれた印刷デバイス１０３Ａとがネットワーク１０１を介して通信可能に接続されている。そして、印刷デバイス１０３Ａは、第１の実施形態で説明した図３のフローチャートを実行し、何れかのクライアント装置からの印刷処理リクエストを待機する。以下、各ステップについて具体的に説明を行う。

クライアント装置１０２は、印刷処理を行うのにあたり、まず、印刷デバイス１０３Ａのスケジューラ１０４Ａに対して、印刷処理リクエストをネットワーク１０１を介して出力する（Ｓ１５０１）。

印刷処理リクエストを受けたスケジューラ１０４Ａは、第１の実施形態にて詳しく説明した印刷処理クエストの登録可否の判断を図３のフローチャートで説明したように実行し、必要な場合には整理券の発行を行う。

ここで、印刷リクエストの登録を不可と判断した場合には、第１の実施の形態で説明した、図９、図１１、図１２及び図１３のフローチャートに従う処理を実行する。なお、印刷リクエストの登録が不可と判断される場合とは、例えば、既に管理テーブルに制限数まで各種リクエストが登録されている場合や、スケジューラ１０４Ａが利用可能な記憶領域に空きが無い場合、スケジューラ１０４Ａの処理パフォーマンスが劣化すると判断された場合等がある。そして、印刷デバイス１０３Ａのスケジューラ１０４Ａは、このような場合に、順番制御のための管理テーブルに空きがないと判断する。

一方、クライアント装置１０２からの印刷リクエストを登録できた場合には、スケジューラ１０４Ａは、図４に従う処理を実行する。より具体的には、まず、スケジューラ１０４Ａは、リクエストの登録順番に従い、各リクエストに対応する順序制御を実行する（Ｓ１５０２）。そして、クライアント装置１０２で生成された印刷ジョブが受信可能になると、スケジューラ１０４Ａは、クライアント装置１０２に対して印刷ジョブの転送開始指示を通知する（Ｓ１５０３）。

印刷デバイス１０３Ａの印刷ジョブ格納メモリは、容量が少ないことが想定される。つまり、他のクライアント装置からの印刷ジョブの印刷処理が終了し、印刷ジョブが印刷ジョブ格納メモリから解放され、印刷ジョブを受信するに充分な印刷ジョブ格納領域が確保された場合に、Ｓ１５０３の通知がクライアント装置１０２に対して行われる。

続いて、スケジュール１０４Ａから印刷ジョブの転送開始指示をを受けたクライアント装置１０２は、自装置に保持しておいた印刷ジョブを印刷デバイス１０３Ａのプリンタコントローラ（アプリケーションサーバ１０３の一部に相当）に転送する（Ｓ１５０４）。

続いて、印刷ジョブをプリンタコントローラを介して受信した印刷デバイス１０３Ａは、受信した印刷ジョブに基づく印刷出力をプリンタエンジンにより行う。そして、印刷出力を含む印刷ジョブの印刷処理が終了したことに応じて、スケジューラ１０４Ａに対して印刷処理終了を通知する（Ｓ１５０５）。そして、プリンタコントローラより印刷処理終了通知を受けたスケジューラ１０４Ａは、Ｓ１５０１における印刷処理リクエストを出力したクライアント装置１０２に対して、印刷処理終了を通知する（Ｓ１５０６）。

（他の実施形態）
本実施形態のスケジューラ１０４としては、図２に示した各構成要素を備えていればいかなる構成であってもよく、例えば、アプリケーションサーバやデバイスに直接組み込んだ形式や、複数のアプリケーションサーバやデバイスを１台のスケジューラで管理する形式で用いてもよい。

本発明の実施形態は、例えば、図３のステップＳ３０１〜ステップＳ３０５、図４のステップＳ４０１〜ステップＳ４０７、図６のステップＳ６０１〜ステップＳ６０４、図８のステップＳ８０１〜ステップＳ８０５、図９のステップＳ９０１〜ステップＳ９１０、図１１のステップＳ１１０１〜ステップＳ１１０７、図１２のステップＳ１２０１〜ステップＳ１２０４、図１３のステップＳ１３０１〜ステップＳ１３０８の各処理のプログラムをコンピュータが実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段としては、例えば、かかるプログラムを記録したＣＤ−ＲＯＭ、ＤＶＤ、メモリ、ハードディスク等のコンピュータ読み取り可能な記録媒体や、かかるプログラムを伝送するインターネットやＬＡＮ等の伝送媒体が挙げられる。以上、本発明の実施形態について、図面を参照して詳述してきたが、具体的な構成は前述した実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲で適宜変更可能である。

本実施形態によれば、各クライアント装置１０２からリクエストを受信した場合に、指示された順序に基づいてリクエストを管理するスケジュールテーブル２０５ａに空きがあるか否かを判断し（ステップＳ４０２）、スケジュールテーブル２０５ａに空きがあると判断された場合に、当該リクエストをスケジュールテーブル２０５ａに登録し（ステップＳ４０３）、スケジュールテーブル２０５ａに空きがないと判断された場合に、当該リクエストがスケジュールテーブル２０５ａに未登録であることを示す未登録整理券を発行し、この未登録整理券を当該リクエストの送信元のクライアント装置１０２に対して送信する（ステップＳ４０５）ようにしたので、各クライアント装置１０２から多数のリクエストが指示された場合においても、許容範囲以上の負荷をかけることなく、当該リクエストが指示された順序で各リクエストの処理を行うことができる。

また、スケジューラ１０４が起動停止から復旧した際に、各クライアント装置１０２に対して復旧の通知を行い、当該復旧の通知から所定時間内に各クライアント装置１０２から指示されたリクエストを、当該リクエストの整理番号に応じた順序で整列させ（ステップＳ１３０４）、整列されたリクエストの順序にしたがって登録済整理券を発行する（ステップＳ１３０６）ようにしたので、スケジューラ１０４の起動停止によりスケジュールテーブル２０５ａが初期化された場合でも、起動停止前に登録されていたリクエストの順序で各リクエストの処理を行うことができる。

第１の実施形態における情報管理システムの概略構成図である。 スケジューラの内部構成を示した概略図である。 クライアント装置からリクエストを受信した際のスケジューラにおける処理を示したフローチャートである。 スケジューラにおいて、図３のステップＳ３０４に示す通常状態時のリクエスト受信処理を示すフローチャートである。 スケジュールテーブルの管理内容を示した概略図である。 クライアント装置でのリクエスト処理の終了通知を受信した際のスケジューラにおける処理を示したフローチャートである。 整理券管理部で発行される整理券の好適な一例を示した図である。 スケジューラから自己のリクエストに対する整理券を受信した際のクライアント装置における処理を示したフローチャートである。 スケジューラにおいて、図３のステップＳ３０５に示す順番整理状態時のリクエスト受信処理を示すフローチャートである。 整理券管理部の内部構成を示した概略図である。 スケジューラの整理券管理部において、未登録整理券が登録可能な整理券であるか否かを問われた際の処理を示したフローチャートである。 整理券管理部の未登録整理券有効期限タイマーを使用した整理券の無効処理を示したフローチャートである。 スケジューラにおいて、起動停止から復旧した際の処理を示したフローチャートである。 第２の実施形態における情報管理システム（印刷情報管理システム）の概略構成図である。 図１４の印刷情報管理システムにおけるクライアント装置及び印刷デバイス間の処理を示すシーケンス図である。

符号の説明

１０１、１０５ ネットワーク
１０２ クライアント装置
１０３ アプリケーションサーバ
１０３Ａ 印刷デバイス
１０４、１０４Ａ スケジューラ（情報管理装置）
２０１ リクエスト管理部
２０２ 整理券管理部
２０３ 最大リクエスト数カウンタ
２０４ リクエスト数カウンタ
２０５ スケジュールテーブル（管理テーブル）記憶部
２０５ａ スケジュールテーブル
２０６ アプリケーションサーバ管理部
２０７ 整理券暗号化部
２０８ 整理券復号化部
７０１ 整理券
７０２ 整理番号
７０３ 発行日時
７０４ 識別子
１００１ 未登録整理券管理部
１００２ 最大整理番号カウンタ
１００３ 最小整理番号カウンタ
１００４ 未登録整理券有効期限タイマー
１００５ 次順整理番号カウンタ

Claims (18)

1. クライアント装置からリクエストを受信する受信手段と、
   前記クライアント装置から送信された各リクエストを、その指示された順序に基づいて管理する管理テーブルを記憶する管理テーブル記憶手段と、
   前記受信手段でリクエストを受信した場合に、前記管理テーブルに登録できるか否かを判断する判断手段と、
   前記判断手段により前記管理テーブルに登録できると判断された場合に、当該リクエストを前記管理テーブルに登録する登録手段と、
   前記判断手段により前記管理テーブルに登録できないと判断された場合に整理券を発行し、当該リクエストの送信元のクライアント装置に対して前記整理券を送信する整理券発行手段と
   を有することを特徴とする情報管理装置。
2. 前記整理券発行手段は、前記登録手段により登録されたリクエストについて、当該リクエストが前記管理テーブルに登録済であることを示す登録済整理券を発行し、当該リクエストの送信元のクライアント装置に当該登録済整理券を送信することを特徴とする請求項１に記載の情報管理装置。
3. 前記整理券発行手段は、前記整理券の発行に際して、前記管理テーブルに未登録となったリクエストの順序に応じた整理番号を当該整理券に付することを特徴とする請求項１又は２に記載の情報管理装置。
4. 前記管理テーブルに登録されているリクエストの処理順序を管理する順序管理手段と、
   前記順序管理手段による管理により処理順序となったリクエストの送信元のクライアント装置に対して、当該リクエストの実行を許可するリクエスト許可手段と
   を更に有することを特徴とする請求項１〜３のいずれか１項に記載の情報管理装置。
5. 前記整理券発行手段による前記整理券の発行がされた後に、前記判断手段により前記管理テーブルに新たにリクエストの登録ができると判断された場合、新たに登録可能な前記整理券を設定する設定手段を更に有し、
   前記登録手段は、前記設定手段により設定された前記整理券におけるリクエストを前記管理テーブルに登録することを特徴とする請求項１〜４のいずれか１項に記載の情報管理装置。
6. 前記整理券発行手段は、前記整理券に有効期限を設けて発行するものであり、当該有効期限を経過した整理券を無効とすることを特徴とする請求項１〜５のいずれか１項に記載の情報管理装置。
7. 自機器が起動停止から復旧した際に、前記クライアント装置に対して復旧を通知する復旧通知手段と、
   前記復旧通知手段による通知から所定時間内に前記クライアント装置から指示されたリクエストを、当該リクエストの整理番号に応じた順序で整列するリクエスト整列手段とを更に備え、
   前記整理券発行手段は、前記リクエスト整列手段により整列されたリクエストの順序にしたがって前記登録済整理券を発行することを特徴とする請求項２に記載の情報管理装置。
8. 前記整理券発行手段により発行される整理券を暗号化する暗号化手段と、
   前記暗号化手段により暗号化された整理券を復号化する復号化手段と
   を更に有することを特徴とする請求項１〜７のいずれか１項に記載の情報管理装置。
9. 請求項１〜８のいずれか１項に記載の情報管理装置と、
   前記情報管理装置にリクエストを送信するクライアント装置と
   を有することを特徴とする情報管理システム。
10. クライアント装置からリクエストを受信する受信ステップと、
    前記受信ステップでリクエストを受信した場合に、前記クライアント装置から送信された各リクエストを、その指示された順序に基づいて管理する管理テーブルに登録できるか否かを判断する判断ステップと、
    前記判断ステップにより前記管理テーブルに登録できると判断された場合に、当該リクエストを前記管理テーブルに登録する登録ステップと、
    前記判断ステップにより前記管理テーブルに登録できないと判断された場合に整理券を発行し、当該リクエストの送信元のクライアント装置に対して前記整理券を送信する整理券発行ステップと
    を有することを特徴とする情報管理方法。
11. 前記登録ステップにより登録されたリクエストについて、当該リクエストが前記管理テーブルに登録済であることを示す登録済整理券を発行し、当該リクエストの送信元のクライアント装置に当該登録済整理券を送信する登録済整理券発行ステップを更に有することを特徴とする請求項１０に記載の情報管理方法。
12. 前記整理券発行ステップでは、前記整理券の発行に際して、前記管理テーブルに未登録となったリクエストの順序に応じた整理番号を当該整理券に付することを特徴とする請求項１０又は１１に記載の情報管理方法。
13. 前記管理テーブルに登録されているリクエストのうち、処理順序となったリクエストの送信元のクライアント装置に対して、当該リクエストの実行を許可するリクエスト許可ステップを更に有することを特徴とする請求項１０〜１２のいずれか１項に記載の情報管理方法。
14. 前記整理券発行ステップによる前記整理券の発行がされた後に、前記判断ステップにより前記管理テーブルに新たにリクエストの登録ができると判断された場合、新たに登録可能な前記整理券を設定する設定ステップを更に有し、
    前記登録ステップでは、前記設定ステップにより設定された前記整理券におけるリクエストを前記管理テーブルに登録することを特徴とする請求項１０〜１３のいずれか１項に記載の情報管理方法。
15. 前記整理券発行ステップでは、前記整理券に有効期限を設けて発行するものであり、当該有効期限を経過した整理券を無効とすることを特徴とする請求項１０〜１４のいずれか１項に記載の情報管理方法。
16. 自機器が起動停止から復旧した際に、前記クライアント装置に対して復旧を通知する復旧通知ステップと、
    前記復旧通知ステップによる通知から所定時間内に前記クライアント装置から指示されたリクエストを、当該リクエストの整理番号に応じた順序で整列するリクエスト整列ステップとを更に備え、
    前記登録済整理券発行ステップでは、前記リクエスト整列ステップにより整列されたリクエストの順序にしたがって前記登録済整理券を発行することを特徴とする請求項１１に記載の情報管理方法。
17. 前記整理券発行ステップで発行される前記整理券、及び前記登録済整理券発行ステップで発行される前記登録済整理券のうち、少なくともいずれか一方の整理券を暗号化する暗号化ステップと、
    前記暗号化ステップにより暗号化された整理券を復号化する復号化ステップと
    を更に有することを特徴とする請求項１１に記載の情報管理方法。
18. クライアント装置からリクエストを受信する受信手順と、
    前記受信手順でリクエストを受信した場合に、前記クライアント装置から送信された各リクエストを、その指示された順序に基づいて管理する管理テーブルに登録できるか否かを判断する判断手順と、
    前記判断手順により前記管理テーブルに登録できると判断された場合に、当該リクエストを前記管理テーブルに登録する登録手順と、
    前記判断手順により前記管理テーブルに登録できないと判断された場合に整理券を発行し、当該リクエストの送信元のクライアント装置に対して前記整理券を送信する整理券発行手順と
    をコンピュータに実行させるためのプログラム。

Images