JP2007207261A - メールピースを作成するためのドキュメントフォーマット及びプリントストリーム変更 - Google Patents

Abstract

【課題】メールピースを生成する方法を提供する。
【解決手段】本方法は、メールピースコンテンツ素材の電子的アプリケーションファイルを作成するステップとソフトウェアアプリケーションからプリントストリームデータを発生させるステップとプリントストリームデータをオブジェクト指向データに変換するステップを含む。オブジェクト指向データは、その後、複数のデータセットを形成するために解析され又はセグメント化される。データセットは、１又は複数のデータパケットからなり、データを指示するためのオブジェクトディクショナリを含んでいる。各データセットは、その後、メールピースインサーターにおいて利用するためにメールピースコンテンツ素材を生成するように処理される。処理は、ページ、メールピースドキュメント、メールピース、又は全メールピースデータ実行ファイルの形態で、データを複数の論理ドキュメントに再構成するステップを含む。
【選択図】図１

Description

本特許出願は、“メールピースインサーターに対するリプリント機能（REPRINT FUNCTION FOR MAILPIECE INCERTERS）”と称する米国特許番号第１１／３４４，３４８号及び“（メールピースコンテンツ変更のためのルールエンジン）RULES ENGLINE FOR MAILPIECE CONTENT MODIFICATION”米国特許番号第１１／３４４，２６６号に関する。

本発明は、概して、メールピースを生成する方法に関し、より詳細には、メールピース挿入システムと組み合わせて用いるときにメールピースの作成、操作及びプリントを容易にする新規かつ有用な方法に関する。

メールピース挿入システム又は“メールピースインサーター（ｍａｉｌｐｉｅｃｅ ｉｎｓｅｒｔｅｒ）”は、大量のメール通信に対して意図したメールピースを生成するために一般に使用される。上記のメールピースインサーターは、典型的には、各メールピースのコンテンツが特定の受取人に関する場合に大量の特定のメール通信を生成するために、銀行、保険会社及び公益会社などの組織によって用いられる。また、ダイレクトメール業者などの他の組織は、各メールピースのコンテンツが各受取人について実質的に同一である場合に大量の郵便物を生成するためにメールピースインサーターを用いる。

多くの点で、典型的なインサーターシステムは、製造アセンブリラインに似ている。シート及び他の原材料（すなわち、ペーパーストックのウェブ、エンクロージャ及びエンベロープ）は、入力としてインサーターシステムを投入している。インサーターシステムにおける様々なモデルは又はワークステーションは、完成したメールピースが生成されるまでシーツを処理するために協同して機能する。典型的には、インサーターシステムは、素材の事前プリントシートすなわちトランスポートデッキにおけるメールピースのコンテンツ素材（material）を照合することによってメールピースを用意する。事前プリントシートの照合は、追加のシート又は挿入が事前定義された基準に基づいて加えられ得る場合にシャシーモジュールに対して継続し、例えば、挿入は、特定の地理学的領域の受取人に送信される。続いて、照合が終了されエンベロープに置かれる。一度満たされると、エンベロープは、閉じられ、密閉され、検量され、分類される。郵便料金メータは、その後、メールピースの重さ及び／又は大きさに基づいて郵便切手をつけるのに用いられる。

従来、インサーターシステムは、メールピースコンテンツ素材をメールピースエンベロープと結合すること、すなわちエンベロープにコンテンツ素材を挿入することに制限されていた一方、インサーターシステムは、現在では、メールピースを訂正しリプリントする目的で、又は顧客関係管理（ＣＲＭ）システムなどのダウンストリーム処理によって用いるために、（ｉ）メールピースコンテンツを変更し、分類し、操作し、（ｉｉ）プリントストリーム／コンテンツ素材から情報を読み取り、解釈し、抽出し、（ｉｉｉ）各メールピースの処理ステータスに関する情報を監視し、記録し、記憶する能力を含む広範囲の特徴を提供している。

インサーターがより進歩し、複雑化されるようになるにつれて、これらのマシンのセットアップ及びプログラミング要求は、対応してより複雑かつ困難になっている。結果として、上記のメールピースインサーターのオリジナル機器製造業者（ＯＥＭ）にとっては、その適切／有効なオペレーション（操作）に対してメールピースインサーターのコマンド／インストラクションを定義するために顧客のオペレーション（操作）／ニーズに詳細に熟知することが必要になっている。

顧客とＯＥＭの間の上記の通信はインサーターが利用するためのルール／コマンドを展開するために唯一の機会を提供する一方で、オリジナルのセットアップ／ルールに対する変化が必要とされ、（再度、ＯＥＭの特有のスキル及び知識を必要とする）後続の変更に関連するコストが極端に高くなり得ることを評価するであろう。

それゆえ、メールピースインサーターシステムにおいては、ドキュメントの作成、操作及びプリントを容易にする方法が必要とされる。

メールピースインサーターにおいて利用するためのメールピースコンテンツ素材を生成する方法が提供される。前記方法は、メールピースコンテンツ素材の電子的アプリケーションファイルを作成するステップと、ソフトウェアアプリケーションからプリントストリームデータを発生させるステップと、前記プリントストリームデータをオブジェクト指向データに変換するステップとを含んでいる。オブジェクト指向データは、その後、複数のデータセットを形成するために解析され、セグメント化される。データセットは、１又は複数のデータパケットからなり、データを指示するオブジェクトディクショナリを含んでいる。各データセットは、その後、メールピースインサーターでの利用に対してメールピースコンテンツ素材を生成するために処理される。処理は、ページ、メールピースドキュメント、メールピース、又は全メールピースデータ実行ファイルの形態で複数の論理ドキュメントにデータを再構成するステップを含み得る。メールピースコンテンツのプリントは合理化され、メールピースインサーターの効率及びスループットを上げる。

メールピースを作成し、操作し、プリントする本発明の方法は、メールピース挿入システムの場面において説明される。本発明の方法を実施するのに使用される様々な方法ステップを議論する前に、様々なコンポーネント及びシステム要素の協働を含むインサーターのシステムアーキテクチャを理解することは有用である。図１、１ａ及び１ｂにおいて、メールピースアセンブリシステム／アーキテクチャ２０は、メールピースインサーター１０、システムプロセッサ１２（例えば、サーバ）及びクライアント／ユーザプロセッサ１４（例えば、ユーザＰＣ）を備えている。システム要素１０、１２、１４の各々は、例えば、キーボード又はマウスなどのオペレータ入力装置からオペレータ入力を受け付け、ディスプレイモニタを介して出力を表示し、システムプロセッサ上でプログラムコードを実行することができる。要素１０、１２、１４がネットワーク接続されるので、入力／出力は、システム要素１０、１２及び１４のいずれかから作られ／表示され得る。各々の能力にもかかわらず、サーバ／システムプロセッサ１２は、メールピースインサーター１０上で処理されているメールピースついての情報を監視して記録する。同時に、クライアント／ユーザプロセッサ１４は、完全なメールピースを生成するためにメールピースインサーター１０によって用いられるメールピースコンテンツを作成するために様々なアプリケーションソフトウェア２２及びシステムプラグイン２４を実行する。

