CN101547217A - 用于管理上下文的方法、系统和装置 - Google Patents

Abstract

本发明提供了用于管理上下文的方法、系统和装置。当前上下文被确定。判断在共享存储器中是否存在与当前上下文相关联的上下文对象，如果没有，则在共享存储器中创建所述上下文对象。在当前上下文活动时收集与当前上下文相关联的数据。与当前上下文相关联的数据被存储在与当前上下文相关联的上下文对象中。

Description

用于管理上下文的方法、系统和装置

技术领域

本发明一般地涉及通信系统，更具体而言，涉及用于管理上下文(context)的方法、系统和装置。

背景技术

企业(例如公司和/或组织)的工作可以分成正规和非正规的部分。正规工作由商业过程(business process)来规定。非正规工作用于管理这些过程。但是，人员(例如管理者)通常发现要想管理关于日常解决的大量问题的信息是很艰难的，并且还发现同事之间在这些问题上的协作也是很有挑战性的。

例如，人员通常需要将他们的注意力分配到组织中具有不同紧急性的多个问题，并且他们通常还必须在常规的正规商业过程和工作流之外进行活动，从而在问题出现时逐件地处理和解决这些问题。跟踪各种正被管理的问题的工作变得很有挑战性。在具体示例中，在单个会话中，组织的两个成员可能讨论/管理彼此可能相关或不相关的若干不同问题。此外，对于政策性问题的考虑可能不得不被推迟以处理紧急问题，例如停产或放弃客户。在这些情况下，人员通常不具有计划日程的闲情逸致，以便能够仔细地准备每项任务。相反地，他们必须能够动态地评估情况并将注意力转移到当前最重要的问题，从而在相互竞争的请求之间设置优先级以用更高注意力处理最急迫的问题。在此过程中，人员通常将注意力从一个问题转移到另一个，并因此组织的成员必须能够快速熟悉新问题。此外，他们必须能够刷新他们关于已经撇开的问题的记忆，并且能够获知从其上次接手时起已经发生的进展。

虽然客户关系管理(CRM)系统能够解决这些问题中的一些，但是，它们大多致力于维护与客户之间的关系：当客户要求买进时，代理获得屏幕弹出收益承销公告(tombstone)(姓名、地址等等)数据以及该客户与该组织早先的交互历史，例如早先的购买或为解决问题而进行的交互。代理进而基于这些早先的交互获得一脚本(script)。虽然该信息帮助代理处理买进，但是一般不要求代理与客户的商业上下文相关地判断买进，换言之，CRM大大有助于正规过程，但是对非正规过程没有帮助。CRM也不能帮助代理管理组织内的问题。

发明内容

本说明书的第一方面提供了一种管理上下文的方法。该方法包括确定当前上下文。该方法还包括判断在共享存储器中是否存在与当前上下文相关联的上下文对象，如果没有，则在共享存储器中创建所述上下文对象。该方法还包括在当前上下文活动时收集与当前上下文相关联的数据。该方法还包括将与当前上下文相关联的数据存储在与当前上下文相关联的上下文对象中。

确定当前上下文可以基于通信会话、位置和日程中的至少一种。当确定当前上下文是基于通信会话时，确定当前上下文可以包括确定与通信会话相关联的两个用户之间的至少一个先前通信会话的上下文。

确定当前上下文可以响应于计算设备控制显示设备显示对当前上下文的请求的表示而基于经由输入设备接收的输入数据。对当前上下文的请求可以包括至少一个潜在当前上下文的列表，所述至少一个潜在当前上下文的列表是通过处理共享存储器中的至少一个现有上下文对象而确定的，并且输入数据包括来自所述列表的第一选择。该方法还包括接收指示来自所述列表的第二选择将被删除的输入数据，并且作为响应，删除与所述第二选择相关联的上下文对象。对当前上下文的请求可以包含输入当前上下文的名称的请求，并且输入数据包括包含所述名称的文本数据。

确定当前上下文可以是基于对通信会话的邀请中的上下文头部。所述邀请可以包括SIP邀请。

确定当前上下文可以包括确定初始当前上下文的“最佳猜测”。

确定当前上下文可以包括从自动系统接收上下文指示，所述自动系统被使能为创建上下文以辅助所述自治系统调度至少一个用户的动作。

所述共享存储器可以包括数据库和元组空间中的至少一种，并且确定当前上下文可以是基于存储在共享存储器中的评价。

在当前上下文活动时收集与当前上下文相关联的数据可以包括收集以下各项中的至少一种：与在当前上下文活动时发生的至少一个通信相关联的数据、在上下文活动时生成的文档、在当前上下文活动时用户的位置、在当前上下文活动时用户的行为，以及在当前上下文活动时与用户协作的其他用户的标识符。

所述方法还包括判断当前上下文是否是活动的。判断当前上下文是否是活动的可以包括监视输入设备以判断是否已经接收到输入数据，所述输入数据指示出上下文已经从当前上下文改变到新的当前上下文，并且如果不存在所述输入数据，则确定当前上下文是活动的。

所述方法还包括：判断上下文是否已经从当前上下文改变到新的当前上下文；判断在共享存储器中是否存在与新的当前上下文相关联的新的上下文对象，如果没有，则在共享存储器中创建该新的上下文对象；在新的当前上下文活动时收集与该新的当前上下文相关联的数据；以及将与该新的当前上下文相关联的数据存储在与该新的当前上下文相关联的新的上下文对象中。判断上下文是否已经从当前上下文改变到新的当前上下文可以包括监视输入设备以判断是否已经接收到输入数据，所述输入数据指示出上下文已经从当前上下文改变到新的当前上下文。

该方法还包括接收对与当前上下文相关联的数据的请求，并且作为响应，提供存储在上下文对象中的数据。

该方法还包括使上下文对象与以下各项同步：至少一个关联的上下文对象、存储在网络中的第一计算设备处的上下文对象，以及存储在网络中的第二计算设备处的至少一个关联的上下文对象。所述网络可以包括P2P网络。

