建立对等因果关系和信任关系的方法和设备

摘要

公开一种由网络中的第一用户建立对等因果关系和信任关系的本发明的方法和设备的一个实施例，其包括：与所述网络中的至少一个第二用户进行事务；和与所述第二用户交换关于所述事务的反馈，由所述第一用户和所述第二用户的至少其中之一本地保存所述反馈的副本。然后，保存反馈的一方或多方响应于第三方的查询提供反馈。这样，第三方可调查第一和/或第二用户的可靠性(或缺乏可靠性)。

说明书

技术领域

本发明一般地涉及计算网络，更具体地，涉及在对等数据传输网络的用户之间建立信任关系(trust)或因果关系(karma)。

背景技术

图1是以对等(P2P)方式交互的节点(例如，计算装置)的网络100的示意性示图。一般地，请求节点101将搜索消息105(例如，包含与请求节点101希望定位的数据相关的关键字)经由对等连接发送到与请求节点101通信的至少一个中间节点111。中间节点111接收搜索消息105，并将搜索消息105转发到至少一个附加节点111。最后，搜索消息105到达具有被请求数据的至少一个响应节点103(在某些情况下，搜索消息105被转发到的第一中间节点111也可以是响应节点103)。然后，至少一个响应节点103例如经由中间节点111将响应消息107发送回请求节点101。然后，请求节点101通过例如经由直接连接109与响应节点103直接连接的方式从响应节点103请求相应数据。

如上所述的传统P2P事务是相对匿名的或半匿名的事件，包括请求节点101和响应节点103的用户典型地对彼此知道很少。因此，如果一个用户在先前没有与另一用户进行过处理，则很难确定所述另一用户的可靠性。因此，在处理其它网络用户的过程中会涉及一定量风险。

因此，在本领域中需要一种建立P2P因果关系和信任关系的方法和设备。

发明内容

公开一种由网络中的第一用户建立对等因果关系和信任关系的本发明的方法和设备的一个实施例，其包括：与所述网络中的至少一个第二用户进行事务；和与所述第二用户交换关于所述事务的反馈，由所述第一用户和所述第二用户的至少其中之一本地保存所述反馈的副本。然后，保存反馈的一方或多方响应于第三方的查询提供反馈。这样，第三方可调查第一和/或第二用户的可靠性(或缺乏可靠性)。

附图说明

本发明的上文所述实施例实现的并且可以被详细理解的方式、本发明的更特定描述、上文简述的发明内容可通过参照附图中所示的实施例获得。然而，应该注意，附图仅示出本发明的典型实施例，因此不认为是本发明的范围的限制，并且可以容许其它等效实施例。

图1是以对等方式交互的节点的网络的示意性示图；

图2是示出在例如P2P网络的计算网络的第一用户和第二用户之间建立因果关系或信任关系的方法的一个实施例的顺序图；

图3是示出根据本发明的评估反馈的方法的一个实施例的流程图；

图4是示出根据本发明的评估反馈的方法的一个实施例的流程图；和

图5是使用通用计算装置实施的信任关系建立方法的高度框图。

为了便于理解，在尽可能的情况下，使用相同的标号，以指定对于附图共用的相同元素。

具体实施方式

在一个实施例中，本发明是一种建立P2P因果关系和信任关系的方法和设备。本发明的实施例使得网络的用户基于其它方所提供的关于其它网络用户的反馈检测其它网络用户的可靠性(或缺乏可靠性)。因此，网络用户可以在加入与另一用户的事务(例如，买/卖事务)之前确定是否值得冒险与这个相对匿名的其它用户进行事务。这样可以辅助网络用户减少他们参加的不满意或其它不利事务的次数。此外，反馈以基本防止伪造或篡改的方式保存，并且在不需要使用中心服务器的情况下进行，从而反馈“满足”从应用到应用或从网络到网络的用户。

本发明的实施例依赖于公共密钥和私用密钥的使用，例如由公知的认证机构(例如，客户端软件公司或网络创建者)提供的密钥。

图2是示出在计算网络(例如P2P网络)的第一用户201和至少一个第二用户203之间建立因果关系或信任关系的方法200的一个实施例的顺序图。具体地，方法200出现在买/卖事务的示例性环境中。在买/卖事务的环境中，第一和第二用户201、203中的一个是买方，另一个卖方。