システム要素１０、１２、１４は、閉ループ又は開ループオペレーティングモードで機能し得る。オペレーティングモードの原理の差は、システム要素がネットワークラインＮＬを介してリアルタイムで通信するか又は自主的に所定のアルゴリズムに基づいて通信するかどうかに関係する。閉ループオペレーティングモードでは、様々なシステム要素が各メールピースの製作に関する情報を運搬し、監視し、記録するために通信する。すなわち、システム要素１０、１２及び１４は、正確にアセンブルし、エラー／欠陥を検出し、メールピースをリプリントするのに用いられるであろう重大な情報を共有し、記憶する。より詳細には、ユーザＰＣは、メールピースドキュメント及びメール実行データファイルを生成するために閉ループモードで処理する前に実行する一方で、メールピースインサーター１０及びシステムサーバ１２はリアルタイムで通信する。開ループオペレーティングモードでは、サーバ１２は必要とされないため、インサーター１０は、自主的に／独立して動作し、メールピースインサーター１０の内部のプログラムされた情報を信頼し、必要なメールピースアセンブリインストラクションを提供する。

閉ループ又は開ループのいずれの構成で動作させようとも、システムアーキテクチャ２０は、アセンブリインストラクションコードＡＣ（すなわち、メールピース又はスキャンコード）を使用し、ユーザプロセッサ１４からメールピースインサーター１０へメールピースの製作に関する情報を通信する。この中で用いられる場面においては、“アセンブリ又はインストラクションコードＡＣ”（図１ｂ参照）は、メールピースのコンテンツシート２８に（典型的には、ドキュメントの右手又は左手の余白に）配置されるマーク又はマークのセットであり、メールピースインサーター１０の１又は複数のオペレーション／ファンクションを制御する。上記の制御オペレーションは、新規なドキュメントがメールピースコンテンツシートのスタックが開始し及び／又は終了するときに関する情報、すなわちドキュメントの最初の及び／又は最終のページを含んでいてもよい。この情報があれば、メールピースインサーター１０は、１セットのコンテンツシートを別のものから適切に分離することができる。ユーザプロセッサ１４は、（ユーザプロセッサ１４がネットワークラインＮＬを介して接続されているならば、）アセンブリインストラクションコードＡＣをインサーター１０からアップロードすることができ、適当なマーク（例えば、数値的な識別番号）をメールピースコンテンツ素材のオブジェクト指向データファイルに取り込むことができる。代替的に、ユーザプロセッサ１４は、メール作成プリントマネージャ２４のプログラムされた情報を信頼し、変換されたイメージにおいてアセンブリコードＡＣを生成することができる。メールピースコンテンツ素材をオブジェクト指向データファイルに変換する重要性及びメール作成プリントマネージャ２４の利用は、続く段落においてより詳細に議論されるであろう。

本発明の一実施形態では、論理ドキュメントを指示する電子アプリケーションファイルからコンテンツ素材を生成する方法が提供される。前記方法は、（ｉ）ソフトウェアアプリケーションによってコンテンツ素材の電子ファイルを生成するステップと、（ｉｉ）与えられたフォーマットの電子ファイルからデータのプリントストリームを発生させるステップと、（ｉｉｉ）オブジェクトディクショナリによって定義され又は指示されるオブジェクトを有するオブジェクト指向データに前記プリントストリームを変換するステップと、（ｉｖ）前記オブジェクト指向データを、各々のデータが少なくとも１つのデータパケットを備えた複数のデータセットに構文解析し又はセグメント化するステップと、（ｖ）前記オブジェクトディクショナリを各データセットに付加するステップと、（ｖｉ）少なくとも１つの論理ドキュメントを作成するために前記データセットを処理するステップと、（ｖｉｉ）メールピースインサーターシステムと関連して利用するために前記論理ドキュメントをプリントするステップとを備えている。

図１、１ａ、１ｂ及び２を参照すると、ワード処理、スプレッドシート又はフレームらフィックプログラムなどのアプリケーション２２は、ユーザスペースプロセスを実行し、メールピースコンテンツの電子データファイルを発生させるのにステップＡで用いられる。アプリケーション２２は、様々なカーネルスペースプロセスを行い制御するためのオペレーティングシステムによって実行される。本発明の教示を与えるように適応された典型的なオペレーティングシステムは、ウィンドウズ２０００ＯＳ（ウィンドウズはオペレーションのその原理基礎を有する米国ワシントン州のマイクロソフト社の登録商標である）を含んでいる。しかしながら、本発明は任意のオペレーティングシステムを使用できるようになっていることを評価すべきである。

ステップＢでは、オペレータは、アプリケーションに与えられたデータのプリントストリームを発生させるプリントコマンドを入力する。すなわち、ウィンドウズベースのオペレーティングシステム（ＯＳ）に適用可能なグラフィックデバイスインターフェース（ＧＤＩ）は、メールピースコンテンツ素材のテキスト及びグラフィックを適当に与えるためのアプリケーションによって用いられる。ＧＤＩファンクションは、テキストを抜き取り、パスを作成し、ビットマップ＆グラフィックイメージ（例えば、線、曲線、閉図（closed figures）など）を発生させるのに用いられ得る。さらに、アプリケーションソフトウェアは、ＧＤＩファンクションを用いて、オペレーティングモードを設定し、例えば、プリンタ又はビデオディスプレイなどの出力デバイスの最新の選択をする。オペレーティングモードは、（ａ）テキスト及び背景色、（ｂ）色がディスプレイ表面に既に存在する色とどのように結合するかを特定する混合モード、（ｃ）アプリケーションソフトウェアによって用いられる座標が出力デバイスの座標系に対してどのようにマッピングされるかを指令するマッピングモードを含み得る。最新の選択は、どの表示オブジェクト（例えば、ペン、ブラシ及びフォント）が用いられるようになっているかを識別し得る。上記の属性を発生させるためのコード／アルゴリズムは一般に当業者には知られているので、そのようなプログラムコードは、この中でより詳細には議論しない。属性がプリントストリームデータを表示するためにＧＤＩ（又は同様のプログラムコード）などの上記のデバイスを用いて定義されることを言及するには十分である。

