CN112740214A

CN112740214A - 具有托管安全的数字化合约生成

Info

Publication number: CN112740214A
Application number: CN202080004034.1A
Authority: CN
Inventors: 詹姆斯·拉里三世·普尔
Original assignee: Warrendai Ltd
Current assignee: Warrendai Ltd
Priority date: 2019-02-12
Filing date: 2020-02-12
Publication date: 2021-04-30
Also published as: EP3924854A1; WO2020167917A1; US20210133903A1

Abstract

所公开的计算机系统实现用于数字文档的内容的协作和多方操纵的数字文档管理的技术。所公开的协作系统利用具有增强的安全性和跟踪(例如，改变标识)能力的托管区域(例如，逻辑或物理共享储存库或工作区域)。可以利用对托管区域和对数字文档的特定部分的基于角色的访问。因而，对于协作的所有方，以安全且可识别的方式维护更新。可关于与协作的每一方当前定义的角色(例如，供应商、供应商、顾客、管理员、律师)不一致的可见性或改变而限制协作的每一方。所公开的技术可适用于任何类型的数字文档协作，并且可能对可能在多方形成协议(例如，产品或服务的合同)时发生的数字文档协商特别有用。

Description

具有托管安全的数字化合约生成

相关申请

本申请要求于2019年2月12日提交的美国临时申请No.62/804,572的优先权(和所有适用的权利)，该美国临时申请具有与本申请相同的标题和发明人。

技术领域

背景技术

文档管理系统是基于计算机的系统，该系统用于管理表示文档的数字文件的内容。典型的计算机系统将整个数字文档作为整体(即，作为表示整个文档的单个计算机文件)进行管理。当作为单个文档管理时，对数字文档所做的改变可能被数字文档中的其他信息混淆。即，数字文档可以包含许多参数和部分，这些参数和部分在设置数字文档作为整体表示什么方面都是独立重要的。以前的数字文档管理系统将数字文档作为单个实体进行管理，而没有用于审查/批准和安全的模块化。

在以前可用的文档管理系统的实现中，例如，数字合约文档可使用诸如MICROSOFT

的常规文字处理软件来创建，并经由电子邮件在各方之间来回传输。已经开发了协作技术来允许文档共享。参见例如美国专利No.9875221、No.9699409、No.9613340、No.9306941、No.9137220和No.2015/0350690。对于高度机密的文档，还开发了保护文档的技术。参见例如美国专利申请No.2017/0237569和No.2017/0243193。

尽管在文档创建、共享和安全方面有所进步，但仍需要允许各方更高效且安全地管理合约、识别对文档的改变、保护对不同子章节的修改以确保仅允许经授权方更改适当的子章节、并更高效地管理文档的内容(例如，被用作数字文档协商的一部分的数字文档)的技术。现有技术系统可以允许仅允许对模板中的“空白”(例如，数据输入的特定字段)进行修改的模板。

发明内容

附图说明

为了能够详细理解本公开的上述特征和优点，通过参考在附图中示出的本公开的实施例，可以获得对以上简要概述的所公开的改进的更具体的描述。附图示出了示例性实施例，因此不应被认为是对其范围的限制。附图不一定是按比例绘制的，并且为了清楚和简明，某些特征以及附图的某些视图可能在比例上或在示意图中被夸大地示出。

图1是描绘根据所公开的实现的一个示例性数字化合约生成系统的示意图。

图2示出了可用于实现图1的数字化合约生成系统或其他所公开的实现的示例性计算机网络。

图3A-图3L示出了所公开的数字化合约生成系统的示例性实现的示例性计算机屏幕截图。

图4示出了描述当完成(例如，认证初始协议或修改)在根据本公开构建的计算机系统内维护的数字化合约时，可能的计算机系统的处理流程的示意图。

图5示出了描述当执行托管数字文档协商并保护在根据本公开构建的计算机系统内维护的数字化合约时，可能的计算机系统的处理流程的示意图。

图6示出了根据本公开的示例的用于处理数字文档协商的第一示例性方法。

图7示出了根据本公开的示例的包括用于执行图6的示例性方法的计算机指令的计算装置。

图8示出了可以用于实现本公开的方法、过程和技术的示例性分布式计算系统。

图9示出了可以用于实现本公开的方法、过程和技术的示例性计算装置。

具体实施方式

以下描述包括体现本文主题的技术的示例性系统、设备、方法和指令序列。然而，应当理解，可以在没有这些具体细节的情况下实践所描述的实施例。

本公开呈现了一种允许针对数字文档协商的每个步骤进行增强的跟踪、修改、安全和授权的系统。更具体地，本公开涉及数字化合约生成系统(“合约系统”)，该数字化合约生成系统具有允许对协议的离散(但相关)方面进行模块化控制的属性。所公开的合约系统的实施例可以提供可以适用于软件许可协议的特定改进。尽管关于关注软件许可协议的技术解释了本公开的实现示例，但是所公开的技术也可以适用于其他环境中。因此，所公开的用于促进数字协商过程的计算机系统不限于软件许可协议的管理。

在商业环境中，各方用不同的参数协商协议，以建立一组共有的合法绑定承诺，并识别各方之间商定的权利和职责。这个协商可以结束并被记录在合法的合约中。合约可以是具有阐述这些权利和职责的条款列表的书面形式。该条款列表可以涉及协议的特定子章节和相应的数字文档。各方可以通过协商调整和修订这些条款，直到双方接受最终条款。这些最终条款可以由双方通过书面合约的签名来确认。签名确认它们遵守这种协商的条款的协议。一种类型的合约涉及软件供应商和客户之间的软件许可协议。在软件许可协议中，可能存在对于其它类型的合约而言不是共同的协议方面，因此可以受益于如本文所描述的更自动化的“数字协商过程”。

本公开解释了已经开发的用于处理各方之间的数字文档协商的各种技术。在此上下文中，条款“数字文档协商”是指对文档应用改变并将关于那些改变的信息提供给所有感兴趣方(例如，产品、服务等的协议的各方)的迭代性质。数字文档协商的最后步骤可以是请求关于在整个协商期间所做的改变的总和的协议。在典型的协商过程中，可以存在许多迭代，并且每个迭代可以包括对一个或更多个子章节(例如，条款、权利和职责的列表)的改变。理解和跟踪每次迭代时每一方所做的改变可能是重要的。这种理解可以通过设计成具有增强的跟踪和通知能力的计算机系统(诸如本文所公开的系统)来改进。

通常，所公开的文档管理系统提供安全和集中的工具，即合约托管，其中各方之间的合约被数字地处理(例如，创建、更改、审查、编辑、完成、批准、签署和/或保护)。与可能需要使用文档编辑软件在通信网络上来回传递整个文档的现有技术不同，该合约系统允许用户进入合约托管，以在安全合约托管内对同一合约(或基于角色的特定部分，如以下将解释的)进行工作。该托管区域可以使用单个的可能基于云的存储储存库来实现，或者可以在多个离散储存库中实现，其中托管方面是逻辑地而不是物理地实现的。在任何情况下，不管如何实现，可以基于用户在特定阶段所需的角色和动作(例如，基于如下所述的状态机)向用户呈现到合约的适用部分的界面。

