CN101272261A

CN101272261A - 用于调解用户对呈献媒体的注意力的系统和方法

Info

Publication number: CN101272261A
Application number: CNA2008100080015A
Authority: CN
Inventors: 彼得·弗朗西斯·库斯; 托马斯·A·格雷
Original assignee: Mitel Networks Corp
Current assignee: Mitel Networks Corp
Priority date: 2007-03-01
Filing date: 2008-02-29
Publication date: 2008-09-24
Also published as: CA2619197A1; US20080215745A1; EP1965563A3; CA2619197C; EP1965563A2

Abstract

提供了用于在多个呈献媒体之间调解用户的注意力的系统和方法，包括：流式媒体应用，用于向用户提供媒体流；通知系统，用于生成中断的通知；以及流式媒体管理器，用于接收所述通知，并且作为响应使流式媒体应用自动暂停媒体流或者为媒体流设置书签，以帮助在中断之后继续媒体流。

Description

用于调解用户对呈献媒体的注意力的系统和方法

技术领域

本发明一般地涉及通信系统，更具体而言涉及用于在多个呈献媒体(presentational media)之间调解(mediate)用户注意力的系统和方法。

背景技术

当前多媒体通信的发展为新型工作方式提供了巨大的机会。用户能够使用多种模式来访问信息并与其同事进行交互。例如，诸如VoIP之类的同步应用使得同事之间可以进行实时会话。诸如电子邮件和语音邮件之类的异步应用使得交互可以在一段时间中发生，诸如即时消息收发(IM)之类的半同步应用使得交互可以几乎实时地发生。

这些各种应用的益处部分地与在任何给定时间用户能够给予应用的注意程度相关。诸如VoIP之类的同步应用需要用户的几乎全部注意力，而诸如电子邮件之类的异步交互则只需要较低级别的注意力。从而，注意程度有限的繁忙用户将会基于其注意程度来划分事务。紧急且重要的事务一般需要用户的全部注意力。因而诸如VoIP之类的模式就有理由被用于这样的事务。不那么重要的事务对用户注意力的需求较低，因此可以在更重要的事务当前不那么紧要的时候开始从事。可以随时关注的电子邮件就很适合这种事务。

因而，在一天之中，典型的用户将会利用与各种事务的重要性应当得到的注意程度相适应的模式来在各种事务之间划分其注意力。

新一代的使用流式传输(streaming)的呈献应用使得用户更加难以在多种模式之间划分注意力。这种呈献应用包括基于web的向导和电子邮件的媒体附件，其中任一个可以是完全多媒体呈献(presentation)(例如基于web的向导)或者单媒体呈献(例如年度股东大会的音频/视频记录)。这些呈献不能被分类成次要的(例如背景音乐)，但是在被访问时就要求用户的全部注意力。但是，如上所述，对这些素材的访问可能被更加紧急的事务所中断。访问年度股东大会的记录的股票分析人可能被来自客户的紧急呼叫所中断。查看基于web的向导的工程师可能被来自其个人电子日志的、告知他必须参加会议的通知所中断。

目前，当发生这种中断时，用户必须使流式媒体(streaming media)呈献静音或者手动停止或暂停流式媒体呈献。处理诸如呼叫电话这样的中断并同时控制流式媒体应用将会是困难的。结果，流式媒体经常会在用户分心的同时仍在播放，其结果是一旦用户能够使其注意力返回到流式媒体呈献，他/她就必须搜索呈献中其注意力被中断的位置。

发明人已经认识到，需要提供一种机制，用于控制干扰用户注意力的各种应用和系统，以使得诸如呈献之类的应用可以无需用户搜索就能继续开始。

现有技术中已知，为了判定所提议的通信是否重要到足以应当中断用户的注意力而对用户的当前上下文情况进行评定(参见Pinard的题为“Dialable Screening”的美国专利6,363,140，其内容通过引用结合于此)。用户的当前内容方面可包括位置和角色关系。Gray等人的题为“Context Aware Call Handling System”的美国专利公布2005/0100157(其内容通过引用结合于此)公开了各种类型的推理，这些推理用于确定用户上下文情况，以选择最适当的用户策略来处理传入的电话呼叫和其它干扰通信。但是，这两个现有技术方法都没有解决与如上所述的呈献应用交互的问题。

发明内容

