CN101080734A - 使用推理逻辑的协同处理 - Google Patents

Abstract

本发明涉及使用推理逻辑的协同处理。协同引擎通过使用推理逻辑电子处理对于结果的请求。如果提供不充分的目标以解析请求，那么根据一个或更多个未解析的目标产生部分结果。可以通过使用工作区链用两个或更多个协同引擎处理对于结果的请求，以处理来自/送往具有防止其间的信息的完全流通的安全限制的多个域或系统。一个协同引擎的工作区可用的输入尽可能地被解析，并且，基于该处理的部分结果产生并被传送，用于在另一协同引擎的工作区中进一步处理。本发明可用于确定送往/来自通信网络的用户的数据或电话通信的路由选择通路，或用于处理电子数据网络的部件的管理动作或商业交易。

Description

使用推理逻辑的协同处理

技术领域

本发明涉及使用推理逻辑(inference logic)电子处理对于结果的请求的方法和设备。在特定的实施例中，它针对使用基于计算机的推理逻辑协同处理来自多方的输入的方法和设备，其中，各方的专用输入不公开给其它方。

背景技术

在本说明书的结尾提供这里使用的一些术语的术语表。提供在术语表中包含的例子和解释是为了澄清或解释的目的，不是为了限制。

由于推理规则的宣示性的本性意味着它们可很容易地限定商业规则，并且推理规则可被迅速修改以反映变化的商业要求，因此，商业正越来越多地使用推理逻辑以使处理自动化。简单而言，推理是通过在工作区(workspace)中应用推理规则从已知的事实得出新的事实的过程。在本上下文中，‘事实’表示实体的已知值(例如，“CUSTOMER＝Company-A”，这里，‘Company-A’可以是简单值或复杂结构的当前状态)，而‘规则’表示事实之间的关系，并且一般采用“如果A，那么B”的形式(例如，“如果CUSTOMER＝Company-A，那么DISCOUNT＝10％”)。

更一般地，推理逻辑通过解析(resolve)一般是事实和规则但也可包含工作区中的其它构造(例如，约束)的推理目标得出结果。“工作区”是存储器中对于给定计算解析推理目标的区域。推理逻辑确定目标以根据已解析的初始输入和目标解析下一个，并在该结果所需要的所有目标都已被解析时产生结果。这意味着，如果一个或更多个所需要的目标不能被解析，那么不产生结果。推理逻辑从一般包含一个或更多个数据仓库(data store)的知识库检索目标，但是其它的实现是可能的。推理逻辑可作为常被称为推理引擎(inference engine)的专用逻辑被实现，或者可以作为诸如应用程序的更大的逻辑块的一部分被包含。Adrian A.Hopgood在Intelligent Systems for Engineers andScientists(CRC出版社，2000年，第2版)提供了推理逻辑的介绍和基于知识的系统(以及其它智能系统)的实际应用。

诸如因特网的通信网络越来越多地被各合作方(cooperatingparty)使用，用于信息的交换和用于协同任务(undertaking)和处理。使这些协同处理自动化常常需要计算任务基于多于一方的输入的合作计算。

常规的命令式编程可被用于实现自动化的协同处理。命令式编程描述程序状态方面的计算和改变程序状态的语句。命令式程序(例如，以诸如COBOL、C、C++、Java等的语言写成的程序)是计算机执行的一系列命令。方法(recipe)是常见的类推法；各个步骤是指令并且实体世界保持该状态。使用命令式编程，控制计算的逻辑被嵌入各单个系统的代码中。

这些系统的主要缺点由于程序逻辑包含许多或全部商业规则而产生。这意味着，每当商业规则改变到它们在如何处理方面需要改变的程度时，程序逻辑必须被重新评价、被修改和被重新测试。由于改变系统以匹配新的商业规则会根据系统代码以及实现改变的难度花费几个月或者甚至几年，因此使系统与商业规则保持一致需要一些先见之明。

由于命令式编程基于状态，因此输入和输出依据一般以参数(名称，值对(value pair))表示的值。使用命令式编程实现定制的自动化的协同处理方案要求系统之间的通信依据参数。参数在被定义时必须使得它们在不同的系统中具有相同的意思，并且它们必须在系统之间被传送并在系统之间被映射。

由于各个系统在与其连接的其它系统如何工作方面具有非常精确的期望值，因此这些系统被“紧密耦合”。这意味着，希望使协同处理自动化的各方必须一般在它们的系统的设计、购买和实现中合作以保证它们是相容的。当一方希望与大量的其它方协作时，它必须规定、购买和安装大量的不同系统，或者在单一标准系统上与其它方达成一致。这些紧密耦合的系统还对变化十分敏感。常常是，如果一方更新其系统，那么被更新的系统将不再与其它系统中的一些或全部相容。对大量各方组织同时的更新会是极其困难的，或者甚至是不可能的。实际上，这些方案只对于少量的合作方是可行的，并且通常仅由与它们的几个长期伙伴连接的较大的组织使用。

一种简化通信过程的方式是使用用于描述交易的标准化的格式，例如电子数据交换(EDI)。EDI为贸易伙伴之间的商业对商业交易提供通信方案。该标准指定在诸如采购定单、货运单据和发票的商业文件和帐票的交换中使用的格式、字符集和数据元素。该标准规定对特定文件哪些信息是强制的以及哪些是任选的，并对文件的结构给出规则。贸易伙伴仍然必须对要被传送的特定信息以及应如何对其使用达成一致，并且这需要伙伴之间的详细的程序和技术协议。典型的EDI布署需要6～18个月以共同设计、同意和实现将只在两个公司之间使用的交易定义。虽然EDI帮助伙伴以标准化、自动化的方式通信，但交易以非常刚性的条件被限定，并且计算化的谈判不被支持。

推理逻辑是用于实现自动化的协同处理的命令式编程时的显然的替代方案。使用推理逻辑具有商业规则不被嵌入程序逻辑中的优点。与改变用命令式编程实现的系统相比，可更容易、更迅速和更可靠地被结合新的商业规则。

另外，推理规则固有地非常灵活，因此它们很好地适于描述商业交易。仍需要对用于描述交易的基本项(fundamental term)达成一致，但各方可使用规则以限定这些议定项如何与该方有关。另外，由于规则表达关系，不是如命令式编程中那样只表达各值，因此它们可表达可谈判项，并且计算化的谈判是可能的。

存在用于使用推理逻辑进行协同处理的提议。在电子商务的背景中，例如，电子市场(拍卖)被视为可通过使用推理逻辑被自动化的应用。例如，Benjamin N.Grosof，Daniel Reeves和Michael P.Wellman在Proceedings of the Fifth International Conference on AutomatedAgents，2001中的题目为“Automated Negotiation and DeclarativeContract Descriptions”的文章中略述了用于通过使用推理引擎使经济合同自动化和商议这些经济合同并将合同描述成商业规则组的方法。但是，由于如果失去所需的目标则已知的推理处理技术不能实现(resolve)结果，因此这些提议需要在事实上意味着一个推理引擎的一个工作区中执行协同处理。因此，要通过使用已知的推理逻辑执行协同处理，一方必须检索和/或被发送来自所有协作方的输入。如果任何一方都不能足够确信知道所有的输入，或者对被公开的专用输入存在法律障碍，那么协同处理不能被完成，并且这些提议是不实际的。

密码理论提出安全的分布式协议，以在不公开它们的值的情况下共享用于处理的专用输入。这些协议依赖于可证实的秘密共享以提供仿效的被信任的第三方。由于表示加密的秘密所需要的相对大量的数据和预计的两个通信圆(communication round)的最小值，因此一般存在相当数量的与安全协议有关的网络开销。另外，复杂的加密计算导致较高的计算开销。

在向商业应用添加功能的背景中，普通的经验法则是，新功能的开销大于50％表示实现的可行性应被怀疑，并且100％的开销意味着实现是不可接受的。安全协议显著增加计算开销，其增加量一般大于六个数量级(100,000,000％)。例如，Ioannis Ioannidis和AnanthGrama在Proceedings of the 36^th Hawaii International Conference onSystem Sciences，2003中的题目为“An Efficient Protocol for Yao’sMillionaires’Problem”的文章中，给出用于比较两个数的有效协议并报告了用于通过使用Pentium III/450Mhz计算机比较两个20位数的290毫秒的计算开销。即使考虑100个CPU周期用于在没有安全协议的情况下比较两个(32位)数，这也是每秒约3.5比每秒4,500,000的比例，该比例表示超过一百万比一的开销。

安全协议因此对于许多要求在短时帧中或者在更极端的情况下以接近实时的方式实施多个多方计算的商业应用是不实际的。当在地理分散的主机之间实施处理时，该问题得到解决。安全协议一般试图提供“理想的”安全级，这等于由受信任的第三方执行计算的情况。在真实世界中，如果理想的安全性对于实际使用不是足够有效的，那么可优选提供可接受的安全级的方案。牺牲一些安全性或公开一些关于专用数据的有限信息在实际中常常是可接受的。

本发明的目的在于，提供用于通过使用推理逻辑协同处理多方的输入的实际方法和系统，其中，对于一方不需要知道所有的输入并且各方的专用输入不向其它方公开。

发明内容

在一种宽泛的形式中，本发明提供一种用使用推理逻辑的协同引擎(collaborative engine)电子处理对结果的请求的方法，其中，该方法包括根据一个或更多个未解析的(unresolvable)目标产生部分结果的步骤。

一般地，提供不充分的目标以解析请求，并且产生部分结果。

部分结果一般包含至少一个能够部分解析被请求的结果的目标。