根据方法200的事务包括3个主要阶段：提交阶段213、事务阶段214和完成阶段215。在提交阶段213中，第一用户201和第二用户203同意事务的处理。在事务阶段214中，以(例如，用于数字物品或服务的)在线方式或(例如，用于非数字物品或服务的，通过邮件的)离线方式实际发生所同意的事务。在完成阶段215中，第一用户201和第二用户203发出关于所完成事务的反馈。

当第一用户201将事务“封包”(例如，包括事务细节的消息，例如，买方买什么或卖方卖什么)发送到第二用户203时，在步骤205中启动提交阶段213(和相关的事务)。在一个实施例中，在事务封包中包括的细节包括以下至少一个：第一用户的认证证书、第一用户的公共密钥、第一用户的事务ID、事务的日期、事务的类型(例如，有形物品、无形物品、汇款等)、在事务核心的物品或服务的描述和支付细节(例如，物品或服务的成本、邮寄和处理、保险、邮寄和帐单地址等)。由第一用户201使用第一用户的私用密钥签署事务封包。使用私用密钥签署事务封包基本保证了由第一用户201提供的信息不能伪造。

在步骤207，第一用户201从第二用户203接收附加事务封包。附加事务封包(例如，使用第一用户的公共密钥)验证了在步骤205中发送的原始事务封包中提供的事务细节，并且还包括向原始事务封包中提供的事务细节进行增加。具体地，附加事务封包包括第二用户203所需的细节。在一个实施例中，附加事务封包包括以下至少一个：第二用户的认证证书、第二用户的公共密钥和事务的进一步描述或需求。由第二用户203使用第二用户的私用密钥签署附加事务封包(即，包括由第一用户201提供的事务细节和由第二用户203提供的事务细节的整个事务封包)，因此变成完整事务封包。使用私用密钥签署完整事务封包基本保证了由第二用户203提供的信息不能伪造。第一用户201使用第二用户的公共密钥验证向完整事务封包的第二用户的增加。为了用户观察完整事务封包的全部内容，需要第一用户的公共密钥和第二用户的公共密钥。公共密钥可通过通用的密钥分发技术可用，或可附加于事务。

一旦由第一用户201和第二用户203签署了完整事务封包，则提交阶段213结束。然后，根据在事务核心的物品或服务(例如，数字或非数字事务或服务)的特征，基于已知的在线和/或离线方法开始事务阶段214。

一旦事务阶段214完成，则完成阶段215开始。当一个用户(例如，第一用户201或第二用户203)启动与其它用户的反馈交换时，完成阶段215开始。在图2中所示的实施例中，第一用户201通过将包括反馈的完整事务封包发送到第二用户来启动反馈的交换。反馈涉及使用(例如，如至少事务阶段215中具体化的)事务是如何满足(或未满足)的第一用户201的。由第一用户使用第一用户的私用密钥签署完整事务封包(即，包括由第一用户201提供的事务细节、由第二用户203提供的事务细节和第一用户的反馈的完整事务封包)。使用私用密钥签署事务封包基本保证了由第一用户201提供的信息不能伪造。

在步骤211，第一用户201从第二用户203接收完整事务封包，现在还包括第二用户的反馈。现在，由第二用户203使用第二用户的私用密钥签署完整事务封包(即，包括由第一用户201提供的事务细节、由第二用户203提供的事务细节、第一用户的反馈和第二用户的反馈的整个事务封包)，因此变成最终事务封包。因此，第二用户203除了提供他/她自己的反馈之外还辨别第一用户的反馈。使用私用密钥签署完整事务封包基本保证了由第二用户203提供的信息不能伪造。可选择地，第二用户203可通过作为第一方提供反馈以及将包括反馈的完整事务封包发送到第一用户201来启动完成阶段215。在一个实施例中，反馈不认为是有效的或可靠的，直到由第一用户201和第二用户203两者签署了最终事务封包为止。

这样，为了在将来可以与用户进行事务的多方利益，可保存在网络中与用户事务和行为相关的反馈，而不需要使用中心服务器。因此，例如，如果第三用户(未示出)识别出销售第三用户正在搜索的产品的多个其它用户，则第三用户至少部分地基于其它用户的先前所证明的可靠性确定从哪些其它用户购买产品。例如，如果第一用户201是多个用户中的一个，第三用户可从第一用户201和/或第二用户203获得用于先前所述事务的最终事务封包(其包括反馈)。该反馈可辅助第三用户确定他/她是否喜欢进行与第一用户201的事务。此外，以这种方式保存的反馈可“满足”其相关用户他/她所在的网络——因此，反馈不必是特定应用或特定地点的。

