语义CRM移动通信会话

背景技术

客户关系管理(“CRM”)是一种管理公司与当前客户和潜在客户的交互的方法。CRM实现对客户与公司的历史的数据分析，以改进与客户的业务关系，具体集中于客户保持和销售增长。CRM系统编译来自包括电话、电子邮件、在线聊天、文本消息传递、营销材料、网站和社交媒体的一系列通信渠道的数据。通过CRM方法和用于促进CRM方法的系统，企业了解更多关于他们的目标受众以及如何最好地解决他们的需要。

企业CRM系统可能是巨大的。这样的系统可以包括数据仓库技术，用于聚集交易信息，将该信息与关于CRM产品和服务的信息合并，以及提供关键性能指标。CRM系统帮助管理不稳定的生长和需求，并实现将销售历史与销售预测集成的预测模型。CRM系统跟踪并测量多个网络上的营销活动，通过客户点击和销售跟踪客户分析。一些CRM软件可通过云系统、软件即服务(SaaS)供使用，经由网络被递送并且经由浏览器被访问，而不是安装在本地计算机上。使用基于云的CRM SaaS的企业通常订阅这种CRM系统，支付定期订阅费，而不是完全购买该系统。

尽管CRM系统规模庞大，但是当今的许多CRM系统缺乏充分利用它们可以访问的信息的基础结构。例如，仅客户联系就可能难以跟踪。当今的远程代理不将客户联系仅仅限制为来自呼叫中心中的办公桌的电话呼叫。通常通过联系中心来管理这样的联系，该联系中心可以管理跨越多个位置的多个代理之间的多种模式的联系、电话、文本、电子邮件等。当表示代表营销客户的联系中心的特定远程代理接受来自客户代表的电话呼叫时，完全可能与该客户代表的多个介入联系，多个介入联系包括文本消息和电子邮件或者甚至包括来自人工智能代理的自动消息，这对于当前的远程代理来说是很难知道或分类的。

附图说明

图1阐明了示出用于根据本发明的实施例的客户关系管理(“CRM”)的示例系统的网络图。

图2阐明了用于根据本发明的实施例的CRM中的语义三元组的示例图谱的线条图。

图3阐明了实现根据本发明的实施例的CRM的示例计算机系统的功能框图。

图4阐明了实现根据本发明的实施例的CRM的示例控制面板的线条图。

图5阐明了根据本发明的实施例的瘦客户端架构中的CRM的示例设备的功能框图。

图6阐明了用作根据本发明的实施例的CRM的声音服务器的示例计算机的框图。

图7阐明了用作根据本发明的实施例的CRM的三元组服务器的示例计算机的框图。

图8阐明了用作根据本发明的实施例的CRM的示例计算机存储器系统的框图。

图9阐明了根据本发明的实施例的胖客户端架构中的CRM的示例装置的功能框图。

图10阐明了示出根据本发明的实施例的CRM的示例方法的流程图。

图11阐明了关于客户、客户代表和通信会话的三元组被实现为子图谱的示例企业知识图。

图12阐明了关于客户、客户代表和通信会话的三元组被实现为单独的图谱的示例图谱集。

图13和图14阐明了示出根据本发明实施例的CRM的另一示例方法的流程图。

具体实施方式

从图1开始，参考附图描述了在计算机系统中实现的用于客户关系管理(“CRM”)的示例方法和设备。图1阐明了示出用于根据本发明的实施例的CRM的示例计算机系统的网络图。图1的示例中的计算机系统包括客户端计算机(152)和若干服务器(三元组服务器(157)、语音服务器(151))、线索(1ead)引擎(134)和脚本引擎(132)。客户端计算机和服务器(包括线索引擎和脚本引擎)一起构成实现根据本发明的实施例CRM的整个计算机系统。客户端计算机是是被配置用于通过显示器、图形用户界面或语音使能接口具有CRM相关的I/O的CRM的自动计算机器，语音使能接口接受并识别来自用户的语音并向用户表达语音提示和语音响应。这样的装置被称为客户端装置，因为它们实现了执行根据实施例的CRM的计算机架构的客户端侧。图1的示例中的客户端计算机包括台式计算机(107)、移动电话(110)和膝上型计算机(126)，其中任何一个或全部可以作为用于在例如联系中心(305)中执行CRM的远程代理的工作站。客户端计算机由通过网络(100)的无线连接(116、118、120)耦接到三元组服务器(157)、声音服务器(151)、线索引擎(134)和脚本引擎(132)以进行数据通信。

线索引擎(134)是从各种资源收集线索并通过GUI将线索提供给远程代理以便与客户和预期客户使用的自动计算机器。线索是表示客户或潜在客户的结构化数据，通常包括线索ID、线索名称、公司、线索角色、线索或公司的地址、线索的电话号码以及本领域技术人员所能想到的其他相关信息。这种线索可实现为对自动计算机器进行自动线索生成和通过GUI呈现给远程代理有用的记录、消息、对象或其他数据结构。

脚本引擎(206)是实时创建动态脚本以供远程代理在与客户通信时使用的自动计算机器。动态脚本是根据各种因素(诸如，当前的行业趋势数据，并且往往是远程代理支持的特定产品和客户拥有或不拥有的产品)实时改变的脚本。也就是说，动态脚本在其基于行业趋势而实时改变的意义上是动态的。为了客户的利益，脚本中的语句被实时地动态重新排序、添加或删除。通过被动态地重新排序或被实时创建、从相关行业和软件描述的知识库中被检索、被其他远程代理提供、或以本领域技术人员将想到的其他方式，这样的语句可以在脚本中动态地更改。

如在本说明书中使用的短语，自动计算机器表示本地的或远程的代码或其他自动计算逻辑的模块、片段、部分，硬件，软件，固件等，以及上述任何项的组合。自动计算机器通常被实现为可执行指令、物理单元或用于实现指定逻辑功能的其他计算逻辑。

远程代理(128)是负责销售或支持商业产品和服务的人，是联系中心的代理。客户代表(129)是表示作为联系中心的商品或服务的当前购买者或潜在购买者的客户、公司或其他企业的人。

CRM联系中心(305)是提供根据本发明的实施例的CRM的人员和计算机资源的组织。在图1的示例中，虚线表示联系中心(305)的范围。该范围是逻辑的而不是物理的。构成联系中心的所有资源和人员可以具有相同的物理位置，或者联系中心可以被高度虚拟化并且例如远程代理、客户端装置和服务器具有分开的物理位置。一些或所有的远程代理可以在为代理提供办公桌、工作站、电话等的呼叫中心一起办公。所有或一些远程代理可以在家办公或移动办公。脚本引擎和线索引擎可以位于与容纳三元组服务器和声音服务器的数据中心分开的数据中心中等。

语义图谱数据库(152)是使用用于语义查询的以节点、边和属性表示数据和存储数据的图谱结构的数据库。这个数据库系统的关键概念是与数据存储中的数据项直接相关的图谱(或边或关系)。这些关系允许存储中的数据直接链接在一起，并且在许多情况下以一个操作被检索。这种图谱数据库与传统的关系数据库形成对比，在传统的关系数据库中，数据之间的链接仅是间接的元数据，并且使用连接来查询对存储内的数据的搜索以收集相关数据。通过设计，图谱数据库在数据之间形成明确的关系，并且允许简单且快速地检索在关系系统中难以建模的复杂分层结构。

图谱数据库的底层存储机制可以变化。一些图谱数据库依赖于关系引擎并将图谱数据存储在表中。其他图谱数据库使用键值存储或面向文档的数据库进行存储，使该图谱数据库固有地成为NoSQL结构。

从图谱数据库检索数据通常需要SQL以外的查询语言，SQL是为关系数据库设计的，并且不能很好地处理对图谱的遍历。存在许多系统，最经常与一个产品紧密相关联，并且存在一些多供应商查询语言，如Gremlin、SPARQL和Cypher。除了具有查询语言接口之外，一些图谱数据库通过应用编程接口(API)被访问。

图谱数据库基于图谱理论，并且采用节点、边和属性。节点表示诸如人、企业、帐户或任何其他要跟踪的项的实体。它们大致等同于关系数据库中的记录、关系或行，或者文档数据库中的文档。边(也称为图谱或关系)是将节点连接到其他节点的线，它们表示节点之间的关系。当检查节点、属性和边的连接和互连时，出现有意义的模式。边是图谱数据库中的关键概念，表示不在其他系统中直接实现的抽象概念。属性是与节点相关的密切关系信息。例如，如果N3是节点之一，则它可与诸如网络服务支持、云计算、或以字母N开头的词的属性相关，这取决于N3的哪些方面与给定数据库有密切关系。

图1的图谱数据库是语义图谱数据库，并且在其中存储的是企业知识图谱(154)。图1的示例企业知识图谱可以例如根据资源描述框架(“RDF”)来实现。在这样的实施方式中，企业知识图谱具有由资源标识符表示的每个数据项。这样的资源标识符可以包括统一资源标识符(‘URI’)、国际化资源标识符(‘IRI’)、统一资源定位符(‘URL’)、文字资源标识符、非文字资源标识符或任何其他资源标识符。RDF使数据项之间的资源标识符关系成为RDF的整个数据模型的中心属性。诸如URI的资源标识符是以数据创建的，并使用也用资源标识符命名的关系被链接在一起。RDF数据存储中的所有标识符都以标识符命名的事实意味着包括关系、边或属性的所有数据项都是被明确定义和自定义的。

图1的企业知识图谱(154)具有数学有向图的特征，因为它由顶点(又称节点)和有向边组成。每条边连接两个顶点，具有类型，并且可以具有一个或多个属性。在该示例中，每个属性可以被实现为键-值对。表征边并将属性附加到边的能力增加了这种知识图谱的语义表达性。对图谱数据库和语义图谱数据库的描述是为了解释而不是限制。实际上，可替代实施例可包括关系数据库、非SQL数据存储、文件、文本文档、电子表格和其他可行的数据库结构。

计算机存储器(169)可以包括高速缓存、随机存取存储器(“RAM”)、磁盘存储器等大多数形式的计算机存储器。如此配置的计算机存储器通常驻留在语音使能装置上，或者如本文(169)所示，驻留在一个或多个三元组服务器(157)上。

除了诸如图像、数字文本等的其他内容之外，口述或键入的文本的词(509)通常构成会话和联系的内容(509)中的至少一些。这样的词可以是键入到文本框中的词、来自电子邮件或文本消息的词、或从对话(313)中识别(315)的数字化语音的词。识别的语音可以是整个对话，其中例如两个讲话的人在同一房间中，并且整个对话由语音使能装置上的麦克风拾取。通过仅向语音使能装置提供对话的一方，如仅通过耳机(105)上的麦克风，能够减小识别的语音的范围。通过仅提供对来自在客户端计算机上执行的VoiceXML对话的提示进行相应的语音进行识别，能够进一步减小识别的语音的范围。随着识别的语音的范围减小，在整个系统上，数据处理负担被降低，但是至少在一些实施例中，识别整个对话并在显示器(110)上流出对话中所有词的流仍是一种选择。

通过自然语言处理语音识别(“NLP-SR”)引擎(153)的操作，来自对话(313)的语音被识别为数字化的词，NLP-SR引擎在此被示出为设置在声音服务器(151)上，但也适于安装在语音使能客户端计算机上。除了通过声音服务器(151)的语音识别功能将词(509)数字化之外，对于另一示例，可以通过图形用户界面(110)的小部件的操作将词(509)数字化。或者，对于更进一步的示例，可以通过用户(128)将词(509)键入到图形用户界面(110)的文本输入框(366)中来对词进行数字化。