在某些实现中，文档由共同形成整个文档的不同部分(例如，子章节)组成。这些子章节中的每一个可以被存储为独立的计算机文件，这些计算机文件在协商过程的不同阶段可通过安全考虑由协议的不同方访问。此外，不同方中的每一方可(例如，基于其在过程中的角色)指定个人在不同阶段中的每一阶段评论、更新和/或批准不同的子章节。在技术条款，这可以被认为是文档的每个子章节通过适用于该子章节的状态机前进。因此，实现可以利用由在计算机系统上执行的软件控制的多个状态机来管理文档的每个子章节的生命周期(即，子章节生命周期)并作为整体的协议(即，文档生命周期)。

通常，第一方可能能够访问子章节集合的第一子集并与之交互，而第二方可能能够访问子章节的第二子集(不同于第一子集)并与之交互。一旦每个子章节已经被内部地“批准”聚会(例如，完成了子章节生命周期)，则可以使该“完成的”子章节对所有用户可见。可以对所有子章节重复这一安全和可见性过程，使得一经(在签名之前)最终批准，所有各方都可以只读访问所有子章节，并由此访问整个文档。接下来，签核过程可以完成数字协商过程。在一些实现中，每个子集可作为单独的计算机文件来控制，并逻辑地连接以形成整个文档。

在一个示例中，第一状态机可以被实现为反映数字文档的特定子章节的子章节生命周期。第二状态机可以被实现为反映不同子章节的不同子章节生命周期(即，每个子章节可以具有其自己的生命周期)。文档状态机可以被实现为反映整个文档的文档生命周期。这些不同状态机中的每一个都可以使用由计算机系统处理的有向图来实现，以通过数字协商过程来控制对文档的它们各自部分的访问和批准。状态可以被表示为有向图的节点。从一个节点到下一个节点的转换(例如，状态转换)可以基于用户采取的动作，并且基于用户角色和用户对每个节点处的每个文档部分的访问来(例如，分层安全)控制。

所公开的合约系统提供了一种集中式合约结构，用于：指定用户(例如，审查者、授权签署者等)、输入合约参数(例如，参与方信息、定义的条款、定价等)、监视合约文档上的活动(例如，编辑、评论、批准等)、(例如，用数字签名和公钥/私钥)数字地签署合约、以及保护合约(例如，验证、识别、以及数字化)。合约的每一方可以指定用户接收已分配合约(子章节)的状态改变的通知，并接收输入合约托管对这些合约(子章节)采取行动的警告。此外，所公开的过程在最初达成协议时不会终止，并且允许在任何协议的整个条款中进行修改。例如，客户可以协商用于组织的多个软件许可证的初始购买。随着时间的推移，该组织可能需要原始产品或其他产品的附加(或更少)许可证。所公开的合约系统通过允许在最初同意的购买合约条款下进行更改(例如修改)来促进这些改变的商业需求。

合约系统还提供多层安全，以限制对托管的访问，并定义在可以访问合约(或其一部分)之前必须核实与各方及其合约有关的凭证(例如，口令、密钥、时间戳等)。验证由熟悉合约的指定用户和各方以及由具有核实凭证的能力的合约系统来执行。这种多层安全还包括用于签署合约的数字核实，以及合约本身的数字编码(即数字指纹或哈希值)。将合约从可读文档格式转换成数字格式(例如，哈希值)，该数字格式提供合约到仅由具有匹配加密密钥的授权用户可访问的安全数字代码的数字转换。为了增加的安全，信息可以存储在分布式交易总账(“DTL”)(诸如允许跨越多个服务器存储不可更改的信息的区块链)中，从而提供关于准确的总账条目(例如，区块链中的区块)的一致性。

所公开的合约系统可以被实现为提供以下特征中的一个或更多个：合约的集中处理、高效审查/修订、修订和评论的记录、修订通知、指定的用户访问级别(例如，对于审查者/批准者/签署者)、对合约的安全访问、合约的数字化记录、对合约(或其部分)的多层访问和存储、导入或访问现有条款的能力、用于合约审查/修订的跟踪系统、简化的合约创建、用户参数(例如，联系人信息、受限访问、审查/批准许可等)的存储、合约参数(例如，合约条款、合约访问、合约处理等)的存储等。在一个示例中，导入特征允许用户导入信息(例如，来自结构化文件或网络上发现的信息)以在合约系统内自动填充信息。具体地，供应商可以在导入文件中提供信息以描述来自该供应商的可用软件供应。作为第二示例，客户可以在他们的网络上运行发现过程，以确定软件产品的(例如，用于审计和合规性的)当前使用级别，并使该信息可被所公开的合约系统访问。每个公开的导入功能可以由供应商或客户自动执行(例如，周期性地运行)。

一种合约系统结构

图1是描绘在合约系统100的示例性实现中描绘的用于处理各方之间的(例如，执行如针对合约所公开的数字协商过程的)合约的一个示例性文档管理系统(DMS)的示意图。合约系统100可以是定义可由各方指定的一个或更多个用户102访问的托管101的集中式系统。所描绘的这种用户102表示一个人或更多个人。在所示的示例中，用户102包括供应商102a、供应商102b和客户端102c。供应商102a、102b中的每一个都试图与客户端102c签订合约。如上所述，托管101可以是物理上集中式系统，或者可以在逻辑上作为托管101控制的物理上不同的系统上实现。

用户102可以位于各种位置，并且具有能够与合约系统100通信的一个或更多个计算装置(例如，计算机)104a。如本文所使用的，“计算装置”可以是服务器、计算机联网装置，包括专用芯片组、台式计算机、工作站或任何其他处理装置或装备，诸如与远程网络硬件接口的服务器(诸如源节点交换机)。计算装置104a可以是例如具有相关联的硬件(例如，处理器、数据库、服务器、显示器、鼠标、键盘等)的常规计算机，该常规计算机可以通过软件被具体配置以允许用户102访问合约系统100来生成合约(或执行对现有合约或其子章节的修改)。

在该示例中，计算装置104a经由通信链路106a、106b访问合约系统100。每个通信链路106a、106b可以是能够在用户102和合约系统100之间传输数据的有线、无线、卫星、本地、远程或其他类型的通信链路(例如，诸如以太网的电力电缆、光纤、无线电波等)。例如，每个通信链路可以是用户102和托管101之间的直接链路106a。在另一示例中，通信链路可以是从用户102b通过云结构108(例如，远程连通性连接)延伸到托管101的间接链路106b。用户102可以经由网关107a访问托管101。网关107a可以是使用密码认证器、公钥基础设施(PKI)或用于选择性地允许指定用户102访问合约系统100的其他安全手段的受限访问网关。

