JPH11272594A - 電子ネットワーク上でのドキュメントデリバリ方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】 文書書式を維持しながら電子ネットワーク上
で安全に文書送付する方法と装置を提供し、更に、シス
テムへのアクセスを認められたユーザーだけに制限する
機密保護を提供する。 【解決手段】 文書は、送信クライアントアプリケーシ
ョンを使って送信コンピューターから専用サーバーへ送
信され、専用サーバーは、文書を記憶し電子通知を受信
装置に送り、文書は通知に応じて受信クライアントアプ
リケーションを使って専用サーバーからダウンロードさ
れる。送信クライアントアプリケーションに依ってユー
ザーは、文書デリバリパラメーターを指定することがで
きる。送信者操作証明登録システムとその使用方法も提
供され、送信者は文書を暗号化し安全な方法で受信者に
送信するために使用されるデジタル証明の生成を管理す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の背景】

【０００２】

【発明の属する技術分野】本発明は、電子ネットワーク
上での通信に関する。より詳しくは、インターネットの
様な電子ネットワーク上で、フォーマットされた文書を
安全な方法で送付する方法と装置に関する。更に、本発
明は、電子文書暗号化の分野に関する。より詳しくは、
離れた受信者への電子文書の安全な送付についての技術
に関する。

【０００３】

【従来の技術】インターネットやイントラネットの様な
電子ネットワークは、様々なデータを記憶し配布するた
めに益々使用されるようになってきている。例えば、ワ
ールドワイドウエブ（ウエブ）ページには、テキスト、
グラフ表示、ビデオ表示、アニメーション、音声を含め
ることができる。ウエブは、プラットフォーム、オペレ
イティングシステム、或いは電子メールシステムとは無
関係に受信者が送信者から文書を受信することを可能に
した。文書がコンピューターで受信されずファクシミリ
機或いはインターネットに接続されたネットワーク化さ
れたプリンターで受信される場合でさえもそのような通
信は可能である。多くの場合、文書の送信者は、本文で
イントラネットとよばれるローカルエリアネットワーク
上に在る。送信者のコンピューターは、インターネット
に直接接続されるか或いはイントラネットのサーバーを
通して接続されている。直接インターネットに接続して
いないユーザーは、インターネットの場合にはインター
ネットサービスプロバイダ（ＩＳＰ）と呼ばれるアクセ
スプロバイダのサービスに加入する。

【０００４】ＩＳＰは、そのクライアントをインターネ
ットに接続するネットワークを保守し、そのクライアン
トにホストとして作動するサーバーコンピューターを提
供する。クライアントはモデム付きのコンピューターを
使って公衆電話システムを通してＩＳＰに電話を掛け、
インターネットにアクセスする。ＩＳＰはインターネッ
ト標準ＴＣＰ／ＩＰプロトコルを使って、クライアント
が直接インターネットに通信するポイントツーポイント
（シリアル）のリンクを通常提供する。現在存在する伝
送の枠組みでは、例えばインターネット上で、ある種の
文書を送信するのには適当でない場合が多々ある。重要
な文書は完全な機密保護の下でで送信されなければなら
ない。しかしながら、電子メールシステムの種類が違え
ば、機密保護支援のレベルも違う。それ故、電子通信が
安全かどうか決定するのは難解或いは不可能である。

【０００５】電子通信に機密保護を提供するために、様
々な暗号化スキームが使用されてきた。しかしながら、
暗号化されたメッセージの受信者は、解読スキームを有
するだけでなく、通信を解読するのに十分なハードウエ
アとソフトウエアを持っていなければならない。この様
に、そのような暗号化されたメッセージを送信すること
は、しばしば現実的でなかったり不可能であったりす
る。この様に、ユーザーは文書を電子的に送信するのに
気の進まないことが多い。これらユーザーは、遅くて費
用の掛かるクーリエサービスや、従来の郵便サービスの
方法に頼らざるを得ない。重要な或いは要注意の文書を
追跡して、適切に受信されたと保証できることも望まれ
ている。しかしながら、電子ネットワークに沿って地点
から地点へ文書を追跡することは、不可能でないにして
も、大変難しい。例えば、インターネットを通じて送信
される電子メールメッセージは、多くの別々のデータパ
ケットに分割される。パケットは、インターネットを通
じて宛先の受信者に別々に送信される。各々のパケット
は、再度結合して元の文書を作り上げ受信者に渡す前
に、異なるルートをとる。それ故その様な文書を追跡す
るには、インターネットの各々のリンクを通って各々の
個々のパケットを追跡することが必要となる。

【０００６】加えて、コンピューターは受信された文書
に、例えばパスワードや暗号文であるレベルの機密保護
を提供することはできるが、電子通信は必ずしもコンピ
ューターに向けられるとは限らない。この様に、プリン
ター或いはファクス機に電子的に送信される重要な文書
は、公衆の目に晒される可能性がある。たとえその様な
文書が安全に伝送されたとしても、受信された時点では
判読できない場合もある。電子メールに共通する一つの
問題点は、文書のフォーマットが失われることである。
電子メールによって送信される文書は通常、電子メール
メッセージ本体内のテキスト又はそれへの添付書類の何
れかとして送信される。テキスト文書は通常、元の文書
のフォーマットを維持しない。添付された文書は送信者
と受信者の両方が互換性のあるソフトウエアアプリケー
ションを有する場合の様に、ある環境下ではフォーマッ
トを維持できる。しかしながら、いくつかのフォーマッ
トは、受信者が受信した文書を、作成されたのと同じア
プリケーションを使って開く場合でさえ失われることが
ある。

【０００７】文書のフォーマットが変わるということ
は、深刻な問題を引き起こす。フォーマットが異なる場
合、電子的フォームは互換性がない。間違ってフォーマ
ットされた文書は、受信者には理解できない。多くのフ
ォーマット変化が訂正可能である一方、時間と経費に関
する受信者への負担は重大な問題である。それ故、イン
ターネットの様な電子ネットワーク上で文書を安全に送
付するための方法と装置を提供することは有益なことで
ある。その様な方法と装置が文書の送信と受信を追跡で
きれば更に有益である。そのような方法と装置が送付さ
れた文書のフォーマットを維持できれば又更に有益であ
る。例えばインターネットや他のオンライン発信源から
提供されるコンピューター化された情報源の発達は、電
子的に入手可能な情報の増大につながった。ネットワー
クを通しての情報と文書の安全な配布のために、機密保
護が要望或いは要求され、情報を保護するため様々な設
計と技術が開発されてきた。

【０００８】暗号化は、情報への招かざるアクセスを防
ぐため情報ないし文書にスクランブルをかけるのに使用
される基本技術である。図１は、シークレットキー暗号
化１２１０ａのブロック線図であり、文書１２１２は、
シークレットキー１２１４を使って、暗号化或いはスク
ランブル１２１６をかけられ、暗号化された文書１２２
０になる。暗号化された文書１２２０は次に受信者に送
信される。時に対称キー暗号方式と呼ばれる、シークレ
ットキー暗号化は、招かざるアクセスを防ぐために独自
シークレットキー１２１４を使って情報にスクランブル
をかける技術を使用している。図２は、シークレットキ
ー解読１２１０ｂのブロック線図であり、元の文書１２
１２のコピーを復元するのに、暗号化された文書１２２
０のスクランブル解除１２２２するため、同じ独自シー
クレットキー１２１４が必要となる。シークレットキー
１２１４へのアクセスがなければ、暗号化された文書１
２２０は、不当な干渉から安全に保たれる。

【０００９】シークレットキー暗号化１２１０ａと１２
１０ｂに関する潜在的問題の一つはシークレットキー１
２１４を安全に配布することへの挑戦である。例えば、
送信者が文書１２１２を暗号化するためにシークレット
キー暗号化を使用し、次に受信者に暗号化された文書１
２２０を送信すると仮定する。受信者は、暗号化された
文書１２２０を解読１２２２するためにシークレットキ
ー１２１４を必要とする。シークレットキー１２２２が
安全でないチャンネルで送信されると、機密保護の完全
性が危険に晒される。多くのアプリケーションの場合、
電話ないしファクスはシークレットキー１２１４送付の
十分安全な方法を提供するが、一方、暗号化された文書
１２２０は、ポスタ^TM 文書デリバリシステムを使って
インターネットで送付できる。しかしながら幾つかの例
においては、送信者と受信者はシークレットキー１２１
４の配布により強力かつ便利な手段を必要としている。

【００１０】パブリックキー暗号化は情報を安全に送付
する、より強力、そして一般的により便利な手段を促進
している。パブリックキー暗号化方法では、個々の受信
者がパブリックキーとプライベートキーと呼ばれる一対
のキーを所有する。キーペアーの所有者（受信者）は、
パブリックキーを発行し、プライベートキーを秘密にし
ておく。図３はパブリックキー暗号化１２３０ａのブロ
ック線図であり、文書１３１２は、パブリックキー１３
３２を使用して、暗号化或いはスクランブルをかけられ
１２３４、暗号化された文書１３３６になる。情報を受
信者に送信するために、送信者は、情報を暗号化１２３
４するために対象受信者の発行されたパブリックキー１
３３２を使い、次に受信者は、情報を解読するために自
分自身のプライベートキー１３３４（図４）を使う。従
って、（情報を解読するのに必要な）プライベートキー
１３３４は配布されない。図４はプライベートキー解読
１２３０ｂのブロック線図であり、プライベートキー１
３３４は、暗号化された文書１３３６のスクランブルを
解除１２３８し、元の文書１３１２のコピーを復元する
ために必要とされる。プライベートキー１３３４へのア
クセスがなければ、暗号化された文書１３３６は、不当
な干渉から安全に保たれる。

【００１１】パブリックキー暗号化１２３０ａと１２３
０ｂは通常、パブリックキーとプライベートキー１３３
２、１３３４の間の数理的関係を利用するが、これは、
発行されるパブリックキー１３３２からプライベートキ
ー１３３４を引き出すという危険性無しにパブリックキ
ー１３３２の発行ができるようにする。パブリックキー
暗号化アルゴリズムは一般に難解で、その結果多くのユ
ーザーにとっては、時間が掛かり過ぎ実際の使用ができ
ない。シークレットキー暗号化１２１０ａ、１２１０ｂ
は、パブリックキー暗号化１２３０ａ、１２３０ｂより
も一般にかなり早いが、シークレットキー１２１４を送
信者から受信者へ送信する必要がある。ディジタル封筒
システムにおいては、ユーザーはシークレットキー１２
１４を使って文書１２１２を暗号化し、次に対象受信者
のパブリックキー１３３２を使ってシークレットキー１
２１４を暗号化する。暗号化された文書１２２０の受信
者は、次にシークレットキー１２１４を解読するために
自分のプライベートキー１２４０を使い、文書を解読す
るためにシークレットキー１２１４を使う。

【００１２】文書が送信中に変えられていないかを確認
すること、或いは所定の文書の送受信者を確認すること
がしばしば役に立つ。細かなアルゴリズム（或いはメッ
セージ要覧）及びパブリックキー技術は、文書の完全性
と伝送確認の解決策を促進している。デジタル証明は、
暗号化された情報に対しより高い安全性を提供するため
にも使用可能である。受信者が、パブリック／プライベ
ートキーペアーを所有しており、パブリックキー１３３
２を発行して、他の者が、受信者に送信される情報を暗
号化するか、或いは受信者のデジタルサインを確認する
かの何れかのためにパブリックキー１３３２を使用でき
る様にしたいと希望しているとする。受信者にとってパ
ブリックキー１３３２を発行するのに安全な技術は、信
頼できる機関にパブリックキー１３３２を登録すること
である。すると信頼できる機関は、特定のパブリックキ
ー１３３２がその受信者に属していると証明できる。デ
ジタル証明は、受信者ないし他の存在を特定のパブリッ
クキー１３３２と結び付ける。

【００１３】後に開示する様に、デジタル証明は、パブ
リックキーと身元の記録であり、デジタルサインによっ
て第三者により証明されたその二つの連合である。プラ
イベートキーは、証明にはないが、ただ一つのプライベ
ートキーが所定のパブリックキーと合致する。パブリッ
ク／プライベートキーペアーは、実際には次の特性を持
つ一対の数字である。即ち、プライベートキーは、パブ
リックキーから安易に引き出せない。そしてパブリック
キーは、プライベートキーを知ることによってのみ解読
可能であるデータを暗号化するために使用することがで
きる（ＲＳＡの様な幾つかのパブリックキーアルゴリズ
ムは逆の特性も持っており、これをデジタルサインの使
用に適する様にしている）。

【００１４】信頼できる、ないし証明する機関はデジタ
ル証明を発行し保守する。開示されている先行技術シス
テム及び方法論は、この様に文書の暗号化と安全な送付
に関する方法を提供しているが、送信者によって実行さ
れ制御される簡単なデジタル証明生成と登録システムが
提供できていない。その様なデジタル証明システムの発
達は、主要な技術的進歩を作り出すであろう。

【００１５】

【発明の要約】本発明は電子ネットワーク上で文書を安
全に送付するための方法と装置を提供する。本発明に依
って、ユーザーは、一方で文書の元の書式を維持してな
がら、文書の送信と受信を追跡できるようになる。本文
での論議の目的のために、「文書」という用語は、デー
タストリーム、ビデオデータ、オーディオデータ、アニ
メーション、ＨＴＭＬ或いはＰＤＦ或いはエンボイ文書
の様なプラットフォームに依存せずフォーマットされた
文書、マイクロソフトワード或いはエクセル文書の様な
プラットフォーム特定のフォーマットされた文書、テキ
スト文書の様なフォーマットされていない文書、特注作
成されたレポート或いはウエブページ、ＳＱＬ記録の様
な一つ或いはそれ以上のデータベース記録のグルーピン
グを始めとした、あらゆるデータの連続集合体を含むも
のとする。文書という用語は、一つ或いはそれ以上のそ
の様な文書のグルーピングされたものも含む。本発明の
好適実施例が、インターネット上での文書送信に利用で
きるようになっている一方で、本発明は同様に他の幅広
い分野ないしローカルエリアネットワークにも適用可能
である。

【００１６】本発明の本好適実施例に依ると、ユーザー
が送信コンピューターのデスクトップから電子ネットワ
ーク上で文書を送信可能な送信クライアントアプリケー
ションが提供されている。その様な文書は、文書作成ア
プリケーション内からも送信できる。専用サーバーが、
送信コンピューターから受信された文書を記憶するため
に設けられている。すると、専用サーバーは、文書の送
信を受信者に通知するために電子メッセージを受信装置
に送る。対象受信者は、このメッセージに応じて専用サ
ーバーから記憶された文書をダウンロードする。本発明
の好適実施例では、受信装置はパーソナルコンピュータ
ーである。しかしながら代替例では、受信装置にはネッ
トワークサーバー装置、ファクス機、プリンター、イン
ターネット互換電話機、インターネットアクセス機器或
いはパーソナルデジタルアシスタントが含まれる。

【００１７】受信装置に備えられている受信クライアン
トアプリケーションは、専用サーバーから文書をダウン
ロードするために使用される。受信クライアントアプリ
ケーションは、ウエブブラウザであるのが望ましいが、
文書書式を維持しながら記憶された文書を検索可能ない
かなる他のソフトウエアアプリケーションであってもよ
い。受信クライアントアプリケーションに依って、受信
者は文書を受信し、検分し、印刷し、操作することがで
きる。送信クライアントアプリケーションは、アプリケ
ーションウインドウを経てアクセスされる。アプリケー
ションウインドウは、送信コンピューターのデスクトッ
プに表示される。アプリケーションウインドウには、主
要機能にアクセスするための常駐のツールバーと送信ク
ライアントアプリケーション用の操作コマンドをリスト
表示するメニューとが含まれている。

