CN114556317A - 通过版本散列链接图形的文档跟踪 - Google Patents

Abstract

本发明的实施方案提供了跟踪文档版本控制的能力。在对第一文档版本执行打开操作之前，生成第一前散列。在执行所述打开操作之后，生成第一后散列。在执行保存操作之前，获取所述第一个前散列，且在执行之后(产生第二文档版本)，生成所述第二文档版本的第二后散列。生成版本散列链接图形(VHLG)，并且所述VHLG包括不同文档版本的文档节点，其中每一节点包括所述文档版本的散列、对应于执行操作的用户或应用程序的用户‑应用程序节点，以及连接节点(例如，其标识所述操作及/或文档谱系)的边缘。基于所述VHLG，提供文档的完整历史记录。

Description

通过版本散列链接图形的文档跟踪

相关申请的交叉引用

本申请涉及以下共同未决及共同转让的专利申请，所述申请以引用方式并入本文中：

美国专利申请第62/913,380号，于2019年10月10日提出申请，发明人为RobertMaguire及Ravinder Krishnaswamy，标题为“通过版本散列链接图形的文档跟踪(Documenttracking through Version Hash Linked Graphs)”，代理人案号为30566.0585USP1。

发明背景

1.技术领域

本发明总体上涉及跟踪文档版本，并且具体地，涉及用于使用文档散列来连接文档版本的方法、系统、设备及制品，所述文档散列用于构造可进行进一步分析及利用的图形。

2.相关技术的描述

在当今的云连接及多装置世界中，通过共享文档及文档内容进行协作是常态。此种协作需要对文档及文档内容版本进行协调访问。此外，以高效且全面的方式对协作者及协作本身的分析(例如，协作者在协作环境中进行交互/保存/编辑/查看文件/文档的内容及方式等)能够了解应用程序产品特征开发。就这一点来说，协作使得以下内容对于提供文档查看及编辑应用的业务变得越来越重要：

1.理解用户及行业的不同分段如何交互，以便帮助企业优先考虑对产品特征的投资；及

2.提供生产力增强工具，以解决其用户在共享文档上进行协作的挑战，诸如及时通知文档编辑及文档版本协调。

下文描述现有技术中存在的将基于散列的链接用于协作场景的技术。这些为本发明中的关键新概念及其解决的问题空间提供了背景。

链式散列的使用

通过散列来链接数据版本的理念并不新鲜。GIT的底层机制使用提交散列并将提交散列链合在一起以生成提交的DAG(有向无环图)，以便仅使用散列来有效地查找提交上下文。图1示出GIT中所使用的散列提交的DAG。如所示出，每次将改变提交到代码(称为“提交”)时，都会拍摄快照，并且可应用或回滚两个快照之间的改变集。每一快照以从快照的内容(例如，实际内容及一些元数据，诸如呈递时间、作者信息、父项等)导出的提交/散列ID102命名。GIT中的改变流是改变集的有序列表，因为所述改变流被一个接一个地应用以从一个快照/提交102转到下一个。指向特定快照的指针被称为“分支”，并且“头”104指向最后从工作区检出的分支(例如，主分支106)的位置。可在可最终合并到主分支106中的其他分支108中定义不同特征。可在任何有效快照版本110至112上创建其他分支106至108。另外，如所示出，提交102可具有多个父项114，并且每一父项可具有多个子项116。

然而，此种链式散列所缺少的是提供更深层次的上下文以便对执行提交的用户/角色/行业有一般理解的能力以及对散列有不仅仅用于查找提交上下文的能力。

在加密货币及分布式账本世界中，基于散列值的不同链合形式是算法的基础。图2示出如加密货币中所使用的散列链合。区块链由彼此链接204的各种区块202组成。散列树(也称为默克尔树(Merkle tree))对区块链200数据进行编码。在区块链200网络上发生的每个事务206都具有与其相关联的散列208，所述散列存储在树状结构中，使得每一散列208链接到其父项，从而遵循父子树状关系。区块202中的所有事务散列208也被散列化，从而产生默克尔根210。默克尔根210包含关于存在于相应区块202上的每个单个事务散列208的所有信息。每一区块也可具有一次性随机数212(“数字仅使用一次”)。一次性随机数212是添加到散列化区块202的数字，当被重新散列化时，所述数字满足难度级别限制并且是区块链矿工正在求解的数字。每一区块202还包含时间戳214(例如，针对当前时间)，所述时间戳用于确立区块的有效性(例如，如果时间戳大于前11个区块的中值时间戳并且小于经网络调整的时间+2小时，那么所述时间戳可被接受为有效)。此外，每一区块202的先前散列216是先前区块202的散列(例如，先前区块的散列的标识/指针)。

然而，虽然散列函数在安全地表示数据区块的链接方面是区块链算法的基础，但散列函数无法提供本发明的结构的优点(如下文所描述)。

数据管理解决方案

除了使用如上文所描述的链式散列以外，现有技术的数据管理解决方案也可用于实现协作。然而，现有技术的数据管理解决方案(例如，产品数据管理-PDM应用程序)要求用户使其数据在应用程序的约束内工作以进行版本管理及通知。

鉴于以上情况，所需要的是能够实现协作的灵活性以及对此种协作的分析，此种协作是有效的并且不受限于特定应用程序或文档存储库。

发明内容

本发明的实施方案提供一种用以通过使用文档散列及/或其内容的唯一标识符来构造图形从而连接文档版本的数据结构。此种数据结构及图形可用于：

