JP3225711B2 - ジョブ処理システムおよびジョブ処理実行装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ワークステーション等
の端末装置から送られた印刷文書等の一連の印刷要求に
対して、印刷出力処理等の処理を行う場合、該一連の印
刷要求等を１つのまとまり（１つのジョブ）として処理
するジョブ処理システムに関する。

【０００２】

【従来の技術】従来、プリントシステム等のネットワー
クシステムにおいて、ワークステーション等の端末装置
から送出される印刷要求は、１つの印刷文書データを処
理するため、あるユーザが同一のワークステーションか
ら連続して、印刷要求したとしても、同時に他人の印刷
要求が存在すれば、あるユーザが連続して送出した印刷
要求は、他人の印刷要求と混在してしまうため、このあ
るユーザが連続して送出した印刷要求に対する印刷出力
処理の結果は他人の印刷要求に対するものと混在したか
たちで出力され、このあるユーザは、出力処理結果を区
分するのに多大な時間を要していた。

【０００３】また、例えばプリントサーバ側で、ユーザ
から複数の文書データを受け付けたとしても、この複数
の文書データに対し、個々の文書毎に各種の指定を行う
ことはできなかった。

【０００４】さらに、ユーザ側が印刷要求で指定できる
のは、文書データに対するものか、プリントサーバ側に
インストールされているリソースに対するもののみであ
り、ユーザ側から任意に指定することはできなかった。

【０００５】また、ユーザが印刷要求して転送するデー
タは、その実体であるため、その実体のデータ量が大き
い場合、ネットワークに大きな負荷がかかり、効率的な
処理が阻害されることもあった。

【０００６】

【発明が解決しようとする課題】前述したように、従来
のプリントシステム等のネットワークシステムにおい
て、あるユーザがネットワークに接続されたプリンタ等
の出力装置に複数の処理要求を行う場合に、この処理要
求の処理中に出力装置が他のユーザからの処理要求を受
け付けた場合、あるユーザの処理要求に対する処理結果
に他のユーザの処理要求に対する処理結果が混在してし
まい、あるユーザは、自己の処理結果と他のユーザの処
理結果とを区分するのに多大な時間を要するという問題
点があった。

【０００７】また、たとえ出力装置が複数の処理要求を
受け付けることができても、ユーザはそれぞれの処理要
求に対する様々な指定およびその指定の削除を行うこと
ができなかった。さらに、ユーザが処理要求として指定
可能なのは、文書データか、出力装置にインストールさ
れているリソースのみであり、任意に指定することがが
できなかった。このため、柔軟性に欠けたシステムであ
るという問題点があった。

【０００８】さらに、ユーザが処理要求して転送するデ
ータは、その実体であるため、その実体のデータ量が大
きい場合、ネットワークに大きな負荷がかかり、効率的
な処理が阻害されるという問題点があった。

【０００９】そこで、本発明は、かかる問題点を除去
し、ユーザから各種の指定や参照データの転送を含む複
数の処理要求があった場合に、この複数の処理要求をま
とまりのあるものとして処理することができるジョブ処
理システムを提供することを目的とする。

【００１０】

【課題を解決するための手段】本発明は、複数の処理要
求を生成する端末装置と、該端末装置からネットワーク
を介して入力された処理要求を受け付け、該処理要求に
対応する変換、出力等の各種処理および実行をジョブを
単位として行うジョブ処理実行装置とを有したジョブ処
理システムにおいて、前記ジョブ処理実行装置は、前記
端末装置から識別子の付加されていない処理要求を受信
すると、当該処理要求に関連するジョブを新規に生成
し、該生成したジョブの識別子を前記端末装置に送信す
る手段と、前記識別子の付加された処理要求を受信する
と、該識別子に対応するジョブに該処理要求を振り分け
て格納する振り分け手段と、前記識別子とともに最後の
処理要求であることを示す情報の付加された処理要求を
受信すると、該識別子に対応するジョブに含まれる最後
の処理要求であると判断する判断手段と、前記ジョブ毎
にスケジューリングを行うスケジューラとを具備し、前
記端末装置は、前記複数の処理要求のうちの先頭の処理
要求を識別子を付加せずに送信し、前記ジョブ処理実行
装置にて前記先頭の処理要求に関連して生成されたジョ
ブの識別子を該ジョブ処理実行装置から受信し、該受信
した識別子を前記複数の処理要求に付加して送信し、さ
らに該複数の処理要求のうちの最後の処理要求に最後の
処理要求であることを示す情報を付加して送信する送信
処理手段を具備することを特徴とする。また、この発明
は、入力された処理要求を受け付け、該処理要求に対応
する処理制御を行うジョブ処理実行装置において、入力
された複数の処理要求が一連のまとまりとして処理する
ものと判断された場合には、前記複数の処理要求を一連
のまとまりとして入力された順に処理することを特徴と
する。

