CN1989498A

CN1989498A - 电子文件管理***

Info

Publication number: CN1989498A
Application number: CNA2005800244749A
Authority: CN
Inventors: 吉冈孝司; 武仲正彦
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2004-07-20
Filing date: 2005-01-24
Publication date: 2007-06-27
Anticipated expiration: 2025-01-24
Also published as: US20070050713A1; US8091015B2; JP4339891B2; KR100835631B1; CN1989498B; WO2006008847A1; KR20070015161A; JPWO2006008847A1; EP1770546A1; EP1770546A4

Abstract

本发明提供电子文件管理***、电子文件管理方法、电子文件管理程序。一种电子文件管理***等，能够担保电子文件中进行的部分修改是正确进行的，而且能够对它们的正当性进行第三方证明。一种管理利用电子信息而制作的原稿信息的电子文件管理***，该***具有：部分识别信息生成部(51)，其生成以可识别的方式表示文件信息的各部分的部分识别信息；部分修改信息生成部(52)，其在文件信息的各部分有修改时，生成与被修改的部分的修改历史相关的信息、即部分修改信息；以及原稿管理部(40)，其把文件信息、部分识别信息、部分修改信息和所规定的规定规则信息关联起来进行管理。

Description

电子文件管理***

技术领域

本发明涉及一种对利用电子信息而生成的文件信息进行管理的电子文件管理***等，特别涉及在适用于要求与纸件相同的证据能力的文件的电子化、流通、保管，且产生部分修改(例如包括追加、变更、删除、涂墨(墨塗り)等)的电子化的文件信息中，能够容易地进行该修改部位的确定以及其正当性的担保、和第三方证明的电子文件管理***、电子文件管理方法、电子文件管理程序。

背景技术

作为现有技术，首先说明处理纸件文件时的修改方法及其正当性确认方法。

以往，作为对纸件文件进行修改的代表性的修改方法，图48所示的方法已被公知。即，根据图48，利用双重线删除修改部位的文字，在其上的空白处标注修改文字(P1)，然后在空白处注明修改信息，加盖当事人双方的修改***(P2)。

在对以往的纸件文件的修改中，通过进行上述P1、P2，可以担保、确认以下内容。

(1)能够容易地确认并确定修改部位，能够确认除修改部位之外没有因故意、过失造成的变更。

(2)能够容易地确认并确定修改范围。

(3)能够容易地确认修改部位是由谁修改的。

(4)能够确认是否是可以修改的部位。

(5)能够确认修改前的内容。

(6)能够按照有关修改的规则(控制信息)进行修改，而且可以验证。

并且，对在保险合同申请书和运输委托票等中使用的带复写纸的文件，同样也可以担保、确认以下内容。

(7)能够阴蔽部分内容，能够确认其他部位没有修改。

(8)在已对比了原件和复写纸的内容的情况下，能够根据原件和复写纸上书写的笔迹确认内容相同。

(9)通过分开保管原件和复写纸，可以检测出内容的窜改。

(10)在根据上述(9)来打官司时，能够进行与内容相关的第三方证明。

(11)原件和复写纸根据需要被流通使用。并且，根据情况可以分别流通使用。

如上所述在使用纸件文件时，修改方法及其正当性确认方法有各种优点，但在另一方面，伴随近年来的IT技术的进步，基于数据的处理、保存等的便利性，正在提出使用电子数据(电子信息)来代替上述的纸件文件的技术(例如，参照下述专利文献1、2、3和非专利文献1、2)。

专利文献1 日本特开2000-285024号公报

专利文献2 日本特开2001-117820号公报

专利文献3 日本特开2003-114884号公报

非专利文献1情報処理学会/コンピユ一タセキユリテイ研究会(CSEC)输文「電子文書墨塗り問题」(2003/7/17)(2003-CSEC-22-009)

非专利文献2SCIS2004論文「開示条件を制御可能な電子文書墨塗り技術」

专利文献1和专利文献2涉及电子文件的原稿保管技术，提供以下技术：在保存电子文件时，使电子信息具有纸件原稿所具有的性质，并且保护电子文件不被窜改。即，这些技术中，将已确定的最终形式的电子文件作为原稿来保管并管理的机构、即原稿的所在是明确的，着重点在于如何安全地保管在一个组织内所积蓄的原稿。

但是，在这种原稿保管技术中，在对电子文件发生了修改时，哪怕一部分被进行了修改的情况下，也被识别为“窜改”。例如，在考虑前面叙述的“对纸件合同文件的修改”时，在修改时进行以下处理，“利用双重线删除修改部位的文字，在其上的空白处标注修改文字。然后加盖修改人的***”，但是即使施加了修改，也与合同文件的原稿没有差异。

关于纸件文化的这种行为，如果履行了正当手续进行了修改，则被官方地判断，能够进行第三方证明。

与此相对，如果是电子文件，从证据性的观点考虑，如果适用以往的原稿保管技术，则产生不能识别修改部分是被窜改的、还是经过正当手续进行的修改的问题。这也可以说是源于设计成能够检测出对电子文件的任何变更这样的当前的电子签名的特征。

专利文献3涉及电子文件编辑显示技术，提供一种保证电子文件的原稿性、并且不需要使文件为多份即可对每个要素进行修改和追加及显示控制的手段。在该技术中，原稿信息由包括作为实际数据的原稿部分和记载了每个要素的控制的定义部分的一个文件构成，并被实施管理，在进行修改和追加时，作为修改信息记载附加在该定义部分中。由此，可以进行与修改信息相关的第三方证明。

但是，在该方式中必须示出包括旧版在内的所有的修改信息，存在不能进行隐藏了部分内容(实施了涂墨)的状态和仅使用部分版本的第三方证明的问题。

非专利文献1涉及电子文件涂墨技术，在论文“電子文書墨塗り問题”中提出了电子文件的涂墨技术，该技术解决对某个文件实施的签名由于将文件的一部分隐匿而不能验证的问题。通过应用该论文的电子文件涂墨技术，即使在对带签名的电子文件实施了涂墨的状态下，也能够进行签名验证，而且能够对涂墨部位之外没有变更进行第三方证明，能够实现在专利文献3的问题部分中指出的“将部分内容隐藏(实施了涂墨)的状态下的第三方证明”。

但是，在该论文的电子文件涂墨技术中，保证原始文件的制作者，而不能明确地识别出由谁进行了涂墨。另外，列举了信息公开制度中的电子文件涂墨问题作为使用场景，但没有考虑到使部分涂墨的文件在多个实体之间流通，进一步使用该文件的情况。

发明内容

本发明就是为了解决上述问题而提出的，其目的在于，提供电子文件管理***、电子文件管理方法和电子文件管理程序，在电子文件于多个实体之间辗转流通的过程中，对于被实施了部分修改(例如包括追加、变更、删除等)的电子文件能够确定修改部位，并且能够确认除修改部位之外没有改变，能够确定并确认部分修改是由谁进行的，而且能够担保该部分修改是正确进行的，可以对它们的正当性进行第三方证明。

为了解决上述问题，本发明的电子文件管理***对利用电子信息而制作的文件信息进行管理，其特征在于，该电子文件管理***具有：规则信息保管部，其保管预先规定的规则信息；部分识别信息生成部，其生成以能够识别的方式表示文件信息的各部分的部分识别信息；部分修改信息生成部，其在所述文件信息的各部分有修改指示时，生成与被修改的部分的修改历史相关的信息、即部分修改信息；管理部，其把所述文件信息、由所述部分识别信息生成部生成的部分识别信息、由所述部分修改信息生成部生成的部分修改信息、和保管在所述规则信息保管部中的规则信息关联起来进行管理；以及登记文件验证部，其使用通过所述管理部而被关联起来的部分识别信息、部分修改信息，来验证文件信息的正当性。

在该电子文件管理***中，其特征在于，所述部分识别信息生成部将文件信息划分为多个部分，根据各部分的信息生成所述部分识别信息。并且，在该电子文件管理***中，其特征在于，所述登记文件验证部确认与部分修改相关的合适性。另外，在该电子文件管理***中，其特征在于，该电子文件管理***具有收发部，该收发部在多个实体之间进行由所述管理部管理的信息的收发。

并且，在本发明的电子文件管理***中，其特征在于，所述部分识别信息生成部使用哈希(hash)函数生成所述部分识别信息。

并且，在本发明的电子文件管理***中，其特征在于，所述部分识别信息生成部对所述各部分的信息追加任意信息来生成所述部分识别信息。

在该电子文件管理***中，其特征在于，所述部分识别信息生成部在文件信息被修改时，可以仅针对从前一版本被修改的位置生成新的部分识别信息，并且，在该电子文件管理***中，其特征在于，文件信息和部分识别信息以及部分修改信息可以分别被赋予了签名。另外，在本发明的电子文件管理***中，其特征在于，该电子文件管理***具有登记规则验证部，其在对所述文件信息进行了修改时，使用规则信息来验证是否在可修改范围内进行了修改。

并且，本发明的特征在于，由所述管理部管理的所述信息由具有分层的文件结构的XML数据构成。并且，本发明的特征在于，所述部分识别信息生成部按照所述文件信息的各部分的修改指示，在具有分层的文件结构的XML数据的修改中，把从前一版本被修改的位置、以及未被修改的位置的所有母要素、子要素作为对象，生成部分识别信息。

并且，本发明的特征在于，所述部分识别信息生成部对从前一版本被修改的位置，把子要素及其所属的母要素作为对象来生成部分识别信息，针对对于属于母要素的所有子要素没有修改的位置，只把该母要素作为对象来生成部分识别信息。

并且，本发明的特征在于，所述部分识别信息生成部对于作为修改位置所记录的母要素的部分识别信息，当在下次修改时该位置没有修改的情况下，沿用所述记录的母要素的部分识别信息。

另外，本发明的特征在于，所述部分识别信息生成部只针对从前一版本被修改的位置，把子要素及其所属的母要素作为对象来生成部分识别信息，所述管理部只对与前一版本相比的差分的部分识别信息进行管理。

另外，本发明的特征在于，所述部分识别信息生成部对记录了同一要素名的正文，使用Xpath功能生成对应的部分识别信息。

