用于扩展应用程序首选项类的系统和方法

摘要

本系统和方法揭示一种用于个性化计算机功能的系统。为最终用户提供容易地编写丰富和复杂的首选项的工具，例如，通过使用多个简单的如果－那么(IF－THEN)命题逻辑。首选项随后被变换成查询并且有效地在结构化数据上执行。满足的首选项随后执行动作，诸如提供通知或者在一个特定的文件夹中存储数据。而且，按照本发明的一个方面，数据、逻辑、事件以及其它全部被系统化，从而能够在应用组件之间和跨应用共享数据。

说明书

相关申请的交叉引用

本申请要求2003年10月24日提交的、题为SYSTEM AND METHOD FOREXTENDING APPLICATION PREFERENCE CLASSES(用于扩展应用程序首选项类的系统和方法)的美国专利申请序列号10/693,717的优先权，其全部内容通过引用而包括在此。

技术领域

本发明通常涉及计算机系统，特别涉及个性化计算机系统的系统和方法。

背景

计算机和计算相关技术的用户一般可分为两种不同类，即高技术和知识水平的人和其它的人。高技术和知识水平的人了解如何用丰富的方法使用计算机并让它们遵从他们的意愿来形成程序及促进丰富而有代价的性能。计算机用户世界的其余人则任高技术和知识水平的人处置，因为他们被拒绝方便或轻易地访问知识、信息或者让计算机服务于他们所需的能力。在技术上打破这些访问障碍中的一些时，就在计算中发生了主要突破。在大型机世界中，只有最大的企业才支付得起其昂贵费用。小型机和随后的个人计算机(PC)的出现打破了价格障碍并使计算机可用于小企业和个人。在1980年代，程序设计员努力创建了图形用户界面(GUI)应用程序。没有丰富而一致的GUI，程序设计员就不能为PC用户创建有代价的应用程序。Visual Basic革命以及控件的使用和基于事件的GUI构造使得应用程序开发者能够方便地创建丰富的应用程序。继而建立有效力的循环，其中多得多的终端用户能够使用这些应用程序。在1990年代，终端用户努力克服了对信息访问的缺乏。因特网的成长转变了这种空间距离，使得几乎任何人都可用浏览器访问所有有价值的信息。但是，仍然存在需要克服的大量障碍。

常规计算不是个人的。很少有所谓的个人计算机是真正“个人的”。确实，存储在本地盘上的数据是个人的。但是，机器的行为，即代表用户而执行的动作，对于数百万用户是相同的。尽管拥有非常强大的通用计算机，但一般用户将它视为静态工具，用作通信端点，用作搜索入口点，用于执行某些固定的销量大的应用程序，但却不能够实现任何“个人计算”这个词语的真正意义。在当前应用程序中可用的个人化能力刚刚触到可能的和所想要的表面。

而且，常规计算不是自动的而是人工的，要求用户在适当的时候作出决策和对其起作用。考虑大多数典型计算机最终用户的日常例程。尤其是，最终用户收集信息，对通信起反应，开始或响应通信，以及组织信息。计算机改进了人之间的通信并且改进了对信息的访问。然而，计算机在使最终用户解脱在正确的时间作出决策和对其起作用的责任方面做得很少。

另外，传统的计算不是上下文有关的。计算机软件一般提供选项设置，它们是相当静态的并且与用户的实际上下文不相关。

所需要的是一种真正个人化的计算机系统--一种知道最终用户的需求和首选项并且以那些需求以及用户上下文指示的方式表现的系统。而且，计算机系统和软件应当为每个最终用户提供一个个人助理，用于收集和筛选一个或多个最终用户的感兴趣信息并且按照用户指定的方式自动地对该信息作出反应。

发明概述

下面提供本发明的一个简化的概要，以便提供对本发明某些方面的基本理解。这个概要不是本发明的详尽概观。目的不是标识本发明的关键/紧要元素或描绘本发明的范围。其唯一目的是以简化的形式提供本发明的某些概念，作为稍后提供的更详细描述的序言。

在此揭示一种信息代理系统、应用程序和方法。信息代理系统提供执行信息代理应用程序(在此有时称为IA应用程序)的平台。IA应用程序随后可以由最终用户编程并且作为最终用户执行助理或代理使用。代理随后可以用于极大地增进最终用户个人生产率，集成桌面应用程序和所有个人通信介质(例如，移动电话、寻呼机、PDA...)。

信息应用程序系统的中心是数据的系统化。系统化是以众所周知并且良好定义的模式结构化数据，这使多个应用程序能够彼此识别和交互。信息属性、信息事件和决策逻辑都可以被系统化。系统化的信息属性指作为最终用户应用程序(例如，电子邮件、人、组、位置...)的基础的数据。信息属性可以被系统化成允许大量不同应用程序一致地解释数据。信息事件提供钩子以系于程序逻辑。这些事件是高层的并且系于信息流以方便没有经验的最终用户的理解。事件也可以被系统化。而且，决策逻辑可以被系统化。由于最终用户是没有训练过的开发者，因此没有理由期望一个用传统编程语言编写的程序。相反，可以为最终用户提供系统化的逻辑构件块(例如，IF-THEN命题)，使得他们可以通过用简单但丰富的组合将它们绑结在一起来编程。数据的系统化，信息钩子(事件)和最终用户编程能力让最终用户得到很大的价值，具有通过最终用户逻辑耦合和合作的应用程序的丰富生态系统，它随后允许新手最终用户变成系统综合者。

而且，按照本发明的一个方面，信息应用程序系统包括一个灵活的执行引擎，它可以编译和执行重量级和轻量级信息应用程序两者。重量级应用程序尤其包括常常在高端服务器上运行并且要求高吞吐量和可伸缩性的应用程序。轻量级应用程序是常常在较小的系统如个人计算机上执行并且要求低延迟时间、小数据库足迹和小工作集合的应用程序。在较小的应用程序中，在延迟时间与吞吐量之间的权衡与较大服务器应用程序相反。因此，本发明的执行引擎是灵活的，因为它可以在多个不同的应用程序平台上编译和执行应用程序，通过作出权衡以强调特定的系统要求(例如，低延迟时间、小数据库足迹...)。

按照绑定的另一方面，最终用户首选项或规则以一次一个但在集合中执行的方式开发。一次一个编程模型是对于开发者最自然的模型，它允许开发者针对一个首选项指定一个事件。然而，按照本发明的一个方面，系统检索一次一个程序声明并且构思条件类查询，以面向集合的方式执行从而利用如索引和重复消除这样的技术。这有利于以非常有效的方式评估首选项，同时使开发者和最终用户保持以一次一个方式概念化和编写程序。

按照本发明的另一方面，提供一种新的应用程序安装系统和方法。在常规系统中，应用程序安装包括数据库对象、表和存储过程的激增。在某些实例中，应用程序创建整个新数据库。本发明通过提供一组基表来简化和加快应用程序安装。为安装一个应用程序，系统仅更新基表。这可以通过将程序动作、条件、事件和过程存储为数据来完成。例如，对于过程，可以作为一卷文本来创建它们，存储在数据存储器中。为运行这类过程，可以简单地从数据存储器中拉出程序文本并执行它。

按照本发明的又一方面，系统可以支持存取器常数以允许条件/动作跨不同域的信息使信息联系起来。存取器常数促进信息交换或者跨不同域的数据共享。例如，可以定义一个存取器常数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是本发明可以与其交互的示例计算环境的示意框图。

详细描述

现在参考附图描述本发明，其中相同的标号代表在全部附图中的相同元素。然而，应当理解，附图及其详细说明目的不是将本发明限制于所揭示的特定形式。相反，目的是要覆盖落在本发明的精神和范围内的所有修改、等价和变更方案。

如在本申请中使用的，术语“组件(component)”和“系统(system)”目的是指计算机相关的实体，或者硬件、软硬件组合、软件或执行中的软件。例如，一个组件可以是，但不限于，在处理器上运行的处理过程、处理器、对象、可执行体、执行的线程、程序和/或计算机。作为例示，在服务器上运行的应用程序和服务器都可以是组件。一个或多个组件可驻留在一个计算机上和/或分布在两或多个计算机之间。

如在此使用的，术语“推理(inference)”一般指根据经由事件和/或数据捕捉的一组观测资料推断或推理关于系统10、环境和/或用户的状态的过程。例如，可以使用推理来标识一个特定的上下文或动作，或者可以产生关于各状态的分布概率。推理可以是概率的--即，基于数据和事件的考虑在感兴趣的状态上的概率分布的计算。推理也可以指用于根据一组事件和/或数据组成高层事件的技术。这样的推理根据一组观测到的事件和/或存储的事件数据导致新事件或动作的构造，而不论事件是否在接近的时间上相关、以及事件和数据是来自一个还是多个若干事件和数据源。

信息代理平台

首先转到图1，例示按照本发明一个方面的信息代理系统100。信息代理系统100包括应用程序编程接口(API)110、编译器120、事件组件130、上下文分析程序140、系统化数据存储器150、首选项执行引擎160、动作组件170和通知组件180。系统100提供一个平台，它促进各种信息代理应用程序的执行。系统100可以是一个独立系统或者是一个较大系统的一个组成部分。按照本发明的一个方面，可以结合计算机操作系统使用系统100，其中可以在多个不同计算设备包括但不限于个人计算机和移动设备诸如电话和个人数字助理(PDA)上使用操作系统。也可以在服务器(例如，SQLServer、WinFS服务器)上并且结合订阅服务使用系统100。因此，系统100可以用于提供在各种产品和服务(在客户机、服务器提供信息代理能力)与客户机-服务器-集群服务(例如，Outlook、Exchange和Hotmail)之间的协同。

在系统100中包括API 110以促进与系统100的交互。API 110可以由开发者使用以在信息代理系统100中的建立各种组件。而且，API 110可以用于从一个或多个事件源和/或可用于在系统100上运行的信息代理应用程序的当前用户上下文构造多个事件。而且，API 110可以用于反映存储在数据存储器150中的逻辑模式并且编写首选项到数据存储器150。应当意识到，API 110的许多其它用途，其目的是落在本发明主题的范围内，在阅读这个说明书时对于本领域熟练技术人员变成显而易见的。

数据存储器150是用于系统化数据的结构丰富的存储器。数据的系统化，数据构造成众所周知和定义的模式，对于本发明特别重要，因为它支持多应用程序交互。如在下面详细描述的，数据存储器150可以由信息代理应用程序用于存储，尤其是，与应用程序相关联的数据诸如例如事件和首选项的表。而且，尽管数据存储器150被例示为包括在信息代理系统100中，但应当意识到，数据存储器150可与系统外部的组件交互。

编译器120也包括在系统100中。编译器120用于编译信息代理应用程序。具体地说，编译器120编译开发者模式和最终用户首选项。按照本发明的一个方面，促进将模式和最终用户首选项翻译成存储在例如数据存储器150的表中的数据。

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

还存在可以由事件组件130用于收集数据的各种不同模型。这些模型可以影响事件组件130如何频繁和在什么环境下从各种事件源收集事件。

可以用至少两种方式之一通知或者为事件组件130提供数据。事件组件130可等待信息被“推(push)”或者发送给它，或者它可以通过轮询一源和收集任何新的或经更新的数据从该源“拉(pull)”信息。例如，如果用户希望每次在一个喜爱的新闻页面上的标题行故事变化时被通知，则可以实现事件组件130，例如，使得它监控该页面并且搜索标题行文本的变化。当文本变化时，事件组件130可以提取新标题行数据并且例如将它存储在数据存储器150的事件表中来将它提供给系统100。在上面的例子中，事件组件负责收集所需要的数据，因为不为事件组件130提供来自事件源的数据，如使用推方法的情况。

另外或者可供替换地，事件组件130可以获得系统100的事件数据，或者基于时间表或者基于符合预先规定的准则的事件的出现。排定的事件组件130可以周期性地运行，基于由应用程序开发者实现的设置。排定的事件组件130可以开始运行、检索和提供新的事件数据并且随后入眠直到下一个排定的触发时间。事件驱动的事件组件130也可以通过连续地运行来监控事件源。之后，当符合用于收集的特定准则的数据时，事件组件可以收集或者表示事件的发生。可供替换地，事件驱动的事件组件130只能响应于回调函数或者某些其它外部刺激来运行。这个外部函数随后将判定是否存在有效的事件数据要收集，并且使用事件组件130作为收集这类数据的装置。一旦事件组件130从外部事件源收集到数据，它应将数据写到事件表并且将该事件表保存到数据库150。

无论使用什么方法或系统汇集和/或收集事件，应当意识到，为了效率可以按批编写和处理事件。批，如在此一般定义的，可以是作为一个组处理的数据(例如，事件、首选项...)的集合。例如，组或批的大小可以由开发者在系统建立期间确定和指定和/或由用户通过控制面板指定。

按照本发明的一个方面，由上下文分析程序140控制的信息，包括在由分析程序确定的上下文信息中。上下文信息是由分析程序140通过基于一个或多个上下文信息源(未示出)鉴别用户的位置和注意状态来确定的，如在本说明书的后面章节更详细地描述的。上下文分析程序3122，例如，能够通过作为用户的汽车或蜂窝电话部件的全球定位系统(GPS)按精度确定用户的实际位置。分析程序也可使用统计模型通过考虑背景估计和/或观查资料(这是通过考虑这样的信息如日子的类型、时刻、在用户日程表中的数据和关于用户的活动的观测收集的)来确定用户在一个给定的注意状态中的可能性。给定的注意状态随后可以用作用户定义的首选项的事件或条件。

首选项执行引擎160也可以涉及动作处理。尽管首选项逻辑实际上只产生一组结果，但在此可供替换地将它称为动作，因为这是这类结果的共同影响。使用首选项执行引擎160执行动作只是一种可以执行动作的方式。动作也可以由仅从系统100检索首选项结果并且对它们起作用的应用程序执行。通过作为系统100一部分的执行引擎的动作执行具有更多主动代理的味道，而通过应用程序的动作执行具有更多被动决定逻辑的味道。因此，系统100可以为应用程序动作处理程序提供一个主机服务，应用程序动作处理程序可以用与系统100提供主机服务用于与事件组件130有关的事件检索和处理相似的方式检索和执行动作。而且，应当意识到按照本发明的一个方面，接近于数据的动作(例如，将一个电子邮件移到一个特定文件夹)可以在系统100内由执行引擎160与首选项评估以及同一事务的一部分同步地执行。

系统100的首选项执行引擎160，除了别的以外，处理或评估首选项。首选项是由事件发生触发的最终用户定义的规则。存在两个能由系统100支持的激活模型，同步和异步。在同步激活模型中，存在在事件提交与首选项评估之间的无关紧要的延时。即，首选项评估可以在对事件提交的应答之前完成。作为对照，在异步激活方式中，在事件提高的完成与首选项评估的完成之间，存在着显著的延时。例如，按照一种实现异步激活的方法，排队所提交的事件，直到对它们起作用。系统100可以支持一个或两个模型激活。而且，按照本发明的一个方面，可以在批提交期间动态地选择同步或异步行为，按照大量需要考虑的事项，包括但不限于批尺寸和可用于处理的时间。首选项处理的另一个方面包括隔离和事务边界。例如处理与一个单一事件批相关联的首选项可以是事务的(transactional)。可供替换地，许多事件批可以作为一个事务单元一起处理。系统100可以支持上述模型场景之一或两者。可供替换地，首选项执行引擎160处理事件提交和首选项处理的事务范围。系统100可以支持下列两个模型之一或两者。首先，事件提交和首选项处理可以共享同一事务且因此被一起执行。否则，事件提交和首选项处理可以在不同事务中发生。

按照本发明一个方面，执行引擎160和系统100可以支持轻量级和/或重量级信息代理或首选项应用程序。轻量级应用程序是那些要求低延迟时间、小数据库足迹和小工作集的应用程序。高吞吐量和可伸缩性对于轻量级应用程序不是第一位的要求。重量级应用程序是那些要求高吞吐量、可伸缩性、高可靠性、严格的正确性保证、可预测的崩溃恢复和简便的可管理能力的应用程序。低延迟时间和资源消耗对于重量级应用程序不是最优先考虑的事情。高性能服务器一般执行重量级应用程序，而轻量级应用程序通常在包括但不限于个人计算机和移动设备的较低性能的系统上使用。因此，执行引擎160必须能够区分重量级应用程序与轻量级应用程序并作出改变，以便以一种最响应于一种特定应用程序类型(例如，高吞吐量对低延迟时间)的方式执行。通常，执行引擎与数据库足迹、组件激活时的延迟时间、处理、存储器足迹和永久过程最有关系。重量级应用程序的执行可要求(1)大数据库足迹的分配，以便支持，除其它的以外，多数据库、表、视图、存储过程和用户定义函数；(2)事件收集、通知产生和通知分发的小轮询间隔；和(3)信息的批处理。轻量级应用程序的执行不同点在于，它们能够(1)在最小的存储器和数据库足迹的情况下被使用；(2)使用较大的轮询间隔用于事件收集、通知产生和通知分发(如果允许)；和(3)以小的批或个别处理信息如事件。而且，按照本发明的一个方面，不能在轻量级应用程序中支持主含事件提供者和某些通知分发，因为它们要求连续地运行干预系统响应时间的处理过程。然而，应当意识到，执行引擎160是灵活的，因为它能支持应用程序“轻度(lightness)”的递增变化，取决于可用的资源和技术状态。

应当注意，系统100还包括动作组件170。在首选项的成功评估时，首选项执行引擎160可以按照一个或多个有效首选项启用动作组件170以执行某些动作。动作可以影响在系统100内或外的数据存储器150(例如，插入、删除或修改数据)和/或其它组件和系统。一种特定类型的动作是用户通知。因此，动作组件由通知组件180例示。

