CN1520572A - 用于自动通知和响应的方法和设备 - Google Patents

Abstract

所公开的通知与响应系统允许应用利用多种不同的媒体与接收者进行通信。该通知与响应系统(i)利用每个单独接收者规定的媒体，将请求发送到一个或者多个接收者；(ii)收集并处理各响应；以及(iii)利用最终目的地规定的媒体，将各响应转发到其最终目的地。应用以至少一种人类语言和媒体格式编制请求，并根据他们的喜好将该请求传送到正确的接收者。通信流表达式规定给定请求的接收者，以及每个接收者将如何、何时以及何地接收该请求。动态更新各请求，而在传送该请求之前，不评估通信流表达式的参数。通信流规则规定接收者的通信喜好，并将通信流修改为发送者的特性、课题或调度约束。利用三值逻辑评估通信流表达式：通知失败(不确定)、响应失败(假)以及响应成功(真)。通过确定成功测试结果的逻辑组合，基元规定同时或顺序接触，以及何时终止装置子表达式的执行。

Description

用于自动通知和响应的方法和设备

相关专利申请的交叉参考

本专利申请要求2001年5月15日提交的第60/291,087号美国临时专利申请的优先权。

技术领域

本发明一般地涉及与一个或者多个接收者进行通信的方法和设备，本发明更特别地涉及利用一种或者多种不同类型的媒体，在应用与一个或者多个接收者之间自动进行通知和响应的方法和设备。

背景技术

企业应用需要接触人，而且存在如何接触，以及如果存在响应，收集什么响应的要求。例如，应用可能需要接触具有特定兴趣的所有人，或者人们或一个人的特殊列表。应用可能需要在危机中立即接触某个人，或者它们可能希望在适当时间提醒某人执行任务。企业应用还存在关于在接触不成功时做什么的要求，其中成功是由企业定义的。

另一方面，关于如何和何时接触他们，接收者具有自己的喜好。例如，在建立实时接触方面，接收者可能希望对特定的人，例如老板或家庭成员，或者代表特殊利益的人，例如Fortune 500公司的行政领导给予更大的灵活性。此外，对于已知的任务，例如每周的状况或消费更新，接收者通常可能推迟接触，直到时间或地点合适。通常，接收者的喜好与企业的喜好或特殊应用的实施不一致。在这些情况下，为了满足他们的喜好，接收者发现创造性方式以回避应用约束，或者发现企业的程序令人沮丧甚或令人烦恼。

为了使应用与一个或者多个接收者通信，已经建议或开发了多种通知系统。然而，现有通知系统通常在媒体和功能功能方面受限制。例如，通知系统可能仅将电子邮件消息发送到蜂窝电话或寻呼机。此外，现有通知系统不支持灵活使用不同通信基础设施。例如，无线业务，例如采用无线访问协议(WAP)的无线业务的增长导致开发许多仅接触一个装置，从而在蜂窝电话上推出和接收web窗体的响应的通知和响应业务，2000年6月的WAP论坛“WirelessAccess Protocol 1.2.1”中对WAP进行了描述。

例如在M.Handley等人的“SIP：Session Initiation Protocol”RFC 2543，March 1999中描述的对话启动协议(SIP)提供了一种登记表(registry)，其中通过特定装置的SIP统一资源定位器(URL)，可以使用户与该装置相关。现存的许多SIP代理均支持并行或顺序接触对给定用户记录在该登记表内的URL列表，从而与用户建立通信的能力。例如在J.Lennox和H.Schulzrinne的“CPL：ALanguage for User Control of Internet Telephony Services，”DraftRFC drat-ietf-iptel-cpl-05.txt，November 2001中描述的呼叫处理语言(CPL)是为SIP代理建议的语言。

CPL允许用户事先规定如何选择SIP INVITE消息的特定URL给定特征(根据SIP协议使用它以与用户建立联系)，例如在发送者地址和目标地址或INVITE的主体解释字符串。CPL还允许用户规定超时，因此在试图与接收者建立通信时，可以尝试将INVITE消息顺序序列发送到特定装置。此外，SIP还允许每个SIP装置或终点将其用户的喜好表示为媒体类型和人类语言的加权表。要求发送者根据他们可用的媒体类型和人类语言提供最高加权媒体类型和人类语言。SIP和CPL不对解释通信结果以及根据该结果采取不同的行动提供支持。例如，一旦电话呼叫被成功应答，则SIP和CPL就不能发现用户是挂断电话机，还是实际应答该请求。

尽管用于规定通过系统的数据流和程序流的技术足够多，但是可用的规定通信流的技术通常不成熟。通信流是从请求者到接收者的通路。这些现有通信流技术通常等于规定接收者利用某种预定接触方法进行请求，例如将电子邮件消息发送到邮箱或将消息发送到寻呼机。而通信流通路通常被看作两方之间的简单连接，现代通信能力能够实现各种通信流。例如，给定的通信流可以(i)并行或顺序接触接收者或接收者使用的装置；(ii)等待所有接收者或仅某些接收者响应该请求；或者(iii)在发生通信错误时，取不同方向。

因此，需要一种方便、准确规定诸如请求的接收者，以及每个接收者应该如何、何时以及何地接收该请求，而且响应如何管理后续通信的通信流参数的通用技术。还需要一种以捕获并组合应用的要求和接收者的喜好的方式规定通信参数的技术。

发明内容

本发明一般地公开了一种通知与响应系统，该通知与响应系统允许一个或者多个应用利用诸如电子邮件、电话、web页面、寻呼或传真的多种不同媒体与一个或者多个接收者进行通信。通常，该通知与响应系统(i)利用每个单独接收者规定的媒体，将请求发送到一个或者多个接收者；(ii)收集并处理各响应；以及(iii)利用最终目的地规定的媒体，将各响应转发到其最终目的地。

应用可以以任何一种所支持的人类语言和媒体格式编制请求，并根据每个接收者的媒体和人类语言的喜好，自动将该请求传送到正确的(各)接收者。因此，根据他们规定的喜好和终点能力，接收者从不同的应用或系统(或者它们二者)接收消息。以相应接收者方便的格式，使响应返回每个应用。应用可以将消息发送到一个或者多个接收者，或者根据预定接收者表或角色发送消息。接收者喜好与角色数据库对接收者表、角色以及接收者喜好进行集中管理。接收者喜好与角色数据库记录角色、人和装置信息以及有关通信流信息。

应用利用通信流表达式规定接触谁(“Bob”)、在什么条件下接触(“只在Ann说是时”)以及何时接触(“除星期日之外任何一天的上午9点至下午5点”)。利用如何，即使用哪个装置以及何时接触他们的细节，接收者规定改进通信流表达式的规则。接收者还可以自动对其他接收者委托一些请求。根据本发明的一个特征，在传送该请求之前，可以利用新信息动态更新该请求，因此接收者可以接收最新商业信息。此外，在传送请求时，评估通信流表达式的参数(谁、何时以及何地)，以便根据接收者的最新喜好，传送请求。

应用将请求送到所公开的通知与响应系统，要求将特定通知消息送到一个或者多个接收者，而且该应用响应所收集并返回请求者或转发到另一个应用的通知。请求包括：(i)通知消息、(ii)请求参数、(iii)通信流表达式以及(iv)响应。可以以所支持的任何一种人类语言和媒体格式编制通知消息，并根据每个接收者的媒体和人类语言喜好，将请求自动传送到正确的(各)接收者。请求参数规定必须能够用于通知与响应系统以控制请求的行为或正确格式化该请求(或者它们二者)的信息。

通信流表达式捕获并组合应用要求和接收者的喜好。请求的通信流表达式部分规定与请求有关的接收者(“谁”)，以及该接收者如何、何时和何地接收该请求。接收者可以是角色(例如，“客户服务”)、人(例如，“Jerry”)、装置(例如，“800-555-1234”)或将被评估的其他通信流表达式。每个接收者是活动的，因为各接收者可以提供用于规定他们的通信喜好并用于将他们的通信流修改为发送者的特性、请求的课题或他们的安排要求的通信流规则。通常，根据接收者的喜好，通信流规则利用关于何时、何地以及如何接触接收者的详情代替通信流中接收者的名称。通信流表达式还规定在特定接收者未成功响应请求时采取什么动作。

通知与响应系统可以利用通信流中的成功测试评估响应者规定的值，以确定特定接触是否成功。响应者是已经收到请求而且已经返回了响应的人。在收到响应时，通知与响应系统转发每个单独响应的属性值，或者在请求完成之后，将校验的结果转发到初始请求规定的最终目的地。

发生通信流失败的原因有两个。首先，可以简单是不能接触接收者，或者接收者始终不能响应通知，称为通知失败(反之则称为通知成功)。其次，可以接触接收者，随后接收者接收或拒绝响应，分别称为响应成功(所谓“真”或“是”)，或响应失败(所谓“假”或“否”)。

根据本发明的另一个特征，利用三值逻辑评估通信流表达式。3个可能的逻辑值是通知失败(不确定)、响应失败(假)以及响应成功(真)。对于许多装置，在收到接收者发出的响应时，只能知道通知已经被接收。因此，与请求有关的成功表达式对可能包括在从接收者接收的响应内的各变量规定三值逻辑表达式。成功表达式测试响应中各值的逻辑组合，如果存在响应成功，则接触被评估为“真”，如果存在响应失败，则接触被评估为“假”，否则，如果不对响应留出更长时间，则存在通知失败，而且接触被评估为“不确定”。

通信流表达式包括一个或者多个基元，从而通过确定成功测试结果的逻辑组合，规定是同时还是顺序接触接收者，以及应该何时终止执行子表达式。更具体地说，基元将并行或顺序通信的方向与对与接收者的通信状态如何影响通信流的进行评估组合在一起。其他基元控制何时进行接触，或者如何根据目录中的对象列表建立通信流。

当然，可以将所公开的通知与响应系统采用的基元分组为下面的并行/顺序对：“and/then”、“or/else”、“races/delegates”以及“votes/polls”。并行与顺序基元在如何评估操作数方面不同。在并行基元中，并行接触每个接收者。在不再需要确定基元的真值时，取消未完成的请求。在顺序基元中，以接收者出现的顺序，对每个接收者发出请求。在接收者响应时，如果需要，将请求发送到下一个接收者以确定该基元的真值。每个基元被评估为真、假或不确定，取决于与接收者的通信是否成功。

通过参考以下的详细说明和附图，可以更全面地理解本发明以及本发明的其他特征和优点。

附图说明

图1示出包含了本发明特征的通知与响应系统；

图2更详细示出图1所示通知与响应系统；

图3是图2所示请求管理器采用的典型请求数据库中的采样表；

图4是示出引入了本发明特征的三值逻辑评估器的流程图；

图5是图2所示的典型接收者喜好与角色数据库中的采样表；

图6示出图5所示接收者喜好与角色数据库中的、指出大量接收者的个人命名上下文的部分LDAP目录树；

图7是另一部分图5所示典型接收者喜好与角色数据库中的采样表；

图8是根据本发明指出一组典型通信流表达式基元的采样表；

图9A至9E示出图8所示各种基元的真值表；

图10是概括了图8所示每个基元的计数的采样表；

图11示出图2所示请求管理器与通信流管理器之间的交互；

图12A和12B一起是更详细示出图11所示请求管理器的运行过程的流程图；

图13是更详细示出图11所示通信流管理器的运行过程的流程图；

图14示出允许应用规定团队会议请求参数的典型web窗体；

图15示出图14所示请求的编译结果；

图16示出其中请求者在4小时期间内对优选客户提供新公司的初始公众股((initial public offering)IPO)的整笔拨款股份；以及

图17示出根据图16所示请求发送到特定接收者的典型电子邮件消息。

优选实施例的详细说明

本发明提供了一种通知与响应系统100，如图1所示，它使一个或者多个应用(application)110-1至110-N通过多种不同媒体(例如，电子邮件、电话、网页、寻呼机或传真)与一个或者多个接收者120-1至120-N通信，以下将一个或者多个应用110-1至110-N统称为应用110，而将一个或者多个接收者120-1至120-N被统称为接收者120。通常，通知与响应系统100(i)利用每个单独接收者120指定的媒体，将请求发送到一个或者多个接收者120；(ii)收集并处理响应；以及(iii)利用最终目的地指定的媒体，将响应转发到其最终目的地。

图2更详细示出通知与响应系统100。如图2所示，而且如下所述，通过应用接口(interface)220，应用110向请求管理器1200提交请求，应用接口220提供提交请求或取消请求、检验请求的状态以及将结果返回应用110的服务。通过HTTP POST，应用可以将通知请求和用于取消未决(pending)通知的请求提交到正确的应用接口220。

