CN101202792B - 基于发送方与接收方之间的关系处理消息的方法和装置 - Google Patents

Abstract

这里描述了基于发送方和接收方之间的交互历史和上下文处理消息的技术。在一种实现方式中，处理包括但不限于：响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方相关联的实体中执行的操作的过程期间被记录的；以及基于所确定的一个或多个之前的事务，生成一个或多个交互历史链接的候选的列表，以使得接收方能够选择将被执行的交互历史链接候选中的一个或多个，以便对发送方的消息做出响应。还描述了其它方法和装置。

Description

基于发送方与接收方之间的关系处理消息的方法和装置

版权声明

本专利文件的一部分公开内容包含受版权保护的资料。版权所有者不反对任何人以其在专利商标局专利文件或记录所表现的形式传真复制该专利文件或专利公开内容，但仍然保留其它所有版权权利。

技术领域

本发明总体上涉及数据处理。更具体地说，本发明涉及基于消息的发送方和接收方之间的关系对消息进行处理。

背景技术

当业务用户在多方之间进行交互时(例如接到客户打来的电话)，该业务用户希望看到该用户与客户之间的交互历史，以便总是能在通信过程中做好准备。然而，在真实世界中，用户仅仅能够通过点击不同网页上的若干按钮在网站上进行查看。此外，不能找到完整的客户相关链接。

电话通信的业务上下文与双方(例如发送方和接收方)之间讨论的特定主题密切相关。主题通常由一方发起，并且可以根据需要变成另一个主题。根据市场分析，固定通信方之间的主题相对稳定。然而，这种相关信息通常不能在传统的通信系统中获得，传统的通信系统只能让用户手动搜索客户相关信息的片断。

此外，当用户接收到从客户打来的电话时，用户希望系统生成直接触发对客户的动作的动作链接，而不是访问入口(portal)，打开OIF(例如位于不同应用的若干网页)，以及必须输入相关客户数据。这样的系统将增加用户生产率。然而，在传统系统中，用户只能通过采取若干步骤在入口中查看，这会被认为是非常低的生产率。

发明内容

这里描述了基于发送方和接收方之间的交互历史和上下文处理消息的技术。在一个实施例中，处理包括但不限于：响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务(transaction)，所述一个或多个之前的事务是在与接收方相关联的实体中执行的操作的过程期间被记录的；以及基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表，使得接收方能够选择要执行的动作候选中的一个或多个，以对发送方的消息作出响应。

通过附图以及随后的具体描述，本发明的其它特征将变得明显。

附图说明

附图中以示例的方式而非限制的方式示出了本发明，附图中，相似的参考标记指示相似的元素。

图1是示出根据本发明的一个实施例的用于处理通信消息的系统配置的框图。

图2是示出根据本发明的一个实施例的用于处理进来的呼叫(incomingcall)的处理的流程图。

图3是示出根据本发明的替代实施例的用于处理进来的呼叫的处理的示图。

图4是示出根据本发明的一个实施例的在处理期间使用的数据库的框图。

图5是示出根据本发明的一个实施例的业务上下文的例子的示图。

图6是示出根据本发明的一个实施例的用于处理通信消息的系统配置的框图。

图7是示出根据本发明的一个实施例的用于处理进来的消息或呼叫的处理的流程图。

图8是示出根据替代实施例的用于处理进来的消息或呼叫的处理的流程图。

图9是示出根据本发明的一个实施例的在处理进来的呼叫期间使用的数据库的框图。

图10是示出根据本发明的另一个实施例的业务上下文的例子的示图。

图11是示出根据一个实施例的提供用于处理进来的呼叫或消息的信息的用户接口的示图。

图12是数字处理系统的框图，该数字处理系统可以与本发明的实施例一起使用。

具体实施方式

这里描述了基于发送方和接收方之间的交互历史和上下文的动作预测的技术。在下面的描述中，阐述许多细节是为了提供对本发明实施例的更全面的解释。但是对于本领域技术人员来说，很显然没有这些特定的细节也可以实施本发明的实施例。在其它情况中，公知的结构和设备以框图形式示出，而不是具体示出，以避免使本发明的实施例变得难以理解。

说明书中提到“一个实施例”、“实施例”时，是指结合该实施例描述的具体特征、结构或特性包括在本发明的至少一个实施例中。在说明书中不同位置出现短语的“在一个实施例中”并不一定都是指代相同的实施例。

接下来，介绍特定的技术，用以考虑由与企业实体或机构相关的诸如企业资源规划(ERP)的企业信息系统(EIS)提供的信息来处理进来的呼叫或消息，所述技术包括：生成与呼叫方或发送方相关的适当的上下文，识别适当的用户或接收方以处理该进来的呼叫或消息，以及提供建议或预测特定的可以执行的进一步动作。

面向发送方和面向用户的动作生成

接下来，在呼叫参与者(例如消息的发送方和接收方，或者电话呼叫的呼叫方和接收方)之上建立业务上下文。因此，对于在诸如电话呼叫的通信中所涉及双方，存在面向发送方(例如呼叫方)和/或面向用户(例如接收方)。在一个实施例中，基于两个中心收集业务上下文，一个基于发送方，另一个基于接收方或潜在接收方。贯穿本申请，将电话呼叫用作在发送方(即呼叫方)和接收方(这里也称为用户)之间的通信的例子。然而，本发明不限于此。也可以应用其它类型的通信(例如电子邮件或即时消息等)。

在一个实施例中，使用面向用户的搜索引擎和面向呼叫方的搜索引擎构建交互历史(例如来自之前事务(transaction)的业务上下文的相关链接)生成器。面向用户的搜索引擎被配置成从用户工作中心和/或机构或企业实体的平面图(floor plan)搜索用户相关的链接。可以基于一个或多个规则(例如最频繁使用的链接)提取业务对象(BO)相关链接。在一个实施例中，面向呼叫方的搜索引擎被配置成从由呼叫方事务数据库或由基于之前事务的自学习引擎记录的呼叫方交互历史搜索用户/呼叫方相关链接。还可以基于一个或多个规则(例如以前呼叫方与各个用户交互的最频繁的相关链接)提取用户相关链接。在另一个实施例中，在该系统中可以实现附加的功能性，包括：选择机制，允许用户选择面向用户或面向呼叫方的相关链接；以及配置单元(例如业务配置)，用于配置面向用户或面向呼叫方的业务上下文。

