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

電子文書管理プログラム、電子文書管理システム及び電子文書管理方法 Download PDF

Info

Publication number
JP2007156970A
JP2007156970A JP2005353525A JP2005353525A JP2007156970A JP 2007156970 A JP2007156970 A JP 2007156970A JP 2005353525 A JP2005353525 A JP 2005353525A JP 2005353525 A JP2005353525 A JP 2005353525A JP 2007156970 A JP2007156970 A JP 2007156970A
Authority
JP
Japan
Prior art keywords
information
document management
electronic document
electronic
partial signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2005353525A
Other languages
English (en)
Other versions
JP4739000B2 (ja
Inventor
Koji Yoshioka
孝司 吉岡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2005353525A priority Critical patent/JP4739000B2/ja
Priority to US11/544,404 priority patent/US8028169B2/en
Priority to EP06122206.3A priority patent/EP1806678A3/en
Priority to KR1020060103928A priority patent/KR100822596B1/ko
Priority to CN2006101366716A priority patent/CN1992586B/zh
Publication of JP2007156970A publication Critical patent/JP2007156970A/ja
Application granted granted Critical
Publication of JP4739000B2 publication Critical patent/JP4739000B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/68—Special signature format, e.g. XML format

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Document Processing Apparatus (AREA)

Abstract

【課題】 電子データの部分開示・非開示を制御しつつ、かつ非開示情報以外の不変と非開示部分における解読情報の原本性が確保されていることを第三者に証明可能とする。
【解決手段】 閲覧者、システム、時間等の条件や状況に応じて電子情報の部分開示・非開示制御を行う手段を提供し、加えて、電子情報の本文とは別に、ｐｉａｔ署名情報を生成して分割・保持し、電子情報と部分署名情報（検証情報）の持つ機能・役割を明確に分離することで、電子情報の部分開示・非開示を制御し、かつ非開示情報以外の不変と非開示部分における解読情報の原本性が確保されていることを第三者に証明可能とする。
【選択図】 図１

Description

本発明は、電子データの部分開示・非開示を制御しつつ、かつ非開示情報以外の不変と非開示部分における解読情報の原本性が確保されていることを第三者に証明可能とするための電子文書管理プログラム、電子文書管理システム及び電子文書管理方法に関するものである。
近年のＩＴの進展に伴い、行政文書や民間企業の帳簿、契約書等の形態は、従来の紙文書での運用、保管から電子（ディジタル）文書へと徐々に移行されつつある。具体的には、スキャナ装置の普及に伴い、従来、紙で保存されていた文書を容易に電子データ化することが可能となった。更に、高解像度を内蔵するスキャナ装置の実用化に伴い、一定のセキュリティ要件を満足すれば従来認められなかった紙文書の電子保存が容認されるようになった（e-文書法:２005年４月施行に伴う）。
一方でこのような文書や画像等の電子保存要求の増加とともに、電子データを安全に保管、管理する技術の必要性が高まっている。従来、紙として保存されていた文書を、紙と同等の証拠能力を維持した状態で電子的に保存するためには、「改ざん検出・防止」、「作成者の識別」、「アクセス管理・制御」、「履歴管理」等の技術要件を満たす必要があると言われている。このような要件を満たすためには、従来の文書管理システムでは機能不足であり、最近では、本技術要件を満足する「原本性保証システム」の開発、市場投入が急速に進んでいる。
この「原本性保証システム」において、最も一般的に用いられているセキュリティ要素技術が電子署名である。電子署名は、文書の作成者を特定できる（本人性）のと同時に、その文書が作成時点から変更がないこと（非改ざん性）を第三者に証明・確認できる技術である。また、タイムスタンプという技術もある。これは、電子署名によく似た技術であるが、電子署名の機能に加え、電子文書の確定時刻を証明することが可能である。関連する従来技術（公知）３件について以下に列挙する。
（１）電子文書原本保管技術
電子文書の原本性を確保する技術として、下記特許文献１，２が知られる。
（２）電子文書墨塗り技術
電子文書の墨塗り問題を解決する技術として、下記非特許文献１にて解決方式が提案されている。また、下記非特許文献２では、開示部分に対する追加的な墨塗りの可否を制御可能とする電子文書墨塗り技術についても提案されている。
（３）XACML（eXtensible Access Control Markup Language）
本技術は、２００３年２月にOASIS（Organization for the Advancement of Structured Information Standards）が標準承認した仕様であり、ＸＭＬ（eXtensible Markup Language）文書に対するアクセス権を設定するための仕様である。あるリソースに対して、「だれ」がどのような「権限」で「どこ」にアクセスできるのかを記述が可能である。例えば、"２０才以上のユーザ"、"ユーザ登録している者のみ"等、複雑な条件判断によるアクセス制御が可能となる。
特開２０００−２８５０２４号公報 特開２００１−１１７８２０号公報 情報処理学会／コンピュータセキュリティ研究会（CSEC）論文「電子文書墨塗り問題（2003/7/17）（2003-CSEC-22-009） SCIS2004論文「開示条件を制御可能な電子文書墨塗り技術」
従来技術のような原本性保証の考え方では、確定された最終形態の文書を原本として安全に管理する、いわゆる紙文書を鍵付きロッカー等に保管するのと同様、原本の所在が明確である文書を対象としている。このような環境においては、電子署名は本人性や非改ざん性を保証するのに非常に有効な技術となる。
しかしながら、申請書や稟議書のように、文書自身に直接追加や訂正、秘匿等の部分操作や加工がなされ、転々流通する文書の原本性保証を考えた場合には、一般的な電子署名方式ではその性質上、一切の加工が許されないために逆に障害となる。つまり、従来技術では、以上のように文書に対する操作や加工あるいはその流通性等が考慮されておらず、電子署名を使って電子データを完全なまま保存するための技術が中心であった。
以下に上記（１）〜（３）に示した従来技術の問題点について述べる。
（１）電子文書原本保管技術
特許文献１や特許文献２の技術は、電子データを保存する際に紙の原本が有する性質を電子情報に持たせる、また、電子データが改ざんされないように保護する、あるいは、改ざんされたら検出できる技術を提供している。
つまり、これらの技術は、確定された最終形態の電子文書を原本として安全に保管、管理する機構、いわゆる原本の所在が明確であり、一組織内に蓄えられる原本をいかに安全に保管するかという点に注目している。
このような原本保管環境においては、電子文書に対して訂正が発生した場合、一部でも訂正を行った場合は“改ざん”と認識されてしまう。例えば、“紙の契約文書への訂正”を考えた場合、訂正の際は、「訂正箇所の文字を二重線で消し、すぐ上の余白に訂正文字を記入し、訂正者印を押印する」といった処理が行われているが、訂正を加えても契約文書の原本には相違ない。
紙文化におけるこのような行為は、正当な手続きを踏んで訂正を行っていると公的に判断され、第三者的に証明が可能となっている。
これに対して電子文書の場合、証拠性という観点から従来の原本保管技術を適用すると、訂正部分は改ざんされたものなのか、正当な手続きを経て訂正されたものなのか識別できないという問題が生じる。これは、電子データに対するいかなる改変も検知できるように設計されている現状の電子署名の特徴からも言えることである。
（２）電子文書墨塗り技術
「電子文書墨塗り問題」における論文では、ある文書に対して施された署名が、文書の一部を秘匿することによって検証できなくなる問題を解決する電子文書の墨塗り技術を提案している。本論文の電子文書墨塗り技術を適用することにより、署名付き電子文書に対して墨塗りを施した状態でも署名検証が可能、且つ墨塗り箇所以外は改変がないことを第三者証明することが可能となり、「一部の内容を隠した（墨塗りを施した）状態での第三証明」が可能になる。
しかしながら、上記論文の電子文書墨塗り技術では、オリジナル文書の作成者を保証しており、誰が墨塗りを行ったかまで明確に識別することができない。更に、利用シーンとして情報公開制度における電子文書墨塗り問題を取り挙げており、例えば、対象は行政機関と住民（区民）の１対１のやりとりである。よって、一部墨塗りした文書を複数のエンティティ間で流通させ、当該文書を更に利用することまでは考慮されていない。
また、墨塗り箇所の情報に対して、ハッシュ情報と置き換えて実現しているため、閲覧者等の条件や状況による部分開示・非開示制御ができない。さらに非開示情報の内容が本人作成のものであり、改変がないことを閲覧側で確認・証明することができない。
（３）XACML（eXtensible Access Control Markup Language）：ＸＭＬ文書に対するアクセス権を設定するための仕様
この技術は、あるリソースに対して、「だれ」がどのような「権限」で「どこ」にアクセスできるかを制御可能とする技術である。この従来技術では、部分開示・非開示制御が可能で、閲覧が許可されたエンティティ（人やシステム等を指す）以外には非開示情報が漏洩しないことが証明可能とされる事に特化して実現されたものであり、非開示情報以外が改変されていない（原本性、完全性）ことの証明、ならびに、非開示情報の内容が本人作成のものであり、且つ改変がないことを閲覧側で確認し、又は証明することができない。
本発明は、上述した問題点を解決するためになされたものであり、電子データの部分開示・非開示を制御するとともに非開示情報以外の不変と非開示部分における解読情報の原本性が確保されていることを第三者に証明可能とすることを目的とする。
上記課題を解決するために、本発明では、閲覧者、システム、時間等の条件や状況に応じて電子情報の部分開示・非開示制御を行う手段を提供し、加えて、電子情報の本文とは別に部分署名情報（本発明の実施の形態では、ｐｉａｔ署名情報と表記する）を生成して分割・保持し、電子情報と部分署名情報（検証情報）の持つ機能・役割を明確に分離することで、電子情報の部分開示・非開示を制御し、且つ非開示情報以外の不変と非開示部分における解読情報の原本性が確保されていることを第三者に証明可能とするための技術思想を提供する。
本発明は、電子情報で作成される文書情報を原本情報として管理することをコンピュータに実行させる電子文書管理プログラムであって、前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理ステップと、前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理ステップと、前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理ステップとをコンピュータに実行させるものである。
また、本発明の電子文書管理プログラムにおいては、さらに、文書情報の管理を受け付ける受付処理ステップと、前記鍵生成・管理ステップにおいて管理されている暗号化鍵の時限情報を管理するための時限管理ステップと、前記文書管理ステップにおいて管理されている前記一体化原本情報から公開に用いられる原本情報を公開する情報公開ステップとをコンピュータに実行させるものである。
また、本発明の電子文書管理プログラムにおいて、前記部分署名処理ステップは、前記部分署名情報を生成処理するための部分署名生成ステップと、前記部分署名情報を用いて検証処理を行うための部分署名検証ステップを備えることを特徴とする。
また、本発明の電子文書管理プログラムにおいて、前記部分署名生成ステップは、原本情報を複数の部分に区切り、各部分の情報に基づいて前記部分署名情報を生成することを特徴とする。
なお、実施の形態においては、前記部分署名生成ステップは、一方向性ハッシュ関数を用いて前記部分署名情報を生成する。
また、前記部分署名生成ステップは、前記各部分の情報の他に任意情報を加えて、前記部分署名情報を生成する。
さらに、前記部分署名情報は、前記各部分の情報の他に加える任意情報として、乱数を用いることを特徴とする。
また、前記部分署名情報は、前記各部分の情報の他に加える任意情報として、日時情報を用いる。
更に、本実施の形態において、前記部分署名生成ステップは、原本情報に対して部分訂正や追加、墨塗り等の変更がなされた場合において、前版から変更された箇所のみ異なる任意情報を用いて新たな部分署名情報を生成し、変更箇所以外は前版と同一の任意情報を用いて部分署名情報を生成する。
また、前記部分署名検証ステップは、条件や状況等に応じて部分開示・非開示制御をしつつ、且つ非開示情報以外が不変であること、及び非開示情報の原本性が確保されていることの確認を行う。
また、本発明の電子文書管理プログラムにおいて、前記鍵生成・管理ステップは、生成した前記暗号化鍵を閲覧が許可されたエンティティ（人やシステム等を指す）の公開鍵で更に暗号化して管理することを特徴とすることができる。
また、本発明の電子文書管理プログラムにおいて、前記時限管理ステップは、前記鍵生成・管理部において管理されている暗号化鍵の時限情報を保持し、該時限情報を用いてアクセス制御を行うことを特徴とすることができる。
また、本発明の電子文書管理プログラムにおいて、前記時限管理ステップで管理されている暗号化鍵の時限情報を用いて、有効期限が切れている場合は、該暗号鍵、ならびに該原本情報へのアクセスを無効にすること特徴とすることができる。
また、本発明の電子文書管理プログラムにおいて、前記情報公開ステップは、前記文書管理ステップと連携して公開情報のみを取得して蓄積し、公開を行うことを特徴とすることができる。
また、本発明の電子文書管理プログラムにおいて、前記部分署名処理ステップは、前記部分署名情報を生成処理するための部分署名生成ステップと、前記部分署名情報を用いて検証処理を行うための部分署名検証ステップを備えることを特徴とすることができる。
また、本発明の電子文書管理プログラムにおいて、原本情報と部分署名情報のそれぞれに電子署名が付与されていることを特徴とすることができる。
さらに、本発明の電子文書管理プログラムにおいて、原本情報と部分署名情報のそれぞれにタイムスタンプが付与されていることを特徴とすることができる。
また、本発明の電子文書管理プログラムにおいて、前記文書管理ステップは、登録される電子情報をすべて原本情報として扱い、変更の際には旧版を残して更新文書として新たな登録文書として保管し、版数管理を自動的に行うことを特徴とすることができる。
ここで、前記文書管理ステップは、原本情報、部分署名情報の各情報を分割して管理し、相互に関連付けて一元的に管理・制御することを特徴とすることができる。
また、本発明は、電子情報で作成される文書情報を原本情報として管理する電子文書管理システムであって、前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理部と、前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理部と、前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理部とを備えてなる。
また、本発明は、電子情報で作成される文書情報を原本情報として管理することをコンピュータにより行う電子文書管理方法であって、前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理ステップと、前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理ステップと、前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理ステップとを備えるものである。
本発明によれば、以下のような効果を奏する。
（１）部分開示・非開示制御が可能で、閲覧が許可されたエンティティ（人やシステム等を指す）以外は非開示情報が漏洩しないことが証明可能である。
（２）非開示箇所とそれ以外の箇所が区別可能で、非開示情報以外が改変されていないことが証明可能（原本性、完全性の保証）である。
（３）非開示制御を誰が行ったか特定することができ、またそれを証明することができる。
（４）非開示情報の内容が本人作成のものであり、改変がないことが証明可能である。
（５）一部を秘匿しても、秘匿した箇所以外の部分が改変されていないことが証明可能である。
（６）一部を秘匿しても、秘匿していない部分の作成者が証明可能である。
（７）原本（第１版）からの履歴過程（いつ、誰が、どの箇所を、どのように）を証明可能である。
（８）本システム内に保存・管理されている全ての版数の電子データを取り出さなくても、一部墨塗りされた状態や一部の版のみを用いた第三者証明や流通を行うことが可能である。
本発明における一実施例として、閲覧が許可されたエンティティを人（閲覧者、利用者）であることを想定し、閲覧者制御機能付き部分完全性保証システムの原理を示す構成例を図１に示す。図１に示す閲覧者制御機能付き部分完全性保証システム１０は、受付処理部２０、文書管理部３０、ｐｉａｔ署名処理部４０、鍵生成・管理部５０、時限管理部６０、および情報公開部７０を備える。以下に各部の構成・役割を示す。
（受付処理部２０）
受付処理部２０は、利用者（９０−Ａ，Ｂ，Ｃ，・・・）やポータルサイト提供部１００、ＣＡ（第三者発行機関（Certificate Authority））２００、ＴＡ（時刻配信局（Time Authority））３００からの入力情報の受信、ならびに上記記載の各部への出力情報の送信を行う中枢部である。上記記載の各部４０〜７０からの処理依頼を受け付け、文書管理部３０への処理仲介を行い、その結果を返す。
（文書管理部）
文書管理部３０は、受付処理部２０から入力処理要求を受け付け、各要求に応じた処理を実行する手段を提供する。文書管理部３０は、処理した電子情報を記憶しておく文書管理用ＤＢ（データベース）３１と、処理した電子情報のエントリ情報を管理する文書管理ＴＢ（テーブル）３２の２つのサブ要素から構成される。
（文書管理用ＤＢ３１）
文書管理用ＤＢ３１は、文書管理部３０内で管理されており、格納依頼を受け付けると、電子情報と部分署名情報を一体化した形で格納処理を行う。
（文書管理ＴＢ３２）
文書管理ＴＢ３２は、文書管理部３０内で管理されており、文書管理用ＤＢ３１への格納処理が行われると同時に処理した電子情報のエントリ情報の管理を行う。
（ｐｉａｔ署名処理部４０）
ｐｉａｔ署名処理部４０は、文書管理部３０からのｐｉａｔ署名処理依頼を受け付け、各要求に応じた処理を実行する手段を提供する。ｐｉａｔ署名処理部４０は、ｐｉａｔ署名生成部４１と、ｐｉａｔ署名検証部４２の２つのサブ要素から構成する。
（ｐｉａｔ署名生成部４１）
ｐｉａｔ署名生成部４１は、文書管理部３０からのｐｉａｔ署名生成依頼を受け付け、電子情報に対する部分署名情報の生成を行う。
（ｐｉａｔ署名検証部４２）
ｐｉａｔ署名検証部４２は、文書管理部３０からのｐｉａｔ署名検証依頼を受け付け、電子情報に対する部分署名情報の検証を行う。
（鍵生成・管理部５０）
鍵生成・管理部５０は、文書管理部３０からの鍵生成・管理処理依頼を受け付け、閲覧者制御を行うための暗号鍵の生成と管理を行う手段を提供する。鍵生成・管理部５０は、生成した暗号鍵を記憶しておく鍵ＤＢ（鍵データベース）５１のサブ要素から構成される。
（鍵ＤＢ５１）
鍵ＤＢ５１は、鍵生成・管理部５０内で管理されており、格納依頼を受け付けると、閲覧者制御を行うための暗号鍵の格納処理を行う。
（時限管理部６０）
時限管理部６０は、文書管理部３０からの処理依頼を受け付け、管理されている時限情報の抽出、ならびに暗号鍵の時限検証を行う。
（情報公開部７０）
情報公開部７０は、文書管理部３０からの処理依頼を受け付け、文書管理部３０内の文書管理用ＤＢ３１から公開情報のみ取得して蓄積し、各利用者９０に公開する。情報公開部７０は、情報公開用ＤＢ７１のサブ要素から構成する。
（情報公開用ＤＢ７１）
情報公開用ＤＢ７１は、情報公開部７０内で管理されており、格納依頼を受け付けると、電子情報と部分署名情報を一体化した形で格納処理を行う。
以上が閲覧者制御機能付き部分完全性保証システム１０の各部の構成・役割である。以下、これより、閲覧者制御機能付き部分完全性保証システム１０の周辺に存在する外部アクタについて説明する。
（電子通信路８０）
電子通信路８０は、各アクタからの処理要求、ならびに電子情報を送信、流通させる手段となり、閲覧者制御機能付き部分完全性保証システム１０、および周辺に存在する外部アクタは全てこの電子通信路８０に接続される。電子通信路８０は、例えば、インターネットやイントラネット、エクストラネット、ワイドエリアネットワーク等のあらゆる通信プロトコルに相当する。
（利用者９０）
利用者９０は閲覧者制御機能付き部分完全性保証システム１０、ポータルサイト提供部１００を利用するアクタであり、電子通信路８０を経由して閲覧者制御機能付き部分完全性保証システム１０、ポータルサイト提供部１００にアクセスする。
（ポータルサイト提供部１００）
ポータルサイト提供部１００は、閲覧者制御機能付き部分完全性保証システム１０へ処理要求を送信する際に必要な電子情報を生成するため、入力フォームや処理メニュー等を提供する手段に相当し、場合によっては、閲覧者制御機能付き部分完全性保証システム１０と連携した形で提供される場合もあり得る。
（ＣＡ２００）
ＣＡ２００は、電子情報は誰が作成したかを確認でき、かつその電子情報は改ざんがないことを保証するため、電子情報への電子署名（ＰＫＩ署名）付与に利用するアクタである。ＣＡは、第三者発行機関（Certificate Authority）の略であり、本機関が発行したものを採用することで、情報の信憑性、真実性を強化、厳密な第三者証明を行うことを可能とする。
（ＴＡ３００）
ＴＡ３００は、ＰＫＩ署名の機能に加え、この時点から改ざんされていないことを保証する（電子情報の確定時刻を保証する）ため、電子情報へのタイムスタンプ付与に利用するアクタである。ＴＡは、時刻配信局（Time Authority）の略であり、ＣＡ２００同様、本機関が発行したものを採用することで、情報の信憑性、真実性を強化し、厳密な第三者証明を行うことを可能とする。
以下、利用シーンを想定した本システムの適用方法について述べる。本利用シーンでは、企業・消費者間（B to C: Business to Consumer）の電子商取引（ネットショッピング）における情報流通スキームと自治体文書管理における情報公開スキームの２つの利用形態を想定し説明する。まずは、B to C電子商取引（ネットショッピング）における情報流通スキームで説明する。
利用者が本システムを利用する場面として、電子的に作成した発注書を、あるいは、紙の発注書をスキャナ等の装置を用いて電子化し、署名付き発注書情報として記録・保存する場面が考えられる。また、記録・保存された署名付き発注書情報は、複数のエンティティ間で流通され、事後、必要に応じて発注書情報の正当性確認を行うため、第三者に提示する場合が考えられる。また、複数のエンティティ間で流通がなされる際、必要に応じて部分開示・非開示を行うことが求められる。
例えば、発注書情報は申込者から問屋へ送信され、決済を行うためクレジットカード会社（決済機関）へも送信されるシーンを考えた場合、問屋には重要情報となるクレジットカード番号を秘匿し、クレジットカード会社（決済機関）には、必要に応じて申込者が購入した品物を秘匿する場面が考えられる。このような場合、部分開示・非開示制御が可能で、閲覧可能者以外は非開示情報が漏洩しないことの証明、非開示情報以外が改変されていない（原本性、完全性）ことの証明、非開示情報の内容が本人作成のものであり、改変がないことの証明等、これら開示・非開示操作に対する証拠性、証明性の確保が求められる。
よって、利用者は事後、裁判沙汰等になった場合に証拠として提出できるよう記録を残す手段として、また、第三者に対して発注書情報に対する証明を行う際に本システムを利用する。本利用シーンの登場人物として、発注書情報を本システムに登録する「申込者」と、申込者の依頼によって発注書情報を受信し、申込内容の確認を行って受注処理を行う「問屋」と、「問屋」からの依頼によって、発注所情報を受信し、決済内容の確認を行って決済処理を行う「カード会社」の３者が登場する。
上記利用シーンにおいて、本システムでは申込者、問屋、カード会社に対して以下の４機能を提供する。
（Ａ）登録機能（発注書情報の生成・登録時に申込者が利用）
（Ｂ）確認機能（発注書情報の内容確認時に問屋とカード会社が利用）
（Ｃ）更新機能（発注書情報の受付・承認時に問屋とカード会社が利用）
（Ｄ）取得機能（発注書情報の取得時に申込者、問屋、カード会社が利用）
以下より、上記（Ａ）〜（Ｄ）の各事象における作用について説明する。
本利用シーンの事前条件として、申込者（９０−Ａ）、問屋（９０−Ｂ）、カード会社（９０−Ｃ）は本閲覧者制御機能付き部分完全性保証システム１０、ポータルサイト提供部１００を利用できるよう利用者認証情報が事前登録されており、厳密なアクセス制御がなされていることを前提とする。本利用シーンでは最初から電子情報として扱うことを想定して説明する。
（発注書生成シーケンス）
図２は、発注書生成処理のフローチャート図である。
（１）申込者（９０−Ａ）は、ポータルサイト提供部１００に電子通信路８０を通じて接続し、問屋（９０−Ｂ）が提供するネットショッピングサイトにアクセスする（ステップＳＴ−Ｃ１）。尚この時、本ネットショッピングサイトには申込者（９０−Ａ）の利用者登録がなされていることが前提となる。
（２）申込者（９０−Ａ）は、例えばＩＤ、パスワードでログインし、発注書入力フォーム内に必要情報を入力する（ステップＳＴ−Ｃ２）。この時入力する情報として、氏名や住所等の個人を特定するための情報、品名、個数等を含む注文情報（品名）、クレジットカード情報を含む決済情報（ＮＯ）があるとする。
（３）申込者（９０−Ａ）が入力後確定処理をすると、ポータルサイト提供部１００は閲覧者制御機能付き部分完全性保証システム１０に対して申込者（９０−Ａ）に代わって作成処理要求を発行する（ステップＳＴ−Ｃ３）。尚、ここでポータルサイト提供部１００が、申込者（９０−Ａ）に代わって作成処理要求を発行するようにしているが、入力確定後に発注書データ（例えば、データフォーマットはＸＭＬデータ）を一旦申込者（９０−Ａ）へ返却し、申込者（９０−Ａ）が閲覧者制御機能付き部分完全性保証システム１０に対して作成処理要求を発行するようにしてもよい。
（４）受付処理部２０は、ポータルサイト提供部１００より作成処理要求を受信する。この時受け取る情報は、発注書[Ｄ１−１]（例えば、ＸＭＬデータ形式で受信）であり、秘匿処理条件を有するものとなる。秘匿処理条件とは、例えば、どの箇所を暗号化するか（本例では"注文情報（品名）"と、"決済情報（ＮＯ）"に相当）、また誰が閲覧できるようにするか（本例では"注文情報（品名）"は問屋のみ、"決済情報（ＮＯ）"はカード会社のみ閲覧可能とする）等の情報が含まれていることを意味する。これらの条件設定は問屋（９０−Ｂ）がポータルサイト提供部１００内に条件ポリシとして事前設定しておくのが望ましく、本要求時に自動的に抽出されるものとすればよい。よって、申込者（９０−Ａ）はこれらのセキュリティ設定、制御を意識せず、安全にネットショッピングを利用できる。また、事前設定時には文書毎にＩＤが振られ、一緒に管理されれば、条件ポリシの検索は容易に行える。
（５）受付処理部２０は受信後、文書管理部３０に対し、作成処理要求を発行する。
（６）作成処理要求を受信した文書管理部３０は、ｐｉａｔ署名処理部４０内のｐｉａｔ署名生成部４１に対し、ｐｉａｔ署名情報[Ｈ１−１]の生成要求を発行する（ステップＳＴ−Ｃ４）。この時、発注書[Ｄ１−１]が渡される。ｐｉａｔ署名情報とは、発注書の変更有無を検出し、且つ変更箇所（変更位置）を特定し、これらに加えて、変更箇所以外の不変を第三者に証明可能とするための情報、いわゆる、部分署名情報である。ｐｉａｔ署名情報から発注書の内容が推測されては困るため、一方向性ハッシュ関数と乱数を組み合わせて生成するのが望ましい。
（７）処理要求を受け取ったｐｉａｔ署名生成部４１は、発注書[Ｄ１−１]に対するｐｉａｔ署名情報[Ｈ１−１]を生成する（ステップＳＴ−Ｃ５）。図３は生成処理時のｐｉａｔ署名情報の生成例を示した図である。例えば、乱数“４５６”に、“品物Ａ”という文字列を連結し、文字列“４５６品物Ａ”に対するハッシュ情報を生成。生成結果として、“ＤＥＦ”というハッシュ情報が出力されている様子を示している。（ステップＳＴ−Ｃ５−１）、以下、他項目についても同様の生成処理が行われる。この例では乱数を使用しているが、当該目的のために乱数以外の手法を用いても構わない。例えば、その時点で入力した事を示すため時刻情報を用いてもよい。
（８）文書管理部３０は、ｐｉａｔ署名生成部４１からｐｉａｔ署名情報[Ｈ１−１]を取得する。このｐｉａｔ署名情報[Ｈ１−１]は、上記で示した役割を果たすものと同時に、閲覧者側で非開示情報を解読した際、その内容の原本性を確認するためにも用いられる。ここで発注書[Ｄ１−１]とｐｉａｔ署名情報[Ｈ１−１]が揃うので、各情報に申込者（９０−Ａ）のＰＫＩ（Public Key Infrastructure：公開鍵暗号基盤）を用いた電子署名（以降、ＰＫＩ署名と略）、タイムスタンプ（以降、ＴＳと略）をそれぞれ付与し、これら２つの情報を一体化した状態でＤＢ３１に格納する（ステップＳＴ−Ｃ６）。ＰＫＩ署名については、ＣＡ２００、タイムスタンプについては、ＴＡ３００によりそれぞれ公的機関が発行したものを採用することで、当情報の信憑性、真実性を強化、厳密な第三者証明を行うことを可能とする。
（９）次に部分暗号のフェーズに移る。暗号化のための鍵を生成するため、鍵生成・管理部５０に対し、暗号鍵の生成要求を発行する（ステップＳＴ−Ｃ７）。この時、使う情報は先に取得した秘匿処理条件であり、これらの条件を基に作成を行う。本例では、"注文情報（品名）"と、"決済情報（ＮＯ）"の２箇所を暗号化するため、２つの鍵を生成することとなる。
（１０）鍵生成・管理部５０は、"注文情報（品名）"用と、"決済情報（ＮＯ）"用の暗号鍵（共通鍵）を生成し、鍵ＤＢ５１に格納する（ステップＳＴ−Ｃ８）。図４は鍵ＤＢ５１内の状態を示している。鍵ＤＢ５１には、以下の方法で格納される。各秘匿箇所用の暗号鍵（共通鍵）を各閲覧可能者の公開鍵情報で暗号化を行う。本例では、"注文情報（品名）"に関しては、"注文情報（品名）"用の暗号鍵（共通鍵）を問屋（９０−Ｂ）の公開鍵情報で、"決済情報（ＮＯ）"用の暗号鍵（共通鍵）をカード会社９０−Ｃの公開鍵情報で暗号化を行う。
これにより、本例では１箇所に対して１人の閲覧者制御の場合を示しているが、これが１箇所に対して複数人の閲覧者がいる場合にも同様の方法で管理すれば柔軟に対応できる。また、この暗号鍵（共通鍵）を時限管理部６０で制御・管理することで、復号後の鍵漏洩を防止できる。言い換えれば、当暗号鍵で暗号化された発注書情報に含まれた重要情報（クレジットカード番号等）の漏洩を防止することができる。例えば、新規に発注書情報が生成されてから２週間は復号できる状態（決済できる状態）にして、それ以降は復号できないよう制御することで安全性を確保するのに使える。
（１１）文書管理部３０は、鍵生成・管理部５０から暗号鍵を受信し、発注書[Ｄ１−１]内の各秘匿箇所に対し、各秘匿箇所用の暗号鍵で暗号化処理を行う（ステップＳＴ−Ｃ９）。この時、発注書[Ｄ１−１]中の秘匿各箇所の乱数と、暗号化対象情報を連結したものを暗号化する（図３中のステップＳＴ−Ｃ９−１）。具体的には、"注文情報（品名）"については、"４５６+品物Ａ"の内容を暗号化し、"決済情報（ＮＯ）"については、"７８９＋１２３４"の内容を暗号化する。このように生成するのは事後、閲覧者側で非開示情報を解読した際、その内容の原本性を確認するためである。これらの暗号化処理が完了すると、部分暗号化済み発注書[Ｄ１−２]として一時保存する。この時、例えば発注書がＸＭＬデータ形式の場合は、ＸＭＬ部分暗号（XML Encryption）を用いるのが望ましい。
（１２）続けて、文書管理部３０はｐｉａｔ署名処理部４０内のｐｉａｔ署名生成部４１に対し、ｐｉａｔ署名情報[Ｈ１−２]の生成要求を発行する。この時、一時保存された部分暗号化済み発注書[Ｄ１−２]が渡される（ステップＳＴ−Ｃ１０）。
（１３）処理要求を受け取ったｐｉａｔ署名生成部４１は、部分暗号化済み発注書[Ｄ１−２]に対するｐｉａｔ署名情報[Ｈ１−２]を生成する（ステップＳＴ−Ｃ１１）。ここで、ｐｉａｔ署名情報の生成においては、前の状態[Ｄ１−１]から暗号化された"注文情報（品名）"、"決済情報（ＮＯ）"の乱数を別のものに変更した上で新たなｐｉａｔ署名情報[Ｈ１−２]を生成し、"名前"（本例では唯一、暗号化箇所以外で、且つ前回より変更が加えられていない箇所）に関しては前の状態[Ｄ１−１]と同一の乱数を用いて生成する。これにより、作成されたｐｉａｔ署名情報[Ｈ１−１]及び[Ｈ１−２]を比較することにより、"名前"に関しては、事後変更が加えられていないこと、申込者本人が記載したことを第三者に証明することが可能となる。
図３中のステップＳＴ−Ｃ１１−１はその様子を示している。"注文情報（品名）"の乱数が"４５６"から"９８７"へ、"決済情報（ＮＯ）"の乱数が"７８９"から"６５４"に変更され、暗号化済み情報（本例では、"注文情報（品名）"、 "決済情報（ＮＯ）"ともに暗号化処理結果が"*****"となると想定）と連結してハッシュ情報を生成し、それぞれ生成結果として"注文情報（品名）"が"ＯＰＱ"、"決済情報（ＮＯ）"が"ＲＳＴ"になっていることがわかる。
（１４）文書管理部３０は、ｐｉａｔ署名生成部４１からｐｉａｔ署名情報[Ｈ１−２]を取得する。ここで部分暗号化済み発注書[Ｄ１−２]とｐｉａｔ署名情報[Ｈ１−２]が揃うので、各情報に申込者（９０−Ａ）のＰＫＩ署名、ＴＳをそれぞれ付与し、これら２つの情報を一体化した状態でＤＢ３１に格納する（ステップＳＴ−Ｃ１２）。この時、先に格納された発注書[Ｄ１−１]、ｐｉａｔ署名情報[Ｈ１−１]とは別に管理され、自動的に版数管理がなされる。このような版数管理機能を有するＤＢ３１を用いれば、必要に応じて適切な版数の状態の証明を第三者に行うことが可能になる。
（１５）これまでの処理が正常に完了すると、文書管理部３０内の管理ＴＢ３２に発注書情報がエントリされる（ステップＳＴ−Ｃ１３）。管理ＴＢのエントリ構成としては、"文書名"、"文書ＩＤ"、"利用者ＮＯ"、"秘匿箇所"、"部分暗号情報"、"時限情報"が含まれる。図５はそのテーブルの構成を示している。申込者（鈴木花子さん）によって作成された発注書は、注文情報（品名）、決済情報（ＮＯ）共に、各エンティティ用の暗号化鍵を用いて時限付きで部分暗号化され、文書ＩＤ="Ａ００１"にて正常に登録されたことを示している。この管理ＴＢは登録の度に追記されていくものとする。また、本エントリ情報の原本性、信憑性を確保するため、本システムのＰＫＩ署名、ＴＳを付与しておくことが望ましい。
（１６）最後に、暗号化済み発注書[Ｄ１−２]を申込者（９０−Ａ）に返却し、作成処理を正常終了する。（ステップＳＴ−Ｃ１４）。ここで、異常が発生した場合は、その旨、申込者（９０−Ａ）にエラー通知し、異常終了する。本例では、ＤＢ３１に全て版数管理されて格納されることを想定し、暗号化済み発注書[Ｄ１−２]のみを申込者（９０−Ａ）に返却しているが、ｐｉａｔ署名情報[Ｈ１−１]とｐｉａｔ署名情報[Ｈ１−２]も同時に返却してもよい。この際、申込者（９０−Ａ）は、暗号化済み発注書[Ｄ１−２]とｐｉａｔ署名情報[Ｈ１−１]とｐｉａｔ署名情報[Ｈ１−２]の３つの情報（図３中の問屋参照情報群）をまとめて、電子メール等で直接問屋へ送信する場合もあり得る。
（発注書確認シーケンス（問屋側））
図６は発注書確認処理のフローチャート図である。
（１）問屋（９０−Ｂ）は申込者（９０−Ａ）からの発注依頼を何らかの方法で受信する。この時、発注依頼の取得手段として、問屋（９０−Ｂ）の担当者が定期的にポータルサイト提供部１００に電子通信路８０を通じて接続し、受注表（未処理リスト）を取得することが考えられる。また、別の手段として申込者（９０−Ａ）から電子メールにて直接受信する方法も考えられるが、本例では上述した受注表（未処理リスト）を取得し、発注書を確認するところから始まる。
（２）問屋（９０−Ｂ）は、ポータルサイト提供部１００に電子通信路（８０）を通じて接続し（ステップＳＴ−Ｖ１）、受注表（未処理リスト）を取得し表示させる（ステップＳＴ−Ｖ２）。図７はその表示結果例を示したものである。先に作成した申込者（（９０−Ａ）＝鈴木花子さん）（お客様コード"３３"）の発注書が未処理案件として表示されているのがわかる。
（３）問屋（９０−Ｂ）は、受注表中の申込者（（９０−Ａ）＝鈴木花子さん）を選択すると、ポータルサイト提供部１００は閲覧者制御機能付き部分完全性保証システム１０に対して確認処理要求を発行する（ステップＳＴ−Ｖ３）。
（４）受付処理部２０は、ポータルサイト提供部１００より確認処理要求を受信する。この時受け取る情報は、申込者（（９０−Ａ）＝鈴木花子さん）の発注書インデックスとなる。発注書インデックスとは、エントリ情報を検索するために必要な情報であり、文書ＩＤや利用者ＮＯ（お客様コード）、作成者（お客様名）等を含んでいる。
（５）受付処理部２０は受信後、文書管理部３０に対し、確認処理要求を発行する。
（６）確認処理要求を受信した文書管理部３０は、まず、発注書インデックスを基に管理ＴＢ３２から検索を行い、検索された場合、ＤＢ３１から該当する発注書を取得する（ステップＳＴ−Ｖ４）。この時、取得する情報は、暗号化済み発注書[Ｄ１−２]、ｐｉａｔ署名情報[Ｈ１−１]、ｐｉａｔ署名情報[Ｈ１−２]の３情報となる。つまりこれは、図３中の問屋参照情報群を示している。以降、これら３情報を"問屋参照情報群"と呼ぶ。
（７）取得処理が完了すると、文書管理部３０は、問屋参照情報群に付与されているＰＫＩ署名、ＴＳの有効性確認を行う（ステップＳＴ−Ｖ５）。この検証はＤＢ３１に格納されてから情報に改変がないことを確認するために行う。ＰＫＩ署名についてはＣＡ２００、ＴＳについてはＴＡ３００に対してそれぞれ電子通信路８０を通じて問合せを行い、検証結果を取得することになる。
（８）問屋参照情報群に付与されているＰＫＩ署名、ＴＳの有効性が確認できれば、文書管理部３０はｐｉａｔ署名処理部４０内のｐｉａｔ署名検証部４２に対し、問屋参照情報群の確認要求を発行する（ステップＳＴ−Ｖ６）。この時、問屋参照情報群が渡される。
（９）処理要求を受け取ったｐｉａｔ署名検証部４２は、問屋参照情報群を用いて確認処理を行う（ステップＳＴ−Ｖ７）。図８は確認処理時の問屋参照情報群の確認例を示した図である。暗号化済み発注書[Ｄ１−２]から乱数“１２３”と、“鈴木花子”という文字列を連結し、文字列“１２３鈴木花子”に対するハッシュ情報を生成する。生成結果として、“ＡＢＣ”というハッシュ情報が得られる。更に、ｐｉａｔ署名情報[Ｈ１−２]から名前部分のハッシュ情報を取り出し、比較・確認を行っている様子を示している（ステップＳＴ−Ｖ７−１）、以下、他項目についても同様の確認処理が行われる。
（１０）文書管理部３０は、ｐｉａｔ署名検証部４２から確認結果を取得する。次に暗号化済み発注書[Ｄ１−２]の復号フェーズに移る。発注書インデックスから管理ＴＢ３２中の"秘匿箇所"、"部分暗号情報"、"時限情報"を取得する（ステップＳＴ−Ｖ８）。この時、"秘匿箇所"、"部分暗号情報"から問屋（９０−Ｂ）の公開鍵で暗号化されていることを確認できるため、"注文情報（品名）"の復号のみ行えることが確認できる。また、"時限情報"はこの日時まで復号できることを示している。この時点で時限管理部６０に問合せを行う（ステップＳＴ−Ｖ９）。
この時、文書管理部３０からは"文書ＩＤ"と、"注文情報（品名）"を渡され、時限管理部６０では、時限管理部６０の管理ＴＢ６１内を検索し、時限情報を取得し、現在日時と比較する。もし、現日時を過ぎていなければ復号承諾を行い、現日時を過ぎていれば、復号拒否を文書管理部３０に返す（ステップＳＴ−Ｖ１０）。ここで時限管理部６０内には、正確な現在日時を有し、誤差がないことが前提であることは言うまでもない。図９は時限管理部６０の管理ＴＢ６１の様子を示している。文書ＩＤ="Ａ００１"の発注書は、注文情報（品名）、決済情報（ＮＯ）共に２００５年９月１日午前０時まで復号を承諾し、それ以降は復号を拒否することを示している。また、本エントリ情報の原本性、信憑性を確保するため、本システムのＰＫＩ署名、ＴＳを付与しておくことが望ましい。
（１１）復号承諾の結果を取得すれば、文書管理部３０は鍵生成・管理部５０に対し、暗号鍵の取得要求を発行する（ステップＳＴ−Ｖ１１）。この時、渡される情報は検索インデックスとなる。検索インデックスとは、文書ＩＤ及び作成者及び秘匿箇所（文書ＩＤ:作成者:秘匿箇所）のことであり、ここでは、"A00１:鈴木花子:注文情報（品名）"が検索インデックスとなる。
（１２）鍵生成・管理部５０は、検索インデックスから検索を行い、目的の鍵情報を取得する（ステップＳＴ−Ｖ１２）。
（１３）文書管理部３０は鍵生成・管理部５０から暗号鍵を受信し、問屋（９０−Ｂ）の秘密鍵で暗号化済み発注書[Ｄ１−２]中の"注文情報（品名）"に対する復号処理を行う（ステップＳＴ−Ｖ１３）。この時、問屋（９０−Ｂ）の秘密鍵を閲覧者制御機能付き部分完全性保証システム１０内に取り込む際は、セキュリティ上漏洩しないよう対策を行う必要がある。例えば、問屋（９０−Ｂ）の秘密鍵自身を閲覧者制御機能付き部分完全性保証システム１０の公開鍵で暗号化し、取り込む方法もあり得る。
（１４）続いて、復号処理後、解読情報の原本性を確認する（ステップＳＴ−Ｖ１４）。具体的には解読結果として、"４５６＋品物Ａ"が取得できるので、"４５６＋品物Ａ"の情報からハッシュ情報を生成し"ＤＥＦ"の結果を得る。ｐｉａｔ署名情報[Ｈ１−１]の"注文情報（品名）"から"ＤＥＦ"を取り出して比較することで、"注文情報（品名）"の原本性を確認することができる（図８中のステップＳＴ−Ｖ１４−１）。この検証により、申込者（９０−Ａ）が記載した発注書情報は作成時点から変更又は差し替えが行われていないこと、加えて、発注書に対して暗号化処理を加えられると同時に他の箇所も一緒に変更が加えられていないこと、また、解読内容の本人性、原本性の保証を第三者に証明することが可能となる。
（１５）最後に、検証結果を問屋（９０−Ｂ）に返却し、確認処理を正常終了する（ステップＳＴ−Ｖ１５）。ここで、異常が発生した場合は、その旨問屋（９０−Ｂ）にエラー通知し、異常終了する。
（発注書受付・承認シーケンス）
図１０は発注書受付・承認処理のフローチャート図である。
（１）前述した問屋（９０−Ｂ）における発注書確認シーケンスにて申込者（９０−Ａ）からの発注書情報の確認が完了すると、続けて、発注書情報の受付・承認処理を行う作業に移る。この受付・承認処理処理とは問屋（９０−Ｂ）が申込者（９０−Ａ）の発注書を受付処理し、承認した旨の追加を行う作業となる。
（２）先に記述した発注書確認シーケンスの最後で検証結果の通知を受けると、受付・承認処理を継続する旨の確認がなされる（ステップＳＴ−Ｕ１）。
（３）問屋（９０−Ｂ）が受付・承認の確定処理をすると、受付処理部２０は受付・承認処理要求を受信する。
（４）受付処理部２０は受信後、文書管理部３０に対し、受付・承認処理要求を発行する（ステップＳＴ−Ｕ２）。
（５）受付・承認処理要求を受信した文書管理部３０は、現在の最新版の発注書[Ｄ１−２]に対して、問屋（９０−Ｂ）承認済みを示す項目を追加し、新たな発注書[Ｄ２]を生成し、一時保存する（ステップＳＴ−Ｕ３）。
（６）ｐｉａｔ署名処理部４０内のｐｉａｔ署名生成部４１に対し、ｐｉａｔ署名情報[Ｈ２]の生成要求を発行する（ステップＳＴ−Ｕ４）。この時、一時保存された最新版の発注書[Ｄ２]が渡される。
（７）処理要求を受け取ったｐｉａｔ署名生成部４１は、最新版の発注書[Ｄ２]に対するｐｉａｔ署名情報[Ｈ２]を生成する（ステップＳＴ−Ｕ５）。図１１は受付・承認処理時のｐｉａｔ署名情報の生成例を示した図である。新規項目（"承認"）に乱数（"３２１"）を追加し、“承認済”という文字列を連結し、文字列“３２１承認済”に対するハッシュ情報を生成する。生成結果として、“ＵＶＷ”というハッシュ情報が出力されている様子を示している（図１１のステップＳＴ−Ｕ５−１）、以下、他項目については変更がないため、前版と同一の乱数を用いて同様の生成処理が行われる。
（８）文書管理部３０はｐｉａｔ署名生成部４１からｐｉａｔ署名情報[Ｈ２]を取得する。ここで最新版の発注書[Ｄ２]とｐｉａｔ署名情報[Ｈ２]が揃うので、各情報に問屋（９０−Ｂ）のＰＫＩ署名、ＴＳをそれぞれ付与し、これら２つの情報を一体化した状態でＤＢ３１に格納する（ステップＳＴ−Ｕ６）。この時、先に格納された[Ｄ１−１]及び[Ｈ１−２]と[Ｄ１−２]及び[Ｈ１−２]とは別に管理され、自動的に版数管理がなされる。
（９）最後に、最新版の発注書[Ｄ２]を問屋（９０−Ｂ）に返却し、受付・承認処理を正常終了する（ステップＳＴ−Ｕ７）。ここで、異常が発生した場合は、問屋（９０−Ｂ）にエラー通知し異常終了する。本例ではＤＢ３１に全て版数管理されて格納されることを想定し、最新版の発注書[Ｄ２]のみを問屋（９０−Ｂ）に返却しているが、ｐｉａｔ署名情報[Ｈ２]、ｐｉａｔ署名情報[Ｈ１−１]、ｐｉａｔ署名情報[Ｈ１−２]も同時に返却してもよい。この際、問屋（９０−Ｂ）は最新版の発注書[Ｄ２]とｐｉａｔ署名情報[Ｈ２]とｐｉａｔ署名情報[Ｈ１−１]とｐｉａｔ署名情報[Ｈ１−２]の４つの情報（図１１中のカード会社参照情報群）をまとめて、電子メール等で直接カード会社へ送信する場合もあり得る。
（発注書確認シーケンス（カード会社側））
発注書確認処理のフローチャート図は、問屋側で行った確認処理同様、図６の通りであるのでここでは割愛する。
（１）カード会社（９０−Ｃ）は、問屋（９０−Ｂ）からの決済依頼を何らかの方法で受信する。この時、決済依頼の取得手段して、カード会社（９０−Ｃ）の担当者が定期的にポータルサイト提供部１００に電子通信路８０を通じて接続し、決済依頼表（未処理リスト）を取得することが考えられる。また、別の手段として問屋（９０−Ｂ）から電子メールにて直接受信する方法も考えられるが、本例では前記で示した決済依頼表（未処理リスト）を取得し、発注書を確認するところから始まる。
（２）カード会社（９０−Ｃ）は、ポータルサイト提供部１００に電子通信路８０を通じて接続し（ステップＳＴ−Ｖ１）、決済依頼表（未処理リスト）を取得・表示させる（ステップＳＴ−Ｖ２）。
（３）カード会社（９０−Ｃ）は、決済依頼表中の申込者（（９０−Ａ）＝鈴木花子さん）を選択すると、ポータルサイト提供部１００は閲覧者制御機能付き部分完全性保証システム１０に対して確認処理要求を発行する（ステップＳＴ−Ｖ３）。
（４）受付処理部２０はポータルサイト提供部１００より確認処理要求を受信する。この時受け取る情報は、申込者（（９０−Ａ）＝鈴木花子さん）の発注書インデックスとなる。
（５）受付処理部２０は受信後、文書管理部３０に対し確認処理要求を発行する。
（６）確認処理要求を受信した文書管理部３０は、まず、発注書インデックスを基に管理ＴＢ３２から検索を行い、見つかった場合、ＤＢ３１から該当する発注書を取得する（ステップＳＴ−Ｖ４）。この時、取得する情報は、最新版の発注書[Ｄ２]、ｐｉａｔ署名情報[Ｈ２]、ｐｉａｔ署名情報[Ｈ１−１]、ｐｉａｔ署名情報[Ｈ１−２]の４つとなる。つまりこれは、図１１中のカード会社参照情報群を示している。以降、これら４情報を" カード会社参照情報群"と呼ぶ。
（７）取得処理が完了すると、文書管理部３０は、カード会社参照情報群に付与されているＰＫＩ署名、ＴＳの有効性確認を行う（ステップＳＴ−Ｖ５）。
（８）カード会社参照情報群に付与されているＰＫＩ署名、ＴＳの有効性が確認できれば、文書管理部３０はｐｉａｔ署名処理部４０内のｐｉａｔ署名検証部４２に対し、カード会社参照情報群の確認要求を発行する（ステップＳＴ−Ｖ６）。この時、カード会社参照情報群が渡される。
（９）処理要求を受け取ったｐｉａｔ署名検証部４２は、カード会社参照情報群を用いて確認処理を行う（ステップＳＴ−Ｖ７）。本確認処理では、２つの段階に分けて行われる。まず、第１段階では、最新版の発注書[Ｄ２]、ｐｉａｔ署名情報[Ｈ２]、ｐｉａｔ署名情報[Ｈ１−２]の３つの情報を用いて確認処理を行う。
図１２は確認処理時のカード会社参照情報群の確認例（第１段階）を示した図である。これによれば、最新版の発注書[Ｄ２]から乱数“１２３”と、“鈴木花子”という文字列を連結し、文字列“１２３鈴木花子”に対するハッシュ情報を生成する。生成結果として、“ＡＢＣ”というハッシュ情報が得られる。更に、ｐｉａｔ署名情報[Ｈ２]から名前部分のハッシュ情報を取り出し、比較・確認を行う（ステップＳＴ−Ｖ７−１：ｐｉａｔ検証−１）。以下、他項目についても同様の確認処理が行われる。
ｐｉａｔ検証−１で問題がないことが確認されると、続けて、ｐｉａｔ署名情報[Ｈ１−２]とｐｉａｔ署名情報[Ｈ２]をから項目毎のハッシュ情報を取り出して比較し、変更箇所の特定を行う（ステップＳＴ−Ｖ７−２：ｐｉａｔ検証−２）。本例のｐｉａｔ検証−２では、"名前"、"品名"、"ＮＯ"の項目は暗号化文書[Ｄ１−２]が作成されてから変更がないことを確認でき、"承認"項目については、暗号化文書[Ｄ１−２]から生成されたｐｉａｔ署名情報[Ｈ１−２]に"承認"項目のハッシュ情報が存在しないため、最新版の発注書[Ｄ２]の作成時点で"承認"項目が追加されたことがここで確認できる。また、各情報に付与されていたＰＫＩ署名、ＴＳからも以下の確認が行える。
"名前"、"品名"、"ＮＯ"の項目については、暗号化文書[Ｄ１−２]の状態から変更がないことを確認できたため、暗号化文書[Ｄ１−２]の作成者である申込者（９０−Ａ）が作成したことを確認でき、"承認"項目については問屋（９０−Ｂ）が追加したことを確認することができる。これらの確認は、カード会社参照情報群、カード会社参照情報群に付与されたＰＫＩ署名、ＴＳの情報を第三者に提示することで可能になる。
（１０）文書管理部３０は、ｐｉａｔ署名検証部４２から第１段階での確認結果を取得する。次に第２段階として、最新版の発注書[Ｄ２]、ｐｉａｔ署名情報[Ｈ１−１]の２つの情報を用いて確認処理を行う。図１３は確認処理時のカード会社参照情報群の確認例（第２段階）を示した図である。最初に行うことは、最新版の発注書[Ｄ２]の復号である。発注書インデックスから管理ＴＢ３２中の"秘匿箇所"、"部分暗号情報"、"時限情報"を取得する（ステップＳＴ−Ｖ８）。
この時、"秘匿箇所"、"部分暗号情報"からカード会社（９０−Ｃ）の公開鍵で暗号化されていることを確認できるため、"決済情報（ＮＯ）"の復号のみ行えることが確認できる。この時点で時限管理部６０に問合せを行う（ステップＳＴ−Ｖ９）。この時、文書管理部３０からは"文書ＩＤ"と、"決済情報（ＮＯ）"を渡され、時限管理部６０では、時限管理部６０の管理ＴＢ６１内（図９参照）を検索し、時限情報を取得、現在日時と比較する。もし、現日時を過ぎていなければ復号承諾を文書管理部３０に返し、現日時を過ぎていれば復号拒否を文書管理部３０に返す（ステップＳＴ−Ｖ１０）。
（１１）復号承諾の結果を取得すれば、文書管理部３０は、鍵生成・管理部５０に対し、暗号鍵の取得要求を発行する（ステップＳＴ−Ｖ１１）。この時、渡される情報は検索インデックスとなる。検索インデックスとは、文書ＩＤと作成者と秘匿箇所（文書ＩＤ:作成者:秘匿箇所）のことであり、ここでは、"Ａ００１:鈴木花子:決済情報（ＮＯ）"が検索インデックスとなる。
（１２）鍵生成・管理部５０は、検索インデックスから検索を行い、目的の鍵情報を取得する（ステップＳＴ−Ｖ１２）。
（１３）文書管理部３０は、鍵生成・管理部５０から暗号鍵を受信し、カード会社（９０−Ｃ）の秘密鍵で最新版の発注書[Ｄ２]中の"決済情報（ＮＯ）"に対する復号処理を行う（ステップＳＴ−Ｖ１３）。
（１４）続いて、復号処理後、解読情報の原本性を確認する（ステップＳＴ−Ｖ１４）。具体的には解読結果として、"７８９+１２３４"が取得できるので、"７８９+１２３４"の情報からハッシュ情報を生成し、"ＧＨＩ"の結果を得る。ｐｉａｔ署名情報[Ｈ１−１]の"決済情報（ＮＯ）"から"ＧＨＩ"を取り出して比較することで、"決済情報（ＮＯ）"の原本性を確認することができる（図１３中のステップＳＴ−Ｖ１４−１）。このように第１段階、第２段階のフェーズを踏んで検証を行うことにより、申込者（９０−Ａ）が記載した発注書情報は問屋（９０−Ｂ）が追加処理を行っても作成時点から変更、差し替えが行われていないこと、加えて、発注書に対して暗号化処理を加えられると同時に他の箇所も一緒に変更が加えられていないこと、また、解読内容の本人性、原本性の保証を第三者に証明することが可能となる。
（１５）最後に、検証結果をカード会社（９０−Ｃ）に返却し、確認処理を正常終了する（ステップＳＴ−Ｖ１５）。ここで、異常が発生した場合は、その旨、カード会社（９０−Ｃ）にエラー通知し、異常終了する。
（発注書取得シーケンス）
申込者（９０−Ａ）、問屋（９０−Ｂ）、カード会社（９０−Ｃ）の各利用者は、情報公開部７０内の情報公開ＤＢ７１に蓄積されている発注書情報の取得することが可能である。これは、既に受け付けされ、もしくは、既に処理されている発注書の内容を確認したり、検証したり、当事象における裁判等の紛争が発生した場合に、第三者へ提出する際に利用される。本取得シーケンスにおいては、先に説明した発注書確認シーケンスにおける取得処理、ならびに、取得した発注書情報の確認、検証処理と同一のため、説明は割愛する。
続けて、本システムを利用した場合の自治体文書管理における情報公開スキームについて説明する。
利用者が本システムを利用する場面として、電子的に作成した自治体公文書を署名付きで記録・保存する場面が考えられる。また、記録・保存された署名付き公文書は、開示請求者へ流通され、事後、必要に応じて開示された公文書の正当性確認を行うため、第三者に提示する場面が考えられる。また、開示請求者への流通がなされる際、必要に応じて部分開示・非開示を行うことが求められる。
例えば、開示請求者へ到達するまでの過程で第三者が閲覧できないように、言い換えれば、ある箇所に対しては開示請求者のみ閲覧できるように秘匿する場面や、そもそも第三者は閲覧できないようにするのはもちろんのこと、ある箇所に対しては開示請求者をも閲覧を許さない、いわゆる、完全な墨塗りを行う場面が考えられる。
特に前者の場合は、部分開示・非開示制御が可能で、閲覧可能者以外は非開示情報が漏洩しないことの証明、非開示情報以外が改変されていない（原本性、完全性）ことの証明、非開示情報の内容が本人作成のものであり、改変がないことの証明等、これら開示・非開示操作に対する証拠性、証明性の確保が求められる。
よって、利用者は事後、裁判沙汰等になった場合に証拠として提出できるよう記録を残す手段として、また、第三者に対して公文書に対する証明を行う際に本システムを利用する。本利用シーンでは、公共施設利用申請を例に説明する。
本利用シーンの登場人物として、公共施設利用申請を行う「申請者」と、申請者の依頼により申請書情報を受信し、公文書として本システムに登録を行う「区職員」と、公文書群の開示請求要求を行う「閲覧者」の３者が登場する。
図１４は公共施設利用申請における一実施例を示している。図１４中の自治体文書管理システムは、本発明のシステムである閲覧者制御機能付き部分完全性保証システム１０に対応する。また、電子申請受付サーバは図１中の受付処理部２０及びポータルサイト提供部１００に対応し、文書管理サーバは文書管理部３０に対応し、ｐｉａｔ処理サーバはｐｉａｔ署名処理部４０に対応し、鍵管理サーバは鍵生成・管理部５０に対応し、時限管理サーバは時限管理部６０に対応し、情報公開サーバは情報公開部７０に対応し、申請者・閲覧者は利用者９０に対応し、ＣＡ、ＴＡ（認証局）はＣＡ２００、ＴＡ３００にそれぞれ対応している。
本実施の形態における各登場者と動作について説明する。
（区民（申請者・利用者））
公共施設を利用するため電子申請を行う。この時、申請環境はパソコン、携帯電話、ＰＤＡ（Personal Digital Assistance：携帯情報端末）等が考えられる。
（自治体文書管理システム、区職員）
区民（申請者・利用者）からの電子申請書を収受し、起案、決裁、認可証発送、保存、検索、公開を行う。更に自治体文書管理システムには、電子申請受付サーバ、文書管理サーバ、情報公開サーバ、時限管理サーバ、ｐｉａｔ処理サーバ、鍵管理サーバの６つのモジュールが存在する。各モジュールの動作について説明する。
（電子申請受付サーバ）
区民（申請者・利用者）からの電子申請を収受する。本サーバはポータルサイトの役割も果たしている。
（文書管理サーバ）
区民（申請者・利用者）からの決裁済み公文書を管理、保存する。
（情報公開サーバ）
決裁済み文書中の秘匿箇所（個人情報等）を墨塗り、保存し、区民（閲覧者）向けに公開する。
（時限管理サーバ）
区役所から情報公開されている決裁済み公文書中の秘匿箇所に対し時限による開示・非開示制御を行う。
（ｐｉａｔ処理サーバ）
文書管理サーバに保存されている決裁済み文書の部分署名生成、ならびに部分署名検証を行う。
（鍵管理サーバ）
文書管理サーバに保存されている決裁済み文書の閲覧者制御を行うための暗号鍵の生成と管理を行う。
（区民（閲覧者））、（監査人、警察、区民等）
区から情報公開されている決裁済み公文書を検索し、閲覧を行う。また必要に応じて第三者証明を依頼し、公開文書の検証を行う。 以降、これら登場人物を総括して「閲覧者」と示す。
（ＣＡ，ＴＡ（認証局））
電子署名、タイムスタンプ等の第三者証明情報の付与、ならびに正当性確認を行う。
（公共施設（体育館、プール等）受付）
利用者から認可証を受け取り正当性確認を行う。
上記利用シーンにおいて、本システムでは申請者、区職員、閲覧者に対して以下の３機能を提供する。
（Ａ）受付機能（申請時に申請者が利用）
（Ｂ）登録機能（公文書の登録時に区職員が利用）
（Ｃ）取得機能（公文書の取得時に申請者、閲覧者が利用）
以下より、上記（Ａ）〜（Ｃ）の各事象における作用について説明する。
本利用シーンの事前条件として、申請者、区職員、閲覧者は本システムを利用できるよう利用者認証情報が事前登録されており、厳密なアクセス制御がなされていることを前提とする。
（申請書受付・登録シーケンス）
図１５は公共施設利用申請における受付・登録処理フローを示している。
（１）申請者は、電子申請受付サーバに対してインターネットを通じて接続し、アクセスする。この時、電子申請受付サーバには申請者の利用者登録がなされていることが前提となる。申請者は、例えばＩＤ、パスワードでログインし、申請書入力フォーム内に必要情報を入力する。この時入力する情報として氏名、住所、電話番号、利用場所、利用月日、利用時間等があるとする。これら情報の入力後、確定処理を行うと、電子申請受付サーバ内に一時保存される。
（２）電子申請受付サーバに蓄積された申請書は、即日、区職員によって受付・確認処理され、収受、起案、決済の順で手続きが行われる。この時、各申請書にはセキュリティポリシがリンクされており、起案時に秘匿箇所が設定される。
（３）上記受付・確認処理が完了すると保存フェーズに移る。区職員は文書管理サーバに対して、保存処理要求を発行する。
（４）保存処理要求を受信した文書管理サーバは、ｐｉａｔ処理サーバに対し、ｐｉａｔ署名情報[Ｈ１−１]の生成依頼を発行する。この時、申請書[Ｄ１−１]が渡される。
（５）生成依頼を受け取ったｐｉａｔ処理サーバは、申請書[Ｄ１−１]に対するｐｉａｔ署名情報[Ｈ１−１]を生成する。本生成処理時のｐｉａｔ署名情報の生成例を示した図は、図３で説明したとおりである。ｐｉａｔ署名情報の生成方法についての基本原理は同一であるため本例では説明を割愛する。文書管理サーバは、ｐｉａｔ処理サーバからｐｉａｔ署名情報[Ｈ１−１]を取得する。
（６）ｐｉａｔ処理サーバからｐｉａｔ署名情報[Ｈ１−１]を受信した文書管理サーバは、ＰＫＩ署名とＴＳの付与フェーズに移る。ここで申請書[Ｄ１−１]とｐｉａｔ署名情報[Ｈ１−１]が揃うので、各情報に申請者のＰＫＩ署名、ＴＳをそれぞれ付与する。ＰＫＩ署名については、ＣＡ、タイムスタンプについては、ＴＡによりそれぞれ公的機関が発行したものを採用することで、当情報の信憑性、真実性を強化、厳密な第三者証明を行うことを可能とする。
（７）ＰＫＩ署名とＴＳが付与された申請書[Ｄ１−１]とｐｉａｔ署名情報[Ｈ１−１]の２つの情報を一体化した状態で文書管理サーバ内の目録ＤＢに原本保存する。
（８）次に部分暗号のフェーズに移る。暗号化のための鍵を生成するため、鍵管理部サーバに対し、暗号鍵の生成要求を発行する。この時、起案時に設定された秘匿箇所に対して処理を行う。本例では、"氏名"、"住所"、"電話番号"の３つの情報を暗号化することとし、開示請求時に申請者本人のみが閲覧できるよう、３つの情報に対して秘匿制御を行うものとする。つまり、申請者本人以外の者に対して、情報公開法に基づき本申請書の閲覧は可能になるが、個人情報保護法の観点から上記３つの情報は秘匿されるものとする。
（９）鍵管理サーバは、"氏名"用と、"住所"用と、"電話番号"用の暗号鍵（共通鍵）を生成し、鍵管理サーバ内に格納する。具体的には以下の方法で格納される。本例では、"氏名"用と、"住所"用と、"電話番号"用の暗号鍵（共通鍵）を申請者の公開鍵情報で暗号化を行う。本例では、１箇所に対して複数人の閲覧者が存在せず、３情報に対して１人の閲覧者制御ができればよいので、同一の鍵情報を用いて制御・管理することで問題ない。また、この暗号鍵（共通鍵）を時限管理サーバで制御・管理することで、復号後の鍵漏洩を防止できる。言い換えれば、当暗号鍵で暗号化された申請書に含まれた上記３情報の漏洩を防止することができる。例えば、新規に申請書が生成されてから２年間は復号できる状態（閲覧できる状態）にして、それ以降は復号できないよう制御することで安全性を確保するのに使える。
（１０）文書管理サーバは、鍵管理サーバから暗号鍵を受信し、申請書[Ｄ１−１]内の各秘匿箇所に対し、暗号化処理を行う。本暗号処理時のｐｉａｔ署名情報の生成例を示した図は、図３中のステップＳＴ−Ｃ９−１で説明したとおりである。暗号処理時におけるｐｉａｔ署名情報の生成方法についての基本原理は同一であるため本例では説明を割愛する。
（１１）続けて、文書管理サーバは、ｐｉａｔ処理サーバに対し、ｐｉａｔ署名情報[Ｈ１−２]の生成依頼を発行する。この時、一時保存された部分暗号化済み申請書[Ｄ１−２]が渡される。
（１２）生成依頼を受け取ったｐｉａｔ処理サーバは、部分暗号化済み申請書[Ｄ１−２]に対するｐｉａｔ署名情報[Ｈ１−２]を生成する。ここで、ｐｉａｔ署名情報の生成においては、前の状態[Ｄ１−１]から暗号化された"氏名"、"住所"、"電話番号"の乱数を別のものに変更した上で新たなｐｉａｔ署名情報[Ｈ１−２]を生成し、"利用場所"、"利用月日"、"利用時間"（暗号化箇所以外で、且つ前回より変更が加えられていない箇所）に関しては前の状態[Ｄ１−１]と同一の乱数を用いて生成する。これにより、作成された[Ｈ１−１]と[Ｈ１−２]を比較することにより、暗号化箇所以外に関しては、事後変更が加えられていないことを第三者に証明することが可能となる。その様子は、図３中のステップＳＴ−Ｃ１１−１で表現しており、基本原理は同一である。文書管理サーバは、ｐｉａｔ処理サーバからｐｉａｔ署名情報[Ｈ１−２]を取得する。
（１３）ｐｉａｔ処理サーバからｐｉａｔ署名情報[Ｈ１−２]を受信した文書管理サーバは、ＰＫＩ署名とＴＳの付与フェーズに移る。ここで申請書[Ｄ１−２]とｐｉａｔ署名情報[Ｈ１−２]が揃うので、各情報に申請者のＰＫＩ署名、ＴＳをそれぞれ付与する。ＰＫＩ署名については、ＣＡ２００、タイムスタンプについては、ＴＡ３００によりそれぞれ公的機関が発行したものを採用することで、当情報の信憑性、真実性を強化、厳密な第三者証明を行うことを可能とする。
（１４）ＰＫＩ署名とＴＳが付与された申請書[Ｄ１−２]とｐｉａｔ署名情報[Ｈ１−２]の２つの情報を一体化した状態で文書管理サーバ内の目録ＤＢに原本保存する。この時、先に格納された[Ｄ１−１]−[Ｈ１−１]とは別に管理され、自動的に版数管理がなされる。このような版数管理機能を有する目録ＤＢを用いれば、必要に応じて適切な版数の状態の証明を第三者に行うことが可能になる。これまでの処理が正常に完了すると、文書管理サーバ内の管理ＴＢに申請書情報がエントリされる。文書管理サーバ内の管理ＴＢのエントリ構成例については、図５で示しており、その基本情報、ならびに、構成については同一であるため本例では説明を割愛する。
（１５）最後に、現時点で最終版となる申請書[Ｄ１−２]は、情報公開サーバにアップロードされ、公開用インデックスとして登録される。
（１６）以上で公共施設利用申請における受付・登録処理が正常終了し、申請者に対して利用許可証を送付する。ここで、異常が発生した場合は、その旨エラー通知し、異常終了する。
（１７）上記処理が完了し、利用許可証を受け取った申請者は、公共施設の利用が可能になる。また、公共施設側の受付端末には例えばバーコードリーダーが装備されており、利用許可証に印刷されたバーコードを読み取ることによりリアルタイムに区役所側の文書管理サーバと通信を行い、利用許可証の正当性確認を行うことが可能となる。以上が申請書の受付・登録シーケンスである。
次に公文書の取得・閲覧シーケンスに移る。次に説明する公文書の取得・閲覧シーケンスでは、区役所にて受付・承認、保管、公開されている申請者本人申請済みの公共施設利用申請書を公文書として情報公開サーバから取得・閲覧する場面と、申請者ではない第三者の区民や監査人、警察等の人間が当申請書を取得・閲覧する場面の２つの利用シーンを想定し、説明を行う。
まず、初めに申請者本人による公文書取得・閲覧シーケンスについて説明する。
（公文書取得・閲覧シーケンス（申請者））
図１６は、公文書の取得・閲覧処理フローを示している。
（１）申請者は、情報公開サーバに対してインターネットを通じて接続し、アクセスする。この時、情報公開サーバには申請者の利用者登録がなされていることが前提となる。申請者は、例えばＩＤ、パスワードでログインする。情報公開サーバには公開済みとなっている公文書のインデックスが用意されており、申請者は本インデックスのリストから取得・閲覧したい公文書を選択することになる。この時、選択する公文書は、先に説明した申請者自身の公共施設利用申請書を取得・閲覧するものと想定する。
（２）申請者からの取得・閲覧依頼を受信すると、情報公開サーバは指定されたインデックスを基にデータベースより検索をかけ、見つかった場合、データベースから該当する公文書の原本を取得する。この時、取得する情報は、暗号化済み公文書[Ｄ１−２]、ｐｉａｔ署名情報[Ｈ１−１]、ｐｉａｔ署名情報[Ｈ１−２]の３つの情報となる。以降、これら３情報を" ｐｉａｔ検証情報群"と呼ぶ。
（３）取得処理が完了すると、情報公開サーバは、ｐｉａｔ検証情報群に付与されているＰＫＩ署名、ＴＳの有効性確認を行う。この検証は、情報公開サーバにアップロードされてから行われるもので、情報に改変がないことを確認するために行われる。ＰＫＩ署名についてはＣＡ、ＴＳについてはＴＡに対してそれぞれ問合せを行い、検証結果を取得することになる。
（４）ｐｉａｔ検証情報群に付与されているＰＫＩ署名、ＴＳの有効性が確認できれば、情報公開サーバは、ｐｉａｔ処理サーバに対し、ｐｉａｔ検証情報群の検証依頼を発行する。この時、ｐｉａｔ検証情報群が渡される。
（５）検証依頼を受け取ったｐｉａｔ処理サーバは、ｐｉａｔ検証情報群を用いて検証処理を行う。本検証処理時のｐｉａｔ署名情報の確認例を示した図は、図８で説明したとおりである。ｐｉａｔ署名情報の確認方法についての基本原理は同一であるため本例では説明を割愛する。
（６）情報公開サーバは、ｐｉａｔ処理サーバから確認結果を取得する。次に暗号化済み公文書[Ｄ１−２]の復号フェーズに移る。情報公開サーバは、時限管理サーバに対して時限確認依頼を発行する。時限管理サーバでは時限管理サーバ内に保持されている管理ＴＢを検索し、時限情報を取得、現在日時と比較。もし現日時を過ぎていなければ復号承諾を、現日時を過ぎていれば復号拒否を情報公開サーバに結果を返す。ただし、時限管理サーバ内には、正確な現在日時を有し、誤差がないことが必須要件であることは言うまでもない。時限管理部内の管理ＴＢのエントリ構成例については、図９で示しており、その基本情報、ならびに、構成については同一であるため本例では説明を割愛する。
（７）復号承諾の結果を取得すれば、情報公開サーバは、鍵管理サーバに対し、暗号鍵の取得依頼を発行する。 この時、渡される情報は、検索インデックスとなる。検索インデックスとは、"文書ＩＤ:作成者:秘匿箇所"のことである。鍵管理サーバは、検索インデックスから、検索をかけ目的の鍵情報を取得する。
（８）情報公開サーバは、鍵管理サーバから暗号鍵を受信し、申請者の秘密鍵で暗号化済み公文書[Ｄ１−２]中の"名前"、"住所"、"電話番号"に対する復号処理を行う。
（９）続けて、復号処理後、解読情報の原本性を確認する。その様子は、図８中のステップＳＴ−Ｖ１４−１で表現しており、基本原理は同一である。この検証により、申請者が記載した公文書は作成時点から変更、差し替えが行われていないこと、加えて、公文書に対して暗号化処理を加えられると同時に他の箇所も一緒に変更が加えられていないこと、また、解読内容の本人性、原本性の保証を第三者に証明することが可能となる。なお、この例では、申請者自身による暗号化箇所の復号処理であり、本解読情報の原本性確認は行わなくてもよい。
（１０）最後に、検証結果付き公文書を申請者に返却し、申請者は内容を確認する。これで取得・閲覧処理を正常終了する。ここで、異常が発生した場合は、その旨、申請者にエラー通知し、異常終了する。
次に申請者本人以外の閲覧者による公文書取得・閲覧シーケンスについて説明する。
（公文書取得・閲覧シーケンス（閲覧者））
図１７は、公文書の取得・閲覧処理フローを示している。
（１）閲覧者は、情報公開サーバに対してインターネットを通じて接続し、アクセスする。この時、情報公開サーバには閲覧者の利用者登録がなされていることが前提となる。閲覧者は、例えばＩＤ、パスワードでログインする。情報公開サーバには公開済みとなっている公文書のインデックスが用意されており、閲覧者は本インデックスのリストから取得・閲覧したい公文書を選択することになる。
（２）閲覧者からの取得・閲覧依頼を受信すると、情報公開サーバは指定されたインデックスを基にデータベースより検索をかけ、見つかった場合データベースから該当する公文書の原本を取得する。この時、取得する情報は、暗号化済み公文書[Ｄ１−２]、ｐｉａｔ署名情報[Ｈ１−１]、ｐｉａｔ署名情報[Ｈ１−２]の３情報となる。以降、これら３情報を" ｐｉａｔ検証情報群"と呼ぶ。
（３）取得処理が完了すると、情報公開サーバは、ｐｉａｔ検証情報群に付与されているＰＫＩ署名、ＴＳの有効性確認を行う。この検証は情報公開サーバにアップロードされてから情報に改変がないことを確認するために行う。ＰＫＩ署名についてはＣＡ、ＴＳについてはＴＡに対してそれぞれ問合せを行い、検証結果を取得することになる。
（４）ｐｉａｔ検証情報群に付与されているＰＫＩ署名、ＴＳの有効性が確認できれば、情報公開サーバは、ｐｉａｔ処理サーバに対し、ｐｉａｔ検証情報群の検証依頼を発行する。この時、ｐｉａｔ検証情報群が渡される。
（５）検証依頼を受け取ったｐｉａｔ処理サーバは、ｐｉａｔ検証情報群を用いて検証処理を行う。本検証処理時のｐｉａｔ署名情報の確認例を示した図は、図８で説明したとおりである。ｐｉａｔ署名情報の確認方法についての基本原理は同一であるため本例では説明を割愛する。
（６）最後に、検証結果付き公文書を閲覧者に返却し、閲覧者は内容を確認する。ここで閲覧者は検証結果として以下の情報を取得することになる。まず始めに"氏名"、"住所"、"電話番号"の各箇所については区職員によって墨塗りが行われていること、上記秘匿箇所以外（"利用場所"、"利用月日"、"利用時間"）については申請時点から改変がないことを確認することができる。この時、秘匿箇所以外は誰が記載したかについても確認できるが、本情報は個人情報保護の観点から開示されない。これで取得・閲覧処理を正常終了する。ここで、異常が発生した場合は、その旨、申請者にエラー通知し、異常終了する。
また本利用シーンでは、警察等による事情調査により、本公文書が申請者本人のアリバイとして利用されることや、何らかの事件性があり、本例で登場の区立体育館がその日時に使われていたことを確認するために利用する等の場面が想定できる。例えば、このような特殊事情の場合、警察自身が閲覧者として公文書を閲覧する場合や、申請者本人が閲覧するのと同様、墨塗り箇所を解読し、全情報を閲覧する場合が考えられるが、両利用シーンにおいても、先に説明した検証結果を得ることが可能となる。
本発明の実施の形態によれば、従来技術、および、その単純な組み合わせでは不可能であった下記の要件を満足することが可能となる。更に、最も類似する従来技術と比べて、墨塗り（変更）文書の完全性、原本性を容易に実現することが可能となる。
上述した本発明の実施の形態において、本発明に対応する所定のステップを電子文書管理プログラムとして、コンピュータにより読取り可能な記録媒体に記憶させることによって、当該電子文書管理をコンピュータに実行させることが可能となる。なお、本発明において、上記コンピュータにより読取り可能な記録媒体は、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
（付記１） 電子情報で作成される文書情報を原本情報として管理することをコンピュータに実行させる電子文書管理プログラムであって、
前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理ステップと、
前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理ステップと、
前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理ステップと
をコンピュータに実行させる電子文書管理プログラム。
（付記２） 付記１に記載の電子文書管理プログラムにおいて、
鍵生成・管理ステップにおける、条件は、閲覧者である事を特徴とする電子文書管理プログラム。
（付記３） 付記１に記載の電子文書管理プログラムにおいて、
文書情報の管理を受け付ける受付処理ステップと、
前記鍵生成・管理ステップにおいて管理されている暗号化鍵の時限情報を管理するための時限管理ステップと、
前記文書管理ステップにおいて管理されている前記一体化原本情報から公開に用いられる原本情報を公開する情報公開ステップと
をコンピュータに実行させることを特徴とする電子文書管理プログラム。
（付記４） 付記１に記載の電子文書管理プログラムにおいて、
前記部分署名処理ステップは、前記部分署名情報を生成処理するための部分署名生成ステップと、前記部分署名情報を用いて検証処理を行うための部分署名検証ステップを備えることを特徴とする電子文書管理プログラム。
（付記５） 付記４に記載の電子文書管理プログラムにおいて、
前記部分署名生成ステップは、原本情報を複数の部分に区切り、各部分の情報に基づいて前記部分署名情報を生成することを特徴とする電子文書管理プログラム。
（付記６） 付記１に記載の電子文書管理プログラムにおいて、
前記鍵生成・管理ステップは、生成した前記暗号化鍵を閲覧が許可されたエンティティ（人やシステムを指す）の公開鍵で更に暗号化して管理することを特徴とする電子文書管理プログラム。
（付記７） 付記３に記載の電子文書管理プログラムにおいて、
前記時限管理ステップは、前記鍵生成・管理部において管理されている暗号化鍵の時限情報を保持し、該時限情報を用いてアクセス制御を行うことを特徴とする電子文書管理プログラム。
（付記８） 付記３に記載の電子文書管理プログラムにおいて、
前記時限管理ステップで管理されている暗号化鍵の時限情報を用いて、有効期限が切れている場合は、該暗号鍵、ならびに該原本情報へのアクセスを無効にすること特徴とする電子文書管理プログラム。
（付記９） 付記３に記載の電子文書管理プログラムにおいて、
前記情報公開ステップは、前記文書管理ステップと連携して公開情報のみを取得して蓄積し、公開を行うことを特徴とする電子文書管理プログラム。
（付記１０） 付記１に記載の電子文書管理プログラムにおいて、
前記部分署名処理ステップは、前記部分署名情報を生成処理するための部分署名生成ステップと、前記部分署名情報を用いて検証処理を行うための部分署名検証ステップを備えることを特徴とする電子文書管理プログラム。
（付記１１） 付記１に記載の電子文書管理プログラムにおいて、
原本情報と部分署名情報のそれぞれに電子署名が付与されていることを特徴とする電子文書管理プログラム。
（付記１２） 付記１に記載の電子文書管理プログラムにおいて、
原本情報と部分署名情報のそれぞれにタイムスタンプが付与されていることを特徴とする電子文書管理プログラム。
（付記１３） 付記１に記載の電子文書管理プログラムにおいて、
前記文書管理ステップは、登録される電子情報をすべて原本情報として扱い、変更の際には旧版を残して更新文書として新たな登録文書として保管し、版数管理を自動的に行うことを特徴とする電子文書管理プログラム。
（付記１４） 電子情報で作成される文書情報を原本情報として管理する電子文書管理システムであって、
前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理部と、
前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理部と、
前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理部と
を備えてなる電子文書管理システム。
（付記１５） 付記１に記載の電子文書管理システムにおいて、
鍵生成・管理部における、条件は、閲覧者である事を特徴とする電子文書管理システム。
（付記１６） 付記１４に記載の電子文書管理システムにおいて、
文書情報の管理を受け付ける受付処理部と、
前記鍵生成・管理ステップにおいて管理されている暗号化鍵の時限情報を管理するための時限管理部と、
前記文書管理部において管理されている前記一体化原本情報から公開に用いられる原本情報を公開する情報公開部と
を備えることを特徴とする電子文書管理システム。
（付記１７） 付記１４に記載の電子文書管理システムにおいて、
前記部分署名処理部は、前記部分署名情報を生成処理するための部分署名生成部と、前記部分署名情報を用いて検証処理を行うための部分署名検証部を備えることを特徴とする電子文書管理システム。
（付記１８） 付記１４に記載の電子文書管理システムにおいて、
前記鍵生成・管理部は、生成した前記暗号化鍵を閲覧が許可されたエンティティ（人やシステム等を指す）の公開鍵で更に暗号化して管理することを特徴とする電子文書管理システム。
（付記１９） 電子情報で作成される文書情報を原本情報として管理することをコンピュータにより行う電子文書管理方法であって、
前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理ステップと、
前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理ステップと、
前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理ステップと
を備える電子文書管理方法。
（付記２０） 付記１９に記載の電子文書管理方法において、
鍵生成・管理ステップにおける、条件は、閲覧者である事を特徴とする電子文書管理プログラム。
本発明の原理図及びシステム構成例を示す図である。 発注書生成処理のフローチャートである。 生成処理時のｐｉａｔ署名情報の生成例を示す図である。 鍵管理の概要を示す図である。 文書管理部内の管理ＴＢのエントリ構成例を示す図である。 発注書確認処理のフローチャートである。 受注表の表示結果例を示す図である。 確認処理時の問屋参照情報群の確認例を示す図である。 時限管理部内の管理ＴＢのエントリ構成例を示す図である。 発注書受付・承認処理のフローチャートである。 受付・承認処理時のｐｉａｔ署名情報の生成例を示す図である。 確認処理時のカード会社参照情報群の確認例（第１段階）を示す図である。 確認処理時のカード会社参照情報群の確認例（第２段階）を示す図である。 公共施設利用申請における一実施例を示す図である。 公共施設利用申請における受付・登録処理フローを示す図である。 申請者による公文書の取得・閲覧処理フローを示す図である。 閲覧者による公文書の取得・閲覧処理フローを示す図である。
符号の説明
１０ 閲覧者制御機能付き部分完全性保証システム、２０ 受付処理部、３０ 文書管理部、３１ 文書管理用ＤＢ、３２ 文書管理ＴＢ、４０ ｐｉａｔ署名処理部、４１ ｐｉａｔ署名生成部、４２ ｐｉａｔ署名検証部、５０ 鍵生成・管理部、５１ 鍵ＤＢ、６０ 時限管理部、６１ 時限管理ＴＢ、７０ 情報公開部、７１ 情報公開用ＤＢ、８０ 電子通信路、９０−Ａ 利用者Ａ、９０−Ｂ 利用者Ｂ、９０−Ｃ 利用者Ｃ、１００ ポータルサイト提供部、２００ ＣＡ、３００ ＴＡ。

Claims (10)

  1. 電子情報で作成される文書情報を原本情報として管理することをコンピュータに実行させる電子文書管理プログラムであって、
    前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理ステップと、
    前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理ステップと、
    前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理ステップと
    をコンピュータに実行させる電子文書管理プログラム。
  2. 請求項１に記載の電子文書管理プログラムにおいて、
    文書情報の管理を受け付ける受付処理ステップと、
    前記鍵生成・管理ステップにおいて管理されている暗号化鍵の時限情報を管理するための時限管理ステップと、
    前記文書管理ステップにおいて管理されている前記一体化原本情報から公開に用いられる原本情報を公開する情報公開ステップと
    をコンピュータに実行させることを特徴とする電子文書管理プログラム。
  3. 請求項１に記載の電子文書管理プログラムにおいて、
    前記部分署名処理ステップは、前記部分署名情報を生成処理するための部分署名生成ステップと、前記部分署名情報を用いて検証処理を行うための部分署名検証ステップを備えることを特徴とする電子文書管理プログラム。
  4. 請求項３に記載の電子文書管理プログラムにおいて、
    前記部分署名生成ステップは、原本情報を複数の部分に区切り、各部分の情報に基づいて前記部分署名情報を生成することを特徴とする電子文書管理プログラム。
  5. 請求項１に記載の電子文書管理プログラムにおいて、
    前記鍵生成・管理ステップは、生成した前記暗号化鍵を閲覧が許可されたエンティティ（人やシステム等を指す）の公開鍵で更に暗号化して管理することを特徴とする電子文書管理プログラム。
  6. 電子情報で作成される文書情報を原本情報として管理する電子文書管理システムであって、
    前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理部と、
    前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理部と、
    前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理部と
    を備えてなる電子文書管理システム。
  7. 請求項６に記載の電子文書管理システムにおいて、
    文書情報の管理を受け付ける受付処理部と、
    前記鍵生成・管理ステップにおいて管理されている暗号化鍵の時限情報を管理するための時限管理部と、
    前記文書管理部において管理されている前記一体化原本情報から公開に用いられる原本情報を公開する情報公開部と
    を備えることを特徴とする電子文書管理システム。
  8. 請求項６に記載の電子文書管理システムにおいて、
    前記部分署名処理部は、前記部分署名情報を生成処理するための部分署名生成部と、前記部分署名情報を用いて検証処理を行うための部分署名検証部を備えることを特徴とする電子文書管理システム。
  9. 請求項６に記載の電子文書管理システムにおいて、
    前記鍵生成・管理部は、生成した前記暗号化鍵を閲覧が許可されたエンティティ（人やシステム等を指す）の公開鍵で更に暗号化して管理することを特徴とする電子文書管理システム。
  10. 電子情報で作成される文書情報を原本情報として管理することをコンピュータにより行う電子文書管理方法であって、
    前記原本情報に対して、原本情報の変更有無を検出するとともに、変更箇所を特定し、さらに変更箇所以外の箇所の不変を第三者に証明可能とするための部分署名情報の処理を行うための部分署名処理ステップと、
    前記原本情報の任意部分に対する条件や状況等に応じたアクセス制御を行うための暗号化鍵を生成し、管理を行う鍵生成・管理ステップと、
    前記原本情報の任意部分のアクセス制御を行いつつ、前記原本情報と前記部分署名情報を一体化原本情報として、登録・管理する文書管理ステップと
    を備える電子文書管理方法。
JP2005353525A 2005-12-07 2005-12-07 電子文書管理プログラム、電子文書管理システム及び電子文書管理方法 Expired - Fee Related JP4739000B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2005353525A JP4739000B2 (ja) 2005-12-07 2005-12-07 電子文書管理プログラム、電子文書管理システム及び電子文書管理方法
US11/544,404 US8028169B2 (en) 2005-12-07 2006-10-06 Electronic document management program, electronic document management system and electronic document management method
EP06122206.3A EP1806678A3 (en) 2005-12-07 2006-10-12 Program, system and method for managing electronic documents
KR1020060103928A KR100822596B1 (ko) 2005-12-07 2006-10-25 전자 문서 관리 프로그램을 기록한 기록 매체, 전자 문서 관리 시스템 및 전자 문서 관리 방법
CN2006101366716A CN1992586B (zh) 2005-12-07 2006-11-09 电子文档管理系统及方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005353525A JP4739000B2 (ja) 2005-12-07 2005-12-07 電子文書管理プログラム、電子文書管理システム及び電子文書管理方法

Publications (2)

Publication Number Publication Date
JP2007156970A true JP2007156970A (ja) 2007-06-21
JP4739000B2 JP4739000B2 (ja) 2011-08-03

Family

ID=37579239

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005353525A Expired - Fee Related JP4739000B2 (ja) 2005-12-07 2005-12-07 電子文書管理プログラム、電子文書管理システム及び電子文書管理方法

Country Status (5)

Country Link
US (1) US8028169B2 (ja)
EP (1) EP1806678A3 (ja)
JP (1) JP4739000B2 (ja)
KR (1) KR100822596B1 (ja)
CN (1) CN1992586B (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009199385A (ja) * 2008-02-22 2009-09-03 Nec Corp 情報管理装置
US8223968B2 (en) 2007-12-27 2012-07-17 Fujitsu Limited Image data verification program recorded on a recording medium, image data verification method, and image data verification system
WO2019082442A1 (ja) * 2017-10-27 2019-05-02 日本電信電話株式会社 データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラム
JP2021081777A (ja) * 2019-11-14 2021-05-27 株式会社日立製作所 組織間の情報連携を制御するシステム
JP7526655B2 (ja) 2020-12-10 2024-08-01 富士通株式会社 情報処理プログラム、情報処理方法、情報処理装置および情報処理システム

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8958562B2 (en) * 2007-01-16 2015-02-17 Voltage Security, Inc. Format-preserving cryptographic systems
KR100911445B1 (ko) * 2007-08-13 2009-08-11 주식회사 아이콘랩 전자서명이 포함된 문서를 보관하는 장치, 방법 및 그 방법을 실행하는 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체
DE102007054649A1 (de) * 2007-11-15 2009-05-28 Siemens Ag Validierung elektronischer Objekte durch öffentliche vertrauenswürdige Filter
JP2009200595A (ja) * 2008-02-19 2009-09-03 Fujitsu Ltd 署名管理プログラム、署名管理方法及び署名管理装置
JP5387282B2 (ja) * 2009-09-25 2014-01-15 富士通株式会社 コンテンツ処理装置、コンテンツの部分完全性保証のためのプログラム
JP5684761B2 (ja) * 2012-08-31 2015-03-18 富士フイルム株式会社 医療支援装置及び医療支援方法
JP6364786B2 (ja) * 2014-01-24 2018-08-01 富士通株式会社 設計書管理プログラム、設計書管理方法および設計書管理装置
US10176193B2 (en) 2014-06-23 2019-01-08 International Business Machines Corporation Holding specific versions of a document
CN104156674A (zh) * 2014-08-13 2014-11-19 北京淦蓝润和信息技术有限公司 电子文档的处理方法及装置
US10853502B1 (en) 2015-03-04 2020-12-01 Micro Focus Llc Systems and methods for reducing computational difficulty of cryptographic operations
CN106487763B (zh) * 2015-08-31 2020-01-10 腾讯科技（深圳）有限公司 一种基于云计算平台的数据访问方法及用户终端
CN108664798B (zh) 2017-03-31 2021-06-29 北京京东尚科信息技术有限公司 信息加密方法和装置
US10749674B2 (en) 2017-09-29 2020-08-18 Micro Focus Llc Format preserving encryption utilizing a key version
US10673637B1 (en) * 2019-11-19 2020-06-02 Quantum Information Security, LLC Polymorphic digital security and methods of use thereof

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004364070A (ja) * 2003-06-06 2004-12-24 Hitachi Ltd マスキング可能な署名技術を用いた電子文書管理システム
JP2005031777A (ja) * 2003-07-08 2005-02-03 Hitachi Ltd ファイルセキュリティ維持処理方法及び実施装置並びに処理プログラム
JP2005124150A (ja) * 2003-07-31 2005-05-12 Sony United Kingdom Ltd デジタルコンテンツのためのアクセス制御
JP2005165738A (ja) * 2003-12-03 2005-06-23 Fusionsys:Kk 電子コンテンツ管理システム、電子コンテンツ管理方法、及びそのプログラム

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5825880A (en) * 1994-01-13 1998-10-20 Sudia; Frank W. Multi-step digital signature method and system
US6237096B1 (en) * 1995-01-17 2001-05-22 Eoriginal Inc. System and method for electronic transmission storage and retrieval of authenticated documents
JP3980785B2 (ja) 1999-03-30 2007-09-26 株式会社リコー 原本性保証電子保存装置、原本性保証電子保存方法およびその方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体
AU4460600A (en) * 1999-04-13 2000-11-14 Ilumin Corporation Collaborative creation, editing, reviewing, and signing of electronic documents
JP4011243B2 (ja) 1999-10-15 2007-11-21 富士通株式会社 電子原本管理装置および方法
US6950522B1 (en) * 2000-06-15 2005-09-27 Microsoft Corporation Encryption key updating for multiple site automated login
JP2003076822A (ja) * 2001-09-05 2003-03-14 Mitsubishi Electric Corp 文書管理システム
US7167986B2 (en) * 2001-12-26 2007-01-23 Storage Technology Corporation Upgradeable timestamp mechanism
US7317799B2 (en) * 2002-07-19 2008-01-08 Vadium Technology, Inc. Cryptographic key distribution using key folding
JP2004282677A (ja) * 2003-01-21 2004-10-07 Canon Inc 画像処理方法
JP4676136B2 (ja) * 2003-05-19 2011-04-27 株式会社日立製作所 文書構造検査方法および装置
JP2005051734A (ja) * 2003-07-15 2005-02-24 Hitachi Ltd 電子文書の真正性保証方法および電子文書の公開システム
US7930757B2 (en) * 2003-10-31 2011-04-19 Adobe Systems Incorporated Offline access in a document control system
KR100579147B1 (ko) * 2004-01-29 2006-05-12 (주)드림투리얼리티 전자문서파일의 위변조 검증 전자문서관리시스템 및 그를이용한 방법
JP4728104B2 (ja) * 2004-11-29 2011-07-20 株式会社日立製作所 電子画像の真正性保証方法および電子データ公開システム
CN100505621C (zh) * 2005-05-18 2009-06-24 上海龙方信息技术有限公司 数字签名锁定域的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004364070A (ja) * 2003-06-06 2004-12-24 Hitachi Ltd マスキング可能な署名技術を用いた電子文書管理システム
JP2005031777A (ja) * 2003-07-08 2005-02-03 Hitachi Ltd ファイルセキュリティ維持処理方法及び実施装置並びに処理プログラム
JP2005124150A (ja) * 2003-07-31 2005-05-12 Sony United Kingdom Ltd デジタルコンテンツのためのアクセス制御
JP2005165738A (ja) * 2003-12-03 2005-06-23 Fusionsys:Kk 電子コンテンツ管理システム、電子コンテンツ管理方法、及びそのプログラム

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8223968B2 (en) 2007-12-27 2012-07-17 Fujitsu Limited Image data verification program recorded on a recording medium, image data verification method, and image data verification system
JP2009199385A (ja) * 2008-02-22 2009-09-03 Nec Corp 情報管理装置
WO2019082442A1 (ja) * 2017-10-27 2019-05-02 日本電信電話株式会社 データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラム
JPWO2019082442A1 (ja) * 2017-10-27 2020-10-22 日本電信電話株式会社 データ登録方法、データ復号方法、データ構造、コンピュータ、及びプログラム
US11720689B2 (en) 2017-10-27 2023-08-08 Nippon Telegraph And Telephone Corporation Data registration method, data decryption method, data structure, computer, and program
JP2021081777A (ja) * 2019-11-14 2021-05-27 株式会社日立製作所 組織間の情報連携を制御するシステム
JP7351724B2 (ja) 2019-11-14 2023-09-27 株式会社日立製作所 組織間の情報連携を制御するシステム
JP7526655B2 (ja) 2020-12-10 2024-08-01 富士通株式会社 情報処理プログラム、情報処理方法、情報処理装置および情報処理システム

Also Published As

Publication number Publication date
EP1806678A3 (en) 2013-05-08
US20070130627A1 (en) 2007-06-07
CN1992586B (zh) 2011-10-05
KR20070059942A (ko) 2007-06-12
US8028169B2 (en) 2011-09-27
EP1806678A2 (en) 2007-07-11
KR100822596B1 (ko) 2008-04-16
CN1992586A (zh) 2007-07-04
JP4739000B2 (ja) 2011-08-03

Similar Documents

Publication Publication Date Title
JP4739000B2 (ja) 電子文書管理プログラム、電子文書管理システム及び電子文書管理方法
US10135797B2 (en) Method and system for the supply of data, transactions and electronic voting
JP5028884B2 (ja) 電子文書管理システム、電子文書管理方法、電子文書管理プログラム
TWI614636B (zh) 基於數位簽章代碼的內容驗證方法
KR101968079B1 (ko) 전자증명서 관리 시스템 및 그 방법
JP4664107B2 (ja) 事業者側装置、利用者側装置、個人情報閲覧更新システムおよび個人情報閲覧更新方法
JP2009104448A (ja) 申請処理プログラム、申請処理方法、および仲介サーバ装置、並びに仲介サーバシステム
US8799675B2 (en) System and method for electronic certification and authentication of data
KR20100114321A (ko) 디지털 콘텐츠 거래내역 인증확인 시스템 및 그 방법
KR101449806B1 (ko) 디지털 정보 상속 방법
EP4409426A1 (en) Groups a and b: system and method for decentralized timestamping of a submission of content onto a blockchain group c: method for timestamping verification of a submission of content onto a blockchain
Reed Legally binding electronic documents: digital signatures and authentication
JP2012248915A (ja) 識別名管理システム
KR20160020850A (ko) 인증서 발급 및 전자 서명 위임 방법 및 서버
JP2004363779A (ja) 認証システムおよび記録サーバ
Karuppiah Blockchain for digital rights management
WO2010018587A1 (en) Verification of document and it's conveying information for the reliable authentification
Bhaskar et al. THE ELECTRONIC TRANSACTIONS AND IPRs: A NEED FOR DIGITAL TIME STAMPING
Lacoste et al. Chapter 14: Legal Aspects

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080416

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110411

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110426

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110427

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140513

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees