JP5028884B2 - 電子文書管理システム、電子文書管理方法、電子文書管理プログラム - Google Patents

Description

本発明は、電子情報で作成される文書情報を管理する電子文書管理システム等に関し、特に、紙と同等の証拠能力を必要とする文書の電子化・流通・保管に適用され、部分的な訂正（例えば追加・変更・削除・墨塗り等を含む）が発生する電子化された文書情報において、その訂正箇所の特定、並びにその正当性の担保、及び第三者証明を容易に行うことができる電子文書管理システム、電子文書管理方法、電子文書管理プログラムに関するものである。

従来の技術として、まず、紙文書を取り扱う際における訂正方法とその正当性確認方法について説明する。
従来、紙文書に対して訂正を行う代表的な訂正方法として、図７０に示すような方法が知られている。すなわち、図７０によれば、訂正箇所の文字を二重線で消し、すぐ上の余白に訂正文字を記入し（Ｐ１）、次に、訂正情報を余白に明記し、当事者双方の訂正印を押印する（Ｐ２）。

従来の紙文書に対する訂正においては、上記Ｐ１、Ｐ２を行うことで以下を担保、確認することが可能である。
（１）訂正箇所を容易に確認・特定可能であり、訂正箇所以外は故意・過失による変更がないことを確認可能である。
（２）訂正範囲が容易に確認・特定可能である。
（３）訂正箇所は誰が訂正したのか容易に確認可能である。
（４）訂正してもよい箇所かどうか確認可能である。
（５）訂正前の内容が確認可能である。
（６）訂正に関するポリシ（制御情報）に従って訂正可能であり、かつ、検証可能である。

また、保険契約申込書や運送依頼票等で使用されるカーボン紙付き文書も同様に、以下を担保・確認することが可能である。

（７）一部の内容を隠蔽可能であり、その他の箇所は改変がないことを確認可能である。
（８）原紙とカーボン紙の内容を比較した場合、各々に書かれた筆跡から内容が同一であることを確認可能である。
（９）原紙とカーボン紙を分けて保管することで、内容の改ざんを検知可能である。
（１０）上記（９）から裁判沙汰になった場合、内容に関する第三者証明が可能である。
（１１）原紙とカーボン紙は必要に応じて流通して利用される。また、場合によっては別々に流通利用が可能である。

以上のように紙文書を用いる場合は、訂正方法とその正当性確認方法について様々な点で優れるが、一方で、近年のＩＴ技術の進歩に伴って、データの取り扱い、保存等の利便性から上述した紙文書に代えて電子データ（電子情報）を取り扱うという技術が提案されつつある（例えば、下記特許文献１，２，３及び非特許文献１，２参照）。
特開２０００−２８５０２４号公報 特開２００１−１１７８２０号公報 特開２００３−１１４８８４号公報 情報処理学会／コンピュータセキュリティ研究会（CSEC）論文「電子文書墨塗り問題（2003/7/17）（2003-CSEC-22-009） SCIS2004論文「開示条件を制御可能な電子文書墨塗り技術」

特許文献１や特許文献２は、電子文書の原本保管技術に関するものであり、電子文書を保存する際に、紙の原本が有する性質を電子情報に持たせ、また、電子文書が改ざんされないように保護する技術を提供している。つまり、これらの技術は、確定された最終形態の電子文書を原本として保管、管理する機構、いわゆる原本の所在が明確であり、一組織内に蓄えられる原本をいかに安全に保管するかという点に注目している。

しかしながら、このような原本保管技術においては、電子文書に対して訂正が発生した場合、一部でも訂正が行われた場合は“改ざん”と認識されてしまう。例えば、先に述べたような“紙の契約文書への訂正”を考えた場合、訂正の際は、「訂正箇所の文字を二重線で消し、すぐ上の余白に訂正文字を記入する。更に、訂正者印を押印する。」といった処理が行われるが、訂正を加えても契約文書の原本には相違ない。

紙文化におけるこのような行為は、正当な手続きを踏んで訂正を行っていると公的に判断され、第三者的に証明が可能となっている。

これに対して電子文書の場合、証拠性という観点から従来の原本保管技術を適用すると、訂正部分は改ざんされたものなのか、正当な手続きを経て訂正されたものなのか識別できないという問題が生じる。これは、電子文書に対するいかなる改変も検知できるように設計されている現状の電子署名の特徴からも言えることである。

特許文献３は、電子文書編集表示技術に関するものであり、電子文書の原本性を保証しつつ、文書を複数化することなく要素毎に修正や追加及び表示制御を行う手段が提供されている。この技術では、原本情報は実データである原本部分と要素毎の制御を記載した定義部分を含む一ファイルで構成・管理されており、修正や追加が行われる場合には、この定義部分に修正情報として記載・付加される。これにより、修正情報に関する第三者証明を行うことは可能である。

しかし、この方式では旧版を含む全ての修正情報を示さなければならず、一部の内容を隠した（墨塗りを施した）状態や、一部の版のみでの第三者証明ができないという問題があった。

非特許文献１は、電子文書墨塗り技術に関するものであり、「電子文書墨塗り問題」論文では、ある文書に対して施された署名が、文書の一部を秘匿することによって検証できなくなる問題を解決する電子文書の墨塗り技術が提案されている。本論文の電子文書墨塗り技術を適用することにより、署名付き電子文書に対して墨塗りを施した状態でも署名検証が可能となり、且つ墨塗り箇所以外は改変がないことを第三者証明することが可能となり、特許文献３の課題で指摘した「一部の内容を隠した（墨塗りを施した）状態での第三者証明」が可能になる。

しかしながら、本論文の電子文書墨塗り技術では、オリジナル文書の作成者を保証しており、誰が墨塗りを行ったかまで明確に識別することができない。更に、利用シーンとして情報公開制度における電子文書墨塗り問題を取り挙げており、一部墨塗りした文書を複数のエンティティ間で流通させ、当該文書を更に利用することまで考慮されていない。

本発明は、上述した問題点を解決するためになされたものであり、電子文書が複数のエンティティ間で転々流通する過程において、部分的な訂正（例えば、追加、変更、削除等を含む）がなされた電子文書に対し、保管される少ないメタデータ量にて、訂正箇所を特定することができ、また訂正箇所以外は改変されていないことを確認することができ、並びに部分的な訂正が誰によって行われたかを特定・確認することができ、さらに当該部分訂正が正しく行われたことを担保し、これらの正当性を第三者証明可能とすることができる電子文書管理システム、電子文書管理方法及び電子文書管理プログラムを提供することを目的としている。

上述した課題を解決するため、本発明は、電子情報で作成され登録される文書情報をコンピュータにより管理する電子文書管理プログラムであって、文書情報を複数の部分に区切り、各部分の情報に基づいて文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成ステップと、文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成ステップと、文書情報を管理する管理ステップと、管理されている文書情報の正当性を検証する検証ステップとを有し、前記管理ステップは、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成ステップにより作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての部分識別情報を得ると共に、前記電子署名作成ステップにより、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての部分識別情報を訂正された文書情報に対応付けて管理し、前記検証ステップは、前記管理ステップにより前記訂正された文書情報に対応付けられて管理されている前記部分識別情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成ステップにより部分識別情報を生成させて得られた部分識別情報とを用いて検証することをコンピュータに実行させることを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記電子署名作成ステップは、前記部分識別情報生成ステップにより、生成された部分識別情報の集合と、秘密鍵とをパラメータとして署名関数を用いて電子署名を作成することを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記電子署名作成ステップは、グループ署名の一種であり、多段の署名を1つの署名に重畳することが可能なアグリゲート（Aggregate）署名関数を用いて電子署名を作成することを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記訂正された文書情報に対応付けられて管理される前記部分識別情報は、前記訂正された文書情報のデータと別個に管理されることを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記部分識別情報は、前記訂正済の文書情報に埋め込まれて管理されることを特徴とする。

また、本発明の電子文書管理プログラムにおいて、更に、予め規定されたポリシ情報を保管するポリシ情報保管ステップと、前記文書情報に訂正があった場合に、訂正された部分の訂正履歴に関する情報である部分訂正情報を生成する部分訂正情報生成ステップとを備え、前記管理ステップは、前記文書情報の一部に対して訂正があった場合、前記部分訂正情報生成ステップにより部分訂正情報を生成させ、生成された部分訂正情報と、前記所定のポリシ情報保管ステップにより保管されているポリシ情報とを更に前記訂正された文書情報に対応させて管理し、前記検証ステップは、前記訂正された文書情報の正当性を、該文書情報に関連付けられて前記管理ステップにより管理されている前記部分識別情報と前記署名情報とに加え、更に前記部分訂正情報と、前記ポリシ情報とを用いて検証することを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記部分識別情報生成ステップは、文書情報を複数の部分に区切り、各部分の文書情報に対してハッシュ関数を用いて部分識別情報を生成することを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記管理ステップにより管理される前記情報は、階層的な文書構造を持つXMLデータにより構成されることを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記管理ステップは、全ての電子情報を版数に対応する原本情報として扱うと共に、版数管理されている原本情報の内容は、各版数の原本情報の内容によって閲覧可能者と閲覧不能者を識別可能とすることを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記電子署名作成ステップで作成された電子署名を暗号化する暗号化ステップを備えることを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記暗号化ステップは前記電子署名作成ステップで作成された電子署名を所定の暗号鍵で暗号化することを特徴とする。

また、本発明の電子文書管理プログラムにおいて、前記暗号化ステップは前記電子署名作成ステップで作成された電子署名に所定の乱数を付加することを特徴とする。

また、本発明は、電子情報で作成され登録される文書情報を管理する電子文書管理システムであって、文書情報を複数の部分に区切り、各部分の情報に基づいて文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成部と、文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成部と、文書情報を管理する管理部と、管理されている文書情報の正当性を検証する検証部とを有し、前記管理部は、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成部により作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての部分識別情報を得ると共に、前記電子署名作成部により、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての部分識別情報を訂正された文書情報に対応付けて管理し、前記検証部は、前記管理部により前記訂正された文書情報に対応付けられて管理されている前記部分識別情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成部により部分識別情報を生成させて得られた部分識別情報とを用いて検証する
ことを特徴とする。

また、本発明は、電子情報で作成され登録される文書情報をコンピュータにより管理する電子文書管理方法であって、文書情報を複数の部分に区切り、各部分の情報に基づいて文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成ステップと、文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成ステップと、文書情報を管理する管理ステップと、管理されている文書情報の正当性を検証する検証ステップとを有し、前記管理ステップは、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成ステップにより作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての部分識別情報を得ると共に、前記電子署名作成ステップにより、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての部分識別情報を訂正された文書情報に対応付けて管理し、前記検証ステップは、前記管理ステップにより前記訂正された文書情報に対応付けられて管理されている前記部分識別情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成ステップにより部分識別情報を生成させて得られた部分識別情報とを用いて検証する
ことを特徴とする。

本発明によれば、非常に少ないメタデータ量を管理することにより、従来の技術及びその単純な組み合わせでは不可能であった下記の要件を満足することが可能となるという効果を奏する。
（１）電子文書の訂正箇所を特定、並びに、訂正箇所以外は変更されていないことを確認することが可能である。
（２）複数エンティティ間で訂正済み電子文書を転々流通させ、かつ、各エンティティにおいて訂正・追加等を行う場合、各時点において電子文書の完全性・原本性を保証（第三者証明）することが可能である。
（３）本システム内に保存・管理されている全ての版数の電子文書を取り出さなくても、一部墨塗りされた状態や、一部の版のみを用いた第三者証明や流通を行うことが可能である。

以下、本発明の実施の形態を説明するため、その前提となる技術について図面を用いて説明する。

（前提技術）
本発明の前提技術における電子文書管理システムは、電子情報で作成された電子文書としての文書情報とは別に、ポリシ情報（登録用ポリシ情報と訂正用ポリシ情報）と部分完全性情報（部分識別情報と部分訂正情報）を別個に保持し、言わば電子文書部分完全性保証システムとして電子文書を検証、流通させる仕組みを提供する。

図１は本発明に係る電子文書管理システムの原理図を示す。まず、図１を用いて電子文書管理システムの基本構成について説明する。なお、以下、本明細書においては、文書情報と原本情報、及び文書と原本は、それぞれ同義語として用いることとする。

図１に示す電子文書管理システムは、登録手段１、生成手段２、管理手段３、検証手段４、及び流通手段５を備える。
登録手段１は電子情報から作成される文書情報を原本情報として登録し、生成手段２は登録された原本情報の部分的な訂正、変更、追加、削除等（以下訂正という）を識別する部分識別情報と、原本情報の部分的な訂正履歴を表す部分訂正情報を生成する。
管理手段３は、部分識別情報と部分訂正情報の２つの情報を部分完全性情報として原本情報とともに管理し、更に、ポリシ情報と関連付けて管理する。

ポリシ情報は、原本情報の登録時には、登録ポリシ情報として、当該原本情報における必要記載事項（必要文書情報）や作成者権限等の条件を記述したものとして使用され、また、原本情報の登録後の訂正時には、訂正ポリシ情報として、当該原本情報に対してあらかじめ決められている部分訂正管理制御情報（訂正者、訂正可能範囲、訂正不可範囲等）、手順、制約、条件等を記述したものとして使用される。なお、本前提技術では、訂正ポリシ情報も登録ポリシ情報も同一のものが使用される。

紙での契約文書の場合、入力すべき箇所や訂正者、訂正操作、手順は規約等によって決まっており、電子情報からなる文書情報においても同様に操作制御とその内容を検証する手段を提供する。

検証手段４は、訂正ポリシ情報と部分完全性情報を用いて、原本情報に対する部分訂正が正しく行われたことを確認する。
流通手段５は、複数のエンティティ間で当該原本情報を流通させるため、原本情報の送受信を行う送受信部を構成する。

登録手段１が登録する原本情報は、事後、裁判沙汰になった場合に証拠として提出するため第三者証明が必要な文書（例えば、契約書等の重要文書）に対応し、登録された原本情報は、登録手段１内に保存される。生成手段２が生成する部分識別情報と部分訂正情報は、登録手段１に登録されている原本情報の訂正箇所、訂正内容に関して事後確認できるようにするために生成され、当該原本情報に関連付けされる。登録手段１内に保存されている原本情報の訂正を行う場合は、旧版を残して新版として作成、保存され、当該版数に対する部分完全性情報が生成され、関連付けが行われる。

このような電子文書管理システムによれば、上述した原本情報のような電子文書の訂正箇所を明確に特定でき、部分訂正が正しく行われた事を担保することが可能になり、訂正済み電子文書（文書情報）を複数エンティティ間で転々流通させ、かつ、各エンティティの時点において訂正済み電子文書の完全性を保証することが可能となる。

（前提技術１）
以下、本発明の前提技術１として、本発明の前提技術を第１の適用分野に適用した場合について説明する。図２は、本発明の前提技術における電子文書管理システムの構成を示す機能ブロック図である。

図２に示す電子文書管理システム１０は、要求解析部２０、ポリシ管理部３０、原本管理部４０、部分完全性情報生成部５０、部分完全性情報検証部６０、及び流通管理部７０を備える。

以下にこれら各部の構成および役割について説明する。
要求解析部２０は、利用者９０からの処理依頼を受け付け、各処理に応じてポリシ管理部３０、原本管理部４０への処理割り振りを行う。ポリシ管理部３０は、原本情報に対応するポリシ情報の保管と検証を行う。

ポリシ情報とは、当該原本情報に対して、登録時（作成時）の必要記載事項・作成者権限や、所定の部分訂正管理制御情報（訂正者、訂正可能／不可範囲等）、手順、制約、条件等が記述されている。

紙での契約文書の場合、入力すべき箇所や訂正者、訂正操作・手順は規約等によって決まっており、電子情報においても同様に操作制御とその内容を検証する部を提供する。ポリシ管理部３０は、ポリシ保管部３１と、登録ポリシ検証部３２ａ、訂正ポリシ検証部３２ｂの２つのサブ要素から構成される。

ポリシ保管部３１は、要求解析部２０よりポリシ保管依頼を受け付け、ポリシ情報の登録、保管を行う。登録ポリシ検証部３２ａは、ポリシ保管部３１に既に登録されている登録ポリシ情報に従って、原本情報の登録時に予め決められた作成者であるかどうか、また、その必要記載事項が満たされているか否かの検証を行う。訂正ポリシ検証部３２ｂは、ポリシ保管部３１に既に登録されている訂正ポリシ情報に従って当該原本情報が正しく作成、訂正されているか否かの検証を行う。

原本管理部４０は、ポリシ管理部３０に登録されているポリシ情報を部分完全性情報とともに電子情報に関連付け、これら情報を原本情報として登録、管理、保管する。原本管理部４０は、原本処理部４１と、原本保管部４２の２つのサブ要素から構成される。

原本処理部４１は、要求解析部２０より処理依頼を受け付け、原本情報に対する各種処理の実行を行う。原本処理部４１には、例えば、新規データ登録処理（原本登録処理）、登録データ訂正処理（登録原本訂正処理）、登録データ取得処理（登録原本取得処理）、登録データ検証処理（登録原本検証処理）を実行可能な機能を保持する。

原本保管部４２は、原本処理部４１より原本格納・保管依頼を受け付け、当該原本情報と部分完全性情報と共に登録、保管を行う。また、原本処理部４１より原本情報の取得依頼を受け付け、当該原本情報と部分完全性情報の取り出しを行う。

部分完全性情報生成部５０は、原本管理部４０より部分完全性情報生成依頼を受け付け、原本情報に対する部分識別情報と、部分訂正情報の生成を行う。部分完全性情報生成部５０は、部分識別情報生成部５１と、部分訂正情報生成部５２の２つのサブ要素から構成される。

