JP2005515519A - 自動的な通知および応答用の方法および装置 - Google Patents

Abstract

開示されている通知および応答システムを使用すると、さまざまな種類の媒体を使用してアプリケーションと受信者との通信が可能になる。通知および応答システムは（ｉ）それぞれの個別受信者により指定された媒体を使用して１人または複数の受信者に要求を送信し、（ｉｉ）応答を収集して処理し、（ｉｉｉ）最終宛先により指定された媒体を使用して最終宛先に応答を転送する。アプリケーション、少なくとも１つのサポートされている人間の言語および媒体形式で要求をフレーム化し、要求を該当する受信者に、その環境設定に応じて配送する。通信フロー式で、指定された要求の受信者および各受信者が要求をいつ、どこで、どのように、受信するかを指定する。要求は、動的に更新され、通信フロー式のパラメータは、要求が配送されるまで、評価されない。通信フロー規則により、受信者の通信の環境設定を指定し、送信者側の特性、トピック、またはスケジューリングの制約条件に合わせて通信フローを手直しする。通信フロー式は、通知失敗（ｍａｙｂｅ）、応答失敗（ｆａｌｓｅ）、および応答成功（ｔｒｕｅ）の３値論理を使用して評価する。プリミティブは、同時または順次連絡を指定し、また成功検査結果の論理結合を定義することによりいつ部分式の実行を終了すべきかを指定する。

Description

本発明は、一般に１人または複数の受信者と通信するための方法および装置に関するものであり、より具体的には、アプリケーションと１つまたは複数の異なる種類の媒体を使用する１人または複数の受信者との間で自動的な通知および応答を行うための方法および装置に関するものである。

本出願は、２００１年５月１５日に出願した米国仮出願番号６０／２９１，０８７の特権を主張するものである。

企業向けアプリケーションでは、人々との連絡が必要であり、またその連絡の取り方および応答があった場合にどのような応答を収集するかに関して要求条件が設定されている。たとえば、アプリケーションにより、ある種の関心を持つすべての人々、または特定のリストに載っている人々または１人の人と連絡を取らなければならない場合がある。また、今まさに危機的状態にある人に連絡を取る必要がある場合や、適切な時期にタスクのあることを知らせて思い出させたい場合がある。企業向けアプリケーションではさらに、何が成功かということが企業によって定義されている場合に、連絡が不成功だった場合に何をすべきかについても必要条件を定めている。

一方、受信者側は、連絡の取り方および連絡を取る時期について各自の環境設定（ｐｒｅｆｅｒｅｎｃｅ）がある。たとえば、受信者は、上司や家族などの特定の人々、あるいはフォーチュン５００社のリストに載っている会社の企業幹部などの特定の利害を代表する人々がリアルタイムで連絡をより自由に取れるようにしたいと考えている。さらに、受信者は、日常的に、週別状況または支出更新などの知られているタスクについての連絡を、都合のよい時期または場所が確定するまで遅らせたい場合もある。多くの場合、受信者側の環境設定は、企業側の環境設定または特定のアプリケーションの実装に反する。そのような場合には、受信者は受信者の環境設定がかなえられるように何とかやりくりしてアプリケーションの制約事項に対処するが、そうでなければ、企業のプロセスにフラストレーションを感じたり、さらには煩わしくなったりする。

アプリケーションが１人または複数の受信者と通信できるようにする通知システムが多数、提案されたり開発されたりしている。しかし、既存の通知システムは、媒体および機能の点で制限があるのがふつうである。たとえば、通知システムは、電子メール・メッセージを携帯電話またはポケットベルにしか送信できないことがある。さらに、既存の通知システムでは、異なる通信インフラ基盤の柔軟な使用に対応していない。たとえば、ＷＡＰ Ｆｏｒｕｍ、「Ｗｉｒｅｌｅｓｓ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ １．２．１」、Ｊｕｎｅ ２０００で説明されているＷｉｒｅｌｅｓｓ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＷＡＰ）を使用するサービスなどの無線サービスが成長し、１つのデバイスとのみ連絡を取り、それにより、携帯電話のＷｅｂフォームへの応答のプッシュおよび受信を行う通知および応答サービスが多数開発されてきている。

たとえば、Ｍ．Ｈａｎｄｌｅｙ ｅｔ ａｌ．「ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」ＲＦＣ ２５４３、１９９９年３月で説明されているようなＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）は、デバイスのＳＩＰ Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）を登録することにより特定のデバイスにユーザーを関連付けることができるレジストリを備える。ユーザーとの通信を確立するのと並行して、または順次、所定のユーザーについてレジストリに記録されているＵＲＬのリストを使って連絡を取ることができる多数のＳＩＰプロキシが存在する。たとえば、Ｊ．Ｌｅｎｎｏｘ ａｎｄ Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ「ＣＰＬ：Ａ Ｌａｎｇｕａｇｅ ｆｏｒ Ｕｓｅｒ Ｃｏｎｔｒｏｌ ｏｆ Ｉｎｔｅｒｎｅｔ Ｔｅｌｅｐｈｏｎｙ Ｓｅｒｖｉｃｅｓ」Ｄｒａｆｔ ＲＦＣ ｄｒａｆｔ−ｉｅｔｆ−ｉｐｔｅｌ−ｃｐｌ−０５．ｔｘｔ、２００１年１１月で説明されているようなＣａｌｌ Ｐｒｏｃｅｓｓｉｎｇ Ｌａｎｇｕａｇｅ（ＣＰＬ）はＳＩＰプロキシに関して提案されている言語である。

ＣＰＬでは、ユーザーはあらかじめ、送信者および宛先のアドレスまたはＩＮＶＩＴＥの件名内の文字列の解釈など、ＳＩＰ ＩＮＶＩＴＥメッセージ（ＳＩＰプロトコルに従ってユーザーとの連絡を確立するために使用される）の特性を付加された特定のＵＲＬを選択する方法を指定することができる。ＣＰＬではさらに、ユーザーはタイムアウトを指定することができるため、受信者との通信確立を試みるときに順次ＩＮＶＩＴＥメッセージ列を特定のデバイスに送ろうとすることができる。さらに、ＳＩＰでは、各ＳＩＰデバイスまたはエンド・ポイント側でユーザーの環境設定を媒体タイプおよび人間の言語の重み付きリストとして指定することができる。送信者は、利用できるようにしている媒体タイプおよび人間の言語から、最も高い重み付けの媒体タイプおよび人間の言語を用意するように求められる。ＳＩＰおよびＣＰＬは、通信の結果の解釈、およびその結果に応じてさまざまなアクションを実行することについてはサポートしていない。たとえば、電話がかかって応答に成功した後、ＳＩＰおよびＣＰＬは、ユーザーが電話を切ったのか、実際に要求に応答したのかを検出しない。

システム内のデータ・フローまたはプログラム・フローを指定する十分な技術は存在しているが、通信フローを指定するのに利用できる手法は通常、初歩的なものである。通信フローは、要求者側から受信者側への要求の経路である。これらの既存の通信フローの技術では、要求に関して受信者を指定することを、電子メール・メッセージをメールボックスに送ったり、メッセージをポケットベルに送信したりするなどの何らかのあらかじめ定められている連絡方法と同一視している。通信フロー経路は多くの場合、２人の当事者間の単純な接続と考えられるが、現代的な通信機能により、さまざまな通信フローが可能である。たとえば、与えられた通信フローは、（ｉ）並行してまたは順次に受信者または受信者が使用するデバイスと連絡を取るか、（ｉｉ）すべての受信者または受信者の一部だけが要求に応答するのを待つか、または（ｉｉｉ）通信エラーが発生したときに別の方向を選択することができる。

したがって、要求に対する受信者、および各受信者が要求をいつどこでどのように受信し、それに対する応答でさらにどのように通信を進めるかなどの、通信フローのパラメータを都合よく、正確に指定する一般的な手法が要求される。さらに、アプリケーションの要件および受信者の環境設定を捕捉し、組み合わせるような方法で通信のパラメータを指定する手法も必要である。
米国仮出願番号６０／２９１，０８７ ＷＡＰ Ｆｏｒｕｍ、「Ｗｉｒｅｌｅｓｓ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ １．２．１」、Ｊｕｎｅ ２０００ Ｍ．Ｈａｎｄｌｅｙ ｅｔ ａｌ．「ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」ＲＦＣ ２５４３、１９９９年３月 Ｊ．Ｌｅｎｎｏｘ ａｎｄ Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ「ＣＰＬ：Ａ Ｌａｎｇｕａｇｅ ｆｏｒ Ｕｓｅｒ Ｃｏｎｔｒｏｌ ｏｆ Ｉｎｔｅｒｎｅｔ Ｔｅｌｅｐｈｏｎｙ Ｓｅｒｖｉｃｅｓ」Ｄｒａｆｔ ＲＦＣ ｄｒａｆｔ−ｉｅｔｆ−ｉｐｔｅｌ−ｃｐｌ−０５．ｔｘｔ、２００１年１１月 Ｍ．Ｗａｈｌ ｅｔ ａｌ．「Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ｖ３）」、ＲＦＣ ２２５１（１９９７年１２月） Ｍ．Ｈａｎｄｌｅｙ ｅｔ ａｌ．「ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」、ＲＦＣ ２５４３、１９９９年３月

概して、１つまたは複数のアプリケーションが、電子メール、電話、Ｗｅｂページ、ポケットベル、またはＦＡＸなどの多様な複数の媒体を使用して１人または複数の受信者と通信することができる通知および応答システムが開示されている。一般に、通知および応答システムは（ｉ）それぞれの個別受信者により指定された媒体を使用して１人または複数の受信者に要求を送信し、（ｉｉ）応答を収集して処理し、（ｉｉｉ）最終宛先により指定された媒体を使用して最終宛先に応答を転送する。

アプリケーションでは、サポートされている多数の人間の言語および媒体形式のうちの１つで要求をフレームにまとめることができ、要求は、それぞれの受信者の媒体および人間の言語に対する環境設定に応じて、該当する受信者に自動的に配送される。したがって、受信者は、指定された環境設定およびエンド・ポイントの能力に応じて、異なるアプリケーションまたはシステム（またはその両方）からメッセージを受信する。応答は、対応するアプリケーションに都合のよい形式でそれぞれのアプリケーションに返される。アプリケーションは、メッセージを１人または複数の指定された受信者に送信するか、あるいはあらかじめ定められている受信者リストまたはロールに従って送信することができる。受信者の環境設定およびロール・データベースは、受信者リスト、ロール、受信者環境設定を集中管理することができる。受信者の環境設定およびロール・データベースには、ロール、人、およびデバイスの情報だけでなく、関連する通信フロー情報も記録される。

アプリケーションでは、通信フロー式を使用して、連絡相手（「Ｂｏｂ」）、連絡条件（「Ａｎｎが「ｙｅｓ」の返事をした場合のみ」）、および連絡日時（「週末の午前９時から午後５時までの間」を指定する。受信者は、デバイスをどのように使用するか、つまり、どのデバイスを使用し、いつ連絡するかという詳細を使用して通信フロー式を精密化する規則を指定する。受信者は、さらに、いくつかの要求を他の受信者に自動的に委託することもできる。本発明の一特徴によれば、要求は、要求が配送されるまで新しい情報で動的に更新することができ、したがって、受信者は最近のビジネス情報を受信する。さらに、通信フロー式のパラメータ（誰が、何を、およびいつ）は、要求が配送されたときに評価され、要求は最新の受信者環境設定に応じて配送される。

アプリケーションは、特定の通知メッセージを一人または複数の受信者に送信し、その通知に対する応答を収集して要求者に返すか、または他のアプリケーションに転送することを求める要求を開示されている通知および応答システムに送信する。要求は、（ｉ）通知メッセージ、（ｉｉ）要求パラメータ、（ｉｉｉ）通信フロー式、および（ｉｖ）応答からなる。通信メッセージは、サポートされている多数の人間の言語および媒体形式のうちの１つでフレームにまとめることができ、要求は、それぞれの受信者の媒体および人間の言語に対する環境設定に応じて、該当する受信者に自動的に配送される。要求パラメータにより、要求の振る舞いを制御したり、要求の形式を適切に定める（またはその両方を行う）通知および応答システムから利用できるようになっていなければならない情報を指定する。

通信フロー式では、アプリケーションの要件および受信者の環境設定を捕捉して組み合わせる。要求の通信フロー式部分により、要求に関連付けられている受信者（「Ｗｈｏ」）だけでなく、そのような受信者がどのようにして、いつ、どこで、要求を出すかを指定する。受信者は、ロール（たとえば、「顧客サービス」）、人（たとえば、「Ｊｅｒｒｙ」、アドバイス（たとえば、「８００−５５５−１２３４」）、または評価すべき他の通信フロー式とすることができる。各受信者はアクティブであるが、それは、受信者がその通信の環境設定を指定し、通信フローを送信者側の特性、要求のトピック、またはスケジュールの要求条件に合わせて手直しする通信フローの規則を定めることができるからである。一般に、通信フローの規則では、受信者の環境設定に応じて、通信フローの中の受信者の名前を受信者と連絡を取る時期、場所、および方法に関する詳細で置き換える。通信フロー式はさらに、特定の受信者が要求に対し正常に応答できなかった場合に実行すべきアクションを指定する。

通知および応答システムでは、通信フローの中で成功テストを使用し、応答性側によって指定された対応を評価して特定の連絡が成功したか失敗したかを判別することができる。応答者側は、要求を受信し、応答を返した人である。応答が受信されると、通知および応答システムは各個別応答の属性値ペア、または要求が完了した後では、照合された結果を最初の要求で指定された最終宛先に転送する。

通信フローが２つの理由で失敗することがある。１つは、単に受信者と連絡を取れなかったか、または受信者がまったく通知に応答できない場合であって、通知失敗（その逆を通知成功）と呼ぶ。もう１つは、受信者と連絡を取ることができ、その後要求を受理するか、または拒絶する場合であって、応答成功（「ｔｒｕｅ」または「ｙｅｓ」を示す）または応答失敗（「ｆａｌｓｅ」または「ｎｏ」を示す）とそれぞれ呼ぶ。

本発明の他の特徴では、３値論理を使用して通信フロー式を評価する。この論理の３つの可能な値は、通知失敗（ｍａｙｂｅ）、応答失敗（ｆａｌｓｅ）、および応答成功（ｔｒｕｅ）である。通知成功は、応答成功または応答失敗の前に発生する、識別された一時的状態である。多数のデバイスが使用されている場合、受信者からの応答を受信したときに知ることができるのは、通知を受信したということだけである。そのため、要求と関連付けられた成功式で、受信者から受信した応答に含めることができる変数に対する３値論理式を指定することができる。成功式で、応答の中の値の論理的組み合わせを検査し、応答成功がある場合、連絡は「ｔｒｕｅ」に評価され、応答失敗がある場合、連絡は「ｆａｌｓｅ」に評価され、それ以外については、応答に対し時間の余裕がない場合、通知失敗があり、連絡は「ｍａｙｂｅ」に評価される。

各通信フロー式は、受信者に同時に連絡するかまたは順次連絡するか、およびいつ部分式の実行を成功検査結果の論理結合を定義することにより終了すべきかを指定する１つまたは複数のプリミティブを含む。具体的には、プリミティブでは、並行または順次通信の方向と受信者との通信の状況を通信フローにどのような影響を及ぼすかということの評価と組み合わせる。他のプリミティブは、連絡を取る時期またはディレクトリを探索することにより見つかった対象のリストから通信フローを構築する方法を制御する。

開示されている通知および応答システムにより採用されているプリミティブは、当然、ａｎｄ／ｔｈｅｎ、ｏｒ／ｅｌｓｅ、ｒａｃｅｓ／ｄｅｌｅｇａｔｅｓ、およびｖｏｔｅｓ／ｐｏｌｌｓのように並行／順次のペアにグループ化することができる。並行プリミティブと順次プリミティブは、オペランドの評価方法が異なる。並行プリミティブでは、それぞれの受信者に並行して連絡を取る。未処理要求（ｏｕｔｓｔａｎｄｉｎｇ ｒｅｑｕｅｓｔ）は、プリミティブのｔｒｕｅ値を決定するためにもはや必要なくなれば取り消される。順次プリミティブでは、要求は現れる順序でそれぞれの受信者に送られる。受信者が応答すると、要求は次の受信者に送信され、必要ならば、プリミティブのｔｒｕｅ値を決定する。それぞれのプリミティブは、受信者との通信が成功したかどうかに応じて「ｔｒｕｅ」、「ｆａｌｓｅ」、または「ｍａｙｂｅ」に評価される。
本発明、および本発明の他の特徴と利点の詳細については、後述の説明および図面を参照することで得られる。

本発明は、電子メール、電話、Ｗｅｂページ、ポケットベル、またはＦＡＸなどのさまざまな種類の媒体により、図１に示されている、１つまたは複数のアプリケーション１１０−１〜１１０−Ｎ（これ以降アプリケーション１１０と総称する）と１つまたは複数の受信者１２０−〜１２０−Ｎ（これ以降受信者１２０と総称する）との通信を可能にするための通信および応答システム１００を実現する。一般に、通知および応答システム１００は（ｉ）それぞれの個別受信者１２０により指定された媒体を使用して１人または複数の受信者１２０に要求を送信し、（ｉｉ）応答を収集して処理し、（ｉｉｉ）最終宛先により指定された媒体を使用して最終宛先に応答を転送する。

図２は、通知および応答システム１００の詳細な図である。図２に示されているように、また後述のように、アプリケーション１１０は、要求の送信または取り消し、要求のステータスのチェック、およびアプリケーション１１０に結果を返す動作を行うサービスを提供するアプリケーション・インターフェイス２２０を使用して要求を要求マネージャ１２００に送信する。アプリケーションでは、通知要求および保留通知の取り消し要求を適切なアプリケーション・インターフェイス２２０に、たとえば、ＨＴＴＰ ＰＯＳＴを介して送信することができる。

アプリケーション・インターフェイス２２０は、たとえば、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）、またはＩＢＭ Ｃｏｒｐ．が販売しているＭＱＳｅｒｉｅｓ（商標）インターフェイスやＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．が販売しているＪ２ＥＥ（商標）インターフェイスなどの各種の市販Ｅｎｔｅｒｐｒｉｓｅ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ（ＥＡＩ）インターフェイスとして実現することができる。アプリケーション・インターフェイス２２０は、要求毎に、外部要求表現と通知および応答システム１００の内部表現との間のマッピングを行う。同様に、アプリケーション・インターフェイス２２０は、応答毎に、通知および応答システム１００の内部表現と外部要求表現との間のマッピングを行う。

図１１に関して以下で説明する要求マネージャ１２００は、送信されたすべての要求を追跡する。図３に関して後述するように、要求マネージャ１２００は、各要求に関する情報を格納している要求データベース３００を保持し、保留、取り消し、あるいは完了などのそれぞれの要求のステータスを示す。要求データベース３００は、メモリまたは永続的データベースに保持することができ、要求およびその現在状態（応答を含む）をそこに格納することができる。機能はいろいろあるが特に、要求マネージャ１２００は、受信者１２０が受信する要求および応答が適用される要求を識別するために使用することができるそれぞれの要求に一意の識別子を割り当てる。さらに、要求マネージャ１２００は、必要に応じて、要求を修正し、必ず応答を通知および応答システム１００に返送するようにする。

