基于发送方与接收方之间的交互历史和上下文的动作预测的制作方法

专利名称：基于发送方与接收方之间的交互历史和上下文的动作预测的制作方法
技术领域：
本发明总体上涉及数据处理。更具体地说，本发明涉及基于消息发送方 和接收方关系的动作预测。
背景技术：
当业务用户在多方之间进行交互时(例如接到客户打来的电话)，该业务 用户希望看到该用户与客户之间的交互历史，以便总是能在通信过程中做好 准备。然而，在真实世界中，用户仅仅能够通过点击不同网页上的若干按钮 在网站上进行查看。此外，不能找到完整的客户相关链接。
电话通信的业务上下文与双方(例如发送方和接收方)之间讨论的特定 主题密切相关。主题通常由一方发起，并且可以根据需要变成另一个主题。 根据市场分析，固定通信方之间的主题相对稳定。然而，这种相关信息通常 不能在传统的通信系统中获得，传统的通信系统只能让用户手动搜索客户相 关信息的片断。
此外，当用户接收到从客户打来的电话时，用户希望系统生成直接触发
对客户的动作的动作链接，而不是访问入口(portal)，打开OIF(例如位于不 同应用的若干网页)，以及必须输入相关客户数据。这样的系统将增加用户生 产率。然而，在传统系统中，用户只能通过釆取若千步骤在入口中查看，这 会被认为是非常低的生产率
发明内容
术。在一个实施例中，处理包括但不限于响应于由接收方通过网络从发送 方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务 (transaction),所述一个或多个之前的事务是在与接收方相关联的实体中执 行的操作的过程期间被记录的；以及基于所确定的一个或多个之前的事务，
生成一个或多个动作候选的列表，其中所述一个或多个动作候选是除了响应 于所述消息需要采取的一个或多个动作之外，推荐给接收方的可选动作。 通过附图以及随后的具体描述，本发明的其它特征将变得明显。


