JP4121006B2

JP4121006B2 - Printing system

Info

Publication number: JP4121006B2
Application number: JP2000353484A
Authority: JP
Inventors: 岳彦森田
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2000-04-24
Filing date: 2000-11-20
Publication date: 2008-07-16
Anticipated expiration: 2020-11-20
Also published as: JP2002014791A

Description

【０００１】
【発明の属する技術分野】
本発明は、クライアントから送信された印刷データが、ネットワークを経由して、印刷サーバあるいは印刷装置に受信、処理され、印刷される印刷システムに関し、特に、各モジュールの印刷ジョブの履歴を取得、管理する印刷システムに関する。
【０００２】
【従来の技術】
ネットワークを経由して複数のクライアント装置からデータを送信し、ネットワークに接続される印刷装置あるいは印刷サーバにより送信されたデータを受信して処理し、印刷を行う印刷システムが実用化されている。
【０００３】
上記印刷システムにおいて、「印刷ジョブの履歴」を取得する方法として、例えばクライアント上の印刷ドライバが生成するジョブの情報を印刷ドライバ自体がデータとして保管する技術、印刷サーバがサービスする印刷ジョブの情報を印刷サーバ自体が保管する技術、および印刷装置が印刷するジョブの情報を印刷装置自体が保管するという技術が知られている。
【０００４】
このような従来技術として、特開平１０−２８３１３１号公報には、印刷履歴情報をプリンタ内の記憶媒体に蓄積し、蓄積された印刷履歴情報を印刷したり、ホストコンピュータに送信したりすることによってユーザに表示する技術が提案されている。
【０００５】
【発明が解決しようとする課題】
本来、印刷ジョブは、ジョブの生成箇所「クライアント」から始まり、印刷サーバ等を経由し、最終的に印刷装置に到達して印刷データが印刷され、処理が終了するという、一連のパスを通る。
【０００６】
しかしながら、上記従来技術において、各印刷ドライバ、印刷サーバおよび印刷装置は、通過するパスの中のただ１点において、その点（場所）で採取し得る印刷ジョブ情報を保管するのみに限られていた。
【０００７】
例えば印刷ドライバは、ジョブの開始点であるクライアント上に存在するため、ジョブを要求したユーザ名や印刷を行ったアプリケーション名など、「ジョブの開始点」に関する情報は詳細に採取できる。しかしながら、最終的に何枚出力されたかなどの「ジョブの終了点」に関する情報や、印刷サーバが行う予定の印刷付加価値ジョブスケジューリングに関する情報を保管することができない。
【０００８】
また印刷サーバは、印刷サーバ上のジョブスケジュールリング、分散印刷、正常に動作しない印刷装置回避による別の印刷装置への出力等、印刷サーバがサービスする情報に関しては詳細に採取可能である。しかしながら、印刷サーバは、ジョブ開始点や終了点に関する情報を保管できない。
【０００９】
さらに印刷装置は、実際に出力された枚数など、ジョブの終了点に関する情報は詳細に採取できるが、要求者などの開始点の情報や、サーバによる印刷付加価値情報などは保管できない。
【００１０】
印刷ジョブは開始点からサービス点を通過して、終了点に到達するが、その間の各点で取得し得る印刷ジョブ情報は異なっており、従来技術によって生成されるジョブ履歴情報は、このパス上のいずれか一点のジョブ情報に偏っているという問題点があった。
【００１１】
また、ジョブ履歴は、課金、負荷分析など様々な用途で用いられる。必要なジョブ情報は用途によって異なっており、場合によってジョブのパス上での全情報が必要になる場合もある。上記されたような問題点があると、ジョブ情報を使用する上で不便な場合があった。
【００１２】
本発明は、上記問題点に鑑みてなされたものであり、印刷ジョブに関する一連の情報を統合化し、統合化されたジョブの全体像をユーザに提供する印刷システムを提供することを目的とする。
【００１３】
さらに、１つの印刷ジョブの生成から消滅までに与えられる識別情報を印刷システム上の各々のサブシステムが取得するものを提供することも目的とする。また、ジョブ情報断片が増えなくなり、情報をクローズするタイミングを認識するものを提供することを目的とする。
【００１４】
【課題を解決するための手段】
かかる目的を達成するため、請求項１に記載の発明は、ネットワーク上のクライアントの有する印刷データ生成部が印刷データを前記ネットワークを通じて送信して印刷する印刷システムであって、印刷装置駆動部は、ドライバ履歴情報を記憶する第１の記憶手段を有し、印刷装置は、前記印刷装置が行った印刷装置履歴情報を記憶する第２の記憶手段を有し、印刷管理装置は、前記第１の記憶手段が記憶するドライバ履歴情報と、前記第２の記憶手段が記憶する印刷装置履歴情報とを読み出す手段と、前記読み出し手段によって読み出された前記ドライバ履歴情報および前記印刷装置履歴情報を記憶する第３の記憶手段と、前記読み出された前記ドライバ履歴情報および前記印刷装置履歴情報のいずれかに含まれるデータに示される処理を選択し、基準の処理を決定する基準ジョブ決定手段と、前記基準ジョブ決定手段によって決定された基準の処理とは別のデータで示される処理が、同一の印刷ジョブで行われているか否かを判断する判断手段と、前記基準の処理を示すデータとは別の処理を示すデータを基準の処理を示すデータに追加し、また、前記基準の処理とは別のデータで示される処理が前記判断手段によって前記印刷ジョブで行われていると判断された場合に追加されるデータ追加手段と、前記データ追記手段により追加され、１つの印刷ジョブのジョブ情報として統合された統合履歴情報を前記クライアントに転送する転送手段と、を有することを特徴とする。
【００１５】
請求項２に記載の発明は、請求項１に記載の発明において、前記追加手段によって追加された別の処理を示すデータを、前記追加手段によって追加される前に格納されていた前記ドライバ履歴情報および前記印刷装置履歴情報のいずれか１つを削除する第１の削除手段を有することを特徴とする。
【００１６】
請求項３に記載の発明は、請求項１または２に記載の発明において、前記印刷データ生成部は、前記ネットワーク上および該ネットワークに接続される端末内で共通で、各々の前記印刷ジョブによって区別される識別情報を前記印刷データに組み込む識別情報組み込み手段を有し、前記判断手段による判断の基準は、前記識別情報組み込み手段によって組み込まれた識別情報に基づくことを特徴とする。
【００１７】
請求項４に記載の発明は、請求項１から３のいずれか１項に記載の発明において、前記印刷管理装置は、前記ドライバ履歴情報および前記印刷装置履歴情報のいずれか１つに含まれる１つの情報を構成する１つの要素である情報項目を削除する第２の削除手段を有し、前記判断手段によって判断される際に、前記ドライバ履歴情報の情報項目と前記印刷装置履歴情報の情報項目とが一致する場合、前記ドライバ履歴情報の情報項目および前記印刷装置履歴情報の情報項目のいずれか一方を前記第２の削除手段によって削除することを特徴とする。
【００１８】
請求項５に記載の発明は、請求項１記載の発明において、前記ネットワークにはさらにサーバが接続され、前記サーバは前記印刷ジョブにおいて前記サーバがどのような処理を行ったかというサーバ履歴情報を記憶し、保存する第４の記憶手段を有し、前記読み出し手段は、前記第４の記憶手段が記憶するサーバ履歴情報をさらに読み出すことを特徴とする。
【００１９】
請求項６に記載の発明は、請求項１に記載の発明において、ネットワークにはさらにサーバが接続され、第３の記憶手段はサーバ履歴情報をさらに記憶することを特徴とする。
【００２０】
請求項７に記載の発明は、請求項１または３に記載の発明において、ネットワークにはさらにサーバが接続され、基準ジョブ決定手段の選択の対象はサーバ履歴情報に含まれる任意の１つのデータに示される処理も含まれることを特徴とする。
【００２１】
請求項８に記載の発明は、請求項２に記載の発明において、ネットワークにはさらにサーバが接続され、第１の削除手段の削除の対象はサーバ履歴情報も含まれることを特徴とする。
【００２２】
請求項９に記載の発明は、請求項４に記載の発明において、ネットワークにはさらにサーバが接続され、第２の削除手段による削除の対象はサーバ履歴情報に含まれる１つのデータを構成する１つの要素である情報項目も含まれることを特徴とする。
【００２３】
請求項１０に記載の発明は、複数のサブシステムを有する印刷システムであって、印刷システムは、印刷システムで行われる各々の印刷ジョブを識別するジョブ識別子と、印刷システムの所定の範囲内でジョブ識別子を検索するために用いられるキーとを対応づけて保存するジョブＩＤ一覧保持部をさらに有し、複数のサブシステムは、キーによって識別子を検索し、識別子によって、印刷ジョブにおいて複数のサブシステム各々で行われるジョブである断片ジョブをまとめることを特徴とする。
【００２４】
請求項１１に記載の発明は、請求項１０の印刷システムにおいて、ジョブＩＤ一覧保持部は、ジョブ識別子を破棄する識別子破棄手段と、破棄する時期を決める破棄時期決定手段と、をさらに有し、破棄する時期は複数のサブシステムの通知によって決定されることを特徴とする。
【００２５】
請求項１２記載の印刷システムの発明は、請求項１０または１１の印刷システムにおいて、複数のサブシステムは、サブシステムにおける断片ジョブの開始と終了とをジョブＩＤ一覧保持部に通知するジョブ開始終了通知手段をさらに有し、サブシステムは、ジョブ開始終了通知手段が断片ジョブの終了を通知してから、断片ジョブをまとめることを特徴とする。
【００２８】
【発明の実施の形態】
以下に添付図面を参照した本発明に係る印刷システムの実施形態を詳細に説明する。図１から図１０に、本発明に係る印刷システムの一実施例が示す。
【００２９】
［第１の実施例］
図１に、本発明に係る印刷システムの第１の実施例を示す。図１に示すように、本実施例は、クライアント１０、サーバＰＣ２０、印刷装置３０およびジョブ情報履歴装置４０がネットワークを介して接続されて構成されている。
【００３０】
以下に、一般的な印刷ジョブの流れを示す。まずアプリケーション１１で印刷データの生成が指示されて、ドライバ１２で印刷データが生成する。生成した印刷データは、サーバ通信１３によってサーバＰＣ２０の付加サービス２１に送信される。付加サービス２１によって分散印刷、異常プリンタ回避などの付加サービスが提供され、印刷装置３０において印刷データが印刷される。
【００３１】
上記された印刷ジョブにおいて、ドライバ１２、サーバ通信１３、付加サービス２１および印刷装置３０のそれぞれにおいて、行ったジョブの履歴が蓄積される。しかしながら、上記された各モジュール（ドライバ１２、サーバ通信１３等）に保存される履歴情報だけでは、一連の印刷ジョブの全体的な流れで各モジュールが行った動作を把握できるように、以下のように行う。ここで本実施例では、図１に示されるように、各々のモジュールが保存する履歴情報を統合し、管理するジョブ情報履歴装置４０がネットワークに接続されている。
【００３２】
以下では図４に基づいて、ジョブ情報履歴装置４０が各モジュールの履歴情報を収集し、一連の印刷ジョブの流れを示す情報が作成される。
【００３３】
ジョブ情報履歴装置４０は、図２に示されるような各モジュールが生成したジョブ履歴情報を収集する（ステップＳ１）。収集された複数のジョブ履歴情報の内、一つの履歴情報を選択して、選択された履歴情報を基準履歴情報とする（ステップＳ２）。基準履歴情報に含まれるジョブ情報を全部走査する（ステップＳ３）。走査されたジョブの内の任意の１つを基準ジョブとし（ステップＳ４）、以下このジョブが行われた印刷ジョブの他のモジュールに格納される履歴が収集される。
【００３４】
マージの対象となる任意の履歴情報を１つ取り出す（ステップS ５）。基準ジョブと同一の印刷データを印刷する際に行われたと判断されるジョブを残りの各履歴情報の中から抽出し（ステップＳ６）、基準ジョブのジョブ情報に追加する（ステップＳ７）。本実施例では判断の基準は印刷が行われた日時と印刷データのサイズに基づいている。
【００３５】
抽出されたジョブ情報を履歴情報から削除する（ステップＳ８）、追加したジョブ情報でその印刷ジョブの全情報がマージされていなければ（ステップＳ９／Ｎｏ）、別の履歴情報を取り出す（ステップＳ５）。すべての履歴情報がマージされていれば（ステップＳ９／Ｙｅｓ）、取得したすべてのジョブ情報を１つの印刷ジョブのジョブ情報として統合化して、先に統合化されている統合化履歴情報に追加する（ステップＳ１０）。
【００３６】
基準履歴情報中のすべてのジョブが基準ジョブになっていなければ（ステップＳ１１／Ｎｏ）、別の任意のジョブを基準ジョブにする（ステップＳ４）。基準履歴情報中のすべてのジョブが基準ジョブになっており（ステップＳ１１／Ｙｅｓ）、かつ、収集した履歴情報が基準履歴情報になっていれば（ステップＳ１２／Ｙｅｓ）、処理は終了する。収集した履歴情報がすべて基準履歴情報になっていなければ（ステップＳ１２／Ｎｏ）、別の履歴情報が基準履歴情報になる（ステップＳ２）。
【００３７】
上記されたように１回の印刷ジョブについて、各モジュールに保存されるジョブ情報が統合化することによって、例えば、その結果を印刷するなどしてユーザが入手すれば、ユーザは従来に比べてそれぞれの印刷ジョブについて全体的な情報を入手することが容易になる。
【００３８】
本実施例では、ジョブ情報履歴装置４０は各モジュールの生成した履歴情報を統合化する時に、ある基準履歴情報中の基準ジョブと同一の印刷ジョブの際に行われたと判断されるジョブ情報を、残りの各履歴情報中から取得する際に判断基準が使用される。この判断基準は、その印刷ジョブが行われた日時とサイズの一致に基づいて行われる。
【００３９】
［第２の実施例］
以下に、第２の実施例を示す。本実施例では、上記第１の実施例において、上記された判断基準に基づいて判断された場合、同一の日時に同一のサイズの印刷ジョブが行われた時、別の印刷処理のジョブであったとしても、同一の印刷ジョブと判断してしまう可能性がある場合の回避例を示す。これ以下、第２の実施例としてＰＪＬ等の印刷制御情報中に「ＪＯＢＩＤ＝識別情報」を埋め込む方法について説明する。図５に、各モジュールが保存する履歴情報の内容を示す全体の構成図が示されている。
【００４０】
本実施例では、ドライバ１２等の印刷ジョブの開始点となるモジュールが、印刷データ中にジョブの識別情報を埋め込む。この識別情報は、システムやネットワーク全体の中で、その印刷ジョブであると特定できるものであるとする。識別情報を埋め込む方法としては、上記されたようにＰＪＬ等の印刷制御情報中に「ＪＯＢＩＤ＝識別情報」を付加する方法が選択される。
【００４１】
以下、図７（ａ）に示されるフローチャートに基づいて、本実施例におけるドライバ１２等のジョブの開始点において、識別情報をジョブデータに埋め込む処理を説明する。アプリケーションやシステムから、印刷要求の開始と印刷データの生成が依頼される（ステップＳ１１）。
【００４２】
印刷データとジョブの識別情報とを生成し（ステップＳ１２）、生成した印刷データとジョブの識別情報とをセットにして履歴情報に保管し（ステップＳ１３）、ジョブの識別情報をジョブデータに埋め込み、その後、印刷工程（付加サービス等）に送る（ステップＳ１４）。
【００４３】
以下、図７（ｂ）に示すフローチャートに基づいて、本実施例におけるジョブの開始点以外の点における処理を説明する。
モジュールの前の工程から送信されたジョブデータを受け取り（ステップＳ２１）、ジョブデータに従って各モジュールの一般の処理（付加サービス２１ならサーバサービスで、印刷装置３０なら紙出力）を行う（ステップＳ２２）。
【００４４】
ジョブデータ中のジョブ識別情報を抽出し、ジョブ識別情報とその他の情報（処理結果の情報やジョブ情報など）とをセットにして履歴情報に保管する（ステップＳ２３）。上記各モジュールが保存したジョブ履歴情報を、図６に示す。
【００４５】
各モジュールが保存したジョブ履歴情報群を統合するときは、基本的な統合化処理の流れは前記第１の実施例の場合と同様である。第１の実施例では、基準ジョブと同じ印刷ジョブで行われたジョブを他の履歴情報中から検索する場合は、日時とサイズの一致を判断基準としていた。本実施例では各ジョブの識別情報の一致により検索を実行する。
【００４６】
システム全体で印刷ジョブを特定できるジョブ識別情報の生成に関しては、クライアント１０のネットワークアドレスを使用する方法などが考えられる。ネットワークアドレスを用いることによりシステム上のネットワークノードが特定されるのため、識別情報の前半にクライアントのネットワークアドレスあるいはそれに基づいた値を用いる。
【００４７】
識別情報の後半には、そのネットワークノード（具体的にはクライアント１０）内で特有の値を付加する。例えば、特有の値としては、ミリ秒やマイクロ秒レベルの時間情報、あるいは、インクリメント・カウンタなどが考えられる。さらに分散コンピューティング技術におけるいくつかの「ユニーク値生成方式」（ＵＵＩＤなど）を用いてもよい。
【００４８】
また、ドライバ１２等の印刷データを生成するモジュールが、ジョブ識別情報を埋め込めないシステム構成の場合は、その後の工程モジュールが、前工程モジュールから送られた印刷データに対し、後から識別情報を付加する方法が採用される。
【００４９】
また印刷データの形式によっては識別情報を埋め込むことができない場合もあるが、その場合は前工程から後工程に印刷データを渡す通信手段の中で、識別情報を送信してもよい。つまり印刷データ内に識別情報を埋め込むのではなく、パケットのヘッダやコマンドの引数など、データ受け渡し手段の方を経由してジョブ識別情報を送信してもよい。
【００５０】
また通信手段によっては、ジョブを送信するのではなく、受信側が識別情報を付加する場合には、前工程（ジョブを送信する側）が後工程（ジョブを受け取る側）からその識別情報を受け取って、履歴情報に追加してもよい。
【００５１】
上記した本実施例に示すように、印刷ジョブに識別情報を新たに埋め込むことによって、印刷ジョブ情報を統合化する際に、違う印刷ジョブで行われたジョブであっても同じ印刷ジョブで行われたジョブと判断される可能性がなくなる。これにより、ユーザはより正確なジョブ情報を把握することができるようになる。
【００５２】
［第３の実施例］
以下、第１の実施例において、文書名（ジョブ名）、要求者情報や課金情報など、ジョブが開始されてから完了するまで変化しないと予想される情報が同一印刷ジョブの複数の履歴情報中で重複して現れる場合の、重複する情報を１つにマージして情報を統合化する方法について、第３の実施例として説明する。図８に、第３の実施例における全体の構成図を示す。図８において、各モジュールが保存する履歴情報の内容も示す。
【００５３】
以下に、図１０に示すフローチャートに基づいて、本実施例における動作を示す。以下の動作は図４に示すフローチャートのＳ６とＳ７との間で行われる。まず基準ジョブの中から情報項目の項目識別子をすべて取得する（ステップＳ３１）。ステップＳ６において抽出された統合化対象のジョブ中で、Ｓ３１で取得した項目識別子と重なるものを削除する（ステップＳ３２）。
【００５４】
この第３の実施例では、例としてジョブ情報は、ジョブ識別情報、日付、ユーザ名およびバイト数の４つから構成されるものとする。これら４つの情報は、ジョブ情報を表現する個々の構成要素であると考えられ、これらの構成要素は、以下に示すように、「タイプと値」の組から構成される。
【００５５】
例えば、ジョブ情報が上記４つの上記４つの要素から構成される場合は、１つのジョブ情報は「”jobid ＝１２３４”」「”date＝０６／０１”」「”user＝浅谷”」「”size＝１８０”」という４つの「タイプ＋値」組から成る。
【００５６】
各履歴情報は各モジュールにおけるジョブの履歴を並べたものでり、その個々のジョブ情報に、その値だけでなく、項目識別情報も含まれる。項目識別情報は情報要素のタイプを意味し、具体的には日時を表す情報の場合には日時情報を、バイト数を表す情報の場合にはバイト数情報のタイプである。
【００５７】
履歴情報がＣＳＶ（comma separated value ）形式のデータである場合、
jobid, date， user
１２３４，０６／０１，浅谷
１２３５，０６／０１，井上
の様になり、一行目にどの様なタイプのデータがどの順で並んでいるかを表す行を設けて識別するという方法がある。
【００５８】
あるいは履歴情報をＸＭＬ（extensible markup language）などのタグ付け形式にして、各情報要素が異なるタグ名で記載される方法もある。また履歴情報がバイナリデータの場合、各情報要素はその値だけではなく「タイプ、値」の列で格納される方法もある。
【００５９】
履歴情報を生成する各モジュールは、同じ意味の情報要素については同じ情報識別子で識別するようにする。例えば「ジョブ識別情報」という情報要素は、同じ印刷ジョブで行われている以上、ジョブのパスの開始から終了のいかなる点で採取しても同じ意味を持つ。
【００６０】
システムによっては、ジョブ名やジョブの要求者名も、ジョブの開始から終了まで同じ意味を持つ場合がある。上記されたような情報要素については、すべてのログ情報保存モジュールが、jobid 、jobname あるいはuserなどの同一の情報要素識別子を用いるようにする。
【００６１】
上記されたように型が付けられた履歴情報において、これらを統合化する場合には、同じ情報要素であれば一つにまとめることが可能になる。その処理の流れを図１０に示す。以下、まとめる処理について、図１０に基づいて説明する。
【００６２】
第１の実施例において、基準ジョブに別の履歴情報中の同一の印刷ジョブで行われたと判断されるジョブの情報を追加する時に、単に追加するのではなく、基準ジョブ情報内に既に存在する情報要素を１つ列挙する。そして各々の既存情報要素に対して、情報要素識別子をもつ情報要素を探し、一致する情報要素があれば、それを削除する。こうして残された情報要素だけが基準ジョブ情報に追加される。
【００６３】
本実施例では、２つのジョブ情報の中に重複する情報要素があった時に、基準ジョブ情報の値を優先する方法であった。しかしながら、基準ジョブ情報の値を統合化対象のジョブ情報の値で上書きしてもよい。また、双方の値を比較して、一致しない場合には、ユーザに一方の値を選択させたり、一致しなかった場合には、あらかじめユーザがどちらの値を選ぶかを指定できるようにするという方法を採用する。
【００６４】
上記されたように、複数の履歴情報に存在する同一印刷ジョブで行われたジョブの情報が統合化される際に、重複する情報要素を検知しマージすることで、統合化されたジョブ履歴情報は、情報を失わずに簡素化され、ユーザがデータを閲覧する際にも見易くなる。
【００６５】
［第４の実施例］
ジョブ識別情報に関する上記の説明では、印刷ジョブの情報断片に識別情報を必ず埋め込むむものとして説明したが、ジョブのデータ形式によっては、埋め込むことができない場合がある。また、ジョブ情報断片を供給するサブシステムの中には、ジョブデータの中身を見ることができない場合がある。
【００６６】
また、サブシステム間のジョブ搬送手段は、ジョブデータを埋め込まない場合もあり、さらには、ジョブ情報断片を供給するサブシステムの中にジョブの搬送に関与しないものもある。
【００６７】
以下、図１１の本発明の一実施形態として適用される印刷システムの構成図に基づいて、キーによって識別子を得る処理について説明する。ジョブの識別子を採番したサブシステムは、その識別子と、そのジョブを検索し得るキーのペアを、ジョブＩＤ一覧保持部に登録する。一方、ジョブ情報断片を供給するサブシステムは、そのジョブを検索し得るキーをジョブＩＤ一覧保持部に渡して、対応する識別子を受け取る。
【００６８】
以下、「ジョブを検索し得るキー」と「ジョブを識別する識別子」との違いについて説明する。
まず、「ジョブを識別する識別子」とは、ジョブの生成から消滅までの時間、システム全体でジョブを一意に識別するようなものである。
【００６９】
一般に印刷を行うシステムでは、ジョブは例えばClient ＰＣ上で生成され、ＰＣ上の様々なモジュールを通り、やがて、そのジョブはＰＣの外を出て、印刷サーバに渡され、サーバＰＣ内の様々なモジュールを通り、さらに、サーバＰＣを出て印刷装置に渡される。
【００７０】
他方、キーとは範囲の限定されたコンテキスト内で、ジョブを識別可能な値である。例えば、Client ＰＣ上でＯＳが番号をふる、すなわち採番するジョブＩＤは、そのＰＣ内に限定すれば、ジョブを識別できる。しかし、この値は、ジョブが印刷サーバや印刷装置など、Client ＰＣ外ではジョブの識別に用いることができない。また、ＯＳによっては、再起動するだけでジョブ識別ができなくなるものもある。この場合、Client ＰＣ上でＯＳが番号をふるＩＤは上記キーである。
【００７１】
ジョブＩＤ一覧保持部がこのClient ＰＣ上で稼働する場合、ジョブＩＤ一覧保持部は、ＯＳが番号を振ったＩＤであるキーとジョブ識別子とのペアを保持する。Client ＰＣ上でジョブ情報を供給する様々なモジュール（例えば、印刷アプリケーションや、プリンタドライバ、ポートドライバ、印刷プロセッサなど）は、ＯＳのジョブＩＤから、システム全体に渡って有効なジョブ識別子を入手することができる。
【００７２】
以下、サブシステム間でジョブを搬送する例について説明する。例えば、ネットワーク印刷プロトコルの中には、ジョブ受信側（印刷サーバなど）が、ジョブを受け取るときにふったＩＤをジョブ送出側（印刷クライアントなど）に渡すものがある。
【００７３】
この場合、ＩＤとしてどのような値を用いるかの決定権は、ジョブ受信側にある。本来、ジョブの生成時に識別子を生成し、ジョブの生成と同じ時点からのそのジョブの識別を可能にしなければ、ジョブの生成初期の時点で関与するサブシステムはジョブ情報を生成できない（生成できても、識別子は埋め込めない）。
【００７４】
また、ジョブ受信側の中には、このジョブ受信側のみでジョブを識別可能な値、すなわち、他のサブシステムでは識別不能な値を返すものもある。また、印刷プロトコルによっては、ジョブ受信側が返すジョブＩＤのデータ形式が決められている場合がある。この場合、システム全体でジョブを識別するための共通の情報を埋め込むことができない。
【００７５】
従って、システム全般でジョブを識別可能な識別子は、別途に採番される。例えば、ジョブの生成時点で番号をふられるようにしてもよい。そして、この例では、キーは印刷サーバなどが生成するＩＤとなる。
【００７６】
この場合、「ClientなどのサブシステムＡと、サーバなどのサブシステムＢの間のジョブ搬送」という限定されたコンテキストで、搬送プロトコル上のＩＤは有用なものである。従って、この間の授受に対してジョブＩＤ一覧保持部を起き、ジョブ送出側と受信側の二者間で有効なＩＤをキーとして、ジョブフローの上流から引き継がれてきたジョブ識別子を検索可能にする。
【００７７】
このように既存の技術で導入されているジョブＩＤ値とは、Client ＰＣ内のＯＳ範囲内や、二者間のジョブ搬送通信など、限定されたコンテキストで有用な値である。既存技術ではこのようなＩＤは多いので、それをそのコンテキスト内における「キー」とし、そのキーからシステム全体でジョブを識別できる識別子を検索する。
【００７８】
なお、本例では、「ジョブＩＤ一覧保持部をCleint ＰＣ内に置き、Cleint ＰＣ内の各モジュールでのジョブ識別子検索を可能にする」「ジョブ送信側と受信側の二者間にジョブＩＤ一覧保持部を置き、この二者間でのジョブ識別子検索を可能にする」という方法を例示した。この例は、ジョブＩＤ一覧保持部を、各々のコンテキスト内に置くモデルである。
【００７９】
しかし、別の方法として、ジョブＩＤ一覧保持部を各々のコンテキストの外に置き、システム全体で活用できる位置付けとすることもできる。そのためには、例えば、［key-識別子］というペアの配列でなくて、［contexｔ‐Ａのkeｙ，context - Ｂのkey ，context - Ｃのkey - 識別子］というように、一つのジョブ識別子に対して、各コンテキスト毎のkey を結び付けられるようにすればよい。
【００８０】
以下、図１２（ａ）および（ｂ）に基づいてジョブ生成側サブシステムおよびジョブ受信／監視側サブシステムが行う処理について説明する。まず、ジョブ生成側サブシステムがジョブＩＤ一覧保管部にキーと識別子のペアを保管する処理について説明する。
【００８１】
ジョブ識別子を生成する（ステップＳ４１）と、そのジョブを限定されたコンテキスト内であれば別の方法で特定できるようなキーを決定する（ステップＳ４２）。ジョブ識別子とキーとを、ジョブＩＤ一覧保持部に通知する（ステップＳ４３）。ジョブＩＤ一覧保持部は、キーと識別子とのペアを保管して（ステップＳ４４）、処理が終了する。
【００８２】
次に、ジョブ受信／監視側サブシステムがキーと一致する識別子を返す処理について説明する。ジョブ情報を取得すると（ステップＳ５１）、そのジョブを限定されたコンテキスト内であれば別の方法で特定できるようなキーを決定する（ステップＳ５２）。
【００８３】
キーをジョブＩＤ一覧保持部に送り、対応する識別子を要求する（ステップＳ５３）。ジョブＩＤ一覧保持部はＩＤ一覧を検索し、キーと一致する識別子を返す（ステップＳ５４）。
以下、消去する時期を認識する処理について説明する。
【００８４】
ジョブ識別子一覧は各サブシステムが保持する。各サブシステムは、自分がジョブを処理する過程で、必要なジョブ識別子のみ記憶し、ジョブ情報を送出し終えた場合に不要となった識別子が発生する。この識別子は、サブシステム自身の適切なタイミングで破棄すればよい。
【００８５】
ＩＤ通知部が［key ］−［識別子] の情報を各サブシステムに通知する手段としては、予めそのような情報を必要とするサブシステムが自身を通知先として登録する方法もあるし、あるいは、ネットワーク上のbroadcast/multicast のようにあらかじめ、決められた手段で情報を不特定多数に流し、各サブシステムが必要な分だけ拾うという方法もある。
【００８６】
以下、図１５の（ａ）および（ｂ）に基づいて、識別子の番号をふる処理（採番処理）について説明する。まず、（ａ）に基づいてこの処理を説明する。
【００８７】
アプリケーションやドライバなどジョブ識別子の番号をふるモジュールは、識別子とキーとをＩＤ通知部に渡す（ステップＳ６１）。ＩＤ通知部はこのキーと識別子とを各サブシステムに通知する（ステップＳ６２）。キーと識別子とを受信した各サブシステムは、それを自身で保持して（ステップＳ６３）、処理は終了する。
【００８８】
次に、（ｂ）に基づいてサブシステムによるジョブ情報生成時の処理について説明する。対象とするジョブのキーをもとにして、自身が持つテーブルから対応する識別子を取り出す（ステップＳ７１）。そのジョブの情報を送出し、自身のテーブルからそのジョブの［キー］−［識別子］を削除する（ステップＳ７２）。
【００８９】
以下、ジョブ履歴保持部が、任意のジョブ情報において、情報断片の受信待機時間の判断方法について説明する。ここで、ジョブが通るパス上のサブシステムは様々なタイミングでジョブ情報断片をジョブ履歴保持部に供給するものとする。
【００９０】
図１６に、本発明の一実施形態として適用される印刷システムの構成図が示す。各サブシステムは、自身のもとにジョブが搬送された時に、開始を表す通知をジョブ履歴保持部αに送る。この時、この通知だけでなく、開始に関するジョブ情報断片を一緒に送ってもよい。
【００９１】
サブシステムはジョブ処理を行った後、次工程のサブシステムにジョブを搬送する。
サブシステムはジョブ処理を開始したら、Start の通知をジョブ履歴情報保持部に送る。前工程のサブシステムは、ジョブの転送が完了した後、ジョブ情報断片を送らないことを表す通知を送る。なお、前記同様に、自身のジョブ処理の終了に関するジョブ情報断片を一緒に送るようにしてもよい。
【００９２】
次工程のサブシステムも同様に、ジョブ処理を行った後に次工程に送り、End の通知（必要ならばジョブ情報断片も）ジョブ履歴保持部に送る。サブシステムの中には、ジョブのフローに介在せず、ジョブパスの外から監視を行うものもある。本例では、印刷装置を監視するサブシステムがあるとする。
【００９３】
このサブシステムは、自身が監視するポイントでジョブが発生（あるいは受信）したことを発見した場合、前記同様にStart の通知や補足のジョブ情報断片をジョブ履歴保持部に送る。また、そのポイントにおいてジョブが消滅したら、End の通知や補足のジョブ情報断片をジョブ履歴保持部に送る。
【００９４】
一方、ジョブ履歴保持部は、Start - End やそれに付随するジョブ情報断片を蓄積する。任意のジョブに対し、一のサブシステムからEnd の通知が来ても、他のサブシステムからはStart の通知しかきていない場合、このジョブは、システム上で生存し、今後も情報断片が寄せられる可能性がある。その場合は、そのジョブに関しては、まだオープン状態とする。
【００９５】
Start を送ったすべてのサブシステムから、そのジョブに対するEnd の通知が来たら、システム上でそのジョブに対する情報断片はそれ以上寄せられないと判断し、そのジョブの情報をクローズし、情報断片のマージを行う。以上のようにすれば、システム上の様々なサブシステムが、様々なタイミングでジョブ情報断片を供給する場合でも、情報断片をまとめあげる正確なタイミングを得ることができる。
【００９６】
図１７に、上記の処理についての処理の流れを示す。まず、Subsystem Ａにジョブが搬送されると、開始を示す通知がジョブ履歴保持部に送られ、ジョブ処理が開始される。そのジョブ処理が終了したら次工程のサブシステムであるSubsystem Ｂにそのジョブは搬送される。
【００９７】
その搬送が終了すると、終了を示す通知をジョブ履歴保持部に送る。一方、ジョブが搬送されたSubsystem Ｂは開始を示す通知をジョブ履歴保持部に送り、搬送されたジョブの処理を開始する。
【００９８】
同様に、処理が終了したら次工程のサブシステムである印刷装置にジョブを搬送する。搬送が終了したら終了を示す通知をジョブ履歴保持部に送る。一方、ジョブが搬送された印刷装置では搬送が終了したら、印刷処理を行って処理を終了する。
【００９９】
また、ジョブのフローに参加しないSubsystem Ｘでは、Subsystem Ｂから印刷装置へのジョブの搬送が開始したら、ジョブ履歴保持部へその開始を示す通知を行い、上記システムにおけるすべての処理が終了したら、その終了を示す通知をジョブ履歴保持部へ行う。
【０１００】
【発明の効果】
以上の説明から明らかなように、本発明によれば、１回１回の印刷ジョブについて、各モジュールに保存されるジョブ情報が統合化されるので、その結果を印刷するなどしてユーザが入手しやすくすれば、ユーザは従来に比べてそれぞれの印刷ジョブについての全体的な情報を入手することが容易になる。
【０１０１】
さらに印刷ジョブに識別情報を新たに埋め込むことによって、印刷ジョブ情報を統合化する際に、違う印刷ジョブで行われたジョブであっても同じ印刷ジョブで行われたジョブと判断される可能性がなくなるので、ユーザはより正確なジョブ情報を把握することができるようになる。
【０１０２】
さらに、複数の履歴情報に存在する同一印刷ジョブで行われたジョブの情報が統合化される際に、重複する情報要素を検知しマージすることで、統合化されたジョブ履歴情報は、情報を失わずに簡素化され、ユーザがデータを閲覧する際にも見易くなる。
【０１０３】
また、ジョブ識別子を直接読み出すことができなくても、検索して読み出すことができるので、確実に識別子を読み出すことができ、より正確に印刷ジョブをまとめることが可能になる。
【０１０４】
また、ジョブ履歴保持部において必要がなくなった識別子を破棄することができるようになったので、より効率よくジョブ履歴保持部を識別子の記憶領域を使用することが可能になった。
【０１０５】
また、ジョブをまとめるタイミングをサブシステムが把握することが可能になったので、各サブシステムはジョブをまとめる適切なタイミングのもとにジョブをまとめることが可能になった。
【図面の簡単な説明】
【図１】本発明の印刷システムに係る第１の実施例の全体構成図である。
【図２】ドライバ１２に保存される履歴情報１２ａ、付加サービス２１に保存される履歴情報２１ａおよび印刷装置３０に保存される３０ａ各々の履歴情報の内容の一例である。
【図３】第１の実施例における処理動作を実行するプログラムの内容が示されている。
【図４】第１の実施例における動作が示されるフローチャートである。
【図５】本発明の印刷システムに係る第２の実施例の全体構成図である。
【図６】第２の実施例において各モジュールが保存する履歴情報の一例が示されている。
【図７】第２の実施例において各モジュールの動作が示されるフローチャートである。
【図８】本発明の印刷システムに係る第３の実施例における全体構成図である。
【図９】第３の実施例における処理動作を実行するプログラムが示されている。
【図１０】第３の実施例における動作が示されるフローチャートである。
【図１１】本発明の一実施形態として適用される印刷システムの構成図である。
【図１２】ジョブ生成側のサブシステムがキーと識別子を保管する処理およびジョブ受信／監視側のサブシステムがキーから識別子を検索する処理が示されたフローチャートである。
【図１３】印刷ジョブの基本モデル、ジョブデータへの埋め込みおよびジョブ搬送手段でのＩＤ通知について示される図である。
【図１４】本発明の一実施形態として適用される印刷システムの構成図である。
【図１５】識別子の番号をふる処理とサブシステムによってジョブ情報の生成時に行われる処理とが示されたフローチャートである。
【図１６】本発明の一実施形態として適用される印刷システムの構成図である。
【図１７】ジョブ履歴保持部に各サブシステムがジョブの開始と終了とを示すフローチャートである。
【符号の説明】
１０クライアント
１１アプリケーション
１２ドライバ
１２ａドライバに保存される履歴情報
１２ｂドライバに保存される履歴情報
１２ｃドライバに保存される履歴情報
１３サーバ通信
１３ａサーバ通信に保存される履歴情報
１３ｂサーバ通信に保存される履歴情報
１３ｃサーバ通信に保存される履歴情報
２０サーバＰＣ
２１付加サービス
２１ａ付加サービスに保存される履歴情報
２１ｂ付加サービスに保存される履歴情報
２１ｃ付加サービスに保存される履歴情報
３０印刷装置
３０ａ印刷装置に保存される履歴情報
３０ｂ印刷装置に保存される履歴情報
３０ｃ印刷装置に保存される履歴情報
４０ジョブ情報履歴装置
４０ａジョブ情報履歴装置に保存される履歴情報
４０ｂジョブ情報履歴装置に保存される履歴情報
４０ｃジョブ情報履歴装置に保存される履歴情報
Ａサブシステム
Ｂサブシステム
Ｃサブシステム
Ｘサブシステム[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a printing system in which print data transmitted from a client is received, processed, and printed via a network by a print server or a printing apparatus, and in particular, acquires and manages a print job history of each module. The present invention relates to a printing system.
[0002]
[Prior art]
A printing system that transmits data from a plurality of client apparatuses via a network, receives and processes data transmitted from a printing apparatus or a print server connected to the network, and performs printing has been put into practical use.
[0003]
In the printing system described above, as a method for acquiring the “print job history”, for example, a technique in which the print driver itself stores data of a job generated by the print driver on the client as data, and information on a print job serviced by the print server A technique for storing the print server itself and a technique for storing information on a job to be printed by the printing apparatus are known.
[0004]
As such prior art, Japanese Patent Laid-Open No. 10-283131 discloses that print history information is stored in a storage medium in a printer, and the stored print history information is printed or transmitted to a host computer. Techniques for displaying to the user have been proposed.
[0005]
[Problems to be solved by the invention]
Originally, a print job starts from a job generation location “client”, passes through a print server or the like, finally reaches a printing apparatus, print data is printed, and the process ends.
[0006]
However, in the above-described prior art, each print driver, print server, and printing apparatus is limited to storing print job information that can be collected at a single point (location) in a passing path. .
[0007]
For example, since the print driver exists on the client that is the job start point, information related to the “job start point” such as the name of the user who requested the job and the name of the application that performed the printing can be collected in detail. However, information regarding the “job end point” such as how many sheets have been finally output and information regarding print value-added job scheduling scheduled to be performed by the print server cannot be stored.
[0008]
In addition, the print server can collect in detail information serviced by the print server, such as job scheduling on the print server, distributed printing, and output to another printing apparatus by avoiding a malfunctioning printing apparatus. However, the print server cannot store information regarding the job start point and end point.
[0009]
Furthermore, the printing apparatus can collect in detail information regarding the end point of the job, such as the number of sheets actually output, but cannot store information on the starting point of the requester, print added value information by the server, and the like.
[0010]
The print job passes through the service point from the start point and reaches the end point, but the print job information that can be acquired at each point in the meantime is different, and the job history information generated by the conventional technology is on this path. There was a problem that it was biased to any one of the job information.
[0011]
The job history is used for various purposes such as billing and load analysis. The necessary job information varies depending on the application, and in some cases, all information on the job path may be required. If there are problems as described above, there are cases where it is inconvenient to use job information.
[0012]
The present invention has been made in view of the above problems, and an object of the present invention is to provide a printing system that integrates a series of information related to a print job and provides a user with an overall image of the integrated job.
[0013]
It is another object of the present invention to provide a system in which each subsystem on the printing system acquires identification information given from generation to deletion of one print job. It is another object of the present invention to provide a job information fragment that does not increase and recognizes the timing for closing information.
[0014]
[Means for Solving the Problems]
  In order to achieve this object, the invention according to claim 1 is a printing system in which a print data generation unit included in a client on a network transmits print data through the network for printing, and the printing apparatus driving unit includes: The printer has first storage means for storing driver history information, the printing apparatus has second storage means for storing printing apparatus history information performed by the printing apparatus, and the print management apparatus has the first storage means. Means for reading out driver history information stored in the storage means and printing device history information stored in the second storage means;Third storage means for storing the driver history information and the printing apparatus history information read by the reading means, and data included in any of the read driver history information and the printing apparatus history information The reference job determination means for selecting the process shown in FIG. 5 and determining the reference process and the process indicated by the data different from the reference process determined by the reference job determination means are performed in the same print job. A determination means for determining whether or not the data indicating the reference process is added to the data indicating the reference process, and the data indicating the reference process is indicated by data different from the reference process. Added by the data adding unit, the data adding unit added when it is determined by the determining unit that the process is performed in the print job, One of the integrated history information that is integrated as a job information of the print job and having a transfer means for transferring to the client.
[0015]
  The invention according to claim 2 is the invention according to claim 1,A first deletion that deletes any one of the driver history information and the printing apparatus history information stored before the data indicating another process added by the adding unit is added by the adding unit. It has the means.
[0016]
  The invention according to claim 3 is the invention according to claim 1 or 2,The print data generation unit includes identification information incorporation means that is common in the network and a terminal connected to the network and incorporates identification information that is distinguished by each print job into the print data. The criterion for determination by the means is based on the identification information incorporated by the identification information incorporation means.
[0017]
  The invention according to claim 4The invention according to any one of claims 1 to 3, wherein the print management apparatus is one element constituting one information included in any one of the driver history information and the printing apparatus history information. A second deletion unit that deletes a certain information item, and when the information item of the driver history information and the information item of the printing device history information match when determined by the determination unit, the driver history Either the information item of information or the information item of the printing apparatus history information is deleted by the second deleting unit.
[0018]
  The invention described in claim 54. The fourth storage means according to claim 1, wherein a server is further connected to the network, and the server stores and saves server history information indicating what processing the server has performed in the print job. The reading means further reads server history information stored in the fourth storage means.
[0019]
  The invention described in claim 6The invention according to claim 1 is characterized in that a server is further connected to the network, and the third storage means further stores server history information.
[0020]
  The invention described in claim 7The invention according to claim 1 or 3 is characterized in that a server is further connected to the network, and the selection target of the reference job determination means includes a process indicated by any one data included in the server history information. And
[0021]
  The invention according to claim 8 provides:The invention according to claim 2 is characterized in that a server is further connected to the network, and the deletion target of the first deletion means includes server history information.
[0022]
  The invention according to claim 9 is:In the invention described in claim 4, a server is further connected to the network, and a deletion target by the second deletion means includes an information item that is one element constituting one data included in the server history information. It is characterized by that.
[0023]
  The invention according to claim 10 is:A printing system having a plurality of subsystems, wherein the printing system identifies a job identifier for identifying each print job performed in the printing system, and a key used for searching for the job identifier within a predetermined range of the printing system. Are stored in association with each other, and a plurality of subsystems search for an identifier by a key, and a fragment job that is a job executed in each of the plurality of subsystems in a print job by the identifier. It is characterized by grouping.
[0024]
  The invention according to claim 1111. The printing system according to claim 10, wherein the job ID list holding unit further includes an identifier discarding unit that discards the job identifier, and a discarding time determining unit that determines a discarding time. The discarding time is determined by a plurality of subsystems. It is determined by notification.
[0025]
  The invention of the printing system according to claim 1212. The printing system according to claim 10, wherein the plurality of subsystems further include job start / end notification means for notifying the job ID list holding unit of the start and end of the fragment job in the subsystem. After the start / end notification means notifies the end of the fragment job, the fragment jobs are collected.
[0028]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of a printing system according to the present invention will be described in detail below with reference to the accompanying drawings. 1 to 10 show an embodiment of a printing system according to the present invention.
[0029]
[First embodiment]
FIG. 1 shows a first embodiment of a printing system according to the present invention. As shown in FIG. 1, the present embodiment is configured by connecting a client 10, a server PC 20, a printing apparatus 30, and a job information history apparatus 40 via a network.
[0030]
A general print job flow is shown below. First, the generation of print data is instructed by the application 11, and the print data is generated by the driver 12. The generated print data is transmitted to the additional service 21 of the server PC 20 by the server communication 13. Additional services such as distributed printing and abnormal printer avoidance are provided by the additional service 21, and print data is printed by the printing apparatus 30.
[0031]
In the above-described print job, the history of jobs performed in the driver 12, the server communication 13, the additional service 21, and the printing apparatus 30 is accumulated. However, only the history information stored in each of the above-described modules (driver 12, server communication 13, etc.) allows the operation performed by each module to be grasped in the overall flow of a series of print jobs as follows. To do. Here, in this embodiment, as shown in FIG. 1, a job information history apparatus 40 that integrates and manages history information stored in each module is connected to a network.
[0032]
In the following, based on FIG. 4, the job information history apparatus 40 collects history information of each module, and information indicating the flow of a series of print jobs is created.
[0033]
The job information history device 40 collects job history information generated by each module as shown in FIG. 2 (step S1). One piece of history information is selected from the collected job history information, and the selected history information is set as reference history information (step S2). All the job information included in the reference history information is scanned (step S3). Arbitrary one of the scanned jobs is set as a reference job (step S4), and the history stored in other modules of the print job in which this job is performed is collected.
[0034]
One arbitrary history information to be merged is extracted (step S5). A job judged to have been performed when printing the same print data as the reference job is extracted from the remaining pieces of history information (step S6) and added to the job information of the reference job (step S7). In this embodiment, the determination criterion is based on the date and time when printing was performed and the size of the print data.
[0035]
The extracted job information is deleted from the history information (step S8). If all information of the print job is not merged with the added job information (step S9 / No), another history information is extracted (step S5). . If all the history information has been merged (step S9 / Yes), all the acquired job information is integrated as job information of one print job and added to the integrated history information that has been integrated previously. (Step S10).
[0036]
If all the jobs in the reference history information are not reference jobs (step S11 / No), another arbitrary job is set as a reference job (step S4). If all jobs in the reference history information are reference jobs (step S11 / Yes) and the collected history information is reference history information (step S12 / Yes), the process ends. If all the collected history information is not the reference history information (step S12 / No), another history information becomes the reference history information (step S2).
[0037]
As described above, by integrating the job information stored in each module for a single print job, if the user obtains it by printing the result, for example, the user can compare with the conventional one. It is easy to obtain overall information about the print job.
[0038]
In the present embodiment, when the job information history device 40 integrates the history information generated by each module, the job information that is determined to be performed in the same print job as the reference job in a certain reference history information, Judgment criteria are used when obtaining from the remaining pieces of history information. This determination criterion is made based on the coincidence of the date and time when the print job was performed.
[0039]
[Second Embodiment]
The second embodiment is shown below. In this embodiment, when a determination is made based on the above-described determination criteria in the first embodiment, when a print job of the same size is performed at the same date and time, it is a job for another print processing. Even if this is the case, an example of avoiding the case where there is a possibility of determining that the print jobs are the same will be described. Hereinafter, a method of embedding “JOBID = identification information” in print control information such as PJL will be described as a second embodiment. FIG. 5 is an overall configuration diagram showing the contents of history information stored in each module.
[0040]
In this embodiment, a module serving as a start point of a print job such as the driver 12 embeds job identification information in the print data. It is assumed that this identification information can be identified as the print job in the entire system or network. As a method of embedding the identification information, a method of adding “JOBID = identification information” to the print control information such as PJL as described above is selected.
[0041]
A process for embedding identification information in job data at the start point of a job such as the driver 12 in this embodiment will be described below based on the flowchart shown in FIG. The application or system requests the start of a print request and the generation of print data (step S11).
[0042]
Print data and job identification information are generated (step S12), the generated print data and job identification information are set and stored in history information (step S13), and the job identification information is embedded in the job data. Then, it is sent to a printing process (additional service etc.) (step S14).
[0043]
Hereinafter, based on the flowchart shown in FIG. 7B, processing at points other than the job start point in the present embodiment will be described.
The job data transmitted from the previous process of the module is received (step S21), and general processing of each module (server service for the additional service 21 and paper output for the printing apparatus 30) is performed according to the job data (step S22).
[0044]
The job identification information is extracted from the job data, and the job identification information and other information (processing result information, job information, etc.) are set and stored in the history information (step S23). FIG. 6 shows job history information stored by each module.
[0045]
When integrating the job history information groups stored by the modules, the basic integration processing flow is the same as in the case of the first embodiment. In the first embodiment, when searching for a job performed in the same print job as the reference job from other history information, the coincidence of date and size is used as a determination criterion. In this embodiment, the search is executed based on the match of the identification information of each job.
[0046]
Regarding generation of job identification information that can specify a print job in the entire system, a method of using the network address of the client 10 can be considered. Since the network node on the system is specified by using the network address, the network address of the client or a value based thereon is used in the first half of the identification information.
[0047]
In the latter half of the identification information, a value specific to the network node (specifically, the client 10) is added. For example, the unique value may be millisecond or microsecond level time information, an increment counter, or the like. Further, some “unique value generation methods” (such as UUID) in the distributed computing technology may be used.
[0048]
If the module that generates print data such as the driver 12 has a system configuration in which job identification information cannot be embedded, the subsequent process module adds identification information to the print data sent from the previous process module later. Is adopted.
[0049]
In some cases, the identification information cannot be embedded depending on the format of the print data. In this case, the identification information may be transmitted in a communication unit that passes the print data from the previous process to the subsequent process. That is, instead of embedding the identification information in the print data, the job identification information may be transmitted via the data delivery means such as a packet header or a command argument.
[0050]
Also, depending on the communication means, when the receiving side adds identification information instead of transmitting a job, the preceding process (the side that transmits the job) receives the identification information from the subsequent process (the side that receives the job). , May be added to the history information.
[0051]
As shown in the above-described embodiment, when the print job information is integrated by newly embedding the identification information in the print job, even if the job is performed in a different print job, it is performed in the same print job. The possibility of being judged as a job is lost. As a result, the user can grasp more accurate job information.
[0052]
[Third embodiment]
Hereinafter, in the first embodiment, information that does not change from the start of the job to the completion, such as the document name (job name), requester information, and billing information, is included in the plurality of history information of the same print job. In the third embodiment, a method of merging overlapping information into one and integrating the information in the case of overlapping appearing in FIG. FIG. 8 shows an overall configuration diagram of the third embodiment. In FIG. 8, the contents of the history information stored by each module are also shown.
[0053]
The operation in this embodiment will be described below based on the flowchart shown in FIG. The following operations are performed between S6 and S7 in the flowchart shown in FIG. First, all item identifiers of information items are acquired from the reference job (step S31). Of the jobs to be integrated extracted in step S6, those that overlap with the item identifier acquired in S31 are deleted (step S32).
[0054]
In the third embodiment, as an example, job information is assumed to be composed of job identification information, date, user name, and number of bytes. These four pieces of information are considered to be individual components representing job information, and these components are composed of a pair of “type and value” as shown below.
[0055]
For example, when the job information is composed of the above four elements, one job information is ““ jobid = 1234 ””, ““ date = 06/01 ””, ““ user = Aya ””, “” size = “180” ”and consists of four“ type + value ”pairs.
[0056]
Each history information is a list of job histories in each module, and the individual job information includes not only the value but also item identification information. Item identification information means the type of information element. Specifically, it is date information in the case of information representing the date and time, and is a type of byte number information in the case of information representing the number of bytes.
[0057]
If the history information is CSV (comma separated value) format data,
jobid, date, user
1234, 06/01, Asaya
1235, 06/01, Inoue
There is a method of identifying by providing a line indicating what type of data is arranged in which order on the first line.
[0058]
Alternatively, there is a method in which history information is set in a tagging format such as XML (extensible markup language) and each information element is described with a different tag name. Further, when the history information is binary data, there is a method in which each information element is stored not only in its value but in a column of “type, value”.
[0059]
Each module that generates history information identifies information elements having the same meaning with the same information identifier. For example, the information element “job identification information” has the same meaning even if it is collected at any point from the start to the end of the job path as long as it is performed in the same print job.
[0060]
Depending on the system, the job name and the job requester name may have the same meaning from the start to the end of the job. For the information elements as described above, all log information storage modules use the same information element identifier such as jobid, jobname, or user.
[0061]
In the history information typed as described above, when these are integrated, the same information elements can be combined into one. The processing flow is shown in FIG. Hereinafter, the processing to be summarized will be described with reference to FIG.
[0062]
In the first embodiment, when adding information on a job determined to have been performed by the same print job in different history information to the reference job, it is not simply added, but already exists in the reference job information. List one information element. Then, an information element having an information element identifier is searched for each existing information element, and if there is a matching information element, it is deleted. Only the remaining information elements are added to the reference job information.
[0063]
In this embodiment, when there are overlapping information elements in two job information, the value of the reference job information is prioritized. However, the value of the reference job information may be overwritten with the value of the job information to be integrated. Also, when both values are compared, if they do not match, the user can select one value, or if they do not match, the user can specify which value to select in advance. Adopt the method.
[0064]
As described above, integrated job history information by detecting and merging duplicate information elements when information of jobs performed in the same print job existing in multiple history information is integrated Is simplified without losing information, and is easy to see when the user browses the data.
[0065]
[Fourth embodiment]
In the above description regarding the job identification information, it has been described that the identification information is necessarily embedded in the information fragment of the print job. However, depending on the data format of the job, it may not be embedded. Also, some subsystems that supply job information fragments may not be able to see the contents of job data.
[0066]
Further, the job transfer means between subsystems may not embed job data, and some subsystems that supply job information fragments may not be involved in job transfer.
[0067]
Hereinafter, processing for obtaining an identifier using a key will be described based on the configuration diagram of the printing system applied as an embodiment of the present invention in FIG. 11. The subsystem that has assigned the job identifier registers the identifier and a key pair that can search for the job in the job ID list holding unit. On the other hand, the subsystem that supplies the job information fragment passes a key for searching for the job to the job ID list holding unit and receives the corresponding identifier.
[0068]
Hereinafter, the difference between the “key for searching for a job” and the “identifier for identifying a job” will be described.
First, the “identifier for identifying a job” is such that a job is uniquely identified in the entire system during the time from generation to disappearance of the job.
[0069]
In general, in a printing system, a job is generated on, for example, a client PC, passes through various modules on the PC, and eventually, the job leaves the PC and is passed to the print server. It passes through the module, and further leaves the server PC and is delivered to the printing apparatus.
[0070]
On the other hand, a key is a value that can identify a job within a limited range of context. For example, if the OS assigns a number on the client PC, that is, the job ID to be assigned is limited to that PC, the job can be identified. However, this value cannot be used for job identification outside the client PC such as a print server or a printing apparatus. Depending on the OS, there is a case where the job cannot be identified only by restarting. In this case, the ID given by the OS on the Client PC is the key.
[0071]
When the job ID list holding unit operates on the client PC, the job ID list holding unit holds a pair of a key and a job identifier that is an ID numbered by the OS. Various modules that supply job information on the Client PC (for example, print applications, printer drivers, port drivers, print processors, etc.) obtain job identifiers that are valid throughout the entire system from the OS job ID. Can do.
[0072]
Hereinafter, an example of conveying a job between subsystems will be described. For example, in some network printing protocols, a job receiving side (such as a print server) passes an ID given when receiving a job to a job sending side (such as a print client).
[0073]
In this case, the job receiving side has the right to determine what value to use as the ID. Essentially, if an identifier is generated when a job is generated and the job cannot be identified from the same time as the generation of the job, subsystems involved in the initial generation of the job cannot generate job information. Cannot be embedded).
[0074]
Some job receivers return a value that allows only the job receiver to identify the job, that is, a value that cannot be identified by other subsystems. Depending on the print protocol, the data format of the job ID returned by the job receiving side may be determined. In this case, common information for identifying a job cannot be embedded in the entire system.
[0075]
Therefore, an identifier that can identify the job in the entire system is assigned separately. For example, a number may be assigned at the time of job generation. In this example, the key is an ID generated by a print server or the like.
[0076]
In this case, the ID on the transport protocol is useful in a limited context of “job transport between the subsystem A such as the client and the subsystem B such as the server”. Therefore, a job ID list holding unit is generated for the exchange between these times, and the job identifier taken over from the upstream of the job flow can be searched by using a valid ID between the job sending side and the receiving side as a key. .
[0077]
As described above, the job ID value introduced in the existing technology is a value useful in a limited context such as within the OS range in the client PC or between two parties. Since there are many such IDs in the existing technology, the ID is used as a “key” in the context, and an identifier that can identify the job in the entire system is searched from the key.
[0078]
In this example, “the job ID list holding unit is placed in the Cleint PC, and the job identifier can be searched in each module in the Cleint PC.” “The job ID list between the job sending side and the receiving side. A method of placing a holding unit and enabling a job identifier search between the two parties is exemplified. In this example, a job ID list holding unit is placed in each context.
[0079]
However, as another method, the job ID list holding unit can be placed outside each context so that it can be used in the entire system. For this purpose, for example, instead of an array of [key-identifier] pairs, [context-A key, context-B key, context-C key-identifier] Thus, it is only necessary to be able to bind the key for each context.
[0080]
Hereinafter, processing performed by the job generation subsystem and the job reception / monitoring subsystem will be described with reference to FIGS. 12 (a) and 12 (b). First, a process in which the job generation side subsystem stores a key / identifier pair in the job ID list storage unit will be described.
[0081]
When a job identifier is generated (step S41), a key that can identify the job by another method is determined within a limited context (step S42). The job identifier and key are notified to the job ID list holding unit (step S43). The job ID list holding unit stores the key / identifier pair (step S44), and the process ends.
[0082]
Next, processing in which the job receiving / monitoring subsystem returns an identifier that matches the key will be described. When the job information is acquired (step S51), a key that can be specified by another method if the job is within a limited context is determined (step S52).
[0083]
The key is sent to the job ID list holding unit, and a corresponding identifier is requested (step S53). The job ID list holding unit searches the ID list and returns an identifier that matches the key (step S54).
Hereinafter, processing for recognizing the time to erase will be described.
[0084]
Each subsystem holds a job identifier list. Each subsystem stores only necessary job identifiers in the course of processing a job, and an unnecessary identifier is generated when job information has been sent. This identifier may be discarded at an appropriate timing of the subsystem itself.
[0085]
As a means for the ID notification unit to notify each subsystem of information of [key]-[identifier], there is a method in which a subsystem that requires such information in advance registers itself as a notification destination, or There is also a method in which information is flowed to an unspecified number by predetermined means, such as broadcast / multicast on a network, and each subsystem picks up as much as necessary.
[0086]
Hereinafter, a process for assigning an identifier number (numbering process) will be described with reference to FIGS. First, this process will be described based on (a).
[0087]
A module that assigns a job identifier number, such as an application or a driver, passes the identifier and key to the ID notification unit (step S61). The ID notification unit notifies each subsystem of this key and identifier (step S62). Each subsystem that has received the key and identifier holds it by itself (step S63), and the process ends.
[0088]
Next, processing at the time of job information generation by the subsystem will be described based on (b). Based on the key of the target job, the corresponding identifier is extracted from the table held by itself (step S71). The job information is sent out, and the [key]-[identifier] of the job is deleted from its own table (step S72).
[0089]
Hereinafter, a method for the job history holding unit to determine the reception waiting time of the information fragment in arbitrary job information will be described. Here, it is assumed that the subsystem on the path through which the job passes supplies the job information fragment to the job history holding unit at various timings.
[0090]
FIG. 16 is a configuration diagram of a printing system applied as an embodiment of the present invention. Each subsystem sends a notification indicating the start to the job history holding unit α when the job is conveyed to itself. At this time, not only this notification but also a job information fragment regarding the start may be sent together.
[0091]
After performing job processing, the subsystem conveys the job to the subsystem in the next process.
When the subsystem starts job processing, it sends a Start notification to the job history information holding unit. The subsystem in the previous process sends a notification indicating that the job information fragment is not sent after the job transfer is completed. In the same manner as described above, a job information fragment regarding the end of its own job processing may be sent together.
[0092]
Similarly, the subsystem of the next process sends the job process to the next process after the job processing, and sends the End notification (and the job information fragment if necessary) to the job history holding unit. Some subsystems monitor from outside the job path without intervening in the job flow. In this example, it is assumed that there is a subsystem that monitors the printing apparatus.
[0093]
When this subsystem finds that a job has been generated (or received) at a point monitored by itself, it sends a Start notification and a supplemental job information fragment to the job history holding unit as described above. When the job disappears at that point, an end notification or supplemental job information fragment is sent to the job history holding unit.
[0094]
On the other hand, the job history holding unit accumulates Start-End and job information fragments associated therewith. If an end notification is received from one subsystem for an arbitrary job, but only a start notification is received from another subsystem, this job will survive on the system, and information fragments will be gathered in the future. There is a possibility that. In that case, the job is still open.
[0095]
When all subsystems that sent Start receive an End notification for the job, it is determined that no more information fragments for the job can be received on the system, the job information is closed, and the information fragments are merged. I do. In this way, even when various subsystems on the system supply job information fragments at various timings, it is possible to obtain accurate timing for collecting information fragments.
[0096]
FIG. 17 shows a flow of processing for the above processing. First, when a job is conveyed to Subsystem A, a notification indicating the start is sent to the job history holding unit, and job processing is started. When the job processing is completed, the job is transferred to Subsystem B, which is a subsystem in the next process.
[0097]
When the conveyance is completed, a notification indicating the completion is sent to the job history holding unit. On the other hand, Subsystem B to which the job has been conveyed sends a notification indicating the start to the job history holding unit, and starts processing the conveyed job.
[0098]
Similarly, when the processing is completed, the job is conveyed to a printing apparatus which is a subsystem of the next process. When the conveyance is completed, a notification indicating the completion is sent to the job history holding unit. On the other hand, in the printing apparatus to which the job is conveyed, when the conveyance is completed, the printing process is performed and the process is terminated.
[0099]
Also, in Subsystem X that does not participate in the job flow, when the conveyance of the job from Subsystem B to the printing device starts, the job history holding unit is notified of the start, and when all the processes in the system are completed, A notification indicating completion is sent to the job history holding unit.
[0100]
【The invention's effect】
As is clear from the above description, according to the present invention, job information stored in each module is integrated for a single print job, so that the user can obtain it by printing the result. This makes it easier for the user to obtain overall information about each print job than in the past.
[0101]
Further, by embedding the identification information in the print job, when integrating the print job information, there is a possibility that even if the job is performed in a different print job, it is determined that the job is performed in the same print job. As a result, the user can grasp more accurate job information.
[0102]
Further, when job information performed in the same print job existing in a plurality of history information is integrated, by detecting and merging overlapping information elements, the integrated job history information It is simplified without being lost, and it is easy to see when the user browses the data.
[0103]
  Also,Even if the job identifier cannot be directly read out, it can be retrieved and read out, so that the identifier can be surely read out and the print jobs can be collected more accurately.
