JP2008026925A - ファイル管理プログラム - Google Patents

Abstract

【課題】
ユーザの利便性を損なうことなく、ファイルの一元管理を行うファイル管理プログラムを提供すること。
【解決手段】
管理の対象としたい元ファイルの指定を受け付けるファイル指定部２１と、元ファイルを利用する際のポリシーを策定するポリシー策定部２２と、元ファイル毎に生成された共通鍵とポリシーに基づいて生成されたポリシーファイルと、共通鍵で暗号化された元ファイルとをパッケージしてパッケージファイルを生成するパッケージ部２３とを有し、ポリシーの利用条件を満足したユーザのみが、ポリシーファイル内の共通鍵と元ファイルの利用権限をユーザの端末４の一時メモリ上に展開出来るようにし、更に、共通鍵で復号化された元ファイルを前記一時メモリ上にのみ展開出来、利用権限の範囲内で元ファイルの利用が可能なようにパッケージファイルを生成することを特徴とする。
【選択図】図２

Description

本発明は、ファイル管理プログラムに関し、特に、利用条件を設定してファイルをパッケージし、またパッケージされたファイルを利用条件の範囲内で利用するためのファイル管理プログラムに関する。

従来、利用条件を設定して、データやソフトウェアを利用者に配信する配信システムとしては、特許文献１に示されるような配信システムがあった。

特許文献１に開示された配信システムでは、配信サーバが、利用成約付きデータ及びソフトウェアと利用条件を、配信先のクライアント端末に対応する暗号鍵を用いて暗号処理部で暗号化し、更にパッケージ部でパッケージ化した後、送信する。クライアント端末は、暗号処理部で暗号鍵を用いて利用条件を復号し、その利用条件が利用可であるときには、データ及びソフトウェアを復号してインストールする。

このような配信システムによれば、データ及びソフトウェアを再コンパイルすることなく、利用条件を付加及び暗号化し、クライアント端末において実行可能な形式で配信するように構成されているため、利用成約付きのデータ及びソフトウェアを容易に作成し、利用者に配布し、かつ、利用者が容易に利用成約付きのデータ及びソフトウェアを利用することが出来る。

しかし、このような配信システムには、以下に説明する技術的な課題があった。

特開２００２−１８９５２６号公報

特許文献１に開示された配信システムでは、利用条件は、データやソフトウェアを利用するクライアント端末毎の鍵で暗号化されるため、パッケージファイルは、自ずと端末クライアント毎に生成される。

従って、データやソフトウェアを例えば社内や社外の複数のユーザに利用させたい場合には、ユーザの数だけのパッケージファイルを生成する必要があり、複数ユーザ間でのデータの共有が出来ず、データの一元管理が困難であった。

本発明は、このような従来の問題点に鑑みてなされたものであって、その目的とするところは、ユーザの利便性を損なうことなく、ファイルの一元管理を行うことが出来るファイル管理プログラムを提供することにある。

請求項１の発明は、
ユーザ端末に格納、実行され、任意のユーザが作成した元ファイルの一元管理を行うためのファイルパッケージプログラムを有するファイル管理プログラムであって、前記ファイルパッケージプログラムは、管理の対象としたい元ファイルの指定を受け付けるファイル指定部と、前記元ファイルを利用する際のポリシーを策定するポリシー策定部と、前記元ファイル毎に生成された共通鍵と前記ポリシーに基づいて生成されたポリシーファイルと、前記共通鍵で暗号化された元ファイルとをパッケージしてパッケージファイルを生成するパッケージ部とを有し、前記ポリシーの利用条件を満足したユーザのみが、前記ポリシーファイル内の共通鍵と元ファイルの利用権限を前記ユーザの端末の一時メモリ上に展開出来るようにし、更に、前記共通鍵で復号化された元ファイルを前記一時メモリ上にのみ展開出来、前記利用権限の範囲内で元ファイルの利用が可能なように前記パッケージファイルを生成するファイル管理プログラムである。

請求項２の発明は、
更に、前記パッケージファイルのパッケージ履歴に関する情報や、前記パッケージファイルへのユーザのアクセス履歴に関する情報の検索を行う検索部を有するファイル管理プログラムである。

請求項１、請求項２の発明によれば、あらゆる種類のファイルを、ファイル毎に生成された共通鍵で暗号化した後、ポリシーファイルとともにパッケージして、利用条件を満足したユーザのみに元ファイルの利用権限を与える仕組みや、ユーザのアクセス履歴を確認する仕組みが、ユーザに提供されることになる。

しかも、元ファイルをパッケージするユーザは、利用権限を与えるユーザ数にかかわらず、１つのパッケージファイルを生成し、利用権限を与えらえたユーザのユーザ端末がアクセスすることが出来る記憶媒体に格納しておくだけで、元ファイルを複数ユーザ間で共有することが可能となる。

つまり、高いセキュリティレベルが維持された状態で、かつ、ユーザのパッケージファイル生成の際の利便性を損なうことなく、ファイルの一元管理を行うことが出来るようになる。

請求項３の発明は、
前記パッケージ部でパッケージファイルが生成されるとともに、前記元ファイルの利用権限が与えられたユーザのユーザ端末に、前記パッケージファイルの生成を、通知もしくは、前記パッケージファイルをメール添付により送信する通知部を有するファイル管理プログラムである。

請求項３の発明によれば、元ファイルの利用権限が与えられていないユーザのユーザ端末に、当該元ファイルがパッケージされたパッケージファイルの存在を不用意に知られないようにすることが出来るだけでなく、利用権限が与えられたユーザに、即時に、元ファイルの利用をさせることが出来る。

請求項４の発明は、
ユーザ端末に格納、実行され、任意のユーザが作成した元ファイルの一元管理を行うためのファイルパッケージプログラムによりパッケージされた元ファイルを復元してユーザが利用するためのファイル利用プログラムを有するファイル管理プログラムであって、前記ファイル利用プログラムは、パッケージファイルのうち、利用したい元ファイルがパッケージされているパッケージファイルの指定を受け付けるファイル指定部と、前記パッケージファイル内のポリシーファイルを構成しているポリシーの利用条件照合を行ない、前記元ファイルの利用が前記利用条件の範囲内の利用である場合、前記元ファイル毎に生成された共通鍵であって、暗号化に用いられた元ファイルの復号鍵と、前記元ファイルの利用権限とを、前記ポリシーファイルの中から取得するとともに、これら復号鍵と利用権限を前記ユーザ端末の一時メモリ上に展開する復号鍵解読部と、前記取得した共通鍵によって、前記パッケージファイル内の暗号化された前記元ファイルを復号化し、前記ユーザ端末の一時メモリ上に展開する復号化部と、前記取得した利用権限に基づいて、前記元ファイルの利用を制御するファイル利用制御部とを有するファイル管理プログラムである。

請求項４の発明によれば、元ファイルの利用権限や元ファイルの復号鍵は、利用条件を満足した場合にのみ解読可能なように、パッケージファイルに含まれているので、ユーザは、パッケージファイルに含まれたポリシーの利用条件を満足した場合のみ、元ファイルの利用権限を与えられ、利用権限が与えられていないユーザによる元ファイルの利用は出来ない仕組みが提供されることになる。つまり、当該、ファイル管理プログラム１により、高いセキュリティレベルが維持された状態で、利用権限が与えられたユーザによる元ファイルの利用が可能となる。

また、利用権限が、編集、保存以外の権限に限定されるのであれば、元ファイルの作成ユーザ以外のユーザが元ファイルを変更することは出来ないから、利用権限を与えられたどのユーザ間でも同一の元ファイルが共有されることになる。これは、パッケージファイルが、メール添付等の方法により、利用権限を与えられたユーザのユーザ端末に格納された場合でも、同一の効果を奏するものである。

つまり、ユーザは、自己のユーザ端末以外のユーザ端末にアクセスしなくても、結果的に、他のユーザと同一の元ファイルを共有することが出来るのである。このように、他のユーザと同一の元ファイルを共有することが出来るのは、元ファイルが元ファイル毎に生成された共通鍵で暗号化され、１の元ファイルにつき、ユーザ数によらず１つのパッケージファイルが生成されることにも起因している。

請求項５の発明は、
前記ファイル利用制御部は、前記元ファイルの対応ソフトを制御して、前記対応ソフトからユーザ端末のＯＳ若しくはミドルウェアに対して、前記取得した利用権限に基づいた機能呼び出し命令を行うＡＰＩフッキングを行う手段であるファイル管理プログラムである。

請求項５の発明によれば、あらゆる元ファイルに対応して閲覧、印刷、編集、保存等を行うような専用ソフトを作成しなくとも、既存の元ファイル対応ソフトを利用しながら、利用権限の制御を行うことが可能となる。

請求項６の発明は、
更に、前記パッケージファイル中の暗号化された元ファイルが復号化され、ユーザの利用権限に基づいて前記元ファイルの編集がなされた場合、編集後の元ファイルを再び前記ポリシーファイルとともにパッケージし、元のパッケージファイルを更新する再パッケージ部を有するファイル管理プログラムである。

請求項６の発明によれば、パッケージファイルの更新が行われることで、元ファイルの一元管理は継続して行われることになり、複数ユーザ間で共有しているような元ファイルの単一性も保持される。

請求項７の発明は、
前記元ファイルの再パッケージが行われた場合に、前記元ファイルの作成ユーザのユーザ端末もしくはサーバに、再パッケージが行われた旨を通知する通知部を有するファイル管理プログラムである。

請求項７の発明によれば、元ファイルの作成ユーザやサーバは、即時に、元ファイルが更新されたことを確認することが出来る。

請求項８の発明は、
前記ユーザ端末においてパッケージファイル内の元ファイルを利用しようとする毎に前記ユーザ端末による元ファイルの利用状況を更新することが出来る利用状況データベースを、前記ユーザ端末以外のユーザ端末による読みとり、更新が出来ないような状態で、前記ユーザ端末に生成するデータベース生成部を有するファイル管理プログラムである。

請求項８の発明によれば、利用状況データベースがユーザ端末に生成されることにより、当該ユーザ端末以外のユーザ端末で、元ファイルが不正に利用されるのを防止、検知することが出来る。

請求項９の発明は、
前記ポリシーファイルの一部又は全ては、サーバに格納されており、前記ファイル利用プログラムは、前記サーバに、前記ポリシーファイル内の利用条件の照合を要求するファイル管理プログラムである。

請求項９の発明によれば、ポリシーファイルの一部または全てをサーバに置くことによって、ポリシーファイルの改ざん等の不正行為を一層防止することが出来る。

請求項１０の発明は、
前記ポリシーファイルは、サーバ毎に生成された置換表によって置換された鍵によって、暗号化されており、前記置換表は、前記ファイル管理プログラムが前記ユーザ端末に格納されるとともに、前記ユーザ端末に格納されるファイル管理プログラムである。

請求項１０の発明により、パッケージファイルの単独での不正利用を防止することが出来る。

請求項１１の発明は、
前記ポリシーファイルは、利用条件が、複数のポリシーオブジェクトと対応付けて記述されたものであり、任意のポリシーオブジェクトに対応する利用条件が満足された場合には、別のポリシーオブジェクトを開くための鍵を取得することが出来、最終的に全てのポリシーオブジェクトの鍵が開かれ、全ての利用条件が満足された場合にのみ、前記復号鍵と利用権限を取り出すことが出来るような鎖状のデータ構造を有しているファイル管理プログラムである。

請求項１１の発明により、ポリシーファイルから容易に復号鍵と利用権限を取り出して不正に利用することはより困難になる。

請求項１２の発明は、
ファイル管理プログラムの登録ユーザかどうかの認証もしくは、前記利用条件に含まれる元ファイルの利用許可ユーザかどうかの認証を行う認証インターフェースを有しており、前記認証インターフェースは、ユーザからの要求によって決定した認証デバイス、もしくは、前記認証インターフェース側で予め決めた認証デバイスから出力された前記ユーザの第２パスワードと、当該認証デバイスの種類を、前記ファイル管理プログラムのログインＩＤ、パスワードとともに前記ユーザ端末からサーバに送信し、前記サーバに既に保存されているデータとの照合を依頼するファイル管理プログラムである。

請求項１３の発明は、
前記認証インターフェースは、前記認証デバイスが、暗号化ロジックの入るものであれば、前記サーバもしくは前記ユーザ端末に保存されているテンプレートデータのうち、前記ログインＩＤに対応するテンプレートデータを取得し、前記ユーザのＰＫＩ証明書によって、署名検証及び復号化して前記第２パスワードを取得し、前記サーバに既に保存されているデータとの照合を依頼するファイル管理プログラムである。

請求項１２、請求項１３の発明によれば、どのような種類の認証デバイスからユーザの認証結果をもらっても、サーバもしくはユーザ端末がユーザ認証を行えるようになり、また、ユーザが、ユーザ認証の数、組合わせを任意に変えることも出来るようになる。