·数据分析处理，以通过其对共同数据的访问来推断行业及用户类型的协作网络。这解决了理解用户及行业的不同分段如何彼此交互的能力(例如，帮助企业优先考虑投资产品特征)。

·应用程序，以检测过期版本文档访问、文档更新通知及文档版本协调以及汇总组织或项目中的文档使用统计信息。这解决了提供生产力增强工具的能力，所述工具解决了用户在共享文档上协作的挑战。

附图说明

现在参考附图，其中相同参考符号自始至终表示对应部分：

图1示出在现有技术的GIT中所使用的散列提交的DAG；

图2示出在现有技术的加密货币中所使用的散列链合；

图3示出根据本发明的一个或多个实施方案的示范性版本散列链接图形；

图4A示出根据本发明的一个或多个实施方案的可访问的示范性谱系(lineage)；

图4B示出根据本发明的一个或多个实施方案的基于图4的版本散列链接图形而链接用户的能力；

图5示出根据本发明的一个或多个实施方案的可如何使用VHLG来推断通过其对共同谱系的访问来协作的业务的示例；

图6示出版本散列链接图形/树，其中从各种不同位置/装置访问的数据利用相同签名/散列/GUID访问版本信息；

图7示出根据本发明的一个或多个实施方案的用于跟踪文档版本控制的逻辑流程；

图8是用于实现本发明的一个或多个实施方案的示范性硬件及软件环境；且

图9示意性地示出根据本发明的一个或多个实施方案的典型分布式/基于云的计算机系统。

具体实施方式

在以下描述中，参考随附图式，所述随附图式形成本发明的一部分并通过说明示出本发明的几个实施方案。应理解，在不脱离本发明的范围的情况下，可利用其他实施方案并且可进行结构改变。

综述

基于文件的文档(例如DWG文件)基于在其内容上应用散列算法或在每次更新文档时创建新的GUID而具有与其相关联的唯一签名。与额外操作及使用上下文信息链接的连续文档版本的散列用于生成可连接用户与公司的依赖图。还可分析依赖图，以提供关于社区、协作者及所使用的特征(及潜在扩展区)的有用信息。

版本散列链接图形

本发明的实施方案将(文档的)连续版本信息(即，在操作之前及之后，例如，编辑时创建、接着保存的版本)链合在一起。所述链可用于生成/获得文档的完整历史记录(例如，无需进行实际链接或存储文档本身)。如本文中所使用，所述链被称为版本散列链接图形(VHLG)。图3示出根据本发明的一个或多个实施方案的示范性版本散列链接图形。版本散列链接图形300包括对应于对文档节点304(即，文档节点304A及304B，统称为文档节点304)进行访问的用户或应用程序的节点302至304(例如，用户节点302A及302B，统称为用户节点302)、指示操作并包含例如访问时间或产品版本等额外元信息的边缘306，以及表示版本关系的边缘308。

如图3中所示出，文档节点304由表示“版本”(或“下代版本”)关系的箭头308连接(而边缘306是生成或访问版本的操作)。最终用户节点302基于参考/编辑操作而连接到文档版本(例如，用户302打开或保存文档版本)。为了从应用程序构造图形300，需要将少量额外信息(与正被记录的操作相关联的散列或id)发送到服务或后端。这将允许后端依据从多个用户获得的数据组装图形。在本发明的实施方案中，信息包括操作之前及操作之后的散列。举例来说，以下格式可用于记录构造图形所需的信息：

日志项：(匿名-用户-id，平台，文件-操作，散列-之前，散列-之后，时间)

以下各项表示可被记录/发送到图3的服务/后端的日志项：

(u88，“台式机-win”，“打开”，“EF8A09D”，“EF8A09D”，9310028)

(u88，“台式机-win”，“保存”，“EF8A09D”，“D9A22B”，9320031)

(u89，“移动装置-ios”，“打开”，“D9A22B”，“D9A22B”，10311299)

这些日志项表示用户u88 302A已打开文档EF8A09D 304A，且接着保存文档D9A22B304B(例如，文档EF8A09D 304A被修改并使用新散列保存为D9A22B 304B)。此后，用户302B打开文档304B。以上日志项标识用户(u88或u89)、平台(台式机windows或移动装置ios)、操作(打开或保存)、操作之前及之后的散列(即，EF8A09D及D9A22B)，以及执行操作的时间(9310028、9320031或10311299)。通过比较/链接不同散列(例如，用户u88及u89两者在与每一用户相关联的日志项中都具有散列D9A22B)，可将共享相同数据的不同平台上的不同用户链接在一起。

如本文中所使用，可使用任何类型的散列算法来生成散列，只要算法产生表示文档304的唯一标识符(例如，散列或GUID)。此外，日志项是存储/提供给服务/后端并独立于数据本身的信息。就这一点来说，仅日志项/散列信息被存储且可用于重建/生成文档的历史记录。

图3的示范性图形(及其他VHLG)将跨时间及多个用户而按比例缩放。通过对作为文档版本(相关版本或衍生版本)“谱系”的一部分的文档进行访问，存在一种自然的协作理念。图4A示出根据本发明的一个或多个实施方案的可访问的示范性谱系；如所示出，台式机用户Bob 402已打开文件404，然后保存/导出所述文件，从而创建版本406。台式机用户Scott 408已打开文件410，然后保存并导出文件410，从而产生新版本412(如所示出，版本404、406、410及412全部是VHLG中的散列)。Bob 402也参考了版本412。web用户Joe 414及John 416都已打开版本412。台式机用户Mary 418已打开版本406，并将其保存/导出，从而创建也已由移动装置用户Yan 422打开的版本420。使用日志项中的信息(例如，经由图形)，可容易地确定文档版本的谱系424及426。谱系424由不同文档版本404、406及420组成，而谱系426由文档版本410及412组成。散列及操作信息(例如，打开、保存/导出、参考)(以及额外信息)可用于确定谱系。图4B示出根据本发明的一个或多个实施方案的基于图4的VHLG 400而链接用户402、408、414、416、418和422的能力。

