JP2010009602A

JP2010009602A - 動的ｘｐｓフィルタ

Info

Publication number: JP2010009602A
Application number: JP2009152077A
Authority: JP
Inventors: Jerome Pouyadou; ポウヤドウジェロム; Victor Ciriza; シリザビクター
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 2008-06-27
Filing date: 2009-06-26
Publication date: 2010-01-14
Anticipated expiration: 2029-06-26
Also published as: EP2138930A3; JP5478955B2; JP2014075151A; EP2138930A2; US20090328031A1; US8479192B2

Abstract

【課題】ドキュメント処理の管理の方法を提供する。
【解決手段】デフォルトのワークフローパスより豊かなコンテキストでフィルタの実行を可能にするための方法は、それぞれのフィルタがポリシーの規則および関連するトリガ条件を含む複数のフィルタを構成することと、複数のフィルタをデフォルトのワークフローパスと独立したリポジトリ内にストアすることと、ポリシーの規則のうちの選択されたものを少なくとも１つのリソースに結合することと、複数のフィルタに対するアクセスを有するデフォルトのワークフローパス内にオーケストレータをインストールすることであって、オーケストレータが、デフォルトのワークフローパスに提出されたジョブのためのデフォルトのワークフローパス処理の間に、フィルタのためのトリガ条件がジョブについて評価され、かつトリガされたポリシーの規則が適用されるように実行されるべく構成されることと、を含む。
【選択図】図１

Description

例示的な実施態様は、ドキュメント処理の管理のためのシステムおよび方法に関する。特にそれは、ポリシーの規則がフィルタのセットの実装に使用されるプリント・パスに関連して応用が見出されている。

ワークフロー・システムは、提出されたドキュメントをプリントに先行して処理するために広く使用される。プリント・パスの１つの例は、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）によって開発され、最近はウインドウズ・ビスタ（Ｗｉｎｄｏｗｓ（登録商標）Ｖｉｓｔａ）およびウインドウズＸＰ（Ｗｉｎｄｏｗｓ（登録商標）ＸＰ）等の多様なプラットフォーム上で利用可能となっているＸＰＳプリント・パスである。ＸＰＳシステムにおいては、拡張マークアップ言語（ＸＭＬ）が、プリンティング・パラメータの指定のために使用される。それがプリント処理内におけるドキュメント処理に関して有意の利点を提供する一方、直観的な構成ツールおよび実際のワークフロー管理両方に関していくつかの特徴が欠落している。

米国特許出願公開第２００３／０１８４７８４号明細書米国特許出願公開第２００６／０１３９６７３号明細書米国特許出願公開第２００７／０１６５２６７号明細書米国特許出願公開第２００７／０２１６９３９号明細書米国特許出願公開第２００７／０２１６９４４号明細書米国特許出願公開第２００８／００６８６４１号明細書米国特許第７３０４７５８号明細書

本質においてＸＰＳプリント・パス・システムは、ＸＭＬ構成ファイル内において呈示される命令の中で呼び出される統計的に構成された動的ライブラリのセットである。このシステムは、動的に再構成することが容易には可能でない。加えてそのライブラリは、ドキュメントがプリントのために提出される前に、当該ライブラリのそれぞれによって順番にそれが逐次的に処理されるように、逐次的に作用させられるフィルタのシーケンスに関連付けされる。このシステムは、条件付き実行、データの並列処理、およびそのほかの、先進ワークフロー・システム内において価値を有すると見られる能力といった洗練されたフィルタ実行を提供しない。これらの相対的な弱さにもかかわらず、このシステムは、広く分布しているオペレーティング・システム上で容易に利用できるという利点を有する。

１つの態様において、デフォルトのワークフロー・パスより豊かなコンテキストでフィルタの実行を可能にするための方法は、それぞれのフィルタがポリシーの規則および関連するトリガ条件を包含する複数のフィルタを構成することを含む。複数のフィルタは、デフォルトのワークフロー・パスとは独立したリポジトリ内にストアされる。それらのポリシーの規則のうちの選択されたものが少なくとも１つのリソースに結合される。オーケストレータが、複数のフィルタに対するアクセスを有するデフォルトのワークフロー・パス内にインストールされる。オーケストレータは、デフォルトのワークフロー・パスに提出されたジョブのためのデフォルトのワークフロー・パス処理の間に、それらのフィルタのためのトリガ条件が当該ジョブについて評価され、かつトリガされたポリシーの規則が適用されるように実行されるべく構成される。

この方法は、さらに以下のうちの１つ以上を含んでもよい。

（ａ）複数のポリシーの規則を少なくとも１つのポリシー・セットに結合すること、ただしポリシーの規則のセットは、当該セット内のポリシーの規則が適用されるべき順序を決定し、それにおいてポリシーの規則のうちの選択されたものおよび関連するトリガ条件を少なくとも１つのリソースに結合するステップは、当該少なくとも１つのポリシー・セットのうちの選択されたものを少なくとも１つのリソースに結合することを含むことができる。

（ｂ）デフォルトのワークフロー・パスに提出されたジョブのためのトリガ条件のうちの少なくとも１つを評価することおよび当該評価に基づく戻り値を生成すること、および関連するトリガ条件が評価するステップに基づいて満たされた場合にポリシーの規則に基づいて処理ユニットを実行すること。

（ｃ）ポリシーの規則のうちの少なくとも１つおよび関連するトリガ条件に関連付けされた、少なくとも１つの実行のユニットを構成すること、ただし当該実行のユニットは、実行可能コードを包含し、それにおいて処理ユニットを実行するステップは、ポリシーの規則に関連付けされた実行のユニットを実行することを含む。

（ｄ）オーケストレータによる、戻り値を実行コンテキストの中にストアすること、ただしそれにおいてデフォルトのワークフロー・パスに提出されたジョブのためのトリガ条件のそれぞれを評価するステップは、実行コンテキストの中にストアされた戻り値を以前に提出されたジョブのために利用することを含む。

この方法において、リソースはプリンタを含むことができ、デフォルトのワークフロー・パスはプリント・パスを含むことができ、また提出されたジョブはプリント・ジョブを含むことができる。プリント・パスは、ＸＰＳプリント・パスを含むことができる。オーケストレータは、フィルタを含むことができる。