本発明にかかるファイル管理プログラムによれば、あらゆる種類のファイルを、ファイル毎に生成された共通鍵で暗号化した後、ポリシーファイルとともにパッケージして、利用条件を満足したユーザのみに元ファイルの利用権限を与える仕組みや、ユーザのアクセス履歴を確認する仕組みが、ユーザに提供されることになる。

しかも、元ファイルをパッケージするユーザは、利用権限を与えるユーザ数にかかわらず、１つのパッケージファイルを生成し、利用権限を与えらえたユーザのユーザ端末がアクセスすることが出来る記憶媒体に格納しておくだけで、元ファイルを複数ユーザ間で共有することが可能となる。

また、元ファイルの利用権限や元ファイルの復号鍵は、利用条件を満足した場合にのみ解読可能なように、パッケージファイルに含まれているので、ユーザは、パッケージファイルに含まれたポリシーの利用条件を満足した場合のみ、元ファイルの利用権限を与えられ、利用権限が与えられていないユーザによる元ファイルの利用は出来ない仕組みが提供されることになる。

つまり、当該、ファイル管理プログラムにより、高いセキュリティレベルが維持された状態で、かつ、ユーザのパッケージファイル生成の際の利便性を損なうことなく、ファイルの一元管理及び利用を行うことが出来るようになる。

また、利用権限が、編集、保存以外の権限に限定されるのであれば、元ファイルの作成ユーザ以外のユーザが元ファイルを変更することは出来ないから、利用権限を与えられたどのユーザ間でも同一の元ファイルが共有されることになる。これは、パッケージファイルが、メール添付等の方法により、利用権限を与えられたユーザのユーザ端末に格納された場合でも、同一の効果を奏するものである。

つまり、ユーザは、自己のユーザ端末以外のユーザ端末にアクセスしなくても、結果的に、他のユーザと同一の元ファイルを共有することが出来るのである。このように、他のユーザと同一の元ファイルを共有することが出来るのは、元ファイルが元ファイル毎に生成された共通鍵で暗号化され、１の元ファイルにつき、ユーザ数によらず１つのパッケージファイルが生成されることにも起因している。

以下、本発明の好適な実施の形態について、添付図面に基づいて詳細に説明する。本発明のファイル管理プログラム１は、文書、画像（動画、静止画は問わない）等のドキュメントファイル（以下、単にファイルという）に含まれる情報が、社内外で当該ファイルに関する閲覧、印刷、編集、保存等の利用権限を有さない者へ漏洩し、不正利用されるのを防止するために使用されるものであり、ファイルの利用条件（ポリシー）を設定することで、ファイルの安全性を高めるためのプログラムである。

以下は、本発明のファイル管理プログラム１が、一般企業の社内外で利用されることを前提として説明を行うが、これはあくまで一実施例であり、家庭や個人によって利用されるものであってもよい。

ファイル管理プログラム１は、ユーザ端末４に格納、実行されるプログラムであって、任意のユーザがユーザ端末４において、任意のユーザが作成したファイルからパッケージファイルを作成し、ファイルの一元管理を行うためのファイルパッケージプログラム２と、ファイル作成ユーザ以外のユーザが、ユーザ端末４において、パッケージファイルから元のファイルを復元して当該ファイルを利用するためのファイル利用プログラム３とに大別される。尚ここでは、「ファイルの利用」とは、ファイルの閲覧、印刷、編集、保存等の行為を指す。

これらユーザ端末４は、図１に示されるように、社内では、ＬＡＮ６ａ等のネットワーク６を介して互いに接続されており、社外では、インターネット６ｂ等のネットワーク６を介して社内のサーバ５と接続される。また、社内のユーザ端末４ａは、社外へのアクセス時、各種の認証要求時、各種の情報登録時、また更に、本発明のファイル管理プログラム１のダウンロード時、ファイル管理プログラム１の利用時に、ネットワーク６を介してサーバ５に接続される。尚、社外のユーザ端末４ｂも、上記と同様の時に、ネットワーク６を介してサーバ５に接続される。

ユーザ端末４は、これらプログラムを格納し、実行・利用するために必要な構成（ＣＰＵ、一時メモリ４３、ハードディスク４４等の外部記憶装置、通信用デバイス、入出力デバイス等）を有するものであり、通常のコンピュータであればよい。

尚、ユーザ及びユーザ端末４は、本発明のファイル管理プログラム１を利用するために、サーバ５に対してユーザ登録を行ない、ユーザ及びユーザ端末４に関する情報をサーバ５に登録するものとする。本実施例では、ユーザとユーザ端末４とは、１対１で対応付けられており、１人のユーザと１台のユーザ端末４のセットに対して、１ユーザＩＤが付与される。

従って、例えば、ユーザが社内外に関わらず２台のユーザ端末４を所有する場合で、それぞれのユーザ端末４においてファイル管理プログラム１を利用する場合には、当該ユーザに対して２ユーザＩＤが付与されるものとする。尚、ユーザ端末４を問わず１人のユーザに対して１ユーザＩＤが付与されてもよいし、ユーザを問わず１台のユーザ端末４に対して１ユーザＩＤが付与されてもよい。

サーバ５は、ユーザ端末４と同様の構成を有する他、サーバソフトウェアを備えた通常のサーバコンピュータであればよい。尚、本実施例においては、サーバ５は、ユーザ情報やユーザ端末４のハードウェア情報等の情報を格納したユーザデータベース５５や、ユーザの認証に必要な認証情報を格納した認証データベース５７や、ユーザからのアクセス履歴やパッケージファイル作成履歴等の履歴情報を格納した履歴データベース５６等の各種データベースを備えている。

尚、サーバ５内のデータベースに格納されている情報の閲覧、印刷、編集、保存等の作業を行う権限は、サーバ５の管理者若しくは所定の認証許可がなされたユーザのみが有しており、それ以外の者（悪意者も含む）が、不正にその権限を濫用することは出来ない仕組み（例えば、ファイアウォールの組み込み、データベースの暗号化、認証システムへの接続、プロキシサーバの設置等）が、サーバ５には施されているものとする。

次に、図２に基づいて、ファイルパッケージプログラム２の構成について説明する。まず、ファイルパッケージプログラム２は、ユーザ端末４に格納され、ユーザ端末４において利用されるものであるが、プログラムの格納方法は問わず、例えば、サーバ５からインストーラとともにユーザ端末４にダウンロードされてもよいし、ＣＤ−ＲＯＭ等の記憶媒体からユーザ端末４にコピーされてもよい。

ファイルパッケージプログラム２は、主として、ファイル指定部２１、ポリシー策定部２２、パッケージ部２３、検索リクエスト部２４の機能ブロックから構成される。

ファイル指定部２１は、ユーザ端末４がアクセスすることが出来る記憶媒体に格納されたファイルのうち、管理の対象としたいファイルの指定を受け付ける手段である。例えば、ファイル指定部２１は、ユーザ端末４の画面上に、その時点でユーザ端末４が管理することが可能なファイルの識別情報（タイトル、作成日時、作成ユーザ、ファイルの種類（拡張子等）、ファイルのデータサイズ等）を表示させ、キーボードやマウス等の入力デバイスに当該情報のいずれかを選択させることで、ファイルの指定を受け付けることが出来る。

ポリシー策定部２２は、ファイル指定部２１で指定を受け付けたファイル（以下、元ファイルという）を利用する際のポリシーを策定する手段である。尚、本実施例では、策定したポリシーは、元ファイルの識別情報とともに、サーバ５に送信されるが、これらは必ずしもサーバ５に送信される必要はない。

ポリシーとは、例えば、元ファイルの利用許可／不許可ユーザかどうかの認証、パスワードその他の認証、ファイルの利用可能回数、元ファイルの利用期限、ファイルへの同時アクセス可能台数、アクセス可能時間等の利用条件と、これら利用条件を満足した場合に与えられる利用権限（例えば、元ファイルの閲覧、印刷、編集、保存等の利用形態）である。

ここでサーバ５は、図２に示されるように、鍵生成部５１と、ポリシーファイル生成部５２を機能ブロックとして有している。

鍵生成部５１は、元ファイルを暗号化（復号化）するための暗号鍵（復号鍵）を生成する手段である。本発明では、ファイルの暗号化、復号化は、共通鍵暗号方式で行われる。つまり、暗号鍵と復号鍵は共通であって、元ファイル毎に１種類のみ生成される。そのため、以下においては、暗号鍵も復号鍵と称して説明するものとする。

尚、本実施例では、鍵生成部５１で生成される復号鍵は、ポリシー策定部２２でポリシーが策定される毎に（かつ元ファイル毎に）生成される乱数であるが、ポリシー毎に異なるように生成される鍵であれば、必ずしも乱数である必要はない。

ここで、ファイルの暗号化、復号化に、共通鍵暗号方式が採用されているのは、ユーザ端末４でファイルの暗号化、復号化を行うのにかかる処理時間が、公開鍵暗号方式を用いた場合の暗号化、復号化処理時間と比較して短く、ユーザ端末４の負担が少ないからである。

しかし、共通鍵暗号方式を用いて、例えば、サーバ５で生成された暗号鍵をファイルの暗号化に用いる場合や、暗号化されたファイルを特定のユーザにのみ暗号鍵と同一の復号鍵で復号化させる場合、一般的には、鍵の受け渡し方法が問題となることが多い。暗号鍵と復号鍵が同一である以上、ひとたび鍵が第三者に知られてしまえば、誰でも暗号化されたファイルを復号化することが可能となり、ファイルを暗号化した意味がなくなるからである。

そこで、本発明では、共通鍵で暗号化されたファイルであっても、鍵を知っているだけでは暗号化されたファイルを復号化することが出来ず、ポリシー策定部２２で策定されたポリシーの利用条件が満足された場合のみ、暗号化されたファイルの復号鍵と、ファイルの利用権限を取得することが出来る仕組みを採用した。

ここで、ポリシーファイル生成部５２は、ポリシー策定部２２で策定されたポリシーと、鍵生成部５１で生成された復号鍵に基づいて、ポリシーファイルを生成する手段である。ポリシーファイルは、例えば、ＸＭＬ形式のデータであって、復号鍵とポリシーを記述したものであるが、詳細には、ポリシー内の利用条件は複数のポリシーオブジェクトと対応付けて記述されており、あるポリシーオブジェクトに対応する利用条件が満足された場合には、別のポリシーオブジェクトを開くための鍵を取得することが出来、最終的に全てのポリシーオブジェクトの鍵が開かれ、すなわち、全てのポリシーの利用条件が満足された場合にのみ、復号鍵と利用権限を取り出すことが出来るような鎖状のデータ構造となっている。

このようなデータ構造により、ポリシーファイルから容易に復号鍵と利用権限を取り出して不正に利用することはより困難になる。また、仮に、復号鍵と利用権限をポリシーファイルの取得経路以外から知り得たとしても、後述する復号鍵解読部３４によって、ポリシーファイルの中から解読された復号鍵と利用権限を用いていなければ、暗号化された元ファイルの復号化、元ファイルの利用が出来ないようになっている。

尚、生成されたポリシーファイルは、ユーザ情報を格納するユーザデータベース５５内に、ユーザ毎にポリシーファイルの識別ＩＤを付与して格納されるとともに、ユーザ端末４にも送信される。この際、鍵生成部５１で生成された復号鍵も、ユーザデータベース５５に格納され、ユーザ端末４に送信されてもよい。

また、ポリシーオブジェクト毎にも識別ＩＤが付与され、鍵生成部５１でポリシーオブジェクトを開くための鍵が生成されるとともに、これらの情報もまたユーザデータベース５５に格納される。

また、ポリシーファイル生成部５２は、ユーザ端末４がサーバ５に接続しない場合には、ユーザ端末４に格納されるファイルパッケージプログラム２の機能ブロックとして含まれていてもよく、その場合には、ユーザ端末４は、サーバ５にポリシーを送信せず、自らポリシーファイルを生成し、ユーザ端末４内にポリシーファイルの識別ＩＤを付与して格納することになる。

ファイルパッケージプログラム２の構成の説明に戻ると、パッケージ部２３は、鍵生成部５１で生成された復号鍵で、元ファイルを暗号化し、暗号化された元ファイルと、ポリシーファイル生成部５２で生成されたポリシーファイル、ファイル基本情報とを１つにまとめてパッケージし、更にヘッダを付加して、新たなファイル（パッケージファイルという）を生成する手段である。パッケージ部２３がパッケージファイルを生成する際の概念図を図３に示す。

図３に示したように、暗号化された元ファイルと、ポリシーファイルとをパッケージすることによって、暗号化された元ファイルは、単独で取り出したり、利用することが不可能となり、ポリシーファイルとの連動のみによって利用することが可能となる。

