JP2000501540A

JP2000501540A - 自己破棄文書およびｅメールメッセージシステム

Info

Publication number: JP2000501540A
Application number: JP11504709A
Authority: JP
Inventors: ユーデル，ハワード，アール．; ベイカー，ステュアート，ディー．; カペル，キャリー，エス．; シャーマン，グレッグ，エム．; リース，ウィリアム．
Original assignee: パーデューファーマエルピー
Priority date: 1997-06-17
Filing date: 1998-06-16
Publication date: 2000-02-08
Also published as: EP1000400A1; HUP0001042A2; KR100336025B1; US20030126215A1; AU725944B2; CA2263171A1; AT4261U2; AT4261U3; US7191219B2; HUP0001042A3; CA2362716A1; EP1000400A4; CN1229489A; IL128576A0; KR20000068195A; WO1998058321A1; AU8373698A; IL128576A; BR9806000A; NZ334075A

Abstract

(57)【要約】文書またはＥメールメッセージにマクロまたはウィルスを添付することにより、所定の時間において文書またはＥメールメッセージを自動的に破棄する、自己破棄文書またはＥメールメッセージングシステムが得られる。マクロが作成され(220)、Ｅメールメッセージ（280）や文書(270)といったファイルが作成されるとこのマクロが添付される（230）。マクロは、所望の時間にウィルスが添付されたファイルを上書きおよび/または削除するようにコンピュータに命令する、実行可能コードあるいは実行可能プログラムの一部を含んでいる。

Description

