CN101093497B

CN101093497B - 文档管理服务器、文档管理方法及管理文档使用的***

Info

Publication number: CN101093497B
Application number: CN2007100023997A
Authority: CN
Inventors: 川边惠久; 国武节; 寺尾太郎
Original assignee: Fuji Xerox Co Ltd
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2006-06-22
Filing date: 2007-01-15
Publication date: 2011-07-27
Anticipated expiration: 2027-01-15
Also published as: CN101093497A; US20070299880A1; JP4816281B2; JP2008003847A

Abstract

本申请提供了一种文档管理服务器，包括：接收单元，从客户机接收请求和表示文档的第一ID；ID处理单元，当对所述文档执行一项操作时，发出第二ID，并记录将所述第二ID作为所述第一ID之子节点的派生关系；基本节点设定单元，设定基本节点，以表示用户在所述派生关系的节点组中的部门；文档关联单元，将通过与基本节点的后代节点相对应的操作记录的所述文档的相关数据与所述基本节点相关联；文档提供单元，当其收到用户对数字文档的请求时，通过从所述请求伴随的ID到根节点跟踪所述派生关系来检测一个基本节点，并根据与所检测到的基本节点相关联的相关数据提供所请求的文档。

Description

文档管理服务器、文档管理方法及管理文档使用的***

发明领域

本发明涉及用于管理数字文档使用的***。

技术背景

迄今为止，诸如文档数据和音频数据、图像数据、多媒体数据以及程序之类的数字文档(后面简称为文档)是记录在文档管理服务器中的，并且，响应于用户请求而提供这些文档。在这种用于管理数字文档使用的***中，由服务器的文档管理功能提供增值，例如文档属性管理、访问管理、版本管理、附加信息(例如文档附件)管理等。然而，增值信息的这些类型是由服务器控制的，所以，文档在从服务器中提取出来后并且在分配过程中通常未附带有这样的增值信息。过去，在开放环境中以这种方式进行分配的文档和服务器上的文档属性以及其他增值信息之间的映射通常是手动进行的，例如通过文档名。

日本专利公开案No.2005-038371披露了一种信息处理***，其是与文档访问管理相关的传统技术。该***根据组织的安全政策描述来执行动态的版本管理和访问控制。该***基于要成为操作对象的信息的安全属性和请求该操作的用户的安全属性，指定是否准许或禁止该操作，并且指定通过处理一种预定情况来准许该操作。

此外，美国专利No.5,828,375披露了一种信息处理***，其通过绑定正在工作的文件组来创建部分单元集ad hoc，并将其保存成快照。然后，该快照随后由多个用户读取和共享。

此外，在另一相关技术的公知***或装置中，打印机打印出数字文档，打印结果上列出的标识信息或坐标信息与该数字文档相关联，并且存储在文档管理数据库中。使用诸如电子笔之类的坐标输入装置或电子信息输入接口，在打印出的文档上执行写入，并且，基于标识信息或坐标信息所获得的数字文档的更新信息与数字文档相关联，并在操作历史管理数据库或操作历史管理文档文件夹中进行保存和更新。

在日本专利公开案No.2005-135211中披露了这类***的一个示例。

在一个这种类型的传统***中，在数字文档中直接反映纸件文档上的手动编辑，并且，将数字文档的一系列更新版本保存成树结构，其中，将数字文档作为节点。

日本专利公开案No.2005-135211披露了文档历史树的一个示例，其能够管理根据文档和文件的更新所产生的版本，其中，文档和文件作为节点。通常，该版本管理***被广泛认为是CVS(并存版本***)。

日本专利公开案No.2005-135211披露了一种用于管理与作为文档历史树的数字文档更新相关的历史的方法，其中，更新之前的数字文档为父，而更新之后的数字文档为子。

在诸如企业之类的组织内的文档管理过程中，例如，当该组织的领导在组织内提出战略信息时，该领导把该战略信息的文档集合(即具有多于一个文档的集合)的副本传递给各部门的经理，各部门对该文档集合中属于自己的那部分进行编辑或者添加补充文档，并在附属部门内进一步制订该文档集合。该工作在组织层级中从高到底重复进行。除了特殊情况外，采用该文档分配方法，部门成员只需要观看和编辑属于该部门的那部分，而不必观看属于其他部门的部分。在有些情况下，能够观看这些部分可能会成为障碍。因而，需要进行文档管理，以防止访问属于其他部门的部分。

当在传统文档管理服务器的范围(其中，文档集合在多个部门之间从高到低传递)内试图执行这种类型的文档管理时，文档集合在每一较低部门中进行复制，各较低部门进行编辑并向其副本中添加信息。当对各文档进行版本管理时，如果将文档集合传给较低部门，则创建版本分支，并且，该较低部门对该分支进行版本改变。为了防止各部门的成员访问属于其他部门的部分，需要根据分配给各部门的版本分支和文档集合的复制，对各部门的成员设置访问权限。当组织的层数增加时，分级地创建复制和版本分支，所以，对它们设置适当访问权限的任务将变得复杂且麻烦。

此外，就独立于服务器的开放环境中的文档而言，还没有通过部门来执行这种类型的访问管理的已知***。

日本专利公开案No.2005-038371披露了一种动态地改变访问权限的***。但是，其没有考虑分级组织内的文档分配，因此，用策略描述来正确表达如上文所述的分级部门的访问权限未必是一件容易的事情。

美国专利No.5,838,375披露了一种可以在各时间点在多个用户之间共享文档组的***，但是，与日本专利公开案No.2005-038371一样，它也未考虑分级组织内的文档分配。因此，由组织中的部门创建适当快照的任务必须由用户手动执行。

此外，对于纸件文档的复制，日本专利公开案No.2005-135211并未针对通过复制装置的命令或输入来添加或改变文档历史树中的节点的特定装置做出任何描述。同样，当丢弃纸件文档时，未针对通过复制装置的命令或输入来添加或改变文档历史树中的节点的特定装置做出描述。此外，未对组织中的文档分配进行描述。

发明内容

根据本发明的一个方面，提供了用于管理要提供给客户机的数字文档的文档管理服务器，包括：接收单元，其从客户机接收请求和第一ID，其中，所述第一ID表示所述请求之对象的数字文档；ID处理单元，当响应于所述请求而对所述数字文档进行操作时，其发出与所述操作相关联的第二ID，并记录将所述第二ID作为所述第一ID之子节点的派生关系；基本节点设定单元，其设定基本节点，以表示用户在所述派生关系的节点组中的部门；文档关联单元，其将通过与基本节点的后代节点相对应的操作记录的所述数字文档的相关数据与所述基本节点相关联；文档提供单元，当其收到用户对数字文档的请求时，通过从所述请求伴随的ID到根节点跟踪所述派生关系来检测所述基本节点，并根据与所述检测到的基本节点相关联的相关数据提供所请求的文档。

附图说明

根据以下附图将对本发明的实施例进行详细描述，其中：

图1的框图示出了使用副本快捷方式来管理文档使用的***的简化结构；

图2示出了客户机终端的内部结构的示例；

图3示出了文档管理服务器的内部结构的示例；

图4示出了由日志管理单元生成的日志数据的一个示例；

图5示出了图4的日志数据中所示的副本ID构成的派生关系树；

图6示出了当生成图4的日志数据时的***操作；

图7示出了用于在组织内管理文档分配的***的总体结构；

图8示出了在组织信息管理数据库中记录的用户信息的一个示例；

图9示出了图7的***中的文档管理服务器的内部结构；

图10的流程图示出了当采用总体管理方法接收文档记录请求时的文档记录单元的过程；

图11的流程图示出了当采用总体管理方法接收读取请求时的副本提供单元的过程；

图12的流程图示出了当采用总体管理方法接收更新请求时的文档记录单元的过程；

图13示出了在组织内进行文档分配的特定示例中某特定时间点时的派生关系树；

图14示出了与图13的派生关系树相对应的日志数据的内容；

图15示出了在图13的状态之后当属于办事机构A的用户更新文档时的派生关系树；

图16示出了在更新之后且在图15的状态之后相同用户读取该文档时的日志数据的内容；

图17示出了当属于办事机构B的另一用户更新和读取文档时的派生关系树；

图18示出了当属于办事机构A的另一用户更新和读取文档时的派生关系树；

图19对应于图18的派生关系树；

图20示出了当属于办事机构A的用户读取文档时的派生关系树；

图21示出了采用差分管理方法的派生关系树的一个示例；

