JP4339891B2 - 電子文書管理システム - Google Patents

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上述した課題を解決するため、本発明は、電子情報で作成される文書情報を管理する電子文書管理システムであって、予め規定されたポリシ情報を保管するポリシ情報保管部と、文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成部と、前記文書情報の各部分に訂正指示があった場合に、訂正された部分の訂正履歴に関する情報である部分訂正情報を生成する部分訂正情報生成部と、前記文書情報と前記部分識別情報生成部で生成された部分識別情報と前記部分訂正情報生成部で生成された部分訂正情報と前記ポリシ情報保管部に保管されているポリシ情報とを関連付けて管理する管理部と、文書情報の正当性を前記管理部により関連付けられている部分識別情報、部分訂正情報を用いて検証する登録文書検証部とを備えることを特徴とする。

この電子文書管理システムにおいて、前記部分識別情報生成部は、文書情報を複数の部分に区切り、各部分の情報に基づいて前記部分識別情報を生成することを特徴とすることができる。また、この電子文書管理システムにおいて、前記登録文書検証部は、部分訂正に関する整合性を確認することを特徴とすることができる。さらに、この電子文書管理システムにおいて、複数のエンティティ間において前記管理部により管理されている情報の送受信を行う送受信部を備えることを特徴とすることができる。

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

また、本発明の電子文書管理システムにおいて、前記部分識別情報生成部は、前記各部分の情報に任意情報を加えて前記部分識別情報を生成することを特徴とする。

この電子文書管理システムにおいて、前記部分識別情報生成部は、文書情報が訂正された場合において、前版から訂正された箇所のみ新たな部分識別情報を生成することを特徴とすることができ、またこの電子文書管理システムにおいて、文書情報と部分識別情報と部分訂正情報のそれぞれに署名が付与されていることを特徴とすることができる。さらに、本発明の電子文書管理システムにおいて、前記文書情報に訂正が行われた場合に、ポリシ情報を用いて訂正可能範囲において訂正が行われていることを検証する登録ポリシ検証部を備えることを特徴とすることができる。

また、前記管理部により管理される前記情報は、階層的な文書構造を持つXMLデータにより構成されることを特徴とすることができる。また、前記部分識別情報生成部は、前記文書情報の各部分の訂正指示に従い、階層的な文書構造を持つXMLデータの訂正において、前版から訂正された箇所、並びに訂正されていない箇所の全ての親要素、子要素を対象として部分識別情報を生成することを特徴とすることができる。

また、前記部分識別情報生成部は、前版から訂正された箇所については、子要素とその属する親要素を対象として部分識別情報を生成し、親要素に属する全ての子要素に訂正がない箇所については、当該親要素のみを対象として部分識別情報を生成することを特徴とすることができる。

また、前記部分識別情報生成部は、訂正箇所として記録された親要素の部分識別情報は、次回訂正時に当該箇所に対して訂正がない場合は、前記記録された親要素の部分識別情報を流用することを特徴とすることができる。

さらに、前記部分識別情報生成部は、前版から訂正された箇所のみ、子要素とその属する親要素を対象として部分識別情報を生成し、前記管理部は前版からの差分のみの部分識別情報を管理することを特徴とすることができる。

さらにまた、前記部分識別情報生成部は、同一要素名が記録された本文についてはXpath機能を用いて、対応する部分識別情報を生成することを特徴とすることができる。

また、前記管理部は、部分識別情報の全版数を連結管理することを特徴とすることができ、また、前記管理部は、当該情報群を１ファイルで管理することを特徴とすることができ、更に前記管理部は、Xlink機能を用いて当該情報群を管理することを特徴とすることができ、更にまた、前記管理部は、時系列に識別可能で、かつ、各版数に対する作成者を識別可能とすることを特徴とすることができる。また、前記管理部は、各版数に対する作成者の識別としてXML部分署名を用いることを特徴とすることもできる。また、前記管理部は、全ての電子情報を版数に対応する原本情報として扱うと共に、版数管理されている原本情報の内容は、各版数の原本情報の内容によって閲覧可能者と閲覧不能者を識別可能とすることを特徴とすることができる。