图1所示的整个示例计算机系统通常进行操作以通过在远程代理(128)和客户代表(129)之间的第一通信联系(142)时建立通信会话(140)作为计算机系统的计算机存储器(169)的结构来实现根据本发明实施例的CRM。该计算机系统通常还通过跨通信平台(101)的通信会话管理远程代理和客户代表之间的一系列通信联系来运行，该一系列通信联系包括第一联系(142)并且也包括随后的通信联系(144)。通信平台的示例包括电子邮件平台、聊天机器人、电话和文本消息传递平台。可被适配为根据实施例的CRM通信平台的文本消息传递平台的示例包括通过电话系统的SMS消息传递、在网络应用程序内内联的网络聊天、以及面向网络的消息传递应用，诸如WhatsApp、Facebook送信器、Slack、Snapchat、Cryptocat、Kik、Google环聊、Line、Meowchat、Ethan、中国的微信和QQ送信器、Viber、韩国的KakaoTalk、越南的Zalo、以及Instagram和Twitter中的直接消息传递功能。

在建立会话时，计算机系统将作为自动计算机器的面向对象的模块的会话(140)建立作为计算机系统的计算机存储器的结构，自动计算机器的结构和内容(509)也作为语义三元组(752、754)被存储在企业知识图谱(154)中。也就是说，在该示例中，会话最初至少被建立为面向对象的会话类的实例。建立这种会话包括在计算机存储器中存储主体代码、时间戳、远程代理的标识、客户代表的标识以及可选地还有关于会话的其他信息作为会话的成员数据元素。

计算机系统通过建立作为自动计算机器的面向对象的模块的每个联系来管理一系列联系，该自动计算机器构成计算机系统的计算机存储器，并且其结构和内容也作为语义三元组存储在企业知识图谱中。也就是说，在该示例中，联系最初至少被建立为面向对象的联系类的实例。管理一系列联系包括在计算机存储器中记录开始联系的时间戳、联系的持续时间、联系的会话标识符、平台类型、联系状态、联系的任何通信内容以及可选地还有关于联系的其他信息作为每个联系的成员数据元素。

跨平台管理联系包括跨相同平台或跨不同平台异步地管理联系，并且跨平台管理包括跨平台类型管理。会话中的第一联系可以通过电话进行，而随后的联系可以通过相同的电话或不同的电话进行。第一联系可以通过电子邮件进行，并且随后的联系通过电话或文本消息进行。

跨平台管理联系包括跨平台的物理位置管理联系。会话的第一联系可以通过呼叫中心中的陆线电话进行，并且随后的联系可以通过餐馆中的蜂窝电话进行。第一联系可以通过来自呼叫中心中的办公桌的电子邮件进行，并且随后的联系通过来自超市的蜂窝电话或文本消息进行。

图1的示例计算机系统包括解析引擎(380)，其将通信会话的结构和内容(509)解析为描述逻辑的解析的三元组(752)，通信会话的结构和内容(509)包括通信联系的结构和内容。图1的示例计算机系统还包括推断引擎(298)，其根据企业知识图谱的推断规则从解析的三元组(752)推断出推断的三元组(754)。图1的示例计算机系统的功能包括将解析的三元组(752)和推断的三元组(754)存储在企业知识图谱(154)中以用于根据实施例的CRM。

解析的三元组(752)是由例如主体、谓词和客体组成的语义三元组，该语义三元组是在其是由从会话或联系导出的元素组成的意义上被“解析”的，该元素包括例如识别的语音、来自GUI小部件的选择、通过GUI键入的文本等。也就是说，“解析”意味着从各种源取得会话和联系的组成元素，并将它们形成为语义三元组。解析可以包括将来自数据输入的原始文本形成为语义三元组或将由NLP-SR引擎处理的会话语音形成为词类。通过将每个部分适当地作为主体-谓词-客体放置在三元组中，可以将这样的词类形成为三元组。

根据管理知识图谱(这里是企业知识图谱(154))中的数据元素之间的关系的推断规则(376)，从解析的三元组(752)推断出推断的三元组(754)。推断是基于现有的三元组中的模式将新三元组系统地添加到图谱中的处理。通过在查询处理之前或在查询处理期间调用推断，可以实现信息集成，信息集成包括新推断的三元组。在不仅为查询而且为推断设计的引擎中，以推断规则执行的查询不仅返回断言的数据，而还返回推断的信息。读者将认识到，对“数据”或“信息”或“知识”的所有这样的引用实际上是对语义三元组的引用。

这里是推断规则的示例：

IF{＜A＞＜is a subclass of＞＜B＞}

AND{＜x＞＜is of type＞＜A＞}

THEN{＜x＞＜is of type＞＜B＞}

(如果{＜A＞是＜B＞的＜子类＞}

并且{＜x＞＜是类型＞＜A＞}

则{＜x＞＜是类型＞＜B＞})

在明语中，该规则说明如果类型A是类型B的子类，则类型A的任何东西也是类型B。我们将该规则称为“类型传播规则”，A是B的子类型，x是A，x也是B。或者在SPARQLCONSTRUCT查询中，这种类型的传播规则可以表示为：

CONSTRUCT{？R：type？B}

WHERE{？A：subClassOf？B

？R：type？A}

(结构{？R：类型？B}

其中{？A：？B的子类.

？R：类型？A})

为了进一步解释，假设这些示例三元组先前被断言：

＜Henleys＞ ＜subClassOF＞ ＜Shirts＞

＜Shirts＞ ＜subClassOF＞ ＜MensWear＞

＜Blouses＞ ＜subClassOF＞ ＜WomensWear＞

＜Oxfords＞ ＜subClassOF＞ ＜Shirts＞

＜Tshirts＞ ＜subClassOF＞ ＜Shirts＞

＜ChamoisHenley＞ ＜isOfType＞ ＜Henleys＞

＜ClassicOxford＞ ＜isOfTvpe＞ ＜Oxfords＞

＜ClassicOxford＞ ＜isOfType＞ ＜Shirts＞

＜BikerT＞ ＜isOfType＞ ＜Tshirts＞

＜BikerT＞ ＜isOfType＞ ＜MensWear＞

(＜衬衫＞＜的子类＞＜亨利汗衫＞

＜男装＞＜的子类＞＜衬衫＞

＜女装＞＜的子类＞＜女装衬衫＞

＜衬衫＞＜的子类＞＜牛津衫＞

＜衬衫＞＜的子类＞＜T恤＞

＜麂皮亨利＞＜的类型是＞＜亨利汗衫＞

＜经典牛津衫＞＜的类型是＞＜牛津衫＞

＜经典牛津衫＞＜的类型是＞＜衬衫＞

＜BikerT＞＜的类型是＞＜衬衫＞

＜Bikert＞＜的类型是＞＜男装＞)

应用类型传播规则导致以下推断：

＜ChamoisHenley＞ ＜isOfType＞ ＜Shirts＞

＜ChamoisHenley＞ ＜isOfType＞ ＜MensWear＞

＜ClassicOxford＞ ＜isOfType＞ ＜Shirts＞

＜ClassicOxford＞ ＜isOfType＞ ＜Shirts＞

＜BikerT＞ ＜isOfType＞ ＜MensWear＞

(＜麂皮亨利＞＜的类型是＞＜衬衫＞

＜麂皮亨利＞＜的类型是＞＜男装＞

＜经典牛津衫＞＜的类型是＞＜衬衫＞

＜经典牛津衫＞＜的类型是＞＜男装＞

＜BikerT＞＜的类型是＞＜衬衫＞

＜Bikert＞＜的类型是＞＜男装＞)

先前也断言了两个推断的三元组：

＜经典牛津衫＞＜的类型是＞＜衬衫＞

＜Bikert＞＜的类型是＞＜男装＞

并且，对于简单地将推断的三元组插回到断言的图谱中的推断引擎，这里是推断的三元组以粗斜体表示的新的图谱：

＜Henleys＞ ＜subClassOF＞ ＜Shirts＞

＜Shirts＞ ＜subClassOF＞ ＜MensWear＞

＜Blouses＞ ＜subClassOF＞ ＜WomensWear＞

＜Oxfords＞ ＜subClassOF＞ ＜Shirts＞

＜Tshirts＞ ＜subClassOF＞ ＜Shirts＞

＜ChamoisHenley＞ ＜isOfType＞ ＜Henleys＞

＜ChamoisHenley＞ ＜isOfType＞ ＜Shirts＞

＜ChamoisHenley＞ ＜isOfType＞ ＜MensWear＞

＜ClassicOxford＞ ＜isOfType＞ ＜Oxfords＞

＜ClassicOxford＞ ＜isOfType＞ ＜Shirts＞

＜ClassicOxford＞ ＜isOfType＞ ＜MensWear＞

＜BikerT＞ ＜isOfType＞ ＜Tshirts＞

＜BikerT＞ ＜isOfType＞ ＜MensWear＞

＜BikerT＞ ＜isOfType＞ ＜Shirts＞

＜衬衫＞＜的子类＞＜亨利汗衫＞

＜男装＞＜的子类＞＜衬衫＞

＜女装＞＜的子类＞＜女装衬衫＞

＜衬衫＞＜的子类＞＜牛津衫＞

＜衬衫＞＜的子类＞＜T恤＞

＜麂皮亨利＞＜的类型是＞＜亨利汗衫＞

＜麂皮亨利＞＜的类型是＞＜衬衫＞

＜麂皮亨利＞＜的类型是＞＜男装＞

＜经典牛津衫＞＜的类型是＞＜牛津衫＞

＜经典牛津衫＞＜的类型是＞＜衬衫＞

＜经典牛津衫＞＜的类型是＞＜男装＞

＜BikerT＞＜的类型是＞＜衬衫＞

＜Bikert＞＜的类型是＞＜男装＞

＜Bikert＞＜的类型是＞＜衬衫＞

这种推断的基本目的是创建更多连接、更完整的数据，并且其中，在数据本身中表达关于数据的一致性约束。数据本身描述了可以如何使用数据。为了使数据更完整和一致，类似于刚才描述的那些的简单推断通常比详尽的推断更有用，不是非常令人激动，而是非常有用。可以以根据实施例的推断来完成CRM数据的这种工作日一致性完成。尽管这种推断初看起来似乎没有什么意义，但是事实上，这种推断正是在大数据存储中影响一致性的那种相关性。

在本文中，“解析的三元组”是在联系发生时或在联系发生后立即从联系和会话的结构和内容或多或少实时解析的三元组。企业知识图谱中的许多三元组中的可能在某个点被解析，但是尽管如此，为了本文描述的清楚，已经在企业知识图谱中的三元组是“断言的三元组”，并且现在刚刚从会话和联系的结构和内容解析的三元组是“解析的三元组”。“推断的三元组”是当联系发生时或在联系发生之后立即从解析的三元组或多或少实时推断的三元组。企业知识图谱中的许多三元组中的可能在某一点被推断，但是，尽管如此，为了本文描述的清楚，已经在企业知识图谱中的三元组是“断言的三元组”，并且现在刚从会话或联系解析的三元组中推断的三元组是“推断的三元组”。

在这些三元组之间没有结构、功能或逻辑上的差异。断言的三元组、解析的三元组、推断的三元组都是完全相同种类的实体。这里使用的标记“断言”、“解析”和“推断”仅仅是为了便于解释，而不是为了识别种类的差异。所有这些三元组都是符合知识图谱的某种形式的定义逻辑的信息的三部分式表达，该定义逻辑通常是描述逻辑，通常是支持可决定性的逻辑。

在至少一些实施例中，企业知识图谱(154)可以包括描述整个企业、财务、商业实体和结构、雇员数据、公司数据、交易、合同、销售历史、产品描述等或与这些项相关或在这些项中有用的所有或大多数信息。因此，CRM信息是整个公司信息的子集，并且断言、解析和推断的三元组是各种CRM信息。作为整个企业知识图谱的子图谱的三元组的当前描述是用于解释而不是限制。在一些实施例中，至少由于各种原因，CRM数据、通信会话数据、联系数据、客户数据、与客户代表相关的信息或呼叫记录数据可以在单独的图谱中而不是子图谱中实现。在图1的示例中，以根据至少一种形式的语义逻辑(诸如，例如，谓词逻辑或描述逻辑)组织和连接的语义三元组来实现企业知识图谱(154)。在图1的示例中，企业知识图谱由定义逻辑的语义三元组组成，该定义逻辑包括通过整个计算机系统对远程代理可用的所有CRM相关知识。三元组是在这种三元组具有由推断定义的含义的意义下的语义三元组，该推断在附加的三元组中被清楚地描述，附加的三元组在此被称为“推断的三元组”。

