CN102365648B - 用于管理数字式互动的系统和方法 - Google Patents

Abstract

一种用于管理数字式互动的系统，其包括：用于创建身份的身份模块，其中身份包括与第一方相关联的唯一的标识符，用于与第二方的关系的多个被提议的条款；及关系模块，其与身份模块通信，用于接收和评估所述多个被提议的条款，包括接受或拒绝所述多个被提议的条款，如果接受，则根据所述多个被提议的条款允许所述第一方与所述第二方通信。

Description

用于管理数字式互动的系统和方法

技术领域

本发明一般涉及方便社会交际，更具体地，涉及提供关于人和实体之间关系的结构的系统。

背景信息

在哑终端时代，每个用户得到登录ID和密码。其用于连接到主机并被映射到被集中管理的特定权限。这是一种非常好的安排，因为要求某种权限的用户取得被授予的权限，并最终能够访问某些主机资源。这实际上没有副作用。

随着客户端/服务器架构的发展，相同的、登录ID和密码的概念得以延续，但现在有许多网络，每个网络都有他们自己的配给登录ID和密码的策略。仍然要求每个用户请求某种权限，获得被授予的权限，并且取得访问权。但是现在必须对许多系统重复该过程，并且记住每个系统的用户ID和密码变得麻烦，不过不用担心记住用户在每个系统上具有的具体权限。

在这方面，各种身份管理(IDM)产品开始出现，以使创建ID和密码的过程更加简单，并提供更为集中的权限管理。所有这些看起来是一件好事，且只要将IDM的范围保持在单个企业内，这将对用户提供显著的优势，即几乎没有不需要的副作用。大部分企业提供了改变和复查权限的方法，尽管该过程较为不方便，但其在封闭式企业环境的背景下是足够的。

随着因特网的出现，用户的连接世界突飞猛进地扩大。现在每个用户都拥有许多身份：他们在工作中的角色，作为银行顾客、作为父母、作为学生，等等。但遗憾的是，对标识符和权限的管理并没有以相同的方式发展。配给登录ID和密码的过程简单地转移到互连网上的个别的域(AOL、Yahoo、MSN，等等)中，身份的概念变为一个单向的过程——用户提交信息并取回完全由第三方定义的身份。这导致事务的当前状态为：用户实质上已放弃了她的隐私权，第三方能够不经用户同意随意搜集该用户的个人信息。

需要一种通过其用户能够自由协商权力和隐私的系统，其以对所有的联网互动都将一致奏效的方式进行协商。

发明概述

本发明体现匹配新的互联网世界的身份的概念。本发明把用户重新置于控制地位，其使用的访问资源的过程围绕着对双方同意的条款的协商，该协商对于每个关系都是非公开的且唯一的。旧的标识符成为一种关系双方一致认可的协商架构，但对于任何第三方则完全不透明。用户现在位于她建立的每一关系的一端，而且复查条款(或访问和更新根据那些条款共享的信息)变得像打开她的电子地址薄一样简单。

关系联络代理商(RNA)将该示范扩展到在逻辑上补充的阶段：关系的存在是出于交换信息的目的。信息交换很少基于条款和条件的静态集合。而是这些交换随时间不断变化，并且条款随着交换改变。这意味着所有信息实际上是动态过程的完整的一部分，其定义在复杂关系的背景下发生的不断变化的对话的条款。根据本发明的RNA架构使这些复杂的互动明确、可管理和安全。

受管理的数字式互动的一个方面是相互性。每个关系的条款是双方同意的并且能够协商的。隐私作为这些条款的一部分被包括进来。

受管理的数字式互动的另一个方面是互连性。这通过提供相互地和全球工作的互动来实现。由于知识很大程度上是连接数据的结果，所以这趋于增加知识。

受管理的数字式互动的另一个方面是允许对话随时间不断变化，而在对话中传达的信息仍然由关系的条款定义。

受管理的数字式互动的另一个方面是主动认证。认证是主动事件，但不需要保持为过去认证的“快照”不变。互动的原则允许随时间改变和基于背景改变。