この方法は、さらに、再構成されるべきリポジトリ内におけるフィルタのセットの提供を含むことができる。

別の態様においては、デフォルトのワークフロー・パスより豊かなコンテキストでフィルタの実行を可能にするためのシステムが、デフォルトのワークフロー・パスを含む。リポジトリは、デフォルトのワークフロー・パスと独立であり、それぞれのフィルタがポリシーの規則および関連するトリガ条件を包含する複数のフィルタをストアし、それらのポリシーの規則のうちの選択されたものが少なくとも１つのリソースに結合される。オーケストレータが、複数のフィルタに対するアクセスを有するデフォルトのワークフロー・パス内にインストールされ、当該オーケストレータは、デフォルトのワークフロー・パスに提出されたジョブのためのデフォルトのワークフロー・パス処理の間に、それらのフィルタのためのトリガ条件が当該ジョブについて評価され、かつトリガされたポリシーの規則が適用されるように実行されるべく構成される。

このシステムは、さらに、ポリシーの規則およびワークフロー・システムのデフォルトのワークフロー・パスに利用可能でない能力を指定する関連するトリガ条件を構成し、構成したポリシーの規則および関連するトリガ条件をリポジトリ内にストアするための構成ユニットを含むことができる。

オーケストレータは、デフォルトのワークフロー・パスの標準コンポーネントとしてインストールされるフィルタを含むことができる。

オーケストレータは、デフォルトのワークフロー・パスに提出されたジョブのためのデフォルトのワークフロー・パス処理の間に実行されるべく構成されることができ、かつそれにおいてオーケストレータは、ポリシーの規則および関連するトリガ条件にアクセスする機能、デフォルトのワークフロー・パスに提出されたジョブのためのトリガ条件のうちの少なくとも１つを評価し、かつ当該評価に基づいて戻り値を生成する機能、および関連するトリガ条件が評価するステップに基づいて満たされた場合にポリシーの規則に基づいて処理ユニットを実行する機能を包含する処理機能のセットを実行するべく構成される。

フィルタのセットは、動的に修正可能であるとすることができる。

このシステムは、さらに第２のリポジトリ、処理機能の第３のセットであって、第２のポリシーの規則およびワークフロー・システムのデフォルトのワークフロー・パスに利用可能でない関連する第２のトリガ条件を構成する機能、構成した第２のポリシーの規則および関連する第２のトリガ条件を第２のリポジトリ内にストアする機能、および第２のポリシーの規則および関連する第２のトリガ条件のうちの選択されたものを少なくとも１つのリソースに結合する機能を包含する処理機能の第３セットを実行するべく構成された第２の構成ユニット、および許可ユーザの要求により管理アプリケーションによって起動されたときに、第１のリポジトリ内の第１のポリシーの規則および関連する第１のトリガ条件を第２のポリシーの規則および関連する第２のトリガ条件に置換すること、および第２のポリシーの規則および関連する第２のトリガ条件が第２のリポジトリ内にストアされるときを決定するべくリポジトリを周期的にポーリングして第１のポリシーの規則および関連する第１のトリガ条件を第２のポリシーの規則および関連する第２のトリガ条件に置換することのうちの少なくとも１つを包含する引き渡し処理を実行するべく構成されたダウンロード・ユニットを含むことができる。

このシステムは、第２のリポジトリ、第２の構成ユニット、およびダウンロード・ユニットを含む中央管理システム（ＣＡＳ）を含むことができる。

このシステムは、複数のクライアント・システムの１つを含むことができ、それにおいてクライアント・システムのそれぞれはＣＡＳによって管理される。

複数のポリシーの規則および関連するトリガ条件は、少なくとも１つのポリシー・セットに結合されることができ、ポリシー・セットは、当該ポリシー・セット内の規則が適用されるべき順序を決定する。

このシステムは、フィルタのためのトリガ条件がジョブのために評価され、トリガされたポリシーの規則が適用されるときに更新される実行コンテキストを含むことができる。このシステムは、それぞれがソフトウエア処理インストラクションを含む複数の処理ユニットを含むことができ、当該インストラクションは、実行されると、提出されたジョブのための処理動作を実行し、それによって複数の処理ユニットのうちの選択された１つがトリガされた規則の動作によって実行される。

このシステムにおいて、リソースはプリンタを含むことができ、デフォルトのワークフロー・パスはプリント・パスを含むことができ、また提出されたジョブはプリント・ジョブを含むことができる。

このシステムを使用するための方法は、デフォルトのワークフロー・パスにジョブを入力すること、およびデフォルトのワークフロー・パス内にインストールされたオーケストレータを用いてジョブを処理することを含むことができ、それにはフィルタのセットの適用、それらのフィルタのためのトリガ条件の評価、およびトリガされたポリシーの規則の適用が含まれる。

別の態様においては、デフォルトのワークフロー・パスを有するクライアント・システム内における方法が提供され、デフォルトのワークフロー・パスは、第１の構成済みフィルタを有し、当該方法は、第１の構成済みフィルタを動的に更新するためのものであり、第１の構成済みフィルタは、構成済みの第１のポリシーの規則および関連する第１のトリガ条件を包含する。この方法は、第２の構成済みフィルタであって、第２のポリシーの規則および関連する第２のトリガ条件を包含する第２の構成済みフィルタを構成すること、および当該第２の構成済みフィルタをデフォルトのワークフロー・パスと独立のリポジトリ内にストアすることを含む。構成された第２の構成済みフィルタは、クライアント・システムに引き渡される。この引き渡しは、第１の構成済みフィルタを第２の構成済みフィルタに許可ユーザの要求により管理アプリケーションによって置換すること、および第２の構成済みフィルタがリポジトリ内にストアされるときを決定するべくリポジトリをクライアント・システムによって周期的にポーリングして第１の構成済みフィルタを第２の構成済みフィルタに置換することのうちの少なくとも１つを含む。