ステップＣでは、ＧＤＩ（図１ａ参照）によって表示されるプリントストリームデータ（ＰＳＤ）は、ポータブルドキュメントフォーマット（ＰＤＦ）ファイルに使用されるそれらのオブジェクト／定義／ディクショナリなどのオブジェクト指向データＯＯＤに変換される。ＰＤＦ変換がオブジェクト指向データファイルに対して一般的な用語として産業上知られているので、用語ＰＤＦデータ及びオブジェクト指向データは、互換性をもって用いられ得る。しかしながら、上記の変換は、典型的には、ＰＤＦドキュメントに割り当てられ／ＰＤＦドキュメントによって定義される特定のオブジェクト／属性に制限されるものではないことが評価されるべきである。例えば、メタコードデータは、ＰＤＦデータと同じ特徴／属性を幾つか有しているが、広い意味では、それでもなおオブジェクト指向データである。

ステップＣの議論に戻ると、プリントストリームデータＰＳＤは、従来のプリンタドライバ３０によってプリントするための準備においてメール作成プリントマネージャ及び関連するプラグインモジュールによって遮断され、操作される。より詳細には、図１ａにおいて、バーチャルプリントドライバ２４ＰＤのプログラムコードは、（オペレータプリントコマンドに応答して発生する）プリントストリームデータＰＳＤを定義されたオブジェクト／属性を有するオブジェクト指向データＯＯＤに変換するようになっている。先行する段落で述べたように、オブジェクト指向データＯＯＤのオブジェクト／属性は、選択されたオブジェクト及び割り当てられた属性は、選択されたフォーマットに依存して異なる意味を有するかもしれないが、本質的には、ＰＤＦドキュメントに使用されるものと同様である。さらに、これらのオブジェクトは、プリントストリーム内のデータを位置決め／識別するためにオブジェクトディクショナリＤＩＣ（又はヘッダ）において指示される。

プリントストリームデータＰＳＤは、その後、各々が１又は複数のデータパケットを備えている複数のデータセットに解析され又はセグメント化される。データセットの数及び大きさは、データパケットがより小さく、データセットを備えるために複数のパケット（例えば２又は３以上）を含み得るが、一般には、オリジナルドキュメントの個々のページの大きさによって決定される。ステップＤでは、ディクショナリは、各データセットに付加／結合されるので、結果として、各々が共有されたオブジェクトディクショナリを有する多数のデータセットを生じる。オブジェクトディクショナリは、多くのデータセットに対して共通であってもよいし、特定のデータセット／パケットのオブジェクトを指示／識別するように個々に変更し又は構成してもよい。それゆえ、構成可能なディクショナリを各データセット／パケットに付加することによって、個々のデータセット／パケットは、特別に変更し操作してもよい。

プリントストリームデータを（各々が付加／結合されたディクショナリを有する）複数のデータセットにセグメント化することによって、メールピースインサーターのスループットは、大きく強化される。すなわち、ＰＳＤをより小さなユニットにセグメント化することによって、プリンタドライバは、セグメント化されたデータのプリントを増量させて開始することができる。したがって、プリントは、全電子ファイル及びディクショナリコンテンツが完全に処理される前に始めることができる（ディクショナリは、典型的は、電子ファイルの終わりに追加される）。さらに、プリントストリームデータのオブジェクト指向データＯＯＤへの変換は、アプリケーションソフトウェアからプリントストリームデータＰＳＤの操作を可能にし実行するための特有の機会を提供する。例えば、ＯＯＤは、ユーザ／システムオペレータがドキュメント内の領域を定義し、識別された領域から読み出し、選択された領域から情報を抽出し、特定の領域に含まれる情報に関してオペレーションを実行し、新規な情報（例えば、挿入スキャンコード）を挿入し、メールコンテンツのページを整理し直し、そのページ付けを変更し、メールピースコンテンツからページを追加及び／又は削除することなどを可能にする。続いて、オブジェクト指向データは、今までユーザ／システムオペレータに対して直接利用可能であったコンテンツ素材生成／メールピース製作と共に情報を変更し、操作し、挿入及び／抽出するための柔軟性及び能力をより大きく提供する。さらに、メールピースインサーターの場面では、そのような能力は、メールピースインサーターを動作させるのに用いられるプログラミング言語に熟練してＯＥＭを組み合わせた努力の成果、及びメールピース実行データファイルの特有の要求及び目的に関する知識を有する顧客を通じてのみ利用可能であった。

サーバアプリケーション２４ＳＡは、その後、オブジェクト指向データ及びディクショナリＯＯＤを個々のページすなわちメール実行データファイルの所定の最小の構築ブロックに再構成するのに使用されている。次に、プラグインマネージャ２４ＰＩは、最適化及びタイミング要求に依存して、ページ、ドキュメント又はメールピースのようなデータを分割して追跡する。そのようなＰＩマネージャは、データのスループットを最適化しタイミングをとるための技術において周知であるため、最適化アルゴリズムの更なる議論は提供しないし、そのような詳細についても述べない。

なお、様々なモジュール又はプラグイン２４ＸＸは、論理ドキュメントの要求に従ってデータを変更し、操作し、プリントするようになっている。論理ドキュメントは、様々なプラグインによって実行されるコマンド及び制御に従って構成されるデータの任意のコンパイルである。最後に、ＯＯＤは、従来のプリンタハードウェアを用いてプリントするために、ＯＤＤを必要なプリンタ制御言語ＰＣＬに変換する特定のプリンタドライバ３０によって認識され得る表示可能なデータに逆に変換される。

ステップＥでは、アセンブリ／スキャンコードＡＣは、メールピース２８の各々に対するインストラクションを指示して定義される。アセンブリコードＡＣを展開して実行するために、プラグインマネージャ２４（図１参照）は、各々が互いに異なり本質的に自主的なファンクションを有する、複数のメールピースプラグイン又はモジュール２４ＣＧ、２４ＭＣ、２４ＰＰ、２４ＤＦ、２４ＲＥなどを含む。さらに、プラグインマネージャ２４は、これらのプラグインをイネーブル／ディセーブルし、特定のプリントジョブを実行するためのワークフローを管理する。アセンブリコードＡＣを定義することは、このときに起こる必要はないが、プリントストリームデータＰＳＤを表示する前又は表示した後のいずれかの時に展開され得ることも評価されるべきである。以下の表Ｉは、プラグインマネージャ２４によって管理される様々なプラグインのリスト及び簡単な説明である。

表Ｉ