并且，本发明的特征在于，所述管理部可以把部分识别信息的所有版本连接起来进行管理，而且所述管理部可以利用一个文件来管理该信息组，所述管理部使用Xlink功能来管理该信息组，此外所述管理部能够按时间序列进行识别、并且能够识别各个版本的制作者。并且，本发明的特征在于，所述管理部可以使用XML部分签名作为对各个版本的制作者的识别。另外，本发明的特征在于，所述管理部还可以把所有电子信息作为对应于版本的原稿信息来处理，并且对于被实施版本管理的原稿信息的内容，根据各个版本的原稿信息的内容能够识别可浏览者和不可浏览者。

并且，本发明的电子文件管理方法进行由计算机利用电子信息而制作的文件信息的管理处理，其特征在于，该电子文件管理方法执行以下步骤：登记请求接收步骤，该登记请求接收步骤接收所述计算机制作的文件信息的登记请求；登记规则验证步骤，该登记规则验证步骤参照预先保管有规则信息的规则保管部的信息，验证在所述登记请求接收步骤接收的文件信息是否符合规定的规则信息；部分识别信息生成步骤，该部分识别信息生成步骤在通过所述登记规则验证步骤的验证认为所述文件信息符合规定的规则信息时，生成以可识别的方式表示所述文件信息的各部分的部分识别信息；以及登记步骤，该登记步骤把所述文件信息、所述部分识别信息和所述规则信息关联起来进行登记。

并且，本发明的电子文件管理方法进行计算机利用电子信息而制作的文件信息的管理处理，其特征在于，该电子文件管理方法执行以下步骤：修改请求接收步骤，接收关于所述计算机对管理对象的文件信息进行了修改的文件信息的修改请求；修改规则验证步骤，该修改规则验证步骤验证在所述修改请求接收步骤接收的文件信息是否符合在规则信息保管部中保管的规则信息；部分识别信息生成步骤，该部分识别信息生成步骤在通过所述修改规则验证步骤认为所述文件信息符合所述规则信息时，生成以可识别的方式表示所述被修改的文件信息的各部分的部分识别信息；部分修改信息生成步骤，该部分修改信息生成步骤在通过修改规则验证步骤认为所述文件信息符合所述规则信息时，生成与所述被修改的部分的修改历史相关的信息、即部分修改信息；管理步骤，该管理步骤把所述被修改的文件信息、所述部分识别信息、所述部分修改信息和所述规则信息关联起来进行管理；以及登记验证步骤，该登记验证步骤使用通过所述管理步骤被关联起来的部分识别信息、部分修改信息，来验证文件信息的正当性。

并且，本发明的电子文件管理程序使计算机执行利用电子信息而制作的文件信息的管理，其特征在于，该电子文件管理程序使计算机执行以下步骤：登记请求接收步骤，该登记请求接收步骤接收所制作的文件信息的登记请求；登记规则验证步骤，该登记规则验证步骤参照预先保管有规则信息的规则保管部的信息，验证在所述登记请求接收步骤接收的文件信息是否符合规定的规则信息；部分识别信息生成步骤，该部分识别信息生成步骤在通过所述登记规则验证步骤的验证认为所述文件信息符合规定的规则信息时，生成以可识别的方式表示所述文件信息的各部分的部分识别信息；以及登记步骤，该登记步骤把所述文件信息、所述部分识别信息和所述规则信息关联起来进行登记。

并且，本发明的电子文件管理程序使计算机执行利用电子信息而制作的文件信息的管理，其特征在于，该电子文件管理程序使计算机执行以下步骤：修改请求接收步骤，该修改请求接收步骤接收关于对管理对象的文件信息进行了修改的文件信息的修改请求；修改规则验证步骤，该修改规则验证步骤验证在所述修改请求接收步骤接收的文件信息是否符合在规则信息保管部中保管的规则信息；部分识别信息生成步骤，该部分识别信息生成步骤在通过所述修改规则验证步骤认为所述文件信息符合所述规则信息时，生成以可识别的方式表示所述被修改的文件信息的各部分的部分识别信息；部分修改信息生成步骤，该部分修改信息生成步骤在通过修改规则验证步骤认为所述文件信息符合所述规则信息时，生成与所述被修改的部分的修改历史相关的信息、即部分修改信息；管理步骤，该管理步骤把所述被修改的文件信息、所述部分识别信息、所述部分修改信息和所述规则信息关联起来进行管理；以及登记验证步骤，该登记验证步骤使用通过所述管理步骤被关联起来的部分识别信息、部分修改信息，来验证文件信息的正当性。

在该电子文件管理程序中，其特征在于，所述部分识别信息生成步骤使计算机执行以下步骤：将文件信息划分为多个部分，根据各部分的信息而生成所述部分识别信息，并且，本发明的特征在于，所述部分识别信息生成步骤使计算机执行使用哈希函数来生成所述部分识别信息的步骤。

附图说明

图1是表示本发明的实施方式的原理图的方框图。

图2是表示本发明的实施方式的电子文件管理***的结构的功能方框图。

图3是表示规则信息的内容示例的图。

图4是表示部分识别信息的内容示例的图。

图5是表示登记新文件时的保管状态的图。

图6是表示新文件登记处理的动作的流程图。

图7是表示确定可修改范围/不可修改范围的示例图。

图8是表示部分修改信息的内容示例的图。

图9是表示登记文件修改时的保管状态的图。

图10是表示登记文件修改处理的动作的流程图。

图11是表示修改规则信息和部分修改信息的比较的图。

图12是表示登记文件和部分识别信息的比较的图。

图13是表示部分识别信息的新版和旧版的比较的图。

图14是表示登记文件验证处理的动作的流程图。

图15是表示第2局面中的利用场景的图。

图16是表示登记文件修改(部分涂墨)时的原稿保管状态的图。

图17是表示发送对象的一份合同文件的图。

图18是表示登记文件流通(发送)处理的动作的流程图。

图19是表示等待登记文件接收处理的动作的流程图。

图20是表示登记文件获取处理的动作的流程图。

图21是表示第三方证明1的图。

图22是表示第三方证明2的图。

图23是表示第三方证明3的图。

图24是表示实施方式2中的第2应用领域的利用场景的图。

图25是表示利用XML数据来表现保险合同申请书(第1版)-正文的示例的图。

图26是表示保险合同申请书(第1版)的XML数据模型的图。

图27是表示利用XML数据来表现保险合同申请书(第1版)-部分识别信息的示例的图。

图28是表示提取了“合同人”的XML数据模型的图。

图29是表示生成保险合同申请书(第1版)时的保管状态的图。

图30是表示利用XML数据来表现保险合同申请书(第2版)-正文的示例的图。

图31是表示利用XML数据来表现保险合同申请书(第2版)-部分识别信息的示例的图。

图32是表示生成保险合同申请书(第2版)时的保管状态的图。

图33是表示金融机构担当人可以浏览的验证数据组的图。

图34是表示利用XML数据来表现保险合同申请书(第3版)-正文的示例的图。

图35是表示利用XML数据来表现保险合同申请书(第3版)-部分识别信息的示例的图。

图36是表示生成保险合同申请书(第3版)时的保管状态的图。

图37是表示第2版的所有部分识别信息的连接管理的图。

图38是表示第3版的所有部分识别信息的连接管理的图。

图39是表示使用方式2并利用XML数据来表现部分识别信息(第2版)的示例的图。

图40是表示生成使用了方式2的保险合同申请书(第3版)时的保管状态的图。

图41是表示评价分析用的XML数据示例的图。

图42是表示评价分析用的XML数据的更新的图。

图43是表示基于方式0的部分识别信息的生成和验证的图。

图44是表示基于方式1的部分识别信息的生成和验证的图。

图45是表示基于方式2的部分识别信息的生成和验证的图。

图46是表示各方式的分析结果的图。

图47是表示各方式的分析结果的泡泡图(bubble chart)的图。

图48是表示以往采用纸件的已修改合同文件的一例的图。

具体实施方式

以下，使用附图说明本发明的实施方式。

本发明的实施方式的电子文件管理***将规则信息(登记用规则信息和修改用规则信息)和部分完整性信息(部分识别信息和部分修改信息)，独立于利用电子信息生成的作为电子文件的文件信息而另外保存，即作为电子文件部分完整性保证***，提供一种验证电子文件并使其流通的机制。

图1表示本发明涉及的电子文件管理***的原理图。首先，使用图1说明电子文件管理***的基本结构。另外，以下在本说明书中，文件信息和原稿信息、及文件和原稿分别作为同义词来使用。

图1所示的电子文件管理***具有登记单元1、生成单元2、管理单元3、验证单元4和流通单元5。

登记单元1把根据电子信息而生成的文件信息作为原稿信息进行登记，生成单元2生成用于识别所登记的原稿信息的部分修改、变更、追加、删除等(以下称为修改)的部分识别信息，和表示原稿信息的部分修改历史的部分修改信息。

管理单元3把部分识别信息和部分修改信息这两种信息作为部分完整性信息，与原稿信息一起管理，并且与规则信息关联起来管理。

关于规则信息，在登记原稿信息时，登记规则信息被作为记述了该原稿信息中的必要记载事项(必要文件信息)和制作者权限等条件的信息来使用，并且在原稿信息登记后的修改时，修改规则信息被作为记述了针对该原稿信息预先确定的部分修改管理控制信息(修改者、可修改范围、不可修改范围等)、步骤、制约、条件等的信息来使用。另外，在本实施方式中，修改规则信息和登记规则信息使用相同的信息。

如果是纸件的合同文件，应该输入的位置和修改者、修改操作、步骤由规章等确定，提供在由电子信息构成的文件信息中也进行相同的操作控制和验证其内容的手段。

验证单元4使用修改规则信息和部分完整性信息，确认针对原稿信息的部分修改是否被正确地进行。

流通单元5构成进行原稿信息的收发，用于使该原稿信息在多个实体之间流通的收发部。

登记单元1登记的原稿信息在事后打官司时作为证据提交，所以对应于需要第三方证明的文件(例如合同书等重要文件)，所登记的原稿信息保存在登记单元1内。生成单元2生成的部分识别信息和部分修改信息是为了在事后能够确认被登记在登记单元1中的原稿信息的修改位置、修改内容而生成的，被与该原稿信息关联起来。在进行保存在登记单元1内的原稿信息的修改时，保留旧版而生成新版并保存，生成对应于该版数的部分完整性信息，并关联起来。