[0104]
  Also,Since identifiers that are no longer necessary in the job history holding unit can be discarded, the job history holding unit can use the identifier storage area more efficiently.
[0105]
  Also,Since the subsystem can grasp the timing of grouping the jobs, each subsystem can group the jobs at an appropriate timing for grouping the jobs.
[Brief description of the drawings]
FIG. 1 is an overall configuration diagram of a first embodiment according to a printing system of the present invention.
FIG. 2 is an example of history information 12a stored in a driver 12, history information 21a stored in an additional service 21, and history information stored in a printing apparatus 30;
FIG. 3 shows the contents of a program that executes a processing operation in the first embodiment.
FIG. 4 is a flowchart showing an operation in the first embodiment.
FIG. 5 is an overall configuration diagram of a second embodiment according to the printing system of the present invention.
FIG. 6 shows an example of history information stored in each module in the second embodiment.
FIG. 7 is a flowchart showing the operation of each module in the second embodiment.
FIG. 8 is an overall configuration diagram of a third embodiment according to the printing system of the present invention.
FIG. 9 shows a program for executing processing operations in the third embodiment.
FIG. 10 is a flowchart showing the operation in the third embodiment.
FIG. 11 is a configuration diagram of a printing system applied as an embodiment of the present invention.
FIG. 12 is a flowchart showing processing in which a job generation subsystem stores a key and an identifier, and job reception / monitoring subsystem retrieves an identifier from a key.
FIG. 13 is a diagram illustrating a basic model of a print job, embedding in job data, and ID notification in a job transport unit.
FIG. 14 is a configuration diagram of a printing system applied as an embodiment of the present invention.
FIG. 15 is a flowchart showing processing for assigning identifier numbers and processing performed when job information is generated by a subsystem.
FIG. 16 is a configuration diagram of a printing system applied as an embodiment of the present invention.
FIG. 17 is a flowchart illustrating the start and end of a job by each subsystem in a job history holding unit.
[Explanation of symbols]
10 clients
11 Application
12 Driver
12a History information stored in the driver
12b History information stored in the driver
12c History information stored in the driver
13 Server communication
13a History information stored in server communication
13b History information stored in server communication
13c History information stored in server communication
20 server PC
21 Additional services
21a History information stored in additional services
21b History information stored in additional services
21c History information stored in additional services
30 Printing device
30a History information stored in the printing device
30b History information stored in the printing device
30c History information stored in the printing device
40 Job information history device
40a History information stored in the job information history device
40b History information stored in the job information history device
40c History information stored in the job information history device
A subsystem
B subsystem
C subsystem
X subsystem