本说明书的第二方面提供了一种用于管理上下文的系统。该系统包括共享存储器，用于存储多个上下文对象，每个上下文对象包括与给定上下文相关联的数据。该系统还包括与共享存储器通信的至少一个计算设备。所述计算设备包括：通信接口，该通信接口被使能为经由通信网络与共享存储器通信；以及处理器。该处理器被使能用于：确定当前上下文；判断在共享存储器中是否存在与所述当前上下文相关联的上下文对象，如果没有，则在所述共享存储器中创建所述上下文对象；在当前上下文可以活动时收集与当前上下文相关联的数据；以及将与当前上下文相关联的数据存储在与当前上下文相关联的上下文对象中。

所述共享存储器可以包括数据库和元组空间中的至少一种。

该系统还可以包括至少一个知识源代理，用于处理与通信会话、位置和日程中的至少一个相关联的数据以辅助确定所述当前上下文。

所述计算设备可以被耦合到输入设备和显示设备，所述输入设备用于接收输入数据，所述显示设备用于显示当前上下文的表示和潜在的当前上下文的列表的表示，其中当前上下文可以通过经由输入设备接收输入数据而改变到潜在的当前上下文，所述输入数据包括所述列表的成员。

本说明书的第二方面提供了一种用于管理上下文的计算设备。该计算设备包括：通信接口，其被使能为经由通信网络与共享存储器通信；以及处理器。该处理器被使能用于：确定当前上下文；判断在共享存储器中是否存在与当前上下文相关联的上下文对象，如果没有，则在所述共享存储器中创建所述上下文对象；在当前上下文可以活动时收集与当前上下文相关联的数据；以及将与当前上下文相关联的数据存储在与当前上下文相关联的上下文对象中。

附图说明

参考附图描述实施例，其中：

图1示出根据非限制性实施例，组织中的用户之间的交互的示意图；

图2示出根据非限制性实施例用于管理上下文的系统；

图3示出根据非限制性实施例用于管理上下文的用户界面；

图4示出根据非限制性实施例的上下文管理器的表示；

图5示出根据非限制性实施例用于管理上下文的方法；以及

图6到图11示出根据非限制性实施例用于管理上下文的应用的GUI的视图。

具体实施方式

图1示出在一个可能的工作日，组织中的用户110a、110b、110c等(一般统称为用户110)之间的交互的示意图，其中用户110是组织或公司的雇员和/或管理者，该图示出用户110不是在单独的题目或上下文下孤立工作的。相反，它们一般在非正规的组中工作，这些非正规的组处理独立的题目或上下文。因此，每个用户110每天在组织中的不同上下文中工作，上下文包括与这些组的目的、行为、能力和历史相关联的数据。用户110可以同时和/或接连在若干上下文中工作。例如，用户110b既在“预算”上下文中工作也在“职工安置”上下文中工作，在“预算”方面，他与用户110a、110c、110e和110f协作，而在“职工安置”方面，他与用户110c、110d和110f协作。在与用户110c通信期间(例如打电话或交谈)，上下文可以从“预算”开始，转移到“职工安置”，再回到“预算”。在该通信期间，可能产生与不同(或有时重叠的)上下文相关联的各种文档或生成和发送电子邮件等等。此外，在一给定的工作日期间，这些上下文中的某些将被用户抛在脑后并且可能不会给予其任何程度的关注。其他上下文将被给予更多关注，并且一个或多个上下文一般将作为用户110全面关注的当前上下文。

图2示出用于管理上下文的系统200的框图，系统200包括与用户110相关联的上下文管理器(CM)210，CM 210包含由计算设备230的处理器220所处理的应用。在某些实施例中，计算设备还包括用于存储CM 210的存储器240。计算设备230能够经由通信接口260通过通信网络250进行通信。CM 210因此与共享存储器270通信。在某些实施例中，共享存储器270包括数据库，而在其他实施例中，共享存储器包含元组空间(tuple space)，下面将描述。一般而言，共享存储器270能够存储上下文对象(CO)280(一般统称为CO 280)，每个CO 280与不同的上下文相关联。虽然下面将进一步描述CO 280，但是一般而言，每个CO280包含与其相关联的上下文的标识符以及与该上下文相关联的数据，包括(但不局限于)与该上下文相关联的用户110。计算设备230还耦合到显示设备290，例如平板显示器(例如LCD)或CRT，并且计算设备230能够控制显示设备290显示CM 210的一部分的表示295。在某些实施例中，表示295包含用于CM 210的图形用户界面(GUI)，下面将在图3中示出并描述。在某些实施例中，计算设备230可以位于用户110本地，例如个人计算机、工作站或膝上型电脑。在其他实施例中，计算设备230可以位于用户110远端，例如作为客户端/服务器计算体系结构。

系统200一般还包括耦合到计算设备230的输入设备234，用于接收来自用户110的输入数据。输入设备234可以包括键盘、点选设备、触摸屏或它们的组合。

通信网络250包括有线或无线计算网络的任意所需组合，包括LAN、WAN、因特网、PSTN、WiFi网络、WiMax网络、蜂窝网络(例如CDMA、GSM、1x)等等。接口260一般能够经由通信网络250接收和发送通信。

CM 210一般能够经由表示295提供用户110所关注的当前上下文。因此，CM 210帮助用户110变得具有更高生产力和效率。此外，CM 210帮助用户110将工作日的各个方面与上下文相关联。用户的每个当前上下文(其在整个工作日中改变)与存储在共享存储器270处的一个CO 280相关联，即一个CO对应于一个上下文。因此，CM 210一般还能够经由与共享存储器270之间的通信来处理、创建、删除和更新CO 280，下面将描述。

在某些实施例中，系统200还包括SIP代理275(例如用于处理SIP通信的计算设备)，共享存储器270与该SIP代理275通信。SIP代理275能够发布要与用户110协作的邀请276(例如经由计算设备230或与用户110相关联的可选通信设备232，例如实现了SIP的电话)，如本领域技术人员所知，邀请276一般包含针对VOIP呼叫的SIP Invite(SIP邀请)、IM会话等等。邀请276一般将在来自另一用户(例如与另一用户110′相关联的通信设备230′，通信设备230′一般与计算设备230类似)的通信请求(在某些实施例中，还包含SIP邀请)到达SIP代理275时发布。

