JP2008269004A - データ処理装置、データ処理方法、およびコンピュータプログラム - Google Patents

Abstract

【課題】発生時刻が不確定な複数の処理要求を受けて、それらを一定の資源を使用して処理するシステムにおいて、過度の処理遅れが生じる可能性を低減する。
【解決手段】リクエストに応じて所定のデータ処理を行うデータ処理装置であって、以下のような構成を備える。すなわち、このデータ処理装置は、リクエストを受け取る受付部と、受け取ったリクエストに応じた処理を行う処理部と、受け取ったリクエストの送信元に返信を行う返信部と、を備える。そして、返信部は、処理部における処理が行われなかった旨の返信を行う場合には、処理が行われなかったリクエストを識別するための識別データを付加して送信元に返信する。処理部は、受け取ったリクエストであって識別データを含まない第１種のリクエストの処理よりも、受け取ったリクエストであって識別データを含む第２種のリクエストの処理を優先的に行う。
【選択図】図３

Description

この発明は、サーバへの処理要求を取り扱う技術に関する。

従来より、ネットワークに接続された複数の機器と、ネットワークを介してそれらの機器（端末）を管理するサーバと、で構成されるシステムが存在する。そのようなシステムにおいて、各機器は、状況に応じてサーバに対してリクエストを送信する。サーバは、各機器からのリクエストを受信し、リクエストに応じてサーバ内で所定の処理を実行する。また、サーバは、ネットワークを介して外部に対してリクエストに応じたデータを送信する。

上記のようなシステムにおいては、各機器からサーバへのリクエストが集中した場合には、サーバがすべてのリクエストを処理しきれなくなる場合がある。そのような場合には、処理を行うことができないリクエストについては、そのリクエストを行った機器に対して、「処理が行われなかった旨の返信」（「処理失敗」の返信）がなされる。そして、その機器は、一定の時間が経過した後、再びサーバに対してリクエストを行う。しかし、再度のリクエストがサーバにおいて必ずしも処理されるとは限らず、何度も「処理が行われなかった旨の返信」がなされる場合がある。

そのような事態を防止するための方法として、たとえば、以下のような方法がある。すなわち、時間を時間軸に沿って複数種類のタイムスロットに区分する。そして、機器ごとにサーバに対してリクエストを送信できるタイムスロットを定める（特許文献１）。この方法によれば、各機器のリクエストが各タイムスロットに分散されるため、サーバにリクエストが集中することを、ある程度、防止できる。

特開２００６−３３０７０号公報

しかし、１日のうちのある特定の時間帯にリクエストが集中するシステムにおいては、その時間帯に含まれる各タイムスロットにおいてやはりサーバにリクエストが集中する。そして、サーバが処理しきれなくなったリクエストを行った機器に対しては、やはり、「処理が行われなかった旨の返信」がなされる。すなわち、このよう態様のシステムにおいては、依然として、同じリクエストに対して何度も「処理が行われなかった旨の返信」がなされるという問題が生じうる。

また、上記の態様においては、リクエストが集中する時間帯を過ぎても、その機器に割り当てられたタイムスロットがくるまでは、再リクエストを行うことができない。このため、リクエストの待ち時間が不必要に長くなる。

さらに、２４時間稼働しているシステムにおいては、緊急を要する処理のリクエストを次のタイムスロットにおいて行うこととしても時間遅れが過度に大きくなる可能性は低い。しかし、たとえば、毎日、夜１１時から翌朝の５時までは休止するシステムにおいては、ある機器に割り当てられた最後のタイムスロットの後に、その機器に緊急の処理を要するリクエストをすべき事態が生じた場合には、その処理は、大幅に遅れて翌朝にサーバで処理されることとなる。

このような問題は、複数の機器から、発生時刻が不確定な処理要求を含む複数の処理要求を受けて、一定の資源を使用して処理要求に応じた処理を行うシステムにおいて、広く生じうる。

本発明は、上述した従来の課題の少なくとも一部を取り扱うためになされたものであり、複数の機器から発生時刻が不確定な処理要求を受けて、一定の資源を使用して処理要求に応じた処理を行うシステムにおいて、過度の処理の遅れが生じる可能性を低減することを目的とする。

本発明の一態様としてのデータ処理装置は、リクエストに応じて所定のデータ処理を行うデータ処理装置であって、以下のような構成を備える。すなわち、データ処理装置は、リクエストを受け取る受付部と、受け取ったリクエストに応じた処理を行う処理部と、受け取ったリクエストの送信元に返信を行う返信部と、を備える。そして、返信部は、処理部における処理が行われなかった旨の返信を行う場合には、処理が行われなかったリクエストを識別するための識別データを付加して送信元に返信する。処理部は、受け取ったリクエストであって識別データを含まない第１種のリクエストの処理よりも、受け取ったリクエストであって識別データを含む第２種のリクエストの処理を優先的に行う。

このような態様とすれば、過去に処理が行われなかった旨の返信がされたリクエストについては、そうではないリクエストよりも、優先的に処理が行われる。このため、識別データを使用しない態様に比べて、リクエストについて過度の処理遅れが生じる可能性を低減することができる。

なお、返信部と送信部は、同一のモジュールによって実現されてもよい。また、優先的な処理を行うか否かは、処理部が決定することとしても良いし、他のモジュールがその決定を行い、その決定に従って処理部がリクエストを処理することとしてもよい。

なお、処理部は、第１種および第２種のリクエストの処理を実行するための第１の処理部と、第２種のリクエストの処理を実行するための第２の処理部であって、第１種のリクエストの処理には使用されない第２の処理部と、を備えることが好ましい。そして、第２の処理部を使用して優先的な処理を行うことができる。

このような態様とすれば、簡易な構成で、第２種のリクエストについて、優先的な処理を行うことができる。

また、処理部は、受付部が第２種のリクエストを受け取った場合であって、処理部が１以上の第１種のリクエストの処理を実行中である場合には、少なくとも一つの第１種のリクエストの処理を中止して、第２種のリクエストの処理を実行することもできる。

このような態様とすれば、第２種のリクエストの処理のために専用の資源を確保する態様に比べて、処理を実行するための資源を効率的に活用して、処理を実行することができる。このため、全体として、処理に要する時間を短くすることができる。

なお、識別データは、有効期限に関する情報を含むことができる。そして、処理部は、有効期限が過ぎた識別データを含むリクエストについては、第１種のリクエストとして扱うことがこのましい。

このような態様とすれば、長期にわたって再リクエストをおこたっていた機器からのリクエストを、優先的に処理することによって、他のリクエストの処理が遅れる事態を防止することができる。

また、識別データは、優先度に関する情報を含むことができる。そして、処理部は、第２種のリクエストの処理のうち、第１の優先度を表す情報を含むリクエストの処理よりも、第１の優先度より高い第２の優先度を表す情報を含むリクエストの処理を優先的に行うことが好ましい。

このような態様とすれば、たとえば、エラー情報に関するリクエストなどの処理に緊急を要する処理を、他の処理と区別して、さらに優先的に処理することができる。

なお、識別データは、受け取ったリクエストについて処理部における処理が行われなかった旨の返信が行われた回数に関する情報を含むことができる。そして、処理部は、第２種のリクエストの処理のうち、第１の回数を表す情報を含むリクエストの処理よりも、第１の回数より高い第２の回数を表す情報を含むリクエストの処理を優先的に行うことが好ましい。