アセンブリ／スキャンコードＡＣを生成するために、メールピースプリント／プラグインマネージャ２４は、様々なユーザ／システムオペレータコマンドを記号表現（例えば、数字的識別、ＯＭＲマーク、又はバーコード記号使用）へ変換するアセンブリ／スキャンコードジェネレータプラグイン２４ＣＧを含んでいる。これらの記号マーク付け（symbolic markings）は、様々なアセンブリインストラクションを実行するためにメールピースインサーター１０によって認識される。より詳細には、メールピースプリント／プラグインマネージャ２４は、特定の入力コマンドを処理することができる適当なプラグインに要求することによって入力コマンドを処理する。入力コマンドの例は、アセンブリ／スキャンコード又はその一部によって表現され、（ｉ）ドキュメントブレーク（break）、すなわち、ドキュメントブレーク（break）プラグインを用いてドキュメントがどこで始まりどこで終わるか、（ｉｉ）ドキュメント印刷、すなわち、ドキュメントが単一面に印刷されるか、又は両面印刷プラグインを使用することによって両面印刷されるか、（ｉｉｉ）ドキュメント結合、例えば、同一のアドレスを有するドキュメントがドキュメント選択プラグインを用いて単一のエンベロープ（封筒）に結合されること、（ｉｖ）ドキュメントルール、例えば、閾値を超えたインボイス合計を有するドキュメントがルールエンジンを用いてメールピース作成プラグインによって決定される挿入を受信することを含んでいる。メールピースプリント／プラグインマネージャ２４は、その後、様々な入力コマンドを記号で表すアセンブリ／スキャンコード構成を生成／選択する。アセンブリ／スキャンコードＡＣは、ＰＤＦドキュメントの所定の位置又は領域に配置される一連の長短のバー（ＯＭＲマーク）を含む様々な形態をとり得る。典型的には、そのようなマークＳＣは、ドキュメントの左右の余白部に現れるであろう（図１ａ参照）。

ステップＦでは、（図１に示されるメール作成プリントマネージャ＆プラグイン２４によって生成される）スキャンコードデータを含むオブジェクト指向データファイルは、電子的なページ／ドキュメント／メールピースを形成するように構成され、印刷される。閉ループモードでは、ページ、メールピース又はドキュメントは、必要なメールピースアセンブリインストラクションを得る目的でシステムプロセッサ１２が読み出すことができる識別情報を含んでいてもよい。開ループモードでは、ページ又はメールピースは、ドキュメントの余白部にＯＭＲ又はバーコード記号による表示を含んでもよい。特定のプリンタによって認識されるためには、電子データをプリント制御言語（ＰＣＬ）フォーマットに逆に変換することが必要であり得る。この転換は、典型的には、ジョブを実行するように要求されたプリンタ３２に基づいてオペレーティングシステムによって選択されるプリンタドライバ３０（図１を参照）によって実行されるであろう。ファイルを適当なＰＣＬフォーマットに逆に変換するのに利用可能な様々な処理にもかかわらず、処理されるデータは、プリントトゥープリンタプラグイン２４ＰＰを用いて印刷される。さらに、印刷されたメールピースコンテンツ素材２８は、メールピース挿入システム１０によって処理するために使用可能なスタックを形成するために照合され得る。システムアーキテクチャ２０がメールピースコンテンツ素材２８を印刷するためのスタンドアロンのプリンタ３２を表す一方で、そのプリンタ３２は、メールピース挿入システム１０を用いて統合され得る。それ自体として、メールピースコンテンツ素材の転送、すなわち、プリンタ３２からメールピース挿入システム１０への転送は必要とされないであろう。すなわち、メールピースコンテンツ素材２８を１又は複数の入力トレー３６ａ、３６ｂへロードすることをもはや必要としないであろう。

厳密な議論をすると、プラグインマネージャ２４ＰＩは、２つのパスのうちの１つからのオブジェクト指向データを受信してもよい。先行する段落に記載されたパスは、“プリント挿入パス”（すなわち、上記のステップＡ−Ｅ）に関するものである。その点で、プリントコマンドは、アプリケーション２２に対して実行又は入力され、プリントストリームデータは複数のオブジェクト指向データセットに通知割り込み（インターセプト）／セグメント化／操作され、後続の処理、すなわち、様々なプラグインによる処理のためにプラグインマネージャに提供される。既に述べたように、このパスは、データを操作するためのスループット及び柔軟性を強化する。代替的に、オブジェクト指向データ、例えば、ＰＤＦファイルＦＢ（図１ａを参照）は、ＰＤＦファイルソースからプラグインマネージャに直接的に与えてもよい。例えば、メインフレームプロセッサは、様々なプラグインによって処理するために全ＰＤＦメール実行データファイルを直接的にプラグインマネージャへ生成してもよい。この交代するパスでは、データ変換すなわちオブジェクト指向データへの変換は必要とされず、データは直ぐに処理され得る。それ自体として、データセット／パケット（各々がそれ自身の構成可能なディクショナリを有する）のデータを区分する能力がないために、データを変更するための上述の柔軟性が失われるが、オブジェクト指向データ変換を実行するのに必要とされる時間が軽減される。

図１及び３では、システムプロセッサ１２は、ステップＧにおいて、処理データの全て、すなわち、特定のプリントジョブと関連するデータセットの全てを、後の利用のため又は更なる電子ファイル操作のためにリポジトリへ記憶することができる。その原理の利用は、紙詰まり、挿入エラー、又は取り扱いを誤った／取り逃したシートから生じ得る破損した又は不良のメールピースをリプリントすることに関係する。図３では、上記のプリント機能を実行する方法ステップは、以下により詳細に説明する“リプリントサブルーチン”として参照される。リプリント機能はまた、共通に所有される同時継属中の“リプリントサブルーチン（Reprint Subroutine）”と称する特許出願に詳細に述べられており、その内容は完全にこの中に参照によって取り込まれている。

ステップＨでは、メールピースコンテンツ素材２８の照合は、コンテンツ素材２８の構成及び／又はサイズに依存してメールピースインサーター１０の１又は複数の入力トレー３６ａ、３６ｂにロードされる。入力トレー３６ａ、３６ｂに加えて、メールピースインサーター１０は、挿入物（例えば、広告、クーポン、情報文献など）をメールピースコンテンツ素材２８と組み合わせるために、一対の挿入トレー３８ａ、３８ｂを含み得る。そこで、コンテンツ素材２８は、メールピースインサーター１０に送り込まれ、コンテンツ素材２８が処理され搬送されるときに電気的に及び／又は光学的に走査される。すなわち、アセンブリ又はスキャンコードＡＣは、製作されたメールピース４０のアセンブリ及び／又はメールピースインサーター１０によって実行されることになる様々なオペレーションに重大な情報を取得するために読み出され得る。既に述べたように、ドキュメントが両面印刷されることになるかどうか、挿入物がコンテンツ素材に組み合わされるか又は追加されることになるか否かなど、アセンブリスキャンコードＡＣはドキュメントのページ番号を含む様々な情報／インストラクション／コマンドを含み得る。