在某些实施例中，如图所示，邀请276经由共享存储器270被发布，共享存储器270进而向CM 210发布新呼叫消息277。虽然在图2中SIP代理275被示为与共享存储器270直接通信，但是可以理解，SIP代理275可能经由通信网络250(或另一通信网络)与共享存储器270通信，并且SIP代理275进一步与计算设备230和/或通信设备232通信。因此，在这些实施例中，共享存储器270被使能作为消息路由器。但是，在其他实施例中，新呼叫消息277可以经由硬连线连接被发送。在其他实施例中，新呼叫消息277可以经由任意合适的事件系统或发布/订购系统来发送。例如，新呼叫消息277可以按与本领域技术人员所知的路由器中的分组转发类似的方式被发送：分组基于它们的地址字段的内容被转发。共享存储器270(例如元组空间或其它类型的共享存储器)一般可以按类似方式使能。在其他实施例中，共享存储器270可以被使能为基于其他字段的内容转发数据。

在任意情况下，图2还示出上下文可以经由CM 210被管理的情况的非限制性示例。当CM 210接收到消息277时，计算设备230控制显示设备290显示表示295(如果尚未显示的话)以便于用户110查看。表示295的非限制性实施例在图3中示出。在该实施例中，表示包括关于发出协作邀请的另一用户110′的承销公告信息310。承销公告信息310可以包括(但不局限于)另一用户110′的名称、亲属关系和联络地址。在某些实施例中，承销公告信息310还包括MORE(更多)按钮312，利用该按钮，用户110可以与输入设备232交互，以使得当激活MORE按钮312时，关于另一用户110′的额外信息可以被呈现，例如另一用户110′的工作职称、地理位置等等。表示295还包括当前上下文框(CCB)314，用于显示用户110和另一用户110′之间的通信的当前上下文，具体而言，当前上下文的标识符，该标识符存储在与该当前上下文相关联的CO 280中。在一个实施例中，该标识符包括当前上下文的发起者分配给该当前上下文的名称。当前上下文的确定下面将描述。

如图1所示，用户110被牵涉到与一协作者(例如另一用户110′)之间多个上下文中的情形是时常发生的。对于协作会话(例如电话和/或IM会话)，在很多上下文之间顺序移动的情况也是常见的。协作会话开始于其中的上下文通常将仅仅是会话的若干题目中的第一个。因此，CM 210还被使能为允许用户110经由与表示295的交互来转移上下文。例如，在图3所示实施例中，表示295还包括所有上下文框(ACB)316，其显示用户110可能经由与输入设备234的交互而选择的协作会话的可能上下文的标识符的列表。

为了编辑在ACB 316中显示的列表，CM 210将扫描CO 280(例如经由对发送到共享存储器270的信息的请求)，以寻找与用户110和/或另一用户110′相关联的所有上下文。例如，CM 230请求与用户110和/或另一用户110′相关联的CO 280中的上下文的标识符，并且根据这些标识符来编辑所述列表。用户110可以将列表中的标识符之一选为当前上下文。例如，经由输入设备234，用户110可以点击一标识符或将一标识符拖到CCB 314中。该上下文的标识符随后将被显示在CCB 314中，并且CM210将理解当前上下文是与显示在CCB 314中的标识符相关联的上下文。这对于与该上下文相关联的CO 280的影响下面将描述。

在某些实施例中，CM 210还被使能为允许用户110经由与表示295交互而定义将参与的新上下文。例如，在这些实施例中的某些中，表示295包含新上下文按钮(NCB)318。在例如经由输入设备234激活NCB318之后，用户110经被提示例如经由弹出屏幕输入新上下文的标识符(例如名称)。新上下文的标识符将被显示在ACB 316中。此外，CM210将致使与新上下文相关联的新CO 280被添加到共享存储器270。新CO 280最起码将包括新上下文的标识符，以及致使新CO 280被创建的用户110的标识符(例如姓名、雇员号码、电话号码等等)。在某些实施例中，新CO 280还将包括当新CO 280被创建时与用户110处于通信会话中的另一用户110′的标识符。

在某些实施例中，CM 210还被使能为允许用户110经由与表示295之间的交互从显示在ACB 316中的列表中删除将参与的上下文和/或删除与显示在CCB 314中的标识符相关联的上下文。例如，在这些实施例中的某些中，表示295包括删除上下文按钮(RCB)320。在例如经由输入设备234激活RCB 320之后，被高亮的上下文将被从列表和/或CCB 314中删除。例如，用户110可以通过经由输入设备234点击标识符来高亮显示在列表和/或CCB 314中的上下文的标识符(例如在所示实施例中，“CONTEXT GUI PATENT”被高亮)。在某些实施例中，CM 210将致使与被删除的上下文相关联的CO 280被从共享存储器270中删除。该特征可被用于删除对不再使用的上下文的引用。

下面将描述CO 280和CO 280的更新。如上所述，用户110将与一个或多个其他用户110之间在多个上下文中工作。这些上下文中的每个可以与一个企业对象相关。因此，帮助用户110将他们的注意力集中在一个特定上下文中是有益而合乎需要的，特别是当用户在执行其他任务时被电话或其他通信尝试所打断时。因此，经由CM 210的表示295的CCB 314，用户110可以指示哪个上下文是当前上下文。可替换地，系统200可以确定当前上下文。这在下面将参考图4来更详细地描述。与当前上下文相关联的数据随后在当前上下文活动的同时被收集。与当前上下文相关联的数据被存储在与当前上下文相关联的CO 280中。与当前上下文相关联的数据可以包括与当前上下文活动时发生的通信相关联的数据、在上下文活动时生成的文档、在当前上下文活动时用户110的职位、在当前上下文活动时用户110的行为，以及在当前上下文活动时与用户110协作的其他用户110的标识符。下面将参考图4来描述用于收集与当前上下文相关联的某些种类的数据的系统。

在某些实施例中，与存储在CO 280中的当前上下文相关联的数据可以包括对数据的引用。例如，如果在当前上下文活动时用户110生成文档，与当前上下文相关联的数据则可以包含对该文档的引用(例如网络地址、在硬盘驱动器上的位置等等)而非文档本身。