すでに示しているように、アプリケーション１１０では通信フロー式を使用して、与えられた要求のパラメータを指定する。要求マネージャ１２００は、受信者とのそれぞれの媒体特有の通信を実行する際に通信フローの方向に従う。要求マネージャ１２００では、図１３に関して後述する通信フロー・マネージャ１３００の通信フロー式サービスを使用する。要求マネージャ１２００と通信フロー・マネージャ１３００との間の相互作用を、図１１に関して後述する。

一般に、通信フロー・マネージャ１３００は、要求の中で定義されているターゲット通信フローを解釈してより効率の高いツリー構造の内部表現に変える。さらに、通信フロー・マネージャ１３００は、ツリー表現のトラバースを繰り返し、その実行中に、非デバイス受信者を展開して、デバイスをインスタンス化する。繰り返し毎に、通信フロー・マネージャ１３００は、利用可能になっていた成功検査結果を入力し、保留中の連絡を取り消すか、それとも新規連絡を開始するかを決定する。そこで、通信フロー・マネージャ１３００は、通信フロー式を解釈して実行し、要求を適切な受信者１２０にどのように配送するかを決定し、また通信の各試行結果の成功または失敗にどのように応答するかを決定する。

ディレクトリ・インターフェイス２５０は、通知および応答システム１００で使用しているロール、人、およびデバイスの内部表現と受信者環境設定およびロール・データベース５００内の表現との間のマッピングを行う。さらに、ディレクトリ・インターフェイス２５０は、検索およびその他の要求も処理する。通信フロー・マネージャ１３００は、全体として、通知および応答システム１００が連絡方法を認識しているデバイスに対して解決される必要があるロールおよび受信者の名前を連絡する通信フローで示されている。ディレクトリ・スキーマおよび通知および応答システム１００の内部表現を単一のクラス内にマッピングすることにより、他の種類のデータベースも使え、内部表現を、使用している特定のディレクトリ・スキーマから独立させることもできる。このクラスはさらに、一組の特定の検索および取り出し方法も提供する。

媒体特有の連絡２７０では、通知および場合によっては応答収集結果の実際の配送を処理する。指定可能な持続時間または試行回数の後、特定の媒体を介した連絡を実行できない場合、通知失敗メッセージが要求マネージャ１２００に返される。媒体特有のインターフェイス２７０については、以下の「媒体特有のインターフェイス」という表題の項目で説明する。通知メッセージ毎に、媒体特有のインターフェイス２７０は、通知および応答システム１００の内部要求ドキュメント表現と外部表現との間でマッピングを行う。同様に、媒体特有のインターフェイス２７０は、応答毎に、外部要求表現と通知および応答システム１００の内部表現との間のマッピングを行う。

Ｗｅｂポータル２８０は、さまざまな媒体を介してデータを受信者１２０に提供し、応答を収集する。Ｗｅｂポータル２８０は、受信者の保留、完了、および取り消された通知へのアクセスを可能にするサーブレット集である。これは、保留通知のリストを表示し、受信者がそこから読み込むまたは聞き取ることができるようにするサーブレット、および通知を表示するサーブレット、および応答を収集する他のサーブレットを含む。Ｗｅｂポータル２８０はこのように構造化され、すべての通知が、通知および応答システム１００により直接配送され、すべての応答は通知および応答システム１００により収集されるようになっている。集中型実装により、通知の内容を制御し、通知を個人化し、通知に前回の応答を組み込むようにすることができる。受信者環境設定およびロール・データベース５００からの個人化データは、ｆｏｒｍアクション・タグを修正して適切なサーブレットを指すようにするのと同じ書き換えメカニズムによって処理される。

通知および応答システム１００は、通信フロー式内で指定された受信者１２０へのすべての要求を仲介する。これにより、通知および応答システム１００は、応答を記録し、それらの応答を通信フロー・マネージャ１３００に伝達する。通信フロー・マネージャ１３００は、これらの応答の内容に基づき通信フローを通る異なる経路を取る。たとえば、Ｗｅｂアプリケーション・プログラム・インターフェイス（ＡＰＩ）の例では、要求はすべてＷｅｂページとして表され、応答を必要とするものはその応答を受け付けるためのフォームを含む。要求は、応答を指定のＵＲＬに送るように書き換えられ、通知および応答システム１００に対し行われた元の要求で指定されている最終の宛先への経路選択を行う前に完了ステータスを記録することができる。通知および応答システム１００の経路選択および戻り処理は、ユニファイド・メッセージング・システムまたはＸＭＬベースのＡＰＩのものなどの要求および応答を指定するさまざまな方法に適合させることができる。

したがって、本発明では、個人化されたメッセージ配送を実現する（受信者は自分を望むときおよび望む方法でメッセージを受信する）。通知および応答システム１００は、電子メール、電話、Ｗｅｂページ、ポケットベル、またはファクスなどさまざまなサポートされている人間の言語および媒体形式をのうちの１つで、要求を配送し応答を収集することができる。さらに、通知および応答システム１００は、要求者および受信者の一括集中要求管理、応答照合、および既存のアプリケーションからの要求（および既存のアプリケーションへの応答）の透過的経路選択を行う。

要求
アプリケーション１１０は、特定の通知メッセージを１人または複数の受信者に送信し、その通知に対する応答を収集して要求者に返すか、または他のアプリケーションに転送することを求める要求を通知および応答システム１００に送信する。本明細書で使用しているように、要求は、（ｉ）通知メッセージ、（ｉｉ）要求パラメータ、（ｉｉｉ）通信フロー、および（ｉｖ）応答からなる。

通知メッセージ
アプリケーション１１０は、異なる媒体を介した、異なる人間の言語による配送をサポートするため、要求の１つまたは複数のバージョンを作成することができる。つまり、アプリケーション１１０は、受信者が受信するのを好む種類のドキュメントにサーブレットによって変換されるデータ・ファイルを作成し、その後、サーブレットのＵＲＬを通知および応答システム１００に受け渡す。たとえば、１人または複数の受信者に会合通知を送信することを望んでいるアプリケーション１１０は、応答がもしあればそのような応答を処理するためのフォームとともにメッセージを含むＨＴＭＬドキュメントを作成することができる。その後、このＨＴＭＬドキュメントは、Ｗｅｂサーバ上に格納され、ＵＲＬが通知および応答システム１００に渡される。

サーブレットを使用して特定の媒体形式でメッセージを生成する方法には、本発明の利点の１つが示されている。配送時にメッセージの媒体を受信者のニーズおよび環境設定に合わせて手直しし、配送時にメッセージの内容を生成することで、常に最新の情報が含まれるようにすることができる。たとえば、本発明で使用している媒体連絡の多くでは最初に、通知メッセージを取り出すために受信者が指定された電話番号に電話をかけなければならないことを指示するページまたは通知メッセージを含むＷｅｂページを指しているハイパーリンクを含む電子メール・メッセージなどの受信者が通知メッセージを利用できる状態にあることを示す情報を受信者に送る。その後、受信者が通知メッセージにアクセスすると、アクセス時点で最新バージョンの通知メッセージが表示される。このようにして、要求者は、受信者が実際に通知メッセージにアクセスするまで、通知メッセージを更新することができる。

要求パラメータ
要求は、関連する一組のパラメータを持つ。これらのパラメータにより、要求の振る舞いを制御したり、要求の形式を適切に定める（またはその両方を行う）通知および応答システム１００から利用できるようになっていなければならない情報を指定する。すでに示されているように、要求マネージャ１２００は、各要求に関する情報を格納している要求データベース３００を使用して送信されたすべての通知要求を追跡し、保留、取り消し、あるいは完了などのそれぞれの要求の現在ステータスを示す。

図３は、要求データベース３００の例からのサンプル・テーブルである。図３に示されているように、要求データベース例３００は、複数のレコード３０５〜３１５を備え、それぞれのレコードは異なる要求に関連付けられている。フィールド３３０で識別されている要求毎に、要求データベース３００に記録されているパラメータは、（ｉ）フィールド３３５内の要求者識別子（つまり、要求を生成した人またはアプリケーションの名前）、（ｉｉ）フィールド３４０内の応答宛先（たとえば、応答の転送先であるＵＲＬまたは応答の経路を選択する方法を示す通信フロー式、および照合された応答を要求の終了時に送信するか、各応答を受信時に転送するかを示す情報）、（ｉｉｉ）フィールド３４５内の件名（つまり、たとえば電子メールの件名行内で使用できる要求の簡単な説明）、（ｉｖ）フィールド３５０内の最大存続期間（つまり、すべての保留要求が取り消され、収集された応答が最終宛先に送信されるまで、通知および応答システム１００が通知の配送および応答の収集の試行を続ける時間の長さ）、（ｖ）フィールド３５５内の言語（つまり、有効な通知メッセージの言語）、（ｖｉ）フィールド３６０内のＨＴＭＬ、ＶＸＭＬ、およびプレーン・テキストなどのメッセージが利用可能なコンテンツ・タイプ、フィールド３６５内の通信フロー式、（ｖｉｉ）受信した応答が他の指定受信者から見えるか、または利用できるかを示すパブリック／プライベート・フラグ、および（ｖｉｉｉ）フィールド３７５内の要求の現在ステータスを含む。

件名見出しを含むそれぞれの通知メッセージの内容は、所定のアプリケーション１１０により１つまたは複数のサポートされている人間の言語で供給することができるか、または望ましいサポートされている人間の言語に自動的に翻訳できることに注意されたい。他のバリエーションでは、フィールド３５５内の言語パラメータは、言語翻訳を取得する方法と時期を指定する規則で置き換えることができ、またコンテンツ・タイプ・パラメータは、コンテンツ・タイプを生成する方法と時期を指定する規則で置き換えることができる。

通信フロー
後述のように、「通信フロー」という表題のセクションでは、通知および応答システム１００は、通信フロー式を使用して通信を行う際の、誰が、どのように、いつ、およびどこで、を指定する。通信フロー式により、要求の対象の受信者を指定する。受信者は、ロール（たとえば、「顧客サービス」）、人（たとえば、「Ｊｅｒｒｙ」）、アドバイス（たとえば、「８００−５５５−１２３４」）、ソフトウェア・アプリケーションまたはエージェント（たとえば、「カレンダー・エージェント」）、または他の通信フロー式とすることができる。さらに、通信フロー式では、受信者が要求をいつ、どのように、どこで受信するかを指定する。通信フロー式はさらに、特定の受信者が要求に対し正常に応答できなかった場合に実行すべきアクションを指定する。

通信フロー式では、アプリケーションの要件および受信者の環境設定を捕捉して組み合わせる。通信フロー式は、アクティブ受信者リストである。各受信者は、通信フロー内の名前を受信者の環境設定に応じていつ、どこで、どのように連絡するかに関する詳細で置き換える通信フロー規則を用意しているため、アクティブである。これらの通信フロー規則により、受信者は個人通信フローを要求の通信フロー式に組み込むことができる。受信者はこれらの規則を使用して、通信の環境設定を指定し、通信フローを送信者側の特性、要求のトピック、またはスケジュールの要求条件に合わせて手直しする。

応答
後述のように、「通信フロー」という表題のセクションで、通知および応答システム１００は、通信フローの中で成功テストを使用し、応答性側によって指定された対応を評価して特定の連絡が成功したか失敗したかを判別することができる。応答者側は、要求を受信し、応答を返した人である。応答が受信されると、通知および応答システム１００は各個別応答の属性値ペア、または要求が完了した後では、照合された結果を最初の要求で指定された最終宛先に転送する。一実施例では、通知および応答システム１００は、通信フロー全体が実行されるまで待機し、その後、結果を返すが、受信するときにそれぞれの応答を返すように修正することは自明なことである。

通信フロー
通信フローは、通信フロー式、成功指定、通信フロー規則、およびパラメータによって特徴付けられる。通信フロー式は、アプリケーションの通信要件をユーザーの通信環境設定に取り込む。通信フロー式により、要求に対する受信者を指定する（直接名前で、または定義されている受信者リストまたはロールを使用して）。さらに、通信フロー式では、受信者が要求をいつ、どのように、どこで受信するかを指定する。通信フロー式はさらに、特定の受信者が要求に対し正常に応答できなかった場合に実行すべきアクションを指定する。

通信フローの成功／失敗の指定
通信フローの成功指定では、通信フローにおける各ステップでの応答の成功および失敗に対する条件を記述する。この実施例では、通信フローの成功指定は、特定の通信フローに対してシステム規模のデフォルト成功指定および要求者定義のデフォルト成功指定の両方をサポートしている。それとは別に、要求者は、後述のテスト応答ステータス・プリミティブを使用して、通信フロー内の受信者毎に成功指定を指定することができる。

通信フローが２つの理由で失敗することがある。１つは、単に受信者と連絡を取れなかったか、または受信者がまったく通知に応答できない場合であって、通知失敗（その逆を通知成功）と呼ぶ。もう１つは、受信者と連絡を取ることができ、その後要求を拒絶するか、または否定的な応答をする場合であって、応答失敗（「ｎｏ」を示す）または応答成功（「ｙｅｓ」を示す）と呼ぶ。「ｎｏ」と「ｙｅｓ」は意味論的要素を持つが、それは、通信フローを継続する目的で要求に対して受信者が肯定的に応答（たとえば、「ｙｅｓ」という）したかどうかを判別することができる唯一のアプリケーションだからである。たとえば、応答成功は、受信者がドキュメントをレビューして、その受け入れを否決するときに生じることがある。受信者は「はい、レビューを終えました」と応え、通信フローは次のレビューアへ続く。その一方で、受信者がソフトウェアのリビジョンの要求をレビューし、拒絶した場合に応答失敗が発生する。受信者は、「いいえ、このソフトウェアのリビジョンは行いません」と応え、通信フローは終了するか、またはエラー処理へ進む。

本発明の一態様では、通信フロー式は、図４に示されている３値論理エバリュエータ４００を使用して評価する。この論理の３つの可能な値は、ステップ４２０での通知失敗（ｍａｙｂｅ）、ステップ４５０での応答失敗（ｆａｌｓｅ）、およびステップ４４０での応答成功（ｔｒｕｅ）である。図４に示されているように、通知成功は、応答成功または応答失敗の前に実行されるステップ４１０で識別される一時的状態であり、直接的に表されることはない。多数のデバイスが使用されている場合、受信者からの応答を受信したときに知ることができるのは、通知を受信したということだけである。

成功式では、受信者１２０から受信した応答に含めることができる変数に対する３値論理式を指定する。つまり、一般に、通知にはＨＴＭＬフォーム、ＶＸＭＬダイアログ、または相当するオブジェクトが含まれる。たとえば、フォームは、名前を応答者によって指定された値に関連付ける。成功式で、応答の中の値の論理的組み合わせを検査し、応答成功がある場合、連絡は「ｔｒｕｅ」に評価され、応答失敗がある場合、連絡は「ｆａｌｓｅ」に評価され、それ以外については、応答に対し時間の余裕がない場合、通知失敗があり、連絡は「ｍａｙｂｅ」に評価される。

たとえば、クリックされたときにボタンの値が「ｔｒｕｅ」に設定される「Ｓｕｂｍｉｔ」という名前の単一のボタンがある１つのフォームを含む通知が収められているＨＴＭＬページを考察する。このページに対する成功式は、「Ｓｕｂｍｉｔ＝ｔｒｕｅ」である。株価変更の通知には、値「ｂｕｙ」または「ｓｅｌｌ」を取ることができる「Ａｃｔｉｏｎ」という名前のラジオ・ボタンと数値を取ることができる「Ｑｕａｎｔｉｔｙ」という名前のもう１つの別のフィールドのペアを含めることができる。このページに対する成功式は、「Ａｃｔｉｏｎ＝ｂｕｙ ＆ Ｑｕａｎｔｉｔｙ＞１０００」である。たとえば、「Ａ ？ Ｓｕｂｍｉｔ＝「ｔｒｕｅ」？」は、Ａと連絡を取るという意味だが、成功検査をこれに指定すると、応答を受け取ったときに、応答により値「ｔｒｕｅ」がパラメータ「Ｓｕｂｍｉｔ」に割り当てられた場合その連絡を「ｔｒｕｅ」と定義する。「Ｓｕｂｍｉｔ」の値がｔｒｕｅ以外の場合、連絡は「ｆａｌｓｅ」であり、応答を受け取れる時間がもうない場合には連絡は「ｍａｙｂｅ」に評価される。

例には、２値論理に対する通信フロー式で使用する３値論理の利点が示されている。Ｊｏａｎｎとの連絡が成功した場合にはＴｏｍに連絡し、Ｊｏａｎｎとの連絡が失敗した場合にはＰｒｉｙａに連絡することを望んでいるとする。従来の２値論理プリミティブのｔｈｅｎおよびｅｌｓｅを使用すると、この関係は、次のように表すことができる。

（Ｊｏａｎｎ ｔｈｅｎ Ｔｏｍ）ｏｒ（Ｊｏａｎｎ ｅｌｓｅ Ｐｒｉｙａ）
そこで、さらに、Ｊｏａｎｎが同じ論理を使用して、携帯電話で、あるいは事務所の電話経由で失敗した場合、あるいは要求をＪｅｒｒｙに委託するするのに失敗した場合に、連絡を取ることを好んでいることを指定するものとする。

ｃｅｌｌ ｅｌｓｅ ｏｆｆｉｃｅ ｅｌｓｅ Ｊｅｒｒｙ
この式には固有の問題があるが、それは、要求者は間違いなく、Ｊｏａｎｎからの実際の応答の結果に基づいてＴｏｍまたはＰｒｉｙａと連絡を取りたがっており、ＪｏａｎｎはＰｒｉｙａが応答に失敗した場合にのみＪｅｒｒｙと連絡を取りたがっている（つまり、「ｎｏ」で応答する場合は連絡を取らない）からである。これらの結果すべてを従来の２値論理から得ることは不可能である。以下の項で説明するが、本発明の３値論理では、Ｔｏｍは、Ｊｏａｎｎが「ｙｅｓ」と言った場合のみ連絡が取られ、Ｐｒｉｙａは、Ｊｏａｎｎが「ｙｅｓ」で応答しなかった場合にのみ連絡が取られ、Ｊｅｒｒｙは、Ｊｏａｎｎがまったく応答できなかった場合にのみ連絡が取られる。

通信フロー受信者
すでに示しているように、通信フロー式は、要求に対する受信者および受信者から受け取った返信に対する応答での通信の方向を決める方法を指定する柔軟性の高い一般的な手法を提供する。一実施例では、図５に示されているように、受信者環境設定およびロール・データベース５００は、Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＬＤＡＰ）ディレクトリとして実現することができるが、これについては、たとえば、参照により本明細書に組み込まれているＭ．Ｗａｈｌ ｅｔ ａｌ．「Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ｖ３）」、ＲＦＣ ２２５１（１９９７年１２月）で説明されている。受信者環境設定およびロール・データベース５００は、通信フロー式内に現れる可能性のある受信者を記述したオブジェクトを保持する。図５に示されているように、受信者環境設定およびロール・データベース例５００は、複数のレコード５０５〜５２０を備え、それぞれのレコードは異なる受信者に関連付けられている。