三元组(752、754)是以逻辑形式表达的三部分式语句。根据上下文，不同的术语被用于按照逻辑有效地指代语句的相同的三个部分。在一阶逻辑中，该部分被称为常量、一元谓词及二元谓词。在网络本体语言(“OWL”)中，这些部分是个体、类和属性。在一些描述逻辑中，这些部分被称为个体、概念和角色。在本文中，三元组的元素被称为主体、谓词和客体，并且这样表示：＜主体＞＜谓词＞＜客体＞-或类似的：(主体谓词客体)，或按照旨在由人阅读的其他抽象形式。三元组有许多表达模式。三元组的元素可以表示为统一资源定位符(“URL”)、统一资源标识符(“URI”)或国际资源标识符(”IRI“)。三元组可以用N个四元组、Turtle语法、TriG、Javascript对象符号或“JSON”来表示，列表不胜枚举。这里使用的表达式，尖括号或圆括号中的主体-谓词-客体是一种抽象语法形式，其针对人类可读性而不是机器处理而被优化，尽管其实质内容对于三元组的表达是正确的。使用该抽象语法，这里是三元组的示例：

＜Bob＞＜is a＞＜person＞

＜Bob＞＜is a friend of＞＜Alice＞

＜Bob＞＜is born on＞＜the 4

＜Bob＞＜is interested in＞＜the Mona Lisa＞

＜the Mona Lisa＞＜was created by＞＜Leonardo da Vinci＞

＜the video‘La Joconde à Washington'＞＜is about＞＜the Mona Lisa＞

(＜鲍勃＞＜是＞＜人＞

＜鲍勃＞＜朋友是＞＜爱丽丝＞

＜鲍勃＞＜出生于＞＜1990年7月4日＞

＜鲍勃＞＜喜欢＞＜对蒙娜丽莎＞

＜蒙娜丽莎＞＜创作者是＞＜列昂纳多达芬奇＞＜＞

＜视频“蒙娜丽莎在华盛顿”＞＜讲述的是＞＜蒙娜丽莎＞)

相同的项可以在多个三元组中引用。在该示例中，鲍勃是四个三元组的主体，而蒙娜丽莎是一个三元组的主体和两个三元组的客体。这种使相同项成为一个三元组的主体和另一个三元组的客体的能力使得能够实现三元组之间的连接，并且连接的三元组形成图谱。

为了进一步解释三元组和图谱之间的关系，图2阐明了图谱(600)的线条图。图2的示例性图谱以线条图的形式实现了上述关于鲍勃和蒙娜丽莎的示例性三元组图谱。在图2的示例中，图谱边(604、608、612、616、620、624)分别表示节点之间的关系，即，表示谓词＜是＞、＜朋友是＞、＜出生于＞、＜喜欢＞、＜创作者是＞、以及＜讲述的是＞。节点本身表示三元组的主体(602、618、626)和客体(606、610、614、618、622)，＜鲍勃＞，＜人＞，＜爱丽丝＞，＜1990年7月4日＞，＜蒙娜丽莎＞，＜莱昂纳多达芬奇＞和＜视频“蒙娜丽莎在华盛顿”＞。表示蒙娜丽莎的节点(618)既是主体又是客体。表示蒙娜丽莎的节点(618)是描述鲍勃的兴趣的三元组(602,616,618)的客体。表示蒙娜丽莎的节点(618)是描述由蒙娜丽莎是由莱昂纳多创建的三元组(618、620、622)的主体。

在知识表示系统中，知识以三元组的图谱表示，包括例如以Gremlin、Cypher、Prolog数据库、Lisp数据结构或RDFS、OWL和其他本体语言中的面向RDF的本体实现的知识表示。通过被配置为在例如Gremlin、Cypher、Prolog、Lisp或SPARQL中执行语义查询和语义推断的搜索引擎对这些图谱进行搜索和推断。

Gremlin是通过来自阿帕奇基金会的TinkerPop图谱计算框架提供的查询语言。Cypher是AI程序，其根据自然语言输入生成SPARQL查询，允许用户说明语来更新和查询数据库；Cypher将其自身的语法和词典带入自然语言处理。SPARQL是“SPARQL协议和RDF查询语言”的递归首字母缩写词。Lisp是一种可靠、灵活的编程语言，其广泛用于人工智能、知识表示和语义应用。Prolog是通用逻辑编程语言。Prolog支持对被表达为Prolog数据库中的语句和规则的连接的三元组的查询。SPARQL支持对以RDFS、OWL或其他面向RDF的本体表达的本体的查询。关于Prolog、SPARQL、Cypher、Gremlin、Lisp等，这些是解释本发明的示例性实施例的技术的示例。因此，这不是对本发明的限制。根据实施例有用的知识表示可以采取现在或将来本领域中的许多形式，并且所有这些指示表示现在完全在本发明的范围内且将一直在本发明的范围内。

描述逻辑是形式知识表示语言的家族的成员。一些描述逻辑比命题逻辑更具有表达性，但比一阶逻辑具有更少的表达性。与一阶逻辑相反，描述逻辑的推理问题通常是可决定的。因此，可以针对描述逻辑中的搜索和推断问题实现高效的决定过程。存在一般的、空间的、时间的、时空的和模糊的描述逻辑，并且每个描述逻辑通过支持不同的数学构造器集合而以表达性和推理复杂度之间的不同平衡为特征。

搜索查询沿语义的尺度设置。例如，传统的网络搜索被置于该该尺度的零点上，无语义、无结构。针对关键词“派生”的传统网络搜索返回讨论派生作品的文学概念以及演算过程的数千个HTML文档。针对关键词“差速器”的传统网络搜索返回描述汽车部件的许多网页和讨论演算函数的许多网页。

其他查询沿尺度的中点、某些语义、某些结构、不完全完整地布置。这实际上是网页搜索中的当前趋势。这样的系统可以被称为可执行的而不是可决定的。从一些观点来看，可决定性不是主要关注点。例如，在许多网络应用中，数据集是巨大的，并且它们根本不需要100％的正确模型来分析可能已经被某些本身不完美的启发式程序爬取、刮取并被转换成结构的数据。人们使用Google是因为它可以在很多时候找到好的答案，即使它不能一直找到完美的答案。在这种粗糙且混乱的搜索环境中，可证明的正确性不是关键目标。

在结果的正确性是关键并且输入可决定性的情况下设置其他类别的查询。通过电话与讨论前差速器的汽车客户通话的作为数据中心中的远程代理的用户不关心需要对计算结果进行分类以找到正确的术语。这样的用户需要汽车术语的正确定义，并且用户需要实时(即，例如，在几秒内)对话中的查询结果。

在形式逻辑中，如果存在一种方法，使得对于可以用系统表达的每个断言，该方法能够决定该断言在系统内是否有效，则该系统是可决定的。在实际情况中，针对可决定描述逻辑的查询将不会无限地循环、崩溃、不能返回答案或返回错误答案。可决定描述逻辑支持清楚、明确和机器可处理的数据模型或本体。不可决定的系统不支持清楚、明确和机器可处理的数据模型或本体。可决定描述逻辑支持算法，通过该算法计算机系统可确定在逻辑中定义的类的等价性。不可决定的系统不支持该算法。可决定描述逻辑可以用C、C++、SQL、Lisp、RDF/RDFS/OWL等来实现。在RDF空间中，OWL的细分在可决定性方面是变化的。完全OWL不支持可决定性。OWL DL支持可决定性。

为了进一步说明，图3阐明了实现根据本发明的实施例的CRM的示例计算机系统(178)的功能框图。图3的示例计算机系统包括处理器或“CPU”(156)、随机存取存储器或“RAM”(168)、声卡(174)和显示器(180)。该系统包括CRM应用程序(195)，通常存储在RAM中并在CPU上执行。CRM应用通过显示器以控制面板(110)的形式展示图形用户界面或“GUI”，控制面板(110)除了通过使用显示器(180)之外还通过使用声卡、音频设备、键盘和鼠标(181)接受并提供用户I/O。

图3所示的示例计算机系统通常进行操作以通过在远程代理(128)和客户代表(129)之间的第一通信联系(142)时建立通信会话(140)作为计算机系统的计算机存储器(169)的结构来实现根据本发明实施例的CRM。在建立会话时，计算机系统将作为自动计算机器的面向对象的模块的会话(140)建立作为计算机系统的计算机存储器的结构，该自动计算机器的结构和内容(509)也作为语义三元组(752、754)被存储在企业知识图谱(154)中。也就是说，在该示例中，会话最初至少被建立作为面向对象的会话类的实例。建立这种会话包括在计算机存储器中存储主体代码、时间戳、远程代理的标识、客户代表的标识以及可选地还有关于会话的其他信息作为会话的成员数据元素。

计算机系统通常还通过跨通信平台的通信会话管理一系列(374)通信联系来运行，该一系列通信联系包括远程代理和客户代表之间的第一联系(142)以及随后的通信联系(144)。计算机系统通过建立作为自动计算机器的面向对象的模块的每个联系来管理一系列联系，该自动计算机器构成计算机系统的计算机存储器，并且其结构和内容也作为语义三元组存储在企业知识图谱中。也就是说，在该示例中，联系最初至少被建立为面向对象的联系类的实例。管理一系列联系包括在计算机存储器中记录开始联系的时间戳、联系的持续时间、联系的会话标识符、平台类型、联系状态、联系的任何通信内容以及可选地还有关于联系的其他信息作为每个联系的成员数据元素。

图3的示例计算机系统包括解析引擎(380)，其将通信会话的结构和内容(509)解析为描述逻辑的解析的三元组(752)，通信会话的结构和内容(509)包括通信联系的结构和内容。图3的示例计算机系统还包括推断引擎(298)，其根据企业知识图谱的推断规则(376)从解析的三元组(752)推断出推断的三元组(754)。图3的示例计算机系统的功能包括将解析的三元组(752)和推断的三元组(754)存储(398)在企业知识图谱(154)中以用于根据实施例的CRM中。

在图3的示例中，CRM应用(195)生成一系列(374)联系(142、144)。CRM联系是生成内容的活动，该内容包括用于解析(380)和推断(298)成三元组(752、754)的数字化词，该三元组可有用地包括在企业知识图谱(154)中。例如，作为面向对象的联系类的实例，毫无疑问，除了词之外，CRM联系还将包括成员方法、其他成员数据元素等。然而，CRM联系基本上是用于解析和推断的内容和结构(509)的容器或包装器。CRM内容的示例包括描述新客户、新客户代表、新呼叫记录、由用户利用GUI小部件新构建的三元组等的词。CRM联系可由用户输入(例如，对指定联系的控制面板上的按钮小部件的激活)界定范围。

在该示例中，推断引擎(298)在语义推理器(378)的情况下进行操作。语义推理器是自动模块，其扩展具有丰富功能的推断引擎。在本文中，通常假设查询执行和推断由同一引擎(查询和推断引擎，通常简称为推断引擎)执行。能够将查询引擎配置为与推断引擎分离，但是为了便于解释，在本文中，将查询功能和推断功能组合在“推断引擎”中。通过推理器，推断引擎的功能可以被限制为查询执行和推断。语义推理器提供与查询和推断相关联的附加功能。这种附加功能的示例包括将解析的三元组和推断的三元组插入到企业知识库中，将解析的三元组或推断的三元组存储为单独的图谱以用于进一步处理，将解析的三元组和推断的三元组存储到新的单独的数据集中以用于发布，将解析的三元组和推断的三元组序列化以用于保存到文件，显示解析的三元组和推断的三元组以用于由用户管理等。

为了进一步说明，图4阐明了实现根据本发明实施例的CRM的示例控制面板(110)的线条图。控制面板是计算机系统(152)的图形用户界面(“GUI”)。控制面板本身是由语音使能CRM应用展示的GUI，该语音使能CRM应用向远程代理提供针对联系中心的所有相关功能、线索、脚本、企业知识库、具有语义CRM存储的三元组服务器、客户信息，关于客户代表的信息、呼叫记录存储、声音服务、通信会话、通信联系等的前端、界面等。

