CN101142549A - 用于首选项应用程序安装和执行的系统和方法 - Google Patents

Abstract

本系统和方法揭示了一种用户个人化计算机功能的系统。向终端用户提供工具，以例如通过使用多个简单的IF－THEN命题逻辑来容易地编写丰富而复杂的首选项。首选项然后被转换成查询，并有效地执行于结构化数据上。被满足的首选项随后执行诸如提供通知或将数据存储于某一文件夹之类的动作。此外，根据本发明的一方面，数据、逻辑、事件都被模式化，从而允许应用程序组件和跨应用程序之间共享数据。

Description

用于首选项应用程序安装和执行的系统和方法

相关申请交叉参考

本申请要求通过被引用而整体上结合于此的、2003年10月24日提交的、题为“用于首选项应用程序安装和执行的系统和方法”的美国专利申请序列号10/693735的优先权。

技术领域

本发明总地涉及计算机系统，尤其涉及一种用于使计算机系统个人化的系统和方法。

背景

计算机以及计算相关技术的用户典型地被分成两种不同的类别，即高度熟练的和博学的个人以及其它人。熟练的和博学的个人知道如何以丰富的方式使用计算机，并且使它们服从于他们的愿望以便塑造程序和促进丰富的和有价值的行为。其余的计算机用户受熟练的和博学的个人的支配，因为他们被拒绝容易地或便宜地访问知识、信息或使得计算机服务于他们的需要。

当技术克服了这些对访问的屏障中的一些时，在计算中产生了重大突破。在大型机世界中，计算机太昂贵，以至于只有最大的公司才能负担得起。小型机的出现以及随后的个人计算机(PC)克服了成本障碍，使得计算机可用于小型企业和个人。在1980年代，编程者努力地构建图形用户界面(GUI)应用程序。没有丰富的和相容的GUI，编程者不能够为PC用户构建有价值的应用程序。Visual Basic革命以及对控件和基于事件的GUI构造的使用，使得应用程序开发者能够容易地构建丰富的应用程序。接着，建立了一种良性循环，其中更多的终端用户能够开发这些应用程序。在1990年代，终端用户努力地克服缺乏对信息的访问的问题。因特网的发展改变了这种空白，使得几乎所有有价值的信息都可由任何人通过浏览器来访问。然而，仍然存在许多需要克服的障碍。

传统的计算不是针对个人的。所谓的个人计算机并非是真正的“针对个人的”。事实上，本地盘上存储的数据是针对个人的。然而，机器的行为，即代表用户执行的动作几乎是对于成百上千的用户来说都是相同的。尽管拥有非常强大的通用计算机，平均用户把它作为静态工具、用作通信终端、用作搜索入口点、用于执行某些预先录制好的大量销售的应用程序，但是不能在真实世界的意义上进行任何“个人化计算”。当前的应用程序中的个人化能力仅仅触及了可能的和所希望的事物的表面，而并不周详。

此外，传统的计算并非是自动的，而是手工的，要求用户作出判决，并在适当的时间进行动作。考虑大多数典型的计算机用户的日常惯例。其中，终端用户收集信息、对通信起反应、发起或回答通信、以及组织信息。计算机改进了人们之间的通信，并改进了对信息的访问。然而，计算机对于减轻终端用户作出判决并在正确的时间进行动作的责任并没有作出什么贡献。

进一步地，传统的计算并非是涉及上下文环境的。计算机软件典型地提供相当静态的、且与用户的实际上下文环境无关的选项设置。

所需要的是一种真正个人化的计算机系统，即一种意识到终端用户的需要和偏好，以那些需要以及用户上下文环境支配的方式进行动作的系统。此外，计算机系统和软件应该向每个终端用户提供个人助理，用于对一个或多个终端用户收集和筛选所关心的信息，以及自动地以用户规定的方式对该信息作出反应。

发明概述

下面给出本发明的简单概述，以便提供对本发明的某些方面的基本理解。该概述并非本发明的广范围的综述。并不意图标识本发明的关键/重要的元素或描绘本发明的范围。其唯一目的是以简单的形式给出本发明的某些概念，作为后面将给出的更为详细的描述的序言。

这里揭示了一种信息代理系统、应用程序和方法。信息代理系统提供用于执行信息代理应用程序(这里有时也称为IA应用程序)的平台。IA应用程序于是可由终端用户编程，并用作为终端用户执行助手或代理。代理于是可极大地增强终端用户个人生产率，结合桌面应用程序和所有个人通信媒介(如移动电话机、寻呼器、PDA……)。

信息应用程序系统的中心是数据的模式化。模式化是以已知的和已经定义的模式使数据结构化，使得多个应用程序能够彼此识别和交互。信息属性、信息事件以及判决逻辑都可以被模式化。模式化的信息属性指的是作为终端用户应用程序的基础的数据(例如电子邮件、人、组、位置……)。信息属性可以被模式化来允许多个不同的应用程序之间对数据进行一致的解释。信息事件提供挂钩以附加程序逻辑。这些事件是高级的，且依附于信息流，以便于没有经验的终端用户理解。事件也可被模式化。此外，判决逻辑可被模式化。由于终端用户并非是受训练的开发者，因此，期望以传统编程语言编写的程序是不合理的。相反，可向终端用户提供模式化的逻辑构件块(如IF-THEN命题)，从而他们能够通过以简单而丰富的组合将它们缝合在一起来编程。数据的模式化、信息挂钩(事件)以及终端用户编程能力以通过终端逻辑耦合和协作的应用程序的丰富体系给予终端用户极大的价值，允许新手终端用户变为系统综合者。

此外，根据本发明的一方面，信息应用程序系统包括灵活的执行引擎，能够编译和执行重型和轻型信息应用程序。重型应用程序包括那些通常运行于高端服务器上并尤其要求高吞吐量和扩展性的应用程序。轻型应用程序是那些通常在诸如个人计算机之类的较小系统上运行并要求低等待时间、小的数据库覆盖区(footprint)以及小的工作集。在较小的应用程序中，等待时间与吞吐量之间的折衷是与较大的服务器应用程序相反的。因此，本发明的执行引擎是灵活的，它能够通过进行折衷来强调某些系统要求(例如低等待时间、小数据库覆盖区……)来在多个不同的应用程序平台上编译和执行应用程序。

根据本发明的另一方面，以一次一个的方式开发终端用户首选项或规则，但成组执行。一次一个编程模型是这样一种模型，它对于开发者来说是最为自然的，允许开发者对一个首选项规定一个事件。然而，根据本发明，系统检索一次一个程序声明，并创作以面向集合的方式执行的条件类查询，从而采用类似于索引和复本消除技术。其好处在与以非常有效的方式评估首选项，同时开发者和终端用户以一次一个的方式使程序概念化或编写程序。

根据本发明的另一方面，提供一种新的应用程序安装系统和方法。在传统系统中，应用程序安装涉及数据库对象、表和存储的过程的增生。在某些示例中，应用程序创建完全新的数据库。本发明通过提供一组基表来简化和加速应用程序安装。为了安装应用程序，系统简单地更新基表。这可通过按照数据来存储程序动作、条件、事件和过程来实现。例如，就过程而言，可以按照存储于数据存储器中的一卷文本来创建。为了运行这些过程，程序文本可被简单地从数据存储器中拉出并执行。

根据本发明的又一方面，系统可支持存取器常量，以允许条件/动作跨不同的信息域来关联信息。存取器常量便于不同域之间的信息交换或数据共享。例如，可定义存取器常量MyFamily，使得存取器函数能够通过查询电子邮件应用程序或日程表应用程序存储的数据来确定MyFamily的成员。模式化逻辑和存取器的组合是有益的，至少是因为它使得非编程者能够编写有效的跨域的查询。此外，与相对较少数量的存取器限制组合的相对较少数量的条件类使得大量的感兴趣的条件被采用，而原先这些条件可能未被应用程序开发者提供。

根据本发明的又一方面，用户定义的首选项可被扩展以允许应用程序之间的关系。在很大程度上，IA应用程序的度量是由呈现给用户的能力来确定的。因此，IA应用程序可扩展的程度可由新的条件和动作可用于用户在现有的应用程序的上下文环境中定义新的首选项的程度来确定。应用程序扩展性主要针对于使得在应用程序被安装后能把新的条件和动作添加到应用程序，而不用原应用程序的作者的进一步干涉。因此，终端用户不用开发者输入就能够创建利用不同应用程序提供的条件和动作的首选项，从而允许了应用程序之间丰富的关系。

进一步，本发明的系统支持信息代理应用程序。根据本发明的一方面，这样一种应用程序可与使文件夹、数据容器或数据存储器和相关文件系统(例如分级系统、通过任意的或明确的关系而相关的文件)提供的其它数据组织系统个人化有关。个人化文件夹由终端用户规定的逻辑或首选项来定义和控制。因此，终端用户能够定义根据事件的发生控制文件夹的内容的动作。在本发明的一个方面中，事件对应于文件夹数据中的变化(例如文档添加、删除或修改)。对于本概述来说，首选项(例如条件、动作)可被归结为三种类别：代表用户采取动作的首选项(例如将涉及费用报告的电子邮件移动到类似名称的文件夹)，控制文件夹的内容的首选项(例如将过去两星期收听的爵士乐保存于当前爵士乐文件夹中)，以及前两者的组合(例如将少于某一货币量的所有费用报告存储于认可的文件夹中，并向终端用户发送电子邮件以向他通知该动作)。

根据本发明的又一方面，可使用活动文件夹来采用工作流式的活动。在此，利用首选项的终端用户可规定多步骤任务或工作片段要通过文件夹中的项目来标识。接着可对文件夹项目采取动作，以完成任何或工作片段。

根据本发明的一方面，也可使用大事记文件夹。大事记表示与系统的用户的上下文环境相关的上下文环境信息。根据本发明的又一方面，大事记可存储于数据存储器中，逼供可由终端用户自由访问。从而，终端用户能够对例示数据保持控制，并根据它来编写首选项。例如，用户能够允许工作组中的每个成员看到关于某一股票价格的历史信息，但是可能希望限制诸如他们是否位于办公桌前或在开会之类的上下文环境信息。

为了实现上述和相关方面，这里连同下面的描述和附图一起描述了本发明的某些说明性的方面。这些方面指示出可实施本发明的各种方式，所有这些都被本发明所覆盖。通过下面的详细描述，连同附图一起考虑，本发明的其它优点和新颖特征将变得显而易见。

附图简述

图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是本发明可与之交互的示例性计算环境的示意框图。

详细描述

现在参考附图描述本发明，附图中，相同的参考标号表示相同的元素。然而，应该理解，附图及其描述不意图将本发明限制于所揭示的特定形式。相反，意图是覆盖落于本发明的要旨和范围之内的所有的修改、等价物和替代物。

如该申请中所使用的那样，术语“组件”和“系统”意图涉及计算机相关的实体，任一种硬件、硬件和软件的组合、软件或执行中的软件。例如，组件可以是但不限于运行于处理器上的进程、处理器、对象、可执行的、执行线程、程序和/或计算机。出于说明的目的，运行于服务器上的应用程序和服务器都可以是组件。一个或多个组件可驻留于进程和/或执行线程中，组件可位于一个计算机上和/或分布于两个或多个计算机之间。

如这里所使用的那样，术语“推断”一般指的是从通过事件和/或数据捕获的一组观察值中推出或推理系统10、环境、和/或用户的状态的过程。例如，可采用推断来识别特定的上下文环境或动作，或可生成状态的概率分布。推断可以是概率性的，即根据对数据和事件的考虑对所关心的状态的概率分布的计算。推断还可涉及用于从一组事件和/或数据组成更高级的事件的技术。这种推断导致从一组观察的事件和/或存储的事件数据中构成新事件或动作，而不管事件是否以紧密的时间邻近性相关，以及事件和数据是否来自一个或若干个事件和数据源。

信息代理平台

最初转向图1，例示出根据本发明的一方面的信息代理系统100。信息代理系统100包括应用程序编程接口(API)110、编译器120、事件组件130、上下文环境分析器140、模式化数据存储器150、首选项(preference)执行引擎160、动作组件170以及通知组件180。系统100提供一种便于各种信息代理应用程序的执行的平台。系统100可以是自主系统，或是一个更大的系统的一个组成部分。根据本发明的一方面，可在计算机操作系统采用系统100，其中可在多个不同的计算设备上采用操作系统，这些设备包括但不限于个人计算机和诸如电话机、个人数字助理(PDA)之类的移动设备。还可在服务器(如SQLServer、WinFS服务器)以及连同订阅服务一起采用系统100。因此，系统100可用于在各种客户端、服务器、以及client-server-cloud服务(例如Outlook、Exchange和Hotmail)中提供信息代理能力的产品和服务之间提供协同。

API 110包含于系统100中，以便于与系统100的交互。API 110可由开发者用于配置信息代理系统100中的各种组件。此外，API 110可用于从运行于系统100上的信息代理应用程序可用的一个或多个事件源和/或当前的用户上下文环境中构造多个事件。进一步，API 110可用于回顾存储于数据存储器150中的逻辑模式(logic schema)，并将首选项写入数据存储器150。应理解，通过阅读本说明书，落于本发明的范围之内的API 110的许多其它用途将变得显而易见。

数据存储器150是用于模式化的数据的丰富的结构化的存储器。数据的模式化，即把数据结构化成已知的和规定的型式，这对于本发明来说是尤其重要的，因为它允许多个应用程序交互。如将要进一步详细描述的那样，数据存储器150可由信息代理应用程序使用，尤其是存储与应用程序相关联的数据，例如事件和首选项的表。此外，虽然把数据存储器150例示为包含于信息代理系统中，但是应理解，数据存储器150可与系统外部的组件进行交互。

编译器120也包含于系统100中。编译器120用于对信息代理应用程序进行编译。特别地，编译器120对开发者模式(schema)和终端用户首选项进行编译。根据本发明的一个方面，编译器促进了将模式和终端用户首选项翻译成用于存储于表中的数据，例如存储于数据存储器150中。

系统100还包括事件组件130。事件是向首选项评估发起和提供信息的触发机制。事件源自于事件源，事件源可以是按照应用程序或数据的内部状态变化和/或世界中的外部变化。事件组件130可以捕获从应用程序通过API提交的事件，并开始首选项评估。例如，事件可由接收新的SMTP消息的简单邮件传输协议(SMTP)提供商、数据存储器150中的数据变化、操作系统动作、明确的用户动作、和/或其它首选项的动作提出。事件组件130还能够从第三方提供商以及从多个不同类型的源收集事件或接收事件，这些源包括但不限于：诸如因特网和基于网络的通信之类的通信、电话通信、以及软件服务、XML文件、应用程序和数据库。此外，事件组件130可以通过各种方法来监控和收集数据。收集数据的示例性方法包括但不限于：对文件添加监控目录、对某些类型的输入项(entry)检查系统和应用程序的日志文件、从应用程序捕捉告警、监控web网页、跟踪数据库表中的变化、以及评审由web服务提供的数据。

事件组件130还可采用各种不同的模型来收集数据。这些模型能够影响事件组件130每隔多少时间以及在什么情况下从各种事件源收集事件。

可以两种方式中的至少一种来向事件组件130通知或提供数据。事件组件130可等待要被“推入”或发送到它的信息，或者事件组件可以通过轮询源以及收集任何新的或更新的数据来从源“拉出”信息。例如，如果用户希望在每次所喜欢的新闻页面上的标题故事发生变化时被告知，则事件组件130可以被实现为例如监控该页面和搜索对标题文本的改变。当文本变化时，事件组件130能够提取新的标题数据，并将它提供给系统100，例如通过将它存储于数据存储器150中的事件表中。在上述的例子中，事件组件负责收集所需的数据，因为数据并不向采用推入方法的情况那样从事件源提供给事件组件130。

除此以外或作为替代，事件组件130可以根据计划或根据满足预定规则的事件的出现来获得用于系统100的事件数据。计划的事件组件130可以根据应用程序开发者实行的设置来定期地运行。计划的事件组件130可以起动运行，检索和提交新的事件数据，然后休眠，直到下一个计划的触发时间为止。事件驱动的事件组件130也能够通过连续运行来监控事件源。此后，当满足用于收集的特定规则的数据出现时，事件组件可收集或指示出事件的出现。可选地，事件驱动的事件组件130可仅响应于回调功能或某些其它的外部激励来运行。这种外部功能将确定是否有有效的数据以备收集，以及使用事件组件130作为收集这种数据的手段。一旦事件组件130从外部事件源收集了数据，它就能将数据写入事件表，在数据库150中保存时间表。

不管使用什么方法或系统来收集和/或聚集事件，应该理解到为了效率的目的可成批地写入和处理事件。如这里总体上定义的那样，一批可以是按照组来处理的一组数据(例如事件、首选项……)。组或批的大小可以由开发者在系统设置器件确定和指定，和/或可由用户通过例如控制面板来规定。

根据本发明的一个方面，上下文环境分析器140收集的信息包含由分析器确定的上下文环境信息。上下文环境信息由分析器140通过根据一个或多个上下文环境信息源(未示出)来鉴别用户的位置和注意状态来确定，如在说明书的后述部分中更为详细地描述的那样。例如，上下文环境分析器3122能够通过作为用户的汽车或移动电话机的一部分的全球定位系统(GPS)来精确地确定用户的实际位置。分析器还可采用统计模型，通过考虑诸如日子类型、一天的时间、用户的日程表中的数据以及关于用户的活动的观察资料之类的信息而收集到的背景估计和/或观察资料，来确定用户处于给定的注意状态中的可能性。给定的注意状态可随后用作用户定义的首选项的事件或条件。

首选项执行引擎160也可涉及动作处理。虽然首选项逻辑实际上仅产生一组结果，在这里这也可选地被称为是动作，因为这是这些结果的普通效果。采用首选项执行引擎160来执行动作，这仅仅是可执行动作的一种方式。动作还可由仅从系统100检索首选项结果并对这些结构起作用的应用程序来执行。作为系统100的一部分的执行引擎对动作的执行具有更多的主动代理的味道，而应用程序对动作的执行具有更多的被动判决逻辑的味道。因此，以与系统100相对于事件组件130为事件检索和处理提供主控服务相类似的方式，系统100可为检索和执行动作的应用程序动作处理器提供主控服务。此外，应理解到，根据本发明的一个方面，接近于数据的动作(例如将电子邮件移动到某一文件夹)可由执行引擎160与首选项评估以及同一处理的一部分同步地在系统100内执行。

系统100的首选项执行引擎160尤其处理或评估首选项。首选项是终端用户定义的规则，由事件的出现来触发。系统100可支持两种激活模型，同步和异步。在同步激活模式中，事件提交(event submission)和首选项评估之间有可忽略的延迟。也就是说，首选项评估可在对事件提交的响应被返回之前完成。相反，在异步激活模式中，在事件提交的完成和首选项评估的完成之间存在显著的延迟。例如，根据实施异步激活的一个方法，提交的事件被排队，直到它们被起作用为止。系统100可支持一个或这两种激活模型。此外，根据本发明的一方面，可根据包括但不限于批大小和可用于处理的时间在内的多个考虑事项，在批提交期间动态地选择同步或异步行为。首选项处理的另一个方面涉及隔离和处理边界。例如，处理与单个事件批(event batch)有关的首选项可以是可事务处理(transactional)的。可选地，许多事件批可作为一个处理单元(transactional unit)来一起处理。系统100可支持上述模型情况中的一个或这两种。此外，首选项执行引擎160应付事件提交和首选项处理的事务处理(transaction)范围。系统100可支持下面两个模型中的一个或两个。首先，事件提交和首选项处理可共享相同的事务处理(transaction)，从而可被一起执行。另外，事件提交和首选项处理可在不同的事务处理中发生。

根据本发明的一方面，执行引擎160和系统100能够支持轻型的和/或重型的信息代理或首选项应用程序。轻型的应用程序是那些要求低等待时间、小的数据库覆盖区(database footprint)以及小的工作集(working set)的应用程序。高吞吐量和扩缩性不是轻型应用程序的首要要求。重型应用程序是那些要求高吞吐量、扩缩性、高可靠性、严格正确性保证、可预测的应急恢复、以及便捷的可管理性的应用程序。低等待时间和资源消耗并不是重型应用程序应予最优先考虑的事。高性能服务器一般执行重型应用程序，而轻型应用程序通常在包括但不限于个人计算机和移动设备的较低性能的系统上采用。因此，执行引擎160必须能够区分重型应用程序和轻型应用程序，并作出改变，以便以对专门的应用程序类型(如高吞吐量对低等待时间)最为敏感的方式进行执行。一般来说，执行引擎将非常地与数据库覆盖区、组件激活中的等待时间、处理、存储器覆盖区以及不间断处理有关。重型应用程序的执行可能要求(1)分配大的数据库覆盖区，以便支持特别是多个数据库、表、视图、存储的过程、以及用户定义的函数；(2)用于事件收集、通知产生、以及通知分布的小的轮询间隔；以及(3)信息的批处理。轻型应用程序的执行的不同在于它们能够(1)以最小的存储器和数据库覆盖区来使用；(2)对事件收集、通知产生以及通知分布(如果允许的话)使用较大的轮询间隔；以及(3)以小的批量或单独地处理诸如事件之类的信息。此外，根据本发明的一方面，轻型应用程序中可不支持主控的事件提供商和某些通知分布，因为它们将要求连续地运行处理，这将会妨碍系统响应时间。然而，应理解，执行引擎160的灵活性在于根据可用的资源和技术状态，它能够支持应用程序“轻型”的逐步增加的变化。

应注意，系统100还包括动作组件170。根据对首选项的成功评估，首选项执行引擎160能够调用动作组件170来根据一个或多个有效的首选项进行某些动作。动作可影响数据存储器150(例如插入、删除或修改数据)和/或系统100内外的其它组件和系统。一个具体的动作类型是用户通知。因此，动作组件被例示为具有通知组件180。

参考图2，更为详细地例示出通知组件180。通知组件180包括格式化器272和递送协议274。通知组件180按照输入接收原始通知数据，输出最终到达用户设备(如计算机、PDA、移动电话机……)的格式化的通知。在通知组件180接收了原始通知数据之后，通知被转换成为目标设备格式化的可读通知，可能是以用户的首选语言，然后通过递送协议274发送到设备。内容格式化是由一个或多个内容格式化组件272处理的任务。内容格式化器272将打包成阵列的通知输入作为输入。对于标准递送来说，阵列中应当仅存在一个元素，它包含用于单个通知记录的信息。对于摘要递送来说，其中要求以单个消息将多个通知发送到订户，阵列中可具有多个元素，每个元素包含来自一个通知的数据。内容格式化器272随后使用包含于通知数据中的接收者信息(例如用于确定适当的格式化)对数据格式化用于显示。此外，如果采用摘要递送，内容格式化器272还负责适当地集合通知信息。在内部，内容格式化器272可使用任何适当的模式来对通知进行格式化。例如，这种模式可以是和采用基本串操作一样简单，或可以更为复杂，例如使用可扩展样式单语言(XSL)变换或ASP.NET翻译。当内容格式化器完成其任务时，它输出包含格式化的数据的串。该串与可被生成的某种通知标题信息一起传送到递送协议组件274。