また、本発明は、コンピュータが電子情報で作成される文書情報の管理処理を行う電子文書管理方法であって、前記コンピュータが作成された文書情報の登録要求を受信する登録要求受信ステップと、前記登録要求受信ステップにおいて受信した文書情報が所定のポリシ情報に適合するか否かを予めポリシ情報が保管されているポリシ保管部の情報を参照して検証する登録ポリシ検証ステップと、前記登録ポリシ検証ステップの検証により前記文書情報が所定ポリシ情報に適合するとした場合に、前記文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成ステップと、前記文書情報と前記部分識別情報と前記ポリシ情報とを関連付けて登録する登録ステップとを実行するものである。

また、本発明は、コンピュータが電子情報で作成される文書情報の管理処理を行う電子文書管理方法であって、前記コンピュータが管理対象の文書情報に対する訂正された文書情報についての訂正要求を受信する訂正要求受信ステップと、前記訂正要求受信ステップにて受信した文書情報がポリシ情報保管部に保管されているポリシ情報に適合するか否か検証する訂正ポリシ検証ステップと、前記訂正ポリシ検証ステップにて、前記文書情報が前記ポリシ情報に適合するとされた場合に、前記訂正された文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成ステップと、訂正ポリシ検証ステップにて前記文書情報が前記ポリシ情報に適合するとされた場合に、前記訂正された部分の訂正履歴に関する情報である部分訂正情報を生成する部分訂正情報生成ステップと、前記訂正された文書情報と前記部分識別情報と前記部分訂正情報と前記ポリシ情報とを関連付けて管理する管理ステップと、文書情報の正当性を前記管理ステップにより関連付けられた部分識別情報、部分訂正情報を用いて検証する登録検証ステップとを実行することを特徴とする。

また、本発明は、電子情報で作成される文書情報の管理をコンピュータに実行させる電子文書管理プログラムであって、作成された文書情報の登録要求を受信する登録要求受信ステップと、前記登録要求受信ステップにおいて受信した文書情報が所定のポリシ情報に適合するか否かを予めポリシ情報が保管されているポリシ保管部の情報を参照して検証する登録ポリシ検証ステップと、前記登録ポリシ検証ステップの検証により前記文書情報が所定ポリシ情報に適合するとした場合に、前記文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成ステップと、前記文書情報と前記部分識別情報と前記ポリシ情報とを関連付けて登録する登録ステップとをコンピュータに実行させる。

また、本発明は、電子情報で作成される文書情報の管理をコンピュータに実行させる電子文書管理プログラムであって、管理対象の文書情報に対する訂正された文書情報についての訂正要求を受信する訂正要求受信ステップと、前記訂正要求受信ステップにて受信した文書情報がポリシ情報保管部に保管されているポリシ情報に適合するか否か検証する訂正ポリシ検証ステップと、前記訂正ポリシ検証ステップにて、前記文書情報が前記ポリシ情報に適合するとされた場合に、前記訂正された文書情報の各部分を識別可能に表す部分識別情報を生成する部分識別情報生成ステップと、訂正ポリシ検証ステップにて前記文書情報が前記ポリシ情報に適合するとされた場合に、前記訂正された部分の訂正履歴に関する情報である部分訂正情報を生成する部分訂正情報生成ステップと、前記訂正された文書情報と前記部分識別情報と前記部分訂正情報と前記ポリシ情報とを関連付けて管理する管理ステップと、文書情報の正当性を前記管理ステップにより関連付けられた部分識別情報、部分訂正情報を用いて検証する登録検証ステップとをコンピュータに実行させる。