图22的流程图示出了当采用差分管理方法接收文档记录请求时的文档记录单元的过程；

图23的流程图示出了当采用差分管理方法接收读取请求时的副本提供单元的过程；

图24的流程图示出了当采用差分管理方法接收更新请求时的文档记录单元的过程；

图25示出了采用通过添加文档附件来更新文档集合的方法的派生关系树；

图26是采用通过添加文档附件来更新文档集合的方法的日志数据的示例；

图27的流程图示出了当采用通过添加文档附件来更新文档集合的方法接收原始文档记录请求时的文档记录单元的过程；

图28的流程图示出了当采用通过添加文档附件来更新文档集合的方法接收读取请求时的副本提供单元的过程；

图29的流程图示出了采用通过添加文档附件来更新文档集合的方法接收文档附件记录请求时的副本提供单元的过程；

图30的流程图示出了当采用基于读取请求收集基本节点的后代节点的更新信息的方法接收更新请求时的文档记录单元的过程；

图31的流程图示出了当采用基于读取请求收集基本节点的后代节点的更新信息的方法接收读取请求时的复制单元的过程；以及

图32是配有本实施例之装置的计算机的硬件结构的示例。

具体实施方式

使用副本快捷方式来管理文档使用的***的概述

首先，将描述使用副本快捷方式来管理文档使用的***。

图1的框图示出了用于管理文档使用的***的总体结构。该***包括文档管理服务器10和客户机终端20-1、20-2(下面统称为客户机终端20)等，它们经由诸如因特网或局域网之类的网络30相连。

在该***中，数字文档的原始文件由文档管理服务器10来管理，因此，该数字文档的安全性不是通过将该数字文档的文件存储在客户机终端20中来得以保证的。在客户机终端20中保存的是名为副本快捷方式(下面称为副本SC)的文件，而非数字文档文件自身，其中，副本SC包括用于访问数字文档的信息。副本SC可以包括：用于进行管理的标识信息，其名为副本ID；访问信息，如文档管理服务器10的主机名或文档读取请求对应的URL(统一资源***)；副本SC的属性。在副本SC中包括的信息的一个示例为：“id＝1234567，host＝foo.fujixerox.co.jp，createDate＝2005/05/24 11:12:34”。

在该示例中，“id＝1234567”表示副本ID，“host＝foo.fujixerox.co.jp”表示文档管理服务器10的主机名，以及，“createDate＝2005/05/24 11:12:34”表示创建日期和时间，其是副本SC的一个属性。为了防止数据泄漏，副本快捷方式不包括实际的数字文档。但是，为了使用户可以标识副本ID对应的数字文档，数字文档的一部分(如仅第一页的信息)或数字文档的各页的缩略图可以作为数字文档的低质量采样而包括在副本SC中。

当使用副本SC的客户机终端20访问用于管理与副本SC相对应的原本的文档管理服务器10时，使用副本SC中包括的访问信息。但是，如果在网络上提供服务器(并且该服务器地址包括在副本SC中并为阅览器22所知晓)，以便为用于管理副本ID所对应的原本的文档管理服务器10解析访问信息，则文档管理服务器10的访问信息不必包括在副本SC中。

如图2所示，其他应用程序文件和副本SC 26的文件一起存储在客户机终端20的文件***24中。将副本SC 26创建成一个文件，其采用的格式可以将属性信息同文档的实体数据一起保存，例如由Adobe Systems公司开发的PDF(便携式文档格式)或由Fuji Xerox有限公司开发的DocuWorks(注册商标)。在这种情况下，副本ID和访问信息作为属性信息包括在副本SC 26的文件中。当用户想要对文档管理服务器10中的数字文档进行读取或执行另一操作时，该用户从文件***24或搜索软件提供的文件列表画面中选择对应于数字文档的副本SC 26(与普通快捷方式文件相类似)，并执行该操作。然后，已经与副本SC 26的文件格式相关联的阅览器22启动，阅览器22使用副本SC 26内的访问信息和副本ID访问文档管理服务器10，并获取副本文档文件，即与副本ID相对应的数字文档的副本。阅览器22显示该副本文件，于是，可以根据用户操作对该副本文件执行编辑操作。副本文件包括表示该文件是副本的信息(例如，后面将对进行描述的更新副本ID)，阅览器22根据该信息认识到该文件是副本。阅览器22并不将副本文件存储在文件***243中。仅在由客户机终端20的阅览器22管理的存储空间中打开该副本文件，并不将其存储在文件***24中。可以将与PDF格式相兼容的Adobe Systems公司的Acrobat(注册商标)用作阅览器22。可以将在该***固有的副本SC中处理的功能(已经对部分功能做了描述，后面还将对其进一步进行描述)以插件(Plug-ins)的格式添加到现有阅览器中，例如Acrobat。

在该***中，每当用户使用客户机终端20上的副本SC对文档管理服务器10上的原始数字文档执行一项操作时，文档管理服务器10发出用于更新的副本ID并使用新的副本ID更新客户机终端20上的副本SC内的副本ID。因此，每当在该***中使用副本SC对数字文档执行操作时，副本SC内的副本ID得到更新。例如，如果用户X使用副本SC从文档管理服务器10请求数字文档的副本文件并获取和读取该副本文件，则位于用户X的客户机终端20中的副本SC内的副本ID的值在读取操作前后发生改变。因此，如果考虑用户X将副本SC的副本添加到电子邮件中并将该邮件发送给另一用户Y的情况，则该用户Y收到的副本SC中的副本ID将根据其发送是在读取操作之前还是之后而改变。如果用户使用副本SC请求对数字文档进行操作，则副本SC中包括的副本ID从客户机终端20发送到文档管理服务器10，因此，文档管理服务器10可以根据所收到的副本ID认出，作为请求基础的副本SC对应于某特定操作的一个步骤(例如用户X读取之前或之后)。此外，如果副本ID与原始数字文档的标识信息(称为文档ID)和执行导致发出副本ID的操作的用户的用户ID(即发出副本ID的用户ID)相关联，并存储在文档管理服务器10中，则可以根据该副本ID确定用户操作和要进行该操作的文档，从而，可以详细地跟踪数字文档的分配情况。

副本ID表示***内的唯一标识信息，并与用户对数字文档执行的各操作相对应。副本ID可以是序列号，其随着每次操作而增加。但是，从阻止基于第三方猜测的攻击的角度来看，可以使用通过采用确保高度唯一性并难以猜测的生成规则而生成的值，例如足够长的随机数。此外，随各副本ID的发出而改变的属性信息(如，副本ID的生成日期和时间)的hash值(具有足够多的位数)或者固定属性信息(如，与副本ID相对应的原本的标识信息)与变化属性信息的组合的hash值也可以用于副本ID。

如图3所示，文档管理服务器10包括原始文档数据库11、原始文档记录单元13、副本SC提供单元15、副本文档提供单元17以及日志管理单元19。

原始文档数据库11将数字文档作为已经从客户机终端20上载的原本进行存储和管理。在该***的框架内，只将存储在原始文件数据库11中的数字文档处理成原本。在该框架内，即使数字文档的副本存在于网络上，也可以将其处理成与原本无关。具体而言，如果客户机终端20的阅览器22未将副本文档文件如上所述存储在文件***中，则原本的副本在网络上传播的可能性会大大降低。

原始文档记录单元13将已经从客户机终端20上载并将要记录成原本的数字文档记录到原始文档数据库11中。此时，原始文档记录单元13将名为“文档ID”的唯一标识信息分配给要记录的原始数字文档文件。文档ID可以是随机数或hash值。

响应于用户的操作请求，副本SC提供单元15将原始文档数据库11内的数字文档对应的副本SC发给该用户。响应于该用户的操作请求，副本文档提供单元17创建所请求的数字文档的副本文件并将其提供给该用户。

如果文档管理服务器10响应于用户操作请求经由客户机终端20执行处理，则日志管理单元19将与该操作相关的信息记录成事件日志。如图4所示，日志管理单元19将各操作事件记录成日志记录，例如，作为操作对象的原始数字文档的文档ID、在操作事件中提供有副本ID的用户(在该情况下，与针对该操作访问文档管理服务器10的用户相同)的用户ID(目的用户ID)、事件类型、事件发生的日期和时间、将要提供给事件中的目的方用户的副本ID以及在导致该事件的请求中包括的副本ID(称为旧副本ID)。根据该日志记录，副本ID和相应的原始文件ID相关联。此外，通过根据副本ID检查日志记录，由文档管理服务器10提供的新副本ID可以与使用文档操作的旧副本ID的访问相关联，从而可以确定由于该操作引起的文档ID的改变。可以将副本ID的这种改变表示成一种关系，其中，新副本ID是由于一项操作而从旧副本ID中派生出来的。由于副本ID的唯一性而不能从多个不同旧副本ID派生出相同的副本ID，所以派生关系是树形。在图5中示出了图4所示的日志数据中的副本ID的派生关系。