可以将应用接口220实现为例如简单对象访问协议(SOAP)或许多商业企业应用集成(EAI)接口，例如IBM公司市售的MQSeries^TM接口，或Sun Microsystems，Inc市售的J2EE^TM接口。对于每个请求，应用接口220在通知与响应系统100的外部请求表示与内部表示之间建立映像关系。同样，对于每个响应，应用接口220在通知与响应系统100的内部响应表示与外部表示之间建立映像关系。

以下将结合图11说明请求管理器1200，请求管理器1200跟踪已经提交的所有请求。如结合图3所述，请求管理器1200保持请求数据库300，请求数据库300包括关于每个请求的信息并指出每个请求的状态，例如未决、取消或完成。请求数据库300可以保持在其中可以存储请求及其当前状态(包括响应)的存储器或持久性数据库中。在其他功能中，请求管理器1200对每个请求分配唯一标识符，该标识符可以用于识别接收者120应该接收的请求和响应应答的请求。此外，在需要时，请求管理器1200修改请求以确保将响应转发回通知与响应系统100。

如上所述，应用110利用通信流表达式(expression)规定给定请求的参数。在与接收者进行每种媒体特定通信时，请求管理器1200沿通信流的方向执行。请求管理器1200使用通信流管理器1300的通信流表达式服务，以下将结合图13进行说明。以下将结合图11说明请求管理器1200与通信流管理器1300之间的交互。

通常，通信流管理器1300将请求确定的目标通信流解释成更有效的树形结构内部表示。此外，通信流管理器1300重复遍历树表示，而且在此过程中，扩展非装置接收者和实例装置。在每次重复过程中，通信流管理器1300输入可用的任意成功测试结果，并确定是应该取消未决接触还是应该发起新接触。因此，通信流管理器1300解释并执行通信流表达式以确定如何将请求传送到正确接收者120，并确定如何对每次通信尝试的成功或失败做出响应。

目录接口250在通知与响应系统100使用的角色、人以及装置的内部表示与接收者喜好与角色数据库500中的表示之间建立映像关系。此外，目录接口250处理搜索和其他请求。通常，利用接触角色和接收者名字的通信流表示通信流管理器1300，需要对通知与响应系统100知道如何接触的装置决定角色和接收者名字。为了支持使用其他类型的数据库并使内部表示独立于正在使用的特定目录模式，可在一个类内映像通知与响应系统100中的目录模式(scheme)和内部表示。该类还提供了一组特定搜索和检索方法。

媒体专用接触(media specific contact)270对实际传送通知进行处理，而在某些情况下，对响应收集过程进行处理。如果在可指定时长或可指定尝试次数之后，不能进行通过特定媒体的接触，则将通知失败消息返回请求管理器1200。将在下面的“媒体专用接口”小节进一步说明媒体专用接口270。对于每个通知消息，媒体专用接口270在通知与响应系统100的内部请求文档表示与外部表示之间建立映像关系。同样，对于每个响应，媒体专用接口270在外部响应表示与通知与响应系统100的内部表示之间建立映像关系。

web入口280通过各种媒体将数据送到接收者120并收集响应。Web入口280是对接收者未决的、完成的以及取消的通知进行存取的服务小程序(servlet)集。它包括显示未决通知列表以便接收者可选择一个未决通知从而读出或监听的服务小程序，以及用于显示通知的一个服务小程序，以及收集响应的另一服务小程序。以这样的方式构造Web入口280，以便通知与响应系统100直接传送所有通知，而且通知与响应系统100收集所有响应。集中实现使得可以控制通知的内容、可以使通知实现个性化而且可以使通知包含先前的响应。利用同一个重写机制处理接收者喜好与角色数据库500输出的个性化数据，该重写机制修改窗体动作标记(form action tag)以指向正确的服务小程序。

通知与响应系统100将所有请求传达到通信流表达式规定的接收者120。这样可以使通知与响应系统100记录响应并将这些响应送到通信流管理器1300。根据这些响应的内容，通信流管理器1300选择不同的路径通过通信流。例如，对于典型web应用程序接口(API)，所有请求均被表示为网页，而且这些要求的响应包括用于接收该响应的窗体(form)。重写各请求以便直接响应给定的URL，因此，可以在重新路由选择到对通知与响应系统100发出的原始请求规定的最终目的地之前，记录完成状态。通知与响应系统100的路由选择与返回过程适于规定请求和响应的各种方法，例如，统一消息传送系统或基于XML的API。

本发明提供个性化消息传送(在接收者希望的时间以他们希望的方式，接收者接收消息)。通知与响应系统100以所支持的多种人类语言和媒体格式(例如：电子邮件、电话、网页、寻呼机或传真)中的任何一种，传送请求和收集响应。此外，通知与响应系统100对请求者和接收者、响应校验(collation)以及从现有应用透明路由选择请求(和对现有应用的响应)进行集中请求管理。

请求

应用110将请求发送到通知与响应系统100，通知与响应系统100要求将特定通知消息发送到一个或者多个接收者，并要求收集对该通知的响应、将该通知的响应返回请求者或转发到另一个应用。在此使用的请求包括(i)通知消息、(ii)请求参数、(iii)通信流以及(iv)响应。

通知消息

为了支持通过不同媒体、以不同人类语言进行传送，应用110可以建立一种或者多种版本的请求。换句话说，应用110准备数据文件，服务小程序将该数据文件变换为接收者喜好接收类型的文档，然后，应用110将该服务小程序的URL传送到通知与响应系统100。例如，希望将会议通知发送到一个或者多个接收者的应用110可以创建含有该消息以及用于处理可能响应(如果存在)的窗体(form)的HTML文档。然后，将该HTML文档存储到web服务器，并将URL传送到通知与响应系统100。

利用服务小程序以特定媒体格式产生消息显示了本发明的优点之一。在传送时，可以使该消息的媒体满足接收者的要求和喜好，而且在可以在传送时，产生该消息的内容，以使它始终含有最新信息。例如，本发明采用的许多媒体接触(contact)首先对接收者指出有该接收者的通知消息，例如，指出该接收者必须呼叫指定电话号码，以检索通知消息或含有到含有该通知消息的网页的超级链接的电子邮件消息的页面。此后，接收者访问该通知消息，并在访问时，对接收者显示最新版本的通知消息。这样，在接收者实际访问该通知消息之前，请求者可以更新该通知消息。

请求参数

请求具有一组相关参数。这些参数规定对通知与响应系统1 00控制请求的行为或者正确格式化该请求(或者它们二者)必须可用的信息。如上所述，利用包括关于每个请求的信息并指出每个请求的状态(例如：未决、取消或完成)的请求数据库300，请求管理器1200跟踪所有已经提交的通知请求。

图3是典型请求数据库300中的采样表。如图3所示，典型请求数据库300包括多个每个分别与不同请求相关的记录305至315。对于在字段330识别的每个请求，记录在请求数据库300内的参数包括(i)字段335内的请求者标识符(即，人名或产生该请求的应用)；(ii)字段340内的响应目的地(例如，响应应该被转发到的URL，或指出如何路由选择响应的通信流表达式以及关于是在请求结束时发送校验的响应还是在接收每个响应时转发它的指示)；(iii)字段345内的主题(即，在电子邮件主题行内可以采用的、对请求的简要描述)；(iv)字段350内的最长寿命(即，通知与响应系统100应该连续尝试传送请求并收集响应的时间长度，该时间之后，应该取消所有未决请求，并应该将任何收集的响应发送到其最终目的地)；(v)字段355内的语言(即，通知消息可以采用的语言)；(vi)字段360内的、该消息可以采用的内容类型，例如HTML、VXML以及明文，字段365内的通信流表达式；(vii)指出接收的响应是否应该对其他指定接收者可视或可用的公开/专用标记；以及(viii)字段375内的、请求的当前状态。

请注意，给定应用110可以以支持的一种或者多种人类语言提供包括主题头部的、每个通知消息的内容，或者以要求的支持人类语言自动翻译包括主题头部的、每个通知消息的内容。在其他变换例中，可以利用用于规定应该如何和何时进行语言翻译的规则代替字段355内的语言参数，而且可以利用用于规定应该如何和何时产生内容类型的规则代替内容类型参数。

通信流

正如以下进一步说明的那样，在“通信流”小节内，通知与响应系统100采用通信流表达式(expression)规定谁、如何、何时以及何地进行通信。通信流表达式规定请求的接收者。接收者可以是角色(role)(例如，“客户服务”)、人(例如，“Jerry”)、装置(例如，“800-555-1234”)、软件应用或代理(例如，“日程代理”)或通信流表达式。此外，通信流表达式还规定接收者如何、何时以及何地接收请求。通信流表达式还规定在特定接收者未能成功响应请求时采取什么动作。

通信流表达式捕获应用要求和接收者的喜好，并将它们组合在一起。通信流表达式是活动接收者列表。每个接收者是活动的，因为接收者提供根据接收者喜好与角色，利用关于何时、何地以及如何接触他们的进一步细节代替他们在通信流中的名称的通信流规则。这些通信流规则允许接收者将他们的个人通信流包含到该请求的通信流表达式中。接收者利用该规则规定其通信喜好，并使其通信流满足发送者的特征，请求的课题或其调度要求。

响应

正如以下进一步说明的那样，在“通信流”小节内，通知与响应系统100可以采用通信流中的成功测试来估计响应者规定的值，从而确定特定接触是否成功。响应者是已经收到请求并返回了响应的人。在接收响应时，通知与响应系统100将每个单独响应的属性值对，或请求完成后的校验的结果转发到初始请求规定的最终目的地。在典型实施过程中，通知与响应系统100一直等待直到在返回任何结果之前执行了整个通信流，但是在接收它时进行修改以返回每个响应并不重要。

通信流

通信流的特征在于通信流表达式、成功规范、通信流规则以及参数。通信流表达式将应用的通信要求与用户的通信喜好结合起来。通信流表达式规定请求的接收者(利用名字直接规定，或者利用确定的接收者列表或角色规定)。此外，通信流表达式规定接收者将如何、何时以及何地接收请求。通信流表达式还规定在特定接收者不能成功响应请求时采取什么动作。

通信流成功/失败规范

通信流成功规范(specification)描述通信流中每个步骤的响应成功和失败的条件。在典型实现过程中，通信流成功规范既支持全系统缺省成功规范，又支持请求者对特定通信流确定的成功规范缺省。作为一种选择，如下所述，在通信流中，测试响应状态(testresponse status)基元(primitive)允许请求者对每个接收者规定成功规范。

发生通信流失败的原因有两个。首先，可以简单是不能接触接收者，或者接收者始终不能响应通知，称为通知失败(反之则称为通知成功)。其次，可以接触接收者，随后接收者拒绝响应或回答为否定，称为响应失败(所谓“否”)，或响应成功(所谓“是”)。“否”和“是”具有语义成分，因为只有该应用可以确定接收者是否为了使该通信流连续已经可接受地响应了请求。例如，在接收者再检查文档并反对接受时，可以出现响应成功。接收者已经说了“是的，我需要再检查”，而且对于下一个检查者通信流继续。相反，在接收者再检查并拒绝软件修订的请求时，出现响应失败。接收者已经说了“否，我们不进行此软件修订”，而且该通信流结束，或者在进行差错处理情况下，该通信流继续。

根据本发明的一个方面，利用三值逻辑评估器400评估通信流表达式，如图4所示。3个可能的逻辑值是步骤420期间的通知失败(不确定)、步骤450期间的响应失败(假)以及步骤440期间的响应成功(真)。如图4所示，通知成功是在步骤410期间识别的过渡状态，在响应成功或响应失败之前出现该过渡状态，因此，不直接表示它。对于许多装置，在收到接收者发出的响应时，只能知道通知已经被接收。

成功表达式对可能包括在从接收者120接收的响应内的各变量规定三值逻辑表达式。即，通知通常含有HTML窗体、VXML对话或等效对象。窗体例如使名字与响应者规定的值相关。成功表达式测试响应中各值的逻辑组合，如果存在响应成功，则接触被评估为“真”，如果存在响应失败，则接触被评估为“假”，否则，如果不对响应留出更长时间，则存在通知失败，而且接触被评估为“不确定”。