根据这种电子文件管理***，可以明确地确定上述的原稿信息那样的电子文件的修改位置，可以担保部分修改是正确地进行的，使已修改的电子文件(文件信息)在多个实体之间辗转流通，而且能够保证已修改的电子文件在各个实体时的完整性。

实施方式1

以下，作为本发明的实施方式1，说明把本发明适用于第1应用领域时的情况。图2是表示本发明的实施方式的电子文件管理***的结构的功能方框图。

图2所示的电子文件管理***10具有：请求分析部20；规则管理部30；原稿管理部40；部分完整性信息生成部50；部分完整性信息验证部60；流通管理部70。

以下说明这些各部分的结构和作用。

请求分析部20接受来自使用者90的处理委托，根据各处理进行向规则管理部30、原稿管理部40的处理分配。规则管理部30进行与原稿信息对应的规则信息的保管和验证。

所说的规则信息，针对该原稿信息记述有登记时(生成时)的必要记载事项和制作者权限、及规定的部分修改管理控制信息(修改者、可修改/不可修改范围等)、步骤、制约、条件等。

如果是纸件的合同文件，应该输入的位置和修改者、修改操作、步骤按照规章等确定，提供在电子信息中也同样地进行操作控制和验证其内容的单元。规则管理部30包括规则保管部31、和登记规则验证部32a、修改规则验证部32b这两个子要素。

规则保管部31从请求分析部20接受规则保管委托，进行规则信息的登记、保管。登记规则验证部32a按照已经登记在规则保管部31中的登记规则信息，进行是否是在登记原稿信息时预先确定的制作者、是否符合其必要记载事项的验证。修改规则验证部32b按照已经登记在规则保管部31中的修改规则信息，进行该原稿信息是否被正确地生成、修改的验证。

原稿管理部40把登记在规则管理部30中的规则信息和部分完整性信息一起，与电子信息关联起来，并将这些信息作为原稿信息进行登记、管理、保管。原稿管理部40包括原稿处理部41和原稿保管部42这两个子要素。

原稿处理部41从请求分析部20接受处理委托，进行针对原稿信息的各种处理。原稿处理部41具有以下功能，例如可以执行新数据登记处理(原稿登记处理)、登记数据修改处理(登记原稿修改处理)、登记数据获取处理(登记原稿获取处理)、登记数据验证处理(登记原稿验证处理)。

原稿保管部42从原稿处理部41接受原稿存储及保管委托，并与该原稿信息和部分完整性信息一起进行登记、保管。并且，从原稿处理部41接受原稿信息的获取委托，进行该原稿信息和部分完整性信息的获取。

部分完整性信息生成部50从原稿管理部40接受部分完整性信息生成委托，进行针对原稿信息的部分识别信息和部分修改信息的生成。部分完整性信息生成部50包括部分识别信息生成部51和部分修改信息生成部52这两个子要素。

部分识别信息生成部51从原稿管理部40接受部分识别信息生成委托，进行针对原稿信息的部分识别信息(可识别地表示原稿信息的各部分及其记载事项的信息)的生成。部分识别信息中记载有例如哈希信息和表示该哈希信息相当于哪部分的位置信息，其中上述哈希信息包括各部分的随机数，以便可以确认原稿信息的各部分(例如一个文字单位，或者如果是XML数据则可以是一个要素单位)有无变更。

部分修改信息生成部52从原稿管理部40接受部分修改信息生成委托，进行针对原稿信息的部分修改信息的生成。部分修改信息中记载有例如“何时”、“谁”、“对哪个位置”、“进行了什么修改”、“修改前信息”、“修改理由”等信息(原稿信息的各部分的修改历史)。

部分完整性信息验证部60从原稿管理部40接受部分完整性信息验证委托，进行针对原稿信息的部分识别信息和部分修改信息的验证。部分完整性信息验证部60包括部分识别信息验证部61和部分修改信息验证部62这两个子要素。

部分识别信息验证部61从原稿管理部40接受部分识别信息验证委托，进行针对原稿信息的部分识别信息的验证。

部分修改信息验证部62从原稿管理部40接受部分修改信息验证委托，进行针对原稿信息的部分修改信息的验证。

流通管理部70从原稿管理部40接受原稿信息的收发委托，进行该原稿信息和部分完整性信息的发送处理及接收处理。流通管理部70包括发送处理部71和接收处理部72这两个子要素。

发送处理部71从原稿管理部40接受原稿信息的发送委托，进行向对象实体发送该原稿信息和部分完整性信息的处理。接收处理部72从原稿管理部40接受原稿信息的接收委托，进行从对象实体发送来的该原稿信息和部分完整性信息的接收处理。

以下把本实施方式分为两个应用领域进行说明。首先，在第1应用领域中，说明与成为本发明的基本概念(独立的基本功能)的“新制作功能”、“修改(部分涂墨)功能”、“验证功能”、“流通功能”、“获取功能”相关的各种作用。在第2应用领域中，以对在第1应用领域中实现的原稿管理方法和验证方法进一步进行改进、改善为目的，特定为XML(eXtensible Markup Language，可扩展标记语言)文件进行说明。此处，着重于XML文件格式的特征之一、即结构化，说明更加高效地实现部分窜改检测的原稿管理方法和验证方法。

首先，按照利用场景说明第1应用领域的基本概念(独立的基本功能)。以下作为本实施方式1的动作示例，说明第1局面和第2局面这两种情况。

[第1局面]

首先，假设以下的利用场景作为第1局面。

作为使用者使用本***的场景，有合同文件的记录/保存。在合同文件中，有时在制作后要进行修改。此时，对修改者和修改位置的确定、修改内容等要求其证明性。之后，利用本***，作为保留了在事后打官司时可以作为证据提交的记录的单元。作为本利用场景的出场人物有两人，进行该合同文件的新制作及修改的“铃木花子小姐”，和进行使用本***的验证的“管理者”。上述两人执行以下处理步骤。

(新制作)

由铃木花子小姐新制作该合同文件，并在本***中进行登记。

(修改)

由于搬迁，铃木花子小姐的住所需要修改，由铃木花子小姐本人将该合同文件中的住所栏中记载的“川崎市中原区”修改为“横浜市港北区”，并在本***中进行登记。

(验证)

在完成修改处理/登记后不久，由管理者进行伴随住所修改的验证(修改位置的确定和修改内容的确认、以及除了修改位置之外没有修改的确认)。

在上述利用场景中，在本***中对铃木花子小姐和管理者提供以下三种功能。

(A)新数据登记功能(在新制作合同文件时使用)

(B)登记数据修改功能(在修改合同文件时使用)

(C)登记数据验证功能(在验证合同文件时使用)

以下，说明上述(A)～(C)的各种情况时的作用。

作为该利用场景的前提条件，使用者90(铃木花子小姐、管理者)已经被事前登记可以使用本电子文件管理***。该利用场景从铃木花子小姐、管理者访问/登录该***开始。并且，对应于该合同文件的规则信息已经在规则保管部31中登记/保管。例如，图3是表示规则信息的内容示例的图。

说明图3所示的规则信息的内容，该规则信息记述有以下控制信息。作为合同文件的必要信息，应该输入“姓名”、“住所”、“出生年月日”，关于“姓名”和“住所”，根据需要可以修改，但“出生年月日”因为其性质是不能修改的。但是，对于“出生年月日”可以实施涂墨。考虑到该规则信息在该***中要在多个实体之间流通，为了提高其安全性，也可以规定为要实施***管理者的签名。

(A)新制作合同文件时

图6是表示新文件登记处理的动作的流程图。在进行该新登记处理时，使用者90(铃木花子小姐)首先选择未图示的画面中的“新文件制作”菜单的“合同文件”，对基于规则信息的已格式化的合同文件进行输入。在确定了输入时，向电子文件管理***10内的请求分析部20发布新文件登记委托。由此开始以下的处理(步骤)。

(1)电子文件管理***10内的请求分析部20接收新文件登记委托(步骤ST-R1)，向原稿处理部41发布新文件登记委托(步骤ST-R2)。

(2)原稿处理部41向登记规则验证部32a发布登记规则验证委托(步骤ST-R3)。

(3)登记规则验证部32a参照在规则保管部31中登记/保管的规则信息，进行文件是否是按照该规则信息而制作的验证，把验证结果返回原稿处理部41(步骤ST-R4)。

(4)原稿处理部41获取来自登记规则验证部32a的验证结果，在验证结果为肯定(OK)时，向部分识别信息生成部51发布生成委托(步骤ST-R5)。在验证结果为否定(NG)时，登出***，并异常结束新文件登记处理。

(5)部分识别信息生成部51生成对应于该文件的部分识别信息，向原稿处理部41返回生成结果(步骤ST-R6)。

图4是表示由部分识别信息生成部51生成的部分识别信息的内容示例的图。此处，示出了以下的状态：例如把随机数“123”与字符串“铃木花子”连接起来，计算相对于字符串“铃木花子123”的哈希信息，作为其生成结果，输出哈希信息“abcdefgh”。以后，对其他要素也进行相同的生成处理。

此处，作为具体示例列举了随机数，其理由是在后面叙述的第2局面中部分地进行涂墨时，使被涂墨前的原有信息不容易被推测出来。在该示例中使用了随机数，但为了该目的，也可以使用随机数以外的方法。

另外，作为该随机数以外的方法，也有使用表示日期时间的时间戳F(time-stamp)的方法。该情况时，F是任意函数，不直接使用时间戳(time-stamp)。这是因为时间戳的情况下，有可能由“年月日时分秒”这种固定格式构成，可容易地被推测出来，为此为了避免该问题。并且，此处在使用时间戳时，也可以同时保证制作日期时间。

(6)原稿处理部41获取来自部分识别信息生成部51的部分识别信息，将该合同文件和部分识别信息登记在原稿保管部42中并保管(步骤ST-R7)。

此时，对合同文件和部分识别信息分别赋予铃木花子小姐的签名。

图5表示登记新文件时的原稿保管部42的状态。所生成的部分识别信息作为为正文的合同文件的管理信息以一体化的形式被保存。在完成以上处理后，进行登出，并正常结束新文件登记处理。

(B)修改合同文件时

图10是表示登记文件修改处理的动作的流程图。在该动作中，首先，当使用者90(铃木花子小姐)选择了未图示的画面中的“登记文件修改”菜单时，显示铃木花子小姐可以处理(可以修改)的“对象登记文件一览”。当铃木花子小姐从画面中的“对象登记文件一览”选择了将要修改的合同文件并确定时，向电子文件管理***10内的请求分析部20发布登记文件获取委托。由此开始以下处理(步骤)。