この電子文書管理プログラムにおいて、前記部分識別情報生成ステップは、文書情報を複数の部分に区切り、各部分の情報に基づいて前記部分識別情報を生成することをコンピュータに実行させることを特徴とすることができ、また、前記部分識別情報生成ステップは、前記部分識別情報をハッシュ関数を用いて生成することをコンピュータに実行させることを特徴とすることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、図示したフローチャートやステップに示された各動作をコンピュータにより実行させるプログラムを提供することにより、本発明の電子文書管理プログラムを提供することができる。これらプログラムはコンピュータにより読取可能な媒体に記録されてコンピュータにより実行させることができる。ここで、コンピュータにより読取可能な媒体としては、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。

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

Claims (10)

1. 電子情報で作成される文書情報を管理する電子文書管理システムであって、
   新規登録される文書情報の各部分を符号化し、符号化された部分を前記各文書部分の各部分と対応付けて識別可能に表す部分識別情報を生成する処理と、前記文書情報の各部分に訂正指示があった場合、前記文書情報中の訂正指示により変更された部分を新たに符号化し、該新たに符号化した情報に基づいて前記部分識別情報を訂正して新たな部分識別情報として生成する処理とを実行する部分識別情報生成部と、
   前記文書情報の各部分に訂正指示があった場合に、訂正された部分についての訂正履歴を表す部分訂正情報を生成する部分訂正情報生成部と、
   新規登録される前記文書情報と前記部分識別情報生成部で生成された部分識別情報とを関連づけて記憶する処理と、前記文書情報の各部分に訂正指示があった場合、訂正により改版された文書情報と新たに生成された部分識別情報と前記部分訂正情報とを関連付けて記憶する処理とを実行する管理部と、
   文書情報の正当性を検証する要求があった場合に、前記管理部により当該文書情報と関連付けられて記憶された部分訂正情報により前記文書情報において訂正された箇所を特定し、当該文書情報と関連付けられた部分識別情報と当該文書情報の訂正前の版と関連付けられた部分識別情報とを比較し、前記特定された箇所の訂正がなされ、かつ特定された箇所以外は訂正されていないことを確認することにより正当性を検証する登録文書検証部と、
   を備えることを特徴とする電子文書管理システム。
2. 請求項１に記載の電子文書管理システムにおいて、
   前記部分識別情報生成部は、文書情報を一文字単位もしくはＸＭＬデータにおいては一要素単位に区切り、各部分の情報を符号化して前記部分識別情報を生成することを特徴とする電子文書管理システム。
3. 請求項１に記載の電子文書管理システムにおいて、
   前記管理部により管理される部分識別情報、部分訂正情報は、階層的な文書構造を持つＸＭＬデータにより構成されることを特徴とする電子文書管理システム。
4. 請求項１に記載の電子文書管理システムにおいて、
   予め決められた作成者、必要記載事項、および文書情報の作成及び訂正についての条件が規定されたポリシ情報を保管するポリシ情報保管部をさらに有し、
   前記部分識別情報生成部は、前記文書情報が前記ポリシ情報の規定を満たした場合に部分識別情報の生成処理を行うことを特徴とする電子文書管理システム。
5. コンピュータが電子情報で作成される文書情報の管理処理を行う電子文書管理方法であって、
   前記コンピュータが作成された文書情報の登録要求を受信する登録要求受信ステップと、
   前記文書情報の各部分を符号化し、符号化された部分を前記文書情報の各部分と対応付けて識別可能に表す部分識別情報を生成する第一の部分識別情報生成ステップと、
   前記文書情報と前記部分識別情報とを関連付けて登録する第一の登録ステップと、
   前記コンピュータが前記文書情報の訂正指示を受信する訂正要求受信ステップと、
   前記訂正要求に基づいて訂正された前記文書情報の部分を新たに符号化し、該新たに符号化した情報に基づいて前記部分識別情報を訂正して新たな部分識別情報として生成する第二の部分識別情報生成ステップと、
   前記訂正要求に基づいて前記文書情報の訂正された部分についての訂正履歴を表す部分訂正情報を生成する部分訂正情報生成ステップと、
   前記訂正により改版された文書情報と前記第二の部分識別情報生成ステップで生成された部分識別情報と前記部分訂正情報とを関連付けて登録する第二の登録ステップと、
   文書情報の正当性を検証する要求があった場合に、前記第二の登録ステップにて当該文書情報と関連付けられて記憶された部分訂正情報により前記文書情報において訂正された箇所を特定し、当該文書情報と関連付けられた部分識別情報と当該文書情報の訂正前の版と関連付けられた部分識別情報とを比較し、前記特定された箇所の訂正がなされ、かつ特定された箇所以外は訂正されていないことを確認することにより正当性を検証する登録文書検証ステップと、
   を実行する電子文書管理方法。