通过递送协议274实现通知递送。当一批通知变得可用时，通知组件180读取通知中的订户数据，以确定正确的格式化。通知组件180然后能够利用递送协议274将通知发送到递送服务，例如.NET Alerts或SMTP服务器。更为具体的，当应用程序正在运行时，通知组件172能够读取每个通知以获得订户递送设备和场所。然后，分配器(distributor)将设备和场所的组合匹配到特定的格式化器对象，以生成最终的通知。通知本身可包含原始通知数据、在格式化时计算的数据以及内容格式化器272规定的文本的组合。这些选项允许专业的和用户友好的通知文本，以及包含Web链接和标记信息。

虽然系统100可处理内部通知(例如弹出通知)，但是系统100不必处理通知向外部第三方设备的最终递送。相反，系统可使用递送通道(未示出)，可把它看作为递送服务的管道，例如电子邮件网关或.NET Alerts服务器。具体来说，递送通道可由协议和终端地址组成。系统100可配置递送协议274来提供从通知组件180到将通知发送到接收者的外部递送系统的管道。通知组件随后可使用递送协议组件274将通知打包成协议分组，将通知发送到一个或多个递送通道。递送通道最后将分组呈现给外部递送服务，外部递送服务能够最终将通知发送到计划中的接收者。

信息代理应用程序

参考图3，根据本发明的一方面描述了信息代理应用程序300。应用程序300是系统100上的布署单元，并包括逻辑模式(schema)310、用户界面320、判决逻辑组件330、事件编程组件340、以及任务调度组件350。逻辑模式310定义了可由终端用户装配在一起的模式化逻辑构件块或模板。模式开发者负责构造逻辑模式310，默认行为，以及当异常应该发生时的行为。实际上，逻辑模式310限制了终端用户逻辑的实际表达力，从而使得未受训练的终端用户实际上“编程”应用程序变得切实可行。逻辑构件块可包括首选项类、一组条件类定义、以及一组可能的结果或动作。条件和动作可与相关的应用程序300的功能和/或用户上下文环境相关联。此外，应理解到，根据本发明的一方面，可使用XML(可扩展标记语言)来定义逻辑模式310。

根据本发明的一方面，模式逻辑310可定义两种类型的构件块：定义模板化的布尔逻辑功能的条件类，以及定义模板化的过程的动作类。首选项类是信息代理模式开发的单位。首选项包括一组允许的条件类(例如IsFrom(X)，IsTo(Y))和动作类(例如MoveToFolder(Z)、Delete())。此外，每个首选项与一特定的事件类或触发机制相关联，以发起动作(例如EmailEvent)。在规定了模式逻辑310之后，模式310可由编译器120编译，并存留于数据存储器150中的标准化的系统元表(meta-table)中。此外，存储的过程可在能够评估首选项的编译周期期间被创建。模式逻辑310和过程都可存储于模式化的数据存储器150中，用于稍候的存取访问和执行。此外，当用户试图规定首选项时，可把首选项与逻辑模式122比较以验证其形式一致性，然后将其存储于数据存储器150中，例如存储于一个或多个首选项表中。当适当的事件发生时，系统100能够确保通过执行所存储的在编译时间期间创建的过程评估适当的首选项。根据本发明的一方面，存储的过程可有效地以面向集合的方式一起评估多个首选项，采用类似于索引和复本消除的技术(下文描述)。

用户界面320向终端用户呈现首选项创作或编程界面。终端用户并非是受训练的开发者，因此标准的过程程序设计或脚本设计对于用户规定逻辑来说并非是可行的选项。因此，可以通过例如用户界面320，以点击和拖曳或复制和粘贴的方式向终端用户视觉上表示和呈现逻辑。应理解，用户界面320可以是应用程序300内的工具栏，或者是完全独立的图形用户界面(GUI)。此外，应理解，虽然将应用程序300例示为包含用户界面320，但是应用程序320并不必具有自己的用户界面用于定义首选项。应用程序可被设计成使用操作系统或专用用户界面来进行逻辑创建。

应用程序300还包含可由终端用户采用来产生首选项或各种功能的程序的三种组件：判决逻辑组件330、事件编程组件340、以及任务调度组件430。判决逻辑组件330使得终端用户能够定义判决逻辑(a/k/a终端用户逻辑)。应用程序然后能够允许通过定义的终端用户逻辑来控制各种判决。例如，终端用户能够规定是否、何时以及如何告警能够在屏幕上弹出并打断用户。应用程序还能够暴露出终端用户可对其附加判决逻辑的事件。例如，电子邮件应用程序能够无论何时新的电子邮件到达文件夹时产生事件。事件编程组件340允许终端用户附加首选项或规则，规定可根据例如消息的内容和用户的上下文而发生的行为。规则中的条件可访问来自其它应用程序的数据(例如活动目录，以检查发送者是否来自同一工作组)以及动作可根据本发明的一个方面影响其它应用程序450或产生另一事件。任务调度组件430使得终端用户能够向事件的出现附加特别的或预先规定的任务。例如，当新的用户抱怨发生时，终端用户可选择开始预先规定的工作流来处理该抱怨。

判决逻辑组件330允许终端用户通过将开发者提供的条件和结论模板组合来编写判决逻辑或终端用户逻辑程序。可使用“IF(条件)THEN(结果)”首选项或规则来规定判决逻辑。这种类型的逻辑特别适用于终端用户规定，因为即使完全没有编程经验的终端用户也能够容易地理解和创建这种规则。考虑下面的例子：IF(TheDogBarks)OR(TheBeeStings)THEN(IFeelSad)(如果(狗吠)或(蜜蜂叮咬)，则(我感觉不好))。该规则是非开发者甚至是小孩子就能够理解和表达的，只要给出正确的用户界面就行。这种类型的IF-THEN逻辑编程适用于终端用户规定，至少是因为它与人类的推理概念和语言通信相匹配。单个规则的语义是声明性的且是已知的，也就是说，当且仅当条件是真的，结果才是真的。此外，在活动上下文环境中运用首选项逻辑，这对于终端用户来说是直观的。结果变为采取动作而不是简单地声明真实性。例如，IF(TheDogBarks OR TheBeeStings)THEN(ThinkAboutRaindropsOnRoses)(如果(狗吠或蜜蜂叮咬)则(考虑玫瑰花上的雨滴))。即使在单个IF-THEN规则内，在允许的表达力中可能存在变化的丰富程度。上文的例子大致上对应于命题逻辑。命题逻辑基于这样的概念，即简单的真/假命题可组合作出逻辑声明。然而，在本发明中，可采用对于平均终端用户来说太过复杂以致于不能规定的更为丰富形式的逻辑，它们包括但不限于谓词逻辑、约束逻辑以及复现。

可通过用户界面(例如控制面板、工具栏)来规定首选项。模式开发者可提供一组基本的谓词作为条件逻辑的构件块。终端用户可随后挑选适当的条件，在适当的地方指定参数值，以及将它们与布尔逻辑操作符(例如AND、OR、NOT)相组合。类似地，终端用户可挑选适当的结果以及在适当的地方指定参数值。终端用户规定的程序的丰富性来自于开发者提供的模式化的逻辑。这些条件和结果模板在它们的内部逻辑中可能是丰富的，访问大量的信息，包括终端用户应用程序的结构化数据。事件条件或结果模板可具有描述参数列表的模式。终端用户可通过简单地提供适当的参数值来使用这些构件块。

迄今为止已经描述了对信息代理系统100的被动使用，下文中描述更为主动的形式。根据对系统100的被动使用，应用程序负责在适当的阶段调用判决逻辑以及提供必要的参数。应用程序还能够负责调用另一应用程序来对结果其作用。此外，应注意，程序接触结构即系统100还可能需要解释器(未示出)来评估首选项，处理多个首选项之间的冲突，以及判断正确的结果集。

事件编程组件340为信息代理应用程序300提供至少三个功能。首先，事件编程组件420能够提供一组模式化的信息事件(例如由模式开发者定义)，能够充当终端用户程序的挂钩(hook)。每个事件可带有结构化的数据。存在若干种机制用于事件实例捕获(例如用于事件提交的API)。也存在某些子类的信息事件。事件的一个子类对应于模式化数据存储器150中的数据变化。因此，事件编程组件340能够提供机制来访问存储器420中的数据变化，使它们作为模式化变化事件而可用。另一子类的事件可对应于复现定时器事件，这对于计划的首选项活动来说可能是重要的。事件编程者组件340还可提供将终端用户“处理程序”逻辑关联到特定事件的发生的能力。此外，事件编程组件340可提供服务来捕获事件、运用适当的判决逻辑以及调用动作处理程序来执行判决结果。

事件编程组件340可与判决逻辑组件330交互，来提供更多的功能。例如，终端用户可使用判决逻辑组件330设置不变的判决逻辑，它在新事件到达时重复被运用。因此，系统和/或运行于其上的应用程序的主动性在于每个触发事件引起适当的判决逻辑的评估。更为特别的，触发事件可形成对判决逻辑的输入，首选项逻辑评估的结果可形成事件编程组件340能够代表终端用户执行的动作。此外，动作可产生新鲜的事件，新鲜的事件随后引起进一步的逻辑由编程组件340执行。结果，存在特别的链式事件编程设计。

任务调度组件350管理终端用户任务调度或工作流。这里所采用的调度是一种任务之间具有特定顺序或分级的有组织的任务集合。整体上执行任务的目的一般在于完成某些真实世界的目的，例如，安排与四个人的会谈。在会谈例子中，调度中的任务可尤其包括发出发起会谈的请求，以及处理肯定和否定的应答。虽然工作流在商业过程自动化中是普遍的，但是关于本发明所描述的任务调度或工作流与终端用户活动相关联(例如安排会谈、评审文档、委托请求……)。虽然这些工作流中的许多都是简单的过程，但是它们对于终端用户来说是可定制的和透明的。

任务调度组件350可与判决逻辑组件330和事件编程组件340提供的功能进行交互并对其进行影响。事件编程组件340提供理想的挂钩来调用任务调度。例如，包含工作请求的新的电子邮件的到达可踢脱(kick off)任务调度。虽然某些任务调度是严格的，处理流是明确的，但是许多其它的任务调度是灵活的，允许终端用户选择不同的路径。例如，如果两个或多个被邀请者拒绝了会谈请求，则可重新安排会谈或者可选地会谈可进行下去。这是用于利用终端用户首选项和判决逻辑组件330的良好区域。此外，应注意到，根据本发明的可选的一个方面，任务调度组件350可结合于事件编程组件340中，因为调度涉及对变化作出反应以及调用适当的动作。总而言之，虽然任务调度的某些部分可由开发者进行困难的编码，但是通过使得流变得动态，由通过终端用户编程而有时自动化的明确的用户判决来配置，就附加了显著的价值。

对于这里描述的信息代理概念来说，存在至少两个中心元素。首先，终端用户提供控制应用程序行为的判决逻辑的能力是重要的。这仅仅是应用程序的终端用户可编程性，并不实际上涉及代表终端用户进行动作的代理。在这里把它称为终端用户逻辑的被动调用。其次，信息代理概念中的一个重要元素是终端用户提供主动的判决逻辑的能力。当适当的信息事件发生时，可重复施加主动的判决逻辑，从而可充当代表终端用户的软件代理。在两种情况下，判决逻辑对于用户的上下文环境和应用程序的状态来说都具有典型的上下文环境依赖性。下文中将描述这两种上下文环境类别中的各种情况。此外，还将描述信息代理可采取的以不同的“角色”的形式的端到端情况。

终端用户逻辑的被动调用的一个例子是操作系统使用信息代理来控制用户的中断。无论何时某一应用程序向带有声音地在屏幕上产生弹出窗口，操作系统都能利用API来调用信息代理判决逻辑组件来决定什么应当发生。判决逻辑可揭示若干个可能的结果，包括显示、推迟、删除以及提前。一旦判决逻辑组件330告诉操作系统做什么，操作系统随后能够实施实际的判决。

还可采用判决逻辑组件330来定制常规程序的选项。例如，常规的电子邮件程序提供读取接收条、施加签名、以及邮件属性的选项。根据读取收条，常常存在一复选框来指示出是否应当启用读取收条。判决逻辑组件330能够定制该选项，以仅仅对重要的消息或发送到其管理者的消息允许收条读取。此外，用户一般能够对发出的消息施加签名，然而，采用判决逻辑组件330能够通过根据目标接收者而向消息附加签名来使得操作更为有价值和个人化。最后，电子邮件属性等级一般由发送者确定和设置。通过使用判决逻辑组件330，邮件属性还可由接收方根据例如接收者的当前上下文环境来确定。此外，应注意，终端用户逻辑不仅可用于确定在上述情况之类的情况中要做什么(例如附加签名)，也可用于确定动作的内容应当是什么(例如实际上应当附加什么签名)。

通过判决逻辑组件330对终端用户逻辑的主动调用可用于多种情况中。例如，可采用主动逻辑组织数据，例如在照片从照相机下载下来后进行分类，或根据组织规则接收的电子邮件。主动逻辑还可用于对诸如当新的点击邮件到达以及接收者不在他/她的办公桌前时将邮件发送到他们的移动电话机上之类的变化发生作用。主动逻辑还可用于增强通信，例如通过在用户没空时回答用户的电话，并以例如下次用户将有空接电话作出回答。此外，主动逻辑可用于订阅公开的信息，例如可通知用户其旅游目的地何时预期有坏天气。进一步，主动逻辑可用于维护上下文环境。例如，当用户进入或离开不同位置的会谈时，可适当地更新上下文环境(例如远程的或本地的，忙的或空闲的……)。

信息代理可充当各种角色，就像实际的人类代理对用户所做的那样。因此，信息代理可具有各种不同的角色，包括但不限于：增强通信的秘书、组织信息的图书管理员、确保委托人/用户意识到机会的服务代理、确保委托人/用户不会有麻烦的伴侣、以及使得委托人/用户看上去和感觉良好的仆从。作为秘书，信息代理可执行各种功能，例如当委托人/用户没空时回答电话呼叫、将呼叫者转移到没空的用户的语音邮件，并向用户发出即时消息指示出呼叫被错过。充当图书管理员的作用，信息代理能够组织数字照片和电子邮件。作为服务代理，信息代理能够保持委托人被通知例如购买销售股票或房地产的机会。充当伴侣的信息代理可在委托人的银行账户余额低于最低余额时通知委托人，当他们接近于他们的信用卡限额时通知委托人，提供通知以确保按时支付账单，和/或告警委托人关于电池用完或他们的计算机上磁盘已满的信息。作为仆从，信息代理能够阻止与来自重要的客户的进入呼叫相关的所有文档和电子邮件，和/或确保麻烦的通知不会在演示的中间弹出。

逻辑模式

转向图4，描述了根据本发明的一方面的示例性逻辑模式400。逻辑模式400包括条件类410、动作类415、事件类420、首选项类425、绑定430、大事记435、冲突解决445、明确的执行顺序450、要求的条件和动作455、模板460、以及计划的和复现的首选项465。处于解释简单的目的，给出示例性的逻辑模式400和上述模式组件。因此，应理解，逻辑模式400可包含上述组件的全部、其子集、和/或这里没有描述的其它模式组件。如先前所讨论的那样，模式开发者定义可由终端用户装配在一起的模式化逻辑构件块。两种类型的构件块是条件类410和动作类415。条件类410可定义模板化的布尔逻辑功能，而动作类415可定义模板化的过程。首选项类425是信息代理模式开发的单位。首选项类425可尤其包含一组允许的条件类和动作类、绑定430、冲突解决445和要求的条件455。此外，每个首选项类425可与特定的事件类420相关联，特定的事件类定义了首选项的触发事件。下面是用于信息代理电子邮件应用程序的首选项类的例子：

InboxPreferenceClass         //收件箱首选项类

     ●ConditionClasses      //条件类

         ○IsFrom(X)

         ○IsTo(Y)

     ●ActionClasses         //动作类

         ○MoveToFolder(Z)

         ○Delete()

     ●TriggeringEventClass  //触发事件类

         ○EmailEventClass

●Source of triggering event        //触发事件的源

    ○Changes to an inbox folder    //对收件箱文件夹的变化

    ○ApplyNow()

    ○ScheduledEvent()