【００１８】パッケージマネージャとパッケージウイン
ドウも、アプリケーションウインドウからアクセスされ
る。パッケージマネージャーは、アプリケーションセッ
ションの間に開始される全ての文書作業をリスト表示す
る。ユーザーは、パッケージウインドウに依って受信
者、文書、送信オプションを含む文書送付のパラメータ
ーを指定することができる。文書デリバリパラメーター
は、後の変更及び／或いは使用のために記憶モジュール
に記憶される。文書は、配布のためにいくつかの方法で
指定される。ユーザーは、送信コンピューターデスクト
ップからアプリケーションウインドウ或いはパッケージ
ウインドウの一つに文書をクリックアンドドラッグでき
る。文書は、送信クライアントアプリケーションを表す
アイコン、又は記憶された文書のデリバリパラメーター
にアクセスするためのアイコンの何れかにドラッグする
こともできる。ユーザーは、更に、ローカル及びネット
ワークディレクトリを拾い読みし、希望の文書を選択で
きる。文書は、文書作成アプリケーション内からも送信
できる。

【００１９】専用サーバーを直接呼び出しカスタマイズ
するために、コンフィギュレーションユーザーインター
フェース（ＣＵＩ）が設けられている。本発明の好適実
施例において、ＣＵＩはＨＴＭＬインターフェースであ
る。それ故、専用サーバーはウエブブラウザ経由で直接
呼び出されカスタマイズされる。このＨＴＭＬインター
フェースは、文書の送信と追跡、アカウント情報へのア
クセス、ビリングの管理、メール配布リストの管理のた
めのモジュールを含んでいる。ＣＵＩは、管理コンピュ
ーターデスクトップに表示されるＣＵＩアプリケーショ
ンウインドウ経由でアクセスされる。管理コンピュータ
ーは、送信コンピューター、受信コンピューター、専用
サーバーないし電子ネットワークにおける他の存在であ
ってよい。ＣＵＩアプリケーションウインドウは、主要
機能にアクセスするためのメインツールバー及び第二機
能にアクセスするための第二ツールバーを表示する。Ｃ
ＵＩアプリケーションウインドウは、アクセスされた機
能への対話型インターフェースを表示するための作業場
所と操作コマンドをリスト表示するメニューも含んでい
る。

【００２０】本発明は更に、システムアクセスを認めら
れたユーザーだけに制限する機密保護構造を提供する。
サポートされる機密保護の型式には、認証レイヤー、セ
キュアソケットレイヤー、パスワード保護、プライベー
トキー暗号化、パブリックキー暗号化、証明認証が含ま
れる。機密保護構造は、一つ或いはそれ以上のモジュー
ルとして提供することができ、送信クライアントアプリ
ケーション、受信クライアントアプリケーション、ＣＵ
Ｉの少なくとも一つに組み込むことができる。送信者操
作の証明登録システムとその使用方法が、提供されてお
り、それによって送信者はデジタル証明の生成を制御
し、文書を安全な方法で暗号化し受信者に送信するのに
使用することができる。送信者は、以前に記憶された受
信者情報を受信者から集められた情報と比較する。情報
が合致する場合、送信者はキー生成ソフトウエアを受信
者に送信し、それによりパブリック／プライベートキー
ペアーを含むデジタル証明を作成する。次に、送信者は
パブリックキーを使用して文書を暗号化し受信者に送信
し、そこで受信者は合致するプライベートキーを使用し
て文書を解読する。好適実施例において、サーバーは、
送信者と受信者の間に配置され、システム機密保護、自
動化、完全性のレベルを高める。

【００２１】 〔発明の詳細な説明〕本発明は、電子ネットワーク上で
文書を安全に送付するための方法と装置を提供する。本
発明は、ユーザーにそのような文書の送信と受信の追跡
の可能性を提供する。送付の間、文書のフォーマットは
維持される。本文での論議の目的のために、「文書」と
いう用語は、データストリーム、ビデオデータ、オーデ
ィオデータ、アニメーション、ＨＴＭＬ或いはＰＤＦ或
いはエンボイ文書の様なプラットフォームに依存せずフ
ォーマットされた文書、マイクロソフトワード或いはエ
クセル文書の様なプラットフォーム特定のフォーマット
された文書、テキスト文書の様なフォーマットされてい
ない文書、特注作成されたレポート或いはウエブペー
ジ、ＳＱＬ記録の様な一つ或いはそれ以上のデータベー
ス記録のグルーピングを始めとした、あらゆるデータの
連続集合体を含むものとする。文書という用語は、一つ
或いはそれ以上のその様な文書のグルーピングされたも
のも含む。本発明の好適実施例は、インターネット上で
の文書送信に利用できるようになっている一方で、本発
明は同様に他の幅広い分野ないしローカルエリアネット
ワークにも適用可能である。

【００２２】下文において述べる表示スクリーンとグラ
フィックユーザーインターフェースの構成は、本発明の
本好適実施例に依って提供される。しかしながら、その
ような表示スクリーンとグラフィックユーザーインター
フェースは、本発明の代替実施例の要求に見合う様に簡
単に変更修正されることは当業者には明らかである。下
文における論議は、それ故、例示を目的として提供され
ており、本発明の範囲を制限するものではない。図５は
本発明に依る文書送付システム１０の線図である。シス
テムに依って、ユーザーは、送信クライアントアプリケ
ーション２０を使って電子ネットワーク１８上で、送信
コンピューター１４のデスクトップ１２から文書１６或
いは文書のセット、受信者アドレス或いは受信者アドレ
スのセットを送信できる。その様な文書は、ワードプロ
セッサー、スプレッドシートないしグラフィックアプリ
ケーションの様な文書作成アプリケーション内からも送
信することができる。送信クライアントアプリケーショ
ンは送信コンピューターに記憶されるのが望ましいが、
送信コンピューターがアクセス可能な離れた場所に記憶
されていてもよい。

【００２３】送信コンピューターは、専用サーバー２２
接続する。専用サーバーは、例えば送受信者の間の文書
送信を管理するためのインターネット基準の様な基準に
従って機能する。専用サーバーは、インターネットサー
ビスプロバイダ（ＩＳＰ）によって提供されるサーバ
ー、或いは単独の専用サーバーであってもよい。本発明
の好適実施例において、文書はハイパーテキストトラン
スファープロトコル（ＨＴＴＰ）を使って専用サーバー
にアップロードされたりダウンロードされたりする。Ｈ
ＴＴＰは、ワールドワイド（「ウエブ」）上でサーバー
に接続するために使用される通信プロトコルである。Ｈ
ＴＴＰの重要な有利な点は、それがアプリケーションで
ありプラットフォームに依存しないことである。この様
に送受信者は同じウエブブラウザを使用する必要はな
く、オペレイティングシステムでさえ同じものを使用す
る必要がない。

【００２４】専用サーバー２２は、送信コンピューター
１４から受信した文書を記憶する。専用サーバーは、次
に文書の送信の対象受信者に通知するために送信クライ
アントアプリケーションから受信したアドレスにある受
信装置に電子メッセージを送る。この通知メッセージ
は、インターネットの簡単なメールトランスポートプロ
トコル（ＳＭＴＰ）を使ってテキスト（例えばＡＳＣＩ
Ｉ）メッセージとして送信される。本発明の好適実施例
において、受信装置は、パーソナルコンピューター２４
である。しかしながら、代替実施例においては、受信装
置には、プリンター２６、ファックス機２８、ネットワ
ークサーバー装置、インターネット互換電話機、インタ
ーネットアクセス器械、或いはパーソナルデジタルアシ
スタントが含まれる（図示せず）。

【００２５】通知メッセージは、文書のユニフォームリ
ソースロケータ（ＵＲＬ）を含み、それによってサーバ
ーは文書に位置を突きとめることができる。このメッセ
ージに応じて、対象受信者は、受信クライアントアプリ
ケーション３０を使って専用サーバー２２から記憶され
た文書をダウンロードする。受信クライアントアプリケ
ーションは、受信装置に記憶されているのが好ましい
が、受信装置がアクセス可能な離れた位置に記憶されて
もよい。受信クライアントアプリケーションに依って受
信者は、文書を受信、検分、印刷及び／或いは操作する
ことができる。本発明の好適実施例において、受信クラ
イアントアプリケーションは、ウエブブラウザである。
この様に、対象受信者は、通知メッセージから直接ＵＲ
Ｌをコピーでき、それを受信コンピューターのウエブブ
ラウザにペーストすることができる。ウエブブラウザ
は、次に専用サーバーから文書を検索する。本発明の代
替実施例においては、受信クライアントアプリケーショ
ンは、文書書式を維持しながら、専用サーバーから記憶
された文書を検索可能な全ての他のソフトウエアアプリ
ケーションである。

【００２６】送信クライアントアプリケーションは、Ｃ
Ｄ−ＲＯＭからコンピューターに、或いはウエブからダ
ウンロードすることによって簡単にインストールされ
る。例えば、専用サーバープロバイダに既にアカウント
を持つユーザーは、適切なアカウント情報で送信クライ
アントアプリケーションを作り上げることができる。そ
のようなアカウントを持たないユーザーは、アカウント
を作るための情報を有するＵＲＬに導かれる。送信クラ
イアントアプリケーションは、送信コンピューターのデ
スクトップに表示されるアプリケーションウインドウ経
由でアクセスされる。一旦アカウント情報が適切に形成
されると、アプリケーションウインドウが表示される。
図６は本発明の好適実施例に依るアプリケーションウイ
ンドウ３２の画面である。

【００２７】アプリケーションウインドウの主要な機能
は、送信クライアントアプリケーション作業の状態を見
て、管理することである。アプリケーションウインドウ
は、送信クライアントアプリケーションの様々な機能と
コンフィギュレーションユーザーインターフェースＣＵ
Ｉに連絡を取るための足掛かりとしても役立つ（下文に
て論議）。本発明の好適実施例において、アプリケーシ
ョンウインドウは、送信クライアントアプリケーション
の主要機能にアクセスするためのメインツールバー３４
を表示する。その機能の一つに、新しいパッケージ３６
のための選択可能なボタンがある。新しいパッケージを
クリックすると、新しいパッケージウインドウが開き
（下文にて論議）、ユーザーが文書の配布を始められる
ようになる。オープンのボタン３８をクリックすると、
セーブされたデリバリパラメーター又はセーブされたパ
ッケージウインドウの何れかを開く（下文にて論議）。

【００２８】好適実施例では、メインツールバー３４
は、ＣＵＩ機能へのインターネットショートカットであ
るボタンを含んでいる。そのようなボタンをクリックす
ると、ユーザーのウエブブラウザを立ち上げ、ＣＵＩに
ある適切なページを表示する。本発明の好適実施例で
は、この過程で、追加のログインは必要とされない。そ
の様なボタンの例には、トラッキング４０、アカウント
４２、ビリング４４及びメールリスト４６の各ボタンが
含まれる。ボタンは、送信クライアントアプリケーショ
ン設定のために設けることもできる。例えば、セットア
ップボタン４８経由でアクセスされる選択ダイアログに
依って、ユーザーは専用サーバーと代理サーバーアカウ
ント情報を特定することができる。ユーザーは、全ての
送信に関してデスクトトップと専用サーバー間の接続を
安全にするためのセキュアソケットレイヤー（ＳＳＬ）
の様な低レベル安全通信プロトコルを使用するか否かを
指定することもできる。

【００２９】送信クライアントアプリケーションは、サ
ポートされたアプリケーションのローカルアドレスブッ
クにアクセス可能である。本発明の好適実施例では、ユ
ーザーがセットアップボタン４８を選択すると、本発明
に依ってサポートされたアドレスブックをリスト表示す
るプルダウンメニューが提示される。ユーザーは、次に
希望のアドレスブックファイルを選択する。停止ボタン
５０は、専用サーバーへの全ての情報の送信を停止する
ために使用する。本発明の好適実施例では、一旦クリッ
クすると、停止ボタンは押された状態のままとなる。送
信を再開するには、ユーザーがボタンを再度クリックす
るとボタンは上がった位置に戻る。メニュー５２は、送
信クライアントアプリケーション用の操作なコマンドを
リスト表示する。本発明の好適実施例では、ファイルメ
ニュー５４には、メインツールバー３４にあるボタンと
同じ機能を有するコマンドが含まれている。その他のコ
マンドは送信クライアントアプリケーションに関する情
報を提供するか、或いはＣＵＩの機能へのインターネッ
トショートカットである。図６において、メニューは、
編集５６、パッケージ５８、ＣＵＩ６０及びヘルプ６２
をリスト表示する。

【００３０】アプリケーションウインドウは又、アプリ
ケーションセッションの間に開始された全ての文書作業
をリスト表示するパッケージマネージャー６４も表示す
る。パッケージマネージャーは、送信クライアントアプ
リケーションセッションの間に開始された全ての文書作
業をリスト表示するアプリケーションウインドウ本体に
おけるエリアないしフィールドのセットである。送信ク
ライアントアプリケーションが最初に立ち上げられる
と、パッケージマネージャーフィールドは空になる。し
かしながら、文書が送信されるにつれて、それらはパッ
ケージマネージャーにリスト表示される。図７は、本発
明の好適実施例に依る文書作業７２を示すアプリケーシ
ョンウインドウ３２の画面である。パッケージマネージ
ャは、受信者６６、サブジェクト６８、送付の状態７０
を表示する。配布中の状態は、アップロードが完了され
た動的パーセントテージとして表される。その他の可能
な状態ラベルとしては「完了」、「エラー」、「ペンデ
ィング」、「ホールド中」が含まれている。

【００３１】文書は、処理順或いは処理順の逆に表示さ
れる。本発明の好適実施例では、現在処理中の文書７４
は、太い文字で表示される。代替実施例では、最新の文
書は、強調表示、点滅、色に依って示されるか、或いは
印がされていないかである。リスト表示された文書７６
をクリックすると、その項目を強調表示し、その文書を
選択する。複数の文書も一度に選択できる。一旦文書が
選択されると、ユーザーはメニュー５２を使用して、例
えば文書をホールド、編集或いは削除することができ
る。ホールドは、ペンディング中の文書が処理されるの
を防ぐ。文書は削除されるか或いはホールドが解除され
るまで待ち行列に維持される。本発明の好適実施例で
は、リストにあるいかなる文書も、或いは全ての文書が
削除可能である。現下の送信は完全に打ち切られ、既に
処理された文書はウインドウから削除される。

【００３２】編集は、新しいパッケージウインドウ内で
文書を開く（下文にて論議）。ユーザーは、次に文書を
編集し、送信のために再度提出できる。文書が送信中に
編集される場合、送信は打ち切られる。文書は、新しい
パッケージウインドウで開かれ、次のペンディング中の
文書が送信される。図８は、本発明の好適実施例に依る
パッケージウインドウ７８の画面である。パッケージウ
インドウ７８に依って、ユーザーは文書送付のパラメー
ターを指定することができる。新しいパッケージウイン
ドウは、例えばメニューないしツールバー選択によって
アプリケーションウインドウからアクセスできる。パッ
ケージウインドウはセーブされ、後で開かれる。更に、
ユーザーが文書作成アプリケーションから送信クライア
ントアプリケーションへ文書を送信（印刷）する時点
で、パッケージウインドウが開かれる。