部分識別情報生成部５１は、原本管理部４０より部分識別情報生成依頼を受け付け、原本情報に対する部分識別情報（原本情報の各部分及びその記載事項を識別可能に示す情報）の生成を行う。部分識別情報には例えば、原本情報の各部分（例えば、一文字単位、もしくは、ＸＭＬデータであれば一要素単位でもよい）に対して変更の有無が確認できるよう各部分の乱数を含めたハッシュ情報、並びにそのハッシュ情報がどの部分に相当するかの位置情報が記載されている。

部分訂正情報生成部５２は、原本管理部４０より部分訂正情報生成依頼を受け付け、原本情報に対する部分訂正情報の生成を行う。部分訂正情報には例えば、「いつ」、「誰が」、「どの箇所に対して」、「どのような操作を行ったか」、「訂正前情報」、「訂正理由」のような情報（原本情報の各部分における訂正履歴）が記載されている。

部分完全性情報検証部６０は、原本管理部４０より部分完全性情報検証依頼を受け付け、原本情報に対する部分識別情報と、部分訂正情報の検証を行う。部分完全性情報検証部６０は、部分識別情報検証部６１と、部分訂正情報検証部６２の２つのサブ要素から構成される。

部分識別情報検証部６１は、原本管理部４０より部分識別情報検証依頼を受け付け、原本情報に対する部分識別情報の検証を行う。

部分訂正情報検証部６２は、原本管理部４０より部分訂正情報検証依頼を受け付け、原本情報に対する部分訂正情報の検証を行う。

流通管理部７０は、原本管理部４０より原本情報の送受信依頼を受け付け、当該原本情報と部分完全性情報の送信処理、並びに受信処理を行う。流通管理部７０は、送信処理部７１と、受信処理部７２の２つのサブ要素から構成される。

送信処理部７１は、原本管理部４０より原本情報の送信依頼を受け付け、当該原本情報と部分完全性情報を対象エンティティに対して送信処理を行う。受信処理部７２は、原本管理部４０より原本情報の受信依頼を受け付け、対象エンティティから送信されてきた当該原本情報と部分完全性情報の受信処理を行う。

以下に本前提技術を２つの適用分野に分類して説明する。まず第１の適用分野では、本発明の基本概念（個別基本機能）となる「新規作成機能」、「訂正（一部墨塗り）機能」、「検証機能」、「流通機能」、「取得機能」に関する各作用について説明する。第２の適用分野では、第１の適用分野において実現される原本管理方法と検証方法に関して更に改良、改善することを目的として、XML（eXtensible Markup Language）文書に特化して説明する。ここでは、XML文書フォーマットの特徴のひとつである構造化に着目し、より効率的な部分改ざん検出を実現する原本管理方法、および、検証方法について説明する。
まず初めに、第１の適用分野である基本概念（個別基本機能）について利用シーンに沿って説明する。以下に本前提技術１の動作の例として、第１の局面と第２の局面の二つの場合について説明する。
〔第１の局面〕
まず、第１の局面として、次の利用シーンを想定する。
利用者が本システムを利用する場面として契約文書の記録／保存がある。契約文書では、作成後に訂正を行う場合がある。この時、訂正者や訂正箇所の特定、訂正内容等、その証明性が求められる。事後、裁判沙汰になった場合に証拠として提出できるよう記録を残す部として本システムを利用する。本利用シーンの登場人物として、当該契約文書の新規作成、並びに訂正を行う「鈴木花子さん」、また、本システムを利用した検証を行う「管理者」の２名が登場する。上記２名は、以下のプロセスを行うものとする。

（新規作成）
鈴木花子さんによって当該契約文書を新規作成し、本システムに登録を行う。
（訂正）
引越しのため、鈴木花子さんの住所に訂正事由が発生し、鈴木花子さん本人によって当該契約文書中の住所欄に記載されている「川崎市中原区」を「横浜市港北区」に訂正し、本システムに登録を行う。
（検証）
訂正処理／登録完了後まもなく、管理者によって、住所訂正に伴う検証（訂正箇所の特定と訂正内容の確認、並びに、訂正箇所以外は訂正されていないことの確認）を行う。

上記利用シーンにおいて、本システムでは鈴木花子さんと管理者に対して以下の三つの機能を提供する。
（Ａ）新規データ登録機能（契約文書の新規作成時に利用）
（Ｂ）登録データ訂正機能（契約文書の訂正時に利用）
（Ｃ）登録データ検証機能（契約文書の検証時に利用）

以下より、上記（Ａ）〜（Ｃ）の各事象における作用について説明する。
本利用シーンの事前条件として、利用者９０（鈴木花子さん、管理者）は本電子文書管理システムを利用できるよう事前登録されている。本利用シーンは、鈴木花子さん、管理者が当該システムにアクセス／ログインするところから始まる。また、当該契約文書に対応するポリシ情報は、ポリシ保管部３１に既に登録／保管されているものとする。例えば、図３は、ポリシ情報の内容例を示した図である。

図３に示すポリシ情報の内容を説明すると、以下の制御情報が書かれている。契約文書の必須情報として“名前”、“住所”、“生年月日”を入力すること、“名前”と“住所”に関しては必要に応じて訂正可能、“生年月日”はその性質上、訂正できないものとする。ただし、“生年月日”については、墨塗りを施すことを可能とする。本ポリシ情報は、当該システムにおいて、複数のエンティティ間で流通されていくことを考慮し、その安全性を向上させるため、システム管理者の署名が施されるよう規定されていてもよい。

（Ａ）契約文書の新規作成時
図６は、新規文書登録処理の動作を示すフローチャートである。この新規登録処理に際して、利用者９０（鈴木花子さん）は、まず、図示しない画面中の「新規文書作成」メニューの「契約文書」を選択し、ポリシ情報に基づいたフォーマット済み契約文書に対して入力を行う。入力が確定すると、電子文書管理システム１０内の要求解析部２０に対して、新規文書登録依頼を発行する。これより以下の処理（ステップ）が開始される。

（１）電子文書管理システム１０内の要求解析部２０は、新規文書登録依頼を受信し（ステップST-R1）、原本処理部４１に対して新規文書登録依頼を発行する（ステップST-R2）。

（２）原本処理部４１は、登録ポリシ検証部３２ａに対して、登録ポリシ検証依頼を発行する（ステップST-R3）。

（３）登録ポリシ検証部３２ａは、ポリシ保管部３１に登録／保管されているポリシ情報を参照し、当該ポリシ情報に従って文書が作成されているかの検証を行い、検証結果を原本処理部４１へ返す（ステップST-R4）。

（４）原本処理部４１は、登録ポリシ検証部３２ａからの検証結果を取得し、検証結果が肯定（ＯＫ）の場合は、部分識別情報生成部５１へ生成依頼を発行する（ステップST-R5）。検証結果が否定（ＮＧ）の場合は、ログアウトし、新規文書登録処理を異常終了する。

（５）部分識別情報生成部５１は、当該文書に対応する部分識別情報を生成し、原本処理部４１へ生成結果を返す（ステップST-R6）。

図４は、部分識別情報生成部５１により生成される部分識別情報の内容例を示した図である。ここでは、例えば、“鈴木花子”という文字列に乱数“123”を連結し、文字列“鈴木花子123”に対するハッシュ情報を計算し、その生成結果として、“abcdefgh”というハッシュ情報が出力されている様子を示している。以下、他要素についても同様の生成処理が行われる。

ここで、具体例として乱数を取り挙げているのは、後に記述する第２の局面において部分的に墨塗りを行う際、墨塗りされる前の元の情報が容易に推測されることを困難にするためである。この例では乱数を使用しているが、当該目的のために乱数以外の手法を用いても構わない。

なお、この乱数以外の手法として、日時を示すタイムスタンプ F(time-stamp)を使用する方法も有り得る。この場合、Fは任意関数であり、タイムスタンプ(time-stamp)をそのまま流用するわけではない。これは、タイムスタンプの場合、「年月日時分秒」といった固定フォーマットによって構成される可能性があり容易に推測可能となるため、この問題を回避するためである。またここで、タイムスタンプを用いる場合は、作成日時も同時に保証することが可能となる。

（６）原本処理部４１は、部分識別情報生成部５１からの部分識別情報を取得し、当該契約文書と部分識別情報を原本保管部４２へ登録し保管する（ステップST-R7）。

この時、契約文書と部分識別情報には鈴木花子さんの署名をそれぞれ付与する。

図５は、新規文書登録時の原本保管部４２の状態を示している。生成された部分識別情報は本文である契約文書の管理情報として一体化された形で保持される。以上の処理が完了すればログアウトし、新規文書登録処理を正常終了する。

（Ｂ）契約文書訂正時
図１０は、登録文書訂正処理の動作を示すフローチャートである。この動作においては、まず、利用者９０（鈴木花子さん）が図示しない画面中の「登録文書訂正」メニューを選択すると、鈴木花子さんが取り扱い可能な（訂正可能な）「対象登録文書一覧」が表示される。鈴木花子さんが画面中の「対象登録文書一覧」より、訂正する契約文書を選択し確定すると、電子文書管理システム１０内の要求解析部２０に対して、登録文書取得依頼を発行する。これより以下の処理（ステップ）が開始される。

（１）登録文書取得依頼が発行されると、電子文書管理システム１０内の要求解析部２０は、登録文書取得依頼を受信し（ステップST-U1）、原本処理部４１に対して登録文書取得依頼を発行する（ステップST-U2）。

（２）原本処理部４１は、原本保管部４２に登録／保管されている当該文書を取り出し、鈴木花子さんが参照できるよう画面に表示する（ステップST-U3）。

ここで、鈴木花子さんは契約文書内の住所欄に記載されている「川崎市中原区」を「横浜市港北区」に訂正して確定すると、電子文書管理システム１０内の要求解析部２０に対して、登録文書訂正依頼を発行する。

（３）電子文書管理システム１０内の要求解析部２０は、登録文書訂正依頼を受信し（ステップST-U4）、原本処理部４１に対して登録文書訂正依頼を発行する（ステップST-U5）。

（４）原本処理部４１は、訂正ポリシ検証部３２ｂに対して、訂正ポリシ検証依頼を発行する（ステップST-U6）。

（５）訂正ポリシ検証部３２ｂは、ポリシ保管部３１に登録／保管されているポリシ情報を参照し、当該ポリシ情報に従って文書が訂正されているかの検証を行い、検証結果を原本処理部４１へ返す（ステップST-U7）。なお、この訂正ポリシ検証は、原本情報において、訂正可能と規定されている範囲においてのみ（その範囲を逸脱しないで）、訂正が行われているか否かを検証する。

図７は、訂正可能範囲と訂正不可範囲を特定する例を示した図である。訂正可能範囲である“住所”を訂正した場合は検証を肯定（ＯＫ）し、訂正不可範囲である“生年月日”を訂正した場合は、検証を否定（ＮＧ）する様子を示している。

（６）原本処理部４１は、訂正ポリシ検証部３２ｂからの検証結果を取得し、検証結果を肯定する場合は、部分識別情報生成部５１へ生成依頼を発行する（ステップST-U8）。検証ＮＧの場合は、ログアウトし、登録文書訂正処理を異常終了する。

（７）部分識別情報生成部５１は、当該文書に対応する部分識別情報を生成し、原本処理部４１へ生成結果を返す（ステップST-U9）。ここで、部分識別情報の生成においては、前版から訂正された“住所”のみ新しい乱数、もしくは、訂正処理時のタイムスタンプを用いて新たな部分識別情報を生成し、“住所”以外（訂正箇所以外）は前版と同一の乱数、もしくは、作成時のタイムスタンプを用いて生成する。これにより、訂正文書（第２版）はオリジナル文書（第１版）の派生文書であることが証明でき、かつ、同一人物が同じ内容を記載しても毎回異なる部分識別情報が生成されるため、紙ベースで実現されている「筆跡が同一」であることを証明することが可能となる。

（８）原本処理部４１は、引き続き、部分訂正情報生成部５２へ生成依頼を発行する（ステップST-U10）。

（９）部分訂正情報生成部５２は、当該文書に対応する部分訂正情報を生成し、原本処理部４１へ生成結果を返す（ステップST-U11）。例えば、図８は、部分訂正情報の内容例を示した図である。

（１０）原本処理部４１は、部分識別情報生成部５１から部分識別情報を、部分訂正情報生成部５２から部分訂正情報をそれぞれ取得し、当該訂正済み契約文書、並びに、部分識別情報と部分訂正情報を原本保管部４２へ登録し保管する。この時、契約文書、並びに、部分識別情報と部分訂正情報には鈴木花子さんの署名をそれぞれ付与する（ステップST-U12）。

図９は、登録文書訂正時の原本保管部４２の状態を示している。前述したとおり、契約文書の１版と２版を参照し、住所要素の属性=Ｒ部分（この例では乱数を用いている）を比べてみると、１版がＲ="234"、２版がＲ="876"となっており、訂正された住所欄のみ異なる乱数を用いていることがわかる。また、住所欄以外の乱数は１版、２版ともに同一の値を用いていることがわかる。部分識別情報の１版、２版を比べても、同様の結果が得られていることは一目瞭然である。

以上の処理が完了すればログアウトし、登録文書訂正処理を正常終了する。なお、上記ステップST-U8〜ステップST-U11の少なくともいずれか一つの過程で、電子文書管理システム１０は「訂正箇所」と「訂正内容」を表示し、訂正に対する同意を利用者９０（鈴木花子さん）に求めるようにしてもよい。例えば、「住所が”川崎市中原区”から”横浜市港北区”に訂正されましたがよろしいですか？」等と求めてもよい。

（Ｃ） 訂正済み契約文書に関する完全性／正当性検証時
図１４は、登録文書検証処理の動作を示すフローチャートである。

この処理においては、まず、利用者９０（管理者）が図示しない画面中の「登録文書検証」メニューを選択すると、管理者が取り扱い可能な（検証可能な）「対象登録文書一覧」が表示される。管理者が画面中の「対象登録文書一覧」より、検証する契約文書を選択し確定すると、電子文書管理システム１０内の要求解析部２０に対して、登録文書検証依頼を発行する。これより以下の処理（ステップ）が開始される。

（１）電子文書管理システム１０内の要求解析部２０は、登録文書検証依頼を受信し（ステップST-V1）、原本処理部４１に対して登録文書検証依頼を発行する（ステップST-V2）。

（２）原本処理部４１は、原本保管部４２に登録／保管されている当該検証データ群を取り出す（ステップST-V3）。この時、取り出す検証データ群は以下のとおりである。カッコ[ ]内は、最新版をＮ版とした場合の版数を示す。

（ａ）：契約文書（最新版:２版[Ｎ版]）
（ｂ）：部分識別情報（最新版:２版[Ｎ版]）
（ｃ）：部分識別情報（１版[Ｎ−１版]）
（ｄ）：部分訂正情報（最新版:２版[Ｎ版]）

（３）原本処理部４１は、訂正ポリシ検証部３２ｂに対して、訂正ポリシ検証依頼を発行する（ステップST-V4）。

（４）訂正ポリシ検証部３２ｂは、ポリシ保管部３１に登録／保管されているポリシ情報を参照し、ステップST-V3で取得した部分訂正情報（ｄ）と比較することで、当該ポリシ情報に従って文書が正しく訂正されているかの検証を行い、検証結果を原本処理部４１へ返す（ステップST-V5）。

図１１は、ポリシ情報と部分訂正情報の比較を示した図である。部分訂正情報に記載されている訂正内容は“住所”に関する内容であり、ポリシ情報にも“住所”項目は訂正可能範囲と記述されているため、検証は肯定（ＯＫ）とされる。

（５）原本処理部４１は、訂正ポリシ検証部３２ｂからの検証結果を取得する。次に、部分訂正情報検証部６２へ検証依頼を発行する（ステップST-V6）。

（６）部分訂正情報検証部６２は、以下の検証処理を実行し、原本処理部４１へ検証結果を返す（ステップST-V7）。
（６−１）ステップST-V3で取得した部分訂正情報（ｄ）を参照し、訂正箇所の特定と部分訂正内容を確認する。

（７）原本処理部４１は、引き続き、部分識別情報検証部６１へ検証依頼を発行する（ステップST-V8）。

（８）部分識別情報検証部６１は、以下の検証処理を実行し、原本処理部４１へ検証結果を返す（ステップST-V9）。
（８−１）ステップST-V3で取得した契約文書（ａ）と、部分識別情報（ｂ）を比較して、当該版数の契約文書を本システムに登録後、改ざんがないことを確認する。図１２は、その比較の様子を示した図である。
（８−２）ステップST-V7で取得した部分訂正情報の検証結果（６−１）から訂正箇所（“住所”）を特定する。ステップST-V3で取得した部分識別情報（ｂ）と（ｃ）中の“住所”の内容を比較し、確かに訂正されていることを確認する。更に、訂正箇所以外は前版数から訂正がなされていないことを確認する。図１３は、その比較の様子を示した図である。この例では、１版の部分識別情報（ｃ）と比較して、住所部分の“67890123”と、“qrstuvwx”だけ異なることを確認する。よって、住所以外は前版数の１版から訂正がなされていないことを確認できる。

（９）原本処理部４１は、ステップST-V5、ステップST-V7、ステップST-V9で取得した検証結果をまとめ、出力する（ステップST-V10）。

以上の処理が完了すればログアウトし、登録文書検証処理を正常終了する。なお、以上の構成において、訂正ポリシ検証部３２ｂ、部分完全性情報検証部６０（部分識別情報検証部６１、部分訂正情報検証部６２）は本発明の登録文書検証部を構成している。

〔第２の局面〕
次に、本前提技術における第２の局面として、次の利用シーンを想定する。