在一个实施例中，(例如，如提交阶段213中提供的)事务细节的一个或多个字段可加密，或保持空白，以保持信息的保密性。此外，不同的信息字段可具有不同的安全级别。例如，如果在向其它用户提供最终事务封包时，第一用户不期望他或她的地址出现在纯文本中，则第二用户203可使用第一用户的公共密钥对第一用户的地址加密。然后，第一用户201可使用她或她的公共密钥观察该信息。当向其它用户提供最终事务封包时，其它用户将能够观察至少反馈，并且也可能观察某些事务细节，但是不能够观察第一用户的地址。

如上所述，在提供信息或反馈的每一个阶段使用私用密钥签署事务封包基本保证了其中包含的信息或反馈不能伪造。由于最终的反馈需要由事务中涉及的所有方(使用公共密钥和私用密钥)签署，所以不能由用户产生虚假正反馈。此外，因为方法200需要两个用户在提交阶段213同意事务，所以关于用户的虚假负反馈不能伪造。此外，由于通过事务ID、第一用户密钥和第二用户密钥三者唯一识别任意事务，所以负反馈不能被(例如，将新事务与给出负反馈的先前执行事务的ID关联)复制事务ID隐藏或遮掩。

在一个实施例中，在第一用户201和第二用户203之间的事务完成以满足两个用户(例如，第一用户201和第二用户203两者发出正反馈)的情况下，最终事务封包被第一用户201和第二用户203两者保存，以用于未来参考。因此，第一用户201和第二用户203分别可提供最终事务封包，作为与他或她交互的未来多方的参考(例如，在买/卖事务中的未来买方或卖方)。正反馈证明没有遇到关于相关事务的问题，以及提供最终事务封包的用户已经建立了某种程度或等级的可靠性。

在另一个实施例中，在第一用户201和第二用户203之间的事务没有完成以满足两个用户(例如，第一用户201和第二用户203中的一个或两个发出负反馈)的情况下，最终事务封包被发出负反馈的一个或多个用户保存。例如，如果第一用户201不满足该事务，则第一用户201将保存最终事务封包并将最终事务封包提供给寻找关于第二用户203的信息的其它用户(例如，潜在寻找与第二用户203进行事务的用户)。负反馈证明遇到了关于相关事务的问题，以及提供最终事务封包的用户在与最终封包涉及的其它用户处理的过程中明显需要小心谨慎。

在另一个实施例中，在网络中的某些节点可设计为事务存储节点。事务存储节点(例如，通过存储最终事务封包)保持事务的记录，从而使得事务记录分布式存储在网络中。事务存储节点可以是具体存在的用于存储事务记录的专用节点，或者他们可以是执行存储事务记录的附加任务的用户节点。在一个实施例中，网络用户向事务存储节点提供最终事务封包的副本，从而事务存储节点可以将最终事务封包提供给寻找关于某些其它用户的反馈的其它用户。事务存储节点可以有利地配置在瞬态网络中，例如P2P网络，其中所有用户在所有时刻都不可用。

在另一实施例中，反馈可被更新，例如，以解决可导致提供负反馈的任何问题。在一个实施例中，可以将为一个事务更新反馈的次数设置为固定数目。在一个实施例中，固定数目足够大，以使得用户解决可导致提供负反馈的问题，但是也足够小，以保证用户不继续发出反馈或不确定地冲突。

图3是示出根据本发明的用于获得反馈的方法300的一个实施例的流程图。例如，当第一用户考虑与第二用户进行事务，并希望首先确定第二用户的可靠性时，可以实施方法300。

方法300在步骤302初始化，并且进行到步骤304，其中方法300直接向第二用户查询关于第二用户的反馈(例如，第二用户从先前事务保存的最终事务封包)。在步骤306，如果第二用户提供任意反馈，则方法300从第二用户接收所请求的反馈。在一个实施例中，在用户仅保存向他或她作出肯定反应的最终事务封包的情况下，因此，方法300在步骤306从第二用户接收0条或多条正反馈。

在步骤308，方法300确定是否有必要(例如，从其它来源)获得关于第二用户的更多反馈。在一个实施例中，基于用户的偏好，作出关于其它用户的确定所需的反馈的量是可调节的和/或用户可定义的(例如，“需要n条反馈进行确定”)。如果方法300在步骤308确定具有了期望或需要的关于第二用户的所有反馈，则方法300在步骤314终止。