【００３３】各々の文書送付処理には、送信者が、文書
の受信者、送付される文書、デリバリオプションを指定
する必要がある。その様なデリバリオプションには、優
先順位８０、リクエスト確認８２、文書失効８６、予定
通知８８、ビリングコード９０が含まれている。本発明
の好適実施例は、クリアーフォーム９２、セーブフォー
ム９４、セーブパラメーター９６、送信９８の様な選択
可能ボタンを含んでいる。所定の送付に関する受信者或
いはメールリストの数がどれだけあっても、パッケージ
ウインドウの「Ｔｏ：」フィールド１１０に指定され
る。各々の受信者は電子メールアドレス、別名、メール
リストによって指定されなければならない。ユーザーは
直接「Ｔｏ：」フィールドにアドレスを打ち込む。代わ
りに、ユーザーは「Ｔｏ：」ボタン１０８をクリックし
て受信者のウインドウにアクセスすることもできる。

【００３４】メッセージのサブジェクトは、サブジェク
トフィールド１３４に入力される。メッセージ自体は、
メッセージフィールド１３６に入力される。サブジェク
ト１３４とメッセージ１３６のフィールドは随意選択で
ある。本発明の好適実施例では、サブジェクトは、電子
メール通知メッセージとダウンロードされた文書に関す
るＨＴＭＬカバーページ上に現れる。メッセージは、電
子メール通知にのみ現れる。パッケージウインドウにあ
る文書フィールド１１２に依って、ユーザーは、送付さ
れる文書がどんな数であっても指定することができる。
文書は、幾つかの方法で指定される。ユーザーは、送信
コンピューターデスクトップからアプリケーションウイ
ンドウ、パッケージウインドウの一つ、或いは送信クラ
イアントアプリケーションを表すアイコン又は記憶され
た文書デリバリパラメーターにアクセスするためのアイ
コンの何れかに文書をクリックアンドドラッグできる。

【００３５】パッケージウインドウにある文書ボタン８
４をクリックすると、送信者は、ローカル及びネットワ
ークディレクトリを拾い読みし、希望の文書を選択でき
る。パッケージウインドウが文書作成アプリケーション
から引き出されると、文書フィールドには自動的に現在
使用中の文書が書き込まれる。ファイルフォーマットフ
ィールド１３８に依って、ユーザーはどの電子フォーマ
ットに文書がセーブされたか明記することができる。送
信クライアントアプリケーションは、マックバイナリ
ー、エンボイ、ＰＤＦ、ダイナドック、ＨＴＭＬの様な
異なるフォーマットを容易にサポートできるようになっ
ている。例えば、あるプラットフォームで操作可能なワ
ープロアプリケーションで作成された文書は、異なるプ
ラットフォームで操作可能な他のワープロアプリケーシ
ョンのフォーマットでセーブすることができる。

【００３６】各々の配布処理は、関連した送信オプショ
ンを有する。本発明の好適実施例では、全てのオプショ
ンは、送付の前にユーザーが変更可能なディフォルト設
定をされている。設定は、パッケージウインドウで見
て、編集できる。優先順位フィールド８０において、ユ
ーザーは、例えば、通常、低、高、至急の様な送付の優
先順位を指定することができる。優先順位は、文書が専
用サーバー同様クライアントに依って処理される順序も
決定する。リクエスト確認フィールド８２は、受信者
に、文書が首尾よく受信されたかどうかを確認する様に
促すために使用される。リクエスト確認は、希望に応じ
て選択されたり或いはされなかったりする。機密保護ダ
イアログ１０１に依って、使用者は、高度な機密保護方
法の様々なレベルを指定することができる。これらのレ
ベルは、基本パスワード保護のためのパスワード１００
を記すか或いはパスワード１０２の確認を要求すること
を含む。暗号化１０４或いは受信者に文書を受信するた
めにＳＳＬの使用を要求する１０６といった様な追加の
機密保護の規定も提供できる。ユーザーが受信者にＳＳ
Ｌの使用を要求し、送信コンピューターデスクトップと
専用サーバー間に安全な接続を使用しない場合、受信者
は、専用サーバーへの接続を保護するか否かをたずねら
れる。

【００３７】文書失効フィールド８６に依って、ユーザ
ーは、受信者が入手するためにどれだけの期間文書が専
用サーバーに残るかを指定することができる。通知送信
後１０日の様に、ディフォルトを設定してもよい。予定
通知フィールド８８を使えば、ユーザーは、専用サーバ
ーがユーザーに所定の送付を通知する予定時間と時刻を
指定することができる。ビリングコードダイアログ９０
を使えば、ユーザーは、ユーザーの送信クライアントア
プリケーションアカウントに関連するリストから随意選
択のビリングコードを選択できる。本発明の好適実施例
では、ビリングコードの隠されたリストが利用可能であ
る。リフレッシュボタン１１４は、専用サーバー上の最
新のビリングコードリストを使ってリストをリフレッシ
ュする。

【００３８】一旦ユーザーがパッケージウインドウにデ
リバリパラメーターを指定すると、ユーザーは、送信ボ
タン９８をクリックして文書送付を開始できる。受信者
と文書フィールドの両方が正しく入力された場合のみ、
送付は開始される。送信ボタンは、その様なフィールド
両方が完成するまで作動しない。ユーザーがオフライン
で作業中である場合、送信された文書は、接続が最終的
に確立する時点で、送信のための待ち行列に入れられ
る。アドレスは先ず最新のローカルアドレスブックと比
べられる。アドレスが合致しない場合、それらは、専用
サーバーにその様にアップロードされる。専用サーバー
は、次にアドレスをメールリストと合致させようとす
る。アドレスがなお合致しない場合、専用サーバーはア
カウント所有者のドメイン名を追加する。

【００３９】部分的に完了したパッケージウインドウ
は、セーブフォームボタン９４を使ってキャンセル或い
はセーブできる。セーブされたパッケージウインドウは
後で使用するため再度開けることができる。セーブされ
たデリバリパラメーターは、セッションの間再生ベース
で使用できる。パッケージウインドウから、ユーザー
は、指定された送信オプション、アドレスリスト及び／
或いは固定されたサブジェクト又はメッセージを含むデ
リバリパラメーターをセーブできる。デリバリパラメー
ターをセーブするには、ユーザーはセーブパラメーター
ボタン９６をクリックする。ダイアログボックスは、ユ
ーザーにセーブするデリバリパラメーターに関する名称
と場所を指定する様に促す。

【００４０】セーブされたデリバリパラメーターがアド
レスリストを含む場合、ユーザーは文書アイコンをセー
ブされたデリバリパラメーターアイコン上にクリックア
ンドドラッグすることに依って送付を開始できる。文書
は、送付に必要な残りの情報を提供し、送信が自動的に
始まる。セーブされたデリバリパラメーターは、この様
に受信者の特定のセットへの専用メールシュートとして
機能する。現行の送信オプションは、送付を起こす前に
変更修正或いは確認できる。全ての送信パラメーターを
表示するウインドウが開けられ、ユーザーは、文書を送
信する前にパラメーターを変更修正し、或いはメッセー
ジを追加できる。本発明の好適実施例では、ユーザー
は、パッケージウインドウを閉じる時に、送信オプショ
ン又は現行のアドレスリストに対する全ての変更をセー
ブする様促される。

【００４１】セーブされたデリバリパラメーターがアド
レスを含んでいない場合、文書をセーブされたデリバリ
アイコンへクリックアンドドラッグすれば、パッケージ
ウインドウが開く。セーブされた送信オプションと文書
名がパッケージウインドウに記入される。文書が送信で
きるようにするには、ユーザーは受信者を指定しなけれ
ばならない。セーブされたデリバリパラメーターは、関
連するアイコンをクリックするか、或いは適切なメイン
ツールバー３４又はメニュー項目を選択することによっ
て開かれる。設定はパッケージウインドウに表示され、
送付のために完了或いは変更修正される。送信クライア
ントアプリケーションが開いていない場合、セーブされ
たデリバリパラメーターを開くとパッケージウインドウ
だけでなくアプリケーションウインドウも開く。セーブ
されたデリバリパラメーターへの変更修正は、現行のセ
ーブされたパラメーターを入れ替えるか、或いは違う名
前の新しくセーブされたデリバリパラメーターを作成す
ることによって保存される。

【００４２】セーブされていない変更がセーブされたデ
リバリパラメーターに対して行われた場合、ユーザー
は、パッケージウインドウを閉じる際に変更をセーブす
る様に促される。送信者は、以前にアドレスリストを含
んでいなかった現行のセーブされたデリバリパラメータ
ーにアドレスリストを加えることができる。パッケージ
ウインドウの設定は「ディフォルトとしての設定をセー
ブする」ボタン１１６を使ってセーブされる。図９は、
本発明の好適実施例に依る受信者ウインドウの画面であ
る。受信者ウインドウ１１８は、アドレスブック或いは
以前定義されたメールリストから受信者の名前を選択す
るために使用される。本発明の好適実施例において、プ
ルダウンメニュー１２０に依って、ユーザーは、ローカ
ルアドレスブック或いはメールリストにあるアドレスに
アクセスできる。例えば、プルダウンメニューにあるメ
ールリストを選択し、リフレッシュボタン１２２をクリ
ックすると、送信クライアントアプリケーションが構成
されるアカウント用の専用サーバーに記憶されたメール
リストの名前がリストボックス１２４に入ってくる。ロ
ーカルアドレスブックを選択し、リフレッシュボタンを
クリックすると、選択ダイアログで指定されたアドレス
ブックからのアドレスがリストボックスに入ってくる。

【００４３】受信者のウインドウが開かれる度に、送信
クライアントアプリケーションは以前に貯えられたアド
レスのリストを表示する。リフレッシュをクリックする
と、適切なソースからのリストを強制的にリフレッシュ
する。送信クライアントアプリケーションは、セッショ
ン内とセッション中の両方で次回の送信のために前回選
択されたソースを提示する。キャンセルボタン１３５
は、受信者のウインドウ表示をキャンセルする。ユーザ
ーは、リストボックス１２４から項目を選択し、受信者
としての選択を明記するために「Ｔｏ」矢印ボタン１２
６をクリックする。本発明の好適実施例では、コントロ
ールクリックは複数の項目の選択を可能にし、シフトク
リックは項目の範囲を選択する。受信者は、受信者ボッ
クス１２８に提示される。受信者ボックスリストにリス
ト表示された受信者は、削除ボタン１３０をクリックす
るか或いはキーボードバックスペースないしデリートキ
ーを叩くことによって選択され、削除される。

【００４４】ユーザーが「ＯＫ」ボタン１３２をクリッ
クすると、受信者ボックスリストにある項目が、パッケ
ージウインドウ７８の「Ｔｏ：」フィールド１１０に表
示される（図８参照）。本発明の好適実施例では、メー
ルリストは、未決の場合接頭辞「リスト：」を有する。
ユーザーは、パッケージウインドウの「Ｔｏ：」フィー
ルドから受信者アドレスを更に削除或いは変更修正でき
る。指定された文書デリバリパラメーターは、後の変更
修正及び／或いは使用のために記憶モジュールに記憶さ
れる。本発明の好適実施例では、送信クライアントアプ
リケーションとパッケージウインドウには、送信コンピ
ューターのデスクトップからそれらを表すアイコン（図
示せず）を選択することによってアクセスできる。

【００４５】コンフィギュレーションユーザーインター
フェースは、専用サーバーを直接呼び出しカスタマイズ
するために提供されている。ＣＵＩは、管理コンピュー
ターデスクトップに表示されるＣＵＩアプリケーション
ウインドウ経由でアクセスできる。代りに、ＣＵＩは、
表をサポートする全てのウエブブラウザアプリケーショ
ンを通して、或いは送信クライアントアプリケーション
を通してアクセスできる。図１０は、本発明の好適実施
例に依るＣＵＩアプリケーションウインドウ１４０の画
面である。本発明の好適実施例では、ＣＵＩは、ウエブ
ブラウザ経由で専用サーバーを呼び出しカスタマイズす
るためのＨＴＭＬインターフェースである。このＨＴＭ
Ｌインターフェースは、文書送信、文書追跡、文書送付
アカウントに関連する情報へのアクセス、文書送付に関
するビリング管理、メール配布リストの管理のためのモ
ジュールを含んでいる。

【００４６】ＣＵＩは、ユーザーと使用されるアカウン
トの型によって、異なる機能のセットを提供する。個々
のアカウントホルダー、グループアカウントマンージャ
ー、グループメンバーは、僅かに異なるインターフェー
スを見て、様々なセットのデータにアクセスし操作する
ことができる。ユーザーがＣＵＩセッションを開始する
と、アカウントの型が専用サーバーによって確認され
る。そして、特定のユーザーには、適切な機能とデータ
が提供される。本発明の好適実施例では、個々のアカウ
ントホルダーとグループアカウントマネージャーは、全
ての送付とアカウントに関連するアカウント情報へアク
セスできる。アカウントマネージャーは、それ故アカウ
ントを使用する全てのグループメンバーの作業に関する
情報へアクセスできる。

【００４７】アカウントマンージャーは更に、メンバー
アカウントを作成及び管理することが認められている。
グループメンバーは、メンバー自身の送付サービスに関
する情報のみにアクセスできる。管理コンピューター
は、送信コンピューター、受信コンピューター、専用サ
ーバー、或いは電子ネットワーク内にある他のコンピュ
ーターであってもよい。ＣＵＩは、五つの主要機能即
ち、新しいパッケージ１４２、トラッキング１４４、ア
カウント１４６、ビリング１４８、メールリスト１５０
を含んでいる。本発明の好適実施例では、これら主要機
能は、常駐のメインツールバー１５４にある選択可能ボ
タン１４２、１４４、１４６、１４８、１５０として表
示されている。図１０において、このメインツールバー
が水平方向に表示されており、クイットボタン１５２が
更に含まれている。しかしながら代替実施例では、アプ
リケーションウインドウの構成は異なった形になってい
る。

【００４８】第二ツールバー１５６は、主要機能内にあ
る第二次機能１６４にアクセスしナビゲイトするために
提供されている。図１０において、第二ツールバーは、
垂直方向に表示される。しかしながら、この構成は例示
するためだけのものである。本発明では、メイン及び第
二ツールバーを異なる方向に簡単に表示することができ
る。ＣＵＩアプリケーションウインドウ１４０に関する
第二ツールバー１５６にある第二ナビゲーションは、ア
ドレス１６６とオプション１６８を含む。全ての第二ツ
ールバーに含まれるヘルプボタン１５８は、使われてい
る機能に対するオンラインヘルプにアクセスするために
使用される。ＣＵＩアプリケーションウインドウには、
アクセスされた機能への対話型インターフェースを表示
するためのワークスペース１６０も含まれている。メニ
ュー１６２は、ＣＵＩに関する操作上のコマンドをリス
ト表示する。

【００４９】送信機能は、送信クライアントアプリケー
ションの機能を映す。送信機能は、新しいパッケージボ
タン１４２からアクセスされる。この送信機能に依っ
て、ユーザーは、どのブラウザを使用しても離れた場所
から文書を送信できる。送信機能に依って、文書は、送
信クライアントアプリケーションによってサポートされ
ていないプラットフォームからでも送信可能である。本
発明の好適実施例では、セーブされているデリバリパラ
メーター、エンボイ変換、及びローカルアドレスブック
へのアクセスは利用できない。送信機能にアクセスする
ために新しいパッケージボタンをクリックするとパッケ
ージウインドウが出てくる。図１１は、本発明の好適実
施例に依るＣＵＩパッケージウインドウ１７０の画面で
ある。使用中の機能は、第二ツールバーにある項目１９
２によって示される。