【００１１】

【作用】本発明では、前記端末装置が複数の処理要求を
行う場合、送信処理手段が、まず、該複数の処理要求の
うちの先頭の処理要求を識別子を付加しないで送信し、
前記ジョブ処理実行装置は、前記先頭の処理要求に関連
して新規にジョブを生成して該ジョブの識別子を前記端
末装置に返し、前記送信処理手段は、前記ジョブ処理実
行装置から返された前記先頭の処理要求に関連して生成
されたジョブの識別子を前記複数の処理要求に付加して
送信する。そして、処理要求を受信したジョブ処理実行
装置の振り分け手段は、前記識別子の付加された処理要
求を、該識別子に対応するジョブに振り分けて格納し、
判断手段が、前記識別子とともに最後の処理要求である
ことを示す情報の付加された処理要求を受信すると、該
識別子に対応するジョブに含まれる最後の処理要求であ
ると判断し、前記ジョブ毎に設定されたスケジューリン
グに基づいてジョブ単位の処理を行う。これにより、あ
る端末装置から複数の処理要求を行う場合に、ジョブ処
理装置は、ユーザの指定によりこの複数の処理要求に対
して１つのジョブを生成し、ジョブ毎に処理を行うの
で、この複数の処理要求は１つのジョブとして独立して
管理され、他のユーザの処理要求と混在することはない
ため、例えば、この複数の処理要求に対する出力処理結
果と他のユーザの処理要求に対する出力処理結果とが混
在することがなくなる。

【００１２】また、本発明のジョブ処理実行装置は、入
力された複数の処理要求が一連のまとまりとして処理す
るものと判断した場合には、この複数の処理要求を一連
のまとまりとして、入力された順に処理する。これによ
り、端末装置側では処理要求の処理順序を設定する必要
がなくなり、また、ジョブ処理実行装置側でも処理要求
を並べ替える必要がなくなるため、端末装置側およびジ
ョブ処理実行装置の双方にかかる負荷を小さくできる。

【００１３】

【実施例】以下、図面を参照して本発明の一実施例につ
いて説明する。

【００１４】図２は、本発明の一実施例の一部であるジ
ョブ処理実行装置の構成を示す図である。

【００１５】図２において、ジョブ処理実行装置は、ネ
ットワークＮに接続された複数のジョブ受付部１ａ〜１
ｃ、管理部２、管理入出力制御部２ａ、ジョブ制御部
３、複数のジョブ実行部４ａ〜４ｃ、ログファイル６、
アカウントファイル７、オブジェクト処理部８、オブジ
ェクトファイル９を有している。なお、複数のジョブ受
付部１ａ〜１ｃおよび複数のジョブ実行部４ａ〜４ｃ
は、それぞれまとめてジョブ受付部１およびジョブ実行
部４として呼称する。

【００１６】ジョブ制御部３は、ジョブ制御基本部１
０、イベント処理部１０ａ、ロギング処理部１０ｂ、ア
カウント処理部１０ｃ、およびオブジェクト管理部１０
ｄを有している。

【００１７】ジョブ受付部１は、ネットワークを介して
入力されたジョブを受け付け、それぞれ正規化を行って
ジョブ制御部３のジョブ制御基本部１０に供給する。こ
こで、正規化とは、各種フォーマットで送られてきたジ
ョブを、本システムが定めるジョブのフォーマットに統
一することをいう。なお、図２において、ジョブ受付部
１ａ〜１ｃは、３つの構成となっているが、これは複数
の一例であり、複数としたのは、送られてくる種々のジ
ョブフォーマットに対応できるようにするためである。