首选项是终端用户逻辑的单位。首选项可以是采用“ON(event)IF(condition)THEN(actionset)”(ON(事件)IF(条件)THEN(动作集)的形式的逻辑声明。因此每个首选项应当但非必须具有下面的属性。首先，首选项应当属于首选项类。其次，首选项应当由某一用户或委托人所拥有。第三，条件应当是组合了一个或多个条件类的实例的声明性布尔逻辑表达式，其中每个条件实例定义了用于条件类的参数值。最后，动作集应当是一组动作类。每个动作实例定义了用于动作类的参数值。例如：

UserPreference：         //用户首选项

      ●Instance of InBoxPreferenceClass    //收件箱首选项类的实例

      ●IF(IsFrom(John)OR IsTo(‘bookclub”)THEN MovetoFolder(‘Book Club’)

终端用户随后能够通过定义事件处理程序(handler)来“编程”。每个事件处理程序由同一首选项类的一组首选项来定义，因此由同一事件触发。例如：

●IF(IsFrom(John)OR IsTo(‘bookclub”)THEN MovetoFolder(‘Book Club’)

●IF(IsTo(‘SillyStuffDL’)THEN Delete()

接着，当某一事件发生时(例如电子邮件到达)，不止一个首选项可具有有效的条件，导致执行多个动作的可能性。于是，可施加各种冲突解决机制，如下文所述。

此外，应理解，每个条件仅仅是连同其调用参数一起的布尔逻辑函数。根据本发明的一个方面，要求示意性的逻辑跨越应用程序边界。因此，条件需要能够观察多个不同的应用程序创建的数据。例如：

●Presence data：IF(IsFrom(‘John’)AND SenderIsOnline())THEN…

●Location data：IF(IAmFarMeetingLocation())THEN ReminderMinutesWindow(30)

●Organizational hierarchy：IF(IsFromMyManagement())THEN MarkAsHighPriority()

所有上述的例子都涉及用户上下文环境。用户上下文环境可由上下文环境分析器140(图1)来确定，并存储于数据存储器150中(图1)供信息代理应用程序使用。从而，类似于“BoolIsOnline(X)”的函数可根据传入的X这个人的身份以及由上下文环境分析器确定的他/她的当前上下文环境来返回真或假。

继续上述的例子，诸如InBoxPreferenceClass之类的首选项类的模式开发者需要提供条件类410供终端用户使用。有若干种做法。例如，条件类可以是IsOnline()。在该情况下，终端用户能够以“IF(IsOnline(Email.Sender))THEN…”的形式定义首选项。可选地，条件类可以是SenderIsOnline()，在其声明中，模式开发者可以将其绑定到IsOnline()，将X绑定到Email.Sender。因此，终端用户能够按照：“IF(SenderIsOnline())THEN…”来定义首选项或规则。虽然本发明支持多种形式来规定条件类410，但是应注意，在上述的形式中有显著的差异。第一个形式是传统的肯定计算规则，其中创作该规则的人(即终端用户)推理模式和变量绑定。第二种形式较不灵活，但是对于终端用户使用来说确是更为简单。因此，类条件410是模式开发者能够限制终端用户逻辑的表达力的区域，从而使得自然终端用户更为切实可行地“编程”信息代理应用程序。

简而言之，当模式开发者创作一首选项类425时，就作出了一组条件类声明410。每个条件类声明标识了实现函数和对于该函数的由开发者定义的表达式绑定的某些参数。剩余的参数是终端用户在设置首选项时为每个条件实例提供的常量。动作是动作类415的实例。每个动作类415是具有参数的过程。正如同条件一样，参数可由开发者绑定，或可由终端用户指定为常量。此外，事件类420提供事件的定义。如开发者规定或终端用户指定的那样，事件类定义了事件的信息内容，它触发首选项评估。

如贯穿本说明书和根据本发明的一方面所注意到的那样，不期望终端用户是有经验的编程者。因此，首选项是根据具有直观名称的条件(例如EmailIsFrom())来创建的，并且条件的自变量可以是简单的用户定义的常量(例如Mary)。这使得终端用户能够编写由EmailIsFrom(Mary)触发的首选项。然而，仅仅具有基于用户提供的串常量的自变量就太过局限了。因此，可以在逻辑模式400中规定绑定430，作为首选项类425的一部分，既使得编程对于终端用户更为容易，又使得扩展了可从中检索到信息的范畴。模式400中可规定至少三种类型的参数绑定。首先，可规定预先定义常量的常量绑定。规定常量绑定是有益的，至少是因为它使得终端用户不用必须选择或规定常量。也可将事件绑定表达式绑定到作为对条件和动作的自变量而提供的值。更为具体地，可将表达式定义为使用事件字段和常量来计算值。例如：

●Conditon Class：SenderIsOnline()

●Definintion Function：IsOnline(X)

●Binding：X→Email.Sender

最后，可定义常量存取器(accessor)。常量存取器是对象的有名组，提供对条件和动作的自变量来代替用户必须人工地规定每个这种对象的情况。

常量存取器是非常有力的常量，允许将首选项和条件编写成能够从各种域导航或检索信息。这些常量仅仅是胶合于用于寻找和实现正确信息的函数上的名字，即与常量的名字相关联的组的成员。转到图5，例示出根据本发明的一方面的用于检索常量值的系统500。系统500包括存取器输入组件510、链接组件520、多个域530、540和550(域₁至域_N，其中N大于1)。存取器输入组件610按照输入接收诸如MyFamily、MyCoworkers或MyFriends之类的常量，并将常量提供给存取器组件520。存取器组件520用于搜索所有可访问的域520、530和540，以尝试和解析或链接到与输入常量规定的组的成员相关联的值。根据本发明的一个方面，域530、540和550可以是存储于模式化数据存储器中的应用程序。例如，域520可以是电子邮件应用程序，域530可以是日程表应用程序、域540可以是用户账户应用程序。因此，存取器组件520可访问电子邮件应用程序或本地化的数据登记项目，以试图确定常量(例如MyFamily)的值。如果组件520不能解析该域或本地化的数据登记项目中的值，它可以继续检查其它的可访问的域，直到它确定了常量值或它检查了所有的域为止。在一个例子中，存取器组件可以发现电子邮件应用程序中的数据，如：

<MyFamily>

  <Father>Bob Jones</Father>

  <Mother>Barb Jones</Mother>

  <Brothers>

     <Bro1>Michael Jones</Bro1>

     <Bro2>Jason Jones</Bro2>

   </Brothers>

</MyFamily>

应理解，与常量MyFamily相关联的组的成员的XML表示仅用于说明的目的。可以各种方式由本发明来定义和/或实现组的对象群体。因此，根据从电子邮件应用程序检索到的数据，存取器组件520可以将MyFamily解析为或链接到Bob、Jones、Barb Jones、Michael Jones以及Jason Jones。然而，存取器组件540能够继续检查其它域，以确保数据完整性和精确性。例如，它可以在日程表应用程序中发现<MySister>Jennifer Jones</MySister>，并将该值添加到域与常量MyFamily相关的值的串中。

至此所讨论的常量(例如MyFamily、MyCoworkers、MyFriends、MyFavoriteMusicians)被称为是第一级的常量，因为它们是与给定用户相关地被定义的。存取器组件510或存取器可随后切断用户的身份或其它起始点。应注意，N级常量也可由用户通过使用首选项来组合先前定义的组(例如由常量命名)来合成和保存。作为例示，考虑提供与介词短语的语义类似的功能性的常量命名的组的组合。例如，用于可合成和保存代表FreindsOfMyFamily或EmailsFromPreferredCustomersInAppointmentsToday之类的组的常量。从另一观点来看，常量扩展类似于也可被表示为常量存取器并与其它常量相组合的项目的字段上的条件。

因此，常量存取器提供了跨不同域对数据的导航。模式化逻辑与导航的存取器的组合使得非编程者能够编写跨域的首选项。而且，相对少量的条件类域相对少量的存取器约束的组合促进了对可能另外被应用程序开发者所预期的大量有意思的和强大的条件的指定。

此外，应注意，也可规定首选项组。终端用户定义的判决逻辑由一个或多个首选项集合来定义。因此，首选项组可被定义为相关首选项的组的容器。首选项组中的首选项于是能够(1)属于同一首选项类，(2)被一起评估，结果遭受到冲突解决。此外，首选项组中的首选项可一起被启用或禁用。首选项的一起启用或禁用在无数种情况下都是有用的。例如，终端用户可能在工作时具有一组首选项，而在家中时具有另一组首选项。从而，可以根据用户的上下文环境来启用或禁用首选项组。

逻辑模式400还可包括大事记435。许多信息代理应用程序需要维持状态以便作出切合实际的判决。作为一个简单的例子，考虑新闻公开信息代理应用程序。终端用户订阅感兴趣的新的文章。事件供给携带有稳定的新闻文章流。一个问题是同一文章可能多次到达，每次有少量修改内容，但具有相同的标题。在该环境下，切合实际的判决将是：IsNewArticle()。该条件可检查该标题以前未被看见过。另一例子是检查稳定的更新流是否使得文章成为断碎的故事。为了允许这种类型的功能，随着事件的处理，需要维持状态。该状态在这里被成为大事记，因为它代表应用程序历史。

信息代理模式开发者能够定义大事记(例如作为关系数据库中的表，或操作系统管理的文件夹)。更为重要的是，模式开发者能够定义在事件处理的关键阶段运行以便更新应用程序状态的逻辑。例如，计算是否一事件对应于断碎的故事的适当时间将是事件被处理之前。此外，记录新闻文章被处理从而具有相同标题的后续事件显露为复本的适当时间将是事件被处理之后。进一步，应注意到，除了事件历史之外，大事记还可用于记录动作历史。

开发者可在作为逻辑模式400中的首选项类425的一部分的冲突解决组件545中规定冲突解决过程或逻辑。当事件发生时，如果多个首选项与该事件匹配，则可产生多个动作。从而，希望用于确定执行顺序和/或采取的最终动作的系统和方法。至少有三种方式来处理多个动作的触发。例如，终端用户能够向每个首选项指定优先级。此外，终端用户可以向某些首选项指定停止处理标志(例如标记)。因此，当事件触发多个动作时，必须以优先级顺序执行动作。此外或可选地，如果多个首选项匹配在一首选项组中匹配，则可执行最高优先级的首选项而丢弃其它。此外，模式400可使得终端用户能够规定冲突解决过程，例如允许他们将停止处理标志附加到某些首选项，以处理在与其它首选项相同的时间触发了包含该标志的首选项的情况。可解决冲突的另一种方式是在模式400中定义动作类优先级。因此，模式开发者能够规定动作类优先级。例如，MoveToFolder动作类可被指定为具有比Delete动作类更高的优先级。当同一动作类的多个动作被同时触发时，其它冲突情况可能发生。模式开发者可定义多个冲突解决逻辑来应对这种类型的情况。例如，假设存在设置所希望的弹出窗口的体积的动作类(如SetVolume())。进一步假设一事件触发了两个动作SetVolume(50)和SetVolume(70)。在该情况下，冲突解决组件545中定义的冲突逻辑可以被定义成采用对应于这两种水平的最小、最大或平均水平的动作。

通过明确的执行组件450还可在模式400中规定首选项执行顺序。在某些情况下，首选项的明确的排序是必需的，因为一个首选项的动作可能影响到另一个中的条件。例如，对于电子邮件首选项，一个首选项可用于决定呼入的消息的优先级，而另一个首选项可被编写成对消息的优先级起作用并决定如何进行动作。终端用户首选项编写者一般是没有经验的编程者。根据本发明的一方面，不要求终端用户编写具有副作用以及因此而来的排序要求的首选项或规则。对于模式开发者来说，较佳的是对终端用户隐藏排序依赖性。这可通过多个不同的方式来实现，包括但不限于：首选项类排序、明确的链接(explicitchain)以及首选项组排序。通过首选项组排序，模式开发者能够将一个首选项类排序成在另一个之前执行。在上述的例子中，用于建立消息属性(例如属性)的首选项类应当在对该消息起反应的首选项类之前到达。根据本发明的一方面，呈现给终端用户的用户界面可被分成窗格，使得每个首选项类具有其自己的窗格。根据明确的链接，模式开发者能够规定产生新鲜事件的动作及其排序。因此，首选项类可以动作-事件链接而不是首选项类排序来实现。进一步，模式开发者能够使用首选项组来规定执行顺序。利用首选项组排序提供了与首选项类排序相同的能力，但是形式上更为灵活。例如，每个首选项组中可具有正好一个首选项，导致首选项的完全有序顺序列表的等价。

作为首选项类425的一部分，还可使用要求的条件和动作组件455在模式400中规定“要求的”条件和动作。每个首选项类可包括要求的条件和动作。要求的条件和动作可用于对所有的首选项强制实施某些公共的模式。例如，在服务器上运用的熟悉的电子邮件处理例子中，对Inbox首选项的要求的条件可以是首选项的所有者也是电子邮件的接收者。

模板460也可定义与逻辑模式400中。为了便于没有经验的终端用户创作逻辑，开发者或第三方可为用户提供模板供其采用或利用。因此，如果模板对于终端用户可用，则系统100应支持首选项模板的抽象。这可简单地对应于某些参数未被规定的坚持完成的首选项(选择了条件表达式和动作)。

模式400还可被定义成以便通过计划的和复现的首选项组件465处理计划的和复现的首选项。许多信息代理应用程序可能希望利用以复现的时间安排来评估的首选项。许多例子之一将包括每个工作日的下午5点发送简明状态的首选项。根据本发明的一个方面，计划的和复现的功能可使用两种抽象在模式400中实施。首先，系统定义的事件类(例如TimerEvent)可用于为计划的活动提供事件挂钩。该事件类可配置成各种规则的尺度。此外，与事件相关联的数据可包括当前时间和前一个激发时间。其次，每个计划的首选项可包括条件，例如：

RecurrenceInWindow(RecurrenceSchedule，StartTime，EndTime)，其中

●RecurrenceSchedule是表示所希望的复现模式的常量，从终端用户规定中捕获；

●StartTime由开发者绑定到定时器事件的前一个时间；

●EndTime由开发者绑定到定时器事件的当前激发时间。

总而言之，逻辑模式400可包含若干个不同的组件或部分，以便为终端用户首选项提供逻辑构件块。模式可采用任何形式，例如XML文件。一旦模式完成之后，它就能够被编译成数据库表示，并存储于例如数据存储器150(图1)中。应理解，可使用诸如Visual Studio之类的应用程序来之间创作或构造模式文件。因此，系统编译器应当能够支持使用多种模式编辑器应用程序产生的模式文件。

应用程序执行

信息代理应用程序的执行可被细分成三种不同的类别：事件处理、首选项处理以及动作处理。事件处理涉及事件如何被捕获以及它们如何激活首选项逻辑。首选项处理可以多个不同的方式来完成，这部分地取决于不同的首选项处理模式。最后，应用程序执行涉及确定如何处理动作。

事件可由使用系统API 110(图1)明确地提交事件的某些应用程序来捕获。事件可单独地被提交，或者可成批地被提交。对于事件捕获，存在许多情况，包括但不限于：

●作为规则的应用程序逻辑的一部分，例如，Exchange SMTP提供商可接收新的SMTP消息，并且明确地引发信息代理事件。

●通过数据变化，例如，当数据在数据存储器150中改变时为IA逻辑触发事件。

●通过操作系统，例如，应用程序可监听操作系统和/或它相关的运行时间，并在检测到某一特定动作时引发事件。

●通过信息胆力首选项，一个首选项的动作可引发另一事件，导致跨首选项评估的链接。

●用户可明确地规定生成事件。例如，用户可规定对应于文件夹中的每个文件生成事件。

此外，应注意，系统100可为不要求更大的应用程序活动地执行的事件捕获逻辑提供主控服务。例如，信息代理应用程序可能希望某些操作系统事件触发应用程序活动性。因此，就可能在服务中主控该事件提供者，而不是要求一单独的应用程序仅仅为此功能而运行。

通过事件的出现而激活首选项。其处理可以是同步的、异步的或两者的组合。利用同步处理，事件提交和首选项评估之间存在可忽略的小的延迟。另一方面，异步处理在事件提交和事件处理之间存在显著的延迟。本发明的系统支持这两种模式的处理，并且根据事件批提交来实时地在两个模式之间选择。

而且，根据本发明的一个方面，首选项处理利用了数据库查询的能力，来有效地评估首选项。暴露于开发者并且最终暴露于终端用户的是一种声明性编程模型，它允许根据每次一个(one-at-a-time)模型来规定条件函数。每次一个编程模型是这样一种模型，它最为自然地来使用，并使得开发者和用户能够相对于一个首选项来规定一个事件。然而，根据本发明的一方面，系统100精心地制作以面向集合的方式执行的条件类查询，采用类似于索引和复本消除的技术。其好处在于首选项是以有效的方式被评估的，而允许开发者和终端用户以每次一个的方式来构思和编写程序，虽然容易理解和编写，但是对于执行多个首选项来说却不是有效的方式。此外，虽然可成批地处理多个首选项，但是应注意，可根据事件发生来单独地评估首选项。

转到图6，例示出根据本发明的一方面的用于首选项评估的系统600。系统600包括数据存储器150、多个表610、首选项执行引擎160和结果表630。数据存储器150收容了多个表610，所述多个表是由系统100从开发者模式以及终端用户首选项产生的。作为事件出现的结果，首选项执行引擎例如从数据存储器150中存储的表中接收或检索首选项。执行引擎160随后利用首选项以及某些存储的过程(这写过程也可按照数据被存储)来查询表610，并产生结果表630。结果表630可存储条件已被满足使得规定的动作可出现于其上的首选项。

表610的数量和复杂性可根据开发者编写的模式的复杂性来改变，用于支持终端用户首选项。下文中给出了一个例子，以便澄清系统600如何利用数据库表和查询来处理首选项。在该例子中，存在两个个人Jack和Jill，他们试图利用若干组首选项。如已经讨论的那样，在Jack和Jill能够规定终端用户首选项之前，必须已经产生了一模式。模式具有如上所讨论的若干部分，但是，出于简单理解的目的，这里将描述一个非常简单的模式。模式的基本部分之一是事件类的定义。在该例子中，考虑了两个事件类，EmailEvents和StockEvents。转到说明书所附的附录，示出的伪代码例示了两个事件类以及三个首选项类的模式定义。两个首选项类基于EmailEvents，而第三个类基于StockEvents。信息系统100能够随后使用该模式来产生首选项类表和条件类，可存储于数据存储器150中。例如：

PreferenceClasses Table    //首选项类表

---------------------------------------------------------------

应用程序Id，首选项类Id，     首选项类名，         事件类Id

(App.Id)，  (Pref.Class Id)，(Pref.Class Name)    (Event Class Id)

---------------------------------------------------------------

1           1                EmailPreferences1    1

1           2                EmailPreferences2    1

1           3                StockPreferences     2

---------------------------------------------------------------

ConditionClasses Table               //条件类表

---------------------------------------------------------------

首选项类Id，          条件类Id，         条件类名

(Pref.Class Id)       (Cond.Class Id)    (Cond.Class Name)

---------------------------------------------------------------

1                     1                  MailIsFrom

1                     2                  MailContains

2                     3                  MailPriority

2                     4                  MailIsFrom

3                     5                  StockSymbol

3                     6                  TargetPrice

---------------------------------------------------------------

Jack和Jill能够定义他们的首选项。对于本例来说，假设Jack定义了三个首选项组PG(Jack，1)、PG(Jack，2)以及PG(Jack，3)。此外，Jack定义了在诸组之间分布的五个首选项，如下：

PG(Jack，1)

P1：On EmailEvents if MailIsFrom(Mary)AND MailContains(″California″)

                           then PopAToast

P2：On EmailEvents if MailIsFrom(Bob)OR MailContains(″InfoAgent″)

                           then PopAToast

P3：On EmailEvents if MailIsFrom(Home)OR MailIsFrom(MyWife)OR

MailIsFrom(MySon)

                           then PopAToast

PG(Jack，2)

P3：On EmailEvents if MailIsFrom(Home)OR MailIsFrom(MyWife)OR

MailIsFrom(MySon)

                           then PopAToast

PG(Jack，3)

P4：On EmailEvents if MailIsFrom(Home)AND MailPriority(10)

                           then MoveToFolder(″URGENT″)

P5：On EmailEvents if MailPriority(15)

                           then MoveToFolder(″VERY URGENT″)

对于本例，假设Jill定义了两个首选项组(JIll，1)和(Jill，2)。此外，假设Jill规定了在诸组之间分布的五个首选项，如下：

PG(Jill，1)

P6：On EmailEvents if MailIsFrom(Home)OR MailContains(″Vacation″)

                           then PopAToast

P7：On EmailEvents if MailIsFrom(Bob)AND！MailContains(″Work″)

                           then PopAToast

P8：On EmailEvents if MailContains(″Bonus″)

                           then PopAToast

PG (Jill，2)

P9：On StockEvents if StockSymbol＝(′EBAY′)AND TargetPrice＞120

                           then SendCellPhoneMessage(′Me′)

P10：On StockEvents if StockSymbol＝(′AMZN′)AND TargetPrice＞50

                           then SendCellPhoneMessage(′Me′)

信息代理系统100能够随后利用这写首选项来产生额外的关系数据库表，描述首选项以及与其相关的条件。考虑下面的示例性表，每次一个，并考虑如何采用它们来评估首选项。

下面示出的Preference Groups表(首选项组表)包含五行，每行用于Jack和Jill定义的首选项组中的一个。此外，注意，列被指定为指示出首选项组是否被使能。如上文所述，例如如果用户想要规定他们在家时启用的一组首选项和他们在工作时启用的另一组首选项，这是有用的。在此，所有的首选项组都被视为使能的(启用的)。

PreferenceGroups Table      //首选项组表

----------------------------------------------------------------------

首选项组Id，首选项组名，订户Id，启用

(Pref.Group Id)，(Pref.Group Name)，(Subscriber Id)，(Enabled)

----------------------------------------------------------------------

1                Jack_1      Jack           True

2                Jack_2      Jack           True

3                Jack_3      Jack           True

4                Jill_1      Jill           True

5                Jill_2      Jill           True

----------------------------------------------------------------------

还可定义PreferenceGroupMemberShip表(首选项组成员关系表)来汇总哪些首选项是哪些首选项组的成员。下面例示出该表包含11行，每个行用于一个首选项。

PreferenceGroupMemberShip Table  //首选项组成员关系表

----------------------------

首选项组Id，首选项Id，

----------------------------

1           1

1           2

1           3

2           3

3           4

3           5

4           6

4           7

4           8

5           9

5           10

----------------------------

下面的首选项表可存储于数据存储器150中，以汇总与用户定义的首选项有关的数据。该表包含10行，每行对应于10个首选项中的一个。请注意，该表被链接以仅示出重要的列和名字。

Preference Table    //选项表

-----------------------------------------------------------------

首选项类Id，首选项Id，原始条件表达式，ANDGroupCount(AND组计数)

---------------------------------------------------------

1    1  From(Mary)AND Contains(CA)         1

1    2  From(Bob)OR Contains(IA)           2

1    3  From(Home)OR From(MyWife)OR        3

        From(MySon)

2    4  From(Home)AND Priority(10)         1

2    5  Priority(15)                       1

1    6  From(Home)OR Contains(Vacation)    2

1    7  From(Bob)AND！Contains(Work)       1

1    8  Contains(Bonus)                    1

3    9  Symbol(EBAY)AND Price(120)         1

3    10 Symbol(AMZN)AND Price(50)          1

---------------------------------------------------------

           注意：总计(sum)＝14

还应注意，在上述首选项表中存在总共14个AND组。

此外，上面共有19个条件。关于这些AND组和条件的信息可捕获在额外的表中，如下：

ANDGroups Table    //AND组表

-------------------------------------------------------

首选项Id，ANDGroupId(AND组Id)，ConditionCount(条件计数)

-------------------------------------------------------

1              1                     2            --From(Mary)AND Contains(CA)

2              2                     1            --From(Bob)

2              3                     1            --Contains(IA)

3              4                     1            --From(Home)

3              5                     1            --From(MyWife)

3              6                     1            --From(MySon)

4              7                     2            --From(Home)AND Priority(10)

5              8                     1            --Priority(15)

6              9                     1            --From(Home)

6              10                    1            --Contains(Vacation)

7              11                    1              --From(Bob)AND！Contains(work)

8              12                    1              --Contains(Bonus)

9              13                    2              --Symbol(EBAY)AND Price(120)

10             14                    2              --Symbol(AMZN)AND Price(50)

---------------------------------------------------

ANDGroupId在上表中顺序编号。ConditionCount记录由AND所连接的条件数。

上表中的惟一一个不寻常的行是如下所示的一行。

7          11                  1       --From(Bob)AND！Contains(Work)

注意，ConditionCount是1而不是所预期的2。为了考虑到查询评估中的NOT的存在，条件计数被定义为AND组中的那些前面没有NOT(！)的条件的总计数。其前部具有NOT的那些条件可如下文所示那样汇总在一单独的表中。

ANDGroup还可按照ANDGroupMembership(AND组成员关系)的表来定义，如下面链接的表所示：

ANDGroupMembership表

--------------------------------------

ANDGroupId，条件类Id，    条件Id

--------------------------------------

1           1             1           --From(Mary)

1           2             2           --Contains(CA)

2           1             3           --From(Bob)

3           2             4           --Contains(IA)

4           1             5           --From(Home)

…………………………………………………………………………

…………………………………………………………………………

…………………………………………………………………………

14          6             19          --Price(50)

--------------------------------------------------------

如上所示，具有NOT的条件可被看作是一种特殊的情况，并汇总在它们自己的表中，如下：

NOT表

-------------------

条件类Id，  条件Id

-------------------

2           14     --！Contains(Work)

--------------------

还可创建条件值表来存储首选项中规定的条件的值。应注意，该表仅仅允许两个参数值与每个条件相关联。对于该例子，这是充分的，因为所有的条件仅具有一个参数值，但是如果允许条件包含与之相关联的两个以上的参数值时，可以扩展该表或者可例示出另一个表来示出额外的条件值。

ConditionValues表(参数值表)

----------------------------------------------------------

首选项Id，条件类Id，条件Id，ParamVal1(参数值1)，参数值2

----------------------------------------------------------

1         1         1       Mary                NULL

1         2         2       CA                  NULL

2         1         3       Bob                 NULL

2         2         4       IA                  NULL

3         1         5       Home                NULL

……………………………………………………………………………

……………………………………………………………………………

……………………………………………………………………………

10        6         19      50                  NULL

----------------------------------------------------------

还可提供ConditionsResults表(条件结果表)。ConditionsResults表可用作最终结果表730的前身。随着条件查询被执行，ConditionsResults表被填充。当条件查询还未运行时，表中没有行。用于评估条件以及填充该表的示例性过程在下文中揭示。

ConditionResults表

---------------------------------

Bool，条件Id，首选项Id，事件Id

---------------------------------

---------------------------------

如先前所述，本发明的一个方面给出一种声明性编程系统，允许向条件函数的开发者暴露每次一个(one-at-a-time)模型，但是最终制作出以面向集合的方式执行的条件类查询，以利用数据库查询的效率。因此，一对一的条件类声明可被变换为查询。例如，在EmailEvents中，终端用户首选项可根据电子邮件的发送者作出动作(例如Jack的P1)。从而，终端用户可通过用户界面编写MailIsFrom(Mary)。然而，当执行首选项时，系统700将执行代表用户条件声明的数据库查询。例如，系统能执行下面的SQL查询声明来代替用户声明，其中CV.ParamValue1＝’Mary’：

SELECT 1

FROM  EmailEvents E，ConditionValues CV

WHERE E.Sender＝CV.ParamValue1；

因此，开发者应当为每个条件定义查询代码，并将它们存储于表中。虽然可能，但是新的表不需要为该特殊目的而建立。先前定义的ConditionClasses表可被简单地修改来包含在下面的伪代码中所示的查询文本。

-----------------------------------------------------------------

首选项类Id，条件类Id，类名，查询文本

------------------------------------------------------------------

1           1         MailFrom  select l，条件Id，首选项Id，事件Id

                                from EmailEvents E，ConditionValues CV

                                where E.Sender＝CV.ParamValue1

                                AND CV.Cond.ClassId＝1

                                AND required conditions

1            2        MailContains  select 1，条件Id，首选项Id，事件Id

                                    from EmailEvents E，ConditionValues CV

                                    where E.MessageText like′％′+

                                    CV.ParamValue1+′％′

                                    AND CV.Cond.ClassId＝2

                                    AND required conditions

……………………………………………………………………………………………………………

……………………………………………………………………………………………………………

……………………………………………………………………………………………………………

3            6        TargetPrice  select 1，条件Id，首选项Id，事件Id

                                   from StockEvents S，ConditionValues CV

                                   where S.Price＞CV.ParamValue 1

                                   AND CV.Cond.ClassId＝6

                                   AND required conditions

----------------------------------------------------------------------------------

一旦所有的表710都已被定义，就可相对于这些数据来评估首选项，以便填充结果表730，并在此后执行与之相关联的动作。可通过评估查询来执行首选项。根据本发明的一方面，可通过采用一个或多个过程来评估查询，所述一个或多个过程可按照数据存储于数据存储器150中，并可根据需要来被构造。若干过程可致力于评估条件和首选项，并随后填充结果表，例如，利用指示出首选项是否评估为真使得与之相关联的动作的执行可发生的首选项和标记。例如，可采用下面的过程来评估或查询条件，并将结果存储于ConditionResults表中，该表随后可被评估来填充结果表730。

create proc NSStoreResultsIntoResultsTable

@conditionClassId int

AS

declare@query varchar(255)--this number could be much larger

select@query＝Query_Text

from ConditionClasses

where conditionClassId＝@conditionClassId

insert ConditionResults exec(@query)

return(0)

此外，应理解，上述的过程可利用循环，使得所有的条件查询都被执行。然而，可能较佳的是对每个条件调用上述过程一次，以便允许递增的条件评估。一旦所有的条件都被评估，则可利用另一个过程来评估首选项，这些首选项通常是其间具有布尔逻辑算子的条件。

如同这里所描述的所有过程一样，存在许多不同的编写过程的方式，这尤其取决于编程者类型、效率、以及构造的表的性质。出于理解的目的，下面的过程作为可按照本发明的一方面用于评估首选项的查询的例子。应注意，可使用更为有效的查询过程，递增地评估首选项的不同的ANDGroup，而不是进行单次执行。

select distinct(eventId，prefId)

from ConditionResults C，AndGroupMemberShip A

where C.condId＝A.condId

group by C.eventId，C.prefId，A.AndGroupId

having sum(C.Bool)＝(select ConditionCount

              from AndGroups A2

              where C.Prefid＝A2.PrefId

              and A.AndGroupId＝A2.AndGroupId)

为了澄清上面的过程如何产生最终的结果表730的行，下面给出了一些例子。

例子1：

假设ConditionResults表中有下面的两行。

------------------------------------

Bool，条件Id，首选项Id，事件Id

------------------------------------

1     1       1         100      --From(Mary)

1      2       1        100      --Contains(CA)

-----------------------------------------

在首选项1(Preference 1)中的这两个条件之间存在AND。因此，仅当上述条件都为真时，该首选项将评估为真。这两个条件都属于条件计数为2的第一个ANDGroup。因此，当上述表与ANDGroupMembership表结合时，下面的表产生：

------------------------------------------

Bool，条件Id，首选项Id，事件Id，AndGroupId

------------------------------------------

1     1       1         100      1

1     2       1         100      1

------------------------------------------

总计(sum)＝2

在进行了group by(按……分组)之后，我们得到下面的行：

----------------------------------

sum(Bool)，首选项Id，事件Id，AndGroupId

----------------------------------

2          1         100        1

-----------------------------------

现在，(首选项Id，ANDGroupId)形成了用于ANDGroups表的钥匙。

从中查找提供了条件计数为2，等于sum(Bool)。

因此，首选项为真，它可被加入结果表730。

例子2：

假设ConditionResults表具有下面两行：

------------------------------

Bool，条件Id，首选项Id，事件Id

------------------------------

1      3      2       101       --From(Bob)

1      4      2       101       --Contains(IA)

在首选项2(Preference 2)中的两个条件之间存在OR。从而，仅当该两个条件中任一个为真时，该首选项评估为真。这两个首选项分别属于第二和第三ANDGroups，其条件计数都为1。因此，当上表与ANDGroupMembership表结合时，下面的表产生：

-------------------------------------------

Bool，条件Id，首选项Id，事件Id，AndGroupId

-------------------------------------------

1     3       2         101       2

1     4       2         101       3

-------------------------------------------

在将上述表分组之后，我们得到：

-------------------------------------------

sum(Bool)，首选项Id，事件Id，AndGroupId

---------------------------------------

1          2         101       2

1          2         101       3

----------------------------------------

上面的两行都将满足having子句，因此，在进行了区别之后，我们发现首选项(首选项Id＝2，事件Id＝101)将被复制到结果表703中。

例子3：

对于该最后一个例子，假设ConditionResults表具有下面的两行：

-------------------------------

Bool，条件Id，首选项Id，事件Id

-------------------------------

1         13       7      102      --From(Bob)

1         14       7      102      --Contains(Work)

-----------------------------

回想到首选项7上的条件实际上是From(Bob)and！Contains(Work)。

在存在NOT的情况下，根据本发明的一方面，上述第二行中的1被改变成-1。下面是提供这种功能的示例性查询：

update ConditionResults

set Bool＝-1

where cond.Id IN (select cond Id

           from Not)

此外，应注意，如果一聪明的查询优化程序被采用，并注意到NOT表非空，则该查询应当立即返回。因此，上表变为：

--------------------------------

Bool，条件Id，首选项Id，事件Id

--------------------------------

1       13       7         102      --From(Bob)

-1      14       7          102     --！Contains(Work)

--------------------------------

sum＝0

这两个条件都属于第11个ANDGroup。从ANDGroup表中可以确定该首选项(首选项，ANDGroup)的条件计数为1。由于0≠1，因此首选项评估查询不会产生行。然而，注意，如果第二行不在ConditionResults表中，则我们将具有sum为1(＝1)，且首选项7将被评估为真。

在填充了结果表730之后，可执行首选项动作。可通过信息代理系统100或由信息代理应用程序通过检索来自系统100的首选项结果并对其作用来执行动作。如果应用程序而非信息代理系统100执行动作，则可使用事件提交应用程序或某些其它应用程序来从系统100检索动作。按照系统100，系统100可为能够检索和执行动作的应用程序动作处理程序提供一主控服务。

优先级动作和上下文环境分析

下面的讨论涉及能够使得与诸如通知或消息之类的产生的动作相关联的多个信息由优先级系统自动划分优先级进行向用户或系统的传送的一种系统和方法。此外，虽然出于解释简单的目的，该讨论关注于通知的优先级以及上下文环境分析，但是应该理解到，任何动作可以类似的方式来使用优先级和上下文环境分析。优先级系统可利用明确地和/或隐含地经训练的分类器，来根据所学习的对用户的重要性来对一个或多个接收的消息进行划分优先级。作为一个例子，可通过具有相似重要程度的通知的例子或类型的训练集合来将通知分类为高、中、低或其它程度。可提供背景监视器来监视关于消息处理的用户的活动，以根据用户关于消息重要性的个人判决来进一步精练或调谐分类器。其它优先级分类可涉及关于与对消息的延迟审阅或处理的时间有关的损失的确定。

在消息或其它通知被自动划分优先级之后，用户能够审阅更重要的消息，而不用必需通过多个较不重要的和/或不相关的消息进行排序。按照重要性，消息还可被集合成一个或多个文件夹，其中用户可以在希望的时间查阅具有类似分类的重要性的消息。诸如信息代理系统100之类的其它系统(例如通过通知组件180)能够根据所确定的优先级将消息引导到一个或多个通知信宿(notification sink)(例如移动电话机、手持计算机)。例如，如果电子邮件消息被确定为具有高重要性，则信息代理系统100能够确定用户当前是否在他的办公桌前接收消息。如果不是，则通知平台能够将消息重新引导到用户当前能够处理的最可能的通信设备，例如移动电话机或家庭膝上型计算机，可将重要的或紧急的消息通知给用户。

参考图7，系统700例示出根据本发明的一方面的优先级系统712和通知动作架构。优先级系统712接收一个或多个消息或通知714、为相关的消息生成优先级或测量重要性(例如消息是高或低重要性的概率值)，并在输出716处提供具有相关优先级值的一个或多个消息。如下面将详细描述的那样，分类器可被构造和训练成自动地向消息714分配优先级的度量。例如，输出716可悲格式化成使得消息被分配有关于该消息属于高、中、低或其它重要性程度类别的概率。例如，根据所确定的重要性类别，消息可被自动地存储于电子邮件程序(未示出)的收件箱中。排序还可包括将文件引导到具有定义的重要性标签的系统文件夹中。这可包括将文件夹标记为诸如低、中和高之类的重要性程度，确定为某一重要性的消息被排序到相关的文件夹。类似地，一个或多个声音或视觉显示(例如图标、符号)可被适配成警告用户已经接收到具有所希望的优先级的消息(例如对于高优先级消息为三声蜂鸣音，对于中等优先级消息为两声蜂鸣音，对于低优先级消息为一声蜂鸣音，对于高优先级消息为红色或闪烁的警告符号，对于中等优先级消息为绿色的无闪烁的警告符号)。

根据本发明的另一方面，信息代理系统717(图1中为100)能够连同优先级系统712来将划分优先级的消息引导到用户可访问的一个或多个通知信宿。如下文中将要详细描述的那样，IA系统717能被适配成接收划分优先级的消息716，作出关于例如何时、何处以及如何通知用户的判决。作为一个例子，IA系统717能够确定用户的通信模态(例如用户的当前通知信宿718，如无线电话机或个人数字助理(PDA))，以及可能的位置和/或可能的关注焦点。例如，如果接收到高重要性电子邮件，IA系统717能够确定用户的位置/焦点，并将消息引导到/重新格式化到与该用户相关联的通知信宿718。如果接收到较低优先级的消息716，IA系统717可被配置成例如将该电子邮件留在用户的收件箱内共用户以后按需查阅。如将要详细描述的那样，其它转发(routing)和/或告警系统719可用于将划分优先级的消息716引导到用户和/或其它系统。

在下面的部分中，通过自动分类系统和处理来描述用于诸如电子邮件之类的文本文件的优先级的生成。如所述的用户文本的优先级的生成可用于其它系统中，例如下面更为详细描述的通知平台。该部分的描述与图8和图9有关，图8是例示出文本分类器的明确的和隐含的训练的示图，图9是描述通过文本分类器的输入如何生成文本的优先级的示图。该部分的描述还与作为根据文本的优先级可被分类成哪个的不同模式的示图的图10和图11有关，以及与作为例示出根据文本类型可使用的代价函数的示图的图8和图11有关。

现在参考图8，如箭头822所示，可明确地训练文本/数据分类器820，以及如箭头824所示，可隐含地训练文本数据分类器820，从而进行按照优先级的分类。箭头822所表示的明确训练一般在构造分类器820的初始阶段进行，而箭头824所表示的隐含训练一般在已经构造了分类器820之后进行，以便调谐分类器820，例如通过背景监视器834来进行。出于说明分类训练和实现方法的示意性目的，这里参考SVM分类器来作出具体描述。其它文本分类方法包括贝叶斯网络、判决树、概率分类模型，其条件为可采用不同的独立性模式。这里所使用的文本分类还包括用户产生优先级模型的统计回归。

根据本发明的一个方面，采用已知的支持矢量机器(Support VectorMachines)(SVM)作为分类器820。要理解到还可使用其它分类器模型，例如自然贝叶斯(

Bayes)、贝叶斯网(Bayes Net)、判决树以及其它学习模型。在分类器构造器和特征选择模块826中，通过学习或训练阶段来配置SVM。分类器是将输入属性矢量x＝(x1，x2，x3，x4，xn)映射到输入属于某一类的置信度，即f()＝confidence(class)。在文本分类的情况下，属性是单词或短语或从单词得出的其它域特定的(domain-specific)属性(例如语音部分、关键术语的存在)，类是重要性(interest)的类别或范围(例如优先级等级)。

SVM以及其它归纳学习方法的一个方面是采用标记的实例的训练集合来自动地学习分类函数。训练集合在与分类器构造器826相关联的数据存储器830中得到描述。如所例示的那样，训练集合可包括分组G1至GN的子集，指示出与某一类别相关联的可能的和/或实际的元素或元素组合(例如单词或短语)。数据存储器830还包括多个类别1至M，其中所述分组可与一个或多个类别相关联。在学习期间，学习将输入特征映射到类的置信度的函数。从而，在学习了模型之后，类别被表示为输入特征的加权矢量。

对于类别分类，通常采用二进制特征值(例如类别中单词出现或不出现)，或实际值特征(例如伴随着一重要性权重r而出现单词)。由于类别集合可包含大量的唯一项，通常在对分类施加机器学习技术时采用特征选择。为了减少特征数量，可根据总体频率计数来移除特征，并随后根据基于对类别的拟合的较少数量的特征来选择。对类别的拟合可通过交互信息、信息增益、x检验法(chi-square)和/或实质上任何其它统计选择技术来确定。这些较小的描述然后用作SVM的输入。注意，线性SVM提供适当的泛化精确性，以及提供适当的快速学习。其它类的非线性SVM包括多项式分类器和径向基函数，并且也可根据本发明而被利用。

分类器构造器826采用学习模型832，以便分析数据存储器830中的分组和相关类别，来“学习”将输入矢量映射到类的置信度的函数。对于包括SVM的许多学习模型，用于类别的模型可被表示为特征权重w的矢量，其中对于每个类别可存在一个经学习的权重矢量。当学习了权重w之后，通过计算x和w的点积来分类新的文本，其中w是经学习的权重的矢量，x是表示新的文本的矢量。还可提供S形函数来将SVM的输出变换到概率P。概率提供了跨类别或类的可比较的分数，从中可确定优先级。

SVM是一种用参数表示的函数，其函数形式是在训练之前被定义的。训练SVM一般需要标记的训练集合，因为SVM将从一组例子中来拟合该函数。训练集合可由一组N个例子组成。每个例子由输入矢量xi和描述输入矢量是否在类别中的类别标记yi组成。对于每个类别，在用N个例子训练的SVM中可存在N个自由参数。为了找到这些参数，如所理解的那样，解答二次规划(QP)问题。有多种已知的技术来用于解答QP问题。这些技术可包括顺序最小优化(Sequential Minimal Optimization)技术以及其它技术。如图9所描绘的那样，已被转变成输入矢量x的文本输入936被施加到用于每个类别的分类器920。分类器920使用由分类器构造器926确定的经学习的权重矢量w(例如对于每个类别一个权重矢量)，并形成点积，以提供优先级输出938，其中可向输入文本936分配概率P，指示出一个或多个相关联的优先级(例如高、中和低)。

回到图8，由箭头822所表示的文本分类器820的训练包括在826中构造分类器，包括利用特征选择。在明确训练阶段，可向分类器820给予时间关键的(time-critical)或非时间关键的文本，从而分类器可能能够在两者之间进行区分。该训练集合可由用户提供，或可使用标准的或默认的训练集合。给定一训练文集，分类器820首先施加特征选择过程，试图找到最为区别的特征。该处理采用交互信息分析。特征选择可对一个或多个单词或可用的更高级的区别(例如以自然语言处理为特征的语音的短语和部分)起作用。也就是说，文本分类器820可用专门加标志的文本来播种，以便区别那些被认为是重要的文本的特征。

文本分类的特征选择一般在单独的单词上进行搜索。除了对单独的单词的信任之外，也可使域特定的短语和高级模式的特征可用。特殊的标记也能增强分类。例如，对于电子邮件关键程度的经学习的分类器的品质可通过将被认为是有用于区别不同时间关键程度的电子邮件的手工特征输入到特征选择过程中。从而，在特征选择期间，考虑一个或多个单词以及有用于区别不同级别的时间关键程度的消息的短语和符号。

如下面的例子所例示出的那样，识别消息的关键程度的值的标记和/或模式包括诸如下列的布尔逻辑组合的区别：

消息头部中的信息

例如：

至：字段(接收者信息)

仅以用户为收信地址，

以包括用户的一些人为收信地址，

以少数人别名为收信地址，

以少数人若干别名为收信地址，

Cc：’d to user，//抄送到用户

Bcc：’d to user。//盲目复制到用户

发自：字段(发送者信息)

预先规定的重要人物的列表上的名字，可能被分段成多类个人(如家庭成员、朋友)，

被标识为用户的公司/组织内部的发送者，

从在线组织机构图中提取的相对于用户的组织关系结构的信息，在线组织机构图例如：

用户要对其进行报告的经理，

用户的经理的经，

向用户报告的人，

外部商业人士。

过去时信息

这包括关于已经发生的时间的描述，例如：

We met，              //我们过去见面

meeting went，        //会谈进行过了

happened，            //发生了

got together，        //商谈过了

took care of，        //照顾过了

meeting yesterday。   //昨天的会谈

将来时信息

Tomorrow，            //明天

This week，           //这星期

Are you going to，    //你准备……？

When can we，         //我们何时能够……？

Looking forward to，  //期待……

Will this，           //这将……

Will be。             //将会……

会谈和协作信息

Get together，        //商谈

Can you meet，        //你能会谈吗？

Will get together，   //将商谈吗？

Coordinate with，     //与……协作

Need to get together，//需要商谈

See you，             //再见

Arrange a meeting，   //安排会谈

Like to invite，      //很高兴邀请

Be around。           //来访

决定的日期

从文本模式中指示出的将来对过去的日期和时间，以明确地或典型地声明日期和时间缩略语，例如：

On 5/2，      //在5月2日

At 12:00。    //在12:00

问题

位于问号(？)附近的单词、短语

个人请求的指示：

Can you，           //你能……？

Are you，           //你是……？

Will you，          //你会……？

you please，        //您请

Can you do，        //你能做……？

Favor to ask，      //请问

From you。          //从您……

需要的指示：

I need，            //我需要……

He needs，          //他需要……

She needs，         //她需要……

I’d like，         //我愿意……

It would be great， //……太好了

I want，            //我想……

He wants，          //他想……

She wants，         //她想……

Take care of。      //照顾

时间关键程度

happening soon，        //马上发生

right away，            //立刻

deadline will be，      //期限将是

deadline is，           //期限是

as soon as possible，   //尽可能快

needs this soon，       //马上需要

to be done soon，       //马上做

done right away，       //立刻做

this soon，             //不久

by[date]，              //到[日期]

by[time]。              //到[时间]

重要性

is important，          //重要

is critical，           //关键

Word，phrase+！，       //加！的单词、短语

Explicit priority flag status(low，none，high)。

                        //明确的优先级标记状态(低、无、高)

消息长度

新消息成分的字节数。

商业和成人内容广告邮件的标志

Free！！，              //免费！！

Word+！！！，           //带有！！！的单词

Under 18，              //18岁以下

Adult’s only，         //仅针对成人

Percent of capitalized words，         //大写单词的百分比

Percent non-alphanumeric characters。  //非字母数字字符的百分比

注意，上述的单词或短语分组例示出可用于从中进行分类器训练的示例性的单词、分组或短语。要理解，可类似地采用其它类似的单词、分组或短语，从而本发明不限于上述例子。

此外，仍然参考图8，箭头824所代表的分类器820的隐含训练可通过驻留于例如用户的桌面或移动计算机上的背景监视器834监视用户工作或使用模式来进行。例如，当用户工作且查阅邮件列表时，可以假设首先读取时间关键性的消息，稍候查阅和/或删除较低优先级的消息。也就是说，当给出新的电子邮件时，用户被监视以确定他或她是立即打开该电子邮件、以什么顺序打开、不打开而删除该电子邮件、和/或以相对较短的时间回复该电子邮件。从而，分类器820被适配成在用户工作或操作系统的同时监视用户，通过在背景中进行训练来周期性地精练分类器，并进行更新以用于增强实时作出判决。利用新的训练消息，构建分类器的背景技术可从那些更新分类器820的技术中扩展出来。

可选地，可以集合更大量的消息，其中在批处理中创建新的过滤器，可以按照日程表、按照进入分类器的新的消息数量、和/或其组合。对于输入分类器的每个消息，例如，可以创建用于该分类器的一个新的范例。按照例如高或低优先级的文本的反例或正例来存储这些范例。作为一个例子，可以识别一个或多个低、中等、和高紧急的类，使得位于这些类中的每个类中的成员关系的概率被用于构建期望的关键程度。更大量的关键程度类可用于寻找更高的分辨力。例如，如图9所示，消息的训练集合940(例如非常高、高、中等、一般、低、非常低等等)最初可用于训练分类器942，使得实现实时分类，如944处所指示出的那样，其中按照训练集合940所解析的若干例子来分类新的消息。在图9中，出于示例性的目的，例示出三个这种类别，然而，要理解可根据所希望的重要性程度的变化来训练多个这样的类别。如所例示的那样，可例如根据分类器942所指定的优先级来对新的消息944进行加标记、加标签和/或分类到一个或多个文件夹946中。如下面将更为详细地描述的那样，所分配的优先级还可进一步由后续的系统使用，来对用户或为用户作出消息格式、递送和模态确定。

根据本发明的另一方面，例如，可通过监视用户对电子邮件的反应来实现某一数字或值的估计，而不是将该范例或消息标记为一组文件夹中的一个。从而，分类器可继续被更新，但具有一移动窗口，其中按照用户的规定，考虑比某一时期新的消息或文档的范例。

例如，与对消息的延迟的查阅相关联的恒速率损失被称为是消息的预期的关键程度(EC)，其中， $\mathrm{EC}=\underset{i}{\mathrm{\&Sigma;}}{C}^d\left(H_i\right)p\left(H_i\right|E^d),$ 其中C是代价函数，d是延迟，E是时间，H是电子邮件的关键程度类，EC被表示为按照可能的类的代价函数C描述的损失速率加权的类的似然性的总和。

作为一个例子，仍然参考图9，诸如电子邮件消息的文本936被输入到分类器920，分类器根据该消息用于文本936的优先级938。也就是说，分类器920生成优先级938，例如，优先级的量度为0～100％的百分比。基于分类器920的先前的训练，该百分比可以是文本为高优先级或某一其它优先级的似然性的量度。

注意，如上所述的本发明中，分类器920和优先级938可基于这样一种模式，例如，训练阶段中的电子邮件被分析成高优先级或低优先级。该模式例示于图10，其中文本分类器1020由预定为高优先级的一组文本1047和预定为低优先级的一组文本1048训练。要被分析的文本被输入到分类器820，分类器输出例如一标量数字1049，该标量数字度量被分析的文本是高优先级还是低优先级的似然性。

例如，参考图10和11，例示出文本1036、1136被分类成低、中和高优先级的模式。如上所述，可采用多个其它的训练集合来提供更大的或更高的优先级区别分辨力。文本分类器1020、1120由高优先级的一组文本1047、1147和低优先级的一组文本1048、1148，以及中等优先级的一组文本1150训练。从而，要被分析的文本1036、1136被输入到分类器1020、1120，分类器输出一标量数字1049、1149，能够度量该文本被分析为高优先级、中等优先级或低优先级的似然性。分类器1020、1120还能够输出类1152，该类指示出文本1136最可能落于其中的低、中等和高优先级类。此外，如果需要，也可添加更多的类。

本发明不限于优先级的这种定义，因为分类器1020、1120采用该术语来向诸如电子邮件消息之类的文本指定这种优先级。例如，可按照损耗函数来定义优先级。更为具体地，可按照接收文本后对该文本的查阅每次时间延迟所错过的机会中的预期代价来定义优先级。也就是由于对文本的延迟处理而造成的预期的损失或代价。损耗函数还可根据接收到的文本的类型而变化。

例如，图12中例示出一般的情况，即取决于文本的优先级的线性代价函数的曲线图1254。在曲线图1254中，随着时间增加，还为查阅文本的代价也增加。然而，如线1256、1258和1260所示，对于高优先级的消息来说，代价增加得比中等优先级的消息或低优先级的消息更多。例如，高优先级线1256可具有斜率为100，中等优先级线1258可具有斜率为10，而低优先级线可具有斜率为1。这些斜率值可随后由分类器1020、1120使用来向给定文本指定优先级，例如通过回归分析。

然而，某些消息的优先级并非可用线性代价函数来良好近似。例如，关于会谈的消息的代价函数将按照会谈时间的靠近而上升，此后，代价函数迅速下降。也就是说，在错过了会谈之后，一般来说用户不会再对其采取行动。该情况由非线性代价函数来良好近似，如图13所示。在曲线图1362中，代价函数1364迅速增加，直到它到达线1366划界的会谈时间，然后，它迅速减少。根据消息的类型，可以由许多不同的代表性的代价函数中的一个，线性的或非线性的，来近似代价函数。

从而，如已经描述的那样，文本的优先级可以恰好是作为基于分类器的输出的多个优先级之一的似然性，或同样基于分类器的输出的该文本最可能适用于的优先级。可选地，可确定诸如电子邮件消息之类的文本的预期的时间关键程度。这可被写成： $\mathrm{EL}=\underset{i}{\overset{n}{\mathrm{\&Sigma;}}}p\left({\mathrm{critical}}_i\right)C\left({\mathrm{critical}}_i\right).$ 其中EL是预期的损失，p(critical_i)是文本具有关键程度i的概率，C(critical_i)是具有关键程度i的文本的代价函数，n是关键程度类的总数减1。如上所述，代价函数可以是线性的或非线性的。在代价函数是线性的情况下，代价函数定义了随时间变化的恒定的损失率。对于非线性的代价函数，损失率随对文本的延迟查阅或处理而变化，并可根据延迟的时间量而增加或减少。

在n＝1的情况下，规定仅有两个优先级类：低和高，预期的损失可重新表示为：EC＝p(critical_high)C(critical_high)+[1-p(critical_low)]C(critical_low)。其中，EC是文本的预期的关键程度。此外，如果低关键程度消息的代价函数被设置为0，则变成：EC＝p(critical_high)C(critical_high)。直到对文本的查阅为止的总损失可被表示为所表示的关键程度的积分，即 $\mathrm{EL}={\&Integral;}_0^{t}p\left({\mathrm{critical}}_{\mathrm{high}}\right)C({\mathrm{critical}}_{\mathrm{high}},t)\mathrm{dt},$ 其中t是查阅文档前的时间延迟。

还有其它的测量符合用于对诸如电子邮件消息之类的文档进行按重要性分级的数值量度。虽然上述讨论集中在作为时间关键程度的优先级上，但是还可以训练“重要性”的其它概念。例如，可通过标记一组训练文件夹来实现：“高重要性”一直到“低重要性”，其中可确定“预期的重要性”的度量。其它量度可基于语义标记，如“我希望在旅行时在1天之内接收到的消息”，并确定用于划分消息的优先级以转发到旅行的用户的度量。此外，所利用的一种量度是紧急程度或时间关键程度，因为它具有明确的语义用于作出判决、筛余和转发。在该情况下，根据不同等级的紧急程度来对类进行标记，并从推断出消息处于每个类中的概率中按照每个消息的预期的紧急程度来计算。

如在先前的部分中所描述的那样，还可根据本发明提供对关键程度分类的扩展。例如，分类可包括在特征的类之间或之内自动搜索高性能指标(payoff)特征的组合。作为一个例子，在分类过程中可搜索和使用那些特殊区别、结构等与已被发现对于某些用户特别有用的单词的组合。两个特征的组合被称为是两个一对(doublet)，三个特征的组合被称为是三个一组(triplet)，依此类推。特征的组合可允许改进的分类。

还可利用在分类器中采用移动窗口的递增索引来改进分类。这使得随着旧数据到期而新数据到来，分类器能够定期地被刷新。

分类器还可基于对消息中规定的某一事件的日期和时间的确定。该确定能够向消息分配可由分类器使用的特征。例如，所分配的特征可包括：今天在四小时内、今天在八小时内、明天、本周、本月、下个月以及下个月以后。这使得分类器能够对所分类的消息具有改进的精确性。一般来说，分类可基于所引用的事件的时间，考虑该事件是将要到来的还是已经过去的。就将来的事件而言，分类从而考虑事件将要发生的将来中的时间的发送者的参考。

其它新的特征也可被结合于分类过程中。例如，可使用组织机构图来按照图内发送者的位置确定消息有多么重要。语言学特征可结合于分类器中。为了适应不同的语言，可根据发送者的出身和/或编写该消息所采用的语言来修改特征。分类可根据存储消息的不同文件夹而进行改变，也可根据其它定标和控制规则。除了电子邮件和其它源之外，可对即时消息、以及诸如证券报价机之类的其它信息源等等进行分类。

一般来说，在分类过程中可考虑发送者-接收者结构关系。如果用户实际上仅仅是消息的接收者，则例如该消息可被认为是比发送到少量人的消息更为重要。接着，发送到少量人的消息可能比盲目复制(bcc’ed：blind-copied)到用户或抄送到(cc’ed：carbon-copied)用户的消息更为重要。就发送者而言，可根据发送者的姓名是否被认出来分配关键程度。还可根据发送者对于用户相关的组织来说是组织外部还是内部人员来分配关键程度。

在分类中可考虑的其它区别可包括消息的长度、是否检测到问题、用户的姓名是否在消息中。与时间关键程度相关联的语言可增加消息的重要性。例如，诸如“马上发生”、“立即”、“尽可能快”、“ASAP”以及“期限是”等之类的短语可使得消息更为关键。与将来时相比，可考虑过去时的使用，以及由诸如“商谈”、“我们能会谈吗”等等之类的短语规定的协作任务。广告邮件的迹象会降低消息的优先级。在分类过程中还可包括了表示组合的谓语，例如来自最接近于组织机构图中的用户的一发送者的一个简短问题。

在本说明书的以下部分中，描述了提供何时向用户通知有高优先级文本的判断的过程，高优先级文本例如具有比用户设置的阈值高或比判决理论推理所确定的阈值高的高优先级的似然性的文本。也就是说，除了知道时间关键的消息之外，判断例如在用户没有直接查阅收到的电子邮件的情况下，何时通知用户时间关键的消息，这也是重要的。一般来说，确定将用户注意力从当前正在解决的当前任务中转移到了解该时间关键的消息的代价。

可选地，可采用用于警告和通知的各种策略。这些策略可在通知平台架构内实现，例如，在下文中更为详细地描述的那样。这些策略中的一些策略包括：

●设置关于总损失的用户规定的上限。该策略将规定当与延迟查阅某一消息相关联的总损失超过某一预先规定的“可容许”的损失“x”时，生成一告警。

●另一策略可以是基于更为完整的判决理论分析的成本效益分析，例如NEVA＝EVTA-ECA-TC，其中NEVA是预期的告警净值，EVTA预期的告警值，ECA是告警的预期代价，TC是与传播消息有关的传输费用。

一般来说，当成本效益分析认为用户在时刻t不查阅消息而会发生的预期的损失高于通知用户的预期的代价时，应当向用户告警。也就是说，如果EL-EC＞0，则应当进行告警，其中EL是在当前时刻t不查阅文本的预期损失，EC是在当前时刻t向用户通知该文本的预期代价。预期损失在本说明书的先前部分中有述。

然而，上述的公式可能并非是最精确的，因为用户通常在将来主动地查阅消息。因此，实际上，当被称为是EVTA的预期的告警值是正的，一般应当向用户告警。从而，与不用告警用户稍候主动地查阅消息的值相对，预期的告警值应当考虑现在向用户通知文本的告警值减去告警的代价。这可被规定为：EVA＝EL_alert-EL_no-alert-EC，其中，EL_alert是用户在被告警时如果现在查阅消息的预期损失，EL_no-alert是用户在某一时间点不用被告警而主动地查阅消息的预期损失，EC是基于注意力转移的考虑和基于传送信息的直接代价的预期的告警代价。

此外，可把来自若干消息的信息组在一起称为单个复合的告警。与转播关于单个消息的信息的告警相比，在一个告警中查阅关于多个消息的信息代价更高。这种注意力转移中的增加可通过告警的代价作为其信息复杂性的函数来表示。可假设电子邮件的EVA与其它电子邮件消息的EVA无关。例如，EVA(M_i，t)指的是在时刻t向用户告警单个消息的M_i值，ECA(n)指的是转播n个消息的内容的预期代价。从而，可通过将转播关于一组n个消息的信息的预期值加在一起来考虑多个消息，其中： $\mathrm{NEVA}=\underset{i=1}{\mathrm{\&Sigma;}}\mathrm{EVA}(M_i,t)+\mathrm{ECA}\left(n\right).$

还注意到，为了确定告警的预期值，推断或直接访问关于用户是否在场的信息是有用的。可采用指示出用户何时处于办公室中的传感器，例如红外传感器和压力传感器。然而，如果没有这种设备，则可按照例如计算机上的用户活动的函数来指定用户处于办公室内的概率，例如最后观察到的鼠标或键盘活动后经过的时间。此外，还可采用日程表中可用的计划安排信息，来推断用户的位置和距离，以及考虑通过不同的处理将消息转发到用户的代价。

同样重要的是在进行关于用具有高时间关键程度的消息的信息打断用户的判决中知道用户有多忙。可以推理(例如推理性的判决)用户是否在操作计算机和用户在操作计算机的比率、用户是否在打电话和用户打电话的比率、用户是否与某人交谈和用户与某一交谈的比率、或用户是否在另一位置参加会谈和用户在另一位置参加会谈的比率。可采用若干类的证据来评估用户的活动或他或她的注意力焦点，如图14所例示的那样。然后可使用贝叶斯网络进行关于用户的活动的推理。这种网络的一个例子示于图15。

一般来说，应当根据对预期的关键程度和用户活动的推断，作出关于何时以及如何向用户告警消息以及提供服务的判决。例如，可利用判决模型来进行判决。图16至图18是例示出这些判决模型如何可用于作出告警判决的影响图。图16显示出用于关于打断用户、考虑当前活动、消息的预期的时间关键程度、以及基于通信模态的告警代价的判决的判决模型。图17还包括了表示当前位置的变量以及变量对活动以及可选的消息发送技术的代价的影响。此外，图18扩展到当带有重要图形内容的消息被转发到用户而不呈现图形内容时，与逼真度中的损失相关联的代价。

可选地，可采用一组用户规定的定义关于告警的策略的阈值和参数来作出关于何时和如何告警用户的判决。例如，可根据鼠标或键盘的活动来推断用户的存在性。从而，例如，可允许用户能够输入关于告警活动非活动的推断状态的阈值。用户还能够输入活动之后跟随的空闲活动的量，其中告警将以较低的关键程度发生。如果根据实质上没有检测到任何计算机活动的时间判断出用户没空，则可存储消息，并在用户返回到与计算机进行交互时，按照关键程度向用户报告。此外，用户可将路由和寻呼选项规定为包括预期的关键程度、最大预期损失、以及告警用户的值在内的量的函数。

通知和/或告警系统还可估计预期用户何时返回，使得它在预期用户返回之前传送预期为重要的优先级。这可通过学习随时间的经过的用户存在和用户离开模式来实现。然而用户可在他或她预期何时返回到系统、不用被告警而查看优先级方面设置适当策略。系统确定的预期的返回时间可自动地被传达给例如高度紧急的消息的发送者。以此方式，消息发送者接收关于用户预期何时返回使得他或她能够回答消息的反馈。发送者还可被告知她或她的消息已被转移到用户的移动设备等等。

图19例示出根据本发明的用于生成优先级以及根据优先级进行告警判决的方法。虽然，出于解释简单的目的，所示和所描述的方法为一系列的动作，但是，要理解到本发明不限于动作的顺序，根据本发明，某些动作可以不同的方式发生，和/或与这里所示和所描述的不同的其它动作同时发生。例如，本领域的技术人员将理解到可把某一方法表示成一系列的相关状态或事件，例如状态图。而且，对于实现根据本发明的方法来说，并非所有的例示出的动作都是必需的。

参考图19，流程图1974例示出根据本发明的生成和利用优先级的方法。在1980处，接收到诸如文本之类的要被指定优先级的数据。数据可以是电子邮件消息，或实质上可以是任何其它类型的数据或文本。在1982处，根据已描述的分类器生成数据的优先级。此外，1982可包括对分类器的初始和后续训练，如已描述的那样。

随后，在1984输出数据的优先级。如图19中所指示出的那样，这可包括1986、1988、1990、1992和1994处的处理。在1986处，确定当前时刻t处不查阅数据的预期损失。基于用户将在将来不用被告警而自己查阅文本的假设，该确定考虑了在一未来时刻进行文本的当前查阅的预期损失(如已经描述的那样)。在1988处，确定预期的告警代价(如已经描述的那样)。在1990处，如果损失大于代价，则在1992处，在时刻t不作出告警。随着时间前进，可以进行继续回到1986，在某一点，预期损失可能查过告警代价，从而在1990处的计算发生改变。当预期损失超过告警代价时，在1994处，进行向用户或其它系统告警。

现在描述向用户或其它系统告警的输出。可根据指示出何时应当向用户告警被划分了优先级的文本的告警标准在电子设备上告警用户。该电子设备可以是寻呼器、蜂窝网/数字移动电话机、或其它通信模态，下文详述。在诸如寻呼器或移动电话机上向用户告警可基于适配成敏感于关于例如用户的位置信息、推断的任务、和/或注意力焦点之类的信息的告警标准。这种信息可被不确定地推断出，或可从在线信息源中被访问出。例如，来自在线日程表的信息可被适配成控制用于作出关于将信息转发到诸如通知信宿(下面详细描述)之类的设备的判决的标准。

可通过根据路由标准对划分了优先级的文本或其它数据进行路由来进行告警。在文本是电子邮件的情况下，文本的路由转发可包括传送文本、和/或向文本的发送者回答。例如，可播放声音来告警用户有关划分了优先级的文档。可选地，可打开一代理或自动助理(例如交互显示向导)。也就是说，该代理可出现在显示屏幕上，通知用户关于划分了优先级的文档。此外，可打开划分了优先级的文档，例如显示在屏幕上。文档可受到关注。这还可包括根据其优先级来划分大小，使得越高优先级的文档，显示的窗口越大，和/或根据优先级在显示器上将文档定位在中间。

参考图20，示出根据本发明的一方面的文本生成和优先级系统2000的示图。系统2000包括程序2002和分类器2004。注意，程序2002和分类器2004可包括计算机的处理器从计算机可读介质执行的计算机程序。

程序2002生成文本用于输入到分类器2004。程序包括接收电子邮件的电子邮件程序，电子邮件充当文本。分类器为相关的消息产生优先级。如上所述，分类器2004可以是贝叶斯分类器、支持矢量机器分类器或其它类型的分类器。由分类器2004输出的文本的优先级然后连同一成本收益分析一起被使用，如已描述的那样，用于实现基于其的进一步输出和/或告警。

现在转到图21，系统2100例示出根据本发明的一方面的首选项执行引擎和上下文环境分析器如何一起起作用。系统2100包括上下文环境分析器2122、首选项执行引擎2124、一个或多个事件或通知源1至N(2126、2127、2128)、充当通知源的优先级系统2130、以及一个或多个动作或通知信宿1至M(2136、2137、2138)，其中N和M分别是整数。根据本发明的一方面，源也可被称为是事件发布器，信宿也可被称为是事件订户。可以有任何数量的信宿和源。一般来说，部分地根据上下文环境分析器2122中存储的和/或由其访问的参数信息，执行引擎2124将也被称为是事件或告警的通知从源2126-2128传递给信宿2136-2138。

上下文环境分析器2122存储/分析关于影响作出通知判决的用户的变量和参数的信息。例如，参数可包括上下文环境信息，例如用户在每天的每个时间或每星期的每天的典型位置和注意力焦点或活动，参数还可包括以这些参数为条件的其它参数，例如用户易于在不同的位置访问的设备。这些参数也可以是通过一个或多个传感器自主地作出的观察值的函数。例如，可根据例如全球定位系统(GPS)子系统提供的用户的位置的信息、根据正被使用的设备的类型和/或设备的使用模式的信息、以及用户最后一次访问某一类型的设备的时间，来选择或修改一个或多个配置文件(未示出)。此外，如下面更为详细地描述的那样，还可采用自动推断，来动态地推断诸如位置和关注之类的参数或状态。配置文件参数可按照可由用户编辑的用户配置文件来存储。除了依赖于预定的配置文件的集合或动态推断之外，通知架构能够使得用户能实时地规定他或她的状态，例如对于接下去的“x”个小时或知道某一给定的时间，除了对于重要的通知之外，用户都没空。

参数还可包括与关于在不同设置中被不同类型的通知打扰的用户的首选项有关的默认通知首选项参数，可用作执行引擎2124作出通知判决的基础，并且用户可根据它而发起改变。参数可包括关于在不同的情况下(例如移动电话机、寻呼器)用户如何希望被通知的默认参数。参数可包括诸如与被不同设置中的不同模式通知相关联的中断的代价之类的评估。这可包括上下文环境参数，指示出用户位于不同位置的似然性、不同设备可用的似然性、以及他或她在给定时间的关注状态的似然性，还可包括指示出用户如何希望在一给定时间被通知的通知参数。

根据本发明的一方面，上下文环境分析器2122存储的信息包括由分析器确定的上下文环境信息。该上下文环境信息是由分析器2122通过根据以个或多个上下文环境信息源(未示出)鉴别用户的位置和关注状态来确定的，如下面的描述中将更为详细地描述的那样。例如，上下文环境分析器2122可通过作为用户的汽车或移动电话机的一部分的全球定位系统(GPS)来精确地确定用户的实际位置。分析器还可采用统计模型，通过考虑背景估计和/或观察值来确定用户处于给定的关注状态的似然性，其中，所述背景估计和/或观察值是通过考虑诸如日期类型、一天的时间、用户日程表中的数据以及关于用户的活动的观察值来收集的。给定的关注状态可包括用户是否有空接收通知、还是忙碌、或者是没空接收通知，以及可包括诸如工作日、周末、假日和或其它时机/时期之类的其它考虑。

源2126-2128、2130产生用于用户和/或其它实体的通知。例如，源2126-2128可包括诸如因特网和基于网络的通信、电话通信以及软件服务之类的通信。一般在这里将通知源定义为生成事件(也可被称为是通知和告警)，意图向用户或用户的代理告警信息、服务和/或系统或世界事件。通知源还可被称为是事件源。

例如，可由优先级系统2130按照通知来生成电子邮件，使得它被划分优先级，其中生成通知的应用程序或系统向电子邮件分配对应于该电子邮件对于用户来说的可能的重要性或紧急程度的相对优先级。也可不管对于用户的相对重要性来发送来电子邮件。与因特网相关的服务可包括包含用户已订阅的信息的通知，例如时常的当前新闻的标题以及股票报价。

通知或事件源2126-2128本身可以是推式(push type)或拉式(pull type)源。推式源无需请求而自动地生成和发送信息，例如标题新闻，以及在被订阅之后自动地发送信息的其它基于因特网的服务。拉式源响应于请求来发送信息，例如在挂号通信电子邮件服务器之后接收电子邮件。还有其它的通知源包括：

●诸如日程表系统之类的电子邮件桌面应用程序；

●计算机系统(例如可向用户通知关于与系统活动或问题有关的告警的信息)；

●与因特网相关的服务，约会信息、计划安排查询；

●一个或多个共享文件夹中的文档中或某些类型的文档数中的变化；

●响应于对信息的持续的或不变的查询的新的文档的可用性；和/或

●关于人及其存在性、他们的位置变化、他们的接近程度(例如当我在旅行时告诉我是否有另一个同事或朋友在我10英里范围内)、或他们的可用性(例如，当Steve能够进行对话并靠近能够支持全视频会话的高速链路时告诉我)的信息的信息源。

通知动作信宿2136-2138能够向用户提供通知。例如，这些通知动作信宿2136-2138可包括诸如桌面和/或膝上型计算机、手持计算机之类的计算机、移动电话机、陆线电话机、寻呼器、基于汽车的计算机、以及其它系统/应用程序。注意，信宿2136-2138中的一些能够比其它信宿更为丰富地传递通知。例如，桌面计算机一般具有扬声器和相对较大的彩色显示器，并且在耦合于局域网或因特网时，具有较高的接收信息带宽。从而，可以相对较为丰富的方式通过桌面计算机向用户传递通知。相反，许多移动电话机的显示屏较小，它们可能是黑白的，以较小的带宽接收信息。因此，与移动电话传递的通知相关联的信息可能一般较短，并适合于电话的界面能力。从而，根据通知被发送到移动电话机还是桌面计算机，通知的内容可以不同。根据本发明的一个方面，通知信宿可指例如通过事件订阅服务订阅事件或通知的那些通知信宿。

执行引擎2124访问上下文环境分析器存储和/或确定的信息，并确定从源2126-2128接收的哪个信息要被传递到哪个信宿2136-2138。此外，引擎2124可根据哪个信宿2136-2138已被选择向其发送信息来确定如何传递通知。例如，可确定通知被提供给所选择的信宿2136-2138之前应当被汇总概括。

本发明不限于引擎2124如何作出关于哪个通知被传递到哪个通知信宿，以及以何种方式传递通知的判决。根据一个方面，可利用判决理论分析。例如，执行引擎2124可被适配成推断关于包括用户的位置、关注、设备可用性、在没有告警的情况下直到用户将要访问信息为止的时间量的变量的重要的不确定因素。通知引擎2124随后可作出关于是否要向用户告警通知的通知判决，如果是，则作出用于转发通知的汇总概括性质和适当的设备。一般来说，执行引擎2124确定通知的净预期值。在这样做时，可考虑下列：

●每个可用的通知信宿的逼真度和传送可靠性；

●打扰用户的值得注意的代价；

●信息对用户的新颖性；

●到用户将主动查阅信息为止的时间；

●信息的可能的上下文环境敏感的值；和/或

●包含在通知内的信息随时间的经过的增加和/或减少的值。

从而，例如，给定用户的某一关注状态，使用某一设备的某一模式，可按照诸如对用户的打扰的代价之类的值的预期似然性来生成关于不确定因素的推断。执行引擎2124可按照下列的一个或多个作出判决：

●用户当前意图做什么以及正在做什么(基于例如上下文环境信息)；

●用户当前在哪里；

●信息有多么重要；

●延迟该通知的代价是什么；

●通知将有多么令人注意力转移；

●与用户联系的似然性是什么；以及

●与给定通知信宿的特定模式的使用相关的逼真度损失。

因此，执行引擎2124能够执行对待决的和活动的通知的分析，例如判决理论分析，评估信息信宿和源提供的与上下文环境有关的变量，以及推断所选择的不确定因素，例如到用户可能查阅信息为止的时间以及用户的位置和当前关注状态。

此外，执行引擎2124能够访问上下文环境分析器2122存储于用户配置文件中的信息，以代替个人化的判决理论分析。例如，用户配置文件可指示出在一给定时间，仅当通知具有预定的重要性程度时，用户希望通过寻呼器来被通知。这种信息可被用作基准，以此基准为基础开始判决理论分析，或者这种信息可作为执行引擎2124确定如何和是否通知用户的方式。

根据本发明的一个方面，通知平台架构2100可被配置成驻留于事件发生(eventing)或消息传递基础结构上的一层。然而，本发明不限于任何特定的事件发生基础结构。这种事件发生和消息传递系统和协议可包括：

●本领域中已知的超文本传输协议(HTTP)或HTTP扩展；

●本领域中已知的简单对向访问协议；

●本领域中已知的Windows管理工具；

●本领域中已知的Jini；以及

●诸如基于分组交换协议的那些协议之类的实质上任何类型的通信协议。

此外，该架构可被配置成驻留于灵活的分布式计算基础结构上的一层，这对于本领域的技术人员来说是能够理解的。从而，通知平台架构2100可利用底层的基础结构，作为源发送信息、告警和事件的方式，以及作为信宿接收通知、告警和事件的方式。然而，本发明不限于此。

参考图22，在本说明书先前部分中描述的信息代理系统基础结构的上下文环境分析器2122在此在系统2200中得到更为详细的描述。图22中所例示出的上下文环境分析器2222包括用户通知首选项存储器2240、用户上下文环境模块2260，所述用户上下文环境模块2260包括用户上下文环境配置文件存储器2262以及白板2264。根据本发明的一个方面的上下文环境分析器2222可被实现为计算机的处理器从计算机可读介质执行的一个或多个计算机程序，计算机可读介质包括但不限于存储器。

首选项存储器2262存储用户的通知参数，例如用户的默认通知首选项，例如用户配置文件，它可由用户编辑和修改。首选项存储器2262可被认为是存储了关于影响用户如何被通知的参数的信息的存储器。如这里已经描述的那样，用户可使用模式化的逻辑，例如以IF-THEN模式来规定首选项。用户上下文环境模块2260根据例如公布到白板2264的一个或多个上下文环境信息源2280来确定用户的当前上下文环境。用户上下文环境配置文件存储器2262存储用户的上下文环境参数，例如用户的默认上下文环境设置，它可由用户编辑和修改。也就是说，用户上下文环境模块2260通过访问来自配置文件存储器2262的信息和/或通过一个或多个上下文环境源2280利用实况感测更新存储器2262中的看法(belief)的先验集合，来提供关于用户的当前上下文环境信息的最佳猜测或估计。配置文件存储器2262可被认为是存储了例如用户在哪里以及用户在做什么的先验知识。

用户上下文环境配置文件存储器2262可以是预先评估和/或预先定义的用户配置文件，它捕获诸如确定性的或概率的配置文件。配置文件可以是关于典型的位置、活动、设备可用性以及作为诸如一天中的时间、每日的类型和用于与一个或多个设备的交互之类的观察值的函数的不同类的通知的代价和值。例如，每日的类型可以包括工作日、周末和假日。用户上下文环境模块2260能够随后主动地推断或确定用户的上下文环境或状态的特征，例如用户的当前或将来位置和关注状态。此外，上下文环境的实际状态可以直接从上下文环境信息源2280通过白板2264来访问，和/或从多种观察值通过诸如贝叶斯推理之类的推断方法来推断，如下面更为详细描述的那样。

上下文环境信息源2280可通过白板2264向上下文环境模块2260提供关于用户的关注状态和位置的信息，从中模块2260可作出关于用户的当前上下文环境的判定(例如用户的当前关注状态和位置)。此外，本发明不限于某一特定数量或类型的上下文环境源2280，也不限于用户上下文环境模块2260推断或访问的信息类型。然而，上下文环境源2280可包括多个桌面信息和事件，例如鼠标信息、键盘信息、应用程序信息(例如哪个应用程序当前正被用户所关注)，环境声音和话语信息、桌面上的窗口中的文本信息。白板2264可包括公共存储区域，上下文环境信息源2280可向公共存储区域公布信息，并且包括源和上下文环境模块2260在内的多种组件可从公共存储区域访问该信息。事件或动作(也被称为是通知或告警)一般可包括关于一个或多个世界状态的观察值的信息。这些状态可包括系统组件的状态、用户的活动、和/或对环境的度量。此外，事件可由测量设备和/或事件的源的主动轮询、由对由于变化而发送的信息的接收、和/或按照恒定的或变化的事件心跳来产生。

其它类型的上下文环境源2280可包括用户的个人信息管理器(PIM)信息，例如它一般能够提供关于用户的计划安排的计划安排信息。例如可由全球定位系统(GPS)和/或可被确定位置的用户的移动电话机、PDA或膝上型设备的接入来确定的用户的位置也是上下文环境源2280的类型。此外，实时移动设备使用也是一类上下文环境源2280。例如，诸如移动电话机之类的移动设备可能能够确定它当前是否正被用户访问，以及设备的取向和倾斜(例如指示出关于设备使用的信息)，以及加速度和速度(例如指示出用户是否移动的信息)。

参考图23，更为详细地描述了上述的通知源。通知源2326-2328一般生成被传递给通知执行引擎2324的通知，通知执行引擎2324确定何时应当发生通知，哪个通知应被传递给哪个通知信宿2336-2338，以及以何种顺序进行。

根据本发明的一个方面，通知源2326-2328能够在标准的属性和关系说明中具有一个或多个下列参数，这里称为通知源模式或源模式。注意，可为源、信宿和上下文环境信息源提供模式。这些模式提供关于不同组件的声明性信息，并能够使得源2326-2328、通知引擎2324、信宿2336-2338以及上下文环境分析器2322互相共享语义信息。从而，不同的模式提供了关于与通知相关联的性质、紧急程度和设备信号发送模态的信息。也就是说，模式可一般被定义为类和类之间的关系的集合，定义了通知和事件的结构，包含事件或通知类、源、目标、事件或通知语义、本体内容信息、观察可靠性、以及实际上任何服务质量属性之类的信息。

通知源模式的参数(未示出)可包括下列的一个或多个：消息类；相关性；重要性；时间关键程度；新颖性；内容属性；逼真度折衷、和/或源信息汇总概括信息。通知源生成的通知的消息类指示出通知的通信类型，例如电子邮件、即时消息、数值金融更新、桌面服务等。通知源生成的通知的相关性指示出，对于一个或多个规定的上下文环境来说，包含于通知内的信息是相关的似然性。例如，可通过一逻辑标记来提供相关性，指示出源是否对于一给定上下文环境来说是相关的。通知的新颖性指示出用户已经直到包含于通知内的信息的似然性。也就是说，新颖性是随着事件的经过，信息是否对于用户来说是新的(指示出是否用户现在知道信息，(如果发生的话)用户将在未来何时不用被告警就知道该信息)。

与通知相关联的逼真度折衷指示出例如可能由不同形式的规定的允许的截短和/或汇总概括而产生的通知内信息的值的损失。这种截短和/或汇总概括对于要被传送到可能具有带宽和/或防止信宿完全接收原始生成的通知的其它限制的某些类型的通知信宿2336-2338的通知来说是必需的。逼真度一般指的是与通知相关的原始内容的完整性质和/或程度。例如，长的电子邮件消息可能被截短，或者另外被汇总归纳成移动电话机所允许的最大100个字符，导致逼真度损失。类似的，包含文本和图形内容的原始消息在通过仅具有文本能力的设备传送时会导致逼真度损失。逼真度折衷指的是在排序(例如以图形第一、声音其次的顺序再现重要性)和/或指示出随着逼真度的变化通知的内容的总值如何减少的代价函数方面声明的源的一组逼真度首选项。例如，逼真度折衷可描述与完整的电子邮件消息的传输相关联的全部值如何随着增加的截短量而变化。内容属性例如可包括内容的性质的汇总概括，表示诸如核心消息是否包括文本、图形和声音成分之类的信息。内容本身是实际的图形、文本和/或声音，它们构成通知的消息内容。

假设信息在当前上下文环境中是相关的，通知的重要性指的是包含于通知内的信息对用户的值。例如，重要性可被表示成信息对用户的价值的货币值。时间关键程度指示出通知中包含的信息的值中的依赖于时间的变化，即信息的值如何随时间变化。在大多数但非所有情况下，通知的信息的值随时间减少。这例示于图24。曲线图2400描绘出随时间变化绘制的通知的效用。曲线图中的点2402表示初始时间，指示出通知的重要性，而曲线2404指示出效用随时间减小。

回到图23，用于不同通知源或源类型的默认属性和模式模板可存在于存储于用户通知首选项存储器(例如图22的存储器2240)中的通知源配置文件中。这种默认模板可被控制用于在通知源提供的值或属性错过源提供的模式时，覆盖这些值或提供属性。源汇总概括信息使得源能够发送可从源得到的信息和可能的通知的状态的一般汇总概括。例如，来自发消息的源的源汇总概括信息可包括关于至少为某一优先级的未读取的消息的总数的信息、人们尝试与用户通信的状态、和/或其它汇总概括信息。

通知信宿2336-2338可以实际上是可借助来通知用户或其它实体有关包含在通知内的信息的任何设备或应用程序。关于采用哪个信宿或哪些信宿来传递某一通知的选择是由通知引擎2324确定的。

通知信宿2336-2338可具有模式中提供的下列参数的一个或多个。这些参数可包括设备类；发信号(发告警)的模式；以及用于相关模式的逼真度/再现能力、传输可靠性、通信的实际代价、和/或中断的注意代价。对于适配用于参数化控制告警属性的设备来说，用于设备的模式可额外地包括对告警属性和用于控制属性的参数的说明，以及其它属性(如传输可靠性、分布代价)随着告警属性的不同设置而变化的函数。用于通知信宿的模式提供了通知设备与通知执行引擎2324和/或系统的其它组件通信关于它们的性质和能力的语义信息的方式。用于不同设备类型的默认属性和模式模板可存在于存储于用户通知首选项存储器(例如图22所示的存储器2240)中的设备配置文件中。这些默认模板可被控制来在设备提供的值或属性错过这些设备提供的模式时覆盖这些值或提供属性。

现在描述每个模式参数。设备的类指的是设备的类型，诸如移动电话机、桌面型计算机、和膝上型计算机等。类也可更为一般，例如移动的或固定的设备。发信号的模式指的是给定设备向用户告警通知的方式。设备可具有一个或多个通知模式。例如，移动电话机可以仅仅是振动，可仅以某一音量响铃，和/或振动加响铃。此外，用于告警系统的桌面显示器可被分解成若干分立模式(如显示器的右上角的小的通知窗口，屏幕的顶端处的小缩略图——可具有或不具有声音信使)。除了局限于一组预定义的行为之外，设备能够按照设备定义的一部分来允许具有告警属性的模式，它们是参数的函数。这些用于模式的连续不断的告警参数代表了诸如在桌面播放告警的音量、移动电话机的响铃、以及告警窗口的大小之类的控制。

通知信宿2336-2338的模式的传输可靠性指示出用户将接收到通过该信宿以该模式传递给用户的通知的告警的似然性。由于传输可靠性可依赖于设备可用性和用户的上下文环境，设备的不同模式的传输可靠性可取决于诸如用户的位置和关注之类的上下文环境属性。还可规定一个或多个唯一上下文环境状态的传输可靠性，所述一个或多个唯一上下文环境状态按照诸如唯一位置和唯一关注状态之类的属性的叉积来定义，所述唯一位置和唯一状态按照这些属性(例如对于离开家的任何位置，以及早上8点以后和中午之间的任何时间段)的抽象创建的逻辑或来定义。例如，根据用户当前在哪里，发送到移动电话机的信息并不总会到达用户，尤其是当用户处于间歇覆盖区或用户一般在该位置(如家庭假日)不易于具有移动电话机的情况更是如此。上下文环境也能够影响传输可靠性，这是由于环境噪声和/或上下文环境的其它屏蔽或转移注意力性质。

通信的实际代价指示出信息包含于传递给信宿的通知中时将信息通信给用户的实际代价。例如，该代价可包括与移动电话机传输相关的费用。中断的代价包括与在某一上下文环境中设备的某一模式采用的告警相关联的中断有关的注意代价。注意代价一般敏感于用户的关注的特殊焦点。逼真度/再现能力是给定模式下设备的文本、图形和声音/触觉能力。例如，移动电话的文本限制可以是对于任何单个消息为100字符，该电话机可能不具有图形能力。

转到图25，界面2500例示出根据本发明的一方面能够直接地实现上下文环境说明。例如，窗口2502具有关注焦点部分2520和位置部分2540。在焦点部分2520中，用户能够例如复选一个或多个复选框2522，指示出用户是否总能够接收告警；用户不能接收告警；以及用户仅能够接收具有比预定阈值高的重要性等级的告警。要理解，可提供其它的可用选择。如图25中描绘的那样，可以货币来度量阈值，但是这仅仅是出于示例性的目的，本发明不限于此。用户能够通过直接输入新的值或通过利用箭头2526来增加或减少阈值来改变框2524中的阈值。

在位置部分2540中，用户能够复选一个或多个复选框2542，以指示出用户希望将告警传递到哪里。例如，用户能够使得告警传递到桌面、通过电子邮件传递、传递到膝上型设备、传递到移动电话机上、传递到他或她的车里、传递到寻呼器上、或传递到个人数字助理(PDA)设备上等等。然而要理解，这些仅仅是示例，本发明不限于此。

窗口2502可被认为是默认的用户配置文件，其中可以有用于部分2520的复选框2522和框2524以及部分2540的复选框2542的阈值默认选项。配置文件是用户可修改的，用户能够利用他或她自己希望的选项来替换默认选项。根据本发明，还可使用其它类型的配置文件。

此时参考图26，例示出根据本发明的一方面的例如使用一个或多个传感器通过直接测量对用户上下文环境的确定。用户的上下文环境可包括用户的关注焦点以及他或她的当前位置。然而，本发明不限于此。上下文环境的直接测量指示出可采用传感器来检测用户当前是否有义务接收告警，以及检测用户当前在哪里。根据本发明的一个方面，可利用推断分析连同直接测量一起来确定用户上下文环境，如说明书的后面的部分中所述的那样。

参考图26，例示出可实现用户上下文环境的直接测量的系统2600。系统2600包括上下文环境分析器2602，以及通信上与之耦合的多个传感器2604-2616，即例如移动电话机2604、摄像机2606、话筒2608、键盘2610、PDA2612、车辆2614、GPS 2616。图26中描绘的传感器2604-2616仅出于示例性目的，不是对本发明的任何限制。这里所使用的术语“传感器”是一般性的和极度包容的术语，指的是上下文环境分析器2602可借助来确定用户的当前关注焦点是什么和/或用户当前位置在哪里的任何设备或方式。

例如，如果用户有移动电话机2604，则这可指示出用户能够在移动电话机2604上接收告警。然而，如果用户当前正在用移动电话机2604通话，则这可指示出用户的关注焦点在其它事情上(即当前的电话呼叫)，使得用户当前不应被通知告警所打断。摄像机2606例如能够位于用户的办公室内，检测用户是否处于他或她的办公室内(即用户的位置)，以及是否有其他人也在用户的办公室内，以检测到用户是否在与其他人谈话从而用户不应被打断，以及检测到用户是否在键击键盘(例如通过从中发出的声音)使得用户当前不应被打断。也能采用键盘2610来确定用户当前是否正在键击，使得例如如果用户正在非常快速地键击，则这可指示出用户关注于与计算机相关的活动，从而不应被不适当地打断(还可指示出用户实际上在他或她的办公室内)。

如果PDA设备2612正被用户访问，则这可指示出用户能够在该设备2612处接收告警，即通知应当被传递到的位置是该设备2612所位于的任何地方。设备2612还可用于确定用户的当前关注焦点。车辆2614可用于确定用户当前是否在车内，即是否车辆当前正由用户操作。此外，可考虑例如车辆的速度来确定用户的关注焦点是什么。例如，如果速度大于某一预定速度，则可确定用于在关注于驾驶，并且不应被通知告警打扰。GPS设备2612也可用于确定用户的当前位置，这是本领域中已知的。

在下面的详细描述中，描述根据用户可修改的规则对用户上下文环境的确定。用户的上下文环境可包括用户的关注焦点以及他或她的当前位置。然而，本发明不限于此。通过规则确定上下文环境指示出可遵循分级的一组if-then规则，来确定用户的位置和/或关注焦点。

参考图27，例示出示例性的分级排序的一组规则2700。例如，规则集2700描述了规则2702、2704、2706、2708、2710、2712以及2714。注意，可类似地配置其它规则。如图27所示，规则2704和2706为规则2702的次级，规则2706为规则2704的次级，规则2714为规则2712的次级。规则被排序成：规则2702首先被检查；如果为真，则检查规则2704，如果规则2704为真，则检查规则2706，依此类推。如果规则2704为假，则检查规则2708。如果规则2702为假，则检查规则2710。如果规则2710为真，则检查规则2712，如果规则2712为真，则检查规则2714。规则是用户可创建和/或可修改的。在规则集中还可包括其它类型的规则(例如如果if-then规则为假，则其它规则进行控制)。

从而，可由用户来构造一组规则，使得确定用户的上下文环境。例如，就位置而言，规则集可以是，第一规则检查当前日子是否是工作日。如果是，则作为第一规则的次级的第二规则检查当前时间是否为早上9点至下午5点之间。如果是，则第二规则指示出用于位于他或她的办公室内，否则用户在家。如果第一规则为假，即当前日子是周末或非工作日，则另外的规则可声明用户在家。注意，该例子并不意味着对本发明的限制，可以类似地配置一个或多个其它规则。

在下面的描述中，描述通过诸如采用统计和/或贝叶斯模型之类的推断分析对用户上下文环境的确定。注意，通过推断分析进行的上下文环境确定可依赖其它确定的某些方面，例如通过传感器的直接测量。这里所使用的推断分析指的是使用对若干输入变量的推断处理，产生输出变量，即用户的当前上下文环境。在一个方面中，分析可包括利用统计模型和/或贝叶斯模型。

参考图28，例示出根据本发明的一方面的系统2800，其中推断引擎2802进行推断分析来确定用户的上下文环境2804。在一个方面中，引擎2802是计算机的处理器可从诸如存储器之类的计算机可读介质执行的计算机程序。用户上下文环境3804可被认为是引擎2802的输出变量。

引擎2802可对一个或多个输入变量进行处理，以作出上下文环境判决。这种输入变量可包括一个或多个传感器2808(如在说明书的先前部分连同用于上下文环境确定的直接测量方法一起描述的传感器)，以及由时钟2810和日历2812表示当前日期和时间，可在例如用户的计划安排或个人信息管理器(PIM)计算机程序和/或用户的PDA设备上访问到。除了图28所例示出的之外，还可考虑其它输入变量。图28的变量不是对本发明的任何限制。

现在参考图29和30，例示出根据本发明的诸如由可由上述的推断引擎执行的统计和/或贝叶斯模型提供的示例性推断模型。一般来说，计算机系统可能在某种程度上不确定用户的状态的细节。从而，可以构造概率模型，能够以不确定性推断用户的关注或其它状态。贝叶斯模型能够推断用户的关注焦点的概率分布。这些关注状态可被公式化成一组原型情况或用户所致力于的认知询问(cognitive challenge)的一组截然不同的类的更为抽象的表示。可选地，可把模型公式化成能够作出关于注意焦点的连续不断的测量的推断，和/或对不同类型的通知直接推断中断的代价的概率分布。

可采用贝叶斯网络，根据关于用户的活动和位置的一组观察值来推断可选的活动上下文环境或状态的概率。作为一个例子，图29显示了贝叶斯网络2900用于推断某一单个时间段用户的关注焦点。变量的状态(即关注的焦点2920)指的是桌面和非桌面上下文环境。模型中所考虑的示例性的关注上下文环境包括例如情况了解、吸引住(catching up)、非特定背景任务、焦点内容生成或查阅、轻型内容生成或查阅、浏览文档、办公室内会谈、办公室外会谈、收听演讲、私有时间、家庭时间、个人焦点、临时的谈话和旅行。贝叶斯网络2900指示出用户的当前关注和位置受到用户的计划安排的约会2930、一天的时间2940以及期限的邻近2950的影响。用户的关注的概率分布也受到例如在用户的办公室内监控到的环境声音信号2960的状态的汇总的影响。环境声音信号2960随时间的分段提供了关于活动和谈话的存在的线索/输入。软件应用程序的状态和配置以及通过用于与计算机交互而生成的用户活动的正在进行的活动流也向源提供了关于用户的关注的证据。

如网络2900中描绘的那样，操作系统或其它环境中当前处于最高关注焦点2970的软件应用程序影响了用户的关注和任务的性质，以及用户的关注的状态和处于焦点的应用程序一起影响以计算机为中心的活动。这种活动包括从鼠标和键盘动作顺序以及更广时间范围上的更高级模式的应用程序使用中构建的用户活动的流。这些模式包括以电子邮件为中心、以Word处理器为中心，以及涉及包含多个应用程序交替的方式的活动的原型类。

图30例示出在不同的时间段的上下文环境变量之间用户的关注焦点的贝叶斯模型3000。模型3000例示出一组马尔可夫时间依赖性，其中在用户状态的当前确定中考虑上下文环境变量的过去状态。这种贝叶斯模型3000实时地考虑例如在线日程表提供的信息，以及时间感测系统(未示出)报告的关于室内声音和用户活动的观察值流，并连续不断地提供关于用户的关注的概率分布的推断结果。

图31和32例示出根据本发明用于提供诸如上下文环境分析器和通知引擎之类的通知架构的一部分的方法。虽然，出于解释简单的目的，方法被示为和描述为一系列动作，但是要理解到本发明不限于动作的顺序，根据本发明，某些动作可以不同顺序发生，和/或与不同于这里所示和所描述的其它动作同时发生。例如，本领域的技术人员将理解到可选地可以把方法标识为一系列相互关联的状态或时间，例如状态图。而且，并非所有的动作都是实施根据本发明的方法所必需的。

参考图31，流程图3100例示出根据本发明确定用户的上下文环境。处理包括在3102确定用户的位置，以及在3104确定用户的焦点。这些动作可通过先前所述的一个或多个方法来完成。例如，可采用配置文件；用户可规定他或她的上下文环境；可利用上下文环境的直接测量；可遵循一组规则；也可进行诸如贝叶斯或统计模型之类的推断分析。要理解到，可采用其它分析来确定用户的上下文环境。例如，可以利用集成的摄像机源，指出是否某人在计算机前以及他或她是否正在看着计算机。然而，注意，系统可以带有摄像机或不带有摄像机来操作。对于所有的源，系统可实际上利用任何可用的输入源来操作，不要求任何特定的源来推断上下文环境。此外，在其它方面中，可以有集成的加速度计、话筒、和接近传感器，位于小型的PDA上，给出对用户的位置和关注的感测。

参考图32，流程图3200例示出根据本发明的一方面的用于通知引擎的判决处理。在3202，一个或多个通知源生成通知，通知由通知引擎接收。在3204，上下文环境分析器生成/确定关于用户的上下文环境信息，在3206，通知引擎接收该信息。即，根据本发明的一方面，在3204，上下文环境分析器访问指示出用户的当前关注状态和位置的用户的上下文环境信息配置文件，和/或从一个或多个上下文环境信息源评估关于用户的当前关注状态和位置的实时信息，如说明书先前部分所述的那样。在3208，通知引擎部分地根据从上下文环境分析器接收的上下文环境信息来确定哪些通知要被传递给哪些通知信宿。通知引擎还根据关于上下文环境分析器存储的用户的通知参数的信息来作出判定。即，根据一个方面，在3208，引擎执行关于对于给定通知，用户是否应当被告警，以及应如何通知用户的判决理论分析。如下文中将详细描述的那样，可在3208处采用判决理论和/启发式分析，判定和策略。关于用户的通知参数可通过填入缺失的值或覆盖源或信宿的模式中提供的参数来使分析个人化。通知首选项还能提供按照判决理论分析来采用的策略(如启发式的)。根据该判定，在3210，通知引擎将通知传递给分配器。

数据驱动的应用程序安装

根据本发明的一个方面，信息代理应用程序的安装可以通过更新预先定义的表来完成。传统的通知系统以及其它应用程序在它们被安装时一般包含数据库对象的增生(proliferation)。每个应用程序传统上在安装处理期间必需存储过程以及大量的表和数据库。然而，本发明采用了不同的方式。首先，当安装诸如信息代理系统100之类的系统或平台时，创建表的基本集合。因此，应用程序安装仅仅涉及将数据插入到预先存在的表中。该方法消除了随着安装的应用程序的数量的增加而产生的数据库对象的增生，并提供了扩展性(下文讨论)。

为了实现上述内容，事件、首选项和过程都能够被存储为数据。这使得系统能够利用不断增加的数据库引擎和查询的处理能力，以执行诸如信息代理应用程序300(图3)之类的多个应用程序。如上已经描述的，首选项可由终端用户定义，并然后被抽象成表和数据库中的高级数据字段。可捕获或检索事件，随后存储于数据库中。诸如查询评估过程之类的传统存储的过程也可通过创建过程以及将文本卷成数据库表来被表示为数据。此后，当执行过程时，表示该过程的文本的串就能够从数据库表中被拉出，并在数据库表中被动态地评估。该方法显著地减少了需要由应用程序创建的存储的过程的数量，并使得应用程序安装仅仅是DML(数据操作语言)数据驱动操作。

组成性(composability)和扩展性

该部分描述了在初始创建时如何组成信息代理应用程序，以及随后如何进行扩展。信息代理应用程序(IA应用程序)设计成使得终端用户能够通过事件-条件-动作(ECA)模型与某些底层的系统或应用程序域交互。更为特别的，信息代理应用程序设计成使得用户能够规定控制如何应用其它应用程序能力的首选项，特别是对于处理信息路由转发、过滤和处理的问题域，其中对于用户上下文环境的敏感性是重要的。以此为基础，应理解信息代理应用程序的组成性及扩展性是以用户有效地创建首选项(新的ECA示例)的能力为目标的，而不是针对组成或扩展底层系统或应用程序域。

创建新的应用程序、组件或系统模型并非是信息代理应用程序组成性和扩展性的目的(虽然这是可能的，并且应被考虑成处于本发明的范围之内)。相反，其目的是使得能够动态扩展到允许用户通过ECA模型规定首选项逻辑的系统的层或组件(例如判决逻辑组件330)。具体来说，其目的是在给定的应用程序安装之后，允许新的条件和动作(ECA中的CA)对于终端用户可用。此外，应理解，事件(ECA中的E)也可以类似的方式被动态扩展。

根据本发明的一个方面，信息代理应用程序不具有它们自己的界面来定义首选项，但是利用操作系统界面或专用于应用程序的用户界面来创建首选项。在该上下文环境下，信息代理应用程序组成性和扩展性被设计成以现存的用户界面能够允许用户利用新的条件和动作创建新的首选项的方式来添加新的条件和动作。就这一点而言，IA应用程序能够支持这些新的条件和动作上的反射，使得可以与提供了扩展的描述一起适当地显示这种新的功能的特征标，以向终端用户提供关于如何以及何时适当地使用新的条件和动作的上下文环境。

对于信息代理应用程序来说，各种上下文环境以及各种时间内存在多重性。特别是，虽然IA应用程序可以是自给自足的和独立的，但是许多IA应用程序实际上会与其它IA应用程序提供的能力交互并进行平衡。具体来说，一个应用程序定义的条件和动作函数也可以由另一应用程序来使用。IA代理还能够以若干中其它方式而彼此交互。例如，一个IA应用程序中的首选项评估可能触发创建提交给另一个IA应用程序的事件的动作。

组成性和扩展性之间的区别对于理解信息代理应用程序的集合如何交互和发展来说是重要的。组成性是这样一种概念，它用于建立在新的信息代理应用程序创建时，新的信息代理应用程序是建立在存在的且由其它信息代理应用程序在初始安装该信息代理应用程序时提供的能力的基础上的。扩展性指的是这样一种概念或处理，已经存在的信息代理应用程序利用在应用程序创建或安装之后产生的新的能力来扩展。此外，由于使用公共的一组机制来支持组成性和扩展性，因此，理解这些公共机制如何用于实现组成性和扩展性的稍微不同的目的的小差异，这是非常重要的。IA应用程序组成性的概念还可适用于从一组单独的片段构造单个IA应用程序的处理。组成性的这一方面致力于以模块化方式开发IA应用程序的软件工程目的。引入IA应用程序系统中的扩展性的概念与传统的扩展性的概念是相一致的。也就是说，在IA应用程序的原始定义之后添加新的能力，增强的应用程序的能力。

在很大程度上，IA应用程序的度量是由呈现给用户的能力来确定的。因此，IA应用程序能够扩展的程度可由在现存的应用程序的上下文环境内哪些新的条件和动作可用于用户定义新的首选项的程度来确定。IA应用程序扩展性首要针对于在应用程序被安装之后使得新的条件和动作能被添加到应用程序，而不用原始应用程序的作者的进一步发明创造。为了理解这是如何进行的，重要的是强调动作或条件函数的定义最终变得可由信息代理应用程序的终端用户访问的进化链。

转到图33，描述了根据本发明的一方面的条件/动作进化链3300。在3310，条件和动作以条件和动作函数为起始。该函数指定可用于在涉及例如SQL可调用的函数/存储的过程的定义的正式特征标(signature)时。在新的条件或动作函数被定义的时间与通过对应的条件或动作的声明将函数绑定于现存的应用程序的时间之间，函数被认为是候选函数。候选函数的开发者规定了将允许作为目标的要被扩展的应用程序从被称为是3320处的候选条件或动作的函数创建条件或动作的绑定。在该阶段，条件或动作是由现存的要被扩展的应用程序使用的候选者，使得应用程序能够使用条件或动作，但并不要求接受它们。要被扩展的应用程序中的接受逻辑确定是否将接受这种绑定，例如根据谁签署了所提出的扩展/绑定。一旦应用程序将其首选项类绑定到条件或逻辑函数，在3330，候选条件或动作就简单地变成条件或动作。最终，当终端用户使用新定义的首选项的上下文环境内的条件或动作时，如3340处的链所描述的那样，该动作或条件被称为是被例示。

图34例示出根据本发明的一方面的用于应用程序交互的系统3400。系统3400包括实例注册组件3410、定义注册3412、绑定注册3414、应用程序A3420、应用程序B3430、绑定3425以及扩展组件3440。在一个扩展性实现中，部署的单位是应用程序或扩展。通过添加应用程序或应用程序数据文件(ADF)来扩展实例。ADF可由开发者创建，在部署新的单个应用程序时使用。ADF一般定义了应用程序的中央逻辑，并能够包括尤其用于诸如通知之类的事件、条件和动作的模式。可通过添加扩展或扩展数据文件(EDF)来扩展应用程序。EDF可由任何人创建，用于创建了实例和应用程序之后的任何时间(包括应用程序的初始安装)。

为了应用程序共享功能，它们需要彼此了解。根据本发明的一方面，可通过使用实例注册3410来实现，实例注册3410由定义注册3412和绑定注册3414组成，存储关于函数以及函数如何绑定到应用程序的信息。实例注册3410为应用程序提供了一共享的位置来存储数据。实例注册3410包括定义注册3412和绑定注册3414。

定义注册3412存储关于应用程序函数的信息。根据本发明的一方面，应用程序(例如IA应用程序)使用的应用程序函数可注册或存储于定义注册3412中。将函数注册于定义注册3412中会引起函数被公开给运行于系统上的所有应用程序。因此，应用程序使用的函数或者是完全私有的(即没有注册在定义注册中)，或完全是公开的(即注册在定义注册中并可由所有其它应用程序访问)。应注意，这仅仅是实现定义注册的一个方式。其它实现机制可以是存储一标志，表示函数是公共的还是私有的。可结合于定义注册中的某些示例性的信息包括下列：

列	说明
		SourceApplication//源应用程序	实现函数的应用程序的GUID
FunctionID//函数ID	被注册的函数的GUID
		FynctionType//函数类型	可以是ConditionFunction(条件函数)、ActionFunction(动作函数)或AccessorFunction(存取器函数)
FunctionVersion//函数版本	函数版本由以句点隔开的四个整数字段组成<Major>.<Minor>.<Build>.<Revision>
		FunctionDescription//函数说明	函数执行的服务的文本说明，可用作消耗应用程序的帮助文本。该说明不应该提及函数名，因为它将按照Condition(条件)、Action(动作)或Accessor(存取器)而适当地暴露给用户。
ParameterName//参数名	参数的正式名称
		ParameterDataType//参数数据类型	参数数据类型
ParameterDescription//参数说明	参数以及它在函数中的角色的文本说明。该说明不应提及函数明，因为它将按照Condition(条件)、Action(动作)或Accessor(存取器)而适当地暴露给用户。
		Optional//可选的	参数是否是可选的

绑定注册3414可以存储来自多个应用程序的所有的对函数的绑定、条件、动作和存取器。不管这些函数是得自于初始定义或对应用程序的稍候扩展，这都是事实。此外，应注意，根据本发明的一方面，公共函数在没有绑定元数据时是不可用的。绑定元数据是固定公共函数如何绑定到应用程序数据事件数据的信息。在绑定注册3414中注册公共函数将函数绑定到应用程序。这是一对多的关系，其中一个函数可被绑定到许多不同的应用程序。

绑定注册3414中注册的绑定可具有若干状态。例如，绑定可以是候选绑定。候选绑定由函数的定义者定义，并可用于其它应用程序。绑定还可使绑定函数的状态指示出绑定是专用于给定的应用程序的，表示该给定的应用程序如何绑定到给定的条件或动作函数。进一步，绑定可具有“不接受”的状态。这些是针对特定应用程序但不被目标应用程序的接受逻辑接受的候选函数。接受逻辑可在ADF中声明，并可包括用于确保EDF资源是可信的(例如使用数字签名)、授权的(例如来自一列受信任的源)、和经鉴定的(EDF已被受信任的源签署)的组件。可位于绑定注册3414中的其它信息包括但不限于：

列	说明
		ExtensionID//扩展ID	用于该特定绑定的GUID
FunctionID//函数ID	表示被绑定的函数的GUID
		TargetApplication//目标应用程序	表示被扩展的应用程序的GUID。该字段对于不以特定应用程序为目标的公共候选函数来说是Null。
TargetApplicationVersion//目标应用程序版本	由通过句点分割的四个整数组成的函数版本<Major>.<Minor>.<Build>.<Revision>
		SourceApplication//源应用程序	表示提供候选函数绑定的应用程序的GUID
SourceApplicationVersion//源应用程序版本	由通过句点分割的四个整数组成的函数版本<Major>.<Minor>.<Build>.<Revision>
		Binding Status//绑定状态	指示出：{候选、绑定、或不接受}绑定
BindingType//绑定类型	可以是Condition(条件)、Action(动作)或Accessor(存取器)
		BindingName//绑定名	表示绑定的串。在内在化(internalization)到消耗应用程序中期间，该名将用作条件、动作或存取器名。
ParameterName//参数名	被绑定的函数的参数名

ParameterValue//参数值	返回对应于定义注册中定义的ParameterDataType(参数数据类型)的数据类型的Constant(常量)，FieldReference(字段引用)或其它函数
		ConflictResolution//冲突解决	聚集多个动作优先级的开发者指定的整数(Int)值

扩展组件3420根据候选函数创建条件和动作。扩展组件3420可由安装脚本在安装时调用来将候选函数绑定到应用程序。如果在绑定注册3414中作出新的候选函数输入项，则根据在目标应用程序方面采取的动作或缺省，可能发生若干情况。例如，如果目标应用程序没有被安装，则该输入项可被忽略。如果目标应用程序被安装，但配置成不接受扩展，则忽略该输入项。然而，如果目标应用程序被安装且接受该候选函数，则利用扩展组件3420对该应用程序创建新的条件、动作或存取器，并绑定到应用程序。因此，在系统3400中，应用程序A3430包含本地函数“ConditionFuncX”，它希望可用于应用程序B3440。可通过添加扩展数据文件(EDF)使该函数可用于应用程序B3440。此后，该函数以可用于应用程序B3440的方式存储于实例注册3410中。例如，ConditionFuncX可注册在定义注册3412中，候选函数可存储在绑定注册3414中。扩展组件3420可随后从绑定组件3414读取候选函数，通过将其绑定到应用程序B3440来创建条件A。因此，创建了绑定3450，将条件A绑定到应用程序A的ConditionFuncX。

一旦建立了绑定或相关性，则应注意可以许多方式来进行破坏。例如，如果应用程序被卸载，则应用程序实现的函数就不可用(即破坏的相关性)。可破坏相关性的方式的另一个例子是如果以被绑定到不再可用的新的条件、动作或存取器安装新的应用程序。如果应用程序被配置成不再接受所有的或某些扩展，则也可破坏相关性。从而，现存的首选项可能对不再可用的条件、动作或存取器有相关性。可以许多方式来补偿破坏的相关性。根据本发明的一方面，可以定义不可用状态。例如，在允许应用程序破坏相关性之前，所有其它的应用程序可被通知，使得它们可将相关的首选项至于“NotAvailable”(不可用)状态。此后，无论何时安装了一应用程序，系统或应用程序可检查是否已经重新建立的相关性，从而可把不可用状态改变成可用，并可利用首选项。

可在信息代理应用程序之间创建首选项。首选项实例表示IA应用程序之间实现交互的方法。根据本发明的一方面，可提供至少两种机制来使得用户能够创建访问不止一个IA应用程序中的能力的首选项。一种机制是EDF绑定。应用程序开发者能够创建EDF绑定，来允许一个应用程序中的首选项类引用其它应用程序中定义的条件和动作。这使得终端用户能够用具体例子说明引用来自多个应用程序的条件和动作的首选项。事件提交动作也可利用多个应用程序提供的能力。当应用程序定义事件类时，可隐含地创建事件提交动作函数。此后，这些事件提交动作函数可通过其它应用程序使用的EDF绑定到动作，从而丰富了新创建的用户首选项的潜在能力。

与终端用户相对，为了使得应用程序能够直接实例化按照应用程序开发者规定的首选项，可能需要额外的机制或组件。一种机制或组件可对应于首选项模板。首选项模板可定义在首选项类的上下文环境内，并包括这一组条件和类。首选项类的语法可以用为了定义模板的新的标签来扩展。接着，该标签可由EDF使用用于以新的模板扩展应用程序。还可采用首选项实例化动作。当创建新的首选项模板时，可以隐含地创建动作函数来从规定的模板中实例化首选项。对该动作函数的参数表示从模板的固定的条件动作集合实例化首选项所需的常量。

开发者还能够在应用程序内或跨应用程序来实例化首选项，而不需要终端用户的明确干涉。可采用若干机制来实现这个功能。例如，可把新的ADF标签添加到首选项类，以允许直接在应用程序定义时间在ADF中实例化首选项。可选地，可把新的EDF标签添加到首选项类。这将允许在应用程序被定义期间以及之后都能实例化首选项。此外，首选项实例化也能通过模式定义外的脚本(例如SQL脚本)来实现，例如通过使用系统API。

利用上述的能力，应用程序(例如IA应用程序)交互能够按照一个应用程序发送事件、评估条件/动作、或在其它应用程序中实例化首选项来发生。这些交互可直接通过开发者或通过终端用户定义的首选项来完成。

为了进一步理解应用程序组成性和扩展性的各种方面，下文中提供了若干例子。ShellApp是操作系统信息代理应用程序。Office也是一种信息代理应用程序。

例子#1组成(Composition)

当创作新的应用程序以绑定到现存的已知函数时，可定义组成。在该例子中，首先安装ShellApp，随后安装Office。当创作Office时，开发者知道并涉及Office应用程序来平衡(leverage)ShellApp的FuncX条件函数。当Office被安装时，它在绑定注册中注册一绑定，将FuncX条件函数(旧函数)绑定到Office应用程序(新的应用程序)中的条件。Office应用程序安装脚本然后调用扩展组件，读取绑定注册。扩展组件然后可检测存在已经定义的(“内建的”)条件，并因此跳到下一步骤，在该步骤它重新评估实例范围的NotAvailable状态。Office应用程序被称为是要由ShellApp扩展。

例子#2扩展

当旧的应用程序用新的函数扩展时，可定义扩展。在该例子中，类似于上述，Shell应用程序先被安装，然后安装Office。当Office被创作时，开发者创建了可用于ShellApp中的动作函数FuncY。当Office被安装时，它在定义注册中注册动作函数，并在绑定注册中注册将该Office应用程序FuncY(新函数)绑定到ShellApp(旧应用程序)中的动作的绑定。Office应用程序脚本调用扩展组件来检测存在在ShellApp中不具有对应动作的新的绑定，并因此通过在ShellApp创建来将该动作内在化。随后它重新评估实例范围的NotAvailable状态。ShellApp被称为是已经用Office应用程序扩展。

例子#3补丁扩展

当函数和应用程序都已安装在系统上时，可进行补丁。因此，假设ShellApp和Office都已安装在系统上，则然后安装office技术维护补丁包(office servicepack)。在Office应用程序发行之后，开发者认识到Office中有ShellApp能够使用的动作函数。技术维护补丁包尤其包含定义了将新的Office应用程序条件绑定到Office应用程序中的条件函数的绑定的EDF。当技术维护补丁包被安装时，它可以在绑定注册中注册该绑定，并调用扩展组件。扩展组件能够检测存在在目标应用程序中没有对应的动作或条件的新的绑定，并随后在ShellApp和Office应用程序中创建它们。然后，扩展组件能够重新评估实例范围的Notavailable状态。ShellApp于是可被称为已由Office应用程序扩展，而Office可被称为是已由ShellApp扩展。

例子#4卸载

假设已经卸载了先前安装的Office应用程序，在该过程期间，它从定义和绑定注册中删除所有的注册。ShellApp现在可具有依赖于现在被移除的Office实现的功能的动作。因此，可以对具有破坏的相关性的所有动作声明不可用或NotAvailable状态。终端用户于是能够接收到关于缺少相关性的提示。终端用户于是能够选择保持不可用的首选项或动作(例如Office将要回来)，或简单地删除它们。

例子#5重新安装

假设现在重新安装先前被卸载的Office的应用程序，在安装期间，它重新注册其动作函数以及对ShellApp的绑定。Office安装脚本于是能够调用扩展组件来在ShellApp中创建动作。然而，如果条件、动作或存取器已经存在于目标应用程序中(例如应用程序先前被安装)，扩展组件简单的删除，并跳过创建步骤。然后可重新评估函数的不可用(NotAvailable)状态，以确保能够为有效的所有函数都处于使能的状态。

个人化文件夹

上述系统促进了使对于给定的事件组的判决和动作的处理自动化的信息应用程序的构造。因此，可以构建应用程序，使得终端用户能够使对包括但不限于桌面通知和电子邮件到达的事件的响应个人化。这样一种应用程序是个人化文件夹应用程序，下文描述。本发明通过尤其利用模式化数据存储器和模式化逻辑使得诸如个人化事件处理之类的功能变得可能。

转到图35，描述了根据本发明的一方面的个人化系统3500。系统3500包括数据存储器3550和信息代理应用程序300，信息代理应用程序300包含个人化文件夹3510和首选项3512。个人化文件夹3510指的是能够根据可由终端用户直观规定的条件表达式来包含或排出项目的文件夹或数据容器。在一个实例中，可以分级的方式来安排文件夹3510，并由操作系统的组件来实现。然而，应注意，对术语文件夹和数据容器的使用并非是局限性的。文件夹3510可扩展到由一组关系定义的任何链接、指针或数据的任何集合。信息代理首选项3512表示非技术终端用户组合模式逻辑或和模式化数据(例如通过数据存储器150)来提供丰富的个人化应用程序和环境的能力。相反，传统的首选项仅仅使用具有提供了串常量的直观名字的简单条件。首选项3512能够由终端用户规定，例如使用类似于诸如以下之类的逻辑：On event IF conditions THENactions(On事件IF条件THEN动作)，或以更为应用程序专用的形式：On folderevent IF conditions THEN include/exclude actions(On文件夹事件IF条件THEN包括/排出动作)。此外，应注意，首选项3512可通过推断分析来开发，例如通过采用统计和/或贝叶斯模型来根据用户动作学习用户首选项。这里使用的推断分析指的是对若干输入变量使用推断处理，产生输出变量，即对首选项开发工具的用户首选项或输入。在一个方面中，分析可包括对统计模型和/或贝叶斯模型的使用，但不限于此。处理条件和动作之外，首选项包含触发机制，发起对首选项的评估。根据本发明的一个方面，这种触发机制可包括明确的用户指示、按时间计划安排、和/或在文件夹中添加文档、删除文档和/或修改文档时自动进行。进一步，应理解，首选项3512可以分组以实现太复杂以致于不能通过单个表达式来简单创建的结果集(例如从文件夹包括/排出特定项目，组合多个查询的效果)。进一步，应注意，单个和成组的首选项3512都可被清楚地表现为用户能够在文件夹3510之间拖放、剪切和粘贴首选项的实际实体。文件夹3510可包含数据复本，或仅仅是指向存储于存储器设备(a/k/a虚拟文件夹)中的数据的指针。存储的数据可包括但不限于word处理文档、电子数据表、图片和音乐。进一步，个人化文件夹3510能够具有与多个不同的域中的项目相关的相关首选项3512。为了支持这种功能，可以引入预定的常量。更为具体的，来自一个项目域(如MyGrandparent)的预定常量可以用作为对来自其它域(如Photosfrom(MyParent))的条件的自变量。预定条件和常量的组合为终端用户提供了一种简单的和直观的方式，以使得各种项目域相关联。当然，用户定义的常量也能被提供给个人化文件夹的条件。对于一项目域，可从模式中推断出简单的条件。例如，可从电子邮件模式中推断出EmailIsFrom()或SubjectContains()。然而，模式开发者能够无疑地明确地规定更为丰富的或更为小的有用条件的集合。此外，应注意，新的条件可被加到应用程序300(扩展性)，并随后由终端用户使用来定义新的首选项。当新的模式被安装时，用于个人化文件夹的新的能力变得可能。

根据本发明的一方面，文件夹3510可被分类成活动的或派生的。当某些令人感兴趣的事情在文件夹中发生时，活动文件夹代表用户进行动作(例如事件-文档添加、删除或修改)。例如，可从数字照相机将照片下载到称为MyPictures的文件夹。与此同时或此后的短时间内，活动文件夹能够请教日程表应用程序，以确定当拍摄照片时用户在做什么，并随后以适当的标题(例如钓鱼活动)来创建新的文件夹，并将照片移动到该新的文件夹中。在电子邮件的上下文环境中，电子邮件应用程序能够确定消息何时包含消费报告，如果它小于某一值，则能够将报告移动到被认可的消费报告文件夹。在又一个使用活动文件夹的例子中，可把音乐下载到活动文件夹，然后活动文件夹确定艺术流派(如爵士、经典、打击乐、流行乐……)，并将其移动到适当的文件夹。

派生文件夹使用首选项来确定是否要从文件夹中包含或排出某些文件。此外，应注意，派生文件夹可以是提供对文件的映射或指针的虚拟文件夹。虚拟文件夹充当用于收容数据的实际文件夹，而该文件夹不具有实际的物理存在性。使用派生文件夹的一个例子包括这样一种情况，其中用户定义文件夹包含用户在前两个星期至少收听了三次的所有爵士乐。还可由首选项来定义派生文件夹，以包括某一类型但具有某些例外的所有文件。例如，可以把文件夹定义成包括爵士音乐家Mile Davis的所有音轨，但排出了某些歌曲音轨(例如HumanNature和New Rumba)。此外，应注意，可以把首选项定义成使得用户能够将文件拖放到文件夹，文件夹将确保被拖放的文件是规定的类型。如果文件是允许的类型，则它能够被添加到文件夹，如果不是，则该文件被拒绝(如不被复制到文件夹)，或可选地，可以提示用户是否要对该特定文件创建例外。

此外，应注意，某些文件夹能够表现出活动文件夹和派生文件夹的双重特性。因此，某些文件夹能够具有与它们相关联的首选项，规定哪些项目包含于文件夹中，以及具有规定当某些事件发生于那些项目时采用什么动作的首选项。

可使用系统100的执行引擎来处理应用程序。如先前所揭示的那样，可按照数据来存储首选项，并以数据查询的方式来执行。数据存储器150能够将数据存储于一个或多个表中，然后可使用首选项信息来查询这些表。传统上，对表的数据库执行查询在计算上是不可行的，因为查询必需以相对较短的间隔连续执行，以确保文件夹中的数据是当前的。对于类似于个人计算机之类的轻型系统来说，这尤其不切实际，在这些计算机中，处理器不能有效地执行多个程序同时恒定地运行查询以更新文件夹数据。然而，本发明通过对诸如数据何时被添加、删除或修改之类的事件的出现执行查询而克服了该问题。因此，处理器没有连续执行查询的负担，文件夹数据保持为当前。

基于活动文件夹的工作流式的活动

个人化(例如ECA规则)与工作流或任务计划安排是不同的。工作流或任务计划安排是多步骤工作片段，可通过文件夹中的项目来表示。个人化是使得终端用户能够规定在系统/应用程序的中断点运用的用于使终端用户有意义的事件(如电子邮件到达)或系统/应用程序行为(如根据用户上下文环境控制桌面中断)自动化的首选项的概念。个人化涉及使得终端用户能够表达首选项，其逻辑被定位到给定的中断点(如事件、流程中的点……)。由于单个首选项的动作而造成的多个首选项的级联评估是偶然的，而非计划的。因此，个人化并非是小型的工作流，相反工作流和个人化总是不同的。用于处理事件的首选项的偶然级联不同于工作流中计划的任务/规则链。此外，个人化可被运用于电子邮件、电话呼叫、桌面中断、以及许多其它类型的终端用户事件，不依赖于是否涉及工作流或任务计划安排。个人化工作流的前提是，个人化是独立的，而与工作流是互补的概念。

无论何时用户判决是相关的，个人化可被运用于工作流或任务计划安排。在任务的个人化、工作流起动的个人化、工作流任务的个人化、以及工作流安排的个人化中，对于工作流的个人化来说存在各种机会。使任务个人化的一个例子可以是，用户规定判决逻辑使诸如通过人的直接报告自动认可某一货币量的订单的任务的处理自动化。工作流起动涉及根据感兴趣的事件(如电话呼叫、电子邮件到达)确定是否打开/发起工作流。可以通过用与要被遵循的计划等交互的适当能力来包装计划的个人化，从而可能将计划的个人化转变成工作流任务。换言之，个人化可被用作工作流中的计划任务，其中用户首选项将完全确定任务的解决。最后，个人化可被包含于工作流计划安排中。当关于工作流中的接下去的步骤存在选择时，个人化可用于允许用户为这些判决规定首选项。

包含上述类别中的许多类别的个人化工作流的一个实际例子是处理费用报告。在该例子中，电子邮件到达收件箱，检测电子邮件的类型(例如主题行，标记为费用报告……)，扫描电子邮件数据，如果发票金额小于某一货币量，则将报告移动到认可的文件夹。此后，可将一电子邮件发送回发送者，指示出报告被认可的状态。接着，可创建期刊用户由用户每月查阅，可计算认可的总量。

虽然工作流的个人化的所有上述类别增强了工作流的价值，但是这些好处的适用性并非工作流专用的。这些好处还可适用于许多其它域，包括但不限于：通信处理、路由转发、或个人化，其中这些域可能不参与到工作流中。

大事记文件夹

根据本发明的一方面，大事记表示域系统的用户相关的历史和上下文环境信息。通知系统通常包括历史数据的概念，能够用作对是否要根据前一动作采取动作的评估的一部分。例如，用户可能希望设置一首选项，称“当MSFT的股票攀升到当日的新的高点时，通知我”。在该情况下，系统必须能够保持当前MSFT股票的最高价格点，并在到达新的高点时更新该信息。

根据本发明的一方面，大事记存储于数据存储器中，用户可通过用户界面(例如由操作系统提供)来自由访问。从而，终端用户可对其历史数据进行控制；她能够以备份其它文件的方式对其进行备份，她能够将其与她家里或办公室里的其它计算机同步，她能够通过常规的文件共享机制来将其共享，以及能够设置访问许可和其它安全设置来控制谁能够访问该上下文环境信息。例如，用户能够允许其工作组中的每个人看到关于MSFT股票价格的历史信息，但可能希望限制诸如他们是否在办公桌前或是否在开会之类的上下文环境信息。

此外，本发明的系统能够使得这些大事记由不知道信息代理应用程序的应用程序更新成为可能。许多通知平台能够使得上下文环境信息在用户规则(这里也被成为是首选项)的正常处理期间被更新成为可能，但是因为本发明利用存储于数据存储器中的且作为规则或首选项处理的一部分的模式化数据，系统能够使用任何应用程序创建的上下文环境信息。例如，用户能够下载和运行由NASDAQ编写的应用程序，该应用程序向用户计算机流传输实时的股票报价。

NASDAQ应用程序可以为用户所感兴趣的每个符号创建文件，并在这些文件内存储相关信息。因为，根据一个方面，本发明的信息代理应用程序被构建成利用该种类型的形象化的上下文环境信息，信息代理系统能够在用户规则或首选项处理期间按照大事记来利用这些文件。

大事记也可连同活动文件夹一起使用。因为个人化文件夹系统包括监视特定文件夹的能力，因此创建、修改或移动到这些文件夹的文件夹项目能够作为对某一大事记或一组大事记的上下文环境更新来对待。如此，用户就可能不用任何编程者编写的代码为其利益而运行来维护大事记。相反，终端用户能够简单地使用操作系统的现存的文件操作机制来保持他们的上下文环境信息为最新。

从而，本发明可被实现为使用标准编程和/或工程技术来制造软件、固件、硬件或其组合的方法、装置或产品。这里所使用的术语“产品”(可选地可以是“计算机程序产品”)意图包含可从任何计算机可读设备、载体或介质访问的计算机程序。当然，本领域的技术人员将认识到可不用背离本发明的范围就能够对该配置作出许多修改。

鉴于上述的示例性系统，参考流程图36至41，将更佳地理解可根据本发明实现的方法。虽然出于简单的目的，所示的方法为一系列框，但是要理解，本发明不限于框的顺序，根据本发明，某些框可以不同的顺序和/或与不同于这里所述的其它框同时进行。而且，并非所有的框对于实现本发明的方法来说都是必需的。

转到图36，例示出根据本发明的采用首选项的方法3600。在3610处，终端用户根据开发者模式(如XML模式)规定首选项，并存储于例如数据库存储器中的表中。然后，在3620，可接收或检测一个或多个事件。在3630，使用查询语言(如SQL)查询数据表来执行或评估首选项。在3640，可产生或用条件有效的首选项填充结果表。最后，在3650，根据结果表的结果执行各个的动作。

转到图37，例示出根据本发明的安装应用程序的方法3700。在3710处，在与将执行安装的应用程序的系统或平台相关联的数据存储器(例如信息代理系统数据存储器150)中设置基表。随后，在3720用应用程序数据更新基表，而不是严格地为安装的应用程序创建新的表和数据库。在3730，按照数据来存储应用程序过程，例如存储于为应用程序过程指定的基表中。为了执行，根据一个方面，应用程序过程文本串从数据库中移除并实时执行。

图38描述了根据本发明的用于扩展应用程序的方法3800。在3810，从开发者接收EDF。EDF包含关于使得一个应用程序中的首选项类引用其它应用程序中定义的条件、动作和事件的信息。此后，在3820，在诸如实例注册之类的中央位置注册函数绑定。在3830，通过扩展组件检索或接收绑定信息。随后，在3840将接受逻辑运用于绑定。然而，当EDF被安装且绑定可用时，根据本发明的一方面，它们不是自动地被运用于一应用程序。相反，运用接受逻辑来判断是否要接受EDF。接受逻辑尤其询问受信任的源的绑定可靠性、绑定授权和/或绑定认证，以便确定它是否将被接受。在3850，应用程序作出关于它是否将接受该绑定的判决。如果“否”，则处理简单地终止，而没有绑定。如果“是”，则在3860，将候选函数从第一应用程序绑定到第二应用程序。

图39是根据本发明的用于卸载应用程序的方法3900的流程图。在3910，正被卸载的应用程序从中央存储位置删除其所有的注册。中央存储位置可以是具有定义和绑定注册的实例注册。然后，在3920，可移除应用程序组件。随后相关的应用程序可被通知该卸载的应用程序(例如通过扩展组件)。此外，如上所述，方法3900的框可以采用任何顺序。因此，本发明的另一方面包括在任何卸载或移除处理之前通知相关的应用程序。

图40是根据本发明的一方面的跨应用程序扩展程序常量的方法的流程图。在4010，接收常量。在4020，通过跨应用程序域搜索来确定常量值。例如，如果常量是MyManager，则该方法可通过电子邮件应用程序搜索，并确定MyManager的值。

图41是根据本发明的一方面的用于个人化计算机功能的方法4100。在4110，终端用户根据提供的模式编写首选项。首选项可以是任何形式，但根据本发明的一个方面，它包括由布尔逻辑算子分隔的多个IF-THEN声明。模式可由应用程序开发者来提供，以限制并从而简化终端用户编程。在4120，对事件的出现执行首选项。事件可以是发生的任何事，包括但不限于文件夹数据的改变或股票价格的改变。可通过查询数据存储器组件中的数据来执行首选项的执行或评估。在4130，根据条件有效的首选项采取动作。

为了提供用于本发明的各方面的上下文环境，图42和43以及下面的描述提供了可实施本发明的各个方面的适当的计算环境的简要的、一般的描述。虽然已经在运行于计算机和/或多个计算机上的计算机程序的计算机可执行指令的一般上下文环境中描述了本发明，但是本领域的技术人员将认识到本发明还可与其它程序模块组合来实现。一般来说，程序模块包括例行程序、程序、组件、数据结构等，它们执行特定的任务和/或实现特定的抽象数据类型。而且，本领域的技术人员将理解可用其它计算机系统配置来实施本发明的方法，包括：单处理器或多处理器计算机系统、小型计算设备、大型计算机、以及个人计算机、手持计算设备、基于微处理器的或可编程的消费电子产品等等。还可在分布式计算环境中实施所例示的本发明的各个方面，分布式计算环境中，任务是由通过通信网络链接的远程处理设备执行的。然而，本发明的某些(如果不是全部)方面可在单独的计算机上实施。在分布式计算环境中，程序模块可位于本地和远程存储器存储设备中。

参考图42，用于实现本发明的示例性环境4210包括计算机4212。计算机4212包括：处理单元4214、系统存储器4216以及系统总线4218。系统总线4218将包括但不限于系统存储器4216的各种系统组件连接到处理单元4214。处理单元4214可以是各种可用的处理器中的任何一种。双微处理器和其它多处理器架构也可用作处理单元4214。

系统总线4218可以是若干类型总线结构中的任一种，包括使用各种总线结构体系中的任一种的存储器总线或存储器控制器、外围总线和/或局部总线。例如但不限于，这种总线结构体系包括工业标准结构(ISA)总线、微通道结构(MCA)总线、扩展ISA(EISA)总线、智能驱动器电子设备(IDE)、VESA局部总线、外设部件互连(PCI)总线、通用串行总线(USB)、高级图形端口(AGP)、个人计算机存储卡国际协会(PCMCIA)总线以及小型计算机系统接口(SCSI)。

系统存储器4216包括易失性存储器4220和非易失性存储器4222。包含如在启动期间帮助计算机4212内的各元件间传输信息的基本例行程序的基本输入/输出系统(BIOS)存储在非易失性存储器4222中。作为例示，但非限制，非易失性存储器4222可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除ROM(EEPROM)、或闪存。易失性存储器4220包括随机存取存储器，它作为外部高速缓冲存储器。作为例示但非限制，RAM有各种形式，例如同步RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链(synchlink)DRAM(SLDRAM)以及直接Rambus RAM(DRRAM)。

计算机4212还包括可移动/不可移动、易失性/非易失性的计算机存储介质。例如，图42例示了盘存储器4224。盘存储器4224包括但不限于磁盘驱动器、软盘驱动器、磁带驱动器、Jaz驱动器、Zip驱动器、LS-100驱动器、闪存卡、或记忆棒之类的设备。此外，盘存储器4224可包括与包括但不限于光盘驱动器的其它存储介质分离或组合的存储介质，光盘驱动器例如紧致盘ROM(CD-ROM)、CD可录制驱动器(CD-R Drive)、CD可复写驱动器(CD-RW Drive)或数字通用盘ROM驱动器(DVD-ROM)。为了便于将盘存储设备4224连接到系统总线4218，通常使用诸如接口4226之类的可移动的或不可移动的接口。

要理解到，图42描述了充当用户和适用的操作环境4210中描述的基本计算机资源之间的中介的软件。这种软件包括操作系统4228。操作系统4228可存储于盘存储器4224上，用于控制和分配计算机系统4212的资源。系统应用程序4230通过存储于系统存储器4216或盘存储器4224上的程序模块4232和程序数据4234来利用操作系统4228对资源的管理。还要理解到可用各种操作系统或操作系统的组合来实施本发明。

用户通过输入设备4236将信息或命令输入到计算机4212。输入设备4236包括但不限于诸如鼠标之类的指点设备、轨迹球、触笔、触板、键盘、话筒、操纵杆、游戏盘、圆盘式卫星天线、扫描仪、TV调谐器卡、数字照相机、数字摄像机、web照相机等等。这些和其它输入设备通过接口端口4238，经系统总线4218连接到处理单元4214。接口端口4238包括例如串口、并口、游戏端口、通用串行总线(USB)。输出设备4240使用某些与输入设备4236相同类型的端口。从而，例如，USB端口可用于向计算机4212提供输入，以及从计算机4212将信息输出到输出设备4240。提供输出适配器4242来例示出存在某些输出设备4240，例如监视器、扬声器、打印机等，它们要求特殊的适配器。作为例示但非限制，输出适配器4242包括视频卡和声卡，它们提供了一种输出设备4240和系统总线4218之间的连接的手段。应注意到其它设备和/或设备的系统提供输入和输出能力，例如远程计算机4244。

计算机4212可工作于适用对诸如远程计算机4244之类的一个或多个远程计算机的逻辑连接的连网环境中。远程计算机4244可以是个人计算机、服务器、路由器、网络PC、工作站、基于微处理器的设备、对等设备或其它公共网络节点等，一般包括关于计算机4212描述的许多或全部元件。处于简要的目的，远程计算机4244仅例示出存储器存储设备4246。远程计算机4244通过网络接口4248与计算机4212逻辑连接，然后通过通信连接4250而在物理上进行连接。网络接口4248包括通信网络，例如局域网(LAN)和广域网(WAN)。LAN技术包括光纤分布式数据接口(FDDI)、铜芯分布式数据接口(CDDI)、以太网/IEEE 4202.3、令牌环/IEEE 4202.5等等。WAN技术包括但不限于点对点链接、类似于综合业务数字网络(ISDN)的电路交换网络及其变型、分组交换网络、数字订户线路(DSL)。

通信连接4250指的是用于将网络接口4248连接到总线4218的硬件/软件。虽然出于例示的目的示出通信连接位于计算机4212内，但是它也可在计算机4212的外部。出于示例性的目的，对于到网络接口4248的连接所必需的硬件/软件包括但不限于内部和外部技术，例如包括常规电话级调制解调器、电缆调制解调器、DSL调制解调器、ISDN适配器、以太网卡之类的调制解调器。

图43是本发明可与之相互的示例计算环境4300的示意框图。系统4300包括一个或多个客户端4310。客户端4310可以是硬件和/或软件(例如线程、进程、计算设备)。系统4300还包括一个或多个服务器4330。服务器4330可以是硬件和/或软件(例如线程、进程、计算设备)。例如，服务器4330能够收容线程来通过采用本发明执行转换。客户端4310和服务器4330之间的一个可能的通信可以采用适用于在两个或多个计算机进程之间传输的数据分组的形式。系统4300包括通信框架4350，通信框架可用于促进客户端4310和服务器4330之间的通信。客户端4310操作上连接到一个或多个客户端数据存储器4360，客户端数据存储器可用于存储客户端4310的本地信息。类似地，服务器4330操作上连接到一个或多个服务器数据存储器4340，服务器数据存储器可用于存储服务器4330的本地信息。

上述已经描述的内容包括本发明的例子。当然，不可能为了描述本发明的目的而描述组件或方法的每一可构想的组合，但本领域的技术人员可以认识到，本发明的很多其它组合和置换都是可能的。因此，本发明旨在包含落在所附权利要求书的精神和范围之内的所有这样的变换、修改和变化。此外，在详细描述或者权利要求之中使用了术语“包括”的意义上，这一术语以类似于术语“包含”的方式意味着包含性的，如术语“包含”在权利要求书中被用作过渡词时所解释的。

附录

    <EventClasses>

         <EventClass>

         <EventClassName>EMailEvents</EventClassName>

             <Schema>

                 <Field>

                      <FieldName>Sender</FieldName>

                      <FieldType>nvachar(255)</FieldType>

                      <FieldTypeMods>NOT NULL</FieldTypeMods>

                 </Field>

                 <Field>

                      <FieldName>Receiver</FieldName>

                      <FieldType>nvachar(255)</FieldType>

                      <FieldTypeMods>NOT NULL</FieldTypeMods>

                 </Field>

                 <Field>

                      <FieldName>Priority</FieldName>

                      <FieldType>int</FieldType>

                      <FieldTypeMods>NOT NULL</FieldTypeMods>

                 </Field>

                      <Field>

                      <FieldName>Subject</FieldName>

                      <FieldType>nvachar(255)</FieldType>

                      <FieldTypeMods>NOT NULL</FieldTypeMods>

                 </Field>

                 <Field>

                      <FieldName>MessageText</FieldName>

                      <FieldType>nvachar(255)</FieldType>

                      <FieldTypeMods>NOT NULL</FieldTypeMods>

                </Field>

             <Schema>

      </EventClass>

      <EventClass>

      <EventClassName>StockEvents</EventClassName>

           <Schema>

              <Field>

                  <FieldName>Symbol</FieldName>

                  <FieldType>nvachar(10)</FieldType>

                  <FieldTypeMods>NOT NULL</FieldTypeMods>

            </Field>

            <Field>

                <FieldName>Price</FieldName>

                <FieldType>float</FieldType>

                <FieldTypeMods>NOT NULL</FieldTypeMods>

           </Field>

           <Field>

                <FieldName>Time</FieldName>

                <FieldType>Datetime</FieldType>

                <FieldTypeMods>NOT NULL</FieldTypeMods>

            </Field>

        <Schema>

    </EventClass>

<EventClasses>

<PreferenceClasses>

    <PreferenceClass>

        <PreferenceClassName>EmailPreferencel</PreferenceClassName>

        <EventClassName>EmailEvents</EventClassName>

        <ConditionClasses>

           <ConditionClass>

              <Name>MailFrom</Name>    <！--Condtion Class id＝1-->

              Mail is From@Sender

           </CondtionClass>

           <ConditionClass>

              <Name>MailContains</Name>    <！--Condtion Class id＝2-->

              Mail Contains@KeyWord

          </CondtionClass>

     </CondtionClasses>

     <ActionClasses>

         <ActionClass>

             <Name>PopToast</Name>

             Pop A Toast

         </ActionClass>

     </ActionClasses>

</PreferenceClass>

<PreferenceClass>

    <PreferenceClassName>EmailPreference2</PreferenceClassName>

    <EventClassName>EmailEvents</EventClassName>

    <ConditionClasses>

        <ConditionClass>

        <Name>MailPriority</Name>    <！--Condtion Class id＝3-->

        Priority>@Priority

        </CondtionClass>

        <ConditionClass>

            <Name>MailFrom</Name>    <！--Condtion Class id＝4-->

            Mail is From@Sender

        </CondtionClass>

    </CondtionClasses>

    <ActionClasses>

        <ActionClass>

            <Name>MoveToFolder</Name>

            MoveToFolder(@TargetFolder)<

        </ActionClass>

    </ActionClasses>

</PreferenceClass>

<PreferenceClass>

    <PreferenceClassName>StockPreference</PreferenceClassName>

    <EventClassName>StockEvents</EventClassName>

    <ConditionClasses>

    <ConditionClass>

        <Name>StockSymbol</Name>    <！--Condtion Class id＝5-->

        Symbol＝@Ticker

    </CondtionClass>

    <ConditionClass>

        <Name>TargetPrice</Name>    <！--Condtion Class id＝6-->

        Price>@TargetPrice

    </CondtionClass>

</CondtionClasses>

<ActionClasses>

    <ActionClass>

    <Name>SendCellPhoneMsg</Name>

    Send a message to cell phone of@subscriberId

                   </ActionClass>

               </ActionClasses>

          </PreferenceClass>

</PreferenceClasses>

Claims (23)

1.一种首选项评估系统，其特征在于，包括：

用于存储模式化数据的数据存储器组件；

对包含终端用户规定的首选项的应用程序进行编译，并将它们存储于数据存储器中的编译器；以及

根据一个或多个事件的出现，评估存储于数据存储器中的首选项的执行引擎。

2.如权利要求1所述的系统，其特征在于，还包括用于采取条件有效的首选项规定的一个或多个动作的动作组件。

3.如权利要求2所述的系统，其特征在于，所述动作组件根据用于一个或多个用户通信设备的用户首选项对执行引擎生成的通知数据进行转换和格式化。

4.如权利要求1所述的系统，其特征在于，所述通信设备包括移动电话机、寻呼器、PDA和计算机。

5.如权利要求1所述的系统，其特征在于，还包括从事件源提取事件数据并将数据存储于数据存储器中的事件组件。

6.如权利要求5所述的系统，其特征在于，所述事件源是订阅服务。

7.如权利要求5所述的系统，其特征在于，所述事件源是数据存储器组件。

8.如权利要求1所述的系统，其特征在于，还包括产生表示给定时间的终端用户上下文环境的上下文环境数据，并将上下文环境数据存储于数据存储器中的上下文环境分析器。

9.如权利要求1所述的系统，其特征在于，还包括与应用程序交互的一个或多个API。

10.如权利要求1所述的系统，其特征在于，所述编译器能够编译重型应用程序和轻型首选项应用程序，所述执行引擎能够执行重型应用程序和轻型首选项应用程序。

11.如权利要求1所述的系统，其特征在于，所述执行引擎通过执行对数据存储器中存储的数据的查询来评估首选项。

12.如权利要求1所述的系统，其特征在于，用户终端首选项基于开发者规定的模式。

13.如权利要求12所述的系统，其特征在于，关于终端用户首选项和开发者模式的信息存储于数据存储器中的一个或多个表中。

14.一种应用程序安装方法，包括：

建立一组基表；以及

用与正被安装的应用程序相关联的应用程序数据更新基表。

15.如权利要求14所述的方法，其特征在于，所述应用程序采用用户定义的首选项。

16.如权利要求14所述的方法，其特征在于，所述应用程序数据包括按照数据存储的应用程序过程。

17.一种存储了用于执行权利要求14所述方法的指令的计算机可读介质。

18.一种用于采用首选项的方法，包括：

根据开发者模式规定用户首选项；

将首选项存储于数据存储器中的一个或多个表中；

在事件出现时，查询数据存储器中的表；

产生结果表；以及

根据结果表中的数据执行动作。

19.如权利要求18所述的方法，其特征在于，通过利用一次一个声明性编程模型来规定用户首选项。

20.如权利要求19所述的方法，其特征在于，使用一个或多个On-Event-If-Then声明和布尔逻辑算子来规定用户首选项，以规定条件和状态。

21.如权利要求20所述的方法，其特征在于，查询表包括执行查询语言声明。

22.如权利要求19所述的方法，其特征在于，开发者模式是XML模式。

23.一种存储了用于执行权利要求19所述方法的指令的计算机可读介质。

Images