图1是示出根据本发明实施例的用于处理通信消息的系统配置的框图。在一个实施例中，系统100包括但不限于处理逻辑，其响应于将由接收方通过网络从发送方接收的消息，确定与该发送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在在与该接收方相关联的实体中所执行的操作过程期间记录的。系统100还包括动作生成器，其链接到处理逻辑，用以基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表，以使得接收方能够选择将要执行的一个或多个动作候选，以响应发送方的消息。

参照图1，系统100包括一个或多个客户端101-102，其通过网络104可通信地连接到服务器103。出于示例的目的，客户端101-102是可通信地连接到通信中心103的呼叫方，所述通信中心103可以是与机构或企业实体相关联的呼叫中心。例如，呼叫方101-102可以是拥有和/或运行通信中心103的企业实体的客户。一个或多个用户106可以是企业实体的雇员或客户代表。用户106可以通过网络接收来自呼叫方101-102的呼叫，所述网络可以是PSTN(公共交换电话网)或数据网络(例如使用基于IP的话音传输技术，或VOIP技术的因特网)。

在一个实施例中，通信中心103可以可通信地连接到与企业实体相关联的企业信息系统(EIS)105。再次参照图1，在一个实施例中，服务器103可以包括连接到面向呼叫方的搜索引擎107和面向用户的搜索引擎108的动作生成器111，其响应于通过网络从呼叫方(例如呼叫方101-102)接收的进来的呼叫，生成与呼叫方和/或处理该进来的呼叫的潜在用户106(例如接收方)相关的通信上下文112。

在一个实施例中，响应于进来的呼叫，面向呼叫方的搜索引擎107和/或面向用户的搜索引擎108执行在一个或多个数据库(例如数据库109-110)中的搜索，所述数据库用于存储关于与该呼叫方和/或潜在用户相关联的业务事务的信息。例如，搜索引擎可以基于与呼叫方和/或用户相关联的特定因素，搜索和识别一个或多个可能适合处理特定呼叫方的进来的呼叫的用户。

在一个实施例中，面向呼叫方的搜索引擎107可以访问各个面向呼叫方的数据库109，并且面向用户的搜索引擎108可以访问各个面向用户的数据库110。数据库109-110可以由企业信息系统(EIS)维护，所述企业信息系统可以是ERP系统。注意，数据库109和110仅仅是出于示例的目的被示出的，它们也可以是单个数据库或多个数据库。此外，取决于具体的实现方式，搜索引擎107-108可以是EIS105的一部分。再有，服务器103和EIS105可以被实现为相同的服务器或服务器群。类似地，搜索引擎111-112可以是在同一数据库或不同的数据库中搜索的相同的搜索引擎。其它配置也可能存在。面向用户的数据库可以转变成面向呼叫方的数据库，其中在进来的呼叫中用户处于呼叫方位置，这与面向呼叫方的数据库类似。面向用户/呼叫方的数据库的核心属性是：它是这样的数据库，能够存储通信期间的所有业务事务，并且能够满足对于相关功能的面向人的搜索。再有，基于在面向用户或呼叫方的业务事务的第一次搜索，搜索通常可以采取另一个步骤，以进一步过滤与该用户或呼叫方的对方相关的业务事务。

在一个实施例中，响应于进来的呼叫，面向呼叫方的搜索引擎107基于进来的呼叫，生成与该呼叫方相关联的呼叫上下文(例如业务相关上下文)，包括例如呼叫方的姓名和电话号码以及与该呼叫方相关联的业务类型等。

此外，根据一个实施例，响应于进来的呼叫，面向呼叫方的搜索引擎107在面向呼叫方的数据库109中搜索与在该呼叫方和与通信中心103和/或EIS105相关联的企业实体之间的之前的事务相关联的任何信息。基于作为搜索结果的信息，生成与在相关链接上的呼叫方的之前的事务相关联的第一业务上下文。这是面向呼叫方的业务上下文数据库。

再有，根据另一个实施例，响应于进来的呼叫，面向用户的搜索引擎108基于之前的操作，在面向识别出的呼叫方的数据库110中进行搜索。基于作为所述搜索结果的信息，生成与在相关链接上的所述呼叫方和用户的之前的活动相关联的第二业务上下文。

基于该第二业务上下文，除了与该呼叫方相关联的一般上下文(例如图5的动作上下文501)之外，处理进来的呼叫的用户还可以利用相关链接上下文(例如图5的相关链接上下文502)之一或两者来处理进来的呼叫。在再一个实施例中，可以通过自学习引擎，基于业务上下文提取算法来生成相关链接上下文，该业务上下文提取算法将会确保，与其它使用频率低的业务上下文相比，使用频率高的业务事务会被首先生成。自学习引擎将基于一个或多个规则来执行这样的确定。注意，与服务器103和105相关联的一些或全部功能单元可以以软件、硬件或它们的组合来实现。也可以存在其它配置。

图2是示出根据本发明的一个实施例的用于处理进来的呼叫的处理的流程图。注意，处理200可以通过处理逻辑来执行，该处理逻辑可以包括软件、硬件或两者的组合。例如，处理200可以由图1的系统100的一个或多个功能单元来执行。在一个实施例中，处理200包括但不限于，响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方相关联的实体中执行操作的过程中被记录的，并且，基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表，以便接收方能够选择一个或多个将执行的动作候选，作为对发送方的消息的响应。

参照图2，在方框201，处理逻辑通过网络接收来自发送方或呼叫方的消息或进来的呼叫。仅仅出于示例的目的，将电话呼叫用作通信消息的例子。在方框202，处理逻辑在第一数据库(例如面向呼叫方的数据库)中搜索与相对于机构或企业实体的呼叫方相关联的历史事务，其中，接收方为所述机构或企业实体的雇员。在方框203，基本上是在那之后，处理逻辑在方框202识别出的数据库中搜索与相对于呼叫方的接收方相关联的历史事务。在方框204，处理逻辑基于搜索结果生成候选动作的列表。在方框205，将候选动作的列表提供给接收方或用户，以允许用户从该列表中选择一个或多个动作，以作为处理该进来的呼叫或消息的一部分。也可以执行其它的操作。

图3是是示出根据本发明的替代实施例的用于处理进来的消息的处理的示图。注意，处理300可以由处理逻辑来执行，该处理逻辑可以包括软件、硬件或它们的组合。例如，处理300可以由图1的系统100的一个或多个功能单元来执行。