因此，通过在给定上下文为当前上下文时将与该给定上下文相关联的数据保存在CO 280中，用户110随后可以通过查询存储在CO 280中的数据而快速知晓该给定上下文的日期。例如，当用户110的上下文在一天中的若干时刻在多个上下文之间移动时，在一天中的某一时刻，给定上下文可能变为当前上下文，因此用户110具有可获得的数据的记录，该记录使得用户110能够在给定上下文方面快速刷新其自身的记忆。

在某些实施例中，例如通过显示上下文的某些视图(例如与上下文相关联的所有电子邮件)，存储在CO 280中的数据可被用于支持帮助用户110转移其注意力的应用。

现在关注图4，其示出根据非限制性实施例用于管理上下文的系统400。在某些实施例中，上述系统200是系统400的子集，其中类似的元件具有类似的标号，在系统400中，共享存储器270包含元组空间410。元组空间一般是一种数据库，其中可以放置关于用户110的状态和/或与用户110相关联的装置和系统的状态的各种评价(被称为元组)，包括以CO 280形式存在的当前和先前的上下文。

系统400一般是从申请人共同未决的2003年8月1日递交的题为“Context Aware Call Handling System”的美国专利申请No.10/631,834修改而来的，该申请通过引用被结合于此，该申请描述了上下文敏感的呼叫处理系统的操作。本发明的实施例使用了申请人共同未决的美国专利申请No.10/631,834中描述的基本结构来管理上下文并确定当前上下文。该基本结构是一种由知识源所包围的黑板系统(blackboard system)，所述知识源收集和处理与用户110相关联的上下文信息，以使得可以识别出一般的用户上下文并可以使得传入的呼叫尝试位于其中。但是，系统400通过提供一个或多个各自可以支持特定对象的特定上下文的可能性而扩展了这种概念。

系统400包括元组空间410，用于维护一般上下文和与元组空间410通信的多个知识源代理420-460(下面将描述)。上下文是通过由知识源代理420-460中的一个或多个所作出的一个或多个评价来指定的，所述一个或多个评价例如作为元组被存储在元组空间410中，如本领域技术人员所知。这些元组中的某些是长期存活的。其中一个示例可以是用户110之间的用户角色关系(例如老板—销售员)。某些评价(assertion)是短期存活的。其中一个示例可以是用户110的职位，该职位可以按分钟改变。不同的上下文可以作为CO 280存储在元组空间410中。虽然图4中没有示出CO 280，但是可以理解，像图2的共享存储器270中一样，CO 280被存储在元组空间410中。

所有这些评价都是由围绕元组空间410的知识源代理420-460之一放置到元组空间410中的，或者本领域技术人员将想到另一知识源代理。不是所有知识源代理420-460都将能够解释所有上下文评价。相反，需要理解和确定评价的知识源代理420-460将被提供以适当评价的语法。单独的评价的语义针对每个知识源代理420-460可以(并可能将是)不同的。每个知识源代理420-460可以使用其自己的语义来针对其自己的目的解释评价。因此，CO 280不需要必须是结构化的。相反，在某些实施例中，CO280是半结构化的，从而使得存储在CO 280中的数据的项目将被将被识别出以使得可以找到需要数据的应用。此外，不是所有使用CO 280的应用都需要理解包含在CO 280中的所有数据。这有助于互操作性和可扩展性。

在特定的非限制性实施例中，与特定上下文相关联的数据可以作为与特定上下文相关联的评价被存储在CO 280中。例如，针对上下文的标识符可以作为标识上下文的关键值对被存储在CO 280中(例如在CO 280起始端处)。这可以具有以下形式：

<Context><123456>，其标识特定上下文123456。

在CO 280中的上下文的表示可以是基于树的，其中为特定类型的数据预留CO 280的特定区域。可以存储在CO 280中的数据有：

a)上下文的名称

b)上下文的目的

c)上下文的参与者

d)上下文中的通信尝试

作为通信尝试类别的另一示例，其可以是其中可以存储关于通信尝试的注释(annotation)的类别。

例如，这样的评价可以是：

<Context><123456>

<Communication_Attempt><314159>

<Annotation><Discussing UK product launch>

在某些实施例中，通信尝试的标识符(即在以上示例中为“314159”)可以由呼叫处理代理来分配，在图4的结构中呼叫处理代理例如是SIP代理275。通信尝试的标识符标识特定呼叫尝试。在某些实施例中，一个上下文中可能存在很多这样的标识符。

在该通信尝试中的呼叫者(例如图2中的另一用户110′)还可以利用以下评价来标识：

<Context><123456>

<Call_Attempt><314159>

<Participant><Amanda_Slack＠mitel.com>

如上所述，用户110可以与CM 210交互，CM 210帮助用户110经由表示295在多个上下文之间转移，并且CM 210还可以确定当前上下文。现在将在系统400的构架中对此进行描述。SIP代理275(或可替换地，PBX)将接收传入呼叫。使用公共网关接口(CGI)或某种其他服务，SIP代理275将关于呼叫的评价放置到元组空间410中。在传统的PBX的情况下，这可能局限于呼叫线路ID(CLIP)和所拨打的号码(来自DHIS拨打号码信息服务)。但是，使用SIP或类似协议可以导致特定数据被提供，例如呼叫主题、紧急性等等。结果是元组空间410现在将包含多个描述呼叫的评价。

现在将描述知识源代理420-460。一般而言，知识源代理420-460不一定被安装在特定计算设备上，而是可能分布在计算设备的网络上，所述计算设备有权访问处理元组空间410的服务器(即包含存储和处理元组的共享存储器的服务器)。知识源代理420-460将有权访问各种可被用于猜测用户上下文的证据源。证据源的示例包括(但不局限于)：

1.用户的日历的内容

2.其它用户的日历的内容

3.来自用户的当前上下文的社会意识观察和猜测

4.用户声明

系统管理代理(SMA)420在通信(例如电话呼叫、SIP请求等等)的处理和确定上下文数据方面使围绕元组空间410的其他代理430-460的行为同步。SMA 420将在适当的时间触发代理430-460以评价当前在元组空间410中的信息并进一步作出统一地描述通信的评价。具体而言，关系分配代理(RAA)430和一个或多个上下文代理440将被触发以评价当前评价并将传入通信与用户110的当前上下文相关。在某些实施例中，每个客户端(例如计算设备230)与一个SMA 420相关联。