例如，对含有包括一个窗体的通知的HTML页面进行研究，该窗体具有一个被称为“Submit(提交)”的按钮，在点击该按钮时，该按钮的值被设置为“true(真)”。该页面的成功表达式可以是“Submit＝true”。股票价格变化的通知可能含有一对被称为“Action(动作)”、可以取值“buy(买)”或“sell(卖)”的无线电按钮，以及另一个被称为“quantity(数量)”、可以取数值的字段。该页面的成功表达式可以是“Action＝buy&Quantity＞1000”。可以将成功测试规定为例如“A？Submit＝“true”？”，这意味着接触A，而且在接收响应时，如果响应对参数“Submit”赋予值“真”，则确定该接触为“真”。如果“Submit”的值不是真值，则接触为“false(假)”，而如果不对所接收的响应留出更长时间，则接触被评估为“maybe(不确定)”。

示例表明在通信流表达式中采用三值逻辑比二值逻辑有利。假定一个人如果接触Joann成功，就想接触Tom，或者如果接触Joann失败，就想接触Priya。利用传统二值逻辑基元“then(则)”和“else(否则)”，可以将此关系表示为：

(Joann then Tom)or(Joann else Priya)

现在进一步假定Joann利用同一个逻辑规定她更喜好通过蜂窝电话(cell)接触，或如果通过蜂窝电话接触失败则通过办公室(office)电话接触，或者如果通过办公室电话接触失败则将请求委托(delegate)给Jerry：

cell else office else Jerry

该表达存在内在问题，因为，毫无疑问，根据Joann发出的实际响应的结果，请求者希望接触Tom或Priyq，而且如果她没有响应(即，如果她响应为“否”)，则Joann仅希望接触Jerry。根据传统二值逻辑不可能得到所有这些结论。正如在下面的小节所述，在本发明的三值逻辑中，如果Joann说了“是”，则仅接触Tom，如果Joann未给出用“是”响应，则仅接触Priya，而且如果Joann根据没有响应，则仅接触Jerry。

通信流接收者

如上所述，通信流表达式提供了一种灵活、通用技术，该技术规定请求的接收者以及如何根据接收者接收的应答进行通信。在典型实现过程中，可以将图5所示的接收者喜好与角色数据库500实现为轻型目录访问协议(LDAP)目录，例如在M.Wahl等人的“Lightweight Directory Access protocol(v3)”RFC 2251(Dec.1997)中对它进行了描述，在此引用该文献供参考。接收者喜好与角色数据库500保持用于描述出现在通信流表达式中的接收者的对象。如图5所示，典型接收者喜好与角色数据库500包括多个分别与不同接收者相关的记录505-520。

对于字段530内的每个接收者，接收者喜好与角色数据库500识别字段540内的接收者类型以及字段550内对接收者确定的个人通信流。可以出现在字段540内的接收者的类型是人、角色、应用、装置、命名的通信流或用于接触各接收者的方法。尽管人、角色或命名的通信流对象可以规定用于接触接收者的通信流表达式，但是用于接触各接收者的方法或应用(或媒体接触对象)是接收者名字翻译过程的终端对象(即，在该目录中不再进一步翻译该对象)。该对象包括对于到达该个人或作为该个人的代理的应用重要的属性，具体地说是进行接触的地址、协议、超时以及重发间隔。

根据本发明的另一个方面，被称为动态通信流表达式置换，在接收者喜好与角色数据库500中将接收者的名字绑定到信息的过程被延迟到接触时间。因此，本发明的后绑定方面意味着，在系统100开始尝试通知其之前，可以变更作为角色的接收者，例如公司的CEO。此外，在旅游期间，接收者的个人通信流，例如办公室电话号码可以变更为外出电话(away phone)，而在开始旅游之前提交的请求仍可以成功使用它。

在通过媒体接触接触接收者时，接收者可以请求，在通信流中，利用不同的通信流表达式代替他或她的表达式。这样允许接收者将任务动态委托给多个正确接收者。通过将通信流代入具有延迟子句例如用于产生在延迟4小时之后处理请求的提醒的“Joann after+4:00”的通信流表达式中，这样还允许接收者延迟任务。

图5提供示出不同类型接收者的典型接收者喜好与角色数据库500中的大量典型对象。以下将在“基元”小节内对接收者喜好与角色数据库500采用的典型基元进行说明。例如，如记录505所示，接收者“Joann”利用下面的表达式对所有请求规定后面的个人通信流：

(cell races email)delegates Jerry

这样，在接触Joann时，应该呼叫Joann的蜂窝电话，并且同时对她发送电子邮件。如果Joann未应答，则应该接触Jerry以认为是Joann的请求(根据Jerry的个人通信流)。如果Joann自己应答该请求，则绝对不接触Jerry。

在记录510所示的例子中，角色SysAdmin规定用于将请求路由选择到管理员以实现当前移动的个人通信流：

(Sam between 0:800-16:59 or Sue between 17:00-00:59

or Greg between 01:00-07:59)delegates SysAdmin

在从上午8点开始的工作日期间，记录510内的角色将请求送到在特定时间期间工作的系统管理员。如果在请求处理的第一个工作日，未能接触管理员，则括号内的子句失败，而在第二天，利用递归SysAdmin引用重复进行接触尝试。

请注意，例如SysAdmin角色中的接收者的递归引用(recursivereference)仅允许在存在其他终止条件的通信流中跟随顺序基元。在SysAdmin例子中，在接收到响应时请求以真或假完成，或者在到达请求者设定超时时，请求以通知失败(不确定)完成。

即使利用该预防，仍可能在目录中出现通过循环名称引用的循环。例如，Joann的通信流表达式可以是“Tom”，而Tom的通信流表达式可以是“Joann”。此外，在这种情况下，并行与顺序递归引用之间的区别避免了不可控的资源紧张循环。通过分析名称翻译历史，可以防止没有其他终止条件的所有并行循环引用和顺序循环引用。尽管关于Joann和Tom的上述例子可能错误，但是以下情况是可以接受的：Joann的通信流表达式试图通过电子邮件接触她，而在失败时委托给Tom，Tom的通信流表达式简单交回给Joann(因为Tom度假)。作为迅速或者通过长周期循环到同一个接收者的请求的最终预防，在尝试接触接收者的次数超过规定的最多次数时，通信流表达式就返回错误。

为了继续图5所示的例子，记录415内的命名通信流“Reviewer”(检查者)规定为了进行再检查而必须接触的一系列接收者：

Chris and Jerry and Benji and Jenny

在所有检查者成功响应时，对“Reviewer”的请求成功。正如以下在“通信流基元”小节所述的那样，“vote”基元可以用于改变该列表的成功判据。例如：

Reviewer votes 2

在两个检查者成功响应时，成功完成。

请注意，接收者喜好与角色500内的媒体接触对象还可以是软件代理。例如，日程代理(calendor agent)可以提供3种媒体接触，在下面的通信流中，将这3个媒体接触组合在一起：

HoldCal then(Cell then ScheduleCal else CancelCal)

如果HoldCal发现请求的日期有效，则通过蜂窝电话接触该用户以批准会议用途。如果用户批准会议用途，则安排会议时间，否则，取消会议。

LDAP目录树

图6示出指出多个接收者的个人命名上下文的部分LDAP目录树600。LDAP目录树600是记录在接收者喜好与角色数据库500内的用户喜好信息的图解表示。例如，图6所示的LDAP目录树600包括接收者Joann的个人命名上下文610和接收者Tom的个人命名上下文620。接收者Joann的个人命名上下文610具有确定的规则、通信流表达式以及媒体接触。接收者Tom使用缺省规则、通信流表达式以及媒体接触。

通信流规则和参数

通信流规则规定何时将接收者的名字翻译为特定个人通信流表达式。接收者可以根据诸如标题参数和请求者参数的请求参数规定条件，以控制将哪个个人通信流表达式用于特定请求。例如，接收者可以通过蜂窝电话选择要立即处理的特定课题(正如标题所表示的那样)或请求者。他们可以通过电子邮件或web选择待之后处理的其他类型的请求。

与其他基于喜好的系统不同，通信流管理器1300中的喜好处理是与传送请求集成在一起的通用机制。接收者120的规则和个人通信流表达式对该接收者120建立个人命名上下文(personal namingcontext)610。翻译接收者的名称和接收者的规则或通信流表达式中的名称要与接收者上下文相对应。与其他基于上下文的命名系统不同，该基于规则的喜好处理过程不妨碍名称的全程意义。全程名对(global name)全程保持可视和可用。因为此原因，接收者可以容易地使用全程名来规定他们希望将特定类型的请求委托给某个其他人。个人命名上下文610进行对接收者上下文重要而且适当，同时支持有意义的全程名的翻译。

因此，如图6所示，Joann的个人命名上下文610包括对应于3个通信流规则，即管理器规则630、族规则640以及书面工作规则650的节点。每个接收者的个人命名上下文，例如接收者Joann的个人命名上下文610被建立为其根在LDAP目录树600中的InetOrgPerson{RFC2798}或InetOrgRole对象的子树。InetOrgPerson对象是用于描述关于人的接触信息的LDAP标准对象，而InetOrgRole对象是LDAP标准对象类OrgRole{RFC2256}的子类。例如，在图6中，Joann的个人命名上下文610的根在被标记为“UID＝joann”的InetOrgPerson节点。

每个个人命名上下文610可以具有3种与通信流表达式处理过程有关的对象：通信流规则对象、命名通信流表达式对象以及媒体接触对象。在图6中，个人命名上下文610中最高的3个条目630、640、650代表3个通信流规则，它们的名字是：MgrRule、FamilyRule以及PaperwrkR。节点660、670、680与3个分别名字为：web、cell(蜂窝电话)和email(电子邮件)的媒体接触对象对应。节点690、695与两个名字为：UrgentCF和RelaxedCF的命名通信流表达式对应。

可以在接收者喜好与角色数据库500内确定通信流规则，例如Joann规定的管理器规则630、族规则640以及书面工作规则650。确定管理器规则630、族规则640以及书面工作规则650的接收者喜好与角色数据库500内的相应对象示于图7。具体地说，接收者喜好与角色数据库500包括用于确定管理器规则630的记录710、用于确定族规则640的记录720以及用于确定书面工作规则650的记录730。

诸如图7所示通信流规则的每个通信流规则包括下面4个属性：活动、顺序、条件以及通信流表达式。活动被设置为“是”或“否”。在将接收者的名称翻译为个人通信流时，不考虑不活动的、即被设置为“否”的规则。顺序属性用于对接收者命名上下文610中的所有活动规则进行排序以进行评估。依次测试该顺序的每个规则的条件。各条件是包括诸如等同、不等同、范围以及正常表达式匹配的属性值比较的逻辑表达式。一旦满足条件，则为了传送该请求，将接收者的名称翻译为伴随通信流表达式。利用用户名或uid，MgrRule的条件测试特定请求者。FamilyRule的条件测试以“Family”开头的标题。始终满足PaperwrkR的条件。PaperwrkR是在其他规则不满足时采用的缺省规则。因为此原因，其顺序号是最大号。

如图7所示，记录710、720和730内的每个典型规则至少引用一个命名通信流表达式(urgentCF 690或relaxedCF 695)。在接收者喜好与角色数据库500中，可以将urgentCF或relaxedCF通信流表达式定义为命名通信流表达式，如下所述：

UrgentCF：cell races officephon races homephone

RelaxedCF：email races web

这样，命名通信流表达式使接收者Joann根据规则中规定的条件建立用于被接触的各种规则。

在建立规则时，对通用接触方法建立命名通信流表达式通常有用。这样，接收者可以一次性更新命名通信流表达式中的特定引用，而且自动更新引用被变更的命名通信流表达式的所有通信流规则。然后，该规则参考有时对各种用途使用同一个命名通信流的命名流。规则PaperwrkR简单使用命名通信流(relaxedCF 695)。规则MgrRule对何时可以紧急接触接收者设置临时限制，并始终使用松弛接触通信流。规则FamilyRule使用所有可用媒体接触。

通过升级(escalation)，通信流规则还使企业雇员提供紧急响应。例如，假定企业必须对客户的请求立即做出响应，而且从客户接收到包括关键字“紧急业务”的标题的请求。还假定对至少一个企业雇员规定下面的通信流规则：

Title＝”^*Urgent Business^*”；

Communication flow：(cellphone races paper)before+0:05delegates manager

“manager”(管理者)是在接收者目录条目中使用管理者链路以发现正确管理者的缺省命名通信流。在接收到包括关键字“紧急业务”的标题的请求时，触发升级规则。如果雇员在五(5)分钟内不应答他或她的蜂窝电话或寻呼，则将该请求升级到“manager”。