参照图3，根据一个实施例，在方框301，当接收到进来的呼叫时，从进来的呼叫中提取呼叫方的身份(ID)。例如，可以从进来的呼叫中提取呼叫方的呼叫方ID或SIP(会话发起协议)地址。然后，由呼叫路由单元302将呼叫方ID路由到面向呼叫方的搜索引擎303或面向用户的搜索引擎304。基于呼叫方ID，面向呼叫方的搜索引擎303例如基于从系统所维护的且通过呼叫方ID识别出的呼叫方简档(profile)检索的信息，生成与呼叫方相关联的业务上下文305。在一个实施例中，面向呼叫方的搜索引擎303可以访问面向呼叫方的数据库以进行这样的操作。呼叫方的业务上下文305可以如方框306所示包括呼叫方的姓名和电话号码。此外，根据一个实施例，面向呼叫方的搜索引擎303还生成呼叫方的相关链接的交互历史307。

此外，根据一个实施例，在方框308，面向用户的搜索引擎304可以基于呼叫方ID，匹配具有与该呼叫方相关联的角色的任何用户。在一个实施例中，面向用户的搜索引擎304可以访问识别出的呼叫方数据库以进行这样的操作。例如，面向用户的搜索引擎304可以基于与呼叫方和/或呼叫方的位置(例如区域或国家)等相关联的业务类型匹配用户。匹配的或识别出的用户可以具有与呼叫方特性匹配的特定职责(responsibility)。结果，可以生成考虑到呼叫方而与用户相关联的相关链接。请注意，启动在面向呼叫方的数据库中的初始搜索和在面向用户的搜索中的初始搜索之间是有差别的。

根据特定实施例，在方框311，可以从工作中心309和/或工作中心309的平面图310收集或积累与用户相关联的相关链接。在方框312，从所积累的用户的相关链接中，提取被各个用户触发过的所有相关链接。在方框313，生成所提取的相关链接的业务上下文。在一个实施例中，可以仅仅使用被用户触发最频繁的特定相关链接来生成业务上下文(例如面向用户的业务上下文)。在一个实施例中，当如上下文317的部分320那样呼叫方未知时(例如未知的呼叫方ID或呼叫方没与该企业实体进行过任何业务)，这样的上下文可以在相关链接317中使用。

此外，在方框314，用户可以使用或选择上下文313和上下文307以生成相关链接的业务上下文316，所述相关链接例如由呼叫方触发的、并且由用户相关链接318提取的最频繁的相关链接，或者由用户触发的、并且由呼叫方相关链接319提取的最频繁的相关链接。当呼叫方已知时，可以使用上下文316来提供与相关链接317的部分321相关的信息。此外，可以使用自学习引擎315来基于相关链接307和313生成上下文316。

图4是示出根据本发明的一个实施例的在处理进来的呼叫期间使用的数据库的框图。参照图4，在一个实施例中，面向呼叫方的搜索引擎401和面向用户的搜索引擎402两者都被用于在数据库403中存储从呼叫方和用户之间的呼叫得到的交互数据，所述数据库403可以是位于本地或远程的单个数据库或多个数据库。

在一个实施例中，可以在联系人的文件夹的基础上机构数据库403。对于每个联系人，数据库403建立特定的文件夹，在该文件夹中存储与各个联系人相关的一些或全部交互历史。在一个实施例中，交互历史可以被分成至少两段(segment)。第一段是基于用户的(例如用户接收呼叫并触发对其它联系人的交互历史)。第二端是基于呼叫方的(例如，呼叫方触发进来的呼叫并且用户接收该呼叫)。

例如，当从客户(例如呼叫方)接收到进来的呼叫时，首先执行上下文搜索以识别用户业务上下文数据库。然后，利用基于频率和/或最近的事务的顺序从用户业务上下文数据库中过滤出呼叫方相关链接。之后，在用户接口示出作为业务上下文的相关链接，以使得用户能够选择它们中的任何一个以进行查看。

在一个实施例中，数据库403包括一组记录单元，例如包括单元404。在一个实施例中，记录单元404例如包括但不限于每次通信所涉及的通信方的简档405、时间407和持续时间406、基于一个和多个预定或预先默认的内容的触发记录(例如相关链接408的点击记录或“您也可以”链接409的点击记录)。

在一个实施例中，预先默认的内容是链接，通过该链接，用户可以访问定义的业务对象。在用户接口(例如入口)中示出业务对象之前，还可以通过呼叫方或用户来进一步提取业务对象。基于交互历史记录单元，系统能够通过由自学习引擎(例如图3中的自学习引擎315)执行的自学习处理提取用户期望的业务上下文。在业务配置期间预先默认的内容将被安装。当然，用户还可以为他/她的通信业务上下文数据库选择有限的内容。

再次参照图3，基于个性化切换触发模式和交互历史数据库提取模式(例如块314、316和318-319)构建自学习处理。面向呼叫方的搜索引擎303和面向用户的搜索引擎304可以聚集由用户或呼叫方触发过的大部分或全部交互历史。

根据一个实施例，交互历史数据库提取模式可以包括但不限于通过呼叫方的电话号码或SIP地址来提取联系人、基于定义的联系人提取联系人的交互历史数据库、和从交互历史数据库中以频率顺序或日期和时间顺序提取触发记录(基于一个或多个配置规则)。在按照频率提取、并且两个或多个触发记录频率相同的情况下，可以进一步提取日期和时间，以将其用作优先因子(priority factor)。

根据另一个实施例，个性化切换触发模式可以包括通过呼叫方的电话号码或SIP地址提取联系人，基于定义的联系人提取联系人的个性化切换记录，并按频率或按日期和时间列出切换记录(基于一个或多个配置规则)。在按照频率提取、并且存在频率相同的两个或多个切换记录的情况下，可以进一步提取日期和时间，以将其用作优先因子。

在一个实施例中，自学习处理由个性化切换触发模式在识别呼叫方之后启动。对于不同的呼叫方，自学习处理基于个性化切换触发模式，生成对于面向呼叫方的搜索或面向用户的搜索的用户偏好。此后，可以执行交互历史数据库提取模式来进一步识别相关联的业务上下文。