このような態様においては、あるリクエストについて、処理が行われなかった旨の返信が行われた回数が増大するほど、そのリクエストは優先的に処理されることとなる。このため、リクエストの処理が過度に遅れる事態を防止することができる。

また、データ処理装置であって、さらに、処理の優先度を表す優先度データであって、各識別データと対応づけられた優先度データを格納する優先度データ格納部を備えることが好ましい。そして、処理部は、第２種のリクエストの処理のうち、第１の優先度を表す優先度データに対応づけられた識別データを含むリクエストの処理よりも、第１の優先度より高い第２の優先度を表す優先度データに対応づけられた識別データを含むリクエストの処理を優先的に行うことが好ましい。

このような態様とすれば、返信を受け取った側で優先度を改変する不正行為が行われる事態を防止することができる。

なお、本発明は、種々の態様で実現することが可能である。例えば、データ処理装置、データ処理システム、データ処理方法、リクエストの処理方法、それらの装置および方法の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の態様で実現することができる。

Ａ．第１実施例：
Ａ１．全体の構成：
図１は、本発明の実施例であるプリンタ管理システム１０００の構成を示す説明図である。このプリンタ管理システム１０００においては、第１のネットワークシステム１１００と、第２のネットワークシステム１２００と、第３のネットワークシステム１３００と、がインターネットＩＮＥＴを介して互いに接続されている。

第１のネットワークシステム１１００は、たとえば、ある会社の社内ネットワークシステムである。この第１のネットワークシステム１１００においては、クライアントＣＬ１１，ＣＬ１２と、プリンタＰＲＴ１１〜ＰＲＴ１３と、がローカルエリアネットワークＬＡＮ１によって接続されている。この第１のネットワークシステム１１００は、ファイアウォールＦＷ１を介してインターネットＩＮＥＴに接続されている。

なお、図１においては、プリンタＰＲＴ１１〜ＰＲＴ１３のうち、代表してプリンタＰＲＴ１１のみについて詳細な構成を示す。しかし、プリンタＰＲＴ１２，ＰＲＴ１３もプリンタＰＲＴ１１と同様の構成を有する。また、本実施例において単純に「プリンタ」と呼称しているデバイスは、ＦＡＸ、スキャナ、コピーなどの各種の機能を備える、いわゆる「複合機」を含みうる。図１のプリンタＰＲＴ１１においては、プリンタＰＲＴ１１が有するそれら各種の構成および機能のうち、一部のみを示す。

第１のネットワークシステム１１００を構成する各デバイス間の通信は、ＴＣＰ／ＩＰプロトコルに従って行われる。ＴＣＰ／ＩＰプロトコルでは、各デバイスのそれぞれにＩＰアドレスが割り当てられる。あるデバイスから発信された通信データには、発信元のデバイスのＩＰアドレス（発信元ＩＰアドレス）と、送信先のデバイスのＩＰアドレス（送信先ＩＰアドレス）とが含まれている。通信データは、送信先ＩＰアドレスに従って、そのＩＰアドレスを有するデバイスに送信される。

たとえば、クライアントＣＬ１１は、印刷ジョブをプリンタＰＲＴ１１に送信する。プリンタＰＲＴ１１は、クライアントＣＬ１１から送信された印刷ジョブに従って印刷を実行する。第１のネットワークシステム１１００のクライアントＣＬ１１，ＣＬ１２は、第１のネットワークシステム１１００の任意のプリンタＰＲＴ１１〜ＰＲＴ１３に対して、印刷ジョブを送信することができる。

第２のネットワークシステム１２００は、たとえば、第１のネットワークシステム１１００の会社とは異なる会社の社内ネットワークシステムである。第２のネットワークシステム１２００においては、クライアントＣＬ２１と、プリンタＰＲＴ２１，ＰＲＴ２２と、がローカルエリアネットワークＬＡＮ２によって接続されている。この第２のネットワークシステム１１００は、ファイアウォールＦＷ２を介してインターネットＩＮＥＴに接続されている。

第２のネットワークシステム１２００のプリンタＰＲＴ２１，ＰＲＴ２２は、印刷機能、および第３のネットワークシステム１３００の管理サーバＳＶとの関係に関する機能に関しては、第１のネットワークシステム１１００のプリンタＰＲＴ１１〜ＰＲＴ１３構成および機能を有する。また、第２のネットワークシステム１２００のクライアントＣＬ２１は、印刷に関する機能、および第３のネットワークシステム１３００の管理サーバＳＶとの関係に関する機能については、それぞれ第１のネットワークシステム１１００のクライアントＣＬ１１，ＣＬ１２と同様の構成および機能を有する。

第３のネットワークシステム１３００においては、ローカルエリアネットワークＬＡＮ３に管理サーバＳＶが接続されている。第３のネットワークシステム１３００は、ファイアウォールを介さずにインターネットＩＮＥＴに接続されている。

管理サーバＳＶは、インターネットを介して、第１のネットワークシステム１１００のプリンタＰＲＴ１１〜ＰＲＴ１３、ならびに第２のネットワークシステム１２００のプリンタＰＲＴ２１，２２からリクエストを受け取って、それらのリクエストに応じた所定の処理を行う。そして、処理結果を各プリンタＰＲＴ１１〜ＰＲＴ２２に送信する。

具体的には、管理サーバＳＶは、各プリンタから、各プリンタの状態に関する情報を伴ったリクエストを受け取って、各プリンタの状態を管理する。たとえば、各プリンタの電源投入時に、各プリンタから「機器構成に関する情報」を伴ったリクエストを受け取って、管理サーバＳＶは、それらの情報を管理する。

また、管理サーバＳＶは、各プリンタの状態に応じて、図示しない他の端末にＬＡＮ３またはインターネットを介して所定のデータを送信することができる。たとえば、あるプリンタから「エラーが発生した旨の情報」を受け取った場合には、管理サーバＳＶは、管理会社の端末に、エラーの内容とサポート員を派遣すべき旨の指示を送る。

なお、ファイアウォールを有するネットワークシステム１１００，１２００との情報のやりとりは、プリンタ側からサーバに送られるリクエストと、そのリクエストに対する返信（レスポンス）の形で行われる。このため、管理サーバＳＶは、ファイアウォールＦＷ１，ＦＷ２に阻害されることなく、第１のネットワークシステム１１００および第２のネットワークシステム１２００と情報のやりとりを行うことが可能である。

なお、各プリンタＰＲＴ１１〜ＰＲＴ１３，ＰＲＴ２１，ＰＲＴ２２と、管理サーバＳＶとの間の通信は、ＨＴＴＰ（hyper text transfer protocol）を用いて行われる。この通信は、ＨＴＴＰの一種であるＨＴＴＰＳプロトコルによる暗号化通信でおこなわれるものとする。

Ａ２．プリンタおよび管理サーバの構成および動作：
以下では、プリンタおよび管理サーバＳＶの構成および動作について説明する。プリンタの構成および動作についてはプリンタＰＲＴ１１を例に説明する。しかし、プリンタＰＲＴ１１〜ＰＲＴ２２は、印刷機能、および第３のネットワークシステム１３００の管理サーバＳＶとの関係に関する機能に関しては、いずれも同様の構成を備え、同様に動作する。