根据本发明的一个方面，提供了用于在多个呈献媒体之间调解用户的注意力的系统和方法。在一个实施例中，提供了流式媒体管理器，用于响应于来自如美国专利公布2005/0100157中所述的上下文知晓呼叫处理系统(context aware call processing system)、电子邮件系统或其它通知系统中的一个或多个的通知而控制流式媒体应用的操作。在接收到这种关于即将发生的用户中断(例如使用户的电话呼叫振铃、传入的电子邮件警告等等)的通知后，流式媒体管理器使流式媒体应用或者立即停止以便用户能够从中止点起继续开始播放，或者在中止处存储书签以便用户能够很容易地定位到该点并从该点起继续开始播放。

附图说明

现在将参考附图仅通过示例方式来描述本发明的实施例，附图中：

图1是本发明的实施例与之结合工作的上下文知晓呼叫处理系统的硬件实现方式的框图；

图2示出了图1的系统的系统体系结构和模块交互；

图3是图2的服务器模块的类图(class diagram)；

图4是图2的客户端模块的类图；

图5是根据本发明优选实施例的系统的框图；以及

图6是根据优选实施例的示出图5的系统的操作方法的步骤的流程图。

具体实施方式

首先参考图1，其中示出了根据美国专利公布2005/0100157(其内容通过引用结合于此)的上下文知晓呼叫处理系统。

图1的系统基于客户端-服务器体系结构。主动呼叫递送(ACD，Active Call Delivery)客户端21与ACD服务器27通信，ACD服务器27进而又与TSpaces服务器23和MiTAI网关服务器25通信。MiTAI网关服务器25经由PBX 26提供对PSTN 28的接入。ACD服务器27是能够访问TSpaces服务器23的单个服务器或多个服务器。ACD服务器27由用户界面和下文参考图3来更详细论述的“系统代理”的集合组成。用户界面提供介绍窗口、系统管理员的登录窗口、用于管理上下文层次体系的上下文窗口以及用于模拟电话呼叫的呼叫模拟窗口。每个系统代理都有助于呼叫处理，并且具有其自己的职责：关系指定(RA，Relationship Assigning)代理负责获取主叫者与被叫方之间的关系，并将其指定给相关数据字段以用于呼叫处理。用户规则指定(URA)代理负责根据当前上下文和每条规则的条件来提取所有的匹配用户规则，并将它们指定给相关数据字段以用于呼叫处理。用户规则冲突解决(UCR，User-rule Conflict Resolving)代理负责解决所指定的规则中可能存在的任何冲突。如上所述，这些代理不一定要被安装在特定的机器上，而是可以分布在能够访问TSpaces服务器23的机器的网络中。

ACD客户端21由用户界面和用户代理组成。用户界面提供介绍窗口、注册系统用户的登录窗口以及新用户的注册窗口。知识管理是客户端系统上的用户界面的一个重要部分。用户可以创建或管理诸如好友列表、关系信息、日程和用户偏好规则之类的个人信息。客户端服务器利用下文将参考图4来更详细论述的两类代理：呼叫递送(CD)代理和系统管理(SM)代理。CD代理确认TSpaces服务器23中由呼叫监视器生成的事件。呼叫监视器是与MiTAI网关25的直接接口，并且创建被馈送到TSpaces服务器23中的事件用于启动CD代理的呼叫处理。接下来，SM代理确认来自CD代理的事件，并且将呼叫处理分布到网络上的代理。虽然各个代理具有不同的服务，但是服务器和客户端都有某些根据惯常的面向对象设计的共同模块。这些共同对象模块和其他模块在下文说明。

图2示出了图1的上下文知晓呼叫处理系统的系统体系结构和模块交互。用户界面31由用于提供用户登录、注册、用户偏好规则设置、上下文模拟和用于辅助用户的消息的显示的窗口、表单(form)、菜单和按钮组成。

事件处理机子系统23是位于用户界面31和应用级子系统35之间的监视后台程序(daemon)。它等待来自用户界面31的物理事件(例如鼠标点击)，并将它们引导到适当的应用模块。开发工具Java提供了用于此目的的嵌入式事件处理机，例如ActionListener。

应用级35是系统的核心。它由多个代理组成，这些代理为客户端和服务器提供服务。所有的系统事务、功能和知识管理都是在这个子系统内执行的。