该方法可包括识别能够部分解析对于结果的请求的未解析的目标的步骤，并且，部分结果根据识别的未解析的目标产生。

该方法可包括检索至少一个可检索的目标的步骤。每个可检索的目标是可通过对于目标的请求被协同引擎检索的目标。每个个目标可包含可被推理逻辑使用以解析对于结果的请求的事实、规则或其它结构。对于结果的请求根据目标被处理。如果提供不充分的目标，那么产生被请求的结果。

一般地，推理逻辑包含基于规则的逻辑。

在本说明书中，术语“推理引擎”意图在于意味着寻求从数据库或其它知识库导出希望的信息的过程或执行过程的设备。一般地，设备是计算装置或计算系统，并且过程由软件驱动。‘协同引擎’是适于处理来自或送往一般具有防止其间的信息的完全流通的一些安全限制的多个域或系统的信息的推理引擎。

根据一个或更多个未解析的目标产生部分结果的步骤可包括：产生一组未解析的目标和未解析的目标依赖的任何目标，以及将该组包含于部分结果中。该组未解析的目标的子集可进一步被产生并被包含于部分结果中。

产生部分结果的步骤还可包含屏蔽部分结果中的至少一个目标。这可包含：改变目标或涉及该目标的一个或更多个目标；和/或用仅对执行屏蔽的协同引擎已知的产生的目标或值或在与该引擎相同的安全域中的处理代替该目标或该目标中的值。

协同引擎可包含发送协同引擎、接收协同引擎或收发协同引擎。

在发送协同引擎的情况下，该方法还可包括以下步骤：(i)包含具有对于结果的另一请求的部分结果并将另一请求传送给至少一个另外的协同引擎或逻辑的执行段；或(ii)存储部分结果。在传送另一请求前，可以从一个或更多个可检索的目标产生动态验证标志，用于包含该另一请求。产生的动态验证标志应以前没有作为动态验证标志被传送给其它协同引擎。

在接收协同引擎的情况下，如果对于结果的请求包含至少一个能够部分解析请求的结果的目标并且该目标不是可检索的目标，那么对于结果的请求根据可检索的目标和包含于对于结果的请求中的至少一个目标处理对于结果的请求。请求可包括用于确认的动态验证标志。如果动态验证标志被确认，则对于请求的处理可前进。否则，如果确认失败，则终止处理。

在收发协同引擎的情况下，如果对于结果的请求包含至少一个能够部分解析请求的结果的目标，则根据可检索的目标和包含于对于结果的请求中的至少一个目标处理请求。否则，根据可检索的目标处理请求。

在本发明的一个实施例中，用两个或更多个协同引擎处理对于结果的请求。如果在可检索的目标内提供不充分的目标，并且，如果包含于对于结果的请求中的至少一个目标是可应用的以使得协同引擎能够解析被请求的结果，那么产生部分结果。该部分结果被包含于被传送给至少一个另外的协同引擎的对于结果的另一请求内。

本发明因此使得能够通过使用推理逻辑多方处理一般的计算。通过使用“工作区链”，一个协同引擎的工作区可用的输入尽可能地被解析，并且，基于该处理的部分结果产生并被传送，用于在另一协同引擎的工作区中进一步处理。对于可参于该链的工作区的数量没有理论上的限制。另外，协同引擎可将响应从启动的协同引擎接收的部分结果产生的新的部分结果传送回启动的协同引擎。这样，延长的商议可被有效支持。

由于部分结果一般只包含在特定计算中包含的一组目标的子集，并且包含于特定计算中的一组目标一般大大小于能够解析计算的一组目标，因此引擎之间的各数据传送的大小保持较小。另外，即使当里面的值被屏蔽时，也常常是在两个协同引擎之间只需要单一的传送。这是对现有技术的显著改进。已知的推理技术必须传送可包含于计算中的所有目标，或者在单独的传送中传送各个目标。安全协议必须传送加密形式的附加数据并使用两个或更多个传送。

与计算最终结果相比，导出部分结果的计算开销较少。这是因为将未解析的目标添加到列表中然后遍历(traverse)该列表的开销比识别、检索和解析这些目标的开销低。类似地，在屏蔽部分结果中包含的处理比用于完成几乎大多数琐碎的推理计算的处理少。因此，屏蔽部分结果的开销一般明显小于实际计算的处理。在最坏的情况下它也在其数量级内。这是对屏蔽的开销通常比处理计算大几个数量级的安全协议的实质性改进。

本发明的另一益处在于，部分结果可被保存到例如磁盘或磁带的永久存储器中，然后，在另一输入可用时被执行。这允许推理处理暂停以等待要被发现的事实，或重复使用一个部分结果以产生两个或更多个随后的被请求的结果。

本发明的另一益处在于，需要大量资源的计算可在多个协同设备之间被分开。本发明提供用于通过产生部分结果并将它们转送给其它协同设备以继续处理分开推理处理的一般机制。很容易理解，这种分开的布局可任意地复杂，使得接收另一处理的部分结果的任何协同设备可进一步将该处理的多个部分委托给一个或更多其它协同设备。

在一些实施例中，根据可检索的目标和包含于对于结果的请求中的至少一个目标处理对于结果的请求可包含在可检索的目标和包含于对于结果的请求中的目标之间进行区分，并可包含在处理中使用这种区分。

部分结果的产生可作为对于结果的请求的一部分或通过由推理逻辑推理被规定或禁止。如果部分结果被禁止，并且不是所有的被识别为能够部分解析结果的目标被解析，那么会产生错误。

本发明的方法可被应用于许多实际应用中。例如，对于结果的请求可以是以下请求：

(i)送往或来自通信网络的用户的对于电子通信用路由选择通路的请求(并且该方法可包括检索作为与为该用户处理电子通信有关的事实或规则的至少一个可检索目标的步骤)；

(ii)对于电话连接用路由选择通路的请求(并且该方法可包括检索作为与为该用户确定电话连接用路由选择通路有关的事实或规则的至少一个目标的步骤)；

(iii)来自或送往网络的用户的对于通信消息用路由选择通路的请求(并且该方法可包括检索作为与为该用户确定通信消息用路由选择通路有关的事实或规则的至少一个目标的步骤)；

(iv)对于电子数据网络的部件的管理动作的请求(并且该方法可包括检索作为与管理该部件有关的事实或规则的至少一个可检索目标的步骤)；

(v)对于商业交易的请求(并且该方法可包括检索作为与处理商业交易有关的事实或规则的至少一个可检索目标的步骤)；或者

(vi)对于执行办公自动化、工作流程、日程表或文件管理处理的请求(并且该方法可视情况而定包括检索作为与办公自动化、工作流程、日程表或文件管理处理有关的事实或规则的至少一个可检索目标的步骤)。

在另一方面中，本发明提供用使用推理逻辑的协同引擎电子处理对结果的请求的方法，其中，该方法包括根据一个或更多个可检索的目标处理部分结果的步骤。

在另一宽泛的形式中，本发明提供一种通过使用推理逻辑电子处理对于结果的请求的协同引擎，其中，协同引擎包含用于根据一个或更多个未解析的目标产生部分结果的装置。协同引擎适于在没有足够的目标可用于解析请求的情况下产生部分结果。

在另一形式中，本发明提供一种通过使用推理逻辑电子处理对于结果的请求的协同引擎，其中，对于结果的请求包含部分结果，其中，协同引擎包含用于处理部分结果的装置。

本发明的设备可被应用于许多实际应用中。例如，

(i)协同引擎可与至少一个通信网络连接并适于处理送往或来自通信网络的用户的对于电子通信用路由选择通路的请求(在这种情况下，协同引擎可检索作为与为该用户处理电子通信有关的事实或规则的至少一个可检索目标)；

(ii)协同引擎可与至少一个电子数据网络连接并适于处理用于确定关于该网络的至少一个部件的管理动作的请求(在这种情况下，协同引擎可检索作为与网络的该部件的管理有关的事实或规则的至少一个可检索目标)；

(iii)协同引擎可与至少一个电子数据网络连接并适于处理用于为与该网络连接的用户确定商业交易的请求(在这种情况下，协同引擎可检索作为与为该用户处理商业交易有关的事实或规则的至少一个可检索目标)；或者

(iv)协同引擎可与至少一个电子数据网络连接并适于为与该网络连接的用户处理用于执行办公自动化、工作流程、日程表或文件管理处理的请求(在这种情况下，协同引擎可视情况而定为该用户检索作为与办公自动化、工作流程、日程表或文件管理处理有关的事实或规则的至少一个可检索目标)。

为了帮助理解和实现本发明，现在参照附图通过例子说明其实施例，在这些附图中，类似的附图标记表示类似的元件。

附图说明

图1a～1c示出现有技术中的推理逻辑。

图2a～2c示出本发明的推理逻辑的基本例子。

图3是包含根据本发明执行多方处理的两个互连协同设备的分布式数据处理系统的框图。

图4是示出在图3的各协同设备中执行的推理逻辑的流程图。

图5、图6和图7是用于描述图4的逻辑的规则和事实的例子。

图8解释其中多个协同设备根据本发明执行多方处理的分布式数据处理系统。

具体实施方式