つまり、全ての利用条件が満足された場合にのみ、利用権限を取得し、暗号化されたファイルを復号化することが出来るようになっているので、復号鍵が単独でユーザ端末４に送信されたり、知られてしまったとしても、パッケージファイルそのものがなければ、かつ、全てのポリシーの利用条件が満足された場合でなければ、暗号化された元ファイルを復号化することは出来ないので、暗号化されたファイルの安全性は確保される。

しかも、復号鍵は、ポリシーファイルに含まれ、更に暗号化された元ファイルとパッケージされているので、共通鍵暗号方式の問題である鍵の受け渡しについても、ユーザが意識せずに、かつ安全に行われる。

従来は、高いセキュリティレベルを維持しながら、特定ユーザに対してのみファイルの利用権限を与えるために、公開鍵暗号方式が採用されていた。しかし、公開鍵暗号方式の場合、公開鍵と秘密鍵を生成する手間、ファイルの利用権限が与えられるユーザの公開鍵を入手する手間、ユーザ毎の公開鍵でファイルを暗号化する手間がかかっていた。本発明のファイル管理プログラム１では、共通鍵暗号方式を用いているため、このような手間は発生せず、しかも、ファイル指定、ポリシー策定、パッケージという簡単な手順を経るだけで、セキュリティレベルの高いファイル管理が実現されることになる。

尚、ファイル基本情報は、元ファイルの識別情報であるところのタイトル、作成日時、作成ユーザ、元ファイルの種類（拡張子等）、元ファイルのデータサイズ等の情報に加え、元ファイルの利用許可／不許可ユーザリストが含まれる。また、パッケージファイルの識別情報であるところのタイトル、作成（パッケージ日時）、作成ユーザ（パッケージした者）、パッケージファイルの種類、パッケージファイルのデータサイズ等が含まれてもよい。

ここで、ファイル基本情報の暗号化は任意であり、また、基本的にファイル基本情報の内容は、元ファイルの利用権限を有していないユーザであっても知ることが出来る。これは、本件出願時点における法律上、全てのユーザに対し、元ファイルの利用／不許可を知る権利が認められているからである。

検索リクエスト部２４は、サーバ５内の検索部５３に対して、履歴データベース５６に格納されているファイルパッケージの履歴情報や、パッケージファイルへのアクセス履歴に関する情報の検索を要求する手段である。尚、履歴データベース５６には、ユーザデータベース５５に格納されているデータと同じものが格納されていてもよく、ユーザデータベース５５に格納されている履歴情報が検索されてもよい。

また、ファイル作成ユーザ自身が、自己のファイルパッケージ履歴や、自己のユーザ端末４内の共有記憶媒体への他ユーザのアクセス履歴を検索したい場合には、検索リクエスト部２４は、ファイル作成ユーザのユーザ端末４内のデータベース（例えば、後述する利用状況データベース３３ａ）に格納されている履歴情報にアクセスする手段であってもよい。

検索リクエスト部２４は、例えば、検索条件を指定し、当該検索条件をサーバ５に送信する。サーバ５の検索部５３は、履歴データベース５６内から、検索条件に合致する履歴情報を取り出し、ユーザ端末４に送信する。ここで、検索された履歴に基づいて、ユーザ端末４側では、更に、ポリシー策定部２２でポリシーの変更を行ったり、ファイル指定部２１でファイルの変更を行ったりすることが出来る。何らかの変更が行われた場合には、パッケージ部２３は、ファイルをパッケージし直す。この手順は、新規にファイルパッケージを行う場合の手順と同様であり、上述した通りである。

尚、履歴データベース５６には、パッケージファイルへのユーザのアクセス履歴も格納される。従って、ファイルのパッケージを行ったユーザは、検索リクエスト部２４から、誰がいつどこからどのパッケージファイルにアクセスしたかを確認することが出来る。

以上説明したファイル管理プログラム１内のファイルパッケージプログラム２の構成によれば、あらゆる種類のファイルを、ファイル毎に生成された共通鍵で暗号化した後、ポリシーファイルとともにパッケージして、利用条件を満足したユーザのみに元ファイルの利用権限を与える仕組みや、ユーザのアクセス履歴を確認する仕組みが、ユーザに提供されることになる。

しかも、元ファイルをパッケージするユーザは、利用権限を与えるユーザ数にかかわらず、１つのパッケージファイルを生成し、利用権限を与えらえたユーザのユーザ端末４がアクセスすることが出来る記憶媒体に格納しておくだけで、元ファイルを複数ユーザ間で共有することが可能となる。

つまり、当該、ファイル管理プログラム１により、高いセキュリティレベルが維持された状態で、かつ、ユーザのパッケージファイル生成の際の利便性を損なうことなく、ファイルの一元管理を行うことが出来るようになる。

次に、図４に基づいて、ファイル利用プログラム３の構成について説明する。まず、ファイル利用プログラム３は、ファイルパッケージプログラム２同様、ユーザ端末４に格納され、ユーザ端末４において利用されるものであるが、プログラムの格納方法は問わず、例えば、サーバ５からインストーラとともにユーザ端末４にダウンロードされてもよいし、ＣＤ−ＲＯＭ等の記憶媒体からユーザ端末４にコピーされてもよい。また、ファイル利用プログラム３は、ファイルパッケージプログラム２と一体になってプログラム化されていてもよく、その場合には、ファイル管理プログラム１として、ユーザ端末４に格納される。

但し、ファイル管理プログラム１が提供する機能のうち、ファイル利用プログラム３側のファイル利用機能しか利用しないユーザや、ファイルパッケージプログラム２側のファイルパッケージ機能、履歴検索機能しか利用しないユーザには、それぞれ必要なプログラムのみがユーザ端末４に格納されていてもよい。

ファイル利用プログラム３は、主として、ファイル指定部３１、認証リクエスト部３２、データベース生成部３３、復号鍵解読部３４、復号化部３５、ファイル利用制御部３６、再パッケージ部３７の機能ブロックから構成される。

ファイル指定部３１は、ユーザ端末４がアクセスすることが出来る記憶媒体に格納されたパッケージファイルのうち、利用したい元ファイルがパッケージされているパッケージファイルの指定を受け付ける手段である。例えば、ファイル指定部３１は、ユーザ端末４の画面上に、パッケージファイルのファイル基本情報（パッケージファイルもしくは元ファイルのタイトル、作成日時、作成ユーザ、ファイルの種類（拡張子等）、元ファイルの利用許可／不許可ユーザ等）をさせ、キーボードやマウス等の入力デバイスに当該情報のいずれかを選択させることで、パッケージファイルの指定を受け付けることが出来る。

尚、元ファイルの利用権限が与えられていないユーザのユーザ端末４に、当該元ファイルがパッケージされたパッケージファイルの存在を不用意に知られないようにするためには、ファイル基本情報をユーザ端末４上に表示出来ないようにし、例えば、パッケージファイルがメールに添付されて、元ファイルの利用権限を与えられたユーザのユーザ端末４に送信されてきた場合のみや、指定の格納場所にあるパッケージファイル中の元ファイルが利用出来るようになった旨を通知するメール等の文書が、ユーザ端末４に送信されてきた場合のみに、ユーザ端末４が、パッケージファイルにアクセスすることが出来るようになっていてもよい。

つまり、この場合、ファイルパッケージプログラム２は、パッケージ部２３でパッケージファイルが生成されるとともに、元ファイルの利用権限が与えられたユーザのユーザ端末４に、パッケージファイルの生成を、通知もしくは、パッケージファイルをメール添付により送信する通知部（図示せず）を有している。これにより、元ファイルの利用権限が与えられていないユーザのユーザ端末４に、当該元ファイルがパッケージされたパッケージファイルの存在を不用意に知られないようにするだけでなく、利用権限が与えられたユーザに、即時に、元ファイルの利用をさせることが出来る。

認証リクエスト部３２は、本実施例では、ファイル利用プログラム３を利用しようとするユーザの認証をサーバ５に対して要求する手段である。尚、１ユーザ、１ユーザ端末４に対して１ユーザＩＤが付与されている場合には、当然、当該ユーザ端末４からユーザによって、サーバ５への認証要求がされなければ、認証がされない。

尚、認証リクエスト部３２は、必ずしもサーバ５に対して認証を要求する必要はなく、ユーザ端末４自身でユーザの認証を行う手段であってもよい。これについては、実施例において後述する。

データベース生成部３３は、ユーザがユーザ端末４においてパッケージファイル内の元ファイルを利用しようとする毎にユーザ端末４による元ファイルの利用状況（例えば、利用回数等）を更新することが出来る利用状況データベース３３ａを、当該ユーザのユーザ端末４以外のユーザ端末４による読みとり、更新が出来ないような状態で、ユーザ端末４に生成する手段である。

尚、ポリシー策定部２２で策定されたポリシーの利用条件うち、元ファイルの利用都度、元ファイルの利用状況を更新する必要がない利用条件（例えば、元ファイルの利用許可／不許可ユーザかどうかの認証、パスワードその他の認証、元ファイルの利用期限、同一パッケージファイルへの同時アクセス可能台数、アクセス可能時間等）によってのみ、ポリシーが生成されている場合には、データベース生成部３３は必ずしも利用状況データベース３３ａを生成する必要はない。

また、利用状況データベース３３ａに相当するデータベースは、必ずしもユーザ端末４に生成される必要はなく、サーバ５に生成されていてもよい。この場合、ファイルパッケージプログラム２内にデータベース生成部３３は不要である。

復号鍵解読部３４は、パッケージファイル内のポリシーファイルを構成している全てのポリシーオブジェクト内のポリシーの利用条件照合を行ない、暗号化された元ファイルの復号鍵とユーザの利用権限を取得するとともに、これら復号鍵と利用権限をユーザ端末４の一時メモリ４３上に取り出す手段であり、利用条件の照合及び利用状況の更新を行う照合・更新手段３４ａを有している。

照合・更新手段３４ａは、例えば、利用条件と元ファイルの利用状況とを照合する必要があるポリシーについては、利用条件と利用状況データベース３３ａに格納された利用状況との照合を行い、利用状況が利用条件に違反しない場合（例えば、利用可能回数１０回という利用条件に対し、利用状況が３回）に限り、利用状況データベース３３ａ内の利用状況を更新し、別のポリシーオブジェクトを開く鍵もしくは、暗号化された元ファイルの復号鍵を取り出す。

尚、この場合、サーバ５またはユーザ端末４のいずれかには、利用状況データベース３３ａの内容を更新させるためのプログラム（例えば計数手段、計時手段等）が必要である。また、利用状況データベース３３ａの生成場所や利用状況の更新方法については、ポリシーファイル内に格納されていてもよい。

また、照合・更新手段３４ａは、元ファイルの利用状況を更新する必要がない利用条件と、その利用状況（現況）との照合については、サーバ５に依頼してもよいし、また、ユーザ端末４内で行うことも出来る。

また、ポリシーオブジェクトの一部または全てが、サーバ５に格納されているような場合にも、照合・更新手段３４ａは、サーバ５にアクセスして、利用条件と利用状況との照合を要求し、照合結果や、次に開くべきポリシーオブジェクトの鍵をサーバ５から受け取る。

尚、サーバ５は、ユーザ端末４に照合結果や鍵を、予め生成されたユーザの公開鍵で暗号化してユーザ端末４に送信することが出来る。これにより、暗号化された照合結果や鍵は、ユーザの秘密鍵によってしか復号化されないため、照合結果や鍵の送信時の安全性がより高まる。

復号化部３５は、復号鍵解読部３４によって解読され、ユーザ端末４の一時メモリ４３に取り出された復号鍵を用いて、パッケージファイル内の暗号化された元ファイルを復号化する手段である。また、復号化部３５は、暗号化された元ファイルを復号化するだけでなく、復号鍵解読部３４と連動して、その他の暗号化されたデータを復号化する手段であってもよい。

ファイル利用制御部３６は、復号鍵解読部３４によって解読された利用権限に基づいて、復号化された元ファイルの利用を制御する手段である。また、ファイル利用制御部３６は、元ファイルのファイル識別情報に基づいて、元ファイルを開くための対応ソフト４２を起動させる手段を兼ねていてもよい。尚、対応ソフト４２は、ファイル利用プログラム３内に用意されていてもよい。例えば、あらゆる種類の元ファイルを閲覧することが出来るビューアー専用ソフトを、ユーザ端末４で利用することが出来るようになっていてもよい。

尚、ファイル利用制御部３６は、ＡＰＩ（Application Program Interface）フッキングを行う手段であってもよい。具体的には、元ファイルの対応ソフト４２内のビューアー等の全部または一部の機能が、ＯＳやミドルウェアで提供されている機能を呼び出すことによって実現されているような場合に、ファイル利用制御部３６は、対応ソフト４２を制御して、対応ソフト４２から、ＯＳ若しくはミドルウェアに対して、取得した利用権限に基づいた機能呼び出し命令を行う。これにより、あらゆる元ファイルに対応して閲覧、印刷、編集、保存等を行うような専用ソフトを作成しなくとも、既存の対応ソフト４２を利用しながら、利用権限の制御を行うことが可能となる。