第１のネットワークシステム１１００プリンタＰＲＴ１１は、ネットワークボード１１０と、プリンタ制御部１２０と、プリントエンジン１３０と、を備えている。ネットワークボード１１０と、プリンタ制御部１２０は、それぞれ、図示しない中央処理装置（ＣＰＵ）とメモリとを備えるコンピュータとして構成されている。プリントエンジン１３０は、与えられた印刷データに応じて印刷を実行する印刷機構である。

ネットワークボード１１０は、通信制御部１１２と、印刷ジョブ処理部１１４と、ＳＮＭＰエージェント１１６と、リクエスト送信部１１８と、を備えている。通信制御部１１２は、ネットワークボード１１０が備えるネットワークインターフェース（図示しない）を制御することにより、ローカルエリアネットワークＬＡＮ１に接続されたクライアントＣＬ１１，ＣＬ１２等のデバイスとの間でのＴＣＰ／ＩＰプロトコルに従った通信を行う。

通信制御部１１２は、クライアントＣＬ１１，ＣＬ１２からの印刷ジョブを含む通信データを受け取ると、受け取った通信データを印刷ジョブ処理部１１４に供給する。印刷ジョブ処理部１１４は、受け取った通信データからページ記述言語等で記述された文書データを抽出し、プリンタ制御部１２０に供給する。プリンタ制御部１２０は、文書データに基づいて印刷データを生成し、印刷データをプリントエンジン１３０に供給する。そして、プリントエンジン１３０は供給された印刷データに応じて印刷を実行する。

ＳＮＭＰエージェント１１６は、プリンタＰＲＴ１１に関する種々の情報を管理情報として収集して、メモリ上の管理データファイル１４０に格納する。管理データファイル１４０には、（１）プリンタＰＲＴ１１の機器構成に関する第１の情報、（２）プリンタＰＲＴ１１において使用された紙の種類および枚数に関する第２の情報、（３）完了した印刷ジョブに関する第３の情報、そして、（４）発生したエラーおよび解消したエラーに関する第４の情報が格納される。なお、これら第１〜第４の情報をまとめてプリンタの「管理情報」と呼ぶ。

これらの第１〜第４の情報は、それぞれ個別のファイルの形で管理データファイル１４０の一部として保持される。格納すべき情報がない場合には、各ファイルは生成されない。

たとえば、ＳＮＭＰエージェント１１６は、プリンタＰＲＴ１１の電源が投入されたときに、プリンタＰＲＴ１１の機器構成を確認し、第１の情報に関するファイルを生成する。また、ＳＮＭＰエージェント１１６は、８時間おきに、プリンタＰＲＴ１１において使用された紙の種類および枚数の情報をプリンタ制御部１２０から情報を受け取って、新たに第２の情報に関するファイルを生成する。

そして、ＳＮＭＰエージェント１１６は、プリンタ制御部１２０がプリントエンジン１３０への印刷データの供給を完了したタイミングで、プリンタ制御部１２０からその情報を受け取って、第３の情報に関するファイルを新たに生成する。さらに、ＳＮＭＰエージェント１１６は、紙詰まりエラーやセンサのエラー等が発生すると、プリンタ制御部１２０からその情報を受け取って、第４の情報に関するファイルを生成する。これらのファイルの生成、すなわち管理情報の更新の処理は、たとえば、ＳＮＭＰエージェント１１６が所定のタイミングでプリンタ制御部１２０に対して情報を要求することによって、開始される。

第３のネットワークシステム１３００の管理サーバＳＶは、通信制御部３１０と、管理情報データベース３２０と、データベース管理部３３０と、を備えている。通信制御部３１０は、図示しないネットワークインターフェースを制御することにより、インターネットＩＮＥＴを介したプリンタＰＲＴ１１〜ＰＲＴ２２との通信を行う。

管理情報データベース３２０は、管理サーバＳＶの外部記憶装置上に構築されている。管理情報データベース３２０には、プリンタＰＲＴ１１〜ＰＲＴ２２から取得された管理情報、すなわち（１）プリンタＰＲＴ１１の機器構成に関する第１の情報、（２）プリンタＰＲＴ１１において使用された紙の種類および枚数に関する第２の情報、（３）完了した印刷ジョブに関する第３の情報、そして、（４）発生したエラーおよび解消したエラーに関する第４の情報が格納される。

データベース管理部３３０は、リクエスト受付部３３２と、優先処理制御部３３４と、処理部３３６と、を備えている。リクエスト受付部３３２は、プリンタＰＲＴ１１〜ＰＲＴ２２から管理サーバＳＶに送信されるリクエストを取得する。また、リクエスト受付部３３２は、そのリクエストに対応する返信（レスポンス）をリクエストの送信元であるプリンタに送信する。なお、上述のように、各プリンタＰＲＴ１１〜ＰＲＴ２２から管理サーバＳＶへの管理情報の送信は、ＨＴＴＰにより行われる。そのため、リクエスト受付部３３２は、ＨＴＴＰサーバとしての機能を有している。

処理部３３６は、プリンタから受信したリクエストに基づいて、管理情報データベース３２０に格納された管理情報の更新や管理情報データベース３２０への管理情報の追記等のデータベースの操作を行う。

この処理部３３６は、リクエストに基づく管理情報データベース３２０の操作に関して、２種類の処理を並行して行う。第１種の処理は、プリンタからの管理情報を伴う任意のリクエストに基づいて行う管理情報データベース３２０の操作である。そして、第２種の処理は、プリンタからの管理情報を伴うリクエストであって、優先チケットを伴うリクエストに基づいて行うデータベースの操作である。以下では、優先チケットを伴わないリクエストを「第１種のリクエスト」と呼ぶ。優先チケットを伴うリクエストを「第２種のリクエスト」と呼ぶ。なお、「優先チケット」とは、過去に処理が行われなかったために優先的に処理すべきリクエストを、そうではないリクエストと識別するためのデータである。

第１種の処理のために使用できる資源の量（ＣＰＵの処理能力やメモリの容量）と、第２種の処理のために使用できる資源の量とは、あらかじめ定められている。たとえば、処理部３３６が管理情報データベース３２０の操作のために使用できるメモリのうち７０％が、第１種の処理のために使用される。そして、処理部３３６が管理情報データベース３２０の操作のために使用できるメモリのうち残りの３０％が、第２種の処理のために使用される。以下、第１種の処理に使用されるメモリを、便宜的に「第１のメモリ３３６ａ」と呼ぶ。第２種の処理に使用されるメモリを、便宜的に「第２のメモリ３３６ｂ」と呼ぶ。

たとえば、第１のメモリ３３６ａが多数の第１種の処理のために使用されており、それ以上、処理を実行できない場合には、優先チケットを伴わない第１種のリクエストに基づく第１種の処理は実行されない。これに対して、優先チケットを伴う第２種のリクエストに基づく第２種の処理については、第１のメモリ３３６ａを使用して処理できない場合にも、第２のメモリ３３６ｂを使用して処理可能であるか否かが検討される。そして、第２のメモリ３３６ｂを使用して実行可能である場合には、第２種の処理は実行される。

すなわち、各プリンタからのリクエストのうち、優先チケットを伴う第２種のリクエストは、優先チケットを伴わない第１種のリクエストよりも優先的に処理される。

優先処理制御部３３４は、リクエストに対応する処理を処理部３３６においておこなわれなかった旨のレスポンスがプリンタに送信される場合に、そのレスポンスに対する優先チケットを発行する。