理解现有技术中的推理逻辑有利于理解本发明。已知的推理逻辑的基本原理是识别和处理确定希望的结果所需要的目标。在本文中，目标可限定一些信息的值，或者可以限定如何可从一个或更多个目标解析一个或更多个其它目标。限定某值的目标常被称为“事实”并可限定简单的值(例如‘10’)或复杂的状态(例如客户记录或对象(object)的状态)。限定如何解析其它目标的目标常被称为‘规则’并且可以：限定事实之间的关系(例如，“如果CUSTOMER ＝Customer-A，那么DISCOUNT＝10％”)；约束事实(例如，“10％＜DISCOUNT＜15％”)；或限定事实和规则的组合之间的关系(例如，“如果CUSTOMER＝Customer-A，那么10％＜＝DISCOUNT＜＝15％”)。推理逻辑的实现改变，并且目标的准确性质由实现确定。类似地，对于结果的请求的性质随推理逻辑的实现改变。例如，根据实现，对于结果的请求可包含要求一个或更多个值、断言(assert)一个或更多个新值、它们的组合或其它的形式。

推理逻辑识别确定结果所需要的目标，然后识别和检索解析已得到识别的目标所需要的其它目标。从一个目标移动到下一个目标的过程可被称为链(chaining)，并且存在两种本领域中公知的主要链形式：正向链(Forward chaining，也称“演绎法”)和反向链(Backwardchaining，也称“归纳法”)。在正向链中，解析第一目标会影响一个或更多个二次目标，从而导致它们也被解析。在反向链中，解析第一目标被延迟直到一个或更多个二次目标得到解析，使得二次目标的结果对于解析第一目标是可用的。

虽然推理过程能够例如通过外部命令早早被终止，但该过程一般继续，直到希望的结果被解析或没有其它目标可被识别。如果推理过程由于没有其它目标可被发现在结果被确定之前停止，那么不产生结果。这表明没有足够的目标可被用于确定结果并且常被推理逻辑表示为错误。

在推理的过程中，逻辑会识别它发现由于不能被检索或由于依赖于不能被解析的二次目标而不能被解析的目标。推理逻辑将所有这些目标标记为无法解析，这保证逻辑将不再准备解析这些目标。如果无法解析目标没有这样被标记，那么推理逻辑会试图重新解析它们，并会因此永久循环下去。由于已知的推理逻辑不能使用这些未解析的目标确定结果，因此未解析的目标被舍弃。

因此，已知的推理逻辑的两种特性是，未解析的目标被识别和舍弃，以及，当没有新的未被解析的目标可被识别时，处理可能在不产生结果的情况下停止。

在图1a～1c中示出现有推理逻辑的简单例子。在这些图示中，参照这里列于下表1中的统称为目标的示例性规则和事实。

         表1

目标	内容
		规则R1	如果A和B，那么C
规则R2	如果C和D，那么E
		事实1	A
事实2	B
		事实3	D

参照表1，示例性规则R1和R2具有类似的形式(如果X和Y，那么Z)，但是很容易理解，规则可采取推理逻辑可理解的任何形式。

参照图1a，通过使用反向链在推理工作区W1中从事实A、B和D解析结果E。如果结果E被请求，那么逻辑推断规则R2可解析该请求。逻辑进一步推断，规则R1可解析由规则R2需要的事实C，因此，通过解析规则R2和R1，结果E被解析。

参照图1b，通过使用正向链在推理工作区W1中从事实A、B和D解析结果E。如果对比如说事实A断言新值，那么逻辑推断规则R1受事实A影响，并解析该规则(还需要事实B)。解析规则R1对事实C断言新值，这导致逻辑处理规则R2，(还需要事实D)，这样，通过解析规则R1和R2，结果E被解析。

图1a和图1b中的逻辑图之间的主要差别在于箭头的方向，该方向表示推理的方向。在反向链中推理远离结果链，而在正向链中它们向结果链。应用于推理逻辑的一般方法可被应用于正向和反向链以及两者的组合。

现在参照图1c，由于事实D不能被解析，因此结果E不能被解析。在本例子中，由于不存在可产生D的规则目标，并且没有用于D的值可在工作区W1中被检索，因此事实D不能被解析。考虑图1a和图1b中的逻辑，如果用于事实D的值不能在与规则R2相同的工作区中被解析，那么规则R2不能被解析，因此，只有用于事实D的值可在工作区W1中被检索，已知的推理逻辑才能解析结果E。存在用于在工作区W1中定位和检索用于事实D的值的方法，但是，这些方法不针对事实D例如由于代表另一工作区专用的数据不能被检索的情况。

参照图1c，与可被称为“可检索的”目标A、B、R1和R2相反，目标D可被称为“不可检索的”。对于本文件，可检索的目标是可在请求时从知识库在工作区中检索的目标。如果推理逻辑可向知识库发送对目标的请求，并作为答复接收该请求的目标，那么该目标是可检索的。

现在结合表1参照图2a～2c说明本发明的推理逻辑的简单例子。它们示出在两个单独的工作区W1和W2中解析的结果E，其中，事实A和B没有在工作区W1之外被公开，并且事实D没有在工作区W2之外被公开。

参照图2a，在工作区W1和W2中使用反向链以解析结果E。事实C在工作区W1中从事实A和B被解析，但事实D不能在工作区W1中被解析。从包含事实C的工作区W1的内容产生部分结果，而不是在不产生结果的情况下停止。在本例子中，事实C已屏蔽事实A和B，使得部分结果可在没有修改的情况下、在不公开事实A和B的情况下被传递给工作区W2。来自部分结果的事实C与规则R2和事实D结合使用以解析工作区W2中的结果E。

参照图2b，示出相同的方案，只是在两个工作区中使用正向链而不是反向链。如果向工作区W1断言用于事实A的新值，那么规则R1将被解析，这将断言用于事实C的新值。规则R2受事实C影响，但是，由于事实D不能在工作区W1中被解析，因此规则R2也不能被解析。在本例子中，包含事实C的部分结果被传递给工作区W2。向工作区W2断言来自部分结果的C的值，这使规则R2乃至结果E被解析。很容易理解，反向链和正向链的组合也是可能的。

参照图2c，如图2a那样使用反向链解析结果E，但处理的次序相反。在本例子中，规则R2不能在工作区W2中被解析，因此产生包含事实D和规则R2的部分结果。这可被传递给工作区W1，但这同时公开事实D和规则R2。通过将已知的事实D从部分解析的规则R2中提出(factor)，事实D和规则R2可被屏蔽。在本例子中，事实D已知为真实的，因此规则R2“如果C和D，那么E”被重构(refactor)为新规则R3“如果C，那么E”。包含R3的部分结果然后被传送给工作区W1。在工作区W1中，事实C从事实A和B被解析，然后，通过使用来自部分结果的规则R3，结果E被解析。

规则R3对于工作区W1或W2中的任一个都不是可检索的目标。由于在物理上在知识库中不存在规则R3，因此诸如“检索R3”的请求不能返回结果。不存在可被用于检索规则R3的标识符“R3”或其它选择准则。相反，规则R2是可检索的目标。诸如“检索解析E并依赖于D的所有目标”的请求可在工作区W2中检索规则R2。只有规则R2被允许向工作区W1公开，规则R2才对于工作区W1是可检索的目标。诸如“检索解析E的所有目标”的请求可在工作区W2中检索一组目标(在本例子中，为规则R2和事实D)，但不检索规则R3。如果该组中的目标之一对于工作区W1是不可检索的(由于例如它是专用的并且不被允许向工作区W1公开)，那么整个组对于工作区W1是不可检索的。规则R3是在对于结果的特定请求的背景中处理该组目标的结果。因此，对于规则R3的请求必须采取对于结果的请求的形式，例如，“返回试图解析E的结果”。这种对于结果的请求不是对于来自知识库的目标的请求；这是对于处理的请求。

很容易理解，也可以通过使用与图2c相同的技术屏蔽图2a和图2b中的部分结果。在这种情况下，被解析的事实C从规则R2中被提出，因此，规则R2“如果C和D，那么E”被重构以产生新规则例如“如果D，那么E”。该新规则然后在部分结果中被传递给工作区W2，该工作区W2然后使用该新规则以解析结果E。还容易理解，该新规则，诸如事实C，不是可检索的目标。

图2a～2c所示的逻辑可被用于通过“工作区链”处理多个推理工作区中的单个计算，其中，一个工作区可用的输入被解析，并且产生基于该处理的部分结果。该部分结果然后被传递给第二工作区用于通过使用包含部分结果的第二工作区可用的输入进一步处理。

参照图3，协同设备100和105可分别为通用计算设备，诸如服务器、工作站、膝上型电脑等，或可以为通过使用具有相关存储器和输入/输出设备的微处理器实现的专用设备，或者可以是诸如一个或更多个集成电路的电子电路系统和相关硬件。有利的是，协同设备100和105被配置为能够例如通过时间分割或多个处理器同时处理多个协同计算。

通信端口50被用于将各个协同设备连接到包含其它协同设备的外部部件上，并且，本文件中提到的与其它设备或引擎(engine)通信的协同设备或协同引擎暗指使用这种通信的通信端口50。通信端口50可以为本领域公知的以太网端口、USB端口和/或串行端口等。各协同设备可从和向诸如个人、计算机程序、计算机逻辑的执行件的外部方或能够发送请求和/或接收结果的任何其它代理接收请求和发送结果。另外，关于诸如时间、日期或特定状态的一些事件，协同计算可被协同设备自动启动。

协同设备100和105一般实现为独立的设备，但也可实现为与一个或更多个其它设备耦合的部件，例如实现为要被插入兼容计算设备中的电路板，或实现为要与其它集成电路连接的一个或更多个集成电路。