Ａ地点で作成、訂正、登録された訂正済み契約文書をＢ地点に流通させる手段として本システムを利用する。この時、“生年月日”の情報は一部墨塗りを施すこととし、その他の情報は開示した形で提供するものとする。本利用シーンの登場人物として、第１の局面において、契約文書を作成、訂正を経て登録を行った「鈴木花子さん」、当該契約文書中の“生年月日”欄を一部墨塗りしてＢ地点の受信担当者に流通させる送信担当者の「佐藤太郎さん」、Ｂ地点において、Ａ地点の佐藤太郎さんから送信された当該契約文書一式を本システムに登録する受信担当者の「山田稔さん」の３名が登場する。また、「山田稔さん」は、公的な第三者証明を行うために（例えば、裁判所等へ証拠として提出するため）、Ａ地点から流通された契約文書を含む検証データを取得する。上記３名は、以下の４つのプロセスを行うものとする。

（訂正（一部墨塗り））
Ａ地点に位置する利用者である「鈴木花子さん」が契約文書を作成して登録し、訂正した後、送信担当者である「佐藤太郎さん」は、Ｂ地点に流通させるため、訂正処理を行い、Ａ地点に存在する本システムに登録を行う。ここでの訂正処理とは、前述した生年月日の情報を一部墨塗り処理し、その他の情報は開示した状態として登録することを意味する。

（流通（送信））
Ａ地点に位置する送信担当者である「佐藤太郎さん」は、契約文書一式をＢ地点の受信担当者「山田稔さん」に送信する。

（流通（受信））
Ｂ地点に位置する受信担当者である「山田稔さん」は、Ａ地点の送信担当者「佐藤太郎さん」から送信された契約文書一式を受信し、Ｂ地点に存在する本システムに登録を行う。

（第三者証明のための取り出し）
Ｂ地点に位置する「山田稔さん」は、公的な第三者証明を行うために（例えば、裁判所等へ証拠として提出するため）、Ａ地点から流通された契約文書一式（検証データ）の取り出しを行う。

図１５は、上記第２の局面における利用シーンをイメージした図である。図１５の利用シーンにおいて、本システムでは、佐藤太郎さんと山田稔さんに対して以下の機能を提供する。

（Ｂ）登録データ訂正機能（契約文書の一部墨塗り時に利用）
（Ｄ）登録データ流通（送信）機能（契約文書の送信時に利用）
（Ｅ）登録データ流通（受信）機能（契約文書の受信時に利用）
（Ｆ）検証データ取得機能（裁判所等に証拠データとして提出する場合に利用）

（Ｂ）の作用については、第１の局面における利用シーンで説明しているのでここでは割愛することとし、以下より、上記（Ｄ）〜（Ｆ）の各事象における作用について説明する。なお、（Ｂ）の訂正（一部墨塗り）時の原本保管部４２の状態は図１６のようになる。第３版が新たに登録されていることがわかり、第２版の部分識別情報と第３版の部分識別情報を比較すると、生年月日を一部墨塗り処理したことにより、“生年月日”と“プロフィールデータ”の内容のみ異なっていることを確認できる。また、本利用シーンの事前条件として、利用者９０（佐藤太郎さん、山田稔さん）は本電子文書完全性保証システムを利用できるよう事前登録されている。本利用シーンは、佐藤太郎さん、山田稔さんが当該システムにアクセス／ログインするところから始まる。

（Ｄ）契約文書の流通（送信）時
図１８は、登録文書流通（送信）処理の動作を示すフローチャートである。
この動作においては、まず、利用者９０（佐藤太郎さん）が図示しない画面中の「登録文書流通（送信）」メニューを選択すると、佐藤太郎さんが取り扱い可能な（送信可能な）「対象登録文書一覧」が表示される。次いで、佐藤太郎さんが画面中の「対象登録文書一覧」より、送信する契約文書を選択し確定すると、電子文書管理システム１０内の要求解析部２０に対して、登録文書取得依頼を発行する。これにより以下の処理が開始される。

（１）電子文書管理システム１０内の要求解析部２０は、登録文書取得依頼を受信し（ステップST-S1）、原本処理部４１に対して登録文書取得依頼を発行する（ステップST-S2）。

（２）原本処理部４１は、原本保管部４２に登録され保管されている当該契約文書一式を取り出し、佐藤太郎さんが確認できるよう契約文書の内容を画面に表示する。更に、原本処理部４１は、ポリシ保管部３１に登録され保管されている当該契約文書のポリシ情報も取り出す（ステップST-S3）。

この時、取り出される契約文書一式を図１７に示す。ここで注意すべきことは、契約文書-２版（本文）は開示されないことである。つまり、契約文書-２版の本文には、墨塗りされる前の情報が記載されているためである。また、同様に、一部黒塗り処理においては、訂正処理と共通化されるが、部分訂正情報への「訂正前情報」の記載は行われないものとする。契約文書-２版（本文）を除くこれらの情報を一体化した形で送信することで、墨塗りされる前の内容を秘匿したまま、Ｂ地点へ流通させ利用させることができ、更には、第三者証明が可能となる。当該文書群を用いた第三者証明の方法については、後述する。ここで、佐藤太郎さんは送信文書の内容を確認し確定すると、電子文書管理システム１０内の要求解析部２０に対して、登録文書流通（送信）依頼を発行する。

（３）電子文書管理システム１０内の要求解析部２０は、登録文書流通（送信）依頼を受信し（ステップST-S4）、原本処理部４１に対して登録文書流通（送信）依頼を発行する（ステップST-S5）。

（４）原本処理部４１は、送信する当該契約文書の検証プロセスを実行する（ステップST-S6）。ここでの検証プロセスは、第１の局面における利用シーンで説明しているので割愛する。

（５）原本処理部４１は、送信する当該契約文書の検証結果を取得し、検証が肯定（ＯＫ）の場合は、送信処理部７１へ送信依頼を発行する（ステップST-S7）。検証が否定（ＮＧ）の場合は、ログアウトし、登録文書流通（送信）処理を異常終了する。

（６）送信処理部７１は、当該契約文書一式を地点Ｂの電子文書管理システムに送信し、原本処理部４１へ送信結果を返す(ステップST-S8)。

以上の処理が完了すればログアウトし、登録文書流通（送信）処理を正常終了する。

（Ｅ）契約文書の受信時
図１９は、登録待ち文書の受信処理の動作を示すフローチャートである。

この処理に際しては、まず、利用者９０（山田稔さん）が図示しない画面中の「登録待ち文書の受信」メニューを選択すると、山田稔さんが取り扱い可能な（受信可能な）「対象登録待ち文書一覧」が表示される。山田稔さんが画面中の「対象登録待ち文書一覧」より、受信する契約文書を選択し確定すると、電子文書管理システム１０内の要求解析部２０に対して、登録待ち文書受信依頼を発行する。これより以下の処理（ステップ）が開始される。

（１）電子文書管理システム１０内の要求解析部２０は、登録待ち文書受信依頼を受信し、（ステップST-T1）、原本処理部４１に対して登録待ち文書受信依頼を発行する（ステップST-T2）。

（２）原本処理部４１は、受信処理部７２に対して、登録待ち文書受信依頼を発行する。

（３）受信処理部７２は、当該契約文書一式を本システムに受信し、原本処理部４１へ受信した当該契約文書一式を返す(ステップST-T3)。

（４）原本処理部４１は、受信処理部７２から取得した当該契約文書の検証プロセスを実行する（ステップST-T4）。ここでの検証プロセスは、第１の局面における利用シーンで説明しているので割愛する。

（５）原本処理部４１は、受信する当該契約文書の検証結果を取得し、検証が肯定（ＯＫ）の場合は、当該ポリシ情報をポリシ保管部３１へ、当該契約文書一式を原本保管部４２へ登録／保管する（ステップST-T5）。検証が否定（ＮＧ）の場合は、ログアウトし、登録待ち文書受信処理を異常終了する。

以上の処理が完了すればログアウトし、登録待ち文書受信処理を正常終了する。

（Ｆ）契約文書の取得時
図２０は、登録文書取得処理の動作を示すフローチャートである。

この処理に際しては、まず、利用者９０（山田稔さん）が図示しない画面中の「登録文書取得」メニューを選択すると、山田稔さんが取り扱い可能な（取得可能な）「対象登録文書一覧」が表示される。山田稔さんが画面中の「対象登録文書一覧」より、取得する契約文書を選択し確定すると、電子文書管理システム１０内の要求解析部２０に対して、登録文書取得依頼を発行する。これより以下の処理（ステップ）が開始される。

（１）電子文書管理システム１０内の要求解析部２０は、登録文書取得依頼を受信し、（ステップST-G1）、原本処理部４１に対して登録文書取得依頼を発行する（ステップST-G2）。

（２）原本処理部４１は、原本保管部４２に登録／保管されている当該文書を取得する。更に、原本処理部４１は、ポリシ保管部３１に登録／保管されている当該契約文書のポリシ情報も取り出す（ステップST-G3）。

以上の処理が完了すればログアウトし、登録文書取得処理を正常終了する。
本取得処理により、取り出される検証データ群は、図１７のようになる。当該検証データ群を裁判所等に証拠として提出した場合、本利用シーンにおいてどのような第三者証明が可能になるかを以下に説明する。

まず、図２１において、契約文書-３版（Ｄ３）と部分識別情報-２版（Ｓ２）と部分識別情報-３版（Ｓ３）を比較することで、以下の第三者証明が可能となる。

証明１：契約文書-３版（Ｄ３）は、鈴木花子さん自署による契約文書から作成されたことを確認可能である。
証明２：鈴木花子さんが記載した内容が改ざんされていないことを確認可能である。
証明３：前版より“生年月日”欄のみ変更されていることを確認可能である。同時に“生年月日”欄以外は前版より変更されていないことを確認可能である。

（証明１〜３における検証方法）
部分識別情報-２版（Ｓ２）と部分識別情報-３版（Ｓ３）を参照すると、部分識別情報-２版（Ｓ２）中の生年月日のハッシュ値は、“yz012345”であり、部分識別情報-３版（Ｓ３）中の生年月日のハッシュ値は、“qwertyui”となっており生年月日が互いに異なっている。またこれに伴ってプロフィールデータも異なったものとなっているが、それらを除いた他の項目に関するハッシュ値は、すべて同一となっている。

これにより、第３版は第２版と比べて“生年月日”及び“プロフィールデータ”欄のみが変更されていることを確認できる。同時に、“生年月日”及び“プロフィールデータ”欄以外は変更がないことを確認できる。更に、部分識別情報-第２版（Ｓ２）と部分識別情報-第３版（Ｓ３）にはそれぞれ鈴木花子さんと、佐藤太郎さんの署名が施されており、検証も可能である。よって、証明３を立証できる。また、上記比較をもって、変更箇所以外は確かに鈴木花子さんの署名が施されているため、証明１、２が立証できる。

なお、本前提技術では部分識別情報に“プロフィールデータ”を含めるようにしたが、この“プロフィールデータ”についての部分識別情報を含めないようにすれば、“生年月日”のみの部分識別情報が異なるのみとなる。

次に、図２２において、契約文書-３版（Ｄ３）と部分識別情報-３版（Ｓ３）を比較することで、以下の第三者証明が可能となる。

証明４：契約文書-３版（Ｄ３）の内容は本システムに登録されてから改ざんされていないことを確認可能である。

（証明４における検証方法）
契約文書-３版（Ｄ３）から部分識別情報を再生成し、部分識別情報-３版（Ｓ３）と比較することで、証明４を立証できる。具体的には、例えば、契約文書-３版（Ｄ３）中の名前要素より、文字列“鈴木花子”と、文字列“123”を連結し、文字列“鈴木花子123”からハッシュ値を生成。部分識別情報-３版（Ｓ３）中の名前から、“abcdefgh”を取り出し、生成したハッシュ値と比較して同一であるかを判断する。以下、名前要素以外も同様の処理・比較を行い、すべて同一であることが確認された場合、契約文書-３版（Ｄ３）は本システムに登録されてから改ざんされていないことを確認できる。よって、証明４が立証できる。

更に、図２３において、契約文書-３版（Ｄ３）と部分訂正情報-３版（Ｔ３）を比較することで、以下の第三者証明が可能となる。

証明５：部分訂正情報-３版（Ｔ３）を確認することで、契約文書-３版（Ｄ３）は前版より“生年月日”が一部墨塗りされた状態で送られてきたことを確認可能である。更に、訂正（一部墨塗り）した日時や訂正者は「佐藤太郎さん」であることも証明可能である。

（証明５における検証方法）
佐藤太郎さんの署名の付いた部分訂正情報-３版（Ｔ３）中の訂正日時、訂正者、訂正箇所、訂正コード、訂正理由を参照することで証明５を立証できる。

（前提技術２）
次に、本発明の前提技術２として、第２の適用分野による利用シーンについて説明する。上述したように、ここでは、XML文書に特化した部分改ざん検出のための原本管理方法と検証方法について説明する。

まず、本利用シーンでは、申請者と保険会社と金融機関の三者間において流通する電子データとして、“保険契約申込書”を採用し、本データの取り扱いを行う「保険契約申込サービス」を考える。図２４は本システムモデルの形態を表している。上述の三者は上記構成にて提供・運営されている「保険契約申込サービス」（専用Webサーバ／ＡＳＰ）へアクセスすることで本システムが利用可能となる。この「保険契約申込サービス」は、前提として信頼のおける第三者機関が運営することを想定し、本機関を通じて流通するものを考える。

ここでは、申請者（鈴木花子さん）がインターネット上に設置／提供されている本システムを利用して、保険契約申込を行い、保険会社が受付、金融機関が当該契約の決済処理を行う場面を想定する。文書の流れは以下のステップ（１）〜（５）の通りである。なお、事前準備として、「保険契約申込サービス」には、申請者（鈴木花子さん）、保険会社担当者、金融機関担当者が利用できるよう、三者は既にユーザ登録されているものとする。

（１）申請者（鈴木花子さん）は、「保険契約申込サービス」にWebブラウザからログインし（この時、本人確認の方法として、ID＋パスワードの組み合わせや、生体認証等が考えられる）、保険契約申込書を第１版として新規作成／登録を行うことで、本システム内に設置された原本保管装置（原本保管部４２）に格納される。確定／送信を行うことで、申込書データ（第１版）が保険会社に送信される（図２４中Ｓ１部分）。

（２）保険会社担当者は、例えば電子メールの受信を用いて確認する等の何らかの手段で（定期確認のために本システムへアクセスするようにしても良い）申請者（鈴木花子さん）からの保険契約申込書（第１版）を本システムから取得し、内容を確認し、検証を行う。

（３）保険会社担当者は、保険契約に伴う決済処理を行うべく、金融機関に対して与信情報を送信する。その前準備として、金融機関にとって与信情報に不必要な情報（例えば、保険コース等の契約情報）は、一部秘匿（墨塗り）処理が施され、保険契約申込書を第２版として更新／登録を行うことで、本システム内に設置された原本保管装置（原本保管部４２）に格納される。そして、確定／送信を行うことで、申込書データ（第２版）が金融機関に送信される（図２４中Ｓ２）部分）。

（４）次に、金融機関担当者は、電子メールの受信等、上述したと同じ手段（上記保険会社担当者と同様の手段）を用いて保険会社からの保険契約申込書（第２版）を本システムから取得し、内容を確認し、検証を行う。

（５）金融機関担当者は、申請者（鈴木花子さん）の保険契約に伴う決済処理結果を保険会社に対して送信する。その前準備として、金融機関担当者は、与信確認情報を追加し、保険契約申込書を第３版として更新／登録を行うことで、本システム内に設置された原本保管装置（原本保管部４２）に格納される。確定／送信を行うことで、申込書データ（第３版）が保険会社に送信される（図２４中Ｓ３部分）。

次に、上記各ステップ（１）〜（５）の過程で保険契約申込書が原本保管装置内（原本保管部４２）でどのように原本管理されていくか、また、各時点においてどのような検証を行うことで、どのような内容を第三者に証明できるかについて説明する。なお、本システムがどのような手段、機能を経て作用するかは、前提技術１で説明した第１の適用分野における利用シーンで具体的に説明しているので、ここでは割愛する。

（１）保険契約申込書（第１版）作成
本ステップおいて新規に作成される保険契約申込書（XMLデータ）の例を図２５に示す。前提技術１で説明した第１の適用分野においては、基本概念を説明するため、フラットな構造を持つ（親要素が１つで、その配下に複数の子要素が並んでいる形態）、ごくシンプルなXMLデータ（図５参照）を例として採り上げた。本適用分野の保険契約申込書については、図２５に示すような複雑な階層構造を持つXMLデータを対象とする。図２５は、保険契約申込書（第１版）の本文をXMLデータで表現した一例を示している。

図２５に示すXMLデータ例では、＜保険契約申込書＞をルート要素とし、その配下に、＜契約者＞、＜指定預金口座＞、＜契約情報＞の３つの親要素が配置されている。各親要素の配下には、子要素がそれぞれ配置されている。本XMLデータをツリーモデル化すると図２６のようになる。図２６は、保険契約申込書（第１版）のＸＭＬデータモデルを示す図である。当該保険契約申込書は、ツリー構造を持つ一種の階層構造型文書と言える。

次に、本保険契約申込書データに対する部分識別情報の生成方法について説明する。図２７は、保険契約申込書（第１版）作成時に生成された部分識別情報のＸＭＬデータでの表現例を示している。

図２７に示すように、第１版（初版）に関しては、すべての子要素に対してハッシュ情報を生成、記録するのと同時に、親要素（この例は、＜保険契約申込書＞、＜契約者＞、＜指定預金口座＞、＜契約情報＞、＜名前＞に該当する）のハッシュ情報も生成、記録している。