尚、復号化部３５やファイル利用制御部３６は、復号鍵解読部３４における正規の解読過程を経て一時メモリ４３に取り出された復号鍵と利用権限を用いてのみ、暗号化された元ファイルを復号化したり、利用することが出来るものとする。例えば、単独で入力された復号鍵や利用権限を用いての復号化や利用がされそうになった場合には、復号化部３５やファイル利用制御部３６は、復号化や利用の過程をその場で中止させることが出来る。これにより、元ファイルの不正利用を防止することが出来る。

再パッケージ部３７は、パッケージファイル中の暗号化された元ファイルが復号化され、ユーザの利用権限に基づいて、元ファイルの編集がなされた場合、編集後の元ファイルを再びポリシーファイルとともにパッケージする手段である。

再パッケージ部３７は、編集後の元ファイルをパッケージしてパッケージファイルを生成した後は、元のパッケージファイルとの交換（もしくは元のパッケージファイルに上書き、更新）を行う。これにより、元のパッケージファイルは削除され、パッケージファイルが更新されることになる。

尚、元のパッケージファイルと再パッケージされたパッケージファイルとの基本的な相違は、元ファイルのデータ容量の相違のみであり、ファイル基本情報等の関連データは再パッケージに伴って更新される場合があるが、ファイル名や元ファイルの復号鍵は変わらない。また、例えば、元ファイルのハッシュ値に基づいて、改ざんや不正利用の検知の仕組みが採用されている場合には、当該ハッシュ値も更新される必要がある。

再パッケージ部３７によりパッケージファイルの更新が行われることで、元ファイルの一元管理は継続して行われることになり、複数ユーザ間で共有しているような元ファイルの単一性も保持される。

尚、再パッケージ部３７は、利用権限のうち、元ファイルの編集が許可された場合のみ機能するようになっていればよく、そもそも利用権限の中に、元ファイルの編集が含まれていない場合には、再パッケージ部３７は不要である。更に、本実施例では、元ファイルの編集が許可されたユーザによるポリシーファイルの編集は出来ないようになっている。これは、ポリシーファイルを編集して、元ファイルが不正に利用されるのを防止するためである。

また、再パッケージ部３７を有するファイル利用プログラム３は、元ファイルの再パッケージが行われた場合に、元ファイルの作成ユーザのユーザ端末４もしくはサーバ５に、再パッケージが行われた旨を通知する通知部（図示せず）を有していてもよい。これにより、元ファイルの作成ユーザやサーバは、即時に、元ファイルが更新されたことを確認することが出来る。

以上説明したファイル管理プログラム１内のファイル利用プログラム３の構成によれば、元ファイルの利用権限や元ファイルの復号鍵は、利用条件を満足した場合にのみ解読可能なように、パッケージファイルに含まれているので、ユーザは、パッケージファイルに含まれたポリシーの利用条件を満足した場合のみ、元ファイルの利用権限を与えられ、利用権限が与えられていないユーザによる元ファイルの利用は出来ない仕組みが提供されることになる。つまり、当該、ファイル管理プログラム１により、高いセキュリティレベルが維持された状態で、利用権限が与えられたユーザによる元ファイルの利用が可能となる。

また、利用権限が、編集、保存以外の権限に限定されるのであれば、元ファイルの作成ユーザ以外のユーザが元ファイルを変更することは出来ないから、利用権限を与えられたどのユーザ間でも同一の元ファイルが共有されることになる。これは、パッケージファイルが、メール添付等の方法により、利用権限を与えられたユーザのユーザ端末に格納された場合でも、同一の効果を奏するものである。

つまり、ユーザは、自己のユーザ端末以外のユーザ端末にアクセスしなくても、結果的に、他のユーザと同一の元ファイルを共有することが出来るのである。このように、他のユーザと同一の元ファイルを共有することが出来るのは、元ファイルが元ファイル毎に生成された共通鍵で暗号化され、１の元ファイルにつき、ユーザ数によらず１つのパッケージファイルが生成されることにも起因している。

ここで、利用状況データベース３３ａの詳細について説明する。利用状況データベース３３ａ内の情報の読みとり、更新は、復号鍵解読手段による復号鍵及び利用権限の解読過程に於いてのみしか行われず、その過程以外に於いて、利用者や悪意者による更新、改ざんはされないこととする。

そのため、ユーザ端末４に生成される利用状況データベース３３ａは、ユーザ端末４の識別情報（ＭＡＣアドレス、ＢＩＯＳのシリアル番号、ハードディスク４４のシリアル番号等）のハッシュ値等の一方向性関数によって暗号化されていてもよい。

尚、利用状況データベース３３ａ内の利用状況の無断更新、改ざん、不正利用等の検知は、公知のハッシュ（一方向性）関数技術等を用いれば可能である。例えば、利用状況を常に、直前に更新又は読みとりがされた時点の利用状況のハッシュ値で暗号化する等して、次の更新又は読みとり時に、正しいハッシュ値で暗号化されていたかどうかの整合性をチェックする。

不正な読みとりや更新が実行されていた場合には、次に正規の読みとりや更新をしようとしても、利用状況が本来のハッシュ値で暗号化されていないか、正しい復号鍵を手に入れることが出来ないため、暗号化された元ファイルの復号化が出来ない。

又、例えば、利用状況の更新を、例えば１ずつ減らす等、決められた数字でしか増減出来ないような仕組みにしておき、本来利用状況を２回から３回に更新すべきところを、０回に改ざんすることは不可能なようにすることも出来る。

このように、万一、不正な読みとりや改ざん等がされた場合には、その場で、ファイル利用プログラム３の動作や復号鍵の解読を中止させるか、レジストリ等に暗号化してバックアップしておいた正しい利用状況を読み込んで、改ざんされた利用状況データベース３３ａを元の状態に復元させるようにする。

利用状況データベース３３ａをユーザのユーザ端末４にのみ生成可能とするためには、パッケージファイルを、新規ユーザが初めて開こうとする際にのみ、利用状況データベース３３ａの生成が可能なプログラムを設けるか、ダウンロード前にサーバ５が予めユーザ端末４の識別情報（ＭＡＣアドレス、ＢＩＯＳのシリアル番号、ハードディスク４４のシリアル番号等）を認識し、その識別情報のハッシュ値等で利用状況データベース３３ａを暗号化しておき、他の識別情報を有する端末内では、暗号化された利用状況データベース３３ａを復号化出来ないようにするプログラムを設ける等する。

次に、利用状況データベース３３ａを初めに生成されたユーザ端末４以外の端末での読みとりを不可とするためには、復号鍵解読手段が利用条件と利用状況の照合を行う際に、サーバ５側に登録された識別情報を有するユーザ端末４に利用状況データベース３３ａが生成されているかどうかを確認し、利用状況データベース３３ａが見つからなかった場合には、ユーザ端末４以外の端末で元ファイルが利用されそうになったとみなし、元ファイルの利用を中止させる方法や、利用状況データベース３３ａをユーザ端末４毎に固有の識別情報のハッシュ値等で暗号化しておき、他の端末の識別情報のハッシュ値等では利用状況データベース３３ａを復号化出来ないようにする方法等が挙げられる。

更に、利用状況データベース３３ａを、利用状況の更新に用いる以外にも利用する場合の一実施例について説明する。

例えば、予め生成される利用条件の中に、ユーザ端末４の識別情報を１条件として加えておき、利用条件と利用状況の照合をする際に、利用状況として実際利用されているユーザ端末４の識別情報を調べ、利用条件としての本来利用権限を与えられたユーザのユーザ端末４の識別情報と合致しない場合には元ファイルの利用を中止させる方法をとってもよい。尚、この利用条件は、当然のことながらユーザ毎に異なるものとなるため、ポリシーファイルの共通化を図りたい場合には、当該利用条件に関するポリシーオブジェクトの利用条件や鍵は、サーバ５に格納されてもよい。

また、利用状況データベース３３ａをユーザやユーザ端末４の識別情報や固有の鍵によって暗号化することによって、利用状況データベース３３ａの中身が実質的に空であったとしても、復号鍵解読部３４が、利用状況データベース３３ａの存在を確認するようにすれば、自ずとユーザやユーザ端末４の認証を行うことにもなり、元ファイルの利用権限を有していないユーザやユーザ端末４による不正利用の防止に一層効果がある。

ここで、パッケージファイルのデータ構造の一例を図５に示す。図５に基づいて説明すると、パッケージファイルは、ルートディレクトリの下に、復号鍵及び利用権限の取得経路及び取得順序を示す鍵取得経路ディレクトリと、ポリシーオブジェクト毎の利用条件を示す利用条件ディレクトリと、暗号化された元ファイルを格納するファイルディレクトリと、ファイル基本情報の４つのディレクトリによって構成されている。

尚、鍵取得経路ディレクトリと、利用条件ディレクトリがポリシーファイルに相当する部分で、パッケージ部２３によって、このポリシーファイルと、暗号化された元ファイルと、ファイル基本情報とをパッケージしたのが、このパッケージファイルということになる。

鍵取得経路ディレクトリ下には、複数のポリシーオブジェクトが順番に並び、最終的に取得可能な利用権限及び復号鍵も含まれている。そして、各ポリシーオブジェクト内には、照合・更新手段３４ａを起動し、次のポリシーオブジェクトを開くための鍵が含まれている。

尚、図５中、点線枠で囲まれた部分のポリシーオブジェクトと利用条件は、実際には、ポリシーファイル内に含まれておらず、サーバ５に格納されている。このように、ポリシーファイルの一部または全ては、サーバ５から取得することも可能である。ポリシーファイルの一部または全てをサーバ５内に置くことによって、ポリシーファイルの改ざん等の不正行為を一層防止することが出来る。

また、利用条件ディレクトリ下には、生成されたポリシーオブジェクトの種類に応じて、利用条件の初期値が含まれており、データベース生成部３３は、ユーザ端末４が元ファイルを初回利用する時に、この利用条件の初期値を利用状況データベース３３ａにコピー又は移動する。尚、利用状況データベース３３ａの生成場所や利用状況の更新方法についても、利用条件ディレクトリに格納されていてもよい。

尚、利用条件の初期値が必要なポリシーオブジェクトとは、前述したように、例えば、元ファイルの利用可能回数のように、ファイルの利用都度、その利用状況を更新し、次回のファイル利用時には更新された利用状況との比較を行う種類のものである。また、初期値を必要としないポリシーオブジェクトとは、例えば、元ファイルの利用期限のように、利用条件と、更新を必要としない利用状況との比較を行う種類のものである。

ここで、例えば、利用可能回数に関する利用条件の初期値は、例えば、１０回であれば１０回であるが、利用状況データベース３３ａに格納される数値は、「０回」もしくは「１０回」となる。

仮に、「１０回」と格納されている場合には、利用状況データベース３３ａは、元ファイルの利用の都度、１回ずつ回数を減らすように更新され、「０回」になった時点で元ファイルを利用出来なくなるので、照合・更新手段３４ａに於ける照合作業は実質的に不要となる。

一方、「０回」という格納されている場合には、照合・更新手段３４ａは、利用回数を増やすという利用状況データベース３３ａ内の更新作業を行い、かつ、利用条件との照合作業（１０回以下かどうかという判断）を行う必要がある。

つまり、復号鍵解読部３４内の照合・更新手段３４ａは、図６に示されるように、利用条件の種類に応じて、鍵に対応する利用状況データベース３３ａの場所を利用条件ディレクトリ下から探し出し、利用状況データベース３３ａの更新を行ない、次の鍵を取得する。又、場合によっては、対応する利用条件を利用条件ディレクトリ下から探し出して、利用条件と利用状況の照合を行う。そして、図５に示したポリシーファイル内の分岐した各ディレクトリに格納されている鍵と利用条件と利用状況格納場所とを相互に結び付ける役割を担う。

ポリシーファイルを含むパッケージファイルを図５に示したような木構造としていることにより、利用権限及び復号鍵は正規の順序を経ないと取得されないこととなる。又、一方のディレクトリ内のデータが他方のディレクトリ内のデータと対応されないと復号鍵が解読されないため、一部のディレクトリのみをコピーしたり、いずれかのディレクトリの格納場所やパス名が変わってしまうと、復号鍵解読手段との連携が行われなくなるので不正利用が行われにくい、という効果がある。

次に、ファイル管理プログラム１を用いて、あるユーザＡがファイルのパッケージを行ない、その後、パッケージファイルに含まれたファイルを他のユーザＢが利用する場合のプロセスの一例を図８から図１５までのフローチャート図及び図１、図２、図４、図６の構成図を用いて詳細に説明する。

尚。本実施例では、後述するサーバ情報格納ファイルがなければ、ファイル管理プログラム１の利用が出来ないものとする。従って、サーバ情報格納ファイルが、ファイル管理プログラム１のインストールと同時にユーザ端末４に格納されるか、または、インストーラが、サーバ情報格納ファイルの存在を条件としてファイル管理プログラム１のインストールを可能とするように構成されていることが望ましい。