协同设备100和105分别包含协同引擎20和25，该协同引擎20和25执行本发明的逻辑并可体现为一个或更多个计算机程序、计算机可执行代码的库、用于微处理器的机器码或诸如一个或更多个集成电路的电子电路。协同引擎20和25可分别访问一个或更多个工作区(未示出)。工作区是由本发明的逻辑使用以解析推理目标的存储器的区域。用于工作区的存储器可体现为一个或更多个专用集成电路，或可被保持在协同设备的存储器中。用于管理工作区的逻辑可实现为本发明的逻辑的一部分，一个或更多个计算机程序、计算机可执行代码的库、用于微处理器的机器码、或诸如一个或更多个集成电路的电子电路系统。

协同引擎20和25分别与数据仓库30和35连接，以检索用于推理处理的目标。数据仓库30和35可体现为诸如索引文件或数据库的一个或更多个计算机程序，或替代性地体现为非易失性存储器和相关的控制逻辑。数据仓库30和35可以如图所示分别在协同设备100和105内部，或可以在它们外部。

通过向已知的推理逻辑添加三种特征，各协同引擎实现能够在多个引擎之间分布单个计算的处理的推理逻辑。

1)当未解析的目标被识别时，它不被舍弃而被添加到未解析的目标的列表中。由于协同引擎会另外永远循环下去，因此未解析的目标如已知的推理逻辑那样被标记为无法解析。未解析的目标列表可实现为元件的矢量或阵列、动态阵列或类似的结构。

2)当没有新的未被解析的目标可被识别时，会产生部分结果。部分结果根据未解析的目标产生，这些目标是当前在工作区中的那些和在可不解析的目标的列表中的那些，因此它们均已知为可解析最终结果的目标。因此，假定第二协同引擎可从部分结果解析未被解析的目标中的一个或更多个，那么部分结果代表第二协同引擎可使用以解析希望的最终结果的知识。一般地，部分结果包含被编码成协同引擎可接受的形式的未被解析的目标和它们所依赖的目标。存在许多本领域公知的用于推理目标的编码，包含诸如RuleML的非专有编码。

3)当部分结果被接收时，其中的目标被解码并使得对推理逻辑可用，因此，它们可以以通常的方式用于推理过程中。诸如词法分析器和分析程序的解码技术是本领域中公知的。解码的目标一般通过使用与已用于例示在工作区中检索目标的逻辑相同或类似的逻辑被例示为推理逻辑可理解的形式。被解码的目标可以以使得推理逻辑可随时检索它们的形式被存储在协同引擎内的临时数据仓库或知识高速缓存中。临时数据仓库中的目标一旦不再被需要就可被去除。

可以理解，实现所有三种修改的协同引擎能够同时发送和接收部分结果(即，它是“收发型”协同引擎)。其它的实施例可实现这三种修改的子集。例如，可以通过仅实现修改1和2构造只发送协同引擎，由此制造能够产生和发送但不接收部分结果的引擎。类似地，可以通过只实现修改3构造只接收协同设备。

优选地，当产生部分结果时，协同引擎还可屏蔽该部分结果中的目标。有利的是，其逻辑体现为可被协同引擎理解的一组目标，但它也可体现为诸如计算机程序、微处理器机器码或一个或更多个集成电路的离散逻辑。屏蔽某一目标的方法可以为：通过修改该目标本身(例如，可通过修改事实的值屏蔽事实目标)，或通过修改涉及该目标的目标(例如，规则目标可使事实或规则被提出(factor out))。但是，不是所有的目标都必须被屏蔽。可以理解，以下观察适用。

如果某一目标不能被检索，或者如果它涉及一个或更多个不能被解析的二次目标，那么该目标是未解析的。

不能在工作区中被检索的目标不能被屏蔽，也不能为该工作区所专用。

如果不涉及二次目标的目标(例如事实目标)不能被检索，那么它只能是未解析的，在这种情况下，它是如上面的图所示的目标。

被解析的目标可总是被提出涉及它的任何目标，因此不再需要包含于部分结果中。

涉及一个或更多个二次目标的目标可使解析的二次目标被修改和/或被重构和/或被提出，并使二次目标被提入(factor in)。

从这些观察可以理解，以下四种屏蔽技术足以在需要时(例如，由于目标或其涉及的目标是专用的)屏蔽部分结果中的目标：

a)被解析的二次目标可通过被修改而被屏蔽。例如，可以通过沿算子的方向对值进行取整(rounding)，修改“如果A＜$993.02，那么C”中的“993.02”，从而导致例如“如果A＜$950，那么C”。

b)被解析的二次目标可通过被提出而被屏蔽。例如，“如果A和B，那么C”中的B可被提出，从而根据B的被解析的值导致“如果A，那么C”或“不是C”。

c)被解析的二次目标可通过被重构而被屏蔽。例如，“如果A＞100，那么A＝100”可被重构为将直接引用(等算子)变为间接引用(小于等于算子)的“A＜＝100”。

d)涉及一个或更多个二次目标的目标可使被解析和/或未解析的目标被提入和/或被提出。例如，根据存在什么涉及A和B的其它目标，“如果A＜B+C，那么D”可被重构为“如果A＜X，那么D”或“如果A+Y＜Z，那么D”。

可以理解，用于屏蔽多个值的其它技术可根据在协同引擎中使用的目标的表示法被实现。另外，应用专用信息可被用于屏蔽多个值。例如，专用值“100”可由唯一标识符“abc”代替。如果标识符“abc”在随后遇到访问原始专用数据的过程，那么标识符“abc”可由原始值“100”代替。还可以理解，实施例可对于专用数据不能被屏蔽的情况规定该行为，例如，可产生错误，可包含不被屏蔽的数据，或者可以调用替代性的处理。

优选地，协同引擎可在从接收的部分结果解码的目标和从数据仓库检索的目标之间进行区分，并可在处理中使用这种区分，同时总是允许通过推理逻辑透明访问所有目标。透明访问所有目标保证所有适当的目标不管它们的来源(origin)如何都被推理逻辑使用。区分的能力允许协同引擎在处理中包含目标的来源，从而例如使目标之间的冲突的解析自动化。存在许多在目标之间实现区分的方式，诸如，用其来源标记各例示的目标、或保持目标及其来源之间的相关关系，使用散列表或类似的结构。

可以通过修改已知的推理引擎，或通过构建包含本发明的特定特征的新的推理引擎，构建协同引擎。已知的推理引擎的逻辑可以：识别未解析的目标；检测没有其它的目标可被识别；和响应输入启动处理。因此，对于本发明的逻辑，可以很容易地在现有的逻辑或新的设计内识别定位。例如，可以通过改变适当的类的适当方法、通过限定新导出的类或通过产生其它方法和/或类，改变体现为以诸如Java或C++的面向对象的编程语言写成的计算机程序中的现有推理引擎。可以使用相应的技术以修改机器码实现或电子电路设计。存在硬件和计算机软件形式的推理引擎的许多现有实现。这些实现可以是专用的或公共可自由获得的实现。

现在参照图3的设备和对于结果的请求即请求41被协同设备100接收的示例性例子讨论图4中的逻辑。协同设备100根据从数据仓库30检索的目标在协同引擎20中处理请求41，从而导致在对于结果的请求中产生并包含于其中的部分结果45被发送到协同设备105用于进一步的计算。协同设备105根据部分结果45中的目标和从数据仓库35检索的目标在协同引擎25中处理该请求，从而产生最终结果49。在本例子中，最终结果49通过各协同设备被传送给外部方(未示出)。在图3中，箭头线代表元件之间的数据通信。

逻辑通过接收请求41的协同引擎20在块2010中开始。通过对用请求41算出的任何部分结果解码并通过询问数据仓库30检索目标，协同引擎20例示(在块2010中)与请求41有关的推理目标。优选地，协同引擎20在完成这一点时使得它可以在来自部分结果的目标和从数据仓库30检索的目标之间进行区分(从而例如解析目标之间的冲突)，同时允许推理逻辑透明访问所有目标。在本例子中，不存在用由协同引擎20接收的请求算出的部分结果。

协同引擎20通过使用推理逻辑在其工作区中处理(在块2020中)例示的目标。推理逻辑通过从数据仓库30检索解析任何当前目标所需要的其它目标对它们进行例示，并且作为解析各目标的结果执行零个或更多个动作。推理逻辑是本领域公知的，并可包含正向或反向链逻辑、它们的组合或其它推理逻辑。

如果协同引擎20确定(在块2022中)目标不能被解析，那么它将未被解析的目标添加(在块2024中)到未解析的目标的列表中。

如果协同引擎20确定(在块2029中)存在至少一个未被解析且不是未解析的下一目标，那么逻辑后退到块2020。

如果不存在下一目标，那么，由于没有其它的目标可被识别，因此可应用于该计算的所有目标都已被协同引擎20识别和处理，从而导致工作区状态42，该工作区状态42可包含解析的目标和现在已知是未解析的未被解析的目标这两种目标。

协同引擎20确定(在块2030中)是否产生部分结果45。如果请求41需要的一个或更多个目标未被解析，并且如果部分结果不被禁止，那么协同引擎20确定产生部分结果45。部分结果可明确通过请求41或隐含地通过与请求41相关的目标的处理被规定或禁止。如果协同引擎20确定(在块2030中)不产生部分结果，那么逻辑前进到块2090，在该块2090中最终结果被传送。在这种情况下，如果一个或更多个目标未被解析，那么最终结果会是错误。如果协同引擎确定产生部分结果，那么逻辑产生空的部分结果45，并前进到块2040。

