专利名称：提供情境感知型宣告的方法
技术领域：
本说明书一般地涉及通信系统，更具体地涉及提供情境感知型宣告 (context aware announcement)的方法。
背景技术：
在一天的正常过程中，人们接收涉及多个主题的多个呼叫。这些可能 引起破坏(disruption)，这种破坏可能有害地影响到人们有效地开展工作 所需的集中度。为了处理这些中断，人们必须找到对他们的呼叫进行优先 级排序的方式，以使得他们可以高效地管理他们的注意力。以开发了呼叫 线路ID (CLID)和CRM (客户关系管理)工具来帮助人们高效地管理这 些呼叫尝试并将可能发生的破坏降到最少。此外，可以为高级经理提供人 事助理以针对与经理的当前情境的适合程度来检查呼入(incoming call)。助理可以对呼叫进行优先级排序，捎口信，并且打断经理以接听 重要呼叫。助理可以向呼叫者和经理作出行宣告，这些宣告涉及所提议的 基于优先级而对呼叫的安排。助理可以向经理和呼叫者提供用于呼叫处理 的选项。所作出的宣告对于呼叫者和经理之间的角色关系可能是适当的。
另外，对社交感知的感觉提供与高级经理的助理相同的功能。希望与 传统的办公室环境中特定的人进行交互的人能够感觉他们的情境并且评估 他们所提议交互在其中的适合程度。例如，看见一个人在与同事密切合作 会提供这样的感觉不经意的交谈是不合适的。但是，如果所提议的主题 是关于这个人当前所做工作的，则交互可能是最合适的。因此，企业内的合作是通过对任何特定的所提议交互在当前情境中的
适合程度的感觉来调解(mediate)的。这种感知可以通过如同事交互的示 例所示的接近性(proximity)来调解。但是，在IP电话和其他网络合作系 统的情况下，这种对感知的感觉丧失。高级经理的助理的示例给出了可以 恢复这种感觉的一种方式的示例。所提议的交互和这些交互中的事件可与 所提议的动作一起宣告给双方。
然而，某些语音邮件系统允许基于所提供的呼叫线路身份(CLID)来 选择问候语。这是提供情境感知型宣告的方向中的一步；这些宣告是仅依 捎口信这一个条件而定的。例如，用户可能在他/她的办公室中与其他人一 起忙碌，或者他可能离开他的桌子达数分钟。语音邮件系统仅感知到呼叫 已被转发到它，而无法调整其消息使其适应于用户的当前情境。
类似地，美国专利5,754,627 ( "Method and Apparatus for Managing Calls Using a Soft Call Park (利用软呼叫停放来管理呼叫的方法和装 置)")公开了一种系统，利用这种系统，被通知了来自主叫方的呼叫的 被叫方可以触发宣告，该宣告被播放给主叫方以给予他/她留下语音邮件消 息或者在队列中等待以与被叫方交谈的选项。这是"等一会儿(Wait a minute)"特征。该特征仅仅提供一般的消息。其不是针对主叫方或者当 前用户情境而定制的。无法使得消息适合于被叫方和主叫方之间的关系， 并且无法具体给出呼叫无法被立即接听的原因。
发明内容
实施例的第一广阔方面试图提供一种提供情境感知型宣告的方法，该
方法包括应用情境呼叫处理规则以确定呼入的当前情境；以及提供至少
一个情境感知型宣告以提供与当前情境相关联的信息和呼叫信息。
在第一广阔方面的一些实施例中，呼入是从呼叫者到用户，并且提供 至少一个情境感知型宣告的步骤包括向呼叫者、用户和第三方中的至少
一个提供至少一个情境感知型宣告。
在第一广阔方面的其他实施例中，应用情境呼叫处理规则以确定当前
情境的步骤基于以下各项中的至少一项呼叫者和用户之间的关系、用户的时间表、用户的位置、用户的活动、呼叫类型和用户的偏好。
在第一广阔方面的其他实施例中，所述至少一个情境感知型宣告包括 用于处理呼入的至少一个可选选项。在这些实施例的一些中，所述至少一 个可选选项包括请求与呼入的情境相关联的信息。在这些实施例的其他实 施例中，所述方法还包括以下步骤接收对所述至少一个可选选项的选 择，并提供用于处理所述呼入的至少一个其他可选选项。在这些实施例的 其他实施例中，所述至少一个可选选项包括与呼入的情境相关联的信息， 并且所述方法还包括将呼入转发到语音邮箱、数据库和第三方中的至少一 个。
在第一广阔方面的其他实施例中，所述方法还包括检索情境呼叫处理
在第一广阔方面的一些实施例中，所述情境呼叫处理规则还基于结 合对呼叫处理的具体决定而来自所生成的模糊可用性的指示符的可用性的 清晰指示符。
在第一广阔方面的其他实施例中，所述至少一个情境感知型宣告包括 至少一个变量值，所述至少一个变量值是通过处理当前情境和呼叫信息中 的至少一个而确定的。
实施例的第二广阔方面试图提供一种用于提供情境感知型宣告的系 统。该系统包括用于管理呼入和情境感知型宣告的呼叫管理实体。所述系 统还包括可由呼叫管理实体访问的共享存储器空间，用于存储情境数据。 所述系统还包括耦合到共享存储器空间的至少一个代理，所述至少一个代 理用于向情境数据应用情境呼叫处理规则以确定呼入的当前情境；以及 向呼叫管理实体提供至少一个情境感知型宣告以提供与当前情境相关联的 信息和呼叫信息。
在第二广阔方面的一些实施例中，所述系统还包括用户界面，用于允 许用户与共享存储器空间的交互。在这些实施例的一些中，用户界面能够 允许用户设置共享存储器空间中的当前情境。在这些实施例的其他实施例 中，用户界面能够允许用户对源自呼叫管理实体的情境感知型宣告进行应 答。实施例的第三广阔方面试图提供一种在其中实现计算机可读代码的计 算机可读介质，所述计算机可读代码用于控制计算机来执行以下操作应 用情境呼叫处理规则以确定呼入的当前情境；以及提供至少一个情境感知 型宣告以提供与当前情境相关联的信息和呼叫信息。
参考附图来描述实施例，在附图中
图1是根据一个非限制性实施例的因特网电话系统的功能图，其体现 了分布式呼叫处理模型；
图2是根据一个非限制性实施例的因特网电话系统的硬件实现方式的 框图3示出了根据一个非限制性实施例的用于图1和图2的因特网电话 系统的系统架构和模块交互；
图4是根据一个非限制性实施例的用于图3的服务器模块的分类图； 图5是根据一个非限制性实施例的用于图3的客户端模块的分类图； 图6是根据一个非限制性实施例的具有相应参与者的系统的使用情况
图7是根据一个非限制性实施例的用于用户登录和注册的状态线图； 图8是根据一个非限制性实施例的在系统操作期间显示给用户的服务 器欢迎窗口；
图9是根据一个非限制性实施例的在系统操作期间显示给用户的服务 器主窗口；
图10是根据一个非限制性实施例的在系统操作期间显示给管理员的 管理员登录窗口；
图11是根据一个非限制性实施例的在系统操作期间显示给管理员的 情境设置窗口；
图12是根据一个非限制性实施例的在系统操作期间显示给管理员的 计算机名称和分机号码(extensionnumber)设置窗口；图13是根据一个非限制性实施例的在系统操作期间显示给管理员的
关系分配代理窗口；
图14是根据一个非限制性实施例的在系统操作期间显示给管理员的 用户规则分配代理窗口；
图15是根据一个非限制性实施例的在系统操作期间显示给管理员的 用户规则冲突解决代理窗口 ；
图16是根据一个非限制性实施例的在系统操作期间显示给用户的用 户登录窗口；
图17是根据一个非限制性实施例的在系统操作期间显示给用户的用 户注册窗口；
图18是根据一个非限制性实施例的在系统操作期间显示给用户的客 户端主窗口；
图19是根据一个非限制性实施例的在系统操作期间显示给用户的关 系设置窗口；
图20是根据一个非限制性实施例的在系统操作期间显示给用户的好 友列表设置窗口；
图21是根据一个非限制性实施例的在系统操作期间显示给用户的时 间表设置窗口；
图22是根据一个非限制性实施例的在系统操作期间显示给用户的用 户规则设置窗口；
图23是根据一个非限制性实施例的在设置用户规则时显示给用户的 用于选择情境的窗口；
图24是根据一个非限制性实施例的在设置用户规则时显示给用户的 用于选择呼叫者状况的窗口；
图25是根据一个非限制性实施例的在设置用户规则时显示给用户的 用于选择动作的窗口；
图26是根据一个非限制性实施例的在设置用户规则时显示给用户的 确认窗口；
图27是示出根据一个非限制性实施例的、根据图23至图26来创建用
8户规则的步骤的流程图28是根据一个非限制性实施例的在系统操作期间显示给用户的情
境模拟窗口；
图29是根据一个非限制性实施例的在系统操作期间显示给用户的呼 叫递送代理窗口；
图30是根据一个非限制性实施例的在系统操作期间显示给用户的呼 入通知窗口；
图31是根据一个非限制性实施例的在系统操作期间显示给用户的系 统管理代理窗口；
图32是根据一个非限制性实施例的、图2和图3的系统的基于代理的 视图33是根据一个非限制性实施例的在系统操作期间显示给用户的消 息指定窗口；以及
图34是根据一个非限制性实施例的在系统操作期间显示给用户的消 息指定窗口。
具体实施例方式
转到图1，提供了根据一个非限制性实施例的系统的功能图。在操作 中，从一个或多个普遍存在的传感器(未示出)接收涉及用户的位置和活 动的感知数据1，然后将感知数据1应用于情境引擎3。可使用各种技术 来跟踪人的位置。这种普遍存在的传感器的示例包括Active Badge System (有源牛示i己系纟充)[Roy Want, Andy Hopper, Veronica Falcao， Jonathan Gibbons, "The Active Badge Location System", ACM Transactions on Information System 10(1) 91-102， 1992]、 PARCTabs[Norman Adams, Bill N. Schilit， Rich Gold, Michael Tso and Roy Want, "The PARCTAB Mobile Computing System", Proceedings of the Fourth Workshop on Workstation Operating Systems (WWOS隱IV), pages 34-39， Napa, Calif" October 1993]、移 动电话[Peter Duffet-Smith， "High precision CURSOR and digital CURSOR: the real alternatives to GPS"， Proceedings of EURONA V 96 Conference onVehicle Navigation and Control, Royal Institute of Navigation, 1996]及走丑声波 设备[Andy Ward, Alan Jones and Andy Hopper, "A new location technique for the active office", IEEE Personal Communications 4(5), 43-7, 1997]。
申请人的于2003年8月1日递交且通过引用结合于此的美国序号为 10/631,819的共同未决申请"Availability and Location Predictor Using Call Processing Indications (使用呼叫处理指示的可用性和位置预测器)"描述 了从用户与PBX系统的交互来推测(即，猜测)用户可用性的证据收集方 法。这些交互被收集为感知信息并且被通过算法而处理成可用性信息。通 过使用感知信息作为证据，算法对用户的可用性进行预测或者在呼叫处理 中作出决定。该信息被反馈到共享数据库(例如，元组空间(tuple space))中作为断言，这些断言指示关于用户状态的高级评估。这些评估 然后被以下描述的呼叫处理组件用来对呼叫处理作出决定。
在申请人的以下共同未决申请中描述了与将感知数据1应用于基于情 境的通信系统有关的其他方面于2003年7月31日递交且通过引用结合 于此的美国序号为10/631,789的"System and method for facilitating communication using presence and communication services (禾ll用存在性禾口通 信服务来辅助通信的系统和方法)"；以及于2003年8月1日递交且通过 引用结合于此的美国序号为10/631,747的"Generation of Availability Indicators from Call Control Policies for Presence Enabled Telephony System (从用于存在性使能的电话系统的呼叫控制策略中生成可用性指示 符)"。
已被情境引擎3处理成可用性信息的感知数据(即，关于用户的原始 信息)然后以对系统内策略有关的断言的形式被应用于策略引擎5，如下 详细所述。策略引擎5包 括情境更新块9和特征选择策略11。
在情境更新块9中，进入的事件(例如邀请等)与用户的当前情境有 关。每个事件都将其与一些指示符相关联，这些指示符与用户的呼叫相关 并且提供呼叫对用户的相关性、紧急性和重要性的证据。这种指示符包括 呼叫者身份、呼叫者和被叫方之间的角色关系、群组或项目成员资格、用 户的位置、被叫用户的当前状态、呼叫的主题等等。这些证据指示符中的一些在呼叫中是显式的，而一些是可以通过推理而从其他指示符(例如， 上面所讨论的感知数据)得出的。情境更新块9使用机遇推理
(opportunistic reasoning)来形成所需要的证据。该证据然后被提供给特 征选择策略21以选择特征，这将在下面更详细地讨论。如上面所参考的 题为"Generation of Availability Indicators from Call Control Policies for Presence Enabled Telephony System"的对应申请中所讨论的，证据指示符 的形式可以是模糊变量。这些变量的模糊度(fUzziness)用于指示系统在 这些变量中所具有的置信程度。
在由块9所执行的情境更新证据收集处理中，系统有时询问用户他/她 希望执行哪个特征。将用户选项发送给他/她的无线浏览器以询问他/她的 选择是完成此操作的若干相互合适的选项之一。此外，选项可被发送给主 叫方以请求他/她选择若干可接受的选项之一。
如上面所讨论的，尽管在人们一般交互的方式中，许多策略是隐式 的，但是用户可以设置在情境更新块9的机遇推理中使用的一些策略。因 此，系统管理员利用社交学原理设置若千缺省策略。这种缺省策略的示例 包括来自上级的呼叫比来自下级的呼叫更重要，办公室中单独的某个人 比有若干来访者的某个人更加可用，具有与用户的当前活动有关的主题的 呼叫比具有无关主题的呼叫有更少闯入性(intrusive)，等等。
一旦在块9中利用依呼叫而定的信息更新了用户情境，就在块11中 选择要执行的特征。根据由用户设置的、管理其所期望的个性化
(personalized)呼叫处理的策略，特征选择策略块11利用先前在块9中 生成的证据来引导呼叫处理。这些策略指示出针对不同的角色关系、 一天 中的时间、用户状态、用户位置等应该如何处理呼叫。根据申请人的于 2003年8月1日递交并通过引用结合于此的美国序号为10/631,853的共同 未决申请"Personalizable and customizable feature execution for IP telephony using operational semantics and deontic task trees "， 块 11禾!j用前向链
(forward chaining)和模糊推理在所有被提议的特征中生成优先级，并且 将此与所提议的动作的闯入(intrusiveness)相关联。这使得在给出用户的 所声明的私人化偏好的情况下，选择单个特征作为最适合于呼叫处理的特征。如块13所示，该特征然后被执行。
如在申请人的于2000年8月21日递交并通过引用结合于此的美国专 禾U号为7,096,259且题为"Processing by use of synchronized tuple spaces and assertions (通过利用同步元组空间和断言的处理)"的对应授权专利中所 述，在块13处对特征的执行可以被调制，以使得外部特征充当企业约束 (enterprise constraint)从而控制所选择特征的执行。
因此，利用基于因特网的电话的新的寻址能力，特征可以呈现新的语 义。特征可以在私人级别下操作，而非像传统电话一样保持在设备级别。 呼叫不是被引导至物理端点，而是被引导至用户在其商业情境(或者社交 情境)内的身份的各方面。用户可以具有他/她的身份的多个方面，每个方 面在商业环境中具有不同的能力。例如，用户可以具有的身份的多个方面 可以是以下形式
针对不需要当前关注的消息的语音邮箱；
可以使用呼叫处理之外的机制来就呼叫安排进行例程决定(routine decision)和使用其他事物来使用户免受中断的秘书(secretary)或等同功 能；
，代表不同当前项目中的用户的身份，等等。
可直接在URL中运载这多个身份，这些URL利用标准的"点"约定 ("dot" convention)来传达关于用户身份的方面的含义。因此，名字为 JonhDoe的用户可以将其商业身份的多个方面指定为
assistant.john—doe@example.com;
personal .John—doe@example.com;
voice-mail.john_doe@example.com;禾口/或
project.sub.--3499.john—doe@example.com。
约定中的这种改变有效地创建了电话特征如何在所汇聚的语音和数据 系统中操作的全新模型。如上所述，特征在了解当前用户情境的情况下操 作，并且通信被引导至用户身份的最合适方面。因此，例如，主叫方可以 指示他们希望联系身份的哪些方面和他们不希望处理哪些方面。
图2示出根据一个非限制性实施例的系统的示例性硬件实现方式。该系统基于客户端-服务器体系结构。活跃呼叫递送(ACD， Active Call Delivery)客户端21与ACD服务器27通信，ACD服务器27又与TSpaces 服务器23和MiTAI网关服务器25通信。MiTAI网关服务器25提供经由 PBX 26对PSTN 28的接入。ACD服务器27是可以访问TSpaces服务器23
的单个服务器或多个服务器。ACD服务器27包括以下更详细地讨论的 "系统代理"的设置和用户界面。这些用户界面提供介绍窗口、用于系统 管理员的登录窗口、用于管理情境的层次的情境窗口和用于模拟电话呼叫 的呼叫模拟窗口。每个系统代理都对呼叫处理有所贡献并且具有其自己的 责任关系分配(RA， Relationship Assigning)代理负责获取呼叫者和接 收者之间的关系并将其分配给用于呼叫处理的相关数据字段。用户规则分 配(URA)代理负责根据每个规则的条件和当前情境来提取所有匹配用户 规则，并将这些规则分配给用于呼叫处理的相关数据字段。用户规则冲突 解决(UCR)代理负责解决所分配的规则中可能存在的任何冲突。如上所 述，这些代理不必安装在特定机器上，而是可以分布在可以访问TSpaces 服务器23的机器的网络上。将在以下描述各种代理的进一步细节。
ACD客户端21包括用户界面和用户代理。用户界面提供介绍窗口、 用于经注册的系统用户的登录窗口和用于新用户的注册窗口。知识管理是 客户端系统上的用户界面的重要部分。用户可以创建或管理诸如好友列 表、关系信息、时间表和用户偏好规则之类的私人信息。客户端服务器使 用两种类型的代理呼叫递送(CD)代理和系统管理(SM)代理。CD
代理确认TSpaces服务器23中由呼叫监视器生成的事件。呼叫监视器是与 MiTAI网关25的直接接口 ，并且创建事件，该事件被馈给到TSpaces服务 器23中以由CD代理开始呼叫处理。接下来，SM代理确认来自CD代理 的事件，并且将呼叫处理分布给网络上的代理。尽管每个代理具有不同的 服务，但是按照常用的面向对象的设计，服务器和客户端可以具有某些公 共模块。以下说明这些公共对象模块和其他模块。
图3示出了图1和图2的因特网电话系统的系统体系结构和模块交 互。用户界面31包括窗口、表格、菜单和按钮，用于提供用户登录、注 册、用户偏好规则设置、情境模拟和用于辅助用户的消息的显示。
13事件处理器子系统33是位于用户界面31和应用级子系统35之间的监 视后台程序(monitoring daemon)。事件处理器子系统33等待诸如鼠标点 击之类的物理事件从用户界面31到达，并将这些事件引导至适当的应用 模块。开发工具Java为该目的提供了嵌入式事件处理器，例如 ActionListener (动作侦听器)。
应用级35是系统的核心。应用级35包括多个代理，这些代理为客户 端并且为服务器提供服务。所有的系统事务(transaction)、功能和知识管 理都是在该子系统中进行的。
如图4的等级图所示，多个服务器模块被分成三个主要部分系统知 识管理、代理服务和呼叫模拟。系统知识管理模块包括情境设置子模块， 用于使得经授权的管理员能够创建或修改诸如位置和活动之类的情境层 次。代理服务模块包括三个不同的代理模块关系分配(RA)代理、用户 规则分配(URA)代理和用户规则冲突解决(UCR)代理。为了给出代理 的灵活实现方式，管理代理的状态以知道它们的可用性。网络连通性可以 影响它们的可用性。因此，为了使用代理，代理以及代理和和系统的 TSpaces37 (图3)之间的连接必须是起作用的。系统通过检查TSpaces 37 中的相应状态元组来获取代理的状态。状态元组包括"名称"、"优先 级"和"可用性"字段。每个代理负责更新其在TSpaces 37中的状态元 组。用于更新状态元组的过程包括每秒一次地取得状态元组并用新的状态 信息来对其进行改写。元组可被设置为在预定时间之后期满。 一旦期满， TSpaces服务器23就从TSpaces 37中去除该元组。状态元组的期满时间是 三秒，因此如果代理因为任何原因而连续三次未能更新元组，则在 TSpaces 37中将不存在针对相应代理的状态元组。如果没有针对代理的状 态元组，或者如果状态元组中的"可用性"字段被设置为"异常"，则系 统假定该代理是异常的。更新状态元组所花费的一秒和状态元组期满之前 所允许的三秒之间的时间间隙可以防止由临时网络干扰所引起的不必要的 状态切换(status toggling)。
每个代理还负责将事件注册到TSpaces 37中以与客户端机器通信。每 当所等待的元组被写入TSpaces 37中时，TSpaces服务器23就将此通知给已注册了事件的代理。生成事件并从TSpaces 37获得该事件的通知形成了 代理之间的双向通信-确认。
关系分配(RA)代理负责对来自客户端的SM代理的关系分配请求进 行应答。来自SM代理的请求包含呼叫者和接收者信息。RA代理根据用 户的好友列表来分配用户和呼叫者之间的关系。
用户规则分配(URA)代理负责对来自客户端的SM代理的用户规则 分配请求进行应答。在请求之后，URA代理检索关系信息和用户的当前情 境这两者。关系信息是由RA代理设置的呼叫者和接收者之间的关系。用 户的当前情境是用户的位置、当前时间与用户的时间表以及用户的活动。
谁在呼叫？
用户在哪里？
用户在做什么？
是什么时候了？
用户规则冲突解决(UCR)代理负责针对用户规则冲突解决请求对客 户端的SM代理进行应答。该请求包含由URA代理所分配的用户规则信 息。UCR代理在所分配的规则中选择最具体的一个规则。规则具有的条件 越多，就认为规则是越具体的。提供呼叫模拟服务用来在无需连接到 MiTAI网关25的情况下进行测试。具有表格的窗口服务于该功能。
如图5的客户端模块分类图所示，多个客户端模块被分成三个子系 统用户知识管理、代理服务和情境模拟。用户可以通过用户知识管理模 块来操纵私人知识。
呼叫递送(CD)代理负责通过MiTAI网关25而与电话交换机或PBX 26通信。具体而言，CD代理向M汀AI网关25注册事件，并且等待对用 户的呼入的通知。当通知到达时，CD代理向SM代理发送进一步处理的 请求并且等待应答。来自SM代理的该应答包含作为整个呼叫处理的结果 而采取的动作。然后，CD代理负责向MiTAI网关25请求所选择的动作。
系统管理(SM)代理负责管理其他代理的状态并且根据系统代理的 优先级来对呼叫处理进行排序。当CD代理请求呼叫处理时，SM代理在 TSpaces 37中扫描代理的状态元组，并且根据它们的优先级来做出顺序表。SM代理向最高优先级的代理发送处理请求，等待应答，然后将请求 发送给下一最高优先级的代理。当SM代理接收到来自最低优先级的代理
的应答时，其向CD代理发送回信息元组。
情境模拟模块充当情境代理，其动态地检测、解释并更新用户的当前 情境。情境模拟窗口包括由系统管理员设置的所有可能的情境，并且用户 从中进行选择。
TSpaces 37 (即，元组空间)在一个或多个服务器23中被实现为具有 数据库能力的网络通信缓冲器。在http:〃www.almaden.ibm.com/cs/TSpaces/ 和美国专利7,096,259中可以找到对TSpaces 37的更全面描述。TSpaces 37 允许应用和设备之间在异类的计算机和操作系统的网络中通信。TSpaces 37提供群组通信服务、数据库服务、基于URL的文件传输服务和事件通 知服务。TSpaces 37是以Java编程语言实现的，因此通过平台独立性而自 动拥有网络普遍存在性以及对所有数据类型拥有标准类型的表示法。 TSpaces系统适合于任何具有分布或数据存储要求的应用。TSpaces系统可 以执行关系数据库系统的许多职责，而无需强加过度限制(和原始)型系 统、严格的大纲(rigid schema)、笨拙的用户界面或者苛刻的运行时间存 储器要求。在本发明中，TSpaces服务器23是系统和用户知识仓库 (store)之间的媒介。但是，将会了解，TSpaces 37可被关系数据库或提 供等同功能的其他共享数据库所取代，该功能用于管理知识事务(包括 读、写、更新、取得和扫描)以及事件处理(例如事件的注册和通知)。
MiTAI网关25针对不是基于"C"开发语言的程序来辅助与MITEL 电话服务器(即，PBX 26)的通信。但是，MiTAI网关25不受特别限 制，执行类似功能的任何合适网关都在当前实施例的范围内。MiTAI网关 25是基于Windows的进程，其可在任何Windows平台上执行。MiTAI网 关25可以管理网络上来自任何其他程序的单个插座连接(socket connection)并且支持有限会话协议。
MiTAI网关服务器25是PBX 26和ACD的应用级子系统35之间的中 间系统。应用级子系统35为了监视呼入的目的而向MiTAI网关服务器25 注册事件。在系统拓扑方面，用户界面31被建立在Windows平台上，并且通过 事件处理器33与应用级35交互。应用级35子系统使用TSpaces服务器 23作为媒介来进行通信并访问服务器的系统知识管理模块和客户端。
包括用户信息、用户规则、用户的当前情境信息和呼叫信息在内的所 有知识都被存储在TSpaces 37中。与以上引用的参考文献中给出的一样， 如本说明书的附录中所讨论的，存储的单位是元组。
用户信息包括基本用户信息、关系信息、好友列表、用户偏好规则和 动态变化的用户的当前情境信息。用户信息被存储在名称为 "UserProfile"(用户概况)的元组中并且结构如下 其中，"UserProfile"是元组的名称、id是用于在系统中唯一地标识用户 的用户标识。user-info (用户信息)字段包含关于用户的基本用户信息， 例如密码、名字、电话号码和用户的时间表。电话号码是PBX26中的 扩展电话号码，例如我的办公室和助理的电话号码(例如，4001)。该字 段还包含用户的时间表。用于午餐和会议的时间表可以由用户直接输入或 者从另一应用(例如，Microsoft Outlook等)来确定。关系字段包含由用 户利用用户界面以关系层次方式定义的关系信息。用户可以在buddy-list (好友列表)中将任何人加为他的"好友"。好友列表包含关于作为名字 和电话号码而包括的人的信息以及它们与用户的关系。user-rule (用户规 则)字段包含用户偏好规则。用户经由用户界面31来创建他/她的用于处 理呼入的私人偏好。规则中的条件可以使用情境、好友列表和从关系信息 层次中选择的关系。在这一点上，context (情境)字段包含情境信息。系 统中使用的情境确定参数是地址、用户的当前活动和当前时间。位置和活 动情境具有层次，以使得它们可以具有子情境。用户的当前情境信息可以 是真实情境或者由用户所设置的假装情境(pretended context)。真实情境 信息由(一个或多个)情境代理来更新，而另一方面，假装情境由用户来 设置和控制。如果用户希望，则假装情境被设计为超越真实情境。位置参 数的层次是由系统管理员来定义的。因此，如果位置的属性与电话号码相 耦合，则系统可以将用户的呼叫递送到离用户的当前位置最近的电话。存在两种可被定义的活动。 一些活动可被系统自动检测，而其他活动 可仅由用户来假定或设置。例如，系统能够知道用户是否"在打电话"， 但是难以判断用户是否"忙于工作"或"正在休息"。因此，可检测的活 动被系统自动更新，且其他活动由用户设置。接收者的时间情境是根据他 的时间表来设置的。例如，如果用户的午餐时间被制定为从下午12点到 下午1点，则系统可以假定用户在该时间段期间在吃午餐。
呼叫信息包含在代理所共享以与其他代理通信的元组中，用于处理呼 入。因此，呼叫信息包含针对呼叫者信息和用户偏好规则的所有必要数据
字段。代理从TSpaces 37取得"Call"(呼叫)元组并根据它们的责任来 更新该元组。例如，RA代理分配呼叫者和接收者之间的关系，URA代理 分配所有适当的用户规则，且UCR代理通过仅选择一个用户规则来解决 用户规则冲突。该元组的形式是
{"Call", dest-agent, source-agent, id， call-info, user-rule} 其中，"Call"是元组的名称，dest-agent (目的地代理)是希望其接收该 元组的目的地代理，source-agent (源代理)字段标识出发送该元组的源代 理，id字段是用户标识，且call-info (呼叫信息)字段包含呼叫者和接收 者这两者的基本信息，例如电话号码、名字和他们之间的关系信息。user-rule (用户规则)与由代理所分配的(一个或多个)用户规则相匹配。当 代理在TSpaces服务器23中注册事件时，"Call"字段和dest-agent字段 被使用。以下是对TSpaces服务器23的SM代理事件注册例程的一部分
Tuple template=new Tuple("Call"， "SMAgent"， new Field(String.class), id, new Field(String.class), new Field(String.class), new Field(String.class));
seqNum=ts.eventRegister(TupleSpace.WRITE, template, this, newThread);
当元组被张贴时，该例程请求TSpaces服务器23通知SM代理，其中 第一字段是"Call"(呼叫)，第二字段是"SMAgent" (SM代理)且第 四字段是用户id，并且其中，第三字段是表示该字段可接受任何值的 "new Field(String.class)"。
模块交互示出了类、模块和系统整体的行为。它们描述了系统的组件 如何通过消息传送、功能调用和通过共享状态信息来交互。利用统一建模
18语言(UML)符号，分别在图6的使用情况图和图7的状态线图中示出了
本发明的组件交互。
为了使用该系统(包括用于管理员的服务器系统和用于用户的客户端
系统)，必须得到授权。如图7所示，首次使用的用户通过点击"登录窗 口"中的"注册"按钮进行注册。注册中的用户提供用于使用系统的重要 信息，例如用户ID、密码、名字和电话号码。在点击用于提交的"OK" (确定)按钮之前，无遗漏地填写每个字段。 一旦提交，系统就检査有效 性，例如每个字段是否具有正确的长度和每个字段是否是有含义的。在一 些实施例中，用户ID小于IO个字母字符且密码小于10个数和/或字母。 在其他实施例中，名字字段小于20个字符且电话号码字段仅允许数字。 如果图7中的"有效性检査"阶段成功，则系统通过执行"write()"操作 将信息写到TSpaces 37中。当系统成功地将用户的信息写入TSpaces中 时，用户注册过程完成。
注册后的用户和管理员在使用系统之前需要被认证。必须正确填写 "登录窗口"中的用户ID和密码字段，然后点击"OK"按钮。如果两个 字段被无遗漏地填写，则系统检査每个字段的有效性。该有效性确认过程 与用户注册过程中相同。所确认的用户ID和密码对应当与TSpaces 37中 的相匹配。系统通过执行"read()"操作来获得信息，并将它们进行比较。 当用户点击"退出"按钮或者输入的用户ID和密码对与已经在TSpaces 37 中的用户ID和密码对之间匹配时，登录过程结束。
本发明的ACD系统的原型已被利用Java编程语言在Windows NT平 台上实现了，以下程序包(package)被用于该实现
用于Java开发环境的Java 2平台标准版v 1.3.1 。
作为数据存储库和代理之间的通信媒介的TSpaces v2丄2。
用于PBX接口的Mitel电话应用接口 (MiTAI)。
系统的安装和执行方法的细节包括对Java类文件进行拆包(u叩ack) 并执行这些文件，以及本领域技术人员所公知的其他服务器启动过程。
ACD系统的设计不限制于任何特定用户域(user domain)。 一种定义
用户域的知识的灵活方法允许系统用于不同的域。系统管理员可以根据目
19标用户域来定义用户的位置、活动和时间的层次。为了本发明的成功原型
的目的，系统提供了两种示例域办公室职员(office worker)的域和教 授(professor)的域。如图8所示，用户可以通过点击介绍窗口中的相应 按钮来选择这两个域中的一个。其自动地建立必要知识，例如可能的位置 的层次、关系信息和好友列表。
ACD服务器系统27被设计为简单且易于使用。在连接到TSpaces服 务器23之后，ACD服务器系统27的安装过程要求对Java类文件进行拆 包并在网络上的任何机器上执行这些文件。开始时，欢迎窗口提供关于 ACD系统的简要信息、管理员登录信息以及加载用于测试目的信息的两个 按钮"办公室职员情境设置加载"和"教授情境设置加载"，如图8所 示。当"办公室职员情境设置加载"按钮被点击时，办公室职员的示例情 境被写入到TSpaces 37中。在图9中示出位置和活动的这种层次模型。为 了测试教授的域的示例，可以选择"教授情境设置加载"。测试者可以在 无需选择用于测试定制情境的预定的一组信息的情况下启动服务器。当测 试者跳过信息加载时，服务器系统告知测试者应当从这两个选择中选择 情境的层次或者手动选择情境的层次。"管理员登录"和"退出"按钮是 无需说明的。
为了作为控制服务器的知识和服务的管理员来登录，通过图10所示 的管理员登录窗口来认证用户。如果有字段被遗漏或者管理员ID和密码 之间存在失配，则错误消息窗口被呈现。
一旦登录被授权，服务器主窗口就被呈现以用于进一步处理，如图9 所示。在建立系统知识管理模块(图3)过程中，在客户端系统提供用户 服务之前，必须首先执行情境设置以构建情境层次。点击"情境"的"设 置"按钮(图9)使得管理员能够利用GUI来设置情境的层次。在一些实 施例中，用于该系统的情境层次的预定根是位置和活动。时间是该系统中 使用的另一情境，但是可以基于特定用户的时间表或者特定公司的时间表 (例如，公司定义的午餐时间和/或咖啡时间和/或上班时间)来将其私人 化。因此，每个客户端系统管理其自己的时间情境。在图11中示出具有 示例位置层次和活动的情境窗口。为了添加新的子情境，管理员点击层次
2中的情境之一并点击"添加"按钮。从而添加了缺省名称为"新节点n" 的"子"情境。双击该名称可以重新命名该情境。为了去除节点，管理员 点击要去除的节点并点击"去除"按钮。点击"清除"按钮将从情境树中 清除所有节点。为了保存改变并完成修改，管理员点击"完成"。
返回图9，计算机名称和电话号码被配对并保存，以转发呼入。在
ACD系统27中，当匹配用户偏好规则的递送动作是"将其转发到我所在 的地方"或者当用户想要将呼入转发到不同的电话时，该信息被使用。管 理员可以通过点击"Comp-ext"(计算机-分机)的"设置"按钮来添加、 去除和改变该信息，这使得显示图12所示的表。
可在任何可以访问TSpaces服务器23的机器上执行服务器代理。这意 味着网络内的任何机器可以用于执行服务器代理。这种设计给出了代理的 灵活分布。可以通过点击"全部"按钮(图9)而在一个给定的机器上一 起执行全部代理，或者可以通过点击相应按钮而在网络内的同一机器或者 不同机器上分开执行各个代理。在一些实施例中，由于网络限制，每个代 理可以通过每秒一次地写它的状态元组来定期报告它的状态，其中元组的 寿命是三秒。上面参考图4和图5详细给出了对服务器代理的状态管理的 细节。在一些实施例中，每个代理具有显示窗口和用于控制其的四个按 钮，如图13、图14和图15所示。点击"启动"按钮将通过激活其状态报 告来启动相应的代理。"停止"按钮是用于对其测试目的的状态包括解除 激活(deactivate)。在这些实施例中，三秒的最大值之后，用于相应代理 的状态元组不再存在于TSpaces 37中，结果客户端认识到该代理不可用。 "启动"和"停止"按钮是互斥的，当一个在执行时另一个被禁止。"清 除"按钮可以清除显示区域，并且"完成"按钮可以终止相应代理。
关系分配(RA)代理基于用户的好友列表来分配呼叫者和接收者之间 的关系信息。在图13中示出执行的示例，其中来自用户(具有用户ID "choi")的系统管理(SM)代理的关系分配请求被接收。该请求与呼叫 者的电话号码(在该示例中为"4021") —起到来。RA代理从TSpaces 37获得用户的好友列表，并找出用户"choi"和电话号码为"4021"的人 之间的关系。结果，发现"老板"关系。通过将具有关系信息的元组写入到TSpaces 37中，将呼叫控制发送回客户端。该代理可以返回多个关系。 例如， 一个人可以既是朋友又是客户。因此，用于这两个关系的元组将被 返回。
用户规则分配(URA)代理分配与规则的条件和用户的当前情境相匹 配的所有用户偏好规则，如图14所示。如果规则的条件由具有层次的信 息构成，则检查子类(sub-category)。例如，用户偏好规则的位置条件是 "如果我在办公室中"。办公室的子位置(例如实验室、会议室)也满足 规则的条件。例如，当用户"choi"在会议室中并且繁忙时，考虑该用户 接收来自分机号码"4021"的呼叫。在测试情形中，"4021"是Thomas Ragan的电话并且他是用户的老板。基于用户的当前情境、关系信息和呼 叫者的匹配用户偏好规则如下
规则名称职员-办公室规则
条件如果呼叫来自[职员]关系
并且当我在我的[办公室]中时
动作接通该呼叫
规则名称Thomas Ragan-繁忙规则 条件如果呼叫来自[Thomas Ragan]
并且我[繁忙] 动作询问呼叫者要做什么
规则名称职员-办公室-繁忙规则 条件如果呼叫来自[职员]关系
当我在我的[办公室]中时
如果我[繁忙] 动作将呼叫转发到语音邮箱
分配规则的名称被显示为图14中所匹配的那样。尽管对于用户的当 前情境，这些规则是令人满意的，但是系统需要选择最适合于用户的一个 规则以采取行动。
如果URA代理分配了多于一个规则，则用户规则冲突解决(UCR) 代理选择一个用户偏好规则。根据一个非限制性实施例，UCR在所分配的规则中选择最具体的规则。认为具有更多条件的规则是更具体的。在上面 给出的情形中，"职员-办公室-繁忙"是所分配的规则中最具体的规则， 并因此被选择，如图15所示。但是，如果规则具有相同数目的条件，则 UCR代理通过比较条件项在层次中的深度来寻找更具体的条件(例如，
"会议室"比"办公室"更具体)。当UCR代理无法通过上面给出的任
一种方法来选择冲突规则当中的一个规则时，系统选择最近创建的规则。
具体而言，当UCR代理经由TSpaces 37生成去往呼叫递送(CD)代理的 所选择的(一个或多个)代理的列表时，CD代理假定仅有一个由UCR代 理所分配的规则，因此其仅使用第一规则，这是最近创建的规则(以用户 创建顺序来保存用户规则，并且以降序排列给予CD代理的列表)。或 者，UCR代理可以总是简单地随机选择规则，或者在多个最具体的规则之 间为平分的情况下随机选择规则.
如上参考图8所讨论的，当ACD代理启动时，用户被呈现欢迎窗 口。在白色文本区域上说明测试信息和项目的简要说明。"办公室职员信 息加载"按钮和"教授信息加载"按钮这两个按钮被用于测试每个用户 域。在点击适当的按钮之后，用于测试客户端的所有必要私人信息(用户 ID、密码、用户名字、电话号码、私人关系的层次、好友列表表格、时间 表和用户偏好规则)被拷贝到TSpaces 37中。确认窗口示出了处理结果的 反馈。
在登录过程(图16)期间，利用TSpaces服务器23上的信息来检査 用户的ID和密码。如果用户是新的系统用户，则通过"注册"选项来实 现注册。点击注册窗口中的"注册"按钮会对每个输入字段执行有效性确 认和验证。 一旦用户通过登录窗口或者注册窗口而登录了，用户名字就作 为用户标识的反馈而出现在每个客户端窗口框架上。
提示首次使用的用户通过注册来提供诸如用户ID、密码、名字和电话 号码之类的基本用户信息。检查输入的用户ID以査看其是否与现有的用 户ID重复。每个字段都具有其自己的对长度和格式的限制。在点击"注 册"按钮(图17)之后，如果违反了任何限制，则错误窗口将通知用户。
如果登录或注册过程成功，则用于客户端控制的主窗口被呈现，如图18所示。其包括三个部分用户信息、知识管理和情境模拟。基本用户信 息(用户名字和办公室电话号码)被作为反馈而显示给用户。用户ID被 显示在窗口的框架中。用户可以通过该菜单来设置他的私人信息，例如关 系信息、好友列表、时间表和用户偏好规则。在一些非限制性实施例中， 每个菜单都具有帮助按钮以给出对相应项的功能的简要说明。
私人关系信息被示出为易于维护的树结构(图19)。为了添加新的子 关系，用户选择关系节点之一并且点击"添加"按钮。从而创建了具有缺
省名称"新节点n"的新的子节点，可以通过双击名称来对该节点重新命
名。为了去除一个关系，用户选择要去除的关系节点并且点击"去除"按 钮。应当注意，属于要去除的关系的子关系也被去除。为了去除所有的关 系，用户点击"清除"按钮以从树上清除所有的关系节点。为了保存改变 并完成修改，用户点击"完成"。
点击图20中的好友列表表格上的任何字段将允许用户对该特定字段
进行改变。为了从表中去除一组好友信息，用户可以选择一栏并点击"去
除"。当"完成"按钮被点击时，修改后的表被保存到TSpaces37中。
如图21所示，在一些非限制性实施例中，用户可以设置两个经分类 的时间表午餐时间和会议时间。当用户创建新的偏好规则时，这些时间 设置可被作为"午餐时间"和"会议时间"而参考。用户从图21所示的 下拉菜单中为每个时间表选择开始时间和结束时间。"完成"按钮保存时 间表并且去除时间表设置窗口。尽管图21的时间表设置窗口被示出为仅 具有两个经分类的时间表，但是经分类的时间表的数目不受特别限制。此 外，在一些非限制性实施例中，可以经由时间表代理(未示出)从另一个 应用(例如，Microsoft Outlook等)来确定用户的时间表。
用户规则设置窗口包括三个部分包括顺序号和用户规则名称的用户
规则表、UI按钮和描述窗口，如图22所示。点击表中的规则之一使得用 户能够在描述窗口中看到对所选择的规则的描述。添加、刷新、去除、清 除和完成按钮用于管理规则。"添加"按钮被设计为用于创建新规则并且 其需要四个步骤，这将在以下详细描述。通过点击"刷新"按钮，新创建 的规则被显示在用户规则表中。为了去除现有的规则，用户在表上选择要删除的规则并点击"去除"按钮。为了去除所有的现有规则，用户可以点 击"清除"按钮。为了完成编辑，用户可以点击"完成"按钮以保存任何 改变。
点击"用户规则设置窗口"中的"添加"按钮将开始创建新规则。添 加新规则涉及四个步骤。第一步是选择情境作为要创建的规则的条件的一 部分(图23)。从给出的层次树来进行位置和活动选择。位置和活动的这 些层次是有来自服务器的管理员定义的。从具有以下三个选择的下拉菜单 中选择时间情境"任何时间"、"会议时间"和"午餐时间"。实际时 间表是由用户通过"时间表设置窗口"来设置的。在窗口的底部显示这些 步骤并且以红色来书写当前步骤。当情境条件已被选择时，用户点击"下 一步"按钮以移到第二步。
第二步是选择呼叫者的类型作为条件的一部分。可以选择以下三个类 别之一任何呼叫者、好友列表表格和关系树。这三个类别是互斥的，因 此提供单选按钮来仅选择一个类别。当选择了类别时，用户然后可以选择 其选择窗口中的项。图24示出了对"好友"的选择的一个非限制性示 例现在可以从好友表中选择好友之一，而关系层次窗口保持被禁止。
第三步是从预订的动作列表中选择规则的动作，如图25所示。动作 项被用他们的相关联的单选按钮而列出，并且仅一个动作项可被从该列表 中选择。
用于创建新规则的第四步即最后一步是确认。如图26所示，用户确
认并指派唯一规则名称。"对规则的描述"窗口示出了用户所作的选择 (一个或多个)条件和动作。点击"提交"按钮将保存新规则。
作为用于创建新规则的示例(从图23到图26)，对规则的描述如
下
规则名称MindyBaker-办公室房间-繁忙规则 条件如果呼叫来自[Mindy Baker]
并且当我在我的[办公室房间]中时
并且当我[繁忙]时 动作将其转发给助理
25在图27中示出创建用户偏好规则的整个过程。
最终，用户的当前情境(例如当前位置和活动)被通过情境代理而更 新。在成功的原型中，模拟程序用于替代现实生活中事件的发生。为了测 试的目的，测试者选择层次树上的期望情境之一，然后点击"应用"(图
28)。显示在窗口上的当前时间是客户端机器的系统时间，该系统时间通
过与用户的时间表匹配而被用作时间情境。
如上面所讨论的，客户端具有两个代理呼叫递送(CD)代理和系统
管理(SM)代理。每个代理具有其自己的显示窗口以向用户呈现过程消 息。CD代理既连接到TSpaces服务器23以与其他代理通信，又连接到 MiTAI网关服务器以与电话系统通信。
图29中的窗口显示该客户端所连接到的TSpaces服务器23的机器名 称和端口号。缺省的TSpaces服务器名称是"本地主机"，这与当前客户 端机器是相同的机器。第二行示出MiTAI网关服务器名称及其端口号。 "用于[choi]的CD代理现在准备就绪"意味着两个必要连接已被确认，并 且CD代理准备好用于用户ID为"choi"的用户。
可以从呼叫模拟或者呼叫监视器来接收呼叫处理请求。呼叫监视器与 用于处理实际电话呼叫的MiTAI网关服务器25通信，而呼叫模拟是服务 器机器上的另一个窗口，用于在无需MiTAI网管接口的情况下测试系统。 当涉及所有可用代理的呼叫处理已经结束时，CD代理提取所选择的用户 规则(这是处理的结果)并请求呼叫监视器执行所选择的规则中声称的动 作。当图29中的示例被执行时，动作"在屏幕上通知我"使得在客户端 机器上产生通知窗口，如图30所示。
SM代理还连接到TSpaces服务器23以与其他代理通信。图31中的显 示确认了所建立的连接。缺省的TSpaces服务器名称是"本地主机"，这 与CD代理的缺省服务器名称是相同的。"用于[choi]的SM代理现在准备 就绪"意味着必要的连接被确认并且SM代理准备好用于用户ID为 "choi"的用户。SM代理负责根据可用代理的优先级来对这些可用代理进 行排序。显示窗口将对代理的排序示出为呼叫处理的一部分。当CD代理 将呼入通知给用户时，SM代理检索代理的状态并将呼叫控制分布给每个
26代理。在完成呼叫处理之后，控制被发送回CD代理以执行所选择的动
作。SM代理窗口具有"代理状态"按钮，该按钮使得用户能够手动检查
代理状态。"清除"按钮可清除消息显示区域并且"完成"按钮可退出系 统。
总之，根据本发明，定义了一种用户消息递送系统的情境模型，并且 提供了一种辅助创建基于情境和基于规则的通信的系统体系结构。位置情 境用于基于位置信息来转发呼入。用户的活动或可用性在本发明中用于将 诸如"繁忙"、"回来"、"离开"和"午餐"之类的用户状态通知给其 他所连接的用户。时间情境用于设置某些由用户定义的规则的应用时间。
通过在合适的情形中接收适当的消息，系统用户受益于最少的中断。 通过采用私人特征并且基于用户的当前情境模型和他/她的偏好规则来过滤 消息，提高了将期望的递送动作用于用户的可能性。尽管出于以上详细给 出的系统的工作原型的目的而模拟了用户的当前情境，但是本领域技术人 员将会容易地认识到可以用实际上检测用户的情境的情境代理来实现该系 统。为此，已测试了一种简单类型的情境代理，该情境代理检测计算机的 鼠标运动。在操作中，在网络中使用多个机器的用户首先登录到特定计算
机上。情境代理检测计算机的鼠标运动，并且作为响应而更新TSpaces37 中的用户位置信息，以使得呼入可以被通知或者转发给该位置处的用户。
如申请人的于2003年8月12日递交且通过引用结合于此的美国序号 为10/638,416的共同未决申请"Privacy and Security Mechanism for Presence Systems with Tuple Spaces (用于具有元组空间的存在性系统的隐 私和安全机制)"中所讨论的，尽管使用TSpaces 37在多代理系统设计方 面提供了很大的灵活性，但是因为其允许共享所有信息，所以安全性较 弱。诸如用户概况之类的一些隐私敏感型信息应当得到保护。TSpaces服 务器23通过在TSpaces 37上设置用户和群组许可而提供访问控制，以使 得仅具有正确的访问控制许可的用户可以从TSpaces中读写元组。在上述 共同未决申请中给出了其他的安全性措施。
此外，尽管在呼叫处理方面已描述了成功的原型，但是可以想到，可 以扩展本发明的原理以实现除电话之外的事件处理，例如电子邮件处理、来访者通知服务等等。
现在可以提供情境感知型宣告的实施例，图32示出了图2和图3的系 统的一个实施例的基于代理的视图的框图。但是，在图32所示的实施例 中，SIP代理(SIP proxy) 3210取代了图2的PBX 26。实际上，通信系统 和通信网络不受特别限制，在本发明的实施例中可以使用任何合适的通信 系统和通信网络。
SIP代理3210 (或者图2的PBX 26)接收呼入。利用公共网关接口 (CGI)或者另一合适设备，SIP代理3210将在元组空间3220中就呼叫作 出断言，该元组空间3220与上面所述的元组空间23和元组空间37类似。 在传统的PBX的情况下，这可能受限于呼叫线路ID (CLID)和所拨号码 (例如，来自DNIS-所拨号码信息服务)信息。但是，利用SIP或者类似 的合适协议，可以提供诸如呼叫主题、紧急性等的更多信息。该动作的结 果是元组空间3220现在将包含描述呼叫的多个断言。
系统管理代理(SMA) 3230在呼叫处理方面将围绕元组空间3220的 其他代理(在下面描述)的行为同步。SMA 3230将在适当的时间触发这 些代理，以评估当前在元组空间3220中的信息并且作出总地来描述呼叫 的进一步断言。具体而言，关系分配代理3240和一个或多个情境代理 3250将被触发，以评估当前断言并将呼入与当前用户情境相关联。
用户情境被理解为表示用户在哪里、他/她在做什么、他/她和谁在一 起以及从该信息可以推断出什么。此处的"什么"和"谁"可以超出原始 信息。情境代理3250将包含IF-Then (如果-则)规则或者可以将多个具体
事实与多个抽象概念相关联的策略。因此，如果位置感知型情境代理确定 用户在特定房间(即，603-1)中，则另一情境代理规则可以将房间603-1 标识为会议室并且作出关于用户在会议室中的断言。
类似地，关系分配代理3240具有多个规则，这些规则取得关于呼叫 的证据并且将呼叫者与用户相关联。例如，规则可以涉及与特定个体相关 联的电话号码(例如，号码683-1556是Amanda Slack的电话号码)。而 其他规则可以涉及用户和特定个体之间的关系(例如，Amanda Slack是用 户的老板)。因此，情境代理3250和关系分配代理3240之间的配合操作 (interoperation)可以取得呼入可用的一些粗略信息，并且使呼叫与当前 用户情境相称(fit)。因此，当Debbie在会议室中时，来自683-1556的 呼叫(其本身仅提供了用于对其进行处理的有限指导)被变换成来自用户 Debbie的老板的呼叫。规则也可以提供并操纵其他信息，例如用户和谁在 一起、呼叫的主题、用户当前在写的文档等等。这些多提供和得出的断言 一起使呼叫与用户的当前商业和/或社交情境相称。
这种相称提供了一种基础，其他规则可以藉由该基础来决定如何处理 呼叫。图23提供了这种类型的规则相称的示例。在该示例中，情境是由 用户在哪里、他/她在做什么以及当前时间来描述的。这被图24扩展，在 图24中，定义了呼叫者和用户之间的关系。注意，在图24中，在关系类 别中存在归类，使"老板"被归入类别"职员"等等。并且最终，由前述 两个界面所描述的具体情境中的呼叫所要求的动作被选择，如图25所 示。
此外，图32示出了至少一个规则分配代理3260和至少一个冲突解决 代理3270，这些代理合作以如上所述地选择可用于具体情境中的呼叫的一 个或多个规则中最适当的规则。如果发现规则的情境和由图23、图24和 图25的GUI所建立的情境中的呼叫，则如上所述，执行由图30的单选按 钮所选择的动作。
或者，可以通过呼叫控制策略来决定用户的可用性，如申请人的于 2003年8月1日递交并通过引用结合于此的美国序号为10/631,747的共同 未决申请"Generation of Availability Indicators from Call Control Policies for Presence Enabled Telephony System"中所描述的
a) 可由用户来创建规则，这些规则中并入了情境特征以描述可用 性，并且作为响应而生成模糊可用性的指示符。这些规则与确定呼叫 处理建议的规则一起在用户规则分配代理(URA)(未示出)中被执 行。
b) URA中决定对呼叫的具体处理的规则被扩展，以给出对这些决定 所指示出的可用性的指示。因此，将呼叫引导至用户的规则将显示
29"可用"，将呼叫引导为远离用户的规则将显示"不可用"，并且询 问用户的规则将显示"未作决定"。
c)冲突解决(CR)代理3270被修改，以结合对呼叫处理的具体决定 而从所生成的模糊可用性的指示符来生成可用性的清晰指示符。CR 代理接受具体呼叫处理规则的决定作为限定(definitive)。在这些规 则无法作出决定的任何情况下，CR代理合成(compose)模糊指示符 以产生清晰指示符。
在任何情况下，例如通过用户的当前情境和呼叫信息来建立情境感知 型规则，这些规则将基于与呼叫相关联的情境来决定对呼叫的处理。
现在返回图25，在一些实施例中，对在给出当前情境的情况下如何处 理呼叫的选择被呈现给用户。在这些选择中有a)"在屏幕上通知我"和 b)"询问呼叫者要做什么"。在当前讨论的实施例中，可在图33中看到 选择a)的结果。这是将被呈现给用户以允许他/她对处理呼叫的各种方式 作进一步选择的选择框。尽管在这里将其示出为文本屏幕表示，但是通过 语音接口来提供这种选择在本领域中是广泛已知的。申请人的于2003年2 月27日递交的美国序号为10/375,439的共同未决申请"Bimodal Feature Access For Web Applications (对Web应用的双模特征访问)"呈现了一种 非限制性装置，通过该装置，可以从文本或语音接口来进行这种选择，该 装置具有用于得出这两种接口的公共源。图33是这种通知的一个非限制 性表示。
在当前讨论的实施例中，图25的选择b)指定将与选择a)对用户 所作的分类相同的分类的呼叫者作出宣告。可以作出的选择的示例是 1)去往用户语音邮箱，2)在不挂机的情况下等待用户，3)去往用户助 理等等。
这些宣告被发送，以使得用户或者呼叫者可以选择动作。此外，这些 宣告可由消息来补充(即，进一步的宣告)，这些消息可被发送给用户、 呼叫者或者由用户指定的某一其他目的地。这些消息可以具有多个目的。 例如，可向用户播放消息以提供他/她正在被转发到地方和为什么被转发的 细节。其次，可以向用户播放消息以提供对情境的描述，在该情境中，呼
30叫被转发给他/她。如果用户已经决定将呼叫转发到除了他/她自己之外的 目的地，例如同事或者助理，则可以提供消息以警告目的地用户注意呼叫 的目的。这种便利在以下方面对语音邮件是有用的可以将语音邮件与提 供语音邮件的情境的消息一起存储。在其他实施例中，消息可被发送到数 据库，在此处该消息可作为用户日记或其他应用的一部分而被稍后使用， 以向用户提供他/她的交互历史(这将在以下更详细地描述)。
在一些非限制性实施例中，可由图33和图34的GUI来提供这种便
利。同时，图23、图24、图25和图26的GUI提供了为特定情境中的动 作设置规则的手段。具体而言，图25的UI允许选择特定动作。在当前实 施例中，在图25的GUI中对特定动作的选择使得至少一个另外的GUI被 呈现给用户和/或呼叫者，例如图33和图34的GUI中的一者或两者。
图33的GUI将直接遵循来自图25的GUI的规则编程顺序。照此，用 户可以指定消息，该消息可针对指定情境中的呼叫而被发送到呼叫者。用 户可以可选地选择文本消息和语音消息中的一者或者两者。点击多媒体文 件框将允许用户a)录制语音宣告，或者b)从文件系统(本地文件系统 或者网络文件系统)中选择多媒体文件以作为宣告而呈现给呼叫者。点击 文本框将a)输入具体文本消息，或者b)从文件系统(本地文件系统或 者网络文件系统)选择文件。可以选择这些选择中的任一者、两者，或者 都不选择。
例如，可以发送具有以下形式的消息
"Sandy, Acme问题已变得非常紧急。我将把你转发到我的同事 Carla，我已向其简要地说明了 Violet发生的事情"
可以每次一个地输入用于呼叫者的多个消息，直到用户选择了 GUI上 的完成按钮为止，此时，顺序将被移到下一步。
在用于呼叫者的消息已被选择之后，顺序可移到图34的GUI上。利 用该GUI，用户可以选择试图用于接收侧的消息。如图33的前一 GUI — 样，用户可以选择语音和/或文本消息来递送。但是，对于该GUI，提供了 用于该消息的不同目的地的可能性。如图34所示，这些目的地是 活跃设备； 偏好的设备；
曰记；和
被转发的设备
这些不同的目的地识别去往接收侧的消息可以提供的多个目的。现在 根据非限制性实施例来描述这些目的地中的每一个。
活跃设备是用户当前正在其上通信的设备。在这些实施例中，用户可 能是活跃的但是想知道在特定情境中何时从呼叫者接收到了消息。利用该 知识，用户例如可以调整他/她的优先级，以便他/她可以关注该情境中的 主题。因此，例如，去往接收侧的消息可以具有以下形式
"来自Doris Leafloor的关于Acme项目的呼叫已被发送到语音邮箱" 或者
"来自Debbie Pinard的呼叫已被转发给部门助理Amanda Slack"
在每一种情况中，己经警告用户注意将允许他/她调整他的优先级的可 能重要的消息。
另一替代是偏好的设备。例如，可以给予用户选择他希望在上面接收 消息的设备的选项，该设备不必是活跃设备。因此，偏好的设备将是允许 用户在稍后的时间接收消息的设备或者比他的活跃设备处于更少闯入的格 式。例如，这可以是电子邮件地址、能够接收电子邮件和/或文本消息的设 备、由于稍后递送的语音邮箱或者用于更少闯入的宣告的即时消息(IM) 地址。可在方便的时候检查发送到用户的语音邮箱的消息，以使得用户可 以获悉呼叫者何时或者出于什么原因而试图联系他/她。利用IM地址，消 息可以在客户端中累积，其中该客户端是当用户可以从紧急任务暂时转移 他/她的注意力时他/她可以关注的客户端。因此，用户可以维持对紧急任 务的紧密关注，而同时获得对请求优先级的其他任务的感知。
选择日记目的地将使得向数据库发送消息，在该数据库处，这些消息 稍后可被其他应用出于其他目的而访问。在一些实施例中，图1的元组空 间3220可以包括该数据库，而在其他实施例中，网络数据库可以包括该 数据库。在这些实施例中，网络数据库可以是Exchange服务器，该 Exchange服务器可以保存供其他应用使用的数据。由于日记应用可以提取消息并将其以各种格式呈现给用户，因此在该示例中使用名称"日记"。 例如，日记应用可以呈现按呼叫者、接收的时间、呼叫的主题等所索引的 消息。利用这种便利，用户可以获得对访问他/她的尝试的认识和感知和他 /她的关注。用于可以在设置他/她的优先级时考虑该信息。
被转发的设备目的地指的是所选择的策略将把呼叫引导至的设备。例 如，用户可以偏好将呼叫引导至同事、助理、他/她的语音邮箱等。在这些 情况下，希望向呼叫的目的地提供说明消息。在同事或者助理的情况下， 他们将接收对其他人的呼叫，因此在他们的头脑中可能不是最重要的。因 此，该消息可以提供初始说明，该说明将使得他们能够更有效和高效地处 理呼叫。例如，可以存在以下种类的消息
"Beverly,这是来自Eliana的消息，我将把来自Aurora的关于Acme
专利问题的呼叫转发给你。请提醒她注意修改后的建议"。
在相同的方式下，用户可以选择将呼叫发送到语音邮箱。该宣告将提 供对呼叫目的的快速指示。与上面所述的日记应用类似，文本消息可以使 得语音邮箱能够通过呼叫者、时间、主题等来排列宣告。
与用于呼叫者的宣告一样，利用该窗口可以输入多个宣告。在选择图 34的完成按钮时，该过程将结束。
规则分配代理3260和冲突解决代理3270将合作，以选择可用于具体 情境中的呼叫的一个或多个规则中最适当的规则。这些代理将经由元组空 间3220来命令SIP代理3210 (或者图2的PBX 26)执行什么功能。在一 个非限制性示例中，可以通过与在与图33的GUI交互期间所指示的设备 协商会话来递送SIP消息。随后，将以适合于每个设备类型的手段通过 SIP媒体协商来递送消息(不管是语音、文本还是媒体宣告)。例如，IM 客户端可以直接接收文本，但使得语音媒体可以作为接收者可以选择稍后 打开的附件而被呈现。对于发送到电话、语音邮箱或者其他语音设备的文 本消息，可以将文本至语音转换器引入到服务中。这些递送方法中的每一 个的细节对本领域技术人员是已知的。
允许使用文本标记的文本编辑器是已知的，标记能够提供诸如选择列 表、单选按钮、滑动块等的特征。在一些实施例中，在文本消息中使用这些特征将提供呼叫者、同事等的能力和如何处理呼叫的选择提供给用户。 此外，例如，可以允许发送经标记的HTML页面的服务器接收其中已由用
户指示出选择的HTML页面，并且提取用户的选择。因此，文本消息的形 式可以是可以与供应服务器处的CGI程序、小服务程序(servlet)等进行 交互以实现选择的HTML页面。例如，用户可以向呼叫者道歉并提供能够 接听呼叫的其他同事的列表。
使用标记还提供了一种机制，利用该机制，变量值可被编程到上面所 述的宣告中。例如， 一些宣告使用呼叫者的名字、呼叫被转移到的人的名 字等等。变量可被置于经编程的宣告(文本宣告、口头宣告等)中，而非 单独对这些名字编程(如果策略基于诸如同事之类的类，则这种编程将是 冗长的或者不可能的)。这些变量可以使用作为断言而存储在元组空间中 的数据。例如，在上面使用的宣告示例"来自Debbie Pinard的呼叫己被转 发给部门助理Amanda Slack"中，该宣告可被编程为"来自[呼叫者]的呼 叫已被转发给部门助理[当前秘书]"，方括号中的元素被解释为变量，这 些变量的值可被从元组空间中的断言中获得。
在一些实施例中，用户可以录制可被呈现给呼叫者和/或接收侧上的另 一方的消息。实际上，在一些情境中，在用户的语音中呈现消息可能是希 望的，因为其可以加到客户值上。例如，信任是商业关系的不可或缺方 面。如果同事或者客户觉得他们的努力被忽略或者轻视，则容易失去信 任。但是，存在许多示例，在这些示例中，商业人士将不得不关注紧急问 题，而在当时暂时让其他事情自然发展。这产生了不希望的可能性如果 关注其他事情的同事和客户的呼叫始终被发送到语音邮箱，则他们将觉得 他们的努力已被轻视。因此，提供对当前紧急情况的说明的用户语音的声 音将使得他们相信他们的努力仍然是重要的。通过向他们提供迫使作出优 先级选择的当前情形的感知，能够维护信任，这例如在商业情境中是必不 可或缺的，并且对用户语音的使用显示出提高信任的私人意识。
现在转到提供了交互式消息的实施例，有许多这样的情形其中，由 无线通信设备所提供的连通性对于重要合作是必要且有用的，但可能产生 社交困难(social awkwardness)的情形。前面所述的实施例允许呼入被置于情境中，以査看这些呼入是否足够紧急以致于要终端用户正在做的事 情。但是，即使是足够重要的呼叫也可能产生社交困难情形。例如，用户 可能正在与重要来访者和公司行政人员的会议中。答复和参与无线电话呼 入可能被认为是无礼和欠考虑的。因此，用户将经常把他们的手机置于振 动警告模式，以使得这种警告不会打扰会议。但是，这种解决方案具有有 限的实用性，尤其在结果是会议参与者将手机放到他/她的耳朵上并且迅速 离开会议室同时向受话器嘀咕着什么的情况下。这可能是非常破坏性的并 且可能对所有入会人员是难以接受的。因此，现在描述的实施例提供了一 种方式来以无声和谨慎的的方式处理这种呼叫。
如上面所讨论的，所选择的情境感知型宣告(即，消息)可被提供给 呼叫者。此外，通知可与各种处理呼叫的选项以及消息一起提供给用户。 至此，已描述的实施例提供了单个通知和选择。但是，在其他实施例中， 多个通知可被提供给用户，其中与宣告相关联的每个动作利用一组新的动 作选项来触发新的通知。这可以被无限期地执行，或者直到所选择的动作 产生与呼叫的处理有关的最终消息和最终决定为止。
例如，用户可以选择使他的设备被警告以注意呼入，从而呼叫可以被 答复。但是，在这些实施例中，可能将通知和呼叫一起提供给用户，该通 知将包含与动作相关联的多个可能消息。这些可能被配置为给予客户如下 能力以无声且比现在的可能方式更加谨慎的方式来接听呼叫者并与他交 互。
作为这些实施例的示例，可以在用户的屏幕上向他/她呈现无声警告 (振动)和各种选项。这些选项可以包括与各种动作相关联的各种消息。 这些可以包括如上所述的标准的"我现在繁忙"和发送到语音邮箱的选 项。但是，其还可以包括答复呼叫和选择选项(该选项向呼叫者提供消息
(例如，预先录制的消息)以宣告"我现在在开会，呼叫是关于什么") 的选项。希望呼叫者简要地说明呼叫的目的。同时，将向用户呈现同一组 宣告和选项或者基于情境和用户先前选择的选项来选择的新的一组。新的 一组选项可以包括诸如所期望的"请在我的语音邮箱中留下消息"、"请 告诉我更多"、"在我离开房间时等待一会儿"等项。这些交互的持续时
35间(即，宣告和选项的轮数)和所呈现的可能选项的深度没有固有限制， 其可以是任何合适的大小。
如前所述，可以使用两种类型的系统来呈现交互式选项。在一种情况 中，相同的选项可以用于所有的轮。也就是说，这些选项将保持活跃，直 到选择了指示不再需要选项的选项时为止。诸如"发送到语音邮箱"和 "不在需要选项"之类的选项是这种类型的。另一种情况允许选择以下选 项生成新的一组选项以补充以前的选项。这些都可以相同方式来实现。
图32示出了用于创建在本公开中的前面已经描述了的情境感知型宣
告的代理的系统。在操作中，代理通过将断言写入到元组空间3220中来 进行通信并协调它们的行为。元组空间3220因此将被加载与以下相关的
多组结果确定用户情境、使呼入与用户情境相称和选择可用于处理这些
呼叫的特征。这些规则对于被写入到元组空间3220中的断言是敏感的。 这些规则的输出可以是被写入到元组空间3220中的其他断言。因此，触 发一个情境规则可以使得触发将断言写入到元组空间3220中，这可以引 起其他断言的写入，这些其他断言可以触发基于第一断言而从基于规则的 推理得出的一系列断言的写入。
与上面描述的情境实施例类似，用户可以从先前所述的向呼叫者发送 宣告的能力得出的通知中选择选项。该实施例中所描述的交互式选项通过 允许可能在这些选项下动作成为另一组选项而对此进行扩展。这些选项将 提供先前已描述过的一组交互式选项。
因此可以看出，在关于情境的推理方面，向呼叫者发送交互式宣告的 能力类似于与就情境进行推理有关的系统的功能。 一个规则可以触发另一 规则。但是，在对呼叫者情况的交互式宣告中，将通过宣告的手段在呼叫 者帮助的情况下进行交互。
现在转到宣告的源，可按之前所述的各种媒体的方式来将这些宣告发 送给呼叫者。但是，对于这里已经描述的交互的类型，希望这些宣告在用 户的语音中。可以通过用于将来的注册过程来提供这种能力，在该注册过 程中将要求用户说出宣告所需要的必要短语。这类似于公知的语音邮件服 务的注册过程，在该过程中要求用户说出各种短语。可以提供一组标准录
36制短语作为在用户无论因为什么原因而未能提供录音的情况下的缺省措 施。
本领域技术人员将会认识到，在一些实施例中，可以利用预编程的硬 件或固件元件(例如，专用集成电路(ASIC)、电可擦除可编程只读存储
器(EEPROM)等)或者其他相关组件来实现SIP代理3210、元组空间 3220、系统管理代理3230、关系分配代理3240、情境代理3250、规则分 配代理3260和冲突解决代理3270的功能。在其他实施例中，可以利用计 算装置来实现SIP代理3210、元组空间3220、系统管理代理3230、关系 分配代理3240、情境代理3250、规则分配代理3260和冲突解决代理3270 的功能，该计算装置可以访问存储了用于计算装置的操作的计算机可读程 序代码的代码存储器(未示出)。计算机可读程序代码可被存储在固定 的、有形的并且可由这些组件直接读取的介质(例如，可移动盘、CD-ROM、 ROM、固定盘、USB驱动器)上，或者计算机可读程序代码可被 远程存储，但可经由调制解调器或通过传输介质而连接到网络(包括但不 限于因特网)的其他接口设备来传输到这些组件。传输介质可以是非无线 介质(例如，光学或模拟通信线路)或者无线介质(例如，微波、红外、 自由空间光学或其他传输方式)或者其组合。
本领域技术人员将会认识到，还存在可用于实现实施例的更多替代实 现方式和修改，并且以上实现方式和示例仅仅是对一个或多个实施例的说 明。因此，范围仅由所附权利要求来限制。
权利要求
1. 一种提供情境感知型宣告的方法，包括以下步骤-应用情境呼叫处理规则以确定呼入的当前情境；以及-提供至少一个情境感知型宣告，用于提供与所述当前情境相关联的信息和呼叫信息。
2. 如权利要求1所述的方法，其中，所述呼入是从呼叫者到用户的，并且所述提供至少一个情境感知型宣告的步骤包括向所述呼叫者、所述 用户和第三方中的至少一个提供至少一个情境感知型宣告。
3. 如权利要求1所述的方法，其中，所述应用情境呼叫处理规则以确 定当前情境的步骤基于以下各项中的至少一项呼叫者和用户之间的关 系、所述用户的时间表、所述用户的位置、所述用户的活动、呼叫类型和 所述用户的偏好。
4. 如权利要求1所述的方法，其中，所述至少一个情境感知型宣告包 括用于处理所述呼入的至少一个可选选项。
5. 如权利要求4所述的方法，其中，所述至少一个可选选项包括请求与所述呼入的所述情境相关联的信息。
6. 如权利要求4所述的方法，还包括以下步骤接收对所述至少一个可选选项的选择，并提供用于处理所述呼入的至少一个其他可选选项。
7. 如权利要求4所述的方法，还包括以下步骤将所述呼入转发到语音邮箱、数据库和第三方中的至少一个，并且其中，所述至少一个可选选 项包括与所述呼入的所述情境相关联的信息。
8. 如权利要求1所述的方法，还包括以下步骤检索所述情境呼叫处
9. 如权利要求1所述的方法，其中，所述情境呼叫处理规则还基于 结合对呼叫处理的具体决定而从模糊可用性的指示符生成的可用性的清晰 指示符。
10. 如权利要求1所述的方法，其中，所述至少一个情境感知型宣告 包括至少一个变量值，所述至少一个变量值是通过处理所述当前情境和所述呼叫信息中的至少一个而确定的。
11. 一种用于提供情境感知型宣告的系统，包括-呼叫管理实体，用于管理呼入和所述情境感知型宣告； -可由所述呼叫管理实体访问的共享存储器空间，用于存储情境数 据；以及-耦合到所述共享存储器空间的至少一个代理，所述至少一个代理用于向所述情境数据应用情境呼叫处理规则以确定呼入的当前情境；以及向所述呼叫管理实体提供至少一个情境感知型宣告，用于提供与所述当前 情境相关联的信息和呼叫信息。
12. 如权利要求ll所述的系统，还包括用户界面，用于允许用户与所述共享存储器空间的交互。
13. 如权利要求12所述的系统，其中，所述用户界面能够允许用户设 置所述共享存储器空间中的当前情境。
14. 如权利要求12所述的系统，其中，所述用户界面能够允许用户对源自所述呼叫管理实体的情境感知型宣告进行应答。
15. —种在其中实现计算机可读代码的计算机可读介质，所述计算机可读代码用于控制计算机来执行以下操作-应用情境呼叫处理规则以确定呼入的当前情境；以及 -提供至少一个情境感知型宣告，用于提供与所述当前情境相关联的 信息和呼叫信息。
全文摘要
本发明公开了提供情境感知型宣告的方法。该方法包括应用情境呼叫处理规则以确定呼入的当前情境；以及提供至少一个情境感知型宣告以提供与当前情境相关联的信息和呼叫信息。
文档编号H04M1/64GK101505340SQ20081018406
公开日2009年8月12日 申请日期2008年12月15日 优先权日2007年12月14日
发明者庄·蒂姆·崔恩, 托马斯·A·格雷 申请人:米特尔网络公司