可选择地，如果方法300在步骤308确定应该获得更多关于第二用户的反馈，则方法300进行步骤310，并向其它用户节点和/或事务存储节点查询关于第二用户的反馈。如果任意这种反馈存在，则方法300在步骤312从其它用户节点和/或事务节点接收关于第二用户的反馈。因此，方法300在步骤312从其它用户节点和/或事务存储节点接收0条或多条正反馈，以及0条或多条负反馈。然后，方法300在步骤314终止。

图4是示出根据本发明的用于评估反馈的方法400的一个实施例的流程图。具体地，方法400是验证最终事务封包的内容的方法。例如，在第一用户已经(例如，从第二用户或一个或多个其它用户)获得关于第二用户的(以一种或多个最终事务封包的形式的)反馈之后，可以实施方法400。

方法400在步骤402初始化，并且进行到步骤404，其中方法400选择(例如，根据方法300接收的)最终事务封包用于验证。选择的最终事务封包包含与第二用户涉及的先前事务相关的信息。

在步骤406，方法400识别所选择的最终事务封包的最新增加的、未经验证的部分。通过未经验证，标识第一用户还没有浏览该部分的内容。

在步骤408，方法400将增加所识别部分(即，最新增加、未经验证部分)的用户的公共密钥应用于识别部分，以“打开”所识别部分，从而可以观察其内容。

在步骤410，方法400确定是否剩余最终事务封包的任意未经验证部分。如果方法400在步骤410断定剩余至少一个未经验证部分，则方法400返回步骤406，并如上所述继续，以打开最终事务封包的最新增加、未经验证部分。因此，方法400通过在每一个步骤应用增加相关部分的用户的公共密钥，以从最后部分开始(即，最新增加部分)并且向后朝向第一部分工作的方式打开最终事务封包的部分。

或者，如果方法400在步骤410断定没有剩余最终事务封包的未经验证部分(即，所有部分已经验证)，则方法400进行步骤412，并确定最终事务封包的任意部分是否验证失败。在这个阶段，如果通过适当用户的公共密钥已经通过验证了最终事务封包的所有部分，则可以确定，在最终事务封包包含所有期望信息的情况下，最终事务封包是“完整的”。

如果方法400在步骤412确定最终事务封包验证失败一个或多个部分，则方法400在步骤414断定最终事务封包没有通过验证。或者，如果方法在步骤412确定最终事务封包没有任意部分验证失败，则方法400在步骤416断定最终事务封包通过验证。然后，方法400在步骤418终止。

图5是使用通用计算装置500实现的信任关系建立方法的高级框图。在一个实施例中，通用计算装置500包括：处理器502、存储器504、信任关系建立模块505和各种输入/输出(I/O)装置506，例如显示器、键盘、鼠标、调制解调器等。在一个实施例中，至少一个I/O装置是存储装置(例如，盘驱动器、光盘驱动器、软盘驱动器)。应该理解，信任关系建立模块505可以作为通过通信信道与处理器耦合的物理装置或子系统实施。

或者，信任关系建立模块505可以通过一个或多个软件应用表示(或，例如，使用专用集成电路(ASIC)的软件和硬件的组合)，其中软件从存储介质(例如，I/O装置506)加载，并且在通用计算装置500的存储器504中通过处理器502操作。因此，在一个实施例中，在参照先前附图的这里所述的计算网络中用于建立信任关系或因果关系的信任关系建立模块505可以存储在计算机可读介质或载波上(例如，RAM、磁或光驱动器或盘等)。

因此，本发明代表了计算网络领域的明显改进。提供一种方法和设备，使得网络用户能够基于其它方所提供的关于其它网络用户的反馈检测其它网络用户的可靠性(或缺乏可靠性)。因此，网络用户可以在加入与另一用户的事务(例如，买/卖事务)之前确定是否值得冒险与这个相对匿名的其它用户进行事务。这样可以辅助网络用户减少他们参加的不满意或其它不利事务的次数。此外，反馈以基本防止伪造或篡改的方式保存，并且在不需要使用中心服务器的情况下进行。

尽管上文涉及本发明的优选实施例，但是可以在不脱离本发明的基本范围的情况下设计本发明的其它和更多实施例，本发明的范围由所附权利要求确定。