【００１８】管理部２は、システム管理者からの操作な
どを受け付けて、インターフェースである管理入出力制
御部２ａを介して、ジョブ制御部３に管理制御に関する
処理を依頼する。なお、図２において、管理部２は、管
理入出力制御部２ａとローカルに接続されているが、ネ
ットワーク例えばネットワークＮを介してリモートに接
続されてもよい。

【００１９】このようにして、ジョブ制御部３に対し
て、上述したジョブ受付部１および管理２からプリント
処理等のジョブあるいは管理のための制御依頼が入力さ
れることになる。

【００２０】ジョブ制御部３は、ジョブ受付部１、ある
いは管理入出力制御部２ａを介して管理部２から入力さ
れたジョブ等の内容を解析し、ジョブ実行部４に該ジョ
ブ等の処理を実行させる。

【００２１】ジョブ実行部４は、ジョブ処理部あるいは
ジョブ出力部のいづれかであり、ジョブ処理部は、文書
フォーマットの変換、イメージ処理、ノティファイ等の
処理を行い、ジョブ出力部は、ジョブの出力すなわち出
力媒体への記録、もしくはリダイレクトを実行する。な
お、ジョブ制御部３からジョブ実行部４に対する実行指
示は、ジョブの内容により、１回とは限らず必要な回数
の実行指示が繰り返される。また、リダイレクトとは、
このジョブ実行処理装置内のジョブ実行部４では処理で
きない場合や該当するジョブ実行部４が稼動していない
場合に、ネットワークＮに接続された他のジョブ実行処
理装置のジョブ実行部にこのジョブを転送することをい
う。

【００２２】イベント処理部１０ａは、ジョブ制御部３
から通知された各種イベントを管理入出力制御部２ａを
介して管理部２にイベント通知を行う。また、ロギング
処理部１０ｂを介して、その履歴をログファイル６に記
憶する。

【００２３】アカウント処理部１０ｃは、ジョブに関す
るアカウント情報（課金情報）を、オブジェクト処理部
８、オブジェクト管理部１０ｄを介してオブジェクトフ
ァイル９から収集して、アカウントファイル７に記憶す
る。

【００２４】オブジェクト管理部１０ｄは、ジョブ制御
部３内で使用する各種オブジェクトを、メモリ１０ｅま
たはオブジェクト処理部８を使用してオブジェクトファ
イル９に書き込んだり、読み出したりする。なお、この
オブジェクトのオブジェクトクラスとしては、ジョブ以
外にジョブ管理、各ジョブ処理、各ジョブ出力などのク
ラスがあげられる。

【００２５】オブジェクト処理部８は、各種のオブジェ
クトをアトリビュート（属性）とバリュー（値）として
オブジェクトファイル９に格納し、あるいは取り出しを
行う。ジョブ実行部４は、このオブジェクト処理部８に
アクセスして、ジョブ制御部３から依頼されたジョブの
アトリビュートを取り出してそれぞれの処理等の実行を
行う。

【００２６】図１は、ジョブ制御基本部１０の構成を示
す図である。

【００２７】図１において、ジョブ制御基本部１０は、
さらに要求制御部１１、ジョブスケジュール部１２、ジ
ョブ実行部制御部１３、キュー管理部１４から構成され
る。そして、ジョブ受付部１、または管理入出力制御部
２ａを介した管理部２との間の処理は、要求制御部１１
が行い、ジョブ実行部４との間の処理は、ジョブ実行部
制御部１３が行う。

【００２８】要求制御部１１は、ジョブ受付部１、また
は管理入出力制御部２ａを介した管理部２からのジョブ
要求を受け付け、オブジェクト管理部１０ｄを用いてジ
ョブオブジェクトを作成して、ジョブスケジュール部１
２に処理を依頼する。

【００２９】そして、要求制御部１１は、ジョブスケジ
ュール部１２またはジョブ実行部制御部１３に処理を依
頼すると、その処理の依頼が完了するまで待ち合わせる
という、「完了復帰」の処理制御を行う。

