[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP6819748B2 - 情報処理装置、情報処理システム及びプログラム - Google Patents

情報処理装置、情報処理システム及びプログラム Download PDF

Info

Publication number
JP6819748B2
JP6819748B2 JP2019164090A JP2019164090A JP6819748B2 JP 6819748 B2 JP6819748 B2 JP 6819748B2 JP 2019164090 A JP2019164090 A JP 2019164090A JP 2019164090 A JP2019164090 A JP 2019164090A JP 6819748 B2 JP6819748 B2 JP 6819748B2
Authority
JP
Japan
Prior art keywords
processing device
metadata
information
edoc
user
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.)
Active
Application number
JP2019164090A
Other languages
English (en)
Other versions
JP2019212337A (ja
Inventor
伊與田　哲男
哲男 伊與田
成樹 神谷
成樹 神谷
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.)
Fujifilm Business Innovation Corp
Original Assignee
Fuji Xerox Co Ltd
Fujifilm Business Innovation Corp
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 Fuji Xerox Co Ltd, Fujifilm Business Innovation Corp filed Critical Fuji Xerox Co Ltd
Publication of JP2019212337A publication Critical patent/JP2019212337A/ja
Application granted granted Critical
Publication of JP6819748B2 publication Critical patent/JP6819748B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Storage Device Security (AREA)

Description