关系分配代理(RAA)430一般被使能用于对来自SMA 420的关系分配请求作出响应。来自SMA 420的请求一般包含呼叫者和接收者信息。RAA 430例如根据用户110的兄弟列表或根据另一关系数据列表(例如公司组织结构图)来分配用户110和呼叫者之间的关系。

一个或多个上下文代理440被使能为监视用户110的行为。例如，上下文代理440可以确定用户110在哪里，跟谁在一起等等，并且可以作出关于元组空间410中的上下文的评价。因此，上下文代理440可以有权访问用户110的日程安排、与用户110相关联的位置确定设备(例如被使能用于无线通信的GPS设备)、webcam、键盘动作检测代理等等。在当前上下文活动时，该数据可以被存储在与当前上下文相关联的CO 280处。

规则分配代理450被使能用于根据每个规则的条件和当前上下文提取出匹配的用户规则，并将它们分配给相关的数据字段以用于呼叫处理和上下文的确定。

冲突解决代理(CRA)460被使能用于解决可能存在于所分配的规则中的冲突。

而且，利用上下文，可以知道用户110在哪里，和/或用户110在做什么、用户110和谁在一起以及可以从该数据推导出什么。但是，上下文的“什么”和“谁”可以超出原始数据。上下文代理440可以包含IF-THEN规则或将更多事实与更多抽象概念相关的策略。例如，如果位置敏感的上下文代理440确定用户110在特定房间中(例如603-1)，上下文代理规则则可以将房间603-1标识为会议室并作出用户110在会议室中的评价，并且进一步确定用户110在会议中。在当前上下文活动的同时，该数据随后可被存储在与当前上下文相关联的CO 280中。

类似地，RAA 430具有多个规则，这些规则可以取得关于呼叫的证据，并将呼叫者与用户110相关。例如，规则可以将呼叫号码(例如图3中的613-592-2122)与特定人(例如图3中的Amanda Slack)的电话号码相关。进而，其他规则可以将呼叫者与用户110的上司相关。在当前上下文活动的同时，该数据随后可被存储在与当前上下文相关联的CO 280中。

因此，上下文代理440和关系分配代理430的互操作可以取得某些利用传入呼叫可获得的粗略信息(例如CLID)，并使呼叫适合于用户110的当前上下文。此外，与呼叫相关联的数据可被保存在与当前上下文相关联的CO 280中。因此，当用户110在会议室中时，来自(613)592-2122的呼叫(其本质上只提供有限的指引)被转换成来自用户的上司的呼叫。这种存储在CO 280中的数据可以随后被用户110取得，并帮助用户110记忆与特定上下文相关联的事件和其他数据。其他信息也可以由规则提供和操作。例如，在当前上下文活动时用户110和谁在一起，在当前上下文活动时发生的呼叫或通信的主题、在当前上下文活动时用户正在处理的文档。与所述数据一起，得到的评价使得呼叫适合于用户的当前工作和社会上下文。

使用这些评价，规则分配代理450将确定提供给系统400的策略中的哪些适合于当前通信。通常，多个规则将应用到呼叫。CRA 460随后将确定哪种规则应该具有优先级。然后再将其提供到SIP代理275(或PBX)来进行动作。

如图所示，CM 210还将与元组空间410通信，并且进一步，在该实施例中，与用户110相关联的CO 280作为评价的集合被存储在元组空间410中。CM 210将有权访问并能够解释CO 280中的评价，以及CRA 460用来指导SIP代理275进行动作的评价。

当传入通信发生时，CM 210可以被SMA 420顺序触发，以理解CRA 460(或另一知识源代理)将发出对元组空间410中的动作的评价。CM 210将检测到该评价是指导SIP代理275向用户110(例如向计算设备230和/或通信设备232)直接发送通信的。CM 210还能够从元组空间410中的评价中确定与传入通信相关联的用户110′(例如该示例中的AmandaSlack)。然后，CM 210将扫描位于元组空间410内的CO 280以寻找与用户110′之间的关联(即它们是否处于与用户110相关联的特定CO 280的参与者列表中)。CM 210随后将在图3的表示295的承销公告信息310中显示与用户110′相关联的数据，并且与用户110′相关联的上下文的名称被从CO 280中的适当评价中提取出并被显示在图3的ACB 316中。

在某些实施例中，当确定了当前上下文时，当前上下文的标识符可以作为评价被存储在元组空间410中的用户110的上下文中。

在某些实施例中，在SIP协议中，当前上下文可以通过将上下文头部添加到SIP INVITE消息来确定。上下文头部将包含通信的上下文的标识符，因此包含用户110的当前上下文(假设通信被接受)。上下文头部的内容将通过SIP代理275被提供到元组空间410，作为邀请过程的一部分。如果CM 210在处理邀请的同时找到位于其中的有效上下文标识符，则将该上下文设置为用户的当前上下文。就是说，在元组空间410中，它将当前上下文评价设置到该上下文，并在图3的CCB 314中显示上下文的标识符。如果其中的上下文头部包含在其CO 280位于元组空间410中的上下文没有找到的上下文的标识符，CM 210则将假设将创建新的上下文，并因此创建新CO 280。因此，CM 210将针对该上下文在元组空间410中触发新CO 280的创建，并将随后将上下文信息显示在CCB 314处。

但是，如果邀请不包含上下文头部或者如果上下文头部为空，当前上下文评价则将被设置为空并且CCB 314将被保持空白。当用户110与输入设备234交互时，当前上下文随后可以经由接收自输入设备234的数据来确定，现在将对此进行描述。

一种常见的情况是，在通信/交互期间，参与者将希望改变上下文。用户110将通常被牵扯到与企业内和外的其他用户110之间的多个上下文中，并将使他们的注意力在这些上下文之间转移。因此，为了改变上下文，在通信中的一个或多个用户110将从在ACB 316中显示的列表中选择一个上下文标识符，并经由与输入设备234的交互(例如通过将其拖到CCB 314中或双击它)将该标识符显示在CCB 314中。如果只有通信中的一个用户110执行该动作，与该用户110相关联的CM 210则可以随后向与其他参与者相关联的CM 210发送消息，这些CM 210则可以随后致使其他参与者的当前上下文也改变。在任意情况下，CM 210随后都将致使元组空间410中的当前上下文评价被设置到所选上下文并且还使其显示在CCB 314中。此外，与在该所选上下文作为当前上下文活动时收集的新上下文相关联的任意数据将被保存到与所选上下文相关联的CO 280。该技术还可被用于当在邀请中不存在上下文头部时或者如果上下文头部为空时定义当前上下文。