根据本发明，为了使结果有效，有三个需要遵循的检验标准的概念。首先，建立协商安全通信渠道。其次，建立动态的合作网络。再次，动态决定合作协议。

从优选的实施方式的详细描述，本发明的这些和其他的特征和优点对本领域技术人员来讲将变得更加明显。以下将描述随附详细描述的附图。

附图简述

图1是示出根据本发明的示例性实施方式的实体的框图。

图2是示出用户的示例性关系的示意图。

图3是示出两个实体达成合约协议的示意图。

图4是示出将一个实施方式应用到卫生保健业的示意图，其中用户为医院的病人。

图5-11公开了在各种背景下协商实体的各种步骤。

图12和13公开了对背景敏感的关系的例子。

详述

在以下示例性实施方式的讨论中，术语“实体”用于指示控制数字式互动的、人和机器之间的关系。

在任何商业交易中，必须控制对资源，诸如应用和信息系统的访问。该控制通过确定由包括身份的一组属性描述的主体是否被授权访问所要求的资源，然后授予他们权限来执行。也通过合约协议和背景(例如，对某些文件的访可能被限制在特定的安全区域)来控制权限。

由于商业机构开放他们的基础设施，并将他们的网络和应用扩展到包括客户、合作伙伴和供应商，这使其面临一种基本的断开(disconnect)原则：当前没有一种标准化的方式来“信任”或以中间人的身份安排属于合作伙伴和其他外部用户的身份。于是出现了联合的身份解决方案，但当机构希望将他们的网络扩展到大量的经常来往的小型合作伙伴时，这些联合的身份解决方案被证明实施起来较为困难且成本较高。

问题的核心在于信任问题：期望机构提前建立所有可能的信任关系简直是不现实的。需要仅为所需量的时间仅建立适当量的信任，而不是过多量的信任的方式。建立和破坏这些关系必定和发送电子邮件消息一样容易，但它也应当提供完备(bullet-proof)的安全性和责任性。

密钥管理使用与在传统的公共密钥基础设施中使用的相同技术(即，本发明的实施方式不试图改进已被证明了的加密技术)中的一些。然而，使用本发明的实体管理密钥的过程是非常不同的。

密钥管理是密码学最难的部分。通常有两类密钥，即短期密钥和长期密钥。短期会话密钥(有时称为短暂密钥)通常被自动地且不可视地生成。它们用于一则消息或会话并被丢弃。长期密钥由用户明确地生成。它们用于认证(包括访问控制、诚实和不可拒绝)和保密(加密)。长期密钥也用于建立会话密钥和保护存储的数据。

本发明的实施方式被设计为使用所需要的最少量的外围基础设施完全透明地处理短期密钥和长期密钥。通常仅在最初的提供过程要求进行认证和验证，因此大大地减少了第三方参与交易的次数。

对于大部分的提供和认证功能，一些实施方式依赖于对到简单邮件传输协议(SMTP)和可扩展的通信和表示协议(XMPP)的简单协议扩展，允许参与者通信的服务器处理大部分的交易，而所述交易使用公共密钥基础设施通常导致可扩展性问题。

本发明的实施方式提供了灵活的密钥鉴定框架。有许多为了证实密钥不需要第三方的情况(例如小型商业的情况，参与者是建立的关系的一部分的)。在一个实施方式中，本发明有效去除了公共密钥的观念。取而代之的是，实体嵌入了关于每个关系的唯一的密钥对，这具有许多好处。获得其他人的公共密钥像发送邮件以便提议关系一样简单。没有涉及公共密钥——自动提议关系创建专门关于该关系的新公共密钥。

本发明的实施方式提供了内置的保密性和认证。对于保密(即，只与预期方共享信息)，实体嵌入只能被预期的接收者读取的加密材料。该机制可被扩展，以便应对不断变化的安全要求。关于认证(即，与预期方共享信息)，实体能够利用带外认证机密，它们也能够使用身份验证权威，如Equifax。

本发明的实施方式可被用于设计能够像电子邮件地址一样被管理的实体。它们能够存储在地址簿、活动目录、或其他适合的库中。由于没有公共密钥，也不需要复杂的废弃机制。实体可被废弃，这通过将其删除并可能地配给一个新的实体。