この方法は、さらに、オーケストレータをデフォルトのワークフロー・パス内にインストールすることを含むことができ、オーケストレータは、デフォルトのワークフロー・パスの標準コンポーネントとしてインストールされるフィルタを包含し、それにおいてオーケストレータは、デフォルトのワークフロー・パスに提出されたジョブのためのデフォルトのワークフロー・パス処理の間に実行されるべく構成され、構成された第２の構成済みフィルタをクライアント・システムに引き渡すステップは、オーケストレータがデフォルトのワークフロー・パスに提出されたジョブのためのデフォルトのワークフロー・パス処理の間に実行されるとき、オーケストレータによって第１の構成済みフィルタを第２の構成済みフィルタに置換することを含むことができる。

第１の構成済みフィルタは、少なくとも１つの第１の実行のユニットであって第１の実行可能コードを包含する第１の実行のユニットを含むことができ、さらに第２の構成済みフィルタは、少なくとも１つの第２の実行のユニットであって第２の実行可能コードを包含する第２の実行のユニットを包含する。

プリント・パスが動作する例示的な環境を示した説明図である。ポリシー・セットに対する規則の関係を図式的に示すためのポリシー・セットのグループを示した説明図である。規則の例示的な構成を示した説明図である。ドキュメントがプロセスに与えられるときの実施態様の動作を示したフローチャートである。ワークフロー・システム内の実施態様の例示的な処理構成を示した説明図である。フィルタのインストールおよび実行の方法を示したフローチャートである。管理者によるポリシーの規則の構成を示したフローチャートである。ウェブ・アプリケーション上においてシステムを管理するための管理インターフェースの例示的な実施態様を示した説明図である。ウェブ・アプリケーション上においてポリシー・セットに規則を追加するための例示的なスクリーンを示した説明図である。

ここでは、プリント・パスを管理するためのシステムおよび方法を開示する。

図１は、プリント・パスが動作する例示的な環境を図解する。ドキュメントが、ドキュメントを生成するための１つまたは複数のアプリケーションを含むことができるパーソナル・コンピュータ、ラップトップ、またはこれらの類といったワークステーション１０においてプリントのために選択される。ワークステーションは、プリンティング・システム１６に提出されることになるプリント要求１４として出力するためにドキュメントをフォーマットするプリント・ドライバ１２を含む。プリント要求１４は、通常、プリントされることになるドキュメントとともに、多様な前プリント動作、プリント動作、および／または仕上げ動作を指定する情報を含む。この情報は、ドキュメント内に埋め込まれるか、またはＸＭＬファイルまたはそのほかのファイルとしてそれに取り付けられることができる。いくつかの実施態様においては、たとえばＸＰＳプリント・ジョブ・チケット等の、ドキュメントに関連付けされ、ドキュメントがシステムによって処理されるときに更新されることができるプリント・ジョブ・チケット内においてこの情報が維持される。プリントのために処理されるドキュメントおよび当該ドキュメントに関する、関連する情報が、ここではプリント・ジョブおよびプリント・ジョブ・チケット、またはより包括的にジョブおよびジョブ・チケットと呼ばれる。認識されるものとするが、この出願のコンセプトは、プリントされるドキュメントの処理に限定されず、等しい有効性をもって、その先の処理のために提出されるデータ・ファイルまたはデータ・ファイルのグループのためのワークフロー管理を利用する任意のシステムに適用可能である。また、プリンタ使用ポリシーの強制、プリント要求の会計および請求、プリント要求の内容ベースの処理、およびドキュメント・フォーマット変換にも適すると見られる。

プリンティング・システム１６は、独立した処理ユニットまたはライブラリ２０、２２、２４、２６、２８のセットを含むプリント・パス・システム１８を含む（図解された実施態様内では５つであるが、より多くの、またはより少ないライブラリが企図される）。処理ユニット２０、２２、２４、２６、２８のそれぞれは、ソフトウエア処理インストラクションを含み、それらは、実行されたときに提出されたドキュメントと関係する処理動作を実行する。例示的な処理ユニットは、プリンタ使用ポリシーの強制、プリント要求の会計および請求、プリント要求の内容ベースの処理、ドキュメント・フォーマット変換のためのユニット、およびこれらの類を含むことができる。したがって、たとえば処理ユニット２０は、特定のユーザに高品質プリンタ上におけるドキュメントのプリントを許可する一方、別のユーザのグループによる高品質プリンタの使用を妨げるか、または制限するといったプリンタ使用ポリシーをもたらすことができる。処理ユニット２２は、会計および金額請求を、たとえば特定のクライアントに対してドキュメントのプリントを金額請求することによって扱うことができる。１つの実施態様においては、ユニット２２が、内容がビジネス関連というよりはむしろ個人的となりがちなドキュメントを検出してプリントの費用をユーザの口座に課金するか、またはそのほかの方法でドキュメントの意図された使用についての推論に依存してドキュメントを処理する能力を有する。処理ユニット２４は、たとえばドキュメントに透かしを追加するか、または別の画像修正を行う内容ベースの処理ユニットとすることができる。処理ユニット２６は、１つのフォーマットから別のそれへのドキュメント変換のために構成されることができる。

例示的なプリント・パス・システム１８は、ローカル・エリア・ネットワークまたはワイド・エリア・ネットワーク、たとえばインターネット等の有線または無線のネットワーク３２を介してワークステーション１０に通信的にリンクされるプリント・サーバ３０上に常駐する。サーバ３０は、ネットワーク３２または別のネットワークによって、１つまたは複数のリソース、たとえばプリンタ３４、３６と通信的にリンクされる。これらのプリンタは、紙等のプリント媒体上に、インクまたはトナー等のマーキング媒体を使用してドキュメントをレンダリングするために構成される。ほかの実施態様においては、リソースが、スクリーン上にドキュメントを出力するディスプレイ・デバイスになることがある。

例示的なプリント・パス・システム１８の１つまたは複数のコンポーネントは、プリンタ３４、３６のうちの１つまたは複数のデジタル・フロント・エンド（ＤＦＥ）内、またはワークステーション１０、またはそれらの組み合わせ等の、サーバ３０以外のコンピューティング・デバイス上に適切に置かれるようにできる。