如上所述，在某些实施例中，用户110可以经由NCB 318的激活来创建新上下文。用户110随后将被提示新上下文的名称。新上下文将被利用为其创建的元组空间410中的CO 280来创建。用户110还可以被提示诸如目的等的永久信息。在其他实施例中，可以通过用户110经由输入设备234选择CCB 314的字段并且输入新的上下文标识符来创建新的上下文。

虽然在某些实施例中所描述的用于确定当前上下文的某些技术是基于SIP IVITE消息的，但是SIP可能不是在系统400中所使用的协议。例如，不同于SIP，关于通信的数据可以在呼叫线路ID、ANI(自动号码标识)或其他信令结构中提供。这些也可被用于标识呼叫者和辅助确定当前上下文。此外，P2P系统(例如下面将描述的)也可被用于确定当前上下文。但是，在没有信息可用于识别传入呼叫者的实施例中，当前上下文可以手工确定，如上所述。

在某些实施例中，系统400被使能用于针对未使用SIP(或其等同物)的那些系统或当没有提供上下文头部或上下文头部为空时，对初始的当前上下文作出“最佳猜测”。元组空间410一般保存有协作历史，因此存储有可被处理以用于进行这种最佳猜测的数据，例如CO 280和其他评价。例如，在某些实施例中，元组空间410保存有用户110与呼叫者之间使用的上一上下文的评价。在这些实施例中，该上一上下文可以在用户110和呼叫者之间的下一通信期间被设置为当前上下文。在另一实施例中，元组空间410是用户110在与呼叫者之间的上次通信期间转向的第一上下文。在这些实施例中，该第一上下文可以在用户110和呼叫者之间的下一通信期间被设置为当前上下文。在另一实施例中，元组空间410可以维护这样的数据结构，该数据结构中例如在每个CO 280中存储有用于给定上下文的累计时间。在这些实施例中，基于被最多使用的上下文在呼叫者-用户关系方面是最重要的这样的假设，被最多使用的上下文在用户110和呼叫者之间的下一通信期间被设置为当前上下文。经由最佳猜测确定当前上下文的其他方法处于本发明的实施例的范围之内。

虽然这里描述的很多实施例引用了涉及语音通信(例如电话呼叫)的通信，但是上下文也可以针对其他类型的通信(例如多媒体、IM、电子邮件等等)来管理。在这些实施例中，通信用户的身份可以经由接收自通信用户的数据(例如在电子邮件的FROM头部中)来确定，并据此选择上下文。这样一来，用户110可以在查看当前通信的同时看见(例如通过取得与通信相关联的上下文所关联的CO 280)协作历史并与协作历史交互。

上述实施例引用了作为人类用户的用户110之间的通信。但是，在其他实施例中，上下文可以针对与人类用户和商业过程系统或自动系统(一般称为机器人)之间的协作相关联的通信来管理。例如，机器人可能被使能用于创建上下文，以帮助其调度一个或多个人类用户的动作。这些机器人可进一步被使能用于创建向用户110提供关于支持过程的上下文中的当前活动的信息的通信(记录、语音、文本等等)。用户110可以查看它们的上下文并维护与机器人、其他用户110或其他机器人相关联的上下文中的活动历史，以便集中用户110的注意力。

如上所述，参考CO 280，上下文可以与参与者的数目相关联。参与者将在他们被邀请时进入和离开上下文，完成他们指定的任务和丢弃上下文。如上所述，CO 280包含有记录，所述记录详细描述每个参与者、上下文的描述(目的、参与节点/计算设备)以及交互历史(特定协作的注释)。因此，CO 280充当中央仓库，该中央仓库将使得人类、机器人和应用能够处理CO 280中的数据以及交互和协作。因此，在某些实施例中，CO 280的一部分可以专用于属于每个参与者的特定上下文，该特定上下文将包含用于所有参与者的公共信息。例如，针对特定上下文的每个CO 280包含针对所有呼叫的注释以及在特定上下文中已经发生的其他协作。因此，支持应用可以使得用户110具有所有呼叫的表示和/或在特定上下文中发生的数据。虽然上面已经进行了一般描述，但是在特定非限制性实施例中，为了对所有CO 280提供公共基础，每个上下文都将被链接所有用户110的P2P网络所支持。该P2P网络可以按照与下述美国专利申请中所描述的P2P网络类似的方式来创建、操作和管理：申请人共同未决的2007年7月23日递交的题为“CONFIGURATION OF IP TELEPHONYAND OTHER SYSTEM”的美国专利申请No.11/781,319，该申请通过引用被结合于此。

该P2P网络的结构包括被使能用于接收更新的所选主节点，该主节点进而将更新分发到参与节点(即计算/通信设备和/或服务器)。节点一般被理解为包括存储器、通信接口和处理器的计算设备。每个参与节点将与主节点之间具有公布/订购关系。每个参与节点将向主节点公布任意相关的更新，并且其进而将更新通知到所有其他参与节点。因此，存储在每个参与节点处的CO可以按类似方式被更新，并因此所有参与节点都将具有维持到同一状态的公共的CO 280，并且进而位于参与节点本地的CO将是在其他节点处的关联CO。在某些实施例中，这使得包含CO的元组空间能够在多个节点上被维护。

通过使用该所选主节点，在维护CO的状态方面的竞争状况(racecondition)问题得到解决。另外，带宽量和处理消耗得以减少。据本领域技术人员所知，在其最简单的形式中，竞争状况是两个进程在计算机上同时使用共享资源但又彼此独立地完成它们的任务的状况。例如，在某些实施例中，参与节点可以是网状网络的元素。在这些实施例中，每个参与节点将更新通知到所有其他的参与节点。但是，随着参与节点到来和离开，将会出现竞争状况问题。因此，将难以确保所有节点都具有相同的参与者列表，因此某些CO 280可能丢失掉在其加入上下文之后很快发生的更新。所选主节点体系结构解决了该问题。