(1)当发布了登记文件获取委托时，电子文件管理***10内的请求分析部20接收登记文件获取委托(步骤ST-U1)，向原稿处理部41发布登记文件获取委托(步骤ST-U2)。

(2)原稿处理部41取出在原稿保管部42中登记/保管的该文件，并显示于画面中，使铃木花子小姐可以参照(步骤ST-U3)。

此处，当铃木花子小姐把合同文件中的住所栏中记载的“川崎市中原区”修改为“横浜市港北区”并确定时，向电子文件管理***10内的请求分析部20发布登记文件修改委托。

(3)电子文件管理***10内的请求分析部20接收登记文件修改委托(步骤ST-U4)，向原稿处理部41发布登记文件修改委托(步骤ST-U5)。

(4)原稿处理部41向修改规则验证部32b发布修改规则验证委托(步骤ST-U6)。

(5)修改规则验证部32b参照在规则保管部31中登记/保管的规则信息，进行文件是否是按照该规则信息被修改的验证，把验证结果返回原稿处理部41(步骤ST-U7)。另外，该修改规则验证要验证在原稿信息中是否只在规定为可以修改的范围内(不脱离该范围)进行了修改。

图7是表示确定可修改范围/不可修改范围的示例的图，表示在修改了作为可修改范围的“住所”时，验证为肯定(OK)，在修改了作为不可修改范围的“出生年月日”时，验证为否定(NG)的状态。

(6)原稿处理部41获取来自修改规则验证部32b的验证结果，在验证结果为肯定时，向部分识别信息生成部51发布生成委托(步骤ST-U8)。在验证为NG时，进行登出，并异常结束登记文件修改处理。

(7)部分识别信息生成部51生成对应于该文件的部分识别信息，向原稿处理部41返回生成结果(步骤ST-U9)。此处，在生成部分识别信息时，只对从前一版本被修改的“住所”使用新的随机数或者修改处理时的时间戳而生成新的部分识别信息，对“住所”以外(修改位置以外)使用与前一版本相同的随机数或制作时的时间戳而生成部分识别信息。由此，可以证明修改文件(第2版)是原始文件(第1版)的派生文件，而且即使同一人记载相同内容，由于每次生成不同的部分识别信息，所以能够证明已基于纸件方式实现的“笔迹相同”。

(8)然后，原稿处理部41向部分修改信息生成部52发布生成委托(步骤ST-U10)。

(9)部分修改信息生成部52生成对应于该文件的部分修改信息，向原稿处理部41返回生成结果(步骤ST-U11)。例如，图8是表示部分修改信息的内容示例的图。

(10)原稿处理部41从部分识别信息生成部51获取部分识别信息，从部分修改信息生成部52获取部分修改信息，将该已修改的合同文件及部分识别信息和部分修改信息登记在原稿保管部42中进行保管。此时，分别对合同文件及部分识别信息和部分修改信息赋予铃木花子小姐的签名(步骤ST-U12)。

图9表示登记文件修改时的原稿保管部42的状态。如前面所述，参照合同文件的1版和2版，对比住所要素的属性＝R部分(在该示例中使用随机数)，可知1版中R＝“234”、2版中R＝“876”，只有被修改的住所栏使用不同的随机数。并且，可知住所栏之外的随机数，1版、2版均使用相同的值。对比部分识别信息的1版、2版，获得相同结果，这是一目了然的。

在完成以上处理后，进行登出，并正常结束登记文件修改处理。另外，在上述步骤ST-U8～步骤ST-U11的至少任一个过程中，电子文件管理***10也可以显示“修改位置”和“修改内容”，要求使用者90(铃木花子小姐)同意修改。例如，可以讯问“住所已从“川崎市中原区”修改为“横浜市港北区”，可以吗？”等。

(C)有关已修改的合同文件的完整性/正当性验证时

图14是表示登记文件验证处理的动作的流程图。

在该处理中，首先，当使用者90(管理者)选择了未图示的画面中的“登记文件验证”菜单时，显示管理者可以处理(可以验证)的“对象登记文件一览”。当管理者从画面中的“对象登记文件一览”选择了将要验证的合同文件并确定时，向电子文件管理***10内的请求分析部20发布登记文件验证委托。由此开始以下处理(步骤)。

(1)电子文件管理***10内的请求分析部20接收登记文件验证委托(步骤ST-V1)，向原稿处理部41发布登记文件验证委托(步骤ST-V2)。

(2)原稿处理部41取出在原稿保管部42中登记/保管的该验证数据组(步骤ST-V3)。此时，取出的验证数据组如下所示。中括号[]内表示把最新版设为N版时的版本。

(a)合同文件(最新版：2版[N版])

(b)部分识别信息(最新版：2版[N版])

(c)部分识别信息(1版[N-1版])

(d)部分修改信息(最新版：2版[N版])

(3)原稿处理部41向修改规则验证部32b发布修改规则验证委托(步骤ST-V4)。

(4)修改规则验证部32b参照在规则保管部31中登记/保管的规则信息，与在步骤ST-V3获取的部分修改信息(d)进行比较，从而进行文件是否按照该规则信息被正确修改的验证，把验证结果返回原稿处理部41(步骤ST-V5)。

图11是表示规则信息和部分修改信息的比较的图。记载于部分修改信息中的修改内容是有关“住所”的内容，在规则信息中“住所”项目也被记述为可修改范围，所以验证为肯定(OK)。

(5)原稿处理部41获取来自修改规则验证部32b的验证结果。然后，向部分修改信息验证部62发布验证委托(步骤ST-V6)。

(6)部分修改信息验证部62执行以下的验证处理，向原稿处理部41返回验证结果(步骤ST-V7)。

(6-1)参照在步骤ST-V3获取的部分修改信息(d)，确定修改位置和确认部分修改内容。

(7)然后，原稿处理部41向部分识别信息验证部61发布验证委托(步骤ST-V8)。

(8)部分识别信息验证部61执行以下的验证处理，向原稿处理部41返回验证结果(步骤ST-V9)。

(8-1)比较在步骤ST-V3获取的合同文件(a)和部分识别信息(b)，在将该版本的合同文件登记在该***中后，确认没有窜改。图12是表示该比较的状态的图。

(8-2)根据在步骤ST-V7获取的部分修改信息的验证结果(6-1)确定修改位置(“住所”)。比较在步骤ST-V3获取的部分识别信息(b)和(c)中的“住所”的内容，确认已确实修改。另外，确认除了修改位置之外，没有从前一版本被修改的。图13是表示该比较的状态的图。在该示例中，与1版的部分识别信息(c)比较，确认只有住所部分的“67890123”和“qrstuvwx”不同。因此，可以确认除了住所之外，没有从前一版本的1版被修改的。

(9)原稿处理部41汇总在步骤ST-V5、步骤ST-V7、步骤ST-V9获取的验证结果并输出(步骤ST-V10)。

在完成以上处理后，进行登出并正常结束登记文件验证处理。另外，在以上结构中，修改规则验证部32b、部分完整性信息验证部60(部分识别信息验证部61、部分修改信息验证部62)构成本发明的登记文件验证部。

[第2局面]

下面，作为本实施方式的第2局面，假设以下所述的利用场景。

使用本***作为使在A地点制作、修改、并登记的已修改的合同文件流通到B地点的手段。此时，假设“出生年月日”的信息被部分实施涂墨，其他信息以公开的形式提供。作为该利用场景的出场人物有三人，在第1局面中制作合同文件并经过修改进行了登记的“铃木花子小姐”，将该合同文件中的“出生年月日”栏部分涂墨并将其流通到B地点的接收担当人的发送担当人“佐藤太郎先生”，在B地点把从A地点的佐藤太郎先生发送的一份该合同文件登记在本***中的接收担当人“山田稔先生”。“山田稔先生”为了进行官方的第三方证明(例如作为证据提交给法院等)，获取包括从A地点流通来的合同文件的验证数据。假设上述三人进行以下4个处理步骤。

(修改(部分涂墨))

位于A地点的使用者“铃木花子小姐”制作合同文件并登记、修改后，发送担当人“佐藤太郎先生”为了把该合同文件流通到B地点，进行修改处理，并在位于A地点的本***中登记。此处的修改处理，指对前述的出生年月日信息进行部分涂墨处理，其他信息以公开的状态登记。

(流通(发送))

位于A地点的发送担当人“佐藤太郎先生”向B地点的接收担当人“山田稔先生”发送合同文件一份。

(流通(接收))

位于B地点的接收担当人“山田稔先生”接收从A地点的发送担当人“佐藤太郎先生”发送的合同文件一份，并在位于B地点的本***中登记。

(用于第三方证明的取出)

位于B地点的“山田稔先生”为了进行官方的第三方证明(例如作为证据提交给法院等)，取出从A地点流通来的合同文件一份(验证数据)。

图15是图示上述第2局面中的利用场景的图。在图15的利用场景中，在本***中对佐藤太郎先生和山田稔先生提供以下功能。

(B)登记数据修改功能(在对合同文件进行部分涂墨时使用)

(D)登记数据流通(发送)功能(在发送合同文件时使用)

(E)登记数据流通(接收)功能(在接收合同文件时使用)

(F)验证数据获取功能(在作为证据数据提交给法院等时使用)

关于作用(B)，在第1局面的利用场景中已经说明，所以此处省略说明，以下说明上述(D)～(F)的各种情况时的作用。另外，(B)的修改(部分涂墨)时的原稿保管部42的状态如图16所示。已知第3版已被新登记，当比较第2版的部分识别信息和第3版的部分识别信息时，通过对出生年月日进行了部分涂墨处理，从而能够确认只有“出生年月日”和“人物介绍数据”的内容不同。并且，作为本利用场景的前提条件，使用者90(佐藤太郎先生、山田稔先生)已经被事前登记可以利用本电子文件完整性保证***。本利用场景从佐藤太郎先生、山田稔先生访问/登录该***开始。

(D)合同文件的流通(发送)时

图18是表示登记文件流通(发送)处理的动作的流程图。