これは、次回（第２版）以降に発生する文書更新を考慮し、変更のない親と子の集合群、例えば図２８に示すように、｛＜姓＞、＜名＞（ともに親要素は＜名前＞）、＜住所＞、＜電話番号＞｝全てに変更が生じない場合は、その親要素である＜契約者＞のハッシュ情報（=“7ed6c”）のみを記録すればよい。図２８は、「契約者」を抽出したＸＭＬデータモデルを示す図である。よって、このような記録管理を行えば、事後、＜契約者＞のハッシュ情報のみ完全性を検証すればよく、｛＜姓＞、＜名＞（ともに親要素は＜名前＞）、＜住所＞、＜電話番号＞｝の計５つの検証については省略できることになる。

したがって、次回（第２版）の検証時には、｛＜姓＞、＜名＞、＜名前＞、＜住所＞、＜電話番号＞｝の全ての検証データを保持・管理するよりも遥かにデータ量と検証コストの削減が図れる。また、本例は同一要素名が存在しない場合を想定しているが、同一要素名が出現する場合を想定し、Xpath機能等を用いて対応する要素のハッシュ情報を識別・管理する仕組みは当然必要である。

（２）保険契約申込書（第１版）取得／検証
図２９は保険契約申込書（第１版）作成時の原本保管状態を示している。図２９で示す通り、保険会社担当者は、第１版の保険契約申込書（本文）と部分識別情報を取得し、検証を行う。この時、当該検証データ群を使うことで、申請者（鈴木花子さん）が作成したものかどうか、申込書自身に改ざんがないかを確認できる。なお、第１版に関する具体的な検証方法については、前提技術１における第１の適用分野にて作用を説明しているので、ここでは割愛する。

（３）保険契約申込書（第２版）作成
第２版の作成は、保険会社担当者が申請者（鈴木花子さん）によって作成された保険契約申込書（第１版）を基に更新を行う。更新作業として契約者情報の一部秘匿（墨塗り）を行う。図３０は、更新された保険契約申込書（第２版）の本文のXMLデータによる表現例を示している。

図３０中のＴＺ部分は、今回変更された箇所を示している。この時、当該本文に付与される電子署名は、申請者（鈴木花子さん）のものではなく、保険会社のものであることは言うまでもない。これは、一般的な電子署名方式を利用することで、その文書は誰によって作成されたか（本人性）と、事後、文書自身が改ざんされていないこと（非改ざん性）を保証している。

本発明の前提技術における特徴は、文書全体に対する検証は、一般的な電子署名方式を用いることで安全性を確保し、文書中の部分保証については、部分識別情報を生成し、本文とは別に管理することによって、「誰が」、「どの部分を」、「どのように変更したか」に対して責任範囲を明確化している。

図３０中のＴＺ部分で示すように、変更されたのは、＜保険コース＞と＜保険金額＞で、その内容はアスタリスク（＊＊＊＊＊）で表現されており、一部秘匿（墨塗り）された状態であることが分かる。もちろん、前提技術１における第１の適用分野で述べたように、変更箇所｛＜保険コース＞、＜保険金額＞（ともに親要素は＜契約情報＞）｝に対しては、R属性部分が変更になっていることが分かる。

同様に、＜契約情報＞の親要素、かつ、本XMLデータのルート要素である＜保険契約申込書＞についてもR属性が変更になっている。文書中にR属性を付与し、また、変更箇所に対してR属性を変えている理由については、上述した第１の適用分野で具体的に説明しているので、ここでの説明は割愛する。

次に、本保険契約申込書データに対する部分識別情報の生成方法について説明する。図３１は、保険契約申込書（第２版）作成時に生成された部分識別情報のＸＭＬデータによる表現例を示している。

図３１に示すとおり、第２版以降に関しては、以下の手法に従って部分識別情報を生成している。

まず、本例では親要素である＜契約者＞と＜指定預金口座＞に変更がない。これは、必然的に＜契約者＞と＜指定預金口座＞の両配下の子要素は全て変更がなかったことを意味している。そのため、第２版の部分識別情報には前述のとおり親要素＜契約者＞と＜指定預金口座＞のハッシュ情報のみ記録している（図３１中、Ｖ２−１部分）。この部分については、第１版の部分識別情報から当該部分をコピーしてもよいし、再度、第２版の保険契約申込書本文から当該部分のハッシュ情報を生成しても構わない。

ただし、当該情報の生成コストが削減できるという意味では、前者の方法での記録を選択した方が適切であることは言うまでもない。

次に今回、＜保険コース＞と＜保険金額＞が変更になったことにより、親要素のハッシュ情報に影響を与えるものがある。それは、当該親要素である＜契約情報＞と＜保険契約申込書＞である。ここでは、これら親要素のハッシュ情報の再生成を行い、記録している（図３１中、Ｖ２−２部分）。この部分は、次回更新（第３版）時に当該箇所に変更がない場合に利用することを考慮し、記録している。

これにより、次回以降の更新においても、非変更箇所に対するハッシュ情報の生成コストを削減できる。また、＜保険契約申込書＞は、いわゆる、ルート要素に相当する。ルート要素の特徴として、その配下の親要素／子要素がひとつでも変更になると、ルート要素（＜保険契約申込書＞）のハッシュ情報が変わってしまう。ここでは、より検証品質を向上させるため、ルート要素（＜保険契約申込書＞）のハッシュ情報を持つことで当該情報が改ざんされていないことを事後、容易に確認できるよう記録している。

ただし、文書全体に付与されている電子署名からも同様な検証が行えるため、ルート要素（＜保険契約申込書＞）のハッシュ情報に関しては必ずしも記録が必要ということではない。また、今回変更となった＜保険コース＞と＜保険金額＞に対するハッシュ情報の再生成、記録は、言うまでもなく部分変更箇所を事後特定するために必要である（図３１中、Ｖ２−３部分）。

図３２は保険契約申込書（第２版）作成時の原本保管状態を示している。図３２中、Ｔ１部分は変更箇所を示しており、Ｔ２部分は、今回変更がなかった箇所（子要素）を示している。ここでは、当該子要素に対するハッシュ情報は記録されず、親要素の＜契約者＞と＜指定預金口座＞のハッシュ情報が記録されていることがわかる。

なお、第２の適用分野による利用シーンでは、部分訂正情報の生成、記録の説明については直接関係しないため、特に触れていない。部分訂正情報の生成、記録に関しては第１の適用分野による利用シーンにて具体的に説明しているので、そちらを参照されたい。

（４）保険契約申込書（第２版）取得／検証
図３２で示す通り、金融機関担当者が取得するのは、第２版の保険契約申込書（本文）と部分識別情報、第１版の部分識別情報である。この時、第１版の保険契約申込書（本文）は取得、閲覧できないことは容易に推測できる。なぜなら、第１版の保険契約申込書（本文）は、一部秘匿（墨塗り）する前の＜保険コース＞と＜保険金額＞の内容を含んでいるからであり、これを提示してしまうと情報漏洩となる。よって、版数管理による原本管理方法の他に、各時点（版数）の文書内容によって閲覧可能者と閲覧不能者をアクセス制御できる仕組みが必要になることは言うまでもない。

ただし、この要件は本利用シーンの特徴のひとつであるＡＳＰ内で流通データを一元管理している場合に適用可能であり、適宜、電子メール等で直接データを送信する形態では、単に送信データを選択・限定すればよい。

上記の条件のもとで、金融機関担当者が閲覧可能な検証データ群は、「保険契約申込書（第２版）-本文」、「部分識別情報（第１版）」、「部分識別情報（第２版）」であることがわかる。図３３はその内容を示している。図３３は、金融機関担当者が閲覧可能な検証データ群を示す図である。

図３３で示す検証データ群を使って以下のような検証を行うことが可能となる。最初に各検証データの電子署名を検証し、各検証データ自身に改ざんがないかどうか確認、検証を行う。

各検証データに改ざんがないことが確認されると、次に、保険契約申込書（第２版）と部分識別情報（２版）を用いて、保険契約申込書（第２版）の内容自身が確認され、また、部分的に差し替わっていないかどうかが確認される。その手段として、まず保険契約申込書（第２版）の各要素部分からハッシュ情報を生成し、部分識別情報（２版）に記録されている当該部分のハッシュ情報と比較して同一かどうかを判定する。

全ての要素部分の完全性が確認できると、次に前版の部分識別情報（第１版）との比較を行う。その手段として、まず、ＯＤ１部分に関しては変更がないため、該当するハッシュ情報は、ＶＤ１−２部分で示す親要素のみの記録となっている。よって、部分識別情報（１版）の該当ハッシュ情報（ＶＤ１−１）と、部分識別情報（２版）の該当ハッシュ情報（ＶＤ１−２）を比較すれば当該箇所は変更がないことを確認できる。

この例では、＜契約者＞のハッシュ情報はともに“7ed6c”、＜指定預金口座＞のハッシュ情報はともに“8c320”であり変更がないことを確認できる。したがって、親要素である＜契約者＞の検証１回完了させれば、＜契約者＞の子要素である｛＜姓＞、＜名＞（ともに親要素は＜名前＞）、＜住所＞、＜電話番号＞｝の５箇所（親要素の＜名前＞の検証を含まない場合は４箇所）については検証を省略できる。

同様に、親要素である＜指定預金口座＞の検証１回完了させれば、＜指定預金口座＞の子要素である｛＜金融機関名＞、＜口座番号＞、＜口座名義人＞｝の３箇所については検証を省略できる。よって、当該親要素２回の検証により計８回分の検証を満たすことができ、この例では、７５％の検証コストを削減できたと言える。また、当該８要素分のハッシュ情報の記録が、２要素分の記録で済むため、データ量に関しても同様に７５％削減できたと言える。

逆に、ＯＤ２部分に関しては前版から変更があるため、該当するハッシュ情報はＶＤ２−２部分で示すとおり、子要素も記録している。よって、部分識別情報（１版）の該当ハッシュ情報（ＶＤ２−１）と、部分識別情報（２版）の該当ハッシュ情報（ＶＤ２−２）を比較すれば当該箇所は変更されていることを確認できる。

この例では、＜保険コース＞のハッシュ情報は、１版が“abfd3”、２版が“d2419”で異なり、＜保険金額＞のハッシュ情報は、１版が“623a1”、２版が“f56da”で異なるため、当該箇所は変更されていることを確認できる。

（５）保険契約申込書（第３版）作成
第３版の作成は、金融機関担当者が保険会社担当者によって作成した保険契約申込書（第２版）を基に更新を行う。更新作業として与信確認情報の追加を行う。

図３４は、更新された保険契約申込書（第３版）の本文のXMLデータによる表現例を示している。図３４中のＫＺ部分は、今回追加された箇所である。同様に、この時、当該本文に付与される電子署名は、保険会社担当者のものではなく、金融機関担当者のものである。

図３４中のＫＺ部分で示すように、追加されたのは、＜与信結果＞と＜与信NO＞である。

次に、本保険契約申込書データに対する部分識別情報の生成方法について説明する。図３５は、保険契約申込書（第３版）作成時に生成された部分識別情報のＸＭＬデータによる表現例を示している。

図３５に示すとおり、第２版同様、第３版においても以下の手法に従って部分識別情報を生成している。

まず、本例では親要素である＜契約者＞、＜指定預金口座＞、＜契約情報＞に変更がなかった。これは、必然的に＜契約者＞、＜指定預金口座＞、＜契約情報＞の各配下の子要素は全て変更がなかったことを意味している。そのため、第３版の部分識別情報には前述のとおり親要素＜契約者＞、＜指定預金口座＞、＜契約情報＞のハッシュ情報のみ記録している（図３５中、Ｖ３−１部分）。

前回（第２版）の更新では、＜契約情報＞配下の子要素＜保険コース＞と＜保険金額＞が変更されていたが、今回は変更がなかった。ここで、前回第２版で生成した部分識別情報の中に、第２版の時点の＜契約情報＞のハッシュ情報を記録していたことにより、第３版の生成にて有効活用できていることは容易に推測できる。これは、第２版の部分識別情報生成時に予測した“次回以降の更新においても非変更箇所に対するハッシュ情報の生成コストを削減できる”という事が実現できたことを意味する。

これに習って、今回＜与信結果＞と＜与信NO＞が追加になったことにより、その親要素である＜金融与信情報＞のハッシュ情報も記録している（図３５中、Ｖ３−２部分）。これは、次回更新（第４版）時に当該箇所に変更がない場合に利用することを考慮してのことである。

また、当該追加に伴い、必然的にルート要素である＜保険契約申込書＞も再生成、記録される（図３５中、Ｖ３−２部分）。更に、今回追加となった＜与信結果＞と＜与信NO＞に対するハッシュ情報も生成、記録は、言うまでもなく部分変更箇所を事後特定するために必要である（図３５中、Ｖ３−３部分）。

図３６は、保険契約申込書（第３版）作成時の原本保管状態を示している。図３６中、Ｋ１部分は今回追加箇所を示しており、Ｋ２部分は、今回変更がなかった箇所（子要素）を示している。ここでは、当該子要素に対するハッシュ情報は記録されず、親要素の＜契約情報＞のハッシュ情報のみ記録されていることがわかる。

以上の説明では、ステップ（１）〜（５）の各ステップにおいて保険契約申込書が原本保管装置内（原本保管部４２）でどのように原本管理されていくか、また、各時点においてどのような検証を行うことで、どのような内容を第三者に証明できるかについて説明した。このように、ステップ（１）〜（５）で示した文書作成時／更新時における部分識別情報の生成方法、原本管理方法、検証方法を行えば、複雑な階層構造を持つXMLデータの部分改ざん検出機能が容易に実現できる。よって、更新時に変更のない箇所においても子要素全てを管理する方式と比べると、飛躍的に検証コストの削減が見込めるし、転送・保存データ量も削減できることが大きい。

また、更新時に変更のない箇所においても子要素全てを管理する方式では、一部の版数のみの検証にしか使えなかった。例えば、第三者に証明を依頼するために第３版を提示する場合、その直近の前版（第２版）との相違点しか検証できなかった。もちろん、第１版からの変更点を検証することも可能であるが、全要素を含む部分識別情報を提示する必要があり、転送・保存データ量もその分増大し、検証処理にも時間を要していた。

これに対して、複雑な階層構造を持つXMLデータの部分改ざん検出機能を利用すれば、検証に必要な部分識別情報を最小限の内容で記録・管理することが可能で、第１版の部分識別情報をオリジナル（ベース）として第２版、第３版・・・第Ｎ版の組み合わせを最小限の転送・保存データ量で流通・検証することが可能になる。これにより、全版数の訂正事象の履歴管理が各エンティティ（地点）においてより簡単に、かつ、低コストで検証可能となる。

更には、「いつ、誰が、どの時点で、どの部分を、どのように訂正したか」についての履歴追跡・証明も可能となるところが大きい。

また、図３６の第３版時における保険契約申込書の保管状態の例では、各版の部分識別情報はそれぞれ別ファイルとして管理されているが、複数エンティティ間で検証データ群を転々持ち歩き、各地点において履歴追跡・証明を行うためのより効率的な手段として、各版の部分識別情報を連結し、１つのファイルにまとめる方法も有り得る。

このように連結管理された部分識別情報は特に版数における時系列性が確保でき、かつ、各版数に対する作成者（本人性）を識別できることも必要である。また、この連結管理の方法として、Xlink機能を用いて実現する方法も有り得る。

図３７、図３８は１つのファイルとして連結管理された様子を示している。図３７は、第２版を検証する際に必要な全部分識別情報を連結管理している様子を、図３８は、第３版を検証する際に必要な全部分識別情報を連結管理している様子を示している。

各版の部分識別情報は、それぞれ作成者による電子署名が施されている。電子署名の付与方法としては、XML部分署名等を用いれば容易に実現可能である。本利用シーンでは、第１版は申請者（鈴木花子さん）、第２版は保険会社担当者、第３版は金融機関担当者がそれぞれ電子署名を付与している。そのため、各部分識別情報の作成者の本人性、並びに、データ自身の完全性は容易に検証可能である。

図３７と図３８を見比べればわかる通り、たとえ保険契約申込書の本文が上書きされたとしても、部分識別情報という形で履歴管理を行えば、部分訂正箇所とその訂正内容を第三者的に証明できるようになる。言い換えれば、部分識別情報の内容は、各版のスナップショットであると言える。このような形態で検証データ群を複数エンティティ間で転々持ち歩けば、一部秘匿された情報の漏洩を防止しつつ、各地点において部分箇所の履歴追跡・証明が容易に実現可能となる。

以上の利用シーンでは、前版から訂正された箇所については、子要素とその属する親要素を記録し、親要素に属する全ての子要素に訂正がない箇所については、当該親要素のみ記録する方式（以降、方式１と定義する）について説明した。

更に、方式１と比べて、転送・保存データ量を削減することを目的として、前版からの訂正された箇所のみ、子要素とその属する親要素を記録する、いわゆる、純粋に差分のみ管理する方式も有り得る。次に、この差分のみ管理する方式（以降、方式２と定義する）について説明する。

方式１の手段に従えば、保険契約申込書（第２版）-本文（図３０）の部分識別情報の管理方法は、図３１のようになった。一方、方式２を用いて記録すると図３９のようになる。図３９は、方式２を用いて部分識別情報（第２版）をXMLデータで表現した例を示す図である。

図３９に示す通り、方式１では、非変更箇所の＜契約者＞と＜指定預金口座＞は記録されていたが、今回の方式では、その部分は省略されており、転送・保存データ量が方式１と比べてより削減できることがわかる。

図４０は方式２を用いた保険契約申込書（第３版）作成時の原本保管状態を示している。