【００３０】ジョブスケジュール部１２は、オブジェク
ト管理部１０ｄから該当するジョブおよび関連するジョ
ブ実行部４のオブジェクトを取り出し、ジョブのスケジ
ューリングを行い、キュー管理部１４を用いて、ジョブ
実行部４にそれぞれ対応する専用のキューを作成等のジ
ョブのキューイングを行う。要求制御部１１に制御を戻
す。

【００３１】また、ジョブスケジュール部１２は、ジョ
ブ実行部制御部１３を介して、ジョブ実行部４に対して
ジョブの処理依頼を行う。なお、キューイングの実行
は、ジョブスケジュール部１２の指示によりキュー管理
部１４が実行する。

【００３２】ジョブ実行部制御部１３は、要求制御部１
１またはジョブスケジュール部１２からの処理要求を、
ジョブ実行部４に渡す。

【００３３】ここで、ジョブスケジュール部１２および
ジョブ実行部制御部１３は、関連する他の処理部に処理
を依頼するだけで、処理の完了を待たずに次の処理の依
頼を待ち合わせるという、「即時復帰」の処理制御を行
う。なお、処理の完了は、処理の依頼と同じようにし
て、処理の依頼元に終了を通知する。

【００３４】なお、要求制御部１１およびジョブスケジ
ュール部１２は、それぞれ、ジョブの受け付けに対応し
て、複数の要求処理部２０−１〜２０−ｎ、複数の処理
部３０−１〜３０−ｎ、複数の別処理部４０−１〜４０
−ｎを生成して並列処理を効率的に行う。

【００３５】次に、ジョブ受付部１に入力された処理要
求が複数の印刷文書を含む印刷処理要求である場合のジ
ョブ処理実行装置の処理を説明する。

【００３６】まず、要求制御部１１の処理について説明
する。

【００３７】ネットワークＮを介して図示しない端末装
置からの印刷処理要求は、ジョブ処理実行装置のジョブ
受付部１に入力される。印刷処理要求はジョブ受付部１
で正規化され、ジョブ制御部３の要求制御部１１に入力
される。

【００３８】図３は、要求制御部１１の詳細構成を示す
図である。

【００３９】図３において、要求制御部１１の要求受付
／生成部１１ａが印刷処理要求を受け付けると、新たな
要求処理部２０−３を生成する。この場合、２つのジョ
ブ処理要求が滞留しており、２つの要求処理部２０−
１，２０−２が既に生成されている。

【００４０】要求処理部２０−３において、要求解析部
２１は、この印刷要求内にジョブＩＤが設定されている
か否かをチェックする。ここで、要求解析部２１は、ジ
ョブＩＤが設定されていなければ、すなわちヌルポイン
タであれば、新規のジョブ要求と判断し、ユーザが設定
したジョブに関する情報と印刷文書に関する各種指定情
報である属性情報のチェックを行う。そして、属性情報
内にユーザによる設定時のエラーがある場合は、その
旨、ユーザに通知する。

【００４１】この後、ジョブ情報生成部２２はジョブ属
性情報を、またドキュメント情報生成部２３は印刷文書
属性情報を、オブジェクト管理部１０ｄを用いて作成す
る。この際、ジョブＩＤおよび印刷文書データ番号が付
与される。そして、要求処理部２０−３は、ジョブスケ
ジュール部１２にこの印刷要求を依頼する。

【００４２】そして、要求処理部２０−３は、ジョブス
ケジュール部１２からの応答を待ち、応答を受けたなら
ば、ユーザに新規に付与されたジョブＩＤを復帰情報と
して返す。

【００４３】なお、ユーザは、以降のこのジョブ、すな
わち印刷要求に対する問合せや、引き続く印刷文書の要
求時に、この付与されたジョブＩＤ（継続識別子）を設
定して使用する。

【００４４】すなわち、このジョブＩＤが設定される
と、既に受け付けたジョブ内の印刷文書データであると
判断し、印刷文書の各種指定に対しての属性チェックを
行い、ジョブ生成部でのジョブの生成は行わずに、直接
（Ｌ２０）、ドキュメント情報生成部２３において、印
刷文書属性情報のみを作成する。そして、印刷文書デー
タ番号が付与され、ジョブスケジュール部１２に印刷依
頼を行う。その後、ジョブスケジュール部１２から印刷
依頼に対する応答を受け、ユーザのジョブＩＤを復帰情
報として返す。

