特開2019-179579(P2019-179579A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 富士ゼロックス株式会社の特許一覧
特開2019-179579ドキュメント管理システム、処理装置及び管理装置
<>
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000003
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000004
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000005
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000006
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000007
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000008
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000009
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000010
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000011
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000012
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000013
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000014
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000015
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000016
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000017
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000018
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000019
  • 特開2019179579-ドキュメント管理システム、処理装置及び管理装置 図000020
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2019-179579(P2019-179579A)
(43)【公開日】2019年10月17日
(54)【発明の名称】ドキュメント管理システム、処理装置及び管理装置
(51)【国際特許分類】
   G06F 13/00 20060101AFI20190920BHJP
   G06F 21/62 20130101ALI20190920BHJP
【FI】
   G06F13/00 520B
   G06F21/62 309
【審査請求】有
【請求項の数】10
【出願形態】OL
【全頁数】40
(21)【出願番号】特願2019-123548(P2019-123548)
(22)【出願日】2019年7月2日
(62)【分割の表示】特願2017-52850(P2017-52850)の分割
【原出願日】2017年3月17日
(71)【出願人】
【識別番号】000005496
【氏名又は名称】富士ゼロックス株式会社
(74)【代理人】
【識別番号】110001210
【氏名又は名称】特許業務法人YKI国際特許事務所
(72)【発明者】
【氏名】神谷 成樹
(72)【発明者】
【氏名】伊與田 哲男
【テーマコード(参考)】
5B084
【Fターム(参考)】
5B084AA01
5B084AA12
5B084AB01
5B084AB31
5B084BB01
5B084BB16
5B084CA11
5B084CB04
5B084CB22
5B084CC04
5B084CC17
5B084CD02
5B084CD24
(57)【要約】
【課題】入力されたドキュメントのメタデータを生成する処理装置がシステム内に複数存在する場合に、対象のドキュメントのメタデータを生成した処理装置を特定しなくても、そのドキュメントのメタデータを取得できるようにする。
【解決手段】処理装置#1は、作成端末102から登録されたドキュメントを暗号化等により処理済みドキュメントに変換し、指定された配信先の閲覧端末104に配信する。また配信先情報を含むそのドキュメントのメタデータを生成して保存すると共に、上位のローカルメタデータサーバ156に登録する。別の場所の処理装置#2は、閲覧端末104を使用するユーザが自身に登録されていない場合、上位のローカルユーザIDサーバ152にユーザ認証を依頼し、また要求された処理済みドキュメントのメタデータを持っていない場合は上位のローカルメタデータサーバ156からそのメタデータを取得して閲覧端末104に送信する。
【選択図】図13
【特許請求の範囲】
【請求項1】
管理装置と複数の処理装置とを含み、
前記複数の処理装置の各々は、
ドキュメントとそのドキュメントの送信先の情報を取得する取得手段と、
前記送信先の情報を含む前記ドキュメントのメタデータを前記管理装置に送信すると共に、前記ドキュメントを処理することにより得られた処理済みドキュメントを前記送信先に送信する送信手段と、
を含み、
前記管理装置は、
前記複数の処理装置の各々から受信した各ドキュメントのメタデータを記憶する記憶手段と、
ドキュメントに対応するメタデータを要求された場合に、前記記憶手段内のそのドキュメントのメタデータを応答する応答手段と、
を含む、ドキュメント管理システム。
【請求項2】
前記処理装置から前記処理済みドキュメントを受信する第1受信手段と、
前記管理装置から前記処理済みドキュメントに対応する前記メタデータを受信する第2受信手段と、
を含む閲覧装置、を更に含む請求項1に記載のドキュメント管理システム。
【請求項3】
前記処理済みドキュメントは、前記取得手段が取得した前記ドキュメントに暗号化処理を施すことにより生成されたものであり、
前記処理装置は、
前記送信手段が送信した前記処理済みドキュメントを生成した際に用いられた前記暗号化処理に脆弱性が見つかった場合に、脆弱性が見つかっていない第2の暗号化処理を前記ドキュメントに施すことで第2の処理済みドキュメントを生成し、前記送信手段を用いて前記第2の処理済みドキュメントを前記送信先の前記閲覧装置に送信する制御を行う制御手段と、
を更に含む請求項2に記載のドキュメント管理システム。
【請求項4】
前記制御手段は、前記送信先の前記閲覧装置に対して、脆弱性が見つかった前記暗号化処理により生成した前記処理済みドキュメントを削除させる制御を更に行う、ことを特徴とする請求項3に記載のドキュメント管理システム。
【請求項5】
前記複数の処理装置の各々は、それぞれ当該処理装置に対応するローカルネットワーク上に設けられており、
前記管理装置は、外部ネットワーク上に設けられており、前記外部ネットワークは、前記複数の処理装置の各々が設けられた各ローカルネットワークの外部のネットワークであり、それら各ローカルネットワークに接続されており、
前記閲覧装置の前記第1受信手段は、当該閲覧装置と同じローカルネットワークに接続されている前記処理装置から前記処理済みドキュメントを受信し、
前記閲覧装置の前記第2受信手段は、前記外部ネットワーク上の前記管理装置から前記処理済みドキュメントに対応するメタデータを受信する、
請求項2に記載のドキュメント管理システム。
【請求項6】
前記送信手段が前記管理装置に送信する前記メタデータには、前記ドキュメントを処理した前記処理装置を特定する情報が更に含まれる、
請求項1〜5のいずれか1項に記載のドキュメント管理システム。
【請求項7】
ドキュメントとそのドキュメントの送信先の情報を取得する取得手段と、
各処理装置から送られてくる各ドキュメントの管理情報を管理する管理装置に対して、前記送信先の情報を含む前記ドキュメントのメタデータを送信すると共に、前記ドキュメントを処理することにより得られた処理済みドキュメントを前記送信先に送信する送信手段と、
を有する処理装置。
【請求項8】
前記処理済みドキュメントは、前記取得手段が取得した前記ドキュメントに暗号化処理を施すことにより生成されたものであり、
前記送信手段が送信した前記処理済みドキュメントを生成した際に用いられた前記暗号化処理に脆弱性が見つかった場合に、脆弱性が見つかっていない第2の暗号化処理を前記ドキュメントに施すことで第2の処理済みドキュメントを生成し、前記送信手段を用いて前記第2の処理済みドキュメントを前記送信先に送信する制御を行う制御手段、
を更に含む請求項7に記載の処理装置。
【請求項9】
前記制御手段は、前記送信先に対して、脆弱性が見つかった前記暗号化処理により生成した前記処理済みドキュメントを削除させる制御を更に行う、ことを特徴とする請求項8に記載の処理装置。
【請求項10】
複数の処理装置と協働する管理装置であって、
前記複数の処理装置の各々は、ドキュメントとそのドキュメントの送信先の情報を取得し、前記送信先の情報を含む前記ドキュメントのメタデータを前記管理装置に送信すると共に、前記ドキュメントを処理することにより得られた処理済みドキュメントを前記送信先に送信し、
前記管理装置は、
前記複数の処理装置の各々から受信した各ドキュメントのメタデータを記憶する記憶手段と、
ドキュメントに対応するメタデータを要求された場合に、前記記憶手段内のそのドキュメントのメタデータを応答する応答手段と、
を含む、管理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ドキュメント管理システム、処理装置及び管理装置に関する。
【背景技術】
【0002】
特許文献1に開示されたシステムでは、表示装置またはプリンタのあるコンピュータを有する複数のユーザから、文書に対する要求を固有のユーザ識別情報とともに受信する。次に、複数のユーザからの要求を著作権サーバで認証する。次に、著作権サーバは、文書サーバに対し各要求の正しい認証に作用するよう指令する。これに応答して、文書サーバは、認証された各要求に対して、独自に符号化され圧縮され暗号化された文書を作成し、認証された各要求ユーザへの文書を、ネットワークを通じて、認証された各要求ユーザの対応する表示または印刷のエージェントへ転送する。文書は、複数のユーザのそれぞれに対応して独自に符号化される。最後に、各エージェントで文書の復号および圧縮解除を行い、認証された要求ユーザによってエージェントに提供された正しい秘密鍵にのみ応答して文書を利用可能にする。
【0003】
特許文献2には、文書に対して一意な文書識別子を付与し、その文書識別子の一意性を維持するための仕組みが記載されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開平7−239828号公報
【特許文献2】特開平9−223130号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
ドキュメントをユーザに提供するシステムは、対象となるドキュメントをシステムに登録する装置が、そのドキュメントの属性情報を示すメタデータを生成し、生成したメタデータをドキュメントに対応付けて保持し、メタデータを用いてドキュメントの提供や管理を行う。この種のシステムでは、ドキュメントの登録を行う装置がシステム内に複数存在する場合、あるドキュメントのメタデータを取得するには、そのドキュメントを登録した装置を特定し、特定した装置からメタデータを取得する必要がある。
【0006】
本発明は、入力されたドキュメントのメタデータを生成する処理装置がシステム内に複数存在する場合に、対象のドキュメントのメタデータを生成した処理装置を特定しなくても、そのドキュメントのメタデータを取得できるようにすることを目的とする。
【課題を解決するための手段】
【0007】
請求項1に係る発明は、管理装置と複数の処理装置とを含み、前記複数の処理装置の各々は、ドキュメントとそのドキュメントの送信先の情報を取得する取得手段と、前記送信先の情報を含む前記ドキュメントのメタデータを前記管理装置に送信すると共に、前記ドキュメントを処理することにより得られた処理済みドキュメントを前記送信先に送信する送信手段と、を含み、前記管理装置は、前記複数の処理装置の各々から受信した各ドキュメントのメタデータを記憶する記憶手段と、ドキュメントに対応するメタデータを要求された場合に、前記記憶手段内のそのドキュメントのメタデータを応答する応答手段と、を含む、ドキュメント管理システムである。
【0008】
請求項2に係る発明は、前記処理装置から前記処理済みドキュメントを受信する第1受信手段と、前記管理装置から前記処理済みドキュメントに対応する前記メタデータを受信する第2受信手段と、を含む閲覧装置、を更に含む請求項1に記載のドキュメント管理システムである。
【0009】
請求項3に係る発明は、前記処理済みドキュメントは、前記取得手段が取得した前記ドキュメントに暗号化処理を施すことにより生成されたものであり、前記処理装置は、前記送信手段が送信した前記処理済みドキュメントを生成した際に用いられた前記暗号化処理に脆弱性が見つかった場合に、脆弱性が見つかっていない第2の暗号化処理を前記ドキュメントに施すことで第2の処理済みドキュメントを生成し、前記送信手段を用いて前記第2の処理済みドキュメントを前記送信先の前記閲覧装置に送信する制御を行う制御手段と、を更に含む請求項2に記載のドキュメント管理システムである。
【0010】
請求項4に係る発明は、前記制御手段は、前記送信先の前記閲覧装置に対して、脆弱性が見つかった前記暗号化処理により生成した前記処理済みドキュメントを削除させる制御を更に行う、ことを特徴とする請求項3に記載のドキュメント管理システムである。
【0011】
請求項5に係る発明は、前記複数の処理装置の各々は、それぞれ当該処理装置に対応するローカルネットワーク上に設けられており、前記管理装置は、外部ネットワーク上に設けられており、前記外部ネットワークは、前記複数の処理装置の各々が設けられた各ローカルネットワークの外部のネットワークであり、それら各ローカルネットワークに接続されており、前記閲覧装置の前記第1受信手段は、当該閲覧装置と同じローカルネットワークに接続されている前記処理装置から前記処理済みドキュメントを受信し、前記閲覧装置の前記第2受信手段は、前記外部ネットワーク上の前記管理装置から前記処理済みドキュメントに対応するメタデータを受信する、請求項2に記載のドキュメント管理システムである。
【0012】
請求項6に係る発明は、前記送信手段が前記管理装置に送信する前記メタデータには、前記ドキュメントを処理した前記処理装置を特定する情報が更に含まれる、請求項1〜5のいずれか1項に記載のドキュメント管理システムである。
【0013】
請求項7に係る発明は、ドキュメントとそのドキュメントの送信先の情報を取得する取得手段と、各処理装置から送られてくる各ドキュメントの管理情報を管理する管理装置に対して、前記送信先の情報を含む前記ドキュメントのメタデータを送信すると共に、前記ドキュメントを処理することにより得られた処理済みドキュメントを前記送信先に送信する送信手段と、を有する処理装置である。
【0014】
請求項8に係る発明は、前記処理済みドキュメントは、前記取得手段が取得した前記ドキュメントに暗号化処理を施すことにより生成されたものであり、前記送信手段が送信した前記処理済みドキュメントを生成した際に用いられた前記暗号化処理に脆弱性が見つかった場合に、脆弱性が見つかっていない第2の暗号化処理を前記ドキュメントに施すことで第2の処理済みドキュメントを生成し、前記送信手段を用いて前記第2の処理済みドキュメントを前記送信先に送信する制御を行う制御手段、を更に含む請求項7に記載の処理装置である。
【0015】
請求項9に係る発明は、前記制御手段は、前記送信先に対して、脆弱性が見つかった前記暗号化処理により生成した前記処理済みドキュメントを削除させる制御を更に行う、ことを特徴とする請求項8に記載の処理装置である。
【0016】
請求項10に係る発明は、複数の処理装置と協働する管理装置であって、前記複数の処理装置の各々は、ドキュメントとそのドキュメントの送信先の情報を取得し、前記送信先の情報を含む前記ドキュメントのメタデータを前記管理装置に送信すると共に、前記ドキュメントを処理することにより得られた処理済みドキュメントを前記送信先に送信し、前記管理装置は、前記複数の処理装置の各々から受信した各ドキュメントのメタデータを記憶する記憶手段と、ドキュメントに対応するメタデータを要求された場合に、前記記憶手段内のそのドキュメントのメタデータを応答する応答手段と、を含む、管理装置である。
【発明の効果】
【0017】
請求項1、2、6、7、又は10に記載の発明によれば、入力されたドキュメントのメタデータを生成すると共に送信先に送信する処理装置がシステム内に複数存在する場合に、対象のドキュメントのメタデータを生成した処理装置を特定しなくても、そのドキュメントのメタデータを取得できる。
【0018】
請求項3又は8に係る発明によれば、送信先が、脆弱性の見つかった暗号化処理により生成された処理済みドキュメントの代わりに、脆弱性の見つかっていない第2の暗号化処理により生成された第2の処理済みドキュメントを用いられるようにすることができる。
【0019】
請求項4又は9に係る発明によれば、脆弱性の見つかった暗号化処理により生成された処理済みドキュメントが不正利用されることを防ぐことができる。
【0020】
請求項5に係る発明によれば、処理装置が持つ処理済みドキュメントがその処理装置が設けられているローカルネットワークの外部の外部ネットワークに流れることを防ぎつつも、その処理済みドキュメントを受信した閲覧装置は、そのローカルネットワークの外に出た場合でも、管理装置からメタデータを取得してその処理済みドキュメントを閲覧することができる。
【図面の簡単な説明】
【0021】
図1】ドキュメント管理システムの構成の例を示す図である。
図2】ドキュメント管理システムを利用したドキュメントの配信及び閲覧の概要を説明するための図である。
図3】メタデータのデータ内容を例示する図である。
図4】ユーザIDサーバが管理するデータ内容を例示する図である。
図5】DIDサーバが管理するデータ内容を例示する図である。
図6】処理装置管理サーバが管理するデータ内容を例示する図である。
図7】処理装置の構成及び処理装置が持つデータ内容を例示する図である。
図8】ドキュメント管理システムにおけるドキュメント配信及び閲覧の流れを説明する図である。
図9】属性データの入力画面の例を示す図である。
図10】オプション設定画面の例を示す図である。
図11】リスト画面の例を示す図である。
図12】組織内管理システムを設けたシステム構成の例を示す図である。
図13】ユーザが自分の登録されていない処理装置を用いてドキュメントのメタデータ取得及び閲覧を行う際の処理の流れの例を示す図である。
図14】ユーザが自分の登録されていない処理装置を用いてドキュメント管理システムにドキュメントを登録する際の処理の流れの例を示す図である。
図15】DIDのデータ内容の例を示す図である。
図16】処理装置管理サーバが実行する処理装置のステータスチェック処理の流れを例示する図である。
図17】処理装置管理サーバが実行する処理装置のステータスチェック処理の流れの別の例を示す図である。
図18】暗号化ソフトに脆弱性が見つかった場合の処理装置の処理の流れを例示する図である。
【発明を実施するための形態】
【0022】
図1に、ドキュメント管理システムの一つの実施形態の概略構成を示す。
【0023】
紙の文書の場合、文書を持つ者が自由にコピーしたり他人に渡したりすることができる。また、文書を入手した者は、その文書を読むことができる。このように、紙の文書は情報漏洩を招くリスクが極めて高い。
【0024】
これに対して、本実施形態のドキュメント管理システムは、電子的なドキュメントをセキュアに利用できる環境を提供し、ドキュメントの情報が漏洩するリスクを下げることを目指す。ここで、ドキュメントは、1つの単位(例えば1つのファイル)として流通可能なコンテントデータであり、データの種類は特に限定されない。例えば、ドキュメントの概念には、テキストデータ、ワードプロセッサソフトで作成された文書データ、表計算ソフトで作成されたスプレッドシートデータ、CAD(Computer Aided Design)データ、画像データ、動画データ、音声データ、マルチメディアデータ、ウェブブラウザで表示されたページデータ、その他PC上で作成・編集・閲覧されプリントアウト対象となる様なデータなどが含まれる。
【0025】
このドキュメント管理システムは、複数のローカルシステム100とそれらローカルシステムに関する管理(特に後述する処理システムの管理)を行う管理システム200とを含む。管理システム200は、インターネット等の広域ネットワーク10を介して各ローカルシステム100と通信可能である。
【0026】
ローカルシステム100は、ローカルネットワーク108に接続された1以上の作成端末102、1以上の閲覧端末104、及び処理装置110を含む。ローカルネットワーク108は、企業等の組織内に設けられたプライベートネットワーク(例えばLANとして構成)であり、ファイアウォール等により広域ネットワーク10から保護されている。処理装置110は、基本的に、ローカルシステム100内に1つ設置される。組織内のプライベートネットワークが大規模なものである場合、プライベートネットワークを構成する個々のネットワークセグメントをそれぞれローカルシステム100とし、それら個々のローカルシステム100内に1つずつ処理装置110を設置してもよい。例えば、ある会社の部署毎の居室内のネットワークセグメントがそれぞれその部署のローカルシステム100となり、そのセグメントに1つの処理装置110が設置される。この例では、会社毎や各会社の部署毎に処理装置110を核とするローカルシステム100が形成され、それら各処理装置110が中央にある管理システム200から管理される。
【0027】
作成端末102は、ドキュメントを作成するために用いられる端末であり、例えばデスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン、複合機、スキャナ、ファクシミリ装置、デジタルカメラ等がその例である。作成端末102には、ドキュメントの作成、編集等のためのアプリケーションがインストールされている。また、作成端末102には、作成したドキュメントの配信をドキュメント管理システムに依頼するためのソフトウエアがインストールされている。このソフトウエアの形態としては、後述する処理装置110と情報をやりとりするデバイスドライバとして実装、またはWebアプリによる実装、などが考えられる。
【0028】
処理装置110は、作成端末102が作成したドキュメントを、本実施形態のドキュメント管理システムが提供するセキュアな環境で用いる形態である保護済みドキュメント(以下では「eDocファイル」とも呼ぶ)へと変換するという保護処理を実行する。保護処理は、元のドキュメントをeDocへとエンコードする処理ともいえ、この意味では処理装置110は一種のエンコーダである。この保護処理では、ドキュメントを、例えば、本実施形態のシステムのために設計された専用フォーマットのデータに変換すると共に、そのドキュメントの配信先に指定されたユーザにのみ復号可能な形で暗号化する。フォーマット変換と暗号化はどちらを先に行ってもよい。
【0029】
また処理装置110は、保護済みドキュメントのメタデータを作成し、作成したメタデータを上位システムである管理システム200に登録する。メタデータは、当該保護済みドキュメントの書誌事項、配信先の情報、各配信先が保護済みドキュメントの暗号化を解除するのに用いるキーの情報等を含む。メタデータは複数の項目を含み、このサービスで提供される機能に応じて対応するデバイスやユーザからデータ付与・編集・更新が実行される。
【0030】
例として、それら項目のうちの一部を、ドキュメント管理システムに対するドキュメントの登録指示を行ったユーザが指定し、別の一部は処理装置110が作成する。また、メタデータのうちの一部の項目の値を管理システム200や閲覧端末104が設定することもあり得る。また、処理装置110は、生成した保護済みドキュメント(eDocファイル)を、ユーザの指定した配信先の閲覧端末104に送信する。
【0031】
保護済みドキュメントすなわちeDocファイルは、元のドキュメントを専用フォーマットに変換し暗号化したものであり、eDocの本体とも呼ぶ。eDocファイルを閲覧可能とするには、対応するメタデータが必要となる。eDocファイルとメタデータとが揃って、閲覧可能な完全な保護済みドキュメントを構成する。このように、eDocファイルとこれに対応するメタデータとの組を、以下では「eDoc」と呼ぶ。
【0032】
処理装置110は、無線LANのアクセスポイントの機能を内蔵していてもよい。この場合、閲覧端末104は、無線LANで処理装置110と通信可能である。
【0033】
閲覧端末104は、保護済みドキュメント(eDocファイル)の閲覧に用いられる端末である。ここで言う「閲覧」は、保護済みドキュメントをそのドキュメントが表す情報内容に応じた態様で利用することを意味する。例えば、保護済みドキュメントがワープロデータや図面等の文書を情報内容として持つ場合、閲覧は、閲覧端末104が表示したその文書をユーザが読む又は見ることである。また保護済みドキュメントが表す情報内容が音声である場合、閲覧とは、閲覧端末104が再生したその音声をユーザが聞くことである。閲覧端末104は、例えば、デスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン等の汎用のコンピュータに、保護済みドキュメントを閲覧するためのビューワアプリケーションをインストールして構成される。また、電子書籍端末のような閲覧専用の端末に、ビューワアプリケーションと同等の機能を持たせたものを閲覧端末104として用いてもよい。ビューワアプリケーションは、暗号化されている保護済みドキュメントをメタデータの情報を用いて復号する機能や、保護済みドキュメントの専用フォーマットで表されるデータを可読な状態のデータへとデコードする機能を有する。なお、本実施形態のドキュメント管理システムに対応するビューワアプリケーションを持たないコンピュータは、専用フォーマットのデータを可読なデータへとデコードすることはできない。
【0034】
閲覧端末104は、保護済みドキュメントを復号及びデコードして表示する機能に加え、表示したそのドキュメントに対するユーザからの加工(編集)を受け付ける機能を有していてもよい。加工されたドキュメントは、元の保護済みドキュメントとは異なる内容となるが、この編集後のドキュメントを閲覧端末104から処理装置110に送ってドキュメント管理システムに登録(すなわち保護済みドキュメントへとエンコード)できるようにしてもよい。このように、1つの端末が、作成端末102と閲覧端末104の両方の機能を持っていてもよい。なお、eDocには閲覧者に許可する権限(後述するメタデータ中のアクセス権限情報)が設定されており、その権限の内容には、そのeDocへの書き込み制限、再配布先の制限などが含まれてもよい。このような制限がアクセス権限情報中に規定されているeDocの場合、閲覧端末104は、閲覧者からの加工(編集)操作をその書き込み制限の範囲内でのみ受け付け、また加工後の新たなeDocの再配布先の指定を、その再配布先の制限の範囲内でのみ受け付ける。
【0035】
また、本実施形態では、一例として、本実施形態のドキュメント管理システムを利用するユーザを認証するためのツールとして、ユーザが携帯する認証デバイス130を用いる。認証デバイス130は、ICカードのように、当該デバイスを携帯するユーザに固有の識別情報を内蔵し、外部装置からの要求に応じてユーザ認証のためのデータ処理を実行するデバイスである。認証デバイス130は、そのような個人認証用のICカードと同等の機能を内蔵したスマートフォンのような携帯端末であってもよい。閲覧端末104や作成端末102は、NFC(Near Field Communication)等の無線通信プロトコルを用いて認証デバイス130と通信する機能を備える。閲覧端末104や作成端末102は、認証デバイス130との間で所定のプロトコルに沿ってユーザ認証のための情報をやりとりし、その認証デバイス130を携帯するユーザを認証する。あるいは、実際のユーザ認証は処理装置110や管理システム200等、本実施形態のドキュメント管理システムのサーバ側が実行し、閲覧端末104や作成端末102は、サーバ側と認証デバイス130との間のデータ転送の仲介を行う方式であってもよい。また、閲覧端末104や作成端末102が認証デバイス130の機能を内蔵していてもよい。
【0036】
管理システム200は、各ローカルシステム100内の処理装置110を管理する。また管理システム200は、それら各処理装置110が生成した保護済みドキュメントのメタデータを管理し、要求に応じてメタデータを閲覧端末104に提供する。管理システム200は、1台のコンピュータ、又は相互に通信可能な複数のコンピュータにより構成され、ユーザIDサーバ210、DIDサーバ220、メタデータサーバ230、処理装置管理サーバ240の機能を有する。
【0037】
ユーザIDサーバ210は、ドキュメント管理システムを利用する各ユーザの情報を管理するサーバである。ドキュメント管理システムを利用するユーザには、2つの階層がある。1つは、ドキュメント管理システムの利用のための契約を本システムの運営者と結んだ契約者であり、もう1つはその契約の下で実際にシステムを利用してドキュメントの登録や閲覧を行う一般ユーザである。例えば、会社が契約者であり、その会社のローカルネットワーク108に処理装置110が設置され、その会社の社員が一般ユーザとして、その処理装置110を介してドキュメント管理システムを利用するケースが多いと想定される。ユーザIDサーバ210は、契約者と一般ユーザのそれぞれについての情報を保持し、管理する。
【0038】
DIDサーバ220は、保護済みドキュメントの識別情報(ID)であるDID(ドキュメントID)を管理する。実際に保護済みドキュメントにDIDを付与するのはその保護済みドキュメントを作成した処理装置110であるが、DIDサーバ220は処理装置110に対してDIDの発行権限と発行枠(発行数)を付与し、その発行権限と発行枠の中で処理装置110が実際に発行したDIDの報告を受けて記録する。これにより、DIDサーバ220は、不正なDIDの発生を抑止し、不正なDIDを持つドキュメントを検知可能とする。
【0039】
メタデータサーバ230は、処理装置110が生成した保護済みドキュメント(eDocファイル)のメタデータを保持し、管理する。メタデータサーバ230は、ユーザから閲覧端末104を介して保護済みドキュメントのメタデータを要求された場合、そのユーザが正当な者であれば、メタデータをその閲覧端末104に提供する。なお、メタデータを要求するユーザ(閲覧者)がメタデータサーバ230にとって「正当な者」であるとは、そのユーザと、そのユーザがその要求を発する際に用いた閲覧端末104との組合せが、そのeDocファイルのDID(これはその要求に含まれる)に対応づけてメタデータサーバ230が保持しているメタデータ中の配信先情報(詳しくは後述)に示される配信先ユーザ及び配信先の閲覧端末104の組合せに該当する場合のことである。
【0040】
処理装置管理サーバ240は、各処理装置110のステータス(状態)を管理するサーバである。
【0041】
図2を参照して、本実施形態の仕組みを概略的に説明する。
【0042】
(0)管理システム200(DIDサーバ220)は、ローカルシステム100内の処理装置110に対してDID(ドキュメントID)の発行権及びこれに付随する発行枠(ドキュメント数)を事前に付与している。DIDの発行権は、無制限ではなく、管理システム200発行枠に制限される。すなわち、処理装置110は、管理システム200から付与された発行枠が示す数までのドキュメントであれば、同時に付与された発行権に基づいたDIDを付与することができる。発行枠を使い切れば、処理装置110は、管理システム200から新たな発行権及び発行枠の付与を受ける。
【0043】
(1)ユーザは、ドキュメントを本実施形態のドキュメント管理システムに登録したい(すなわち配信したい)場合、作成端末102にドキュメント登録を指示する(例えばアプリケーションのメニュー上で「登録」を指示する)。この指示を受けた作成端末102は、ユーザ認証を求める。この認証は、ユーザID及びパスワードの入力により行ってもよいし、作成端末102のカードリーダ部の近傍にユーザが認証デバイス130を近づけることで行ってもよい。ユーザ認証は、作成端末102が行ってもよいし、ドキュメントの登録先である処理装置110が行ってもよい。そして、ユーザは、作成端末102に保持されているドキュメントからドキュメント管理システムに登録するものを選んでその登録を指示する。
【0044】
作成端末102(より詳しくは、作成端末102にインストールされた登録処理用プログラム)は、ユーザからドキュメントの登録指示を受けた場合、そのドキュメントに対する属性データのうちそのユーザが指定すべき項目(例えばドキュメントの配信先)の入力を受け付ける。ここで、配信先として、ユーザと閲覧端末104の組合せの指定を受け付けるようにしてもよい。この場合、ユーザと、そのユーザがドキュメントの閲覧に用いる閲覧端末104との組合せが、配信先として指定された組合せと一致する場合に、ユーザはそのドキュメントを閲覧可能となる。
【0045】
作成端末102は、ユーザが入力した配信先等の属性項目と、作成端末102自身が生成した他の属性項目(例えば登録者の情報、作成日時等)と合わせた属性データを、そのドキュメントのデータと共に処理装置110に送信する。なお、作成端末102は、様々なアプリケーションが作成した様々なフォーマットのドキュメントを、閲覧端末104側で取扱可能な統一的なフォーマットに変換するドライバを有していてもよい。例えば、ワープロデータ、スプレッドシート、CADデータのような静的な文書画像を示すデータの場合、そのドライバは、プリンタドライバと同様、そのデータをページ記述言語で表現されたドキュメントへと変換する。また、例えば、元のデータが音声データの場合、ドライバは、その音声データを本実施形態のドキュメント管理システム(特に閲覧端末104)が対応する特定の音声データ形式のデータ(ドキュメント)へと変換する。
【0046】
(2)処理装置110は、作成端末102から受信した登録対象のドキュメントに対して保護処理を施すことで保護済みドキュメント(eDocファイル)を生成する。この生成では、受信したドキュメントを本実施形態のドキュメント管理システムの専用フォーマットへとエンコードし、エンコードしたデータを、生成した暗号鍵を用いて暗号化することで、eDocファイルを生成する。エンコードと暗号化の順序は逆でもよい。また処理装置110は、そのeDocに対して一意なDIDを付与する。このDIDには、管理システム200から受けた発行権限に基づくものであることを証する情報(後述する発行権限キー)と、その処理装置110自身が付与したものであることを証する情報(後述する発行証明キー)が含まれる。なお、DIDのデータ構造については、後で詳細な例を説明する。生成されたDIDは、eDocファイル内に(例えばそのファイルのプロパティの一項目として)組み込まれる。
【0047】
また処理装置110は、生成したeDocファイルに対応するメタデータを生成する。このメタデータには、作成端末102からそのドキュメントと共に受け取った属性データと、処理装置110自身が生成した属性項目(例えば、DID、処理装置自身のID、エンコード日時、暗号鍵情報)の値とが含まれる。メタデータに含まれる暗号鍵情報は、eDocファイルの暗号化を解除するための鍵を示す情報である。暗号化に共通鍵方式を用いた場合、暗号鍵情報はその共通鍵を示す情報である。ただし、共通鍵そのものを平文でメタデータに含めると、盗聴や傍受により悪用される懸念があるので、その共通鍵を配信先ユーザの公開鍵で暗号化したものを暗号鍵情報としてメタデータに組み込む。
【0048】
また、処理装置110は、生成したeDocファイルとメタデータを、内蔵するデータベースに保存する。
【0049】
(3)処理装置110は、生成したメタデータを管理システム200に送信して登録する。管理システム200(メタデータサーバ230)は、受信したメタデータを保存する。
【0050】
(4)処理装置110は、生成したeDocファイルを、配信先に指定された閲覧端末104に配信する。この配信は、プッシュ型でもプル型でも、それら両方(例えばeDoc作成時にプッシュ配信し、そのときに非稼働で受信しなかった閲覧端末104はプル型で配信を受ける)であってもよい。この配信は、ローカルシステム100内のローカルネットワーク108を介して行われる。
【0051】
(5)閲覧端末104が受信したeDocファイルは、暗号化等により保護されているのでそのままでは閲覧が不可能である。ユーザは、閲覧端末104でそのeDocファイルを閲覧したい場合、自分の認証デバイス130をその閲覧端末104のカードリーダ部に近づけてユーザ認証を受けた後、閲覧端末104の画面上でそのeDocの閲覧を指示する。この指示を受けた閲覧端末104は、管理システム200にアクセスしてそのeDocのメタデータを要求する。この要求には、そのeDocのDIDが含まれる。
【0052】
(6)管理システム200(メタデータサーバ230)は、閲覧端末104から要求されたeDocの最新のメタデータをその閲覧端末104に送信する。
【0053】
(7)閲覧端末104は、要求したメタデータを管理システム200から受信すると、そのメタデータに含まれる配信先情報に、当該閲覧端末104と現在この閲覧端末104を利用しているユーザ(認証デバイス130で認証済み)との組合せが含まれるかどうかを判定する。含まれていない場合、そのユーザはその閲覧端末104でそのeDocを閲覧する権限がないので、閲覧端末104はeDocファイルを開かず、閲覧権限がない旨を示すエラーメッセージを表示する。含まれる場合は、そのユーザはその閲覧端末104でそのeDocファイルを閲覧する権限を持つ。この場合閲覧端末104は、そのeDocファイルをそのメタデータに含まれる暗号鍵情報を用いて復号し、画面に表示する(すなわちそのeDocファイルの情報内容に応じた態様で出力する)。
【0054】
メタデータには有効期限を設定する事が出来る。有効期限は、例えばメタデータが送信された日時に対し、規定の有効期間、または配信者等が指定した有効期間を足すことで求められる。閲覧端末104は、メタデータの有効期限が過ぎた後には、メタデータを再度管理システム200から取得し直さないと、対応するeDocファイルを開く(復号及び表示する)ことができない。閲覧端末104は、処理装置110又は管理システム200と通信可能であれば、閲覧対象に指示されたeDocファイルのその指示の時点での最新のメタデータを処理装置110又は管理システム200から取得し、この最新のメタデータに基づいて閲覧可否を判定する。
【0055】
メタデータが最初の管理システム200に登録された後、そのメタデータに含まれる配信先情報やアクセス権限情報が配信者、または配信先の変更権限が与えられた者(例えばデータの編集権限を保有する者)により変更されることがある。eDocが作成・登録された時点で配信先に指定されたユーザであっても、その後の変更により配信先から外された場合には、閲覧端末104は、管理システム200から取得した最新のメタデータに含まれる配信先情報によりそのことを検知し、eDocファイルの表示を行わない。
【0056】
次に、図3を参照して、eDocのメタデータ300のデータ内容の例を説明する。
【0057】
メタデータ300の含む項目のうち、まず「DID」は、そのeDocを生成した処理装置110が付与したドキュメントIDである。「ドキュメント名」は、そのeDocの名称又はタイトルである。
【0058】
「配信者ID」は、そのeDocを配信した者、すなわち作成端末102から処理装置110に対してドキュメントの登録操作を行い、処理装置110を介して配信を行う者(以下、配信者と呼ぶ)のユーザIDである。
【0059】
「エンコード日時」は、作成端末102からのドキュメントがエンコード(保護処理)されてそのeDocが作成された日時である。「処理装置ID」は、その保護処理を実行した処理装置の識別情報である。「暗号化情報」は、そのeDocの生成時の暗号化に関する情報であり、暗号化に用いた暗号化ソフト名、その暗号化ソフトのバージョン、及びその暗号化を解除(復号)するための鍵を表す鍵情報を含む。鍵情報は、例えば、復号のための鍵を各配信先ユーザの公開鍵で暗号化したものである。「キーワード情報」は、そのeDoc(又は元データ)から抽出したキーワードのリストである。このキーワード情報は、例えばeDocの検索の際に利用される。
【0060】
「配信先情報」は、配信者がそのeDocの配信先に指定したユーザ及び閲覧端末を表す情報である。図3の例では、配信先情報は、配信先のユーザ毎に、そのユーザのユーザIDとそのユーザが閲覧に用いるべき閲覧端末104のID(識別情報)とを含んでいる。そのユーザがそのeDocの閲覧に利用可能な閲覧端末104が複数指定された場合は、そのユーザのユーザIDとそれら複数の閲覧端末104のIDとの組が配信先情報に組み込まれる。
【0061】
また別の例として、配信先ユーザは配信先に指定された閲覧端末104のうちのいずれを利用してもそのeDocを閲覧可能とする方式を採用した場合、配信先情報には、配信先ユーザのIDのリストと、配信先の閲覧端末104のIDのリストが含まれる。例えば、配信先の閲覧端末104の候補として、部署の共用端末や、部署の居室や会議室に備え付けられた端末等が想定される場合がある。共用端末や居室等の備え付け端末(これも共用端末の一種)等は、組織内のユーザのだれが使うか決まっていないが、少なくともどのような端末であるかは配信者には分かっており、また勝手に組織外に持ち出される可能性が低いことも分かっているので、機密対象のドキュメントの配信先として適格である。このように素性の分かった共用端末でeDocを利用する場合には、このように配信先ユーザは配信先に指定された閲覧端末104のうちのどれを利用してもよい、という利用形態も考えられる。
【0062】
「アクセス権限情報」は、配信者が配信先のユーザに対して付与したそのeDocに対する利用権限を表す情報である。
【0063】
「オフライン有効期間」は、そのメタデータの有効期間の長さを表す情報である。すなわち、閲覧端末104が管理システム200にアクセスできない状態(オフライン状態)にあるときでも、そのeDocの前回の閲覧時に取得してキャッシュしているメタデータが存在し、そのメタデータの取得日時からその「オフライン有効期間」内であれば、閲覧端末104はそのメタデータ内の暗号鍵情報を用いてそのeDocを復号して表示する。一方、オフライン状態であり、閲覧を指示されたeDocについてのキャッシュしたメタデータのオフライン有効期間が既に過ぎている場合は、閲覧端末104は、そのeDocを復号せず、したがって表示も行わない。なお、閲覧端末104は、管理システム200にアクセス可能(すなわちオンライン状態)である間は、ユーザがeDocの閲覧を指示した場合、そのeDocの最新のメタデータを管理システム200(特にメタデータサーバ230)から取得して使用する。
【0064】
「元データ情報」は、eDocが生成(エンコード)される前の元データが保存されているか否かを示す情報と、保存されている場合はその元データの保存場所を示す情報(例えばURL:Uniform Resource Locator)である。ここでの元データは、例えば作成端末102から処理装置110に送られたドキュメント(保護処理を施す前のもの)、又はそのドキュメントの元になったアプリケーションデータ(例えばドキュメントがページ記述言語データである場合、そのデータに変換する前のワープロソフトのデータ)、又はそれらの両方である。
【0065】
「ドキュメント取得日時」は、閲覧端末104がそのeDocの本体データのファイル(すなわちeDocファイル)を取得した日時である。「メタデータ取得日時」は、閲覧端末104がそのeDocの現在キャッシュしている最新のメタデータを管理システム200から取得した日時である。ドキュメント取得日時及びメタデータ取得日時は、管理システム200に保持されているメタデータには含まれず、閲覧端末104が管理システム200から取得したメタデータに対して自機での管理のために追加する。
【0066】
また図3に示したメタデータの項目のうち、DID、エンコード日時、処理装置ID、暗号化情報、キーワード情報は、処理装置110が生成する情報である。また、ドキュメント名、配信者ID、配信先情報、アクセス権限情報、オフライン有効期間、元データ情報は、作成端末102から処理装置110に送られるドキュメントや属性データに由来する。
【0067】
次に、管理システム200の各サーバ210〜250が管理する情報のデータ内容を例示する。
【0068】
まず図4を参照して、ユーザIDサーバ210が管理するデータ内容の例を説明する。ユーザIDサーバ210には、各契約者の契約者データ212と、各一般ユーザのユーザデータ214が登録されている。
【0069】
契約者データ212には、契約者ID、契約内容情報、及びユーザリストが含まれる。契約者IDは、ドキュメント管理システムの運営者と契約した契約者(例えば組織や組織内の部署)の識別情報である。ユーザリストは、その契約者の契約によってこのドキュメント管理システムを利用する一般ユーザ(例えば契約者である組織に所属するメンバ)のユーザIDのリストである。
【0070】
一般ユーザデータ214には、その一般ユーザのユーザID、パスワード、ユーザIDキー情報、公開鍵証明書、既定の処理装置ID、既定の閲覧端末リスト、所属情報を含む。ユーザIDキー情報は、そのユーザの認証デバイス130が用いるそのユーザの認証情報である。公開鍵証明書は、そのユーザの公開鍵を証明するデジタル証明書である。既定の処理装置IDは、そのユーザが登録された処理装置110のIDである。通常、ユーザは自分が所属するオフィスに置かれた処理装置110に登録され、その処理装置110がそのユーザにとっての既定の処理装置となる。既定の閲覧端末リストは、そのユーザが主として使用する1以上の閲覧端末のIDのリストである。このリストに含まれる閲覧端末が、そのユーザに対してeDocを配信する際の配信先の端末の候補となる。所属情報は、そのユーザが所属する組織やその部署等を特定する情報であり、例えばその組織や部署の契約者IDである。
【0071】
次に図5を参照して、DIDサーバ220が管理するデータ内容の例を示す。
【0072】
DIDサーバ220は、図5に示すように、処理装置に対して発行した発行権限キー毎に、発行枠、付与先処理装置、キー付与日時、キー終了日時、発行済DIDリストの各項目の情報を保持している。
【0073】
発行権限キーは、DIDサーバ220が処理装置110に対して付与した、DIDの発行権限を証明するキー情報(例えばランダムに生成した文字列)である。処理装置110は、自らが発行するDIDに、DIDサーバ220から付与された発行権限キーを含めることで、そのDIDが正当な発行権限の下で発行したものであることを証する。
【0074】
発行枠は、その発行権限キーと共に処理装置110に付与したDID発行上限数(DIDを付与可能な上限のドキュメント数)である。処理装置110は、発行権限キーと発行枠のペアをDIDサーバ220から付与されると、その発行枠が示す上限数までのeDocに対して、それぞれ固有のDIDを付与することができる。
【0075】
付与先処理装置は、その発行権限キー(及び発行枠)の付与先の処理装置110のIDを示す。キー付与日時は、その発行権限キーを処理装置110に付与した日時である。キー終了日時は、付与先の処理装置110がその発行権限キーを使い終わった日時である。すなわち、処理装置110がその発行権限キーと共に付与された発行枠が示す上限数のeDocに対するDIDの付与をし終えた日時である。なお、処理装置110が発行枠を使い切った後に次の発行権限キーと発行枠をDIDサーバ220に要求する仕組みを採用している場合、ある発行権限キー(第1のキーと呼ぶ)のキー終了日時を明示的に記録する代わりに、当該発行権限キーの次に処理装置110が付与された発行権限キーのキー付与日時を、第1のキーのキー終了日時として用いてもよい。発行済DIDリストは、付与先の処理装置110がその発行権限キーを用いて発行したDIDとその発行年月日のリストである。付与先の処理装置110は、発行権限キーを用いてDIDを発行する毎にそのDIDをDIDサーバ220に通知し、DIDサーバ220は通知されたDIDとその発行年月日を、そのDIDに含まれる発行権限キーに対応する発行済DIDリストに追加する。
【0076】
メタデータサーバ230は、各処理装置110から送られてくる各eDocのメタデータを保管する。保管するメタデータのデータ内容は、図3に例示したものと同様である。ただし、図3に例示したメタデータの項目のうち、閲覧端末104のみで用いる項目(ドキュメント取得日時やメタデータ取得日時等)については、メタデータサーバ230では管理しない。
【0077】
次に図6を参照して処理装置管理サーバ240が管理するデータについて説明する。処理装置管理サーバ240は、管理対象の処理装置110毎に、その処理装置110のステータス履歴242を記憶している。ステータス履歴には、その処理装置110のIDに対応付けて、作成及び個々の更新の時点(作成・更新日時)でのその処理装置110のステータス244の情報が含まれる。
【0078】
個々の時点でのステータス244には、設置場所、契約者ID、管理者名、管理者連絡先、登録ユーザリスト、ソフトウエア情報246、ハードウエア情報248、ディスク空き容量、セキュリティ証明書情報が含まれる。設置場所は、その処理装置110の設置場所を示す情報であり、例えば住所や建物名、階数などの情報を含む。契約者IDは、その処理装置110を使用している契約者のIDである。管理者名は、その処理装置110の管理者の名前である。管理者は、処理装置110の設置先の部署等においてその処理装置110を管理しているユーザである。管理者連絡先は、その管理者の連絡先の情報(例えば電子メールアドレス)である。登録ユーザリストは、その処理装置110に登録されたユーザ(言い換えればその処理装置110を「既定の処理装置」とするユーザ)のユーザIDのリストである。
【0079】
ソフトウエア情報246には、エンコードソフト名、エンコードソフトバージョン、暗号化ソフト名、暗号化ソフトバージョン、処理装置110にインストールされているその他のソフトウエアの名称及びバージョンが含まれる。ここでエンコードソフトは、作成端末102から入力されたドキュメントを、ドキュメント管理システムの専用フォーマットへと変換(エンコード)するソフトウエアである。暗号化ソフトは、ドキュメント(例えば専用フォーマットに変換されたもの)を暗号化するソフトウエアである。
【0080】
ハードウエア情報248には、エンコード回路情報、エンコード回路FWバージョン、当該処理装置110の製造者名等の項目が含まれる。エンコード回路情報は、エンコード処理に用いるハードウエア回路の機種を示す情報である。エンコード回路FWバージョンは、そのエンコード回路のファームウェア(FW)のバージョンである。
【0081】
ディスク空き容量は、処理装置110が持つハードディスク又はソリッドステートディスク等の二次記憶装置の、その時点での空き容量である。
【0082】
セキュリティ証明書情報は、処理装置110にその時点でインストールされている各セキュリティ証明書を特定する情報(例えば証明書のサブジェクト(subject:主体者)識別子、イシュア(issuer:発行者)識別子、発行日時等の情報)である。
【0083】
また煩雑さを避けるために図示は省略したが、ステータス244には、処理装置110にインストールされているフォントの種類(フォント名のリスト)、ネットワーク通信のためのアドレス(例えばIPアドレス)、搭載している二次記憶装置(ハードディスクドライブ等)の装置ID、処理装置110を設置先の組織の基幹システムの処理に繋ぐためのカスタマイズ内容を示す情報、処理装置110が用いる暗号鍵(通信路暗号化や署名等のためのもの)のインストール日時等が含まれる。
【0084】
次に図7を参照して、処理装置110が保持するデータベース群について説明する。図示のように、処理装置110は、管理情報記憶部112、ユーザDB114及びドキュメントDB116を含む。
【0085】
管理情報記憶部112には、管理情報112aが記憶される。管理情報112aには、上位装置アドレス情報、セキュリティ証明書、暗号鍵、エンコードソフト名、エンコードソフトバージョン、暗号化ソフト名、暗号化ソフトバージョン等の項目が含まれる。上位装置アドレス情報は、処理装置110を管理する上位装置のそれぞれの通信アドレス(例えばIPアドレス、URL等)の情報である。管理システム200やその中の各サーバ210〜240、又は後述する組織内管理システム150やその中の各サーバ152〜156が上位装置の例である。セキュリティ証明書は、処理装置110がネットワーク上の他の装置と公開鍵基盤準拠のセキュアな通信を行う際に用いるデジタル証明書である。処理装置110は、よく通信する相手である各上位装置のセキュリティ証明書を保持している。また作成端末102や閲覧端末104を使用する各ユーザのセキュリティ証明を保持してもよい。暗号鍵は、処理装置110がネットワーク上の他の装置と通信を行う際の暗号化や復号、処理装置110によるデジタル署名(又はそれに類する証明情報の生成)等の目的に用いる、当該処理装置110の暗号鍵であり、例えば公開鍵基盤においてその処理装置110に対して付与された秘密鍵と公開鍵のペアである。エンコードソフト及び暗号化ソフトは、それぞれ、この処理装置110にインストールされているエンコード(専用フォーマットへの変換)及び暗号化のためのソフトウエアである。
【0086】
ユーザDB114には、この処理装置110に登録されている各ユーザ(言い換えればこの処理装置110を「既定の処理装置」とするユーザ)のユーザ情報114aが記憶されている。個々の登録ユーザのユーザ情報114aには、ユーザID、パスワード、ユーザIDキー情報、公開鍵情報、既定の閲覧端末リスト等の項目が含まれる。これらの項目については、上述のユーザIDサーバ210が持つデータの説明(図4参照)で説明した。
【0087】
ドキュメントDB116には、処理装置110が生成したeDocファイルと、そのeDocファイルに対応するメタデータとが保存される。eDocファイルとメタデータとはDIDの情報を含んでいるので、対応付けが可能である。またドキュメントDB116には、eDocにエンコードする前の元のデータ(作成端末102から受け取ったもの)を、そのeDocのDIDに対応付けて登録してもよい。
【0088】
作成端末102及び閲覧端末104は、当該端末を利用するユーザ毎に、そのユーザの認証情報(ユーザID、パスワード等)、既定の処理装置のID、既定の処理装置のアドレス情報、上位装置(例えば管理システム200や後述の組織内管理システム150)のアドレス情報、処理装置や上位装置のセキュリティ証明書、通信路暗号化等に用いる暗号鍵等を記憶している。
【0089】
<システムの処理の流れ>
ローカルネットワーク108上に処理装置110を設置した場合、処理装置110の保守を行う保守作業員は、処理装置110に対して、その処理装置110を利用するユーザの情報や、それらユーザが利用する可能性のある作成端末102や閲覧端末104の情報を登録する。登録されたユーザの情報は、上位装置であるユーザIDサーバ210(あるいは後述のローカルユーザIDサーバ152)にも転送され、登録される。なお、設置後、処理装置110を利用するユーザが増えたり減ったりした場合には、保守作業員は、処理装置110に対して増えたユーザの情報を新たに追加登録したり、減ったユーザの情報の登録を削除したりする作業を行う。このような追加や削除は、ユーザIDサーバ210等の上位装置にも通知され、これに応じ上位装置の保持する情報が更新される。また保守作業員は、それら各作成端末102に対して、処理装置110にドキュメントの登録及び配信を依頼する処理を行うソフトウエア(例えば処理装置110のデバイスドライバの形態をとる)をインストールする。また、保守作業員は、各閲覧端末104に対して、処理装置110と通信するための情報(例えば装置名、通信アドレス、無線アクセス設定)等を登録する。
【0090】
次に図8を参照して、本実施形態のドキュメント管理システムを経由してドキュメントが登録及び配信される際の処理の流れを説明する。
【0091】
(1)−1: ユーザ(配信者)が作成端末102に対してドキュメントの登録の指示を行うと、作成端末102は、ログイン認証情報(例えばユーザID及びパスワード、又は認証デバイス130)の入力を求める画面を表示する。配信者がその求めに応じて認証情報を入力すると、作成端末102は、その認証情報をローカルネットワーク108経由で処理装置110に送信する。
【0092】
(1)−2: ログイン認証情報を受け取った処理装置110はその情報を用いてユーザ認証を行う。ここではそのユーザ認証が成功した(正しいユーザと確認できた)とする。図示例では、ログインIDとパスワードを用いてログイン認証を行っているが、作成端末102が認証デバイス130との通信に対応している場合は認証デバイス130を用いてログイン認証を行ってもよい。
【0093】
(2)−1: ログイン認証が成功すると、ユーザは、作成端末102に保持されたドキュメントの中からドキュメント管理システムに登録したい(そして他のユーザに配信したい)ドキュメントを選択し、処理装置110への登録を指示する。すると、処理装置110とのインタフェースとなるソフト(例えばデバイスドライバ)が起動し、ユーザからそのドキュメントについての属性データの入力を受け付け、受け付けた属性データとそのドキュメントのデータを処理装置110に送信する。
【0094】
図9に、この属性データの入力画面400の一例を示す。この入力画面400は、配信先ユーザ選択メニュー402、配信先ユーザリスト欄404、配信先端末選択メニュー406、配信先端末リスト欄408、アクセス権限設定欄410、オフライン有効期間メニュー412、及びオプション設定呼出ボタン414を含む。
【0095】
配信先ユーザ選択メニュー402は、そのドキュメントの配信先ユーザの選択肢を列挙するプルダウン形式のメニューである。選択肢となるユーザは処理装置110に登録されたユーザであり、選択肢となるそれらユーザのID及びユーザ名のリストは処理装置110から取得すればよい。あるいは、作成端末102が、組織に所属するドキュメント管理システムのユーザの情報を管理する後述のローカルユーザIDサーバ152(図12参照)からユーザのリストを取得し、配信者が、組織内の他の処理装置110に登録されたユーザを配信先に選択できるようにしてもよい。この場合、配信先ユーザ選択メニュー402では、各ユーザを、各々が登録された処理装置110が区別可能な表示形態で表示する。例えば、ユーザを、そのユーザが登録された処理装置110毎に異なる色や字体で表示してもよい。あるいはそのメニューを階層構造とし、まず処理装置110を選んでその処理装置110に登録されたユーザのリストを呼び出し、そのリストの中から配信先のユーザを選ぶ態様としてもよい。配信先ユーザリスト欄404には、ユーザが選んだ配信先ユーザのリストが表示される。配信者が配信先ユーザ選択メニュー402で配信先ユーザを選び、右側にある「追加」ボタンを押下すると、その配信先ユーザのユーザID又はユーザ名が配信先ユーザリスト欄404に追加される。また、配信者が配信先ユーザリスト欄404内の配信先ユーザを選び、右側の「削除」ボタンを押下すると、その配信先ユーザが配信先ユーザリスト欄404から削除される(すなわち配信先ではなくなる)。
【0096】
配信先端末選択メニュー406は、そのドキュメントの配信先とする閲覧端末(ビューワ)104の選択肢を列挙するプルダウン形式のメニューである。選択肢となる閲覧端末104は処理装置110に登録されたものであり、選択肢となるそれら閲覧端末104のID及び端末名のリストは処理装置110から取得すればよい。あるいは、処理装置110自身やローカルユーザIDサーバ152(図12参照。詳細は後述)等がドキュメント管理システムに登録された組織内の閲覧端末104のリストを有しており、作成端末102が、そのリストを配信者に提示して、組織内の他の処理装置110に登録されたユーザの閲覧端末104を配信先に選択できるようにしてもよい。配信先ユーザリスト欄404には、配信先ユーザリスト欄404の場合と同様、配信者が配信先端末選択メニュー406で選んだ配信先の閲覧端末104のリストが表示される。
【0097】
なお、配信先のユーザ毎にそのユーザに対応する配信先の閲覧端末104を指定できるようにしてもよい。これには作成端末102は、例えば、配信先ユーザリスト欄404で配信先のユーザが選択される毎に、処理装置110(あるいはローカルユーザIDサーバ152又はユーザIDサーバ210)からそのユーザの既定の閲覧端末のリストを取得し、そのリストを配信先端末選択メニュー406に設定すればよい。配信者が配信先のユーザに対する配信先の閲覧端末104を明示的に選択しなかった場合は、そのユーザの既定の閲覧端末のリスト中の特定のもの(例えばリストの先頭)が自動的に配信先の閲覧端末104に選択される。
【0098】
アクセス権限設定欄410は、そのドキュメントに対する配信先ユーザのアクセス権限(利用権限)を設定するための欄である。図示例では、閲覧、加工(編集)、印刷、コピーの4つの権限項目についてのチェックボックスが示されており、配信者は、そのドキュメントについて配信先ユーザに許可する項目のチェックボックスにチェックを入れる。
【0099】
オフライン有効期間メニュー412は、ドキュメントに対して設定するオフライン有効期間の長さの選択肢を示すプルダウンメニューである。配信者は、オフライン有効期間メニュー412に示される数段階のオフライン有効期間の中から、今回システムに登録して配信するドキュメントに対して設定する期間を選ぶ。
【0100】
またオプション設定呼出ボタン414が押下されると、作成端末102は、図10に例示するオプション設定画面420を表示する。オプション設定画面420は、処理装置指定欄422と元データ設定欄424を含む。処理装置指定欄422には、ドキュメントの送信先とする処理装置110の選択肢を示したプルダウンメニューが含まれる。このメニューには、作成端末102から選択可能な処理装置110のリストが含まれる。このリストに含まれる処理装置110は、まずその作成端末102が属するローカルシステム100内にある処理装置110(基本は1つだが、複数あってもよい)である。また、同じ組織内の別のローカルシステム100の処理装置110がそのリストに含まれていてもよい。元データ設定欄424には、eDocの元になった元データを処理装置110に保存するかの選択を受け付けるプルダウンメニューが表示される。
【0101】
ステップ(2)−1で作成端末102から処理装置110に送られる属性データには、このような設定画面により設定された、配信先情報(ユーザのリスト及び閲覧端末のリスト)、アクセス権限情報、オフライン有効期間、元データ情報等の情報が含まれる。
【0102】
図8の説明に戻る。
【0103】
(2)−2: 処理装置110は、作成端末102からドキュメント(対象ドキュメントと呼ぶ)及び属性データを受信する。
【0104】
(3)−1: 処理装置110は、DIDの発行権限及び発行枠を受け取っていない場合(あるいは受け取った発行枠を使い切った場合)は、管理システム200のDIDサーバ220に対して新たな発行権限及び発行枠を要求する。なお、受け取った発行枠に残りがある場合には、この要求を行わずに後述のステップ(4)に進む。
【0105】
(3)−2: DIDサーバ220は、処理装置110からの要求に応じ、新たな発行権限及び発行枠をその処理装置110に送信する。
【0106】
(4) 処理装置110は、DIDサーバ220から付与された発行権限を用いてDIDを発行し、そのDIDを対象ドキュメントから生成するeDoc(次のステップで生成する)に付与する。
【0107】
(5)−1: 処理装置110は、対象ドキュメントを暗号化するための暗号鍵を例えば乱数等を用いて生成する。また処理装置110は、対象ドキュメントをeDocファイルへ変換する。すなわち、その対象ドキュメントをドキュメント管理システムの専用フォーマットへとエンコードし、エンコード結果を先ほど生成した暗号鍵で暗号化することでeDocファイルを生成する。生成したeDocファイルには先ほど生成したDIDの情報を含める。
【0108】
(5)−2: 処理装置110は、生成したeDocのメタデータを生成する。すなわち、作成端末102から受信した属性データに対して、先ほど生成したDID、エンコードの日時、当該処理装置110のID、暗号化情報等を追加することでメタデータを生成する(図3参照)。ここで、暗号化情報には、配信先ユーザのそれぞれについて、暗号化に用いた暗号鍵をその配信先ユーザの公開鍵で暗号化した鍵情報が含まれる。
【0109】
(5)−3: 作成端末102から元データを保管する旨の指示を受け取った場合は、処理装置110は、作成端末102から受信したドキュメント(又はそのドキュメントの元になったアプリケーションデータ)を保存する。
【0110】
(6)−1: 処理装置110は、先ほど生成したDIDをDIDサーバ220にアップロードする。DIDサーバ220は、処理装置110からアップロードされたDIDを保管する。
【0111】
(6)−2: 処理装置110は、先ほど生成したメタデータをメタデータサーバ230にアップロードする。メタデータサーバ230は、処理装置110からアップロードされてきたメタデータを保管する。
【0112】
(7) 処理装置110は、生成したeDocの配信先の各閲覧端末104に対して、そのeDocについての配信準備完了通知を送信する。この通知には、先ほど生成したDID、eDocのドキュメント名の情報を含む。また、この通知は、eDocの代表ページ(先頭ページ等の予め指定されたページ)のサムネイル画像を含んでいてもよい。
【0113】
さて、閲覧端末104を利用するユーザ(閲覧者と呼ぶ)は、自分の認証デバイス130を閲覧端末104のカードリーダ部に近づけることで、ユーザ認証を受ける。閲覧端末104は、自身に配信されているeDocのリストを表示するリスト画面を表示する。図11にこのリスト画面500の例を示す。この例のリスト画面500には、eDoc毎に、通知マーク502、そのeDocのドキュメント名504、閲覧可否マーク506が含まれる。通知マーク502は、そのeDocの状態を閲覧者に通知するためのマークである。通知マーク502が表すeDocの状態には、「新着」(処理装置110からドキュメントが配信された後、まだ開かれていない状態。図では「☆」印で示す)、「正常」(図では無印)、「期限切れ」(アクセス有効期間が過ぎている状態。図では「!」印で示す)等がある。「期限切れ」状態については、閲覧端末104内にeDocファイルが保存されていても、そのeDocについての最新のメタデータを処理装置110又は管理システム200から取得するまでは、閲覧できない。「正常」状態のeDocについては、その閲覧端末104内には、アクセス有効期間が切れていないメタデータが保存(キャッシュ)されているので、仮に閲覧端末104が処理装置110や管理システム200に対してオフライン状態となっていても閲覧可能である。閲覧可否マーク506は、閲覧端末104及びこれを使用しているユーザ(認証デバイス130により認証)の組合せが、当該閲覧端末104にキャッシュされたそのeDocのメタデータに示されるそのeDocの配信先のユーザ及び閲覧端末104の組合せに合致するか否かを示す。合致すればそのeDocは閲覧可能(図では「○」印)、合致しなければ閲覧不可(図では「×」印)である。また、配信準備完了通知は受け取ったがまだeDocファイル及びメタデータを受信していないeDocについては、閲覧端末104は配信先の組合せに合致するか否かの判断基準の情報を持たないので、閲覧可否マーク506は、未定であることを示す「−」印となる。図示例では、上から3つのeDocは、新着のものであり、まだeDoc本体(ファイル及びメタデータ)の取得が済んでいないので、閲覧可否マーク506は未定を表すマークとなっている。
【0114】
閲覧者は、このリスト画面(図11)上で、自分が閲覧したいeDocを例えばタッチ操作等で選択し、閲覧指示を行う。ここでは、新着(通知マーク502が「☆」印)のeDocが閲覧対象に選ばれたとする。
【0115】
(8) 図8の説明に戻る。閲覧端末104は、選ばれた閲覧対象のeDocファイル及びメタデータを保持していないので、処理装置110から取得する必要がある。そこで、閲覧端末104は、自身が接続されているローカルネットワーク108上の処理装置110に対して、その閲覧者の認証デバイス130から取得した認証情報であるユーザIDキーを自身が接続されているローカルネットワーク108上に処理装置110に対して送信する。処理装置110は、そのユーザIDキーが自身に登録されているユーザを証明するものであるか検証する(ユーザ認証)。ここでは、そのユーザ認証が成功したとする。なお、閲覧端末104から受信したユーザIDキーが処理装置110に登録されたいずれのユーザにも該当しなかった場合、処理装置110は、そのユーザIDキーをユーザ認証に関する上位装置(ユーザIDサーバ210又はローカルユーザIDサーバ152)に送り、ユーザ認証を依頼してもよい。
【0116】
(9)−1: また閲覧端末104は、処理装置110でのユーザ認証が成功したのを受けて、閲覧者が選択した閲覧対象のeDocのDIDを含む配信要求を処理装置110に送る。
【0117】
(9)−2: 処理装置110は、閲覧端末104からの配信要求に含まれるDIDに対応するeDocファイル及びメタデータを、閲覧端末104に返信する。
【0118】
(10) 閲覧端末104は、処理装置110から送られてきたeDocファイル及びメタデータを受信して保存(キャッシュ)する。
【0119】
(11) 閲覧端末104は、自身と、自身を現在使用中の閲覧者との組合せと一致する組合せが、そのメタデータ中の配信先情報(図3参照)に示される配信先ユーザと配信先端末の組合せの中にあるかどうかを判定する。ないと判定した場合は、閲覧者はその閲覧端末104ではそのeDocファイルを閲覧できない。この場合、閲覧端末104は、閲覧できない旨を示すエラーメッセージを表示する。またこの場合、閲覧端末104は、保存しているそのeDocファイル(及び対応するメタデータ)を削除してもよい。一方、閲覧端末104とそれを現在使用中の閲覧者との組合せに該当するものがメタデータ中の配信者情報内にあると判定した場合、閲覧端末104は、閲覧者に対してeDocの閲覧を許可する。この場合、閲覧端末104は、そのメタデータ内の暗号化情報に含まれる各配信先ユーザに対応する暗号化済みの鍵の中から閲覧者に対応するものを取り出し、その鍵を閲覧者の秘密鍵(これは例えば認証デバイス130が保持している)で復号することで、eDocファイルの復号に必要な復号鍵を復元する。
【0120】
(12) 閲覧端末104は、復元した復号鍵を用いてそのeDocファイルを復号することで閲覧可能なドキュメントを再生し、そのドキュメントを出力(例えば画面表示)する。また、閲覧端末104は、閲覧者からそのドキュメントに対する操作指示を受け付けるかどうかを、メタデータに含まれるアクセス権限情報に従って制御する。閲覧端末104は、基本的には、復号したドキュメントをファイルに保存することはしない。すなわち、閲覧終了後は、閲覧端末104の不揮発性記憶装置には、eDocファイルとメタデータが保存されるが、復号結果のドキュメントは保存されない。
【0121】
次に、図12を参照して、本実施形態のドキュメント管理システムの別の例を説明する。図12に示す例では、企業等の組織のプライベートネットワークである組織内ネットワーク内にローカルシステム100が複数存在する。そして、組織内ネットワークには、組織内管理システム150が設けられている。組織内管理システム150は、ドキュメント管理システムのうち当該組織内の処理やそれに必要な情報を管理する。すなわち、管理システム200は、ドキュメント管理システムのサービスプロバイダが運用し、ドキュメント管理システムを利用する複数の組織についての情報や処理を管理するのに対し、組織内管理システム150はそれら情報や処理のうち当該組織に関する部分を、管理システム200の管理下で管理する。
【0122】
組織内管理システム150は、ローカルユーザIDサーバ152、ローカルDIDサーバ154、及びローカルメタデータサーバ156を有する。
【0123】
ローカルユーザIDサーバ152は、当該組織のメンバのうちドキュメント管理システムにユーザ登録されているユーザの情報を管理する。ローカルユーザIDサーバ152が保持する個々のユーザの情報は、図4に記載したユーザIDサーバ210が保持する一般ユーザの情報と同様である。処理装置110に対して、その処理装置110を取得し利用するユーザ(すなわちその処理装置110を「既定の処理装置」とするユーザ)が登録されると、処理装置110は登録されたユーザの情報を組織内のローカルユーザIDサーバ152に送る。ローカルユーザIDサーバ152は、受け取ったユーザの情報を保存すると共に、広域ネットワーク10経由で中央の管理システム200のユーザIDサーバ210に送る。ユーザIDサーバ210は、受け取ったユーザの情報を保管する。又、処理装置110に登録されたユーザの情報に変更が生じた場合、管理者等が処理装置110に対してそのユーザの情報の変更を行う。処理装置110は、このユーザ情報の変更内容の情報(例えばユーザIDと、変更された情報項目の項目名と、その項目の変更後の値とを含む)をローカルユーザIDサーバ152に送信し、ローカルユーザIDサーバ152は、受信した変更に内容に応じて自身が保管している当該ユーザの情報を変更する。また、ローカルユーザIDサーバ152は、受け取った変更内容の情報を中央のユーザIDサーバ210に送り、ユーザIDサーバ210は送られてきた情報に応じて、自分が保持するそのユーザの情報を変更する。
【0124】
ローカルDIDサーバ154は、当該組織の組織内ネットワークに属する各ローカルシステム100内の処理装置110が発行したDIDを受け取り、保管する。ローカルDIDサーバ154が保持する情報は、図5に記載したDIDサーバ220が保持する情報と同様である。またローカルDIDサーバ154は、処理装置110から受け取ったDIDの情報を中央のDIDサーバ220に送り、DIDサーバ220はその情報を保管する。また、ローカルDIDサーバ154は、中央のDIDサーバ220からDIDの発行権限及び発行枠を付与され、その発行枠の範囲内で、その発行権限に基づいて管理下の各処理装置110に対してDIDの発行権限及び発行枠を付与する。
【0125】
ローカルメタデータサーバ156は、当該組織の組織内ネットワークに属する各ローカルシステム100内の処理装置110が生成したeDocのメタデータを受け取り、保管する。ローカルメタデータサーバ156が保持する情報は、メタデータサーバ230が保持する情報と同様である。またローカルメタデータサーバ156は、処理装置110から受け取ったメタデータを中央のメタデータサーバ230に送り、メタデータサーバ230はそのメタデータを保管する。
【0126】
図12のシステムでは、処理装置110は、自分には登録されていないが同じ組織内の他の処理装置110に登録されているユーザからのドキュメントの登録(及び配信)要求、又はeDocファイル又はメタデータの取得要求等の要求を受けた場合、組織内管理システム150を介してそれら要求に応答する。
【0127】
1つの例として、組織内ネットワーク内の第1の部署にある第1のローカルシステム100内の処理装置#1に登録されている閲覧者が、その処理装置#1に登録され配信されたeDocを自分の閲覧端末104に保存し、その後処理装置#2の管理下にある第2の部署に移動してそのeDocを閲覧しようとしたときのことを考える。この時点では、その閲覧端末104内に保存されたそのeDocのメタデータは古くなっている(すなわちアクセス有効期間が過ぎている)ものとする。この場合、閲覧者がその閲覧端末104でそのeDocを開く操作を行った場合、図13に示す処理が行われる。
【0128】
まず、閲覧端末104は、自身が今接続している第2のローカルシステム100のローカルネットワーク108から処理装置110を探す。これにより処理装置#2が見つかる。この処理装置#2は、そのeDocを配信した処理装置#1とは別の装置なので、そのeDocファイルやメタデータは持っていない。
【0129】
(1) 閲覧端末104は、閲覧者の認証デバイス130からユーザIDキー(認証情報)を読み込む。
【0130】
(2) 閲覧端末104は、閲覧の対象として指示されたそのeDocの最新のメタデータを取得するためのユーザ認証のために、その処理装置#2に対して、認証デバイス130から取得したユーザIDキーを送信する。
【0131】
(3) 閲覧端末104は、そのeDocのメタデータを処理装置#2に要求する。この要求には、そのeDocのDIDが含まれる。
【0132】
(4)−1: 処理装置#2は、閲覧端末104から受け取ったユーザIDキーが自身に登録されたユーザのものかどうかを調べる(ユーザ認証)。この例では、その閲覧者は処理装置#1に登録されており、処理装置#2には登録されていないので、処理装置#2は、予め設定されているローカルユーザIDサーバ152のアドレスに対して、そのユーザIDキーを含む認証要求を送る。また、処理装置#2は、閲覧端末104からのメタデータ要求に含まれるDIDを、予め設定されているローカルDIDサーバ154に送り、認証を求める。
【0133】
(4)−2: ローカルユーザIDサーバ152は、処理装置#2から受け取ったユーザIDキーが、自身に登録されているユーザのものであるかどうかを検証する(ユーザ認証)。そのユーザIDキーの持ち主である閲覧者は、処理装置#1に登録されているので、その上位装置であるローカルユーザIDサーバ152にもユーザ登録がなされている。したがって、このユーザ認証は成功する。ローカルユーザIDサーバ152は、認証が成功したことを示す応答を処理装置#2に返す。
【0134】
またローカルDIDサーバ154は、閲覧端末104から送られてきた検証対象のDIDが正当なDIDであるかどうか、すなわち自身が保存しているDIDであるかどうかを調べる。この例では、そのeDocのDIDは、処理装置#1が発行したものであり、処理装置#1のDIDに関する上位装置であるローカルDIDサーバ154にも保存されている。したがって、そのDIDは正当なものであると認証される。ローカルDIDサーバ154は、DIDが正当であると認証する旨の応答を処理装置#2に返す。
【0135】
(5)−1: ユーザ認証及びDID認証が成功したので、処理装置#2は、閲覧端末104からのメタデータ要求に応えるための処理を続行する。すなわち、処理装置#2は、DIDを含むメタデータ要求を、あらかじめ設定されているローカルメタデータサーバ156のアドレスに送る。
【0136】
(5)−2: ローカルメタデータサーバ156は、処理装置#2からメタデータ要求を受けると、その要求に含まれるDIDに対応するメタデータを処理装置#2に返す。eDocのメタデータは、配信者から処理装置110にて変更されると、その変更が即座にローカルメタデータサーバ156に反映されるので、このとき処理装置#2に返されるメタデータは、閲覧対象のeDocのメタデータの最新版である。
【0137】
(6) 処理装置#2は、ローカルメタデータサーバ156から受け取ったメタデータを、閲覧端末104に対して送信する。
【0138】
(7) 閲覧端末104は、処理装置#2からメタデータを受信し、保存(キャッシュ)する。
【0139】
(8) 閲覧端末104は、受け取った最新のメタデータの配信先情報を参照し、閲覧端末104及び閲覧者の組合せの権限チェックを行う。すなわち、閲覧端末104自身と閲覧者との組合せと一致する組合せが、その配信先情報(図3参照)に示される配信先ユーザと配信先端末の組合せの中にあれば、閲覧権限ありと判定し、なければ閲覧権限なしと判定する。閲覧権限なしと判定した場合、閲覧端末104はエラー表示を行う。閲覧権限ありと判定した場合、閲覧端末104は、そのメタデータ内の暗号化情報に含まれる各配信先ユーザに対応する暗号化済みの鍵の中から閲覧者に対応するものを取り出し、その鍵を閲覧者の秘密鍵(これは例えば認証デバイス130が保持している)で復号することで、eDocファイルの復号に必要な復号鍵を復元する。
【0140】
(9) そして閲覧端末104は、復元した復号鍵を用いてそのeDocファイルを復号することで閲覧可能なドキュメントを再生し、そのドキュメントを出力(例えば画面表示)する。そして、閲覧者からそのドキュメントに対する操作指示を受け付けるかどうかを、メタデータに含まれるアクセス権限情報に従って制御する。
【0141】
次に、図14を参照して、第1のローカルシステム100内の処理装置#1に登録されているユーザが、処理装置#2の管理下にある第2の部署でドキュメントをドキュメント管理システムに登録する場合の処理の流れを考える。そのユーザ(ドキュメントの配信者)は、処理装置#2には登録されていないとする。
【0142】
(1) ユーザは、自分の作成端末102にドキュメントの登録を指示すると、作成端末102はログイン認証情報の入力を求める画面を表示する。配信者がその求めに応じて認証情報(例えばユーザID及びパスワード)を入力すると、作成端末102は、その認証情報をローカルネットワーク108経由で処理装置110に送信する。
【0143】
(2) 処理装置#2は、作成端末102から受け取った認証情報が自身に登録されたユーザのものであるか判定する。この場合、配信者は処理装置#2に登録されていない。この場合、処理装置#2は、上位のローカルユーザIDサーバ152に対してその認証情報を送り、認証を求める。
【0144】
(3) ローカルユーザIDサーバ152は、受け取った認証情報が自身に登録されているユーザのものかどうか判定する(ユーザ認証)。この例では、配信者は処理装置#1に登録されているユーザなので、ローカルユーザIDサーバ152にも登録されており、このユーザ認証は成功する。ローカルユーザIDサーバ152は、処理装置#2に対して、ユーザ認証が成功したことを示す情報を返す。
【0145】
(4) 処理装置#2は、ローカルユーザIDサーバ152から認証成功の旨の応答を受けると、作成端末102に対してユーザ認証が成功した旨を応答する。
【0146】
(5) 作成端末102は、ユーザ認証が成功した場合、ユーザが登録対象に選択したドキュメントと、ユーザが入力した属性データとを処理装置#2に送る。
【0147】
(6) 処理装置#2は、作成端末102からドキュメント及び属性データを受信する。
【0148】
(7)−1: 処理装置#2は、DIDの発行権限及び発行枠を使い切った場合は、ローカルDIDサーバ154に対して新たな発行権限及び発行枠を要求する。なお、受け取った発行枠に残りがある場合には、この要求を行わずに後述のステップ(8)に進む。
【0149】
(7)−2: ローカルDIDサーバ154は、処理装置#2からの要求に応じ、新たな発行権限及び発行枠をその処理装置#2に付与する。なお、中央のDIDサーバ220から付与された発行枠を使い切った場合、ローカルDIDサーバ154は、DIDサーバ220に新たな発行権限及び発行枠を要求し、これに応じて付与された発行権限及び発行枠を用いて、処理装置#2にDIDの発行権及び発行枠を付与する。
【0150】
(8) 処理装置#2は、付与された発行権限を用いてDIDを発行し、そのDIDを対象ドキュメントから生成するeDoc(次のステップで生成する)に付与する。
【0151】
(9)−1: 処理装置#2は、対象ドキュメントを暗号化するための暗号鍵を生成し、対象ドキュメントを本システムの専用フォーマットへとエンコードし、エンコード結果を先ほど生成した暗号鍵で暗号化することでeDocファイルを生成する。
【0152】
(9)−2: 処理装置#2は、作成端末102から受信した属性データに対して、先ほど生成したDID、エンコードの日時等の項目を追加することで、eDocのメタデータを生成する。
【0153】
(10) 処理装置#2は、生成したDIDをローカルDIDサーバ154に、生成したメタデータをローカルメタデータサーバ156に、それぞれアップロードする。ローカルDIDサーバ154は、処理装置#2からアップロードされたDIDを、その中に含まれる発行権限キーに対応する発行済DIDリスト(図5参照)に追加すると共に、中央のDIDサーバ220にアップロードする。DIDサーバ220は、ローカルDIDサーバ154からアップロードされたDIDを、発行権限キーに対応する発行済DIDリスト(図5参照)に追加する。またローカルメタデータサーバ156は、処理装置#2からアップロードされたメタデータを保管すると共に、中央のメタデータサーバ230にアップロードする。メタデータサーバ230は、ローカルメタデータサーバ156からアップロードされたメタデータを保管する。
【0154】
処理装置#2は、生成したeDocを配信者の指定した配信先に配信する。この処理は、図8のステップ(7)乃至(12)と同様である。
【0155】
(11) また処理装置#2は、生成したeDocファイル及びメタデータを作成端末102に送信する。処理装置#2は、そのeDocファイル及びメタデータを保存してもよいし、保存せずに削除してもよい。保存せずに削除する場合、それらeDocファイル及びメタデータは、組織内の処理装置110群のうち、後述するステップ(13)により既定の処理装置である処理装置#1のみに保存されることになる。配信者の既定の処理装置でない処理装置110がその配信者から登録・配信依頼されたeDocファイル及びメタデータを保存するか否かは、処理装置110に設定可能としてもよい。
【0156】
(12) 作成端末102は、処理装置110から受け取ったeDocファイル及びメタデータを、後でその配信者の既定の処理装置である処理装置#1に転送するために保存する。
【0157】
(13) 配信者は、作成端末102を持って自分の所属する第1の部署に戻った際、作成端末102は、第1のローカルネットワーク108上でその配信者の既定の処理装置である処理装置#1を探す。処理装置#1を見つけると、作成端末102は、上記ステップ(12)で保存していたeDocファイル及びメタデータを処理装置#1に登録する。これにより、配信者は、メタデータの内容(例えば配信先)を変更したい場合には、既定の処理装置#1にアクセスしてその変更の操作を行えばよい。
【0158】
以上に説明した本実施形態のドキュメント管理システムでは、作成端末102から処理装置110に配信を指示したドキュメントの本体情報(すなわちeDocファイル)は、処理装置110と配信先の閲覧端末104が持つのみで、その他のネットワークや装置には出回らない。このためeDocファイルの漏洩リスクが極小化される。特にeDocファイルの配信先を、そのeDocを生成したローカルネットワーク108上の閲覧端末104に限定すれば、eDocはそのローカルネットワーク108から外に一切出ないことになる。
【0159】
一方、eDocのメタデータは、中央の管理システム200や組織毎の組織内管理システム150に登録されており、閲覧端末104がいろいろな場所に移動しても、広域ネットワーク10や組織のプライベートネットワークを介して入手可能となっている。閲覧端末104は、eDocの閲覧指示をユーザから受けた場合、そのeDocの最新のメタデータを組織内管理システム150又は中央の管理システム200から取得し、その最新のメタデータに含まれる配信先情報に基づき、そのユーザにそのeDocの閲覧を許可してよいかどうかを判定する。そのユーザが、そのeDocの登録・配信時には配信先に指定されていても、その後の配信先変更で配信先から外れている場合には、閲覧は許可されない。
【0160】
図13及び図14の例では、処理装置#1及び処理装置#2は共に同じ組織内に設置されたものであり、配信先のユーザもその組織に所属していると想定しているので、ユーザ認証はその組織のローカルユーザIDサーバ152で行った。これに対し、閲覧者が処理装置#2とは異なる組織に属するユーザの場合、処理装置#2でもその上位のローカルユーザIDサーバ152でもその配信者を認証できない。この場合、更に上位のユーザIDサーバ210がその配信者のユーザ認証を行ってもよい。
【0161】
図13及び図14の例では、別の処理装置#2が、処理装置#1に登録されたユーザの閲覧端末104と、ローカルユーザIDサーバ152やローカルメタデータサーバ156とのやりとりの仲立ちをした。しかし、これは一例に過ぎない。この代わりに、例えば、処理装置#2は、閲覧端末104から送られてきたユーザの認証情報からそのユーザが処理装置#2に登録されたものでない場合、閲覧端末104に対して認証不可の応答を行えばよい。この場合、閲覧端末104は、自機に登録されている上位装置のアドレス情報を用いて、ローカルユーザIDサーバ152に認証を求め、認証が成功すると、ローカルメタデータサーバ156にアクセスして必要なメタデータを取得する。
【0162】
図13の例は、ユーザは自分の所属する組織内の、自分の既定の処理装置とは別の処理装置110の管理下にあるローカルシステム100に移動してドキュメントの閲覧を行う場合の例であった。しかしながら、ユーザが、自分の所属する組織の外で、自分の既定の処理装置から配信されたドキュメントを閲覧できるようにしてもよい。この場合、ユーザの閲覧端末104は、中央の管理システム200内のユーザIDサーバ210で認証を受け、閲覧したいドキュメントのメタデータをメタデータサーバ230から取得する。
【0163】
<DIDの例>
次に、図15を参照して、ドキュメント管理システムでeDocの識別情報に用いるDID600の構成について説明する。
【0164】
図示のようにDID600は、発行権限キー602、処理装置固有情報604、発行年月日606、発行証明キー608、及び発行番号610を含む。なお、図示のDID600及びその構成要素602〜610の桁数はあくまで例示的なものにすぎない。
【0165】
発行権限キー602は、DIDサーバ220が処理装置110に付与した発行権限を識別するキー情報である。DIDサーバ220は、処理装置110から発行権限及び発行枠の要求を受けた場合、発行権限キー602を生成し、その発行権限キー602を発行枠(例えばドキュメント数100個)の数値と共に処理装置110に送信する。なお、DIDサーバ220と処理装置110との間にローカルDIDサーバ154が介在するシステム構成の場合には、DIDサーバ220がローカルDIDサーバ154に対して、例えば、発行権限キーと発行枠の組を複数組一括して付与する。この付与は、DIDサーバ220が、それら複数組の発行権限キー及び発行枠を処理装置110に付与する処理をローカルDIDサーバ154に依頼することと捉えてもよい。ローカルDIDサーバ154は、管理下の処理装置110から発行権限を要求された場合、付与された複数組の発行権限キー及び発行枠の中の未付与のものをその処理装置110に付与すればよい。
【0166】
処理装置固有情報604は、そのDIDを発行した処理装置110に固有な情報である。すなわち、DID600中の処理装置固有情報604を調べることで、そのDID600を発行した処理装置110が一意に特定できる。処理装置固有情報604は、処理装置110が保持している。
【0167】
発行年月日606は、そのDIDを発行した年月日を示す文字列である。DIDの発行年月日は、そのDIDの付与先であるeDocを生成(エンコード)した年月日でもある。
【0168】
発行証明キー608は、その処理装置110(処理装置固有情報604により特定される)が、発行権限キー602が示す発行権限を用いてそのDIDを発行したことを証明するキー情報である。発行証明キー608は、例えば、発行権限キー602をその処理装置110の秘密鍵で暗号化することで得られる値である。この場合、発行証明キー608をその処理装置110の公開鍵で復号して得られた値が、発行権限キー602に一致すれば、そのDID600は、その発行権限キー602を用いてその処理装置110が発行したものであることが証明される。また、DID600のうち発行権限キー602を除く部分の値(又はその値から生成した所定桁数のハッシュ値)を処理装置110の秘密鍵で暗号化して得た値を発行証明キー608としてもよい。この場合、発行証明キー608を処理装置110の公開鍵で復号した値が、DID600の発行証明キー608を除いた部分の値と矛盾しなければ(例えば復号結果がその値のハッシュ値と一致)、そのDID600は発行権限キー602に基づきその処理装置110が発行したものであり、DID600の発行証明キー608以外の部分に改ざんがないことが証明される。
【0169】
発行番号610は、そのDID600が、処理装置110がその発行権限キー602を用いて発行した何番目のDIDであるかを示す通し番号である。ある発行権限キー602を用いて生成されたDID600の発行番号610が取り得る最大値は、その発行権限キー602と共にDIDサーバ220(又はローカルDIDサーバ154)が付与した発行枠の値(ドキュメント数)である。
【0170】
<登録後の配信先変更>
さて、eDocをドキュメント管理システムに登録した後、配信者(あるいは配信先の変更権限を与えられた他の者)が、配信先の削除や追加、それら配信先に与えたeDocへのアクセス権限を修正したくなることも考えられる。そのような場合、配信者は、作成端末102又は閲覧端末104(以下ユーザ端末と総称)を用いて例えば既定の処理装置110にアクセスし、対象となるeDocのDIDを指定して、配信先(又はアクセス権限)の編集処理の実行を指示する。
【0171】
この指示を受けた処理装置110は、ユーザ認証によりその指示を発したユーザがその対象eDocの正しい配信者等(配信者及び配信先変更権限を与えられた他の者の総称)であることを確認した場合、配信先及びアクセス権限の編集画面をユーザ端末に提供する。編集画面は、図9に示した入力画面400と同様のものでよい。配信者等は、その編集画面上で、配信先のユーザ及び閲覧端末の追加や削除、アクセス権限内容の変更を行う。配信者等が、編集画面上で必要な変更を行った後、その変更を確定する操作を行うと、処理装置110は、保存しているそのeDocのメタデータにその変更を反映させると共に、その変更内容を上位のローカルメタデータサーバ156及びメタデータサーバ230に通知する。ローカルメタデータサーバ156及びメタデータサーバ230は、通知された変更内容を、保存しているそのeDocのメタデータに反映させる。例えば、配信時には配信先に指定されていたユーザであっても、その後の変更で配信先から削除された場合、そのeDocの閲覧が不可となる。また、処理装置110は、このようにeDocのメタデータ中の配信先情報が変更された場合、変更前の配信先情報には含まれていたが、変更後の配信先情報には含まれていない配信先の閲覧端末104に対して、そのeDocファイル(及び対応するメタデータ)を削除する指示を送ってもよい。
【0172】
以上の例では、処理装置110がeDocの配信先やアクセス権限の変更指示を受け付けたが、この代わりに又はこれに加えて、上位装置、すなわち管理システム200(メタデータサーバ230)又は組織内管理システム150(ローカルメタデータサーバ156)がその変更指示を受けてもよい。この場合、上位装置は、そのeDocを生成した処理装置110(及びその処理装置110が属する組織のローカルメタデータサーバ156)に対して、その変更指示に応じて変更された新たなメタデータを送信し、処理装置110内の既存のメタデータと置き換えさせるようにする。
【0173】
<処理装置のステータス管理>
次に、処理装置110のステータス管理に基づく制御について説明する。
【0174】
処理装置110は、定期的に自身のステータスを管理システム200に通知する。管理システム200では、処理装置管理サーバ240が、受け取ったステータスを、その受け取りの日時と対応付けて当該処理装置110についてのステータス履歴242に追加する。また処理装置管理サーバ240は、受け取ったステータスについてチェックを行い、そのチェックの結果に従って、処理装置110のユーザに対するサービス提供の可・不可を制御する。
【0175】
処理装置110が処理装置管理サーバ240に定期送信するステータスは、図6に例示した処理装置のステータス244と同様の項目を含む(ただし、ステータス244のうち処理装置110によっては変更されることがない設置場所やエンコード回路情報、処理装置の製造者名等は定期送信しなくてよい)。
【0176】
処理装置管理サーバ240は、処理装置110から送られてくるステータスに基づき、例えば図16に例示する処理を実行する。
【0177】
まず、処理装置管理サーバ240は、処理装置110からステータスを受信すると(S100)、そのステータスのうちの検査対象項目の値を、それぞれの項目の基準と照合する(S102)。検査対象項目には、暗号化ソフトの名称及びバージョン、エンコードソフトの名称及びバージョン、処理装置110にインストールされているセキュリティ証明書、処理装置110にインストールされている暗号鍵(例えば秘密鍵と公開鍵ペア。通信路暗号化や署名的な目的等に用いる)の情報(例えば当該鍵の識別情報やインストール日時等)、エンコード回路の名称及びファームウエア(FW)のバージョン、搭載フォント種類、ディスク(二次記憶)の空き容量、が含まれる。また、個々の項目についての基準の例としては、暗号化ソフトやエンコードソフト、ファームウエアが最新バージョンであること(あるいはあるバージョン以降のバージョンであること)、ディスクの空き容量が所定の閾値以上であること、インストールされているセキュリティ証明書の中にブラックリストに入っている証明書がないこと、処理装置110の暗号鍵がインストールされた日から所定期間が経過していないこと、所定(すなわちあらかじめ定めた)種類のフォントがインストールされていること、などがある。
【0178】
例えば、処理装置110が通信路暗号化や署名等に用いる暗号鍵は、その安全性を維持するために、定期的に新しい鍵に変更することが望ましいので、インストール日時から所定期間が経過した以降は基準を満たさないものと判定してサービス提供を不可とし(あるいは不可となる旨の警告を発し)、新しい鍵への交換を促す。
【0179】
次に処理装置管理サーバ240は、処理装置110から受け取ったステータスの検査対象項目の中に、当該項目の基準を満たさないものがあるかどうかを判定し(S104)、なければ今回ステータスを受信した処理装置110についての処理を終了する。S104で基準を満たさない項目があった場合、処理装置管理サーバ240は、その処理装置110に対してサービス不可を通知する(S106)。この通知を受けた処理装置110は、本実施形態のドキュメント管理システムに対するドキュメントの登録(配信)サービスを停止する。すなわち、作成端末102からのドキュメントの登録(配信)要求を受け付けず、サービス停止中である旨のメッセージを返す。
【0180】
このような制御によれば、処理装置110が基準を満たさない品質のeDocを生成してしまう可能性が低減される。例えば、この制御によれば、古い暗号化ソフトにより暗号化の強度が十分でないeDocが生成される前に、その処理装置110のサービスが停止される。また、ディスク空き容量が少なかったりファームウエアが古かったりしてeDocの生成処理にエラーが生じ、それが元でドキュメントの漏洩が生じるといった事態が起こる前に、サービスが停止される。また、所定のフォントを持たない処理装置110がドキュメント中のそのフォントを別のフォントに置き換えてエンコードしてしまうことによるeDocの画質低下が起こる前に、サービスが停止される。エンコード回路のファームウエアが古いため、最新のファームウエアがサポートしているドキュメントの画像サイズがサポートされておらず、eDocの画像サイズが制限されてしまう等の事態も生じにくくなる。
【0181】
なお、ステータスの検査対象項目に、eDocのセキュリティに影響する項目とそうでない項目の分類を設け、処理装置110にサービスを停止させるのは、前者の項目が基準を満たさない場合に限ってもよい。後者の項目が基準を満たさない場合は、処理装置110やその管理者に警告を送り、その項目についての不具合を解消するよう促す。この警告を受けて、処理装置110の管理者は、自分で対処できる項目については処理装置110の修理を行い、専門の保守作業員の介入が必要な項目については、保守作業員の派遣をシステム運営者に依頼する。また、検査対象項目のうちの特定項目が基準を満たさないことが分かった場合に、処理装置管理サーバ240が、当該処理装置110に対して保守作業員を派遣する手配を自動的に行ってもよい。
【0182】
図16の処理の変形例を、図17を参照して説明する。
【0183】
図17の手順では、処理装置110のステータスの検査対象項目に、緊急項目とそれ以外というレベル分けを導入している。緊急項目は、処理装置110が生成するeDocのセキュリティ上の品質やドキュメント管理システムのセキュリティに大きな影響を与える項目である。その項目が基準を満たさない処理装置110が生成したeDocは十分な安全性が確保されないか、またはその項目が基準を満たさない処理装置110が稼働を続けると、その処理装置110がドキュメント管理システムのセキュリティホール(脆弱性)となってしまう可能性がある。そのような緊急項目の対象の例としては、暗号化ソフトのバージョン、処理装置110にインストールされているセキュリティ証明書、処理装置110にインストールされている暗号鍵に脆弱性が見つかった場合等がある。
【0184】
緊急項目が基準を満たさないことによる問題を避ける1つの方法は、緊急項目が基準を満たさない処理装置110を停止させ、保守作業員を派遣してその緊急項目についての修正・修理を行わせることである。しかし、修正が完了するまでの間、ユーザはその処理装置110を使えないという不便がある。
【0185】
そこで、図17の手順では、処理装置管理サーバ240は、S104で基準を満たさない項目を見つけた場合、その項目が緊急項目であるかどうかを判定する(S110)。そして、緊急項目である場合、その緊急項目の不具合を修正するための設定情報を処理装置管理サーバ240からその処理装置110に対して、広域ネットワーク10を経由してリモートインストールする(S112)。緊急項目の不具合を修正するための設定情報の例としては、最新バージョンの暗号化ソフト、脆弱性が見つかったセキュリティ証明書に対する脆弱性が解消された最新版のセキュリティ証明書、処理装置110の脆弱性が見つかった秘密鍵・公開鍵のペアを置き換える新たな鍵ペア、等がある。
【0186】
例えば新たな鍵ペアの場合、その新たな鍵ペアを生成するためのフレーズを処理装置管理サーバ240が用意してそのフレーズを用いて鍵ペアを生成し、生成した鍵ペアをセキュアな方法で処理装置110に伝送してリモートインストールする。
【0187】
これにより処理装置110内の基準を満たさない緊急項目についての設定情報が基準を満たすものへと更新される。またこの更新に応じて、その処理装置110が持つステータスのうちのその緊急項目の値が更新される。
【0188】
またS110の判定結果がNo(緊急項目に該当しない)の場合、処理装置管理サーバ240は、処理装置110又は管理者に対して基準を満たさない項目を示す警告を送り、その処理装置110のその項目についての修正のために保守作業員の派遣の手配を行う(S114)。緊急項目でない項目については、処理装置110がそのまま稼働を続けてもセキュリティ上の重大な問題は生じにくいので、処理装置110は停止させず、保守作業員の派遣により対処するのである。緊急項目以外の項目については、処理装置管理サーバ240がリモートインストールしなくてよいので、処理装置管理サーバ240の負荷増大が避けられる。
【0189】
図17の例では、緊急項目についての設定情報を処理装置管理サーバ240からトップダウンで処理装置110にインストールし、これに応じて処理装置110にてその設定情報がインストールされ、処理装置110のステータスのうちその緊急項目の値が更新される。これに対して、緊急項目以外のステータスの項目については、個々の処理装置110にて、例えば保守作業員により値の設定や変更を行い、その項目に対応する設定情報(例えば暗号化ソフトの最新バージョン)のインストールを行う。このように処理装置110で行われたステータス項目値の設定や変更は、上位の処理装置管理サーバ240に通知され、処理装置管理サーバ240は、その通知に応じて自身が持つその処理装置110のステータスの対応項目の値を変更する。
【0190】
<DIDの検証>
管理システム200は、処理装置110が発行したDIDを通知してきた際や、閲覧端末104からメタデータの要求(この要求はDIDを含む)を送ってきた際、あるいはDIDの検証の依頼をユーザ等から受けた際に、そのDIDが正しいものかどうかを検証する。
【0191】
この場合DIDサーバ220は、対象のDID600(図15参照)について以下の点を検証する。
【0192】
(a)DID600中の発行権限キー602と処理装置固有情報604との間に矛盾がないこと。
【0193】
DIDサーバ220は、その発行権限キー602が、自身の記録している情報(図5参照)の中に、その処理装置固有情報604が示す処理装置110を付与先とする発行権限キーとして記録されているかどうか調べる。記録されていなければ、その発行権限キー602はその処理装置固有情報604が示す処理装置110に発行されたことがないものなので、それら両者は矛盾する。この場合、そのDID600は不正なDIDである。
【0194】
(b)DID600中の発行権限キー602と発行年月日606とが矛盾しないこと。
【0195】
DIDサーバ220は、発行権限キーに対応づけて、キー付与日時とキー終了日時を記録している(図5参照)。DID600中の発行年月日606が、DID600中の発行権限キー602に対応付けて記録されているキー付与日時からキー終了日時までの期間から外れている場合、発行権限キー602と発行年月日606は矛盾している。この場合、DID600は不正なDIDである。
【0196】
(c)DID600中の発行権限キー602、処理装置固有情報604及び発行証明キー608の間に矛盾がないこと。
【0197】
DIDサーバ220は、発行証明キー608を、その処理装置固有情報604が示す処理装置110の公開鍵で復号し、その復号結果が示す発行証明キーが、DID600中のその発行証明キー608と一致するかどうかを判定する。一致しない場合、それら三者の間には矛盾が存在し、DID600は不正なものであると分かる。
【0198】
(d)DID600中の発行番号610が、発行権限キー602に対応する発行枠と矛盾しないこと。
【0199】
DIDサーバ220は、発行権限キー602と共に処理装置110に付与した発行枠を記録している(図5参照)。DID600中の発行番号610が、発行権限キー602に対応して記録されている発行枠よりも大きい番号である場合、そのDIDは不正なものである。
【0200】
(e)DID600中の発行番号610が、そのDID600の発行権限キー602と同じ発行権限キーを含む発行済みのDIDの発行番号と矛盾しないこと。この基準は、処理装置110から新たに発行したDIDを通知された場合に、そのDIDが既に発行済みのものと矛盾するかどうかの検証に用いる。
【0201】
DIDサーバ220は、発行権限キーに対応付けて、その発行権限キーを用いて発行されたDIDやその発行日時の情報を記録している(図5の発行済DIDリスト)。DIDサーバ220は、検証対象のDID600の発行権限キー602と同じ発行権限キーを持つ発行済みDIDの中に、そのDID600中の発行番号610と同じ発行番号を持つものがあるかどうかを調べる。そのようなものがあれば、そのDID600は不正なものであると判定される。
【0202】
(f)DID600中の発行年月日606及び発行番号610の組合せが、そのDID600の発行権限キー602と同じ発行権限キーを含む発行済みのDIDの発行年月日と発行番号の組合せと矛盾しないこと。
【0203】
DIDサーバ220は、検証対象のDID600の発行年月日606と発行番号610の組合せが、そのDID600の発行権限キー602と同じ発行権限キーを含む個々の発行済DIDの発行年月日と発行番号の組合せと矛盾するかどうか、すなわち前後関係が逆になっているものがあるかどうか、を判定する。例えばDID600よりも発行年月日が後にもかかわらず、発行番号が小さい発行済みDIDが見つかった場合、DID600とその発行済みDIDとは矛盾、すなわち前後関係が逆転している。このような矛盾が見つかった場合、検証対象のDID600だけ、あるいはこれとその発行済みDIDとの両方を不正なものと判定する。
【0204】
DIDサーバ220は、以上のような基準に従った検証によりあるDIDが不正なものであると判定した場合、その不正なDIDに関連する処理装置110の管理者に電子メール等で警告通知を行う。警告通知には、その処理装置110の発行したものと偽装したDIDが見つかったことを知らせるメッセージが含まれる。管理者は、その通知により、セキュリティ強化の施策を行う。処理装置110の管理者やその連絡先は、処理装置管理サーバ240が持つ情報(図6参照)から求めればよい。警告通知の宛先である不正なDIDに関連する処理装置110は、そのDIDに含まれる処理装置固有情報604が示す処理装置110である。また、その不正なDIDに含まれる発行権限キーと同じ発行権限キーを過去に付与したことがある処理装置110を警告通知の宛先としてもよい。
【0205】
<eDocの暗号に脆弱性が発見された場合の処理>
さて、次に、eDocファイルの生成の際の暗号化に用いた暗号化ソフトに脆弱性が発見された場合の処理について説明する。ドキュメント管理システムの運営者は、いずれかの処理装置110が用いた暗号化ソフトの特定バージョンに脆弱性が発見されたことを知得した場合、管理システム200から各処理装置110に対して脆弱性通知を送信する。脆弱性通知には、脆弱性が発見された暗号化ソフトのソフト名及びバージョンの情報が含まれる。組織内管理システム150が存在する場合には、脆弱性通知は、管理システム200から組織内管理システム150に渡され、組織内管理システム150が配下の各処理装置110にその脆弱性通知を送信する。この通知に対して、処理装置110は図18に例示する処理を実行する。
【0206】
処理装置110は、上位装置(管理システム200又は組織内管理システム150)から脆弱性通知を受信(S200)すると、その通知が示す脆弱性が見つかった暗号化ソフトのバージョンを用いて自機が暗号化したファイルを特定する(S202)。処理装置110のドキュメントDB116には、その処理装置110が生成した各eDocファイルとそのメタデータが保存されており、それら各eDocファイルのメタデータから各eDocの生成に用いられた暗号化ソフト名とバージョンが分かる(図3に示すメタデータの構造例を参照)。S202では、処理装置110は、メタデータに含まれる暗号化ソフト名とバージョンの組合せが、脆弱性通知に示された組合せと一致するeDocを特定する。
【0207】
次に処理装置110は、特定した各eDocファイルを、自機にインストールされている現用の暗号化ソフトのバージョンで再暗号化する(S204)。この例では、処理装置110の暗号化ソフトは適切にバージョンアップされており、処理装置110が持つ現用の暗号ソフトのバージョンについては脆弱性が未発見であると想定している。一般に、処理装置110が過去に用いた暗号化ソフトのバージョンで脆弱性が発見されることが多いと考えられる。なお万が一、脆弱性通知の対象である暗号化ソフトのバージョンが、処理装置110の現用バージョンの暗号ソフトである場合には、処理装置110は上位装置等から最新バージョンの暗号ソフトをダウンロードし、その最新バージョンを用いて再暗号化を行う。仮に現用の最新バージョンの暗号化ソフトに脆弱性が発見された場合、上位装置は、その脆弱性が解消された更に新しいバージョンの暗号化ソフトを有しているか、そのソフトの配布元の情報を有していると想定できる。再暗号化は、例えば、対象のeDocファイルを、そのeDocファイルに対応するメタデータに記録されている復号鍵の情報を用いて復号し、その復号結果を新たに生成した暗号鍵を用いて、脆弱性のないバージョンの暗号化ソフトを用いて暗号化する。なお、処理装置110の保存するメタデータには復号鍵の情報が、例えば処理装置110の公開鍵で暗号化された状態で含まれているものとする(同様に、上位装置に送るメタデータには、その復号鍵がその上位装置の公開鍵で暗号化されたものを含めてもよい)。
【0208】
処理装置110は、その再暗号化に応じて、そのeDocファイルのメタデータを更新する(S206)。すなわち、メタデータ(図3参照)中のエンコード日時、暗号化情報(暗号化ソフト名、バージョン情報及び鍵情報)を、再暗号化の日時、再暗号化に用いた暗号化ソフト名、バージョン及びその暗号化を解くための復号鍵の情報へと書き換える。そして、処理装置110は、更新後のメタデータを保存(例えばそのeDocファイルに対する最新のメタデータとして保存)し、上位装置にアップロードする。上位装置は、アップロードされた更新後のメタデータを保存する。
【0209】
その後、処理装置110は、再暗号化により得られたeDocファイルを、メタデータの配信先情報に示される配信先の各閲覧端末104に配信するための処理を実行する(S208)。すなわち例えば、配信先の各閲覧端末104に対して、配信準備完了通知を送る(図8のステップ(7)参照)。この通知には、DIDやドキュメント名に加え、配信するeDocが既配信のeDocの更新版である旨を示す情報を含めてもよい。この配信準備完了通知を受け取った閲覧端末104は、閲覧者が閲覧端末104のリスト画面500(図11参照)で、その再暗号化により配信準備完了通知を受けたeDocを閲覧対象に指示した場合、閲覧端末104は、その指示に応じて処理装置110から取得したeDocファイルと、自機内にある再暗号化前のeDocファイルに上書きする。また閲覧端末104は、そのeDocファイルと共に受け取った更新後のメタデータを、そのeDocの最新のメタデータとして保存する。これにより、脆弱性のある暗号化ソフトで暗号化されたeDocファイル及びそれに対応するメタデータは閲覧端末104からなくなり、脆弱性の見つかっていない暗号化ソフトで再暗号化されたeDocファイル及びメタデータに置き換えられる。
【0210】
なお、処理装置110は、再暗号化したeDocの閲覧準備完了通知を送る際又はその前に、そのeDocのDIDを含む削除通知を配信先の各閲覧端末104に明示的に送信してもよい。この場合、その指示に応じて各閲覧端末104が、そのDIDを持つ既存のeDocファイル(再暗号化前のもの)を削除する。このとき既存のメタデータも併せて削除してもよい。
【0211】
<配信先端末指定の別の例>
これまでに説明した例では、配信者が作成端末102のUI画面(図9の入力画面400)で選択可能な配信先のユーザ及び閲覧端末104は、同じローカルシステム100内の処理装置110に登録されたユーザ及び閲覧端末104か、あるいは同じ組織の組織内管理システム150に登録されたユーザ及び閲覧端末104(この場合、別の処理装置110に登録されたユーザ及び閲覧端末104も配信先に指定可能)に限られていた。
【0212】
しかし、組織内のユーザが組織外の人(ゲスト)を交えた会議において、作成した会議メモ等のドキュメントをゲストに対して一時的に閲覧させたい場合もある。このような場合に、ゲストやゲストの携帯端末を処理装置110やその上位装置に登録したり、閲覧終了後にその登録を解除したりするのは煩雑な作業となる。
【0213】
そこで、本実施形態では、ゲストの端末と判断できる閲覧端末104には、一定の制限の下でeDocを配信可能とする。
【0214】
例えば、作成端末102の近傍にいるユーザの端末はゲスト端末であると見なし、そのゲスト端末を配信先端末選択メニュー406の選択肢に加える。あるいは、処理装置110の近傍にいるユーザの端末はゲスト端末であると見なし、そのゲスト端末を配信先端末選択メニュー406の選択肢に加える。作成端末102や処理装置110は、組織の建物の部屋(例えば部署の居室、会議室)に設置されていることが多いと考えられ、作成端末102又は処理装置110の近くにいる人は、会議等のためにしかるべき許可を受けてその部屋に入室している人であると想定される。
【0215】
例えば、処理装置110又は作成端末102は、Bluetooth Low Energy(登録商標)等の近距離無線通信を用いて通信可能な相手端末を探し、見つかった相手端末、又はそれら相手端末のうち自機からの距離(その近距離無線通信には、自機と相手の通信距離を求めることができるものもある)があらかじめ定めた閾値以下の端末を、自機の近傍にあるゲスト端末と判定する。そして、配信先端末選択メニュー406には、処理装置110又は作成端末102が検出したゲスト端末の端末名が、あらかじめ登録されている組織内の閲覧端末104とは別の表示態様で、選択肢として表示される。配信者は、その中で、配信先とするゲスト端末を選択可能である。
【0216】
ここで、処理装置110又は作成端末102は、自機の近傍にある端末すべてではなく、それら近傍の端末のうち所定の条件を満たすもののみをゲスト端末として配信先の選択肢に選んでもよい。例えば、端末が搭載しているビューワアプリケーションその他の特定のソフトウエアのバージョンがあるバージョン以上であることを条件としたり、あらかじめ定められている拒否端末リストに含まれないことを条件とすること等が考えられる。
【0217】
ゲスト端末を携帯しているユーザは、処理装置110やローカルユーザIDサーバ152等に登録されていないことが一般的と考えられる。そこで処理装置110は、ドキュメントの配信先に指定されたゲスト端末から、eDocファイルやメタデータを要求された場合には、ユーザ認証を省略してそれらデータを配信してもよい。また、ゲスト端末に配信するeDocのメタデータには、削除条件が満たされたらそのeDocファイル及びメタデータをゲスト端末から削除する旨の削除指示を組み込む。削除条件は、例えばそのeDocの画面表示が終了した場合、又は、配信時点から所定の許可期間が経過した場合、等である。ゲスト端末は、削除条件が満たされた時点で、そのeDocファイル及びメタデータを自端末内から削除する。これにより、ゲスト端末によるeDocの漏洩リスクが低減される。
【0218】
<配信先端末以外からの要求に対する対処>
これまでに説明した例は、配信者が配信先として指定した閲覧端末104に対して処理装置110がeDoc(又はこれに対応する配信準備完了通知)を配信するという、プッシュ型の配信形態であった。
【0219】
しかし、別の例として、閲覧端末104からの要求に応じて処理装置110が保持しているeDocのリストを閲覧端末104に提供し、その中からユーザが選択した閲覧対象を閲覧端末104に配信するという、プル型の配信形態も考えられる。プル型の配信形態の場合、配信先ユーザが、配信先に指定されていない閲覧端末104から処理装置110にアクセスし、eDocを要求することも考えられる。このような要求があった場合に処理装置110が行う対処として、以下のような方式がある。
【0220】
(方式1) 処理装置110は、閲覧端末104からeDocの配信要求を受けた場合に、その閲覧端末104が、そのeDocの最新のメタデータの配信先情報にて配信先とされている閲覧端末に該当するかどうか判定する。そして、該当しないと判定した場合には、そのeDocのファイル(本体)もメタデータもその閲覧端末104には送信しない。なお、該当すると判定した場合には、更に、その配信要求を行ったユーザ(あるいはそのユーザと閲覧端末104の組合せ)が、そのメタデータの配信先情報に含まれているかどうかを判定し、含まれている場合には配信を行い、含まれていない場合には配信を行わないようにしてもよい。
【0221】
このように、方式1では、配信者から指定された配信先に該当しない閲覧端末104には、eDoc(本体ファイル及びメタデータ)は配信されない。
【0222】
(方式2) この方式では、処理装置110は、eDocの配信要求を送ってきた閲覧端末104がそのeDocのメタデータの配信先情報に規定された配信先の閲覧端末104に該当しない場合でも、その要求を発したユーザ(すなわちその閲覧端末104を使用しているユーザ)がその配信先情報に配信先として含まれる場合は、eDocの本体ファイル及びメタデータを送信する。ただし、処理装置110は、この場合、送信するeDocファイル及びメタデータには、保存不可を示すフラグ情報を組み込む。閲覧端末104は、保存不可のフラグ情報を含んだeDocファイル及びメタデータは、表示はするが、ユーザからの保存指示は受け付けず、ユーザの閲覧が終了すると、それらを保存せずに破棄する。
【0223】
なお、配信先に指定されていない閲覧端末104に送信したeDocファイル及びメタデータをその閲覧端末104に保存させない方式に代えて、保存はいったん認めることも考えられる。ただし、この場合、その後再びその閲覧端末104がそのeDocファイルを開こうとする際、その閲覧端末104は処理装置110等にそのeDocの最新のメタデータを要求(これは閲覧の許可を求める要求である)するが、その要求に応じて処理装置110がその閲覧端末104と要求したユーザの組合せがそのメタデータの配信先情報に含まれるか判定し、含まれない場合は、閲覧端末104にそのeDocを削除する指示を送る。閲覧端末104は、その指示に応じて、保存しているそのeDocファイルとこれに対応するメタデータを削除する。なお、処理装置110は、最新のメタデータを要求した閲覧端末104に明示的にeDocの削除指示を送る代わりに、単にその最新のメタデータを応答してもよい。この場合、閲覧端末104が、受け取った最新のメタデータに、自機と現在のユーザの組合せが含まれているか判定し、含まれていない場合には、eDocファイルを開かず、更にその保存しているeDocファイルを削除してもよい。
【0224】
以上に説明した図18の例では、再暗号化後のeDocファイルは再暗号化前のeDocファイルのDIDを引き継いだが、再暗号化後のeDocファイルに再暗号化前のeDocファイルとは別のDIDを付与してもよい。この場合、処理装置110は、配信先の各閲覧端末104に対して、再暗号化前のeDocファイルのDIDを含んだ明示的な削除指示を送ることで、脆弱性のある再暗号化前のeDocファイルが閲覧端末104に残らないようにする。また、再暗号化後のeDocファイルと再暗号化前のeDocファイルとが互いに同じドキュメントに対応するものであることを示す関連付けの情報を、再暗号化後のeDocファイルに対応するメタデータ、又は処理装置110内(あるいは上位のDIDサーバ220、ローカルDIDサーバ154内)に記録する。再暗号化後のeDocに対応するメタデータに記録する場合には、例えば、そのメタデータに例えば「更新前のDID」の項目として、再暗号化前のeDocのDIDを含めればよい。
【0225】
以上、本発明の実施形態を説明した。以上に例示した作成端末102、閲覧端末104、処理装置110、ローカルユーザIDサーバ152、ローカルDIDサーバ154、ローカルメタデータサーバ156、ユーザIDサーバ210、DIDサーバ220、メタデータサーバ230、処理装置管理サーバ240等の各装置は、コンピュータに上述のそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、CPU等のマイクロプロセッサ、ランダムアクセスメモリ(RAM)およびリードオンリメモリ(ROM)等のメモリ(一次記憶)、フラッシュメモリやSSD(ソリッドステートドライブ)、HDD(ハードディスクドライブ)や等の固定記憶装置を制御するコントローラ、各種I/O(入出力)インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバス等を介して接続された回路構成を有する。それら各機能の処理内容が記述されたプログラムがネットワーク等の経由でフラッシュメモリ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがRAMに読み出されCPU等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
【符号の説明】
【0226】
10 広域ネットワーク、100 ローカルシステム、102 作成端末、104 閲覧端末、108 ローカルネットワーク、110 処理装置、112 管理情報記憶部、112a 管理情報、114a ユーザ情報、130 認証デバイス、150 組織内管理システム、152 ローカルユーザIDサーバ、154 ローカルDIDサーバ、156 ローカルメタデータサーバ、200 管理システム、210 ユーザIDサーバ、212 契約者データ、214 一般ユーザデータ、220 DIDサーバ、230 メタデータサーバ、240 処理装置管理サーバ、242 ステータス履歴、244 ステータス、246 ソフトウエア情報、248 ハードウエア情報、300 メタデータ、400 入力画面、402 配信先ユーザ選択メニュー、404 配信先ユーザリスト欄、406 配信先端末選択メニュー、408 配信先端末リスト欄、410 アクセス権限設定欄、412 オフライン有効期間メニュー、414 オプション設定呼出ボタン、420 オプション設定画面、422 処理装置指定欄、424 元データ設定欄、500 リスト画面、502 通知マーク、504 ドキュメント名、506 閲覧可否マーク、602 発行権限キー、604 処理装置固有情報、606 発行年月日、608 発行証明キー、610 発行番号。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18