控制面板实现被称为小部件的数字控件。小部件是GUI交互元件，诸如按钮或滚动条。小部件是自动元件，用户通过直接操纵与该自动元件交互以读取或编辑信息或管理控件。每个小部件表现为GUI的数字部分，并且便于特定类型的用户-计算机交互。一些小部件(例如，标签、按钮和复选框)支持与用户的交互。其他小部件用作容器，例如，窗口、面板和标签，该容器将添加到该容器的小部件分组。根据实施例的在CRM控件中可选地有用的小部件的示例包括按钮、单选按钮、复选框、滑块、列表框、旋转器、下拉列表、菜单、菜单栏、滚动条、文本框、对话框等。

在图4的示例中，通过使用搜索小部件(115)，控制面板已经被导航以指向名为表面电子设备公司的客户信息。客户信息滚动框小部件(352)将显示客户信息(未示出)，诸如，地址、网页链接、电子邮件、电话等。类似地，客户代表滚动框小部件354将显示(未示出)表面电子设备公司的已经与远程代理具有联系的每个客户代表的身份、联系信息和其他信息。

在图4的示例中，控制面板生成CRM会话(140)和联系(144)，并将它们交给解析引擎(380)和推断引擎(298)以供进一步处理，包括显示这种处理的结果(752、754)以支持用户代理的CRM操作。控制面板通过呼叫记录文本输入滚动文本框小部件(366)接受用户输入的文本的词作为描述远程代理(128)与客户代表(129)之间的电话呼叫的内容(509)，并且，当事件小部件按钮(394)被调用时，控制面板将描述电话呼叫的输入词收集到CRM联系(374)中并且将该联系传递到解析引擎(380)。控制面板接受用户输入的文本的词作为电子邮件、文本消息和从电话呼叫识别和记录的语音的内容(509)。因此，GUI的一系列用户操作生成一系列联系，以便由解析引擎和推断引擎处理成解析的三元组和推断的三元组。计算机系统(152)的解析引擎(380)和推断引擎(298)处理会话(140)和联系(144)的结构和内容(509)，并且在控制面板(110)上在滚动文本框小部件中显示得到的解析的三元组(752)和推断的三元组(754)。

图4的示例中的控制面板以若干方式运行以获取被收集到CRM联系中以供解析和推断的内容。在将数字化内容(509)提供至解析引擎(298)的第一种可替代方式中，控制面板通过语音引擎(153)将来自从远程代理(128)和客户代表(129)之间的对话的词识别为数字化语音。在该示例方法中，如下执行从这样的对话中识别语音。来自对话(313)的语音的词经过计算机(152)的麦克风(176)和放大器，并且在瘦客户端架构中，经过VOIP连接到达到声音服务器(151)，在声音服务器中，语音识别引擎将词识别为数字化语音流，该数字化语音流被传递到自然语言处理(“NLP”)引擎，该NLP引擎将数字化语音处理为语句和词类，并且将如此处理的词(509)传递到解析引擎(298)，在解析引擎(298)中，如此处理词被解析为三元组(752)。这是控制面板提供包括在联系中的内容的第一可替代方式。

在向解析引擎提供数字化内容的第二可替代方式中，控制面板将来自文本框小部件(366)的呼叫记录的内容收集到联系中。远程代理不是说出词作为联系的内容，而是将呼叫记录键入文本框小部件(366)中，并且如此键入的文本被控制面板提供给自然语言处理引擎(155)作为联系的数字化内容。对自然语言处理引擎来说，来自文本框(366)的键入的词与来自口语对话的数字化语音流中的词之间没有差异。因此，除了不需要语音识别之外，第二可替代方式类似于第一可替代方式，因为当数字化文本流到达语音引擎(153)时，该流中的词已经通过经由文本框(366)键入该词而被数字化。自然语言处理引擎(155)按照与第一可替代方式相同的方式工作，将来自文本框(366)的数字化文本处理成语句和词类，并将如此处理的词(509)传递到解析引擎(298)，在解析引擎(298)中，如此处理的词被解析成三元组(752)。这是控制面板提供包括在CRM联系中的内容的第二可替代方式。

在向解析引擎提供数字化词的第三可替代方式中，控制面板通过控制面板的小部件(360、362、364)向解析引擎传递被指定为三元组的元素的词。这些小部件是三元组的主体(360)、三元组的谓词(362)和三元组的客体(364)的下拉菜单列表。谓词(362)和客体(364)通常是在支持企业知识图谱的语义CRM三元组存储部分的本体中已经定义的三元组元素。主体(360)是用于包括在三元组中的文本词候选流。主体下拉菜单(360)中的文本由语音引擎(153)从呼叫记录文本(366)或从根据对话(313)识别的词提供，或以其它方式提供。通过从主体下拉菜单(360)中选择文本，例如，通过键盘或鼠标(181)进行选择，远程代理(128)指定要包括在联系中的内容(509)。远程代理可以通过双击或通过拖放到用于三元组的组合框(368)上来从下拉菜单(360)中选择文本。远程代理还可以可选地通过双击或拖放来选择谓词(362)或客体(364)以便与所选主体一起包含在同一三元组中。在一些实施例中，远程代理对谓词和客体的选择还可以绑定在解析引擎上。在其他实施例中，远程代理的选择仅作为推荐由解析引擎处理。解析引擎(298)可选地接受远程代理对谓词和客体的选择，或者解析处理做出自己对谓词和三元组的选择，以便与词一起包括在至少一个解析的三元组中(752)。这是控制面板提供包括在CRM联系中的内容的第三可替代方式。

为了进一步说明，图5示出了根据本发明的实施例的瘦客户端架构中的CRM的示例设备的功能框图。瘦客户端架构是一种客户端-服务器架构，其中，语音处理和三元组处理中至少一些从客户端卸载到服务器，在一些实施例中，语音处理和三元组处理中的大部分从客户端卸载到服务器，在一些实施例中，语音处理和三元组处理的全部从客户端卸载到服务器。瘦客户端的瘦度是变化的。图5的示例中的计算机(152)是大多数语音处理被卸载到声音服务器(151)的瘦客户端。计算机(152)接受声音输入(315、174)，但随后通过VOIP连接(216)将声音输入传送到声音服务器(151)，在声音服务器(151)执行所有的语音处理。在该示例中的语音使能装置实现了用于三元组处理、自然语言处理引擎(155)、解析引擎(380)和推断引擎(298)的一些能力，但是其中大部分是瘦客户端中的可选架构。可以在不具有自然语言处理引擎(155)、不具有解析引擎(380)且不具有推断引擎(298)的情况下，通过仅将CRM会话以及联系结构和内容(509)传递到自身执行所有解析和推断的三元组服务器(157)，来实现具有减少的存储容量的装置，例如智能手表或移动电话。

在图5的特定示例中，计算机(152)占据瘦客户端架构的中间地位。它支持很少的语音处理或者不支持语音处理，但是它确实支持一些三元组处理。在该示例中，瘦客户端计算机仅对RAM(168)中的三元组存储(752、754)执行解析和推断，将大规模的存储留给三元组服务器(157)。语义推理器(378)根据需要从三元组服务器(157)上的存储加载之前存储的断言的三元组，以支持推断。这是在根本不具有三元组存储的极瘦客户端与以下关于图9描述的胖客户端之间的折衷。

图5的示例设备包括通过数据通信网络(100)由VOIP连接(216)连接用于数据通信的计算机(152)和声音服务器(151)。控制面板(110)在语音使能装置(152)上运行，并且在该示例中，控制面板(110)是通过声音(315)、通过显示器(180)上的GUI、通过键盘和鼠标(181)等操作用户I/O的语音使能应用。CRM应用(195)将控制面板作为用户界面来操作，并且CRM应用可以被实现为在语音使能浏览器上执行的X+V或SALT文档的集合或序列、在Java虚拟机上执行的Java语音应用、或者在其他技术中实现的语音使能应用。图5的示例计算机还包括声卡(174)，其是I/O适配器的示例，该I/O适配器被专门设计用于接受来自麦克风(176)的模拟音频信号，并将音频模拟信号转换为数字形式，以便由编码解码器(183)进一步处理。

VOIP代表“互联网协议电话(Voice Over Internet Protocol)”，是在基于IP的数据通信网络上路由语音的通用术语。语音数据在通用分组交换数据通信网络上流动，而不是在传统的专用电路交换声音传输线上流动。用于通过IP数据通信网络承载声音信号的协议通常被称为“IP电话”或“VOIP”协议。VOIP流量可以部署在任何IP数据通信网络上，任何IP数据通信网络包括缺少到互联网的其余部分的连接的数据通信网络，例如VOIP流量可以部署在私有建筑物-广域数据通信网络或“LAN”上。

许多协议可以用于实现VOIP，包括例如以IETF的会话发起协议(“SIP”)和ITU的协议(称为“H.323”)实现的VOIP类型。SIP客户端使用TCP和UDP端5060以连接到SIP服务器。SIP本身用于建立和拆除用于语音传输的呼叫。然后，具有SIP的VOIP使用RTP来传输实际的编码语音。类似地，H.323是来自国际电信联盟的标准分部的综合(umbrella)推荐，国际电信联盟定义了在任何分组数据通信网络上提供视听通信会话的协议。

在该示例中，CRM应用(195)是向用户(128)呈现声音接口的用户级的、语音使能的客户端侧的计算机程序，CRM应用(195)提供音频提示和响应(314)并且接受输入的语音(315)以进行识别。CRM应用(195)提供语音接口，通过该语音接口，用户可以通过麦克风(176)提供口述的语音以进行识别，并且通过声卡(174)的音频放大器(185)和编码器/解码器(“编码解码器”)(183)将该语音数字化，并且提供给声音服务器(151)以进行识别。语音使能应用(195)根据VOIP协议将数字化的语音打包到识别请求消息中，并通过网络(100)上的VOIP连接(216)将语音发送到声音服务器(151)。

通过接受对话指令、VoiceXML段等，并返回语音识别结果(包括表示识别的语音的文本、用作对话中变量值的文本、以及从执行语义解释脚本的输出)以及语音提示，声音服务器(151)为语音使能装置提供声音识别服务。声音服务器(151)包括计算机程序，该计算机程序在诸如例如X+V应用、SALT应用、Java语音应用等的语音使能应用中为声音提示和用户输入的声音响应提供文本到语音(“TTS”)转换。

图5的示例中的计算机(152)包括语义查询和推断引擎(298)、自动计算机器的模块，该自动计算机器的模块从CRM应用(195)和控制面板(110)接受解析的三元组(752)并根据推断的语义规则(376)对解析的三元组(752)执行语义查询和推断。在本文中，为了便于参考，查询和推断引擎通常仅被称为推断引擎。但是较长的名称是适当的，因为在许多实施例中用于推断的指令，尤其是实现用于三元组的RDF/RDGS/OWL本体和用于查询的SPARQL的哪些指令，被表达为SPARQL查询的组件，并且在这样的实施例中，推断规则(376)可以被表达为并且通常被表达为语义查询的元素。在这样的实施例中，CRM应用(195)利用通过控制面板来自语音(315)、GUI(110)、键盘或鼠标(181)等的用户输入来制定语义查询。这种语义查询是针对结构化数据设计和实现的查询。语义查询利用逻辑运算符、命名空间、模式匹配、子类化、传递关系、语义规则和上下文全文搜索。语义查询用于命名的图谱、链接的数据或三元组。在本发明的实施例中，链接的三元组通常形成图谱。这种结构化数据使得语义查询能够处理信息项之间的实际关系并根据数据的结构化网络推断答案。语义查询与语义搜索形成对比，语义搜索试图在非结构化文本中使用语义来改善搜索结果的含义，取得了不同程度的成功。

在C、C++、Java、Prolog、Lisp等中具有语义查询的示例公式。例如，W3C的语义网络技术栈是提供SPARQL以用类似于SQL的语法来实现语义查询的示例公式。语义查询用于针对三元组存储、图谱数据库、语义维基百科、自然语言和人工智能系统中结构化的数据。如上所述，语义查询用于结构化的数据，并且在本情况的特定示例中，结构化的数据是在以符合形式逻辑(有时是谓词逻辑，通常是描述逻辑)的方式连接的语义三元组中描述和定义的词，该词包括URI中标识的文字短语和名称。在本发明的许多实施例中，针对根据实现可决定性的描述逻辑而结构化的数据来断言语义查询。