ステップＩでは、メールピースインサーター１０のインサーター制御システム（ＩＣＳ）５０ＩＮは、サーバ／システムプロセッサ１４の制御システムエンジン（ＣＳＥ）５０ＳＥに対するメール実行のステータスに関する情報を感知して中継する。メールピースインサーター１０は様々な光センサー及び走査デバイス（示されていない）、例えば、インサーター１０の給電（feed）パスに沿って配置される光電セルを取り入れているので、メールピースは、ＩＣＳ５０によって独立して追跡され、１つのメールピースが成功して終了されたかどうかを決定する。

ステップＪでは、ＣＳＥ５０ＳＥは、その後、完成したジョブ実行のリストを展開し、メール実行データファイル（ＭＲＤＦ）５２にそれを記録する。記録された情報の範囲を評価するために、ＭＲＤＦ５２は、成功して終了した場合にそのメールピースに関するステータス情報を含む各メールピースの処理（すなわち、各メールピースに直接関係のあるアセンブリインストラクション）についての特定のジョブ実行情報を含んでいる。付加的に、ＭＲＤＦ５２は、処理がいつ及び／又はどこで失敗したか（例えば、紙詰まり）、どのメールピースが影響しているかに関する情報を含んでいる。ＣＳＥ５０及びＭＲＤＦ５２が特定のメールピース製作ジョブに含まれる個々のメールピースに特定の情報を制御し／含んでいる一方で、制御システムアプリケーション（ＣＳＡ）ファイル５６及び制御システムデータベースファイル（ＣＳＤＦ）５８は、メールピース製作ジョブに特定の情報を制御し／含んでいる。例えば、制御システムアプリケーションファイル５６は、複数のメールピース製作ジョブ、例えば、３つのメールピースインサーター１０に渡って３つのジョブを制御している。同様に、ＭＲＤＦ５２は、特定のメールピース製作ジョブに対するそれぞれ個々のメールピースに特有の情報を記憶する一方で、ＣＲＤＦ５８は、各ジョブ実行に特有な情報、例えば、完了までの推定時間又は特定のメールピースインサーター１０に用いられるエンベロープナンバー（number envelops）を記憶し得る。

ステップＫでは、ＣＳＥ５０ＳＥは、ＭＲＤＦ５２に置かれている終了したジョブ実行のリスト（すなわち、成功して製作されたメールピースから生じた結果）について問合せ、各々に関連するリプリントファイル、すなわち、リプリントリポジトリ３４に置かれているリプリントファイルを削除する。それ自体、残っているファイルは、リプリントファイルを含むものであるため、ＭＲＤＦ５２は、破損及び不良のメールピースを識別／列挙するために照合調整（reconcile）される。したがって、ユーザは、その後、リプリントファイル及びジョブに対してＭＲＤＦ５２に含まれる任意の他の情報を有するジョブのリストを選んで表示し得る。そのリストから、ユーザは、破損した又は不良のメールピースの全てを選んで再び印刷し、又は、完成したリプリントファイルリストから特定のプリントジョブ（例えば、高い優先順位を指定されているもの）を選択することができる。オプションで、ユーザは、欠陥のあるメールピースアセンブリに対する原因であり又は欠陥のあるメールピースアセンブリを生じさせ得る一定の情報を確認するために、１又は複数のメールピースを選んでプレビューしてもよい（すなわち、プリントプレビュープラグインを用いる）。例えば、アセンブリ／スキャンコードＡは、メールピースインサーター１０のＩＣＳ５０ＩＮに対してアセンブリコマンドを通信するのに不適切に符号化されているかもしれない。

一度、ユーザが再び印刷されることになるメールピースを選択すると、ＣＳＥ５０ＳＥは、コンテンツ素材ページ２８のインデックスを発生させ、メールピース作成プリントマネージャ２４の全ての無関係なプラグインを使用禁止にする。システムは、プラグインを使用禁止にし、ユーザＰＣに対する処理の容量／時間を低減させる。残っている使用可能なプラグインは、一般には、プリントトゥープリンタプラグイン２４ＰＰを含み、オプションで、印刷プレビュープラグイン（図示されていない）を含んでいる。ステップＬでは、ＣＳＥ５０ＳＥは、対応するリプリントファイルをリプリントリポジトリ３４からロードし、ステップＭでは、メールピースインサーター１０によって処理するためにコンテンツ素材２８を印刷する。その方法は、その後、リプリント及び反復のために識別されるそれらの選択されたメールピースのみに対して、ステップＨからＫを、必要であり又はオペレータによって要求される回数分、再度行う。

ステップＥ（図２）におけるオブジェクト指向データファイル（すなわち、符号化ファイル）が破損し又は欠陥のあるメールピースをリプリントすることに関して付加的な柔軟性を提供する一方で、オブジェクト指向データファイルはまた、ユーザ／システムオペレータがメールピースコンテンツの全ての可視化画像を得ることができるようにし、結果として、フィールド、ルール及びエクスプレッションを実行するためのグラフィック編集ツールを導入する唯一の機会を提供する。ネットワークを形成したしアーキテクチャを用いて、ユーザ／オペレータは、任意のＰＣベースの入力及び／又は表示デバイスを用いることができ、メールピースジョブ実行の任意の選択されたメールピースのイメージを検索する。すなわち、グラフィックユーザインターフェースデバイスは、メールピースコンテンツ素材２８を視覚的に検査し又は編集する目的でメールピースインサーター１０又はシステムプロセッサ１２に、又はユーザＰＣ１０に関連してインストールしてもよい。

図４を付加的に参照すると、そのようなグラフィックツールをシステムアーキテクチャ２０に導入する方法ステップが示されている。方法ステップ又はアルゴリズムに関して、グラフィックス編集ツールは、メール作成プリントマネージャ２４の幾つかの付加的なプラグイン又はモジュールを起動する“ルールエンジンサブルーチン”として参照される（図１参照）。

ステップＮでは、少なくとも１つのメールピース又はメールピーステンプレートがモニタ上に表示される。定義フィールドプラグインステップＯを用いて、ユーザは、サンプルメールピース又はメールピーステンプレートに関して空間的な位置、場所又は領域を様々な既知の強調表示技術の任意の１つによって選択する。典型的には、ポインタは静止され、ドラッグされ、リリース／ドロップされて、入力デバイス（典型的には、ボールピックアップを有するマウス）の仮想的な２次元平面内の移動によって確立される方形領域を定義する。代替的には、他の形状は、ユーザ／システムオペレータによる形状指示次第で用いられ、例えば、円形、楕円形又は他の形状が他のアプリケーションに対しては有用であり得る。