ドキュメント処理ユニット２０、２２、２４、２６、２８は、実行の条件が特定の数の規則（「ポリシーの規則」と呼ばれる）によって記述される独立したライブラリのセットとして実装され、コンピュータ言語に中立な態様で記述され、実装に中立なリポジトリ４０内にストアされる。リポジトリ４０は、サーバ・メモリ４２またはサーバ・ストレージ・デバイス４４、たとえばディスク・ドライブ等のいずれかの中にストアされることが可能である。１つの実施態様においては、ＸＰＳフィルタ‐ベースのメカニズムが、それらの規則の適用に使用される。図１は、例としてオーケストレータ５４によってコントロールされるフィルタ４６、４８、５０、５２のセットを示す。例示的な実施態様においては、オーケストレータがＸＰＳプリント・パス・エンジン５６によって起動される。オーケストレータ５４によってドキュメントが処理されているとき、フィルタ４６、４８、５０、５２のそれぞれを試験することによって決定されるトリガ条件に基づいて適切な処理ユニット２０、２２、２４、２６、２８が実行される。これに関していえば、処理ユニットの１つの実行が以前に実行された処理ユニットからの結果に依存することがあるため、オーケストレータ５４によって実行コンテキスト５８が維持される。実行コンテキスト５８は名前付き変数のセットであり、多様な実行のユニットによる、またはオーケストレータによる作成、読み出し、修正、または削除が可能であり、それによって処理ユニット２０、２２、２４、２６、２８のそれぞれの条件付き実行をさらに容易にする。実行コンテキスト５８は、サーバ・メモリ４２またはサーバ・ストレージ・デバイス４４のいずれかの中に維持されることが可能である。

例示的なポリシーの規則は、限定ではないが、ＸＰＳフィルタに基づいて集中または分散いずれかの態様で動的に構成されることができる。例示的なフィルタは、デフォルトのＸＰＳプリント・パス・コンテキストより豊かなコンテキストで実行されることが可能であり、特に、既存のＸＰＳプリント・パス・メカニズムをてこ入れする一方、条件の評価に基づいてそれらの振る舞いを変更する能力を提供する。

リポジトリ４０内の例示的なフィルタのセットは、たとえば１つまたは複数のフィルタを更新すること、１つまたは複数のフィルタを修正すること、１つまたは複数のフィルタを置換すること、および／または１つまたは複数の新しいフィルタを追加することによって動的に再構成されることが可能である。これは、随時、自動的に、またはオペレータによって行われることが可能である。

１つの実施態様においては、システムが、ＸＰＳ構成を動的にインスタンシエートするか、または変更すること、したがってポリシー構成に対してシステム管理者によって行われた変更を即座に反映することが可能である。１つの実施態様においては、中央管理システム（ＣＡＳ）６０、たとえばＸＤＭサーバが存在し、そこでサーバ３０上のフィルタ・リポジトリ４０に類似の中央フィルタ・リポジトリ６２が維持される。中央フィルタ・リポジトリ６２は、ＣＡＳメモリ６４またはＣＡＳストレージ・デバイス６６、たとえばディスク・ドライブ等のいずれかの中にストアされることが可能である。この構成は、プリンティング・システム１６等のクライアント・プリンティング・システムの集中管理ネットワークに特に適しており、ＣＡＳ６０上における集中化によって管理が単純化される。当然のことながら、この出願のコンセプトは、プリンティング・システムの分散ネットワークに利用されることもできる。それぞれのサーバ・フィルタ４６、４８、５０、５２の現在のフィルタ・バージョン６８、７０、７２、７４は、ＣＡＳ６０上において維持され、構成される。管理者またはそのほかの許可ユーザは、ＣＡＳ６０のユーザ・インターフェース７５を介し、構成処理ユニット７６によって中央フィルタ・リポジトリ６２内のフィルタの更新、作成、および／または削除を行う。

サーバ３０上におけるフィルタ４６、４８、５０、５２の動的更新は、ユーザによってプリントのためにドキュメントが提出されるとき、クエリがＣＡＳに送信され、提出しているユーザのため、および目標とされた物理的なプリンタのための構成を尋ねるといった形で達成されるようにできる。構成についてのクエリに応答して、ＣＡＳは、そのプリンタ上においてそのユーザのために実行されるべきモジュールのリストを提供する。どのようなモジュール、たとえば処理ユニット、ポリシー・セット、および／またはフィルタが利用可能であるかがわかれば、ダウンロード・ユニット７８によって現在のバージョンをダウンロードすることが可能である。１つの実施態様においては、ダウンロードが、必要時ベースでのみ実行される。たとえば、サーバ３０上のバージョン番号がＣＡＳ６０上の対応するモジュールのバージョン番号より低い場合にダウンロードが生じることが可能である。タイムスタンプ等の追加の特徴が、ダウンロードの決定において補助できる。

このコンセプトは動的であるべきであり、言い替えると必要に応じてサーバ３０上でフィルタおよび処理ユニットを更新し、基本的にリアル‐タイム更新の等価を提供する。しかしながら一旦、必要なモジュールがダウンロードされた後は、更新されたバージョンのインスタンシエートに必要とされるときを除いて再びダウンロードされない。フィルタが適用される、所定のユーザのための、所定の瞬時における、所定のドキュメントのため、および所定の物理的プリンタのための構成は、処理のためにドキュメントが提出される都度ダウンロードされること、すなわち一過性とすることができる。コア・ライブラリ、たとえば処理ユニットは、必ずしも一過性でない。一旦コア・ライブラリがダウンロードされた後は、それらがそれほど更新されがちではなく、その結果、それらを必要時にだけダウンロードすることによって処理時間を節約する。

ＣＡＳ６０の代替として、説明中のコンセプトがサーバ３０上に直接実装されることが可能である。言い替えると、同じメカニズム、同じエンジン、同じ構成ファイル等々が使用されることが可能である。外部ソース、すなわちＣＡＳ６０は存在しないが、新しく更新されるか、または追加されたモジュールが、中央フィルタ・リポジトリ６２を参照して説明したものと類似の態様で利用可能になる更新キューを提供することによって類似の効果が達成できる。