通常，实现升级的通信流采用委托基元，其中在升级到下一级之前，取消该请求。在其他变换例中，通信流可以升级，而不对通路中在先的人们取消未完成的请求。例如，后面的对象通信流实现升级，而不对通路中在先的人们取消未完成的请求：

(Tom else Manager)races(Manager after+04:00)

该通信流将首先仅接触Tom，然后，如果初始响应失败，则立即接触被确定的“Manager”(管理者)。此外，四(4)小时之后，升级该请求，而且仅接收Tom或“Manager”发出的第一响应。请注意，通知与响应系统100可以任选保持关于为什么取消给定请求的信息，而且可以将这种信息送到与取消的请求有关的接收者。

在该通信流表达式中，尽管在同一个时间，在通信流中，可以将被命名为“Manager”的接收者激活两次，但是仍可以利用优化过程仅接触“Manager”一次。接收者名称的每个实例被将它贡献给该请求的实体拥有，即被提供个人通信流的请求者或人或角色拥有。如果接收者名称识别同一个对象/接收者，而且接收者名称的所有者相同，则对于这些名字，仅接触一次接收者。如果所有者不同，则假定接收者可能希望以不同方式作为所有者的代表，因此，利用关于谁将请求委托给接收者的注释，不止一次接触接收者。

可以利用存在与可用性信息修改以上结合图5至7说明的、记录在接收者喜好与角色数据库500和LDAP目录树600上的用户喜好。例如，接收者可以规定他或她的喜好，如下所述：

(present(cell)then cell)delegates(present(email)then email)

利用对蜂窝媒体接触可用的接收者与装置信息，当前函数(present function)接触存在服务器。如果存在服务器(presenceserver)指出蜂窝电话开机，则当前函数返回“真”。如果蜂窝电话未开机，则当前函数返回“不确定”。同样，如果接收者为了进行电子邮件媒体接触在使用网络，则当前函数返回“真”。如果未使用网络，则返回“不确定”。如果接收者使用蜂窝电话，则通过蜂窝电话接触他或她。如果不存在接收者，或者如果接触失败，则检验网络，而如果在此存在接收者，则发送电子邮件。根据存在服务器提供的特征，当前函数或多或少被复杂化。还请注意，通信流规则允许接收者限制哪个请求者或哪种类型的请求可以通过存在服务器进入他们。

在存在与可用性信息的另一种应用中，通过跳过存在信息指出将失败(例如，蜂窝电话关机)的通信尝试(例如，电话呼叫)，媒体接触可以优化其行为。可以简单进行媒体接触，就象尝试的电话呼叫失败。

还可以由企业确定用户喜好。例如，根据客户的支付历史，企业可以以不断提高的强硬性将通知发送到客户。例如，正如以下对“delegate”(委托)基元所做的说明进一步说明的那样，支付历史糟糕的客户可以通过自动电话呼叫接收第一到期通知，而通过托收代理接收第二通知。具有一般支付历史的客户可以通过邮寄服务接收第一到期通知，通过自动电话呼叫接收第二通知，通过托收代理接收第三通知。

目录缺省和试探

通信流管理器1300利用LDAP目录树600(参考图6)上的缺省目录以便快速安装并容易使用，以下将结合图13进一步说明通信流管理器1300。在搜索目录时，通过进行试探，通信流管理器1300使得更便于使用。在通信流管理器1300首先安装在企业时，通信流管理器1300将运行现有企业LDAP目录500。除了关于现有企业LDAP目录500的配置的信息外，通信流管理器1300要求对其应用特定对象建立对象类(即，通信流、通信流规则、媒体接触、增强的角色和配置对象。)

通信流管理器1300还要求建立目录子树600，该目录子树600可以存储其配置及其其他对象的缺省实例。缺省目录用于对企业目录中现有的人们和角色提供通信流服务。利用个性化通信流和规则，根据接收者及其企业的意思，增强这些人和角色。

媒体接触对象的缺省实例使用还可以被规定其自己的媒体接触对象的用户使用的替换功能。媒体接触对象内的地址字段可以在预定接收者的LDAP目录条目中利用角括号规定属性名称。如果存在属性值，则根据检索的对象，属性值可以代替地址字段内角括号中的属性名称。例如，利用描述预定接收者Joann的inetOrgPerson对象中的“mobile”(移动)值，<mobile>填充媒体接触对象地址字段。更复杂的替换技术也是可能的，而且它们属于本发明范围。

除了媒体接触对象的缺省实例之外，通信流管理器1300还建立缺省命名通信流表达式及缺省通信流规则。在典型的通知与响应系统100中，缺省就是将每个请求发送到接收者电子邮件帐户和web入口：“email races web”。为了适应此需要，企业可以改变所有缺省，而且建立其个人通信流表达式和通信流规则的用户可以使用给缺省对象。

条目的整个可识别名可能繁琐而且没有直观性。因此，通信流管理器1300对短名称采用试探搜索以定位它需要的对象。通过使可识别名包括在通信流表达式的角括号内，例如，<uid＝joann，ou＝people，o＝research.avaya.com>，规定对象的整个可识别名。在该例子中仅使用了该短名字。

在遇到名字时，通信流管理器1300搜索用于适当存储关于人、角色、命名通信流或个人命名上下文的目录子树，例如610、620。通过将该短名称与子树条目的有关可识别名进行比较，通信流管理器1300进行搜索。如果发现不匹配，则通信流管理器1300搜索其缺省目录，然后返回错误。

即使外部组织还未安装通信流管理器，通过本地通信流管理器1300，仍可以接触企业的其他部门或其他企业。如果外部组织具有LDAP目录500，则可以以两种方式将它包含到通信流管理器1300的名称空间。首先，“智能转荐(smart referral)”或其他机制可以连接到外部目录用于进行响应，它用于将外部目录包含到本地目录。在这种情况下，每当缺省或个人通信流信息不可用时，就可以将本地目录的通信流缺省应用于外部目录。其次，adv_search基元允许请求者描述和使用外部目录的接触信息。在需要缺省的所有情况下，使用本地缺省，除非外部目录内用于存储通信流管理器1300的缺省和配置的目录子树与建议的通信流管理器1300常规匹配。因为此原因，建议LDAP目录支持通信流管理器1300的建议子树名。在典型通知与响应系统100中，该名字是：

<ou＝Xui Server，o＝domain-name-of-server>

请求者有时具有他们希望接触的、不在该目录中的个人的地址薄。有时，请求者强烈喜好通过诸如电话的特定媒体类型接触特定个人。在这些情况下，请求者可以在目录中对请求者个人命名上下文中的个人建立个人命名上下文。另一个人的每个个人命名上下文均包括该人的inetOrgPerson条目，因此，该子树内的通信流规则、媒体接触以及命名通信流的根均在inetOrgPerson条目。然后，请求者在他或她的请求的通信流中，对这些接收者中的每个接收者规定完整可识别名。

通信流管理器1300将对接收者使用请求者110规定的通信流。增强该系统可以扩展用于搜索缺省的算法，以便首先在请求者的树上查找短名称，然后通过目录的人与角色子树查找短名称，最后在目录的缺省子树内查找短名称。这些技术与接收者对他们的喜好所做的说明矛盾，因此它们应该仅用于未出现在目录中的接收者，或者仅用于与接收者的喜好无关或者不需要遵守接收者的喜好的应用。

通信流基元

如上所述，通信流表达式规定将接收请求的接收者以及接收者将如何、何时以及何地接收该请求。通过确定成功测试结果的逻辑组合，包括在通信流表达式中的基元规定是同时还是顺序接触接收者，以及何时应该终止执行子表达式。图8是指出一组典型通信流表达式基元的采样表。图9A至9E示出图8所示各种基元的真值表。在图9A至9E中，“F”表示假响应，“T”表示真响应，“X”表示不确定响应。图9A至9E的左列示出用于响应的第一操作数，最上一行示出用于响应的第二操作数(对于单个操作数“not”基元之外的所有基元)。T、X或F上的“b”下标表示必须评估两个操作数以获得所示的值。基元使请求流指向接收者。更具体地说，基元将并行或顺序通信的方向与对与接收者的通信状态如何影响通信流的进行评估组合在一起。其他基元控制何时进行接触，或者如何根据目录中的对象列表建立通信流。

当然，可以将基元分组为下面的并行/顺序对：“and/then”、“or/else”、“races/delegates”以及“votes/polls”。并行与顺序基元在如何评估操作数方面不同。在并行基元中，并行接触每个接收者。在不再需要确定基元的真值时，取消未完成的请求。在顺序基元中，以接收者出现的顺序，对每个接收者发出请求。在接收者响应时，如果需要，将请求发送到下一个接收者以确定该基元的真值。每个基元被评估为真、假或不确定，取决于与接收者的成功通信。

And/Then

“and”(与)基元规定并行接触两个接收者，而且在两个接收者成功响应时，通信流成功(评估为真)。如果对接收者之一的请求失败，则“and”基元评估为假，而且如果可能，取消对其他接收者的请求。在所有其他情况下，“and”基元评估为“不确定”。图9A示出“and”的真值表，其中用于响应的第一操作数的值位于每行的左侧，而用于响应的第二操作数的值位于每列的顶部。

“then”(则)基元是“and”的顺序形式。换句话说，以接收者出现的顺序，一次接触一个接收者，而仅在第一接收者成功响应时，才接触第二接收者。在第一操作数返回不确定而且第二操作数可能返回假时，图9B所示的“then”基元的真值表与“and”基元的真值表不同。对于“then”基元而且在“then”基元的真值保持不确定的情况下，不评估第二操作数，而对于“and”基元，评估第二操作数，而且该基元返回假。对“then”基元进行这种选择以提供更自然的语义解释。

Or/Else

“or”(或)基元规定并行接触两个接收者，而且如果至少一个接收者成功响应，则该通信流成功(评估为真)。如果两个接收者均未响应，则该基元评估为假。在所有其他情况下，该基元评估为不确定。图9C示出“or”基元的真值表。

“else”(否则)基元是“or”基元的顺序形式，因此仅在第一响应不成功时，才接触第二接收者。“else”基元的真值表与图9C所示的“or”基元的真值表相同。对于“else”基元，如果第一操作数评估为不确定或假，则仅评估第二操作数。提供“else”运算符以确定其中仅在第一接收者说“否”或不能响应(不确定)时，接触第二接收者的情况。

Races/Delegates

“and/then”、“or/else”基元均集中在接触足够多的接收者以确定通信流表达式的成功或失败。有时，接收许多可能响应中的第一个响应也有用。利用现有基元，这是不可能的，因为它们不可能实现或执行成功前计数表决。并行基元“races”(跟随)的成功或失败，取决于用于响应的其操作数中的第一个操作数的状态。如果第一响应者成功，则“races”基元成功。如果第一响应者失败，则“races”基元失败。如果可能，就取消第二响应者的请求。例如，

cell races office races Emial races Web

的成功或失败，取决于通过下面任何一种媒体接触：蜂窝电话、办公室电话、电子邮件或web入口从接收者接收的第一响应。

与在此说明的其他基元不同，“races”基元对根据操作数的成功响应或失败响应提供同等权重。“and/then”基元立即响应操作数的失败，但是在返回成功之前，等待根据两个操作数的结果。“or/else”基元立即响应操作数的成功，但是在返回失败之前，等待两个操作数。“races”基元立即响应根据操作数的第一响应，并且返回该操作数的结果。正如在上面的例子中说明的那样，对通过多个装置接触个人并使该个人仅通过这些装置之一成功或失败应答该请求特别有用。其他基元不能规定“races”基元。图9D示出RACES的真值表。

“delegates”基元是“races”基元的顺序形式。“delegates”基元的真值表与“races”基元的真值表相同。如果左边的操作数返回通知失败(不确定)，则“delegates”基元仅评估右边的操作数。与“races”类似，其他基元不能规定“delegates”基元。

回到上面讨论的例子，Joann可以将她的喜好表示为：

cell delegates office delegates Jerry

而请求发生器规定：

(Joann then Tom)or(Joann else Priya)

如果Joann不能响应，则仅Jerry响应。如果在Joann不在时，Joann或Jerry说“是”，则仅接触Tom。如果Joann和Jerry均不响应，或均说“否”，则接触Priya。

通过多个同时操作装置接触一个人的需要激发“races”基元。例如，接收者可以规定应该将通知发送到她的蜂窝电话和办公室电话。为了能够规定该接收者是否通过她的办公室电话响应，所以无论该响应是成功还是失败，该响应均应该应用于未决接触蜂窝电话。