示范性谱系/历史记录确定可通过以下示例来示出：可从CAD(计算机辅助设计)绘图发布PDF(便携式文档格式)文件。为CAD绘图(散列A)以及PDF(散列B)创建散列，并且图形的边缘将连接两者。如果用户在不知道PDF的来源的情况下打开PDF，那么可再次计算/获得PDF的散列(产生散列B)。然后可使用所计算散列(散列B)来查询图形并检索边缘/确定散列B源自散列A。就这一点来说，利用前散列值及后散列值，有可能确定文档版本的历史记录/谱系，而无需访问/使用创建文档的应用程序(例如，CAD应用程序)并且文档无需驻留/存在于同一存储库中。换句话说，仅需查询VHLG即可确定文档历史记录。

大规模使用版本散列链接图形的分析及见解

通过大规模构造图形，并用数据(包括更多用户上下文，诸如行业类型、公司类型等，以及具有访问时间、产品版本等的边缘)对所述图形进行扩增，有可能推断并获得对社区的见解，所述社区进行协作并理解随时间的访问模式。

图5示出根据本发明的一个或多个实施方案的可如何使用VHLG来推断通过其对共同谱系的访问来协作的业务的示例。更特定来说，图5示出可从VHLG推断的行业类型协作的示例。每一树图标节点502表示一个谱系(通过其版本链来相关的文档集合)。每一公司/行业类型504A至504L(统称为行业类型504)由图标表示。不同类型的示例可包括业务504A、工业机械504B、未知项504C、消费产品504D、教育504E、采矿504F、建筑504G、施工服务504H、工程服务提供商504I、架构服务504J、建筑产品及制作504K、民用基础设施504L等。边缘506的厚度(即，边缘506A至506C统称为边缘506)与公司对谱系的访问次数成比例。举例来说，与由边缘504B表示的访问相比，边缘504A表示对谱系502的访问更少(例如，通过连接到边缘504A的行业类型)，边缘504B具有比由边缘506C表示的访问更少的访问。

图5中所示出的示例可使用大数据分析(例如，APACHE SPARK及NEO4J(图形数据库))来生成。此种分析可用于评估重点开发的特征(例如，只要一些用户与来自一组学科的很大一部分用户在某些文档类型上或通过文档上的特定特征或操作进行交互)。

使用版本散列链接图形的生产力及数据管理最终用户特征

本发明的额外实施方案利用VHLG推动最终用户特征。对于利用数据协作的一组用户(例如，公司内的用户)，可构造VHLG以捕获访问模式及文件版本之间的依赖性(如上文所描述)。重要的是，实际文件可驻留在任何地方。举例来说，如果在移动装置、web浏览器或本地驱动器上对数据进行访问——只要文件中的内容等同，那么所述数据就具有相同签名。

图6示出版本散列链接图形/树，其中从各种不同位置/装置访问的数据利用相同签名/散列/GUID访问版本信息。VHLG 600被示出为从本地驱动器602、移动装置604及web606对所述结构进行访问。使用结构600(当用户访问文件时)，通过参考VHLG 600，本发明的实施方案可判断用户是否正在更新最新版本，是否有新版本可供参考等等。举例来说，用户1 608及用户2 610两者都从其本地台式计算机602访问了由散列表示的文件612。文件612是文件614(由散列E7D78D表示)的父项，而文件614又是文件616(由散列C7890表示)及文件618(由散列8977AA表示)的父项。用户3 620及用户4 622两者在访问相同文件版本618，如可由相同散列8977AA所确定。值得注意的是，即使用户3 620在移动装置604上并且用户4622在web 606上，这两者访问的文件内容618也是等同的(可通过散列8977AA确认)。

VHLG的概念及应用可扩展到操作及不同格式。举例来说，用户可从DWG导出为PDF或将DWG导入到REVIT或INVENTOR文档中。

基于对VHLG 600的分析，可生成允许用户以可理解及全面方式使分析可视化的图形用户界面(GUI)。在第一示例中，GUI可(部分地)由VHLG本身组成(例如，如图3及图4A所示出)。替代地，GUI可由VHLG的各种不同格式/表示或其他组成。举例来说，可基于颜色及/或图案来区分VHLG的GUI的不同图标及边缘(反映不同类型/装置等)。在特定示例中，不同装置类型可由不同颜色表示(例如，绿色表示台式机，红色表示web，蓝色表示移动装置)。在另一示例中，一种颜色(例如，紫色)可用于指定特定文件版本的指纹，而所述颜色(紫色)节点的链可反映特定谱系。另外，不同大小的不同箭头(例如，结合或独立于边缘本身)可反映对特定节点/指纹版本的访问次数)。

虽然可在一个GUI中提供对VHLG的描述，但其他GUI可集中于数据/数据分析的特定方面。举例来说，GUI可呈现反映由不同装置访问的数据部分的简单图表(例如，其中x轴用于每谱系的文件版本的最小数目，并且y轴反映由一个以上装置访问的谱系的百分比)。在另一示范性实施方案中，可生成反映访问模式的时间序列(热度)图表(其中y轴为时间片，其中所述图表示出跨不同公司/公司类型的访问频率，并允许查看者快速地确定通信是同步还是异步以及大多数协调需求集中在哪个文档上)。