Claims

ネットワーク上のクライアントの有する印刷データ生成部が印刷データを前記ネットワークを通じて送信して印刷する印刷システムであって、
印刷装置駆動部は、ドライバ履歴情報を記憶する第１の記憶手段を有し、
印刷装置は、前記印刷装置が行った印刷装置履歴情報を記憶する第２の記憶手段を有し、
印刷管理装置は、
前記第１の記憶手段が記憶するドライバ履歴情報と、前記第２の記憶手段が記憶する印刷装置履歴情報とを読み出す手段と、
前記読み出し手段によって読み出された前記ドライバ履歴情報および前記印刷装置履歴情報を記憶する第３の記憶手段と、
前記読み出された前記ドライバ履歴情報および前記印刷装置履歴情報のいずれかに含まれるデータに示される処理を選択し、基準の処理を決定する基準ジョブ決定手段と、
前記基準ジョブ決定手段によって決定された基準の処理とは別のデータで示される処理が、同一の印刷ジョブで行われているか否かを判断する判断手段と、
前記基準の処理を示すデータとは別の処理を示すデータを基準の処理を示すデータに追加し、また、前記基準の処理とは別のデータで示される処理が前記判断手段によって前記印刷ジョブで行われていると判断された場合に追加されるデータ追加手段と、
前記データ追記手段により追加され、１つの印刷ジョブのジョブ情報として統合された統合履歴情報を前記クライアントに転送する転送手段と、を有することを特徴とする印刷システム。A print system in which a print data generation unit of a client on a network transmits print data through the network and prints,
The printing apparatus driving unit has first storage means for storing driver history information,
The printing apparatus includes a second storage unit that stores printing apparatus history information performed by the printing apparatus,
The print management device
Means for reading out driver history information stored in the first storage means and printing apparatus history information stored in the second storage means ;
Third storage means for storing the driver history information and the printing apparatus history information read by the reading means;
A reference job determination unit that selects a process indicated by data included in any of the read driver history information and the printing apparatus history information, and determines a reference process;
Determining means for determining whether or not processing indicated by data different from the reference processing determined by the reference job determining means is performed in the same print job;
Data indicating a process different from the data indicating the reference process is added to the data indicating the reference process, and a process indicated by data different from the reference process is added to the print job by the determination unit. A data adding means to be added when it is determined that it is being performed;
And a transfer unit configured to transfer integration history information added by the data appending unit and integrated as job information of one print job to the client .