“and”和“or”基元不满足该要求。“delegate”基元确定例如其中仅在第一接收者未响应，或者在接触接收者之前，顺序搜索一系列装置表时，接触第二接收者的情况。

如上所述，“delegates”基元允许企业提供升级的个性化请求传送。例如，根据与客户的关系史，收款单上的企业可以对每个客户提供个性化通信流，如下所述：

信用良好客户：web delegates email delegates sms delegateshomephone

信用糟糕客户：homephone delegates officephone deletates cell

因此，客户不能响应每个请求，该请求被升级为下一种接触方法。

Votes/Polls

可以对接收者的各表通用化顺序通信流基元和并行通信流基元。“and/or”基元的并行和顺序形式是允许一系列接收者并行或顺序表决的两个更通用基元的特例。例如，成功的“and”基元是由两个接收者进行的表决，其中100％表决是，而成功的“or”基元是由两个接收者进行的表决，其中至少50％表决是。

如果达到计数m或成功响应百分比n％，则“votes”(表决)基元并行接触一系列数c个(多个)接收者，并返回成功(真)。因此，如果存在c-m+1个假响应，则失败。每个接收者可以是通信流表达式，而计数和百分比表示为了成功必须对“votes”基元接收的成功次数。例如，

{Tom，Joann，Jerry}votes 50％

并行接触Tom，Joann和Jerry。如果至少两个响应成功，则“votes”基元导致成功。在足够数量的接收者为了避免达到规定的计数或百分比而返回假响应时，“votes”基元失败(返回假)。在其他情况下，如果不能成功，则“votes”基元导致不确定。在上面的例子中，如果Tom、Joann和Jerry中至少两人响应失败，则“votes”基元才导致失败。相反，真、假以及不确定导致不确定的真值。

请注意，可以根据基元中的计数和百分比，计算直接返回真需要的真“votes”的数量。根据此，容易计算返回假需要的假“votes”的数量(总计数+1-真数量)，容易计算返回不确定(总计数+1-真数量)需要的非真“votes”的数量(假或不确定，其中至少一个是不确定)。“polls”基元是“votes”基元的顺序形式。

“votes”基元可以有利地用于例如销售或分销有限数量的商品。例如，具有500台给定商品和5000个可能客户的公司可以给定下面的通信流：

{customer1，customer2，...，customer5000}votes 500

在客户订购了500台(假定每个客户仅订购一台)时，该请求完成。为了说明其中每个客户可以订购一台以上的例子，请参考以下对测试响应状态基元的说明。

“poll”(轮询)基元可以有利地用于例如满足紧急劳动力需要。例如，明天上午之前从顺序表中查找五(5)个替换老师的学校可以给定下面的通信流：

{teacher1，teacher2，...，teacherN}polls5

如上所述，在5个替换老师同意教书时，该请求完成。

由于通信流表达式不是表，所以将表达式变换为“votes”和“polls”基元要求的表格有用。特别是，接收者喜好与角色数据库500内的命名通信流自然具有表结构。在括号内的各项之外的通信流表达式作为其第一操作数出现时，对“votes”和“polls”基元支持自动变换。对仅含有合取(conjunction)或仅含有析取(disjunction)的通信流表达式进行自动变换。如果表达式仅含有“and”和“then”基元，则将该表达式变换为其一系列合取式。如果表达式仅含有“or”和“else”基元，则将该表达式变换为一系列析取式。回到上面的例子，实际上，

Reviewers votes 2

是表达式：

(Chris and Jerry and Benji and Jenny)votes 2

自动将析取变换为表{Chris，Jerry，Benji，Jenny}。尽管可以详细规定将任何表达式变换为表，但是不清楚这种变换是必要的、清楚的或希望的。下面说明的搜索基元将表变换为表达式。

通用化“races”和“delegates”基元

可以对接收者的各表通用化“races”和“delegates”基元。通用化“races”被称为gen_races，该通用化过程接收接收者列表、用于收集的响应数量以及用于根据接收的响应确定基元的成功或失败的判定算法。例如，gen_races的一种使用是接收所收到的第N个响应的值。这相当于从第100个主叫用户接收响应的无线电通话显示模型。在另一个例子中，gen_races收集5个响应中的3个响应，并返回3个响应中的大部分响应。请注意，该结果不同于：

{A，B，C，D，E}votes 2

它等待两个成功。Gen_delegates是通用化的“delegates”基元。除了在满足该基元之前，Geh_delegates顺序接触接收者之外，Gen_delegates与gen_races相同。

实现顺序/并行基元

在典型实施例中，采用简单计数算法实现顺序和并行基元。利用返回真所需的真响应的数量和返回假所需的假响应的数量，描述每个基元。还利用返回不确定所需的不确定响应的最少数量和在返回不确定之前必须接收的响应的总数量描述它。图10概括了每个基元的计数，其中C是列在“votes/polls”中的所有接收者的计数，而X是“votes/polls”百分比或计数要求的真响应的数量。并行和顺序基元对在每类接收的响应的数量进行计数。每当满足状态返回之一的要求时，该基元取消未完成的请求并返回正确状态。

状态解释和时间基元

正如以上结合图4所述，对接收者120的成功请求包括通知成功和响应成功。在成功接触接收者时，通知成功。根据缺省，在接收者满足对请求和响应系统API成功的定义的方式响应时，响应成功。对于通知与响应系统100的web API，响应成功的缺省为对web窗体应答而不包括提交按钮的“假”值或“否”值。提交按钮的“假”值或“否”值是对响应失败的缺省响应。

某些应用可以要求响应成功的应用专用定义。例如，如果一项消费报告被几个经理顺序批准，则可以将成功定义为对请求的响应为report_status＝“approved”。

测试响应状态基元允许应用根据响应提供响应成功规范作为属性值对的比较逻辑表达式。在其响应将被测试的接收者之后的问号之间规定逻辑表达式。比较可以包括等同、不等同、范围以及正常表达式匹配。在其中对于通信流内的所有接收者，成功规范均相同，但与系统缺省却不同的情况下，可以提供全请求缺省。

下面的例子规定不使用缺省功能情况下的响应成功状态：

DepartmentHead？report_status＝“approved”？then Director？report_status＝“approved”？then VP？report_status＝“approved”？

在将测试响应状态基元应用于含有多个接收者的表达式时，它可以应用于更复杂表达式中的每个接收者。例如，还可以将上述表达式书写为：

(DepartmentHead then Director then VP)？report_status＝“approved”？

成功规范可以对迄今为止的所有响应的响应属性进行聚合和其他高级处理，然后，测试成功或失败的结果。

如上所述，“votes”基元可以用于销售或分销有限数量的商品，但是假定每个客户仅购买一台。下面的成功表达式允许每个客户订购不止一台，而且在至少销售100台时，终止该通知：

(Sue or Fred or...or Sam)？sum(number_sold)≥100？

销售100台之后，取消对其他接收者的未完成的请求。在利用通知与响应系统可用的数据使通知报价个性化时，先前响应的结果可以用于对仍可以销售的这些商品(100-sum(number_sold))向接收者报价。如果两个接收者试图购买剩余商品，则第一个接收者将成功，而第二个接收者将被告知请求被取消(即，报价被撤回)，因为被另一个接收者完成。

between/before/after

除了测试响应状态的基元，“between”(之间)、“before”(之前)和“after”(之后)基元规定用于传送通知和从接收者收集响应的时间约束。时间约束可以如在“after”基元中规定开始时间，或如在“before”基元中规定结束时间，或者如在“between”基元中规定它们二者。还可以将“between x-y”表示为“after xbefore y”。在对同一个接收者应用多个时间约束时，从左到右评估时间约束。第一时间约束建立有效开始之间和结束时间。后续时间约束可以使这些时间精确。相对时间约束可以向前或先后调节时间。其他约束，例如包括用于确定间隔的开始或结束的约束可以向前移动开始之间并先后移动结束时间。换句话说，如果多个基元建立矛盾的绝对开始时间或矛盾的绝对结束时间，则通过交集约束间隔，可以有效使用在后开始时间和在先结束时间。在时间约束基元应用于含有多个接收者的表达式时，它可以应用于更复杂表达式中的每个接收者。

利用时间表达式和时域表达式规定时间约束。时间表达式代表特定时间瞬间，而时域表达式代表时域。我们首先定义时域表达式，因为这些用于书写时间表达式。时域是一个或者多个被规定为(开始时间，结束时间)的时间间隔，其中开始时间在该间隔内，而结束时间不在该间隔内。基本时域是无穷期，从理论上说，无穷期是一个从时间的开始(创造世界的时间)到时间的结束(世界末日)的间隔。创造世界的时间可以取任意开始时间(例如，Unix中的纪元，1970年1月1日的00:00.00U TC)，而以类似的方式处理世界末日。当前，自从创造世界以来以秒为分辨率规定时间。每个其他时域是一组间断的时间间隔(开始、结束)，其中间隔的开始包括在该间隔内，而间隔的结束不包括在该间隔内。

在联合、交集以及补集情况下，时域是封闭的，这意味着，对该时域的运算始终产生另一个有效时域。根据基元时域(以下定义)以及联合、交集以及补集的运算，建立时域表达式。就象可以在其他通信流表达式中命名并使用通信流表达式一样，可以在其他时域表达式中命名并使用时域表达式。

基元时域包括：

具有规定的开始时间和结束时间的间隔，例如从2002年5月13日9:00.00到2002年5月13日17:00.00。

给定的任意一天，例如2002年5月13日。

给定的任意一周，例如从2002年5月12日星期日到2002年5月18日星期六。

给定的任意一个月，例如2002年5月。

给定的任意一年，例如2002年。

一周中给定的任意一天，例如星期一(意味着创造世界与世界末日之间的所有星期一的联合)。

给定的任意一个月，例如5月(意味着创造世界与世界末日之间的所有5月的联合)。

该年中给定的任意一天，例如7月4日(意味着创造世界与世界末日之间的所有7月4日的联合)。

给定的任意时间范围，例如9:00.00-17:00.00(意味着创造世界与世界末日之间的所有日期的所有该间隔的联合)。

例如，可以将星期日以外的任何一天定义为给定天：星期一、星期二、星期三、星期四以及星期五的联合。可以将假日定义为1月1日，7月4日以及12月25日的联合。可以将营业时间定义为星期日之外的任何一天与时间范围9:00.00-17:00.00的交集。通过使它与假日的补集交集，可以使营业时间进一步精确。

时间表达式可以规定绝对时间，也可以规定根据开始时间计算的时间(例如从现在开始的4个小时)，还可以规定根据时域和开始时间计算的时间(例如，开始下一个营业日；或从现在开始的4小时的营业时间，指仅在营业时间时域内计数的、从现在开始的4个小时)。

时间表达式可以取下面的形式之一。

任何绝对时间，例如2002年5月13日17:00.00

相对时间，例如+4:00.00，指当前时间之后4个小时，或-3:00.00，指当前时间之前3个小时。

可以将时域内的下一个间隔的开始时间和结束时间，例如下一次停止营业时间规定为当前时间之后的营业时间内的间隔的下一个结束时间。更一般的说，可以计算开始时间和结束时间，例如第二次停止营业时间。

在给定时域内经过的时间，例如，如果现在是2002年5月13日16:00.00，则经过的4小时营业时间产生2002年5月14日的12:00.00。还可以从当前时间向后移，在向前移之后，这样特别有用。例如，可以对下一个假期确定时域，然后，可以将它称为下一个假期开始之前的4小时营业时间。

根据这些，可以确定更复杂的时间表达式。

例如，可以确定从每天的12:00.00到12:00.00的(空)时间间隔。取该时间间隔的下一个开始时间(结束时间)作为第二天的中午。利用与星期日之外的任何一天的交集，可以简单计算下一个营业日的中午。将它与用于计算间隔的结束时间的运算符组合在一起，可以计算下一个营业日中午之后两天的停止营业时间。

作为另一个例子，可以将西班牙的营业时间规定为时间范围9:00.00-12:00.00与14:00.00-19:00.00的联合(union)。为了确定当天的停止营业时间，可以使西班牙的营业时间与当天交集，然后确定得到的时域内的间隔的最后结束时间。

企业可以对通信流管理器确定缺省时域对象，或者每个接收者可以确定自己的个人时域对象。这种典型的一个典型用途是确定企业的营业时间。该对象含有：

时域对象的通用名称(cn)：商业

目录过滤器，该接收者使用该时域。这可以用于使该商业时域与特定公司内的人、时间区域或地理区域相关。

时间区域，用于计算有效时间。