参考图2，例示了通知组件180的更多细节。通知组件180包括格式化程序和交付协议274。通知组件180接收原始通知作为输入并输出最终到达用户设备(例如，计算机、PDA、移动电话...)的格式化的通知。在原始通知数据由通知组件180接收之后，通知被变换成为目的地设备格式化的可读通知，并且有可能用用户较喜欢的语言，随后通过交付协议274发送到该设备。内容格式化是由一个或多个内容格式化程序组件272处理的任务。内容格式化程序272用打包成数组的通知数据作为输入。对于标准交付，在数组中应当只有一个元素，它包含单个通知记录的信息。对于摘要交付，其中多个通知被搜索以在单个消息中发送到一个订户，在数组中可以有多个元素，它们每个包含来自一个通知的数据。内容格式化程序272随后格式数据用于显示，例如，使用包含在通知数据中的接收者信息来确定合适的格式化。而且，如果使用摘要交付，则内容格式化程序272还负责适当地聚集通知信息。在内部，内容格式化程序272可以使用任何合适的模式来格式通知。例如，这样的模式可以是与使用基本串操作一样简单，或者它可以更复杂，诸如使用可扩展样式表语言(XSL)变换或者ASP.NET呈现。当内容格式化程序完成其任务时，它输出一个包含格式化数据的串。该串连同可以产生的一些通知头部信息被传递到交付协议组件274。

通知交付通过交付协议274完成。当一批通知变成可供使用时，通知组件180读通知中的订户数据以确定合适的格式化。例如，通知组件180随后可以经由交付协议274发送通知到交付服务，诸如.NET报警(Alert)或SMTP服务器。更明确地说，当应用程序正在运行时，通知组件172可以读每个通知来获得订户交付设备和地点。分发程序随后将设备和地点的组合匹配一个特定的格式化程序对象来产生最终的通知。通知本身可以包含原始通知数据、在格式化时计算的数据以及由内容格式化程序272指定的文本的组合。这些选项允许专业的和用户友好的通知文本并且包括网络链接和标记信息。

尽管系统100可处理内部通知(例如，弹出通知)，但系统100不必办理将通知最终交付到外部第三方设备。相反，系统可以使用交付信道(未示出)，这可以看作是到交付服务如电子邮件网关或.NET报警服务器的管道。更明确地说，交付信道可以由协议和终点地址组成。系统100可以配置交付协议274来提供一个从通知组件180到一个将通知发送到接收者的外部交付系统的管道。通知组件随后可以将通知打包成一个使用交付协议组件274的协议数据包并且发送通知到一个或多个交付信道。交付信道随后将数据包提供给外部交付服务，它最终可以将通知发送给所希望的接受者。

信息代理应用程序

参考图3，描绘按照本发明一个方面的信息代理应用程序300。应用程序300是在系统100上的部署单元并且包括逻辑模式310、用户界面320、决策逻辑组件330、事件编程组件340和任务调度组件350。逻辑模式310定义系统化逻辑构件或模板，它们可以由最终用户放在一起。模式开发者负责构造逻辑模式310，以及默认行为，和在异常发生时的行为。实际上，逻辑模式310约束最终用户逻辑的实际表达力，从而使它对于未受训练的最终用户实际“编程”应用程序是实际的和切实可行的。逻辑构件可以包括一个首选项类、一组条件类定义和一组可能的结果或动作。条件和动作可以与相关应用程序300和/或用户上下文的功能有关。而且，应当意识到，按照本发明的一个方面，逻辑模式310可以使用XML(可扩展标记语言)来定义。

按照本发明一个方面，存在两种模式逻辑310可以定义的构件：定义模板化布尔函数的条件类和定义模板化过程的动作类。首选项类是信息代理模式开发的单元。首选项包括一组允许的条件类(例如，IsFrom(X)，IsTo(Y))和动作类(例如，MoveToFolder(Z)，Delete())。而且，每个首选项与一个特定的事件类或开始一个动作的触发器(例如，EmailEvent(电子邮件事件))相关联。在指定一个模式逻辑310之后，模式310可以由编译器120编译并且持久存留在数据存储器150的标准化系统元表中。而且，存储过程可以在可以评估首选项的编译时段内创建。模式逻辑310和过程两者都可以存储在系统化数据存储器150用于稍后的访问和执行。之后，当用户搜索以指定时，可以将首选项与逻辑模式122比较以验证它的形式一致并随后存储在数据存储器150中，例如在一个或多个首选项表中。当一个适当的事件发生时，系统100随后可以保证通过执行在编译时间内创建的存储的过程来评估适当的首选项。按照本发明一个方面，存储过程可以有效地以面向组的方式一起评估多个首选项，利用与索引和重复消除一样的技术(下文描述)。

用户界面320向最终用户呈现首选项编写或编程界面。最终用户不是受过训练的开发者，因此标准过程编程或编脚本对于指定逻辑的用户不是一个可行的选项。因此，逻辑可以用点击和拖拉或拷贝和通过的方式，例如通过用户界面320，来向最终用户可视地表示和显示。应当注意，用户界面320可以是应用程序300内的工具栏或者完全独立的图形用户界面(GUI)。而且，应当意识到，尽管应用程序300例示为包含用户界面320，但对于应用程序没有必要它们自己的用户界面用于定义首选项。为了逻辑建立，可以将应用程序设计为使用操作系统或应用程序专用用户界面。

应用程序300还包含三个组件，最终用户可以使用它们来产生首选项或变化功能的程序--决策逻辑组件330、事件编程组件340和任务调度组件430。决策逻辑组件330使最终用户能够定义决策逻辑(又称最终用户逻辑)。应用程序随后可以允许不同的决策受定义的最终用户逻辑控制。例如，最终用户可指定，如果、当和如何报警可以在屏幕上弹出和打断用户。应用程序也可以揭示最终用户可以附加决策逻辑的事件。例如，只要新电子邮件到达一个文件夹，电子邮件应用程序就可以提出一个事件。事件编程组件340允许最终用户附加指定可以发生的行为的首选项或规则，例如，取决于消息的内容和用户的上下文。在规则中的条件可以访问来自其它应用程序的数据(例如，活动目录，以检查发送者是否来自同一工作组)，并且动作可按照本发明一个方面影响其它应用程序450或提出另一个事件。任务调度组件430使最终用户能够将特别或预定义的任务附加到一个事件发生。例如，当新的客户申诉出现时，最终用户可以选择开始预定的工作流以处理该申诉。

决策逻辑组件330允许最终用户通过组合由开发者提供的条件和结论模板来编写决策逻辑或最终用户逻辑程序。决策逻辑可以使用“如果(条件)那么(结果)”首选项或规则来指定。这种类型的逻辑特别适合于最终用户描述，因为甚至绝对没有任何编程经验的最终用户也能容易地理解和创建这类规则。考虑例如下面的：如果(狗吠)或者(蜜蜂叮)那么(感觉难过)。这个规则是非开发者甚至小孩也能理解并在给定正确用户界面时说清楚。这种类型如果-那么(IF-THEN)逻辑编程适合于最终用户描述，至少因为它符合人的推理概念和口头交流。单个规则的语义是声明性的并且很好理解。而且，对于最终用户在活动上下文中应用首选项逻辑是直觉的。结果变成要采取的动作而不只是真实性的语句。例如，如果(狗吠或者蜜蜂叮)那么(回想在玫瑰上的雨点)。甚至在单个如果-那么规则内，在允许的表达力中可以存在变化程度的丰富性。前例在上面一般说来对应于命题逻辑。命题逻辑基于可以组合起来以产生逻辑语句的简单真/假命题的概念。然而，对于一般最终用户用于描述太复杂的丰富的逻辑形式，包括但不限于谓词逻辑、约束逻辑和递归，也可以结合本发明使用。

首选项可以通过用户界面(例如，控制面板、工具栏)来指定。模式开发者可以提供一组基本谓词作为条件逻辑的构件。最终用户可以随后拾取适当的条件，在适当的地方指派参数值，并且用布尔操作符(例如，AND(与)、OR(或)、NOT(非))将它们组合起来。同样，最终用户可以拾取适当的结果并且在适当的地方指派参数值。最终用户指定的程序的丰富性来自开发者提供的系统化逻辑。这些条件和结果模板在它们的内部逻辑方面是丰富的，访问多种多样信息，包括最终用户应用程序的结构化数据。每个条件或结果模板可以具有一个描述参数列表的模式。最终用户可以通过简单地提供适当的参数值来使用这些构件。

到这里已经描述了信息代理系统100的被动使用，下文描述更主动的型式。按照系统100的被动使用，应用程序负责在适当阶段启用决策逻辑并且提供必要的参数。应用程序也可以负责调用另一个应用程序对结果起作用。而且，应当注意，程序内部结构，即系统100也需要一个解释程序(未示出)来评估首选项，处理多个首选项之间的冲突，并确定正确的结果集。

事件编程组件340为信息代理应用程序300提供至少三个功能。第一，事件编程组件420可以提供一组系统化信息事件(例如，由模式开发者定义的)，可以用作最终用户程序的钩子。每个事件可以用它携带结构化数据。有许多机制用于事件实例捕捉(例如，事件提交的API)。还有一些信息事件的子类。一个事件子类相应于在系统化数据存储器150中的数据改变。因此，事件编程组件340可以提供机制，以访问存储器420中的数据变化并使它们可用作系统化改变事件。另一个事件子类可以相应于再现定时器事件，它对于预定的首选项活动是重要的。事件编程组件340也可以提供将“处理程序(handler)”逻辑关联于特定事件的发生的能力。另外，事件编程组件340可以提供服务来捕捉事件、应用适当的决策逻辑和启用动作处理程序来执行决策结果。

事件编程组件340可以与决策逻辑组件330交互以提供附加的功能。例如，最终用户可以建立使用决策逻辑组件330的持续的决策逻辑，在新事件到达时它被反复地应用程序。因此，在其上运行的系统和/或程序可以是活动的，因为每个触发事件引起适当的决策逻辑的评估。更具体地，触发事件可以形成决策逻辑的输入，并且首选项逻辑评估的结果可以形成事件编程组件340可以代表最终用户执行的动作。另外，动作可提出新出现的事件，它随后使更进一步的逻辑由编程组件340执行。因此，存在特别链接式事件编程的概念。

任务调度组件350管理最终用户任务调度或工作流。在此使用的时间表是一个经过协调的任务集，在任务之间具有特定的排序和分段。在它们整体上执行任务的目的一般是实现某个真实世界的目标，例如，调度一个四个人的会议。在这个会议例子中，在时间表中的任务可以包括，特别是，发送初始会议请求和处理肯定和否定的响应。尽管工作流在业务处理自动化中是共同的，但任务调度或工作流，如关于本发明所述的，与最终用户活动相关联(例如，调度会议、检阅文档、委托请求...)。尽管这些工作流中的许多是简单的过程，但它们对于最终用户是能定制和透明的。

任务调度组件350可以与由决策逻辑组件330和事件编程组件340两者提供的功能交互并利用它。事件编程组件340提供一个理想的钩子来调用任务调度。例如，包括一个工作请求的新电子邮件的到达可启动一个任务调度。尽管某些任务调度是刚性的，处理流程是明确的，但许多其它任务调度是灵活的，允许最终用户在不同路径之间选择。例如，如果一个会议请求被两或多个被邀请者拒绝，则会议可以重新调度或者可供替换地会议可以进行。这是使用最终用户首选项和决策逻辑组件330的合适场所。而且，应当注意按照本发明的一个可替换方面，任务调度组件350可以被结合到事件编程组件340中，因为调度包括对改变作出反应和启用适当的动作。总之，尽管任务调度的某些部分可以由开发者硬编码，但通过使流程动态化添加一个有意义的值，并由显式的用户决策(它们有时是通过最终用户编程被自动化的)配置。

对于在此描述的信息代理概念有至少两个主要元素。首先，最终用户提供控制应用程序行为的决策逻辑的能力是重要的。这只是最终用户对应用程序的编程能力，并且实际上不包括代表最终用户起作用的代理。这在此称为最终用户逻辑的被动启用。第二，在信息代理概念中的一个重要元素是最终用户提供主动的决策逻辑的能力。主动的决策逻辑可以在适当的信息事件发生时反复地应用程序，因而用作代表最终用户的软件代理。在两种情况下，决策逻辑一般是上下文相关的--取决于用户的上下文和应用程序的状态。下文将描述在这两个上下文类别中的各种情况。而且，还将描述以信息代理可以采用的不同“人物(persona)”的形式的端对端情况。

最终用户逻辑的被动启用的一个例子是操作系统使用一个信息代理控制对用户的打扰。只要某个应用程序想要在屏幕出现一个伴有声音的弹出，操作系统可使用一个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(收件箱首选项类)

·ConditionClass(条件类)

*IsFrom(X)(是来自X的)

*IsTo(Y)(是给Y的)

·ActionClass(动作类)

*MoveToFolder(Z)(移到文件夹Z)

*Delete()(删除)

·TriggeringEventClass(触发事件类)

*EmailEventClass(电子邮件事件类)

·触发事件的源

*改变到一个收件箱文件夹

*ApplyNow()(现在应用程序)

*SheduledEvent()(预定的事件)

首选项是最终用户逻辑的单元。首选项可以是“当(事件)时如果(条件)那么(动作集)”形式的逻辑语句。每个首选项因此应当但不要求具有下列属性。首先，首选项应当发生一个首选项类。其次，首选项应当由某个用户或委托人拥有。第三，条件应当是一个组合一个或多个条件类的声明性布尔表达式，其中每个条件实例定义条件类的参数值。最后，动作集应当是一组动作类。每个动作实例定义动作类的参数值。例如：

UserPreference(用户首选项)：

·InBoxPreferenceClass(收件箱首选项类)的实例