【００５０】所定の送付のために、ユーザーは、「Ｔ
ｏ：」フィールド１７２に手動で名前を入力できる。メ
ールリストも、プルダウンメニュー１７４から選択でき
る。ユーザーは、それによってメールリストを見て、操
作する。本発明の好適実施例では、ユーザーは、ローカ
ル電子メールアドレスブックへはアクセスできない。
「Ｔｏ：」フィールド１７２に入力された項目が適切な
ドメイン書式を含んでいない場合（例えば「＠」が落ち
ている）、項目はサーバーによってメールリストと比較
される。項目がメールリストに無い場合、サーバーは、
送信者のドメイン名を項目の最後に付け足す。送信者
は、サブジェクトフィールド１７６とメッセージフィー
ルド１７８にテキストを入力する。送信者は、「文
書：」フィールド１８０に、文書の名前と、その文書へ
のパスををタイプすることによって送信される文書を指
定する。代りに、文書は、ブラウズボタン１８２をクリ
ックし、ローカル或いはネットワークディレクトリから
文書を選択するために拾い読みして指定することもでき
る。

【００５１】複数の文書を送信するには、送信者は「文
書を更に追加する．．．」リンク１８４をクリックす
る。次に送信者には、四つの追加「文書：」フィールド
とブラウズボタンが追加された、新しいパッケージウイ
ンドウと同様のフォーマットを有するウインドウ（図示
せず）が提示される。前のＣＵＩパッケージウインドウ
１７０に既に入力されている情報は、新しいウインドウ
に繰り越される。この様に好適実施例では、送信者は文
書を５つまで指定できる。代替実施例では、文書の数は
幾つでも指定できる。リセットボタン１８６は、ウイン
ドウにある全てのフィールドをそれらのディフォルト状
態にクリアーする。送信ボタン１８８は、ディフォルト
オプションを使って文書の送付を開始するために使用さ
れる。アドレスフォームに入力された情報が不完全或い
は正しくない場合、本発明はエラーページ（図示せず）
を送信者に表示する。それが認識されない場合、本発明
は、送信者に文書の模写タイプを促す。模写タイプは、
文書のフォーマットを指定し、文書を表示するための対
応するアプリケーションを立ち上げるため受信者ブラウ
ザによって使用される。好適実施例では、エラーページ
は直接編集され、新しい情報は直接提出される。送信が
完了した場合、送信者に通知ページ（図示せず）が表示
される。

【００５２】本発明の好適実施例では、ＣＵＩには、送
信クライアントアプリケーションの送信オプションの殆
どが含まれている（図８参照）。これらの送信オプショ
ンには、オプションボタン１９０をクリックして、ＣＵ
Ｉオプションページを開けばアクセスできる。図１２
は、本発明の好適実施例に依るＣＵＩオプションページ
１９４の画面である。その様なオプションには、優先順
位１９６、リクエスト確認１９８、文書失効２００、予
定通知２０２が含まれている。しかしながら送信クライ
アントアプリケーションドライバーはサーバーからは利
用できないため、文書タイプの様な特定の送信クライア
ントオプションは設けられていない。文書は、それ故文
書の元の書式でのみ送信される。機密保護機能２０４
は、本発明の好適実施例に組み込まれる。本発明の好適
実施例は、米国で使用が現在の法の下で許可されている
機密保護と暗号化特性をサポートする。本発明の代替実
施例は、米国からの輸出を意図するソフトウエアアプリ
ケーションに対するいかなる機密保護と暗号化の要件に
も合致する。

【００５３】ＣＵＩユーザーは、受信者が文書にアクセ
スするために提供しなければならないパスワード２０６
を指定することができる。ユーザーは、確認パスワード
２０８、暗号化文書２１０を指定し、２１２を受信する
のにＳＳＬを要求することもできる。パスワードは、サ
ーバーで文書を暗号化するためのシークレットキーとし
て使用することができる。これは、文書がサーバーで記
憶されるにも関わらずより高い機密保護レベルを提供す
る。暗号化文書機能２１０が選択されながらもユーザー
がパスワードを特定しない場合、ＣＵＩは、ユーザーが
設定の適用を試みる時点でエラーメッセージを送信す
る。ビリングコードオプション２１４に依って、ユーザ
ーは、プルダウンメニューからの「無し」を含むビリン
グコードを選択できる。リストは、ＣＵＩのビリングモ
ジュールで定義され保守される（図１９参照）。「ビリ
ングコード」テキストリンクは、ユーザーをＣＵＩのビ
リングセクションに導く。ユーザーは、それによってビ
リングコードを見て、操作できる。

【００５４】リセットボタン２１６をクリックすると、
ディフォルト設定状態に戻る。代りに、現在の設定をデ
ィフォルトとしてセーブ２１８することもできる。一旦
オプションが設定されると、ユーザーは、更新ボタン２
２０を使用してパッケージウインドウ１７０に戻る。送
信ボタン１８８をクリックすると送付が開始される。追
跡には、常駐のメインツールバー１５４にある追跡ボタ
ン１４４からアクセス可能である。追跡サーチ機能は、
アカウントから送信された送付についての情報に関して
のＣＵＩデータベースを照会するために使用される。送
信者は、それ故、受信者が特定の文書を受信したかどう
かが分かる。データベースアーカイブは、過去の処理の
記録に関してもサーチできる。図１３は、本発明の好適
実施例に依るＣＵＩ追跡サーチページ２２２の画面であ
る。第二ツールバー１５６からの第二ナビゲーション
は、ログ２２４、サーチ２２５、レポート２２６、選択
２２８、ヘルプ１５８を含んでいる。現在の機能１９
２、サーチ２２５、は同一である。メインツールバーに
ある追跡ボタンは、デリバリログ（図示せず）としてア
カウントから送信された全ての送付の記録を表示する。

【００５５】アカウントマネージャーは、グループアカ
ウントから開始された全ての送付の追跡が可能である。
グループメンバーは、メンバーによって個人的に開始さ
れた送付のみ追跡が可能である。デリバリログのフォー
マットはトラッキング選択において指定される（図１４
参照）。選択されたフォーマットは、デリバリログとト
ラッキングレポートの両方に利用される（図１５−１７
参照）。本発明の好適実施例は、ユーザーが以前の或い
はその後のログページにアクセスできる様にナビゲーシ
ョンボタンを含んでいる。個々の送付に関する情報は、
ログされた配布の総数の指示にと一緒にデリバリログに
表示される。ログにある各々の項目のサブジェクトは、
特定の送付に関するパッケージ詳細レポート（図示せ
ず）にリンクしている。詳細レポートは、失効していな
ければ文書へのリンク、模写タイプ、メッセージを含む
各々の送付の送信パラメーターを含んでいる。詳細レポ
ートは、個々の受信者への送付の状態と処理に当てられ
た費用も含んでいる。ユーザーは、第二ツールバー１５
６にあるログ２２４をクリックしてトップレベルログに
戻ることができる。

【００５６】サーチ機能に依って、ユーザーは、特定の
送付或いは送付のセットに関する情報と状態を正確に示
すことができる。ユーザーは、関心のある送付を確認す
るためにサーチ基準のいずれかの組み合わせを指定す
る。複数の基準が指定された場合、サーチエンジンは、
全ての基準の中で論理「ＡＮＤ」サーチを実行する。本
発明の好適実施例において、サーチページグラフィカル
ユーザーインターフェース（ＧＵＩ）は、簡単にされて
いる。共通のサーチ可能フィールドのショートリスト２
３０は、サーチページに提示される。ショートリストに
は、五つのサーチ基準が含まれている。「Ｔｏ：」フィ
ールド２３２に依って、ユーザーは、対象受信者のフル
アドレス或いは受信者の部分電子メールアドレスを使っ
てサーチできる。部分電子メールアドレスにより、ユー
ザーはドメイン名を使ってサーチできる。

【００５７】「Ｆｒｏｍ：」フィールド２３４によっ
て、アカウントマネージャーは、送付の開始者に依るサ
ーチができる。アカウントマネージャは、プルダウンメ
ニューからメンバーの電子メールアドレスを選択する。
グループメンバーと個々のアカウントホルダーに対し、
この所定のユーザーの電子メールが提供され、変更不可
能である。「サブジェクト：」フィールド２３６によっ
て、ユーザーは、文書のサブジェクトフィールドで見つ
けられるキーワードを入力できる。「文書：」フィール
ド２３８によって、ユーザーは、文書名でテキストサー
チができる。ユーザーは、文書名で打ち込んだり、文書
を選択するために文書リストを拾い読みしたりできる。

【００５８】「送信データ：」フィールド２４０によっ
て、ユーザーは、特定の日又はその前後で送信された送
付をサーチできる。サーチボタン２４２をクリックする
と照会を開始し、照会に合致する全ての送付のレポート
を戻す。リセットボタン２４６をクリックすると、フォ
ームをクリアーしてディフォルト設定にする。ショート
フォームの下部にある「更なるオプション．．．」ボタ
ン２４８をクリックすると、ユーザーは、ショートリス
トからの全てのフィールドを含む、サーチ可能なフィー
ルドの第二、拡張リスト（図示せず）を有するページに
導かれる。好適実施例では、拡張リスト内の追加フィー
ルドには次のものが含まれる。ビリングコード：フィー
ルドによって、ユーザーはプルダウンメニューにある予
め定義されたリストから選択できる。

【００５９】「配布状態：」フィールドによって、ユー
ザーは、送付状態のメニューから選択できる。送付状態
オプションには、全ての受信されたもの、されていない
もの（通知失敗のもの及びピックアップされていないも
のの両方を含む）、確認されたもの、されていないも
の、ペンディング通知及び失敗通知が含まれる。ユーザ
ーは、文書失効、予定通知日、受信日付、メッセージフ
ィールドをサーチすることもできる。サーチ結果は、追
跡レポートに表示される。追跡レポートは、追跡選択ダ
イアログに記されたフォーマットで表として表示され
る。図１４は、本発明の好適実施例に依るＣＵＩ追跡レ
ポート選択ダイアログ２５０の画面である。ダイアログ
によって、ユーザーは、文書フォーマット２５２を選択
したり或いは新しいフォーマット２５４を定義したりで
きる。本発明の好適実施例では、ユーザーは、二つの予
めフォーマットされたレポート、即ち基本フォーマッ
ト、ビリングコードフォーマットから選択できる。要約
と詳細情報レポートの両方が、各フォーマットで利用で
きる。

【００６０】ダイアログによって、ユーザーは、ページ
毎の行数２５６を指定することができる。加えて、ユー
ザーは、受信者要約情報２５８、又は詳細情報２６０を
示すかどうかを選択する。更新２６２をクリックすると
全ての変更がセーブされ、ユーザーは、追跡レポートに
アクセスした元のレポート或いはページに戻る。ユーザ
ーがレポートに戻ると、新しい選択設定で表示される。
ダイアログはリセットボタン２６４を使ってリセットさ
れる。図１５は、本発明の好適実施例に依る基本フォー
マット２６６での受信者要約追跡レポートの画面であ
る。サーチ結果が表示されると、第二ツールバー１５６
にある第二ナビゲーションは、送信者がレポートモード
２２６に在ると示す。追跡レポートの要素と動きは、デ
リバリログのそれらと一致する。

【００６１】本発明の好適実施例では、送付は日付によ
って分類され、入力順の逆に表示される。しかしなが
ら、代替例において、送付は、例えば受信者によって、
入力順に表示或いは分類される。送付項目の次のページ
は、ネクストボタン２８４をクリックしてアクセスされ
る。受信者要約追跡レポートは、「受信者：」フィール
ド２７０に、特別の送付の第一受信者の名前２６８の
み、或いは送付が送信されたメールリストにある第一受
信者をリスト表示する。リストにそれ以上の名前がある
場合、表示（．．．）が、名前の次に出る。送付の受信
者数が、「受信済み：」フィールド２７２にリスト表示
され、通知された数が「通知済み：」フィールド２７４
にリスト表示される。この情報は全ての受信者に渡って
総計される２７６。

【００６２】例えば、図１５に示される最も最近の送付
は、「サブジェクト：」フィールド２７８にリスト表示
されたパーティー招待である。パーティー招待が送信さ
れた日付は、「送信：」フィールド２８０に示されてい
る様に１９９７年１月２２日である。追跡レポートは、
総計三つのパーティー招待文書が送信されたことを示
す。全ての三人の受信者が通知され文書を受信してい
る。第一受信者２６８“ｊａｎｅ＠ｉｓｐ．ｃｏｍ，”
のみが「受信者：」フィールド２７０に表示されてい
る。図１６は、本発明の好適実施例に依る基本フォーマ
ットでの受信者詳細追跡レポートの画面である。受信者
詳細追跡レポート２８２は、「受信者：」フィールド２
７０に個々の送付の個々の受信者をリスト表示する。
「受信済み：」２７２フィールド及び「通知済み：」２
７４フィールドは、個々の受信者が送付を通知され、送
付を受信した特定日をリスト表示する。例えば、図１６
は、パーティー招待の三人の受信者、彼等の通知と受信
日を別々にリスト表示している。

【００６３】受信者詳細追跡レポートは又、全てのメー
ルリストを拡張する。本発明の好適実施例では、メール
リストは、処理された送付に関して拡張されているだけ
である。先の予定送付と進行中の送付は、その様に示さ
れる。図１７は、本発明の好適実施例に依るビリングコ
ードフォーマット２８６での受信者詳細追跡レポートの
画面である。ビリングコードフォーマットは、ビリング
コード２８８を表示し、ビリングコードと日付により結
果を分類する。ＣＵＩアカウント管理機能は、「アカウ
ント」１４６と表示しててあるメインツールバーボタン
から利用可能である。アカウント機能は、グループアカ
ウントマネージャー、個別アカウントホルダー、メンバ
ーアカウントホルダーの様なアカウントのタイプ及びユ
ーザーのタイプによって変化する。サーバーソフトウエ
アはユーザーのアカウントタイプを確認し、適切な機能
と利用可能な情報を作成する。

【００６４】全てのユーザーは、アカウントバランスを
含む個々のユーザーのアカウントに関する記録にある管
理アカウント情報を見ることができ、そのパスワードを
変更することもできる。しかしながら、グループアカウ
ントマネージャーは拡張された能力を有し、グループメ
ンバーの新しいアカウントを作成できるだけでなく、そ
のアカウント情報を編集できる。この様に、グループア
カウントマネージャーに表示された第二ツールバーの第
二ナビゲーションは、情報：３０２、メンバー検分：３
０４、メンバー追加：３０６の様な機能を含んでいる
（参照図１８）。情報ページ（図示せず）は、専用サー
バーに記憶されたグループアカウントに関する基本情報
を表示する。その様な基本アカウント情報には次のもの
が含まれる。

【００６５】・アカウント名 ・アカウントタイプ ・作成日付 ・最新アクセス日付 ・最大許可されたメンバーの数に対する現在のメンバー
の数 アカウントマネージャーは、メンバーページ（図示せ
ず）経由で現在のメンバーリストを見て、管理できる。
アカウントホルダー情報には次のものが含まれる。 ・マネージャー名 ・電子メールアドレス ・会社名 ・アドレス 基本アカウント情報とアカウントマネージャー情報は編
集できない。