本发明的实施方式可被配置为应对泄露(compromise)信息导致的影响。关于认证，除非加有时间戳，否则将使已签字的文件无效。为了应对这种情况，可以重新认证(产生新的实体)且文件可以通过双方同意被重定密钥。关于保密性，使用被泄露的实体加密的所有数据都被泄露。然而，该作用被严格限制到受影响的关系，使得对受影响的材料重定密钥相当地简单。

实体是一个按照明确的相互协商/管理的协议定义对基于关系的身份进行创建和管理的框架。身份最初以URI或电子邮件地址的形式来表示，其中电子邮件地址包含带有被提议条款的概要和数字签名的唯一加密身份——其结果称为实体。一个实体能够正好像规则的邮件地址一样使用。实际上，建立基于实体的关系的默认方法是简单交换电子邮件。然而，本发明的实施方式不限于这种交换方法。建立实体的过程可以在任何适合的传输机制中发生。

实体仅用于建立最初的协议以进入一个关系。关系的实际条款通过基于工作流的代理商，被称为NetRNA(网络关系网络代理商)来进行协商。NetRNA是条款的体现和实施。除非身份是在关系的背景下定义的，否则其没有实际意义。

例子

图1示出了示例性的实体。用户Alice和Bob均具有一个身份以及与他们各自的公司相关的角色。在他们的企业的背景中，这些用户也具有彼此之间的协商关系。参考图2，本发明的实施方式可用于在她与其雇主的关系的背景下创建和管理关于人力资源经理的数字式互动。如果Alice是ABC公司的人力资源经理，那么在她与ABC公司的关系的背景下，她的作用可包括雇用雇员、管理福利计划、并与其他公司达成某些协议诸如雇用一个分包商(例如，Bob)。本发明的实施方式可用于定义可分配给Alice和被Alice接受的身份(例如，Alice-ABC公司的HR经理)。然后在其作为人力资源经理时，该身份可被用于管理和实施Alice与ABC公司的关系的条款。其使用的访问资源的过程围绕着对双方同意的条款的协商，该协商对于每个关系都是非公开的且唯一的。

本发明的实施方式允许Alice访问的资源围绕对双方同意的条款的协商，该协商对于每个关系都是非公开的且唯一的。旧的标识符成为一种关系双方一致认可的协商架构，但对任何第三方则完全不透明。Alice现在位于她建立的每一关系的一端，而且复查条款(或访问和更新根据那些条款共享的信息)变得像打开她的电子地址簿一样简单。

关系的存在是出于交换信息的目的。此外，信息交换很少基于条款和条件的静态集合-而是这些交换随时间不断变化，并且这些条款随着交换改变。例如，合作写一本书具有许多阶段，其涉及在该过程的各个点上的不同的人。这意味着所有信息实际上是动态过程的完整的一部分，其定义在复杂关系的背景下发生的不断变化的对话的条款。根据本发明的关系联络代理商(RNA)架构使这些复杂的互动明确、可管理和安全。

用于Office 2007文档的开放式XML规范，和Windows工作流基础(WWF)和Windows通信基础(WCF)的近期发布为本发明的实施方式提供了进一步的加强。开放式XML格式限定了由部分和关系构成的文档的内部框架。根据一个实施方式，实体表示了关系的条款。通过将开放式XML文档中的关系的定义进行扩展，以包括一个实体，如这里所述，可创建表示包含多个相关关系的复杂商业协议的文档。以这种方式创建的文档能够将管理对文档中的每一部分的访问的条款嵌入，且各种部分可表示非常具体的原则和权限。例如，保留顾问的合约能够嵌入具体的权限，该权限将建立到打印机、共享资源、日历视图，等等的访问。当与WWF和WCF组合时，可基于能够安全地跨机构分布的丰富的工作流来创建表示动态关系的文档。