次に、今まで説明してきた部分識別情報の生成に関する以下３方式による転送・保存データ量と検証処理についてコスト評価・分析を行う。ここで方式０は、第１の適用分野の利用シーンで説明した方式としている。

方式０（比較対象）は、変更箇所、および、非変更箇所全てのハッシュ情報を記録する方式である。方式１は、前版から訂正された箇所については、子要素とその属する親要素を記録し、親要素に属する全ての子要素に訂正がない箇所については、当該親要素のみ記録する方式である（第２の適用分野の利用シーン例で採用）。方式２は、前版からの訂正された箇所のみ、子要素とその属する親要素を記録する、いわゆる、純粋に差分のみ管理する方式である。

ここでは、図４１で示すような簡単なXMLデータ例を用いて解析を行う。図４１は、評価・分析のためのXMLデータ例を示す図である。

本評価・分析では、第２版への更新作業として、＜保険コース＞のみの訂正を考える。図４２は、＜保険コース＞の内容が、“ＡＡＡ”から“ＢＢＢ”に訂正されている様子を示している。すなわち、図４２は、評価・分析用XMLデータの更新を示す図である。

まず、初めに、比較対象（方式０）について、転送・保存データ量と検証回数の解析を行う。図４３は、方式０におけるデータ管理方法と検証処理の様子を示している。即ち図４３は、方式０による部分識別情報の生成と検証を示す図である。検証Ａ１では、保険契約申込書（第２版）と部分識別情報（２版）を用いて、保険契約申込書（第２版）の内容自身が、また、部分的に差し替わっていないかを確認している。その手段として、まず保険契約申込書（第２版）の各要素部分からハッシュ情報を生成し、部分識別情報（２版）に記録されている当該部分のハッシュ情報と比較して同一かどうかを判定している。

検証Ａ２では、前版の部分識別情報（第１版）と部分識別情報（２版）の比較を行うことで、変更箇所の特定と、変更箇所以外の不変確認を行っている。

本方式０における転送・保存データ量と検証回数をまとめると以下のようになる。まず、部分識別情報（第２版）の転送・保存データ量は、単純に行数で表現すると、７行となる。

この方式では、変更箇所、および、非変更箇所全てのハッシュ情報を記録するため、第１版、第２版ともにデータ量は７行ということになる。なお、この例では＜部分識別情報＞は当該ファイルのルート要素なのでカウントしていない。次に、検証回数においては、まず、検証Ａ１のステップでは７回の検証を、検証Ａ２のステップでは同じく７回の検証を行っており、７回＋７回＝計１４回の検証コストがかかることになる。

次に、方式１について、転送・保存データ量と検証回数の解析を行う。図４４は、方式１におけるデータ管理方法と検証処理の様子を示している。即ち図４４は、方式１による部分識別情報の生成と検証を示す図である。

同様に、本方式１における転送・保存データ量と検証回数をまとめると以下のようになる。まず、部分識別情報（第２版）の転送・保存データ量は、３行となる。この方式では、前版から訂正された箇所については、子要素とその属する親要素を記録し、親要素に属する全ての子要素に訂正がない箇所については、当該親要素のみ記録するため、方式０と比べて第１版、第２版ともにデータ量に差が出てくる。

次に、検証回数においては、まず、検証Ｂ１のステップでは３回の検証を、検証Ｂ２のステップでは同じく３回の検証を行っており、３回＋３回＝計６回の検証コストがかかることになる。即ち、＜名前＞、＜姓＞、＜名＞、＜住所＞の４箇所に関しては、これらの親要素である＜契約者＞の検証１回で満たしているため、省略できることとなる。

次に、方式２について、転送・保存データ量と検証回数の解析を行う。図４５は、方式２におけるデータ管理方法と検証処理の様子を示している。即ち、図４５は、方式２による部分識別情報の生成と検証を示す図である。

同様に、本方式２における転送・保存データ量と検証回数をまとめると以下のようになる。まず、部分識別情報（第２版）の転送・保存データ量は、２行となる。この方式では、前版からの訂正された箇所のみ、子要素とその属する親要素を記録するため、方式１同様第１版、第２版ともにデータ量に差が出てくる。

次に、検証回数においては、まず、検証Ｃ１のステップでは２回の検証を、検証Ｃ２のステップでは同じく２回の検証を行っており、計４回の検証コストがかかることになる。

本方式では、訂正箇所のみ記録しているため、非訂正箇所に当たる＜契約者＞、＜名前＞、＜姓＞、＜名＞、＜住所＞について前版と変わっていないことの検証が行えない。なぜなら、検証Ｃ１において、保険契約申込書（第２版）と部分識別情報（２版）を用いて、保険契約申込書（第２版）の内容自身が、また、部分的に差し替わっていないかを確認しているが、転送・保存データ量を最優先に考慮しているため、当該箇所については検証する材料を持っていなかった。

よって、保険契約申込書（第２版）から当該箇所のハッシュ情報を生成し、前版の部分識別情報（第１版）の当該箇所と検証を行わなければならない。この検証は、図４５中、検証Ｃ３のステップで行っており、検証Ｃ３のステップにおいては５回の検証コストがかかることになる。よって、本方式による検証コストは検証Ｃ１〜Ｃ３を累計２回＋２回＋５回＝９回ということなる。

上記方式０における解析結果を対象として、方式１と方式２を比較してみる。図４６は、その方式別解析結果を表している。本解析結果からわかる通り、方式１、方式２ともに、比較対象（方式０）に比べて転送・保存データ量、検証処理ともに削減していることが分かり、部分識別情報の生成・管理には、方式１、もしくは、方式２を採用した方が良いと言える。また、方式１と方式２の比較では、方式２の転送・保存データ量は、方式１よりも少なくて済むが、それだけ検証処理に時間を要している。それに比べ方式１では、転送・保存データ量、検証処理ともにバランスよくコスト削減できていることが分かる。

この結果は方式１、方式２のどちらの方式が良いかではなく、文書階層構造の度合いによって最適な方式を選択すべきである。

図４７は、方式別解析結果におけるバブルチャートを示している。

以上、本発明の前提技術によれば、従来の技術及びその単純な組み合わせでは不可能であった下記の要件を満足することが可能となる。（１）電子文書の訂正箇所を特定、並びに、訂正箇所以外は変更されていないことを確認することが可能である。（２）複数エンティティ間で訂正済み電子文書を転々流通させ、かつ、各エンティティにおいて訂正・追加等を行う場合、各時点において電子文書の完全性・原本性を保証（第三者証明）することが可能である。（３）本システム内に保存・管理されている全ての版数の電子文書を取り出さなくても、一部墨塗りされた状態や、一部の版のみを用いた第三者証明や流通を行うことが可能である。

以上、本発明の前提技術について、文書情報として契約文書等の原本情報の管理に例をとって説明したが、本前提技術は文書に関する履歴の正当な証明、検証等にも幅広く適用され得るものである。また、ポリシ情報については、登録検証のときと、訂正検証のときで同じポリシ情報を用いたが、異なるポリシ情報がそれぞれ用意されていても良いことは言うまでもない。

（前提技術のまとめ）
本実施の形態は、上述した前提技術１、２で説明した技術に対し、さらに保管データ量の削減を図る改良技術について説明するものであるが、その説明の便宜のために前提技術１，２を以下にまとめておく。なお、以下において、前提技術及び本実施の形態における黒塗り署名技術をPIAT署名技術と呼ぶこととする。

黒塗り署名に登場するエンティティは署名者(signer)、墨塗り者(sanitizer)、検証者(verifier)の三者で、署名者はオリジナル文書に対する署名を生成し、墨塗り者はオリジナル(または墨塗り)文書から追加非開示する部分文書を定めて墨塗り文書を作成し、検証者は署名検証により開示部分の完全性を確認するというものであった。

前提技術１では、文書をブロックに分割し、それぞれのブロックについてハッシュ関数を利用して特徴情報を抽出した。そして、それらの特徴情報を集めた情報を部分識別情報と呼び、この部分識別情報に電子署名を施した。これを第１版とする。

第１版に対する追加・訂正・削除（黒塗り）では、文書を追加・訂正・削除した（黒塗り）後、署名作成時と同様に部分識別情報とその電子署名を作成する。また誰が何処を変更したかを部分訂正情報として保存する。これを第２版とする。

PIAT署名確認では、第１版の部分識別情報と第２版の文書、部分識別情報、部分訂正情報を用いて検証を行う。第１版と第２版の部分識別情報を比較することで、これらの版での変更箇所を識別できる。また部分識別情報の電子署名から、部分識別情報の完全性検証と作成及び変更が誰によって行われたかの保証ができる。さらに文書と部分識別情報から文書の完全性が検証・保証できる。

前提技術２では、前提技術１の改良を行った。前提技術１では、各版において全てのブロックのハッシュ値を部分識別情報として保持する必要があるため、部分識別情報の情報量が膨大になる。前提技術２では、第２版以降の部分識別情報を変更部分のみ保存することによって、部分識別情報の情報量を削減した。またXMLなどの構造化文書の場合はその構造に着目して、効率的に変更部分の保存を行う方法を提案している。

これら前提技術において、署名の対象となる文書はn 個の部分文書から構成される列(M1, . . . ,Mn)であるとする。乱数は適当な(疑似)乱数生成機によって生成され、関数H()は安全な任意のハッシュ関数とする。さらに関数Sign_SK()は安全な(つまり適応的選択文書攻撃に対して存在的偽造不可能な)任意の署名方式の署名生成関数とする。

前提技術１におけるPIAT 署名の処理概要を下記（Algorithm 1）に示す。ここで墨塗り者の人数はm 人であるとする。PIAT 署名における署名者は、乱数を添付した各部分文書のハッシュ値の集合(これを部分識別情報と呼ぶ) h(0)に対する署名σ(0) を生成・出力する。原本（オリジナル文書）と部分識別情報・署名のペアを受け取った最初の墨塗り者は、開示する部分文書については内容をそのままに保持し、非開示する部分文書については、部分文書と対応する乱数を適当なデータ列(例えばM =“XXXX”) と新しい乱数に置き換え、新しいハッシュ値を求める。

このようにして新しい部分識別情報h(1)と墨塗り者による署名σ(1) を生成し、変更後の墨塗り文書および２組の部分識別情報・署名ペア(h(0), σ(0)), (h(1), σ(1))を出力する。墨塗り者は部分識別情報を比較することによってどの部分文書が墨塗りされているかを識別できる。

同様にj 番目(j = 1, . . . ,m) の墨塗り者はj-1 番目の墨塗り者が出力した墨塗り文書と、j 組の部分識別情報・署名ペア(h(0), σ(0)), . . . , (h(j-1), σ(j-1)) を入力とする。このとき部分識別情報h(0) とh(j-1) を比較することで、j 番目の墨塗り者はどの部分文書が墨塗りされているか識別できる。そして新しい部分識別情報・署名(h(j), σ(j))を生成し、変更後の墨塗り文書とj + 1 組の部分識別情報・署名ペア(h(0), σ(0)), . . . , (h(j-1), σ(j-1)), (h(j), σ(j))を出力する(図４８)。

検証者は、最後の(m 番目の) 墨塗り者が出力した墨塗り文書[M (m)]とm + 1 個の部分識別情報・署名ペア(h(0), σ(0)), . . . , (h(m), σ(m)) を受け取る。まず検証者は墨塗り文書と各署名を検証し、墨塗り文書と部分識別情報の完全性を確認する。次に部分識別情報h(0) とh(m) を比較して墨塗り部分文書を特定した上で、墨塗りされた部分文書についてhi(0) = . . . = hi(j-1) ≠hi(j) = . . . =hi(m)となるようなj を求める。このようなj が求まった場合には、この部分文書がj 番目の墨塗り者によって墨塗りされたことが特定できるし、求まらなかった場合には、不正な墨塗りがなされていたこと、さらには誰が不正墨塗りを行ったかが識別できる。

（Algorithm 1）
（署名者による署名）
（Ｓ１）契約文書であるオリジナル文書(M1, . . . ,Mn)が入力される。
（Ｓ２）各部分文書Mi (i = 1, . . . , n) に対する識別子ri をランダムに生成して[Mi] (0)←ri||Mi とした上で、ハッシュ値hi(0)←H([Mi] (0)) を求める。
（Ｓ３）署名σ(0)← Sign_sk0 (h(0)) を生成する(sk0 は署名者の秘密鍵)。
ただし、h(0) = h1(0)||. . . ||hn(0) である。
（Ｓ４）文書([M1] (0), . . . ,[Mn] (0))、部分識別情報・署名ペア(h(0), σ(0))を出力する。

（j 番目の墨塗り者による黒塗り）
（Ｓ１）文書([M1](j-1) , . . . , [Mn](j-1)), j 組の部分識別情報・署名ペア(h(0), σ(0)), . . . , (h(j-1), σ(j-1))を入力する。
（Ｓ２）２組の部分識別情報h(0), h(j-1) を比較し、墨塗りされている部分文書の添字集合C =｛i|hi(0) ≠hi(j-1)｝を求める。
（Ｓ３）新たに墨塗り(非開示) する部分文書を定め、添字集合C´⊇C を求める。
（Ｓ４）各部分文書[Mi](j-1) (i = 1, . . . , n) から新しい部分文書を生成する。

[Mi](j) =r||M if i ∈C´/C
=[Mi](j-1) otherwise
ただし、rは乱数、Mは適当なデータ列である。

（Ｓ５）得られた部分文書からハッシュ値hi(j)← H([Mi](j))を求める。
（Ｓ６）署名σ(j) ←Sign_skj(h(j)) を生成する。ここで、skj はj 番目の墨塗り者の秘密鍵である。ただしh(j) = h1(j) ||. . . ||hn(j) である。
（Ｓ７）文書（[M1](j) , . . . , [Mn](j)）, j +1 組の部分識別情報・署名ペア(h(0), σ(0)), . . . , (h(j), σ(j)) を出力する。

（検証者）
（Ｓ１）文書([M1](m) , . . . , [Mn](m) ), m + 1 組の部分識別情報・署名ペア(h(0), σ(0)), . . . , (h(m), σ(m)), 署名者/墨塗り者の公開鍵pkj (j = 0, . . . ,m) を入力する。
（Ｓ２：墨塗り文書確認）各部分文書[Mi](m) (i = 1, . . . , n) のハッシュ値hi を求め、h1 ||. . . ||hn がh(m) に等しくない場合にはinvalid を出力して終了する。
（Ｓ３：署名検証）各j (j = 0, . . . ,m) に対し、公開鍵pkjと部分識別情報h(j) を用いて署名σ(j) を検証する。検証に失敗した場合にはinvalid を出力して終了する。
（Ｓ４：墨塗り箇所の特定）２組の部分識別情報h(0)、h(m)を比較し、墨塗り部分文書の添字集合C = ｛i|hi(0) ≠hi(m)｝を求める。
（Ｓ５：墨塗り者の検証）m+ 1 組の部分識別情報h(0), . . . ,h(m) を用いて、墨塗りされたi 番目(i ∈ C) の部分文書の墨塗り者を特定する。ここでhi(0) = . . . = hi(j-1) ≠hi(j) = . . . =hi(m) となるとき、j 番目の墨塗り者がこの部分文書を墨塗りしたと判定する。全てのi∈C に対して墨塗り者が特定できた場合にはvalid をそうでなければinvalid を出力して終了する。

前提技術１におけるPIAT 署名の（Algorithm 1）では、検証においては、墨塗り文書の他にm + 1 組の部分識別情報・署名ペア、特に(m + 1)n 個(最後の墨塗り者の部分識別情報を削除する場合にはmn 個) のハッシュ値を必要とする。

しかし、i 番目の部分文書に対応するm+1 個のハッシュ値hi(0), . . . , hi(m)のほとんどの値は等しい(開示される場合にはhi(0) = . . . = hi(m)、非開示される場合には、hi(0) = . . . = hi(j-1) ≠hi(j) = . . . =hi(m))ため、全ての値を保持するのは効率が悪い。そこで前提技術２は、署名者によるオリジナル文書についてはその全ての部分識別情報を出力するが、訂正（墨塗り）した部分については、当該訂正に係る部分のみの訂正（墨塗り）情報(i, j) を出力するようにした改良法を提案している。ここで墨塗り情報(i, j) は、i 番目の部分文書をj 番目の墨塗り者が墨塗りしたことを表す(図４９)。

墨塗り者による訂正においては、変更後の墨塗り文書、墨塗り情報、および墨塗り情報に対する署名を出力される。検証者はこれらの情報から前提技術１の場合と同等の情報を構成可能であるため、従来と全く同じ処理を行えばよい。このような変更により、検証者が必要とするハッシュ値の個数をn 個に削減できる(しかし署名の必要個数は変わらない)。なお前提技術１は、第1 版を基点にしてその差分を版管理するため、同様の差分版管理を行うプログラム等のソースコード管理ツールより、便宜上SCCS (SourceCode Control System) 型と呼んでいる。

（実施の形態）
本実施の形態は、前提技術２をさらに改良して、保持しなければならない部分識別情報の情報量を大幅に削減する方式について説明する。すなわち、前提技術２では、部分識別情報の差分を持つことで保存する情報量の削減を行ったが、これが効果を表すのは第２版以降であり、相変わらず第１版の部分識別情報の情報量は削減できていなかった。また、各版の部分識別情報には電子署名が必要で、版の数だけ電子署名の情報量の保存が必要であった。そこでこれらの情報量を可能な限り削減する方式を説明する。

前提技術１では、第１版の部分識別情報を保存し、第２版はそれに対する差分を使用していた(前向きの差分)。これに対して、本実施の形態では最新版からの後ろ向きの差分を使用する。基本的には前向きの差分を使用しても後ろ向きの差分を使用しても差分の情報量は変わらない。しかし、PIAT署名の場合、公開される本文から最新の部分識別情報が生成可能なため、最新版の部分識別情報を保存する必要がない。