在这种体系结构中，节点可以通过初始邀请(例如发送自主节点或另一参与节点)被邀请到上下文中。邀请包含节点先前尚未看到的的上下文名称。节点从而针对新的上下文创建上下文/CO。

新创建的CO随后可以被链接到P2P网络，从而接收公共上下文(即在存储在其他参与节点中的关联CO中的数据)。在基于SIP的P2P系统中，可以针对邀请消息定义头部，该头部将包含主节点的URL或IP地址：“当前P2P主头部”。使用该URL或IP地址，节点可以使用标准的SIP事件通知控制消息来与主节点之间建立公布/订购关系。节点随后将被告知其他CO 280的公共内容并更新本地CO 280。

在非SIP系统中，呼叫者ID(或类似信息)可以被用于标识传入邀请的源。在这些实施例中，节点可以使用目录(ENUM或其他)来确定可被用于寻址发起传入邀请的源的URL或IP地址。节点随后将从发起传入邀请的节点请求(使用SIP通知等同物或其他消息)当前主节点的URL或IP地址。节点随后可以加入网络，如上所述。

当从上下文中删除节点时，被删除的节点可以向存储在本地CO中的所有参与节点的列表中的其他节点发送更新。节点一般还结束与当前主节点之间的公布/订购关系。

在某些实施例中，创建上下文/CO的节点将向另一节点发出第一邀请以加入该上下文。发起节点将宣称其自身为主节点并将此用作使第一节点进入P2P网络的过程的一部分。从此以后，P2P网络将按以上描述进行操作，并按需要选择新的主节点或使得节点进入和离开。

现在关注图5，其示出根据非限制性实施例管理上下文的方法500。为了辅助对方法500的说明，将假设方法500是使用系统400来执行的。此外，以下对方法500的论述将使得能够进一步理解系统400及其各个组件。但是，将会理解，系统400和/或方法500可以被改变，并且不一定如这里论述的那样彼此结合地工作，并且这些变化处于本发明的实施例的范围之内。

在步骤510处，如上所述，例如通过经由输入设备234从用户110接收输入数据、通过接收带有上下文头部的SIP邀请、或者通过进行“最佳猜测”，当前上下文被确定。当前上下文随后可以与任意承销公告信息一起被显示在CCB 314中，如上所述。

在步骤520处，判断在数据库(例如元组空间410或另一数据库)中是否存在与当前上下文相关联的上下文对象(例如上下文对象280)。如果不存在上下文对象，则在步骤530处，在数据库中创建上下文对象。在当前上下文活动时，与所述当前上下文相关联的数据在步骤540处被收集，如上所述。在步骤550处，该数据被存储在上下文对象中，从而创建和/或更新当前上下文的历史。在步骤560处，例如通过判断用户110是否已经致使不同的上下文标识符被显示在CCB 314中(如上所述)，来判断当前上下文是否已经改变。如果没有，则在步骤540处继续收集数据。如果有，则在步骤520处判断是否存在针对新的当前上下文的上下文对象。此后，方法500按上述方式继续。因此，用户110可以例如使用应用来致使上下文的历史和/或对上下文历史的更新被存储在上下文对象中以备随后参考。方法500可以通过关闭CM 210(例如通过关闭表示295)在任意步骤期间或之后终止/中断。

图6到11示出根据非限制性实施例，用于管理上下文的应用的图形用户界面(GUI)的非限制性实施例。例如，应用可以被使能用于处理CO以在GUI中呈现与上下文相关联的数据，具体而言，控制显示设备来显示这些数据。GUI被构造为标签(tab)格式，以使得每个标签呈现出上下文的不同视图和/或与应用的用户相关联的额外信息。用户可以通过使用点选设备“点击”标签来在标签视图之间进行切换。图6示出根据非限制性实施例的ID标签，其显示出与应用的用户相关联的信息，包括(但不局限于)用户的姓名、单位和职位。标签还包括注释字段，以允许用户输入上下文标识符。应用接收上下文标识符并取得与该上下文标识符相关联的CO(例如从元组空间或其他数据库)。通过输入上下文标识符，用户指示他/她想要浏览所关联的上下文的历史的愿望。

图7示出根据非限制性实施例的电子邮件标签，其显示出与在ID标签上输入的上下文相关联的电子邮件(或其他通信)的标识符。例如，存储在所取得的CO中的电子邮件的标识符可以被显示在该标签上。如果用户选择特定标识符，应用则可以被使能用于取得所选电子邮件(或者从CO(如果存储在此的话)，或者在CO中与标识符相关联地存储的地址处)并显示该电子邮件。可替换地，应用可以致使打开电子邮件应用，该电子邮件应用进而显示所选电子邮件。

图8示出根据非限制性实施例的日历标签，其显示出与在ID标签上输入的上下文相关联的用户/参与者的日历信息。例如，应用可以处理所取得的CO以确定参与者和/或参与者标识符，并取得与每个参与者相关联的日历信息以显示在日历标签上。

图9示出根据非限制性实施例的知识网络标签，其显示出具有与在ID标签上输入的上下文相关联的专业技能的用户的标识符和状态。例如，应用可以处理所取得的ID以确定哪种专业技能与所取得的CO相关联(在该示例中是“消息发送”)，然后发起对组织数据库的搜索。在组织数据库中与该专业技能相关联的个人的状态(如果可获得的话)名称随后可以被显示在知识网络标签上。

图10示出根据非限制性实施例的Web信息标签，其显示出在ID标签上输入的上下文的标识符，在某些实施例中，显示出一段时间以来在ID标签上已经输入的所有上下文的标识符：例如Web信息标签维护在ID标签上输入的上下文标识符的历史。用户可以通过选择标识符来发起Web搜索，这致使应用例如经由Web搜索应用来触发Web搜索。

图11示出根据非限制性实施例的桌面标签，其显示出与ID标签上输入的上下文相关联的文档的标识符。这些标识符可以按照与以上参考图7所描述的取得电子邮件标识符相似的方式来取得，并且文档可以被访问。