フィールド５３０で識別されている受信者毎に、受信者と環境設定およびロール・データベース５００により、フィールド５４０内の受信者タイプとフィールド５５０で受信について定義されている個人通信フローが識別される。フィールド５４０に現れる受信者のタイプは、人、ロール、アプリケーション、デバイス、名前付き通信フロー、または個々の受信者と連絡を取るための方法である。人、ロール、または名前付き通信フロー・オブジェクトでは受信者と連絡を取るための通信フロー式を指定することができるが、個々の受信者またはアプリケーション（または媒体連絡オブジェクト）と連絡を取るための方法は受信者名の変換におけるターミナル・オブジェクトである（つまり、オブジェクトはディレクトリ内でさらに変換されないということである）。オブジェクトには、個人に対するエージェントとして動作することが可能な個人またはアプリケーションと連絡を取るのに重要な属性が含まれ、特に、アドレス、プロトコル、タイムアウト、および連絡を取る再試行間隔がある。

動的通信フロー式代入と呼ばれる本発明の他の態様では、受信者名を受信者環境設定およびロール・データベース５００内の情報にバインドする操作を連絡のときが来るまで遅らせる。したがって、本発明の遅延バインドの態様では、会社のＣＥＯなどのロールとして記述されている受信者は、システム１００がＣＥＯへの通知の試行を開始するまで変えられる。さらに、オフィス電話番号などの受信者の個人通信フローは、出張先の電話に切り替えることができ、出張が始まる前に送信した要求によりそのまま正常に使用できる。

媒体連絡で受信者と連絡を取る場合、受信者は、異なる通信フロー式を通信フロー内の自分の式の代わりに使用するよう要求することができる。このため、受信者はタスクをさらに多くの適切な受信者に動的に委託することができる。また、受信者は通信フロー内に遅延節を含む通信フロー式、たとえば、４時間遅れた後に要求を処理する催促を行う通知を生成する「Ｊｏａｎｎ ａｆｔｅｒ ＋０４：００」を代入することにより、タスクの実行を遅らせることができる。

図５は、さまざまな種類の受信者を説明する受信者環境設定およびロール・データベース５００内の多数のオブジェクト例を示している。受信者と環境設定およびロール・データベース５００で採用しているプリミティブの例について、以下の「プリミティブ」という表題の項で説明する。たとえば、レコード５０５に示されているように、受信者「Ｊｏａｎｎ」は次のような式ですべての要求に対する以下の個人の通信フローを指定する。

（ｃｅｌｌ ｒａｃｅｓ ｅｍａｉｌ）ｄｅｌｅｇａｔｅｓ Ｊｅｒｒｙ
したがって、Ｊｏａｎｎに連絡する場合、Ｊｏａｎｎの携帯電話に電話をかけ、それと同時に電子メールをＪｏａｎｎに送信しなければならない。Ｊｏａｎｎが応答しない場合、Ｊｅｒｒｙに、Ｊｏａｎｎの代わりに要求を受け取るよう連絡する（Ｊｅｒｒｙの個人通信フローに従って）。Ｊｏａｎｎが自分で要求に応答した場合、Ｊｅｒｒｙに対してはまったく連絡がいかない。

レコード５１０に示されている例では、ロールＳｙｓＡｄｍｉｎが、現在の交代に関する要求の経路を管理者に設定する個人通信フローを指定する。
（Ｓａｍ ｂｅｔｗｅｅｎ ０８：００−１６：５９ ｏｒ Ｓｕｅ ｂｅｔｗｅｅｎ １７：００−００：５９ ｏｒ Ｇｒｅｇ ｂｅｔｗｅｅｎ ０１：００−０７：５９）ｄｅｌｅｇａｔｅｓ ＳｙｓＡｄｍｉｎ
レコード５１０内のロールにより、午前８時から始まる平日の特定の時間に働いているシステム管理者に要求が回される。要求処理の第１作業日にどの管理者とも連絡がつかない場合、かっこ内の節は失敗し、再帰的ＳｙｓＡｄｍｉｎ参照により次の日に連絡試行が繰り返される。

受信者への再帰的参照、たとえば、ＳｙｓＡｄｍｉｎロールでの再帰的参照は、他の終了条件が存在している場合に限り通信フロー内の順次プリミティブをたどることを許されることに注意されたい。ＳｙｓＡｄｍｉｎの例では、要求は、応答を受信した場合にｔｒｕｅまたはｆａｌｓｅで完了し、要求者設定タイムアウトが発生した場合に通知失敗（ｍａｙｂｅ）で完了する。

このような予防をしていても、ディレクトリ内で循環名前参照をループする可能性がある。たとえば、Ｊｏａｎｎの通信フロー式で「Ｔｏｍ」と言い、Ｔｏｍの通信フロー式で「Ｊｏａｎｎ」と言うことができる。この場合も、並列再帰的参照と順次再帰的参照とを区別することにより、無統制の大量のリソースが消費されるループが回避される。他に終了条件のないすべての並列循環参照および順次循環参照は、名前変換履歴を通じて防止される。ＪｏａｎｎおよびＴｏｍに関する前の例はエラーとなるが、Ｊｏａｎｎの通信フロー式が電子メールを介して連絡を取ろうとし、失敗の場合にＴｏｍに委託し、Ｔｏｍの通信フロー式は単にＪｏａｎｎに戻す（Ｔｏｍが休暇中であるため）という状況は受け付けられる。同じ受信者に素早くループする、あるいは長期間にわたってループする要求に対する最終的な予防として、通信フロー式は、受信者に対する連絡の指定最大試行回数を超えたときにエラーを返すことができる。

図５の例を続行するには、レコード４１５の名前付き通信フローで、レビューのため並行して連絡を取らなければならない受信者のリストを指定する。
Ｃｈｒｉｓ ａｎｄ Ｊｅｒｒｙ ａｎｄ Ｂｅｎｊｉ ａｎｄ Ｊｅｎｎｙ
すべてのレビューアが正常に応答した場合、レビューアに対する要求は成功する。以下の「通信フローのプリミティブ」という表題の項で説明しているように、「ｖｏｔｅｓ」プリミティブを使用して、このリストに対する成功基準を変更することができる。
たとえば、
Ｒｅｖｉｅｗｅｒｓ ｖｏｔｅｓ ２
は、２人のレビューアが正常に応答した場合に正常に完了する。

受信者環境設定およびロール・データベース５００内の媒体連絡オブジェクトもエージェントであってよいことに注意されたい。たとえば、カレンダー・エージェントは、以下の通信フロー内で結合された３つの媒体連絡を供給することができる。
ＨｏｌｄＣａｌ ｔｈｅｎ（Ｃｅｌｌ ｔｈｅｎ ＳｃｈｅｄｕｌｅＣａｌ ｅｌｓｅ ＣａｎｃｅｌＣａｌ）
ＨｏｌｄＣａｌで利用可能な要求データが見つかると、携帯電話でユーザーに連絡を取り、会合目的の承認を得る。ユーザーが会合目的を承認した場合、会合時間のスケジュールを決定し、そうでなければ、会合は取り消される。

ＬＤＡＰディレクトリ・ツリー
図６は、多数の受信者の個人名前付けコンテキストを示すＬＤＡＰディレクトリ・ツリー６００の一部を示している。ＬＤＡＰディレクトリ・ツリー６００は、受信者環境設定およびロール・データベース５００に記録されているユーザーの環境設定の表現である。たとえば、図６に示されているＬＤＡＰディレクトリ・ツリー６００は、受信者Ｊｏａｎｎの個人名前付けコンテキスト６１０と受信者Ｔｏｍの個人名前付けコンテキスト６２０を含む。受信者Ｊｏａｎｎの個人名前付けコンテキスト６１０では、規則、通信フロー式、および媒体連絡を定義している。受信者Ｔｏｍは、デフォルトの規則、通信フロー式、および媒体連絡を使用する。

通信フローの規則およびパラメータ
通信フローの規則では、受信者名をいつ特定の個人通信フロー式に変換するかを指定する。受信者は、タイトルおよび要求者パラメータなどの、特定の要求に対してどの個人通信フロー式を使用するかを制御する、要求のパラメータに関する条件を指定することができる。たとえば、受信者は、タイトルで表されるときには特定のトピック、または携帯電話による即時注意の要求者を選択することができる。電子メールまたはＷｅｂで後から注意するある種の要求を選択することができる。

他の環境設定に基づくシステムとは異なり、通信フロー・マネージャ１３００の環境設定処理は、要求の配送を処理するこに組み込まれている一般的なメカニズムである。受信者１２０の規則および個人通信フロー式により、その受信者１２０の個人名前付けコンテキスト６１０が確立される。受信者の名前および受信者が規則または通信フロー式内にある名前は、受信者のコンテキストに応じて変換される。他のコンテキストに基づく名前付けシステムとは異なり、この規則に基づく環境設定処理では、名前の大域的な意味を隠さない。大域的名前は、常に見えたままである、全員が使用できる。このような理由から、受信者は特定の種類の要求を誰か他の人に委託したいことを指定するために大域的名前を簡単に使用することができる。個人名前付けコンテキスト６１０では、受信者のコンテキストにとって重要であり適切である変換を実行するが、意味のある大域的名前をサポートしている。

したがって、図６に示されているように、Ｊｏａｎｎの個人名前付けコンテキスト６１０は、３つの通信フロー規則に対応するノード、つまり、マネージャ規則６３０、家族規則６４０および事務処理規則６５０を含む。受信者の個人名前付けコンテキスト６１０などの各受信者の個人名前付けコンテキストをＬＤＡＰディレクトリ・ツリー６００にあるＩｎｅｔＯｒｇＰｅｒｓｏｎ｛ＲＦＣ２７９８｝またはＩｎｅｔＯｒｇＲｏｌｅオブジェクトを根とする部分ツリーとして確立する。ＬＤＡＰ内のＩｎｅｔＯｒｇＰｅｒｓｏｎオブジェクトは、人々に関する連絡情報を記述するＬＤＡＰ標準オブジェクトであり、ＩｎｅｔＯｒｇＲｏｌｅオブジェクトは、ＬＤＡＰ標準オブジェクト・クラスＯｒｇＲｏｌｅ｛ＲＦＣ２２５６｝の部分クラスである。たとえば、図６で、Ｊｏａｎｎの個人名前付けコンテキスト６１０は「ＵＩＤ＝ｊｏａｎｎ」というラベルが付いているＩｎｅｔＯｒｇＰｅｒｓｏｎノードをルートとする。

それぞれの個人名前付けコンテキスト６１０は、通信フロー式、名前付き通信フロー式、および媒体連絡オブジェクトを処理する通信フロー式に関係する３種類のオブジェクトを備えることができる。図６では、個人名前付けコンテキスト６１０の一番上の３つのエントリ６３０、６４０、６５０は、ＭｇｒＲｕｌｅ、ＦａｍｉｌｙＲｕｌｅ、およびＰａｐｅｒｗｒｋＲという名前を持つ３つの通信フロー式を表している。ノード６６０、６７０、６８０は、それぞれ、ｗｅｂ、ｃｅｌｌ、およびｅｍａｉｌという名前が付けられた３つの媒体連絡オブジェクトに対応している。ノード６９０、６９５は、ＵｒｇｅｎｔＣＦおよびＲｅｌａｘｅｄＣＦという２つの名前付き通信フロー式に対応している。

Ｊｏａｎｎによって指定されたマネージャ規則６３０、家族規則６４０、および事務処理規則６５０は、受信者環境設定およびロール・データベース５００で定義される。マネージャ規則６３０、家族規則６４０、および事務処理規則６５０を定義する受信者環境設定およびロール・データベース５００からの対応するオブジェクトは、図７に示されている。特に、受信者環境設定およびロール・データベース５００は、マネージャ規則６３０を定義するレコード７１０、家族規則６４０を定義するレコード７２０、および事務処理規則６５０を定義するレコード７３０を含む。

図７に示されているような、それぞれの通信フロー規則は、アクティブ、順序、条件、および通信フロー式という４つの属性を含む。アクティブは、「ｙｅｓ」または「ｎｏ」に設定される。非アクティブである規則、つまり、「ｎｏ」に設定されている規則は、受信者の名前を個人通信フローに変換する場合には考慮されない。順序属性は、評価対象の名前付けコンテキスト６１０内のすべてのアクティブ規則の順序を指定する場合に使用される。ｏｒｄｅｒ内のそれぞれの規則の条件が次に検査される。条件は、等式、不等式、範囲、および正規表現マッチングなどの属性値比較からなる論理式である。条件が満たされると、要求配送のため、受信者の名前が随伴する通信フロー式に変換される。ＭｇｒＲｕｌｅの条件では、ユーザー名またはｕｉｄで特定の要求者を検査する。ＦａｍｉｌｙＲｕｌｅの条件では、「Ｆａｍｉｌｙ」で始まるタイトルを検査する。ＰａｐｅｒｗｒｋＲの条件は、常に満たされる。ＰａｐｅｒｗｒｋＲは、他の規則が満たされない場合に適用されるデフォルトの規則である。このため、その順序番号は最高位の番号である。

図７に示されているように、レコード７１０、７２０、および７３０の規則例ではそれぞれ、少なくとも１つの名前付き通信フロー式（ｕｒｇｅｎｔＣＦ ６９０またはｒｅｌａｘｅｄＣＦ ６９５）を参照している。ｕｒｇｅｎｔＣＦまたはｒｅｌａｘｅｄＣＦ通信フロー式は、以下のように、受信者環境設定およびロール・データベース５００内の名前付き通信フロー式として定義することができる。

ＵｒｇｅｎｔＣＦ：ｃｅｌｌ ｒａｃｅｓ ｏｆｆｉｃｅｐｈｏｎｅ ｒａｃｅｓ ｈｏｍｅｐｈｏｎｅ
ＲｅｌａｘｅｄＣＦ：ｅｍａｉｌ ｒａｃｅｓ ｗｅｂ
この方法では、名前付き通信フロー式により、受信者Ｊｏａｎｎは、規則で指定されている条件に基づき連絡のためさまざまな規則を確立することができる。

規則を構成する場合、連絡の共通方法の名前付き通信フロー式を作成すると便利なことが多い。この方法で、受信者は名前付き通信フロー式内の特定の環境設定を１回更新することができ、変更された名前付き通信フロー式を参照するすべての通信フロー式が自動的に更新される。その後、ときにはさまざまな目的のために同じ名前付き通信フローを使用して、規則で名前付きフローを参照できる。規則ＰａｐｅｒｗｒｋＲでは、単純に名前付き通信フロー（ｒｅｌａｘｅｄＣＦ ６９５）を使用するだけである。規則ＭｇｒＲｕｌｅでは、受信者に緊急連絡を取ることができる場合に対して時間的制約を加え、いつでも緩和された連絡通信フローを使用する。規則ＦａｍｉｌｙＲｕｌｅでは、利用可能なすべての媒体連絡を使用する。

通信フロー規則を使用すると、さらに、企業の従業員は段階的に緊急応答を行うことができる。たとえば、企業が顧客からの要求に即時応答しなければならず、要求はキーワード「ｕｒｇｅｎｔ ｂｕｓｉｎｅｓｓ」を含むタイトルとともに顧客から受信する。さらに、企業の少なくとも１人の従業員が以下の通信フロー規則を指定していると仮定する。
Ｔｉｔｌｅ＝「＊Ｕｒｇｅｎｔ Ｂｕｓｉｎｅｓｓ＊」；
Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｌｏｗ：（ｃｅｌｌｐｈｏｎｅ ｒａｃｅｓ ｐａｇｅｒ）ｂｅｆｏｒｅ ＋０：０５ ｄｅｌｅｇａｔｅｓ ｍａｎａｇｅｒ

「ｍａｎａｇｅｒ」は、正しいマネージャを見つけるために受信者のディレクトリ・エントリ内のマネージャ・リンクを使用するデフォルトの名前付き通信フローである。キーワード「ｕｒｇｅｎｔ ｂｕｓｉｎｅｓｓ」を含むタイトルとともに要求を受信したときに、段階規則がトリガされる。従業員が５分以内に自分の携帯電話またはポケットベルに出ない場合、要求は上位レベルの「ｍａｎａｇｅｒ」に伝達される。

通常、段階処理を行う通信フローでは、要求が次の上位レベルに回される前に取り消される場合にｄｅｌｅｇａｔｅｓプリミティブを使用する。他のバリエーションでは、通信フローは、連鎖の前の方にいる人々への未処理要求を取り消さずに段階処理を実行できる。たとえば、以下の通信フロー例は、連鎖の前の方にいる人々への未処理要求を取り消さずに段階処理を実行する。

（Ｔｏｍ ｅｌｓｅ Ｍａｎａｇｅｒ）ｒａｃｅｓ（Ｍａｎａｇｅｒ ａｆｔｅｒ ＋０４：００）
この通信フローは、最初に、Ｔｏｍだけと連絡を取り、初期応答が失敗した場合に即座に定義済みのＭａｎａｇｅｒに連絡する。さらに、４時間経過したら要求を１段上のＭａｎａｇｅｒに伝え、ＴｏｍまたはＭａｎａｇｅｒからの第１の応答のみが受け付けられる。通信および応答システム１００は任意選択により、指定された要求が取り消された理由に関する情報を保持し、そのような情報を取り消された要求と関連する受信者に供給することができる。

この通信フロー式では、最適化を使用することにより、受信者指定Ｍａｎａｇｅｒが同時に通信フロー内で２回アクティブになっている可能性があるという事実があろうと、１回Ｍａｎｇａｇｅｒと連絡を取る。受信者名の各インスタンスは、その要求に寄与したエンティティ、つまり、要求者、または個人通信フローに関わるロールにより所有される。受信者名により同じオブジェクト／受信者が識別され、受信者名の所有者が同じである場合、受信者はそれらの名前に関して１回だけ連絡が取られる。所有者が異なる場合、受信者が所有者の代理として異なる方法で行動したがっていると仮定する、したがって受信者は、要求を受信者に委託した人に関する記録により複数回連絡が取られる。

受信者環境設定およびロール・データベース５００およびＬＤＡＰディレクトリ・ツリー６００に記録されているユーザーの環境設定は、図５〜７に関して上で説明したように、存在および利用可能性の情報により修正することができる。たとえば、受信者は、次のように、自分の環境設定を指定することができる。
（ｐｒｅｓｅｎｔ（ｃｅｌｌ）ｔｈｅｎ ｃｅｌｌ）ｄｅｌｅｇａｔｅｓ（ｐｒｅｓｅｎｔ（ｅｍａｉｌ）ｔｈｅｎ ｅｍａｉｌ）

ｐｒｅｓｅｎｔ機能により、携帯電話媒体連絡に使用できる受信者およびデバイス情報により存在サーバと連絡を取る。携帯電話がオンになっていることを存在サーバが示した場合、ｐｒｅｓｅｎｔ機能は「ｔｒｕｅ」を返す。そうでなければ、「ｍａｙｂｅ」を返す。同様に、受信者が電子メール媒体連絡に対しネットワーク上に存在している場合、ｐｒｅｓｅｎｔ機能は「ｔｒｕｅ」を返す。そうでなければ、「ｍａｙｂｅ」を返す。受信者が携帯電話を使用できる状態にある場合、携帯電話で連絡が取られる。受信者が携帯電話を使用できる状態にない、または連絡が失敗した場合、ネットワークがチェックされ、受信者がそこにいれば電子メールが送信される。ｐｒｅｓｅｎｔ機能は、存在サーバによって提供される機能にもよるが多かれ少なかれ高度なものである。また、通信フロー規則により、受信者は存在サーバを通じてアクセスできる要求者または要求の種類を制限することもできることに注意されたい。