まず、ファイル管理プログラム１を用いるユーザＡ，Ｂの双方は、それぞれにファイル管理プログラム１の利用規約に同意した後、ユーザ登録を完了しておく必要がある。

このユーザ登録の流れの一実施例について以下、図８のフローチャート図を参照しながら説明する。尚、以下のユーザ登録フローは、ユーザＡ，Ｂともに同じであり、ユーザ及びユーザ端末４の別を問わない。

ユーザ端末４は、ネットワーク６を介して、サーバ５等のコンピュータに格納されているユーザ登録用ホームページにアクセスするため、ユーザ登録用ホームページのＵＲＬを入力して、サーバ５に送信する（Ｓ１１０）。

サーバ５は、ユーザ端末４から受信したＵＲＬにあるユーザ登録用ホームページのデータをユーザ端末４に送信する（Ｓ１１５）。

サーバ５は、ユーザ端末４上に、ユーザ登録用ホームページ内のユーザ登録画面を表示させる。ユーザは、ユーザ登録画面上で、ユーザの識別情報やユーザ端末４の識別情報等の登録情報を入力し、サーバ５に送信する（Ｓ１２０）。尚、ユーザ端末４の識別情報等は、ユーザが入力しなくとも、ユーザ端末４から自動的に抽出され、サーバ５に送信されてもよい。

サーバ５は、ユーザ端末４から受信した登録情報をチェックし（Ｓ１２５）、入力漏れ等の不備があれば（Ｓ１３０）、エラーメッセージをユーザ端末４に送信する（Ｓ１３５）。尚、入力漏れ等の不備ではなく、例えば、登録情報に含まれるユーザのメールアドレスが既にサーバ５のユーザデータベース５５に登録済みであり（Ｓ１４０）、登録情報の一部が既登録の登録情報と異なる場合には、登録情報の更新がされたと判断し、サーバ５のユーザデータベース５５内の登録情報を更新する（Ｓ１４５）。

登録情報に不備や二重登録の恐れがなければ、サーバ５は、ユーザの公開鍵と秘密鍵のペアを生成し、サーバ５のユーザデータベース５５に格納する（Ｓ１５０）。ここで生成された公開鍵と秘密鍵のペアは、後で、ユーザ端末４とサーバ５とが何らかのデータの送受信を行う際や、ユーザ端末４自体がユーザの認証を行う際に用いられるが、鍵の生成は必須ではない。

更に、サーバ５は、ユーザ毎にユニークなＩＤ（ユーザＵＩＤ）と、ユーザ端末４毎にユニークなＩＤ（ユーザ端末ＵＩＤ）を生成し、これらとともに登録情報をユーザデータベース５５に格納し（Ｓ１５５）、ユーザ端末４に登録完了メッセージとともに、格納された登録情報と、生成された公開鍵と秘密鍵と、ユーザＵＩＤとユーザ端末ＵＩＤとを送信する（Ｓ１６０）。公開鍵と秘密鍵の生成が行われなかった場合には、鍵の送信は不要である。

尚、公開鍵と秘密鍵の送信の安全性に問題があるような場合には、これらの鍵を、サーバ５の秘密鍵で暗号化して、サーバ５の署名を付したり、ユーザ端末４のＭＡＣアドレス等のユニークな識別情報によって暗号化して、ユーザ登録がされたユーザ端末４においてしか、鍵を知ることが出来ないようにすることが出来る。

ユーザ端末４は、サーバ５が指定するユーザ端末４内の所定の場所（例えば、レジストリ内の所定の場所）に、登録情報を格納する（Ｓ１６５）。尚、この所定の場所とは、予め生成された利用状況データベース３３ａであってもよい。

次に、ユーザ登録を行ったユーザＡが、任意のファイルをパッケージする流れの一実施例について以下、図９から図１１までのフローを参照しながら説明する。尚、この前提として、ユーザＡは、上述したようにサーバ５にユーザ登録を行っている他、ユーザＡのユーザ端末Ａに、図２に示したようなファイルパッケージプログラム２をインストールしているものとする。

ユーザ端末Ａは、インストールされているファイルパッケージプログラム２を、画面上のアイコンをダブルクリックする等して起動する（Ｓ２１０）。

ユーザ端末Ａの画面上には、図１６に示すように、ファイルパッケージプログラム２へのログイン画面が現われるので、ユーザ端末Ａは、登録ユーザか否かの認証を行う（もしくはサーバ５に要求する）ため、ログインＩＤとパスワードの入力を、キーボード等の入力デバイスから受け付ける（Ｓ２１５）。尚、本実施例では、ログインＩＤは、ユーザ登録時に登録されたユーザのメールアドレスであり、パスワードは、ユーザ登録時にユーザが指定し、サーバ５の認証データベース５７に、ログインＩＤと対応させて格納している文字列である。

更に本実施例では、登録ユーザの認証精度を向上させるため、先に入力したパスワードによる認証を行う他、第２パスワードによる認証も行う。ここで、第２パスワードとは、ユーザが任意に指定することが出来る認証デバイスから得られる認証結果である。

認証デバイスは、ユーザ端末Ａに接続されていればよく、どんな種類のものでもよい。認証デバイスの認証方式としては、大別して、パスワードベースの認証、所有物認証（ＩＣカード、ＰＫＩ証明書を用いるＩＣカード、ＵＳＢキー、ＵＳＢトークン等）、生体認証（指紋、声紋、声紋、筆跡、顔、静脈等）の３種類がある。

本実施例では、どのような種類の認証デバイスからユーザの認証結果をもらっても、サーバ５もしくはユーザ端末Ａがユーザ認証を行えるようにするため、また、ユーザが、ユーザ認証の数、組合わせを任意に変えることが出来るようにするための認証インターフェースを、サーバ５もしくはユーザ端末Ａ内に有している。尚、認証インターフェースが、ユーザ端末Ａ内にあるのは、ユーザがサーバ５にアクセスしないで、ユーザ端末Ａ内での認証を要求する場合である。

認証インターフェースは、上記の認証方式を、（１）暗号ロジックが入るもの（一部のＩＣカード、ＵＳＢキー、生体認証等のＰＫＩを用いるもの）、（２）認証結果ＹＥＳ／ＮＯの２値のみ出力するもの（一部の生体認証、パスワードベースの認証）、（３）何らかの文字列を出力するもの（一部のＵＳＢキー、ＭＡＣアドレス、ＢＩＯＳシリアルナンバー等のデバイスＩＤを有するデバイス）というように、認証デバイスの出力データ（第２パスワード）の種類別に分類し、ログインＩＤ、パスワード、第２パスワード、第２パスワードの認証種類とを対応付けて、サーバ５もしくはユーザ端末Ａに保存しておく。

尚、（１）の暗号ロジックが入る認証方式の場合には、ログインＩＤ、パスワード、第２パスワード、第２パスワードの認証種類に加え、第２パスワードをＰＫＩ証明書に基づくユーザの公開鍵（以降、ＰＫＩ公開鍵という）で暗号化しユーザの秘密鍵（以降、ＰＫＩ秘密鍵という）で署名したデータ（テンプレートデータ）が、サーバ５もしくはユーザ端末Ａに保存される。

認証インターフェースは、ユーザからの要求によって決定した認証デバイス、もしくは、認証インターフェース側で予め決めた認証デバイスから出力されたユーザの第２パスワードと、当該認証デバイスの種類を、ログインＩＤ、パスワードとともにユーザ端末Ａから受け取って、既に保存されているデータと照合する。

尚、認証デバイスが、暗号化ロジックの入るものであれば、認証インターフェースは、既にサーバ５もしくはユーザ端末Ａに保存されているテンプレートデータのうち、ログインＩＤに対応するテンプレートデータを受け取り、ユーザのＰＫＩ証明書によって、署名検証及び復号化して第２パスワードを取得し、既に保存されているデータと照合する。

尚、認証インターフェースでは、ログインＩＤと第２パスワードの照合のみが行われてもよく、パスワードの照合を省略してもよい。

このように構成された認証インターフェースが、サーバ５もしくはユーザ端末４に備えられていれば、ユーザが認証種類の数、組合わせを任意に行って、ユーザ認証を要求することが出来、また、予め決められた認証種類の数、組合わせでのユーザ認証を行うことも出来るので、サーバ５もしくはユーザ端末４は、認証デバイスが追加された場合にも、柔軟に対応することが出来る。また、１種類のパスワードのみによる認証ではなくなるので、認証精度は向上し、パスワードの秘匿性を完全に保つ必要はなくなり、パスワードそのものをユーザ端末４に保存しておくことも可能となる。

図９のフローチャート図の説明に戻ると、認証インターフェースは、上述したように任意の認証デバイスから第２パスワードを取得する（Ｓ２２０）。

ここで、ユーザＡは、ユーザ端末Ａにおけるユーザ認証（ローカルログイン）か、サーバ５におけるユーザ認証（サーバログイン）かのいずれかを選択する（Ｓ２２５）。

尚、ローカルログインを行うためには、図８のユーザ登録フローの中で、ユーザＡの公開鍵と秘密鍵のペアが生成されており、かつ、ログインＩＤ、パスワード、第２パスワードとが対応付けられてユーザ端末Ａに保存されており、更に、生成された秘密鍵が第２パスワードによって暗号化された状態で、ユーザ端末Ａに保存されていることが必要である。

ローカルログインが選択された場合は、認証インターフェースは、ユーザ端末Ａでユーザ認証を行うのに必要なユーザ情報（ログインＩＤ、パスワード、第２パスワード、認証種類、公開鍵と秘密鍵のペア、第２パスワードで暗号化された秘密鍵）が登録されているか否かを確認する（Ｓ２３０）。当該ユーザ情報のうち、いずれか１つでも登録されていなければ、図９のＢのサーバログインのフローに進む。また、ローカルログインが選択されなかった場合にも、図９のＢに進む。

ユーザ情報が登録されていれば、認証インターフェースは、取得したユーザ情報とユーザ端末Ａに保存されているユーザ情報とを照合し、更に、ユーザ情報のうち、第２パスワードで暗号化された秘密鍵を、認証インターフェースが取得した第２パスワードによって復号化し、復号化された秘密鍵を、ユーザ端末Ａに既に保存されている秘密鍵と照合する（Ｓ２３５）。

本実施例における秘密鍵の照合方法を以下、詳細に説明する。本実施例では、ユーザ登録の際に、ローカルログインを行うかどうかの決定がされ、ローカルログインを行うと決定した場合には、ユーザ端末Ａに利用状況データベース３３ａが生成され、利用状況データベース３３ａ内に、ユーザＡの公開鍵と秘密鍵を含むユーザ情報が格納される。

更に、ユーザ登録時、ユーザＡの秘密鍵は、置換表によって別の鍵に置換された後、利用状況データベース３３ａを暗号化する。

置換表は、乱数等で生成された暗号解読表の一種であり、置換前と置換後の対応を表す表である。本実施例では、後述するように、この置換表を用いて、ポリシーファイルの暗号化も行っている。これにより、ポリシーファイルが直接、利用者や悪意者の目に触れられることがなく、ポリシーファイルの解読や不正利用がしづらくなる。

置換表は、サーバ情報格納ファイルに格納されている。サーバ情報格納ファイルは、サーバ５毎に生成されるファイルであり、つまりサーバ５を識別するためのファイルでもある。従って、ユーザ端末Ａがアクセスするサーバ５のＵＲＬが変更される場合等には、サーバ情報格納ファイル自体も変更されることになる。

サーバ情報格納ファイルには、置換表の他、サーバ情報格納ファイルの対応するサーバ５がファイル管理プログラム１の利用を許容するユーザＩＤの範囲と、サーバ５側のプログラムのＵＲＬと、ユーザ端末Ａとサーバ５が通信するための鍵（例えば、サーバ５の公開鍵等）が含まれている。尚、ここでの、ユーザＩＤの範囲は、ユーザＩＤのスタート値とマスク値（範囲）であってもよい。

サーバ５側のプログラムのＵＲＬと、ユーザ端末Ａとサーバ５が通信するための鍵は、ユーザ端末Ａがサーバ５にアクセスしてきた際に、サーバ５側のプログラムを初期化して、サーバ５の負担を軽減するため、また、ユーザ端末Ａからの暗号化通信を解読するためのものである。

本実施例では、ユーザＡが、ファイル管理プログラム１をユーザ端末Ａに格納する際に、サーバ情報格納ファイルを一緒に格納するようになっており、また、サーバ情報格納ファイルが一緒に格納されなければ、ファイル管理プログラム１を格納することが出来ないようになっている。これにより、パッケージファイルの単独での不正利用を防止することが出来る。