この性質を利用することで、従来必須だった差分のベースとなる(第１版の)部分識別情報の保存が不要となり、大幅な保存情報量削減が可能となる。
また、各版の部分識別情報(またはその差分)に対する電子署名が必要であるが、この電子署名にAggregate(一括)署名を適用する場合についても説明する。

実施の形態１．
PIAT 署名の部分識別情報の削減を目的として、前提技術２（SCCS 型差分管理方式）の代わりに最新の版を基点にした差分管理方式を用いる。本方式は同様の差分版管理方式を導入しているソースコード管理ツールにちなみ、RSC (Revision Control System) 型（改良１）と呼ぶこととする。

実施の形態１の構成を図５０に示す。図５０に示す構成は、前提技術１で用いた構成に、電子署名作成部８０Ａが付加されている。また、原本管理部４０、原本処理部４１、原本保管部４２が、それぞれ文書情報管理部４０Ａ、処理部４１Ａ、保管部４２Ａとなっている。以下、動作について説明する。

（署名処理動作）
図５１は、署名処理動作を示す図である。
（Ｓ１）部分識別情報生成部５１により、署名者により入力されたメッセージ（契約文）M(0)がM1〜Mnに分割される。
（Ｓ２）また、部分識別情報生成部５１は、それぞれのブロックのハッシュをとりハッシュ値を生成する(例えばi番目のブロックならh(Mi)を生成する)。そのハッシュ値集合をH(0)とする。

（Ｓ３）署名者が署名を行うと、電子署名作成部８０Ａはそのハッシュ値集合H(0)と署名者の秘密鍵をパラメータとして署名関数で電子署名を作成する。
この署名は、例えばSig₀ = Sig(sk0,h(H(0)))とする。これはハッシュ値集合をさらにハッシュし、それに対して署名関数Sig()を用いて署名者の秘密鍵sk0で署名したもの（Sig₀）を表している。
（Ｓ４）そして署名者の指示に従い、文書情報管理部４０Ａは、メッセージM(0)と署名Sig₀を墨塗り者へ公開する。

なお、（Ｓ３）で署名関数を用いる場合にハッシュ値集合をさらにハッシュしているが、これは一例に過ぎず、他にも署名関数の種類により様々処理の方式が採用し得ることは言うまでもない。

（黒塗り処理（１）動作）
図５２は、オリジナルに対する最初の黒塗り処理（１）動作を示す図である。
最初の墨塗処理(変更処理)は以下のとおりである。

（Ｓ１）墨塗者１により、処理部４１Ａは、まず非公開(変更する)部分のメッセージを新たなメッセージに置き換える。図５２ではブロック３と５をM3,M5からS3,S5に置き換えている。S3,S5は墨塗の場合ランダムな情報でも良いしXXXXXXXXと墨塗りだと分かる情報でもよい。また変更の場合はS3,S5は変更後の情報となる。この変更後のデータの集合をM(1)と呼ぶ。
（Ｓ２）また、墨塗者１の指示により、部分識別情報生成部５１は変更前のメッセージブロック(ここではM3,M5)の各ハッシュ値(h(M3),h(M5))を別途計算しておく。これを署名復元データと呼ぶ。署名処理と同様に、M(1)の各ブロックに対してハッシュ値を計算し、その集合をH(1)とする。

（Ｓ３）また、電子署名作成部８０Ａは、墨塗者１の指示に従い、そのハッシュ値集合H(1)に墨塗者1の秘密鍵で署名を行う。例えば、Sig₁ = Sig(sk₁,h(H(1)))とする。これはハッシュ値集合をさらにハッシュし、それに対して署名関数Sig()を用いて墨塗者1の秘密鍵sk₁で署名したもの（Sig₁）を表している。
（Ｓ４）そして黒塗り者１の指示に従い文書情報管理部４０Ａは、メッセージM(1)と署名Sig₁に加え、署名者の署名Sig₀、および署名復元データを次の墨塗り者へ公開する。ここで、署名復元データは墨塗者１のID(1番目の墨塗者であること)とそのメッセージのブロックナンバとを共に公開しているが、署名復元データの作成者(つまり墨塗者１)と何番目のブロックのデータかが分かれば署名復元データの公開フォーマットは、どんなものを使用しても良い。

（黒塗り処理（２）動作）
図５３は、２回目以後（ｉ番目（ｉ≧２））の黒塗り処理（２）動作を示す図である。ｉ番目の墨塗処理(変更処理)は以下のとおりである。

（Ｓ１）墨塗者ｉに従い文書情報管理部４０Ａは、まず非公開(変更する)部分のメッセージを新たなメッセージに置き換える。図５３ではブロック4をM4からS4に置き換えている。S4は墨塗の場合ランダムな情報でも良いしXXXXXXXXと墨塗りだと分かる情報でもよい。また変更の場合はS4は変更後の情報となる。さらに変更の場合は前の墨塗者(変更者)が変更した部分を再度変更しても良い。変更後のデータの集合をM(i)と呼ぶ。

（Ｓ２）墨塗者の指示に従い、部分識別情報生成部５１は変更前のメッセージブロック(ここではM4)の各ハッシュ値(h(M4))を別途計算しておく。これを署名復元データと呼ぶ。
（Ｓ３）署名処理と同様に、M(i)の各ブロックに対してハッシュ値を計算し、その集合をH(i)とする。

（Ｓ４）電子署名作成部８０Ａは、墨塗者iの指示に従い、そのハッシュ値集合H(i)に墨塗者iの秘密鍵で電子署名を作成する。例えば、Sig_i= Sig(sk_i,h(H(i)))とする。これはハッシュ値集合をさらにハッシュし、それに対して署名関数Sig()を用いて墨塗者iの秘密鍵sk_iで署名したものSig_iを表している。
（Ｓ５）そして黒塗り者iの指示に従い文書情報管理部４０Ａは、メッセージM(i)と署名Sig_iに加え、署名者、墨塗者1からi-1までの署名Sig０, Sig１〜Sig_i、および墨塗者1〜iまでの署名復元データ(この図では、(3, h(M3), ID1), (5, h(M5), ID1), …(4, h(M4), IDi) )を次の墨塗り者(または検証者)へ公開する。

（署名確認（検証）処理動作）
図５４は、署名確認（検証）処理動作を示す図である。
（Ｓ１）検証者の指示に従い、部分識別情報検証部６１は、まずメッセージM(i)と署名復元データから、署名者のハッシュ値集合H(0)および墨塗者1〜iのハッシュ値集合H(1)〜H(i)を復元する。
（Ｓ２）次に部分識別情報検証部６１は、署名者の署名Sig₀とハッシュ値集合H(0)を用いて署名検証を行う。同様に墨塗者1〜iの署名Sig₁〜Sig_iとハッシュ値集合H(1)〜H(i)をそれぞれ署名検証する。
（Ｓ３）これらの署名検証がすべて正しく行われればメッセージM(i)の署名確認が完了する。

以上の処理により、署名復元データがない部分は署名者が作成・署名した原本であり、署名復元データがある部分はその署名復元データの作成者が墨塗りもしくは変更した部分であることが証明できる。

実施の形態１では、最新版の部分識別情報を基点にした差分情報管理を行うことで、前提技術２（SCCS 型）と同様の機能を実現し、さらに最新版の部分識別情報が最新版の本文から生成できることを利用することによって、基点となる部分識別情報の保持が不要となる。

なお、実施の形態１によれば、前提技術２におけるPIAT 署名の基本機能(すなわち非開示部分の秘匿性と開示部分の完全性保証)は保持されるが、不正墨塗りの特定だけは不可能になる。これは、本改良ではオリジナル（原本）の部分識別情報が保持されていないため、墨塗り情報(i, j, hj)（i番目の部分文書をj番目の黒塗り者が黒塗りし、黒塗り前の部分文書のハッシュ値がhjであったことを表す） において墨塗り前の部分文書に対応するハッシュ値hj が偽造された場合、その検出ができないからである。これ以外の機能は前提技術２と同じである。

上述した動作を前提技術１の第１の局面についての利用シーンに沿って説明する。
（新規作成時）
（Ａ）契約文書の新規作成時
契約文書の新規作成時の処理は、図６に示した第１の局面とほぼ同じである。異なる部分は、ＳＴ＿Ｒ７で本保管部へ登録する際に、「鈴木花子さん」の署名が付与された当該契約文書と、部分識別情報に対して行われた「鈴木花子さん」の署名のみを保存することである。ここで、部分識別情報自体については破棄し、保存しない。

これは、当該契約文書があれば、対応する部分識別情報は復元可能なためであり、対応する部分識別情報に対する「鈴木花子さん」の署名が保存されていれば、当該契約文書より復元した部分識別情報の完全性を保証することができるためである。

（訂正時）
（Ｂ）契約文書の訂正時
契約文書の訂正時の処理（図１０）と異なる部分は、「鈴木花子さん」が変更する契約文書を選択したとき、ＳＴ＿Ｕ２において、それに対応する部分識別情報を復元することである。それ以降は利用シーン１とほぼ同じ処理を行う。そして、原本保管部へ登録する際（ＳＴ＿Ｕ１２）に、生成した第２版の部分識別情報を基点として復元した第１版の部分識別情報の差分をとり、その差分情報を第１版の部分識別情報差分として保管する。また、契約時と同様に、「鈴木花子さん」の署名が付与された第２版の契約文書と、第２版の部分識別情報に対して行われた「鈴木花子さん」の署名のみを保存する。ここで、やはり第２版の部分識別情報自体については破棄し、保存しない（部分識別情報は保存しないが、「部分識別情報差分」という情報を次版作成時に生成して、保存する必要がある）。

（検証時）
（Ｃ）訂正済み契約文書に関する完全性／正当性検証時
訂正済み契約文書に関する完全性／正当性検証時の処理も前提技術１とほぼ同じである。異なるのは、部分識別情報が保存されていないため、部分識別情報の復元操作が追加される。ＳＴ＿Ｖ６において、まず訂正済契約文書（第２版）を取り出して、部分識別情報生成部で第２版の部分識別情報を復元する。次に、第１版の「部分識別情報差分」を原本保管部から取り出して、第２版の部分識別情報と当該部分識別情報差分から第１版の部分識別情報を生成する。

これにより第１の局面の完全性/正当性検証時に必要な、訂正済契約文書（第
２版の原本）とそれに対する「鈴木花子さん」の署名、第２版の部分識別情報とそれに対する「鈴木花子さん」の署名、第１版の部分識別情報とそれに対する「鈴木花子さん」の署名がそろうので、第１の局面と同様の処理を行うことで。訂正済み契約文書に関する完全性／正当性検証が完了する。

第２局面においても、上記と同様に部分識別情報を保存せず代わりに「部分識別情報差分」を保存していき、必要な場合にそれらから全ての部分識別情報を復元することで、基本方式と同様の処理を行うことができる。

（墨塗り時）
（Ｂ）登録データ訂正機能（契約文書の一部墨塗り時に利用）
前提技術１の第２の局面と同様に（Ｂ）契約文書の訂正時と同じ処理を「佐藤太郎さん」が行えば(「佐藤太郎さん」の署名を行えば)いいので、ここでは割愛する。

（送信時）
（Ｄ）登録データ流通（送信）機能（契約文書の送信時に利用）
処理は基本方式とほぼ同じであり、異なるのは送信するデータである。前提技術１の送信データは、第３版（佐藤さんが墨塗りした契約書）と第１版から第３版まで(あるいはは第２、３版)の部分識別情報、第３版の部分訂正情報、ポリシ情報を送信する。これに対して実施の形態２では、第３版（佐藤さんが墨塗りした契約書）と第１版から第３版まで(あるいはは第２、３版)の部分識別情報差分、第３版の部分訂正情報、ポリシ情報を送信する。つまり基本方式では部分識別情報そのものを送信していたのに対して、本方式では部分識別情報差分を送信するところが異なっている。

（受信時）
（Ｅ）登録データ流通（受信）機能（契約文書の受信時に利用）
処理は全く同じである。検証プロセスに本方式（Ｃ）の検証を利用する。

（第三者検証出力時）
（Ｆ）検証データ取得機能（裁判所等に証拠データとして提出する場合に利用）処理は全く同じである。（Ｄ）と同様に取り出されるデータが、基本方式では部分識別情報そのものを送信していたのに対して、本方式では部分識別情報差分を送信するところが異なっている。

以上より、前提技術１では、図５５に示すようにオリジナル文書の全ての部分識別情報（ａ）と訂正後の全ての部分識別情報（ｂ）を管理するのに対し、本実施の形態１では、図５５の（ｄ）に示される部分識別情報差分のみを管理する。前提技術２では第１版の部分識別情報（図５５の（ａ））と、第２版以降の部分識別情報の差分（図５５の（ｃ））を文書の階層構造を利用して保管する（図挿入１（Ａ））。本実施の形態は前提技術２と比較して差分情報だけの保管でいいので、大幅な保管・送信データ量の削減ができる（図５６参照）。なお、前提技術２が最も効率的である場合と比較しても、本実施の形態の方式では第１版の部分識別情報のデータ量の分だけ保管・送信データ量が削減できる。

実施の形態２．
実施の形態１の保管データ量をさらに削減する方式として、実施の形態２では、変更差分情報の文書への埋込む手法について説明する。

実施の形態１では、最後に墨塗りされた文書の他に、検証者は墨塗り箇所の個数と同じ個数のハッシュ値を必要としている。このとき、部分文書を墨塗りするのに使用するデータ列M として墨塗り前の部分文書のハッシュ値を用いると、墨塗り情報としてハッシュ値を保持する必要性はなくなる。

実施の形態２の構成は、実施の形態１で用いた構成と同じであるが、それらの動作が後述するように異なっている。この動作処理は図５０に示した処理部４１Ａにおいて行われる。以下、動作について説明する。

（署名処理動作）
図５７は、署名処理動作を示す図である。これは図５１と全く同じであり、その動作も同じであり、ここでの説明は省略する。

（黒塗り（１）処理動作）
図５８は、原本に対する最初の黒塗り処理（１）動作を示す図である。最初の墨塗処理の変更点は以下のとおりである。
（Ｓ１）文書情報管理部４０Ａは、部分識別情報生成部５１で計算した黒塗り前の部分識別情報のハッシュ値を署名復元データとして墨塗り情報Sの代わりに使用して文書情報とするとともに、部分識別情報生成部５１にそれらを用いてハッシュ値を生成させる。
図５８ではS3,S5の代わりにH(M3),h(M5)を使用している。

（Ｓ２）そして、変更のあったブロック番号と署名復元データを作成したIDだけ(ここでは(3, ID1), (5, ID1))を署名復元データの代わりに公開する。

ここで、ブロック番号は署名復元データが埋め込まれた場所であるので、公開しなくてもよく、IDも署名復元データと同様に黒塗り情報Sの代わりに埋め込んでも良い。さらに図５８にe.g.の部分に示すように、XMLタグとして情報を格納することも可能である。

（黒塗り処理（２）動作）
図５９は、２回目以後（ｉ番目（ｉ≧２））の黒塗り処理（２）動作を示す図である。これは図５８と全く同じであり、その動作も同じである。

（署名確認（検証）処理動作）
図６０は、署名確認（検証）処理動作を示す図である。
署名確認処理は実施の形態１に示した図５４に対して、ハッシュ値情報の復元を署名確認データから行うのではなく、変更ブロックのメッセージから取り出して復元を行う点が異なるのみであり、それ以外の部分は図５４の場合と同様である。

図６１は、実施の形態２の作用を示す概念図である。これによれば、メタデータとしての部分識別情報は一切保管する必要がない。図６２は実施の形態１と２を前提技術２と比較した結果を示している。ただし、署名復元データをメッセージに埋め込む場合、変更や削除(ブロックそのものを削除すること)には対応できない。これらによれば、前提技術１から部分識別情報は数分の1〜数十分の1に、前提技術２からからも、1/2〜数分の1に削減可能である。なお、前提技術１から前提技術２では、1/2〜数分の1に削減できている。

実施の形態３．
実施の形態３では、電子署名にAggregate(一括)署名を適用する場合について説明する。

Aggregate署名は(複数人による)複数の署名を1つに重畳することが可能で、重畳した署名を一括して検証することができる署名技術である。そこで、修正を行うことで部分識別情報を行った場合に従来と同様に部分識別情報に署名を行うが、その署名をAggregate署名で行い、前版までの署名に重畳する。こうすることによって、従来版数の数だけ必要であった電子署名のデータ量を1つの電子署名のデータ量に削減することができる。

以下では(Sequential) Aggregate 署名(KG,AS,AV)を用いる。ここでKG は鍵生成、ASはAggregate 署名生成、AVはAggregate 署名検証を行うアルゴリズムである。j番目の署名者は、j-1 番目の署名者から文書M1, . . . ,Mj-1 とAggregate 署名σj-1 を受け取り、自分が署名したい文書Mj とAggregate 署名σj-1 とからアルゴリズムAS を用いて新しいAggregate 署名σj を生成し、文書M1, . . . ,Mj-1,Mj とAggregate 署名σj を出力する。Aggregate 署名の検証者はアルゴリズムAV を用いて、文書M1, . . . ,Mm に対するAggregate 署名σm を検証する。検証結果がvalid であれば、全ての文書の完全性が保証される。

なお、参照文献として、下記文献が知られる。

[BGL+03] D. Boneh, C. Gentry, B. Lynn, H. Shacham, “Aggregate and Verifiably Encrypted Signatures from Bilinear Maps”, Eurocrypt 2003, LNCS 2656, pp.416-432, Springer-Verlag, 2003.
[LMR+04] A. Lysyanskaya, S. Micali, L. Reyzin, H. Schacham, “Sequential Aggregate Signatures from Trapdoor Permutations”, EUROCRYPT 2004, LNCS 3027, pp. 74.90, Springer-Verlag, 2004.