可以使用web服务器和web应用程序来组织文档管理服务器10。在这种情况下，文档管理服务器10将作为用户界面屏幕的网页提供给客户机终端20。

接下来，为了阐明用于管理文档使用的***的机制，将参考图6描述当形成图4所示的日志数据时***的操作。

首先，用户P01将数字文档“O”100的记录请求从客户机终端20-P01发到文档管理服务器10。数字文档100可以处于客户机终端20-P01的本地文件***内或处于网络上的文件服务器或文档服务器中。该记录请求可以经由阅览器22提供的用户界面来执行。用户界面提供目录屏幕，用以表示网络文件***或文件***的树形目录，并且，在该目录屏幕上从用户P01接收对要记录的文件的选择。此外，用户界面可以提供搜索屏幕，用户通过该搜索屏幕输入搜索条件。从本地文件***或网络文件服务器中搜索与这些条件相匹配的数字文档，并将搜索结果提供给用户，用户可从其中选择要记录的文档。由客户机终端20发出的记录请求包括标识用户P01的用户ID和要成为对象的数字文档100(文档100的实体数据或该实体数据的链接信息)。对于记录请求中包括的用户ID，可以使用当登录该***或客户机终端20-P01时用户P01提供的用户ID。

在接收到记录请求的文档管理服务器10中，原始文档记录单元13获取该请求中包括的数字文档100的实体数据(或使用链接获取实体数据，如果该实体数据的链接包括在请求中的话)，然后将唯一文档ID“D01”添加到数字文档中。然后，将数字文档100的实体数据与文档ID“D01”相关联并记录到原始文档数据库11中。如果从客户机终端20发送过来的原始文档100不是采用***的文档格式(例如PDF)，则在将数字文档100转换成***的文档格式之后文档管理服务器10可以将其记录到原始文档数据库11中。

接下来，副本SC提供单元15生成唯一副本ID“a”，生成包括副本ID“a”和文档管理服务器10的主机名的副本SC 102，然后，响应于例如记录请求而将该副本SC 102发送到客户机终端20-P01。此外，在文档管理服务器10中，日志管理单元19将图4所示的表的第二行记录成与上述记录事件相关的日志记录。在该记录中，作为操作事件之对象的原始数字文档的文档ID是“D01”，而作为在操作事件中生成的新副本ID的目的用户的用户ID是“P01”。此外，操作事件的类型是“文档记录”，而事件的日期和时间是“2006/03/03/10:00:00”。另外，作为事件结果提供给目的用户的副本ID是“a”，在这种情况下，旧副本ID未包括在该操作的请求中，故显示为NULL。

将副本SC 102连同记录成功的响应一起接收的客户机终端20-P01将副本SC 102记录到文件***24-P01中。此时，可以删除文件***24-P01内的原始数字文档100，而可以将副本SC 102的文件进行存储。如果执行了该过程，那么，将数字文档100的原始实体数据仅存储在文档管理服务器10中，因此，保证其是实际的原本就变得很容易。

如果用户向文档管理服务器10发送请求以便记录位于网络上的文件服务器中的数字文档100，则文档管理服务器10可以将副本SC102发送到该文件服务器。存储数字文档100和接收该请求的文件服务器可以删除数字文档100而存储副本SC 102。在这种情况下，用户P01可以在网络文件***等的目录屏幕上观看位于文件服务器上的副本SC 102。

在这里假定用户P01将数字文档“O”100的副本SC 102发送到用户P03，例如通过电子邮件附件的形式。然后，将副本SC 102作为数字文档“0”的快捷方式存储到用户P03的客户机终端20-P03的文件***24-P03中。为了读取数字文档“O”，用户P03打开阅览器22中的副本SC 102，并输入读取命令。阅览器22从副本SC 102获取副本ID“a”和文档管理服务器10的主机名，使用该主机名访问文档管理服务器10，并将副本ID“a”伴随的读取请求104发送出去。该读取请求104包括用户P03的用户ID。在随后步骤中，当用户将请求或其他数据发送到文档管理服务器10时，文档管理服务器10还可以确定哪一个用户正在访问，因为该用户的ID包括在该请求中或在发送之前该用户已经登录到文档管理服务器10中。

在接收到读取请求104的文档管理服务器10中，副本文档提供单元17启动。例如，副本文档提供单元17从日志管理单元19中获取将读取请求104伴随的文档ID“a”作为“提供的副本ID”的记录，从原始文档数据库11中获取由该记录中的文档ID“D01”表示的数字文档“O”的实体数据，并创建文档副本。然后，副本文档提供单元17创建用于更新的副本ID“b”，并将其设在副本文件的副本ID属性中，从而创建副本文件106。副本文件106包括原始文件的主体和副本ID“b”。作为对读取请求104的响应，将副本文件106返回到客户机终端20-P03。

此外，日志管理单元19创建并记录日志记录，例如图4所示表的第三行。读取请求104包括副本ID“a”，所提供的副本文件106相应地包括副本ID“b”，因此，在该日志记录中，“旧副本ID”是“a”，而“提供的副本ID”是“b”。另外，在日志记录中，将“D01”记录成对象文档ID，将“P03”记录成目的用户ID，以及，将“副本提供”记录成事件信息。

客户机终端20-P03的阅览器22打开并显示所接收的副本文件106中的文档实体数据。因为副本文件106附带有表示“保存禁用”的属性，所以，阅览器22未将副本文件106保存到文件***24-P03中。例如，在阅览器22上提供用户界面屏幕，其中，保存副本文件106的选择是不可用的。此外，阅览器22将在文件***24-P03中存储的副本SC 102中的副本ID“a”改写成副本文件106中包括的经过更新的副本ID“b”，因此，数字文档“O”的快捷方式得到更新。因此，将文件***24-P03中的副本SC 102重写到包括有副本ID“b”的副本SC 108中。

当考虑用户P03将数字文档“O”的副本SC发送给另一用户的情况时，如果在用户P03读取副本文件106之前进行发送，那么发送包括有副本ID“a”的副本SC 102。但是，如果是在用户P03读取副本之后进行发送，那么发送包括有副本ID“b”的副本SC 108。

接下来，将考虑用户P04获取数字文档的情况，该数字文档由文档管理服务器进行管理。在这种情况下，用户P04从客户机终端20-P04向文档管理服务器10发送对目录屏幕或搜索屏幕的请求。用于选择原始文档数据库11内记录的数字文档的目录屏幕或搜索屏幕由文档管理服务器10生成，并返回到客户机终端20-P04。用户P04经由屏幕找到所期望的数字文档“O”。当用户发送命令以获取数字文档时，客户机终端20将数字文档“O”的标识信息(例如文档ID“D01”)伴随的获取请求112发送到文档管理服务器10。这在文档管理服务器10中进行接收，在文档管理服务器10中，副本SC提供单元15生成新副本ID“c”并生成包括该新副本ID“c”的副本SC 114，并将该副本SC 114返回到客户机终端20-P04。然后，日志管理单元19创建与提供快捷方式的该事件相关的记录(图4所示表的第四行)。

客户机终端20-P04将所收到的副本SC 114存储到文件***24-P04中。当用户选择副本SC 114并发出读取命令时，阅览器22发出副本ID“c”伴随的读取请求116。作为响应，文档管理服务器10创建与副本ID“c”相对应的原本的副本，创建用于更新的副本ID“d”，并将其设成副本的文件属性，创建包括该副本和副本ID“d”的副本文件118，并将其返回到客户机终端20-P04。此外，日志管理单元19记录一条记录，例如图4所示表的第五行。

客户机终端20-P04的阅览器22打开并显示副本文件118，并将文件***24-P04内的副本SC 114的副本ID改变成副本文件118中包括的用于更新的副本ID“d”。因此，对应于客户机终端20-P04保存的数字文档“0”的快捷方式变成了副本SC 120。

