專利名稱：電子文件管理系統的制作方法
技術領域：
本發明涉及一種對利用電子信息而生成的文件信息進行管理的電子文件管理系統等，特別涉及在適用于要求與紙件相同的證據能力的文件的電子化、流通、保管，且產生部分修改(例如包括追加、變更、刪除、涂墨(墨塗り)等)的電子化的文件信息中，能夠容易地進行該修改部位的確定以及其正當性的擔保、和第三方證明的電子文件管理系統、電子文件管理方法、電子文件管理程序。
背景技術：
作為現有技術，首先說明處理紙件文件時的修改方法及其正當性確認方法。
以往，作為對紙件文件進行修改的代表性的修改方法，圖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局面。
作為使用者使用本系統的場景，有合同文件的記錄/保存。在合同文件中，有時在制作后要進行修改。此時，對修改者和修改位置的確定、修改內容等要求其證明性。之后，利用本系統，作為保留了在事后打官司時可以作為證據提交的記錄的單元。作為本利用場景的出場人物有兩人，進行該合同文件的新制作及修改的“鈴木花子小姐”，和進行使用本系統的驗證的“管理者”。上述兩人執行以下處理步驟。
(新制作)由鈴木花子小姐新制作該合同文件，并在本系統中進行登記。
(修改)由于搬遷，鈴木花子小姐的住所需要修改，由鈴木花子小姐本人將該合同文件中的住所欄中記載的“川崎市中原區”修改為“橫浜市港北區”，并在本系統中進行登記。
(驗證)在完成修改處理/登記后不久，由管理者進行伴隨住所修改的驗證(修改位置的確定和修改內容的確認、以及除了修改位置之外沒有修改的確認)。
在上述利用場景中，在本系統中對鈴木花子小姐和管理者提供以下三種功能。
(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局面，假設以下所述的利用場景。
使用本系統作為使在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)即使不取出在本系統內保存管理的所有版本的電子文件，也能夠進行被部分涂墨的狀態和只使用了部分版本的第三方證明和流通。
權利要求
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所述的電子文件管理程序，其特征在于，所述部分識別信息生成步驟針對從前一版本被修改的位置，把子要素及其所屬的母要素作為對象來生成部分識別信息，針對屬于母要素的所有子要素中沒有修改的位置，只把該母要素作為對象來生成部分識別信息。
全文摘要
本發明提供電子文件管理系統、電子文件管理方法、電子文件管理程序。一種電子文件管理系統等，能夠擔保電子文件中進行的部分修改是正確進行的，而且能夠對它們的正當性進行第三方證明。一種管理利用電子信息而制作的原稿信息的電子文件管理系統，該系統具有部分識別信息生成部(51)，其生成以可識別的方式表示文件信息的各部分的部分識別信息；部分修改信息生成部(52)，其在文件信息的各部分有修改時，生成與被修改的部分的修改歷史相關的信息、即部分修改信息；以及原稿管理部(40)，其把文件信息、部分識別信息、部分修改信息和所規定的規定規則信息關聯起來進行管理。
文檔編號G06F17/24GK1989498SQ20058002447
公開日2007年6月27日 申請日期2005年1月24日 優先權日2004年7月20日
發明者吉岡孝司, 武仲正彥 申請人:富士通株式會社