本発明は、情報処理装置、情報処理システム及びプログラムに関する。
特許文献１に開示された文書管理システムは、文書記憶部に、文書を、文書の内容に関する商品等の属性情報とともに記憶し、アクセス情報記憶部に、文書へのアクセスを許可する者に関するアクセス情報を文書の内容に関する属性情報に関連付けて記憶する。文書管理システムは、アクセス受付部が、文書記憶部の文書へのアクセス要求を受け付けると、要求者情報取得部が、文書へのアクセスの要求者に関する要求者情報を取得し、アクセス制御部が、アクセスの要求者の要求者情報と文書に関するアクセス情報に基づいて、アクセス要求を制御する。
特許文献２に開示された方法は、端末装置から文書データにアクセスがあった場合に、権限確認部がデータベースを参照してアクセス元のアクセス権限を取得するとともに、無効化処理部が文書データ内部のタグによって指定されるリンク先のアドレスを変換して無効化する。解除処理部は、権限確認部によって確認したアクセス権限と文書データに設定されたセキュリティレベルとを比較し、セキュリティレベルがアクセス権限未満であるリンク先の無効化処理を解除することでリンク先文書の表示を許可する。
特開２０１６−１３９２３０号公報 特開２００４−１７１３９６号公報
添付ファイルのついた電子メール等のように途中にネットワーク上の１以上のサーバを介してデータを転送する方式では、転送経路上のサーバからデータが漏洩するリスクがある。
本発明は、送信側装置から受信側装置へ、文書本体と当該文書に関連するメッセージとを送信する場合において、管理システム側で当該メッセージに関する情報の送受信を管理しつつ、文書本体の送受信は当該メッセージに関するメタデータを用いて装置間で行うシステムを提供することを目的とする。
請求項１に係る発明は、暗号化文書を記憶する記憶手段と、前記暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを管理システムへ送信する第１送信手段と、前記管理システムから前記第１のメタデータを受け取った受信側装置からの転送要求に応じて、前記暗号化文書を前記受信側装置へと送信する第２送信手段と、を備えた情報処理装置である。
請求項２に係る発明は、前記第１のメタデータには、前記情報処理装置の識別情報である送信側識別情報、前記受信側装置の識別情報である受信側識別情報、及び前記暗号化文書の文書識別情報が含まれ、前記第２送信手段は、前記第１のメタデータに含まれる前記受信側識別情報を持つ前記受信側装置から、前記第１のメタデータに含まれる前記文書識別情報を含む前記転送要求を受けた場合に、前記文書識別情報に対応する前記暗号化文書を前記受信側装置に送信する、請求項１に記載の情報処理装置である。
請求項３に係る発明は、前記情報処理装置自身のステータスを前記管理システムに送信するステータス送信手段、を更に備え、前記第１送信手段は、前記ステータス送信手段が送信した前記ステータスが条件を満たしている場合に前記管理システムが発する送信許可を受け取った場合に、前記第１のメタデータを前記管理システムに送信する、請求項１に記載の情報処理装置である。
請求項４に係る発明は、前記管理システムは、前記受信側装置のステータスが条件を満たす場合に前記受信側装置に前記暗号化文書の受信許可を与え、前記第２送信手段は、前記受信許可を受けた前記受信側装置からの転送要求を受けた場合に、前記暗号化文書を前記受信側装置に送信する、請求項３に記載の情報処理装置である。
請求項５に係る発明は、前記暗号化文書を閲覧可能なユーザ又は閲覧端末のうちの少なくとも一方を規定する情報を含んだ第２のメタデータを前記管理システムに送信する第３送信手段、を更に備え、前記受信側装置から前記暗号化文書を受け取った閲覧端末は、前記暗号化文書の内容をユーザに表示するか否かを、前記第２のメタデータに従って制御する、請求項１〜４のいずれか１項に記載の情報処理装置である。
請求項６に係る発明は、コンピュータを、暗号化文書を記憶する記憶手段、前記暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを管理システムへ送信する第１送信手段、前記管理システムから前記第１のメタデータを受け取った受信側装置からの転送要求に応じて、前記暗号化文書を前記受信側装置へと送信する第２送信手段、として機能させるためのプログラム。
請求項７に係る発明は、送信側装置が記憶する暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを管理システムから受信する第１受信手段と、前記第１受信手段が受信した前記第１のメタデータに含まれる情報を用いて前記送信側装置に前記暗号化文書の転送要求を送信し、前記転送要求に応じて前記送信側装置が送信した前記暗号化文書を受信する第２受信手段と、を備えた情報処理装置である。
請求項８に係る発明は、前記第１のメタデータには、前記送信側装置の識別情報である送信側識別情報、前記情報処理装置の識別情報である受信側識別情報、及び前記暗号化文書の文書識別情報が含まれ、前記第２受信手段は、前記第１のメタデータに含まれる前記送信側識別情報を持つ前記送信側装置に対して、前記第１のメタデータに含まれる前記文書識別情報を含む前記転送要求を送り、前記転送要求に応じて前記送信側装置から送信された前記暗号化文書を受信する、請求項７に記載の情報処理装置である。
請求項９に係る発明は、前記情報処理装置自身のステータスを前記管理システムに送信するステータス送信手段、を更に備え、前記第２受信手段は、前記ステータス送信手段が送信した前記ステータスが条件を満たしている場合に前記管理システムが発する許可を受け取った場合に、前記送信側装置に対して前記転送要求を送る、請求項８に記載の情報処理装置である。
請求項１０に係る発明は、コンピュータを、送信側装置が記憶する暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを管理システムから受信する第１受信手段、前記第１受信手段が受信した前記第１のメタデータに含まれる情報を用いて前記送信側装置に前記暗号化文書の転送要求を送信し、前記転送要求に応じて前記送信側装置が送信した前記暗号化文書を受信する第２受信手段、として機能させるためのプログラムである。
請求項１１に係る発明は、送信側装置と、受信側装置と、管理システムとを備え、前記送信側装置は、暗号化文書を記憶する記憶手段と、前記暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを前記管理システムへ送信する第１送信手段と、前記管理システムから受信側装置に送信された前記第１のメタデータに対し前記受信側装置にてアクセスが行われたことに応じて、前記暗号化文書を前記受信側装置へ送信する第２送信手段と、を備え、前記受信側装置は、前記管理システムから前記第１のメタデータを受信する第１受信手段と、前記第１受信手段が受信した前記第１のメタデータに対しアクセスが行われた場合に、前記第１のメタデータに含まれる情報を用いて前記送信側装置から前記暗号化文書を受信する第２受信手段と、を備える情報処理システムである。
請求項１２に係る発明は、閲覧端末を更に備え、前記送信側装置は、前記暗号化文書を閲覧可能な配信先を規定する情報を含んだ第２のメタデータを前記管理システムに送信する第３送信手段を更に備え、前記受信側装置は、前記閲覧端末に対して前記暗号化文書を送信する手段を更に備え、前記閲覧端末は、前記受信側装置から前記暗号化文書を受信し、前記管理システムから前記暗号化文書に対応する前記第２のメタデータを受信し、前記暗号化文書の内容をユーザに表示するか否かを前記第２のメタデータに従って制御する、請求項１１に記載の情報処理システムである。
本発明によれば、送信側装置から受信側装置へ、文書本体と当該文書に関連するメッセージとを送信する場合において、管理システム側で当該メッセージに関する情報の送受信を管理しつつ、文書本体の送受信は当該メッセージに関するメタデータを用いて装置間で行うシステムを提供することができる。
ドキュメント管理システムの構成の例を示す図である。 ドキュメント管理システムを利用したドキュメントの配信及び閲覧の概要を説明するための図である。 メタデータのデータ内容を例示する図である。 ユーザＩＤサーバが管理するデータ内容を例示する図である。 ＤＩＤサーバが管理するデータ内容を例示する図である。 処理装置管理サーバが管理するデータ内容を例示する図である。 処理装置の構成及び処理装置が持つデータ内容を例示する図である。 ドキュメント管理システムにおけるドキュメント配信及び閲覧の流れを説明する図である。 属性データの入力画面の例を示す図である。 オプション設定画面の例を示す図である。 リスト画面の例を示す図である。 組織内管理システムを設けたシステム構成の例を示す図である。 ユーザが自分の登録されていない処理装置を用いてドキュメントのメタデータ取得及び閲覧を行う際の処理の流れの例を示す図である。 ユーザが自分の登録されていない処理装置を用いてドキュメント管理システムにドキュメントを登録する際の処理の流れの例を示す図である。 ＤＩＤのデータ内容の例を示す図である。 処理装置管理サーバが実行する処理装置のステータスチェック処理の流れを例示する図である。 処理装置管理サーバが実行する処理装置のステータスチェック処理の流れの別の例を示す図である。 暗号化ソフトに脆弱性が見つかった場合の処理装置の処理の流れを例示する図である。 処理装置のグループの設定の例を示す図である。 処理装置が転送管理のために保持する各種情報を示す図である。 ある処理装置の転送設定情報の例を示す図である。 アウェイ装置に該当する処理装置の処理手順を例示する図である。 ホーム装置に該当する処理装置の処理手順を例示する図である。 実施形態のシステムにおける送信側と受信側の処理装置を経由したドキュメントを転送する実施形態の処理を説明するための図である。 管理システムが行う、送信側の処理装置のセキュリティ要件のチェックの手順を例示する図である。 送信側の処理装置が行う送信準備処理の手順を例示する図である。 付箋メタデータのデータ構造を例示する図である。 管理システムが行う、受信側の処理装置のセキュリティ要件のチェックの手順を例示する図である。 一対多送信に対応するドキュメント管理システムの構成の例を示す図である。 一対多送信の処理の流れの例を説明する図である。
本発明に係るドキュメントの送信制御の実施形態を説明する前に、この送信制御が適用されるドキュメント管理システムについて説明する。このドキュメント管理システムは、出願人が先に出願した特願２０１７−０５２８５０号、特願２０１７−０５２８５１号、特願２０１７−０５２８５２号、特願２０１７−０５２８５３号、及び特願２０１７−１８０２１３号の明細書に例示したものと同様のものである。
図１に、ドキュメント管理システムの概略構成を示す。
紙の文書の場合、文書を持つ者が自由にコピーしたり他人に渡したりすることができる。また、文書を入手した者は、その文書を読むことができる。このように、紙の文書は情報漏洩を招くリスクが極めて高い。
これに対して、このドキュメント管理システムは、電子的なドキュメントをセキュアに利用できる環境を提供し、ドキュメントの情報が漏洩するリスクを下げることを目指す。ここで、ドキュメントは、１つの単位（例えば１つのファイル）として流通可能なコンテントデータであり、データの種類は特に限定されない。例えば、ドキュメントの概念には、テキストデータ、ワードプロセッサソフトで作成された文書データ、表計算ソフトで作成されたスプレッドシートデータ、ＣＡＤ（Computer Aided Design）データ、画像データ、動画データ、音声データ、マルチメディアデータ、ウェブブラウザで表示されたページデータ、その他ＰＣ上で作成・編集・閲覧されプリントアウト対象となる様なデータなどが含まれる。
このドキュメント管理システムは、複数のローカルシステム１００とそれらローカルシステムに関する管理（特に後述する処理システムの管理）を行う管理システム２００とを含む。管理システム２００は、インターネット等の広域ネットワーク１０を介して各ローカルシステム１００と通信可能である。
ローカルシステム１００は、ローカルネットワーク１０８に接続された１以上の作成端末１０２、１以上の閲覧端末１０４、及び処理装置１１０を含む。ローカルネットワーク１０８は、企業等の組織内に設けられたプライベートネットワーク（例えばＬＡＮとして構成）であり、ファイアウォール等により広域ネットワーク１０から保護されている。処理装置１１０は、基本的に、ローカルシステム１００内に１つ設置される。組織内のプライベートネットワークが大規模なものである場合、プライベートネットワークを構成する個々のネットワークセグメントをそれぞれローカルシステム１００とし、それら個々のローカルシステム１００内に１つずつ処理装置１１０を設置してもよい。例えば、ある会社の部署毎の居室内のネットワークセグメントがそれぞれその部署のローカルシステム１００となり、そのセグメントに１つの処理装置１１０が設置される。この例では、会社毎や各会社の部署毎に処理装置１１０を核とするローカルシステム１００が形成され、それら各処理装置１１０が中央にある管理システム２００から管理される。
作成端末１０２は、ドキュメントを作成するために用いられる端末であり、例えばデスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン、複合機、スキャナ、ファクシミリ装置、デジタルカメラ等がその例である。作成端末１０２には、ドキュメントの作成、編集等のためのアプリケーションがインストールされている。また、作成端末１０２には、作成したドキュメントの配信をドキュメント管理システムに依頼するためのソフトウエアがインストールされている。このソフトウエアの形態としては、後述する処理装置１１０と情報をやりとりするデバイスドライバとして実装、またはＷｅｂアプリによる実装、などが考えられる。
処理装置１１０は、作成端末１０２が作成したドキュメントを、ドキュメント管理システムが提供するセキュアな環境で用いる形態である保護済みドキュメント（以下では「ｅＤｏｃファイル」とも呼ぶ）へと変換するという保護処理を実行する。保護処理は、元のドキュメントをｅＤｏｃへとエンコードする処理ともいえ、この意味では処理装置１１０は一種のエンコーダである。この保護処理では、ドキュメントを、例えば、本実施形態のシステムのために設計された専用フォーマットのデータに変換すると共に、そのドキュメントの配信先に指定されたユーザにのみ復号可能な形で暗号化する。フォーマット変換と暗号化はどちらを先に行ってもよい。
また処理装置１１０は、保護済みドキュメントのメタデータを作成し、作成したメタデータを上位システムである管理システム２００に登録する。メタデータは、当該保護済みドキュメントの書誌事項、配信先の情報、各配信先が保護済みドキュメントの暗号化を解除するのに用いるキーの情報等を含む。メタデータは複数の項目を含み、このサービスで提供される機能に応じて対応するデバイスやユーザからデータ付与・編集・更新が実行される。
例として、それら項目のうちの一部を、ドキュメント管理システムに対するドキュメントの登録指示を行ったユーザが指定し、別の一部は処理装置１１０が作成する。また、メタデータのうちの一部の項目の値を管理システム２００や閲覧端末１０４が設定することもあり得る。また、処理装置１１０は、生成した保護済みドキュメント（ｅＤｏｃファイル）を、ユーザの指定した配信先の閲覧端末１０４に送信する。
保護済みドキュメントすなわちｅＤｏｃファイルは、元のドキュメントを専用フォーマットに変換し暗号化したものであり、ｅＤｏｃの本体とも呼ぶ。ｅＤｏｃファイルを閲覧可能とするには、対応するメタデータが必要となる。ｅＤｏｃファイルとメタデータとが揃って、閲覧可能な完全な保護済みドキュメントを構成する。このように、ｅＤｏｃファイルとこれに対応するメタデータとの組を、以下では「ｅＤｏｃ」と呼ぶ。
処理装置１１０は、無線ＬＡＮのアクセスポイントの機能を内蔵していてもよい。この場合、閲覧端末１０４は、無線ＬＡＮで処理装置１１０と通信可能である。
閲覧端末１０４は、保護済みドキュメント（ｅＤｏｃファイル）の閲覧に用いられる端末である。ここで言う「閲覧」は、保護済みドキュメントをそのドキュメントが表す情報内容に応じた態様で利用することを意味する。例えば、保護済みドキュメントがワープロデータや図面等の文書を情報内容として持つ場合、閲覧は、閲覧端末１０４が表示したその文書をユーザが読む又は見ることである。また保護済みドキュメントが表す情報内容が音声である場合、閲覧とは、閲覧端末１０４が再生したその音声をユーザが聞くことである。閲覧端末１０４は、例えば、デスクトップ型又はノート型のパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン等の汎用のコンピュータに、保護済みドキュメントを閲覧するためのビューワアプリケーションをインストールして構成される。また、電子書籍端末のような閲覧専用の端末に、ビューワアプリケーションと同等の機能を持たせたものを閲覧端末１０４として用いてもよい。ビューワアプリケーションは、暗号化されている保護済みドキュメントをメタデータの情報を用いて復号する機能や、保護済みドキュメントの専用フォーマットで表されるデータを可読な状態のデータへとデコードする機能を有する。なお、本実施形態のドキュメント管理システムに対応するビューワアプリケーションを持たないコンピュータは、専用フォーマットのデータを可読なデータへとデコードすることはできない。
閲覧端末１０４は、保護済みドキュメントを復号及びデコードして表示する機能に加え、表示したそのドキュメントに対するユーザからの加工（編集）を受け付ける機能を有していてもよい。加工されたドキュメントは、元の保護済みドキュメントとは異なる内容となるが、この編集後のドキュメントを閲覧端末１０４から処理装置１１０に送ってドキュメント管理システムに登録（すなわち保護済みドキュメントへとエンコード）できるようにしてもよい。このように、１つの端末が、作成端末１０２と閲覧端末１０４の両方の機能を持っていてもよい。なお、ｅＤｏｃには閲覧者に許可する権限（後述するメタデータ中のアクセス権限情報）が設定されており、その権限の内容には、そのｅＤｏｃへの書き込み制限、再配布先の制限などが含まれてもよい。このような制限がアクセス権限情報中に規定されているｅＤｏｃの場合、閲覧端末１０４は、閲覧者からの加工（編集）操作をその書き込み制限の範囲内でのみ受け付け、また加工後の新たなｅＤｏｃの再配布先の指定を、その再配布先の制限の範囲内でのみ受け付ける。
また、一例として、ドキュメント管理システムを利用するユーザを認証するためのツールとして、ユーザが携帯する認証デバイス１３０を用いる。認証デバイス１３０は、ＩＣカードのように、当該デバイスを携帯するユーザに固有の識別情報を内蔵し、外部装置からの要求に応じてユーザ認証のためのデータ処理を実行するデバイスである。認証デバイス１３０は、そのような個人認証用のＩＣカードと同等の機能を内蔵したスマートフォンのような携帯端末であってもよい。閲覧端末１０４や作成端末１０２は、ＮＦＣ（Near Field Communication）等の無線通信プロトコルを用いて認証デバイス１３０と通信する機能を備える。閲覧端末１０４や作成端末１０２は、認証デバイス１３０との間で所定のプロトコルに沿ってユーザ認証のための情報をやりとりし、その認証デバイス１３０を携帯するユーザを認証する。あるいは、実際のユーザ認証は処理装置１１０や管理システム２００等、本実施形態のドキュメント管理システムのサーバ側が実行し、閲覧端末１０４や作成端末１０２は、サーバ側と認証デバイス１３０との間のデータ転送の仲介を行う方式であってもよい。また、閲覧端末１０４や作成端末１０２が認証デバイス１３０の機能を内蔵していてもよい。
管理システム２００は、各ローカルシステム１００内の処理装置１１０を管理する。また管理システム２００は、それら各処理装置１１０が生成した保護済みドキュメントのメタデータを管理し、要求に応じてメタデータを閲覧端末１０４に提供する。管理システム２００は、１台のコンピュータ、又は相互に通信可能な複数のコンピュータにより構成され、ユーザＩＤサーバ２１０、ＤＩＤサーバ２２０、メタデータサーバ２３０、処理装置管理サーバ２４０の機能を有する。
ユーザＩＤサーバ２１０は、ドキュメント管理システムを利用する各ユーザの情報を管理するサーバである。ドキュメント管理システムを利用するユーザには、２つの階層がある。１つは、ドキュメント管理システムの利用のための契約を本システムの運営者と結んだ契約者であり、もう１つはその契約の下で実際にシステムを利用してドキュメントの登録や閲覧を行う一般ユーザである。例えば、会社が契約者であり、その会社のローカルネットワーク１０８に処理装置１１０が設置され、その会社の社員が一般ユーザとして、その処理装置１１０を介してドキュメント管理システムを利用するケースが多いと想定される。ユーザＩＤサーバ２１０は、契約者と一般ユーザのそれぞれについての情報を保持し、管理する。
ＤＩＤサーバ２２０は、保護済みドキュメントの識別情報（ＩＤ）であるＤＩＤ（ドキュメントＩＤ）を管理する。実際に保護済みドキュメントにＤＩＤを付与するのはその保護済みドキュメントを作成した処理装置１１０であるが、ＤＩＤサーバ２２０は処理装置１１０に対してＤＩＤの発行権限と発行枠（発行数）を付与し、その発行権限と発行枠の中で処理装置１１０が実際に発行したＤＩＤの報告を受けて記録する。これにより、ＤＩＤサーバ２２０は、不正なＤＩＤの発生を抑止し、不正なＤＩＤを持つドキュメントを検知可能とする。
メタデータサーバ２３０は、処理装置１１０が生成した保護済みドキュメント（ｅＤｏｃファイル）のメタデータを保持し、管理する。メタデータサーバ２３０は、ユーザから閲覧端末１０４を介して保護済みドキュメントのメタデータを要求された場合、そのユーザが正当な者であれば、メタデータをその閲覧端末１０４に提供する。なお、メタデータを要求するユーザ（閲覧者）がメタデータサーバ２３０にとって「正当な者」であるとは、そのユーザと、そのユーザがその要求を発する際に用いた閲覧端末１０４との組合せが、そのｅＤｏｃファイルのＤＩＤ（これはその要求に含まれる）に対応づけてメタデータサーバ２３０が保持しているメタデータ中の配信先情報（詳しくは後述）に示される配信先ユーザ及び配信先の閲覧端末１０４の組合せに該当する場合のことである。
処理装置管理サーバ２４０は、各処理装置１１０のステータス（状態）を管理するサーバである。
図２を参照して、このドキュメント管理システムの仕組みを概略的に説明する。
（０）管理システム２００（ＤＩＤサーバ２２０）は、ローカルシステム１００内の処理装置１１０に対してＤＩＤ（ドキュメントＩＤ）の発行権及びこれに付随する発行枠（ドキュメント数）を事前に付与している。ＤＩＤの発行権は、無制限ではなく、管理システム２００発行枠に制限される。すなわち、処理装置１１０は、管理システム２００から付与された発行枠が示す数までのドキュメントであれば、同時に付与された発行権に基づいたＤＩＤを付与することができる。発行枠を使い切れば、処理装置１１０は、管理システム２００から新たな発行権及び発行枠の付与を受ける。
（１）ユーザは、ドキュメントをドキュメント管理システムに登録したい（すなわち配信したい）場合、作成端末１０２にドキュメント登録を指示する（例えばアプリケーションのメニュー上で「登録」を指示する）。この指示を受けた作成端末１０２は、ユーザ認証を求める。この認証は、ユーザＩＤ及びパスワードの入力により行ってもよいし、作成端末１０２のカードリーダ部の近傍にユーザが認証デバイス１３０を近づけることで行ってもよい。ユーザ認証は、作成端末１０２が行ってもよいし、ドキュメントの登録先である処理装置１１０が行ってもよい。そして、ユーザは、作成端末１０２に保持されているドキュメントからドキュメント管理システムに登録するものを選んでその登録を指示する。
作成端末１０２（より詳しくは、作成端末１０２にインストールされた登録処理用プログラム）は、ユーザからドキュメントの登録指示を受けた場合、そのドキュメントに対する属性データのうちそのユーザが指定すべき項目（例えばドキュメントの配信先）の入力を受け付ける。ここで、配信先として、ユーザと閲覧端末１０４の組合せの指定を受け付けるようにしてもよい。この場合、ユーザと、そのユーザがドキュメントの閲覧に用いる閲覧端末１０４との組合せが、配信先として指定された組合せと一致する場合に、ユーザはそのドキュメントを閲覧可能となる。
作成端末１０２は、ユーザが入力した配信先等の属性項目と、作成端末１０２自身が生成した他の属性項目（例えば登録者の情報、作成日時等）と合わせた属性データを、そのドキュメントのデータと共に処理装置１１０に送信する。なお、作成端末１０２は、様々なアプリケーションが作成した様々なフォーマットのドキュメントを、閲覧端末１０４側で取扱可能な統一的なフォーマットに変換するドライバを有していてもよい。例えば、ワープロデータ、スプレッドシート、ＣＡＤデータのような静的な文書画像を示すデータの場合、そのドライバは、プリンタドライバと同様、そのデータをページ記述言語で表現されたドキュメントへと変換する。また、例えば、元のデータが音声データの場合、ドライバは、その音声データを本実施形態のドキュメント管理システム（特に閲覧端末１０４）が対応する特定の音声データ形式のデータ（ドキュメント）へと変換する。
（２）処理装置１１０は、作成端末１０２から受信した登録対象のドキュメントに対して保護処理を施すことで保護済みドキュメント（ｅＤｏｃファイル）を生成する。この生成では、受信したドキュメントをドキュメント管理システムの専用フォーマットへとエンコードし、エンコードしたデータを、生成した暗号鍵を用いて暗号化することで、ｅＤｏｃファイルを生成する。エンコードと暗号化の順序は逆でもよい。また処理装置１１０は、そのｅＤｏｃに対して一意なＤＩＤを付与する。このＤＩＤには、管理システム２００から受けた発行権限に基づくものであることを証する情報（後述する発行権限キー）と、その処理装置１１０自身が付与したものであることを証する情報（後述する発行証明キー）が含まれる。なお、ＤＩＤのデータ構造については、後で詳細な例を説明する。生成されたＤＩＤは、ｅＤｏｃファイル内に（例えばそのファイルのプロパティの一項目として）組み込まれる。
また処理装置１１０は、生成したｅＤｏｃファイルに対応するメタデータを生成する。このメタデータには、作成端末１０２からそのドキュメントと共に受け取った属性データと、処理装置１１０自身が生成した属性項目（例えば、ＤＩＤ、処理装置自身のＩＤ、エンコード日時、暗号鍵情報）の値とが含まれる。メタデータに含まれる暗号鍵情報は、ｅＤｏｃファイルの暗号化を解除するための鍵を示す情報である。暗号化に共通鍵方式を用いた場合、暗号鍵情報はその共通鍵を示す情報である。ただし、共通鍵そのものを平文でメタデータに含めると、盗聴や傍受により悪用される懸念があるので、その共通鍵を配信先ユーザの公開鍵で暗号化したものを暗号鍵情報としてメタデータに組み込む。
また、処理装置１１０は、生成したｅＤｏｃファイルとメタデータを、内蔵するデータベースに保存する。
（３）処理装置１１０は、生成したメタデータを管理システム２００に送信して登録する。管理システム２００（メタデータサーバ２３０）は、受信したメタデータを保存する。
（４）処理装置１１０は、生成したｅＤｏｃファイルを、配信先に指定された閲覧端末１０４に配信する。この配信は、プッシュ型でもプル型でも、それら両方（例えばｅＤｏｃ作成時にプッシュ配信し、そのときに非稼働で受信しなかった閲覧端末１０４はプル型で配信を受ける）であってもよい。この配信は、ローカルシステム１００内のローカルネットワーク１０８を介して行われる。
（５）閲覧端末１０４が受信したｅＤｏｃファイルは、暗号化等により保護されているのでそのままでは閲覧が不可能である。ユーザは、閲覧端末１０４でそのｅＤｏｃファイルを閲覧したい場合、自分の認証デバイス１３０をその閲覧端末１０４のカードリーダ部に近づけてユーザ認証を受けた後、閲覧端末１０４の画面上でそのｅＤｏｃの閲覧を指示する。この指示を受けた閲覧端末１０４は、管理システム２００にアクセスしてそのｅＤｏｃのメタデータを要求する。この要求には、そのｅＤｏｃのＤＩＤが含まれる。
（６）管理システム２００（メタデータサーバ２３０）は、閲覧端末１０４から要求されたｅＤｏｃの最新のメタデータをその閲覧端末１０４に送信する。
（７）閲覧端末１０４は、要求したメタデータを管理システム２００から受信すると、そのメタデータに含まれる配信先情報に、当該閲覧端末１０４と現在この閲覧端末１０４を利用しているユーザ（認証デバイス１３０で認証済み）との組合せが含まれるかどうかを判定する。含まれていない場合、そのユーザはその閲覧端末１０４でそのｅＤｏｃを閲覧する権限がないので、閲覧端末１０４はｅＤｏｃファイルを開かず、閲覧権限がない旨を示すエラーメッセージを表示する。含まれる場合は、そのユーザはその閲覧端末１０４でそのｅＤｏｃファイルを閲覧する権限を持つ。この場合閲覧端末１０４は、そのｅＤｏｃファイルをそのメタデータに含まれる暗号鍵情報を用いて復号し、画面に表示する（すなわちそのｅＤｏｃファイルの情報内容に応じた態様で出力する）。
メタデータには有効期限を設定する事が出来る。有効期限は、例えばメタデータが送信された日時に対し、規定の有効期間、または配信者等が指定した有効期間を足すことで求められる。閲覧端末１０４は、メタデータの有効期限が過ぎた後には、メタデータを再度管理システム２００から取得し直さないと、対応するｅＤｏｃファイルを開く（復号及び表示する）ことができない。閲覧端末１０４は、処理装置１１０又は管理システム２００と通信可能であれば、閲覧対象に指示されたｅＤｏｃファイルのその指示の時点での最新のメタデータを処理装置１１０又は管理システム２００から取得し、この最新のメタデータに基づいて閲覧可否を判定する。
メタデータが最初の管理システム２００に登録された後、そのメタデータに含まれる配信先情報やアクセス権限情報が配信者、または配信先の変更権限が与えられた者（例えばデータの編集権限を保有する者）により変更されることがある。ｅＤｏｃが作成・登録された時点で配信先に指定されたユーザであっても、その後の変更により配信先から外された場合には、閲覧端末１０４は、管理システム２００から取得した最新のメタデータに含まれる配信先情報によりそのことを検知し、ｅＤｏｃファイルの表示を行わない。
次に、図３を参照して、ｅＤｏｃのメタデータ３００のデータ内容の例を説明する。
メタデータ３００の含む項目のうち、まず「ＤＩＤ」は、そのｅＤｏｃを生成した処理装置１１０が付与したドキュメントＩＤである。「ドキュメント名」は、そのｅＤｏｃの名称又はタイトルである。
「配信者ＩＤ」は、そのｅＤｏｃを配信した者、すなわち作成端末１０２から処理装置１１０に対してドキュメントの登録操作を行い、処理装置１１０を介して配信を行う者（以下、配信者と呼ぶ）のユーザＩＤである。
「エンコード日時」は、作成端末１０２からのドキュメントがエンコード（保護処理）されてそのｅＤｏｃが作成された日時である。「処理装置ＩＤ」は、その保護処理を実行した処理装置の識別情報である。「暗号化情報」は、そのｅＤｏｃの生成時の暗号化に関する情報であり、暗号化に用いた暗号化ソフト名、その暗号化ソフトのバージョン、及びその暗号化を解除（復号）するための鍵を表す鍵情報を含む。鍵情報は、例えば、復号のための鍵を各配信先ユーザの公開鍵で暗号化したものである。「キーワード情報」は、そのｅＤｏｃ（又は元データ）から抽出したキーワードのリストである。このキーワード情報は、例えばｅＤｏｃの検索の際に利用される。
「配信先情報」は、配信者がそのｅＤｏｃの配信先に指定したユーザ及び閲覧端末を表す情報である。図３の例では、配信先情報は、配信先のユーザ毎に、そのユーザのユーザＩＤとそのユーザが閲覧に用いるべき閲覧端末１０４のＩＤ（識別情報）とを含んでいる。そのユーザがそのｅＤｏｃの閲覧に利用可能な閲覧端末１０４が複数指定された場合は、そのユーザのユーザＩＤとそれら複数の閲覧端末１０４のＩＤとの組が配信先情報に組み込まれる。
また別の例として、配信先ユーザは配信先に指定された閲覧端末１０４のうちのいずれを利用してもそのｅＤｏｃを閲覧可能とする方式を採用した場合、配信先情報には、配信先ユーザのＩＤのリストと、配信先の閲覧端末１０４のＩＤのリストが含まれる。例えば、配信先の閲覧端末１０４の候補として、部署の共用端末や、部署の居室や会議室に備え付けられた端末等が想定される場合がある。共用端末や居室等の備え付け端末（これも共用端末の一種）等は、組織内のユーザのだれが使うか決まっていないが、少なくともどのような端末であるかは配信者には分かっており、また勝手に組織外に持ち出される可能性が低いことも分かっているので、機密対象のドキュメントの配信先として適格である。このように素性の分かった共用端末でｅＤｏｃを利用する場合には、このように配信先ユーザは配信先に指定された閲覧端末１０４のうちのどれを利用してもよい、という利用形態も考えられる。
「アクセス権限情報」は、配信者が配信先のユーザに対して付与したそのｅＤｏｃに対する利用権限を表す情報である。
「オフライン有効期間」は、そのメタデータの有効期間の長さを表す情報である。すなわち、閲覧端末１０４が管理システム２００にアクセスできない状態（オフライン状態）にあるときでも、そのｅＤｏｃの前回の閲覧時に取得してキャッシュしているメタデータが存在し、そのメタデータの取得日時からその「オフライン有効期間」内であれば、閲覧端末１０４はそのメタデータ内の暗号鍵情報を用いてそのｅＤｏｃを復号して表示する。一方、オフライン状態であり、閲覧を指示されたｅＤｏｃについてのキャッシュしたメタデータのオフライン有効期間が既に過ぎている場合は、閲覧端末１０４は、そのｅＤｏｃを復号せず、したがって表示も行わない。なお、閲覧端末１０４は、管理システム２００にアクセス可能（すなわちオンライン状態）である間は、ユーザがｅＤｏｃの閲覧を指示した場合、そのｅＤｏｃの最新のメタデータを管理システム２００（特にメタデータサーバ２３０）から取得して使用する。
「元データ情報」は、ｅＤｏｃが生成（エンコード）される前の元データが保存されているか否かを示す情報と、保存されている場合はその元データの保存場所を示す情報（例えばＵＲＬ：Uniform Resource Locator）である。ここでの元データは、例えば作成端末１０２から処理装置１１０に送られたドキュメント（保護処理を施す前のもの）、又はそのドキュメントの元になったアプリケーションデータ（例えばドキュメントがページ記述言語データである場合、そのデータに変換する前のワープロソフトのデータ）、又はそれらの両方である。
「ドキュメント取得日時」は、閲覧端末１０４がそのｅＤｏｃの本体データのファイル（すなわちｅＤｏｃファイル）を取得した日時である。「メタデータ取得日時」は、閲覧端末１０４がそのｅＤｏｃの現在キャッシュしている最新のメタデータを管理システム２００から取得した日時である。ドキュメント取得日時及びメタデータ取得日時は、管理システム２００に保持されているメタデータには含まれず、閲覧端末１０４が管理システム２００から取得したメタデータに対して自機での管理のために追加する。
また図３に示したメタデータの項目のうち、ＤＩＤ、エンコード日時、処理装置ＩＤ、暗号化情報、キーワード情報は、処理装置１１０が生成する情報である。また、ドキュメント名、配信者ＩＤ、配信先情報、アクセス権限情報、オフライン有効期間、元データ情報は、作成端末１０２から処理装置１１０に送られるドキュメントや属性データに由来する。
次に、管理システム２００の各サーバ２１０〜２４０が管理する情報のデータ内容を例示する。
まず図４を参照して、ユーザＩＤサーバ２１０が管理するデータ内容の例を説明する。ユーザＩＤサーバ２１０には、各契約者の契約者データ２１２と、各一般ユーザのユーザデータ２１４が登録されている。
契約者データ２１２には、契約者ＩＤ、契約内容情報、及びユーザリストが含まれる。契約者ＩＤは、ドキュメント管理システムの運営者と契約した契約者（例えば組織や組織内の部署）の識別情報である。ユーザリストは、その契約者の契約によってこのドキュメント管理システムを利用する一般ユーザ（例えば契約者である組織に所属するメンバ）のユーザＩＤのリストである。
一般ユーザデータ２１４には、その一般ユーザのユーザＩＤ、パスワード、ユーザＩＤキー情報、公開鍵証明書、既定の処理装置ＩＤ、既定の閲覧端末リスト、所属情報を含む。ユーザＩＤキー情報は、そのユーザの認証デバイス１３０が用いるそのユーザの認証情報である。公開鍵証明書は、そのユーザの公開鍵を証明するデジタル証明書である。既定の処理装置ＩＤは、そのユーザが登録された処理装置１１０のＩＤである。通常、ユーザは自分が所属するオフィスに置かれた処理装置１１０に登録され、その処理装置１１０がそのユーザにとっての既定の処理装置となる。既定の閲覧端末リストは、そのユーザが主として使用する１以上の閲覧端末のＩＤのリストである。このリストに含まれる閲覧端末が、そのユーザに対してｅＤｏｃを配信する際の配信先の端末の候補となる。所属情報は、そのユーザが所属する組織やその部署等を特定する情報であり、例えばその組織や部署の契約者ＩＤである。
次に図５を参照して、ＤＩＤサーバ２２０が管理するデータ内容の例を示す。
ＤＩＤサーバ２２０は、図５に示すように、処理装置に対して発行した発行権限キー毎に、発行枠、付与先処理装置、キー付与日時、キー終了日時、発行済ＤＩＤリストの各項目の情報を保持している。
発行権限キーは、ＤＩＤサーバ２２０が処理装置１１０に対して付与した、ＤＩＤの発行権限を証明するキー情報（例えばランダムに生成した文字列）である。処理装置１１０は、自らが発行するＤＩＤに、ＤＩＤサーバ２２０から付与された発行権限キーを含めることで、そのＤＩＤが正当な発行権限の下で発行したものであることを証する。
発行枠は、その発行権限キーと共に処理装置１１０に付与したＤＩＤ発行上限数（ＤＩＤを付与可能な上限のドキュメント数）である。処理装置１１０は、発行権限キーと発行枠のペアをＤＩＤサーバ２２０から付与されると、その発行枠が示す上限数までのｅＤｏｃに対して、それぞれ固有のＤＩＤを付与することができる。
付与先処理装置は、その発行権限キー（及び発行枠）の付与先の処理装置１１０のＩＤを示す。キー付与日時は、その発行権限キーを処理装置１１０に付与した日時である。キー終了日時は、付与先の処理装置１１０がその発行権限キーを使い終わった日時である。すなわち、処理装置１１０がその発行権限キーと共に付与された発行枠が示す上限数のｅＤｏｃに対するＤＩＤの付与をし終えた日時である。なお、処理装置１１０が発行枠を使い切った後に次の発行権限キーと発行枠をＤＩＤサーバ２２０に要求する仕組みを採用している場合、ある発行権限キー（第１のキーと呼ぶ）のキー終了日時を明示的に記録する代わりに、当該発行権限キーの次に処理装置１１０が付与された発行権限キーのキー付与日時を、第１のキーのキー終了日時として用いてもよい。発行済ＤＩＤリストは、付与先の処理装置１１０がその発行権限キーを用いて発行したＤＩＤとその発行年月日のリストである。付与先の処理装置１１０は、発行権限キーを用いてＤＩＤを発行する毎にそのＤＩＤをＤＩＤサーバ２２０に通知し、ＤＩＤサーバ２２０は通知されたＤＩＤとその発行年月日を、そのＤＩＤに含まれる発行権限キーに対応する発行済ＤＩＤリストに追加する。
メタデータサーバ２３０は、各処理装置１１０から送られてくる各ｅＤｏｃのメタデータを保管する。保管するメタデータのデータ内容は、図３に例示したものと同様である。ただし、図３に例示したメタデータの項目のうち、閲覧端末１０４のみで用いる項目（ドキュメント取得日時やメタデータ取得日時等）については、メタデータサーバ２３０では管理しない。
次に図６を参照して処理装置管理サーバ２４０が管理するデータについて説明する。処理装置管理サーバ２４０は、管理対象の処理装置１１０毎に、その処理装置１１０のステータス履歴２４２を記憶している。ステータス履歴には、その処理装置１１０のＩＤに対応付けて、作成及び個々の更新の時点（作成・更新日時）でのその処理装置１１０のステータス２４４の情報が含まれる。
個々の時点でのステータス２４４には、設置場所、契約者ＩＤ、管理者名、管理者連絡先、登録ユーザリスト、ソフトウエア情報２４６、ハードウエア情報２４８、ディスク空き容量、セキュリティ証明書情報が含まれる。設置場所は、その処理装置１１０の設置場所を示す情報であり、例えば住所や建物名、階数などの情報を含む。契約者ＩＤは、その処理装置１１０を使用している契約者のＩＤである。管理者名は、その処理装置１１０の管理者の名前である。管理者は、処理装置１１０の設置先の部署等においてその処理装置１１０を管理しているユーザである。管理者連絡先は、その管理者の連絡先の情報（例えば電子メールアドレス）である。登録ユーザリストは、その処理装置１１０に登録されたユーザ（言い換えればその処理装置１１０を「既定の処理装置」とするユーザ）のユーザＩＤのリストである。
ソフトウエア情報２４６には、エンコードソフト名、エンコードソフトバージョン、暗号化ソフト名、暗号化ソフトバージョン、処理装置１１０にインストールされているその他のソフトウエアの名称及びバージョンが含まれる。ここでエンコードソフトは、作成端末１０２から入力されたドキュメントを、ドキュメント管理システムの専用フォーマットへと変換（エンコード）するソフトウエアである。暗号化ソフトは、ドキュメント（例えば専用フォーマットに変換されたもの）を暗号化するソフトウエアである。
ハードウエア情報２４８には、エンコード回路情報、エンコード回路ＦＷバージョン、当該処理装置１１０の製造者名等の項目が含まれる。エンコード回路情報は、エンコード処理に用いるハードウエア回路の機種を示す情報である。エンコード回路ＦＷバージョンは、そのエンコード回路のファームウエア（ＦＷ）のバージョンである。
ディスク空き容量は、処理装置１１０が持つハードディスク又はソリッドステートドライブ等の二次記憶装置の、その時点での空き容量である。
セキュリティ証明書情報は、処理装置１１０にその時点でインストールされている各セキュリティ証明書を特定する情報（例えば証明書のサブジェクト（subject:主体者）識別子、イシュア（issuer:発行者）識別子、発行日時等の情報）である。
また煩雑さを避けるために図示は省略したが、ステータス２４４には、処理装置１１０にインストールされているフォントの種類（フォント名のリスト）、ネットワーク通信のためのアドレス（例えばＩＰアドレス）、搭載している二次記憶装置（ハードディスクドライブ等）の装置ＩＤ、処理装置１１０を設置先の組織の基幹システムの処理に繋ぐためのカスタマイズ内容を示す情報、処理装置１１０が用いる暗号鍵（通信路暗号化や署名等のためのもの）のインストール日時等が含まれる。
次に図７を参照して、処理装置１１０が保持するデータベース群について説明する。図示のように、処理装置１１０は、管理情報記憶部１１２、ユーザＤＢ１１４及びドキュメントＤＢ１１６を含む。
管理情報記憶部１１２には、管理情報１１２ａが記憶される。管理情報１１２ａには、上位装置アドレス情報、セキュリティ証明書、暗号鍵、エンコードソフト名、エンコードソフトバージョン、暗号化ソフト名、暗号化ソフトバージョン等の項目が含まれる。上位装置アドレス情報は、処理装置１１０を管理する上位装置のそれぞれの通信アドレス（例えばＩＰアドレス、ＵＲＬ等）の情報である。管理システム２００やその中の各サーバ２１０〜２４０、又は後述する組織内管理システム１５０やその中の各サーバ１５２〜１５６が上位装置の例である。セキュリティ証明書は、処理装置１１０がネットワーク上の他の装置と公開鍵基盤準拠のセキュアな通信を行う際に用いるデジタル証明書である。処理装置１１０は、よく通信する相手である各上位装置のセキュリティ証明書を保持している。また作成端末１０２や閲覧端末１０４を使用する各ユーザのセキュリティ証明を保持してもよい。暗号鍵は、処理装置１１０がネットワーク上の他の装置と通信を行う際の暗号化や復号、処理装置１１０によるデジタル署名（又はそれに類する証明情報の生成）等の目的に用いる、当該処理装置１１０の暗号鍵であり、例えば公開鍵基盤においてその処理装置１１０に対して付与された秘密鍵と公開鍵のペアである。エンコードソフト及び暗号化ソフトは、それぞれ、この処理装置１１０にインストールされているエンコード（専用フォーマットへの変換）及び暗号化のためのソフトウエアである。
ユーザＤＢ１１４には、この処理装置１１０に登録されている各ユーザ（言い換えればこの処理装置１１０を「既定の処理装置」とするユーザ）のユーザ情報１１４ａが記憶されている。個々の登録ユーザのユーザ情報１１４ａには、ユーザＩＤ、パスワード、ユーザＩＤキー情報、公開鍵情報、既定の閲覧端末リスト等の項目が含まれる。これらの項目については、上述のユーザＩＤサーバ２１０が持つデータの説明（図４参照）で説明した。
ドキュメントＤＢ１１６には、処理装置１１０が生成したｅＤｏｃファイルと、そのｅＤｏｃファイルに対応するメタデータとが保存される。ｅＤｏｃファイルとメタデータとはＤＩＤの情報を含んでいるので、対応付けが可能である。またドキュメントＤＢ１１６には、ｅＤｏｃにエンコードする前の元のデータ（作成端末１０２から受け取ったもの）を、そのｅＤｏｃのＤＩＤに対応付けて登録してもよい。
作成端末１０２及び閲覧端末１０４は、当該端末を利用するユーザ毎に、そのユーザの認証情報（ユーザＩＤ、パスワード等）、既定の処理装置のＩＤ、既定の処理装置のアドレス情報、上位装置（例えば管理システム２００や後述の組織内管理システム１５０）のアドレス情報、処理装置や上位装置のセキュリティ証明書、通信路暗号化等に用いる暗号鍵等を記憶している。
＜システムの処理の流れ＞
ローカルネットワーク１０８上に処理装置１１０を設置した場合、処理装置１１０の保守を行う保守作業員は、処理装置１１０に対して、その処理装置１１０を利用するユーザの情報や、それらユーザが利用する可能性のある作成端末１０２や閲覧端末１０４の情報を登録する。登録されたユーザの情報は、上位装置であるユーザＩＤサーバ２１０（あるいは後述のローカルユーザＩＤサーバ１５２）にも転送され、登録される。なお、設置後、処理装置１１０を利用するユーザが増えたり減ったりした場合には、保守作業員は、処理装置１１０に対して増えたユーザの情報を新たに追加登録したり、減ったユーザの情報の登録を削除したりする作業を行う。このような追加や削除は、ユーザＩＤサーバ２１０等の上位装置にも通知され、これに応じ上位装置の保持する情報が更新される。また保守作業員は、それら各作成端末１０２に対して、処理装置１１０にドキュメントの登録及び配信を依頼する処理を行うソフトウエア（例えば処理装置１１０のデバイスドライバの形態をとる）をインストールする。また、保守作業員は、各閲覧端末１０４に対して、処理装置１１０と通信するための情報（例えば装置名、通信アドレス、無線アクセス設定）等を登録する。
次に図８を参照して、ドキュメント管理システムを経由してドキュメントが登録及び配信される際の処理の流れを説明する。
（１）−１： ユーザ（配信者）が作成端末１０２に対してドキュメントの登録の指示を行うと、作成端末１０２は、ログイン認証情報（例えばユーザＩＤ及びパスワード、又は認証デバイス１３０）の入力を求める画面を表示する。配信者がその求めに応じて認証情報を入力すると、作成端末１０２は、その認証情報をローカルネットワーク１０８経由で処理装置１１０に送信する。
（１）−２： ログイン認証情報を受け取った処理装置１１０はその情報を用いてユーザ認証を行う。ここではそのユーザ認証が成功した（正しいユーザと確認できた）とする。図示例では、ログインＩＤとパスワードを用いてログイン認証を行っているが、作成端末１０２が認証デバイス１３０との通信に対応している場合は認証デバイス１３０を用いてログイン認証を行ってもよい。
（２）−１： ログイン認証が成功すると、ユーザは、作成端末１０２に保持されたドキュメントの中からドキュメント管理システムに登録したい（そして他のユーザに配信したい）ドキュメントを選択し、処理装置１１０への登録を指示する。すると、処理装置１１０とのインタフェースとなるソフト（例えばデバイスドライバ）が起動し、ユーザからそのドキュメントについての属性データの入力を受け付け、受け付けた属性データとそのドキュメントのデータを処理装置１１０に送信する。
図９に、この属性データの入力画面４００の一例を示す。この入力画面４００は、配信先ユーザ選択メニュー４０２、配信先ユーザリスト欄４０４、配信先端末選択メニュー４０６、配信先端末リスト欄４０８、アクセス権限設定欄４１０、オフライン有効期間メニュー４１２、及びオプション設定呼出ボタン４１４を含む。
配信先ユーザ選択メニュー４０２は、そのドキュメントの配信先ユーザの選択肢を列挙するプルダウン形式のメニューである。選択肢となるユーザは処理装置１１０に登録されたユーザであり、選択肢となるそれらユーザのＩＤ及びユーザ名のリストは処理装置１１０から取得すればよい。あるいは、作成端末１０２が、組織に所属するドキュメント管理システムのユーザの情報を管理する後述のローカルユーザＩＤサーバ１５２（図１２参照）からユーザのリストを取得し、配信者が、組織内の他の処理装置１１０に登録されたユーザを配信先に選択できるようにしてもよい。この場合、配信先ユーザ選択メニュー４０２では、各ユーザを、各々が登録された処理装置１１０が区別可能な表示形態で表示する。例えば、ユーザを、そのユーザが登録された処理装置１１０毎に異なる色や字体で表示してもよい。あるいはそのメニューを階層構造とし、まず処理装置１１０を選んでその処理装置１１０に登録されたユーザのリストを呼び出し、そのリストの中から配信先のユーザを選ぶ態様としてもよい。配信先ユーザリスト欄４０４には、ユーザが選んだ配信先ユーザのリストが表示される。配信者が配信先ユーザ選択メニュー４０２で配信先ユーザを選び、右側にある「追加」ボタンを押下すると、その配信先ユーザのユーザＩＤ又はユーザ名が配信先ユーザリスト欄４０４に追加される。また、配信者が配信先ユーザリスト欄４０４内の配信先ユーザを選び、右側の「削除」ボタンを押下すると、その配信先ユーザが配信先ユーザリスト欄４０４から削除される（すなわち配信先ではなくなる）。
配信先端末選択メニュー４０６は、そのドキュメントの配信先とする閲覧端末（ビューワ）１０４の選択肢を列挙するプルダウン形式のメニューである。選択肢となる閲覧端末１０４は処理装置１１０に登録されたものであり、選択肢となるそれら閲覧端末１０４のＩＤ及び端末名のリストは処理装置１１０から取得すればよい。あるいは、処理装置１１０自身やローカルユーザＩＤサーバ１５２（図１２参照。詳細は後述）等がドキュメント管理システムに登録された組織内の閲覧端末１０４のリストを有しており、作成端末１０２が、そのリストを配信者に提示して、組織内の他の処理装置１１０に登録されたユーザの閲覧端末１０４を配信先に選択できるようにしてもよい。配信先ユーザリスト欄４０４には、配信先ユーザリスト欄４０４の場合と同様、配信者が配信先端末選択メニュー４０６で選んだ配信先の閲覧端末１０４のリストが表示される。
なお、配信先のユーザ毎にそのユーザに対応する配信先の閲覧端末１０４を指定できるようにしてもよい。これには作成端末１０２は、例えば、配信先ユーザリスト欄４０４で配信先のユーザが選択される毎に、処理装置１１０（あるいはローカルユーザＩＤサーバ１５２又はユーザＩＤサーバ２１０）からそのユーザの既定の閲覧端末のリストを取得し、そのリストを配信先端末選択メニュー４０６に設定すればよい。配信者が配信先のユーザに対する配信先の閲覧端末１０４を明示的に選択しなかった場合は、そのユーザの既定の閲覧端末のリスト中の特定のもの（例えばリストの先頭）が自動的に配信先の閲覧端末１０４に選択される。
アクセス権限設定欄４１０は、そのドキュメントに対する配信先ユーザのアクセス権限（利用権限）を設定するための欄である。図示例では、閲覧、加工（編集）、印刷、コピーの４つの権限項目についてのチェックボックスが示されており、配信者は、そのドキュメントについて配信先ユーザに許可する項目のチェックボックスにチェックを入れる。
オフライン有効期間メニュー４１２は、ドキュメントに対して設定するオフライン有効期間の長さの選択肢を示すプルダウンメニューである。配信者は、オフライン有効期間メニュー４１２に示される数段階のオフライン有効期間の中から、今回システムに登録して配信するドキュメントに対して設定する期間を選ぶ。
またオプション設定呼出ボタン４１４が押下されると、作成端末１０２は、図１０に例示するオプション設定画面４２０を表示する。オプション設定画面４２０は、処理装置指定欄４２２と元データ設定欄４２４を含む。処理装置指定欄４２２には、ドキュメントの送信先とする処理装置１１０の選択肢を示したプルダウンメニューが含まれる。このメニューには、作成端末１０２から選択可能な処理装置１１０のリストが含まれる。このリストに含まれる処理装置１１０は、まずその作成端末１０２が属するローカルシステム１００内にある処理装置１１０（基本は１つだが、複数あってもよい）である。また、同じ組織内の別のローカルシステム１００の処理装置１１０がそのリストに含まれていてもよい。元データ設定欄４２４には、ｅＤｏｃの元になった元データを処理装置１１０に保存するかの選択を受け付けるプルダウンメニューが表示される。
ステップ（２）−１で作成端末１０２から処理装置１１０に送られる属性データには、このような設定画面により設定された、配信先情報（ユーザのリスト及び閲覧端末のリスト）、アクセス権限情報、オフライン有効期間、元データ情報等の情報が含まれる。
図８の説明に戻る。
（２）−２： 処理装置１１０は、作成端末１０２からドキュメント（対象ドキュメントと呼ぶ）及び属性データを受信する。
（３）−１： 処理装置１１０は、ＤＩＤの発行権限及び発行枠を受け取っていない場合（あるいは受け取った発行枠を使い切った場合）は、管理システム２００のＤＩＤサーバ２２０に対して新たな発行権限及び発行枠を要求する。なお、受け取った発行枠に残りがある場合には、この要求を行わずに後述のステップ（４）に進む。
（３）−２： ＤＩＤサーバ２２０は、処理装置１１０からの要求に応じ、新たな発行権限及び発行枠をその処理装置１１０に送信する。
（４） 処理装置１１０は、ＤＩＤサーバ２２０から付与された発行権限を用いてＤＩＤを発行し、そのＤＩＤを対象ドキュメントから生成するｅＤｏｃ（次のステップで生成する）に付与する。
（５）−１： 処理装置１１０は、対象ドキュメントを暗号化するための暗号鍵を例えば乱数等を用いて生成する。また処理装置１１０は、対象ドキュメントをｅＤｏｃファイルへ変換する。すなわち、その対象ドキュメントをドキュメント管理システムの専用フォーマットへとエンコードし、エンコード結果を先ほど生成した暗号鍵で暗号化することでｅＤｏｃファイルを生成する。生成したｅＤｏｃファイルには先ほど生成したＤＩＤの情報を含める。
（５）−２： 処理装置１１０は、生成したｅＤｏｃのメタデータを生成する。すなわち、作成端末１０２から受信した属性データに対して、先ほど生成したＤＩＤ、エンコードの日時、当該処理装置１１０のＩＤ、暗号化情報等を追加することでメタデータを生成する（図３参照）。ここで、暗号化情報には、配信先ユーザのそれぞれについて、暗号化に用いた暗号鍵をその配信先ユーザの公開鍵で暗号化した鍵情報が含まれる。
（５）−３： 作成端末１０２から元データを保管する旨の指示を受け取った場合は、処理装置１１０は、作成端末１０２から受信したドキュメント（又はそのドキュメントの元になったアプリケーションデータ）を保存する。
（６）−１： 処理装置１１０は、先ほど生成したＤＩＤをＤＩＤサーバ２２０にアップロードする。ＤＩＤサーバ２２０は、処理装置１１０からアップロードされたＤＩＤを保管する。
（６）−２： 処理装置１１０は、先ほど生成したメタデータをメタデータサーバ２３０にアップロードする。メタデータサーバ２３０は、処理装置１１０からアップロードされてきたメタデータを保管する。
（７） 処理装置１１０は、生成したｅＤｏｃの配信先の各閲覧端末１０４に対して、そのｅＤｏｃについての配信準備完了通知を送信する。この通知には、先ほど生成したＤＩＤ、ｅＤｏｃのドキュメント名の情報を含む。また、この通知は、ｅＤｏｃの代表ページ（先頭ページ等の予め指定されたページ）のサムネイル画像を含んでいてもよい。
さて、閲覧端末１０４を利用するユーザ（閲覧者と呼ぶ）は、自分の認証デバイス１３０を閲覧端末１０４のカードリーダ部に近づけることで、ユーザ認証を受ける。閲覧端末１０４は、自身に配信されているｅＤｏｃのリストを表示するリスト画面を表示する。図１１にこのリスト画面５００の例を示す。この例のリスト画面５００には、ｅＤｏｃ毎に、通知マーク５０２、そのｅＤｏｃのドキュメント名５０４、閲覧可否マーク５０６が含まれる。通知マーク５０２は、そのｅＤｏｃの状態を閲覧者に通知するためのマークである。通知マーク５０２が表すｅＤｏｃの状態には、「新着」（処理装置１１０からドキュメントが配信された後、まだ開かれていない状態。図では「☆」印で示す）、「正常」（図では無印）、「期限切れ」（アクセス有効期間が過ぎている状態。図では「！」印で示す）等がある。「期限切れ」状態については、閲覧端末１０４内にｅＤｏｃファイルが保存されていても、そのｅＤｏｃについての最新のメタデータを処理装置１１０又は管理システム２００から取得するまでは、閲覧できない。「正常」状態のｅＤｏｃについては、その閲覧端末１０４内には、アクセス有効期間が切れていないメタデータが保存（キャッシュ）されているので、仮に閲覧端末１０４が処理装置１１０や管理システム２００に対してオフライン状態となっていても閲覧可能である。閲覧可否マーク５０６は、閲覧端末１０４及びこれを使用しているユーザ（認証デバイス１３０により認証）の組合せが、当該閲覧端末１０４にキャッシュされたそのｅＤｏｃのメタデータに示されるそのｅＤｏｃの配信先のユーザ及び閲覧端末１０４の組合せに合致するか否かを示す。合致すればそのｅＤｏｃは閲覧可能（図では「○」印）、合致しなければ閲覧不可（図では「×」印）である。また、配信準備完了通知は受け取ったがまだｅＤｏｃファイル及びメタデータを受信していないｅＤｏｃについては、閲覧端末１０４は配信先の組合せに合致するか否かの判断基準の情報を持たないので、閲覧可否マーク５０６は、未定であることを示す「−」印となる。図示例では、上から３つのｅＤｏｃは、新着のものであり、まだｅＤｏｃ本体（ファイル及びメタデータ）の取得が済んでいないので、閲覧可否マーク５０６は未定を表すマークとなっている。
閲覧者は、このリスト画面（図１１）上で、自分が閲覧したいｅＤｏｃを例えばタッチ操作等で選択し、閲覧指示を行う。ここでは、新着（通知マーク５０２が「☆」印）のｅＤｏｃが閲覧対象に選ばれたとする。
（８） 図８の説明に戻る。閲覧端末１０４は、選ばれた閲覧対象のｅＤｏｃファイル及びメタデータを保持していないので、処理装置１１０から取得する必要がある。そこで、閲覧端末１０４は、自身が接続されているローカルネットワーク１０８上の処理装置１１０に対して、その閲覧者の認証デバイス１３０から取得した認証情報であるユーザＩＤキーを自身が接続されているローカルネットワーク１０８上に処理装置１１０に対して送信する。処理装置１１０は、そのユーザＩＤキーが自身に登録されているユーザを証明するものであるか検証する（ユーザ認証）。ここでは、そのユーザ認証が成功したとする。なお、閲覧端末１０４から受信したユーザＩＤキーが処理装置１１０に登録されたいずれのユーザにも該当しなかった場合、処理装置１１０は、そのユーザＩＤキーをユーザ認証に関する上位装置（ユーザＩＤサーバ２１０又はローカルユーザＩＤサーバ１５２）に送り、ユーザ認証を依頼してもよい。
（９）−１： また閲覧端末１０４は、処理装置１１０でのユーザ認証が成功したのを受けて、閲覧者が選択した閲覧対象のｅＤｏｃのＤＩＤを含む配信要求を処理装置１１０に送る。
（９）−２： 処理装置１１０は、閲覧端末１０４からの配信要求に含まれるＤＩＤに対応するｅＤｏｃファイル及びメタデータを、閲覧端末１０４に返信する。
（１０） 閲覧端末１０４は、処理装置１１０から送られてきたｅＤｏｃファイル及びメタデータを受信して保存（キャッシュ）する。
（１１） 閲覧端末１０４は、自身と、自身を現在使用中の閲覧者との組合せと一致する組合せが、そのメタデータ中の配信先情報（図３参照）に示される配信先ユーザと配信先端末の組合せの中にあるかどうかを判定する。ないと判定した場合は、閲覧者はその閲覧端末１０４ではそのｅＤｏｃファイルを閲覧できない。この場合、閲覧端末１０４は、閲覧できない旨を示すエラーメッセージを表示する。またこの場合、閲覧端末１０４は、保存しているそのｅＤｏｃのファイル（及び対応するメタデータ）を削除してもよい。一方、閲覧端末１０４とそれを現在使用中の閲覧者との組合せに該当するものがメタデータ中の配信者情報内にあると判定した場合、閲覧端末１０４は、閲覧者に対してｅＤｏｃの閲覧を許可する。この場合、閲覧端末１０４は、そのメタデータ内の暗号化情報に含まれる各配信先ユーザに対応する暗号化済みの鍵の中から閲覧者に対応するものを取り出し、その鍵を閲覧者の秘密鍵（これは例えば認証デバイス１３０が保持している）で復号することで、ｅＤｏｃファイルの復号に必要な復号鍵を復元する。
（１２） 閲覧端末１０４は、復元した復号鍵を用いてそのｅＤｏｃファイルを復号することで閲覧可能なドキュメントを再生し、そのドキュメントを出力（例えば画面表示）する。また、閲覧端末１０４は、閲覧者からそのドキュメントに対する操作指示を受け付けるかどうかを、メタデータに含まれるアクセス権限情報に従って制御する。閲覧端末１０４は、基本的には、復号したドキュメントをファイルに保存することはしない。すなわち、閲覧終了後は、閲覧端末１０４の不揮発性記憶装置には、ｅＤｏｃファイルとメタデータが保存されるが、復号結果のドキュメントは保存されない。
次に、図１２を参照して、ドキュメント管理システムの別の例を説明する。図１２に示す例では、企業等の組織のプライベートネットワークである組織内ネットワーク内にローカルシステム１００が複数存在する。そして、組織内ネットワークには、組織内管理システム１５０が設けられている。組織内管理システム１５０は、ドキュメント管理システムのうち当該組織内の処理やそれに必要な情報を管理する。すなわち、管理システム２００は、ドキュメント管理システムのサービスプロバイダが運用し、ドキュメント管理システムを利用する複数の組織についての情報や処理を管理するのに対し、組織内管理システム１５０はそれら情報や処理のうち当該組織に関する部分を、管理システム２００の管理下で管理する。
組織内管理システム１５０は、ローカルユーザＩＤサーバ１５２、ローカルＤＩＤサーバ１５４、及びローカルメタデータサーバ１５６を有する。
ローカルユーザＩＤサーバ１５２は、当該組織のメンバのうちドキュメント管理システムにユーザ登録されているユーザの情報を管理する。ローカルユーザＩＤサーバ１５２が保持する個々のユーザの情報は、図４に記載したユーザＩＤサーバ２１０が保持する一般ユーザの情報と同様である。処理装置１１０に対して、その処理装置１１０を取得し利用するユーザ（すなわちその処理装置１１０を「既定の処理装置」とするユーザ）が登録されると、処理装置１１０は登録されたユーザの情報を組織内のローカルユーザＩＤサーバ１５２に送る。ローカルユーザＩＤサーバ１５２は、受け取ったユーザの情報を保存すると共に、広域ネットワーク１０経由で中央の管理システム２００のユーザＩＤサーバ２１０に送る。ユーザＩＤサーバ２１０は、受け取ったユーザの情報を保管する。又、処理装置１１０に登録されたユーザの情報に変更が生じた場合、管理者等が処理装置１１０に対してそのユーザの情報の変更を行う。処理装置１１０は、このユーザ情報の変更内容の情報（例えばユーザＩＤと、変更された情報項目の項目名と、その項目の変更後の値とを含む）をローカルユーザＩＤサーバ１５２に送信し、ローカルユーザＩＤサーバ１５２は、受信した変更に内容に応じて自身が保管している当該ユーザの情報を変更する。また、ローカルユーザＩＤサーバ１５２は、受け取った変更内容の情報を中央のユーザＩＤサーバ２１０に送り、ユーザＩＤサーバ２１０は送られてきた情報に応じて、自分が保持するそのユーザの情報を変更する。
ローカルＤＩＤサーバ１５４は、当該組織の組織内ネットワークに属する各ローカルシステム１００内の処理装置１１０が発行したＤＩＤを受け取り、保管する。ローカルＤＩＤサーバ１５４が保持する情報は、図５に記載したＤＩＤサーバ２２０が保持する情報と同様である。またローカルＤＩＤサーバ１５４は、処理装置１１０から受け取ったＤＩＤの情報を中央のＤＩＤサーバ２２０に送り、ＤＩＤサーバ２２０はその情報を保管する。また、ローカルＤＩＤサーバ１５４は、中央のＤＩＤサーバ２２０からＤＩＤの発行権限及び発行枠を付与され、その発行枠の範囲内で、その発行権限に基づいて管理下の各処理装置１１０に対してＤＩＤの発行権限及び発行枠を付与する。
ローカルメタデータサーバ１５６は、当該組織の組織内ネットワークに属する各ローカルシステム１００内の処理装置１１０が生成したｅＤｏｃのメタデータを受け取り、保管する。ローカルメタデータサーバ１５６が保持する情報は、メタデータサーバ２３０が保持する情報と同様である。またローカルメタデータサーバ１５６は、処理装置１１０から受け取ったメタデータを中央のメタデータサーバ２３０に送り、メタデータサーバ２３０はそのメタデータを保管する。
図１２のシステムでは、処理装置１１０は、自分には登録されていないが同じ組織内の他の処理装置１１０に登録されているユーザからのドキュメントの登録（及び配信）要求、又はｅＤｏｃファイル又はメタデータの取得要求等の要求を受けた場合、組織内管理システム１５０を介してそれら要求に応答する。
１つの例として、組織内ネットワーク内の第１の部署にある第１のローカルシステム１００内の処理装置＃１に登録されている閲覧者が、その処理装置＃１に登録され配信されたｅＤｏｃを自分の閲覧端末１０４に保存し、その後処理装置＃２の管理下にある第２の部署に移動してそのｅＤｏｃを閲覧しようとしたときのことを考える。この時点では、その閲覧端末１０４内に保存されたそのｅＤｏｃのメタデータは古くなっている（すなわちアクセス有効期間が過ぎている）ものとする。この場合、閲覧者がその閲覧端末１０４でそのｅＤｏｃを開く操作を行った場合、図１３に示す処理が行われる。
まず、閲覧端末１０４は、自身が今接続している第２のローカルシステム１００のローカルネットワーク１０８から処理装置１１０を探す。これにより処理装置＃２が見つかる。この処理装置＃２は、そのｅＤｏｃを配信した処理装置＃１とは別の装置なので、そのｅＤｏｃファイルやメタデータは持っていない。
（１） 閲覧端末１０４は、閲覧者の認証デバイス１３０からユーザＩＤキー（認証情報）を読み込む。
（２） 閲覧端末１０４は、閲覧の対象として指示されたそのｅＤｏｃの最新のメタデータを取得するためのユーザ認証のために、その処理装置＃２に対して、認証デバイス１３０から取得したユーザＩＤキーを送信する。
（３） 閲覧端末１０４は、そのｅＤｏｃのメタデータを処理装置＃２に要求する。この要求には、そのｅＤｏｃのＤＩＤが含まれる。
（４）−１： 処理装置＃２は、閲覧端末１０４から受け取ったユーザＩＤキーが自身に登録されたユーザのものかどうかを調べる（ユーザ認証）。この例では、その閲覧者は処理装置＃１に登録されており、処理装置＃２には登録されていないので、処理装置＃２は、予め設定されているローカルユーザＩＤサーバ１５２のアドレスに対して、そのユーザＩＤキーを含む認証要求を送る。また、処理装置＃２は、閲覧端末１０４からのメタデータ要求に含まれるＤＩＤを、予め設定されているローカルＤＩＤサーバ１５４に送り、認証を求める。
（４）−２： ローカルユーザＩＤサーバ１５２は、処理装置＃２から受け取ったユーザＩＤキーが、自身に登録されているユーザのものであるかどうかを検証する（ユーザ認証）。そのユーザＩＤキーの持ち主である閲覧者は、処理装置＃１に登録されているので、その上位装置であるローカルユーザＩＤサーバ１５２にもユーザ登録がなされている。したがって、このユーザ認証は成功する。ローカルユーザＩＤサーバ１５２は、認証が成功したことを示す応答を処理装置＃２に返す。
またローカルＤＩＤサーバ１５４は、閲覧端末１０４から送られてきた検証対象のＤＩＤが正当なＤＩＤであるかどうか、すなわち自身が保存しているＤＩＤであるかどうかを調べる。この例では、そのｅＤｏｃのＤＩＤは、処理装置＃１が発行したものであり、処理装置＃１のＤＩＤに関する上位装置であるローカルＤＩＤサーバ１５４にも保存されている。したがって、そのＤＩＤは正当なものであると認証される。ローカルＤＩＤサーバ１５４は、ＤＩＤが正当であると認証する旨の応答を処理装置＃２に返す。
（５）−１： ユーザ認証及びＤＩＤ認証が成功したので、処理装置＃２は、閲覧端末１０４からのメタデータ要求に応えるための処理を続行する。すなわち、処理装置＃２は、ＤＩＤを含むメタデータ要求を、あらかじめ設定されているローカルメタデータサーバ１５６のアドレスに送る。
（５）−２： ローカルメタデータサーバ１５６は、処理装置＃２からメタデータ要求を受けると、その要求に含まれるＤＩＤに対応するメタデータを処理装置＃２に返す。ｅＤｏｃのメタデータは、配信者から処理装置１１０にて変更されると、その変更が即座にローカルメタデータサーバ１５６に反映されるので、このとき処理装置＃２に返されるメタデータは、閲覧対象のｅＤｏｃのメタデータの最新版である。
（６） 処理装置＃２は、ローカルメタデータサーバ１５６から受け取ったメタデータを、閲覧端末１０４に対して送信する。
（７） 閲覧端末１０４は、処理装置＃２からメタデータを受信し、保存（キャッシュ）する。
（８） 閲覧端末１０４は、受け取った最新のメタデータの配信先情報を参照し、閲覧端末１０４及び閲覧者の組合せの権限チェックを行う。すなわち、閲覧端末１０４自身と閲覧者との組合せと一致する組合せが、その配信先情報（図３参照）に示される配信先ユーザと配信先端末の組合せの中にあれば、閲覧権限ありと判定し、なければ閲覧権限なしと判定する。閲覧権限なしと判定した場合、閲覧端末１０４はエラー表示を行う。閲覧権限ありと判定した場合、閲覧端末１０４は、そのメタデータ内の暗号化情報に含まれる各配信先ユーザに対応する暗号化済みの鍵の中から閲覧者に対応するものを取り出し、その鍵を閲覧者の秘密鍵（これは例えば認証デバイス１３０が保持している）で復号することで、ｅＤｏｃファイルの復号に必要な復号鍵を復元する。
（９） そして閲覧端末１０４は、復元した復号鍵を用いてそのｅＤｏｃファイルを復号することで閲覧可能なドキュメントを再生し、そのドキュメントを出力（例えば画面表示）する。そして、閲覧者からそのドキュメントに対する操作指示を受け付けるかどうかを、メタデータに含まれるアクセス権限情報に従って制御する。
次に、図１４を参照して、第１のローカルシステム１００内の処理装置＃１に登録されているユーザが、処理装置＃２の管理下にある第２の部署でドキュメントをドキュメント管理システムに登録する場合の処理の流れを考える。そのユーザ（ドキュメントの配信者）は、処理装置＃２には登録されていないとする。
（１） ユーザは、自分の作成端末１０２にドキュメントの登録を指示すると、作成端末１０２はログイン認証情報の入力を求める画面を表示する。配信者がその求めに応じて認証情報（例えばユーザＩＤ及びパスワード）を入力すると、作成端末１０２は、その認証情報をローカルネットワーク１０８経由で処理装置１１０に送信する。
（２） 処理装置＃２は、作成端末１０２から受け取った認証情報が自身に登録されたユーザのものであるか判定する。この場合、配信者は処理装置＃２に登録されていない。この場合、処理装置＃２は、上位のローカルユーザＩＤサーバ１５２に対してその認証情報を送り、認証を求める。
（３） ローカルユーザＩＤサーバ１５２は、受け取った認証情報が自身に登録されているユーザのものかどうか判定する（ユーザ認証）。この例では、配信者は処理装置＃１に登録されているユーザなので、ローカルユーザＩＤサーバ１５２にも登録されており、このユーザ認証は成功する。ローカルユーザＩＤサーバ１５２は、処理装置＃２に対して、ユーザ認証が成功したことを示す情報を返す。
（４） 処理装置＃２は、ローカルユーザＩＤサーバ１５２から認証成功の旨の応答を受けると、作成端末１０２に対してユーザ認証が成功した旨を応答する。
（５） 作成端末１０２は、ユーザ認証が成功した場合、ユーザが登録対象に選択したドキュメントと、ユーザが入力した属性データとを処理装置＃２に送る。
（６） 処理装置＃２は、作成端末１０２からドキュメント及び属性データを受信する。
（７）−１： 処理装置＃２は、ＤＩＤの発行権限及び発行枠を使い切った場合は、ローカルＤＩＤサーバ１５４に対して新たな発行権限及び発行枠を要求する。なお、受け取った発行枠に残りがある場合には、この要求を行わずに後述のステップ（８）に進む。
（７）−２： ローカルＤＩＤサーバ１５４は、処理装置＃２からの要求に応じ、新たな発行権限及び発行枠をその処理装置＃２に付与する。なお、中央のＤＩＤサーバ２２０から付与された発行枠を使い切った場合、ローカルＤＩＤサーバ１５４は、ＤＩＤサーバ２２０に新たな発行権限及び発行枠を要求し、これに応じて付与された発行権限及び発行枠を用いて、処理装置＃２にＤＩＤの発行権及び発行枠を付与する。
（８） 処理装置＃２は、付与された発行権限を用いてＤＩＤを発行し、そのＤＩＤを対象ドキュメントから生成するｅＤｏｃ（次のステップで生成する）に付与する。
（９）−１： 処理装置＃２は、対象ドキュメントを暗号化するための暗号鍵を生成し、対象ドキュメントを本システムの専用フォーマットへとエンコードし、エンコード結果を先ほど生成した暗号鍵で暗号化することでｅＤｏｃファイルを生成する。
（９）−２： 処理装置＃２は、作成端末１０２から受信した属性データに対して、先ほど生成したＤＩＤ、エンコードの日時等の項目を追加することで、ｅＤｏｃのメタデータを生成する。
（１０） 処理装置＃２は、生成したＤＩＤをローカルＤＩＤサーバ１５４に、生成したメタデータをローカルメタデータサーバ１５６に、それぞれアップロードする。ローカルＤＩＤサーバ１５４は、処理装置＃２からアップロードされたＤＩＤを、その中に含まれる発行権限キーに対応する発行済ＤＩＤリスト（図５参照）に追加すると共に、中央のＤＩＤサーバ２２０にアップロードする。ＤＩＤサーバ２２０は、ローカルＤＩＤサーバ１５４からアップロードされたＤＩＤを、発行権限キーに対応する発行済ＤＩＤリスト（図５参照）に追加する。またローカルメタデータサーバ１５６は、処理装置＃２からアップロードされたメタデータを保管すると共に、中央のメタデータサーバ２３０にアップロードする。メタデータサーバ２３０は、ローカルメタデータサーバ１５６からアップロードされたメタデータを保管する。
処理装置＃２は、生成したｅＤｏｃを配信者の指定した配信先に配信する。この処理は、図８のステップ（７）乃至（１２）と同様である。
（１１） また処理装置＃２は、生成したｅＤｏｃファイル及びメタデータを作成端末１０２に送信する。処理装置＃２は、そのｅＤｏｃファイル及びメタデータを保存してもよいし、保存せずに削除してもよい。保存せずに削除する場合、それらｅＤｏｃファイル及びメタデータは、組織内の処理装置１１０群のうち、後述するステップ（１３）により既定の処理装置である処理装置＃１のみに保存されることになる。配信者の既定の処理装置でない処理装置１１０がその配信者から登録・配信依頼されたｅＤｏｃファイル及びメタデータを保存するか否かは、処理装置１１０に設定可能としてもよい。
（１２） 作成端末１０２は、処理装置１１０から受け取ったｅＤｏｃファイル及びメタデータを、後でその配信者の既定の処理装置である処理装置＃１に転送するために保存する。
（１３） 配信者は、作成端末１０２を持って自分の所属する第１の部署に戻った際、作成端末１０２は、第１のローカルネットワーク１０８上でその配信者の既定の処理装置である処理装置＃１を探す。処理装置＃１を見つけると、作成端末１０２は、上記ステップ（１２）で保存していたｅＤｏｃファイル及びメタデータを処理装置＃１に登録する。これにより、配信者は、メタデータの内容（例えば配信先）を変更したい場合には、既定の処理装置＃１にアクセスしてその変更の操作を行えばよい。
以上に説明したドキュメント管理システムでは、作成端末１０２から処理装置１１０に配信を指示したドキュメントの本体情報（すなわちｅＤｏｃファイル）は、処理装置１１０と配信先の閲覧端末１０４が持つのみで、その他のネットワークや装置には出回らない。このためｅＤｏｃファイルの漏洩リスクが極小化される。特にｅＤｏｃファイルの配信先を、そのｅＤｏｃを生成したローカルネットワーク１０８上の閲覧端末１０４に限定すれば、ｅＤｏｃはそのローカルネットワーク１０８から外に一切出ないことになる。
一方、ｅＤｏｃのメタデータは、中央の管理システム２００や組織毎の組織内管理システム１５０に登録されており、閲覧端末１０４がいろいろな場所に移動しても、広域ネットワーク１０や組織のプライベートネットワークを介して入手可能となっている。閲覧端末１０４は、ｅＤｏｃの閲覧指示をユーザから受けた場合、そのｅＤｏｃの最新のメタデータを組織内管理システム１５０又は中央の管理システム２００から取得し、その最新のメタデータに含まれる配信先情報に基づき、そのユーザにそのｅＤｏｃの閲覧を許可してよいかどうかを判定する。そのユーザが、そのｅＤｏｃの登録・配信時には配信先に指定されていても、その後の配信先変更で配信先から外れている場合には、閲覧は許可されない。
図１３及び図１４の例では、処理装置＃１及び処理装置＃２は共に同じ組織内に設置されたものであり、配信先のユーザもその組織に所属していると想定しているので、ユーザ認証はその組織のローカルユーザＩＤサーバ１５２で行った。これに対し、閲覧者が処理装置＃２とは異なる組織に属するユーザの場合、処理装置＃２でもその上位のローカルユーザＩＤサーバ１５２でもその配信者を認証できない。この場合、更に上位のユーザＩＤサーバ２１０がその配信者のユーザ認証を行ってもよい。
図１３及び図１４の例では、別の処理装置＃２が、処理装置＃１に登録されたユーザの閲覧端末１０４と、ローカルユーザＩＤサーバ１５２やローカルメタデータサーバ１５６とのやりとりの仲立ちをした。しかし、これは一例に過ぎない。この代わりに、例えば、処理装置＃２は、閲覧端末１０４から送られてきたユーザの認証情報からそのユーザが処理装置＃２に登録されたものでない場合、閲覧端末１０４に対して認証不可の応答を行えばよい。この場合、閲覧端末１０４は、自機に登録されている上位装置のアドレス情報を用いて、ローカルユーザＩＤサーバ１５２に認証を求め、認証が成功すると、ローカルメタデータサーバ１５６にアクセスして必要なメタデータを取得する。
図１３の例は、ユーザは自分の所属する組織内の、自分の既定の処理装置とは別の処理装置１１０の管理下にあるローカルシステム１００に移動してドキュメントの閲覧を行う場合の例であった。しかしながら、ユーザが、自分の所属する組織の外で、自分の既定の処理装置から配信されたドキュメントを閲覧できるようにしてもよい。この場合、ユーザの閲覧端末１０４は、中央の管理システム２００内のユーザＩＤサーバ２１０で認証を受け、閲覧したいドキュメントのメタデータをメタデータサーバ２３０から取得する。
＜ＤＩＤの例＞
次に、図１５を参照して、ドキュメント管理システムでｅＤｏｃの識別情報に用いるＤＩＤ６００の構成について説明する。
図示のようにＤＩＤ６００は、発行権限キー６０２、処理装置固有情報６０４、発行年月日６０６、発行証明キー６０８、及び発行番号６１０を含む。なお、図示のＤＩＤ６００及びその構成要素６０２〜６１０の桁数はあくまで例示的なものにすぎない。
発行権限キー６０２は、ＤＩＤサーバ２２０が処理装置１１０に付与した発行権限を識別するキー情報である。ＤＩＤサーバ２２０は、処理装置１１０から発行権限及び発行枠の要求を受けた場合、発行権限キー６０２を生成し、その発行権限キー６０２を発行枠（例えばドキュメント数１００個）の数値と共に処理装置１１０に送信する。なお、ＤＩＤサーバ２２０と処理装置１１０との間にローカルＤＩＤサーバ１５４が介在するシステム構成の場合には、ＤＩＤサーバ２２０がローカルＤＩＤサーバ１５４に対して、例えば、発行権限キーと発行枠の組を複数組一括して付与する。この付与は、ＤＩＤサーバ２２０が、それら複数組の発行権限キー及び発行枠を処理装置１１０に付与する処理をローカルＤＩＤサーバ１５４に依頼することと捉えてもよい。ローカルＤＩＤサーバ１５４は、管理下の処理装置１１０から発行権限を要求された場合、付与された複数組の発行権限キー及び発行枠の中の未付与のものをその処理装置１１０に付与すればよい。
処理装置固有情報６０４は、そのＤＩＤを発行した処理装置１１０に固有な情報である。すなわち、ＤＩＤ６００中の処理装置固有情報６０４を調べることで、そのＤＩＤ６００を発行した処理装置１１０が一意に特定できる。処理装置固有情報６０４は、処理装置１１０が保持している。
発行年月日６０６は、そのＤＩＤを発行した年月日を示す文字列である。ＤＩＤの発行年月日は、そのＤＩＤの付与先であるｅＤｏｃを生成（エンコード）した年月日でもある。
発行証明キー６０８は、その処理装置１１０（処理装置固有情報６０４により特定される）が、発行権限キー６０２が示す発行権限を用いてそのＤＩＤを発行したことを証明するキー情報である。発行証明キー６０８は、例えば、発行権限キー６０２をその処理装置１１０の秘密鍵で暗号化することで得られる値である。この場合、発行証明キー６０８をその処理装置１１０の公開鍵で復号して得られた値が、発行権限キー６０２に一致すれば、そのＤＩＤ６００は、その発行権限キー６０２を用いてその処理装置１１０が発行したものであることが証明される。また、ＤＩＤ６００のうち発行権限キー６０２を除く部分の値（又はその値から生成した所定桁数のハッシュ値）を処理装置１１０の秘密鍵で暗号化して得た値を発行証明キー６０８としてもよい。この場合、発行証明キー６０８を処理装置１１０の公開鍵で復号した値が、ＤＩＤ６００の発行証明キー６０８を除いた部分の値と矛盾しなければ（例えば復号結果がその値のハッシュ値と一致）、そのＤＩＤ６００は発行権限キー６０２に基づきその処理装置１１０が発行したものであり、ＤＩＤ６００の発行証明キー６０８以外の部分に改ざんがないことが証明される。
発行番号６１０は、そのＤＩＤ６００が、処理装置１１０がその発行権限キー６０２を用いて発行した何番目のＤＩＤであるかを示す通し番号である。ある発行権限キー６０２を用いて生成されたＤＩＤ６００の発行番号６１０が取り得る最大値は、その発行権限キー６０２と共にＤＩＤサーバ２２０（又はローカルＤＩＤサーバ１５４）が付与した発行枠の値（ドキュメント数）である。
＜登録後の配信先変更＞
さて、ｅＤｏｃをドキュメント管理システムに登録した後、配信者（あるいは配信先の変更権限を与えられた他の者）が、配信先の削除や追加、それら配信先に与えたｅＤｏｃへのアクセス権限を修正したくなることも考えられる。そのような場合、配信者は、作成端末１０２又は閲覧端末１０４（以下ユーザ端末と総称）を用いて例えば既定の処理装置１１０にアクセスし、対象となるｅＤｏｃのＤＩＤを指定して、配信先（又はアクセス権限）の編集処理の実行を指示する。
この指示を受けた処理装置１１０は、ユーザ認証によりその指示を発したユーザがその対象ｅＤｏｃの正しい配信者等（配信者及び配信先変更権限を与えられた他の者の総称）であることを確認した場合、配信先及びアクセス権限の編集画面をユーザ端末に提供する。編集画面は、図９に示した入力画面４００と同様のものでよい。配信者等は、その編集画面上で、配信先のユーザ及び閲覧端末の追加や削除、アクセス権限内容の変更を行う。配信者等が、編集画面上で必要な変更を行った後、その変更を確定する操作を行うと、処理装置１１０は、保存しているそのｅＤｏｃのメタデータにその変更を反映させると共に、その変更内容を上位のローカルメタデータサーバ１５６及びメタデータサーバ２３０に通知する。ローカルメタデータサーバ１５６及びメタデータサーバ２３０は、通知された変更内容を、保存しているそのｅＤｏｃのメタデータに反映させる。例えば、配信時には配信先に指定されていたユーザであっても、その後の変更で配信先から削除された場合、そのｅＤｏｃの閲覧が不可となる。また、処理装置１１０は、このようにｅＤｏｃのメタデータ中の配信先情報が変更された場合、変更前の配信先情報には含まれていたが、変更後の配信先情報には含まれていない配信先の閲覧端末１０４に対して、そのｅＤｏｃファイル（及び対応するメタデータ）を削除する指示を送ってもよい。
以上の例では、処理装置１１０がｅＤｏｃの配信先やアクセス権限の変更指示を受け付けたが、この代わりに又はこれに加えて、上位装置、すなわち管理システム２００（メタデータサーバ２３０）又は組織内管理システム１５０（ローカルメタデータサーバ１５６）がその変更指示を受けてもよい。この場合、上位装置は、そのｅＤｏｃを生成した処理装置１１０（及びその処理装置１１０が属する組織のローカルメタデータサーバ１５６）に対して、その変更指示に応じて変更された新たなメタデータを送信し、処理装置１１０内の既存のメタデータと置き換えさせるようにする。
＜処理装置のステータス管理＞
次に、処理装置１１０のステータス管理に基づく制御について説明する。
処理装置１１０は、定期的に自身のステータスを管理システム２００に通知する。管理システム２００では、処理装置管理サーバ２４０が、受け取ったステータスを、その受け取りの日時と対応付けて当該処理装置１１０についてのステータス履歴２４２に追加する。また処理装置管理サーバ２４０は、受け取ったステータスについてチェックを行い、そのチェックの結果に従って、処理装置１１０のユーザに対するサービス提供の可・不可を制御する。
処理装置１１０が処理装置管理サーバ２４０に定期送信するステータスは、図６に例示した処理装置のステータス２４４と同様の項目を含む（ただし、ステータス２４４のうち処理装置１１０によっては変更されることがない設置場所やエンコード回路情報、処理装置の製造者名等は定期送信しなくてよい）。
処理装置管理サーバ２４０は、処理装置１１０から送られてくるステータスに基づき、例えば図１６に例示する処理を実行する。
まず、処理装置管理サーバ２４０は、処理装置１１０からステータスを受信すると（Ｓ１００）、そのステータスのうちの検査対象項目の値を、それぞれの項目の基準と照合する（Ｓ１０２）。検査対象項目には、暗号化ソフトの名称及びバージョン、エンコードソフトの名称及びバージョン、処理装置１１０にインストールされているセキュリティ証明書、処理装置１１０にインストールされている暗号鍵（例えば秘密鍵と公開鍵ペア。通信路暗号化や署名的な目的等に用いる）の情報（例えば当該鍵の識別情報やインストール日時等）、エンコード回路の名称及びファームウエア（ＦＷ）のバージョン、搭載フォント種類、ディスク（二次記憶）の空き容量、が含まれる。また、個々の項目についての基準の例としては、暗号化ソフトやエンコードソフト、ファームウエアが最新バージョンであること（あるいはあるバージョン以降のバージョンであること）、ディスクの空き容量が所定の閾値以上であること、インストールされているセキュリティ証明書の中にブラックリストに入っている証明書がないこと、処理装置１１０の暗号鍵がインストールされた日から所定期間が経過していないこと、所定（すなわちあらかじめ定めた）種類のフォントがインストールされていること、などがある。
例えば、処理装置１１０が通信路暗号化や署名等に用いる暗号鍵は、その安全性を維持するために、定期的に新しい鍵に変更することが望ましいので、インストール日時から所定期間が経過した以降は基準を満たさないものと判定してサービス提供を不可とし（あるいは不可となる旨の警告を発し）、新しい鍵への交換を促す。
次に処理装置管理サーバ２４０は、処理装置１１０から受け取ったステータスの検査対象項目の中に、当該項目の基準を満たさないものがあるかどうかを判定し（Ｓ１０４）、なければ今回ステータスを受信した処理装置１１０についての処理を終了する。Ｓ１０４で基準を満たさない項目があった場合、処理装置管理サーバ２４０は、その処理装置１１０に対してサービス不可を通知する（Ｓ１０６）。この通知を受けた処理装置１１０は、本実施形態のドキュメント管理システムに対するドキュメントの登録（配信）サービスを停止する。すなわち、作成端末１０２からのドキュメントの登録（配信）要求を受け付けず、サービス停止中である旨のメッセージを返す。
このような制御によれば、処理装置１１０が基準を満たさない品質のｅＤｏｃを生成してしまう可能性が低減される。例えば、この制御によれば、古い暗号化ソフトにより暗号化の強度が十分でないｅＤｏｃが生成される前に、その処理装置１１０のサービスが停止される。また、ディスク空き容量が少なかったりファームウエアが古かったりしてｅＤｏｃの生成処理にエラーが生じ、それが元でドキュメントの漏洩が生じるといった事態が起こる前に、サービスが停止される。また、所定のフォントを持たない処理装置１１０がドキュメント中のそのフォントを別のフォントに置き換えてエンコードしてしまうことによるｅＤｏｃの画質低下が起こる前に、サービスが停止される。エンコード回路のファームウエアが古いため、最新のファームウエアがサポートしているドキュメントの画像サイズがサポートされておらず、ｅＤｏｃの画像サイズが制限されてしまう等の事態も生じにくくなる。
なお、ステータスの検査対象項目に、ｅＤｏｃのセキュリティに影響する項目とそうでない項目の分類を設け、処理装置１１０にサービスを停止させるのは、前者の項目が基準を満たさない場合に限ってもよい。後者の項目が基準を満たさない場合は、処理装置１１０やその管理者に警告を送り、その項目についての不具合を解消するよう促す。この警告を受けて、処理装置１１０の管理者は、自分で対処できる項目については処理装置１１０の修理を行い、専門の保守作業員の介入が必要な項目については、保守作業員の派遣をシステム運営者に依頼する。また、検査対象項目のうちの特定項目が基準を満たさないことが分かった場合に、処理装置管理サーバ２４０が、当該処理装置１１０に対して保守作業員を派遣する手配を自動的に行ってもよい。
図１６の処理の変形例を、図１７を参照して説明する。
図１７の手順では、処理装置１１０のステータスの検査対象項目に、緊急項目とそれ以外というレベル分けを導入している。緊急項目は、処理装置１１０が生成するｅＤｏｃのセキュリティ上の品質やドキュメント管理システムのセキュリティに大きな影響を与える項目である。その項目が基準を満たさない処理装置１１０が生成したｅＤｏｃは十分な安全性が確保されないか、またはその項目が基準を満たさない処理装置１１０が稼働を続けると、その処理装置１１０がドキュメント管理システムのセキュリティホール（脆弱性）となってしまう可能性がある。そのような緊急項目の対象の例としては、暗号化ソフトのバージョン、処理装置１１０にインストールされているセキュリティ証明書、処理装置１１０にインストールされている暗号鍵に脆弱性が見つかった場合等がある。
緊急項目が基準を満たさないことによる問題を避ける１つの方法は、緊急項目が基準を満たさない処理装置１１０を停止させ、保守作業員を派遣してその緊急項目についての修正・修理を行わせることである。しかし、修正が完了するまでの間、ユーザはその処理装置１１０を使えないという不便がある。
そこで、図１７の手順では、処理装置管理サーバ２４０は、Ｓ１０４で基準を満たさない項目を見つけた場合、その項目が緊急項目であるかどうかを判定する（Ｓ１１０）。そして、緊急項目である場合、その緊急項目の不具合を修正するための設定情報を処理装置管理サーバ２４０からその処理装置１１０に対して、広域ネットワーク１０を経由してリモートインストールする（Ｓ１１２）。緊急項目の不具合を修正するための設定情報の例としては、最新バージョンの暗号化ソフト、脆弱性が見つかったセキュリティ証明書に対する脆弱性が解消された最新版のセキュリティ証明書、処理装置１１０の脆弱性が見つかった秘密鍵・公開鍵のペアを置き換える新たな鍵ペア、等がある。
例えば新たな鍵ペアの場合、その新たな鍵ペアを生成するためのフレーズを処理装置管理サーバ２４０が用意してそのフレーズを用いて鍵ペアを生成し、生成した鍵ペアをセキュアな方法で処理装置１１０に伝送してリモートインストールする。
これにより処理装置１１０内の基準を満たさない緊急項目についての設定情報が基準を満たすものへと更新される。またこの更新に応じて、その処理装置１１０が持つステータスのうちのその緊急項目の値が更新される。
またＳ１１０の判定結果がＮｏ（緊急項目に該当しない）の場合、処理装置管理サーバ２４０は、処理装置１１０又は管理者に対して基準を満たさない項目を示す警告を送り、その処理装置１１０のその項目についての修正のために保守作業員の派遣の手配を行う（Ｓ１１４）。緊急項目でない項目については、処理装置１１０がそのまま稼働を続けてもセキュリティ上の重大な問題は生じにくいので、処理装置１１０は停止させず、保守作業員の派遣により対処するのである。緊急項目以外の項目については、処理装置管理サーバ２４０がリモートインストールしなくてよいので、処理装置管理サーバ２４０の負荷増大が避けられる。
図１７の例では、緊急項目についての設定情報を処理装置管理サーバ２４０からトップダウンで処理装置１１０にインストールし、これに応じて処理装置１１０にてその設定情報がインストールされ、処理装置１１０のステータスのうちその緊急項目の値が更新される。これに対して、緊急項目以外のステータスの項目については、個々の処理装置１１０にて、例えば保守作業員により値の設定や変更を行い、その項目に対応する設定情報（例えば暗号化ソフトの最新バージョン）のインストールを行う。このように処理装置１１０で行われたステータス項目値の設定や変更は、上位の処理装置管理サーバ２４０に通知され、処理装置管理サーバ２４０は、その通知に応じて自身が持つその処理装置１１０のステータスの対応項目の値を変更する。
＜ＤＩＤの検証＞
管理システム２００は、処理装置１１０が発行したＤＩＤを通知してきた際や、閲覧端末１０４からメタデータの要求（この要求はＤＩＤを含む）を送ってきた際、あるいはＤＩＤの検証の依頼をユーザ等から受けた際に、そのＤＩＤが正しいものかどうかを検証する。
この場合ＤＩＤサーバ２２０は、対象のＤＩＤ６００（図１５参照）について以下の点を検証する。
（ａ）ＤＩＤ６００中の発行権限キー６０２と処理装置固有情報６０４との間に矛盾がないこと。
ＤＩＤサーバ２２０は、その発行権限キー６０２が、自身の記録している情報（図５参照）の中に、その処理装置固有情報６０４が示す処理装置１１０を付与先とする発行権限キーとして記録されているかどうか調べる。記録されていなければ、その発行権限キー６０２はその処理装置固有情報６０４が示す処理装置１１０に発行されたことがないものなので、それら両者は矛盾する。この場合、そのＤＩＤ６００は不正なＤＩＤである。
（ｂ）ＤＩＤ６００中の発行権限キー６０２と発行年月日６０６とが矛盾しないこと。
ＤＩＤサーバ２２０は、発行権限キーに対応づけて、キー付与日時とキー終了日時を記録している（図５参照）。ＤＩＤ６００中の発行年月日６０６が、ＤＩＤ６００中の発行権限キー６０２に対応付けて記録されているキー付与日時からキー終了日時までの期間から外れている場合、発行権限キー６０２と発行年月日６０６は矛盾している。この場合、ＤＩＤ６００は不正なＤＩＤである。
（ｃ）ＤＩＤ６００中の発行権限キー６０２、処理装置固有情報６０４及び発行証明キー６０８の間に矛盾がないこと。
ＤＩＤサーバ２２０は、発行証明キー６０８を、その処理装置固有情報６０４が示す処理装置１１０の公開鍵で復号し、その復号結果が示す発行証明キーが、ＤＩＤ６００中のその発行証明キー６０８と一致するかどうかを判定する。一致しない場合、それら三者の間には矛盾が存在し、ＤＩＤ６００は不正なものであると分かる。
（ｄ）ＤＩＤ６００中の発行番号６１０が、発行権限キー６０２に対応する発行枠と矛盾しないこと。
ＤＩＤサーバ２２０は、発行権限キー６０２と共に処理装置１１０に付与した発行枠を記録している（図５参照）。ＤＩＤ６００中の発行番号６１０が、発行権限キー６０２に対応して記録されている発行枠よりも大きい番号である場合、そのＤＩＤは不正なものである。
（ｅ）ＤＩＤ６００中の発行番号６１０が、そのＤＩＤ６００の発行権限キー６０２と同じ発行権限キーを含む発行済みのＤＩＤの発行番号と矛盾しないこと。この基準は、処理装置１１０から新たに発行したＤＩＤを通知された場合に、そのＤＩＤが既に発行済みのものと矛盾するかどうかの検証に用いる。
ＤＩＤサーバ２２０は、発行権限キーに対応付けて、その発行権限キーを用いて発行されたＤＩＤやその発行日時の情報を記録している（図５の発行済ＤＩＤリスト）。ＤＩＤサーバ２２０は、検証対象のＤＩＤ６００の発行権限キー６０２と同じ発行権限キーを持つ発行済みＤＩＤの中に、そのＤＩＤ６００中の発行番号６１０と同じ発行番号を持つものがあるかどうかを調べる。そのようなものがあれば、そのＤＩＤ６００は不正なものであると判定される。
（ｆ）ＤＩＤ６００中の発行年月日６０６及び発行番号６１０の組合せが、そのＤＩＤ６００の発行権限キー６０２と同じ発行権限キーを含む発行済みのＤＩＤの発行年月日と発行番号の組合せと矛盾しないこと。
ＤＩＤサーバ２２０は、検証対象のＤＩＤ６００の発行年月日６０６と発行番号６１０の組合せが、そのＤＩＤ６００の発行権限キー６０２と同じ発行権限キーを含む個々の発行済ＤＩＤの発行年月日と発行番号の組合せと矛盾するかどうか、すなわち前後関係が逆になっているものがあるかどうか、を判定する。例えばＤＩＤ６００よりも発行年月日が後にもかかわらず、発行番号が小さい発行済みＤＩＤが見つかった場合、ＤＩＤ６００とその発行済みＤＩＤとは矛盾、すなわち前後関係が逆転している。このような矛盾が見つかった場合、検証対象のＤＩＤ６００だけ、あるいはこれとその発行済みＤＩＤとの両方を不正なものと判定する。
ＤＩＤサーバ２２０は、以上のような基準に従った検証によりあるＤＩＤが不正なものであると判定した場合、その不正なＤＩＤに関連する処理装置１１０の管理者に電子メール等で警告通知を行う。警告通知には、その処理装置１１０の発行したものと偽装したＤＩＤが見つかったことを知らせるメッセージが含まれる。管理者は、その通知により、セキュリティ強化の施策を行う。処理装置１１０の管理者やその連絡先は、処理装置管理サーバ２４０が持つ情報（図６参照）から求めればよい。警告通知の宛先である不正なＤＩＤに関連する処理装置１１０は、そのＤＩＤに含まれる処理装置固有情報６０４が示す処理装置１１０である。また、その不正なＤＩＤに含まれる発行権限キーと同じ発行権限キーを過去に付与したことがある処理装置１１０を警告通知の宛先としてもよい。
＜ｅＤｏｃの暗号に脆弱性が発見された場合の処理＞
さて、次に、ｅＤｏｃファイルの生成の際の暗号化に用いた暗号化ソフトに脆弱性が発見された場合の処理について説明する。ドキュメント管理システムの運営者は、いずれかの処理装置１１０が用いた暗号化ソフトの特定バージョンに脆弱性が発見されたことを知得した場合、管理システム２００から各処理装置１１０に対して脆弱性通知を送信する。脆弱性通知には、脆弱性が発見された暗号化ソフトのソフト名及びバージョンの情報が含まれる。組織内管理システム１５０が存在する場合には、脆弱性通知は、管理システム２００から組織内管理システム１５０に渡され、組織内管理システム１５０が配下の各処理装置１１０にその脆弱性通知を送信する。この通知に対して、処理装置１１０は図１８に例示する処理を実行する。
処理装置１１０は、上位装置（管理システム２００又は組織内管理システム１５０）から脆弱性通知を受信（Ｓ２００）すると、その通知が示す脆弱性が見つかった暗号化ソフトのバージョンを用いて自機が暗号化したファイルを特定する（Ｓ２０２）。処理装置１１０のドキュメントＤＢ１１６には、その処理装置１１０が生成した各ｅＤｏｃファイルとそのメタデータが保存されており、それら各ｅＤｏｃファイルのメタデータから各ｅＤｏｃの生成に用いられた暗号化ソフト名とバージョンが分かる（図３に示すメタデータの構造例を参照）。Ｓ２０２では、処理装置１１０は、メタデータに含まれる暗号化ソフト名とバージョンの組合せが、脆弱性通知に示された組合せと一致するｅＤｏｃを特定する。
次に処理装置１１０は、特定した各ｅＤｏｃファイルを、自機にインストールされている現用の暗号化ソフトのバージョンで再暗号化する（Ｓ２０４）。この例では、処理装置１１０の暗号化ソフトは適切にバージョンアップされており、処理装置１１０が持つ現用の暗号化ソフトのバージョンについては脆弱性が未発見であると想定している。一般に、処理装置１１０が過去に用いた暗号化ソフトのバージョンで脆弱性が発見されることが多いと考えられる。なお万が一、脆弱性通知の対象である暗号化ソフトのバージョンが、処理装置１１０の現用バージョンの暗号化ソフトである場合には、処理装置１１０は上位装置等から最新バージョンの暗号化ソフトをダウンロードし、その最新バージョンを用いて再暗号化を行う。仮に現用の最新バージョンの暗号化ソフトに脆弱性が発見された場合、上位装置は、その脆弱性が解消された更に新しいバージョンの暗号化ソフトを有しているか、そのソフトの配布元の情報を有していると想定できる。再暗号化は、例えば、対象のｅＤｏｃファイルを、そのｅＤｏｃファイルに対応するメタデータに記録されている復号鍵の情報を用いて復号し、その復号結果を新たに生成した暗号鍵を用いて、脆弱性のないバージョンの暗号化ソフトを用いて暗号化する。なお、処理装置１１０の保存するメタデータには復号鍵の情報が、例えば処理装置１１０の公開鍵で暗号化された状態で含まれているものとする（同様に、上位装置に送るメタデータには、その復号鍵がその上位装置の公開鍵で暗号化されたものを含めてもよい）。
処理装置１１０は、その再暗号化に応じて、そのｅＤｏｃファイルのメタデータを更新する（Ｓ２０６）。すなわち、メタデータ（図３参照）中のエンコード日時、暗号化情報（暗号化ソフト名、バージョン情報及び鍵情報）を、再暗号化の日時、再暗号化に用いた暗号化ソフト名、バージョン及びその暗号化を解くための復号鍵の情報へと書き換える。そして、処理装置１１０は、更新後のメタデータを保存（例えばそのｅＤｏｃファイルに対する最新のメタデータとして保存）し、上位装置にアップロードする。上位装置は、アップロードされた更新後のメタデータを保存する。
その後、処理装置１１０は、再暗号化により得られたｅＤｏｃファイルを、メタデータの配信先情報に示される配信先の各閲覧端末１０４に配信するための処理を実行する（Ｓ２０８）。すなわち例えば、配信先の各閲覧端末１０４に対して、配信準備完了通知を送る（図８のステップ（７）参照）。この通知には、ＤＩＤやドキュメント名に加え、配信するｅＤｏｃが既配信のｅＤｏｃの更新版である旨を示す情報を含めてもよい。この配信準備完了通知を受け取った閲覧端末１０４は、閲覧者が閲覧端末１０４のリスト画面５００（図１１参照）で、その再暗号化により配信準備完了通知を受けたｅＤｏｃを閲覧対象に指示した場合、閲覧端末１０４は、その指示に応じて処理装置１１０から取得したｅＤｏｃファイルと、自機内にある再暗号化前のｅＤｏｃファイルに上書きする。また閲覧端末１０４は、そのｅＤｏｃファイルと共に受け取った更新後のメタデータを、そのｅＤｏｃの最新のメタデータとして保存する。これにより、脆弱性のある暗号化ソフトで暗号化されたｅＤｏｃファイル及びそれに対応するメタデータは閲覧端末１０４からなくなり、脆弱性の見つかっていない暗号化ソフトで再暗号化されたｅＤｏｃファイル及びメタデータに置き換えられる。
なお、処理装置１１０は、再暗号化したｅＤｏｃの閲覧準備完了通知を送る際又はその前に、そのｅＤｏｃのＤＩＤを含む削除通知を配信先の各閲覧端末１０４に明示的に送信してもよい。この場合、その指示に応じて各閲覧端末１０４が、そのＤＩＤを持つ既存のｅＤｏｃファイル（再暗号化前のもの）を削除する。このとき既存のメタデータも併せて削除してもよい。
＜配信先端末指定の別の例＞
これまでに説明した例では、配信者が作成端末１０２のＵＩ画面（図９の入力画面４００）で選択可能な配信先のユーザ及び閲覧端末１０４は、同じローカルシステム１００内の処理装置１１０に登録されたユーザ及び閲覧端末１０４か、あるいは同じ組織の組織内管理システム１５０に登録されたユーザ及び閲覧端末１０４（この場合、別の処理装置１１０に登録されたユーザ及び閲覧端末１０４も配信先に指定可能）に限られていた。
しかし、組織内のユーザが組織外の人（ゲスト）を交えた会議において、作成した会議メモ等のドキュメントをゲストに対して一時的に閲覧させたい場合もある。このような場合に、ゲストやゲストの携帯端末を処理装置１１０やその上位装置に登録したり、閲覧終了後にその登録を解除したりするのは煩雑な作業となる。
そこで、ドキュメント管理システムでは、ゲストの端末と判断できる閲覧端末１０４には、一定の制限の下でｅＤｏｃを配信可能とする。
例えば、作成端末１０２の近傍にいるユーザの端末はゲスト端末であると見なし、そのゲスト端末を配信先端末選択メニュー４０６の選択肢に加える。あるいは、処理装置１１０の近傍にいるユーザの端末はゲスト端末であると見なし、そのゲスト端末を配信先端末選択メニュー４０６の選択肢に加える。作成端末１０２や処理装置１１０は、組織の建物の部屋（例えば部署の居室、会議室）に設置されていることが多いと考えられ、作成端末１０２又は処理装置１１０の近くにいる人は、会議等のためにしかるべき許可を受けてその部屋に入室している人であると想定される。
例えば、処理装置１１０又は作成端末１０２は、Bluetooth Low Energy（登録商標）等の近距離無線通信を用いて通信可能な相手端末を探し、見つかった相手端末、又はそれら相手端末のうち自機からの距離（その近距離無線通信には、自機と相手の通信距離を求めることができるものもある）があらかじめ定めた閾値以下の端末を、自機の近傍にあるゲスト端末と判定する。そして、配信先端末選択メニュー４０６には、処理装置１１０又は作成端末１０２が検出したゲスト端末の端末名が、あらかじめ登録されている組織内の閲覧端末１０４とは別の表示態様で、選択肢として表示される。配信者は、その中で、配信先とするゲスト端末を選択可能である。
ここで、処理装置１１０又は作成端末１０２は、自機の近傍にある端末すべてではなく、それら近傍の端末のうち所定の条件を満たすもののみをゲスト端末として配信先の選択肢に選んでもよい。例えば、端末が搭載しているビューワアプリケーションその他の特定のソフトウエアのバージョンがあるバージョン以上であることを条件としたり、あらかじめ定められている拒否端末リストに含まれないことを条件とすること等が考えられる。
ゲスト端末を携帯しているユーザは、処理装置１１０やローカルユーザＩＤサーバ１５２等に登録されていないことが一般的と考えられる。そこで処理装置１１０は、ドキュメントの配信先に指定されたゲスト端末から、ｅＤｏｃファイルやメタデータを要求された場合には、ユーザ認証を省略してそれらデータを配信してもよい。また、ゲスト端末に配信するｅＤｏｃのメタデータには、削除条件が満たされたらそのｅＤｏｃファイル及びメタデータをゲスト端末から削除する旨の削除指示を組み込む。削除条件は、例えばそのｅＤｏｃの画面表示が終了した場合、又は、配信時点から所定の許可期間が経過した場合、等である。ゲスト端末は、削除条件が満たされた時点で、そのｅＤｏｃファイル及びメタデータを自端末内から削除する。これにより、ゲスト端末によるｅＤｏｃの漏洩リスクが低減される。
＜配信先端末以外からの要求に対する対処＞
これまでに説明した例は、配信者が配信先として指定した閲覧端末１０４に対して処理装置１１０がｅＤｏｃ（又はこれに対応する配信準備完了通知）を配信するという、プッシュ型の配信形態であった。
しかし、別の例として、閲覧端末１０４からの要求に応じて処理装置１１０が保持しているｅＤｏｃのリストを閲覧端末１０４に提供し、その中からユーザが選択した閲覧対象を閲覧端末１０４に配信するという、プル型の配信形態も考えられる。プル型の配信形態の場合、配信先ユーザが、配信先に指定されていない閲覧端末１０４から処理装置１１０にアクセスし、ｅＤｏｃを要求することも考えられる。このような要求があった場合に処理装置１１０が行う対処として、以下のような方式がある。
（方式１） 処理装置１１０は、閲覧端末１０４からｅＤｏｃの配信要求を受けた場合に、その閲覧端末１０４が、そのｅＤｏｃの最新のメタデータの配信先情報にて配信先とされている閲覧端末に該当するかどうか判定する。そして、該当しないと判定した場合には、そのｅＤｏｃのファイル（本体）もメタデータもその閲覧端末１０４には送信しない。なお、該当すると判定した場合には、更に、その配信要求を行ったユーザ（あるいはそのユーザと閲覧端末１０４の組合せ）が、そのメタデータの配信先情報に含まれているかどうかを判定し、含まれている場合には配信を行い、含まれていない場合には配信を行わないようにしてもよい。
このように、方式１では、配信者から指定された配信先に該当しない閲覧端末１０４には、ｅＤｏｃ（本体ファイル及びメタデータ）は配信されない。
（方式２） この方式では、処理装置１１０は、ｅＤｏｃの配信要求を送ってきた閲覧端末１０４がそのｅＤｏｃのメタデータの配信先情報に規定された配信先の閲覧端末１０４に該当しない場合でも、その要求を発したユーザ（すなわちその閲覧端末１０４を使用しているユーザ）がその配信先情報に配信先として含まれる場合は、ｅＤｏｃの本体ファイル及びメタデータを送信する。ただし、処理装置１１０は、この場合、送信するｅＤｏｃファイル及びメタデータには、保存不可を示すフラグ情報を組み込む。閲覧端末１０４は、保存不可のフラグ情報を含んだｅＤｏｃファイル及びメタデータは、表示はするが、ユーザからの保存指示は受け付けず、ユーザの閲覧が終了すると、それらを保存せずに破棄する。
なお、配信先に指定されていない閲覧端末１０４に送信したｅＤｏｃファイル及びメタデータをその閲覧端末１０４に保存させない方式に代えて、保存はいったん認めることも考えられる。ただし、この場合、その後再びその閲覧端末１０４がそのｅＤｏｃファイルを開こうとする際、その閲覧端末１０４は処理装置１１０等にそのｅＤｏｃの最新のメタデータを要求（これは閲覧の許可を求める要求である）するが、その要求に応じて処理装置１１０がその閲覧端末１０４と要求したユーザの組合せがそのメタデータの配信先情報に含まれるか判定し、含まれない場合は、閲覧端末１０４にそのｅＤｏｃを削除する指示を送る。閲覧端末１０４は、その指示に応じて、保存しているそのｅＤｏｃのファイルとこれに対応するメタデータを削除する。なお、処理装置１１０は、最新のメタデータを要求した閲覧端末１０４に明示的にｅＤｏｃの削除指示を送る代わりに、単にその最新のメタデータを応答してもよい。この場合、閲覧端末１０４が、受け取った最新のメタデータに、自機と現在のユーザの組合せが含まれているか判定し、含まれていない場合には、ｅＤｏｃを開かず、更にその保存しているｅＤｏｃのファイルを削除してもよい。
以上に説明した図１８の例では、再暗号化後のｅＤｏｃファイルは再暗号化前のｅＤｏｃファイルのＤＩＤを引き継いだが、再暗号化後のｅＤｏｃファイルに再暗号化前のｅＤｏｃファイルとは別のＤＩＤを付与してもよい。この場合、処理装置１１０は、配信先の各閲覧端末１０４に対して、再暗号化前のｅＤｏｃファイルのＤＩＤを含んだ明示的な削除指示を送ることで、脆弱性のある再暗号化前のｅＤｏｃファイルが閲覧端末１０４に残らないようにする。また、再暗号化後のｅＤｏｃファイルと再暗号化前のｅＤｏｃファイルとが互いに同じドキュメントに対応するものであることを示す関連付けの情報を、再暗号化後のｅＤｏｃファイルに対応するメタデータ、又は処理装置１１０内（あるいは上位のＤＩＤサーバ２２０、ローカルＤＩＤサーバ１５４内）に記録する。再暗号化後のｅＤｏｃに対応するメタデータに記録する場合には、例えば、そのメタデータに例えば「更新前のＤＩＤ」の項目として、再暗号化前のｅＤｏｃのＤＩＤを含めればよい。
以上の例では、ｅＤｏｃファイルは、そのｅＤｏｃファイルが登録された処理装置１１０が接続されたローカルネットワーク１０８に接続可能な閲覧端末１０４以外の端末には配信されない。しかし、セキュリティが確保されると考えられる特別な場合には、その処理装置１１０から他のネットワークに接続された閲覧端末１０４にそのｅＤｏｃファイルを配信してもよい。このような例を以下に説明する。
この例では、処理装置１１０をグループ化し、ある処理装置１１０が保持するｅＤｏｃの配信を、同一のグループに属する他の処理装置１１０に接続する閲覧端末１０４にも許可する。グループは、契約者の要望に添って規定される。例えば、同じ契約者に対応する処理装置１１０を１つのグループとしたり、契約者である会社の同じ拠点（工場やオフィス）や部署に設置された処理装置１１０を１つのグループとしたりする形で、グループが定義される。また、複数の契約者が協業を行う場合に、それら契約者の協業する部門に設置された処理装置１１０を１つのグループとしてもよい。
図１９に、Ｘ社及びＹ社という２つの契約者に設定されているグループを例示する。この例ではＸ社には、まずＸ社に設置されたすべての処理装置１１０からなるグループＡが設定されている。また、Ｘ社内の本社に設置された処理装置１１０からなるグループＢや、技術部門、工場部門及び営業部門にそれぞれ設置された処理装置１１０からなるグループＣ１、Ｃ２及びＤが設定されている。グループＢ、Ｃ１、Ｃ２、Ｄは、グループＡに含まれる。また、営業部門のグループＤの中には、東京営業所に設置された処理装置１１０からなるグループＤ１と、関西営業所に設置された処理装置１１０からなるグループＤ２が含まれる。これらグループＡ、Ｂ、Ｃ１、Ｃ２、Ｄ、Ｄ１、Ｄ２は、Ｘ社の組織構成に従って設けられたグループであり、ほぼ永続的に存在すると想定される。このように永続的な存在が想定されるグループのことを固定グループと呼ぶ。一方、Ｘ社内には、アドホックに作られる一時的なプロジェクトのためのグループＧ１及びＧ２が設定されている。例えばグループＧ１には、対応するプロジェクトチームに参加している部門に設置された処理装置１１０が含まれる。グループＧ１及びＧ２のように、一時的であることが前提のグループを変動グループと呼ぶ。
同様に、Ｙ社には、Ｙ社に設置されたすべての処理装置１１０からなるグループＡと、営業部門、会計部門、監査部門にそれぞれ設置された処理装置１１０からなるグループＢ、Ｃ、Ｄという４つの固定グループが設定されている。グループＢ、Ｃ、ＤはグループＡに含まれる。
また図示例では、Ｘ社とＹ社は協業を行っており、その協業に関する特別監査プロジェクトのために、Ｘ社及びＹ社それぞれの、協業に関係する部門に属する処理装置１１０から、２社に跨がる変動グループであるグループＧ−Ｙ−Ｘ−１が設定されている。
さて、この例では、図２０に示すように、各処理装置１１０には、管理情報１１２ａに加え、所属グループ情報１１２ｂと転送設定情報１１２ｃが保持されている。
所属グループ情報１１２ｂは、処理装置１１０が所属するグループを示す情報である。１つの例では、処理装置１１０が持つ所属グループ情報は、その処理装置１１０が属しているグループＩＤのリストである。グループＩＤは、グループを全世界的に一意に識別する識別情報である。グループＩＤの全世界的な一意性は、例えば全世界的に一意な契約者ＩＤを含む形式（例えば契約者ＩＤに、その契約者内でのグループの通し番号をマージしたもの）とすることで実現すればよい。
処理装置１１０が設置されている部門に対応するグループの他に、そのグループを包含する上位グループのグループＩＤも含まれる。例えば、図１９の例で、東京営業所内の、特別監査プロジェクトにも関与している部署に設置される処理装置１１０の所属グループ情報は、グループＤ１、Ｄ、Ａ及びＧ−Ｙ−Ｘ−１という４つのグループのグループＩＤを含む。
転送設定情報１１２ｃは、当該処理装置１１０が保持しているｅＤｏｃを他の処理装置１１０からの要求に応じて転送する場合の転送方法についての設定情報である。この例では、処理装置１１０は、自分が持つｅＤｏｃに対して他の処理装置１１０から転送要求が来た場合、その要求元の処理装置１１０が自分と同じグループに属していれば、その要求元に対してそのｅＤｏｃを応答する。ここで、上述のように、処理装置１１０は、複数のグループに所属している場合があり、それら所属グループ毎に、転送の仕方や条件を異ならせることができるよう、転送設定情報１１２ｃを設けている。
図２１に、転送設定情報１１２ｃの例を示す。図示の例は、図１９のグループ構成例において、Ｘ社の東京営業所内の、特別監査プロジェクトにも関与している部署に設置される処理装置１１０に設定された転送設定情報１１２ｃである。この処理装置１１０は、グループＤ１、Ｄ、Ａ、及びＧ−Ｙ−Ｘ−１という４つのグループに属しており、それら４つのグループのそれぞれについて、「◎」、「○」、「△」という３段階のレベルのいずれかが設定されている。
レベル「◎」は、要求されたｅＤｏｃを既定の転送プロトコルで即座に要求元に転送する方式である。このレベルは、互いに信頼できる処理装置１１０からなる緊密なグループに適用される。なお、転送プロトコルには、ＦＴＰ、ＴＦＴＰ、ＦＴＰＳ、ＷｅｂＤＡＶ、ｒｓｙｎｃ、ＳＣＰ等さまざまなものがあり、既定の転送プロトコルはそれらのいずれであってもよい。また、安全性を高めるためにこれらプロトコルに改変（例えばより高レベルの暗号化）を加えたものを使用してもよい。
レベル「○」は、要求元との間の通信接続の状態を確認し、自分と要求元の双方が利用可能な転送プロトコルの中から、所定の基準に従って選択した転送プロトコル（例えば最もセキュリティが強い転送プロトコル）を用いて転送する方式である。このレベルの方式は、一般的なデータ転送で用いられるものと同等である。
レベル「△」は、ｅＤｏｃに対して特定の高い権限を持つ者（例えばオーナー、すなわち当該処理装置１１０にそのｅＤｏｃを登録したユーザ）の要求である場合にのみ、要求元の処理装置１１０に対して要求されたｅＤｏｃを転送する方式である。転送に用いるプロトコルは、レベル「○」と同様、要求元の処理装置１１０とのネゴシエーションで決定する。このレベル「△」は、セキュリティに関する信頼度が低い処理装置１１０を含んでいるグループ等への適用を想定したものである。
また、それら各レベルに、転送先の処理装置１１０でのそのｅＤｏｃのキャッシュ期間を対応付けてもよい。レベルが高いほど、キャッシュ期間は長くする。グループのレベルが高いとは、グループに属する処理装置１１０同士の信頼度が高いと言うことである。上述の例では、「◎」、「○」、「△」の順に高レベルである。
処理装置１１０は、要求されたｅＤｏｃを、要求元について判定したレベルに対応するキャッシュ期間の情報と共にその要求元に転送する。要求元の処理装置１１０は、転送されたｅＤｏｃを、そのキャッシュ期間の間キャッシュし、その間にそのｅＤｏｃの要求を受けた場合には、キャッシュしたｅＤｏｃを用いて応答する。
図２１に例示した転送設定情報には、「一致」と「特殊な設定」という２つのカラムがある。「一致」は、転送要求対象のｅＤｏｃを保持している当該処理装置１１０と、転送要求元の処理装置１１０と、の間で一致する所属グループについて適用されるレベルを示すカラムである。「特殊な設定」は、業務監査や管理等の目的のために用いられる、マスター鍵的な設定のカラムである。「特殊な設定」は、例えば、すべての固定グループに属する処理装置１１０から監査者又は管理者の装置にｅＤｏｃを転送可能とするものである。要求元が監査者等の装置であることは、その装置が要求先の処理装置１１０に対して例えば監査者等であることを示す特別な認証情報を送信することで証明する。
以上に説明した所属グループ情報１１２ｂ及び転送設定情報１１２ｃは、例えば、各処理装置１１０の管理者、あるいはこのシステムのサービスを提供する業者のサービスパースンが、各処理装置１１０に対して設定する。
なお、処理装置１１０が保持する所属グループ情報１１２ｂと転送設定情報１１２ｃは、図６に示した処理装置管理サーバ２４０に、当該処理装置１１０の処理装置ＩＤに対応するステータス履歴２４２のステータス２４４の項目として登録される。
以下、ある処理装置１１０（「ホーム装置」と呼ぶ）に登録されたユーザが、ホーム装置が接続されたローカルネットワークの外にある別の拠点で、その拠点にある処理装置１１０（「アウェイ装置」と呼ぶ）を経由して、ホーム装置内のｅＤｏｃを取得する処理を説明する。ユーザＩＤサーバ２１０には、ホーム装置のＩＤがそのユーザの既定の処理装置ＩＤとして登録されている（図４参照）。そのユーザは、通常は、ホーム装置の接続されたローカルネットワーク１０８に接続し、ホーム装置に登録されたｅＤｏｃの配信を受ける。ここでは、そのユーザが、別の場所に出かけたときに、その場所のローカルネットワーク１０８に接続されたアウェイ装置を介して、ホーム装置からｅＤｏｃの配信を受ける場合の流れを説明する。
図２２を参照して、アウェイ装置の処理手順を例示する。この手順では、アウェイ装置がユーザ（そのアウェイ装置に登録されていないユーザ）の閲覧端末１０４から、取得対象のｅＤｏｃのＤＩＤの入力を受ける（Ｓ１０）。ここで、このステップの前に、アウェイ装置は、アクセスしてきたそのユーザを、上位のユーザＩＤサーバ２１０を利用してユーザ認証してもよい。また、そのユーザの閲覧端末１０４は、そのユーザ認証の後、メタデータサーバ２３０又はホーム装置から、そのユーザが配信先に設定されているｅＤｏｃのリストを取得し、そのリストをユーザに提示して取得対象の選択を受け付けてもよい。
次にアウェイ装置は、Ｓ１０で入力されたＤＩＤに対応する最新のメタデータをメタデータサーバ２３０から取得し（Ｓ１２）、そのメタデータの配信先情報（図３参照）にそのユーザが含まれることを確認する（Ｓ１４、Ｓ１６）。そのユーザが配信先情報に含まれていない場合は、アウェイ装置は閲覧端末１０４に対して配信不許可の旨を示すエラー情報を送る（Ｓ１７）。閲覧端末１０４は、そのエラー情報に従って画面に配信不可の旨を表示する。
Ｓ１６でそのユーザがそのｅＤｏｃの配信先であると確認できた場合、アウェイ装置のキャッシュの中にそのｅＤｏｃのファイルが存在するかどうかを調べる（Ｓ１８）。そのｅＤｏｃが既にホーム装置から取得済みでキャッシュ内にまだ残っている場合は、Ｓ１８の判定結果がＹｅｓとなる。この場合、アウェイ装置は、そのキャッシュ内のｅＤｏｃを閲覧端末１０４に応答する（Ｓ２０）。
Ｓ１８の判定結果がＮｏの場合、アウェイ装置は、そのメタデータからそのｅＤｏｃを持つホーム装置を特定する（Ｓ２２）。そのメタデータ（図３参照）が含む処理装置ＩＤに対応する処理装置がホーム装置である。アウェイ装置は、そのホーム装置のアドレス情報を管理システム２００から取得し、そのアドレス情報を用いてホーム装置にアクセスし、そのｅＤｏｃの転送要求を送る（Ｓ２４）。この転送要求には、そのｅＤｏｃのＤＩＤと、アウェイ装置の所属グループ情報が含まれる。
次にアウェイ装置は、その転送要求に応じてホーム装置からそのｅＤｏｃが提供されたかどうかを判定する（Ｓ２６）。後述するように、アウェイ装置がホーム装置と共通のグループに属していない場合、ホーム装置はアウェイ装置にｅＤｏｃを送信しないので、Ｓ２６の判定結果はＮｏとなる。この場合、アウェイ装置は閲覧端末１０４に対して配信不許可の旨を示すエラー情報を送る（Ｓ１７）。閲覧端末１０４は、そのエラー情報に従って画面に配信不可の旨を表示する。
Ｓ２６の判定結果がＹｅｓの場合、アウェイ装置は、ホーム装置から送信されたｅＤｏｃを要求元ユーザの閲覧端末１０４に応答する（Ｓ２８）。またアウェイ装置は、そのｅＤｏｃを、自分の記憶装置内にキャッシュする（Ｓ２９）。ここで、ホーム装置から送信されたｅＤｏｃにキャッシュ期間の指定がある場合、アウェイ装置は、そのｅＤｏｃを取得した時点からそのキャッシュ期間が経過すると、そのｅＤｏｃをキャッシュから削除する。キャッシュ期間は、閲覧端末１０４上でのそのｅＤｏｃの有効期間とは独立して定められる。なお、キャッシュ期間の指定がない場合は、Least Recently Used等の通常のキャッシュアルゴリズムに従って、古くなったｅＤｏｃを破棄する。
図２３を参照して、アウェイ装置からｅＤｏｃの転送要求を受けた時のホーム装置の処理手順の例を説明する。ホーム装置は、アウェイ装置から転送要求を受け取ると（Ｓ３０）、その転送要求中の所属グループ情報（アウェイ装置のもの）と、ホーム装置自身の所属グループ情報とを比較し、両者の間に一致（共通）するグループＩＤが存在するか否かを判定する（Ｓ３２）。共通するグループＩＤが一つもない場合は、ホーム装置は、アウェイ装置に対して、要求されたｅＤｏｃが転送できない旨を応答する（Ｓ３８）。この場合、アウェイ装置は、ホーム装置と同じグループに属していないので、ホーム装置から信頼できるか不明な装置であるため、転送を許可しない。
Ｓ３２の判定結果がＹｅｓの場合、ホーム装置は、それら両者間で一致するグループＩＤのレベルの最高レベルを特定し（Ｓ３４）、特定したレベルに対応する転送方式を用いて、アウェイ装置に対してｅＤｏｃを転送する（Ｓ３６）。特定したレベルにキャッシュ期間が設定されている場合には、そのキャッシュ期間を示す情報をｅＤｏｃと対応付けてアウェイ装置に転送する。なお、Ｓ３４で特定した最高レベルが上述のレベル「△」である場合には、ホーム装置は、転送要求元のユーザＩＤがそのｅＤｏｃについての特定の高い権限を持つ者（例えばオーナー）に該当するか否かを判定し、該当する場合にはＳ３６に進んでｅＤｏｃの転送を行い、該当しない場合にはＳ３８に進んで転送不許可の旨を応答してもよい。
なお、ｅＤｏｃの転送のためにファイアウォールを通過する必要がある処理装置１１０には、トンネリングプロトコルを組み込んでおく。組み込むトンネリングプロトコルは、Ｌ２Ｆ、ＰＰＴＰ、Ｌ２ＴＰ、ＧＲＥ、ＩＰｓｅｃ等のいずれであってもよい。また複数組み込んでおき、転送の相手との間で共通のものを選んで利用する手順としてもよい。
また、ｅＤｏｃ転送に用いる転送プロトコルの種別やトンネリングプロトコルの使用の有無及び／又は種別に応じて、上記処理手順により自動転送を許可するｅＤｏｃのデータ量の上限を設定することにより、転送の安定性の向上を図ってもよい。また、この上限を超えた場合には、ｅＤｏｃを上限以下の部分に分割して転送してもよい。
以上の例では、各処理装置１１０の所属グループ情報１１２ｂには、その処理装置１１０が直接所属するグループのＩＤの他に、そのグループが包含されるより広いグループのＩＤのように、その処理装置１１０が階層的に所属するすべてのグループのＩＤが含まれるとしたが、このような所属グループ情報１１２ｂの形態はあくまで一例に過ぎない。処理装置１１０が所属グループ情報１１２ｂを持つ代わりに、処理装置１１０からアクセス可能なネットワーク上に設けられたサーバ上に所属グループ情報１１２ｂを保持し、処理装置１１０がそれを参照する方式でもよい。また、処理装置１１０は、自分が直接所属するグループのＩＤのみを持ち、グループ間の階層関係の情報はネットワーク上のサーバを参照してもよい。
以上に例示したように、処理装置１１０を契約者の希望に従ってグループ化し、同一グループ内の処理装置１１０間ではｅＤｏｃの転送を許可することで、ユーザは、自分が登録された処理装置１１０がある場所（例えば自分のオフィス）以外の場所にいるときにも、自分宛のｅＤｏｃの本体を取得できる機会が増える。
以上、処理装置１１０と管理システム２００を含むドキュメント管理システムについて説明した。
次に、本発明の一実施形態のドキュメント送信制御をそのドキュメント管理システムに適用した場合の例を説明する。本実施形態は、ユーザが自分の既定の処理装置１１０内に記憶されているｅＤｏｃを、別の処理装置１１０を「既定の処理装置」とする送信先ユーザに対してセキュアに送信する仕組みを提供する。
前述のように、各ユーザ（例えば企業）のローカルシステム１００内にある処理装置１１０には、このドキュメント管理システムでの情報セキュリティの基盤である公開鍵基盤の認証局から発行された、当該処理装置の公開鍵証明書がインストールされている。この公開鍵証明書は、失効する前に適宜更新するようメインテナンスされている。また、各処理装置１１０は、自分自身を特定する情報セット（以下「特定情報セット」と呼ぶ）と、自分の公開鍵の公開鍵証明書を、管理システム２００（特に処理装置管理サーバ２４０）に登録している。ここで、処理装置１１０の特定情報セットは、例えば処理装置ＩＤ、契約に関する状態情報、セキュリティ維持情報等を含む。処理装置ＩＤは、管理システム２００が付与した一意な識別情報であってもよいし、当該処理装置１１０のＩＰアドレス、ＦＱＤＮ、ＭＡＣアドレス等の他の識別情報を用いてもよい。また、ＩＰアドレス、ＦＱＤＮ等の２以上を組み合わせたものを処理装置ＩＤとしてもよい。処理装置１１０の特定情報セット及び公開鍵証明書は、管理システム２００内の処理装置管理サーバ２４０が保持する当該処理装置１１０の管理情報（図６参照）に含まれている。例えば、図６の処理装置ＩＤ、契約者ＩＤ等が特定情報セットに含まれる要素の例である。特定情報セットは、後述する管理システム２００での処理装置１１０の認証の際に、当該処理装置１１０の固有情報として用いられる。処理装置管理サーバ２４０が保持する処理装置１１０の管理情報内のどの項目をどの順に並べたものを特定情報セットとするかは予め取り決められており、処理装置１１０及び管理システム２００はその取り決めに従って当該処理装置１１０の特定情報セットを構成する。
本実施形態におけるドキュメント送信の流れを、図２４を参照して説明する。図２４に示す流れは、以下の（１）から（８）までの各ステップから構成される。
（１）送信者から処理装置１１０Ｓへの送信指示
（２）送信側の処理装置１１０Ｓから管理システム２００への送信許可要求
（３）管理システム２００から受信側の処理装置１１０Ｒへの受信処理の開始指示
（４）処理装置１１０Ｒから処理装置１１０ＳへのｅＤｏｃの転送要求
（５）処理装置１１０Ｓから処理装置１１０ＲへのｅＤｏｃの転送
（６）処理装置１１０Ｒから送信先のユーザの端末へのｅＤｏｃ提供
（７）送信先のユーザの端末でのｅＤｏｃの表示
（８）送信先でｅＤｏｃが閲覧されたことを送信者に通知
以下、これら各ステップの処理内容について更に詳しく説明していく。
（１）送信者から処理装置１１０Ｓへの送信指示
図２４の例では、送信者は、例えば自分の閲覧端末１０４Ｓから、送信側のローカルシステム１００Ｓ内のネットワークを介して、当該ローカルシステム１００Ｓ内の処理装置１１０Ｓにログインする。そして、処理装置１１０Ｓ内に保存されている保護済みドキュメント（ｅＤｏｃファイル）群の中から送信対象とするものを選択し、送信処理の開始指示を行う。なお、送信者は、閲覧端末１０４の代わりに、作成端末１０２から送信処理の開始指示を行ってもよい。この場合、送信者は、作成端末１０２で作成したドキュメントを処理装置１１０Ｓに登録する際に、そのドキュメントの登録により生成されるｅＤｏｃの送信処理の開始を指示してもよい。
この開始指示を受けた処理装置１１０Ｓは、自分の特定情報セットを自分の秘密鍵で暗号化（すなわち電子署名）することで暗号化特定情報を生成する。特定情報セットそのものでなく、そのダイジェスト値（例えばハッシュ値）を秘密鍵で暗号化したものを暗号化特定情報としてもよい。この暗号化特定情報は、処理装置１１０Ｓの電子署名として機能する。処理装置１１０Ｓは、生成した暗号化特定情報（すなわち自身の電子署名）と自身の処理装置ＩＤを含んだ認証要求を管理システム２００に送る。
管理システム２００は、処理装置１１０Ｓからの認証要求に対する認証処理を行う。この認証処理では、その認証要求に含まれる暗号化特定情報を、その処理装置１１０Ｓの公開鍵証明書（これは処理装置管理サーバ２４０に保持されている。図６の「セキュリティ証明書情報」）に示される公開鍵で復号する。そして、復号結果が、処理装置管理サーバ２４０が保持しているその処理装置１１０Ｓの特定情報セット（あるいはそのダイジェスト値）と一致するか否かを判定し、一致すれば認証成功、不一致であれば認証失敗とする。認証失敗の場合、管理システム２００は、認証失敗の旨を示す通知を送信側の処理装置１１０Ｓに送り、その認証失敗を示すログをログサーバ（図示省略）に記録して、処理を終了する。認証成功の場合、管理システム２００は、認証成功の通知と共に、宛先のユーザが用いる受信側の処理装置１１０Ｒからの転送要求（後述）を復号、認証するために必要な情報を、送信側の処理装置１１０Ｓに送る。このとき送られる情報には、例えば、受信側の処理装置１１０Ｒの識別情報（例えば、処理装置ＩＤ、ＩＰアドレス、ＦＱＤＮ等）及び公開鍵証明書が含まれる。
認証成功の通知を受けた送信側の処理装置１１０Ｓは、送信者の閲覧端末１０４Ｓに対して、条件指定用のＵＩ画面（例えばウェブページとして構成される）を提供する。閲覧端末１０４Ｓは、このＵＩ画面を表示し、この画面内の各入力欄への入力を送信者から受けつける。
この条件指定用のＵＩ画面には、ｅＤｏｃの送信先の入力欄が含まれる。この場合の送信先は、他のローカルシステム１００を常用しているユーザである。ここでは、受信側のローカルシステム１００Ｒ内のユーザ（受信者と呼ぶ）が宛先に指定されるものとする。送信先の指定は、例えば、受信者の電子メールアドレスや社員番号等、送信者が知っている受信者の識別情報を入力することにより行ってもよい。管理システム２００（ユーザＩＤサーバ２１０）には、各ローカルシステム１００内の処理装置１１０に登録されたユーザの情報が保持されており、その中にそのユーザの電子メールアドレスその他の識別情報が含まれている。したがって、管理システム２００に問い合わせれば、その電子メールアドレス等に対応するユーザのユーザＩＤや、そのユーザの「既定の処理装置ＩＤ」（図６参照）等の情報が取得可能である。
また条件指定用のＵＩ画面には、送信するｅＤｏｃと共に受信者に送る付箋の情報の入力のためのいくつかの欄が含まれる。この付箋は、送信先でｅＤｏｃを表示する際に、例えばそのｅＤｏｃの表紙や特定のページに対して貼付された付箋のような形態で表示される。付箋情報に関する入力欄には、例えばその付箋の画像内に表示するメッセージ（例えば送信者が受信者に伝えたいコメント）を入力する欄、付箋の形態（例えば矩形、ハート形などといった付箋の形状や、付箋の表示色等）を指定する欄、この付箋情報を暗号化するか否かを指定する欄等がある。また、この付箋情報は、上述したｅＤｏｃに対するアクセス権を規定するメタデータとは別種のメタデータ（付箋メタデータと呼ぶ）として、そのｅＤｏｃに対応付けて保存したり、転送したりしてもよい。ＵＩ画面には、付箋メタデータを管理システム２００のメタデータサーバ２３０に追加登録するか（すなわち送信終了後もメタデータサーバ２３０に保存するか）否かを指定する欄が含まれてもよい。ユーザは、ＵＩ画面上の各入力欄に対して入力を行った後、最初に選んだｅＤｏｃの送信を指示する。また、ｅＤｏｃに付される付箋メタデータについてのアクセス権を、そのｅＤｏｃに対するアクセス権（例えば図３の配信先情報により規定される）とは独立に設定できるようにしてもよい。これにより、送信者は、付箋メタデータに含まれるメッセージ内容（タイトルやコメント）を、そのｅＤｏｃの送信先のユーザのうち特定ユーザには見せて、別のユーザには見せない、といった指定が可能になる。
（２）送信側の処理装置１１０Ｓから管理システム２００への送信許可要求
送信者の閲覧端末１０４Ｓから送信指示を受けた処理装置１１０Ｓは、管理システム２００に対して、他の処理装置１１０へのｅＤｏｃ送信の許可を要求する。この依頼に対して管理システム２００は、処理装置１１０Ｓのステータスが、他の処理装置１１０へのｅＤｏｃ送信のための情報セキュリティ要件（以下、単に「セキュリティ要件」という）を満たすかどうかを判定する。そして、満たす場合には処理装置１１０Ｓにその送信を許可し、満たさない場合にはその送信を禁止する。この管理システム２００による送信許可の判定処理の例を、図２５を参照して説明する。
管理システム２００は、送信側の処理装置１１０Ｓから送信許可の要求を受け取ると、処理装置管理サーバ２４０が管理するその処理装置１１０Ｓのステータス（図６参照）のうちｅＤｏｃ送信に関する項目の値を調べ（Ｓ３００）、それら項目の中にｅＤｏｃ送信のためのセキュリティ要件を満たさないものがあるかどうかを判定する（Ｓ３０２）。なお、Ｓ３０２では、管理システム２００は、処理装置１１０Ｓから、その時点での最新のステータスのうち少なくともｅＤｏｃの送信に関する所定の項目を取得し、それら取得した項目の中にセキュリティ要件を満たさないものがあるかどうか判定してもよい。
ここでの判定対象となる項目には、例えば、オペレーティングシステムのバージョン、暗号化ソフトの名称及びバージョン、エンコードソフトの名称及びバージョン、処理装置１１０にインストールされているセキュリティ証明書、処理装置１１０にインストールされている暗号鍵（例えば秘密鍵と公開鍵ペア。通信路暗号化や署名的な目的等に用いる）の情報（例えば当該鍵の識別情報やインストール日時等）、エンコード回路の名称及びファームウエア（ＦＷ）のバージョン、ウィルスチェックソフトのバージョンやウィルス定義データのバージョン、ウィルスチェックソフトの設定状態等がある。これらの項目は、図１６の手順の場合と同様の理由で、送信されるｅＤｏｃのセキュリティに関わるので、これら項目がｅＤｏｃ送信のためのセキュリティ要件を満たしているかをチェックする。このときのセキュリティ要件は、図１６の手順の際の判定基準と同じでもよいし、異なっていてもよい。例えば、本実施形態では、送信対象のｅＤｏｃが、インターネットを経由して受信側の処理装置１１０Ｒに送られる可能性があるので、判定に用いるセキュリティ基準は、図１６の手順での判定基準よりも厳しいものとしてもよい。
また、Ｓ３０２では、当該処理装置１１０Ｓにインストールされている１以上の転送プロトコルの中に、ｅＤｏｃ送信のためのセキュリティ要件を満たすものがあるかどうかを判定してもよい。転送プロトコルの中には、伝送路暗号化を行うものと行わないものとがあり、また伝送路暗号化を行うものであっても、使用できる暗号化方式及び鍵長等の暗号化パラメータが様々に異なる。そこで、ｅＤｏｃ送信を許可するためのセキュリティ要件として、転送プロトコルの種類や転送プロトコルで用いる暗号化方式や暗号化パラメータについての条件を規定しておき、送信側の処理装置１１０Ｓがその条件を満たす転送プロトコルを持っているかどうかをＳ３０２で判定する。処理装置１１０Ｓがその条件を満たす転送プロトコルを１つも持っていない場合、Ｓ３０２の判定結果はＹｅｓ（セキュリティ要件を満たさない項目あり）となる。
Ｓ３０２の判定結果がＮｏ、すなわち処理装置１１０Ｓのステータスの項目の中に他の処理装置１１０へのｅＤｏｃ送信のためのセキュリティ要件を満たさないものがない場合、管理システム２００は、処理装置１１０Ｓに対して送信を許可する旨の回答を行う（Ｓ３０８）。
Ｓ３０２の判定結果がＹｅｓの場合、処理装置１１０Ｓのステータスの項目の中に他の処理装置１１０へのｅＤｏｃ送信のためのセキュリティ要件を満たさない項目（不充足項目と呼ぶ）がある。この場合、管理システム２００は、その不充足項目がセキュリティ要件を満たすようにするための修正を、管理システム２００からリモートで実行可能かどうかを判定する（Ｓ３０４）。不充足項目が、リモートからの修正が技術的に不可能なものであれば、Ｓ３０４の判定結果はＮｏとなる。また例えば、処理装置１１０Ｓ内の暗号化ソフト、エンコードソフト、転送プロトコル等のインストールや更新は、技術的にリモートから実行できる場合がある。ただし、技術的にはリモートから修正可能であっても、ユーザ側（すなわちローカルシステム１００側）の管理者が、事前通知なしでのリモートからの自動修正を認めない項目もあるので、不充足項目の中にそのような自動修正の認められない項目に該当するものが一つでもある場合には、Ｓ３０４の判定結果はＮｏとなる。不充足項目のすべてが、リモートからの修正が技術的に可能なものであり、かつリモートからの自動修正がユーザ側から許可されているものであれば、Ｓ３０４の判定結果はＹｅｓとなる。
Ｓ３０４の判定結果がＹｅｓの場合、管理システム２００は、処理装置１１０Ｓ内の各不充足項目についての修正を、リモートから実行する（Ｓ３０６）。そして、その修正が完了した後、要求された送信を許可する旨の回答を処理装置１１０Ｓに対して行う（Ｓ３０８）。
なお、詳しくは後述するが、この時点での送信の許可は、あくまで送信に必要な準備処理（図２６に示す処理）を進めることの許可であり、暗号化文書を実際に送信することの許可ではない。この許可の後、その準備処理を経て、送信先の処理装置１１０Ｒについても同様のセキュリティ要件のチェック（図２８に示す処理）を行い、処理装置１１０Ｒもセキュリティ要件を満たすことが確認できて初めて、実際の暗号化文書の送信が許可される。
Ｓ３０４の判定結果がＮｏの場合、管理システム２００は、要求された送信を不許可とする旨の回答を処理装置１１０Ｓに対して行う（Ｓ３１０）。この回答を受けた処理装置１１０Ｓは、送信対象のｅＤｏｃの送信を取りやめる。また処理装置１１０Ｓは、送信者の閲覧端末１０４Ｓに、要求されたｅＤｏｃの送信がセキュリティ上の理由で不許可となったことを示すメッセージを表示させる。また、処理装置１１０Ｓは、ユーザから要求されたｅＤｏｃの送信が不許可になったこと、及びその不許可の理由（例えば不充足項目）やその不許可を解消するために必要な修正の情報を、処理装置１１０Ｓの管理者に対して通知してもよい。管理者は、その通知に応じて、不許可を解消するための修正を行うかどうかを判断する。
図２５の処理で用いるセキュリティ要件は、インターネット等のネットワークにおける脅威の状況に応じて、管理システム２００側で適宜設定変更できるようにする。
Ｓ３０８で管理システム２００から許可が得られた場合、送信側の処理装置１１０Ｓは、図２６に示す準備処理を行う。
まず処理装置１１０Ｓは、送信対象として指定されたドキュメントがｅＤｏｃ化されているか否かを判定する（Ｓ４００）。ｅＤｏｃ化されていない場合（例えば作成端末１０２で作成したドキュメントの送信が指示された場合）、処理装置１１０Ｓは、そのドキュメントをエンコードしてｅＤｏｃを生成し、保存したのち（Ｓ４０２）、Ｓ４０４に進む。指定された送信対象がｅＤｏｃであれば、Ｓ４０２をスキップしてＳ４０４に進む。
次に、処理装置１１０Ｓは、送信者が入力した送信先の情報（例えば電子メールアドレス）に対応するユーザ情報（例えばユーザＩＤ、既定の処理装置ＩＤ）を管理システム２００から取得する（Ｓ４０４）。また処理装置１１０Ｓは、送信対象のｅＤｏｃのメタデータ（図３参照）、特にその配信先情報を管理システム２００から取得し、その配信先情報にその送信先のユーザが配信先として含まれているか否かを判定する（Ｓ４０６）。含まれていない場合、処理装置１１０Ｓは、その送信先ユーザのユーザＩＤを、管理システム内のその配信先情報に追加する（Ｓ４０８）。
また処理装置１１０Ｓは、送信者が入力した付箋情報に従って、付箋メタデータを生成し、生成した付箋メタデータをそのｅＤｏｃのＤＩＤに対応づけてメタデータサーバ２３０に登録する（Ｓ４１０）。付箋メタデータの暗号化の指定がある場合は、暗号化を行ってから、メタデータサーバ２３に登録する。この暗号化は、例えば自動生成したセッション鍵により行う。暗号化した付箋メタデータを送信先に送る場合には、そのセッション鍵をその送信先のユーザの公開鍵で暗号化したものを合わせて送る。
図２７に付箋メタデータが含むデータ項目を例示する。例示した項目には、送信側の処理装置１１０Ｓが設定するもの、管理システム２００が設定するもの、受信側の処理装置１１０Ｒが設定するものがある。このうち、メタデータ番号は、その付箋メタデータの一意な識別情報であり、管理システム２００が設定する。また、受信側の処理装置１１０ＲのＩＤ情報は、送信側の処理装置１１０Ｓから送られてきた送信先の情報に基づいて管理システム２００が特定し、付箋メタデータに設定する。メタデータ種別には、ｅＤｏｃのアクセス権管理のための配信先情報（図３参照）を含んだメインメタデータの他に、今回説明するｅＤｏｃ送信のための付箋メタデータ等の何種類かの付箋メタデータ、あるいは付箋以外の他の種類等がある。送信時刻は、付箋メタデータとこれが付されるｅＤｏｃの送信が指示された時刻である。暗号化有無フラグは、その付箋メタデータを暗号化するか否かを指定するフラグである。ｅＤｏｃ−ＩＤは、この付箋メタデータが付されるｅＤｏｃのＩＤ情報（ＤＩＤ）である。これらメタデータ種別、送信時刻、暗号化有無フラグ、ｅＤｏｃ−ＩＤ、送信者や送信側の処理装置１１０ＳのＩＤその他の情報、受信者のＩＤその他の情報、付箋のタイトルや表示内容、表示色や形状等の項目は、送信側の処理装置１１０Ｓが設定する。また、閲覧済みフラグは、送信先のユーザが付箋を閲覧したか否かを示すフラグであり、受信側の処理装置１１０Ｒにより設定される。また、表示状態番号は、送信先のユーザの端末における付箋の表示状態を示す番号あり、これもその端末からの通知に基づき受信側の処理装置１１０Ｒにより設定される。また回答要求フラグは、送信したｅＤｏｃに対する回答を送信先に要求するかどうかを示すフラグであり、送信者からの入力に基づいて送信側の処理装置１１０Ｓが設定する。
図２４の処理の流れの説明に戻る。
（３）管理システム２００から受信側の処理装置１１０Ｒへの受信処理の開始指示
管理システム２００は、送信側の処理装置１１０ＳからｅＤｏｃ送信用の付箋メタデータの登録を受け付けると、受信側の処理装置１１０Ｒの認証処理を行う。すなわち、管理システム２００は、処理装置１１０Ｒに対して暗号化特定情報の提出を要求する。この要求に応じて、処理装置１１０Ｒは、自分の特定情報セット（又はそのダイジェスト値）を自分の秘密鍵で暗号化することで暗号化特定情報を生成し、生成した暗号化特定情報を管理システム２００に送る。管理システム２００は、処理装置１１０Ｒから受け取った暗号化特定情報を、その処理装置１１０Ｒの公開鍵で復号する。そして、その復号結果が、処理装置管理サーバ２４０が保持しているその処理装置１１０Ｒの特定情報セット（あるいはそのダイジェスト値）と一致するか否かを判定し、一致すれば認証成功、不一致であれば認証失敗とする。認証失敗の場合、管理システム２００は、その認証失敗を示すログをログサーバ（図示省略）に記録する。また、この場合、管理システム２００は、その処理装置１１０Ｒに対して認証失敗の旨を通知すると共に、送信側の処理装置１１０Ｓにも、受信側の処理装置１１０Ｒの認証が失敗した旨を通知する。
認証成功の場合、管理システム２００は、処理装置１１０Ｒのステータスが、他の処理装置１１０からのｅＤｏｃ受信のためのセキュリティ要件を満たすかどうかを判定する。
処理装置１１０Ｒについてのセキュリティ要件の判定処理の手順を図２８に例示する。
この手順では、管理システム２００は、処理装置管理サーバ２４０が管理する受信側の処理装置１１０Ｒのステータス（図６参照）のうちｅＤｏｃ送信（転送）に関する項目を調べ（Ｓ５００）、その中にｅＤｏｃ送信のためのセキュリティ要件を満たさないものがあるかどうかを判定する（Ｓ５０２）。Ｓ５００及びＳ５０２では、管理システム２００は、処理装置１１０Ｒから、その時点での最新のステータスのうち少なくともｅＤｏｃ転送に関する所定の項目を取得し、それら取得した項目の中にセキュリティ要件を満たさないものがあるかどうか判定してもよい。
ここでの判定基準となるセキュリティ要件は、送信側の処理装置１１０Ｓに対する上記ステップ（２）での判定で用いたセキュリティ要件と同様でよい。ただし、一つ異なるのは、転送プロトコルに関する要件である。送信側の処理装置１１０Ｓの場合、ある条件を満たす転送プロトコルを１つ以上備えていれば送信が許可されるが、受信側の処理装置１１０Ｒの場合、受信が許可されるためには、送信側の処理装置１１０Ｓが持つその条件を満たす転送プロトコルと同じ転送プロトコルを持っている必要がある。このような転送プロトコルが受信側の処理装置１１０Ｒにない場合、転送プロトコルに関するセキュリティ要件は満たされないことになる。この場合、リモートの管理システム２００からの自動的な（すなわち処理装置１１０Ｒの管理者側からの許可を得る必要無しでの）インストール又は更新により、処理装置１１０Ｒ内のその同じ転送プロトコルを構成可能であれば、転送プロトコルについてのセキュリティ要件を満たすことができる。逆に、その転送プロトコルについての自動的なインストールまたは更新が許可されていない場合には、その転送プロトコルについてのセキュリティ要件を満たすことはできない。
Ｓ５０２の判定結果がＮｏの場合、管理システム２００は、処理装置１１０Ｒに対してｅＤｏｃの受信処理の開始を指示する（Ｓ５０８）。
Ｓ５０２の判定結果がＹｅｓの場合、処理装置１１０Ｒのステータスの項目の中にセキュリティ要件についての不充足項目がある。この場合、管理システム２００は、その不充足項目がセキュリティ要件を満たすようにするための修正を、管理システム２００からリモートで実行可能かどうかを判定する（Ｓ５０４）。不充足項目が、リモートからの修正が技術的に不可能なものであるか、又はリモートからの修正が処理装置１１０Ｒの管理者から許可されていないものであれば、Ｓ５０４の判定結果はＮｏとなる。不充足項目のすべてが、リモートからの修正が技術的に可能なものであり、かつリモートからの自動修正がユーザ側から許可されているものであれば、Ｓ５０４の判定結果はＹｅｓとなる。
Ｓ５０４の判定結果がＹｅｓの場合、管理システム２００は、処理装置１１０Ｒ内の各不充足項目についての修正を、リモートから実行する（Ｓ５０６）。そして、その修正が完了した後、処理装置１１０Ｒに対してｅＤｏｃの受信処理の開始を指示する（Ｓ５０８）。
Ｓ５０４の判定結果がＮｏの場合、管理システム２００は、ｅＤｏｃの受信を不許可とする旨の通知を受信側の処理装置１１０Ｒに送ると共に、送信側の処理装置１１０ＳにｅＤｏｃの送信を不許可とする旨の通知を送る（Ｓ５１０）。この通知を受けた送信側の処理装置１１０Ｓは、送信対象のｅＤｏｃの送信を取りやめる。また処理装置１１０Ｓは、送信者の閲覧端末１０４Ｓに、要求されたｅＤｏｃの送信がセキュリティ上の理由で不許可となったことを示すメッセージを表示させる。また、処理装置１１０Ｓは、ユーザから要求されたｅＤｏｃの送信が不許可になったこと、及びその不許可の理由（例えば受信側の不充足項目）を、処理装置１１０Ｓの管理者に対して通知してもよい。
管理システム２００がＳ５０８で処理装置１１０Ｒに送る受信処理の開始指示には、送信側の処理装置１１０Ｓから登録された付箋メタデータが含まれる。なお、受信処理開始指示には、付箋メタデータ全体ではなく、そのうち送信側の処理装置１１０ＳにｅＤｏｃの転送を要求するのに必要な項目のみ（例えば送信側の処理装置１１０Ｓの処理装置ＩＤ及びＩＰアドレス等の通信アドレス情報、送信対象のｅＤｏｃのＤＩＤ）が含まれるようにしてもよい。またこの開始指示には、ｅＤｏｃ送信のためのセキュリティ要件を満たし、かつ送信側及び受信側の処理装置１１０Ｓ及び１１０Ｒが共通して有している１以上の転送プロトコルを示す転送プロトコル情報が含まれる。
図２４の説明に戻る。
（４）処理装置１１０Ｒから処理装置１１０ＳへのｅＤｏｃの転送要求
受信処理の開始指示を受けた受信側の処理装置１１０Ｒは、その開始指示に含まれる情報を用いて、送信側の処理装置１１０Ｓに対して、送信対象のｅＤｏｃの転送を要求する。この転送要求は、その情報に含まれる処理装置１１０Ｓの通信アドレス宛に行う。また、この転送要求には、その情報に含まれる送信対象のｅＤｏｃの識別情報（ＤＩＤ）が含まれる。また、その転送要求には、その情報に含まれる転送プロトコル情報が含まれる。この転送プロトコル情報は、そのｅＤｏｃの転送のために選択可能な、セキュリティ要件を満たす転送プロトコルのリストである。またその転送要求には、受信側の処理装置１１０Ｒの処理装置ＩＤと、受信者のユーザＩＤ、付箋メタデータに含まれていた送信時刻が含まれる。送信側の処理装置１１０Ｓから、同じＤＩＤを持つｅＤｏｃが時を隔てて複数回、同じ受信者（送信先の処理装置１１０Ｒと送信先のユーザ）に送られる場合もあるので、そのうちどの時刻に送信されたｅＤｏｃであるかを特定するために、送信時刻の情報を転送要求に含める。
（５）処理装置１１０Ｓから処理装置１１０ＲへのｅＤｏｃの転送
受信側の処理装置１１０Ｒから転送要求を受け取った送信側の処理装置１１０Ｓは、その転送要求が、自分が送信を指示したｅＤｏｃについてのものかチェックする。すなわち、処理装置１１０Ｓは、自分が過去に送信を指示したｅＤｏｃについての付箋メタデータを保持しており、そのうち受信側の処理装置１１０Ｒへの転送が未完了であるものの中に、送信対象のｅＤｏｃのＤＩＤ、転送要求に含まれる受信側の処理装置１１０Ｒの処理装置ＩＤ、受信者のユーザＩＤ、送信時刻の組合せに合致する付箋メタデータがあるかどうかを調べる。該当する付箋メタデータがあれば、処理装置１１０は、その転送要求が正当なものと判断し、その転送要求中の転送プロトコル情報に含まれるリストの中から所定の基準に基づいて選んだ転送プロトコルを用いて、その送信対象のｅＤｏｃファイルを受信側の処理装置１１０Ｒに転送する。この転送の際、使用する転送プロトコルが用いる暗号化に加えて、受信者の公開鍵でｅＤｏｃファイルを暗号化してもよい。
送信側及び受信側の処理装置１１０Ｓ及び１１０Ｒは、それぞれ、このｅＤｏｃの転送及び受信が成功したか否かを示すログ情報を、管理システム２００に送信する。管理システム２００は、受信したそのログ情報をログサーバ（図示省略）に記録させる。
（６）処理装置１１０Ｒから送信先のユーザの端末へのｅＤｏｃ提供
送信側の処理装置１１０Ｓから転送されたｅＤｏｃファイルを受け取った処理装置１１０Ｒは、受信者（これはそのｅＤｏｃファイルに対応する付箋メタデータに示されている）に対して、その受信者宛のｅＤｏｃファイルが届いたことを通知する。この通知は、その受信者の既定の閲覧端末１０４Ｓ（図４の既定の閲覧端末リスト中の予め指定された端末）に対して送られる。
（７）送信先のユーザの端末でのｅＤｏｃの表示
ｅＤｏｃファイルが届いた旨の通知を見た受信者は、閲覧端末１０４Ｒ上でそのｅＤｏｃファイルを開く指示を行う。この指示に応じて、閲覧端末１０４Ｒは、そのｅＤｏｃファイルに対応するメタデータ（図３参照）を取得し、そのメタデータの配信先情報中にその受信者のユーザＩＤが含まれていることを確認すると、そのメタデータ中の鍵情報を用いてｅＤｏｃファイルを復号し、画面表示する。これにより、受信者はそのｅＤｏｃファイルの閲覧が可能になる。また、このｅＤｏｃファイルの表示の際、付箋メタデータ中の付箋情報に従って生成した付箋画像を、例えばそのｅＤｏｃファイルが示す文書の表紙等に貼付したような態様で表示してもよい。付箋画像は、付箋情報が示す形状、色の付箋上に、付箋のタイトル及びコメントの文字列を表示したものである。なお、閲覧端末１０４Ｒは、付箋メタデータに設定されたアクセス権情報を管理システム２００から取得し、受信先のユーザが付箋メタデータへのアクセス権を持つかどうかをその情報により確認し、アクセス権を持たない場合は付箋画像の表示を行わない。
（８）送信先でｅＤｏｃが閲覧されたことを送信者に通知
受信したｅＤｏｃを表示した場合、受信者の閲覧端末１０４Ｓは、そのｅＤｏｃが閲覧済みであることを示す通知を処理装置１１０Ｒに送る。この通知には、その表示を行った時刻（閲覧時刻）の情報が含まれる。この通知を受けて、処理装置１１０Ｒは、そのｅＤｏｃが閲覧された旨の通知（閲覧時刻を含む）を管理システム２００及び送信側の処理装置１１０Ｓに送る。送信側の処理装置１１０Ｓは、この通知に応じて、送信者の閲覧端末１０４Ｓに対して、送信したｅＤｏｃが閲覧されたことを示す通知を送る。送信者は、閲覧端末１０４Ｓでその通知を見ることで、送ったｅＤｏｃが閲覧されたことを知る。また、管理システム２００及び送信側の処理装置１１０Ｓは、ｅＤｏｃが閲覧された旨の通知に応じて、そのｅＤｏｃに対応する付箋メタデータ中の閲覧済みフラグを「閲覧済」に変更する。
以上に説明したように、本実施形態では、ｅＤｏｃファイルは、送信側の処理装置１１０Ｓから受信側の処理装置１１０Ｒに、管理システム２００を初めとする途中のサーバを介することなく、ピア・トゥ・ピアで直接転送される。このため、データを送信側から途中のサーバにいったん蓄積し、受信側がそのサーバからデータを取得する方式よりも、ｅＤｏｃの漏洩リスクが低い。処理装置１１０Ｒから受信者の閲覧端末１０４Ｒへは、ローカルシステム１００Ｒのローカルネットワーク１０８経由でｅＤｏｃファイルが転送される。ローカルネットワーク１０８はファイアウォール等でインターネット等の外部ネットワークから保護されているので、受信側のローカルシステム１００Ｒ内のｅＤｏｃが外部に漏洩するリスクも低い。
その一方、付箋メタデータその他のメタデータは、管理システム２００に登録され、送信側の処理装置１１０Ｓ及び受信側の処理装置１１０Ｒを初めとする様々な処理装置１１０から参照可能である。したがって、例えば、送信先のユーザが、処理装置１１０Ｒとは別の処理装置１１０のある場所に出かけているとき、そのユーザの閲覧端末１０４Ｒは当該別の処理装置１１０にアクセスし、送信者から送信されたｅＤｏｃファイルがあることを当該ｅＤｏｃのメタデータや付箋メタデータ（これらには送信先ユーザのＩＤが配信先又は送信先として含まれる）から認識し、そのｅＤｏｃファイルを当該別の処理装置１１０を介してダウンロードすることができる。
また本実施形態では、送信側の処理装置１１０Ｓと受信側の処理装置１１０Ｒの両方が、ｅＤｏｃの送信のためのセキュリティ要件を満たしてはじめて、それら両者間でのｅＤｏｃの転送がなされる。したがって、セキュリティが甘い状態（例えば十分な強度での伝送路暗号化がなされていない状態）でｅＤｏｃが転送されることがない。
以上にて図２４を参照して説明した処理の流れでは、まず送信元の処理装置１１０ＳがｅＤｏｃ送信のためのセキュリティ要件を満たすか否かを判定し、満たすと分かった場合に、送信先の処理装置１１０Ｒがセキュリティ要件を満たすか判定した。しかし、この流れは一例に過ぎない。送信元の処理装置１１０Ｓが、その処理装置１１０Ｓと送信先の処理装置１１０Ｒとの情報を含んだ付箋メタデータ（図２７参照）を管理システム２００に送ったときに、管理システム２００が処理装置１１０Ｓ及び１１０Ｒがそれぞれセキュリティ要件を満たすかどうかを判定してもよい。そして、いずれか一方でもセキュリティ要件を満たし得ない（すなわちリモートからの修正でも対処できない）と分かった場合に、管理システム２００がその付箋メタデータに係るｅＤｏｃ送信を不許可とする旨を処理装置１１０Ｓ（及び１１０Ｒ）に通知してもよい。
以上の例では、受信側の処理装置１１０Ｒが管理システム２００から送信側の処理装置１１０Ｓの情報（付箋メタデータに含まれる）を取得し、その情報を用いて送信側の処理装置１１０Ｓから対象のｅＤｏｃをダウンロードした。しかしこれは一例に過ぎない。この代わりに、送信側の処理装置１１０Ｓが管理システム２００から受信側の処理装置１１０Ｓの処理装置ＩＤや通信アドレス等の情報を取得し、この情報を用いて受信側の処理装置１１０Ｒに対してｅＤｏｃを転送してもよい。この場合、管理システム２００は、その転送が開始される前に、受信側の処理装置１１０Ｒに対して付箋メタデータを送り、処理装置１１０Ｒは、送信側の処理装置１１０ＳからｅＤｏｃが転送されてきた場合に、その転送元の処理装置ＩＤや転送されてきたｅＤｏｃのＤＩＤ等が、既に受信済みの付箋メタデータ内の対応項目の値に合致するか否かを確認するようにしてもよい。合致しない場合には、処理装置１１０ＲはそのｅＤｏｃを受け取らないようにしてもよい。
次に、ドキュメント送信のための別の実施形態として、一対多送信に対応するためのシステムの例を説明する。ここでいう一対多送信とは、送信対象のドキュメントについて、予め定めた閾値以上の数の送信先が指定されている場合の送信処理である。
上で図２４〜図２８を参照して説明したドキュメント（すなわちｅＤｏｃ）の送信処理では、ユーザから送信指示を受けた処理装置１１０Ｓ（送信側）が、受信側の処理装置１１０Ｒに対するドキュメントの送信処理を行った。この送信処理では、送信側の処理装置１１０Ｓが、セキュリティ要件を満たし、かつ受信側の処理装置１１０Ｒも対応可能な転送プロトコルを選択し、その転送プロトコルを用いてｅＤｏｃを処理装置１１０Ｒに送信する。ここで、ユーザからの送信指示の中で指定された送信先の数が多いと、処理装置１１０Ｓが送信先に対応する多数の処理装置１１０Ｒに対して上述の送信処理を行うこととなる。このように多数の処理装置１１０Ｒへの送信処理のために処理装置１１０Ｓの負荷が高くなると、処理装置１１０Ｓが行うべき他の処理、例えばユーザからのドキュメントの登録要求に対するｅＤｏｃ化等の処理、を妨げたり遅延させたりする可能性がある。
そこで、以下では、ｅＤｏｃの一対多送信のための送信側の処理装置１１０Ｓの処理負荷を軽減するための実施形態を、図２９〜図３０を参照して説明する。
図２９は、この実施形態のシステム構成の一例を示す。図２９に示す例では、管理システム２００には、インターネット等の広域ネットワークを介して複数の組織内管理システム１５０が接続されている。個々の組織内管理システム１５０は、図１２に例示したものと同様のものである。組織内管理システム１５０が設けられた組織内ネットワーク１６０−１、・・・１６０−Ｎ内（区別不要の場合は組織内ネットワーク１６０と総称）にはいくつかのローカルシステム１００が存在している。個々のローカルシステム１００は、組織内ネットワーク１６０に接続された処理装置１１０と１以上の作成端末１０２及び１以上の閲覧端末１０４を含む。なお、小規模な組織の場合のように、組織内ネットワーク１６０内に組織内管理システム１５０を設けず、その組織の処理装置１１０が中央の管理システム２００により直接管理される場合もある。
図２９のシステム構成では、管理システム２００内に送信プロキシサーバ２５０が設けられる。送信プロキシサーバ２５０は、一対多送信の実行が指示された場合に、個々の送信先の処理装置１１０Ｒへの送信処理を、その一対多送信の指示を受けた送信側の処理装置１１０Ｓに代わって実行する。図２９の例では、送信プロキシサーバ２５０は、管理システム２００内のメタデータサーバ２３０と接続されているが、これはあくまで一例に過ぎない。
図２９の例では、組織内ネットワーク１６０−１内のある作成端末１０２Ｓからあるユーザが処理装置１１０Ｓに対して一対多送信の指示を行ったものとする。この指示には、例えば他の組織内ネットワーク１６０−Ｎ内にある処理装置１１０Ｒ（受信側）に登録されたユーザを含む、閾値以上の送信先が指定されているものとする。
図３０にこの例におけるシステム各部の処理の流れを示す。以下、この図に示した処理の流れを説明していく。
（１）送信者が組織内ネットワーク１６０−１内の作成端末１０２Ｓから処理装置１１０Ｓにログインし、その処理装置１１０Ｓに対してドキュメント送信を指示する。この指示において、送信者は、処理装置１１０Ｓに対して、送信対象のドキュメントと１以上の送信先ユーザを指定する。送信先ユーザの指定は、例えばユーザＩＤを入力又は選択することにより行えばよい。また送信者は、送信対象のドキュメント（すなわちｅＤｏｃ）と共に送信する付箋に記すコメントを処理装置１１０Ｓに対して入力する。この例では、送信の指示において送信者が複数の送信先ユーザを指定する場合がある。作成端末１０２Ｓは、このようにして入力された送信先のユーザの情報、及び、送信対象のｅＤｏｃを特定する情報を含んだ送信指示の情報を、処理装置１１０Ｓに渡す。以上に説明した送信指示のための処理は、送信先ユーザが複数になる場合があることを除き、図２４〜図２８の実施形態の場合と同様でよい。
送信指示を受けた処理装置１１０Ｓは、その送信指示に含まれる送信先ユーザの数が予め定められた閾値以上であるかどうかを判定する。この閾値は、その送信指示が、送信プロキシサーバ２５０が送信代行を行う「一対多」送信に該当するための最低限の送信先ユーザの数である。
図示は省略したが、指定された送信先ユーザの数がその閾値を下回る場合には、処理装置１１０Ｓは、その送信指示の処理の代行を送信プロキシサーバ２５０に依頼することはせず、図２４〜図２８の実施形態と同様の処理を行う。この場合、送信対象であるｅＤｏｃは管理システム２００側には送られず、処理装置１１０Ｓが自分の持つそのｅＤｏｃを、送信先に対応する処理装置１１０Ｒに提供することとなる。
（２）これに対し、指定された送信先ユーザの数がその閾値以上である場合には、処理装置１１０Ｓは、送信者からの一対多送信の指示に対する処理の代行を、自分の上位にある組織内管理システム１５０を介して管理システム２００（特にメタデータサーバ２３０）に依頼する。この依頼のために処理装置１１０Ｓが管理システム２００に渡す情報には、送信対象のｅＤｏｃ、送信先のリストが含まれる。また、このとき、図２４〜図２８の実施形態で説明した付箋メタデータ等、送信対象のｅＤｏｃに対応付けられる他のデータも、管理システム２００に渡してもよい。
（３）管理システム２００（特にメタデータサーバ２３０）は、処理装置１１０Ｓから一対多送信の処理代行依頼を受けると、その処理代行のための準備処理を行う。この準備処理では、管理システム２００は、その依頼の送信先のリストに含まれる各ユーザＩＤについて、そのユーザＩＤに対応する既定の処理装置ＩＤを求める。すなわち、送信先の各ユーザが登録されている処理装置１１０を特定する。送信先ユーザの中には、送信者と同じ組織内ネットワーク１６０内の処理装置１１０に登録されたユーザがいる場合もあれば、送信者とは異なる組織内ネットワーク１６０内の処理装置１１０に登録されたユーザがいる場合もある。そして管理システム２００は、求めた送信先ユーザのユーザＩＤと既定の処理装置ＩＤとの対応関係の情報を、送信対象のｅＤｏｃの識別情報（すなわちＤＩＤ）に対応付けた一次管理情報を生成する。
また管理システム２００は、一次管理情報に含まれる「既定の処理装置ＩＤ」に対応する処理装置１１０（以下、受信側の処理装置１１０Ｒと呼ぶ）のそれぞれについて、認証処理及びセキュリティ要件のチェックを行う。この処理は、図２４のステップ（３）についての上述した処理（この処理については図２８のセキュリティ要件チェックのフローも参照）と同様でよい。この認証及びセキュリティ要件チェックの処理により、送信先の各ユーザが登録されている処理装置１１０ＲがｅＤｏｃ送信のための安全な中継ポイントとなることが確認される。管理システム２００は、受信側の処理装置１１０Ｒのうち認証及びセキュリティ要件チェックの両方が成功したものを、送信対象のｅＤｏｃの転送先として選択する。セキュリティ要件チェックが失敗した処理装置１１０Ｒであっても、リモートからの修正（図２８のＳ５０４，Ｓ５０６参照）が可能であれば、その修正を実行し、ｅＤｏｃの転送先に選択する。また、管理システム２００は、転送先に選択した処理装置１１０Ｒごとに、その処理装置１１０Ｒが備える、セキュリティ要件を満足する転送プロトコルを特定し、特定した転送プロトコルのうち１つ（例えばセキュリティの強度が最も高いもの）をその処理装置１１０ＲへのｅＤｏｃの転送に用いるプロトコルとして選ぶ。
逆に受信側の処理装置１１０Ｒのうち認証又はセキュリティ要件チェックが失敗（後者についてはリモートからの修正処理が不可）したものについては、管理システム２００は、それらをｅＤｏｃの転送先には選ばず、それら処理装置１１０Ｒに対応する送信先ユーザについては、セキュアな送信が不可能である旨を示すエラーメッセージを、送信側の処理装置１１０Ｓを介して送信者の端末（例えば作成端末１０２Ｓ）に返す。
管理システム２００は、一次管理情報のうち、ｅＤｏｃの転送先に選択した各処理装置１１０Ｒに関する部分の情報を抜き出して「送信管理情報」を生成する。生成される送信管理情報には、送信対象のｅＤｏｃのＤＩＤが含まれると共に、更に、転送先に選択された処理装置１１０Ｒごとに、その処理装置１１０Ｒの処理装置ＩＤ、この処理装置１１０Ｒに対応する送信先のユーザＩＤ、その処理装置１１０ＲへのｅＤｏｃの転送に用いる転送プロトコルの識別情報、及び付箋メタデータが含まれる。
（４）管理システム２００は、生成した送信管理情報と、送信対象のｅＤｏｃとを送信プロキシサーバ２５０に渡し、一対多送信の実行を指示する。また管理システム２００は、転送先に選んだ各処理装置１１０Ｒに対して、ｅＤｏｃの受信開始を指示する。この指示は、図２８の処理手順のＳ５０８で行われる指示と同様のものである。ただし、この受信開始指示には、送信側の処理装置１１０Ｓの処理装置ＩＤや通信アドレスの情報の代わりに、送信プロキシサーバ２５０のＩＤや通信アドレスの情報が含まれる。またその開始指示には、対象となるｅＤｏｃのＤＩＤが含まれる。また付箋メタデータが更に含まれていてもよい。また管理システム２００は、送信対象のｅＤｏｃを送信プロキシサーバ２５０に渡すと、管理システム２００内にあるｅＤｏｃを削除する。なお、この削除は、指示された一対多送信の全ての送信先に対応する処理装置１１０ＲへのｅＤｏｃの送信が完了した時点に行うようにしてもよい。
（５）、（７）一対多送信の実行指示を受けた送信プロキシサーバ２５０は、ｅＤｏｃ受信開始指示を受け取った各処理装置１１０Ｒと協働して、その指示に付随する送信管理情報に従って一対多送信の処理を実行する。
すなわち、それら各処理装置１１０Ｒは、開始指示に含まれる情報を用いて、送信プロキシサーバ２５０に対してそのｅＤｏｃの転送要求を送る。この転送要求を受け取った送信プロキシサーバ２５０は、その転送要求が正当なものであるかどうかをチェックし、正当なものであれば、その転送要求の対象であるｅＤｏｃを、その転送要求の送信元の処理装置１１０Ｒに転送する。転送要求が正当なものであるかどうかをチェックは、図２４の処理のステップ（５）における処理と同様に行えばよい。すなわち、例えば、その転送要求の対象のｅＤｏｃのＤＩＤとその転送要求の送信元の処理装置１１０ＲのＩＤが、送信プロキシサーバ２５０が保持している送信対象のｅＤｏｃのＤＩＤとこれに対応する送信管理情報に含まれる転送先の処理装置のＩＤとの組合せに合致しているかどうかを判定することで行えばよい。
送信プロキシサーバ２５０から転送されたｅＤｏｃを受け取った処理装置１１０Ｒは、そのｅＤｏｃを、そのｅＤｏｃに対応する付箋メタデータに示される送信先のユーザのうち、当該処理装置１１０Ｒに登録されているユーザの端末に提供する。また、ユーザがその端末でそのｅＤｏｃを閲覧すると、閲覧済みを示す情報がその端末から処理装置１１０Ｒに送られる。
（６）送信プロキシサーバ２５０は、１つの一対多送信指示について、上述した閾値以上の送信先に対応する多数の処理装置１１０ＲへｅＤｏｃを送信するので、その一対多送信指示に対応するｅＤｏｃの送信が全て完了するまでにはある程度の時間がかかる。そこで、送信プロキシサーバ２５０は、例えば、１つまたは所定数の処理装置１１０ＲへのｅＤｏｃの送信処理が完了するごとに、又は、定期的に、管理システム２００に対して、その一対多送信の進捗状況を示す経過通知を送る。この経過通知には、例えばｅＤｏｃの送信が完了した処理装置１１０ＲのＩＤや、そのｅＤｏｃを閲覧したユーザのＩＤ等が含まれる。また管理システム２００は、その経過通知が示す情報を、そのｅＤｏｃのメタデータ（ＭＤ）に反映させる。このときメタデータに反映させる情報には、例えば、各処理装置１１０Ｒに対してそのｅＤｏｃの送信が完了した日時、その送信を行った装置（この場合は送信プロキシサーバ２５０）のＩＤ、各送信先ユーザによるそのｅＤｏｃの閲覧の有無、閲覧した場合にはその閲覧の日時、等が含まれる。
（８）送信管理情報に示される全ての転送先の処理装置１１０ＲへのｅＤｏｃの送信が完了すると、送信プロキシサーバ２５０は、完了通知を管理システム２００に送る。完了通知には、そのｅＤｏｃを閲覧したユーザのＩＤを含めてもよい。また管理システム２００は、その経過情報が示す情報を、そのｅＤｏｃのメタデータに反映させる。
また送信プロキシサーバ２５０は、一対多送信が完了したので、対象のｅＤｏｃを送信プロキシサーバ２５０内から削除する。
（９）送信プロキシサーバ２５０から完了通知を受け取った管理システム２００、その完了通知の対象である一対多送信指示の送信側の処理装置１１０Ｓに対して、その送信指示に対応する処理が完了したことを示す完了通知を送る。また、管理システム２００は、その処理装置１１０Ｓとの間で、そのｅＤｏｃのメタデータの内容を同期する。すなわち、送信されたｅＤｏｃのメタデータの項目のうち、各送信先ユーザへの送信完了や各送信先ユーザの閲覧完了等についての情報は管理システム２００が最新のものを持っているので、その最新の情報を処理装置１１０ＳにあるそのｅＤｏｃのメタデータに反映する。
（１０）完了通知を受けた処理装置１１０Ｓは、送信指示の入力元の作成端末１０２Ｓに対して、その指示に係る送信が完了した旨を通知する。
以上、図３０を参照して、送信プロキシサーバ２５０を用いた一対多送信の実施形態を説明した。上述の通り、この実施形態では、送信先の数が多い場合に、実体的な送信処理を管理システム２００内の送信プロキシサーバ２５０が代行するので、送信側の処理装置１１０Ｓが送信のために行う処理の負荷は少ない。
図２９及び図３０を参照して以上で説明した例では、一対多送信を送信プロキシサーバ２５０が代行するか否かを、指定されている送信先ユーザの数が閾値以上であるか否かで判定したが、これは一例に過ぎない。この代わりに、それら送信先ユーザが登録されている処理装置１１０Ｒ（すなわち送信先ユーザの「既定の処理装置」）の数が閾値以上であるか否かにより判定してもよい。複数の送信先ユーザが同一の処理装置１１０に登録されている場合、その処理装置１１０にｅＤｏｃを１回送れば、その処理装置１１０がそのｅＤｏｃをそれら複数の送信先ユーザに配信する仕組みとすることも考えられる。この仕組みの場合、送信側の処理装置１１０Ｓにとっての送信処理の負荷は、送信先ユーザの数ではなく、送信先の処理装置１１０Ｒの数に依存する。したがって、このような仕組みを用いる場合には、送信プロキシサーバ２５０による送信代行を行うかどうかを送信指示に係る送信先（すなわち受信側）の処理装置１１０Ｒの数で判定することが合理的である。
この場合、処理装置１１０は、自分が所属する組織の外部のユーザがどの処理装置１１０に登録されているのかは分からないことが一般的なので、送信プロキシサーバ２５０による送信代行を行うかどうかは管理システム２００が判定してもよい。例えば、送信側の処理装置１１０Ｓは、ユーザから指定された送信先のリストを含む送信指示を管理システム２００に送り、管理システム２００がその送信先のリストに含まれるユーザが登録されている処理装置１１０を特定すると共にそれら特定した処理装置１１０の合計数を求める。そして、その合計数が閾値以上であれば、管理システム２００は、処理装置１１０Ｓに送信対象のｅＤｏｃを要求し、この要求に応じて提供されたｅＤｏｃを、送信管理情報と共に送信プロキシサーバ２５０に渡し、これらの情報に基づき一対多送信を実行させる。なお、この送信管理情報には、上に例示したように、その送信先のリストに含まれるユーザが登録されている処理装置１１０Ｒのうち認証及びセキュリティ要件チェックの両方が成功した処理装置１１０Ｒの情報が含まれる。逆にその合計数が閾値未満であれば、管理システム２００は、送信先のリストに含まれるユーザごとの登録先の処理装置１１０のＩＤ及び通信アドレスの情報を処理装置１１０Ｓに提供し、処理装置１１０Ｓはその情報を用いて図２４〜図２８の例と同様の方法でそれら各送信先へのｅＤｏｃの送信を行う。
また、送信プロキシサーバ２５０による送信代行の可否を送信先ユーザの数に基づいて判定する場合でも、その判定を送信側の処理装置１１０Ｓではなく、管理システム２００が実行してもよい。この場合、処理装置１１０Ｓはユーザから受け取った送信指示の情報を管理システム２００に送り、管理システム２００がその送信指示の情報に含まれる送信先ユーザの数に基づいて、送信プロキシサーバ２５０による代行の可否を判定する。
また、送信プロキシサーバ２５０による代行の可否を管理システム２００が判定する方式の場合、処理装置１１０Ｓは、ユーザからの送信指示の情報を管理システム２００に送ってその判定を依頼する際に、その送信指示の送信対象であるｅＤｏｃを併せて管理システム２００に送ってもよい。このようにすると、送信プロキシサーバ２５０に代行させるという判定結果が得られた場合に、管理システム２００は既に受け取っているそのｅＤｏｃをその送信指示に係る一対多送信の対象として送信プロキシサーバ２５０に渡せばよい。すなわち、送信プロキシサーバ２５０に代行させるという判定結果が得られた後に、管理システム２００が処理装置１１０Ｓから送信対象のｅＤｏｃを取得して送信プロキシサーバ２５０に渡すよりも、送信プロキシサーバ２５０による送信代行の開始が早くなる。一方、送信プロキシサーバ２５０に代行させない（すなわち処理装置１１０Ｓ自身が送信する）という判定結果が得られた場合には、管理システム２００は、処理装置１１０Ｓに対して送信管理情報を渡し、その送信管理情報に従って送信先の各処理装置１１０Ｒに対してｅＤｏｃを送信するよう指示する。この送信管理情報は、上述のように、その送信先のリストに含まれるユーザが登録されている処理装置１１０Ｒのうち認証及びセキュリティ要件チェックの両方が成功した処理装置１１０Ｒの情報が含まれる。
また、図３０の例ではユーザの送信指示は作成端末１０２から入力されたが、閲覧端末１０４から入力することもあり得る。
また、図２９の例では送信プロキシサーバ２５０を中央の管理システム２００に設けたが、この代わりに、送信プロキシサーバ２５０を組織内管理システム１５０に設けてもよい。
以上に例示した作成端末１０２、閲覧端末１０４、処理装置１１０，１１０Ｓ及び１１０Ｒ、ローカルユーザＩＤサーバ１５２、ローカルＤＩＤサーバ１５４、ローカルメタデータサーバ１５６、ユーザＩＤサーバ２１０、ＤＩＤサーバ２２０、メタデータサーバ２３０、処理装置管理サーバ２４０、送信プロキシサーバ２５０等の各装置は、コンピュータに上述のそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、フラッシュメモリやＳＳＤ（ソリッドステートドライブ）、ＨＤＤ（ハードディスクドライブ）や等の固定記憶装置を制御するコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバス等を介して接続された回路構成を有する。それら各機能の処理内容が記述されたプログラムがネットワーク等の経由でフラッシュメモリ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
１０ 広域ネットワーク、１００ ローカルシステム、１０２ 作成端末、１０４，１０４Ｓ，１０４Ｒ 閲覧端末、１０８ ローカルネットワーク、１１０，１１０Ｓ，１１０Ｒ 処理装置、１１２ 管理情報記憶部、１１２ａ 管理情報、１１４ａ ユーザ情報、１３０ 認証デバイス、１５０ 組織内管理システム、１５２ ローカルユーザＩＤサーバ、１５４ ローカルＤＩＤサーバ、１５６ ローカルメタデータサーバ、２００ 管理システム、２１０ ユーザＩＤサーバ、２１２ 契約者データ、２１４ 一般ユーザデータ、２２０ ＤＩＤサーバ、２３０ メタデータサーバ、２４０ 処理装置管理サーバ、２５０ 送信プロキシサーバ。