Aggregate署名とは、グループ署名の一種であり、多段の署名を1つの署名に重畳することが可能となる。

ここで、１）〜４）が成立するとき
１） G₁,G₂,G_Tが位数ｐの乗法巡回群
２） g₁, g₂がそれぞれG₁,G₂の生成元
３） ψがG₁からG₂への計算可能な同型写像ψ(g₁)=g₂
４） e()が計算可能な双線形写像G₁×G₂ →GT

pk_i= g₁ ^ski, σ_i= h_i ^ski，σ= Π_iσ_i とすると、
e(g₁,σ)=e(g₁,Π_ih_i ^ski)=Πi e(g₁, h_i)^ski=Π_i e(g₁ ^ski, h_i) =Π_i e(pk_i, h_i)
が成立する。

sk_i,pk_iを秘密鍵/公開鍵,σをAggregate署名とすれば署名の重畳が可能である。
ここでハッシュ関数hの出力域はG₁であり、通常とは異なっている。Aggregate 署名は、上のような処理で計算を行うが、本例で重要なことは、例えば、

Aggregate 署名関数でのm1の署名をσ1＝SigA(sk₁,m1)
Aggregate 署名関数でのm2の署名をσ2＝SigA(sk₂,m2)
Aggregate 署名関数でのm3の署名をσ3＝SigA(sk₃,m3)
としたとき署名の重畳σ=σ1×σ2×σ3が計算できて、
署名検証時にVerA(pk₁,pk₂,pk₃,σ,m1,m2,m3)で検証が可能になるということである。

なお、ここで、注意を要することは、通常の検証なら
Ver(pk1,σ1,m1,m2,m3)
Ver(pk2,σ2,m1,m2,m3)
Ver(pk3,σ3,m1,m2,m3)
と署名が3つ(σ1, σ2, σ3)必要となるが、Aggregate署名ならσだけで良く、データ量が1/3になる。ここで、σ1〜σ3を個別署名、重畳した署名σをAggregate署名と呼んでいる。

本明細書では双線形写像を使ったアグリゲート署名で説明を行っているが、アグリゲート署名は双線形写像以外にも例えば以下の論文で提案されているような従来のRSAベースで構成するアグリゲート署名方法が知られており、これを用いることも可能である。
[LMRS04] (Sequential Aggregate署名の提案論文)
A. Lysyanskaya, S. Micali, L. Reyzin, and H. Shacham,“Sequential Aggregate Signatures from Trapdoor Permutations", Eurocrypt 2004, LNCS 3027, pp.74-90, 2004
[TSNT05] (Sequential Aggregate署名の改良)
寺西勇, 佐古和恵, 野田潤, 田口大悟,“署名長が署名者数に比例しないRSAベース Sequential Aggregate 署名方式”, 情報処理学会コンピュータセキュリティ(CSEC)研究会, 2005年3月.

以下、動作について説明する。
（署名処理動作）
図６３は署名時の動作を示している。署名関数の代わりにｃ関数を使用し、個別署名σ0を計算し、それをAggregate署名σ(0)とし、Aggregate署名σ(0)を公開する部分が異なる。

（黒塗り処理（１）動作）
図６４は、原本に対する最初の黒塗り処理（１）動作を示す図である。墨塗り処理でも同様であり、署名関数の代わりにAggregate署名関数を使用し、個別署名σ１を計算し、署名者のAggregate署名σ(0)に自分の個別署名σ1を掛け合わせて、新しいAggregate署名σ(1)とし、公開する署名が新しいAggregate署名σ(1)だけであるという部分が異なる。

（黒塗り処理（２）動作）
図６５は、２回目以後（ｉ番目（ｉ≧２））の黒塗り処理（２）動作を示す図である。この場合も図６４の黒塗り処理（１）の場合と全く同様である。

（署名確認（検証）処理動作）
図６６は、署名確認（検証）処理動作を示す図である。
署名確認処理では、署名検証が図５４に比べ、Aggregate署名の検証になる部分だけがことなる。

上述した前提技術１，２や実施の形態１，２に紹介したPIAT 署名では、検証者は署名者とm 人の墨塗り者が生成した計m+1 個の署名を必要としていた。これら署名の代わりにAggregate 署名を用いることによって、必要な署名を1 個に削減することができる（図６７）。ただし必要な部分識別情報は不変である。このAggregate 署名を上述した前提技術２、実施の形態１，２に対して適用することにより、これらの文書管理において管理される署名はやはり1 個に削減可能となる（図６８）。なお、この場合不正墨塗り者の特定はできなくなる。これはAggregate 署名の検証に失敗した場合は、どの署名者/墨塗り者の署名の検証に失敗したかを特定できないからである。これ以外の機能は従来と変わるところがない。

実施の形態２と実施の形態３のAggregate 署名を組み合わせると、保管データ量の削減効果は顕著であり、ハッシュ値を必要とせず, 署名も1 個しか必要としないことから, 検証者が必要とするデータ量という観点からは最適になっている。この場合でも墨塗り署名として必要最小限の機能は有している。

以下、Aggregate署名を行う場合の一例を前提技術２に登場する「鈴木花子さん」、及び他２名（佐藤太郎さん、山田稔さん））についての具体例に即して説明しておく。

（準備）
Aggregate 署名を適用する場合、「鈴木花子さん」、「佐藤太郎さん」、「山田稔さん」はそれぞれAggregate 署名に対応した署名用の鍵を持っている。またAggregate 署名用の共通パラメータも共有しているものとする。また、シーン１の例の場合、契約書本文の署名はAggregate 署名を用いてもデータ量が削減されないので、部分識別情報に対する署名に適用する場有について述べる。さらに個々の文書（部分識別情報）に対する署名を個別署名、共有情報を利用して重畳したものを一括署名と呼ぶ。Aggregate 署名の検証は一括署名とそれぞれの文書(部分識別情報)から検証可能であり、個別署名の検証は不要である。

Aggregate 署名は以下のように説明できる。
文書Miに対する個別署名の作成:σi=Sign(Mi)n個の個別署名から一括署名を作成する。

σ＝σ0×σ1×σ2×…σn

例えば、双線形写像を用いたAggregate 署名の場合Sign(Mi)は楕円曲線暗号に基づいた署名方式、一括署名作成には個別署名の法P(Aggregate 署名のパラメータ)上の乗算剰余で実現できる。

（新規作成時）
（Ａ）契約文書の新規作成時
契約書新規作成時に契約書の部分識別情報を生成し、「鈴木花子さん」の署名行う。Aggregate 署名を適用する場合、この署名を「鈴木花子さん」の個別署名とする。また、最初の一括署名は「鈴木花子さん」の個別署名とし、個別署名は破棄する。例えば一括署名をσ、部分識別情報に対する「鈴木花子さん」の個別署名をσ1とすると、σ←σ1と表せる(「←」は代入を示す)。

（訂正時）
（Ｂ）登録データ訂正機能（契約文書の一部墨塗り時に利用）
データ訂正時は、まず、訂正契約書の部分識別情報に対して、「鈴木花子さん」の個別署名を行う。次に一括署名として第1版の一括署名に第2版部分識別情報に対する「鈴木花子さん」の個別署名を重畳する。その後、「鈴木花子さん」の個別署名は破棄する。例えば一括署名をσ、第2版部分識別情報に対する「鈴木花子さん」の個別署名をσ2とするとσ←σ×σ2とあらわすことができる。

（検証時）
（Ｃ）訂正済み契約文書に関する完全性／正当性検証時
復元した部分識別情報(第１，２版)と一括署名より、Aggregate 署名の検証処理を利用して署名検証を行う。

（墨塗り時）
（Ｂ）登録データ訂正機能（契約文書の一部墨塗り時に利用）
訂正時と全く同様のAggregate 署名処理を行う。

（送信時）
（Ｄ）登録データ流通（送信）機能（契約文書の送信時に利用）
送信時は署名・署名検証処理を行わない。送信データの殆どは上記と同じであるが各版の部分識別情報の署名ではなく、一括署名1つを送信するところが異なる。

（受信時）
（Ｅ）登録データ流通（受信）機能（契約文書の受信時に利用）
受信時は（Ｂ）検証時と同様の処理を行う。

（第三者検証出力時）
（Ｆ）検証データ取得機能（裁判所等に証拠データとして提出する場合に利用）
送信時は署名・署名検証処理を行わない。検証用のデータはほぼ上記と同じであるが各版の部分識別情報の署名ではなく、一括署名1つを出力するところが異なる。

以上より、部分識別情報に対する署名データについて、通常の署名を行う場合、「鈴木花子さん」の署名が２個、「佐藤太郎さん」の署名が１個保存・送信する必要があるが、Aggregate 署名を適用すれば、それらが重畳され一括署名１個を保存・送信すればよく、保存・送信の署名データ量を大幅に削減することができる。

実施の形態４．
上述した実施の形態３において、Aggregate 署名（σ(0)、σ(1)、σ(2)、…）は検証者等に公開される。従って、もし仮に、最初の署名者から、後の１又は複数の訂正者（黒塗り者）にかけて、Aggregate 署名が生成されていく場合に、最初もしくは途中のAggregate 署名と、最後の黒塗り文書に係るハッシュ値（H(n)）を入手できることとなれば、それを基に偽造署名を生成することができる。

例えば、最初の署名者による署名σ(0)と、最後の文書に係るハッシュ値（H(n)）を用いれば、σ(A)なる個別署名を作成し、σ←σ×σ(A)とした一括署名を作成し、それを持って、悪意のあるものが、署名者を偽ることが可能になるという恐れがある。これは、特に、実際の文書訂正者（黒塗り者）が誰であるかが重要な意味を持つ場合に重要な問題となる。

この様な問題は、黒塗り者間でAggregate 署名そのものが送信されるためであり、悪意のある者がそのデータを通信回線上で入手できることによる。そこで、本実施の形態４では、通信回線上に載せられるAggregate 署名を暗号化することにより、署名データが悪意では復元できないようにした場合について説明する。

この場合、図６９に示すように、文書情報管理部４０Ａにおいて、暗号／復号部４３Ｂを設け、署名データが送信処理部７１から回線上に載せられる（送信される）場合に、Aggregate 署名を暗号化すると共に、回線上から取得する（受信する）場合に、暗号化されたAggregate 署名を復号するようにする。なお、以下に詳述する暗号化については、対策１に関数を用いる暗号化（暗号鍵で暗号化する暗号化）を、対策２においては論理演算による暗号化（電子署名に所定の乱数を付加する）を説明している。なお、下記説明は、図６３〜図６５に基づいて行われている。

（対策１）
（Ｓ１）作成された部分文書に署名を行った署名者（例えば文書作成者０）は、部分文書に対応するハッシュ値を求め、これらハッシュ値に対する署名 σ(0) を生成する。
（Ｓ２）そして、第１のAggregate 署名を行う（σ0←σ(0) と設定する）。
（Ｓ３）次に得られたAggregate 署名に対し、暗号化（c0←Enc(σ0,key1)） を行い送信する。ここで Enc(σ0,key1) は、σ0 を墨塗り者１の暗号鍵 key1 で暗号化する処理を表している。
（Ｓ４）暗号化されたAggregate 署名を受信したシステムでは、墨塗り者１の指示に従い、その復号化を行い、σ0←Dec(c0,key1') を求める。ここで Dec(c0,key1') は、c0 を墨塗り者１の復号鍵 key1' で復号する処理を表している。この場合、key1=key1' であってもかまわない。

（Ｓ５）そして、黒塗り者１は、受け取ったσ0 に基づいて、新しい墨塗り文書を生成する。
（Ｓ６）新しい墨塗り文書の各部分文書に対応するハッシュ値を求め、これらハッシュ値に対する署名 σ(1) を生成する。
（Ｓ７） σ0 と σ(1) の一括署名である第２のAggregate 署名σ1 を求める。
（Ｓ８）このAggregate 署名を、暗号化（ c1←Enc(σ1,key2)）し、黒塗り者２に送信する。ここで Enc(σ1,key2) は、σ1 を墨塗り者２の暗号鍵 key2 で暗号化する操作を表す。

（Ｓ９）暗号化されたAggregate 署名を受信したシステムでは、墨塗り者２の指示に従い、その復号化を行い、σ1←Dec(c1,key2') を求める。ここで Dec(c1,key2') は、c1 を墨塗り者２の復号鍵 key2' で復号する処理を表している。この場合、key2=key2' であってもかまわない。
（Ｓ１０）そして、黒塗り者２は、受け取った文書から、新しい墨塗り文書を生成する。

（Ｓ１１）新しい墨塗り文書の各部分文書に対応するハッシュ値を求め、これらハッシュ値に対する署名 σ(2) を生成する。
（Ｓ１２）σ1 と σ(2) の一括署名である第３のAggregate 署名σ2 を求め、以下、同様に、墨塗り者２の次に墨塗り者３が存在する場合には、（Ｓ８）以降を繰り返し行う。

（対策２）
（Ｓ１）作成された部分文書に署名を行った署名者（例えば文書作成者０）は、部分文書に対応するハッシュ値を求め、これらハッシュ値に対する署名 σ(0) を生成する。
（Ｓ２）そして、第１のAggregate 署名を行う（σ0←σ(0) と設定する）。
（Ｓ３）次に得られたAggregate 署名に対し、σ0'←σ(0)+key1 を求め、黒塗り者１に送信する。
ここで + はビットごとの排他的論理和であり、加算,減算,乗算,除算などの演算を表す。また key1 は墨塗り者１から事前に渡された秘密情報(パスワードなど)を表している。

（Ｓ４）暗号化されたAggregate 署名を受信したシステムでは、墨塗り者１の指示に従い、σ0'と key1 とから σ0 を求める。
（Ｓ５）そして、黒塗り者１は、受け取ったσ0 に基づいて、新しい墨塗り文書を生成する。
（Ｓ６）新しい墨塗り文書の各部分文書に対応するハッシュ値を求め、これらハッシュ値に対する署名 σ(1) を生成する。
（Ｓ７） σ0 と σ(1) の一括署名である第２のAggregate 署名σ1 を求める。
（Ｓ８）このAggregate 署名に対して、σ1'←σ(1)+key2 を求め、黒塗り者２に送信する。
ここで + はビットごとの排他的論理和であり、加算,減算,乗算,除算などの演算を表す。また key1 は墨塗り者１から事前に渡された秘密情報(パスワードなど)を表している。

（Ｓ９）暗号化されたAggregate 署名を受信したシステムでは、墨塗り者２の指示に従い、σ1'と key2 とから σ1 を求める。
（Ｓ１０）そして、黒塗り者２は、受け取ったσ1 に基づいて、新しい墨塗り文書を生成する。
（Ｓ１１）新しい墨塗り文書の各部分文書に対応するハッシュ値を求め、これらハッシュ値に対する署名 σ(2) を生成する。
（Ｓ１２） σ1 と σ(2) の一括署名である第３のAggregate 署名σ2 を求め、
以下、同様に、墨塗り者２の次に墨塗り者３が存在する場合には、（Ｓ８）以降を繰り返し行う。