【００６６】グループアカウントパスワードは、情報ペ
ージから変更できる。マネージャーは、現行のパスワー
ドと希望の新しいパスワードを入力し、新しいパスワー
ドを確認しなければならない。マネージャーは、更新を
クリックして新しいパスワードを提示する。好適実施例
では、情報ページは、パスワードが最後に何時変更され
たかをマネージャーに知らせるフィールドも含んでい
る。パスワードが一度も変更されていない場合、このフ
ィールドはアカウントの作成日付を表示する。アカウン
トの変更を認められたサーバーマネージャーに、リンク
を提供することもできる。マネージャーは、情報ページ
にあるメンバーテキストリンクをクリックし、或いは第
二ツールバー１５６の検分メンバー機能を選択すること
によってメンバーのリストを見ることができる。図１８
は、本発明の好適実施例に依るグループアカウントマネ
ージャーアカウント検分メンバーウインドウ２８８の画
面である。ある実施例では、マネージャーは、自分が、
フォーマット、ページ毎の行数、検分メンバー表の分類
順序を指定することができるプリファランス（図示せ
ず）へのリンクを使用する。

【００６７】検分メンバーページは、グループアカウン
トの名前２９０と総数から表示されたメンバー数２９２
を表示する。メンバーのリストは、アカウントマネージ
ャーを含み、メンバーアカウント名２９４、メンバー名
２９６、作成日付２９８、最後にアクセスされた日付３
００を表す表で表示される。メンバー名をクリックする
と、メンバ−に予めアドレス指定されている「メール
先：」ボックス（図示せず）が出てくる。アカウント名
をクリックすることに依って、マネージャーは、個々の
メンバーアカウント情報を見て編集できる。この情報
は、グループアカウント情報ページと同様なフォーマッ
トのメンバーアカウント情報ページ（図示せず）に表示
される。基本メンバーアカウント情報は、次のものを含
む（編集可能な情報はその旨示されている）。

【００６８】・グループアカウント ・メンバーアカウント（編集可能） ・作成日付 ・最新アクセス日付 メンバー情報 ・メンバー名（編集可能） ・電子メールアドレス（編集可能） マネージャーは、メンバーのパスワードは見れないが、
新しいパスワードを指定し、それを確認することによっ
てメンバーアカウント情報ページにあるパスワードを変
更できる。マネージャー或いはメンバー何れかによる最
新パスワード変更の日付（図示せず）も表示される。こ
のページにある情報になされたどんな変更も、更新（図
示せず）をクリックすることによって提示できる。リセ
ット（図示せず）は、以前に記憶された情報を復元す
る。

【００６９】メンバーアカウントは、メンバーアカウン
ト情報ページにある削除ボタンをクリックすると完全に
削除することができる。アカウントを削除する前に、専
用サーバーは、今から行う作業をマネージャーに通知し
処理の前に確認を要求する確認ページを出す。メンバー
アカウントが更新或いは削除されると、更新された検分
メンバーウインドウが表示される。マネージャーは、第
二ツールバー１５６にある追加メンバーリンクをクリッ
クすることによりメンバーを追加できる。アカウントマ
ネージャーに、メンバーアカウントの作成に必要とされ
る情報を促すフォーム（図示せず）が表示される。この
フォームは、メンバーが追加されるグループアカウント
と、許可された最大総数に対するメンバー数とを示す。
必要とされる情報には次のことが含まれる。

【００７０】 ・メンバーアカウント名（マネージャーによって作成） ・メンバー名 ・メンバーの電子メールアドレス ・パスワード（及び確認パスワード） 追加（図示せず）をクリックすると新しいアカウントが
作成され、マネージャーは、更新された検分メンバーウ
インドウに戻る。リセット（図示せず）をクリックする
とフォームをクリアーする。個々のアカウントは、アカ
ウントホルダーを除いてはグループメンバーを有してい
ないので、その様な個々のアカウントホルダーは、メン
バー情報ないし機能を有していない。第二ツールバー１
５６は、情報（図示せず）とヘルプ（図示せず）しか含
んでいない。アカウント情報ページから表示される情報
は、現在のメンバー数を除いては、グループアカウント
情報ページから利用可能なものと同じである。

【００７１】メンバーアカウントホルダーは、メンバー
管理機能も有しておらず、第二ツールバーは、情報（図
示せず）とヘルプ（図示せず）のみを含んでいる。メン
バーアカウント情報は、マネージャーが見るのと同じ基
本情報を含んでいる。しかしながら、メンバーは、電子
メールアドレス情報を編集することができるのみであ
る。好適実施例では、メンバーは、メンバーアカウント
情報ページにおいて自分自身のパスワードを変更でき
る。彼らは、現行のパスワードと新しいパスワードを入
力し、次に新しいパスワードを確認しなければならな
い。しかしながら代替実施例では、メンバーは、アカウ
ントマネージャー経由自分のパスワードを変更できるだ
けである。

【００７２】メインツールバー１５４にあるビリングボ
タン１４８で、ビリングコードモード管理とインボイス
機能にアクセスできる。ビリングボタンをクリックする
と、定義されたビリングコードの表３２０が表示され
る。図１９は、本発明の好適実施例に依るビリングコー
ドウインドウ３０８の画面である。第二ツールバー１５
６上のビリング用の第二ナビゲーションは、ビリングコ
ード３１０、追加コード３１２、インボイス作成３１
４、インボイス検分３１６、選択３１８、ヘルプ１５８
を含んでいる。表は、コードの総数及びどれが現在見ら
れていたものかを示す３２２を表示する。本発明の好適
実施例では、ビリングコードは２５文字までの長さで、
英字、数字、文字で構成される。

【００７３】各々のビリングコード３２４は、随意選択
の簡単な英語記述３２６又はそれに関連する名前を有す
る。ビリング選択（参照図２４）において、ユーザー
は、コード又は記述によってビリングコードを分類する
か、及びページ毎に何行表示するかを指定する。選択設
定３２８は、表で表示される。ネクスト３３０とプレビ
アス（図示せず）ボタンに依って、ユーザーは、ビリン
グコードの追加ページを見ることができる。ビリングコ
ードの二つのレベルがグループアカウントに提供されて
いる。グループマネージャーは、全てのグループメンバ
ーがアクセス可能なコードのリストを保守する。グルー
プメンバーは、頻繁に使用されるコードに容易にアクセ
スするためにグループリストから自分自身のコードのサ
ブセットを選択できる。

【００７４】メンバーは、ビリングコードを編集及び作
成できず、マネージャーが作成したリストからコードを
選択して、自分の個人リストに追加しなければならな
い。メンバーは、ビリング選択にグループ或いは個人ビ
リングコードを表示するか否かを指定することができ
る。ホットリンクされたビリングコードをクリックする
と、ユーザーは、コード又はその記述を編集又は削除で
きる。図２０は、本発明の好適実施例に依る編集ビリン
グコードウインドウ３３２の画面である。ユーザーは、
ダイアログにある適切なフィールド３３８、３４０から
ビリングコード又は記述を編集できる。フィールドの情
報はリセットボタン３４２を使ってクリアされる。変更
は、更新３３４をクリックしてセーブされ、ユーザー
は、更新された情報を表示するビリングコード表に戻
る。ユーザーは、このダイアログからコードと記述を削
除３３６することもできる。グループメンバーは、グル
ープビリングコードを編集できないので、グループメン
バーが見る場合、グループビリングコードはホットリン
クされていない。

【００７５】第二ナビゲーションにある追加コード機能
３１２は、個人ビリングコードリストに項目を追加する
ために使用される。図２１は、本発明の好適実施例に依
る追加ビリングコードダイアログ３４４の画面である。
マネージャーと個々のアカウントホルダーは、新しいコ
ードを「ビリングコード入力：」フィールド３４６に入
力する。全ての関連する随意選択記述も、提供されたフ
ォームで「記述：」フィールド３４８に入力される。追
加ボタン３５０がクリックされると、ビリングコードリ
ストに新しい情報が追加される。リプレースボタン３５
２がクリックされると、ビリングコードリストにある情
報が置き換えられる。ビリングコードは、テキストファ
イルからもアップロード３５４できる。ブラウズボタン
３５６は、適切なテキストファイルの位置を突きとめ、
アップロードするために使用される。このテキストファ
イルは、現行のビリングコードリストに置き換えられる
か、又はこれに加えられる。新しいコードが首尾よく加
えられた場合、ユーザーには、更新されたビリングコー
ドリストが提示される。

【００７６】グループメンバーは、コードをグループビ
リングコードリストからの自分の個人コードリストに追
加できるだけである。グループメンバーが追加コードを
クリックすると、グループリストからのコードのリスト
ボックスが提示される。彼らは次にリストボックスから
複数のコードを選択できる。一旦希望のコードが選択さ
れると、メンバーは、追加ボタンをクリックして自分の
個人リストに選択したコードを追加する。インボイス作
成３１４リンクをクリックすると、ユーザーは、インボ
イスを作成できる。図２２は、本発明の好適実施例に依
るインボイス作成ウインドウ３５８の画面である。ダイ
アログは、ユーザーが、どの送付が現在のインボイスに
対する請求なのかを指定することができるサーチスクリ
ーンである。送付は、ビリングコードないし受信者によ
って請求される。

【００７７】ユーザーは、リスト３６０からビリングコ
ードないしビリングコードのセットを選択するか、或い
は受信者の電子メールアドレス３６２を入力する。リス
トには、ビリングコードとビリング選択に示された関連
する記述が含まれている。現在の選択が表示される３６
４。ユーザーは、インボイスのビリング期間３６６に関
する日付範囲も指定する。一旦適切な情報が入力される
と、ユーザーは作成３６８をクリックして、照会を開始
しインボイスを生成する。リセット３７０は、全ての項
目をクリアーする。照会結果は、図２３で示す様に、検
分インボイスモードにある予めフォーマットされた基本
インボイスレポートウインドウ３７２に表示される。ビ
リングコード３７４とビリング期間３７６は、照会結果
を含む表３７８と共に表示される。

【００７８】表は、個々の送付のサブジェクト３８４、
送信日付３９０、受信者３９２を表示する。料金３８０
と送付の総額３８２も示される。インボイスフォーマッ
トは、ビリング選択に記される。個々の送付のサブジェ
クト３８４は、上記の様にパッケージ詳細レポートにホ
ットリンクされる。パッケージ詳細にアクセスすると、
ナビゲーション状態はビリング／検分インボイスのまま
である。インボイス検分３１６をクリックすると、表示
はインボイスレポートに戻る。エクスポートボタン３８
６に依って、ユーザーは、統合のためにタブで区切った
テキストファイルとしてレポートデータを他の現行のビ
リングシステムにエクスポートできる。インボイスレポ
ート選択３８８（利掛け料金は除く）も表示される。

【００７９】ビリング選択３１８に依って、ユーザー
は、ビリングコード管理とインボイスレポートフォーマ
ットに作用する選択を記すことができる。図２４は、本
発明の好適実施例に依るビリング選択ダイアログ３９４
の画面である。プルダウン３９６に依って、グループメ
ンバーは、個人ビリングコードリスト或いはアカウント
マンージャーが保守しているグループビリングコードを
使用するかが選べる。全てのユーザーは、ビリングコー
ド３９８ないし記述４００によってリストを表示する様
選択する。この選択は、送信オプションとインボイス作
成にある選択ボックスでの表示に作用する。選択は、ビ
リングコード表示表の表示にも作用する。表示がビリン
グコードでされる場合、第一コラムはビリングコードで
あり、リストはビリングコードによって分類される。表
示が記述で行われる場合、第一コラムは記述であり、リ
ストは記述により分類される。ユーザーは、ページ毎に
表示される行の数４０２を指定する。

【００８０】ユーザーは、クライアントに請求する料金
４０４を更に記す。この料金は均一料金４０８でもよい
し、ユーザーのインターネットサービスプロバイダが請
求する費用に加えてパーセンテージ利掛け４０６を含ん
でいてもよい。ビリング選択ダイアログに表示される情
報は、更新４０５或いはリフレッシュされる４０７。イ
ンボイスレポートに関して、ユーザーは予め定義された
フォーマット４１０を選択してもよいし、新しいフォー
マットを定義４１２してもよい。好適実施例では、ユー
ザーは、三つの予め定義されたフォーマット、基本イン
ボイス、明細インボイス、ビリングコードインボイスの
各フォーマットから選択する。基本インボイスフォーマ
ットは、既に図２３に示した。図２５は、本発明の好適
実施例に依る明細インボイスフォーマットでのインボイ
スレポートの画面である。明細インボイス４１４は、文
書サイズ４１８だけでなく個々の送付に関する受信者の
総数４１６を表示する。この情報は、入力順に分類され
る。

【００８１】図２６は、本発明の好適実施例に依るビリ
ングコードインボイスフォーマットでのインボイスレポ
ートである。ビリングコードインボイスフォーマット４
２０は、日付同様、ビリングコード４２２によっても分
類される。ＣＵＩに依って、発行者と他のユーザーは配
布リストを作成及び管理できる。図２７は、本発明の好
適実施例に依るメールリストページ４２４の画面であ
る。メールリスト機能は、メインツールバー１５４から
アクセス可能である。第二ナビゲーションは、メールリ
スト４２６、作成リスト４２８、選択５３０、ヘルプ１
５８を含む。グループアカウント用に、メールリストに
二つのレベルがあり、それはグループと個人である。グ
ループリストは、アカウントマネージャーによって管理
されており、全てのグループメンバーがアクセス可能で
ある。グループメンバーは、そのグループメンバーによ
ってのみアクセス可能な個人リストを定義できる。個々
のメンバーは、自分のメールリスト選択の中でどのリス
トのセットを使用するか指定することができる。

【００８２】メインツールバー１５４にあるメールリス
トボタン１５０をクリックすると、現行メールリスト４
３４を表す表４３２を表示する。この表は、個々のメー
ルリストにある受信者の総数４３６とメールリストが最
も最近変更された日付４３８を提示する。選択設定４４
０も表示される。メールリスト選択（図示せず）におい
て、ユーザーは、項目をメールリスト名で分類するか、
日付によって分類するかを指定する。現在の選択が、メ
ールリストダイアログに表示される。ネクストとプレビ
アスボタン（図示せず）が、メールリストのページ間を
ナビゲートするために提供されている。メールリストの
ホットリンクされた名前４４２をクリックすると、選択
されたメールリストに関するメールリスト詳細が出てく
る。図２８は、本発明の好適実施例に依るメールリスト
詳細ウインドウ４４４の画面である。

【００８３】メールリスト詳細ページは現行のメールリ
ストについての一般情報を表示し、ユーザーは、メール
リストアドレスを見たり管理したりできる。グループメ
ンバーは、グループメールリストを操作できない。それ
故、グループリストのメールリスト詳細は、編集のため
のフィールドを表示しない。しかしながらグループメン
バーは、個人メールリストを編集できる。アカウントマ
ネージャーは、グループメールリストを操作できる。ア
カウントマネージャーに提示された詳細４４４は、編集
可能なフォームでメールリストの名前４４６を表示す
る。リストの名前を変えるには、ユーザーは、フォーム
にある名前を変更し、更新ボタン４４８をクリックす
る。ユーザーは、適切なボタンをクリックして、全体の
メールリストを削除４５０、或いはアドレスを追加４５
２できる。送受信者４５４と最後に変更された日付４５
６も表示される。

【００８４】この詳細はメールリストアドレス４５８も
表示する。本発明の好適実施例では、完全なアドレスリ
ストの最初のページは、メールリスト選択で指定された
ページ毎の行数に従って表示される。この詳細は、総ア
ドレスからどのアドレスが表示されているかを示す。ネ
クストとプレビアスリンク（図示せず）は、アドレスの
複数ページ間をナビゲートするために提供される。ユー
ザーは、設けられているフィールド４６０で照会を指定
してアドレスの選択セットを見ることもできる。例え
ば、電子メールアドレス或いはドメイン名の様なアドレ
スの一部分を指定することもできる。検分ボタン４６２
をクリックすると、合致アドレス４５８の表４６４が表
示される。表は、アドレスの総合致セットからどのアド
レス４６６が表示されているかを示す。