时域内间隔的时域表达式。该时域表达式可以引用其他基本时域或命名时域。

在“before”、“after”和“between”基元内，该时域与暂时表达式运算符“end of”、“start of”、“n end of”、“n start of”(其中n是计数)，或末尾的关键字“+”(时域内的相对时间)、“-”(时域内的相对时间)一起使用，例如：

AFTER end of business

BEFORE 2 start of business

BETWEEN start of business-end of business

BEFORE business+4:00.00

AFTER end of business AFTER business-01:00.00

AFTER last end of(SpanishBusinessHours交集Today)

可以进行各种简化，以使语法更自然。例如，如果时域的名称跟在“after”(之后)后面，则可以取该时域中间隔的下一个结束时间为指定时间。对于“before”(之前)也同样，可以区该时域中间隔的下一个开始时间为指定时间。这样可以将“AFTER end ofbusiness”简化为“AFTER BUSINESS”，而将“BEFORE start ofMonday”简化为“BEFORE Monday”。这样还可以将“B ETWEEN end of 08:00.00-start of 17:00.00”简化为“BETWEEN08:00.00-17:00.00”。对现有时域使用联合、交集和补集的整个时域表达式还可以用于采用时域名称的地方。

利用两个附带条件，通信流管理器的标准缺省处理对时域名称进行解析：时域对象的通用名称以通信流中规定的名称开始，但是还可以在美元字符$之后包括其他限定，正如在“business$west-coast”中那样，并且接收者必须匹配时域对象的过滤器。如果发现几个匹配对象，则可以选择其中一个对象，如果可能是具有最专用逻辑滤波器(蕴含所有其他匹配过滤器的过滤器)的对象，或者如果那是不可能的，则任意选择一个匹配对象。通信流管理器首先利用匹配过滤器在inetOrgPerson或inetRole对象的上下文中查找给定名称的时域。如果什么也没有查到，则通信流管理器在其缺省目录中查找该时域。

短名称和目录搜索基元

在此讨论的例子说明请求者110可以利用短名称规定接收者120。正如以下在“目录缺省和试探”小节所描述的那样，接收者喜好与角色数据库500的试探搜索过程对这些短名称进行翻译。请求者110还可以在角括号内规定接收者120的整个可识别名，例如，<uid＝joann，ou＝people，o＝reseach.avaya.com>。对接收者120规定的可识别名可以对各用户不同，因为它要求他们知道LDAP名称树600的结构(参考图6)。通信流表达式还支持搜索过程，因此用户可以描述接收者喜好与角色数据库500内的一个或者多个接收者对象的属性。在用户采用搜索过程时，他们不需要知道各目录对象的可识别名。具有诸如“search(filter，pattern，op)”的格式的典型搜索基元在接收者喜好与角色数据库500中搜索匹配该规定的过滤器的人、角色或命名通信流对象。典型高级搜索基元具有诸如“adv_search(directory-server，directory-port，base，scope，filter，pattern，op)”的格式。高级搜索基元的“filter”(过滤器)、“pattern”(模式)以及“op”参数的运算与搜索基元的相同。“directory-server”(目录服务器)参数规定接收者喜好与角色数据库500的主机的域名以进行搜索，而“directory-port”(目录端口)参数规定该主机上的接收者喜好与角色数据库500服务器的端口号。在该服务器上搜索其根在基址中的可识别名的目录树。搜索范围是基址(base)(对于仅利用基址识别的对象)、一级(只用于搜索仅利用基址识别的对象的子代)，或者子树(用于搜索利用基址识别的对象的全部子树)。“directory-server”、“directory-port”、“base”或“scope”(范围)可以是“NULL”(无)，在这种情况下采用缺省。

通常，用于通信流表达式的搜索基元包括用于处理该搜索的结果的宏功能。对于记号“<dn>”，返回的每个对象分别被替换为模式，搜索基元的“pattern”参数给出该模式。然后，利用搜索基元的“op”参数给出的、用户规定的基元，例如“and”或“races”，将该对象的结果字符串连接到其他对象的结果字符串。例如，模式：

(<dn>between 5/01/01-05/08/01)delegates(<dn>between 5/08/01-05/10/01)

产生用于将在2001年5月1日之后请求一次，然后如果未收到响应则在2001年5月8日之后再请求一次通知每个接收者的字符串。如果在完成请求之前，需要每个接收者发出响应，则可以利用“and”基元连接结果字符串以产生通信流表达式。本技术领域内的普通技术人员明白，用户还可以限制搜索以便仅返回一个接收者。对搜索规定如何处理多重匹配可以防止用户在仅希望将敏感请求发送到某个个人时，无意中将该敏感请求发送到一大群人。

搜索基元可以用于例如获得专家帮助。例如，如果请求者需要从专家获得关于诸如J2EE的给定课题的信息，则请求者可以规定下面的通信流：

search(“&((objectclass＝inetOrgPerson)(expertise＝J2EEE))”，“<dn>”，OR)

作为一种选择，还可以将该通信流规定为：

expert1 or expert2...or expertN

在另一个例子中，产生网络告警，而且必须由专家解决该网络告警。请求者可以规定下面的通信流：

search(“&((objectclass＝inetOrgPerson)(expertise＝netmgr))”，“<dn>”，OR)

在一个专家满意地满足该请求时，完成这些请求。

下表从上到下列出运算符的典型先后次序。同一级的运算符从左到右相关。通常，圆括号可以改变先后次序的顺序。

运算符
	AND，THEN
OR，ELSE
	RACES，DELEGATES
NOT
	VOTES，POLLS
AFTER，BEFORE，BETWEEN

？
	SEARCH以及其他功能

请求管理器1200与通信流管理器1300的交互作用

图11至13示出请求管理器1200与通信流管理器1300之间的交互。图11是与请求有关的各实体之间的信息流的原理框图。图12A和12B一起是更详细示出图11所示请求管理器的运行过程的流程图。图13是更详细示出图11所示通信流管理器的运行过程的流程图。在典型实施例中，请求管理器1200和通信流管理器1300对在步骤1205(参考图12)和1305(参考图13)检测的各种预定异步事件分别进行处理。

如图12A所示，在步骤1210期间，请求管理器1200检测通过应用接口220从应用110接收的新请求。然后，在步骤215，在请求数据库300内，请求管理器1200对该请求建立条目，在步骤1220，将该请求的通信流表达式部分和请求标识符送到通信流管理器1300进行解析。

如图13所示，在步骤1310，通信流管理器1300检测新通信流表达式以进行处理。在需要时，在步骤1315，通信流管理器1300处理通信流表达式，利用接收者喜好与角色数据库500，继续对通信流表达式中的每个名字进行解析(resolve)，直到到达树600上的一组可执行终端节点，这样指出对给定接收者采用的媒体接触对象。请注意，利用通信流管理GUI1110，接收者120可以在接收者喜好与角色数据库500中输入并更新其喜好。

在步骤1325通信流管理器1300产生装置表以接触请求管理器1200，并将该表返回请求管理器1200，作为接触调度信息的一部分。通常，接触调度信息仅包括请求管理器1200可以立即调度的接触。例如，如果给定接收者的喜好指出在上午8点至下午5点期间只能利用电话联系接收者，则在该时间窗口有效之前，通信流管理器1300不安排电话媒体接触。

更具体地说，通信流管理器1300将接收的通信流表达式剖析为树，并例如通过利用深度优先搜索方法走查该树，开始递归处理该树上的各节点，直到到达终端节点。在每次遇到树上的终端(叶)节点时，对存储在其上的媒体接触进行处理。如果给定节点包括并行基元，则与该并行基元的操作数有关的所有节点均被处理。如果给定节点包括顺序基元，则在完成处理左侧的操作数之前，不处理右侧的操作数。

此外，在将媒体接触返回请求管理器1200之前，通信流管理器1300确定是否满足与该媒体接触(终端节点)有关的时间约束。例如，通信流管理器1300确定是否到达开始时间。如果满足所有时间约束，则媒体接触包括在返回请求管理器1200的表中。如果不满足所有时间约束，则该媒体接触不包括在返回请求管理器1200的表中，而且通信流管理器1300设置定时器，以便通信流管理器1300可以在适当时间将媒体接触附加到该表。请注意，在满足所有时间约束之前，不检索媒体接触对象。

请注意，通信流表达式的树表示可以包括以已知方式指向根节点的反向指针，从而便于识别相关时间约束。如果在该树上遇到人或角色的命名节点，则确定事先是否利用同一个所有者(规定的同一个通信流)接触该名称。如果同一个所有者事先接触过该名称，则不进行第二次接触尝试。相反，根据先前接触传送状态信息。

如图12A所示，在步骤1225，请求管理器1200检测接收的接触调度信息，并在步骤1230，利用指出的媒体接触方式，尝试接触接触调度信息内指出的每个接收者，下面将在“媒体专用接口”小节中进行说明。

如果在步骤1240(参考图12B)，请求管理器1200检测一个或者多个响应或消息失效事件，则为了保持归档文件或记录，在步骤1245，例如，可以在响应数据库1150内选择性地建立具有相应请求标识符的响应记录或失效记录。在其中将每个单独响应送到请求的应用110的实施例中，在步骤1248，将接收的响应转发到相应应用110。在步骤1250，将响应或失效状态转发到通信流管理器1300做进一步处理。

在步骤1330，通信流管理器1300利用请求标识符检测接收的响应或失效状态，并在步骤1335，利用请求标识符检索正确的通信流表达式。在在步骤1330检测响应或失效状态时，在步骤1335，通信流管理器还更新通信流表达式的树表示，以反映媒体接触的状态。然后，通过确定现在确定的任何一个上级操作数的状态，通信流管理器1300将该状态上传到树根，因此，利用媒体接触状态，该操作数完成。在操作数完成时，将该操作数的未完成媒体接触列到接触表中以便被取消。适当时，在步骤1350或1320之后，将该表返回请求管理器1200。如果状态的传播不能使该通信流彻底完成(在设置该树上的最高级操作数的完成状态时出现)，则在步骤1315使处理过程继续进行。如果整个通信流完成，则在步骤1350使处理过程继续进行。

利用通信流表达式，通信流管理器1300确定是否需要附加通信，或者该通信是否完成。如果在步骤1340确定附加通信是必要的，则程序控制返回步骤1315以产生接触调度信息，并将该接触调度信息进一步送到请求管理器1200。然而，如果在步骤1340确定通信流表达式完成，则在步骤1350，通信流管理器1300将完成状态指示转发到请求管理器1200。

在其中将校验的响应送到请求的应用110的实施例中，在步骤1260，一旦请求管理器1200从通信流管理器1300收到完成状态指示，则在步骤1265，请求管理器1200对响应进行校验并将它们返回请求的应用110指出的最终目的地地址。在步骤1270，完成状态消息被送到相应应用。

媒体专用接口

在典型实现过程中，媒体专用接口是一个抽象MediaContact类的所有子类，该抽象MediaContact类要求每个子类实现两种方法，一种方法用于启动接触，另一种方法用于取消它。然而，尽管仅要求两种方法，但是子类在非常简单与非常复杂之间变化，在某种程度上取决于通知与响应系统100与终点之间要传送的信息(ingelligence)分布。通常，对于每个媒体接触，利用如下所述的媒体专用变码器之一对该请求进行变码，以产生适于要尝试的特定接触的编码。协议专用通信接口对将编码请求实际传送到每个接收者进行处理。

可以将类集看作装置抽象(abstraction)层。这种装置抽象层对其他通知与响应系统100类隐藏了各种装置的所有复杂性，而仅显露几种简单方法，以便例示、启动合取消通知以及一些对所有装置相同的参数设置与获取方法。以下将说明多种典型MediaContact子类。

WebContact

WebContact类使接收者登录到web入口以查看未决的、完成的以及取消的各请求的表，WebContact类将含有请求者的名称、请求时间、主题以及到请求URL的超级链接的项简单插入未决表中。取消过程刚好是将该项从未决表转移到取消表中。通过点击要求的通知，然后完成显示的窗体，“接收者”进行响应。

PhoneContact

PhoneContact类必须启动电话呼叫，而不是等到接收者呼叫它或接触它。此外，PhoneContact类可以采用语音可扩充标记语言(VoiceXML)系统，该语音可扩充标记语言(VoiceXML)系统产生VXML底稿(或者另一种文本表示)的声频再现。通过规定请求标识符、媒体接触标识符、要拨号的电话号码以及将返回目标接收者的VXML底稿的服务小程序的URL，利用TCP，PhoneContact类将消息送到自动电话拨号器。对于取消，如果还未安排，则PhoneContact仅发送指出取消电话呼叫的消息。