当呼叫方已知时，根据一个实施例，基于用户偏好，经由默认的面向呼叫方的搜索引擎或面向用户的搜索引擎搜索各个呼叫的业务上下文。当呼叫方未知时，经由面向呼叫方的搜索引擎进行搜索是不可行的。在这种情况下，可以基于面向用户的信息(例如提取用户之前执行得最频繁的触发记录)搜索业务上下文。在一个实施例中，基于呼叫方和用户的角色(例如客户对销售代表)，预先默认的内容322可以被用作数据库的输入。也可以存在其它配置。

动作预测实施例

根据特定实施例，动作预测器被设计成生成到正与特定呼叫方通信的用户的可能的动作链接。动作预测器是在面向用户的搜索引擎以及面向呼叫方的搜索引擎之上构建的。与上面描述的类似，在一个实施例中，面向用户的搜索引擎被配置成从用户的工作中心，包括工作中心的平面图，搜索用户相关动作。之后，可以基于一个或多个规则，诸如例如最频繁使用的链接，来提取BO(业务对象)相关的“您也可以”。

在一个实施例中，面向呼叫方的搜索引擎被配置成从呼叫方事务数据库记录的呼叫方交互历史中搜索呼叫方和用户相关链接。可以基于一个或多个规则(例如，呼叫方与用户交互的最频繁的相关链接)来提取相关链接。其它的功能性也可以添加到所述系统，包括：1)来自可以生成可能的动作链接的语音交互应用的关键词捕捉器(catcher)；2)作为下一操作的指导动作，；3)对于用户选择面向用户的或面向呼叫方的动作链接的切换；以及4)用于设置面向用户的或面向呼叫方的业务上下文的业务配置。

图6是示出根据本发明的一个实施例的用于处理通信消息的系统配置的框图。在一个实施例中，系统600包括但不限于：处理逻辑，用于响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方相关联的实体中执行的操作过程中被记录的；动作生成器，被连接用于基于所确定的一个或多个之前的事务，生成要求采取的一个或多个动作；以及动作预测器，被连接用于基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表，其中，所述一个或多个动作候选是指，除了响应于所述消息的一个或多个要求动作之外，向接收方推荐的可选动作。

参照图6，系统600包括通过网络604可通信地连接到服务器603的一个或多个客户端601-602。出于示例的目的，客户端601-602是可通信地连接到通信中心603的呼叫方，通信中心603可以是与机构或企业实体相关联的呼叫中心。例如，呼叫方601-602可以是拥有和/或运行通信中心603的企业实体的客户。一个或多个用户606可以是企业实体的雇员或客户代表。用户606可以通过网络接收来自呼叫方601-602的呼叫，所述网络可以是PSTN(公共交换电话网)或数据网络(例如使用基于IP的话音传输技术，或VOIP技术的因特网)。

在一个实施例中，通信中心603可以可通信地连接到与企业实体相关联的企业信息系统(EIS)605。EIS用于维护有关企业实体的运转的信息。例如，EIS可以是企业资源规划(ERP)系统的一部分。在一个实施例中，服务器603可以包括连接到面向呼叫方的搜索引擎607和面向用户的搜索引擎608的动作生成器611，其响应于通过网络从呼叫方(例如呼叫方601-602)接收的进来的呼叫，生成与呼叫方和/或处理该进来的呼叫的潜在用户606(例如接收方)相关的通信上下文612。

在一个实施例中，响应于进来的呼叫，面向呼叫方的引擎607和/或面向用户的搜索引擎608执行在一个或多个数据库(例如数据库609-610)中的搜索，所述数据库用于存储关于与该呼叫方和/或潜在用户相关联的业务事务的信息。例如，搜索引擎可以基于与呼叫方和/或用户相关联的特定因素，搜索和识别一个或多个可能适合处理特定呼叫方的进来的呼叫的用户。

在一个实施例中，面向呼叫方的搜索引擎607可以访问各个面向呼叫方的数据库609，并且面向用户的搜索引擎608可以访问各个面向用户的数据库610。数据库609-610可以由企业信息系统(EIS)维护，所述企业信息系统可以是ERP系统。注意，数据库609和610仅仅是出于示例的目的被示出的，它们也可以是单个数据库或多个数据库。此外，取决于具体的实现方式，搜索引擎607-608可以是EIS605的一部分。再有，服务器603和EIS605可以被实现为相同的服务器或服务器群。类似地，搜索引擎611-612可以是在同一数据库或不同的数据库中搜索的相同的搜索引擎。其它配置也可能存在。

在一个实施例中，响应于进来的呼叫，面向呼叫方的搜索引擎607基于进来的呼叫，生成与该呼叫方相关联的呼叫上下文(例如业务相关上下文)，包括例如呼叫方的姓名和电话号码以及与该呼叫方相关联的业务类型等。

此外，根据一个实施例，响应于进来的呼叫，面向呼叫方的搜索引擎607在面向呼叫方的数据库609中搜索与在该呼叫方和与通信中心603和/或EIS605相关联的企业之间的之前的事务相关联的任何信息。基于作为搜索结果的信息，生成与有关相关链接的呼叫方的之前的事务相关联的第一业务上下文。这是面向呼叫方的业务上下文数据库。

再有，根据另一个实施例，响应于进来的呼叫，面向用户的搜索引擎608在面向用户的数据库610中搜索与所述企业实体中的用户所执行的之前的活动相关的任何信息。所述活动可以与在企业实体中的操作过程中用户的特定角色相关。基于作为搜索结果的信息，生成与在相关链接上的用户之前的活动相关联的第二业务上下文。

基于该第一和第二业务上下文，除了与该呼叫方相关联的一般上下文之外，处理进来的呼叫的用户还可以利用相关链接上下文(例如图10的相关链接上下文1001)之一或两者来处理进来的呼叫。在另一个实施例中，可以通过自学习引擎，基于业务第一和第二业务上下文生成相关链接上下文。所述自学习引擎可以基于一个和多个规则来执行这样的确定。

此外，根据一个实施例，系统600还包括动作预测器614，其可以实现为动作生成器611的一部分，或者可以实现为可通信地连接到动作生成器611的分离的功能单元。在处理进来的呼叫中，动作预测器614可以被配置成生成除了要求的那些操作之外的被推荐给用户的(例如可选的)附加动作项目。动作预测器614可以依靠从进来的呼叫中提取的特定信息、搜索引擎607和/或608的结果、以及自学习引擎613的结果。结果，用户能够执行特定的要求的动作，以及如图10的动作1002示出的“您还可以”执行的特定动作。注意，与服务器603和605相关联的一些或全部功能单元可以以软件、硬件或两者的组合来实现。其它的配置也可以存在。