認証インターフェースは、暗号化された秘密鍵を、認証デバイスから取得した第２パスワードで復号化して秘密鍵を得て（Ｓ２３５）、更に、秘密鍵をサーバ情報格納ファイル中の置換表で置換して、暗号化された利用状況データベース３３ａを復号化する。復号化された利用状況データベース３３ａ内に保存されているユーザ情報と、認証インターフェースが取得したユーザ情報とを照合して問題がなければ、ユーザＡは、認証（ログイン）に成功したことになる（Ｓ２４０、Ｓ２４５）。

ユーザＡがログインに成功すると、ユーザ端末Ａの画面上に、利用状況データベース３３ａ内に保存されているユーザ情報のうち、名前や所属名等の情報が表示される（これをユーザ情報回復という）。

尚、ここまでのログイン過程で、置換表が存在しない、復号化がされない、照合結果が正しくない等の問題があれば、ログイン失敗となり（Ｓ２５０）、以降の手続きに進むことは出来ない。

次に、図１０のフローチャート図を参照しながら、サーバ５ログインの場合の流れを説明する。認証インターフェースは、ユーザ端末ＵＩＤがユーザ端末Ａに登録されているかどうか確認する（Ｓ３１０）。尚、本実施例では、ユーザ端末ＵＩＤが登録されているかどうかは、ユーザ端末Ａに、利用状況データベース３３ａが生成され、かつ、利用状況データベース３３ａ内にユーザ端末ＵＩＤが保存されているかどうかによって確認することが出来る。その他、ユーザ端末ＡのＭＡＣアドレス等の識別情報をユーザ端末Ａ自身から検出して、当該識別情報で暗号化された利用状況データベース３３ａを復号化することが出来るか等の方法によっても確認することが出来る。

ユーザ端末ＵＩＤが登録されていなければ、認証インターフェースは、サーバ５にユーザ端末Ａの識別情報を送信する（Ｓ３１５）。サーバ５は、当該ユーザ端末Ａの識別情報に基づいて、ユーザ端末ＵＩＤを生成し、登録する（Ｓ３２０）。

ユーザ端末ＵＩＤがユーザ端末Ａに登録されれば、認証インターフェースは、サーバ５に、ユーザＡのログインＩＤ、パスワード、第２パスワード、第２パスワードの認証種類を送信する（Ｓ３２５）。

サーバ５は、図２に示された認証部５４において、送信された情報と認証データベース５７に保存されている情報とを照合し（Ｓ３３０）、問題なければ、ユーザデータベース５５に保存されているユーザ情報をユーザ端末Ａに送信する（Ｓ３３５）。尚、この時、サーバ５は、ユーザ端末Ａのユーザ情報とともに、他の登録ユーザのメールアドレスリストや、公開鍵リストを送信することも出来る。

照合の際に、問題があれば、ユーザ端末Ａにエラーメッセージを送信する（Ｓ３４０）。

サーバ５からユーザ情報を受信したということは、ユーザＡがログインに成功したということを意味する（Ｓ３４５）。ユーザ端末Ａは、このユーザ情報に基づいて、画面上に、ユーザ名、所属名等の情報を表示させる（ユーザ回復という）。

ここからは、図２の構成図と、図１１のフローチャート図を参照しながら説明する。ユーザ端末Ａは、ログインが完了したユーザに対して、ファイルパッケージプログラム２のファイルパッケージ用画面を表示する。図１７、図１８に、ファイルパッケージ用画面の一例を示す。

ユーザＡは、ファイルパッケージ用画面の任意のボタンをクリックする等して、ファイルパッケージプログラム２内の機能ブロックを有効にすることが出来る。

本実施例では、まず、ファイル指定部２１は、ユーザＡから、管理の対象としたいファイルの指定を受け付ける（Ｓ４１０）。図１７においては、暗号化対象ファイルの指定の参照ボタン、図１８においては、ファイル追加ボタンが、ファイルの指定受付に相当している。

次に、ポリシー策定部２２は、ユーザＡから、ファイル指定部２１で指定したファイル（以下、元ファイルという）を他のユーザが利用する際のポリシーの策定を受け付ける（Ｓ４２０）。図１７においては、セキュリティポリシーの設定画面における入力、図１８においては、ポリシー設定画面における入力が、ポリシーの策定の受付に相当している。

本実施例では、元ファイルの利用権限が与えられるユーザ／グループ（例えば、ユーザＢや、開発グループＡ等）、元ファイルの利用期限、元ファイルの利用回数、元ファイルを利用するためのパスワード、元ファイルの利用権限（利用形態）等のポリシーを策定する。

ポリシーは、図１７においては、許可ユーザ／グループの選択、許可する操作（印刷、編集、保存、閲覧）の選択、閲覧条件（期間、回数、ファイルパスワード）の選択から構成されており、図１８においては、動作（見る、プリント、保存、編集）の設定、期間と回数（期間、期限、回数）の設定、ユーザとグループの設定、サーバチェック（使用都度サーバ５で権利をチェックするか、一定の頻度でサーバ５で権利をチェックするか、使用できるクライアント（端末）数を制限するか）の設定、パスワードの設定から構成されている。

尚、本実施例では、元ファイルの利用権限が与えられるユーザは、登録ユーザに限られ、ユーザ端末Ａは、予め、サーバ５から受信した登録ユーザのメールアドレスリストに基づいて、ユーザを選択する。ユーザは、例えば、所属グループ毎等に一括して選択されてもよい。図２２に、図１７の画面内の許可ユーザ／グループの選択画面の一例を示す。図２２に示したように、画面上の左段に表示されたアドレス帳の中から許可ユーザ／グループをクリック等によって指定し、右段の許可ユーザ／グループ欄に表示されるようにする。

ポリシー策定部２２は、ユーザＡがユーザ端末Ａ上で策定したポリシーに基づいて、ＸＭＬ文を生成する（Ｓ４２５）。尚、ここでＸＭＬ文が生成されるのは、策定されたポリシーの構造を明確化し、ポリシーオブジェクトと、利用権限と、復号鍵と、利用条件とからなるポリシーファイルを生成しやすくするためであるが、必ずしも、ＸＭＬ文が生成される必要はない。

尚、ＸＭＬ文の生成は、例えば、図１７において、暗号化ボタンがクリックされた時に行われてもよいし、図１８においては、ポリシーを保存するボタンがクリックされた時に行われてもよい。

ここでユーザＡは、ユーザ端末Ａ上で、ポリシーファイルの生成を行う（ローカルパッケージ）か、サーバ５上でポリシーファイルの生成を行う（サーバパッケージ）かを選択する（Ｓ４３０）。

ユーザＡによって、ローカルパッケージが選択された場合、後述するように、ユーザ端末Ａで鍵が生成され、生成された鍵は、ユーザＢが元ファイルを利用する際に用いられるが、この鍵はサーバ５には保存されない。従って、元ファイルの利用許可ユーザの認証方法は、自ずとローカルログインにしか対応しないようになる。

そのため、ユーザ端末Ａは、元ファイルの利用許可ユーザ（ここではユーザＢ）毎に予め生成された公開鍵を取得する（Ｓ４３５）。尚、公開鍵の取得方法は任意である。例えば、ユーザＡが、サーバログインを行った場合には、ログイン成功時に、サーバ５から登録ユーザの公開鍵リストを受信していてもよい。また、ユーザＡがユーザ登録を行った際に、同様の公開鍵リストを受信していてもよい。また、都度、サーバ５にアクセスして、利用許可ユーザの公開鍵を取得してもよい。本実施例では、公開鍵を公開していないユーザに対しては、元ファイルの利用時にローカルログインを行えないため、ユーザ端末Ａは、サーバパッケージしか行なえない。

ここで、ローカルパッケージを選択したユーザ端末Ａは、図２においてサーバ５が有している鍵生成部５１と同じ機能ブロックを有しているものとする。そこで、ユーザ端末Ａの鍵生成部５１は、元ファイルを暗号化するための乱数の復号鍵の他、後で生成されるポリシーファイルのポリシーオブジェクトを開くための鍵をポリシーオブジェクトの数だけ生成する（Ｓ４４０）。

更に、ユーザ端末Ａの鍵生成部５１もしくは、暗号化部（図示せず）は、鍵生成部５１で生成された鍵のうち、ポリシーオブジェクトを開くための鍵を、先に取得した各利用許可ユーザの公開鍵で暗号化する（Ｓ４４５）。これは、利用許可ユーザの自己の秘密鍵でしか、鍵を復号化できないようにすることで、利用許可ユーザのみに元ファイルの利用をさせるためである。

ユーザ端末Ａは、図２においてサーバ５が有しているポリシーファイル生成部５２と同じ機能ブロックを有しているものとする。そこで、ユーザ端末Ａのポリシーファイル生成部５２は、利用条件と、利用権限と、復号鍵と、ポリシーオブジェクトを開くための鍵とを一体化して、図５に示したようなディレクトリ構造のポリシーファイルを生成する（Ｓ４５０）。本実施例では、ポリシーファイルも、策定されたポリシー同様、ＸＭＬ形式で生成される。尚、ポリシーファイルは、ここで、所定の置換表により置換されてもよい。

一方、Ｓ４３０において、ユーザＡが、ローカルパッケージ以外のパッケージ方法、すなわち、サーバパッケージを選択した場合には、ユーザ端末Ａからサーバ５に対し、先に生成されたＸＭＬ形式のポリシーが送信される（Ｓ４５５）。

サーバ５は、ポリシーを受信し、ＸＭＬ文に含まれるポリシーの構造を解析する（Ｓ４６０）。ここで、ポリシーに基づいて、複数のポリシーオブジェクトが生成されてもよい。

サーバ５の鍵生成部５１は、受信したポリシーに基づいて、元ファイルを暗号化するための乱数の復号鍵や、ポリシーオブジェクトの数だけの鍵を生成する（Ｓ４６５）。

サーバ５のポリシーファイル生成部５２は、鍵生成部５１が生成した鍵に基づいて、履歴データベース５６に元ファイルのパッケージ履歴を格納するとともに（Ｓ４７０）、鍵生成部５１で生成した鍵と、ポリシー策定部２２で策定されたポリシーに基づいてポリシーファイルを生成する（Ｓ４７５）。尚、ポリシーファイルは、所定の置換表により置換されてもよい。

サーバ５は、生成されたポリシーファイルを、ユーザ端末Ａに送信する（Ｓ４８０）。

ユーザ端末Ａのパッケージ部２３は、ローカルパッケージの場合にユーザ端末Ａで生成されたポリシーファイルもしくは、サーバパッケージの場合にサーバ５で生成されたポリシーファイルに基づいて、元ファイルを復号鍵で暗号化するとともに、暗号化された元ファイルとポリシーファイルとをパッケージし、パッケージファイルを生成する（Ｓ４８５）。Ｓ４２５からＳ４８５までの一連の流れは、図１７における暗号化ボタンや、図１８におけるポリシー設定ボタンのクリックに伴い、行われてもよい。

尚、ユーザＡは、ユーザＡ以外のユーザに元ファイルが改ざんされるのを検知できるように、生成されたパッケージファイルに署名を付けてもよい。尚、署名は、改ざんの検知対象となる元ファイルのハッシュ値をユーザＡの秘密鍵で暗号化して、パッケージファイルに付される。

パッケージファイルは、ユーザＡが指定する所定の格納場所に格納される。所定の格納場所に格納されたパッケージファイルは、利用許可ユーザが即座に開くことが出来るよう、生成されると同時に、図１９に示すように、利用許可ユーザ宛のメールに添付されて送信されてもよい。また、図１９の下段に示すように、メール本文に、利用許可ユーザに設定されたポリシーに関する情報が表示されてもよい。

また、ユーザ端末Ａの検索リクエスト部２４は、ユーザＡがパッケージファイルを作成した履歴を履歴データベース５６に基づいて検索することが出来る。図２０、図２１に、ユーザ端末Ａ上に表示されるパッケージ履歴検索画面の一例を示す。このようなパッケージ履歴検索画面を用いれば、ユーザＡは、どのユーザのためにどのような利用条件で、元ファイルをパッケージしたかを把握することが出来る。また、ポリシーの見直しや、ポリシーの修正に伴う元ファイルの再パッケージを行うことも可能となる。

次に、ユーザＢが、ユーザＡのユーザ端末Ａでパッケージされたパッケージファイル中の元ファイルを利用する場合の一例を、図４の構成図と、図１２〜図１５のフローチャート図を参照しながら説明する。尚、ユーザＢのユーザ端末Ｂには、ファイル利用プログラム３がインストールされているものとする。

ユーザＢは、ユーザＡが先にパッケージを行ない、ユーザ端末Ｂがアクセスすることが出来る記憶媒体に格納されたパッケージファイルを、ユーザ端末Ｂ上でダブルクリックする等して指定する（Ｓ５１０）。