合约系统100可以包括容纳在网络105上的一个或更多个计算装置104b。计算装置104b可以包括托管101和节点112(例如，交易节点112a、验证节点112c和安全节点112b)。托管101可以经由网络105与节点112和用户102通信。网络105可以提供计算装置104a、104b之间的通信路径、至少一个数据链接(例如，通信链路106a、106b)或其组合，以允许计算装置104a、104b之间的通信和数据交换。网络105还可以包括计算装置104a、104b之间的中间计算装置。在一些示例中，网络105可以是单独的网络或彼此互连并且作为单个大型网络(例如，内联网)的许多这种单独网络的集合。在一些示例中，网络105可以被实现为局域网(LAN)、广域网(WAN)等。

托管101包括通过网络105连接到存储介质110的(有时称为计算机处理器的)处理资源108。处理资源108可为(例如)中央处理单元(CPU)、基于半导体的微处理器、数字信号处理器(DSP)(诸如数字图像处理单元)、适合于检索并执行存储在存储介质中的指令的其它硬件装置或处理元件或它们的合适组合的形式。如本文进一步描述的，处理资源可用于获取、解码和执行指令。

存储介质110可以是非暂时性机器可读存储介质的形式，诸如合适的电子、磁、光或其他物理存储设备，以包含或存储诸如指令114的信息。存储介质110可以位于如图所示的托管101处，或者位于穿过合约系统100的一个或更多个位置。存储介质110可以是能够接收和存储数据的机器可读存储介质。存储介质110可以包括一个或更多个存储设施，用于存储在合约系统100中接收或生成的各种形式的数据。例如，存储介质110可以包括用于容纳合约条款、参与方信息、合约参数、安全协议等的一个或更多个存储设施。

在图1的示例中，指令114被存储(编码)在存储介质110上，并且可由处理资源108执行以实现本文描述的功能。在一些示例中，存储介质110可以包括附加指令，诸如用于实现关于节点112描述的一些功能的指令。在其他示例中，存储介质110的任何指令的功能可以以电子电路的形式、以编码在机器可读存储介质上的可执行指令的形式或它们的组合来实现。

如图1中示意性地示出的，托管101可以用于实现用于管理合约120的指令114(例如，执行合约功能管理的计算机功能模块)。如本文进一步描述的，这种管理120可以涉及附加功能模块，用于创建合约122，更改(审查/批准/修改)合约124，核实(签署)合约126，以及(例如，使用基于角色的安全)保护合约128。创建122和更改124功能可以从托管101内执行。签署126和保护128功能可以与节点112和外部源129a、129b结合执行。

合约托管101可以与内部和/或外部服务结合使用，以生成安全凭证130。这些安全凭证130可以包括安全密码132a、公钥132b、私钥132c、数字签名132d和如示意性示出的用于认证的其它手段。如本文进一步描述的，安全凭证130与节点112结合使用，以限制访问并保护合约，从而提供多层安全。如本文进一步描述的，安全凭证130还用于为合约创建数字指纹(哈希值)。

如示意性地示出的，可以使用外部服务129a、129b来提供安全凭证130。这些外部服务129a、129b可由托管101访问，并在合约系统100外部实现。通过访问外部服务129a、129b，加密密钥132b、132c和数字签名132d可以在托管101外部被保护、创建和维护。具有外部服务可以帮助隔离与安全凭证130相关联的安全信息的暴露。

外部服务129a、129b可以包括例如用于生成安全密钥132b、132c中的每一个的外部密钥库129a和用于生成数字签名132d的外部签名存储129b。密钥库129a可以是能够为用户102定义加密密钥的任何密钥库(例如ETHERIUM或www.walleth.org)。在另一示例中，密钥服务129b可以是能够为用户生成数字签名的任何服务，例如(在www.docusign.com商业上可获得的)

或(在www.globalsign.com商业上可获得的)

与数字签名132d相关联的数字证书可以被上传到托管101中，链接到系统内的用户简档，并且被分配相应的密码。如本文进一步描述的，用户102可以使用该密码来用数字证书签名。

托管101可以耦合到节点112以便与其一起操作。可以设置网关107b以限制对节点112的访问。网关107b可以采用验证器(例如，

)来在可以访问节点112之前要求授权证明(认证)。授权证明可以包括例如系统证书的核实，诸如时间戳、公共地址、交易ID和/或一个或更多个安全证书130的核实。

所示的节点112包括交易节点112a、安全节点112b(其可以包括区块链或其他分布式交易总账实现方式)和验证节点112c。节点112a-112c中的每一个可以是经由网络105耦合到托管101的一个或多个计算装置104b的形式。这些节点112中的每一个被用于进一步处理使用处理资源108、存储介质110和指令114在托管101内生成的合约134(或基于角色的它们的子章节)。这些节点112a-112c2可以用于使用交易节点112a验证用户102，使用安全节点112b验证安全合约134，以及使用验证节点112c验证合约134。验证节点112c可包括系统验证节点112c2和一个或更多个用户(对等)验证节点112c1。每个验证节点112c1可对应于用户102a-102c中的一个。

如示意性地示出的，一旦创建了合约134，就(例如，通过网络上传合约134)使合约134在交易节点112a处可用。交易节点112a捕捉在托管101处创建/更新的合约134(或其子章节)，并向验证节点112c广播合约134。在该示例中，交易节点112a充当到验证节点112c的通信网关，并且验证节点112c被用于确认合约134。在合约134可以进行签名之前，可能需要验证节点112c的预定量(例如，50％)的验证(例如，一致性验证可以跨多个节点发生)。这种验证可以涉及安全凭证130的核实。

一旦被验证，合约134就可以被传递到安全节点112b并被处理以便签名。在签名被处理之前安全节点112b可能需要识别一个或更多个安全凭证130。在所示的示例中，在合约134可以被验证之前，安全节点112b确定适当的密码132a、公钥132b、数字签名132d和私钥132c。一旦完成，便可将合约134数字化为数字合约134'。为了清楚起见，在上述示例中，系统可以针对上述处理步骤中的任何一个处理完整合约134或其一部分(例如，子章节)。在(对合约的更新)修改过程中，每次修改可能只影响所选择的子章节。

参考图2，示出了第二示例性分布式计算机系统150。在该示例中，可以在客户端装置(例如，客户端装置154A)上(例如，从诸如图1的托管101的托管区域)获得数字协议151(或其部分)。可以基于数字协商处理的状态和与特定客户端装置相关联的用户的角色来使数字协议151的部分可用。不同类型的客户端装置可以在整个数字协商过程中进行接口。例如，用户可以使用台式计算机154B或膝上型计算机154C。客户端装置154A表示通用客户端装置，并且可以包括智能电话、平板电脑或具有用户接口的其他类型的计算装置。