存在および利用可能性の情報の他の応用では、媒体連絡は、存在情報が失敗（たとえば、携帯電話のスイッチがオフになっている）を示す通信試行（たとえば、電話呼び出し）をスキップすることでその動作を最適化することができる。媒体連絡は、単に、電話をかけようとして失敗したかのように先へ進むことができる。

ユーザーの環境設定は、企業側で決定することもできる。たとえば、企業は、顧客の支払い履歴に基づいて、侵襲性の度合いの高い顧客に通知を送信することができる。たとえば、以下の「ｄｅｌｅｇａｔｓ」プリミティブの項で詳述するように、支払い履歴が芳しくない顧客は、自動電話呼び出しにより１回目の延滞通知を受け取り、集金代行業者を通じて２回目の延滞通知を受け取るようにできる。支払い履歴が平均的な顧客は、１回目の延滞通知を郵便で受け取り、２回目の延滞通知を自動電話呼び出しで受け取り、３回目の延滞通知を集金代行業者を通じて受け取るようにできる。

ディレクトリのデフォルトおよび発見的手段
図１３に関して以下で詳述する通信フロー・マネージャ１３００は、短時間で導入でき、使いやすいため、ＬＤＡＰディレクトリ・ツリー６００（図６）のデフォルト・ディレクトリを採用している。通信フロー・マネージャ１３００もまた、ディレクトリの検索時に発見的手法を採用することにより使い勝手を向上させる。通信フロー・マネージャ１３００は、まず企業側にインストールされると、通信フロー・マネージャ１３００は、既存の企業ＬＤＡＰディレクトリ５００から外れる。企業ＬＤＡＰディレクトリ５００の構成に関する情報に加えて、通信フロー・マネージャ１３００では、アプリケーション特有のオブジェクト（つまり、通信フロー、通信フロー規則、媒体連絡、強化されたロールおよび構成オブジェクト）に対しオブジェクト・クラスを作成する必要がある。

通信フロー・マネージャ１３００は、さらに、その構成および他のオブジェクトのデフォルト・インスタンスを格納できるディレクトリ・サブツリー６００を作成する必要もある。デフォルト・ディレクトリを使用して、企業ディレクトリ内にすでに存在している人々およびロールに通信フロー・サービスを提供する。これらの人々およびロールは、受信者およびその企業の裁量で、個人化された通信フローおよび規則で強化することができる。

媒体連絡オブジェクトのデフォルト・インスタンスでは、自分の媒体連絡オブジェクトを指定するユーザーからも利用できる代入機能を使用する。媒体連絡オブジェクト内のアドレス・フィールドでは、角かっこを使用して、対象の受信者のＬＤＡＰディレクトリ・エントリ内の属性の名前を指定することができる。その属性の値は、もし存在すれば、オブジェクトの取り出し後、アドレス・フィールド内の角かっこで囲まれた属性名を置き換える。たとえば、＜ｍｏｂｉｌｅ＞は、媒体連絡オブジェクトのアドレス・フィールドを、意図された受信者Ｊｏａｎｎを記述するｉｎｅｔＯｒｇＰｅｒｓｏｎオブジェクト内のｍｏｂｉｌｅの値で埋めるさらに高度な代入手法も可能であり、本発明の範囲内にある。

媒体連絡オブジェクトのデフォルト・インスタンスとともに、通信フロー・マネージャ１３００では、デフォルトの名前付き通信フロー式およびデフォルト通信フロー規則を作成する。通知および応答システム１００の例では、デフォルトでは、受信者の電子メール・アカウントおよびＷｅｂポータル（電子メール・レースＷｅｂ）にすべての要求を送信する。デフォルトはすべて、企業側でニーズに合わせて変更することができ、デフォルト・オブジェクトは、個人通信フロー式および通信フロー規則を構成するユーザーから利用できる。

エントリの完全な識別名は、扱いにくく、直感的でない。そこで、通信フロー・マネージャ１３００では、短い名前での発見的探索を使用して必要なオブジェクトを特定する。オブジェクトの完全な識別名は、通信フロー式内で識別名を各角かっこで囲むことにより、たとえば、＜ｕｉｄ＝ｊｏａｎｎ，ｏｕ＝ｐｅｏｐｌｅ，ｏ＝ｒｅｓｅａｒｃｈ．ａｖａｙａ．ｃｏｍ＞として指定する。本明細書の例では、短い名前だけを使用してきた。

名前に遭遇すると、通信フロー・マネージャ１３００は、人々、ロール、名前付き通信フロー、または個人名前付けコンテキストを適宜格納するために使用するディレクトリ部分ツリー、たとえば、６１０、６２０を探索する。通信フロー・マネージャ１３００は、短い名前を部分ツリー内のエントリの相対的識別名と比較することにより探索する。マッチングが見つからなければ、通信フロー・マネージャ１３００は、その後、デフォルト・ディレクトリを探索してから、エラーを返す。

外部組織が通信フロー・マネージャをインストールしていなくても、ローカル通信フロー・マネージャ１３００を通じて、企業または他の企業群の他の部分と連絡を取ることができる。外部組織にＬＤＡＰディレクトリ５００がある場合、２つの方法で通信フロー・マネージャ１３００の名前空間内に組み込むことができる。まず、応答のため外部のディレクトリに連鎖している「ｓｍａｒｔ ｒｅｆｅｒｒａｌ」または他のメカニズムを使用して、外部ディレクトリをローカル・ディレクトリに組み込む。この場合、デフォルトまたは個人通信フロー情報がそこで利用できない場合には必ず、ローカル・ディレクトリに対する通信フローのデフォルトが外部ディレクトリに適用される。次に、ａｄｖ＿ｓｅａｒｃｈプリミティブにより、外部ディレクトリの連絡情報を記述し、要求者側で使用することができる。デフォルトが必要なすべての場合に、通信フロー・マネージャ１３００のデフォルトおよび構成を外部ディレクトリに格納するディレクトリ部分ツリーの名前が通信フロー・マネージャ１３００の提案された規約と一致していない限りローカル・デフォルトが使用される。このような理由から、ＬＤＡＰディレクトリで通信フロー・マネージャ１３００の推奨部分ツリー名をサポートするよう推奨する。通知および応答システム１００の例では、その名前は次のとおりである。
＜ｏｕ＝Ｘｕｉ Ｓｅｒｖｅｒ，ｏ＝ｄｏｍａｉｎ−ｎａｍｅ−ｏｆ−ｓｅｒｖｅｒ＞

要求者は、ときおり、ディレクトリ内にいないが、連絡したい連絡先の個人の住所録を用意していることがある。時々、要求者は、電話などの特定の媒体タイプで特定の個人と連絡を取ることを強く好んでいることがある。これらの場合には、要求者は、ディレクトリ内の要求者の個人名前付けコンテキストの中にあるそれらの個人の個人名前付けコンテキストを作成することができる。他の人のそれぞれの個人名前付けコンテキストは、その人のｉｎｅｔＯｒｇＰｅｒｓｏｎエントリを含み、さらに、ｉｎｅｔＯｒｇＰｅｒｓｏｎエントリをルートとする部分ツリー内の通信フロー規則、媒体連絡、および名前付き通信フローを含む。次に、要求者は、自分の要求に対する通信フロー内の各受信者の完全識別名を指定する。

通信フロー・マネージャ１３００では、受信者に対して要求者１１０により指定された通信フローを使用する。システムの強化では、デフォルトを探索し、まず要求者のツリー内に短い名前がないか調べ、次にディレクトリの人々およびロールの部分ツリーを調べ、そして最後に、ディレクトリのデフォルト部分ツリー内を調べることによりアルゴリズムを拡張する。このような手法は、受信者の環境設定に対する指定に反しており、ディレクトリに載っていない受信者または受信者の環境設定に関連性がないか、従う必要のないアプリケーションにしか使用されない。

通信フローのプリミティブ
すでに述べたように、通信フロー式では、要求を受け取る受信者、および受信者が要求を受け取る仕方、いつ受け取るか、およびどこで受け取るかを指定する。通信フロー式に含まれるプリミティブは、受信者に同時に連絡するかまたは順次連絡するか、および成功検査結果の論理結合を定義することによりいつ部分式の実行を終了すべきかを指定する。図８は、一組の通信フロー式のプリミティブの例を示すサンプル・テーブルである。図９Ａ〜図９Ｅは、図８に示されているさまざまなプリミティブに対する真理値表の図である。図９Ａ〜９Ｅで、「Ｆ」はｆａｌｓｅの応答を、「Ｔ」はｔｒｕｅの応答を、「Ｘ」はｍａｙｂｅの応答を示す。図９Ａ〜９Ｅのそれぞれの左欄は、応答する第１オペランドを示し、最上位行は第２オペランドが応答することを示している（単一のオペランド「ｎｏｔ」プリミティブ以外のすべてのプリミティブについて）。Ｔ、Ｘ、またはＦの「ｂ」下付添え字は、指示された値を取得するために両方のオペランドを評価しなければならないことを示している。プリミティブにより、要求の流れが受信者に向かう。具体的には、プリミティブでは、並行または順次通信の方向と受信者との通信の状況を通信フローにどのような影響を及ぼすかということの評価と組み合わせる。他のプリミティブは、連絡を取る時期またはディレクトリのオブジェクトのリストから通信フローを構築する方法を制御する。

プリミティブは、当然、ａｎｄ／ｔｈｅｎ、ｏｒ／ｅｌｓｅ、ｒａｃｅｓ／ｄｅｌｅｇａｔｅｓ、およびｖｏｔｅｓ／ｐｏｌｌｓのように並行／順次のペアにグループ化することができる。並行プリミティブと順次プリミティブは、オペランドの評価方法が異なる。並行プリミティブでは、それぞれの受信者に並行して連絡を取る。処理要求は、プリミティブのｔｒｕｅ値を決定するためにもはや必要なくなれば取り消される。順次プリミティブでは、要求は現れる順序でそれぞれの受信者に送られる。受信者が応答すると、要求は次の受信者に送信され、必要ならば、プリミティブのｔｒｕｅ値を決定する。それぞれのプリミティブは、受信者との通信が成功したかどうかに応じてｔｒｕｅ、ｆａｌｓｅ、またはｍａｙｂｅに評価される。

Ａｎｄ／Ｔｈｅｎ
「ａｎｄ」プリミティブでは、並行して２人の受信者と連絡を取ること、および両方の受信者が成功で応答した場合に通信フローが成功している（ｔｒｕｅに評価される）ことを指定する。受信者のうちの一方への要求が失敗した場合、「ａｎｄ」プリミティブはｆａｌｓｅに評価され、他方の受信者への要求は可能であれば取り消される。他のすべての場合は、「ａｎｄ」プリミティブはｍａｙｂｅに評価される。「ａｎｄ」に対する真理値表は図９Ａに示されており、第１オペランドが応答する値は、各行の左に沿ってあり、第２オペランドが応答する値は各列の上段に沿ってある。

「ｔｈｅｎ」プリミティブは、「ａｎｄ」の順次形式である。つまり、受信者は、現れた順に一度に１人ずつ連絡が取られ、第２の受信者は、第２の受信者が成功で応答した場合のみ連絡が取られる。図９Ｂに示されている「ｔｈｅｎ」の真理値表は、第１のオペランドがｍａｙｂｅを返し、第２のオペランドがｆａｌｓｅを返したときの「ａｎｄ」プリミティブの真理値表と異なる。「ｔｈｅｎ」プリミティブの場合には第２オペランドは評価されず、「ｔｈｅｎ」プリミティブの真理値がｍａｙｂｅのままであるが、「ａｎｄ」プリミティブの場合は、第２オペランドが評価され、プリミティブはｆａｌｓｅを返す。この選択は、「ｔｈｅｎ」プリミティブに対して行われており、より自然な意味論的解釈を行える。

Ｏｒ／Ｅｌｓｅ
「ｏｒ」プリミティブでは、並行して２人の受信者と連絡を取ること、および受信者のうち少なくとも一方が成功で応答した場合に通信フローが成功している（ｔｒｕｅに評価される）ことを指定する。両方の受信者が否定的応答をした場合、プリミティブはｆａｌｓｅに評価される。他のすべての場合には、プリミティブはｍａｙｂｅに評価される。「ｏｒ」プリミティブの真理値表は図９Ｃに示されている。

「ｅｌｓｅ」プリミティブは、「ｏｒ」プリミティブの順次形式であり、第２受信者は、第１の応答が成功しなかった場合にのみ連絡が取られる。「ｅｌｓｅ」プリミティブの真理値表は図９Ｃに示されている「ｏｒ」プリミティブと同じである。「ｅｌｓｅ」プリミティブの場合、第２オペランドは、第１オペランドがｍａｙｂｅまたはｆａｌｓｅに評価された場合にのみ評価される。「ｅｌｓｅ」演算子が用意されており、第１受信者が「ｎｏ」と応えるか、または応答に失敗（ｍａｙｂｅ）した場合のみ第２受信者に連絡を取るシナリオに対処している。

Ｒａｃｅｓ／Ｄｅｌｅｇａｔｅｓ
ａｎｄ／ｔｈｅｎ、ｏｒ／ｅｌｓｅプリミティブは、通信フロー式の成功または失敗を判別するために、十分な受信者に連絡を取ることにすべて集中している。ときには、多くの可能な応答のうちの第１のものを受け付けるのがよいこともある。これは、成功するか、または不可能になるまで票を数えるので、既存のプリミティブではできない。並行プリミティブ「ｒａｃｅｓ」は、応答するオペランドのうちの第１のもののステータスに応じて成功または失敗する。第１の応答者が成功した場合、「ｒａｃｅｓ」プリミティブは成功する。第１の応答者が失敗した場合、「ｒａｃｅｓ」プリミティブは失敗する。第２の応答者に対する要求は、可能であれば取り消される。たとえば、
Ｃｅｌｌ ｒａｃｅｓ Ｏｆｆｉｃｅ ｒａｃｅｓ Ｅｍａｉｌ ｒａｃｅｓ Ｗｅｂ
は、携帯電話、事務所の電話、電子メール、またはＷｅｂポータルの媒体連絡のどれかを経由して受信者から受け取った第１の応答に応じて成功または失敗する。

本明細書で説明している他のプリミティブとは異なり、「ｒａｃｅｓ」プリミティブは、一方のオペランドからの成功または失敗応答に対して等しい重みを付ける。ａｎｄ／ｔｈｅｎプリミティブは、オペランドの失敗には即座に応答するが、両方のオペランドから結果が返るのを待ち、その後、成功を返す。ｏｒ／ｅｌｓｅプリミティブは、オペランドの成功には即座に応答するが、両方のオペランドから結果が返るのを待ち、その後、失敗を返す。「ｒａｃｅｓ」プリミティブは、オペランドからの第１の応答に対して即座に応答し、そのオペランドの結果を返す。これは特に、上の例で示されているように、複数のデバイスを経由して個人に連絡し、個人がそれらのデバイスのうちの１つだけを介して成功または失敗とともに要求に応答することができるため有用である。「ｒａｃｅｓ」プリミティブは、他のプリミティブから指定することはできない。「ｒａｃｅｓ」の真理値表は図９Ｄに示されている。

「ｄｅｌｅｇａｔｅｓ」プリミティブは、「ｒａｃｅｓ」プリミティブの順次形式である。「ｄｅｌｅｇａｔｅｓ」プリミティブの真理値表は「ｒａｃｅｓ」プリミティブと同じである。「ｄｅｌｅｇａｔｅｓ」プリミティブは、左オペランドが通知失敗（ｍａｙｂｅ）を返した場合にのみ右オペランドを評価する。「ｒａｃｅｓ」プリミティブと同様に、「ｄｅｌｅｇａｔｅｓ」プリミティブは、他のプリミティブから指定することはできない。

上述の例に戻ると、Ｊｏａｎｎは自分の環境設定を次のようにして指定することができる。
ｃｅｌｌ ｄｅｌｅｇａｔｅｓ ｏｆｆｉｃｅ ｄｅｌｅｇａｔｅｓ Ｊｅｒｒｙ
その一方で、要求の生成側では以下のように指定する。
（Ｊｏａｎｎ ｔｈｅｎ Ｔｏｍ）ｏｒ（Ｊｏａｎｎ ｅｌｓｅ Ｐｒｉｙａ）
Ｊｅｒｒｙは、Ｊｏａｎｎが応答に失敗した場合にのみ応答する。Ｔｏｍに対しては、ＪｏａｎｎまたはＪｅｒｒｙが、Ｊｏａｎｎの不在中に「ｙｅｓ」と応える場合にのみ連絡が取れる。ＪｏａｎｎもＪｅｒｒｙも応答しない、あるいは両者とも「Ｎｏ」と返事した場合、Ｐｒｉｙａに連絡を取る。

「ｒａｃｅｓ」プリミティブが作られたのは、複数の同時デバイスを経由して１人の人と連絡を取る必要があるということが動機となっている。たとえば、受信者は携帯電話と事務所の電話の両方に通知を送るということを指定できる場合がある。受信者が自分の事務所の電話で応答した場合、その応答は、成功、失敗に関係なく、携帯電話への保留連絡にも適用すべきである。「ａｎｄ」および「ｏｒ」プリミティブは、この要求条件を満たしていなかった。「ｄｅｌｅｇａｔｅｓ」プリミティブでは、たとえば、第１受信者が応答しない場合のみ第２受信者に連絡を取るシナリオを扱うことができるか、あるいは受信者と連絡が取れるまで一連のデバイスの探索を順次続けてゆく。

すでに述べているように、ｄｅｌｅｇａｔｅｓプリミティブを使用すると、企業では、個人化された要求配送を段階的に行うことができる。たとえば、代金取り立て業務にかかわる企業は、次のように、顧客との関係履歴に基づき、それぞれの顧客の個人通信フローを用意することができる。
ｇｏｏｄ ｃｒｅｄｉｔ ｃｕｓｔｏｍｅｒｓ：ｗｅｂ ｄｅｌｅｇａｔｅｓ ｅｍａｉｌ ｄｅｌｅｇａｔｅｓ ｓｍｓ ｄｅｌｅｇａｔｅｓ ｈｏｍｅｐｈｏｎｅ
ｐｏｏｒ ｃｒｅｄｉｔ ｃｕｓｔｏｍｅｒｓ：ｈｏｍｅｐｈｏｎｅ ｄｅｌｅｇａｔｅｓ ｏｆｆｉｃｅｐｈｏｎｅ ｄｅｌｅｇａｔｅｓ ｃｅｌｌ
したがって、顧客がそれぞれの要求に対する応答を失敗すると、要求は次の連絡方法へ格上げされる。
ｖｏｔｅｓ／ｐｏｌｌｓ

受信者のリストに対し順次および並行通信フロー・プリミティブを一般化することが可能である。ａｎｄ／ｏｒプリミティブの並行および順次形式は、受信者のリストによる並行または順次投票を可能にするもう２つの一般的なプリミティブの特別なケースである。たとえば、「ａｎｄ」プリミティブの成功は、１００％がｙｅｓに投票した場合に２人の受信者による投票であり、「ｏｒ」プリミティブの成功は、少なくとも５０％がｙｅｓに投票した場合の２人の受信者による投票である。