6. 電子情報で作成される文書情報の管理をコンピュータに実行させる電子文書管理プログラムであって、
   前記コンピュータが作成された文書情報の登録要求を受信する登録要求受信ステップと、
   前記文書情報の各部分を符号化し、符号化された部分を前記文書情報の各部分と対応付けて識別可能に表す部分識別情報を生成する第一の部分識別情報生成ステップと、
   前記文書情報と前記部分識別情報とを関連付けて登録する第一の登録ステップと、
   前記コンピュータが前記文書情報の訂正指示を受信する訂正要求受信ステップと、
   前記訂正要求に基づいて訂正された前記文書情報の部分を新たに符号化し、該新たに符号化した情報に基づいて前記部分識別情報を訂正して新たな部分識別情報として生成する第二の部分識別情報生成ステップと、
   前記訂正要求に基づいて前記文書情報の訂正された部分についての訂正履歴を表す部分訂正情報を生成する部分訂正情報生成ステップと、
   前記訂正により改版された文書情報と前記第二の部分識別情報生成ステップで生成された部分識別情報と前記部分訂正情報とを関連付けて登録する第二の登録ステップと、
   文書情報の正当性を検証する要求があった場合に、前記第二の登録ステップにて当該文書情報と関連付けられて記憶された部分訂正情報により前記文書情報において訂正された箇所を特定し、当該文書情報と関連付けられた部分識別情報と当該文書情報の訂正前の版と関連付けられた部分識別情報とを比較し、前記特定された箇所の訂正がなされ、かつ特定された箇所以外は訂正されていないことを確認することにより正当性を検証する登録文書検証ステップと、
   をコンピュータに実行させるための電子文書管理プログラム。
7. 請求項６に記載の電子文書管理プログラムにおいて、
   前記部分識別情報生成ステップは、文書情報を一文字単位もしくはＸＭＬデータにおいては一要素単位に区切り、各部分の情報を符号化して前記部分識別情報を生成することをコンピュータに実行させるための電子文書管理プログラム。
8. 請求項６に記載の電子文書管理プログラムにおいて、
   前記管理ステップにより管理される部分識別情報、部分訂正情報は、階層的な文書構造を持つＸＭＬデータにより管理されることを特徴とする電子文書管理プログラム。
9. 請求項６に記載の電子文書管理プログラムにおいて、
   前記部分識別情報生成ステップは、前記文書情報の各部分の訂正指示に従い、階層的な文書構造を持つＸＭＬデータの訂正において、文書全体を対象として、前記文書情報の各部分を符号化し、符号化された部分を前記文書情報の各部分と対応付けて識別可能に表す部分識別情報を生成することを特徴とする電子文書管理プログラム。
10. 請求項６に記載の電子文書管理プログラムにおいて、
    前記第一の部分識別情報生成ステップ及び前記第二の部分識別情報生成ステップでは、予め決められた作成者、必要記載事項、および文書情報の作成及び訂正についての条件が規定されたポリシ情報が保管されたポリシ情報保管部から、ポリシ情報を読み出して、処理対象の文書情報が前記ポリシ情報の規定を満たした場合に部分識別情報の生成処理を行うことを特徴とする電子文書管理システム。

Images