每个客户端装置154可以连接到客户网络152以(例如，经由可以是因特网的网络158)与后端或云资源155和经由网络链路连接的其他计算机系统接合。在该示例中，客户网络152包括被示为参与分布式交易总账(DTL)安全实现(例如，区块链实现)的计算资源156A、156B。后端或云资源155包括多个服务器154，该多个服务器154可以用于群集如针对服务器152A所示的托管储存库(并且执行托管功能)。后端或云资源155还包括可以附加地设置DTL安全的服务器152B。从用户的角度来看，网络附接后端服务器(例如，后端云或服务器资源155)表现为功能上分立的系统。这些功能上分立的系统中的每一个可以在物理硬件上实现，或者可以使用虚拟机(VM)来实现。

如上所述，角色可以被分配给不同的用户，并且用于确定指定用户在数字协商过程的生命周期(例如，阶段)中的某一点处的可访问性和动作许可。在一个实现中，角色包括：客户端作者、客户端审查者、客户端签署者、供应商作者、供应商审查者和供应商签署者。对于一个示例实现，这些角色中的每一个可被实现为如接下来所描述的(也可基于角色来指定其它能力)。

客户端作者可以在所公开的系统内创建/启动合约过程。作者充当向供应商提交合约信息并从客户端侧分配审查者和签署者的过程的焦点。客户端审查者是组织内帮助作者审查合约条款和条件的内部批准者。客户端审查者仅具有对合约的读访问权以及批准部分的能力。客户端签署者是具有解除合约协议的权限的最终的审查者。供应商作者可在所公开的系统内创建/启动合约过程。作者充当向客户提交合约信息并从供应商侧分配审查者和签署者的过程的焦点。供应商审查者是组织内帮助作者审查合约条款和条件的内部批准者。客户端审查者仅具有对合约的读访问权以及批准部分的能力。供应商签署者是具有在所公开的系统内签署合约协议的权限的最终的审查者。

现在参考图3A和图3B-图3L，其中图3A示出示意图305，而图3B-图3L示出不同的屏幕截图，这些屏幕截图被示为可以作为所公开的用于具有托管安全的数字化合约生成的系统的一种实现方式的用户界面(UI)(未另外示出)的一部分来呈现。这里简要描述每个屏幕截图，然后在下面关于图4-图6的流程进一步讨论每个屏幕截图。回想可以将角色分配给用户以帮助安全，并针对合约创建或更新过程的状态为特定用户提供焦点。在一些实施方式中，数字协商过程的生命周期可以使用一个或更多个状态机来实现，以控制动作的流程并在整个生命周期内订约子章节内容。如本领域所理解的，状态机可以基于有向图来可视化或实现，其中有向图的节点(例如，节点表示状态)之间的转换(例如，状态改变)控制适当的流程。即，有向图可以确定从一个状态到下一状态的容许转换的受限集合，因为仅允许转换在连接的节点之间发生。

图3A示出了示意图305，用于描述了一旦呈现适当的凭证130，用户102可以经由网关107a访问托管101。图3B示出了可以表示进入所公开的系统以启动用于创建或更新协议的新会话的入口点的屏幕截图310。图3C示出了在生命周期状态区域316向用户通知数字协商过程的状态(例如，合约的状态)以及关于当前活动的合约(或其子章节)的其他信息的屏幕截图315。图3D示出了包括“状态”区域321和“我的动作”区域322的屏幕截图320。因此，屏幕截图320示出了UI屏幕，其中用户可以接收查看关于他们在所公开的数字协商系统内的角色的他们的当前任务列表的“仪表板”。图3E示出了包括下拉326的屏幕截图325，其中用户可包括来自要被包括在正在被创建或调整的合约中的特定供应商的产品。图3F示出了屏幕截图330，该屏幕截图330提供了当前文档331和先前文档332之间的改变的视图(例如，为用户突出显示改变的部分)。

图3G示出了屏幕截图335，该屏幕截图335包括针对当前所选合约的章节名称336A、审查名称336B、作者336C和版本336D。章节选择区域338A指示用户可(例如，基于其角色和可访问性许可)选择合约的不同章节来与其交互。批准历史图例338B提供了可以单独应用于在选择章节区域338A中可用的每个子章节的颜色编码。历史区域338C提供关于当前活动的子章节(例如，当前子章节工作区域338D中所示的子章节)的改变的信息。图3H示出了屏幕截图340，该屏幕截图340包括章节选择识别341、章节选择区域342A、批准历史图例342B、历史342C和当前子章节工作区域342D。图3I示出了屏幕截图345，该屏幕截图345包括角色识别347(例如，供应商签署者)和用于上传数字证书文件的输入区域346。图3J示出了屏幕截图350，该屏幕截图350包括角色识别区域351(例如，客户端签署者)和与具有该角色的特定用户有关的其他信息。

图4示出了用于完成所批准的合约的示例性过程400。如图4所示，在用户(客户端)405数字地签署合约协议406之后，(使用哈希算法407)转化合约以创建数字哈希值408，并且将经签署的数字合约411与私有加密密钥409和指定的供应商410相关联。之后，供应商410(例如，不同的用户)可以识别先前签署的合约411，并使用公钥412来解密和并重新创建数字哈希值408。由于这个重建过程利用与客户端405相关联的公钥，哈希值408的比较将确定哈希值408是否已被相同地重建(例如，验证)。在该示例中，因为哈希值的后续生成是(先前签署的合约411)文档的相同内容，所以文档未被篡改。一旦被核实，供应商410就可使用私钥409来访问数字签署的合约411并将供应商的数字签名应用于合约411，从而共同签署(代表供应商的)(即，先前由客户端405签署的)数字合约411。

如以下参考图6的方法600所更多讨论的，可以在每个数字签名之后保护所签署的合约，基于用户凭证(签名密码和用户密码)来验证数字签名，从而允许每个用户确认签署的合约，并由此基于合约参数来验证用户和签署的合约。可以通过允许将由用户和联系系统核实的每个签名来验证所批准的合约。然后，可以经由交易节点(参见图1)向用户验证节点和系统验证节点广播批准的合约。交易节点可用于向所分配的用户通知指示该合约被批准的状态改变(例如，状态机内的状态转变)的合约。用户验证节点可以被激活以核实用户和/或合约，以确保合约准备好验证。系统验证节点也可被激活以经由安全节点核实凭证是有效的。如果用户验证节点的所需数目和系统验证节点批准了(例如达成共识)，则可以签署合约。

图5示出了用于在使用例如区块链的整个数字协商过程中保护合约和其中的信息的示例性过程500。保护可以涉及用户(客户端405、供应商410或附加方415)在用户节点处执行用户验证并且在系统节点处执行系统验证(例如，如图1中所示)。如图5所示，在每个签名被应用于合约(或其子章节)之后，签署的合约可以被发送给交易节点413(也参见图1的112a)，并且被广播给用户节点和系统节点(也参见图1的112c)。用户将有机会使用客户端公钥412经由交易节点413访问合约411并确认各方和合约。用户可以经由他们各自的交易节点413来验证(例如，执行用户验证)或拒绝合约。用户验证可以涉及确认各方和条款。所公开的合约系统还具有经由系统节点来验证合约或无效合约的能力。系统验证可以涉及确认用户安全凭证(例如签名、密码等)和系统安全凭证(例如时间戳、日志、公共地址、数字指纹等)。合同系统可以确认这种安全凭证适当地对应于合约。在给定数量的验证节点(例如，大约50％或更多)之间达成一致并且合约系统节点批准合约之后，数字合约然后被验证并且转换到批准状态，在批准状态中数字合约可以变成活动合约。在一段时间之后，可以对任何活动合约处理修改，以允许调整(例如，添加产品或更改定价)，并且每次修改可以在变为活动的并扩充/替换原始合约之前经历类似的创建/审查/批准生命周期。