「ｖｏｔｅｓ」プリミティブは、成功応答のカウントｍまたはパーセンテージｎ％に達した場合に並行して人数ｃの受信者のリストについて連絡し、成功（ｔｒｕｅ）を返す。したがって、ｃ−ｍ＋１のｆａｌｓｅ応答があった場合に失敗が発生する。各受信者は、通信フロー式で表すことができ、カウントまたはパーセンテージは、成功する「ｖｏｔｅｓ」プリミティブについて受信しなければならない成功の回数を表す。たとえば、
｛ＴＯＭ，Ｊｏａｎｎ，Ｊｅｒｒｙ｝ｖｏｔｅｓ ５０％
は、Ｔｏｍ、Ｊｏａｎｎ、およびＪｅｒｒｙに並行して連絡する。少なくとも２人が成功で応答すると、「ｖｏｔｅｓ」プリミティブは成功となる。「ｖｏｔｅｓ」プリミティブが失敗するのは（ｆａｌｓｅを返すのは）、十分な受信者が、指定されたカウントまたはパーセンテージに達することができないようなｆａｌｓｅ応答を返した場合である。他の場合には、成功に達することができなければ「ｖｏｔｅｓ」プリミティブはｍａｙｂｅとなる。上の例で、Ｔｏｍ、Ｊｏａｎｎ、およびＪｅｒｒｙのうち少なくとも２人が失敗で応答した場合、「ｖｏｔｅｓ」プリミティブは失敗となる。その一方で、ｔｒｕｅ、ｆａｌｓｅ、およびｍａｙｂｅだと、ｍａｙｂｅの真理値になる。

プリミティブのカウントまたはパーセンテージから直接ｔｒｕｅを返す必要があるｔｒｕｅ投票の回数を計算することが可能であることに注意されたい。これから、ｆａｌｓｅを返す必要のあるｆａｌｓｅ投票の数（総数＋１−ｔｒｕｅの数）およびｍａｙｂｅを返す非ｔｒｕｅ投票（少なくとも１つがｍａｙｂｅである場合のｆａｌｓｅまたはｍａｙｂｅ）の数（総数＋１−ｔｒｕｅの数）を計算するのは簡単なことである。「ｐｏｌｌｓ」プリミティブは、「ｖｏｔｅｓ」プリミティブの順次形式である。

ｖｏｔｅｓプリミティブを、たとえば、限られた数の品目を販売または配布する場合に使用すると便利である。たとえば、５００ユニットの指定品目と５０００人の見込み客がいる会社では、以下の通信フローを指定することができる。
｛ｃｕｓｔｏｍｅｒ１，ｃｕｓｔｏｍｅｒ２，．．．，ｃｕｓｔｏｍｅｒ５０００｝ｖｏｔｅｓ ５００
要求は、顧客が５００ユニット注文したときに完了する（各顧客は１ユニットのみを注文すると仮定する）。各顧客が複数のユニットを注文できる例については、ｔｅｓｔ ｒｅｓｐｏｎｓｅ ｓｔａｔｕｓプリミティブの以下の説明を参照のこと。

ｐｏｌｌｓプリミティブを、たとえば、至急人員を補充する必要がある場合に使用すると便利である。たとえば、明日の朝までに注文リストから５人の代用教員を見つけようとしている学校は、以下のように通信フローを指定することができる。
｛ｔｅａｃｈｅｒ１，ｔｅａｃｈｅｒ２，．．．，ｔｅａｃｈｅｒＮ｝ｐｏｌｌｓ ５
すでに示されているように、この要求は、５人の代用教員が授業を受け持つことに同意した場合に完了する。

通信フロー式は、リストではないため、式を「ｖｏｔｅｓ」および「ｐｏｌｌｓ」プリミティブで必要なリストに変換すると都合がよい。特に、受信者環境設定およびロール・データベース５００内の名前付き通信フローは、多くの場合、当然であるが、リスト構造を持つ。大かっこで囲まれたリストではなく、通信フロー式が第１オペランドとして現れるときに「ｖｏｔｅｓ」および「ｐｏｌｌｓ」プリミティブに対しては自動変換がサポートされる。自動変換は、結合のみまたは調整のみを含む通信フロー式に対して実行される。式に「ａｎｄ」および「ｔｈｅｎ」プリミティブのみが含まれる場合、これは、結合のリストに変換される。式に「ｏｒ」および「ｅｌｓｅ」プリミティブのみが含まれる場合、式は、分離のリストに変換される。上に示した例をもう一度検討すると、
Ｒｅｖｉｅｗｅｒｓ ｖｏｔｅｓ ２
は、実際には以下のような式である。
（Ｃｈｒｉｓ ａｎｄ Ｊｅｒｒｙ ａｎｄ Ｂｅｎｊｉ ａｎｄ Ｊｅｎｎｙ）ｖｏｔｅｓ ２
結合は、自動的に、リスト｛Ｃｈｒｉｓ，Ｊｅｒｒｙ，Ｂｅｎｊｉ，Ｊｅｎｎｙ｝に変換される。式をリストに変換する操作の詳細を指定することは可能であるが、このような変換が、必要であるとか、明らかであるとか、または望ましいということは明確でない。後述のｓｅａｒｃｈプリミティブは、リストを式に変換する。

「ｒａｃｅｓ」および「ｄｅｌｅｇａｔｅｓ」プリミティブの生成
受信者のリストに対しｒａｃｅｓおよびｄｅｌｅｇａｔｅｓプリミティブを一般化することが可能である。ｒａｃｅｓの一般化は、ｇｅｎ＿ｒａｃｅｓと呼ばれるものであるが、受信者のリスト、収集する応答の数、および受信した応答からプリミティブの成功または失敗を判別する決定アルゴリズムを受け付ける。たとえば、ｇｅｎ＿ｒａｃｅｓを１回使用すると、Ｎ番目の受信した応答の値を受け付ける。これは、１００番目の呼び出し側から応答を受け付けるラジオ・トーク・ショー・モデルに対応している。他の例では、ｇｅｎ＿ｒａｃｅｓは、５つの応答のうち３つを収集し、その３つの大半の応答を返す。この結果は、
｛Ａ，Ｂ，Ｃ，Ｄ，Ｅ｝ｖｏｔｅｓ ２
と異なり、これは、２つ成功するまで待つ。ｇｅｎ＿ｄｅｌｅｇａｔｅｓは、ｄｅｌｅｇａｔｅｓプリミティブの一般化である。ｇｅｎ＿ｄｅｌｅｇａｔｅｓは、ｇｅｎ＿ｒａｃｅｓと似ているが、プリミティブの条件が満たされるまで受信者に順次連絡してゆく点が異なる。

順次／並行プリミティブの実装
順次および並行プリミティブは、単純なカウント・アルゴリズムを使用する実施例において実装されている。各プリミティブは、ｔｒｕｅを返す必要のあるｔｒｕｅ応答の数とｆａｌｓｅを返す必要のあるｆａｌｓｅ応答の数により記述される。さらに、ｍａｙｂｅを返す必要があるｍａｙｂｅ応答の最小数とｍａｙｂｅが返される前に受信していなければならない応答の総数により記述される。図１０は、Ｃがｖｏｔｅｓ／ｐｏｌｌｓでリストに載っているすべての受信者のカウント数であり、Ｘがｖｏｔｅｓ／ｐｏｌｌｓパーセンテージまたはカウントにより必要なｔｒｕｅ応答の数である、それぞれのプリミティブのカウントを要約したものである。並行および順次プリミティブは、各クラス内で受信された応答の数を数える。返されるステータスの１つに対する要求条件が満たされると、これらのプリミティブは未処理要求すら取り消して、適切なステータスを返す。

ステータスの解釈および時間的プリミティブ
図４に関して上で説明したように、受信者１２０に対する要求の成功は、通知成功と応答成功が伴う。通知成功は、受信者と正常に連絡が取れた場合に発生する。デフォルトで、受信者が要求および応答システムＡＰＩの成功の定義を満たす方法で応答した場合に応答成功が発生する。通知および応答システム１００のＷｅｂ ＡＰＩについては、応答成功のデフォルトでは、ｓｕｂｍｉｔボタンの値「ｆａｌｓｅ」または「ｎｏ」を含まないＷｅｂフォームへの返信となっている。ｓｕｂｍｉｔボタンに対する「ｆａｌｓｅ」または「ｎｏ」は、応答失敗のデフォルトの応答である。

一部のアプリケーションでは、応答成功のアプリケーション特有の定義が必要になることがある。たとえば、支出レポートが複数のマネージャによって順番に承認される場合、成功はｒｅｐｏｒｔ＿ｓｔａｔｕｓ＝「ａｐｐｒｏｖｅｄ」で要求に応答することと定義することができる。

Ｔｅｓｔ Ｒｅｓｐｏｎｓｅ Ｓｔａｔｕｓプリミティブを使用すると、アプリケーションは、応答成功指定を応答からの属性−値のペアの比較の論理式として供給することができる。この論理式は、応答が検査される受信者の後の疑問符の間に指定する。比較には、統合、不等号、範囲、および正規表現マッチングを含めることができる。成功指定が通信フロー内のすべての受信者について同じであるが、システム・デフォルトとは異なる場合、要求全体にわたるデフォルトを指定することができる。

以下の例では、デフォルトの機能を使用せずに、応答成功ステータスを指定している。
ＤｅｐａｒｔｍｅｎｔＨｅａｄ？ ｒｅｐｏｒｔ＿ｓｔａｔｕｓ＝「ａｐｐｒｏｖｅｄ」？ ｔｈｅｎ Ｄｉｒｅｃｔｏｒ？ ｒｅｐｏｒｔ＿ｓｔａｔｕｓ＝「ａｐｐｒｏｖｅｄ」？ ｔｈｅｎ ＶＰ？ ｒｅｐｏｒｔ＿ｓｔａｔｕｓ＝「ａｐｐｒｏｖｅｄ」？
Ｔｅｓｔ Ｒｅｓｐｏｎｓｅ Ｓｔａｔｕｓプリミティブが複数の受信者を含む式に適用される場合、これは、さらに複雑な式の中のそれぞれの受信者に適用される。たとえば、前の式は次のように書くことができる。
（ＤｅｐａｒｔｍｅｎｔＨｅａｄ ｔｈｅｎ Ｄｉｒｅｃｔｏｒ ｔｈｅｎ ＶＰ）？ ｒｅｐｏｒｔ＿ｓｔａｔｕｓ＝「ａｐｐｒｏｖｅｄ」？
成功指定では、集計およびその他の高度な処理をそこまでのすべての応答にわたって応答の属性に対し実行し、結果を成功または失敗について検査することができる。

上で示したように、ｖｏｔｅｓプリミティブを使用して、限られた数の品目を販売または配布することができるが、それぞれの顧客はちょうど１ユニット購入すると仮定する。以下の成功式では、それぞれの顧客は複数のユニットを注文し、少なくとも１００ユニットが販売されていたときには通知を終了する。
（Ｓｕｅ ｏｒ Ｆｒｅｄ ｏｒ．．．ｏｒ Ｓａｍ）？ ｓｕｍ（ｎｕｍｂｅｒ＿ｓｏｌｄ）≧１００？
１００個販売した後、他の受信者への未処理要求は取り消される。通知申し出が通知および応答システムから利用できるデータにより個人化された場合、前の応答の結果を利用して、受信者にまだ売られている品目を提供することができる（１００−ｓｕｍ（ｎｕｍｂｅｒ＿ｓｏｌｄ）。受信者が残りの品目を買おうとした場合、第１のものは成功し、第２のものは、他の要求により完了したためその要求は取り消された（つまり、申し出が撤回された）という通知を受ける。

ｂｅｔｗｅｅｎ／ｂｅｆｏｒｅ／ａｆｔｅｒ
応答ステータスを検査するプリミティブに加えて、「ｂｅｔｗｅｅｎ」、「ｂｅｆｏｒｅ」および「ａｆｔｅｒ」プリミティブにより、通知を配送し、受信者から応答を収集する時間的制約条件を指定する。時間制約条件により、「ａｆｔｅｒ」プリミティブの場合のように開示時刻を、あるいは「ｂｅｆｏｒｅ」プリミティブまたはその両方、「ｂｅｔｗｅｅｎ」プリミティブの場合のように終了時刻を指定することができる。「ｂｅｔｗｅｅｎ ｘ−ｙ」も、「ａｆｔｅｒ ｘ ｂｅｆｏｒｅ ｙ」で表すことができる。複数の時間制約条件を同じ受信者に適用する場合、時間制約条件は左から右へ評価される。第１の時間制約条件により、実際の開始時刻および終了時刻が設定される。その後の、時間制約条件によりこれらの時刻を微調整することができる。相対的時間制約条件では、時刻を順方向または逆方向に調整することができる。他の制約条件、たとえば、区間の先頭または末尾を見つけることにかかわるものは、開始時刻を先へ進め、終了時刻を逆に戻すことができる。つまり、複数のプリミティブにより食い違う絶対開始時刻または食い違う絶対終了時刻を設定した場合、遅れている開始時刻と早くなった終了時刻を使用して、実際に、制約区間を交差する。ｔｅｍｐｏｒａｌ ｃｏｎｓｔｒａｉｎｔプリミティブが複数の受信者を含む式に適用される場合、これは、さらに複雑な式の中のそれぞれの受信者に適用される。

時間制約条件を指定するには、時間式と時間領域式を使用する。時間式は特定の時点を表し、時間領域式は時間領域を表す。まず、時間領域式を定義するが、これらは時間式を書くときに使用される。時間領域は、（開始時刻、終了時刻）で指定された１つまたは複数の時間的区間であり、開始時刻はその区間内に含まれ、終了時刻はその区間内に含まれない。基本的な時間領域は、概念上始まり（Ｃｒｅａｔｉｏｎ）から終了時刻（Ａｒｍａｇｅｄｄｏｎ）までの１つの区間であるＥｔｅｒｎｉｔｙである。Ｃｒｅａｔｉｏｎは、任意の開始時刻（Ｕｎｉｘ（登録商標）の時間表現では、００：００．００ ＵＴＣ ｏｎ Ｊａｎｕａｒｙ １，１９７０など）として取られ、Ａｒｍａｇｅｄｄｏｎも同様に取り扱われる。現在、時間は、Ｃｒｅａｔｉｏｎから経過した秒単位の分解能で指定される。他のすべての時間領域は、一組の非連結時間区間（開始、終了）であり、区間の始まりは閉であり、区間の終わりは開である。

時間領域は、和集合、共通部分、および補集合の演算のもとで閉じている、つまり、これらの演算を領域上で実行すると必ず、他の有効な領域が得られるということである。時間領域式は、プリミティブの時間領域（下で定義）と、和集合、共通部分、補集合の演算から作成される。通信フロー式に名前を付け、他の通信フロー式の中で使用できるのと同様に、時間領域に名前を付け、他の時間領域式の中で使用することができる。

プリミティブ時間領域には以下のものがある。
ｆｒｏｍ ９：００．００，１３ Ｍａｙ ２００２ ｕｎｔｉｌ １７：００．００，１３ Ｍａｙ ２００２などの指定された開始時刻と終了時刻を持つ区間。
１３ Ｍａｙ ２００２などの指定された日。
Ｓｕｎｄａｙ，１２ Ｍａｙ ２００２ ｔｈｒｏｕｇｈ Ｓａｔｕｒｄａｙ，１８ Ｍａｙ ２００２などの指定された週。
Ｍａｙ ２００２などの指定された月。
２００２などの指定された年。
Ｍｏｎｄａｙなどのその週の指定された曜日（つまり、ＣｒｅａｔｉｏｎからＡｒｍａｇｅｄｄｏｎまでの間のすべてのＭｏｎｄａｙｓの和集合を意味する）。
Ｍａｙなどの指定された月（つまり、ＣｒｅａｔｉｏｎからＡｒｍａｇｅｄｄｏｎまでの間のすべてのＭａｙｓの和集合を意味する）。
Ｊｕｌｙ ４などのその年の指定された日（つまり、ＣｒｅａｔｉｏｎからＡｒｍａｇｅｄｄｏｎまでの間のすべてのＪｕｌｙ ４の和集合を意味する）。
９：００．００−１７：００．００などの指定された時間範囲（つまり、ＣｒｅａｔｉｏｎからＡｒｍａｇｅｄｄｏｎまでの間のすべての日に対するすべてのそのような区間の和集合を意味する）。

たとえば、平日をＭｏｎｄａｙ、Ｔｕｅｓｄａｙ、Ｗｅｄｎｅｓｄａｙ、Ｔｈｕｒｓｄａｙ、およびＦｒｉｄａｙの和集合として定義することもできる。休日を、Ｊａｎｕａｒｙ １、Ｊｕｌｙ ４、およびＤｅｃｅｍｂｅｒ ２５の和集合として定義することができる。営業時間を、平日と９：００．００〜１７：００．００の時間範囲と共通部分として定義することができる。また、営業時間と休日の補集合との共通部分を求めることにより、営業時間を精密化することができる。

時間式では、絶対時間を指定することができるか、または開始時刻（今から４時間など）に関して計算される時刻を指定することができるか、または時間領域と開始時刻（から計算される時刻を指定することができる（次の営業日の始まり、または今から４営業時間、つまり営業時間の時間領域内でのみカウントする今からの４時間を意味する）。

時間式は、以下の形式のうちの１つをとることができる。
１７：００．００ １３ Ｍａｙ ２００２などの絶対時刻。
＋４：００．００などの相対的時刻であり、これは、現在時刻の後４時間、または−３：００．００を意味し、現在時刻の前の３時間を意味する。

時間領域内の次の区間の開始または終わり、たとえば、業務の次の完了を現在時刻以降の営業時間内の区間の次の終わりとして指定することができる。より一般的には、開始または終了、たとえば、第２の業務完了をカウントすることができる。

指定された時間領域内で経過した時間、たとえば、現在１６：００．００ ｏｎ １３ Ｍａｙ ２００２だとすると、４営業時間が経過すると、１２：００．００ ｏｎ １４ Ｍａｙ ２００２を出力する。また、現在の時刻から戻すこともできるが、これは、先へ進めた後に、特に有用である。たとえば、次の休暇について時間領域を定義し、その後、次の休暇の始まる前に４営業時間を参照する。

これらに関して、さらに複雑な時間式を定義することができる。
たとえば、毎日１２：００．００〜１２：００．００まで続く（空の）時間区間を定義することができる。このような区間の次の開始（または終了）を取ることで、次の日の正午が指定される。平日との共通部分を使用することにより、同様に、次の営業日の正午を計算で求めることができる。これと、区間の終了をカウントする演算子とを結合することで、次の営業日の正午から２日間に業務の完了を計算することができる。

他の例として、スペインでの営業時間を範囲９：００．００〜１２：００．００および１４：００．００〜１９：００．００の和集合として指定することもできる。当日の業務完了を見つけるために、スペインでの営業時間と当日との共通部分を求め、その結果の時間領域内の区間の最後の終わりを見つける。