在用户P04读取数字文档“O”的副本之后，将副本SC 120传送到用户P08。当用户P08使用副本SC 120发送读取请求122时，文档管理服务器10将包括有用于更新的副本ID“e”的副本文件124提供给客户机终端20-P08，并记录图4的表中第六行所示的日志记录。客户机终端20-P08的阅览器22打开所收到的副本文件124并将其提供给用户，并将文件***24-P08内的副本SC的副本ID变成副本ID“e”。

图4所示的日志数据中记录了操作事件中副本ID对应的目的用户ID。但是，也记录了发送导致该事件的请求的用户ID。在上述示例中，发送导致该事件的请求的用户和在事件中新生成的副本ID的目的地是相同的。但是，如果它们不同的话，则优选记录两用户ID，如上所述。

上面详细描述了作为该实施例基础的用于管理文档使用的***的结构和处理。该***的特征概括如下：

在文档管理服务器中记录数字文档的原本。

向用户提供副本SC，而非数字文档的实体数据。副本SC包括副本ID。当使用副本SC对文档管理服务器10执行与原本相关的操作时，需要识别管理原本的文档管理服务器10。因此，副本SC可以包括用于管理相应原本的文档服务器10的识别信息。

文档管理服务器管理所提供的副本SC的副本ID和相应原本之间的对应关系(在上述示例中，副本ID和原本之间的对应关系是以包括在日志管理单元19的日志记录中的形式进行管理的。只要两者之间的对应关系清楚，则对应关系数据可以采用任何形式)。

当对文档管理服务器执行与文档相关的操作时，将执行该操作的终端保存的副本SC的副本ID发送到服务器。

文档管理服务器根据副本ID和原本之间的对应关系，识别与从终端接收的副本ID相对应的原本，并执行与原本相关的请求操作。

当执行与原本相关的操作时，文档管理服务器创建新副本ID，并将该副本ID发送到请求该操作的客户机终端。接收该副本ID的客户机终端将请求中使用的副本SC的副本ID更新成所收到的新副本ID。

文档管理服务器管理副本ID派生关系，后者是来自客户机终端的请求中包括的副本ID和通过执行与请求相关的操作而生成的新副本ID之间的对应关系。

当从客户机终端发送获取数字文档实体数据的操作请求时，例如读取数字文档，则文档管理服务器向终端提供副本文档数据，即原本的副本。该副本文档数据仅存在于由阅览器管理的存储器的区域中，该阅览器运行在客户机终端上，并对该副本文档数据进行设置，从而不能将其存储在硬盘上。

在上述示例中，文档管理服务器10记录图4所示的日志记录。但是，这仅仅是一个示例。例如，除了目的用户ID之外或取代目的用户ID，还可以记录目的用户的用户名。可以从客户机终端20中获取用户名。此外，可以记录目的用户所属组织的名称。用户所属组织的名称可以是企业或部门的名称，并且是从与本***相连的组织信息管理数据库中获取的。组织信息管理数据库是一种用于管理组织、部门、职位、联系信息等的各成员名称的目录服务器。在企业***中具有这类组织信息管理数据库是很正常的，从而，可以从该数据库中获取信息。此外，对于用户名和组织名而言，可以使用ITU-T建议X.509证明标准的区别名(DN)。可以从LDAP(轻量级目录访问协议)服务器中获取DN。此外，可以将由目的用户使用的客户机终端20的IP(互联网协议)地址或MAC(媒体访问控制)地址记录到日志记录中。在访问过程中，可以从客户机终端20中获取IP地址或MAC地址。

此外，在用于管理文档使用的***中的上述示例中示出了如文档记录、副本SC的获取以及文档读取之类的操作。但是，除了这些操作之外，与原始文档相关的所有***操作均适用于上述特征的处理。

在上文和下文所示的***中，根据读取请求或其他请求从客户机终端20发送到文档管理服务器10的用户ID或其他信息可以设在HTTP请求首部中并进行传送，例如，或者可以包括在用XML书写的HTTP请求中并进行传送。当将文档从客户机终端20传送到文档管理服务器10时，所传送的信息可以是该文档的元数据的一部分。

下面将使用副本SC描述用于管理分级组织内的文档分配的***。在以上所述的***中，仅仅读取文档。但是，在下面***中，也考虑了向文档和/或附加数据中添加更新的情况，例如将文档附件添加到文档中。

在该***中，用户可以将基本节点设在数字文档的派生关系树的一个节点(副本ID)中，并将在部门内共享的数字文档或要相关数据与该基本节点相关联并存储到其中。然后，部门成员读取已经与基本节点相关联并存储到其中的数字文档以及相关数据。由部门成员执行的向数字文档添加任何更新或数据与基本节点相关联并进行存储。这样，属于该部门的各成员可以访问在他们部门中共享的数字文档和对数字文档更新或添加的数据。

图7示出了用于实现该类控制的***的总体结构。与图1所示的***相比，图7的***添加了组织信息管理数据库40。组织信息管理数据库40将关于上述组织的各成员的信息和关于组织中的部门分级的信息进行存储。例如，如图8所示，对于每个成员而言，在组织信息管理数据库40中记录的信息包括唯一用户ID、用户名以及部门名。文档管理服务器10a和客户机终端20必要时从组织信息管理数据库40中获取关于各用户的信息。

图9示出了图7的***中的文档管理服务器10a的内部结构。在图9的文档管理服务器10a中，文档数据库不仅存储作为派生关系树之根节点(参考图4)的数字文档(原本)，而且还存储用于原本的更新和添加的数据。文档记录单元13a响应于数据的记录请求，执行将用于更新和添加原本的数据记录到文档数据库11a中这一处理。此外，当接收到读取请求时，副本文档提供单元17a的处理不同于图3的示例中的副本提供单元17的处理。其他部件可以与图3中所示的部件相同。

通常可以将添加到文档的改变分为改变文档主体内容的“更新”和将文档附件或其他数据添加到文档主体的“添加”。首先将对“更新”情况的示例进行描述。

用于管理文档主体的更新的方法包括：将每次更新之后的文档的全部数据进行保存(后面称之为“总体管理方法”)和仅将更新之后的差异进行保存(后面称之为“差分管理方法”)。在差分管理方法中，对原始文档执行更新的次序差异进行更新，从而生成最新文档。下面将把总体管理方法作为典型示例进行描述。

在总体管理方法中，当从用户接收到用于记录原始文档的文档记录请求时，文档记录单元13a执行图10所示的过程。

文档记录单元13a将唯一文档ID分配给伴随着文档记录请求从用户接收到的文档，将表示该文档是原本的预定版本号进行分配，并将该文档与文档ID和版本号相关联，然后将该文档记录到文档数据库11a中(S1)。此外，文档记录单元13a获取请求方用户的部门属性(S2)。用户的部门属性可以伴随着文档记录请求由用户发送到文档管理服务器10a，或者可以由文档管理服务器10a通过使用伴随着文档记录请求所收到的用户信息从组织信息管理数据库40中获取。此外，文档记录单元13a生成唯一副本ID以及生成包括该副本ID的副本SC，并将该副本SC发送到请求方用户(S3)。然后，创建日志记录，并记录派生关系信息(S4)。除了图4所示的这些项之外，也将导致事件的发出请求用户的部门属性的值(即表示目的地ID的用户)和文档数据库11a中存储的文档的版本号记录到所创建的日志记录中。图14示出了用该方式创建的日志记录组的一个示例。应当注意的是，图10中的步骤的执行顺序仅仅是一个示例。可以按任何顺序执行这些相互独立的步骤。

接下来，参考图11，将描述当采用总体管理方法从用户接收文档读取请求时副本提供单元17a的过程。

通过使用上述副本SC执行读取请求。将包括副本SC的副本ID伴随着读取请求从客户机终端20发送到文档管理服务器10a。接收副本ID的副本提供单元17a从副本ID到根节点跟踪派生关系树，一次一个节点(日志记录)，检查该节点是否设有版本属性值(版本号)，并重复跟踪，直到找到设有版本属性值的节点为止(S11)。该***把要在部门中进行共享的版本号的值记录到组织的分级结构中该部门的基本节点中。除了基本节点外，未将版本的值记录在其他节点。因此，在步骤S11中，为了识别将要提供给发出读取请求的用户的版本，搜索基本节点。然后，从文档数据库11a中获取与搜索到的节点中的版本属性值相对应(版本号)的文档(步骤S12)。这里，如果由文档管理服务器10a分配的版本号仅在从相同文档派生出的版本组中是唯一的，则在步骤12中搜索文档数据库11a，以查找与版本号和原本的文档ID的组合相对应的文档数据。然后，副本提供单元17a生成新副本ID以及生成包括该副本ID和在步骤S12中获取的文档的副本文件，并将该副本文件提供给发出读取请求的用户(S13)。接下来，生成包括关于所提供副本ID的信息的日志记录，并将其记录到日志管理单元19中(S14)。未将部门属性和版本属性的值记录到这里所生成的日志记录中。