【００４５】そして、ジョブの終了は、ユーザからの印
刷要求時にこの印刷文書データが最後である旨の指定情
報を設定することにより判断される。

【００４６】ここで、印刷要求は、ヘッダ部とデータ部
で構成され、このヘッダ部内には、識別子の有無あるい
は識別子がある場合の該識別子のデータ部内の位置を示
すポインタを示す領域がある。最初の印刷要求の場合に
は、このヘッダ部内の所定位置に識別子がないことを示
すヌルポインタが設定される。例えば、ヘッダ部内の該
所定位置の情報ビット全てを「０」としたり、または全
てを「１」とするようにしている。また、２番目以降の
印刷要求時には、最初の印刷要求に対する応答からジョ
ブＩＤの通知を受けているので、このジョブＩＤを継続
識別子として、ヘッダ部の該所定位置に該ジョブＩＤが
格納されている位置を示すポインタを付けて、一連の処
理要求であることを示して他の処理要求と区別するよう
にしている。

【００４７】次に、ジョブスケジュール部１２の処理に
ついて説明する。

【００４８】図４および図５は、ジョブスケジュール部
１２の詳細構成を示す図である。

【００４９】まず、図４において、要求制御部１１から
要求／通知受付部１２ａを介して印刷要求を受けると、
処理部３０−３は、ジョブの状態を判定し、この状態に
該当するキューへのキューイングのキュー管理をキュー
管理部１４に依頼し、このキューイングの完了をキュー
管理部１４から受けると、要求制御部１１に応答を返
す。

【００５０】このキューイング時には、必ずジョブＩＤ
と印刷文書データ番号とを指定して、同一ジョブ内にキ
ューイングされるようにする。

【００５１】要求制御部１１への応答を返した後、処理
部３０−３は、キューイングしたジョブのスケジュール
属性をチェックする。このスケジュール属性は、大きく
次の２つの種類がある。すなわち、 （１）「全ての印刷文書を受信した後、処理を行う」と
いう属性 （２）「印刷文書データを受信する毎に処理を行う」と
いう属性 がある。

【００５２】（１）の属性の場合は、上述した最後であ
る旨の指定情報をもとにドキュメントの終了を判断し、
ドキュメントの終了前であれば、次の処理要求を待ち、
ドキュメントの終了であれば、印刷に必要な前処理を行
う。また、（２）の属性の場合は、直ちに印刷に必要な
前処理を行う。

【００５３】ここで、前処理とは、最終的にジョブを印
刷できる状態にもっていく処理のことであり、具体的に
は、プリンタ等の出力装置の選択処理や、出力データフ
ァイル転送処理や、適正なページ記述言語等への変換処
理をいう。

【００５４】次に、この前処理について説明する。

【００５５】上述した出力装置の選択処理や出力データ
ファイル転送処理等の前処理の処理順序については、様
々考えられるが、ここでは出力装置の選択処理を先に行
うものとする。また、出力装置の選択処理方法も様々考
えられるが、ここではユーザが指定した出力装置名例え
ばプリンタ名をもとに選択が決定されるものとする。

【００５６】さて、前処理は、まず印刷前処理３１によ
って行われる。すなわち、印刷前処理部３１の印刷文書
種別判定部３１ａは、ユーザから指定された印刷文書の
属性から実体データか参照データか否かを判定する。こ
の実体データとは、印刷文書本体そのもののデータ、あ
るいはフォームやロゴ等に関するリソースデータそのも
ののデータであり、参照データとは、転送されることが
要求される印刷文書の格納場所等を指定する参照用のデ
ータあるいはリソースデータの格納場所等を指定する参
照用のデータである。

【００５７】さて、印刷文書種別判定部３１ａが実体デ
ータであると判定した場合は、出力装置選択部におい
て、プリンタ名をもとにプリンタ等の出力装置を選択す
る。そして、この選択した出力装置にそのまま出力可能
な印刷文書形式であれば、選択した出力装置の専用のキ
ューにキューイングされ、出力装置とするジョブ実行部
４への出力処理を待つ。

