(57)【要約】複数の配信メディアを介して受信者に対する情報の大量通信を行うための方法（１００）、システムおよび前述の大量通信を実行させるプログラムを提供する。前述のメディアにはファクシミリ、電子メール、物理メール、ＳＭＳメッセージおよびアーカイビング（が含まれている。（さらに、将来における新しいメディアにも適用される。）単一のインターフェースは、各受信者に特有である１つ以上のテンプレート・ドキュメント（１１０）およびデータ（１０６）を含む分配のための情報（１０６、１０８、１１０）を受信してきた。受信した情報（１０６，１０８，１１０）に基づいた少なくとも１つのドキュメントは、受信者の配信優先順位（１２２，１７６）に基づいた各受信者に特有の配信メディア（１４４，１５０，１５６，１６２，１６８）を使用して送信される。ドキュメントの送信エスカレート（１７２，１７８）は指定された配信メディアによる送信が失敗した受信者のための異なった配信メディアの使用を引き起こす。エスカレートステップ（１７２，１７８）は各受信者へのドキュメントの配信に関するキャリアからのステータス情報（１７６）に依存する。
2005535013.tif 000002
【特許請求の範囲】
【請求項１】
ファクシミリ、電子メール、物理メール、およびＳＭＳメッセージングを含む複数の配信メディアを介して受信者に対する情報の大量通信を行うための方法であって、
単一のインターフェースを介して、受信者に関する情報を含む配信についての情報を受け取るステップ、および、
前記受け取った情報を基礎として少なくとも１つのドキュメントを、前記配信メディアの、前記受信者の配信プレファレンスを基礎として前記受信者のそれぞれについて指定された１つを使用して送信するステップ、
を有する方法。
【請求項２】
さらに、前記指定された配信メディアによる送信が失敗した１ないしは複数の前記受信者のそれぞれについて、前記配信メディアの異なる１つを使用して前記少なくとも１つの送信をエスカレートするステップを有する、請求項１に記載の方法。
【請求項３】
前記受け取った情報は、１ないしは複数のテンプレート・ドキュメントおよび各受信者に固有のデータを含む、請求項１に記載の方法。
【請求項４】
さらに、前記１ないしは複数のテンプレート・ドキュメントと前記各受信者に固有のデータを、前記受信者のそれぞれのための前記少なくとも１つのドキュメントを提供するべく併合するステップを有する、請求項３に記載の方法。
【請求項５】
さらに、それぞれ配信メディアについてドキュメント・テンプレート・タイプを決定するステップ、および前記ドキュメント・テンプレート・タイプごとに併合プロセスを選択するステップを有する、請求項４に記載の方法。
【請求項６】
前記各受信者に固有のデータは、前記それぞれの併合プロセスへ提供される、請求項５に記載の方法。
【請求項７】
さらに、
前記少なくとも１つのドキュメントを、前記受信者のそれぞれについて前記指定された１つもしくは前記異なる１つに適したフォーマットへ変換するステップ、および、
前記フォーマット済みドキュメントを、前記配信メディアの前記指定された１つもしくは前記異なる１つを使用する送信のためのキャリアへ渡すステップ、
を有する、請求項２に記載の方法。
【請求項８】
さらに、前記キャリアからの前記送信に関するレポートを、前記ドキュメントの各受信者に対する配信に関するステータス情報を提供するべく処理するステップを有する、請求項７に記載の方法。
【請求項９】
前記エスカレートするステップは、前記ステータス情報に依存する、請求項８に記載の方法。
【請求項１０】
前記配信メディアはアーカイビングを含む、請求項１に記載の方法。
【請求項１１】
前記配信メディアは、１ないしは複数の新しいメディア・タイプを含む、請求項１に記載の方法。
【請求項１２】
ファクシミリ、電子メール、物理メール、およびＳＭＳメッセージングを含む複数の配信メディアを介して受信者に対する情報の大量通信を行うためのシステムであって、
受信者に関する情報を含む配信についての情報を受け取るための単一のインターフェース、および、
前記受け取った情報を基礎として少なくとも１つのドキュメントを、前記配信メディアの、前記受信者の配信プレファレンスを基礎として前記受信者のそれぞれについて指定された１つを使用して送信するための手段、
を有するシステム。
【請求項１３】
さらに、前記指定された配信メディアによる送信が失敗した１ないしは複数の前記受信者のそれぞれについて、前記配信メディアの異なる１つを使用して前記少なくとも１つの送信をエスカレートするための手段を有する、請求項１２に記載のシステム。
【請求項１４】
前記受け取った情報は、１ないしは複数のテンプレート・ドキュメントおよび各受信者に固有のデータを含む、請求項１２に記載のシステム。
【請求項１５】
さらに、前記１ないしは複数のテンプレート・ドキュメントと前記各受信者に固有のデータを、前記受信者のそれぞれのための前記少なくとも１つのドキュメントを提供するべく併合するための手段を有する、請求項１４に記載のシステム。
【請求項１６】
さらに、それぞれ配信メディアについてドキュメント・テンプレート・タイプを決定するための手段、および前記ドキュメント・テンプレート・タイプごとに併合プロセスを選択するための手段を有する、請求項１５に記載のシステム。
【請求項１７】
前記各受信者に固有のデータは、それぞれの併合プロセスにかけられる、請求項１６に記載のシステム。
【請求項１８】
さらに、
前記少なくとも１つのドキュメントを、前記受信者のそれぞれについて前記指定された１つもしくは前記異なる１つに適したフォーマットへ変換するための手段、および、
前記フォーマット済みドキュメントを、前記配信メディアの前記指定された１つもしくは前記異なる１つを使用する送信のためのキャリアへ渡すための手段、
を有する、請求項１３に記載のシステム。
【請求項１９】
さらに、前記キャリアからの前記送信に関するレポートを、前記ドキュメントの各受信者に対する配信に関するステータス情報を提供するべく処理するための手段を有する、請求項１８に記載のシステム。
【請求項２０】
前記エスカレートするための手段は、前記ステータス情報に依存する、請求項１９に記載のシステム。
【請求項２１】
前記配信メディアはアーカイビングを含む、請求項１２に記載のシステム。
【請求項２２】
前記配信メディアは、１ないしは複数の新しいメディア・タイプを含む、請求項１２に記載のシステム。
【請求項２３】
ファクシミリ、電子メール、物理メール、およびＳＭＳメッセージングを含む複数の配信メディアを介して受信者に対する情報の大量通信のためのコンピュータ・プログラムが記録されたコンピュータ可読メディアを含むコンピュータ・プログラム・プロダクトであって、
単一のインターフェースを介して、受信者に関する情報を含む配信についての情報を受け取るためのコンピュータ・プログラム・コード手段、および、
前記受け取った情報を基礎として少なくとも１つのドキュメントを、前記配信メディアの、前記受信者の配信プレファレンスを基礎として前記受信者のそれぞれについて指定された１つを使用して送信するためのコンピュータ・プログラム・コード手段、
を有するコンピュータ・プログラム・プロダクト。
【請求項２４】
さらに、前記指定された配信メディアによる送信が失敗した１ないしは複数の前記受信者のそれぞれについて、前記配信メディアの異なる１つを使用して前記少なくとも１つの送信をエスカレートするためのコンピュータ・プログラム・コード手段を有する、請求項２３に記載のコンピュータ・プログラム・プロダクト。
【請求項２５】
前記受け取った情報は、１ないしは複数のテンプレート・ドキュメントおよび各受信者に固有のデータを含む、請求項２３に記載のコンピュータ・プログラム・プロダクト。
【請求項２６】
さらに、前記１ないしは複数のテンプレート・ドキュメントと前記各受信者に固有のデータを、前記受信者のそれぞれのための前記少なくとも１つのドキュメントを提供するべく併合するためのコンピュータ・プログラム・コード手段を有する、請求項２５に記載のコンピュータ・プログラム・プロダクト。
【請求項２７】
さらに、それぞれ配信メディアについてドキュメント・テンプレート・タイプを決定するためのコンピュータ・プログラム・コード手段、および前記ドキュメント・テンプレート・タイプごとに併合プロセスを選択するためのコンピュータ・プログラム・コード手段を有する、請求項２６に記載のコンピュータ・プログラム・プロダクト。
【請求項２８】
前記各受信者に固有のデータは、前記それぞれの併合プロセスにかけられる、請求項２７に記載のコンピュータ・プログラム・プロダクト。
【請求項２９】
さらに、
前記少なくとも１つのドキュメントを、前記受信者のそれぞれについて前記指定された１つもしくは前記異なる１つに適したフォーマットへ変換するためのコンピュータ・プログラム・コード手段、および、
前記フォーマット済みドキュメントを、前記配信メディアの前記指定された１つもしくは前記異なる１つを使用する送信のためのキャリアへ渡すためのコンピュータ・プログラム・コード手段、
を有する、請求項２４に記載のコンピュータ・プログラム・プロダクト。
【請求項３０】
さらに、前記キャリアからの前記送信に関するレポートを、前記ドキュメントの各受信者に対する配信に関するステータス情報を提供するべく処理するためのコンピュータ・プログラム・コード手段を有する、請求項２９に記載のコンピュータ・プログラム・プロダクト。
【請求項３１】
前記エスカレートするためのコンピュータ・プログラム・コード手段は、前記ステータス情報に依存する、請求項３０に記載のコンピュータ・プログラム・プロダクト。
【請求項３２】
前記配信メディアはアーカイビングを含む、請求項２３に記載のコンピュータ・プログラム・プロダクト。
【請求項３３】
前記配信メディアは、１ないしは複数の新しいメディア・タイプを含む、請求項２３に記載のコンピュータ・プログラム・プロダクト。
【請求項３４】
ファクシミリ、電子メール、物理メール、およびＳＭＳメッセージングを含む複数の配信メディアを介して受信者に対する情報の大量通信を行うための方法であって、実質的に、添付図面の図１〜１０の任意の１つを参照してここに開示されているとおりの方法。
【請求項３５】
ファクシミリ、電子メール、物理メール、およびＳＭＳメッセージングを含む複数の配信メディアを介して受信者に対する情報の大量通信を行うためのシステムであって、実質的に、添付図面の図１〜１０の任意の１つを参照してここに開示されているとおりのシステム。
【請求項３６】
ファクシミリ、電子メール、物理メール、およびＳＭＳメッセージングを含む複数の配信メディアを介して受信者に対する情報の大量通信を行うためのコンピュータ・プログラム・プロダクトであって、実質的に、添付図面の図１〜１０の任意の１つを参照してここに開示されているとおりのコンピュータ・プログラム・プロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本件出願は、これより先の出願である、トレード・ウインド・コミュニケーションズ・リミテッド（Ｔｒａｄｅ  Ｗｉｎｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｌｔｄ）の名において２００２年７月２９日に出願された、本件と原文において同じ発明の名称（ア・バルク・コミュニケーションズ・プロセス・ユージング・マルチプル・デリバリ・メディア（Ａ  Ｂｕｌｋ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｐｒｏｃｅｓｓ  Ｕｓｉｎｇ  Ｍｕｌｔｉｐｌｅ  Ｄｅｌｉｖｅｒｙ  Ｍｅｄｉａ））を有するオーストラリア仮特許出願第２００２９５０４３５号の利益を主張するものであり、その内容は、参照によってこれに援用されている。
【０００２】
本発明は、概して大量通信に関し、特に、複数の配信メディアを使用する大量通信のための方法およびシステムに関する。
【背景技術】
【０００３】
ビジネス、会社、および組織（以下、単純に発信者と言う）は、各種の理由から、そのクライアント、サプライヤ、およびそのほかの相手（以下、単純に受信者と言う）との通信に大量通信を使用する。通常、その種の大量通信は、次に示すメディアの１つを使用して行われている：すなわち、物理メール、電子メール、ファクシミリ、および受信者の携帯電話へ送信されるショート・メッセージ・サービス（ＳＭＳ）である。
【０００４】
通信の発信者は、それらの受信者との通信に各種タイプの大量通信を有しており、それは特定目的のマーケティング通信から、繰り返し発生するインボイス、明細書、および督促状といった重要な情報の配信まで及ぶ。概して言えば、これらの大量通信は、次に示す共通の要素を有している：
・  受信者情報のリストが個別に提供され、しばしばコーポレート・データベースもしくはアカウンティング・システムからそれらを抽出することが必要になる；
・  ドキュメント・テンプレートのフォームが使用される；
・  受信者リストからのデータがテンプレート・ドキュメントに差し込まれ、あるいはオーバーレイされる；
・  最終的な『差し込み済み』ドキュメントがカスタマへ配信される。
【０００５】
受信者との通信は、発信者の各種部署もしくはエンティティから発信すること、あるいは使用される通信メディアのタイプに応じて各種の方法で行うことができる。これらの各種通信の実行において、発信者は、異なるインターフェースならびにテクノロジを、その発信者が物理メール、電子メール、ファクシミリ、またはＳＭＳのいずれを経由して情報を送信するかに応じて使用する。発信者が、関連する通信のために必要な一部もしくは全部のテクノロジをインハウスでホストすることもあるが、それ以外では発信者が、それらの通信をアウトソーシングすることもある。
【０００６】
封筒用の住所ステッカーの作成、および文字の差し込み処理ならびにプリントについては、メール・マージ・ソフトウエア・アプリケーションが存在する。発信者が、プロプラエタリ・システムおよび、物理メールの差し込み処理を管理するためにセットアップされたインハウスのプリント部門を有していることもある。メーリング・ハウスは、発信者へ、それらの物理メールをアウトソーシングする能力を提供する。概して、カスタム化されたスクリプトが記述され、発信者のデータベースから抽出されたデータをマップし、当該抽出されたデータをあらかじめプリントされたペーパー・ストック上へオーバーレイする。
【０００７】
ファクシミリ（ファックス）マシンは、リストのストアおよび大量メッセージ配信を行う能力を有している。通信のサイズによっては、マイクロソフト・アウトルック（Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ）等のツールを使用して大量メーリングを行うことが可能である。このアプリケーションを用いてユーザは、データ・リポジトリのデータ・フィールドをマイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）ドキュメントに差し込み、かつそれ続いて差し込み済みドキュメントを、そのメール差し込みツールを介して受信者リストに対して電子メールすることができる。マイクロソフト・アウトルック（Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ）およびマイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）以外のソフトウエア・アプリケーションにも類似の機能がある。この分野におけるソフトウエア・ソリューションについては、ファクシミリ・カードまたはファクシミリ・プリント・ドライバ等が、そのソフトウエアがインストールされたネットワーク上もしくはワークステーション上にインストールされていなければならない。ビジネスもしくは会社は、大量ファクシミリならびに電子メール・サービスも提供する。そのいくつかでは、異なる受信者用にパーソナル化されたドキュメントが発信者によって供給されることが必要になり；別のいくつかでは、発信者のためにデータの差し込みを行う。企業資源計画（ＥＲＰ）およびアカウンティング・ソフトウエアもまた、アプリケーションまたはソフトウエア・パッケージ内から電子メールもしくはファクシミリを行う能力を提供する。しかしながら、これは通常、大量のパーソナル化ならびに配信に備えるというよりは、個別の通信に適合されている（つまり、ビジネス・プロセス内の特定のポイントにおいてパッケージ内からの単一の電子メールもしくはファクシミリを送信する）。
【０００８】
発信者は、その発信者のシステムを適合させて、キャリアを介してＳＭＳメッセージを発行することができる。一般にこれは、電子メールを指定アドレスへ、所定の方法でフォーマットして送信し、その後、ＳＭＳメッセージとして携帯電話へ転送することを可能にする「ＳＭＳ向け電子メール」タイプのサービスを使用して行われる。発信者は、ＳＭＳメッセージの大量アウトソーシングを可能にすることができるが、概して、別の配信メカニズムと同一のデータベースからのパーソナル化されたデータの差し込みを行う能力を提供しないか、第三者製品によるその能力の提供をサポートしていない。
【０００９】
限定的な結合されたサービスは存在し、一般に、電子メールをファクシミリまたはＳＭＳへ転送することができる。とりわけ、これらのサービスは、フォーマッティングおよび差し込み機能を提供しない。この種のサービスは、同一の受信者リストならびにデータベースを使用しつつ、各種の配信メカニズム用に特定のフォーマッティング規則が指定されることを考慮してなく、また配信オプションの１つとして物理メールをサポートしていない。
【００１０】
メッセージングダイレクト（ＭｅｓｓａｇｉｎｇＤｉｒｅｃｔ）（ＡＣＩの製品）は、ｅ‐クーリエ（ｅ‐Ｃｏｕｒｉｅｒ）を提供している。ｅ‐クーリエ（ｅ‐Ｃｏｕｒｉｅｒ）１は、直接電子請求書発行ならびに支払いのソリューションである。これらのツールは、伝統的な直接ビジネス対ビジネスのペーパー取引と、電子配信の高速性、効率、および柔軟性の結合を追求している。またこれらのいずれも、直接電子ビジネスを介してストリームライン化されたビジネス・プロセスを促進することを試みている；すなわちディジタル署名され、法的に拘束され、かつ安全に配信されるエンド‐ツー‐エンドの請求書、明細書、インボイス、確認、ポリシー等の電子取引である。全体的なビジネス・プロセスは、直接的にビジネスとそれらのカスタマ、パートナー、およびサプライヤの間において、電子取引が電子チャンネルを通って流れることを可能にするオンライン化を目指している。メッセージングダイレクト（ＭｅｓｓａｇｉｎｇＤｉｒｅｃｔ）システムは、電子メール、ファクシミリ、または物理メールの配信のための統一されたインターフェースをサポートしていない。メッセージングダイレクト（ＭｅｓｓａｇｉｎｇＤｉｒｅｃｔ）製品では、すべての受信者がそのサービスに登録することが必要とされる。
【００１１】
メッセージリーチ（ＭｅｓｓａｇｅＲｅａｃｈ）およびファックス・メールマージ（Ｆａｘ  ＭａｉｌＭＥＲＧＥ）（エクスペダイト（Ｘｐｅｄｉｔｅ）の製品）は、異なるメディアのための異なるオファーを行っているが、単一の受信者リストのパーソナル化および配信を同時に行わない。
【００１２】
パルス・エンタープライズ（Ｐｕｌｓｅ  Ｅｎｔｅｒｐｒｉｓｅ）（エスカー・ソフトウエア（Ｅｓｋｅｒ  Ｓｏｆｔｗａｒｅ）の製品）は、もう１つの類似のアプリケーションであるが、エスカレーションを組み込んでなく、ＡＳＰモデルとして（またはウェブ・サーバとして）提供されてなく、物理メールの配信のサポートもしていない。またパルス・エンタープライズ（Ｐｕｌｓｅ  Ｅｎｔｅｒｐｒｉｓｅ）では、ファクシミリ・カード等がソフトウエアとともにインストールされていることが必要となる。パルス・エンタープライズ（Ｐｕｌｓｅ  Ｅｎｔｅｒｐｒｉｓｅ）を使用する会社は、それらの環境の中にソフトウエアならびにハードウエアをともにインストールし、パルス・エンタープライズ（Ｐｕｌｓｅ  Ｅｎｔｅｒｐｒｉｓｅ）はもとより、ファクシミリ、ＳＭＳ、電子メールのインターフェース等をすべて管理しなければならない。パルス・エンタープライズ（Ｐｕｌｓｅ  Ｅｎｔｅｒｐｒｉｓｅ）は、ジェネラル・ドキュメント・レコグニション（Ｇｅｎｅｒａｌ  Ｄｏｃｕｍｅｎｔ  ＲｅｃｏｇｎｉｔｉｏｎＴＭ）（ＧＤＲ）コンポーネントを含んでいる。このジェネラル・ドキュメント・レコグニション（Ｇｅｎｅｒａｌ  Ｄｏｃｕｍｅｎｔ  ＲｅｃｏｇｎｉｔｉｏｎＴＭ）は、テキストならびにプリント‐ストリーム・データを複数の電子フォーマットへ変換すること、および任意の受信デバイスへそれらのドキュメントを配信することの自動化を追求している。
【発明の開示】
【００１３】
このように、発信者が、単一の共通インターフェースを用いて１つの大量通信サービスを利用すること、および同一の受信者データのセットを再使用することを可能にし、それによって受信者への大量通信が、従来の郵便つまり物理メール、電子メール、ファクシミリ、およびＳＭＳを含むすべての現存する各種メディア（および、将来的に現れる可能性のあるそのほかの任意の新しい配信メディア）を介して運ばれることを可能にする自動化されたサービスへの要求が明らかに存在する。さらに、発信者が、受信者へのメッセージの配信を、最初のメディアが成功しなかった場合の情報の配信方法を含めた情報の受け取りに関する受信者のプレファレンスを基礎として管理することを可能にし、しかも発信者が、特定の配信タイプに特有のテクノロジのインストールならびに管理を発信者に求めることのない自動化されたサービスへの要求が明らかに存在する。さらにまた、単一のインターフェースを介した、受信者のプレファレンスを基礎とする全範囲の配信メディア（ファクシミリ、電子メール、ＳＭＳ、ペーパー、およびアーカイビング）に対するデータのフォーマットならびに配信が可能な自動化されたサービスへの要求が存在する。
【００１４】
本発明の第１の側面によれば、ファクシミリ、電子メール、物理メール、およびＳＭＳメッセージを含めた複数の配信メディアを介して受信者に対する情報の大量通信を行うための方法が提供される。好ましくはこれが、このほかの将来における新しいメディア・タイプへ拡張する能力を含む。受信者に関する情報を含む配信のための情報は、単一のインターフェースを介して受信される。受信された情報は、１ないしは複数のテンプレート・ドキュメントおよびそれぞれの受信者に固有のデータ（埋め込みイメージ・データを含む）を含むことができる。受信された情報に基づく少なくとも１つのドキュメントは、それぞれの受信者の配信プレファレンスに基づいてそれぞれの受信者について指定された１つの配信メディアを使用して送信される。
【００１５】
好ましくはこの方法が、指定された配信メディアによる送信が失敗した１ないしは複数の受信者のそれぞれについて、別の１つの配信メディアを使用して少なくとも１つのドキュメントの送信をエスカレートするステップを含む。この少なくとも１つのドキュメントは、それぞれの受信者に関する前述の指定された１つの配信メディア、または別の１つの配信メディアに適したフォーマットへ変換されるようにしてもよい。フォーマットされたドキュメントは、その後、指定された１つまたは別の１つの配信メディアを使用する送信のためのキャリアへ渡される。キャリアからの送信に関するレポートを処理し、それぞれの受信者に対するドキュメントの配信に関するステータス情報を提供することもできる。また、エスカレートするステップが、このステータス情報に依存するようにしてもよい。
【００１６】
この方法はさらに、１ないしは複数のテンプレート・ドキュメントと、それぞれの受信者に特有のデータ（オプションとして、それぞれの受信者に特有のイメージ・データを含む）を、それぞれの受信者のための少なくとも１つのドキュメントを提供するべく併合するステップを含むことができる。さらにまた、この方法は、それぞれの配信メディアについてドキュメント・テンプレート・タイプを決定するステップ、およびそのドキュメント・テンプレート・タイプのための併合プロセスを選択するステップを含むことができる。それぞれの受信者に固有のデータが、それぞれの併合プロセスへ提供されるようにしてもよい。配信メディアは、将来における任意のときに併合済みテンプレート・ドキュメントの追加のコピーに対する受信者の要求を容易にするために、アーカイビングを含むことができる。
【００１７】
本発明のこのほかの側面は、上記の方法に基づいて、ファクシミリ、電子メール、物理メール、およびＳＭＳメッセージングを含めた（かつ、そのほかの新しいメディア・タイプへ拡張することができる）複数の配信メディアを介し、受信者に対する情報の大量通信を行うためのシステムおよびコンピュータ・プログラム・プロダクトを含む。これらの、およびそのほかの本発明の側面について、次に詳細に説明する。
【００１８】
以下添付図面を参照して、本発明の少数の実施態様について説明する。
【発明を実施するための最良の形態】
【００１９】
受信者の配信プレファレンスに基づく、複数の配信メディアを経由した単一セットの受信者に対する大量通信のための、かつエスカレーションを組み込んだ、方法、システム、およびコンピュータ・プログラム・プロダクトを開示する。好ましくはこの方法、システム、およびコンピュータ・プログラム・プロダクトは、ウェブ・サービスとして配信されるサービスを可能にする。さらに、配信メディアは、物理メール、電子メール、暗号化電子メール、ファクシミリ、ＳＭＳ、およびアーカイビングを含む（かつ、将来におけるほかのメディア・タイプの包含を考慮している）。以下の説明においては、通信ネットワーク、通信プロトコル、およびデータ・フォーマット等、たとえばＭＨＴＭＬおよびポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）等のデータ・フォーマットといった多くの具体的な詳細が示されている。しかしながら、当業者にはこの開示に照らして明らかになるように、本発明の範囲ならびに精神から逸脱することなしに修正および／または置換を行い得る。一方、本発明の不明瞭化を避けるために、当業者に周知の詳細は割愛されることもある。
【００２０】
用語『エスカレーション』、『エスカレート』、『エスカレーティング』、およびそのほかの単語『エスカレート』の形式は、この文書の関係においてリダイレクションを意味する。したがって、『配信メディアの異なる１つを使用して少なくとも１つの書類の送信をエスカレートする』という表現は、別のメディアを使用してその送信のリダイレクションが行われることを意味する。
【００２１】
受信者は、特に、いずれのメディアによって情報が配信されると好ましいかについて指定する。さらに受信者は、好ましいメディアを使用して配信が達成できなかった場合に、情報が配信されるメディアを指定することができる。したがって、配信の失敗を生じた場合においては、異なるメディアへのエスカレーションが、受信者のプレファレンスに従う。好ましくは、このプロセスがオブジェクト指向態様で開発され、複数のサブコンポーネントから作られているコンピュータ・ソフトウエアを使用して具体化される。このソフトウエアに対するユーザ・インターフェースは、好ましくはウェブ・サービスとして配信される。より好ましくはソフトウエア・アプリケーションが、ジャバ（Ｊａｖａ）および拡張マークアップ言語（ＸＭＬ）によって記述される。次に、全般的な概要を説明し、その後、図面を参照して本発明の実施態様をより詳細に説明する。
【００２２】
以下の説明のいくつかの部分は、コンピュータ・メモリ内のデータに関するアルゴリズムならびにオペレーションの記号表現について、明示的もしくは暗示的に与えられている。これらのアルゴリズムの記述ならびに表現は、データ処理技術分野の当業者によって、その研究の実体をほかの当業者へもっとも効果的に伝えるために使用されている手段である。ここではアルゴリズムを、概して、望ましい結果へ導くステップの自己矛盾のないシーケンスとして考える。これらのステップは、物理量の物理的操作を必要とするステップである。一般に、必須ではないが、これらの量は、ストア、伝達、結合、比較、およびそのほかの操作が可能な電気的または磁気的信号の形式をとる。しばしば主として共通使用の理由から、これらの信号が、便宜上、ビット、値、エレメント、記号、文字、項、数として、あるいはこれらの類似概念を用いて参照される。
【００２３】
しかしながら、上記の、および類似の用語は、適切な物理量に関連付けされるべきであり、それらの量に対して便宜上のラベルが適用されるに過ぎない。特に示さない限り、また以下から明らかなとおり、当業者であれば認識されることになろうが、『コンピューティング』、『併合』、『計算』、『変換』、『決定』、『比較』、『生成』、『選択』、『出力』等、ならびにこれらに類似の用語をここで用いている部分は、コンピュータ・システムもしくは類似の電子デバイスのアクションならびにプロセス、すなわちコンピュータ・システムのレジスタならびにメモリ内の物理（電気）量として表されたデータを操作し、コンピュータ・システムのレジスタもしくはメモリまたはそのほかのその種の情報ストレージ、送信または表示デバイス内における物理量として同様に表される別のデータへ変換するアクションならびにプロセスを言う。
【００２４】
また、この明細書は、この方法のオペレーションを実行するための装置も開示している。この種の装置は、要求された目的に対して専用に構成されるものとしてもよく、あるいはコンピュータ内にストアされたコンピュータ・プログラムによって選択的にアクティブ化されるか、または再構成される汎用コンピュータもしくはそのほかのデバイスを有することができる。ここに示されているアルゴリズムならびに表示は、本質的に、特定のコンピュータもしくはそのほかの装置のいずれにも関連していない。ここでの教示に従ったプログラムとともに、各種の汎用マシンを使用することができる。それに代えて、必要な方法ステップを実行するべく、より特化された装置の構成が適切となることもある。たとえば、インターネット・ディレクトリ・サーバ・コンピュータを、以下に述べる計算、比較、および選択のステップを実行するためのコンピュータ・プログラムをインストールすることによって、そこにストアされたディレクトリを投入するべく構成することができる。
【００２５】
さらに、この明細書は、この方法のオペレーションを実行するためのコンピュータ・プログラムがストアされたコンピュータ可読メディアを含むコンピュータ・プログラム・プロダクトも開示している。コンピュータ可読メディアは、ソースとディスティネーションの間においてコンピュータ・プログラムを伝達するための任意の伝送メディアを含むものと考える。この伝達メディアには、磁気または光ディスク等のストレージ・デバイス、メモリ・チップ等のストレージ・デバイス、あるいは汎用コンピュータとのインターフェースに適したそのほかのストレージ・デバイスを含めることができる。また伝送メディアは、インターネット・システムに例示されるようなハード・ワイヤード・メディア、あるいはＧＳＭ携帯電話システムに例示されるようなワイヤレス・メディアを含むことができる。このコンピュータ・プログラムは、あらゆる特定のプログラミング言語、およびその実装への限定が意図されていない。各種のプログラミング言語ならびにそのコーディングを使用して、ここに含まれている開示の教示を具体化できることを認識されるであろう。
【００２６】
添付図面の任意の１つもしくはそのいくつかにおいて、同一の参照番号を有するステップおよび／または特徴への参照が行われているところでは、それらのステップおよび／または特徴がこの記述の目的に関して、同一の機能（１ないしは複数）またはオペレーション（１ないしは複数）を、それに反する意図が現れていない限り有する。
【００２７】
参照の容易のため、以下に述べる説明は、次に示す小項目に分けられている：
Ａ．  第１の実施態様
Ｉ．  概要
ＩＩ．  メッセージ処理
ＩＩＩ．  サービス・インターフェース
ＩＶ．  プラグイン可能なデータ・ファイル・コンバータ
Ｖ．  ドキュメント・マージャ
ＶＩ．  プレファレンス規則プロセス
ＶＩＩ．  トランスミッタ
ＶＩＩＩ．  キャリア・インターフェース
ＩＸ．  エスカレーション・プロセッサ
Ｘ．  レポーティング
ＸＩ．  差し込み／送信の同時性／パイプライニング
Ｂ．  第２の実施態様
Ｉ．  概要
ＩＩ．  コンセプト
ＩＩＩ．  ウェブ・インターフェース
ＩＶ．  システム・アーキテクチャ
Ｖ．  データ・ファイル構造
ＶＩＩ．  データベース構造
ＶＩＩＩ．  ジャバ（Ｊａｖａ）マッピング・クラスおよびＸＳＬテンプレート
【００２８】
Ａ．  第１の実施態様
Ｉ．  概要
本発明の一実施態様に従った大量通信プロセスおよびシステムの重要な側面は、次の内容を含む：
・  発信者は、１つのサービスを使用し、単一のインターフェースを介して、かつ単一の受信者リストを使用して受信者との大量通信を行うことが可能であり、しかも従来的な（物理）メール、電子メール（暗号化および非暗号化）、ファクシミリ、およびＳＭＳ等を含むすべての現在利用可能なメディアを経由して配信可能であるだけでなく、ホスト付きドキュメント・アーカイビングおよび検索システムへのドキュメントの配信が可能である（かつ、将来における別のメディア・テクノロジへ拡張することができる）。
・  個別の受信者について配信プレファレンスをはじめエスカレーション規則を指定することができる。したがって、たとえば受信者は、その受信者がファクシミリを経由して通信を受信することを優先するが、そのファクシミリが失敗した場合には、その情報が物理メールによって受け取られると好ましいという指定を行うことができる。これは、個別の受信者レベルをはじめ、包括的なレベルにおいて行うことが可能である。
・  システム内への１つのアプリケーション・プログラミング・インターフェース（ＡＰＩ）が存在する。この１つのＡＰＩを経由して、ファクシミリ、電子メール、暗号化電子メール、ＳＭＳ、物理メール、およびアーカイビング（および、利用可能になったときには将来のメディア・タイプ）のいずれを使用しても配信を行うことができる。
・  プロセスは、将来的な配信メディアのタイプ（たとえば、ＷＡＰ、別のワイヤレス等）の組み込みの要求を容易に満たすべく、コンポーネント化された態様で設計されている。
・  各種のターゲット・メディアのすべてに対する配信に、単一の受信者リストを使用することができる。この受信者リストは、任意のフォーマットとすることが可能であり、プロセスがそのリストをＸＭＬへ変換する。多様な入力受信者ファイル・フォーマットがサポートされ、ＸＭＬフォーマットへのデータ変換が行われる。
・  差し込み（パーソナル化）は、各種の配信メディアのすべてについて、受信者リスト内のフィールドを使用して行うことができる。これは、ＳＭＳテキスト・メッセージ、電子メール本文ならびに件名テキストのパーソナル化をはじめ、ワード（Ｗｏｒｄ）、ポータブル・ドキュメント・フォーマット（Ｐｏｒｔａｂｌｅ  Ｄｏｃｕｍｅｎｔ  Ｆｏｒｍａｔ）（ＰＤＦ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、およびＭＩＭＥ‐ＨＴＭＬ（ＭＨＴＭＬ）のためのドキュメント差し込みを含む。ＭＩＭＥは、マルチパーパス・インターネット・メール・エクステンション（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎ）の略語である。ドキュメント差し込みは、最先端のＸＭＬドキュメント・フォーマットおよびデータ・フォーマットならびにプレゼンテーションのためのＸＳＬならびにＸＳＬ‐ＦＯのスタイルシートを使用してサポートされる。
・  サービスは、物理メールのメーリング・ハウスを含めたキャリアに対するすべてのインターフェース、およびホスト付きアーカイビング・サービスに対するインターフェースを管理する。発信者側においてソフトウエアをインストールし、もしくは管理する必要はない。同一メディア・タイプについて異なるキャリアがサポートされることも許され、発信者は、優先するキャリアを指定することができる。
・  異なるメディア・タイプにわたるすべての受信者に関する成功／失敗、および発生したエスカレーションに関するレポーティングを含めた配信結果の統合されたレポーティングが提供される。統合されたレポーティング・インターフェースが提供され、それによってユーザは、個別の受信者のメッセージングならびにエスカレーション状態を観察することが可能になる。
・  このプロセスは、従来的な物理メールのメーリング・ハウスによって多数の受信者がターゲットされる方法と類似の態様において多数の受信者がターゲットとなる「大量メーリング」シナリオのために設計されている。
【００２９】
このプロセスまたはシステムは、次に示すテクニックの１ないしは複数を使用して、ほかのメッセージング・サービスに見られない特徴を提供する：
・  プロセスは、受信者との通信において必要とされる共通エレメントを認識し、それらのエレメントをＸＭＬドキュメント内にカプセル化する。これらのエレメントには、受信者の配信プレファレンス、およびエスカレーション評価基準のセットが含まれる。配信プレファレンスならびにエスカレーション評価基準は、簡略表記を使用して指定される。プロプラエタリＸＭＬスキーマもまた、ＸＭＬドキュメント・フォーマットの記述のために定義される。
・  プロセスは、リモート・アクセス可能な、かつ安全な電子インターフェースまたは共通インターフェースを提供する。単一のアプリケーション・プログラミング・インターフェース（ＡＰＩ）が、一貫性のある態様においてすべての形式のメッセージをサポートする。共通インターフェースへは、ファイル転送プロトコル（ＦＴＰ）もしくはシンプル・オブジェクト・アクセス・プロトコル（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）（ＳＯＡＰ）のいずれかによってアクセスされる。このインターフェースへは、ウェブ・ユーザ・インターフェースを経由してもアクセスが可能である。
・  サービスは、受信者データを各種のドキュメント・フォーマットへ差し込むサービスを可能にするデータ差し込み（パーソナル化）機能を提供し、そのドキュメント・フォーマットには、ＰＤＦ、ＨＴＭＬ、ＭＨＴＭＬ、マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）、およびテキストが含まれる。好ましくはサービスがエクステンシブル・スタイルシート・ランゲージ・フォーマティング・オブジェクト（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ  Ｆｏｒｍａｔｔｉｎｇ  Ｏｂｊｅｃｔｓ）（ＸＳＬ‐ＦＯ）フォーマッティング・エンジンを使用してデータ差し込みを実行する。パーソナル化機能は、電子メール・メッセージをはじめＳＭＳを経由して送信されるメッセージの件名行および本文テキストをパーソナル化する能力を含む。
・  ＡＰＩは、データ・コンバータを指定するためのメカニズムをサポートする。このサービスは、カスタム化されたデータ・コンバータが動的に記述され、かつプラグインされることを可能にする特殊なコードを組み込んでいる。データ・コンバータは、任意のフォーマットの（つまり、発信者のアカウンティングまたはＥＲＰシステムから抽出されたとおりの）受信者データを取り込み、その受信者データを、メッセージング・エンジンへ供給するための共通ＸＭＬフォーマットへ変換する。
・  このサービスは、次に示すすべてのキャリア・インターフェースを管理する：すなわち、ＳＭＳ、電子メール、暗号化電子メール、ファクシミリ、従来的な（物理）メール、およびアーカイビングである。これは、独立したコード・レイヤをシステム内に有し、それが残りのメッセージング・エンジンへ共通キャリア・インターフェースを提供することによって達成される。またこれは、将来的なメディア・タイプが容易にサービス内へ組み込まれることも可能にする（たとえばＷＡＰ）。さらにこのサービスは、キャリアの選択に関して発信者が有するプレファレンスをストアすることもできる。
・  このサービスは、各種のドキュメント‐テンプレートならびに配信メディア・タイプのすべてについて、単一セットの入力データを再使用する。これは、１つのモジュールまたはコンポーネント内においてドキュメントの差し込みを行い、個別のモジュール内のキャリア・インターフェースへ与えるためのそのフォーマティングを行うことによってなされる。
・  このサービスは、キャリアから返される各種タイプのレポートを受け取り、それらのレポートを、リレーショナル・データベース内にストアするための共通フォーマットへ変換することによって、ユーザに対して単一の統合されたレポーティング・インターフェースを提供する。続いてこのサービスは、配信を追跡し、かつエスカレーション手続きをドライブするために、それらの配信レポートを個別のメッセージング受信者と調和させる。これによってこのサービスは、個別のメッセージの成功ならびに失敗に関するレポートをユーザへ提供すること、および個別の受信者のためにとられたエスカレーション・パスを示すことが可能になる。
・  このサービスは、高容量のメッセージング・スループットを可能にするような方法で具体化されている。このサービスは、メッセージング・プロセス内のステップを異なるコンポーネントに分解することによってこれを行っている。続いてこれらのコンポーネントが同時に実行され、その結果、多くの異なるステップが同時に実行される。
【００３０】
ＩＩ．  メッセージ処理
図１は、ソフトウエア内における具体化が可能なメッセージング・プロセス１００を図式的に示している。プロセスは、ステップ１０２において開始する。受信者データ・ファイル１０６、ｊｏｂＤｅｓｃｒｉｐｔｏｒ．ＸＭＬ（ジョブディスクリプタ．ＸＭＬ）１０８、およびテンプレート・ドキュメント１１０が、ＡＰＩを経由してステップ１０４において受け取られる。ｊｏｂＤｅｓｃｒｉｐｔｏｒ．ＸＭＬ（ジョブディスクリプタ．ＸＭＬ）１０８の詳細については、この後に説明する。ステップ１１２においては、ジョブ・パラメータが処理され、データ・ファイルが入力される。ステップ１１４においては、チェックが行われて、データ・コンバータが指定されているか否かについて決定される。ステップ１１４が真（ＹＥＳ）を返した場合には、プロセスがステップ１１６へ進み、指定されたカスタム・コンバータがロードされる。ステップ１１８においては、このカスタム・コンバータを使用してデータがＸＭＬへ変換され、その後プロセスがステップ１２０へ進む。ステップ１１４が偽（ＮＯ）を返した場合には、そこからプロセスがステップ１２０へ進む。
【００３１】
ステップ１２０においては、ＸＭＬ受信者リストの妥当性検査が行われた後、それがデータベースへストアされる。これは、ストア済みの受信者のデータならびに配信プレファレンス１２２をもたらす。ステップ１２４においては、受信者の配信プレファレンスが処理され、さらに異なるメディア・タイプごとの束に分解される。ステップ１２６においては、チェックが行われてそれぞれのメディア・タイプ用のドキュメント・テンプレートが決定され、対応するドキュメント・マージャが選択される。ドキュメント・テンプレートは、特定のメディア・タイプごとに、すべての受信者について同一である。ドキュメント・マージャは、各個別の受信者のデータを受け取り、ドキュメント・テンプレートへのそのデータの差し込みを行って、その受信者用にパーソナル化されたドキュメントを生成する。このドキュメント・テンプレートは、ＸＳＬドキュメントとすることができる。それに代わるべきものとしては、ＭＳワード（ＭＳ  Ｗｏｒｄ）テンプレートおよびＨＴＭＬテンプレートがサポートされる。これが「テンプレート・タイプ」である。テンプレート・タイプに応じて、異なるドキュメント・マージャ（ＸＳＬ‐ＦＯマージャ、ＭＳワード（ＭＳ  Ｗｏｒｄ）マージャ、ＨＴＭＬマージャ等）がロードされる。ステップ１２６から、１ないしは複数の差し込みステップまたは差し込みオペレーションを行うことができる。これらの差し込みステップは、テキスト差し込み１２８、ＰＤＦ差し込み１３０、ポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）差し込み１３２、ＨＴＭＬ差し込み１３４、およびマイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）差し込み１３６を含む。当業者であればこの開示に照らして認識されることになろうが、本発明の範囲ならびに精神から逸脱することなくこのほかのタイプの差し込みを実施することもできる。これらの差し込みステップ１２８〜１３６へは、受信者データ１３８が供給される。
【００３２】
ステップ１２８〜１３６のそれぞれから、プロセスは、ステップ１４０へ進む。ステップ１４０においては、チェックが行われて受信者用の配信キャリアが選択される。これは、以前の「受信者の配信プレファレンスを処理する」ステップ１２４の結果を、このジョブの発信者用に構成された各メディアについて優先するキャリアとともに再チェックする。これらの２つの情報の組み合わせは、使用するキャリア・モジュールの決定に使用される。ファクシミリが送信されることになる場合には、プロセスがステップ１４２〜１４４を含むパスを通る。電子メールが送信されることになる場合には、ステップ１４８〜１５２を含むパスをプロセスが通る。物理メールが送られることになる場合には、ステップ１５４〜１５８を含むパスをプロセスが通る。ＳＭＳメッセージが送信されることになる場合には、ステップ１６０〜１６４を含むパスをプロセスが通る。ドキュメントのアーカイブが行われる場合には、ステップ１６６〜１７０を含むパスをプロセスが通る。
【００３３】
ファクシミリのパスについては、差し込み済みドキュメントが、ステップ１４２において、好ましくはＴＩＦＦとするビットマップ・フォーマットへ変換される。ステップ１４４においては、このＴＩＦＦフォーマットのドキュメントが、送信のためにファクシミリ・キャリアへ渡される。ステップ１４６においては、生成されたファクシミリ・キャリア・レポートの処理ならびにパーズが行われる。送信ステータスが、受信者リストに基づいて追跡される。その後、プロセスがステップ１７２へ進む。
【００３４】
電子メールのパスについては、差し込み済みドキュメントが、必要な場合にはステップ１４８においてＭＨＴＭＬフォーマットへ変換される。ドキュメントがＰＤＦ、ＨＴＭＬ、またはマイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）の添付として残存していることから、しばしばこのＭＨＴＭＬへの変換が不要になる。ステップ１５０においては、添付として、あるいは埋め込みＭＴＨＭＬとしてドキュメントを含む電子メール・メッセージが電子メール・キャリアへ渡される。ステップ１５２においては、生成された電子メール・キャリア・レポートの処理ならびにパーズが行われる。送信ステータスが、受信者リストに基づいて追跡される。その後、プロセスがステップ１７２へ進む。
【００３５】
物理メールのパスについては、差し込み済みドキュメントが、必要な場合にはステップ１５４においてポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）フォーマットへ変換される。ステップ１５６においては、このポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）フォーマットのドキュメントが、送信のために従来的な物理メール・キャリアへ渡される。ステップ１５８においては、生成された物理メール・キャリア・レポートの処理ならびにパーズが行われる。送信ステータスが、受信者リストに基づいて追跡される。その後、プロセスがステップ１７２へ進む。
【００３６】
ＳＭＳメッセージのパスについては、差し込み済みドキュメントが、必要な場合にはステップ１６０においてＳＭＳ用にフォーマットされる。ステップ１６２においては、このＳＭＳフォーマットのドキュメントが、送信のためにＳＭＳキャリアへ渡される。ステップ１６４においては、生成されたＳＭＳキャリア・レポートの処理ならびにパーズが行われる。送信ステータスが、受信者リストに基づいて追跡される。その後、プロセスがステップ１７２へ進む。
【００３７】
アーカイビングのパスについては、差し込み済みドキュメントが、必要な場合にはステップ１６６においてアーカイビング用にフォーマットされる。このフォーマットは、概してＰＤＦもしくはポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）であるが、アーカイビング・システムによって必須とされている特定のフォーマットはなく、したがってフォーマットは、発信者のプレファレンスに依存する。ステップ１６８においては、フォーマット済みのドキュメントがアーカイビング・システムへ渡される。ステップ１７０においては、アーカイビング・システムによって生成されたレポートの処理ならびにパーズが行われる。送信ステータスが、受信者リストに基づいて追跡される。その後、プロセスがステップ１７２へ進む。
【００３８】
ステップ１７２においては、受信者リストのステータスならびに配信プレファレンス１７６に基づき、必要に応じてエスカレーションが処理される。ステップ１７８においては、エスカレーションが必要か否かのチェックが行われる。ステップ１７８が真（ＹＥＳ）を返した場合には、エスカレーションの生じた受信者についてのプロセスがステップ１２４へ続く。それ以外の場合、すなわちステップ１７８が偽（ＮＯ）を返した場合には、ステップ１８０においてプロセスが終了する。
【００３９】
図１のプロセス１００提供するために使用されるソフトウエア・アーキテクチャは、オーストラリア仮特許出願第２００２９５０４３５号の図１１および１１Ａ〜１１Ｍのクラス図に図解されており、それらについては、参照によってこれに援用されている。オーストラリア仮特許出願第２００２９５０４３５号においては、図１１が図１１Ａ〜１１Ｍに示されているそれぞれの部分の配置を示している。これらのクラス図は、アプリケーションのアーキテクチャならびに当該アプリケーションを構成するコンポーネントの詳細な記述を提供する。これらのコンポーネントには、エスカレーション処理、ステータス処理、ジョブの提出ならびに処理、差し込み、フォーマッティング、およびキャリア送信が含まれる。このスキーマは、そのアーキテクチャのいくつかの側面を伝える。
【００４０】
次に、このプロセスの追加の側面について詳細に説明する。
【００４１】
ＩＩＩ．  サービス・インターフェース
本発明のこの実施態様は、好ましくはアプリケーション・サービス・プロバイダ（ＡＳＰ）モデルとして一般に知られているホスト付きサービスとして提供される。好ましくは、各種のアクセス・モデルが、ホスト付きサービスへのアクセスのために使用され、かつ３つの異なるインターフェース・コンポーネントによってそれぞれサポートされる。図２には、ウェブ・サービス・インターフェース（ＳＯＡＰ）２１０、ＦＴＰインターフェース２１２、およびウェブ・グラフィカル・ユーザ・インターフェース（ブラウザ／ＨＴＭＬベース）２１４を含むサービス・インターフェース２００が示されている。これら３つの外部インターフェース・コンポーネント２１０、２１２、および２１４はすべて、同一の基礎をなす共通インターフェース・コンポーネント２１６を使用し、好ましくはそれをＸＭＬとする。
【００４２】
ウェブ・サービスは、ユニバーサル・ディスクリプション・ディスカバリ・アンド・インテグレーション（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ，  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）（ＵＤＤＩ）およびウェブ・サービス・ディスクリプション・ランゲージ（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）（ＷＳＤＬ）標準によって記述されている形式的インターフェースである。ホスト付きサービスは、この標準に適合するインターフェース２１０を提供する。ＦＴＰ（ファイル転送プロトコル）は、インターネットを介してファイルを転送するための共通プロトコルである。ホスト付きサービスは、ＦＴＰインターフェース２１２を提供するが、それはこのインターフェース２１２が、発信者にとってアクセス容易なインターフェースであると一般に理解されていることによる。ウェブ・グラフィカル・ユーザ・インターフェース２１４は、発信者が、グラフィカル・ユーザ・インターフェースを介してジョブをマニュアル提出することができるように提供されている。
【００４３】
これら各種のインターフェース２１０、２１２、２１４は軽量であり、図２に示されているように、基礎をなす共通インターフェース２１６への提出のための共通フォーマットにデータを整理する。インターフェース・パラメータは、ＸＭＬとして渡される。ＸＭＬスキーマもまた、ジョブを記述するために定義されている。このスキーマは、各種メディア用の各種ドキュメント・テンプレートを提供するため、また、特定のジョブに関するほかのプレファレンスを指定するためのメカニズムを提供する。図１に示されているこのＸＭＬジョブ記述ファイル（「ｊｏｂＤｅｓｃｒｉｐｔｏｒ」ＸＭＬ（「ジョブディスクリプタ」ＸＭＬ）））１０８のフォーマットについては、このＸＭＬスキーマ内の重要なタグを含めて次の表１（表１ａ〜表１ｅ）に示す。
【００４４】
【表１ａ】
2005535013.tif 000003
【表１ｂ】
2005535013.tif 000004
【表１ｃ】
2005535013.tif 000005
【表１ｄ】
2005535013.tif 000006
【表１ｅ】
2005535013.tif 000007
【００４５】
ＩＶ．  プラグイン可能なデータ・ファイル・コンバータ
ホスト付きサービスを使用する発信者は、特定の大量通信の一部として、ターゲットされている受信者についての情報を含むファイルを提出する。これらのファイルは、内部データベースまたはビジネス、組織等のアカウンティング・システムから抽出することができる。本発明のこの実施態様は、ＸＭＬ入力ファイルについて標準化し、したがって図３に示されているとおり、データ変換３００が受信者リスト・ファイル３１０をＸＭＬ  ３１４へ変換する。たとえば、受信者リスト・ファイル３１０は、テキストまたはフラット・ファイルとすることができる。この変換は、データ・ファイル・コンバータ３１２を使用して行われ、好ましくはそれを、基礎をなすプラットフォーム内へのカスタム化されたコンバータのプラグインを可能にするコンポーネントとする。その場合の入力ファイルの変換は、サービスのユーザにとってトランスペアレントになる。本発明のこの実施態様においては、データ変換が次のように具体化される。
・  ＣｕｓｔｏｍＭａｐｐｅｒＩｎｔｅｒｆａｃｅ（カスタムマッパーインターフェース）と呼ばれるジャバ（Ｊａｖａ）インターフェースが定義される。
・  このジャバ（Ｊａｖａ）インターフェースは、次に示すメソッドを定義する：
ＣｏｎｖｅｒｔＦｉｌｅ（Ｈａｓｈｍａｐ  ｈｍ，  Ｄｅｓｔｉｎａｔｉｏｎ  ｄ）
・  ＪｏｂＤｅｓｃｒｉｐｔｏｒ．ｘｍｌ（ジョブディスクリプタ．ｘｍｌ）入力ファイルは、カスタム・マッパーが使用されることになるか否かを示す「ＣｕｓｔｏｍＪａｖａＭａｐｐｉｎｇ」（カスタムジャバマッピング）タグ、変換クラスを指定することのできる「ＣｕｓｔｏｍＪａｖａＣｌａｓｓＮａｍｅ」（カスタムジャバクラスネーム）タグ、およびファイル名の鍵付きセットを指定することのできる「ＪａｖａＭａｐｐｉｎｇＦｉｌｅ」（ジャバマッピングファイル）タグを有している。
・  ジョブ処理エンジンは、ジャバ（Ｊａｖａ）の反射機能を使用してＣｕｓｔｏｍ  Ｊａｖａ  Ｃｏｎｖｅｒｔｅｒ（カスタム・ジャバ・コンバータ）クラスのインスタンス作成を行い、ＪａｖａＭａｐｐｉｎｇＦｉｌｅ（ジャバマッピングファイル）パラメータをＨａｓｈｍａｐ（ハッシュマップ）内のＣｕｓｔｏｍ  Ｊａｖａ  Ｃｏｎｖｅｒｔｅｒ（カスタム・ジャバ・コンバータ）クラスへ渡す。
・  その後、Ｃｕｓｔｏｍ  Ｊａｖａ（カスタム・ジャバ）クラスが、ファイル・パラメータを処理し、変換済みファイルを生成する。
【００４６】
Ｖ．  ドキュメント・マージャ
本発明のこの実施態様は、各種タイプのメディアに対する配信用にデータをフォーマットする。図４は、相応じてドキュメント差し込み４００がどのように扱われるかについて示している。ＸＭＬ受信者リスト４１０（図３のリスト３１４に対応する）およびＸＳＬまたはＸＳＬ‐ＦＯテンプレート４１２が、好ましくはＰＤＦもしくはＨＴＭＬとする所望のフォーマットのドキュメント４１６を作成するために、ドキュメント・マージャ・モジュールまたはコンポーネント４１４へ渡される。このプレゼンテーション・フォーマッティングを実行するために、ＸＳＬまたはＸＳＬ‐ＦＯ標準が使用され、ＸＭＬデータのフォーマッティングならびにプレゼンテーションのための規則が定義される。ドキュメント・マージャ・モジュールまたはコンポーネント４１４は、選択したＸＳＬまたはＸＳＬ‐ＦＯテンプレート４１２を、基礎をなすＸＭＬ受信者リスト４１０に適用して、クライアントへ送信するためのＰＤＦまたはＨＴＭＬドキュメント４１６を作成する。
【００４７】
単一の受信者リストを使用し、受信者の配信プレファレンスに基づいて、多様な各種のメディアに対するデータの差し込み（パーソナル化）および配信を可能にするために、特殊なＸＭＬ受信者リスト・スキーマ１０００が定義されており、図１０ａ、１０ｂ、および１０ｃに図示されている。図１０には、特定のスキーマが示されているが、当業者であればこの開示に照らして認識されるように、本発明の範囲ならびに精神から逸脱することなく、このスキーマに対して修正および／または置換を行うことができる。スキーマ１０００は、次に示す２つの主要なサブセクションに分けられる。
１．  送信規則セット：各種メディアに関する受信者ごとのアドレスおよびプレファレンス評価基準を記述する。
２．  受信者データ・セクション：送信されるドキュメント内へ差し込まれることになるデータを含む。受信者データ・セクションは、本発明のＸＭＬスキーマに従って構成することができる。それに代えて、発信者が独自のＸＭＬスキーマに従って受信者データのこの部分を構成することを可能にするＸＭＬデータ・サブエレメント・タイプの提供もある。
【００４８】
ＶＩ．  プレファレンス規則プロセス
本発明のこの実施態様においては、複雑なものも含めて、個別の受信者用にプレファレンス規則を指定することが可能であり、それには、そのプレファレンス規則を定義するための所定の表記法を使用する。たとえば、本発明のこの実施態様は、表記法（Ｆ：Ｓ‐Ｐ）を使用して、ファクシミリ（Ｆａｘ）およびＳＭＳを送信し、それらがともに失敗した場合には、それに代えて物理メール（ペーパー（Ｐａｐｅｒ））により送信することを意味する。好ましくはユーザ・インターフェースが配信プレファレンスを選択するために使用され、簡略表記が配信プレファレンスを指定するために使用される。配信メディア・タイプについての規則の表記法を、次の表２に詳細に示す。
【００４９】
【表２】
2005535013.tif 000008
【００５０】
優先する規則を考慮し、かつ１を超えるメディア・タイプを１つの規則に結合する能力を提供するために、いくつかの演算子が使用される。リスト・プレファレンスは、規則の連続として指定し、ダッシュ（‐）によって区切る。ダッシュ（‐）は、先行する規則が失敗した場合に、次の規則を使用することを示す。規則は、単一のメディア・タイプの指定（たとえばファクシミリ（Ｆａｘ）についてＦ）のように単純になることもあり、あるいはプラス（＋）またはコロン（：）演算子によって区切られたメディア・タイプのストリングとなることもあるが、詳細については以下に述べる。括弧「（」および「）」は、１を超えるメディア・タイプを含む規則をカプセル化するために使用される。
【００５１】
ダッシュ（‐）演算子の使用を例示した単純なプレファレンス規則の例を次に示す。
【００５２】
Ｅ‐Ｆ‐Ｐ        （１）
【００５３】
この規則は、電子メールを送信することを示す（規則１）。規則１が失敗した場合（たとえば、電子メール・アドレスが指定されていない場合）には、ファクシミリを送信する（規則２）。規則２が失敗した場合には、ペーパー‐ベースのメディアを介してアイテムを送信する（規則３）。
【００５４】
２つのメディア・タイプがプラス（＋）演算子によって分けられている場合には、それら２つのメディア・タイプをともに使用して（優先順位なし）情報を送信することを意味する。いずれの送信も不可能であった場合に規則が失敗する。たとえば、規則（Ｆ＋Ｅ）は、電子メールおよびファクシミリの両方の送信を試みることを示す。この規則は、ファクシミリ番号および電子メール・アドレスがいずれも提供されていない場合に失敗する。
【００５５】
プラス（＋）演算子および優先順位演算子（‐）の組み合わせの例を次に示す。
【００５６】
（Ｅ＋Ｆ）‐Ｐ        （２）
【００５７】
この規則は、ファクシミリおよび電子メールをともに送信することを示す。これらのメディアが、いずれも成功しなかった場合（たとえば、ファクシミリ番号および電子メール・アドレスが指定されていない場合）には、ダッシュ（‐）演算子が作用して、プロセスが次の規則へ移り、そこでドキュメントをペーパーによって送信することが示される。
【００５８】
２つのメディア・タイプがコロン（：）演算子によって分けられている場合には、特定のメディア・タイプをともに送信することを示す（優先順位なし；つまりプラス（＋）演算子に同じ）。しかしながらこの規則は、メディアの一方が送信できないときに失敗する。たとえば、（Ｆ：Ｅ）は、電子メールならびにファクシミリの両方の送信を試みることを示す。この規則は、ファクシミリ番号もしくは電子メール・アドレスのいずれかが提供されていないときに失敗する。コロン（：）演算子および優先順位演算子（‐）の組み合わせの例を次に示す。
【００５９】
（Ｅ：Ｆ）‐Ｐ        （３）
【００６０】
この規則は、ファクシミリおよび電子メールをともに送信することを示す。いずれかのメディアが失敗した場合（たとえば、ファクシミリ番号もしくは電子メール・アドレスのいずれかが指定されていない場合）には、ダッシュ（‐）演算子が作用して、プロセスが次の規則へ移り、そこでドキュメントをペーパーによって送信することが示される。
【００６１】
各種の演算子の優先順位は、（）、＋、：、‐の順になっている。括弧が最初に評価され、プラス（＋）演算子がコロン（：）の前に評価されるが、これらはすべてダッシュ（‐）に先行して評価される。次に、各種の演算子のすべてを使用した複雑な規則を例示し、優先順位規則がどのように作用するかについて示す。
【００６２】
（Ｅ：Ｆ＋Ｓ）‐（Ｐ：Ｖ）      （４）
【００６３】
このシナリオにおいて、括弧が優先されることから、規則（Ｅ：Ｆ＋Ｓ）が最初に評価される。プラス（＋）は、括弧の次に優先され、したがってＦ＋Ｓが次に評価される。これは、ファクシミリならびにＳＭＳの両方へ情報を渡すことを示す。次に『：』が評価され、したがって規則Ｅ：『Ｆ＋Ｓ』が次に評価されることになる。これは、電子メールならびに『Ｆ＋Ｓ』（ファクシミリならびにＳＭＳの両方へ情報を渡すことを示す）の両方へ情報を渡すことを示す。この情報は、電子メール、ファクシミリ、およびＳＭＳの３つすべてに渡される。規則（Ｆ＋Ｓ）の失敗があったということは、ファクシミリおよびＳＭＳがともに失敗したことになる。Ｅ：『Ｆ＋Ｓ』の失敗は、電子メールもしくは「Ｆ＋Ｓ」のいずれかが失敗したことによる。最初に規則Ｅ：『Ｆ＋Ｓ』の全体が失敗した場合には、ダッシュ（‐）が作用し、次の規則（Ｐ：Ｖ）が有効になる。この規則（Ｐ：Ｖ）は、ペーパーおよび音声の両方へ情報を渡すことを示す。まとめると、例（４）の規則は、電子メール、ファクシミリ、およびＳＭＳに対して情報を渡すことを示している。電子メールが失敗した場合（たとえば電子メール・アドレスが指定されていない）、あるいはＳＭＳならびにファクシミリの両方が失敗した場合（たとえばＳＭＳおよびファクシミリ番号が与えられていない）には、情報がペーパーならびに音声の両方へ渡される。
【００６４】
本発明のこの実施態様においては、ユーザ・インターフェース・コンポーネントまたはモジュールによって、単純な配信の組み合わせの迅速な入力が可能になる一方、同時に複雑な規則を入力するオプションの提供が可能になる。図８に示されているユーザ・インターフェース・コンポーネント８００は、ブロードキャスト・オプションというタイトルが付けられており、それぞれのメディア・タイプ用のチェックボックス８０２をいくつか含み、それにはファクシミリ、電子メール、ＳＭＳ、音声、およびペーパーが含まれている。「全員へ送信する」または「リスト・プレファレンスを使用する」を選択するためのラジオ・ボタン８０４も備わっている。ユーザは、リスト・プレファレンスを上書きする規則をテキスト入力ボックス８０６内に指定することができる（たとえば、（Ｅ＋Ｓ）‐Ｆ‐Ｐ）。
【００６５】
プレファレンス規則プロセッサは、受信者のプレファレンスを解釈し、各受信者について送信する配信メディアを決定する。図５は、プレファレンス規則を処理するための方法５００を示している。ＸＭＬフォーマットの受信者データ５１０がステップ５１２において提供され、それがそれぞれの場合に応じて最初の、または次の受信者のためのプレファレンス規則データをロードする。ステップ５１４においては、これより以前の処理が完了しているというポジションからプロセスが開始する。ステップ５１６においては、チェックが行われ、処理のために残されている文字があるか否かについて決定される。ステップ５１６が偽（ＮＯ）を返した場合には、ステップ５４８において現在の回の規則処理が終了する。それ以外の場合、すなわちステップ５１６が真（ＹＥＳ）を返した場合には、プロセスがステップ５１８へ進む。
【００６６】
ステップ５１８においては、優先順位演算子を表す文字またはメディアの表記に応じて実行が分岐する。ステップ５１８が「（」または「）」であると決定した場合には、プロセスが５２０へ進む。ステップ５２０においては、チェックが行われ、いずれのタイプの括弧が関係しているかについて決定される。ステップ５２０において「（」であると決定された場合には、プロセスがステップ５２２へ進み、開始括弧が記録される。それ以外の場合、すなわちステップ５２０において「）」であると決定された場合には、プロセスがステップ５２４へ進む。ステップ５２４においては、閉じ括弧が記録され、先行する規則セットのグループが作成される。プロセスは、ステップ５２２および５２４のそれぞれから、ステップ５１６へ進む。
【００６７】
ステップ５１８が、現在の文字は（Ｆ、Ｅ、Ｓ、Ｐ、Ａ、Ｃ）であると決定した場合には、プロセスが５２６へ進む。ステップ５２６においては、チェックが行われ、その文字がＦ、Ｅ、Ｓ、Ｐ、Ａ、またはＣのいずれであるか決定される。ステップ５２６がＦを返した場合には、プロセスがステップ５２８へ進み、その受信者がファクシミリ・リストに追加される。ステップ５２６がＥを返した場合には、プロセスがステップ５３０へ進み、その受信者が電子メール・リストに追加される。ステップ５２６がＣを返した場合には、プロセスがステップ５３２へ進み、その受信者が暗号化電子メール・リストに追加される。ステップ５２６がＰを返した場合には、プロセスがステップ５３４へ進み、その受信者が物理メール（ペーパー）リストに追加される。ステップ５２６がＳを返した場合には、プロセスがステップ５３６へ進み、その受信者がＳＭＳリストに追加される。ステップ５２６がＡを返した場合には、プロセスがステップ５３８へ進み、その受信者がアーカイビング・リストに追加される。プロセスは、ステップ５２８、５３０、５３２、５３４、５３６、および５３８のそれぞれからステップ５１６へ進む。
【００６８】
ステップ５１８が、現在の文字は演算子『：』、『＋』、または『‐』であると決定した場合には、プロセスがステップ５４０へ進む。ステップ５４０においては、チェックが行われ、現在の文字がいずれの演算子であるか決定される。ステップ５４０が『‐』を返した場合には、プロセスがステップ５４２へ進み、『‐』記号の後のポジションが記録される。その後、プロセスがステップ５４８へ進む。ステップ５４０が『‐』を返した場合には、プロセスがステップ５４４へ進み『‐』（ＯＲ）演算子が記録される。その後プロセスがステップ５１６へ進む。ステップ５４０が『＋』を返した場合には、プロセスがステップ５４６へ進み『＋』（ＡＮＤ）演算子が記録される。その後プロセスがステップ５１６へ進む。
【００６９】
ＶＩＩ．  トランスミッタ
トランスミッタは、キャリア・インターフェースへ与えるための最終的なデータの変換を行う。たとえば、ファクシミリ送信の場合には、ドキュメント・マージャ・プロセスから出力されたＰＤＦドキュメントが、ファクシミリ・キャリアへ与えるためのＴｉｆｆファイルへ変換される。このシステムは、適切な場合には各種のキャリア用に各種のトランスミッタがプラグインされることを許容する。
【００７０】
ＶＩＩＩ．  キャリア・インターフェース
キャリア・インターフェースは、選択された特定のメディア・タイプについて選択されたキャリアへ送信するための、キャリア固有のファイル・フォーマットへの最終的なデータ変換およびバッチが行われる。代替キャリアを各種のキャリア・インターフェース用にプラグインすること、および発信者のユーザ・プロファイルの一部としてキャリアの選択を動的に構成することができる。
【００７１】
ＩＸ．  エスカレーション・プロセッサ
エスカレーション・プロセスは、キャリア・インターフェースからの応答をチェックし、各受信者に向けた送信の結果をパーズする。ある送信が失敗した場合には、エスカレーション・プロセスが受信者のプレファレンス規則（プレファレンス規則プロセッサを経由して）を使用し、異なるメディアを介して通信をリトライするべきか否かについて決定し、当該異なるメディアを介したデータの送信を再スケジューリングするアクティビティを管理する。図６のフローチャートは、エスカレーション・プロセス６００を、特に、電子メールのためのエスカレーション規則がどのように作用するか（電子メールがもっとも複雑である）について例示している。そのほかのメディア・タイプについては、エスカレーションが、単純にキャリアから返される成功／失敗レポートを基礎としている。
【００７２】
図６においては、プロセスがステップ６１０から開始し、そこでキャリアへ電子メールを渡すことが試みられる。ステップ６１２においては、チェックが行われて、未知のＳＭＴＰサーバに起因するエラーが発生したか否かについて決定される。ステップ６１２が真（ＹＥＳ）を返した場合には、プロセスがステップ６２４へ進む。ステップ６１２が偽（ＮＯ）を返した場合には、プロセスがステップ６１４へ進む。ステップ６１４においては、チェックが行われて、バウンスされた電子メールが、ホスト付きサービスにおける発信者の（クライアントの）受信ボックス（ＥＭｄｉｒｅｃｔ）内に到達したか否かについて決定される。ステップ６１４が真（ＹＥＳ）を返した場合には、プロセスがステップ６２２へ進む。ステップ６２２においては、発信者がマニュアルで、その受信者宛の電子メール配信が失敗したことを示す。好ましくはこれが、ウェブ・インターフェースを介して行われる。その後プロセスは、ステップ６２４へ進む。ステップ６１４が偽（ＮＯ）を返した場合には、プロセスがステップ６１６へ進む。
【００７３】
ステップ６１６においては、チェックが行われて、電子メール開封タイムアウトが経過したか否かについて決定される。ステップ６１６が偽（ＮＯ）を返した場合には、プロセスがステップ６１８へ進む。ステップ６１８においてプロセスは、タイムアウトが経過するまで待機し、その後ステップ６１６へ進む。ステップ６１６が真（ＹＥＳ）を返した場合には、プロセスがステップ６２０へ進む。ステップ６２０においては、チェックが行われて、その電子メールが開封されたことを電子メール追跡が示しているか否かについて決定される。ステップ６２０が真（ＹＥＳ）を返した場合には、プロセスがステップ６３２において終了し、エスカレーションは行われない。ステップ６２０が偽（ＮＯ）を返した場合には、プロセスがステップ６３０へ進む。
【００７４】
ステップ６２４においては、チェックが行われて、エスカレーションのために発信者の承認が必要とされているか否かについて決定される。ステップ６２４が偽（ＮＯ）を返した場合には、プロセスがステップ６３０へ進み、次のメディア・タイプへのエスカレーションを生じる。それ以外の場合、すなわちステップ６２４が真（ＹＥＳ）を返した場合には、プロセスがステップ６２６へ進む。ステップ６２６においては、チェックが行われて、発信者の承認が与えられたか否かについて決定される。ステップ６２６が偽（ＮＯ）を返した場合には、プロセスがステップ６２８へ進む。ステップ６２８においては、ウェブ・インターフェース経由でマニュアルによる発信者の承認イベントを待機する。その後プロセスは、ステップ６２６へ進む。ステップ６２６が真（ＹＥＳ）を返した場合には、プロセスがステップ６３０へ進む。このプロセスのより詳細な説明を以下に示す。
【００７５】
エスカレーション・プロセスは、以下に示す機能を提供する。
・  エスカレーション機能を、オプションの余得（ユーザ・レベルにおいて構成される）および有料として相応じて提供できる能力。
・  ジョブ・レベルにおいて、特定のジョブについて、エスカレーションが必要とされているか否かを決定できる能力。
・  『リスト・プレファレンス』がジョブ提出に関して選択されている場合に、エスカレーションが受信者の配信プレファレンスに従って作用できる能力。
・  『リスト・プレファレンス』以外のブロードキャスト選択が使用される場合に、指定された選択にエスカレーションが追随できる能力（たとえば、電子メール＋ファクシミリ＋ペーパーは、最初に受信者に対する電子メールを試行し、それが失敗するとファクシミリへ移り、さらにそれが失敗するとペーパーへ移る）。
・  発信者が、マニュアルでエスカレーション・プロセスに介入し、かついずれのエスカレーションを進めるか、進めないかをマニュアルで表示できる能力。
・  ユーザが、要エスカレーションとしてマニュアルで電子メールにフラグを設定できる能力（したがって発信者は、到達したバウンスを確認した後にウェブ・サイトへ行き、それらを要エスカレーションとしてマークすることができる）。
【００７６】
各種のメディア・タイプについてのエスカレーション評価基準は、次のとおりとなる。メディア・タイプのいくつかについては、代替メカニズムが記述されている。代替手段が使用できる場合には、発信者が、いずれのエスカレーション評価基準の適用を発信者が希望するかについて選択することができる。これは、発信者のユーザ・プレファレンスの部分として構成される。
【００７７】
エスカレーションは、規定された回数のリトライの後においてもファクシミリの送信が不可能であった場合に生じることがある。これは、無効なファクシミリ番号から指定のファクシミリ装置へ接続するネットワーク障害（ＮＣＮ）まで、多様な理由に起因し得る。
【００７８】
エスカレーションは、規定日数内に受信者によって電子メールが開封されたことが追跡されなかった場合に生じることがある。しかしながら、電子メールのバウンスの自動化された処理が行われる必要はなく、ジョブの提出者がマニュアルで、特定の電子メールが送信に成功しなかった旨を（ウェブ・インターフェース経由で）示すことができるファシリティを提供してもよい。エスカレーションは、ＳＭＳ番号に接触できなかった（無効である）場合に生じることがある。これは、このレベルのレポーティングがモバイル・サービス・プロバイダによって提供され得るか否かに依存する。
【００７９】
エスカレーションは、物理メールのアドレスが首尾よくバーコード作成されなかった場合に生じることがある。メール・アドレスのバーコード作成ができない理由は、多様となり得る‐‐たとえば、郵便コードが提供されていないか無効な郵便コードが提供されている場合、あるいは特定の通りに無効な通り番号が提供されている場合などである。
【００８０】
次に示すフィールドが、エスカレーションに関連して次のユーザ・プレファレンスをストアするためにユーザ構成スクリーン上に用意される。
・  開封の記録がない場合に電子メールをエスカレートするか？
・  上記が真の場合に、エスカレーションまでに必要とする未開封の日数は？
・  ウェブ・インターフェースを経由し、電子メールを要エスカレーションとしてマニュアルでマークする機能を必要とするか？
・  エスカレーションが実際に生じる前にマニュアルの介入を必要とするか？
【００８１】
「エスカレーション」を構成する発信者のために、ウェブ・インターフェースを経由して提出されるすべてのジョブは、自動的にエスカレーションをスイッチ・オンする。エスカレーションは、選択されたブロードキャスト・プレファレンスに従って進められるか、あるいはリスト・プレファレンスがブロードキャスト・プレファレンスとして選択されている場合には、エスカレーションが個別の受信者のリスト・プレファレンスに従って進められる。
【００８２】
エスカレーションを構成する発信者のために、ＪｏｂＤｅｓｃｒｉｐｔｏｒ．ＸＭＬ（ジョブディスクリプタ．ＸＭＬ）ファイル内のＦＴＰインターフェースを経由して追加のオプションが用意される。これは「エスカレーション」フラグである。「エスカレーション」フラグが「Ｙ」にセットされている場合には、そのジョブに対してエスカレーションが適用される。エスカレーションは、選択されたブロードキャスト・プレファレンスに従って進められるか、あるいはリスト・プレファレンスがブロードキャスト・プレファレンスとして選択されている場合には、個別の受信者のリスト・プレファレンスに従ってエスカレーションが進められる。
【００８３】
ジョブ処理エンジンは、各受信者の配信状態を追跡し、受信者についてエスカレーション・イベントが生じた場合（たとえば、不良ファクシミリ・レポートの受信、またはＸ日内の電子メールの未開封、またはユーザによる特定のジョブがエスカレーションを必要とする旨のマニュアル・フラグ設定）には、エスカレーション・パスに沿ってそれらの受信者を移動する。
【００８４】
電子メールのためのエスカレーションのマニュアル・フラグ設定は、ウェブ・インターフェース経由で行うことができる。ジョブを提出した後、発信者は、そのジョブをサーチし、続いて「電子メール・エスカレーションを追加する」ボタンを選択することができる。これは、発信者に、すべての電子メール受信者のリストを提供し、発信者は、発信者がエスカレートさせたいと希望する任意の受信者に隣接する「エスカレート」ボックスにチェックすることができる。このスクリーンの目的は、主として、発信者が電子メールのバウンスを受信し、そのためエスカレーションが必要である旨をマニュアルで示したいと希望する状況に備えることである。このファシリティは、このほかの状況、すなわち発信者／センダが、電子メールを受信しないであろうという何らかの別の事前の知識を有している状況についても考慮している（たとえば、アカウント部門へ電子メールを送るが、定期的な電子メール接触が休日となることがわかっており、そのためファクシミリ／手紙を送り、その代理人がファクシミリ／手紙を受け取るようにしたいと希望する場合）。
【００８５】
エスカレーション・ステータス：ジョブを提出した後、ユーザは、随時ジョブをサーチし、すべての受信者の現在の状態を観察すること、およびそれらの受信者がエスカレートした否か、あるいはエスカレーションを進めるための発信者の承認の待機中であるか否かを観察することができる。エスカレーションの理由もまた示される（たとえば『３回のリトライを行ったがファクシミリが失敗した』、『電子メールが５日内に開封されなかった』、『通りのアドレスに対して無効な通り番号』、『マニュアルでフラグ設定されたエスカレーション』等）。
【００８６】
エスカレーション・プロセス：発信者がそれぞれのプロファイル内において「マニュアル仲裁」を構成している場合には、発信者は、エスカレーション・ステータス・スクリーンから「エスカレーションの処理」機能を選択することができる。これは、エスカレーションを待機している受信者のリストを表示する。エスカレーション・イベントを生じている受信者については、その受信者のステータス行の隣に「続行」チェックボックスがある。発信者は、エスカレーションに進むことを発信者が希望している受信者の一部もしくは全部（「すべてにチェック」ボタンを介して）にチェックし、続いて「選択したエスカレーションを続行する」ボタンを押すことができる。
【００８７】
メッセージ・リトライ：発信者は、エスカレーション・ステータス・スクリーンから「メッセージの再送」機能を選択することも可能であり、それによりエスカレーションを待機中の受信者のリストが表示される。エスカレーションに代えて、発信者は、特定の受信者に対して「リトライ」もしくは「アドレスを修正してリトライ」のいずれも選択することができる。「アドレスを修正してリトライ」を選択した場合には、ユーザに対して、修正後のファクシミリ番号、電子メール・アドレス、または物理メール・アドレスの入力を促すスクリーンが表示される。いずれのオプションについても、続いてアプリケーションが、以前の、もしくは更新された詳細を使用してその受信者への再送を試みる。ユーザは、そのユーザが再送を希望する受信者のそれぞれについて、この手続き（１度に１回）を行うことができる。再送の試みが成功した場合には、受信者がエスカレーション状態から出る。再送の試みが失敗すると、受信者は、エスカレーションを待機している状態に戻る。「アドレスを修正してリトライ」が選択されている場合には、常に、発信者に対してそれぞれのデータベースの更新を気付かせるために、発信者にもオリジナルのコピーおよび修正後の詳細の電子メールが送られる。
【００８８】
エスカレーション・イベントが受信者の集合に関して生じた場合には（失敗を示すファクシミリ・ステータス・レポートの受領、あるいは電子メールがエスカレーションを必要としていることを示すために使用される「開封」期限のタイムアウトのいずれかに起因して）、ジョブを提出した発信者に対して電子メールが送信される。それにより発信者は、ウェブ上のエスカレーション・ステータス・スクリーンへ移動し、発信者が「マニュアル仲裁」オプションを構成している場合には、マニュアルでエスカレーションを続行する。
【００８９】
Ｘ．  レポーティング・コンポーネント
レポーティング・コンポーネントは、キャリア・インターフェースから配信レポートを受領し、それらの配信レポートをまとめて、リレーショナル・データベースへストアするための１つの共通ステータス・フォーマットに結合する責任を負う。またレポーティング・コンポーネントは、統合された配信レポートを生成し、かつ閲覧する（ウェブ・ベースのＨＴＭＬインターフェースを介して閲覧するか、もしくは電子メールを介してそれらを受け取る）ために発信者によって使用されるグラフィカル・インターフェースおよびツールを包含している。
【００９０】
図７は、各種のキャリア・レポートがパーズされ、データベース内にストアされて、統合されたレポートをウェブ・サイトから発信者へ提示することを可能にする方法のプロセス７００を示したフローチャートである。ステップ７１０において、メッセージング・ジョブを提出することによってプロセスが開始する。ステップ７１２においては、受信者データ７１４のデータベース内に受信者情報がストアされる。ステップ７１６においては、ＦＴＰを経由してメッセージがキャリアへ送信される。ステップ７１８においては、ＦＴＰを経由してレポートがキャリアから受信される。ステップ７２０においては、キャリア・レポートのパーズが行われ、その受信者の送信結果がデータベース内にストアされる。送信は、ステップ７２２において終了する。ステップ７２０から、受信者のデータベース内においてステータスが更新される。
【００９１】
分離されているが関連するプロセスとして、ユーザ発信者は、ステップ７２６においてステータス・レポートを要求することができる。受信者データベース内の更新されたステータス情報が、ステップ７２６の後に続いているステップ７２８へ提供される。
【００９２】
ＸＩ．  差し込み／送信の同時性／パイプライニング
ホスト付きサービスは、差し込みおよび配信プロセスを構成するサブタスクが、可能な場合には同時に実行される方法で設計されている。この設計は、ホスト付きサービス内における高レベルのスループットを可能にし、かつホスト付きサービスがサポートする複雑なエスカレーション手順をホスト付きサービスが提供することを可能にする。図９は、各種のコンポーネント９０２、９０４、９０６の複数のインスタンス９００が同時に機能し、データのスループットを合理化する方法を示している。より詳細に述べれば、複数のマージャ・モジュール９０２の複数のインスタンスが同時に機能して複数の並行するトランスミッタ・モジュール９０４のそれぞれの１つへ出力を提供する。トランスミッタ・モジュール９０４もまた、複数のキャリア９０６のそれぞれの１つに結合されている。
【００９３】
Ｂ．  第２の実施態様
Ｉ．  概要
本発明の実施態様は、受信者の配信プレファレンスに基づいて複数の配信メディア（ファクシミリ、電子メール、ＳＭＳ、物理メール、およびアーカイブ）を介して受信者の単一集合に対して情報の大量通信を行うため、および配信が失敗した場合における受信者のプレファレンスに従った異なるメディアへのエスカレーションを統合するための方法、システム、およびコンピュータ・プログラム・プロダクト（ウェブ・サービス）を提供する。コンピュータ・ソフトウエアは、オブジェクト指向態様で開発されており、複数のサブコンポーネントから構成されている。ソフトウエアに対するユーザ・インターフェースは、好ましくはウェブ・サービスとして配信される。
【００９４】
メッセージ・ブロード・サービスは、次に示すテクニックを使用する：
（Ａ）このシステムは、カスタマとの通信に必要な共通エレメントを認識しており、それらのエレメントをＸＭＬドキュメント内にカプセル化している。これらのエレメントには、カスタマの配信プレファレンスおよびリダイレクション評価基準のセットが含まれる。配信プレファレンスおよびリダイレクション評価基準は、一意的な簡略表記を使用して指定される。ＸＭＬドキュメント・フォーマットを記述するプロプラエタリＸＭＬスキーマもまた定義されている。
（Ｂ）このシステムは、リモート・アクセス可能な、かつ安全な電子インターフェースを提供する。単一のデータ・ストリームは、一貫性のある方法ですべての形式のメッセージをサポートする。このデータ・ストリームは、インタラクティブ・ウェブ・ユーザ・インターフェースを介して、あるいはインターネットを介した非インタラクティブの大量提出によって（ＦＴＰまたはそのほかのプロトコルによって）供給することが可能である。
（Ｃ）このシステムは、データ・コンバータを指定するためのメカニズムをサポートしている。システムは、カスタム化されたデータ・コンバータの記述ならびに動的なプラグインを可能にする特殊なコードを組み込んでいる。データ・コンバータは、任意フォーマットの（すなわち、発信者のアカウンティングまたはＥＲＰシステムから抽出されたとおりの）受信者データを取り入れ、それらのデータを、メッセージング・エンジンへ供給するための共通ＸＭＬフォーマットへ変換する。
（Ｄ）このシステムは、ＰＤＦ、ＨＴＭＬ、ＴＩＦＦ、マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）、およびテキストを含む多様なドキュメント・フォーマットへの受信者データの差し込みを可能にする差し込み（パーソナル化）機能を提供する。システムは、ＸＳＬ‐ＦＯフォーマッティング・エンジンを使用してデータ差し込みを実行する。このパーソナル化機能は、電子メール・メッセージをはじめＳＭＳを経由して送信されるメッセージの件名行および本文テキストをパーソナル化する能力を含む。
（Ｅ）このシステムは、次に示すすべてのキャリア・インターフェースを管理する：すなわち、ＳＭＳ、電子メール、ファクシミリ、従来的な（物理）メール、およびアーカイビングである。これは、独立したコード・レイヤをシステム内に有し、それが残りのメッセージング・エンジンへ共通キャリア・インターフェースを与えることによって行われる。またこれは、将来的なメディア・タイプが容易にシステム内へ組み込まれることも可能にする（たとえばＷＡＰ）。
（Ｆ）このシステムは、キャリアから返される各種タイプのレポートを受け取り、それらのレポートを、リレーショナル・データベース内にストアするための共通フォーマットへ変換することによって、ユーザに対して単一の統合されたレポーティング・インターフェースを提供する。続いてこのシステムは、配信を追跡し、かつエスカレーション手続きをドライブするために、それらの配信レポートを個別のメッセージング受信者と調和させる。これによってこのシステムは、個別のメッセージの成功ならびに失敗に関するレポートをユーザへ提供すること、および個別の受信者のためにとられたリダイレクション・パスを示すことが可能になる。
（Ｇ）このシステムは、高容量のメッセージング・スループットを可能にするような方法で具体化されている。システムは、メッセージング・プロセス内のステップを異なるコンポーネントに分解することによってこれを行っている。続いてこれらのコンポーネントが同時に実行され、その結果、多くの異なるステップが同時に実行される。
・  （Ａ）配信プレファレンスは、個別の受信者をはじめ、リダイレクション規則ごとに指定することができる。たとえば受信者は、その受信者がファクシミリ経由で通信を受信することを優先するが、ファクシミリが失敗した場合には物理メールによって受け取ることを指定できる。
・  （Ｂ）受信者情報がシステムへ供給されるときに使用される１つのデータ・ストリームが存在する。この１つのストリームを介して、ファクシミリ、電子メール、ＳＭＳ、物理メール、およびアーカイビングのうちの任意のいずれかを経由して配信を行うことが可能である。
・  （Ｃ）受信者リストは任意のフォーマットとすることが可能であり、システムがそのリストをＸＭＬへ変換する。
・  （Ｄ）各種の配信メディアのすべてについて、受信者内のフィールドを使用して差し込み（パーソナル化）を行うことができる（ＳＭＳテキスト・メッセージ、電子メール本文ならびに件名テキストのパーソナル化をはじめ、ワード（Ｗｏｒｄ）、ＰＤＦ、ＨＴＭＬ、およびＭＨＴＭＬのためのドキュメント差し込みを含む）。
・  （Ｅ）このシステムは、キャリア（物理メールのメーリング・ハウスおよびホスト付きアーカイビング・サービスを含む）に対するすべてのインターフェースを管理する。発信者側においてソフトウエアをインストールもしくは管理する必要はない。
・  （Ｆ）単一の受信者リストを、各種のターゲット・メディアのすべてに対する配信のために使用することができる。
・  （Ｇ）異なるメディア・タイプにわたるすべての受信者に関する成功／失敗、および発生したエスカレーションに関するレポーティングを含めた配信結果の統合されたレポーティングが提供される。
・  （Ｈ）このシステムは、従来的な物理メールのメーリング・ハウスによって多数の受信者がターゲットされる方法と類似の態様において多数の受信者がターゲットとなる「大量メーリング」シナリオのために慎重に設計されている。
・  会社および組織は、それらのクライアントとの大量通信を、１つのシステムを使用し、１つのインターフェースを介して、かつ単一の受信者リストを用いて行うことが可能になり、しかも従来的な（物理）メール、電子メール（暗号化および非暗号化）、ファクシミリ、およびＳＭＳを含めた現在利用可能なあらゆるメディアを経由する配信をはじめ、ホスト付きドキュメント・アーカイビングおよび検索システムへのドキュメントの配信を行うことが可能になる。
・  個別の受信者レベルをはじめ、包括的なレベルにおいて配信プレファレンスおよびリダイレクション規則の指定をサポートする。
・  このシステムは、ファクシミリ、電子メール、およびＳＭＳキャリアおよび従来的な（物理）メールのメーリング・ハウスに対するインターフェースを管理する。
・  またこのシステムは、多様な入力受信者ファイル・フォーマットをサポートし、ＸＭＬフォーマットへのデータ変換を実行する。
・  このシステムは、最先端のＸＭＬドキュメント・フォーマットおよびデータ・フォーマットならびにプレゼンテーションのためのＸＳＬならびにＸＳＬ‐ＦＯのスタイルシートを使用する。
・  このシステムは、高容量のメッセージ・スループットを可能にする方法で具体化される。
・  このシステムは、ユーザが、個別の受信者のメッセージングならびにエスカレーション・ステータスを観察することを可能にする統合されたレポーティング・インターフェースを提供する。
【００９５】
このテクノロジは、一般にアプリケーション・サービス・プロバイダ・モデルとして知られているホスト付きサービス、もしくは完全なライセンス付きモデルの形式のいずれにおいても提供することが可能である。システムへアクセスするための３つの異なる方法が存在し、２つの異なるインターフェース・コンポーネントによって３つの異なるアクセス方法がサポートされている。これらの２つの外部インターフェース・コンポーネントはすべて、同一の基礎をなす共通インターフェース・コンポーネントを使用する。図２９は、システム３０００を図示したブロック図であり、バルク・インターフェース３０１０、ウェブ・インターフェース３０１２、および共通インターフェース３０２０を含んでいる。
【００９６】
Ａ．  グラフィカル・ユーザ・インターフェース（ブラウザ／ＨＴＭＬベース）３０１２
グラフィカル・ユーザ・インターフェースを経由したジョブのマニュアル提出を希望するエンティティのために、ウェブ・ブラウザ・ベースのＨＴＭＬインターフェース３０１２がシステムに備えられている。
【００９７】
Ｂ．  バルク・インターフェース３０１０
インターネットを介したジョブの大量提出がサポートされている。これによりカスタマのＥＲＰシステムは、ジョブを直接このシステムへ送ることが可能になる。ＦＴＰ（ファイル転送プロトコル）は、インターネットを介してファイルを転送するための共通プロトコルである。このサービスは、バルク・インターフェース３０１０としてＦＴＰインターフェースを提供するが、それはこのインターフェースが、エンティティにとってアクセス容易なインターフェースであると一般に理解されていることによる。このほかの、ユニバーサル・ディスクリプション・ディスカバリ・アンド・インテグレーション（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ，  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）（ＵＤＤＩ）およびウェブ・サービス・ディスクリプション・ランゲージ（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）（ＷＳＤＬ）標準によって記述されている形式的インターフェースといった提出インターフェースを使用することもできる。
【００９８】
Ｃ．  共通インターフェース３０２０
各種のインターフェース３０１０、３０１２はすべて軽量であり、図２９に示されているように、基礎をなす共通インターフェース３０２０への提出のための共通フォーマットにデータを整理する。インターフェース・パラメータは、ＸＭＬとして渡される。
【００９９】
レポーティング・コンポーネントは、キャリア・インターフェースから配信レポートを受領し、それらの配信レポートをまとめて、リレーショナル・データベースへストアするための１つの共通ステータス・フォーマットに結合する責任を負う。またこのコンポーネントは、統合された配信レポートを生成し、かつ閲覧する（ウェブ・ベースのＨＴＭＬインターフェースを介して閲覧するか、もしくは電子メールを介してそれらを受け取る）ためにユーザによって使用されるスクリーンおよびツールを包含している。図７に示されている図解は、いかにすれば各種のキャリア・レポートがパーズされ、かつデータベース内にストアされ、ウェブ・サイトが統合されたレポートをユーザへ提示することが可能になるかについて示している。
【０１００】
受信者の配信プレファレンスを基礎として、各種の異なるメディアに対するデータの差し込み（パーソナル化）および配信に単一の受信者リストが使用されることを可能にするメカニズムを提供するために、特殊なＸＭＬスキーマが定義されている。受信者リストのＸＭＬスキーマを図３０に示す。
【０１０１】
鍵となる差別化ポイントは次のとおりである：
・  メッセージ配信システムは、数百あるいは数千の受信者に対してメッセージをブロードキャストするための汎用プロダクトである。
・  データは、任意の電子フォーマットで配信システムへ提出可能であり、それには、限定の意図ではないが、非常に多くのインターフェースを介したプリントストリームが含まれる。
・  メッセージは、各受信者について詳細にわたってパーソナル化することができる。
・  強力な差し込みファシリティをサポートする洗練されたメッセージ・テンプレートの定義にＸＭＬテクノロジが使用される。
・  メッセージ配信システムは、データ・コンバータまたはジャバ（Ｊａｖａ）マッピング・クラスとして知られる強力な機能を組み込んでいる。これによりメッセージ配信システムが、任意のフォーマットの受信者情報を受け入れることが可能になる。
・  メッセージを、現在のところファクシミリ、電子メール、ペーパー、またはＳＭＳへ送信することが可能である。新しいメディア・タイプ（たとえば、ＰＤＡ）は、容易に追加することができる。「アーカイブ」の出力メディア・タイプ（差し出しメッセージをアーカイブへコピーすることを可能にする）の設計は進行中である。
・  各受信者は、異なるメディア・タイプを指定することができる。したがって、単一のメッセージ配信が、一部の受信者へはペーパーによって、別の受信者へは電子メールによって、さらに別の受信者へはファクシミリによって送られるといったことが可能になる。
・  「リダイレクション」機能が提供される。受信者が最初に選択したメディアへメッセージを配信することが不可能であった場合には、このメッセージ配信システムが、指定された第２の選択肢へ、さらには第３の選択肢へ向けてリトライする。したがって、たとえば、特定の受信者のためのファクシミリへの送信が失敗した場合にこのメッセージ配信システムは、電子メール、ペーパー、あるいはそのほか類似のものによる送信を自動的に試みる。リダイレクション規則は、各受信者用に個別に、あるいは全ジョブについて包括的に、必要に応じて指定される。
【０１０２】
本発明の第２の実施態様においては、図１１に示されているとおり、電子メッセージ・ブロードキャスト・システム１１００が開示されている。このメッセージ配信システム１１００は、「１対多」状態を扱うべく特別に設計されており、それにおいては、単一のメッセージ１１１０がメッセージ配信システム１１００によって（より詳細にはシステム・エンジン１１２０によって）受け取られ、多数の、数百数千の宛先１１３０へブロードキャストされる。このメッセージ配信システムは、各受信者について個別にメッセージの「調整」が行われるようにするためのファシリティを提供する。メッセージは、インターネットを経由して、あるいは専用通信リンクによって受信ならびに送信が行われる。
【０１０３】
メッセージは、テキスト、グラフィックス、埋め込みオーディオ／ビデオを有することが可能であり、実質的に電子的に表現可能なあらゆるものを有することができる。
【０１０４】
このメッセージ配信システムは、メモならびにマーケティング資料からインボイスおよび明細書までにわたる広範な情報のブロードキャストに使用することができる。
【０１０５】
図１２は、図１１のシステム・エンジン１１２０の全体的なアーキテクチャをより詳細に示したブロック図である。インターネット・インターフェース１２１０がアプリケーション・サーバ１２２０に結合されており、それもまたデータベース・サーバ１２４０に結合されている。アプリケーション１２２０は、たとえばマイクロソフト・ウインドウズ（Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ）２０００オペレーティング・システムを使用するＰＣハードウエア１２３２を使用して具体化することができる。
【０１０６】
アプリケーション・サーバ１２２０は、ジャバ（Ｊａｖａ）仮想マシン１２２８、ＪＤＢＣ  １２３０、アパッシュ・トムキャット（Ａｐａｃｈｅ  Ｔｏｍｃａｔ）ウェブ・サーバ１２２４、およびジェイボス（ＪＢｏｓｓ）アプリケーション・サーバ１２２６を包含している。またアプリケーション・サーバ１２２０は、ジャバ（Ｊａｖａ）プログラムならびにユーティリティを含むアプリケーション・ソフトウエア１２２２も包含している。
【０１０７】
データベース・サーバ１２４０は、オペレーティング・システム・レベル（たとえばマイクロソフト・ウインドウズ（Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ）２０００）のＰＣハードウエア１２４６、ＪＤａｔａＣｏｎｎｅｃｔ（ジェイデータコネクト）１２４４、およびＳＱＬサーバ１２４２を包含している。
【０１０８】
このシステムは、好ましくは安全なデータ・センタに配置されたコンピュータ上において動作する。別の場所のデータ・センタに、ほかのメッセージ配信システムがインストールされることは意図されている。システム・ソフトウエア１２２０は、好ましくはジャバ（Ｊａｖａ）プログラミング言語により記述され、多数の第三者製ユーティリティ・パッケージを含むことができる（その多くもまた、ジャバ（Ｊａｖａ）プラットフォーム用に設計されている）。メッセージ配信システムは、データを表現するためにＸＭＬ標準を使用する。
【０１０９】
このメッセージ配信システムは、広範なプラットフォーム上において動作することが可能であり、たとえばこのシステムは、マイクロソフト・ウインドウズ（Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ）２０００オペレーティング・システムを使用するＰＣの「アプリケーション・サーバ」１２３２、１２４６上において動作することができる。ジャバ（Ｊａｖａ）プログラミング環境は、アパッシュ・トムキャット（Ａｐａｃｈｅ  Ｔｏｍｃａｔ）ウェブ・サーバ１２２４およびジェイボス（ＪＢｏｓｓ）アプリケーション・サーバ１２２４によって提供される。
【０１１０】
すべての持続性データは、ジャバ（Ｊａｖａ）ＪＤＢＣインターフェース１２３０を経由してアクセスされる別のＰＣの「データベース・サーバ」１２４０内のメッセージ配信システム・データベース内において維持される。データベース・ソフトウエアは、ＪＤａｔａＣｏｎｎｅｃｔ（ジェイデータコネクト）ソフトウエア１２４４を使用してメッセージ配信システム・サーバとのリンクを取り扱うマイクロソフト（Ｍｉｃｒｏｓｏｆｔ）のＳＱＬサーバ１２４２とすることができる。
【０１１１】
Ｉ．  コンセプト
このメッセージ配信システムは、好ましくは、大量メッセージ市場用に特別に開発されるソフトウエア・スイートとして具体化される。このシステムは、メッセージ配信システム・エンジンとして知られるメッセージング・コンピュータをコントロールする。
【０１１２】
このメッセージ配信システムは、センダからのメッセージ（すなわち、テキスト、グラフィクス、サウンド／ビデオ・ファイル等の電子表現）を受け入れ、そのメッセージのコピーを多数の（数十、数百、あるいは数万の）受信者へ配信する。通常センダは、何らかの種類の組織であり、受信者は個人もしくはほかの組織である。センダがカスタマとなることもあり、カスタマＩＤによって識別されることがある。用語「センダ」および「カスタマ」は、本書において、文脈に応じて相互交換可能に使用される。メッセージの内容は、それぞれの受信者用に調整できるが、メッセージの全体的なフォーマットは、通常、すべての受信者に対して類似である。例として述べるが、センダが銀行であり、メッセージが月々の残高明細書であると考える。メッセージの全体的なフォーマット（すなわち、銀行の名前、銀行のロゴ、列タイトル等）はすべての受信者について同一であるが、詳細（すなわち、受信者の名前およびアドレス、口座の残高、および個別の貸し方／借り方取引）はそれぞれの受信者について異なる。
【０１１３】
センダからメッセージを受け入れ、複数のコピーを受信者へ配信する全体のプロセスをジョブと呼ぶ。ジョブが完了すると、メッセージ配信システムは、センダのためにジョブ・ステータス・レポートを自動的に準備する。このレポートは、ジョブの結果（すなわち、配信が成功した受信者メッセージの数および失敗した数）を要約し、成功／失敗の詳細を個別の受信者ベースで提供する（たとえば、特定の受信者に対して配信の行われた回数および失敗した理由）。
【０１１４】
このメッセージ配信システムは、各受信者のメッセージ・トランザクションの結果に関するより詳細な情報を含む請求書発行レコードのセットも用意する。この請求書発行レコードは、請求書発行システムへ渡され、そこでは、月末に、カスタマのインボイス作成のためにこの請求書発行レコードが使用される。
【０１１５】
各カスタマへは、１ないしは複数のメッセージ配信システムのアカウント（それぞれはアカウントＩＤによって識別される）が割り付けられる。各ジョブは、１つのアカウントに関連付けされなければならない。アカウントは、ジョブの特定の動作上の特性（ファクシミリ・ページの最大サイズ、必要なプリントの質、使用可能なメッセージ配信システムの機能等）を定義しており、請求書発行プロセスにおいて使用されて、そのジョブについてカスタマにどれだけ課金するかについて決定される。カスタマは、通常、適切に構成されたアカウントのグループを、そのカスタマの企業内の組織上の単位（コスト・センタ、部門、そのほか類似のもの）に割り当てることができる。
【０１１６】
センダは、一般に、オンラインウェブ・インターフェースを用いてメッセージ配信システムとのインタラクション（すなわち、ジョブの提出、ジョブ・ステータス・レポートの検索等）を行う。カスタマは、そのカスタマの組織内の特定の個人を指定してこれを行わせる；これらの個人は、ユーザとして知られる（かつ、そのカスタマ内において一意的なユーザＩＤによって識別される）。ユーザは、インターネット・エクスプローラ（Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ）あるいはネットスケープ（Ｎｅｔｓｃａｐｅ）等のウェブ・ブラウザによってウェブ・インターフェースへアクセスする。
【０１１７】
場合によっては、ウェブ・インターフェースに対する代替手段として、ユーザがＦＴＰファイル転送を使用し、インターネットを介してメッセージ配信システムへジョブを提出することも可能である。このオプションについては、後に考察する。
【０１１８】
受信者は、多数の異なるメディアを介し、各種のキャリアによって配信される自分宛のメッセージを受信することができる。これらのメディアには、次のものが含まれる：
・  電子メール：メッセージ配信システムは、電子メールとしてメッセージを受信者の電子メール・アドレスへ配信するキャリアへ電子的にメッセージを渡すが、それにおいてメッセージは、電子メールの本文内に埋め込まれるか、かつ／または添付となる。
・  ペーパー：メッセージ配信システムは、メッセージをプリントし、プリント後のメッセージを封筒に収め、郵便システムを介してそのメッセージを受信者へ郵送するキャリアへ電子的にメッセージを渡す。
・  ＳＭＳ：メッセージ配信システムは、メッセージをテキストとして受信者の携帯電話へ配信するキャリアへ電子的にメッセージを渡す。
・  ファクシミリ：メッセージ配信システムは、メッセージを受信者のファクシミリ装置へ転送するキャリアへ電子的にメッセージを渡す。
【０１１９】
ここでこのほかのメディアが将来において導入されることが予測される。このシステム・アーキテクチャは、最小限の開発努力を伴って新しいメディアの導入をサポートするべく設計されている。差し出しメッセージがアーカイブ・ファイルへ渡されることを可能にする「アーカイブ」メディアを具体化することもできる。
【０１２０】
上にリストしたすべてのメディアは、一意的にアドレス可能である。このアドレスは、宛先ＩＤと呼ばれる。
【０１２１】
宛先ＩＤのフォーマットは、それぞれのメディア・タイプごとに異なる。ファクシミリ装置および携帯電話については宛先ＩＤが電話番号となり、ペーパーについては宛先ＩＤが郵便の住所となり、電子メールについては宛先ＩＤが電子メール・アドレスになる。したがって、特定の受信者が、たとえば次に示すような宛先ＩＤを有することがある。
・  ファクシミリ宛先ＩＤ：＋６１  ２  １２３４  ５６７８
・  ＳＭＳ宛先ＩＤ：＋６１  ４３８  ９８７６５４
・  ペーパー宛先ＩＤ：Ｍｒ  Ｐ  Ｊｏｎｅｓ，  ２４  Ｗａｒａｔａｈ  Ｓｔ，  Ｓｔ  Ｌｅｏｎａｒｄｓ  ＮＳＷ，  ２０６５
・  電子メール宛先ＩＤ：ｐｊｏｎｅｓ＠ｂｉｇｐｏｎｄ．ｃｏｍ．ａｕ
【０１２２】
１つのメディア・タイプについて１つの宛先ＩＤが使用される。宛先は、「受信者ごと」のベースで指定される；任意の個々のジョブにおいて、各受信者は、異なるメディアならびに異なる宛先を指定することができる。
【０１２３】
ジョブを開始するためには、ユーザが、テンプレート・ファイルならびに受信者ファイルをメッセージ配信システムへ提出する。１つのジョブは、１ないしは複数のテンプレート・ファイルを要求することができる。１つのテンプレート・ファイルは、単一のテンプレートだけを含む。１つのジョブは、各配信メディアについて１ないしは複数のテンプレートを必要とする。たとえば、ＳＭＳならびに電子メールを扱うジョブが、そのＳＭＳメッセージ用に１つのテンプレートを、電子メール・メッセージ用に５つのテンプレート（電子メールの件名用に１つ、電子メール本文のテキスト・バージョン用に１つ、電子メール本文のＨＴＭＬバージョン用に１つ、および２つの電子メール添付書類用にそれぞれ１つ）を要求するといったこともあり得る。
【０１２４】
テンプレートは、アドビ・アクロバットＰＤＦ（Ａｄｏｂｅ  Ａｃｒｏｂａｔ  ＰＤＦ）（ＰＤＦ）フォーマット、ＴＩＦＦイメージ（ＴＩＦＦ）フォーマット、ポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）（ＰＲＮ）フォーマット、ＸＭＬスタイルシート（ＸＳＬ）フォーマット、マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）（ＤＯＣ）フォーマット、およびシンプル・テキスト（ＴＸＴ）フォーマットを含む多数の異なるフォーマットで供給される。
【０１２５】
各テンプレートは、メッセージの不変部分（すなわち、すべての受信者についてまったく同じになる部分）を記述する。
【０１２６】
特定タイプのテンプレート（すなわち、ＤＯＣ、ＸＳＬ、およびＴＸＴのみ）は、「パーソナル化可能」である（すなわち、これらは、オプションとして１ないしは複数の「差し込みフィールド」を含むことができる）。またＸＳＬテンプレートは、「テンプレート・アーティファクト・ファイル」が随伴することがある。
・  差し込みフィールドは、テンプレート内においては「プレース・ホルダ」と呼ばれる。各差し込みフィールドは、メッセージ配信システムが特定の受信者用にメッセージを作成するときに受信者固有のデータが挿入されることになる場所、すなわちプレースを示す。したがって、たとえばあるテンプレートが「ｃｕｓｔ＿ｎａｍｅ」（カスト＿ネーム）、「ａｃｃｏｕｎｔ＿ｂａｌａｎｃｅ」（アカウント＿バランス）、および「ｄａｔｅ」（デート）と呼ばれる差し込みフィールドを含むことができ、それらを図１３に示されているようにテンプレート１３００内に出現させることができる。
・  例示を目的として、図１３の例は、「シェブロン」文字によって区切られる差し込みフィールドを示している。実際にこのように、ＤＯＣならびにＴＸＴのテンプレート内（ＸＳＬテンプレート内は異なる）において現れる。
・  テンプレート・アーティファクト・ファイルがＸＳＬテンプレート・ファイルに随伴することがある。これらは、グラフィクス、サウンド、ビデオ・クリップ、またはそのほかのマルチメディア・ファイルである。たとえば、銀行残高明細書メッセージがロゴを含んでいる場合にはテンプレート・ファイルに、適切なグラフィクスを含むイメージ・ファイル（おそらくは「ＢａｎｋＬｏｇｏ．ｊｐｇ」（バンクロゴ．ｊｐｇ）といった名前が付けられる）が随伴することができる。
【０１２７】
１つのジョブは、１ないしは複数の受信者ファイルを必要とする。受信者ファイルが受け取られると、メッセージ配信システムは、それらすべての受信者ファイルを単一ファイルへ連結し、もしくはそのほかの結合を行う。このファイルの内容は、受信者リストとして知られている。
【０１２８】
受信者リストは、多くの受信者レコード（通常、数百または数千）を包含している。各受信者レコードは、そのメッセージの、意図された１人の受信者を記述するテキストを含むことができる。受信者レコードは、次に示す情報を含むことができる。
・  受信者情報：レコードは、受信者に関する何らかの基本的な情報、たとえば受信者の名前および参照コードを含む。
・  宛先ＩＤ：それぞれのメディアについて、１つの宛先ＩＤが存在し、それによりメッセージをその受信者へ配信することができる。したがって、たとえば、ある受信者が電子メールもしくはファクシミリのみによってメッセージを受信できる場合に、その受信者レコードは、電子メール・アドレスおよびファクシミリ電話番号のみを含む；「ペーパー」ならびに「ＳＭＳ」用の宛先ＩＤはヌルになる（郵便またはＳＭＳによってその受信者と接触できないことを示す）。宛先ＩＤが指定されるということは、必ずしもそのＩＤが使用されることを意味しない。特定のメッセージの配信に使用されることになる宛先ＩＤは、「宛先プレファレンス情報」に指定される。
・  差し込み値：受信者レコードは、テンプレート・ファイル内の「差し込みフィールド」に対応する「差し込み値」を含んでいる。差し込み値は、この受信者のためのメッセージをメッセージ配信システムが生成するときに、メッセージ配信システムによって差し込みフィールド内に配置される。たとえば、あるテンプレートが「《ａｃｃｏｕｎｔ＿ｂａｌａｎｃｅ》」（アカウント＿バランス）と呼ばれる差し込みフィールドを含み、特定の受信者レコードが差し込み値「＄４５１．３４」を含むとする。その受信者へこのメッセージが配信されるときには、テキスト「＄４５１．３４」が、差し込みフィールド名に代わってメッセージ内に現れる。
・  宛先プレファレンス情報：宛先プレファレンス情報は、そのメッセージを送信する宛先をメッセージ配信システムへ知らせる。
・  各受信者について、宛先プレファレンス情報の一部として、指定の数（たとえば３）以下の配信の試行を指定することができる。各試行は、指定の数（たとえば３）を上限として異なる宛先ＩＤに対する送信を指定することができる；それらの最初がマスタ送信となり、残りがコピー送信となる。
・  メッセージ配信システムは、最初の試行を伴って開始する。システムは、マスタおよびコピー送信を同時に送信する。マスタ送信が受信者までの到達に失敗した場合には、メッセージ配信システムが次の試行を試みる。このようにしてプロセスは、マスタ送信が首尾よく完了するか、すべての試行が網羅されるまで継続される。
・  マスタ送信の配信をこのような形で複数にわたって試みることは、リダイレクションとして知られている。メッセージ配信システムは、「コピー」送信の失敗を決定的と見なさず、それが結果としてリダイレクションをもたらすことはない。
・  以上は、図１４の例によって例示される。受信者レコード１４００は、図１４に示される試行ならびに送信を指定している。メッセージ配信システムは、最初にマスタ送信をファクシミリへ渡し、同時にコピーを電子メールへ渡す。マスタ送信（つまりファクシミリ）が成功すれば、この受信者の処理が完了する。
・  マスタ送信が成功しなかった場合（たとえば、そのファクシミリ番号が話中であるか獲得できない場合）には、メッセージ配信システムが、試行番号２を開始する（つまり、システムは、マスタ送信をペーパーへ渡し、コピーをＳＭＳへ渡す）。第３の試行が指定されていないことから、これがこのメッセージ配信システムの処理のエンドになる。
【０１２９】
ＩＩ．  ウェブ・インターフェース
ユーザとメッセージ配信システムの間におけるインタラクションは、ウェブ・ブラウザ・インターフェースを使用して行うことができる。メッセージ配信システムとのインタラクションを開始するために、ユーザは、単純にウェブ・ブラウザ（たとえば、マイクロソフト・インターネット・エクスプローラ（Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ）あるいはネットスケープ・ナビゲータ（Ｎｅｔｓｃａｐｅ  Ｎａｖｉｇａｔｏｒ））を起動し、適切なＵＲＬを入力する。
【０１３０】
ＵＲＬの入力は、ユーザとメッセージ配信システム・エンジンの間における論理的なリンクを設定し、図１６に示されている「ログオン・スクリーン」１６００が表示される。
【０１３１】
以下の説明は、メッセージ配信システムによって表示されるスクリーンおよびそれらがどのように使用されるかについて示している。
【０１３２】
カスタマ、ユーザ、およびアカウント
ウェブ・インターフェースによって「ユーザ」（「カスタマ」を代表し、メッセージ配信システムの「アカウント」の下にオペレーションを行う）は、メッセージ配信システムへジョブを提出し、そのほかのオペレーションを行うことが可能になる。
【０１３３】
システム・オペレータの組織内には、メッセージ配信システムのオペレーション上のコントロールのため、およびメッセージ配信システムのカスタマをサポートするための責任を有するスタッフのグループが存在し得る。それらを、ここではメッセージ配信システム・サポート・チームと呼ぶ。サポート・チームは、システムに関する全体的な管理責任を有し、特に新しいカスタマによるこのシステムの使用をセットアップするジョブを有する。
【０１３４】
メッセージ配信システム・サポート・チームのメンバは、新しいカスタマをシステムへ導くとき、メッセージ配信システムのデータベース内に次の項目を作成する：
・  そのカスタマについての情報を含む単一の「ＣＵＳＴＯＭＥＲ」（カスタマ）レコード、
・  このカスタマが使用することのできるアカウントについての情報をそれぞれが含む、いくつかの「ＡＣＣＯＵＮＴ」（アカウント）レコード、および
・  管理者ユーザ（すなわち、特別な権利を伴うユーザ）を記述する１ないしは複数の「ＵＳＥＲ」（ユーザ）レコード。
・  カスタマの管理者ユーザに、標準ユーザの管理がこのカスタマの直接コントロール下となるように、このカスタマに関する１ないしは複数の標準ユーザ（すなわち、管理者特権のないユーザ）の作成を許可することができる。しかしながら、管理者ユーザは、メッセージ配信システム・サポート・チームによってのみ作成することができる。
【０１３５】
メッセージ配信システムは、個々のカスタマに関連する情報を維持する。この情報には、そのカスタマのアカウント情報、ユーザ情報、およびそのカスタマのユーザによって提出される各種のジョブに関する情報を含めることができる。この情報は、アクセス・コントロールの観点から「閉じられたグループ」を包含し、通常はそれを形成する。カスタマのユーザは、そのカスタマに関連するアカウント、ユーザ、およびジョブについての情報に対してのみアクセスすることができる。それらのユーザは、ほかのカスタマについての情報にアクセスすることはできない。これは、メッセージ配信システムのセキュリティ要件である。
【０１３６】
これに対する例外が１つ存在し得る。メッセージ配信システム・サポート・チームを、「コントロール」のカスタマＩＤを伴う「特別カスタマ」としてメッセージ配信システム内に登録することができる。この特別カスタマに属するユーザ（「コントロール・ユーザ」）は、メッセージ配信システム・サポート・チームによって実行されるスーパーバイザの役目に値する特別な力を有することができる。より詳細に述べれば、コントロール・ユーザについてだけ：
・  管理者ユーザは、任意のカスタマに関するカスタマ、ユーザ、およびアカウント情報へのアクセスならびに変更を行う権限、および任意のカスタマのためのジョブを提出する権限を有し、かつ
・  標準ユーザは、任意のカスタマに関するカスタマ、ユーザ、およびアカウント情報を閲覧する権限（ただし変更はできない）、および任意のカスタマのためのジョブを提出し、電子メール・エラーをレポートする権限を有する。
【０１３７】
コントロール・ユーザは、任意の指名されたカスタマのユーザを「装って」、それによってコントロール・ユーザがそのカスタマであるかのようにシステムにアクセスすることができる。このようにカスタマがコントロール・ユーザによって「装われている」とき、それをプロキシ・カスタマと呼ぶ。
【０１３８】
各種タイプのユーザに実行が許可されるウェブ・インターフェース機能を支配する規則を、図１５の表１５００にまとめた。次に、図１５に示されている機能について説明する。
【０１３９】
図１５の補注『１』を伴って示されている機能は、カスタマ固有である。これらは、指名されたプロキシ・カスタマのために実行される（すなわち、コントロール・カスタマが最初に特定のプロキシ・カスタマを指名し、その後その機能を実行する）。そのほかのコントロール・カスタマ機能は、最初にプロキシ・カスタマを指名する必要がない。図１５の補注『２』については、ユーザに、そのユーザ独自のＵＳＥＲ（ユーザ）レコード上の特定のフィールドの変更を許すことができるが、ほかのユーザのＵＳＥＲ（ユーザ）レコード上の変更は許されない。
【０１４０】
ログオン
使用することのできるログオン・スクリーン１６００を図１６に示す。ユーザは、このログオン・スクリーン１６００上においてカスタマＩＤ、ユーザＩＤ、およびパスワードの入力が必要になることがある。
【０１４１】
スクリーン・レイアウト
ユーザがログオンに成功すると、図１７のメイン・スクリーン１７００が現れ、ユーザがこのスクリーンを「キャンセル」するまで表示される。このメイン・スクリーンは、メイン・メニューが左側に並び、場合によっては一連のタブが上側を横断する形式をとる。図１７は、そのスキームを示している。
【０１４２】
左側はメイン・メニュー（「メイン・メニュー１」、「メイン・メニュー２」等）によって占められている。現在選択されているメイン・メニュー・オプションは、そのオプションを黒枠によって囲むことによって強調表示することができる（図１７においては「メイン・メニュー２」）。
【０１４３】
スクリーンの上側は、カスタマ名（ブラケットによって囲まれたカスタマＩＤが続く）およびユーザ名（ブラケットによって囲まれたユーザＩＤが続く）を含むことができる。ユーザ名ならびにＩＤは、現在ログオンしているユーザを識別する。カスタマ名ならびにＩＤは、このユーザを「所有している」カスタマ、もしくはそのカスタマが「コントロール」であれば、プロキシ・カスタマを示す。プロキシ・カスタマおよび管理者ユーザを斜体字で表示することもできる。
【０１４４】
このスクリーンの残りの部分は、現在選択されているメイン・メニュー・アイテムに対応するパネルまたはパネル・グループを構成する（すなわち、１ないしは複数のパネルが、互いの上へ概念的に積み重ねられている）。パネル・グループの場合には、スクリーン最前面のタブがそのグループ内の個別のパネルの表示に使用される（すなわち、スタックのトップに配置される）。各パネルは、記述テキスト、データ入力フィールド、ドロップ‐ダウン・リスト、ラジオ・ボタン、チェックボックス、およびそのほかのアーティファクトを構成する情報を包含している。パネルの提出もしくはキャンセル、またはヘルプ情報を呼び出すボタンを下側に配置することができる。
【０１４５】
管理
管理パネル・グループは、カスタマのＵＳＥＲ（ユーザ）レコードならびにＡＣＣＯＵＮＴ（アカウント）レコードの閲覧、および場合によっては変更を可能にする。
【０１４６】
ユーザを閲覧するためのパネルの一例を図１８に示す。このパネルにはいくつかの別形が、通常はユーザ用に１つ、カスタマの（またはコントロール）管理者ユーザ用に１つ、およびこのＵＳＥＲ（ユーザ）レコードによって表される特定ユーザ用に１つ存在することができる。図１８は、管理者ユーザによって閲覧されることになるパネル１８００を示している。
【０１４７】
コントロール管理者ユーザおよびカスタマの管理者ユーザは、このパネルの任意のフィールドに情報を入力することができる。ほとんどの標準ユーザの場合には、すべてのフィールドが「閲覧のみ」となる。このレコードが適用される標準ユーザについては、「パスワード」、「連絡先」、および「テスト用宛先」フィールドを除くすべてのフィールドが「閲覧のみ」となる。
【０１４８】
ほとんどのフィールドは、データベース上のＵＳＥＲ（ユーザ）レコード内のフィールドと「１対１」の対応を有している。「このユーザがジョブを提出できるアカウント」のリスト内のチェックが付されたアイテムは、このユーザの「ＵＳＥＲ＿ＡＣＣＯＵＮＴ＿ＸＲＥＦ」（ユーザ＿アカウント＿ＸＲＥＦ）レコードを反映している。
【０１４９】
メッセージ配信システムへのジョブの提出
ユーザは、２つのインターフェースのうちの１つを使用してメッセージ配信システムへジョブを提出することができる。
【０１５０】
・  エンタープライズ・インターフェース
エンタープライズ・インターフェースは、通常、カスタマおよびサプライヤの追跡ならびに管理のための高性能コンピュータ・システムを所有する大企業によって使用される。エンタープライズ・インターフェースは、インボイスならびに明細書といった「最重要メール」に指向されている。
・  そのような場合においては、メッセージ・フォーマットが複雑になり（ロゴおよびそのほかのグラフィクスを組み込んでいる）、頻繁に変更されることはない。これは、適切なテンプレートの開発は、時間を要するタスクになるが、いったん完成すれば頻繁にそれを反復する必要がないことを意味する。
・  エンタープライズ・インターフェース・カスタマ用のテンプレートは、メッセージ配信システム・サポート・チームにより、カスタマの仕様に対して開発することができる。完成したテンプレートは、その後、会社のコントロール下にあるメッセージ配信システムのデータベース内にストアすることができる。カスタマがジョブを実行するごとに、システムはこのテンプレート（適切なジョブ・タイプを引用することによって）参照するが、テンプレート自体は変更されず、実際のところカスタマによる修正は不可能である。
・  エンタープライズ・インターフェースを使用するカスタマは、連絡先の詳細、およびそれらのカスタマのサプライヤ、カスタマ、スタッフ、アソシエーツ等に関するそのほかの情報を含むデータベースを（カスタマ独自のコンピュータ上に）有することができる。したがって、カスタマがこのメッセージ配信システムを介して多様な受信者へのメッセージの送信を希望するとき、カスタマは、カスタマ独自のデータベースに対して「データベース抽出」プログラムを実行し、受信者ファイルを生成することができる。
・  エンタープライズ・インターフェースのテンプレートは、ＸＭＬスタイルシート（ＸＳＬ）フォーマットでストアすることができる。差し込みフィールドを含まない電子メール添付書類の場合は、この例外となることがある。それらは、アドビ・アクロバットＰＤＦ（Ａｄｏｂｅ  Ａｃｒｏｂａｔ  ＰＤＦ）フォーマットで指定することができる。
・  受信者ファイル・フォーマットは、広範多様となるが、メッセージ配信システムが、受信時に、すべてのファイル・フォーマットをＸＭＬフォーマットへ変換する。
・  エンタープライズ・インターフェースを使用する応用の一例として、月ごとの銀行残高明細書のジョブを考える。明細書の全体的なフォーマット（すなわち、表題、ロゴ、ボイラ板テキスト等）は、仮にあったとしても定期的に変更されることはない。このフォーマットは、メッセージ配信システム・サポート・チームにより、銀行の仕様に対して開発されたＸＳＬテンプレート・ファイルのセットによって記述することができる。しかしながら、明細書の詳細（カスタマ名、アドレス、取引の詳細、口座残高等）は、カスタマごと、および月ごとに異なる。通常、明細書の詳細は、プログラムによって銀行のメインフレーム・データベースから毎月抽出され、その後、受信者ファイルとしてメッセージ配信システムへ転送される。
【０１５１】
・  標準インターフェース
標準インターフェースは、より小規模の、より複雑でないジョブのために使用することができる。
・  標準インターフェースのユーザは、そのユーザがジョブを開始するときには常に、そのユーザ独自のテンプレート・ファイルの準備およびそのテンプレート・ファイルの供給の責任を負うことがある。これは、テンプレートが比較的単純になる状況において実際的となり得る（たとえば、単純なワード・プロセッサを使用して準備可能なメモ、プレス・リリース、およびマーケティング・キャンペーン）。この種の状況においては、それぞれのメッセージ配信システムのジョブについて新しいテンプレート・ファイルが準備されることが一般的となる。
・  いくつかの場合においては（すなわち、単純なテキスト情報が必要とされる場合）、ユーザは、標準インターフェースを介してオンラインでそのユーザのテンプレート・ファイルへ入力することが可能になる。そのほかの場合においては、ユーザは、オフラインでテンプレート・ファイルを（たとえば、マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）「ＤＯＣ」フォーマットで）準備することができる。
・  受信者ファイルには、「コンマ・セパレーテッド・バリュー（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅ）」（ＣＳＶ）フォーマットを用いることができるが、メッセージ配信システムは、その受信時にＸＭＬフォーマットへ変換することができる。
【０１５２】
標準インターフェースは、単純なメモもしくはマーケティング資料を迅速に作成し、それらのメッセージを自分のカスタマへブロードキャストすることを希望するカスタマによく適している。エンタープライズ・インターフェースは、フォーマットが長期間にわたって持ちこたえるが、その間、反復して使用される明細書およびインボイスといった安定した応用に適している。
【０１５３】
次の表３および４は、技術的な意味においてこれら２つのインターフェースの間の相違をまとめたものである。
【０１５４】
【表３】
2005535013.tif 000009
【０１５５】
【表４】
2005535013.tif 000010
【０１５６】
キャリアへ渡されるメッセージの対応フォーマットは、多様なものとなり得る：
・  各ペーパー・メッセージは、ポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）ファイルとしてキャリアへ渡すことができる。
・  各ファクシミリ・メッセージは、１ないしは複数のＴＩＦＦファイルとして（特別なヘッダに含められたプレーン・テキスト・フォーマットの「件名」情報とともに）キャリアへ渡すことができる。
・  各電子メール・メッセージは複合フォーマットでキャリアへ渡すことができ、それにおいては：
‐  件名行を、特別なコントロール・ファイル内にプレーン・テキスト形式でエンコードすることができる。
‐  ＨＴＭＬおよびテキスト本文を、それぞれＨＴＭＬファイルおよびプレーン・テキスト・ファイルとしてエンコードすることができる。
‐  エンタープライズ・インターフェース添付書類を、ＰＤＦファイルとして渡すことができる。
‐  標準インターフェース添付書類を、オリジナルの受信時と同一のフォーマットで渡すことができる。
・  上記の規則の１つの例外として、ＤＯＣフォーマットの任意の標準インターフェース添付書類が、ＰＤＦフォーマットでキャリアへ渡されることが挙げられる。
・  標準インターフェースによって扱われるＨＴＭＬファイルは、好ましくは完全に組み込み済みとする（ファイルが、イメージ・ファイル等の外部アーティファクトに対する参照を含まない）。
・  各ＳＭＳメッセージは、テキスト・フォーマットで携帯電話へ渡される。
【０１５７】
ユーザは、最初にアカウントを、すなわちそれの下にこのジョブが実行されるアカウントを選択する。「ドロップ‐ダウン」リストは、そのカスタマ（もしくはプロキシ・カスタマ）のアカウントのうち、そのユーザに使用権限のあるすべてのアカウントの名前をリストすることができる。ユーザが「提出」をクリックすると、新しいパネルが現れ、エンタープライズもしくは標準インターフェースが（選択したアカウントに指定されているとおりに）反映される。
【０１５８】
エンタープライズ・インターフェース
図１９は、エンタープライズ・インターフェースのジョブ提出スクリーン１９００のレイアウトを示している。
・  ジョブ表示名
‐  ジョブ表示名フィールドは、オプションとすることができる。ユーザは、そのユーザにとって意味を持ったジョブの名前を入力することができる。この名前は、このジョブに関係するすべてのレポートに表示される。
・  ジョブ・タイプ
‐  このフィールドは、ジョブ・タイプのリストをユーザに提供し、そのそれぞれは、そのユーザに意味をなす名前によって識別されている。ユーザは、このリストから１つのアイテムを選択しなければならない。
‐  ジョブ・タイプは、ジョブ・コンフィグレーションとしてメッセージ配信システムのデータベース内に表現されている。各ジョブ・コンフィグレーションは、ジョブ‐レベル情報および、メッセージ配信システム・サポート・チームによってあらかじめ用意され、テストされ、かつそのデータベース内にストアされているテンプレート・ファイルならびにテンプレート・アーティファクトの集合を構成する。
・  受信者ファイル
‐  当初、ユーザには、１つのテキスト入力フィールド（関連する「ブラウズ」および「アップロード」ボタンを伴う）を提供することができる。
‐  受信者ファイルを指定するために、ユーザは「ブラウズ」ボタンをクリックしてブラウズ・ウインドウを表示させる。ユーザが要求するファイルを選択すると、そのファイルパスがこのテキスト入力フィールド内に現れる。ユーザが「アップロード」ボタンをクリックすると、そのファイルがメッセージ配信システムへアップロードされ、「アップロード済みファイル」リスト内に表示される。ユーザは、この方法に従って、希望する数のファイルをアップロードすることができる。
‐  「アップロード済みファイル」リストに隣接する「削除」ボタンを使用して、選択したアップロード済みファイルを削除することができる。
‐  メッセージ配信システムのエンタープライズ・インターフェースは、広範多様なフォーマットの受信者ファイルを受け入れる。受信者は、ＸＭＬフォーマットへ変換され、この形式の変換済みの形式のデータベース内に保持される。
・  ジョブ開始時刻
ユーザには、直ちにジョブを処理するオプション、またはその後の日時にジョブを開始するべくスケジュールするオプションを提供することができる。「日付」フィールドは、その後の３０日までの選択を提供する。「時刻」フィールドでは、ユーザが時分を用いて開始時刻を指定することができる。
【０１５９】
ユーザは、「提出」を選択してジョブを提出する。ジョブが提出された後、メッセージ配信システムは、そのデータベース内から、テンプレート、テンプレート・アーティファクト、およびそのほかの、指定されたジョブ・タイプに対応するジョブ情報を探し出す。続いてシステムは、必要に応じて受信者ファイルの妥当性検査を行う。この妥当性検査プロセスの間にエラーに遭遇した場合には、メッセージ配信システムが、エラーを生じた受信者の詳細を表示する。その後ユーザは、エラーを訂正し、ジョブを再提出する。
【０１６０】
ジョブ・ステータス・レポートの閲覧
ユーザは、ジョブの提出後において随時ジョブ・ステータス・レポートを要求することができる。メッセージ配信システムは、そのデータベースの情報からジョブの現在のステータスを獲得し、適切なジョブ・ステータス・レポートをスクリーン上に表示する（ユーザは、希望する場合にそれをプリントすることができる）。
【０１６１】
図２０の例は、エンタープライズ・インターフェースを使用して提出されたインボイス配信ジョブに関する完全なジョブ・ステータス・レポート２０００（すなわち、４つのオプションをすべて含んでいる）を示している。レポート２０００は、「プリンタで扱いやすい」フォーマット（白黒）により表示されるように、また新しいブラウザ・ウインドウ内に表示されるようにすることができる。この例において、メッセージ配信システムのジョブＩＤは「３４６５６」であり、ユーザによって割り当てられたジョブ表示名は「Ｉｎｖｏｉｃｅ３」（インボイス３）である。
【０１６２】
このジョブは、アカウント「Ｅｓｓｅｎｔｉａｌ  Ｍａｉｌ」（エッセンシャル・メール）の下に２２時２１分に提出され、その４時間３１分後（翌午前２：５２）にこのジョブ・ステータス・レポートが作成されたが、そのときはまだ、ジョブが「２回目の試行」段階（「ジョブ・ステータス」によって表示されているとおり）にあった。可能ジョブ・ステータスは、「プロセスの開始待ち」、「試行１の進行中」、「試行２の進行中」、「試行３の進行中」、および「完了」に各種のエラー・ステータスが加わる。このジョブは７６３人の受信者を指定して、エンタープライズ・インターフェース経由で提出された。
【０１６３】
レポートの残りの部分は、このレポートの作成時におけるメッセージ送信のステータスを示している。情報は、次の３つのカテゴリに分けられる。
・  「マスタ・メッセージ」情報は、各試行について受信者レコード内に最初に指定された送信に関する。マスタ・メッセージの送信における失敗は、おそらくはリダイレクションを生じさせることになる（すなわち、次の試行を開始する）。
・  「コピー・メッセージ」情報は、そのほかのすべての送信に関係し、リダイレクションをトリガすることはない。
・  「電子メール添付書類の開封」は、電子メール添付の開封のみを参照する。
【０１６４】
例示のレポート２０００においては、受信者ごとに１つ、合計７６３のマスタ・メッセージが送信された。全体でそのうちの１２が失敗し、２回目の試行を生じている。７６３のマスタ・メッセージのうち、（指定されたリダイレクションの後においても）２つが失敗した。別の４つは、まだ未決である（すなわち、これら４つのメッセージは送信されたが、まだ配信ステータスが決定されていない）。ほかには、９４の「コピー」メッセージが送信された。これらのうち、８９が配信に成功し、２つが失敗し、３つがまだ未決である。
【０１６５】
このレポートの第２および第３のセクションは、各個別の送信の詳細を明細に記す。各送信ステータスは、次のフォーマットで与えられる。
【０１６６】
ｎｎ‐ｍｍｍ‐ｈｈ：ｍｍｄ
【０１６７】
これにおいて：
・  「ｎｎ」は、次のとおりの送信のステータスをあらわす：
‐  「ＯＫ」は成功を示す。
‐  「ＩＰ」は「進行中」を示す。
‐  「ＮＣ」は「未確認」（すなわち、「ＯＫ」を呈しているが明確にそうであるとは確認されていない）を示す。「ＮＣ」ステータスは、電子メールに特有であり、それについては以下に説明する。
‐  「２桁数字」はエラーが発生したことを示す（かつ、数字が失敗の理由を示す）。
・  「ｍｍｍ」は、宛先メディアである（ＥＭＬ、ＦＡＸ、ＳＭＳ、またはＰＡＰ）。
・  「ｈｈ：ｍｍ」は、配信成功または配信失敗の時刻である（あるいは、ＳＭＳならびにペーパーについては、キャリアへ送信した時刻）。
・  「ｄ」は、その後に続く日にメッセージが配信された場合（または配信に失敗した場合）にのみ含められる上付数字である。数字「１」は翌日、「２」は翌々日、という形で以下同様になる。
【０１６８】
「マスタ・メッセージ」セクション内においては、マスタ・メッセージ送信が（数回の試行の後においても）失敗したか、あるいは「進行中」のすべての受信者が、レポートのトップにグループ化される。そのほかは、受信者表示名によってソーティングされる。「コピー・メッセージ」セクション内においても、受信者が同じ順序に従ってソーティングされる。このレポートの最後のセクションは、電子メール添付が開封された時刻を示す。各添付は、「Ｘｎ」によって識別され、それにおいて「ｎ」は、セッションのはじめにある凡例の中にある添付書類を識別する番号である。以上のレポート２０００は、単なる一例に過ぎず、多くの変形が本発明の範囲ならびに精神から逸脱することなく実施され得る。
【０１６９】
ジョブ・コンフィグレーション（コントロール・ユーザのみ）
図２１Ａおよび２１Ｂのジョブ・コンフィグレーション・パネル２１００は、コントロール・ユーザ用に用意されており、ジョブ・コンフィグレーションに対応するメッセージ配信システムのデータベース内におけるレコードのクラスタの追加、変更、および削除に使用される。エンタープライズ・インターフェース用のジョブ・コンフィグレーションだけにアクセスすることができる。
【０１７０】
「ジョブ・コンフィグレーション」メイン・メニュー・オプションを選択した後、選択パネルが表示され、ユーザは、現存するジョブ・コンフィグレーションの選択、または新規作成のいずれかを選択することができる。このパネルを完成した後に、メイン・ジョブ・コンフィグレーション・パネル２１００が表示される。
【０１７１】
図２１Ａおよび２１Ｂのパネル２１００は、所定のジョブ・コンフィグレーションの完全な詳細を示している。情報は、水平ラインによって分割された多数のセクションとしてフォーマットすることができる。各セクションは、ジョブ・コンフィグレーション・レコード・クラスタ内の１つのレコードを表すことができる。図示されている例においては、ジョブ・コンフィグレーションが「ＪＡＶＡ＿ＭＡＰＰＩＮＧ＿ＣＬＡＳＳ」（ジャバ＿マッピング＿クラス）レコード、「ＪＡＶＡ＿ＭＡＰＰＩＮＧ＿ＣＬＡＳＳ＿ＲＥＳＯＵＲＣＥ」（ジャバ＿マッピング＿クラス＿リソース）レコード、「ＣＯＮＦＩＧ＿ＤＡＴＡ」（コンフィグ＿データ）レコード、「ＴＥＭＰＬＡＴＥ」（テンプレート）レコード、および２つの「ＴＥＭＰＬＡＴＥ＿ＡＲＴＩＦＡＣＴ」（テンプレート＿アーティファクト）レコードを包含している。
【０１７２】
各セクションには、レコードへインポートされたファイルのファイル名およびそのレコード内のほかのフィールドの値が示される。ユーザは、必要に応じてフィールドを変更することができる。またユーザは、「ブラウズ」ボタン（「ブラウズ」ウインドウを起動し、そこからユーザは、インポートするファイルを選択することができる）を使用し、それに続いて「インポート」ボタンを使用することによって新しいファイルをインポートすることもできる。それとは別に、ユーザは、「削除」ボタンを使用して全体のセクションを削除すること（すなわち関連するレコードを削除すること）ができる。
【０１７３】
繰り返すことのできるセクションについては、別の空のセクションを追加する「新しい．．．レコードを追加する」ボタンが提供されている。
【０１７４】
パネルのボトムにあるセクションでは、クラスタ内のファイルをＺＩＰアーカイブとして指定されたファイルへエクスポートすることができる。ファイルは、メッセージ配信システム上の特定のディレクトリ（たとえば、「Ｃ：￥ＪｏｂＣｏｎｆｉｇｕｒａｔｉｏｎｓ」）へストアでき、カスタマ名、ジョブ・コンフィグレーション表示名（すなわち、ジョブ・タイプ）および日付を連結した名前を自動生成させることができる。ユーザが「提出」ボタンをクリックするまで、変更は適用されない。削除ボタンは、必要時に全体のクラスタを削除することを可能にする。
【０１７５】
ＩＶ．  ＦＴＰインターフェース
特定の場合においては、カスタマが、カスタマのエンタープライズ・システムから受信者ファイルを生成し、自動配信（すなわち、人間の介入を伴わない）のためにそれらのファイルをメッセージ配信システムへ渡す必要を生じることがある。その種の状況においては、それらのニーズを満たす上でウェブ・インターフェースが適当でないものとなり得る。したがって、メッセージ配信システムは、ＦＴＰ転送によってインターネットを介して「エンタープライズ・インターフェース」スタイルのジョブの提出を可能にする。ＦＴＰ転送は、ジョブ提出（および関連する）スクリーンを置換する。カスタマ、ユーザ、およびアカウント・レコードは、ＦＴＰ転送前に正しくセットアップされる必要がある。
【０１７６】
ＦＴＰジョブ提出の後、ユーザは、通常のメッセージ配信システムのファシリティ（すなわち、ジョブ・ステータス・レポートの閲覧）を使用して、ジョブの進捗を監視することができる。
【０１７７】
ＦＴＰインターフェースを経由してジョブを提出するとき、ユーザは、ＦＴＰクライアント・プログラムを使用してインターネット経由で単一ＺＩＰファイルをメッセージ配信システムへ送信する。この送信プロセスは、ＳＳＬセキュリティを使用して行われ、ユーザに対してＦＴＰ「ユーザＩＤ」（「ｃｃｃｃｃ‐ｕｕｕｕｕ」の形式とすることができる；それにおいて「ｃｃｃｃｃ」はユーザのメッセージ配信システムのカスタマＩＤであり、「ｕｕｕｕｕ」はユーザのメッセージ配信システムのユーザＩＤである）およびＦＴＰ「パスワード」（ユーザのメッセージ配信システムのユーザ・パスワードと同一とすることができる）の入力を求めることができる。
【０１７８】
このＺＩＰファイルは、次に示すファイルを有する：
・  「ｊｏｂｃｏｎｔｒｏｌ．ｘｍｌ」（ジョブコントロール．ｘｍｌ）と呼ばれるジョブ・コントロール・ファイル；および、
・  ジョブ・コントロール・ファイル内に名前が指定されている１ないしは複数の受信者ファイル（「受信者ファイル」の項を参照されたい）。
【０１７９】
ジョブ・コントロール・ファイル（ｊｏｂｃｏｎｔｒｏｌ．ｘｍｌ（ジョブコントロール．ｘｍｌ））２２００のフォーマットを図２２に示す。このファイル内のほとんどのフィールドは、それらのウェブ・インターフェース等価部分の写しである。ｔｅｓｔ（テスト）属性は、これがテスト・ジョブであるか否かを指定する。カスタマは、一意的な「ｊｏｂ‐ｒｅｆｅｒｅｎｃｅ」（ジョブ‐リファレンス）、すなわちジョブ表示名を指定することができ、その結果カスタマは、その後に「ステータス・レポート」スクリーン上においてジョブを識別することができる。
【０１８０】
Ｖ．  システム・アーキテクチャ
次に、メッセージ配信システムの内部アーキテクチャについて、当該メッセージ配信システムを通る主要なプロセス・フローを含めて説明する。Ｊ２ＥＥおよびジャバ（Ｊａｖａ）ウェブ・コンテナの概念に対する全体的な知識が望まれるが、以下の説明の理解に不可欠ではない。折に触れ、このセクションではデータベース内のテーブル（または「レコード・タイプ」）を参照する。これらの名前には大文字を用いている。レコードの機能ならびに構造の詳細は、セクションＶＩＩに含めた。
【０１８１】
図２３は、メッセージ配信システム２４００のアーキテクチャを図示したブロック図である。システム２４００は、フロント・エンド２４１０およびバック・エンド２４２０を有する。ユーザ２４０２は、モジュール２４１２を使用してジョブ・ステータス・レポートを検索すること、標準インターフェース２４１４を使用してジョブを提出すること、およびエンタープライズ・インターフェース２４１６を使用してジョブを提出することが可能であり、これらはすべてフロント・エンド２４１０内にある。ＦＴＰファイル２４０４は、エンタープライズ・インターフェース２４１２へ供給することができる。
【０１８２】
標準インターフェース２４１４においては、ジョブ情報がユーザ２４０２から受け取られ、受信者リストおよびテンプレートがアップロードされる。『妥当性検査』が受信者リストのチェックのため起動される。提出要求がユーザから受け取られ、『提出』プロセスが起動される。
【０１８３】
インターフェース２４１４から、バック・エンド２４２０の標準ジョブ提出プロセッサ２４２４が、入力データの妥当性検査もしくはチェックを行い、そのジョブを提出する。これには、受信者リストのＸＭＬへの変換、およびジョブ・キュー内へのそのジョブのストアが含まれる。その後プロセスは、フラックス（Ｆｌｕｘ）モジュール２４３２へ進む。
【０１８４】
エンタープライズ・インターフェースは、ユーザ２４０２からジョブ情報を受け取り、受信者リストをアップロードする。受信者リストは、妥当性検査プロセスを起動することによってチェックされる。提出要求がユーザから受け取られ、提出プロセスが起動されてその要求が処理される。プロセスは、インターフェース２４１６から、エンタープライズ・ジョブ提出プロセッサ２４２６へ続く。ここでは、入力データをチェックすることによって受信者リストの妥当性検査を行い、かつ提出プロセスを操作するが、それが受信者リストをＸＭＬへ変換してそのジョブをジョブ・キュー内へストアする。その後プロセスは、フラックス（Ｆｌｕｘ）モジュール２４３２へ進む。プロセッサ２４２４ならびに２４２６の出力はイベントである。その後、フラックス（Ｆｌｕｘ）２４３２からアクションが生じる。
【０１８５】
アクションは、バンドル・プロセッサ２４５０へ進む。モジュール２４５２は、各メディア・タイプについて１つの送信バンドルを構築し、その後、それぞれの送信バンドルごとにプロセス・バンドル・スレッド（ａ、ｂ、ｃ、およびｄ）を開始する。これらのスレッドは、Ａ、Ｂ、Ｃ、およびＤと示されており、それぞれモジュール２４５４、２４５６、２４５８、および２４６０へ結合される。これらのモジュール２４５４、２４５６、２４５８、および２４６０のそれぞれは、類似のフォーマットを有している。たとえば、ファクシミリ送信バンドル２４５４は、差し込み、フォーマット、およびその後の送信オペレーションを伴う。ペーパー送信バンドル２４５６、ＳＭＳ送信バンドル２４５８、および電子メール送信バンドル２４６０も類似の構成を有している。各バンドル・モジュールの出力は、それぞれのキャリアへ、たとえばエクスペダイト（ｅｘｐｅｄｉｔｅ）２４６２、ＥＤＩポスト（ＥＤＩ  ｐｏｓｔ）２４６４、ＳＭＳリーチ（ＳＭＳ  ｒｅａｃｈ）２４６６、およびメッセージ・リーチ（ｍｅｓｓａｇｅ  ｒｅａｃｈ）２４６８へ提供されるが、これらはすべてキャリアである。各キャリアは、ステータス・レポートをバック・エンド２４２０へ帰す。エクスペダイト（ｅｘｐｅｄｉｔｅ）２４６２はファクシミリ・ステータス・レポート２４４２を、ＥＤＩポスト（ＥＤＩ  ｐｏｓｔ）２４６４はペーパー・ステータス・レポート２４４０を、ＳＭＳリーチ（ＳＭＳ  ｒｅａｃｈ）２４６６はＳＭＳステータス・レポート２４３８を、メッセージ・リーチ（ｍｅｓｓａｇｅ  ｒｅａｃｈ）２４６８は電子メール・ステータス・レポート２４３６をそれぞれ提供する。
【０１８６】
電子メール・ステータス・レポート２４３６、ＳＭＳステータス・レポート２４３８、ペーパー・ステータス・レポート２４４０、およびファクシミリ・ステータス・レポート２４４２は、ステータス収集モジュール２４３４へ提供される。このモジュール２４３４は、フラックス（Ｆｌｕｘ）２４３２によって周期的に起動される。これは、キャリアから供給されたステータス情報を検索し、それをジョブ・キューへ適用する。ジョブ・キュー２４３０は、ジョブならびにテンプレート情報、受信者情報およびステータス情報を有する。ジョブ・キュー２４３０は、請求書発行レコードを請求書発行システム２４６０へ提供し、更新ステータス情報をバンドル・プロセッサ２４５０へ提供する。ジョブ・キュー２４３０は、出力を、好ましくはＸＭＬドキュメントとして、ステータス情報を検索するステータス・レポート・モジュール２４２２へ提供する。ステータス・レポート・モジュール２４２２は、フロント・エンド２４１０内のモジュール２４１２によって検索されたジョブ・ステータス・レポートを提供する。ユーザ２４０２は、ＸＳＬスタイルシートを使用してフォーマットされたＸＭＬのステータス・レポートを検索し、それをプリンタで扱いやすいフォーマットで表示することができる。これらの、およびそのほかの詳細については、以下に説明する。
【０１８７】
ジョブ・キュー
ジョブ・キュー２４３０は、メッセージ配信システム２４００の主要コンポーネントである。ジョブ・キュー２４３０は、現在実行中、実行待ち、あるいは最近完了したすべてのメッセージ配信システムのジョブの詳細を含んでいる。各ジョブは、各種タイプのレコードのクラスタによってデータベース内に表されている。各クラスタは、ＪＯＢ（ジョブ）レコードによって見出しが付けられる。レコードは、ジョブ自体、使用されているテンプレート、メッセージが渡されることになる受信者、差し込みフィールド、および宛先の詳細を包含している。
【０１８８】
通常動作の間、メッセージ配信システム２４００は、あらかじめ定義済みの時刻において（たとえば毎分）ジョブ・キュー２４３０をスキャンし、実行中もしくは最近完了したすべてのジョブの詳細を抽出する。メッセージ配信システム・サポート・チームの、「コンソール」パネルを表示している任意のブラウザがこの抽出されたデータにアクセスし、獲得されたデータを使用してシステム内における現在のジョブ・ステータスを表示する。このようにしてメッセージ配信システム・サポート・チームは、ジョブ・キュー２４３０の最新の概観を有する。
【０１８９】
チームは、『ジョブ・コントロール』パネルによって提供される機能を使用し、ジョブのプロセスに影響を与える（たとえば、失敗したジョブのリカバリ、送信バンドル・ファイルの再送信等）。このようにジョブ・キューは、コントロールの中心ポイントを提供し、それを使用してシステム２４００上におけるプロセス負荷を平滑にし、カスタマの要求に迅速に応答し、最初からユーザにジョブを再提出させることを必要とせずに予期しない問題に対処することができる。
【０１９０】
ジョブは、そのジョブの妥当性検査が完了し、ユーザによってプロセッサ２４２４もしくは２４２６を介して提出されると直ちにジョブ・キュー２４３０内に入れられる。ジョブは、そのジョブが完了し、その後いくらかの時間が経過するまで（ユーザに、そのジョブによって生成されるジョブ・ステータス・レポート２４２２を調べる時間を与えるため）ジョブ・キュー２４３０内に残存する。その後、「ガーベージ・コレクション」プロセスによってそれを削除することができる。
【０１９１】
ジョブの処理
再度図２３を参照すると、メッセージ配信システムのハイレベルのアーキテクチャ２４００が示されている。大きなボックス２４００は、メッセージ配信システム自体を表す。データ構造は、モジュール２４３４、２４３６、２４３８、２４４０、２４４２、２４５４、２４５６、２４５８、および２４６０であり、外部エンティティは、モジュール２４０２、２４０４、２４６０、２４６２、２４６４、２４６６、および２４６８である。プロセスは、モジュール２４１２、２４１４、および２４１６（サーブレットおよびＪＳＰ）およびモジュール２４２２、２４２４、２４２６、２４３４、および２４５０（セッション・ビーン）である。
【０１９２】
システム２４００は、基本的に２分され、フロント・エンド２４１０およびバック・エンド２４２０に分けられ、ジョブ・キュー２４３０は、それらの間の「ブリッジ」を表す：
・  フロント・エンド・ロジック２４１０は、トムキャット（Ｔｏｍｃａｔ）コンテナ内において実行されるジャバ（Ｊａｖａ）「ＪＳＰ」ならびに「サーブレット」によって供給され得る。
・  バック・エンド２４２０は、ジェイボス（ＪＢｏｓｓ）コンテナ内において実行されるジャバＥＪＢ（Ｊａｖａ  ＥＪＢ）「セッション・ビーン」（それもまたＥＪＢ「エンティティ・ビーン」およびそのほかのジャバ（Ｊａｖａ）オブジェクトを使用する）を有することができる。
【０１９３】
フロント・エンドは、データベースへ直接アクセスせず、それに代えて、バック・エンド２４２０内のセッション・ビーンを起動してそれを行わせる。
【０１９４】
フロント・エンド
メッセージ配信システムのフロント・エンド２４１０は、ユーザ・インターフェースの扱いに関するロジックを包含している。フロント・エンド２４１０は、ユーザ２４０２へ高速応答を提供するべく設計され、そのため、フロント・エンド２４１０からは長い処理タスクが排除されることがある。
【０１９５】
フロント・エンドの主要な機能は、ユーザ２４１４、２４１６によって提出されたジョブを受け取り、それらをジョブ・キュー２４３０上に置き、処理を待機させることである。図面には、より重要な３つのフロント・エンド・プロセス２４１２、２４１４、２４１６が示されている：
・  エンタープライズ・インターフェース２４１６を経由したジョブの提出、
・  標準インターフェース２４１４を経由したジョブの提出、および
・  ジョブ・ステータス・レポート２４１２の要求。
【０１９６】
このほかのフロント・エンド・プロセスも考えられるが、簡潔のためその種のプロセスは図２３内に含めていない。
【０１９７】
それぞれの「フロント・エンド」プロセス（サーブレットおよびＪＳＰの混合を有する）は、対応する「バック・エンド」セッション・ビーンを有しており、それがそのすべてのデータベース検索および更新を実行する。これによりフロント・エンド２４１０は、データベース・アクセス／ロッキング問題からサーブレットおよびＪＳＰを解放することによって良好なインタラクティブ応答を提供することが可能になる。
【０１９８】
フラックス（Ｆｌｕｘ）
フロント・エンド２４１０がジョブ・キュー２４３０上にジョブを置くときは常に、「フロント・エンド」（または、より正確に言うのであれば、フロント・エンドのセッション・ビーン）がフラックス（Ｆｌｕｘ）イベント２４３２をトリガする。フラックス（Ｆｌｕｘ）は、シムズ・ソフトウエア（ＳＩＭＳ  Ｓｏｆｔｗａｒｅ）によって供給されるイベント・スケジューリング・ツールである。このスケジューリング・ツールは、メッセージ配信システム２４００がアクティブなときは常に、ジャバ（Ｊａｖａ）仮想マシン内の独立したプロセスとして連続的に動作している。このツールは、メッセージ配信システム内に独自の情報テーブルを維持している。それらは、完全にフラックス（Ｆｌｕｘ）２４３２によって管理される。フラックス（Ｆｌｕｘ）モジュール２４３２は、タイマによって、もしくはそのほかのプロセスによってトリガされるイベントに応答し、そのそれぞれについて、あらかじめ定義済みのアクションを行う。たとえば、新しいジョブがジョブ・キュー２４３０上に置かれると、フロント・エンドのセッション・ビーンが、フラックス（Ｆｌｕｘ）２４３２に対して直ちに（あるいは、ユーザがその後のジョブの実行をスケジュールしている場合には、将来の時点において）トリガされるイベントを定義する。イベントがトリガされると、フラックス（Ｆｌｕｘ）２４３２は、「バック・エンド」２４３０内のこのイベントを扱うセッション・ビーンを起動する。
【０１９９】
バック・エンド
「バック・エンド」２４２０は、フロント・エンド・プロセスに対する「ヘルパ」として作用するセッション・ビーンのセットを含んでいる。バック・エンドのセッション・ビーンは、フロント・エンドのコンポーネントが要求するデータベース・アクセス・オペレーションを実行する。たとえば、
・  ＥｎｔｅｒｐｒｉｓｅＪｏｂＳｕｂｍｉｓｓｉｏｎＰｒｏｃｅｓｓｏｒＢｅａｎ．ｊａｖａ（エンタープライズジョブサブミッションプロセッサビーン．ｊａｖａ）は、エンタープライズ・ジョブ提出インターフェースを具体化するサーブレットおよびＪＳＰのためのデータベース・オペレーションを実行する。
・  ＳｔａｔｕｓＲｅｐｏｒｔＢｅａｎ．ｊａｖａ（ステータスレポートビーン．ｊａｖａ）は、「ジョブ・ステータス・レポート」機能を具体化するサーブレットおよびＪＳＰによる使用のためにデータベースからステータス・レポート情報を収集する。
・  ＡｃｃｏｕｎｔＢｅａｎ．ｊａｖａ（アカウントビーン．ｊａｖａ）は、アカウント維持パネルを具体化するサーブレットおよびＪＳＰに代わってＡＣＣＯＵＮＴ（アカウント）レコードに対するデータベースＩ／Ｏを実行する。
【０２００】
またバック・エンド２４２０は、メッセージ配信システム２４００の「実際の仕事」、すなわちジョブ・キュー２４３０から獲得されたジョブの処理を実行するセッション・ビーンを含んでいる。ジョブの処理は、概略で以下のように進められる。
【０２０１】
１．  メッセージ配信システム２４００が、そのジョブ内のすべてのＲＥＣＩＰＩＥＮＴ（レシピエント；受信者）レコードをスキャンし、最初のＡＴＴＥＭＰＴ（アテンプト；試行）レコードにリンクされているＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション；送信）レコードを識別する。これらのそれぞれは、最初の試行として送信されなければならない宛先を表している。メッセージ配信システム２４００は、続いていくつかの送信バンドル２４５４、２４５６、２４５８、２４６０（「送信パケット・バンドル」と呼ばれることもある）をメモリ内に生成する。宛先メディアごとに１つの送信バンドル２４５４、２４５６、２４５８、２４６０が存在し（すなわち、ファクシミリについて１つ、電子メールについて１つという形になる）、それぞれがいくつかの送信パケットを含んでいる。各送信パケットは、そのメディアに向けられた「最初の試行」の宛先を伴う受信者についての情報を含む。
【０２０２】
したがって、たとえば、特定のＲＥＣＩＰＩＥＮＴ（レシピエント；受信者）レコードが、その最初の「試行」においてファクシミリならびに電子メールの両方に対する「送信」を指定している場合、その受信者の詳細のコピーが、ファクシミリ送信バンドルならびに電子メール送信バンドルの両方に現れる。
【０２０３】
２．  続いて送信バンドルが異なる処理スレッド上において並列に処理される。各送信バンドルは、３つの段階において処理される：
差し込み段階‐‐受信者レコードからの差し込み値が、そのメディア用のテンプレート（１ないしは複数）内の適切な差し込みフィールド内に代入され、その結果、各受信者用の完全に差し込みが行われたメッセージが作られる。
フォーマット段階‐‐バンドル内の各メッセージは、必要に応じて、適切な出力フォーマット（たとえば、ファクシミリ用のＴＩＦＦ）へ再フォーマットされる。
送信段階‐‐各送信バンドルは、ディスク・ファイルに書き込まれ、その後、それ以降のその宛先に対する送信のためのキャリア（たとえば、ファクシミリについてはエクスペダイト（Ｘｐｅｄｉｔｅ）、電子メールについてはメッセージリーチ（ＭｅｓｓａｇｅＲｅａｃｈ）、ペーパーについてはＥＤＩポスト（ＥＤＩ  Ｐｏｓｔ）等）へ送信される。
【０２０４】
３．  その後メッセージ配信システム２４００は、キャリアによって供給されるキャリア・ステータス・レポートを待機する。各キャリア２４６２、２４６４、２４６６、２４６８は、受け取ったそれぞれの送信バンドルごとにキャリア・ステータス・レポートを作成する。このレポート２４３６、２４３８、２４４０、２４４２は、受信者に対する各個別のメッセージの配信の結果を示す。キャリア・ステータス・レポートの検索は、ステータス収集２４３４として知られる。
【０２０５】
４．  メッセージ配信システム２４００は、各種のキャリア・ステータス・レポート２４３６、２４３８、２４４０、２４４２内の情報を使用して、ジョブ・キュー２４３０（ＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション；送信）レコード内に保持されている）内の受信者ステータス情報を更新する。この情報には、成功／失敗コード、送信完了時刻、送信されたページ／バイト数等が含まれる。
【０２０６】
最初の「試行」に関する各種のキャリア・ステータス・レポートのすべてが受信され、ジョブ・キュー２４３０内に収められると、メッセージ配信システム２４００は、再度、ジョブ・キュー２４３０内の受信者データをスキャンする。最初の試行のマスタ（すなわち、最初の）送信が失敗した受信者がいる場合には、メッセージ配信システム２４００が、それらの「２回目の試行」の送信を使用してそれらのジョブを（前述のステップ１〜４を反復することによって）再処理する。これらの２回目の試行のいずれかのマスタ送信が失敗した場合には、プロセスが３回目の試行の送信について再度繰り返される。
【０２０７】
ジョブの処理の間もしくはその後において、カスタマは、随時、整理統合された「ジョブ・ステータス・レポート」を要求することができる。これは、ジョブの詳細、受信者の数、およびその時点における送信済みの各メッセージの顛末の完全な要約を提供する。オプションとしてユーザは、ジョブの完了時にこのレポートをそのユーザに対して電子メールさせることができる。このオプションは、アカウント・レコード内に示される。メッセージ配信システムは、各送信の試行の完全な詳細（すなわち、ページ数、送信されたバイト数、成功／失敗ステータス等）を含む請求書発行レコードのセット（受信者への各試行済み送信について１つ）を作成することができ、それらを請求書発行システム２４６０へ渡せば、そこでこれらのレコードをカスタマへのインボイスに使用することができる。
【０２０８】
ＶＩ．  データ・ファイル構造
次に、メッセージ配信システムによって使用されるいくつかのデータ・ファイルのフォーマットについて説明する。
【０２０９】
テンプレート・ファイル
テンプレート・ファイルは、広範なフォーマットで供給することが可能であるが、２つのグループ、すなわち差し込みフィールドを包含できるグループとそれを包含できないグループに分けることができる。
【０２１０】
第１のグループは、ＸＭＬスタイルシート（ＸＳＬ）ファイル、マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）（ＤＯＣ）ファイル、およびシンプル・テキスト（ＴＸＴ）ファイルを含むことができる。
・  ＸＭＬスタイルシート（ＸＳＬ）ファイル
‐  ＸＭＬスタイルシートは、ＸＭＬ表記法で表わされるファイルであり、ドキュメントのフォーマットを正確に記述する（テキスト、イメージ、マージン、ヘッダ、フッタ、およびそのほかのアーティファクトを含んでいる）。またこのファイルには、「差し込みフィールド」の定義も用意されている。受信者ファイル（ＸＭＬフォーマット）のスキャン、各受信者の「差し込み値」の抽出、それらとＸＳＬスタイルシートの結合、および各受信者のための出力ドキュメント（ＸＳＬ：ＦＯとして知られるフォーマット）の作成のプロセスは、ザラン（Ｘａｌａｎ）（アパッシュ（Ａｐａｃｈｅ）から提供されている）と呼ばれるソフトウエア・プロダクトによって実行することができる。ＸＳＬならびにＸＳＬ：ＦＯの詳細については、次のドキュメントを参照されたい：エクステンシブル・スタイルシート・ランゲージ（Ｅｘｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ）（ＸＳＬ）、バージョン１．０、Ｗ３Ｃ勧告、２００１年１０月１５日、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ（ワールド・ワイド・ウェブ・コンソーシアム））発行、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｓｌから入手可能。
・  マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）（ＤＯＣ）ファイル
‐  ＤＯＣファイルは、マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）ワード・プロセッサによって作成することができる。「差し込みフィールド」をドキュメント内に定義することが可能であり、ワード（Ｗｏｒｄ）の標準「差し込み」ファシリティを使用して「差し込み値」を代入することができる。メッセージ配信システム内においては、ＤＯＣファイル・テンプレートの差し込み処理を、マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）自体によって行うことができる。ワード（Ｗｏｒｄ）は、Ｗｉｎｄｏｗｓ  ２０００（ウインドウズ２０００）のコントロールの下に（すなわち、ジャバ（Ｊａｖａ）仮想マシンの外側で）直接実行されるスタンド‐アロンのプログラムとして実行される。メッセージ配信システムは、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）のＤＣＯＭファシリティを使用してワード（Ｗｏｒｄ）とインタラクションすること（すなわち、テンプレートならびに受信者ファイルをそれに渡し、差し込みの結果をそれから受け取ること）ができる。
・  テキスト・ファイル（ＴＸＴ）
‐  テキスト・ファイルは、オプションとして差し込みフィールドを含むことができる。適切なところでの「エンド‐オブ‐ライン」文字（すなわち、＜ＣＲ＞および＜ＬＦ＞）の使用は許されているが、そのほかのフォーマッティング文字は許可されていない。
【０２１１】
このほかのタイプの、差し込みフィールドを含むことのできないテンプレートとして次に示すものが挙げられる。
・  ＴＩＦＦ（ＴＩＦ）ファイル
ＴＩＦＦファイルは、ビットマップ・グラフィクス形式のイメージを含む。
・  アドビ・アクロバット（Ａｄｏｂｅ  Ａｃｒｏｂａｔ）ドキュメント（ＰＤＦ）ファイル
これらのファイルのフォーマットは、アドビ（Ａｄｏｂｅ）によって公開されている。
・  ポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）（ＰＲＮ）ファイル
ポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）ファイルは、広範なプリンタをドライブするべく特別に設計されている（かつ、ペーパーに向けられる出力を作成するメッセージ配信システムによって使用することができる）。ユーザは、通常、テキストおよびそのほかの情報をワード・プロセッサへ入力し、その後そのファイルを物理的なプリンタではなくプリント・ファイル（デフォルトでファイル・タイプＰＲＮを有する）へ出力することによってポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）ファイルを作成する。
・  ＨＴＭＬ（ＨＴＭ）ファイル
ＨＴＭＬファイルは、ＨＴＭＬマークアップ言語でフォーマットされた情報を有する。
【０２１２】
受信者ファイル
エンタープライズ・インターフェース２４１６のユーザは、広範多様なフォーマットを用いてファイルをメッセージ配信システム２４００へ提出するが、標準インターフェース２４１４のユーザは、好ましくは「コンマ・セパレーテッド・バリュー（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅ）」（ＣＳＶ）フォーマットを用いてファイルを提出する。特別なジャバ（Ｊａｖａ）クラス（データ・コンバータの部分）が使用されて、ジョブ・キュー２４３０内（メッセージ配信システム内）へ入れる前に、モジュール２４２４もしくは２４２６内において提出されたファイルがＸＭＬフォーマットへ変換される。このクラスは、データベース内に保持されているジョブ・コンフィグレーション内のＪＡＶＡ＿ＭＡＰＰＩＮＧ＿ＣＬＡＳＳ（ジャバ＿マッピング＿クラス）レコード内において保持されている。ジャバ・マッピング・クラスは、このほかの、マッピング・プロセスを援助するアーティファクトを使用することができる。これは、このほかのジャバ（Ｊａｖａ）クラス、Ｘフラット（ＸＦｌａｔ）マッピング・ファイル、およびＸＳＬスタイルシートを含むことができる。これらのアーティファクトは、データベース内に保持されているジョブ・コンフィグレーション内のＪＡＶＡ＿ＭＡＰＰＩＮＧ＿ＣＬＡＳＳ＿ＲＥＳＯＵＲＣＥ（ジャバ＿マッピング＿クラス＿リソース）レコード内において維持される。
【０２１３】
Ｘフラット（ＸＦｌａｔ）マッピング・ファイルは、「ＸＭＬ変換ユーティリティ」、すなわち広範多様な単純フォーマット変換を扱うプログラムへ提出することができるステートメント（Ｘフラット（ＸＦｌａｔ）として知られるフォーマット変換定義言語で表現される）のセットである。
【０２１４】
ＸＭＬフォーマット
ＸＭＬフォーマットの受信者ファイルは、受信者ごとに１つの、したがって多数の＜ｒｅｃｉｐｉｅｎｔ＞（レシピエント）エレメントを包含している。その種のファイル２５００（１人の受信者だけを含んでいる）を図２４に示す。次に、この例のデータを簡単に説明する。
・  個人の詳細
「＜ｐｅｒｓｏｎａｌ‐ｄｅｔａｉｌｓ＞」（パーソナル・ディーテイルズ）エレメントは、受信者の敬称（ｔｉｔｌｅ）、名前（ｆｉｒｓｔ  ｎａｍｅ）、および姓（ｌａｓｔ  ｎａｍｅ）を表示するサブエレメントを含む。これらは、ファクシミリの「ストリップ・アドレス」内（ファクシミリが受信者へ送信される場合は常時）、および郵便の宛名の最初の行内（ペーパーの郵便が受信者へ送られるとき）において使用される。オプションの「＜ｒｅｆｅｒｅｎｃｅ＞」（リファレンス）エレメントが用意されており、そこには、メッセージ配信システムによって生成されるジョブ・ステータス・レポート上に現れる最大１０文字のユーザ指定テキストを含めることができる。センダは、通常、このエレメントを使用し、センダにとって意味のある何らかの名前（たとえば、従業員番号、銀行口座番号、メディケア番号等）によって受信者を識別する。
・  宛先プレファレンス
「＜ｄｅｓｔｉｎａｔｉｏｎ‐ｐｒｅｆｅｒｅｎｃｅ＞」（ディスティネーション・プレファレンス）エレメントは、受信者に対して使用される宛先、および失敗の場合に起動されるリダイレクション・オプションを指定する。このエレメントは、１、２、または３の「＜ａｔｔｅｍｐｔ＞」（アテンプト）サブエレメントを有する。それぞれの「＜ａｔｔｅｍｐｔ＞」（アテンプト）サブエレメントは、スペースまたはカンマによって分けられた１、２、または３の送信を指定する。各「送信」は、「＜ｄｅｓｔｉｎａｔｉｏｎ＞」（ディスティネーション）フィールド内の「ｉｄ」属性と対応しており、したがって特定の宛先を示す。最初の送信は「マスタ」として指定される。ファクシミリの場合は、各「送信」が３回までのリトライを含む。
・  宛先
各メディア・タイプ（「メディア」（ｍｅｄｉａ）属性によって示される）について１つの「＜ｄｅｓｔｉｎａｔｉｏｎ＞」エレメントを許容することができる。特定のメディアに対してエレメントが提供されていない場合は、そのメディアによってその受信者へ到達できないことを意味する。「ｉｄ」属性は、前述した「＜ａｔｔｅｍｐｔ＞」（アテンプト）エレメントへのリンクとして使用され、任意の都合のよい識別子を含むことができる。「＜ｄｅｓｔｉｎａｔｉｏｎ＞」（ディスティネーション）エレメントのサブエレメントは、それ自体の実際の宛先を指定する。
ペーパー・アドレスには、２つのスタイルが許容されている。図２４は、パーズ済みの形式を示す。パーズ未済のアドレスについても、次に示すエレメントを使用して入力することができる：
＜ａｄｄｒｅｓｓ‐ｌｉｎｅ‐１＞  ＜／ａｄｄｒｅｓｓ‐ｌｉｎｅ‐１＞，
＜ａｄｄｒｅｓｓ‐ｌｉｎｅ‐２＞  ＜／ａｄｄｒｅｓｓ‐ｌｉｎｅ‐２＞
．．．
＜ａｄｄｒｅｓｓ‐ｌｉｎｅ‐６＞  ＜／ａｄｄｒｅｓｓ‐ｌｉｎｅ‐６＞
・  受信者データ
「＜ｒｅｃｉｐｉｅｎｔ‐ｄａｔａ＞」（レシピエント・データ）エレメントは、差し込みフィールドを含む。上記の例においては、インボイス上の単一行を表す１つの差し込みフィールドが存在し、これがその行内の情報の項目を表すいくつかのサブ差し込みフィールドを含んでいる。ただしこれは、単なる例に過ぎない。「＜ｒｅｃｉｐｉｅｎｔ‐ｄａｔａ＞」（レシピエント・データ）フィールドは、完全に自由なフォーマットを（良好にフォーマットされたＸＭＬを含んでいることを前提として）許容する。
【０２１５】
ＶＩＩ．  データベース構造
メッセージ配信システムのデータベースは、多様なテーブルを含んでいる。図２５は、テーブルおよび関係を示したエンティティ関係図２６００である。図２５において、データベース・テーブル間の「多対１」対応は、関係の「多」側の「クローフート」によって示されている。
【０２１６】
それぞれのテーブル（「レコード」または「エンティティ」と様々に呼ばれる）およびテーブル内の列（「フィールド」と呼ばれることもある）について次に説明する。各テーブルは、好ましくは「ｘｘｘｘ＿ＰＫ」（「ｘｘｘｘ」はそのテーブルの名前）と名付けられた一意的な１次鍵を含む。このキーは、データベースの複製を理由として必要となり、通常は自動的に生成される。
【０２１７】
カスタマ、アカウント、およびユーザ
このメッセージ配信システムは、カスタマ、アカウント、および請求書発行の各プレファレンスを関係付けする情報を有している。メッセージ配信システムは、この情報のサブセットだけを必要とする。この理由からカスタマに、請求書発行システムへの直接オンライン・アクセスが提供されることがあり、それによってカスタマは、そのカスタマのアカウントおよび請求書発行のプレファレンスの直接コントロールを有する（かつ、必要なときは、メッセージ配信システムのサブセットがメッセージ配信システムへダウンロードされる）。
【０２１８】
データは、メッセージ配信システムと請求書発行システムの間においてマニュアルで複製することができる。そのようにする場合には、メッセージ配信システム内に維持されるその種のデータの量を最小に維持することができる。メッセージ配信システムは、３つの主要エンティティ、すなわちＣＵＳＴＯＭＥＲ（カスタマ）２６１０、ＵＳＥＲ（ユーザ）２６１２、およびＡＣＣＯＵＮＴ（アカウント）２６１４としてカスタマ関連の情報をストアする。各カスタマは、そのカスタマ独自の、ユーザおよびアカウントのグループを「所有」し、管理する。次に、データベース・テーブルならびに各フィールドについて説明する。
【０２１９】
ＣＵＳＴＯＭＥＲ（カスタマ）
このテーブル２６１０はカスタマを表し、データベース内の「アンカー・ポイント」であり、ほかのすべてのエンティティがリンクされる。
ｃｕｓｔｏｍｅｒ＿ＰＫ（カスタマ＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｉｄ：カスタマの識別子。ｎ文字（ｎを８としてもよい）の識別子が一意的にカスタマを識別する。カスタマの各ユーザは、そのユーザがメッセージ配信システムにログオンするとき、このカスタマＩＤを入力する。
ｎａｍｅ（ネーム）：カスタマの名前（たとえば、ＡＢＣ  Ｂａｎｋｉｎｇ  Ｃｏｒｐｏｒａｔｉｏｎ（ＡＢＣバンキング・コーポレーション））。このフィールドは、そのカスタマに関係する各種のスクリーンならびにレポート上に現れる。
ｔｉｍｅｚｏｎｅ＿ｃｏｄｅ（タイムゾーン＿コード）：カスタマが在住するタイムゾーンを識別する。
ｅｎａｂｌｅｄ（イネーブルド）：このカスタマがイネーブルであるか、ディセーブルであるかを示すブール・フラグ。ディセーブルされているカスタマは、メッセージ配信システムへアクセスすることが許されない（すなわち、そのカスタマのユーザは、だれもログオンすることができない）。
ｅｎａｂｌｅｄ＿ｃｈａｎｇｅ＿ｔｉｍｅ（イネーブルド＿チェンジ＿タイム）：「ｅｎａｂｌｅｄ（イネーブルド）」フラグが最後に変更された日／時を示す。長期間にわたってディセーブルされているカスタマは、このデータベースから削除される。
ｆｔｐＪｏｂＳｕｂｍｉｓｓｉｏｎ（ｆｔｐジョブサブミッション）：このカスタマが、ＦＴＰを介してジョブを提出できる場合には「真」にセットされる。
【０２２０】
ＵＳＥＲ（ユーザ）
ＵＳＥＲ（ユーザ）レコード２６１２は、ユーザ（すなわち、メッセージ配信システムへアクセスする人間）に関する情報を含んでいる。データベース内におけるこのテーブルの実際の名前は、「ＵＳＥＲ＿」（ユーザ＿）である。後続のアンダースコア文字は、ＳＱＬの予約語「ｕｓｅｒ」（ユーザ）とのコンフリクトを回避するために追加されている。
ｕｓｅｒ＿ＰＫ（ユーザ＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｉｄ：ユーザの識別子。ｎ文字（ｎを８としてもよい）の識別子が一意的にユーザを識別する。ユーザは、そのユーザがメッセージ配信システムにログオンするとき、このユーザＩＤを入力しなければならない。
ｎａｍｅ（ネーム）：ユーザの名前（たとえば、Ｍａｒｙ  Ｓｍｉｔｈ（メリー・スミス））。このフィールドは、そのユーザに関係する各種のスクリーンならびにレポート上に現れる。
ｐａｓｓｗｏｒｄ（パスワード）：ログオンのために入力することができるユーザのパスワード。
ｃｕｓｔｏｍｅｒ＿ＦＫ（カスタマ＿ＦＫ）：このユーザを「所有」するカスタマに対するリンク。
ｅｍａｉｌ（イーメール）、ｐｈｏｎｅ＿ｎｕｍｂｅｒ（フォン＿ナンバ）、ｆａｘ＿ｎｕｍｂｅｒ（ファックス＿ナンバ）、ｍｏｂｉｌｅ＿ｎｕｍｂｅｒ（モバイル＿ナンバ）：これらのフィールドは、ユーザに関する連絡先情報を含む（その結果、メッセージ配信システム・サポート・チームは、必要なときにこのユーザへ連絡することができる）。
ｔｅｓｔ＿ｅｍａｉｌ（テスト＿イーメール）、ｔｅｓｔ＿ｆａｘ＿ｎｕｍｂｅｒ（テスト＿ファックス＿ナンバ）、ｔｅｓｔ＿ｓｍｓ＿ｎｕｍｂｅｒ（テスト＿ｓｍｓ＿ナンバ）：これらのフィールドは、テスト・ジョブのための宛先としてユーザの電子メール・アドレス、ファクシミリ番号、およびＳＭＳ電話番号を含む。
ｅｎａｂｌｅｄ（イネーブルド）：このユーザがイネーブルであるか、ディセーブルであるかを示すブール・フラグ。ディセーブルされているユーザは、メッセージ配信システムへアクセスすることが許されない。
ｅｎａｂｌｅｄ＿ｃｈａｎｇｅ＿ｔｉｍｅ（イネーブルド＿チェンジ＿タイム）：「ｅｎａｂｌｅｄ（イネーブルド）」フラグが最後に変更された日／時を示す。規定の期間にわたってディセーブルされているユーザは、このデータベースから削除されることがある。
ａｄｍｉｎｉｓｔｒａｔｏｒ（アドミニストレータ）：このユーザが管理者ユーザであるか否かを示すブール・フラグ。管理者ユーザは、標準ユーザが使用できない特定の特権を有する。
【０２２１】
ＡＣＣＯＵＮＴ（アカウント）
ＡＣＣＯＵＮＴ（アカウント）レコード２６１６は、アカウントに関する情報を含んでいる。各ＡＣＣＯＵＮＴ（アカウント）２６１６は、そのアカウントの下に実行するジョブに設定される特性ならびに制約を定義する。
ａｃｃｏｕｎｔ＿ＰＫ（アカウント＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｎａｍｅ（ネーム）：アカウントの名前。これは、そのアカウントの目的の備忘としてカスタマに有用な「意味をなす」名前である。
ｃｕｓｔｏｍｅｒ＿ＦＫ（カスタマ＿ＦＫ）：このアカウントを「所有」するカスタマに関するＣＵＳＴＯＭＥＲ（カスタマ）レコードに対するリンク。
ｅｎａｂｌｅｄ（イネーブルド）：このアカウントがイネーブルであるか、ディセーブルであるかを示すブール・フラグ。ディセーブルされているユーザは、メッセージ配信システムへアクセスすることが許されない。
ｅｎａｂｌｅｄ＿ｃｈａｎｇｅ＿ｔｉｍｅ（イネーブルド＿チェンジ＿タイム）：「ｅｎａｂｌｅｄ（イネーブルド）」フラグが最後に変更された日／時を示す。規定の期間にわたってディセーブルされているアカウントは、このデータベースから削除されることがある。
ｅｎｔｅｒｐｒｉｓｅ（エンタープライズ）：このアカウントに、エンタープライズもしくは標準インターフェースのいずれが必要となるかを示すブール・フラグである。
ｐｒｏｄｕｃｔ（プロダクト）：このアカウントの下に使用可能なメッセージ配信システムの機能を示すコード。
ｆａｘ＿ｃａｒｒｉｅｒ（ファックス＿キャリア）、ｆａｘ＿ｃａｒｒｉｅｒ＿ｕｓｅｒ（ファックス＿キャリア＿ユーザ）、ｆａｘ＿ｃａｒｒｉｅｒ＿ｐａｓｓｗｏｒｄ（ファックス＿キャリア＿パスワード）、ｅｍａｉｌ＿ｃａｒｒｉｅｒ（イーメール＿キャリア）、ｅｍａｉｌ＿ｃａｒｒｉｅｒ＿ｕｓｅｒ（イーメール＿キャリア＿ユーザ）、ｅｍａｉｌ＿ｃａｒｒｉｅｒ＿ｐａｓｓｗｏｒｄ（イーメール＿キャリア＿パスワード）、ｓｍｓ＿ｃａｒｒｉｅｒ（ｓｍｓ＿キャリア）、ｓｍｓ＿ｃａｒｒｉｅｒ＿ｕｓｅｒ（ｓｍｓ＿キャリア＿ユーザ）、ｓｍｓ＿ｃａｒｒｉｅｒ＿ｐａｓｓｗｏｒｄ（ｓｍｓ＿キャリア＿パスワード）、ｐａｐｅｒ＿ｃａｒｒｉｅｒ（ペーパー＿キャリア）、ｐａｐｅｒ＿ｃａｒｒｉｅｒ＿ｕｓｅｒ（ペーパー＿キャリア＿ユーザ）、ｐａｐｅｒ＿ｃａｒｒｉｅｒ＿ｐａｓｓｗｏｒｄ（ペーパー＿キャリア＿パスワード）：「ｘｘｘ＿ｃａｒｒｉｅｒ」（ｘｘｘ＿キャリア）フィールドは、メディア「ｘｘｘ」のために使用されることになるキャリアに関する３文字の識別子を含む。現在の値は次のとおりである：
エクスペダイト（Ｘｐｅｄｉｔｅ）についてＸＰＤ、ＥＤＩポスト（ＥＤＩ  Ｐｏｓｔ）についてＥＤＩ、メッセージリーチ（ＭｅｓｓａｇｅＲｅａｃｈ）についてＭＳＲ、ＳＭＳリーチ（ＳＭＳＲｅａｃｈ）についてＳＭＲ。
「ｘｘｘ＿ｃａｒｒｉｅｒ＿ｕｓｅｒ」（ｘｘｘ＿キャリア＿ユーザ）ならびに「ｘｘｘ＿ｃａｒｒｉｅｒ＿ｐａｓｓｗｏｒｄ」（ｘｘｘ＿キャリア＿パスワード）フィールドは、ファイルをＦＴＰによりキャリアへ転送するときにメッセージ配信システムによって内部的に使用される。異なるキャリアも含めて、このほかの識別子を使用することもできる。
ｆａｘ＿ｑｕａｌｉｔｙ（ファックス＿クオリティ）：ファクシミリに関する出力品質（標準または高画質）。
ｆａｘ＿ｍａｘ＿ｐａｇｅ＿ｓｉｚｅ（ファックス＿マックス＿ページ＿サイズ）：バイトで表したファクシミリ・ページの最大サイズ。
ｆａｘ＿ｃｏｖｅｒ＿ｐａｇｅ（ファックス＿カバー＿ページ）：このアカウントの下に提出されるジョブについて、ファクシミリ・カバー・ページを作成するか否かを示すブール値。
ｆａｘ＿ｃｏｍｐａｎｙ（ファックス＿カンパニ）、ｆａｘ＿ａｄｄｒｅｓｓ＿１（ファックス＿アドレス＿１）、ｆａｘ＿ａｄｄｒｅｓｓ＿２（ファックス＿アドレス＿２）、ｆａｘ＿ａｄｄｒｅｓｓ＿３（ファックス＿アドレス＿３）：これらのフィールド内の会社名およびアドレスが、各ファクシミリのカバー・ページ上にプリントされる。
ｅｍａｉｌ＿ｆｒｏｍ＿ａｄｄｒｅｓｓ（イーメール＿フロム＿アドレス）：メッセージ配信システムが生成した受信者へ届けられている電子メールが到来したと見られる電子メール・アドレス。
ｅｍａｉｌ＿ｔｉｍｅｏｕｔ（イーメール＿タイムアウト）：電子メールの未決が許される最長時間（好ましくはジョブの試行の開始からの時間数）。この時間に達すると、すべての未決の電子メールが成功したと見なされ、次の試行が開始する。
ｅｍａｉｌ＿ｊｏｂ＿ｓｔａｔｕｓ＿ａｄｄｒｅｓｓ（イーメール＿ジョブ＿ステータス＿アドレス）：ジョブ・ステータス・レポートが送信される電子メール・アドレス。
【０２２２】
ＵＳＥＲ＿ＡＣＣＯＵＮＴ＿ＸＲＥＦ（ユーザ＿アカウント＿ＸＲＥＦ）
この「相互参照」エンティティ２６１４は、ＵＳＥＲ（ユーザ）２６１２とＡＣＣＯＵＮＴ（アカウント）２６１６の単一の有効な組み合わせを指定する。各ユーザについて、このエンティティは、ユーザがジョブをメッセージ配信システムへ提出するときにユーザが指定することのできるアカウントを定義する。各アカウントについて、このエンティティ２６１４は、そのエンティティを使用することのできるユーザを定義する。
ｕｓｅｒ＿ａｃｃｏｕｎｔ＿ｘｒｅｆ＿ＰＫ：自動的に生成される一意的な１次鍵。
ｕｓｅｒ＿ＦＫ：ＵＳＥＲ（ユーザ）レコードへのリンク。
ａｃｃｏｕｎｔ＿ＦＫ：ＡＣＣＯＵＮＴ（アカウント）レコードへのリンク。
【０２２３】
ジョブ・キュー
ジョブ・キューは、メッセージ配信システムのリレーショナル・データベース２６００内にテーブルのセットとして存在する。図２５のエンティティ関係図におけるジョブ・キュー・エンティティは次のとおりである：２６１８、２６３２、２６３４、２６４０；２６２０、２６２２、２６２４、２６２６、２６２８、２６３０；および２６３６、２６３８、２６４２、２６４４、２６４６、２６４８、２６５０、および２６５２。
【０２２４】
レコード２６３６、２６３８、２６４２、２６４４、２６４６、２６４８、２６５０、２６５２、２６２０、２６２２、２６２４、２６２６、２６２８、および２６３０は、ジョブ・キューのエントリが作成された後に変更されることはないが、レコード２６１８、２６３２、２６３４、および２６４０は、時々更新されてジョブ処理の状態を示す。
【０２２５】
レコード２６３６、２６３８、２６４２、２６４４、２６４６、２６４８、２６５０、および２６５２は、ジョブ提出時にセットアップされる。標準インターフェースについてはレコード２６２０、２６２２、２６２４、２６２６、２６２８、および２６３０もまた、ジョブ提出時にセットアップされるが、エンタープライズ・インターフェースの場合には、そのジョブが最初に具体化され、いくつかのジョブにわたって維持されるとき、メッセージ配信システム・サポート・チームによってセットアップされることがある。
【０２２６】
ＪＯＢ（ジョブ）
ジョブ・キュー階層構造のトップは、ＪＯＢ（ジョブ）レコード２６１８である。これはキュー内の各ジョブについて１つ存在し、ＪＯＢ（ジョブ）レコード２６１８は、１つのジョブに関連するすべての情報のための「アンカー」レコードを有する。
ｊｏｂ＿ＰＫ（ジョブ＿ＰＫ）：ｊｏｂｉｄは、メッセージ配信システムによって生成される数字識別子であり、このジョブを一意的に識別する。この識別子は、このジョブに関係する出力上（ジョブ・ステータス・レポート等）に現れ、ユーザがジョブを提出するとき「確認スクリーン」上に表示される。
ｕｓｅｒ‐ｒｅｆｅｒｅｎｃｅ（ユーザ‐リファレンス）：ジョブ用にユーザが作成した名前であり、各種のメッセージ配信システム／請求書発行レポートに含められ、かつユーザが希望する任意のテキストを含むことができる。
ｊｏｂ＿ｃｏｎｆｉｇｕｒａｔｉｏｎ＿ＦＫ（ジョブ＿コンフィグレーション＿ＦＫ）：このジョブに関するＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）レコードへのリンク。
ａｃｃｏｕｎｔ＿ＦＫ（アカウント＿ＦＫ）：このジョブが実行されるアカウントに関するＡＣＣＯＵＮＴ（アカウント）レコードへのリンク。
ｕｓｅｒ＿ＦＫ（ユーザ＿ＦＫ）：このジョブを開始したユーザに関するＵＳＥＲ（ユーザ）レコードへのリンク。
ｓｕｂｍｉｔ＿ｔｉｍｅ（サブミット＿タイム）：ジョブが提出された日時。
ｆａｘ＿ｏｎｌｙ（ファックス＿オンリー）：「定義されたファクシミリ・アドレスを用いてすべての受信者へファクシミリを送信する」を意味する。
ｓｍｓ＿ｏｎｌｙ（ｓｍｓ＿オンリー）：「定義されたＳＭＳアドレスを用いてすべての受信者へＳＭＳを送信する」を意味する。
ｅｍａｉｌ＿ｏｎｌｙ（イーメール＿オンリー）：「定義された電子メール・アドレスを用いてすべての受信者へ電子メールを送信する」を意味する。
ｆａｘ＿ｐｒｅｆｅｒｒｅｄ（ファックス＿プレファード）：「ファクシミリによってすべての受信者へ送信する（ファクシミリ・アドレスが定義されている場合）；できないときは電子メールを用いる」を意味する。
ｅｍａｉｌ＿ｐｒｅｆｅｒｒｅｄ（イーメール＿プレファード）：「電子メールによってすべての受信者へ送信する（電子メール・アドレスが定義されている場合）；できないときはファクシミリを用いる」を意味する。
ｊｏｂ＿ｓｕｂｍｉｓｓｉｏｎ＿ｆｏｌｄｅｒ（ジョブ＿サブミッション＿フォルダ）：各種のジョブ・アーティファクト（テンプレート、受信者ファイル、送信バンドル・ファイル等）がストアされているフォルダの名前。
ｍａｓｔｅｒ＿ｓｔａｔｕｓ（マスタ＿ステータス）：包括的なジョブ・ステータス。
ｍａｓｔｅｒ＿ｃｈａｎｇｅ＿ｔｉｍｅ（マスタ＿チェンジ＿タイム）：最後にｍａｓｔｅｒ＿ｓｔａｔｕｓ（マスタ＿ステータス）が変更された日時。
【０２２７】
ジョブ・コンフィグレーション情報
レコード・タイプＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）２６２０、ＴＥＭＰＬＡＴＥ（テンプレート）２６２４、ＴＥＭＰＬＡＴＥ＿ＡＲＴＩＦＡＣＴ（テンプレート＿アーティファクト）２６２２、ＣＯＮＦＩＧ＿ＤＡＴＡ（コンフィグ＿データ）２６２６、ＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ＿ＲＥＳＯＵＲＣＥ（ジャバ＿マッピング＿クラス＿リソース）２６２８、およびＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ（ジャバ＿マッピング＿クラス）２６３０は、ジョブによって使用される各種のアーティファクトならびにコンフィグレーションを定義する。
【０２２８】
エンタープライズ・インターフェースを使用して提出されるジョブについては、そのジョブがメッセージ配信システム・サポート・チームによって最初にセットアップされるとき、このレコードのクラスタが定義される。レコードのクラスタは、多くのジョブによって使用され、ジョブとジョブの間において変更されない。クラスタは、各種データ・ファイルの内容（テンプレート、イメージ等）を含み、そのそれぞれは、メッセージ配信システム・サポート・チームによって、そのクラスタがセットアップされるときにバイナリ・オブジェクト（ＢＬＯＢ）としてデータベース・レコード内へ「インポート」することができる。
【０２２９】
標準インターフェースを使用して提出されるジョブについては、ジョブの提出時にこのレコードのクラスタが作成され、その特定のジョブに関連する。テンプレートは、このクラスタ内から参照されるが、実際にデータベース自体の中へはストアされない；むしろテンプレートは、フラット・ファイルとして個別に保持される。
【０２３０】
ＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）
このレコード２６２０は、ジョブ・コンフィグレーション・レコード・クラスタのための「アンカー」である。
ｊｏｂ＿ｃｏｎｆｉｇｕｒａｔｉｏｎ＿ＰＫ（ジョブ＿コンフィグレーション＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｄｉｓｐｌａｙ＿ｎａｍｅ（ディスプレイ＿ネーム）：カスタマにとって意味をなすジョブ・コンフィグレーションのための名前であり、ジョブ提出スクリーン（「ジョブ・タイプ」）上においてジョブ・コンフィグレーションを選択するために使用される。このフィールドは、エンタープライズ・インターフェース・ジョブのためにだけ定義される。
ｅｎｔｅｒｐｒｉｓｅ（エンタープライズ）：このジョブ・コンフィグレーションがエンタープライズもしくは標準インターフェースのいずれに適用されるかを示すブール・フラグである。
ｃｕｓｔｏｍｅｒ＿ＦＫ（カスタマ＿ＦＫ）：このジョブ・コンフィグレーションを使用するすべてのジョブを「所有」するＣＵＳＴＯＭＥＲ（カスタマ）レコードに対するリンク。
【０２３１】
ＴＥＭＰＬＡＴＥ（テンプレート）
このレコード２６２４は、テンプレート（すなわち、差し込み可能なマイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）、ＸＳＬ、またはテキスト・ドキュメント、あるいは差し込み可能でないＰＤＦ、ＴＩＦＦ、ＨＴＭＬ、またはポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）フォーマットのドキュメント）を定義する。エンタープライズ・インターフェース・ジョブについては、テンプレート２６２４自体がバイナリ・イメージとしてこのレコードの中に保持される。標準インターフェース・ジョブについては、テンプレート２６２４が、フラット・ファイルとしてデータベース外（ジョブ提出フォルダ内）に保持される。
ｔｅｍｐｌａｔｅ＿ＰＫ（テンプレート＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｆｉｌｅｎａｍｅ（ファイルネーム）：このテンプレートを構成するファイルのファイル名。
ｆｉｌｅｔｙｐｅ（ファイルタイプ）：テンプレートを構成するファイルのファイル・タイプ。
ａｔｔａｃｈ＿ｎａｍｅ（アタッチ＿ネーム）：この名前は、電子メール添付のテンプレートのためにだけ定義され、受信者への送信時に添付ファイルに与えられる名前である（ファイル・タイプを除く）。
ｍｅｄｉａ＿ｔｙｐｅ（メディア＿タイプ）：このテンプレートが適用されるメディアを示す。
ｆｏ＿ｒｅｎｄｅｒｉｎｇ＿ｅｎｇｉｎｅ（ＦＯ＿レンダリング＿エンジン）：これは、ペーパー・テンプレートのためにだけ定義され、メッセージ配信システムによってポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）出力の作成に使用されるＦＯレンダリング・エンジンの名前を含む（現在のところ、ＸＥＰまたはＦＯＰ）。
ｊｏｂ＿ｃｏｎｆｉｇｕｒａｔｉｏｎ＿ＦＫ（ジョブ＿コンフィグレーション＿ＦＫ）：ＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）に対するリンク。
ｃｏｍｐｏｎｅｎｔ＿ｔｙｐｅ（コンポーネント＿タイプ）：このテンプレートが、最終的な受信者メッセージのいずれのコンポーネントを定義しているかを示す。ファクシミリについては、これを「件名」もしくは「その他」とすることができる。電子メールについては、これを「件名」、「本文」、または「添付」とすることができる。ペーパーおよびＳＭＳについては定義されていない。
ｃｏｍｐｏｎｅｎｔ＿ｓｅｑｕｅｎｃｅ（コンポーネント＿シーケンス）：ｃｏｍｐｏｎｅｎｔ＿ｔｙｐｅ（コンポーネント＿タイプ）が「添付」でない場合に定義されるコンポーネントの連続番号である。このフィールドは、メッセージ内におけるこの添付のシーケンス番号を表す。たとえば、４つの添付のある電子メール・メッセージのための電子メール添付は、１、２、３、および４という番号が付けられる。
ｔｅｍｐｌａｔｅ（テンプレート）このフィールドは、エンタープライズ・インターフェース・テンプレートにだけ有効であり、テンプレート自体を含む。（標準インターフェース・ジョブについては、ジョブ提出フォルダ内のフラット・ファイル内にテンプレートが維持される。）
【０２３２】
ＴＥＭＰＬＡＴＥ＿ＡＲＴＩＦＡＣＴ（テンプレート＿アーティファクト）
このレコード２６２２は、このＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）２６２０内のＴＥＭＰＬＡＴＥ（テンプレート）レコード２６２４によって使用されるイメージならびにそのほかのマルチメディア・ファイルを示す。このレコードは、エンタープライズ・インターフェース・ジョブのために定義される（ＸＳＬテンプレートを使用する）。
ｔｅｍｐｌａｔｅ＿ａｒｔｉｆａｃｔ＿ＰＫ（テンプレート＿アーティファクト＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｆｉｌｅｎａｍｅ（ファイルネーム）：このアーティファクトがインポートされたファイルのファイル名。
ｆｉｌｅｔｙｐｅ（ファイルタイプ）：このアーティファクトがインポートされたファイルのファイルタイプ（通常、ＧＩＦまたはＪＰＧ）。
ｊｏｂ＿ｃｏｎｆｉｇｕｒａｔｉｏｎ＿ＦＫ（ジョブ＿コンフィグレーション）＿ＦＫ：ＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）レコードへのリンク。
ａｒｔｉｆａｃｔ（アーティファクト）：アーティファクト自体を含む。
【０２３３】
ＣＯＮＦＩＧ＿ＤＡＴＡ（コンフィグ＿データ）
レコード２６２６は、メディア・タイプに固有のコンフィグレーション・データを含んでいる。このレコードは、ペーパーのために使用され、いずれの給紙ビンを使用するか、両面プリントか否かといった情報を含む。このレコードは、エンタープライズ・インターフェース・ジョブ用に定義される。
ｃｏｎｆｉｇ＿ｄａｔａ＿ＰＫ（コンフィグ＿データ＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｆｉｌｅｎａｍｅ（ファイルネーム）：このコンフィグレーション・データがインポートされたファイルのファイル名。
ｆｉｌｅｔｙｐｅ（ファイルタイプ）：このコンフィグレーション・データがインポートされたファイルのファイルタイプ（通常、ＴＸＴ）。
ｍｅｄｉａ＿ｔｙｐｅ（メディア＿タイプ）：このコンフィグレーション・データが適用されるメディアを示す。
ｊｏｂ＿ｃｏｎｆｉｇｕｒａｔｉｏｎ＿ＦＫ（ジョブ＿コンフィグレーション＿ＦＫ）：ＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）レコードへのリンク。
ｃｏｎｆｉｇｕｒａｔｉｏｎ（コンフィグレーション）：コンフィグレーション・データ自体。図２６は、ＥＤＩ  Ｐｏｓｔ（ＥＤＩポスト）へ提出されるペーパー・ジョブに関する代表的なコンフィグレーション２７００の一例を示している。
【０２３４】
ＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ（ジャバ＿マッピング＿クラス）
このレコード２６３０は必須であり、受信者ファイルをＸＭＬへ変換するために使用するジャバ（Ｊａｖａ）クラスを含んでいる（可能性としては、１ないしは複数のＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ＿ＲＥＳＯＵＲＣＥ（ジャバ＿マッピング＿クラス＿リソース）レコードを使用する）。標準インターフェース・ジョブは、ＣＳＶフォーマットされた受信者ファイルを使用し、したがってそれらのジョブは、「ＣＳＶＭａｐｐｉｎｇ．ｃｌａｓｓ」（ＣＳＶマッピング．クラス）と呼ばれる標準ジャバ（Ｊａｖａ）マッピング・クラスを使用する。
ｊａｖａ＿ｍａｐｐｉｎｇ＿ｃｌａｓｓ＿ＰＫ（ジャバ＿マッピング＿クラス＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｆｉｌｅｎａｍｅ（ファイルネーム）：このジャバ（Ｊａｖａ）クラスがインポートされたファイルのファイル名。
ｆｉｌｅｔｙｐｅ（ファイルタイプ）：このジャバ（Ｊａｖａ）クラスがインポートされたファイルのファイルタイプ（通常、ＣＬＡＳＳ）。
ｊｏｂ＿ｃｏｎｆｉｇｕｒａｔｉｏｎ＿ＦＫ（ジョブ＿コンフィグレーション＿ＦＫ）：ＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）レコードへのリンク。
ｃｌａｓｓ（クラス）：このジャバ（Ｊａｖａ）クラスを含む。
【０２３５】
ＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ＿ＲＥＳＯＵＲＣＥ（ジャバ＿マッピング＿クラス＿リソース）
このレコード２６２８はオプションであり、受信者リスト情報を再フォーマットするためにジャバ（Ｊａｖａ）マッピング・クラスによって使用されるリソース・オブジェクトを含む。レコード２６２８は、任意タイプのリソース、たとえば、ほかのジャバ（Ｊａｖａ）クラス、ＸＭＬスタイルシート、あるいはＸＦｌａｔ（Ｘフラット）言語のステートメント（「ＸＭＬ  Ｃｏｎｖｅｒｔ」（ＸＭＬコンバート）プロダクトへの入力用）を含むことができる。
ｊａｖａ＿ｍａｐｐｉｎｇ＿ｃｌａｓｓ＿ｒｅｓｏｕｒｃｅ＿ＰＫ（ジャバ＿マッピング＿クラス＿リソース＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｆｉｌｅｎａｍｅ（ファイルネーム）：このＸＦｌａｔ（Ｘフラット）マッピング・データがインポートされたファイルのファイル名。
ｆｉｌｅｔｙｐｅ（ファイルタイプ）：このＸＦｌａｔ（Ｘフラット）マッピング・データがインポートされたファイルのファイルタイプ。
ｊｏｂ＿ｃｏｎｆｉｇｕｒａｔｉｏｎ＿ＦＫ（ジョブ＿コンフィグレーション＿ＦＫ）：ＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）レコードへのリンク。
ｒｅｓｏｕｒｃｅ＿ｄａｔａ（リソース＿データ）：このリソース自体を含む。
【０２３６】
図２７は、このレコード内にストアすることのできるリソースの１つのタイプの一例２８００を示している。ＸＦｌａｔ（Ｘフラット）ステートメントは、ＣＳＶファイルをＸＭＬへ変換する。このＣＳＶファイルは、レコードごとに３つのフィールド、すなわち「ｒｅｆｎｏ」（レフナンバ）、「ｎａｍｅ」（ネーム）、および「ｓａｌａｒｙ」（サラリー）を含む。
【０２３７】
受信者情報
ＲＥＣＩＰＩＥＮＴ（レシピエント）、ＡＴＴＥＭＰＴ（アテンプト）、ＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション）、ＭＥＲＧＥ＿ＤＡＴＡ（マージ＿データ）、ＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）、ＰＡＰＥＲ＿ＡＤＤＲＥＳＳ＿ＰＡＲＳＥＤ（ペーパー＿アドレス＿パーズド）、ＰＡＰＥＲ＿ＡＤＤＲＥＳＳ＿ＵＮＰＡＲＳＥＤ（ペーパー＿アドレス＿アンパーズド）、ＰＨＯＮＥ＿ＮＵＭＢＥＲ（フォン＿ナンバ）、およびＥＭＡＩＬ＿ＡＤＤＲＥＳＳ（イーメール＿アドレス）レコード、すなわち、それぞれ２６３６、２６３８、２６４０、２６４２、２６４４、２６５２、２６５０、２６４８、２６４６として示されているレコードは、１つのジョブに関する受信者情報を定義する。
【０２３８】
ＲＥＣＩＰＩＥＮＴ（レシピエント）
それぞれのレコード２６３６は、１人の受信者を表す。
ｒｅｃｉｐｉｅｎｔ＿ＰＫ（レシピエント＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｊｏｂ＿ＦＫ（ジョブ＿ＦＫ）：このジョブのためのＪＯＢ（ジョブ）レコードへのリンク。
ｔｉｔｌｅ（タイトル）：受信者の敬称（Ｍｒ、Ｍｒｓ、Ｄｒ等）。
ｆｉｒｓｔ＿ｎａｍｅ（ファースト＿ネーム）：受信者の名。
ｌａｓｔ＿ｎａｍｅ（ラスト＿ネーム）：受信者の姓。
ｕｓｅｒ＿ｄａｔａ（ユーザ＿データ）：ユーザ定義データ・フィールドであり、通常、ユーザの見方からこの受信者を識別するために使用される。
【０２３９】
ＡＴＴＥＭＰＴ（アテンプト）
受信者ごとに最大で３つのＡＴＴＥＭＰＴ（アテンプト）レコード２６３８が存在できる。そのそれぞれは、受信者リスト・レコード内に指定されているとおり、１つの「＜ａｔｔｅｍｐｔ＞」（アテンプト）を表す。ＡＴＴＥＭＰＴ（アテンプト）レコード２６３８には、正しい順序でこのレコードにアクセスできるように連続番号が付されている。ＡＴＴＥＭＰＴ（アテンプト）レコードの目的は、それの下にＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション）レコードをグループ化することである。
ａｔｔｅｍｐｔ＿ＰＫ（アテンプト＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｒｅｃｉｐｉｅｎｔ＿ＦＫ（レシピエント＿ＦＫ）：ＲＥＣＩＰＩＥＮＴ（レシピエント）レコードへのリンク。
ｓｅｑ＿ｎｕｍｂｅｒ（セク＿ナンバ）：この試行の連続番号（１、２、または３）。
【０２４０】
ＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション）
受信者ごとに最大で３つのＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション）レコード２６４０が存在できる。そのそれぞれは、受信者リスト・レコード内の「＜ａｔｔｅｍｐｔ＞」（アテンプト）エレメント内に指定されている送信を表す。ＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション）レコード２６４０は、正しい順序でこのレコードにアクセスできるように連続番号が付されている。最初のレコード（常に、連続番号「１」）は、マスタ送信（失敗したときにはリダイレクションをもたらす）を表す。
【０２４１】
次に示すフィールドは、ジョブがジョブ・キュー内に入れられたときにセットアップされる。
ｔｒａｎｓｍｉｓｓｉｏｎ＿ＰＫ（トランスミッション＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｄｅｓｔｉｎａｔｉｏｎ＿ＦＫ（ディスティネーション＿ＦＫ）：ＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）レコードへのリンク。
ａｔｔｅｍｐｔ＿ＦＫ（アテンプト＿ＦＫ）：ＡＴＴＥＭＰＴ（アテンプト）レコードへのリンク。
ａｃｃｏｕｎｔ＿ＦＫ（アカウント＿ＦＫ）：このジョブに関するＡＣＣＯＵＮＴ（アカウント）レコードへのリンク。
ｒｅｃｉｐｉｅｎｔ＿ＦＫ（レシピエント＿ＦＫ）：ＲＥＣＩＰＩＥＮＴ（レシピエント）レコードへのリンク。
ｔｒａｎｓｍｉｓｓｉｏｎ＿ｂｕｎｄｌｅ＿ＦＫ（トランスミッション＿バンドル＿ＦＫ）：ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＢＵＮＤＬＥ（トランスミッション＿バンドル）レコードへのリンク。
ｊｏｂ＿ＦＫ（ジョブ＿ＦＫ）：このジョブのためのＪＯＢ（ジョブ）レコードへのリンク。
ａｔｔｅｍｐｔ＿ｎｏ（アテンプト＿ナンバ）：試行の番号。
ｓｅｑ＿ｎｕｍｂｅｒ（セク＿ナンバ）：この送信の連続番号（１、２、または３）。
ｓｔａｔｅ（ステート）：この送信が「試行されていない」（ＩＮＡＣＴＩＶＥ（イナクティブ））、「成功して完了」（つまり、ＯＫ）、あるいは「失敗して完了」（つまりエラー・コード）のいずれであるかを示す。
【０２４２】
残りのフィールドは、送信が試行されてからセットアップされ、その送信の成功／失敗に関する情報を含む。
ｊｏｂ＿ｒｅｆｅｒｅｎｃｅ（ジョブ＿リファレンス）：ジョブに関するユーザの参照ＩＤ。
ｕｓｅｒ＿ｄａｔａ：この受信者に関するユーザの参照ＩＤ。
ｄｅｓｔｉｎａｔｉｏｎ＿ａｄｄｒｅｓｓ（ディスティネーション＿アドレス）：この送信が送られる電話番号、電子メール・アドレス、あるいはペーパー・アドレス。
ｄａｔｅ＿ｔｉｍｅ＿ｊｏｂ＿ｓｕｂｍｉｔｔｅｄ（デート＿タイム＿ジョブ＿サブミッテッド）：ジョブが提出された日時。
ｄａｔｅ＿ｔｉｍｅ＿ｍｅｓｓａｇｅ＿ｄｅｌｉｖｅｒｅｄ（デート＿タイム＿メッセージ＿デリバード）：メッセージが受信者へ配信された日時。
ｃａｒｒｉｅｒ＿ｎａｍｅ（キャリア＿ネーム）：キャリアの名前（エクスペダイト（Ｘｐｅｄｉｔｅ）等）。
ｃａｒｒｉｅｒ＿ｒｅｆｅｒｅｎｃｅ＿ｉｄ（キャリア＿リファレンス＿ｉｄ）：キャリアの参照ＩＤ（たとえば、エクスペダイト（Ｘｐｅｄｉｔｅ）のジョブ番号）。
ｍｅｄｉｕｍ（メディア）：この送信が送られるメディア（ｆａｘ（ファックス）、ｐａｐｅｒ（ペーパー）等）
ｓｉｚｅ＿ｏｆ＿ｍｅｓｓａｇｅ（サイズ＿オブ＿メッセージ）：バイトを用いて表したメッセージの合計サイズ。
ｄｅｓｔｉｎａｔｉｏｎ＿ｃｏｕｎｔｒｙ（ディスティネーション＿カントリ）：メッセージが配信された国または地域。
ｄｅｌｉｖｅｒｙ＿ｓｕｃｃｅｓｓ＿ｆａｉｌｕｒｅ＿ｃｏｄｅ（デリバリ＿サクセス＿フェイラー＿コード）：送信の成功または失敗の理由を示すキャリアのコード。
【０２４３】
ＭＥＲＧＥ＿ＤＡＴＡ（マージ＿データ）
受信者レコードからの差し込みデータ２６４２は、ここにＸＭＬテキスト形式でストアされる。
ｍｅｒｇｅ＿ｄａｔａ＿ＰＫ（マージ＿データ＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｒｅｃｉｐｉｅｎｔ＿ＦＫ（レシピエント＿ＦＫ）：ＲＥＣＩＰＩＥＮＴ（レシピエント）レコードへのリンク。
ｍｅｒｇｅ＿ｄａｔａ（マージ＿データ）：差し込みデータ自体をＸＭＬフォーマット済みテキストの文字列として含む。
【０２４４】
ＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）
各受信者について、それぞれのメディアごとにＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）レコード２６４４が存在する（つまり、最大で４つ）。このレコードは「メディアＩＤ」（ファクシミリ、ペーパー、ＳＭＳ、または電子メールを示す）を含み、次に示すレコード・タイプの１つである単一の「サブレコード」を「ポイントする」。
ｄｅｓｔｉｎａｔｉｏｎ＿ＰＫ（ディスティネーション＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｒｅｃｉｐｉｅｎｔ＿ＦＫ（レシピエント＿ＦＫ）：ＲＥＣＩＰＩＥＮＴ（レシピエント）レコードへのリンク。
ｍｅｄｉａ＿ｔｙｐｅ（メディア＿タイプ）：このディスティネーションが表すメディアを示し、それによって探すべき宛先アドレスのタイプ（後述）を示す。
【０２４５】
ＰＡＰＥＲ＿ＡＤＤＲＥＳＳ＿ＰＡＲＳＥＤ（ペーパー＿アドレス＿パーズド）
このレコード２６５２は、パーズ未済のペーパー宛先アドレスを含む。
ｐａｐｅｒ＿ａｄｄｒｅｓｓ＿ｐａｒｓｅｄ＿ＰＫ（ペーパー＿アドレス＿パーズド＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｄｅｓｔｉｎａｔｉｏｎ＿ＦＫ（ディスティネーション＿ＦＫ）：ＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）レコードへのリンク。
ｓｔｒｅｅｔ＿ａｄｄｒｅｓｓ（ストリート＿アドレス）：ストリート番号および名前。
ｓｕｂｕｒｂ（サバーブ）：郊外
ｓｔａｔｅ（ステート）：州
ｐｏｓｔｃｏｄｅ（ポストコード）：郵便コード。
ｃｏｕｎｔｒｙ（カントリ）：国。
【０２４６】
ＰＡＰＥＲ＿ＡＤＤＲＥＳＳ＿ＵＮＰＡＲＳＥＤ（ペーパー＿アドレス＿アンパーズド）
このレコード２６５０は、パーズ済みのペーパー宛先アドレスを含む。
ｐａｐｅｒ＿ａｄｄｒｅｓｓ＿ｕｎｐａｒｓｅｄ＿ＰＫ（ペーパー＿アドレス＿アンパーズド＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｄｅｓｔｉｎａｔｉｏｎ＿ＦＫ（ディスティネーション＿ＦＫ）：ＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）レコードへのリンク。
ａｄｄｒｅｓｓ＿ｌｉｎｅ＿１（アドレス＿ライン＿１）：アドレスの１行目。
ａｄｄｒｅｓｓ＿ｌｉｎｅ＿２（アドレス＿ライン＿２）：アドレスの２行目。
ａｄｄｒｅｓｓ＿ｌｉｎｅ＿３（アドレス＿ライン＿３）：アドレスの３行目。
ａｄｄｒｅｓｓ＿ｌｉｎｅ＿４（アドレス＿ライン＿４）：アドレスの４行目。
ａｄｄｒｅｓｓ＿ｌｉｎｅ＿５（アドレス＿ライン＿５）：アドレスの５行目。
ａｄｄｒｅｓｓ＿ｌｉｎｅ＿６（アドレス＿ライン＿６）：アドレスの１行目。
【０２４７】
ＰＨＯＮＥ＿ＮＵＭＢＥＲ（フォン＿ナンバ）
このレコード２６４８は、電話番号を含む（すなわち、ＳＭＳまたはファクシミリ用の宛先アドレス）。
ｐｈｏｎｅ＿ｎｕｍｂｅｒ＿ＰＫ（フォン＿ナンバ＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｄｅｓｔｉｎａｔｉｏｎ＿ＦＫ（ディスティネーション＿ＦＫ）：ＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）レコードへのリンク。
ｃｏｕｎｔｒｙ＿ｃｏｄｅ（カントリ＿コード）：国コード。
ａｒｅａ＿ｃｏｄｅ（エリア＿コード）：エリア・コード。
ｌｏｃａｌ＿ｎｕｍｂｅｒ（ローカル＿ナンバ）：電話番号の残りの部分。
【０２４８】
ＥＭＡＩＬ＿ＡＤＤＲＥＳＳ（イーメール＿アドレス）
このレコード２６４６は、電子メール宛先アドレスを含む。
ｅｍａｉｌ＿ａｄｄｒｅｓｓ＿ＰＫ（イーメール＿アドレス＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｄｅｓｔｉｎａｔｉｏｎ＿ＦＫ（ディスティネーション＿ＦＫ）：ＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）レコードへのリンク。
ｅｍａｉｌ＿ａｄｄｒｅｓｓ（イーメール＿アドレス）：電子メール・アドレス
ｉｓ＿ｖａｌｉｄ（イズ＿バリッド）：アドレス・シンタクスが有効か否かを示すブール値。
【０２４９】
送信バンドル情報
メッセージ配信システムが特定のジョブの送信の試行を処理するとき、システムは、受信者を、それぞれが特定のメディアにターゲットされた「送信バンドル」に分類する。各送信バンドルは、キャリアへ送信され、その送信の顛末が最終的にキャリアからメッセージ配信システムへ返される。ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＢＵＮＤＬＥ（トランスミッション＿バンドル）レコード２６３２は、それぞれの送信バンドルについて作成され、そのステータスの追跡に使用される。
【０２５０】
ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＢＵＮＤＬＥ（トランスミッション＿バンドル）
それぞれの送信バンドルについて１つのＴＲＡＮＳＭＩＳＳＩＯＮ＿ＢＵＮＤＬＥ（トランスミッション＿バンドル）レコード２６３２が存在する。このレコード２６３２は、バンドル自体が作成されるときに作成され、最終的にこのジョブがデータベースから削除されるときに削除される。
ｔｒａｎｓｍｉｓｓｉｏｎ＿ｂｕｎｄｌｅ＿ＰＫ（トランスミッション＿バンドル＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｊｏｂ＿ＦＫ（ジョブ＿ＦＫ）：このジョブのためのＪＯＢ（ジョブ）レコードへのリンク。
ａｔｔｅｍｐｔ（アテンプト）：この試行の連続番号（１、２、または３）。
ｍｅｄｉａ＿ｔｙｐｅ（メディア＿タイプ）：この送信バンドルに予定されているメディアを示す。
ｃｒｅａｔｉｏｎ＿ｔｉｍｅ（クリエーション＿タイム）：このレコードが作成された日時。
ｂｕｎｄｌｅ＿ｓｔａｔｕｓ（バンドル＿ステータス）：この送信バンドルの処理状態。セクション５．３．１を参照されたい。
ｓｔａｔｕｓ＿ｃｈａｎｇｅ＿ｔｉｍｅ（ステータス＿チェンジ＿タイム）：ｂｕｎｄｌｅ＿ｓｔａｔｕｓ（バンドル＿ステータス）が最後に変更された日時。
【０２５１】
ＣＡＲＲＩＥＲ＿ＲＥＦＥＲＥＮＣＥ（キャリア＿リファレンス）
特定のメディア・タイプならびにジョブＩＤに関してキャリアへ送信されるそれぞれの送信バンドル・ファイルごとに１つのＣＡＲＲＩＥＲ＿ＲＥＦＥＲＥＮＣＥ（キャリア＿リファレンス）レコード２６３４が存在する。このレコード２６３４は、送信バンドル・ファイル自体が作成されるときに作成され、最終的にこのジョブがデータベースから削除されるときに削除される。
【０２５２】
ほとんどの場合において、１回の試行は、メディア・タイプごとに１つの送信バンドル・ファイルを作成するだけであるが、場合によっては（たとえば、エクスペダイト（Ｘｐｅｄｉｔｅ）が予定されており、かつ１０Ｍバイトを超えるファクシミリ送信バンドル・ファイルの場合）ファイルがいくつかの別々のファイルに分割されることがある。この理由から、場合によっては１つのＴＲＡＮＳＭＩＳＳＩＯＮ＿ＢＵＮＤＬＥ（トランスミッション＿バンドル）レコード２６３２に対していくつかのＣＡＲＲＩＥＲ＿ＲＥＦＥＲＥＮＣＥ（キャリア＿リファレンス）レコード２６３４が存在することがある。
ｃａｒｒｉｅｒ＿ｒｅｆｅｒｅｎｃｅ＿ＰＫ（キャリア＿リファレンス＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｔｒａｎｓｍｉｓｓｉｏｎ＿ｂｕｎｄｌｅ＿ＦＫ（トランスミッション＿バンドル＿ＦＫ）：ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＢＵＮＤＬＥ（トランスミッション＿バンドル）レコードへのリンク。
ｃａｒｒｉｅｒ＿ｉｄ（キャリア＿ｉｄ）：この送信バンドル・ファイルを一意的に表すためにキャリアによって供給される識別子。メッセージ配信システムは、この識別子を使用してキャリアからフィードバック情報のポーリングを行うことができる。このフィールドのフォーマットは、キャリアごとに多様となる。
ｔｒａｎｓｍｉｓｓｉｏｎ＿ｂｕｎｄｌｅ＿ｆｉｌｅｎａｍｅ（トランスミッション＿バンドル＿ファイルネーム）：送信バンドル・ファイルのファイル名。
ｓｔａｔｕｓ＿ｃｏｌｌｅｃｔｅｄ（ステータス＿コレクテッド）：この送信バンドル・ファイルに関するキャリア・ステータス・レポートがキャリアから受信されたか否かを示すブール値。「真」にセットされている場合には、情報が受信済みであり、かつＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション）レコードへ適用済みである。
【０２５３】
その他
ＮＵＭＢＥＲ＿ＧＥＮＥＲＡＴＯＲ（ナンバ＿ジェネレータ）
これは、新しいジョブへ一意的なジョブＩＤを割り付け、そのほかのレコードへ一意的なレコード鍵を割り付ける単集合レコード２６５４である。
ｎｕｍｂｅｒ＿ｇｅｎｅｒａｔｏｒ＿ＰＫ（ナンバ＿ジェネレータ＿ＰＫ）：自動的に生成される一意的な１次鍵。
ｊｏｂ＿ｎｕｍｂｅｒ（ジョブ＿ナンバ）：次に割り当てられることになるジョブＩＤ。
ｇｅｎｅｒａｌ＿ｎｕｍｂｅｒ（ジェネラル＿ナンバ）：次に割り当てられることになる包括的な番号（ＪＯＢ（ジョブ）レコードを除くすべてのレコード用のレコード鍵として使用される）。
【０２５４】
ＶＩＩＩ．  ジャバ（Ｊａｖａ）マッピング・クラスおよびＸＳＬテンプレート
このメッセージ配信システムは、一般化されたメッセージ処理エンジンとして設計される。このメッセージ配信システム自体の「コア」は、任意タイプのメッセージを任意の宛先へブロードキャストするべく設計されている。しかしながら、それぞれのメッセージ配信システムのカスタマの「ジョブ・タイプ」（「ジョブ・コンフィグレーション」と呼ばれることもある）は、特別な処理特性を有している。それらは、次に示す２つのカテゴリに分けることができる。
・  カスタマから受け取った受信者ファイルの妥当性検査ならびに再フォーマット、および
・  テンプレート内の差し込みフィールド内へ差し込み値を代入して行う、個別に調整された受信者メッセージの生成。
【０２５５】
これらのカテゴリは、それぞれジャバ（Ｊａｖａ）マッピング・クラス・プロセス、およびテンプレート差し込みプロセスと呼ばれている。これらのプロセス・カテゴリは、いずれもそれぞれのカスタマならびにジョブ・タイプに固有のプロセスを起動し、それぞれについてのプログラム／スタイルシートは、システム上における新しいジョブ・タイプのセットアップのための手続きの一部として開発される。さらに、プログラム／スタイルシートの開発は、メッセージ配信システム自体を開発するチームから分離された開発チームによって行われることが許される。
【０２５６】
図２８は、プロセス・パス２９００がメッセージ配信システムの「コア」２９１０からジャバ（Ｊａｖａ）マッピング・クラス２９３０およびテンプレート２９４０へ進み、再び戻る態様を例示したジョブの実行フローを示したブロック図である。
【０２５７】
メッセージ配信システムの「コア」２９１０は不変である。システム・ソフトウエア２９１０は、一般化されたプラットフォームを表し、その上で任意タイプのメッセージ配信システムのジョブを実行することができる。カスタマ固有コンポーネント２９３０および２９４０は、それぞれのジョブ・タイプごとに異なる。
【０２５８】
ステップ２９２０においては、ユーザがジョブをシステム・ソフトウエア２９１０へ提出する。ジョブ情報がステップ２９１２において組み立てられる。ジャバ（Ｊａｖａ）マッピング・クラス２９３０の場合には、ステップ２９３２において受信者リストの妥当性検査が行われる。続いて、この受信者リストがステップ２９３４においてマップされる。その後、プロセスがシステム・ソフトウエア２９１０へと続き、そのときステップ２９１４においてジョブが開始される。ステップ２９１６においては、次の受信者の差し込みデータが獲得される（「ｇｅｔ」（ゲット））。テンプレート２９４０は、その受信者の差し込み値をテンプレートの差し込みフィールドへ代入する。これらのメッセージは、ステップ２９１８において受信者へ送信される；またステップ２９１６において、次の受信者の差し込みデータが獲得される。
【０２５９】
ジャバ（Ｊａｖａ）マッピング・クラス
ジャバ（Ｊａｖａ）マッピング・クラス２９３０（データ・コンバータと呼ばれることもある）は、メッセージ配信システム２９００の強力な特徴である。このクラス２９３０は、任意のフォーマットを用いてカスタマの受信者データをメッセージ配信システムへ供給することを可能にする。ジャバ（Ｊａｖａ）マッピング・クラス２９３０は、特定のカスタマのジョブに対して調整されるメッセージ配信システム２９１０自体の分離された付属物である。クラス２９３０は、すべてのカスタマの受信者リストを、セクションＶＩの中で述べたとおり、メッセージ配信システムの標準フォーマットへ変換する。またクラス２９３０は、カスタマの受信者リストに対する全般的な変更を自動的に行う機能も提供する。たとえばジャバ（Ｊａｖａ）マッピング・クラス２９３０は、『ＮＳＷ内の全受信者に対してはファクシミリによって送信するが、ほかの受信者に対しては電子メールによる』といった全般的な要求を具体化することができる。それぞれのジョブ・タイプ（「ジョブ・コンフィグレーション」と呼ばれることもある）について１つのジャバ（Ｊａｖａ）マッピング・クラス２９３０が存在し、その機能は、カスタマから受け取る受信者ファイルの妥当性検査２９３２、およびメッセージ配信システムの標準受信者リスト・フォーマットへのそれらの変換２９３０である。
【０２６０】
クラス２９３０は、２つの主要なメソッド、すなわち「ｖａｌｉｄａｔｅ」（バリデート）および「ｍａｐ」（マップ）を提供し、これらは必要時にメッセージ配信システムによって呼び出される。ジャバ（Ｊａｖａ）マッピング・クラス２９３０自体は、データベース内（ＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ（ジャバ＿マッピング＿クラス）レコード内）に維持されており、そのクラスが必要とする多様なリソース（すなわち、ＸＦｌａｔ（Ｘフラット）スキーマおよびＸＳＬＴスタイルシート）もまたデータベース内（ＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ＿ＲＥＳＯＵＲＣＥ（ジャバ＿マッピング＿クラス＿リソース）レコード内）に維持されている。
【０２６１】
特殊なジャバ（Ｊａｖａ）マッピング・クラス環境
ジャバ（Ｊａｖａ）マッピング・クラスのクラス・ファイルは、ほかのメッセージ配信システムのクラスのようにＪＡＲファイル内にストアされない；それに代えて、このファイルは、ジョブ・コンフィグレーションの一部としてデータベース内、すなわちＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ（ジャバ＿マッピング＿クラス）レコード内に維持されている。メッセージ配信システムは、このクラス・ファイルの必要時には随時、自動的にこのクラス・ファイルをそのデータベースからメモリ内へ読み込み、その後、ジャバ（Ｊａｖａ）のＣｌａｓｓＬｏａｄｅｒ（クラスローダ）（ここでは「特殊ＣｌａｓｓＬｏａｄｅｒ（クラスローダ）」と呼ぶ）を使用してそのファイルをロードする。
【０２６２】
ジャバ（Ｊａｖａ）仮想マシンは、クラスのロードに使用されるＣｌａｓｓＬｏａｄｅｒ（クラスローダ）によってすべてのクラスを区別する。特定のＣｌａｓｓＬｏａｄｅｒ（クラスローダ）によってロードされたクラスは、そのＣｌａｓｓＬｏａｄｅｒ（クラスローダ）用の「ｃｌａｓｓｐａｔｈ」（クラスパス）上において明確に指定されたほかのクラスにのみアクセスすることができる。ジャバ（Ｊａｖａ）仮想マシンは、別々の「ワールド」に分割される。同一のＣｌａｓｓＬｏａｄｅｒ（クラスローダ）を用いてロードされたすべてのクラスは、互いに直接アクセスすることが可能であるが、１つの「ワールド」内のクラスは、別の「ワールド」内のクラスへ容易にアクセスすることができない。この用語「ワールド」は、このコンセプトを記述するためにここで作り出された用語である。
【０２６３】
このジャバ（Ｊａｖａ）の特徴は、ジャバ（Ｊａｖａ）マッピング・クラスがメッセージ配信システムの「コア」クラスへアクセスすることを制限するために意図的に使用されている。ジャバ（Ｊａｖａ）マッピング・クラスは、メッセージ配信システムの残りとは異なる「ワールド」内において機能する。
・  メッセージ配信システムのコアは、すべての標準ジャバ（Ｊａｖａ）ＳＤＫパッケージ（ｊａｖａ．ｉｏ、ｊａｖａ．ｕｔｉｌ等）ならびにすべてのカスタム開発されたメッセージ配信システムのパッケージへアクセスすることができる。
・  ジャバ（Ｊａｖａ）マッピング・クラスは、すべての標準ジャバ（Ｊａｖａ）ＳＤＫパッケージ（ｊａｖａ．ｉｏ、ｊａｖａ．ｕｔｉｌ等）ならびに特殊ジャバ（Ｊａｖａ）マッピング・クラス・パッケージ（ｃｏｍ．ｓｙｓｔｅｍ．ｍａｐｐｅｒ）だけにアクセスすることができる。
【０２６４】
このようにジャバ（Ｊａｖａ）マッピング・クラスは、メッセージ配信システムから「絶縁」されており、メッセージ配信システムへはまったくアクセスすることができず、したがってメッセージ配信システム自体への対応する変更を必要とすることなく、ジャバ（Ｊａｖａ）マッピング・クラスを強化し、あるいは修正することが可能になる。これは、システムの管理を有意に簡素化し、かつ「なりすまし」のジャバ（Ｊａｖａ）マッピング・クラスからシステムを保護する。
【０２６５】
メッセージ配信システム自体ならびにジャバ（Ｊａｖａ）マッピング・クラスは、同一のジャバ（Ｊａｖａ）仮想マシン内の分離された「島」として可視化することができる。メッセージ配信システムは、「リフレクションＡＰＩ」を使用してジャバ（Ｊａｖａ）マッピング・クラスへ引数を渡す（通常のメソッド起動は役立たない）。
【０２６６】
引数を渡すメカニズムに関し、実際的な例として、エンタープライズ・ジョブに関するジョブ情報（ジョブＩＤ、ジョブ・リファレンス、ジョブ提出フォルダ、および受信者ファイル）がどのようにしてメッセージ配信システムからジャバ（Ｊａｖａ）マッピング・クラスへ渡されるかについて考察する。
【０２６７】
メッセージ配信システムは、すべてのこの情報および追加の情報（単純なストリングおよびほかのメッセージ配信システムが定義したクラスを含む多様なフォーマットでストアされる）を含む「ＥｎｔｅｒｐｒｉｓｅＪｏｂＳｕｂｍｉｓｓｉｏｎ」（エンタープライズジョブサブミッション）と呼ばれるクラスを包含している。自明のストラテジは、このＥｎｔｅｒｐｒｉｓｅＪｏｂＳｕｂｍｉｓｓｉｏｎ（エンタープライズジョブサブミッション）のオブジェクトを単純に、ジャバ（Ｊａｖａ）マッピング・クラス内の「ｓｅｔＪｏｂＳｕｂｍｉｓｓｉｏｎ」（セットジョブサブミッション）メソッドへ渡すことである。これは、ジャバ（Ｊａｖａ）マッピング・クラスのロードに使用されたＣｌａｓｓＬｏａｄｅｒ（クラスローダ）へ供給されるｃｌａｓｓｐａｔｈ（クラスパス）内にこのクラスの定義が含められていないことから、ジャバ（Ｊａｖａ）マッピング・クラスには「ＥｎｔｅｒｐｒｉｓｅＪｏｂＳｕｂｍｉｓｓｉｏｎ」（エンタープライズジョブサブミッション）クラスについての知識がまったくなく、そのために失敗する。要するに、ジャバ（Ｊａｖａ）マッピング・クラスは、それ独自の「ワールド」内のクラスを知っているに過ぎない；このクラスは、メッセージ配信システムの「ワールド」内のクラスについては何も知らない。しかしながら、各ジャバ（Ｊａｖａ）マッピング・クラスは、「ＥｎｔｅｒｐｒｉｓｅＪｏｂＳｕｂｍｉｓｓｉｏｎＤａｔａ」（エンタープライズジョブサブミッションデータ）と呼ばれるクラスを知っている。このクラス定義は、ジャバ（Ｊａｖａ）マッピング・クラス自体の「ワールド」の一部である（したがって、メッセージ配信システムのワールドの一部ではない）。したがって、ジャバ（Ｊａｖａ）マッピング・クラスを起動する前に、メッセージ配信システムは、ＥｎｔｅｒｐｒｉｓｅＪｏｂＳｕｂｍｉｓｓｉｏｎＤａｔａ（エンタープライズジョブサブミッションデータ）のインスタンスを作成し（特殊ＣｌａｓｓＬｏａｄｅｒ（クラスローダ）を使用する）、その「ｓｅｔｔｅｒ」（セッター）メソッドを使用して、必要なデータ（すなわち、ジョブＩＤ、ジョブ・リファレンス、ジョブ提出フォルダ、および受信者ファイル）をこのインスタンス内へ配置する。メッセージ配信システムは、このオブジェクトが別の「ワールド」内に存在することから、リフレクションによってこれらのｓｅｔｔｅｒ（セッター）メソッドを起動しなければならない。続いてメッセージ配信システムは、ジャバ（Ｊａｖａ）マッピング・クラス自体のインスタンスを作成する（この場合にも特殊ＣｌａｓｓＬｏａｄｅｒ（クラスローダ）を使用する）。最後にシステムは、その「ｓｅｔｔｅｒ」（セッター）メソッドの１つを使用してＥｎｔｅｒｐｒｉｓｅＪｏｂＳｕｂｍｉｓｓｉｏｎＤａｔａ（エンタープライズジョブサブミッションデータ）オブジェクトをジャバ（Ｊａｖａ）マッピング・クラス２９３０へ渡す。
【０２６８】
ジャバ（Ｊａｖａ）マッピング・クラス２９３０は、このオブジェクトがそれ自体の「ワールド」内にあり、それが含むすべてのオブジェクトが標準ジャバ（Ｊａｖａ）環境の一部である単純なオブジェクト（ストリング、アレイ、ファイル等）であることから、このオブジェクトへアクセスし、そのオブジェクトを通常の方法に従って、そのメンバ変数の１つの中へストアすることができる。メッセージ配信システムとジャバ（Ｊａｖａ）マッピング・クラス２９３０の間における情報の引き渡しには、いま説明したとおりのテクニックが使用される。
【０２６９】
ジャバ（Ｊａｖａ）マッピング・クラスのメソッド
エンタープライズ・インターフェース・ジョブ用のジャバ（Ｊａｖａ）マッピング・クラスは、ＥｎｔｅｒｐｒｉｓｅＭａｐｐｅｒ（エンタープライズマッパー）クラスを拡張しなければならず（それもまた、Ｍａｐｐｅｒ（マッパー）クラスを拡張する）、またＣｕｓｔｏｍＭａｐｐｅｒ（カスタムマッパー）インターフェースを具体化しなければならない。これは、次の表５に示されているメソッドを必要とする。
【０２７０】
【表５】
2005535013.tif 000011
【０２７１】
受信者の配信プレファレンスを基礎とし、エスカレーションを組み込んだ、複数の配信メディアを経由して単一セットの受信者への情報の大量通信を行うための方法、システム、およびコンピュータ・プログラム・プロダクトについて開示してきた。限られた数の実施態様だけが開示されているが、当業者であれば、この開示に照らして、本発明の範囲ならびに精神から逸脱することなく修正および／または置換を行うことができよう。
【０２７２】
【図面の簡単な説明】
【０２７３】
【図１ａ】本発明の一実施態様に従ってメッセージを取り扱うためのプロセスを例示したフローチャートである。
【図１ｂ】本発明の一実施態様に従ってメッセージを取り扱うためのプロセスを例示したフローチャートである。
【図１ｃ】本発明の一実施態様に従ってメッセージを取り扱うためのプロセスを例示したフローチャートである。
【図１ｄ】本発明の一実施態様に従ってメッセージを取り扱うためのプロセスを例示したフローチャートである。
【図２】本発明の上記実施態様に従った３つの異なるアクセス方法に関するサービス・インターフェースを例示したブロック図である。
【図３】本発明の上記実施態様に従ったプラグイン可能なデータ・ファイル・コンバータを例示したブロック図である。
【図４】本発明の上記実施態様に従ったドキュメント・マージャを例示したブロック図である。
【図５ａ】本発明の上記実施態様に従った受信者用のプレファレンス規則ならびに対応する各受信者用の配信メディアを取り扱うためのプロセスを例示したフローチャートである。
【図５ｂ】本発明の上記実施態様に従った受信者用のプレファレンス規則ならびに対応する各受信者用の配信メディアを取り扱うためのプロセスを例示したフローチャートである。
【図５ｃ】本発明の上記実施態様に従った受信者用のプレファレンス規則ならびに対応する各受信者用の配信メディアを取り扱うためのプロセスを例示したフローチャートである。
【図５ｄ】本発明の上記実施態様に従った受信者用のプレファレンス規則ならびに対応する各受信者用の配信メディアを取り扱うためのプロセスを例示したフローチャートである。
【図６ａ】本発明の上記実施態様に従った受信者プレファレンスを基礎とするエスカレーション処理のためのプロセスを例示した詳細なフローチャートである。
【図６ｂ】本発明の上記実施態様に従った受信者プレファレンスを基礎とするエスカレーション処理のためのプロセスを例示した詳細なフローチャートである。
【図７ａ】本発明の上記実施態様に従って統合されたレポートを生成するためのプロセスを例示したフローチャートである。
【図７ｂ】本発明の上記実施態様に従って統合されたレポートを生成するためのプロセスを例示したフローチャートである。
【図８】本発明の上記実施態様に従って受信者が配信プレファレンスを指定するユーザ・インターフェースのスクリーンショットを示した説明図である。
【図９】本発明の上記実施態様に従った差し込みおよび送信処理の同時性ならびにパイプライニングを例示したブロック図である。
【図１０ａ−１】本発明の上記実施態様に従った受信者リストのＸＭＬスキーマのリスティングである。
【図１０ａ−２】本発明の上記実施態様に従った受信者リストのＸＭＬスキーマのリスティングである。
【図１０ｂ−１】本発明の上記実施態様に従った受信者リストのＸＭＬスキーマのリスティングである。
【図１０ｂ−２】本発明の上記実施態様に従った受信者リストのＸＭＬスキーマのリスティングである。
【図１０ｂ−３】本発明の上記実施態様に従った受信者リストのＸＭＬスキーマのリスティングである。
【図１０ｃ−１】本発明の上記実施態様に従った受信者リストのＸＭＬスキーマのリスティングである。
【図１０ｃ−２】本発明の上記実施態様に従った受信者リストのＸＭＬスキーマのリスティングである。
【図１１】本発明の別の実施態様に従ったメッセージ配信システムのブロック図である。
【図１２】図１１のシステム・エンジンを例示したブロック図である。
【図１３】テンプレートを例示した説明図である。
【図１４】受信者レコード内に含まれているリダイレクション／エスカレーション情報を例示した説明図である。
【図１５】ウェブ・インターフェースの機能を覆う規則を示した表である。
【図１６】実施されると見られるログオン・スクリーンを例示した説明図である。
【図１７】メイン・スクリーンのレイアウトを例示した説明図である。
【図１８】ユーザを閲覧するための管理パネルを例示した説明図である。
【図１９】エンタープライズ・インターフェースのジョブ提出スクリーンを例示した説明図である。
【図２０ａ】ステータス・レポートの一例を示した説明図である。
【図２０ｂ】ステータス・レポートの一例を示した説明図である。
【図２１ａ】ジョブ・コンフィグレーション・パネルを例示した説明図である。
【図２１ｂ】ジョブ・コンフィグレーション・パネルを例示した説明図である。
【図２２】ＦＴＰインターフェースによって提出されることになるメッセージング・ジョブの定義を含むファイルを例示した説明図である。
【図２３ａ】メッセージ配信システムのアーキテクチャを示したブロック図である。
【図２３ｂ】メッセージ配信システムのアーキテクチャを示したブロック図である。
【図２３ｃ】メッセージ配信システムのアーキテクチャを示したブロック図である。
【図２４ａ】ＸＭＬフォーマットを用いた受信者ファイルの一例を示した説明図である。
【図２４ｂ】ＸＭＬフォーマットを用いた受信者ファイルの一例を示した説明図である。
【図２４ｃ】ＸＭＬフォーマットを用いた受信者ファイルの一例を示した説明図である。
【図２５ａ】データベース構造のエンティティ関係図である。
【図２５ｂ】データベース構造のエンティティ関係図である。
【図２６】ペーパー・ジョブに関するコンフィグレーション・パラメータの一例を示した説明図である。
【図２７】ＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ＿ＲＥＳＯＵＲＣＥ（ジャバ＿マッピング＿クラス＿リソース）レコード内のリソースの１つのタイプの一例を示した説明図である。
【図２８】ジョブの実行フローを示したブロック図である。
【図２９】バルク・インターフェース、ウェブ・インターフェース、および共通インターフェースを有するシステムを示したブロック図である。
【図３０ａ】受信者リストＸＭＬスキーマを示した説明図である。
【図３０ｂ】受信者リストＸＭＬスキーマを示した説明図である。
【図３０ｃ】受信者リストＸＭＬスキーマを示した説明図である。
【図３０ｄ】受信者リストＸＭＬスキーマを示した説明図である。
【符号の説明】
【０２７４】
１００  メッセージング・プロセス
１０６  受信者データ・ファイル
１０８  ｊｏｂＤｅｓｃｒｉｐｔｏｒ．ＸＭＬ（ジョブディスクリプタ．ＸＭＬ）
１１０  テンプレート・ドキュメント
１２８  テキスト差し込み
１３０  ＰＤＦ差し込み
１３２  ポストスクリプト（Ｐｏｓｔｓｃｒｉｐｔ）差し込み
１３４  ＨＴＭＬ差し込み
１３６  マイクロソフト・ワード（Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ）差し込み
１３８  受信者データ
２００  サービス・インターフェース
２１０  ウェブ・サービス・インターフェース（ＳＯＡＰ）／外部インターフェース・コンポーネント
２１２  ＦＴＰインターフェース／外部インターフェース・コンポーネント
２１４  ウェブ・グラフィカル・ユーザ・インターフェース／ウェブ・グラフィカル・ユーザ・インターフェース（ブラウザ／ＨＴＭＬベース）／外部インターフェース・コンポーネント
２１６  共通インターフェース／共通インターフェース・コンポーネント
３００  データ変換
３１０  受信者リスト・ファイル
３１２  データ・ファイル・コンバータ
３１４  ＸＭＬ
４００  ドキュメント差し込み
４１０  ＸＭＬ受信者リスト
４１２  ＸＳＬまたはＸＳＬ‐ＦＯテンプレート
４１４  ドキュメント・マージャ・モジュールまたはコンポーネント
４１６  ドキュメント
５００  方法
５１０  受信者データ
６００  エスカレーション・プロセス
７００  プロセス
７１４  受信者データ
８００  ユーザ・インターフェース・コンポーネント
８０２  チェックボックス
８０６  テキスト入力ボックス
９００  インスタンス
９０２  コンポーネント／マージャ・モジュール
９０４  コンポーネント／トランスミッタ・モジュール
９０６  キャリア／コンポーネント
１０００  ＸＭＬ受信者リスト・スキーマ
１１００  メッセージ配信システム／電子メッセージ・ブロードキャスト・システム
１１１０  メッセージ
１１２０  システム・エンジン
１１３０  宛先
１２１０  インターネット・インターフェース
１２２０  アプリケーション／アプリケーション・サーバ／システム・ソフトウエア
１２２２  アプリケーション・ソフトウエア
１２２４  アパッシュ・トムキャット（Ａｐａｃｈｅ  Ｔｏｍｃａｔ）ウェブ・サーバ
１２２６  ジェイボス（ＪＢｏｓｓ）アプリケーション・サーバ
１２２８  ジャバ（Ｊａｖａ）仮想マシン
１２３０  ＪＤＢＣ／ジャバ（Ｊａｖａ）ＪＤＢＣインターフェース
１２３２  ＰＣハードウエア
１２４０  データベース・サーバ
１２４２  ＳＱＬサーバ
１２４４  ＪＤａｔａＣｏｎｎｅｃｔ（ジェイデータコネクト）
１２４６  ＰＣハードウエア
１３００  テンプレート
１４００  受信者レコード
１５００  表
１６００  ログオン・スクリーン
１７００  メイン・スクリーン
１８００  パネル
１９００  ジョブ提出スクリーン
２０００  ジョブ・ステータス・レポート
２１００  ジョブ・コンフィグレーション・パネル
２２００  ジョブ・コントロール・ファイル
２４００  メッセージ配信システム
２４０２  ユーザ
２４０４  ＦＴＰファイル
２４１０  フロント・エンド／フロント・エンド・ロジック
２４１２  モジュール
２４１４  標準インターフェース
２４１６  エンタープライズ・インターフェース
２４２０  バック・エンド
２４２２  ステータス・レポート・モジュール
２４２４  標準ジョブ提出プロセッサ
２４２６  エンタープライズ・ジョブ提出プロセッサ
２４３０  ジョブ・キュー
２４３２  フラックス（Ｆｌｕｘ）／フラックス（Ｆｌｕｘ）イベント／フラックス（Ｆｌｕｘ）モジュール
２４３４  ステータス収集モジュール
２４３６  キャリア・ステータス・レポート／電子メール・ステータス・レポート
２４３８  キャリア・ステータス・レポート／ＳＭＳステータス・レポート
２４４０  キャリア・ステータス・レポート／ペーパー・ステータス・レポート
２４４２  キャリア・ステータス・レポート／ファクシミリ・ステータス・レポート
２４５０  バンドル・プロセッサ
２４５２  モジュール
２４５４  ファクシミリ送信バンドル／モジュール
２４５６  ペーパー送信バンドル／モジュール
２４５８  ＳＭＳ送信バンドル／モジュール
２４６０  モジュール／請求書発行システム／電子メール送信バンドル
２４６２  エクスペダイト（ｅｘｐｅｄｉｔｅ）
２４６４  ＥＤＩポスト（ＥＤＩ  ｐｏｓｔ）
２４６６  ＳＭＳリーチ（ＳＭＳ  ｒｅａｃｈ）
２４６８  メッセージ・リーチ（ｍｅｓｓａｇｅ  ｒｅａｃｈ）
２５００  ファイル
２６００  エンティティ関係図／リレーショナル・データベース
２６１０  カスタマ／ＣＵＳＴＯＭＥＲ（カスタマ）
２６１２  ユーザ
２６１４  アカウント／エンティティ
２６１６  ＡＣＣＯＵＮＴ（アカウント）レコード／アカウント／アカウント・レコード
２６１８  ＪＯＢ（ジョブ）レコード
２６２０  ＪＯＢ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ジョブ＿コンフィグレーション）
２６２２  ＴＥＭＰＬＡＴＥ＿ＡＲＴＩＦＡＣＴ（テンプレート＿アーティファクト）
２６２４  ＴＥＭＰＬＡＴＥ（テンプレート）／テンプレート
２６２６  ＣＯＮＦＩＧ＿ＤＡＴＡ（コンフィグ＿データ）
２６２８  ＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ＿ＲＥＳＯＵＲＣＥ（ジャバ＿マッピング＿クラス＿リソース）
２６３０  ＪＡＶＡ＿ＭＡＰＩＮＧ＿ＣＬＡＳＳ（ジャバ＿マッピング＿クラス）
２６３２  ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＢＵＮＤＬＥ（トランスミッション＿バンドル）レコード
２６３４  ＣＡＲＲＩＥＲ＿ＲＥＦＥＲＥＮＣＥ（キャリア＿リファレンス）レコード
２６３６  ＲＥＣＩＰＩＥＮＴ（レシピエント）レコード
２６３８  ＡＴＴＥＭＰＴ（アテンプト）レコード
２６４０  ＴＲＡＮＳＭＩＳＳＩＯＮ（トランスミッション）レコード
２６４２  ＭＥＲＧＥ＿ＤＡＴＡ（マージ＿データ）レコード
２６４４  ＤＥＳＴＩＮＡＴＩＯＮ（ディスティネーション）レコード
２６４６  ＥＭＡＩＬ＿ＡＤＤＲＥＳＳ（イーメール＿アドレス）レコード
２６４８  ＰＨＯＮＥ＿ＮＵＭＢＥＲ（フォン＿ナンバ）レコード
２６５０  ＰＡＰＥＲ＿ＡＤＤＲＥＳＳ＿ＵＮＰＡＲＳＥＤ（ペーパー＿アドレス＿アンパーズド）レコード
２６５２  ＰＡＰＥＲ＿ＡＤＤＲＥＳＳ＿ＰＡＲＳＥＤ（ペーパー＿アドレス＿パーズド）レコード
２６５４  ＮＵＭＢＥＲ＿ＧＥＮＥＲＡＴＯＲ（ナンバ＿ジェネレータ）レコード／単集合レコード
２７００  コンフィグレーション
２９００  メッセージ配信システム／処理パス
２９１０  システム・ソフトウエア／メッセージ配信システムのコア
２９３０  カスタマ固有コンポーネント／ジャバ（Ｊａｖａ）マッピング・クラス
２９４０  カスタマ固有コンポーネント／テンプレート
３０００  システム
３０１０  バルク・インターフェース
３０１２  ウェブ・インターフェース／ウェブ・ブラウザ・ベースのＨＴＭＬインターフェース／グラフィカル・ユーザ・インターフェース（ブラウザ／ＨＴＭＬベース）
３０２０  共通インターフェース
【図１ａ】
2005535013.tif 000012
【図１ｂ】
2005535013.tif 000013
【図１ｃ】
2005535013.tif 000014
【図１ｄ】
2005535013.tif 000015
【図２】
2005535013.tif 000016
【図３】
2005535013.tif 000017
【図４】
2005535013.tif 000018
【図５ａ】
2005535013.tif 000019
【図５ｂ】
2005535013.tif 000020
【図５ｃ】
2005535013.tif 000021
【図５ｄ】
2005535013.tif 000022
【図６ａ】
2005535013.tif 000023
【図６ｂ】
2005535013.tif 000024
【図７ａ】
2005535013.tif 000025
【図７ｂ】
2005535013.tif 000026
【図８】
2005535013.tif 000027
【図９】
2005535013.tif 000028
【図１０ａ−１】
2005535013.tif 000029
【図１０ａ−２】
2005535013.tif 000030
【図１０ｂ−１】
2005535013.tif 000031
【図１０ｂ−２】
2005535013.tif 000032
【図１０ｂ−３】
2005535013.tif 000033
【図１０ｃ−１】
2005535013.tif 000034
【図１０ｃ−２】
2005535013.tif 000035
【図１１】
2005535013.tif 000036
【図１２】
2005535013.tif 000037
【図１３】
2005535013.tif 000038
【図１４】
2005535013.tif 000039
【図１５】
2005535013.tif 000040
【図１６】
2005535013.tif 000041
【図１７】
2005535013.tif 000042
【図１８】
2005535013.tif 000043
【図１９】
2005535013.tif 000044
【図２０ａ】
2005535013.tif 000045
【図２０ｂ】
2005535013.tif 000046
【図２１ａ】
2005535013.tif 000047
【図２１ｂ】
2005535013.tif 000048
【図２２】
2005535013.tif 000049
【図２３ａ】
2005535013.tif 000050
【図２３ｂ】
2005535013.tif 000051
【図２３ｃ】
2005535013.tif 000052
【図２４ａ】
2005535013.tif 000053
【図２４ｂ】
2005535013.tif 000054
【図２４ｃ】
2005535013.tif 000055
【図２５ａ】
2005535013.tif 000056
【図２５ｂ】
2005535013.tif 000057
【図２６】
2005535013.tif 000058
【図２７】
2005535013.tif 000059
【図２８】
2005535013.tif 000060
【図２９】
2005535013.tif 000061
【図３０ａ】
2005535013.tif 000062
【図３０ｂ】
2005535013.tif 000063
【図３０ｃ】
2005535013.tif 000064
【図３０ｄ】
2005535013.tif 000065
【国際調査報告】
2005535013.tif 000066
2005535013.tif 000067