图6是描绘执行数字协商过程以生成和认证数字化合约的示例性方法(600)的流程图。在框602，在计算机网络内逻辑地或物理地提供了托管区域(例如，图1的托管101)。可以使用合约系统生成合约，以基于角色和访问准则来创建合约，如在框605处所指示的。框610指示可以导入信息以便于合约生成。例如，关于来自供应商的产品供应的信息可以导入到系统中以用于合约生成。框615指示完成的数字文档协商过程可以导致完成(例如，由授权方基于他们的角色签名)的协议。方法(600)包括框620，其中在其初始完成状态(即，在可能的修改之前或未来调整之前)的协议可以通过向各方提供对托管区域的访问来进行认证。

框630指示DTL可以以一次写入多次读取(WORM)方式提供每个DTL条目的自动传播。诸如区块链的DTL允许在链中创建新块，但从不允许删除或更改。框635指示可以在稍后的时间检索完成的合约(数字文档)，并且可以启动认证请求以核实检索到的数字文档是真实和正确的(例如，如图4所示的哈希匹配)。块660指示可以从DTL检索总账条目以执行比较。此时，可以将所提供的信息作为当前生效的信息来审查。

框665指示用户可启动修改当前生效的信息的过程(例如，提出对原始或当前合约的修改)。框670指示可以在托管区域中以与原始数字文档协商的处理的类似的方式(例如，使用角色、认证和验证)处理该修改。修改过程可以被批准，并且框675指示修改的文档可以变成修改状态中的认证协议，以反映原始协议和作为修改的一部分而进行的修改。

总之，该过程包括基于在合约托管处从第一方接收的合约参数在合约托管区域创建草案合约；允许各方在该托管处更改草案合约；通过将来自各方中的每一方的数字签名应用于经批准的合约来完成各方之间的经批准的合约，以及部分地通过使用诸如区块链之类的DTL来认证合约而保护合约。

向各方提供对合约托管的访问可以涉及例如为各方中的每一方定义用户凭证和角色、接收用户识别以及接收用户选项。当一方首次进入(例如，远程地连接到)合约系统时，每个用户被设立为通过经过为托管提供安全的网关来使用合约系统(例如，如例如图1中所示)。为此，用户被注册用于识别目的，被分配用户证书用于认证，并且与每个数字协商过程的角色相关联。为了注册和/或认证，用户可以输入用户识别信息，诸如联系人信息、标题、角色等。用户还可以通过选择诸如屏幕设置、联系方法等选项来输入用于使用合约系统的用户选项。可选地，该用户信息可以存储在合约系统中，并且可以被其他用户使用。

当每个用户注册(在其中定义)到合约托管时，可以创建用户凭证，并且用户凭证可以包括例如密码、公钥、私钥和/或其他安全凭证(见图3A)。在最初进入合约系统时，用户注册并定义他们的用户密码。然后使用外部密钥存储(例如，如图1所示的129a)为每个用户分配公钥和私钥。可以使用加密软件来生成公钥和私钥，该加密软件在合约托管的内部或外部。私钥可以(例如，使用

)被生成并被分配给用户，并且使用例如PKI和/或认证机构(CA)来加密。用户的安全凭证(例如，图1的安全凭证130)可以由这样的用户分配和维护，而不存储在联系人托管内。诸如口令、公钥和私钥等安全凭证的组合可由合约系统使用来访问和/或更改合约托管中的合约，如本文进一步描述的。

通过定义诸如合约方信息、用户角色、合约参数和合约条款之类的某些合约参数，首先在该托管处创建草案合约。该草案合约可以由离散的子章节形成，这些子章节一起创建表示合约的完整数字文档。合约的初始草案可以由诸如供应商的各方之一或诸如合约服务的第三方创建。创建涉及定义合约各方、分配用户角色、定义合约参数、导入供应商信息以及选择草案合约条款(撰写、导入和/或选择预起草条款)。这些合约参数可以存储在该托管中，并且可以为期货合约而被访问。

各方可以通过输入诸如名称、实体、状态、地址、分支机构、商业伙伴选择、联系信息等的参与方信息来定义。该信息可以被填充在草案合约的部分(诸如前序、签名块等)中。该信息可以由用户输入和/或由另一用户根据提供给这些用户的访问和许可(例如，角色)来编辑/补充。参与方信息可以与用户输入的注册信息和与用户相关联的安全凭证相链接。参与方信息可以与每个适用合约相关联并且“链接”到每个适用合约。各方还可以被分配参与方用户角色以定义哪些用户可以访问哪些合约。用户可被分配许可以指定哪些合约(或其部分)可被访问。可以向用户提供关于这样的合约的状态改变(例如，通过生命周期的状态转变)的警告。所分配的用户角色还可用于确定哪些用户将对合约采取行动。选择用户可以被分配为发起者、审查者、编辑者、批准者、签署者等。合约系统还可以基于分配的角色发送通知、警报、请求授权和请求批准。

可以通过输入关于要形成的诸如合约类型(例如，制造、购买)、日期、国家、货币、描述等的合约的信息，来定义合约参数。还可以定义附加信息，例如附属公司、支付信息、费用等。合约和其他合约参数可以由用户输入、由一个或更多个用户更新、和/或从合约系统中的先前记录条目中选择。合约参数的示例包括合约类型、标题、开始和结束日期、位置、客户实体、货币和描述(例如，如图3B所示)。

可以通过从预先存在的文档或从合约系统选择条款来将草案合约条款添加到合约。图3C中描绘了示例合约条款。现有合约和/或合约条款可以由用户导入到合约托管中，以便在合约系统内使用。用户还可以在该托管中打开新的草案合约，并选择条款以添加到草案中。条款可以从导入的条款中选择，或者从合约托管中存储的条款中选择。可以选择各种条款，例如价格、交付、各方的义务、担保、赔偿、定义、样板语言和/或其它条款和条件。如图3C所示，条款可以被分成多个章节，例如标题、定义、要求、定价、支付条款、登记条款、登记细节、信息、财务等。这样的项目可以是可搜索的，并且还可以提供诸如附属公司、语言等的合约标签。

一旦选择了合约参数，就可以创建草案合约。可以用合约参数填充草案合约，并将其汇编到可由选定用户访问的合约文档中。创建合约的初始草案的一方可以汇编合约文档，并在将合约提交给其他用户以供审阅之前作出改变。合约可以存储在合约系统中(例如，在合约托管处)，并由起草方访问以备将来使用。