协同引擎20对于作为当前在工作区状态42中的那些和在未解析的目标的列表中的那些的各个未被解析的目标将一组目标添加(在块2040中)到部分结果45中。该逻辑递归地向部分结果添加各未被解析的目标提到的所有目标加上已在部分结果中的任何未被解析的目标提到的所有目标。该逻辑可体现为可由协同引擎解析的推理目标。并且，逻辑或推理目标可另外被用于优化、整理或重构(refactor)部分结果中的目标。在一些实施例中，逻辑首先将所有当前未被解析的目标添加到未解析的目标的列表中，然后将未解析的目标的列表中的所有目标加上它们涉及的那些目标添加到部分结果中。

如果协同引擎20确定(在块2049中)存在下一个未被解析的目标，那么逻辑前进到块2040。

协同引擎20识别(在块2050中)专用的部分结果45中的任何目标。协同引擎可以通过询问数据仓库30以确定各目标上的任何访问限制完成这一点。协同引擎20然后通过修改各专用目标和/或重构涉及专用目标的任何目标屏蔽专用数据。

协同引擎20可任选地将限定部分结果45中的包含可能的冲突或不定性的目标可如何被处理的其它目标添加(在块2050中)到部分结果45中。可通过导出例如通过使用存储在数据仓库30中的度量或目标的形式的优先级信息限定一个目标相对于另一个目标的优先级的度量或约束目标完成这一点。推理逻辑中的优先级目标和度量是本领域公知的。

协同引擎20将部分结果递送(在块2090中)到一个或更多个下一个协同引擎。协同引擎20通过直接从请求41或通过解析推理目标识别至少一个下一个协同设备并将部分结果递送给该协同设备用于通过与该设备相关的协同引擎进行处理，完成这一点。在本例子中，用对于协同引擎25使用刚才说明的逻辑处理的传送给协同设备105的结果的请求算出部分结果45。

协同引擎25例示(在块2010中)来自部分结果45的目标以及来自数据仓库35的目标。协同引擎25解析产生请求的结果所需要的所有目标，并因此在其未解析的目标的列表中不具有任何未被解析的目标。协同引擎25因此决定(在块2030中)不产生部分结果，并因此前进到产生并传输最终结果49的块2090。

图4中所示的逻辑能够按照收发两用协同引擎同时发送和接收部分结果。在不同的例子中，逻辑可从协同引擎25接收对于结果的请求开始，并且，如果(在块2030中)产生结果所需要的一个或更多个目标未被解析，那么协同引擎25可产生部分结果，该部分结果然后被递送到协同引擎20进行进一步的处理。可以理解，只发送或只接收协同引擎使用一部分被去除的类似的逻辑，因此不背离本发明的范围。

图5和图6示出分别被Company-A和Company-B使用的协同引擎20和25的目标的例子。在本例子中，目标包含规则和事实。可以理解，这是简化的例子，并且规则仅是解释性的，并可以采取协同引擎20和25可理解的任何形式。参照图5，数据集31和规则集32被存储在数据仓库30中，并为Company-A关于购买分别示出示例性的事实和规则。工作区状态42代表特定时间点上的协同引擎20内的状态，并且部分结果45示出协同引擎20产生的部分结果。参照图6，数据集36和规则集37被存储在数据仓库35内，并为Company-B关于销售分别示出示例性的事实和规则。工作区状态47和48代表特定时间点上的协同引擎25内的状态，并且最终结果49示出由协同引擎25产生的示例性请求的结果。

参照包含的图3～6说明Company-A从Company-B自动购买某一数量的螺栓的例子。响应购买请求41，协同引擎20设定“价格”和“数量”作为其目标，并通过使用数据集31和规则集32进行下去。协同引擎20到达工作区状态42中示出的状态，其中，可解析“价格”和“数量”的那些规则已在工作区中被检索，可从数据仓库31检索的那些规则提到的事实也已被解析，并且没有其它的目标可被识别。由于规则4201、4202和4203涉及未被解析的目标“价格”和“数量”，因此它们在工作区状态42中是未被解析的。协同引擎20因此产生部分结果45，并将未被解析的目标4201、4202和4203添加到部分结果中。在本例子中，在到达工作区状态42之前没有目标被识别为是未解析的，因此未解析的目标的列表是空的。另外，未被解析的目标只涉及被解析的二次目标，因此在部分结果中不包含其它的目标。

协同引擎20然后检查数据仓库30，以确定部分结果45中的任何目标是否是专用的。不管规则3201是否是专用的，事实3102都是专用的，因此，涉及它的任何目标，包含规则4203，也是这样。由于规则4203涉及专用事实，因此协同引擎20通过从规则4203导出新规则4501修改部分结果。通过屏蔽在这种情况下为公开银行存款余额3102的值$997.56的专用数据产生规则4501。通过从规则提出条件子句屏蔽该值。这样做时，条件子句中的大于算子被重构为使其“被逆转”的则子句中，从而导致小于等于算子。在本例子中，“如果价格×量＞$997.56，那么价格×量＝997.56”被重构为“价格×量＜＝997.56”。由于该规则不再包含等算子，因此它不再是对专用值的直接引用。

通过沿算子的方向将其取整(rounding)为一些合理值的倍数，该值可被进一步屏蔽。在本例子中，该值被取整为$50的倍数，从而导致值$950.00。在该过程后，部分结果45不包含对专用数据的直接或间接引用。在本例子中，屏蔽逻辑在推理规则(未示出)中被实现。

协同引擎25接收部分结果45，并且前进以通过使用数据集36和规则集37解析部分结果。在处理规则集37中的规则后，协同引擎25具有解析的“数量”值(1000；与部分结果45中的规则一致的值)折扣值(10％)和价格值($1.08)，从而导致工作区状态47所示的状态。但是，当协同引擎25考虑规则4701时，由于1000×$1.08大于$950，因此新的“数量”值将被解析。对此响应，协同引擎25解析新的“折扣”值，从而到达工作区状态48所示的状态。由于请求的目标“价格”和“数量”现在被解析，并且工作区状态48中的所有值都与所有规则一致，因此协同引擎25产生它可返回协同引擎20的最终结果49。

很容易理解，协同引擎20和25已在不向其它协同引擎公开专用目标的情况下通过使用推理逻辑商议多方计算结果。在本例子中，部分结果45内的目标允许在不需要通信的第二交换的情况下进行商议。由于协同引擎25不能解析所有的目标，因此它可向协同引擎20发送第二部分结果进行进一步处理。这样，延长的商议被支持。

可以理解，对于在这种计算中包含的协同引擎的数量没有理论限制。在不同的例子中，协同引擎25解析一些而不是全部的未解析目标，并产生部分结果以发送给第三协同引擎(未示出)。通过规定是否可产生部分结果，各协同引擎可对什么时候产生最终结果进行控制。例如，协同引擎20可通知协同引擎25需要部分结果，由此保证协同引擎25不产生最终结果，使得第三协同引擎也可被包含于计算中。类似地，协同引擎20可通知协同引擎25需要最终结果，从而强制协同引擎25产生最终结果，或者，如果这是不可能的，产生错误。

部分结果也可被发送给另一协同设备以外的目的地。部分结果可被发送给逻辑的执行段(executing piece)，用于被转发给一个或更多个协同设备，或用于其它处理。部分结果也可被存储在暂时存储器(例如要在协同设备之中共享)中和/或从其中被检索，或者可被保存到诸如磁盘或磁带的永久存储器中。

在另一实施例中，本发明被应用于智能网络(IN)通信网络中的电话呼叫的通路选择。

如果通信网络可考虑呼叫方和被叫方双方的偏好，那么会对顾客存在显著的附加益处。这会使得能够进行比孤立考虑各方的偏好的已知技术更好地匹配双方的组合偏好的呼叫路由决定。对于包含呼叫转移的呼叫，如果组合确定在发端网络上是可用的，那么还会在信息通路的更有效路由和更有效使用方面有显著的益处。这会使得呼叫能够被直接发送到它们的最终目的地。使用常规的呼叫转移，呼叫通过呼叫方的网络被路由到被叫方的网络，该被叫方的网络然后将呼叫转移到最终目的地。这种呼叫转移的第二支路(leg)包含一般由最初的被叫方承担的第二呼叫。

已知的推理逻辑要求在单一的推理引擎中产生推理结果，但用户偏好会包含不可与其它网络共享的诸如电话号码和详细联系方式的专用信息。同时，电话网络一般需要每秒解析几十个、几百个或者甚至几千个路由选择通路，并且，对于完成路由选择的总时间存在严格约束。例如，对于路由选择通路的询问的响应会需要少于250毫秒。本发明通过使用呼叫方和被叫方双方的偏好提供用于使用推理逻辑以计算路由选择通路的实际方案。

例子将考虑呼叫方Alice和被叫方Bob之间的电话呼叫的路由选择。在本例子中，Alice使用其移动电话呼叫作为业务联系人的Bob，在Bob的电话上为下午6:00。Alice和Bob是不同移动网络的客户。Alice知道她的业务联系人中的一些在家里工作，并且有时将他们的移动呼叫转接到他们的住宅电话。虽然Alice喜欢她的电话在上班时间转接到住宅电话，但是，如果接收人的当地时间晚于下午5:30，那么她希望它们转接到语音邮件。Bob希望能够激活将打给他的手机的所有电话转接到他的住宅电话的“在家”模式。他还希望使来自特定的重要呼叫者的电话以外的所有电话在下午9:00后转接到语音邮件。