附图中以示例的方式而非限制的方式示出了本发明，附图中，相似的参 考标记指示相似的元素。
图1是示出根据本发明的一个实施例的用于处理通信消息的系统配置的 框图。
图2是示出根据本发明的一个实施例的用于处理进来的呼叫(incoming call)的处理的流程图。
图3是示出根据本发明的替代实施例的用于处理进来的呼叫的处理的示图。
图4是示出根据本发明的一个实施例的在处理期间使用的数据库的框图。
图5是示出根据本发明的 一 个实施例的业务上下文的例子的示图。 图6是示出根据本发明的一个实施例的用于处理通信消息的系统配置的 框图。
图7是示出根据本发明的一个实施例的用于处理进来的消息或呼叫的处 理的流程图。
图8是示出根据替代实施例的用于处理进来的消息或呼叫的处理的流程图。
图9是示出根据本发明的一个实施例的在处理进来的呼叫期间使用的数 据库的框图。
图10是示出根据本发明的另 一 个实施例的业务上下文的例子的示图。 图11是示出根据一个实施例的提供用于处理进来的呼叫或消息的信息的用户"t妾口的示图。
图12是数字处理系统的框图，该数字处理系统可以与本发明的实施例一 起使用。
具体实施例方式
这里描述了基于发送方和接收方之间的交互历史和上下文的动作预测的 技术。在下面的描述中，阐述许多细节是为了提供对本发明实施例的更全面 的解释。但是对于本领域技术人员来说，很显然没有这些特定的细节也可以 实施本发明的实施例。在其它情况中，公知的结构和设备以框图形式示出， 而不是具体示出，以避免使本发明的实施例变得难以理解。
说明书中提到"一个实施例"、"实施例"时，是指结合该实施例描述的 具体特征、结构或特性包括在本发明的至少一个实施例中。在说明书中不同 位置出现短语的"在一个实施例中"并不一定都是指代相同的实施例。
接下来，介绍特定的技术，用以考虑由与企业实体或机构相关的诸如企
业资源规划(ERP)的企业信息系统(EIS)提供的信息来处理进来的呼叫或 消息，所述技术包括生成与呼叫方或发送方相关的适当的上下文，识别适 当的用户或接收方以处理该进来的呼叫或消息，以及提供建议或预测特定的 可以执行的进一步动作。
面向发送方和面向用户的动作生成
接下来，在呼叫参与者(例如消息的发送方和接收方，或者电话呼叫的 呼叫方和接收方)之上建立业务上下文。因此，对于在诸如电话呼叫的通信 中所涉及双方，存在面向发送方(例如呼叫方)和/或面向用户(例如接收方)。 在一个实施例中，基于两个中心收集业务上下文， 一个基于发送方，另一个 基于接收方或潜在接收方。贯穿本申请，将电话呼叫用作在发送方(即呼叫 方)和接收方(这里也称为用户)之间的通信的例子。然而，本发明不限于 此。也可以应用其它类型的通信(例如电子邮件或即时消息等)。
在一个实施例中，使用面向用户的搜索引擎和面向呼叫方的搜索引擎构 建交互历史(例如来自之前事务(transaction)的业务上下文的相关链接)生 成器。面向用户的搜索引擎被配置成从用户工作中心和/或机构或企业实体的 平面图(floor plan)搜索用户相关的链接。可以基于一个或多个规则(例如 最频繁使用的链接)提取业务对象(BO)相关链接。在一个实施例中，面向呼叫方的搜索引擎被配置成从由呼叫方事务数据库或由基于之前事务的自学 习引擎记录的呼叫方交互历史^t索用户/呼叫方相关链接。还可以基于一个或 多个规则(例如以前呼叫方与各个用户交互的最频繁的相关链接)提取用户 相关链接。在另一个实施例中，在该系统中可以实现附加的功能性，包括选 择机制，允许用户选择面向用户或面向呼叫方的相关链接，以及配置单元(例 如业务配置)，用于配置面向用户或面向呼叫方的业务上下文。
图1是示出根据本发明实施例的用于处理通信消息的系统配置的框图。 在一个实施例中，系统100包括但不限于处理逻辑，其响应于将由接收方通 过网络从发送方接收的消息，确定与该发送方和接收方相关联的一个或多个 之前的事务，所述一个或多个之前的事务是在在与该接收方相关联的实体中
所执行的操作过程期间记录的。系统100还包括动作生成器，其链接到处理
逻辑，用以基于所确定的一个或多个之前的事务，生成一个或多个动作候选 的列表，以使得接收方能够选择将要执行的一个或多个动作候选，以响应发 送方的消息。
参照图1，系统100包括一个或多个客户端101 - 102，其通过网络104 可通信地连接到服务器103。出于示例的目的，客户端101 - 102是可通信地 连接到通信中心103的呼叫方，所述通信中心103可以是与机构或企业实体 相关联的呼叫中心。例如，呼叫方101-102可以是拥有和/或运4亍通信中心 103的企业实体的客户。 一个或多个用户106可以是企业实体的雇员或客户 代表。用户106可以通过网络接收来自呼叫方101 - 102的呼叫，所述网络可 以是PSTN (公共交换电话网)或数据网络(例如使用基于IP的话音传输技 术，或VOIP技术的因特网)。
在一个实施例中，通信中心103可以可通信地连接到与企业实体相关联 的企业信息系统(EIS) 105。再次参照图1，在一个实施例中，服务器103 可以包括连接到面向呼叫方的搜索引擎107和面向用户的搜索引擎108的动 作生成器111,其响应于通过网络从呼叫方(例如呼叫方101-102)接收的 进来的呼叫，生成与呼叫方和/或处理该进来的呼叫的潜在用户106(例如接 收方)相关的通信上下文112。
在一个实施例中，响应于进来的呼叫，面向呼叫方的搜索引擎107和/ 或面向用户的搜索引擎108执行在一个或多个数据库(例如数据库109-110) 中的搜索，所述数据库用于存储关于与该呼叫方和/或潜在用户相关联的业务事务的信息。例如，搜索引擎可以基于与呼叫方和/或用户相关联的特定因素， 搜索和识别一个或多个可能适合处理特定呼叫方的进来的呼叫的用户。
在一个实施例中，面向呼叫方的^l叟索引擎107可以访问各个面向呼叫方
的数据库109，并且面向用户的搜索引擎108可以访问各个面向用户的数据 库110。数据库109-110可以由企业信息系统(EIS)维护，所述企业信息系 统可以是ERP系统。注意，数据库109和110仅仅是出于示例的目的被示出 的，它们也可以是单个数据库或多个数据库。此外，取决于具体的实现方式， 搜索引擎107- 108可以是EIS 105的一部分。再有，服务器103和EIS 105 可以被实现为相同的服务器或服务器群。类似地，搜索引擎111 _ 112可以是 在同一数据库或不同的数据库中搜索的相同的搜索引擎。其它配置也可能存 -在。面向用户的数据库可以转变成面向呼叫方的数据库，其中在进来的呼叫 中用户处于呼叫方位置，这与面向呼叫方的凝:据库类似。面向用户/呼叫方的 数据库的核心属性是它是这样的数据库，能够存储通信期间的所有业务事 务，并且能够满足对于相关功能的面向人的搜索。再有，基于在面向用户或 呼叫方的业务事务的第一次搜索，搜索通常可以采取另一个步骤，以进一步 过滤与该用户或呼叫方的对方相关的业务事务。
在一个实施例中，响应于进来的呼叫，面向呼叫方的搜索引擎107基于 进来的呼叫，生成与该呼叫方相关联的呼叫上下文(例如业务相关上下文)， 包括例如呼叫方的姓名和电话号码以及与该呼叫方相关联的业务类型等。
此外，根据一个实施例，响应于进来的呼叫，面向呼叫方的搜索引擎107 在面向呼叫方的数据库109中搜索与在该呼叫方和与通信中心103和/或EIS 105相关联的企业实体之间的之前的事务相关联的任何信息。基于作为搜索 结果的信息，生成与在相关链接上的呼叫方的之前的事务相关联的第一业务 上下文。这是面向呼叫方的业务上下文数据库。
再有，根据另一个实施例，响应于进来的呼叫，面向用户的搜索引擎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 (业务对象)相关的"您也可以"。
在一个实施例中，面向呼叫方的搜索引擎被配置成从呼叫方事务数据库 记录的呼叫方交互历史中搜索呼叫方和用户相关链接。可以基于一个或多个 规则(例如，呼叫方与用户交互的最频繁的相关链接)来提取相关链接。其
它的功能性也可以添加到所述系统，包括i)来自可以生成可能的动作iy妻
的语音交互应用的关键词捕捉器(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可以是EIS 605的一部分。再有，服务器603和EIS 605 可以被实现为相同的服务器或服务器群。类似地，搜索引擎611-612可以是 在同 一数据库或不同的数据库中搜索的相同的搜索引擎。其它配置也可能存 在。
在一个实施例中，响应于进来的呼叫，面向呼叫方的搜索引擎607基于 进来的呼叫，生成与该呼叫方相关联的呼叫上下文(例如业务相关上下文)， 包括例如呼叫方的姓名和电话号码以及与该呼叫方相关联的业务类型等。
此外，根据一个实施例，响应于进来的呼叫，面向呼叫方的搜索引擎607 在面向呼叫方的数据库609中搜索与在该呼叫方和与通信中心603和/或EIS 605相关联的企业之间的之前的事务相关联的任何信息。基于作为搜索结果 的信息，生成与有关相关链接的呼叫方的之前的事务相关联的第一业务上下 文。这是面向呼叫方的业务上下文数据库。
再有，根据另一个实施例，响应于进来的呼叫，面向用户的搜索引擎608 在面向用户的数据库610中搜索与所述企业实体中的用户所执行的之前的活 动相关的任何信息。所述活动可以与在企业实体中的操作过程中用户的特定 角色相关。基于作为搜索结果的信息，生成与在相关链接上的用户之前的活 动相关联的第二业务上下文。
基于该第一和第二业务上下文，除了与该呼叫方相关联的一般上下文之 外，处理进来的呼叫的用户还可以利用相关链接上下文(例如图IO的相关链 接上下文1001 )之一或两者来处理进来的呼叫。在另一个实施例中，可以通 过自学习引擎，基于业务第一和第二业务上下文生成相关链接上下文。所述 自学习引擎可以基于一个和多个规则来执行这样的确定。
此外，才艮据一个实施例，系统600还包括动作预测器614，其可以实现 为动作生成器611的一部分，或者可以实现为可通信地连接到动作生成器611 的分离的功能单元。在处理进来的呼叫中，动作预测器614可以-陂配置成生 成除了要求的那些操作之外的被推荐给用户的(例如可选的)附加动作项目。动作预测器614可以依靠从进来的呼叫中提取的特定信息、搜索引擎607和/ 或608的结果、以及自学习引擎613的结果。结果，用户能够执行特定的要 求的动作，以及如图10的动作1002示出的特定动作"您还可以"执行。注 意，与服务器603和605相关联的一些或全部功能单元可以以软件、硬件或 两者的组合来实现。其它的配置也可以存在。
图7是示出根据本发明的一个实施例的用于处理进来的消息或呼叫的处 理的流程图。注意，处理700可以通过处理逻辑来t丸行，该处理逻辑可以包 括软件、硬件或两者的组合。例如，处理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，在进来的呼叫处于迷路(inlost) 状态的情况下，面向用户的搜索引擎804可以基于呼叫方ID,匹配具有与该 呼叫方相关联的相似角色的任何用户。在一个实施例中，面向用户的搜索引 擎804可以访问面向用户的数据库以进行这样的操作。例如，面向用户的搜 索引擎804可以基于与呼叫方和/或呼叫方的位置(例如区域或国家)等相关 联的业务类型匹配用户。匹配的或识别出的用户可以具有与呼叫方特性匹配 的特定职责。结果，可以生成考虑到呼叫方而与用户相关联的相关链接。
根据特定实施例，可以从工作中心809和/或工作中心809的平面图收集 或积累与用户相关联的相关链接。从所积累的用户的相关链接中，提取被各
个用户触发过的所有相关链接。在一个实施例中，在方框833，可以从用户
提取的相关链接的业务上下文。在一个实施例中，仅仅被用户触发最频繁的 特定相关链接可以被用来生成业务上下文(例如面向用户的业务上下文)。在 一个实施例中，当作为上下文830的部分832的呼叫方未知时(例如未知的 呼叫方ID或呼叫方没与该企业实体进行过任何业务)，这样的上下文可以在 "您也可以，，上下文830中使用。
此外，在方框814，用户可以使用或选择上下文813和上下文807以生 成"您也可以，，链接的业务上下文816，所述"您也可以"链接是例如由呼 叫方触发的、并且由用户相关链接818提取的最频繁的相关链接，或者由用 户触发的、并且由呼叫方相关链接819提取的最频繁的相关链接。当呼叫方 已知时，可以使用上下文816来提供与"您也可以，，链接830的部分831相关的信息。此外，可以使用自学习引擎815来基于相关链接807和813生成 上下文816。
此外，根据另一个实施例，系统840还包括连接到面向呼叫方的搜索引 擎803的语音处理单元840，以进一步处理语音相关信息。语音处理单元840 可以以软件、硬件或两者的组合来实现。在一个实施例中，语音处理单元840 包括-f旦不限于语音应用(例如语音识别应用)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。 一部分内容与一个或多个工作中心中的公共任务一致(inline),或者与 一个或多个业务对象平面图中的"您也可以"动作一致，另一些内容则基于 与可能的通信场景相关的特定业务对象(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是示出根据一个实施例的提供用于处理进来的呼叫或消息的信息 的用户接口的示图。例如，GUI 1100可以与如上所述的系统，诸如例如图1 的系统100和/或图6的系统600， 一起使用。如图11的GUI 1100所示，相 关链接信息1101和"您还可以"信息1102可以被生成和提供。注意，GUI 1100 仅仅是出于示例的目的被示出；也可以实现GUI的其它格式或布局。
数据处理系统的例子
图12是数字处理系统的框图，该数字处理系统可以与本发明的 一个实施 例一起使用。例如，系统1200可以用作以上参照图1和6描述的客户端和/ 或服务器。注意，尽管图12示出了计算机系统的不同组件，但是其并不是想 要代表互连所述组件的任何具体体系结构或方式；因为这些细节与本发明并 非密切相关。应当会理解到，网络计算机、手持计算机、蜂窝电话和其它具 有较少或可能更多组件的数据处理系统都可以与本发明一起使用。
如图12所示，作为数据处理系统的一种形式的系统1200包括总线或互 连线1202,其连"^到一个或多个樣i处理器1203和ROM 1207、易失性RAM 1205和非易失性存储器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典型地为磁性硬盘驱 动器，磁光驱动器、光驱动器或DVDRAM或即使在从系统去除电源之后仍 能维持数据的其它类型的存储器系统。典型地，非易失性存储器也将是随机 存取存储器，尽管并不要求如此。
尽管图12示出了非易失性存储器为直接连接到数据处理系统中的其它 组件的本地设备，但是，本发明也可以利用远离系统的非易失性存储器。例 如，通过诸如调制解调器或以太网口的网络接口连接到数据处理系统的网络 存储设备。总线1202可以包括通过各种桥、控制器和/或适配器彼此连接的 一个或多个总线，如本领域中公知的那样。在一个实施例中，1/0控制器1209 包括用于控制USB (通用串行总线)外围设备的USB适配器。或者，1/0控 制器1209可以包括用于控制Fire Wire设备的正EE-1394适配器，其也称为 FireWire适配器。
EIS和ERP系统概述
可以用于上文描述的本发明的实施例的EIS —般指任何类型的"企业级" 的计算系统。这意味着典型地提供高质量的服务，处理大量数据(例如，能 够支持一些相对大型的机构，也称为"企业")。
EIS系统提供技术平台，使得机构能够整合和协调其业务处理。它们在 逻辑上提供对机构来说是中枢的单个系统，并且确保信息能够在所有功能级 和管理层次之间共享。通过创建标准的数据结构，企业系统在消除由机构中 多个信息系统引起的信息碎片化问题方面的价值无法估量。
典型地，EIS会由专业的系统管理员操作，并且部署在专用的服务器上。 它典型地提供网络连接，并提供服务，以支持企业所执行的操作。例如，EIS 可以包括企业资源规划(ERP)系统。ERP系统将机构的大多数或所有数据 和处理整合(或试图整合)成逻辑上统一的系统。典型的ERP系统使用计算 机软件和/或硬件的多个组件来实现整合。大多数ERP系统的关键要素是使用 逻辑上单一的、统一的数据库来保存各种系统模块的数据，尽管该数据库或数据可以本地管理或通过网络远程管理。
术语ERP最初是指被设计成规划企业范围的资源利用的系统。尽管首字
母缩写词ERP起源于制造界，但今天术语ERP系统具有宽得多的使用范围。 ERP系统典型地试图覆盖机构的所有基本功能，而不管机构的业务或规章如 何。商业、非营利机构、非政府机构、政府和其它大型实体都使用ERP系统。 另外，可能会注意到，在被视为ERP系统时，包(package)(可以包括 软件、硬件或两者的组合) 一般只需要提供单个包中的功能性，而这通常由 两个或更多系统覆盖。技术上，认为提供工资单和帐目管理这两项功能的包 是ERP包。
然而，该术语一般被保留给更大、基础更广的应用。引入ERP系统以取 代两个或更多个独立应用消除或减少了对于以前系统之间要求的外部4妄口的 需要，并且提供了额外的好处，其范围从标准化和低成本维护(一个系统而 非两个或更多)到更容易和/或更强大的报告能力(因为所有数据典型地逻辑 上保存在一个数据库中)。
ERP中的以前曾经是孤立应用的模块的示例包括但不局限于制造、供应 链、财务、CRM (客户关系管理)、人力资源和仓库管理等。ERP是交叉功 能和企业范围的。操作或生产中涉及的所有功能部门整合在一个系统中(逻 辑上)。除了制造、仓储、后勤和信息技术(IT)以外，它还包括财会、人力 资源、营销和战略管理。
最佳方法(best practice)也是实现ERP系统的好处。当实现ERP系统 时，机构本质上要进行选择，即，定制软件，或者将其业务处理修改成软件 普通版中提供的"最佳方法"功能。 一些人将最佳方法当作商业时髦用语， 用来描述开发和遵循做事情的标准方式的处理，所述标准方式多个机构都可 以使用以用于管理、策略、特别是软件管理。
考虑最佳方法在今天的计算机系统，特别是MOM (营销操作管理)系 统中的应用。选择最佳方法(它是否真的是最佳)，并将其实现到计算机系统 中。这允许执行类似任务的多个机构能够将相同的软件用于它们的任务。
MOM是从规划和预算、到营销内容管理、到全球营销执行和分析的端 到端的营销优化方案。其特征在于，尝试实现对营销投资(ROMI)的可测量 和可跟踪的反馈(return),并且，作为实现这种反馈的方法，创建营销4义表 板(dashboard)。营销仪表板的概念是，营销管理人员、或者甚至是机构中的任何雇员都能够登录到系统中，所述系统显示所有正在进行的营销活动的状
态一在汽车模拟(automotive analogy)中显示"油耗"(花费)、"速度"(销 售)以及各种其它度量。营销资源管理(MRM)业，包括软件厂家，才是供软 件基础结构，以便为机构提供营销操作管理方面的帮助。这形成了对于有效 的营销操作管理策略来说非常关键的对人员、处理和技术的基本调整的技术 支柱。
人力资源是最佳方法的一个好示例，如在大多数MOM系统中所证明的 那样。在管理机构的雇员、志愿者和合同工中涉及无数的方式和大量的处理。 通过选择组织和执行处理的"最佳方法"或标准方式，MOM系统或HRMS (人力资源管理系统)软件的制作者能够创造可以由多个机构使用的系统。
在本上下文中，最佳方法实现方式的好处往往在于，为流程设计(或者 更恰当的说是演进)欠佳的机构提供以下选择对其系统进行(一般来说) 昂贵的修改，或者选择遵循最佳方法。最佳方法随时间的变化是ERP系统生 命周期的主要动力。许多主要软件的发布都是在业内最佳方法的变化或引入 下推进的。上世纪巨大的技术变化速度推动了快速适应和多样的最佳方法。
上文所描述的 一部分可以通过诸如专用逻辑电路的逻辑电路，或通过农乏 控制器或执行程序代码指令的其它形式的处理核来实现。因而，上述讨论所 教导的处理可以通过程序代码来执行，所述程序代码例如机器可执行指令， 其导致执行这些指令的机器来执行特定的功能。在本上下文中，"机器"可以 是把中间形式(或"抽象")指令转换成处理器特定指令(例如，诸如"虚拟 机"(例如，Java虛拟机)的抽象执行环Jt竟、翻i奪器、Common Language Runtime、高级语言虛拟机等)的机器，和/或布置在半导体芯片(例如，用 晶体管实现的"逻辑电路")上用于执行指令的电子电路，例如通用处理器和 /或专用处理器。上述讨论教导的处理也可以由设计成执行处理(或其一部分) 而不执行程序代码的电子电路(替代机器或与机器结合)来执行。
相信，上文的讨论教导的处理也可以用由各种软件开发框架(例如，微 软公司的.NET、 Mono、 Java、甲骨文公司的Fusion等)支持的各种面向对象 或非面向对象的计算机编程语言(例如，Java、 C#、 VB、 Python、 C、 C++、 J#、 APL、 Cobol、 ABAP、 Fortran、 Pascal、 Perl等)的源程序代码来描述。 源程序代码可以转换成抽象执行环境(例如，Java虚拟机、Common Language Runtime、高级语言虚拟机、翻i奪器等)可以理解的中间形式程序代码(例如Java字节代码、微软中间语言等)，或者针对特定处理器的更特定形式的程序 代码。
前面详细描述中的一些部分以对计算机存储器内数据比特操作的算法和 符号表现形式呈现。这些算法的描述和表现形式是数据处理领域的技术人员 所使用的、以便最有效地把他们工作的实质传达给本领域其他技术人员的方 式。在这里， 一般来讲，算法被认为是带来期望结果的前后一致的操作序列。 操作是指那些要求对物理量的物理处理的操作。通常，尽管不是必须的，这 些量采用能够被保存、传输、组合、比较以及以其它方式处理的电或磁信号 的形式。已经证明，有时称这些信号为比特、值、元素、符号、字符、术语、 数字等很方便，主要是由于通用的原因。
然而，应该记住，所有这些和类似术语都与适当的物理量相关联，并且 只是适用于这些量的方便标志。除非特别说明，否则如根据上文的讨论显而 易见地，应当理解，贯穿说明书，使用诸如"处理"或"计算"或"确定" 或"显示"等术语的讨论，是指计算机系统和类似的电子计算设备的动作和 处理，所述计算机系统或类似的电子设备将计算机系统的寄存器和存储器内 表示为物理(电子)量的数据处理和转换成计算机系统存储器或寄存器或其 它这样的信息存储、传输或显示设备内类似地表示为物理量的其它数据。
这里，本发明的实施方式还涉及一种用于执行操作的装置。该装置可以 为要求的目的特殊构造，或者它可以包括由保存在计算机中的计算机程序选 择性激活或重配置的通用计算机。这样的计算机程序可以保存在计算机可读 存储介质中，例如但不局限于任何类型的盘，包括软盘、光盘、CD-ROM、 磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、可擦除可编程ROM (EPROM)、电可擦除可编程ROM (EEPROM)、磁或光卡或适于保存电子 指令并且分别连接到计算机系统总线的任何类型的介质。
这里提供的算法和显示并非固有地与任何特定计算机或其它装置相关。 根据这里的教导，各种通用系统都可以与程序一起使用，或者可以证明构建 更专门的设备来执行要求的方法操作很便利。从以下的描述中将出现这些各 种系统所要求的结构。另外，本发明的实施方式并非参考任何特定的编程语 言来描述的。可以理解，各种编程语言都可以用来实现这里描述的本发明实 施方式的教导。
机器可读介质可以包括用于以机器(例如计算机)可读的形式保存或传输信息的任何介质。例如，机器可读介质包括只读存储器("ROM");随机 存取存储器("RAM");磁盘存储介质；光存储介质；闪存设备；电、光、 声或其它形式的传播信号(例如，载波、红外信号、数字信号等)等。
在以上的说明书中，已经参照本发明的特定示例实施例对本发明的实施 例进行了描述。很显然，可以对本发明实施例进行各种修改，而不会脱离所 附权利要求书中阐述的本发明的更宽的精神和范围。因此，说明书和附图仅 仅被认为是示例性的，而不是限制性的。
权利要求
1、一种机器实现的方法，包括响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方相关联的实体中执行的操作的过程期间被记录的；以及基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表，其中，所述一个或多个动作候选是除了响应于所述消息要求所采取的一个或多个动作之外的、推荐给接收方的可选动作。
2、 如权利要求1所述的方法，还包括基于与所述发送方和接收方相关联 的一个和多个之前的事务，生成所述一个或多个要求的动作。
3、 如权利要求l所述的方法，其中，确定一个或多个之前的事务包括 访问第一数据库，以搜索与相对于所述实体的发送方相关联的第一之前事务；以及基本上并行地访问第二数据库，以搜索与相对于所述发送方的所述接收 方相关联的第二之前事务，其中，所述动作候选的列表是基于所述第一和第 二之前事务中的至少一个生成的。
4、 如权利要求3所述的方法，还包括 从所述消息提取一个或多个关键词；基于所述第一之前事务，识别与所提取的一个或多个关4建词相关的一个 或多个事务对象；以及基于所识别的一个或多个事务对象，生成一个或多个指导动作，其中， 所述一个或多个动作候选是基于所述一个或多个指导动作生成的。
5、 如权利要求4所述的方法，还包括基于从所述第一之前事务得到的 发送方的一个或多个行为，调整所述指导动作，以形成所述推荐的动作。
6、 如权利要求4所述的方法，还包括基于所述第一之前事务和所述一个或多个指导动作，生成表示由所述发 送方执行的一个或多个公共任务的第一事务上下文；以及基于所述第二之前事务，生成表示由所述接收方执行的一个或多个公共 任务的第二事务上下文，其中，所述一个或多个动作候选是基于所述第一和 第二事务上下文中的至少一个生成的。
7、 如权利要求6所述的方法，还包括考虑到所述第一和第二事务上下文 记录所述接收方的一个或多个行为，其中，所记录的行为被用于生成针对发 送方和/或接收方的进一 步推荐的动作。
8、 如权利要求l所述的方法，其中，所述实体使企业实体，并且其中， 所述之前事务的信息是从与该企业实体相关联的企业信息系统(EIS)提供的， 该EIS系统包括至少企业资源规划(ERP)系统。
9、 一种具有存储在其中的指令的机器可读介质，当所述指令被机器执行 时，导致该机器执行一种方法，所述方法包括响应于由接收方通过网络从发送方接收的消息，确定与发送方和接收方 相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方 相关联的实体中执行的操作的过程期间被记录的；以及基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表， 其中，所述一个或多个动作候选是除了响应于所述消息要求所采取的一个或 多个动作之外的、推荐给接收方的可选动作。
10、 如权利要求9所述的机器可读介质，其中所述方法还包括基于与所 述发送方和接收方相关联的一个和多个之前的事务，生成所述一个或多个要 求的动作。
11、 如权利要求9所述的机器可读介质，其中，确定一个或多个之前的 事务包括访问第一数据库，以搜索与相对于所述实体的发送方相关联的第一之前 事务；以及基本上并行地访问第二数据库，以搜索与相对于所述发送方的所述接收 方相关联的第二之前事务，其中，所述动作候选的列表是基于所述第一和第 二之前事务中的至少一个生成的。
12、 如权利要求11所述的机器可读介质，其中所述方法还包括 从所述消息提取一个或多个关键词；基于所述第一之前事务，识别与所提取的一个或多个关键词相关的一个 或多个事务对象；以及基于所识别的一个或多个事务对象，生成一个或多个指导动作，其中， 所述一个或多个动作候选是基于所述一个或多个指导动作生成的。
13、 如权利要求12所述的机器可读介质，其中所述方法还包括基于从所述第一之前事务得到的发送方的一个或多个行为，调整所述指导动作，以 形成所述推荐的动作。
14、 如权利要求12所述的机器可读介质，其中所述方法还包括 基于所述第一之前事务和所述一个或多个指导动作，生成表示由所述发送方执行的一个或多个公共任务的第一事务上下文；以及基于所述第二之前事务，生成表示由所述接收方执行的一个或多个公共 任务的第二事务上下文，其中，所述一个或多个动作候选是基于所述第一和 第二事务上下文中的至少一个生成的。
15、 如权利要求14所述的机器可读介质，其中所述方法还包括考虑到 所述第一和第二事务上下文记录所述接收方的一个或多个行为，其中，所记 录的行为被用于生成针对发送方和/或接收方的进一步推荐的动作。
16、 如权利要求9所述的机器可读介质，其中，所述实体使企业实体， 并且其中，所述之前事务的信息是从与该企业实体相关联的企业信息系统(EIS)提供的，该EIS系统包括至少企业资源规划(ERP)系统。
17、 一种数据处理系统，包括处理逻辑，其响应于由接收方通过网络从发送方接收的消息，确定与发 送方和接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务 是在与接收方相关联的实体中执行的操作的过程期间被记录的；以及所连接的动作生成器，其基于所确定的一个或多个之前的事务，生成要 求采取的一个或多个动作；以及所连接的动作预测器，其基于所确定的一个或多个之前的事务，生成一 个或多个动作候选的列表，其中，所述一个或多个动作候选是除了响应于所 述消息的一个或多个要求的动作之外的、推荐给接收方的可选动作。
18、 如权利要求17所述的系统，还包括第一搜索引擎，其在第一数据库中搜索与相对于所述实体的发送方相关 联的第一之前事务；以及第二搜索引擎，基本上并行地在第二数据库中搜索与相对于所述发送方 的所述接收方相关联的第二之前事务，其中，所述动作候选的列表是基于所 述第一和第二之前事务中的至少一个生成的。
19、 如权利要求18所述的系统，还包括连接到所述第一搜索引擎的消 息分析器，其分析所述消息，其中，所述消息分析器包括关键词识别器，其从该消息中提取一个或多个关键词；事务识别器，其基于所述第一之前事务，识别与所提取的一个或多个关键词相关的一个或多个事务对象；以及动作指导单元，其基于所识别的一个或多个事务对象，生成一个或多个指导动作，其中，所述一个或多个动作候选是基于所述一个或多个指导动作生成的。
20、 如权利要求19所述的系统，其中，所述关键词识别器识别语音应用 中的一个或多个关^t词，然后基于识别出的关^t词搜索一个或多个事务对象， 其中，所述动作指导单元基于所述一个或多个事务对象生成一个或多个指导 动作，并且其中， 一个或多个动作候选是基于所述一个或多个指导动作生成 的。
21、 如权利要求19所述的系统，还包括第一上下文生成器，基于所述第一之前事务和所述一个或多个指导动作， 生成表示由发送方执行的一个或多个公共任务的第一事务上下文；以及第二上下文生成器，其基于所述第二之前事务，生成表示由所述接收方 执行的一个或多个公共任务的第二事务上下文，其中，所述一个或多个动作 候选是基于所述第一和第二事务上下文中的至少一个生成的。
全文摘要
这里描述了基于发送方和接收方之间的交互历史和上下文的动作预测的技术。在一种实现方式中，处理包括但不限于响应于由接收方通过网络从发送方接收的消息，确定与发送方或接收方相关联的一个或多个之前的事务，所述一个或多个之前的事务是在与接收方相关联的实体中执行的操作的过程期间被记录的；以及基于所确定的一个或多个之前的事务，生成一个或多个动作候选的列表，其中，所述一个或多个动作候选是除了响应于所述消息要求采取的一个或多个动作之外的、推荐给接收方的可选动作。还应用语音应用中的关键词识别和指导动作来生成动作预测候选交互历史链接。还描述了其它方法和装置。
文档编号H04Q3/00GK101287040SQ20071019666
公开日2008年10月15日 申请日期2007年11月29日 优先权日2006年11月29日
发明者埃克哈德·法伦科普夫, 安德烈·艾科霍斯特, 天 徐, 德克·萨格尔 申请人:Sap股份公司