在该动作中，首先，当使用者90(佐藤太郎先生)选择了未图示的画面中的“登记文件流通(发送)”菜单时，显示佐藤太郎先生可以处理的(可以发送的)“对象登记文件一览”。然后，当佐藤太郎先生从画面中的“对象登记文件一览”选择了将要发送的合同文件并确定时，向电子文件管理***10内的请求分析部20发布登记文件获取委托。由此开始以下处理。

(1)电子文件管理***10内的请求分析部20接收登记文件获取委托(步骤ST-S1)，向原稿处理部41发布登记文件获取委托(步骤ST-S2)。

(2)原稿处理部41获取在原稿保管部42中登记保管的该合同文件一份，在画面上显示合同文件的内容以使佐藤太郎先生能够进行确认。另外，原稿处理部41也取出在规则保管部31中登记保管的该合同文件的规则信息(步骤ST-S3)。

此时，图17表示被取出的一份合同文件。此处应该注意的是合同文件-2版(正文)没有公开。即，合同文件-2版的正文中记载有被涂墨之前的信息。并且，同样在部分涂墨处理中，虽然被共同化为修改处理，但不进行对部分修改信息的“修改前信息”的记载。将除了合同文件-2版(正文)之外的这些信息以一体化的形式发送，从而可以在将涂墨前的内容隐匿的状态下流通到B地点使用，另外也可以进行第三方证明。关于使用了该文件组的第三方证明的方法将在后面叙述。此处，当佐藤太郎先生确认了发送文件的内容并确定时，向电子文件管理***10内的请求分析部20发布登记文件流通(发送)委托。

(3)电子文件管理***10内的请求分析部20接收登记文件流通(发送)委托(步骤ST-S4)，向原稿处理部41发布登记文件流通(发送)委托(步骤ST-S5)。

(4)原稿处理部41执行要发送的该合同文件的验证处理(步骤ST-S6)。此处的验证处理已经在第1局面的利用场景中说明，所以省略。

(5)原稿处理部41获取要发送的该合同文件的验证结果，在验证为肯定(OK)时，向发送处理部71发布发送委托(步骤ST-S7)。在验证为否定(NG)时，进行登出，并异常结束登记文件流通(发送)处理。

(6)发送处理部71向地点B的电子文件管理***发送该合同文件一份，向原稿处理部41返回发送结果(步骤ST-S8)。

在完成以上处理后，进行登出并正常结束登记文件流通(发送)处理。

(E)接收合同文件时

图19是表示等待登记的文件的接收处理动作的流程图。

在进行该处理时，首先，当使用者90(山田稔先生)选择了未图示的画面中的“等待登记文件的接收”菜单时，显示山田稔先生可以处理的(可以接收的)“对象等待登记文件一览”。当山田稔先生从画面中的“对象等待登记文件一览”选择了要接收的合同文件并确定时，向电子文件管理***10内的请求分析部20发布等待登记文件接收委托。由此开始以下处理(步骤)。

(1)电子文件管理***10内的请求分析部20接收等待登记文件接收委托(步骤ST-T1)，向原稿处理部41发布等待登记文件接收委托(步骤ST-T2)。

(2)原稿处理部41向接收处理部72发布等待登记文件接收委托。

(3)接收处理部72在本***接收该合同文件一份，向原稿处理部41返回所接收的该合同文件一份(步骤ST-T3)。

(4)原稿处理部41执行从接收处理部72获取的该合同文件的验证处理(步骤ST-T4)。此处的验证处理在第1局面的利用场景中已经说明，所以省略。

(5)原稿处理部41获取接收的该合同文件的验证结果，在验证为肯定(OK)时，向规则保管部31登记该规则信息并保管，向原稿保管部42登记该合同文件一份并保管(步骤ST-T5)。在验证为否定(NG)时，进行登出，并异常结束等待登记文件接收处理。

在完成以上处理后，进行登出，并正常结束等待登记文件接收处理。

(F)获取合同文件时

图20是表示登记文件获取处理的动作的流程图。

在进行该处理时，首先，当使用者90(山田稔先生)选择了未图示的画面中的“登记文件获取”菜单时，显示山田稔先生可以处理的(可以获取的)“对象登记文件一览”。当山田稔先生从画面中的“对象登记文件一览”选择了要获取的合同文件并确定时，向电子文件管理***10内的请求分析部20发布登记文件获取委托。由此开始以下处理(步骤)。

(1)电子文件管理***10内的请求分析部20接收登记文件获取委托(步骤ST-G1)，并向原稿处理部41发布登记文件获取委托(步骤ST-G2)。

(2)原稿处理部41获取在原稿保管部42中登记/保管的该文件。另外，原稿处理部41也取出在规则保管部31中登记/保管的该合同文件的规则信息(步骤ST-G3)。

在完成以上处理后，进行登出，并正常结束登记文件获取处理。

通过本获取处理，取出的验证数据组如图17所示。以下，说明在把该验证数据组作为证据提交给法院等时，在本利用场景中可以进行怎样的第三方证明。

首先，在图21中，通过比较合同文件-3版(D3)和部分识别信息-2版(S2)和部分识别信息-3版(S3)，可以进行以下的第三方证明。

证明1：可以确认合同文件-3版(D3)是从铃木花子小姐自己签名的合同文件而制作的。

证明2：可以确认由铃木花子小姐记述的内容没有被窜改。

证明3：可以确认相比前一版本只有“出生年月日”栏被变更。同时，可以确认相比前一版本除了“出生年月日”栏之外没有变更。

(证明1～3的验证方法)

参照部分识别信息-2版(S2)和部分识别信息-3版(S3)，部分识别信息-2版(S2)中的出生年月日的哈希值为“yz012345”，部分识别信息-3版(S3)中的出生年月日的哈希值为“qwertyui”，出生年月日彼此不同。随之，人物介绍数据也不同，但与除此之外的其他项目有关的哈希值全部相同。

由此，可以确认第3版与第2版相比仅“出生年月日”和“人物介绍数据”栏被变更。同时，可以确认除了“出生年月日”和“人物介绍数据”栏之外没有变更。另外，部分识别信息-第2版(S2)和部分识别信息-第3版(S3)分别被赋予了铃木花子小姐和佐藤太郎先生的签名，也可以进行验证。因此，可以证实证明3。并且，通过上述比较，由于变更位置之外确实有铃木花子小姐的签名，所以可以证实证明1、2。

另外，在本实施方式中，部分识别信息中包括“人物介绍数据”，但如果不包含有关该“人物介绍数据”的部分识别信息，则视为仅“出生年月日”的部分识别信息不同。

下面，在图22中通过比较合同文件-3版(D3)和部分识别信息-3版(S3)，可以进行以下的第三方证明。

证明4：可以确认合同文件-3版(D3)的内容在登记到本***中后没有被窜改。

(证明4的验证方法)

从合同文件-3版(D3)再次生成部分识别信息，并与部分识别信息-3版(S3)进行比较，由此可以证实证明4。具体地讲，例如从合同文件-3版(D3)中的姓名要素中，将字符串“铃木花子”和字符串“123”连接起来，根据字符串“铃木花子123”生成哈希值。从部分识别信息-3版(S3)中的姓名中取出“abcdefgh”，并与所生成的哈希值相比较，判定是否相同。以后，对姓要素名之外的要素也进行相同的处理及比较，在确认了全部相同时，可以确认在合同文件-3版(D3)登记到本***中后没有被窜改。因此，可以证实证明4。

另外，在图23中通过比较合同文件-3版(D3)和部分修改信息-3版(T3)，可以进行以下的第三方证明。

证明5：通过确认部分修改信息-3版(T3)，可以确认合同文件-3版(D3)是在与前一版本相比“出生年月日”被部分涂墨的状态下发送来的。另外，也可以证明修改(部分涂墨)的日期时间、以及修改者是“佐藤太郎先生”。

(证明5的验证方法)

通过参照带有佐藤太郎先生签名的部分修改信息-3版(T3)中的修改日期时间、修改者、修改位置、修改代码、修改理由，可以证实证明5。

实施方式2

下面，作为本发明的实施方式2，说明在第2应用领域的利用场景。如上所述，此处说明用于检测被特定为XML文件的部分窜改的原稿管理方法和验证方法。

首先，在本利用场景中，作为在申请人和保险公司和金融机构三者之间流通的电子数据，考虑采用“保险合同申请书”，进行本数据的处理的“保险合同申请服务”。图24表示本***模型的形式。上述三者通过访问通过上述结构而被提供、运营的“保险合同申请服务”(专用Web服务器/ASP)，可以利用本***。作为前提，假定该“保险合同申请服务”由可靠的第三方机构运营，通过本机构流通。

此处，假定以下场面，申请人(铃木花子小姐)利用在因特网上设置/提供的本***，进行保险合同申请，保险公司受理，金融机构进行该合同的结算处理。文件的流程如以下步骤(1)～(5)所示。另外，作为事前准备，假设三者已经在“保险合同申请服务”中进行了用户登记，以便申请人(铃木花子小姐)、保险公司担当人、金融机构担当人可以利用。

(1)申请人(铃木花子小姐)从Web浏览器登录“保险合同申请服务”(此时，作为本人确认的方法，考虑ID+密码的组合、生物体验证等)，并把保险合同申请书作为第1版进行新制作/登记，并存储在设于本***内的原稿保管装置(原稿保管部42)中。通过进行确定/发送，申请书数据(第1版)被发送给保险公司(图24中的S1部分)。

(2)保险公司担当人例如通过使用电子邮件的接收来确认等的某种手段(也可以为了定期确认而访问本***)，从本***获取来自申请人(铃木花子小姐)的保险合同申请书(第1版)，并确认内容进行验证。

(3)保险公司担当人为了进行伴随保险合同的结算处理，向金融机构发送授予信用(与信)信息。作为其前期准备，对于金融机构而言授予信用信息中不需要的信息(例如保险产品(course)等的合同信息)被部分实施隐匿(涂墨)处理，把保险合同申请书作为第2版进行更新/登记，并存储在设于本***内的原稿保管装置(原稿保管部42)中。通过进行确定/发送，申请书数据(第2版)被发送给金融机构(图24中的S2部分)。

(4)然后，金融机构担当人使用电子邮件的接收等与上面所述相同的手段(与上述保险公司担当人相同的手段)，从本***获取来自保险公司的保险合同申请书(第2版)，并确认内容进行验证。