企業では、通信フロー・マネージャに対してデフォルト時間領域オブジェクトを定義することができ、あるいはそれぞれの受信者が自分の個人時間領域オブジェクトを定義することができる。このようなオブジェクトの使用例として、企業に対し営業時間を定義する例がある。オブジェクトには以下のものが含まれる。
時間領域オブジェクトの共通名（ｃｎ）：ｂｕｓｉｎｅｓｓ
その領域を使用する受信者のディレクトリ・フィルタ。これは、この営業時間領域を特定の会社、時間帯、または地理的領域内の人々に関連付けるために使用することができる。
実効時間を計算するために使用する時間帯。
領域内の区間に対する時間領域式。この時間領域式は、他の基本または名前付き時間領域を参照することができる。

この時間領域は、時間式演算子「ｅｎｄ ｏｆ」、「ｓｔａｒｔ ｏｆ」、「ｎ ｅｎｄ ｏｆ」、「ｎ ｓｔａｒｔ ｏｆ」とともに使用され、ｎはカウントまたはキーワードｌａｓｔ、「＋」は領域内の相対時間、「−」は「ｂｅｆｏｒｅ」、「ａｆｔｅｒ」、および「ｂｅｔｗｅｅｎ」プリミティブの領域内の相対時間であり、たとえば、次のものがある。
ＡＦＴＥＲ ｅｎｄ ｏｆ ｂｕｓｉｎｅｓｓ
ＢＥＦＯＲＥ ２ ｓｔａｒｔ ｏｆ ｂｕｓｉｎｅｓｓ
ＢＥＴＷＥＥＮ ｓｔａｒｔ ｏｆ ｂｕｓｉｎｅｓｓ−ｅｎｄ ｏｆ ｂｕｓｉｎｅｓｓ
ＢＥＦＯＲＥ ｂｕｓｉｎｅｓｓ＋４：００．００
ＡＦＴＥＲ ｅｎｄ ｏｆ ｂｕｓｉｎｅｓｓ
ＡＦＴＥＲ ｂｕｓｉｎｅｓｓ−０１：００．００
ＡＦＴＥＲ ｌａｓｔ ｅｎｄ ｏｆ（ＳｐａｎｉｓｈＢｕｓｉｎｅｓｓＨｏｕｒｓ ｉｎｔｅｒｓｅｃｔ Ｔｏｄａｙ）

構文をより自然なものとするためにさまざまな簡略化を行うことができる。たとえば、時間領域の名前がａｆｔｅｒの後に来る場合、その時間領域内の区間の次の終わりを指定された時刻とみなすことができる。ｂｅｆｏｒｅについても同様に、領域内の区間の次の開始を指定された時刻としてみなすことができる。こうすることで、「ＡＦＴＥＲ ｅｎｄ ｏｆ ｂｕｓｉｎｅｓｓ」は「ＡＦＴＥＲ ＢＵＳＩＮＥＳＳ」に、「ＢＥＦＯＲＥ ｓｔａｒｔ ｏｆ Ｍｏｎｄａｙ」は「ＢＥＦＯＲＥ Ｍｏｎｄａｙ」に簡略化される。さらに、「ＢＥＴＷＥＥＮ ｅｎｄ ｏｆ ０８：００．００−ｓｔａｒｔ ｏｆ １７：００．００」は「ＢＥＴＷＥＥＮ ０８：００．００−１７：００．００」に簡略化される。和集合、共通部分、および補集合の演算を使用する完全な時間領域式はさらに、時間領域の名前が使用されている場所でも使用できる。

通信フロー・マネージャの標準のデフォルト処理は、時間領域オブジェクトの共通名は通信フロー内で指定された名前から始まるが、ｂｕｓｉｎｅｓｓ＄ｗｅｓｔ−ｃｏａｓｔのようにドル記号「＄」の後に他の修飾文字列を挿入することもでき、受信者は時間領域オブジェクト内でフィルタを一致させなければならない。複数の一致するオブジェクトが見つかった場合、それらのオブジェクトの１つを選択するが、可能であれば、論理的に最も固有性の高いフィルタ（他のすべての一致するフィルタを含むフィルタ）を選択し、あるいはそれが可能でなければ、一致するオブジェクトのうちの任意に選択したオブジェクトを選択する。通信フロー・マネージャはまず、ｉｎｅｔＯｒｇＰｅｒｓｏｎまたはｉｎｅｔＲｏｌｅオブジェクトのコンテキスト内で一致するフィルタにより指定された名前の時間領域を探す。何も見つからない場合、通信フロー・マネージャは、そのデフォルト・ディレクトリ内の領域を探索する。

短い名前とディレクトリ探索プリミティブ
本明細書で説明している例は、要求者１１０は短い名前を使用して受信者１２０を指定できることを示している。以下の「ディレクトリのデフォルトと発見的手法」の項で説明しているように、これらの短い名前は、受信者環境設定およびロール・データベース５００の発見的探索により変換される。要求者１１０は、さらに、角かっこで囲んだ受信者１２０の安全識別名、たとえば＜ｕｉｄ＝ｊｏａｎｎ，ｏｕ＝ｐｅｏｐｌｅ，ｏ＝ｒｅｓｅａｒｃｈ．ａｖａｙａ．ｃｏｍ＞を指定することもできる。受信者１２０の識別名を指定することは、ユーザーにとっては難しい場合があるが、それは、ＬＤＡＰ名前ツリー６００（図６）の構造を知っている必要があるからである。また、通信フロー式では、探索演算もサポートしており、ユーザーは受信者環境設定およびロール・データベース５００内の１つまたは複数の受信者オブジェクトの属性を記述することができる。ユーザーは、探索演算を使用する場合、ディレクトリ・オブジェクトの識別名を知っている必要はない。「ｓｅａｒｃｈ（ｆｉｌｔｅｒ，ｐａｔｔｅｒｎ，ｏｐ）」などの形式のｓｅａｒｃｈプリミティブの例では、受信者環境設定およびロール・データベース５００を探索して、指定されたフィルタに一致する人、ロール、または名前付き通信フロー・オブジェクトを探す。高度なｓｅａｒｃｈプリミティブの例は、「ａｄｖ＿ｓｅａｒｃｈ（ｄｉｒｅｃｔｏｒｙ−ｓｅｒｖｅｒ，ｄｉｒｅｃｔｏｒｙ−ｐｏｒｔ，ｂａｓｅ，ｓｃｏｐｅ，ｆｉｌｔｅｒ，ｐａｔｔｅｒｎ，ｏｐ）」などの形式である。高度な探索プリミティブのフィルタ、パターン、およびｏｐパラメータの演算は、探索プリミティブと同じである。ｄｉｒｅｃｔｏｒｙ−ｓｅｒｖｅｒパラメータでは、探索する受信者環境設定およびロール・データベース５００のホストのドメイン名を指定し、ｄｉｒｅｃｔｏｒｙ−ｐｏｒｔパラメータでは、ホスト上の受信者環境設定およびロール・データベース５００サーバのポート番号を指定する。ｂａｓｅの識別名をルートとするディレクトリ・ツリーは、サーバ上で探索される。探索の範囲は、ｂａｓｅ（ｂａｓｅのみで識別されたオブジェクトの）、ｏｎｅ−ｌｅｖｅｌ（ｂａｓｅで識別されたオブジェクトの子のみを探索する）、またはｓｕｂｔｒｅｅ（ｂａｓｅで識別されたオブジェクトの部分ツリー全体を探索する）のいずれかである。Ｄｉｒｅｃｔｏｒｙ−ｓｅｒｖｅｒ、ｄｉｒｅｃｔｏｒｙ−ｐｏｒｔ、ｂａｓｅ、またはｓｃｏｐｅは、ＮＵＬＬであってもよく、その場合、デフォルトが適用される。

一般に、通信フロー式のｓｅａｒｃｈプリミティブは、探索結果を処理するためのマクロ機能を備えている。返されるそれぞれのオブジェクトは、トークン「＜ｄｎ＞」に対する、ｓｅａｒｃｈプリミティブのｐａｔｔｅｒｎパラメータで与えられる、パターンに代入される。次に、このオブジェクトの結果文字列は、ｓｅａｒｃｈプリミティブのｏｐパラメータ、たとえば「ａｎｄ」または「ｒａｃｅｓ」で与えられる、ユーザー指定プリミティブを使用して他のオブジェクトの結果文字列に接続される。例として、以下のパターン
（＜ｄｎ＞ｂｅｔｗｅｅｎ ５／０１／０１−０５／０８／０１）ｄｅｌｅｇａｔｅｓ（＜ｄｎ＞ｂｅｔｗｅｅｎ ５／０８／０１−０５／１０／０１）
は、２００１年５月１日以降に１回、応答が来なければ２００１年５月８日に以降に再び、要求の各受信者に通知する文字列を作成する。要求の完了前にすべての受信者からの応答が必要な場合、結果文字列を「ａｎｄ」プリミティブで接続して、通信フロー式を作成する。ユーザーはさらに、探索を、１人の受信者だけを返すように制約することもできるが、当業者には明らかなことであろう。探索結果に対する複数の一致を処理する方法を指定することで、個人にしか送信できないのにユーザーは知らずに機密の要求を大きなグループに送信してしまうのを防止できる。

ｓｅａｒｃｈプリミティブは、たとえば、エキスパートの援助を求めるときに使用できる。たとえば、要求者がエキスパートからＪ２ＥＥなどの指定されたトピックに関する情報を必要とする場合、要求者は以下の通信フローを指定するとよい。
ｓｅａｒｃｈ（「＆（（ｏｂｊｅｃｔｃｌａｓｓ＝ｉｎｅｔＯｒｇＰｅｒｓｏｎ）（ｅｘｐｅｒｔｉｓｅ＝Ｊ２ＥＥ））」，「＜ｄｎ＞」，ＯＲ）
他に、通信フローを次のように指定することもできる。

ｅｘｐｅｒｔ１ ｏｒ ｅｘｐｅｒｔ２．．．ｏｒ ｅｘｐｅｒｔＮ
さらに他の例では、ネットワーク・アラームが発生し、これをエキスパートが解決しなければならない。要求者は、以下の通信フローを指定することができる。
ｓｅａｒｃｈ（「＆（（ｏｂｊｅｃｔｃｌａｓｓ＝ｉｎｅｔＯｒｇＰｅｒｓｏｎ）（ｅｘｐｅｒｔｉｓｅ＝ｎｅｔｍｇｒ））」，「＜ｄｎ＞」，ＯＲ）
これらの要求は、エキスパートが要求に申し分なく応えた場合に完了する。

以下の表は、高から低への演算子の優先順位（演算子の順序）の例をまとめたものである。同じレベルにある演算子は、左から右への順序である。一般に、優先順位の順序を変更するには、かっこを使用する。

要求マネージャ１２００と通信フロー・マネージャ１３００の相互作用
図１１〜１３には、要求マネージャ１２００と通信フロー・マネージャ１３００との間の相互作用が示されている。図１１は、要求に関連するさまざまなエンティティの間の情報の流れを示す概略ブロック図である。図１２Ａおよび図１２Ｂは、図１１の要求マネージャの動作を詳しく説明する流れ図である。図１３は、図１１の通信フロー・マネージャの動作を詳しく説明する流れ図である。実施例では、要求マネージャ・プロセス１２００および通信フロー・マネージャ・プロセス１３００は、それぞれ、ステップ１２０５（図１２）および１３０５（図１３）で検出されたさまざまな定義済み非同期イベントを処理する。

図１２Ａに示されているように、要求マネージャ１２００は、ステップ１２１０でアプリケーション・インターフェイス２２０を通じてアプリケーション１１０から受信した新しい要求を検出する。次に、要求マネージャ１２００は、ステップ１２１５で要求データベース３００（図３）に要求のエントリを作成し、要求識別子とともに、要求の通信フロー式部分をステップ１２２０で構文解析する通信フロー・マネージャ１３００に供給する。

図１３に示されているように、通信フロー・マネージャ１３００は、ステップ１３１０で処理する新しい通信フロー式を検出する。通信フロー・マネージャ１３００は、必要に応じて、ステップ１３１５で通信フロー式を処理し、ツリー６００内の一組の実行可能ターミナル・ノードに到達し、指定された受信者について採用する媒体連絡オブジェクトを示すまで、受信者環境設定およびロール・データベース５００を使用して通信フロー式内の各名前を解決する作業を続ける。受信者１２０は、通信フロー管理ＧＵＩ １１１０を使用して受信者環境設定およびロール・データベース５００への環境設定の入力と更新を行うことができることに注意されたい。

通信フロー・マネージャ１３００は、ステップ１３２５で、連絡するデバイスのリストを生成し、そのリストを要求マネージャ１２００に連絡スケジューリング情報の一部として返す。一般に、連絡スケジューリング情報は、要求マネージャ１２００によって即座にスケジュール可能な連絡のみを含む。たとえば、指定された受信者の環境設定が、その受信者には午前８時から午後５時までの間に電話でしか連絡できないことを示している場合、通信フロー・マネージャ１３００はその時間枠が有効になるまで電話媒体連絡をスケジュールしない。

より具体的には、通信フロー・マネージャ１３００は、受信した通信フロー式を解析してツリーにし、そのツリー内のノードの再帰的処理を開始するが、それには、縦型検索アプローチを使用し、ターミナル・ノードに到達するまで、ツリーをたどる。ツリー内でターミナル（リーフ）ノードに遭遇する毎に、そこに格納されている媒体連絡が処理される。指定されたノードに並行プリミティブが含まれる場合、並行プリミティブのオペランドに関連付けられたすべてのノードが処理される。指定されたノードに順次プリミティブが含まれる場合、左側オペランドは完了するまで、右側オペランドは処理されない。

さらに、媒体連絡を要求マネージャ１２００に返す前に、通信フロー・マネージャ１３００は、媒体連絡（ターミナル・ノード）と関連する時間的制約条件が満たされているかどうかを判別する。たとえば、通信フロー・マネージャ１３００は、開始時刻になったかを判別する。すべての時間的制約条件が満たされると、媒体連絡が、要求マネージャ１２００に返されるリストに取り込まれる。すべての時間的制約条件が満たされているだけではない場合、媒体連絡は、要求マネージャ１２００に返されるリストにはまだ含まれず、通信フロー・マネージャ１３００は、適切な時刻に通信フロー・マネージャ１３００によってリストに媒体連絡を追加できるようにタイマーを設定する。媒体連絡オブジェクトは、すべての時間的制約が満たされるまで取り出されないことに注意されたい。

通信フロー式のツリー表現は、知られている方法でルート・ノードヘの逆ポインタを含むことができ、そのため関連する時間的制約条件を識別しやすくなっていることに留意されたい。人またはロールに対する名前付きノードがツリー内に見つかった場合、その名前に対してすでに同じ所有者（同じ指定された通信フロー）と連絡が取られているかどうかを判別する。その名前に対してすでに同じ所有者と連絡が取られている場合、第２の連絡が試みられない。むしろ、ステータス情報が前の連絡から伝搬される。

図１２Ａに示されているように、要求マネージャ１２００は、ステップ１２２５で受信した連絡スケジューリング情報を検出し、以下の「媒体特有のインターフェイス」という表題のセクションで説明しているように、ステップ１２３０で指示された媒体連絡タイプを使用して連絡スケジューリングに情報に示されているそれぞれの受信者と連絡を取ろうとする。

ステップ１２４０（図１２Ｂ）で要求マネージャ１２００が１つまたは複数の応答またはメッセージ期限切れイベントを検出した場合、対応する要求識別子を持つ応答または期限切れのレコードが、任意選択により、たとえば、ステップ１２４５で、アーカイブまたは記録付けを目的として、応答データベース１１５０内に作成される。各個別応答が要求側アプリケーション１１０に供給される実施例では、ステップ１２４８で受信した応答が対応するアプリケーション１１０に転送される。応答または期限切れステータスは、ステップ１２５０で、さらに処理するため通信フロー・マネージャ１３００に転送される。

通信フロー・マネージャ１３００は、ステップ１３３０で、要求識別子を持つ受信された応答または期限切れステータスを検出し、ステップ１３３５で、その要求識別子を使用して、適切な通信フロー式を取り出す。ステップ１３３０で、応答または期限切れステータスが検出された場合、通信フロー・マネージャはさらに、ステップ１３３５で通信フロー式のツリー表現を更新し、媒体連絡のステータスを反映するようにする。次に、通信フロー・マネージャ１３００は、現在判別されている上位オペランドのステータスを判別することにより、ステータスを上に向かってツリーのルートに伝搬し、したがって、媒体連絡のステータスの結果としてオペランドはこれで完成する。オペランドが完了すると、そのオペランドに対する未処理媒体連絡は取り消し対象の連絡のリストに置かれる。このリストは、適宜、ステップ１３５０または１３２０の後に要求マネージャ１２００に返される。ステータスの伝搬によって通信フローが全体として完了しない場合、これは、ツリー内の最高優先度の演算子を完了ステータスが設定されているときに発生するが、処理はステップ１３１５に続く。通信フロー全体が完了した場合、処理はステップ１３５０へ続く。

通信フロー・マネージャ１３００は、通信フロー式を使用して、追加通信が必要かどうか、または通信が完了しているかを判別する。ステップ１３４０で、追加通信が必要だと判断された場合、プログラムの制御はステップ１３１５に戻り、連絡スケジューリング情報を生成し、さらに連絡スケジューリング情報を要求マネージャ１２００に送る。しかし、ステップ１３４０で、通信フロー式が完了していると判断された場合、通信フロー・マネージャ１３００は、ステップ１３５０で完了ステータス指示を要求マネージャ１２００に転送する。

照合された応答が要求側アプリケーション１１０に供給される一実施例では、要求マネージャ１２００は応答を照合し、ステップ１２６０で要求マネージャ１２００が通信フロー・マネージャ１３００から完了ステータス指示を受信すると、ステップ１２６５でそれを要求側アプリケーション１１０により指示されている最終宛先アドレスに返す。ステップ１２７０で、完了ステータス・メッセージが対応するアプリケーションに送信される。

媒体特有のインターフェイス
一実施例では、媒体特有のインターフェイスは、それぞれのサブクラスが２つのメソッド、つまり、連絡を開始するメソッドとそれを取り消すメソッドを実装する必要がある単一のＭｅｄｉａＣｏｎｔａｃｔ抽象クラスのすべてのサブクラスである。しかし、２つのメソッドだけが必要であるが、通知および応答システム１００とエンド・ポイントとの間の情報の配分の程度に応じて、非常に単純なサブクラスから極めて複雑なサブクラスまである。一般に、それぞれの媒体連絡について、要求は後述の媒体特有のトランスコーダの１つによりトランスコーティングされ、試行対象の特定の連絡に好適な符号化を出力する。プロトコル固有の通信インターフェイスでは、各受信者への符号化された要求の実際の配送を処理する。

このクラスの収集は、デバイス抽象層と考えることができる。このようなデバイス抽象層は、さまざまなデバイスのあらゆる複雑さを他の通知および応答システム１００のクラスから隠し、通知のインスタンス化、開始、および取り消しをを行うごく少数の単純なメソッドのみを公開するほかに、すべてのデバイスにわたって一様ないくつかのパラメータ設定および参照メソッドを公開する。以下では、多数のＭｅｄｉａＣｏｎｔａｃｔサブクラス例について説明する。

ＷｅｂＣｏｎｔａｃｔ
ＷｅｂＣｏｎｔａｃｔクラスでは、受信者はＷｅｂポータルにログインして、保留、完了、および取り消し済みの要求のリスト表示させることができる。ＷｅｂＣｏｎｔａｃｔクラスでは、単純に、要求者の名前、要求の時刻、件名、および要求ＵＲＬへのハイパーリンクを含むアイテムを保留リストに挿入するだけである。取り消しでは、アイテムを保留リストから取り消し済みリストへ移動するだけである。「ｒｅｃｉｐｉｅｎｔ」は、目的の通知をクリックし、表示されているフォームを完成させることにより応答する。