图7是示出根据本发明的一个实施例的用于处理进来的消息或呼叫的处理的流程图。注意，处理700可以通过处理逻辑来执行，该处理逻辑可以包括软件、硬件或两者的组合。例如，处理700可以由图6的系统600的一个或多个功能单元来执行。在一个实施例中，处理700包括但不限于，响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方相关联的实体中执行操作的过程中被记录的，并且，基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表，其中，所述一个或多个动作候选是除了响应于所述消息要求采取的一个或多个动作之外，推荐给接收方的可选的动作。

参照图7，在方框701，处理逻辑接收来自发送方的、将由企业实体或机构的接收方或用户接收的消息(例如来自呼叫方的进来的呼叫)。在方框702，处理逻辑在第一数据库(例如面向呼叫方的数据库)中搜索与相对于接收方的发送方相关联的历史事务。在方框702，基本并行地，处理逻辑基于所识别的数据库(面向用户的数据库)，搜索与接收方相关联的历史事务(例如考虑企业实体中用户的角色)。注意，为了从数据库中搜索可能的动作，将默认使用面向用户的数据库，然后将进一步通过呼叫方来过滤。在方框703，处理逻辑基于在面向用户的数据库中搜索的搜索结果，生成用户有可能采取的动作候选的列表(例如“您还可以”执行动作项目的选项)。在操作705，除了那些要求采取的动作或相关链接之外，还将候选动作提供给用户以供选择。也可以执行其它的操作。

图8是示出根据替代实施例的用于处理进来的消息或呼叫的处理的流程图。注意，处理800可以由处理逻辑来执行，该处理逻辑可以包括软件、硬件或它们的组合。例如，处理800可以由图6的系统600的一个或多个功能单元来执行。

参照图8，根据一个实施例，在方框801，当接收到进来的呼叫时，从进来的呼叫中提取呼叫方的身份(ID)。例如，可以从进来的呼叫中提取呼叫方的呼叫方ID或SIP(会话发起协议)地址。然后，由呼叫路由单元802将呼叫方ID路由到面向用户的搜索引擎804或面向呼叫方的搜索引擎803。基于市场调查，与呼叫方相比，通信中的动作更多的取决于用户。基于呼叫方ID，面向用户的搜索引擎804生成与用户相关联的业务上下文，然后，与上面提到实施例类似，例如基于从系统所维护的并且通过呼叫方ID识别出的呼叫方简档中提取的信息，通过呼叫方进一步进行提取。在一个实施例中，面向用户的搜索引擎804可以访问面向用户的数据库以进行这样的操作。用户的业务上下文可以包括用户的姓名和电话号码。此外，根据一个实施例，面向用户的搜索引擎804还生成可选动作或“您还可以”动作选项813的交互历史。

此外，根据一个实施例，在方框808，在进来的呼叫处于迷路(in lost)状态的情况下，面向用户的搜索引擎804可以基于呼叫方ID，匹配具有与该呼叫方相关联的相似角色的任何用户。在一个实施例中，面向用户的搜索引擎804可以访问面向用户的数据库以进行这样的操作。例如，面向用户的搜索引擎804可以基于与呼叫方和/或呼叫方的位置(例如区域或国家)等相关联的业务类型匹配用户。匹配的或识别出的用户可以具有与呼叫方特性匹配的特定职责。结果，可以生成考虑到呼叫方而与用户相关联的相关链接。

根据特定实施例，可以从工作中心809和/或工作中心809的平面图收集或积累与用户相关联的相关链接。从所积累的用户的相关链接中，提取被各个用户触发过的所有相关链接。在一个实施例中，在方框833，可以从用户的各个工作中心提取由特定用户执行的特定公共任务。在方框813，生成所提取的相关链接的业务上下文。在一个实施例中，仅仅被用户触发最频繁的特定相关链接可以被用来生成业务上下文(例如面向用户的业务上下文)。在一个实施例中，当作为上下文830的部分832的呼叫方未知时(例如未知的呼叫方ID或呼叫方没与该企业实体进行过任何业务)，这样的上下文可以在“您也可以”上下文830中使用。

此外，在方框814，用户可以使用或选择上下文813和上下文807以生成“您也可以”链接的业务上下文816，所述“您也可以”链接是例如由呼叫方触发的、并且由用户相关链接818提取的最频繁的相关链接，或者由用户触发的、并且由呼叫方相关链接819提取的最频繁的相关链接。当呼叫方已知时，可以使用上下文816来提供与“您也可以”链接830的部分831相关的信息。此外，可以使用自学习引擎815来基于相关链接807和813生成上下文816。

此外，根据另一个实施例，系统840还包括连接到面向呼叫方的搜索引擎803的语音处理单元840，以进一步处理语音相关信息。语音处理单元840可以以软件、硬件或两者的组合来实现。在一个实施例中，语音处理单元840包括但不限于语音应用(例如语音识别应用)841、关键词识别器842、和BO主题提取器843。例如，语音应用841可以用于将语音流转换成文本。关键词识别器842可以用于从经转换的文本中识别一个或多个关键词。BO主题提取器843可以用于基于识别出的关键词提取一个或多个BO主题。所述BO主题可以由自学习引擎815在确定上下文816时使用。

在接收到进来的呼叫之后，面向呼叫方的搜索引擎803通过交互历史数据库(例如方框807)和语音处理系统840两者识别可能的业务上下文。通过由自学习引擎815基于从交互历史数据库中提取的信息执行的自学习处理，系统生成供用户考虑的最推荐动作。通过语音处理系统840，系统还生成附加的推荐动作。

根据另一个实施例，系统800还包括指导调整器(guided adjuster)844，以考虑呼叫方交互历史上下文807来调整由语音处理系统840生成的特定指导动作，以便生成更好地适合真实生活业务情景的动作。

在一个实施例中，系统800还基于业务角色或情景提供预先默认的内容822。一部分内容与一个或多个工作中心中的公共任务一致(in line)，或者与一个或多个业务对象平面图中的“您也可以”动作一致，另一些内容则基于与可能的通信场景相关的特定业务对象(BO)实例。

通过语音处理系统840，一个用户与相同呼叫方或客户在不同时间谈话的业务上下文内容可能不同。因为语音处理系统840生成新的参考点，以作为情景停留在哪个业务处理阶段的参考。