前記追加手段によって追加された別の処理を示すデータを、前記追加手段によって追加される前に格納されていた前記ドライバ履歴情報および前記印刷装置履歴情報のいずれか１つを削除する第１の削除手段を有することを特徴とする請求項１に記載の印刷システム。A first deletion that deletes any one of the driver history information and the printing apparatus history information stored before the data indicating another process added by the adding unit is added by the adding unit. The printing system according to claim 1, further comprising: means.

前記印刷データ生成部は、前記ネットワーク上および該ネットワークに接続される端末内で共通で、各々の前記印刷ジョブによって区別される識別情報を前記印刷データに組み込む識別情報組み込み手段を有し、The print data generation unit includes identification information incorporation means that is common in the network and a terminal connected to the network and incorporates identification information that is distinguished by each print job into the print data.
前記判断手段による判断の基準は、前記識別情報組み込み手段によって組み込まれた識別情報に基づくことを特徴とする請求項１又は２に記載の印刷システム。 The printing system according to claim 1, wherein a criterion for determination by the determination unit is based on identification information incorporated by the identification information incorporation unit.

前記印刷管理装置は、前記ドライバ履歴情報および前記印刷装置履歴情報のいずれか１つに含まれる１つの情報を構成する１つの要素である情報項目を削除する第２の削除手段を有し、The print management apparatus includes a second deletion unit that deletes an information item that is one element constituting one information included in any one of the driver history information and the printing apparatus history information,
前記判断手段によって判断される際に、前記ドライバ履歴情報の情報項目と前記印刷装置履歴情報の情報項目とが一致する場合、前記ドライバ履歴情報の情報項目および前記印刷装置履歴情報の情報項目のいずれか一方を前記第２の削除手段によって削除することを特徴とする請求項１から３のいずれか１項に記載の印刷システム。 If the information item of the driver history information and the information item of the printing device history information match when determined by the determining means, any of the information item of the driver history information and the information item of the printing device history information 4. The printing system according to claim 1, wherein one of the two is deleted by the second deleting unit.