图3是示出了根据一个实施方式的情况的示意图，其中ABC公司决定与XYZ公司达成关于开发新的软件应用程序的临时职位的合约协议。在图3中，我们假设Alice和Bob已经建立了由实体所定义的最初关系。在处理协商要求(保密性、可查证性，等等)的协商过程期间创建了新的实体，一旦协议达成将创建实体来表示最终的条款。一个典型的情况将涉及协商服务的协议，然后在ABC公司环境中提供一个新用户以允许XYZ公司的订约人访问ABC公司内的所需资源。该职位将要求创建新的实体。与该缔约机构的任何关系从该过程断开，并且如果这在长时间周期内对许多合作伙伴重复该过程，则其结果是在今天的大多数机构中发现的那种混乱无序。联合的身份解决方案必须在企业内部和跨企业地管理完整的用户生存周期。这意指用户和账户创建、账户连接、认证、访问控制和账户终止。一旦考虑到身份联合，则需要评估与联合有关的事项，即谁将参与、它将怎样管理、以及联合的参与者必定承担什么类型的风险。

本发明的实施方式通过扩展定义了协议的自然商业过程来消除这个问题，使得满足该过程所需要的资源和权限被分配并永久地与协商的最终产物相关联。实际上，与合约相关的资源和权限的整个生命周期都依赖于它，并因此是自描述的而且在很大程度上是自管理的。

图4是示出了根据一个实施方式的来自卫生保健行业的情况的示意图，其中Jane是医院的病人。其涉及了关系和隐私原则的复杂集合。使用本发明的实施方式，可以简单且有效地处理这种情况，而同时完全保持所要求的隐私和保密性的级别。例如，Jane的医生可以访问Jane的诊断结果，但医院的计费部门只能看到产生账单的所需细节——而不是实际的诊断结果。实际上，使用了根据本发明的实施方式的实体以及开放式XML文件格式的患者记录能够实施强有力的安全措施，诸如在能够访问或共享某些信息之前要求Jane的明确许可。也能够非常容易地实现自动跟踪特性。

本发明的某些实施方式的目的是使安全简单化。安全、隐私和访问控制应该像发送电子邮件、复查文档，等等一样简单和自然。实施方式开始的前提是，对于在定义了身份的关系中所涉及的各方而言，该身份是非公开的。身份的建立是非公开的、安全的协商的结果。一旦经过了协商，本发明的实体能够在协商阶段中同意的期间内提供到NetRNA的访问——没有废弃机制且只有关系所涉及的各方能够改变条款和彼此认证。本发明的实施方式还提供了一种机会，即将空前的保密级别与关系所涉及的各方的责任进行平衡。每一关系包含唯一的密钥；在关系之间不可能有交叉引用。通过将实体扩展到开放式XML文档，有可能无缝地处理最复杂的关系，该关系包括涉及具有复杂的相关原则的多个方的情况。

图5-11公开了在各种背景下协商实体的各种步骤。

图12和13公开了对背景敏感的关系的例子。

实体框架方便了集合性的知识的研究和表示。它包括模块化的部件结构和安全通信。最后，所有富有意义的数字式互动涉及在个人(作为一角色)和一个或多个代理商之间的、围绕某一目的的给-和-收行为。知识作为这些给-和-收行为的结果而出现。

参考图14，示出了该过程的概念图。如上所示，方便特定互动集合的协议的实现通过关系联络代理商(RNA)体现。

实体结构基本上是分布式网络，其被设计以方便关系联络代理商(RNA)的例证和管理以通过目的驱动的追踪(pursuit)的互连来组合丰富的、全球的、集合性知识网。

最终产生的集合性知识能够以实体形式被形式化。通过将能够为一个代理商或一群代理商而存在的概念和关系形式化，实体对知识进行编纂。

当RNA基于谈判的目的创建互连时形成动态网，其中集合性的知识以目的驱动向量而非传统的数据提取的形式来表达。这在图15中示出，其示出了通过关系联络代理商(RNA)网络的协商遍历路径(箭头)。实体是到知识的目的驱动路径，其中所有的参与者都积极地合作。

在实践中，其意味着软件代理商的全球网状网络能够在知识的集合性发展中安全地进行通信和参与。由角色的一个或多个对象出于同意的目的访问每个代理商。

实体SDK提供了用于配置关系联络代理商的网状网络和必要的安全通信基础设施的基本构造，以便允许通过全球RNA网来协商和管理实体。