对于未知的呼叫方(例如不能从进来的呼叫或消息中获得呼叫方ID或SIP地址)，相同的用户可以在“您还可以”动作具有相同的业务上下文；然而，取决于基于交互历史数据库的自学习处理的结果，它也可以有所不同。可以存在其它的配置。

图9是示出根据本发明的一个实施例的在处理进来的呼叫期间使用的数据库的框图。参照图9，在一个实施例中，面向呼叫方的搜索引擎901和面向用户的搜索引擎902两者被用于将从呼叫方和用户之间的呼叫得到的交互数据存储在数据库903中，所述数据库903可以是位于本地或远程的单个数据库或多个数据库。

在一个实施例中，可以在联系人的文件夹的基础上组织数据库903。对于每个联系人，数据库903建立特定的文件夹，在该文件夹中存储与各个联系人相关的一些或全部交互历史。在一个实施例中，交互历史可以被分成至少两段。第一段是基于用户的(例如用户接收呼叫并触发对其它联系人的交互历史)。第二段是基于呼叫方的(例如，呼叫方触发进来的呼叫并且用户接收该呼叫)。

在一个实施例中，数据库903包括一组记录单元，例如包括单元904。在一个实施例中，记录单元904例如包括但不限于每次通信所涉及的通信方905的简档、时间907和持续时间906、基于一个和多个预定或预先默认的内容(诸如内容822)的触发记录(例如相关链接908的点击记录或“您也可以”链接909)。

在一个实施例中，预先默认的内容是链接，通过该链接，用户可以访问定义的业务对象。在用户接口(例如入口)中示出业务对象之前，还可以通过呼叫方或用户来进一步提取业务对象。基于交互历史记录单元，系统能够通过由自学习引擎(例如图8中的自学习引擎815)执行的自学习处理来提取用户期望的业务上下文。此外，在方框910，预先默认的内容可用来识别业务情景，以帮助语音识别系统840生成附加的推荐动作，以作为“您也可以”动作项目的一部分。

再次参照图8，基于个性化切换触发模式和交互历史数据库提取模式(例如块814、816和818-819)构建自学习处理。面向呼叫方的搜索引擎803和面向用户的搜索引擎804可以聚集由用户或呼叫方触发过的大部分或全部交互历史。

根据一个实施例，交互历史数据库提取模式可以包括但不限于通过呼叫方的电话号码或SIP地址来提取联系人、基于定义的联系人提取联系人的交互历史数据库、和从交互历史数据库中以频率顺序或日期和时间顺序提取触发记录(基于一个或多个配置规则)。在按照频率提取、并且两个或多个触发记录频率相同的情况下，可以进一步提取日期和时间，以将其用作优先因子。

根据另一个实施例，个性化切换触发模式可以包括通过呼叫方的电话号码或SIP地址提取联系人，基于定义的联系人提取联系人的个性化切换记录，并按频率或按日期和时间列出切换记录(基于一个或多个配置规则)。在按照频率提取、并且存在频率相同的两个或多个切换记录的情况下，可以进一步提取日期和时间，以将其用作优先因子。

在一个实施例中，自学习处理由个性化切换触发模式在识别呼叫方之后启动。对于不同的呼叫方，自学习处理基于个性化切换触发模式，生成面向呼叫方的搜索或面向用户的搜索的用户偏好。此后，可以执行交互历史数据库提取模式来进一步识别相关联的业务上下文。

当呼叫方已知时，根据一个实施例，经由面向呼叫方的搜索引擎搜索各个呼叫的业务上下文。当呼叫方未知时，经由面向呼叫方的搜索引擎进行搜索是不可行的。在这种情况下，可以基于面向用户的信息(例如提取用户之前执行的最频繁的触发记录)搜索上下文。在一个实施例中，基于呼叫方和用户的角色(例如客户对销售代表)，预先默认的内容822可以被用作数据库的输入。也可以存在其它配置。

图11是示出根据一个实施例的提供用于处理进来的呼叫或消息的信息的用户接口的示图。例如，GUI1100可以与如上所述的系统，诸如例如图1的系统100和/或图6的系统600，一起使用。如图11的GUI1100所示，相关链接信息1101和“您还可以”信息1102可以被生成和提供。注意，GUI1100仅仅是出于示例的目的被示出；也可以实现GUI的其它格式或布局。

数据处理系统的例子

图12是数字处理系统的框图，该数字处理系统可以与本发明的一个实施例一起使用。例如，系统1200可以用作以上参照图1和6描述的客户端和/或服务器。注意，尽管图12示出了计算机系统的不同组件，但是其并不是想要代表互连所述组件的任何具体体系结构或方式；因为这些细节与本发明并非密切相关。应当会理解到，网络计算机、手持计算机、蜂窝电话和其它具有较少或可能更多组件的数据处理系统都可以与本发明一起使用。

如图12所示，作为数据处理系统的一种形式的系统1200包括总线或互连线1202，其连接到一个或多个微处理器1203和ROM1207、易失性RAM1205和非易失性存储器1206。微处理器1203可以是例如PowerPC微处理器或Intel兼容处理器，如图12的例子所示，其连接到高速缓冲存储器1204。总线1202将这些不同的组件相互连接在一起，并且还将这些组件1203、1207、1205和1206与显示控制器和显示设备1208、以及输入/输出(I/O)设备1210相互连接，所述I/O设备1210可以是鼠标、键盘、调制解调器、网络接口、打印机和本领域公知的其它设备。

典型地，输入/输出设备1210通过输入/输出控制器1209连接到系统。易失性RAM 1205被典型地实现为动态RAM(DRAM)，其要求持续的电源，以便刷新或维持存储器中的数据。非易失性存储器1206典型地为磁性硬盘驱动器，磁光驱动器、光驱动器或DVD RAM或即使在从系统去除电源之后仍能维持数据的其它类型的存储器系统。典型地，非易失性存储器也将是随机存取存储器，尽管并不要求如此。

尽管图12示出了非易失性存储器为直接连接到数据处理系统中的其它组件的本地设备，但是，本发明也可以利用远离系统的非易失性存储器。例如，通过诸如调制解调器或以太网口的网络接口连接到数据处理系统的网络存储设备。总线1202可以包括通过各种桥、控制器和/或适配器彼此连接的一个或多个总线，如本领域中公知的那样。在一个实施例中，I/O控制器1209包括用于控制USB(通用串行总线)外围设备的USB适配器。或者，I/O控制器1209可以包括用于控制FireWire设备的IEEE-1394适配器，其也称为FireWire适配器。