逻辑流程

图7示出根据本发明的一个或多个实施方案的用于跟踪文档版本控制的逻辑流程。

在步骤702处，在对第一文档版本执行打开(或参考)操作之前，生成第一文档版本的第一前散列。

在步骤704处，用户或应用程序执行打开操作。

在步骤706处，在执行打开操作之后，生成第一文档版本的第一后散列。

在步骤708处，在对第一文档版本执行保存操作之前，获取第一文档版本的第一前散列(例如，可再次执行散列函数，从而产生相同散列ID，及/或系统可辨识出打开操作没有改变第一文档版本，并且因此，获取/获得相同的第一前散列)。

在步骤710处，用户或应用程序对第一文档版本执行保存操作，从而产生第二文档版本。

在步骤712处，在执行保存操作之后，生成第二文档版本的第二后散列。

在步骤714处，生成(或扩增)版本散列链接图形(VHLG)。VHLG包括：第一文档版本节点(包括第一前散列)；第二文档版本节点(包括第二后散列)；用户-应用程序节点，其对应于执行打开操作及保存操作的用户及应用程序；打开操作边缘，其将用户-应用程序节点连接到第一文档版本节点(其中打开操作边缘标识打开操作)；保存操作边缘，其将用户-应用程序节点连接到第二文档版本节点(其中保存操作边缘标识保存操作)；及文档边缘，其将第一文档版本节点连接到第二文档版本节点。

VHLG的生成/扩增可包括将打开操作的信息及保存操作的信息发送到VHLG生成服务(其基于所述信息而生成VHLG)。每一操作的信息包括操作之前的散列、操作之后的散列及操作的标识。此种信息可在日志项中指定/提供，所述日志项包括对应于用户及应用程序的匿名用户标识、用户或应用程序所使用的平台、操作的标识、前散列、后散列，及执行操作的时间。举例来说，打开操作的信息可由第一前散列、第一后散列及打开操作的标识组成。对应日志项可包括对应于用户及应用程序的匿名用户标识、用户或应用程序所使用的平台、打开操作的标识、第一前散列、第一后散列，及执行打开操作的时间。因此，可通过个别记录的日志项来扩增VHLG，并且可根据记录在数据库(例如，SPARK)或其他数据聚合后端中的日志项按需生成最新图形结构。

类似于打开操作，保存操作的信息可由第一前散列、第二后散列及保存操作的标识组成。对应日志项可由对应于用户及应用程序的匿名用户标识、用户或应用程序所使用的平台、打开操作的标识、第一前散列、第二后散列，及执行保存操作的时间组成。

在步骤716处，提供基于VHLG的文档的完整历史记录。

在任选步骤718处，可提供(例如，对社区检测及协作网络的)见解/(例如，用于对文档进行共享及协作的)最终用户特征。

可注意到，VHLG跨时间及多个用户或多个应用程序而按比例缩放。在步骤718处，一旦按比例缩放，则可基于VHLG而确定示范性见解、谱系。在示范性实施方案中，此种谱系可由通过版本链来相关的文档集合组成，其中所述集合由第一文档版本及第二文档版本组成，并且版本链包括文档边缘。

在步骤718处，额外见解/特征可包括/提供用上下文数据(例如，行业类型、公司类型等)对第一文档版本节点及第二文档版本节点进行扩增。基于谱系及上下文数据，可确定协作的社区(例如，行业类型)。在替代实施方案中，可基于VHLG而确定随时间的访问模式。

还可注意到，文档的数据可独立于VHLG而存储(例如，实际文件可驻留在任何地方)。就这一点来说，无论使用何种装置平台(例如，台式机、移动装置、web)来对第一文档版本进行访问，第一前散列都保持相同(即，只要第一文档版本中的内容等同)。类似地，无论使用何种装置平台来对第二文档版本进行访问，第二后散列都保持相同(即，只要第二文档版本中的内容等同)。

在步骤718处提供的额外见解/特征可包括由VHLG的可视化组成的图形用户界面(GUI)，所述VHLG显示第一文档版本与第二文档版本之间的访问模式及依赖性。可将此种GUI提供给协作用户。

除了上述内容以外，步骤718中的协作特征可包括当用户或应用程序对第一文档版本或第二文档版本进行访问时执行的操作。特定来说，基于VHLG，可执行关于第一文档版本或第二文档版本是否是文档的最新版本的确定(例如，查VHLG)。然后可将确定的结果告知访问用户/应用程序。

优点

本发明的实施方案在包括台式机-web-移动装置工作流、绘图生命周期及协作集群的各种不同上下文中提供优于现有技术的优点。

台式机-web-移动装置工作流涉及文件如何在台式计算机上的应用程序(例如，AUTOCAD DESKTOP)、web上的应用程序的基于web的版本(例如，AUTOCAD WEB)、移动装置上的应用程序的基于移动装置的版本(例如，AUTOCAD MOBILE)之间移动，以及这些产品中的每一者适合于跨平台工作流中的何处。在这种上下文中，分析法可回答以下问题：

·在台式机上创建及编辑的绘图有多少(每周/每月)在web上、在移动装置上打开？(或者反过来，有多少新绘图被创建，且接着在web上、在移动装置上再次打开？)

·台式机-web或台式机-移动装置之间的绘图交换间隔范围通常是多少？(例如，间隔范围＝dwg在台式机上打开、两天后在移动装置上打开，或者4小时后在web上打开等。)