参照图7，表示为规则和事实的Alice和Bob的偏好分别被存储在知识库33和38中。例如，依次地，规则3302规定Alice的在下午5:30以后对业务联系人的呼叫被路由到他们的语音邮件系统而不是他们的住宅电话的偏好，以及规则3801规定Bob的当“AT-HOME”模式激活时对于其手机的呼叫被路由到他的住宅电话或语音邮件系统的偏好。可以理解，这是简化的例子，并且规则也仅是解释性的。

还参照图3，Alice的移动网络与协同设备100连接，而Bob的移动网络与协同设备105连接。知识库33被存储在数据仓库30中，而知识库38被存储在数据仓库35中。当Alice拔打Bob的号码时，Alice的移动网络对呼叫处理指令启动IN询问。该询问作为对于结果的请求被转发给在协同引擎20中对其处理的协同设备100。应当注意，在图3或图4中没有示出本例子中的对于结果的请求、部分结果和最终结果。

参照图4的逻辑，协同引擎20解析“RECIPIENT is BUSINESS”，但是，由于“DESTINATION”不能被解析，因此规则3302是未解析的。由于没有其它的可被解析的规则，因此协同引擎20产生部分结果44。在本例子中，事实3301是专用的，因此规则3302被重构以去除事实3301，从而导致新的规则4401。协同设备100然后将对于包含部分结果44的结果的请求发送给在协同引擎25中对其处理的协同设备105。

协同引擎25接收部分结果44并进行下去。在本例子中，Bob使其“AT-HOME”模式被激活，因此，协同引擎25从规则3801解析“DESTINATION＝HOME，VOICEMAIL”。协同引擎25现在可从部分结果44解析规则4401，这解析“DESTINATION＝1234 987654”。协同引擎25现在可产生最终结果46。在本例子中，协同设备105将最终结果46发送给协同设备100，该协同设备100可作为对最初询问的响应返回它，从而提供路由选择通路。

存在许多实现允许Alice的偏好改变Bob的偏好的逻辑的方式。在本例子中，协同引擎25在来自部分结果44的目标和从数据仓库38检索的目标之间进行区分，并且，Alice的规则4401如果规定当前Bob的偏好也可接受的DESTINATION则只被允许修改Bob的。由于Alice的规则4401规定“DESTINATION＝VOICEMEAIL”，并且Bob的规则3801也将VOICEMAIL规定为可接受的DESTINATION，因此，Alice的修改可被接受。替代性的实现可以以私密性的次序列出目的地，并且只允许从Alice的选择私密性相同或更小私密性的目的地的规则进行修改。这样，从住宅电话向语音邮件系统的改变可被接受，而从住宅电话向移动电话的改变不能被接受。理想情况下，这种逻辑也会作为规则被实现，因此它可由备用户定制。在任意实现中，如果规则冲突使得没有DESTINATION可被选择，那么不能进行连接，并且返回发起端网络的结果可指示播放通告以通知Alice此时不能完成该呼叫。

在前面的例子中，如果Alice在下午5:30之前进行了呼叫，那么返回协同设备100的最终结果会是Bob的住宅电话号码，并且Alice的呼叫会被直接路由到Bob的住宅电话。使用常规的呼叫转移，Alice的呼叫会被路由到Bob的移动网络，如果呼叫转移被启用，那么该移动网络与PSTN上的Bob的住宅电话进行第二次连接。在这种情况下，对于呼叫的持续过程，用于两次呼叫的网络资源被消耗。

通过在不公开专用信息的情况下使用Alice和Bob双方的偏好，两者之间的呼叫的路由选择通路被有效计算。产生和屏蔽部分结果44的处理开销较少，并且网络传输开销也较少。只存在一次从协同设备100到协同设备105的传输，并且其内容部分结果44较小(通常明显小于Alice的偏好)。从协同设备105到协同设备100的单一答复传输包含最终结果46，该最终结果46也较小(通常比部分结果44小)。诸如作为规则或参数传输Alice或Bob的偏好中的全部的替代性技术包含较多的传输开销，并且可能比处理开销多。由于路由选择通路必须在受限制的时帧中被计算，因此具有较高的计算和网络开销的已知的安全协议不能被用于保护Alice和Bob的偏好。

很容易理解，Alice的网络不需要知道最终结果46包含来自Alice的偏好以外的任何偏好的信息。从网络的观点，进行询问并接收响应。在IN网络的情况下，不需要改变网络逻辑或操作模式。这意味着协同设备可以以最少的集成工作被加入现有的网络中。

还很容易理解，如果只有呼叫中包含的网络中的一个使用协同设备，那么，虽然没有协同处理的益处，但该网络仍享有使用推理逻辑用于处理偏好的益处。当各方的网络使用协同设备时，实现协同处理的附加益处，包括更好地匹配双方的组合偏好的路由选择通路以及协同引擎之间的商议的可能性。并且，在这种协同处理中可包含多于两个的协同设备，并由此可包含多于两个的网络。

使用协同推理处理产生路由选择通路是极其灵活的。例如，Bob的规则和/或网络可禁止输出Bob的电话号码中的一些或全部。协同引擎25可替代性地向Alice的网络返回虚拟电话号码。当Alice的网络与Bob的网络上的该虚拟号码产生连接时，Bob的网络进行IN询问以为该虚拟号码确定正确的目的地，从而导致如前面由协同引擎25确定的那样给该呼叫定路线。

在另一例子中，Bob具有规定“if DESTINATION is VOICEMAILand CALLER is BUSINESS then VOICEMAIL.MESSAGE＝BUSINESS-MESSAGE”的附加规则。由于Alice的网络对Bob的语音邮件系统没有控制，因此解析该规则(在协同引擎25中)以产生“VOICEMAIL.MESSAGE＝BUSINESS-MESSAGE”导致必须在Bob的网络中处理的信息。其一种实现方式是，协同引擎25解析属于Bob的网络的虚拟电话号码的目的地，例如，“DESTINATION＝1234555555”。当Alice的网络将呼叫路由到Bob的网络上的12345时，Bob的网络使用IN询问的结果以将该呼叫路由到Bob的语音邮件系统并播放适当的消息。

很容易理解，诸如短消息服务(SMS)、电子邮件和即时消息收发的其它形式的电信可以以类似的方式被路由，并且任一方的推理规则可包含各种输入而不仅是例子中示出的那些。

本发明针对解决多于一个的工作区中的推理逻辑的问题提供一般方案。与已知的多方推理处理相比，由于部分结果不需要包含仅由其它被解析目标涉及的被解析目标，也不需要包含在计算中不被涉及的数据仓库中的目标，因此本发明大大减少引擎之间的各传输中的数据的量。这是对必须将包含不会被使用的目标的所有可能目标传送给单一推理引擎或在驻留在远程数据仓库中的各个新目标被识别时执行多个网络传输的已知推理逻辑的实质性改进。

由于部分结果一般只包含对于某一计算解析的目标的子集，因此在部分结果中不包含许多专用目标。在部分结果中包含的专用目标可被有效屏蔽，以避免公开它们。另外，不是专用的但是是“位置相关的”输入可在本地被多个互连的协同引擎中的一个处理，由此使得能够产生结果。由于输入对于传输来说太大或者会在传输中受损，因此它们可以是位置相关的。

本发明的一些实施例可以不屏蔽部分结果中的专用值。但是，这些实施例保留本发明的其它益处，诸如，协商被延长和引擎之间的传输开销减少。

很容易理解，可以通过添加诸如新规则的新目标或通过完全将一组目标改变为另一组，改变协同引擎20和25的行为。因此，协同引擎是可编程的，并可被配置为根据与其相关的规则和事实执行一种类型或许多不同类型的计算。

有利的是，协同引擎20和25还可保护它们之间传递的部分结果的内容。由于部分结果可包含间接涉及专用数据的目标，因此，如果可获得足够的相互关联的部分结果，那么恶意方可在一些方案中重构专用数据。恶意方可因此试图为此目的导致产生多个相互关联的部分结果。可以使用多种现有技术以应对这种可能性，包括：对请求进行审计、对任意方限制某一时间周期内的请求的次数、和通过使用诸如密码的静态验证标志(static authentication token)对各方进行验证。虽然这些技术均可有利地单独或以组合的方式与本发明一起使用，但本发明的优选实施例提供一方通过使用作为双方都知道的专用事实的动态验证标志向另一方动态验证自身的另一技术。由于专用事实已被接收方知道，因此这不代表专用事实的公开。各个新的动态验证优选地基于将成功验证的次数限制为共享的专用事实的数量的不同事实或其一些功能使用新的验证标志。

在一个优选实施例中，通过使用来自由两个引擎协同解析的以前的计算的事实，在两个协同引擎之间实现动态验证。因此，可产生验证标志的一组事实在结果产生时连续增长，但是，如果大量的验证在不产生结果的情况下产生，那么该组事实将被耗尽。已知的推理逻辑被用于识别这种来自以前的协同计算的事实，并从其中导出动态验证标志。该标志通过与专用事实相比较被验证。由于本实施例需要来自以前的计算的事实，因此对于第一个这种计算将不存在可用的事实。在这种情况下，逻辑可允许来自以前被验证的协同引擎的第一验证请求为空的标志，并且可能用有限的特权对其进行验证。作为替代方案，初始标志被提供给各协同引擎以使得第一动态验证能够成功。通过防止来自一个协同计算的事实被用于对紧挨着下面的协同计算进行验证，可以获得更大的安全性。

有利的是，为了更大的安全性，常规的验证技术可与动态验证组合。

并且，可以使用安全传输协议以保护验证标志和部分结果的传输。诸如SSL和IPSec的安全传输协议在本领域中是公知的。