EIS和ERP系统概述

可以用于上文描述的本发明的实施例的EIS一般指任何类型的“企业级”的计算系统。这意味着典型地提供高质量的服务，处理大量数据(例如，能够支持一些相对大型的机构，也称为“企业”)。

EIS系统提供技术平台，使得机构能够整合和协调其业务处理。它们在逻辑上提供对机构来说是中枢的单个系统，并且确保信息能够在所有功能级和管理层次之间共享。通过创建标准的数据结构，企业系统在消除由机构中多个信息系统引起的信息碎片化问题方面的价值无法估量。

典型地，EIS会由专业的系统管理员操作，并且部署在专用的服务器上。它典型地提供网络连接，并提供服务，以支持企业所执行的操作。例如，EIS可以包括企业资源规划(ERP)系统。ERP系统将机构的大多数或所有数据和处理整合(或试图整合)成逻辑上统一的系统。典型的ERP系统使用计算机软件和/或硬件的多个组件来实现整合。大多数ERP系统的关键要素是使用逻辑上单一的、统一的数据库来保存各种系统模块的数据，尽管该数据库或数据可以本地管理或通过网络远程管理。

术语ERP最初是指被设计成规划企业范围的资源利用的系统。尽管首字母缩写词ERP起源于制造界，但今天术语ERP系统具有宽得多的使用范围。ERP系统典型地试图覆盖机构的所有基本功能，而不管机构的业务或规章如何。商业、非营利机构、非政府机构、政府和其它大型实体都使用ERP系统。

另外，可能会注意到，在被视为ERP系统时，包(package)(可以包括软件、硬件或两者的组合)一般只需要提供单个包中的功能性，而这通常由两个或更多系统覆盖。技术上，认为提供工资单和帐目管理这两项功能的包是ERP包。

然而，该术语一般被保留给更大、基础更广的应用。引入ERP系统以取代两个或更多个独立应用消除或减少了对于以前系统之间要求的外部接口的需要，并且提供了额外的好处，其范围从标准化和低成本维护(一个系统而非两个或更多)到更容易和/或更强大的报告能力(因为所有数据典型地逻辑上保存在一个数据库中)。

ERP中的以前曾经是孤立应用的模块的示例包括但不局限于制造、供应链、财务、CRM(客户关系管理)、人力资源和仓库管理等。ERP是交叉功能和企业范围的。操作或生产中涉及的所有功能部门整合在一个系统中(逻辑上)。除了制造、仓储、后勤和信息技术(IT)以外，它还包括财会、人力资源、营销和战略管理。

最佳方法(best practice)也是实现ERP系统的好处。当实现ERP系统时，机构本质上要进行选择，即，定制软件，或者将其业务处理修改成软件普通版中提供的“最佳方法”功能。一些人将最佳方法当作商业时髦用语，用来描述开发和遵循做事情的标准方式的处理，所述标准方式多个机构都可以使用以用于管理、策略、特别是软件管理。

考虑最佳方法在今天的计算机系统，特别是MOM(营销操作管理)系统中的应用。选择最佳方法(它是否真的是最佳)，并将其实现到计算机系统中。这允许执行类似任务的多个机构能够将相同的软件用于它们的任务。

MOM是从规划和预算、到营销内容管理、到全球营销执行和分析的端到端的营销优化方案。其特征在于，尝试实现对营销投资(ROMI)的可测量和可跟踪的反馈(return)，并且，作为实现这种反馈的方法，创建营销仪表板(dashboard)。营销仪表板的概念是，营销管理人员、或者甚至是机构中的任何雇员都能够登录到系统中，所述系统显示所有正在进行的营销活动的状态-在汽车模拟(automotive analogy)中显示“油耗”(花费)、“速度”(销售)以及各种其它度量。营销资源管理(MRM)业，包括软件厂家，提供软件基础结构，以便为机构提供营销操作管理方面的帮助。这形成了对于有效的营销操作管理策略来说非常关键的对人员、处理和技术的基本调整的技术支柱。

人力资源是最佳方法的一个好示例，如在大多数MOM系统中所证明的那样。在管理机构的雇员、志愿者和合同工中涉及无数的方式和大量的处理。通过选择组织和执行处理的“最佳方法”或标准方式，MOM系统或HRMS(人力资源管理系统)软件的制作者能够创造可以由多个机构使用的系统。

在本上下文中，最佳方法实现方式的好处往往在于，为流程设计(或者更恰当的说是演进)欠佳的机构提供以下选择：对其系统进行(一般来说)昂贵的修改，或者选择遵循最佳方法。最佳方法随时间的变化是ERP系统生命周期的主要动力。许多主要软件的发布都是在业内最佳方法的变化或引入下推进的。上世纪巨大的技术变化速度推动了快速适应和多样的最佳方法。

上文所描述的一部分可以通过诸如专用逻辑电路的逻辑电路，或通过微控制器或执行程序代码指令的其它形式的处理核来实现。因而，上述讨论所教导的处理可以通过程序代码来执行，所述程序代码例如机器可执行指令，其导致执行这些指令的机器来执行特定的功能。在本上下文中，“机器”可以是把中间形式(或“抽象”)指令转换成处理器特定指令(例如，诸如“虚拟机”(例如，Java虚拟机)的抽象执行环境、翻译器、Common LanguageRuntime、高级语言虚拟机等)的机器，和/或布置在半导体芯片(例如，用晶体管实现的“逻辑电路”)上用于执行指令的电子电路，例如通用处理器和/或专用处理器。上述讨论教导的处理也可以由设计成执行处理(或其一部分)而不执行程序代码的电子电路(替代机器或与机器结合)来执行。