本文档的其余部分重点关注由实体SDK(安全数字密钥)提供的、使本文所描述的概念可行的特殊能力。

实体SDK具有在以下段落中描述的技术特征。

相关密钥：在实体结构中的安全模型的基本构建块。在本质上，其集中在使用椭圆曲线密码术(ECC)，和经过很好的证明的、与所有人的技术组合的、非对称加密技术，以便根据同意条款来递送仅由预期一方(或多方)使用的密钥。相关密钥提供了无状态的验证，并且对于大多数情况而言，它们也消除了对密钥拒绝的需要。相关密钥也嵌入了一些受限的条款以方便密钥管理。

动态数字协议：一旦建立安全的通信渠道仍然存在着问题，即要如何应对关于其与协议趋于随时间不断变化的现实。动态数字协议是一个电子协商和实施的框架，其允许用户和系统相互协商可接受的条款，并随后自动地实施它们。该框架构建在相关密钥的基础上，以便提供在能够定义的协议类型上的、非常高级别的灵活性，且如果需要协议能够随时间不断变化。

通用角色结构：实体结构认可人们倾向于承担各种角色这一事实。为此，该结构围绕基本的构造：角色来进行组织。角色被定义为由一个实体承担并由另一个实体拥有的协议(以接受某些权力和责任)。当角色的拥有者和承担者相同时，我们具有角色被称为自然身份的角色的特殊情况。普通角色被实现为实体，但自然身份具有唯一的设计特征且被称为MI As。该角色结构意味着个人(通过MIRA表示)能够承担跨任何数目的机构的多个角色。

安全通信：基本的实体结构不提供传输层安全特征(例如，源和目的地址的混乱)。主要焦点在于保护信息的内容。实体SDK提供了用于各种类型的通信安全的扩展性支持。密钥安全通信特征包括基于关系的加密、嵌入式的使用控制、权利管理、访问位置控制，等等。在有非常高的安全要求的背景下，和甚至作为安全路由基础设施的一部分也具有对配置实体安全通信特征的选择，但这些特征不包括在实体SDK中。

跨组织的工作流：无缝地越过防火墙和合作机构扩展实现应用的能力，并且完全安全。实体SDK提供了创建和管理完全跨防火墙和网络运行的工作流的能力——最终的工作得到控制。

记录和实例水平数据库安全：使应用能够包括存在于内部和外部网络中的数据源、系统和用户数据。提供高水平的安全和加密一直到属性和应用存储器的目标水平，并跨网络执行那些权限。

无国籍许可：复杂的用户的许可能力，其不需要复杂和昂贵的服务器基础设施，同时允许几乎无限的、定义适合任何商业配置情况的许可证条款的能力。

该基本概念具有非常广的应用范围，其范围从个人-到-个人的安全通信，到越过防火墙的商业-到-商业过程，等等。本文档的接下来的几部分探究几种通常的综合情况。

根据本发明，为了使结果有效，有三个需要遵循的检验标准的概念。首先，建立协商安全通信渠道。其次，建立动态的合作网络。再次，动态决定合作协议。

建立安全通信渠道

建立安全通信渠道的过程围绕相互协商的过程。在一个典型的例子中，Alice希望与Bob建立安全的通信渠道。

Alice连接到她的联络代理商。这是一个能够依靠本地机或远程访问的工作流代理商。与联络代理商的通信一直被加密，并且只有Alice能够使用她自己的联络代理商创建新的连接。联络代理商处理对通信渠道、政策和Alice的变化的偏爱的管理。联络代理商的用户界面能够为网页，但其也可以与普通生产率应用，诸如电子邮件无缝地结合。

Alice决定她愿意向Bob公开哪些凭证。被提供的凭证可包括由第三方提供的、用于证明他们的有效性的安全标志。典型的凭证能够是电子邮件地址、专业的会员、或Bob能够验证且Alice愿意公开的任何其他证明。在Bob满足了Alice在验证Bob身份的下一步骤将建立的要求后，该凭证包将只有Bob可以访问。