前記ネットワークにはさらにサーバが接続され、前記サーバは前記印刷ジョブにおいて前記サーバがどのような処理を行ったかというサーバ履歴情報を記憶し、保存する第４の記憶手段を有し、A server is further connected to the network, and the server has fourth storage means for storing and storing server history information indicating what processing the server has performed in the print job,
前記読み出し手段は、前記第４の記憶手段が記憶するサーバ履歴情報をさらに読み出すことを特徴とする請求項１に記載の印刷システム。 The printing system according to claim 1, wherein the reading unit further reads server history information stored in the fourth storage unit.

前記ネットワークにはさらにサーバが接続され、前記第３の記憶手段は前記サーバ履歴情報をさらに記憶することを特徴とする請求項１に記載の印刷システム。The printing system according to claim 1, wherein a server is further connected to the network, and the third storage unit further stores the server history information.

前記ネットワークにはさらにサーバが接続され、前記基準ジョブ決定手段の選択の対象は前記サーバ履歴情報に含まれる任意の１つのデータに示される処理も含まれることを特徴とする請求項１又は３に記載の印刷システム。4. The server according to claim 1, wherein a server is further connected to the network, and the selection target of the reference job determination unit includes a process indicated by any one data included in the server history information. The printing system described.

前記ネットワークにはさらにサーバが接続され、前記第１の削除手段の削除の対象には前記サーバ履歴情報も含まれることを特徴とする請求項２に記載の印刷3. The printing according to claim 2, wherein a server is further connected to the network, and the server history information is also included in a deletion target of the first deletion unit. システム。system.