図２は、管理情報を伴うリクエストを管理サーバＳＶに送信する際のプリンタＰＲＴ１１の各部のやりとりを示すチャートである。図２のチャートでは、一例として、プリンタ制御部１２０が印刷データをプリントエンジン１３０に供給する動作Ｒｑ１以降の動作が示されている。

ＳＮＭＰエージェント１１６（図１参照）は、所定のタイミングでプリンタ制御部１２０に対して情報要求を行い、プリンタ制御部１２０から管理情報を伴う処理結果の応答を受け取って、管理データファイル１４０を更新する。たとえば、ＳＮＭＰエージェント１１６は、情報要求Ｒｑ２に対する処理結果の応答Ｒｓ２によって、「印刷完了」の情報を得て、管理データファイル１４０の第３の情報に関するファイルを更新する。

リクエスト送信部１１８（図１参照）は、所定のタイミングで、ＳＮＭＰエージェント１１６に対して新たに収集すべき管理情報があるか否かを問い合わせる。具体的には、リクエスト送信部１１８は、上記管理データファイル１４０としての第１〜第４の情報のファイルが生成されているかをＳＮＭＰエージェント１１６に対して問い合わせ（図２のＲｑ３）、ＳＮＭＰエージェント１１６から管理情報を伴う処理結果の応答を受け取る（図２のＲｓ３）。ＳＮＭＰエージェント１１６が新たな情報を収集していた場合には、各情報のファイルが存在する。

リクエスト送信部１１８は、ＳＮＭＰエージェント１１６から新たな管理情報を得た場合には、それを管理サーバＳＶに対するリクエストとして、インターネットを介して管理サーバＳＶに送信する（図２のＲｑ４）。

プリンタＰＲＴ１１の通信制御部１１２から送信された情報が、管理サーバＳＶに受け取られ処理された場合には、管理サーバＳＶから「正常処理」を表す処理結果が返信される。一方、プリンタＰＲＴ１１の通信制御部１１２から送信された情報が、管理サーバＳＶで処理されなかった場合には、管理サーバＳＶから「処理失敗」を表す処理結果が返信される。

たとえば、どの会社のどのプリンタも、朝８時から９時の間に電源を投入される可能性が高い。このため、朝８時から９時の間は、ネットワークに接続された多数のプリンタから、プリンタの機器構成に関する第１の情報を伴うリクエストが、管理サーバＳＶに送信される。その結果、処理の負荷が管理サーバＳＶの処理能力を超えてしまう場合がある。そのような場合には、管理サーバＳＶから「処理失敗」の内容を表す処理結果が返信される。なお、図２におけるレスポンスＲｓ４ａは、「正常処理」の内容を表すレスポンスであるものとする。

図３は、管理情報を伴うリクエストを受け取った場合の管理サーバＳＶの動作を示すフローチャートである。図４は、管理情報を伴うリクエストを受け取った場合の管理サーバＳＶの各部のやりとりを示すチャートである。

図３のステップＳ１０では、リクエスト受付部３３２は、プリンタＰＲＴ１１から送信された管理情報を伴うリクエストを、通信制御部３１０（図１参照）を介して受信する。図４において、プリンタＰＲＴ１１から送信された管理情報を伴うリクエストを、Ｒｑ４で示す。

具体的には、リクエスト受付部３３２は、リクエスト送信部１１８が送信するＨＴＴＰのポスト（ＰＯＳＴ）メッセージを受信し、受信したポストメッセージに含まれるデータから管理情報を抽出する。また、リクエスト受付部３３２は、ポストメッセージに含まれるデータに優先チケットが含まれている場合には、データから優先チケットの情報を抽出する。

図３のステップＳ２０では、リクエスト受付部３３２は、処理部３３６に対して第１の処理能力の余力を問い合わせる（図４のＲｑ１１）。本実施例では、「第１の処理能力の余力」は、上記の第１のメモリ３３６ａの容量のうち、使用されていないメモリの容量で評価されるものとする。

リクエスト受付部３３２は、問い合わせＲｑ１１に対する応答として、第１のメモリ３３６ａ容量のうち使用されていないメモリの容量の情報を伴う応答を、処理部３３６から受け取る（図４のＲｓ１１ａ）。

図３のステップＳ３０では、リクエスト受付部３３２は、プリンタＰＲＴ１１から受信したリクエストの処理に要するメモリの量を計算する。そして、リクエスト受付部３３２は、リクエストの処理に要するメモリの量と、処理部３３６から受け取った空き容量とを比較する。空きメモリ容量がリクエストの処理に要するメモリ量以上である場合には、処理はステップＳ４０に進む。空きメモリ容量がリクエストの処理に要するメモリ量よりも小さい場合には、処理はステップＳ７０に進む。

ステップＳ４０では、リクエスト受付部３３２は、管理情報とともに処理のリクエストを処理部３３６に転送する（図４のＲｑ１２）。処理部３３６は、第１のメモリ３３６ａを使用して、リクエストに応じて管理情報データベース３２０の操作を行う。そして、リクエスト受付部３３２は、「正常処理」の内容を表す処理結果をリクエスト受付部３３２に応答する（図４のＲｓ１２）。

図３のステップＳ５０では、リクエスト受付部３３２は、「正常処理」の内容を表す処理結果のレスポンスＲｓ４ａを、通信制御部３１０を介してプリンタＰＲＴ１１に送る（図４および図２参照）。

以上が、処理部３３６の第１の処理能力でリクエストを処理できる場合（図３のステップＳ３０においてＹｅｓ）の処理の流れである。

一方、図３のステップＳ３０において、第１のメモリ３３６ａの空き容量がリクエストの処理に要するメモリ量よりも小さい場合には、処理はステップＳ７０に進む。

図５は、図３のステップＳ３０において、第１のメモリ３３６ａの空き容量がリクエストの処理に要するメモリ量よりも小さい場合の管理サーバＳＶの各部のやりとりを示すチャートである。図５のチャートは、リクエスト受付部３３２から処理部３３６への第１の処理能力の問い合わせＲｑ１１までは、図４のチャートと同じである。図５の例では、応答Ｒｓ１１ｂによって取得された第１のメモリ３３６ａの空き容量は、プリンタからのリクエストＲｑ４の処理に要するメモリ量よりも小さいかったものとする。

図３のステップＳ７０では、リクエスト受付部３３２（図１参照）は、プリンタＰＲＴ１１から受信したリクエストが優先チケットを含むか否かを判定する。リクエストが優先チケットを含まない場合には、処理は、ステップＳ８０に進む。リクエストが優先チケットを含む場合には、優先チケットの確認が行われた後、処理は、ステップＳ１００に進む。

プリンタからのリクエスト（図５のＲｑ４）が優先チケットを含まない場合には、リクエスト受付部３３２は、図３のステップＳ８０で、優先処理制御部３２４に優先チケットの発行の依頼を送信する（図５のＲｑ１３）。優先処理制御部３２４は、プリンタから送られてきたリクエスト（図５のＲｑ４）に対する優先チケットを発行し、その優先チケットを伴う処理結果の応答Ｒｓ１３をリクエスト受付部３３２に送る。

「優先チケット」とは、前述のように、過去に処理が行われなかったために優先的に処理すべきリクエストを、そうではないリクエストと識別するためのデータである。優先チケットは、禁止期間の情報と、有効期限の情報を含む。