Alice现在决定她将从Bob要求哪些凭证。Alice提供了她自己对于将被使用的凭证的评价。这是一套Bob在访问由Alice提供的凭证前将必须能够正确回答的问题和答案。Alice至少必须提供接收者的地址——这是将用于发送请求的地址。

Alice提出通信渠道的属性。基本属性包括截止日期、加密要求、渠道是否能够被更新，等等。属性可以扩展，但在通信渠道中它们必须可表示为绝对值，且一旦渠道相互同意，它们将是不可取消和不可变的。

联络代理商现在创建新的随机密钥对(Ksalice和Krbob)并准备渠道请求包。

对Alice愿意与之通信的每一方重复该过程。由于使用的凭证是每个渠道中的身份的组成部分，对Alice而言可能有和使用不同凭证的相同接收者的多个渠道。

联络代理商试图发送请求。如果接收者已经使用相同的技术，则接收者地址是接收者的联络代理商的即时通信地址。在接收者不具有该技术的情况下，请求以含有指令的电子邮件或即时消息的形式发出，并且将自动为接收者将新的联络代理商实例化(instantiated)。此处要注意的是，对于要从联络代理商发送出的信息而言有可能不要求接收者成为任何通信渠道的一部分，但这不是这里描述的情况。

Bob的联络代理商接收该请求。该请求由Alice的域所标记，并能够通过证书权威进行公开地验证。

Bob的个人策略(Policy)被激活并开始处理该请求。在随后的步骤中，对Bob而言有可能手动处理该请求，或他的个人策略能够含有将允许该请求的整个处理自动进行的原则。

Bob检查由Alice提出的问题。这时Bob只知道有人请求通信渠道。如果Bob愿意继续向前进行，则使用Diffie-Hellman协议进行密钥交换且在协商的持续期间交换加密密钥。

如果Bob决定他不愿意回答Alice提出的问题，他能够拒绝该请求，并可选地提供一个理由给Alice。如果Bob决定回答问题，则回答的整个处理仅在Bob的联络代理商处发生。

Bob回答来自Alice的问题，并且他检查由Alice提议的条款。

创建Bob的答案的散列(hash)并使用协商的密钥进行加密。Bob现在还决定所提议的条款是否是可接受的且可选地可提议其他条款。散列(和任何所提议的对条款的改变)将发回Alice。

Alice解密散列并将其与在创建请求时预先计算的散列进行比较。如果它们匹配，则Bob对Alice公开的要求感到满意。如果它们不匹配则协商失败。

如果Bob提议了可供选择的条款，Alice能够接受它们、拒绝它们和做出可供选择的提议。如果做出了可供选择的提议，该提议将被发回Bob用于进行接受，并且条款协商继续进行直到双方同意或任何一方终止协商。

如果协商成功，Alice发送Krbob给Bob。

Bob接收Krbob，并且他创建他自己的新密钥对(Ksbob、Kralice)。然后他发送Kralice给Alice。

Alice和Bob现在交换了一起作为双向安全通信渠道的基础的两对密钥。

建立安全通信网络

一旦存在安全通信渠道的网络，接下来的逻辑步骤是能够利用这些渠道创建动态合作网络。例如，让我们看一下下面的合作性网络：

Angela想与慢性病专家Blanchard医生预定一个约会。Angela的保险范围(Health Plus)规定与专家的约会必须通过她的初级护理医师(PCP)Jones转诊。Angela的策略也规定PCP仅能转诊到由保险提供方认可的专家。

在这个例子中，我们假设所有的各方都建立了联络代理商，且根据需要通信渠道已成功协商。

在过程开始时以下连接已建立：

Angela-Jones医生-的病人

Angela-Health Plus-的成员

Jones医生-Health Plus-的网络的医师

Blanchard医生-Health Plus-的网络的专家

此处是在该背景下动态合作协议是如何展开的(在该情况中，联络代理商是其拥有者的在线化身，在提到个人的大多数情况中，能够假设这是联络代理商基于来自拥有者的直接行动或嵌入在联络代理商中的已编辑为脚本的权限来采取行动)：