在图5的示例设备中，计算机(152)被耦合以通过通信适配器(167)、无线连接(118)、数据通信网络(100)和有线连接(121)与三元组服务器(157)进行数据通信。三元组服务器(157)为三元组储存提供大容量备份。三元组服务器是将三元组串行化并将串行化的三元组存储在关系数据库、表、文件等中的自动计算机器的配置。三元组服务器根据需要从非易失性存储装置检索这样的串行化的三元组，将串行化的三元组解析为三元组子图谱，并且在请求时将这样的三元组子图谱提供给瘦客户端计算机和其他装置，以用在利用根据本发明的实施例利用CRM中的三元组的系统中。

图5中所示的示例计算机系统通常进行操作以通过在远程代理(128)与客户代表(129)之间的第一通信联系时建立通信会话(140)作为计算机系统柜的计算机存储器(168)的结构来实现根据本发明的实施例的CRM。在建立会话时，计算机系统将作为自动计算机器的面向对象的模块的会话(140)作为计算机系统的计算机存储器的结构，自动计算机器的结构和内容(509)也作为语义三元组(752、754)被存储在企业知识图谱(154)中。也就是说，在该示例中，会话最初至少被建立为面向对象的会话类的实例。建立这种会话包括在计算机存储器中存储主体代码、时间戳、远程代理的标识、客户代表的标识以及可选地还有关于会话的其他信息作为会话的成员数据元素。

计算机系统(152)通常还通过跨通信平台的通信会话(140)管理一系列通信联系(144)来运行，该一系列通信联系(144)包括远程代理和客户代表之间的第一联系(142)以及随后的通信联系。计算机系统通过建立作为自动计算机器的面向对象的模块的每个联系来管理一系列联系，该自动计算机器构成计算机系统的计算机存储器(168)，并且其结构和内容(509)也作为语义三元组被存储在企业知识图谱(154)中。也就是说，在该示例中，联系(144)最初至少被建立为面向对象的联系类的实例。管理一系列联系包括在计算机存储器中记录开始联系的时间戳、联系的持续时间、联系的会话标识符、平台类型、联系状态、联系的任何通信内容以及可选地还有关于联系的其他信息作为每个联系的成员数据元素。

可以用一个或多个声音服务器实现根据本发明的实施例的具有语义三元组的CRM，特别是在瘦客户端架构中。声音服务器是提供语音识别和语音合成的计算机，即，自动计算机器。为了进一步说明，图6阐明了根据本发明实施例的表示支持CRM的示例声音服务器(151)的自动计算机器与客户端计算机的框图。图6的声音服务器(151)包括至少一个计算机处理器(156)或“CPU”以及随机存取存储器(168)(“RAM”)，随机存取存储器(168)通过高速存储器总线(166)和总线适配器(158)连接到CPU(156)和声音服务器的其它组件。

声音服务器应用(188)存储在RAM(168)中，声音服务器应用(188)是能够操作系统中的声音服务器的自动模块，该系统被配置用于根据本发明的实施例的CRM。声音服务器应用(188)通过接受语音识别请求并返回语音识别结果来为语音使能客户端装置提供声音识别服务，语音识别结果包括表示识别的语音的文本、用作对话中的变量值的文本、以及作为用于语义解释的脚本的字符串表示的文本。声音服务器应用(188)还包括为语音使能客户端侧应用(诸如，例如，语音使能浏览器、X+V应用、SALT应用、Java语音应用)中的用户输入的声音提示和声音响应提供文本到语义(“TTS”)转换的能力。

声音服务器应用(188)可以通过对来自X+V客户端、SALT客户端、Java语音客户端或其他语音使能客户端装置的HTTP请求提供响应而被实现为网络服务器，以Java、C++、Python、Perl或支持X+V、SALT、VoiceXML的任意语言或其他语音使能语言被实现。对于另一个示例，声音服务器应用(188)可以通过对来自运行在语音使能装置上的Java客户端应用的HTTP请求提供响应而被实现为Java服务器，该Java服务器在Java虚拟机(102)上运行并且支持Java声音框架。并且，支持本发明实施例的声音服务器应用可以以各种其他方式被实现，并且所有这些方式都在本发明的范围内。

在该示例中，声音服务器(151)包括自然语言处理语音识别(“NLP-SR”)引擎(153)。NLP-SR引擎有时在本文中被简称为“语音引擎”。语音引擎是功能模块，通常是软件模块，但是它也可以包括专门的硬件，其进行识别人类语音和生成人类语音的工作。在该示例中，语音引擎(153)是包括自然语言处理(“NLP”)引擎(155)的自然语言处理语音引擎。NLP引擎接受来自自动语音识别(“ASR”)引擎的识别的语音，将识别的语音处理为词类、主体、谓词、客体等，然后使这种部分可用于解析引擎，以转换为语义三元组进一步推断且包括在三元组存储中。

语音引擎(153)包括用于语音识别的自动语音识别(“ASR”)引擎和用于生成语音的文本到语音(“TTS”)引擎。语音引擎还包括语法(104)、词典(106)和语言特定声学模型(108)。语言特定的声学模型(108)是例如将语音特征向量(“SFV”)与表示人类语言中的词的发音的音素相关联的数据结构、表或数据库。词典(106)是文本形式的词与表示每个单词的发音的音素的关联，词典有效地标识能够由ASR引擎识别的词。在RAM(168)中还存储了文本到语音(“TTS”)引擎(194)，其是接受文本作为输入并以数字编码语音的形式返回同一文本的计算机程序指令的模块，其用于提供语音作为对语音使能系统的用户的提示和响应。

语法(104)将当前可以识别的词和词的序列传送给ASR引擎(150)。为了进一步解释，区分语法的目的和词典的目的。词典将ASR引擎可以识别的所有词与音素相关联。语法传送当前有资格被识别的词。在任何特定时间的两个集合通常不相同。

可以按照ASR引擎所支持的多种格式(包括例如Java语音语法格式(“JSGF”)、W3C语音识别语法规范(“SRGS”)的格式、来自IETF的RFC2234的扩展的巴科斯格式(“ABNF”))、按照W3C的随机语言模型(N-Gram)规范中描述的随机语法的形式、以及按照本领域技术人员可以想到的其他语法格式来表达语法。语法通常作为对话的元素来操作，诸如，例如VoiceXML＜菜单＞或X+V＜表单＞。语法的定义可以在对话中被内嵌表达。或者，语法可以在在外部单独的语法文档中实现，并且通过具有URI的对话进行引用。这里是以JSFG表达的语法的示例：

(＜语法范围＝“对话”＞＜！[CDATA[

#JSGF V1.0；

语法命令；

＜命令＞＝[提醒我]呼叫|电话|打电话＜名字＞＜何时＞；

＜姓名＞＝bob|martha|joe|pete|chris|john|artoush；

＜何时＞＝今天|今天下午|明天|下周；

]]

＜/语法＞)

在该示例中，名为＜命令＞、＜姓名＞和＜何时＞的元素是语法的规则。规则是规则名称和规则扩展的组合，规则向ASR引擎或声音解释器建议当前可以识别哪些词。在该示例中，扩展包括连接词(conjunction)和间隔(disjunction)，并且竖线“|”表示“或”。ASR引擎或声音解释器按顺序处理规则，先处理＜命令＞，然后处理＜姓名＞，随后处理＜何时＞。＜命令＞规则接受识别“呼叫”或“电话”或“打电话”加(即，结合)从＜姓名＞规则和＜何时＞规则返回的任何内容。＜姓名＞规则接受“bob”或“martha”或“joe”或“pete”或“chris”或“john”或“artoush”，而＜何时＞规则接受“今天”或“今天下午”或“明天”或“下周”。命令语法作为整体匹配如下这些的表达：

·“下周给bob打电话”，

·“今天下午给martha打电话”，

·“提醒我明天给chris打电话”，和

·“提醒我今天给pete打电话”。

在该示例中，声音服务器应用(188)被配置为从通过网络与声音服务器远程定位的语音使能客户端装置接收来自用户的用于识别的数字化语音，并将该语音向前传递到ASR引擎(150)以用于识别。ASR引擎(150)是计算机程序指令的模块，在该示例中，其也被存储在RAM中。在执行自动语音识别时，ASR引擎接收按照至少一个数字化词的形式的语音以用于识别，并使用数字化词的频率分量来导出语音特征向量或SFV。SFV可以例如由数字化语音的样本的前十二或十三个傅立叶或频域分量来定义。ASR引擎可以使用SFV从语言特定声学模型(108)推断单词的音素。ASR引擎然后使用音素来查找词典(106)中的词。

RAM中还存储VoiceXML解释器(192)，它是处理VoiceXML语法的计算机程序指令的模块。输入到VoiceXML解释器(192)的VoiceXML可以例如源自于在语音使能装置上远程运行的VoiceXML客户端、源自于在语音使能装置上远程运行的X+V客户端、源自于在语音使能装置上运行的SALT客户端、源自于在多媒体装置上远程运行的Java客户端应用等。在这个示例中，VoiceXML解释器(192)解释和执行VoiceXML段，该VoiceXML段表示从远程语音使能装置接收并通过声音服务器应用(188)提供给VoiceXML解释器(192)的声音对话指令。

如瘦客户端架构中的客户端侧CRM应用(图5中的195)或控制面板(图5中的110)的语音使能应用可以向通过经由网络与这样的语音使能应用进行数据通信的VoiceXML解释器(149)提供声音对话指令、VoiceXML段、VoiceXML＜表单＞元素等。声音对话指令包括一个或多个语法、数据输入元素、事件处理器等，它们建议VoiceXML解释器如何管理来自用户的声音输入以及要呈现给用户的声音提示和响应。VoiceXML解释器通过根据VoiceXML表单解释算法(“FIA”)(193)顺序处理对话指令来管理这些对话。VoiceXML解释器解释由语音使能应用提供给VoiceXML解释器的VoiceXML对话。

如前所述，表单解释算法(“FIA”)驱动用户和语音使能应用之间的交互。FIA通常负责选择和播放一个或多个语音提示，收集用户输入(填充一个或多个输入项的响应或者一些事件的抛出)，并解释属于新填充的输入项的动作。FIA还处理语音使能应用初始化、语法激活和停用、进入和离开具有匹配表达的表单以及许多其它任务。FIA还维护内部提示计数器，内部提示计数器随着每次试图激发用户的响应而增加。也就是说，每次试图提示来自用户的匹配语音响应失败时，内部提示计数器递增。

RAM(168)中还存储有操作系统(154)。在根据本发明的实施例的声音服务器中使用的操作系统包括UNIX

图6的示例声音服务器(151)包括总线适配器(158)、包含用于高速总线的驱动电子器件的计算机硬件组件、前端总线(162)、视频总线(164)和存储器总线(166)以及用于较慢扩展总线(160)的驱动电子器件。在根据本发明的实施例的声音服务器中有用的总线适配器的示例包括英特尔北桥、英特尔存储器控制器集线器、英特尔南桥和英特尔I/O控制器集线器。在根据本发明的实施例的声音服务器中使用的扩展总线的示例包括行业标准架构(“ISA”)总线和外围组件互连(“PCI”)总线。

图6的声音服务器(151)包括通过扩展总线(160)和总线适配器(158)耦接到处理器(156)和声音服务器(151)的其它组件的磁盘驱动适配器(172)。磁盘驱动适配器(172)将非易失性数据存储连接到磁盘驱动(170)形式的声音服务器(151)。在声音服务器中使用的磁盘驱动适配器包括集成驱动电子器件(“IDE”)适配器、小型计算机系统接口(“SCSI”)适配器以及本领域技术人员将想到的其他适配器。另外，针对声音服务器，非易失性计算机存储器可以实现为如本领域技术人员所知的光盘驱动器、电可擦除可编程只读存储器(所谓的“EEPROM”或“闪速”存储器)、RAM驱动器等。