ポリシーの規則、すなわちフィルタは、ポリシー・セット内にまとめてグループ化されることが可能である。図１に示されるとおり、サーバ上の『フィルタ３』および『フィルタ４』（番号５０、５２）として識別されるフィルタは、ポリシー・セット８０の部分である。同様にＣＡＳ６０上の対応するフィルタ（番号７２、７４）は、ポリシー・セット８２の部分である。ポリシー・セットは、特定数のポリシーの規則／フィルタ、およびそれらの規則が吹き込まれることになる順序の結合からなる。図２を参照すると、引き続き図１も参照するが、ポリシー・セットに対する規則の関係を図式的に示すためにポリシー・セットのグループ８４が示されている。ポリシー・セット８６〜９０のそれぞれは、それぞれのポリシー・セットに関連付けされた選択された規則９２〜１０４からなる。オーケストレータ５４は、構成についての、およびすべてのポリシー・セットおよび規則についての知識を有するソフトウエア要素である。それぞれのポリシーの規則の実行のユニットを順番に呼び出し、結果を解釈するのはこの要素である。オーケストレータ５４は、ＸＰＳプリント・パス・エンジン５６から呼び出される。オーケストレータは、ネイティブ・フィルタとしてデフォルトのワークフロー・システム内にインストールされることができる。それがシステムによって実行されるときにワークフロー・システムの能力を拡張するために、任意のワークフロー・システム内においてそれを容易にインストールすることが可能である。

ポリシーの規則を介して利用可能にされるすべてのコントロールを記述するシンタクスおよび／または選択リストが存在する。多くのユーザを有する大きなシステムにおいては、管理者が管理を行うこと、すなわち当該システムのそれぞれのユーザおよびプリンタに適用する特定の個別の規則を決定することが、時間を要するものとなり得た。ポリシー・セット内において規則をまとめてグループ化することによって、管理者が、それぞれの個別の規則の適用を強いられることなく、規則セットを全体として適用する決定が可能であることから、管理者のタスクが緩和される。

それぞれのコード・ユニット、すなわちポリシーの規則は、ＸＰＳフィルタとして実装されるようにできる。または、いくつかのコード・ユニットが、それらのコード・ユニットのための容器として作用する１つのＸＰＳフィルタに結合される。

図３は、規則の例示的な構成を示す。２つのスタンドアロンの規則１０６、１０８が手前で述べたとおりに構成され、処理される。しかしながら結合された規則セット１１０は、たとえば３つの規則１１２〜１１６を含む。同様に結合された規則セット１１８は、たとえば３つの規則１２０〜１２４を含む。この構成が有用となることがあり、たとえばコード・ユニットの並列処理を、ネイティブ・フィルタ実装、すなわちデフォルトの実装が、たとえばＸＰＳフィルタ実装がこの特徴をサポートしないときに可能にする。結合された規則セットへの規則のグループ化は、ポリシー・セットへの規則のグループ化に類似に見えるが、これが、すなわち管理の容易のために規則をグループ化することに対する並列処理が、基本的な相違理由である。

例示的なポリシーの規則は、以下のように動作できる。それぞれのポリシーの規則は、条件１２６およびオプションの作用１２８の結合からなる。それぞれの作用は、実行のユニット、たとえば管理者によって書き込まれ、可能性として独立の処理ユニットまたはライブラリ２０〜２８のうちの１つを起動する実行可能コードからなり、それが作用の結果を返し、それをオーケストレータ５４が試験して、たとえばドキュメントのプリント処理の終了、別のポリシーの規則の適用等といった次に生じるべき作用を決定できる。ポリシーの規則の適用は、いずれかの段階において『吹き込まれる』ポリシーの規則に帰結する。ポリシーの規則を吹き込むことは、実行のコード・ユニットの実行からなり、実行後にそれが呼び出し元に結果を返す。

再び図１の実行コンテキスト５８を参照するが、実行コンテキストは、多様な実行のユニットによる、またはオーケストレータによる作成、読み出し、修正、または削除が可能な名前付き変数のセットである。１つの実施態様においては、ＸＭＬ‐ベースのシステムであるＸＰＳプリント・ジョブ・チケットが使用されて、ＸＰＳフィルタからＸＰＳフィルタに情報が伝達される。ＸＰＳプリント・ジョブ・チケットは、パブリック・プロパティ、すなわち、たとえば標準化された紙サイズ等の合意された汎用特性の周知のセットを提供する。ＸＰＳプリント・ジョブ・チケットは、特定のコンポーネントだけに意味を持つプライベート・プロパティも提供する。プライベート・プロパティは、実行ユニットの間におけるステータス情報の伝達に使用されることがある。いくつかの特定の実行ユニットの戻り値が、その後プリント・パス・エンジン５６に固有のイベントまたは戻り値にマップされ、したがってプリント要求に作用できる。たとえば、指定された非ゼロの実行ユニットの戻り値を、プリント・パス・エンジンに送出される中止命令にマップすることができる。ゼロの実行ユニットの戻り値は、いずれの追加の動作もとることなく、パス処理が正常に継続されるべきであると示すことができる。

図４を参照するが、例示的な方法は、処理にドキュメントが与えられたときに以下のとおりに動作できる。ステップ２００において、オーケストレータ５４が、フィルタ・リポジトリ４０からポリシーの規則の記述を、以前にロードされていなければすべてロードする。その後ステップ２０２において、それぞれの規則についてオーケストレータが、現在の実行のコンテキストに照らして規則のトリガ条件を評価する。この評価がステップ２０４において真、たとえばブール値で真であると決定されると、当該規則に関連付けされた実行コアのユニットがステップ２０６において実行され、たとえば処理ユニット２０〜２８の１つが実行される。そのコアが実行されると、それがステップ２０８においてオーケストレータに戻り値を提供する。戻り値は、現在の実行コンテキスト５８に追加され、その結果、ステップ２１２における決定時に次のトリガ条件がある場合には、オーケストレータ５４によるそれの評価のために利用可能になる。しかしながら理解されるものとするが、戻り値を中止命令等の特別な値のセットの１つとすることも可能である。これらの特別な値は、終了条件、すなわち動作の正常な連鎖が中止される場合を示すことが可能である。これは、深刻な状態、たとえばメモリ故障またはユーザによるアクセス権の欠落であると以前に決定された状態等が存在するときに生じ得る。この場合においては、残りの規則を処理する必要がない。

図５は、ＸＰＳプリント・パス等のワークフロー・システムと実施態様の相互作用およびインストールを記述した、ワークフロー・システム内の実施態様の例示的な処理構成２２０を示す。１つのリソース、すなわちプリンタ２２２だけが示されているが、複数のリソースが含まれることもある。

