ドキュメントデリバリシステム
【課題】 文書を安全に送付する方法とシステムを、インターネットのような通信網に提供する。
【解決手段】 文書送付アーキテクチャーが情報を配布するためのプライベートなＵＲＬ（ＰＵＲＬ）を動的に生成する。各ＰＵＲＬは、文書の受信者、送付文書、送付プロセスに固有な自由選択のパラメータを独自に確認する。受信者はＰＵＲＬで文書を検索する。送信者は送付サーバーに受信者の公開鍵の検索を命ずる。送付サーバーは保証元を動的に照会し、公開鍵を検索する。公開鍵が送付サーバーから送信者に送られる。送信者はシークレット鍵で文書を暗号化後、公開鍵でシークレット鍵を暗号化する。暗号化された文書とシークレット鍵を送付サーバーにアップロードし、受信者に送信する。受信者は公開鍵と関連する復号鍵でシークレット鍵を解読し、シークレット鍵で文書を解読する。
【解決手段】 文書送付アーキテクチャーが情報を配布するためのプライベートなＵＲＬ（ＰＵＲＬ）を動的に生成する。各ＰＵＲＬは、文書の受信者、送付文書、送付プロセスに固有な自由選択のパラメータを独自に確認する。受信者はＰＵＲＬで文書を検索する。送信者は送付サーバーに受信者の公開鍵の検索を命ずる。送付サーバーは保証元を動的に照会し、公開鍵を検索する。公開鍵が送付サーバーから送信者に送られる。送信者はシークレット鍵で文書を暗号化後、公開鍵でシークレット鍵を暗号化する。暗号化された文書とシークレット鍵を送付サーバーにアップロードし、受信者に送信する。受信者は公開鍵と関連する復号鍵でシークレット鍵を解読し、シークレット鍵で文書を解読する。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明は、コンピューターネットワーク分野に関する。より詳しくは、インターネットでユーザーに電子文書を送付する技術に関する。本発明は更に、インターネットの様に広範なネットワークでの安全な文書送信を提供するための方法とシステムに関する。
【０００２】
【技術的背景】例えばインターネットや他のオンライン発信源から提供されるコンピューター化された情報源の発達は、電子的に入手可能な情報を増大させた。現在では、インターネット加入ユーザーは、手動操作でインターネット中を駆けめぐり、関心のあったりなかったりする個所を訪れる。このインターネットシステムに固有の問題は、入手可能な情報が「プル」型基盤を通して配布されることであり、その場合、情報を受信したいユーザーは手動で関心のある部分を探すかファインダーアプリケーションを使うかして、適切な情報を探しダウンロードせねばならない。情報や文書を発行・配布したいユーザーにしてみれば、配布したい情報を持っている個人にしろ大きな団体にしろ、現行の「プル」型システムは、「プッシュ」方式で、受信者個人或いは受信者のグループへ自由に送信・配布することを許さない。
【０００３】ファクシミリ技術は、単純な文書の配布に広く現在使われているが、低品質の印刷文書、高価でかさばる紙コピー（特に受信者が紙コピーを持つのを気にしない場合）、内容の欠落（例えば、テキストやグラフは編集も手を加えることもできない）、特に長い或いは複雑な文書を送信するのに時間が掛かる等多くの欠点がある。電子メール（Ｅ−メール）は、電子メッセージをコンピューターユーザーから他の人へ送る手段を提供する。Ｅ−メールには、利便性、フォーマット、後の検索のためのメッセージの保存の利点がある。それなりにＥ−メールは受け入れられ、基本的な通信として広く使われている。Ｅ−メールはＡＳＣＩＩベースのフォーマットが代表的であるが、長い或いはフォーマット化された文書の通信をひどく制限することが判明している。更にＥ−メールは、複雑な文書、例えば、レポート、記事、ページレイアウト格子を含む広告と芸術、ポストスクリプト書式の対象物、トラッキングとカーニングのある複数フォント、グラフ、組み込まれた表、スプレッドシート、その他の複雑な情報の配布に当たって選ぶ手段ではない。Ｅ−メールシステムの中には、ＡＳＣＩＩベースのＥ−メールメッセージをダウンロードされる関連ファイルに追加する手段を提供するものがある。関連ファイルの追加が可能なシステムの殆どは、一人のユーザーから同僚ないし友人へ未保護ファイルの送信を可能とはするが、複数の受信者への制御された自動配布のためではなく、高度なアカウンティング、ビリング、ないしそうした特徴を備えたもの（例えば、領収通知書）を提供しない。Ｅ−メールゲートウエイでは、アタッチメントの応用性を制限されるし、機密保護と受信表示ないし受信通知の問題を未解決である。
【０００４】Ｃ．ボードインの米国特許番号５、４０６、５５７（１９９５年４月１１日）「企業間電子メールハブ」は、共有コアと複数の入出力モジュールから成るコンピューターハブを持つ企業間通信センターを開示している。入力モジュールは、第一エンドユーザーに接続され、第一エンドユーザーが送信したメッセージを汎用フォーマットに変換する。ハブコアはメッセージを待ち行列に入れ、行先ユーザーのフォーマットに変換すべく出力モジュールへ送る。開示されたハブは、単純なＥ−メールメッセージの中継技術を開示している一方で、Ｅ−メールメッセージフォーマットを変換する様設計されているため、本来のテキストベースのファイルの完全性を失っている。開示された先行技術システムと方法論はこのように、文書を送付する幾つかの方法を提供しているが、本来の電子ファイルの完全性を維持しつつプッシュ型で作動する経済的かつ迅速な文書送付システムを提供できていない。こうした電子文書送付システムが開発されれば、大きな技術進歩となろう。加えて、制御されかつ経済的で説明可能なやり方で多くの受信者に電子ポータブル高内容品質の文書を配布できる能力は、更なる技術進歩を構成するであろう。
【０００５】インターネットは、通信にますます使用されている。送信者は今やインターネットで、プラットフォーム、基本ソフトウェア、Ｅ−メールシステムとは無関係に、特定の受信者に文書を送ることができる。送信者のコンピューターのインターネットへの接続は、直接でもイントラネットのサーバー経由でもよい。こうした通信は、たとえ受信側がコンピューターでなく、インターネットに接続されたファックス機械ないしプリンターであっても可能である。インターネット通信の増加により、インターネットで送信される情報の保護を保証する機密保護システムの発達を必要とするに至った。暗号化は、情報への一方的なアクセスを防ぐため情報にスクランブルをかけるのに使用される基本技術である。よく知られている一つの暗号化方法はシークレットキー暗号化であり、時にプライベートキー暗号化ないし対称キー暗号方式とよばれる。シークレットキー暗号化で使われる技術は、一方的なアクセスを防ぐために独自キーを使って情報にスクランブルをかける。この独自キーは、情報を復元する際必要となる。図１は、先行技術に依るシークレットキー暗号化を示す図である。
【０００６】文書１０１０は、シークレットキー１０１４使って１０１２にスクランブルされる。シークレットキーは、スキームの公認ユーザーにのみ入手可能な暗号化スキームである。暗号化ソフトウエアは、ユーザーのコンピューター上或いは離れた位置にあってもよい。文書はこうして、本来の場所、ないし別のコンピューターへの送信時に例えばイントラネットサーバーで暗号化されてもよい。結果的に暗号化された文書１０１６が、受信者に送信される。シークレットキー１０１４を使って１０１８のスクランブルを解除し、本来の文書１０１０を再生する。暗号化された文書に、シークレットキーなしではアクセスできない。解読ソフトウエアは、受信者のコンピューター、離れた位置のどちらにあってもよい。
【０００７】シークレットキー暗号化に関する潜在的問題の一つは、シークレットキーの安全な配布である。シークレットキーが安全でないチャンネルで送信される場合、機密保護の完全性が危険に晒される。多くの実際的なアプリケーションの場合、電話ないしファックスはシークレットキー送付に十分な機密保護を提供するが、文書は、カリフォルニア州レッドウッド市タンブルウイードのソフトウエアコーポレイションから入手可能なポスタといったメールスキームを使いインターネットで送付することができる。しかし事例の中には、キー配布をより安全かつより便利に行う方法をユーザーが要求している。別の暗号化方法は、パブリックキー暗号化方法である。パブリックキー暗号化方法では、送信者と受信者がそれぞれパブリックキー及びプライベートキーと呼ばれる一対のキーを所有する。キーペアーの所有者はパブリックキーを発行し、プライベートキーを秘密にしておく。
【０００８】送信者は、対象受信者が発行したパブリックキーを使い、情報を暗号化する。情報の解読には、受信者のプライベートキーを使う。このように、パブリックキー暗号化方式を使えば、プライベートキーを配布する必要がない。図２は、先行技術によるパブリックキー暗号化方式を示す図である。文書１０２０は、パブリックキー１０２４を使って１０２２にスクランブルされる。結果的に暗号化された文書１０２６は、次に受信者に送信される。プライベートキー１０３０を使ってスクランブルを解除し、本来の文書１０２０を再生する。パブリックキー暗号化に使われるキーは、非常に大きな数字である。パブリックキー暗号化方法は、暗号化と解読を実行するためのキー数字間に難解な数理的関係を利用する。結果的に、発行されたプライベートキーからプライベートキーを難なく引出すことはできない。
【０００９】文書が送信中に変えられていないこと、ないし、文書の送受信者を確認することがしばしば役に立つ。シークレット・パプブリックキー技術は、こうした確認を可能とする。しかし、パブリックキー暗号化アルゴリズムは一般に難解で、時間が掛かり過ぎ実際の使用がしばしばできない。シークレットキー暗号化方法はずっと早いが、安全にキーを送信することに関し欠点がある。パブリックキー／プライベートキー暗号化システムは、ガネサン・ヤクシャの米国特許番号５、５３５、２７６（１９９６年７月９日）「分離プライベートキー非対称暗号方式を使用による通信保護のための改良されたシステムと方法」に述べられている。しかし、ガネサンの暗号化スキームの場合、一時キーの生成に複雑な方法を使っており、複数の異なるユーザーに手動でパブリックキーを要求させる。
【００１０】鳥居の米国特許番号５、３１３、５２１（１９９９１年５月１７日）「ＬＡＮにおけるファイル転送のためのキー配布プロトコル」は、サーバーに対し端末を認証するためにキー配布センターを使う。パストルの米国特許番号４、８５３、９６１（１９８９年８月１日）「信頼性のある文書認証システム」では、解読キーを含む文書認証システムが述べられている。コウドリー他の米国特許番号５、５０９、０７４（１９９６年４月１６日）「電子発行された資料を暗号作成プロトコルを使用して保護する方法」が教示する文書保護システムは、各文書要求を認証するためサーバー同志間の機密保護アクセス操作を含んでいる。しかし、これら先行技術のスキームは全て、証明を認証するのにユーザーが介在せねばならない。
【００１１】別の暗号化方法である電子封筒は、シークレットキーとパブリックキー暗号化の欠点がない。電子封筒を使用し、送信者はシークレットキーで文書を暗号化する。その後シークレットキーをパブリックキーで暗号化する。文書の受信者は、自分のプライベートキーでシークレットキーを解読し、シークレットキーで文書を解読する。現在、パブリックキーの発行のためにレジストリを利用できる。こうしたレジストリは、特定のパブリックキーが特別の存在に属していることを証明できる。例えば、証明元は、それらの特定のパブリックキーに存在を接続するのに使われるデジタル証明を発行・維持する。送信者はレジストリを照会し、要求されたパブリックキー情報を受け取らねばならない。この時間の掛かるプロセスは効率が悪く、特に送信者が多数の文書を異なる受信者に送信せねばならぬ時が特に効率が悪い。
【００１２】暗号化を目的として広範なネットワークでパブリックキーを自動的かつ動的に検索するためのシステムと方法を供給することは有利である。そうしたシステムと方法でサーバーを使って証明を検索し、ユーザーの介在を必要としなければ更に有利である。このシステムと方法で、サーバーが使用者にパブリックキーを戻すまで文書をサーバーに送信しないなら更に一つの利点となる。
【００１３】
【発明の概要】電子文書送付システムとその使用の方法を提供する。文書送付アーキテクチャが、情報を配布するためのプライベートなユニフォームリソースロケータ（ＵＲＬ）を動的に生成する。各々のプライベートなＵＲＬ（“ＰＵＲＬ”）は、独自に、文書の対象受信者、送付される文書或いは文書セット、（随意選択で）送付プロセスに特有な他のパラメーターを定める。文書の対象受信者はＰＵＲＬを使って文書を検索する。文書検索の際、サーバーは、ＰＵＲＬに含まれる属性に基いて検索の挙動をカスタマイズし、同様にデータベースにある検索に関連するログ情報もカスタマイズする。こうしたＰＵＲＬの構造と使用により、安全な文書送付と文書受信の追跡が可能となる。
【００１４】本発明は、例えばインターネットの様な広範なネットワークでの安全な文書送付のための方法とシステムを提供する。文書はデリバリーサーバーを経て送信者から受信者に送付される。本発明の好適実施例では、送信者がデリバリーサーバーに、対象受信者のパブリックキー（証明）を検索するよう命じる。デリバリーサーバーは保証元を動的に問い合わせ、パブリックキーを検索する。パブリックキーがデリバリーサーバーから送信者に送信される。送信者は、シークレットキーを使い文書を暗号化する。その後シークレットキーをパブリックキーで暗号化する。暗号化された文書と暗号化されたシークレットキーの両方をデリバリーサーバーにアップロードし、対象受信者に送信する。次に、対象受信者はパブリックキーと関連したプライベートキーで、シークレットキーを解読し、シークレットキーで文書を解読する。
【００１５】本発明の代替の同程度好適実施例において、送信者はパブリックキーを使い、文書を暗号化する。その後、暗号化された文書は対象受信者に送信され、パブリックキーに関連するプライベートキーで解読される。更に別の実施例では、サーバーが暗号化のため文書をデリバリーサーバーに送信する。デリバリーサーバーが、リアルタイムで証明元に問い合わせ、パブリックキーを検索する。デリバリーサーバーは、シークレットキーを使って文書を暗号化後、パブリックキーでシークレットキーを暗号化する。その後デリバリーサーバーは、暗号化された文書と暗号化されたシークレットキーを対象受信者に送信する。デリバリーサーバーの照会が失敗した場合（所定のユーザーの証明が入手できない）、デリバリーサーバーは対象受信者のために新しいパブリックキーを動的に生成する。その後、この新たな証明が文書暗号化に使われる。
【００１６】
【実施例】バイナリーファイルデリバリーシステム１０は、会社、出版社、個人が文書を電子的に配布できるようにする。重要なのは、バイナリーファイルデリバリーシステム１０は、既存のウエブを基にした文書発行技術と異なり、指示どうりかつ安全な文書配布を可能にする。現在のウエブは、文書の顧客がサーバーから文書を見つけ検索せねばならぬプル発行型の環境として特徴付けられる。これとは対照的に、プッシュ発行型は、文書の作成者が顧客宛に文書を送付するのを可能とする。ファクシミリ（ファックス）、郵便サービス、電子メール（Ｅ−メール）は、全てプッシュ発行の例である。図３は、一台のバイナリーファイルサーバー１２を使用するバイナリーファイルデリバリーシステム１０を示すブロック図である。バイナリーファイルデリバリーシステム１０は、ユーザーが文書をプッシュするのを可能にし、文書作成者が文書の行先を指示するのを可能とする。バイナリーファイルデリバリーシステム１０がプッシュ発行を達成する一つの方法は、ネットワークで情報をプルするために通常実行されるＨＴＴＰを、ＳＭＴＰ（テキストのみをサポート）に結び合せる方法である。バイナリーファイルデリバリーサーバー１０は更に、指示された文書送付の様々なアプリケーションを容易にするため、サービスのホスト役を果たす。或るレベルでバイナリーファイルデリバリーシステム１０は、新世代のファクシミリ技術として特徴付けが可能で、電話回線の代わってネットワークを利用し更に既存のファックス様式より非常に優れた新しい文書表示のためのサポートを導入する。別のレベルで、バイナリーファイルデリバリーシステム１０は、膨大な量の文書と取引を支援できる汎用文書デリバリーサーバーである。あらゆるケースでバイナリーファイルデリバリーサーバー１０は、文書送付に関する完全で力強い解決策を提供する。
【００１７】バイナリーファイルデリバリーサーバー１０は、或るエンドポイントから一つ以上のエンドポイントへバイナリーファイルのセットを送信するのに使われる。エンドポイントは、インターネットアクセスする受信者２２が代表的であるが、ファクシミリ機械１７２又はプリンター１７８といった別のものでもよい（図１６R>６、１７）。バイナリーファイルは、信頼性があり、説明可能で、かつ追跡可能な方法で送付される。バイナリーファイルデリバリーシステム１０が指示されたファイルに提供する機密保護のレベルは、Ｅ−メール同等からファクシミリないし一般の郵便よりは優れたレベルまで様々である。本システムは、ビリングアカウントの貸方・借方を始めとするユーザーアカウント管理を提供する。システムは複数のバイナリーファイルデリバリーサーバー１２の間で協力動作でき、サーバーは他の許可により制御されてもされなくてもよい。図４は、インターネットと通信する二台のバイナリーファイルサーバー１２ａ、１２ｎを使うバイナリーファイルデリバリーシステムを示す。
【００１８】バイナリーファイルデリバリーサーバー１２は三種の基本モードで作動し、これらモードは、送信者１６がアカウント１３２自体を設定しビリングに従属するパブリックモード、送信者１６が管理者に制御されビリングが徴収問題というよりもより内部アカウント問題であるプライベートモード、受信者２２は多いが送信者１６の少ない発行モードの三種である。バイナリーファイルデリバリーサーバー１２は、独立した機能コンポーネントから成り、必ずしもプロセスないし共有ライブラリではない。図６に概略で示されているバイナリーファイルサーバー１２は、ストア４２と呼ばれるインテリジェント記憶コンパートメントを含み、本装置はストアクライアント４４と呼ばれる一連のクライアント４４ａ−４４ｎで増大され、ストアクライアント４４はストア方法を使いストアイベントに従うが、他のクライアント４４と対話したり識別しあうことがない。アカウントマネージャ４６コンポーネントは、送信者１６に関する情報を保持する共有サービスである。受信アプリケーションの場合の、受信者２２に関する情報が更に設計上組み込まれている（Ｅ−メール通知とは対照的である）。
【００１９】クライアント／サーバーの汎用アーキテクチャは、よりパイプライン化された構造よりも、より優れた拡張性がある。しかも、本アーキテクチャによりストアクライアント４４は互いから切り離されるので、幾つかのタスクが相互作用し他がより背後志向であるような状況で有効である。
［ストア］ ストア４２は、一連のストア項目４８を含む。図５に示す様に、ストア項目４８は、バイナリーファイルトリー３４と記述子３６を含み、記述子はストア定義された属性とクライアント定義された属性の一連のセットである。バイナリーファイルトリー３４は、ストア定義された属性の部分と見なすことができる。ファイル記憶システムは次に述べる機能性を提供する。
【００２０】１）ストア項目４８の永久記憶（例えば、ストア項目４８に含まれるバイナリーファイルツリー３４がディスクに書き込まれる。）
２）ストア定義された属性とクライアント定義された属性からなる記述子３６へのクライアント読込／書込アクセス（例えば、クライアント４４は、ストア項目４８の満了日を書き込むことができる。）
３）ストアイベント６７のクライアント通知（例えば、クライアント４４は、新しいストア項目４８の作成イベント６８の通知を受けられる。）
４）ストア定義された属性による内部管理（例えば、ストア項目満了日は、イベントを生成する。）
ストア４２は、ストア項目４８へのアクセスを提供し、ストアイベント６７を作成し、ストア項目４８はストア定義された属性、例えばＩＤ、作成データ、ファイルカウント、ファイルネーム、ファイルデータを所有し、ストアイベント６７は、クライアント４４に従うはずである。ストアイベント６７は、ストア項目４８の作成６８、削除６９、ないし変更修正７０を含んでもよい。イベント６７はアーキテクチャにおける決定的役割を果たすが、何故なら、クライアント４４が自分の仕事を他者に関する非常に限られた情報とどのように同期化させるかを定義しているからである。
【００２１】［ストアクライアント］ ストアクライアント４４は非常に多様で、特定のクライアントについては更に詳述する。本構成の場合、ストアクライアント４４はある種のコンポーネントであって、ストア項目４８での役に立つタスクを実行するために、ストア方法の幾つかを使用するかないしストアイベント６７の幾つかに従う。
［アカウントマネージャー］ アカウントマネージャー４６は、ユーザーとビリングアカウントへの読み込み／書き込みアクセスを提供し、クライアント４４ないしシステム１０の他のコンポーネントが使用する。ストア４２はアカウントを使いも識別もしない。
［他のコンポーネント］ ストアクライアント４４とストア４２自身が使う他のコンポーネントは、本システムのアーキテクチャ内で実行される。例えば、相互サーバー通信、ログ管理、及び他の管理サービスでありこれらについて以下に述べる。
【００２２】図７は、バイナリーファイルサーバー４２の一つの実施例のアーキテクチャの例で、サーバー機能の実行に使われるクライアント４４モジュール（５２−６６）を含んでいる。インターネット送信５２で、ストア項目４８を作成し、属性を書き込む。インターネット受信５４で、既存のストア項目４８を開き、それら属性を変更できる。ファックスゲートウエイ５６で、ストア４２が生成した作成イベント６８に従い、関連したストア項目４８を処理し、次にストア４２からそれらを削除する。フォワーダー５８は、ストア４２が生成した作成イベント６８に従い、次に新たなストア項目４８の属性を調査し、フォワーディングが必要か否か決定する。アーカイバー６０は削除イベントに従い、削除が行われる前に第二プライベート記憶にストア項目４８をコピーする。フォーマットトランスレーター６２は作成に従い、属性を調査し、トランスレーションが必要ならば、読込、処理、ストア項目４８のファイルに書き戻しを行う。ウエブパブリシャー６４は作成イベント６８に従い、ストア項目属性がウエブパブリシングを記したかをチェックし、もし記していれば、必要と見なし属性を読み込む。ピックアップ通知６６は作成イベント６８に従い、受信者２２に通知する。
【００２３】［インターネットベースのユーザーのための機密保護問題］ バイナリーファイルデリバリーシステム１０が専用の機密保護解決策を支援する柔軟性を提供する一方、現在の産業ベースの機密保護解決策を難なく支援しており、それらとして以下のものを挙げることができる。
ａ）安全なサーバー間接続とサーバー認証（ＳＳＬ２．０で利用でき、サーバー（ＨＴＴＰ）に組み込まれている）
ｂ）サーバー間の機密保護（ＳＳＬＸ上で）
ｃ）支援エンドポイントプライベートキー（ユーザーは、自分のチャンネルを使ってプライベートキーを交換せねばならない）
ｄ）暗号化ＡＰＩないし標準ユーザーパブリックキーを使いエンドポイントパブリックキーを支援する。本システムは更に、ユーザーがＢＦＤ使用のみに限ってパブリックキーを生成してそのキーでユーザーアカウント情報を更新するのを助けることもでき、送信者はパブリックキーを得るために受信者と直接通信せずに済む。
【００２４】ｅ）ＳＳＬとＭＳ ＰＣＴを有するサーバーによるクライアント認証（エンドユーザーは自身の証明を得られ、サーバーにより認証してもらえる）
バイナリーファイルデリバリーサーバー１２の重要な面は、複数の要求を同時に処理し、殆どの要求に対する応答時間を最小にすることである。それ故、同期化の問題は正確さとシステム性能の両者にとり重要である。性能の向上には、同期化させたデータアクセスを最小にし、可能な時にはいつでも非同期処理に先送りし、多重タスキングとプラットフォームのためのプロセス内通信（ＩＰＣ）を用いる。サーバー１２の一実施例では、一プロセス内で低オーバーヘッド多重タスキングを提供するスレッディングを大きな拠り所とし、又多重プロセッサー性能を利用可能な時に導入する。本実施例のＩＰＣでは、メールスロットないし遠隔手続き呼び出し（ＲＰＣ）に加えて、ネームドパイプを使う。
【００２５】図７は、バイナリーファイルデリバリーサーバー１２のアーキテクチャ内の特定のコンポーネントのブロック図を示す。ユーザーセッション７２が取り扱うセッションは、送信セッション、受信セッション（ユーザーがＢＦＤデスクトップアプリケーション１９２、１９８を使う時に実行される）、ＨＴＭＬ受信セッション（ユーザーがＢＦＤデスクトップ１６４使う時とは対照的に、ＨＴＭＬブラウザーを通して実行される（ＢＦＤデスクトップセッションはＨＴＭＬを通して実行されてもよいことに留意））、保守セッション（アカウントセットアップと保守セッションを実行する（例えば、通知ダウンロード、アカウントセッティング変更修正（パブリックサーバーのエンドユーザーと対照的な管理者によるコンソールサービスと混同しない様に））、ＨＴＭＬ保守セッション（ＨＴＭＬブラウザを通してアカウントセットアップと保守を実行する）である。
【００２６】デリバリーコンポーネント７４は、通知やフォワーディングを含んだ送付という背後作業を実行する。コンソール７６は管理セッションを実行し、このセッションは専用のユーザーインターフェースの代わりにＨＴＭＬインターフェースを通してなされる。コンソール７６は、アカウント、ロギング、パフォーマンス、パラメーターセッティングを含む全てのサーバー属性をブラウズし変更するためのユーザーインターフェースを提供する。
［共有コンポーネント］ 共有コンポーネントは、ストア４２、ストアクライアント４４のいずれで使用されてもよく、ないしそれ自体で作動してもよい。共有コンポーネントがストアイベント６７に従わない間は、必要に応じて効率、例えばコネクター受信のために、ストア方法を使用できる。共有コンポーネントには以下が含まれる。
【００２７】１）アカウントマネージャー。これは、全てのローカルアカウント情報を維持し、ビリングアカウント及び遠隔アカウント情報を始めとするローカルアカウントへの独自のアクセスインターフェースを提供する。
２）サーバー間の全通信を取り扱うサーバーコネクター８０。
３）出されたメールの送受信を取り扱うメールゲートウエイ８４。
４）ロガー８６。型毎に分類された異なるログへの読込／書込アクセスを管理する。最も重要なログは、ストア項目４８で何が起きたかを追跡する送信／受信トランザクションログである。
５）オペレーティングシステムアクセサー８２。これは、オペレーティングシステムが行うファイル入出力（Ｉ／Ｏ）、プロセス管理（同期化、ロッキング、スレッド、プロセス）、ＩＰＣ（ＲＰＣ、共有記憶、共有待ち行列、パイプ）、ネットワークアクセス（ＴＣＰ／ＩＰソケット、ＨＴＴＰサーバーインターフェーシング、ＰＯＰ／ＳＭＴＰインターフェーシング）用にプラットフォーム独立型インターフェースを提供する。特定の部分が必要に応じて実行される。
【００２８】［サーバーアプリケーション］ サーバーアプリケーション８８は、全てのバイナリーファイルデリバリーサーバー１２を構成パラメーターに従って立ち上げ又停止するのに使われる。更に、アカウントマネージャー（４６ないし７８）ないしロガー８６がカバーしないサーバーの管理面の役割、例えばパフォーマンスプロファイリング、使用法情報、サーバーパラメーター／構成も果たす。図１０は、ストア４２のアーキテクチャを示すブロック図である。ストアマネージャー９２は、包括的状態を維持し、ストア４２へのアクセスを同期化し、ハウスキーピング機能を提供するのに使われる。ストア項目マネージャー９４は、ストア項目４８の状態、ロック、キャッシュ機構を維持するために使われる。ストアイベントマネージャー９６は、リスナーリスト及びイベントフィルターを維持し、同様にイベントフィルターとイベント優先順位に従ってイベントをディスパッチするのにも使わる。
【００２９】図１１は、インターネットクライアントをセッション、トランザクション、トランスポートを含む三層にユーザーセッションがどう組織化するかを示す。セッションマネージャー１０２は、現在作動中の全セッション状態を維持し、セッションに関連したハウスキーピングを実行する。１０２は、ストア４２とアカウントマネージャー４６の使いトランザクションマネージャー１０８から届くトランザクションを処理する。トランザクションマネージャー１０８は、トランスポートマネージャー１１４、１１８から未処理のデータを受信し、一つ以上のＢＦＤトランザクションインタープリター１１０ないしＨＴＭＬトランザクションインタープリター１１２を使ってバリデーションとプリプロセシングを実行する。トランザクションマネージャー１０８は、次にデータを適切なＢＦＤセッションマネージャー１０４ないしＨＴＭＬセッションマネージャー１０６に提出し、回答を待ち、次に回答を適切なトランスポートマネージャー１１４ないし１１８に戻す。
【００３０】図１２は、送信セッションがストア項目４８を一旦作成し、ないし別のサーバー１２ａ−ｎがストア項目４８を送っている時のデリバリーの非対話タスク１２０を示す。デリバリーマネージャー１２２は、関連するストアイベントに従い、フォワーディング決定を下し、作業をノーティファイアー６６とフォワーダー５８に調整する。サーバーディレクトリは、Ｅ−メールドメインとサーバードメインの間の関連付けを追跡し続ける。ノーティファイアー６６は、Ｅ−メール通知２０を受信者２２に渡すのに使われる。フォワーダー５８は、サーバーコネクター８０を使ってストア項目４８を他のサーバー１２ａ−ｎへ送るのに使われる。全ての通知が受信されるとは限らないので、Ｅ−メールスキャナーで「返却された」Ｅ−メールのサーバーメールアカウントをチェックし、それを失敗トランザクションとする。
【００３１】図１３は、アカウントマネージャーのアーキテクチャ１３０の詳細を示す。アカウントマネージャー７８は、ローカルサーバー１２のためにユーザーアカウント状態１３２を維持し、ローカルアカウント１３２のためにビリングアカウント状態１３４を保持し、ローカルアカウント１３２を照会し、リモートアカウント１３６のディレクトリーを維持するのに使われる。リモートアカウントディレクトリー１３６の第一目的は、Ｅ−メールアドレスをＢＦＤアカウントないし非ＢＦＤアカウントと関連付けることである。図１４は、ロガーアーキテクチャの詳細を示す。図１５は、サーバーコネクターアーキテクチャの詳細を示す。
［システムオペレーション］ 次の例は、電子情報を送信者１６から受信者２２に配布するのにバイナリーファイルデリバリーシステム１０がどう使われているかを示す。仮の発行者、カリフォルニア州レッドウッド市のサムは、日本の東京にいる友人ロブに文書を送りたい。以下に進行するイベントで、制御された形でこれがどのように達せられるかを示す。
【００３２】［サムはカリフォルニア州サンタクララのローカルサーバーに接続する。］サムのＢＦＤデスクトップが、彼のユーザーアカウントがあるサンタクララのローカルサーバー１２ａに接続される。セッションマネージャー１０２は、ユーザー１６（サム）を有効にする様アカウントマネージャー７８に照会する。セッションマネージャー１０２は次にユーザー１６に対し送信セッション状態を作る。［サムの送信セッション］ サムのＢＦＤデスクトップがトランザクション詳細、例えばファイル番号、ファイルサイズ、対象受信者を送信する。セッションマネージャー１０２は、このデータをセッション状態に添える。次にセッションマネージャー１０２は、メモリーにあるストア項目４８記述子３６を作成し、ストア４２にディスクスペースを確保し、ストア項目ＩＤも又同様である。その後アップロードが始まる。セッションマネージャー１０２は、データを非同期Ｉ／Ｏで直接ファイルに受け渡しする。
【００３３】サムの全ファイルのアップロード１８が完了した時、セッションマネージャー１０２は、ストア項目記述子３６をディスクに対し非同期で更新し、次にストア項目４８をストア４２に非同期で挿入する。セッションマネージャー１０２は、サムのアップロードに認知の旨回答し、トランザクションに関する情報を提供する。こうして本セッションが終了する。
［サンタクララストアにて］ ストア項目４８の挿入は、非同期にストア４２によりロガー８６にログインされる。ストア４２は、次に、登録されたイベントハンドラーフィルターに反して、ストア項目記述子３６を作動する。整合毎に、ストア４２がイベントと受信者（ロブ）をイベント待ち行列に挿入する。こうしてスレッドは終わる。
【００３４】イベントディスパッチスレッドはイベントをプルし、そのイベントを非同期で受信者にディスパッチするが、ディスパッチの速度はシステムのチューニングパラメーターに依存する。
［サンタクララデリバリーが通知される。］ デリバリー７４は、関連するイベントを通知され、ストア項目４８のロックに応じるスレッドをストア４２との同期トランザクションを経て開始させる。一旦ロックが保全されると、スレッドがストア項目記述子３６を読み込み、記述子をどう扱うか決めるため、デリバリーマネージャー７４が分析する。受信者２２は別のＢＦＤ１２ｎの置かれている日本ドメインにいるとわかる。デリバリーマネージャー７４がサーバーディレクトリ１２４に照会することにより、これがわかる。マネージャーが次にストア項目４８を送ることを決める。フォワードマネージャー８０は、コネクター８０が東京に送るように非同期で依頼する。そうしてデリバリー内のスレッドが終了する。デリバリーがサーバープロトコルを識別してないことに留意されたい。
【００３５】サンタクララコネクター８０は、東京コネクター８０に送信を始める。デリバリー要求を扱うスレッドは、最終的にコネクター８０で始動する。コネクターはホストを知っており又ストア項目４８のロックを所有している。東京サーバー１２ｎとの接続を開始する。接続できない場合はしばらくの間休止する。最終的に接続が開き、コネクター８０がプロトコルインタープリターに入り、最終的にストア項目記述子３６と関連のバイナリーデータファイル３４とを転送する。その後接続を閉じ、東京サーバー１２ｎへの転送成功をロガー８６に記録する。送られた旨記録後、次にコネクター８０はストア４２中にあるストア項目４８のロックを開放する。ロックの解除時、ストア４２は、イベントフィルターリストに反してストア項目記述子３６を作動し、局地で扱われているイベントフィルターを見つける。首尾よく送られたストア項目４８は、１だけ減った参照番号を生じさせる。本例の場合、受信者は一人だけなので、カウント番号が０になることを意味する。それ故、ストア４２はストア項目４８を削除リストに移すことができる。ストア４２のハウスキーピングスレッドが、ある時点でストア項目４８を取り除く。
【００３６】東京コネクターレシーバー８０のスレッドが、接続を扱うため開始される。ひとたびプロトコルインタープリターがフォワードと理解すると、ストア４２にストア項目ＩＤ３６と各自に付された記憶スペースとを要求する。実際のストア項目記述子３６とファイルは、ディスクがデータを受信している最中に、ディスクに書き込まれてしまう。ひとたび接続が完了すると、ストア項目４８は、東京のバイナリーファイルデリバリーサーバー１２ｎのストア４２に非同期で挿入される。
［東京デリバリー装置始動］ 挿入時に東京のストア４２は、デリバリーのスレッドが取り扱おうとするイベントを生成する。新たな項目の挿入もロガー８６に記録する。デリバリー７４のマネージャー１０２は、これが送られたこととこのサーバー１２ｎから受信されるであろうことを了解する。
【００３７】サーバー１２ｎは、ロブのＥ−メールアドレスに関連したアカウントがあるか否かをアカウントマネージャー７８に照会する。ロブのＥ−メールに関連するアカウントがなければ、ストア項目ＩＤ３６を示すＵＲＬ付のＥ−メールがロブに送られる。又、ロブの通知を受けたことをコネクター８０がサンタクララサーバー１２ａに知らせるという非同期の要求を待ち行列に入れる。ロブがアカウントをここに持っていれば、デリバリーが、未決定のデリバリーを告げる様にアカウントマネージャー７８で非同期の更新要求を出す。この場合、シナリオはまだ続く。
［ロブが東京サーバーに接続し、新しい文書をチェックする。］ ロブが受信セッションを開く時、セッションマネージャー１０２はロブのアカウントの有効性を同期的にチェックし、その過程でセッション状態を更新し、アカウントに未決定受信の合図があることを記憶する。ロブのＢＦＤデスクトップは結果的に、文書が受信されるべきだと要求する。セッション状態は答を得て、はいと言う。
【００３８】ロブのデスクトップ１７０が受信を要求すると、セッションマネージャー１０２が、ストア４２に関連するストア項目４８のロックを同期的に要求する。ひとたび承諾されると、データの最初の部分を送信することで回答できる。ひとたび文書がダウンロードされると、受信の成功をロガー８６に非同期的に記録する。こうして、最終的送付をサンタクララサーバー１２ａに通知する様、コネクター８０で非同期の要求を出す。東京での受信セッションでは、セッションマネージャー１０２がロックを解除し、ストア４２に非同期削除要求を出す。ロブの受信セッションは、この時終了する。サンタクララのコネクター８０がプロトコルインタープリターを作動させると、通知をロガー８６に待ち行列に入れるべき旨インタープリタが告げる。
【００３９】［サムが状態をチェックする。］ サムは、保守セッションに続く受信セッションを行うために接続する。保守セッション７２は、送信された文書の状態をチェックする要求を受信する。保守セッション７２は、送信時にサムのデスクトップに伝えられたストア項目ＩＤ３６を使いロガー８６に同期的に照会を出す。照会はマッチング記録のリストを戻し、それらは処理されデスクトップに戻され、こうしてユーザーインターフェース１６を更新できる。
［ポータブル文書デリバリーシステム］ 電子ポータブル文書はますます普及している。これらファイルは、本来の外観と感触を失うことなしに異なるプラットフォームに配布できる。アドベシステムのアクロバットＰＤＦTMとノーベルのＥｎｖｏｙTMのポータブル文書フォーマットが広く使われている。本発明の好適実施例では、ポータブル文書デリバリーシステム１６０が、ポータブル文書技術をインターネットに適用して、電子文書の配布に関し一般的な解決を果たした。ポータブル文書デリバリーシステム１６０は、ノーベルのＥＮＶＯＹTMとアドベシステムのＰＴＦTM両フォーマットを始めとするポータブル電子文書フォーマットとの完全な互換性を提供する。
【００４０】ポータブル文書デリバリーシステム１６０からポータブル文書を受信する受信者２２は、それら文書から情報を見て、検索し、印刷し、保管し、取り出すことができる。ポータブル文書デリバリーシステム１６０に関連しＥｎｖｏｙTMないしＡｃｒｏｂａｔTMを使って配布された文書は、完全な視覚忠実性を保ち、最高レベルの品質と解像度で高解像度出力装置上に作成できる。ポータブル文書フォーマットは、文書内の情報の内容と色を保つことを可能とし、多くのフォーマットは、かさ張らない状態でファイルが保管できる一方、索引付け、検索、ハイパーテキストリンキングができる。図１４R>４は、バイナリーファイルデリバリーサーバー１２を使用したポータブル文書デリバリーシステム１６０ａの機能ブロック図である。図１５は、インターネットで通信するバイナリーファイルデリバリーサーバー１２ａと１２ｎ二台を使ったポータブル文書デリバリーシステム１６０ｂの機能ブロック図を示す。
【００４１】ウエブと電子メールの限界について追加的サービスに加えて述べると、ポータブル文書デリバリーシステム１６０は、既存の電子メール上、即ち、ｈｔｔｐサーバーソフトウエア上で作動するサーバーソフトウエアとデータベースシステムとを含む。このように、ポータブル文書デリバリーシステム１６０は、電子メール、ウエブ、データベースに関する業界標準の解決策を結合し、会社やユーザーが受信者に文書送付を伝えられる様にしている。次の開示は、一般的な文書デリバリー解決策に関する要件を、ポータブル文書デリバリーシステム１６０の特定コンポーネントと同様に詳しく述べている。ポータブル文書デリバリーシステム１６０は、三つの基本コンポーネントを結合し、一般的な文書デリバリーの解決策を提供する。
【００４２】１）ポータブル文書送信クライアント ポータブル文書送信クライアント（ＰＤＳＣ）１９２は、全てのデスクトップアプリケーション１９０を直接ポータブル文書デリバリーシステム１６０に内蔵する。ＰＤＳＣ１９２は、本発明の全実施例に必要とは限らない。単にＢＦＤサーバー１２を直接導入したい発行者は、そうすればよい。ＰＤＳＣ１９２は、地点間のデリバリーに問題のある標準的な企業のコンピューターユーザーを対象としている。
２）バイナリーファイルサーバー バイナリーファイルデリバリーサーバー１２は、インターネット標準上で作動し受信者に文書を送付する。ＢＦＤサーバー１２は、ポータブル文書送信クライアント（ＰＤＳＣ）１９２を通して明白に呼び出す、ないしサーバー構成ユーザーインターフェース１９８を使用して呼び出し直接カスタマイズすることができる。
【００４３】３）ポータブル文書受信クライアント ポータブル文書受信クライアント（ＰＤＲＣ）１９４は、文書の受信者２２が文書を受け取り、見て、プリントするのに利用するソフトウエアコンポーネントである。ＰＤＲＣソフトウエア１９４を持たない受信者２２は、リンクが与えられてインターネットで直接ソフトウエアにアクセスする。殆どの場合、ＰＤＲＣ１９４は、ネットスケープナビゲーターTMプラグインないしマイクロソフトアクティブＸTMコントロールないしジャバアプレットとして単純に機能し、こうして直接ＰＤＲＣ１９４は受信者の既存のブラウザに同化する。
【００４４】図１８は、ポータブル文書送信クライアントアプリケーションとポータブル文書受信クライアントアプリケーションが本発明でどう使われているか示す。図１９は、サーバー構成ユーザーインターフェースアプリケーションが本発明でどう使われているか示す。
［ポータブル文書デリバリーシステムの要件］ 最も基本的なレベルとして、文書送付解決策は、文書の作成者により文書が受信者に宛てられるないし「ｐｕｓｈされる」のを可能とせねばならない。ポータブル文書デリバリーシステム１６０の設計ねらいは、様々なコンピューターシステム上で様々なオペレーティングシステム、Ｅ−メールシステム、文書タイプを作動させる様々な受信者が、電子ポータブル文書を受け取り、読み、使用して利益を得られる様にすることである。ポータブル文書デリバリーシステム１６０が適合している様々な設計パラメーターカテゴリーとして、主要コンピューターシステム（例えば、パソコン、ワークステーション、サーバー）、主要オペレーティングシステム（例えば、マッキントッシュ、ウインドウズ３．１、ウインドウズ９５、ＮＴ、ユニックス、ＯＳ／２）、電子メールシステム（例えばマイクロソフト、ｃｃ：メール、グループワイズ、ノーツ、ユードラ）、文書タイプ（例えば、紙、ポストスクリプト、クアーク、ワードパーフェクト、エクセル）、及び使用者タイプ（例えば、ＭＩＳ、法律、財務、消費者／家庭、市場通信（ＭａｒＣｏｍ））が挙げられる。
【００４５】ポータブル文書デリバリー１６０の特有な面は、全てのコンピューターシステム、オペレーティングシステム、電子メールシステム、文書タイプに対して解決策がもたらす互換性のレベルである。本発明の一実施例の場合、文書の送信者１６と受信者２２の両者ともインターネットに接続している。本発明の好適実施例においては、ポータブル文書デリバリーシステム１６０は、インターネットでの送付問題の解決策のみならず、ファクシミリ機１７２とプリンター１７８とのバックワード互換性も、今後の配布プリントアーキテクチャとのフォワード互換性と同様に提供している。
［一般的なデリバリー］ 送付問題解決策は、ユーザーが誰にでも文書を配布できるようにせねばならず、様々なコンピューティングープラットフォーム、ファクシミリ１７２との互換性、今後の配布された印刷アーキテクチャとの互換性への支援を必要とする。ポータブル文書デリバリーシステム１６０は、複雑なポストスクリプトファイルの変換と送付を支援できる。文書は、Ｅーメールアカウントを持ちインターネットにアクセスする受信者２２へなら誰へでも、受信者のプラットフォームないしＥ−メールシステムを問わず、送付できる。
【００４６】［機密保護］文書送付の代表的アプリケーションは、文書全体の源から目的場所までの完全な機密保護を要求する。開放されかつ広範なネットワーク中を文書が流れ始めるにつれ、この要件がより浸透してゆく。ポータブル文書デリバリーシステム１６０は、機密保護に複数のレベルを使用する。ポータブル文書送信クライアント１９２は、サーバー１２に情報をアップロードするために安全なソケットを認証し作成する。こうして非ＢＦＤサーバーは文書を傍受できなくなる。加えて、ＰＤＳＣ１９２は、文書の対象受信者にのみ文書へアクセス可能とするのを保証すべく、送信者１６がプライベートないしパブリック暗号化方法を使える様にする。暗号化が使われない場合でも、ポータブル文書デリバリーシステム１６０は、未許可のユーザーが文書にアクセスするのを防ぐ精巧なアルゴリズムを含む。
【００４７】［アカウントマネジメントサービス］ 多くの例で、文書デリバリーアプリケーションは、文書の各々の送信者１６ないし受信者２２が保守されねばならないビジネスの用命に応じる。１０万人の受信者２２からなる同じグループに定期的に文書を送付する場合を想定する。文書の送信者１６は、多数の申し込み加入／配布ベースを更新かつ操作するツールを必要とする。ポータブル文書デリバリーシステム１６０は、発行者１６が、ＢＦＤサーバー１２にアカウントを作成し、処理を特定のアカウント１３２、１３４、１３６に関連付けることを可能にする。システムは更に、発行者が、多数のユーザーアカウントを単一ビリングアカウント１３４に統合することを可能にする。加えて、発行者が、トランザクションに特定ビリングコードを関連付けさせるのを可能にし、トランザクションが処理レポートで統合されるようにできる。例えば、法律事務所は、アカウント、次に各クライアントのビリングコードを作り、ビリングコードとアカウントを各文書トランザクションに関連付ける。ポータブル文書デリバリーシステム１６０は、アカウント情報を自動的に維持・更新する。ポータブル文書デリバリーシステム１６０の報告機能は、ユーザーが所定のアカウントないし特定のビリングコードに関する報告を作成するのを可能にする。こうしたスキームは、ビリングと同様にクライアント管理を容易にする。
【００４８】［トランザクションマネジメントサービス］ トランザクション管理の要件はアカウント管理に関連する。文書の送信者１６と受信者２２のデータベースを維持することのみならず、送信文書の処理を管理するサービスを提供することも必要である。例えば、送信者１６は、文書が実際に送付され実際に受信されたか、そして恐らく誰が文書を受信したかを知りたい。多くの例で、発行者１６は、送付の郵便料金を請求したいであろうし、それ故に送付処理に関連する会計情報を維持・更新するサービスを必要とする。ポータブル文書デリバリーシステム１６０は、各送信処理に関連した記録を作成でき、これら記録を維持できる。各トランザクションないし文書送信操作は、特定のアカウントに関連している。ユーザー１６は、サーバーから処理情報を直接照会できる。
【００４９】［レポーティング］ アカウントとトランザクションの管理は、レポーティングの精巧な手段が提供されなければ何ら価値がない。例えばユーザー１６は、特定の文書が誰に送付されたか、何人のユーザーが文書の送付を確認したか、請求を目的としたトランザクションに関する費用といった情報を含む所定のトランザクションの完全なレポートを提供してもらえる。
［規模と帯域幅］ 文書デリバリーアプリケーションの領域と応用は広い故、ポータブル文書デリバリーシステム１６０は、無数の文書ないし受信者２２にサービス提供する性能を拡張できる。送付プロセスでの幾つかの局面はリアルタイムで起こる一方、他の局面は延期されるないしスケジュール化される。多くの場合ポータブル文書デリバリーシステム１６０は、帯域幅の量又は展開されるサーバー１２ａ−ｎのセットを動的に広げて、文書送付に必要な処理量を達成する。
【００５０】ポータブル文書デリバリーシステム１６０は、ユーザーの要求を満たすようにスケールが変われる。サーバーソフトウエアは、一日に無数の文書を送信するのを支援するよう設計されており、所定のサーバーに専用となったどんな帯域幅でも活用できる。例えば、最近のＢＦＤサーバー１２は、１０メガビット／秒の帯域幅を効率的に利用する。ＢＦＤサーバー１２で作動する様々なプロセスは、非同期で作動して、多重処理サーバー１２での最適な作動を可能にし、同様に所定のトランザクションサービスを精巧にスケジューリングすることも可能にする。リアルタイムの作動には特に注意が払われ、受信者２２がサーバー１２から文書へアクセスすることに関しては特別の注意が払われる。ＢＦＤサーバー１２は、他のサーバー１２ａ−ｎの間での作業負荷を配分することもできる。本発明の好適実施例では、単一のサーバー１２で作動している個々のプロセスを一群のサーバー１２ａ−ｎに配分されるのを可能にする。本実施例では、アカウント管理プロセスを一つのサーバー（例えば、１２ｄ）上で作動させる一方、ロギング、レポーティング、トランザクション管理、送信、宣伝及び検索の諸プロセスを別のサーバー（例えば１２ｈ）上で作動させることが可能である。
【００５１】［ポータブル文書送信クライアント明細書］ ポータブル文書送信クライアント（ＰＤＳＣ）１９２は、どんなコンピューターユーザーでも、パソコンないしマッキントッシュコンピューターといったどんなパーソナルコンピューターのデスクトップから直接、文書を配布できるようにする。ＰＤＳＣ１９２は、仮想のプリンター装置を使い全てのアプリケーション１９０を直接組み込むので、ＰＤＳＣ１９２は、全てのアプリケーション１９２とフォーマットに対し互換性を持てる。重要なのは、ＰＤＳＣ１９２が直接ポータブル文書技術に組み込まれているので、文書の送信者１６は、文書の対象受信者２２の能力について仮定を設ける必要がないことである。ＰＤＳＣ１９２で、使用法の二つの主要モード：プリントないし「ドラッグアンドドロップ」が可能になる。プリントのモードで、送信者１６は、アプリケーション１９０からプリントオプションを単純に選択し、ポータブル文書を作成するイベントシークエンスを開始させ、その後文書をアドレスし送信できる。ユーザーからみると、ユーザーはプリントコマンドを単純に選び、標準アドレシングインターフェースとアドレスブックを使い、文書の最終目的地を指示するよう促される。例えば、マイクロソフトメールTMのユーザーは、標準マイクロソフトメールTMのアドレシングダイアローグで文書をどこへ送信するか命ずるよう促される。ＰＤＳＣ１９２は、文書の最終目的地を選んだ後、ＢＦＤサーバー１２に自動的に接続し、送信をカスタマイズするために選ばれた他の属性と同様に、文書１６６と対象受信者２２のリストとを安全にアップロードする。「ドラッグ アンドドロップ」使用法では、ユーザー１６は文書を送信するためのアプリケーションの開始と印刷を無しで済ませられる。文書は、ＰＤＳＣ１９２送信アイコンに単純にドロップされ、送信者のデスクトップ１６４からアクセスできる。
【００５２】追加の機能性とカスタマゼーションは、一回のクリックアウェイである。アドレシングプロセスの間、ユーザー１６は、高級オプションを呼び出して、送信オプションを自由にカスタマイズできる。デフォルトにより、各送信では既存のパラメーターを再使用し文書を送信することになる。ユーザー１６は高級オプションユーザーインターフェース１９３を使って、例えば機密保護オプション及びレシート要求を含むデリバリーオプションをカスタマイズすることもできる。例えば、プライベート及び／又はパブリックキー暗号化を含む機密保護オプションをユーザー１６がカスタマイズしたければ、ユーザーは「パブリック暗号化」ないし「プライベート暗号化」のオプションをチェックするだけである。同様に、ユーザーは「レシート通知」オプションを選択でき、こうして何時文書が実際に受け取られたか送付を確認する様ＢＦＤサーバー１２に告げる。
【００５３】［ＢＦＤ サーバー構成オプションとユーザーインターフェース］ ＢＦＤサーバー１２を、直接送信者デスクトップ１６４から構成しカスタマイズすることが可能である。デスクトップからＢＦＤサーバー１２へのアクセスは、ＨＴＭＬ型ユーザーインターフェースを使って達成される。このユーザーインターフェースは、ＢＦＤサーバー１２の高級オプションへのアクセスと制御をサーバー管理者に与えるためにある。例えば、サーバー管理者は、特定の文書を受け取る予定の１０万人の受信者のデータベースを更新し、これら受信者への文書送信を直接呼び出してもよい。サーバー管理者は、先週起きた送信処理に関してのレポートを作成できる。デスクトップ１６６からＢＦＤサーバー１２にアクセスするには、ユーザー１６は、ＢＦＤサーバー１２上に作成された特別のアカウントを持たねばならず、これをＢＦＤサーバー１２が前もって作成する。加えて、このアカウントの上側のＢＦＤサーバー１２にアクセスするには、認証及び機密保護の幾つかの層を必要とするので、こうして一方的なアクセスを防ぐ。
【００５４】サーバー構成ユーザーインターフェース１９８は、ユーザーが、サーバーセッティングにアクセスし制御するのを可能にし、これにはトランザクション管理、アカウント管理、レポート便宜、配布文書の直接アップロードとダウンロード、受信者リストの直接操作、及び送信オプションへの直接アクセスが含まれる。［ポータブル文書受信クライアント］ 文書の受信者２２は、ポータブル文書受信クライアント（ＰＤＲＣ）１９４を利用して、ＢＦＤサーバーアドミニストレータを直接経由してポータブル文書送信クライアント１９２ないしＢＦＤサーバー１２により受信者２２に送られた文書に、アクセスし手を加えることができる。文書の受信者２２がＰＤＲＣ１９４をまだ所有していない場合、ソフトウエアはインターネットから直接ダウンロードされて設置されてもよい。ポータブル文書デリバリーシステム１６０のアーキテクチャは、このプロセスを簡素化し、専用ソフトウエアとスクリプトを使用するが、加えて初心者である受信者２２でも文書受信に必要なソフトウエアへのアクセスを一回のクリック操作で可能にする新しいブラウザアーキテクチャを出現させた。
【００５５】ポータブル文書受信クライアント１９４の最も基本的なケースは、ネットスケープナビゲーターTMのプラグインないしマイクロソフトアクティブＸTMコントロールといったブラウザ拡張子として単純に機能できることである。他のユーザーにとっては、ＰＤＲＣ１９４は、ヘルパーアプリケーションとして作動する分散型アプリケーションとして機能する。第三のアプリケーションは、受信者のデスクトップ１７０からポータブル文書へ直接アクセスすることを望むポータブル文書デリバリーシステム１６０の顧客のためにある。この構成では、専用ポータブル文書受信クライアント１９４をインターネットから直接ダウンロードできる。このコンポーネントは、ポータブル文書デリバリーシステム１６０の作動を連続的に監視し、入ってくるどんなポータブル文書をもＢＦＤサーバー１２から自動的に引き抜いて、受信者２２のコンピューターデスクトップ１７０上で直ちに文書通信として開く。
【００５６】ポータブル文書デリバリーシステム１６０からのポータブル文書の受信者２２は、送信構成オプション次第であるが、文書からの情報を見る、探す、プリントする、保管する、送り出すことができる。ポータブル文書デリバリーシステム１６０に関連してＥｎｖｏｙTMないしアクロバットTMを使って配布された文書は、完全な視覚忠実性を保ち、最高レベルの品質と解像度で高解像度出力装置上に作成できる。図２０は、ＢＦＤサーバー１２のファックスゲートウエイ５６によりプリンター１７８へ文書がどう送られるかを示す。図２１は、専用共同ＢＦＤサーバー２００のデパートメントゲートウエイ２０２によりＬＡＮ２０４を通って、文書がどう送られるかを示す。
【００５７】［指示された文書送信のためのプライベートかつ追跡可能なＵＲＬｓ］本発明のこの実施例は、文書を電子的に送付する独自の方法を提供している。重要なのは、本発明のこの実施例が、基本的な文書送信に加えて、トラッキングと機密保護を含みはするがこれらのみに限定されない付加価値のある多くのサービスを可能にしていることである。本発明は、情報を配布するためにプライベートなユニフォームリソースロケータ（ＵＲＬ）を動的に作成する文書送付アーキテクチャを提供する。各プライベートＵＲＬ（「ＰＵＲＬ」）は、文書の対象受信者、送付される文書ないし文書セット、送付プロセスに固有な他の（随意な）パラメーターを独自に定める。文書の対象受信者はＰＵＲＬを使い文書（ないし複数の文書）を検索する。サーバーは文書の検索の際、データベース中の検索に関連するログ情報と同様に、ＰＵＲＬに含まれている属性に基いた検索の行動をカスタマイズする。ＰＵＲＬｓのアーキテクチャと使用法が、文書の安全な送付と文書受信の追跡を可能にする。
【００５８】ワールドワイドウエブ（「ウエブ」）は、顧客がウエブブラウザを使用してウエブサーバーから内容を検索できるようにする。つまり、顧客はウエブから内容を引き出す。Ｅ−メールは、内容の作成者がその内容を顧客に送ることを可能にする。言い換えれば、作成者は内容をＥ−メールでプッシュする。Ｅ−メールインターネットサーバーは、インターネットサーバーの行動を統制するＳＭＴＰプロトコル（単純化されたメールトランスポートプロトコル）同様に、インターネットのユーザーに提供する限られた能力である。例えば、ＳＭＴＰのＥ−メールサーバーは、バイナリーファイルのタイプ、トラッキング、機密保護について何も知らない。ウエブ及び関連したＨＴＴＰプロトコルは対照的に、バイナリー情報の効率的かつ安全な送信を可能にする柔軟なプロトコルを提供する。しかしＨＴＴＰは、プル型顧客作動のプロトコルである故、情報の作成者ないし送信者は、情報送付を指示するのにＨＴＴＰだけを頼りとすることができない。
【００５９】送付のためのＨＴＴＰを組み合わせ、同様に通知のためのＳＭＴＰ／Ｅ−メールを使うことにより、作成者がドライバーになるないしプッシュするのを可能にし、更にＳＭＴＰ／Ｅ−メールに関連した限定条件や生来の問題とは無縁な解決策を作ることが可能である。ＰＵＲＬｓは一時的かつ動的に作られたＰＵＲであり、文書の送付に関連する属性と同様に、文書の対象受信者と文書自体を独自に確認する。ＰＵＲＬｓは、文書を送信するためＥ−メールメッセージに情報を付けるのを防止し、逆に送られる文書に汎用参照番号をつけ、受信者が参照番号を経て文書にアクセスするのを可能にする。受信者が参照番号を使って文書にアクセスすると、サーバーは、文書にアクセスする要求を傍受し、トラッキング・機密保護といった付加価値のあるサービスを提供する。例えば、ユーザーは、サーバー上で文書のロックを解除する役を果たす、即ち、暗号化された文書を恐らく解読するキーをＰＵＲＬに含ませることができる。ないしユーザーは、受信者を確認する独自の身分証明番号をＰＵＲＬに含ませることができる。この場合、サーバーは、特定の個人が特定の文書にアクセスしたことに注目でき、それをデータベースに書き留め、送信者にその情報を利用できるようにすることができる。従って本発明の本実施例は文書追跡を可能にする。
【００６０】図２２は、本発明により命じられた文書送付のためのプライベートかつ追跡可能なＵＲＬｓを含む文書デリバリーシステムを示すブロック図である。文書３１０は送信者３００からサーバー３１５に送られる。サーバーは文書を一時的に記憶する。サーバーは、文書の各対象受信者のためにＵＲＬを動的に作成する。ユーザー情報と文書情報をＵＲＬで暗号化するのに加え、サーバーは、デリバリーパラメーター或いはＵＲＬのトランザクション識別子も暗号化する。生成された各々の個人ＵＲＬ（ＰＵＲＬ）は、次に各対象受信者３２０に送られる。特定の文書が送られてきた旨の通知３２５が受信者に出される。通知は、プライベートなＵＲＬを含むＥ−メールメッセージの形式が代表的である。受信者はＰＵＲＬ３３０とウエブを使って文書にアクセスする。
【００６１】受信者がＰＵＲＬを経て文書にアクセスする時、受信者はサーバーにＰＵＲＬを示す。この時サーバーには、次の一連の動作を決める機会がある。例えば、サーバーは、パスワードを示してからでないとＰＵＲＬが言及した電子文書にアクセスできないとＰＵＲＬに記されていることに気付く。サーバーは、又ＰＵＲＬで文書にアクセスする特定の受信者を確認し、特定の受信者が特定の文書にアクセスを試みたことを記録し、全てがＰＵＲＬによって再度確認される。サーバーは、更に全ての文書が首尾よく送付された事実を記録する。それ故、サーバーに維持されているデータベースは以下に述べる記録を完全に有しており、例えば次の通りである。
・ 誰が文書にアクセスしたか；
・ いつ文書にアクセスしたか；
・ 首尾よく文書にアクセスしたかどうか。
【００６２】サーバーが記録したこの情報は、文書の送信者に報告される。従って、通知のためのＥ−メール、送付のためのウエブ、受信者と文書を確認するためのプライベートＵＲＬｓの組み合わせを使えば、文書をトラッキングし、送信者に文書の送付状態を報告する様に、デリバリーサーバーを構成することが可能である。そうしたシステムを実際に実行するには、図３−２１との関係でここに述べられているシステムに従ってもよく、又適切な他の形式でもよい。本発明の他の実施例で、サーバーは他のタイプの情報を記録できる。こうしてサーバーは、文書を検索する特定の受信者に関するＩＰアドレスを記録できる。サーバーは更に、同じＰＵＲＬのついた特定の文書へ引き続きなされるどんなアクセスのＩＰアドレスをも記録できる。このように、サーバーは、多数のＩＰが同じキーを使用して同じ文書にアクセスするのを防ぐ。代替案として、サーバーは、特定の受信者を対象とした特定の文書にアクセスしたＩＰアドレスを含むリストを送信者に提供することも可能である。
【００６３】送付のための上記のアーキテクチャは、機密保護も容易にする。文書にアクセスし解読するための有効キーを受信者が示すまで、サーバーで文書を暗号化されたままにできる。このキーは暗号化されて、ＰＵＲＬの一部に示される。代替案として、キーを検索せねばならないとＰＵＲＬが述べており、この場合サーバーは、文書を解読するための独自のパスワードを示すよう受信者に要求する。第一の場合、キーはＰＵＲＬのカプセルに包まれているので、暗号化された文書の検索は第一段階の自動プロセスである。
【００６４】［ＰＵＲＬ実行］最初にＰＵＲＬの潜在的構造を考える。次の図で、ＰＵＲＬの特定の一例を略述する。
http://posta.tumbleweed.com/cgi/posta.dll?pu=0-233-33982-FIAAAV4上記ＰＵＲＬの意味は、次の通りである。
バリュー 意味http：／ アクセスにＨＴＴＰプロトコルを使用せよposta.tumbleweed.com ＨＴＴＰサーバーの名前cpi/posta.dll ＨＴＴＰサーバー拡張子の名前pu=0 パスワード使用禁止２３３ ストア項目識別子３３９８２ 受信者識別子FIAAAV4 文書にアクセスするためのキー更に図２２を参照し、ＰＵＲＬ３０２が様々なフィールドを有しているのが示されていることに注目されたい。これらのフィールドには、パスワード識別子３３１、ストア項目識別子３３２、受信者識別子３３３、文書キー３３４、希望する他のオプションフィールド３３５が含まれる。これらフィールドをより詳しく以下に述べる。
【００６５】［パスワード識別子］ パスワード識別子は、所定の文書にアクセスするためにパスワードが要求されているかどうかを記す。この場合、バリュー“０”は、パスワードが要求されていないことを示す。バリュー“１”は、パスワードが要求されていることを示す。
［ストア項目識別子］ ストア項目識別子は、所定の受信者がどの文書を欲しがっているかを独自に定める。この場合、バリュー“２３３”は、サーバー上のまばらな表に索引を提供し、例えば、所定の文書がサーバーのどこにあるか及び／ないし文書が何と名付けられているかを確認するバリューを定める。
［受信者識別子］受信者識別子は、所定の文書の対象受信者を独自に定める。この場合、バリュー「３３９８２」は、サーバー上のまばらな表に索引を提供する。この表索引にあるバリューは、受信者情報を含む。
【００６６】［文書キー］ 文書キーは、ＰＵＲＬ自体を確認する。この場合、キーは、所定の受信者とストア識別子に関連して無作為に作られた数字である。キーは、所定の受信者識別番号が有効か、所定のストア識別番号が有効か、及び所定のストア識別番号を有する所定の受信者の文書へのアクセスが承認されるかどうかを確認するために使われる。本発明の他の実施例では、キーが、確認情報を含む表の中へ索引をも暗号化しており、確認情報それ自体を暗号化するのとは対照的である。重要なのは、サーバーが、ウエブ拡張子を有し、カスタマイゼイションを提供するように文書のＨＴＴＰプロセスが拡張されるのを可能としている点である。こうして、文書にアクセスする受信者は、ＨＴＴＰサーバー拡張子を通してＨＴＴＰサーバーと通信する。本拡張子は例えば、文書にアクセスする承認を決定でき、その場合、特定文書の送信を容易にする新しいＰＵＲＬをユーザーに示す。
【００６７】サーバーは、ＰＵＲＬの上記属性とバリューを使って、文書送付の挙動をカスタマイズできる。特定すれば、サーバーは、文書を送付し、送付トランザクションを記録するため以下のステップを実行する。
・ＰＵＲＬを様々な部分に暗号化する。
・ＰＵＲＬの各コンポーネントを確認する。
・キーで、ＰＵＲＬを認証する。
・受信者識別子で、どのユーザーが文書にアクセスしているかを決定する。
・ストア項目識別子で、どの文書にユーザーがアクセスしているかを決定する。
・上記を前提に、文書が送付される前に追加入力を要求するか否かを決定する。
・文書を受信者に送付する。
・送信の全属性、例えば、アクセス時間、送信の成功、受信者のＩＰ、を記録する。
【００６８】ひとたび情報が、トランザクション情報を記録するサーバー上で作動するデータベースに記録されると、このデータは、受信者によってアクセスされ、受信者に動的に送信されて戻る。例えば、所定の発行者（送信者）は、特定の受信者に送付された全文書に関するサーバーのデータベースを照会できる。発行者は、１０人に送られた所定の文書の状態レポートを作成するようサーバーに照会する。サーバーは、例えば、文書が特定の時刻に１０人全てに送られたが、３人しか実際に文書を検索しなかったと報告する。各文書の検索には、文書がアクセスされた特定時刻、アクセスされた時間、全部が首尾よくアクセスされたか否かが含まれる。それ故、動的に作成されＥ−メールで広めらるＰＵＲＬは、広範なネットワークでの文書送付を追跡する強力な手段をもたらす。
【００６９】電子文書デリバリーシステムとその使用方法を、インターネット中での使用と関連させてここに述べたが、本発明は、インターネット、イントラネット、ＬＡＮとＷＡＮ、ないし望む所のそれらのどの組み合わせをも含む多様なネットワークのどれにでも適用できる。更に本発明は、多様なコンピュータープラットフォーム、通信プロトコル、ポータブル文書フォーマットないし望まれるそれらのどの組み合わせにも適用できる。本発明は、広範なネットワークでの安全な文書送付のための方法とシステムを提供する。文書デリバリーサーバーが、文書の対象受信者のパブリックキーを動的に検索した後、パブリックキーを使って文書ないし文書のシークレットキーを暗号化する。サーバーは、広範なネットワーク、例えばインターネットで対象受信者に暗号化された文書を送付する。対象受信者は、パブリックキーに関連するプライベートキーを使い文書を解読する。本発明は、対象受信者にのみ特定の文書へのアクセスを許し、それ故文書送付のために独自のレベルの機密保護を提供する。
【００７０】本発明の目的のため、文書なる用語は、同一限界内のデータ集合なら全てを含んでおり、データストリーム、ビデオ、音声データ、アニメーション、ＨＴＭＬ・ＰＤＦ・Ｅｎｖｏｙといったフォーマット化された文書、ないしデータベースが含まれる。本発明の好適実施例がインターネットでの文書送信の使用に適応している一方、本発明は、他の広範なネットワークにも同等に適用できる。更に、本発明の好適実施例が受信者コンピューターへの文書送信を開示する一方、本発明は、プライベートキー／パブリックキーを動的に生成しかつプライベートキーを使って対応するパブリックキーで暗号化された文書を解読する能力を維持ないし有するどんな対象受信者に対して、文書送信を作動させることができる。それ故対象受信者として、例えば、デスクトップコンピューター、ファックス機、パーソナルデジタルアシスタントないしネットワークコンピューター装置のインターネットユーザーが含まれる。
【００７１】同様に、文書送信者はデスクトップコンピューターであるのが好ましい一方、送信者として、ネットワークコンピューター装置の様な文書暗号化できデリバリーサーバーと通信できる装置が含まれる。本発明の代替実施例では、文書をデリバリーサーバーにより暗号化する。この実施例では、送信者として、インターネットブラウザ装置、インターネット電話装置、パーソナルデジタルアシスタントないしファックス機といった、暗号化と対象受信者への送信のためにデリバリーサーバーへ文書を伝送できる装置なら何でも含まれる。図２３は、本発明の第一好適実施例による動的サーバー文書暗号化システムの図である。デスクトップコンピューターに記憶された文書を送信者１０３２は、もう一つのコンピューター、対象受信者１０３４に送信する。この第一好適実施例で文書は、ポータブル文書フォーマット（ＰＤＦ）で記憶される。しかし代替実施例では、文書は、どの適切なフォーマットで記憶されてもよい。ポータブル文書（ＰＤ）のフォーマットが、配布されたプリントとファックス解決策に必要となる。しかし、本発明にＰＤフォーマットは必要でない。
【００７２】文書は、デリバリーサーバー１０３６を経て送信者から受信者に送られる。本発明のこの第一好適実施例の場合、デリバリーサーバーは、対象受信者のパブリックキー（証明）を検索するために証明許可データベースサーバー１０３８と通信するよう、送信者により指示される。デリバリーサーバーは、証明元へ動的に照会し、パブリックキーを検索する。パブリックキーはデリバリーサーバーへ送信され、そこから送信者に送信される。本発明の代替実施例において、デリバリーサーバーは、対象受信者のデスクトップコンピューター、インターネットサーバー、ないし対象受信者のデスクトップコンピューターに接続されたイントラネットサーバーから、対象受信者のパブリックキーを検索する。本発明の第一好適実施例において、送信者は、シークレットキーを使用して文書を暗号化し、パブリックキーを使ってシークレットキーを暗号化する。文書と暗号化されたシークレットキーは、次に対象受信者に送信される。シークレットキーが、対象受信者のプライベートキーで解読された後、文書を解読するのに使用される。
【００７３】代替の同等好適実施例として、送信者は、パブリックキーを使って文書を暗号化する。暗号化された文書は対象受信者に送信され、パブリックキーに関連したプライベートキーを使って解読される。図２４は、本発明の第一好適実施例による動的サーバー文書暗号化のための操作セットのフローチャートである。本例では、１０４０のステップで、送信者はシークレットキーを使って文書を暗号化する。こうしたシークレットキーには、先行技術で知られているどんな適切な暗号化スキームも含まれる。１０４５のステップで、送信者はデリバリーサーバーと交信し、１０５０のステップで、対象受信者に関連したパブリックキーについてに照会する。１０５５のステップで、デリバリーサーバーは、例えばこの証明をリアルタイムで証明元のデータベースから検索し、１０６０のステップで、送信者に証明を送信する。
【００７４】最終的に証明元が証明を返してこない場合、デリバリーサーバーが、受信者に新しい証明を動的に生成する。こうすることで、デリバリーサーバーは、動的に作られたＵＲＬをＥ−メールメッセージに入れ受信者へ送る。受信者がＵＲＬにアクセスすると、ジャバアプレットないしプラグインが検索され、受信者のシステムに自動的にダウンロードされる。このアプレットないしプラグインは次に受信者システム上で作動し、一対のプライベート／パブリックキーを作成する。一対のプライベート／パブリックキーをローカルマシンで生成することは、本発明に固有なことではなく、多くの出典で述べられている。アプレットないしプラグインは、次にパブリックキーをデリバリーサーバーへ送る。サーバーは、作成されたＵＲＬのプロパティを使い、受信者のＥーメールアドレスを確認する。こうして、生成されたパブリックキーは、受信者の電子メールアドレスを認証済みとしたプロパティを有する、何故ならキー生成を呼び出すＵＲＬは特定の電子メールアドレスに送られただけだから。サーバーは、電子メールアドレスとパブリックキーを結合させて証明とし、この証明は送信クライアントへ戻されるか、ないし、文書又はシークレットキーを暗号化するためにサーバーにより使用される。デリバリーサーバーは、ＬＤＡＰないし類似のプロトコルを使って、証明を証明元に伝達する。代替案として、ローカルデータベースないし動的に生成された証明を、デリバリーサーバーは将来の使用のために単に維持してもよい。
【００７５】デリバリーサーバーからパブリックキーを受信すると、送信者はパブリックキーでシークレットキー６５を暗号化する。本発明の代替同等好適実施例では、送信者は、パブリックキーを受信するまで文書を暗号化しない。何故ならパブリックキーが認証されなければ文書は暗号化されないからであり、この実施例は、パブリックキーが検索できない時の処理時間を最小にする。次にスッテプ１０７０で、送信者は、暗号化された文書、対象受信者アドレス（例えば電子メールアドレス）、送付指示、暗号化されたシークレットキーを安全なチャンネルで、デリバリーサーバーへ送る。こうして、文書がシークレットキーで暗号化され、シークレットキーが対象受信者のパブリックキーで暗号化されるまで、文書は送信者から離れることがない。次にスッテプ１０７５で、デリバリーサーバーは、暗号化された文書とシークレットキーを対象受信者に送付する。スッテプ１０８０で、対象受信者はパブリックキーに関連したプライベートキーを使ってシークレットキーを解読し、シークレットキーを使って文書を解読する。こうしたスキームは、文書にアクセスできるのはパブリックキーの所有者のみだから、文書への認められていないアクセスを防ぐことになる。
【００７６】図２５は、本発明の代替実施例による、動的サーバー文書暗号化のための操作セットのフローチャートである。ステップ１０９０で、送信者は所定の受信者に文書を送りたい旨をデリバリーサーバーに通知する。ステップ１０９５で、デリバリーサーバーは、対象受信者のパブリックキーを得るべく証明元に照会し、ステップ１１００で、パブリックキーがデリバリーサーバーに戻される。この実施例では、送信者は文書を暗号化せずに、ステップ１１０５で安全なチャンネルでデリバリーサーバーへ文書を送る。次にステップ１１１０で、デリバリーサーバーは、シークレットキーを使い文書を暗号化する。ステップ１１１５で、デリバリーサーバーは、対象受信者から検索したパブリックキーを使ってシークレットキーを暗号化し、次のステップ１１２０で、暗号化された文書とシークレットキーを対象受信者に送る。ステップ１１２５で、対象受信者はプライベートキーを使ってシークレットを解読後、シークレットキーを使い文書を解読する。
【００７７】代替案として、デリバリーサーバーは、パブリックキーを使って文書を暗号化してもよい。暗号化された文書は、次に受信者に送信される。本発明の好適実行例では、送信者は、広範なネットワーク例えばインターネットで作動する全てのデリバリーサーバーを経由して、対象受信者に接続される。送信者は、本文中でセンドクライアントと呼ぶソフトウエアを使用したコンピューターであるのが望ましい。デリバリーサーバーは、所定の受信者のパブリックキーを決定し、そのキーをセンドクライアントに送る責任を果たす。デリバリーサーバーは更に、暗号化された文書とシークレットキーを対象受信者に送付する責任を果たす。センドクライアントは、送付される文書、全デリバリーパラメーター、文書を受信する対象受信者セットをまず識別することで、デリバリートランザクションを始める。デリバリーパラメーターは、予定送付時間、機密保護オプション、送付の緊急性、送付のための提示パラメーター及び受取通知といったオプションを含む。
【００７８】センドクライアントは次にデリバリーサーバーと対話を開始し、シークレットキーで文書を暗号化する。対話と暗号化の段階は、送信者のハードウエア及びソフトウエア構成次第で、同時ないし順番で実行される。対話において、センドクライアントは、所定文書の対象受信者にデリバリーサーバーを送る。ひとたびパブリックキーが取得されると、センドクライアントは、デリバリーサーバーが送信クライアントと交信するよう要求する。センドクライアントは、所定の文書の対象受信者の身元を様々な方法で表現する。本発明の好適実施例において、センドクライアントは、対象受信者の電子メールアドレスを対象受信者の識別子として使用する。しかし、センドクライアントは、代替識別子、例えば運転免許証番号、社会保障番号、抽象識別子、シンボルネームないしファックス番号で、対象受信者を確認できる。
【００７９】デリバリーサーバーは、幾つか技術を使って対象受信者の証明を得る。本発明の好適実施例においては、デリバリーサーバーは、証明元のデータベースサーバーと交信し、対象受信者を確認する情報を示し、対象受信者のパブリックキーを要求する。それ故本発明を使用し、リアルタイムで（照会される）プログラムインターフェースを通して動的にアクセスできるパブリックキーデータベースを維持している証明元から情報を得てもよい。本発明は、ユーザーを介在させずリアルタイムで対象受信者のパブリックキーを照会するデリバリーサーバーに適切などんな手段でも実行される。この様に、特定のプロトコルとパブリックキーデータベースにアクセスする手段は、本発明にとって重要ではない。パブリックキーデータベースへのアクセスには、インターネット技術タスクフォースと合同でミシガン大学が開発したインターネットライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）基準を使うのが好ましい。ＬＤＡＰサーバーは、ディレクトリと他のサービスを提供する。ＬＤＡＰプロトコルを使えば、所定のサーバーの照会、サーバーに維持されている情報の電子ネットワークでの検索ができる。ＬＤＡＰサーバーへの直接照会が、標準インターネットプロトコルを使って可能である。本発明の代替実施例では、例えば、ＰＲＣ（遠隔手続き呼び出し）を始めとする様々なコネクティビティプロトコルを持つＳＱＬ照会を使う。
【００８０】証明元のデータベースサーバーとデリバリーサーバーは、同一サーバー、別のサーバーのいずれであっても良い。証明元のデータベースとデリバリーサーバーの両方を同じサーバーに維持することは、証明の汎用データベースにアクセスする必要がない文書送付専用アプリケーションにとって有利である。例えば、会社は、インターネット通信に使われる同一サーバー上に従業員のパブリックキーのデータベースを維持してもよい。それ故同じサーバーが、証明元のデータベースとして又社内の事務所間通信のデリバリーサーバーとして使われる。証明元のデータベースサーバーとデリバリーサーバーが別々である実施例においては、デリバリーサーバーは、最新の照会された証明のキャッシュ或いはローカルコピーを維持してもよい。こうしてキャッシュを使うと、同じ受信者と証明を将来照会する際に時間削減となる。
【００８１】本発明は、一人以上の受信者への文書送付を支援する。複数の受信者には、上記で論議したプロセスを、バッチモードで適用する。対象受信者を整理したリストがデリバリーサーバーに送られ、デリバリーサーバーは対応する証明の整理済みリストを回答する。本発明は、送信者から受信者への複数文書送信に使ってもよい。その場合、単一シークレットキーを使って各文書を暗号化する。ひとたび、個々の受信者のパブリックキーを含む証明をデリバリーサーバーが戻すと、単一シークレットキーは、対象受信者の検索されたパブリックキーで暗号化される。各受信者に対し、センドクライアントは、暗号化されたシークレットキーと暗号化された文書を、対象受信者のアドレスとデリバリーパラメーターと共に、デリバリーサーバーに送る。
【００８２】デリバリーサーバーは次に、組み合わされ暗号化されたシークレットキーと文書を各受信者に送る。受信装置は、レシーブクライアントとして知られているソフトウエアを使用する。レシーブクライアントは、標準インターネットブラウザへのプラグイン同様、ジャバアプレットとして現在実行されている。ジャバは、カリフォルニア州マウンテンビューのサンマイクロシステム社が開発したプログラミング言語である。しかし、レシーブクライアントは、送信されたシークレットキーと文書を受信かつ解読できるプログラミング言語でなら他の言語を使用しても実行できる。レシーブクライアントは、ジャバアプレットとして実行される場合、デリバリーサーバーから対象受信者のシステムへ動的に配布される。レシーブクライアントは、プライベートキーを使ってシークレットキーを解読する。この解読されたシークレットキーを受信者が使い、文書を解読する。
【００８３】この発明の好適実施例において、レシーブクライアントは、ハイパーテキストトラスミションプロトコル（ＨＴＴＰ）、即ち、標準インターネットデリバリープロトコルを使って、デリバリーサーバーからの暗号化されたシークレットキーと文書にアクセスする。しかし、レシーブクライアントは他の適切なプロトコルを使用してデリバリーサーバーにアクセスしてもよい。ＨＴＴＰ使う場合、レシーブクライアントは、文書のアドレスと送付さるべき鍵を含むユニフォームリソースロケータ（ＵＲＬ）を送信される。本発明の好適実施例において、文書とシークレットキーは、単一ファイルないしデータストリーム中にまとめられ、ＨＴＴＰを使用するレシーブクライアントにそのまま手つかずの形で送付される。こうして、レシーブクライアントは最大の柔軟性を与えられ、パッケージを検索してそれを受信者ウエブブラウザから解読する。受信者は、どんなウエブブラウザをもあるいは広範なネットワークで送信されたデータを受信できる他のソフトウエアアプリケーションを使用してよい。
【００８４】本発明を、好適実施例に関連してここに述べているが、当業者は、他の応用が本発明の範囲から外れることなくここで述べられている応用に代り得ることを難なく認めるであろう。センドクライアント、レシーブクライアント、及びデリバリーサーバーソフトウエアのソースコードは、周知のプログラミング技術とハードウエアコンポーネントを使用する当業者なら難なく作れる。加えて、レシーブクライアントとデリバリーサーバーの機能も、集積回路、ＥＥＰＲＯＭといったプログラミング可能な記憶装置を始めとする他の手段によって成し遂げることができる。本発明の好適実施例に関して上記で論議した動的サーバー文書暗号化の実行は、可能な実行の一つにすぎない。代替実施例は、本発明の教示と一致する他の実行を使ってもよい。
【００８５】レシーブクライアントは、文書を別の装置に向けるように構成してもよい。例えば、解読された文書をプリンターないしファクス機に送信してもよい。本発明では、ＲＳＡ法、ベリサイン法を始めとする適切などんな暗号化スキームをも、シークレットキー、パブリックキー、プライベートキーのために使用してよい。本発明は、特別の好適実施例に関して詳細を述べているが、この発明に関係する当業者は、先の請求項の精神と範囲から離れることなく様々な変更修正と改良ができることを認めるであろう。
【図面の簡単な説明】
【図１】先行技術によるシークレットキー暗号化方式を示す。
【図２】先行技術によるパブリックキー暗号化方式を示す。
【図３】図３は、バイナリーファイルサーバーを一台使うバイナリーファイルデリバリーシステムを示す。
【図４】ファイルサーバーを二台使うバイナリーファイルデリバリーシステムを示す。
【図５】ストア項目のキー要素を示すブロック図である。
【図６】バイナリーファイルデリバリーサーバーの概略図である。
【図７】バイナリーファイルサーバーの一実施例の構造の例を示す。
【図８】バイナリーファイルデリバリーサーバーが使う異なる型のストアイベントを示す。
【図９】バイナリーファイルデリバリーサーバー構造内の特定コンポーネントのブロック図である。
【図１０】ストアの構造を示すブロック図である。
【図１１】インターネットのクライアントをセッション、トランザクション、トランスポートを含む三層にユーザーセッションがどう組織化するかを示す。
【図１２】送信セッションがストア項目を作成した後ないし別のサーバーがストア項目を送っている際の、送信の非対話タスクを示す。
【図１３】アカウントマネージャーの詳細構造を示す。
【図１４】ロガーの詳細構造を提供する。
【図１５】サーバーコネクターの詳細構造を提供する。
【図１６】ポータブル文書デリバリーサーバー一台を使うポータブル文書デリバリーシステムの機能ブロック図を示す。
【図１７】ポータブル文書デリバリーサーバー二台を使うポータブル文書デリバリーシステムの機能ブロック図を示す。
【図１８】ポータブル文書送信クライアントアプリケーションとポータブル文書受信クライアントアプリケーションが、本発明でどう使われるかを示す。
【図１９】サーバーコンフィギュレイションユーザーインターフェースアプリケーションが本発明でどう使われるかを示す。
【図２０】サーバーのファックスゲートウエイにより文書がプリンターへどう送られるかを示す。
【図２１】専用コーポレートサーバーのデパートメントゲートウエイにより文書がＬＡＮを通してデパートメントプリンターへどう送られるかを示す。
【図２２】本発明による指示された文書送付に関するプライベートかつ追跡可能なＵＲＬｓを含む文書デリバリーシステムを示すブロック図である。
【図２３】本発明の第一好適実施例による動的サーバー文書暗号化方法を示す図である。
【図２４】本発明の第一好適実施例による動的サーバー文書暗号化のための動作セットのフローチャートである。
【図２５】本発明の代替実施例による動的サーバー文書暗号化のための動作セットのフローチャートである。
【符号の説明】
３００ 送信者
３１０ 文書
３１５ サーバー
３２０ 受信者（パソコン）
３２５ ＰＵＲＬの通知
３３０ ＰＵＲＬ経由の検索
３０２ ＰＵＲＬ（プライベートユニフォームリソースロケーター）
３３１ パスワード識別子
３３２ ストア項目識別子
３３３ 受信者識別子
３３４ 文書キー
３３５ オプションフィールド
【０００１】
【産業上の利用分野】本発明は、コンピューターネットワーク分野に関する。より詳しくは、インターネットでユーザーに電子文書を送付する技術に関する。本発明は更に、インターネットの様に広範なネットワークでの安全な文書送信を提供するための方法とシステムに関する。
【０００２】
【技術的背景】例えばインターネットや他のオンライン発信源から提供されるコンピューター化された情報源の発達は、電子的に入手可能な情報を増大させた。現在では、インターネット加入ユーザーは、手動操作でインターネット中を駆けめぐり、関心のあったりなかったりする個所を訪れる。このインターネットシステムに固有の問題は、入手可能な情報が「プル」型基盤を通して配布されることであり、その場合、情報を受信したいユーザーは手動で関心のある部分を探すかファインダーアプリケーションを使うかして、適切な情報を探しダウンロードせねばならない。情報や文書を発行・配布したいユーザーにしてみれば、配布したい情報を持っている個人にしろ大きな団体にしろ、現行の「プル」型システムは、「プッシュ」方式で、受信者個人或いは受信者のグループへ自由に送信・配布することを許さない。
【０００３】ファクシミリ技術は、単純な文書の配布に広く現在使われているが、低品質の印刷文書、高価でかさばる紙コピー（特に受信者が紙コピーを持つのを気にしない場合）、内容の欠落（例えば、テキストやグラフは編集も手を加えることもできない）、特に長い或いは複雑な文書を送信するのに時間が掛かる等多くの欠点がある。電子メール（Ｅ−メール）は、電子メッセージをコンピューターユーザーから他の人へ送る手段を提供する。Ｅ−メールには、利便性、フォーマット、後の検索のためのメッセージの保存の利点がある。それなりにＥ−メールは受け入れられ、基本的な通信として広く使われている。Ｅ−メールはＡＳＣＩＩベースのフォーマットが代表的であるが、長い或いはフォーマット化された文書の通信をひどく制限することが判明している。更にＥ−メールは、複雑な文書、例えば、レポート、記事、ページレイアウト格子を含む広告と芸術、ポストスクリプト書式の対象物、トラッキングとカーニングのある複数フォント、グラフ、組み込まれた表、スプレッドシート、その他の複雑な情報の配布に当たって選ぶ手段ではない。Ｅ−メールシステムの中には、ＡＳＣＩＩベースのＥ−メールメッセージをダウンロードされる関連ファイルに追加する手段を提供するものがある。関連ファイルの追加が可能なシステムの殆どは、一人のユーザーから同僚ないし友人へ未保護ファイルの送信を可能とはするが、複数の受信者への制御された自動配布のためではなく、高度なアカウンティング、ビリング、ないしそうした特徴を備えたもの（例えば、領収通知書）を提供しない。Ｅ−メールゲートウエイでは、アタッチメントの応用性を制限されるし、機密保護と受信表示ないし受信通知の問題を未解決である。
【０００４】Ｃ．ボードインの米国特許番号５、４０６、５５７（１９９５年４月１１日）「企業間電子メールハブ」は、共有コアと複数の入出力モジュールから成るコンピューターハブを持つ企業間通信センターを開示している。入力モジュールは、第一エンドユーザーに接続され、第一エンドユーザーが送信したメッセージを汎用フォーマットに変換する。ハブコアはメッセージを待ち行列に入れ、行先ユーザーのフォーマットに変換すべく出力モジュールへ送る。開示されたハブは、単純なＥ−メールメッセージの中継技術を開示している一方で、Ｅ−メールメッセージフォーマットを変換する様設計されているため、本来のテキストベースのファイルの完全性を失っている。開示された先行技術システムと方法論はこのように、文書を送付する幾つかの方法を提供しているが、本来の電子ファイルの完全性を維持しつつプッシュ型で作動する経済的かつ迅速な文書送付システムを提供できていない。こうした電子文書送付システムが開発されれば、大きな技術進歩となろう。加えて、制御されかつ経済的で説明可能なやり方で多くの受信者に電子ポータブル高内容品質の文書を配布できる能力は、更なる技術進歩を構成するであろう。
【０００５】インターネットは、通信にますます使用されている。送信者は今やインターネットで、プラットフォーム、基本ソフトウェア、Ｅ−メールシステムとは無関係に、特定の受信者に文書を送ることができる。送信者のコンピューターのインターネットへの接続は、直接でもイントラネットのサーバー経由でもよい。こうした通信は、たとえ受信側がコンピューターでなく、インターネットに接続されたファックス機械ないしプリンターであっても可能である。インターネット通信の増加により、インターネットで送信される情報の保護を保証する機密保護システムの発達を必要とするに至った。暗号化は、情報への一方的なアクセスを防ぐため情報にスクランブルをかけるのに使用される基本技術である。よく知られている一つの暗号化方法はシークレットキー暗号化であり、時にプライベートキー暗号化ないし対称キー暗号方式とよばれる。シークレットキー暗号化で使われる技術は、一方的なアクセスを防ぐために独自キーを使って情報にスクランブルをかける。この独自キーは、情報を復元する際必要となる。図１は、先行技術に依るシークレットキー暗号化を示す図である。
【０００６】文書１０１０は、シークレットキー１０１４使って１０１２にスクランブルされる。シークレットキーは、スキームの公認ユーザーにのみ入手可能な暗号化スキームである。暗号化ソフトウエアは、ユーザーのコンピューター上或いは離れた位置にあってもよい。文書はこうして、本来の場所、ないし別のコンピューターへの送信時に例えばイントラネットサーバーで暗号化されてもよい。結果的に暗号化された文書１０１６が、受信者に送信される。シークレットキー１０１４を使って１０１８のスクランブルを解除し、本来の文書１０１０を再生する。暗号化された文書に、シークレットキーなしではアクセスできない。解読ソフトウエアは、受信者のコンピューター、離れた位置のどちらにあってもよい。
【０００７】シークレットキー暗号化に関する潜在的問題の一つは、シークレットキーの安全な配布である。シークレットキーが安全でないチャンネルで送信される場合、機密保護の完全性が危険に晒される。多くの実際的なアプリケーションの場合、電話ないしファックスはシークレットキー送付に十分な機密保護を提供するが、文書は、カリフォルニア州レッドウッド市タンブルウイードのソフトウエアコーポレイションから入手可能なポスタといったメールスキームを使いインターネットで送付することができる。しかし事例の中には、キー配布をより安全かつより便利に行う方法をユーザーが要求している。別の暗号化方法は、パブリックキー暗号化方法である。パブリックキー暗号化方法では、送信者と受信者がそれぞれパブリックキー及びプライベートキーと呼ばれる一対のキーを所有する。キーペアーの所有者はパブリックキーを発行し、プライベートキーを秘密にしておく。
【０００８】送信者は、対象受信者が発行したパブリックキーを使い、情報を暗号化する。情報の解読には、受信者のプライベートキーを使う。このように、パブリックキー暗号化方式を使えば、プライベートキーを配布する必要がない。図２は、先行技術によるパブリックキー暗号化方式を示す図である。文書１０２０は、パブリックキー１０２４を使って１０２２にスクランブルされる。結果的に暗号化された文書１０２６は、次に受信者に送信される。プライベートキー１０３０を使ってスクランブルを解除し、本来の文書１０２０を再生する。パブリックキー暗号化に使われるキーは、非常に大きな数字である。パブリックキー暗号化方法は、暗号化と解読を実行するためのキー数字間に難解な数理的関係を利用する。結果的に、発行されたプライベートキーからプライベートキーを難なく引出すことはできない。
【０００９】文書が送信中に変えられていないこと、ないし、文書の送受信者を確認することがしばしば役に立つ。シークレット・パプブリックキー技術は、こうした確認を可能とする。しかし、パブリックキー暗号化アルゴリズムは一般に難解で、時間が掛かり過ぎ実際の使用がしばしばできない。シークレットキー暗号化方法はずっと早いが、安全にキーを送信することに関し欠点がある。パブリックキー／プライベートキー暗号化システムは、ガネサン・ヤクシャの米国特許番号５、５３５、２７６（１９９６年７月９日）「分離プライベートキー非対称暗号方式を使用による通信保護のための改良されたシステムと方法」に述べられている。しかし、ガネサンの暗号化スキームの場合、一時キーの生成に複雑な方法を使っており、複数の異なるユーザーに手動でパブリックキーを要求させる。
【００１０】鳥居の米国特許番号５、３１３、５２１（１９９９１年５月１７日）「ＬＡＮにおけるファイル転送のためのキー配布プロトコル」は、サーバーに対し端末を認証するためにキー配布センターを使う。パストルの米国特許番号４、８５３、９６１（１９８９年８月１日）「信頼性のある文書認証システム」では、解読キーを含む文書認証システムが述べられている。コウドリー他の米国特許番号５、５０９、０７４（１９９６年４月１６日）「電子発行された資料を暗号作成プロトコルを使用して保護する方法」が教示する文書保護システムは、各文書要求を認証するためサーバー同志間の機密保護アクセス操作を含んでいる。しかし、これら先行技術のスキームは全て、証明を認証するのにユーザーが介在せねばならない。
【００１１】別の暗号化方法である電子封筒は、シークレットキーとパブリックキー暗号化の欠点がない。電子封筒を使用し、送信者はシークレットキーで文書を暗号化する。その後シークレットキーをパブリックキーで暗号化する。文書の受信者は、自分のプライベートキーでシークレットキーを解読し、シークレットキーで文書を解読する。現在、パブリックキーの発行のためにレジストリを利用できる。こうしたレジストリは、特定のパブリックキーが特別の存在に属していることを証明できる。例えば、証明元は、それらの特定のパブリックキーに存在を接続するのに使われるデジタル証明を発行・維持する。送信者はレジストリを照会し、要求されたパブリックキー情報を受け取らねばならない。この時間の掛かるプロセスは効率が悪く、特に送信者が多数の文書を異なる受信者に送信せねばならぬ時が特に効率が悪い。
【００１２】暗号化を目的として広範なネットワークでパブリックキーを自動的かつ動的に検索するためのシステムと方法を供給することは有利である。そうしたシステムと方法でサーバーを使って証明を検索し、ユーザーの介在を必要としなければ更に有利である。このシステムと方法で、サーバーが使用者にパブリックキーを戻すまで文書をサーバーに送信しないなら更に一つの利点となる。
【００１３】
【発明の概要】電子文書送付システムとその使用の方法を提供する。文書送付アーキテクチャが、情報を配布するためのプライベートなユニフォームリソースロケータ（ＵＲＬ）を動的に生成する。各々のプライベートなＵＲＬ（“ＰＵＲＬ”）は、独自に、文書の対象受信者、送付される文書或いは文書セット、（随意選択で）送付プロセスに特有な他のパラメーターを定める。文書の対象受信者はＰＵＲＬを使って文書を検索する。文書検索の際、サーバーは、ＰＵＲＬに含まれる属性に基いて検索の挙動をカスタマイズし、同様にデータベースにある検索に関連するログ情報もカスタマイズする。こうしたＰＵＲＬの構造と使用により、安全な文書送付と文書受信の追跡が可能となる。
【００１４】本発明は、例えばインターネットの様な広範なネットワークでの安全な文書送付のための方法とシステムを提供する。文書はデリバリーサーバーを経て送信者から受信者に送付される。本発明の好適実施例では、送信者がデリバリーサーバーに、対象受信者のパブリックキー（証明）を検索するよう命じる。デリバリーサーバーは保証元を動的に問い合わせ、パブリックキーを検索する。パブリックキーがデリバリーサーバーから送信者に送信される。送信者は、シークレットキーを使い文書を暗号化する。その後シークレットキーをパブリックキーで暗号化する。暗号化された文書と暗号化されたシークレットキーの両方をデリバリーサーバーにアップロードし、対象受信者に送信する。次に、対象受信者はパブリックキーと関連したプライベートキーで、シークレットキーを解読し、シークレットキーで文書を解読する。
【００１５】本発明の代替の同程度好適実施例において、送信者はパブリックキーを使い、文書を暗号化する。その後、暗号化された文書は対象受信者に送信され、パブリックキーに関連するプライベートキーで解読される。更に別の実施例では、サーバーが暗号化のため文書をデリバリーサーバーに送信する。デリバリーサーバーが、リアルタイムで証明元に問い合わせ、パブリックキーを検索する。デリバリーサーバーは、シークレットキーを使って文書を暗号化後、パブリックキーでシークレットキーを暗号化する。その後デリバリーサーバーは、暗号化された文書と暗号化されたシークレットキーを対象受信者に送信する。デリバリーサーバーの照会が失敗した場合（所定のユーザーの証明が入手できない）、デリバリーサーバーは対象受信者のために新しいパブリックキーを動的に生成する。その後、この新たな証明が文書暗号化に使われる。
【００１６】
【実施例】バイナリーファイルデリバリーシステム１０は、会社、出版社、個人が文書を電子的に配布できるようにする。重要なのは、バイナリーファイルデリバリーシステム１０は、既存のウエブを基にした文書発行技術と異なり、指示どうりかつ安全な文書配布を可能にする。現在のウエブは、文書の顧客がサーバーから文書を見つけ検索せねばならぬプル発行型の環境として特徴付けられる。これとは対照的に、プッシュ発行型は、文書の作成者が顧客宛に文書を送付するのを可能とする。ファクシミリ（ファックス）、郵便サービス、電子メール（Ｅ−メール）は、全てプッシュ発行の例である。図３は、一台のバイナリーファイルサーバー１２を使用するバイナリーファイルデリバリーシステム１０を示すブロック図である。バイナリーファイルデリバリーシステム１０は、ユーザーが文書をプッシュするのを可能にし、文書作成者が文書の行先を指示するのを可能とする。バイナリーファイルデリバリーシステム１０がプッシュ発行を達成する一つの方法は、ネットワークで情報をプルするために通常実行されるＨＴＴＰを、ＳＭＴＰ（テキストのみをサポート）に結び合せる方法である。バイナリーファイルデリバリーサーバー１０は更に、指示された文書送付の様々なアプリケーションを容易にするため、サービスのホスト役を果たす。或るレベルでバイナリーファイルデリバリーシステム１０は、新世代のファクシミリ技術として特徴付けが可能で、電話回線の代わってネットワークを利用し更に既存のファックス様式より非常に優れた新しい文書表示のためのサポートを導入する。別のレベルで、バイナリーファイルデリバリーシステム１０は、膨大な量の文書と取引を支援できる汎用文書デリバリーサーバーである。あらゆるケースでバイナリーファイルデリバリーサーバー１０は、文書送付に関する完全で力強い解決策を提供する。
【００１７】バイナリーファイルデリバリーサーバー１０は、或るエンドポイントから一つ以上のエンドポイントへバイナリーファイルのセットを送信するのに使われる。エンドポイントは、インターネットアクセスする受信者２２が代表的であるが、ファクシミリ機械１７２又はプリンター１７８といった別のものでもよい（図１６R>６、１７）。バイナリーファイルは、信頼性があり、説明可能で、かつ追跡可能な方法で送付される。バイナリーファイルデリバリーシステム１０が指示されたファイルに提供する機密保護のレベルは、Ｅ−メール同等からファクシミリないし一般の郵便よりは優れたレベルまで様々である。本システムは、ビリングアカウントの貸方・借方を始めとするユーザーアカウント管理を提供する。システムは複数のバイナリーファイルデリバリーサーバー１２の間で協力動作でき、サーバーは他の許可により制御されてもされなくてもよい。図４は、インターネットと通信する二台のバイナリーファイルサーバー１２ａ、１２ｎを使うバイナリーファイルデリバリーシステムを示す。
【００１８】バイナリーファイルデリバリーサーバー１２は三種の基本モードで作動し、これらモードは、送信者１６がアカウント１３２自体を設定しビリングに従属するパブリックモード、送信者１６が管理者に制御されビリングが徴収問題というよりもより内部アカウント問題であるプライベートモード、受信者２２は多いが送信者１６の少ない発行モードの三種である。バイナリーファイルデリバリーサーバー１２は、独立した機能コンポーネントから成り、必ずしもプロセスないし共有ライブラリではない。図６に概略で示されているバイナリーファイルサーバー１２は、ストア４２と呼ばれるインテリジェント記憶コンパートメントを含み、本装置はストアクライアント４４と呼ばれる一連のクライアント４４ａ−４４ｎで増大され、ストアクライアント４４はストア方法を使いストアイベントに従うが、他のクライアント４４と対話したり識別しあうことがない。アカウントマネージャ４６コンポーネントは、送信者１６に関する情報を保持する共有サービスである。受信アプリケーションの場合の、受信者２２に関する情報が更に設計上組み込まれている（Ｅ−メール通知とは対照的である）。
【００１９】クライアント／サーバーの汎用アーキテクチャは、よりパイプライン化された構造よりも、より優れた拡張性がある。しかも、本アーキテクチャによりストアクライアント４４は互いから切り離されるので、幾つかのタスクが相互作用し他がより背後志向であるような状況で有効である。
［ストア］ ストア４２は、一連のストア項目４８を含む。図５に示す様に、ストア項目４８は、バイナリーファイルトリー３４と記述子３６を含み、記述子はストア定義された属性とクライアント定義された属性の一連のセットである。バイナリーファイルトリー３４は、ストア定義された属性の部分と見なすことができる。ファイル記憶システムは次に述べる機能性を提供する。
【００２０】１）ストア項目４８の永久記憶（例えば、ストア項目４８に含まれるバイナリーファイルツリー３４がディスクに書き込まれる。）
２）ストア定義された属性とクライアント定義された属性からなる記述子３６へのクライアント読込／書込アクセス（例えば、クライアント４４は、ストア項目４８の満了日を書き込むことができる。）
３）ストアイベント６７のクライアント通知（例えば、クライアント４４は、新しいストア項目４８の作成イベント６８の通知を受けられる。）
４）ストア定義された属性による内部管理（例えば、ストア項目満了日は、イベントを生成する。）
ストア４２は、ストア項目４８へのアクセスを提供し、ストアイベント６７を作成し、ストア項目４８はストア定義された属性、例えばＩＤ、作成データ、ファイルカウント、ファイルネーム、ファイルデータを所有し、ストアイベント６７は、クライアント４４に従うはずである。ストアイベント６７は、ストア項目４８の作成６８、削除６９、ないし変更修正７０を含んでもよい。イベント６７はアーキテクチャにおける決定的役割を果たすが、何故なら、クライアント４４が自分の仕事を他者に関する非常に限られた情報とどのように同期化させるかを定義しているからである。
【００２１】［ストアクライアント］ ストアクライアント４４は非常に多様で、特定のクライアントについては更に詳述する。本構成の場合、ストアクライアント４４はある種のコンポーネントであって、ストア項目４８での役に立つタスクを実行するために、ストア方法の幾つかを使用するかないしストアイベント６７の幾つかに従う。
［アカウントマネージャー］ アカウントマネージャー４６は、ユーザーとビリングアカウントへの読み込み／書き込みアクセスを提供し、クライアント４４ないしシステム１０の他のコンポーネントが使用する。ストア４２はアカウントを使いも識別もしない。
［他のコンポーネント］ ストアクライアント４４とストア４２自身が使う他のコンポーネントは、本システムのアーキテクチャ内で実行される。例えば、相互サーバー通信、ログ管理、及び他の管理サービスでありこれらについて以下に述べる。
【００２２】図７は、バイナリーファイルサーバー４２の一つの実施例のアーキテクチャの例で、サーバー機能の実行に使われるクライアント４４モジュール（５２−６６）を含んでいる。インターネット送信５２で、ストア項目４８を作成し、属性を書き込む。インターネット受信５４で、既存のストア項目４８を開き、それら属性を変更できる。ファックスゲートウエイ５６で、ストア４２が生成した作成イベント６８に従い、関連したストア項目４８を処理し、次にストア４２からそれらを削除する。フォワーダー５８は、ストア４２が生成した作成イベント６８に従い、次に新たなストア項目４８の属性を調査し、フォワーディングが必要か否か決定する。アーカイバー６０は削除イベントに従い、削除が行われる前に第二プライベート記憶にストア項目４８をコピーする。フォーマットトランスレーター６２は作成に従い、属性を調査し、トランスレーションが必要ならば、読込、処理、ストア項目４８のファイルに書き戻しを行う。ウエブパブリシャー６４は作成イベント６８に従い、ストア項目属性がウエブパブリシングを記したかをチェックし、もし記していれば、必要と見なし属性を読み込む。ピックアップ通知６６は作成イベント６８に従い、受信者２２に通知する。
【００２３】［インターネットベースのユーザーのための機密保護問題］ バイナリーファイルデリバリーシステム１０が専用の機密保護解決策を支援する柔軟性を提供する一方、現在の産業ベースの機密保護解決策を難なく支援しており、それらとして以下のものを挙げることができる。
ａ）安全なサーバー間接続とサーバー認証（ＳＳＬ２．０で利用でき、サーバー（ＨＴＴＰ）に組み込まれている）
ｂ）サーバー間の機密保護（ＳＳＬＸ上で）
ｃ）支援エンドポイントプライベートキー（ユーザーは、自分のチャンネルを使ってプライベートキーを交換せねばならない）
ｄ）暗号化ＡＰＩないし標準ユーザーパブリックキーを使いエンドポイントパブリックキーを支援する。本システムは更に、ユーザーがＢＦＤ使用のみに限ってパブリックキーを生成してそのキーでユーザーアカウント情報を更新するのを助けることもでき、送信者はパブリックキーを得るために受信者と直接通信せずに済む。
【００２４】ｅ）ＳＳＬとＭＳ ＰＣＴを有するサーバーによるクライアント認証（エンドユーザーは自身の証明を得られ、サーバーにより認証してもらえる）
バイナリーファイルデリバリーサーバー１２の重要な面は、複数の要求を同時に処理し、殆どの要求に対する応答時間を最小にすることである。それ故、同期化の問題は正確さとシステム性能の両者にとり重要である。性能の向上には、同期化させたデータアクセスを最小にし、可能な時にはいつでも非同期処理に先送りし、多重タスキングとプラットフォームのためのプロセス内通信（ＩＰＣ）を用いる。サーバー１２の一実施例では、一プロセス内で低オーバーヘッド多重タスキングを提供するスレッディングを大きな拠り所とし、又多重プロセッサー性能を利用可能な時に導入する。本実施例のＩＰＣでは、メールスロットないし遠隔手続き呼び出し（ＲＰＣ）に加えて、ネームドパイプを使う。
【００２５】図７は、バイナリーファイルデリバリーサーバー１２のアーキテクチャ内の特定のコンポーネントのブロック図を示す。ユーザーセッション７２が取り扱うセッションは、送信セッション、受信セッション（ユーザーがＢＦＤデスクトップアプリケーション１９２、１９８を使う時に実行される）、ＨＴＭＬ受信セッション（ユーザーがＢＦＤデスクトップ１６４使う時とは対照的に、ＨＴＭＬブラウザーを通して実行される（ＢＦＤデスクトップセッションはＨＴＭＬを通して実行されてもよいことに留意））、保守セッション（アカウントセットアップと保守セッションを実行する（例えば、通知ダウンロード、アカウントセッティング変更修正（パブリックサーバーのエンドユーザーと対照的な管理者によるコンソールサービスと混同しない様に））、ＨＴＭＬ保守セッション（ＨＴＭＬブラウザを通してアカウントセットアップと保守を実行する）である。
【００２６】デリバリーコンポーネント７４は、通知やフォワーディングを含んだ送付という背後作業を実行する。コンソール７６は管理セッションを実行し、このセッションは専用のユーザーインターフェースの代わりにＨＴＭＬインターフェースを通してなされる。コンソール７６は、アカウント、ロギング、パフォーマンス、パラメーターセッティングを含む全てのサーバー属性をブラウズし変更するためのユーザーインターフェースを提供する。
［共有コンポーネント］ 共有コンポーネントは、ストア４２、ストアクライアント４４のいずれで使用されてもよく、ないしそれ自体で作動してもよい。共有コンポーネントがストアイベント６７に従わない間は、必要に応じて効率、例えばコネクター受信のために、ストア方法を使用できる。共有コンポーネントには以下が含まれる。
【００２７】１）アカウントマネージャー。これは、全てのローカルアカウント情報を維持し、ビリングアカウント及び遠隔アカウント情報を始めとするローカルアカウントへの独自のアクセスインターフェースを提供する。
２）サーバー間の全通信を取り扱うサーバーコネクター８０。
３）出されたメールの送受信を取り扱うメールゲートウエイ８４。
４）ロガー８６。型毎に分類された異なるログへの読込／書込アクセスを管理する。最も重要なログは、ストア項目４８で何が起きたかを追跡する送信／受信トランザクションログである。
５）オペレーティングシステムアクセサー８２。これは、オペレーティングシステムが行うファイル入出力（Ｉ／Ｏ）、プロセス管理（同期化、ロッキング、スレッド、プロセス）、ＩＰＣ（ＲＰＣ、共有記憶、共有待ち行列、パイプ）、ネットワークアクセス（ＴＣＰ／ＩＰソケット、ＨＴＴＰサーバーインターフェーシング、ＰＯＰ／ＳＭＴＰインターフェーシング）用にプラットフォーム独立型インターフェースを提供する。特定の部分が必要に応じて実行される。
【００２８】［サーバーアプリケーション］ サーバーアプリケーション８８は、全てのバイナリーファイルデリバリーサーバー１２を構成パラメーターに従って立ち上げ又停止するのに使われる。更に、アカウントマネージャー（４６ないし７８）ないしロガー８６がカバーしないサーバーの管理面の役割、例えばパフォーマンスプロファイリング、使用法情報、サーバーパラメーター／構成も果たす。図１０は、ストア４２のアーキテクチャを示すブロック図である。ストアマネージャー９２は、包括的状態を維持し、ストア４２へのアクセスを同期化し、ハウスキーピング機能を提供するのに使われる。ストア項目マネージャー９４は、ストア項目４８の状態、ロック、キャッシュ機構を維持するために使われる。ストアイベントマネージャー９６は、リスナーリスト及びイベントフィルターを維持し、同様にイベントフィルターとイベント優先順位に従ってイベントをディスパッチするのにも使わる。
【００２９】図１１は、インターネットクライアントをセッション、トランザクション、トランスポートを含む三層にユーザーセッションがどう組織化するかを示す。セッションマネージャー１０２は、現在作動中の全セッション状態を維持し、セッションに関連したハウスキーピングを実行する。１０２は、ストア４２とアカウントマネージャー４６の使いトランザクションマネージャー１０８から届くトランザクションを処理する。トランザクションマネージャー１０８は、トランスポートマネージャー１１４、１１８から未処理のデータを受信し、一つ以上のＢＦＤトランザクションインタープリター１１０ないしＨＴＭＬトランザクションインタープリター１１２を使ってバリデーションとプリプロセシングを実行する。トランザクションマネージャー１０８は、次にデータを適切なＢＦＤセッションマネージャー１０４ないしＨＴＭＬセッションマネージャー１０６に提出し、回答を待ち、次に回答を適切なトランスポートマネージャー１１４ないし１１８に戻す。
【００３０】図１２は、送信セッションがストア項目４８を一旦作成し、ないし別のサーバー１２ａ−ｎがストア項目４８を送っている時のデリバリーの非対話タスク１２０を示す。デリバリーマネージャー１２２は、関連するストアイベントに従い、フォワーディング決定を下し、作業をノーティファイアー６６とフォワーダー５８に調整する。サーバーディレクトリは、Ｅ−メールドメインとサーバードメインの間の関連付けを追跡し続ける。ノーティファイアー６６は、Ｅ−メール通知２０を受信者２２に渡すのに使われる。フォワーダー５８は、サーバーコネクター８０を使ってストア項目４８を他のサーバー１２ａ−ｎへ送るのに使われる。全ての通知が受信されるとは限らないので、Ｅ−メールスキャナーで「返却された」Ｅ−メールのサーバーメールアカウントをチェックし、それを失敗トランザクションとする。
【００３１】図１３は、アカウントマネージャーのアーキテクチャ１３０の詳細を示す。アカウントマネージャー７８は、ローカルサーバー１２のためにユーザーアカウント状態１３２を維持し、ローカルアカウント１３２のためにビリングアカウント状態１３４を保持し、ローカルアカウント１３２を照会し、リモートアカウント１３６のディレクトリーを維持するのに使われる。リモートアカウントディレクトリー１３６の第一目的は、Ｅ−メールアドレスをＢＦＤアカウントないし非ＢＦＤアカウントと関連付けることである。図１４は、ロガーアーキテクチャの詳細を示す。図１５は、サーバーコネクターアーキテクチャの詳細を示す。
［システムオペレーション］ 次の例は、電子情報を送信者１６から受信者２２に配布するのにバイナリーファイルデリバリーシステム１０がどう使われているかを示す。仮の発行者、カリフォルニア州レッドウッド市のサムは、日本の東京にいる友人ロブに文書を送りたい。以下に進行するイベントで、制御された形でこれがどのように達せられるかを示す。
【００３２】［サムはカリフォルニア州サンタクララのローカルサーバーに接続する。］サムのＢＦＤデスクトップが、彼のユーザーアカウントがあるサンタクララのローカルサーバー１２ａに接続される。セッションマネージャー１０２は、ユーザー１６（サム）を有効にする様アカウントマネージャー７８に照会する。セッションマネージャー１０２は次にユーザー１６に対し送信セッション状態を作る。［サムの送信セッション］ サムのＢＦＤデスクトップがトランザクション詳細、例えばファイル番号、ファイルサイズ、対象受信者を送信する。セッションマネージャー１０２は、このデータをセッション状態に添える。次にセッションマネージャー１０２は、メモリーにあるストア項目４８記述子３６を作成し、ストア４２にディスクスペースを確保し、ストア項目ＩＤも又同様である。その後アップロードが始まる。セッションマネージャー１０２は、データを非同期Ｉ／Ｏで直接ファイルに受け渡しする。
【００３３】サムの全ファイルのアップロード１８が完了した時、セッションマネージャー１０２は、ストア項目記述子３６をディスクに対し非同期で更新し、次にストア項目４８をストア４２に非同期で挿入する。セッションマネージャー１０２は、サムのアップロードに認知の旨回答し、トランザクションに関する情報を提供する。こうして本セッションが終了する。
［サンタクララストアにて］ ストア項目４８の挿入は、非同期にストア４２によりロガー８６にログインされる。ストア４２は、次に、登録されたイベントハンドラーフィルターに反して、ストア項目記述子３６を作動する。整合毎に、ストア４２がイベントと受信者（ロブ）をイベント待ち行列に挿入する。こうしてスレッドは終わる。
【００３４】イベントディスパッチスレッドはイベントをプルし、そのイベントを非同期で受信者にディスパッチするが、ディスパッチの速度はシステムのチューニングパラメーターに依存する。
［サンタクララデリバリーが通知される。］ デリバリー７４は、関連するイベントを通知され、ストア項目４８のロックに応じるスレッドをストア４２との同期トランザクションを経て開始させる。一旦ロックが保全されると、スレッドがストア項目記述子３６を読み込み、記述子をどう扱うか決めるため、デリバリーマネージャー７４が分析する。受信者２２は別のＢＦＤ１２ｎの置かれている日本ドメインにいるとわかる。デリバリーマネージャー７４がサーバーディレクトリ１２４に照会することにより、これがわかる。マネージャーが次にストア項目４８を送ることを決める。フォワードマネージャー８０は、コネクター８０が東京に送るように非同期で依頼する。そうしてデリバリー内のスレッドが終了する。デリバリーがサーバープロトコルを識別してないことに留意されたい。
【００３５】サンタクララコネクター８０は、東京コネクター８０に送信を始める。デリバリー要求を扱うスレッドは、最終的にコネクター８０で始動する。コネクターはホストを知っており又ストア項目４８のロックを所有している。東京サーバー１２ｎとの接続を開始する。接続できない場合はしばらくの間休止する。最終的に接続が開き、コネクター８０がプロトコルインタープリターに入り、最終的にストア項目記述子３６と関連のバイナリーデータファイル３４とを転送する。その後接続を閉じ、東京サーバー１２ｎへの転送成功をロガー８６に記録する。送られた旨記録後、次にコネクター８０はストア４２中にあるストア項目４８のロックを開放する。ロックの解除時、ストア４２は、イベントフィルターリストに反してストア項目記述子３６を作動し、局地で扱われているイベントフィルターを見つける。首尾よく送られたストア項目４８は、１だけ減った参照番号を生じさせる。本例の場合、受信者は一人だけなので、カウント番号が０になることを意味する。それ故、ストア４２はストア項目４８を削除リストに移すことができる。ストア４２のハウスキーピングスレッドが、ある時点でストア項目４８を取り除く。
【００３６】東京コネクターレシーバー８０のスレッドが、接続を扱うため開始される。ひとたびプロトコルインタープリターがフォワードと理解すると、ストア４２にストア項目ＩＤ３６と各自に付された記憶スペースとを要求する。実際のストア項目記述子３６とファイルは、ディスクがデータを受信している最中に、ディスクに書き込まれてしまう。ひとたび接続が完了すると、ストア項目４８は、東京のバイナリーファイルデリバリーサーバー１２ｎのストア４２に非同期で挿入される。
［東京デリバリー装置始動］ 挿入時に東京のストア４２は、デリバリーのスレッドが取り扱おうとするイベントを生成する。新たな項目の挿入もロガー８６に記録する。デリバリー７４のマネージャー１０２は、これが送られたこととこのサーバー１２ｎから受信されるであろうことを了解する。
【００３７】サーバー１２ｎは、ロブのＥ−メールアドレスに関連したアカウントがあるか否かをアカウントマネージャー７８に照会する。ロブのＥ−メールに関連するアカウントがなければ、ストア項目ＩＤ３６を示すＵＲＬ付のＥ−メールがロブに送られる。又、ロブの通知を受けたことをコネクター８０がサンタクララサーバー１２ａに知らせるという非同期の要求を待ち行列に入れる。ロブがアカウントをここに持っていれば、デリバリーが、未決定のデリバリーを告げる様にアカウントマネージャー７８で非同期の更新要求を出す。この場合、シナリオはまだ続く。
［ロブが東京サーバーに接続し、新しい文書をチェックする。］ ロブが受信セッションを開く時、セッションマネージャー１０２はロブのアカウントの有効性を同期的にチェックし、その過程でセッション状態を更新し、アカウントに未決定受信の合図があることを記憶する。ロブのＢＦＤデスクトップは結果的に、文書が受信されるべきだと要求する。セッション状態は答を得て、はいと言う。
【００３８】ロブのデスクトップ１７０が受信を要求すると、セッションマネージャー１０２が、ストア４２に関連するストア項目４８のロックを同期的に要求する。ひとたび承諾されると、データの最初の部分を送信することで回答できる。ひとたび文書がダウンロードされると、受信の成功をロガー８６に非同期的に記録する。こうして、最終的送付をサンタクララサーバー１２ａに通知する様、コネクター８０で非同期の要求を出す。東京での受信セッションでは、セッションマネージャー１０２がロックを解除し、ストア４２に非同期削除要求を出す。ロブの受信セッションは、この時終了する。サンタクララのコネクター８０がプロトコルインタープリターを作動させると、通知をロガー８６に待ち行列に入れるべき旨インタープリタが告げる。
【００３９】［サムが状態をチェックする。］ サムは、保守セッションに続く受信セッションを行うために接続する。保守セッション７２は、送信された文書の状態をチェックする要求を受信する。保守セッション７２は、送信時にサムのデスクトップに伝えられたストア項目ＩＤ３６を使いロガー８６に同期的に照会を出す。照会はマッチング記録のリストを戻し、それらは処理されデスクトップに戻され、こうしてユーザーインターフェース１６を更新できる。
［ポータブル文書デリバリーシステム］ 電子ポータブル文書はますます普及している。これらファイルは、本来の外観と感触を失うことなしに異なるプラットフォームに配布できる。アドベシステムのアクロバットＰＤＦTMとノーベルのＥｎｖｏｙTMのポータブル文書フォーマットが広く使われている。本発明の好適実施例では、ポータブル文書デリバリーシステム１６０が、ポータブル文書技術をインターネットに適用して、電子文書の配布に関し一般的な解決を果たした。ポータブル文書デリバリーシステム１６０は、ノーベルのＥＮＶＯＹTMとアドベシステムのＰＴＦTM両フォーマットを始めとするポータブル電子文書フォーマットとの完全な互換性を提供する。
【００４０】ポータブル文書デリバリーシステム１６０からポータブル文書を受信する受信者２２は、それら文書から情報を見て、検索し、印刷し、保管し、取り出すことができる。ポータブル文書デリバリーシステム１６０に関連しＥｎｖｏｙTMないしＡｃｒｏｂａｔTMを使って配布された文書は、完全な視覚忠実性を保ち、最高レベルの品質と解像度で高解像度出力装置上に作成できる。ポータブル文書フォーマットは、文書内の情報の内容と色を保つことを可能とし、多くのフォーマットは、かさ張らない状態でファイルが保管できる一方、索引付け、検索、ハイパーテキストリンキングができる。図１４R>４は、バイナリーファイルデリバリーサーバー１２を使用したポータブル文書デリバリーシステム１６０ａの機能ブロック図である。図１５は、インターネットで通信するバイナリーファイルデリバリーサーバー１２ａと１２ｎ二台を使ったポータブル文書デリバリーシステム１６０ｂの機能ブロック図を示す。
【００４１】ウエブと電子メールの限界について追加的サービスに加えて述べると、ポータブル文書デリバリーシステム１６０は、既存の電子メール上、即ち、ｈｔｔｐサーバーソフトウエア上で作動するサーバーソフトウエアとデータベースシステムとを含む。このように、ポータブル文書デリバリーシステム１６０は、電子メール、ウエブ、データベースに関する業界標準の解決策を結合し、会社やユーザーが受信者に文書送付を伝えられる様にしている。次の開示は、一般的な文書デリバリー解決策に関する要件を、ポータブル文書デリバリーシステム１６０の特定コンポーネントと同様に詳しく述べている。ポータブル文書デリバリーシステム１６０は、三つの基本コンポーネントを結合し、一般的な文書デリバリーの解決策を提供する。
【００４２】１）ポータブル文書送信クライアント ポータブル文書送信クライアント（ＰＤＳＣ）１９２は、全てのデスクトップアプリケーション１９０を直接ポータブル文書デリバリーシステム１６０に内蔵する。ＰＤＳＣ１９２は、本発明の全実施例に必要とは限らない。単にＢＦＤサーバー１２を直接導入したい発行者は、そうすればよい。ＰＤＳＣ１９２は、地点間のデリバリーに問題のある標準的な企業のコンピューターユーザーを対象としている。
２）バイナリーファイルサーバー バイナリーファイルデリバリーサーバー１２は、インターネット標準上で作動し受信者に文書を送付する。ＢＦＤサーバー１２は、ポータブル文書送信クライアント（ＰＤＳＣ）１９２を通して明白に呼び出す、ないしサーバー構成ユーザーインターフェース１９８を使用して呼び出し直接カスタマイズすることができる。
【００４３】３）ポータブル文書受信クライアント ポータブル文書受信クライアント（ＰＤＲＣ）１９４は、文書の受信者２２が文書を受け取り、見て、プリントするのに利用するソフトウエアコンポーネントである。ＰＤＲＣソフトウエア１９４を持たない受信者２２は、リンクが与えられてインターネットで直接ソフトウエアにアクセスする。殆どの場合、ＰＤＲＣ１９４は、ネットスケープナビゲーターTMプラグインないしマイクロソフトアクティブＸTMコントロールないしジャバアプレットとして単純に機能し、こうして直接ＰＤＲＣ１９４は受信者の既存のブラウザに同化する。
【００４４】図１８は、ポータブル文書送信クライアントアプリケーションとポータブル文書受信クライアントアプリケーションが本発明でどう使われているか示す。図１９は、サーバー構成ユーザーインターフェースアプリケーションが本発明でどう使われているか示す。
［ポータブル文書デリバリーシステムの要件］ 最も基本的なレベルとして、文書送付解決策は、文書の作成者により文書が受信者に宛てられるないし「ｐｕｓｈされる」のを可能とせねばならない。ポータブル文書デリバリーシステム１６０の設計ねらいは、様々なコンピューターシステム上で様々なオペレーティングシステム、Ｅ−メールシステム、文書タイプを作動させる様々な受信者が、電子ポータブル文書を受け取り、読み、使用して利益を得られる様にすることである。ポータブル文書デリバリーシステム１６０が適合している様々な設計パラメーターカテゴリーとして、主要コンピューターシステム（例えば、パソコン、ワークステーション、サーバー）、主要オペレーティングシステム（例えば、マッキントッシュ、ウインドウズ３．１、ウインドウズ９５、ＮＴ、ユニックス、ＯＳ／２）、電子メールシステム（例えばマイクロソフト、ｃｃ：メール、グループワイズ、ノーツ、ユードラ）、文書タイプ（例えば、紙、ポストスクリプト、クアーク、ワードパーフェクト、エクセル）、及び使用者タイプ（例えば、ＭＩＳ、法律、財務、消費者／家庭、市場通信（ＭａｒＣｏｍ））が挙げられる。
【００４５】ポータブル文書デリバリー１６０の特有な面は、全てのコンピューターシステム、オペレーティングシステム、電子メールシステム、文書タイプに対して解決策がもたらす互換性のレベルである。本発明の一実施例の場合、文書の送信者１６と受信者２２の両者ともインターネットに接続している。本発明の好適実施例においては、ポータブル文書デリバリーシステム１６０は、インターネットでの送付問題の解決策のみならず、ファクシミリ機１７２とプリンター１７８とのバックワード互換性も、今後の配布プリントアーキテクチャとのフォワード互換性と同様に提供している。
［一般的なデリバリー］ 送付問題解決策は、ユーザーが誰にでも文書を配布できるようにせねばならず、様々なコンピューティングープラットフォーム、ファクシミリ１７２との互換性、今後の配布された印刷アーキテクチャとの互換性への支援を必要とする。ポータブル文書デリバリーシステム１６０は、複雑なポストスクリプトファイルの変換と送付を支援できる。文書は、Ｅーメールアカウントを持ちインターネットにアクセスする受信者２２へなら誰へでも、受信者のプラットフォームないしＥ−メールシステムを問わず、送付できる。
【００４６】［機密保護］文書送付の代表的アプリケーションは、文書全体の源から目的場所までの完全な機密保護を要求する。開放されかつ広範なネットワーク中を文書が流れ始めるにつれ、この要件がより浸透してゆく。ポータブル文書デリバリーシステム１６０は、機密保護に複数のレベルを使用する。ポータブル文書送信クライアント１９２は、サーバー１２に情報をアップロードするために安全なソケットを認証し作成する。こうして非ＢＦＤサーバーは文書を傍受できなくなる。加えて、ＰＤＳＣ１９２は、文書の対象受信者にのみ文書へアクセス可能とするのを保証すべく、送信者１６がプライベートないしパブリック暗号化方法を使える様にする。暗号化が使われない場合でも、ポータブル文書デリバリーシステム１６０は、未許可のユーザーが文書にアクセスするのを防ぐ精巧なアルゴリズムを含む。
【００４７】［アカウントマネジメントサービス］ 多くの例で、文書デリバリーアプリケーションは、文書の各々の送信者１６ないし受信者２２が保守されねばならないビジネスの用命に応じる。１０万人の受信者２２からなる同じグループに定期的に文書を送付する場合を想定する。文書の送信者１６は、多数の申し込み加入／配布ベースを更新かつ操作するツールを必要とする。ポータブル文書デリバリーシステム１６０は、発行者１６が、ＢＦＤサーバー１２にアカウントを作成し、処理を特定のアカウント１３２、１３４、１３６に関連付けることを可能にする。システムは更に、発行者が、多数のユーザーアカウントを単一ビリングアカウント１３４に統合することを可能にする。加えて、発行者が、トランザクションに特定ビリングコードを関連付けさせるのを可能にし、トランザクションが処理レポートで統合されるようにできる。例えば、法律事務所は、アカウント、次に各クライアントのビリングコードを作り、ビリングコードとアカウントを各文書トランザクションに関連付ける。ポータブル文書デリバリーシステム１６０は、アカウント情報を自動的に維持・更新する。ポータブル文書デリバリーシステム１６０の報告機能は、ユーザーが所定のアカウントないし特定のビリングコードに関する報告を作成するのを可能にする。こうしたスキームは、ビリングと同様にクライアント管理を容易にする。
【００４８】［トランザクションマネジメントサービス］ トランザクション管理の要件はアカウント管理に関連する。文書の送信者１６と受信者２２のデータベースを維持することのみならず、送信文書の処理を管理するサービスを提供することも必要である。例えば、送信者１６は、文書が実際に送付され実際に受信されたか、そして恐らく誰が文書を受信したかを知りたい。多くの例で、発行者１６は、送付の郵便料金を請求したいであろうし、それ故に送付処理に関連する会計情報を維持・更新するサービスを必要とする。ポータブル文書デリバリーシステム１６０は、各送信処理に関連した記録を作成でき、これら記録を維持できる。各トランザクションないし文書送信操作は、特定のアカウントに関連している。ユーザー１６は、サーバーから処理情報を直接照会できる。
【００４９】［レポーティング］ アカウントとトランザクションの管理は、レポーティングの精巧な手段が提供されなければ何ら価値がない。例えばユーザー１６は、特定の文書が誰に送付されたか、何人のユーザーが文書の送付を確認したか、請求を目的としたトランザクションに関する費用といった情報を含む所定のトランザクションの完全なレポートを提供してもらえる。
［規模と帯域幅］ 文書デリバリーアプリケーションの領域と応用は広い故、ポータブル文書デリバリーシステム１６０は、無数の文書ないし受信者２２にサービス提供する性能を拡張できる。送付プロセスでの幾つかの局面はリアルタイムで起こる一方、他の局面は延期されるないしスケジュール化される。多くの場合ポータブル文書デリバリーシステム１６０は、帯域幅の量又は展開されるサーバー１２ａ−ｎのセットを動的に広げて、文書送付に必要な処理量を達成する。
【００５０】ポータブル文書デリバリーシステム１６０は、ユーザーの要求を満たすようにスケールが変われる。サーバーソフトウエアは、一日に無数の文書を送信するのを支援するよう設計されており、所定のサーバーに専用となったどんな帯域幅でも活用できる。例えば、最近のＢＦＤサーバー１２は、１０メガビット／秒の帯域幅を効率的に利用する。ＢＦＤサーバー１２で作動する様々なプロセスは、非同期で作動して、多重処理サーバー１２での最適な作動を可能にし、同様に所定のトランザクションサービスを精巧にスケジューリングすることも可能にする。リアルタイムの作動には特に注意が払われ、受信者２２がサーバー１２から文書へアクセスすることに関しては特別の注意が払われる。ＢＦＤサーバー１２は、他のサーバー１２ａ−ｎの間での作業負荷を配分することもできる。本発明の好適実施例では、単一のサーバー１２で作動している個々のプロセスを一群のサーバー１２ａ−ｎに配分されるのを可能にする。本実施例では、アカウント管理プロセスを一つのサーバー（例えば、１２ｄ）上で作動させる一方、ロギング、レポーティング、トランザクション管理、送信、宣伝及び検索の諸プロセスを別のサーバー（例えば１２ｈ）上で作動させることが可能である。
【００５１】［ポータブル文書送信クライアント明細書］ ポータブル文書送信クライアント（ＰＤＳＣ）１９２は、どんなコンピューターユーザーでも、パソコンないしマッキントッシュコンピューターといったどんなパーソナルコンピューターのデスクトップから直接、文書を配布できるようにする。ＰＤＳＣ１９２は、仮想のプリンター装置を使い全てのアプリケーション１９０を直接組み込むので、ＰＤＳＣ１９２は、全てのアプリケーション１９２とフォーマットに対し互換性を持てる。重要なのは、ＰＤＳＣ１９２が直接ポータブル文書技術に組み込まれているので、文書の送信者１６は、文書の対象受信者２２の能力について仮定を設ける必要がないことである。ＰＤＳＣ１９２で、使用法の二つの主要モード：プリントないし「ドラッグアンドドロップ」が可能になる。プリントのモードで、送信者１６は、アプリケーション１９０からプリントオプションを単純に選択し、ポータブル文書を作成するイベントシークエンスを開始させ、その後文書をアドレスし送信できる。ユーザーからみると、ユーザーはプリントコマンドを単純に選び、標準アドレシングインターフェースとアドレスブックを使い、文書の最終目的地を指示するよう促される。例えば、マイクロソフトメールTMのユーザーは、標準マイクロソフトメールTMのアドレシングダイアローグで文書をどこへ送信するか命ずるよう促される。ＰＤＳＣ１９２は、文書の最終目的地を選んだ後、ＢＦＤサーバー１２に自動的に接続し、送信をカスタマイズするために選ばれた他の属性と同様に、文書１６６と対象受信者２２のリストとを安全にアップロードする。「ドラッグ アンドドロップ」使用法では、ユーザー１６は文書を送信するためのアプリケーションの開始と印刷を無しで済ませられる。文書は、ＰＤＳＣ１９２送信アイコンに単純にドロップされ、送信者のデスクトップ１６４からアクセスできる。
【００５２】追加の機能性とカスタマゼーションは、一回のクリックアウェイである。アドレシングプロセスの間、ユーザー１６は、高級オプションを呼び出して、送信オプションを自由にカスタマイズできる。デフォルトにより、各送信では既存のパラメーターを再使用し文書を送信することになる。ユーザー１６は高級オプションユーザーインターフェース１９３を使って、例えば機密保護オプション及びレシート要求を含むデリバリーオプションをカスタマイズすることもできる。例えば、プライベート及び／又はパブリックキー暗号化を含む機密保護オプションをユーザー１６がカスタマイズしたければ、ユーザーは「パブリック暗号化」ないし「プライベート暗号化」のオプションをチェックするだけである。同様に、ユーザーは「レシート通知」オプションを選択でき、こうして何時文書が実際に受け取られたか送付を確認する様ＢＦＤサーバー１２に告げる。
【００５３】［ＢＦＤ サーバー構成オプションとユーザーインターフェース］ ＢＦＤサーバー１２を、直接送信者デスクトップ１６４から構成しカスタマイズすることが可能である。デスクトップからＢＦＤサーバー１２へのアクセスは、ＨＴＭＬ型ユーザーインターフェースを使って達成される。このユーザーインターフェースは、ＢＦＤサーバー１２の高級オプションへのアクセスと制御をサーバー管理者に与えるためにある。例えば、サーバー管理者は、特定の文書を受け取る予定の１０万人の受信者のデータベースを更新し、これら受信者への文書送信を直接呼び出してもよい。サーバー管理者は、先週起きた送信処理に関してのレポートを作成できる。デスクトップ１６６からＢＦＤサーバー１２にアクセスするには、ユーザー１６は、ＢＦＤサーバー１２上に作成された特別のアカウントを持たねばならず、これをＢＦＤサーバー１２が前もって作成する。加えて、このアカウントの上側のＢＦＤサーバー１２にアクセスするには、認証及び機密保護の幾つかの層を必要とするので、こうして一方的なアクセスを防ぐ。
【００５４】サーバー構成ユーザーインターフェース１９８は、ユーザーが、サーバーセッティングにアクセスし制御するのを可能にし、これにはトランザクション管理、アカウント管理、レポート便宜、配布文書の直接アップロードとダウンロード、受信者リストの直接操作、及び送信オプションへの直接アクセスが含まれる。［ポータブル文書受信クライアント］ 文書の受信者２２は、ポータブル文書受信クライアント（ＰＤＲＣ）１９４を利用して、ＢＦＤサーバーアドミニストレータを直接経由してポータブル文書送信クライアント１９２ないしＢＦＤサーバー１２により受信者２２に送られた文書に、アクセスし手を加えることができる。文書の受信者２２がＰＤＲＣ１９４をまだ所有していない場合、ソフトウエアはインターネットから直接ダウンロードされて設置されてもよい。ポータブル文書デリバリーシステム１６０のアーキテクチャは、このプロセスを簡素化し、専用ソフトウエアとスクリプトを使用するが、加えて初心者である受信者２２でも文書受信に必要なソフトウエアへのアクセスを一回のクリック操作で可能にする新しいブラウザアーキテクチャを出現させた。
【００５５】ポータブル文書受信クライアント１９４の最も基本的なケースは、ネットスケープナビゲーターTMのプラグインないしマイクロソフトアクティブＸTMコントロールといったブラウザ拡張子として単純に機能できることである。他のユーザーにとっては、ＰＤＲＣ１９４は、ヘルパーアプリケーションとして作動する分散型アプリケーションとして機能する。第三のアプリケーションは、受信者のデスクトップ１７０からポータブル文書へ直接アクセスすることを望むポータブル文書デリバリーシステム１６０の顧客のためにある。この構成では、専用ポータブル文書受信クライアント１９４をインターネットから直接ダウンロードできる。このコンポーネントは、ポータブル文書デリバリーシステム１６０の作動を連続的に監視し、入ってくるどんなポータブル文書をもＢＦＤサーバー１２から自動的に引き抜いて、受信者２２のコンピューターデスクトップ１７０上で直ちに文書通信として開く。
【００５６】ポータブル文書デリバリーシステム１６０からのポータブル文書の受信者２２は、送信構成オプション次第であるが、文書からの情報を見る、探す、プリントする、保管する、送り出すことができる。ポータブル文書デリバリーシステム１６０に関連してＥｎｖｏｙTMないしアクロバットTMを使って配布された文書は、完全な視覚忠実性を保ち、最高レベルの品質と解像度で高解像度出力装置上に作成できる。図２０は、ＢＦＤサーバー１２のファックスゲートウエイ５６によりプリンター１７８へ文書がどう送られるかを示す。図２１は、専用共同ＢＦＤサーバー２００のデパートメントゲートウエイ２０２によりＬＡＮ２０４を通って、文書がどう送られるかを示す。
【００５７】［指示された文書送信のためのプライベートかつ追跡可能なＵＲＬｓ］本発明のこの実施例は、文書を電子的に送付する独自の方法を提供している。重要なのは、本発明のこの実施例が、基本的な文書送信に加えて、トラッキングと機密保護を含みはするがこれらのみに限定されない付加価値のある多くのサービスを可能にしていることである。本発明は、情報を配布するためにプライベートなユニフォームリソースロケータ（ＵＲＬ）を動的に作成する文書送付アーキテクチャを提供する。各プライベートＵＲＬ（「ＰＵＲＬ」）は、文書の対象受信者、送付される文書ないし文書セット、送付プロセスに固有な他の（随意な）パラメーターを独自に定める。文書の対象受信者はＰＵＲＬを使い文書（ないし複数の文書）を検索する。サーバーは文書の検索の際、データベース中の検索に関連するログ情報と同様に、ＰＵＲＬに含まれている属性に基いた検索の行動をカスタマイズする。ＰＵＲＬｓのアーキテクチャと使用法が、文書の安全な送付と文書受信の追跡を可能にする。
【００５８】ワールドワイドウエブ（「ウエブ」）は、顧客がウエブブラウザを使用してウエブサーバーから内容を検索できるようにする。つまり、顧客はウエブから内容を引き出す。Ｅ−メールは、内容の作成者がその内容を顧客に送ることを可能にする。言い換えれば、作成者は内容をＥ−メールでプッシュする。Ｅ−メールインターネットサーバーは、インターネットサーバーの行動を統制するＳＭＴＰプロトコル（単純化されたメールトランスポートプロトコル）同様に、インターネットのユーザーに提供する限られた能力である。例えば、ＳＭＴＰのＥ−メールサーバーは、バイナリーファイルのタイプ、トラッキング、機密保護について何も知らない。ウエブ及び関連したＨＴＴＰプロトコルは対照的に、バイナリー情報の効率的かつ安全な送信を可能にする柔軟なプロトコルを提供する。しかしＨＴＴＰは、プル型顧客作動のプロトコルである故、情報の作成者ないし送信者は、情報送付を指示するのにＨＴＴＰだけを頼りとすることができない。
【００５９】送付のためのＨＴＴＰを組み合わせ、同様に通知のためのＳＭＴＰ／Ｅ−メールを使うことにより、作成者がドライバーになるないしプッシュするのを可能にし、更にＳＭＴＰ／Ｅ−メールに関連した限定条件や生来の問題とは無縁な解決策を作ることが可能である。ＰＵＲＬｓは一時的かつ動的に作られたＰＵＲであり、文書の送付に関連する属性と同様に、文書の対象受信者と文書自体を独自に確認する。ＰＵＲＬｓは、文書を送信するためＥ−メールメッセージに情報を付けるのを防止し、逆に送られる文書に汎用参照番号をつけ、受信者が参照番号を経て文書にアクセスするのを可能にする。受信者が参照番号を使って文書にアクセスすると、サーバーは、文書にアクセスする要求を傍受し、トラッキング・機密保護といった付加価値のあるサービスを提供する。例えば、ユーザーは、サーバー上で文書のロックを解除する役を果たす、即ち、暗号化された文書を恐らく解読するキーをＰＵＲＬに含ませることができる。ないしユーザーは、受信者を確認する独自の身分証明番号をＰＵＲＬに含ませることができる。この場合、サーバーは、特定の個人が特定の文書にアクセスしたことに注目でき、それをデータベースに書き留め、送信者にその情報を利用できるようにすることができる。従って本発明の本実施例は文書追跡を可能にする。
【００６０】図２２は、本発明により命じられた文書送付のためのプライベートかつ追跡可能なＵＲＬｓを含む文書デリバリーシステムを示すブロック図である。文書３１０は送信者３００からサーバー３１５に送られる。サーバーは文書を一時的に記憶する。サーバーは、文書の各対象受信者のためにＵＲＬを動的に作成する。ユーザー情報と文書情報をＵＲＬで暗号化するのに加え、サーバーは、デリバリーパラメーター或いはＵＲＬのトランザクション識別子も暗号化する。生成された各々の個人ＵＲＬ（ＰＵＲＬ）は、次に各対象受信者３２０に送られる。特定の文書が送られてきた旨の通知３２５が受信者に出される。通知は、プライベートなＵＲＬを含むＥ−メールメッセージの形式が代表的である。受信者はＰＵＲＬ３３０とウエブを使って文書にアクセスする。
【００６１】受信者がＰＵＲＬを経て文書にアクセスする時、受信者はサーバーにＰＵＲＬを示す。この時サーバーには、次の一連の動作を決める機会がある。例えば、サーバーは、パスワードを示してからでないとＰＵＲＬが言及した電子文書にアクセスできないとＰＵＲＬに記されていることに気付く。サーバーは、又ＰＵＲＬで文書にアクセスする特定の受信者を確認し、特定の受信者が特定の文書にアクセスを試みたことを記録し、全てがＰＵＲＬによって再度確認される。サーバーは、更に全ての文書が首尾よく送付された事実を記録する。それ故、サーバーに維持されているデータベースは以下に述べる記録を完全に有しており、例えば次の通りである。
・ 誰が文書にアクセスしたか；
・ いつ文書にアクセスしたか；
・ 首尾よく文書にアクセスしたかどうか。
【００６２】サーバーが記録したこの情報は、文書の送信者に報告される。従って、通知のためのＥ−メール、送付のためのウエブ、受信者と文書を確認するためのプライベートＵＲＬｓの組み合わせを使えば、文書をトラッキングし、送信者に文書の送付状態を報告する様に、デリバリーサーバーを構成することが可能である。そうしたシステムを実際に実行するには、図３−２１との関係でここに述べられているシステムに従ってもよく、又適切な他の形式でもよい。本発明の他の実施例で、サーバーは他のタイプの情報を記録できる。こうしてサーバーは、文書を検索する特定の受信者に関するＩＰアドレスを記録できる。サーバーは更に、同じＰＵＲＬのついた特定の文書へ引き続きなされるどんなアクセスのＩＰアドレスをも記録できる。このように、サーバーは、多数のＩＰが同じキーを使用して同じ文書にアクセスするのを防ぐ。代替案として、サーバーは、特定の受信者を対象とした特定の文書にアクセスしたＩＰアドレスを含むリストを送信者に提供することも可能である。
【００６３】送付のための上記のアーキテクチャは、機密保護も容易にする。文書にアクセスし解読するための有効キーを受信者が示すまで、サーバーで文書を暗号化されたままにできる。このキーは暗号化されて、ＰＵＲＬの一部に示される。代替案として、キーを検索せねばならないとＰＵＲＬが述べており、この場合サーバーは、文書を解読するための独自のパスワードを示すよう受信者に要求する。第一の場合、キーはＰＵＲＬのカプセルに包まれているので、暗号化された文書の検索は第一段階の自動プロセスである。
【００６４】［ＰＵＲＬ実行］最初にＰＵＲＬの潜在的構造を考える。次の図で、ＰＵＲＬの特定の一例を略述する。
http://posta.tumbleweed.com/cgi/posta.dll?pu=0-233-33982-FIAAAV4上記ＰＵＲＬの意味は、次の通りである。
バリュー 意味http：／ アクセスにＨＴＴＰプロトコルを使用せよposta.tumbleweed.com ＨＴＴＰサーバーの名前cpi/posta.dll ＨＴＴＰサーバー拡張子の名前pu=0 パスワード使用禁止２３３ ストア項目識別子３３９８２ 受信者識別子FIAAAV4 文書にアクセスするためのキー更に図２２を参照し、ＰＵＲＬ３０２が様々なフィールドを有しているのが示されていることに注目されたい。これらのフィールドには、パスワード識別子３３１、ストア項目識別子３３２、受信者識別子３３３、文書キー３３４、希望する他のオプションフィールド３３５が含まれる。これらフィールドをより詳しく以下に述べる。
【００６５】［パスワード識別子］ パスワード識別子は、所定の文書にアクセスするためにパスワードが要求されているかどうかを記す。この場合、バリュー“０”は、パスワードが要求されていないことを示す。バリュー“１”は、パスワードが要求されていることを示す。
［ストア項目識別子］ ストア項目識別子は、所定の受信者がどの文書を欲しがっているかを独自に定める。この場合、バリュー“２３３”は、サーバー上のまばらな表に索引を提供し、例えば、所定の文書がサーバーのどこにあるか及び／ないし文書が何と名付けられているかを確認するバリューを定める。
［受信者識別子］受信者識別子は、所定の文書の対象受信者を独自に定める。この場合、バリュー「３３９８２」は、サーバー上のまばらな表に索引を提供する。この表索引にあるバリューは、受信者情報を含む。
【００６６】［文書キー］ 文書キーは、ＰＵＲＬ自体を確認する。この場合、キーは、所定の受信者とストア識別子に関連して無作為に作られた数字である。キーは、所定の受信者識別番号が有効か、所定のストア識別番号が有効か、及び所定のストア識別番号を有する所定の受信者の文書へのアクセスが承認されるかどうかを確認するために使われる。本発明の他の実施例では、キーが、確認情報を含む表の中へ索引をも暗号化しており、確認情報それ自体を暗号化するのとは対照的である。重要なのは、サーバーが、ウエブ拡張子を有し、カスタマイゼイションを提供するように文書のＨＴＴＰプロセスが拡張されるのを可能としている点である。こうして、文書にアクセスする受信者は、ＨＴＴＰサーバー拡張子を通してＨＴＴＰサーバーと通信する。本拡張子は例えば、文書にアクセスする承認を決定でき、その場合、特定文書の送信を容易にする新しいＰＵＲＬをユーザーに示す。
【００６７】サーバーは、ＰＵＲＬの上記属性とバリューを使って、文書送付の挙動をカスタマイズできる。特定すれば、サーバーは、文書を送付し、送付トランザクションを記録するため以下のステップを実行する。
・ＰＵＲＬを様々な部分に暗号化する。
・ＰＵＲＬの各コンポーネントを確認する。
・キーで、ＰＵＲＬを認証する。
・受信者識別子で、どのユーザーが文書にアクセスしているかを決定する。
・ストア項目識別子で、どの文書にユーザーがアクセスしているかを決定する。
・上記を前提に、文書が送付される前に追加入力を要求するか否かを決定する。
・文書を受信者に送付する。
・送信の全属性、例えば、アクセス時間、送信の成功、受信者のＩＰ、を記録する。
【００６８】ひとたび情報が、トランザクション情報を記録するサーバー上で作動するデータベースに記録されると、このデータは、受信者によってアクセスされ、受信者に動的に送信されて戻る。例えば、所定の発行者（送信者）は、特定の受信者に送付された全文書に関するサーバーのデータベースを照会できる。発行者は、１０人に送られた所定の文書の状態レポートを作成するようサーバーに照会する。サーバーは、例えば、文書が特定の時刻に１０人全てに送られたが、３人しか実際に文書を検索しなかったと報告する。各文書の検索には、文書がアクセスされた特定時刻、アクセスされた時間、全部が首尾よくアクセスされたか否かが含まれる。それ故、動的に作成されＥ−メールで広めらるＰＵＲＬは、広範なネットワークでの文書送付を追跡する強力な手段をもたらす。
【００６９】電子文書デリバリーシステムとその使用方法を、インターネット中での使用と関連させてここに述べたが、本発明は、インターネット、イントラネット、ＬＡＮとＷＡＮ、ないし望む所のそれらのどの組み合わせをも含む多様なネットワークのどれにでも適用できる。更に本発明は、多様なコンピュータープラットフォーム、通信プロトコル、ポータブル文書フォーマットないし望まれるそれらのどの組み合わせにも適用できる。本発明は、広範なネットワークでの安全な文書送付のための方法とシステムを提供する。文書デリバリーサーバーが、文書の対象受信者のパブリックキーを動的に検索した後、パブリックキーを使って文書ないし文書のシークレットキーを暗号化する。サーバーは、広範なネットワーク、例えばインターネットで対象受信者に暗号化された文書を送付する。対象受信者は、パブリックキーに関連するプライベートキーを使い文書を解読する。本発明は、対象受信者にのみ特定の文書へのアクセスを許し、それ故文書送付のために独自のレベルの機密保護を提供する。
【００７０】本発明の目的のため、文書なる用語は、同一限界内のデータ集合なら全てを含んでおり、データストリーム、ビデオ、音声データ、アニメーション、ＨＴＭＬ・ＰＤＦ・Ｅｎｖｏｙといったフォーマット化された文書、ないしデータベースが含まれる。本発明の好適実施例がインターネットでの文書送信の使用に適応している一方、本発明は、他の広範なネットワークにも同等に適用できる。更に、本発明の好適実施例が受信者コンピューターへの文書送信を開示する一方、本発明は、プライベートキー／パブリックキーを動的に生成しかつプライベートキーを使って対応するパブリックキーで暗号化された文書を解読する能力を維持ないし有するどんな対象受信者に対して、文書送信を作動させることができる。それ故対象受信者として、例えば、デスクトップコンピューター、ファックス機、パーソナルデジタルアシスタントないしネットワークコンピューター装置のインターネットユーザーが含まれる。
【００７１】同様に、文書送信者はデスクトップコンピューターであるのが好ましい一方、送信者として、ネットワークコンピューター装置の様な文書暗号化できデリバリーサーバーと通信できる装置が含まれる。本発明の代替実施例では、文書をデリバリーサーバーにより暗号化する。この実施例では、送信者として、インターネットブラウザ装置、インターネット電話装置、パーソナルデジタルアシスタントないしファックス機といった、暗号化と対象受信者への送信のためにデリバリーサーバーへ文書を伝送できる装置なら何でも含まれる。図２３は、本発明の第一好適実施例による動的サーバー文書暗号化システムの図である。デスクトップコンピューターに記憶された文書を送信者１０３２は、もう一つのコンピューター、対象受信者１０３４に送信する。この第一好適実施例で文書は、ポータブル文書フォーマット（ＰＤＦ）で記憶される。しかし代替実施例では、文書は、どの適切なフォーマットで記憶されてもよい。ポータブル文書（ＰＤ）のフォーマットが、配布されたプリントとファックス解決策に必要となる。しかし、本発明にＰＤフォーマットは必要でない。
【００７２】文書は、デリバリーサーバー１０３６を経て送信者から受信者に送られる。本発明のこの第一好適実施例の場合、デリバリーサーバーは、対象受信者のパブリックキー（証明）を検索するために証明許可データベースサーバー１０３８と通信するよう、送信者により指示される。デリバリーサーバーは、証明元へ動的に照会し、パブリックキーを検索する。パブリックキーはデリバリーサーバーへ送信され、そこから送信者に送信される。本発明の代替実施例において、デリバリーサーバーは、対象受信者のデスクトップコンピューター、インターネットサーバー、ないし対象受信者のデスクトップコンピューターに接続されたイントラネットサーバーから、対象受信者のパブリックキーを検索する。本発明の第一好適実施例において、送信者は、シークレットキーを使用して文書を暗号化し、パブリックキーを使ってシークレットキーを暗号化する。文書と暗号化されたシークレットキーは、次に対象受信者に送信される。シークレットキーが、対象受信者のプライベートキーで解読された後、文書を解読するのに使用される。
【００７３】代替の同等好適実施例として、送信者は、パブリックキーを使って文書を暗号化する。暗号化された文書は対象受信者に送信され、パブリックキーに関連したプライベートキーを使って解読される。図２４は、本発明の第一好適実施例による動的サーバー文書暗号化のための操作セットのフローチャートである。本例では、１０４０のステップで、送信者はシークレットキーを使って文書を暗号化する。こうしたシークレットキーには、先行技術で知られているどんな適切な暗号化スキームも含まれる。１０４５のステップで、送信者はデリバリーサーバーと交信し、１０５０のステップで、対象受信者に関連したパブリックキーについてに照会する。１０５５のステップで、デリバリーサーバーは、例えばこの証明をリアルタイムで証明元のデータベースから検索し、１０６０のステップで、送信者に証明を送信する。
【００７４】最終的に証明元が証明を返してこない場合、デリバリーサーバーが、受信者に新しい証明を動的に生成する。こうすることで、デリバリーサーバーは、動的に作られたＵＲＬをＥ−メールメッセージに入れ受信者へ送る。受信者がＵＲＬにアクセスすると、ジャバアプレットないしプラグインが検索され、受信者のシステムに自動的にダウンロードされる。このアプレットないしプラグインは次に受信者システム上で作動し、一対のプライベート／パブリックキーを作成する。一対のプライベート／パブリックキーをローカルマシンで生成することは、本発明に固有なことではなく、多くの出典で述べられている。アプレットないしプラグインは、次にパブリックキーをデリバリーサーバーへ送る。サーバーは、作成されたＵＲＬのプロパティを使い、受信者のＥーメールアドレスを確認する。こうして、生成されたパブリックキーは、受信者の電子メールアドレスを認証済みとしたプロパティを有する、何故ならキー生成を呼び出すＵＲＬは特定の電子メールアドレスに送られただけだから。サーバーは、電子メールアドレスとパブリックキーを結合させて証明とし、この証明は送信クライアントへ戻されるか、ないし、文書又はシークレットキーを暗号化するためにサーバーにより使用される。デリバリーサーバーは、ＬＤＡＰないし類似のプロトコルを使って、証明を証明元に伝達する。代替案として、ローカルデータベースないし動的に生成された証明を、デリバリーサーバーは将来の使用のために単に維持してもよい。
【００７５】デリバリーサーバーからパブリックキーを受信すると、送信者はパブリックキーでシークレットキー６５を暗号化する。本発明の代替同等好適実施例では、送信者は、パブリックキーを受信するまで文書を暗号化しない。何故ならパブリックキーが認証されなければ文書は暗号化されないからであり、この実施例は、パブリックキーが検索できない時の処理時間を最小にする。次にスッテプ１０７０で、送信者は、暗号化された文書、対象受信者アドレス（例えば電子メールアドレス）、送付指示、暗号化されたシークレットキーを安全なチャンネルで、デリバリーサーバーへ送る。こうして、文書がシークレットキーで暗号化され、シークレットキーが対象受信者のパブリックキーで暗号化されるまで、文書は送信者から離れることがない。次にスッテプ１０７５で、デリバリーサーバーは、暗号化された文書とシークレットキーを対象受信者に送付する。スッテプ１０８０で、対象受信者はパブリックキーに関連したプライベートキーを使ってシークレットキーを解読し、シークレットキーを使って文書を解読する。こうしたスキームは、文書にアクセスできるのはパブリックキーの所有者のみだから、文書への認められていないアクセスを防ぐことになる。
【００７６】図２５は、本発明の代替実施例による、動的サーバー文書暗号化のための操作セットのフローチャートである。ステップ１０９０で、送信者は所定の受信者に文書を送りたい旨をデリバリーサーバーに通知する。ステップ１０９５で、デリバリーサーバーは、対象受信者のパブリックキーを得るべく証明元に照会し、ステップ１１００で、パブリックキーがデリバリーサーバーに戻される。この実施例では、送信者は文書を暗号化せずに、ステップ１１０５で安全なチャンネルでデリバリーサーバーへ文書を送る。次にステップ１１１０で、デリバリーサーバーは、シークレットキーを使い文書を暗号化する。ステップ１１１５で、デリバリーサーバーは、対象受信者から検索したパブリックキーを使ってシークレットキーを暗号化し、次のステップ１１２０で、暗号化された文書とシークレットキーを対象受信者に送る。ステップ１１２５で、対象受信者はプライベートキーを使ってシークレットを解読後、シークレットキーを使い文書を解読する。
【００７７】代替案として、デリバリーサーバーは、パブリックキーを使って文書を暗号化してもよい。暗号化された文書は、次に受信者に送信される。本発明の好適実行例では、送信者は、広範なネットワーク例えばインターネットで作動する全てのデリバリーサーバーを経由して、対象受信者に接続される。送信者は、本文中でセンドクライアントと呼ぶソフトウエアを使用したコンピューターであるのが望ましい。デリバリーサーバーは、所定の受信者のパブリックキーを決定し、そのキーをセンドクライアントに送る責任を果たす。デリバリーサーバーは更に、暗号化された文書とシークレットキーを対象受信者に送付する責任を果たす。センドクライアントは、送付される文書、全デリバリーパラメーター、文書を受信する対象受信者セットをまず識別することで、デリバリートランザクションを始める。デリバリーパラメーターは、予定送付時間、機密保護オプション、送付の緊急性、送付のための提示パラメーター及び受取通知といったオプションを含む。
【００７８】センドクライアントは次にデリバリーサーバーと対話を開始し、シークレットキーで文書を暗号化する。対話と暗号化の段階は、送信者のハードウエア及びソフトウエア構成次第で、同時ないし順番で実行される。対話において、センドクライアントは、所定文書の対象受信者にデリバリーサーバーを送る。ひとたびパブリックキーが取得されると、センドクライアントは、デリバリーサーバーが送信クライアントと交信するよう要求する。センドクライアントは、所定の文書の対象受信者の身元を様々な方法で表現する。本発明の好適実施例において、センドクライアントは、対象受信者の電子メールアドレスを対象受信者の識別子として使用する。しかし、センドクライアントは、代替識別子、例えば運転免許証番号、社会保障番号、抽象識別子、シンボルネームないしファックス番号で、対象受信者を確認できる。
【００７９】デリバリーサーバーは、幾つか技術を使って対象受信者の証明を得る。本発明の好適実施例においては、デリバリーサーバーは、証明元のデータベースサーバーと交信し、対象受信者を確認する情報を示し、対象受信者のパブリックキーを要求する。それ故本発明を使用し、リアルタイムで（照会される）プログラムインターフェースを通して動的にアクセスできるパブリックキーデータベースを維持している証明元から情報を得てもよい。本発明は、ユーザーを介在させずリアルタイムで対象受信者のパブリックキーを照会するデリバリーサーバーに適切などんな手段でも実行される。この様に、特定のプロトコルとパブリックキーデータベースにアクセスする手段は、本発明にとって重要ではない。パブリックキーデータベースへのアクセスには、インターネット技術タスクフォースと合同でミシガン大学が開発したインターネットライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）基準を使うのが好ましい。ＬＤＡＰサーバーは、ディレクトリと他のサービスを提供する。ＬＤＡＰプロトコルを使えば、所定のサーバーの照会、サーバーに維持されている情報の電子ネットワークでの検索ができる。ＬＤＡＰサーバーへの直接照会が、標準インターネットプロトコルを使って可能である。本発明の代替実施例では、例えば、ＰＲＣ（遠隔手続き呼び出し）を始めとする様々なコネクティビティプロトコルを持つＳＱＬ照会を使う。
【００８０】証明元のデータベースサーバーとデリバリーサーバーは、同一サーバー、別のサーバーのいずれであっても良い。証明元のデータベースとデリバリーサーバーの両方を同じサーバーに維持することは、証明の汎用データベースにアクセスする必要がない文書送付専用アプリケーションにとって有利である。例えば、会社は、インターネット通信に使われる同一サーバー上に従業員のパブリックキーのデータベースを維持してもよい。それ故同じサーバーが、証明元のデータベースとして又社内の事務所間通信のデリバリーサーバーとして使われる。証明元のデータベースサーバーとデリバリーサーバーが別々である実施例においては、デリバリーサーバーは、最新の照会された証明のキャッシュ或いはローカルコピーを維持してもよい。こうしてキャッシュを使うと、同じ受信者と証明を将来照会する際に時間削減となる。
【００８１】本発明は、一人以上の受信者への文書送付を支援する。複数の受信者には、上記で論議したプロセスを、バッチモードで適用する。対象受信者を整理したリストがデリバリーサーバーに送られ、デリバリーサーバーは対応する証明の整理済みリストを回答する。本発明は、送信者から受信者への複数文書送信に使ってもよい。その場合、単一シークレットキーを使って各文書を暗号化する。ひとたび、個々の受信者のパブリックキーを含む証明をデリバリーサーバーが戻すと、単一シークレットキーは、対象受信者の検索されたパブリックキーで暗号化される。各受信者に対し、センドクライアントは、暗号化されたシークレットキーと暗号化された文書を、対象受信者のアドレスとデリバリーパラメーターと共に、デリバリーサーバーに送る。
【００８２】デリバリーサーバーは次に、組み合わされ暗号化されたシークレットキーと文書を各受信者に送る。受信装置は、レシーブクライアントとして知られているソフトウエアを使用する。レシーブクライアントは、標準インターネットブラウザへのプラグイン同様、ジャバアプレットとして現在実行されている。ジャバは、カリフォルニア州マウンテンビューのサンマイクロシステム社が開発したプログラミング言語である。しかし、レシーブクライアントは、送信されたシークレットキーと文書を受信かつ解読できるプログラミング言語でなら他の言語を使用しても実行できる。レシーブクライアントは、ジャバアプレットとして実行される場合、デリバリーサーバーから対象受信者のシステムへ動的に配布される。レシーブクライアントは、プライベートキーを使ってシークレットキーを解読する。この解読されたシークレットキーを受信者が使い、文書を解読する。
【００８３】この発明の好適実施例において、レシーブクライアントは、ハイパーテキストトラスミションプロトコル（ＨＴＴＰ）、即ち、標準インターネットデリバリープロトコルを使って、デリバリーサーバーからの暗号化されたシークレットキーと文書にアクセスする。しかし、レシーブクライアントは他の適切なプロトコルを使用してデリバリーサーバーにアクセスしてもよい。ＨＴＴＰ使う場合、レシーブクライアントは、文書のアドレスと送付さるべき鍵を含むユニフォームリソースロケータ（ＵＲＬ）を送信される。本発明の好適実施例において、文書とシークレットキーは、単一ファイルないしデータストリーム中にまとめられ、ＨＴＴＰを使用するレシーブクライアントにそのまま手つかずの形で送付される。こうして、レシーブクライアントは最大の柔軟性を与えられ、パッケージを検索してそれを受信者ウエブブラウザから解読する。受信者は、どんなウエブブラウザをもあるいは広範なネットワークで送信されたデータを受信できる他のソフトウエアアプリケーションを使用してよい。
【００８４】本発明を、好適実施例に関連してここに述べているが、当業者は、他の応用が本発明の範囲から外れることなくここで述べられている応用に代り得ることを難なく認めるであろう。センドクライアント、レシーブクライアント、及びデリバリーサーバーソフトウエアのソースコードは、周知のプログラミング技術とハードウエアコンポーネントを使用する当業者なら難なく作れる。加えて、レシーブクライアントとデリバリーサーバーの機能も、集積回路、ＥＥＰＲＯＭといったプログラミング可能な記憶装置を始めとする他の手段によって成し遂げることができる。本発明の好適実施例に関して上記で論議した動的サーバー文書暗号化の実行は、可能な実行の一つにすぎない。代替実施例は、本発明の教示と一致する他の実行を使ってもよい。
【００８５】レシーブクライアントは、文書を別の装置に向けるように構成してもよい。例えば、解読された文書をプリンターないしファクス機に送信してもよい。本発明では、ＲＳＡ法、ベリサイン法を始めとする適切などんな暗号化スキームをも、シークレットキー、パブリックキー、プライベートキーのために使用してよい。本発明は、特別の好適実施例に関して詳細を述べているが、この発明に関係する当業者は、先の請求項の精神と範囲から離れることなく様々な変更修正と改良ができることを認めるであろう。
【図面の簡単な説明】
【図１】先行技術によるシークレットキー暗号化方式を示す。
【図２】先行技術によるパブリックキー暗号化方式を示す。
【図３】図３は、バイナリーファイルサーバーを一台使うバイナリーファイルデリバリーシステムを示す。
【図４】ファイルサーバーを二台使うバイナリーファイルデリバリーシステムを示す。
【図５】ストア項目のキー要素を示すブロック図である。
【図６】バイナリーファイルデリバリーサーバーの概略図である。
【図７】バイナリーファイルサーバーの一実施例の構造の例を示す。
【図８】バイナリーファイルデリバリーサーバーが使う異なる型のストアイベントを示す。
【図９】バイナリーファイルデリバリーサーバー構造内の特定コンポーネントのブロック図である。
【図１０】ストアの構造を示すブロック図である。
【図１１】インターネットのクライアントをセッション、トランザクション、トランスポートを含む三層にユーザーセッションがどう組織化するかを示す。
【図１２】送信セッションがストア項目を作成した後ないし別のサーバーがストア項目を送っている際の、送信の非対話タスクを示す。
【図１３】アカウントマネージャーの詳細構造を示す。
【図１４】ロガーの詳細構造を提供する。
【図１５】サーバーコネクターの詳細構造を提供する。
【図１６】ポータブル文書デリバリーサーバー一台を使うポータブル文書デリバリーシステムの機能ブロック図を示す。
【図１７】ポータブル文書デリバリーサーバー二台を使うポータブル文書デリバリーシステムの機能ブロック図を示す。
【図１８】ポータブル文書送信クライアントアプリケーションとポータブル文書受信クライアントアプリケーションが、本発明でどう使われるかを示す。
【図１９】サーバーコンフィギュレイションユーザーインターフェースアプリケーションが本発明でどう使われるかを示す。
【図２０】サーバーのファックスゲートウエイにより文書がプリンターへどう送られるかを示す。
【図２１】専用コーポレートサーバーのデパートメントゲートウエイにより文書がＬＡＮを通してデパートメントプリンターへどう送られるかを示す。
【図２２】本発明による指示された文書送付に関するプライベートかつ追跡可能なＵＲＬｓを含む文書デリバリーシステムを示すブロック図である。
【図２３】本発明の第一好適実施例による動的サーバー文書暗号化方法を示す図である。
【図２４】本発明の第一好適実施例による動的サーバー文書暗号化のための動作セットのフローチャートである。
【図２５】本発明の代替実施例による動的サーバー文書暗号化のための動作セットのフローチャートである。
【符号の説明】
３００ 送信者
３１０ 文書
３１５ サーバー
３２０ 受信者（パソコン）
３２５ ＰＵＲＬの通知
３３０ ＰＵＲＬ経由の検索
３０２ ＰＵＲＬ（プライベートユニフォームリソースロケーター）
３３１ パスワード識別子
３３２ ストア項目識別子
３３３ 受信者識別子
３３４ 文書キー
３３５ オプションフィールド
【特許請求の範囲】
【請求項１】 送信コンピューターと受信コンピューター間で電子文書を送付する装置において、前記送信コンピューターと前記受信コンピューター間に設置されたサーバーを有し、前記電子文書が前記コンピューターから前記サーバーへ送られ、前記サーバーがプライーベートなユニフォームリソースロケータ（「ＰＵＲＬ」）を動的に生成し前記電子文書を配布することを特徴とするサーバーを含む装置。
【請求項２】前記ＰＵＲＬが、前記電子文書の対象受信者と、前記電子文書の送付に特有な他の自由選択のパラメーターとを独自に確認することを特徴とする請求項１に記載の装置。
【請求項３】 前記電子文書の前記対象受信者が、前記ＰＵＲＬを使って前記電子文書を検索するのを特徴とする請求項２に記載の装置。
【請求項４】 前記サーバーが前記電子文書の検索時に、前記ＰＵＲＬに含まれる属性に基づいて前記検索の挙動をカスタマイズし、データベースの前記検索に関連するログ情報を自由選択でカスタマイズして、安全な文書送付と文書受信の追跡を可能にすることを特徴とする請求項３に記載の装置。
【請求項５】 前記のサーバーが、前記電子文書を送付するためのＨＴＴＰと、前記電子文書の前記サーバーへの到着を通知するためのＳＭＴＰ／電子メールとを使うことを特徴とする請求項１に記載の装置。
【請求項６】 前記ＵＲＬが、前記電子文書の対象受信者を独自に確認する一時的かつ動的に生成されたＵＲＬと、自由選択の前記電子文書自身と、前記電子文書に関連する自由選択の属性とを含むことを特徴とする請求項１に記載の装置。
【請求項７】 前期ＰＵＲＬが、送信される電子文書に汎用参照番号を付して、受信者が前記参照番号を経て前記電子文書にアクセスするのを可能にするのを特徴とする請求項１に記載の装置。
【請求項８】 前記受信者が前記参照番号を使用して前記文書にアクセスした時に、前記サーバーが、前記電子文書にアクセスする要求を傍受し、前記アクセスに関連して付加価値のあるサービスを提供することを特徴とする請求項７に記載の装置。
【請求項９】 前記ＰＵＲＬが、前記サーバーの文書のロックを解除するキーを更に含むことを特徴とする請求項１に記載の装置。
【請求項１０】 前記ＰＵＲＬが、前記電子文書の受信者を確認する独自の登録番号を更に含むことを特徴とする請求項１に記載の装置。
【請求項１１】 前記サーバーが、特定の個人が特定の文書にアクセスしたことに気付き、データベースにアクセスのあったことを記して文書追跡を提供することを特徴とする請求項１０に記載の装置。
【請求項１２】 送信者と少なくとも一人の受信者の間で電子文書を送付するための文書デリバリーシステムにおいて、前記電子文書を一時的に記憶する文書サーバーを有し、前記サーバーは、前記文書が送られる各対象受信者のためにプライベートかつ追跡可能なＵＲＬ（「ＰＵＲＬ」）を動的に作成することを特徴とする文書デリバリーシステムシステム。
【請求項１３】 前記サーバーが、デリバリーパラメーターないし前記ＰＵＲＬのトランザクション識別子を暗号化することを特徴とする請求項１２に記載のシステム。
【請求項１４】 前記ＰＵＲＬが、Ｅ−メールメッセージを有することを特徴とする請求項１２に記載のシステム。
【請求項１５】 前記受信者が、前記ＰＵＲＬを前記サーバーに示すことにより前記ＰＵＲＬを経て前記電子文書にアクセスすることを特徴とする請求項１２のシステム。
【請求項１６】 パスワードを示してからでないと前記ＰＵＲＬの参照符の付された電子文書にはアクセスできない旨を前記ＰＵＲＬが記すよう、前記サーバーが要求することを特徴とする請求項１５に記載のシステム。
【請求項１７】 前記サーバーが、前記ＰＵＲＬで前記電子文書にアクセスする特定の受信者を確認することを特徴とする請求項１５に記載のシステム。
【請求項１８】 前記サーバーが、特定の受信者が特定の文書にアクセスを試みた事実を記録することを特徴とする請求項１７に記載のシステム。
【請求項１９】 前記サーバーが、全ての電子文書が首尾よく送付された事実を記録することを特徴とする請求項１７に記載のシステム。
【請求項２０】 誰が前記電子文書にアクセスしたか、いつ文書にアクセスしたか、及び前記電子文書に首尾よくアクセスしたか否かのいずれをも述べた完全な記録を所有する前記サーバー上に維持させたないし関連させたデータベースを更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２１】 前記サーバーの記録した情報が、電子文書の送信者に報告されることを特徴とする請求項２０に記載のシステム。
【請求項２２】 前記サーバーが、文書を検索する所定の受信者に関連した全ＩＰアドレス、前記同一ＰＵＲＬで所定の文書へ引き続いてなされた全アクセスのＩＰアドレス、ないし特定の受信者を目的とした特定の文書にアクセスしたＩＰアドレスを含むリストのいずれかを記録できることを特徴とする請求項１２に記載のシステム。
【請求項２３】 受信者が前記電子文書にアクセスし解読するための有効キーを示すまで前記電子文書が前記サーバー上で暗号化されたままであり、前記キーが前記ＰＵＲＬの部分中に暗号化されて示されることを特徴とする請求項１２に記載のシステム。
【請求項２４】 前記ＰＵＲＬが、キーが検索されなければならないことを記し、前記サーバーが受信者は前記電子文書を解読するための独自のパスワードを示すよう要求することを特徴とする請求項１２に記載のシステム。
【請求項２５】 前記ＰＵＲＬが、パスワードが所定の文書にアクセスするのに必要か否かを記すパスワード識別子を更に含むことを特徴とする請求項１２に記載の装置。
【請求項２６】 前記ＰＵＲＬが、所定の受信者がどの文書を得たいのかを独自に確認するストア項目識別子を更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２７】 前記ＰＵＲＬが、所定の文書の対象受信者を独自に確認する受信者識別子を更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２８】 前記ＰＵＲＬが、前記ＰＵＲＬ自体を有効にする文書キーを更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２９】 前記文書キーが、所定の受信者に関連して無作為に生成された番号であるキーと所定の受信者が得たい文書を更に含み、前記キーが、所定の受信者確認番号が有効か否か、所定のストア確認番号が有効か否か、及び所定のストア確認番号を有する所定の受信者が文書へのアクセスするのを承認すべきか否かを確認するため使われることを特徴とする請求項２８に記載のシステム。
【請求項３０】 電子文書を送信者と少なくとも一人の受信者の間で送付する方法において、前記電子文書を一時的に保管するため文書サーバーを使い、前記サーバーが、前記文書が送られる各対象受信者のためにプライベートかつ追跡可能なＵＲＬ（「ＰＵＲＬ」）を動的に生成するステップと、前記ＰＵＲＬをそのコンポーネントの部分に解読するステップと、前記ＰＵＲＬの各コンポーネントの部分を有効にするステップを含むことを特徴とする方法。
【請求項３１】 キーを使用してＰＵＲＬを認証する段階を更に含むことを特徴とする請求項３０に記載の方法。
【請求項３２】 どのユーザーが文書にアクセスしているかを、所定の文書の対象受信者を独自に確認する受信者識別子を使って決定する段階を更に含むことを特徴とする請求項３１に記載の方法。
【請求項３３】 どの文書にユーザーがアクセスするかを、どの文書を所定の受信者が得たいかを独自に確認するストア項目識別子を使って決定する段階を更に含むことを特徴とする請求項３２に記載の方法。
【請求項３４】 前記文書が、送付される前に追加入力を要求するか否かを決定する段階を更に含むことを特徴とする請求項３３に記載の方法。
【請求項３５】 前記文書を前記受信者に送付する段階を更に含むことを特徴とする請求項３５に記載の方法。
【請求項３６】 アクセスの時間、送信の成功、及び受信者のＩＰのいずれをも含むデリバリートランザクションの属性全てを記録する段階を更に含むことを特徴とする請求項３１に記載の方法。
【請求項３７】 広範なネットワークで送信者から安全な送付文書をするための方法において、送信者がシークレットキーを使って文書を暗号化するステップと、送信者がデリバリーサーバーに交信し対象受信者に関連するパブリックキーを照会するステップと、デリバリーサーバーがリアルタイムでパブリックキーを動的に検索するステップと、デリバリーサーバーが送信者にパブリックキーを送信するステップと、送信者がパブリックキーでシークレットキーを暗号化するステップと、送信者が暗号化された文書と暗号化されたシークレットキーを受信者への送信用デリバリーサーバーに送信するステップとを含むことを特徴とする方法。
【請求項３８】 受信者がプライベートキーを使用してシークレットキーを解読する段階を更に含むことを特徴とする請求項３７に記載の方法。
【請求項３９】 受信者がシークレットキーを使って文書を解読する段階を更に含むことを特徴とする請求項３８に記載の方法。
【請求項４０】 送信者が、デリバリーサーバーからパブリックキーを受け取る前に文書を暗号化することを特徴とする請求項３７に記載の方法。
【請求項４１】 送信者が、デリバリーサーバーからパブリックキーを受信するのに続いて文書を暗号化することを特徴とする請求項３７に記載の方法。
【請求項４２】 文書が、データの同一限界内のデータ集合、データストリーム、ビデオ、音声データ、アニメーション、フォーマット化された文書ないしデータベースのいずれかであることを特徴とする請求項３７に記載の方法。
【請求項４３】 送信者が、対象受信者のアドレスと文書送付の指示をデリバリーサーバーに送るステップを更に含むことを特徴とする請求項３７に記載の方法。
【請求項４４】 広範なネットワークがインターネットであることを特徴とする請求項３７に記載の方法。
【請求項４５】 受信者が、デスクトップコンピューター、プリンター、ファックス機、パーソナルデジタルアシスタントないしネットワークコンピューター装置のいずれかであることを特徴とする請求項３７に記載の方法。
【請求項４６】 送信者が、デスクトップコンピューター、インターネットブラウザ装置、インターネット電話装置或いはネットワークコンピューター装置のいずれかであることを特徴とする請求項３７に記載の方法。
【請求項４７】 データベースサーバーが、証明元、インターネットサーバー、パーソナルデジタルアシスタント、ないし対象受信者のデスクトップコンピューターのいずれか、ないし対象受信者のデスクトップコンピューターに接続されたイントラネットサーバーからパブリックキーを動的に検索することを特徴とする請求項３７に記載の方法。
【請求項４８】 広範なネットワークで送信者からの安全な文書送付をするための方法において、送信者がデリバリーサーバーに交信し文書の対象受信者に関連したパブリックキーを照会するステップと、デリバリーサーバーがリアルタイムでパブリックキーを動的に検索するステップと、デリバリーサーバーが送信者にパブリックキーを送信するステップと、送信者がパブリックキーで文書を暗号化するステップと、送信者が受信者への送信のためにデリバリーサーバーへ暗号化された文書を送信するステップとを含むことを特徴とする方法。
【請求項４９】 受信者が、プライベートキーを使用して文書を解読するステップを更に含むことを特徴とする請求項４８に記載の方法。
【請求項５０】 受信者が、デスクトップコンピューター、プリンター、ファックス機、パーソナルデジタルアシスタントないしネットワークコンピューター装置のいずれかであることを特徴とする請求項４８に記載の方法。
【請求項５１】 送信者が、デスクトップコンピューター、インターネットブラウザ装置、インターネット電話装置ないしネットワークコンピューター装置のいずれかであることを特徴とする請求項４８に記載の方法。
【請求項５２】 データベースサーバーが、証明元、インターネットサーバー、パーソナルデジタルアシスタント、対象受信者のデスクトップコンピューターのいずれか、ないし対象受信者のデスクトップコンピューターに接続されたイントラネットサーバーからパブリックキーを動的に検索することを特徴とする請求項４８に記載の方法。
【請求項５３】 広範なネットワークで送信者からの安全な文書送付するための方法において、送信者がデリバリーサーバーに交信し対象受信者に関連したパブリックキーを照会するステップと、デリバリーサーバーがリアルタイムでパブリックキーを動的に検索するステップと、送信者が文書をデリバリーサーバーに送信するステップと、デリバリーサーバーがシークレットキーで文書を暗号化しかつパブリックキーでシークレットキーを暗号化するステップと、デリバリーサーバーが暗号化されたシークレットキーと暗号化された文書を対象受信者に送信するステップを含むことを特徴とする方法。
【請求項５４】 受信者が、プライベートキーを使用してシークレットキーを解読する段階を更に含むことを特徴とする請求項５３に記載の方法。
【請求項５５】 受信者が、シークレットキーを使用して文書を解読する段階を更に含むことを特徴とする請求項５４に記載の方法。
【請求項５６】 受信者が、デスクトップコンピューター、プリンター、ファックス機、パーソナルデジタルアシスタントないしネットワークコンピューター装置のいずれかであることを特徴とする請求項５３に記載の方法。
【請求項５７】 送信者が、デスクトップコンピューター、ネットワークコンピューター装置、インターネットブラウザ装置、インターネット電話装置ないしファックス機のいずれかであることを特徴とする請求項５３に記載の方法。
【請求項５８】 データベースサーバーが、証明元、インターネットサーバー、パーソナルデジタルアシスタント、指定された受信者のデスクトップコンピューターのいずれかから、ないし対象受信者のデスクトップコンピューターに接続されたイントラネットサーバーからパブリックキーを動的に検索することを特徴とする請求項５３に記載の方法。
【請求項５９】 前記受信者が前記検索時にパブリックキーを持っていない場合、前記デリバリーサーバーでパブリックキーを動的に生成する段階を更に含むことを特徴とする請求項５３に記載の方法。
【請求項６０】 前記動的生成ステップが、メッセージを前記受信者に送るステップを更に含み、当該メッセージの読み込みに当って前記受信者のシステム上でプライベート／パブリックキー一対を作成するモジュールを検索することを特徴とする請求項５９に記載の方法。
【請求項６１】 前記動的生成ステップが、前記パブリックキーを前記受信者のシステムから前記デリバリーサーバーへ送るステップを更に含むことを特徴とする請求項６０に記載の方法。
【請求項６２】 広範なネットワークで送信者からの安全な文書送付をするためのシステムにおいて、対象受信者に関連したパブリックキーを送信者の指示で照会しかつリアルタイムでパブリックキーを動的に検索してパブリックキーを送信者に逆送信するデリバリーサーバーと、シークレットキーを使用して文書を暗号化しかつパブリックキーでシークレットキーを暗号化しかつ暗号化された文書と暗号化されたシークレットキーを対象受信者への送信のためデリバリーサーバーへ送信する送信者とを含むことを特徴とするシステム。
【請求項６３】 プライベートキーを使う受信者がシークレットキーを解読するための手段と、シークレットキーを使って暗号化された文書を解読するための手段とを更に含むことを特徴とする請求項６２に記載のシステム。
【請求項１】 送信コンピューターと受信コンピューター間で電子文書を送付する装置において、前記送信コンピューターと前記受信コンピューター間に設置されたサーバーを有し、前記電子文書が前記コンピューターから前記サーバーへ送られ、前記サーバーがプライーベートなユニフォームリソースロケータ（「ＰＵＲＬ」）を動的に生成し前記電子文書を配布することを特徴とするサーバーを含む装置。
【請求項２】前記ＰＵＲＬが、前記電子文書の対象受信者と、前記電子文書の送付に特有な他の自由選択のパラメーターとを独自に確認することを特徴とする請求項１に記載の装置。
【請求項３】 前記電子文書の前記対象受信者が、前記ＰＵＲＬを使って前記電子文書を検索するのを特徴とする請求項２に記載の装置。
【請求項４】 前記サーバーが前記電子文書の検索時に、前記ＰＵＲＬに含まれる属性に基づいて前記検索の挙動をカスタマイズし、データベースの前記検索に関連するログ情報を自由選択でカスタマイズして、安全な文書送付と文書受信の追跡を可能にすることを特徴とする請求項３に記載の装置。
【請求項５】 前記のサーバーが、前記電子文書を送付するためのＨＴＴＰと、前記電子文書の前記サーバーへの到着を通知するためのＳＭＴＰ／電子メールとを使うことを特徴とする請求項１に記載の装置。
【請求項６】 前記ＵＲＬが、前記電子文書の対象受信者を独自に確認する一時的かつ動的に生成されたＵＲＬと、自由選択の前記電子文書自身と、前記電子文書に関連する自由選択の属性とを含むことを特徴とする請求項１に記載の装置。
【請求項７】 前期ＰＵＲＬが、送信される電子文書に汎用参照番号を付して、受信者が前記参照番号を経て前記電子文書にアクセスするのを可能にするのを特徴とする請求項１に記載の装置。
【請求項８】 前記受信者が前記参照番号を使用して前記文書にアクセスした時に、前記サーバーが、前記電子文書にアクセスする要求を傍受し、前記アクセスに関連して付加価値のあるサービスを提供することを特徴とする請求項７に記載の装置。
【請求項９】 前記ＰＵＲＬが、前記サーバーの文書のロックを解除するキーを更に含むことを特徴とする請求項１に記載の装置。
【請求項１０】 前記ＰＵＲＬが、前記電子文書の受信者を確認する独自の登録番号を更に含むことを特徴とする請求項１に記載の装置。
【請求項１１】 前記サーバーが、特定の個人が特定の文書にアクセスしたことに気付き、データベースにアクセスのあったことを記して文書追跡を提供することを特徴とする請求項１０に記載の装置。
【請求項１２】 送信者と少なくとも一人の受信者の間で電子文書を送付するための文書デリバリーシステムにおいて、前記電子文書を一時的に記憶する文書サーバーを有し、前記サーバーは、前記文書が送られる各対象受信者のためにプライベートかつ追跡可能なＵＲＬ（「ＰＵＲＬ」）を動的に作成することを特徴とする文書デリバリーシステムシステム。
【請求項１３】 前記サーバーが、デリバリーパラメーターないし前記ＰＵＲＬのトランザクション識別子を暗号化することを特徴とする請求項１２に記載のシステム。
【請求項１４】 前記ＰＵＲＬが、Ｅ−メールメッセージを有することを特徴とする請求項１２に記載のシステム。
【請求項１５】 前記受信者が、前記ＰＵＲＬを前記サーバーに示すことにより前記ＰＵＲＬを経て前記電子文書にアクセスすることを特徴とする請求項１２のシステム。
【請求項１６】 パスワードを示してからでないと前記ＰＵＲＬの参照符の付された電子文書にはアクセスできない旨を前記ＰＵＲＬが記すよう、前記サーバーが要求することを特徴とする請求項１５に記載のシステム。
【請求項１７】 前記サーバーが、前記ＰＵＲＬで前記電子文書にアクセスする特定の受信者を確認することを特徴とする請求項１５に記載のシステム。
【請求項１８】 前記サーバーが、特定の受信者が特定の文書にアクセスを試みた事実を記録することを特徴とする請求項１７に記載のシステム。
【請求項１９】 前記サーバーが、全ての電子文書が首尾よく送付された事実を記録することを特徴とする請求項１７に記載のシステム。
【請求項２０】 誰が前記電子文書にアクセスしたか、いつ文書にアクセスしたか、及び前記電子文書に首尾よくアクセスしたか否かのいずれをも述べた完全な記録を所有する前記サーバー上に維持させたないし関連させたデータベースを更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２１】 前記サーバーの記録した情報が、電子文書の送信者に報告されることを特徴とする請求項２０に記載のシステム。
【請求項２２】 前記サーバーが、文書を検索する所定の受信者に関連した全ＩＰアドレス、前記同一ＰＵＲＬで所定の文書へ引き続いてなされた全アクセスのＩＰアドレス、ないし特定の受信者を目的とした特定の文書にアクセスしたＩＰアドレスを含むリストのいずれかを記録できることを特徴とする請求項１２に記載のシステム。
【請求項２３】 受信者が前記電子文書にアクセスし解読するための有効キーを示すまで前記電子文書が前記サーバー上で暗号化されたままであり、前記キーが前記ＰＵＲＬの部分中に暗号化されて示されることを特徴とする請求項１２に記載のシステム。
【請求項２４】 前記ＰＵＲＬが、キーが検索されなければならないことを記し、前記サーバーが受信者は前記電子文書を解読するための独自のパスワードを示すよう要求することを特徴とする請求項１２に記載のシステム。
【請求項２５】 前記ＰＵＲＬが、パスワードが所定の文書にアクセスするのに必要か否かを記すパスワード識別子を更に含むことを特徴とする請求項１２に記載の装置。
【請求項２６】 前記ＰＵＲＬが、所定の受信者がどの文書を得たいのかを独自に確認するストア項目識別子を更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２７】 前記ＰＵＲＬが、所定の文書の対象受信者を独自に確認する受信者識別子を更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２８】 前記ＰＵＲＬが、前記ＰＵＲＬ自体を有効にする文書キーを更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２９】 前記文書キーが、所定の受信者に関連して無作為に生成された番号であるキーと所定の受信者が得たい文書を更に含み、前記キーが、所定の受信者確認番号が有効か否か、所定のストア確認番号が有効か否か、及び所定のストア確認番号を有する所定の受信者が文書へのアクセスするのを承認すべきか否かを確認するため使われることを特徴とする請求項２８に記載のシステム。
【請求項３０】 電子文書を送信者と少なくとも一人の受信者の間で送付する方法において、前記電子文書を一時的に保管するため文書サーバーを使い、前記サーバーが、前記文書が送られる各対象受信者のためにプライベートかつ追跡可能なＵＲＬ（「ＰＵＲＬ」）を動的に生成するステップと、前記ＰＵＲＬをそのコンポーネントの部分に解読するステップと、前記ＰＵＲＬの各コンポーネントの部分を有効にするステップを含むことを特徴とする方法。
【請求項３１】 キーを使用してＰＵＲＬを認証する段階を更に含むことを特徴とする請求項３０に記載の方法。
【請求項３２】 どのユーザーが文書にアクセスしているかを、所定の文書の対象受信者を独自に確認する受信者識別子を使って決定する段階を更に含むことを特徴とする請求項３１に記載の方法。
【請求項３３】 どの文書にユーザーがアクセスするかを、どの文書を所定の受信者が得たいかを独自に確認するストア項目識別子を使って決定する段階を更に含むことを特徴とする請求項３２に記載の方法。
【請求項３４】 前記文書が、送付される前に追加入力を要求するか否かを決定する段階を更に含むことを特徴とする請求項３３に記載の方法。
【請求項３５】 前記文書を前記受信者に送付する段階を更に含むことを特徴とする請求項３５に記載の方法。
【請求項３６】 アクセスの時間、送信の成功、及び受信者のＩＰのいずれをも含むデリバリートランザクションの属性全てを記録する段階を更に含むことを特徴とする請求項３１に記載の方法。
【請求項３７】 広範なネットワークで送信者から安全な送付文書をするための方法において、送信者がシークレットキーを使って文書を暗号化するステップと、送信者がデリバリーサーバーに交信し対象受信者に関連するパブリックキーを照会するステップと、デリバリーサーバーがリアルタイムでパブリックキーを動的に検索するステップと、デリバリーサーバーが送信者にパブリックキーを送信するステップと、送信者がパブリックキーでシークレットキーを暗号化するステップと、送信者が暗号化された文書と暗号化されたシークレットキーを受信者への送信用デリバリーサーバーに送信するステップとを含むことを特徴とする方法。
【請求項３８】 受信者がプライベートキーを使用してシークレットキーを解読する段階を更に含むことを特徴とする請求項３７に記載の方法。
【請求項３９】 受信者がシークレットキーを使って文書を解読する段階を更に含むことを特徴とする請求項３８に記載の方法。
【請求項４０】 送信者が、デリバリーサーバーからパブリックキーを受け取る前に文書を暗号化することを特徴とする請求項３７に記載の方法。
【請求項４１】 送信者が、デリバリーサーバーからパブリックキーを受信するのに続いて文書を暗号化することを特徴とする請求項３７に記載の方法。
【請求項４２】 文書が、データの同一限界内のデータ集合、データストリーム、ビデオ、音声データ、アニメーション、フォーマット化された文書ないしデータベースのいずれかであることを特徴とする請求項３７に記載の方法。
【請求項４３】 送信者が、対象受信者のアドレスと文書送付の指示をデリバリーサーバーに送るステップを更に含むことを特徴とする請求項３７に記載の方法。
【請求項４４】 広範なネットワークがインターネットであることを特徴とする請求項３７に記載の方法。
【請求項４５】 受信者が、デスクトップコンピューター、プリンター、ファックス機、パーソナルデジタルアシスタントないしネットワークコンピューター装置のいずれかであることを特徴とする請求項３７に記載の方法。
【請求項４６】 送信者が、デスクトップコンピューター、インターネットブラウザ装置、インターネット電話装置或いはネットワークコンピューター装置のいずれかであることを特徴とする請求項３７に記載の方法。
【請求項４７】 データベースサーバーが、証明元、インターネットサーバー、パーソナルデジタルアシスタント、ないし対象受信者のデスクトップコンピューターのいずれか、ないし対象受信者のデスクトップコンピューターに接続されたイントラネットサーバーからパブリックキーを動的に検索することを特徴とする請求項３７に記載の方法。
【請求項４８】 広範なネットワークで送信者からの安全な文書送付をするための方法において、送信者がデリバリーサーバーに交信し文書の対象受信者に関連したパブリックキーを照会するステップと、デリバリーサーバーがリアルタイムでパブリックキーを動的に検索するステップと、デリバリーサーバーが送信者にパブリックキーを送信するステップと、送信者がパブリックキーで文書を暗号化するステップと、送信者が受信者への送信のためにデリバリーサーバーへ暗号化された文書を送信するステップとを含むことを特徴とする方法。
【請求項４９】 受信者が、プライベートキーを使用して文書を解読するステップを更に含むことを特徴とする請求項４８に記載の方法。
【請求項５０】 受信者が、デスクトップコンピューター、プリンター、ファックス機、パーソナルデジタルアシスタントないしネットワークコンピューター装置のいずれかであることを特徴とする請求項４８に記載の方法。
【請求項５１】 送信者が、デスクトップコンピューター、インターネットブラウザ装置、インターネット電話装置ないしネットワークコンピューター装置のいずれかであることを特徴とする請求項４８に記載の方法。
【請求項５２】 データベースサーバーが、証明元、インターネットサーバー、パーソナルデジタルアシスタント、対象受信者のデスクトップコンピューターのいずれか、ないし対象受信者のデスクトップコンピューターに接続されたイントラネットサーバーからパブリックキーを動的に検索することを特徴とする請求項４８に記載の方法。
【請求項５３】 広範なネットワークで送信者からの安全な文書送付するための方法において、送信者がデリバリーサーバーに交信し対象受信者に関連したパブリックキーを照会するステップと、デリバリーサーバーがリアルタイムでパブリックキーを動的に検索するステップと、送信者が文書をデリバリーサーバーに送信するステップと、デリバリーサーバーがシークレットキーで文書を暗号化しかつパブリックキーでシークレットキーを暗号化するステップと、デリバリーサーバーが暗号化されたシークレットキーと暗号化された文書を対象受信者に送信するステップを含むことを特徴とする方法。
【請求項５４】 受信者が、プライベートキーを使用してシークレットキーを解読する段階を更に含むことを特徴とする請求項５３に記載の方法。
【請求項５５】 受信者が、シークレットキーを使用して文書を解読する段階を更に含むことを特徴とする請求項５４に記載の方法。
【請求項５６】 受信者が、デスクトップコンピューター、プリンター、ファックス機、パーソナルデジタルアシスタントないしネットワークコンピューター装置のいずれかであることを特徴とする請求項５３に記載の方法。
【請求項５７】 送信者が、デスクトップコンピューター、ネットワークコンピューター装置、インターネットブラウザ装置、インターネット電話装置ないしファックス機のいずれかであることを特徴とする請求項５３に記載の方法。
【請求項５８】 データベースサーバーが、証明元、インターネットサーバー、パーソナルデジタルアシスタント、指定された受信者のデスクトップコンピューターのいずれかから、ないし対象受信者のデスクトップコンピューターに接続されたイントラネットサーバーからパブリックキーを動的に検索することを特徴とする請求項５３に記載の方法。
【請求項５９】 前記受信者が前記検索時にパブリックキーを持っていない場合、前記デリバリーサーバーでパブリックキーを動的に生成する段階を更に含むことを特徴とする請求項５３に記載の方法。
【請求項６０】 前記動的生成ステップが、メッセージを前記受信者に送るステップを更に含み、当該メッセージの読み込みに当って前記受信者のシステム上でプライベート／パブリックキー一対を作成するモジュールを検索することを特徴とする請求項５９に記載の方法。
【請求項６１】 前記動的生成ステップが、前記パブリックキーを前記受信者のシステムから前記デリバリーサーバーへ送るステップを更に含むことを特徴とする請求項６０に記載の方法。
【請求項６２】 広範なネットワークで送信者からの安全な文書送付をするためのシステムにおいて、対象受信者に関連したパブリックキーを送信者の指示で照会しかつリアルタイムでパブリックキーを動的に検索してパブリックキーを送信者に逆送信するデリバリーサーバーと、シークレットキーを使用して文書を暗号化しかつパブリックキーでシークレットキーを暗号化しかつ暗号化された文書と暗号化されたシークレットキーを対象受信者への送信のためデリバリーサーバーへ送信する送信者とを含むことを特徴とするシステム。
【請求項６３】 プライベートキーを使う受信者がシークレットキーを解読するための手段と、シークレットキーを使って暗号化された文書を解読するための手段とを更に含むことを特徴とする請求項６２に記載のシステム。
【図５】
【図１】
【図２】
【図３】
【図４】
【図６】
【図１３】
【図７】
【図８】
【図９】
【図１１】
【図１９】
【図２０】
【図１０】
【図１２】
【図１４】
【図１５】
【図１６】
【図２１】
【図１７】
【図１８】
【図２２】
【図２３】
【図２４】
【図２５】
【図１】
【図２】
【図３】
【図４】
【図６】
【図１３】
【図７】
【図８】
【図９】
【図１１】
【図１９】
【図２０】
【図１０】
【図１２】
【図１４】
【図１５】
【図１６】
【図２１】
【図１７】
【図１８】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開平１１−３１１２７
【公開日】平成１１年（１９９９）２月２日
【国際特許分類】
【外国語出願】有
【出願番号】特願平１０−１２６５７６
【出願日】平成１０年（１９９８）４月１日
【出願人】（５９７１５００４９）タンブルウィード ソフトウェア コーポレイション (1)
【公開日】平成１１年（１９９９）２月２日
【国際特許分類】
【出願番号】特願平１０−１２６５７６
【出願日】平成１０年（１９９８）４月１日
【出願人】（５９７１５００４９）タンブルウィード ソフトウェア コーポレイション (1)
[ Back to top ]