「禁止期間」とは、「リクエストが処理されなかった旨の応答をプリンタが受け取った後、再度、同じ内容のリクエストをプリンタが送信することが禁じられる期間」である。優先チケットにこのような情報を付加することで、プリンタによって頻繁に再リクエストが行われ、そのような一部のプリンタのリクエストによって管理サーバＳＶの負荷が増大してしまう事態を防止することができる。

「有効期限」とは、その優先チケットが有効である期間である。有効期限を過ぎると、優先チケットを含むリクエストも、優先チケットを含まない第１種のリクエストとして扱われる。すなわち、優先チケットを含むリクエストの処理であっても、そのリクエストの優先チケットの有効期限が過ぎている場合には、第２のメモリ３３６ｂを使用して実行されない。

図３のステップＳ９０では、リクエスト受付部３３２は、リクエストが処理されなかった旨の処理結果、すなわちリクエスト拒否のレスポンスＲｓ４ｂを、プリンタＰＲＴ１１に送る。リクエスト拒否のレスポンスＲｓ４ｂは、優先処理制御部３２４によって発行された優先チケットを含む。

図６は、リクエストが拒否された場合のプリンタＰＲＴ１１の各部の情報のやりとりを示すチャートである。図６のチャートは、リクエスト送信部１１８から管理サーバＳＶへのリクエストＲｑ４までは、図２のチャートと同じである。図６の例では、レスポンスＲｓ４ｂの処理結果は、リクエストＲｑ４が処理されなかった旨の処理結果である（図５参照）。

優先チケットとともにリクエストが処理されなかった旨の処理結果のレスポンスＲｓ４ｂを受け取ると、プリンタＰＲＴ１１のリクエスト送信部１１８（図１参照）は、優先チケットに基づいて定められる禁止期間経過後、リクエストＲｑ５を管理サーバＳＶに送信する。リクエストＲｑ５は、リクエストＲｑ４の管理情報と同じ管理情報、およびレスポンスＲｓ４ｂで受け取った優先チケットを伴う。

図７は、管理情報と優先チケットを伴うリクエストＲｑ５を受け取った場合の管理サーバＳＶの各部のやりとりを示すチャートである。図３のステップＳ１０でリクエストＲｑ５を受け取った後、リクエスト受付部３３２は、処理部３３６に第１の処理能力の余力を問い合わせ（図７のＲｑ１１），処理結果を得る（同、Ｒｓ１１）。その結果、図３のステップＳ３０において、依然として、処理部３３６の第１の処理能力には余力がなかったものとする（ステップＳ３０においてＮｏ）。その場合は、処理は、ステップＳ７０に進む。

ステップＳ７０では、プリンタから受け取ったリクエスト（図７のＲｑ５）が優先チケットを含むか否かが判定される。リクエストが優先チケットを含む場合には、リクエストから抽出された優先チケットの情報が、優先処理制御部３３４に送信される（図７のＲｑ１４）。そして、優先処理制御部３３４において、優先チケットが真正なものであることが確認され、その結果がリクエスト受付部３３２に返される（図７のＲｓ１４）。優先チケットは真正なものであった場合には、処理はステップＳ１００に進む。優先チケットが真正なものでなかった場合には、処理は、リクエストが優先チケットを含まない場合と同様に、ステップＳ８０に進む。ここでは、優先チケットは真正なものであったとする。

ステップＳ１００では、リクエスト受付部３３２は、処理部３３６に対して第２の処理能力の余力を問い合わせる（図７のＲｑ１５）。本実施例では、「第２の処理能力の余力」は、第２のメモリ３３６ｂの容量のうち、使用されていないメモリの容量で評価されるものとする。

ステップＳ１００では、リクエスト受付部３３２は、第２種の処理にあてることができる空きメモリ容量の情報を処理部３３６から受け取る（図７のＲｓ１５）。そして、ステップＳ１１０で、プリンタＰＲＴ１１から受信したリクエストの処理に要するメモリ量を計算し、処理部３３６から受け取った空きメモリ容量と比較する。空きメモリ容量がリクエストの処理に要するメモリ量以上である場合には、処理はステップＳ４０に進む。

ステップＳ４０では、リクエスト受付部３３２は、管理情報とともにプリンタからの処理のリクエストを処理部３３６に転送する（図７のＲｑ１６）。処理部３３６は、第２のメモリ３３６ｂを使用して、リクエストに応じて管理情報データベース３２０の操作を行う。そして、「正常処理」の内容を表す処理結果をリクエスト受付部３３２に返す（図７のＲｓ１６）。

図３のステップＳ５０では、リクエスト受付部３３２は、「正常処理」の内容を表す処理結果のレスポンスＲｓ５ａを、通信制御部３１０を介してプリンタＰＲＴ１１に送る。

このような態様においては、第１のメモリ３３６ａの空き容量がプリンタからのリクエストの処理に十分ではない場合にも（図３のＳ２０においてＮｏ）、そのリクエストが第２種のリクエストである場合には（同、Ｓ７０においてＹｅｓ）、第２のメモリ３３６ｂを使用して処理を実行できる可能性がある（同、Ｓ４０、Ｓ５０）。その結果、いったん拒否されたリクエストを優先的に処理される。このため、リクエストの処理について、過度の遅れが生じる可能性を減らすことができる。

図８は、図３のステップＳ１１０において、第２のメモリ３３６ｂの空き容量がリクエストの処理に要するメモリ量よりも小さい場合の管理サーバＳＶの各部のやりとりを示すチャートである。図８のチャートは、処理部３３６からリクエスト受付部３３２への第２の処理能力の応答Ｒｓ１５までは、図７のチャートと同じである。図８の例では、応答Ｒｓ１５によって取得された第２のメモリ３３６ｂの空き容量は、プリンタからのリクエストＲｑ５の処理に要するメモリ量よりも小さいかったものとする。

図３のステップＳ１１０において、第２のメモリ３３６ｂの空き容量がリクエストの処理に要するメモリ量よりも小さい場合には、処理はステップＳ８０に進む。リクエスト受付部３３２は、ステップＳ８０で、優先処理制御部３２４に優先チケットの発行の依頼を送信する（図８のＲｑ１７）。優先処理制御部３２４は、プリンタから送られてきたリクエスト（図８のＲｑ５）に対する優先チケットを発行し、その優先チケットを伴う応答Ｒｓ１７をリクエスト受付部３３２に返す。

なお、すでに優先チケットを伴っているリクエストに対して、再度、優先チケットを発行する場合には、優先処理制御部３２４は、上述の禁止期間をそれまでの禁止期間よりも短く設定する。このような態様とすることにより、複数回、拒否されたリクエストについては、拒否された回数が多いほど、より早期に処理される可能性が高くなるようにすることができる。

図３のステップＳ９０では、リクエスト受付部３３２は、リクエストが処理されなかった旨の処理結果、すなわちリクエスト拒否のレスポンスＲｓ５ｂを、プリンタＰＲＴ１１に送る。リクエスト拒否のレスポンスＲｓ５ｂは、優先処理制御部３２４によって発行された優先チケットのデータを含む。

以上で説明したネットワークシステムにおいては、一度、拒否されたリクエストは、その後、優先的に処理される。また、複数回、拒否されたリクエストは、その後、拒否された回数が増えるのに応じて、さらに優先的に処理される。その結果、リクエストの処理の待ち時間が過度に増大する事態を防止することができる。