现在参照图4～6说明动态验证的例子。考虑与以前参照这些图说明的例子相同的例子，协同引擎20确定(在图4中的块2090中)要被用作动态验证标志的专用事实。在本例子中，这是事实3101(lastorder＝PO1234)，协同引擎20确定该事实3101是与与Company-B的以前的交易相关的事实。协同引擎20包含该事实作为具有部分结果45的动态验证标志。协同引擎25通过确认验证事实不涉及Company-A并且它与数据集36中的相应事实3601匹配，动态地验证(在图4中的块2010中)部分结果45。

(本发明的其它应用)

协同设备可被用于各种各样的应用中。除了前面所述的电子商务和通信路由例子，协同设备可被配置和编程为执行特定的任务或广泛的协同和协商。

图8示出多个计算设备如这里说明的那样执行多方处理的分布式数据处理系统。

如图8所示，分布式数据处理系统可包含多个网络，诸如局域网LAN 50和LAN 55，这些局部网中的每一个可包含多个单个计算设备。很容易理解，各个LAN可被诸如公司的单独实体拥有，并且，LAN可在地理上被分开并通过因特网或其它网络被连接。

各单个计算设备可以是诸如服务器100、101和105的服务器(共享计算设备)或诸如客户机200、201、205、206和207的客户机。各单个客户机可以是具有使得用户能够启动处理的用户接口外设(例如，键盘和监视器)的工作站、笔记本计算机或个人计算机等。诸如数据仓库30和35的数据仓库可与服务器或客户机耦合，并且可被用于存储包含推理目标的数据。

由实体拥有的各LAN上的计算设备可运行多个计算机化的应用，用于为该实体执行某一范围的协同任务。这些应用可包含工作流程、商业对商业电子商务、办公自动化、设计和群件应用，并可在客户机和/或服务器上运行。参照图8，协同应用60在LAN 50上的计算设备上运行，并且协同应用65在LAN 55上的计算设备上运行。各协同应用实例可被配置通过使用一个或更多个协同引擎20和25用一个或更多个相应的协同应用实例协同处理。

服务器和/或客户机可以是运行协同引擎的协同设备。执行协同引擎的逻辑的服务器以下称为协同服务器。协同服务器100和101分别使用单独的协同引擎20，并且，通过将规则添加到数据仓库30中的一个或更多个规则集中，可被编程为执行特定的协同任务。协同服务器101还执行协同应用60中的一些或全部的其它逻辑。协同服务器105使用协同引擎25，并且，通过将规则添加到数据仓库35中的一个或更多个规则集中，可被编程为执行特定的协同任务。

客户机200和205也是协同设备。客户机200执行协同引擎20的逻辑，而客户机205执行协同引擎25的逻辑。

很容易理解，协同应用和协同引擎可被松散地耦合(例如，协同应用使用在单独的计算设备上运行的协同引擎)，可在逻辑级上被紧密地耦合(例如，协同引擎仅与特定的协同应用通信)，或者可在物理级上被紧密耦合并在同一计算设备上运行(例如，协同引擎被嵌入协同应用中)。分布式数据处理系统或包含分布式数据处理系统的一部分的网络可包含任意或所有形式。

还可以理解，诸如一些工作流程和商业对商业电子商务应用的一些应用可完全以协同引擎可理解的目标被实现，并因此可被配置在不运行协同应用的一个或更多个协同服务器上。作为例子，拥有LAN 50的公司可从拥有LAN 55的公司购买供应品。响应数据仓库30中的规则，协同服务器100可用协同服务器105执行协同计算。这种计算可被自动化，并且可以是周期性的，或者响应由协同服务器检测的事件，诸如在库存较低时自动购买。

其它应用可包含其它逻辑，诸如协同应用60和65。协同应用60和65可以是办公自动化应用或诸如设计、机械建模、财务建模等的更加为商业专有的处理。这些协同应用可接触代表应用执行计算的协同服务器，或者可在应用逻辑中包含协同引擎，以使应用增加协同能力。

作为例示，参照图8：

●一个或更多个客户机200和/或201分别执行协同应用60的实例，以与在一个或更多个客户机205和/或206上运行的一个或更多个协同应用65协作，以产生协同结果。可以使用协同服务器100和/或105和/或客户机200和205的协同引擎以计算协同结果。

●一个或更多个客户机201上的一个或更多个协同应用60用对于协同计算的请求访问协同服务器100。协同服务器100在与一个或更多个协同引擎20或25的协作中完成计算，从而产生请求的结果。

●客户机200上的协同应用60使用在同一客户机计算设备上运行的协同引擎，以与在一个或更多个客户机205上运行的相应应用65的一个或更多个实例协作，以完成协同计算。

协同计算也可由不执行协同应用的瘦客户端(thin client)请求。瘦客户端可包含网络测览器、Java程序(Java applet)或远程命令解释程序(remote command shell)(例如telnet或rsh)中的网络形式。例如，用户可通过使用客户机207向协同服务器105提交对于协同计算的请求，这可在与协同服务器100和/或一个或更多个协同引擎20的协作中确定结果。

在另一应用(未示出)中，协同引擎和数据仓库可被加入网络管理电路中，并且通过数据仓库中的目标被编程，以产生能够与其它协同网络管理电路协同执行错误检测、服务水平管理和网络管理任务的协同网络管理电路。例如，网络的主段上的一个或更多个协同网络管理电路可与另一网络的主段上的一个或更多个协同网络管理电路协同，以在各段之一中的部件失效的情况下重新配置业务用通路。电路可实现自动化的、多方的、基于规则的错误检测和包括例如附加带宽的协商的业务重新路由选择。目标可实现反映诸如服务水平协议(SLA)的商业考虑的商业规则。

应用的其它领域包括金融，其中，例如，两个或更多个金融机构可使用本发明以在不公开包含的各方的财务细节的情况下确定财务计算。这些机构可包含一般在公开信息方面受到法律限制的银行、信用卡供应商和税务部门。

很容易理解，在所有情况下，对某一域专用的数据可被屏蔽或通过相关的协同引擎或引擎保持专用。域边界不需要与物理边界一致。例如，可以在网络或数据仓库中存在多个域(例如，每个域用于各个公司部门)，和/或在域内存在多个网络或数据仓库(例如，公司的多个LAN或数据仓库)。

(显著优点)

本发明使得能够在不需要将用于计算的所有输入都在单一推理工作区中检索的情况下通过使用推理逻辑处理该计算。这使得专用或位置相关输入在不被传送到其它方的情况下并且以大大少于常规技术的网络和计算开销被用于多方计算。协同引擎可体现为离散的设备，因此容易被添加到现有的基础结构上，并且允许协同及其管理在协同设备级上在中心被限定和控制。还支持用于分布基于推理的计算的附加模型，包括保存部分结果用于后面的延拓(continuation)，以及通过使用多个协同设备归纳并行处理复杂计算。

以上仅说明了本发明的一些实施例，并且，在不背离本发明的范围的条件下，可以利用对本领域技术人员来说显而易见的修改和添加。

(术语表)

目标

推理的目标。推理逻辑将目标的解析设定为其当前的任务，并进行下去。解析该目标的过程将常常导致揭示要被解析的其它目标。在正向链推理中，这些其它的目标作为解析第一目标的结果被解析。在反向链推理中，这些其它的目标作为解析第一目标的先决条件被解析。

目标常被再分为事实和规则，这里，事实是用于一些指定实体的值，规则是一些关系，通常采取“如果X，那么Y”的形式。由于规则只是曾经被检索以解析事实，因此反向链趋于仅将事实看作目标。由于解析一个规则会导致其它规则被识别和解析，因此正向链趋于将规则视为目标。

还存在其它形式的推理逻辑，诸如“基于约束的逻辑”，其一种形式是使用正向推理的类型，其中经典规则和事实目标增加了作为没有“如果X”谓项(predicate)的正向链规则(例如“10＜Y＜100”)的约束目标。

需要注意，所有目标可被有效表示为一个或更多个规则目标：

a)(事实)：如果X没有值，那么X＝100；

b)(约束)：如果Y＜＝10，那么断言Y＝11；如果Y＞＝100，那么断言Y＝99

未解析的目标

推理逻辑确定不能被解析的目标。通常这是因为缺少解析该目标所需要的一些事情。例如，推理逻辑可试图跟随推理到达目标X，但发现它不能从任何可用的来源检索目标X。在这种情况下，目标X被视为是未解析的。并且，第二目标即目标Y可直接依赖于目标X。在这种情况下，作为X未解析的结果，目标Y也是未解析的。第三目标即目标W可间接依赖于目标X(例如，通过直接依赖于目标Y)。在这种情况下，如果从W到X的间接通路为或变为解析目标W的仅有的方式，那么目标W也变为是未解析的。

例如：目标X是事实目标，例如购买的折扣率(X＝？)；

目标Y是规则目标，例如依赖于折扣的规则，并且

目标W是通过规则目标Y依赖于X的事实目标(如果X＞10％，那么W＝W*1.5)。

假定是上述情况，那么，如果不能对X检索或另外确定某值，那么X是未解析的。规则目标Y因此是未解析的。如果规则Y是仅有的可解析W的规则，或者如果W的所有其它剩余的规则都依赖于X或其它未解析的目标，那么W因此也是未解析的。

可检索的目标

可通过使用推理逻辑发起的对于目标源的请求、而不是例如推理逻辑响应由该源发起的呼入通信提出的请求，由推理逻辑检索的目标。

可检索目标是可根据请求在工作区中被检索的目标。因此，如果协同引擎A可请求来自目标源的目标并且作为答复接收该被请求的目标，那么该目标是可检索的。