一旦创建，草案合约就可与用户和用户的凭证相关联。如本文进一步描述的，可以通过要求用户在可以访问合约之前呈现安全凭证(例如，参见图3A)来限制对合约的访问。草案合约还可以在合约托管处由根据其用户角色定义的授权用户访问。

合约系统可以允许各方在托管处更改草案合约。该更改可以涉及根据用户角色通知各方草案合约的状态改变(例如，与创建、修订、评论、拒绝、批准相关联的状态改变)；允许各方根据其用户角色和安全凭证在该托管处访问草案合约；从各方接收更改；以及在双方批准所述草案合约时，提交所述草案合约作为用于签名的批准合约。

本文描述的通知动作可以包括向已经被分配了需要通知的用户角色之一的那些用户发送电子邮件通知。用户角色可以在状态改变或触发事件(诸如创建、修订、评论、拒绝、批准或对合约的其他动作)发生时定义通知的类型、方法和定时。例如，被分配来审阅、修订、批准、签署或接收合约的指定用户将接收通知。这样的通知可以是关于合约的某些活动的警报，诸如到期、没有动作、需要审查、批准、执行等。图3D示出了具有可以被发送给用户的通知的示例屏幕。该示例示出了分配给用户的合约的状态概要，以及用户完成的动作、示出其他用户的动作的内部费用、以及诸如合约到期和我的合约活动等的状态警报。

允许各方访问数字文档信息可以涉及允许用户登录到合约系统中，并且使用各种安全凭证(例如，如图3A所示的安全凭证130)来访问合约托管。在托管的安全环境内提供对合约的这种访问，并且提供其多层安全。为了访问该托管内的特定合约，可以经由链接和/或指定的密码、密钥和/或特定于单个合约的其他安全凭证向用户提供访问。

接收更改可以涉及允许用户审查草案合约(例如，条款、备注、评论、比较文档)、输入对草案合约的更改(例如，修订、评论)、提交经修订的草案合约以供附加的内部/外部审查、以及批准或拒绝经修订的草案合约。用户可以输入合约以仅查看、进行评论、改变条款等。如前所述，可以通过编辑文本、导入或添加条款、改变参与方信息、添加用户(例如，审阅者、批准者、签署者等)来进行修订。

在每次更改之后，可以提交合约以供同一方、另一方或其他第三方的其他用户审查。该过程可以重复，直到不再请求进一步的更改。当双方批准或一方最终拒绝草案合约时，该过程也可以终止。图3G和图3H分别示出了用于批准合约条款和用于查看要被批准的项目的示例性批准页面的屏幕截图。如图3G所示，可以分别查看和选择这些条款以供批准，并且示出了审查和批准的历史。如图3H所示，可以向用户呈现用于批准某些条款的条款列表，这些条款可供访问以查看这些条款的细节。

在各方批准草案合约之后，草案合约变成“批准合约”。批准可以要求由各方中的每一个的一个或更多个指定批准者接受文档。一旦批准，可以保护批准的合约以防止(例如，经由DTL中的条目)进一步的更改。许可和/或授权可以被定义为允许在批准之后进行选择性的更改。在批准后，可以提交批准的合约用于最终签名。

可以通过将来自各方中的每一方的数字签名应用于经批准的合约来最终确定并签署经批准的合约。该最终确定可以包括通知各方中的第一方签署批准的合约，将第一方的数字签名应用于批准的合约，并且将第一方的数字签名链接到第一方的公钥，将合约转化成数字指纹(例如，哈希值)，将数字指纹存储在合约托管中，核实第一数字签名，并且在核实第一数字签名时，将第二方的第二数字签名应用于批准的合约(例如，共同签署)。

可以在通知第一方签署批准的合约、接收第一方的数字签名、以及将第一方的数字签名链接到第一方的公钥之后，应用第一数字签名。接着，第一方的指定用户接收通告，该通告警告第一方批准的合约可用于签名。第一方的指定用户可以使用密码登录到合约托管中以访问批准的合约。一旦访问该合约，第一方的指定用户接收数字签署该合约的提示。第一方数字签名可以通过访问外部签名存储(参见图1的129b)、验证安全凭证、以及使用外部签名存储的数字工具来应用安全签名而被应用。签名可以通过外部签名存储在外部维护。图3I示出了示例性数字签名页面，该页面示出了由充当供应商签署者的用户上传的数字签名。

接着，可以核实第一数字签名，然后应用所批准的合约的第二方的第二数字签名。一旦第一方用户的数字签名被应用于经批准的合约，第二方可被通知经批准的合约已被签署并且可用于由第二方签名。可以通过通知第二方的指定用户共同签署所签署的合约、用公钥解密第一方的数字签名、以及接收第二方的第二数字签名来应用第二数字签名。当访问经批准的合约时，第二方可以看到第一方的数字签名被应用于合约。

在批准合约上的第一方的数字签名可以给出第二方相信消息是由已知发送者创建的理由。图3J示出了链接到签署用户(客户端签署者)的安全的示例。图3J示出了用户/供应商签署者的示例安全凭证，包括个人细节以及密码和数字证书。因为第二方也有权访问合约托管内的第一方的公钥，所以第二方可以使用第一方的公钥来访问签署的合约。第一方的公钥可以被链接到数字签名，使得签署的合约不能被访问，除非公钥能够解密第一方的数字签名。如果公钥不能这样做，则签名的合约是不可访问的。如果签署的合约是不正确的合约，或者签署的合约自签署以来已经被更新，则公钥可被设置为不再起作用。一旦第二方确认第一方的身份，并且可以验证合约上的数字签名，第二方就可以使用相同的数字签名过程来数字地签署合约。

现在参考图7，其示出了根据一个或更多个公开的示例性实现方式的示例性计算装置700，计算装置700具有硬件处理器701和存储在机器可读介质702上的可访问的机器可读指令，该机器可读指令可以用于实现用于创建和管理数字文档的系统。图7示出了被配置为执行方法600的流程的计算装置700作为示例。然而，计算装置700还可以被配置为执行本公开中描述的其他方法、技术、功能或过程的流程。在图7的该示例中，机器可读存储介质702包括使硬件处理器701执行以上参照图6讨论的框602-框675的指令。

诸如图7的702的机器可读存储介质可以包括易失性和非易失性、可移动和不可移动介质，并且可以是包含或存储可执行指令、数据结构、程序模块或处理器可访问的其它数据的任何电子、磁、光学或其它物理存储装置，例如固件、可擦除可编程只读存储器(“EPROM”)、随机存取存储器(“RAM”)、非易失性随机存取存储器(“NVRAM”)、光盘、固态驱动器(“SSD”)、闪存芯片等。机器可读存储介质可以是非暂时性存储介质，其中术语“非暂时性”不包括暂时性传播信号。