Ｂ．第２実施例：
第１実施例においては、第１種のリクエストに対する処理と、第２種のリクエストに対する処理とが、それぞれ固定されたメモリの領域内で実行される（図１の第１のメモリ３３６ａと第２のメモリ３３６ｂ参照）。第２実施例では、第１種のリクエストに対する処理と、第２種のリクエストに対する処理とは、それぞれ固定されたメモリの領域内で実行されるわけではない。そして、第２実施例においては、優先チケットを有するリクエストに対する処理（図３のステップＳ７０においてＹｅｓ）が、第１実施例とは異なる。第２実施例の他の点は、第１実施例と同じである。

図９は、管理情報を伴うリクエストを受け取った場合の、第２実施例の管理サーバＳＶの動作を示すフローチャートである。図９のフローチャートは、ステップＳ１００，Ｓ１１０に代えてステップＳ１２０を有する。図９のフローチャートの他の点は、図３のフローチャートと同じである。

ステップＳ７０において、プリンタからのリクエストが真正な優先チケットを有することが確認された場合には、処理はステップＳ１２０に進む。ステップＳ１２０では、実行中の処理のうち、第１種のリクエストの処理を１個以上、終了する。そして、処理部３３６が管理情報データベース３２０の操作のために使用できるメモリ内に空き領域を確保する。なお、前述のように、第２実施例においては、第１種のリクエストの処理と第２種のリクエストの処理とは、区切られていない一つのメモリの領域を使用して実行される。

処理部３３６は、たとえば、ステップＳ１２０において、実行中の第１種のリクエストの処理のうち、最もメモリを消費している処理を終了する。そして、プリンタから受け取ったリクエストに応じた第２の処理が実行できるだけの空き領域ができるか否かを確認する。依然としてメモリが不足である場合には、第２の処理が実行できるだけの空き領域ができるまで、消費するメモリの多い処理から順に一つずつ、第１の処理を終了する。そして、プリンタから受け取ったリクエストに応じた第２の処理が実行できるだけの空き領域が確保されたら、処理は、ステップＳ４０に進む。

図９のステップＳ４０では、リクエスト受付部３３２は、管理情報とともに処理のリクエストを処理部３３６に転送する（図７のＲｑ１６参照）。処理部３３６は、第２のメモリ３３６ｂを使用して、リクエストに応じて管理情報データベース３２０の操作を行う。そして、「正常処理」の内容を表す処理結果をリクエスト受付部３３２に返す（図７のＲｓ１６）。

図３のステップＳ５０では、リクエスト受付部３３２は、「正常処理」の内容を表す処理結果を、通信制御部３１０を介してプリンタＰＲＴ１１に返信する（図７のＲｓ５ａ参照）。

このような態様とすれば、優先チケットを有する第２種のリクエストについて、リクエストが処理されなかった旨の処理結果が送信され、一方で、優先チケットを有さない第１種のリクエストの処理が実行されるという事態が防止される。その結果、リクエストが拒否され、処理されない時間が過度に長くなる事態を、第１実施例に比べてより効果的に防止できる。

また、優先チケットを有する第２種のリクエストが少ないときには、処理部３３６が管理情報データベース３２０の操作のために使用できるメモリをすべて使って、プリンタから受け取ったすべての第２種のリクエストの処理と、プリンタから受け取った一部の第１種のリクエストの処理と、を実行することができる。このため、メモリを有効に活用することができる。その結果、全体として、プリンタからリクエストが送信されてから、リクエストの処理が完了するまでの時間を短くすることができる。

Ｃ．変形例：
なお、この発明は上記実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。

Ｃ１．変形例１：
第１実施例では、管理情報データベース３２０の操作のために使用できるメモリのうち７０％が、第１種の処理のために使用される。そして、残りの３０％が、第２種の処理のために使用される。しかし、これらの割合は、８０％と２０％など、任意の割合とすることができる。また、第１種と第２種の処理以外の処理のためにメモリを確保しておくこともできる。

Ｃ２．変形例２：
上記実施例においては、優先チケットは、禁止期間および有効期限の情報を保持している。しかし、優先チケットは、禁止期間および有効期限の情報以外にも、たとえば、優先度を表す情報を保持することができる。そして、優先値チケットを有する複数の第２種のリクエストの処理においては、より高い優先度を有するリクエストが優先的に処理されることが好ましい。

たとえば、上記実施例において、（４）発生したエラーおよび解消したエラーに関する第４の情報に関するリクエストの優先度を、他の情報に関するリクエストの優先度に比べて、高く設定することができる。そのような態様とすれば、リクエストを発する機器においてエラーが発生し、緊急の対応を要する場合に、その旨のリクエストを優先的に処理することで、事態を迅速に把握することができる。

また、たとえば、（１）プリンタＰＲＴ１１の機器構成に関する第１の情報に関するリクエストよりも、（２）プリンタＰＲＴ１１において使用された紙の種類および枚数に関する第２の情報に関するリクエストの優先度を、高く設定することが好ましい。そのような態様とすれば、プリンタＰＲＴ１１の機器構成に関するリクエストが集中している時間帯においても、用紙切れが生じる事態を防止することができる。

さらに、優先度に応じた優先的な処理については、以下のような対応を採用することができる。たとえば、第２実施例の図９のステップＳ１２０の処理において、第１種のリクエストの処理がすべて終了されても十分なメモリの空き領域が確保でできない場合には、新たにプリンタから受け取ったリクエストの優先度よりも優先度が低いリクエストの処理のうち、優先度の低いものから順に処理を終了して、新たに受け取ったリクエストの処理を実行するようにすることもできる。

また、上記第１実施例においては、優先チケットを有するリクエストが再度、拒否される場合には、禁止期間がそれまでよりも短く設定される（図３のステップＳ８０参照）。しかし、そのような処理に代えて、優先チケットを有するリクエストが再度、拒否される場合には、それまでよりも高い優先度を設定する態様とすることもできる。そのような態様において、優先度は、たとえば、それまでにそのリクエストが拒否された回数とすることができる。

なお、優先度が、それまでにそのリクエストが拒否された回数に基づいて決定される態様においては、優先チケットは、「禁止期間」を設けることがより好ましい。そのような態様とすれば、たとえば、１秒おきにリクエストを行うなど、短期間に頻繁に再リクエストを行って、優先度を増加させる不正行為を防止することができる。

Ｃ３．変形例３：
上記実施例においては、優先チケットは、拒否されたすべてのリクエストに対して発行される。しかし、優先チケットは、拒否されたすべてのリクエストのうち、一部のリクエストに対してのみ発行することもできる。

たとえば、（１）プリンタＰＲＴ１１の機器構成に関する第１の情報、（２）プリンタＰＲＴ１１において使用された紙の種類および枚数に関する第２の情報、（３）完了した印刷ジョブに関する第３の情報、そして、（４）発生したエラーおよび解消したエラーに関する第４の情報のうち、第４の情報を伴うリクエストに対してのみ、優先チケットを発行することもできる。また、第２と第４の情報を伴うリクエストに対してのみ、優先チケットを発行することもできる。