Claims (12)

  1. 暗号化文書を記憶する記憶手段と、
    前記暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを管理システムへ送信する第１送信手段と、
    前記管理システムから前記第１のメタデータを受け取った受信側装置からの転送要求に応じて、前記暗号化文書を前記受信側装置へと送信する第２送信手段と、
    を備えた情報処理装置。
  2. 前記第１のメタデータには、前記情報処理装置の識別情報である送信側識別情報、前記受信側装置の識別情報である受信側識別情報、及び前記暗号化文書の文書識別情報が含まれ、
    前記第２送信手段は、前記第１のメタデータに含まれる前記受信側識別情報を持つ前記受信側装置から、前記第１のメタデータに含まれる前記文書識別情報を含む前記転送要求を受けた場合に、前記文書識別情報に対応する前記暗号化文書を前記受信側装置に送信する、
    請求項１に記載の情報処理装置。
  3. 前記情報処理装置自身のステータスを前記管理システムに送信するステータス送信手段、を更に備え、
    前記第１送信手段は、前記ステータス送信手段が送信した前記ステータスが条件を満たしている場合に前記管理システムが発する送信許可を受け取った場合に、前記第１のメタデータを前記管理システムに送信する、
    請求項１に記載の情報処理装置。
  4. 前記管理システムは、前記受信側装置のステータスが条件を満たす場合に前記受信側装置に前記暗号化文書の受信許可を与え、
    前記第２送信手段は、前記受信許可を受けた前記受信側装置からの転送要求を受けた場合に、前記暗号化文書を前記受信側装置に送信する、
    請求項３に記載の情報処理装置。
  5. 前記暗号化文書を閲覧可能なユーザ又は閲覧端末のうちの少なくとも一方を規定する情報を含んだ第２のメタデータを前記管理システムに送信する第３送信手段、を更に備え、
    前記受信側装置から前記暗号化文書を受け取った閲覧端末は、前記暗号化文書の内容をユーザに表示するか否かを、前記第２のメタデータに従って制御する、
    請求項１〜４のいずれか１項に記載の情報処理装置。
  6. コンピュータを、
    暗号化文書を記憶する記憶手段、
    前記暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを管理システムへ送信する第１送信手段、
    前記管理システムから前記第１のメタデータを受け取った受信側装置からの転送要求に応じて、前記暗号化文書を前記受信側装置へと送信する第２送信手段、
    として機能させるためのプログラム。
  7. 送信側装置が記憶する暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを管理システムから受信する第１受信手段と、
    前記第１受信手段が受信した前記第１のメタデータに含まれる情報を用いて前記送信側装置に前記暗号化文書の転送要求を送信し、前記転送要求に応じて前記送信側装置が送信した前記暗号化文書を受信する第２受信手段と、
    を備えた情報処理装置。
  8. 前記第１のメタデータには、前記送信側装置の識別情報である送信側識別情報、前記情報処理装置の識別情報である受信側識別情報、及び前記暗号化文書の文書識別情報が含まれ、
    前記第２受信手段は、前記第１のメタデータに含まれる前記送信側識別情報を持つ前記送信側装置に対して、前記第１のメタデータに含まれる前記文書識別情報を含む前記転送要求を送り、前記転送要求に応じて前記送信側装置から送信された前記暗号化文書を受信する、
    請求項７に記載の情報処理装置。
  9. 前記情報処理装置自身のステータスを前記管理システムに送信するステータス送信手段、を更に備え、
    前記第２受信手段は、前記ステータス送信手段が送信した前記ステータスが条件を満たしている場合に前記管理システムが発する許可を受け取った場合に、前記送信側装置に対して前記転送要求を送る、
    請求項８に記載の情報処理装置。
  10. コンピュータを、
    送信側装置が記憶する暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを管理システムから受信する第１受信手段、
    前記第１受信手段が受信した前記第１のメタデータに含まれる情報を用いて前記送信側装置に前記暗号化文書の転送要求を送信し、前記転送要求に応じて前記送信側装置が送信した前記暗号化文書を受信する第２受信手段、
    として機能させるためのプログラム。
  11. 送信側装置と、受信側装置と、管理システムとを備え、
    前記送信側装置は、
    暗号化文書を記憶する記憶手段と、
    前記暗号化文書の送信先に関する情報と、前記暗号化文書に付加されたメッセージとを含む第１のメタデータを前記管理システムへ送信する第１送信手段と、
    前記管理システムから受信側装置に送信された前記第１のメタデータに対し前記受信側装置にてアクセスが行われたことに応じて、前記暗号化文書を前記受信側装置へ送信する第２送信手段と、
    を備え、
    前記受信側装置は、
    前記管理システムから前記第１のメタデータを受信する第１受信手段と、
    前記第１受信手段が受信した前記第１のメタデータに対しアクセスが行われた場合に、前記第１のメタデータに含まれる情報を用いて前記送信側装置から前記暗号化文書を受信する第２受信手段と、
    を備える情報処理システム。
  12. 閲覧端末を更に備え、
    前記送信側装置は、前記暗号化文書を閲覧可能な配信先を規定する情報を含んだ第２のメタデータを前記管理システムに送信する第３送信手段を更に備え、
    前記受信側装置は、前記閲覧端末に対して前記暗号化文書を送信する手段を更に備え、
    前記閲覧端末は、前記受信側装置から前記暗号化文書を受信し、前記管理システムから前記暗号化文書に対応する前記第２のメタデータを受信し、前記暗号化文書の内容をユーザに表示するか否かを前記第２のメタデータに従って制御する、
    請求項１１項に記載の情報処理システム。