(5)金融机构担当人向保险公司发送伴随申请人(铃木花子小姐)的保险合同的结算处理结果。作为其前期准备，金融机构担当人追加授予信用确认信息，把保险合同申请书作为第3版进行更新/登记，并存储在设于本***内的原稿保管装置(原稿保管部42)中。通过进行确定/发送，申请书数据(第3版)被发送给保险公司(图24中的S3部分)。

以下，说明在上述各个步骤(1)～(5)的过程中，保险合同申请书在原稿保管装置内(原稿保管部42)中如何被进行原稿管理、并且在各个时间点进行怎样的验证，从而可以向第三方证明什么样的内容。另外，关于本***通过哪种手段、功能发挥作用，由于已经在实施方式1中说明的第1应用领域的利用场景中具体说明，所以此处省略说明。

(1)制作保险合同申请书(第1版)

图25表示在该步骤中新制作的保险合同申请书(XML数据)的示例。在实施方式1中说明的第1应用领域中已经说明基本概念，所以把具有非分层结构的(母要素为一个，其下并列多个子要素的方式)极其简单的XML数据(参照图5)作为示例。关于本应用领域的保险合同申请书，把具有图25所示的复杂的分层结构的XML数据作为对象。图25表示利用XML数据来表现保险合同申请书(第1版)的正文的示例。

在图25所示的XML数据示例中，把<保险合同申请书>作为根要素，在其下配置有<合同人>、<指定存款户头>、<合同信息>三个母要素。在各个母要素属下分别配置有子要素。如果将本XML数据树模型化，则如图26所示。图26是表示保险合同申请书(第1版)的XML数据模型的图。该保险合同申请书可以说是具有树结构的一种分层结构式文件。

下面，说明针对本保险合同申请书数据的部分识别信息的生成方法。图27表示制作保险合同申请书(第1版)时所生成的部分识别信息的XML数据的表现例。

如图27所示，关于第1版(初版)，对所有子要素生成哈希信息并记录，同时也生成母要素(该示例中相当于<保险合同申请书>、<合同人>、<指定存款户头>、<合同信息>、<姓名>)的哈希信息并记录。

这在考虑到下次(第2版)及之后产生的文件更新时，在没有变更的母和子的集合组、例如图28所示，{<姓>、<名>(母要素均为<姓名>)、<住所>、<电话号码>}都没有产生变更的情况下，也可以只记录其母要素即<合同人>的哈希信息(＝“7ed6c”)。图28是表示提取了“合同人”的XML数据模型的图。因此，如果进行这种记录管理，则事后只对<合同人>的哈希信息来验证完整性即可，可以省略{<姓>、<名>(母要素均为<姓名>)、<住所>、<电话号码>}合计5个的验证。

因此，在下一次(第2版)的验证时，与保存并管理{<姓>、<名>、<姓名>、<住所>、<电话号码>}的所有验证数据相比，实现了数据量和验证成本的削减。并且，本示例假设不存在同一要素名，但假设出现同一要素名时，当然需要使用Xpath功能等来识别并管理对应要素的哈希信息的机制。

(2)保险合同申请书(第1版)的获取/验证

图29表示制作保险合同申请书(第1版)时的原稿保管状态。如图29所示，保险公司担当人获取第1版的保险合同申请书(正文)和部分识别信息，并进行验证。此时，通过使用该验证数据组，可以确认是否是申请人(铃木花子小姐)制作的、申请书本身有无被窜改。另外，关于有关第1版的具体验证方法，在实施方式1的第1应用领域中已经说明了作用，所以此处省略说明。

(3)制作保险合同申请书(第2版)

第2版的制作是由保险公司担当人以申请人(铃木花子小姐)制作的保险合同申请书(第1版)为基础来进行更新。作为更新作业，进行合同人信息的部分隐匿(涂墨)。图30表示被更新的保险合同申请书(第2版)的正文的基于XML数据的表现例。

图30中的TZ部分表示此次变更的位置。此时，赋予给该正文的电子签名当然是保险公司的签名，而不是申请人(铃木花子小姐)的签名。这通过利用普通的电子签名方式，保证了该文件是由谁制作的(本人性)、及事后文件本身没有被窜改(非窜改性)。

本发明的实施方式的特征在于，针对整个文件的验证通过使用普通的电子签名方式来确保安全性，对文件中的部分保证，通过生成部分识别信息，并与正文相独立地管理，由此对“谁”“哪个部分”“如何变更了”明确了责任范围。

如图30中的TZ部分所示，被变更的是<保险产品>和<保险金额>，其内容利用星号(*****)来表现，可以知道是部分隐匿(涂墨)的状态。当然，如在实施方式1的第1应用领域中说明的那样，对于变更位置{<保险产品>、<保险金额>(母要素均为<合同信息>)}，可知R属性部分被变更。

同样，对于<合同信息>的母要素、且作为本XML数据的根要素的<保险合同申请书>，R属性也被变更。关于在文件中赋予R属性、并且对变更位置改变R属性的理由，已经在上述的第1应用领域中具体说明，所以此处省略说明。

下面，说明针对本保险合同申请书数据的部分识别信息的生成方法。图31表示制作保险合同申请书(第2版)时所生成的部分识别信息的基于XML数据的表现例。

如图31所示，对于第2版及第2版以后，按照以下手法生成部分识别信息。

首先，在该示例中，作为母要素的<合同人>和<指定存款户头>没有变更。这意味着自必然<合同人>和<指定存款户头>两者属下的子要素全部没有变更。因此，在第2版的部分识别信息中如前面所述，只记录有母要素<合同人>和<指定存款户头>的哈希信息(图31中的V2-1部分)。对于该部分，也可以从第1版的部分识别信息复制该部分，也可以再次从第2版的保险合同申请书正文生成该部分的哈希信息。

但是，从可以削减该信息的生成成本方面考虑，当然选择基于前者方法的记录时更加合适。

然后，由于此次<保险产品>和<保险金额>有变更，所以对母要素的哈希信息造成影响。这就是作为该母要素的<合同信息>和<保险合同申请书>。此处，进行这些母要素的哈希信息的再生成并记录(图31中的V2-2部分)。该部分是考虑到在下次更新(第3版)时该位置没有变更的情况下使用而记录的。

由此，在下次及下次以后的更新中，也可以削减针对非变更位置的哈希信息的生成成本。并且，<保险合同申请书>相当于所谓的根要素。作为根要素的特征，当在其属下的母要素/子要素哪怕只有一个变更时，根要素(<保险合同申请书>)的哈希信息也发生变更。此处，为了进一步提高验证质量，通过具有根要素(<保险合同申请书>)的哈希信息来进行记录，可以在事后容易确认该信息没有被窜改。

但是，由于也可以根据赋予给整个文件的电子签名进行相同的验证，所以关于根要素(<保险合同申请书>)的哈希信息，未必一定需要记录。并且，当然针对此次发生变更的<保险产品>和<保险金额>的哈希信息的再生成、记录，为了便于事后确定部分变更位置因而是必要的(图31中的V2-3部分)。

图32表示制作保险合同申请书(第2版)时的原稿保管状态。图32中，T1部分表示变更位置，T2部分表示此次没有变更的位置(子要素)。此处，可知针对该子要素的哈希信息未被记录，而记录了母要素<合同人>和<指定存款户头>的哈希信息。

另外，在第2应用领域的利用场景中，关于部分修改信息的生成、记录的说明，由于没有直接关系，所以没有特别提及。关于部分修改信息的生成、记录，在第1应用领域的利用场景中已经具体说明，所以希望参照那些说明。

(4)保险合同申请书(第2版)的获取/验证

如图32所示，金融机构担当人获取的是第2版的保险合同申请书(正文)和部分识别信息、第1版的部分识别信息。此时，很容易推测出第1版的保险合同申请书(正文)不能被获取、浏览。因为第1版的保险合同申请书(正文)包含了部分被隐匿(涂墨)前的<保险产品>和<保险金额>的内容，如果提示该内容，将泄露信息。因此，除了基于版本管理的原稿管理方法外，当然需要能够根据各个时间点(版本)的文件内容对可浏览者和不可浏览者进行访问控制的机制。

其中，该要件可以在本利用场景的特征之一即ASP内对流通数据进行一元管理的情况下应用，可以适当地在利用电子邮件等直接发送数据的方式中，单纯选择并限定发送数据即可。

可知在上述条件的基础下，金融机构担当人可浏览的验证数据组是“保险合同申请书(第2版)-正文”、“部分识别信息(第1版)”、“部分识别信息(第2版)”。图33表示其内容。图33是表示金融机构担当人可以浏览的验证数据组的图。

可以使用图33所示的验证数据组进行以下的验证。首先，验证各个验证数据的电子签名，进行各个验证数据本身有没有被窜改的确认及验证。

在确认了各个验证数据没有被窜改时，接着使用保险合同申请书(第2版)和部分识别信息(2版)，确认保险合同申请书(第2版)的内容本身，并且确认是否被部分替换。作为其手段，首先从保险合同申请书(第2版)的各个要素部分生成哈希信息，并与记录在部分识别信息(2版)中的该部分的哈希信息进行比较，判定是否相同。

当可以确认所有要素部分的完整性时，接着进行与前一版本的部分识别信息(第1版)的比较。作为其手段，首先由于OD1部分没有变更，所以对应的哈希信息成为仅是利用VD1-2部分表示的母要素的记录。由此，如果比较部分识别信息(1版)的对应哈希信息(VD1-1)和部分识别信息(2版)的对应哈希信息(VD1-2)，可以确认该位置没有变更。

在该示例中，可以确认<合同人>的哈希信息均为“7ed6c”，<指定存款户头>的哈希信息均为“8c320”，没有变更。因此，如果完成了一次作为母要素的<合同人>的验证，则可以省略<合同人>的子要素即{<姓>、<名>(母要素均为<姓名>)、<住所>、<电话号码>}的5个位置(不包括母要素<姓名>的验证时为4个位置)的验证。

同样，如果完成了一次作为母要素的<指定存款户头>的验证，则可以省略<指定存款户头>的子要素即{<金融机构名称>、<户头帐号>、<户头名义人>}的3个位置的验证。由此，通过两次该母要素的验证，可以满足合计8次的验证，在该示例中，可以说能够削减75％的验证成本。并且，该8个要素部分的哈希信息的记录通过两个要素部分的记录即可，所以可以说数据量同样也能够削减75％。