ＰｈｏｎｅＣｏｎｔａｃｔ
ＰｈｏｎｅＣｏｎｔａｃｔクラスでは、受信者が電話をかけるか、または連絡をよこすまで待つのではなく、電話呼び出しを開始しなければならない。さらに、ＰｈｏｎｅＣｏｎｔａｃｔクラスでは、ＶＸＭＬスクリプトのオーディオ表現（または他のテキスト表現）を出力するＶｏｉｃｅ ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＶｏｉｃｅＸＭＬ）システムを採用することができる。ＰｈｏｎｅＣｏｎｔａｃｔクラスでは、ＴＣＰ経由で、要求識別子、媒体連絡識別子、ダイヤルする電話番号、およびターゲット受信者のＶＸＭＬスクリプトを返すサーブレットのＵＲＬを指定するメッセージを電話オートダイヤラに送信する。取り消しの場合、ＰｈｏｎｅＣｏｎｔａｃｔは、単に、まだ電話がかけられていない場合に電話を取り消すことを指示するメッセージを送信するだけである。

オートダイヤラの制御プログラムにより、電話呼び出しの要求がキューの中に入れられ、リソースが利用可能になるとすぐにＦＩＦＯの順序で実行される。

ＥｍａｉｌＣｏｎｔａｃｔ
通知および応答システム１００の例では、プレーン・テキスト、ＨＴＭＬ、および埋め込みダイナミックＨＴＭＬの３種類の電子メールに対応できる。第１の場合、多くの受信者がときには、テキストのみの電子メール・クライアントを使用する。これには、テキスト・エディタのｅｍａｃｓやいくつかのＷｅｂベース・クライアントが含まれるが、Ｂｌａｃｋｂｅｒｒｙ（商標）やＰａｌｍ（商標）から市販されているものなどの無線電子メール・クライアントも含まれる。この場合、ディレクトリ内で、テキストのみの電子メールでなければならないことを指示することにより用意しなければならないが、通知および応答システム１００は、通常、要求者の名前、要求の件名、および通知メッセージを指しているＵＲＬを含む単純な電子メール・メッセージを作成する。一実施例では、要求側アプリケーションは、テキスト・メッセージ自体を作成し、さらに、オーディオ・アクセスのため呼び出すことができるボイス・ポータルの電話番号を挿入した。

埋め込まれたフレームまたはレイヤを処理することができないＨＴＭＬ対応電子メール・クライアントに代わって、ＥｍａｉｌＣｏｎｔａｃｔが、またも、通知を説明するＨＴＭＬページを作成するが、今度は、通知メッセージへのハイパーリンクを含む。埋め込まれたフレームおよびレイヤを処理できる電子メール・クライアントの場合、ＥｍａｉｌＣｏｎｔａｃｔは、クライアントがメッセージを表現するときにコンテンツが組み込まれるように通知を埋め込んだメッセージを作成する。

ＥｍａｉｌＣｏｎｔａｃｔが最後に複雑なのは、配送できない電子メール・メッセージを解釈する必要があるということである。これは、さらに通知および応答システム１００に送信されたメッセージを処理するプログラムとして指定されるメイン・メソッドを供給する形で実装される。すると、このメソッドは、返されたメールを解釈して、配送試行が失敗したことを示しているか、あるいは何か他のことを示しているかを判別しようとする。そうであれば、通知および応答システム１００は、連絡が失敗したことを通知される。通知および応答システム１００は、任意選択により、要求を受け取って、解釈することができる。これにより、返信が送信されなくても通知が成功したと判断する可能性があり、また何らかのアプリケーションに必要な機能である場合もある。

ＳＭＳＣｏｎｔａｃｔ
ＳＭＳＣｏｎｔａｃｔでは、Ｓｐｒｉｎｔ（商標）、Ｖｅｒｉｚｏｎ（商標）、およびＡＴ＆Ｔ（商標）をはじめとするさまざまな携帯電話プロバイダが提供しているＳｈｏｒｔ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅを介して通知を処理する。ＳＭＳＣｏｎｔａｃｔオブジェクトは、Ｗｅｂサイトに対してプロバイダ特有のＨＴＴＰ ＰＯＳＴまたはＧＥＴを実行して、メッセージを送信する。ほぼ同じことを。電子メールをサービス・プロバイダに電子メールを送信することにより行うことが可能であるが、ＰＯＳＴではあと少しだけ制御機能を持つ。ＰＯＳＴは、プロバイダのＷｅｂインターフェイスが発達したときのソフトウェアの変化に対する支出を伝送する。通知および応答システム１００は、任意選択により、ほとんどのサービス・プロバイダがメッセージの配送の終了後送出する確認電子メールを解釈することができる。ＳＭＳメッセージが正常に送信されたことを識別する他に、この電子メールでは、サービス・プロバイダのＷｅｂインターフェイスを変更し、ＳＭＳＣｏｎｔａｃｔソフトウェアがアップグレードされるまで電子メールのＳＭＳ配送を使用することにシステムが戻れるかどうかを判別することができる。

ＦａｘＣｏｎｔａｃｔ
通知および応答システム１００は、たとえば、ＡｖａｙａのＡＵＤＩＸシステムのＦＡＸ 機能を使用して、ＦＡＸ機に通知を送信するクラスを提供することができる。このクラスは、ＨＴＭＬまたはテキスト・ページをＴＩＦＦイメージ・ファイルに変換し、ＦＡＸ経由でイメージを宛先に送信する要求を生成する。このクラスはさらに、保留状態のＦＡＸに関する情報を提供し、保留状態のＦＡＸのある種の制御を行う単純なステータスおよび管理サーブレットを含む。

ＡｕｄｉｘＶｏｉｃｅＣｏｎｔａｃｔ
ＡｕｄｉｘＶｏｉｃｅＣｏｎｔａｃｔオブジェクトは、受信者のボイス・メールボックスにテキスト・バージョンの通知を配送するように設計されている。一実施例の実装では、ＩＢＭ Ｃｏｒｐ．のＶｉａＶｏｉｃｅ（商標）製品を使用して実現されており、メッセージをオーディオ・ファイルに落とし、その後、ＦａｘＣｏｎｔａｃｔと本質的に同じメカニズムを使用してＡＵＤＩＸサーバに送信する。

ＳＩＰＣｏｎｔａｃｔ
ＳＩＰＣｏｎｔａｃｔクラスは、通知および応答システム１００をＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）対応のエンド・ポイントに接続する。Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）は、たとえば、Ｍ．Ｈａｎｄｌｅｙ ｅｔ ａｌ．「ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」、ＲＦＣ ２５４３、１９９９年３月で説明されている。ＳＩＰはＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋｆｏｒｃｅ（ＩＥＴＦ）によって、各種通信セッションのセットアップおよび制御のため、定義されている比較的新しいプロトコルである。

このために、ＳＩＰＣｏｎｔａｃｔクラスは通知および応答システム１００からメッセージを受信するＳＩＰ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ（ＳＥＥ）と呼ばれるコンポーネントに依存している。メッセージには、受信者のＳＩＰアドレス、媒体連絡識別子、要求識別子、およびこの要求に対する利用可能な媒体タイプおよび人間の言語のリストが含まれる。その後、ＳＥＥは、ＳＩＰアドレスを受け取り、ＳＩＰプロトコルに従ってアドレスに対して「ｉｎｖｉｔｅ」を実行して、受信者との連絡を確立する。さらに、ＳＥＥは、受信者デバイスから、受信者の好ましい媒体および人間の言語を示すＯＫメッセージを受信する。ＳＥＥは、後述のＸＦＳ要求を実行し、利用可能なもののすでに用意されているリストから媒体連絡識別子、要求識別子、およびこの要求に対する好ましい媒体タイプおよび人間の言語を供給する。ＸＦＳ要求により、受信者のＳＩＰの環境設定に従って、受信者に通知するため適切に書式化されたコンテンツを返す。この手法では、ＳＥＥが目的の形式のそれぞれについてＸＦＳを１回呼び出せるようにすることで、複数の形式を受け取ることを優先するデバイスをサポートする（画面とオーディオを備えるデバイスもある）。

一実施例では、ＳＥＥでは、Ｍｉｃｒｏｓｏｆｔ ＸＰ（商標）ｓｏｆｔｐｈｏｎｅにインスタント・メッセージを送信したり電話をかけたりすること、呼制御プロトコルがＳＩＰに変更された（Ｈ．３２３の代わりに）（ＳＩＰプロトコル・サポートで強化されたバージョンのＭｕｌｔｉＶａｎｔａｇｅ（商標）呼処理ソフトウェアを介して）ＳＩＰ 対応Ａｖａｙａ ４６２４（商標）ＩＰ電話、デジタルおよびアナログ電話をかけること、インスタント・テキスト・メッセージを赤外線機能を持ち、呼制御プロトコルがＳＩＰに変更された（Ｈ．３２３の代わりに）ＳＩＰ対応Ａｖａｙａ ４６２４（商標）ＩＰ電話をかけること、呼制御プロトコルがＳＩＰで置き換えられた（Ｈ．３２３の代わりに）実験的ＳＩＰ対応Ａｖａｙａ ４６３０（商標）ＩＰテレビ電話でＷｅｂページをポップすることができる。

ＳＩＰは、本発明の通知および応答システム１００をさまざまな形で補完する。特に、ＳＩＰは、受信者が１つのサーバ上で自分の連絡の環境設定を設定し、それらの環境設定が自分の連絡先に適用されるようにするメカニズムを提供する。ＳＩＰ対応の受信者はＳＩＰを介して自分の環境設定を表すことができるが、従来の受信者はそれでも、通知および応答システム１００内の個々の通信フローを定義することができる。受信者がＳＩＰメカニズムを使用して、通知の受信方法と受信時期を制御し、その一方で、通知および応答システム１００内の通信フローにより非ＳＩＰエンド・ポイントおよびＳＩＰ指定の好ましいエンド・ポイントに通知を送信する方法と時期を決定することが予想される。つまり、ちょうどＳＩＰおよび統合メッセージングでメッセージの受信方法を制御できるようにするのと同じように、通知および応答システム１００は企業がメッセージを送出する方法を制御する。メッセージの受信方法に対するＳＩＰの制御は、本明細書の開示により、通信フロー式および通信フロー規則の機能により強化することができることに留意されたい。

ＳＩＰＣｏｎｔａｃｔクラスではさらに、通知および応答システム１００のアーキテクチャのいくつかの利点を示している。特に、通知および応答システム１００内の通知メッセージのコンテンツは、Ｗｅｂブラウザまたは電話ブラウザにより、またはＸＦＳと呼ばれるフォーム・サーブレットを、以下のように、要求と連絡される受信者およびデバイスを識別する２つの引数を付けて呼び出すことにより、ＭｅｄｉａＣｏｎｔａｃｔで取り出すことができる。

ｈｔｔｐ：／／ｘｕｉ／ＸＦＳ？Ｒｉｄ＝ｘｕｉ−１２３４−１＆Ｃｉｄ＝１
ただし、Ｒｉｄは要求ＩＤ、ｃｉｄは媒体連絡ＩＤである。この２つを合わせると、受信者を識別するのに十分である。ＸＦＳでは、単純に、要求マネージャ１２００を使用して、適切な要求を取り出しており、これはさらに、通知メッセージのＵＲＬを取得するのにも使用されている。その後、このメッセージは、取り出され、応答をリダイレクトし、メッセージを個人化するように書き換えられ、そして、ブラウザまたは他の宛先に転送される。

複数の言語および媒体タイプをサポートするために、望んでいる言語およびＭＩＭＥタイプを指定する２つの追加パラメータを受け付けるようにＸＦＳサーブレットを修正することができる。たとえば、より汎用的なバージョンのＸＦＳでは、次のように、特定の言語および形式タイプを取り出すことができる。
ｈｔｔｐ：／／ｘｕｉ／ＸＦＳ？Ｒｉｄ＝ｘｕｉ−１２３４−１＆Ｃｉｄ＝１＆Ｃｔｙｐｅ＝ｔｅｘｔ／ｐｌａｉｎ＆Ｌａｎｇｕａｇｅ＝ＥＮＵ
これは、英語のプレーン・テキスト・バージョンの要求「ｘｕｉ−１２３４−１」が必要であることを指定している。

通知および応答システム１００の例では、電話を介した音声メッセージおよび画面上のＷｅｂページ・ポップとして、２つの方法で同時にＳＩＰ対応Ａｖａｙａテレビ電話に通知を配送する。これは、テレビ電話でＳＥＥに対して、Ｗｅｂポップとオーディオ接続の両方を扱えることを指定させることにより行われた。ＳＥＥは、次に、以下のようにＸＦＳを２回呼び出すが、最初にＨＴＭＬページを取り出し、２回目はＶＸＭＬページを取り出す。
ｈｔｔｐ：／／ｘｕｉ／ＸＦＳ？Ｒｉｄ＝ｘｕｉ−１２３４−１＆Ｃｉｄ＝１＆Ｃｔｙｐｅ＝ｔｅｘｔ／ｈｔｍｌ＆Ｌａｎｇｕａｇｅ＝ＥＮＵ、
ｈｔｔｐ：／／ｘｕｉ／ＸＦＳ？Ｒｉｄ＝ｘｕｉ−１２３４−１＆Ｃｉｄ＝１＆Ｃｔｙｐｅ＝ｔｅｘｔ／ｖｘｍｌ＆Ｌａｎｇｕａｇｅ＝ＥＮＵ

すでに述べたように、通知および応答システム１００を使用すると、アプリケーション１１０（要求者）は質問をし、目的の応答のタイプを指定し、電子メール経由で受信者から照合された応答群を受け取ることができる。図１４は、アプリケーション１１０でチーム会合の要求のパラメータを指定することができるＷｅｂフォーム１４００を示している。図１４の例では、Ｊｏａｎｎは会合をスケジュールする要求を「ＹａｎｇＱｉａｎ」と「Ｐｅｔｓｃｈｅ」に送信している。これらの受信者が会合の時間と場所について同意した場合、要求はマネージャ（ｃｍｋ）に転送され、出席の確認が行われる。生成された要求は、適宜、異なる媒体連絡を介して、指示された受信者に送信される。要求にはｙｅｓボタンとｎｏボタンがあり、その要求に応答する。図１５は、要求のコンパイルした結果を示している。図１５に示されているように、Ｐｅｔｓｃｈｅは会合に出席することができるが、ＹａｎｇＱｉａｎは会合に出席することができず、マネージャに連絡が取られなかった。

図１６に示されている他の例では、要求者は、４時間のうちに好ましい顧客に割り当てる新会社のＩＰＯのブロック割り当てで株式を提供する。時間的制約条件が、名前付き通信フローＰｒｅｆｅｒｒｅｄＣｕｓｔｏｍｅｒｓに適用される。ＰｒｅｆｅｒｒｅｄＣｕｓｔｏｍｅｒｓは、受信者の並行結合に変換される。要求者は、要求の中の一連のオプションを自分の最良の顧客に与える。電子メールの環境設定を指定している名前付き通信フローＰｒｅｆｅｒｒｅｄＣｕｓｔｏｍｅｒｓによって定義された各受信者により受信される電子メール・バージョンの要求が図１７に示されている。照合された応答は、すべての受信者が応答するとすぐに、または４時間の申し込み期間が終了するとすぐに返される。受信者が４時間のうちに応答できず、その後、要求を表示または応答しようとすると、適切なメッセージが表示され、返信が求められることも、受け付けられることもない。

「Ｒｅｖｅｒｓｅ ９１１」と呼ばれる、本発明の他の実施例では、通知および応答システム１００は緊急９１１応答を送ることができる。たとえば、学校で緊急の問題が発生した場合に親に通知するため、通信フロー式および規則を定義することができる。このような場合、学校側が学校にいるそれぞれの子供の親または保護者に連絡を取る必要がある緊急事態に備えて必要な資源を整理しておくことは困難である。本発明のＲｅｖｅｒｓｅ ９１１システムは、親と連絡を取るための自動化手法を実現し、また不適切なあるいは不正な使用を防止し、誤った警報を最小限に抑えるための重要な予防対策を講じることもできる。Ｒｅｖｅｒｓｅ ９１１システムで、親が緊急時にサービス・プロバイダと連絡を取るための自分の環境設定を登録する必要がある。学校では、いったんアクティブ化されると、Ｗｅｂインターフェイスまたは電子メールを使用して、すべての親との連絡を並行して開始することができる。通知は、任意選択により、親がメッセージの受信の受領通知を行うためのボタンを備えることができる。さらに、学校側では、通知を親に送信する前に満たされていなければならない本明細書で説明した手法を使用して承認プロセス要求を指定し、さらに他のセキュリティ機能を利用してこのセキュリティの機能を高めることができる（たとえば、要求者の検証を行う対策が行われているログインおよびアクセス制御）。このようにして、本発明は、「ループ内に人を入れる」セキュリティを実現することができる。

同じＲｅｖｅｒｓｅ ９１１システムを他のバリエーションでも採用でき、たとえば、赤十字や政府機関が危機の際に献血者を見つけ、スケジュールを立てるのを支援したり、化学物質流出などの特定の災害に関して近隣の居住者に連絡するのを支援することができるが、本明細書の開示に基づき、当業者には明白なことであろう。

「適応型スケジューリング」と呼ぶ本発明のさらに他の実施例では、通知および応答システム１００は、スケジュールの変更を指定受信者に通知することができる。たとえば、列車または航空機などの大量輸送手段が遅れている場合、または通勤者が会合への途中で交通渋滞に巻き込まれた場合、スケジュールの変更を関係当事者に通知し、参加者のスケジュールに対する適切な改訂を調整するように通知および応答システム１００を構成することができる。たとえば、本明細書で説明しているカレンダー・エージェント手法では、このようなスケジュールの改訂を自動的に行うようにできる。乗客は、たとえば、＝「Ｆｌｉｇｈｔ Ｉｎｆｏｒｍａｔｉｏｎ＊」という表題の電子メール・メッセージを受信した場合に開始される通信フロー規則を指定することができる。通信フロー規則では、リムジン・サービス、同僚、または配偶者など、遅れが発生した場合の連絡先に関する情報を提供することが。通知により、影響を受ける受信者に特有の情報を提供することができる。たとえば、リムジン・サービスへの通知では、代替えピックアップ時間を要求し、同僚への通知では、会合の再スケジュール（たとえば、カレンダー・エージェントを使用する）または遅れた乗客の不在の会合に同僚が出席する（ｄｅｌｅｇａｔｅｓ機能を使用する）ことを要求することができる。