图8表示根据一个或更多个公开的实现的、可以用于实现用于使用托管来创建和管理数字合约的公开的系统的全部或部分的计算机网络基础设施800。网络基础设施800包括一组网络，其中本公开的实现可以在一个或更多个不同的网络中操作。网络基础设施800包括客户网络802、网络808、蜂窝网络803和云服务提供商网络810。在一个实现中，客户网络802可以是本地专用网络，诸如包括各种网络装置的局域网(“LAN”)，所述网络装置包括但不限于交换机、服务器和路由器。

这些网络中的每一个都可以包含有线或无线可编程装置，并且使用任何数量的网络协议(例如，TCP/IP)和连接技术(例如，

网络或

)来操作。在另一实现中，客户网络802表示可以包括或通信地耦合到一个或更多个局域网(“LAN”)、虚拟网络、数据中心和/或其他远程网络(例如，808、810)的企业网络。在本公开的上下文中，客户网络802可以包括使用诸如以上所描述的方法和技术的一个或更多个高可用性交换机或网络装置(例如，用于部分地使用计算资源806A和计算资源806B的具有合作安全的数字化合约生成的系统)。

如图8所示，客户网络802可以连接到一个或更多个客户端装置804A-E，并且允许客户端装置804A-E经由网络808(例如，因特网)彼此通信和/或与云服务提供商网络810通信。客户端装置804A-E可以是计算系统，诸如台式计算机804B、平板计算机804C、移动电话804D、膝上型计算机(被示为无线的)804E和/或一般被示为客户端装置804A的其他类型的计算系统。

网络基础设施800还可以包括通常被称为物联网(“IoT”)的其他类型的装置(例如，边缘IOT装置805)，这些类型的装置可以被配置为经由网络发送和接收信息以访问云计算服务或者与远程网络浏览器应用交互(例如，以接收配置信息)。

图8还示出客户网络802包括本地计算资源806A-C，本地计算资源806A-C可包括服务器、访问点、路由器或被配置为提供本地计算资源和/或促进网络和装置之间的通信的其他装置。例如，本地计算资源806A-C可以是一个或更多个物理本地硬件装置，例如上面概述的自动模式网络基础设施装置。本地计算资源806A-C还可以促进其它外部应用、数据源(例如807A和807B)和服务以及客户网络802之间的通信。

网络基础设施800还包括用于移动通信装置的蜂窝网络803。移动蜂窝网络支持移动电话和许多其它类型的移动装置，例如膝上型计算机等等。网络基础设施600中的移动装置被示为移动电话804D、膝上型计算机804E和平板计算机804C。诸如移动电话804D的移动装置可以在移动装置移动时与一个或更多个移动提供商网络进行交互，通常与多个移动网络塔8620、830和840进行交互以连接到蜂窝网络803。

在图8中，云服务提供商网络810被示为能够经由客户网络802和网络808与客户端装置804A-E通信的远程网络(例如，云网络)。云服务提供商网络810充当向客户端装置804A-E和/或客户网络802提供附加计算资源的平台。在一个实现中，云服务提供商网络810包括具有一个或更多个服务器实例814的一个或更多个数据中心812。云服务提供商网络810还可以包括表示可以实现本公开的技术的可扩展计算资源的一个或更多个帧或集群(以及集群组)。具体地，所公开的技术涉及可以使用用于不同功能组件的基于云的系统来实现的DTL交易。

图9示出了可以用于实现本公开的功能、模块、处理平台、执行平台、通信装置和其他方法和过程或与本公开的功能、模块、处理平台、执行平台、通信装置和其他方法和过程一起使用的计算装置900。例如，图9中所示的计算装置900可以表示客户端装置或物理服务器装置，并且取决于计算装置的抽象级别而包括硬件或(一个或更多个)虚拟处理器。在一些实例(没有抽象)中，如图9所示，计算装置900及其元件各自涉及物理硬件。或者，在一些实例中，可以使用仿真器或虚拟机作为抽象级别来实现一个、更多个或所有元件。在任何情况下，无论距离物理硬件多少抽象级别，处于其最低级别的计算装置900可以在物理硬件上实现。

同样如图9所示，计算装置900可以包括一个或更多个输入装置930(诸如键盘、鼠标、触摸板或传感器读出器(例如，生物测定扫描仪))，以及一个或更多个输出装置915(诸如显示器、用于音频的扬声器或打印机)。一些装置也可被配置为输入/输出装置(例如，网络接口或触摸屏显示器)。

计算装置900还可以包括通信接口925(诸如可以包括有线通信组件和/或无线通信组件的网络通信单元)，该通信接口925可以通信地耦合到处理器905。网络通信单元可以利用各种专有或标准化网络协议中的任何一种(例如以太网、TCP/IP)，来任命许多协议中的一些，从而实现装置之间的通信。网络通信单元还可以包括一个或更多个收发器，收发器利用以太网、电力线通信(“PLC”)、

蜂窝和/或其他通信方法。

如图9所示，计算装置900包括诸如处理器905的包含一个或更多个硬件处理器的处理元件，其中每一硬件处理器可具有单个或多个处理器核。尽管图9中未示出，但是构成处理器905的处理元件还可以包括一个或更多个其他类型的硬件处理组件，例如图形处理单元(“GPU”)、专用集成电路(“ASIC”)、现场可编程门阵列(“FPGA”)和/或数字信号处理器(“DSP”)。

图9示出了存储器910可以可操作地并且通信地耦合到处理器905。存储器910可以是被配置为存储各种类型的数据的非瞬态介质。例如，存储器910可以包括一个或更多个存储装置920，存储装置920包括非易失性存储装置和/或易失性存储器。易失性存储器，例如随机存取存储器(“RAM”)，可以是任何合适的非永久存储装置。非易失性存储装置920可以包括一个或更多个磁盘驱动器、光学驱动器、固态驱动器(“SSD”)、磁带(tap)驱动器、闪存、只读存储器(“ROM”)和/或被设计为在掉电或关机操作之后的一段时间内维持数据的任何其他类型的存储器。在某些情况下，如果分配的RAM没有大到足以保存所有工作数据，则非易失性存储装置920可以用于存储溢出数据。非易失性存储装置920还可以用于存储程序，当选择执行这些程序时，将这些程序加载到RAM中。

本领域的普通技术人员知道，软件程序可以以用于各种软件平台和/或操作系统的各种计算语言来开发、编码和编译，并且随后由处理器905加载和执行。在一个实施方式中，软件程序的编译过程可以将以编程语言编写的程序代码变换成另一计算机语言，使得处理器905能够执行该编程代码。在编译过程之后，编码的指令然后可以作为计算机可执行指令或过程步骤从存储装置920、从存储器910加载到处理器905，和/或嵌入在处理器905内(例如，经由高速缓存或板载ROM)。处理器905可以被配置为执行所存储的指令或处理步骤，以便执行指令或处理步骤，从而将计算装置转换为非通用的、特定的、专门编程的机器或设备。存储的数据(例如由存储装置920存储的数据)可以在计算机可执行指令或过程步骤的执行期间由处理器905访问，以指示计算装置900内的一个或更多个组件。