尚、ユーザＢはユーザＡから、ユーザＢが利用可能な元ファイルがパッケージされたことの通知を受けるか、もしくは、図１９に示したように、ユーザ端末Ａが元ファイルのパッケージを完了すると同時に、ユーザ端末Ａからユーザ端末Ｂに対して、パッケージファイルが添付された電子メールが自動的に送信されるようになっていてもよい。また、先にファイル利用プログラム３を起動させ、ファイル指定部３１が、ユーザＢが利用したいパッケージファイルの指定を受け付けるようにしてもよい。

本実施例では、ユーザ端末Ｂは、パッケージファイルの指定に連動して、インストール済みのファイル利用プログラム３を起動させるようになっており、まず、ファイル利用プログラム３は、指定されたパッケージファイルのファイルフォーマットのチェックを行う（Ｓ５１５）。

更に、ファイル利用プログラム３は、パッケージファイルから、当該パッケージファイルを利用することが可能なユーザＩＤの範囲に関する情報（ＩＤスペース情報）を取り出し（Ｓ５２０）、ファイル利用プログラム３は、取り出されたＩＤスペース情報に対応するサーバ情報格納ファイル及び置換表が、ユーザ端末Ｂに格納されているかを確認する（Ｓ５２５）。ここで、置換表が存在しない場合には、パッケージファイルは、ユーザＢがファイル利用プログラム３によって利用することが出来ないファイルであるので、ユーザ端末Ｂにエラー通知を行う（Ｓ５３０）。

置換表が存在する場合には、ファイル利用プログラム３は、パッケージファイルから、ファイル基本情報を取り出す（Ｓ５３５）。

ファイル利用プログラム３は、取り出されたファイル基本情報に基づいて、ユーザ端末Ｂの画面上に、元ファイルの利用許可ユーザ／不許可ユーザ等のユーザリストを表示する（Ｓ５４０）。

ユーザＢは、ユーザ端末Ｂの画面表示に基づいて、元ファイルの利用許可ユーザに含まれていることを確認した上で、ファイル利用プログラム３へのログインを行う（Ｓ５４５）。ファイル利用プログラム３へのログインの流れの一例は、先に図９、図１０のフローチャート図で、ファイルパッケージプログラム２へのログインについて説明したのと同様であるので、説明及び図示を省略する。

尚、ファイル利用プログラム３のログイン時には、ユーザＢが、ファイル管理プログラム１の登録ユーザかという認証のみならず、元ファイルの利用権限を有するものであるかの認証が行われてもよい。その場合で、かつ、サーバログインを行う場合には、ユーザ端末Ｂからサーバ５に、ユーザＢの認証情報とともに、パッケージファイルまたは元ファイルの識別情報が送信され、サーバ５の認証部５４は、これら受信した情報が、認証データベース５７に格納されているかに基づき、ユーザＢの認証を行う。

また、ユーザＢが元ファイルの利用権限を有するユーザであるかどうかは、ポリシーの利用条件の１つとなって、復号鍵解読部３４が利用条件の照合時に認証するものであってもよい。認証方法としては、ユーザ端末Ｂに、利用許可ユーザの識別情報で暗号化された、ないしは当該識別情報が記述された利用状況データベース３３ａが生成されているかどうかの確認を行うことも挙げられる。

ログイン成功以降の流れは、図１３〜図１５のフローチャート図と、図４、図６の構成図を参照しながら説明する。尚、本実施例では、特定のパッケージファイルを初めて利用する際には、データベース生成部３３は、ユーザ端末Ｂに利用状況データベース３３ａが生成するものとする。また、ポリシーファイルに含まれるポリシーオブジェクトは３つであるものとし、これら３つのポリシーオブジェクトがポリシーファイル内で連鎖接続され、最後に照合が行われる利用条件が含まれるポリシーオブジェクトに、暗号化された元ファイルの復号鍵と、元ファイルの利用権限が接続されているものとする。

ユーザＢがログインに成功すると、ファイル利用プログラム３に含まれる復号鍵解読部３４が起動し、ポリシーファイルの解読を開始する（Ｓ６１０）。ここで、パッケージファイルに含まれているポリシーファイルが暗号化されている場合（Ｓ６１５）、復号鍵解読部３４（もしくは復号化部３５）は、暗号化されたポリシーファイルを復号化するため、ユーザ端末Ｂに格納されている置換表を取り出す（Ｓ６２０）。

尚、ここで、ポリシーファイルは、図７に示すように、任意の鍵Ａを置換表によって置換した鍵Ｂによって、暗号化されているものとする。

復号鍵解読部３４（もしくは復号化部３５）は、サーバ情報格納ファイルやパッケージファイルのファイル基本情報内等に格納されている鍵Ａを取り出し（Ｓ６３０）、置換表を用いて、鍵Ａを鍵Ｂに置換する（Ｓ６３５）。ここで、鍵Ａから鍵Ｂへの置換がされなかった場合には、置換表が改ざんされたことになり、その改ざんを検知するとともに、以降のステップには進めないようにする（Ｓ６４０）。尚、置換された鍵Ｂは、一時メモリ４３上に展開される（Ｓ６４５）。

復号鍵解読部３４（もしくは復号化部３５）は、鍵Ｂを用いて、暗号化されたポリシーファイルを復号化する（Ｓ７１０）。ここで、暗号化されたポリシーファイルの復号化がされなかった場合には、何者かにより鍵Ｂの改ざんがされたことになり、その改ざんを検知するとともに、以降のステップには進めないようにする（Ｓ７１５）。

ポリシーファイルが復号化されたので、図６に示した復号鍵解読部３４の照合・更新手段３４ａは、ポリシーファイルを構成する３つのポリシーオブジェクトのうち、ポリシーオブジェクト１に対応する利用条件１を取り出すことが出来る（Ｓ７２０）。尚、最初の照合・更新手段３４ａの起動は、例えば、ユーザＢがログインに成功した場合にサーバ５から送られてくる鍵０（図６に示す）によって行われてもよいし、パスワードや特定の記号の入力によって行われてもよい。

尚、利用条件や鍵は、上述したように、全部又は一部が、サーバ５又はＣＤ−ＲＯＭ等のデータの書き換えが不可能な記憶媒体に格納されている場合もあるし、ポリシーファイルとは別のファイルとしてユーザＢに発行される場合もある。

特に、ポリシーの中に、日時や回数等、正当な評価判断が必要とされる利用条件が含まれる場合には、鍵や利用条件の全部又は一部がサーバ５に格納されていたり、ポリシーファイルとは別のファイルとされている方が元ファイルの不正利用防止により効果的である。但し、サーバ５側に鍵や利用条件が格納されている場合は、ユーザ端末４が元ファイルの利用都度、サーバ５にアクセスしなければならず、その分ネットワーク接続の負担が高くなるため、サーバ５の設計に注意が必要である。

照合・更新手段３４ａは、取り出された利用条件１に対応する利用状況１がユーザ端末Ｂ内の利用状況データベース３３ａに存在するかどうかを確認する（Ｓ７２５）。尚、本実施例の利用条件１は、ユーザ端末Ｂ内の利用状況データベース３３ａに格納されているデータとの比較、照合が必要な利用条件であるものとするが、必ずしもそのような利用条件ばかりではなく、ユーザ端末Ｂによって検証可能な利用条件、サーバ５によって検証可能な利用条件も当然のことながら存在し、その場合には利用状況データベース３３ａの生成は必須ではない。

利用状況データベース３３ａそのもの、又は利用状況１がユーザ端末Ｂ内に存在しない場合には、ユーザ端末Ｂ以外のユーザ端末４で、元ファイルが不正に利用されそうになったことを表すので、以降のステップには進めないようにする（Ｓ７３０）。

尚、照合・更新手段３４ａで、ポリシーファイルや利用条件や利用状況のハッシュ値をとることによって、これらに対する改ざんを検知することも可能である。

照合・更新手段３４ａは、利用状況１が利用者端末７内に存在した場合（Ｓ７２５）、その利用状況１が利用条件１を満足しているか、つまり、利用条件１の範囲内の利用に相当しているかどうかを確認する（Ｓ７３５）。

例えば、利用条件１は、「利用限度回数が１０回」であり、ユーザ端末Ｂ内に格納された利用状況１が、「現在利用回数３回」であれば、利用条件１を満足したものとする。一方、利用状況１が、現在利用回数１０回であった場合には、利用条件１を満足しなかったものとして、以降のステップに進めないようにする（Ｓ７４０）。このように、以降のステップに進めない場合、ユーザ端末Ｂに表示されるエラー画面の一例を図２３に示す。

利用条件１と利用状況１の照合が終わると、利用状況１の更新を行うとともに、次の照合・更新手段３４ｂに進むために必要な鍵１が取り出される（Ｓ７４５）。

利用状況の更新は、例えば、対応する利用条件が「回数」に関するものである場合には、累積利用回数に１を加算するか、残り利用回数に１を減算する等した状態に自動的に更新される。

又、利用条件が、無期限、回数制限なしといった永久利用権のようなものであった場合でも、利用権限を有していないユーザに元ファイルを不正利用させることを防止するため、中身が空又は無意味なデータで構成された利用状況データベース３３ａをユーザ端末に生成し、利用条件と利用状況の照合時に必ず、利用状況データベース３３ａの存在を確認する過程を経るとよい。

ポリシーオブジェクト１から取り出された鍵１は、次のポリシーオブジェクト２を開き、ポリシーオブジェクト２に対応する利用条件２が取り出される（Ｓ８１０）。

復号鍵解読部３４の照合・更新手段３４ｂは、ユーザＢが、利用条件２を満足しているかどうかを、サーバ５に確認する（Ｓ８１５）。例えば、利用条件２が、元ファイルの利用期限であるとすれば、復号鍵解読部３４は、サーバ５に利用条件２を送信し、サーバ５から現在日時に関する情報を送信してもらうか、サーバ５で現在日時と利用条件２との照合を行いその結果を送信してもらう。

また、利用条件２が、例えば、パッケージファイルへの同時アクセス数であるとすれば、復号鍵解読部３４は、サーバ５に利用条件２を送信し、サーバ５からパッケージファイルへのログインアクセス履歴等の情報に基づいた同時アクセス数に関する情報を送信してもらう。

ユーザＢが利用条件２を満足していなければ、その場で、元ファイルの利用プロセスは中止される（Ｓ８２０）。ユーザＢが利用条件２を満足していれば、ポリシーオブジェクト２に含まれる鍵２が取り出され、鍵２によってポリシーオブジェクト３が開かれる。そして、ポリシーオブジェクト３に対応する利用条件３が取り出される（Ｓ８２５）。

そして、利用条件３についても、Ｓ８１５〜Ｓ８２５と同様の手続きがとられ、復号鍵解読部３４は、最終的に、復号鍵とユーザＢの利用権限を取得する（Ｓ８３０）。尚、これら復号鍵と利用権限は、不正利用されることのないよう、ユーザ端末Ｂの一時メモリ４３に展開されるが、ハードディスク４４等の記憶媒体には格納されない。

復号化部３５は、パッケージファイルの中から、暗号化された元ファイルを取り出し、先の復号鍵を用いて暗号化された元ファイルを復号化する（Ｓ８３５）。

復号化された元ファイルは、先の復号鍵や利用権限同様、ユーザ端末Ｂのハードディスク４４ではなく一時メモリ４３上に展開され、一時メモリ４３上で元ファイルの利用が可能となる。尚、ユーザ端末Ｂのハードディスク４４に元ファイルが格納されないのは、一旦、ハードディスク４４に格納されてしまうと、利用条件を無視した元ファイルの利用が可能となってしまうのを防止するためである。

ファイル利用制御部３６は、復号化された元ファイルの種類に応じた対応ソフト４２をユーザ端末Ｂ上で起動させ（Ｓ８４０）、当該対応ソフト４２上で元ファイルの利用を可能とする。また、その際、取得した利用権限に基づいて、対応ソフト４２の動作を制御する（Ｓ８４５）。例えば、ユーザＢが取得した利用権限が、元ファイルの閲覧のみであった場合には、対応ソフト４２の画面上に現われる保存ボタンや印刷ボタンは表示されないようにする。また、ファイル利用制御部３６は、ユーザＢが取得した利用権限外の利用（例えば、印刷や保存）が行われようとした場合には、その動作を検知して、元ファイルの利用を中止させたり、ユーザ端末Ｂの画面上に警告表示を行ってもよい。

対応ソフト４２は、元ファイルの種類に応じてユーザ端末Ｂ内に用意されていてもよいし、元ファイルの種類によらないマルチ対応ソフトであってもよい。また、対応ソフト４２がファイル利用プログラム３に含まれていてもよい。

尚、ユーザＢが元ファイルの利用を終える場合には、対応ソフト４２をユーザ端末Ｂ上で閉じれば、一時メモリ４３に展開されていた復号鍵、利用権限、元ファイル等のデータは削除され、ユーザ端末Ｂがアクセス可能な記憶媒体にもともとあったパッケージファイルだけが残る。そして、ユーザＢがこれ以降に元ファイルを利用する場合も、これまでと同様の復号鍵解読過程を経ることによって、利用条件及び利用権限の範囲内で元ファイルの利用が可能となる。