ルールエディタを用いて、オペレータ／ユーザは、ステップＰでは、一定のオペレーションを実行するために、エクスプレッションを定義し、作成し又は変更し得る。そのエクスプレッションはそこでの情報に排他的に関連する必要はないが、そのエクスプレッションは、一般には、指示された領域内に含まれる情報に直接的に関係するであろう。例えば、図１Ｂを参照すると、２つの指示された領域Ｒ１及びＲ２は、所定のドキュメント２８に定義され得る。第１の領域Ｒ１は、ドキュメント２８の最新のページ数に関係しており、第２の領域Ｒ２は、ドキュメント２８に全ページ数に関係している。領域は、（ａ）定義フィールドオペレーション／コマンドボタンを定義フィールドプラグインのメインツールバーに選定し、（ｂ）数字の“１”と“４”の１つに隣接するカーソルを用いて（そのイメージの平面で）２次元空間の起点を選定し、（ｃ）それぞれの数の上のカーソルをドラッグし、（ｄ）それぞれの数字に対して包囲する又は僅かに大きい２次元領域すなわち長さ及び高さの大きさを定義するために端点を選定することによって指示され得る。定義フィールドプラグインは、その後、ダイアログボックスにおいてユーザに対して強調された情報を表示し、ユーザは、そこに含まれる情報／データに基づいて、一定の変更又はルールを視覚的に確かめ、及び／又は、一定の変更又はルールを作るために選ぶ。ルールエディタは任意のフィールドについて独立して用いられ得ることを評価すべきである。一度、ユーザがフィールドを定義すると、それはエクスプレッションで用いるためにルールエディタに利用可能である。

ステップＰでは、エクスプレッションは、選択された領域に関連してルールエディタを用いてユーザ／オペレータによって書き込まれる。そのエクスプレッションは、全てのメールピースジョブ実行に対して必要とされるものではなく又は一般に望ましい唯一又は特定のコマンドを提供する。さらに、ルールエディタがユーザ／オペレータからの入力を受け付ける一方で、ルールエンジン２４ＲＥプラグインは、メールピースデータを処理したときのエクスプレッションを実行する。例えば、エクスプレッションは、“フィールドＲ２の値がフィールドＲ１の値に等しいとき、その後、次のページで新たなドキュメントを始める”又は“フィールドＲ２の値がフィールドＲ１の値に等しいとき、メールピースドキュメントをブレークし、全ページ（すなわち、最後にこの状況が満たされたときから）をエンベロープに挿入する”ことを読み取り得る。したがって、“ページ４／４（Page 4 of 4）”が処理されるときだけ、新たなドキュメント又はメールピースが作成され、及び／又は、これらのページはエンベロープに挿入されるであろう。

ステップＱでは、メールピース作成プリントマネージャ２２は、ジョブが所望のコマンドに従って実行することを確実にするために、エクスプレッションの効力をテスト又はシミュレートする。一般には、ユーザ／オペレータは、ルール又はエクスプレッションをテストする適当なサンプルサイズを提供するのに適したメールピースページ又はドキュメントの質を選定するであろう。一度、テストが成功すると、このコマンド／エクスプレッションはルールエンジン２４ＲＥプラグインによって処理され、（図２のステップＥに戻るときに）アセンブリ／スキャンコードジェネレータ２４ＡＣプラグインＰＩによってＯＭＲ又はバーコードマークへ変換される。

図５から７は、ルールエンジンと関連して用いられる様々なユーザインターフェースダイアログボックスを示している。特に、図５は、事前に定義されたフィールド６２、オペレーション６４及びファンクション６４がルールエクスプレッション６８を展開するためにユーザに対して表示される典型的なルールエディタインターフェース６０を示している。例えば、もし、ユーザが各々の新たに発見された顧客番号を有する“次の”ページを生じさせることを望むならば、その後、ユーザは、スクロールダウンし、ダイアログボックス６０のフィールドセクション６２において、“顧客番号（ＣＵＳＴＯＭＥＲ ＮＵＭＢＥＲ）”を選択する。エクスプレッションを展開し続けるために、ユーザは、その後、オペレーションセクション６６におけるオペレーション“不等号（ｎｏｔ ｅｑｕａｌ ｔｏ）”を指示する記号“＜＞”を選択する。“次の”ページファンクションを選択するために、ユーザは、“次（ＮＥＸＴ）”を選択する。最終的に、ユーザは、フィールドセクション６２に逆に移動し、“顧客番号（ＣＵＳＴＯＭＥＲ ＮＵＭＢＥＲ）”を選択する。選択肢の全ては、ダイアログボックス６０のルールエクスプレッションセクション６８に順次現れる。新たなフィールドすなわち先に存在しないフィールドを定義するためには、ユーザは、図６に示される定義フィールドユーザインターフェースダイアログボックス７０を選択する。その中で、メールピース７２のＰＦＤイメージがユーザに対して表示される。もし“顧客番号（ＣＵＳＴＯＭＥＲ ＮＵＭＢＥＲ）”が先に存在するフィールドでなかったならば、ユーザは、既に述べたように、顧客番号と関連する領域の周りに方形ボックス７４を描いて、“フィールド作成（ｃｒｅａｔｅ ｆｉｅｌｄ）”入力ボタン７６を選択してもよい。ルールエンジン２４ＲＥは、この情報を処理し、描かれたオブジェクトと関連する画素を取得する。この例では、選択された画素は、“顧客番号（ＣＵＳＴＯＭＥＲ ＮＵＭＢＥＲ）”と協働する。図７では、“追加／マップフィールドフォーム（Ａｄｄ／Ｍａｐ Ｆｉｌｅｄ Ｆｏｒｍ）”と称する関連ＵＩが、ユーザが選択された領域／フィールドの様々な属性８２、８６及び８８を入力するために（“フィールド作成（ｃｒｅａｔｅ ｆｉｅｌｄ）”ボタン７６のユーザ選択肢に続いて）表示される。名称は“名称（Ｎａｍｅ）”フィールド８２に入力され、定義フィールドプラグイン２４ＤＦは、描かれたフィールドのＸＹ座標及び高さと長さ、すなわち、顧客名を方位する方形ボックス７４を算出する。これらの計算は、プラグインフィールド８４ａ及び８４ｂによって自動的に入力される。フィールドタイプ及び／又は強調カラーなどの他の情報は、ドロップダウンボックス８６及び８８でそれぞれ選択され得る。