1.Angela请求Jones医生转诊。该过程像发送由Angela的联络代理商自动路由给Jones医生的电子邮件一样简单地发生。由于Angela是病人，存在已有策略，在其中适当的位置描述了当与Jones医生通信时Angela能够做什么。在该例子中，当Angela发送她的电子邮件时，该消息被自动认证为来自于Angela，而Angela则在适当的策略中被自动援引。

2.一旦消息被Jones医生的联络代理商接收到，Angela的通信权力已建立，则消息中的实际请求被处理。在这种情况下，可能的过程或许会涉及Jane，即查看该消息的、Jones医生的助手。Jane已被授权访问Jones医生的联络代理商，且她可访问Angela的医疗记录中的有限的一部分。这允许Jane看到Jones医生已经做出了关于将Angela转诊给专家的记录。

3.Jane现在需要找到一位可与之联系的专家并满足Angela与HealthPlus的策略的条款。这时Jones医生从Angela请求获得权限以访问她与Health Plus的策略。

4.一旦被授予权限，Jones医生与Health Plus联系，以便基于Angela的医疗需要和她的策略请求可与之联系的专家的列表。

5.Health Plus接收请求并创建可能的专家的列表。在将列表返回Jones医生前，Health Plus请求来自每位专家的许可。只有回应为可与之联系的专家将被返回给Jones医生。

6.通过Jones医生的联络代理商，Jane现在有了可与之联系的并且愿意见Angela的专家的列表。在这次交换期间，也可以交换额外的信息，诸如可能的约会次数。

7.Jane现在能够选择具体的专家或返回列表给Angela。

8.Angela接受转诊并选择Blanchard医生。一条新的通信渠道在Angela和Blanchard医生之间协商，并将该选择通知Jones医生。

9.Angela现在能够与Blanchard医生通信并安排约会。在安排约会的过程中，Angela的医疗记录(包括联系信息)被自动提供给Blanchard医生。

10.由于Angela的PCP是Jones医生，将协商一个新的多方策略并且推出该策略，这样在Angela看Blanchard医生后，Jones医生能够为她提供后续的治疗。该新的策略不是新的通信渠道。恰恰相反，它是连接到多通信渠道的分布式工作流过程，但该策略具有其自己的、扩展其利用的渠道的潜规则。

注意通信渠道是配置和协商合作协议的能力基础。合作协议是丰富的工作流脚本，其在各方之间协商并在各参与者的联络代理商的背景中运行。

不同于通信渠道，合作协议确实改变并且随时间不断变化。随着它们服务的目的不断变化和有可能终止，合作协议也旨在随时间不管变化和改变。

动态决定合作协议

通信渠道是用作在一段时间周期内的多个合作的管路的安全管道。通信渠道有目的地不可变的，并且它们的属性不关于渠道的寿命发生改变。

另一方面，在本质上，合作性的协议固有地是动态的。它们表示目的且必须能够应对随时间发生的变化。

例如，Alice具有与Bob之间的、基于职业关系的通信渠道。该渠道本身仅仅是合作的可能性-它是合作的潜在关系。当Alice想要从Bob请求一报价时，她创建包含请求和所有相关的数据的合作协议。该通信渠道用于交换请求，但报价过程的实现包含在合作协议中。

但在Alice将关于报价的请求发送给Bob、Charlie和Dave后将发生什么事？可能结果Dave做出最好的报价，且最初对Bob和Charlie的请求需要结束，它变为与Dave的购买订单。以下是涉及协议的动态的不断变化中的基本步骤：

1.Alice发布报价请求(RFQ)给Bob、Charlie和Dave。Alice具有最初的版本，且所发布的每个副本具有与最初的协议周期性通信的能力。

2.30天后，Alice收到了报价且她确定Dave给出了最好的报价。

3.Alice现在使用她的RFQ并激活作为协议的一部分的批准过程，指定Dave为赢家。这触发RFQ发送消息给所有其他的请求。

4.Bob和Charlie的RFQ收到消息，因此RFQ终止，且该RFQ上的进一步通信结束(或可能有可选的生效的反馈过程)。

5.Dave的RFQ收到该成功通知并触发Dave接受订单并请求购买订单。