尚、パッケージファイル一式の格納場所の移動やコピー・複製は任意である。また、利用権限の一態様として、元ファイルの保存や編集が認められている場合には、元ファイルそのものをハードディスク４４に保存することが可能となる。一旦、元ファイルがハードディスク４４に保存されれば、それ以降は、ファイル利用プログラム３の起動を行わずに、対応ソフト４２の起動によって、元ファイルを利用することが可能となる。

次に、利用権限の一態様として元ファイルの編集が認められた場合に、パッケージファイルの更新を行う手順について、以下説明する。尚、ファイル利用プログラム３には、当初から再パッケージ部３７が含まれているものとするが、復号鍵解読部３４で取得した利用権限に編集が含まれていない場合には、再パッケージ部３７が動作しないように制御されることが望ましい。

まず、元ファイルについて編集という利用権限を取得したユーザＢのユーザ端末Ｂ上で、元ファイルの編集が行われると、再パッケージ部３７は、対応ソフト４２から元ファイルの編集が行われたことの通知を受ける。

そこで、再パッケージ部３７は、編集終了後（例えば、ユーザ端末Ｂの画面上に「再パッケージボタン」を表示させ、クリック等されたのを検知して）、編集された元ファイルを、編集前の元ファイルが暗号化されていたのと同じ復号鍵で暗号化して、ポリシーファイルやファイル基本情報とともにパッケージ化し、パッケージファイルを生成する。生成されたパッケージファイルは、元のパッケージファイルに上書きされる。つまり、元のパッケージファイルは削除され、新しいパッケージファイルは元のパッケージファイルの格納場所に格納される。

尚、ポリシーファイルは、元のポリシーファイルと基本的に変わらないが、ファイル基本情報については、内容が一部更新された状態で、再パッケージに用いられる場合もある。

元ファイルの再パッケージが行われた場合には、その旨が、元ファイルの作成ユーザに通知されてもよい。また、ユーザＢのサーバ５へのアクセス履歴や再パッケージ履歴は、サーバ５の履歴データベース５６に逐次格納されるので、元ファイルの作成ユーザＡは、検索リクエスト部２４から、サーバ５の検索部５３に、ユーザＢの元ファイル利用履歴の検索を要求してもよい。これにより、ユーザＡは、元ファイル作成後の追跡、管理を行うことが出来る。

本発明に於ける各手段、データベースは、その機能が論理的に区別されているのみであって、物理上或は事実上は同一の領域を為していてもよい。又データベースの代わりにデータファイルであってもよいことは言うまでもなく、データベースとの記載にはデータファイルをも含んでいる。

尚、本発明を実施するにあたり本実施態様の機能を実現するソフトウェアのプログラムを記録した記憶媒体をシステムに供給し、そのシステムのコンピュータが記憶媒体に格納されたプログラムを読み出し実行することによっても実現される。

この場合、記憶媒体から読み出されたプログラム自体が前記した実施態様の機能を実現することとなり、そのプログラムを記憶した記憶媒体は本発明を構成する。

本発明のプログラムの供給は、主として、ＬＡＮ６ａやインターネット６ｂ等のネットワーク６を介してコンピュータにダウンロードさせる方法による。その他、磁気ディスク、光ディスク、光磁気ディスク、磁気テープ、不揮発性のメモリカード等の可搬型の記憶媒体からコンピュータへの供給も可能である。

又、コンピュータが読み出したプログラムを実行することにより、上述した実施態様の機能が実現されるだけではなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているオペレーティングシステムなどが実際の処理の一部又は全部を行い、その処理によって前記した実施態様の機能が実現される場合も本発明に含まれる。

ファイル管理プログラムをインストールしたユーザ端末とサーバの接続構成の一実施例を示す図である。 ファイルパッケージプログラムとサーバの構成の一実施例を示す図である。 パッケージファイルを生成する概略過程を示す概念図である。 ファイル利用プログラムの構成と、ユーザ端末の構成の一実施例を示す図である。 パッケージファイルのデータ構造の一実施例を示す図である。 ユーザ端末の構成の他の実施例を示す構成図である。 ポリシーファイルを暗号化する概略過程を示す概念図である。 本発明のプロセスのフローの一例を示すフローチャート図である。 本発明のプロセスのフローの他の一例を示すフローチャート図である。 本発明のプロセスのフローの他の一例を示すフローチャート図である。 本発明のプロセスのフローの他の一例を示すフローチャート図である。 本発明のプロセスのフローの他の一例を示すフローチャート図である。 本発明のプロセスのフローの他の一例を示すフローチャート図である。 本発明のプロセスのフローの他の一例を示すフローチャート図である。 本発明のプロセスのフローの他の一例を示すフローチャート図である。 ログイン画面の一例を示す図である。 ファイルパッケージ用画面の一例を示す図である。 ファイルパッケージ用画面の他の一例を示す図である。 メール送信画面の一例を示す図である。 パッケージ履歴検索画面の一例を示す図である。 パッケージ履歴検索画面の他の一例を示す図である。 許可ユーザ／グループの選択画面の一例を示す図である。 エラー画面の一例を示す図である。

符号の説明

１：ファイル管理プログラム
２：ファイルパッケージプログラム
２１：ファイル指定部
２２：ポリシー策定部
２３：パッケージ部
２４：検索リクエスト部
３：ファイル利用プログラム
３１：ファイル指定部
３２：認証リクエスト部
３３：データベース生成部
３３ａ：利用状況データベース
３４：復号鍵解読部
３４ａ，３４ｂ，３４ｃ：照合・更新手段
３５：復号化部
３６：ファイル利用制御部
３７：再パッケージ部
４：ユーザ端末
４２：対応ソフト
４３：一時メモリ
４４：ハードディスク
５：サーバ
５１：鍵生成部
５２：ポリシーファイル生成部
５３：検索部
５４：認証部
５５：ユーザデータベース
５６：履歴データベース
５７：認証データベース
６：ネットワーク

Claims (13)

1. ユーザ端末に格納、実行され、任意のユーザが作成した元ファイルの一元管理を行うためのファイルパッケージプログラムを有するファイル管理プログラムであって、
   前記ファイルパッケージプログラムは、
   管理の対象としたい元ファイルの指定を受け付けるファイル指定部と、
   前記元ファイルを利用する際のポリシーを策定するポリシー策定部と、
   前記元ファイル毎に生成された共通鍵と前記ポリシーに基づいて生成されたポリシーファイルと、前記共通鍵で暗号化された元ファイルとをパッケージしてパッケージファイルを生成するパッケージ部とを有し、
   前記ポリシーの利用条件を満足したユーザのみが、前記ポリシーファイル内の共通鍵と元ファイルの利用権限を前記ユーザの端末の一時メモリ上に展開出来るようにし、更に、前記共通鍵で復号化された元ファイルを前記一時メモリ上にのみ展開出来、前記利用権限の範囲内で元ファイルの利用が可能なように前記パッケージファイルを生成する
   ことを特徴とするファイル管理プログラム。
   
2. 前記ファイルパッケージプログラムは、更に、
   前記パッケージファイルのパッケージ履歴に関する情報や、前記パッケージファイルへのユーザのアクセス履歴に関する情報の検索を行う検索部を有する
   ことを特徴とする請求項１に記載のファイル管理プログラム。
   
3. 前記ファイルパッケージプログラムは、
   前記パッケージ部でパッケージファイルが生成されるとともに、前記元ファイルの利用権限が与えられたユーザのユーザ端末に、前記パッケージファイルの生成を、通知もしくは、前記パッケージファイルをメール添付により送信する通知部を
   有することを特徴とする請求項１又は請求項２に記載のファイル管理プログラム。
   
4. ユーザ端末に格納、実行され、任意のユーザが作成した元ファイルの一元管理を行うためのファイルパッケージプログラムによりパッケージされた元ファイルを復元してユーザが利用するためのファイル利用プログラムを有するファイル管理プログラムであって、
   前記ファイル利用プログラムは、
   パッケージファイルのうち、利用したい元ファイルがパッケージされているパッケージファイルの指定を受け付けるファイル指定部と、
   前記パッケージファイル内のポリシーファイルを構成しているポリシーの利用条件照合を行ない、前記元ファイルの利用が前記利用条件の範囲内の利用である場合、前記元ファイル毎に生成された共通鍵であって、暗号化に用いられた元ファイルの復号鍵と、前記元ファイルの利用権限とを、前記ポリシーファイルの中から取得するとともに、これら復号鍵と利用権限を前記ユーザ端末の一時メモリ上に展開する復号鍵解読部と、
   前記取得した共通鍵によって、前記パッケージファイル内の暗号化された前記元ファイルを復号化し、前記ユーザ端末の一時メモリ上に展開する復号化部と、
   前記取得した利用権限に基づいて、前記元ファイルの利用を制御するファイル利用制御部とを
   有することを特徴とするファイル管理プログラム。
   
5. 前記ファイル利用制御部は、
   前記元ファイルの対応ソフトを制御して、前記対応ソフトからユーザ端末のＯＳ若しくはミドルウェアに対して、前記取得した利用権限に基づいた機能呼び出し命令を行うＡＰＩフッキングを行う手段である
   ことを特徴とする請求項４に記載のファイル管理プログラム。
   
6. 前記ファイル利用プログラムは、更に、
   前記パッケージファイル中の暗号化された元ファイルが復号化され、ユーザの利用権限に基づいて前記元ファイルの編集がなされた場合、編集後の元ファイルを再び前記ポリシーファイルとともにパッケージし、元のパッケージファイルを更新する再パッケージ部を
   有することを特徴とする請求項４又は請求項５に記載のファイル管理プログラム。
   
7. 前記ファイル利用プログラムは、
   前記元ファイルの再パッケージが行われた場合に、前記元ファイルの作成ユーザのユーザ端末もしくはサーバに、再パッケージが行われた旨を通知する通知部を
   有することを特徴とする請求項６に記載のファイル管理プログラム。
   
8. 前記ファイル利用プログラムは、
   前記ユーザ端末においてパッケージファイル内の元ファイルを利用しようとする毎に前記ユーザ端末による元ファイルの利用状況を更新することが出来る利用状況データベースを、前記ユーザ端末以外のユーザ端末による読みとり、更新が出来ないような状態で、前記ユーザ端末に生成するデータベース生成部を
   有することを特徴とする請求項４から請求項７のいずれかに記載のファイル管理プログラム。
   
9. 前記ポリシーファイルの一部又は全ては、サーバに格納されており、
   前記ファイル利用プログラムは、
   前記サーバに、前記ポリシーファイル内の利用条件の照合を要求する
   ことを特徴とする請求項４から請求項８のいずれかに記載のファイル管理プログラム。
   
10. 前記ポリシーファイルは、サーバ毎に生成された置換表によって置換された鍵によって、暗号化されており、
    前記置換表は、前記ファイル管理プログラムが前記ユーザ端末に格納されるとともに、前記ユーザ端末に格納される
    ことを特徴とする請求項１から請求項９のいずれかに記載のファイル管理プログラム。
    
11. 前記ポリシーファイルは、
    利用条件が、複数のポリシーオブジェクトと対応付けて記述されたものであり、
    任意のポリシーオブジェクトに対応する利用条件が満足された場合には、別のポリシーオブジェクトを開くための鍵を取得することが出来、最終的に全てのポリシーオブジェクトの鍵が開かれ、全ての利用条件が満足された場合にのみ、前記復号鍵と利用権限を取り出すことが出来るような鎖状のデータ構造を有している
    ことを特徴とする請求項１から請求項１０のいずれかに記載のファイル管理プログラム。
    
12. 前記ファイル管理プログラムは、
    ファイル管理プログラムの登録ユーザかどうかの認証もしくは、前記利用条件に含まれる元ファイルの利用許可ユーザかどうかの認証を行う認証インターフェースを有しており、
    前記認証インターフェースは、
    ユーザからの要求によって決定した認証デバイス、もしくは、前記認証インターフェース側で予め決めた認証デバイスから出力された前記ユーザの第２パスワードと、当該認証デバイスの種類を、前記ファイル管理プログラムのログインＩＤ、パスワードとともに前記ユーザ端末からサーバに送信し、前記サーバに既に保存されているデータとの照合を依頼する
    ことを特徴とする請求項１から請求項１１のいずれかに記載のファイル管理プログラム。
    
13. 前記認証インターフェースは、
    前記認証デバイスが、暗号化ロジックの入るものであれば、前記サーバもしくは前記ユーザ端末に保存されているテンプレートデータのうち、前記ログインＩＤに対応するテンプレートデータを取得し、前記ユーザのＰＫＩ証明書によって、署名検証及び復号化して前記第２パスワードを取得し、前記サーバに既に保存されているデータとの照合を依頼する
    ことを特徴とする請求項１２に記載のファイル管理プログラム。
    

Images