如图3的类图所示，服务器模块38被划分成三个主要部分：系统知识管理39、代理服务41和呼叫模拟43。系统知识管理模块39包括上下文集合子模块45，用于使授权管理者可以创建或修改诸如位置和活动之类的上下文层次体系。代理服务模块41由三个不同的代理模块组成：关系指定(RA)代理47、用户规则指定(URA)代理49和用户规则冲突解决(UCR)代理51。为了提供灵活的代理实现，对代理的状态进行管理以获知它们的可用性。网络连通性可影响它们的可用性。因此，为了使用代理，该代理以及该代理与系统的TSpaces 23之间的连接都必须能够起作用。系统通过检查TSpaces 23中的相应状态元组(status tuple)来获取代理的状态。状态元组由“名称”、“优先级”和“可用性”字段组成。每个代理负责更新其在TSpaces 23中的状态元组。更新状态元组的过程由以下步骤组成：优选每秒一次地取得状态元组并且用新的状态信息来覆写它。元组可被设置为在预定时间之后期满。在期满后，TSpaces服务器23将元组从TSpaces 23中去除。状态元组的期满时间优选为3秒，因此如果代理由于任何原因连续三次都未能更新元组，则在TSpaces 23将没有相应代理的状态元组。如果没有某个代理的状态元组或者如果状态元组中的“可用性”字段被设置为“异常”，系统则假定该代理发生异常。更新状态元组所花费的1秒与状态元组期满前允许的3秒之间的时间差距可以防止由于暂时的网络干扰而导致不必要的状态切换。

每个代理还负责将事件注册到TSpaces 23中以与客户端机器通信。每当等待的元组被写入元组空间中时，TSpaces服务器23就将此通知给注册事件的代理。生成事件和获得来自TSpaces 23的事件通知形成了代理之间的双向通信-确认。

关系指定(RA)代理47负责对来自下文将参考图4来论述的客户端的系统管理(SM)代理的关系指定请求作出响应。来自SM代理的请求包含主叫者和接收者信息。RA代理47根据用户的好友列表来指定用户和主叫者之间的关系。

用户规则指定(URA)代理49负责对来自客户端的SM代理的用户规则指定请求作出响应。在被请求时，URA代理49检索关系信息和用户的当前上下文情况。关系信息是RA代理47所设置的主叫者与被叫方或接收者之间的关系。用户的当前上下文情况是用户的位置、用户日程的当前时间和用户的活动。

用户规则冲突解决(UCR)代理51负责对客户端SM代理的用户规则冲突解决请求作出响应。该请求包含URA代理49所指定的用户规则信息。UCR代理51选择所指定的规则中最具体的一条规则。规则具有的条件越多，该规则就被认为越具体。呼叫模拟服务43是用来在不连接到MiTAI网关25的情况下进行测试的。具有表单的窗口提供此功能。

如图4的客户端模块类图所示，客户端模块被划分成三个子系统：用户知识管理53、代理服务55和上下文模拟57。用户可以通过用户知识管理模块53来操纵个人知识。

呼叫递送(CD)代理59负责通过MiTAI网关25与电话交换机或PBX 26通信。具体而言，CD代理59向MiTAI网关25注册事件并且等待针对用户的传入呼叫的通知。当通知到达时，CD代理59向SM代理61发送对进一步处理的请求并且等待响应。来自SM代理61的这个响应包含作为整个呼叫处理的结果而将要采取的动作。CD代理59随后负责向MiTAI网关25请求所选的动作。

系统管理(SM)代理61负责管理其他代理的状态并根据系统代理的优先级来对呼叫处理排序。当CD代理59请求呼叫处理时，SM代理61对TSpaces 23中的代理状态元组进行扫描并根据它们的优先级制作顺序表。它向优先级最高的代理发送处理请求，等待响应，然后将其发送到优先级次高的代理。当SM代理61接收到来自优先级最低的代理的响应时，它将信息元组发送回CD代理59。

上下文模拟模块57充当动态地检测、解释和更新用户的当前上下文情况的上下文代理。上下文模拟窗口包括系统管理员设置的所有可能的上下文，用户从中进行选择。

用户知识管理子系统53允许用户建立并维护好友列表集合63、关系集合65、日程集合67和用户规则集合69。

TSpaces 23(即元组空间)在一个或多个服务器23中实现，作为具有数据库能力的网络通信缓冲器。对TSpaces 23的更完整描述可在Gray等人的题为“Processing by Use of Synchronized Tuple Spaces and Assertions”的美国未决专利公布No.2006/0242256中找到，该专利公布的内容通过引用结合于此。TSpaces 23实现了在不同的计算机和操作系统的网络中的应用和设备之间的通信。TSpaces 23提供了群组通信服务、数据库服务、基于URL的文件传送服务和事件通知服务。TSpaces 23是用Java编程语言实现的，因而自动地具备独立于平台的网络普遍性以及用于所有数据类型的标准表示类型。TSpaces系统适合于具有分布或数据存储要求的任何应用。它可以执行关系数据库系统的许多任务，而不会强加限制过多(且原始)类型的系统、僵化的方案、拙劣的用户界面或苛刻的运行时存储器要求。在本发明中，TSpaces服务器23是系统和用户知识存储装置之间的介质。但是，将会理解，TSpaces 23可由提供用于管理包括读、写、更新、取得和扫描在内的知识事务以及诸如事件注册和通知之类的事件处理的等同功能的关系数据库或其他共享数据库所取代。