相反，关于OD2部分，由于与前一版本相比有变更，所以对应的哈希信息如VD2-2部分所示，子要素也被记录。由此，如果对部分识别信息(1版)的对应哈希信息(VD2-1)和部分识别信息(2版)的对应哈希信息(VD2-2)进行比较，则可以确认该位置被变更。

在该示例中，<保险产品>的哈希信息在1版中为“abfd3”、在2版中为“d2419”，1版和2版不同，<保险金额>的哈希信息在1版中为“623al”、在2版中为“f56da”，也不同，所以可以确认该位置被变更。

(5)制作保险合同申请书(第3版)

第3版的制作由金融机构担当人以保险公司担当人制作的保险合同申请书(第2版)为基础进行更新。作为更新作业，进行授予信用确认信息的追加。

图34表示被更新的保险合同申请书(第3版)的正文的基于XML数据的表现示例。图34中的KZ部分表示此次被追加的位置。同样，此时赋予给该正文的电子签名不是保险公司担当人的签名，而是金融机构担当人的签名。

如图34中的KZ部分所示，所追加的是<授予信用结果>和<授予信用NO>。

下面，说明针对本保险合同申请书数据的部分识别信息的生成方法。图35表示制作保险合同申请书(第3版)时生成的部分识别信息的基于XML数据的表现示例。

如图35所示，与第2版相同，在第3版中也按照以下的方法生成部分识别信息。

首先，在本示例中，作为母要素的<合同人>、<指定存款户头>、<合同信息>没有变更。这意味着<合同人>和<指定存款户头>、<合同信息>各自属下的子要素必然全部没有变更。因此，在第3版的部分识别信息中如前面所述，只记录有母要素<合同人>、<指定存款户头>、<合同信息>的哈希信息(图35中的V3-1部分)。

在前次(第2版)的更新中，<合同信息>属下的子要素<保险产品>和<保险金额>被变更，但此次没有变更。此处，由于在前次第2版生成的部分识别信息中记录了第2版时的<合同信息>的哈希信息，因此可以容易地推测出能够在生成第3版时有效运用。这意味着实现了在生成第2版的部分识别信息时所预测的“也能够削减在下次及下次以后的更新中针对非变更位置的哈希信息的生成成本”。

鉴于此，此次通过追加<授予信用结果>和<授予信用NO>，也记录了作为其母要素的<金融授予信用信息>的哈希信息(图35中的V3-2部分)。这是考虑到在下次更新(第4版)时该变更位置没有变更的情况下可以利用。

并且，伴随该追加，必然再次生成作为根要素的<保险合同申请书>并记录(图35中的V3-2部分)。另外，也生成针对此次追加的<授予信用结果>和<授予信用NO>的哈希信息并记录，这当然是为了事后确定部分变更位置所需要的(图35中的V3-3部分)。

图36表示制作保险合同申请书(第3版)时的原稿保管状态的图。图36中，K1部分表示此次追加的位置，K2部分表示此次没有变更的位置(子要素)。此处，可知针对该子要素的哈希信息未被记录，而只记录了母要素的<合同信息>的哈希信息。

在以上说明中，在步骤(1)～(5)的各个步骤中，说明了保险合同申请书在原稿保管装置内(原稿保管部42)中是怎样被进行原稿管理的、在各个时间点进行怎样的验证，从而可以向第三方证明什么样的内容。这样，如果执行在步骤(1)～(5)所示的文件制作时/更新时的部分识别信息的生成方法、原稿管理方法、验证方法，则可以容易地实现具有复杂的分层结构的XML数据的部分窜改检测功能。因此，与即使更新时没有变更的位置也对子要素进行全部管理的方式相比，可以预料验证成本的飞跃性削减，传送、保存数据量也可以大幅削减。

并且，在即使更新时没有变更的位置也对子要素进行全部管理的方式中，只能用于对一部分版本的验证。例如，在为了向第三方委托证明而提示第3版时，只能验证与其最前面的最后一个版本(第2版)的不同。当然，也可以验证与第1版相比的变更点，但是需要提示包括所有要素的部分识别信息，传送、保存数据量也相应地增大，验证处理也需要时间。

与此相对，如果利用具有复杂的分层结构的XML数据的部分窜改检测功能，则能够以最小限度的内容来记录并管理验证所需要的部分识别信息，把第1版的部分识别信息作为原始内容(基础)，能够以最小限度的传送、保存数据量使第2版、第3版…第N版的组合流通并进行验证。由此，能够容易地且低成本地在各个实体(地点)对所有版本的修改情况的历史管理进行验证。

另外，可以进行关于“什么时候、谁、在哪个时间点、哪个部分、如何修改了”的历史跟踪及证明，这方面的优点也是很大的。

并且，在图36中的第3版时的保险合同申请书的保管状态的示例中，各版本的部分识别信息分别作为不同的文件被管理，但是，作为在多个实体之间携带验证数据组进行辗转、在各个地点进行历史跟踪及证明的更加高效的手段，还有将各版本的部分识别信息连接起来，汇总为一个文件的方法。

这样被连接起来管理的部分识别信息需要能够确保版本的时间序列性，而且能够识别各个版本的制作者(本人性)。并且，作为这种连接管理的方法，还有使用Xlink功能来实现的方法。

图37、图38表示作为一个文件被连接管理的状态。图37表示将验证第2版时需要的所有部分识别信息连接起来管理的状态，图38表示将验证第3版时需要的所有部分识别信息连接起来管理的状态。

各版本的部分识别信息分别被实施了制作者的电子签名。作为提供电子签名的方法，如果使用XML部分签名等可容易地实现。在本利用场景中，第1版由申请人(铃木花子小姐)提供电子签名，第2版由保险公司担当人提供电子签名，第3版由金融机构担当人提供电子签名。因此，能够容易地验证各个部分识别信息的制作者的本人性、及数据本身的完整性。

通过对比图37和图38可知，例如即使保险合同申请书的正文被覆盖，如果以部分识别信息的形式进行历史管理，则也可以对部分修改位置及其修改内容进行第三方证明。换言之，部分识别信息的内容可以说是各版本的快照。如果以这种形式携带验证数据组在多个实体之间辗转，则可以防止被部分隐匿的信息的泄露，而且容易在各个地点实现部分位置的历史跟踪及证明。

在以上的利用场景中，说明了对与前一版本相比被修改的位置，记录子要素及其所属的母要素，对属于母要素的所有子要素中没有修改的位置，只记录该母要素的方式(以后定义为方式1)。

另外，与方式1相比，以削减传送、保存数据量为目的，还有以下方式，只对与前一版本相比被修改的位置记录子要素及其所属的母要素，即所谓的纯粹只管理差异部分的方式。下面，说明这种只管理差异部分的方式(以后定义为方式2)。

根据方式1的手段，保险合同申请书(第2版)-正文(图30)的部分识别信息的管理方法如图31所示。另一方面，如果使用方式2记录，则如图39所示。图39是表示使用方式2、利用XML数据来表现部分识别信息(第2版)的示例的图。

如图39所示，在方式1中，非变更位置的<合同人>和<指定存款户头>被记录，但在本次的方式中，该部分被省略，传送、保存数据量与方式1相比可以进一步削减。

图40表示制作使用了方式2的保险合同申请书(第3版)时的原稿保管状态的图。

下面，对前面说明的与部分识别信息的生成有关的以下三种方式的传送、保存数据量和验证处理，进行成本评价及分析。此处，方式0为在第1应用领域的利用场景中说明的方式。

方式0(比较对象)是记录变更位置及非变更位置全部位置的哈希信息的方式。方式1是对与前一版本相比被修改的位置记录子要素及其所属的母要素，对属于母要素的所有子要素中没有修改的位置只记录该母要素的方式(在第2应用领域的利用场景示例中采用)。方式2是只对与前一版本相比被修改的位置记录子要素及其所属的母要素的、所谓纯粹只管理差异部分的方式。

此处，使用图41所示的简单的XML数据示例进行分析。图41是表示评价分析用的XML数据示例的图。

在本评价分析中，作为更新到第2版的更新作业，只考虑<保险产品>的修改。图42表示<保险产品>的内容被从“AAA”修改为“BBB”的状态。即，图42是表示评价分析用的XML数据的更新的图。

首先，对比较对象(方式0)进行传送、保存数据量和验证次数的分析。图43表示方式0的数据管理方法和验证处理的状态。即，图43是表示基于方式0的部分识别信息的生成和验证的图。在验证A1中，使用保险合同申请书(第2版)和部分识别信息(2版)，确认保险合同申请书(第2版)的内容本身是否被部分地替换。作为其手段，首先从保险合同申请书(第2版)的各个要素部分生成哈希信息，并与记录在部分识别信息(2版)中的该部分的哈希信息进行比较，判定是否相同。

在验证A2中，通过进行前一版本的部分识别信息(第1版)和部分识别信息(2版)的比较，进行变更位置的确定和变更位置之外没有改变的确认。

将本方式0的传送、保存数据量和验证次数总结如下。首先，若把部分识别信息(第2版)的传送、保存数据量单纯地利用行数来表现，则为7行。

在该方式中，由于记录变更位置和非变更位置所有位置的哈希信息，所以第1版、第2版的数据量均为7行。另外，在该示例中，<部分识别信息>是该文件的根要素，所以没有计数。其次，在验证次数中，首先在验证A1的步骤中进行7次验证，在验证A2的步骤中同样进行7次验证，所以需要7次+7次＝合计14次的验证成本。

下面，进行对方式1进行传送、保存数据量和验证次数的分析。图44表示方式1的数据管理方法和验证处理的状态。即，图44是表示基于方式1的部分识别信息的生成和验证的图。

同样，将本方式1的传送、保存数据量和验证次数总结如下。首先，部分识别信息(第2版)的传送、保存数据量为3行。在该方式中，对与前一版本相比被修改的位置记录子要素及其所属的母要素，对属于母要素的所有子要素中没有修改的位置只记录该母要素，所以与方式0相比，第1版和第2版在数据量上均出现差异。

其次，在验证次数中，首先在验证B1的步骤中进行3次验证，在验证B2的步骤中同样进行3次验证，所以需要3次+3次＝合计6次的验证成本。即，对于<姓名>、<姓>、<名>、<住所>4个位置，由于通过作为它们的母要素的<合同人>的1次验证便已经满足，所以可以省略这4个位置的验证。

