专利名称：用于通知递送的可扩展用户环境系统的制作方法
技术领域：
本发明涉及计算系统中的通知，尤其涉及一种用于控制来自多个来源并根据用户环境的的通知递送的系统。
背景技术：
在计算机系统中，通知可以采用来自程序的信号的形式，它向用户指出指定的事件已发生。这种通知可以包含文本、声音和图形的各种元素。其它属性也可以被包括在该通知内，例如，优先级、发送该通知的人(关于诸如电子邮件或即时消息通信等通道)、以及该通知何时到期。通知也可以包括某些代码元素，以便该用户可以与该通知交互并启动任意代码(例如，点击该通知内的按钮或文本，这些按钮和文本可以致使启动新的程序或对当前正在运行的程序采取行动)。
操作系统可以创建通知，以让用户知道网络连通性和更新。使用“联系人列表”的即时消息通信程序可以在屏幕上绘制通知，以便让用户知道该联系人列表有什么情况正发生或联系人何时启动即时消息对话。其它程序可以提供绘制在显示器的类似区域内的类似通知。关于这些类型的通知的一个问题是它们通常不了解其它通知，从而有时会导致通知被绘制在其它通知之上。
关于现有通知系统的另一个问题是它们可能会致使通知被不适当地递送或在不适当的时间被递送。例如，对于提供全屏幕演示的用户，在该演示期间让其它程序在屏幕上绘制通知可能是不适当的。可能绘制这类不适当的通知的程序的例子是即时消息通信程序，该即时消息通信程序在操作系统的后台运行，并且当联系人列表中的联系人登录或启动即时消息时，绘制这类通知。对于用户而言，演示期间的这种类型的“中断”可能是不合需要的。
本发明针对提供一种克服前述和其它缺点的系统。更明确地说，本发明针对一种用于控制来自多个来源的通知的递送的系统，它在确定每个通知的适当处理时考虑用户环境。
发明概述提供一种用于控制通知递送的系统。根据本发明的一个方面，该系统代理(broker)并串行化来自多个来源的通知的递送。此外，提供用户环境的共享概念，用于为这些通知中的每一个确定适当的处理。根据这些方面，由系统所递送的通知可以被认为更有价值，因为它们是在用户更易于接收它们时被递送的。这些方面也规定公用规则，这些公用规则帮助用户排除不合需要的通知。
根据本发明的另一个方面，用户环境由操作系统和任意程序来声明。在一个实施例中，用户环境包括可能是真或假的条件，以及如果条件为真则要遵循的指令。例如，条件可能是“当用户正在收听音乐时”，关于它的指令可能是“在屏幕上递送通知，但无声音”。一般而言，关于用户环境的条件可以被认为是系统假定的状态，该状态按某种方法使用户不可用于通知递送，或者使应该递送该通知的方法不同于启动过它的程序发送它的方式。用户可能处于被认为是“不可用”的状态，在此情况中，通知既不被递送，也不被保留，直到用户变成“可用”。例如，如果用户正在运行全屏幕应用程序，其中，该应用程序正在使用或正被显示在显示屏幕的完全区域上，那么，该用户可能被认为是不可用的。或者，用户可能是“可用的”，但处于这种状态通知需要被修改以适合于该用户。
根据本发明的另一个方面，除了声明环境的操作系统以外，程序向该系统注册，并声明它们所提供的环境以及它对通知的影响(按照绘制在屏幕上是否适当、适合于绘制在屏幕上的侵入等级、以及声音是否适当或应该按什么相对音量来播放声音)，然后告诉该系统环境是真还是假。在一个实施例中，在将要递送通知的时候，环境也可以被评估为真或假。在一个实施例中，该系统也可以跟踪调用程序的进程；并且，如果该进程不再存在，那么，环境可以被复位为假。通过跟踪进程，可以避免某些不合需要的情况，例如，应用程序声明用户为正在忙碌，随后崩溃，然后让用户陷入一种他们已被声明为不可用于接收通知的状态。
根据本发明的另一个方面，可以有为通知的绘制而指定的不同的侵入等级。换言之，根据用户环境，可以有关于通知的绘制的梯度，以便可以有采取所绘制的通知的形式的不同的侵入等级。例如，标准通知可以自由地在客户机区域内加以绘制，并简要地遮掩窗口。如果用户在稍微有限制的环境中，那么，通知可以自由地示出，但只按侵入性较小的方式，例如，它可能不被允许绘制在另一个窗口之上。作为另一个例子，如果用户正在运行最大化的应用程序，那么，设置可以是用户环境稍微受到限制，因为用户已清楚地作出陈述他们想要其当前应用程序获得整个客户机区域。在此情况下，通知可以仍然被允许绘制，但只可以使它们出现在工具条内。通知绘制形式的这种类型的降低的侵入性可减少通知的影响，并可减少认知负载。
根据本发明的另一个方面，所提供的环境被展示给用户，并可以按照对递送的影响而被关闭(例如，用户不同意程序对环境的评估)或被更改。
根据本发明的另一个方面，用户可以定义规定应该如何递送包含指定元素的通知的规则。例如，用户规则可以规定从“John Doe”那里接收的以及在主题行内有“紧急”的任何通知应该被立即递送。在一个实施例中，这类用户规则被给予胜过用户环境的优先级。使用户可以获得这些用户规则，以供根据用户的偏好来加以修改。
附图简述通过参考以下的详细说明并结合附图，本发明的前述各个方面和许多附带优点中将变得更容易明白，同时能够获得更好的理解。在附图中
图1是适合用于实现本发明的通用计算机系统的框图；图2是流程图，示出了用于根据本发明来处理通知的通用例程；图3是流程图，示出了用于声明用户环境的操作系统或任意程序的例程；图4是流程图，示出了用于在调用通知API时将用户环境评估为真或假的例程；图5是流程图，示出了用于调整用户环境和创建新的用户规则的例程；图6是流程图，示出了用于根据用户环境和用户规则来处理通知的例程；图7是流程图，示出了用于实现基于通知的内容和用户环境的用户规则的例程；图8是流程图，示出了用于推迟通知的递送的例程；图9是流程图，示出了用于根据各种限制性设置来确定如何绘制通知的例程；以及图10是流程图，示出了用于根据各种限制性设置来确定通知的音量级别的例程。
较佳实施例的详细描述本发明针对一种用于递送通知的系统。在现有系统中，通常有想要将通知发送给用户的众多竞争元素，其中每个竞争元素设计其自己用于发送这些通知的方法。一般没有一个竞争元素了解其它通知并因此往往绘制在彼此之上和彼此的应用程序之上，当每个竞争元素同时选择呈现其各自的通知的指示时，这会导致冲突。此外，没有用户环境的共享概念，从而导致一些通知被不适当地递送或在不适当的时间被递送。本发明通过构建通知作为操作系统的丰富的一部分，来解决这些问题，使得本发明所提供的用于通知的用户界面变得类似，从而停止相互之间的冲突，因为系统适当地代理并串行化其屏幕上的呈现。此外，本发明所提供的通知可以被认为更有价值，因为它们是在用户更易于接收它们时被递送的，此外，公用规则的运用可帮助用户排除不合需要的通知。
图1和下文意在简要概括地描述可以在其中实现本发明的合适的计算环境。虽然未作要求，但是将在诸如程序模块等由个人计算机执行的计算机可执行指令的一般环境中描述本发明。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、特征、组件、数据结构等。如本领域的技术人员将会理解的，可以利用其它计算机系统配置，包括手持设备、多处理器系统、基于微处理器的或可编程的消费电子设备、网络PC、小型计算机、大型计算机等，来实践本发明。也可以在分布式计算环境中实践本发明，其中，由通过通信网络连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于本地和远程记忆存储设备中。
参考图1，用于实现本发明的示例性系统包括常规个人计算机20形式的通用计算设备，常规个人计算机20包括处理单元21、系统存储器22、以及将包括系统存储器22的各种系统组件耦合到处理单元21的系统总线23。系统总线23可以是几种类型的总线结构中的任一种，包括存储器总线或存储器控制器、外围总线、以及使用各种总线体系结构中的任一种的局部总线。系统存储器包括只读存储器(ROM)24和随机存取存储器(RAM)25。基本输入/输出系统(BIOS)26被存储在ROM 24中，它包含例如在启动期间有助于在个人计算机20内的元件之间传送信息的基本例程。个人计算机20还包括用于从硬盘39读取或对其写入的硬盘驱动器27、用于从可移动磁盘29读取或对其写入的磁盘驱动器28、以及用于从可移动光盘31(例如，CD-ROM或其它光学介质)读取或对其写入的光盘驱动器30。硬盘驱动器27、磁盘驱动器28和光盘驱动器30分别通过硬盘驱动器接口32、磁盘驱动器接口33和光驱接口34而被连接到系统总线23。这些驱动器及其相关联的计算机可读介质为个人计算机20提供计算机可读指令、数据结构、程序模块和其它数据的非易失性存储。虽然这里所描述的示例性环境使用硬盘39、可移动磁盘29和可移动光盘31，但是，本领域的技术人员应该理解，在示例性操作环境中，也可以使用可以存储可由计算机访问的数据的其它类型的计算机可读介质，例如，盒式磁带、闪存卡、数字视频盘、Bernoulli磁带匣、随机存取存储器(RAM)、只读存储器(ROM)等。
多个程序模块可以被存储在硬盘39、磁盘29、光盘31、ROM 24或RAM 25上，包括操作系统35、一个或多个应用程序36、其它程序模块37和程序数据38。用户可以通过输入设备(例如，键盘40和定点设备42)来将命令和信息输入个人计算机20。其它输入设备(未示出)可以包括话筒、操纵杆、游戏垫、圆盘式卫星天线、扫描仪等等。这些和其它输入设备通常通过耦合到系统总线23的串行端口接口46连接到处理单元21，但也可以由其它接口，例如，并行端口、游戏端口、或通用串行总线(USB)来连接。监视器47的形式的显示器也经由接口，例如，视频卡或适配器48而被连接到系统总线23。一个或多个扬声器57也可以经由接口，例如，音频适配器56而被连接到系统总线23。除显示器和扬声器以外，个人计算机通常还包括其它外围输出设备(未示出)，例如，打印机。
个人计算机20可以使用与一台或多台个人计算机(例如，远程计算机49)的逻辑连接而在联网环境中进行操作。远程计算机49可以是另一台个人计算机、服务器、路由器、网络PC、对等设备或其它普通网络节点，它通常包括以上相对于个人计算机20而描述的许多或所有元件。图1中所描绘的逻辑连接包括局域网(LAN)51和广域网(WAN)52。这类联网环境在办公室、企业范围计算机网络、内联网和因特网中很常见。
当用于LAN联网环境中时，个人计算机20通过网络接口或适配器53连接到局域网51。当用于WAN联网环境中时，个人计算机20通常包括调制解调器54或用于通过广域网52(例如，因特网)建立通信的其它装置。调制解调器54可以是内置的，也可以是外置的，它经由串行端口接口46而被连接到系统总线23。在联网环境中，相对于个人计算机20或其各个部分而描绘的程序模块可以被存储在远程记忆存储设备中。将会理解，所示的网络连接起示例性作用，可以使用在计算机之间建立通信链路的其它手段。
在图1所示的那种类型的系统上实现的本发明提供了向用户的通知递送。更明确地说，如从以下描述中将会更好地理解的，本发明能够控制来自多个来源并根据用户环境的通知的递送。
在一个实施例中，根据本发明的用户环境系统可以包括三个元素，它们被加以比较，用于决定如何处理通知。第一个元素是用户的环境(如可由操作系统和扩展它的任意程序提供的)。第二个元素是用户的规则和偏好。第三个元素是通知本身(它包含诸如可以与用户的规则相匹配的数据和属性等元素)。
如以下将更详细地描述，本发明通过操作系统和其它程序声明用户环境，其后系统代理用户环境和规则来进行操作。通知由调入该系统的其它程序来引发。比较用户的环境、规则、以及通知的元素，然后确定应该对通知采取什么措施。关于可以对通知采取什么措施的各种选项的例子包括拒绝(如果该通知不被允许绘制或制造噪声，并且该通知将永远不会被用户看见)、推迟(保留该通知，直到用户环境改变或用户的规则规定随后适于递送)、递送(该通知被允许根据用户的环境和规则来递送)、以及路由(用户规则指出该通知应该被交给另一个系统，而不管该通知是否也被允许在本系统中递送)。
以下更详细地描述用于递送通知的各种例程。一般而言，用户可以处于被认为“不可用”的状态，在此情况下，通知既不被递送，也不被保留，直到用户变成“可用的”。例如，如果用户正在运行全屏幕应用程序，那么该用户可被认为是“不可用”的。或者，用户可以是“可用的”，但处于这种状态通知需要被修改，以适合于该用户。例如，如果用户正在收听音乐或在开会，那么，用户可能已指出通知应该被递送到该用户的屏幕，但它们制造的声音应该更轻或根本不制造声音。
如上所述，用户环境部分地确定是否在用户的屏幕上显示通知。当显示通知时，可以基于用户环境内的某些梯度来显示它。换言之，存在可以被指定的所绘制的通知的形式的不同的侵入等级。例如，标准通知自由地弹出到客户机区域内，并简要地遮掩窗口。如果用户在稍微有限制性的环境中，那么，通知可以自由地显示，但只按侵入性较小的方式，例如，它可能不被允许绘制在另一个窗口之上。作为另一个例子。在用户正在运行最大化的应用程序的一个实施例中，默认设置可以是这意味着环境稍微受到限制，并且，用户已清楚地陈述他们想要该应用程序获得整个客户机区域。在这个设置中，通知可能仍然被允许绘制，但只可以使它出现在工具条内。换言之，通知绘制形式的这种类型的降低的侵入性可减少该通知的影响，并可总体上减少认知负载。
图2是流程图，示出了用于根据本发明来处理通知的例程200。在框202处，操作系统或任意程序调用通知应用程序编程接口(API)。在框204处，根据如操作系统和任意程序所设置的以及如用户进一步批准或修改的用户环境，并根据如用户所设置的用户规则，来评估通知的各个元素。在框206处，根据用户环境和用户规则，来递送、推迟、拒绝、发送、或处理通知。
以下将更详细地描述用户环境和用户规则。在一个实施例中，用户环境包括可能是真或假的条件，以及当条件为真时用于确定应该如何处理通知的指令。一般而言，用户环境的条件可以被认为是系统假定的状态，该状态按某种方法使用户不可用于通知递送，或者使递送通知的方法不同于启动过它的程序发送它的方式。换言之，在一个实施例中，用户环境可以被认为是“当条件X为真，则这是应该对传入的通知所采取的措施”的陈述。例子将会是“当我的音乐播放器正在为我播放音乐时，传入的通知应该在屏幕上显示，但不播放声音”。另一个例子将会是“当任何应用程序正在以全屏幕模式运行时，应该将传入的通知推迟到以后”。
对于这类用户环境，在一个实施例中，用户也可以定义用于处理传入通知的特殊规则，从而可以规定对于用户环境的指令的特殊例外。作为例子，用户规则可以规定“当我从‘John Doe’那里接收新的电子邮件时，并且该文本中有‘紧急’，并被标记为‘高优先级’，那么递送该电子邮件，而不管其它用户环境如何”。换言之，在这个例子中，该用户规则为用户环境提供例外，否则，用户环境将会指出此时递送对于传入电子邮件的通知是不适当的。对于根据其来评估用户规则的通知的各个元素，这些可以包括比如文本、声音、图形和其它属性，例如，优先级、发送该通知的人(关于诸如电子邮件或即时消息通信等通道)、该通知何时到期、以及某些代码元素等事物，以便用户可以与通知交互并启动任意代码(例如，点击该通知内的按钮或文本可以致使启动新的程序或对当前正在运行的程序采取行动[例如，删除电子邮件])。
图3是流程图，示出了用于声明用户环境(context)的操作系统或任意程序的例程220。在框222处，操作系统或程序声明默认环境及其对用户的忙碌状态的影响。换言之，程序向系统注册，并提供用户环境，包括它们对通知的影响(例如，绘制在屏幕上是否适当、声音是否适当、或应该按什么相对的音量来播放声音)。作为例子，音乐播放器程序可以声明默认环境，该默认环境规定“当音乐播放器正在为用户播放音乐时，传入的通知应该在屏幕上显示，但不播放声音”。作为另一个例子，操作系统可以声明规定“当任何应用程序正在以全屏幕模式运行时，应该将传入的通知推迟到以后的某个时间”的环境。
返回到图3，在框224处，操作系统或程序将该被声明的环境设置为真或假。例如，对于声明“当音乐播放器正在播放音乐时，传入的通知应该在屏幕上显示，但不播放声音”的环境的音乐播放器，该音乐播放器程序也将这个所声明的环境设置为当前为真或假。换言之，该音乐播放器程序指出该音乐播放器当前正在播放音乐是真还是假。如以下将会更详细地描述，在一个实施例中，在调用通知API的时候，或在重新评估用户规则和例外的时候，也可以评估对环境是真还是假的确定。作为另一特征，系统也可以跟踪调用程序的进程句柄，以便如果进程终止，而没有首先将环境值复位到其默认的“假”值，那么，系统一检测到初始进程不再存在，就将复位该环境值(在一个实施例中，进程句柄状态被设置成用信号通知进程何时终止，并且，该状态变化由观察该进程句柄的系统获得)。这确保如果进程出乎意料地终止或忘记复位环境，则进一步的通知递送将不会受到过度的影响。例如，如果在以上的例子中，音乐播放器程序已被关闭，并且，该进程不再存在，那么，该环境可以被自动复位为假。作为另一个例子，如果程序最初声明用户为正在忙碌，但随后程序崩溃，使得该进程不再存在，那么，该环境可以被自动设置为假，而不是让用户陷入将不会接收通知的状态。在任一情况下，不管环境是被活动地设置还是作功能来评估的，在一个实施例中，这些环境通常可以被解析为要么是真、要么是假。
返回到图3，在框226处，环境信息被添加到系统中所存储的用户环境。这个过程由声明环境的附加程序来重复。此外，如上所述，当用户打开和关闭不同的程序并承担不同的任务时，已被声明的环境是真还是假的状态将会随时间的推移而改变。
如上所述，在一个实施例中，注册环境是声明性过程。如以下将会更详细地描述，根据本发明的一个方面，通过注册用户环境，可以为用户呈现这些环境的列表，以便如果用户不同意这些环境参数，那么，用户可以选择不接受某些环境或更改它们的含义。如上所述，在一个实施例中，环境可以包括可以为真或假的条件，以及关于当条件为真时要对通知采取什么措施的指令。在这方面，用户环境可以包括特定的编程元素，例如人类可读字符串(供最终用户知道含义)；唯一标识符(例如，全球唯一标识符，称为GUID)，以便程序可以告诉操作系统该环境是否为真；以及可以包括就绘制在屏幕上的通知而言该环境意味着什么(如可以包括侵入等级、声音和音量)的陈述的指令。环境也可以是动态的，以下将更详细地描述这一点。
图4是流程图，示出了在调用通知API时供环境被评估为真或假的例程230。在判别框232处，确定当调用通知API时是否将要评估用户环境。如果将要评估用户环境，那么，该例程前进到框234。如果当调用通知API时将不会评估用户环境，那么该例程结束。在框234处，用户环境被评估为真或假。
如图3和图4所示的，并且如上所述，环境可以被主动设置，或者，它可以是在有关的时间被评估的功能。作为例子，程序可以主动指出用户正在收听音乐。作为另一个例子，当评估通知时，程序可能已注册其回叫，以便在评估该通知的时候，系统询问该程序该环境是否为真。第二个过程会特别重要的情况的一个例子是当用户环境与用户规则结合来形成动态环境时。(以下将更详细地描述用户规则。)用户环境与用户规则结合的特定例子将会是当用户已设置规定“我此刻正在会见的人可以总是不管我的忙碌状态而发送通知给我”的规则。在此情况下，必须按照用户正在会见何人，来进一步评估“用户正在开会”的用户环境。在这个例子中，处理会议的程序可以将此注册为动态环境，并且，当评估通知时，依照该环境(否则，它不会被主动地声明为真或假，因为参加会议的人可以随时间的推移而改变)来评估发送该通知的人。换言之，该特定的例子要求按照取决于其它人的环境的用户规则来评估用户的环境。
图5是流程图，示出了用户可以用于调整环境并创建新规则的例程240。在框242处，确定用户是否希望调整环境。如果用户不希望调整环境，那么，该例程前进到判定框246，以下将更详细地描述这一点。如果用户希望调整环境，那么，该例程前进到框244，在那里，用户修改环境。在一个实施例中，可以按允许用户要么关闭环境(例如，用户不同意程序对环境的评估)、要么按照对通知递送的影响来更改环境的方式，来向用户展示所提供的环境。作为更具体的例子，用户环境可以包括各种事物，比如“当任何应用程序正在以全屏幕模式运行时”；“当我正在播放音乐或视频时”；“当我的会议管理器显示我正在开会时”；或“当打开我的不在办公室助理时”。对于这些中的每一项，可以允许用户作出指定指令的选择，当该给定的条件为真时，传入的通知应该遵循所选择的过程。这些指令可以指定各种事物，比如是否或如何在屏幕上绘制通知、以及通知将制造的声音或音量。对于音量，用户可以在给定的条件之下指定所需音量的百分比。对于用于在屏幕上绘制通知的选项，可以向用户提供各个选项，例如，根本不绘制通知、或只在指定的外部显示器上绘制通知、或在当前屏幕上绘制通知。对于通知的绘制，可以指定不同的侵入等级。例如，如果用户正在运行最大化的应用程序，使得环境稍微受到限制，则侵入性设置可以是通知仍然可以绘制，但只可以出现在工具条内。
返回到图5，在判定框246处，确定用户是否希望创建新的用户规则。如果用户不希望创建新的用户规则，则该例程前进到判定框250，以下将更详细地描述这一点。如果用户希望创建新的用户规则，则该例程前进到框248，在那里创建新规则。一般而言，用户规则规定应该如何处理包含指定元素的通知。例如，规则可以规定来自指定的人的通知应该总是被立即递送；并且，该规则可以应用于所有通知，而不管哪个程序启动过该通知，只要它来自该指定的人。作为更具体的例子，其它用户规则可以针对各种事物，比如“关于华盛顿州布雷默顿市的MSN汽车的交通警报”和“来自John Doe的重要的电子邮件”。作为关于来自John Doe的重要的电子邮件的用户规则的例子，该规则可以规定来自John Doe的、文本中有“紧急”的、并被标记为“高优先级”的任何电子邮件都应该遵循指定的处理条件。这些处理条件可以指定该通知应该被立即递送，并且，应该要求用户确认它。一般而言，要求用户确认通知意味着存在该通知的侵入性形式的稍微引发的升级，这体现在该通知将保留在屏幕上，直到用户明确地消除它为止。在一个实施例中，要求用户确认只可以经由用户规则来设置。作为另一个例子，规则也可以指定将要以指定音量为通知播放的自定义声音，以便为该用户提供特殊通知已到达的警报。也可以选择关于在用户的“正常”和“忙碌”条件期间应该如何处理通知的不同设置，这一点可以由用户的环境来确定。处理指令也可以包括比如用于该通知的路由选项等事物，例如，“将通知从John Doe递送到我的寻呼机”。在一个实施例中，当评估环境时，最具限制性的、当前真实的环境是所应用的环境。当评估用户规则时，它意味着特定的通知已与该用户创建的规则相匹配，在此情况下，从已与该通知匹配的用户规则中应用最具侵入性的设置。换言之，在用户规则中，用户已指定某事具有重要性，并且，该过程意在遵循该用户的偏好。如果两个规则之间有冲突，那么，应用最具侵入性的设置。
在一个实施例中，用户规则也可以针对控制来自特殊通知服务的通知的递送。例如，根据通知服务来提供通知的操作系统可以为用户提供用来修改如何递送通知的方法。例如，指定的通知服务可以提供“关于西雅图的交通警报”，并且，用户可以编辑该递送，以便当接收这类通知时，系统应该“显示该通知并播放声音”。
返回到图5，在判定框250处，确定用户是否希望调整已现存的用户规则中的任一个。如果用户不希望调整这些规则中的任一个，则该例程结束。如果用户希望调整用户规则，则该例程前进到框252，在那里，用户修改规则。
如以上根据图3-5而描述的，用户环境和用户规则由操作系统、程序和用户来设置。该系统根据用户的偏好来适当地代理和串行化这些通知的递送。可以向用户展现这些用户环境和用户规则，以便用户可以修改或调整各种环境和规则，或创建新规则。这为用户提供用来管理关于如何处理通知的偏好的集中方法。将会理解，这允许用户有效地管理可能想要将通知发送给用户的计算系统中的许多竞争元素。
图6是流程图，示出了用于根据用户环境和用户规则来处理通知的例程300。在框302处，操作系统或任意程序调用通知API。在判定框304处，确定是否应该将通知记入通知历史。如果要记入该通知，则该例程前进到框306，在那里该通知被记入历史。如果通知不被记入，则该例程前进到判定框310。
在判定框310处，确定通知是否与任何用户规则相匹配。如果通知与任何用户规则相匹配，则该例程前进到框312，在那里遵循这些用户规则(根据该通知内容加上用户环境)，并且该例程继续到点A，点A在图7中延续。如果在判定框310处，该通知不与任何用户规则相匹配，则该例程继续到判定框320。
在一个实施例中，用户规则总是比当前的用户环境重要。如上所述，用户规则可以基于通知的任何元素。例如，基于启动该通知的人的评估的规则可以被应用于所有通知，而不管哪个程序启动该通知，只要它来自该规则所基于的人(例如，“John Doe”总是可以联系到我)。此外，即使在将会导致无法绘制通知的环境中，通知也可以被绘制在屏幕上(例如，“与我会见的人总是可以发给我通知”，即使用户环境一般规定用户在会议期间将不会接收通知)。
返回到图6，在判定框320处，确定通知目前是否可以绘制(只根据用户环境)。如果通知目前可以绘制，则该行程前进到框322，在那里绘制通知，并提供适当的声音和音量。如果目前绘制通知是不适当的，则该例程前进到判定框330。
在判定框330处，确定通知是否已到期。如果通知已到期，则该例程前进到框332，在那里销毁该通知。如果通知还没有到期，则该例程前进到框334，在那里推迟该通知，并且，该例程继续到点B，点B在图7中延续。
图7是流程图，示出了用于根据指定的用户规则来处理通知的例程350。如上所述，从来自图6的点A继续该例程。如图7中所示的，在判定框352处，确定是否应该路由通知。如果将不路由通知，则该例程继续到判定框362，以下将更详细地描述这一点。如果通知将要被路由，则该例程前进到框354，在那里，按指定来路由该通知。当路由通知时，它指出该通知包含与要求该通知被交给另一个系统的用户规则相匹配的元素。如果用户忙碌，则可能会发生这种情况；或者，它可能会在与用户规则中所指定的准则相匹配的每个通知上发生，而不管用户是否不可用。作为例子，具有词“紧急”的通知可以总是被转发到用户的寻呼机，然而，可以根据用户规则和环境的组合来只路由其它通知。
路由指令的一些例子包括“将这个通知转发到电子邮件地址”；“将这个通知转发到另一台PC”；“将这个通知转发到寻呼机”；“将这个通知转发到手机”；或“将这个通知转发到电子邮件服务器”。如以下将更详细地描述，如果通知被路由，它也可以被递送并绘制在屏幕上。此外，向其转发通知的设备可以事先这个相同的环境系统；并且，在那个设备上，可以有关于该用户的环境的另外的或不同的知识；那个设备上的环境系统可以选择对该通知执行不同的动作。
返回到图7，在判定框362处，确定是否要拒绝通知。如果通知将不被拒绝，则该例程继续到判定框366，以下将更详细地描述这一点。如果通知将要被拒绝，则该例程前进到框364，在那里销毁该通知，并且不被该用户看见。换言之，不允许被拒绝的通知绘制或制造噪声。例如，根据规定应该拒绝某个通知的用户规则，或如以上参照图6中的框332而描述的，当通知已到期时，可能会发生这一情况。
返回到图7，在判定框366处，确定是否应该推迟通知。如果通知将不被推迟，则该例程前进到判定框370，以下将更详细地描述这一点。如果通知将被推迟，则该例程前进到框368，在那里保留通知，直到用户环境改变为止，并且，该例程继续到点B，点B在图8中延续。一般而言，推迟通知指出将允许该通知被递送，但用户的当前环境或规则是此时递送通知被认为是不适当的。如以下将参照图8来更详细地描述，一旦用户的环境改变，或者当用户的规则指出它随后是适当的时，该通知将被递送到用户的屏幕，并被允许绘制和/或制造其声音，如用户规则和用户环境所规定的。
返回到图7，在判定框370处，确定是否应该递送通知。如果通知将不被递送，则该例程结束。如果通知将被递送，则该例程前进到框372，在那里根据适当的侵入等级来绘制通知，并且提供适当的声音和音量。换言之，允许通知被递送，尽管是根据用户的环境和规则来递送它的(例如，可以允许通知被绘制，但要求它是无声的)。
图8是流程图，示出了用于推迟通知的递送的例程380。如上所述，从来自图6或图7的点B那里继续该例程。如图8中所示的，在框382处，保留该通知。在框384处，系统监控对被声明为真或假的环境的改变，或者监控规定递送通知现在适当的用户规则。在判定框386处，确定用户环境是否已改变；或者，用户规则规定递送通知现在是适当的。如果用户环境还没有改变，并且如果无用户规则另外规定，则该例程返回到框382，在那里，继续保留该通知。如果用户环境已改变，或如果用户规则规定递送该通知现在可能是适当的，则该例程前进到点C，该点C在图6中延续。图6中的点C返回到判定框304，在那里，用于评估通知的过程重新开始。
图9是流程图，示出了用于根据各种限制来确定通知的绘制的例程400。将会理解，该例程可以作为通知处理的一部分来实现，例如，在图6中的框322或图7中的框372处。一般而言，当通知进入系统时，对当前为真的所有环境进行评估，并且，根据用户的当前状态来将最具限制性的设置应用于该通知。如图9中所示的，在判定框402处，确定是否根本不应该绘制通知。如果通知将根本不被绘制，则该例程前进到框404，在那里，将通知设置成不被绘制在任何显示器上。如果通知将被绘制，则该例程前进到判定框406。
在判定框406处，确定是否应该但只在外部绘制通知。如果通知将只在外部被绘制，则该例程前进到框408，在那里，绘制该通知，但只绘制在外部硬件显示器上。如果通知将不被绘制在外部硬件显示器上，则该例程前进到判定框410。
在判定框410处，确定是否应该在当前显示器上绘制通知。如果通知将要被绘制在当前显示器上，则该例程前进到框412，在那里，根据适当的侵入等级在当前显示器上绘制通知。如果通知将不被绘制在当前显示器上，则该例程结束。
图10是流程图，示出了用于根据各种限制来确定将为通知的声音而播放的音量的例程420。如以上根据图9所描述的，将会理解，该例程可以作为通知处理的一部分来实现，例如，在图6的框322或图7的框372处。当通知进入系统时，对当前为真的所有环境进行评估，并且，根据用户的当前状态来将最具限制性的设置应用于通知。如图10中所示的，在判定框422处，确定是否应该将通知静音。如果通知将要被静音，则该例程前进到框424，在那里，不为该通知提供音量。如果通知将不被静音，则该例程前进到判定框426。
在判定框426处，确定是否应该为通知提供某个百分比的音量，但小于全音量。如果将要提供某个百分比音量，则该例程前进到框428，在那里，按指定的百分比音量来播放通知。如果将不提供指定的百分比音量，则该例程前进到判定框430。
在判定框430处，确定是否应该为通知提供全音量。如果将要提供全音量，则该例程前进到框432，在那里，按该全音量级来播放通知。如果将不提供全音量，则该例程结束。在一个实施例中，除了为通知规定不同的音量级以外，也可以根据用户环境和规则来为通知选择不同的声音。
将会理解，如以上根据图1-10而描述的本发明控制来自各种来源的通知的递送，以便这些通知停止彼此之间的冲突，因为该系统适当地代理并串行化其屏幕上的呈现。此外，本发明所提供的通知可以被认为更有价值，因为它们是在用户更易于接收它们时递送的；此外，公用规则的运用帮助用户排除不合需要的通知。
已示出和描述本发明的较佳实施例，但将会理解，在不脱离本发明的精神和范围的前提下，可以在其中进行各种更改。
权利要求
1.在将通知递送给用户的计算机系统中，一种用于控制所述通知的递送的方法，其特征在于，包括声明可以处于至少第一或第二状态的第一条件；提供第一递送指令，当所述第一条件被确定为处于其第一状态时，执行所述第一递送指令用于控制所述通知递送；以及从多个来源接收通知，并在所述第一条件被确定为处于其第一状态时，根据所述第一递送指令来控制所述通知的递送。
2.如权利要求1所述的方法，其特征在于，所述第一条件是用户环境的一部分，所述用户环境意在至少部分地指示用户对于接收通知的当前可用性。
3.如权利要求1所述的方法，其特征在于，当所述第一条件处于其第一状态时，它表示用户可以至少部分地在视觉上被占用，并且，所述第一递送指令按照其视觉显示来限制通知。
4.如权利要求1所述的方法，其特征在于，当所述第一条件处于其第一状态时，它表示用户可以至少部分地被声音占用，并且，所述第一递送指令按照其音量来限制所述通知递送。
5.如权利要求1所述的方法，其特征在于，当所述第一条件处于其第一状态时，它表示用户对于接收任何种类的通知可以是不可用的，并且，所述第一递送指令完全限制所述通知递送。
6.如权利要求1所述的方法，其特征在于，使所述第一递送指令对用户可用，用于根据用户的偏好来进行修改。
7.如权利要求1所述的方法，其特征在于，使所述第一条件对用户可用，以便可以关闭它，在此情况下，即使所述第一条件处于其第一状态，也不会遵循所述第一递送指令。
8.如权利要求1所述的方法，其特征在于，对于所述第一条件，其第一状态是当它为真时，其第二状态是当它为假时。
9.如权利要求1所述的方法，其特征在于，所述第一条件的状态最初是在声明所述第一条件的时候被确定的。
10.如权利要求1所述的方法，其特征在于，所述第一条件的状态是在将要递送通知的时候被确定的。
11.如权利要求1所述的方法，其特征在于，所述第一条件是由操作系统来声明的。
12.如权利要求1所述的方法，其特征在于，所述第一条件是由除操作系统以外的来源来声明的。
13.如权利要求12所述的方法，其特征在于，所述除操作系统以外的来源是程序。
14.如权利要求11所述的方法，其特征在于，声明可以处于至少第一或第二状态的第二条件，并且，提供第二递送指令，当所述第二条件处于其第一状态时，执行所述第二递送指令，用于控制所述通知递送。
15.如权利要求14所述的方法，其特征在于，声明附加条件，并向所述附加条件提供附加的对应递送指令。
16.如权利要求15所述的方法，其特征在于，所述条件是由操作系统和程序集来声明的。
17.如权利要求1所述的方法，其特征在于，还包括定义第一规则，所述第一规则规定如何控制至少包含第一指定元素的通知的递送。
18.如权利要求17所述的方法，其特征在于，定义附加规则，并且，当两个规则发生冲突时，应用更具侵入性的规则。
19.如权利要求17所述的方法，其特征在于，所述第一规则是由用户来声明的。
20.如权利要求19所述的方法，其特征在于，所述附加规则是由用户来声明的。
21.如权利要求20所述的方法，其特征在于，使所述规则对用户可用，用于根据用户的偏好来进行修改。
22.如权利要求1所述的方法，其特征在于，所述第一递送指令包括路由、拒绝、推迟、或递送通知中的至少一项。
23.一种具有计算机可执行组件的计算机可读介质，所述计算机可执行组件用于实现一种用于控制通知递送的方法，包括声明可以处于至少第一或第二状态的第一条件；提供第一递送指令，当所述第一条件被确定为处于其第一状态时，执行所述第一递送指令，用于控制所述通知递送；以及从多个来源接收通知，并在所述第一条件被确定为处于其第一状态时，根据所述第一递送指令来控制所述通知的递送。
24.如权利要求23所述的方法，其特征在于，所述第一条件是用户环境的一部分，所述用户环境意在至少部分地指示用户对于接收通知的当前可用性。
25.如权利要求23所述的方法，其特征在于，所述第一个递送指令包括路由、拒绝、推迟、或递送通知中的至少一项。
26.如权利要求23所述的方法，其特征在于，所述第一递送指令按照其视觉显示来限制所述通知递送。
27.如权利要求23所述的方法，其特征在于，所述第一递送指令按照其音量来限制所述通知递送。
28.如权利要求23所述的方法，其特征在于，使所述第一递送指令对用户可用，用于根据用户的偏好来进行修改。
29.如权利要求23所述的方法，其特征在于，对于所述第一条件，其第一状态是当它为真时，其第二状态是当它为假时。
30.如权利要求23所述的方法，其特征在于，所述第一条件是由操作系统来声明的。
31.如权利要求30所述的方法，其特征在于，可以处于至少第一或第二状态的第二条件是由除操作系统以外的来源来声明的，并且，提供第二递送指令，当所述第二条件处于其第一状态时，执行所述第二递送指令，用于所述通知的递送。
32.如权利要求31所述的方法，其特征在于，声明所述第二条件的来源是程序。
33.如权利要求23所述的方法，其特征在于，还包括定义第一规则，所述第一规则规定如何控制至少包含第一指定元素的通知的递送。
34.如权利要求33所述的方法，其特征在于，定义附加规则，并且，当两个规则发生冲突时，应用更具侵入性的规则。
35.如权利要求33所述的方法，其特征在于，所述第一规则是由用户来声明的。
36.如权利要求35所述的方法，其特征在于，使所述第一规则和所述第一递送指令对用户可用，用于根据用户的偏好来进行修改。
37.在将通知递送给用户的计算机系统中，一种用于控制所述通知的递送的方法，其特征在于，包括声明多个用户环境，每个用户环境包括可以为真或假的条件，以及如果所述条件为真则要遵循的指令；从多个来源接收通知；以及当用户环境的所述条件为真时，遵循对应于所述用户环境的指令，用于确定应该对所述通知采取什么措施。
38.如权利要求37所述的方法，其特征在于，所述指令包括路由、拒绝、推迟、或递送通知中的至少一项。
39.如权利要求37所述的方法，其特征在于，使所述指令对用户可用，用于根据用户的偏好来进行修改。
40.如权利要求37所述的方法，其特征在于，所述多个用户环境的至少一个是由操作系统来声明的。
41.如权利要求37所述的方法，其特征在于，所述多个用户环境的至少一个是由除操作系统以外的来源来声明的。
42.如权利要求41所述的方法，其特征在于，所述除操作系统以外的来源是程序。
43.如权利要求37所述的方法，其特征在于，还包括定义多个用户规则，所述多个用户规则规定如何控制包含对应于每个规则的指定元素的通知的递送。
44.如权利要求43所述的方法，其特征在于，当两个用户规则发生冲突时，应用更具侵入性的规则。
45.如权利要求44所述的方法，其特征在于，所述用户规则是由用户来声明的。
46.如权利要求45所述的方法，其特征在于，使所述用户环境和用户规则对用户可用，用于根据用户的偏好来进行修改。
47.一种具有计算机可执行组件的计算机可读介质，所述计算机可执行组件用于实现一种用于控制通知递送的方法，包括声明多个用户环境，每个用户环境包括可以为真或假的条件，以及如果所述条件为真则要遵循的指令；从多个来源接收通知；以及当用户环境的所述条件为真时，遵循对应于所述用户环境的指令，用于确定应该对所述通知采取什么措施。
48.如权利要求47所述的方法，其特征在于，所述指令包括路由、拒绝、推迟、或递送通知中的至少一项。
49.如权利要求47所述的方法，其特征在于，使所述指令对用户可用，用于根据用户的偏好来进行修改。
50.如权利要求47所述的方法，其特征在于，所述多个用户环境的至少一个是由操作系统来声明的。
51.如权利要求47所述的方法，其特征在于，所述多个用户环境的至少一个是由除操作系统以外的来源来声明的。
52.如权利要求51所述的方法，其特征在于，所述除操作系统以外的来源是程序。
53.如权利要求47所述的方法，其特征在于，还包括定义多个用户规则，所述多个用户规则规定如何控制包含对应于每个规则的指定元素的通知的递送。
54.如权利要求53所述的方法，其特征在于，当两个用户规则发生冲突时，应用更具侵入性的规则。
55.如权利要求54所述的方法，其特征在于，所述用户规则是由用户来声明的。
56.如权利要求55所述的方法，其特征在于，使所述用户环境和用户规则对用户可用，用于根据用户的偏好来进行修改。
57.一种用于控制通知递送的系统，其特征在于，包括用于声明可以处于至少第一或第二状态的第一条件的装置；用于提供第一递送指令的装置，当所述第一条件被确定为处于其第一状态时，执行所述第一递送指令，用于控制所述通知递送；以及用于从多个来源接收通知，并在所述第一条件被确定为处于其第一状态时根据所述第一递送指令来控制所述通知的递送的装置。
58.如权利要求57所述的系统，其特征在于，还包括用于使所述第一递送指令对用户可用，以便根据用户的偏好来进行修改的装置。
59.如权利要求57所述的系统，其特征在于，还包括用于在声明所述第一条件时确定所述第一条件的状态的装置。
60.如权利要求57所述的系统，其特征在于，还包括用于在将要递送所述通知时确定所述第一条件的状态的装置。
61.如权利要求57所述的系统，其特征在于，还包括用于定义第一规则的装置，所述第一规则规定如何控制至少包含第一指定元素的通知的递送。
62.如权利要求57所述的系统，其特征在于，还包括用于执行所述递送指令的装置，所述递送指令包括路由、拒绝、推迟、或递送通知中的至少一项。
63.一种用于控制通知递送的系统，其特征在于，包括用于声明多个用户环境的装置，每个用户环境包括可以为真或假的条件，以及如果所述条件为真则要遵循的指令；用于从多个来源接收通知的装置；以及当用户环境的所述条件为真时，遵循对应于所述用户环境的指令，用于确定应该对所述通知采取什么措施。
64.如权利要求63所述的系统，其特征在于，还包括用于执行指令的装置，所述指令包括路由、拒绝、推迟、或递送通知中的至少一项。
65.如权利要求63所述的系统，其特征在于，还包括用于使所示指令对用户可用，以便根据用户的偏好来进行修改的装置。
66.如权利要求63所述的系统，其特征在于，还包括用于定义多个用户规则的装置，所述多个用户规则规定如何控制包含对应于每个规则的指定元素的通知的递送。
67.如权利要求63所述的系统，其特征在于，还包括用于使所述用户规则对用户可用，以便根据该用户的偏好来进行修改的装置。
全文摘要
一种用于控制通知的递送的系统(200)。该系统代理并串行化来自多个来源的通知的递送(206)。此外，提供用户环境的共享概念，用于为这些通知中的每一个确定适当的处理。在一个实施例中，用户环境包括可以为真或假的条件，以及如果条件为真则要遵循的指令。例如，如果用户正在收听音乐，则指令可以在屏幕上显示通知，但不为该通知播放任何声音。用户环境由操作系统和任意程序来声明(204)。可以向用户呈现用户的环境，用于根据用户的偏好来进行修改(204)。用户也可以定义规则，它们规定应该如何处理包含指定元素的通知(204)；并且可以为用户环境的指令提供例外。
文档编号G06Q10/00GK1759377SQ03826214
公开日2006年4月12日 申请日期2003年5月15日 优先权日2003年3月26日
发明者T·P·麦基, F·A·德布里, C·K·范多克, R·K·温吉姆 申请人:微软公司