自动电话拨号器控制程序对各电话呼叫请求进行排队，并在有可用资源时，以FIFO顺序执行它们。

EmailContact

典型通知与响应系统100允许3种不同类型的电子邮件：明文、HTML以及嵌入式动态HTML。在第一种情况下，许多接收者有时使用唯文本(text-only)电子邮件客户机。它不仅包括文本编辑器emacs和某些基于web的客户机，而且包括无线电子邮件客户机，例如，Blackberry^TM和Palm^TM市售的无线电子邮件客户机。在这种情况下，通过在目录中指出电子邮件应该是唯文本的，说明必须提供哪种客户机，通知与响应系统100建立通常仅含有请求者的名称、请求主题以及指向通知消息的URL的简单电子邮件消息。在典型实现过程中，请求的应用本身建立文本消息，而且还插入语音入口的电话号码，对于声频接入可以呼叫该电话号码。

对于不能处理嵌入的帧或层的HMTL功能电子邮件客户机，EmailContact建立HTML页面，该HTML页面也描述通知，但是这次含有到通知消息的超级链接。对于能够处理嵌入的帧和层的电子邮件客户机，EmailContact建立用于嵌入通知的消息，因此在客户机再现该消息时，将插入该内容。

EmailContact的最后一个复杂问题是，必需解释不能发送的电子邮件消息。这是通过提供一种本身规定程序处理发送到通知与响应系统100的任意一个消息的主要方法实现的。然后，该方法尝试解释返回的邮件，以确定它是否指出传送尝试失败或诸如此类的其他情况。如果如此，则将接触失败通知通知与响应系统100。通知与响应系统100可以任选读出接收的请求并解释它们。即使没有发送应答，这样仍可以确定通知是成功的，而且对于某些应用，这是必要的。

SMSContact

利用包括Sprint^TM、Verizon^TM以及AT&T^TM的许多蜂窝电话提供商提供的短消息传送业务，SMSContact处理通知。SMSContact对象可以对web站点设置提供商专用HTTP POST或GET以发送消息。尽管通过将电子邮件发送到业务提供商，可以做大致同样的事情，但是POST提供更多的控制。在提供商的web接口逐渐形成时，POST承担了软件变化的费用。通知与响应系统100可以有选择地解释确认电子邮件，一旦消息被传送，大多数业务提供商发出该确认电子邮件。除了在SMS消息被成功发送时进行识别外，该电子邮件允许确定业务提供商的web接口是否发生变化以致该系统可以后退到使用电子邮件SMS传送，直到SMSContact软件被更新。

FaxContact

例如，利用Avaya公司的AUDIX系统的传真能力，通知与响应系统100可以提供类，以将通知发送到传真机。该类将HTML或文本页面变换为TIFF图像文件，然后，产生请求以通过传真将该通信传送到目的地。该类还包括用于提供关于未决传真的信息并对该未决传真提供某些控制的简单状态与管理服务小程序。

AudixVoiceContact

AudixVoiceContact对象用于将通知的文本版本传送到接收者的语音信箱。典型实现过程是利用IBM公司推出的ViaVoice^TM产品将消息再现为声频文件，然后，利用与FaxContact基本相同的机制将该声频文件发送到AUDIX服务器。

SIPContact

SIPContact类将通知与响应系统100连接到SIP(对话启动协议)允许的终点。例如，M.Handley等人在“SIP：Session InitiationProtocol”RFC1543，March 1999中对对话启动协议(SIP)进行了描述。SIP是因特网工程部(IETF)为了建立并控制各种通信对话确定的一个较新协议。

为此，SIPContact类取决于从通知与响应系统100接收消息、被称为SIP执行环境(SEE)的部件。该消息包括接收者的SIP地址、媒体接触标识符、请求标识符以及用于该请求的可用媒体类型和人类语言的表。SEE取SIP地址，并根据SIP协议，通过该地址，发出“邀请”，以与该接收者建立接触。然后，SEE从接收者装置接收指出接收者优选媒体和人类语言的OK消息。如下所述，SEE执行XFS请求，提供将媒体接触标识符、请求标识符以及以上提供的可用媒体类型和人类语言的表中用于该请求的优选媒体类型和人类语言。根据接收者的SIP喜好，XFC请求返回用于通知接收者的正确格式化内容。通过使SEE对每个要求的格式呼叫一次XFS，这种技术支持喜欢接收多种格式的装置(某些装置具有屏幕和声频)。

在典型实现过程中，SEE可以将即可消息或呼叫发送到Microsoft XP^TM；呼叫其呼叫控制协议被变更为SIP(代替H.323)的(利用SIP协议支持增强的MultiVantage^TM呼叫处理软件版本)SIP允许的Avaya 4624^TM IP电话、数字电话和模拟电话；将即刻文本消息发送到具有红外能力而且其呼叫控制协议被变更为SIP(代替H.323)的SIP允许Avaya 4624^TM IP电话；以及在其呼叫控制协议被替换为SIP(代替H.323)的实验SIP允许Avaya 4630^TM IP屏幕电话上弹出web页面。

SIP以多种方式与本发明的通知与响应系统100紧密结合。特别是，SIP提供了一种接收者可以以这样的方式在一个服务器上建立他或她的接触喜好，以致可以将这些喜好应用于接触他或她的任何一个人的机制。尽管SIP允许的接收者可以通过SIP表达其喜好，但是传统接收者仍可以在通知与响应系统100内确定单独通信流。可以预料，接收者利用SIP机制控制如何以及何时接收通知，而通知与响应系统100内的通信流确定如何以及何时将通知送到非SIP终点以及SIP规定的优选终点。即，就在SIP和统一消息传送对如何接收消息提供控制时，通知与响应系统100对企业如何发出这些消息提供控制。请注意，根据以上披露的内容，利用通信流表达式和通信流规则功能块，可以增强SIP对如何接收消息的控制。

SIPContact类还展示了这种体系结构的通知与响应系统100的一些优点。特别是，通过调用具有用于识别请求和接收者以及被接触的装置的两个变元(argument)、被称为XFS的窗体服务小程序，利用web或电话浏览器或MediaContact，可以检索通知与响应系统100内的通知消息的内容：

http：//xui/XFS？Rid＝xui-1234-1&Cid＝1

其中Rid是请求id，而cid是媒体接触id。它们两个一起足以识别该接收者。XFC仅利用请求管理器1200检索正确请求，这又用于获得通知消息的URL。然后，检索该消息，重写该消息，以改变该响应的地址并个性化该消息，然后，将该消息转发到浏览器或其他目的地。

为了支持多种语言和媒体类型，可以修改XFS服务小程序以接收两个附加参数，从而规定要求的语言和MIME类型。例如，更一般版本的XFS允许检索下面的特定语言和格式类型：

http：//xui/XFS？Rid＝xui-1234-1&Cid＝1&Ctype＝

text/plain&Language＝ENU，

它规定要求英文、明文版本的请求“xui-1234-1”。

典型的通知与响应系统100以两种方式将通知同时传送到SIP允许的Avaya屏幕电话，作为通过电话的语音消息和弹出在屏幕上的web页面。这是通过使屏幕电话规定SEE即可以处理web的弹出又可以处理声频连接实现的。然后，SEE对XFS发出两个呼叫，第一个呼叫用于检索HTML页面，第二个呼叫用于检索VXML页面：

http：//xui/XFS？Rid＝xui-1234-1&Cid＝1&Ctype＝

text/html&Language＝ENU

http：//xui/XFS？Rid＝xui-1234-1&Cid＝1&Ctype＝

text/vxml&Language＝ENU

典型实施例

如上所述，通知与响应系统100允许应用110(请求者)提出问题、规定要求的响应类型以及通过电子邮件从接收者接收一组校验的响应。图14示出允许应用110规定团队会议请求参数的web窗体1400。在图14所示的例子中，Joann正为了安排会议将请求发送到“YangQian”和“Petsche”。如果这些接收者同意会议时间和地点，则将该请求转发到其经理(cmk)以检查他是否可以参加会议。适当时，通过不同媒体接触，将产生的请求发送到指出的接收者。该请求包括用于回答该请求的是按钮和否按钮。图15示出该请求的编译结果。如图15所示，Petsche可以参加会议，但是YangQian不能参加会议，因此未接触他们的经理。

图16示出另一个例子，请求者在4小时期间内对优选客户提供新公司IPO的整笔拨款的股份。对命名通信流PreferredCustomer施加时间约束。PreferredCustomer被翻译为各接收者的并行合取。请求者将请求中的一系列选项送到他/她的最佳客户。图17示出命名通信流PreferredCustomer确定的、已经规定了喜好电子邮件的每个接收者接收的该请求的电子邮件版本。在所有接收者响应时或者在所提供的4小时期满时，就返回校验的响应。如果接收者未能在4小时期间内做出响应，此后尝试查看或响应该请求，则显示适当消息，而且既不恳求应答，也不接受应答。

本发明的另一个典型例子称为“反向911”，它使通知与响应系统100提供紧急911响应。例如，可以确定通信流表达式和规则以在学校发生紧急情况时，通知父母。在这种情况下，在发生需要接触学校中每个孩子的父母或监护人的紧急情况时，学校难以安排所需资源。本发明的反向911系统提供接触父母的自动技术，而且还可以提供重要的安全措施，以防止不正确使用或诈骗使用，从而将错误告警降低到最少。反向911系统要求父母在业务提供商那里登记他们在紧急情况时被喜好的接触方式。一旦被激活，学校就可以利用web接口或电子邮件开始并行接触所有父母。通知可以可选择包括父母确认收到通知的按钮。此外，学校可以规定一个请求者使用在此描述的技术的批准程序，在将通知发送到父母之前，必须满足该批准程序，而且学校还可以利用其他安全特性增强其安全性(例如，保密登录和访问控制以校验请求者)。这样，本发明可以提供“圈内中人”的安全性。

根据以上披露的内容，本技术领域内的普通技术人员明白，在其他变换例中也可以采用同样的反向911，例如，在出现危机时，支持红十字会或政府机构发现和调度献血者，或者关于特定危险，例如化学物质泄漏，接触附近居民。

在本发明的又一个典型实施例中，该实施例被称为“自适应调度”，通知与响应系统100可以将安排变更通知指定接收者。例如，如果诸如火车、飞机的大量运输方式发生延误，或者如果通勤者在他或她去开会的路上发生交通拥堵，可以配置通知与响应系统100以将安排变更通知有关各方，协调修改利益各方的安排。例如，在此描述的日程代理技术允许自动进行这种安排修改。乘客可以规定通信流规则，例如，如果收到标题＝“Flight Information^*”的电子邮件消息，则可以启动该通信流规则。该通信流规则可以提供关于如果发生延误接触何人的信息，例如，豪华轿车服务、同事或配偶。通知可以提供专门给受影响接收者的信息。例如，给豪华轿车服务的通知可以请求改变接乘客的时间，给同事的通知可以请求重新安排会议(例如，利用日程代理)，或者可以请求在延误乘客缺席时请同事参加会议(利用委托特性)。

在本技术领域内众所周知，可以将在此说明的方法和设备作为制造商品分销，该商品本身包括具有在其上实现的计算机可读代码装置(means)的计算机可读介质。结合计算机系统可以运行计算机可读程序代码装置，以执行实现该方法的所有步骤或一些步骤，或建立在此描述的设备。计算机可读介质可以是可记录介质(例如，软盘、硬盘，压缩光盘或存储卡)，也可以是传输介质(例如，包括光纤、环球网、电缆或采用时分多址、码分多址的无线信道或其他无线频道)。可以使用可以存储适合与计算机系统一起使用的信息的任何已知的或开发的介质。计算机可读代码装置是使计算机读取指令和数据的任何一种机制，例如磁性介质上的磁性变化或压缩光盘上的高度变化。

在此描述的计算机系统和服务器分别含有存储器，该存储器配置有关处理器以执行在此披露的方法、步骤以及功能。存储器可以是分布式的，也可以在本地，处理器可以是分布式的，也可以是单独的。可以将存储器实现为电、磁或光存储器，或者这些或其他存储装置的组合。此外，应该广泛地理解术语“存储器”，它足以包括能够被读出或写入可寻址空间内的地址的任何信息，相关处理器可以对该可寻址空间进行访问。根据该定义，网络上的信息也在存储器内，因为相关处理器可以从网络上检索该信息。

显然，在此说明和描述的各实施例和各变换例，仅用于说明本发明原理，而且在本发明实质范围内，本技术领域内的熟练技术人员可以对它们进行各种修改。