图6的示例声音服务器包括一个或多个输入/输出(“I/O”)适配器(178)。声音服务器中的I/O适配器通过例如软件驱动器和计算机硬件实现面向用户的输入/输出，以控制到显示装置(诸如计算机显示屏)的输出以及来自用户输入装置(181)(诸如键盘和鼠标)的用户输入。图6的示例声音服务器包括视频适配器(209)，其是专门设计用于向显示装置(180)(诸如显示屏或计算机监视器)的图形输出的I/O适配器的示例。视频适配器(209)通过高速视频总线(164)、总线适配器(158)和也作为高速总线的前端总线(162)连接到处理器(156)。

图6的示例声音服务器(151)包括用于与其它计算机(182)进行数据通信以及用于与数据通信网络(100)进行数据通信的通信适配器(167)。这种数据通信可以通过RS-232连接、通过诸如通用串行总线(“USB”)的外部总线、通过诸如IP数据通信网络的数据通信数据通信网络、以及按照本领域技术人员将想到的其他方式串行地执行。通信适配器实现数据通信的硬件级别，通过该硬件级别，一个计算机直接地或通过数据通信网络向另一计算机发送数据通信。可用于本发明实施例的通信适配器的示例包括用于有线拨号通信的调制解调器、用于有线数据通信网络通信的以太网(IEEE 802.3)适配器和用于无线数据通信网络通信的802.11适配器。

为了进一步说明，图7阐明了根据本发明的实施例的自动计算机器的框图，该自动计算机器包括用作CRM的三元组服务器(157)的计算机的示例。图7的三元组服务器(157)包括至少一个计算机处理器(156)或“CPU”以及随机存取存储器(168)(“RAM”)，其通过高速存储器总线(166)和总线适配器(158)连接到处理器(156)和三元组服务器的其他组件。处理器通过视频总线(164)连接到视频适配器(209)和计算机显示器(180)。处理器通过扩展总线(160)连接到通信适配器(167)、I/O适配器(178)和磁盘驱动适配器(172)。处理器通过数据通信网络(100)和无线连接(118)连接到语音使能膝上型计算机(126)。RAM设置有操作系统(154)。

RAM中还设置有三元组服务器应用(297)、数据通信会话(140)、数据通信联系(144)、会话和联系的结构和内容(509)、推理规则(376)、自然语言处理(“NLP”)引擎(155)、解析引擎(380)、推断引擎(298)和语义推理器(378)。RAM中还设置有三元组串行化器(294)、三元组转换器(292)和一个或多个三元组文件(290)。

三元组服务器应用程序(297)通过网络(100)从诸如膝上型计算机(126)的客户端侧装置接受会话(140)和联系(144)的实例，从这些实例中提取结构和内容(509)用于解析。NLP引擎可选地通过首先至少一些内容处理为语句和词类并且随后将如此处理的内容提供至解析引擎来简化解析过程。解析引擎将结构和内容解析为解析的三元组(752)。推断引擎(298)将解析的三元组(752)和推断规则(376)作为输入，并且推断出推断的三元组(754)。三元组服务器应用(297)然后将解析的三元组和推断的三元组的副本返回给客户端侧，以用于进一步处理，并且将解析的三元组和推断的三元组存储在企业知识图谱(154)中。这样，三元组服务器从客户端装置(126)卸载大部分的三元组相关的处理和存储数据处理工作负荷。

串行化器(294)管理RAM中的三元组存储(750、752、754)和各种形式的磁盘存储或其他非易失性存储之间的三元组的传输。串行化器(294)接受三元组存储的内容作为输入，并将它们串行化以作为三元组文件(290)、表、关系数据库记录、电子表格、文本文档等的输出，以便长期存储在非易失性存储器中，诸如，存储在硬盘(170)上。串行化器(294)接受三元组文件(290)作为输入，并且将解析的三元组输出到RAM中的三元组存储中。在许多实施例中，当串行化器(294)接受三元组文件(290)作为输入并且将解析的三元组输出到RAM中的三元组存储中时，串行化器将输出的三元组存储存储到存储器的连续段中。连续的存储可以在C编程语言中通过调用malloc()函数来实现。连续的存储可由Python缓冲器协议实现。可以按照本领域技术人员所能想到的其他方式来实现连续的存储，并且所有这些方式都在本发明的范围内。在许多实施例中，三元组存储(750、752和754)将被存储在连续的存储器的段中。

参考图8更详细地解释了连续的存储器。图8阐明了计算机存储器系统的框图，该计算机存储器系统被配置为支持根据实施例的CRM，该计算机存储器系统包括由执行CRM应用程序(195)的各种寄存器(190)组成的计算机处理器(156)。CRM应用(195)、处理器的寄存器(190)以及存储器的所有伴随的配置、数据通信会话(140)、通信联系(144)、会话和联系(509)的结构和内容的表示、解析的三元组(752)、推断的三元组(754)等都利用虚拟存储器(708)中设置的存储器地址(700)进行操作。虚拟存储器的内容由处理器上高速缓存(186)、RAM(168)和磁盘(170)中的物理存储来备份。高速缓存的内容被组织在高速缓存行(702)中。RAM中的存储器被组织在页面(712)中。磁盘上的存储器被组织为帧(706)。存储器管理单元(“MMU”)(184)将虚拟存储器地址翻译成物理存储器位置，并且将存储器的内容从物理存储移动到处理器寄存器以及从处理器寄存器移出。在访问物理存储器时，MMU总是首先在高速缓存中查看。在高速缓存中找不到内容被称为高速缓存未命中(714)。在高速缓存未命中时，MMU在RAM(168)中寻找存储器内容并将其移动到高速缓存中。在RAM中找不到所寻找的内容的情况下，即被称为“页面错误”(716)的失败，则MMU一直留意磁盘上的页帧(pageframe)(706)，将内容移动到RAM(168)中，然后移动到高速缓存(186)中。

使用连续的存储器的涉及对CRM的存储器管理的特殊挑战。在典型的实施例中，高速缓存访问花费10纳秒。RAM访问花费100纳秒。磁盘访问花费10,000,000纳秒。这些数字不是直观的，因为人们不能感受纳秒级的时间。因此，让我们以更熟悉的术语来看待该挑战。如果高速缓存访问被视为花费一分钟，则RAM访问花费10分钟，并且对相同数据的磁盘访问花费两年。分散在虚拟存储器地址上的三元组存在被存储在多个页帧中的风险。在连续存储器段中彼此靠近存储的三元组更可能存储在少量页帧中。

假设例如解析、推断或之前断言和存储的三元组的相关集合(三元组的子图谱)由10千字节的存储组成。现今，计算机系统支持兆字节或更大的存储器页面大小。这样的三元组集合(704)可以存储在单个存储器页面(710)中，并且一旦该页面位于RAM(168)中，CRM的三元组集合的操作可以在根本没有页面错误的风险的情况下进行。即使用于这种集合的连续存储落在页面边界上，整个三元组集合也可以被加载，并仅有两个页面错误，并且在将其加载到RAM中之后，其可以在前面存在零页面错误的情况下进行操作。将仍然需要高速缓存未命中来将内容加载到高速缓存中，但是除了第一个未命中或两个未命中之外，其它的未命中都不会有页面错误的风险。发明人估计在CRM的情况下，在短期操作之后，对于这种三元组集合的操作，高速缓存未命中率将小于百分之一。也就是说，当三元组集合被设置在支持根据本发明的实施例的CRM的连续存储器中时，对于超过99％的存储器访问，存储器访问时间通常将近似于高速缓存访问时间，仅几纳秒。

为了进一步说明，图9阐明了根据本发明的实施例的在胖客户端架构中的示例设备(即，用于CRM的语音使能装置)的功能框图。胖客户端架构是一种客户端-服务器架构，其中管理根据实施例的CRM所需的所有或大部分功能直接在客户端侧装置上而不是在服务器上得到支持。服务器用于备份和同步，而不用于会话管理、联系管理、语音识别、语义查询或推断。胖客户端需要可能在小型装置(诸如，智能手表或移动电话)上不总是可用的资源、处理器功率和存储器存储。然而，在具有足够数据处理资源的胖客户端中，所有相关的功能、通信会话、通信联系、解析、推断规则、推断、三元组存储、语音处理等通常立即且完全有用，而不管网络可用性如何。图9的示例中的胖客户端语音使能计算机(152)是自动计算机机器，其包括CPU(156)、RAM(168)、数据总线(162、164、166、160)、视频(180、209)、数据通信(167)、I/O(178)和磁盘存储(170)。

RAM中设置有CRM应用程序(195)，其呈现并且操作GUI控制面板(110)、由在计算机(152)上运行的CRM应用建立和管理的通信会话(140)和通信联系(144)、将被解析为三元组(752)的会话和联系结构和内容(509)、推断规则(376)、自然语言处理(“NLP”)引擎(155)、解析引擎(380)、推断引擎(298)和语义推理器(378)。RAM中还设置有三元组串行化器(294)、三元组转换器(292)和一个或多个三元组文件(290)。可选地，NLP引擎通过首先将结构和内容(509)处理为语句和词类并且随后将如此处理的内容提供至解析引擎来简化解析处理。解析引擎将结构和内容解析为解析的三元组(752)。推断引擎(298)将解析的三元组(752)和推断规则(376)作为输入，并推断出推断的三元组(754)。

串行化器(294)管理在RAM中的三元组存储(752、754)与磁盘存储或其他非易失性存储之间的三元组的传送。串行化器(294)接受三元组存储的内容作为输入，并将它们串行化以输出作为三元组文件(290)、表、关系数据库记录、电子表格、文本文档等，以便长期存储在非易失性存储器中，诸如，硬盘(170)上。串行化器(294)接受三元组文件(290)作为输入，并将解析的三元组输出到RAM中的三元组存储中。在许多实施例中，当串行化器(294)接受三元组文件(290)作为输入并且将解析的三元组输出到RAM中的三元组存储中时，串行化器将输出的三元组存储存储到存储器的连续段中。连续存储可以在C编程语言中通过调用malloc()函数来实现。连续存储可由Python缓冲器协议实现。可以以本领域技术人员所能想到的其他方式来实现连续存储，并且所有这些方式都在本发明的范围内。在许多实施例中，三元组存储(752、754)将被存储在连续存储器的段中。

语音引擎(153)是全服务NLP-SR引擎，其包括自然语言处理(155)、语音识别(150)、语法(104)、词典(106)、模型(108)和文本到语音处理(194)，所有这些都如以上关于图6更详细的描述。完全语音启用可直接在胖客户端计算机本身上使用。

图9所示的示例计算机系统通常操作以通过在远程代理和客户代表之间的第一通信联系时建立通信会话(140)作为计算机系统的计算机存储器(168)的结构来实现根据本发明的实施例的CRM。在建立会话时，计算机系统将作为自动计算机器的面向对象的模块的会话(140)建立作为计算机系统的计算机存储器的结构，自动计算机器的结构和内容(509)也作为语义三元组(752、754)被存储在企业知识图谱(154)中。也就是说，在该示例中，会话最初至少被建立为面向对象的会话类的实例。建立这种会话包括在计算机存储器中存储主体代码、时间戳、远程代理的标识、客户代表的标识以及可选地还有关于会话的其他信息作为会话的成员数据元素。

计算机系统(152)通常还通过跨通信平台的通信会话管理一系列通信联系(144)来运行，该一系列通信联系(144)包括远程代理和客户代表之间的第一联系以及随后的通信联系。计算机系统通过建立作为自动计算机器的面向对象的模块的每个联系来管理一系列联系，该自动计算机器构成计算机系统的计算机存储器(168)，并且其结构和内容(509)也作为语义三元组存储在企业知识图谱中。也就是说，在该示例中，联系(144)最初至少被建立为面向对象的联系类的实例。管理一系列联系包括在计算机存储器中记录开始联系的时间戳、联系的持续时间、联系的会话标识符、平台类型、联系状态、联系的任何通信内容以及可选地还有关于联系的其他信息作为每个联系的成员数据元素。