·IF(IsFrom(John)OR IsTo(’bookclub″)THEN MoveToFolder(’BookClub’)(如果(是来自(约翰)或者是给(‘图书俱乐部’)那么移到文件夹(‘图书俱乐部’))

最终用户随后可以通过定义事件处理程序来“编程”。每个事件处理程序是由一组相同首选项类的首选项定义的并且因此由相同的事件触发。例如：

·IF(IsFrom(John)OR IsTo(’bookclub″)THEN MoveToFolder(’BookClub’)(如果(是来自(约翰)或者是给(‘图书俱乐部’)那么移到文件夹(‘图书俱乐部’))

·IF(IsTo(’SillyStuffDL’)THEN Delete()(如果(是给(‘无聊内容下载’)那么删除)

随后，当一个特定事件发生(例如，电子邮件到达)时，不止一个首选项可能具有有效的条件，导致执行多个动作的可能性。各种冲突解决机制随后可应用程序，如下所述。

而且，应当意识到，每个条件只是一个布尔函数连同它的启用参数。按照本发明的一个方面，要求系统逻辑跨越应用程序边界。因此，条件需要能够观看由许多不同应用程序创建的数据。例如：

·存在数据：IF(IsFrom(’John’)AND SenderIsOnline())THEN...(如果(是来自(‘约翰’)并且发送者是在线的)那么...)

·位置数据：IF(IAmFarMeetingLocation())THENRemainderMinutesWindow(30)(如果(我在远的会议位置)那么提醒(30)分钟窗口)

·组织层次结构：IF(IsFromMyManagement())THENMarkAsHighPriority()(如果(是来自我的管理那么标记为高优先级)

所有上面的例子涉及用户上下文。用户上下文可以由上下文分析程序140(图1)确定并且存储在数据存储器150(图1)中供信息代理应用程序使用。因而，象“Bool IsOnline(X)(布尔)X(是在线的)”的函数可以返回真或假，基于传入的个人X的身份和他/她的当前上下文，如由上下文分析程序确定的。

继续上面的例子，一个首选项类如InBoxPreferenceClass(收件箱首选项类)的模式开发者需要提供一个条件类410供最终用户使用。这可以由若干方式来完成。例如，一个条件类可以是IsOnline()(是在线的)。在这个例子中，最终用户可定义一个“IF(IsOnline(Email.Sender))THEN...(如果(电子邮件的发送者是在线的那么...)”形式的首选项。可供替换地，条件类可以是SenderIsOnline()(发送者是在线的)，并且在其声明中模式开发者可定义一个首选项或规则如下：“IF(SenderIsOnline())THEN...(如果(发送者是在线的)那么)”。因此，最终用户可定义一个首选项或规则如下：“IF(SenderIsOnline())THEN...(如果(发送者是在线的)那么...)”。尽管本发明支持大量指定条件类410的形式，但应当注意，在上述形式中存在显著的区别。第一个形式是传统的谓词演算规则形式，其中编写规则的个人(即，最终用户)推理关于模式和可变绑定。第二个形式不太灵活，但对于最终用户使用肯定更简单。因此，条件类410是模式开发者可以限制最终用户逻辑的表达力的地方，并且因而使它对于未用过的最终用户来“编程”信息代理应用程序更实用和切实可行。

简言之，模式开发者编写首选项类425，产生一组条件类声明410。每个条件类声明标识一个执行函数和由开发者定义的表达式绑定的函数的参数。剩余的参数是由最终用户在建立首选项时为每个条件实例提供的常数。动作是动作类415的实例。每个动作类415是具有参数的过程。就象条件一样，参数由开发者绑定或者可由最终用户指派。而且，事件类420提供事件的定义。事件类定义事件信息内容，如由开发者指定或者由最终用户指派，它触发首选项评估。

如贯穿本说明书提到的，并且按照本发明的一个方面，最终用户不预期为有经验的程序员。因此，基于具有直观的名字(例如，EmailIsFrom()(电子邮件来自))的条件创建首选项，并且条件的自变量可以是简单的用户定义常数(例如，玛丽)。这使最终用户能够编写一个由EmailIsFrom(Mary)(电子邮件来自玛丽)触发的首选项。然而，具有仅基于用户提供的串常数的自变量太受限制。因此，可以在逻辑模式400指定绑定430，作为首选项类425的一部分，以使编程对于最终用户更容易并且扩展可以检索信息的范围。存在至少三个可以在模式400中指定的参数绑定类型。第一，可指定预定义一个常数的常数绑定。指定一个常数绑定是有利的，至少因为它使最终用户免除必须选择或指定一个常数。事件绑定的表达式也可以绑定到作为条件和动作的自变量提供的值。更明确地说，可以定义使用事件字段和常数来计算值的表达式。例如：

·条件类：SenderIsOnline()(发送者是在线的)

·定义函数：IsOnline()(是在线的)

·绑定：X→Email.Sender(X→电子邮件.发送者)

最后，可定义常数存取器。常数存取器是命名的对象分组，它代替用户必须人工地指定每个这类对象，提供条件和动作的自变量。

常数存取器是非常强大的常数，允许编写能够导航和从各种域检索信息的首选项和条件。这些常数只是虚饰在用于找到和具体化正确信息的函数上的名字，即与常数的名字相关联的分组成员。简短地转到图5，例示了按照本发明一个方面用于检索常数值的系统500。系统500包括一个存取器输入组件510、链接组件520和多个域530、540和550(域1至域N，其中N大于一)。存取器输入组件610接收一个常数如MyFamily(我的家庭)、MyCoworkers(我的同事)或MyFriends(我的朋友)作为输入，并且提供该常数给存取器组件520。存取器组件520用于通过所有可访问的域520、530和540搜索以尝试和解析或者链接到与由输入常数指定的分组成员相关联的值。按照本发明的一个方面，域530、540和550可以是存储在系统化数据存储器中的应用程序。例如，域520可以是一个电子邮件应用程序，域530可以是一个日程表应用程序，而域540可以是一个客户帐户应用程序。因此，存取器组件520可在试图确定一个常数(例如，MyFamily(我的家庭))值时访问电子邮件应用程序或者定位数据注册表。如果组件530不能在该域或者在一个定位的数据注册表中解析这个值，则它可以保持检查其它可访问的域，直到确定常数值或者它已经检查了所有可用的域。在一个例子中，存取器组件可在电子邮件应用程序中查找数据，诸如：

<MyFamily>

 <Father>Bob Jones</Father>

 <Mother>Barb Jones</Mother>

 <Brothers>

  <Brol>Michael Jones</Brol>

  <Bro2>Jason Jones</Bro2>

 </Brothers>

</MyFamily>

应当注意，与常数MyFamily(我的家庭)相关联的分组成员的XML表示只用于例示的目的。一个分组的填充可以用许多方式由本发明定义和/或具体化。因此，存取器组件520可解析或链接MyFamily(我的家庭)到Bob Jones、BarbJones、Michael Jones和Jason Jones，基于从电子邮件应用程序的检索的数据。然而，存取器组件540可继续其它域以保证数据完整性和准确性。例如，它可在日程表应用程序中找到<MySister>Jennifer Jones</MySister>，并且将这个值添加到与常数MyFamily(我的家庭)相关的值串。

到这里所讨论的常数(例如，MyFamily(我的家庭)、MyCoworkers(我的同事)、MyFriends(我的朋友)、MyFavorite Musicians(我喜爱的音乐家))称为一阶常数，因为它们是相对于一个给定用户定义的。存取器组件510或存取器随后可以切断用户的身份或者其它起点。也应当注意，N阶常数也可以由用户通过使用首选项来组合以前定义的分组(例如，由常数命名的)来编写和保存。作为例子，考虑常数命名的分组的组合，提供与介语短语相似的功能。例如，用户可以编写和保存象FriendsOfMyFamily(我的家庭的朋友)或EmailsFromPreferredCustomersInAppointmentsToday(来自今天预约的较喜欢的客户的电子邮件)这样的常数。从另一个角度，常数扩展与也可以表示为常数存取器并且与其它常数组合的项目字段上的条件相似。

因此，常数存取器提供跨越不同域对数据的导航。系统化逻辑与导航的存取器的组合使非程序员能够编写跨域的首选项。而且，与相对小数量的存取器约束组合的相对小数量的条件类促进了大量感兴趣和强大的条件的指定，否则必须由应用程序开发者参与。

另外，应当注意，也可以指定首选项分组。由最终用户定义的决策逻辑由一个或多个首选项集表示。因此，首选项分组可以定义为相关联首选项分组的容器。在一个首选项分组内的首选项随后可以(1)属于同一首选项类，(2)被一起评估，结果接受冲突解决。而且，在首选项分组中的首选项可以共同地允许或禁止。首选项的共同允许和禁止在无数情况中是有用的。例如，最终用户在工作时具有一组首选项，并且在家里时具有另一组首选项。因而，可以基于用户上下文允许或禁止首选项分组。

逻辑模式400还包括记事435。许多信息代理应用程序需要保持状态以便作出明智的决策。如一个简单的例子，考虑新闻公布信息代理应用程序。最终用户订阅感兴趣的新闻文章。事件馈送运送新闻文章的稳定流。一个问题是同一文章可带有轻微修改的内容到达许多次，但带有同一标题。在这个上下文中，明智的条件是：IsNewArticle()(是新文章)。这个条件可以检查以前未见过的标题。另一个例子是检查更新的稳定流是否使一篇文章成为一个断续的故事。为了允许这种类型的功能，在处理事件时需要保持一个状态。这个状态在此称为记事(chronicle)，因为它是应用程序历史的表示。

信息代理模式开发者可以定义记事(例如，作为关系数据库中的表，或者在由操作系统管理的文件夹中)。更重要地，模式开发者可以定义在事件处理的重要阶段运行的逻辑，以便更新应用程序状态。例如，计算一个事件是否相应于一个断续故事的适当时间是在事件被处理之前。另外，记录一个新闻文章被处理的事实使得后续的具有相同标题的事件示为复制品的适当时间，是在事件被处理之后。而且，应当注意，记事也可以用于记录动作历史以及事件历史。

开发者可以指定冲突解决组件545中的冲突解决过程或逻辑作为逻辑模式400中首选项类425的一部分。当一个事件发生时，多个动作可以引起，如果多个首选项符合该事件。因而，用于确定执行的顺序和/或最后采取的动作的系统和方法是想要的。有至少三种方法来处理多个动作的触发。第一，模式500可允许最终用户能够定义动作或首选项优先级。例如，最终用户可指派优先级给每个首选项。另外，最终用户可将一个停止处理指示符(例如，标志)指派给某些首选项。因此，当一个事件触发多个动作时，可按优先级的顺序执行动作。另外和可供替换地，如果多个首选项在一个首选项分组内符合，则可以执行最高优先级的首选项而丢弃其它的。而且，模式400可使最终用户能够指定冲突解决过程，诸如允许它们附加一个停止处理指示符到某些首选项以处理一个包含该指示符的首选项在其它首选项同时被触发时的情况。另一个可以解决冲突的方式是通过定义模式400内的动作类优先级。因此，模式开发者可以指定动作类优先级。例如，MoveToFolder(移到文件夹)动作类可指定比Delete(删除)动作类更高的优先级。其它冲突情况可以在同一动作类的多个动作被同时触发时引起。模式开发者可以定义多个冲突解决逻辑以处理这种情况。例如，假定有一个动作类设置想要的弹出的音量(例如，SetVolume()(设置音量))。还假定一个事件触发两个动作，SetVolume(50)(设置音量50)和SetVolume(70)(设置音量70)。在这种情况下，在冲突解决组件545中定义的冲突逻辑可以这样定义，使得相应于两个级别的最小、最大或平均来采取动作。

首选项执行顺序也可以通过显式执行组件450在模式400中指定。在有些情况下，首选项的显式排序是必要的，因为一个首选项的动作可以影响另一个中的条件。例如，关于电子邮件首选项，一个首选项可以用于决定进入消息的优先级，同时另一个首选项可被编写为对消息的优先级起反应并且决定如何对它起作用。最终用户首选项编写者一般是没有经验的程序员。按照本发明一个方面，不要求最终用户编写具有副作用并因此具有排序要求的首选项或规则。最好是模式开发者向最终用户隐藏排序依赖。这可以用多个不同方法来完成，包括但不限于首选项类排序、显式链接和首选项分组排序。通过首选项分组排序，模式开发者可以排序首选项类以在另一个之前执行。在上面提到的例子中，用于建立消息属性(例如优先级)的首选项类应当在对消息起反应的首选项类之间出现。按照本发明一个方面，向最终用户呈现的用户界面可被划分成窗格，使得首选项类具有它自己的窗格。按照显式链接，模式开发者可指定引起新出现事件的动作及其排序。因此，首选项类可用动作-事件链接而不是首选项类排序来实现。而且，模式开发者可使用首选项分组指定执行排序。使用首选项分组排序提供与首选项类排序相同的能力，但以更灵活的形式。例如，每个首选项分组可在其中只有一个首选项，导致等价于首选项的完全排序的顺序列表。

使用要求的条件和动作组件455，“要求的(required)”条件和动作也可以在模式400中指定为首选项类425的一部分。每个首选项类可以包括要求的条件和动作。要求的条件和动作可以用于在所有首选项上强制某些共同的模式。例如，在熟悉的在服务器上应用程序的电子邮件处理例子中，关于收件箱首选项的要求的条件为首选项的所有者也是电子邮件的接收者。

模板460也可以在逻辑模式400中定义。为方便没有经验的最终用户对逻辑的编写，可以由开发者或者第三方提供模板供最终用户采纳和使用。因此，如果模板可用于最终用户，则系统100应当支持首选项模板的抽象。这可以简单地相应于一个具有部分未指定的参数的持久的完整首选项(选择条件表达式和动作)。

也可以定义模式400，以便通过预定和再现的首选项组件405处理预定和再现的首选项。许多信息代理应用程序希望使用在再现调度上评估的首选项。许多例子之一包括每个工作日在5p.m.(下午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可以为事件捕捉逻辑提供一个主机服务，它不要求主动执行的较大应用程序。例如，包信息代理应用程序希望某个操作系统事件触发应用程序活动。因此，有可能在一个服务中主这个事件提供者而不要求一个仅为此功能运行的单独应用程序。

首选项由事件的发生激活。其处理可以是同步的、异步的或者两者的组合。对于同步处理，在事件提交与首选项评估之间存在微不足道的小延迟。另一方面，异步处理，在事件提交与事件处理之间存在明显的延迟。本发明的系统支持两种处理模型并且可以实时基于事件批提交在这些模型之间选择。

而且，按照本发明的一个方面，首选项处理利用强大的数据库查询来有效地评估首选项。向开发者并且最终向最终用户揭示的是一个声明性编程模型，允许条件功能按照一次一个模型来指定。一次一个编程模型是一个最自然使用的模型，并且使开发者和用户能够针对一个首选项指定一个事件。然而，按照本发明的一个方面，系统100制作以面向集合的方式执行的条件类查询，利用像索引和重复消除的技术。这是有利的，因为首选项是以有效方式评估的，同时开发者和用户保留着以一次一个的方式概念化和编写程序，尽管这易于理解和编写，但这是一种效率低下的方式来执行大量首选项。而且，尽管多个首选项可以成批处理，但应当注意，首选项可以在事件发生时个别地评估。

转到图6，例示按照本发明一个方面用于首选项评估的系统600。系统600包括一个数据存储器150、大量表610、首选项执行引擎160和一个结果表630。数据存储器150容纳大量表610，它们是由系统100从一个开发者模式以及最终用户首选项产生的。作为一个事件发生的结果，首选项执行引擎接收或检索首选项，例如从存储在数据存储器150中的表。执行引擎160随后使用首选项以及一些存储过程(它也可以存储为数据)到查询表610并产生一个结果表630。结果表630可以存储已经满足其条件使得指定的动作可以在其上开始的首选项。

表610的数量和复杂性可以根据由开发者为支持最终用户首选项编写的模式的复杂度变化。下文提供一个例子，以便阐明系统600如何使用数据库表和查询来处理首选项。在本例中，有两个人，杰克和吉尔，它们搜索所使用的若干首选项分组。如已经讨论的，在杰克和吉尔可以指定最终用户首选项之前必须已经产生一个模式。模式具有上述几个部分，然而为了方便理解，在此描述一个非常简单的模式。一个模式的基本部分之一是事件类的定义。在本例中，考虑两个事件类，EmailEvent(电子邮件事件)和Stockevent(股票事件)。转到附于本文的附录，示出例示两个事件类以及三个首选项类的模式定义的伪代码。这两个首选项类基于EmailEvent(电子邮件事件)而第三个类基于StockEvent(股票事件)。信息系统100随后可以使用这个模式来产生一个首选项类表和条件类，它们可以存储在数据存储器150中。例如：

PreferenceClass(首选项类)表

  App.Id(应用程序ID)  Pref.Class Id(首选项类ID)  Pref.Class Name(首选项类名字)  Event Class Id(事件类ID)  111  123  EmailPreferences1(电子邮件首选项1)EmailPreferences2(电子邮件首选项2)StockPreferences(股票首选项)  112

ConditionClass(条件类)表

  Pref.Class Id(首选项类ID)  Cond.Class Id(条件类ID)  Cond.Class Name(条件类名字)  112233  123456  MailsFrom(邮件来自)MailContains(邮件包含)MailPriority(邮件优先级)MailIsFrom(邮件来自)StockSymbol(股票符号)TargetPrice(目标价格)

杰克和吉尔随后可以定义它们的首选项。为了这个例子，假定杰克定义三个首选项分组PG(杰克，1)，PG(杰克，2)和PG(杰克，3)。而且杰克定义五个首选项分布在如下的分组之中：

PG(Jack，1)((PG(杰克，1))

P1：On EmailEvent if MailIsFrom(Mary)AND MailContains(″Califonia″)then PopAToast(当电子邮件事件时如果邮件来自玛丽并且邮件包含加利福尼亚那么弹出一个祝酒词)

P2：On EmailEvent if MailIsFrom(Bob)AND MailContains(″InfoAgent″)then PopAToast(当电子邮件事件时如果邮件来自鲍伯并且邮件包含信息代理那么弹出一个祝酒词)

P3：On EmailEvent if MailIsFrom(Home)AND MailContains(″MyWife″)OR MailIsFrom(MySon)then PopAToast(当电子邮件事件时如果邮件来自家里或者邮件来自我的妻子或者邮件来自我的儿子那么弹出一个祝酒词)

PG(Jack，2)((PG(杰克，2))

P3：On EmailEvent if MailIsFrom(Home)AND MailContains(″MyWife″)OR MailIsFrom(MySon)then PopAToast(当电子邮件事件时如果邮件来自家里或者邮件来自我的妻子或者邮件来自我的儿子那么弹出一个祝酒词)

(PG(Jack，3)((PG(杰克，3))

P4：On EmailEvent if MailIsFrom(Home)AND MailPriority(10)thenMoveToFolder(″URGENT″)(当电子邮件事件时如果邮件来自家里并且邮件优先级为10那么移动到文件夹“急件”)

P5：On EmailEvent if MailPriority(15)then MoveToFolder(″VERYURGENT″)(当电子邮件事件时如果邮件优先级为15那么移动到文件夹“非常急件”)

为了本例的目的，假定吉尔定义两个首选项分组(吉尔，1)和(吉尔，2)。而且，假定吉尔指定五个首选项分布在如下的分组之中：

PG(Gill，1)((PG(吉尔，1))

P6：On EmailEvents if MailIsFrom(Home)OR MailContains(″Vaction″)then PopAToast(当电子邮件事件时如果邮件来自家里或者邮件包含“度假”那么弹出一个祝酒词)

P7：On EmailEvents if MailIsFrom(Bob)OR！MailContains(″Work″)thenPopAToast(当电子邮件事件时如果邮件来自鲍伯或者邮件不包含“工作”那么弹出一个祝酒词)

P8：On EmailEvents if MailContains(″Bonus″)then PopAToast(当电子邮件事件时如果邮件包含“奖金”那么弹出一个祝酒词)

PG(Jill，2)((PG(吉尔，2))

P9：On StockEvents if StockSymbol＝(’EBAY’)AND TargetPrice>120 thenSendCellPhoneMessage(’Me’)(当股票事件时如果股票符号＝“EBAY”并且目标价格>120那么发送蜂窝电话消息“Me”)

P10：On StockEvents if StockSymbol＝(’AMZN’)AND TargetPrice>50 thenSendCellPhoneMessage(’Me’)(当股票事件时如果股票符号＝“AMZN”并且目标价格>50那么发送蜂窝电话消息“Me”)

信息代理系统100随后可以使用这些首选项来产生另外的关系数据库表，它们描述与其相关联的首选项和条件。一次一个地考虑下列示例性表以及如何使用它们来评估首选项。

下面示出的首选项分组表包含五行，杰克和吉尔定义的每个首选项分组一行。而且注意，指定一个列来表示是否允许首选项分组。如前所述，这是有用的，例如，如果用户想要指定一个当他们在家里时允许的首选项分组和另一个在他们工作时允许的首选项分组。这里所有首选项分组被示为允许的。

PreferenceGroup(首选项分组)表

  Pref.Group Id(首选项分组ID)  Pref.Group Name(首选项分组名字)  Subscriber(订户ID)  Enabled(允许的)  12345  Jack_1Jack_2Jack_3Jill_1Jill_2  JackJackJackJillJill  真真真真真

PreferenceGroupMemberShip(首选项分组成员资格)也可以定义为概括哪些首选项是哪些首选项分组的成员。下面例示的这个表包含十一行，每个首选项一行。

PreferenceGroupMemberShip(首选项分组成员资格)表

  首选项分组ID，  首选项ID，  11123344455  123345678910

下面的首选项表可以存储在数据存储器150以概括与由用户定义的首选项相关的数据。这个表将包含十个相应于这十个首选项每一个的行。请注意，这个表集中于仅示出重要的列和名字。

首选项表

  Pref.Class ID(首选项类ID)，  Pref.Id(首选项ID)  Orig.Cond.Expr(首选项ID，原来的条件表达式)， ANDGroupCount(与分组计数)  1112  1234  From(Mary)AND Contains(CA)(来自玛丽并且包含CA)From(Bob)OR Contains(IA)(来自鲍伯或者包含IA)From(Home)OR From(MyWife)OR From(MySon)(来自家里或者来自我的妻子或者来自我的儿子)From(Home)AND Priority(10) 12312111335678910  (来自家里并且优先级10)Priority(15)(优先级15)From(Home)OR Contains(Vacation)(来自家里或者包含度假)From(Bob)AND！Contains(Work)(来自鲍伯并且不包含工作)Contains(Bonus)(包含奖金)Symbol(EBAY)AND Price(120)(符号EBAY并且价格120)Symbol(AMZN)AND Price(50)(符号AMZN并且价格50)121111

注意：总和＝14

应当注意，在上面的首选项表中一共有14个AND分组。

另外，上面一共有19个条件。关于这些AND分组和条件的信息可以在如下的附加表中捕捉：

ANDGroup(与分组)表

  Pref.Id(首选项ID)，  ANDGroupId(与分组ID)，  ConditionCount(条件计数)  12233345  12345678  2--From(Mary)AND Contains(CA)(来自玛丽并且包含CA)1--From(Bob)(来自鲍伯)1--Contains(IA)(包含IA)1--From(Home)(来自家里)1--From(MyWife)(来自我的妻子)1--From(MySon)(来自我的儿子)2--From(Home)AND Priority(10)(来自家里并且优先级为10)1--Priority(15)  6678910  91011121314  1--From(Home)1--Contains(Vacation)(包含度假)1--From(Bob)AND！Contains(Work)(来自鲍伯并且不包含工作)1--Contains(Bonus)(包含奖金)2--Symbol(EBAY)AND Price(120)(符号EBAY并且价格120)2--Symbol(AMZN)AND Price(50)(符号AMZN并且价格50)

AND分组ID是从先前的表顺序编号的。ConditionCount(条件计数)记录由与(AND)连接的条件的数量。在上面的表中唯一令人吃惊的行条目是下面示出一个。

711 1--From(Bob)AND！Contains(Work)(来自鲍伯并且不包含工作)

注意，ConditionCount(条件计数)是1而不是如所预期的2。为了解释在查询评估中非(NOT)的存在，条件计数定义为只有在其前面没有非(Not)(！)的与分组中的那些条件的总和。在其前面具有非(NOT)的条件可以在如下所示的一个单独的表中概括。

ANDGroup(与分组)可以进一步在表中按照ANDGroupMembership(与分组成员资格)定义，如下面的串联的表例示：

ANDGroupMembership(与分组成员资格)表

  ANDGroupId(与分组ID)，  Cond.Class Id(条件类ID)，  Cond.Id(条件ID)  11234  12121  1--From(Mary)(来自玛丽)2--Contains(CA)(包含CA)3--From(Bob)(来自鲍伯)4--Contains(IA)(包含IA)5--From(Home)(来自家里)  ...............................  ..............................................................  14  6  19--Price(50)(价格50)

如上提到的，具有非(NOT)的条件可以看作是一种特殊情况并且在它们自己的表中概括，如下：

非(Not)表

  Cond.Class Id(条件类ID)，  Cond.Id(条件ID)  2  14--！Contains(Work)(不包含工作)

还可以创建条件值表来存储在首选项中指定的条件值。应当注意，这个目标只考虑与每个条件相关联的两个参数值。为了这个例子的目的，这是足够的，部分因为所有的条件只具有一个参数值，然而如果条件被允许包含多于两个与其相关联的值，则表可以被扩展或者可供替换地另一个表可被实例化以如何处理额外的条件值。

ConditionValue(条件值)表

  Pref.Id(首选项ID)，  Cond.Class Id(条件类ID)，  Cond.Id(条件ID)， ParamVal1(参数值1)，  ParamVal2(参数值2)  11223  12121  12345 MaryCABobIAHome  NULLNULLNULLNULLNULL  .............................................................................................  10  6  19  50  NULL

也可以提供ConditionsResult(条件结果)。ConditionsResuit(条件结果)表可以用作最后结果表730的预报器。ConditionsResult(条件结果)表是在执行条件查询时填充的。因为条件查询还没有运行，所以在表中还没有行。下面揭示用于评估条件和填充表的示例性过程。

ConditionResults(条件结果)表

  Bool(布尔)，  Cond.ID(条件ID)，  Pref.Id(首选项ID)，  Event ID(事件ID)

如前面提到的，本发明的一个方面是要提供一个声明性编程系统，它允许向条件功能的开发者揭示一个一次一个模型，但这最终制作利用数据查询效率的面向集的方式执行的条件类查询。因此，一对一条件类声明可以被变换成查询。例如，在EmailEvent(电子邮件事件)中，一个最终用户首选项可以使一个动作依赖于电子邮件的发送者(例如，杰克的P1)。因而，一个通过用户界面的最终用户可编写MailIsFrom(Mary)(邮件来自玛丽)。然而，当执行首选项时，系统700可执行表示用户条件语句的数据库查询。例如，系统可执行下列SQL查询语句代替用户声明即CV.ParamValue1＝’Mary’：

SELECT 1

FROM EmailEvents E，ConditionValues CV

WHERE E.Sender＝CV.ParamValue1；

因此，开发者应当定义用于每个条件的查询代码并将它们存储在一个表中。尽管可能，但不需要为了表达的目的而创建一个新的表。可以简单地修改前面定义的ConditionClass(条件类)表以包括如下面的伪代码中所示的查询文本。

  Pref.Class ID.(首选项类ID)，  Cond.Class ID，(条件类ID)，  Class Name，(类名)，  Query_Text(查询文本)  1  1  MailFrom select 1，Cond.Id，Pref.Id，Event Idfrom EmailEvents E，ConditionValues CVwhere E.Sender＝CV.ParamValue1AND CV.Cond.ClassId＝1AND required conditions  1  2  MailContains select 1，Cond.Id，Pref.Id，Event Idfrom EmailEvents E，ConditionValues CVwhere E.MessageText like′％′+CV.ParamValue1+′％′AND CV.Cond.ClassId＝2AND required conditions  .............................................................................................................................................  3  6  TargetPrice select 1，Cond.Id，Pref.Id，Event Idfrom StockEvents S，ConditionValues CVwhere S.Price＞CV.ParamValue1AND CV.Cond.ClassId＝6AND required conditions

一旦已经定义了所有的表710，就可以针对这样的数据评估首选项，以便填充结果表730并且之后执行与其相关的动作。通过评估查询可以执行首选项。可以通过使用一个或多个过程评估查询，可以将它们存储为数据存储器150中的数据并且在需求时按照本发明的一个方面来构造它们。若干过程可以专用于评估条件和首选项并且随后填充结果表，例如用首选项以及表示是否评估为真的首选项的标记，使得相关联动作的执行可以开始。例如，下面的过程可以用于评估或查询条件并且将结果存储在ConditionResults(条件结果)表中，随后可以被评估以填充结果表730。

create proc NSStoreResultsIntoResultsTable

@conditionClassId int

AS

declare @query varchar(255)--这个数字可以更大

select @query＝Query_Text

from CondtionClasses

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，  Cond.ID，  Pref.ID，  Event ID  11  12  11  100--From(Mary)(来自玛丽)100--Contains(CA)(包含CA)

在首选项1中这两个条件之间有一个AND(与)。因此，这个首选项只有在上面条件都为真时才评估为真。这两个条件属于第1个ANDGroup(与分组)，其条件计数是2。因此，当上面的表与AndGroupMembership(与分组成员资格)表连接时，下面的表得到：

  Bool，  Cond.ID，  Pref.ID，  Event ID，  AndGroupId  11  12  11  100100  11

合计＝2

在执行分组(group by)之后，得到下面的行

 sum(Bool)， Pref.ID， Event ID， AndGroupId 2 1 100 1

现在(首选项ID，ANDGroupId(与分组ID))形成ANDGroup(与分组)表的键。在这个查找中提供条件值2，它等于sum(Bool)(Bool之和)。因此首选项是真的，并且可以将它添加到结果表730。

例2：

假定ConditionResults表具有下面的二个行：

  Bool，  Cond.Id，  Pref.Id，  Event Id  1  3  2  101--From(Bob)(来自鲍伯)  1  4  2  101--Contains(IA)(包含IA)

在首选项2的这两个条件之间有一个(OR或)。因而，这个首选项只有在这两个条件中任一个为真时才评估为真。这些条件分别属于第2和第3个ANDGroup，并且它们的条件计数都是1。因此，当上面的表与AndGroupMembership(与分组成员资格)表时，得到下面的表：

  Bool，  Cond.Id.  Pref.Id，  Event Id，  AndGroupId  11  34  22  101101  23

在上面的表被分组后得到，

 sum(Bool)，  Pref.Id，  Event Id， AndGroupId 11  22  101101 23

上面的两行都满足having子句并且因此在应用程序不同的之后，我们发现首选项(Pref.Id＝2，Event Id＝101)将被拷贝到结果表703)。

例3：

对于这个最后的例子，假定ConditionResults(条件结果)表具有下面的两个行：

  Bool，  Cond.Id，  Pref.Id，  Event Id  11  1314  77  102--From(Bob)(来自鲍伯)102--Contains(Work)(包含工作)

回想在首选项7上的条件实际上是

From(Bob)and！Contains(Work)。

按照本发明一个方面，在存在NOT时，在上面第二行中的1变成-1。下面是提供这样的功能的示例性查询：

update CondtionResults

set Bool＝-1

where cond.Id IN(select cond Id

from Not)

而且，应当注意，如果使用聪明的查询优化器并且通知NOT表为空，则查询应当立刻返回。因此，上述表变成：

  Bool，  Cond.Id，  Pref.Id，  Event Id  1-1  1314  77  102--From(Bob)(来自鲍伯)102--！Contains(Work)(不包含工作)

合计＝0

这些条件都属于第11个ANDGroup(与分组)。从这个ANDGroup(与分组)表，它可以确定这个首选项(首选项，ANDGroup(与分组))的条件计数是1。由于0≠1，因此从这个首选项评估查询没有行得到。然而，注意，如果第二行不在ConditionResults(条件结果)表中，则将得到合计为1(＝1)且首选项7被评估为真。

在填充结果表730之后，可以执行首选项动作。动作可以由信息代理系统100或者由信息代理应用程序通过从系统100检索首选项结果并且对它们起作用来执行。如果动作由应用程序而不是信息代理系统100来执行，则可以使用事件提交应用程序或者某个其它应用程序从系统100检索动作。按照系统100，可以由系统100为可以检索和执行动作的应用程序动作处理程序提供主机服务。

优先级动作和上下文分析

下面的讨论涉及一种系统和方法，使与产生的动作诸如通知或消息相关联的多个信息，例如能够由优先权系统自动地排列优先顺序用于向用户或系统发送。而且，尽管为了说明简单的目的，本讨论集中在通知的优先级和上下文分析，但应当意识到，任何动作可以用相似的方式使用优先级和上下文分析。优先权系统可以使用分类器，它可以显式地和/或隐含地训练成按照向用户学得的重要性排列一个或多个收到的消息。如作为一个例子，通知可以通过一个训练实例集或者具有相似等级重要性的通知类型来分类成高、中、低或其它等级重要性。可以提供后台监控程序来监控用户的关于消息处理的活动，以进一步按照用户关于消息重要性的个人决策来改进或调整分类器。其它优先级分类可以包括关于与消息的延迟检阅或处理的时间相关的损失的确定。

在消息或其它通知已经被自动地排列优先顺序之后，用户可以检阅更重要的消息，而不必通过多个不太重要和/或不相关消息的排序。消息可以进一步按照重要性收集到一个或多个文件夹中，其中用户可以在希望的时间检阅相似分类的重要性的消息。其它系统诸如信息代理系统100(例如，通过通知组件180)可以将消息指向一个或多个通知接受器(例如，移动电话、手持式计算机)，基于确定的优先级。例如，如果一个电子邮件消息被确定为高重要性，则信息代理系统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可以配置为将电子邮件留在用户的收件箱中，在以后想看的时候检阅。如下面将更详细地描述的，其它路由和/或报警系统719可用于将优先化消息716指向用户和/或其它系统。

在下面描述的章节中，通过一个自动分类系统和过程描述为文本文件如电子邮件产生一个优先级。为所述文本产生优先级随后可以用于其它系统，如下面更详细描述的通知平台。在本章节中的描述结合图8和图9提供，前者是例示一个文本分类器的显式和隐式训练的图，后者是描绘如何由到文本分类器的输入产生一个文件的优先级的图。还结合图10和11提供描述，它们是不同模式的图，按照这些模式可以分类文本的优先级，并且结合图8和11，它们是例示依赖于文件类型可应用程序的代价函数的图。

现在参考图8，文本/数据分类器820可以显式地训练，如由箭头822表示，和隐式地训练，如由箭头824表示，以按照优先级执行分类。由箭头822表示的显式训练通常在构造分类器820的初始阶段进行，而由箭头824表示的隐式训练一般在分类器820已经构造之后进行--以更好地调整分类器820，例如，通过后台监控程序834。在此参考SVM分类器作出特定的描述，为了例示分类训练和实现方法的示例性目的。可以使用其它文本分类方法，包括Bayesian(贝叶斯定理)网络、决策树和提供不同独立性模式的概率分类模型。在此使用的文本分类还包括用于开发优先级模型的统计回归。

按照本发明一个方面，众所周知的支持向量机(SVM)用作分类器820。要意识到，其它分类器模型也可以使用，诸如Naive Bayes(单纯贝叶斯)、BayesNet(贝叶斯网)、决策树和其它学习模型。SVM通过分类器构造器和特征选择模块826内的学习和训练短语来配置。分类器是一个函数，将一个输入属性向量x＝(x1，x2，x3，x4，xn)映射为该输入属于一个类的置信度--即，f(x)＝confidence(class)。在文本分类的情况下，属性是词语或短语或从词语导出的其它域专用属性(例如，词法、关键词组的存在)，类是感兴趣的类别或范围(例如，优先级的级别)。

SVM的一个方面和其它归纳学习方法使用有标签的实例训练集来自动学习分类函数。在与分类器构造器826相关联的数据存储器830中描绘训练集。如所示的，训练集可包括分组G1至GN的一个子集，表示与一个特定类别相关联的可能和/或实际的元素或元素组合(例如，词语或短语)。数据存储器830还包括多个类别1至M，其中分组可以与一个或多个类别相关联。在学习期间，学习将输入特征映射为类的置信度函数。因而，在学习一个模型之后，类别表示为输入特征的有权重向量。

对于类别分类，二进制特征值(例如，在一个类别中一个词语出现或不出现)，或实值特征(例如，一个词语以重要性权重r出现)是经常使用的。由于类别收集包含大量唯一的专用名词，因此在将应用机器学习技术应用程序于分类时通常使用特征选择。为减少特征的数量，可根据整体频率计数移除特征，随后按照较少数量的特征根据对类别的适合选择特征。对类别的适合可通过相互信息、信息增益、x校验法和/或实质上任何统计选择技术来确定。这些较小的描述随后用作到SVM的输入。注意，线性SVM提供适当的一般准确性并且提供相当快的学习。非线性SVM的其它类包括多项式分类器和径向基础函数并且按照本发明也可使用。

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

SVM是一个参数化函数，在训练之前就定义了其函数的形式。训练SVM一般要求有标签的训练集，因为SVM将从一组实例来适配函数。训练集可以由一个N个实例的集合组成。每个实例包括一个输入向量xi，和一个类别标签yj，它描述输入向量是否在一个类别中。对于每个类别，在用N个实例训练的SVM中可以有N个自由参数。为找到这些参数，解决二次规划(QP)问题是众所周知的。存在多个众所周所的技术用于解决QP问题。这些技术包括顺序最小优化技术以及其它技术。如图9所示，已经变换成输入向量x的文本输入936应用程序于分类器920每个类别。分类器920使用由分类器构造器926确定的学到的权重w(每个类别的一个权重向量)并且形成点积以提供优先级输出938，其中可将概率P指派给输入文本936，表示一个或多个相关优先级(例如，高、中、低)。

回来参考图8，由箭头822表示的文件分类器820的训练包括在826中构造分类器，包括使用特征选择。在显式训练短语中，例如，可以给分类器820提供时间重要和非时间重要两者的文本，因此分类器也能够区别两者。这个训练集可由用户提供，或者可使用标准或默认训练集。给定一个训练文集，分类器820首先应用程序特征选择过程，它试图找出最有区别的特征。这个过程使用交互信息分析。特征选择可以在一个或多个词语或可供使用的更高级区别诸如用自然语言处理标记的短语或词法上操作。即，文本分类器820可以由特殊标记的文本来播种，以区别认为是重要的文本特征。

文本分类的特征选择一般在单个词语上进行搜索。除信任单个词语外，也可使域专用短语和高级特征模式可用。特殊的记号可以增强分类。用于电子邮件临界性的学到的分类器的质量，例如，可以通过将标识为用于区别不同时间临界性的电子邮件的手工特征输入到特征选择过程中来增强。因而，在特征选择期间，考虑用于区别不同级别时间临界性的消息的一个或多个词语以及短语和符号。

如下面的例子例示的，标识消息临界性的值的标记和/或模式包括这样的区别诸如下面的布尔组合，并且包括它们：

消息头部中的信息

例如：TO(收件人)：字段(接收者信息)

只寻址于用户，

寻址于包括用户在内的一些人，

寻址于少数人的别名，

寻址于少数人的若干别名，

Cc(抄送)：到用户，

Bcc(密送)：到用户。

FROM(发件人)：字段(发送者信息)

在预定的重要人物列表上的名字，可能被分段成各种个别人的类，(例如，家庭成员，朋友)

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

相对于从一个在线组织图提取的用户关于组织关系结构的信息，诸如：

用户向其报告的管理者，

用户的管理者的管理者，

向用户报告的人，

外部业务人。

过去时信息

这些包括关于已经发生的事件的描述，诸如：

我们见面了，

会议过去了，

发生了，

聚会了，

照顾了，

昨天的会议。

将来时信息

明天，

这个星期，

你是否打算，

什么时候我们可以，

期望，

这将，

将是。

会议和协调信息

聚会，

你是否能会面，

将聚会，

协调，

需要聚会，

见你，

安排一个会议，

想邀请，

来访。

决定的日期

将来对过去的日期和时间，由文本的模式表示，显式地陈述日期和时间或者典型的缩写词，诸如：

在5/2，

在12:00。

问题

毗邻于问号(？)的词语，词组

表示人的请求：

你是否能，

你是否是，

你是否将，

请你，

你是否能做，

请问，

由你。

表示需要：

我需要，

他需要，

她需要，

我想要，

它会伟大，

我想要，

他想要，

她想要，

照顾。

时间临界性

不久发生，

立即，

最终期限将是，

最终期限是，

尽可能快，

立即需要，

立即要做，

立即完成，

在[日期]前，

在[时间]前。

重要性

是重要的，

是关键的，

单词，短语+！，

显式优先级标志状态(低，无，高)。

消息的长度

组成新消息的字节数。

商业或成人内容垃圾电子邮件的符号

免费！！

词语+！！！

小于18岁，

仅限成人，

大写词语的百分比，

非字母数字字符的百分比。

注意，上述单词和短语分组例示了示例性单词、分组或短语，它们可用于进行分类器训练。要意识到，其它相似的语语、分组或短语可相似地使用并且因而本发明不限于所例示的例子。

而且，仍参考图8，分类器820的隐式训练，如由箭头824表示的，可以通过由后台监控程序824监控用户工作或使用模式来进行，例如，后台监控程序824可以驻留在用户的桌面或移动计算机中。例如，在用户工作时，以及检阅邮件列表时，可以假定先读时间临界的消息，稍后检阅和/或删除较低优先级的消息。即，当提供新的电子邮件时，监控用户以确定他或她是否立即打开电子邮件，并且以什么顺序，在不打开的情况下删除电子邮件，和/或在相对短的时间内答复电子邮件。因而，调整分类器820，使得用户在工作或操作系统时监控用户，周期性地通过在后台训练来改进分类器并且更新分类器以增强实时决策制定。用于建立分类器的后台技术可以从用新训练消息更新分类器820的那些来扩展。

可供替换地，可以收集较大数量的消息，其中在一个批处理过程中创建新的过滤器，或者按照每日调度，或者按照训练集承认的消息的新数量的数字，和/或组合。对于每个输入分类器的消息，例如，可以创建分类器的一个新案例。例如，这些案例存储为文本的否定或主动实例，它们是高或低优先级。如一个例子，可以识别一个或多个低、中和高紧急类，使得在这些类的每一个中的成员资格的概率用于建立预期的临界性。可以使用较大数量临界性类来寻求较高的分辨率。例如，如图9所示，消息的训练集940(例如，非常高、高、中、正常、低、非常低等)最初可以用于训练分类器942，使得实时分类完成，如在944表示的，其中新消息按照由训练集940分析的实例数量来分类。在图9中，为了示例性目的例示了三个这样的类别，然而，要意识到，可按照所希望的重要性变化等级训练多个这样的类别。如所例示的，新消息944可被加标签、加标记和/或分类到一个或多个文件夹946中，例如，按照由分类器942指派的优先级。如下面将更详细地描述的，指派的优先级还可由后续的系统用于对/为用户作出消息格式、交付和形式决定。

按照本发明另一个方面，可以通过监控用户与电子邮件的交互，例如，而不是将案例或消息加标签为一组文件夹之一，来完成一个数字或值的估计。因而，分类器可以继续被更新但具有一个移动的窗口，其中考虑在某个时间之后的消息或文档的案例，如由用户指定的。

例如，一个与消息的延迟检阅相关联的常数损失率称为消息的预期临界性(EC)，其中，

$$ >>EC>=>>\Sigma >i>>>C>d>>>(>>H>i>>)>>p>>(>>H>i>>|>>E>d>>)>>>$$

其中C是代价函数，d是延迟，E是事件，H是电子邮件的临界性类，而EC表示为由用于可能的类的代价函数C描述的损失率加权的类的可能性之和。

作为一个例子，仍参考图9，诸如电子邮件消息的文本936输入到分类器920，它根据该输入为文本936产生优先级938。即，分类器920产生优先级938，例如按照从0至100％的百从比测量。这个百分比可以是文本936是高或某种其它优先级的可能性的量度，基于分类器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中，随着时间增加，没有检阅过文本的代价也增加。然而，与由直线1258表示的中优先级消息或者由直线1260表示的低优先级相比，由直线1256表示的高优先级消息代价增加得更多。例如，高优先级直线1256具有斜度为100，中优先级直线1258具有斜度为10，而低优先级直线1260具有斜度为一。这些斜度值随后可以由分类器1020、1120在给一个给定的文本指派优先级中使用，例如通过回归分析。

然而，有些消息它们不具有由线性代价函数的使用良好近似的优先级。例如，与一个会议有关的消息其代价函数随着会议的时间接近而增加，并且之后，代价函数快速减少。即，在错过会议之后，用户一般对于它就没有什么可做的了。这个情况由非线性代价函数更好地近似，如图13所示。在图1362中，代价函数1364快速地增加，直到它到达由直线1366划分界线的会议时间，之后它快速地减少。取决于消息的类型，代价函数可以由许多不同的线性和非线性表示代价函数之一来近似。

因而，如已经描述的，文本的优先级可以只是它是多个优先级之一的可能性，基于分类器的输出，或者是该文本最有可能应用程序于的优先级类，同样基于分类器的输出。可供替换地，文本的预期时间临界性如电子邮件消息可以被确定。这可以写成：

$$ >>EL>=over>>\Sigma >i>nover>>p>>(>>critical>i>>)>>C>>(>>critical>i>>)>>>$$

其中EL是预期损失，p(criticali)是一个文本具有临界性i、C(criticali)是具有临界性i的文本的代价函数，并且n是临界性类的总数减一。在函数是线性的情况下，代价函数定义一个关于时间的常数损失率。对于非线性函数，损失率随着延迟的检阅或者文本的处理改变并且可以增加或减少，取决于延迟量。

在n＝1的情况下，指定只存在两个优先级类低和高，预期的损失可以再表示成：

EC＝p(criticalhigh)C(criticalhigh)+[1-p(criticallow)]C(criticallow)

其中EC是文本的预期临界性。而且，如果将低临界性消息的代价函数设置为零，则这变成：

EC＝p(criticalhigh)C(criticalhigh)

直到一个文本的检阅的时间为止的总损失可以表示为所表示的临界性的积分，即，

EL＝∫₀p(critical_high)C(critical_high，t)dt

其中t是在检阅文档之前的时间延迟。

符合用于分类文档如按照重要分类电子邮件消息的值度量的其它量度。尽管上面的讨论集中于按照时间临界性的优先级，但也可以训练其它“重要性”的概念。例如，这可以通过给一组训练文件夹加标签来完成：“高重要性”一直到“低重要性”，其中可以确定“预期重要性”的量度。另一个度量可以基于语义标签，“我希望在旅行中在1天内听到消息”，并且确定一个量度，用于按优先级排列要转送给旅行中的用户的消息。而且，一个可使用的度量是紧急性或时间临界性，因为它具有清楚语义用于决策制定、筛余和路由。在这种情况下，按照不同级别的紧急性给类加标签并且根据推断的消息在每个类中的概率计算每个消息的预期紧急性。

对临界性分类的扩展，如在前面的章节中描述的，也可以按照本发明提供。例如，分类可以包括自动搜索在特征类内或特征类之间的高支付(high-payoff)特征的组合。如一个例子，在分类过程中可以搜索和使用的特殊区别、结构等的组合，带有已经找到的对于某些用户特别有用的词语。两个特征的组合称为二元组(doublet)，然而三个特征的组合称为三元组(triplet)，等等。特征的组合可以允许改进的分类。

分类也可以通过使用递增的索引(它在分类器中使用移动窗口)来改进。这使分类器能够被例行公事地刷新，如旧数据超时，并引进新数据。

分类也可以基于在消息中指定事件的日期和时间的确定。这个确定可以向消息指派可以由分类器使用的特征。例如，指派的特征可包括：今天在四小时内，今天在八小时内，明天，这个星期，这个月，和下个月及以后。这使分类器能够具有改进的准确性，相对于被分类的消息。通常，分类可以基于被引用事件的时间，考虑事件在将来还是已经过去了。关于将来的事件，分类因而考虑发送者对在将来事件发生的时间的引用。

其它新特征可以结合到分类过程中。例如，可以使用组织图来按照发送者在图中的位置确定消息的重要性。语言特征可以结合到分类器中。为适应不同的语言，可根据发送者的来历和/或编写消息的语言来修改特征。分类可根据存储消息的不同文件夹以及其它定标(scaling)和控制规则变化。除电子邮件和其它源之外，分类可以在即时消息以及其它信息源如证券报价机等上执行。

通常，可在分类过程中考虑发送者-接收者结构关系。例如，如果用户实质上是消息的唯一接收者，则这个消息可看作是比发送给少数人的消息更重要。接着，发送给少数人的消息比发送用户是隐蔽拷贝(密送)的或者复制拷贝(抄送)的消息更重要。关于发送者，可基于发送者的名字是否认识来指派临界性。临界性也可根据发送者对于用户相关联的组织是内部的还是外部的来指派。

在分类中可考虑的其它区别包括消息的长度，问题是否检测到过，以及用户的名字是否在消息中。与时间临界性相关联的语言可增加消息的重要性。例如，短语如“很快发生”、“立即”、“尽可能快”、“尽快”和“最后时限是”可表示消息更紧急。可考虑过去时与将来时相比较的使用，并可考虑由短语如“聚会”、“我们是否能会面”等指定的协调任务。垃圾邮件的证据可降低消息的优先级。谓词表示的组合，如来自一个接近用户在组织图中位置的发送者的短问题，也可在分类过程中考虑。

在下一个章节中，描述提供一个何时向用户报警高优先级文本的决定的过程，例如，一个具有为高优先级的可能性大于用户设置的阈限或者大于由决策理论推理确定的阈限的文本。即，除了知道时间临界性消息之外，决定何时向用户报警时间临界性消息也很重要，例如如果用户不是直接观看进入的电子邮件。通常，确定将用户从当前正在解决的任务转移到了解时间临界性消息的代价。

可供替换地，可以使用各种策略用于报警和通知。例如，这些策略可以在通知平台体系结构内实现，下面更详细地描述。这些策略的一些包括：

·在总损失上设置用户指定的上边界。这个策略指定一个系统应当在与一个消息的延迟检阅相关联的总损失超过某个预先指定的“可容忍”的损失“x”时产生警报。

·另一个策略可以是代价-利益分析，基于更完整的决策理论分析，如NEVA＝EVTA-ECA-TC，其中NEVA是报警的净预期值，EVTA是报警的预期值，ECA是报警的预期代价，以及TC是与发送一个消息相关的传输代价。

通常，用户应当在代价-利益分析建议用户因没有在时间t检阅会招致的预期损失大于向用户报警的预期代价时被报警。即，报警应当进行，如果：

EL-EC＞0

其中EL是在当前时间t不检阅文本的预期损失，以及EC是在当前时间t向用户报警文本的预期代价。预期的损失如前面的描述章节所述。

然而，上面的公式可能不是最准确的，因为用户常常在将来主动地检阅消息。因此，实际上，通常应当在称为EVTA的报警预期值为正时就向用户报警。报警预期值因而应当考虑现在向用户报警文本的价值，与用户在以后主动检阅消息的价值相反，减去报警的代价。这可以陈述为：

EVA＝ELalert-ELno-alert-EC

其中，ELalert是如果用户现在要检阅消息时，在被报警时，用户检阅消息的预期损失，与ELno-alert相反，它是用户在某个点主动检阅消息的预期损失，在没有被报警的情况下，基于转移的考虑和基于发送信息的直接代价的报警的预期代价。

而且，来自几个消息的信息可以被分组到一个单一的混合警报。在一个警报中关于多个消息的检阅信息可以比一个中继关于单个消息的信息的警报代价更大。在转移注意力方面这样的增加可以通过使警报的代价成为它信息复杂性的函数来表示。可以假定一个电子邮件消息的EVA独立于其它电子消息的EVA。例如，EVA(Mi，t)，指在时间t向用户报警一个单个消息Mi的价值，以及ECA(n)指中继n个消息的内容的预期成本。因而，可以通过将中继关于一组n个消息的信息的预期值合计起来考虑多个消息，其中：

$$ >>MEVA>=>>\Sigma >>i>=>1>>>EVA>>(>>M>i>>,>t>)>>->ECA>>(>n>)>>>$$

也要注意，为了确定报警的预期代价，推理或直接访问关于用户是在还是不在的信息是有用的。可以使用传感器来表示用户何时在办公室时，诸如红外传感器和压力传感器。然而，如果这类设备不存在，可以按照用户在计算机上的活动的函数来指派一个用户在办公室时的概率，例如，诸如自从最后一次观察到鼠标或键盘活动起的时间。而且，在日程表中的调度信息也可以用于进行关于用户的距离和安排的推理并且用于考虑通过不同的过程转送消息给用户的代价。

在进行用关于具有高时间临界性的消息的信息打扰用户的决策时，知道用户有多忙也是重要的。可以推理(例如，推理决策制定)用户是否在计算机上工作和以什么速度工作，或者用户是在电话上与某人讲话，或者在另一个地方开会。若干证据类可以用于评估用户的活动或者他或她的注意力焦点，如图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，在一个新当前时间t。回到1986可被执行，因为随着时间前进，预期损失可在某个点超过报警代价，使得在1990的计算会改变。在预期损失超过报警代价时，则在1994执行向用户或其它系统的报警。

现在描述向用户或其它系统报警的输出。可以在电子设备上向用户报警，基于报警准则，它表示何时应当向用户报警一个优先化文本。用于向用户报警的电子设备可以是寻呼机、蜂窝式/数字移动电话，或其它通信方式，如下面更详细描述的。在电子设备如寻呼机或移动电话上向用户的报警，可以基于报警准则，例如，该准则可以被调整为对用户的位置、推理的任务和/或注意力焦点的信息敏感。这样的信息可以在不确定的情况下推理出来，或者可以从在线信息源被访问。例如，来自一个在线日程表的信息，可以适合于控制用于作出关于中继信息至设备(诸如下面更详细描述的通知接收器)的决策的准则。

报警可以通过基于路由准则路由优先化文本或其它数据来执行。文本的路由可以包括转送文本，和/或向发送者答复文本，在文本是电子邮件的情况下。例如，可以播放一个声音来向用户报警一个优先化文档。可供替换地，可以打开代理或自动助理(例如，交互显示向导)。即，代理可以出现在显示屏幕上，来向用户通知优先化文档。而且，可以打开优先化文档，诸如在屏幕上显示。该文档可以接收焦点。这也可以包括基于文档的优先级改变文档的尺寸，使得文档的优先级越高，显示它的窗口越大，和/或基于它的优先级将文档定位在显示的中央。

现在参考图20，这是按照本发明一个方面的文本产生和优先权系统2000的图。系统2000包括程序2002和分类器2004。注意，程序2002和分类器2004可以包括由计算机的处理器从其计算机可读介质执行的计算机程序。

程序2002产生用于到分类器2004的输入的文本。程序包括一个接收电子邮件的电子邮件程序，电子邮件随后用作文本。分类器2004为相关联的消息产生优先级。如上所述，分类器2004可以是贝叶斯定理分类器，支持向量机分类器，或者其它类型的分类器。由分类器2004输出的文本优先级随后可以结合代价-利益分析使用，如已经描述的，来实现进一步的输出和/或基于其的报警。

现在转到图21，按照本发明的一个方面，系统2100例示首选项执行引擎和上下文分析程序如何一起起作用。系统2100包括上下文分析程序2122、首选项执行引擎2124、一个或多个事件或通知源1至N，2126，2127，2128，优先权系统2130，以及一个或多个动作或通知接收器1至M，2136，2137，2138，其中N和M分别是整数。按照本发明的一个方面，源也可以称为事件发布者，而接收器也可以称为事件订户。可以有任意数量的接收器和源。通常，执行引擎2124传送通知，通知也称为事件或报警，从源2126-2128至接收器2136-2138，部分基于存储在上下文分析程序2122中和/或由它访问的参数信息。

上下文分析程序2122存储/分析关于用户的变量和参数的信息，它影响通知决策制定。例如，参数可包括上下文相关信息，如用户的典型位置和注意力焦点或者一天每个时间和一周每天的活动，以及以这类参数为条件的附加参数，如用户在不同位置倾向于访问的设备。这类参数也可以是通过一个或多个传感器匿名地产生的观察资料的函数。例如，基于关于用户位置的信息(如可以由全球定位系统(GPS)子系统提供的)，基于有关正在使用的设备类型和/或设备使用的模式以及由访问一个特定类型的设备的最后时间，选择或修改一个或多个概况(未示出)。而且，如下面更详细地描述的，也可使用自动推理，以动态地推理出参数或状态，如位置和注意力。概况参数可存储为可由用户编辑的用户概况。除依赖于预定义的概况的设置或动态推理之外，通知体系结构可以使用户能够实时指定他或她的状态，如用户在接下去的几个小时里不在，除非是重要的通知，或者直到一个给定时间，例如。

参数也可以包括默认的通知首选项参数，关于用户在不同设置中被不同类型的通知打扰的首选项，可以用作由执行引擎2124作出通知决策的基础，并且基于此用户可以开始改变。参数可包括默认的参数，关于用户希望在不同的情况下如何被通知(例如，诸如用蜂窝电话，用寻呼机)。参数可以包括这样的评估，如与在不同设置中由不同方式通知相关联的中断的代价。这可以包括表示用户在不同位置的可能性、不同设备可用的可能性、在给定时间他或她的注意力状态的可能性的上下文相关参数，以及表示用户希望在给定时间如何被通知的通知参数。

按照本发明的一个方面，由上下文分析程序2122存储的信息，包括由分析程序确定的上下文相关信息。上下文相关信息是由分析程序2122通过基于一个或多个上下文相关信息源(未示出)识别用户的位置和注意力状态来确定的，如在后面的描述章节中更详细地描述的。上下文分析程序2122，例如，能够通过全球定位系统(GPS)(它是用户的汽车或蜂窝电话的部件以一定的精度确定用户的实际位置。分析程序也可使用一个统计模型来确定用户在一个给定的注意力状态中的可能性，通过考虑后台评估和/或通过考虑诸如日子的类型、时刻、在用户日程表中的数据和关于用户活动的观察资料之类的信息而收集的观察资料。给定的注意力状态可以包括用户是否开放接收通知、忙或不开放接收通知，并且可以包括其它考虑事项如工作日、周末、假期和/或其它时机/时段。

源2126-2128，2130产生目标为用户和/或其它实体的通知。例如，源2126-2128可包括通信，如因特网和基于网络的通信，电话通信，以及软件服务。通知源在此通知定义为产生事件的源，也可以称为通知和报警，目的是向用户或者用户的代理报警，关于信息、服务和/或系统或世界事件。通知源也称为事件源。

例如，可由优先权系统2130产生电子邮件作为通知，使得它被优先化，其中产生通知的应用程序程序或系统为电子邮件指派一个相应于电子邮件对于用户的可能的重要性或紧急性的相对优先级。也可在与对于用户的相对重要性无关的情况下发送电子邮件。因特网相关的服务可以包括通知，它们包括用户已经订阅的信息，例如，诸如经常是当前新闻的大字标题和股票价格。

通知或事件源2126-2128可以是推型或拉型源。推型源是那些自动产生和发送信息的源，没有相应的请求，如大字标题新闻和其它因特网相关的服务，它们在被订阅后自动地发送信息。拉型源是那些响应于请求发送信息的源，如在查询邮件服务器之后接收的电子邮件。还有其它的通知源，包括下列：

·电子邮件桌面应用程序如日程表系统；

·计算机系统(例如，可用消息向用户报警关于有关系统活动或问题的报警的信息的计算机系统)；

·因特网相关的服务，约会信息，调度查询；

·在文档中或在一个或多个共享文件夹中某种文档的数量的改变；

·响应于对信息的常设或持久的查询，新文档的可用性；

·用于有关人及其存在的信息源，他们在位置上的改变，它们所接近的(例如，在我正旅行时，如果另一个同事或朋友在我的10英里之内，则让我知道)，或者他们所能够做的(例如，让我知道何时斯蒂芬可以交谈并且靠近一个可以支持全视频电话会议的高速链路)。

通知动作接收器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可以配置为一个驻留在事件或消息基础结构之上的层。然而，本发明不限于任何特定的事件基础结构。这样的事件和消息系统和协议可以包括：

·超文本传输协议(HTTP)，或者在本领域内已知的HTTP扩展；

·简单对象访问协议(SOAP)，如在本领域内已知的；

·窗口管理工具，如在本领域内已知的；

·Jini，如在本领域内已知的；以及

·实质上任何类型的通信协议，例如，诸如那些基于数据包交换协议的通信协议。

而且，该体系结构可以配置为一个驻留在灵活的分布式计算基础结构之上的层，如本领域普通技术人员可以意识到的。因而，例如，通知平台体系结构2100可以使用底下的基础结构作为源发送通知的方式，以及作为接收器接收通知、报警和事件的方式。然而，不要这样限制本发明。

现在参考图22，这里在系统2200中更详细地描绘了在前面的描述章节中描述的信息代理系统体系结构的上下文分析程序2122。如图22例示的上下文分析程序2222包括用户通知首选项存储器2240，用户上下文模块2260，它包括用户上下文概况存储器2262和白板2264。按照本发明一个方面的上下文分析程序2222可以实现为一个或多个可由计算机的处理器从其机器可读介质(包括但不限于存储器)执行的计算机程序。

首选项存储器2262存储用户的通知参数，如用户的默认通知首选项，例如可以由用户编辑和修改的用户概况。首选项存储器2262可以看作是存储关于影响如何通知用户的参数的信息的存储器。如在此已经描述的，首选项可以由用户使用系统化逻辑来指定，例如，用如果-那么(IF-THEN)格式。用户上下文模块2260确定用户的当前上下文，例如，基于一个或多个上下文信息源2280，如向白板2264发布的。用户上下文概况存储器2262存储用户的上下文参数，如用户的默认设置，可以由用户编辑和修改。即，用户上下文模块2260提供有关用户当前上下文信息的最佳推测或估计，通过访问来自概况存储器2262的信息和/或用实际的感觉更新在存储器2262中的一组先前的信条，经由一个或多个上下文源2280。概况存储器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的通知，它确定何时通知应当发生，并且如果要发生，确定哪些通知应当传送到哪些通知接收器2336-2328，以及以什么顺序。

依照本发明的一个方面，通知源2326-2328可以具有一个或多个下列在属性和关系的标准描述中的参数，在此称为通知源模式或源模式。注意，可以为上面描述的源、接收器和上下文信息源提供模式。这类模式提供有关不同组件的声明性信息并且可以使源2326-2328、通知引擎2324、接收器2336-2338和上下文分析程序2322能够彼此共享语义信息。因而，不同的模式提供有关与通知相关联的性质、紧急性和设备信令形式的信息。即，模式通常可以定义为类和类之中的关系的集合，它们定义通知和事件的结构，包含例如包括事件或通知类、源、目标、事件或通知语义、本体论(ontological)内容信息、观察资料可靠性和实质上任何服务质量属性的信息。

用于通知源模式的参数(未示出)可以包括下列的一个或多个：消息类；关联性；重要性；时间临界性；新颖性；内容属性；保真度权衡，和/或源信息概要信息。用于由通知源产生的通知的消息类例如表示通知的通信类型，如电子邮件、即时消息、数字财务更新和桌面服务。用于由通知源产生的通知的关联性表示包含在通知内的信息与一个或多个指定的上下文相关的可能性。例如，关联性可以由一个逻辑标志来提供，表示源是否与一个给定的上下文相关。通知的新颖性表示用户已经知道包含在通知内的信息的可能性。即，新颖性是信息对于用户是否为新的，随着时间过去(表示用户现在是否知道该信息，并且将来何时用户在没有向用户报警该信息的情况下会了解该信息(如果发生的话))。

与通知相关联的保真度权衡表示可以通过不同形式指定的且允许的例如切断和/或概括所导致的在通知内的信息的价值损失。要求对要传送到某些类型的通知接收器2336-2338进行这样的切断和/或概括，因为它们具有带宽和/或其它限制，使它们不能接收原来产生的完整通知。保真度通常指与通知相关联的原始内容的完整性的性质和/或等级。例如，可切断一个长电子邮件，或者将它概括成蜂窝电话所允许的最多100个字符，招致保真度损失。同样，在通过仅具有文本能力的设备传输时，包含文本和图形内容的原始消息遭受保真度方面的损失。另外，设备可能只能够描绘从源可得到完整分辨率的一部分。保真度权衡指按照顺序(例如，按照图形在先，随后声音的顺序呈现重要性)和/或表示通知的内容的总价值如何随着保真度方面的改变而消失的代价函数陈述的一个源的一组保真度首选项。例如，保真度权衡可以描述与一个完整的电子邮件消息的传输相关联的全部价值如何随着递增加大的切断量变化。内容属性，例如，可以包括内容性质的摘要，表示诸如核心消息是否包括文本、图形和音频组件之类的信息。内容本身是构成通知的消息内容的实际图形、文本和/或音频。

通知的重要性指包含在通知的信息对于用户的价值，假定信息与一个当前上下文相关。例如，重要性可以表示为信息对于用户的价值的美元值。时间临界性表示在包含在通知中的价值时间相关地变化--即，信息的价值如何随着时间过去而改变。在大多数但不是全部情况中，通知的信息价值随时间衰减。这在图24的图中例示。图2400描绘一个被映射的通知随着时间过去的实用性。在图内的点2402处，代表开始时间，表示通知的重要性，而曲线2404表示实用性随着时间过去而衰减。

回到图23，使用于不同通知源的默认属性和模式模板可用于存储在用户通知首选项存储器如图22的存储器2240中的通知源概况。这样的默认模板可以用于覆盖由通知源提供的值或者用于在它们未得到由源提供的模式时提供属性。源摘要信息使源能够发送可从源得到的信息状态和可能的通知的一般摘要。例如，来自一个消息源的源摘要信息可包括有关至少是某个优先级的未读消息总数、由人们试图与用户通信的状态和/或其它摘要信息的信息。

通知接收器2336-2338实质上可以是能向用户或其它实体通知包含在通知中的信息的任何设备或应用程序。关于哪个(些)接收器的选择是要用于传送一个由通知引擎2324确定的特定通知。

通知接收器2326-2338具有一个或多个在一个模式中提供的下列参数。例如，这些参数可包括一个设备类；信令(报警)的方式；以及，对于相关联的方式，保真度/呈现能力，传输可靠性，通信的实际代价，和/或中断的注意力代价。对于适合于对报警属性的参数化控制的设备，用于这些设备的模式可以另外包括用于控制属性的报警属性和参数的描述，以及其它属性(例如，传输可靠性、分发代价)在不同的报警属性设置的情况下按其变化的函数。通知接收器的模式提供通知设备向通知执行引擎2324和系统的其它组件传送有关其性质和能力的语义信息所用的方式。可以使用于不同设备类型的默认属性和模式模板可用于存储在用户通知首选项存储器如图22的存储器2240中的设备概况，如在前面的章节中描述的。这类默认模板可以用于覆盖由设备提供的值或者用于在它们未得到由这类设备提供的模式时提供属性。

现在依次描述每个模式参数。设备的类指设备的类型，例如，诸如蜂窝电话、台式计算机和膝上型计算机。类也可以是更一般的，诸如移动或文具设备。信令的方式指一个给定的设备可以向用户报警一个通知的方式。设备可具有一个或多个通知方式。例如，蜂窝电话可只振动，可只以某个音量响铃，和/或可以既振动又响铃。而且，用于一个报警系统的桌面显示可以分解成若干离散方式(例如，在显示的右上侧的小通知窗口对在屏幕上面的小缩略图--伴有或不伴有音频通报)。除不限于一组预定义的行为之外，设备可以支持带有报警属性的方式，它们是作为设备定义的一部分的参数。用于一种方式的这类连续的报警参数代表这样的控制，例如，诸如在桌面播放警报的音量，在蜂窝电话上的响铃，以及报警窗口的尺寸。

通知接收器2336-2338的一种方式的传输可靠性表示用户将接收到所传送的关于通知的警报的可能性，它是通过接收器以该方式传送到用户的。如传输可靠性取决于设备可用性和用户的上下文，设备的不同方式的传输可靠性可以以诸如用户的位置和注意力之类的上下文属性为条件。一个或多个唯一上下文状态的传输可靠性，由诸如唯一位置和唯一注意力状态之类的属性的叉积定义的，按这类属性的抽象创建的逻辑和来定义的(例如，对于离开家里的任何位置，以及在8am之后中午之前的任何时段)，也可以指定。例如，取决于用户当前所在位置，传输到蜂窝电话的信息不是总能到达用户，尤其是如果用户在具有间隙覆盖的区域中，或者用户在这个位置(例如家庭假日)中不想有蜂窝电话。上下文也可以影响传输可靠性，因为环境噪声和/或上下文的其它屏蔽或转移注意力属性。

通信的实际代价表示将信息传送到用户的实际代价，当被包含在被传送到接收器的通知中的时候。例如，这个代价可以包括与蜂窝电话传输相关联的费用。中断的代价包括关联于与由一个设备的特定方式在一个特定的上下文中使用的警报相关的中断的注意力代价。注意力代价一般对于用户的注意力的特定焦点是敏感的。保真度/呈现能力是一个设备的文本、图形描述和/或音频/触觉的能力，也是在给定的方式下。例如，蜂窝电话的文本限制可以是任何单个消息100个字符，以及电话可能没有图形能力。

现有转到图25，一个示例性界面2500例示可由用户选择的上下文描述，可以由上下文分析程序用于确定用户的当前上下文。描述按照用户的直接描述的用户上下文确定，和/或用户可修改的概况。用户的上下文可以包括用户的注意力焦点--即，用户当前是否有责任接收通知警报--以及用户的当前位置。然而本发明不受此限制。

用户对上下文的直接描述使用户能够表示他或她是否能接收警报，并且用户希望在何处接收它们。默认的概况(未示出)可以用于表示默认的注意力状态，并且用户可以接收警报的默认位置。默认概况可以由用户按所希望的修改。

参考图25，按照本发明的一个方面，接口2500例示可以如何实现上下文的直接描述。窗口2502，例如，具有一个注意力焦点部分2520和一个位置部分2540。在焦点部分2520中，用户可以选取一个或多个复选框2522，例如，表示用户是否始终能接收警报；用户是否从不接收警报；以及，用户只能接收具有比一个预定阈限更高的重要性级别的警报。要意识到，可以提供其它可用性选择。如图25所示，阈限可以用美元测量，但这只是为了示例性目的，并且本发明不受此限制。用户可以增加方框2524中的阈限，通过直接输入新的值，或者通过用箭头2526增加或减少阈限。

在位置部分2540中，用户可以复选一个或多个复选框2542，以表示用户希望让警报在何处传送。例如，用户可以让警报在桌面、通过电子邮件、在膝上型计算机、在蜂窝电话上、在他或她的汽车中、在寻呼机上或者在个人数字助理(PDA)设备上等等传送。然而要意识到，这些只是例子，并且本发明本身不受此限制。

窗口2502，其中可以有部分2520的复选框2522和方框2524以及部分2540的复选框2542的预置默认值，可以看作一个默认用户概况。概况是用户可修改的，因为用户可以用他或她自己希望的选择覆盖默认的选择。按照本发明也可以使用其它类型的概况。

现在参考图26，按照本发明例示按照直接测量的用户上下文确定，例如，使用一个或多个传感器。用户的上下文可以包括用户的注意力焦点，以及他或她的当前位置。然而，本发明不受此限制。上下文的直接测量表示传感器可以用于检测用户当前是有责任接收警报，以及检测用户当前在何处。按照本发明的一个方面，结合直接测量的推理分析可以用于确定用户上下文，如在稍后的描述章节中描述的。

参考图26，例示系统2600，其中可以实现用户上下文的直接测量。系统2600包括一个上下文分析程序2602，和以通信方式耦合到它的许多传感器2604-2616，即，例如蜂窝电话2604、视频摄像机2606、话筒2608、键盘2610、PDA 2612、汽车2614和GPS 2616。图26所示的传感器2604-2616只是为了示例性目的，并且不表示对本发明本身的限制。在此使用的术语传感器是一个概括的和极大范围的术语，指上下文分析程序2602可以用于确定用户的当前注意力焦点是什么和/或用户的当前位置是什么的任何设备或方式。

例如，如果用户的蜂窝电话2604开着，这可以表示用户可以在蜂窝电话2604上接收警报。然而，如果用户当前正在蜂窝电话2604通话，这可以表示用户的注意力焦点在其它事物上(即，当前的蜂窝电话)，使得用户目前不应当被通知警报打扰。视频摄像机2606，例如，可以在用户的办公室，检测用户是否在他或她的办公室中(即用户的位置)，以及其他人是否在他或她的办公室中，暗示与他们的会见，使得用户不应当被打扰(即用户的焦点)。同样，话筒2608也可以在用户的办公室中，以检测用户是否正在与其他人谈话，使得用户不应当被打扰，检测用户是否正在打键盘(例如，通过从键盘发出的声音)，使得用户目前也不应当被打扰。键盘2610也可以用于确定用户当前是否正在打字，使得，例如，如果用户正在非常快地打字，则这可表示用户集中于计算机相关的活动，并且不应当被不适当地打扰(并且，也可以表示用户实际上在他或她的办公室里)。

如果PDA设备2612正由用户访问，则这可以表示用户能够在设备2612接收警报--即，应当传送通知的位置是设备2612被定位的地方。设备2612也可以用于确定用户的当前注意力焦点。汽车2612也可以用于确定用户当前是否在汽车中--即，如果汽车当前是由用户操作的。而且，可以考虑汽车的速度，例如，以确定用户的焦点是什么。如果速度大于一个预定的速度，例如，则可以确定用户集中于驾驶，并且不应当被通知警报烦扰。GPS设备2616也可以用于确定用户的当前位置，如在本领域内已知的。

在下面详细描述的章节中，描述按照用户可修改规则的用户上下文确定。用户的上下文可以包括用户的注意力焦点，以及他或她的当前位置。然而本发明不受此限制。通过规则确定上下文表示可以按照一个分层的如果-那么规则集合来确定用户的位置和/或注意力焦点。

参考图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，如果发现为真，引起规则2712的测试，如果发现为真则引起规则2714的测试。规则希望是用户可创建和可修改的。否则-类型的规则也可以包括在规则集2700中(例如，如果发现如果-那么规则为假，则由否则规则控制)。

因而，规则集可以由用户构造，使得用户的上下文被确定。例如，关于位置，规则集可以是这样的，即第一个规则测试当前日子是工作日。如果是，则作为第一个规则子例程的第二个规则是测试当前时间是在9a.m与5p.m.之间。如果是，则第二个规则表示用户在他或她的办公室里，否则用户在家里。如果发现第一个规则为假--当前日子是周末并且不是工作日--则一个否则规则可陈述用户在家里。注意，这个例子不是要关于本发明本身的限制性例子，其中可相似地配置一个或多个其它规则。

在下面的描述章节中，描述按照推理分析的用户上下文确定，诸如通过使用统计和/或贝叶斯定理模型。注意通过推理分析的上下文确定可以依赖其它决定的某些方面，诸如通过传感器的直接测量，如已经描述的。在此使用的推理分析指使用在多个输入变量上的推理处理过程，来输出一个输入变量，即，用户的当前上下文。在一个方面，分析可以包括统计模型和/或贝叶斯定理模型的使用。

参考图28，按照本发明的一个方面，例示系统2800的图，其中推理分析是由推理引擎2802执行以确定用户的上下文2804。在一个方面，引擎2802是由计算机的处理器从其计算机可读介质如存储器执行的计算机程序。用户上下文3804可以看作是引擎2802的输出变量。

引擎2802可以处理一个或多个输入变量以作出上下文决策。这类输入变量可以包括一个或多个传感器2808，如已经在前面的描述章节中结合上下文确定的的直接测量方法描述的传感器，以及当前时间和日子，例如，如由时钟2810表示和日程表2812表示的，如可在用户的调度或个人信息管理器(PIM)计算机程序中访问的，和/或在用户的PDA设备上。其它输入变量也可以看作是除图28所示之外的变量。图28的变量不是要对本发明本身进行限制。

现在参考图29和30，按照本发明一个方面，描述一个示例性推理模型，诸如通过能由上述推理模型执行的统计和/或贝叶斯模型提供的。通常，计算机系统可以是用户状态细节的某种程度的不确定。因而，可以构造概率模型，它可以在不确定性之下进行关于用户的注意力或其它状态的推理。贝叶斯定理模型可以推理在用户的注意力焦点上概率分布。这类注意力状态可以明确表示为一组原型情况或者一组由用户解决的不同类的认知问题的更抽象表示。可供替换地，模型可以明确表示为进行关于注意力焦点的连续测量的推理，和/或直接推理在不同类型通知的中断代价上的概率分布的模型。

可使用贝叶斯定理网络，它可以推理替换活动上下文或状态的概率，基于一组有关用户的活动和位置的观察资料。作为一个例子，图29显示一个贝叶斯定理网络2900，用于推理用户在一个单个时段的注意力焦点。变量的状态，注意力的焦点2920，指桌面和非桌面上下文。在模型中考虑的示例性注意力上下文包括例如情况意识、追赶、非特定的后台任务、聚焦的内容产生或检阅、轻内容产生或检阅、浏览文档、办公室里的会议、办公室外的会议、听取介绍、私人时间、家庭时间、个人焦点、偶然交谈和旅行。贝叶斯定理网络2900表示用户的当前注意力和位置受用户的预定约会2930、时刻2940和最终期限的临近2950的影响。例如，在用户注意力上的概率分布也受在用户办公室里监控的环境声音信号2960的状态总和的影响。环境声音信号2960的分段随着时间过去提供有关活动和交谈存在的线索/输入。软件应用程序的状态和配置和由用户与计算机交互产生的用户活动的输出流也是有关用户注意力证据的源。

如在网络2900中描绘的，软件应用程序当前在操作系统或其它环境中的顶级焦点2970影响用户的焦点和任务的性质，并且用户的注意力的状态和在焦点处的应用程序一起影响计算机为中心的活动。这样的活动包括在较宽的时间范围内从鼠标和键盘动作和应用程序使用的高级模式建立的用户活动的流。这类模式包括以电子邮件为中心和以词语-处理器为中心，并且指涉及交织多个应用程序的方法的活动的原型类。

图30例示在不同的时间段用户在上下文变量之中的注意力焦点的贝叶斯定理模型3000。一组马尔可夫(Markov)时间依赖性由模型3000例示，其中上下文变量的过去状态在用户当前状态的判定中考虑。实时地，例如，这样的贝叶斯定理模型3000考虑由在线日程表提供的信息，以及有关如由事件检测系统(未示出)报告的房间声音和用户活动的观察资料的流，并且继续提供有关用户注意力的概率分布的推理结果。

图31和32例示按照本发明用于提供通知体系结构的部分如上下文分析程序和通知引擎的方法。尽管，为了说明简单的目的，按照一系列行为显示和描述的这些方法，但要理解和意识到，本发明不受行为顺序的限制，因为按照本发明，有些行为可按不同的顺序和/或与在此所示和描述的其它行为同时发生。例如，本领域熟练技术人员将理解和意识到，一个方法能可供替换地表示为一系列相关的状态或事件，诸如在状态图中。而且，按照本发明，不是所有例示的行为被要求用于实现一个方法。

参考图31，流程图3100例示按照本发明确定用户的上下文。该过程包括在3102中确定用户的位置，并在3104中确定用户的焦点。这些行为可以由先前所述一个或多个方法完成。例如，可以使用一个概况；用户可以指定他或她的上下文；可以使用上下文的直接测量；可以遵循规则集；也可以进行推理分析，诸如通过贝叶斯定理或统计模型。要意识到，可以使用其它分析来确定用户的上下文。例如，可以有集成的视频摄像机源，它注意是否有人在计算机前或者他或她是否在看计算机。然而，注意，系统可以在有摄像机和没有摄像机的情况下运行。对于所有的源，系统实质上可以以任何可用的输入源运行，不要求任何特定的源来推理上下文。而且，在其它方面，可以在小的PDA上有集成的加速度计、话筒和接近检测器，它们给出用户的位置和注意力的检测值。

现在参考图32，按照本发明一个方面，流程图3200例示通知引擎的决策过程。在3202，一个或多个通知源产生通知，它由通知引擎接收。在3204，上下文分析程序产生/确定有关用户的上下文信息，在3206中由通知引擎接收。即，按照本发明的一个方面，在3204，上下文分析程序访问用户上下文相关信息概况，它表示用户的当前注意力状态和位置，和/或从一个或多个上下文相关信息源访问有关用户的当前注意力状态和位置实时信息，如已经在前面的描述章节中描述的。在3208，通知引擎确定哪些通知要传送到哪些通知接收器，部分基于从上下文分析程序接收的上下文相关信息。通知引擎也基于有关存储在上下文分析程序中的用户的通知参数的信息作出决定。即，按照一个方面，在3208，引擎执行有关对于一个给定的通知用户是否应当被报警和应当如何向用户报警的决策理论分析。如将在下面更详细地描述的，决策理论和/或启发式分析、判定和策略可在3208使用。有关用户的通知参数可以用于个性化分析，通过填充未得到的值或通过覆写在源或接收器的模式中提供的参数。通知首选项也可以提供代替决策理论分析使用的策略(例如，启发式)。基于这个判定，通知引擎在3210传送通知到分发程序。

数据驱动的应用程序安装

按照本发明另一个方面，信息代理应用程序的安装可以通过更新预定义表来完成。常规的通知系统以及其它应用程序一般涉及在安装它们时的数据库对象激增。每个应用程序按照惯例已经不得不在安装过程中存储过程以及大量表和数据。然而本发明采取不同的方法。首先，当系统或平台诸如信息代理系统100在安装时，可以产生一个基本表集合。因此，应用程序安装只涉及将数据插入预先存在的表中。这个方法消除了数据库对象随着已安装应用程序的增加而激增并且支持可扩展性(下面讨论)。

为完成上述内容，事件、首选项和过程，全部可以存储数据。这使系统能够利用不断增加的数据库引擎的处理能力和执行大量应用程序诸如信息代理应用程序300(图3)的查询。如上所述，首选项可以由最终用户定义并且随后提取到表和数据库的高级数据字段。事件可以捕捉或检索并且随后被存储在数据库中。常规存储过程诸如查询评估过程也可以表示为数据，通过创建过程和滚动数据到一个或多个数据库表中。之后，当过程被执行时，表示过程的文本串可以从数据库表中拉出并且在数据库表中动态地评估。这个方法显著地减少应用程序需要创建的存储过程的数量，并且使应用程序安装仅仅成为一个DML(数据操纵语言)数据驱动操作。

可组成性和可扩展性

本章节描述信息代理应用程序在初始创建时如何组成以及它们以后可以如何扩展。信息代理应用程序(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可调用函数/存储过程的定义的形式特征来使用。在一个新的条件或动作函数被定义时与该函数通过一个相应条件或动作的声明被绑定到一个现有的应用程序中时之间，该函数被认为是一个候选函数。在3320，候选函数的开发者指定绑定，它们将允许一个作为目标的要被扩展的应用程序从称为候选条件或动作的函数创建一个条件或一个动作。在这个阶段，条件或动作是供现有的要扩展的应用程序使用，使得应用程序可以使用条件或动作但不要求接受它们。在要扩展的应用程序中的接受逻辑确定这样的绑定是否被接受，例如基于谁监署了所提议的扩展/绑定的人。一旦一个应用程序绑定它的首选项类到一个条件或逻辑函数，在3330，候选条件或动作就简单地变成条件或动作。最后，当最终用户使用在新定义的首选项内的条件或动作，该动作或条件被称为实例化，如在3340的链中所示。

图34例示按照本发明一个方面的用于应用程序交互的系统3400。系统3400包括一个实例注册表组件3410，定义注册表3412，绑定注册表3414，应用程序A 3420，应用程序B 3430，和扩展组件3440。在可扩展性的一个实现中，部分的单位是应用程序或扩展。实例是通过添加应用程序或应用程序数据文件(ADF)扩展的。ADF可以由开发者为用户在部署单个应用程序时创建。ADF通常定义应用程序的核心逻辑并且可以包括用于，尤其是，事件、条件和动作如通知的模式。应用程序可以通过添加扩展或扩展数据文件(EDF)来扩展。EDF可以由任何人创建并且在一个实例和应用程序已经创建(包括应用程序的初始安装)之后的任何时间使用。

对于共享功能的应用程序，它们需要彼此知道。按照本发明的一个方面，这可以通过使用定义注册表314和绑定注册表3414组成的实例注册表3410来存储有关函数和函数如何与应用程序绑定的信息。实例注册表3410为应用程序提供一个用于存储数据的共享位置。实例注册表3410包括定义注册表3412和绑定注册表3414。

定义注册表3412存储有关应用程序函数的信息。按照本发明的一个方面，由应用程序(例如，IA应用程序)使用的应用程序函数可以注册或存储在定义注册表3412中。在定义注册表3412中注册的函数使这些函数对于运行在系统上的所有应用程序公开。因此，由应用程序使用的函数或者完全是私有意义的，在定义注册表中不注册，或者是公开意义的，在定义注册表中注册它们并且对于所有其它应用程序是可访问的。应当注意，这只是一种实现定义注册表的方式。另一种实现机制可以是存储一个指示器，表示一个函数是公开的还是私有的。一些可以包含在定义注册表中的示例性信息包括下列：

 列  说明 SourceApplication(源应用程序)  实现函数的应用程序的GUID FunctionID(函数ID)  正在注册的函数的GUID FunctionType(函数类型)  可以是ConditionFunction(条件函数)，ActionFunction(动作函数)和AccessorFunction(存取器函数)。 FunctionVersion(函数版本)  函数版本由四个用句点分开的整数字段组成。<主>.<次>.<编译>.<修订> FunctionDescription(函数描述)  由函数执行的服务的文本描述，可以由消费的应用程序用作帮助文本。描述不应当引用函数名字，因为它有可能向用户揭示为条件、动作或存取器。 ParameterName(参数名)  参数的形式名字 ParameterDataType(参数数据类型)  参数数据类型 ParameterDescription(参数描述)  参数的文本描述和它在函数中扮演的角色。描述不应当引用函数名字，因为它有可能向用户揭示为条件、动作或存取器。 Optional(可选的)  参数是否是可选的

绑定注册表3414可以存储来自多个应用程序的函数的所有绑定、条件、动作和存取器。这都可以是真的，无论那些函数是从一个初始定义导出还是对应用程序的以后扩展。而且，应当注意，按照本发明的一个方面，公开函数在没有绑定元数据的情况下不能使用。绑定元数据是指定一个公开函数如何绑定到一个应用程序数据事件数据的信息。在绑定注册表3414中注册一个公开函数将一个函数绑定到一个应用程序。这是一个一对多关系，其中一个函数可以绑定到许多不同应用程序。

注册在绑定注册表3414中的绑定可以具有若干状态。例如，一个绑定可以是候选绑定。候选绑定是由函数的定义者创建的并且使之可用于其它应用程序。绑定还可以具有一个绑定功能的状态，表示绑定专用于一个给定的应用程序，它表示该特定应用程序如何绑定到一个给定的条件或动作函数。而且，绑定可具有“不被接受”的状态。这些是目标在于一个特定应用程序但不被作为目标的应用程序的接受逻辑接受的候选功能。接受逻辑可以在ADF中声明，并且可以包括组件用于，尤其是，确保EDF源是可信的(例如，使用数字签名)，经过授权的(例如，来自可信源的列表)，和有书面证明的(已由一个可信源签署的EDF)。在绑定注册表3414中可容纳的更多的信息包括但不限于：

  列  说明  ExtensionID(扩展ID)  用于这个特定绑定的GUID  FunctionID(函数ID)  表示要绑定的函数的GUID  TargetApplication(目标应用程序)  表示正在扩展的应用程序的GUID。对于不是以一个特定应用程序为目标的候选函数，这个字段是Null。  TargetApplicationVersion(目标应用程序版本)  由四个用句点分开的字段组成的函数版本。<主>.<次>.<编译>.<修订>  SoureApplication(源应用程序)  表示提供候选函数绑定的应用程序的GUID。  SourceApplicationVersion(源应用程序版本)  由四个用句点分开的字段组成的函数版本。<主>.<次>.<编译>.<修订>  BindingStatus(绑定状态)  表示：{Candidate(候选)，Bound(已绑定)，或NotAccepted(不接受)}绑定  BindingType(绑定类型)  可以是条件、动作或存取器  BindingName(绑定名)  表示绑定的串。这个名字将在内在化到消费应用程序之中时用作条件、动作或存取器名字。  ParameterName(参数名)  用于要绑定的函数的参数名字  ParameterValue(参数值)  常数、FieldReference(字段引用)、或其它函数，返回一个相应于在定义注册  表中定义的ParameterDataType(参数数据类型)的数据类型。  ConflictResolution(冲突解决)  开发者指派的一个Int(整数型)值或聚集多个动作优先级的函数

扩展组件3420基于候选函数创建条件和动作。扩展组件3420是可以在安装时由安装脚本调用以将候选函数绑定到应用程序的组件。如果在绑定注册表3414中产生新的候选函数条目，则取决于在目标应用程序的部件上采取的动作或不采取动作，若干事情会发生。例如，如果目标应用程序没有被安装，则该条目可以被忽略。如果安装目标应用程序但配置为不接受扩展，则该条目被再次忽略。然而如果目标应用程序被安装并且接受候选函数，则使用扩展组件3420为该应用程序创建新条件、动作或存取器绑定并且被绑定到应用程序A3410。因此，在系统3400中，应用程序A 3430包含一个本地函数“CondtionFuncx(条件函数x)”，它愿意使之可用于应用程序B 3440。通过添加一个扩展数据文件(EDF)，可以使该函数可用于应用程序B 3440。之后该函数存储在实例注册表3410中，以使它可用于应用程序B 3440的方式。例如，ConditionFuncX(条件函数X)可以在定义注册表3412中注册，并且候选函数可以存储在绑定注册表3414中。扩展组件3420随后可以从可以创建条件A的绑定注册表3414读取该候选函数，通过将它绑定到应用程序B 3440。因此，创建将条件A绑定到应用程序A的conditonFuncX(条件函数X)的绑定3450。

一旦绑定或依赖性已经建立，就应当注意，它们可以用许多方式断开。例如，由一个应用程序实现的一个函数可变成不可用(即，断开的依赖性)，如果该应用程序被卸除。一种断开依赖性的方法的另一个例子是如果一个新应用程序被安装，具有新条件、动作或存取器，它被绑定于一个不再可用的函数。而且，依赖性可以被断开，如果一个应用程序被重新配置为不典型示范接受所有或特定的扩展。因而，现有的首选项可能对不再可用的条件、动作或存取器有依赖性。断开的依赖性可以用许多方法补偿。按照本发明的一个方面，可以定义一个不可用的状态。例如，在如果允许一个应用程序彻底断开依赖性之前可以通知所有其它的应用程序，因此它们可以将依赖的首选项放在“NotAvailable(不可用)”状态中。之后，只要应用程序被安装，系统或应用程序可以检查以查看是否已经重新建立依赖性，使得不可用状态可以改变成可用并且可以使用这些首选项。

首选项可以在信息代理应用程序之间创建。首选项实例化表示可以用于实现在IA应用程序之间的交互的方法。按照本发明的一个方面，至少两个机制可以提供，使用户能够创建在多于一个的IA应用程序中访问的能力的首选项。一个机制是EDF绑定。应用程序开发者可以创建EDF绑定以使在一个应用程序中的首选项类能够引用在另一个应用程序中定义的条件和动作。这使最终用户能够实例化引用来自多个应用程序的条件和动作的首选项。事件提交动作也可以利用大量应用程序提供的能力。事件提交动作函数可以隐式地在由应用程序定义事件类时创建。之后，三个事件提交动作函数可以通过EDF绑定到由其它应用程序使用的动作，从而使新创建用户首选项的潜在能力变得更丰富。

为了使应用程序能够直接实例化由应用程序开发者指定的首选项(与最终用户相反)，需要使用另外的机制或组件。一个机制或组件可相应于首选项模板。首选项模板可以在首选项类的上下文内定义并且包括一组条件和类。为了定义模板，首选项类的句法可以用新的标记来扩展。接着，这个标记可以由EDF为了用新模板扩展应用程序的目的而使用。首选项实例化动作也可以使用。当创建一个新的首选项模板时，可以隐式地创建一个动作函数以从一个指定的模板实例化一个首选项。该动作函数的参数表示从模板的一个固定的条件动作集实例化一个首选项所需要的常数。

开发者也能够在应用程序内和跨应用程序在没有最终用户的显式干预的情况下实例化首选项。若干机制可以用于实现这个功能。例如，一个新ADF标记可以添加到一个首选项类以允许首选项在ADF内在应用程序定义时直接被实例化。可供替换地，一个新的EDF标记可添加到首选项类。这将允许首选项在定义应用程序期间和在定义应用程序之后都能被实例化。另外，首选项实例化能通过在模式定义之外的脚本(例如，SQL脚本)来完成，例如通过系统API的使用。

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

为进一步理解应用程序可组成性和可扩展性的各种方面，在下面提供几个例子。ShellApp(命令解释程序应用程序)是一个操作系统信息代理应用程序。Office(办公室)也是一个信息代理应用程序。

例#1组成

组成可以在一个新应用程序被编写以绑定到一个现有的已知函数时定义。在本例中，ShellApp(命令解释程序应用程序)先安装，而Office(办公室)在后安装。当Office(办公室)被编写时，开发者知道并且设计Office(办公室)以利用ShellApp(命令解释程序应用程序)的FuncX(函数X)条件函数。当Office(办公室)被安装时，它在绑定注册表中注册一个绑定，将FuncX(函数X)条件函数(旧函数)绑定到在Office(办公室)应用程序(新应用程序)中的一个条件上。Office(办公室)应用程序安装脚本随后调用扩展组件，它读取绑定注册表。扩展组件随后可以检测已经定义的条件(“内建的(built in)”)，并且因此跳过下一个步骤即它重新评估实例级的NotAvailable(不可用)状态。Office(办公室)应用程序称为是由ShellApp(命令解释程序应用程序)扩展的。

例#2扩展

扩展可以在一个旧应用程序用一个新函数扩展时定义。在本例中，如上，ShellApp(命令解释程序应用程序)被安装，随后安装Office(办公室)。当Office(办公室)被编写时，开发者创建一个可以在ShellApp(命令解释程序应用程序)中使用的动作函数FuncY(函数Y)。当安装Office(办公室)时，它在定义注册表中注册一个动作函数并且在在绑定注册表中注册一个将Office(办公室)应用程序FuncY(函数Y)绑定到ShellApp(命令解释程序应用程序))(旧应用程序)中的一个动作的绑定。Office(办公室)应用程序脚本调用扩展组件以检测存在一个新的绑定，它在ShellApp(命令解释程序应用程序)中没有相应的动作，并且因此通过在ShellApp(命令解释程序应用程序)中创建它来内在化该动作。随后重新评估实例级NotAvailable(不可用)状态。ShellApp(命令解释程序应用程序)称为已经用Office(办公室)应用程序扩展了。

例#3补丁扩展

打补丁可以在函数和应用程序两者都已经安装在系统上时发生。因此，假定ShellApp(命令解释程序应用程序)和Office(办公室)两者都已经安装在系统上，并且随后要安装一个Office(办公室)服务包。在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，它包含个性化文件夹3510和首选项3512。个性化文件夹3510指可以基于可以由最终用户直观地指定的条件表达式来包括或排除项的文件夹或数据容器。在一个实例中，文件夹3510可以以分层方式安排并且由操作系统的一个组件来实现。然而，应当注意，术语文件夹或数据容器不是以受限制的方式使用的。文件夹3510可以扩展到链接、指针或由一组关系定义的数据的任何集合。信息代理首选项3512表示一个非技术性最终用户组合系统化逻辑和系统化数据(例如通过数据存储器150)以提供丰富的个性化应用程序和环境的能力。相反，常规的首选项仅利用具有直观名字(提供串常数)的简单条件。首选项3512可以由最终用户指定，例如，使用对他们熟悉的逻辑，诸如：在事件IF(如果)条件THEN(那么)动作或者以更多应用程序专用的术语：在文件夹事件时IF(如果)条件THEN(那么)包括/排除动作。而且，应当注意，首选项3512可以由推理逻辑开发，诸如通过使用统计和/或贝叶斯定理模型基于用户动作来了解首选项。在此使用的推理分析指在许多输入变量上使用推理过程，以给出一个输出变量，即，用户首选项或对首选项开发工具的输入。该分析可以包括，在一个方面，统计模型和/或贝叶斯定理模型的使用，但不限于此。除条件和动作之外，首选项包含开始首选项评估的触发器。按照本发明的一个方面，这类触发器可以包括显式用户指令，按照时间调度的，和/或自动地在一个文件夹中添加文档、删除文档和/或修改文档。还有，应当意识到首选项3512可以被分组，以实现将会太复杂的结果集能通过单个表达式容易地创建(例如，从文件夹包括/排除特定的项，组合多个查询的效果)。再有，应当注意个别和分组首选项3512可以表示为一个物理实体，使得用户在文件夹3510之间可以拖、放、剪切和粘贴首选项。文件夹3510可以包含数据拷贝或者指向存储在存储设备(即虚拟文件夹)中的数据的简单指针。所存储的数据可以包括但不限于词语处理文档、电子表格、图片和音乐。再有，个性化文件夹3510可以具有相关联的首选项3512，它与在多个不同域中的项有关。为了支持这样的功能，可以引入预定义的常数。更明确地说，来自一项域(例如，MyGrandparent(我的祖父))的预定义的常数可以用作来自其它域(例如，PhotofromMyGrandparent(来自我祖父的照片))的条件参数。预定义的条件和约束的组合提供一种简单直观的方法让用户联系各种项域。当然，用户定义的常数也可以提供给个性化文件夹的条件。简单的条件可以从一个项域的模式中推理。例如，条件EmailIsFrom()(电子邮件来自)或者SubjectContains()(主题包含)可以从一个电子邮件模式中推理。然而，模式开发者可肯定地显式指定既更丰富又更小的有用条件集合。而且，还应当注意，新的条件可以添加到应用程序300(可扩展性)并且随后由最终用户用于定义新首选项。在新的模式安装时，用于个性化文件夹的新能力变成可能。

按照本发明的一个方面，文件夹3510可以分类成主动或导出的。主动文件夹代表用户在一个文件夹中出现感兴趣的内容时(例如，事件--文件文本添加、删除或修改)采取动作。例如，可以从数字摄像机下载图片至一个称为MyPictures(我的图片)主动文件夹。同时或者在之后的短时间内，主动文件夹可咨询日程表应用程序以确定在拍照时用户要做什么并且随后创建一个具有合适名字的新文件夹(例如，钩鱼旅行)并且将图片移动到该新文件夹。在一个电子邮件上下文中，电子邮件应用程序可确定何时一个消息包含一个花费报告并且如果它小于某个值则它可以将报告移到经批准的报告文件夹。在主动文件夹的另一个示例性使用中，音乐可下载到一个主动文件夹，它随后确定艺术风格(例如，爵士、经典、说唱、摇滚...)并且将该音乐移到一个适当的文件夹。

导出文件夹使用首选项决定是否要包括或从文件夹排除特定的文件。另外，应当注意，导出文件夹可以是提供到文件的映射或指针的虚拟文件夹。虚拟文件夹用作容纳数据的真实文件夹，但文件夹并没有实际的物理存在。导出文件夹使用的一个例子包括这样一种情况，即用户定义一个文件夹以包括用户在最近两个星期内至少听过三次的所有爵士音乐。导出文件夹也可以由首选项来定义，以包括一种特定类型的所有文件，除某些例外之外。例如，可以定义一个文件夹来包括爵士音乐家Miles Davis(迈尔斯·戴维斯)的所有曲目，但排除特定的歌曲曲目(例如，Human Nature and New Rumba(人性和新伦巴))。而且，应当注意，可定义首选项使得用户能将文件拖放到文件夹中并且文件夹会确定放入的文件是否是定义的类型。如果文件是允许的类型，则它可以被添加到该文件夹，如果不是，则该文件被拒绝(例如，不拷贝到该文件夹)或者可供替换地可提示用户关于是否应当为该特定文件创建一个例外。

而且，应当注意，某些文件夹可以展示活动文件夹和导出文件夹两者特性。因此，有些文件夹可以具有与它们相关联的首选项，指定哪些项包含在一个文件夹中，并且具有当某些事件在那些项上发生时要采取什么动作的首选项。

可以使用系统100的执行引擎来处理应用程序。如前揭示的，可以将首选项存储为数据并且以数据查询的形式执行。数据存储器150可以在一个或多个表中存储数据，随后可以使用首选项信息来查询。按照惯例，对一个数据库的表执行查询在计算上是不可行的，因为这些查询必须在相对短的时间间隔内连续地执行以保证在文件夹中的数据保持最新。这在轻量级系统如个人计算机上尤其是不切实际的，其中的处理器不能有效地执行大量程序同时不断地运行查询以更新文件夹数据。然而，本发明通过在事件发生时诸如当添加、删除或修改数据时执行查询来克服这个问题。因此，处理器没有负担并连续地执行查询而文件夹数据保持最新。

基于活动文件夹的类似工作流的活动

个性化(例如，ECA规则)与工作流或任务调度不同。工作流或任务调度是可以通过在文件夹中的项表示的多步骤的工作片段。个性化是使最终用户能够指定在系统/应用程序拦截点应用程序的首选项的概念，为了自动化最终用户有意义的事件(例如，电子邮件到达)或者系统/应用程序行为(例如，基于用户上下文控制桌面中断)的处理。个性化关心的是使最终用户能够表示一个其逻辑被定位在一个给定拦截点(例如，事件，在一个流程中的点...)的首选项。多个首选项的任何级联的评估由于单个首选项的动作，因此是偶然的，不是计划的。因此个性化不是工作流的小型形式，相反，工作流与个性化是完全不同的事。用于处理事件的首选项的偶然级联与在工作流中的一个计划的任务/规则链不同。而且，个性化可以应用程序于电子邮件、电话呼叫、桌面中断和许多其它类型的最终用户事件，与是否涉及工作流或任务调度无关。个性化工作流基于个性化与工作流无关，但却是工作流的互补概念的前提。

个性化可以应用程序于工作流或任务调度，只要最终用户决策是相关的。在任务的个性化中存在工作流个性化的各种机会，工作流开始的个性化、工作流任务的个性化和工作流调度的个性化。个性化一个任务的一个例子是，用户指定决策逻辑以自动化某个任务的处理，诸如批准由一个人直接报告的某个美元金额的订货单。工作流开始处理是否基于一个感兴趣的事件(例如，电话呼叫、电子邮件到达...)打开/开始一个工作流。一个计划的个性化有可能转变成一个工作流，通过用与要跟踪的时间表交互的适当能力等来包装它。换言之，个性化可用作在工作流内的一个计划的任务，其中用户首选项将完全确定任务的解决方案。最后，个性化可以涉及工作流调度。存在有关工作流中下一个步骤的选择时，个性化可以用于允许用户指定用于这类决策的首选项。

包括许多上述类别的个性化的工作流的一个实际例子是花费报告的处理。在本例中，电子邮件到达收件箱，检测电子邮件的类型(例如，主题行，标志为花费报告...)，扫描电子邮件数据，并且如果发票金额小于某个美元金额则将该报告移到一个批准的文件夹。之后，可以发送一个电子邮件回发送者，表示该报告已被批准的状态。随后，可以创建一个日志让用户每月检阅并且可以计算已批准的总金额。

尽管工作流的个性化的所有上述类别增强了工作流的价值，但这类好处的应用程序能力不排除工作流。那些好处可以应用程序于许多其它领域，包括但不限于通信处理、路由、或个性化，其中这类领域可不参与工作流。

记事文件夹

按照本发明一个方面的记事表示与用户或系统的用户有关的历史和上下文信息。通知系统经常包括可以用作基于先前的动作评估是否采取动作的一部分的历史数据的概念。例如，用户希望建立一个首选项，它表示“当MSFT股票达到一天的新高时通知我”。在这个例子中，系统必须能够在这一天中保存MSFT股票的最高价格点并且在达到新高时更新这个信息。

按照本发明的一个方面，记事存储在数据存储器中并且用户可通过用户界面(例如，由操作系统提供的)随意地访问。因而，最终用户具有对这个历史数据的控制；她可以用备份其它文件的方式备份它，她可以将它与她家里或办公室里的其它计算机同步，她可以通过正常的文件共享机制来共享它，并且可以设置访问许可和其它安全设置以准确控制谁可以访问这个上下文信息。例如，用户可以允许在他们的工作组中的每个人看有关MSFT股票价格的历史信息，但希望限制诸如他们是否在办公桌前或者在开会的上下文信息。

而且，本发明的系统可以将某些共同的行为揭示为“内建”的记事创建/维护逻辑，包括创建一个“审计(audit)”记事的能力，其中代表用户采取的每个动作被保存在一个记事中；“计数(count)”记事，其中系统保持它已经看到的一个特定种类的事件或动作的数量；以及“高/低水印(high/lowwatermark)”记事，它可以保持跟踪在某个时段在历史上见过的最高和最低值。

而且，本系统可以使不知道信息代理应用程序的应用程序更新这些记事成为可能。许多通知平台使得在用户规则(此也称为首选项)的正常处理期间更新上下文信息成为可能，但因为本发明使用存储在数据存储器中的系统化数据并且作为规则或首选项处理的一部分，所以系统可以使用由任何应用程序创建的上下文信息。例如，用户可以下载并运行由NASDAQ编写的应用程序，它使实时证券报价流到用户的计算机。NASDAQ应用程序为每个用户感兴趣的符号创建一个文件，并且在这些文件中保存相关的信息。因为本发明的信息代理应用程序，按照一个方面，建立成使用这类具体化的上下文信息，所以信息代理系统可以在用户规则或首选项处理期间利用这些文件作为记事。

记事也可以结合活动文件夹使用。因为个性化文件夹系统包括监视特定文件夹的能力，创建、修改或移动到这类文件夹中的文件夹项可以视为对一个特定的记事或记事集的上下文更新。这样，用户有可能在没有代表他们运行的任何程序员编写的代码的情况下保存记事。相反，最终用户可以仅使用操作系统的现有文件操纵机制来保持他们的上下文信息最新。

因而，使用产生软件、固件、硬件或它们的任何组件的标准编程和/或工作技术，可将本发明实现为方法、装置或制造品。在此使用的术语“制造品(article of manufacture)”(或者，可供替换地，“计算机程序产品”)旨在包括可从任何计算机可读设备、载波或介质访问的计算机程序。当然，本领域熟练技术人员将认识到，可以在不脱离本发明范围的情况下作为这个配置作出许多修改。

通过上面描述的示例性系统，参考图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，在事件发生时执行首选项。事件可以是发生的任何东西，包括但不限于在文件夹数据方面的变化或在股票价格方面的变化。首选项的执行或评估可以通过利用查询数据存储器组件中的数据来完成。在4120，基于有条件地有效的首选项采取动作。

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

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

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

系统存储器4216包括易失性存储器4220和非易失性存储器4222。基本输入/输出系统(BIOS)包含在计算机4212的元件之间传送信息如在启动时的基本例程，存储在非易失性存储器4222中。作为例示，且非限制性地，非易失性存储器4222可以包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除ROM(EEPROM)或闪存。易失性存储器4220包括随机访问存储器(RAM)，它用作外部高速缓存存储器。作为例示而非限制性地，RAM可以多种形式提供，诸如同步RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双倍数据速率SDRAM(DDR SDRAM)、增强型SDRAM(ESDRAM)、同步链路DRAM(SLDRAM)和直接存储器总线(Rambus)RAM(DRRAM)。

计算机4212还包括可移动/不可移动、易失性/非易失性计算机存储介质。图42例示，例如一个盘存储器4224。盘存储器4224包括，但不限于，设备如磁盘驱动器、软盘驱动器、磁带驱动器、Jaz驱动器、Zip驱动器、LS-100驱动器、闪存卡或存储器棒。另外，盘存储器4224可以包括与其它存储介质分开或组合起来的存储介质，包括但不限于光盘驱动器，诸如光盘ROM设备(CD-ROM)、CD可记录驱动器(CD-R驱动器)、CD可重写驱动器(CD-RW驱动器)或数字多功能ROM驱动器(DVD-ROM)。为便于盘存储设备4224连接到系统总线4218，一般使用可移动或不可移动接口，如接口4226。

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

用户通过输入设备4236向计算机4212输入命令或信息。输入设备4236包括但不限于，定点设备诸如鼠标、轨迹球、输入笔、触摸板、键盘、话筒、操纵杆、游戏垫、卫星天线、扫描仪、TV调谐卡、数字照像机、数字视频摄像机、网络摄像机等等。这些和其它输入设备经接口端口4238通过系统总线4218连接到处理单元4214。接口端口4238包括，例如，串行端口、并行端口、游戏端口和通用串行总线(USB)。输出设备4240使用与输入设备4236相同类型的一些。因而，例如，USB端口可用于提供输入到计算机4212，并且从计算机4212输出信息到输出设备4240。除其它输入设备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 1102.3、令牌环/IEEE 1102.5等等。WAN技术包括但不限于，点对点链路、电路交换网络如综合业务数字网络(ISDN)和其各种变体、包交换网络和数据订户线路(DSL)。

通信连接4250指用于将网络接口4248连接到总线4218的硬件/软件。尽管为了例示清楚，通信连接4250在计算机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本地的信息。

上面所描述的包括本发明的例子。当然，没有可能描述为了描述本发明的目的而描述每一个想象得到的组件和方法的组合，但本领域熟练技术人员可认识到，许多其它的本发明组合和变换是可能的。因此，本发明旨在包括所有落入所附权利要求书的精神和范围之内的这类改变、修改和变体方案。而且，对于在详细描述和权利要求书中使用的术语“包括(include)”，这样术语指在以与术语“包括(comprising)”在权利要求中用作过渡词时解释的“包括(comprising)”相似的方式来包括。

                     附录<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>EmailPreference1</PreferenceClassName>

    <EventClassName>EmailEvents</EventClassName>

<ConditionClasses>

    <ConditionClass>

             <Name>MailFrom</Name><！--条件类ID＝1-->

        Mail is From @Sender

    </CondtionClass>

    <ConditionClass>

        <Name>MailContains</Name><！--条件类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><！--条件类ID＝3-->

    Priority>@Priority

    </CondtionClass>

    <ConditionClass>

        <Name>MailFrom</Name><！--条件类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><！--条件类ID＝5-->

            Symbol＝@Ticker

        </CondtionClass>

        <ConditionClass>

            <Name>TargetPrice</Name><！--条件类ID＝6-->

            Price>@TargetPrice

        </CondtionClass>

    </CondtionClasses>

    <ActionClasses>

        <ActionClass>

        <Name>SendCellPhoneMsg</Name>

        Send a message to cell phone of @subscriberId

        </ActionClass>

    </ActionClasses>

</PreferenceClass></PreferenceClasses>