(57)【要約】【課題】異種ジョブのリクエストを一元的かつ効率良く受け付けおよび管理すること。【解決手段】リクエスト管理部１１３ａは、いわゆる「フォルダ−ファイル」モデルのアナロジーとしてオブジェクトモデリングをおこない、リクエストフォルダクラス３１０、リクエストクラス３２０、リクエスト仕様クラス３３０を有する構成とすることでリクエストを管理し、さらに、成果物クラス３４０および成果物仕様クラス３５０を有する構成とすることでリクエストの成果物を管理する。【選択図】        図７
2006059199.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ操作によるジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答するジョブの実行を指示するとともに、各ジョブ処理依頼をリクエストとして管理するリクエスト管理装置であって、
前記リクエストに応じたジョブの実行を指示するリクエスト手段と、
前記リクエスト手段の詳細な仕様を保持するリクエスト仕様保持手段と、
前記リクエスト手段並びに前記リクエスト仕様保持手段をフォルダ管理するリクエスト保管手段と
を備えたことを特徴とするリクエスト管理装置。
【請求項２】
前記リクエスト手段は、前記リクエスト仕様保持手段と一対一に対応し、該リクエスト仕様保持手段へのリンク情報を保持することを特徴とする請求項１に記載のリクエスト管理装置。
【請求項３】
前記リクエスト手段は、前記リクエスト保管手段を木構造の親として該リクエスト保管手段により管理されることを特徴とする請求項１または２に記載のリクエスト管理装置。
【請求項４】
前記リクエスト手段は、当該リクエスト手段に対応するジョブの実行状態を取得して保持することを特徴とする請求項１、２または３に記載のリクエスト管理装置。
【請求項５】
前記リクエスト保管手段は、ユーザ操作によりジョブ処理依頼を受け付けた際に、当該ユーザ操作の種別に応じたリクエスト手段を生成することを特徴とする請求項１〜４のいずれか一つに記載のリクエスト管理装置。
【請求項６】
前記リクエスト保管手段は、受付可能なジョブ処理依頼の限界数と生成したリクエスト手段の数を有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理をおこなうことを特徴とする請求項１〜５のいずれか一つに記載のリクエスト管理装置。
【請求項７】
前記リクエスト仕様手段は、前記ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に前記要望仕様の代替仕様として用いられる許容仕様とを有することを特徴とする請求項１〜６のいずれか一つに記載のリクエスト管理装置。
【請求項８】
前記要望仕様は、入力仕様および出力仕様を有することを特徴とする請求項７に記載のリクエスト管理装置。
【請求項９】
前記リクエスト手段により実行指示されるジョブの出力成果物に応じた進捗状況を管理する成果物手段と、前記リクエスト仕様保持手段が保持する仕様のうち前記出力成果物の仕様を保持する成果物仕様保持手段とをさらに備えたことを特徴とする請求項１〜８のいずれか一つに記載のリクエスト管理装置。
【請求項１０】
前記成果物手段は、前記リクエスト手段により実行指示されるジョブの一または複数の出力成果物とそれぞれ一対一に対応することを特徴とする請求項９に記載のリクエスト管理装置。
【請求項１１】
前記成果物手段は、前記ジョブ処理依頼に伴って入力される入力物の進捗状況と、該ジョブ処理依頼に対応するジョブによって出力される成果物の進捗状況とを前記成果物進捗状況の一部として管理することを特徴とする請求項９または１０に記載のリクエスト管理装置。
【請求項１２】
表示部、印刷部および撮像部などのハードウェア資源と、該ハードウェア資源を用いた画像形成に係るジョブ実行をおこなう共通処理部とを有し、ユーザ操作による画像形成に係るジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答するジョブを前記共通処理部で実行するとともに、各ジョブ処理依頼をリクエストとして管理する画像形成装置であって、
前記リクエストに応じたジョブの実行を前記共通処理部に対して指示するリクエスト手段と、
前記リクエスト手段の詳細な仕様を保持するリクエスト仕様保持手段と、
前記リクエスト手段並びに前記リクエスト仕様保持手段をフォルダ管理するリクエスト保管手段と
を備えたことを特徴とする画像形成装置。
【請求項１３】
前記リクエスト手段は、前記リクエスト保管手段を木構造の親として該リクエスト保管手段により管理されることを特徴とする請求項１２に記載の画像形成装置。
【請求項１４】
前記リクエスト保管手段は、受付可能なジョブ処理依頼の限界数と生成したリクエスト手段の数を有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理をおこなうことを特徴とする請求項１２または１３に記載の画像形成装置。
【請求項１５】
前記リクエスト仕様手段は、前記ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に前記要望仕様の代替仕様として用いられる許容仕様とを有することを特徴とする請求項１２、１３または１４に記載の画像形成装置。
【請求項１６】
前記リクエスト手段により実行指示されるジョブの出力成果物に応じた進捗状況を管理する成果物手段と、前記リクエスト仕様保持手段が保持する仕様のうち前記出力成果物の仕様を保持する成果物仕様保持手段とをさらに備えたことを特徴とする請求項１２〜１５のいずれか一つに記載の画像形成装置。
【請求項１７】
ユーザから受け付けたジョブ処理のリクエストに応じて、他のサブシステムにジョブ処理の指示をおこなうジョブ処理指示方法であって、
コンピュータは、
ユーザから受け付けたリクエストの詳細な仕様をあらわすユーザの要望データを自己の属性区画で保持するリクエスト仕様保持手段を、該リクエストごとに生成するリクエスト仕様保持手段生成ステップと、
前記リクエスト仕様保持手段のリンク情報およびリクエストの受け付けが可能な限界数を自己の属性区画で保持し、前記リクエスト仕様保持手段をフォルダ管理するリクエスト保管手段を生成するリクエスト保管手段生成ステップと
を実行し、
前記リクエスト保管手段は、
前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定をおこなう判定ステップと、
前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能なリクエスト手段を生成するリクエスト手段生成ステップと、
前記リクエスト手段生成ステップにより生成したリクエスト手段に対して、前記リクエスト仕様保持手段のリンク情報を渡すことでリクエストの投入をおこなうリクエスト投入ステップと
をコンピュータに実行させ、
前記リクエスト手段は、
前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記リクエスト仕様保持手段との関連付けをおこなうリクエスト仕様関連付けステップと、
前記関連付けステップにより関連付けしたリクエスト仕様保持手段に対して、該リクエスト仕様保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップと
をコンピュータに実行させ、
前記リクエスト仕様保持手段は、
前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記リクエスト手段に渡す参照ステップ
をコンピュータに実行させ、
前記リクエスト手段は、
前記リクエスト仕様保持手段から取得したユーザの要望データに従い、前記他のサブシステムに対してジョブ処理の開始を指示する指示ステップ
をコンピュータに実行させることを特徴とするジョブ処理指示方法。
【請求項１８】
前記リクエスト手段は、前記指示ステップの実行前に、
前記リクエスト仕様保持手段から取得したユーザの要望データに従い、出力成果物に応じた進捗状況を管理する成果物手段を生成する成果物手段生成ステップと、
前記成果物手段生成ステップにより生成した成果物手段に対して、前記リクエスト仕様保持手段のリンク情報を渡すリンク情報提供ステップと
をコンピュータに実行させ、
前記成果物手段は、前記参照ステップの実行後に、
前記リクエスト仕様保持手段から取得したユーザの要望データに従い、前記リクエスト仕様保持手段が保持するユーザの要望データのうち、前記成果物手段に応じたユーザの要望データを自己の属性区画で保持する成果物仕様保持手段を生成する成果物仕様保持手段生成ステップと、
前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記成果物仕様保持手段との関連付けをおこなう成果物仕様関連付けステップと
をコンピュータに実行させることを特徴とする請求項１７に記載のジョブ処理指示方法。
【請求項１９】
ユーザから受け付けたジョブ処理のリクエストに応じて、他のサブシステムにジョブ処理の指示をおこなうためのジョブ処理指示プログラムであって、
コンピュータは、
ユーザから受け付けたリクエストに基づいて生成され、前記リクエストの詳細な仕様をあらわすユーザの要望データを自己の属性区画で保持するリクエスト仕様保持手段と、
前記リクエスト仕様保持手段のリンク情報およびリクエストの受け付けが可能な限界数を自己の属性区画で保持し、前記リクエスト仕様保持手段をフォルダ管理するリクエスト保管手段と
を有した状態で、
前記リクエスト保管手段は、
前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定をおこなう判定ステップと、
前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能なリクエスト手段を生成するリクエスト手段生成ステップと、
前記リクエスト手段生成ステップにより生成したリクエスト手段に対して、前記リクエスト仕様保持手段のリンク情報を渡すことでリクエストの投入をおこなうリクエスト投入ステップと
をコンピュータに実行させ、
前記リクエスト手段は、
前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記リクエスト仕様保持手段との関連付けをおこなうリクエスト仕様関連付けステップと、
前記関連付けステップにより関連付けしたリクエスト仕様保持手段に対して、該リクエスト仕様保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップと
をコンピュータに実行させ、
前記リクエスト仕様保持手段は、
前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記リクエスト手段に渡す参照ステップ
をコンピュータに実行させ、
前記リクエスト手段は、
前記リクエスト仕様保持手段から取得したユーザの要望データに従い、前記他のサブシステムに対してジョブ処理の開始を指示する指示ステップ
をコンピュータに実行させることを特徴とするジョブ処理指示プログラム。
【請求項２０】
前記リクエスト手段は、前記指示ステップの実行前に、
前記リクエスト仕様保持手段から取得したユーザの要望データに従い、出力成果物に応じた進捗状況を管理する成果物手段を生成する成果物手段生成ステップと、
前記成果物手段生成ステップにより生成した成果物手段に対して、前記リクエスト仕様保持手段のリンク情報を渡すリンク情報提供ステップと
をコンピュータに実行させ、
前記成果物手段は、前記参照ステップの実行後に、
前記リクエスト仕様保持手段から取得したユーザの要望データに従い、前記リクエスト仕様保持手段が保持するユーザの要望データのうち、前記成果物手段に応じたユーザの要望データを自己の属性区画で保持する成果物仕様保持手段を生成する成果物仕様保持手段生成ステップと、
前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記成果物仕様保持手段との関連付けをおこなう成果物仕様関連付けステップと
をコンピュータに実行させることを特徴とする請求項１９に記載のジョブ処理指示プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ操作によるジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答するジョブの実行を指示するとともに、各ジョブ処理依頼をリクエストとして管理するリクエスト管理装置、画像形成装置、ジョブ処理指示方法およびジョブ処理指示プログラムに関するものである。
【背景技術】
【０００２】
従来、プリンタ、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した複合機が知られている。かかる複合機では、ＵＮＩＸ（登録商標）などの汎用ＯＳ上に、プリンタアプリ、コピーアプリおよびスキャナアプリと呼ばれる複数のアプリケーションを搭載し、これらのアプリケーションの実行処理を切替えながら複数の機能を実現していた。
【０００３】
ところが、上記プリンタアプリ、コピーアプリおよびスキャナアプリは、それぞれエンジン制御、メモリ制御およびシステム制御などを別個におこなっているので、重複処理という無駄が生ずる。
【０００４】
このため、特許文献１では、複合機に搭載される複数のアプリケーションがそれぞれ担っていたエンジン制御、メモリ制御およびシステム制御などの処理を共通処理部分（プラットホーム）として各アプリケーションから括り出すことにより、アプリケーションの開発効率の向上を図っている。
【０００５】
【特許文献１】特開２００２−０８４３８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、かかる特許文献１によれば、ジョブの生成以降の処理を共通化しているものの、ジョブ処理依頼（以下「リクエスト」と言う）の管理などをそれぞれのアプリケーションで別個におこなっているため、複合機上のアプリケーションのスリム化を図るうえで改善の余地がある。なお、「ジョブ」とは、成果物の作成が完了するまでの処理の実行単位をいい、複合機全体として入力の始まりから出力の終了までを示す。また、一連の原稿束の読み取り処理や、一連の印刷処理を指して「ジョブ」と呼ぶこともある。
【０００７】
たとえば、複合機に搭載されるコピーアプリは、コピーのリクエストを受け付けたならば、このリクエストに対応するジョブの実行を共通処理部分（プラットホーム）に指示するとともに、かかるリクエストの管理をおこなうことになるが、プリンタアプリの場合にも同様のジョブ実行指示とリクエスト管理をおこなっている。
【０００８】
このため、リクエストの一元管理をおこなうことが望まれるが、かかるリクエストは、一元的に管理可能なジョブが生成される前段階のものであるので、特許文献１の共通処理部分で対応するのは無理がある。このリクエストにジョブと同様の仕様制限を加えてしまうと、複合機が新規のリクエストに対応できなくなってしまうからである。
【０００９】
これらのことから、複合機に搭載されるアプリケーションへのリクエストをいかにして効率良く一元管理するかが大きな課題となっている。なお、かかる課題は複合機についてのみ生じるものではなく、たとえば異種のジョブを実行する複数のサーバ機能を搭載した多機能サーバ装置を形成するような場合にも同様に生ずる課題である。
【００１０】
本発明は、上述した従来技術による問題点を解消するためになされたものであり、異種ジョブのリクエストを一元的かつ効率良く受け付けることができ、管理することができるリクエスト管理装置、画像形成装置、ジョブ処理指示方法およびジョブ処理指示プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、ユーザ操作によるジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答するジョブの実行を指示するとともに、各ジョブ処理依頼をリクエストとして管理するリクエスト管理装置であって、前記リクエストに応じたジョブの実行を指示するリクエスト手段と、前記リクエスト手段の詳細な仕様を保持するリクエスト仕様保持手段と、前記リクエスト手段並びに前記リクエスト仕様保持手段をフォルダ管理するリクエスト保管手段とを備えたことを特徴とする。
【００１２】
この請求項１の発明によれば、リクエストに応じたジョブの実行を指示するリクエストクラスと、リクエスト手段の詳細な仕様を保持するリクエスト仕様クラスと、これらのクラスをフォルダ管理するリクエストフォルダクラスとを備えることとしたので、異種ジョブのリクエストを一元的かつ効率良く受け付けて管理することができる。
【００１３】
また、請求項２にかかる発明は、請求項１の発明において、前記リクエスト手段は、前記リクエスト仕様保持手段と一対一に対応し、該リクエスト仕様保持手段へのリンク情報を保持することを特徴とする。
【００１４】
この請求項２の発明によれば、リクエストクラスとリクエスト仕様クラスとが一対一に対応し、対応するリクエスト仕様クラスへのリンク情報をかかるリクエストクラスが保持することとしたので、リクエストとリクエストの詳細情報とを対応づけて管理することができる。
【００１５】
また、請求項３にかかる発明は、請求項１または２の発明において、前記リクエスト手段は、前記リクエスト保管手段を木構造の親として該リクエスト保管手段により管理されることを特徴とする。
【００１６】
この請求項３の発明によれば、リクエストフォルダクラスを木構造の親として、リクエストクラスがリクエストフォルダクラスにより管理されることとしたので、リクエストを一元的に効率良く管理することができる。
【００１７】
また、請求項４にかかる発明は、請求項１、２または３の発明において、前記リクエスト手段は、当該リクエスト手段に対応するジョブの実行状態を取得して保持することを特徴とする。
【００１８】
この請求項４の発明によれば、対応するジョブの実行状態の取得および保持をリクエストクラスがおこなうこととしたので、ジョブの実行状態を効率良く管理することができる。
【００１９】
また、請求項５にかかる発明は、請求項１〜４の発明において、前記リクエスト保管手段は、ユーザ操作によりジョブ処理依頼を受け付けた際に、当該ユーザ操作の種別に応じたリクエスト手段を生成することを特徴とする。
【００２０】
この請求項５の発明によれば、ユーザ操作によりジョブ処理依頼を受け付けた際に、かかるユーザ操作の種別に応じたリクエストクラスのオブジェクトの生成をリクエストフォルダクラスがおこなうこととしたので、異種ジョブのリクエストを効率良く管理することができる。
【００２１】
また、請求項６にかかる発明は、請求項１〜５の発明において、前記リクエスト保管手段は、受付可能なジョブ処理依頼の限界数と生成したリクエスト手段の数を有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理をおこなうことを特徴とする。
【００２２】
この請求項６の発明によれば、受付可能なジョブ処理依頼の限界数と生成したリクエストクラスのオブジェクトの数を有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理をリクエストフォルダクラスがおこなうこととしたので、装置全体の処理許容量を越えた場合には、効率良くリクエストを拒否することができる。
【００２３】
また、請求項７にかかる発明は、請求項１〜６の発明において、前記リクエスト仕様手段は、前記ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に前記要望仕様の代替仕様として用いられる許容仕様とを有することを特徴とする。
【００２４】
この請求項７の発明によれば、ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に要望仕様の代替仕様として用いられる許容仕様とをリクエスト仕様クラスが有することとしたので、ユーザの要望仕様を満足させることができない場合であっても、ただちにリクエストを取り消すことなく代替仕様に基づいたジョブの実行を指示することができる。
【００２５】
また、請求項８にかかる発明は、請求項７の発明において、前記要望仕様は、入力仕様および出力仕様を有することを特徴とする。
【００２６】
この請求項８の発明によれば、入力仕様および出力仕様を要望仕様が有することとしたので、ジョブ処理依頼の入力に伴う入力物の仕様と、ジョブ処理依頼に対応するジョブの出力に伴う出力物の仕様とに基づいてリクエストを効率的に管理することができる。
【００２７】
また、請求項９にかかる発明は、請求項１〜８の発明において、前記リクエスト手段により実行指示されるジョブの出力成果物に応じた進捗状況を管理する成果物手段と、前記リクエスト仕様保持手段が保持する仕様のうち前記出力成果物の仕様を保持する成果物仕様保持手段とをさらに備えたことを特徴とする。
【００２８】
この請求項９の発明によれば、リクエストクラスにより実行指示されるジョブの出力成果物に応じた進捗状況を管理する成果物クラスと、リクエスト仕様クラスが保持する仕様のうち出力成果物の仕様を保持する成果物仕様クラスとをさらに備えることとしたので、リクエストクラスが実行指示するジョブに対応した出力成果物が複数存在する場合であっても、リクエストを効率良く管理することができる。
【００２９】
また、請求項１０にかかる発明は、請求項９の発明において、前記成果物手段は、前記リクエスト手段により実行指示されるジョブの一または複数の出力成果物とそれぞれ一対一に対応することを特徴とする。
【００３０】
この請求項１０の発明によれば、リクエストクラスにより実行指示されるジョブの一または複数の出力成果物と成果物クラスがそれぞれ一対一に対応することとしたので、各出力成果物を効率良く管理することができる。
【００３１】
また、請求項１１にかかる発明は、請求項９または１０の発明において、前記成果物手段は、前記ジョブ処理依頼に伴って入力される入力物の進捗状況と、該ジョブ処理依頼に対応するジョブによって出力される成果物の進捗状況とを前記成果物進捗状況の一部として管理することを特徴とする。
【００３２】
この請求項１１の発明によれば、ジョブ処理依頼に伴って入力される入力物の進捗状況と、ジョブ処理依頼に対応するジョブによって出力される成果物の進捗状況とを成果物進捗状況の一部として管理することとしたので、各成果物の進捗状況を効率良く管理することができる。
【００３３】
また、請求項１２にかかる発明は、表示部、印刷部および撮像部などのハードウェア資源と、該ハードウェア資源を用いた画像形成に係るジョブ実行をおこなう共通処理部とを有し、ユーザ操作による画像形成に係るジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答するジョブを前記共通処理部で実行するとともに、各ジョブ処理依頼をリクエストとして管理する画像形成装置であって、前記リクエストを前記共通処理部に対して指示するリクエスト手段と、前記リクエスト手段の詳細な仕様を保持するリクエスト仕様保持手段と、前記リクエスト手段並びに前記リクエスト仕様保持手段をフォルダ管理するリクエスト保管手段とを備えたことを特徴とする。
【００３４】
この請求項１２の発明によれば、リクエストに応じたジョブの実行を指示するリクエストクラスと、リクエスト手段の詳細な仕様を保持するリクエスト仕様クラスと、これらのクラスをフォルダ管理するリクエストフォルダクラスとを備えることとしたので、異種ジョブのリクエストを一元的かつ効率良く受け付けて管理することができる。
【００３５】
また、請求項１３にかかる発明は、請求項１２の発明において、前記リクエスト手段は、前記リクエスト保管手段を木構造の親として該リクエスト保管手段により管理されることを特徴とする。
【００３６】
この請求項１３の発明によれば、リクエストフォルダクラスを木構造の親として、リクエストクラスがリクエストフォルダクラスにより管理されることとしたので、リクエストを一元的に効率良く管理することができる。
【００３７】
また、請求項１４にかかる発明は、請求項１２または１３の発明において、前記リクエスト保管手段は、受付可能なジョブ処理依頼の限界数と生成したリクエスト手段の数を有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理をおこなうことを特徴とする。
【００３８】
この請求項１４の発明によれば、受付可能なジョブ処理依頼の限界数と生成したリクエストクラスのオブジェクトの数を有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理をリクエストフォルダクラスがおこなうこととしたので、装置全体の処理許容量を越えた場合には、効率良くリクエストを拒否することができる。
【００３９】
また、請求項１５にかかる発明は、請求項１２、１３または１４の発明において、前記リクエスト仕様手段は、前記ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に前記要望仕様の代替仕様として用いられる許容仕様とを有することを特徴とする。
【００４０】
この請求項１５の発明によれば、ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に要望仕様の代替仕様として用いられる許容仕様とをリクエスト仕様クラスが有することとしたので、ユーザの要望仕様を満足させることができない場合であっても、ただちにリクエストを取り消すことなく代替仕様に基づいたジョブの実行を指示することができる。
【００４１】
また、請求項１６にかかる発明は、請求項１２〜１５の発明において、前記リクエスト手段により実行指示されるジョブの出力成果物に応じた進捗状況を管理する成果物手段と、前記リクエスト仕様保持手段が保持する仕様のうち前記出力成果物の仕様を保持する成果物仕様保持手段とをさらに備えたことを特徴とする。
【００４２】
この請求項１６の発明によれば、リクエストクラスにより実行指示されるジョブの出力成果物に応じた進捗状況を管理する成果物クラスと、リクエスト仕様クラスが保持する仕様のうち出力成果物の仕様を保持する成果物仕様クラスとをさらに備えることとしたので、リクエストクラスが実行指示するジョブに対応した出力成果物が複数存在する場合であっても、リクエストを効率良く管理することができる。
【００４３】
また、請求項１７にかかる発明は、ユーザから受け付けたジョブ処理のリクエストに応じて、他のサブシステムにジョブ処理の指示をおこなうジョブ処理指示方法であって、コンピュータは、ユーザから受け付けたリクエストの詳細な仕様をあらわすユーザの要望データを自己の属性区画で保持するリクエスト仕様保持手段を、該リクエストごとに生成するリクエスト仕様保持手段生成ステップと、前記リクエスト仕様保持手段のリンク情報およびリクエストの受け付けが可能な限界数を自己の属性区画で保持し、前記リクエスト仕様保持手段をフォルダ管理するリクエスト保管手段を生成するリクエスト保管手段生成ステップとを実行し、前記リクエスト保管手段は、前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定をおこなう判定ステップと、前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能なリクエスト手段を生成するリクエスト手段生成ステップと、前記リクエスト手段生成ステップにより生成したリクエスト手段に対して、前記リクエスト仕様保持手段のリンク情報を渡すことでリクエストの投入をおこなうリクエスト投入ステップとをコンピュータに実行させ、前記リクエスト手段は、前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記リクエスト仕様保持手段との関連付けをおこなうリクエスト仕様関連付けステップと、前記関連付けステップにより関連付けしたリクエスト仕様保持手段に対して、該リクエスト仕様保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップとをコンピュータに実行させ、前記リクエスト仕様保持手段は、前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記リクエスト手段に渡す参照ステップをコンピュータに実行させ、前記リクエスト手段は、前記リクエスト仕様保持手段から取得したユーザの要望データに従い、前記他のサブシステムに対してジョブ処理の開始を指示する指示ステップをコンピュータに実行させることを特徴とする。
【００４４】
この請求項１７の発明によれば、コンピュータは、ユーザから受け付けたリクエストの詳細な仕様をあらわすユーザの要望データを自己の属性区画で保持するリクエスト仕様オブジェクトを、リクエストごとに生成するリクエスト仕様オブジェクト生成ステップ（ステップＳ１１０２参照）と、リクエスト仕様オブジェクトのリンク情報およびリクエストの受け付けが可能な限界数を自己の属性区画で保持し、リクエスト仕様オブジェクトをフォルダ管理するリクエストフォルダオブジェクトを生成するリクエストフォルダオブジェクト生成ステップとを実行し、リクエストフォルダオブジェクトは、リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定をおこなう判定ステップ（ステップＳ１１０７参照）と、判定ステップにより投入可能と判定した場合には、リクエストに応じたジョブの実行を指示することが可能なリクエストオブジェクトを生成するリクエストオブジェクト生成ステップ（ステップＳ１１０８参照）と、リクエストオブジェクト生成ステップにより生成したリクエストオブジェクトに対して、リクエスト仕様オブジェクトのリンク情報を渡すことでリクエストの投入をおこなうリクエスト投入ステップ（ステップＳ１１０９参照）とをコンピュータに実行させ、リクエストオブジェクトは、渡されたリンク情報を自己の属性区画に保持することにより、自己とリクエスト仕様オブジェクトとの関連付けをおこなうリクエスト仕様関連付けステップ（ステップＳ１１１０参照）と、関連付けステップにより関連付けしたリクエスト仕様オブジェクトに対して、リクエスト仕様オブジェクトの属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップ（ステップＳ１１１１参照）とをコンピュータに実行させ、リクエスト仕様オブジェクトは、リクエストオブジェクトの参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、リクエストオブジェクトに渡す参照ステップをコンピュータに実行させ、リクエストオブジェクトは、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップ（ステップＳ１１１７参照）をコンピュータに実行させるよう構成したので、異種ジョブのリクエストを一元的かつ効率良く受け付けて管理することができる。
【００４５】
また、請求項１８にかかる発明は、請求項１７の発明において、前記リクエスト手段は、前記指示ステップの実行前に、前記リクエスト仕様保持手段から取得したユーザの要望データに従い、出力成果物に応じた進捗状況を管理する成果物手段を生成する成果物手段生成ステップと、前記成果物手段生成ステップにより生成した成果物手段に対して、前記リクエスト仕様保持手段のリンク情報を渡すリンク情報提供ステップとをコンピュータに実行させ、前記成果物手段は、前記参照ステップの実行後に、前記リクエスト仕様保持手段から取得したユーザの要望データに従い、前記リクエスト仕様保持手段が保持するユーザの要望データのうち、前記成果物手段に応じたユーザの要望データを自己の属性区画で保持する成果物仕様保持手段を生成する成果物仕様保持手段生成ステップと、前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記成果物仕様保持手段との関連付けをおこなう成果物仕様関連付けステップとをコンピュータに実行させることを特徴とする。
【００４６】
この請求項１８の発明によれば、リクエストオブジェクトは、指示ステップの実行前に、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、出力成果物に応じた進捗状況を管理する成果物オブジェクトを生成する成果物オブジェクト生成ステップ（ステップＳ１１１３参照）と、成果物オブジェクト生成ステップにより生成した成果物オブジェクトに対して、リクエスト仕様オブジェクトのリンク情報を渡すリンク情報提供ステップ（ステップＳ１１１４参照）とをコンピュータに実行させ、成果物オブジェクトは、参照ステップの実行後に、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、リクエスト仕様オブジェクトが保持するユーザの要望データのうち、成果物オブジェクトに応じたユーザの要望データを自己の属性区画で保持する成果物仕様オブジェクトを生成する成果物仕様オブジェクト生成ステップ（ステップＳ１１１５参照）と、渡されたリンク情報を自己の属性区画に保持することにより、自己と成果物仕様オブジェクトとの関連付けをおこなう成果物仕様関連付けステップ（ステップＳ１１１６参照）とをコンピュータに実行させるよう構成したので、各成果物の進捗状況を効率良く管理することができる。
【００４７】
また、請求項１９にかかる発明は、ユーザから受け付けたジョブ処理のリクエストに応じて、他のサブシステムにジョブ処理の指示をおこなうためのジョブ処理指示プログラムであって、コンピュータは、ユーザから受け付けたリクエストに基づいて生成され、前記リクエストの詳細な仕様をあらわすユーザの要望データを自己の属性区画で保持するリクエスト仕様保持手段と、前記リクエスト仕様保持手段のリンク情報およびリクエストの受け付けが可能な限界数を自己の属性区画で保持し、前記リクエスト仕様保持手段をフォルダ管理するリクエスト保管手段とを有した状態で、前記リクエスト保管手段は、前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定をおこなう判定ステップと、前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能なリクエスト手段を生成するリクエスト手段生成ステップと、前記リクエスト手段生成ステップにより生成したリクエスト手段に対して、前記リクエスト仕様保持手段のリンク情報を渡すことでリクエストの投入をおこなうリクエスト投入ステップとをコンピュータに実行させ、前記リクエスト手段は、前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記リクエスト仕様保持手段との関連付けをおこなうリクエスト仕様関連付けステップと、前記関連付けステップにより関連付けしたリクエスト仕様保持手段に対して、該リクエスト仕様保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップとをコンピュータに実行させ、前記リクエスト仕様保持手段は、前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記リクエスト手段に渡す参照ステップをコンピュータに実行させ、前記リクエスト手段は、前記リクエスト仕様保持手段から取得したユーザの要望データに従い、前記他のサブシステムに対してジョブ処理の開始を指示する指示ステップをコンピュータに実行させることを特徴とする。
【００４８】
この請求項１９の発明によれば、コンピュータは、ユーザから受け付けたリクエストに基づいて生成され、リクエストの詳細な仕様をあらわすユーザの要望データを自己の属性区画で保持するリクエスト仕様オブジェクトと、リクエスト仕様オブジェクトのリンク情報およびリクエストの受け付けが可能な限界数を自己の属性区画で保持し、リクエスト仕様オブジェクトをフォルダ管理するリクエストフォルダオブジェクトとを有した状態で、リクエストフォルダオブジェクトは、リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定をおこなう判定ステップ（ステップＳ１１０７参照）と、判定ステップにより投入可能と判定した場合には、リクエストに応じたジョブの実行を指示することが可能なリクエストオブジェクトを生成するリクエストオブジェクト生成ステップ（ステップＳ１１０８参照）と、リクエストオブジェクト生成ステップにより生成したリクエストオブジェクトに対して、リクエスト仕様オブジェクトのリンク情報を渡すことでリクエストの投入をおこなうリクエスト投入ステップ（ステップＳ１１０９参照）とをコンピュータに実行させ、リクエストオブジェクトは、渡されたリンク情報を自己の属性区画に保持することにより、自己とリクエスト仕様オブジェクトとの関連付けをおこなうリクエスト仕様関連付けステップ（ステップＳ１１１０参照）と、関連付けステップにより関連付けしたリクエスト仕様オブジェクトに対して、リクエスト仕様オブジェクトの属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップ（ステップＳ１１１１参照）とをコンピュータに実行させ、リクエスト仕様オブジェクトは、リクエストオブジェクトの参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、リクエストオブジェクトに渡す参照ステップをコンピュータに実行させ、リクエストオブジェクトは、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップ（ステップＳ１１１７参照）をコンピュータに実行させるよう構成したので、異種ジョブのリクエストを一元的かつ効率良く受け付けて管理することができる。
【００４９】
また、請求項２０にかかる発明は、請求項１９の発明において、前記リクエスト手段は、前記指示ステップの実行前に、前記リクエスト仕様保持手段から取得したユーザの要望データに従い、出力成果物に応じた進捗状況を管理する成果物手段を生成する成果物手段生成ステップと、前記成果物手段生成ステップにより生成した成果物手段に対して、前記リクエスト仕様保持手段のリンク情報を渡すリンク情報提供ステップとをコンピュータに実行させ、前記成果物手段は、前記参照ステップの実行後に、前記リクエスト仕様保持手段から取得したユーザの要望データに従い、前記リクエスト仕様保持手段が保持するユーザの要望データのうち、前記成果物手段に応じたユーザの要望データを自己の属性区画で保持する成果物仕様保持手段を生成する成果物仕様保持手段生成ステップと、前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記成果物仕様保持手段との関連付けをおこなう成果物仕様関連付けステップとをコンピュータに実行させることを特徴とする。
【００５０】
この請求項２０の発明によれば、リクエストオブジェクトは、指示ステップの実行前に、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、出力成果物に応じた進捗状況を管理する成果物オブジェクトを生成する成果物オブジェクト生成ステップ（ステップＳ１１１３参照）と、成果物オブジェクト生成ステップにより生成した成果物オブジェクトに対して、リクエスト仕様オブジェクトのリンク情報を渡すリンク情報提供ステップ（ステップＳ１１１４参照）とをコンピュータに実行させ、成果物オブジェクトは、参照ステップの実行後に、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、リクエスト仕様オブジェクトが保持するユーザの要望データのうち、成果物オブジェクトに応じたユーザの要望データを自己の属性区画で保持する成果物仕様オブジェクトを生成する成果物仕様オブジェクト生成ステップ（ステップＳ１１１５参照）と、渡されたリンク情報を自己の属性区画に保持することにより、自己と成果物仕様オブジェクトとの関連付けをおこなう成果物仕様関連付けステップ（ステップＳ１１１６参照）とをコンピュータに実行させるよう構成したので、各成果物の進捗状況を効率良く管理することができる。
【発明の効果】
【００５１】
請求項１にかかるリクエスト管理装置は、リクエストに応じたジョブの実行を指示するリクエストクラスと、リクエストクラスの詳細な仕様を保持するリクエスト仕様クラスと、これらのクラスをフォルダ管理するリクエストフォルダクラスとを備えることとしたので、異種ジョブのリクエストを一元的かつ効率良く受け付けおよび管理することができるという効果を奏する。
【００５２】
また、請求項２にかかるリクエスト管理装置は、リクエストクラスとリクエスト仕様クラスとが一対一に対応し、対応するリクエスト仕様クラスへのリンク情報をかかるリクエストクラスが保持することとしたので、リクエストとリクエストの詳細情報とを対応づけて管理することができるという効果を奏する。
【００５３】
また、請求項３にかかるリクエスト管理装置は、リクエスト管理クラスを木構造の親として、リクエストクラスがリクエストフォルダクラスにより管理されることとしたので、リクエストを一元的に効率良く管理することができるという効果を奏する。
【００５４】
また、請求項４にかかるリクエスト管理装置は、対応するジョブの実行状態の取得および保持をリクエストクラスがおこなうこととしたので、ジョブの実行状態を効率良く管理することができるという効果を奏する。
【００５５】
また、請求項５にかかるリクエスト管理装置は、ユーザ操作によりジョブ処理依頼を受け付けた際に、かかるユーザ操作の種別に応じたリクエストクラスのオブジェクトの生成をリクエストフォルダクラスがおこなうこととしたので、異種ジョブのリクエストを効率良く管理することができるという効果を奏する。
【００５６】
また、請求項６にかかるリクエスト管理装置は、受付可能なジョブ処理依頼の限界数と生成したリクエストクラスのオブジェクトの数を有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理をリクエストフォルダクラスがおこなうこととしたので、装置全体の処理許容量を越えた場合には、効率良くリクエストを拒否することができるという効果を奏する。
【００５７】
また、請求項７にかかるリクエスト管理装置は、ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に要望仕様の代替仕様として用いられる許容仕様とをリクエスト仕様クラスが有することとしたので、ユーザの要望仕様を満足させることができない場合であっても、ただちにリクエストを取り消すことなく代替仕様に基づいたジョブの実行を指示することができるという効果を奏する。
【００５８】
また、請求項８にかかるリクエスト管理装置は、入力仕様および出力仕様を要望仕様が有することとしたので、ジョブ処理依頼の入力に伴う入力物の仕様と、ジョブ処理依頼に対応するジョブの出力に伴う出力物の仕様とに基づいてリクエストを効率的に管理することができるという効果を奏する。
【００５９】
また、請求項９にかかるリクエスト管理装置は、リクエストクラスにより実行指示されるジョブの出力成果物に応じた進捗状況を管理する成果物クラスと、リクエスト仕様クラスが保持する仕様のうち出力成果物の仕様を保持する成果物仕様クラスとをさらに備えることとしたので、リクエストクラスが実行指示するジョブに対応した出力成果物が複数存在する場合であっても、リクエストを効率良く管理することができるという効果を奏する。
【００６０】
また、請求項１０にかかるリクエスト管理装置は、リクエストクラスにより実行指示されるジョブの一または複数の出力成果物と成果物クラスがそれぞれ一対一に対応することとしたので、各出力成果物を効率良く管理することができるという効果を奏する。
【００６１】
また、請求項１１にかかるリクエスト管理装置は、ジョブ処理依頼に伴って入力される入力物の進捗状況と、該ジョブ処理依頼に対応するジョブによって出力される成果物の進捗状況とを成果物進捗状況の一部として管理することとしたので、各成果物の進捗状況を効率良く管理することができるという効果を奏する。
【００６２】
また、請求項１２にかかる画像形成装置は、リクエストに応じたジョブの実行を指示するリクエストクラスと、リクエストクラスの詳細な仕様を保持するリクエスト仕様クラスと、これらのクラスをフォルダ管理するリクエストフォルダクラスとを備えることとしたので、異種ジョブのリクエストを一元的かつ効率良く受け付けおよび管理することができるという効果を奏する。
【００６３】
また、請求項１３にかかる画像形成装置は、リクエスト管理クラスを木構造の親として、リクエストクラスがリクエストフォルダクラスにより管理されることとしたので、リクエストを一元的に効率良く管理することができるという効果を奏する。
【００６４】
また、請求項１４にかかる画像形成装置は、受付可能なジョブ処理依頼の限界数と生成したリクエストクラスのオブジェクトの数を有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理をリクエストフォルダクラスがおこなうこととしたので、装置全体の処理許容量を越えた場合には、効率良くリクエストを拒否することができるという効果を奏する。
【００６５】
また、請求項１５にかかる画像形成装置は、ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に要望仕様の代替仕様として用いられる許容仕様とをリクエスト仕様クラスが有することとしたので、ユーザの要望仕様を満足させることができない場合であっても、ただちにリクエストを取り消すことなく代替仕様に基づいたジョブの実行を指示することができるという効果を奏する。
【００６６】
また、請求項１６にかかる画像形成装置は、リクエストクラスにより実行指示されるジョブの出力成果物に応じた進捗状況を管理する成果物クラスと、リクエスト仕様クラスが保持する仕様のうち出力成果物の仕様を保持する成果物仕様クラスとをさらに備えることとしたので、リクエストクラスが実行指示するジョブに対応した出力成果物が複数存在する場合であっても、リクエストを効率良く管理することができるという効果を奏する。
【００６７】
また、請求項１７にかかるジョブ処理指示方法は、コンピュータは、ユーザから受け付けたリクエストの詳細な仕様をあらわすユーザの要望データを自己の属性区画で保持するリクエスト仕様オブジェクトを、リクエストごとに生成するリクエスト仕様オブジェクト生成ステップ（ステップＳ１１０２参照）と、リクエスト仕様オブジェクトのリンク情報およびリクエストの受け付けが可能な限界数を自己の属性区画で保持し、リクエスト仕様オブジェクトをフォルダ管理するリクエストフォルダオブジェクトを生成するリクエストフォルダオブジェクト生成ステップとを実行し、リクエストフォルダオブジェクトは、リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定をおこなう判定ステップ（ステップＳ１１０７参照）と、判定ステップにより投入可能と判定した場合には、リクエストに応じたジョブの実行を指示することが可能なリクエストオブジェクトを生成するリクエストオブジェクト生成ステップ（ステップＳ１１０８参照）と、リクエストオブジェクト生成ステップにより生成したリクエストオブジェクトに対して、リクエスト仕様オブジェクトのリンク情報を渡すことでリクエストの投入をおこなうリクエスト投入ステップ（ステップＳ１１０９参照）とをコンピュータに実行させ、リクエストオブジェクトは、渡されたリンク情報を自己の属性区画に保持することにより、自己とリクエスト仕様オブジェクトとの関連付けをおこなうリクエスト仕様関連付けステップ（ステップＳ１１１０参照）と、関連付けステップにより関連付けしたリクエスト仕様オブジェクトに対して、リクエスト仕様オブジェクトの属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップ（ステップＳ１１１１参照）とをコンピュータに実行させ、リクエスト仕様オブジェクトは、リクエストオブジェクトの参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、リクエストオブジェクトに渡す参照ステップをコンピュータに実行させ、リクエストオブジェクトは、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップ（ステップＳ１１１７参照）をコンピュータに実行させるよう構成したので、異種ジョブのリクエストを一元的かつ効率良く受け付けて管理することができるという効果を奏する。
【００６８】
また、請求項１８にかかるジョブ処理指示方法は、リクエストオブジェクトは、指示ステップの実行前に、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、出力成果物に応じた進捗状況を管理する成果物オブジェクトを生成する成果物オブジェクト生成ステップ（ステップＳ１１１３参照）と、成果物オブジェクト生成ステップにより生成した成果物オブジェクトに対して、リクエスト仕様オブジェクトのリンク情報を渡すリンク情報提供ステップ（ステップＳ１１１４参照）とをコンピュータに実行させ、成果物オブジェクトは、参照ステップの実行後に、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、リクエスト仕様オブジェクトが保持するユーザの要望データのうち、成果物オブジェクトに応じたユーザの要望データを自己の属性区画で保持する成果物仕様オブジェクトを生成する成果物仕様オブジェクト生成ステップ（ステップＳ１１１５参照）と、渡されたリンク情報を自己の属性区画に保持することにより、自己と成果物仕様オブジェクトとの関連付けをおこなう成果物仕様関連付けステップ（ステップＳ１１１６参照）とをコンピュータに実行させるよう構成したので、各成果物の進捗状況を効率良く管理することができるという効果を奏する。
【００６９】
また、請求項１９にかかるジョブ処理指示プログラムは、コンピュータは、ユーザから受け付けたリクエストに基づいて生成され、リクエストの詳細な仕様をあらわすユーザの要望データを自己の属性区画で保持するリクエスト仕様オブジェクトと、リクエスト仕様オブジェクトのリンク情報およびリクエストの受け付けが可能な限界数を自己の属性区画で保持し、リクエスト仕様オブジェクトをフォルダ管理するリクエストフォルダオブジェクトとを有した状態で、リクエストフォルダオブジェクトは、リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定をおこなう判定ステップ（ステップＳ１１０７参照）と、判定ステップにより投入可能と判定した場合には、リクエストに応じたジョブの実行を指示することが可能なリクエストオブジェクトを生成するリクエストオブジェクト生成ステップ（ステップＳ１１０８参照）と、リクエストオブジェクト生成ステップにより生成したリクエストオブジェクトに対して、リクエスト仕様オブジェクトのリンク情報を渡すことでリクエストの投入をおこなうリクエスト投入ステップ（ステップＳ１１０９参照）とをコンピュータに実行させ、リクエストオブジェクトは、渡されたリンク情報を自己の属性区画に保持することにより、自己とリクエスト仕様オブジェクトとの関連付けをおこなうリクエスト仕様関連付けステップ（ステップＳ１１１０参照）と、関連付けステップにより関連付けしたリクエスト仕様オブジェクトに対して、リクエスト仕様オブジェクトの属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップ（ステップＳ１１１１参照）とをコンピュータに実行させ、リクエスト仕様オブジェクトは、リクエストオブジェクトの参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、リクエストオブジェクトに渡す参照ステップをコンピュータに実行させ、リクエストオブジェクトは、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップ（ステップＳ１１１７参照）をコンピュータに実行させるよう構成したので、異種ジョブのリクエストを一元的かつ効率良く受け付けて管理することができるという効果を奏する。
【００７０】
また、請求項２０にかかるジョブ処理指示プログラムは、リクエストオブジェクトは、指示ステップの実行前に、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、出力成果物に応じた進捗状況を管理する成果物オブジェクトを生成する成果物オブジェクト生成ステップ（ステップＳ１１１３参照）と、成果物オブジェクト生成ステップにより生成した成果物オブジェクトに対して、リクエスト仕様オブジェクトのリンク情報を渡すリンク情報提供ステップ（ステップＳ１１１４参照）とをコンピュータに実行させ、成果物オブジェクトは、参照ステップの実行後に、リクエスト仕様オブジェクトから取得したユーザの要望データに従い、リクエスト仕様オブジェクトが保持するユーザの要望データのうち、成果物オブジェクトに応じたユーザの要望データを自己の属性区画で保持する成果物仕様オブジェクトを生成する成果物仕様オブジェクト生成ステップ（ステップＳ１１１５参照）と、渡されたリンク情報を自己の属性区画に保持することにより、自己と成果物仕様オブジェクトとの関連付けをおこなう成果物仕様関連付けステップ（ステップＳ１１１６参照）とをコンピュータに実行させるよう構成したので、各成果物の進捗状況を効率良く管理することができるという効果を奏する。
【発明を実施するための最良の形態】
【００７１】
以下に添付図面を参照して、この発明にかかるリクエスト管理装置、画像形成装置、ジョブ処理指示方法およびジョブ処理指示プログラムの最良な実施の形態を詳細に説明する。なお、本実施の形態では、この発明を画像形成装置に適用した場合について説明するが、本発明はこれに限らず、リクエスト管理をおこなう各種装置に適用することができる。
【００７２】
まず、本実施の形態に係る画像形成装置（以下「複合機」と言う）１の概念について図１、図２、図３、図１６および図１７を用いて説明する。図１は、本実施の形態に係る複合機１を取り巻くネットワーク環境を説明するためのネットワーク図であり、図２は、図１に示した複合機１のハードウェア構成を示すブロック図であり、図３は、図１に示した複合機１のソフトウェアとハードウェアの関係を説明するための説明図であり、図１６は、複合機１に搭載されるソフトウェア構成の変遷を説明するための説明図であり、図１７は、従来の複合機のソフトウェアとハードウェアの関係を説明するための説明図である。
【００７３】
図１に示すように、近年のネットワーク化の進展により、オフィスなどに設けられたパーソナルコンピュータ（ＰＣ）などの機器は、ＬＡＮ（Local Area Network）などのネットワークに接続され、相互に通信することができる。たとえば、同図に示したように、ＬＡＮなどのネットワークには、クライアントＰＣ、ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ、ＦＴＰ（File Transfer Protocol）サーバ、サーバＰＣなどが接続され、電子メールの送受信やファイル転送をすることができ、モデム接続された配信サーバは、オフィス外のファックス装置と通信することができる。
【００７４】
このようなネットワーク化の進展に伴い、複合機１についてもネットワークに接続され、ＰＣ等の機器と相互に通信することが可能となり、ハードディスク等の記憶装置を内蔵することで、いわゆるネットワーク複合機へと進化し、ユーザの様々なニーズに応えることができるようになった。
【００７５】
具体的には、複合機１は、通常のコピー機能に加えて、クライアントＰＣからの印刷要求により文書データ等を印刷するプリンタ機能、クライアントＰＣからのファックス要求により文書データ等をサーバＰＣに接続されたモデムを経由して他のオフィスのファックス機器に送信するファックス機能、受信したファックス文書やコピー文書を内蔵したハードディスクに蓄積する蓄積機能などを有するようになった。このような多くの機能を実現するために、複合機１に搭載されるソフトウェアは規模が大きくなり、また、複雑なものとなってきた。
【００７６】
図２は、かかる複合機１のハードウェア構成を示すブロック図である。同図に示すように、この複合機１は、コントローラ１０とエンジン部（Engine）６０とをＰＣＩ（Peripheral Component Interconnect）バスで接続した構成となる。コントローラ１０は、複合機１全体の制御と描画、通信、図示しない操作部からの入力を制御するコントローラである。エンジン部６０は、ＰＣＩバスに接続可能なプリンタエンジンなどであり、たとえば白黒プロッタ、１ドラムカラープロッタ、４ドラムカラープロッタ、スキャナまたはファックスユニットなどである。なお、このエンジン部６０には、プロッタなどのいわゆるエンジン部分に加えて、誤差拡散やガンマ変換などの画像処理部分が含まれる。
【００７７】
コントローラ１０は、ＣＰＵ１１と、ノースブリッジ（ＮＢ）１３と、システムメモリ（ＭＥＭ−Ｐ）１２と、サウスブリッジ（ＳＢ）１４と、ローカルメモリ（ＭＥＭ−Ｃ）１７と、ＡＳＩＣ（Application Specific Integrated Circuit）１６と、ハードディスクドライブ（ＨＤＤ）１８とを有し、ノースブリッジ（ＮＢ）１３とＡＳＩＣ１６との間をＡＧＰ（Accelerated Graphics Port）バス１５で接続した構成となる。また、ＭＥＭ−Ｐ１２は、ＲＯＭ（Read Only Memory）１２ａと、ＲＡＭ(Random Access Memory)とをさらに有する。
【００７８】
ＣＰＵ１１は、複合機１の全体制御をおこなうものであり、ＮＢ１３、ＭＥＭ−Ｐ１２およびＳＢ１４からなるチップセットを有し、このチップセットを介して他の機器と接続される。
【００７９】
ＮＢ１３は、ＣＰＵ１１とＭＥＭ−Ｐ１２、ＳＢ１４、ＡＧＰ１５とを接続するためのブリッジであり、ＭＥＭ−Ｐ１２に対する読み書きなどを制御するメモリコントローラと、ＰＣＩマスタおよびＡＧＰターゲットとを有する。
【００８０】
ＭＥＭ−Ｐ１２は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ＲＯＭ１２ａとＲＡＭ１２ｂとからなる。ＲＯＭ１２ａは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、ＲＡＭ１２ｂは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。
【００８１】
ＳＢ１４は、ＮＢ１３とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。このＳＢ１４は、ＰＣＩバスを介してＮＢ１３と接続されており、このＰＣＩバスには、ネットワークインターフェース（Ｉ／Ｆ）部なども接続される。
【００８２】
ＡＳＩＣ１６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）であり、ＡＧＰ１５、ＰＣＩバス、ＨＤＤ１８およびＭＥＭ−Ｃ１７をそれぞれ接続するブリッジの役割を有する。このＡＳＩＣ１６は、ＰＣＩターゲットおよびＡＧＰマスタと、ＡＳＩＣ１６の中核をなすアービタ（ＡＲＢ）と、ＭＥＭ−Ｃ１７を制御するメモリコントローラと、ハードウェアロジックなどにより画像データの回転などをおこなう複数のＤＭＡＣ（Direct Memory Access Controller）と、エンジン部６０との間でＰＣＩバスを介したデータ転送をおこなうＰＣＩユニットとからなる。このＡＳＩＣ１６には、ＰＣＩバスを介してＦＣＵ（Fax Control Unit）３０、ＵＳＢ（Universal Serial Bus）４０、ＩＥＥＥ１３９４（the Institute of Electrical and Electronics Engineers 1394）インターフェース５０が接続される。
【００８３】
ＭＥＭ−Ｃ１７は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＨＤＤ（Hard Disk Drive）１８は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージである。
【００８４】
ＡＧＰ１５は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、ＭＥＭ−Ｐ１２に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にするものである。
【００８５】
図３は、かかる複合機１のハードウェアおよびソフトウェアの構成を示した概念図であり、具体的には、後述する本実施形態の特徴部分であるリクエスト管理部１１３ａを含む統合アプリケーション１１０と、ソフトウェア１００およびハードウェア２００の階層関係を示している。同図に示すように、ハードウェア２００は、ハードウェアリソース２０１を有し、このハードウェアリソース２０１は、スキャナ２０１ａ、プロッタ２０１ｂ、ＨＤＤ（Hard Disk Drive）２０１ｃ、ネットワーク２０１ｄおよびその他のリソース２０１ｅを有する。なお、その他のリソース２０１ｅは、２０１ａ〜２０１ｄ以外のハードウェアリソース２０１のことであり、たとえば、操作パネルなどの入出力デバイスを示す。
【００８６】
また、かかるハードウェア２００に搭載されるソフトウェア１００は階層化されており、オペレーティングシステム１０３の上層にはサービス層１０２が構築され、このサービス層１０２の上層にはアプリケーション層１０３が構築されている。そして、サービス層１０２は、各ハードウェアリソース（２０１ａ〜２０１ｅ）を制御するドライバーに相当する、スキャナ制御１０２部ａ、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃ、配信／メール送受信制御部１０２ｄ、ＦＡＸ送受信制御部１０２ｅ、ネットワーク通信制御部１０２ｆおよびその他の制御部１０２ｇを有する。
【００８７】
ここで、図３に示したソフトウェア１００が、かかる階層構造をとるに至った経緯について、図１６および図１７を用いて説明する。図１６は、複合機１に搭載されるソフトウェア構成の変遷を示す説明図である。図１６のサービス層分離前アプリケーション５０１に示すように、多機能化した複合機１に搭載されるソフトウェアは、コピーアプリケーション、ＦＡＸアプリケーション、スキャナアプリケーションなどの機能別に独立したアプリケーションとして作成され、図３に示したオペレーティングシステム１０３上で動作していた。
【００８８】
しかしながら、これらのアプリケーションは、ハードウェアリソースを制御するドライバー（サービス層１０２）を含んでいたため、各アプリケーションには重複した処理が存在していた。その結果、各アプリケーションの規模は大きなものとなっていた。
【００８９】
そこで、図１６のサービス層分離後アプリケーション５０２に示すように、サービス層分離前アプリケーション５０１のサービス層１０２相当部分を括りだしサービス層１０２とするとともに、各アプリケーションは、このサービス層１０２の上層であるアプリケーション層１０１に構築する構成とした。かかる階層化構成をとることにより、各アプリケーションはスリム化され開発労力も軽減された。
【００９０】
しかしながら、複合機１のネットワーク化、多機能化がさらに進展するに従って、各アプリケーションに共通処理部分が存在することが問題となってきた。具体的には、アプリケーション層１０１の各アプリケーション、たとえば、コピーアプリケーションやスキャナアプリケーションなどは、それぞれ、スキャナ制御部１０２ａや蓄積制御部１０２ｃといったドライバーと通信をおこなう処理や、リクエスト受付やリクエスト実行といったジョブ管理処理などの同様な処理を内部に有していた。このように、同様な処理を各アプリケーションが有していると、各アプリケーションの開発規模が大きくなるとともに、サービス層の仕様変更に対する各アプリケーションの改修規模が大きくなることが問題となってきた。
【００９１】
この問題を解決するため、図１６の共通ルーチン分離アプリケーション５０３に示すように、かかる同様な処理（共通処理部分）を共通ルーチンとして括りだすことも考えられた。しかしながら、かかる共通ルーチンは、各アプリケーションにおいて微妙に異なる処理を共通化しようとするものであるため、共通ルーチン内部の処理は複雑なものとなってしまう。また、たとえば、プリンタアプリケーションなどの新規アプリケーションを追加する場合においては、かかる新規アプリケーションに適応するために、共通ルーチンの改修が必要となる。
【００９２】
しかし、共通ルーチンの内部処理は複雑であるため、改修要員が処理を把握することが困難となり、改修規模の増大や、改修ミスによる他のアプリケーションへの影響が懸念された。
【００９３】
そこで、図１６のオブジェクト指向アプリケーション５０４に示すように、オブジェクト指向による設計手法（オブジェクトモデリング）により、かかる複数のアプリケーションを、統合アプリケーション１１０に統合することとした。具体的には、各アプリケーションの共通処理部分をオブジェクトモデルとして抽出し、このオブジェクトモデルの集合体から、統合アプリケーション１１０を構成する。そして、従来のコピー機能やスキャナ機能といった機能は、かかるオブジェクトモデルの協調関係によって実現する。
【００９４】
このような構成をとることにより、たとえばプリンタ機能のような新規機能の追加は、かかるオブジェクトモデルに属するクラスのサブクラス化などにより対処できる。このため、改修部分が明確となり、改修による他の機能への影響を小さくすることができる。また、オブジェクトモデリングによるプログラムは、従来の手続き型プログラムに比べて、処理の把握が容易であるため、改修要員が処理を把握することも容易となり、改修規模の削減や、改修ミスによる他のアプリケーションへの影響を小さくすることができる。
【００９５】
図１７は、図１６に示したサービス層分離後アプリケーション５０２の段階における従来のアプリケーションの構成と、かかるアプリケーションとサービス層１０２の各ドライバーの関係を示した説明図である。同図に示すように、アプリケーション層１０１は、コピーアプリケーション１２０、スキャナアプリケーション１３０、ファックスアプリケーション１４０およびプリンタアプリケーション１５０を有する。
【００９６】
たとえば、コピーアプリケーション１２０は、コピー機能を実現するために、スキャナ制御部１０２ａ、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃおよびその他の制御部１０２ｇとデータの送受信をおこなう。また、ファックスアプリケーション１４０は、ファックス機能を実現するために、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃ、ＦＡＸ送受信制御部１０２ｅ、ネットワーク通信制御部１０２ｆおよびその他の制御部１０２ｇとデータの送受信をおこなう。このように、アプリケーション層１０１の各アプリケーションとサービス層１０２の各ドライバー間の通信は、複雑なものとなっていた。
【００９７】
図３の説明に戻ると、上述したオブジェクトモデリングにより、アプリケーション層１０１に存在した複数のアプリケーションは、統合アプリケーション１１０に統合されている。そして、各アプリケーションが重複しておこなっていた各ドライバーとの通信処理は、統合アプリケーション１１０を構成する所定のオブジェクトモデルにおこなわせるように構成したことにより、アプリケーション層１０１のアプリケーションと、サービス層１０２の各ドライバー間の通信は、図１７と比較して単純になっている。
【００９８】
次に、統合アプリケーション１１０の内部構成について説明する。図４は、後述する本実施形態の特徴部分であるリクエスト管理部１１３ａの統合アプリケーション１１０における位置づけと、かかる統合アプリケーション１１０の概要構成を説明するための説明図である。
【００９９】
同図に示すように、統合アプリケーション１１０は、操作系サブシステム１１１と、管理系サブシステム１１２および実行系サブシステム１１３とを有する。操作系サブシステム１１１は、マンマシンインタフェースを担当するソフトウェア群である。具体的には、この操作系サブシステム１１１は、ユーザの要求の受付サービスをおこなうとともに、かかる要求に対応した成果物（たとえば、コピーした記録紙）の品質、コストおよび納期を考慮したうえで、ユーザに対して情報提供サービスをおこなう。
【０１００】
管理系サブシステム１１２は、複合機１の資源を管理するソフトウェア群である。具体的には、この管理系サブシステム１１２は、ハードウェアリソース２０１およびこのハードウェアリソース２０１が保持するデータ状態の管理サービスをおこなう。
【０１０１】
実行系サブシステム１１３は、ユーザ要求の実行を担当するソフトウェア群である。具体的には、この実行系サブシステム１１３は、コピーなどの文書操作要求から成果物の出力までの実行サービスをおこなう。そして、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３は、必要に応じて相互に処理を依頼し結果を受けとることで、統合アプリケーション１１０全体として複合機１に必要とされるサービス提供をおこなう。
【０１０２】
かかる実行系サブシステム１１３は、後述する本実施形態の特徴部分であるリクエスト管理部１１３ａと実行制御部１１３ｂとを有する。リクエスト管理部１１３ａは、いわゆるジョブ管理をおこなうソフトウェア群である。具体的には、ユーザの要求をリクエストとして受け付け、このリクエストを実行するとともに、かかるリクエストの実行状態を管理する。
【０１０３】
また、実行制御部１１３ｂは、実行系サブシステム１１３からリクエスト管理部１１３ａを除いた、その他の実行制御をおこなうソフトウェア群である。なお、図４において、リクエスト管理部１１３ａが、操作系サブシステム１１１の近くに配置されているのは、ユーザのリクエストを管理するリクエスト管理部１１３ａが、マンマシンインタフェースを担当する操作系サブシステム１１１と密接な関係を有することを示している。
【０１０４】
図５は、図４に示した各サブシステムを、ＵＭＬ（Unified Modeling Language）のクラス図（ＵＭＬクラス図）に置換えた図である。ここで、ＵＭＬとは、ＯＭＧ（Object Management Group）という団体がまとめたシステムモデリング言語であり、システムモデリングの成果を記述する記法を定義したものである。そして、このＵＭＬは、オブジェクト指向によるソフトウェア開発において、一般的に用いられている。
【０１０５】
図５に示すように、統合アプリケーション１１０は複数のパッケージを含み、この統合アプリケーション１１０自体もパッケージととらえることができる。ここで、パッケージとはＵＭＬモデルの各構成要素（シンボル）をグループ化したものであり、このパッケージは、左上にタブのついたフォルダ型のシンボルで表現する。なお、かかるパッケージは、上述したオブジェクトモデルあるいはオブジェクトモデルの集合体ととらえることもできる。
【０１０６】
図５に示したように、統合アプリケーション１１０は、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３の３つのパッケージを内部に有するパッケージである。さらに、実行系サブシステム１１３は、リクエスト管理部１１３ａおよび実行制御部１１３ｂの２つのパッケージを内部に有するパッケージである。そして、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３を相互に結ぶ直線は、各パッケージ間にメッセージ送受信などの関連があることを示している。なお、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３のタブの右端に記された記号は、かかるパッケージがサブシステムであることを示すＵＭＬのシンボルである。
【０１０７】
次に、本実施形態の特徴部分であるリクエスト管理部１１３ａについて詳細に説明する。このリクエスト管理部１１３ａは、ユーザから受け付けたジョブの実行依頼を管理するとともに、かかる実行依頼に応じて、実行制御部１１３ｂにジョブの実行指示をおこない、実行指示をおこなったジョブの進捗管理をおこなうことを責務とする。
【０１０８】
図６−１は、「ディレクトリ−ファイル」モデルを説明するための説明図であり、図６−２は、リクエスト管理部のモデリングの概要を説明するための説明図である。図６−１に示すように、いわゆる「ディレクトリ−ファイル」モデルは、ＵＮＩＸ（登録商標）やＷＩＮＤＯＷＳ（登録商標）といったオペレーティングシステム（ＯＳ）において、ファイル管理モデルとして一般的に使用されているモデルである。
【０１０９】
この「ディレクトリ−ファイル」モデルは、複数のファイルを管理するディレクトリと、かかるディレクトリの管理下にあるファイルとを有し、ディレクトリおよびファイルは、それぞれディレクトリおよびファイルの詳細情報であるプロパティを有している。この「ディレクトリ−ファイル」モデルを採用することにより、かかるＯＳは、ファイルの作成、コピー、移動、削除および一覧表示といったファイル管理を実現している。
【０１１０】
このように、従来から用いられている「ディレクトリ−ファイル」モデルの類推（アナロジー）により、かかるリクエスト管理部１１３ａのモデリングをおこなうことで、安定したリクエスト管理モデルを実現できることが予想される。
【０１１１】
そこで、図６−２に示すように、リクエスト管理部１１３ａは、複数のリクエストを管理するリクエストフォルダと、かかるリクエストフォルダの管理下にあるリクエストとを有し、リクエストはリクエストの詳細情報であるリクエスト仕様を有する構成をとることとした。なお、「ディレクトリ−ファイル」モデルは、一般的に、ディレクトリ配下にディレクトリを階層的に有する階層構造をとるが、リクエスト管理部１１３ａはかかる階層構造をとらない構成とした。しかしながら、リクエスト管理部１１３ａはかかる階層構造をとる構成とすることもできる。
【０１１２】
このように、「ディレクトリ−ファイル」モデルのアナロジーとして構成したリクエスト管理部１１３ａのクラス構成を、ＵＭＬのクラス図（ＵＭＬクラス図）により表現したものを図７に示す。ここで、クラスとは、オブジェクト指向システムを構成するオブジェクトの設計図に相当する概念であり、このクラスは、データと処理を一体化（カプセル化）して内部に有するとともに、継承関係や集約関係といった、他のクラスとの静的な関係を有する。そして、クラス図においては、各クラスが内部に有するデータおよび処理、複数のクラス間の静的な関係が表される。
【０１１３】
次に、本実施形態の特徴部分であるリクエスト管理部１１３ａのクラス構成について説明する。図７に示すように、リクエスト管理部１１３ａは、リクエストフォルダクラス３１０と、リクエストクラス３２０と、リクエスト仕様クラス３３０と、成果物クラス３４０および成果物仕様クラス３５０とを有する。
【０１１４】
各クラスを示す矩形は３段の区画を有し、上から、クラス名を示す名前区画、クラスが有するデータ（属性）を示す属性区画およびクラスが有する処理（操作）を示す操作区画と呼ばれる。たとえば、リクエストフォルダクラス３１０を示す矩形の名前区画は、かかるクラスのクラス名が「リクエストフォルダ」であることを示し、属性区画は、かかるクラスが有する属性が、「受付状態」と「限界数」であることを示し、操作区画は、かかるクラスが有する操作が、「リクエスト投入（）」であることを示している。
【０１１５】
このように、各クラスは、データ（属性）を所持するための属性区画と、かかる属性の書き込みおよび読み出しをおこなう処理（操作）を所持するための操作区画とを有している。これらのクラスは、プログラム（統合アプリケーション１１０）の一部として含まれるので、あらかじめＲＯＭ１２ａに格納されたこのプログラムが実行されると、各クラスはＲＡＭ１２ｂの所定領域に実体化され、属性区画に含まれる各データ（属性）がＲＡＭ１２ｂ上に展開される。したがって、クラスを実体化したオブジェクトは、ＲＡＭ１２ｂ上の各データ（属性）の書き込みおよび読み出しをすることが可能となる。
【０１１６】
なお、属性や操作といったクラスの要素の左側に「−」記号を付した場合は、かかる要素は外部のクラスには非公開であることを示し、「＋」記号を付した場合は、かかる要素は外部のクラスに公開されていることを示す。また、操作については「リクエスト投入（）」のように「（）」記号を付することが通例であり、「（引数１，引数２）」のように、かかる操作に引き渡す引数を記述する場合もある。
【０１１７】
次に、図７に示した各クラスについて説明する。リクエストフォルダクラス３１０は、リクエストの受付およびリクエストの管理をおこなうクラスである。具体的には、このリクエストフォルダクラス３１０は、属性として、受付状態３１０ａおよび限界数３１０ｂを有し、操作として、リクエスト投入（）３１０ｃを有する。なお、かかるリクエストフォルダクラス３１０を実体化したオブジェクトが生成されると、受付状態３１０ａおよび限界数３１０ｂはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。
【０１１８】
受付状態３１０ａは、リクエストフォルダクラスが管理中のリクエストの数と、限界数３１０ｂとから決定される受付可否の状態であり、たとえば、限界数３１０ｂが２００である場合において、すでに管理中のリクエストが２００であれば、かかる受付状態３１０ａは、受付拒否の状態を保持する。また、限界数３１０ｂは、複合機１が許容する最大のリクエスト数であり、統合アプリケーション１１０が搭載されるハードウェア仕様により変動する。また、リクエスト投入（）３１０ｃは、ユーザの操作により、操作系サブシステム１１１からリクエストを受け付けリクエストクラス３２０にリクエストの実行を依頼する処理をおこなう。
【０１１９】
リクエストクラス３２０は、リクエストの実行および成果物の管理をおこなうクラスである。具体的には、このリクエストクラス３２０は、属性として、要求状態３２０ａを有し、操作として、実現（）３２０ｂを有する。要求状態３２０ａは、リクエストに係る文書操作の実行状態、たとえば、実行中、中断中などの状態である。また、実現（）３２０ｂは、リクエストフォルダクラス３１０からリクエスト開始依頼を受け付けると、リクエスト仕様クラス３３０が保持するリクエスト詳細情報を参照することで、作成すべき成果物の種類を判別し、成果物クラス３４０に対して文書作成開始を依頼する処理をおこなう。なお、かかるリクエストクラス３２０を実体化したオブジェクトが生成されると、要求状態３２０ａはＲＡＭ１２ｂ上に展開されるので、このデータ（属性）の書き込みおよび読み出しをすることが可能となる。
【０１２０】
リクエスト仕様クラス３３０は、リクエストの詳細情報を保持するとともに、他のクラスからの要求により、この詳細情報を提供するクラスである。具体的には、このリクエスト仕様クラス３３０は、属性として、許容仕様３３０ａおよびユーザの要望３３０ｂを有し、操作として、設定（）３３０ｃおよび参照（）３３０ｄを有する。なお、かかるリクエスト仕様クラス３３０を実体化したオブジェクトが生成されると、許容範囲３３０ａおよびユーザの要望３３０ｂはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。
【０１２１】
許容仕様３３０ａは、リクエストの実行中に発生したトラブルにより処理の続行が不可能となった場合における、ユーザの要望３３０ｂの代替仕様である。ユーザの要望３３０ｂは、入力仕様および出力仕様を有する。具体的には、ユーザが複合機１に対して指示した入力原稿の種類および入力方法についての仕様が入力仕様であり、入力原稿をもとに出力される成果物の種類および出力方法についての仕様が出力仕様である。たとえば、ユーザが複合機１を操作して、普通紙原稿を複合機１のＡＤＦ（自動原稿送り装置）にセットし、Ａ４の記録用紙に２部コピーする旨の指示をしたとすると、「普通紙原稿を複合機１のＡＤＦ（自動原稿送り装置）にセット」する指示内容が入力仕様であり、「Ａ４の記録用紙に２部コピー」する指示内容が出力仕様である。なお、かかるユーザの要望３３０ｂは、ユーザの複合機１への指示により、いったん確定するが、再度の指示により変更することが可能であるものとする。
【０１２２】
設定（）３３０ｃは、許容仕様３３０ａおよびユーザの要望３３０ｂを、リクエスト仕様クラス３３０の属性として設定する処理をおこなう。参照（）３３０ｄは、属性として設定された、許容仕様３３０ａおよびユーザの要望３３０ｂを他のクラスからの要求により提供する処理をおこなう。なお、本実施の形態においては、リクエストクラス３２０とリクエスト仕様クラス３３０を別クラスとして構成したが、リクエストクラス３２０がリクエスト仕様クラス３３０の役割を兼ねることにより、リクエスト仕様クラス３３０を有しない構成とすることもできる。
【０１２３】
成果物クラス３４０は、出力されるべき成果物の進捗を管理するとともに、かかる成果物の実行処理をおこなうクラスである。具体的には、この成果物クラス３４０は、属性として、出力できるものの進捗３４０ａ、出力済みのものの進捗３４０ｂおよび実行状態３４０ｃを有し、操作として、作成（）３４０ｄを有する。なお、かかる成果物クラス３４０を実体化したオブジェクトが生成されると、出力できるものの進捗３４０ａ、出力済みのものの進捗３４０ｂおよび実行状態３４０ｃはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。
【０１２４】
出力できるものの進捗３４０ａは、複合機１に入力される入力物（たとえば、原稿）の進捗状況をあらわす。たとえば、ユーザが５０枚の紙原稿をこの複合機１にセットして、セットした紙原稿のコピーを指示するジョブ処理依頼をおこなった場合、かかる入力できるものの進捗３４０ａは、０／５０から５０／５０、あるいは０％から１００％までの値をとる。なお、かかる進捗値の増分は、原稿の種類や、原稿のデータ種別により異なることがあるものとする。
【０１２５】
出力済みのものの進捗３４０ｂは、複合機１から出力される成果物の進捗状況を保持する。たとえば、ユーザが２００枚の紙原稿をこの複合機１にセットして、セットした紙原稿のコピーを指示するジョブ処理依頼をおこなった場合、かかる出力済みのものの進捗３４０ｂは、０／２００から２００／２００、あるいは０％から１００％までの値をとる。
【０１２６】
なお、かかる進捗値の増分は、成果物の種類や、成果物のデータ種別により異なることがあるものとする。実行状態３４０ｃは、成果物を作成する作業の実行状態を保持する。具体的には、この実行状態３４０ｃは、成果物を作成する作業が実行中か、あるいは、発生した障害により実行が中断されているかなどの実行状態を保持する。作成（）３４０ｄは、成果物の作成開始を受け付ける処理をおこなう。
【０１２７】
成果物仕様クラス３５０は、成果物の詳細情報を保持するクラスであり、リクエスト仕様クラス３３０が保持するリクエストの詳細情報から、成果物を作成するうえで必要となる情報を抽出して保持するクラスである。具体的には、この成果物仕様クラス３５０は、属性として、入力の形態３５０ａ、出力の形態３５０ｂおよびユーザの要望３５０ｃを有する。なお、かかる成果物仕様クラス３５０を実体化したオブジェクトが生成されると、入力の形態３５０ａ、出力の形態３５０ｂおよびユーザの要望３５０ｃはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。
【０１２８】
入力の形態３５０ａは、複合機１に入力される原稿の形態を保持する。たとえば、この原稿の形態としては、ユーザがかかる複合機１にセットした紙原稿、かかる複合機１に内蔵された記憶装置に保持される蓄積原稿、ファックス受信原稿などがある。
【０１２９】
出力の形態３５０ｂは、複合機１から出力される成果物の形態を保持する。たとえば、かかる成果物の形態としては、紙に印刷される成果物、電子メールによりＷＡＮ（Wide Area Network）などをとおして送信される成果物、ファックス送信される成果物などがある。
【０１３０】
ユーザの要望３５０ｃは、ユーザが複合機１に対して指示した、成果物の仕上がりについての仕様である。たとえば、紙印刷される成果物の場合、Ａ４横、両面印刷、１枚あたりのページ数などの仕様がある。なお、本実施の形態においては、成果物クラス３４０と成果物仕様クラス３５０を別クラスとして構成したが、成果物クラス３４０クラスが成果物仕様クラス３５０の役割を兼ねることにより、成果物仕様クラス３５０を有しない構成とすることもできる。
【０１３１】
次に、図７に示した各クラス間の関係について説明する。同図に示したように、各クラスを示す矩形を結ぶ直線は、その両端のクラス間に関係があることを表しており、この直線の両端付近の文字はクラスの役割を、数字はクラスの多重度をそれぞれ示している。ここで、役割とは、かかる直線の両端における、一方のクラスからみた、もう一方のクラスの役割や立場のことであり、多重度とは、かかる直線の両端のクラスから生成されるオブジェクト数の対応関係のことである。
【０１３２】
たとえば、成果物クラス３４０からみたリクエストクラス３２０の役割は「監視者」であり、リクエストクラス３２０からみた成果物クラス３４０の役割は「監視対象」であり、リクエストクラス３２０の多重度は「１」であり、成果物クラス３４０の多重度は「１．．＊」である。ここで、「１．．＊」は、かかる成果物クラス３４０の多重度が、１から上限数なしの範囲であることを示している。また、たとえば、「１．．３」の記載をした場合には、かかるクラスの多重度が、１〜３の範囲であることを示す。
【０１３３】
まず、リクエストフォルダクラス３１０とリクエストクラス３２０とのクラス関係について説明する。リクエストフォルダクラス３１０は、リクエストクラス３２０からみると保管先としての役割を有しており、一方、リクエストクラス３２０は、リクエストフォルダクラス３１０からみると保管対象としての役割を有している。上述した「フォルダ−ファイル」モデルの例によれば、リクエストフォルダクラス３１０は、かかるモデルのフォルダに該当し、リクエストクラス３２０は、かかるモデルのファイルに該当する。
【０１３４】
そして、同図に示したように、リクエスト管理部１１３ａが実行される場面において、リクエストフォルダクラス３１０をＲＡＭ１２ｂ上に展開（実体化）したオブジェクトは１個だけ存在し、このリクエストフォルダクラス３１０の保管対象となるリクエストクラス３２０を実体化したオブジェクトは０個以上、上限数なしの範囲で存在する。
【０１３５】
なお、リクエストフォルダクラス３１０を実体化したオブジェクトを複数個とせずに１個としたのは、複合機１に投入される全リクエストを一括して管理するためである。また、リクエストクラス３２０を実体化したオブジェクト数が０個とは、実行中のリクエストが存在しない場合を示しており、また、かかるオブジェクト数の上限数は規定していないものの、当然に、ハードウェア仕様などによる制限を受けるものとする。
【０１３６】
次に、リクエストクラス３２０とリクエスト仕様クラス３３０との関係について説明する。リクエストクラス３２０は、リクエスト仕様クラス３３０からみると適用対象としての役割を有しており、一方、リクエスト仕様クラス３３０は、リクエストクラス３２０からみると、その詳細としての役割を有している。上述した「フォルダ−ファイル」モデルの例によれば、リクエストクラス３２０は、かかるモデルのファイルに該当し、リクエスト仕様クラス３３０は、かかるモデルのプロパティに該当する。
【０１３７】
すなわち、リクエスト仕様クラス３３０は、リクエストクラス３２０の詳細な仕様であり、この詳細な仕様を適用する対象は、リクエストクラス３２０であることを示している。そして、リクエスト管理部１１３ａが実行される場面において、リクエストクラス３２０を実体化したオブジェクトとリクエスト仕様クラス３３０を実体化したオブジェクトとは１対１の関係で存在する。たとえば、複合機１において１０個のリクエストが実行中である場合においては、リクエストクラス３２０を実体化したオブジェクトとリクエスト仕様クラス３３０を実体化したオブジェクトは、それぞれ１０個ずつ存在する。
【０１３８】
次に、リクエストクラス３２０と成果物クラス３４０との関係について説明する。リクエストクラス３２０は、成果物クラス３３０からみると監視者としての役割を有しており、一方、成果物クラス３４０は、リクエストクラス３２０からみると、監視対象としての役割を有している。そして、リクエスト管理部１１３ａが実行される場面において、リクエストクラス３２０を実体化したオブジェクト１個に対し、１個以上の成果物クラス３４０を実体化したオブジェクトが存在する。
【０１３９】
たとえば、ユーザが、複合機１に対して紙原稿５枚からなる入力原稿から１０部のコピーを指示するジョブ処理依頼をおこなった場合、かかる指示に対応するリクエストクラス３２０のオブジェクトは１個生成され、成果物クラス３４０のオブジェクトは１０個生成される。そして、リクエストクラス３２０のオブジェクトは、１０個の成果物クラス３４０のオブジェクトを監視して、１０個の成果物の完了、すなわち５枚×１０部のコピー出力をもって、リクエストの完了と判断する。
【０１４０】
次に、成果物クラス３４０と成果物仕様クラス３５０との関係について説明する。成果物クラス３４０は、成果物仕様クラス３５０からみると適用対象としての役割を有しており、一方、成果物仕様クラス３５０は、成果物クラス３４０からみると、その詳細としての役割を有している。上述した「フォルダ−ファイル」モデルの例によれば、成果物クラス３４０は、かかるモデルのファイルに該当し、成果物仕様クラス３５０は、かかるモデルのプロパティに該当する。
【０１４１】
すなわち、成果物仕様クラス３５０は、成果物クラス３４０の詳細な仕様であり、この詳細な仕様を適用する対象は、成果物クラス３４０であることを示している。そして、リクエスト管理部１１３ａが実行される場面において、成果物クラス３４０を実体化したオブジェクトと成果物仕様クラス３５０を実体化したオブジェクトとは１対１の関係で存在する。たとえば、複合機１において２０個の成果物が実行中である場合においては、成果物クラス３４０を実体化したオブジェクトと成果物仕様クラス３５０を実体化したオブジェクトは、それぞれ２０個ずつ存在する。
【０１４２】
次に、リクエスト仕様クラス３３０と成果物仕様クラス３５０との関係について説明する。リクエスト仕様クラス３３０は、成果物仕様クラス３５０からみると全体としての役割を有しており、一方、成果物仕様クラス３５０は、リクエスト仕様クラス３３０からみると部分としての役割を有している。そして、リクエスト管理部１１３ａが実行される場面において、リクエスト仕様クラス３３０を実体化したオブジェクト１個に対し、１個以上の成果物仕様クラス３５０を実体化したオブジェクトが存在する。
【０１４３】
たとえば、ユーザが、複合機１に対して紙原稿５枚からなる入力原稿から１０部のコピー処理を指示するジョブ処理依頼をおこなった場合、かかる指示に対応するリクエスト仕様クラス３３０のオブジェクトは１個生成され、成果物仕様クラス３５０のオブジェクトは１０個生成される。また、リクエスト仕様クラス３３０と成果物仕様クラス３５０を結ぶ直線の、リクエスト仕様クラス３３０側に記された白抜きのひし形は、集約、すなわち、あるクラスが別のクラスの一部として含まれる関係、を示している。具体的には、成果物仕様クラス３５０は、リクエスト仕様クラス３３０が保持するリクエストの詳細情報から、成果物を作成するうえで必要となる情報を抽出して保持するクラスであるため、リクエスト仕様クラス３３０の一部であり、リクエスト仕様クラス３３０に集約される関係を有する。
【０１４４】
次に、図７に示した、各クラスを実体化したオブジェクトの動作の概要について、図８、図９および図１０−１〜図１０−３を用いて説明する。図８は、複合機１の操作パネル４００の一例を示した図である。同図に示したように、かかる操作パネル４００は、初期設定キー４０１、コピーキー４０２、コピーサーバーキー４０３、プリンタキー４０４、送信キー４０５、テンキー４０６、クリア／ストップキー４０７、スタートキー４０８、予熱キー４０９、リセットキー４１０および液晶タッチパネル４２０を有する。
【０１４５】
初期設定キー４０１をタッチすると、液晶タッチパネル４２０に初期設定用のメニューが表示され、かかるメニューにおいては、収納される用紙サイズなどを設定することができる。また、コピーをしたい場合にはコピーキー４０２を、コピー結果を複合機１に蓄積したい場合にはコピーサーバーキー４０３を、プリンタに係る操作をおこないたい場合には、プリンタキー４０４を、ファックスや蓄積画像などの送信をしたい場合には送信キー４０５を、それぞれタッチすると、液晶タッチパネル４２０に対応したメニューが表示される。
【０１４６】
図９は、図８に示したコピーサーバーキー４０３をタッチすると、液晶タッチパネル４２０に表示されるメニューの一例である。図９に示すように、この液晶タッチパネル４２０には、原稿読み取りボタン４２１、リストから削除ボタン４２２、印刷条件ボタン４２３などのボタンと、蓄積文書の一覧が表示される。
【０１４７】
そして、原稿を蓄積したい場合には、原稿を所定の場所にセットしたうえで、原稿読み取りボタン４２１をタッチする。また、蓄積文書を削除したい場合には、たとえば、ユーザＩＤがＤＥＦの蓄積文書４２５をタッチし、かかる蓄積文書の表示を反転させたうえで、リストから削除ボタン４２２をタッチする。また、蓄積文書の印刷条件を変更したい場合には、たとえば、ユーザＩＤがＡＢＣの蓄積文書４２５をタッチし、かかる蓄積文書の表示を反転させたうえで、印刷条件ボタン４２３をタッチすると印刷条件メニューが表示される。
【０１４８】
かかるメニューにおいて印刷条件を変更することで、選択した蓄積文書４２５の印刷条件を変更することができる。なお、蓄積文書の数が多く表示エリア内に操作対象となる文書が表示されていない場合には、前へボタンおよび後へボタンをタッチすることで、操作対象となる文書を表示することができる。
【０１４９】
図１０−１〜図１０−３は、リクエストフォルダクラス３１０およびリクエストクラス３２０のオブジェクトと、オブジェクト間のメッセージの流れを表現したＵＭＬの協調（コラボレーション）図である。ここで、メッセージとは、オブジェクトが内部に有する操作の呼び出しのことであり、たとえば、オブジェクトＡがオブジェクトＢの操作Ｂ１を呼び出したときに、オブジェクトＡはオブジェクトＢにメッセージを送信した、ということができる。
【０１５０】
そして、あるオブジェクトが別のオブジェクトにメッセージを送信することにより、このメッセージを受信したオブジェクトは、内部の属性（データ）を変化させたり、かかるメッセージに対する応答を返信したり、他のメッセージを送信したりする。このようにして、各オブジェクトは協調して処理を進めていく。
【０１５１】
図１０−１は、リクエストフォルダクラス３１０のオブジェクトであるリクエストフォルダオブジェクト３１０Ａが、新規リクエストを受け付けた場合における、リクエストクラス３２０および成果物クラス３４０のオブジェクトと、オブジェクト間のメッセージの流れを示したＵＭＬコラボレーション図である。
【０１５２】
かかる新規リクエストは、たとえば、図９に示した原稿読み取りボタン４２１をタッチしたときに発生し、サービス層１０２のその他の制御部１０２ｇドライバーおよび操作系サブシステム１１１を経由してリクエストフォルダオブジェクト３１０Ａに到達する。なお、同図においては説明を解り易くするために、リクエスト仕様クラス３３０および成果物仕様クラス３５０を実体化したオブジェクトについての記載は省略している。
【０１５３】
まず、同図に付された各記号の説明をする。内部にアンダーラインを伴った文字列を有する矩形はオブジェクトを示し、アンダーラインを伴った文字列のうちコロン（：）を含むものは、コロンより前がオブジェクト名を、コロンより後ろが、かかるオブジェクトが属するクラスを示す。そして、矢印はオブジェクト間のメッセージを示し、この矢印の近辺に記された、たとえば、「１：リクエストオブジェクト生成」の文字列は、「１」が同図中におけるメッセージの相対的順序を示し、「リクエストオブジェクト生成」がかかるメッセージの内容を示す。また、各オブジェクトを結ぶ線は、各オブジェクトに関係があることを示しており、かかる線に沿って、たとえば、オブジェクト生成メッセージなどのメッセージの送受信がおこなわれる。
【０１５４】
同図に示したように、リクエストフォルダオブジェクト３１０Ａは、すでにコピーリクエストオブジェクト３２０ＢとＦＡＸ・蓄積リクエストオブジェクト３２０Ｃの２つのリクエストを受け付けており、このコピーリクエストオブジェクト３２０Ｂは、１つの実行中の成果物オブジェクト３４０Ｂを管理しており、かかるＦＡＸ・蓄積リクエストオブジェクト３２０Ｃは、２つの成果物オブジェクト、すなわち、待機中のＦＡＸ成果物オブジェクト３４０Ｃおよび待機中の蓄積成果物オブジェクト３４０Ｄを管理しているものとする。
【０１５５】
そして、リクエストフォルダオブジェクト３１０Ａは、新規にコピー・蓄積リクエストを受け付け、コピー・蓄積リクエストオブジェクト３２０Ｄを生成するとともに（ステップＳ１００１）、生成されたコピー・蓄積リクエストオブジェクト３２０Ｄは、２つの成果物オブジェクト、すなわち、待機中のコピー成果物オブジェクト３４０Ｅおよび待機中の蓄積成果物オブジェクト３４０Ｆを生成する（ステップＳ１００２）。
【０１５６】
図１０−２は、リクエストフォルダオブジェクト３１０Ａが、リクエスト一覧要求を受け付けた場合における、リクエストクラス３２０および成果物クラス３４０のオブジェクトと、オブジェクト間のメッセージの流れを示したＵＭＬコラボレーション図である。
【０１５７】
かかるリクエスト一覧要求は、たとえば、図８に示したコピーサーバーボタン４０３をタッチしたときに発生し、サービス層１０２のその他の制御部１０２ｇドライバーおよび操作系サブシステム１１１を経由してリクエストフォルダオブジェクト３１０Ａに到達する。
【０１５８】
同図に示すように、リクエストフォルダオブジェクト３１０Ａは、リクエスト一覧要求を受け付けると、管理する３つのオブジェクト、すなわち、コピーリクエストオブジェクト３２０Ｂ、ＦＡＸ・蓄積リクエストオブジェクト３２０Ｃ、およびコピー・蓄積リクエストオブジェクト３２０Ｄに要求状態の問合せメッセージを送信する（ステップＳ１００３）。
【０１５９】
そして、このメッセージを受信したコピーリクエストオブジェクト３２０Ｂは、管理する実行中の成果物オブジェクト３４０Ｂに実行状態の問合せメッセージを送信する（ステップＳ１００４）。そして、このメッセージを受信した実行中の成果物オブジェクト３４０Ｂは、成果物は実行中である旨の実行状態の回答メッセージを、コピーリクエストオブジェクト３２０Ｂに送信する。
【０１６０】
そして、この回答メッセージを受信したコピーリクエストオブジェクト３２０Ｂは、リクエスト要求状態の回答を、リクエストフォルダオブジェクト３１０Ａに送信する（ステップＳ１０１０）。
【０１６１】
また、リクエストフォルダオブジェクト３１０Ａが送信した要求状態の問合せメッセージ（ステップＳ１００３）を受信したＦＡＸ・蓄積リクエストオブジェクト３２０Ｃは、管理する２つのオブジェクト、すなわち、待機中のＦＡＸ成果物オブジェクト３４０Ｃおよび待機中の蓄積成果物オブジェクト３４０Ｄに実行状態の問合せメッセージを送信する（ステップＳ１００６）。
【０１６２】
そして、このメッセージを受信した待機中のＦＡＸ成果物オブジェクト３４０Ｃは、成果物は待機中である旨の実行状態の回答メッセージをＦＡＸ・蓄積リクエストオブジェクト３２０Ｃに送信し（ステップＳ１００７）、同様に、待機中の蓄積成果物オブジェクト３４０Ｄも、成果物は待機中である旨の実行状態の回答メッセージをＦＡＸ・蓄積リクエストオブジェクト３２０Ｃに送信する（ステップＳ１００７）。
【０１６３】
これら２つの回答メッセージを受信した、ＦＡＸ・蓄積リクエストオブジェクト３２０Ｃは、リクエスト要求状態の回答を、リクエストフォルダオブジェクト３１０Ａに送信する（ステップＳ１０１０）。
【０１６４】
また、リクエストフォルダオブジェクト３１０Ａが送信した要求状態の問合せメッセージ（ステップＳ１００３）を受信したコピー・蓄積リクエストオブジェクト３２０Ｄは、管理する２つのオブジェクト、すなわち、待機中のコピー成果物オブジェクト３４０Ｅおよび待機中の蓄積成果物オブジェクト３４０Ｆに実行状態の問合せメッセージを送信する（ステップＳ１００８）。
【０１６５】
そして、このメッセージを受信した待機中のコピー成果物オブジェクト３４０Ｅは、成果物は待機中である旨の実行状態の回答メッセージをコピー・蓄積リクエストオブジェクト３２０Ｄに送信し（ステップＳ１００９）、同様に、待機中の蓄積成果物オブジェクト３４０Ｆも、成果物は待機中である旨の実行状態の回答メッセージをコピー・蓄積リクエストオブジェクト３２０Ｄに送信する（ステップＳ１００９）。
【０１６６】
これら２つの回答メッセージを受信した、コピー・蓄積リクエストオブジェクト３２０Ｄは、リクエスト要求状態の回答を、リクエストフォルダオブジェクト３１０Ａに送信する（ステップＳ１０１０）。
【０１６７】
そして、リクエストフォルダオブジェクト３１０Ａは、要求状態の問合せメッセージを送信（ステップＳ１００３）した３つのオブジェクト、すなわち、コピーリクエストオブジェクト３２０Ｂ、ＦＡＸ・蓄積リクエストオブジェクト３２０Ｃおよびコピー・蓄積リクエストオブジェクト３２０Ｄのすべてから、要求状態の回答を受信（ステップＳ１０１０）すると、受信した回答をもとに、リクエスト一覧情報を作成し、リクエスト一覧要求をおこなった操作系サブシステム１１１に回答する。かかるリクエスト一覧情報は、サービス層１０２のその他の制御部１０２ｇを経由して、たとえば、図９に示したような文書一覧として、液晶タッチパネル４２０に表示される。
【０１６８】
図１０−３は、リクエストフォルダオブジェクト３１０Ａが、管理中であるＦＡＸ・蓄積リクエストの蓄積成果物の取消要求を受け付けた場合における、リクエストクラス３２０および成果物クラス３４０のオブジェクトと、オブジェクト間のメッセージの流れを示したＵＭＬコラボレーション図である。
【０１６９】
かかる取消要求は、たとえば、図９に示したリストから削除ボタン４２２をタッチしたときに発生し、サービス層１０２のその他の制御部１０２ｇドライバーおよび操作系サブシステム１１１を経由してリクエストフォルダオブジェクト３１０Ａに到達する。同図に示すように、リクエストフォルダオブジェクト３１０Ａは、かかる取消要求を受け付けると、該当するＦＡＸ・蓄積リクエストオブジェクト３２０Ｃに取消メッセージを送信する（ステップＳ１０１１）。
【０１７０】
そして、このメッセージを受信したＦＡＸ・蓄積リクエストオブジェクト３２０Ｃは、待機中の蓄積成果物オブジェクト３４０Ｄに取消メッセージを送信し（ステップＳ１０１２）、このメッセージを受信した待機中の蓄積成果物オブジェクト３４０Ｄは消滅する。
【０１７１】
このように、本実施形態の特徴部分であるリクエスト管理部１１３ａのクラスを実体化したオブジェクトは、図７に示したクラス間の関係に従い、関係するクラスを実体化したオブジェクト間でメッセージをやりとりすることにより、処理を進めていく。
【０１７２】
次に、本実施形態の特徴部分であるリクエスト管理部１１３ａの機能追加の容易性について説明する。図１１は、統合アプリケーション１１０に、プリンタ機能などの新規機能を追加する場合の概念を説明するための説明図である。
【０１７３】
同図に示すように、統合アプリケーション１１０は、楕円形で示したオブジェクトモデルの集合体として構成されており、各オブジェクトモデルは、統合アプリケーション１１０を構成する役割に相当する。この統合アプリケーション１１０に、プリンタ機能などの新規機能を追加する場合においては、まず、追加するプリンタ機能を、統合アプリケーション１１０を構成する各オブジェクトモデルに適合するよう分離する。そして、かかる分離部分を各オブジェクトモデルに反映させる。
【０１７４】
同図に示したサブクラス化によるクラス追加は、かかる反映方法の１つである。ここで、サブクラス化とは、上位クラスの属性および操作を継承して下位クラスを設計する手法であり、オブジェクト指向によるソフトウェア開発の利点の１つである。
【０１７５】
図１２は、統合アプリケーション１１０に、新規機能を追加する場合における、サブクラス化によるクラス追加の一例として、リクエストクラス３２０のサブクラス化を説明したＵＭＬクラス図による説明図である。
【０１７６】
同図に示すように、リクエストクラス３２０は、たとえば、スキャナリクエストクラスと、コピーリクエストクラスおよびファックスリクエストクラスを下位クラス（サブクラス）として有する、上位クラス（スーパークラス）である。
【０１７７】
そして、図１１に示した新規機能として、たとえば、プリンタ機能が追加されたとすると、リクエストクラス３２０へのかかる機能追加は、プリンタリクエストクラスの追加として表現することができる。具体的には、リクエストクラス３２０の属性である、要求状態３２０ａと、リクエストクラス３２０の操作である、実現（）３２０ｂを継承しつつ、必要な処理を追加・変更することにより、新たにプリンタリクエストクラスを設計する。
【０１７８】
次に、図１２に示した、プリンタリクエストクラスを実体化したオブジェクトが、リクエストフォルダクラス３１０により管理される様子を説明する。図１３−１〜図１３−３は、リクエストフォルダクラス３１０のオブジェクトが、リクエストクラス３２０のサブクラスを管理する様子を説明した説明図である。
【０１７９】
図７に示したように、リクエストフォルダクラス３１０とリクエストクラス３２０とは、保管先と保管対象の関係にあるが、リクエストフォルダクラス３１０の保管対象となるクラスは、少なくともリクエストクラス３２０の属性と操作を有する必要がある。言い換えれば、リクエストクラス３２０をサブクラス化したクラスであれば、リクエストフォルダクラス３１０は、保管対象とすることができる。
【０１８０】
たとえば、図１３−１に示すように、リクエストフォルダクラス３１０のオブジェクトは、リクエストクラスをサブクラス化したコピーリクエストクラスのオブジェクトであるＣＯＰＹ０１と、リクエストクラスをサブクラス化したファックスリクエストクラスのオブジェクトであるＦＡＸ０１およびＦＡＸ０２を管理することができる。
【０１８１】
上述したように、リクエストフォルダクラス３１０は、リクエストクラス３２０のサブクラスを管理することができるからである。そして、図１３−２に示すように、リクエストクラス３２０をサブクラス化してプリンタクラスを設計し、かかるクラスのオブジェクトとしてＰＲＮＴ０１を生成すれば、図１３−３に示すように、リクエストフォルダクラス３１０のオブジェクトは、ＰＲＮＴ０１を管理することができる。
【０１８２】
次に、本実施形態の特徴部分であるリクエスト管理部１１３ａにリクエストが投入された場合における、各クラスの処理および各クラスから生成されたオブジェクト間のメッセージの流れについて説明する。
【０１８３】
図１４は、図７に示した、リクエストフォルダクラス３１０、リクエストクラス３２０、リクエスト仕様クラス３３０、成果物クラス３４０および成果物仕様クラス３５０について、リクエスト投入時における、各操作がおこなう処理をＵＭＬのノートシンボルに記載したクラス図である。
【０１８４】
図１５は、図１４に示した各クラスを実体化したオブジェクトと、かかるオブジェクト間のメッセージの流れを時系列に表したＵＭＬのシーケンス図である。同図の上部に並べられた矩形は、各オブジェクトを示し、各オブジェクトから下方に伸びた破線は、各オブジェクトが生存していることを示す線（ライフライン）であり、同図の下方に向かって時間は流れるものとする。そして、かかる破線上の垂直方向に伸びる矩形は、各オブジェクトが実際に活動している期間（活性区間）を示す。
【０１８５】
図１５に示すように、ユーザが複合機１を操作して、リクエストを投入すると操作系サブシステム１１１は、許容仕様[ａ１]およびユーザの要望[ａ２]からなる動作設定情報[ａ]を所持する（ステップＳ１１０１）。そして、リクエスト仕様オブジェクト３３０Ａの生成（）を呼び出すことにより、リクエスト仕様オブジェクト３３０Ａを生成する（ステップＳ１１０２）。ここで、この生成（）は、すべてのオブジェクトが有する操作であり、この生成（）を呼び出すことにより各オブジェクトはＲＡＭ１２ｂ上に実体化される。
【０１８６】
つづいて、操作系サブシステム１１１は、リクエスト仕様オブジェクト３３０Ａの設定（）３３０ｃを呼び出すことにより（ステップＳ１１０３）、かかる操作系サブシステム１１１が所持する許容仕様[ａ１]およびユーザの要望[ａ２]を、リクエスト仕様オブジェクト３３０Ａの属性区画に含まれるデータ（属性）である許容仕様３３０ａおよびユーザの要望３３０ｂに設定する（ステップＳ１１０４）。
【０１８７】
そして、操作系サブシステム１１１は、設定（）３３０ｃの戻り値として、かかるリクエスト仕様オブジェクト３３０Ａを受けとる。そして、操作系サブシステム１１１は、かかるリクエスト仕様オブジェクト３３０Ａを引数として、リクエストフォルダオブジェクト３１０Ａのリクエスト投入（）３１０ｃを呼び出す（ステップＳ１１０５）。
【０１８８】
そして、リクエストフォルダオブジェクト３１０Ａは、リクエスト投入（）３１０ｃの引数として渡されたリクエスト仕様オブジェクト３３０Ａのリンク情報（ＲＡＭ１２ｂ上でオブジェクトが存在する記憶領域を示した情報）を保持する（ステップＳ１１０６）。かかるリンク情報を保持するのは、後に、このリンク情報をリクエストオブジェクト３２０Ａ、成果物オブジェクト３４０Ａおよび成果物仕様オブジェクト３５０Ａに引渡し、これらのオブジェクトからリクエスト仕様オブジェクト３３０Ａを参照できるようにするためである。
【０１８９】
そして、かかるリクエストフォルダオブジェクト３１０Ａは、自身の属性区画に含まれるデータ（属性）である受付状態３１０ａの値を参照して、リクエスト投入可否の判断をおこなう（ステップＳ１１０７）。そして、この受付状態３１０ａの値が受付可能である場合には、以後の処理に進み、かかる値が受付不可能である場合には、その旨を操作系サブシステム１１１に通知して処理を終了する。
【０１９０】
そして、このリクエストフォルダオブジェクト３１０Ａは、リクエストオブジェクト３２０Ａの生成（）を呼び出すことにより、リクエストオブジェクト３２０Ａを生成する（ステップＳ１１０８）。リクエストフォルダオブジェクト３１０Ａは、自身の属性区画に含まれるデータ（属性）である受付状態３１０ａの値が受付可能である場合には、リクエスト仕様オブジェクト３３０Ａのリンク情報を引数として、リクエストオブジェクト３２０Ａの実現（）３２０ｂを呼び出す（ステップＳ１１０９）。
【０１９１】
つづいて、リクエストオブジェクト３２０Ａは、実現（）３２０ｂの引数として渡されたリクエスト仕様オブジェクト３３０Ａのリンク情報を保持することにより、リクエスト仕様オブジェクト３３０Ａとの関連づけをおこない（ステップＳ１１１０）、リクエスト仕様オブジェクト３３０Ａの参照（）３３０ｄを呼び出すことで（ステップＳ１１１１）、この参照（）３３０ｄの戻り値として、リクエスト仕様オブジェクト３３０Ａの属性区画に含まれるデータ（属性）であるユーザの要望３３０ｂを取得する（ステップＳ１１１２）。
【０１９２】
そして、リクエストオブジェクト３２０Ａは、取得したユーザの要望３３０ｂに従い、必要な個数の成果物オブジェクト３４０Ａを生成する。具体的には、このリクエストオブジェクト３２０Ａは、成果物オブジェクト３４０Ａの生成（）を必要な回数呼び出すことで（ステップＳ１１１３）、必要な個数の成果物オブジェクト３４０Ａを生成する。
【０１９３】
つづいて、このリクエストオブジェクト３２０Ａは、ステップＳ１１０８において保持したリクエスト仕様オブジェクト３３０Ａのリンク情報を引数として、先に生成した成果物オブジェクト３４０Ａの作成（）３４０ｄを呼び出す（ステップＳ１１１４）。
【０１９４】
そして、成果物オブジェクト３４０Ａは、作成（）３４０ｄの引数として渡されたリクエスト仕様オブジェクト３３０Ａのリンク情報を引数として、成果物仕様オブジェクト３５０Ａの生成（）を呼び出す（ステップＳ１１１５）。なお、上述したように、この生成（）は、すべてのオブジェクトが有する操作である。そして、この成果物オブジェクト３４０Ａは、かかる生成（）の戻り値として、かかる成果物オブジェクト３４０Ａのリンク情報を取得することにより、成果物仕様との関連づけをおこなう（ステップＳ１１１６）。
【０１９５】
このように、リクエストオブジェクト３２０Ａは、先に生成されたリクエスト仕様オブジェクト３３０Ａのリンク情報を引き渡して、成果物オブジェクト３４０Ａおよび成果物仕様オブジェクト３５０Ａの生成を完了すると、実行制御部１１３ｂに文書操作開始の指示をおこなう（ステップＳ１１１７）。
【０１９６】
なお、上述した説明では、リクエスト仕様オブジェクト３３０Ａの生成および設定を、リクエストオブジェクト３２０Ａの生成に先がけておこない（ステップＳ１１０２およびＳ１１０３）、かかるリクエスト仕様オブジェクト３３０Ａのリンク情報を以降のオブジェクト間通信で受け渡す構成とした。しかしながら、これに限るものではなく、Ｓ１１１１の前までに、Ｓ１１０２およびＳ１１０３の処理をおこなえばよい。たとえば、Ｓ１１０２の処理は、リクエストオブジェクト３２０Ａの生成に先がけておこない、Ｓ１１０３の処理をＳ１１１１の処理の直前におこなうよう構成してもよいし、Ｓ１１０２およびＳ１１０３の処理をＳ１１１１の処理の直前におこなうよう構成してもよい。
【０１９７】
上述してきたように、本実施の形態では、オブジェクト指向設計により、オブジェクトモデルの集合体として統合アプリケーション１１０を構成し、かかるオブジェクトモデルのうち、リクエスト管理をおこなうものをリクエスト管理部１１３ａとし、このリクエスト管理部１１３ａは、いわゆる「フォルダ−ファイル」モデルのアナロジーとして、リクエストフォルダクラス３１０、リクエストクラス３２０、リクエスト仕様クラス３３０を有する構成とし、さらに、成果物クラス３４０および成果物仕様クラス３５０を有する構成としたので、ユーザのリクエストを一括して受け付けることができ、かかるリクエストの投入から成果物の出力までの管理を効率良くおこなうことができるとともに、新規機能の追加などにともなう労力を軽減することができる。
【０１９８】
なお、本実施の形態の画像形成装置で実行されるリクエスト管理プログラム（ジョブ処理指示プログラム）は、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（CD Recordable）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記録媒体に記録して提供するよう構成してもよい。この場合、ＣＰＵ１１が上記記憶媒体から、リクエスト管理プログラム（ジョブ処理指示プログラム）を読み出してＭＥＭ−Ｐ１２上にロードすることで、画像形成装置に、上述した各ステップ（工程）、各手段または各部を実現させる。
【０１９９】
また、リクエスト管理プログラム（ジョブ処理指示プログラム）を、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するよう構成してもよい。さらに、かかるリクエスト管理プログラム（ジョブ処理指示プログラム）をインターネットなどのネットワーク経由で提供または配布するようにしてもよい。
【産業上の利用可能性】
【０２００】
以上のように、本発明にかかるリクエスト管理装置、画像形成装置、ジョブ処理指示方法およびジョブ処理指示プログラムは、リクエスト管理に有用であり、特に、ジョブ処理依頼のリクエスト管理に適している。
【図面の簡単な説明】
【０２０１】
【図１】複合機をとりまくネットワーク環境を示すネットワーク図である。
【図２】複合機のハードウェアを説明するための説明図である。
【図３】複合機におけるハードウェアおよびソフトウェアの階層構造を説明するための説明図である。
【図４】統合アプリケーションの構成を説明するための説明図である。
【図５】統合アプリケーションの構成を表したＵＭＬクラス図である。
【図６−１】「ディレクトリ−ファイル」モデルを説明するための説明図である。
【図６−２】リクエスト管理部のモデリングの概要を説明するための説明図である。
【図７】リクエスト管理部のクラス構成を表したＵＭＬクラス図である。
【図８】複合機の操作パネルを説明するための説明図である。
【図９】液晶タッチパネルに表示されるメニュー例を説明するための説明図である。
【図１０−１】リクエスト管理部のクラスを実体化したオブジェクトのふるまい（新規リクエスト受付）を表したＵＭＬコラボレーション図である。
【図１０−２】リクエスト管理部のクラスを実体化したオブジェクトのふるまい（リクエスト一覧要求受付）を表したＵＭＬコラボレーション図である。
【図１０−３】リクエスト管理部のクラスを実体化したオブジェクトのふるまい（蓄積成果物取消）を表したＵＭＬコラボレーション図である。
【図１１】統合アプリケーションに新規機能を追加する場合の概念を説明するための説明図である。
【図１２】新規機能追加の例としてサブクラス化をおこなう場合を示したＵＭＬクラス図である。
【図１３−１】サブクラス化したクラスを実体化したオブジェクトのふるまい（新規クラス作成前）を説明したＵＭＬコラボレーション図である。
【図１３−２】サブクラス化したクラスを実体化したオブジェクトのふるまい（新規クラス作成）を説明したＵＭＬコラボレーション図である。
【図１３−３】サブクラス化したクラスを実体化したオブジェクトのふるまい（新規クラス作成後）を説明したＵＭＬコラボレーション図である。
【図１４】リクエスト投入時におけるリクエスト管理部のクラスの操作を説明したＵＭＬクラス図である。
【図１５】リクエスト投入時におけるオブジェクトのふるまい時系列に示したＵＭＬシーケンス図である。
【図１６】複合機に搭載されるソフトウェア構成の変遷を示す説明図である。
【図１７】従来の複合機におけるハードウェアおよびソフトウェアの階層構造を説明するための説明図である。
【符号の説明】
【０２０２】
１  画像形成装置（複合機）
１０  コントローラ
１１  ＣＰＵ
１２  ＭＥＭ−Ｐ
１２ａ  ＲＯＭ
１２ｂ  ＲＡＭ
１３  ＮＢ
１４  ＳＢ
１５  ＡＧＰ
１６  ＡＳＩＣ
１７  ＭＥＭ−Ｃ
１８  ＨＤＤ
２０  キーボード（オペレーションパネル）
３０  ＦＣＵ
４０  ＵＳＢ
５０  ＩＥＥＥ１３９４
６０  エンジン部（Engine）
１００  ソフトウェア
１０１  アプリケーション層
１０２  サービス層
１０２ａ  スキャナ制御部
１０２ｂ  プロッタ制御部
１０２ｃ  蓄積制御部
１０２ｄ  配信／メール送受信制御部
１０２ｅ  ＦＡＸ送受信制御部
１０２ｆ  ネットワーク通信制御部
１０２ｇ  その他の制御部
１０３  オペレーティングシステム
１１０  統合アプリケーション
１１１  操作系サブシステム
１１２  管理系サブシステム
１１３  実行系サブシステム
１１３ａ  リクエスト管理部
１１３ｂ  実行制御部
１２０  コピーアプリケーション
１３０  スキャナアプリケーション
１４０  ファックスアプリケーション
１５０  プリンタアプリケーション
２００  ハードウェア
２０１  ハードウェアリソース
２０１ａ  スキャナ
２０１ｂ  プロッタ
２０１ｃ  ＨＤＤ
２０１ｄ  ネットワーク
２０１ｅ  その他のリソース
３１０  リクエストフォルダクラス（リクエスト保管手段の一例）
３１０Ａ  リクエストフォルダオブジェクト（リクエスト保管手段の一例）
３１０ａ  受付状態
３１０ｂ  限界数
３１０ｃ  リクエスト投入（）
３２０  リクエストクラス（リクエスト手段の一例）
３２０Ａ  リクエストオブジェクト（リクエスト手段の一例）
３２０Ｂ  コピーリクエストオブジェクト（リクエスト手段の一例）
３２０Ｃ  ＦＡＸ・蓄積リクエストオブジェクト（リクエスト手段の一例）
３２０Ｄ  コピー・蓄積リクエストオブジェクト（リクエスト手段の一例）
３２０ａ  要求状態
３２０ｂ  実現（）
３３０  リクエスト仕様クラス（リクエスト仕様保持手段の一例）
３３０Ａ  リクエスト仕様オブジェクト（リクエスト仕様保持手段の一例）
３３０ａ  許容仕様
３３０ｂ  ユーザの要望
３３０ｃ  設定（）
３３０ｄ  参照（）
３４０  成果物クラス（成果物手段の一例）
３４０Ａ  成果物オブジェクト（成果物手段の一例）
３４０Ｂ  実行中の成果物オブジェクト（成果物手段の一例）
３４０Ｃ  待機中のＦＡＸ成果物オブジェクト（成果物手段の一例）
３４０Ｄ  待機中の蓄積成果物オブジェクト（成果物手段の一例）
３４０Ｅ  待機中のコピー成果物オブジェクト（成果物手段の一例）
３４０Ｆ  待機中の蓄積成果物オブジェクト（成果物手段の一例）
３４０ａ  出力できるものの進捗
３４０ｂ  出力済みのものの進捗
３４０ｃ  実行状態
３４０ｄ  作成（）
３５０  成果物仕様クラス（成果物仕様保持手段の一例）
３５０Ａ  成果物仕様オブジェクト（成果物仕様保持手段の一例）
３５０ａ  入力の形態
３５０ｂ  出力の形態
３５０ｃ  ユーザの要望
４００  操作パネル
４０１  初期設定キー
４０２  コピーキー
４０３  コピーサーバーキー
４０４  プリンタキー
４０５  送信キー
４０６  テンキー
４０７  クリア／ストップキー
４０８  スタートキー
４０９  予熱キー
４１０  リセットキー
４２０  タッチパネル
４２１  原稿読み取りボタン
４２２  リストから削除ボタン
４２３  印刷条件ボタン
４２４  文書リスト例１
４２５  文書リスト例２
５０１  サービス層分離前アプリケーション
５０２  サービス層分離後アプリケーション
５０３  共通ルーチン分離アプリケーション
５０４  オブジェクト指向アプリケーション
【図１】
2006059199.tif 000003
【図２】
2006059199.tif 000004
【図３】
2006059199.tif 000005
【図４】
2006059199.tif 000006
【図５】
2006059199.tif 000007
【図６−１】
2006059199.tif 000008
【図６−２】
2006059199.tif 000009
【図７】
2006059199.tif 000010
【図８】
2006059199.tif 000011
【図９】
2006059199.tif 000012
【図１０−１】
2006059199.tif 000013
【図１０−２】
2006059199.tif 000014
【図１０−３】
2006059199.tif 000015
【図１１】
2006059199.tif 000016
【図１２】
2006059199.tif 000017
【図１３−１】
2006059199.tif 000018
【図１３−２】
2006059199.tif 000019
【図１３−３】
2006059199.tif 000020
【図１４】
2006059199.tif 000021
【図１５】
2006059199.tif 000022
【図１６】
2006059199.tif 000023
【図１７】
2006059199.tif 000024