Claims (70)

1.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的方法，所述方法包括：

从所述至少一个接收者接收响应；以及

根据所述响应，在所述通信流中，选择至少一个通路。

2.根据权利要求1所述的方法，该方法进一步包括修改所述消息内的应答到地址以确保在要求的目的地收到所述响应的步骤。

3.根据权利要求2所述的方法，其中所述修改的应答到地址使中间人作为所述发送者的软件代理。

4.根据权利要求2所述的方法，其中所述修改的应答到地址使中间人对所述发送者提供响应处理服务。

5.根据权利要求1所述的方法，其中所述选择步骤确定与一个或者多个附加接收者的后续通信。

6.根据权利要求1所述的方法，其中所述选择步骤聚集接收的响应，并评估是否满足预定的消息完成判据。

7.根据权利要求1所述的方法，其中所述选择步骤确定将使响应信息返回所述发送者的完成状态。

8.根据权利要求7所述的方法，其中以所述发送者规定的格式，将所述响应信息送到所述发送者。

9.根据权利要求1所述的方法，其中根据所述至少一个接收者规定的喜好信息，将所述消息送到所述相应至少一个接收者。

10.根据权利要求1所述的方法，其中基本上在将所述消息送到所述至少一个接收者的同时，获得所述消息的内容。

11.根据权利要求1所述的方法，该方法进一步包括评估所述通信流的步骤，其中所述通信流引用所述至少一个接收者确定的至少一个通信流规则，所述通信流规则至少规定所述接收者的一个喜好。

12.根据权利要求1所述的方法，其中所述通信流引用与所述至少一个接收者有关的企业规定的、所述至少一个接收者的至少一个喜好。

13.根据权利要求11所述的方法，其中所述通信流规则至少包括一个时间条件。

14.根据权利要求11所述的方法，其中所述通信流规则至少包括一个媒体喜好。

15.根据权利要求11所述的方法，其中所述通信流规则至少包括一种人类语言喜好。

16.根据权利要求11所述的方法，其中基本上在将所述消息送到所述至少一个接收者的同时，评估所述通信流规则。

17.根据权利要求11所述的方法，其中所述通信流引用所述至少一个接收者的至少一个媒体喜好以接收所述消息，其中将所述至少一个媒体喜好存储在中心位置。

18.根据权利要求11所述的方法，其中所述通信流控制SIP代理中的呼叫处理过程。

19.根据权利要求18所述的方法，其中所述SIP代理评估输入的SIP INVITE消息，并对所述至少一个接收者选择正确的呼叫路由选择规则。

20.一种根据通信流、将消息从发送者送到至少一个接收者的方法，所述方法包括：

从所述发送者接收所述消息；

评估所述通信流，其中所述通信流至少规定所述发送者的一个喜好，以传送所述消息；以及

根据所述发送者的所述喜好，处理所述消息。

21.根据权利要求20所述的方法，该方法进一步包括以所述发送者规定的格式，将响应信息送到所述发送者的步骤。

22.根据权利要求20所述的方法，其中基本在将所述消息送到所述至少一个接收者的同时，获得所述消息的内容。

23.根据权利要求20所述的方法，该方法进一步包括评估所述通信流的步骤，其中所述通信流引用所述至少一个接收者确定的至少一个通信流规则，所述通信流规则至少规定所述接收者的一个喜好。

24.根据权利要求20所述的方法，其中所述通信流引用与所述至少一个接收者有关的企业规定的、所述至少一个接收者的至少一个喜好。

25.根据权利要求23所述的方法，其中所述通信流规则至少包括一个时间条件。

26.根据权利要求23所述的方法，其中所述通信流规则至少包括一个媒体喜好。

27.根据权利要求23所述的方法，其中所述通信流规则至少包括一种人类语言喜好。

28.根据权利要求23所述的方法，其中基本在将所述消息送到所述至少一个接收者的同时，评估所述通信流规则。

29.根据权利要求23所述的方法，其中所述通信流引用所述至少一个接收者的至少一个媒体喜好以接收所述消息，其中将所述至少一个媒体喜好存储在中心位置。

30.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的方法，所述方法包括：

从所述发送者接收所述消息；

评估所述通信流，其中利用至少含有一个用于指出应该如何处理所述消息的基元关键字的通信流表达式，控制所述通信流；以及

根据所述通信流表达式，处理所述消息。

31.根据权利要求30所述的方法，其中所述基元关键字指出应该同时接触两个规定的操作数A和B，而且当且仅当A和B均成功响应时，通信流表达式才成功。

32.根据权利要求30所述的方法，其中所述基元关键字指出，对于两个规定的操作数A和B，只有在A操作数成功时，才应该接触B，而且当且仅当A和B均成功响应时，通信流表达式才成功。

33.根据权利要求30所述的方法，其中所述基元关键字指出应该同时接触两个规定的操作数A和B，而且只要当A或B之一成功响应，通信流表达式就成功。

34.根据权利要求30所述的方法，其中所述基元关键字指出，对于两个规定的操作数A和B，只有在对A操作数的尝试失败时，才应该接触B，而且如果A或B之一成功响应，通信流表达式就成功。

35.根据权利要求30所述的方法，其中所述基元关键字指出应该同时接触两个规定的操作数A和B，而且通信流表达式具有第一接触的值以进行响应。

36.根据权利要求30所述的方法，其中所述基元关键字指出，对于两个规定的操作数A和B，只有在对A操作数的尝试失败时，才应该接触B，而且通信流表达式具有第一非不确定响应的值。

37.根据权利要求30所述的方法，其中所述基元关键字指出应该同时接触各接收者，而且如果收到成功响应的特定阈值，则通信流表达式将成功。

38.根据权利要求30所述的方法，其中所述基元关键字指出应该顺序接触各接收者，而且如果收到成功响应的特定阈值，则通信流表达式将成功。

39.根据权利要求30所述的方法，其中所述基元关键字指出应该并行接触各接收者。

40.根据权利要求39所述的方法，该方法进一步包括在完成所述未完成的请求时，取消未完成的请求的步骤。

41.根据权利要求30所述的方法，其中所述基元关键字指出应该顺序接触各接收者。

42.根据权利要求30所述的方法，其中所述基元关键字指出应该倒置一个或者多个可能操作数的值。

43.根据权利要求30所述的方法，其中利用三值逻辑，评估所述通信流表达式。

44.根据权利要求43所述的方法，其中所述3个可能的逻辑值是通知失败(不确定)、响应失败(假)和响应成功(真)。

45.根据权利要求30所述的方法，其中所述通信流表达式包括用于指出所述通信流表达式应该何时终止的成功测试。

46.根据权利要求45所述的方法，其中根据可以包括在从所述至少一个接收者接收的响应内的变量，所述成功测试规定三值逻辑表达式。

47.根据权利要求45所述的方法，其中所述成功测试对接收的所有响应进行聚集并对所述响应进行处理。

48.根据权利要求30所述的方法，其中所述通信流表达式使事物升级到下一级，并取消与进行所述升级之前的当前级有关的未决消息。

49.根据权利要求30所述的方法，其中所述通信流表达式使事物升级到下一级，并保持与进行所述升级之前的当前级有关的未决消息。

50.根据权利要求30所述的方法，其中所述通信流表达式确定所述发送者和所述至少一个接收者的喜好。

51.根据权利要求30所述的方法，其中在传送到所述至少一个接收者时，评估所述通信流表达式。

52.根据权利要求30所述的方法，其中所述通信流表达式引用所述至少一个接收者确定的通信流规则，其中所述通信流规则可以将所述通信流调节到所述发送者的特性。

53.根据权利要求30所述的方法，其中所述通信流表达式引用所述至少一个接收者确定的通信流规则，其中所述通信流规则可以将所述通信流调节到所述消息的特性。

54.根据权利要求30所述的方法，其中如果所述至少一个接收者不响应所述消息，则所述通信流表达式指出要执行的一个或者多个动作。

55.根据权利要求30所述的方法，其中所述通信流表达式允许所述至少一个接收者将所述消息委托给另一个接收者。

56.根据权利要求30所述的方法，其中在读取所述消息后，所述通信流表达式允许所述至少一个接收者将所述消息委托给另一个接收者。

57.根据权利要求30所述的方法，其中所述通信流表达式利用时间约束指出所述至少一个接收者的喜好。

58.根据权利要求30所述的方法，其中所述通信流表达式利用时域指出所述至少一个接收者的喜好。

59.一种根据通信流，将消息从发送者送到至少一个接收者的方法，所述方法包括：

从所述发送者接收所述消息；

评估所述通信流，其中基本在将所述消息送到所述至少一个接收者的同时，评估所述通信流；以及

根据所述发送者的喜好，处理所述消息。

60.根据权利要求59所述的方法，该方法进一步包括基本在将所述消息送到所述至少一个接收者的同时，获得所述消息的内容的步骤。

61.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的方法，所述方法包括：

从所述发送者接收所述消息；

评估所述通信流，其中利用指出应该如何处理所述消息的通信流表达式，控制所述通信流，其中利用三值逻辑评估所述通信流表达式；以及

根据所述通信流表达式，处理所述消息。

62.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的系统，所述系统包括：

存储器，用于存储计算机可读代码；以及

处理器，可操作地连接到所述存储器，所述处理器被配置以实现所述计算机可读代码，所述计算机可读代码被配置以：

从所述至少一个接收者接收响应；以及

根据所述响应，在所述通信流中选择至少一个通路。

63.一种根据通信流，将消息从发送者送到至少一个接收者的系统，所述系统包括：

存储器，用于存储计算机可读代码；以及

处理器，可操作地连接到所述存储器，所述处理器被配置以实现所述计算机可读代码，所述计算机可读代码被配置以：

从所述发送者接收所述消息；

评估所述通信流，其中所述通信流规定所述发送者的至少一个喜好以传送所述消息；以及

根据所述发送者的所述喜好，处理所述消息。

64.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的系统，所述系统包括：

存储器，用于存储计算机可读代码；以及

处理器，可操作地连接到所述存储器，所述处理器被配置以实现所述计算机可读代码，所述计算机可读代码被配置以：

从所述发送者接收所述消息；

评估所述通信流，其中利用含有用于指出应该如何处理所述消息的至少一个基元关键字的通信流表达式，控制所述通信流；以及

根据所述通信流表达式，处理所述消息。

65.一种根据通信流，将消息从发送者送到至少一个接收者的系统，所述系统包括：

存储器，用于存储计算机可读代码；以及

处理器，可操作地连接到所述存储器，所述处理器被配置以实现所述计算机可读代码，所述计算机可读代码被配置以：

从所述发送者接收所述消息；

评估所述通信流，其中基本在将所述消息送到所述至少一个接收者的同时，评估所述通信流；以及

根据所述发送者的喜好，处理所述消息。

66.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的系统，所述系统包括：

存储器，用于存储计算机可读代码；以及

处理器，可操作地连接到所述存储器，所述处理器被配置以实现所述计算机可读代码，所述计算机可读代码被配置以：

从所述发送者接收所述消息；

评估所述通信流，其中利用用于指出应该如何处理所述消息的通信流表达式，控制所述通信流，其中利用三值逻辑评估所述通信流表达式；以及

根据所述通信流表达式，处理所述消息。

67.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的系统，所述系统包括：

用于从所述至少一个接收者接收响应的装置；以及

用于根据所述响应，在所述通信流中选择至少一个通路的装置。

68.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的系统，所述系统包括：

用于从所述发送者接收所述消息的装置；

用于评估所述通信流的装置，其中利用至少含有一个用于指出应该如何处理所述消息的基元关键字的通信流表达式，控制所述通信流；以及

用于根据所述通信流表达式，处理所述消息的装置。

69.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的制品，所述制品包括：

计算机可读介质，具有在其上实现的计算机可读代码装置，所述计算机可读程序代码装置包括：

用于从所述至少一个接收者接收响应的步骤；以及

用于根据所述响应，在所述通信流中选择至少一个通路的步骤。

70.一种根据具有多个可能通路的通信流，将消息从发送者送到至少一个接收者的制品，所述制品包括：

计算机可读介质，具有在其上实现的计算机可读代码装置，所述计算机可读程序代码装置包括：

用于从所述发送者接收所述消息的步骤；

用于评估所述通信流的步骤，其中利用至少含有一个用于指出应该如何处理所述消息的基元关键字的通信流表达式，控制所述通信流；以及

用于根据所述通信流表达式，处理所述消息的步骤。

Images