此外，副本提供单元17a如在步骤S1中一样获取(S15)发出读取请求的用户的部门属性值，并判断在步骤S11中找到的部门属性值是否与在步骤S15中获取的用户的部门属性值相匹配(S16)。如果它们匹配，那么这意味着在步骤S11中找到的节点是用户所属部门的基本节点。在这种情况下，不再执行其他处理，于是，该处理结束。

另一方面，如果在步骤S16中判断出节点的部门属性值与用户的部门属性值不匹配，那么这意味着该节点是比用户所属部门高一级的部门的基本节点。在这种情况下，响应于读取请求所生成的节点(即日志记录)是用户所属部门中的第一节点。因此，副本提供单元17a将用户的部门属性值和在步骤S12中获取的版本属性值记录到该节点(日志记录)中(S17)。因此，将该节点设为该部门的基本节点。然后，副本提供单元17a终止该处理。

接下来，将参考图12描述当采用总体管理方法从用户接收文档更新请求时文档记录单元13a的过程。

用户可以通过在阅览器22上打开根据读取请求获取的副本文件来编辑文档的内容。当具有接受文档更新命令的用户界面的阅览器22从该用户接收文档更新命令时，将伴有经过编辑的文档(称之为更新文档)的更新请求发送到文档管理服务器10a。接收该更新请求的文档管理服务器10a将新版本号分配给该更新文档，并将该更新文档记录到文档数据库11a中(S21)。此外，文档记录单元13a用与上述步骤S2相同的方式获取请求方用户的部门属性(S22)，生成唯一副本ID，并将包括副本ID的副本SC发送到请求方用户(S23)。然后，创建日志记录并记录派生关系信息(S24)。如上所述，将导致事件的请求方用户的属性信息值和文档数据库11a中存储的文档的版本号记录到该文档记录请求对应的日志记录中。但是，在该更新请求对应的日志记录中，未记录部门属性值和版本号。相反，文档记录单元13a从更新请求伴随的副本ID开始跟踪派生关系树，搜索与该用户具有相同部门属性值的节点，即用户所属部门的基本节点(S25)，并将基本节点的版本属性值变为在步骤S21中分配给更新文档的版本号(S26)。

下面将使用特定的示例描述该***中的处理流程。如图13所示，所示的组织结构在“主办事机构”下包括名为“办事机构A”和“办事机构B”的两个部门。然后，考虑如下情况，即，将在主办事机构中创建的文档传送到办事机构A和办事机构B并且分别在办事机构A和办事机构B中进行更新。图13示出了派生关系树200a和示出了组织结构的组织图的对应关系。为了便于描述，图13中的派生关系树200a的各节点202、204、206采用“副本ID：事件名/部门名”的标记方法，通过对应于该节点的事件中发出的副本ID的相应值、事件名以及用于副本ID的目的用户的部门属性信息来表示。此外，为了阐明该示例中的分级关系，副本ID的值是从父节点派生出的子节点中的唯一值所添加于的父节点的副本ID。

图13的示例示出了由属于主办事机构的用户1创建并记录到文档管理服务器10a中的原始文档。文档管理服务器10a将版本号“V1”203分配给原本，并将新创建的包括有副本ID“ID1”的副本SC返回给用户1。将与上述事件相关的信息表示为节点202。对应于节点202的日志管理单元19内的日志记录是在图14所示表的上数第二行中的“文档记录”事件的记录。

假定用户1例如经由电子邮件或另一传输介质已经分别向属于办事机构A的用户2和属于办事机构B的用户3提供了副本SC“ID1”。例如，当用户2使用副本SC“ID1”向文档管理服务器10a发送读取请求时，文档管理服务器10a的副本提供单元17a执行图11所示的处理，从而找到副本ID“ID1”包括在“提供的副本ID”中的那个记录(节点)并从该节点开始跟踪派生关系树。在这种情况下，该节点本身就是派生关系树中的根节点且包括版本属性值(V1)，因此，在步骤S11中找到该节点。副本提供单元17a从文档数据库11a中读取与节点中包括的版本V1相对应的文档，并向用户2提供包括文档数据和新生成的副本ID“ID11”的副本文件。因为用户2的部门是“办事机构A”并且在步骤S11中找到的节点的部门属性是“主办事机构”，所以，对应于该读取请求的节点是“办事机构A”的基本节点，其是“主办事机构”的附属部门。将在读取操作中获取的版本“V1”和部门“办事机构A”记录到该节点中(参考图14所示表的上数第三行的记录)。同样，当用户3使用副本SC“ID1”发出读取请求时，同样将包括副本ID“ID12”和文档的版本V1的副本文件提供给用户3，并且，将与副本ID“ID12”对应的节点设成办事机构B的基本节点(参考图14所示表的最后一行的记录)。图13所示的派生关系树200a示出了此时的状态。

这里，办事机构A中的用户2响应于读取请求而使用诸如阅览器或文档编辑器之类的客户机程序对所获取的副本文件内的文档数据进行编辑，并将伴有经过编辑的文档数据结果的更新请求发送到文档管理服务器10a。在该情况下，如图15所示，文档管理服务器10a将新版本号“V111”(在该示例中，版本号对应于副本ID)分配给更新请求伴随的文档数据。然后，将数据文档记录到文档数据库11a中，并且，响应于更新请求而返回包括新副本ID“ID11”的副本SC。然后，将副本ID“ID111”的节点208添加到派生关系树中，以及，将办事机构A的基本节点204的版本属性值更新成更新文档的版本“V111”。图15所示的派生关系树200b示出了此时的派生关系(对于不具有版本属性值的节点，已省略了“/”后面的部分)。

接下来，当相同用户2使用副本SC“ID111”发出读取请求时，文档管理服务器10a从“ID111”到根节点跟踪派生关系树200b，并找到作为第一节点的节点204，该第一节点已经设有版本属性值。然后，搜索文档数据库11a，以查找与文档ID“D01”的版本组中的节点204的版本属性值“V111”相对应的文档数据，并且，将包括新生成的副本ID“ID1111”及其文档数据的副本文件提供给用户2。图16示出了此时的日志管理单元19的日志数据。在接收副本文件的用户2的客户机终端20中，与文档“D01”相对应的副本SC的副本ID已经更新成“ID1111”。

然后，办事机构B中的用户3更新响应于读取请求而获取的副本文件“ID12”，并将更新结果记录到文档管理服务器10a中，并进一步读取该更新结果。在这种情况下，将派生关系树示为图17中的树200c。用户3将通过更新事件210而记录的新版本号V12记录到派生关系树中的办事机构B的基本节点206中。在下一个用户3的读取事件212时，提供版本V12的文档数据。

然后，用户2例如经由电子邮件将副本SC“ID1111”发送到相同办事机构A中的用户10，而用户10使用副本SC进行读取和更新。在这种情况下，响应于读取请求，文档管理服务器10a跟踪派生关系树200c，并将包括有与办事机构A的基本节点A 204相对应的版本V111的文档数据和新副本ID“ID11111”的副本文件提供给用户10。用户10对该副本文件进行编辑并将经过编辑的结果伴随着更新请求发送出去。然后，文档管理服务器10a将新版本号“V111111”分配给经过编辑的结果，将该结果记录到文档DB 11a中，并将办事机构A的基本节点204的版本属性值更新成版本号“V111111”。图18示出了此时的派生关系树200d，图19示出了相应的日志数据。

再接着，用户2使用副本SC“ID1111”再次读取相同的文档“D01”。在这种情况下，文档管理服务器10a从“ID1111”跟踪派生关系树200d，获取办事机构A的基本节点204的版本属性值“V11111”，并将包括新副本ID“ID11112”和该版本的文档的副本文件提供给用户2。因此，用户2读取用户10更新之后的版本。图20示出了此时的派生关系树200e。