（定義フィールドＵＩ７９で）フィールドを空間的に選択し、その属性を（追加／マップフィールドフォーム（Ａｄｄ／Ｍａｐ Ｆｉｌｅｄ Ｆｏｒｍ）９０に）入力したとき、指示される“名称（Ｎａｍｅ）”を有するフィールドは、ルールエディタの“フィールド（Ｆｉｅｌｄ）”セクション６２に現れるであろう。この新たに定義されたフィールドは、ルールエディタダイアログボックスにおいて識別される様々なオペレータ及びファンクションと関連して用いられ得る。

システムアーキテクチャ２０は、ユーザＰＣ１４及びメールピースインサーター１０の間に電子的に入るサーバ１２を示す一方で、システム２０は中央システムサーバ又はプロセッサ１２なしで同じ機能性を有して動作し得ることが評価されるであろう。本実施形態では、ユーザＰＣ１４はネットワークラインＮＬを通ってメールピースインサーター１０に直接接続され、スタンドアロン制御システムエンジン５０ＳＥ、メール実行データベース５２及び様々な制御システムアプリケーション５６を含むようになっている。サーバ又はシステムプロセッサ１２は、それゆえ、制御システムエンジン５０ＳＥなどの中央に位置するプログラムコードに対して便利なホームとして見られ得る。制御システムエンジン５０ＳＥは、ロードされる必要がないし、幾つかの個々のユーザＰＣで重複したスペースを処理する必要もないが、個々にかつ独自に印刷ジョブ及びメール実行データファイルを発生させる多数のユーザ間で共有され得る。

要するに、本発明の方法は、ドキュメントをフォーマットし、それについてのプリント制御言語（ＰＣＬ）プリントストリーム（又は任意のデータストリーム又は従来のアプリケーションソフトウェアで生成された出力ファイル）をインターセプトし、メールピースインサーターによって生成されるメールピースの作成、変更及び印刷を容易にする。プリントストリーム変更（すなわち、各々が付属のオブジェクトディクショナリを有するデータセットの形態でのオブジェクト指向データに対して）は、データの増分処理／印刷を可能にする。すなわち、プリンタは、プラグインマネージャが他の論理ドキュメントを処理するときに１つの論理ドキュメントに関するドキュメント生成を初期化し得る。したがって、論理ドキュメントは、外部ファイルのデータを保存する必要なしに“オンザフライ（ｏｎ ｔｈｅ ｆｌｙ）”印刷される。更に、他がまだ“処理中（ｉｎ−ｐｒｏｃｅｓｓ）”である間に完成されたドキュメントを印刷することによって、完成されたドキュメントは、メールピースアセンブリ／製作が迅速に初期化され得るように、メールインサーターに導入／入力され得る。それゆえ、メールピースコンテンツ素材のスループットは本発明の方法及びシステムアーキテクチャによって実質的に高められることが評価されるであろう。

更に、プリントドライバプログラムコードは、プリントストリームをインターセプトし、アプリケーションファイルをオブジェクト指向ドキュメント（ＯＯＤ）又はポータブルドキュメントフォーマット（ＰＤＦ）ファイルに変換するようになっている。柔軟なドキュメント分配（distribution）を提供することに加えて、変換されたＯＯＤ／ＰＤＦファイルは、メールピースコンテンツ素材の様々なフィールド及領域に属性を割り当てる権限を提供する。オブジェクト指向データファイル又はＰＤＦへの変換は、（ｉ）ページごと、（ｉｉ）メールピースごと、（ｉｉｉ）ドキュメントごと、（ｉｖ）全メールピースデータファイルに基づいて、電子的アプリケーションファイルの操作を可能にし実行する唯一の機会を提供する。

ＯＯＤ／ＰＤＦファイルは、ユーザ／システムオペレータが、フィールドを定義し、識別された領域から読み出し、選定領域から情報を抽出し、一領域に含まれる情報に関して数学的及び他のオペレーション（操作）を実行し、新たな情報を挿入し、メールピースコンテンツのページを整理し直し、ドキュメントページネーションを変更し、メールピースコンテンツ素材からページを追加及び／又は削除するなどをできるようにする。それゆえ、ＯＯＤ／ＰＤＦファイルへの変換は、メールピース製作と関連して情報を変更し、操作し、挿入し又は抽出するのにより大きな柔軟性及び能力を提供する。従来技術では、そのような能力は、一般には、全ドキュメントの容易な分配（distribution）に関するものであった。更に、インサーターシステムを操作する能力は、（メールピースインサーターを動作させるのに用いられるプログラミング言語に熟練した）ＯＥＭの組み合わされた成果及び（メールピースの特有の要求に関する知識を有する）顧客を介してのみ利用可能であった。それゆえ、本発明によって、ユーザ／オペレータは、ＯＥＭサポートの必要性又はＯＥＭのプログラム技術なしにメールインサーターのオペレーションをカスタマイズすることができる。

また、ルールエンジンはメールピースの生成に特有でないが、決定が任意のオブジェクト指向データファイル／ドキュメントのコンテンツに基づいてなされることを許容するメカニズムであることを評価すべきである。

更に、オブジェクト指向コンテンツのプログラム操作を許容する。ルールエンジンは、ユーザが個々に区別されるファンクションを作成することを許可することによって拡張可能である。これらのファンクションは、ドキュメントコンテンツと同じアクセス及びその内蔵ファンクションと同じ一般の処理環境を有する。それゆえ、これにより、ユーザは、自分の特定のビジネス論理をルール／エクスプレッションに取り込むことができる。

本発明は、上述及び図面に示された特定の実施形態に限定されるものとして考案されたものではないことを理解されるべきである。例示は、本発明を実行するために現在考えられているベストモードを示したものに過ぎず、上記の変更が可能であることは当業者には明らかである。本発明は、特許請求の範囲内にあると思われる、全てのそのようなバリエーション、変更及びその均等物をカバーすることを意図している。