·当将绘图发送到web及移动装置时，所述绘图会如何改变？这些用户在每一平台上进行什么活动？我们能否通过单个用户(同一个人使用3个不同平台)与团队(不同用户使用不同平台)用例来区分这一点？

·首先在移动装置或web上创建、然后再放回台式机的dwg有多少？

绘图生命周期涉及单个绘图(例如，DWG文件)如何随时间演变。这可包括绘图如何进行版本控制、绘图如何被增强或标记，以及绘图由谁编辑。可使用分析法来回答关于绘图生命周期的以下问题：

·我们能否看到每DWG的不同层的协作者数目？举例来说，1-2、2-10、10-20等。

·我们能否将DWG的各阶段与典型项目阶段相关，包括随时间的演变(方案设计、设计开发、施工文档编制等)？

·我们能否将DWG标识为同一项目的一部分？

·“相同”DWG多久改变文件名称一次？(客户正使用“另存为”进行项目归档、DWG记录、版本控制等)。如何筛选出模板及标准DWG(例如，在多个项目中重复的详细表单等)？

·我们能否推断出其他工具中发生的关于带外协作者的任何事情？(例如，REVIT、BLUEBEAM、纸张等)

·我们能否识别用户多久从现有DWG启动项目一次？

·不同协作者在不同阶段如何访问文件以及在哪个平台上访问文件？

协作集群(也称为协作角色集群)涉及找到人们如何协作的相似性。是否有些人是超级分享者，而其他人是终点？这些超级分享者有什么共同之处？可使用分析法来回答关于协作集群的以下问题：

·用户集群：客户在X时间段内处理了多少DWG？

·用户集群(协作层)：客户与多少人交换了DWG？是否有可能将此频率划分为内部(设计师到起草人)及外部(承包商、项目经理等)协作者？

·用户集群：我们能否定义超级协作者？协作最多的是什么类型的用户？什么行业？他们使用了什么技术？

·我们能否标识出生命周期中更多用户更频繁地彼此交互的“热”协作时间段？

·对这些问题中的任一者进行更深入删减：如果是这样，那么他们在哪个存储提供商上(本地/云)？他们是在同一个环境(例如，1个办公室)还是多个环境中/在家？他们是否使用参照来分解所述工作？绘图中有多少参照？什么文件格式？

·哪些平台具有哪些协作故事的片段？

·我们能否绘制出协作趋势(跨用户生态系统中的产品)以及哪个阶段具有最多来回协作，或者完成哪个阶段用时最长？

硬件实施方案

图8是用于实现本发明的一个或多个实施方案的示范性硬件及软件环境800(称为计算机实现的系统及/或计算机实现的方法)。硬件及软件环境包括计算机802并且可包括外围设备。计算机802可以是用户/客户端计算机、服务器计算机，或者可以是数据库计算机。计算机802包括硬件处理器804A及/或特殊用途硬件处理器804B(替代地下文中统称为处理器804)及存储器806，诸如随机存取存储器(RAM)。计算机802可耦合到其他装置及/或与其他装置集成，其他装置包括输入/输出(I/O)装置，诸如键盘814、光标控制装置816(例如，鼠标、指向装置、笔及平板计算机、触摸屏、多点触摸装置等)及打印机828等。在一个或多个实施方案中，计算机802可耦合到或可包括便携式或媒体观看/收听装置832(例如，MP3播放器、IPOD、NOOK、便携式数字视频播放器、蜂窝装置、个人数字助理等)。在又一实施方案中，计算机802可包括在各种平台及操作系统上执行的多点触摸装置、移动电话、游戏系统、支持互联网的电视、电视机顶盒或其他支持互联网的装置。

在一个实施方案中，计算机802通过硬件处理器804A在操作系统808的控制下执行由计算机程序810(例如，计算机辅助设计[CAD]应用程序)定义的指令来操作。计算机程序810及/或操作系统808可存储在存储器806中，且可与用户及/或其他装置对接以接受输入及命令，并且基于此类输入及命令以及由计算机程序810及操作系统808定义的指令而提供输出及结果。

输出/结果可以呈现在显示器822上或提供给另一装置以进行呈现或进一步处理或动作。在一个实施方案中，显示器822包括具有多个可单独寻址的液晶的液晶显示器(LCD)。替代地，显示器822可包括具有一起驱动以形成全色像素的红色、绿色及蓝色二极管集群的发光二极管(LED)显示器。响应于由处理器804依据计算机程序810及/或操作系统808的指令对输入及命令的应用而生成的数据或信息，显示器822的每一液晶或像素改变为不透明或半透明状态，以在显示器上形成图像的一部分。图像可以通过图形用户界面(GUI)模块818提供。尽管GUI模块818被描绘为单独模块，但执行GUI功能的指令可驻留在或分布在操作系统808、计算机程序810中，或者利用特殊用途存储器及处理器来实现。

在一个或多个实施方案中，显示器822与计算机802集成在一起/集成到计算机802中，并且包括具有触摸感测表面(例如，跟踪荚体(pod)或触摸屏)的多点触摸装置，所述触摸感测表面具有辨识与所述表面的两个或更多个接触点的存在的能力。多点触摸装置的示例包括移动装置(例如，IPHONE、NEXUS S、DROID装置等)、平板计算机(例如，IPAD、HPTOUCHPAD、SURFACE装置等)、便携式/手持式游戏/音乐/视频播放器/控制台装置(例如，IPOD TOUCH、MP3播放器、NINTENDO SWITCH、PLAYSTATION PORTABLE等)、触摸台，以及壁(例如，其中通过丙烯酸脂及/或玻璃投影图像，且然后用LED从背后照明图像)。