下面，对方式2进行传送、保存数据量和验证次数的分析。图45表示方式2的数据管理方法和验证处理的状态。即，图45是表示基于方式2的部分识别信息的生成和验证的图。

同样，将本方式2的传送、保存数据量和验证次数总结如下。首先，部分识别信息(第2版)的传送、保存数据量为2行。在本方式中，只对与前一版本相比被修改的位置记录子要素及其所属的母要素，所以与方式1相同，第1版和第2版在数据量上均出现差异。

其次，在验证次数中，首先在验证C1的步骤中进行2次验证，在验证C2的步骤中同样进行2次验证，所以需要合计4次的验证成本。

在本方式中，只记录修改位置，所以对位于非修改位置的<合同人>、<姓名>、<姓>、<名>、<住所>，不能进行与前一版本相比没有变化的验证。因为虽然在验证C1中使用保险合同申请书(第2版)和部分识别信息(2版)，来确认保险合同申请书(第2版)的内容本身是否被部分地替换，但由于最优先考虑传送、保存数据量，所以不具有对该位置进行验证的材料。

因此，必须从保险合同申请书(第2版)生成该位置的哈希信息，进行前一版本的部分识别信息(第1版)的该位置和验证。在图45中该验证在验证C3的步骤中进行，在验证C3的步骤中需要5次的验证成本。因此，该方式的验证成本为将验证C1～C3累计共2次+2次+5次＝9次。

把上述方式0的分析结果作为对象，比较方式1和方式2。图46表示各方式的分析结果。从本分析结果可知，方式1、方式2与比较对象(方式0)相比，传送、保存数据量及验证处理均削减，可以说部分识别信息的生成及管理采用方式1或方式2比较好。另外，在方式1和方式2的比较中，方式2的传送、保存数据量比方式1少，但相应地验证处理需要时间。与此相比，可知在方式1中，传送、保存数据量及验证处理均可以保持良好的平衡，可削减成本。

该结果并不是说方式1、方式2中的哪种方式更好，而是应该根据文件分层结构的程度来选择最佳方式。

图47表示各方式的分析结果的泡泡图。

以上，根据本发明的实施方式，可以满足通过现有技术及现有技术的简单组合不能实现的下述要件。(1)可以确定电子文件的修改位置，并且可以确认修改位置之外没有被变更。(2)当使已修改的电子文件在多个实体之间辗转流通，并且在各个实体中进行修改及追加等的情况下，可以在各个时间点保证(第三方证明)电子文件的完整性及原稿性。(3)即使不取出在本***内保存管理的所有版本的电子文件，也能够进行被部分涂墨的状态和只使用了部分版本的第三方证明和流通。

以上对本发明的实施方式，作为文件信息以合同文件等的原稿信息的管理为例进行了说明，但本发明也可以广泛应用于与文件有关的历史的正当性证明、验证等。并且，对于规则信息，在登记验证时和修改验证时使用了相同的规则信息，但当然也可以分别准备不同的规则信息。

另外，通过提供利用计算机来执行图示的流程图和步骤所示的各个动作的程序，可以提供本发明的电子文件管理程序。这些程序可以记录在计算机可读的介质中并由计算机执行。此处，作为计算机可读的介质，包括CD-ROM和软盘、DVD盘、光磁盘、IC卡等可移动型存储介质，和保存计算机程序的数据库、或者其他计算机及其数据库、以及线路上的传输介质。

根据本发明，可以发挥能够满足通过现有技术及其现有技术的单纯组合不能实现的下述要件的效果。

(1)可以确定电子文件的修改位置，并且可以确认修改位置之外没有被变更。

(2)当使已修改的电子文件在多个实体之间辗转流通，并且在各个实体中进行修改及追加等的情况下，可以在各个时间点保证(第三方证明)电子文件的完整性及原稿性。

(3)即使不取出在本***内保存管理的所有版本的电子文件，也能够进行被部分涂墨的状态和只使用了部分版本的第三方证明和流通。

Claims

1.一种电子文件管理***，该电子文件管理***对利用电子信息而制作的文件信息进行管理，其特征在于，该电子文件管理***具有：

规则信息保管部，其保管预先规定的规则信息；

部分识别信息生成部，其生成以能够识别的方式表示文件信息的各部分的部分识别信息；

部分修改信息生成部，其在所述文件信息的各部分有修改指示时，生成与被修改的部分的修改历史相关的信息、即部分修改信息；

管理部，其把所述文件信息、由所述部分识别信息生成部生成的部分识别信息、由所述部分修改信息生成部生成的部分修改信息、和所述规定的保管在规则信息保管部中的规则信息关联起来进行管理；以及

登记文件验证部，其使用通过所述管理部而被关联起来的部分识别信息、部分修改信息，来验证文件信息的正当性。

2.根据权利要求1所述的电子文件管理***，其特征在于，所述部分识别信息生成部将文件信息划分为多个部分，根据各部分的信息生成所述部分识别信息。

3.根据权利要求2所述的电子文件管理***，其特征在于，所述部分识别信息生成部使用哈希函数来生成所述部分识别信息。

4.根据权利要求1所述的电子文件管理***，其特征在于，所述部分识别信息生成部在文件信息被修改时，仅针对从前一版本被修改的位置而生成新的部分识别信息。

5.根据权利要求1所述的电子文件管理***，其特征在于，文件信息、部分识别信息和部分修改信息被分别赋予了签名。

6.根据权利要求1所述的电子文件管理***，其特征在于，该电子文件管理***具有登记规则验证部，该登记规则验证部在所述文件信息被进行了修改时，使用规则信息来验证是否在可修改范围内进行了修改。

7.根据权利要求1所述的电子文件管理***，其特征在于，由所述管理部管理的所述信息由具有分层的文件结构的XML数据构成。

8.根据权利要求7所述的电子文件管理***，其特征在于，所述部分识别信息生成部按照所述文件信息的各部分的修改指示，在具有分层的文件结构的XML数据的修改中，把从前一版本被修改的位置、以及未被修改的位置的所有母要素、子要素作为对象，来生成部分识别信息。

9.根据权利要求8所述的电子文件管理***，其特征在于，所述部分识别信息生成部只针对从前一版本被修改的位置，把子要素及其所属的母要素作为对象来生成部分识别信息，所述管理部只对与前一版本相比的差异部分的部分识别信息进行管理。

10.根据权利要求1所述的电子文件管理***，其特征在于，所述管理部把所有电子信息作为对应于版本的原稿信息来处理，并且对于被实施版本管理的原稿信息的内容，根据各个版本的原稿信息的内容能够识别可浏览者和不可浏览者。

11.一种电子文件管理方法，该电子文件管理方法进行由计算机利用电子信息而制作的文件信息的管理处理，其特征在于，该电子文件管理方法执行以下步骤：

登记请求接收步骤，该登记请求接收步骤接收所述计算机制作的文件信息的登记请求；

登记规则验证步骤，该登记规则验证步骤参照预先保管有规则信息的规则保管部的信息，验证在所述登记请求接收步骤接收的文件信息是否符合规定的规则信息；

部分识别信息生成步骤，该部分识别信息生成步骤在通过所述登记规则验证步骤的验证，认为所述文件信息符合规定的规则信息时，生成以可识别的方式表示所述文件信息的各部分的部分识别信息；以及

登记步骤，该登记步骤把所述文件信息、所述部分识别信息和所述规则信息关联起来进行登记。

12.一种电子文件管理方法，该电子文件管理方法进行由计算机利用电子信息而制作的文件信息的管理处理，其特征在于，该电子文件管理方法执行以下步骤：

修改请求接收步骤，该修改请求接收步骤接收关于所述计算机对管理对象的文件信息进行了修改的文件信息的修改请求；

修改规则验证步骤，该修改规则验证步骤验证在所述修改请求接收步骤接收的文件信息是否符合在规则信息保管部中保管的规则信息；

部分识别信息生成步骤，该部分识别信息生成步骤在通过所述修改规则验证步骤认为所述文件信息符合所述规则信息时，生成以可识别的方式表示所述被修改的文件信息的各部分的部分识别信息；

部分修改信息生成步骤，该部分修改信息生成步骤在通过修改规则验证步骤认为所述文件信息符合所述规则信息时，生成与所述被修改的部分的修改历史相关的信息、即部分修改信息；

管理步骤，该管理步骤把所述被修改的文件信息、所述部分识别信息、所述部分修改信息和所述规则信息关联起来进行管理；以及

登记验证步骤，该登记验证步骤使用通过所述管理步骤被关联起来的部分识别信息、部分修改信息，来验证文件信息的正当性。

13.一种电子文件管理程序，该电子文件管理程序使计算机执行利用电子信息而制作的文件信息的管理，其特征在于，该电子文件管理程序使计算机执行以下步骤：

登记请求接收步骤，该登记请求接收步骤接收所制作的文件信息的登记请求；

部分识别信息生成步骤，该部分识别信息生成步骤在通过所述登记规则验证步骤的验证认为所述文件信息符合规定的规则信息时，生成以可识别的方式表示所述文件信息的各部分的部分识别信息；以及

14.一种电子文件管理程序，该电子文件管理程序使计算机执行利用电子信息而制作的文件信息的管理，其特征在于，该电子文件管理程序使计算机执行以下步骤：

修改请求接收步骤，该修改请求接收步骤接收关于对管理对象的文件信息进行了修改的文件信息的修改请求；

15.根据权利要求13所述的电子文件管理程序，其特征在于，所述部分识别信息生成步骤使计算机执行以下步骤：将文件信息划分为多个部分，根据各部分的信息而生成所述部分识别信息。

16.根据权利要求13所述的电子文件管理程序，其特征在于，通过所述管理步骤而被管理的所述信息被利用具有分层的文件结构的XML数据来管理。

17.根据权利要求13所述的电子文件管理程序，其特征在于，所述部分识别信息生成步骤按照所述文件信息的各部分的修改指示，在具有分层的文件结构的XML数据的修改中，把从前一版本被修改的位置、以及未被修改的位置的所有的母要素、子要素作为对象，来生成部分识别信息。

18.根据权利要求13所述的电子文件管理程序，其特征在于，所述部分识别信息生成步骤针对从前一版本被修改的位置，把子要素及其所属的母要素作为对象来生成部分识别信息，针对属于母要素的所有子要素中没有修改的位置，只把该母要素作为对象来生成部分识别信息。