【００８５】ユーザーは、提供されたフィールド４６０
に照会を記して、アドレスの選択セットを見ることが更
にできる。例えば、電子メールアドレスないしドメイン
名の様なアドレスの一部分が記される。検分ボタン４６
２をクリックすると、次に合致するアドレス４５８の表
４６４が表示される。表は、アドレスの総合致セットの
中からどのアドレス４６６が表示されているかを示す。
ユーザーは、適切なアドレスをクリックして表にある個
々のアドレスを編集ないし削除する。次に、更新と削除
ボタンを有する編集ページ（図示せず）が表示される。
アドレスが更新ないし削除されると、ユーザーは、更新
されたメールリスト詳細ページに戻る。ユーザーは、詳
細ページから複数のアドレスを一度に削除することもで
きる。「ページ上の項目削除」ボタン４６８をクリック
すると、表にある全てのアドレスが削除される。「全て
の合致項目削除」４７０をクリックすると、アドレスが
現在のページで見えるか否かにかかわらず、照会に合致
する全ての項目が削除される。専用サーバーが実際にア
ドレスを削除する前に、ユーザーに作業を確認する様求
める警告メッセージが表示される。一旦アドレスが削除
されると、詳細ページはすぐに更新されユーザーに示さ
れる。

【００８６】メールリスト詳細４４４にある追加アドレ
スボタン４５２をクリックすると、追加アドレスページ
が表示される。図２９は、本発明の好適実施例に依る追
加アドレスウインドウ４７２の画面である。最新のメー
ルリスト４７４の名前が一番上に表示される。名前は、
メールリスト詳細ページにもリンクされる。ユーザー
は、追加アドレスを、手動入力４７６により、ファイル
からアップロードして、追加できる。ユーザーは、ファ
イル名４７８を入力することもできるし、全てのファイ
ルをサーチするためにブラウズボタン４８０を使うこと
もできる。名前は現行のメールリスト４８２から得て、
最新メールリストに合体させることもできる。追加アド
レスは、最新アドレスリストに追加される４８４か、最
新リストに置き替わる４８６。名前が提示された後、ユ
ーザーは、ほんの今起こったばかりの追加ないし置き換
えを確認する行が一番上についた、更新されたメンバー
詳細ページに戻る。

【００８７】ユーザーは、第二ナビゲーションから作成
リストリンク４２８をクリックすることにより新しいメ
ールリストを作成できる。本発明の好適実施例では、作
成メールリストページ（図示せず）は、追加アドレスペ
ージと同じである。しかしながら、作成メールリストペ
ージでは、ユーザーはメールリストの名前を督促され
る。ユーザーはアドレスを、設けられたテキストボック
スで手動で入力できる。代りに、ユーザーは、ファイル
からアドレスをアップロードするか、又は現行メールリ
ストからアドレスをコピーすることもできる。しかしな
がら、ユーザーが新しいリストを作成するので、現行リ
ストに置き替えるためのオプションはない。追加をクリ
ックすると、指定された名前とアドレスのあるメールリ
ストが作成される。ユーザーに、新しいリスト情報を含
んだ、更新されたメールリストレポートが提示される。

【００８８】本発明は、システムへのアクセスを認めら
れたユーザーに制限する機密保護を更に提供する。本発
明によってサポートされる機密保護のタイプは、認証レ
イヤー、セキュアソケットレイヤー、パスワード保護、
プライベートキー暗号化、パブリックキー暗号化、証明
認証を含む。この機密保護は、送信クライアントアプリ
ケーション、受信クライアントアプリケーション、ＣＵ
Ｉの内の少なくとも一つにおける少なくとも一つの機密
保護モジュールを含む機密保護フレームワークによって
提供される。図３０は、本発明に依る電子ネットワーク
上での文書送付に関する方法のフローチャートである。
送信コンピューターは、例えば、インターネット上でセ
ッション（５００）を確立する。送信コンピューター
は、次に送信クライアントアプリケーションを使ってこ
の電子ネットワーク上で専用サーバー（５０５）に文書
を送付する。

【００８９】送信クライアントアプリケーションは、文
書送信、文書作業リスト表示、文書追跡、文書パラメー
ター指定と記憶、機密保護特徴提供用のモジュールを含
むのが好ましい（５１０）。これらモジュールの幾つか
或いは全ては、特定のセッションの間アクセスできる。
専用サーバーは文書を記憶し（５１５）、電子通知メッ
セージを受信装置に送る（５３０）。専用サーバーはコ
ンフィギュレーションユーザーインターフェース経由で
管理される（５２０）。コンフィギュレーションユーザ
ーインターフェースは機密保護特徴モジュールと同様
に、文書送信、文書追跡、アカウンティング、ビリン
グ、メールリスト生成用のモジュールを含んでいるのが
好ましい（５２５）。

【００９０】通知メッセージに応じて、受信装置は受信
クライアントアプリケーションを使って専用サーバーか
ら文書をダウンロードする（５３５）。受信クライアン
トアプリケーションは、機密保護提供用と同様に文書を
ダウンロード、検分、操作するためのモジュールを含ん
でいるのが好ましい（５４０）。本発明は、本文におい
て好適実施例に関して述べられているが、当業者には、
他の応用例が本発明の精神と範囲から逸脱することなく
本文に述べられているものと取って替われることは既に
明らかであろう。本発明は、よく知られているプログラ
ミング技術と装置を使って当業者により容易に組み立て
られ構成される。例えば、本文に述べられるデスクトッ
プ表示にあるツールバーとメニューの配置と内容は、説
明のためのものである。更に、本発明の機能は、アイコ
ンやキーボードテキスト入力を含む代替方法によってア
クセスされてもよい。

【００９１】本発明の一実施例において、文書送付に関
する通知メッセージは、通知受信装置で受信される。す
ると、文書は、通知受信装置に含まれているか或いはそ
こから独立している受信装置で検索される。例えば、通
知メッセージは、ページャー又はパーソナルデジタルア
シスタントで受信でき、文書は、ウエブブラウザを使っ
てパーソナルコンピューターで受信できる。送信者がデ
ジタル証明登録の実行を一人或いはそれ以上の受信者ク
ライアントに対し開始及び制御できるようにすることに
より、会社、発行者、個人が、送信者操作証明登録シス
テム（ＳＤＣＥ）４２によって、電子的に文書を安全に
配布できるようになる。図３１は、インターネットを含
むネットワーク１３４４を通して、送信コンピューター
１３５２と受信コンピューター１３７０間で実行される
基本証明登録システム１３４２ａを示す。図３２は、送
信コンピューター１３５２、ＳＤＣＥサーバー１３５
８、受信コンピューター１３７０間で実行される証明登
録システム１３４２ｂを示す。図３３は、送信コンピュ
ーター１３５２、ＳＤＣＥサーバー１３５８、データベ
ースサーバー１３６２、受信コンピューター１３７０間
で実行される証明登録システム１３４２ｃを示す。図３
４は、送信コンピューター１３５２、ＳＤＣＥサーバー
１３５８、データベースサーバー１３６２、証明サーバ
ー１３８８、受信コンピューター１３７０間で実行され
る証明登録システム１３４２ｄを示す。

【００９２】送信者操作証明登録システム１３４２によ
って、文書１３１２の送信者１３５２は、文書の対象受
信者１３７０のためにデジタル証明１３４５の生成（図
３５参照）を開始できる。文書１３１２は、特定コンピ
ューターファイル又はより一般的なあらゆる個別データ
の集まりを意味する。送信者操作証明登録システム１３
４２は、文書の対象受信者１３７０のためのデジタル証
明生成に関連する複雑さを単純にし、証明生成の基本的
な負担を（現在多くのシステムがサポートしている）受
信者１３７０から送信者１３５２へ移す。図３５は、デ
ジタル証明１３４５を示しており、パブリックキー１３
３２とプライベートキー１３４０から成るキーペアー示
しており、パブリックキー１３３２は、対象受信者１３
７０の様な特定のエンティティに関連付けられ、発行さ
れる。

【００９３】安全な文書送付に関連する主要問題の一つ
は、対象受信者１３７０のパブリックキー１３３２を使
って文書を暗号化１３１２する試みから生ずる。特に、
文書の対象受信者１３７０がデジタル証明１３４５を持
っていない場合である。送信者１３５２がアクセス可能
な受信者１３７０のデジタル証明１３４５が無い場合
は、文書１３１２の送信者１３５２は、受信者のパブリ
ックキー１３３２を使って文書１３１２を暗号化でき
ず、その結果、文書１３１２が招かざるアクセスから保
護されることを保証できない。送信者操作証明登録シス
テム１３４２に依って、文書１３１２の送信者１３５２
は、対象受信者１３７０のためにデジタル証明１３４５
を活動的に生成する処理を開始し、それによって対象受
信者１３７０に課す要求は最小限になる。

【００９４】送信者操作証明登録システム１３４２は、
証明生成の負担を所定の文書１３１２の受信者１３７０
から送信者１３５２に移す。送信者操作証明登録システ
ム１３４２は、文書送付に関連して、文書１３１２の送
信者１３５２が多くの場合対象受信者に関する独特且つ
特定の情報を持っている事実を利用する。例えば、弁護
士がクライアント１３７０に文書を送信すると仮定す
る。弁護士１３５２は、クライアントの電子メールアド
レス、実際のアドレス、電話番号の様な特定情報を含む
クライアント１３７０に関連する記録を所有しているは
ずである。クライアント記録は、クライアントの社会保
障番号、運転免許証番号、更にはクレジット情報の様な
極秘情報も含んでいるかもしれない。一般的に所定の個
人或いはエンティティ１３７０を認証するために利用さ
れるのは、このタイプの極秘情報であり、その結果デジ
タル証明１３４５が生成されるのである。極秘性の高く
特別な情報は、高レベルの認証を生み出し、その結果
が、安全なデジタル証明である。

【００９５】それ故、送信者操作登録システム１３４２
は、送信者１３５２が文書１３１２の対象受信者１３７
０に関する重要な極秘情報を多くの場合知っているとい
う事実を利用する。デジタル証明１３４５を生成するた
めに送信者１３５２がこの極秘情報を使用することによ
って、受信者１３７０にその身元を確認するために課さ
れる負担は最小になる。送信者１３５２は、デジタル証
明１３４５を使って、文書１３１２を対象受信者１３７
０に安全に送信する。システム実行。上記例において、
送信者である弁護士１３５２は、対象受信者であるクラ
イアント１３７０に極秘文書を送信したい。弁護士１３
５２がアクセス可能なデジタル証明１３４５を現在持っ
ていないクライアント１３７０に対して、弁護士１３５
２は、クライアント１３７０用のデジタル証明１３４５
を生成するため、送信者操作登録システム１３４２を呼
び出すことができる。

【００９６】最初に、送信者操作登録システム１３４２
は、デジタル証明１３４５が受信者であるクライアント
１３７０用にあるかどうかを決めるために、データベー
ス１３４６をチェックないし照会する。無い場合、送信
者操作登録システム１３４２は、一般的にはクライアン
トの特定且つ極秘情報を含むクライアント１３７０に関
する記録を引き出すためにデータベース照会を行う。送
信者操作登録システム１３４２は次に、図３６に示す様
に、証明要覧１３４７を生成する。この証明要覧１３４
７は、クライアント特定データ１３４８、生成する証明
の型１３４９（例えばＸ．５０９証明）を含むクライア
ント１３７０に関するデジタル証明生成に必要な情報の
殆どを含んでいる。好適実施例では、証明要覧１３４７
は、安全なＳＤＣＥサーバー１３５８に送られる。ＳＤ
ＣＥサーバー１３５８は次に、極秘情報１３４８の独立
確認を求めてクライアント１３７０に「コンタクト」す
る。例えば、本発明の好適実施例では、ＳＤＣＥサーバ
ー１３５８は、独自の動的生成されたＵＲＬ（ユニフォ
ームリソースロケータ）を使ってクライアント１３７０
に電子メールメッセージを送る。すると、クライアント
１３７０は、標準ウエブブラウザを通してこのＵＲＬに
「クリック」或いはアクセスできる。ＵＲＬにアクセス
すると、クライアント１３７０とＳＤＣＥサーバー１３
５８間で直接対話或いはＳＤＣＥ会話１３６８が始ま
る。

【００９７】クライアント１３７０は一般的に、一つ或
いはそれ以上の極秘情報１３４８をＳＤＣＥサーバー１
３５８に入力する様求められる。好適実施例では、会話
は、クライアント１３７０とＳＤＣＥサーバー１３５８
の間のセキュアソケットレイヤー（ＳＳＬ）上で行わ
れ、ＨＴＭＬフォームを利用する。ＳＤＣＥサーバー１
３５８は次に、入力された情報を記憶された証明要覧１
３４７内にある記憶されたクライアント情報と比較し
て、クライアント１３７０が正しいかどうか立証する。
合致すると、ＳＤＣＥサーバー１３５８は、安全なチャ
ンネル上で受信者クライアントデスクトップ１３７２に
証明要覧１３４７を送り、受信者システム上でキーペア
ー１３３２、１３４０を生成するために証明要覧１３４
７を使用するソフトウエアを受信クライアント１３７０
に配布する。本発明の好適実施例では、このソフトウエ
アは、簡単なジャバアプレットであり、ブラウザを通し
て受信者１３７０に包み隠さず送られる。生成されたプ
ライベートキー１３３２は、好ましくはＰＫＣＳ１２フ
ォーマットを使って、受信者システム１３７０に記憶さ
れる。パブリックキー１３３２はＳＤＣＥサーバー１３
５８に戻されるが、このＳＤＣＥサーバー１３５８は普
通、パブリック及びクライアント情報の両方をデジタル
証明１３４５として、ＬＤＡＰないし（カナダ、オタワ
のエントラスト株式会社の）エントラスト証明管理サー
バーの様な証明サーバー１３８８上で記録している。

【００９８】これで、送信者（例えば弁護士）１３５２
は、対象受信者クライアント１３７０用の記憶されたパ
ブリックキー１３３２にアクセスし、パブリックキー１
３３２を使って受信者クライアント１３７０を対象とし
た文書１３１２を暗号化し、そして、暗号化された文書
１３３６をクライアント１３７０に送信することができ
る。次に、クライアント１３７０が、個人受信者システ
ム１３７０に現在ある（パブリックキーと）対応するプ
ライベートキー１３４０を使って暗号化された文書１３
３６を解読する１３３８。図３７は、送信者操作証明登
録システム１３４２の第一段階を示す。送信者１３５２
はステップ１３５６で、ＳＤＣＥサーバー１３５８にコ
ンタクトし、受信者を確認するために電子メールアドレ
スの様な基本情報を送って、受信者１３７０に関する証
明の生成を開始する。

【００９９】ＳＤＣＥサーバー１３５８は次にステップ
１３６０で、社会保障或いは個人アドレスの様な対象受
信者１３７０に特定の極秘情報１３４８に関するデータ
ベース１３４６を照会する。データベース１３４６は、
独立データベースサーバー１３６２内或いはＳＤＣＥサ
ーバー１３５８内の様ないろいろな場所のどこにあって
もよい。使用可能極秘情報１３４８が対象受信者１３７
０のためににある場合、ステップ１３６４で、データ記
録としてＳＤＣＥサーバー１３５８に送られる。ＳＤＣ
Ｅサーバー１３５８は次にステップ１３６５で、データ
記録を使って証明要覧１３４７を生成するが、これは後
で、受信者１３７０を立証し、デジタル証明１３４５を
生成するために使用されることになる。