JP2019164090A 2018-03-15 2019-09-10 情報処理装置、情報処理システム及びプログラム Active JP6819748B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018048162 2018-03-15
JP2018048162 2018-03-15

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2018248249A Division JP6587029B2 (ja) 2018-03-15 2018-12-28 情報処理システム、情報処理装置、管理装置及びプログラム

Publications (2)

Publication Number Publication Date
JP2019212337A JP2019212337A (ja) 2019-12-12
JP6819748B2 true JP6819748B2 (ja) 2021-01-27

Family

ID=67906413

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2018248249A Active JP6587029B2 (ja) 2018-03-15 2018-12-28 情報処理システム、情報処理装置、管理装置及びプログラム
JP2019164090A Active JP6819748B2 (ja) 2018-03-15 2019-09-10 情報処理装置、情報処理システム及びプログラム

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2018248249A Active JP6587029B2 (ja) 2018-03-15 2018-12-28 情報処理システム、情報処理装置、管理装置及びプログラム

Country Status (2)

Country Link
US (1) US10938863B2 (ja)
JP (2) JP6587029B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7262964B2 (ja) * 2018-10-12 2023-04-24 株式会社東芝 情報処理装置、及び情報処理システム
JP7251236B2 (ja) * 2019-03-18 2023-04-04 富士フイルムビジネスイノベーション株式会社 処理制御システム、端末装置管理サーバ及びプログラム
US11736466B2 (en) * 2019-09-18 2023-08-22 Bioconnect Inc. Access control system
JP6982355B1 (ja) * 2021-06-28 2021-12-17 ブルーエストソフト インコーポレイテッドBluestSoft, Inc. 秘密データ送信システムおよび秘密データ送信方法
CN114567483B (zh) * 2022-02-28 2024-03-29 天翼安全科技有限公司 一种数据传输的方法、装置及电子设备

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004171396A (ja) 2002-11-21 2004-06-17 Fujitsu Ltd アクセス管理プログラムおよびアクセス管理装置
EP1480406A1 (en) * 2003-05-19 2004-11-24 Sony International (Europe) GmbH Confinement of data transfers to a local area network
JP3959441B2 (ja) * 2005-12-28 2007-08-15 クオリティ株式会社 管理システム，管理サーバおよび管理プログラム
JP4853240B2 (ja) * 2006-11-07 2012-01-11 富士ゼロックス株式会社 画像処理システムおよびプログラム
JP2010061390A (ja) * 2008-09-03 2010-03-18 Sumitomo Electric Ind Ltd コンピュータプログラム、ファイル転送システム、ファイル送受信方法
US9954689B2 (en) * 2013-06-13 2018-04-24 Pushfor Ltd. Method and system for sharing content files using a computer system and data network
US9336403B2 (en) * 2013-11-26 2016-05-10 Globalfoundries Inc. Managing restricted tagged content elements within a published message
JP2016139230A (ja) 2015-01-27 2016-08-04 株式会社リコー 文書管理装置、文書管理システム、文書管理方法及び文書管理プログラム
CN106302559B (zh) * 2015-05-11 2019-07-05 阿里巴巴集团控股有限公司 一种数据复制方法和设备
JP6634246B2 (ja) 2015-09-08 2020-01-22 信越ポリマー株式会社 導電性高分子溶液及び導電性塗膜
JP2017052851A (ja) 2015-09-08 2017-03-16 株式会社ブリヂストン ゴム組成物およびそれを用いたタイヤ
JP6706471B2 (ja) 2015-09-08 2020-06-10 株式会社大林組 ２液型木材塗料、及びその２液型木材塗料を用いた木材の難燃化処理方法
JP6390562B2 (ja) 2015-09-08 2018-09-19 信越化学工業株式会社 新規熱可塑性オルガノポリシロキサンの製造方法及び該熱可塑性オルガノポリシロキサン
JP2017180213A (ja) 2016-03-29 2017-10-05 株式会社豊田自動織機 電動圧縮機