【００５８】一方、選択した出力装置にそのまま出力可
能な印刷文書形式でなければ、印刷文書データ第１準備
部３１ｃは、選択された出力装置に出力可能な印刷文書
形式に変換処理を行うジョブ実行部４すなわちコンバー
タに処理依頼を行う。その後、コンバータとしてのジョ
ブ実行部４から変換処理の完了通知を受けると、別処理
部４０−３内の印刷前処理部４０において、印刷文書デ
ータ第２準備部４０ａは、出力装置選択部３１ｂで選択
された出力装置の専用のキューにキューイングされ、こ
の出力装置としてのジョブ実行部４への出力処理を待
つ。なお、ジョブスケジュール部１２は、印刷文書デー
タ第１準備部３１ｃから変換処理を依頼した後、該依頼
先からの変換処理完了通知を受けるまでの間、他のジョ
ブのスケジューリングを行う。

【００５９】一方、印刷文書種別判定部３１ａが参照デ
ータであると判定した場合、印刷文書データ第１準備部
３１ｃは、ジョブの属性内の転送方法の指定をもとに、
前処理を行う。この転送方法はユーザにより指定され、
ジョブ処理実行装置から、指定されたデータファイルの
格納されている装置へアクセスしてファイルをリトリー
ブする方法と、ジョブ処理実行装置からデータファイル
の格納場所を示す参照データをユーザに送り、ユーザが
示された格納場所に書き込む方法の２種類がある。

【００６０】以下、前者のリトリーブする転送方法が指
定された場合について説明すると、まず、参照データを
もとに、印刷文書データ第１準備部３１ｃは、出力デー
タファイル転送用のジョブ実行部４すなわちトランスフ
ァに、指定されたデータファイルの格納されている装置
へのアクセスを要求する。そして、ジョブスケジュール
部１２は、トランスファとしてのジョブ実行部４からの
ファイルの転送完了通知を受けると、別処理部４０−３
内の印刷前処理部４０において、印刷文書データ第２準
備部４０ａは、出力装置選択部３１ｂが選択した出力装
置にそのまま出力可能な印刷文書形式か否かを判定し、
印刷文書形式の変換処理が不要であれば、選択した出力
装置の専用のキューにキューイングを行い、選択した出
力装置としてのジョブ実行部４の出力処理を待つ。

【００６１】一方、変換が必要な場合は、選択した出力
装置にそのまま出力可能な印刷文書形式に変換する処理
をジョブ実行部４に依頼する。この変換処理もコンバー
タとしてのジョブ実行部４に処理を依頼する。そして、
コンバータとしてのジョブ実行部４から変換処理完了の
通知を受けると、印刷文書データ第２準備部４０ａは、
選択した出力装置の専用のキューにキューイングし、こ
の出力装置としてのジョブ実行部への出力処理を待つ。

【００６２】なお、印刷文書データ第２準備部４０ａか
ら各種処理をジョブ実行部４に処理を依頼した後、該ジ
ョブ実行部４からの処理完了通知を受けるまでの間、ジ
ョブスケジュール部１２は、他のジョブのスケジューリ
ングを行う。

【００６３】さて、上述した前処理が終了すると、選択
されたプリンタ等の出力装置としてのジョブ実行部４に
処理要求の送信をジョブ実行部制御部１３を介して行
う。ここで、処理要求の送信単位は、ジョブ単位でなく
印刷文書データ単位で行う。なお、この印刷文書データ
のタイプは、印刷文書データだけでなく、各種のリソー
スデータも取り扱うことができるが、この取扱いの可否
は、それぞれのジョブ実行部４の処理に依存する。ジョ
ブスケジュール部１２においては、この印刷文書データ
のタイプにかかわらず、それぞれのジョブ実行部４に送
信する。そして、この送信のタイミングは、それぞれの
ジョブ実行部４に共通したジョブ実行部４からの処理可
能通知、例えばプリンタレディ等を受けたタイミングで
ある。なお、最初のジョブ実行部４への処理要求におい
ては、必ずしも送信タイミングが一致するとは限らない
ので、それぞれのジョブ実行部４の処理状態を記憶して
おき、処理可能な状態のときに送信するようにしてい
る。