为了进一步说明，图10阐明了说明根据本发明实施例的CRM的示例方法的流程图。图10的方法中的功能通过客户端计算机(152)、声音服务器(151)和三元组服务器(157)的某种组合来实现或布置在其上。也就是说，例如，语音引擎可以设置在瘦客户端架构中的在声音服务器(151)上，或者设置在胖客户端架构中的客户端(152)上。并且解析和推断可以在三元组服务器(157)或客户端计算机(152)上执行。除了分别用解析引擎和推断引擎实现的解析(304)和推断(754)之外，该示例中的方法过程通常由CRM应用程序(195)实现。任何特定功能确切地出现在何处的问题取决于架构，但是所有结构元件都是计算机或计算机的组件，并且它们都被配置为在一个架构或另一个架构中一起操作以执行根据各实施例的CRM。

图10的方法包括在远程代理(128)和客户代表(129)之间的第一次通信联系时，由计算机系统建立(381)通信会话(140)作为计算机系统的计算机存储器的结构。在此，“第一”联系的概念是指在预期为多个联系之中的关于特定主体和特定客户(即，由客户代表表示的客户)的第一联系。在图10的示例中，建立(381)会话是通过将作为自动计算机器的面向对象的模块的会话建立作为计算机系统的计算机存储器的结构来执行的。也就是说，在该示例中，会话(140)是将面向对象的会话类实例化的对象。在该示例中，这样实例化的会话(140)包含成员数据元素，成员数据元素包括会话识别代码(393)、识别联系中心的代理和客户代表之间的联系的主体的主体代码(385)、以及识别在会话的联系中表示的客户(即，由客户代表在客户代表和代理之间的联系中表示的客户)的代码(387)。

CRM应用程序可通过搜索会话存储器以寻找客户的会话和新联系的主体来确定(215)新联系是否是会话的第一联系。发现不匹配(217)，应用建立(381)新会话(140)，在新会话和第一联系中记录新会话ID(393)，并将新会话和新联系移交到管理功能(382)。发现匹配(219)，应用将发现的会话ID记录在新联系中，并将发现的会话ID和新联系移交到管理功能(382)。会话ID用作将会话链接到与会话相关联的所有联系的外部密钥。因此，会话用作由会话ID链接的所有联系的包装器或容器。在该示例中，在联系(142)中记录的远程代理和客户代表(205、207)的标识码没有被记录在会话中。因此，示例会话(140)可以用作与客户相关并且具有特定主体的联系的包装器，以用于多个代理和多个客户代表之间的多个联系。

成员数据元素包括会话(140)何时被创建的时间戳(386)。会话还可以包括时间限制(221)，这里表示为生存时间或“TTL”，在生存时间之后会话终止，或者用户被通知超时并被提示是否终止会话。会话还可以包括状态代码(219)以指示会话是活动的还是终止的。未从会话存储器或知识存储中删除的终止会话可选地可以被配置为被重新激活。

在该示例中，会话成员数据元素还包括内容元素(389)。内容元素(389)的典型用途是详细描述会话的联系的主体(385)。在该示例中，联系中的通信内容(213)与联系本身(142、144)相关联地存储，而不是存储在会话对象中。在许多实施例中，在解析(304)为语义三元组之后，会话(140)的结构和内容(通常包括所有会话数据元素以及可选地还包括其他)作为语义三元组被存储在企业知识图谱(154)中。

图10的方法还包括由计算机系统通过跨通信平台的通信会话(140)来管理远程代理和客户代表之间的一系列(374)通信联系，包括第一联系(142)和还包括随后的通信联系(144)。在图10的方法中，通信平台包括电话(135)、文本消息传递平台(137)、电子邮件平台(131)和聊天机器人(133)。文本消息传递平台可以包括通过由联系中心暴露的网页的网络聊天、经由电话的短消息服务(SMS)消息、或者通常通过WhatsApp、FacebookMessenger、Snapchat等的基于网络的文本消息传递。计算机系统本身可以管理任何或所有这样的平台。计算机可以响应于用户调用电话的GUI小部件而打开电话联系。计算机可以接受键入的文本输入或语音消息到电子邮件或文本消息中。计算机可以管理聊天机器人，聊天机器人实现在计算机管理的通信中模拟人类行为的人工智能平台。

在图10的方法中，管理通信联系包括确定(383)每个通信联系(142、144)的通信平台类型(201)。通信联系可以通过计算机系统来实现，并且确定平台类型可以通过用户GUI操作来实现。也就是说，例如，可以通过调用针对平台、电话呼叫、文本消息等调用GUI小部件来明确地选择平台。用户可以选择联系拨号的目标或从联系列表中选择，CRM应用程序然后可以记录联系中的预期代表标识(207)，并从拨号或联系选择推断平台类型是电话。

通信联系可以在没有GUI操作(包括确定平台类型)的情况下仅通过语音来实现。远程代理可以发出口头指令：“计算机，给Bob发电子邮件并要求安排呼叫”、“计算机，给Bob发消息并要求他重新安排呼叫”、“计算机，为我给Bob打电话，并且如果他没有应答，留下消息请求回叫”。这些示例中的每一个明确地标识平台类型，分别为电子邮件、文本消息和电话。

在图10的方法中，跨平台管理(382)可以通过跨平台类型管理来执行。远程代理可以与客户代表一起实现一系列联系，该一系列联系中的每一个可以是相同的平台或相同的平台类型，都在电话上，或者该一系列联系中的每一个可以是不同的平台，电话、电子邮件、文本等。管理功能平等地处理所有平台类型，即使在同一远程代理与同一客户代表的一系列联系中。

在图10的方法中，跨平台管理联系可通过跨平台异步地管理联系来执行。也就是说，定时不是对根据各实施例的CRM的功能的限制。远程代理可以利用管理的呼叫、建立的联系、记录的内容、解析的元素、存储的三元组等在今天给同一客户代表打电话。远程代理可以利用管理的电子邮件、建立的联系、记录的内容、解析的元素、存储的三元组等在明天向同一客户代表发送电子邮件。远程代理可以利用管理的文本消息、建立的联系、记录的内容、解析的元素、存储的三元组等在下一天向同一客户代表发送文本。管理功能(382)跨平台异步工作。

在图10的方法中，跨平台管理(382)联系可以通过跨平台的物理位置管理联系来执行。也就是说，位置不是对根据各实施例的CRM的功能的限制。远程代理可以利用管理的呼叫、建立的联系、记录的内容、解析的元素、存储的三元组等在今天从高速公路上的汽车给同一客户代表打电话。远程代理可以利用管理的电子邮件、建立的联系、记录的内容、解析的元素、存储的三元组等在明天从呼叫中心中的代理办公桌向同一客户代表发送电子邮件。远程代理可以利用管理的文本消息、被建立的联系、记录的内容、解析的元素、存储的三元组等通过在代理的家庭办公室中使用代理的智能电话在下一天向同一客户代表发送文本。管理功能(382)进行工作，而不管平台的物理位置。

在图10的方法中，管理(382)一系列(374)联系包括建立作为自动计算机器的面向对象的模块的每个联系，该自动计算机器构成计算机系统的计算机存储器，并且其结构和内容也作为语义三元组被存储在企业知识图谱中。也就是说，在该示例中，联系是面向对象的联系类的实例。类的对象的结构由第一联系(142)的内容示出，但是所有这样的联系对象(374)的结构将是类似的。

在图10的示例中，管理(382)一系列(374)联系包括在计算机存储器中为每个联系记录针对该联系的会话标识符(393)、时间戳(203)、平台类型(201)、联系状态(211)以及该联系的任何通信内容(213)。会话标识符(393)将会话的每个联系与相关会话相关联。时间戳(203)记录发起联系的日期和时间。在该示例中，联系包括联系尝试失败。也就是说，在图10的方法中，通信联系(142、144)包括远程代理和客户代表之间的实际通信的实例以及在这种通信中的失败尝试。

状态代码(211)可以用于指示联系的成功或失败。声音使能可以响应于来自代理的状态查询而指示“你在上个星期三尝试联系他并且留下消息，但是我们没有进一步的联系”。在该示例中，联系结构包括发起该联系的代理(205)和被寻求联系的客户代表(207)的标识代码。因为代理ID和客户代表ID被记录在联系中而不是会话中，所以该示例会话结构(140)可以用作针对与客户相关并且具有特定主体的联系的包装器，用于多个代理和多个客户代表之间的多个联系。

就通信联系的内容(213)是语音而言，语音可选地是原始记录的，其中URL将其定位在存储的三元组中，或者语音被识别为文本，然后被存储为会话的联系的元素。对于副本，为了使讲话者识别自动化，根据实施例的示例计算机系统实现在具有当前声纹提取并与先前存储的已知讲话者的声纹进行比较的循环中运行的语音识别功能。对于在记录上没有声纹的新讲话者，根据实施例的计算机可以从上下文取得讲话者标识，例如给从地址列表中选择的特定客户代表打电话的远程代理。可替代地，对于在记录上没有声纹的新讲话者，根据实施例的计算机可以提示识别“对不起，我没有获得你的名字”。实现者可以想到将新讲话者与声纹相关联的其他方式，并且所有这些方式都在本发明的范围内。

在图10的方法中，在一些实施例中，管理(382)一系列(374)联系包括在请求会话(140)下的通信状态(219)时，通知(384)远程代理(128)。管理处理(382)可以在CRM应用的GUI的小部件中列出所有打开的会话、关闭的会话、每个会话的联系、每个联系的内容等。管理处理(382)可以接受声音请求并通过语音返回状态，例如，“计算机，我们与Bob的通信状态是什么？”，回答：“你没有与Bob开启会话”。或者，“你有一个开启会话，最后的联系是3月25日你发给他的电子邮件，没有响应。需要我为你读该电子邮件吗？”

在图10的方法中，管理(382)一系列(374)联系可以包括终止(379)会话。根据远程代理指令如此做，管理处理可以将会话状态(219)标记为“终止”或“非活动”等。管理处理可以根据超时终止会话，超时是会话的预定持续时间，其例如通过如下方式实现：将会话开始时的时间戳(386)与生存时间(221)元素以及当前日期和时间进行比较，可选地向远程代理通知超时，并询问是否终止。管理联系还可以包括通过例如将知识图谱中的相关状态三元组标记为“活动”而不是“非活动”来重新激活被终止的会话，或者甚至从知识图谱中检索相关三元组，并且基于它们，来重建面向对象的会话对象以及其所有联系对象。

图10的方法还包括由计算机系统的解析引擎(380)将通信会话(140)的结构和内容(509)(包括通信联系(142、144)的结构和内容(213))解析(304)为描述逻辑的解析的三元组(752)。在至少一些实施例中，描述逻辑是形式知识表示语言家族的成员，在形式知识表示语言家族中，逻辑的查询是可决定的。该结构和内容(509)包括来自在客户端计算机(152)上运行的CRM应用(195)的通信联系的词。CRM联系(142，144)被认为是按顺序(374)出现的，因为它们在时间上顺序地一个接一个地出现。每个CRM联系的特征在于平台类型(372、201)，即类型代码，诸如，例如，“电子邮件”、“聊天机器人”、“电话”、“文本消息”等。

解析处理(304)通过将来自结构和内容(509)的词形成为语义三元组(752)来运行。解析处理(304)可以通过将通过GUI小部件(368)指定为三元组的元素(主体、谓词、客体)的词形成为语义三元组(752)来运行。解析处理(304)可以通过将通过VoiceXML对话(522)中的声音命令指定为三元组的元素(主体、谓词、客体)词形成为语义三元组(752)来运行。解析处理(304)可以通过将自然语言处理引擎(155)指定为词类、主体、谓词、客体的词形成为语义三元组(752)来运行。解析处理将解析的三元组(752)移交到推断引擎(298)和存储功能(322)以用于进一步处理。在许多实施例中，解析处理通过将解析的三元组布置在连续存储器段中并且向推断引擎(298)和存储功能(322)提供针对段的存储器地址，来将解析的三元组(752)移交到推断引擎(298)和存储功能(322)。