プリント・パス・エンジン５６の動作において、プリント・ジョブ要求１４がクライアント・デバイスから処理のために受信され、スケジューラ２２４が、フィルタ・パイプライン・マネージャ２２６に処理の開始を合図する。フィルタ・パイプライン・マネージャは、フィルタ構成ファイル２２８を読み出し、そのフィルタ構成ファイル２２８内にリストされた選択されたプリンタ２２２のためのフィルタをロードすることによってフィルタ・パイプラインを作成する。フィルタ・パイプライン内の第１のフィルタ、すなわちＸＰＳフィルタ１（２３０）がＸＰＳスプール・ファイル２３１の内容を読み出す。それが、ジョブ要求１４からドキュメント部分２３３およびＸＭＬプリント・ジョブ・チケット２３２を読み出し、相応じてドキュメントを処理する。第１のフィルタ２３０は、処理後のドキュメント部分を第２のフィルタ２３４に、フィルタ間コミュニケータ２３６によって提供されるインターフェースを使用して渡す。コミュニケータ２３６は、中間処理結果を、次のフィルタがそれらを処理する準備が整うまで維持する。この処理が、最後のフィルタ２３８がドキュメントおよびＸＭＬプリント・ジョブ・チケットの処理を終わるまで続く（中止がない場合）。プリンタ２２２およびプリント・ジョブについての情報は、使用するＸＰＳフィルタ２３０、２３４、２３８のためのプリント・パイプラインのプロパティ・バッグ２４０内にストアされることもある。これらのフィルタは、プロパティ・バッグ２４０内にストアされた情報にアクセス可能であり、またストアされた情報の共有データを使用することが可能である。シリアル化サービス２４２は、ＸＰＳスプール・ファイル２３１とフィルタ・パイプライン・マネージャ２２６およびスケジューラ２２４の間に流れるデータ・ストリームをシリアル化するためのサービスを提供する。

オーケストレータ５４は、ＸＰＳフィルタ２３０、２３４、２３８のフィルタ・パイプライン内にインストールできる。１つのインストール方法は、特別なフィルタ、すなわちオーケストレータ５４を利用する。オーケストレータ５４は、それが利用されることになるそれぞれのプリンタ用のフィルタ・パス内にインストールできる。別の実施態様においては、より複雑な規則を実装することが可能なシステムに対するフロント・エンドとして働くことができるように、単一のプリンタとともにそれがインストールされる。この態様でのインストールは、ユーザまたはドキュメントの内容による選択に基づいた条件付き実行を提供する。オプションとして、１より多くのオーケストレータが提供される。たとえば、オーケストレータのセットのうちの１つがインストールされ、ドキュメント内の画像、ジョブ自体のフットプリント、たとえばページ数、または大量のインクを消費するフルカラー画像に対するコントロール等の異なるレベルのコントロールを提供することが可能である。

例示的な実施態様は、より複雑なフィルタを提供し、またそれらのより複雑なフィルタの条件付き適用を可能にすることもできる。たとえば、プリンタの物理的な宛先に基づき、ワークステーションまたはユーザに基づいて、フィルタのセットが動的に変更されたかのように処理を変更することが可能である。ＸＰＳプリント・パス内における動的な変更の達成は、フィルタが変更されている間にプリント・サブシステムの停止およびリスタートを伴うことなく遂げられ、それによって、入力ドキュメント２３３および／または入力プリント・ジョブ・チケット２３２を処理または修正するため、および修正済み出力ドキュメント２４４および／または修正済み出力プリント・ジョブ・チケット２４６をジョブ出力２４８の部分として提供するための拡張された能力を提供することが可能である。

これらの能力は、フィルタ・リポジトリ４０および／または実行コンテキスト５８をプリント・パス・エンジン５６のファシリティから分けて維持する能力によって容易にされ、基本的にプリント・パス・エンジン５６に未知であり、かつプリント・パス・エンジンおよびデフォルトのファシリティと独立である。これは、リポジトリ４０を実装に中立なリポジトリとすることを容易にする。これは、フィルタおよび実行コンテキストが、プリント・パス・エンジンのファシリティの制約によって制限されない無制限の柔軟性を持つことを可能にする。オーケストレータ５４は、システムのユーザ・インターフェース・ディスプレイ２５２または出力リソース２２２のいずれかを通じて金額請求および利用度のレポートを生成するべく利用されることが可能な会計ファイル２５０等の独立した情報ファイルを維持することができる。

図６を参照するが、プリント・パス・エンジンの標準コンポーネント、たとえばプリント・パス・エンジンのフィルタとして１つまたは複数のオーケストレータがインストールされる（ステップ２６０）。追加のフィルタがプリント・パス・エンジンの外側のフィルタ・リポジトリ内において構成されるが、プリント・パス・エンジン自体には未知である（ステップ２６２）。インストールされたオーケストレータのうちの１つまたは複数が、その後、条件付きで、または特定のプリンタ、または複数の指定されたプリンタ、またはプリント・パス・エンジンに利用可能なすべてのプリンタのためのプリント・ジョブ要求のそれぞれの処理とともに起動される（ステップ２６４）。特定のプリンタは、オーケストレータを起動するだけの目的のために利用される仮想プリンタとしてもよい。オーケストレータ５４が起動されるとき、それがフィルタ・リポジトリのフィルタを処理し、ドキュメント自体および／または関連するプリント・ジョブ・チケットに基づいた動作を実行する（ステップ２６６）。実行される動作は、ドキュメントまたはプリント・ジョブ・チケットに対する修正、プリント・ジョブの中止、またはそのほかの処理、たとえば会計ファイルの維持、およびユーザの要求時に、または周期的なベースでの会計または利用度のレポートの作成等を含むことが可能である。

ドキュメントの処理の間における情報のストアおよび通信のためのＸＰＳプリント・ジョブ・チケット１４Ｂの使用に代えて、プロパティ・バッグ２４０またはそのほかの任意のメカニズムをこの目的のために利用することが可能である。オーケストレータ５４は、プリント・パス・エンジン内にインストールされるＸＰＳフィルタとして示されているが、オーケストレータがプリント・パス処理と通信する限り、それが必ずしもフィルタである必要はない。プリント・パスまたはワークフロー・パスの標準コンポーネントと類似のオーケストレータ５４のインストールは、プリント・パス・エンジン自体を修正することなくプリント・パス・エンジンの能力を拡張する好都合な方法を提供する。