由计算机802根据计算机程序810指令执行的一些操作或所有操作可在特殊用途处理器804B中实现。在此实施方案中，一些或所有计算机程序810指令可经由存储在特殊用途处理器804B内的只读存储器(ROM)、可编程只读存储器(PROM)或快闪存储器中或者存储器806中的固件指令来实现。特殊用途处理器804B也可通过电路设计来硬连线以执行一些或所有操作来实现本发明。此外，特殊用途处理器804B可以是混合处理器，其包括用于执行功能子集的专用电路系统以及用于执行诸如响应于计算机程序810指令的更一般功能的其他电路。在一个实施方案中，特殊用途处理器804B是专用集成电路(ASIC)。

计算机802还可实现编译器812，其允许以诸如C、C++、Assembly、SQL、PYTHON、PROLOG、MATLAB、RUBY、RAILS、HASKELL或其他语言等编程语言编写的应用程序或计算机程序810被翻译成处理器804可读代码。替代地，编译器812可以是直接执行指令/源代码、将源代码翻译成被执行的中间表示或者执行所存储预编译代码的解释器。此种源代码可用多种编程语言编写，诸如JAVA、JAVASCRIPT、PERL、BASIC等。在完成之后，应用程序或计算机程序810使用了使用编译器812生成的关系及逻辑来访问及操纵从I/O装置接受并存储在计算机802的存储器806中的数据。

计算机802还任选地包括外部通信装置，诸如调制解调器、卫星链路、以太网卡，或用于从其他计算机802接受输入并向其他计算机802提供输出的其他装置。

在一个实施方案中，实现操作系统808、计算机程序810及编译器812的指令被有形地体现在非暂时性计算机可读介质中，例如数据存储装置820，其可包括一个或多个固定或可移动数据存储装置，诸如zip驱动器、软盘驱动器824、硬盘驱动器、CD-ROM驱动器、磁带驱动器等。此外，操作系统808及计算机程序810由计算机程序810指令组成，当由计算机802访问、读取及执行时，所述指令使得计算机802执行用以实现及/或使用本发明所需的步骤，或者将指令程序加载到存储器806中，因此创建特殊用途数据结构，从而致使计算机802操作为执行本文中所描述的方法步骤的经特定编程的计算机。计算机程序810及/或操作指令也可有形地体现在存储器806及/或数据通信装置830中，由此制造根据本发明的计算机程序产品或制品。如此，如本文所使用的术语“制品”、“程序存储装置”及“计算机程序产品”旨在涵盖可从任何计算机可读装置或介质访问的计算机程序。

当然，所属领域的技术人员将认识到，以上部件的任何组合或者任何数目的不同部件、外围设备及其他装置可与计算机802一起使用。

图9示意性地示出使用网络904将客户端计算机902连接到服务器计算机906的典型分布式/基于云的计算机系统900。资源的典型组合可包括：网络904，其包括因特网、LAN(局域网)、WAN(广域网)、SNA(系统网络架构)网络等；客户端902，其是个人计算机或工作站(如图8中所陈述)；和服务器906，其是个人计算机、工作站、小型计算机或大型计算机(如图8中所陈述)。然而，可注意到，诸如蜂窝网络(例如，GSM[全球移动通信系统]或其他)、基于卫星的网络或者任何其他类型的网络等不同网络可用于根据本发明的实施方案来连接客户端902与服务器906。

诸如因特网等网络904将客户端902连接到服务器计算机906。网络904可利用以太网、同轴电缆、无线通信、射频(RF)等来连接客户端902与服务器906并提供客户端902与服务器906之间的通信。此外，在基于云的计算系统中，客户端902及服务器计算机906中的资源(例如，存储装置、处理器、应用程序、存储器、基础设施等)可被客户端902、服务器计算机906及跨一个或多个网络的用户共享。资源可被多个用户共享，并且可根据需求动态地重新分配。就这一点来说，云计算可被称为用于对可配置计算资源的共享池进行访问的模型。

客户端902可执行客户端应用程序或web浏览器并与执行web服务器910的服务器计算机906通信。此种web浏览器通常是诸如MICROSOFT INTERNET EXPLORER/EDGE、MOZILLAFIREFOX、OPERA、APPLE SAFARI、GOOGLE CHROME等程序。此外，在客户端902上执行的软件可从服务器计算机906下载到客户端计算机902并安装为web浏览器的插件或ACTIVEX控件。因此，客户端902可利用ACTIVEX部件/部件对象模型(COM)或分布式COM(DCOM)部件在客户端902的显示器上提供用户界面。web服务器910通常是诸如MICROSOFT’S INTERNETINFORMATION SERVER等程序。

web服务器910可托管可执行脚本的活动服务器页面(ASP)或互联网服务器应用程序编程接口(ISAPI)应用程序912。脚本调用执行业务逻辑的对象(称为业务对象)。然后，业务对象通过数据库管理系统(DBMS)914操纵数据库916中的数据。替代地，数据库916可以是客户端902的一部分或直接连接到客户端902，而不是通过网络904与数据库916通信/从数据库916获得信息。当开发者将业务功能性囊封到对象中时，系统可称为部件对象模型(COM)系统。因此，在web服务器910(及/或应用程序912)上执行的脚本调用实现业务逻辑的COM对象。此外，服务器906可利用MICROSOFT’S TRANSACTION SERVER(MTS)经由诸如ADO(活动数据对象)、OLE DB(对象链接及嵌入数据库)或ODBC(开放数据库连接性)等接口对存储在数据库916中的所需数据进行访问。