本领域技术人员将意识到，在某些实施例中，上下文管理器210、元组空间410、系统管理代理420、关系分配代理430、上下文代理440、规则分配代理450和冲突解决代理460的功能可以使用预先编程的硬件或固件元件(例如专用集成电路(ASIC)、电子可擦除可编程只读存储器(EEPROM)等等)或其他相关组件来实现。在其他实施例中，上下文管理器210、元组空间410、系统管理代理420、关系分配代理430、上下文代理440、规则分配代理450和冲突解决代理460的功能可以通过使用有权访问代码存储器(未示出)的计算装置来实现，所述代码存储器存储有用于操作计算装置的计算机可读程序代码。计算机可读程序代码可以被存储在介质上，所述介质例如是固定的、有形的并且通过这些组件直接可读的(例如可移动盘、CD-ROM、ROM、固定盘、USB驱动器)，或者计算机可读程序代码可以经由调制解调器或其他通过传输介质连接到网络(包括但不局限于因特网)的接口设备被远程地存储但可发送到这些组件。传输介质可以是非无线介质(例如光学或模拟通信线路)或无线介质(例如微波、红外、自由空间光学或其他传输方案)或它们的组合。

本领域技术人员将意识到，仍然存在更多可替换的实现方式和修改可被用于实现本发明的实施例，并且以上实现方式和示例仅仅是对一个或多个实施例的举例说明。因此，本发明的范围仅仅由所附权利要求所限定。

Claims (20)

1.一种管理上下文的方法，包括：

确定当前上下文；

判断在共享存储器中是否存在与所述当前上下文相关联的上下文对象，如果没有，则在所述共享存储器中创建所述上下文对象；

收集与所述当前上下文相关联的数据；以及

将与所述当前上下文相关联的所述数据存储在与所述当前上下文相关联的所述上下文对象中。

2.如权利要求1所述的方法，其中所述确定所述当前上下文是基于通信会话、位置和日程中的至少一种的。

3.如权利要求1所述的方法，其中所述确定所述当前上下文是基于通信会话的，并且包括确定与所述通信会话相关联的两个用户之间的至少一个先前的通信会话的上下文。

4.如权利要求1所述的方法，其中所述确定所述当前上下文是基于输入数据的，所述输入数据是响应于计算设备控制显示设备显示对当前上下文的请求的表示而经由输入设备接收到的。

5.如权利要求4所述的方法，其中所述对当前上下文的请求包含至少一个潜在当前上下文的列表，所述至少一个潜在当前上下文的列表是通过处理所述共享存储器中的至少一个现有上下文对象而确定的，并且所述输入数据包括来自所述列表的第一选择。

6.如权利要求5所述的方法，还包括接收指示来自所述列表的第二选择将被删除的输入数据，并且作为响应，删除与所述第二选择相关联的上下文对象。

7.如权利要求4所述的方法，其中所述对当前上下文的请求包含输入所述当前上下文的名称的请求，并且所述输入数据包括包含所述名称的文本数据。

8.如权利要求1所述的方法，其中所述确定所述当前上下文是基于对通信会话的邀请中的上下文头部的。

9.如权利要求1所述的方法，其中所述确定所述当前上下文包括确定初始当前上下文的“最佳猜测”。

10.如权利要求1所述的方法，其中所述确定所述当前上下文包括从自动系统接收上下文指示，所述自动系统被使能为创建上下文以辅助所述自治系统调度至少一个用户的动作。

11.如权利要求1所述的方法，其中所述共享存储器包括数据库和元组空间中的至少一种，并且所述确定所述当前上下文是基于存储在所述共享存储器中的评价的。

12.如权利要求1所述的方法，其中收集数据包括收集以下各项中的至少一种：与在所述当前上下文活动时发生的至少一个通信相关联的数据、在所述上下文活动时生成的文档、在所述当前上下文活动时用户的位置、在所述当前上下文活动时所述用户的行为，以及在所述当前上下文活动时与所述用户协作的其他用户的标识符。

13.如权利要求1所述的方法，还包括判断所述当前上下文是否是活动的，并且所述收集发生在所述当前上下文是活动的的情况下。

14.如权利要求13所述的方法，其中所述判断所述当前上下文是否是活动的包括监视输入设备的输入数据，所述输入数据指示出所述上下文已经从所述当前上下文改变到新的当前上下文，并且如果不存在所述输入数据，则确定所述当前上下文是活动的。

15.如权利要求1所述的方法，还包括使所述上下文对象与以下各项同步：至少一个关联的上下文对象、存储在网络中的第一计算设备处的所述上下文对象，以及存储在所述网络中的第二计算设备处的所述至少一个关联的上下文对象。

16.如权利要求15所述的方法，其中所述网络包括P2P网络。

17.一种用于管理上下文的系统，包括：

共享存储器，用于存储多个上下文对象，每个上下文对象包括与给定上下文相关联的数据；以及

与所述共享存储器通信的至少一个计算设备，所述计算设备包括：

通信接口，该通信接口被使能为经由通信网络与所述共享存储器通信；以及

处理器，该处理器被使能用于：

确定当前上下文；

判断在共享存储器中是否存在与所述当前上下文相关联的上下文对象，如果没有，则在所述共享存储器中创建所述上下文对象；

在所述当前上下文活动时收集与所述当前上下文相关联的数据；以及

将与所述当前上下文相关联的所述数据存储在与所述当前上下文相关联的所述上下文对象中。

18.如权利要求17所述的系统，还包括至少一个知识源代理，用于处理与通信会话、位置和日程中的至少一个相关联的数据以辅助所述确定所述当前上下文。

19.如权利要求17所述的系统，其中所述计算设备被耦合到输入设备和显示设备，所述输入设备用于接收输入数据，所述显示设备用于显示所述当前上下文的表示和潜在的当前上下文的列表的表示，其中所述当前上下文可以通过经由所述输入设备接收所述输入数据而改变到潜在的当前上下文，所述输入数据包括所述列表的成员。

20.一种用于管理上下文的计算设备，包括：

通信接口，其被使能为经由通信网络与共享存储器通信；以及

处理器，其被使能用于：

确定当前上下文；

判断在共享存储器中是否存在与所述当前上下文相关联的上下文对象，如果没有，则在所述共享存储器中创建所述上下文对象；

在所述当前上下文活动时收集与所述当前上下文相关联的数据；以及

将与所述当前上下文相关联的所述数据存储在与所述当前上下文相关联的所述上下文对象中。

Images