用户接口(例如，输出装置915和输入装置930)可以包括显示器、位置输入装置(诸如鼠标、触摸板、触摸屏等)、键盘或其他形式的用户输入和输出装置。用户接口组件可以通信地耦合到处理器905。

方法600的各个部分可以根据需要重复。该方法的一个或更多个部分可以根据需要同时或以任何顺序执行。

尽管参考各种实现和利用描述了各实施例，但是将理解，这些实施例是说明性的，并且本发明主题的范围不限于它们。许多变型、修改、添加和改进是可能的。例如，可以使用各种合约参数来为一方或更多方和/或用户提供本文中的一个或更多个特征的各种组合，并且以各种组合和顺序来执行一个或更多个特征的各种组合。

可以为本文描述为单个实例的组件、操作或结构提供多个实例。通常，在示例性配置中作为单独组件呈现的结构和功能可以被实现为组合的结构或组件。类似地，作为单个组件呈现的结构和功能可以被实现为单独的组件。这些和其它变型、修改、添加和改进可落在本发明主题的范围内。

在以上描述和附图公开了不在本文的(一个或多个)权利要求的范围内的任何附加主题的情况下，本发明不是专用于公众的，并且保留提交一个或更多个申请以要求保护这样的附加发明的权利。尽管本文可以呈现非常窄的权利要求，但是应当认识到，本发明的范围比权利要求所给出的范围宽得多。在要求本申请的优先权的权益的申请中可以提交更广泛的权利要求。

Claims

1.一种基于计算机的文档管理系统(“DMS”)，用于基于对数字文档的子章节的管理来促进针对所述数字文档的数字协商过程，所述系统包括一个或更多个计算机处理器，所述一个或更多个计算机处理器被配置为执行指令以使得所述一个或更多个计算机处理器：

提供托管区域，所述托管区域可由包括第一用户和第二用户的多个用户同时访问，所述多个用户中的每一个具有对所述托管区域的基于角色的不同访问；

基于相关联的子章节生命周期来管理单个数字文档的多个子章节，所述单个数字文档还具有与任何子章节生命周期不同的文档生命周期；

基于与所述第一用户相关联的第一角色和所述第一用户的安全凭证来认证所述第一用户对所述多个子章节的第一子集的访问；

认证所述第二用户对所述多个子章节的第二子集的访问，所述第二子集与所述第一子集不同，所述认证基于与所述第一角色不同的第二角色，所述认证与所述第二用户以及所述第二用户的安全凭证相关联；

允许所述第一用户或所述第二用户基于经历更改的每个子章节的相应生命周期内的当前状态来更改可访问的子章节；

确定所述多个子章节中的所有子章节已经完成各自相应的子章节生命周期，以使所述单个数字文档前进到所述文档生命周期的签名状态；

接收来自与所述第一用户相关联的第一方的对处于所述签名状态的所述单个数字文档的第一签核，并接收来自与所述第二用户相关联的第二方的第二签核，以完成所述文档生命周期；以及

将所接收的第一签核和所述第二签核的指示存储在分布式交易总账中，以反映所述单个数字文档变成已签署的数字文档。

2.根据权利要求1所述的DMS，其中，使用区块链来实现分布式交易总账。

3.根据权利要求1所述的DMS，其中，所述一个或更多个计算机处理器还被配置为执行指令以使得所述一个或更多个计算机处理器：

基于所述第二角色和与未完成的子章节生命周期相关联的部分来阻止所述第二用户对所述多个子章节的所述第一子集的一部分的访问，其中，相应子章节生命周期未完成的子章节保持受限的访问，并且将完成的子章节提供为只读。

4.根据权利要求1所述的DMS，其中，所述多个子章节作为数字文件保持在所述托管区域内。

5.根据权利要求4所述的DMS，其中，所述托管区域是物理隔离的计算机存储区域。

6.根据权利要求4所述的DMS，其中，所述托管区域包括一组彼此逻辑上相关的单独的计算机存储区域。

7.根据权利要求1所述的DMS，其中，至少一个子章节生命周期被实现为有向图。

8.根据权利要求1所述的DMS，其中，所述文档生命周期被实现为有向图。

9.根据权利要求1所述的DMS，其中，所述第一用户是供应商，所述第二用户是客户端，且所述单个数字文档表示软件许可协议。

10.根据权利要求9所述的DMS，其中，所述一个或更多个计算机处理器还被配置为执行指令以使得所述一个或更多个计算机处理器：

向所述供应商提供导入接口以导入表示适用于所述软件许可协议的软件产品供应的结构化信息。

11.根据权利要求9所述的DMS，其中，所述一个或更多个计算机处理器还被配置为执行指令以使得所述一个或更多个计算机处理器：

向所述客户端提供导入接口，以导入表示从客户端网络内的软件应用的执行收集的软件产品使用的结构化信息。

12.根据权利要求1所述的DMS，其中，所述第一角色和所述第二角色选自以下角色：客户端作者、客户端审查者、客户端签署者、供应商作者、供应商审查者和供应商签署者。

13.根据权利要求1所述的DMS，其中，所述一个或更多个计算机处理器还被配置为执行指令以使得所述一个或更多个计算机处理器：

从所述第一用户或所述第二用户接收关于对所签署的数字文档的修改的更新的指示；以及

提供对所述托管区域的安全访问，以通过受所述修改影响的任何相关联的子章节生命周期来处理所述修改，以完成所述相关联的子章节生命周期，并且在实现所述修改之后将所签署的数字文档前进到所述签名状态。

14.一种包括指令的非暂时性机器可读存储介质，所述指令在被执行时使处理资源：

15.根据权利要求14所述的非暂时性机器可读存储介质，所述非暂时性机器可读存储介质还包括指令，所述指令在被执行时使所述处理资源：

提供对所述托管的安全访问，以通过受所述修改影响的任何相关联的子章节生命周期来处理所述修改，以完成所述相关联的子章节生命周期，并且在实现所述修改之后将数字文档前进到所述签名状态。

16.一种文档管理系统，包括：

一个或更多个计算机处理器；

计算机存储器；

包括多个子章节的数字文档，所述数字文档作为多个数字文件驻留在所述计算机存储器中，每个文件构成所述子章节中的相应一个；

驻留在所述计算机存储器中的指令集，所述指令集在由所述一个或更多个处理器执行时使所述一个或更多个处理器：

通过相应的子章节生命周期管理所述子章节中的每个子章节，并且通过文档生命周期管理所述数字文档；

作为管理的一部分，基于第一子章节生命周期或第二子章节生命周期的当前状态，允许第一认证用户中的至少一个更改第一子章节或第二认证用户更改第二子章节，所述更改使所述第一子章节或所述第二子章节通过相应的子章节生命周期前进；

接收代表所述第一认证用户的第一签核和代表所述第二认证用户的第二签核以完成所述文档生命周期；以及

将所述文档生命周期的完成的指示存储在分布式交易总账中。