Ｃ４．変形例４：
第１実施例においては、第１種の処理のための第１の処理能力と、第２種の処理のための第２の処理能力とは、それぞれの処理のための専用メモリの空き容量で評価される。しかし、第１種の処理のための第１の処理能力と、第２種の処理のための第２の処理能力とは、他の要素を考慮して定めることもできる。

たとえば、管理サーバＳＶが、複数のＣＰＵを備える場合には、第１種の処理を行うことができるＣＰＵの数およびそれぞれの処理能力と、第２種の処理を行うことができるＣＰＵの数およびそれぞれの処理能力と、を考慮して、それぞれ第１の処理能力と第２の処理能力と、を定めることができる。

すなわち、優先チケットを有するリクエストの処理を実行する処理能力と、優先チケットを有さないリクエストの処理を実行する処理能力と、は、それぞれの処理を実行するための任意の資源を考慮して定めることができる。

Ｃ５．変形例５：
上記実施例では説明を省略したが、優先チケットを伴うリクエストの処理が処理部３３６において実行された場合には、優先処理制御部３３４は、リクエスト受付部３３２からの要求に応じて、そのリクエストに対して発行されていた優先チケットを「無効」または「使用済み」とする処理を、管理情報データベースに対して行うことができる。そのような態様とすれば、プリンタ側において、すでに使用した優先チケットを他のリクエストに組み込んで、管理サーバに早期の処理を実現させるという不正行為を、防止することができる。

Ｃ６．変形例６：
上記実施例においては、プリンタＰＲＴ１１〜ＰＲＴ２２と、管理サーバＳＶとの間の通信は、ＨＴＴＰＳプロトコルによる暗号化通信でおこなわれる。しかし、管理対象である機器（プリンタＰＲＴ１１〜ＰＲＴ２２）と管理サーバとの間の通信は、暗号化を伴わないＨＴＴＰで行うこともできる。また、管理対象である機器と管理サーバとの間の通信は、他のプロトコルで行うこともできる。

Ｃ７．変形例７：
第１実施例においては、第２種のリクエストの処理を実行する余裕がない場合には（ステップＳ１１０においてＮｏ）、再度、優先チケットを発行して（同、ステップＳ８０参照）、処理が行われなかった旨の処理結果を返信する（同、ステップＳ９０参照）。しかし、第２種のリクエストの処理を実行する余裕がない場合には、第２実施例のように第１種のリクエストの処理を１個以上中止して、第１種の処理のための資源（たとえばメモリの領域）を使用して、最後に受け取った第２種のリクエストの処理を実行することとしてもよい。

すなわち、リクエストに応じた処理を行う装置（サーバ）は、第２種のリクエストの処理を、第１種のリクエストの処理に比べて優先的に行う。ここで、「第２種のリクエストの処理を、第１種のリクエストの処理に比べて優先的に行う」とは、リクエストが「過去に処理が行われなかった旨の返信がなされたことを表す情報」を有していなければ（すなわち、第１種のリクエスト）、処理されないけれども、同じリクエストが「過去に処理が行われなかった旨の返信がなされたことを表す情報」を有していれば（すなわち、第２種のリクエスト）、処理され得るという状況が生じる任意の処理方法をいう。

Ｃ８．変形例８：
上記実施例においては、優先チケットは、禁止期間および有効期限の情報を保持している。しかし、優先チケットは、過去においてサーバに送信され処理されなかったリクエストを識別するための情報のみを有する態様とすることもできる。そのような態様においては、たとえば、管理情報データベース３２０内に、発行した優先チケットと、その優先チケットに対応づけられた有効期限や優先度のデータと、を保持することが好ましい。そして、優先処理制御部３３４は、リクエストから抽出された優先データをリクエスト受付部３３２から受け取ると、管理情報データベース３２０を参照して、その優先データに対応する有効期限や優先度の情報を取得する。そして、それらの情報をリクエスト受付部３３２に送信する。リクエスト受付部３３２は、それらの情報をもとに、図３や図９の処理を行うことができる。

このような態様とすれば、プリンタなどの端末装置側において有効期限や優先度の情報を改変して、管理サーバに早期に処理を行わせるという不正行為を防止できる。

Ｃ９．変形例９：
上記実施例では、管理サーバＳＶは、データベース管理部３３０を一つ備える（図１参照）。しかし、たとえば、管理サーバを複数のＣＰＵを備える態様とすることにより、管理サーバにデータベース管理部３３０を複数設けることもできる。

そのような態様においては、管理サーバＳＶは、各データベース管理部にリクエストを割り当てるリクエスト分配部（ロードバランサ）を備えることが好ましい。リクエスト分配部は、各データベース管理部にすでに割り当てられているジョブの負荷と、新たに受け取ったリクエストのジョブの負荷と、に基づいて、新たに受け取ったリクエストのジョブをいずれかのデータベース管理部に割り当てる。その際、各データベース管理部に割り当てられたリクエストの負荷の合計値または負荷の推定値の合計がもっとも均等に近づくように、新たなリクエストがデータベース管理部に割り当てられることが好ましい。

Ｃ１０．変形例１０：
上記実施例では、管理サーバが管理する機器は、印刷機能を有するプリンタ、または印刷機能に加えてコピー機能やＦＡＸ機能を有する、いわゆる複合機である。しかし、管理サーバが管理する機器は、たとえば、銀行のＡＴＭ（Automated Teller Machine）や、融資対象者に貸与するローンカードを発行するための端末とすることもできる。すなわち、管理サーバが管理する機器は、管理サーバとネットワークで接続されており、ネットワークを介して、管理サーバに対して不特定のタイミングを含む所定のタイミングで処理要求を行う機器とすることができる。

Ｃ１１．変形例１１：
上記実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。例えば、ネットワークボード１１０の機能の一部を専用のハードウェア回路で実行するようにすることもできる。また、プリンタのネットワークボード１１０と、プリンタ制御部１２０と、プリントエンジン１３０と、をソフトウェアで実現することもできる。

このような機能を実現するコンピュータプログラムは、フロッピディスクやＣＤ−ＲＯＭ等の、コンピュータ読み取り可能な記録媒体に記録された形態で提供される。ホストコンピュータは、その記録媒体からコンピュータプログラムを読み取って内部記憶装置または外部記憶装置に転送する。あるいは、通信経路を介してプログラム供給装置からホストコンピュータにコンピュータプログラムを供給するようにしてもよい。コンピュータプログラムの機能を実現する時には、内部記憶装置に格納されたコンピュータプログラムがホストコンピュータのマイクロプロセッサによって実行される。また、記録媒体に記録されたコンピュータプログラムをホストコンピュータが直接実行するようにしてもよい。

この明細書において、ホストコンピュータとは、ハードウェア装置とオペレーションシステムとを含む概念であり、オペレーションシステムの制御の下で動作するハードウェア装置を意味している。コンピュータプログラムは、このようなホストコンピュータに、上述の各部の機能を実現させる。なお、上述の機能の一部は、アプリケーションプログラムでなく、オペレーションシステムによって実現されていても良い。

なお、この発明において、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスクやＣＤ−ＲＯＭのような携帯型の記録媒体に限らず、各種のＲＡＭやＲＯＭ等のコンピュータ内の内部記憶装置や、ハードディスク等のコンピュータに固定されている外部記憶装置も含んでいる。