前述したとおり、ポリシーの規則のシステムは、コード・ユニットが走ることになるコンピューティング・デバイス上、たとえばプリンティング・システム１６等の上で完全に構成されることが可能であり、またはシステムが集中的に、たとえばＣＡＳ６０等の上で管理されることが可能である。いずれの場合においても、図７では、その種のシステムの管理者がポリシーの規則を構成し（ステップ２８０）、オプションとしてそれらを１つまたは複数のポリシー・セットに結合する（ステップ２８８）。これらの規則は、それぞれトリガ条件およびコード・ユニットを包含し、その後フィルタ・リポジトリ４０内にストアされる。ポリシー・セット、すなわち規則のセットもまた、特定のリソース、たとえば特定のプリンタ等に対して構成可能であり（ステップ２９０）、言い替えると、規則のセットが作成された後は、規則に対してプリント要求がなされるときに必ずそれらが適用されるようにプリンタのキューに結合されることが可能になる。

トリガ条件は、標準化された条件のセット、すなわちそこから管理者が選択できるセットのうちの１つであるとしてもよく（ステップ２８２）、またはトリガ条件は、システムに固有の言語または任意の周知の処理言語で記述されるとしてもよい（ステップ２８４）。戻り値は、単純なゼロ対非ゼロのケースに限定されないが、ただ１つの値に対する、最後に実行された規則の戻り値の単純な評価は、以下の例示的なコード・スニペットと同様にほとんどのトリガ条件の基礎を形成できる。

ＩｆｒｅｔｕｒｎＶａｌｕｅＥｑｕａｌｓ１ＴｈｅｎｔｒｉｇｇｅｒａｃｔｉｏｎＥｎｄＩｆ（「戻り値が１に等しければ動作をトリガせよ」）

例示的な場合においては、コード・スニペット自体を除いてプログラミングがまったく要求されない。しかしながらプログラミングが利用される場合には、管理者がコード・ユニットを直接書き込み／プログラムすること、またはライブラリまたはそのほかからアップロードのためのプログラム済みユニットを選択することが可能である（ステップ２８６）。

規則が一旦、リポジトリ４０上において適正に構成されてしまえば、プリント要求を処理する間にそれらを使用する準備が整う。これが達成されるために、プリント・システム（「クライアント・システム」、個別のコンピュータ、および／または中央サーバ上にある）に、新しい構成を気付かせることが可能である（ステップ２９２）。クライアント・システム上における規則のインストールのために、クライアント・システム上にあるソフトウエア・エージェント１３０が、構成の変更に気付くべく、ＣＡＳ６０からの要求を受け入れるか（ステップ２９４）、または周期的なベースでリポジトリ４０をポーリングする（ステップ２９６）。それが、ＸＰＳフィルタ等の種々の必要とされるソフトウエア、および任意の必要とされる随伴ファイルをそれぞれのクライアント・システムにダウンロードする。ローカルの管理タスク（ローカル・スプーラのリスタートまたはプリント・ドライバの更新）もまた、このエージェントによって続行させることができる。

代替として、特定のＸＰＳフィルタがエージェント１３０と同じタスクを担持するが、プリント要求の時点における構成の更新を伴って進行する（ステップ２９８）。

システム固有の管理ツールおよび／またはカスタム・インストール・モジュールが利用されることもある（ステップ３００）。これらのツールは、システム更新の能力を提供でき、現在のシステム内においてすでに展開済みであるという利点を有する。

図８は、ウェブ・アプリケーションに関連して動作できるシステムを管理するための管理インターフェースの１つの実施態様を示す。規則を追加するための例示的なスクリーン３１０は、規則に名前を付けるための規則名テキスト・ボックス３１２を含む。トリガ選択エリア３１４は、管理者がトリガ・メカニズムのタイプおよび関連する値を選択することを可能にする。前述した例示的なコード・スニペット等の任意の説明を、説明入力エリア３１６内に直接書き込むことが可能である。コード・ユニット・プログラミング・エリア３１８内にフィルタ・コード・ユニットを直接書き込むため、またはあらかじめプログラム済みのコード・ユニットを、それの場所をコード・ユニット・アップロード・エリア３２０内において指定することによってアップロードするための用意もなされている。

図９を参照するが、作成された規則を１つまたは複数のグループに追加することが可能である。ポリシー・セットに規則を追加するための例示的なスクリーン３３０が示されている。セット名テキスト・ボックス３３２は、ポリシー・セットのための名前を管理者が指定することを可能にし、管理者は、セットの規則ボックス３３６内に示されるセットの規則に含ませるために利用可能な規則３３４から選択することができる。

次に、ＸＰＳプリント・パスのシナリオ内における前述したポリシーの規則メカニズムを組織化する例示的な実施態様の動作を説明する。クライアント・システムのユーザが、ドキュメントのためのプリント要求、すなわちプリント・ジョブ要求を発する。スプーラ、たとえばプリント・パス・エンジン５６が、その後、ドキュメント・プリント・データを、指定されたプリンタのためのプリンタ・キューに転送する。当該プリンタは、必ずしも本来的にＸＰＳフォーマットを理解するプリンタである必要はないが、そのプリント・パス内においてＸＰＳプリント・フィルタが利用され、したがって、ＸＰＳデータがオーケストレータ５４に利用可能となる。オーケストレータ５４は、ＸＰＳデータを、それがプリント・パスを通過するときに横取りし、要求しているユーザのユーザ情報、当該ＸＰＳデータ、およびポリシーの規則に基づいてそのデータに作用を及ぼす。この例示的な実施態様においては、オーケストレータ５４を、ＸＰＳプリント・パス内の第１のフィルタとして実装でき、それによってそれがプリント・パス内におけるドキュメント処理の望ましいコントロールを有することを可能にできる。