MiTAI网关25帮助不基于“C”开发语言的进程与电话服务器(例如PBX 26)通信。MiTAI网关25是基于

的进程，其可以在任何Windows平台上执行。它可以管理来自网络上的任何其它进程的单个套接字连接并且它支持有限会话协议。MiTAI网关服务器25是PBX26和ACD的应用级子系统35之间的中间系统。应用级子系统35向MiTAI网关服务器25注册事件以监视传入的呼叫。

就系统拓扑而言，用户界面31是构建在

平台上的，并且它通过事件处理机33来与应用级35交互。应用级子系统35使用TSpaces服务器23作为用于通信并且访问服务器和客户端的系统知识管理的介质。

包括用户信息、用户规则、用户的当前上下文信息和呼叫信息在内的所有知识都存储在TSpaces 23中。存储单位是元组，如以上所引用的参考文献所述。

图1-4和US20050100157中公开的系统(Mitel 544)只例示了能够用于本发明的实现方式中的通知系统的一个实施例，而并不意图限制本发明的应用范围，本发明的应用范围将在下文更详细论述并且由所附权利要求限定。

在操作中，PBX 26处理传入的呼叫，包括多媒体呼叫。因而，针对特定用户(例如图1中的用户1)的呼叫被PBX 26报告给呼叫递送代理59，呼叫递送代理59将关于呼叫的断言(assertion)放到TSpaces元组空间23中。系统管理代理61处理系统中的行为排序。关系指定代理(RAA)47收集关于呼叫的信息和来自其它来源的关于用户角色和关系的信息，以便将传入呼叫适配在用户的上下文内。例如，如果CDA 59放出传入呼叫来自特定电话号码(例如基于主叫者ID信息)的断言，则RRA47可确定电话号码例如是图1中的用户n的，并且用户n既是用户1的同事而且又在与用户1合作项目。RRA 47将所有这些信息都作为断言放到元组空间23中。上下文代理(例如上下文模拟模块57)将关于用户1的当前活动的各种断言(例如位置、其正在操作的文档等等)放到元组空间23中。用户1利用其用户界面31来建立的各种策略确定了在各种上下文情况中应当如何来处理呼叫。这些策略由用户规则指定代理(UAA)49根据存储在元组空间23中的关于呼叫和用户当前上下文情况的信息来评定。经常有这种情况，即，多个策略可以适用任何一个上下文情况。因此，用户规则冲突解决代理51确定最适当的策略并且将其报告给呼叫递送代理59。CDA 59随后指示PBX 26根据该适当的策略来处理呼叫(例如将呼叫转发到用户1的电话以使之振铃，从而干扰用户1的注意力)。

现在参考图5和6，其中分别示出了本发明实施例的框图和流程图。上下文知晓呼叫处理系统71例如可以如图1-4中所述，其中CDA 59被编程为向流式媒体管理器73(SMM)发送通知(步骤81)，此时PBX 26被指示执行将会使用户的电话振铃或者以其他方式中断其注意力的活动。SMM 73可位于ACD服务器27上，或者网络内的其它地方。在接收到通知后，SMM 73将此事件通知给流式媒体应用75(步骤83)。SMA 75优选但并不必须位于客户端21上。由于SMM 73必须知晓代表用户运行的媒体应用，因此SMA 75最好在启动时向SMM 73注册。但是，可以使用其它方法，例如让用户或管理员对SMM 73编程以便识别SMA 75。

响应于接收到来自SMM 73的通知，SMA 75或者立即暂停呈献的流式传输或者存储书签，以使得用户可以从通知被递送的时间起重新启动呈献(步骤85)。

因此，根据本发明，诸如电话呼叫警告(例如振铃)之类的可能中断用户注意力的事件以改善对他/她的注意力的干扰的方式与用户的流式媒体应用75相耦合。

如图5所示，能够干扰用户注意力的其它系统可与SMM 73相耦合。这些系统包括警告用户要留心传入了重要的电子邮件的电子邮件系统77，或者提供用户通知的其它系统，例如个人日志系统、存在系统(例如用于警告用户要留心访问者到达等等)。