Also Published As

Publication number Publication date
JP2019212337A (ja) 2019-12-12
US10938863B2 (en) 2021-03-02
US20190289039A1 (en) 2019-09-19
JP2019164758A (ja) 2019-09-26
JP6587029B2 (ja) 2019-10-09

Similar Documents

Publication Publication Date Title
US10917408B2 (en) Secure document management through verification of security states of information processing apparatuses in peer-to-peer transmission of encrypted documents
JP6572926B2 (ja) ドキュメント管理システム
JP6819748B2 (ja) 情報処理装置、情報処理システム及びプログラム
JP6575547B2 (ja) ドキュメント管理システム
AU2019261686B2 (en) Management apparatus and document management system
JP6708239B2 (ja) ドキュメント管理システム
JP2018156410A (ja) 情報処理装置及びプログラム
US20200084322A1 (en) Information processing apparatus, protection processing apparatus and terminal device
JP6777213B2 (ja) 情報処理装置及びプログラム
JP6849018B2 (ja) ドキュメント管理システム
JP6791308B2 (ja) ドキュメント管理システム、及び管理装置
JP7516798B2 (ja) ドキュメント管理システム、処理端末装置及び制御装置
JP6819734B2 (ja) 情報処理装置及び利用端末
JP6733791B2 (ja) 管理装置及び処理装置
JP2019207732A (ja) ドキュメント管理システム、管理装置及び処理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190910

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: 20201201

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201214

R150 Certificate of patent or registration of utility model

Ref document number: 6819748

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350