如上所述，当从用户接收到文档记录请求时，文档管理服务器10a自动地将具有与该请求相对应的部门属性值的节点设为基本节点。此外，当从用户接收读取请求时，文档管理服务器10a通过跟踪且检查派生关系树来判断该请求是否适用于附属部门中的基本节点，并将部门属性值设到基本节点中。但是，该处理并不总是必需的。相反，例如，发出文档记录请求或读取请求的用户通过客户机终端20宣布自己是该部门的基本节点。作为响应，客户机终端20将用户的部门属性信息和表示请求事件是基本节点的信息发送到文档管理服务器10a。作为响应，文档管理服务器10a可以将部门属性值设到相关请求的节点。

此外，存在一个用户在多个部门中拥有职位的情况。例如，办事机构A的领导同时是主办事机构(管理层)的成员，附属部门的领导同时是更高部门的成员也是一个示例。在这种情况下，当用户向文档管理服务器10a发出请求时，对于该用户而言，优选指定该用户所属的部门。例如，当文档管理服务器10a根据组织信息管理服务器40而检查请求方用户的部门属性并且存在多个值时，可以向用户询问该请求是由哪个部门的成员发出的。此外，当用户发出请求时，客户机终端20从组织信息管理服务器40中获取该用户的部门属性，如果存在多个部门属性，则可以使该用户选择适当的版本属性。在该情况下，所选择的部门属性伴随着该请求并被发送到文档管理服务器10a。

此外，上述示例是针对用总体管理方法执行文档更新的情况而给出的。但是，也可以用其他方法执行文档更新。例如，可以考虑用于记录更新前后的文档的差分数据的方法。可以通过客户机终端20中的诸如阅览器22或文档编辑器之类的应用程序或通过文档管理服务器10a来创建差分数据。下面将对采用前者的示例进行描述。

在该实施例中，如图21所示，派生关系树中的根节点302，即表示原本的文档记录的节点，具有原本(即，原本的文档数据)的文档ID“D01”332。图21示出了派生关系树300，并且，当用差分管理方法表达用总体管理方法的实施例的图18的派生关系树200d表示的状态时，派生关系树300作为一个示例。在该示例中，在“主办事机构”之下的部门“办事机构A”的基本节点304记录着部门成员使用该基本节点的后代节点的副本ID执行更新的差分数据334。该差分数据是由客户机终端20中的诸如阅览器22之类的应用程序生成的，并被发送到文档管理服务器10a。在基本节点304的后代节点308、312中执行更新时的差分数据“U111”和“U111111”与基本节点304相关联，并被存储。差分数据“U111”是原本“D01”和节点308中的经过更新的文档结果之间的差异，同时，差分数据“D111111”是节点308中的经过更新的文档结果和节点312中的经过更新的文档结果之间的差异。

在这种情况下，例如，响应于节点310的读取请求，文档管理服务器10a从节点308到根节点302跟踪派生关系树300，查找基本节点304，并将包括差分数据“U111”(此时未记录差分数据“U111111”)和根节点302的原本“D01”的副本文件提供给请求源。在该示例中，仅存在一个差分数据。但是，当存在多个差分数据时，还包括并提供所有差分数据的时间顺序信息。请求源的客户机终端20中的阅览器22根据该时间顺序应用所有差分数据，并生成反映所有更新的文档，然后将该文档提供给用户。当用户进一步编辑所提供的文档并发出更新请求命令时，阅览器22向文档管理服务器10a发送伴有差分数据的更新请求，以指示经过编辑的内容(即阅览器22首先提供给用户的文档和经过编辑的最终结果之间的差异)。

在图21的示例中，当更新后代节点314时，向办事机构B的基本节点306记录差分数据“U12”。

接下来，将对实现该管理的文档管理服务器10a的处理进行描述。首先，参考图22，将描述当用差分管理方法从用户接收请求原本记录的文档记录请求时的文档管理服务器10a的过程。在图22中，将与图10的过程中的步骤相同的步骤表示成相同的附图标记，并对其将不再赘述。

在图22的过程中，文档记录单元13a首先将与文档记录请求伴随的从客户机终端20接收到的文档记录到文档数据库11a中(S1a)。然后，将副本SC返回到客户机终端20，生成日志记录(S3，S4)，以及，将在步骤S2中获取的请求方用户的部门属性记录到所生成的日志记录(节点)中(S5a)。

接下来，将参考图23描述当用差分管理方法从用户接收文档读取请求时副本提供单元17a的过程。在图23中，与图11的过程中的步骤相同的步骤表示成相同的附图标记，并对其将不再赘述。

在该过程中，副本提供单元17a从读取请求伴随的副本ID开始到根节点跟踪派生关系树300，并在跟踪过程中收集由各基本节点保存的差分数据(S11a)。在该收集过程中，还获取所有差分数据的时间顺序信息。然后，收集由根节点302保存的原本(S11a)。生成包括原本和时间顺序中的差分数据的副本文件和副本ID，并将其提供给请求方用户(S13)。然后，副本提供单元17a生成日志记录(S14)，获取请求方用户的部门属性(S15)，并判断(S16a)所获取的用户部门属性是否与距离当跟踪派生关系树300时的起点最近的基本节点的部门属性相匹配。如果不匹配，则与读取请求相对应的节点是用户所属部门的基本节点，因此，将用户的部门属性设到与该节点相对应的日志记录中(S17a)，于是，该处理结束。如果匹配，则该处理结束。

接下来，将参考图24描述在差分管理方法中当从用户接收文档更新请求时文档管理单元13a的过程。在图24中，与图12的过程中的步骤相同的步骤表示成相同的附图标记，并对其将不再赘述。

在该过程中，文档记录单元13a将ID(例如“U111”)添加到伴随着更新请求所接收到的差分数据中，从而，使该ID与差分数据相关联，并将该数据存储到存储装置中，例如文档数据库11a中(S21a)。然后，执行步骤S22-S24，以便获取请求方用户的部门属性、提供副本SC以及记录日志记录。跟踪派生关系树，并且，搜索具有与用户的部门属性相同部门属性的节点(S25)。将在步骤S21中分配的ID添加到与所找到的节点相对应的日志记录的差分ID属性的字段中。

采用该结构，可以从日志记录中的数据和时间项中获取有关差分数据的时戳的信息，并且，可以根据时戳确定各种差分数据的时间顺序。

在上文中给出了差分管理方法的示例。当在上述示例中发出读取请求时，文档管理服务器10a跟踪派生关系树300到根节点，并收集在跟踪过程中出现的节点中的差分数据以及原本。与此不同，如果相对于基本节点而将在祖先基本节点中保存的差分数据和原本进行保存时，就不必跟踪到根节点，而仅从读取请求伴随的副本ID跟踪到最近的基本节点就足够了。在这种情况下，如果判断出该请求与步骤S16a(图23)中的读取请求处理中的基本节点相对应，则在步骤S11a中收集的原本和差分数据可以与步骤S17a中的读取请求的日志记录相关联。

此外，在上述示例中，虽然在客户机终端20中生成更新操作前后的差分数据，但是，当然也可以在文档管理服务器10a中生成该数据。

在上述示例中，由部门成员执行的更新的内容是在该部门的基本节点中进行收集的。在读取请求期间，在该基本节点中经过更新的内容用于生成副本文件。因此，执行读取请求的用户可以读取反映该用户所属部门内的最新更新的文档。此外，根据该实施例的框架，当根据组织的分级结构从较高部门向较低部门发送副本SC时，提供给属于某一部门的某一用户的文档仅包括来自该部门的更新和直接来自较高部门的更新，而不包括其他部门的更新。例如，对于图21的示例中的节点316的读取请求而言，将原本“D01”和表示节点314中的更新的差分数据336提供给该用户，同时，未将不直接处于节点316之上的节点304中的更新结果和节点304的后代节点中的更新结果提供给该用户。因此，可以减少负面影响，例如另一部门的经过编辑的内容所导致的混淆。

上述示例示出了用于更新文档实体的文档管理。但是，对于首先进行记录然后在较低部门中再添加文档附件的文档来说，类似的文档管理也可以用在更新文档集合(由一个或多个文档构成)的方法中。