还设想了其他实施例，其中，例如，SMM 73通过模拟一个或多个遗留的(legacy)流式媒体应用所期望的控制类型而与这些应用相耦合。例如，SMM 73可模拟用于流式传输应用的控制器上的按钮按压。另外，设想到SMM 73不需要实现为分立的实体，而可结合在通知系统71、77和/或79的每一个中。不需要在生成通知之前进行对通信尝试的优先级或重要性的评估，从而使得所有通信尝试都被报告给SMM 73。SMM 73可以不将通知推给SMA 75，而SMA 75可以调查或以其它方式从SMM 73拉出信息。SMA 75可直接被结合到PBX 26中，或者位于客户端21内，如上所述。

注意，虽然上述示例涉及基于网络的媒体源，但是本领域的普通技术人员将会认识到，这里所指的媒体可包括本地源。例如，音乐或会议的记录的MP3文件可被下载到本地存储设备(例如客户端PC 21的硬盘)并在本地被播放。根据本发明的系统和方法同样可应用到来源于网络外部或者计算机或其它设备本地的媒体。另外，应当注意，本发明还适用于来自CD、MP3播放器的或其他格式的音频的本地或联网呈献。

在所附权利要求所限定的本发明的范围内可实现本发明的其它实施例。

Claims

1.一种用于在多个媒体之间调解用户的注意力的方法，包括：

向所述用户提供媒体流；

接收中断的通知；以及

自动暂停所述媒体流或者为所述媒体流设置书签，以帮助在所述中断之后继续所述媒体流。

2.如权利要求1所述的方法，其中所述中断包括使电话振铃。

3.如权利要求1所述的方法，其中所述中断包括传入的电子邮件。

4.如权利要求1所述的方法，其中所述中断包括个人日志提醒。

5.如权利要求1所述的方法，其中所述中断包括会议提醒。

6.如权利要求1所述的方法，其中所述中断包括访问者通知。

7.如权利要求1所述的方法，其中向所述用户提供媒体流的步骤包括通过因特网来流式传输所述媒体。

8.如权利要求1所述的方法，其中向所述用户提供媒体流的步骤包括从电子邮件中提取所述媒体并启动播放器来呈献所述媒体。

9.一种用于在多个媒体之间调解用户的注意力的系统，包括：

流式媒体应用，用于向所述用户提供媒体流；

通知系统，用于生成中断的通知；以及

流式媒体管理器，用于接收所述通知，并且作为响应使所述流式媒体应用自动暂停所述媒体流或者为所述媒体流设置书签，以帮助在所述中断之后继续所述媒体流。

10.如权利要求9所述的系统，其中所述通知系统包括上下文知晓呼叫处理系统。

11.如权利要求9所述的系统，其中所述通知系统包括电子邮件系统。

12.如权利要求9所述的系统，其中所述通知系统包括个人日志系统。

13.如权利要求9所述的系统，其中所述通知系统包括用于警告所述用户要留心访问者到达的存在系统。

14.如权利要求9所述的系统，其中所述流式媒体应用是遗留流式媒体应用，并且所述流式媒体管理器模拟其控制输入。

15.如权利要求14所述的系统，其中所述流式媒体管理器模拟用于所述遗留流式媒体应用的控制器上的按钮按压。

16.如权利要求9所述的系统，其中所述流式媒体管理器和所述通知系统是集成一体的。

17.如权利要求9所述的系统，其中所述流式媒体管理器通过将进一步的通知推给所述流式媒体来使所述流式媒体应用自动暂停所述媒体流或为所述媒体流设置书签。

18.如权利要求9所述的系统，其中所述流式媒体管理器通过提供被所述流式媒体拉出的进一步的通知来使所述流式媒体应用自动暂停所述媒体流或为所述媒体流设置书签。

19.如权利要求9所述的系统，其中所述流式媒体应用、所述通知系统和所述流式媒体管理器是在PBX内实现的。

20.如权利要求9所述的系统，其中所述流式媒体应用从网络源接收所述媒体。

21.如权利要求9所述的系统，其中所述流式媒体应用从本地源接收所述媒体。

22.如权利要求9所述的系统，其中所述媒体是音频。

23.如权利要求9所述的系统，其中所述媒体是可视的。

24.如权利要求9所述的系统，其中所述媒体是视听媒体。

25.如权利要求9所述的系统，其中所述媒体是音乐。