本発明の実施例であるプリンタ管理システム１０００の構成を示す説明図。 管理情報を伴うリクエストを管理サーバＳＶに送信する際のプリンタＰＲＴ１１の各部のやりとりを示すチャート。 管理情報を伴うリクエストを受け取った場合の管理サーバＳＶの動作を示すフローチャート。 管理情報を伴うリクエストを受け取った場合の管理サーバＳＶの各部のやりとりを示すチャート。 第１のメモリ３３６ａの空き容量がリクエストの処理に要するメモリ量よりも小さい場合の管理サーバＳＶの各部のやりとりを示すチャート。 リクエストが拒否された場合のプリンタＰＲＴ１１の各部の情報のやりとりを示すチャート。 管理情報とともに優先チケットを伴うリクエストＲｑ５を受け取った場合の管理サーバＳＶの各部のやりとりを示すチャート。 第２のメモリ３３６ｂの空き容量がリクエストの処理に要するメモリ量よりも小さい場合の管理サーバＳＶの各部のやりとりを示すチャート。 管理情報を伴うリクエストを受け取った場合の、第２実施例の管理サーバＳＶの動作を示すフローチャート。

符号の説明

１０００…プリンタ管理システム
１１００…第１のネットワークシステム
１２００…第２のネットワークシステム
１３００…第３のネットワークシステム
１１０…ネットワークボード
１１２…通信制御部
１１４…印刷ジョブ処理部
１１６…ＳＮＭＰエージェント
１１８…リクエスト送信部
１２０…プリンタ制御部
１３０…プリントエンジン
１４０…管理データファイル
３１０…通信制御部
３２０…管理情報データベース
３２４…優先処理制御部
３３０…データベース管理部
３３０…優先処理制御部
３３２…リクエスト受付部
３３４…優先処理制御部
３３６…処理部
３３６ａ…第１のメモリ
３３６ｂ…第２のメモリ
ＣＬ１１，ＣＬ１２，ＣＬ２１…クライアント
ＩＮＥＴ…インターネット
ＬＡＮ１，ＬＡＮ２，ＬＡＮ３…ローカルエリアネットワーク
ＰＲＴ１１〜ＰＲＴ１３，ＰＲＴ２１，ＰＲＴ２２…プリンタ
Ｒｑ１，Ｒｑ２…処理の要求
Ｒｑ４，Ｒｑ５…プリンタから管理サーバへの処理の要求
Ｒｓ２，Ｒｓ１１ａ，Ｒｓ１１ｂ，Ｒｓ１３，Ｒｓ１５ｂ…処理結果の応答
Ｒｓ４ａ，Ｒｓ４ｂ，Ｒｓ５ａ，Ｒｓ５ｂ…管理サーバからプリンタへの処理結果の応答
ＳＶ…管理サーバ

Claims (9)

1. リクエストに応じて所定のデータ処理を行うデータ処理装置であって、
   リクエストを受け取る受付部と、
   前記受け取ったリクエストに応じた処理を行う処理部と、
   前記受け取ったリクエストの送信元に返信を行う返信部と、を備え、
   前記返信部は、前記処理部における前記処理が行われなかった旨の前記返信を行う場合には、前記処理が行われなかったリクエストを識別するための識別データを付加して送信元に返信し、
   前記処理部は、前記受け取ったリクエストであって前記識別データを含まない第１種のリクエストの前記処理よりも、前記受け取ったリクエストであって前記識別データを含む第２種のリクエストの前記処理を優先的に行う、データ処理装置。
2. 請求項１記載のデータ処理装置であって、
   前記処理部は、
   前記第１種および第２種のリクエストの前記処理を実行するための第１の処理部と、
   前記第２種のリクエストの前記処理を実行するための第２の処理部であって、前記第１種のリクエストの前記処理には使用されない第２の処理部と、を備え、
   前記第２の処理部を使用して前記優先的な処理を行う、データ処理装置。
3. 請求項１記載のデータ処理装置であって、
   前記処理部は、前記受付部が前記第２種のリクエストを受け取った場合であって、前記処理部が１以上の前記第１種のリクエストの前記処理を実行中である場合には、少なくとも一つの前記第１種のリクエストの前記処理を中止して、前記第２種のリクエストの前記処理を実行することによって、前記優先的な処理を行う、データ処理装置。
4. 請求項１記載のデータ処理装置であって、
   前記識別データは、有効期限に関する情報を含み、
   前記処理部は、前記有効期限が過ぎた前記識別データを含むリクエストについては、前記第１種のリクエストとして扱う、データ処理装置。
5. 請求項１記載のデータ処理装置であって、
   前記識別データは、優先度に関する情報を含み、
   前記処理部は、前記第２種のリクエストの処理のうち、第１の優先度を表す情報を含むリクエストの前記処理よりも、前記第１の優先度より高い第２の優先度を表す情報を含むリクエストの前記処理を優先的に行う、データ処理装置。
6. 請求項１記載のデータ処理装置であって、
   前記識別データは、前記受け取ったリクエストについて前記処理部における前記処理が行われなかった旨の前記返信が行われた回数に関する情報を含み、
   前記処理部は、前記第２種のリクエストの処理のうち、第１の回数を表す情報を含むリクエストの前記処理よりも、前記第１の回数より高い第２の回数を表す情報を含むリクエストの前記処理を優先的に行う、データ処理装置。
7. 請求項１記載のデータ処理装置であって、さらに、
   前記処理の優先度を表す優先度データであって、前記各識別データと対応づけられた優先度データを格納する優先度データ格納部を備え、
   前記処理部は、前記第２種のリクエストの処理のうち、第１の優先度を表す優先度データに対応づけられた前記識別データを含むリクエストの前記処理よりも、第１の優先度より高い第２の優先度を表す優先度データに対応づけられた前記識別データを含むリクエストの前記処理を優先的に行う、データ処理装置。
8. リクエストに応じて所定のデータ処理を行う方法であって、
   （ａ）リクエストを受け取る工程と、
   （ｂ）所定の条件下で、前記受け取ったリクエストに応じた処理を行う工程と、
   （ｃ）前記受け取ったリクエストの送信元に返信を行う工程と、を備え、
   前記工程（ｃ）は、
   前記処理が行われなかった旨の前記返信を行う場合に、前記処理が行われなかったリクエストを識別するための識別データを付加して送信元に返信する工程を含み、
   前記工程（ｂ）は、
   前記受け取ったリクエストであって前記識別データを含まない第１種のリクエストの前記処理よりも、前記受け取ったリクエストであって前記識別データを含む第２種のリクエストの前記処理を優先的に行う工程を含む、方法。
9. ネットワークに接続されたコンピュータにおいて、リクエストに応じて所定のデータ処理を行うためのコンピュータプログラムであって、
   リクエストを受け取る第１の機能と、
   所定の条件下で、前記受け取ったリクエストに応じた処理を行う第２の機能と、
   前記受け取ったリクエストの送信元に返信を行う第３の機能と、を前記コンピュータに実現させるためのコンピュータプログラムを含み、
   前記第３の機能は、
   前記処理が行われなかった旨の前記返信を行う場合に、前記処理が行われなかったリクエストを識別するための識別データを付加して送信元に返信する機能を含み、
   前記第２の機能は、
   前記受け取ったリクエストであって前記識別データを含まない第１種のリクエストの前記処理よりも、前記受け取ったリクエストであって前記識別データを含む第２種のリクエストの前記処理を優先的に行う機能を含む、コンピュータプログラム。

Images