在该方法中，如图25所示，文档集合与基本节点相关联并由基本节点的部门共享。例如，在图25的派生关系树400中，作为原本的文档“D1”与作为主办事机构基本节点的根节点402相关联。此时，当将用户1获取的副本SC“ID1”提供给办事机构A的用户2以及用户2使用该副本SC“ID1”发出读取请求时，文档记录单元13a找到已经记录在根节点420中的文档集合S1，根节点420即从副本ID“ID1”开始的第一基本节点，并将包括该文档集合的副本文件提供给用户2。将该读取事件作为节点404添加到派生关系树400中。这里，节点404成为办事机构A的基本节点，并且，将记录在从节点404派生出的节点408和节点412中的文档附件“D111”和“D111111”记录到节点404的文档集合S11中。另一方面，对于节点410的读取请求来说，将跟踪派生关系树400时遇到的第一基本节点404的文档集合S11提供给用户。同样，节点406成为办事机构B的基本节点，并且，将在节点414中记录的文档附件“D121”记录到节点406的文档集合S12中，并响应于节点406的后代节点中的读取请求而提供节点406的文档集合S11。

例如，可以将文档集合记录成图26所示的日志记录中的一项。图26示出了与图25的派生关系树相同时间点相对应的日志数据。

接下来，将描述文档管理服务器10a用于实现该管理的处理。首先，将参考图27描述当从用户接收原始文档记录请求时文档管理记录单元13a的过程。在图27中，与图10的过程中的步骤相同的步骤表示成相同的附图标记，并对其将不再赘述。

首先，在图27的过程中，文档记录单元13a将ID分配给伴随着文档记录请求从客户机终端20接收到的文档，并将该文档记录到文档数据库11a中(S1b)。然后，将副本SC返回到客户机终端20，生成日志记录(S3、4)，将在步骤S2中获取的请求方用户的部门属性记录成所生成的日志记录(节点)的部门属性，并将在步骤S1b中分配的ID添加到日志记录中的文档集合属性的字段中(S5b)。

接下来，将参考图28描述当从用户接收文档读取请求时副本提供单元17a的过程。在图28中，与图11的过程中的步骤相同的步骤表示成相同的附图标记，并对其将不再赘述。

在该过程中，副本提供单元17a从读取请求伴随的副本ID开始跟踪派生关系树400，并搜寻具有文档集合属性值的节点(即基本节点)(S11b)。然后，从文档数据库11a中获取在该跟踪中找到的第一基本节点中的文档集合中包括的文档(S12b)，生成包括该文档和副本ID的副本文件，并将其提供给原用户(S13)。然后，副本提供单元17a生成日志记录(S14)，获取请求方用户的部门属性(S15)，并判断请求方用户的部门属性是否与在步骤S11b中获取的基本节点的部门属性相匹配(S16)。如果它们不匹配，则对应于读取请求的节点成为用户所属部门的基本节点，将用户的部门属性值设到与该节点相对应的日志记录中，将在步骤S12b中获取的文档集合添加到日志记录的文档集合属性中(S17b)，于是，处理结束。如果它们匹配，则跳过步骤S17b，于是处理结束。

接下来，将参考图29描述当从用户接收文档附件记录请求时文档记录单元13a的过程。在图29中，与图12的过程中的步骤相同的步骤表示成相同的附图标记，并对其将不再赘述。

在该过程中，文档记录单元13a将一个ID(例如“D111”)添加到伴随着文档附件记录请求所接收到的文档附件中，该文档附件与该ID相关联，并将其存储到文档数据库11a中(S21b)。然后，执行用于获取请求方用户的部门属性、提供副本SC以及记录日志记录的步骤。跟踪派生关系树，并搜索具有与用户部门属性相同的部门属性的节点(S25)。将在步骤S21b中分配的ID添加到与所找到的节点相对应的日志记录的文档集合属性的字段中(S26b)。

由于上述处理而进行分配时，如果采用将文档附件添加到文档集合的文档分配方法，则可以很容易地实现文档集合在部门内的共享。当在图25至图29的示例中设定新的基本节点时，将记录到较高基本节点中的文档集合进行传递并设定到该新的基本节点中。但是，并不总是如此。例如，与此相反，如在差分管理方法的更新信息管理中的图21的示例中，针对各基本节点，仅记录在与基本节点相对应的部门中新生成的更新信息，基于该读取请求跟踪派生关系树到根节点，将在跟踪中所遇到的所有基本节点中的文档进行收集并提供给用户。在这种情况下，如果一个较高节点的文档集合中的文档与一个较低节点的文档集合中的文档具有相同的文件名，则选择较低节点的文档，而忽略具有相同文件名的较高节点的文档。这也可适用于对分配在该文档集合中的文档进行更新的情况。

如果用户将更新添加给属于文档集合的文档，则可以用文档更新的实施例中的上述方法(总体管理方法或差分管理方法)来管理文档集合中的各文档。

此外，至此为止通常执行了下面的操作，即：将诸如构成文档的章节或部分之类的逻辑组分准备到不同文件(即文档部分文件)中以及将一个文档表达成文档部分文件的集合。日本专利公开案No.2003-067402披露了通过这些单独的文档部分文件采用总体管理方法或差分管理方法管理更新信息的方法。因此，将一个文档表达成由多个文档部分文件构成的结构，并对每个部分文件管理更新信息。在把构成一个文档的文档部分文件组视为上述文档集合(其中，唯一不同在于是否包括有关构成文档部分文件组的信息)并对文档部分文件分别管理上述更新和读取操作的情况下，可以实现该实施例中的管理方法。

此外，在上述示例中，当存在文档更新请求或文档附件记录请求时，将更新信息或文档附件记录到派生关系树中的最近祖先基本节点中。但是，在更新或记录时，不需要收集基本节点中的更新信息或文档附件。例如，当收到读取请求时可以进行收集。也就是说，在该示例中，在更新请求或文档附件记录请求时，将更新信息或文档附件记录到与该请求相对应的节点中。然后，当有读取请求时，找到与该请求相对应的节点的祖先基本节点，并收集已经记录到该基本节点的后代节点中的更新信息或文档附件，并将其提供给请求方用户。下面将参考图30和31，对适用于差分管理方法中的更新的该管理的过程进行描述。

图30示出了当接收更新请求时的文档记录单元13a的过程。在图30中，与图12和图24的过程中的步骤相同的步骤表示成相同的附图标记，并对其将不再赘述。在该过程中，文档记录单元13a首先将ID添加到伴随着更新请求所接收到的差分数据中，并将该数据存储到存储装置中，例如文档数据库11a中(S21a)。然后，获取请求方用户的部门属性，提供副本SC(S22，S23)，并记录日志记录(S24c)。将在步骤S21a中分配给差分数据的ID作为一个属性记录到此时生成的日志记录中。

图31示出了当接收读取请求时的副本提供单元17a的过程。在图31中，与图11和图23的过程中的步骤相同的步骤表示成相同的参考符号，并对其将不再赘述。

在该过程中，副本提供单元17a从读取请求伴随的副本ID到根节点跟踪派生关系树300，并搜索在跟踪中遇到的第一个基本节点(S11c)。然后，这时从所找到的基本节点向后代节点沿着派生关系树下移，对在该下移过程中遇到的各节点中记录的差分数据进行收集(S12c)。在该数据收集中，获取差分数据所属节点的日期和时间属性，作为差分数据的时戳，并根据该时戳确定各种差分数据的时间顺序。针对所遇到的所有基本节点执行上述处理，直到达到根节点为止。后续的过程与图23的过程相同。

此外，在上述示例中，假定文档在相同部门内传送或者根据组织的分级结构从较高部门向较低部门传送。但是，考虑到将文档传送到不相关部门的用户的情况，例如，可以执行以下类型的控制。也就是说，当从用户接收到读取请求时，例如，文档管理服务器10a在图11的过程的步骤S16中判断该用户所属部门是否位于步骤S11中获取的最近基本节点的部门属性表示的部门之下。如果它不是附属部门，则可以执行控制，以防止读取。因此，可以防止一个部门内更新的内容被不相关部门的人看到。

此外，使用上述实施例的框架，也可以为较高部门收集附属部门中的文档的更新或添加结果。例如，这可以由属于较高部门和较低部门的用户(例如较低部门的领导)来实现，该用户作为较低部门的成员获取由较低部门中的更新或添加所产生的文档(或文档组)，并作为较高部门的成员向文档管理服务器10a发送伴有该文档(或文档组)的更新或添加请求。例如，在派生关系树400具有图25所示的状态时，当作为办事机构A的领导的用户2使用在节点410中获取的副本SC并以作为办事机构A成员的资格发出读取请求时，可以获取包括D1、D111以及D111111的副本数据(或文件夹)。然后，当用户2发出伴有副本数据的文档附件记录请求(如果需要的话，在执行副本数据的另一许可操作之后)时，将用户2的资格(成员资格)改变成主办事机构的成员。因此，将D1、D111以及D111111记录到根节点402，即主办事机构的基本节点。在这种情况下，优选防止把添加记录到已经处在根节点402中的文档。对于该处理，可以在阅览器22中提供用户界面，从而可以使用户选择资格(用户所属的部门)。