图10的方法还包括由推断引擎(298)根据计算机系统的企业知识图谱(154)的推断规则(376)从解析的三元组中推断(307)推断的三元组(754)。针对从会话和联系中解析的三元组的较小集合运行推断的一个效果是减少针对整个企业知识图谱运行推断规则的负担。在由会话和联系表示的较小的数据块中推断三元组是比针对整个企业知识图谱运行推断规则小得多的数据处理任务，并且在由会话和联系表示的较小的数据块中推断三元组生成与通过针对整个企业知识图谱运行推断规则推断的三元组相同的推断三元组。

图10的方法还包括将解析的三元组(752)和推断的三元组(754)存储(322)在企业知识图谱(154)中。在一些实施例中，企业知识图谱由描述逻辑的三元组组成，该描述逻辑包括通过CRM系统对远程代理可用的所有CRM相关知识。在一些实施例中，在整个企业知识图谱内的会话和通信联系的结构和内容的至少一些子图谱被布置在连续计算机存储器的段内。

为了进一步说明，图11阐明了示例企业知识图谱(154)，其中类型编码的子图谱被实现为整个知识图谱的逻辑连接的段。图11的示例图谱(154)中的所有节点和边是语义三元组的元素。示例图谱(154)不仅包括会话(140)的示例，还包括类型编码为客户信息(238)和客户代表信息(136)的子图谱，会话(140)的结构、内容和联系已经被解析为三元组并存储在企业知识图谱(154)中。这三个子图谱仅仅是示例，而不是企业知识图谱的限制。企业知识图谱通常还将包括财务、供应商信息、商业实体和结构、项目信息、公司指南和手册、雇员数据、公司数据、交易、合同、销售历史、研究细节等。

图谱(154)的根是名为企业知识(199)的类对象。节点客户数据(200)和客户代表数据(226)是企业知识的子类，而会话节点(140)是被解析和存储的特定会话的示例实例。会话的联系对象(142、144)均通过会话ID对象(393)被链接到会话(140)。图11的示例还示出了解析过程可以并且将经常导致被解析或推断为语义三元组的每个项的多个三元组的事实。例如，在该示例中，会话(140)是七个三元组的主体：会话识别代码(393)、主体代码(385)、时间戳(386)、客户识别代码(387)、内容字段(389)、状态代码(219)和生存时间代码(221)。并且对于另一示例，联系节点(142)也是七个三元组的主体：将联系(142)链接到会话(140)的会话识别代码(393)，以及联系的平台类型(201)的标识、时间戳(203)、识别进行联系的远程代理的代码(205)、识别进行联系的客户代表的代码(207)、状态代码(211)和联系的内容(213)。

针对类似图谱(154)的图谱中的三元组存储的查询(诸如，例如，由语义推理器使用以提取在当前联系中使用的先前内容的查询)可以包括指定子图谱的子句：

Query：

SELECT ？subject

WHERE {？subject：is ：Contact.

？subjcct：ID ：Session ID(393).}

Response：：Contact(142)

(查询：

选择 ？主体

其中 {？主体 ：是： 联系。

？主体 ：ID： 会话ID(393)。}

响应： ：联系(142))

为了进一步解释，图12阐明了三元组存储的示例集合，其中客户数据(238)、客户代表数据(136)、会话(140)分别被实现为单独的图谱(238、240、242)。读者将理解，企业知识库将包括多于这三种信息。除了用于这种知识库的管理处理可以变化之外，三个独立的图谱以及附加的这种图谱仍然可以实现整个企业知识库的元素，因为知识库的语义数据中的至少一些被容纳在单独的图谱中。例如，查询可以被不同地结构化。针对类似于图谱(242)的图谱中的呼叫记录三元组存储的查询可能不需要指定任何特定子图谱的子句：

Query：

SELECT ？subject

WHERE {？subject：ID ：Session ID(140).}

Response：：Contact(142)

(查询：

选择 ？主体

其中 {？主体 ：ID： 会话ID(140)。}

响应： ：联系(142)

为了进一步说明，图13阐明了根据本发明实施例的CRM的另一示例方法的流程图。图13的方法类似于图10的示例方法，包括图10，在远程代理(128)与客户代表(129)之间的第一通信联系(142)时，由计算机系统(151、152、157)建立通信会话(140)作为计算机系统的计算机存储器的结构。在该示例实施例中，会话(140)是计算机存储器的结构，因为会话可以被实现为面向对象的会话类的实例。还与图10的方法类似，图13的方法还包括由计算机系统通过跨通信平台的通信会话(140)来管理(382)一系列通信联系，其包括远程代理与客户代表之间的第一联系(142)以及还有随后的通信联系(144)。还与图10的方法类似，图13的方法包括将通信会话(140)的结构和内容(509)(包括通信联系(142，144)的结构和内容)解析(304)为语义三元组，从解析的三元组推断出(307)推断的三元组，以及将解析的三元组和推断的三元组存储(322)在企业知识图谱(154)中。

除了与图10的方法的相似处之外，图13的方法包括获取用于包括在语义三元组中的内容的三种替代方式。在该示例中的内容主要由说出至或键入至计算机系统中的词组成。因此获取包括在三元组中的内容的方法通常旨在获取数字化的词以在CRM中进行数据处理。在提供用于解析的数字化的词的第一可替代方式中，在图13的方法中，解析(304)可通过解析数字化的语音的词(509)来执行，该数字化的语音由自然语言处理语音识别(“NLP-SR”)引擎(153)从远程代理(128)和客户代表(129)之间的对话(313)中识别。也就是说，图13的方法包括通过自然语言处理语音识别(“NLP-SR”)引擎将来自这样的会话的词(509)识别(228)为数字化语音(508)。在该示例方法中，通过语音使能装置(152)上的麦克风和放大器以及到声音服务器(151)的VOIP连接(216)引导来自会话(313)的语音的词，来执行从这样的会话识别语音，在声音服务器(151)，语音识别引擎(150)将词识别为数字化的语音流，该数字化的语音流被传递到自然语言处理引擎(155)，该自然语言处理引擎(155)将数字化的语音处理为语句和词类，并将如此处理(509)的词传递到解析处理(304)，在解析处理(304)中，词被解析为三元组(752)。管理处理(382)将数字化的词(509)作为要解析的结构和内容(509)的元素传递到解析处理。这是向解析处理(304)提供数字化的词(509)的第一可替代方式。

在向解析处理提供数字化的词的第二可替代方式中，图13的方法还包括在自然语言处理引擎中从CRM控制面板(110)的文本框小部件(366)接收(307)呼叫记录的词(220)。除了提供口述内容之外或者作为提供口述内容的可替代方式，远程代理将呼叫记录键入GUI文本框(366)中，并且如此键入的所有文本由控制面板(110)直接提供给自然语言处理引擎(155)作为数字化的词(220)。对于自然语言处理引擎来说，键入的词(220)和数字化的语音流中的词(508)之间没有差别。因此，除了不需要语音识别(150)，该第二可替代方式类似于第一可替代方式，因为当数字化的文本流到达NLP-SR引擎(153)中时，已经通过在GUI小部件文本框(366)中进行键入将该流中的词数字化。自然语言处理引擎(155)以与第一可替代方式相同的方式工作，将来自文本框(366)的数字化的文本处理成语句和词类，并通过管理处理(382)将如此处理(509)的词传递到解析处理(304)，在解析处理(304)，词被解析为语义三元组。这是向解析处理(304)提供数字化的词(509)的第二可提点方式。

在向解析处理提供数字化的词的第三可替代方式中，图13的方法还包括通过CRM控制面板(110)的小部件(360、362、364)接收(303)指定为解析的三元组的元素的词(222)。小部件是三元组的主体(360)、三元组的谓词(362)和三元组的客体(364)的下拉菜单列表。在至少该示例实施例中的谓词(362)和客体(364)是已经在支持企业知识图谱(154)的本体中定义的三元组。主体(360)是包括在三元组中的词候选项的流。例如，主体下拉菜单(360)中的词是由NLP-SR引擎(153)从呼叫记录文本(366)或从根据对话(313)识别的词提供。远程代理(128)通过从主体下拉菜单(360)中选择词(例如，通过键盘或鼠标选择)来将词(222)传递到解析处理(304)。远程代理还可以可选地选择谓词(362)或客体(364)以包括在与所选的主体相同的三元组中。在一些实施例中，远程代理对谓词和客体的选择可以在解析处理(304)时绑定。在其他实施例中，远程代理的选择仅被解析处理视为推荐。解析处理可选地接受远程代理对谓词和客体的选择，或者解析处理进行自己对谓词和三元组的选择，以便与词一起包括在至少一个解析的三元组中(222)。这是向解析处理(304)提供数字化的词(509)的第三可替代方式。

为了进一步说明，图14阐明了说明根据本发明实施例的CRM的另一示例方法的流程图。图14的方法类似于图10的示例方法，包括如图10的建立(381)通信会话(140)，跨通信平台管理(382)一系列通信联系，将通信会话的结构和内容解析(304)为语义三元组，通信会话的结构和内容包括通信联系的结构和内容(142、144)，从解析的三元组推断出(307)推断的三元组，以及将解析的三元组和推断的三元组存储(322)在企业知识图谱(154)中。除了与图10的方法的那些相似性之外，图14的方法包括由计算机系统的语义查询和推理引擎(298)针对企业知识图谱(154)执行(338)针对记录在知识图谱中的语义数据的语义查询(341)。图14的方法还包括显示(348、350)语义查询(341)的结果(342)。如此寻找的数据位于先前解析(304)或推断(307)并存储(322)在企业知识图谱(154)中的一个或多个语义三元组或语义子图谱中。

图14的方法与图10的方法的不同之处在于包括查询的执行，不仅确定三元组是否位于三元组存储中，而且包括检索三元组存储(154)的内容的查询(341)的类型。图14的方法包括由查询引擎(298)针对企业知识图谱(154)执行(338)针对来自企业知识图谱(154)中记录的三元组的信息的语义查询(341)。例如，通过GUI的元素(诸如控制面板(110))在查询和推断引擎中接收(344)语义查询，或者对于另一示例，通过声音使能用户接口(诸如麦克风(176)和VoiceXML对话框(522)在查询和推断引擎中接收(344)语义查询。查询和推理引擎(298)检索(343)语义查询(342)的结果(342)并通过GUI(110)或通过语音使能的用户界面(522，177)显示(348、350)语义查询(342)的结果(342)。

查询(341)不仅仅询问数据是否在存储中，查询(341)还要求返回数据本身。因此，再次参考关于鲍勃和蒙娜丽莎的图谱，作为用于解释的另一示例，从鲍勃是主体的所有三元组中请求谓词和客体的查询如下：

SELECT ？predicate ？object

WHERE {：Bob：？predicate ：？subject.}

(选择 ？谓词？客体

其中 {：鲍勃 ：？谓词 ：？主体})

返回如下：

：isA ：person

：isAFriendOf ：Alice

：isBornOn ：“the 4

isInterestedIn ：“the Mona Lisa”)

(：是 ：人

：朋友是 ：爱丽丝

：出生于 ：“1990年7月4日”

：喜欢 ：“蒙娜丽莎”)

该查询：

SELECT ？predicate？object

WHERE {：“the Mona Lisa”：？predicate：？subiect.}

(选择 ？谓词？客体

其中 {：“蒙娜丽莎” ：？谓词 ？主体})

返回如下：

：wasCreatedBy ：“Leonardo da Vinci”

(创作者为 “莱昂纳多达芬奇”)

以及该查询：

SELECT ？subject？predicate？object

WHERE {：？subject：？predicate：？“the Mona Lisa”.}

(选择 ？主体？谓词？客体

其中 {：？主体 ：？谓词 ：？“蒙娜丽莎”})

返回如下：

：“the video‘La Joconde à Washington”’：isAbout：“the Mona Lisa”

(：“视频蒙娜丽莎在华盛顿”：讲述的是：“蒙娜丽莎”)

从前面的描述中可以理解，在不背离本发明的真实精神的情况下，可以对本发明的各种实施例进行修改和改变。本说明书中的描述仅用于说明的目的，而不应被解释为限制性的。本发明的范围仅由所附权利要求的语言来限定。