メールピースインサーター、サーバ／システムプロセッサ及びユーザＰＣを含む本発明の教示に従うメールピース挿入システムのシステムアーキテクチャであって、メールピース挿入システムが完全なメールピースを作成し、操作し、プリントするように適応されているメールピース挿入システムのシステムアーキテクチャを概略的に示している。 アプリケーションのプリントストリームデータをオブジェクト指向データに変換し、続いて様々なシステムプラグイン／モジュールによって処理するための仮想ドライバを含むユーザＰＣの様々な要素を示している。 メールピースインサーターによってメールピースのアセンブリと関連してインストラクションを提供するためにドキュメントに組み込まれるアセンブリ又はスキャンコードを有するメールピースコンテンツ素材のスタックを示している。 メールピースインサーターにおける本発明の教示を実施するための方法ステップのブロック図である。 メールピースインサーターにおける破損又は欠陥データを訂正するために用いられるリプリント機能のための方法ステップのブロック図である。 メールピースドキュメントの製作及びメールピースインサーターにおける利用と関連してフィールドを定義し、ルールを展開し、エクスプレッションを書き込むグラフィックツールのための方法ステップのブロック図である。 メールピースドキュメントを処理するルールエンジンプラグインによる利用に対してフィールド、オペレーション（操作）及びファンクションを選択するためのルールエディタのユーザインターフェース（ＵＩ）を示している。 ルールエンジンプラグインによって用いられるフィールドを定義するためにＵＩモニターにメールピースドキュメントを表示したＰＤＦを示している。 定義されたフィールドと関連して選択された属性をオペレータが入力するのためのダイアログボックスを示している。

Claims (26)

1. メールピースインサーターに利用するためのメールピースコンテンツ素材を生成する方法であって、
   前記メールピースコンテンツの電子的アプリケーションファイルであって、ソフトウェアアプリケーションによって生成される電子的アプリケーションファイルからプリントストリームデータを受信するステップと、
   前記プリントストリームデータをオブジェクト指向データに変換するステップと、
   前記オブジェクト指向データを複数のデータセットにセグメント化するステップと、
   メールピースコンテンツ素材を生成するために前記複数のデータセットを処理するステップとを備えた方法。
2. 前記オブジェクト指向データは、ポータブルドキュメントフォーマット（ＰＤＦ）オブジェクトによって定義される請求項１に記載の方法。
3. 前記オブジェクト指向データをセグメント化するステップは、オブジェクトディクショナリを各データセットに付加するステップをさらに含んでいる請求項１に記載の方法。
4. 前記データセットは、それぞれ複数のデータパケットを備えている請求項３に記載の方法。
5. 前記メールピースコンテンツ素材のアセンブリに必要とされるインストラクションを指示するアセンブリコードデータを定義し、前記アセンブリコードデータを各論理ドキュメントと結合するステップをさらに備えている請求項１に記載の方法。
6. 前記複数のセットを処理するステップは、前記メールピースインサーターにおいて利用するためのアセンブリコードデータを含むメールピースコンテンツ素材を印刷するステップを含んでいる請求項５に記載の方法。
7. 前記複数のデータセットを処理するステップは、前記複数のデータセットを追跡して操作するための少なくとも１つのモジュラプラグインによって実行される請求項１に記載の方法。
8. 前記複数のデータセットは、メールピースページを生成するために結合される請求項１に記載の方法。
9. 電子的メールピースは、メールピースドキュメントを生成するために結合される請求項８に記載の方法。
10. 電子的メールピースドキュメントは、メールピースデータファイルを生成するために結合される請求項９に記載の方法。
11. メールピースインサーターに利用するためのメールピースコンテンツ素材を生成するシステムであって、
    電子的メールピースコンテンツファイルを生成し、前記ファイルを印刷するためのコマンドに応答してプリントストリームデータを発生させるソフトウェアアプリケーションと、
    前記プリントストリームデータを受信し、前記プリントストリームデータをオブジェクト指向データに変換し、前記オブジェクト指向データを複数のデータセットにセグメント化する仮想ドライバと、
    前記複数のデータセットを複数の論理ドキュメントに処理するためのプラグインマネージャと、
    前記複数の論理ドキュメントからメールピースコンテンツを生成するためのプリンタとを備え、
    前記プリンタは、前記プラグインマネージャが他の論理ドキュメントを処理するときに、１つの論理ドキュメント上の前記メールピースコンテンツのドキュメント生成を初期化し、それによって、前記メールピースインサーターにおいて利用するためのメールピースコンテンツ素材のスループットを上げるシステム。
12. 前記オブジェクト指向データは、ポータブルポータブルドキュメントフォーマット（ＰＤＦ）オブジェクトによって定義される請求項１１に記載のシステム。
13. 前記仮想ドライバは、オブジェクトディクショナリを各データセットに付加する請求項１１に記載のシステム。
14. 前記データセットは、それぞれ複数のデータパケットを備えている請求項１３に記載のシステム。
15. 前記プラグインマネージャは、前記データセットを複数のページとして追跡し、前記システムは、さらに、処理中に個々のページで特殊のファンクションを実行するためのプラグインを備えている請求項１１に記載のシステム。
16. 前記プラグインマネージャは、前記データセットを複数のドキュメントとして追跡し、前記システムは、さらに、処理中に個々のページで特殊のファンクションを実行するためのプラグインを備えている請求項１１に記載のシステム。
17. 前記プラグインマネージャは、前記データセットを複数のメールピースとして追跡し、前記システムは、さらに、処理中に個々のページで特殊のファンクションを実行するためのプラグインを備えている請求項１１に記載のシステム。
18. アプリケーションからコンテンツ素材を生成する方法であって、
    前記電子的アプリケーションからプリントストリームデータを受信するステップと、
    前記プリントストリームデータをオブジェクト指向データに変換するステップと、
    複数のデータセットであって、各データセットがオブジェクトディクショナリを有している複数のデータセットに前記オブジェクト指向データファイルを構成するステップと、
    複数の論理ドキュメントを定義するために前記複数のデータセットを処理するステップとを備えた方法。
19. プリントストリームデータを作成するステップは、前記プリントストリームデータを表示するためのグラフィックスデバイスインターフェースによって実行される請求項１８に記載の方法。
20. メールピースアセンブリに必要なインストラクションを提供するためにアセンブリコードデータを生成し、前記アセンブリコードデータを各論理ドキュメントと結合するステップをさらに備えている請求項１８に記載の方法。
21. 前記複数のセットを処理するステップは、メールピースインサーターにおいて利用するための論理ドキュメントを印刷するステップを含んでいる請求項１８に記載の方法。
22. 前記複数のデータセットを処理するステップは、前記複数のデータセットを追跡して操作するための少なくとも１つのプラグインによって実行される請求項１８に記載の方法。
23. データセットは、複数のデータパケットを備えている請求項１８に記載の方法。
24. 前記複数のデータセットは、メールピースページを生成するために結合される請求項１８に記載の方法。
25. 前記ペールピースページは、メールピースドキュメントを生成するために結合される請求項２４に記載の方法。
26. 前記電子的メールピースドキュメントは、メールピースデータファイルを生成するために結合される請求項２５に記載の方法。

Images