当業で知られているように、本明細書で説明した方法および装置は、それ自体コンピュータ読み取り可能コード手段が実現されているコンピュータ読み取り可能媒体を備える製造品として配布することができる。コンピュータ読み取り可能プログラム・コード手段は、コンピュータ・システムとともに動作し、これにより、ステップのすべてまたは一部を実行し、本明細書で説明している方法を実行するか、または本明細書で説明している装置を製作することができる。コンピュータ読み取り可能媒体は記録可能媒体（たとえば、フロッピー（登録商標）・ディスク、ハード・ドライブ、コンパクト・ディスク、またはメモリ・カード）であるか、または伝送媒体（たとえば、光ファイバ、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ、ケーブル、または時分割多重アクセス、符号分割多重アクセス、またはその他の無線周波チャネルを使用する無線チャネルを含むネットワーク）とすることができる。コンピュータ・システムとともに使用するのに好適な情報を格納できる媒体が知られているかまたは開発されていればそれも使用できる。コンピュータ読み取り可能コード手段は、磁気媒体上の磁気的なバリエーションまたはコンパクト・ディスクの表面上の高さバリエーションなどコンピュータが命令およびデータを読み込むためのメカニズムである。

本明細書で説明しているコンピュータ・システムをおよびサーバは、それぞれ、本明細書で開示されている方法、ステップ、および機能を実装するように関連するプロセッサを構成するメモリを備える。メモリは分散させることも、ローカル・メモリとすることもでき、さらにプロセッサも分散されることも、単一とすることもできる。メモリは、電気的メモリ、磁気メモリ、光メモリ、あるいはこれらまたはその他の種類のストレージ・デバイスの組み合わせとして実装することもできる。さらに、「メモリ」という用語は、関連するプロセッサによってアクセスされるアドレス指定可能空間内のアドレスに対し読み書きできる情報を包含するものとして十分広く解釈することができる。この定義を用いると、関連するプロセッサはネットワークから情報を取り出すことができるため、ネットワークに関する情報はそのままメモリ内にある。

本明細書で示し、説明した実施形態およびバリエーションは、単に、本発明の原理を説明しているに過ぎず、また当業者であれば本発明の精神および範囲から逸脱することなくさまざまな修正を加えることができることは理解されるであろう。

本発明の特徴を組み込んだ通知および応答システムの図である。 図１の通知および応答システムの詳細な図である。 図２の要求マネージャによって使用される要求データベースの例からのサンプル・テーブルである。 本発明の特徴を組み込んだ３値論理エバリュエータを説明する流れ図である。 図２の受信者環境設定およびロール・データベースの例からのサンプル・テーブルである。 多数の受信者の個人的名前付けコンテキストを示す図５の受信者環境設定およびロール・データベースからのＬＤＡＰディレクトリ・ツリーの一部の図である。 図５の受信者環境設定およびロール・データベースの他の部分からのサンプル・テーブルである。 本発明による通信フロー式の一組のプリミティブの例を示すサンプル・テーブルである。 図８に示されているさまざまなプリミティブに対する真理値表の図である。 図８に示されているさまざまなプリミティブに対する真理値表の図である。 図８に示されているさまざまなプリミティブに対する真理値表の図である。 図８に示されているさまざまなプリミティブに対する真理値表の図である。 図８に示されているさまざまなプリミティブに対する真理値表の図である。 図８に示されているそれぞれのプリミティブのカウントを集計したサンプル・テーブルである。 図２に示されている要求マネージャと通信フロー・マネージャとの間の相互作用を示す図である。 図１１の要求マネージャの動作を詳しく説明する流れ図である。 図１１の要求マネージャの動作を詳しく説明する流れ図である。 図１１の通信フロー・マネージャの動作を詳しく説明する流れ図である。 アプリケーションでチーム会合の要求のパラメータを指定することができるＷｅｂフォーム例の図である。 図１４の要求のコンパイルした結果を示す図である。 要求側が、４時間のうちに好ましい顧客に割り当てる新会社の新規株式公開（ＩＰＯ）のブロック割り当てで株式を提供する場合の例を示す図である。 図１６の要求に応じて特定の受信者に送信される電子メール・メッセージの例の図である。

Claims (70)

1. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るための方法であって、
   前記少なくとも１人の受信者から応答を受信するステップと、
   前記応答に基づき前記通信フロー内の少なくとも１つの経路を選択するステップを含む方法。
2. さらに前記メッセージ内のｒｅｐｌｙ−ｔｏアドレスを修正し、前記応答が目的の宛先に必ず届くようにするステップを含む請求項１に記載の方法。
3. 前記修正されたｒｅｐｌｙ−ｔｏアドレスにより、媒介を前記送信者のエージェントとして使用できるようになっている請求項２に記載の方法。
4. 前記修正されたｒｅｐｌｙ−ｔｏアドレスにより、媒介が前記送信者に応答処理サービスを提供できるようになっている請求項２に記載の方法。
5. 前記選択するステップは、１人または複数の受信者へのその後続く通信を決定するステップを含む請求項１に記載の方法。
6. 前記選択するステップにおいて、受信した応答を集計し、定義済みメッセージ完了条件が満たされているかどうかを評価する請求項１に記載の方法。
7. 前記選択するステップは、応答情報を前記送信者に返す完了ステータスを決定するステップを含む請求項１に記載の方法。
8. 前記応答情報が前記送信者により指定された形式で前記送信者に供給されるようになっている請求項７に記載の方法。
9. 前記メッセージが前記対応する少なくとも１人の受信者により指定された環境設定情報に従って前記少なくとも１人の受信者に供給される請求項１に記載の方法。
10. 前記メッセージの内容は、前記メッセージが前記少なくとも１人の受信者に送られるのとほとんど時期を接して得られる請求項１に記載の方法。
11. さらに、前記通信フローを評価するステップを含み、前記通信フローは前記少なくとも１人の受信者により定義された少なくとも１つの通信フロー規則を参照し、前記通信フロー規則は前記受信者の少なくとも１つの環境設定を指定するステップを含む請求項１に記載の方法。
12. 前記通信フローは、前記少なくとも１人の受信者と関連する企業により指定された通りの前記少なくとも１人の受信者の少なくとも１つの環境設定を参照する請求項１に記載の方法。
13. 前記通信フロー規則は、少なくとも１つの時間条件を含む請求項１１に記載の方法。
14. 前記通信フロー規則は、少なくとも１つの媒体環境設定を含む請求項１１に記載の方法。
15. 前記通信フロー規則は、少なくとも１つの人間の言語タイプの環境設定を含む請求項１１に記載の方法。
16. 前記通信フロー規則は、前記メッセージが前記少なくとも１人の受信者に送られるのとほとんど時期を接して評価される請求項１１に記載の方法。
17. 前記通信フローは、前記メッセージを受信するため前記少なくとも１人の受信者の少なくとも１つの媒体環境設定を参照し、前記少なくとも１つの媒体環境設定を中央位置に格納する請求項１１に記載の方法。
18. 前記通信フローは、ＳＩＰプロキシで呼処理を制御する請求項１１に記載の方法。
19. 前記ＳＩＰプロキシは、着信したＳＩＰ ＩＮＶＩＴＥメッセージを評価し、前記少なくとも１人の受信者について適切な呼経路選択規則を選択する請求項１８に記載の方法。
20. 通信フローにより送信者から少なくとも１人の受信者にメッセージを送るための方法であって、
    前記送信者から前記メッセージを受信することと、
    前記通信フローを評価し、前記通信フローにより前記メッセージを配送するための前記送信者の少なくとも１つの環境設定を指定することと、
    前記送信者の前記環境設定に基づき前記メッセージを処理することを含む方法。
21. さらに、前記送信者により指定された形式で応答情報を前記送信者に供給するステップを含む請求項２０に記載の方法。
22. 前記メッセージの内容は、前記メッセージが前記少なくとも１人の受信者に送られるのとほとんど時期を接して得られる請求項２０に記載の方法。
23. さらに、前記通信フローを評価するステップを含み、前記通信フローは前記少なくとも１人の受信者により定義された少なくとも１つの通信フロー規則を参照し、前記通信フロー規則は前記受信者の少なくとも１つの環境設定を指定するステップを含む請求項２０に記載の方法。
24. 前記通信フローは、前記少なくとも１人の受信者と関連する企業により指定された通りの前記少なくとも１人の受信者の少なくとも１つの環境設定を参照する請求項２０に記載の方法。
25. 前記通信フロー規則は、少なくとも１つの時間条件を含む請求項２３に記載の方法。
26. 前記通信フロー規則は、少なくとも１つの媒体環境設定を含む請求項２３に記載の方法。
27. 前記通信フロー規則は、少なくとも１つの人間の言語タイプの環境設定を含む請求項２３に記載の方法。
28. 前記通信フロー規則は、前記メッセージが前記少なくとも１人の受信者に送られるのとほとんど時期を接して評価される請求項２３に記載の方法。
29. 前記通信フローは、前記メッセージを受信するため前記少なくとも１人の受信者の少なくとも１つの媒体環境設定を参照し、前記少なくとも１つの媒体環境設定を中央に一括して格納する請求項２３に記載の方法。
30. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るための方法であって、
    前記送信者から前記メッセージを受信することと、
    前記通信フローを評価し、前記メッセージを処理する方法を指示する少なくとも１つのプリミティブ・キーワードを含む通信フロー式により前記通信フローを制御することと、
    前記通信フロー式に基づき前記メッセージを処理することを含む方法。
31. 前記プリミティブ・キーワードは、２つの指定したオペランドＡおよびＢに対し同時に連絡を取らなければならないこと、および通信フロー式はＡおよびＢの両方が正常に応答した場合かつその場合に限り成功することを示す請求項３０に記載の方法。
32. 前記プリミティブ・キーワードは、２つの指定したオペランドＡおよびＢについて、Ａが正常に応答した場合にのみＢと連絡を取らなければならないこと、および通信フロー式はＡおよびＢの両方が正常に応答した場合かつその場合に限り成功することを示す請求項３０に記載の方法。
33. 前記プリミティブ・キーワードは、２つの指定したオペランドＡおよびＢに対し同時に連絡を取らなければならないこと、および通信フロー式はＡまたはＢのいずれかが正常に応答する限り成功することを示す請求項３０に記載の方法。
34. 前記プリミティブ・キーワードは、２つの指定したオペランドＡおよびＢについて、Ａと連絡を取ろうとして失敗した場合のみＢと連絡を取らなければならないこと、および通信フロー式はＡまたはＢのいずれかが正常に応答した場合に成功することを示す請求項３０に記載の方法。
35. 前記プリミティブ・キーワードは、２つの指定したオペランドＡおよびＢに対し同時に連絡を取らなければならないこと、および通信フロー式は応答する第１の連絡の値を持つことを示す請求項３０に記載の方法。
36. 前記プリミティブ・キーワードは、２つの指定したオペランドＡおよびＢについて、Ａと連絡を取ろうとして失敗した場合のみＢと連絡を取らなければならないこと、および通信フロー式は第１のｎｏｎ−ｍａｙｂｅ応答の値を持つことを示す請求項３０に記載の方法。
37. 前記プリミティブ・キーワードは、複数の受信者と同時に連絡を取らなければならないこと、および通信フロー式は成功応答の特定のしきい値を受信した場合に成功することを示す請求項３０に記載の方法。
38. 前記プリミティブ・キーワードは、複数の受信者と順次連絡を取らなければならないこと、および通信フロー式は成功応答の特定のしきい値を受信した場合に成功することを示す請求項３０に記載の方法。
39. 前記プリミティブ・キーワードは、並行して複数の受信者と連絡を取らなければならないことを示す請求項３０に記載の方法。
40. さらに、未処理要求が完了したときに未処理要求を取り消すステップを含む請求項３９に記載の方法。
41. 前記プリミティブ・キーワードは、順次複数の受信者と連絡を取らなければならないことを示す請求項３０に記載の方法。
42. 前記プリミティブ・キーワードは、１つまたは複数の潜在的オペランド値を反転しなければならないことを示す請求項３０に記載の方法。
43. 前記通信フロー式は、３値論理を使用して評価される請求項３０に記載の方法。
44. 前記３つの可能な論理値は、通知失敗（ｍａｙｂｅ）、応答失敗（ｆａｌｓｅ）、および応答成功（ｔｒｕｅ）である請求項４３に記載の方法。
45. 前記通信フロー式は、前記通信フロー式が終了しなければならない時期を指示する成功検査を含む請求項３０に記載の方法。
46. 前記成功検査で、前記少なくとも１人の受信者から受信した応答に含めることができる変数に対する３値論理式を指定する請求項４５に記載の方法。
47. 前記成功検査で、受信したすべての応答について集計を実行し、前記応答を処理する請求項４５に記載の方法。
48. 前記通信フロー式では、内容を段階的に次のレベルに引き上げることができ、前記段階的引き上げの前に現在のレベルと関連する保留メッセージを取り消す請求項３０に記載の方法。
49. 前記通信フロー式では、内容を段階的に次のレベルに引き上げることができ、前記段階的引き上げの前に現在のレベルと関連する保留メッセージを保持する請求項３０に記載の方法。
50. 前記通信フロー式は、前記送信者と前記少なくとも１人の受信者の環境設定を定義する請求項３０に記載の方法。
51. 前記通信フロー式は、前記少なくとも１人の受信者への配送時に評価される請求項３０に記載の方法。
52. 前記通信フロー式は、前記少なくとも１人の受信者により定義された通信フロー規則を参照し、前記通信フロー規則は、前記送信者の特性に合わせて前記通信フローを調整することができる請求項３０に記載の方法。
53. 前記通信フロー式は、前記少なくとも１人の受信者により定義された通信フロー規則を参照し、前記通信フロー規則は、前記メッセージの特性に合わせて前記通信フローを調整することができる請求項３０に記載の方法。
54. 前記通信フロー式は、前記少なくとも１人の受信者が前記メッセージに応答しない場合に実行する１つまたは複数のアクションを指示する請求項３０に記載の方法。
55. 前記通信フロー式により、前記少なくとも１人の受信者が前記メッセージを他の受信者に委託することができる請求項３０に記載の方法。
56. 前記通信フロー式により、前記メッセージを読み込んだ後、前記少なくとも１人の受信者が前記メッセージを他の受信者に委託することができる請求項３０に記載の方法。
57. 前記通信フロー式は、時間的制約条件５８を使用して、前記少なくとも１人の受信者の環境設定を指示する請求項３０に記載の方法。
58. 前記通信フロー式は、時間的領域を使用して、前記少なくとも１人の受信者の環境設定を指示する請求項３０に記載の方法。
59. 通信フローにより送信者から少なくとも１人の受信者にメッセージを送るための方法であって、
    前記送信者から前記メッセージを受信することと、
    前記通信フローを評価し、前記通信フローは前記メッセージが前記少なくとも１人の受信者に送られるのとほとんど時期を接して評価されることと、
    前記送信者の前記環境設定に基づき前記メッセージを処理することを含む方法。
60. さらに、前記メッセージが前記少なくとも１人の受信者に送られるのとほとんど時期を接して前記メッセージの内容を取得するステップを含む請求項５９に記載の方法。
61. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るための方法であって、
    前記送信者から前記メッセージを受信することと、
    前記通信フローを評価し、前記メッセージを処理する方法を指示する通信フロー式を含む通信フロー式により前記通信フローを制御し、前記通信フロー式は３値論理を使用して評価されることと、
    前記通信フロー式に基づき前記メッセージを処理することを含む方法。
62. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るためのシステムであって、
    コンピュータ読み取り可能コードを格納するメモリと、
    前記メモリに結合され動作可能なプロセッサを備え、前記プロセッサは前記コンピュータ読み取り可能コードを実行するように構成され、前記コンピュータ読み取り可能コードは、
    前記少なくとも１人の受信者から応答を受信し、
    前記応答に基づき前記通信フロー内の少なくとも１つの経路を選択するように構成されていることを含むシステム。
63. 通信フローにより送信者から少なくとも１人の受信者にメッセージを送るためのシステムであって、
    コンピュータ読み取り可能コードを格納するメモリと、
    前記メモリに結合され動作可能なプロセッサを備え、前記プロセッサは前記コンピュータ読み取り可能コードを実行するように構成され、前記コンピュータ読み取り可能コードは、
    前記送信者から前記メッセージを受信し、
    前記通信フローを評価し、前記通信フローにより前記メッセージを配送するための前記送信者の少なくとも１つの環境設定を指定し、
    前記送信者の前記環境設定に基づき前記メッセージを処理するように構成されているシステム。
64. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るためのシステムであって、
    コンピュータ読み取り可能コードを格納するメモリと、
    前記メモリに結合され動作可能なプロセッサを備え、前記プロセッサは前記コンピュータ読み取り可能コードを実行するように構成され、前記コンピュータ読み取り可能コードは、
    前記送信者から前記メッセージを受信し、
    前記通信フローを評価し、前記メッセージを処理する方法を指示する少なくとも１つのプリミティブ・キーワードを含む通信フロー式により前記通信フローを制御し、
    前記通信フロー式に基づき前記メッセージを処理するように構成されているシステム。
65. 通信フローにより送信者から少なくとも１人の受信者にメッセージを送るためのシステムであって、
    コンピュータ読み取り可能コードを格納するメモリと、
    前記メモリに結合され動作可能なプロセッサを備え、前記プロセッサは前記コンピュータ読み取り可能コードを実行するように構成され、前記コンピュータ読み取り可能コードは、
    前記送信者から前記メッセージを受信し、
    前記通信フローを評価し、前記通信フローは前記メッセージが前記少なくとも１人の受信者に送られるのとほとんど時期を接して評価され、
    前記送信者の前記環境設定に基づき前記メッセージを処理するように構成されているシステム。
66. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るためのシステムであって、
    コンピュータ読み取り可能コードを格納するメモリと、
    前記メモリに結合され動作可能なプロセッサを備え、前記プロセッサは前記コンピュータ読み取り可能コードを実行するように構成され、前記コンピュータ読み取り可能コードは、
    前記送信者から前記メッセージを受信し、
    前記通信フローを評価し、前記メッセージを処理する方法を指示する通信フロー式により前記通信フローを制御し、前記通信フロー式は３値論理を使用して評価され、
    前記通信フロー式に基づき前記メッセージを処理するように構成されているシステム。
67. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るためのシステムであって、
    前記少なくとも１人の受信者から応答を受信する手段と、
    前記応答に基づき前記通信フロー内の少なくとも１つの経路を選択する手段を備えるシステム。
68. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るためのシステムであって、
    前記送信者から前記メッセージを受信する手段と、
    前記通信フローを評価し、前記メッセージを処理する方法を指示する少なくとも１つのプリミティブ・キーワードを含む通信フロー式により前記通信フローを制御する手段と、
    前記通信フロー式に基づき前記メッセージを処理する手段を備えるシステム。
69. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るための製造品であって、
    コンピュータ読み取り可能コード手段が実装されているコンピュータ読み取り可能媒体を備え、前記コンピュータ読み取り可能プログラム・コード手段は、
    前記少なくとも１人の受信者から応答を受信するステップと、
    前記応答に基づき前記通信フロー内の少なくとも１つの経路を選択するステップを備える製造品。
70. 複数の潜在的経路を持つ通信フローにより送信者から少なくとも１人の受信者にメッセージを送るための製造品であって、
    コンピュータ読み取り可能コード手段が実装されているコンピュータ読み取り可能媒体を備え、前記コンピュータ読み取り可能プログラム・コード手段は、
    前記送信者から前記メッセージを受信するステップと、
    前記通信フローを評価するステップであって、前記メッセージを処理する方法を指示する少なくとも１つのプリミティブ・キーワードを含む通信フロー式により前記通信フローが制御されるステップと、
    前記通信フロー式に基づき前記メッセージを処理するステップを含む製造品。
    

Images