前記ネットワークにはさらにサーバが接続され、前記第２の削除手段による削除の対象には前記サーバ履歴情報に含まれる１つのデータを構成する１つの要素である情報項目も含まれることを特徴とする請求項４に記載の印刷システム。A server is further connected to the network, and an object of deletion by the second deletion unit includes an information item that is one element constituting one data included in the server history information. The printing system according to claim 4.

複数のサブシステムを有する印刷システムであって、A printing system having a plurality of subsystems,
該印刷システムは、各印刷ジョブを識別するジョブ識別子と、前記印刷システムの所定の範囲内で前記ジョブ識別子を検索するために用いられるキーとを対応づけて保存するジョブＩＤ一覧保持部を有し、 The printing system includes a job ID list holding unit that stores a job identifier for identifying each print job and a key used for searching for the job identifier within a predetermined range of the printing system in association with each other. ,
前記複数のサブシステムは、前記キーによって前記識別子を検索し、該識別子によって、前記印刷ジョブにおいて前記複数のサブシステム各々で行われるジョブである断片ジョブをまとめることを特徴とする印刷システム。 The printing system, wherein the plurality of subsystems retrieves the identifier by the key, and collects fragment jobs that are jobs performed in each of the plurality of subsystems in the print job by the identifier.

前記ジョブＩＤ一覧保持部は、前記ジョブ識別子を破棄する識別子破棄手段と、該破棄する時期を決める破棄時期決定手段と、をさらに有し、The job ID list holding unit further includes an identifier discarding unit that discards the job identifier, and a discarding time determining unit that determines the discarding time.
前記破棄する時期は前記複数のサブシステムの通知によって決定されることを特徴とする請求項１０記載の印刷システム。 The printing system according to claim 10, wherein the discarding time is determined by a notification from the plurality of subsystems.

前記複数のサブシステムは、該サブシステムにおける前記断片ジョブの開始と終了とを前記ジョブＩＤ一覧保持部に通知するジョブ開始終了通知手段をさらに有し、The plurality of subsystems further include job start / end notification means for notifying the job ID list holding unit of the start and end of the fragment job in the subsystem,
前記サブシステムは、前記ジョブ開始終了通知手段が前記断片ジョブの終了を通知してから、前記断片ジョブをまとめることを特徴とする請求項１０又は１１記載の印刷システム。 12. The printing system according to claim 10, wherein the sub-system collects the fragment jobs after the job start / end notification unit notifies the end of the fragment jobs.