一般来说，这些部件900至916全部包括逻辑及/或数据，其体现在装置、介质、信号或载体中/可从装置、介质、信号或载体中检索，例如，数据存储装置、数据通信装置、远程计算机或者经由网络或经由另一数据通信装置耦合到计算机的装置等。此外，此逻辑及/或数据在被读取、执行及/或解释时导致用以实现及/或使用本发明所需的步骤被执行。

尽管本文中提到了术语“用户计算机”、“客户端计算机”及/或“服务器计算机”，但应理解，此类计算机902及906可以是可互换的，并且还可包括具有有限或完全处理能力的瘦客户端装置、诸如手机、笔记本计算机、袖珍计算机、多点触摸装置等便携式装置，及/或具有适合处理、通信及输入/输出能力的任何其他装置。

当然，所属领域的技术人员将认识到，以上部件的任何组合或者任何数目的不同部件、外围设备及其他装置可与计算机902及906一起使用。本发明的实施方案被实现为客户端902或服务器计算机906上的软件/CAD应用程序。此外，如上文所描述，客户端902或服务器计算机906可包括具有基于多点触摸的显示器的瘦客户端装置或便携式装置。

结论

对本发明的优选实施方案的描述到此结束。下文描述了用于实现本发明的一些替代实施方案。例如，任何类型的计算机(诸如大型计算机、小型计算机或个人计算机等)或计算机配置(诸如分时大型计算机、局域网等)或独立个人计算机都可与本发明一起使用。总之，本发明的实施方案提供了至少一个或多个以下特征：

1.基于可连接用户与公司的文档版本的依赖图(VHLG)的理念；

2.使用VHLG用于对社区检测及协作网络的见解；及

3.使用VHLG推动文档共享及协作的最终用户特征。

出于说明及描述目的，已呈现本发明的优选实施方案的前述描述。前述描述并不旨在为详尽的或将本发明限制于所公开的精确形式。鉴于上述教导，许多修改及变化都是可能的。旨在使本发明的范围不受此具体实施方式限制，而是受所附权利要求书限制。

Claims (20)

1.一种用于跟踪文档版本控制的计算机实现的方法，其包括：

(a)在对第一文档版本执行打开操作之前，生成所述第一文档版本的第一前散列；

(b)用户或应用程序执行所述打开操作；

(c)在执行所述打开操作之后，生成所述第一文档版本的第一后散列；

(d)在对所述第一文档版本执行保存操作之前，获取所述第一文档版本的所述第一前散列；

(e)所述用户或所述应用程序对所述第一文档版本执行保存操作，从而产生第二文档版本；

(d)在执行所述保存操作之后，生成所述第二文档版本的第二后散列；

(e)生成版本散列链接图形(VHLG)，其中所述VHLG包括：

(i)第一文档版本节点，其包括所述第一前散列；

(ii)第二文档版本节点，其包括所述第二后散列；

(iii)用户-应用程序节点，其对应于执行所述打开操作及所述保存操作的所述用户或应用程序；

(iv)打开操作边缘，其将所述用户-应用程序节点连接到所述第一文档版本节点，其中所述打开操作边缘标识所述打开操作；

(v)保存操作边缘，其将所述用户-应用程序节点连接到所述第二文档版本节点，其中所述保存操作边缘标识所述保存操作；及

(vi)文档边缘，其将所述第一文档版本节点连接到所述第二文档版本节点；以及

(f)基于所述VHLG而提供文档的完整历史记录。

2.根据权利要求1所述的计算机实现的方法，其中所述生成所述VHLG包括：

将所述打开操作的信息及所述保存操作的信息发送到VHLG生成服务，其中：

所述打开操作的所述信息包括所述第一前散列、所述第一后散列及所述打开操作的标识；且

所述保存操作的所述信息包括所述第一前散列、所述第二后散列及所述保存操作的标识；及

所述VHLG生成服务基于所述信息而生成所述VHLG。

3.根据权利要求2所述的计算机实现的方法，其中：

所述打开操作的所述信息包括第一日志项；

所述第一日志项包括：

对应于所述用户或所述应用程序的匿名用户标识；

所述用户或所述应用程序所使用的平台；

所述打开操作的所述标识；

所述第一前散列；

所述第一后散列；及

执行所述打开操作的时间；

所述保存操作的所述信息包括第二日志项；

所述第二日志项包括：

对应于所述用户或所述应用程序的所述匿名用户标识；

所述用户或所述应用程序所使用的所述平台；

所述保存操作的所述标识；

所述第一前散列；

所述第二后散列；及

执行所述保存操作的时间。

4.根据权利要求1所述的计算机实现的方法，其还包括：

跨时间及多个用户或多个应用程序而将所述VHLG按比例缩放；基于所述VHLG而确定谱系，其中：

所述谱系包括通过版本链来相关的文档集合；

所述文档集合包括所述第一文档版本及所述第二文档版本；且

所述版本链包括所述文档边缘。

5.根据权利要求4所述的计算机实现的方法，其还包括：

用上下文数据对所述第一文档版本节点及所述第二文档版本节点进行扩增；

基于所述谱系及上下文数据而确定协作的社区。

6.根据权利要求5所述的计算机实现的方法，其还包括：

基于所述上下文数据而确定所述社区的行业类型。