なお、図示したフローチャートやステップに示された各動作をコンピュータにより実行させるプログラムを提供することにより、本発明の電子文書管理プログラムを提供することができる。これらプログラムはコンピュータにより読取可能な媒体に記録されてコンピュータにより実行させることができる。ここで、コンピュータにより読取可能な媒体としては、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
（付記１）
電子情報で作成され登録される文書情報をコンピュータにより管理する電子文書管理プログラムであって、
文書情報を複数の部分に区切り、各部分の情報に基づいて文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成ステップと、
文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成ステップと、
文書情報を管理する管理ステップと、
管理されている文書情報の正当性を検証する検証ステップとを有し、
前記管理ステップは、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成ステップにより作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての部分識別情報を得ると共に、前記電子署名作成ステップにより、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての部分識別情報を訂正された文書情報に対応付けて管理し、
前記検証ステップは、前記管理ステップにより前記訂正された文書情報に対応付けられて管理されている前記部分識別情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成ステップにより部分識別情報を生成させて得られた部分識別情報とを用いて検証する
ことをコンピュータに実行させることを特徴とする電子文書管理プログラム。
（付記２）
請求項１に記載の電子文書管理プログラムにおいて、
前記電子署名作成ステップは、前記部分識別情報生成ステップにより、生成された部分識別情報の集合と、秘密鍵とをパラメータとして署名関数を用いて電子署名を作成することを特徴とする電子文書管理プログラム。
（付記３）
請求項１に記載の電子文書管理プログラムにおいて、
前記電子署名作成ステップは、グループ署名の一種であり、多段の署名を1つの署名に重畳することが可能なアグリゲート（Aggregate）署名関数を用いて電子署名を作成することを特徴とする電子文書管理プログラム。
（付記４）
請求項１に記載の電子文書管理プログラムにおいて、
前記訂正された文書情報に対応付けられて管理される前記部分識別情報は、前記訂正された文書情報のデータと別個に管理されることを特徴とする電子文書管理プログラム。
（付記５）
請求項１に記載の電子文書管理プログラムにおいて、
前記部分識別情報は、前記訂正済の文書情報に埋め込まれて管理されることを特徴とする電子文書管理プログラム。
（付記６）
請求項１に記載の電子文書管理プログラムにおいて、
更に、予め規定されたポリシ情報を保管するポリシ情報保管ステップと、
前記文書情報に訂正があった場合に、訂正された部分の訂正履歴に関する情報である部分訂正情報を生成する部分訂正情報生成ステップとを備え、
前記管理ステップは、前記文書情報の一部に対して訂正があった場合、前記部分訂正情報生成ステップにより部分訂正情報を生成させ、生成された部分訂正情報と、前記所定のポリシ情報保管ステップにより保管されているポリシ情報とを更に前記訂正された文書情報に対応させて管理し、
前記検証ステップは、前記訂正された文書情報の正当性を、該文書情報に関連付けられて前記管理ステップにより管理されている前記部分識別情報と前記署名情報とに加え、更に前記部分訂正情報と、前記ポリシ情報とを用いて検証することを特徴とする電子文書管理プログラム。
（付記７）
請求項１に記載の電子文書管理プログラムにおいて、
前記部分識別情報生成ステップは、文書情報を複数の部分に区切り、各部分の文書情報に対してハッシュ関数を用いて部分識別情報を生成することを特徴とする電子文書管理プログラム。
（付記８）
請求項１に記載の電子文書管理プログラムにおいて、
前記管理ステップにより管理される前記情報は、階層的な文書構造を持つXMLデータにより構成されることを特徴とする電子文書管理プログラム。
（付記９）
請求項１に記載の電子文書管理プログラムにおいて、
前記管理ステップは、全ての電子情報を版数に対応する原本情報として扱うと共に、版数管理されている原本情報の内容は、各版数の原本情報の内容によって閲覧可能者と閲覧不能者を識別可能とすることを特徴とする電子文書管理システム。
（付記１０）
電子情報で作成され登録される文書情報を管理する電子文書管理システムであって、
文書情報を複数の部分に区切り、各部分の情報に基づいて文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成部と、
文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成部と、
文書情報を管理する管理部と、
管理されている文書情報の正当性を検証する検証部とを有し、
前記管理部は、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成部により作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての部分識別情報を得ると共に、前記電子署名作成部により、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての部分識別情報を訂正された文書情報に対応付けて管理し、
前記検証部は、前記管理部により前記訂正された文書情報に対応付けられて管理されている前記部分識別情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成部により部分識別情報を生成させて得られた部分識別情報とを用いて検証する
ことを特徴とする電子文書管理システム。
（付記１１）
請求項１０に記載の電子文書管理システムにおいて、
前記電子署名作成部は、前記部分識別情報生成部により、生成された部分識別情報の集合と、秘密鍵とをパラメータとして署名関数を用いて電子署名を作成することを特徴とする電子文書管理システム。
（付記１２）
請求項１０に記載の電子文書管理システムにおいて、
前記電子署名作成部は、グループ署名の一種であり、多段の署名を１つの署名に重畳することが可能なアグリゲート（Aggregate）署名関数を用いて電子署名を作成することを特徴とする電子文書管理システム。
（付記１３）
請求項１０に記載の電子文書管理システムにおいて、
前記訂正された文書情報に対応付けられて管理される前記部分識別情報は、前記訂正された文書情報のデータと別個に管理されることを特徴とする電子文書管理システム。
（付記１４）
請求項１０に記載の電子文書管理システムにおいて、
前記部分識別情報は、前記訂正済の文書情報に埋め込まれて管理されることを特徴とする電子文書管理システム。
（付記１５）
請求項１０に記載の電子文書管理システムにおいて、
更に、予め規定されたポリシ情報を保管するポリシ情報保管部と、
前記文書情報に訂正があった場合に、訂正された部分の訂正履歴に関する情報である部分訂正情報を生成する部分訂正情報生成部とを備え、
前記管理部は、前記文書情報の一部に対して訂正があった場合、前記部分訂正情報生成部により部分訂正情報を生成させ、生成された部分訂正情報と、前記所定のポリシ情報保管部により保管されているポリシ情報とを更に前記訂正された文書情報に対応させて管理し、
前記検証部は、前記訂正された文書情報の正当性を、該文書情報に関連付けられて前記管理部により管理されている前記部分識別情報と前記署名情報とに加え、更に前記部分訂正情報と、前記ポリシ情報とを用いて検証することを特徴とする電子文書管理システム。
（付記１６）
請求項１０に記載の電子文書管理システムにおいて、
前記部分識別情報生成部は、文書情報を複数の部分に区切り、各部分の文書情報に対してハッシュ関数を用いて部分識別情報を生成することを特徴とする電子文書管理システム。
（付記１７）
請求項１０に記載の電子文書管理システムにおいて、
前記管理部により管理される前記情報は、階層的な文書構造を持つXMLデータにより構成されることを特徴とする電子文書管理システム。
（付記１８）
請求項１０に記載の電子文書管理システムにおいて、
前記管理部は、全ての電子情報を版数に対応する原本情報として扱うと共に、版数管理されている原本情報の内容は、各版数の原本情報の内容によって閲覧可能者と閲覧不能者を識別可能とすることを特徴とする電子文書管理システム。
（付記１９）
電子情報で作成され登録される文書情報をコンピュータにより管理する電子文書管理方法であって、
文書情報を複数の部分に区切り、各部分の情報に基づいて文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成ステップと、
文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成ステップと、
文書情報を管理する管理ステップと、
管理されている文書情報の正当性を検証する検証ステップとを有し、
前記管理ステップは、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成ステップにより作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての部分識別情報を得ると共に、前記電子署名作成ステップにより、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての部分識別情報を訂正された文書情報に対応付けて管理し、
前記検証ステップは、前記管理ステップにより前記訂正された文書情報に対応付けられて管理されている前記部分識別情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成ステップにより部分識別情報を生成させて得られた部分識別情報とを用いて検証する
ことを特徴とする電子文書管理方法。
（付記２０）
請求項１９に記載の電子文書管理方法において、
前記電子署名作成ステップは、前記部分識別情報生成ステップにより、生成された部分識別情報の集合と、秘密鍵とを用い、グループ署名の一種であり、多段の署名を1つの署名に重畳することが可能なアグリゲート（Aggregate）署名関数を用いて電子署名を作成することを特徴とする電子文書管理方法。
（付記２１）
請求項３に記載の電子文書管理プログラムにおいて、
前記電子署名作成ステップで作成された電子署名を暗号化する暗号化ステップを備える電子文書管理プログラム。
（付記２２）
請求項２１に記載の電子文書管理プログラムにおいて、
前記暗号化ステップは前記電子署名作成ステップで作成された電子署名を所定の暗号鍵で暗号化することを特徴とする電子文書管理プログラム。
（付記２３）
請求項２１に記載の電子文書管理プログラムにおいて、
前記暗号化ステップは前記電子署名作成ステップで作成された電子署名に所定の乱数を付加することを特徴とする電子文書管理プログラム。
（付記２４）
請求項１２に記載の電子文書管理システムにおいて、
前記電子署名作成部で作成された電子署名を暗号化する暗号化部を備える電子文書管理システム。
（付記２５）
請求項２４に記載の電子文書管理システムにおいて、
前記暗号化部は前記電子署名作成部で作成された電子署名を所定の暗号鍵で暗号化することを特徴とする電子文書管理システム。
（付記２６）
請求項２４に記載の電子文書管理システムにおいて、
前記暗号化部は前記電子署名作成部で作成された電子署名に所定の乱数を付加することを特徴とする電子文書管理システム。
（付記２７）
請求項２０に記載の電子文書管理方法において、
前記電子署名作成ステップで作成された電子署名を暗号化する暗号化ステップを備える電子文書管理方法。
（付記２８）
請求項２７に記載の電子文書管理方法において、
前記暗号化ステップは前記電子署名作成ステップで作成された電子署名を所定の暗号鍵で暗号化することを特徴とする電子文書管理方法。
（付記２９）
請求項２７に記載の電子文書管理方法において、
前記暗号化ステップは前記電子署名作成ステップで作成された電子署名に所定の乱数を付加することを特徴とする電子文書管理方法。

本発明の前提技術を示すブロック図である。 本発明の前提技術の電子文書管理システムの構成を示す機能ブロック図である。 ポリシ情報の内容例を示す図である。 部分識別情報の内容例を示す図である。 新規文書登録時の保管状態を示す図である。 新規文書登録処理の動作を示すフローチャートである。 訂正可能範囲／訂正不可範囲を特定する例を示す図である。 部分訂正情報の内容例を示す図である。 登録文書訂正時の保管状態を示す図である。 登録文書訂正処理の動作を示すフローチャートである。 訂正ポリシ情報と部分訂正情報の比較を示す図である。 登録文書と部分識別情報の比較を示す図である。 部分識別情報の新版と旧版の比較を示す図である。 登録文書検証処理の動作を示すフローチャートである。 第２の局面における利用イメージを示す図である。 登録文書訂正（一部墨塗り）時の原本保管状態を示す図である。 送信対象の契約文書一式を示す図である。 登録文書流通（送信）処理の動作を示すフローチャートである。 登録待ち文書受信処理の動作を示すフローチャートである。 登録文書取得処理の動作を示すフローチャートである。 第三者証明１を示す図である。 第三者証明２を示す図である。 第三者証明３を示す図である。 前提技術２における第２の適用分野における利用シーンを示す図である。 保険契約申込書（第１版）-本文をXMLデータで表現した例を示す図である。 保険契約申込書（第１版）のXMLデータモデルを示す図である。 保険契約申込書（第１版）-部分識別情報をXMLデータで表現した例を示す図である。 「契約者」を抽出したXMLデータモデルを示す図である。 保険契約申込書（第１版）作成時の保管状態を示す図である。 保険契約申込書（第２版）-本文をXMLデータで表現した例を示す図である。 保険契約申込書（第２版）-部分識別情報をXMLデータで表現した例を示す図である。 保険契約申込書（第２版）作成時の保管状態を示す図である。 金融機関担当者が閲覧可能な検証データ群を示す図である。 保険契約申込書（第３版）-本文をXMLデータで表現した例を示す図である。 保険契約申込書（第３版）-部分識別情報をXMLデータで表現した例を示す図である。 保険契約申込書（第３版）作成時の保管状態を示す図である。 第２版における全部分識別情報の連結管理を示す図である。 第３版における全部分識別情報の連結管理を示す図である。 方式２を用いて部分識別情報（第２版）をXMLデータで表現した例を示す図である。 方式２を用いた保険契約申込書（第３版）作成時の保管状態を示す図である。 評価・分析のためのXMLデータ例を示す図である。 評価・分析用XMLデータの更新を示す図である。 方式０による部分識別情報の生成と検証を示す図である。 方式１による部分識別情報の生成と検証を示す図である。 方式２による部分識別情報の生成と検証を示す図である。 方式別解析結果を示す図である。 方式別解析結果におけるバブルチャートを示す図である。 前提技術１の処理概要を示す図である。 前提技術２の処理概要を示す図である。 本発明の実施の形態の構成を示すブロック図である。 実施の形態１における署名時の動作を示す図である。 実施の形態１における最初の黒塗り時の動作を示す図である。 実施の形態１における２回目以後の黒塗り時の動作を示す図である。 実施の形態１における署名確認時の動作を示す図である。 実施の形態１の作用概要を前提技術と比較して示す図である。 実施の形態１の作用概要を示す図である。 実施の形態２における署名時の動作を示す図である。 実施の形態２における最初の黒塗り時の動作を示す図である。 実施の形態２における２回目以後の黒塗り時の動作を示す図である。 実施の形態２における署名確認時の動作を示す図である。 実施の形態１、実施の形態２の作用概要を前提技術と比較して示す図である。 実施の形態２の作用概要を示す図である。 実施の形態３における署名時の動作を示す図である。 実施の形態３における最初の黒塗り時の動作を示す図である。 実施の形態３における２回目以後の黒塗り時の動作を示す図である。 実施の形態３における署名確認時の動作を示す図である。 実施の形態３の作用概要を示す図である。 実施の形態３の作用概要を前提技術と比較して示す図である。 実施の形態４の構成を示すブロック図である。 従来の紙による訂正済み契約文書の一例を示す図である。

符号の説明

２０ 解析要求部、３０ 訂正ポリシ管理部、４０Ａ 文書情報管理部、４１Ａ 処理部、４２Ａ 保管部、４３Ｂ 暗号／復号部、５０ 部分完全性情報生成部、５１ 部分識別情報生成部、５２ 部分訂正情報生成部、６０ 部分完全性情報検証部、６１ 部分識別情報検証部、７０ 流通管理部、８０Ａ 電子署名作成部。

Claims (9)

1. 電子情報で作成され登録される文書情報をコンピュータにより管理する電子文書管理プログラムであって、
   文書情報を複数の部分に区切り、各部分の情報に基づいて生成した各部分の識別情報と各部分の位置情報とからなる部分識別情報を生成する部分識別情報生成ステップと、
   文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成ステップと、
   文書情報を管理する管理ステップと、
   管理されている文書情報の正当性を検証する検証ステップとを有し、
   前記管理ステップは、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成ステップにより作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての識別情報と該訂正部分の位置情報とを得ると共に、前記電子署名作成ステップにより、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての識別情報と該訂正部分の位置情報とを訂正された文書情報に対応付けて管理し、
   前記検証ステップは、前記管理ステップにより前記訂正された文書情報に対応付けられて管理されている前記訂正部分の訂正前の識別情報と位置情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成ステップにより部分識別情報を生成させて得られた部分識別情報とを用いて検証する
   ことをコンピュータに実行させることを特徴とする電子文書管理プログラム。
2. 請求項１に記載の電子文書管理プログラムにおいて、
   前記電子署名作成ステップは、前記部分識別情報生成ステップにより、生成された識別情報の集合と、秘密鍵とをパラメータとして署名関数を用いて電子署名を作成することを特徴とする電子文書管理プログラム。
3. 請求項１に記載の電子文書管理プログラムにおいて、
   前記電子署名作成ステップは、グループ署名の一種であり、多段の署名を1つの署名に重畳することが可能なアグリゲート（Aggregate）署名関数を用いて電子署名を作成することを特徴とする電子文書管理プログラム。
4. 請求項１に記載の電子文書管理プログラムにおいて、
   更に、予め規定されたポリシ情報を保管するポリシ情報保管ステップと、
   前記文書情報に訂正があった場合に、訂正された部分の訂正履歴に関する情報である部分訂正情報を生成する部分訂正情報生成ステップとを備え、
   前記管理ステップは、前記文書情報の一部に対して訂正があった場合、前記部分訂正情報生成ステップにより部分訂正情報を生成させ、生成された部分訂正情報と、前記所定のポリシ情報保管ステップにより保管されているポリシ情報とを更に前記訂正された文書情報に対応させて管理し、
   前記検証ステップは、前記訂正された文書情報の正当性を、該文書情報に関連付けられて前記管理ステップにより管理されている前記訂正部分の訂正前の識別情報と位置情報及び前記電子署名に加え、更に前記部分訂正情報と、前記ポリシ情報とを用いて検証することを特徴とする電子文書管理プログラム。
5. 請求項１に記載の電子文書管理プログラムにおいて、
   前記部分識別情報生成ステップは、文書情報を複数の部分に区切り、各部分の文書情報に対してハッシュ関数を用いて識別情報を生成することを特徴とする電子文書管理プログラム。
6. 請求項１に記載の電子文書管理プログラムにおいて、
   前記管理ステップにより管理される前記情報は、階層的な文書構造を持つXMLデータにより構成されることを特徴とする電子文書管理プログラム。
7. 請求項１に記載の電子文書管理プログラムにおいて、
   前記電子署名作成ステップで作成された電子署名を暗号化する暗号化ステップを備える電子文書管理プログラム。
8. 電子情報で作成され登録される文書情報を管理する電子文書管理システムであって、
   文書情報を複数の部分に区切り、各部分の情報に基づいて生成した各部分の識別情報と各部分の位置情報とからなる部分識別情報を生成する部分識別情報生成部と、
   文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成部と、
   文書情報を管理する管理部と、
   管理されている文書情報の正当性を検証する検証部とを有し、
   前記管理部は、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成部により作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての識別情報と該訂正部分の位置情報とを得ると共に、前記電子署名作成部により、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての識別情報と該訂正部分の位置情報とを訂正された文書情報に対応付けて管理し、
   前記検証部は、前記管理部により前記訂正された文書情報に対応付けられて管理されている前記訂正部分の訂正前の識別情報と位置情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成部により部分識別情報を生成させて得られた部分識別情報とを用いて検証する
   ことを特徴とする電子文書管理システム。
9. 電子情報で作成され登録される文書情報をコンピュータにより管理する電子文書管理方法であって、
   コンピュータが、文書情報を複数の部分に区切り、各部分の情報に基づいて生成した各部分の識別情報と各部分の位置情報とからなる部分識別情報を生成する部分識別情報生成ステップと、
   コンピュータが、文書情報に対応する電子署名を前記部分識別情報を用いて作成する電子署名作成ステップと、
   コンピュータが文書情報を管理する管理ステップと、
   コンピュータが、管理されている文書情報の正当性を検証する検証ステップとを有し、
   前記管理ステップは、文書情報の新規登録に際しては、前記文書情報に対応付けて前記電子署名作成ステップにより作成された電子署名を管理し、文書情報の訂正に際しては、該訂正前の文書情報の訂正部分についての識別情報と該訂正部分の位置情報とを得ると共に、前記電子署名作成ステップにより、該訂正された文書情報に対する電子署名を作成し、該電子署名と該訂正前の文書情報の訂正部分についての識別情報と該訂正部分の位置情報とを訂正された文書情報に対応付けて管理し、
   前記検証ステップは、前記管理ステップにより前記訂正された文書情報に対応付けられて管理されている前記訂正部分の訂正前の識別情報と位置情報及び前記電子署名と、前記訂正された文書情報に対して前記部分識別情報生成ステップにより部分識別情報を生成させて得られた部分識別情報とを用いて検証する
   ことを特徴とする電子文書管理方法。