6.一旦Alice收到来自Dave的接受，将制订一个含有购买订单的协议并发送到Dave。

7.Dave收到购买订单，检测条款，在批准该购买订单生效。最初的RFQ现在关闭，但其数据是购买订单的组成部分。

当然，关于该特定主题的存在许多变化。上述实例仅解释了相对简单单边变化。由于协议被实现为丰富的工作流，实现涉及多方的复杂规则是完全有可能的。

根据相关的法律标准描述了前述的发明，因此本描述是示例性的而不是在本质上限定该发明的。本公开的实施方式的变化和修改对本领域技术人员来说是明显的，且在本发明的范围内进行。因此，本发明提供的合法保护的范围仅通过研究以下权利要求才能确定。

Claims (8)

1.一种用于管理数字式互动的方法，包括：

在驻留在机器上的接收方关系联络代理商处经由通过其它关系联络代理商的网络形成的协商遍历路径接收数字向量，所接收的数字向量与请求者端点和接收者端点之间的关系的多个条款关联，并具有使用安全数字密钥来验证的属性，所述安全数字密钥仅能够由所述请求者和所述接收者在同意的条款下使用；

由所述接收方关系联络代理商使用所述安全数字密钥来验证所接收的数字向量；以及

将所述数字向量从所述接收方关系联络代理商中转到与所述接收者关联的角色；

其中，通过包括以下操作的过程来交换所述安全数字密钥和确定所述同意的条款：

通过包括以下操作的过程来在所述请求者和所述接收者之间建立短暂安全渠道：

准备渠道请求包，其中，所述请求者选择要公开的请求者凭证、选择要从所述接收者要求的接收者凭证并选择所述请求者和所述接收者之间的渠道的提出的属性，并且其中，所选择的请求者凭证、所选择的接收者凭证以及所选择的提出的属性由驻留在机器上的请求方关系联络代理商包括在所述渠道请求包中；

由所述请求者关系联络代理商创建请求者创建的第一随机密钥对；

由所述请求方关系联络代理商从所述请求者发送所述渠道请求包；

由所述接收方关系联络代理商在所述接收者处接收所述渠道请求包；

创建接收者创建的第一随机密钥对；以及

通过经由使用所述请求者创建的第一随机密钥对和所述接收者创建的第一随机密钥对的短暂的密钥交换来建立安全的通信渠道；以及

由所述请求方关系联络代理商和所述接收方关系联络代理商建立所述同意的条款和所述安全数字密钥，且所述建立所述同意的条款和所述安全数字密钥包括：

在所述接收者处复查由所述请求者提议的条款；

由所述接收方关系联络代理商通过所述短暂安全渠道将响应发送给所述请求者，所述响应包括对所提议的条款的接受和对所述关系对立地提议的条款之一；

在所述请求者处接收来自所述接收者的所述响应；

从所述请求者通过所述短暂安全渠道发送对所述对立地提议的条款的接受和对所述关系的修订的提议的条款之一；

创建请求者创建的第二随机密钥对；

通过所述短暂安全渠道将所述请求者创建的第二随机密钥对中的一个密钥发送给所述接收者；

创建接收者创建的第二随机密钥对；以及

通过所述短暂安全渠道将所述接收者创建的第二随机密钥对中的一个密钥发送给所述请求者。

2.根据权利要求1所述的方法，其中，所述安全数字密钥没有被容纳在所述数字向量中。

3.根据权利要求1所述的方法，其中，所述请求者端点和所述接收者端点之间的所述关系提供基于关系的加密、嵌入式的使用控制、权利管理或访问位置控制。

4.根据权利要求1所述的方法，其中，所述接收者使用所述请求者的域的电子签名来验证所述渠道请求包。

5.根据权利要求1所述的方法，其中，所述请求者和所述接收者使用Diffie-Hellman协议来交换密钥。

6.根据权利要求1所述的方法，其中，所述同意的条款基于寻求访问所处的背景来限制信息访问权限。

7.根据权利要求6所述的方法，其中，所述背景包括物理位置或安全标志。

8.根据权利要求6所述的方法，其中，所述背景包括发送方的域或角色。

Images