【発明の詳細な説明】自己破棄文書およびEメールメッセージシステム本明細書は、1997年6月17日出願の、米国特許仮（?provisional）明細書シリアル番号第60/049,853号、タイトル「自己破棄文書およびEメールメッセージシステム」の優先権を請求するものであり、本発明書中では該明細書の全開示を参照によって採用している。発明の分野本発明は、電子メール（「Eメール」）メッセージングを含む電子的に作成された文書の分野と、文書保存および削除の分野に関するものである。発明の背景 Eメールメッセージングシステムは、ビジネスでおよび個人によって世界中で広く利用されている。Ｅメールシステムにより、ユーザは別のユーザとの電子メッセージの送受信が行える。Ｅメールシステムは、ローカルエリアネットワーク（LAN）に接続したユーザにメッセージングサービスを提供するように構成でき、またユーザが、インターネットのような外部ネットワークを介して、LANの外にいるユーザとメッセージの送受信を行えるように構成することができる。さらに、Eメールシステムによって、ユーザはEメールシステムを介して受信したメッセージを保存、コピー、転送することも可能である。 Eメールシステムがユーザにメッセージの保存、コピー、転送を許容する容易さによって、文書保存ポリシーを妨害する望まない結果を招いてしまった。一般に文書保存ポリシーは、ビジネスで作成または受信した文書を特定の期間だけ保存し、その後破棄することを確実に行うためにビジネスにおいて実行されている。さらに、異なる文書に異なる文書保存期間を指定することができる。文書保存ポリシーの目的の1つは、ビジネスにおいて、どのクラスの文書がまだ存在するかを与えられた期間から確実に識別できるように、文書の保存および破棄のための組織的な方法を提供することである。効果的な文書保存ポリシーはまた、訴訟の情況において価値のあるものである。このような情況において、ビジネス(？企業)が文書の保存および破棄に関して一貫したポリシーを持っていること、また、このポリシーを実行をしていることが重要である。例えば、ビジネス(？企業)の文書保存ポリシーが、文書を3年間保存するということを提示し、これを一貫して守っていれば、その文書が訴訟でのビジネスの立場に不利であるために、特定の5年前の文書を破棄したという起訴にも有利である。さらに、もし文書保存ポリシーが一貫して守られおらず、ある特定の期間の文書のうち数通のみが破棄されているとすれば、その残りの文書がその期間に起こった証拠の概念を与えてしまう可能性もある。コンピュータファイルに関連して文書保存ポリシーを強制するシステムがよく知られている。一般に、これらのシステムはネットワーク上のファイルを定期的に走査し、指定された日付よりも以前に作成されたファイルを削除するものである。しかし、該システムはネットワーク上で動作するため、個々のコンピュータのハードドライブに記憶されたファイルを削除することができない。これらのファイルにアクセスするためには、文書保存プログラムを個々のコンピュータにインストールする必要がある。しかし、文書保存システムを個々のコンピュータにインストールしたところで、やはりシステムはフロッピーディスクやその他の外部媒体に保存されたファイルまでは削除できない。さらに、これらのシステムは、Eメールを介してネットワーク外のコンピュータに転送されたファイルを削除することも不可能である。従って、例えば、従業員の自宅のコンピュータやラップトップコンピュータに、または第3者に転送されたファイルは、従来の文書保存システムでは削除することができない。発明の概要本発明の第1実施例によれば、文書やEメールメッセージに「ウィルス」のような実行可能モジュールを添付することで、所定の日時がきたら文書やEメールメッセージを自動的に破棄する自己破棄文書およびEメールメッセージングシステムが得られる。コンピュータウィルスはよく知られている。一般的にコンピュータウィルスは、ホストファイルに自己を添付する実行可能コードまたはプログラムである。例えば、「添付ウィルス」は自己をホストプログラムの最後に添付することで動作し、ホストプログラムの実行に先立ち、ホストプログラムにウィルスコードを実行させる。反対に「プリペンディングウィルス」はホストプログラムの最初に自己を添付する。別のタイプのウィルスがホストプログラムの内部に配置される。別のクラスのウィルスは「マクロ」ウィルスとして知られている。これらのウィルスはテキスト文書にエンベッドされたマクロであり、文書がオープン、作成、保存される際に実行するように構成することができる。一般に、ホストファイルまたはプログラムと共に残存し、他のファイルまたはプログラムヘ移動しないウィルスを参照するために「トロイの木馬」という用語が使用される。本発明の第１実施例によれば、トロイの木馬型の実行可能モジュールが、ファイル（Ｅメールメッセージや文書）の作成時にこれに添付される。実行可能モジュールは、所望の日時に、実行可能モジュールが添付されたファイルを上書きおよび/または削除するようコンピュータに命令する実行可能コードまたは実行可能プログラムの一部を含んでいる。この方法において、実行可能モジュールは、文書またはＥメールメッセージの生存期間の制限を設定する。実行可能モジュールはファイルに添付されるため、そのファイルがコピー、転送、またはディスクやテープドライブに保存されても、ファイルと共に移動する。本発明の第１実施例のさらなる局面によれば、実行可能モジュールは、添付先のファイルが開かれる度に実行される。実行可能モジュールは、ファイル削除の条件順序が合致したかどうかを決定する。条件順序が合致した場合、実行可能モジュールはファイルを空白データで上書きし、次にそのファイルを保存、クローズ、または削除するようにコンピュータに命令する。この方法において、本発明は従来技術よりも多くの利点を提供する。例えば、実行可能モジュールはファイルに添付され、そのファイルが開かれる際に実行可能モジュールが実行されるため、もしそのファイルがフロッピーディスクのような外部媒体に、または非ネットワークコンピュータ上に保存されているとしても、本発明によるシステムは文書保存ポリシーを強制することができる。これは、実行可能モジュールがファイルと共に移動し、そのファイルのオープン時に常に実行されるためである。本発明の第2実施例によれば、作成した各ＥメールメッセージまたはＥメールメッセージ添付物に実行可能モジュールを自動的に添付する、自己破棄Ｅメールメッセージングシステムが得られる。実行可能モジュールは、実行可能モジュールを添付したメッセージ（および/またはメッセージ添付物）を所望の日時に上書きおよび/または削除するようにコンピュータに命令する、実行可能コードまたは実行可能プログラムの一部を含む。実行可能モジュールはメッセージに添付されているので、メッセージがそのアドレスに送信されると実行可能モジュールもメッセージと共に移動する。さらに、別のアドレスにメッセージをコピーまたは転送したり、ディスクや他の外部媒体に保存した場合にも、実行可能モジュールはメッセージに添付されたまま残る。本発明の第3実施例によれば、1つ以上のデジタルオブジェクトが「配置」される仮想コンテナを含む文書機密保護システムが得られる。これに関連し、「デジタルオブジェクト」という用語は広く使用され、文書（スプレッドシート、チャート/グラフ、ワードプロセッサ文書、ASCIIテキストファイル、画像、その他のデータファイル）、プログラム、コンピュータに保存できるこの他のものを含む゜文書機密保護システムは、コンテナクリエータとコンテナオープナを備えている。コンテナクリエータとコンテナオープナは、コンピュータ上で実行される1 つ以上のソフトウェアプログラムにおいて実行される。コンテナオープナにより、ユーザはコンテナ内のデジタルオブジェクトの有効生存期間に制限を設定することができる。これらの「生存期間規制」は、例えば満了日、満了時間、その文書を開くことができる固定回数、またはその他の制限を含むことが可能である。コンテナオープナを使ってコンテナが開かれると、コンテナオープナは生存期間規制を調べる。これが有効であれば、ユーザは、表示または実行するためにコンテナ内のデジタルオブジェクトにアクセスすることができる。しかし生存期間規制が無効である場合には、コンテナオープナはそのデジタルオブジェクトを即刻破棄する。コンテナクリエータとコンテナオープナを含む文書機密保護システムの利点の 1つは、ある環境において、実行可能モジュールを備えた自己破棄文書よりもしっかりした生存期間規制の強制を提供することである。これは、製品によって大きく異なる実行可能モジュールを実行するための最新ワード処理能力と、スプレッドシートプログラムのためである。従って、例えば、Microsoft Word^TMで実行される実行可能モジュールを備えた自己破棄文書は、例えば実行可能モジュールを認識および実行するように構成されていない単純なASCIIファイルとして開かれた場合には自己破棄されない。反対に、文書はコンテナオープナによって開かれるコンテナ内で、文書機密保護システムによって保護され、コンテナオープナは、文書のタイプに関わらず、その使用時にコンテナ内のあらゆる文書に対して生存期間規制を強制することができる。本発明の第3実施例による文書機密保護システムのさらなる局面によれば、コンテナ内の各デジタルオブジェクトが独立した生存期間規制を有することが可能である。コンテナの特性によれば、コンテナ内の1つのオブジェクトが満了した場合、他のオブジェクトはそのままでそのオブジェクトだけを破棄することができる。文書機密保護システムのまた別の実施例によれば、デジタルオブジェクトは、本発明の第1または第2実施例に従って作成された自己破棄文書である。この実施例のまたさらなる局面によれば、コンテナ、その内容、その生存期間規制を、機密保護システムの打倒を望むユーザから守ることができる。暗号化技術を利用することでこの機密保護が有効になる。具体的には、コンテナクリエータはコンテナ内のオブジェクトを暗号化するように構成され、コンテナオープナはそのオブジェクトを解読するように構成されている。この方法において、ユーザがコンテナオープナを使わずにオブジェクトの1つを開くと、そのオブジェクトは読出し不可能になる。第1および第2実施例のさらなる局面によれば、自己破棄文書またはEメールメッセージは実行可能モジュールあるいはその他のユーティリティによって暗号化され、実行可能モジュールはその文書またはEメールメッセージが満了していない場合にのみ、これらを解読することが可能である。本発明の別の実施例によれば、複数の実行可能モジュールを文書またはEメールメッセージにエンベッドすることで自己破棄文書が作成され、ここで、各モジュールは異なるワード処理またはEメールシステムによって実行される。例えば1 つの文書に、第1システムにより実行可能な第1モジュールと、第2システムにより実行可能な第2モジュールを備えることができる。文書自体はいずれのシステムにも適応する。この実施例によれば、文書を開くのが第1システムであっても第2システムであっても、文書の生存期間規制は強制される。本発明の別の実施例によれば、仮想コンテナを採用したインターネット商業システムが得られる。この実施例によれば、インターネットで電子的に送信可能な製品を販売したいと望む側が、製品を暗号化し、生存期間規制を設定するコンテナクリエータユーティリティを使ってその製品を仮想コンテナ内に入れる。製品の潜在的な購入者は、購入する前にその製品のサンプルを使用してみたいと望み、販売者からコンテナのコピーをコンテナオープナユーティリティと共に入手する。このコンテナオープナユーティリティによって、潜在的な購入者は予め決められた満了日までその製品を見たり使用したりすることができる。コンテナの実施例において、コンテナオープナはユーザが仮想コンテナから製品を除去することを阻止する。この実施例の好ましい局面によれば、満了日後にコンテナを開いた時に、製品がコンテナオープナによって削除される。この実施例のまたさらなる局面によれば、満了日以前に販売者が製品の支払いを受取ると、販売者は購入者に固有キーを送信する。このキーを受信すると製品をコンテナから解除するようにコンテナオープナを構成することが可能である。図面の簡単な説明第1図は、本発明を実行することができる従来技術の環境を図示したものである。第2(a)図、第2(b)図は各々、プリペンディングウィルスおよび添付ウィルスを含む、本発明によるEメールメッセージを示す。第3図は、本発明の例証的実施例による自己破棄Eメールメッセージを作成する例証的方法のフローチャートである。第4図は、第3図の自己破棄Eメールメッセージにエンベッドされたマクロウィルスのフローチャートである。第5(a)図〜第5(c)図は、Microsoft Excel^TM文書に実行される、本発明の1実施例による自己破棄文書のためのグラフィカルユーザインタフェースを示すものである。第6(a)図〜第6(c)図は、Microsoft Word^TM文書に実行される、本発明の1実施例による自己破棄文書のためのグラフィカルユーザインタフェースを示すものである。第7(a)図〜第7(e)図は、Microsoft Outlook^TMにおいて実行されるされる、本発明の1実施例による自己破壊Eメールメッセージのためのグラフィカルユーザインタフェースを示すものである。第8(a)図は、本発明の1実施例による文書設定仮想コンテナを示す。第8(b)図は、本発明の1実施例による仮想コンテナプロキシを示す。第9(a)図、第9(b)図は、本発明の文書設定仮想コンテナのさらなる実施例を示す。第10(a)図は、1つの文書を保持するように構成された文書設定コンテナのための例証的ヘッダフォーマットを示す。第10(b)図は、複数の文書を保持するように構成された文書設定コンテナのための例証的ヘッダフォーマットを示す。第11図は、コンテナクリエータユーティリティとコンテナオープナユーティリティのためのグラフィカルユーザインタフェースを示すものである。第12図は、第10(b)図の文書設定コンテナに文書を追加するための例証的フローチャートである。第13図は、第10(b)図の文書設定コンテナから文書を抽出するための例証的フローチャートである。好ましい実施例の詳細な説明第1図は、本発明を利用することができる従来技術の環境を図示したものである。ローカルエリアネットワーク1（LAN 1）は、複数のオフィスコンピュータ10 .1から10.6（以下、総合的にコンピュータ10とする）およびサーバ20を含む。各コンピュータ10は、それぞれの一次記憶機構12（ハードディスク等）と二次記憶機構14（フロッピーディスクまたはCD Romドライブ等）を備えている。サーバ20 も同様に、一次ネットワーク記憶機構22（ハードディスク等）と二次ネットワーク記憶機構24（テープまたはCD Romドライブ）を備えている。一次、二次ネットワーク記憶機構22、24に記憶されたデータは共用されるため、全てのコンピュータ10によるアクセスが可能である。これとは逆に、各コンピュータの一次、二次記憶機構12、14上のデータは専用（private）であるため、それぞれのコンピュータ10しかアクセスできない。サーバ20は、伝達線50を介してホームコンピュータ40のようなネットワーク外のコンピュータにインターネットアクセスを提供する。ホームコンピュータ40は一次記憶機構42と二次記憶機構44を備えている。LA N 1は各コンピュータ10に、LAN 1内の他のコンピュータ10にメッセージを送信させる、また、LAN 1外の、ホームコンピュータ40のようなネットワーク外のコンピュータにメッセージを送信させる電子メールメッセージングサービスを支持する。第1図に示した構成は、ビジネスにおいてしばしば利用される典型的なLANを図示したものである。しかしながら、本発明は様々なネットワーク構成での実行が可能であることが当業者にはわかるであろう。さらに、本発明のE-メールメッセージングシステムは、例えば、モデムまたはその他の接続を介してスタンドアロンコンピュータによってEメールメッセージを送受信する、非ネットワークアプリケーションが同等的に適応可能である。さらに、本発明の文書保存および削除は、モデムまたは外部コンピュータへのその他の接続の有無に関わらず、スタンドアロンコンピュータ上で実行される。次に、本発明により軽減される文書の保存および破棄問題について、第1図の構成を参照しながら説明する。実例の目的のために、２年以上経過した文書が破棄されることが要求される、文書保存ポリシーを採用したビジネスにローカルエリアネットワーク１をインストールしてあると仮定する。代表的に、このような文書保存ポリシーは、一次ネットワーク記憶機構22を定期的に走査し、現在の走査日付から２年前の作成日付がついた文書を削除するサーバ20にプログラムをインストールすることによって実行される。このタイプのプログラムの問題の１つは、ネットワーク記憶機構に記憶されていない文書のコピーを正確に計算できないことである。例えば、ユーザ１がコンピュータ10.1上で文書を作成し、ネットワーク記憶機構22に記憶したとする。次に、1週間後にユーザ1が該文書を、二次記憶機構14.1 を介してコンピュータ10.1のハードドライブ12.1に、続いてフロッピーディスクにコピーする。さらに、該文書は一次ネットワーク記憶機構22上にあるため、ユーザ1の行った過程を知らずに、ユーザ2が該文書を二次記憶機構14.2を介してコンピュータ10.2の一次記憶機構12.2に、続いてフロッピーディスクにコピーしたとする。この方法によれば、該文書のコピーは全部で5つ作成されたことになるが、ネットワーク文書保存プログラムはこの内の1つしかアクセスおよび削除することができない。上に参照した問題は、第1図のLANが電子メッセージングサービスを提供する事実によってさらに複雑化する。その結果、ユーザ1はEメールを作成でき、これをインターネットサーバ30を介してLAN外のコンピュータ40に送信することができる。さらに、予め作成された文書ファイルを、添付ファイルとしてEメールメッセージに挿入することが可能である。これによりさらなる問題が持ち上がる。例えば、Eメールメッセージとその添付ファイルを、ビジネスの文書保存ポリシーを認識しないLAN外の第3者側に送信することができる。あらゆる場合において、 Eメールを単に従業員のホームコンピュータに送信する場合でも、ネットワーク文書保存プログラムはホームコンピュータにアクセスしない。一般に、ネットワーク記憶機構に記憶されていない文書に関連した文書保存ポリシーの強制には、各従業員が個々のハードドライブ、そのフロッピーディスクまたは他の二次記憶媒体の各ディレクトリを検索する必要がある。さらに、Eメールメッセージの添付ファイルとしての文書を含むEメールシステムを可能にするために、新しいEメールメッセージに命令文書を隠し入れ、これらの文書の認識および削除を困難にすることができる。従業員もまた、各自のラップトップおよびホームコンピュータでビジネスファイルを検索することを要求される。さらに、たとえ各従業員がこれらの時間のかかる仕事に熱心であったとしても、第3 者側のコンピュータに文書が引続き存在する可能性が残る。文書保存ポリシーの実行に伴う別の問題は、従来は、記憶媒体から文書が削除される際に文書自体が除去されないことである。かわりに、コンピュータは単に、記憶媒体におけるその文書の位置を示す文書のポインタを削除するのである。その文書自体は、コンピュータがこれを他の文書により上書きするまで記憶媒体内に残る。その結果、従業員が実際に文書を確実に削除するためには、文書を空白文字（NUL）で上書きし、次に文書を削除し、さらに、文書保存ポリシーの強制に関連する時間を増加しなければならない。文書またはEメールメッセージにエンベッドされた実行可能モジュール本発明によれば、文書に実行可能モジュールを添付する自己破棄文書システムが得られる。本発明の別の実施例によれば、メッセージまたはメッセージ添付を作成する際に、電子メッセージまたはメッセージ添付に実行可能モジュールを添付する自己破棄Eメールメッセージングシステムが得られる。実行可能モジュールは、従来のあらゆる方法でメッセージまたは文書に添付することができる。例えば、第2図を参照すると、予めペンディングされたウイルス（第2A図）、付加されたウイルス（第2B図）として実行可能モジュールを、あらゆる従来の方法で添付することができる。モジュール自体は、例えばアセンブリ言語、より高度なプログラム言語、あるいはマクロを利用する従来の方法によって作成することができる。添付された実行可能モジュールは、所定の状態になると文書またはメッセージを自己破棄させる。この方法において、実行可能モジュールは、文書の生存期間を制御する「生存期間制御」を設定する。上に参照した実例において、例えば実行可能モジュールは、文書またはメッセージの作成日付が現在日付よりも 2年以上前のものである場合に、添付先の文書またはメッセージを削除するようにプログラムされる。本発明のさらなる実施例によれば、実行可能モジュールは添付先の文書またはメッセージを削除する前に、空白文字(例えば全て”X”)で上書きする。本発明のさらなる実施例によれば、文書またはメッセージの上書きおよび/または削除は、他のまたは追加の状態の発生に伴うことができる。例えばシステムを、メッセージまたは文書がi)閉じられた際に、またはii）2度目に開かれた際に、これらを上書きまたは削除するように構成することができ、これにより破棄前に1度しか読出せない文書を作成することができる。また、システムを、メッセージまたは文書をコピー、転送、印刷しようとすると、メッセージまたは文書を上書きおよび/または削除するようにも構成できる。さらに、メッセージまたは文書を印刷またはコピーする試みを阻止するようにシステムを構成することもでき、これにより見ることはできるが印刷はできない文書を作成することができる。これらの追加的な生存期間制御は事象によってもトリガできるため、パスワードまたはキーが入力されると印刷またはコピー阻止がリフトされるか、あるいは、所定の時間または他の事象の後に印刷またはコピー阻止がインポーズされる。本発明の別の実施例によれば、システムユーザが作成した文書またはメッセージ保存ポリシーを、全てのシステムユーザ上でインポーズできるように、LANの管理者が上書き/削除状態（単数または複数）を予め決定できるようにシステムを構成することが可能である。同様に、システムを、特定の文書またはメッセージが上書き/削除状態を含むかどうかを各ユーザが選択できるように構成することができる。さらに、ユーザは、様々な上書き/削除状態からの選択が可能である。これは例えばツールメニューを介して実行することができる。次に、自己破棄電子文書を実行するための、または、自己破棄電子メッセージングシステムを提供するための例証的方法について説明する。ここで示す例証的な実施例は、Microsoft Word^TM、Microsoft Excel^TM、Microsoft Outlook^TM環境を実例に出して説明しており、当業者には、本発明が様々な環境において様々な方法で実行できることが明白であろう。第3図、第4図は、Microsoft Word^TM6.0文書用の自己破棄電子メッセージングシステムの実行を図示したものである。第3図を参照すると、段階200において、ユーザは、例えば第1図のオフィスコンピュータ10.1上で文書またはメッセージの作成を開始する。段階220では、システムが"AutoOpen"マクロを作成し、これを"Normal.dot"ファイル内に保存する。Microsoft Word^TM構築によれば、AutoOp enによって作成されたマクロは、Word文書が開かれるたびに実行される。段階22 0で参照した、WordBasic^TMプログラム言語で書かれた命令は、AutoOpenマクロとしてnormal.dotテンプレートファイルに保存される。Normal.dotは、Word^TMプログラムによって、グローバルマクロ用の記憶ファイルとしてデザインされたテンプレートである。段階230で、AutoOpenマクロを含むnormal.dotファイルが"mess age.dot"と名前が付けられたファイルにコピーされる。次に段階240において、n ormal.dotファイルからAutoOpenマクロが削除される。段階250〜260において、m essage.dotファイルが開かれ、ユーザは文書またはメッセージのテキストを挿入するよう促される。次に段階270において、現在、normal.dotファイルのコピーと共に文書またはメッセージを含むmessage.dotファイルが保存される。次に、n ormal.dotファイルのコピーがAutoOpenマクロを含む。段階280〜290では、messa ge.dotファイルがmessage.docに名前変更され、電子メールメッセージまたは電子メールメッセージ添付物として送信される。電子メールメッセージは、例えばインターネットを介し、LANサーバ20、インターネットサーバ30を介してホームコンピュータ40へと送られる。Message.doc ファイルにエンベッドされたAutoOpenマクロは、そのメッセージの受信人がファイルmessage.docを開いた時に実行される。第4図は、message.docファイルにエンベッドされたAutoOpenマクロのフローチャートである。段階310において、Dat eSerial()機能は、メッセージの作成日付を表すシリアル値を変数"created"として戻す。機能DateSerialの引数が、AutoOpenマクロが作成された時点で（第3図の段階210、220）設定され、第3図、第4図中でJune 10，1997と任意に表示されている。段階320において、Today()機能が、現在の日付を表すシリアル値を変数 "curdate"として戻す。これらの機能によって戻されたシリアル値は、1〜802074 の間の整数であり、ここで1はDecember 31，1899に、802074はDecember 31，409 5に関連する。段階330において、変数"difference"が"curdate"と"created"の間の差異として設定される。続いて変数"difference"が、message.docファイルの作成日とこの文書が開かれた現在の日付との間に経過した日にちと等しくなる。段階340〜360は、作成日付と現在の日付の間に経過した時間が所定のしきい値を超えているかどうかを決定する"If，Then"文を構成する。説明目的のために、しきい値は60日に設定してある。段階340で、変数"difference"は値60と比較される。"difference"が60よりも大きい場合、すなわち、message.docファイルの作成日から60日以上が経過している場合には、段階350、360、370が実行される。段階350ではEditReplace.Fine機能が実行される。この機能はmessage.docファイルの各文字を空白文字（既に任意に"X"に設定されている）に置換える。次に段階360において、ファイル内のテキストも時の数と等しい一連の"X"で書換えられたmessage.docファイルが保存され、閉じられる。この方法において、message .docファイルが検索されるメモリの位置が空白で上書きされる。これとは逆に、段階340において変数"Difference"が60よりも少ないまたは同値である場合、実行は370へと跳び、メッセージのアドレスを自由に見ることができ、メッセージを編集することができるようになる。当然、さらなる機能を実行するために第4図に示したマクロを変更することができる。例えば、message.docが開かれた時点でこの位置を検索するためにFileN ameFrom Window$()機能を使用することで、またファイルを削除するためにKill 機能を使用することでmessage.docを保存した後に、message.docファイルを削除するようにマクロを変更することができる。さらに、message.docファイルを開いているユーザがメッセージ削除を変えられるようにマクロを変更することもできる。第5(a)図〜第5(c)図および下記の表1は、Microsoft Excel^TM文書に関連して説明した自己破棄文書システムを示している。表1を参照すると、Microsoft Windo ws^TM環境で実行されるユーザインタフェースを含む、自己破棄Excel文書を作成するためのVisual Basic^TMプログラムが示されている。図示した実現は、Micros oft Excel^TMによって支持される"auto#open"と"auto#close"ルーチンを使用したものである。説明した実施例によれば、これらのルーチンはMicrosoft Excel^TM のxlstartサブディレクトリ内の"book.xlt"テンプレートに常駐している。この方法において、book.xltはauto#openとauto#closeと共に、作成された各Microso ft Excel^TM文書用のテンプレートとして使用される。従って、これらルーチンは Excel文書自体の中に常駐する。 Excel文書を作成するたびに、表1のプログラムがマクロとして文書内にエンベッドされる。文書を閉じる時、auto#closeルーチンが実行される。カスタム文書特性から変数"lcdata"と"lcmode"読出した後に（表1、23〜26行）、プログラムはこの文書に生存期間制御がまだ設定されていないかどうかを調べる（表1、28 行）。生存期間制御が既に実行されている場合には、auto#closeルーチンが出される（表1、29行）。生存期間制御がまだ実行されていない場合には、プログラムがユーザに生存期間制御の実施を望むかどうかを聞く（第5a図）。ユーザが望む場合には、プログラムがユーザにその文書の満了日付を入力するよう命じる（第5(b)図、表1、35〜36行）。次に満了日付が"lcdata"として保存され、"lcmode "が"1"に設定される（表1、37〜38行）。ユーザが生存期間制御の実施を望まない場合には、"lcmode"は"0"に設定され、"lcdata"は""に設定される（表1、39〜 41行）。"lcmode"と"lcdata"の値はExcel^TM文書内にカスタム文書特性として記憶される。エンベッドされたプログラムを含むExcel^TM文書が開かれると、auto#openマクロ（表1、2〜20行）が実行される。"lcmode"と"lcdata"はカスタム文書特性から読出される（表1、4〜7行）。"lcmode"が "1"と同等であり（9行）、現在日付が "lcdata"内の日付後である場合（10行）、文書名が変数"fn"として記憶され（12 行）、文書が無効であることを示すメッセージがコンピュータのディスプレー画面上のメッセージボックスに表示され（第5(c)図、表1、14行）、文書が閉じられ、削除される（15〜16行）。表1のプログラムが削除前にExcel文書を空データで上書きしない場合には、例えば以下に示すVisual Basic^TMプログラム言語でのクリア方法を利用してこのような機能を簡単に追加することができる。第6a図〜第6c図および表2（a、b）は、Microsoft Word97^TM文書に関連して説明した自己破棄文書システムを示すものである。表2（a、b）を参照すると、Mic rosoft Word環境で実現されるユーザインタフェースを含む、例証的な自己破棄W ord97文書を作成するためのVisual Basic^TMプログラムを示している。図示した実現は、生存期間制御を開始するためにFileSaveおよびFileSaveAsマクロを使用し、生存期間制御を強制するためにAutoOpenマクロを使用する。例証的な実施例によれば、表2のプログラムがテンプレートとして文書中にエンベッドされる。 Word97^TM文書を作成するたびに、表2のプログラムが文書中にエンベッドされる。プログラムは作成者のワークステーション上の外部文書テンプレート内に常駐し、表2cに示すAutoNewマクロによって新規文書中にコピーされる。このマクロはテンプレートSDD.dotから表2のプログラムを読出し、その内容を、Microsof t Word Organizerオブジェクトを使って新規文書にコピーする機能"InstallSDD" を実行する。この方法を使うことにより、本発明のこの実施例に従って、エンベッドされたプログラムが文書内に閉込められる。新規文書が保存されると（表2bのFileSaveまたはFileSaveAS）、変数"lcmode" が読出される。"lcmode"が定義されていない場合には（すなわち、この文書を保存するのはこれが初めてである場合）、"pflmplementLifetimeControls"ルーチン（表2a）が呼出され、プログラムがユーザに生存期間制御の実施を望むかどうかを聞く（第6a図、表2a）。望む場合には、プログラムがユーザに、文書の満了日付を入力するよう命ずる（第6(b)図、表2a）。次にこの満了日付が"lcdata"として保存され、"lcmode"が"1"に設定される（表2a）。ユーザが生存期間制御の実施を望まない場合には、"lcmode"が"0"に設定され、"lcdata"が""に設定される（表2a）。"lcmode"と"lcdata"の値はWord97文書内に文書変数として記憶される。エンベッドされたプログラムを含むWord97T^TM文書が開かれる時、AutoOpenマクロ（表2b）が実行される。"lcmode"および"lcdata"の値が"pfGetLcmode"と"pf GetLcdata"機能を使って読出される(表2a、2b)。"lcmode"が"1"と同等である場合（表2b）、また、現在日付が"lcdata"の日付を過ぎている場合には、文書名が変数doc内に記憶され（行12）、変数"rng"が文書の長さに設定され、文書が空データ（ret=rng.Delete）で上書きされ、次に削除され（Kill(dlg.name)）、この文書が無効であることを表すメッセージがコンピュータのディスプレー画面上のメッセージボックスに表示される（第6(c)図、表2b）。第7(a)図〜第7(e)図および表3は、Microsoft Outlook^TM98に関連して説明した自己破棄文書システムを示す。表3を参照すると、Microsoft Windows環境で実行されるユーザインタフェースを含む、自己破棄Outlook^TM98Eメールメッセージを作成するための例証的なWordBasicプログラムを示している。第7(a)図、第7(b) 図を参照すると、デフォルトEメールメッセージテンプレートに、「自己破棄」と名付けられたタブ73が追加されている。第7(a)図は、ユーザがEメールメッセージの作成を望む時に表示される、従来の「メッセージ」タブ74を示している。タブ74はEメールメッセージテキスト76と、Eメール77の受信者のアドレスを含んでいる。第7(b)図は自己破棄タブを示しており、これは、メッセージが自己破棄メッセージであるかどうかを示すトグルボックス71と、破棄の日付を入力する日付ボックス72とを含んでいる。下記に説明するように、破棄日付はEメールメッセージ内にエンベッドされ、Eメールメッセージが開かれた時に検索され実行される。 Outlook98は、Visual Basicコードを支持するOutlook ltems（メッセージ、カレンダー、入力、タスク等の個々のオブジェクト）を支持する。各Itemについて事象の収集が定義され、各事象を確認するためにVisual Basicコードが書込まれる。Outlookオブジェクトモデルにおいて、Eメールメッセージは"MailItem”として知られている。Outlook^TMでは、プログラマはアプリケーション動作を妨害および変更でき、また、メッセージの作成とメッセージを開く両動作を妨害および変更できる。表3は、Eメールメッセージにエンベッドされ、Item#Open機能を使ってEメールメッセージが開かれる時にはいつでも実行されるVisual Basicプログラムを図示している。Eメールメッセージが作成され、トグルボックス71内にチェックが入力され、自己破棄タブ73の日付ボックス72に日付が入力されると、トグルボックス71の値が"Item.UserProperties("DoDestruct")"に記憶され、日付ボックス72 に入力された日付が"Item.UserProperties("DestructDate")に記憶される。これらの値は、表3のプログラムに沿ってEメール内にエンベッドされる。Eメールメッセージが開かれると、エンベッドされたプログラムFunction Item#Openが自動的に実行される。表3を参照すると、DoDestruct特性がFalseである場合（すなわち、メッセージが自己破棄メッセージでない場合）には、プログラムエクシットされ、Eメールメッセージが開かれる。しかし、DoDestruct特性がTrueである場合には、プログラムは、"daysTilDestruct"を実行する機能"itemExpired,"を実行することによりメッセージが満期になっているかどうかを調べる。機能daysTi lDestructは、"DestructDate"の値から現在の日付を減算し、日数の差異を戻す。機能daysTilDestructによって戻された値は機能itemExpired内の変数"dt"に記憶される。"dt"がゼロより少ない、または同値である場合には、機能"itemExpir ed"がブール値Trueを機能Item#Openに戻し、第7(e)図に示すように、メッセージのテキストが「このメッセージは使用不可能」というメッセージによって上書きされ、次に第7(d)図に示すように「このメッセージは使用不可能」のメッセージがダイアログボックスに表示される。"dt"が1よりも大きい場合、"itemExpired" が論理値Falseを戻し、第7(c)図に示すように、「このメッセージは[daysTilDes truct]日後に破棄される」のメッセージがダイアログボックスに表示される。表1〜表3 表 1 表 2A 表 2B 表 2C 表３さらに、上記に述べた自己破棄文書に従った実行可能モジュールはまた、ユーザが例えば、実行可能モジュールを実行することが不可能なアプリケーションを伴う自己破棄文書を開くことによって、生存期間制御を無効にしてしまうことを防止するために、暗号技術を使用することもできる。このような実施例に従って、文書を初めて保存または閉じる際に、実行可能モジュールがその文書を暗号化する。次に、これに続いて文書が開かれると、生存期間規制が有効である場合のみに限り、実行可能モジュールが文書を暗号化する。さらに、実行可能モジュールを実行することができないアプリケーションで文書を開いた場合には、文書は暗号のまま残るのでユーザが文書を見ることはできない。例えば、ユーザがWord Perfect^TMアプリケーションを使って自己破棄Microsoft Word^TM文書を開こうとした場合、WordPerfect^TMアプリケーションはMicrosoft Word^TMAutoOpenまたはF ileOpenマクロを実行せず、文書の生存期間が有効であるかどうかに関わらず文書を開く。しかし、自己破棄Microsoft Word^TM文書が予めAutoClose,，FileSave またはFileSaveAsマクロによって記号化されている場合（例えば、下記に示すような独占的または多文字的な暗号文）、ユーザがマクロ（独占的または多文字的暗号文のための関連する解読アルゴリズムを含む）を実行するアプリケーションを使ってファイルを開かない限り、文書は暗号化されたままになる。適切な暗号化技術の選択は、所望の安全性の度合と、これを実行するためのマクロまたはスクリプトの能力とに依存する。仮想コンテナ次に、仮想コンテナを採用した、本発明による文書機密保護システムについて説明する。第8a図に示した文書機密保護システムの第1実施例によれば、各々が独立した生存期間規制520を備えた1つ以上の文書510（またはその他のデジタルオブジェクト）の保存のために、文書設定コンテナ500が使用される。ユーザは、コンテナの内容を開いて表示したいコンピュータにユーティリティをインストールする。ユーティリティは、ユーザの要求に従い文書が表示される前にこの生存期間規制を確認する。生存期間規制が確認された場合には、コンテナから文書が抽出され、ユーザはこれを使用することができる。生存期間規制が確認されない場合には、文書は、例えば空白データで上書きされて破棄される。第8(b)図に示す文書機密保護システムの第2実施例によれば、単一の文書510′ （またはその他のデジタルオブジェクト）を記憶するためにコンテナプロキシ50 0′を使用することができる。ユーザがプロキシコンテナ内の文書を開いて表示したいと望む任意のコンピュータに、プロキシハンドラをインストールする。文書設定コンテナと違い、文書の生存期間規制520′が確認されない限り、プロキシの操作はユーザにとって不可視である。この透明性を提供するために、プロキシに名称が付けられるか、または文書の正規実現値として現れるように暗号化され、文書とそのアプリケーションを関連付けするオペレーションシステム機構が、代わりに文書とプロキシハンドラを関連付けするために変更される。プロキシハンドラは、生存期間規制が有効である場合、文書とアプリケーション間の関連を推移的に完了する。この実施例には、例えばWindows 95^TMデスクトップ、「マイコンピュータ」内のWindows 95文書アイコンから、またはWindows 3.1のファイルマネージャから、ファイルをマウスでクリックすることによりファイルがアクセスされると、オペレーションシステムがファイルを、Microsoft^TM Word、Mi crosoft Excel^TM、 WordPerfect^TMといったアプリケーションと関連付け使用とする利点がある。コンテナプロキシによれば、オペレーティングシステムとアプリケーションの間にコンテナプロキシユーティリティがインターポーズされるため、ユーザがコンテナプロキシ（ユーザには普通文書として現れる）にアクセスする際、オペレーティングシステムがコンテナオープナーを呼出してコンテナを自動的に開き、もし生存期間規制が有効であれば、アプリケーションを開始してコンテナ内の文書を開く。生存期間規制が無効の場合には、文書は、例えば空白データで上書きすることによって、および/または文書を削除することによって破棄される。コンテナプロキシのさらなる実施例によれば、アプリケーションが閉じられたら文書をコンテナプロキシに自動的に戻すようにシステムを構成することができる。次に、文書設定コンテナ（DSコンテナ）の様々な実施例について説明する。DS コンテナの第1実施例によれば、コンテナオープナユーティリティとコンテナクリエータユーティリティが提供される。コンテナオープナユーティリティは、ユーザがDSコンテナを作成したいと望むコンピュータ上に存在し、その名前が指示する通り、DSコンテナの作成、生存期間規制の指定、文書のDSコンテナ内への配置操作が可能である。コンテナオープナユーティリティは、ユーザがDSコンテナを開きたいと望むコンピュータ上に存在し、DSコンテナを開き、生存期間規制の有効性を調べる、そして、生存期間規制が有効である場合、DSコンテナから文書を抽出する操作が可能である。生存期間規制が無効である場合には、文書は、例えばその文書を空白データで上書きする方法で破棄される。1実施例によれば、D Sコンテナは文書を1つだけ含んでいる。さらなる実施例によれば、複数の文書を 1つのコンテナに記憶することができ、各文書に独自の生存期間規制を設定することができる。ユーザがDSコンテナを開くことが許されるが、DSコンテナを作成することは許されないことが好ましいという状況においては、コンテナクリエータユーティリティなしで、コンテナオープナユーティリティをコンピュータにインストールすることができる。DSコンテナ内に存在する文書の数に関わらず、開かれていないDSコンテナはユーザには1つのファイルとして現れ、単数または複数の文書と共に、ヘッダ情報（例えば生存期間規制を含む）を含んでいる。本発明の複数文書DSコンテナのさらなる局面によれば、DSコンテナは、コンテナの制御情報を含む、また、2つの単一的にリンクしたストリームのリストに関連するコンテナヘッダを備えることができる。第1リンクリストはアクティブストリームを含み、第2リンクはインアクティブストリームを含む。アクティブストリームは、まだ有効な生存期間規制を有する文書と関連し、インアクティブストリームは無効の生存期間規制を有するか、またはコンテナから除去（削除）された文書と関連する。稼動状態、インアクティブ両ストリーム共、その関連するストリームのための生存期間規制（および、好ましくは下記に述べる暗号化情報）を含むヘッダを有する。これらのストリームヘッダは、その各々が、リスト（稼動状態、インアクティブどちらでも）における次のストリームの参照か、またはこのストリームがそのリストにおける最後であるという標識を含んでいる。各ストリームはバイナリデータの連続するブロックである。ストリームが無効にされるか、あるいはコンテナから除去されると、そのストリームヘッダに非稼動状態であるとマークされ、インアクティブストリームリストヘ移動され、そして、そのストリーム自体が空白データで上書きされる。コンテナに新規ストリームが追加されると、インアクティブストリームが、新規ストリームを含むのに十分な長さであれば再稼動され使用されることが可能である。使用できるインアクティブストリームがない場合、または新規ストリームを含むのに十分なインアクティブストリームがない場合には、コンテナ内に新規ストリームを作成し、これを稼動状態にすることができる。1つのコンテナが、稼動状態およびインアクティブストリームリストへの多くの変更を経験すると、断片化してしまう可能性がある。言いかえれば、文書が満了し、これが空白データで置換されると、アクティブ文書が1つ以上の単に空白データを有する非稼動状態文書で挟まれる。本発明の好ましい実施例において、コンテナクリエータユーティリティはこの状態を検出し、必要に応じてコンテナを圧縮する。第9(a)図、第9(b)図は、本発明によるアクティブ/インアクティブストリームの具体例を示す。第9(a)図は、作成され、3つの文書を内含する仮想コンテナを示す。第9(a)図に示すように、コンテナヘッダは作成情報（コンテナ名、コンテナのデフォルト生存期間規制、コンテナの作成日、コンテナの前回変更日 DM 80 4、そしてコンテナの前回アクセス日）、アクティブストリームに関する情報（アクティブストリームにおける第1文書へのポインタ、アクティブストリーム内の文書の数）、インアクティブのストリームに関する情報（インアクティブのストリームにおける第1文書へのポインタ、インアクティブのストリーム内の文書の数）を含む。コンテナが作成されたばかりであるので、3つ全ての文書がアクティブストリーム内にあり、コンテナヘッダは、第1文書へのポインタと、3つの文書がアクティブストリーム内にあることを示す表示とを含むアクティブストリームサブヘッダを備えている。インアクティブストリームサブヘッダは空白情報を含んでいる。次に、第9(b)図において、コンテナに2つの新規文書（文書4、5 ）が追加され、文書2が満了する。アクティブストリームコンテナサブヘッダがまだ文書1を指している一方で、文書1ヘッダ内のポインタは文書2ではなく文書3 を指している。さらに、インアクティブストリームコンテナサブヘッダは、現在、文書2を指している。上記に説明したように、本発明による仮想コンテナは、無効になった時（各々の生存期間規制によって決定される）に破棄されなければならない1つ以上の文書を含んでいる。一般に、該制御を無効にするために必要な労力のコストは、文書の有効生存の延長の値を超えるものであるべきである。本発明の好ましい実施例によれば、仮想コンテナ内の文書は、コンテナ内の文書への無許可アクセスを防ぐために、またユーザが文書の生存期間規制を無効にしてしまうことを防ぐために、暗号化されている。これらの暗号化技術は、例えば第8a図、第9a図、第9b図のDSコンテナと、第8b図のプロキシコンテナとを含む、本文中で説明したあらゆる仮想コンテナで使用することができる。本発明のさらなる実施例によれば、システムによって作成者は、内含される文書の認識された値に基づいて、複数の機密保護レベルから選択することができる。一般に、機密保護のレベルが増すに従って、これを無効にするために必要な労力も増加し、また、機密保護自体のコストおよび複雑さも増加する。仮想コンテナ内で暗号化がどのように利用されるかを述べる前に、暗号化技術の基本原理についていくつか説明する。暗号化技術の概要一般に、暗号化技術−正式には暗号システムという−は、アルゴリズムとキーの2つの基本的な構成要素から成る。アルゴリズムはデータを転送する数学的機能である。キーは、転送の正確な性質を送る。暗号化アルゴリズムは簡単に開閉することができる。オープンアルゴリズムは設計者によって発行され、学究的な人々によって細かく観察され、商業的実現を通して綿密に調べられる。クローズアルゴリズムは特有の作業であり、設計者はこれを公に理解または使用されることを望まない。一般に、商業製品に使用された暗号アルゴリズムは「オープン」アルゴリズムである。発行され、観察され、長期にわたって広く実現された後にそのまま使用される暗号アルゴリズムは、一般的に安全なアルゴリズムであると考えられる。これは、このようなアルゴリズムはおそらく主要の研究大学によって分析され、世界中のコンピュータ科学専攻の学生によって攻撃されたと思われるが、それでも妥協することなく存在しているためである。効果的な暗号化システムの強さは、一般にそのキーから引出されるものである。暗号化アルゴリズムが（上述したように）サウンドであると仮定すると、暗号化システムの機密性は適切なキーを作成することと、その機密性の注意深い保護に依存する。適切性の重要な測定の1つは、一般にビットで表されるキーの長さである。短いキーは高速な暗号化と解読を可能にするが、暗号化されたメッセージ壊れ易い。長いキーは、長い暗号および解読処理が必要であるが、必然的に破棄は不可能である。この認識は非常に普及しているため、米国政府があらゆる暗号化アルゴリズムの自由でオープンな使用を容認しているが、キーの長さについては厳密な制限が適応されている。様々なオープン、クローズ暗号化技術の使用が本発明によって可能であるが、ここでは、対称アルゴリズム、公開キーアルゴリズム、デジタル署名、片方向ハッシュの4つの暗号化技術について簡略に説明する。一般に、対称アルゴリズムはメッセージの暗号化および解読のために単一のキーに依存している。これらのアルゴリズムは理解および使用が簡単で、正確に使用すれば比較的高度な機密性が得られる。しかし、受送信を行う両者は、キーを他の何者にも明かすことなく、通信の前にキーに同意しなければならない。さらに、古いメッセージを後になって解読されないために、キーを永久的に秘密にしなくてはならない。対称アルゴリズムは、通信が完了した後に保存されない一時メッセージには特に適している。メッセージが保存されなければ、後になってメッセージが解読される機会もなく、キーを危険にさらすこともない。適切な対称アルゴリズムは、ANSI（米国国家規格協会）およびISO（国際標準化機構）の標準であり、20年以上にわたって使用され続けているData Encryption Standard( データ暗号化規格)（DES）である。公開キーアルゴリズムは、1つが公開キーと呼ばれ、もう1つが専用キーと呼ばれるキーの対を使用する。公開および専用キーのいずれも、メッセージの暗号化に使用でき、メッセージの解読には別のキーを使用する。専用キーのみが、公開キーで暗号化されたメッセージを解読することができ、また、公開キーのみが、専用キーで暗号化されたメッセージを解読することができる。さらに、与えられた公開キーから別の専用キーを作り出すことは必然的に不可能である。一般に、あらゆる対の公開キーはよく知られた、信頼できる場所（例えばデータベースや、インターネット上のディレクトリ）に公開されているが、その一方で専用キーは所有者が保持する。公開キー暗号化に適した共通シナリオは次の通りである：アリスはボブに秘密メッセージを送りたい。アリスは信用できるソースからボブの公開キーを入手することができる。彼女はこのキーを使ってボブへのメッセージを暗号化する。ボブはこの暗号化されたメッセージを受信すると、自分の専用キーを使ってこれを解読できる。もし、a)アリスがボブの（偽造ではない）認証公開キーを入手し、 b)ボブが自分の専用キーの唯一の保持者である（誰もコピーを持っていない）場合、アリスのメッセージを読めるのはボブだけであると保証される。人気のある公開キーアルゴリズムはRSA Data Security，Inc.が所有するRSA暗号化システムである。デジタル署名は、メッセージの作成者の身分を立証するように設計されている。デジタル署名を実現する方法は多くあるが、公開キー暗号化が非常に一般的である。上述したシナリオを次のように延長することができる。アリスはボブにプライベートなメッセージを送りたいが、それが自分からのものであるとボブに確実に知らせたい。結局、先のシナリオではボブが受取ったメッセージがアリスからのものであることが保証されず、単にボブ以外の人物がそのメッセージを読むことができないことをアリスに保証するだけである。そのため、アリスは先ず、自分の専用キーを使ってボブへのメッセージを暗号化する。次に、上述した通りにボブの公開キーを使ってそのメッセージ（既に暗号化されている）を再度暗号化する。ボブはそのメッセージを受信すると、先ず自分の専用キーを使って解読を行う。次に、そのメッセージが本当にアリスからのものであることを確認するために、ボブは信用できるソースから彼女の公開キーを入手する。そしてそのキーを使ってメッセージの解読を行う。もしa)ボブが、（ボブの件で上述したように）アリスのキーがコピーまたは偽造されていないと確信があり、b)アリスがボブのキーに対して同様の確信がある場合、アリスはボブ以外の人物がメッセージを読めないことを保証され、さらに、ボブはそのメッセージがアリスからのものであることを保証される。RSA Data Security，Inc.は幅広く使用されるデジタル署名アルゴリズムを製造している。デジタル署名はデジタル領域における身分を証明するための信頼できる方法であるが、文書全体（大部分）を転送することなく文書の作成者の身分が証明されなければならない特定の例がある。片方向ハッシュは優れた解決法を提供する。片方向ハッシュは、あらゆるデータ設定（または文書その他）をバイナリ情報の小さなストリームに変換する数学的機能である。片方向ハッシュ機能の重要な特性の1つは、この機能が2つの異なるソースから2つの同一のハッシュを作成してはいけないということである。この特性を有する片方向ハッシュの作成のために、学術的および商業的な著しい研究努力がなされてきた。MD5は非常によく知られた、128ビットハッシュを作成する片方向ハッシュ機能である。暗号化技術の仮想コンテナへの適用本発明の好ましい実施例によれば、仮想コンテナ文書機密保護システムによりユーザ（および/またはシステム管理者）はいくつかのレベルの機密保護からの選択が可能である。機密保護の第1レベルは文書の暗号化を全く含まないかもしれない。その機密保護は、文書を表示するためにコンテナの受信者がコンテナオープナを使用ことを必要とすることから生じる。しかし、市販されている数種のバイナリファイルエディタのいずれかを使用すればコンテナ自体を開くことができ、文書の内容を見ることができる。同様に、ほとんどのワード処理プログラムにおいてユーザは文書からASCIIテキストを検索できるので、このようなプログラムを使えばコンテナを1つの文書として開くことができ、コンテナ内のあらゆるテキストを見ることができる。機密保護の第2レベルは、独占的または多文字的暗号文と呼ばれる対称暗号化の形であることができる。この暗号化アルゴリズムはソフトウェア内での実現が簡単で、動作が非常に速い。この暗号化アルゴリズムは、文書の暗号化と解読に 1つのキーを使用する。このキーはソフトウェア内に「ハードコード」されることができ、ソフトウェアと共に分配され、ユーザによって定期的に変更されることができ、また、このキーは、必要がある度に信用できるソースから入手することができる。この方法によれば、このキーで文書をexclusive-or-ingすることによって、文書を暗号化することができる（すなわち、［Document］XOR［key］=［E ncrypted Document]）。その1例として、コンテナオープナとコンテナクリエータユーティリティは、暗号化および解読の両方のための「ハードコードされた」対称キーを1つ備えている。文書の作成者はコンテナクリエータを使って、文書と、任意的にその生存期間規制とを暗号化する。作成者がその文書を分配したいと望む場合、暗号化された文書を仮想コンテナ内に転送する。受信者は、コンテナオープナユーティリティを使って文書とその生存期間規制を解読する。コンテナオープナユーティリティが生存期間規制を調べ、これが有効であれば受信者に文書を表示する。生存期間規制が無効である場合は、文書はコンテナオープナユーティリティによって破棄される。機密保護のこれ以上のレベルは、文書の機密保護をさらに確実にするために中央権限（CA）を利用することができる。CAシステムの第1実施例によれば、作成者が文書とその生存期間規制をCAに送信する。CAは、その文書用の固有識別子を返送する。作成者がその文書を配送したいと望む際に、彼は受信者に固有識別子を転送する。受信者は文書を読むために、その固有識別子をCAに送る。CAは生存期間規制を調べ、これが有効であれば依頼人に文書を返送する。依頼人は文書を受信し、これを表示する。CAの使用により機密保護が拡大するが、中央権限の仲介を必要とする欠点がある。 CAシステムのさらなる実施例は片方向ハッシュを利用するものである。この実施例によれば、作成者はCAに文書とその生存期間規制を送る。CAは生存期間規制をハッシュし、オリジナルの生存期間規制、ハッシュした生存期間規制、文書を組合せてコンテナに入れる。CAは専用キーを使ってこのコンテナを暗号化し、作成者に返送する。作成者はこの文書を配送したいと望んだ際に、CAが署名したコンテナを受信者に転送する。受信者はCAの公開キーを使ってこのコンテナを開き、生存期間規制を調べる。これが無効であればコンテナは破棄される。有効であれば、これをハッシュし、コンテナ内に記憶されたものと比較する。ハッシュが合致しない場合はコンテナは破棄される。ハッシュが合致し、生存期間規制が有効であれば、文書が表示される。 CAシステムのまたさらなる実施例は片方向ハッシュと対称キーを利用するものである。この実施例によれば、作成者は文書とその生存期間規制をCAに送る。CA は固有対称キー（以下DK）を作成し、文書を暗号化する。そしてDKと固有識別子（以下DKID）をデータベースに記録する。CAはオリジナルの生存期間規制をハッシュし、オリジナルの生存期間規制、ハッシュされた生存期間規制、暗号化された文書、そしてDKIDを含むコンテナを作成する。CAは専用キーを使ってこのパッケージに署名し、これを作成者に返送する。作成者は、文書の配送を望む際に、 CAが署名したパッケージを送信する。受信者はCAの公開キーを使ってこのパッケージを開ける。そして、オリジナル生存期間規制、ハッシュされた生存期間規制、DKIDをCAに送信する。CAは生存期間規制を調べる。これが無効である場合、CA は停止する。有効であれば、CAはこれらをハッシュし、これを受信者から受信したハッシュに対してハッシュする。ハッシュが合致しない場合にはCAは停止する。ハッシュが合致し、さらに生存期間規制が有効である場合は、CAは受信者に、 DKIDと関連するDKを返送する。受信者はこのDKを使って文書を解読し、文書を表示する。この実施例の問題は、受信者が、新規の生存期間規制を作成し、これをハッシュし、ハッシュされた新規の生存期間規制をコンテナのオリジナルDKIDと共にCA に送信することで、このシステムを無効にすることができる点である。この問題は、CAが、オリジナルの生存期間規制、ハッシュした生存期間規制、DKIDの暗号化したサブコンテナを作成するという、この実施例のさらなる局面によって緩和される。（単数または複数の）暗号化キー（例えば、対称キー、あるいは公開および専用キー）はCAしか知らない。受信者（サブコンテナへのキーへのアクセスを持っていない）がCAにサブコンテナを返送する。次に、CAがサブコンテナを解読する際、サブコンテナから検索した生存期間規制、ハッシュした生存期間規制、DKIDが、CAによって作成および暗号化されたものであること確信できる。 Java^TM プログラム言語における仮想コンテナの実現次に、1つの文書を含むDSコンテナの例証的実現、また、排他的あるいは多文字的な暗号文の採用について説明するが、ここで、コンテナクリエータとコンテナオープナユーティリティはJava^TMプログラム言語でプログラムされている。コンテナクリエータとコンテナオープナは、Javaプログラム言語の標準I/Oパッケージの1部を形成する、データおよびファイルストリームクラスを使って実現される。特定のストリームクラスの各オブジェクトはメモリの連続バイトのセットと関連する。コンテナの実施例によるDSコンテナは、コンテナの制御情報を含むコンテナヘッダ、コンテナ内の文書用の文書ヘッダを備えている。このDSコンテナの実施例は文書を1つしか保持できないように構成されているが、下記に述べるさらなる実施例は、無制限の数の文書を保持することが可能である。第10a図を参照すると、この単一文書DSコンテナ実施例の好ましい実現により、コンテナヘッダがコンテナ名CNAME 701、コンテナの作成日DC 703、前回コンテナが変更された日付D M 705、前回コンテナがアクセスされた日付DLA 704、コンテナ内の文書数706（0 または1）を含んでいる。コンテナはまた、1つの文書710を含んでいる。この文書は、文書名(707)を含むヘッダ、文書の生存期間規制(708)、文書の長さ（709 ）を備えている。この実施例によれば、DC 703、DM 704、DLA 705フィールドによって、ユーザは、表5(a)の方法を参照して下記に説明するように、コンテナの作成日、前回の変更日、前回のアクセス日を決定することができる。当然、この機能を望まない場合には、コンテナヘッダからコンテナの作成、前回変更、前回アクセスフィールドを省略することも可能である。次に、下記に示す表4(a)を参照すると、DSコンテナは、列「エンベロープファイル名」を引数として含むメソッド"public static int create(String envelop efilename)"を呼出すことにより作成される。"envelopefilename"が存在するファイル名である場合、または、null値を有する場合には、エラーが戻されるか、またはプログラムが進行して新規のコンテナを作成する。FileOutputStreamで、オブジエクト"fos"は宛先のファイル名"envelopefilename"を持っていると定義される。DataOutputStreamで、関連するオブジェクト"dos"はオブジェクト"dos" （"envelopefilename"である）に関連する宛先データを持っていると定義される。次に、プログラムがDataOutputStreamオブジェクト"dos"内に記憶されるヘッダを作成する。これに関連し、オブジェクト"eh"がクラスSdeEnvelopeHeader内で定義され、クラスSdeEnvelopeheaderの"d#name"フィールドがストリング"enve lopefilename"に設定され、"d#created"、"d#last# modified"、"d#last#access ed"フィールドが現在の日付に設定される。次に、コンテナ名、コンテナ作成日、コンテナが前回変更された日付、コンテナが前回アクセスされた日付、コンテナ内の文書数（現在は0）をオブジェクト"dos"に書込むメソッド"writeTo"が呼出され（表4(c)）、これにより、新規に作成されたコンテナ用のコンテナヘッダを作成する。この方法において、コンテナは、"envelopename"フィールド内の名前を持った単一のファイルとして現れる。次に、表4(b)を参照すると、コンテナに文書を追加するために、メソッドaddD ocumentが呼出される。メソッドaddDocumentは"envelopefilename"、"documentf ilename"、"expires"をパラメータとしてとる。いずれかのパラメータが空白である場合には、エラーが戻される。"envelopefilename"という名前のコンテナが存在しない場合は、コンテナ作成のために"create"メソッド（表4(a)）が呼出される。"documentfilename"という名前の文書がない場合は、エラーが戻される。そうでない場合には、FileInputStreamのオブジェクト"fis"が"envelopefilenam e"に定義され、DataInputStreamのオブジェクト"dis"が"envelopefilename"(Dat aInputStream(fis))に関連するデータに定義される。次に、一時コンテナが作成され、"[envelopefilename].temp"と名付けられる。これに関連して、FileOutpu tStreamのオブジェクト"fos"が"[envelopefilename].tempに定義され、DataOutp utStreamのオブジェクト"dos"が"envelopefilename"(DataInputStream(fos))に関速するデータに定義される。次に、エンベロープヘッダをアップデートするために、SdeEnvelopeHeaderのオブジェクト"eh"が作成され、"dis"の内容（"envelopefilename"のコンテナヘッダ）がメソッド"readFrom"によって"eh"内に読取られる（表4(c)）。再び表(b )を参照すると、クラスSdeEnvelopeHeaderのオブジェクト"d#last#modified"、" d#total#documents"がアップデートされ、DataOutputStreamのオブジェクト"dos "にアップデートされたエンベロープヘッダ（eh）が書込まれている。文書ヘッダをアップデートするために、Fileのオブジェクト"file#doc"が"doc umentfilename"のパスに設定され、変数"length"が"file#doc"に置かれたファイルの長さと等しく設定される。FileInputStreamのオブジェクト"fis#doc"が"doc umentfilename"を持つように設定される。次に、SdeDocumentHeaderのオブジェクト"dh"が作成され、クラスSdeDocumentHeaderの"d#name"フィールドがストリング"documentfilename"に設定され、"d#expired"フィールドがパラメータ"expi res"に設定され、"d#total#bytes"フィールドが変数"length"の値に設定される。次に、文書名、満了日、文書の長さをオブジェクトdosに書込むメソッド"writ eTo"が呼出され、文書に文書ヘッダを作成する（表4(d)）。次に、文書が変数"ch"(int ch=fis#doc.read())内に読出され、"ch"上のexclu sive-or機能を実行することにより暗号化される。この方法によれば、コンテナは、コンテナのCNAME 71内の名前を持つ単一ファイルとして現れ、コンテナヘッダ、文書ヘッダ、文書を含む。次に、表5(a)、表5(b)を参照して、DSコンテナオープナの実行について説明する。表5(a)は、表4(a)〜表4(c)に従って作成されたDSコンテナのコンテナヘッダを見るためのプログラムを示す。メソッド"view"は、ストリング"envelopename" と、PrintStream"ps"の2つのパラメータを含む。"envelopename"または"documen tfilename"のいずれも"null"でなく、"envelopename"と名付けられたコンテナが存在する場合、FileInputStreamのオブジェクト"fis"が"envelopename"に定義され、DataInputStreamのオブジェクト"dis"が"envelopename"(DataInputStream(f is))に関連するデータに定義される。SdeEnvelopeHeaderのオブジェクト"eh"が作成され、"dis"（"envelopename"のコンテナヘッダ）の内容がメソッド"readFr om"によって"eh"に読出される（表4(c)）。最終的に、メソッド"println"を使ってコンテナヘッダ情報が印刷される。表5(b)は、表4(a)〜表4(d)に従って作成されたDSコンテナを開くためのプログラムを示す。メソッド"extractDocument"は、ストリング"envelopefilename"、" documentfilename"の2つのパラメータを含んでいる。"envelopename"、"documen tfilename"のいずれも"null"でなく、"envelopename"と名付けられたコンテナが存在する場合、FileInputStreamのオブジェクト"fis"が"envelopefilename"に定義され、また、DataInputStreamのオブジェクト"dis"が"envelopefilename"(Dat aInputStream(fis))に関連するデータに定義される。この方法では、"envelopen ame"と名付けられたコンテナが"fis"および"dis"において開かれる。次に、SdeE nvelopeHeaderのオブジェクトehが作成され、クラスSdeEnvelopeHeader（"envel opefilename"のコンテナヘッダ）のdisの内容がメソッド"readFrom"によって"eh "内に読出される（表4(c)）。次に、SdeDocumentHeaderのオブジェクト"eh"が作成され、クラスSdeDocumentHeader（文書ヘッダ）内の"dis"の内容がメソッドre adFromによって"dh"内に読出される（表4(c)）。次に、フィールド"d#name"が"d ocumentname"と比較され、この2つが同じであればプログラムが進行して文書"do cumentname"の満了日を調べる。Dateメソッド"before"を使用し、もしフィールド"d#expires"内の日付が現在の日付より前のものであれば、変数"valid"がfAls eに設定される。そうでない場合には、文書のパスはクラスFileのオブジェクト" file#doc"内に入れられる。文書"documentname"が存在し、文書が満了していないと仮定して、オブジェクト"file#doc"は新規パス"[documentfilename].x"に設定され、FileOutputStream のオブジェクト"fos#doc"はFileOutput Stream(file#doc)に設定される。この方法では、クラスFileOutputStreamの一時ファイル"fos#doc"が作成される。次に、変数"ch"内に1バイトずつ文書が読出される。続いて、"ch"にX0R機能を実行することで各バイトが解読され、"fos#doc"に書込まれる。文書が存在しない場合は、"fos#doc"がnull値に設定され、ファイルが見つからない旨をプログラムが表示する。文書が存在するが、満了している場合は、"valid"変数がFALSEに設定される。これにより"fos#doc"が文書と関連することを防ぎ、文書の解読を防止し、文書が満了している旨をプログラムに表示させる。文書を削除するために上書きするには、表5bに次の命令を挿入する。第11(a)図、第11(b)図は、表4、表5に関連して上述した単一文書DSコンテナと、第12図、第13図に関連して下記に示す複数文書DSコンテナとの両方を実行するために使用される単純なグラフィカルユーザインタフェースを示す。DSコンテナを作成するには、ユーザは「新規」ボタン1510をクリックする。ユーザにコンテナ名の入力を促すためのダイアログボックス（図示せず）が表示される。コンテナ名が入力されると、DSコンテナが作成され、コンテナ名がバナー1500上に現れる。第11(a)図、第11(b)図において、コンテナ名は"demo.env"であり、コンテナはファイル"demo.env"として"C:＼"ディレクトリに保存される。DSコンテナに文書を追加するには、ユーザは「追加」ボタン1520をクリックする。ファイルメニュー(図示せず)が表示され、ユーザは、所望の文書のための使用可能なディレクトリをブラウズするか、パスと文書名を直接入力するかを選ぶことができる。文書を選択し、ボックス1540に満了日を入力すると、コンテナに文書が追加される。コンテナへの文書の追加が成功すると、文書名、文書の長さ、文書の満了日がボックス1550に表示される。第11(b)図を参照すると、文書"demo.txt"の満了日後にコンテナ"demo.env"が開かれた場合には、文書は自動的に空白データで上書きされ、文書が満了している旨のメッセージがボックス1550に表示される。コンテナから文書を抽出するためには、ボックス1550内の文書をクリックして文書を選択し、次に「抽出」ボタン1530をクリックする。コンテナから文書が抽出され、コンピュータ内の指定されたディレクトリに保存される。文書が満了している場合は、システムはボックス1550でのその文書の選択を拒絶する。上述したように、DSコンテナのさらなる実施例によれば、複数の文書およびその他のデジタルオブジェクトを保持するために、コンテナの拡張、縮小が可能である。コンテナへの新規文書（または他のデジタルオブジェクト）の追加、コンテナ内に存在する文書のアップデートまたは削除、複数のコンテナの併合が可能である。コンテナ内の各文書は独自の生存期間規制と、異なるレベルの機密保護を備えることができる。コンテナの機能を提供するために、DSコンテナは単一ファイル内の仮想ファイルシステムとしてモデル化される。仮想ファイルシステムは、外部世界に単一ファイルとして現れる記憶ユニットであるが、一方で、その内部では実際に多くのファイルとその生存期間規制を管理している。従来、仮想ファイルシステムは階層ディレクトリ構造を含むものであるが、DSコンテナには平坦な−単一ディレクトリー構造を使用することが好ましい。本発明の好ましい実施例によれば、DSコンテナは次の動作を支持する。i)新規DSコンテナを作成する、ii）独立した生存期間規制と機密保護を備えた新規文書をDSコンテナに追加する、iii）DSコンテナ内に存在する文書を、生存期間規制または機密保護を変更することなくアップデートする、iv）DSコンテナ内の文書の生存期間規制または機密保護をアップデートする、v）DSコンテナから存在する文書を削除する、vi）DSコンテナ内の文書を、その生存期間規制に従って無効にし、これをDSコンテナから削除する、vi i）DSコンテナを破棄する。この実施例によるDSコンテナは、コンテナの制御情報を含むコンテナヘッダと、コンテナ内の各文書の文書ヘッダとを備えている。次に第10b図を参照する。この実施例の好ましい実現によれば、コンテナヘッダはコンテナ名CNAME 801、コンテナDLC 802のデフォルト生存期間規制、コンテナの作成日DC 803、前回コンテナが変更された日付DM 804、前回コンテナがアクセスされた日付DLA 805、コンテナ内の文書数806を備えている。第10(b)は、2つの文書904.1、904.1を有するDSコンテナを示すものである。各文書は、文書名（ 901.1または901.2）、文書の生存期間規制（902.1または902.2）、文書の長さ（ 903.1または903.2）を含むヘッダを備えている。この実施例によれば、コンテナに文書が追加された際に、エンベロープヘッダ内のDLS 802がデフォルト生存期間規制として使用される。DC803、DM804、DLA805フィールドにより、ユーザは、表5(a)のビューメソッドと似たルーチンを実行することにより、コンテナの作成日、前回変更日、前回アクセス日を決定することができる。当然、この機能を望まない場合は、デフォルト生存期間規制、コンテナ作成、前回変更、前回アクセスフィールドをコンテナヘッダから省略することもできる。第10b図のDSコンテナが、第10a図および表4a〜表5bのDSコンテナと同じ方法で実行されるため、この実施例をプログラムする方法の詳細な説明は省略する。次に第12図のフローチャートを参照する。存在するDSコンテナに文書を追加するために、DSコンテナが開かれ（段階1010）、コンテナヘッダ（コンテナ名、デフォルト生存期間規制、作成日、前回変更日、前回アクセス日、文書数を含む）が読出される。次に、段階1030において、コンテナに追加する新規文書のヘッダが作成され、このヘッダは文書名、文書の生存期間規制、文書の長さを含んでいる。次に、文書ヘッダと文書自体がコンテナの最後に付加され（段階1040、1050 ）、前回アクセス、前回変更、文書合計数フィールドの値がアップデートされ（段階1060）、新規値が新規コンテナヘッダとして書込まれる。第12図のフローチャートによれば、アップデートされたコンテナはオリジナルコンテナを上書きする。これは、アップデートされたコンテナが新規ファイルとして作成され、次いでオリジナルコンテナが削除される、表4a〜表5bの実施例と対称的である。当然、表4a〜表5bのメソッド（すなわち、オリジナルコンテナを上書きする）を採用するように第10b図、第13図の実施例を変更することができ、またその逆も可能である。次に第13図のフローチャートを参照する。第10b図のDSコンテナから文書を抽出するために、コンテナが開かれ（段階1110）、コンテナヘッダが読出される。段階1130において、抽出する文書名がdnameフィールド901内の名前と比較され、 2つの名前が同じであればプログラムは段階1140へ進む。名前が違う場合にはプログラムは段階1150へ進む。Dnameフィールド内の現在の文書名が要求された文書と同じであると仮定し、プログラムは段階1140において、文書の生存期間規制が有効であるかどうか（例えば、現在の日付が満了日より後の日付であるかどうか）を決定する。生存期間規制が有効であれば現在の文書が抽出される。生存期間規制が無効である場合には文書は削除される。文書削除の例証的コードセグメントを下記に示す。ここで、機能getTotalBytes()が現在の文書の文書ヘッダから文書の長さを検索する。現在の文書が要求された文書でない場合、プログラムは、段階1150において、現在の文書の内容を飛ばし、次の文書ヘッダまたはエンベロープの最後へとスキップする。コンテナの機能を実行するための例証的コードは次の通りである。この方法において、プログラムは現在の文書を越えて読出しを行うため、プログラムが段階1120に戻る際に、コンテナ内の次の文書の文書ヘッダを読出すように設定される。文書が抽出されたら、コンテナヘッダ内の前回アクセスフィールドがアップデートされ（段階1160）、アップデートコンテナヘッダがコンテナヘッダフィールド801〜806を上書きし（段階1170）、コンテナが閉じられる（段階1180）。表4〜表5(B) 表4A 表4B 表4C 表4D 表5A 表5B しかしながら、上記に示した例証的実施例は、比較的単純なグラフィカルユーザインタフェース、単純暗号化技術、満了日付を有する生存期間規制を伴う、Ja vaストリームに基づいた仮想コンテナへのアプローチを提供するが、本発明は、より単純またはより複雑なさらなる実現の幅広い列を含むことに注意すべきである。これに関連して、ユーザインタフェースはさらに複雑なGUIを備えることができ、また、グラフィックなしの単純なコマンドラインインタフェースを備えることができる。同様に、仮想コンテナもJava逐次化機構を使って、またはC++といった他の言語において実行することが可能である。さらに、生存期間規制を、文書が抽出された数、あるいは文書が変更された数の機能となるように変更することができる。さらに、生存期間規制は、特定の期間の後に、または文書のコピーや印刷を防止するために、文書を読出し専用文書に変換することができる。仮想コンテナのインターネット商業アプリケーション本発明の別の実施例によれば、仮想コンテナを採用したインターネット商業システムが得られる。この実施例によれば、インターネットを介して電子送信が可能な製品を販売したいと望む側が、製品を暗号化し、生存期間規制を設定するコンテナクリエータユーティリティを使って、その製品を仮想コンテナ内に入れる。これに関連して、販売者側は潜在的な購入者側に、一定の期間だけ製品を見せ、あるいは使用させ、このトライアル期間中に潜在的購入者が製品を購入しない場合には、期間後に製品を破棄したいと望む。製品を購入する前にサンプルで試してみたいと望む潜在的購入者は、販売者からコンテナオープナユーティリティと共にコンテナのコピーを入手する。このコンテナオープナユーティリティにより、購入者は仮想コンテナ内の製品を維持しながら製品を見たり使用したりすることができる。しかし、コンテナオープナユーティリティは、ユーザが製品（またはその一部）を印刷、コピー、変更できないように構成することが可能である。購入者がコンテナオープナを使わずに製品を見ようとすると、製品が解読できなくなる。いかなる場合においても、製品の生存期間規制が一旦無効になると（例えば、販売者が指定した期間後に）、コンテナオープナでコンテナを開くためにどんなことをしても必ず製品が破棄されてしまう。製品は、例えば文書、写真、画像、プログラムを含む、デジタルフォームで送信することが可能な電子メディアのあらゆる形式であってよいことに注意すべきである。コンテナの実施例のさらなる局面によれば、購入者は、例えば販売者にクレジットカード番号を送ることで、生存期間規制の満了前に製品を購入することができる。販売者はこの支払い情報の受信および/または確認の後に、購入者に購入キーを送信する。コンテナオープナは、この購入キー（その特定な購入者に送る特定な製品に固有のものであることが好ましい）を認識するように、また、購入キーが有効であれば購入者がコンテナから製品を抽出できるように構成されている。仮想コンテナ用のソフトウェアコンポーネントおよびエンベッドされた実行可能モジュールの使用先に説明した例証的実施例の各々において、自己破棄文書がアプリケーション特定プログラムにおいて実行されるため、自己破棄Excel^TM文書よりも自己破棄W ord^TM文書を実行するために異なるプログラムが使用された。この反復的な(再) 開発工程を避けるために、自己破棄文書または仮想コンテナシステムをソフトウェアコンポーネントとして実行することができる。ソフトウェアコンポーネントは、一般に1つの単純なサービスを提供するソフトウェアの容易に再使用可能なユニットである。コンポーネントオブジェクトモデル(C0M)は、ソフトウェアコンポーネント技術のためのMicrosoft社のスタンダードである。これは、容易な再使用のためのパッケージングソフトウェアのスタンダードを定義する。代表的なCOMコンポーネントは、メソッド（機能）のセットとして実行されるコンポーネントの機能性、そしてコンポーネントおよびその機能性に関する既述情報の2つの内容の幅広いカテゴリーを備えている。総合的に、この内容はコンポーネントのインタフェースとして参照される。この用語は「ユーザインタフェース」とは異なって使用されることに注意すべきである。ユーザインタフェースは一般に、ユーザアプリケーションの機能性と対話できるようにするための、ウィンドウ、メニュー、ボタン等のグラフィック表示のことである。しかしながら「インタフェース」は、ソフトウェアのユニットへの入力のポイント（単数または複数）（メソッドまたは機能）としてより幅広く参照される。 COMコンポーネントは、ボタン、リストといったユーザインタフェース要素を実行するために使用することができる。また、ユーザインタフェースを使わずにサービスを提供するためにも使用できる。例えば、COMコンポーネントは、サイン、コサインの計算に数学的機能を提供することができる。コンポーネントとオブジェクトの間には微妙な技術の違いがあるが、この2つは非常に類似した概念を示す。例えば、この文書では、相互変換可能という用語を業界プレスおよび技術参照文献のイディオムと同等に使用している。さらに、関連するユーザインタフェースを備えたコンポーネントを表すために制御という用語を頻繁に使用している。特に、Microsoftは、一般にユーザインタフェースを備えた特別クラスのCOMコンポーネントを表すためにアクティブX制御(ActiveXControl)という言葉を使用している。現存するアプリケーションの機能性を拡張するためにCOMコンポーネントを使用する際、コンポーネントはそのアプリケーションの文書にエンベッドされると言われる。このようなコンポーネントはよく、エンベッドされたオブジェクトと参照される。これに関連し、Word97TM、Excel^TM、Outlook98^TMの各々が、COMオブジェクトのライブラリを介したVisual Basicアプリケーションのためのサポートを含むことに注意する。エンベッドされたオブジェクト技術を使ったアプリケーションの拡張は、一般に、文書作成者のコンピュータにCOMコンポーネントがインストールされていることを必要とする。さらに、拡張された機能性を利用するためには、その文書のコピーを受取るユーザのコンピュータにもCOMコンポーネントがインストールされている必要がある。広いストロークにおいて、仮想コンテナ用のCOMコンポーネントは次のように実行することができる。 1.まず、コンポーネントにインタフェースを指定する。インタフェースはコンポーネントが提供するサービスの各々を記述する。SDEコンポーネントの場合には、サービスがCreateEnvelopeを含んでいてもよい。 2.次に、C++、Java、Visual Basicといったプログラム言語を使ってコンポーネントのサービスの各々を実行する。 3.プログラム言語の開発ツールを使ってCOMコンポーネントを作成する。 4.ユーザのワークステーションにCOMコンポーネントをインストールする。コンポーネントのサービスを呼出すために、スクリプト要求を少し実行する。ここではMicrosoft COMコンポーネントスタンダードについて説明したが、他社製のソフトウェアコンポーネントスタンダードを使用することも可能である。本発明の好ましい実施例であると現在確信されている件について説明したが、本発明の精神を逸脱しない範囲での変更および改良が可能であることが当業者にはわかるであろう。本発明の範囲内にある全てのこういった改良について請求する。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者カペル，キャリー，エス. アメリカ合衆国 10036 ニューヨーク州, ニューヨーク，ウェスト 43番ストリート 500 (72)発明者シャーマン，グレッグ，エム. アメリカ合衆国 10003 ニューヨーク州, ニューヨーク，イースト９番ストリート 115 アパートメントナンバー16ジェイ (72)発明者リース，ウィリアム. アメリカ合衆国 08902 ニュージャージー州，ノースブランズウィック，ペンシルバニアウェイ 165