【００６４】そして、図５において、ジョブスケジュー
ル部１２が、それぞれのジョブ実行部４から印刷文書デ
ータ単位の処理の終了通知を受けると、その印刷文書デ
ータ単位の処理の終了が単なる印刷文書データ単位の処
理の終了か、あるいはジョブとしての終了かを別処理部
４０−３内の印刷終了通知処理部４１のジョブ終了判断
部４１ａが判断する。そして、この判断結果に基づい
て、単なる印刷文書データ単位の処理の終了である場合
は、文書終了処理部４１ｃにより、次の印刷文書データ
の出力処理を行い、ジョブの終了である場合は、ジョブ
終了処理部４１ｂがジョブが終了したことをイベント処
理部１０ａを介して通知する。

【００６５】なお、このようにして印刷処理された印刷
文書データそのものに対して、ユーザは印刷処理後の保
存期間を指定することができるため、この保存期間の設
定によっては、この印刷文書データのそれぞれは即座に
削除されるかもしれないが、リソースデータに関して
は、そのジョブ内の全ての印刷文書データの出力処理が
終了するまで、ユーザの保存期間の指定にかかわらず、
残存することになる。

【００６６】また、ユーザによって１つのジョブ内で指
定した各種リソースデータが、他のジョブへ影響を与え
ないようにするために、ジョブスケジュール部１２は、
ジョブとして終了したときに、ジョブ実行部４に対して
リソースデータの指定をデフォルトの設定に戻すための
要求を発行する。

【００６７】さらに、印刷要求の出力処理が終了した後
も、印刷文書データそのものではなく、そのジョブの属
性情報は、ある一定期間保存されることになる。

【００６８】また、上述した１つのジョブ内の複数の印
刷文書の属性情報が共通する場合は、１つの共通する属
性情報のみを送ればよい。

【００６９】このようにして、本実施例においては、複
数の印刷文書を１つのジョブとして管理するようにして
いるので、複数の印刷文書の処理要求中に他のユーザか
ら印刷要求のあった印刷文書が混合することなく、複数
の印刷文書がまとまって出力されることになる。

【００７０】

【発明の効果】以上説明したように、本発明では、前記
端末装置が複数の処理要求を行う場合、送信処理手段
が、まず、該複数の処理要求のうちの先頭の処理要求を
識別子を付加しないで送信し、前記ジョブ処理実行装置
は、前記先頭の処理要求に関連して新規にジョブを生成
して該ジョブの識別子を前記端末装置に返し、前記送信
処理手段は、前記ジョブ処理実行装置から返された前記
先頭の処理要求に関連して生成されたジョブの識別子を
前記複数の処理要求に付加して、該複数の処理要求の送
信処理を行う。そして、この処理要求を受信したジョブ
処理実行装置の振り分け手段が、前記識別子の付加され
た処理要求を、該識別子に対応するジョブに振り分けて
格納し、判断手段が、前記識別子とともに最後の処理要
求であることを示す情報の付加された処理要求を受信す
ると、該識別子に対応するジョブに含まれる最後の処理
要求であると判断し、前記ジョブ毎に設定されたスケジ
ューリングに基づいてジョブ単位の処理を行うようにし
ている。これにより、ある端末装置から複数の処理要求
を行う場合に、ユーザの指定により、この複数の処理要
求と他のユーザからの処理要求とをそれぞれ独立したジ
ョブとして管理し、処理を行うので、例えば、この複数
の処理要求に対する出力処理結果と他のユーザの処理要
求に対する出力処理結果とが混在することがなくなる
り、出力処理結果の区分にかかる時間を削減することが
できるという利点を有する。

【００７１】また、本発明では、入力された複数の処理
要求が一連のまとまりとして処理するものと判断された
場合には、この複数の処理要求を一連のまとまりとして
入力された順に処理する。これにより、複数の処理要求
を一連のまとまりとして処理するにあたって、当該一連
のまとまりの中では、処理要求の処理順序の設定および
並べ替えの必要がないため、端末装置側およびジョブ処
理実行装置にかかる負荷が小さくなるという利点を有す
る。

