(57)【要約】【課題】  印刷要求ファイルに基づく印刷プロセスをいずれかの印刷拠点の印刷処理装置のいずれかに分配して、効率よく印刷プロセスをそれぞれの印刷処理装置に分配させることである。【解決手段】  印刷注文サーバ１は、クライアント３、４から印刷要求を受信して、複数の印刷拠点５，６に配置される複数の印刷処理装置と通信可能である。そして、各印刷処理装置の処理能力が特定構造で定義されている能力情報ファイルを記憶するデータベース２を備える。さらに、クライアント３、４から複数の印刷プロセスが特定構造で定義されている印刷要求ファイルを受信したら、処理要求と記憶されているリストとを用いて、処理要求により定義されている処理プロセス毎に当該処理プロセスの処理を実行するプロセス処理装置を特定する。そして、処理プロセス毎の処理を実行するプロセス処理装置が特定されることに応じて記憶されるリストを更新することを特徴とする。【選択図】  図１
2007280017.tif 000002
【特許請求の範囲】
【請求項１】
端末装置と複数のプロセス処理装置を含む印刷システムにおけるサーバ装置であって、
プロセス処理装置の処理能力が定義されている能力情報と当該プロセス処理装置とを対応付けた情報を記憶する記憶手段と、
前記端末装置から複数の処理プロセスが定義されている処理要求ファイルを受信する受信手段と、
前記受信手段により受信された前記処理要求と記憶されているリストとを用いて、前記処理要求により定義されている処理プロセス毎に当該処理プロセスの処理を実行するプロセス処理装置を特定する特定手段と、
前記特定手段により処理プロセス毎の処理を実行するプロセス処理装置が特定されることに応じて、前記リストを更新する更新手段を有することを特徴とするサーバ装置。
【請求項２】
前記プロセス処理装置の処理能力が定義されている能力情報と当該プロセス処理装置とを対応付けた情報は、複数のプロセス処理装置を順位付けて管理しており、
前記特定手段は、前記順位に従って処理プロセス毎に当該処理プロセスの処理を実行するプロセス処理装置を特定し、
前記更新手段は、プロセス処理装置の順位を変更すべく更新することを特徴とする請求項１に記載のサーバ装置。
【請求項３】
前記記憶手段は、前記プロセス処理装置の処理能力が定義されている能力情報と当該プロセス処理装置とを対応付けた情報を、前記順位に従うリストとして記憶することを特徴とする請求項２に記載のサーバ装置。
【請求項４】
前記処理プロセスは、前記処理要求で指定された印刷データを収集して印刷する印刷プロセスと、該印刷プロセスで生成されるリソースを製本する製本プロセスとを含む複合プロセスであることを特徴とする請求項１乃至３のいずれか１項に記載のサーバ装置。
【請求項５】
前記処理要求は、印刷プロセスとリソースとの処理形態が定義されたジョブチケットであることを特徴とする請求項１乃至３のいずれか１項に記載のサーバ装置。
【請求項６】
前記能力情報ファイルは、各印刷処理装置で処理可能な印刷プロセスの能力値を示すテンプレートファイルであることを特徴とする請求項１乃至４のいずれか１項に記載のサーバ装置。
【請求項７】
端末装置と複数のプロセス処理装置を含む印刷システムにおけるサーバ装置におけるプロセス管理方法であって、
プロセス処理装置の処理能力が定義されている能力情報と当該プロセス処理装置とを対応付けた情報を記憶手段に記憶する記憶ステップと、
前記端末装置から複数の処理プロセスが定義されている処理要求ファイルを受信する受信ステップと、
前記受信ステップにより受信された前記処理要求と記憶されているリストとを用いて、前記処理要求により定義されている処理プロセス毎に当該処理プロセスの処理を実行するプロセス処理装置を特定する特定ステップと、
前記特定ステップにより処理プロセス毎の処理を実行するプロセス処理装置が特定されることに応じて、前記リストを更新する更新ステップと、
を有することを特徴とするプロセス管理方法。
【請求項８】
前記プロセス処理装置の処理能力が定義されている能力情報と当該プロセス処理装置とを対応付けた情報は、複数のプロセス処理装置を順位付けて管理しており、
前記特定ステップは、前記順位に従って処理プロセス毎に当該処理プロセスの処理を実行するプロセス処理装置を特定し、
前記更新ステップは、プロセス処理装置の順位を変更すべく更新することを特徴とする請求項７に記載のプロセス管理方法。
【請求項９】
前記記憶手段は、前記プロセス処理装置の処理能力が定義されている能力情報と当該プロセス処理装置とを対応付けた情報を、前記順位に従うリストとして記憶することを特徴とする請求項８に記載のプロセス管理方法。
【請求項１０】
前記処理プロセスは、前記処理要求で指定された印刷データを収集して印刷する印刷プロセスと、該印刷プロセスで生成されるリソースを製本する製本プロセスとを含む複合プロセスであることを特徴とする請求項７乃至９のいずれか１項に記載のプロセス管理方法。
【請求項１１】
前記処理要求は、印刷プロセスとリソースとの処理形態が定義されたジョブチケットであることを特徴とする請求項７乃至９のいずれか１項に記載のプロセス管理方法。
【請求項１２】
前記能力情報ファイルは、各印刷処理装置で処理可能な印刷プロセスの能力値を示すテンプレートファイルであることを特徴とする請求項７乃至１０のいずれか１項に記載のプロセス管理方法。
【請求項１３】
請求項７に記載のプロセス管理方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信媒体上に接続された端末装置から印刷要求を受信して、複数の印刷拠点に配置される複数の印刷処理装置と通信可能なサーバ装置のプロセス管理に関するものである。
【背景技術】
【０００２】
近年、印刷出版の専門ではない一般の企業あるいは個人が持つ原稿から短納期で小ロットの印刷を行うことの出来る、いわゆるオンデマンド印刷サービスというものがある。
【０００３】
具体的には、原稿の電子データと印刷注文内容を指示した指示書（ジョブチケット）をネットワークに接続されたサーバにアップロードし、それに従って印刷・製本を行うサービスである。
【０００４】
この背景には、インターネットなどを利用し原稿の電子データを簡単かつ高速に印刷製本業者へ送ることが出来る技術がある。
【０００５】
原稿（電子データ）のやり取りは高速で行うことが出来る一方で、印刷、製本などの製品の作成には出力の量に比例した時間がかかり、顧客の注文方法によっては印刷製本業者によって受注した依頼の負荷に大きな差が出る場合もある。
【０００６】
また、業者間の受注量の差は業者毎の品質（製品の品質、納期の早さ等）や設備の規模などで違いが出る。しかし、一つの業者が複数の印刷製本拠点を持っている、あるいは系列の業者と連携して受注出来る場合には印刷製本拠点間でバランスの取れた配分が行えることが望ましい。
【０００７】
このような大規模な業者の場合には印刷製本依頼を一つのネットワークサービスで受注するようなシステムを構築している。
【０００８】
例えば、インターネットにおけるWorld Wide Web等を利用し、全国どこからでも一つのホームページにおいて注文を受け、それぞれ注文者の地理的位置や注文内容に応じてバランスの取れた拠点配分を行う。
【０００９】
この印刷製本の電子注文システムを利用者の側から見ると、クライアントが原稿ページデータと印刷製本指示をサーバへアップロードし、印刷製本業者において製本物を作成することを依頼するシステムが考えられる。この際、両面指示等のレイアウト指示や製本指示のような印刷方法を指示する内容を印刷対象とは別の文書で保持し、印刷対象と対にしてサーバへ送信するということが行われている。
【００１０】
この指示内容を含む文書を指示書、あるいはジョブチケット（JobTicket）と呼んでいる。ジョブチケットの使用により、複雑となる指示内容を保存しておき同じ指示内容での印刷を容易に繰り返すことが可能となっている。また、同じ原稿データに対して違うジョブチケットを用いることにより異なる形態の出力が可能となる。
【００１１】
ところで、このようなオンデマンド印刷においては、大規模な印刷において用いられるオフセット印刷等の技術ではなく複写機やプリンタに用いられる電子写真方式の印刷技術が用いられるようになってきている。
【００１２】
この理由としては、電子写真技術の発達に伴う高速化および高画質化によってオンデマンド印刷に耐えられる実用性が出てきたこと、さらに電子写真方式の印刷装置のコストメリットが高いこと、が挙げられる。
【００１３】
印刷装置としては電子写真方式の装置は有効であるが、製本処理に関しては、専用の製本装置が別に必要とされる場合が多い。
【００１４】
電子写真プリンタは、近年、画像形成だけでなく、スキャナ、プリンタ、ファクシミリと言った個々の機能を組み合わせ一台の装置で様々な用途に利用できるいわゆるMFPとして構成されていることが普通になってきている。ここで、MFPはマルチ・ファンクション・ペリフェラル（複合機）である。
【００１５】
これらの機能の一部として給排紙系のオプションも存在し、簡易な製本処理も可能とはなってきているが、専用の製本装置に比べればまだ制限が多い。
【００１６】
また、ある程度の規模以上の印刷製本を行うに当たっては、印刷と製本を独立して行うほうが効率も良く、結果的にはコストダウンにつながると言う場合もある。
【００１７】
この結果、印刷製本拠点ごとでも、製本手段を持たない拠点、製本に特化した拠点、印刷製本を行うに当たってもMFPが提供する機能の範囲内のみと専用製本装置を持つ場合と多様な設備状況が出てくることになる。
【００１８】
したがって、利用者がアップロードしたジョブチケットの内容に従ってある一つの拠点へ処理を振り分ける場合には、そのジョブチケットに記載された処理を行うために十分な設備を持つ拠点を絞り込んで、その絞り込まれた拠点に振り分けることになる。
【００１９】
一方、ジョブチケットに記載された処理の全てが必ずしも全自動で行えるとは限らない。
【００２０】
この理由としては、拠点の設備状況、あるいは、印刷製本装置の技術上の限界等が挙げられる。技術上の制約に関してはコストとのバランスも関係する場合がある。いずれにしても、このような場合には、一部あるいは全ての処理について拠点のオペレータによる手作業で対応することになる。
【００２１】
例えば、印刷後に製本装置で製本処理を実行する際の作業などが代表的なものである。拠点への処理の振り分けはこのようなことも考慮に入れて行われる。
【００２２】
なお、下記特許文献１には、印刷オンデマンドサービスを全体的に改良する場合に、印刷プロバイダへの印刷注文を割り振る処理において、自動化するための課題が指摘されている。
【００２３】
また、ジョブチケットを扱う印刷処理システムとして、下記特許文献２が公開されている。なお、特許文献２では、ジョブチケット内の両面指定等を解析候補としないことが記載されている。これは、印刷拠点を人為的に決定することを示唆している。
【特許文献１】特開２００２−９９７９２号公報
【特許文献２】特開２００５−１６５７４６号公報
【発明の開示】
【発明が解決しようとする課題】
【００２４】
従来、処理の振り分けと拠点の選択は、各処理つまりジョブチケット単位で行われていた。
【００２５】
印刷および製本を行うジョブチケットを処理する拠点はジョブチケットに記載された印刷手段および製本手段の両方を持つ拠点である。
【００２６】
このようにジョブチケットを処理する拠点を選択することで、ジョブチケットに記載されている処理を行うことが出来る拠点を容易に選択することが可能となる。
【００２７】
しかし、そのためにはジョブチケットに記載され得る指示の内容を全て処理できるように、いずれかの拠点は、ジョブチケットにて指示された内容を全て実行可能な設備を用意しなければならない。
【００２８】
例えば、ジョブチケットに印刷と製本の指示が記載される場合にはいずれかの拠点が印刷装置と製本装置の両方を備えている必要があり、また、そのようなジョブチケットは常に該当する拠点へ振り分けられることになる。
【００２９】
さらに細かい例としては、印刷の詳細指示と製本の詳細指示が記載されるような場合、いずれかの拠点においては、全ての詳細指示に従うことが可能な印刷装置設備と全ての詳細指示に従うことが可能な製本装置設備の両方が必要ということになってしまう。
【００３０】
印刷製本拠点の設備をこのように維持することはコスト的には非現実的であり、ほとんど不可能といっても良い。
【００３１】
さらに、例え一部の拠点でこのような設備を整えることが可能であったとしても、一部の拠点のみ対応ということであれば、同種の印刷製本依頼がこれらの拠点に集中することになり、処理を分配する利点が得られなくなる。
【００３２】
この問題を解決する一つとして、ジョブチケットに記載される内容を制限するという手段が挙げられる。いずれの拠点でも処理不可能である指示の組み合わせや、設定をジョブチケット作成時、つまり利用者の注文時に禁止することで、処理できる拠点の選択肢を増やせるようにするのである。例えば、指示の種類をメニュー形式で選択させるだけに限定すれば、このような手段は容易に実現することが出来る。
【００３３】
しかし、このような限定的な受注手段では利用者のニーズに幅広く対応することができない。上記に対して逆に、一部の拠点のみが設備の拡充を図ったとしても、受注システムの変更なしには、それらに対応していくことが出来ないことも課題である。
【００３４】
現在、処理のワークフローを記述する形式のジョブチケットも存在している。このようなジョブチケットを利用することで、利用者は所望の印刷製本処理内容を柔軟に表現することが出来る。
【００３５】
このようなジョブチケットにおいてワークフローを構成している各処理はそれぞれ指示内容の粒度にばらつきがある。ある処理は詳細かつ具体的な指示内容が記載してあり、別のある処理は抽象的で大まかな指示内容しかないという具合である。
【００３６】
前者は拠点を含めシステムの自動化が容易であるが、予め決められた種類の処理しか記述できない。一方、後者は、自動化は困難であるが、人手による処理を前提とすれば非常に拡張性のある記述が可能である。
【００３７】
しかし、具体的な指示と抽象的な指示の両方が含まれるようなジョブチケットの場合には、これらを一括して処理することが出来るようなシステムの実現は困難である。
【００３８】
ジョブチケットを人手により解釈実行する拠点においては、このようなジョブチケットの具体的指示部分が実行可能であるかを人間が解釈しなければならず、自動的に拠点へ振り分けることは出来ない。
【００３９】
一方、ジョブチケットの具体的指示を自動で処理するようになっている拠点においては、抽象的な指示を処理することは出来ず、結局全てを人手により解釈実行しなければならなくなってしまう。このため、印刷製本依頼を適切に拠点へ振り分ける処理が非効率となってしまう。
【００４０】
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、印刷要求ファイル内の複数の印刷プロセスを複数の印刷処理装置のいずれかが処理可能な印刷拠点リストを作成することができる仕組みを提供することである。
【００４１】
また、作成された印刷拠点リストを参照して、印刷要求ファイルに基づく印刷プロセスをいずれかの印刷拠点の印刷処理装置のいずれかに分配して、効率よく印刷プロセスをそれぞれの印刷処理装置に分配できる仕組みを提供することである。
【課題を解決するための手段】
【００４２】
上記目的を達成する本発明のサーバ装置は以下に示す構成を備える。端末装置と複数のプロセス処理装置を含む印刷システムにおけるサーバ装置であって、プロセス処理装置の処理能力が定義されている能力情報と当該プロセス処理装置とを対応付けた情報を記憶する記憶手段と、前記端末装置から複数の処理プロセスが定義されている処理要求ファイルを受信する受信手段と、前記受信手段により受信された前記処理要求と記憶されているリストとを用いて、前記処理要求により定義されている処理プロセス毎に当該処理プロセスの処理を実行するプロセス処理装置を特定する特定手段と、前記特定手段により処理プロセス毎の処理を実行するプロセス処理装置が特定されることに応じて、前記リストを更新する更新手段を有することを特徴とする。
【発明の効果】
【００４３】
本発明によれば、印刷要求ファイルに基づく印刷プロセスをいずれかの印刷拠点の印刷処理装置のいずれかに分配して、効率よく印刷プロセスをそれぞれの印刷処理装置に分配できる。
【発明を実施するための最良の形態】
【００４４】
次に本発明を実施するための最良の形態について図面を参照して説明する。
【００４５】
＜システム構成の説明＞
〔第１実施形態〕
図１は、本発明の第１実施形態を示す印刷製本注文システムの全体構成を示すブロック図である。本システムは、印刷注文サーバ１が原稿の電子データと印刷注文内容を指示した指示書（ジョブチケット）をネットワークに接続されたサーバにアップロードし、それに従って印刷・製本サービスを行うシステム例である。なお、本システム例では、印刷注文サーバ１が１台で処理されるシステム例であるが、複数の印刷注文サーバ１が連携するようなシステムであっても、本発明を適用可能である。
【００４６】
図１において、１は注文および印刷を管理する印刷注文サーバである。なお、印刷注文サーバ１は、いわゆるＣＰＵ、ＲＯＭ、ＲＡＭ等を含む制御ボードを備え、入力デバイスであるキーボード、ポインティングデバイスを備える。
【００４７】
また、印刷注文サーバ１は、出力デバイスとして表示装置を備える。また、外部記憶装置を備え、各種のＯＳ、アプリケーションプログラム、各種のデバイスドライバを格納している。
【００４８】
また、印刷注文サーバ１は、ネットワーク通信を行うネットワークコントローラ等を備え、ネットワークに接続された各デバイスと各種のプロトコルで通信可能に構成されている。
【００４９】
２はデータベースで、印刷注文サーバ１と所定のインタフェースを介して接続されている。データベース２は、クライアントからの印刷注文内容を記録している。
【００５０】
３、４は注文を行う端末機を示すクライアントである。クライアント３，４はいわゆるＣＰＵ、ＲＯＭ、ＲＡＭ等を含む制御ボードを備え、入力デバイスであるキーボード、ポインティングデバイスを備える。
【００５１】
また、クライアント３，４は、出力デバイスとして表示装置を備える。また、外部記憶装置を備え、各種のＯＳ、アプリケーションプログラム、各種のデバイスドライバを格納している。
【００５２】
また、ネットワーク通信を行うネットワークコントローラ等を備え、ネットワークに接続された各デバイスと各種のプロトコルで通信可能に構成されている。
【００５３】
５、６は印刷および製本処理を行う印刷拠点である。印刷拠点５、６には、仕様の異なる印刷処理装置や製本装置が配置されており、印刷注文サーバ１は、１つの印刷依頼を分配して、各印刷拠点に送る。印刷拠点は、それぞれの印刷要求を処理することで、１つの印刷結果を得ることができる。なお、分配処理がなされないこともある。
【００５４】
７は印刷注文サーバ１とクライアントをつなぐネットワークである。８は印刷注文サーバ１と印刷拠点５および印刷拠点６をつなぐネットワークである。
【００５５】
また、印刷拠点５、６には、いわゆるプリント処理を行う印刷処理装置、製本処理を行う製本装置等が備えられている。
【００５６】
印刷注文サーバ１は、クライアント３あるいはクライアント４からの印刷、製本注文を受けてデータベース２へ注文内容を記録し、その注文内容に従った出力が得られるよう印刷拠点５、６等に対して指示を出す。
【００５７】
印刷注文サーバ(印刷サービス)の利用者は、ネットワーク７に接続されたクライアント３あるいはクライアント４を端末として利用する。そして、所望のドキュメントファイル(電子データ)とその出力形態(印刷方法、製本方法)を示す指示を印刷注文サーバ１へ送ることにより、出力物を得ることが出来る。
【００５８】
なお、利用者が印刷注文サーバ１への注文を行うにあたって、図１におけるクライアント３を端末としても、クライアント４を端末として使っても構わない。複数の利用者が異なる時間において同一の端末を利用することも可能である。
【００５９】
しかし、以降の説明上の便宜のためクライアント３とクライアント４にはそれぞれ別の利用者が対応し、同じ利用者は決まった１つの端末を利用するものと考える。
【００６０】
図１に示す印刷製本注文システムにおいて、利用者は自分の注文が実際にどの印刷拠点に処理分配されるかについて意識しない。
【００６１】
また、利用者からの印刷注文は印刷注文サーバ１によって適切に１つ以上の印刷拠点へ分配され、最終的に注文の製品（印刷製本結果）が利用者のもとへ届くという運用になっているものとする。
【００６２】
なお、印刷注文サーバ１は、以下の特徴的構成を備える。
【００６３】
印刷注文サーバ１は、通信媒体上に接続された端末装置に対応すべくクライアント３、４から印刷要求を受信して、複数の印刷拠点に配置される複数の印刷処理装置と通信可能に構成されている。
【００６４】
そして、印刷拠点５、６に配置される各印刷処理装置の処理能力が特定構造で定義されている能力情報ファイルを記憶するデータベース２を備える。また、クライアント３、４から複数の印刷プロセスが特定構造で定義されている印刷要求ファイルを受信する。そして、クライアント３、４から受信された前記印刷要求ファイルと記憶されている各能力情報ファイルとを比較して、各印刷プロセスを前記複数の印刷処理装置のいずれかが処理可能な印刷拠点リストを後述する図１９に示す手順に従って作成する。
【００６５】
また、印刷注文サーバ１は、図１９に示す手順に従い作成れた印刷拠点リストに基づいて、各印刷プロセスを複数の印刷処理装置のいずれかに分配する。
【００６６】
さらに、印刷注文サーバ１は、作成された印刷処理装置と印刷プロセスとを含む印刷拠点リストをデータベース２に保存する。
【００６７】
なお、本実施形態において、印刷プロセスは、前記印刷要求ファイルで指定された印刷データを収集して印刷する印刷プロセスと、該印刷プロセスで生成されるリソースを製本する製本プロセスとを含む複合プロセスである。
【００６８】
また、印刷要求ファイルは、図１３に示す特定構造で定義されているように印刷プロセスとリソースとの処理形態が定義されたジョブチケットである。
【００６９】
さらに、能力情報ファイルは、図１４に示す特定構造で定義されている各印刷処理装置で処理可能な印刷プロセスの能力値を示すテンプレートファイルである。
【００７０】
なお、本実施形態における説明においては、分配された処理のための印刷拠点間の物流および利用者までの物流に関しては詳細な説明を省略する。
【００７１】
処理内容が分配された後にはその処理内容に従って適切に必要な物流が介在するものとする。
【００７２】
次に、本実施形態における印刷指示情報の指定および印刷注文サーバ１が利用者の指示内容つまり注文内容の処理を印刷拠点へ振り分ける処理に関する詳細について説明する。
【００７３】
＜ワークフローの表現と拠点の処理能力の表現＞
図２、図３は、図１に示した印刷製本注文システムにおける第１のワークフローを説明する図である。本例は、印刷製本指示の例を示すと同時に、ワークフロー指示に対する本実施形態の構造表現方法の定義も示すものとする。以後、同じ表現用途において断り無く同じ表現方法を用いるものとする。
【００７４】
図２は本文と表紙をそれぞれ別に印刷し、最後にくるみ製本を行うことを示している。
【００７５】
ここで「くるみ製本」とは、印刷された本文の用紙束の背に糊をつけ、表面に表表紙、背表紙、裏表紙が並べて印刷された表紙用の用紙でくるみ込む簡易的な製本方式を示すものである。
【００７６】
図２または図３において、１００、１０１、１０２、１０３、１１２、１１３、１１８で示されている角が丸い四角はリソースを表している。
【００７７】
リソースは印刷製本のワークフロー上、処理に使用される物理的あるいは仮想的な材料やデータなどに対応する資源である。
【００７８】
また、１０８、１０９、１１６で示されている角が丸くない四角はプロセスを表している。プロセスは印刷製本のワークフロー上、処理そのものを表している。
【００７９】
さらに、１０４、１０５、１０６、１０７、１１０、１１１、１１４、１１５、１１７はプロセス間におけるリソースの流れを示している。
【００８０】
リソースおよびプロセスに関するワークフローの構造表現方法について更に詳しく説明する。
【００８１】
図２において、リソース１００は印刷のためのプロセス１０８の入力となるデータを表している。リソース１００は、２段で「本文データ」と「データ」と記載してある。
【００８２】
これは、リソース１００の目的として本文の印刷用データであることを上段で示し、リソースの種類がデータであることを下段で示している。
【００８３】
つまり、本実施形態におけるワークフローの構造表現においてはリソースの目的と種類を表現している。
【００８４】
リソースに目的と種類がある理由は、リソース１１２とリソース１１３を見ると分かりやすい。
【００８５】
リソース１１２とリソース１１３はいずれも同じ「印刷」というプロセスの処理の結果得られたリソースである。
【００８６】
したがって、どちらも同じく印刷された「紙」であるが、プロセス１１６の「くるみ製本」と言う処理の入力として考えると、それぞれ異なった用途に使用されることが分かる。
【００８７】
つまり、「本身」と「表紙」であるため、リソース１１２では目的として「本身」、種類は「紙」、リソース１１３では目的として「表紙」、種類は「紙」、と表現されている。
【００８８】
リソースの種類はプロセスの種類、処理の内容によって決まっているが、リソースの目的はプロセスやワークフローの構成によって変わってくる。したがって、印刷注文サーバ１のような処理の振り分け、特に自動処理を行う際にはリソースの種類のみに着目する。
【００８９】
しかし、プロセス１１６のように同じ種類の異なるリソースを複数入力とする場合には、リソースの種類（例えば「紙」）だけではどの目的に適用されるリソースであるかの区別がつかなくなる。
【００９０】
例えば、プロセス１０８とプロセス１１６を合わせた機能を持つプロセスに相当する処理を考える。
【００９１】
これは例えば、本文データを印刷した後に別途入力された表紙用の用紙を使用してくるみ製本を行うと言うような処理である。
【００９２】
このような処理を図２の示すワークフローの構造の中でリソースの種類だけで組み合わせて考えると、プロセス１１６をプロセス１０８と組み合わせたのか、プロセス１１６をプロセス１０９と組み合わせたのかの区別がつかなくなる。
【００９３】
このため、プロセス１０８とプロセス１１６を組み合わせたプロセスに相当する処理については次のように定める。
【００９４】
まず、プロセス１０８とプロセス１１６を合わせた機能が、実際にプロセス１０８とプロセス１１６の組合わせによって実現される場合には、プロセス１０８とプロセス１１６を合わせた機能というものは定義しない。
【００９５】
具体的には、印刷拠点の処理能力としてはあくまでも「印刷」と言うプロセスと「くるみ製本」と言うプロセスがそれぞれ存在するものとする。そして、プロセス１０８とプロセス１１６を合わせたプロセスは存在しないものとする。
【００９６】
また、実際にプロセス１０８とプロセス１１６の組合わせに相当する機能が一つの装置あるいは手順として存在し、それらの処理が不可分な場合がある。この場合には、「印刷」プロセスでも「くるみ製本」プロセスでも、またそれらの組み合わせと言うことでもなく、全く別の「くるみ製本付印刷」プロセスというものを定義し、図２に示すワークフローとは区別をする。
【００９７】
印刷拠点の処理能力としては、「くるみ製本付印刷」を持っていたとしても、それは図２のワークフローに該当する処理能力を持っていることにはならない。
【００９８】
図４は、図１に示した印刷製本注文システムにおける第２のワークフローを説明する図である。なお、図２と同一のものには同一の符号を付してある。
【００９９】
本例は、「くるみ製本付印刷」プロセスの場合のワークフロー構造表現を示した例である。
【０１００】
このようにすることで、印刷拠点の処理能力に応じた処理の振り分けを自動で行うことが容易になる。
【０１０１】
次に図２、図３を元に、印刷注文サーバ１が印刷拠点の処理能力に応じた処理の振り分けを自動で行うためにワークフローを簡略的に解釈するための構造への対応について説明する。
【０１０２】
図２において、ワークフローはリソースとプロセスによる有向グラフで表現されている。
【０１０３】
図２において、１１９は、プロセス１１６の「くるみ製本」の定義に着目した範囲を示している。
【０１０４】
そして、図３は、図２に示した範囲１１９を抜き出したものである。１１６は「くるみ製本」と言うプロセスを表しているが、実際にはどのようなリソースをどのような目的で入力とし、どのようなリソースを出力するか、までの情報を含めてプロセス１１６の処理内容は定義される。したがって、プロセス１１６の処理内容は図３で示す範囲まで含めて解析する必要がある。
【０１０５】
ここで、図３に相当する図の略記方法を導入する。
【０１０６】
図５は、図３に示したプロセスとリソースの種類に注目して一つの図形で表現する図である。
【０１０７】
図５において、１２１はプロセスを表し、図３に示したプロセス１１６の「くるみ製本」を表している。
【０１０８】
更に１２２と１２３はリソースで、プロセス１２１が「紙」と言う種類の二つのリソース１２２と１２３を入力とし、「製本」という種類のリソース１２４を出力とすることを示している。
【０１０９】
この表現では種類が同じ場合、異なる目的のリソースの区別がつかないが、図５の構造表現は印刷注文サーバ１における処理の振り分けの判断に使用するものである。
【０１１０】
また、複数のプロセスを一つの機能として見せる場合には異なるプロセス名で表現するため、リソースの目的は区別できなくても問題は無い。
【０１１１】
なお、発注元であるユーザおよび実際に処理を行う印刷拠点においては、リソースの目的も含めて判断する必要があるため、この略記構造では判断しない。
【０１１２】
図５に示すプロセスの構造表現を用いると、図２に示したワークフローは、図６に示す表記で示すことができる。
【０１１３】
図６において、１２５と１２６はそれぞれ異なる印刷処理（プロセス）を表している。図６では印刷処理１２５と印刷処理１２６の処理目的の違いは表現されていない。なお、１２８、１３０はリソースで、データを示し、１２９、１３１はリソースで、用紙を示す。
【０１１４】
そして、くるみ製本１２７では印刷処理１２５と印刷処理１２６の出力結果、つまり紙１３２と紙１３３の紙を入力して、くるみ製本処理１２７を行っていることを表している。
【０１１５】
ここで、入力１３２および１３３がどの目的に使用されているかは表していないが、くるみ製本の出力結果として製本１３４が得られている。
【０１１６】
なお、図６におけるワークフローでは３つのプロセス１２５、１２６、１２７が記述されているが、その処理の種類は２つであることが分かる。つまり、「印刷」と「くるみ製本」である。ここで、ワークフローの構造表現を抽象化するためにプロセスとリソースを記号で置き換えてみる。
【０１１７】
図７は、図６に示したプロセスを置換表記した図である。つまり、図６において使用されている２種類のプロセスを、同じプロセス同士、同じリソース同士を同じ記号で置き換えて表したものである。
【０１１８】
図７において、１３５は図６に示した「印刷」に相当するプロセスであり、記号としてP1を使用している。
【０１１９】
１３６は図６に示した「データ」に相当するリソースであり、記号としてR1を使用している。１３７は図６に示した「用紙」に相当するリソースであり、記号としてR2を使用している。
【０１２０】
１３８、１４０、１４１は図６に示した(印刷された)「紙」に相当するリソースであり、記号としてR3を使用している。１３９は図６に示した「くるみ製本」に相当するプロセスであり、記号としてP2を使用している。１４２は図６に示した「製本」に相当するリソースであり、記号としてR4を使用している。
【０１２１】
以後、印刷注文サーバ１の振り分け処理を説明するため、この記号による抽象表現を用いる。つまり、Pで始まりそのあとに数字が続く記号はプロセスを表し、Rで始まりそのあとに数字が続く記号はリソースの種類を表している。そして、同じ記号は同じ種類のプロセスあるいは同じ種類のリソースを表す。例えば、この記述規則にしたがって図６を表現し直すと、図８のようになる。
【０１２２】
図８は、図６に示したワークフローの他の表記例を示す図である。図８に示すワークフローからリソースの種類を省略した簡略記法として、図９に示すような表現を用いることとする。
【０１２３】
図９は、図８に示したワークフローの簡略表記例を示す図である。本例は、図６、図２に対応するものである。図９と図２の対応を考えた場合、図９において１４３、１４４は、図２におけるプロセス１０８およびプロセス１０９に対応し、１４５はプロセス１１６に対応する。
【０１２４】
ここで簡略記法を使用してもう一つの例を示す。
【０１２５】
図１０は、図４に示したワークフローの構造表現を簡略記述した図である。
【０１２６】
図４におけるプロセス１２０は、図２におけるプロセス１０８とプロセス１１６の処理を合わせたもの相当ということであったが、全く異なるプロセスとして扱うため、図１０と図９は異なる構造となる。
【０１２７】
また、図１０における、プロセス１５３は図９においても使用しているプロセスP1であるが、プロセス１５４は図９では使用されていないプロセスであることを示すためにP3と表記している。
【０１２８】
図１０と図４との対応を考えた場合、図１０において、プロセス１５３は図４におけるプロセス１０９に対応し、プロセス１５４はプロセス１２０に対応する。
【０１２９】
＜ワークフローの構造および表現の違いと印刷製本処理の差異＞
以下、構造の区別について更に詳細な例で説明をする。
【０１３０】
図１１は、本実施形態における印刷製本注文システムの複合プロセスの構造を説明する図である。
【０１３１】
本例は、同じ処理結果を得ることになるワークフローを複数のプロセスを１つで実現できる異なる複合プロセスでそれぞれ置き換えた場合のワークフロー構造の違いを示す例である。
【０１３２】
図１１において、１５５、１５６、１５７は置き換える前の元となるワークフローのプロセスを表している。つまり、プロセス１５７は、プロセス１５５の出力とプロセス１５６の出力を入力として処理を行うという構造である。
【０１３３】
これに対して、図１１のプロセス１５８とプロセス１５９は２つの異なるプロセスの置き換えを示している。
【０１３４】
プロセス１５８およびプロセス１５９で示されるワークフローは元のワークフローのプロセス１５５とプロセス１５７の処理を一つのプロセス１５９で置き換えたものである。
【０１３５】
一方、プロセス１６０およびプロセス１６１で示されるワークフローは同じ元のワークフローの一部を複合プロセスで置き換えたものであるが、こちらは、プロセス１５６とプロセス１５７の処理を１つのプロセス１６１で置き換えている。
【０１３６】
プロセス１５９もプロセス１６１も簡略記法では同じプロセスＰ１からプロセスＰ２へのワークフローを統合した処理となっているが、実際には異なる目的のＰ１からの入力を統合しているため、統合後のプロセスは入力の目的も処理内容も異なっている。よって、図１１では、プロセス１５９をＰ３、プロセス１６１をＰ４と表現して別のプロセスであることを示している。
【０１３７】
従って、簡略記法においても、プロセス１５８とプロセス１５９のワークフローとプロセス１６０とプロセス１６１のワークフローは異なる構造を持つことを示すことが出来ている。
【０１３８】
次にこの構造の違いが印刷拠点への処理分配にどのような影響を与えるかについて説明する。
【０１３９】
図１２は、本実施形態における印刷製本注文システムの印刷製本注文内容に対する印刷拠点の対応の一例を示す図である。なお、印刷拠点は拠点毎にワークフローにおけるプロセスを単位としてその処理能力を定義している。つまり、その拠点はどのプロセスを処理することが出来るかをそれぞれ定義している。
【０１４０】
図１２において、１７０、１７１、１７２はそれぞれ注文内容を示すワークフローの例を示している。また１７３、１７４、１７５はＡ、Ｂ、Ｃという印刷拠点の例を示している。図１２は各注文内容をそれぞれの印刷拠点がその拠点内でワークフローの全てを処理できるか否かを示している。
【０１４１】
図１２において示す、注文内容のワークフロー１７０、１７１、１７２はいずれも図１１に示すワークフローと同じものを示しており、同一のプロセスに対しては同じ番号を付している。
【０１４２】
つまり、１７０、１７１、１７２はいずれも同じ製本を意図して異なるプロセスによる指示がされたワークフローである。
【０１４３】
しかし、図１２からは印刷拠点が持つ処理可能プロセスの種類のばらつきにより、同じ製本に対してもその指示ワークフローが異なることにより、一つの印刷拠点内で全て処理が可能なワークフローが異なることが見て取れる。
【０１４４】
例えば、印刷拠点Ａ（１７３）では矢印１７６が示すように、ワークフロー１７０だけがその拠点内だけで処理できるものである。
【０１４５】
ワークフロー１７１やワークフロー１７２で示される指示の一部であるＰ１プロセスであれば、印刷拠点Ａの中で処理可能であるが、Ｐ４やＰ３のプロセスは処理が出来ない。
【０１４６】
Ｐ４やＰ３のプロセスが行うべき処理内容自体はＰ１とＰ２の組み合わせである。このため、印刷拠点Ａにおいても相当する処理を行うことが可能であるが、本実施形態においては印刷注文サーバ１が自動で印刷拠点に振り分けることを目的としているため、これらのプロセスの違いについては明確に区別するものとする。
【０１４７】
同様に印刷拠点Ｂ（１７４）ではワークフロー１７０と１７２が、印刷拠点Ｃ（１７５）ではワークフロー１７１がその印刷拠点内で処理可能である。
【０１４８】
しかし、部分的にでも処理できるプロセスで選択するとすれば、印刷拠点Ａ、Ｂ、Ｃは、ワークフロー１７０、１７１、１７２いずれについても部分的に処理可能である。これは、どの印刷拠点もプロセスＰ１を処理することが可能であり、ワークフロー１７０、１７１、１７２いずれもプロセスＰ１を含んでいるからである。
【０１４９】
＜ジョブチケットと印刷拠点の処理能力の表現＞
次にジョブチケットとテンプレート情報について詳しく説明する。
【０１５０】
図１３は、本実施形態における印刷製本注文システムの印刷製本注文内容の一例を示す図である。本例は、ジョブチケットの一例であり、図１２におけるワークフロー１７０、更に具体的には図２に示すワークフローを表すジョブチケットに対応する。
【０１５１】
本実施形態におけるジョブチケットはSGMLやXMLなどに代表されるマークアップ言語を利用したテキストドキュメントの形式をとっている。
【０１５２】
ただし、本実施形態の説明に必要な部分のみの表現を用いており、SGMLやXML等の仕様に厳密に従ったものではない。また、本実施形態において、図１３に示すジョブチケットは５２行から成り立っている例である。
【０１５３】
図１３において、１行目の＜JobTicket＞はジョブチケットの記述の開始を意味する。これに対応する表現として、５２行目の＜/JobTicket＞はジョブチケットの記述の終了を意味する。２〜５１行目は具体的な指示を表すものである。
【０１５４】
図１３のジョブチケットは複数のリソースとプロセスの記述から成り立っている。
【０１５５】
１つのリソースの記述は＜Resで始まる行から開始し＜/Res＞の行までで完結している。図１３に示すジョブチケットにおいては、例えば１０個のリソースが記述されている。
【０１５６】
１つのプロセスの記述は＜Procで始まる行から開始し＜/Proc＞の行までで完結しており、図１３においては３つのプロセスが記述されている。
【０１５７】
次にリソースとプロセスについて記述を一つずつ説明していく。
【０１５８】
１つ目のリソースは２行目から５行目までに記述されている。本実施形態におけるジョブチケットではリソースの記述を示すResタグにtypeとidという属性をつけられている。typeはリソースの種類を表し、印刷注文サーバ１と印刷拠点が扱うリソースごとに決められた値を指定できる。
【０１５９】
２行目においてtype属性は"data"という値を持っている。これはこのリソースが印刷の元となる原稿データであることを示している。idはジョブチケットの中でリソースを一意に識別するための識別子を表し、他のリソースのid属性値と重複しない値を指定するようにする。
【０１６０】
２行目においてid属性は"id0001"という値を持っている。以後、id0001によってこのリソースを識別する。リソースの記述は入れ子をしてリソースごとのパラメータを記述する。id0001のリソースについては３行目から４行目が対応する。
【０１６１】
図１３においては表示上の都合で改行し２行で記述しているが、３行目と４行目の記述は＜Paramsから/＞までが一続きのパラメータ記述である。パラメータの内容はリソースの種類によって記述する項目が異なり、またリソースごとに設定内容も異なる。
【０１６２】
リソースのパラメータはジョブチケットにおける指示の詳細に当たる。id0001では、例えば６つの属性値をリソースのパラメータとして指定している。
【０１６３】
fileNameは原稿データのファイル名を表し、ここでは"body.pdf"という値が指定されている。typeは原稿データのファイルフォーマットを表し、"pdf"という値はbody.pdfがＰＤＦフォーマットであることを示しているものとする。
【０１６４】
pagesは原稿データとして使用されるページ数を表し、ここでは１００ページが指定されている。pageRangeは原稿データの中から使用されるページの範囲を表し、ここでは０ページ目から９９ページ目までを示す"0~99"という値が指定されている。pageSizeとpageSizeUnitで原稿データのページサイズを表す。
【０１６５】
pageSizeが大きさ、pageSizeUnitはpageSizeが表す大きさの単位を表す。id0001では横210mm、縦290mmの大きさを示している。以上がid0001のリソースの記述である。ちなみに、id0001のリソースは図２に示したリソース１００に対応する。
【０１６６】
２個目のリソースは６行目から９行目までに記述されている。１つ目のリソースと同じく原稿データのリソースであり識別子はid0002である。ファイル名はcover.tifでＴＩＦＦフォーマットであるものとする。ページ範囲は０ページ目のみで、ページ数は省略されている。ページサイズは横422mm、縦290mmである。リソースid0002は図２に示したリソース１０２に対応する。
【０１６７】
３個目のリソースは１０行目から１２行目までに記述されている。type属性値は印刷メディアを表す"media"である。識別子はid0003である。"media"リソースは３つのパラメータを記述する。
【０１６８】
メディアの種類を示すtypeはid0003においては"paper"であり普通紙を表している。sizeとsizeUnitで用紙の大きさを指定している。表記方法は原稿データのページサイズと同じであり210mm×290mmを指定している。リソースid0003は図２における１０１に対応する。
【０１６９】
４個目のリソースは１３行目から１５行目までに記述されている。タイプ属性は、印刷メディアであり、識別子はid0004である。普通紙で422mm×290mmの大きさを指定している。リソースid0004は図２に示したリソース１０３に対応する。
【０１７０】
５個目のリソースは１６行目から１８行目までに記述されている。タイプ属性は、印刷メディアであり、識別子はid0005である。普通紙で422mm×290mmの大きさを指定している。リソースid0005は図２に示したリソース１１２に対応する。
【０１７１】
６個目のリソースは１９行目から２１行目までに記述されている。タイプ属性は、印刷メディアであり、識別子はid0006である。普通紙で422mm×290mmの大きさを指定している。リソースid0006は図２に示したリソース１１３に対応する。
【０１７２】
７個目のリソースは２２行目から２４行目までに記述されている。type属性値は製本された本を表す"bindbook"である。識別子はid0007である。このリソースは最終出力を表していることもあり、パラメータで指定される値は無い。リソースid0007は図２に示したリソース１１８に対応する。
【０１７３】
８個目のリソースは２５行目から２７行目までに記述されている。type属性値は、印刷（print）プロセスの指示パラメータを表す"printparam"である。識別子はid0008である。"printparam"リソースは２つのパラメータを記述する。
【０１７４】
amountは印刷部数を示し、ここでは、例えば部数が「１０」である。また、duplexは両面印刷の指示を選択しており、ここでは"yes"、つまり両面印刷することを指示している。リソースid0008は図２においては図示されていないが、プロセス１０８に含まれる内容である。
【０１７５】
９個目のリソースは２８行目から３０行目までに記述されている。type属性値はprintプロセスの指示パラメータを表す"printparam"である。識別子はid0009である。印刷部数は１０である。また、duplexは"no"、つまり両面印刷しないことを指示している。リソースid0009は図２においては図示されていないが、プロセス１０９に含まれる内容である。
【０１７６】
１０個目のリソースは３１行目から３３行目までに記述されている。type属性値はbindプロセスの指示パラメータを表す"bindparam"である。識別子はid0010である。
【０１７７】
"bindparam"リソースは2つのパラメータを記述する。amountは製本部数を示し、ここでは、例えば「１０」である。また、trimmingは製本後のトリミングを行うか否かの指示を選択しており、ここでは"yes"、つまりトリミングを行うことを指示している。リソースid0010は図２においては図示されていないが、プロセス１１６に含まれる内容である。
【０１７８】
図１３において、１つ目のプロセスは３４行目から３９行目までに記述されている。本実施形態におけるジョブチケットではプロセスの記述を示すＰｒｏｃタグにtypeとidという属性をつける。
【０１７９】
typeはプロセスの種類を表し、印刷注文サーバ１と印刷拠点が扱うプロセスごとに決められた値を指定するものとする。idはプロセスを識別するための識別子でありジョブチケットの処理が複数の印刷拠点に分配された場合に各印刷拠点がどのプロセスを処理するのかを識別するために使用される。プロセスの種類は、図１２におけるプロセス１５５、１５６、１５７で示されるＰ１やＰ２等に対応し、また印刷拠点の処理能力などを識別する際に使用する情報である。
【０１８０】
３４行目においてtype属性は"print"という値を持っている。これはこのプロセスが印刷プロセスであることを示している。
【０１８１】
またid属性は"pid01"という値を持っている。プロセスの記述は入れ子をしてプロセスごとに使用される入出力リソースを記述する。
【０１８２】
入出力リソースはそのプロセスが入力とするリソースと出力するリソースを同じジョブチケット内に記述されているリソースの識別子でid属性に指定する。
【０１８３】
また、入出力リソースはusage属性で各リソースの目的を記述する。プロセスpid01については３５行目から３８行目がこれに対応する。
【０１８４】
入力リソースは＜InputRes…/＞で記述され、出力リソースは＜OutputRes…/＞で記述される。
【０１８５】
３５行目はリソースid0001をプロセスpid01の入力リソースとすることを示しており、リソースid0001をpagedataつまり印刷原稿データとして使用することを示している。３５行目は図２における矢印１０４に対応する。
【０１８６】
３６行目はリソースid0003をプロセスpid01の入力リソースとすることを示しており、リソースid0003をpaperつまり印刷用紙として使用することを示している。３６行目は図２における矢印１０５に対応する。
【０１８７】
３７行目はリソースid0008をプロセスpid01の入力リソースとすることを示しており、リソースid0008をprintparamつまり印刷パラメータとして使用することを示している。
【０１８８】
３７行目は図２において図示されていないが、１０８のプロセスに含まれるものとする。３８行目はリソースid0005をプロセスpid01の出力リソースとすることを示しており、リソースid0005はprintpaperつまり印刷出力であることを示している。３８行目は図２における１１０で示す矢印に対応する。以上、プロセスpid01は図２におけるプロセス１０８に対応する。
【０１８９】
２つ目のプロセスは４０行目から４５行目までに記述されている。４０行目においてtype属性は"print"という値を持っている。これはこのプロセスが印刷プロセスであることを示している。また、id属性は"pid02"という値を持っている。４１行目はリソースid0002をプロセスpid02の入力リソースとすることを示しており、リソースid0002をpagedataつまり印刷原稿データとして使用することを示している。
【０１９０】
４１行目は図２における矢印１０６に対応する。４２行目はリソースid0004をプロセスpid02の入力リソースとすることを示しており、リソースid0004をpaperつまり印刷用紙として使用することを示している。
【０１９１】
４２行目は図２における矢印１０７に対応する。４３行目はリソースid0009をプロセスpid02の入力リソースとすることを示しており、リソースid0009をprintparamつまり印刷パラメータとして使用することを示している。
【０１９２】
４３行目は図２において図示されていないが、プロセス１０９に含まれるものとする。４４行目はリソースid0006をプロセスpid02の出力リソースとすることを示しており、リソースid0006はprintpaperつまり印刷出力であることを示している。４４行目は図２における示す矢印１１１に対応する。以上、プロセスpid02は図２における１０９のプロセスに対応する。
【０１９３】
３個目のプロセスは４６行目から５１行目までに記述されている。
【０１９４】
４６行目においてtype属性は"bind"という値を持っている。これはこのプロセスがくるみ製本プロセスであることを示している。
【０１９５】
また、id属性は"pid03"という値を持っている。４７行目はリソースid0005をプロセスpid03の入力リソースとすることを示しており、リソースid0005をbodyつまり印刷済み本身として使用することを示している。４７行目は図２における矢印１１４に対応する。
【０１９６】
４８行目はリソースid0006をプロセスpid03の入力リソースとすることを示しており、リソースid0006をcoverつまり表紙として使用することを示している。４８行目は図２における矢印１１５に対応する。
【０１９７】
４９行目はリソースid0010をプロセスpid03の入力リソースとすることを示しており、リソースid0010をbindparamつまり製本パラメータとして使用することを示している。
【０１９８】
４９行目は図２において図示されていないが、プロセス１１６に含まれるものとする。５０行目はリソースid0007をプロセスpid03の出力リソースとすることを示しており、リソースid0007はbookつまり製本出力であることを示している。５０行目は図２における１１７で示す矢印に対応する。以上、プロセスpid03は図２における１１６のプロセスに対応する。
【０１９９】
以上のように図１３に示すジョブチケットは図２のワークフローの構造と指示の詳細を含むように記述されている。
【０２００】
次に、図１２における印刷拠点Ａ（１７３）における処理可能プロセスＰ１、Ｐ２を印刷注文サーバ１が印刷拠点Ａの対応プロセスであることを識別するためのテンプレート情報について例を示して説明する。
【０２０１】
図１４は、本実施形態における印刷製本注文システムの印刷拠点の処理能力である対応プロセスの一覧を示すテンプレート情報の一例を示す図である。本例は、図１２における印刷拠点Ａ（１７３）のテンプレート情報に対応する。
【０２０２】
本実施形態におけるテンプレート情報はジョブチケットと同じくマークアップ言語を利用したテキストドキュメントの形式をとっている。ただし、ジョブチケットと同様に本実施例の説明に必要な部分のみの表現を用いる。本例は、図１４に示すテンプレート情報は４３行から成り立っている。
【０２０３】
なお、本実施形態において、テンプレート情報は、印刷注文サーバ１の外部記憶装置あるいはデータベース２内に更新可能に記憶されている。そして、印刷注文サーバ１がジョブチケットを受信した場合に、適時参照されて、後述するフローチャートの手順に従い印刷拠点の振り分け処理が実行される。
【０２０４】
図１４において、１行目の＜Template＞はテンプレート情報の記述の開始を意味する。これに対応する表現として、４３行目の＜/Template＞はテンプレート情報の記述の終了を意味する。２から４２行目は具体的な情報を表すものである。
【０２０５】
図１４のテンプレート情報は複数のプロセスの定義記述から成り立っている。１つの定義記述は＜Procで始まる行から開始し＜/Proc＞の行までで完結している。図１４のテンプレート情報においては２個の定義が記述されている。
【０２０６】
次にプロセスの定義記述を一つずつ説明する。
【０２０７】
１つ目のプロセスは２行目から２５行目までに記述されている。本実施形態におけるテンプレート情報ではプロセス定義の記述を示すProcタグにtypeという属性をつける。
【０２０８】
type属性値の一致するものが同じ種類のプロセスということになる。そこで、ジョブチケットの記述とテンプレート情報の記述でProcタグのtype属性値が一致すればジョブチケットのそのプロセスを、テンプレート情報を定義している印刷拠点が処理可能であることを表す。
【０２０９】
１つ目の定義記述はprintプロセスを定義している。プロセス定義の記述は入れ子をしてプロセスごとに使用される入出力リソースを記述する。プロセス定義における入出力リソースはジョブチケットと同じくInputRes、OutputResというタグを使用する。printプロセスでは３つの入力リソースと1つの出力リソースがあることが、記述されている。
【０２１０】
３行目から１０行目が一つ目の入力リソース、１１行目から１５行目が二つ目の入力リソース、１６行目から１９行目が三個目の入力リソース、そして２０行目から２４行目で一つの出力リソースがあることを定義している。
【０２１１】
入出力リソースのタグはtypeとusageという属性を持ち、それぞれ、リソースの種類、目的を定義する。一つのプロセスの定義の中ではリソースの種類と目的の組み合わせが一致する入出力リソースは存在できないものとする。
【０２１２】
これは、リソースの種類と目的の組み合わせによって、ジョブチケットの記述においてどのリソースのことを示しているのかを識別するためである。
【０２１３】
入出力リソースの記述はさらに入れ子でリソースごとに指定可能なパラメータを定義する。これは、その印刷拠点が処理可能な範囲を示すものでもある。
【０２１４】
pagedata目的のdataリソース（３行目）の場合には４行目から９行目までの６つのパラメータが定義されている。各パラメータの定義はデフォルト値（default属性）、値域（valid属性値）を持つ。デフォルト値はジョブチケットのリソース記述において、そのパラメータを示す属性が省略された場合に採用される値である。
【０２１５】
デフォルト値が定義されていない場合にはジョブチケットにおいてそのパラメータを省略できないものとする。値域はジョブチケットでそのパラメータの属性値に指定できる値の範囲を定義する。
【０２１６】
本実施形態においては一般的に文字列のパターンマッチングに利用される正規表現を用いることとする。４行目のfileNameは図１３における３行目あるいは７行目におけるParamsタグのfileName属性に対応する。デフォルト値はないので必ず指定しなければならない。属性値は任意（".*"で示されているため）である。
【０２１７】
以下、同様に図１４におけるタグ名と同名の図１３におけるParamsタグの属性を定義する。
【０２１８】
５行目のtypeは省略された場合PDFファイルであるものとする。また、type属性値に指定できるのは"pdf"、"TIFF"、"txt"のいずれかである。６行目のpagesには、デフォルトとして１ページを正の整数値を指定しなければならない。
【０２１９】
７行目のpageRangeのデフォルトは全ページで「〜」をはさんで整数値の組を指定する。値はページ番号を示し、負の値は最終ページからのページ番号を示すものとする。
【０２２０】
したがって、デフォルト値の０〜−１は先頭ページから最終ページまでで全ページ範囲を示す。８行目のpageSizeはスペースをはさんで数値の組を指定する。デフォルト値は無いため省略できない。
【０２２１】
９行目のpageSizeUnitのデフォルトは"pnt"であり"mm"、"cm"、"pnt"のいずれかから選択する。
【０２２２】
paper目的のmedia入力リソース、printparam目的のprintparam入力リソース、printpaper目的のmedia出力リソース、についても以下同様にパラメータを定義する。入出力リソースのtype属性値で定義されているリソースの種類はジョブチケットにおけるプロセス内から参照されているidに対応するリソースのtype属性値に一致していなければならない。
【０２２３】
２つ目のプロセスは２６行目から４２行目までに記述されている。一つ目のプロセスと同様のフォーマットにて、bindプロセスの定義を行っている。図１３における４６行目の＜Procで始まる記述に対応するプロセスの定義である。
【０２２４】
上記ジョブチケットの構造およびテンプレートの構造によれば、注文内容すなわちジョブチケットの記述内容として、注文内容の記述の柔軟性を損なわず、かつ受注サーバが注文の拠点分配を自動で処理できる。
【０２２５】
具体的には、図１３に示すように、ジョブチケットにおいてオフラインや人手による作業とデバイスにおける詳細な処理パラメータの混在を可能にし、かつ、設備の充実した拠点だけに処理が偏ることが無いように配分を行うことができる。
【０２２６】
＜ジョブチケットに対応できる印刷拠点の判断と処理の分配＞
以下、図１４に示した印刷拠点のテンプレート情報が図１３に示したジョブチケットの指定するプロセスに対応しているか否かを判断する処理について詳述する。
【０２２７】
図１５は、本実施形態における印刷製本注文システムの第１のデータ処理手順の一例を示すフローチャートである。本処理は、印刷注文サーバ１の受け取ったジョブチケットに含まれるプロセスをどの印刷拠点が処理可能であるかを判断する処理手順に対応する。また、本処理は入力としてジョブチケットを受け取り、出力として、ジョブチケット中のプロセスに対応できる拠点のリストを示すデータ構造を生成する処理である。なお、Ｓ３０１〜Ｓ３１５は印刷注文サーバ１のコントローラ部がメモリから制御プログラムをロードして実行される各ステップを示す。
【０２２８】
まず、図１３に示す構造で定義されているジョブチケットが読み込まれ＜Proc＞タグ単位でジョブチケットの木構造文書が走査される。
【０２２９】
なお、図１３や図１４に示すような階層構造の文書構造を持つファイルを走査する手段についてはＤｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌなど公知の技術により実現可能であり、本実施形態における詳細な説明は省略する。
【０２３０】
まず、ステップＳ３０１において、コントローラ部は、＜Proc＞タグ以下で示されるノードへ移動する。例えば図１３において最初の＜Proc＞タグの構造は３４行目に当たる。ここまでに同じレベルのノードとして＜Res＞タグで示されるノードが存在するが、＜Res＞タグ以下の情報については＜Proc＞タグを解析する過程で参照されるため、この時点では無視する。そして、ステップＳ３０２において、コントローラ部は、＜Proc＞のtype属性を読む。
【０２３１】
例えば図１３における最初の＜Proc＞タグでは"print"である。次にステップＳ３０３にて、コントローラ部は、図１４に示した構造で定義されている印刷拠点のテンプレート情報を１つ読み込み、解析を開始する。なお、印刷拠点のテンプレート情報を走査する元となるデータ構造については後述する。
【０２３２】
次に、ステップＳ３０４においてコントローラ部は、ステップＳ３０３で読み込んだテンプレート情報にステップＳ３０２で読んだtype属性値と同じtype属性値を持つ＜Proc＞ノードが存在するかを調べる。なお、各ステップにおいて読み込んだ値は一時的に記憶されているため、Ｓ３０４の処理が可能となる。図１３の最初の＜Proc＞タグでは"print"であり、図１４のテンプレート情報の２行目には＜Process type=“Print”＞と記述されている。よって、コントローラ部は、図１３と図１４を比較した場合、Ｓ３０４においてＹｅｓと判断する。ここで、存在すると判断した場合（Ｓ３０４−Ｙｅｓ）にはステップＳ３０５へ進み、存在しないと判断した場合（Ｓ３０４−Ｎｏ）にはステップＳ３１４へ進む。なお、Ｓ３０４にてＹｅｓと判定された場合、同じtype属性値を持つ＜Proc＞ノードが存在するということは、詳細はともかく指定されたジョブチケットの処理に必要なプロセスの処理能力をその印刷拠点が持っていることを意味する。一方、ステップＳ３０４で、ノードが存在しないと判断した場合には、その印刷拠点がそのプロセスの処理能力を持っていないことを意味する。
【０２３３】
ステップＳ３０５以降では更に細かい条件も含めて、その印刷拠点がジョブチケットに記載のプロセスを処理可能であるかを判断する。ステップＳ３０５において、コントローラ部は、テンプレート情報において該当する＜Proc＞ノード下のリソースのレベルのノードを順に走査していく。つまり、＜InputRes＞あるいは＜OutputRes＞というタグのレベルを調べる。
【０２３４】
次に、コントローラ部は、現在注目しているリソースのusage属性値を調べ、さらに、ジョブチケットの該当する＜Proc＞以下で同じ＜InputRes＞あるいは＜OutputRes＞で同じusage属性値を持つものを選択する（Ｓ３０６）。例えば、図１３における３４行目の＜Proc＞と図１４における２行目の＜Proc＞を調べた場合、図１４における３行目のusage属性値"pagedata"に一致するusage属性値を持つ＜InputRes＞は図１３における３５行目に存在する。
【０２３５】
ステップＳ３０６ではこのような一致する入出力リソースが見つかったと判断した場合（Ｓ３０６−Ｙｅｓ）にはステップＳ３０７へ進み、見つからなかった場合（Ｓ３０６−Ｎｏ）にはステップＳ３１４へ進む。
【０２３６】
そして、ステップＳ３０７において、コントローラ部は、ジョブチケット内で見つかった入出力リソースのid属性値を辿ってジョブチケット内のリソースの記述を見つける。
【０２３７】
例えば、図１３におけるジョブチケットの３５行目の例ではid属性値が"id0001"であるため、図１３における２行目が該当するリソースの記述である。
【０２３８】
次に、ステップＳ３０８において、コントローラ部は、テンプレート情報の入出力リソースのtypeとジョブチケットのリソースのtypeとを比較して一致するかどうかを判断する。
【０２３９】
具体的には、コントローラ部は、図１３における２行目のtype="data"と図１４における３行目のtype="data"を比較しどちらも同じ"data"であるため一致と判断する。
【０２４０】
ここで、ステップＳ３０８ではtypeが一致したと判断した場合（Ｙｅｓ）にはステップＳ３０９へ、不一致であると判断した場合（Ｎｏ）にはステップＳ３１４へ進む。
【０２４１】
ここからさらに、入出力リソースで指定されたパラメータが印刷拠点の処理可能範囲に入っているかを調べる。ステップＳ３０９では各パラメータについて走査している。
【０２４２】
図１４におけるテンプレート情報の３行目について判定する場合、図１４におけるテンプレートの４行目から９行目までをステップＳ３０９からステップＳ３１１を繰り返すことで調べていく。
【０２４３】
次に、ステップＳ３１０において、コントローラ部は図１３のジョブチケットにおいて属性で指定されているパラメータの値がテンプレート情報の指定する範囲に入っているかを調べる。なお、値が指定範囲に入っているか否かの判断には、図１４のテンプレート情報でdefault属性があり、ジョブチケットの該当属性値が存在しない場合にはデフォルト値として扱うため範囲内であるというものも含まれる。
【０２４４】
テンプレート情報でdefault属性がなく、ジョブチケットの該当属性値が存在しない場合はテンプレート情報の指定範囲外とみなす。
【０２４５】
そして、ステップＳ３１０にて値が範囲内であると判断した場合（Ｓ３１０−Ｙｅｓ）にはステップＳ３１１へ、範囲外であると判断した場合（Ｓ３１０−Ｎｏ）にはステップＳ３１４へ進む。
【０２４６】
そして、ステップＳ３１１において、コントローラ部は、入出力リソースの定義における他のパラメータの定義が存在するかを調べる。そして、定義が存在すると判断したある場合（Ｙｅｓ）にはステップＳ３０９へ戻り、定義が存在しないと判断した場合は、次のステップＳ３１２へ進む。
【０２４７】
そして、ステップＳ３１２において、コントローラ部はプロセスの定義における他の入出力リソースの定義が存在するかを調べる。ここで、定義が存在すると判断したある場合（Ｙｅｓ）にはステップＳ３０５へ戻り、定義が存在しないと判断した場合は、次のステップＳ３１３へ進む。
【０２４８】
なお、ステップＳ３１３まで来たということは、ジョブチケットにおけるプロセスの指定が、テンプレート情報の該当するプロセスの定義の入出力リソースの全てのパラメータの定義内に収まっているということを意味する。
【０２４９】
従って、ジョブチケットの該当するプロセスのidとテンプレート情報に対応する印刷拠点を対にして、印刷拠点がプロセスを処理可能という情報を印刷注文サーバ１のデータベース２に保存する。
【０２５０】
また、ステップＳ３０４、Ｓ３０６、Ｓ３０８、Ｓ３１０のいずれかで（Ｎｏ．）のほうへ処理が進んだ場合には、その印刷拠点のテンプレート情報にジョブチケットの指示が合わなかったことを示すため、処理可能という情報は保存されない。
【０２５１】
そして、ステップＳ３１４では、さらに次の印刷拠点についてもテンプレート情報を調べる。ここで、他にも印刷拠点があると判断した場合（Ｙｅｓ）にはステップＳ３０３へ戻り、すべての印刷拠点のテンプレート情報について調べたと判断した場合（Ｎｏ）にはステップＳ３１５へ進む。
【０２５２】
次に、ステップＳ３１５では、ジョブチケット内の次のプロセスについても調べる。ここで、他にも＜Proc＞のノードが存在すると判断した場合（Ｙｅｓ）にはステップＳ３０１へ戻り、ジョブチケット内の全てのプロセスをチェックしたと判断した場合（Ｎｏ）には、本処理を終了する。
【０２５３】
このように発注されたオーダ情報とデバイスの機能情報を含むテンプレート情報を比較することにより、印刷注文サーバ１は、受信したジョブチケットを処理可能なデバイスの有無を判定することが可能となる。
【０２５４】
次に、図１５におけるステップＳ３１３で、データベース２に保存している印刷拠点とプロセスの対応情報に関するデータ構造の詳細について説明する。
【０２５５】
図１６は、図１に示した印刷注文サーバ１がジョブチケットを解析する際に内部で構成する、どの印刷拠点がこのジョブチケット内のプロセスを処理可能であるかを示すデータ構造の例を示す図である。
【０２５６】
図１６に示すデータ構造は図１５のフローチャートにおけるステップＳ３１３が繰り返されることにより構成される。
【０２５７】
図１６において、４００、４０１、４０２、４０３はジョブチケットに記述されている各プロセスを示している。
【０２５８】
本実施形態において、１つの構造体は、ジョブチケットにおけるプロセスのＩＤと二つのポインタから成っている。ジョブチケットにおけるプロセスのＩＤは、例えば図１３におけるジョブチケットの３４、４０、４６行目に示されているid属性値の"pid01"、 "pid02"、 "pid03"、のことである。
【０２５９】
２つのポインタのうち１つは次のプロセスを示す構造体へのリンクになっている。もう１つのポインタはそのプロセスを処理可能な印刷拠点の線形リストへのリンクとなっている。
【０２６０】
図１６において、４００はpid1、４０１はpid2、４０２はpid3、４０３はpid4、というプロセスＩＤを示している。
【０２６１】
４０４、４０５、４０６はpid1のプロセスを処理可能な印刷拠点のリストを示している。これらのそれぞれの構造体は印刷拠点と次の処理可能印刷拠点の構造体へのポインタから成っている。
【０２６２】
４０４は印刷拠点Ａ、４０５は印刷拠点Ｂ、４０６は印刷拠点Ｃが対応していることを示し、最後の４０６では次の処理可能印刷拠点がないためポインタはどこも指していない。
【０２６３】
本例は、４００、４０４、４０５、４０６によって、pid1を処理可能な印刷拠点はＡ、Ｂ、Ｃであることが分かる。
【０２６４】
なお、図１５に示したステップＳ３１３において印刷拠点が追加される際にはその時点のリストの最後に追加される。
【０２６５】
つまり、４０４、４０５、４０６の順に追加されていったものである。
【０２６６】
同様に４０７、４０８はpid2に対応する印刷拠点のリストであり、拠点ＡとＢがpid2を処理可能であることを示している。
【０２６７】
４０９はpid3に対応し、４１０はpid4に対応する。このデータ構造全体はプロセスのリストの先頭つまり４００から順に辿って走査するように使用するものである。
【０２６８】
次に、図１６を例に、本実施形態におけるジョブチケットすなわち印刷注文に記述されている処理をどのように印刷拠点に配分するかの例を示す。
【０２６９】
図１７は、図１に示した印刷注文サーバ１における印刷拠点の配分処理例を示す図である。
【０２７０】
なお、図１７に示す例はジョブチケットの示すワークフローを図示しているが、プロセスの種類ではなくプロセスのIDを示している。
【０２７１】
また、このワークフローは図１６の処理可能リストに対応するジョブチケットに対応するものである。
【０２７２】
図１７において、４１１〜４１４は、例えば図１３に示した構造のジョブチケットで指定されたワークフローのプロセスを示している。そして、４１５〜４１８にて各プロセス４１１〜４１４をどの印刷拠点に振り分けるかを示している。図１６と対応付けながら説明をする。
【０２７３】
まず、プロセス４１１は、図１６におけるプロセス４００に対応する。プロセス４００から処理可能な印刷拠点を求めて印刷拠点リストのほうへ辿る。印刷拠点リストの先頭には、リスト４０４があり印刷拠点Ａが処理可能であると分かる。
【０２７４】
そこで、振り分けpid1（４１５）には印刷拠点Ａを対応付ける。以下同様に、プロセス４１２はプロセス４０１に対応し、最初の処理可能拠点はリスト４０７から印刷拠点Ａが処理可能であると分かる。
【０２７５】
従って、振り分けpid2（４１６）には、印刷拠点Ａを対応付ける。プロセス４１３はプロセス４０２に対応し、リスト４０９からＢをpid3に対応付ける。プロセス４１４はプロセス４０３に対応し、リスト４１０からＣをpid4に対応付ける。
【０２７６】
以上のように図１６に示すデータ構造を作った後、処理可能印刷拠点リストの最初の印刷拠点だけを使って処理を分配する。
【０２７７】
なお、図１６に示すプロセスに対応する処理可能拠点のリストが存在しない場合にはその印刷注文をどの印刷拠点でも処理できないことになるため、印刷注文サーバにてエラーとなる。なお、エラーに対して、警告処理を実行して、印刷注文サーバ１のオペレータに通知することは任意である。
【０２７８】
次に、印刷拠点の配分処理において、偏りのない印刷拠点分配を行う方法と、図１５における処理可能印刷拠点を調査する順番について補足説明する。
【０２７９】
図１８は、図１に示した印刷注文サーバ１における印刷拠点の配分処理例を示す概念図である。本例は、本実施形態における印刷注文サーバ１が持つ印刷拠点のテンプレート情報群のデータ構造と印刷注文に対する印刷拠点分配後の情報更新を示した例である。
【０２８０】
図１８において、４１９〜４２６は、図１に示した印刷注文サーバ１が対応する印刷拠点のテンプレート情報群のデータ構造を示している。
【０２８１】
また、４２７〜４３１は、図１６および図１７の状況を例にした拠点分配後のテンプレート情報群のデータ構造の変化を示している。なお、データ構造の変化については４１９〜４２３に相当する部分的に図示している。
【０２８２】
図１８において、４１９はテンプレート情報群のデータ構造への入り口となるポインタである。ポインタ４１９を基準に図１５におけるステップＳ３０３、Ｓ３１４の処理を行う。
【０２８３】
４２０〜４２３は、図１に示した印刷注文サーバ１が対応している印刷拠点のリストを示している。このリスト４２０〜４２３は印刷注文に従って印刷拠点に処理が分配されるたびに所定の規則に従って順序が並べ替えられる。従って、このリストの順序はいつも決まった状態にあるわけではない。
【０２８４】
図１８において、リスト４２０の印刷拠点Ａ、リスト４２１の印刷拠点Ｂ、リスト４２２の印刷拠点Ｃ、更にずっと続いて最後にリスト４２３の印刷拠点Ｄの順序に並んでいる。
【０２８５】
リスト４２０〜４２３の各データ構造体は印刷拠点、次の印刷拠点へのポインタ、印刷拠点に対応するテンプレート情報へのポインタの３つのデータから成る。４２４、４２５、４２６はそれぞれテンプレート情報を示している。
【０２８６】
例えば、図１５のフローチャートにおけるステップＳ３０３のテンプレート情報の読み込み処理では、例えば４２０の印刷拠点Ａの場合、リスト４２０のテンプレート情報４２４を読み込んで処理する。その後、次に、リスト４２１へと続き、最後のリスト４２３まで順に処理していくことになる。
【０２８７】
一方、４２７は図１６におけるデータ構造を元に図１７に示す拠点分配を行った後のテンプレート情報群の入り口を示している。
【０２８８】
４２８は元々リスト４２１の位置にあった印刷拠点Ｂ、４２９はリスト４２２の位置にあった印刷拠点Ｃ、４３０は元々テンプレート情報群の最後のリスト４２３であった印刷拠点Ｄである。
【０２８９】
そして、リスト４２０の位置にあった印刷拠点Ａが４３１で示される最後の位置に移動している。
【０２９０】
これは、図１６に示すデータ構造の最初のプロセス（つまり４００）の最初の印刷拠点Ａ（つまり４０４）を、図１８における最後に移動するという並べ替えによるものである。
【０２９１】
並べ替えの際には図１８の拠点リストにおいてどの位置にあっても最後に移動するものとする。つまり、Ａがリストの最後にあった場合にはリストの並びは変わらないことになる。
【０２９２】
また、図１５におけるフローチャートでの処理が、図１８に示す構造のリストの順で処理されるため、図１６に示すデータ構造の拠点の並びも図１８の構造のリストに従ったものとなる。
【０２９３】
そのため、図１６の先頭の印刷拠点を常にリストの最後に移動することで、同じ条件の能力を持つ印刷拠点が複数ある場合に偏った配分がされることがなくなる。
【０２９４】
なお、前記のようにプロセスに対応する処理可能拠点のリストが存在しない場合には印刷注文サーバにてエラーとなるため、図１８における印刷拠点リストの並べ替えは行わないものとする。
【０２９５】
図１９は、本実施形態における印刷製本注文システムの第２のデータ処理手順の一例を示すフローチャートである。本処理は、印刷注文サーバ１が受け取ったジョブチケットを元に処理を一つ以上の印刷拠点に分配する処理例である。なお、Ｓ３２１〜Ｓ３２４は印刷注文サーバ１のコントローラ部がメモリから制御プログラムをロードして実行される各ステップを示す。
【０２９６】
クライアント３、４等から、図１３に示す構造のジョブチケットをネットワークを介して受け取ると、本処理を開始する。
【０２９７】
まず、ステップＳ３２１で、コントローラ部は、受け取ったジョブチケットの処理内容を処理可能な印刷拠点のリストを作成する。これは図１５に示すフローチャートに対応する処理である。
【０２９８】
次に、ステップＳ３２２にて、コントローラ部は、処理可能拠点の無いプロセスが存在するかを判断する。前記の通り図１６に示すデータ構造において拠点リストを持たないプロセスが存在していると判断した場合（Ｙｅｓ）にはステップＳ３２５へ進む。
【０２９９】
一方、コントローラ部が、全てのプロセスがいずれかの印刷拠点にて処理可能であると判断した場合（Ｎｏ）にはステップＳ３２３へ進む。
【０３００】
そして、ステップＳ３２３では、コントローラ部が、図１７に示すように印刷拠点に対して処理を分配する。そして、分配された印刷拠点に対してジョブチケットと各印刷拠点で処理すべきプロセスのid情報を送信して印刷指示を行う。
【０３０１】
そして、ステップＳ３２４では、コントローラ部が、上述した図１８に示すように印刷拠点のテンプレート情報リストを更新する。そして、分配処理を終了し、次のジョブチケットが送られてくるのを待つ。
【０３０２】
以上説明したように、クライアント３，４等よりネットワークを介して、印刷注文をプロセスとリソースとのワークフローで表現したジョブチケットで、印刷注文サーバ１へ送信する。そして、印刷注文サーバ１が対応する印刷拠点ごとのテンプレート情報を元に対応プロセスを判断することにより、１つの印刷注文を偏らずに複数の印刷拠点へ分割分配できるようになった。なお、印刷注文サーバ１が対応する印刷拠点ごとのテンプレート情報をデータベース２に更新可能に保持している。
【０３０３】
これは、印刷拠点の処理能力が変更されたり、オプション機能が強化されることで処理能力が変化した場合にも柔軟に対応するためである。
【０３０４】
本実施形態の方式においては、対象ジョブチケットに記載された処理内容を全て処理可能な印刷拠点の場合には、その印刷拠点で全てのジョブチケットを処理することも可能である。また同時に、ジョブチケットの記載内容を全ては処理できない場合であっても他の印刷拠点の処理との組み合わせによって印刷注文の処理を完了させることも出来る。
【０３０５】
加えて、同じ処理能力を持つ拠点間では特定の充実した処理能力を持つ印刷拠点に偏ることなく処理を分配することが可能である。
【０３０６】
また、本実施形態ではワークフローによる処理の表現をジョブチケットで採用している。これにより、厳密なパラメータ指定が必要な自動処理のデバイスを備える印刷拠点から、手作業による柔軟な受注を受ける印刷拠点まで、様々な印刷拠点が混在する場合でも適切に注文の分割と分配が自動で可能となった。
【０３０７】
さらに、印刷拠点のテンプレート情報においては、自拠点の持つプロセスの組み合わせによって、別定義のプロセス（図１１におけるP3やP4など）とまったく同じ処理が可能な場合がある。この場合には、テンプレート情報にその別定義プロセスをリストアップしておくことで、ワークフローのグラフにおける部分グラフにも対応できることになる。
【０３０８】
本実施形態によれば、一括で受注を受ける印刷注文サーバ１が注文者の注文内容に応じて適切な印刷製本拠点へ処理を分配するシステムにおいて、以下の効果をそうする。つまり、注文内容すなわちジョブチケットの記述内容として、注文内容の記述の柔軟性を損なわず、かつ受注する印刷注文サーバ１が注文の拠点分配を自動で処理できるようになった。
【０３０９】
これは、同じ処理能力を持つ印刷拠点をローテーションして分配するだけではなく、注文指示の内容を分割して複数の印刷拠点に分配できることによる効果と、注文指示を処理の組み合わせで表現する。これにより、ジョブチケットにおいてオフラインや人手による作業とデバイスにおける詳細な処理パラメータの混在が可能になった効果である。
【０３１０】
これにより、設備の充実した拠点だけに処理が偏ることが無いように配分を行うことができる印刷製本受注システムを提供できる。
【０３１１】
なお、ワークフローを示すグラフデータ構造を一般的な部分グラフのパターンマッチングなどで判断しようとすると、計算量の関係で非現実的なシステムとなってしまう。しかし、本実施形態では、部分グラフの処理単位を別プロセスと定義することにより、単純な比較により部分処理の対応を判断できるようになっている。
【０３１２】
上記実施形態によれば、一括で受注を受けるサーバが注文者の注文内容に応じて適切な印刷製本拠点へ処理を分配するシステムにおいて、以下の効果を奏する。つまり、注文内容すなわちジョブチケットの記述内容として、注文内容の記述の柔軟性を損なわず、かつ受注サーバが注文の拠点分配を自動で処理できる。
【０３１３】
〔第２実施形態〕
なお、上記実施形態では、印刷要求ファイルを印刷拠点の印刷処理装置に分配する場合に、各印刷処理装置の処理能力が同じものが複数ある場合や、同一の機能処理を実行できる場合に、何ら優先順位を設定していない場合について説明した。
【０３１４】
しかしながら、各印刷処理装置の処理能力が同じものが複数ある場合や、同一の機能処理を実行できることを考慮して、あらかじめ複数の印刷処理装置に分配のための優先順位を設定することで、印刷処理装置が偏った選択とならないように構成してもよい。
【０３１５】
つまり、印刷処理装置の選択する場合の優先順位を管理者が任意に変更可能とすることで、印刷要求を処理する印刷処理装置資源の環境の変化に適応可能となる。
【０３１６】
〔第３実施形態〕
以下、図２０に示すメモリマップを参照して本発明に係るサーバ装置で読み取り可能なデータ処理プログラムの構成について説明する。
【０３１７】
図２０は、本発明に係るサーバ装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【０３１８】
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０３１９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０３２０】
本実施形態における図１５、図１９に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０３２１】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０３２２】
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０３２３】
従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０３２４】
プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【０３２５】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０３２６】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバやｆｔｐサーバ等も本発明の請求項に含まれるものである。
【０３２７】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０３２８】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。例えばそのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０３２９】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０３３０】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から排除するものではない。
【０３３１】
本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。
【図面の簡単な説明】
【０３３２】
【図１】本発明の第１実施形態を示す印刷製本注文システムの全体構成を示すブロック図である。
【図２】図１に示した印刷製本注文システムにおける第１のワークフローを説明する図である。
【図３】図１に示した印刷製本注文システムにおける第１のワークフローを説明する図である。
【図４】図１に示した印刷製本注文システムにおける第２のワークフローを説明する図である。
【図５】図３に示したプロセスとリソースの種類に注目して一つの図形で表現する図である。
【図６】図２に示した第１のワークフローの他の構造表現例を示すワークフロー図である。
【図７】図６に示したプロセスを置換表記した図である。
【図８】図６に示したワークフローの他の表記例を示す図である。
【図９】図８に示したワークフローの簡略表記例を示す図である。
【図１０】図４に示したワークフローの構造表現を簡略記述した図である。
【図１１】本実施形態における印刷製本注文システムの複合プロセスの構造を説明する図である。
【図１２】本実施形態における印刷製本注文システムの印刷製本注文内容に対する印刷拠点の対応の一例を示す図である。
【図１３】本実施形態における印刷製本注文システムの印刷製本注文内容の一例を示す図である。
【図１４】本実施形態における印刷製本注文システムの印刷拠点の処理能力である対応プロセスの一覧を示すテンプレート情報の一例を示す図である。
【図１５】本実施形態における印刷製本注文システムの第１のデータ処理手順の一例を示すフローチャートである。
【図１６】図１に示した印刷注文サーバがジョブチケットを解析する際に内部で構成する、どの印刷拠点がこのジョブチケット内のプロセスを処理可能であるかを示すデータ構造の例を示す図である。
【図１７】図１に示した印刷注文サーバにおける印刷拠点の配分処理例を示す図である。
【図１８】図１に示した印刷注文サーバにおける印刷拠点の配分処理例を示す概念図である。
【図１９】本実施形態における印刷製本注文システムの第２のデータ処理手順の一例を示すフローチャートである。
【図２０】本発明に係るサーバ装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【符号の説明】
【０３３３】
１  印刷注文サーバ
２  データベース
３，４  クライアント
５，６  印刷拠点
【図１】
2007280017.tif 000003
【図２】
2007280017.tif 000004
【図３】
2007280017.tif 000005
【図４】
2007280017.tif 000006
【図５】
2007280017.tif 000007
【図６】
2007280017.tif 000008
【図７】
2007280017.tif 000009
【図８】
2007280017.tif 000010
【図９】
2007280017.tif 000011
【図１０】
2007280017.tif 000012
【図１１】
2007280017.tif 000013
【図１２】
2007280017.tif 000014
【図１３】
2007280017.tif 000015
【図１４】
2007280017.tif 000016
【図１５】
2007280017.tif 000017
【図１６】
2007280017.tif 000018
【図１７】
2007280017.tif 000019
【図１８】
2007280017.tif 000020
【図１９】
2007280017.tif 000021
【図２０】
2007280017.tif 000022