7.根据权利要求5所述的计算机实现的方法，其还包括：

基于所述VHLG而确定随时间的访问模式。

8.根据权利要求1所述的计算机实现的方法，其中：

所述文档的数据独立于所述VHLG而存储；

无论用于访问所述第一文档版本的装置平台如何，所述第一前散列都保持不变；且

无论用于访问所述第二文档版本的装置平台如何，所述第二后散列都保持不变。

9.根据权利要求1所述的计算机实现的方法，其还包括：

将包括所述VHLG的可视化的图形用户界面(GUI)提供给协作用户，其中所述可视化显示所述第一文档版本与所述第二文档版本之间的访问模式及依赖性。

10.根据权利要求1所述的计算机实现的方法，其还包括：

所述用户或所述应用程序访问所述第一文档版本或所述第二文档版本；

基于所述VHLG而确定所述第一文档版本或所述第二文档版本是否是所述文档的最新版本，其中所述确定包括查询所述VHLG；及

将所述确定的结果告知所述用户或所述应用程序。

11.一种用于跟踪文档版本控制的计算机实现的系统，其包括：

(a)具有存储器的计算机；

(b)在所述计算机上执行的处理器；

(c)存储指令集的所述存储器，其中所述指令集在由所述处理器执行时致使所述处理器执行包括以下各项的操作：

(i)在对第一文档版本执行打开操作之前，生成所述第一文档版本的第一前散列；

(ii)用户或应用程序执行所述打开操作；

(iii)在执行所述打开操作之后，生成所述第一文档版本的第一后散列；

(iv)在对所述第一文档版本执行保存操作之前，获取所述第一文档版本的所述第一前散列；

(v)所述用户或所述应用程序对所述第一文档版本执行保存操作，从而产生第二文档版本；

(vi)在执行所述保存操作之后，生成所述第二文档版本的第二后散列；

(vii)生成版本散列链接图形(VHLG)，其中所述VHLG包括：

(A)第一文档版本节点，其包括所述第一前散列；

(B)第二文档版本节点，其包括所述第二后散列；

(C)用户-应用程序节点，其对应于执行所述打开操作及所述保存操作的所述用户或应用程序；

(D)打开操作边缘，其将所述用户-应用程序节点连接到所述第一文档版本节点，其中所述打开操作边缘标识所述打开操作；

(E)保存操作边缘，其将所述用户-应用程序节点连接到所述第二文档版本节点，其中所述保存操作边缘标识所述保存操作；及

(F)文档边缘，其将所述第一文档版本节点连接到所述第二文档版本节点；以及

(viii)基于所述VHLG而提供文档的完整历史记录。

12.根据权利要求11所述的计算机实现的系统，其中生成所述VHLG的所述操作包括：

将所述打开操作的信息及所述保存操作的信息发送到VHLG生成服务，其中：

所述打开操作的所述信息包括所述第一前散列、所述第一后散列及所述打开操作的标识；且

所述保存操作的所述信息包括所述第一前散列、所述第二后散列及所述保存操作的标识；及

所述VHLG生成服务基于所述信息而生成所述VHLG。

13.根据权利要求12所述的计算机实现的系统，其中：

所述打开操作的所述信息包括第一日志项；

所述第一日志项包括：

对应于所述用户或所述应用程序的匿名用户标识；

所述用户或所述应用程序所使用的平台；

所述打开操作的所述标识；

所述第一前散列；

所述第一后散列；及

执行所述打开操作的时间；

所述保存操作的所述信息包括第二日志项；

所述第二日志项包括：

对应于所述用户或所述应用程序的所述匿名用户标识；

所述用户或所述应用程序所使用的所述平台；

所述保存操作的所述标识；

所述第一前散列；

所述第二后散列；及

执行所述保存操作的时间。

14.根据权利要求11所述的计算机实现的系统，其中所述操作还包括：

跨时间及多个用户或多个应用程序而将所述VHLG按比例缩放；

基于所述VHLG而确定谱系，其中：

所述谱系包括通过版本链来相关的文档集合；

所述文档集合包括所述第一文档版本及所述第二文档版本；且

所述版本链包括所述文档边缘。

15.根据权利要求14所述的计算机实现的系统，其中所述操作还包括：

用上下文数据对所述第一文档版本节点及所述第二文档版本节点进行扩增；

基于所述谱系及上下文数据而确定协作的社区。

16.根据权利要求15所述的计算机实现的系统，其中所述操作还包括：

基于所述上下文数据而确定所述社区的行业类型。

17.根据权利要求15所述的计算机实现的系统，其中所述操作还包括：

基于所述VHLG而确定随时间的访问模式。

18.根据权利要求11所述的计算机实现的系统，其中：

所述文档的数据独立于所述VHLG而存储；

无论用于访问所述第一文档版本的装置平台如何，所述第一前散列都保持不变；且

无论用于访问所述第二文档版本的装置平台如何，所述第二后散列都保持不变。

19.根据权利要求11所述的计算机实现的系统，其中所述操作还包括：

将包括所述VHLG的可视化的图形用户界面(GUI)提供给协作用户，其中所述可视化显示所述第一文档版本与所述第二文档版本之间的访问模式及依赖性。

20.根据权利要求11所述的计算机实现的系统，其中所述操作还包括：

所述用户或所述应用程序访问所述第一文档版本或所述第二文档版本；

基于所述VHLG而确定所述第一文档版本或所述第二文档版本是否是所述文档的最新版本，其中所述确定包括查询所述VHLG；及

将所述确定的结果告知所述用户或所述应用程序。

Images