オーケストレータによる処理の結果は、たとえば作用なし（通過）、プリント・ジョブのキャンセル、別のプリンタへのプリント・ジョブの転送、会計、何らかの種類のドキュメント修正、統計的演算、その後の取り出しのためのドキュメントのストア等を含めた考えられる任意の形で多様化し得る。これらの結果は、処理ユニット２０〜２８の利用によってもたらすことが可能である。

１０ワークステーション、１２プリント・ドライバ、１４プリント要求，ジョブ要求、１４ＢＸＰＳプリント・ジョブ・チケット、１６プリンティング・システム、
１８プリント・パス・システム、２０，２２，２４，２６，２８処理ユニット２２処理ユニット、２４処理ユニット、２６処理ユニット、２８処理ユニット、３０プリント・サーバ，サーバ、３２ネットワーク、３４プリンタ、３６プリンタ、４０リポジトリ、４２サーバ・メモリ、４４サーバ・ストレージ・デバイス、４６，４８，５０，５２フィルタ、４８フィルタ、５０フィルタ、５２フィルタ、５４オーケストレータ、５６ＸＰＳプリント・パス・エンジン、５８実行コンテキスト、６０中央管理システム（ＣＡＳ）、６２中央フィルタ・リポジトリ、６４ＣＡＳメモリ、６６ＣＡＳストレージ・デバイス、６８，７０，７２，７４フィルタ・バージョン、７５ユーザ・インターフェース、７６構成処理ユニット、７８ダウンロード・ユニット、８０ポリシー・セット、８２ポリシー・セット、８４ポリシー・セットのグループ、８６ポリシー・セット、８８ポリシー・セット、９０ポリシー・セット、９２〜１０４，１１２〜１１６，１２０〜１２４規則、１０６規則、１０８規則、１１０規則セット、１１８規則セット、１２６条件、１２８作用、１３０ソフトウエア・エージェント、２２０処理構成、２２２プリンタ，出力リソース、２２４スケジューラ、２２６フィルタ・パイプライン・マネージャ、２２８フィルタ構成ファイル、２３０第１のフィルタ、２３１ＸＰＳスプール・ファイル、２３２ＸＰＳプリント・ジョブ・チケット，入力プリント・ジョブ・チケット、２３３ドキュメント部分，入力ドキュメント、２３４第２のフィルタ、２３６フィルタ間コミュニケータ、２３８最後のフィルタ、２４０プロパティ・バッグ、２４２シリアル化サービス、２４４出力ドキュメント、２４６出力プリント・ジョブ・チケット、２４８ジョブ出力、２５０会計ファイル、２５２ユーザ・インターフェース・ディスプレイ、３１０スクリーン、３１２規則名テキスト・ボックス、３１４トリガ選択エリア、３１６説明入力エリア、３１８コード・ユニット・プログラミング・エリア、３３０スクリーン、３３２セット名テキスト・ボックス、３３４利用可能な規則、３３６セットの規則ボックス。

Claims

デフォルトのワークフロー・パスより豊かなコンテキストでフィルタの実行を可能にするための方法であって、
それぞれのフィルタがポリシーの規則および関連するトリガ条件を包含する複数のフィルタを構成することと、
前記複数のフィルタを、前記デフォルトのワークフロー・パスと独立したリポジトリ内にストアすることと、
前記ポリシーの規則のうちの選択されたものを少なくとも１つのリソースに結合することと、
前記複数のフィルタに対するアクセスを有する前記デフォルトのワークフロー・パス内にオーケストレータをインストールすることであって、前記オーケストレータが、前記デフォルトのワークフロー・パスに提出されたジョブのためのデフォルトのワークフロー・パス処理の間に、前記フィルタのためのトリガ条件が前記ジョブについて評価され、かつトリガされたポリシーの規則が適用されるように実行されるべく構成されることと、
を包含する方法。
前記方法は、さらに、
複数のポリシーの規則を少なくとも１つのポリシー・セットに結合することであって、前記ポリシーの規則のセットが、前記セット内の前記ポリシーの規則が適用されるべき順序を決定することを包含し、
前記ポリシーの規則のうちの選択されたものおよび関連するトリガ条件を少なくとも１つのリソースに結合するステップが、前記少なくとも１つのポリシー・セットのうちの選択されたものを少なくとも１つのリソースに結合することを包含する、請求項１に記載の方法。
デフォルトのワークフロー・パスより豊かなコンテキストでフィルタの実行を可能にするためのシステムであって、
デフォルトのワークフロー・パスと、
ポリシーの規則であって、それらのうちの選択されたものが少なくとも１つのリソースに結合されるポリシーの規則および関連するトリガ条件をそれぞれのフィルタが包含する複数のフィルタをストアする、前記デフォルトのワークフロー・パスと独立のリポジトリと、
前記複数のフィルタに対するアクセスを有する前記デフォルトのワークフロー・パス内にインストールされるオーケストレータであって、前記デフォルトのワークフロー・パスに提出されたジョブのためのデフォルトのワークフロー・パス処理の間に、前記フィルタのためのトリガ条件が前記ジョブについて評価され、かつトリガされたポリシーの規則が適用されるように実行されるべく構成されるオーケストレータと、
を包含するシステム。
デフォルトのワークフロー・パスを有するクライアント・システムための、前記デフォルトのワークフロー・パスが第１の構成済みフィルタを有する、前記第１の構成済みフィルタを動的に更新するための方法であって、前記第１の構成済みフィルタが構成済みの第１のポリシーの規則および関連する第１のトリガ条件を包含し、前記方法が、
第２の構成済みフィルタであって、第２のポリシーの規則および関連する第２のトリガ条件を包含する第２の構成済みフィルタを構成することと、
前記第２の構成済みフィルタを前記デフォルトのワークフロー・パスと独立のリポジトリ内にストアすることと、
前記構成された第２の構成済みフィルタを前記クライアント・システムに引き渡すことと、
を包含し、前記引き渡すことが、
前記第１の構成済みフィルタを前記第２の構成済みフィルタに許可ユーザの要求により管理アプリケーションによって置換することと、
前記第２の構成済みフィルタが前記リポジトリ内にストアされるときを決定するべく前記リポジトリを前記クライアント・システムによって周期的にポーリングし、前記第１の構成済みフィルタを前記第２の構成済みフィルタに置換することのうちの少なくとも１つを包含する方法。