Claims

【特許請求の範囲】１. 実行可能モジュールが取付けられた文書を上書きおよび/または削除するようにコンピュータに命令する、前記実行可能モジュールを作成する段階と、前記文書に前記実行可能モジュールを取付ける段階と、を有することを特徴とする自己破棄文書を作成するための方法。２. 前記実行可能モジュールが実行可能コードであることを特徴とする請求の範囲1に記載の自己破棄文書を作成するための方法。３. 前記実行可能モジュールが実行可能プログラムであることを特徴とする請求の範囲1に記載の自己破棄文書を作成するための方法。４. 前記実行可能モジュールがマクロであることを特徴とする請求の範囲1に記載の自己破棄文書を作成するための方法。５. 前記文書が開かれた際に、前記実行可能モジュールを実行する段階をさらに有することを特徴とする請求の範囲1に記載の自己破棄文書を作成するための方法。６. 自己破棄Ｅメールメッセージングシステムであって、実行可能モジュールを有し、前記実行可能モジュールが、添付先のメッセージを削除するようにコンピュータに命令するように構成されており、さらにＥメールメッセージングシステムを有し、前記Ｅメールメッセージングシステムが、Ｅメールメッセージを作成して、これを送信するように構成されており、前記Ｅメールメッセージングシステムが、送信以前に、前記実行可能モジュールを前記Ｅメールメッセージに添付する、ことを特徴とする自己破棄Ｅメールメッセージングシステム。７. 前記実行可能モジュールが実行可能コードであることを特徴とする請求の範囲6に記載のシステム。８. 前記実行可能モジュールが実行可能プログラムであることを特徴とする請求の範囲6に記載のシステム。９. 前記実行可能モジュールがマクロであることを特徴とする請求の範囲6に記載のシステム。 10. 前記実行可能モジュールが、前記メッセージを空白文字で上書きするように構成されていることを特徴とする請求の範囲6に記載のシステム。 11. 前記実行可能モジュールが、所定の状態が発生した際に、前記Ｅメールメッセージの削除を行うようにコンピュータに命令するように構成されていることを特徴とする請求の範囲6に記載のシステム。 12. 前記所定の状態が日付であることを特徴とする請求の範囲6に記載のシステム。 13. 前記実行可能モジュールが、添付先の前記Ｅメールメッセージが開かれた際に実行するように構成されていることを特徴とする請求の範囲6に記載のシステム。 14. 前記実行可能モジュールが、添付先の前記Ｅメールメッセージが開かれた際に実行を開始するように構成されており、前記実行の最中に所定の状態が発生すると、前記実行可能モジュールが前記メッセージを削除することを特徴とする請求の範囲6に記載のシステム。 15. 前記ＥメールメッセージがＥメールメッセージ添付物であることを特徴とする請求の範囲6に記載のシステム。 16. 前記実行可能モジュールが、所定の状態が発生した際に、前記Ｅメールメッセージ添付物を削除するようにコンピュータに命令するように構成されていることを特徴とする請求の範囲15に記載のシステム。 17. 前記所定の状態が印刷、コピー、Ｅメールの転送であることを特徴とする請求の範囲16に記載のシステム。 18. 前記文書が暗号化された文書であり、前記実行可能モジュールが、所定の状態が発生した際に前記文書を解読するように、また、前記所定の状態が発生しない場合には前記文書を削除するようにコンピュータに命令するように構成されていることを特徴とする請求の範囲1に記載の方法。 19. 前記メッセージが暗号化されたメッセージであり、前記実行可能モジュールが、所定の状態が発生した際に前記メッセージを解読するように、また、前記所定の状態が発生しない場合には前記メッセージを削除するようにコンピュータに命令するように構成されていることを特徴とする請求の範囲6に記載の方法。 20. デジタルオブジェクトを有する仮想コンテナを作成する方法であって、仮想コンテナを作成する段階を有し、前記仮想コンテナが、コンピュータの電子記憶媒体内の連続する位置に存在し、前記仮想コンテナがヘッダ部分とデジタルオブジェクト部分とを有し、前記仮想コンテナに挿入するためのデジタルオブジェクトを選択する段階と、暗号化されたデジタルオブジェクトを作成するために、前記デジタルオブジェクトに暗号化技術を適用する段階と、前記仮想コンテナのヘッダ部分内に、満了日を示す情報を書込む段階と、を有することを特徴とするデジタルオブジェクトを有する仮想コンテナを作成する方法。 21. 仮想コンテナから文書を抽出する方法であって、仮想コンテナのヘッダ部分から、満了日を示す情報を読出す段階を有し、前記仮想コンテナがコンピュータの電子記憶媒体内の連続する位置に存在し、前記仮想コンテナがヘッダ部分とデジタルオブジェクト部分とを有し、前記デジタルオブジェクト部分が暗号化されたデジタルオブジェクトを有し、前記電子オブジェクトが満了した際に、前記情報に基づいて決定を行う段階と、前記電子オブジェクトが満了した場合に、前記仮想コンテナの前記デジタルオブジェクト部を空白データで上書きする段階と、前記デジタルオブジェクト部分から前記デジタルオブジェクトを読出し、前記デジタルオブジェクトが満了していない場合には、前記デジタルオブジェクトに解読技術を適用する段階と、を有することを特徴とする仮想コンテナから文書を抽出する方法。 22. 仮想コンテナシステムであって、コンテナクリエータユーティリティを有し、前記コンテナクリエータユーティリティが、コンピュータの電子記憶媒体内の連続する位置に存在する仮想コンテナを作成し、前記仮想コンテナがヘッダ部分とデジタルオブジェクト部分を有し、コンテナオープナユーティリティが、ユーザからデジタルオブジェクト選択と満了日選択とを受取り、暗号化されたデジタルオブジェクトを作成し、また、前記仮想コンテナの前記デジタルオブジェクト部分に前記暗号化されたデジタルオブジェクトを書込むために、前記コンテナクリエータが選択されたデジタルオブジェクトに暗号化技術を適用し、前記コンテナクリエータが、前記仮想コンテナのヘッダ部分に満了日を示す情報を書込み、前記コンテナオープナユーティリティをさらに有し、前記コンテナオープナユーティリティが、前記仮想コンテナのヘッダ部分から満了日を示す前記情報を読出し、前記コンテナオープナが、前記電子オブジェクトが満了しているかどうかを前記情報に基づいて決定し、前記電子オブジェクトが満了している場合、前記コンテナオープナが前記仮想コンテナのデジタルオブジェクト部分を空白データで上書きし、前記コンテナオープナが、前記デジタルオブジェクトが満了していない場合、前記暗号化されたデジタルオブジェクトをデジタルオブジェクトから読出し、前記デジタルオブジェクトに解読技術を適用する、ことを特徴とする仮想コンテナシステム。 23. 仮想コンテナを作成し、仮想コンテナからデジタルオブジェクトを抽出する方法であって、前記仮想コンテナを作成する方法が、仮想コンテナを作成する段階を有し、前記仮想コンテナがコンピュータの電子記憶媒体内の連続する位置に存在し、前記仮想コンテナがヘッダ部分とデジタルオブジェクト部分とを有し、前記仮想コンテナに挿入するデジタルオブジェクトを選択する段階と、暗号化されたデジタルオブジェクトを作成するために、前記デジタルオブジェクトに暗号化技術を適用する段階と、前記デジタルオブジェクトに前記暗号化されたデジタルオブジェクトを書込む段階と、前記デジタルオブジェクトの満了日を選択する段階と、前記仮想コンテナのヘッダ部分に、満了日を示す情報を書込む段階と、を有し、さらに、前記仮想コンテナから文書を抽出する方法が、仮想コンテナのヘッダ部分から満了日を示す情報を読出す段階と、前記電子オブジェクトが満了しているかどうかを、前記情報に基づいて決定する段階と、前記電子オブジェクトが満了している場合に、前記仮想コンテナの前記デジタルオブジェクト部分を空白データで上書きする段階と、前記デジタルオペレーションが満了していない場合に、前記デジタル上書き部分からデジタル上書きを読出し、前記デジタルオブジェクトに解読技術を適用する段階と、を有することを特徴とする、仮想コンテナを作成し、仮想コンテナからデジタルオブジェクトを抽出する方法。 24. 前記仮想コンテナを作成する段階が、コンテナヘッダとデジタルオブジェクトヘッダとを作成する段階を有し、前記コンテナヘッダが、コンテナ名を含むコンテナに関する情報を有し、前記デジタルオブジェクトヘッダが、デジタルオブジェクト名を含むデジタルオブジェクトに関する情報を有することを特徴とする請求の範囲20に記載の方法。 25. 満了日を示す情報を書込む前記段階が、前記情報を前記コンテナヘッダに書込むことを特徴とする請求の範囲24に記載の方法。 26. 満了日を示す情報を書込む前記段階が、前記情報をデジタルオブジェクトヘッダに書込むことを特徴とする請求の範囲24に記載の方法。 27. 前記仮想コンテナに挿入するデジタルオブジェクトを選択する前記段階が、前記仮想コンテナに挿入する複数のデジタルオブジェクトの選択を含む段階と、暗号化技術を適用する前記段階が、複数のデジタルオブジェクトの各々に前記暗号技術を適用する段階と、前記デジタルオブジェクト部分に前記暗号化されたデジタルオブジェクトを書込む前記段階が、前記デジタルオブジェクト部分に、暗号化されたデジタルオブジェクトの各々を書込む段階と、満了日を選択する前記段階が、前記複数のデジタルオブジェクトの各々に満了日を選択する段階と、情報を書込む前記段階が、前記デジタルオブジェクトの各々の満了日を示す情報を、関連するデジタルオブジェクトヘッダに書込む段階と、を有することを特徴とする請求の範囲24に記載の方法。 28. 前記仮想コンテナを作成する段階が、コンテナヘッダとデジタルオブジェクトヘッダとを作成する前記段階を有し、前記コンテナヘッダが、コンテナ名を含む前記コンテナに関する情報を有し、前記デジタルオブジェクトヘッダが、デジタルオブジェクト名を含む前記デジタルオブジェクトに関する情報を有することを特徴とする請求の範囲23に記載の方法。 29. 満了日を示す情報を書込む前記段階が、コンテナヘッダへの前記情報の書込みを有することを特徴とする請求の範囲28に記載の方法。 30. 満了日を示す情報を書込む前記段階が、前記デジタルオブジェクトヘッダへの前記情報の書込みを有することを特徴とする請求の範囲28に記載の方法。 31. 前記仮想コンテナに挿入するデジタルオブジェクトを選択する前記段階が、前記仮想コンテナに挿入する複数のデジタルオブジェクトの選択を有する段階と、暗号化技術を適用する前記段階が、前記暗号化技術を複数のデジタルオブジェクトの各々に適用する段階と、前記暗号化されたデジタルオブジェクトを前記デジタルオブジェクト部分に書込む前記段階が、前記デジタルオペレーション部分に前記暗号化されたデジタルオブジェクトの各々を書込む段階と、満了日を選択する前記段階が、前記複数のデジタルオブジェクトの各々に満了日を選択する段階と、情報を書込む前記段階が、前記デジタルオブジェクトの各々の満了日を示す情報を、関連するデジタルオブジェクトヘッダに書込む段階と、を有することを特徴とする請求の範囲28に記載の方法。 32. 破棄可能なデジタルオブジェクトを受信者に送信する方法であって、仮想コンテナを作成する段階を有し、前記仮想コンテナが、コンピュータの電子記憶媒体内の連続する位置に存在し、前記仮想コンテナがヘッダ部分とデジタルオブジェクト部分とを有し、前記仮想コンテナに挿入するデジタルオブジェクトを選択する段階と、暗号化されたデジタルオブジェクトを作成するために、前記デジタルオペレーションに暗号化技術を適用する段階と、前記デジタルオブジェクト部分に前期暗号化されたデジタルオブジェクトを書込む段階と、前記デジタルオブジェクトに満了日を選択する段階と、前記仮想コンテナのヘッダ部分に、満了日を示す情報を書込む段階と、前記仮想コンテナとコンテナオープナユーティリティとを受信者に送信する段階とを有し、前記コンテナオープナユーティリティが、受信者によって呼出された際に、前記仮想コンテナのヘッダ部分から満了日を示す情報を読出し、前記電子オブジェクトが満了しているかどうかを前記情報に基づいて決定し、前記電子オブジェクトが満了している場合には、前記仮想コンテナのオブジェクト部分を空白データで上書きし、前記デジタルオブジェクトが満了していない場合には、前記デジタルオブジェクト部分から前記暗号化されたデジタルオブジェクトを読出し、前記デジタルオブジェクトに解読技術を提供する、ことを特徴とする破棄可能なデジタルオブジェクトを受信者に送信する方法。 33. 前記仮想コンテナがインターネットを介して送信されることを特徴とする請求の範囲32に記載の方法。 34. 前記ヘッダ部分が、コンテナヘッダとデジタルオブジェクトヘッダを有し、各デジタルオブジェクトが、前記仮想コンテナ内の関連するデジタルオブジェクトヘッダ付近に配置されていることを特徴とする請求の範囲27に記載の方法。 35. 前記ヘッダ部分が、コンテナヘッドとデジタルオブジェクトヘッドとを有し、各デジタルオブジェクトが、前記仮想コンテナ内の関連するデジタルオブジェクトヘッダ付近に配置されていることを特徴とする請求の範囲31に記載の方法。 36. 前記デジタルオブジェクトが文書であることを特徴とする請求の範囲21 に記載の方法。 37. 前記デジタルオブジェクトが文書であることを特徴とする請求の範囲22 に記載の方法。 38. 前記デジタルオブジェクトが文書であることを特徴とする請求の範囲23 に記載の方法。 39. 前記デジタルオブジェクトが文書であることを特徴とする請求の範囲32 に記載の方法。 40. 前記デジタルオブジェクトがプログラムであることを特徴とする請求の範囲21に記載の方法。 41. 前記デジタルオブジェクトがプログラムであることを特徴とする請求の範囲22に記載の方法。 42. 前記デジタルオブジェクトがプログラムであることを特徴とする請求の範囲23に記載の方法。 43. 前記デジタルオブジェクトがプログラムであることを特徴とする請求の範囲32に記載の方法。