【０１００】図３８は送信者操作証明登録システム１３
４２の第二段階１３６６を示すが、これは立証会話と呼
ばれる。ＳＤＣＥサーバー１３５８は証明要覧１３４７
を取り、ステップ１３６８で、文書１３１２の対象受信
者１３７０と直接対話を開始する。この直接対話１３６
８は、対象受信者１３７０にクライアント特定データ１
３４８を要請する。本発明の好適実施例では、ＳＤＣＥ
サーバー１３５８は、動的に生成されたユニフォームリ
ソースロケータ（ＵＲＬ）を使って電子メールメッセー
ジを送信する。生成されたＵＲＬをクリックして、受信
者１３７０は、ＳＤＣＥサーバー１３５８との直接対話
１３６８を呼び出す。この時点で、ＳＤＣＥサーバー１
３５８は、受信者１３７０からの特定情報を要請するＨ
ＴＭＬフォームを提示する。

【０１０１】ＨＴＭＬフォームと要求される個人情報１
３４８は、受信者１３７０に送信される文書１３１２に
要望される機密保護のレベルによって変わってもよい。
例えば、高い機密保護レベルを必要としない文書の場
合、フォームは確認ボタンを要求するだけでもよい。高
い機密保護レベルを必要とする文書の場合、フォームは
対象受信者１３７０に、個人アドレス、社会保障番号、
被雇用者番号、個人身分証明番号（ＰＩＮ）の様な特定
個人情報１３４８の提示を求めてもよい。本発明の好適
実施例では、ＳＤＣＥサーバー１３５８と受信者１３７
０の間のこの対話は、ＳＳＬを使って安全なチャンネル
上で行われる。送られた個人情報１３４８を使って、ス
テップ１３７４の間、ＳＤＣＥサーバーは、送られたデ
ータ１３４８を対象受信者１３７０に関する証明要覧１
３４７と比較して受信者１３７０を立証する。送られた
情報１３７４と証明要覧１３４７に適切に記憶された情
報１３４８が合致する場合、受信者１３７０はステップ
１３７５で認証され、処理は次の段階に続く。送られた
情報１３７４と証明要覧１３４７に適切に記憶された情
報１３４８が合致しない場合、送信者１３５２には、デ
ジタル証明１３４５が生成されていないと通知される
（図４１）。

【０１０２】図３９は、送信者操作証明登録システム１
３４２の第三段階１３７６を示し、これはパブリック／
プライベートキーペアー生成と呼ばれる。立証会話段階
１３６６上で要請された個人情報１３７４が、ＳＤＣＥ
サーバー１３５８で証明要覧１３４７に合致したと仮定
すると、ＳＤＣＥサーバー１３５８は次にステップ１３
７８で、ソフトウエアと証明要覧１３４７を受信者シス
テム１３７０に送る。送られたソフトウエアは、証明要
覧１３４７と受信者コンピューター１３７０に特有の情
報を利用し、プライベート／パブリックキーペアー１３
３２、１３４０から成るデジタル証明１３４５を生成す
る。キーペアー１３３２、１３４０は、送信され、送信
者システム１３５２で局地的に記憶される。好適実施例
では、パブリック／プライベートキーペアー１３３２、
１３４０は、ＰＫＣＳ１２フォーマットに記憶される。
次に、パブリックキー１３３２と受信者１３７０に関す
る証明要覧１３４７のリファランスは、受信者１３７０
からＳＤＣＥサーバー１３５８に送られる。

【０１０３】図４０は、送信者操作証明登録システム１
３４２の第四段階１３４８を示し、これは受信者パブリ
ックキー１３３２の送信と登録と呼ばれる。処理のこの
段階で、対象受信者１３７０に関するパブリックキー１
３３２は、受信者システム１３７０からＳＤＣＥサーバ
ー１３５８に送られる。ＳＤＣＥサーバー１３５８はス
テップ１３８６で、デジタル証明１３４５として結合さ
れたパブリックキー１３３２と証明要覧１３４７を証明
サーバー１３８８に送る。好適実施例では、証明サーバ
ー１３８８は、ＬＤＡＰ（ライトウエイトディレクトリ
アクセスプロトコル）サーバーである。次に、ＳＤＣＥ
サーバー１３５８は、図３で示す様に文書１３１２が受
信者１３７０のパブリックキー１３３２を使って現在暗
号化１３３４できることを示す通知を、ステップ１３９
０で送信者１３５２に送信する。次に、暗号化された文
書１３３６は、一般的にはネットワーク又はインターネ
ットアーキテクチャ１３４４を通して受信者１３７０に
送付される。受信者１３７０は次に、図４に示す様に、
情報を解読するために自分自身のプライベートキー１３
４０を使う。

【０１０４】実行。このセクションは、送信者操作証明
登録システム１３４２を構成するための構成要素の全体
像を提供する。証明サーバー１３８８の様な構成要素の
幾つかは、カスタマゼーション或いは展開を必要としな
い。図４１は、システムに関するコントロールの流れを
説明する基本フローチャートである。送信者デスクトッ
プクライアントソフトウエア。送信者コンピューター１
３５２のデスクトップ１３５４上では、送信者操作証明
登録システム１３４２は、受信者１３７０と関連するパ
ブリックキー１３３２を照会するためにＳＤＣＥサーバ
ー１３５８及び証明サーバー１３８８に通信するソフト
ウエアを含んでいる。受信者ソフトウエア構成要素は、
受信者１３７０に関するパブリックキー１３３２の検索
時に、通常パブリックキー１３３２を使って文書１３１
２を暗号化し、次に受信者１３７０へ続いて送付するた
めに文書をＳＤＣＥサーバー１３５８に送る。

【０１０５】ＳＤＣＥサーバーソフトウエア。ＳＤＣＥ
サーバーソフトウエアは、本発明の好適実施例では、全
てのＨＴＴＰ要求を遮断し、転送するためのカスタマイ
ズされたフィルターを有するＨＴＴＰウエブサーバー
と、通知を対象受信者１３７０に送る電子メールサーバ
ーと、データベースサーバーを照会し、証明要覧１３４
７を生成し（上記記載）、システムの全ての他の構成要
素と対話するための基本ソフトウエアとロジックとを含
んでいる。ウエブサーバーは、ＳＤＣＥサーバー１３５
８と文書１３１２の対象受信者１３７０間の主たるイン
ターフェースであり、そこでＳＤＣＥサーバー１３５８
はデジタル証明１３４５の構築を援助する。本発明の好
適実施例では、ＳＤＣＥサーバーソフトウエアは、動的
に個人ＵＲＬを生成して、対象受信者１３７０と立証会
話１３６６（図３８）を開始する。個人ＵＲＬは、受信
者１３７０を独自に確認するキーを含み、次にこの「キ
ー」を標準電子メール通知上で受信者に送る。受信者１
３７０が（実際は個人ＵＲＬである）この「キー」にア
クセスすると、ＳＤＣＥサーバー１３５８はキーを所定
の証明要覧１３４７と関連付け、次にウエブインターフ
ェースを通して、立証会話１３６６を行い、所与の受信
者１３７０が証明要覧１３４７のパラメーターに合致す
ることを証明する。

【０１０６】受信者クライアントソフトウエア。送信者
操作証明登録システム１３４２は、証明要覧１３４７か
らパブリック／プライベートキーペアーを作成し、これ
は、ＳＤＣＥサーバー１３５８から受信者システム１３
７０に送られる。受信者コンピューターにあるクライア
ントソフトウエアは、証明要覧１３４７を取り、受信者
デスクトップ１３７２でパブリック／プライベートキー
ペアー１３３２、１３４０を構成し、受信者システム１
３７０でこれらのキー１３３２、１３４０を記憶し、次
にパブリックキー１３３２をＳＤＣＥサーバー１３５８
に送る。ある好適実施例では、受信者クライアントソフ
トウエアは、ジャバアプレットであり、ウエブブラウザ
経由で包み隠さず且つ動的にダウンロードされ、これを
使って、受信者は上記の様にＵＲＬに簡単にアクセスす
る。

【０１０７】証明サーバー。本発明は、基本デジタル証
明管理を利用している。証明サーバー１３８８は、デジ
タル証明が受信者所定特定ユーザープロファイル（例え
ば電子メールアドレス及び識別名）があるかどうか決定
する照会能力を含む。証明サーバー１３８８は、更新能
力も含んでおり、プログラム上のインターフェースが新
しい証明をサーバーのデータベースに追加できるように
なっている。好適実施例では、ＬＤＡＰ、Ｘ．５００、
或いはエントラストサーバーの様な占有の証明サーバー
は証明サーバー１３８８として使用できる。データベー
スサーバー。本発明の好適実施例では、ＳＤＣＥサーバ
ー１３５８は、証明要覧１３４７を構成するために受信
者情報を含むデータベース１３４６を照会する。基本実
施例では、送信者のデスクトップ１３５４は、内部デー
タベース１３４６を照会でき、又、送信者のデスクトッ
プ１３５４は、デスクトップ１３５４から直接情報を簡
単にロードできる。ＳＤＣＥサーバー１３５８によって
提供される好適データベース照会は、更なる規模と拡張
性をサポートする。

【０１０８】本発明の基本設計に加えて、デスクトップ
１３５４から直接に、又はデータベース照会経由での何
れかで送信者システム１３５２から容易にアクセス可能
な受信者データ１３４８が無い場合の状況が残ってい
る。この場合、送信者操作登録システム１３４２はなお
価値を持ち続ける。証明要覧１３４７は制限された情報
１３４８を含んでいるが、立証のレベルも又制限されて
いる。しかしながら、基本立証はなお行え、システム１
３４２は、受信者１３７０のために基本デジタル証明１
３４５を生成する処理をなお簡素化する。この場合、シ
ステムは、より単純化された会話１３６６と証明要覧１
３４７であることを除いて、設計された様に正確に作動
する。図４１は、送信者操作登録システム１３４２の後
ろにある基本決定ツリーを説明するフローチャート１３
０２である。

【０１０９】ステップ１０２で、送信者１３５２は、文
書１３１２に関する対象受信者１３７０のパブリックキ
ー１３３２を証明サーバー１３８８に照会する。パブリ
ックキー１３３２がある場合、文書１３１２は、パブリ
ックキー１３３２を使って暗号化され、ステップ１０４
で受信者１３７０に送信される。パブリックキー１３３
２が存在しない場合、送信者は、ステップ１３５６で対
象受信者１３７０に関する証明要覧１３４７をＳＤＣＥ
サーバー１３５８に照会する。ＳＤＣＥサーバー１３５
８は次にステップ１３６０で、対象受信者１３７０に関
する情報１３４８をデータベース１３４６に照会する。
情報が在り、データベース１３４６に既に記憶されてい
る場合、ＳＤＣＥサーバー１３５８は、ステップ１３６
５でクライアント１３７０に関する豊富な証明要覧を生
成する。情報１３４８が無く、データベース１３４６に
記憶されていない場合、ＳＤＣＥサーバー１３５８は、
ステップ１３６４で簡素化された承認要覧１３４７を生
成する。

【０１１０】ステップ１３６８で、ＳＤＣＥサーバー１
３５８は、受信者１３７０と立証会話１３６６を開始す
る。情報１３４８に合致しない場合、ＳＤＣＥサーバー
１３５８は、ステップ１０６で送信者に通知し、キーペ
アー１３３２、１３４０の生成は行われない。合致して
いれば、ステップ１３８０で、受信者１３７０に関する
プライベート／パブリックキーペアー１３３２、１３４
０が受信者システム１３７０において生成される。次に
ステップ１３８２で、キーペアーはＳＤＣＥサーバー１
３５８に送られる。ステップ１３８８で、ＳＤＣＥサー
バーは、証明サーバー１３８８を使って対象受信者１３
７０に関する証明を登録する。ステップ１３９０で、Ｓ
ＤＣＥサーバーは、送信者１３５２にデジタル証明１３
４５を通知する。すると、送信者１３５２は、図３に示
す様に対象受信者１３７０の生成されたパブリックキー
１３３２を使って文書１３１２を暗号化できる。暗号化
された文書１３３６が、一般的にはネットワーク１３４
４上で受信者１３７０に送信されると、受信者１３７０
は、図４に示す様に記憶されたプライベートキー１３４
０を使って暗号化された文書１３３６を解読できる。

【０１１１】送信者操作証明登録システムとその使用方
法がインターネットでの使用と結びつけて本文で説明し
てあるが、本発明は、希望されるインターネット、イン
トラネット、ＬＡＮｓとＷＡＮｓ、ないしそれらの全て
の組み合わせを含む幅広い種類のネットワークの何れに
も適用できる。その上、本発明は、希望される、広範な
種類のコンピュータープラットフォーム、サーバー、通
信プロトコル、暗号作成プロトコル、或いはそれらの全
ての組み合わせにも適用できる。本発明は、特定の好適
実施例に関して詳細に説明してきたが、本発明が関係す
る当業者には、請求項の精神と範囲から逸脱することな
く様々な変更修正と改良がなされることは明白である。
従って、本発明は請求項によってのみ制限されるもので
ある。

【図面の簡単な説明】

【図１】文書のシークレットキー暗号化のブロック線図
である。

【図２】文書のシークレットキー解読のブロック線図で
ある。

【図３】文書のパブリックキー暗号化のブロック線図で
ある。

【図４】文書のプライベートキー解読のブロック線図で
ある。

【図５】本発明に依る文書送付システムの線図である。

【図６】本発明に依るアプリケーションウインドウの画
面である。

【図７】本発明に依る文書作業を示すアプリケーション
ウインドウの画面である。

【図８】本発明の好適実施例に依るパッケージウインド
ウの画面である。

【図９】本発明に依る受信者のウインドウの画面であ
る。

【図１０】本発明に依るＣＵＩアプリケーションウイン
ドウの画面である。

【図１１】本発明に依るＣＵＩパッケージウインドウの
画面である。

【図１２】本発明に依るＣＵＩオプションページの画面
である。

【図１３】本発明に依るＣＵＩ追跡サーチページの画面
である。

【図１４】本発明に依るＣＵＩ追跡レポート選択ダイア
ログの画面である。

【図１５】本発明に依る、基本フォーマットにおける受
信者要約追跡レポートの画面である。

【図１６】本発明に依る、基本フォーマットにおける受
信者詳細追跡レポートの画面である。

【図１７】本発明に依る、ビリングコードフォーマット
における受信者詳細追跡レポートの画面である。

【図１８】本発明に依る、グループアカウントマネージ
ャーアカウント−検分メンバーウインドウの画面であ
る。

【図１９】本発明に依るビリングコードウインドウの画
面である。

【図２０】本発明に依る編集ビリングコードダイアログ
の画面である。

【図２１】本発明に依る追加ビリングコードダイアログ
の画面である。

【図２２】本発明に依るインボイス作成ページの画面で
ある。

【図２３】本発明に依る基本インボイスレポートウイン
ドウの画面である。

【図２４】本発明に依るビリング選択ダイアログの画面
である。

【図２５】本発明に依る、特定インボイスフォーマット
におけるインボイスレポートの画面である。

【図２６】本発明に依る、ビリングコードインボイスフ
ォーマットにおけるインボイスレポートの画面である。

【図２７】本発明に依るメールリストページの画面であ
る。

【図２８】本発明に依るメールリスト詳細ページの画面
である。

【図２９】本発明に依る追加アドレスページの画面であ
る。