此外，在上文中将副本ID之间的派生关系树表达成日志管理单元19的日志记录组中“旧副本ID”和“提供的副本ID”之间的对应关系。但是，派生关系树的数据结构并不限于此，也可以独立于日志记录组而进行创建。

上述实施例中的“数字文档”并不仅限于用文字处理程序或电子表格程序创建的文档数据，也可以包括各种类型的数据，例如音频数据、图像数据、视频数据、多媒体数据等。因此，“读取”“数字文档”的概念包括重放音频数据、图像数据、视频数据以及多媒体数据。也就是说，上述实施例中的“数字文档”的“读取”包括数字文档的广义宽泛使用。换句话说，响应于***中的用户使用副本SC对数字文档的“获取请求”，文档管理服务器10将与该数字文档相关联的副本SC提供给该用户，然后，响应于使用该副本SC对数字文档的“使用请求”，将包括有数字文档副本(即，反映区别数据或附加数据的副本)的副本文件提供给要求“使用”的用户。

构成上述***的文档管理服务器10、10a一般通过在计算机上执行程序来实现，该程序描述上述各部分的功能或处理。该计算机可以具有图32所示的电路结构，其中，CPU(中央处理单元)50、存储器(主存储器)52、各种I/O接口54等经由总线56相连接。此外，用于读取诸如CD、DVD以及闪存之类的各种标准的便携式非挥发性记录介质的硬盘驱动器58或磁盘驱动器60经由I/O接口54连接至例如总线56。驱动器58、60用作存储器的外部存储。描述实施例的处理的程序经由记录媒体(例如，CD或DVD)或经由网络而存储在二级存储器件(例如，硬盘驱动器58)中，并安装到计算机中。存储在二级存储器件中的程序被加载到存储器中并由CPU执行，从而执行实施例中的文档管理服务器10、10a的处理。同样，实施例中的客户机终端20也可以通过使用通用计算机来实现。

上面针对本发明的示例性实施例做出的描述用于说明和描述目的。其并不是穷举的，也不应将本发明限制到所公开的具体形式。显然，对于本领域的技术人员来说，多种修改和改变是显而易见的。所选择和描述的实施例用于更好地解释本发明的原理及其实际应用，以便能够使本领域的技术人员理解，本发明的各种实施例和适于特定用途的各种修改都是可以想象得到的。本发明的保护范围应由下面的权利要求及其等价物来界定。

Claims

1.一种用于管理要提供给客户机的数字文档的文档管理服务器，包括：

接收单元，其从客户机接收请求和第一ID，所述第一ID表示所述请求之对象的数字文档；

ID处理单元，当响应于所述请求而对所述数字文档执行一项操作时，其发出与所述操作相关联的第二ID，并记录将所述第二ID作为所述第一ID之子节点的派生关系；

基本节点设定单元，其设定用于表示用户在所述派生关系的节点组中的部门的基本节点；

文档关联单元，其将所述数字文档的相关数据与所述基本节点相关联，其中所述数字文档的相关数据通过与基本节点的后代节点相对应的操作来记录；以及

文档提供单元，当其收到用户对数字文档的请求时，通过从所述请求伴随的ID到根节点跟踪所述派生关系来检测用户所属部门的基本节点，并根据与所检测到的基本节点相关联的相关数据提供所请求的文档。

2.根据权利要求1所述的文档管理服务器，其中：

所述文档关联单元响应于来自客户机的对文档更新或文档添加的请求，将所述请求伴随的所收到数字文档的相关数据与当从所述请求伴随的所收到ID到所述根节点跟踪所述派生关系时首先检测到的基本节点相关联。

3.根据权利要求1所述的文档管理服务器，其中：

所述相关数据是根据来自客户机的更新请求而更新的数字文档；

所述文档关联单元将所述更新的数字文档与当从所述更新请求伴随的所收到ID到所述根节点跟踪所述派生关系时首先检测到的基本节点相关联；

所述文档提供单元向所述客户机提供所述数字文档，所述数字文档与当从所述请求伴随的所收到ID到所述根节点跟踪所述派生关系时首先检测到的所述基本节点相关联。

4.根据权利要求1所述的文档管理服务器，其中：

所述相关数据是根据文档更新请求执行更新之后的差分数据；

所述文档提供单元将相关联的差分数据和有关差分数据的时间顺序的信息提供给所述客户机。

5.根据权利要求1所述的文档管理服务器，其中：

所述相关数据是与文档附件记录请求相对应的文档附件数据；

所述文档提供单元将相关联的文档附件数据提供给所述客户机。

6.根据权利要求1所述的文档管理服务器，其中：

当所述检测到的基本节点表示的部门和所述客户机所属的部门不同时，所述基本节点设定单元将所述派生关系中与所述请求相对应的所述第二ID的节点设为表示所述用户的部门的基本节点。

7.根据权利要求6所述的文档管理服务器，其中：

所述基本节点设定单元将所述文档提供单元响应于所述请求而提供的所述相关数据与响应于所述请求而设定的所述基本节点相关联。

8.一种用于管理文档使用的***，包括管理数字文档的文档管理服务器和使用数字文档的客户机；

所述文档管理服务器包括：

文档提供单元，当其收到用户对数字文档的请求时，通过从所述请求伴随的ID到根节点跟踪所述派生关系来检测用户所属部门的基本节点，并根据与所检测到的基本节点相关联的相关数据提供所请求的文档；

所述客户机包括：

ID管理单元，其将响应于与数字文档相关的请求而从所述文档管理服务器接收到的ID保存为与所述数字文档相对应的ID；以及

请求单元，当指定所述ID管理单元保存的所述ID并从用户接收到操作命令时，其将伴有所述ID的请求发送到所述文档管理服务器。

9.根据权利要求8所述的用于管理文档使用的***，其中：

所述客户机通过将表示多个部门中发出所述请求的用户所属的部门的信息关联于由所述请求单元发送到所述文档管理服务器的所述请求，而将所述信息告知所述文档管理服务器。

10.一种用于文档管理的方法，包括：

从客户机接收请求和第一ID，所述第一ID表示所述请求之对象的数字文档；

当响应于所述请求而对所述数字文档执行一项操作时，发出与所述操作相关联的第二ID；

记录将所述第二ID作为所述第一ID之子节点的派生关系；

设定用于表示用户在派生关系树的节点组中的部门的基本节点；

将所述数字文档的相关数据与所述基本节点相关联，其中所述数字文档的相关数据通过与基本节点的后代节点相对应的操作来记录；

当收到用户对数字文档的请求时，通过从所述请求伴随的ID到根节点跟踪所述派生关系树来检测用户所属部门的基本节点；以及

根据与检测到的基本节点相关联的相关数据，提供所请求的文档。

11.根据权利要求10所述的方法，其中：

所述相关数据是根据文档更新请求而更新的数字文档；

所述相关数据的关联包括：将伴随着所述文档更新请求而收到的所述更新的数字文档与当从所述请求伴随的所收到ID到所述根节点跟踪所述派生关系时首先检测到的基本节点相关联；以及

向所述客户机提供与当从所述请求伴随的所收到ID到所述根节点跟踪所述派生关系时首先检测到的所述基本节点相关联的所述数字文档。

12.根据权利要求10所述的方法，其中：

将所述文档提供给所述客户机包括：将相关联的差分数据和有关差分数据的时间顺序的信息提供给所述客户机。

13.根据权利要求10所述的方法，其中：

将所述文档提供给所述客户机包括提供关联的文档附件数据。

14.根据权利要求10所述的方法，其中：

所述基本节点的设定包括：当所述检测到的基本节点表示的部门和所述用户所属的部门不同时，将所述派生关系中与所述请求相对应的第二ID的节点设为表示所述用户的部门的基本节点。

15.根据权利要求14所述的方法，其中：

所述基本节点的设定包括：将响应于所述请求的相关数据组与响应于所述请求而设定的所述基本节点相关联。

16.根据权利要求10所述的方法，其中：

所述相关数据的关联包括：响应于对文档更新或文档添加的请求，将所述请求伴随的所收到数字文档的相关数据与当从所述请求伴随的所收到ID到所述根节点跟踪所述派生关系时首先检测到的基本节点相关联。