【００７２】また、この複数の処理要求はそれぞれ独立
した処理要求である場合は、それぞれ独立の処理要求と
同様な処理が行われ、同一処理を行う複数の処理要求で
ある場合は、複数の処理要求に共通な属性情報の送出は
個々に送出する必要はなく、１回の送出でよいため、ユ
ーザおよびネットワークに負担のかからない効率的な通
信処理が行えるという利点を有する。

【００７３】さらに、この処理要求は、転送、変換等の
各種処理が可能であるので、柔軟なジョブ処理が可能で
あり、プリント、複写時におけるフィニッシング処理等
の処理をさらに指定することにより、製本等の工数が省
け、ユーザにとって総合的に効率的な処理を行うことが
できるという利点を有する。

【００７４】また、処理要求は、実体データのみでなく
参照データとする指定を行うことができので、ネットワ
ークに負荷がかからない効率的なシステムが構築される
という利点を有する。

【図面の簡単な説明】

【図１】ジョブ制御基本部１０の構成を示す図。

【図２】本発明の一実施例の一部であるジョブ処理実行
装置の構成を示す図。

【図３】要求制御部１１の詳細構成を示す図。

【図４】ジョブスケジュール部１２の詳細構成を示す図
（その１）。

【図５】ジョブスケジュール部１２の詳細構成を示す図
（その２）。

【符号の説明】

１，１ａ〜１ｃ ジョブ受付部 ２ 管理部 ２ａ 管
理入力制御部 ３ ジョブ制御部 ４，４ａ〜４ｃ ジョブ実行部 ６
ログファイル ７ アカウントファイル ８ オブジェクト処理部 ９ オブジェクトファイル １０ ジョブ制御基本部 １０ａ イベント処理部 １０ｂ ロギング処理部 １０ｃ アカウント処理部 １０ｄ オブジェクト管理
部 １１ 要求制御部 １２ ジョブスケジュール部 １３ ジョブ実行部制御部 １４ キュー管理部 ２０−１〜２０−ｎ 要求処理部 ３０−１〜３０−ｎ
処理部 ４０−１〜４０−ｎ 別処理部 Ｎ ネットワーク

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】 複数の処理要求を生成する端末装置と、
   該端末装置からネットワークを介して入力された処理要
   求を受け付け、該処理要求に対応する変換、出力等の各
   種処理および実行をジョブを単位として行うジョブ処理
   実行装置とを有したジョブ処理システムにおいて、 前記ジョブ処理実行装置は、 前記端末装置から識別子の付加されていない処理要求を
   受信すると、当該処理要求に関連するジョブを新規に生
   成し、該生成したジョブの識別子を前記端末装置に送信
   する手段と、 前記識別子の付加された処理要求を受信すると、該識別
   子に対応するジョブに該処理要求を振り分けて格納する
   振り分け手段と、 前記識別子とともに最後の処理要求であることを示す情
   報の付加された処理要求を受信すると、該識別子に対応
   するジョブに含まれる最後の処理要求であると判断する
   判断手段と、 前記ジョブ毎にスケジューリングを行うスケジューラと
   を具備し、 前記端末装置は、 前記複数の処理要求のうちの先頭の処理要求を識別子を
   付加せずに送信し、前記ジョブ処理実行装置にて前記先
   頭の処理要求に関連して生成されたジョブの識別子を該
   ジョブ処理実行装置から受信し、該受信した識別子を前
   記複数の処理要求に付加して送信し、さらに該複数の処
   理要求のうちの最後の処理要求に最後の処理要求である
   ことを示す情報を付加して送信する送信処理手段を具備
   することを特徴とするジョブ処理システム。
2. 【請求項２】 入力された処理要求を受け付け、該処理
   要求に対応する処理制御を行うジョブ処理実行装置にお
   いて、 入力された複数の処理要求が一連のまとまりとして処理
   するものと判断された場合には、前記複数の処理要求を
   一連のまとまりとして入力された順に処理することを特
   徴とするジョブ処理実行装置。