相信，上文的讨论教导的处理也可以用由各种软件开发框架(例如，微软公司的.NET、Mono、Java、甲骨文公司的Fusion等)支持的各种面向对象或非面向对象的计算机编程语言(例如，Java、C#、VB、Python、C、C++、J#、APL、Cobol、ABAP、Fortran、Pascal、Perl等)的源程序代码来描述。源程序代码可以转换成抽象执行环境(例如，Java虚拟机、Common LanguageRuntime、高级语言虚拟机、翻译器等)可以理解的中间形式程序代码(例如Java字节代码、微软中间语言等)，或者针对特定处理器的更特定形式的程序代码。

前面详细描述中的一些部分以对计算机存储器内数据比特操作的算法和符号表现形式呈现。这些算法的描述和表现形式是数据处理领域的技术人员所使用的、以便最有效地把他们工作的实质传达给本领域其他技术人员的方式。在这里，一般来讲，算法被认为是带来期望结果的前后一致的操作序列。操作是指那些要求对物理量的物理处理的操作。通常，尽管不是必须的，这些量采用能够被保存、传输、组合、比较以及以其它方式处理的电或磁信号的形式。已经证明，有时称这些信号为比特、值、元素、符号、字符、术语、数字等很方便，主要是由于通用的原因。

然而，应该记住，所有这些和类似术语都与适当的物理量相关联，并且只是适用于这些量的方便标志。除非特别说明，否则如根据上文的讨论显而易见地，应当理解，贯穿说明书，使用诸如“处理”或“计算”或“确定”或“显示”等术语的讨论，是指计算机系统和类似的电子计算设备的动作和处理，所述计算机系统或类似的电子设备将计算机系统的寄存器和存储器内表示为物理(电子)量的数据处理和转换成计算机系统存储器或寄存器或其它这样的信息存储、传输或显示设备内类似地表示为物理量的其它数据。

这里，本发明的实施方式还涉及一种用于执行操作的装置。该装置可以为要求的目的特殊构造，或者它可以包括由保存在计算机中的计算机程序选择性激活或重配置的通用计算机。这样的计算机程序可以保存在计算机可读存储介质中，例如但不局限于任何类型的盘，包括软盘、光盘、CD-ROM、磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、可擦除可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)、磁或光卡或适于保存电子指令并且分别连接到计算机系统总线的任何类型的介质。

这里提供的算法和显示并非固有地与任何特定计算机或其它装置相关。根据这里的教导，各种通用系统都可以与程序一起使用，或者可以证明构建更专门的设备来执行要求的方法操作很便利。从以下的描述中将出现这些各种系统所要求的结构。另外，本发明的实施方式并非参考任何特定的编程语言来描述的。可以理解，各种编程语言都可以用来实现这里描述的本发明实施方式的教导。

机器可读介质可以包括用于以机器(例如计算机)可读的形式保存或传输信息的任何介质。例如，机器可读介质包括只读存储器(“ROM”)；随机存取存储器(“RAM”)；磁盘存储介质；光存储介质；闪存设备；电、光、声或其它形式的传播信号(例如，载波、红外信号、数字信号等)等。

在以上的说明书中，已经参照本发明的特定示例实施例对本发明的实施例进行了描述。很显然，可以对本发明实施例进行各种修改，而不会脱离所附权利要求书中阐述的本发明的更宽的精神和范围。因此，说明书和附图仅仅被认为是示例性的，而不是限制性的。

Claims (10)

1.一种数据处理方法，包括：

响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方相关联的实体中执行的操作的过程期间被记录的；以及

基于所确定的一个或多个之前的事务，生成一个或多个交互历史链接的候选的列表，以使得接收方能够选择将被执行的动作候选中的一个或多个，以便对发送方的消息做出响应，

其中，确定一个或多个之前的事务包括：

在业务上下文数据库中执行第一搜索，以识别与相对于所述实体的发送方相关联的第一之前事务；以及

基于所识别的第一之前事务执行第二搜索，以识别与所述接收方相关联的第二之前事务，其中，所述动作候选的列表是基于与发送方和接收方相关联的第二之前事务生成的。

2.如权利要求1所述的方法，其中，只有在识别了第一之前事务的情况下才执行第二搜索，其中，如果不能识别第一之前事务，则：

在业务上下文数据库中执行第三搜索，以识别与接收方相关联的第三之前事务；以及

基于识别出的第三之前事务执行第四搜索，以识别与发送方相关联的第四之前事务，其中，所述动作候选的列表是基于与发送方和接收方相关联的第四之前事务生成的。

3.如权利要求2所述的方法，还包括：

向接收方提供第二和第四之前事务，以使接收方能够选择该第二和第四之前事务中的至少一部分；以及

基于接收方的选择，生成第一事务上下文，该第一事务上下文表示与所述动作候选的至少一部分链接的、与发送方相关联的一个和多个相关链接。

4.如权利要求3所述的方法，还包括：响应于访问所述第二和第四搜索，生成第二事务上下文，所述第二事务上下文具有与所述动作候选的至少一部分相关的一个或多个链接，并且所述一个或多个链接与接收方所触发的一个或多个事件相关联。

5.如权利要求4所述的方法，还包括：确定在实体中接收方的一个或多个角色，其中，所述第二事务上下文是基于所确定的接收方的一个或多个角色生成的。

6.如权利要求1所述的方法，还包括：基于从所述消息提取的发送方的身份(ID)，生成与该消息相关联的事务上下文，并且其中，所述动作候选链接到所述事务上下文的至少一部分内容。

7.如权利要求1所述的方法，其中，所述实体是企业实体，并且其中，所述之前事务的信息是从与该企业实体相关联的企业信息系统EIS提供的，该EIS系统包括至少企业资源规划ERP系统。

8.一种数据处理系统，包括：

处理器，其响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方相关联的实体中执行的操作的过程期间被记录的；

连接到所述处理器的动作生成器，其基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表，以使得接收方能够选择将被执行的动作候选中的一个或多个，以便对发送方的消息做出响应；

连接到所述处理器的第一搜索引擎，其在业务上下文数据库中进行搜索，以搜索与相对于所述实体的发送方相关联的第一之前事务；以及

连接到所述处理器的第二搜索引擎，其基于所识别的第一之前事务进行搜索，以识别与所述接收方相关联的第二之前事务，其中，所述动作候选的列表是基于与发送方和接收方相关联的第二之前事务生成的。

9.如权利要求8所述的系统，还包括：

用户接口，其向接收方提供第一和第二之前事务，以使接收方能够选择该第一和第二之前事务中的至少一部分；以及

第一上下文生成器，其基于接收方的选择，生成第一事务上下文，该第一事务上下文表示与所述动作候选的至少一部分链接的、与发送方相关联的一个和多个相关链接。

10.如权利要求9所述的系统，还包括第二上下文生成器，其响应于访问另一个业务上下文数据库，生成第二事务上下文，所述第二事务上下文具有与所述动作候选的至少一部分相关的一个或多个链接，并且所述一个或多个链接与接收方所触发的一个或多个事件相关联。

Images