部分结果

能够部分地解析请求但本身不足以解析该请求的与对于结果的请求相关的一个或更多个目标的组。

部分结果中的目标中的至少一个是不可检索的目标。由于部分结果中的不可检索的目标是处理其它目标的结果，因此它不能从任何知识库中被检索。(由于部分结果中的不可检索的目标是从其它已知的目标动态产生而不是从静态存储器中被检索，因此也可被描述为“动态”目标，或者，由于它与持续存在于知识库中的现有目标不同是根据需要产生的临时目标，因此可被描述为“瞬时”目标)。

这意味着以下方面：

c)这种不可检索的目标在物理上不存在于任何知识库中。由于目标X不存在于任何知识库中，因此协同引擎A的请求“送我目标X”不能导致这种目标(事实上，由于目标不存在于任何知识库中，因此不存在可用于检索它的标识符‘X’)；

d)这种不可检索的目标不能单个地通过单一请求被检索。协同引擎A可发送请求“发送解析X的所有目标”。对该请求的响应是多个目标的组，不是单一目标。

e)这种不可检索的目标只能在特定请求的背景中被算出。如果响应的引擎确实响应请求“发送解析X的所有目标”，那么结果将不与相应的部分结果中的一组目标相同。通过取得该请求的结果并在用于特定请求的特定的一组值的背景中处理这些目标，会有效形成部分结果；

f)检索部分结果的目标的请求因此不是对于目标的请求，而是对于结果的请求。例如，推理引擎A可发送请求“发送可解析X的所有目标，假定A＝1，B＝2，C＝3”。首先，这不是对于目标的简单的请求-它是目标的交换。第二，所返回的是结果而不是目标。这是用请求处理提供的目标并作为发送协同引擎的保护动作产生部分或最终结果的结果。

Claims (43)

1.一种用使用推理逻辑的协同引擎电子处理对结果的请求的方法，其特征在于，该方法包括根据一个或更多个未解析的目标产生部分结果的步骤。

2.如权利要求1所述的方法，其中，提供不充分的目标以解析请求。

3.如权利要求1或2所述的方法，其中，部分结果包含至少一个能够部分解析被请求的结果的目标。

4.如权利要求1～3中的任一项所述的方法，包括检索至少一个可检索目标的步骤。

5.如权利要求1～4中的任一项所述的方法，还包括识别能够部分解析对于结果的请求的未解析的目标的步骤，并且其中，部分结果根据识别的未解析的目标产生。

6.如权利要求1～5中的任一项所述的方法，其中，根据一个或更多个未解析的目标产生部分结果的步骤包括：产生一组未解析的目标和未解析的目标依赖的任何目标并将所述组包含于部分结果中。

7.如权利要求1～5中的任一项所述的方法，其中，根据一个或更多个未解析的目标产生部分结果的步骤包括：产生一组未解析的目标的子集和已在子集中的任何目标所依赖的任何目标，并将所述子集包含于部分结果中。

8.如任一项前面的权利要求所述的方法，其中，产生部分结果的步骤还包含屏蔽部分结果中的至少一个目标。

9.如权利要求8所述的方法，其中，屏蔽目标的步骤包括：

(i)改变目标或涉及所述目标的一个或更多个目标；和/或

(ii)用仅对执行屏蔽的协同引擎已知的产生的目标或值或在与所述引擎相同的安全域中的其它处理代替所述目标或所述目标中的值。

10.如任一项前面的权利要求所述的方法，其中，协同引擎包含发送协同引擎，该方法还包括以下步骤：

(i)包含具有对于结果的另一请求的部分结果并将所述另一请求传送给至少一个另外的协同引擎或逻辑的执行段；或

(ii)存储部分结果。

11.如权利要求10所述的方法，其中，从一个或更多个可检索目标产生动态验证标志并包含具有要被传送给至少一个另外的协同引擎的对于结果的另一请求的动态验证标志的步骤在传送对于结果的另一请求的步骤之前。

12.如权利要求11所述的方法，其中，产生的动态验证标志以前没有作为动态验证标志被传送给所述至少一个另外的协同引擎。

13.一种用使用推理逻辑的协同引擎电子处理对结果的请求的方法，其中，协同引擎包含接收协同引擎，并且，对于结果的请求包含至少一个能够部分解析对于结果的请求并且不是可检索的目标的目标，该方法包括根据可检索的目标和包含于对于结果的请求中的至少一个目标处理对于结果的请求的步骤。

14.如权利要求13所述的方法，其中，对于结果的请求还包括动态验证标志，该方法还包括以下步骤：确认包含的验证标志，并且，如果确认成功，则前进，否则，如果确认失败，则终止处理。

15.如权利要求1～14中的任一项所述的方法，其中，协同引擎包含收发协同引擎，该方法包括以下步骤：

(i)如果对于结果的请求包含至少一个能够部分解析请求的结果的目标，则根据可检索的目标和包含于对于结果的请求中的至少一个目标处理对于结果的请求；或者

(ii)否则，根据可检索的目标处理对于结果的请求。

16.如任一项前面的权利要求所述的方法，其中，

(i)用两个或更多个协同引擎处理对于结果的请求，

(ii)如果在可检索的目标内提供不充分的目标，并且，如果包含在对于结果的请求中的至少一个目标可应用于解析被请求的结果，那么产生部分结果，

(iii)如果产生部分结果，那么包含部分结果的对于结果的另一请求被传送给至少一个另外的协同引擎。

17.如任一项前面的权利要求所述的方法，其中，推理逻辑包含基于规则的逻辑。

18.如任一项前面的权利要求所述的方法，其中，对于结果的请求是送往或来自通信网络的用户的用于电子通信的路由选择通路的请求。

19.如权利要求18所述的方法，包括检索作为与为该用户处理电子通信有关的事实或规则的至少一个可检索目标的步骤。

20.如权利要求18所述的方法，其中，对于结果的请求是用于电话连接的路由选择通路的请求。

21.如权利要求20所述的方法，包括检索作为与为该用户确定用于电话连接的路由选择通路有关的事实或规则的至少一个目标的步骤。

22.如权利要求18所述的方法，其中，对于结果的请求是来自或送往该网络的用户的用于通信消息的路由选择通路的请求。

23.如权利要求22所述的方法，包括检索作为与为该用户确定用于通信消息的路由选择通路有关的事实或规则的至少一个目标的步骤。

24.如权利要求1～17中的任一项所述的方法，其中，对于结果的请求是对于电子数据网络的部件的管理动作的请求。

25.如权利要求24所述的方法，包括检索作为与管理该部件有关的事实或规则的至少一个可检索目标的步骤。

26.如权利要求1～17中的任一项所述的方法，其中，对于结果的请求是对于商业交易的请求。

27.如权利要求26所述的方法，包括检索作为与处理商业交易有关的事实或规则的至少一个可检索目标的步骤。

28.如权利要求1～17中的任一项所述的方法，其中，对于结果的请求是用于执行办公自动化、工作流程、日程表或文件管理处理的请求。

29.如权利要求28所述的方法，包括检索作为与办公自动化、工作流程、日程表或文件管理处理有关的事实或规则的至少一个可检索目标的步骤。

30.一种通过使用推理逻辑电子处理对于结果的请求的协同引擎，其特征在于，协同引擎包含用于根据一个或更多个未解析的目标产生部分结果的装置。

31.如权利要求30所述的协同引擎，其中，对于结果的请求包含部分结果，所述协同引擎还包含用于处理部分结果的装置。

32.如权利要求30或31所述的协同引擎，其中，协同引擎适于在没有足够的目标可用于解析请求的情况下产生部分结果。

33.一种通过使用推理逻辑电子处理对于结果的请求的协同引擎，其中，对于结果的请求包含部分结果，其特征在于，协同引擎包含用于处理部分结果的装置。

34.如权利要求30～33中的任一项所述的协同引擎，其中，协同引擎与至少一个通信网络连接并适于处理送往或来自通信网络的用户的用于电子通信的路由选择通路的请求。

35.如权利要求34所述的协同引擎，其特征在于，协同引擎适于检索作为与为该用户处理电子通信有关的事实或规则的至少一个可检索目标。

36.如权利要求30～33中的任一项所述的协同引擎，其中，协同引擎与至少一个电子数据网络连接并适于处理用于确定关于该网络的至少一个部件的管理动作的请求。

37.如权利要求36所述的协同引擎，其特征在于，协同引擎适于检索作为与该网络的至少一个部件的管理有关的事实或规则的至少一个可检索目标。

38.如权利要求30～33中的任一项所述的协同引擎，其中，协同引擎与至少一个电子数据网络连接并适于处理用于为与网络连接的用户确定商业交易的请求。

39.如权利要求38所述的协同引擎，其特征在于，协同引擎适于检索作为与为该用户处理商业交易有关的事实或规则的至少一个可检索目标。

40.如权利要求30～33中的任一项所述的协同引擎，其中，协同引擎与至少一个电子数据网络连接并适于为与该网络连接的用户处理用于执行办公自动化、工作流程、日程表或文件管理处理的请求。

41.如权利要求40所述的协同引擎，其特征在于，协同引擎适于为该用户检索作为与办公自动化、工作流程、日程表或文件管理处理有关的事实或规则的至少一个可检索目标。

42.如权利要求30～41中的任一项所述的协同引擎，其中，推理逻辑使用基于规则的逻辑。

43.一种用使用推理逻辑的协同引擎电子处理对结果的请求的方法，其特征在于，该方法包括根据一个或更多个可检索的目标处理部分结果的步骤。

Images