(57)【要約】１以上の入力デバイスで作成されたメッセージを１以上の通信モードを用いて１以上の受信者へ送信することを容易にする。このような通信モードには、従来の電話や無線電話、ファクシミリ伝送、ページャ、Ｅメール、郵便メールあるいは急便などが含まれうる。アプリケーションプログラムインタフェース（ＡＰＩ）は、メッセージ伝達機能を要求するリモートアプリケーションと実際にそれらの機能を実施するメッセージサーバとの間を仲介する。このＡＰＩは、メッセージルーティング、ステータス情報および様々なその他の機能の大量の要求を自動的に処理することができ、これらの機能を利用して業務の手順化を可能にする。【選択図】図１
2004501419.tif 000002
【特許請求の範囲】
【請求項１】
ａ．メッセージを送信するための複数の形式を含むメッセージサーバであって、メッセージ及び前記送信形式のうちの少なくとも１つの指定を生成するように構成されたリモートアプリケーションに応答し、コンピュータネットワークを介して前記アプリケーションと通信するメッセージサーバと、
ｂ．前記メッセージサーバ上で実行中の記憶された命令を含むアプリケーションプログラムインタフェース（ＡＰＩ）であって、前記アプリケーションから前記メッセージ及び指定を受信し、前記メッセージサーバに該指定に従ったメッセージの送信を行わせるＡＰＩと、
からなるメッセージ伝達システム。
【請求項２】
前記ＡＰＩがＸＭＬ構文を解釈するように構成され、前記指定がＸＭＬ構文で整形された要求として表現される、請求項１のシステム。
【請求項３】
前記メッセージサーバが連絡先データを格納するためのデータベースを含み、前記ＡＰＩが前記アプリケーションからの要求を処理してメンバー及び該メンバーの連絡先データを指定するデータベースレコードを確立するように構成され、前記連絡先データが送信形式を指定する少なくとも１つの連絡方法とその指定された送信形式による前記メンバーとの連絡を容易にするデータとを含み、前記ＡＰＩは前記メッセージサーバに前記連絡先データに従って前記メッセージを送信させる、請求項１のシステム。
【請求項４】
前記メッセージサーバが複数のメンバーの連絡先データを格納するためのデータベースを含み、前記ＡＰＩが前記アプリケーションからの要求を処理し、（ｉ）メンバー及び該メンバーの連絡先データを指定する既存のデータベースレコードにアクセスするか、又は、メンバーでない者について前記アプリケーションから連絡先データを取得するように構成され、前記連絡先データが送信形式を指定した少なくとも１つの連絡方法とその指定された送信形式による前記メンバーとの連絡を容易にするデータとを含み、前記ＡＰＩは前記メッセージサーバに前記連絡先データに従って前記メッセージを送信させる、請求項１のシステム。
【請求項５】
前記ＡＰＩが前記アプリケーションからの要求を処理して複数の既存のデータベースレコードからなる配布リストを作成するようにさらに構成され、前記ＡＰＩは前記メッセージサーバに前記連絡先データに従って前期配布リストのメンバーへメッセージを送信させる、請求項４のシステム。
【請求項６】
前記既存のデータベースレコードが複数の連絡方法を含み、前記ＡＰＩが前記連絡方法のうちの少なくとも１つの指定する前記アプリケーションからの要求を処理するようにさらに構成され、前記ＡＰＩは前記メッセージサーバに前記少なくとも１つの連絡方法に従って前記メンバーへメッセージを送信させる、請求項４のシステム。
【請求項７】
前記ＡＰＩは前記アプリケーションからのステータス要求に応答するようにさらに構成され、前記ＡＰＩはメッセージ伝達タスクを指定するステータス要求に応答して該メッセージ伝達タスクに関連するステータス情報を返す、請求項１のシステム。
【請求項８】
前記ステータス情報は、前記メッセージのステータス指定と、（ｉ）前記メッセージが送信され終わったか否か、（ｉｉ）前記メッセージが無事に受信されたか否か、（ｉｉｉ）前記メッセージが失敗したか否か、及び（ｉｖ）前記メッセージがキャンセルされたか否かを指定するステータス指定とを含む、請求項７のシステム。
【請求項９】
前記ＡＰＩは失敗したメッセージの各々についてその失敗の説明を返す、請求項８のシステム。
【請求項１０】
前記メッセージが少なくとも１つの連絡先へ宛てられ、前記メッセージが質問を含み、前記ＡＰＩは前記メッセージサーバに前記質問を前記少なくとも１つの連絡先へ提出させる、請求項１のシステム。
【請求項１１】
前記ＡＰＩが前記アプリケーションからのステータス要求に応答するようにさらに構成され、前記ＡＰＩは前記メッセージを指定するステータス要求に応答して前記少なくとも１つの連絡先による前記質問に対する何らかの応答を含む前記メッセージに関連するステータス情報を返す、請求項１０のシステム。
【請求項１２】
前記ＡＰＩがオブジェクトの形態の情報を扱うように構成され、前記オブジェクトが（ｉ）前記メッセージの複数の潜在的受信者についてのメンバー情報を指定するメンバーオブジェクトと、（ｉｉ）複数の送信形式に従って前記潜在的受信者と通信することを容易にする情報を指定する連絡先オブジェクトと、（ｉｉｉ）メッセージ及び該メッセージの特徴を指定するジョブオブジェクトと、（ｉｖ）メッセージ配達のモードを指定する配達オブジェクトとを含み、前記アプリケーションは前記メッセージ及び前記指定をオブジェクト形態で提供する、請求項１のシステム。
【請求項１３】
メッセージを送信するための複数の形式を含むメッセージサーバ、及び、コンピュータネットワークを介してリモートアプリケーションと通信するためのインタフェースと共に使用するための、前記メッセージサーバ上で実行中の記憶された命令を含むアプリケーションプログラムインターフェース（ＡＰＩ）であって、メッセージ及び前記通信形式のうちの少なくとも１つの指定を含むアプリケーションによって生成された要求に応答し、前記メッセージサーバに該指定に従ったメッセージの送信を行わせるＡＰＩ。
【請求項１４】
前記実行中の命令がＸＭＬ構文を解釈し、前記メッセージ及び前記指定がＸＭＬ構文で整形された要求として表現される、請求項１３のＡＰＩ。
【請求項１５】
前記メッセージサーバが連絡先データを格納するためのデータベースを含み、前記ＡＰＩが前記アプリケーションからの要求を処理してメンバー及び該メンバーの連絡先データを指定するデータベースレコードを確立するように構成され、前記連絡先データが送信形式を指定する少なくとも１つの連絡方法とその指定された送信形式による前記メンバーとの連絡を容易にするデータとを含み、前記ＡＰＩは前記メッセージサーバに前記連絡先データに従って前記メッセージを送信させる、請求項１３のＡＰＩ。
【請求項１６】
前記メッセージサーバが複数のメンバーの連絡先データを格納するためのデータベースを含み、前記ＡＰＩが前記アプリケーションからの要求を処理し、メンバー及び該メンバーの連絡先データを指定する既存のデータベースレコードにアクセスするように構成され、前記連絡先データが送信形式を指定した少なくとも１つの連絡方法とその指定された送信形式による前記メンバーとの連絡を容易にするデータとを含み、前記ＡＰＩは前記メッセージサーバに前記連絡先データに従って前記メッセージを送信させる、請求項１３のＡＰＩ。
【請求項１７】
前記ＡＰＩが前記アプリケーションからの要求を処理して複数の既存のデータベースレコードからなる配布リストを作成するようにさらに構成され、前記ＡＰＩは前記メッセージサーバに前記連絡先データに従って前記配布リストのメンバーへメッセージを送信させる、請求項１６のＡＰＩ。
【請求項１８】
前記既存のデータベースレコードが複数の連絡方法を含み、前記ＡＰＩが前記連絡方法のうちの少なくとも１つを指定する前記アプリケーションからの要求を処理するようにさらに構成され、前記ＡＰＩは前記メッセージサーバに前記少なくとも１つの連絡方法に従って前記メンバーへメッセージを送信させる、請求項１６のシステム。
【請求項１９】
前記既存の構成が前記アプリケーションからのステータス要求に応答するように構成され、前記ＡＰＩはメッセージ伝達タスクを指定するステータス要求に応答して該メッセージ伝達タスクに関連するステータス情報を返す、請求項１３のＡＰＩ。
【請求項２０】
前記ステータス情報は、前記メッセージのステータス指定と、（ｉ）前記メッセージが送信され終わったか否か、（ｉｉ）前記メッセージが無事に受信されたか否か、（ｉｉｉ）前記メッセージが失敗したか否か、及び、（ｉｖ）前記メッセージがキャンセルされたか否かを指定するステータス指定とを含む、請求項１９のＡＰＩ
【請求項２１】
前記ＡＰＩは失敗したメッセージの各々についてその失敗の説明を返すように構成される、請求項２０のＡＰＩ。
【請求項２２】
前記メッセージが少なくとも１つの連絡先へ宛てられ、前記メッセージが質問を含み、前記ＡＰＩは前記メッセージサーバに前記質問を前記少なくとも１つの連絡先へ提出させる、請求項１３のＡＰＩ。
【請求項２３】
前記実行中の命令が前記アプリケーションからのステータス要求に応答するように構成され、前記ＡＰＩは前記メッセージを指定するステータス要求に応答して前記少なくとも１つの連絡先による前記質問に対する何らかの応答を含む前記メッセージに関連するステータス情報を返す、請求項２２のＡＰＩ。
【請求項２４】
前記実行中の命令がオブジェクトの形態の情報を扱うように構成され、前記オブジェクトが（ｉ）前記メッセージの潜在的受信者についてのメンバー情報を指定するメンバーオブジェクトと、（ｉｉ）複数の送信形式に従って前記潜在的受信者と通信することを容易にする情報を指定する連絡先オブジェクトと、（ｉｉｉ）メッセージ及び該メッセージの特徴を指定するジョブオブジェクトと、（ｉｖ）メッセージ配達のモードを指定する配達オブジェクトとを含み、前記アプリケーションは前記メッセージ及び前記指定をオブジェクト形態で提供する、請求項１３のＡＰＩ。
【請求項２５】
受信者へのメッセージを取り扱い、送信する方法であって、
メッセージを送信するための複数の形式を含み、メッセージ及び前記送信形式のうちの少なくとも１つの指定を生成するように構成されたリモートアプリケーションに応答するメッセージサーバを設けるステップと、
前記メッセージサーバにコンピュータネットワークを介して前記アプリケーションと通信させるステップと、
前記メッセージサーバ上で実行中の記憶された命令を含み、前記アプリケーションから前記メッセージ及び前記指定を受信して前記メッセージサーバに該指定に従ったメッセージの送信を行わせるアプリケーションインタフェース（ＡＰＩ）を設けるステップと、
からなる方法。
【請求項２６】
前記ＡＰＩがＸＭＬ構文を解釈するように構成され、前記指定がＸＭＬ構文で整形された要求として表現される、請求項２５の方法。
【請求項２７】
連絡先データを格納するためのデータベースを設けるステップをさらに含み、前記サーバが前記アプリケーションからの要求を処理してメンバー及び該メンバーの連絡先データを指定するデータベースレコードを確立し、前記連絡先データが送信形式を指定した少なくとも１つの連絡方法とその指定された送信方法による前記メンバーとの連絡を容易にするデータとを含み、前記サーバは前記連絡先データに従って前記メッセージを送信する、請求項２５の方法。
【請求項２８】
複数のメンバーの連絡先データを格納するためのデータベースを設けるステップをさらに含み、前記サーバが前記アプリケーションからの要求を処理してメンバー及び該メンバーの連絡先データを指定する既存のデータベースレコードにアクセスし、前記連絡先データが送信形式を指定した少なくとも１つの連絡方法とその指定された送信方法による前記メンバーとの連絡を容易にするデータとを含み、前記サーバは前記連絡先データに従って前期メッセージを送信する、請求項２５の方法。
【請求項２９】
（ｉ）前記アプリケーションからの要求を処理して複数の既存のデータベースレコードからなる配布リストを作成するステップと、（ｉｉ）前記メッセージを前記連絡先データに従って前記配布リストのメンバーへ送信するステップとをさらに含む、請求項２８の方法。
【請求項３０】
前記既存のデータベースレコードが複数の連絡方法を含み、前記アプリケーションからの要求が前記連絡方法のうちの少なくとも１つを指定し、前記メッセージサーバは前記少なくとも１つの指定された連絡方法に従って前記メッセージを前記メンバーへ送信する、請求項２８の方法。
【請求項３１】
前記アプリケーションからのステータス要求に応答するステップであって、前記サーバがメッセージ伝達タスクを指定するステータス要求に応答して該メッセージ伝達タスクに関連するステータス情報を返すステップをさらに含む、請求項２５の方法。
【請求項３２】
前記ステータス情報は、前記メッセージのステータス指定と、（ｉ）前記メッセージが送信され終わったか否か、（ｉｉ）前記メッセージが無事に受信されたか否か、（ｉｉｉ）前記メッセージが失敗したか否か、及び（ｉｖ）前記メッセージがキャンセルされたか否かを指定するステータス指定とを含む、請求項３２の方法。
【請求項３３】
失敗したメッセージの各々について前期サーバがその失敗の説明を返す、請求項３２の方法。
【請求項３４】
前記メッセージが少なくとも１つの連絡先へ宛てられ、前記メッセージが質問を含み、前記メッセージサーバは前記質問を前記少なくとも１つの連絡先へ提出する、請求項２５の方法。
【請求項３５】
サーバが前記アプリケーションからのステータス要求に応答し、前記サーバは前記メッセージを指定するステータス要求に応答して前記少なくとも１つの連絡先による前記質問に対する何らかの応答を含む前記メッセージに関連するステータス情報を返す、請求項３４の方法。
【請求項３６】
前記ＡＰＩがオブジェクトの形態の情報を扱うように構成され、前記オブジェクトが（ｉ）前記メッセージの複数の潜在的受信者についてのメンバー情報を指定するメンバーオブジェクトと、（ｉｉ）複数の送信形式に従って前記潜在的受信者と通信することを容易にする情報を指定する連絡先オブジェクトと、（ｉｉｉ）メッセージ及び該メッセージの特徴を指定するジョブオブジェクトと、（ｉｖ）メッセージ配達のモードを指定する配達オブジェクトとを含み、前記アプリケーションは前記メッセージ及び前記指定をオブジェクト形態で提供する、請求項２５の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は通信サービスに関するものであり、詳しくは１以上の特定の通信ノードを介してメッセージを選択された受信者まで配達することに関する。
【０００２】
【従来の技術】
技術の向上及び多くの消費者の関心のおかげで通信の新しい形態が普及し、平均的な消費者が多数の通信サービスにアクセスするようになった。かつて選ばれた小数の者に限られていたインターネット及び無線電話は、今や従来の電話サービスを普通に埋め合わせるものになり、同じキャリアから頻繁に供給されている。安価な家庭用コンピュータでさえも、現在ではファクシミリ能力を有している。移動従業員を抱える事業者は、テキスト送信やインターネットアクセスといった先進の機能が組み込まれた経済的なページャを従業員に支給している。
【０００３】
こうした通信オプションの一般化により、アクセス及び利便性が向上した一方、問題も生じている。通信路の存在は、所定の時間にメッセージの受信者がその特定の通信路から「受信」することを保証するものではなく、メッセージの送信者がこれを知るすべはいまだにない。実際、通信トラフィックのチャネルの増加は受信者の注意する必要性が増すことを意味し、Ｅメール、ボイスメール、ページャなどの攻撃に悩まされていると感じている人は、時間によっては通信装置を単に無効にしている場合がある。従ってメッセージの送信者は、自分のメッセージが配達されないリスクを負うか、それとも考えられるすべてのモードの通信方式について苦労してメッセージを再送するかの選択に直面している。
【０００４】
同じメッセージを複数の受信者へ送信することが難しい場合もある。１つのＥメールメッセージは、一回送信すれば無制限の数のあて先へ届けることが可能であるが、電話メッセージは電話のたびに繰り返さなければならない。さらに、異なる受信者は異なる種類の通信路へアクセスする場合があり、受信者によってはＥメールでないと効率的に届かない者、ファックスでないと効率的に届かない者、あるいはページャでないと効率的に届かない者などもありうる。
【０００５】
通信入力デバイスの一体化も複数形態の内容を有するメッセージの可能性を高めている。今日、１つのメッセージは様々な情報源（例えば音声やテキストなど）からの入力を含む場合があり、こうしたメッセージを従来の手段で送信することは極めて厄介であり、複数の個別送信が必要になり、様々な入力を単一のメッセージに収めるあつらえた又は困難な「パッケージ」にならざるをえない。
【０００６】
２０００年２月１日に出願された「Ｍｕｌｔｉ−Ｍｏｄｅ Ｍｅｓｓａｇｅ Ｒｏｕｔｉｎｇ ａｎｄ Ｍａｎａｇｅｍｅｎｔ」と題した米国特許出願第０９／４９６１７０号明細書（その開示全体をここで参照することにより援用する）は、これらの困難に対処するものであり、特に１以上の通信方式により１以上の入力デバイスで作成されたメッセージを１以上の受信者へ送信するための装置を開示している。このような通信装置には、例えば、従来の電話や無線電話、ファクシミリ伝送、ページャ、Ｅメール、郵便メールあるいは急便などが含まれる。従って、メッセージが確実に最も早く受信されるようにするため、１つのメッセージをＥメールやファックスなどの複数の方式で一人の受信者へ宛てて送信したり、１つの方式または異なる方式により複数の受信者へ宛てて送信したり（例えばそのメッセージをＥメールで受信する者もいればファックスで受信する者もあり、あるいは電話で受信する者もいる）することができる。この装置は、様々な配達方式が順番に使用される条件を指定する定義された「エスカレーション」ルールに応じるように構成することができる。例えばこの定義は、Ｅメールによる質問に対して１時間以内に受信者から応答がない場合、その受信者に電話すべきことを示すことができる。さらにエスカレーションルールは、代替の伝送方式の他に、代替の受信者を指定することもできる（もちろんそれらの受信者について代替の方式を指定することもできる）。このエスカレーションルールは、デフォルトの連絡方法を指定することもでき、その連絡方法は特定の個人に適用することもできるし、受信者の一覧に適用することもできる。
【０００７】
’１７０号明細書に開示された発明は、あるメッセージが受信されたか否かを判定する機能（例えば電話やＥメールのポーリング）と共に、受信の確認時における自動送信者通知の機能を含む場合がある。さらに、この発明は、メッセージの受信を確認するためのメッセージのモニタリングに加えて、受信者からの応答を促すこともできる。このように、この発明は、複数の通信モードを利用して複数の質問調査をまとめることができ、例えば、直接連絡を受けた人は直ぐに応答することができるが、その他の人は配達される指示に応じて後で応答することができる。例えば、ウェブサイト経由やフリーダイヤルにより。
【０００８】
’１７０号明細書に開示された発明は、受信者に応答を求める質問が組み込まれたメッセージをサポートしている。このような応答は、受信されたときにそのメッセージの送信者へ伝達されたり、蓄積されたりする。
【０００９】
また、’１７０号明細書に開示された発明により、適当なモードごとのメッセージ配達のスケジューリングも容易になった。スケジューリングには、特定時刻の配達や指定された時間範囲内の配達が含まれ、指定された「除外」時間中に配達を防止することも含まれる場合がある。実施形態によっては、スケジューリングは自動的である場合があり、受信者のタイムゾーン及び通信の形態などの条件に基づく場合がある。
【００１０】
しかしながら’１７０号明細書は、顧客のクライアントコンピュータがワールドワイドウェブ（ウェブ）を介して前述の機能を実行しているサーバと通信するシステムを意図している。即ち、その対話は実質的に手動であり、事実上段階的である。顧客はオプションを選択し、対話セッションにおいて好みを指示する。このモデルは、メッセージ伝達機能に対してより自動化された大量のアクセスが必要とされるビジネス用途には一般的に適さない。
【００１１】
【発明の説明】
発明の簡単な概要
本発明は、’１７０号明細書に開示されるようなメッセージハンドリング機能を用いて、概してインターネットを介した（もちろん必須ではない）対話を容易にするアプリケーションプログラムインタフェース（ＡＰＩ）を提供する。本発明によると、アプリケーションプログラマは、マークアップ言語（ＸＭＬ起源のものが好ましい）を用いて互換性及びメッセージハンドリング機能との通信についてアプリケーションを設定する。このＡＰＩは、メッセージルーティング、ステータス情報及び様々なその他の機能についての大量の要求を自動的に処理する能力があり、これらの機能を利用すると業務を手順化できるようになる。
【００１２】
実際、フレキシブルなメッセージ伝達サービスによって利益を得ることの可能な企業対企業及び企業対顧客の組織の範囲は、事実上無限である。例えば、航空会社はチケットが購入されたときに乗客から連絡先情報を入手することができる。航空会社は、万が一フライトが遅れたりキャンセルされた場合、このメッセージ伝達機能により１つの通知を作成して全ての乗客へ送信することができ、フライト時刻が近づくに従って、定義されたエスカレーションルールに従ってまだ連絡のとれていない乗客へ届ける努力を強めることができる。同様に、クラブやその他の組織は、本ＡＰＩによるメッセージ伝達機能を用いて会議の通知を送信し、メンバーから受信確認及び出欠を受信し、メンバーに変更を知らせることができる。このメッセージは組織により一回だけ書かれ送信されればよく、残りの操作は、大量の再送信から応答の収集・整理まで、自動的に実行される。
【００１３】
本発明によると、メッセージを送信するための複数の形式を含むメッセージサーバがＡＰＩに関連付けられる。アプリケーションは、通常リモートサーバで実行され、メッセージ及び１以上の送信形式の指定を受信するように構成され、さらにＡＰＩとの対話に適合するようになっている。ＡＰＩはこの対話をサポートする記憶された命令を含む。ＡＰＩは、アプリケーションサーバからメッセージ及び指定を受信すると、メッセージサーバにその指定に従ってそのメッセージを送信させる。
【００１４】
【好ましい実施形態の詳細な説明】
１．技術的コンテクスト
本メッセージ伝達システムの機能はサーバ１２５によって実施され、このサーバは活動レベルや組み込まれる機能に応じて単一のワークステーションとして実現することもできるし、サーバコンピュータのネットワークとして実現することもできる。説明のため、サーバ１２５はインターネットに常時接続されたネットワークインタフェースを有する単一のマシンとして表現する。ネットワークインタフェース１２７及びサーバ１２５のその他の内部構成要素はメイン双方向バス１３０（１つのハードウェアデバイスの物理的バスの場合もあるし、ＬＡＮやＷＡＮなどのネットワークを表す場合もある）を介して相互通信する。動作中、サーバ１２５の機能を実行し、顧客、サーバ１２５、インターネット及びその他の形態の通信の間の対話を容易にする命令のメインシーケンスは、大容量記憶装置１３２（ハードディスクや光記憶ユニットなど）及びメインシステムメモリ１３４に内在する。これらの命令の実行及びサーバ１２５の機能の実行は、中央演算処理装置（ＣＰＵ）１３６により行われる。
【００１５】
ＣＰＵ１３６の動作を制御し、サーバ１２５の動作を実行する一群の機能モジュールがシステムメモリ１３４に配置されるように概念的に図示されているが、ここでもこの構成は例示の目的であることを強調しなければならない。ここでも実際には、活動レベル及び組み込まれる能力に応じて、様々なモジュール及びサーバを１つのマシン上で動作する複数のアクティブなプロセスとして実行することができ、機能は複数のマシン（または１つのマシン内の複数のプロセッサ）に分散することもできる。
【００１６】
オペレーティングシステム１４０は、メモリ割当て、ファイル管理及び大容量記憶装置１３２の操作などの低レベルの基本的なシステム機能を管理する。高レベルにおいては、一連の記憶された命令として実施される制御ブロック１４２がサーバの様々な機能構成要素間の対話を管理し、それらの間でのデータの適当なルーティングを保証する。
【００１７】
’１７０号明細書に説明されているように、サーバ１２５はウェブ及び電子メールにより顧客と直接通信することが可能であるが、本出願は主としてハードウェア対ハードウェアの通信に関するものである。従って、ＡＰＩ１４５は外部情報源から情報を受信して処理し、ネットワークインタフェース１２７を介して適当な応答をそれらの情報源へ送信する。ＡＰＩ１４５は、適当に設定されたサードパーティ製のアプリケーションに直接接続するためのプログラム的インタフェースを表している。外部情報源との対話のパターンは、それらの情報源への送信内容も含めて、トランザクションサーバ１５０によって扱われる。トランザクションサーバ１５０は、まとめて符号１５２で示す様々なデータベースへアクセスすることができる。これらのデータベースは通常、装置１３２に格納され、必要に応じてアクセスされる。データベースについては後で詳細に説明する。ＡＰＩ１４５によって受信された要求に応じて、トランザクションサーバ１５０は、収集して指定された連絡先へ送信すべきメッセージを生成し、外部問い合わせ先へ送信するための情報を検索して収集する。クレジットカード認証及び課金のサービスは課金サーバによって扱われる。
【００１８】
顧客と様々なパターンで対話することになるサーバ１２５によって実行される様々な機能についてこれから説明する。
【００１９】
１．１  メディア変換及び基本的なメッセージ送信
まとめて符号１７５で示す一連のメディアサーバは送信用メッセージを整形するためのインタフェースを表しており、これらのメッセージは音声やテキスト（Ｅメール、ウェブまたは郵便メールによる送信用）あるいはその他の所望の形態をとりうる。リモートアプリケーションからＡＰＩ１４５を介してメッセージ及びメディアの指定が受信され、トランザクションサーバ１５０があるメッセージを完全に特定するだけの十分なコマンド及びコンテンツ（即ち、メッセージ本体、受取人、所望の配達方法、及び、配達スケジュールやエスカレーションルールなどのメッセージオプション）を受信すると、メッセージ「ジョブ」が作成され、データベース１５２に格納される。このジョブは、すべてのメッセージジョブの実行及びスケジューリングに責任を負うジョブキューサーバ１６５へ渡される。
【００２０】
この時、そのメッセージは、メッセージが作成されたフォーマットのままである。しかしながら、前述のようにサーバ１２５は、インタフェースサーバを介してメッセージをあるフォーマットで受信し、それらを顧客が選択した異なるフォーマットで送信することが可能である。これらのメディア変換およびメッセージ収集の機能は、まとめて符号１６７で示す専用の一連のメッセージ配達サーバによって実行される。適当なメッセージ配達サーバ１６７はメッセージを指定されたフォーマットに変換し、適当なドライバの中から選択されたデバイスドライバを用い、指定された通信メディアを介してそれらの送信を行う。これらのドライバは一連の送信装置を操作するものであり、送信装置には、Ｅメール及び／又はウェブベースのメッセージ配達用のネットワークインタフェース１２７、電話、ファクシミリ、ページャ又は携帯型無線装置によるメッセージ送信用の電話インタフェース１７０、及び、郵便メールや翌日配達宅配便業者によるメッセージ送信用の文書作成モジュール１７２が含まれる。
【００２１】
メッセージ送信のタイミングは、ジョブキューサーバ１６５によって制御される。ジョブキューサーバ１６５は、顧客のメッセージ送信の認証に応答して今説明した変換及び送信の動作を開始する。ジョブキューサーバ１６５は、メッセージの送信をコンピュータの内部クロックに基づいて顧客が指定した時刻に調整することができるスケジューリングモジュール１８０をさらに含む。
【００２２】
サーバブロック１６５は、顧客が入力したテキストを電話インタフェース１７０により音声で受信者へ送信することができるようにするテキスト／音声変換モジュールを含む場合がある。逆に、電話サーバ１７５を顧客が話したコマンドに応答するように構成し、顧客が電話により（即ち、電話インタフェース１７０を用いてサーバ１２５と通信することにより）メッセージを作成して送信できるようにすることもできる。
【００２３】
さらに複雑な動作モードの場合、サーバ１２５は、同一フォーマットの個別セグメントとして、あるいは、異なるフォーマットにエンコードされたセグメントとして、メッセージの連結を容易にすることもできる。例えば音声メッセージの場合、メッセージ配達サーバ１６７は、顧客のメッセージに音声「ヘッダ」（いわゆる「プロフェッショナルプロンプト」）及び「トレーラ」を付加することができる。従って、受信者がその電話にでたとき、そのメッセージのヘッダ部分によりその受信者が顧客からメッセージを今まさに受信しようとしているところであることを伝えることができ、トレーラ部分により応答が容易になる（以下でさらに詳しく説明する）。
【００２４】
１．２  メッセージ受信の確認
任意の様々な技術を用いて、メッセージが受信されたか否か及び受信された時を判定することが可能である。多くのＥメールシステムは、はじめから受信確認をサポートしている。あるいは、メッセージにＵＲＬを埋め込み、受信者がＥメールを受信してそのＵＲＬをクリックしたときに受信が自動的に記録されるようにすることも可能である。さらに、そのＵＲＬで指定されたウェブページに受信者の応答を促す質問を含め、その後直ぐに受信者がそのウェブページをサーバ１２５へ返送するようにもできる。
【００２５】
印字物の配達は急便を通じてあるいは受信者への追跡電話呼び出しにより追跡することができるが、電話メッセージの場合、受信を確認するために受信者は番号を押すように求められる可能性がある。電話メッセージの場合、その電話にでたのが人間であるか留守番電話であるかを検出することが有用である。例えばこの判定は、適当な音声ヘッダを選択するために使用したり、そのメッセージが受信者や記録装置に配達されたか否かに応じて異なる選択的メッセージを選択するために使用することができる。当然であるが、受信を確認するために番号を押すことを留守番電話に求めることはなく、留守番電話にメッセージが残っていても送信者に配達の確認がなされることはない。応答検出を実施するため、電話サーバ１４７は、いったん接続が確立されるとそのラインのノイズレベルをモニタし、「無音」ノイズレベルと「音声」ノイズレベルとを区別するようにプログラムされている。人間がでた場合、通常短い挨拶が発せられることになる。即ち、人間の返答のパターンは、無音の後短い音声信号が続くものである。これに対して留守番電話の場合、通常長い挨拶（「もしもしスミスです．．．」）が発せられる。電話サーバ１４７は、持続した音声信号及びその直後の無音部分の観測された長さに基づいて、人間がでたか機械がでたかについての最初の推測を行う。人間であることが推測された場合、電話サーバ１４７は、でた者に対してプッシュホン式のボタンを押すことを促す音声ヘッダを再生し、適切なトーンパルスが検出されない場合には、その推測を変更して留守番電話と通信しているものと仮定することができる。
【００２６】
１．３  メッセージのスケジューリング
受信者の居場所において、特定の時間、特定のモードによるメッセージの送信は望ましくない場合がある。これらの「停止」時間は、サーバ１２５により自動的に確立することもできるし、顧客や受信者が指定することもできる。外部アプリケーションは、ＡＰＩ１４５を介して特定のメッセージについての停止時間を指示することもできるし、特定の連絡先（及び特定の通信形式）について停止時間を永久に指定することもできる。最も一般的なのは、永久に指定された停止時間を用いて受信者が通常寝ていると思われる時間や通信装置から離れていると思われる時間に電話やページャへメッセージが送信されることを防止することである。メッセージ固有の停止時間は、受信者の差し迫ったスケジュールをよく知っている送信者や停止時間を永久に確立することを望まない者に利用される場合がある。
【００２７】
逆に、外部情報源はメッセージを配達しなければならない時間範囲内で特定の許された時間範囲を指定することができる。この場合も、これらの時間範囲は、特定の連絡先について永久に確立したり、特定のメッセージについて「その場」で確立したりすることができる。
【００２８】
タイムゾーンのスケジューリングは自動的に用いられる。例えば、顧客が差し迫ったメッセージ配達をその受信者が居る夜遅くの時間に確立した場合、または、そのような時間にメッセージ配達をスケジュールした場合、トランザクションサーバ１５０は、その情報を顧客に促して確認させたり、配達を再スケジュールさせたりすることができる。
【００２９】
１．４  エスカレーション
トランザクションサーバ１５０は、複数の通信形式を用いてメッセージを冗長的に期待する受信者へ送信するのではなく、必要に応じて順次送信するためのエスカレーションルールを指定できるようになっている。外部アプリケーションは、複数の通信形式及び／又は連絡先、並びにそれらの使用管理するルールの形態の基準を選択する。通常、エスカレーションルールは、指定された時刻または指定された時間内に現在の通信形式を用いてメッセージの配達が確認されない場合、別の通信形式を用いる。
【００３０】
スケジューリングの制限と同様に、エスカレーションルールも、ある連絡先について永久に定義したり（その連絡先に関する「アドレスブック」と共にデータベース１５２ｂに記憶される）、特定のメッセージについて定義したりすることができる。外部アプリケーションはメッセージを単に入力し、そのメッセージをサーバ１２５に残すだけで、そのメッセージが各連絡先のエスカレーションルールに従って選択された配達リスト上の各人へ配達されるので、デフォルトメッセージ形式および永久エスカレーションルールは配達リストのコンテクストにおいて特に有用である。一方、メッセージ固有のエスカレーションルールは、ＡＰＩ１４５へ送信される特定のメッセージについて指定される。
【００３１】
エスカレーションルールを実施するため、最初のメッセージ送信に関連するルールにおいて指定された時間がスケジューラ１８０へ送信される。送信の後その時間の最後に、トランザクションサーバ１５０は、そのメッセージが受信されたか否かを上述の方法で判定する。受信されていない場合、エスカレーションルール（データベース１５２ｂまたはその特定のメッセージについてのトランザクションレコードに定義される）が実行され、そのメッセージは別の形式で再送される。そのメッセージについて更にエスカレーションルールが残っている場合、適当な時間が再びスケジューラ１８０へ供給され、このフローシーケンスが繰り返される。
【００３２】
２．アプリケーションプログラムインタフェースの例
図１及び図２を参照すると、サーバ１９０などの外部情報源は、メッセージ伝達機能及びステータス情報の要求を生成し、これらをインターネットなどのコンピュータネットワークを介してサーバ１２５へ送信し、処理する。図２は、ＡＰＩ１４５の役割および基本的な構成要素を示している。実際には、要求はサーバ１９０上でアクティブなプロセスとして動作しているアプリケーション２１０により生成される。ＡＰＩ１４５がアプリケーション２１０から受信した要求は、その要求を解釈してサーバ１２５の様々なサーバモジュールに適当なアクションをとらせるパーサー２１０によって解析される。これらのサーバモジュールは、要求に対して直接応答を生成することもできるし、アプリケーション２１０へ送信するためのステータス情報を提供することもできる。コンバータ２２０は、これらの情報を送信前にＡＰＩ構文を満たすステートメントに配置する。
【００３３】
好ましくは、このＡＰＩ構文は、「タグ」を用いてステートメント及びフィールドデータなどの要素を記述するＸＭＬの約束ごとに従うものである。＜ｔａｇｎａｍｅ＞の形式の文字列で始まり＜／ｔａｇｎａｍｅ＞で終わるタグが関連要素を囲う。従って、パーサー２１５は、従来のＸＭＬパーサー（またはそれに基づくもの）でよい。
【００３４】
ＡＰＩ１４５に対する通信の内容は「文書」の形態をとり、識別タグ及び、「要求」（アプリケーション２１０によって生成される文書の）あるいは「応答」（ＡＰＩ１４５がアプリケーション２１０へ返す文書の）を含む。文書要素は、階層的にオブジェクトへ編成される。各オブジェクトには、そのオブジェクトに関連するフィールドの内容が指定され、１以上のネストされた低階層のオブジェクトを含む場合がある。この構造により情報の構成が維持され、意味のあるまとまりで情報を移動することが容易になり、明示的な繰り返しをすることなく情報の再利用が可能になる。
【００３５】
最上位の階層レベルにおいて、「スーパーオブジェクト」は通信を要求または応答として定義するとともに、１以上の「メジャーオブジェクト」を含む。メジャーオブジェクトはメッセージ伝達活動の重要な機能要素を指定し、関連ユーザアカウント及び所望のメッセージ機能の性質を定義するとともに、その中にサブオブジェクト及び／又は様々なフィールド用エントリを含む場合がある。フィールドはそれらを保持しているオブジェクトに関連する文字列や数値などの情報を保持する。
【００３６】
ＡＰＩ１４５の好ましい実施形態の全体的な構成を以下に概略形態で記載し、概略の後、様々なオブジェクト及びフィールドについてさらに詳細に説明する。このＡＰＩは、単に例示的なものと考えるべきである。
【表１】
基本的なＡＰＩ構成
Ｉ．スーパーオブジェクト：必須フィールド及び１以上のメジャーオブジェクトを保持する。
Ａ．要求（フィールド：）
ｉ）    ユーザネーム
ｉｉ）   パスワード
ｉｉｉ）  ドメイン
ｉｖ）   ＯＥＭＩＤ
ｖ）    ＯＥＭパスワード
ｖｉ）   要求タイプ
Ｂ．応答：要求と同じフィールド／オブジェクト＋エラー、警告
ＩＩ．メジャーオブジェクト：文書の必須要素であり、サブオブジェクトおよびフィールドを含む場合がある。
Ａ．メンバー（フィールド：）
ｉ）     コマンド
ｉｉ）    ＩＤ
ｉｉｉ）  ファーストネーム
ｉｖ）    ラストネーム
ｖ）     会社
ｖｉ）    ユーザネーム
ｖｉｉ）   パスワード
ｖｉｉｉ） 通知許可
ｉｘ）    ダイアルインＩＤ
ｘ）     ダイアルインパスワード
メンバー（サブオブジェクト：）
ｉ）     連絡方法
ｉｉ）   課金（フィールド：ＩＤ；課金プラン；現在残高）
ｉｉｉ）  クレジットカード（期待するフィールド）
Ｂ．連絡先（サブオブジェクト：）
ｉ）    連絡方法（フィールド：）
ｉｉ）  ａ．      ＩＤ
ｂ．      輸送手段
ｃ．      修飾子
ｄ．      順序
ｅ．      電話番号、ファックス番号、ページャ番号
ｆ．      アクセスコード
ｇ．      Ｅメールアドレス
ｈ．      通り１
ｉ．      通り２
ｊ．      部屋
ｋ．      市
ｌ．      州
ｍ．      郵便番号
ｎ．      国
ｉｉ）  連絡方法参照（フィールド：）
ａ．      ＩＤ
ｂ．      ファーストネーム、ラストネーム、国
ｃ．      輸送手段、修飾子、順序
ｄ．      複数許可
連絡先（フィールド：）
ｉ）       コマンド
ｉｉ）      ＩＤ
ｉｉｉ）     プレフィックス（オプション）
ｉｖ）      ファーストネーム、ミドルネーム、ラストネーム
ｖ）       国（オプション）
ｖｉ）       タイトル（オプション）
Ｃ．配布リスト（フィールド：）
ｉ．       コマンド（作成、置換、追加、消去、除去）
ｉｉ．      名称
ｉｉｉ．     説明
ｉｖ．      ＩＤ
Ｄ．ジョブ（フィールド：）
ｉ．       ＩＤ
ｉｉ．      料金
ジョブ（サブオブジェクト：）
ｉ．       メッセージ（フィールド：）
Ａ．    題名
Ｂ．    テンプレート（オプション）
Ｃ．    ＩＤ
Ｄ．    日付
メッセージ（サブオブジェクト：）
Ａ．    メッセージ引数オブジェクト：一連の名称／値タグ：
１）    ＳＥＮＤＥＲ
２）    ＢＯＤＹ
３）    ＡＳＫ＿ＹＥＳＮＯ＿ＱＥＳＴＩＯＮ
４）    ＱＵＥＳＴＩＯＮ＿ＴＯ＿ＡＳＫ
５）    ＥＭＡＩＬ＿ＡＤＤＲ
Ｂ．    配達時間オブジェクト
Ｃ．    配達時間修飾子オブジェクト
ｉｉ．      連絡先（一回限りのメッセージの受信者を指定する）
ｉｉｉ．     配達要求（要素：）
Ａ．    配達オプションフィールド（ｉｎ）
Ｂ．    連絡方法参照サブオブジェクト
配達要求（返される要素：）
Ａ．    連絡方法
Ｂ．    連絡先
Ｃ．    配達（フィールド：）
１）    ＩＤ
２）    タイムスタンプ
３）    継続時間
４）    ステータス（非送信、送信済、失敗、キャンセル、保留）
５）    詳細（不正アドレス、配達アドレスに到達できなかった、返答なし、話中、留守番電話（推測）、留守番電話、最大配達試行回数超過、承認、モデム、ハングアップ、後でコールバック、内部エラー）
６）    サイズ
７）    コスト
Ｄ．   配達要求フィールド（ｏｕｔ）
１）    ＩＤ
２）    推定持続時間
３）    推定サイズ
４）    ステータス
５）    詳細
６）    完了
Ｅ．   範囲（フィールド：）
ｉ．      オブジェクト（即ち探しているオブジェクトのタイプ）
ｉｉ．      タイプ
ｉｉｉ．      開始
ｉｖ．      終了。
【００３７】
ＡＰＩ１４５への各送信ごとに要求が必要であり、要求によりＡＰＩ１４５（及び共に機能するサーバモジュール）から応答が生成される。この要求は、ユーザ名により１以上の有効な「メンバー」を識別しなければならない。要求には、以下の必須フィールドが含まれる：
【表２】
2004501419.tif 000003
（この表及び他の表において、Ｉｎ／Ｏｕｔの列は、そのフィールドが要求（ｉｎ）、それに対応する応答（ｏｕｔ）、またはその両方のうちいずれに使用されているかを示す。）。
【００３８】
この要求は、フィールドの他にも、通常１以上のメジャーオブジェクトを保持する場合がある。典型的なアクションとしては、指定された受信者へのメッセージの送信、メンバー・配布リスト・連絡先情報の追加／編集／消去、課金照会の送信などが含まれる。典型的な要求を以下に示す（後で詳細に説明する連絡先オブジェクトが示されているが、実際には指定されない）：
2004501419.tif 000004
【００３９】
要求は通常その要求に含まれていた同じオブジェクトと共に返されるが、その要求が情報（例えばメッセージステータスや課金情報など）を求めるものである場合、いくつかのオブジェクトまたはフィールドが追加または変更される場合がある。さらに、この要求は適宜次のようなエラーフィールド及び警告フィールドを含む場合がある：
【表３】
2004501419.tif 000005
エラー及び警告について以下で詳細に説明する。典型的な応答を以下に示す（ここでも連絡先オブジェクトが示されているが、実際には指定されない）。
2004501419.tif 000006
【００４０】
要求及び応答は１以上のメジャーオブジェクトを以下のように指定する：
【表４】
2004501419.tif 000007
【００４１】
各メジャーオブジェクトはゼロ以上のフィールド及びサブオブジェクトを含み、これらのサブオブジェクトにはさらにサブオブジェクト及び／又はフィールドが含まれる場合がある。様々なメジャーオブジェクトをこれから詳細に説明する。
・メジャーオブジェクト−Ｍｅｍｂｅｒ：一般にメッセージサービスのエンドユーザである。
・メジャーオブジェクト−Ｍｅｍｂｅｒ：−フィールド：メンバーオブジェクトは以下のフィールドを有する：
【表５】
2004501419.tif 000008
・メジャーオブジェクト−Ｍｅｍｂｅｒ−サブオブジェクト：メンバーオブジェクトはさらに以下の必須サブオブジェクトを含む：
・メジャーオブジェクト−Ｍｅｍｂｅｒ−サブオブジェクト−連絡方法：通信形態（Ｅメール、電話など）及び連絡先固有の連絡先情報（Ｅメールアドレス、電話番号など）を指定する。連絡方法サブオブジェクトについては、連絡先メジャーオブジェクトに関連して以下でさらに説明する。
・メジャーオブジェクト−Ｍｅｍｂｅｒ−サブオブジェクト−課金：課金プラン及び課金メンバーに必要な細目（クレジットカード番号など）を指定する。このオブジェクトは、現在のアカウントステータスも表している。以下の表は、課金サブオブジェクトの必須フィールドを設定するものである：
【表６】
2004501419.tif 000009
【００４２】
次に、課金サブオブジェクトはクレジットカードサブオブジェクトを含み、そのフィールドについて以下の表で説明する：
【表７】
2004501419.tif 000010
【００４３】
メンバーオブジェクト全体の例を以下に示す。
2004501419.tif 000011
2004501419.tif 000012
【００４４】
メジャーオブジェクト−連絡先：メッセージを送信してもよい人を識別する。連絡先オブジェクトは、各人へ届く方法を識別する１以上の連絡方法（以下で説明する）を含む。連絡先及び連絡方法の情報は、メンバーのアドレスブック（即ち、メンバーの連絡先を収集し、データベース１５２ｂに格納さえた連絡方法に関連付けたもの）に記憶される場合もあるし、記憶されない場合もある。このように、連絡先メジャーオブジェクトは、アドレスブックに記憶すべく作成される場合もあるし、一回だけの使用のために作成される場合もある。
【００４５】
メジャーオブジェクト−連絡先−フィールド：連絡先オブジェクトは以下のフィールドを有する：
【表８】
2004501419.tif 000013
【００４６】
コマンドフィールドの使用により、連絡先オブジェクトがその連絡先オブジェクトに関連するメンバーのアドレスブックに確実に記憶されるようになる。連絡先オブジェクトはジョブオブジェクトのサブオブジェクトとしてネストされ（以下で説明する）、その連絡先情報はアドレスブックに記憶されない。
【００４７】
典型的な連絡先オブジェクトを以下に示す（連絡方法オブジェクトが示されているが、実際には指定されない）。
2004501419.tif 000014
メジャーオブジェクト−連絡先−サブオブジェクト−連絡方法：上で説明したように、このオブジェクトはメンバーに連絡をとる方法を指定する。連絡方法サブオブジェクトは、以下のフィールドのうちの一部または全部を含む場合がある：
【表９】
2004501419.tif 000015
【００４８】
メンバーの主要なＥメールアドレスを表すため、例えば次のような構文を用いる：
2004501419.tif 000016
次の例は、アドレスブックへの新たな連絡先の追加を示す：
2004501419.tif 000017
メジャーオブジェクト−連絡先−サブオブジェクト−Ｃｏｎｔａｃｔ ＭｅｔｈｏｄＲｅｆ：連絡方法が作成され格納された後、連絡方法はＣｏｎｔａｃｔ ＭｅｔｈｏｄＲｅｆと呼ばれるポインタを用いて参照される。このポインタは、連絡方法を一意に識別する連絡方法のＩｄまたはフィールドの組み合わせを含む。
【００４９】
Ｃｏｎｔａｃｔ ＭｅｔｈｏｄＲｅｆサブオブジェクトは、次のフィールドのうちの一部または全部を含む場合がある：
【表１０】
2004501419.tif 000018
メジャーオブジェクト−配布リスト：配布リストは連絡方法をグループ分けしたものである。配布リストにより、メンバーはそのリストにある全ての連絡方法でメッセージを送信することが可能になる。配布リストオブジェクトは以下のフィールドのうちの一部または全部を含む場合がある：
【表１１】
2004501419.tif 000019
【００５０】
さらに、配布リストオブジェクトは、Ｃｏｎｔａｃｔ ＭｅｔｈｏｄＲｅｆサブオブジェクト（即ち、既に作成されている連絡方法オブジェクトへのポインタ）のリストを有しなければならない。配布リストの例を以下に示す：
2004501419.tif 000020
メジャーオブジェクト−ジョブ：ジョブオブジェクトは１以上の連絡方法を用いて１以上の連絡先へ送信するメッセージを含むとともに、メッセージタスクの詳細を定義するサブオブジェクト（例えば、送信者、メッセージ本体、受信者など）を含む。また、ジョブオブジェクトは、少なくとも１つのメッセージサブオブジェクト（以下で説明する）及び１以上の配達要求または連絡先サブオブジェクトも含む。
【００５１】
ジョブオブジェクトは２つのフィールドしか保持せず、これらは以下の応答においてのみ指定される：
【表１２】
2004501419.tif 000021
【００５２】
メジャーオブジェクト−ジョブ−サブオブジェクト−メッセージ：メッセージサブオブジェクトは実際のメッセージを指定する。メッセージサブオブジェクトはフィールドおよびオプションのＭｅｓｓａｇｅＡｒｇオブジェクトを含み、要求した者が配達時間を指定できるようにする：
【表１３】
2004501419.tif 000022
【００５３】
メジャーオブジェクト−ジョブ−サブオブジェクト−メッセージ−ＭｅｓｓａｇｅＡｒｇサブオブジェクト：メッセージオブジェクトは、次の構文に従って一連の名称／値からなる１以上のＭｅｓｓａｇｅＡｒｇサブオブジェクトを含む：
2004501419.tif 000023
【００５４】
オプションのＭｅｓｓａｇｅＡｒｇ 名称／値タグは以下のようなものである：
【表１４】
2004501419.tif 000024
【００５５】
ジョブオブジェクトの例は次のようものである。
2004501419.tif 000025
2004501419.tif 000026
【００５６】
メジャーオブジェクト−ジョブ−サブオブジェクト−配達要求：配達要求サブオブジェクトは、要求した者がジョブの受信者を指定し、配達オプション（配達要求サブオブジェクト内のフィールドとして）を指定できるようにするものである。配達要求オブジェクトは、Ｃｏｎｔａｃｔ ＭｅｔｈｏｄＲｅｆサブオブジェクト（受信者について既に作成されている連絡方法を指す）を含む場合があり、あるいは、ジョブオブジェクトの連絡先サブジェクトを指す場合もある（連絡先／連絡方法を一回しか使用しない場合）。
【００５７】
配達要求サブオブジェクトの例を以下に示す：
2004501419.tif 000027
【００５８】
配達要求サブオブジェクトは、ＡＰＩ１４５からも応答として返される。さらに、範囲オブジェクトルックアップ（以下で説明する）を用いて既存のジョブオブジェクトが取得された場合、そのジョブの配達要求も返される。
【００５９】
配達要求サブオブジェクトは次のフィールドを含む場合がある：
【表１５】
2004501419.tif 000028
【００６０】
配達要求応答の例を以下に示す：
2004501419.tif 000029
【００６１】
メジャーオブジェクト−ジョブ−配達要求−配達サブオブジェクト：配達サブオブジェクトが要求に現れることはない。配達サブオブジェクトは、範囲オブジェクトルックアップ（下記を参照）があるジョブに対して実行されたとき、ＡＰＩ１４５により配達要求オブジェクトのサブオブジェクトとして返される。
【００６２】
配達サブオブジェクトは、下記のフィールドを含む場合がある：
【表１６】
2004501419.tif 000030
【００６３】
メジャーオブジェクト−範囲：範囲オブジェクトは、指定された基準に基づいてオブジェクトのリストを取得することを容易にするものである。具体的には、範囲オブジェクトは、配布リスト、ジョブ及び連絡先オブジェクトを取得することができる。範囲オブジェクトに対する応答は、要求されたオブジェクトを返す。
【００６４】
範囲メジャーオブジェクトは以下のフィールドを含む場合がある：
【表１７】
2004501419.tif 000031
【００６５】
範囲オブジェクトは常に要求オブジェクト内に含まれ、ＲｅｑｕｅｓｔＴｙｐｅの値が「ｌｏｏｋｕｐ」に設定される。範囲オブジェクトの最も一般的な使い方は、例えばＩｄからジョブオブジェクトを探すことである。例えば、
2004501419.tif 000032
のようなものである。
【００６６】
エラーハンドリング：エラーは３つのクラスに分類される。即ち、構文解析エラー、致命的エラー、及び、何らかのオブジェクトやフィールドを検査している間に遭遇したエラー／警告である。
【００６７】
構文解析エラーは、入力ＸＭＬタグがＸＭＬ仕様を満たさない場合に発生する。異常のあるＸＭＬコードの例としてはタグが閉じていないものや不正な文字が挙げられ、文字タイプのエラーを避けるため、フリーフォームのテキストはＣＤＡＴＡタグで囲わなければならない。構文エラーに遭遇した場合、ＡＰＩ１４５はＰａｒｓｅＥｒｒｏｒオブジェクトを返し、このオブジェクトにはＰａｒｓｅＥｒｒｏｒと呼ばれる以下のフィールドを含む１以上のサブオブジェクトが含まれる：
【表１８】
2004501419.tif 000033
【００６８】
一例を以下に示す：
2004501419.tif 000034
【００６９】
致命的エラーは、要求の処理中に遭遇した重大な問題を意味する。ＡＰＩ１４５は、そのエラーの性質を示す単一のフィールド（ＥｒｒｏｒＳｔｒｉｎｇ）と共にＦａｔａｌＥｒｒｏｒオブジェクトを返す。例えば、
2004501419.tif 000035
のようなものである。
【００７０】
妥当性確認エラー及び警告は、問題のあるオブジェクトやフィールドに「属性」として付加される。応答オブジェクトのこのエラー及び警告フィールドは次の情報を含む：
【表１９】
2004501419.tif 000036
【００７１】
例えば、ある要求が不正な電話番号を含む場合、その問題のある＜ＰｈｏｎｅＮｕｍ＞フィールドには警告属性が付加される。あるメンバーを追加しようとしたとき、要求が課金サブオブジェクトの提供に失敗した場合、そのメンバーオブジェクトにはエラー属性が付加される。
【００７２】
従って、上述の事項は、複数の通信モードで動作し、一般的な拡張可能なインタフェースを通してリモートアプリケーションと通信することが可能な全機能搭載のメッセージ伝達システムを表すことが分かるであろう。本明細書で使用される用語及び表現は、説明の用語として用いられるものであって制限の意図はなく、このような用語及び表現を用いることにより図示及び説明したあるいはその一部をなす特徴の何らかの均等を除外する意図はなく、本発明の範囲内で様々な変更が可能であると考えられる。
【図面の簡単な説明】
【図１】
本発明の環境を概略的に表す図である。
【図２】
本ＡＰＩの構成要素及びその対話モードを示す図である。
【図１】
2004501419.tif 000037
【図２】
2004501419.tif 000038
【国際公開パンフレット】
2004501419.tif 000039
2004501419.tif 000040
2004501419.tif 000041
2004501419.tif 000042
2004501419.tif 000043
2004501419.tif 000044
2004501419.tif 000045
2004501419.tif 000046
2004501419.tif 000047
2004501419.tif 000048
2004501419.tif 000049
2004501419.tif 000050
2004501419.tif 000051
2004501419.tif 000052
2004501419.tif 000053
2004501419.tif 000054
2004501419.tif 000055
2004501419.tif 000056
2004501419.tif 000057
2004501419.tif 000058
2004501419.tif 000059
2004501419.tif 000060
2004501419.tif 000061
2004501419.tif 000062
2004501419.tif 000063
2004501419.tif 000064
2004501419.tif 000065
2004501419.tif 000066
2004501419.tif 000067
2004501419.tif 000068
2004501419.tif 000069
2004501419.tif 000070
2004501419.tif 000071
2004501419.tif 000072
2004501419.tif 000073
2004501419.tif 000074
2004501419.tif 000075
2004501419.tif 000076
2004501419.tif 000077
2004501419.tif 000078
2004501419.tif 000079
2004501419.tif 000080
2004501419.tif 000081
2004501419.tif 000082
2004501419.tif 000083
2004501419.tif 000084
2004501419.tif 000085
2004501419.tif 000086
【国際公開パンフレット（コレクトバージョン）】
2004501419.tif 000087
2004501419.tif 000088
【国際公開パンフレット（コレクトバージョン）】
2004501419.tif 000089
2004501419.tif 000090
【国際調査報告】
2004501419.tif 000091
2004501419.tif 000092
2004501419.tif 000093