【図３０】本発明に依る、電子ネットワーク上での文書
送付に関する方法のフローチャートである。

【図３１】ネットワーク上での送信コンピューターと受
信コンピューター間で実行される基本証明登録システム
を示す。

【図３２】送信コンピューター、ＳＤＣＥサーバーと受
信コンピューター間で実行される証明登録システムを示
す。

【図３３】送信コンピューター、ＳＤＣＥサーバー、デ
ータベースサーバーと受信コンピューター間で実行され
る証明登録システムを示す。

【図３４】送信コンピューター、ＳＤＣＥサーバー、デ
ータベースサーバー、証明サーバーと受信コンピュータ
ー間で実行される証明登録システムを示す。

【図３５】デジタル証明のブロック線図である。

【図３６】証明要覧のブロック線図である。

【図３７】送信者操作の証明登録システムにおける操作
の第一段階を示す。

【図３８】送信者操作の証明登録システムの第二の立証
対話段階を示す。

【図３９】送信者操作の証明登録システムの第三のパブ
リック／プライベートキーペアー生成段階を示す。

【図４０】送信者操作の証明登録システムの第四段階を
示し、受信者パブリックキーの送信と登録と呼ばれる。

【図４１】送信者操作の証明登録システムにおける基本
決定ツリーを示すフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｈ０４Ｌ 9/32 Ｈ０４Ｌ 9/00 ６７５Ｂ 12/54 11/20 １０１Ｂ 12/58 (72)発明者 ジャン クリストフ バンディーニ アメリカ合衆国 カリフォルニア州 95014 クーパーティノ ノース フット ヒル ブールヴァード 10230−イ−10 (72)発明者 ランディー シュープ アメリカ合衆国 カリフォルニア州 94114 サン フランシスコ ダイアモン ド ストリート 9054

Claims (44)

【特許請求の範囲】
1. 【請求項１】 セッションの間、電子ネットワーク上で
   送信コンピューターから単一パッケージとして少なくと
   も一つの文書を送付するための送信クライアントアプリ
   ケーションと、送信コンピューターからの前記少なくと
   も一つの文書を記憶し、電子メッセージを受信装置に送
   るための専用サーバーと、電子メッセージに応じて専用
   サーバーから前記少なくとも一つの記憶された文書をダ
   ウンロードし、見て、及び／又は操作するための前記受
   信装置上の受信クライアントアプリケーションとから成
   ることを特徴とする装置管理及びデリバリシステム。
2. 【請求項２】 前記送信クライアントアプリケーション
   が、文書送付のパラメーターを指定するためのパッケー
   ジウインドウを更に含むことを特徴とする請求の範囲第
   １項に記載の装置。
3. 【請求項３】 前記送信クライアントアプリケーション
   が、前記指定された文書デリバリパラメーターを構成可
   能に記憶するための記憶モジュールを更に含み、前記文
   書送付が前記記憶された文書デリバリパラメーターを使
   って開始されることを特徴とする請求の範囲第１項に記
   載の装置。
4. 【請求項４】 前記送信クライアントアプリケーション
   が、前記送信コンピューター上でサポートされているア
   プリケーションからアドレスブックにアクセスするため
   のモジュールを更に含み、前記文書送付が前記アドレス
   ブックの内容を使って開始されることを特徴とする請求
   の範囲第１項に記載の装置。
5. 【請求項５】 前記文書が、前記文書を選択して、アプ
   リケーションウインドウ、パッケージウインドウ、前記
   クライアントアプリケーションを表すアイコン、又は前
   記記憶された文書デリバリパラメーターにアクセスする
   ためのアイコンの何れか一つの上にドラッグすることに
   よって、送付されることを特徴とする請求の範囲第１項
   に記載の装置。
6. 【請求項６】 前記コンフィギュレーションユーザーイ
   ンターフェースが、前記文書を送信するための送信モジ
   ュールと、前記文書を追跡するためのトラッキングモジ
   ュールと、文書デリバリアカウントに関連する情報にア
   クセスするためのアカウントＣＵＩと、前記文書送付に
   関するビリングを管理するためのビリングモジュール
   と、メール配布リストを作成し管理するためのメールリ
   ストモジュールとから成ることを特徴とする請求の範囲
   第１４項に記載の装置。
7. 【請求項７】 前記装置及び／又は前記文書へのアクセ
   スを制限するための機密保護フレームワークを更に含
   み、前記機密保護フレームワークが、前記送信クライア
   ントアプリケーション、前記受信クライアントアプリケ
   ーション、コンフィギュレーションユーザーインターフ
   ェースの内の少なくとも一つの中に少なくとも一つの機
   密保護モジュールを有することを特徴とする請求の範囲
   第１項に記載の装置。
8. 【請求項８】 前記機密保護フレームワークが、認証レ
   イヤー、セキュアソケットレイヤー、パスワード保護、
   プライベートキー暗号化、パブリックキー暗号化、証明
   認証の内少なくとも一つをサポートしていることを特徴
   とする請求の範囲第１９項に記載の装置。
9. 【請求項９】 専用サーバー上に記憶された少なくとも
   一つの文書を電子ネットワーク上にある通知受信装置に
   電子的に通知するための専用サーバーと、前記通知に応
   じて前記少なくとも一つの文書を受信するための前記電
   子ネットワーク上にある受信装置とから成り、前記受信
   装置が前記専用サーバーから前記文書をダウンロードす
   るために受信クライアントアプリケーションを使用する
   ことを特徴とする電子ネットワークのための文書管理及
   びデリバリ装置。
10. 【請求項１０】 前記受信装置が前記通知受信装置を含
    むことを特徴とする請求の範囲第９項に記載の装置。
11. 【請求項１１】 ウエブブラウザ経由で前記専用サーバ
    ーを管理するためのコンピューターデスクトップ上のＨ
    ＴＭＬインターフェースを更に含むことを特徴とする請
    求の範囲第９項に記載の装置。
12. 【請求項１２】 セッションの間、前記電子ネットワー
    ク上で送信コンピューターの前記デスクトップから単一
    パッケージとして前記少なくとも一つの文書を送付する
    ための送信クライアントアプリケーションを更に含むこ
    とを特徴とする請求の範囲第９項に記載の装置。
13. 【請求項１３】 前記送信クライアントアプリケーショ
    ンが、前記送信クライアントアプリケーションの主要な
    機能にアクセスするためのツールバーと、送信クライア
    ントアプリケーションセッションの間に開始された全て
    の文書作業をリスト表示するためのパッケージマネージ
    ャーと、前記送信クライアントアプリケーションのため
    の操作コマンドをリスト表示するメニューとから成る送
    信クライアントアプリケーションインターフェースを表
    示するためのアプリケーションウインドウと、前記文書
    送付のパラメーターを指定するためのパッケージウイン
    ドウと、前記文書送付が記憶された文書デリバリパラメ
    ーターを使って開始される、そのような、前記文書デリ
    バリパラメーターを構成可能に記憶するための記憶モジ
    ュールとから成ることを特徴とする請求の範囲第１２項
    に記載の装置。
14. 【請求項１４】 前記装置及び／或いは前記文書へのア
    クセスを制限する機密保護フレームワークを更に含むこ
    とを特徴とする請求の範囲第２４項に記載の装置。
15. 【請求項１５】 送信クライアントアプリケーションを
    使用ってセッションの間に電子ネットワーク上で送信コ
    ンピューターから専用サーバーへ単一パッケージとして
    少なくとも一つの文書を送付する段階と、前記専用サー
    バー上に前記送信コンピューターからの少なくとも一つ
    の文書を記憶する段階と、電子メッセージを前記専用サ
    ーバーから受信装置に送る段階と、電子メッセージに応
    じて前記受信装置上の受信クライアントアプリケーショ
    ンを使って前記専用サーバーから少なくとも一つの記憶
    された文書をダウンロードする段階とを含むことを特徴
    とする電子ネットワーク上での文書管理とデリバリのた
    めの方法。
16. 【請求項１６】 前記送信コンピューターデスクトップ
    が、前記送信クライアントアプリケーションの主要な機
    能にアクセスするためのツールバーと、前記セッション
    の間に開始される全ての文書作業をリスト表示するため
    のパッケージマネージャーと、前記送信クライアントア
    プリケーションに関する操作コマンドをリスト表示する
    メニューとを有する送信クライアントアプリケーション
    インターフェースを持ったアプリケーションウインドウ
    を表示する段階を更に含むことを特徴とする請求の範囲
    第１５項に記載の方法。
17. 【請求項１７】 前記指定された文書デリバリパラメー
    ターを記憶モジュール内に構成可能に記憶する段階を更
    に含み、且つ、前記文書送付が前記記憶された文書デリ
    バリパラメーターを使って開始されることを特徴とする
    請求の範囲第４０項に記載の方法。
18. 【請求項１８】 前記システムへのアクセスを制限する
    ために、認証レイヤー、セキュアソケットレイヤー、パ
    スワード保護、プライベートキー暗号化、パブリックキ
    ー暗号化、証明認証の内の少なくとも一つをサポートす
    る機密保護フレームワークを提供する段階を更に含むこ
    とを特徴とする請求の範囲第１５項に記載の方法。
19. 【請求項１９】 前記送信コンピューター上にサポート
    されたアプリケーションのアドレスブックの内容から前
    記文書送付を開始する段階を更に含むことを特徴とする
    請求の範囲第１５項に記載の方法。
20. 【請求項２０】 コンピューターデスクトップ上で前記
    専用サーバーを管理するために、コンフィギュレーショ
    ンユーザーインターフェースの主要な機能にアクセスす
    るためのメインツールバーと、前記主要な機能内の機能
    にアクセスするための第二次ツールバーと、アクセスし
    た機能との対話型インターフェースを表示するためのワ
    ークスペースと、前記コンフィギュレーションユーザー
    インターフェースに関する操作コマンドをリスト表示す
    るメニューとを有するコンフィギュレーションユーザー
    インターフェースアプリケーションを表示する段階を含
    むことを特徴とする請求の範囲第１５項に記載の方法。
21. 【請求項２１】 送信者が使用する送信コンピューター
    と、受信者が使用する受信コンピューターと、受信者情
    報を記憶するためのデータベースと、前記送信者が前記
    記憶された受信者情報に関する前記データベースを照会
    するための手段と、前記受信者から個人受信者情報を集
    めるための手段と、前記集められた個人受信者情報と前
    記記憶された受信者情報を比較するための手段と、前記
    受信コンピューターでパブリックキーとプライベートキ
    ーとから成るデジタル証明を制御可能に生成するための
    手段と、前記デジタル証明を記憶するための手段と、前
    記パブリックキーを前記送信コンピューターに送信する
    手段とから成ることを特徴とする、送信者が受信者のた
    めにデジタル証明を生成するための装置。
22. 【請求項２２】 前記送信コンピューターと前記受信コ
    ンピューターとの間に置かれるサーバーを更に含むこと
    を特徴とする請求の範囲第２１項に記載の装置。
23. 【請求項２３】 受信者情報を記憶するための前記デー
    タベースが前記サーバーにあることを特徴とする請求の
    範囲第２２項に記載の装置。
24. 【請求項２４】 前記送信者が、前記記憶された受信者
    情報を前記データベースに照会するための前記手段が前
    記サーバーにあることを特徴とする請求の範囲第２２項
    に記載の装置。
25. 【請求項２５】 前記受信者から個人受信者情報を集め
    るための前記手段が前記サーバーにあることを特徴とす
    る請求の範囲第２２項に記載の装置。
26. 【請求項２６】 前記集められた個人受信者情報と前記
    記憶された受信者情報を比較するための手段が前記サー
    バーにあることを特徴とする請求の範囲第２２項に記載
    の装置。
27. 【請求項２７】 前記デジタル証明を記憶するための前
    記手段が前記サーバーにあることを特徴とする請求の範
    囲第２２項に記載の装置。
28. 【請求項２８】 前記記憶された受信者情報と前記デジ
    タル証明に関する送信者選択可能オプションとから成る
    証明要覧を更に含むことを特徴とする請求の範囲第２１
    項に記載の装置。
29. 【請求項２９】 記憶された受信者情報に関するデータ
    ベースを照会する段階と、受信者から情報を集める段階
    と、前記集められた情報を前記照会され記憶された受信
    者情報と比較する段階と、前記比較を基にして前記受信
    者にソフトウエアを選択的に送信する段階と、前記ソフ
    トウエアを使って前記受信者においてパブリックキーと
    プライベートキーとから成る前記デジタル証明を選択的
    に生成する段階とから成ることを特徴とする送信者が受
    信者のためにデジタル証明を生成するための方法。
30. 【請求項３０】 前記デジタル証明のコピーを前記送信
    者に送信する段階を更に含むことを特徴とする請求の範
    囲第２９項に記載の方法。
31. 【請求項３１】 前記パブリックキーのコピーを前記送
    信者に送信する段階を更に含むことを特徴とする請求の
    範囲第２９項に記載の方法。
32. 【請求項３２】 受信者情報を記憶するための前記デー
    タベースがサーバーにあることを特徴とする請求の範囲
    第２９項に記載の方法。
33. 【請求項３３】 前記データベースを照会する前記段階
    がサーバーによって実行されることを特徴とする請求の
    範囲第２９項に記載の方法。
34. 【請求項３４】 前記受信者から情報を集める前記段階
    がサーバーによって実行されることを特徴とする請求の
    範囲第２９項に記載の方法。
35. 【請求項３５】 前記集められた情報を前記照会され記
    憶された受信者情報と比較する前記段階がサーバーによ
    って実行されることを特徴とする請求の範囲第２９項に
    記載の方法。
36. 【請求項３６】 前記記憶された受信者情報と前記デジ
    タル証明に関する送信者選択可能オプションから成る証
    明要覧を生成する段階を更に含むことを特徴とする請求
    の範囲第２９項に記載の方法。
37. 【請求項３７】 送信者が使用する送信コンピューター
    と、受信者が使用する受信コンピューターと、受信者情
    報を記憶するためのデータベースと、前記受信者から情
    報を集めるための手段と、前記集められた情報と前記記
    憶された受信者情報が合致する場合、前記受信者のため
    にデジタル証明を制御可能に生成するための手段とから
    成ることを特徴とする、送信者が受信者のためににデジ
    タル証明を制御可能に生成するための装置。
38. 【請求項３８】 前記送信コンピューターと前記受信コ
    ンピューターとの間に置かれたサーバーを更に含むこと
    を特徴とする請求の範囲第３７項に記載の装置。
39. 【請求項３９】 受信者情報を記憶するための前記デー
    タベースが前記サーバーにあることを特徴とする請求の
    範囲第３８項に記載の装置。
40. 【請求項４０】 前記受信者から情報を集めるための前
    記手段が前記サーバーにあることを特徴とする請求の範
    囲第３８項に記載の装置。
41. 【請求項４１】 デジタル証明を制御可能に生成するた
    めの前記手段が前記サーバーにあることを特徴とする請
    求の範囲第３８項に記載の装置。
42. 【請求項４２】 デジタル証明を制御可能に生成する前
    記手段が、前記サーバーから前記受信コンピューターへ
    ダウンロード可能なソフトウエアを含むことを特徴とす
    る請求の範囲第３８項に記載の装置。
43. 【請求項４３】 前記サーバーが前記デジタル証明を記
    憶するための手段を含むことを特徴とする請求の範囲第
    ３８項に記載の装置。
44. 【請求項４４】 前記記憶された受信者情報と前記デジ
    タル証明に関する送信者選択可能オプションとから成る
    証明要覧を更に含むことを特徴とする請求の範囲第３７
    項に記載の装置。