JP2004005404A - 電子文書をネットワークを介して動的に引渡すシステム - Google Patents
電子文書をネットワークを介して動的に引渡すシステム Download PDFInfo
- Publication number
- JP2004005404A JP2004005404A JP2003012564A JP2003012564A JP2004005404A JP 2004005404 A JP2004005404 A JP 2004005404A JP 2003012564 A JP2003012564 A JP 2003012564A JP 2003012564 A JP2003012564 A JP 2003012564A JP 2004005404 A JP2004005404 A JP 2004005404A
- Authority
- JP
- Japan
- Prior art keywords
- document
- server
- recipient
- data
- representation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/06—Message adaptation to terminal or network requirements
- H04L51/066—Format adaptation, e.g. format conversion or compression
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Entrepreneurship & Innovation (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- General Business, Economics & Management (AREA)
- Tourism & Hospitality (AREA)
- Operations Research (AREA)
- Marketing (AREA)
- Economics (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Document Processing Apparatus (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】電子文書をネットワークを通してユーザに引渡す技術を提供することにある。
【解決手段】高レベルの電子文書を、受信側の能力によって適切且つ必要な低いレベルの表現に変換して、ネットワークを介して受信側に送信する。文書はイントラネット内のコンピュータからファイアウォール／プロキシサーバを通してインターネット上のサーバへ送ることもできる。低レベルバイナリデータはエンコードされ、小さいテキストパケットに細分され、ＨＴＴＰを使用してファイアウォールの外側のサーバへ送られる。サーバはパケットを元の低レベルのバイナリデータ表現に変換しなおす。このバイナリデータは、インターネットに接続された他のコンピュータ、プリンタ等に直接送ることができる。
【選択図】 図２２
【解決手段】高レベルの電子文書を、受信側の能力によって適切且つ必要な低いレベルの表現に変換して、ネットワークを介して受信側に送信する。文書はイントラネット内のコンピュータからファイアウォール／プロキシサーバを通してインターネット上のサーバへ送ることもできる。低レベルバイナリデータはエンコードされ、小さいテキストパケットに細分され、ＨＴＴＰを使用してファイアウォールの外側のサーバへ送られる。サーバはパケットを元の低レベルのバイナリデータ表現に変換しなおす。このバイナリデータは、インターネットに接続された他のコンピュータ、プリンタ等に直接送ることができる。
【選択図】 図２２
Description
【０００１】
【発明の属する技術分野】
本発明は、コンピュータネットワークの分野に関する。より詳しく述べれば本発明は、インターネットを通して電子文書をユーザに引渡す（即ち、デリバリ（ｄｅｌｉｖｅｒｙ））技術に関する。
【０００２】
【発明の背景】
電子文書引渡し
インターネットまたは他のオンライン源から供給されるようなコンピュータ化情報源の開発につれて、電子的に使用可能な情報が急増している。現在では、インターネットへ加入しているユーザは、関心があるかも知れない、またはないかも知れないサイトを訪れるためにインターネットを通して相互にナビゲートしている。このインターネットシステムに固有の問題は、使用可能な情報が「プル」（ｐｕｌｌ ）型インフラストラクチャを通して分配され、情報を受けようとするユーザが適切な情報を探索してダウンロードするためには、関心サイトを手動で探索するか、またはファインダアプリケーションを使用しなければならないことである。情報または文書を公表し、分配することを望むユーザ（分配することを望む情報を有する個々のエンティティ、またはより大きいエンティティの何れかである）の場合、現在の「プル」システムは、「プッシュ」（ ｐｕｓｈ ）方式の受信側または受信側のグループに自由に送って分配することを許さない。
【０００３】
現時点では、簡単な文書を分配するためにファクシミリ技術が広く使用されているが、印刷される文書の質が低いこと、特に、もし受信側が紙コピーが存在することに注意を払わなければ、紙コピーが高価であり、且つ、かさ張ること、例えばテキスト及び図形を編集または処理することができないので、内容が失われること、及び特に、長いまたは複雑な文書の場合、伝送に長時間を要することを含む多くの欠陥を有している。電子メール（Ｅメール）は、コンピュータユーザから別のコンピュータユーザへ電子メッセージを送るための手段を提供する。Ｅメールは、便利さ、フォーマット、及び後刻検索するためにメッセージの格納の長所を有している。そのためにＥメールは基本通信として受入れられ、広く使用されるに至っている。しかしながら、Ｅメールは典型的にはＡＳＣＩＩをベースとするフォーマットであり、長いか、またはフォーマットされた文書の通信の場合には極めて制約されたものである。更にＥメールは、ページレイアウトグリッド、Ｐｏｓｔｓｃｒｉｐｔフォーマットされたオブジェクト、トラッキング及びカーニングを伴う多重フォント、グラフィックス、埋め込み型テーブル及びスプレッドシート、及び他の複雑な情報を含み得る報告、論文、広告、及び美術のような複雑な文書を分配するために選択する媒体ではない。若干のＥメールシステムは、ＡＳＣＩＩをベースとするＥメールメッセージに、ダウンロードされる関連ファイルをＥメールメッセージと共に付加する手段を提供する。関連ファイルの付加を許容する殆どのシステムは、単一のユーザが保護されていないファイルを１人の同僚または友人へ送ることを許容するように設計されており、複数の受信側へ制御された自動分配を許容するようにも、または事前のアカウント、請求、または他のこれらの特色（例えば、領収通知）を行うようにもなっていない。Ｅメールゲートウェイも、アタッチメントの適用性を制限し、機密保護及び領収通知または承認の問題を解消しない。
【０００４】
１９９５年４月１１日付 Ｃ．Ｂａｕｄｏｉｎの米国特許第 ５，４０６，５５７号”Ｉｎｔｅｒｅｎｔｅｒｐｒｉｓｅ Ｅｌｅｃｔｒｏｎｉｃ Ｍａｉｌ Ｈｕｂ”は、共通コアと、複数の入力及び出力モジュールとからなるコンピュータハブを有する会社間通信センターを開示している。入力モジュールは第１のエンドユーザに接続され、第１のエンドユーザによって送られるメッセージを万能フォーマットに変換する。ハブコアはメッセージをキューに入れ、それを出力モジュールへ送って宛先ユーザのフォーマットに変換させる。開示されているハブは簡単なＥメールを中継する技術を示しているが、Ｅメールフォーマットを変換するように設計されているので、元のテキストをベースとするファイルの完全性が失われる。以上のように、開示されている先行技術のシステム及び方法は、文書を引渡す若干の方法を提供してはいるが、プッシュ方式で動作しながら元の電子ファイルの完全性を保存する経済的な、高速文書引渡しシステムを提供することに失敗している。このような電子文書引渡しシステムの開発は、重要な技術的進歩をもたらすことになろう。更に、電子的ポータブル高品質文書を多くの受信側に制御された、経済的な、そしてアカウント可能な方式で分配する能力は、さらなる技術的進歩をもたらすことになろう。
【０００５】
インターネット／イントラネット機密保護
インターネットは、漸増的に通信に使用されつつある。現在では、プラットフォーム、オペレーティングシステム、またはＥメールシステムには無関係に、インターネット上で送信側が特定の受信側に文書を送ることが可能である。たとえ受信側がコンピュータでなく、インターネットに接続されているファクシミリまたはプリンタであるとしても、このような通信が可能である。多くの場合、文書の送信側は、イントラネットと称されるローカルエリアネットワーク上に存在している。送信側のコンピュータは、直接またはイントラネットのサーバを通してインターネットに接続することができる。イントラネットは、ファイアウォール（ｆｉｒｅｗａｌｌ）またはプロキシサーバ（ｐｒｏｘｙ ｓｅｒｖｅｒ）によってインターネットから保護され、絶縁されていることが多い。ファイアウォールは、イントラネットまたはデスクトップコンピュータへのアクセスを制限するソフトウェア及び／またはハードウェアである。プロキシ・サーバは、イントラネットの内側を走るマシンと、イントラネットの外側を走るマシンとの間の要求を遮る専用ソフトウェア及び／またはハードウェアである。
【０００６】
このようなファイアウォールは、幾つかの基本サービスの１つまたはそれ以上を提供する。第１に、ファイアウォールは、イントラネットユーザがインターネット上の特定情報にアクセスすることを阻止する。従って、オフィスの職員は、仕事に関係のないインターネットサイトにアクセスすることを禁止される。第２に、ファイアウォールは、イントラネット上で使用可能な情報に外部からアクセスすることを禁止する。第３に、ファイアウォールは、イントラネットユーザが秘密情報をイントラネットからインターネットへ送るのをブロックする。典型的には、請求されていない外側からのイントラネットへのアクセスをブロックすることは、イントラネットからインターネットへの情報転送をもブロックすることになる。
【０００７】
ファイアウォールによって保護されているイントラネット間で、インターネットを通してデータを転送するためにいろいろな方法が使用されてきた。これらの方法の１つが １９９５ 年５月１６日付 Ａｚｉｚ の米国特許第 ５，４１６，８４２号 ”Ｍｅｔｈｏｄ ａｎｄＡｐｐａｒａｔｕｓ ｆｏｒ Ｋｅｙ−Ｍａｎａｇｅｍｅｎｔ Ｓｃｈｅｍｅ ｆｏｒ Ｕｓｅ Ｗｉｔｈ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌｓ ａｔ Ｓｉｔｅ Ｆｉｒｅｗａｌｌｓ” に開示されている。この方法では、サイト間トラフィックは「スキップ」計画を使用して「インターネットプロトコル」（ＩＰ）層において暗号化され、通信ノードの出所及び行先アドレスの検出を防いでいる。ＩＰパケットは、ファイアウォールサーバだけが「スキップ」計画に関与すればよいように、サイトファイアウォールからサイトファイアウォールまでだけが暗号化される。あるファイアウォールが内部サイトノードから遠隔ファイアウォールへ意図されたＩＣパケットを受信すると、そのファイアウォールはＩＣパケットを暗号化し、それをその遠隔ファイアウォールへ宛てられた別のＩＣパケット内にカプセル封じして送る。遠隔ファイアウォールはカプセル封じされたパケットを解読し、それを明文でこの遠隔ファイアウォールの内側の宛先ノードへ送る。
【０００８】
しかしながらこの方法は、暗号化されたＩＰパケットが、パケットを解読するように構成された遠隔ファイアウォールサーバによって受信される必要がある。このようなファイアウォールサーバを使用していないコンピュータまたはイントラネットシステム、またはファクシミリまたはプリンタのようなデバイスへ、暗号化された情報を直接送ることはできない。コンピュータネットワークを接続する機密保護システムが、１９９６年８月２７日付Ｇｅｌｂ の米国特許第 ５，５５０，９８４号 ”Ｓｅｃｕｒｉｔｙ Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｅｖｅｎｔｉｎｇ Ｕｎａｕｔｈｏｒｉｚｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｂｅｔｗｅｅｎ Ｎｅｔｗｏｒｋｓｂｙ Ｔｒａｎｓｌａｔｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｒｅｃｅｉｖｅｄ ｉｎ ＩＰ Ｐｒｏｔｏｃｏｌ ｔｏ Ｎｏｎ−ＩＰ Ｐｒｏｔｏｃｏｌ ｔｏ Ｒｅｍｏｖｅ Ａｄｄｒｅｓｓ ａｎｄ Ｒｏｕｔｉｎｇ Ｓｅｒｖｉｃｅｓ Ｉｎｆｏｒｍａｔｉｏｎ”に開示されている。しかしながら、Ｇｅｌｂは、どのようにしてファイアウォールまたはプロキシサーバを通して文書を送ることができるのかには言及していない。従って、一連のファイアウォール及び／またはプロキシサーバを通して文書を送る方法及びシステムを提供することが有利であろう。また、もしこのような方法及びシステムが、ファクシミリまたはプリンタのようなデバイスへ文書を伝送することを許容するならば更に有利であろう。もしこのような方法及びシステムが、暗号解除用ファイアウォールによってサービスされるデバイスに受信側コンピュータを必要としなければ、更に有利であろう。
【０００９】
文書変換
２つの異なるシステム間で情報を受渡しするのに伴う多くの複雑性の１つは、例えば能力の差を含むこれらのシステム間の基本的な非互換性に由来する。プリンタは、パーソナルコンピュータとは極めて異なる能力セットを有しているが、プリンタが受け入れることができるデータフォーマットは同一セットである。例えば、パーソナルコンピュータは ＷｏｒｄＰｅｒｆｅｃｔ文書、ポータブル文書（例えば、Ａｄｏｂｅ Ａｃｒｏｂａｔ または Ｎｏｖｅｌｌ Ｅｎｖｏｙ ）、またはＨＴＭＬ文書を処理することができるかも知れない。これに対して、プリンタは、ＰＣＬファイルまたは Ｐｏｓｔｓｃｒｉｐｔ ファイルを受け入れることができるだけかも知れない。ファクシミリも、プリンタと同様に、文書のグループ３圧縮白黒ラスタ表現を受け入れるだけであるかも知れない。このようにいろいろなデバイスは、それらが受入れることができるデータの型に関して、さまざまな能力を有している。
【００１０】
同様に、異なるデータ型は、異なるレベルの柔軟性及び機能を提供する。例えば、Ｅｎｖｏｙ またはＰＤＦファイルは、どのような分解能にもスケールすることができ、数百万の色を支援することができ、そしてテキスト及びフォントを含むことができる。一方、グループ３圧縮ファックスイメージは、分解能が制限され、白黒を支援するだけであり、そしてテキスト及びフォントは含まないので、グループ３圧縮イメージの受信側の能力は、基本動作を除くどのような動作を遂行することも制限される。柔軟性が拡張されているポータブル文書のようなより頑強なデータ表現は、これらの文書をそれ程頑強でない表現に変換することができる。例えば、ポータブル文書は Ｐｏｓｔｓｃｒｉｐｔ ファイルに、またはグループ３圧縮イメージにさえも変換することができる。従って、ポータブル文書は高レベルのデータ表現であり、グループ３圧縮イメージは低レベルのデータ表現であると言うことができる。
【００１１】
殆どの場合、もし受信側のシステムが高レベルのデータ表現を受信することができれば、このような表現が提供する能力が大きいので、このような表現は極上のデータ表現である。従って、このような表現は、特に、もしこのような表現が必要に応じて高レベル表現をより低いレベル表現に変換できるメカニズムを含んでいれば、好ましい共通フォーマットになる。１９９５年６月１３日付 Ｍ． Ｗｉｌｌｉａｍｓ及び Ｒ． Ｙｕｎの米国特許第 ５，４２４，７２４号 ”Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ Ｆｏｒ Ｅｎｈａｎｃｅｄ Ｅｌｅｃｔｒｏｎｉｃ Ｍａｉｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ” は、電子メール文書を、複数のホストシステムに、及び／または単一のホストエージェントを介して外部ネットワークに分配することが可能な強化された電子メール分配方法及び装置を開示している。ホストエージェント参照テーブルが、ローカルネットワーク内の選択されたホストエージェント内に確立される。各ホストエージェント参照テーブルは、選択された宛先ノードの識別（これらのノードのための識別されたホストエージェントに対応付けられている）を含んでいる。ホストエージェント参照テーブルへのリフェラル（ ｒｅｆｅｒｒａｌ ）を使用して、選択されたノードへ宛てられた電子文書のための適切なホストエージェントを決定する。この方法及び装置内には、動的（ダイナミック）なデータ変換の準備はなされていない。従って、文書はその変更されないレベルの表現で、そして宛先ノードにおける処理能力には関係なく、引渡されることになる。
【００１２】
１９８８年６月２８日付 Ｔ． Ｓｃｈｕｌｔｚ 、Ａ． Ｇｒｏｓｓ、Ｂ． Ｐａｐｐａｓ 、Ｇ． Ｓｈｉｆｒｉｎ及び Ｌ．Ｍａｃｋの米国特許第 ４，７５４，４２８号 ”Ａｐｐａｒａｔｕｓ ａｎｄ Ｍｅｔｈｏｄ ｏｆ Ｄｉｓｔｒｉｂｕｔｉｎｇ Ｄｏｃｕｍｅｎｔｓ Ｔｏ Ｒｅｍｏｔｅ Ｔｅｒｍｉｎａｌｓ Ｗｉｔｈ Ｄｉｆｆｅｒｅｎｔ Ｆｏｒｍａｔｓ”、及び １９８７ 年１２月１５日付Ｔ． Ｓｃｈｕｌｔｚ 、Ａ． Ｇｒｏｓｓ、Ｂ． Ｐａｐｐａｓ 、Ｇ． Ｓｈｉｆｒｉｎ及び Ｌ． Ｍａｃｋの米国特許第４，７１３，７８０号 ”Ｅｌｅｃｔｒｏｎｉｃ Ｍａｉｌ”は、常時プリンタに接続され、プリンタ出力を有する源によってローカルサイトから発信された文書を、文書生成源のプリンタ出力に常時接続されているプリンタとは異なり得るプリンタまたはディスプレイデバイスを有する１つまたはそれ以上の遠隔位置に引渡す方法及び装置を開示している。通常プリンタ出力に発生するプリンタコマンド信号は、文字及び位置データ（文書の各ページ上の関連する文字と、それらの水平及び垂直位置とを表す）に変換される。文字及び位置データは遠隔位置へ伝送されてプリンタまたは他のディスプレイデバイスを駆動する形状に再変換され、元のライン対ライン準拠コピーを発生する。
【００１３】
上記 ’４２８ 号及び ’７８０ 号特許は、上流データ変換の使用を開示しているが、下流データ変換を提供していない。即ち、上記 ’４２８ 号及び ’７８０ 号特許では、プリンタへ送られるテキストを、あるプリンタに特定のフォーマットに変換することは許容している。しかしながらこの方法及び装置は、データを高レベルの表現から開始する能力を欠いており、もし変換が必要であると決定されれば、より低いレベルに変換するだけである。従ってこのアプローチは、プリンタフォーマットが未知、または文書発信前に確立される場合、またはインターネットのような異質ネットワークを使用してデータを引渡す場合には、満足できるものではない。１９９６年４月３０日付 Ｌ． Ｈａｒｋｉｎｓ 、Ｋ． Ｈａｙｗａｒｄ、Ｔ． Ｈｅｒｃｅｇ 、Ｊ． Ｌｅｖｉｎｅ 及びＤ． Ｐａｒｓｏｎｓ の米国特許第５，５１３，１２６号 ”Ｎｅｔｗｏｒｋ Ｈａｖｉｎｇ Ｓｅｌｅｃｔｉｖｅｌｙ Ａｃｃｅｓｓｉｂｌｅ Ｒｅｃｉｐｉｅｎｔ Ｐｒｉｏｒｉｔｉｚｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｈａｎｎｅｌ Ｐｒｏｆｉｌｅｓ” は、受信側プロファイル内に定義されているデバイス及び通信チャネルを使用して送信側が情報をネットワーク上の受信側に自動的に分配する方法を開示している。受信側プロファイルは、ネットワーク上の受信側の情報受信の特性及びモードを確立し、このプロファイルは全てのネットワークユーザのネットワークレポジトリに公表されるか、またはネットワーク上の選択されたグループまたは個人によってアクセス可能である。開示されたネットワークはデータ変換を行わないが、チャネルを通して通信する受信側の能力に基づいて所定のデータを送ることを含んでいる。従って、各受信側はデータを交換する前に、先ずフォーマットを確立しなければならない。
【００１４】
１９９５年４月４日付 Ｍ． ＢｌｏｏｍｆｉｅｌｄのＩ．Ｓ．特許第 ５，４０４，２３１号”Ｓｅｎｄｅｒ−Ｂａｓｅｄ Ｆａｃｓｉｍｉｌｅ Ｓｔｏｒｅ ａｎｄ Ｆｏｒｗａｒｄ Ｆａｃｉｌｉｔｙ”は、ファクシミリをベースとする情報を引渡すために、送信側をベースとする蓄積転送サービスを提供するシステムを開示している。このシステムは、ファクシミリビットマップイメージの引渡しだけに関連しており、データ変換には関連していない。現在の技術に伴う制約を考えると、より低いレベル表現まで降格させる能力を保存し、将来時点においてそのようにする柔軟性を与えるようになっているが、適切な場合にはより豊富な機能のセットをも可能ならしめるシステムを提供することが有利であろう。
【００１５】
【発明の概要】
本発明は、電子文書引渡しシステム及びその使用方法を提供する。ポータブルフォーマットであることが好ましい文書は、遠隔サーバへ送られる（例えば、ＨＴＴＰを使用して文書をサーバへ「プッシュ」する）。サーバは意図した受信側へ文書の包括的な通知を送り、受信側はローカルプロトコルを使用して文書をサーバからダウンロードすることができる。好ましい実施例では、本発明は、サーバのネットワーク（蓄積転送手法で文書及び通知を送りながら、経路指定及びアカウント情報を送信側へ送り返す）を使用して、送信側から多数の受信側へポータブル文書を制御された技法で引渡すのに使用される。本発明は、一連のファイアウォール及び／またはプロキシ・サーバを通して、イントラネットの内側のデスクトップコンピュータからインターネット上に存在するサーバへ文書を送る方法及びシステムをも提供する。ファイアウォールは、テキストデータ用のＨＴＴＰが、ユーザがＨＴＭＬ形状で記入可能な有効動作であるものと仮定している。このように、ファイアウォールは、テキストデータ用のＨＴＴＰを妨げない。本発明は、ファイアウォールを通して文書を移動させるＨＴＴＰのこの特色を使用することによって、ファイアウォールによって与えられる機密保護を回避する。
【００１６】
ファイアウォールまたはプロキシサーバによって保護されているイントラネットシステム内のコンピュータは、インターネットにアクセスするためのソフトウェアアプリケーションを使用する。またこのソフトウェアは、テキストとして送られるバイナリデータをエンコードする。このバイナリデータは、より小さいテキストパケットに細分することができる。これらのテキストパケットはＨＴＴＰを使用して、ファイアウォールの外側の、これらのパケットを受入れるように構成されたサーバへ送られる。サーバは、テキストパケットを元のバイナリデータ表現に変換する。インターネットサーバ上に到達したこのバイナリデータは、他のインターネットサーバ、インターネットデスクトップコンピュータ、プリンタ、またはファクシミリへ直接送ることが可能になる。
【００１７】
本発明は、受信側の能力及び引渡される文書の型に基づいて、引渡される文書のフォーマットを動的にカストマイズ（ｃｕｓｔｏｍｉｚｅ） する文書引渡しサーバをも提供する。それによってサーバは受信側の能力には無関係に、フォーマットされた文書を透過的に引渡すことができる。例えば、受信側プラットフォームは、デスクトップコンピュータ、ネットワークコンピュータ、プリンタ、ファクシミリ、またはパーソナルディジタルアシスタントであることができる。サーバは、文書内に含まれる情報を高レベルの表現に維持し、より低いレベル表現への変換の決定を遅らせようとし、それによって引渡しプロセス内の各ステップにおける潜在的なオプションセット及び機能を最大にする。従って、本発明はディジタルの高レベル表現から出発し、必要な場合に限ってより低いレベル表現に変換する。
【００１８】
【実施例】
バイナリファイル引渡し（または、デリバリ）システム１０は会社、出版社、及び個人が文書を電子的に分配することを可能にする。重要なのは、既存の Ｗｅｂをベースとする文書公表技術とは異なり、バイナリファイル引渡しシステム１０は文書を送って確実に分配することができる。現時点での Ｗｅｂは、文書の消費者がサーバから文書を見出し、検索しなければならないような「プル」公表環境であることが特徴である。これに対して「プッシュ」公表は、文書の作成者が消費者に直接文書を引渡すことができる。ファクシミリ（ファックス）、郵便サービス、及び電子メール（Ｅメール）は、全て「プッシュ」公表の例である。図１は、１つのバイナリファイルサーバ１２を使用するバイナリファイル引渡しシステム１０を示すブロック線図である。バイナリファイル引渡しシステム１０によってユーザは、文書をプッシュすることができ、文書の作成者はこれらの文書の宛先へ送ることができる。バイナリファイル引渡しシステム１０がプッシュ公表を達成する１つの方法は、普通はネットワーク上で情報をプルするように実現されているＨＴＴＰと、ＳＭＴＰ（これはテキストだけを支援する）とを組合わせることによってである。更に、バイナリファイル引渡しシステム１０は、送られた文書引渡しのいろいろなアプリケーションを容易にするために、サービスのホストになる。バイナリファイル引渡しシステム１０は、１つのレベルにおいて、電話回線の代わりにネットワークを使用する新世代のファクシミリ技術としての特徴を有し、そして更に、既存のファックスフォーマットより遙かに優れた新しい文書表現のための支援を導入する。別のレベルにおいては、バイナリファイル引渡しシステム１０は、大量の文書及びトランザクションを支援することができる汎用文書引渡しサーバである。全ての場合に、バイナリファイル引渡しシステム１０は、文書引渡しのための完全な、そして頑強な手法を提供する。
【００１９】
バイナリファイル引渡しシステム１０は、１つのエンドポイントから１つまたは複数のエンドポイントへ１組のバイナリファイルを送るために使用される。エンドポイントは、典型的にはインターネットへアクセスできる受信側２２であるが、ファクシミリ１７２またはプロセス１７８（図１４、１５）のような別のエンティティであることもできる。バイナリファイルの引渡しは、信頼できる、アカウント可能な、そして扱い易い手法で達成される。バイナリファイル引渡しシステム１０は、導かれたファイルのために幾つかのレベルの機密保護（Ｅメール等価機密保護から、ファクシミリまたは物理的郵便物より以上の）を提供する。システムは、請求アカウントのクレジット及びデビットを含むユーザアカウント管理をも提供する。システムは、他のあるオーソリティによって制御される、またはされない複数のバイナリファイル引渡しサーバ１２の間で共働することもできる。図２は、インターネットを通して通信する２つのバイナリファイルサーバ１２ａ及び１２ｎを使用するバイナリファイル引渡しシステムを示している。
【００２０】
バイナリファイル引渡しサーバ１２は、３つの主要モードで動作する。これらのモードは、送信側１６が請求の対象であるアカウント１３２を自身で設定するパブリックモード、送信側１６が管理者によって制御され、請求が回収発行を上回る内部アカウント発行であるプライベートモード、及び受信側２２の数は多いが送信側１６の数は僅かであるような公表モードを含むバイナリファイル引渡しサーバ１２は分離した機能構成要素からなり、必要不可欠なプロセスまたは共用ライブラリではない。図４に概要を示すバイナリファイル引渡しサーバ１２は、ストア４２と呼ばれる知的格納コンパートメントを含む。ストア４２は、ストアクライアント４４と呼ばれる１組のクライアント４４ａ−４４ｎによって増補されている。ストアクライアント４４はストア方法を使用し、ストアイベントを聴取するが、他のクライアント４４と会話したり、または他のクライアント４４に関して知ることはない。アカウント管理者４６構成要素は、送信側１６に関する情報を保持する共用サービスである。この設計は、受信アプリケーションの場合に受信側２２に関する情報をも組み入れる（Ｅメール通知とは対照的である）。
【００２１】
クライアント／サーバ汎用アーキテクチャは、よりパイプライン化された構造よりも良好な拡張性を与える。また、それはストアクライアント４４を互いに切り離す。これは、タスクの若干が会話式であり、その他のタスクがよりバックグラウンド向きであるような場合に有用である。
【００２２】
ストア
ストア４２は、１組のストアアイテム４８を含む。図３に示すようにストアアイテム４８は、バイナリファイルの木３４と、１組のストア定義属性及びクライアント定義属性である記述子３６とを含んでいる。バイナリファイルの木３４は、ストア定義属性の一部と見ることができる。ファイル記憶システムは、以下の機能を提供する。
１）ストアアイテム４８の恒久的な格納（例えば、ストアアイテム４８内に含まれるバイナリファイルの木３４はディスクに書き込まれている）、
２）ストア定義属性及びクライアント定義属性で作られた記述子３６へのクライアント読み出し／書き込みアクセス（例えば、クライアント４４はストアアイテム４８の満期日付を書き込むことができる）、
３）ストアイベント６７のクライアント通知（例えば、クライアントは新ストアアイテム４８の作成イベント６８を通知されることができる）、
４）ストア定義属性による内部管理（例えば、ストアアイテム満期日付があるイベントを生成する）。
【００２３】
ストア４２は、ストアアイテム４８へのアクセスを提供し、ストアイベント６７を生成する。ストアアイテム４８はＩＤ、作成日付、ファイルカウント、ファイル名、ファイル日付のようなストア定義属性を有し、またクライアント４４はストアイベント６７を聞くことができる。ストアイベント６７は、ストアアイテム４８の作成６８、削除６９、または変更７０を含むことができる。イベント６７は、クライアントがその仕事をどのようにして他のクライアントの極めて制限された知識に同期させるのかを定義するので、アーキテクチャにおける重要な役割を果たす。
【００２４】
ストアクライアント
ストアクライアント４４は種々雑多であることができ、特定のクライアントに関して以下に詳しく述べる。この枠組の中のストアクライアント４４は、若干のストア方法を使用して、及び／または若干のストアイベント６７を聴取してストアアイテム４８上で有用なタスクを遂行する構成要素である。
アカウント管理者
アカウント管理者４６は、ユーザ及び請求アカウントへの読み出し／書き込みアクセスを与え、クライアント４４またはシステム１０の他の構成要素によって使用される。ストア４２は、アカウントを使用しないか、またはアカウントに関して知らない。
【００２５】
他の構成要素
ストアクライアント４４及びストア４２自体が使用する他の構成要素が、システムのアクセス内に実現されている。例えば、サーバ間通信、ログ管理、及び他の管理サービスであり、これに関しては以下に説明する。図５は、サーバ機能を実現するために使用されるクライアント４４モジュール（５２−６６）を含むバイナリファイルサーバ４２の一実施例のアーキテクチャである。「インターネット送信」５２は、ストアアイテムを作成するのに使用され、属性内を充填する。「インターネット受信」５４は、既存ストアアイテム４８を開き、それらの属性を変更するために使用することができる。「ファックスゲートウェイ」５６は、ストア４２が生成した作成イベント６８を聴取し、関連ストアアイテム４８を処理し、そしてそれらをストア４２から削除する。フォワーダ５８は、ストア４２が生成した作成イベント６８を聴取し、新しいストアアイテム４８の属性を調べ、そして転送が必要か否かを決定する。「アーカイバ」６０は削除イベントを聴取し、そして削除が発生する前にストアアイテム４８を二次プライベートストアへコピーする。「フォーマット翻訳者」６２は、作成を聴取し、属性を調べ、そしてもし翻訳が必要であれば、読み出し、処理し、そしてストアアイテム４８内のファイルへ書き戻す。「Ｗｅｂ 公表者」６４は、作成イベント６８を聴取し、そしてストアアイテム属性が Ｗｅｂ公表を指定しているか否かを検査し、もし指定していれば、必要に応じて属性を読み出す。「ピックアップ通知者」６６は、作成イベント６８について聴取し、次いで受信側２２に通知する。
【００２６】
インターネットをベースとするユーザのための機密保護発行
バイナリファイル引渡しシステム１０は特殊化された機密保護方法を支援する柔軟性を提供する一方で、以下のものを含む現在の工業標準機密保護方法を容易に支援する。
（ａ）安全なサーバ相互接続及びサーバ認証（サーバ（ＨＴＴＰ）内に組み込まれているＳＳＬ ２．０を用いて利用可能）。
（ｂ）「サーバからサーバへ」（ＳＳＬＸのトップに）確保。
（ｃ）エンドポイント専用キーの支援（専用キーは、それら自体のチャネルを使用してユーザによって交換されなければならない）。
（ｄ）ＣｒｙｐｔｏＡＰＩ または標準公開キーを使用するエンドポイント公開キーの支援。システムは、ユーザがＢＦＤ使用だけのために公開キーを生成し、それに伴うユーザアカウント情報を更新することをも援助することができ、従って送信側は公開キーを入手するために受信側と直接通信する必要はない。
（ｅ）ＳＳＬ及びＭＳ ＰＣＴを有するサーバによる「クライアント認証」（エンドユーザはそれら自身の証明書を入手し、サーバはそれを認証することができる）。
【００２７】
バイナリファイル引渡しサーバ１２の重要な面は、それが複数の要求を並列に処理し、殆どの要求に対するレスポンス時間を最小にすることである。従って、正しさ及びシステム性能にとって同期発行が重要である。性能は、同期したデータアクセスを最小にし、可能である場合には常に非同期処理を遅延させることによって、そしてプラットフォームのためにマルチタスキング及びＩＰＣ （ Ｉｎｔｅｒ−Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ）を使用することによって増強される。サーバ１２の一実施例は、１つのプロセス内で低オーバヘッドのマルチタスキングを提供するスレッディングに大きく依存し、利用可能な場合には多重プロセッサ能力を導入する。この実施例におけるＩＰＣは、メールスロットまたはＲＰＣ（ Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ ） に加えて、名前付きのパイプを使用する。
【００２８】
図７は、バイナリファイル引渡しサーバ１２アーキテクチャ内の特定構成要素のブロック線図である。ユーザセッション７２は、送信セッション、受信セッション（これらはユーザがＢＦＤデスクトップアプリケーション１９２、１９８を使用している場合に実現される）、ＨＴＭＬ受信セッション（これらは、ユーザがＢＦＤデスクトップ１６４を使用している場合とは異なり、ＨＴＭＬブラウザによって実現される（ＢＦＤデスクトップセッションはＨＴＭＬによって実現できることに注目されたい））、保守セッション（アカウント設定及び保守セッション（例えば、通知ダウンロード）を実現する）、アカウント設定変更（公衆サーバのエンドユーザとは異なり、管理者によるコンソールサービスによって混乱させられることはない）、ＨＴＭＬ保守セッション（ＨＴＭＬブラウザによってアカウント設定及び保守を実現する）を処理する。
【００２９】
引渡し構成要素７４は、通知及び転送を含む引渡しを行うバックグラウンド作業を実現する。コンソール７６は、特別なユーザインタフェースの代わりにＨＴＭＬインタフェースを通して遂行される管理セッションを実現する。コンソール７６は、ユーザインタフェースをブラウザへ提供し、アカウント、ロギング、性能、及びパラメタ設定を含む全てのサーバプロパティを変更する。
【００３０】
共用構成要素
共用構成要素は、ストア４２、及び何れかのストアクライアント４４によって使用することができ、または、それらはそれら自体上で動作することができる。これらがストアイベント６７を聴取することはないが、これらは効率のために（例えば、コネクタ受信のために）必要に応じてストア方法を使用することができる。共用構成要素は、以下のものを含むことができる。
１）全てのローカルアカウント情報を維持し、請求アカウント及び遠隔アカウント情報を含むローカルアカウントに対して独特なアクセスインタフェースを提供するアカウント管理者、
２）全てのサーバ間通信を処理するサーバコネクタ８０。
３）バウンスしたメールの送信及び受信を処理するメールゲートウェイ８４。
４）型によって分類されている異なるログへのアクセス読み出し／書き込みを管理するロガー８６。最重要なログは、時間の経過と共にストアアイテム４８に何が起こったのかを追跡する送信／受信トランザクションログである。
５）ファイル入力及び出力（Ｉ／Ｏ）、プロセス管理（同期、ロッキング、スレッド、プロセス）、ＩＰＣ（ＲＰＣ、共用メモリ、共用待ち行列、パイプ）、ネットワークアクセス（ＴＣＰ／ＩＰソケット、ＨＴＴＰサーバインタフェーシング、ＰＯＰ／ＳＭＴＰインタフェーシング）のためのオペレーティングシステムに対してプラットフォーム独立インタフェースを提供するオペレーティングシステムアクセッサ８２。特定部分は、必要に応じて実施される。
【００３１】
サーバアプリケーション
サーバアプリケーション８８は、構成パラメタに従ってバイナリファイル引渡しサーバ１２の全ての片を始動及び停止させるのに使用される。またこれはアカウント管理者（４６または７８）、またはロガー８６によってカバーされない、例えば性能プロファイリング、使用情報、及びサーバパラメタ／構成のような、サーバの管理面をも提供する。図８は、ストア４２のアーキテクチャを示すブロック線図である。ストア管理者９２は、グローバル状態を維持し、アクセスをストア４２に同期させ、そしてハウスキーピング機能を提供するために使用される。ストアアイテム管理者９４は、ストアアイテム４８の状態、ロック、及びキャッシュメカニズムを維持するために使用される。ストアイベント管理者９６は、リスナーリスト及びイベントフィルタを維持するために、並びにイベントフィルタ及びイベント優先順位に従ってイベントを発送するために使用される。
【００３２】
図９は、ユーザセッションが、どのようにしてインターネットクライアントをセッション、トランザクション、及び移送を含む３つの層に編成するのかを示している。セッション管理者１０２は、現在活動中のセッション状態の全てを維持し、セッション関連ハウスキーピングを遂行する。これは、ストア４２及びアカウント管理者４６の使用を通してトランザクション管理者１０８から到来するトランザクションを処理する。トランザクション管理者１０８は、移送管理者１１４、１１８から生のデータを受け、１つまたはそれ以上のＢＦＤトランザクションインタプリタ１１０またはＨＴＭＬトランザクションインタプリタ１１２を使用して確認及び処理を遂行する。次いでトランザクション管理者１０８は、データを適切なＢＦＤセッション管理者１０４またはＨＴＭＬセッション管理者１０６に提出し、返答を待機し、次いでその返答を適切な移送管理者１１４または１１８へ送り返す。
【００３３】
図１０は、送信セッションがストアアイテム４８を作成してしまうか、または別のサーバ１２ａ−ｎがストアアイテム４８を転送している場合の引渡しの非対話式タスク１２０を示している。引渡し管理者１２２は、関連ストアイベントを聴取し、転送決定を行い、そして作業を通知者６６及びフォワーダ５８と調和させる。サーバディレクトリは、Ｅメールドメインとサーバドメインとの間の結合を追跡する。通知者６６は、受信側２２へのＥメール通知２０を処理するために使用される。フォワーダ５８は、サーバコネクタ８０を使用してストアアイテム４８を他のサーバ１２ａ−ｎへ転送するために使用される。全てのＥメール通知が受信され得るものではないから、「戻された」Ｅメールのためのサーバメールアカウントを調べ、それを失敗したトランザクションと突き合わせるためにＥメールスキャナが使用される。
【００３４】
図１１は、アカウント管理者アーキテクチャ１３０の詳細を示している。アカウント管理者７８は、ローカルサーバ１２のためにユーザアカウント状態１３２を維持し、ローカルアカウント１３２のために請求アカウント状態１３４を維持し、ローカルアカウント１３２を問い合わせ、そして遠隔アカウントのディレクトリ１３６を維持するために使用される。遠隔アカウントディレクトリ１３６の主目的は、Ｅメールアドレスと、ＢＦＤアカウントまたは非ＢＦＤアカウントの何れかとを結合させることである。図１２は、ロガーアーキテクチャの詳細図である。図１３は、サーバコネクタアーキテクチャの詳細図である。
【００３５】
システム動作
以下の例は、送信側１６から受信側２２へ電子情報を分配するのにバイナリファイル引渡しシステム１０がどのように使用されるのかを示している。仮に公表者であるカリフォルニア州レッドウッド市のサム（ Ｓａｍ ） が、日本の東京にいる仲間のロブ（ Ｒｏｂ ） に文書を送りたいものとする。以下のイベントの進行は、これがどのようにして制御された手法で達成されるかを示す。
サムがカリフォルニア州サンタクララのローカルサーバに接続する
サムのＢＦＤデスクトップは、彼のユーザアカウントが存在しているサンタクララのローカルサーバ１２ａへの接続を開く。セッション管理者１０２は、アカウント管理者７８に問合わせてユーザ１６（サム）を確認する。次いでセッション管理者１０２は、ユーザ１６のために送信セッション状態を作成する。
【００３６】
サムの送信セッション
サムのＢＦＤデスクトップは、ファイル数、ファイルのサイズ、及び意図する受信側のようなトランザクションを送る。セッション管理者１０２は、このデータをセッション状態に付加する。次いでセッション管理者１０２は、ストアアイテム記述子３６をメモリ内に作成し、ストア４２及びストアアイテムＩＤを用いてディスクスペースを確保する。これで、アップロードが開始される。セッション管理者１０２は、非同期Ｉ／Ｏを使用してデータを直接ファイルへスプールする。サムの全てのファイルのアップロード１８が完了すると、セッション管理者１０２はディスクへのストアアイテム記述子３６を非同期で更新し、次いでストアアイテム４８を非同期でストア４２内へ挿入する。セッション管理者１０２は、サムのアップロードに肯定応答で返答し、トランザクションに関する情報を提供する。これで、このセッションは終わる。
【００３７】
サンタクララのストアにおいて
ストアアイテム４８の挿入は、ストア４２によってロガー８６内に非同期でログされる。次いでストアは、登録されたイベントハンドラフィルタに対してストアアイテム記述子３６を走らせる。各突き合わせ毎に、それはイベント及び被通知者（ロブ）をそのイベント待ち行列内に挿入する。これで、そのスレッドは止まる。イベントディスパッチスレッドがイベントをプルし、システムのチューニングパラメタに依存するレートでそれらを非同期で被通知者へ発送する。
【００３８】
サンタクララ引渡しが通知される
引渡し管理者７４は関連イベントを通知し、ストア４２との同期トランザクションを介してストアアイテム４８のロックに伴うスレッドを開始させる。ロックが確保されると、スレッドはストアアイテム記述子３６を読み取り、引渡し管理者７４はそれを解析し、それをどのように処理するかを決定する。引渡し管理者７４は、受信側２２が別のＢＦＤサーバ１２ｎが位置している日本ドメインにあることを見出す。引渡し管理者７４は、サーバディレクトリ１２４に問合わせることによってこれを見出す。次いで、管理者はストアアイテム４８を転送することを決定する。転送管理者８０は、東京への転送を行うことを非同期でコネクタ８０に依頼する。これで、引渡し内のスレッドが止まる。引渡し管理者が、サーバプロトコルを知っていないことに注目されたい。
【００３９】
サンタクララコネクタ８０は、東京コネクタ８０へ転送しかかっている。引渡し要求を処理するスレッドは、結局はコネクタ８０内で始動する。それは、東京サーバ１２ｎとの接続を開始する。もし接続することができなければ、暫時休止する。結局は接続を開き、コネクタ８０はプロトコルインタプリタを入力し、結局はプロトコルインタプリタはストアアイテム記述子及び関連するバイナリデータファイルを転送する。次いで、それは接続を閉じ、東京サーバ１２ｎへの転送の成功をロガー８６内にログする。次に、コネクタ８０は、転送済であるとマークした後に、ストア４２内のストアアイテム４８上のロックを解除する。ロックが解除されると、ストア４２はストアアイテム記述子をイベントフィルタリストに対して走らせ、局部的に処理されるイベントフィルタを見出す。成功裏に転送されたストアアイテム４８は、参照カウントを１だけ減少せしめる。この例では、１つの受信側２２しか存在せず、従ってカウントが０になることを意味する。従って、ストア４２はストアアイテム４８を削除リストへ移動させることができる。そこで、ストア４２のハウスキーピングスレッドは、ある点でストアアイテム４８を消去（パージ）する。
【００４０】
東京コネクタ受信側８０内のスレッドが開始され、接続を処理する。プロトコルインタプリタがそれを転送として理解すると、それはストアアイテムＩＤ３６及び関連するコミットされた貯蔵空間についてストア４２に尋ねる。実際のストアアイテム記述子及びファイルは、それがデータを受信した時に、ディスクに書き込まれている。接続が完了すると、ストアアイテム４８が東京バイナリファイル引渡しサーバ１２ｎのストア４２内に非同期で挿入される。
【００４１】
東京引渡し構成要素が始動
挿入時には、東京ストア４２はイベントを生成しており、そのイベントは引渡しのスレッドによって処理されようとしている。また新しいアイテムの挿入をロガー８６内にログしている。引渡し構成要素７４内の管理者１０２は、これが転送されたものであり、このサーバ１２ｎから受信されるものと理解する。サーバ１２ｎは、ロブのＥメールアドレスに関連するアカウントが存在するか否かを見出すために、アカウント管理者７８に問い合わせる。もし関連アカウントがロブのＥメールに存在しなければ、ＵＲＬ（ストアアイテムＩＤ ３６を指示する）と共にＥメールがロブへ送られる。またサーバ１２ｎは、ロブに通知したことをサンタクララサーバ１２ａに通知するために、コネクタ８０に対する非同期要求を待ち合わせる。もしロブがそこにアカウントを有していれば、未決引渡しに言及するために引渡しはアカウント管理者７８を用いて非同期更新要求を行う（この場合には、シナリオが継続される）。
【００４２】
ロブは新文書を調べるために東京サーバに接続
ロブが受信セッションを開いた時、セッション管理者１０２は同期してロブアカウントの有効性について調べ、そのアカウントがペンディング受信と共にフラグされることを記憶するために、そのプロセス中にセッション状態を更新する。最終的にロブのＢＦＤデスクトップは受信すべき文書を請求する。セッション状態は「ｙｅｓ」を返答する。ロブのデスクトップ１７０は受信を請求し、セッション管理者１０２は同期的に、関連するストアアイテム４８のロックをストア４２に請求する。承認されるとセッション管理者１０２は、返答としてデータの最初の部分を送ることができる。文書がダウンロードされると、セッション管理者１０２は非同期的に、ロガー８６に受信成功をログする。次いで、セッション管理者１０２は非同期的に、サンタクララサーバ１２ａに最終引渡しを通知するようにコネクタ８０に要求する。
【００４３】
東京の受信セッションにおいて、セッション管理者１０２はロックを解除し、ストア４２へ非同期削除要求を行う。これでロブは受信セッションを終了する。サンタクララのコネクタ８０はプロトコルインタプリタを走らせる。プロトコルインタプリタは、通知をロガー８６のキューに入れなければなければならないことを述べる。
サムは状態を調べる
サムは、受信セッションと、それに続く保守セッションとを行うために接続する。保守セッション７２は送られた文書の状態を調べる要求を受信する。保守セッション７２は、非同期的に、送信時にサムデスクトップへ流したストアアイテムＩＤ ３６を使用してロガー８６へ問合わせを依頼する。この問合わせは、突き合わせ記録のリストを戻し、これらの記録は処理されてデスクトップへ流され、デスクトップはユーザインタフェース１６を更新することができる。
【００４４】
ポータブル文書引渡しシステム
電子ポータブル文書は徐々に評判になりつつある。これらのファイルは、それらの元のルック・アンド・フィールを失うことなく異なるプラットフォームに分配することができる。Ａｄｏｂｅ Ｓｙｓｔｅｍの Ａｃｒｏｂａｔ ＰＤＦ（商品名）、及び Ｎｏｖｅｌｌ のＥｎｖｏｙ（商品名）ポータブル文書フォーマットが広く用いられ始めている。本発明の好ましい実施例では、ポータブル文書引渡しシステム１６０は、ポータブル文書技術をインターネットに適用することによって電子文書の引渡しに対する万能手法を達成している。ポータブル文書引渡しシステム１６０は、Ｎｏｖｅｌｌの Ｅｎｖｏｙ（商品名）及び Ａｄｏｂｅ Ｓｙｓｔｅｍ の ＰＤＦ（商品名）を含むポータブル電子文書フォーマットと完全な互換性を有している。
【００４５】
ポータブル文書引渡しシステム１６０からのポータブル文書の受信側２２はそれらの文書からの情報を、見る、探索する、印刷する、保管する、またはエクスポートすることができる。ポータブル文書引渡しシステム１６０と共に Ｅｎｖｏｙ（商品名）または Ａｃｒｏｂａｔ（商品名）を使用して分配される文書は、完全な視覚忠実度を保存し、高分解能出力デバイス上に最高レベルの品質及び分解能をもって生成させることができる。ポータブル文書フォーマットによって文書内の情報の内容及び色を保存することができ、また多くのフォーマットによってファイルをコンパクトな手法で記憶させることを可能にしながら索引し、探索し、そしてハイパーテキストリンキングすることができる。図１４は、バイナリファイル引渡しサーバ１２を使用するポータブル文書引渡しシステム１６０ａを示す機能ブロック図である。図１５は、インターネットを通して通信する２つのバイナリファイル引渡しサーバ１２ａ及び１２ｎを使用するポータブル文書引渡しシステム１６０ａを示す機能ブロック図である。
【００４６】
付加的なサービスを提供するのに加えて、Ｗｅｂ 及び電子メールの制限に対処するために、ポータブル文書引渡しシステム１６０は、現存する電子メールのトップを走るサーバソフトウェア（即ち、 ｈｔｔｐ サーバソフトウェア）、及びデータベースシステムを含む。従って、ポータブル文書引渡しシステム１６０は、電子メール、Ｗｅｂ 、及びデータベースのための工業標準手法を組合わせて会社及びユーザが文書を受信側へ引渡すのを可能にする。以下の説明は、ユニバーサル文書引渡し手法、並びにポータブル文書引渡しシステム１６０の特定構成要素に対する要求に関して詳述するものである。ポータブル文書引渡しシステム１６０は、３つの基本構成要素を組合わせてユニバーサル文書引渡しに対する解決方法を提供する。
【００４７】
１）ポータブル文書送信クライアント。
ポータブル文書送信クライアント（ＰＤＳＣ）１９２は、全てのデスクトップアプリケーション１９０をポータブル文書引渡しシステム１６０に直接統合する。ＰＤＳＣ １９２は本発明の全ての実施例について要求されるものではない。ＢＦＤサーバ１２を直接的にレバレッジすることだけを望んでいる公表者は、そのようにする必要はない。ＰＤＳＣ１９２は、引渡し問題に対してポイント・ツー・ポイントを要求する標準の会社コンピュータユーザのために意図されているのである。
２）バイナリファイルサーバ。
バイナリファイル引渡しサーバ１２は、インターネット標準のトップで作業して受信側に文書を引渡す。ＢＦＤサーバ１２は、ポータブル文書送信クライアント（ＰＤＳＣ）１９２を通して透過的に呼出すことも、またはサーバ構成ユーザインタフェース１９８を使用して直接呼出してカストマイズすることもできる。
【００４８】
３）ポータブル文書受信クライアント。
ポータブル文書受信クライアント（ＰＤＲＣ）１９４は、文書の受信側２２が文書を受信し、見て、印刷するのに使用するソフトウェア構成要素である。ＰＤＲＣソフトウェア１９４を有していない受信側２２には、インターネットを通して直接的にソフトウェアにアクセスするためのリンクが与えられる。殆どの場合、ＰＤＲＣ １９４は、単に、Ｎｅｔｓｃａｐｅ ＮＡＶＩＧＡＴＯＲ（商品名）プラグイン、または Ｍｉｃｒｏｓｏｆｔ ＡｃｔｉｖｅＸ（商品名）制御、または Ｊａｖａ Ａｐｐｌｅｔとして挙動し、従ってＰＤＲＣ １９４を受信側の現存ブラウザと直接統合する。図１６は、ポータブル文書送信クライアントアプリケーション及びポータブル文書受信クライアントアプリケーションを、どのように本発明内に使用するかを示している。図１７は、サーバ構成ユーザインタフェースアプリケーションを、どのように本発明内に使用するかを示している。
【００４９】
ポータブル文書引渡しシステム要求
殆どの基本レベルにおいて、文書引渡し方法は、文書の手順によって文書をクライアントに導く、即ち「プッシュ」することができなければならない。ポータブル文書引渡しシステム１６０は、異なるオペレーティングシステムを用いる異なるコンピュータシステム上で異なる型の受信側が動作するものとして設計されている。Ｅメールシステム及び文書型は、電子ポータブル文書の受信、読み取り、及び使用の全ての便益を得ることができる。いろいろな設計パラメタカテゴリは、ポータブル文書引渡しシステム１６０が主要コンピュータシステム（例えば、ＰＣ、ワークステーション、サーバ）、主要オペレーティングシステム（例えば、Ｍａｃｉｎｔｏｓｈ 、Ｗｉｎ ３．１ 、Ｗｉｎ ’９５ 、ＮＴ、Ｕｎｉｘ、ＯＳ／２）、電子メールシステム（例えば、Ｍｉｃｒｏｓｏｆｔ 、ｃｃ： Ｍａｉｌ、Ｇｒｏｕｐｗｉｓｅ 、Ｎｏｔｅｓ 、Ｅｕｄｏｒａ）、文書型（例えば、ｐａｐｅｒ 、Ｐｏｓｔｓｃｒｉｐｔ、Ｑｕａｒｋ 、ＷｏｒｄＰｅｒｆｅｃｔ 、Ｅｘｃｅｌ ）、及びユーザ型（例えば、ＭＩＳ 、Ｌｅｇａｌ 、Ｆｉｎａｎｃｉａｌ 、Ｃｏｎｓｕｍｅｒｓ／Ｈｏｍｅ、Ｍａｒｋｅｔｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＭａｒＣｏｍ ））を含むようになっている。
【００５０】
ポータブル文書引渡しシステム１６０の独特な面は、全てのコンピュータシステム、オペレーティングシステム、電子メールシステム、及び文書型を用いた手法が提供する互換性のレベルにある。本発明の一実施例では、文書の送信側１６及び受信側２２は共にインターネットに接続されている。本発明の好ましい実施例では、ポータブル文書引渡しシステム１６０が、インターネット引渡し手法だけではなく、ファクシミリ１７２及びプリンタ１７８との後方互換性、及び将来分布印刷アーキテクチャとの前向きの互換性をも提供する。
【００５１】
万能引渡し引渡し手法は、いろいろな計算プラットフォームに対する支援、ファクシミリ１７２との互換性、及び将来分布印刷アーキテクチャとの互換性を要求している誰に対しても、ユーザが文書を分配すことができるようにしなければならない。ポータブル文書引渡しシステム１６０は、複雑なポストスクリプトファイルの変換及び引渡しを支援することができる。文書は、（受信側のプラットフォームまたはＥメールシステムとは無関係に）Ｅメールアカウントとインターネットへのアクセスとを有しているどの受信側へも引渡すことができる。
【００５２】
機密保護
文書引渡しの典型的なアプリケーションは、文書の出所から宛先まで完全な機密保護を要求する。この要求は、文書が開かれた広域ネットワーク上を通って走行し始めるにつれて、より広がり始めている。ポータブル文書引渡しシステム１６０は幾つかのレベルの機密保護を使用する。「ポータブル文書送信クライアント」１９２は認証し、サーバ１２へのアップロード情報への安全ソケットを作成する。従って、非ＢＦＤサーバは、文書を横取りすることはできない。付加的にＰＤＳＣ １９２は、送信側１６が私用及び／または公開暗号を使用して、文書の意図した受信側だけがこれらの文書にアクセスできるようにする。たとえ暗号が使用されない場合でも、ポータブル文書引渡しシステム１６０は無許可のユーザが文書にアクセスしないようにする精緻な（高度な）アルゴリズムを含んでいる。
【００５３】
アカウント管理サービス
多くの場合、文書引渡しアプリケーションは、文書の各送信側１６または受信側２２が維持しなければならないビジネスの要求を満たす。同一群内の十万の受信側２２へ定期的に文書を引渡す場合を考えよう。文書の送信側１６は、大きい定期講読／分配ベースのデータベースを更新し、処理するためのツールを要求する。ポータブル文書引渡しシステム１６０は、公表者がＢＦＤサーバ１２上にアカウントを作成し、次いで特定アカウント１３２、１３４、１３６とのトランザクションを結合させる。システムは、公表者が幾つかのユーザアカウントを単一の請求アカウント１３４に合併することも可能にする。システムは更に、公表者が特定の請求コードを、トランザクション報告内に合併することが可能なトランザクションと結合できるようにする。例えば、法定ファームは、各文書のトランザクションに伴う請求コード及びアカウントと結合させてアカウントを、次いで各クライアント毎の請求コードを作ることができる。ポータブル文書引渡しシステム１６０は、アカウント情報を維持し、自動的に更新する。次いでポータブル文書引渡しシステム１６０報告エンジンは、ユーザが所与のアカウント、または特定の請求コードについての報告を作成することを可能にする。この計画は、クライアント管理並びに請求を容易にする。
【００５４】
トランザクション管理サービス
アカウント管理に関連しているのは、トランザクション管理の要求である。文書の送信側１６及び受信側２２のデータベースを維持する必要があるだけではなく、送信文書のトランザクションを管理するサービスを提供する必要もある。例えば、送信側１６は、文書が実際に引渡され、実際に受信されたか否か、及び多分、誰が文書を受信したかを知りたいであろう。多くの場合、公表者１６は引渡しに対する郵便料金を請求したいであろうから、引渡しトランザクションに関連するアカウント情報を維持し、更新するサービスを要求するであろう。ポータブル文書引渡しシステム１６０は、各送信トランザクションに関連するログを作成し、これらのログを維持することができる。各トランザクション、または文書送信動作は、特定のアカウントに関連付けられる。ユーザ１６は、トランザクション情報をサーバから直接問合わせることができる。
【００５５】
報告
アカウント及びトランザクション管理は、報告の精緻な手段を設けない限り無価値である。例えばユーザ１６は、所与のトランザクションの完全な報告（どの文書が誰に引渡されたか、どれ程多くのユーザが文書の引渡しを確認したか、または請求の目的のために、そのトランザクションに関連する費用のような情報を含む）を準備することができる。
スケーラビリティ及び帯域幅
文書引渡しアプリケーションの範囲及びアプリケーションは広範であるので、ポータブル文書引渡しシステム１６０は、百万の文書または受信側２２にサービスするようにその能力を拡張することができる。引渡しプロセスの幾つかの面は実時間で発生させ、他の面は遅れさせる、またはスケジュールすることができる。多くの場合、ポータブル文書引渡しシステム１６０は、帯域幅の量、または文書引渡しに必要な処理能力を得るために、展開中のサーバ１２ａ−ｎの集合を動的に拡張する。
【００５６】
ポータブル文書引渡しシステム１６０は、ユーザ要求に適合させるようにスケーラブルである。サーバソフトウェアは、毎日百万の文書を送るのを支援するように設計されており、たとえ帯域幅が所与のサーバに専用されていたとしても利用することができる。例えば、１つの現行ＢＦＤサーバ１２は実効的に １０ メガバイト／秒の帯域幅を使用する。ＢＦＤサーバ１２上で走るいろいろなプロセスは非同期で動作するから、多重処理サーバ１２上の最適性能を可能にし、所与のトランザクションのサービスの精緻なスケジューリングを可能にする。実時間で動作させる場合、特に受信側２２がサーバ１２から文書にアクセスする場合には特別な注意が必要である。ＢＦＤサーバ１２は、他のサーバ１２ａ−ｎにワークロードを分配することもできる。本発明の好ましい実施例は、単一のサーバ１２上を走る個々の処理を、サーバ１２ａ−ｎの集まりに分配することができる。この実施例では、アカウント管理プロセスを１つのサーバ（例えば、１２ｄ）上で走らせ、一方ロギング、報告、トランザクション管理、送信、伝播、及び検索プロセスを別のサーバ（例えば、１２ｈ）上で走らせる。
【００５７】
ポータブル文書送信クライアント仕様
ポータブル文書送信クライアント（ＰＤＳＣ）１９２は、どのコンピュータユーザも、ＰＣまたはマッキントッシュコンピュータのようなどのパーソナルコンピュータのデスクトップからでも文書を直接分配することができるようにする。ＰＤＳＣ １９２は、仮想プリンタデバイスを使用することによって全ての応用１９０を直接的に統合し、それによってＰＤＳＣ １９２を全てのアプリケーション及びフォーマットと互換可能にすることができる。重要なことは、ＰＤＳＣ１９２がポータブル文書技術と直接的に統合されるために、文書の送信側１６は文書の意図した受信側の能力に関する仮定を行わないことである。ＰＤＳＣ １９２は、２つの主要モード、即ち印刷、または「ドラッグ・アンド・ドロップ」を使用可能にする。印刷によって送信側１６はどのようなアプリケーション１９０からも簡単に印刷オプションを選択し、ポータブル文書を生成するためにイベントのシーケンスをトリガし、そしてその文書をアドレスして送り出すことができる。ユーザの観点からすれば、ユーザは簡単に印刷コマンドを選択し、標準アドレシングインタフェース及びアドレスブックを使用して文書の宛先について入力要求（もしくはプロンプト）される。例えば、Ｍｉｃｒｏｓｏｆｔ Ｍａｉｌ（商品名）のユーザは標準Ｍｉｃｒｏｓｏｆｔ Ｍａｉｌ （商品名）アドレシング対話によって、文書を送ることができる場所を指示するように入力要求される。文書の宛先を選択すると、ＰＤＳＣ １９２はＢＦＤサーバ１２に自動的に接続され、文書１６６及び意図した受信側２２のリスト、並びに送信をカストマイズするために選択された何等かの他の属性を安全にアップロードする。「ドラッグ・アンド・ドロップ」を使用することにより、ユーザ１６は文書を送り出すためのアプリケーション及び印刷の開始を回避することができ、そして文書は単に、送信側のデスクトップ１６４からアクセス可能なＰＤＳＣ １９２上にドロップさせることができる。
【００５８】
付加的な機能及びカストマイゼーションは、１クリック・アウェイである。アドレシングプロセス中、ユーザ１６は、アドバンスドオプションを呼出すことによってユーザの送信のオプションを自由にカストマイズする。省略時値にすると、各送信側は文書を送り出すための既存パラメタを再使用する。ユーザ１６は、例えば機密保護オプション及び受信証要求を含むユーザの引渡しオプションをカストマイズするために、アドバンスドオプションユーザインタフェース１９３を使用することもできる。例えば、もしユーザ１６が私用及び／または公開キー暗号を含む機密保護をカストマイズすることを望むのであれば、ユーザは単に「公開暗号」または「私用暗号」オプションを調べる。同様に、ユーザは「受信時通知」オプションを選択することができ、それによって文書が実際に受信された時にＢＦＤサーバ１２は引渡しを確認することができる。
【００５９】
ＢＦＤサーバ構成オプション及びユーザインタフェース
ＢＦＤサーバ１２は、送信側デスクトップ１６４から直接構成し、カストマイズすることができる。デスクトップからＢＦＤサーバ１２へのアクセスは、ＨＴＭＬフォームユーザインタフェースを使用して達成される。このユーザインタフェースはサーバ管理者アクセスを与え、ＢＦＤサーバ１２のアドバンスドオプションを制御するために存在する。例えば、サーバ管理者は、特定の文書を受信するように意図されている １００，０００の受信側のデータベースを更新し、次いでこれらの受信側への文書の送信を直接引き起こすことができる。サーバ管理者は、先週中に発生した送信トランザクションに関する報告を生成することができる。デスクトップ１６４からＢＦＤサーバ１２へアクセスするためには、ユーザ１６はＢＦＤサーバ１２上で作成される特別アカウント（ＢＦＤサーバ１２によって意外に早く作成される）を有していなければならない。更に、このアカウントを通してＢＦＤサーバ１２へアクセスするには認証及び機密保護の幾つかの層を通過することを必要とし、従って非請求アクセスが防がれる。
【００６０】
「サーバ構成ユーザインタフェース」１９８によってユーザ１６は、トランザクション管理、アカウント管理、報告機能、文書分配のための直接アップロード及びダウンロード、受信側リストの直接処理、及び送信オプションへの直接アクセスを含むことができるサーバ設定にアクセスし、制御することが可能になる。
【００６１】
ポータブル文書受信クライアント
文書のクライアント２２は、ポータブル文書送信クライアント１９２によって、またはＢＦＤサーバ管理者を介して直接的にＢＦＤサーバ１２によって、受信側２２に送られた文書にアクセスし、処理するためにポータブル文書受信クライアント（ＰＤＲＣ）１９４を利用することができる。文書の受信側２２がＰＤＲＣ １９４を有していない場合には、ソフトウェアをインターネットから直接ダンロードして導入することができる。ポータブル文書引渡しシステム１６０のアーキテクチャはこのプロセスを簡易化し、始めての受信側２２が文書を受信するのに必要なソフトウェアにアクセスすることから１クリック・アウェイできるようにするための新ブラウザアーキテクチャの出現に加えて、専用のソフトウェア及びスクリプトを使用する。
【００６２】
ポータブル文書受信クライアント１９４の最も基本的な場合は、Ｎｅｔｓｃａｐｅ ＮＡＶＩＧＡＴＯＲ（商品名）プラグイン、または Ｍｉｃｒｏｓｏｆｔ ＡｃｔｉｖｅＸ（商品名）制御のようなブラウザ拡張として機能するだけでよい。他のユーザの場合には、ＰＤＲＣ１９４はヘルパーアプリケーションとして作動するスタンドアロンアプリケーションとして挙動する。第３のアプリケーションは、受信側デスクトップ１７０からポータブル文書へ直接アクセスすることを好むポータブル文書引渡しシステム１６０のクライアントのために存在している。この構成では、専用ポータブル文書受信クライアント１９４はインターネットから直接ダウンロードすることができる。この構成要素は、ポータブル文書引渡しシステム１６０の活動を頻繁に監視し、何等かの入力ポータブル文書をＢＦＤサーバ１２から自動的に抽出し、そしてそれらを受信側２２のコンピュータデスクトップ１７０上に即時文書通信のために開く。
【００６３】
ポータブル文書引渡しシステム１６０からのポータブル文書の受信側２２は、送信構成オプションに依存して、それらの文書から情報を見たり、探索したり、印刷したり、保管したり、またはエクスポートすることが許される。ポータブル文書引渡しシステム１６０と共に Ｅｎｖｏｙ（商品名）または Ａｃｒｏｂａｔ（商品名）を使用して分配される文書は、完全な視覚忠実度を保存し、最高レベルの品質で高分解能出力デバイス上に生成することができる。図１８は、文書をファックスゲートウェイ５６によってどのようにプリンタ１７８へ送ることができるかを示している。図１９は、文書をＬＡＮ ２０４を通してどのように専用会社ＢＦＤサーバ２００の部課ゲートウェイ２０２によって部課プリンタ１７８へ送ることができるかを示している。
【００６４】
以下に電子文書引渡しシステム及びその使用方法を、インターネットにおける使用に関連して説明するが、本発明は要望に応じて、インターネット、イントラネット、ＬＡＮ及びＷＡＮ、またはそれらの組合わせを含む広範なネットワークの何れかに適用することができる。また、本発明は要望に応じて、広範なコンピュータプラットフォーム、通信プロトコル、ポータブル文書フォーマット、またはそれらの何れかの組合わせに適用することができる。
【００６５】
インターネット／イントラネット機密保護
本発明は、一連のファイアウォール及び／またはプロキシサーバを通して文書を送るための方法及びシステムをも提供する。ファイアウォール及びプロキシサーバは、実質的に全ての型のデータが、デスクトップコンピュータからインターネットサーバへ分配されるのをブロックする。しかしながら、ファイアウォールは、テクスチャルデータにとってハイパーテキスト転送プロトコル（ＨＴＴＰ）が、ユーザがＨＴＭＬ（ハイパーテキストマークアップ言語）形状で満たすことができる有効動作であると仮定している。従って、ファイアウォールはテクスチャルデータのためのＨＴＴＰをブロックしない。本発明は、ＨＴＴＰのこの特色を使用することによって提供される機密保護を迂回し、ファイアウォールを通して文書を移動させる。
【００６６】
本発明は、イントラネットの内側のデスクトップコンピュータから一連のファイアウォール及び／またはプロキシサーバを通してインターネット上に存在するサーバへバイナリデータを引渡す。インターネット上に到達したデータは、他のインターネットサーバ、インターネットデスクトップコンピュータ、プリンタ、またはファクシミリのような受信側へ直接転送することができる。ファイアウォール及びプロキシサーバを実現するために、いろいろな技術を使用することができる。例えば、専用ハードウェアまたはソフトウェアを使用していろいろなＴＣＰ／ＩＰ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ）ポートをブロックすることができる。送る情報、及び阻止する情報（例えば「不良」情報）の型を解析するためにソフトウェアを使用することができる。しかしながら、イントラネットユーザがインターネットにアクセスする場合、ＨＴＴＰ（インターネット情報にアクセスするための最も基本的なプロトコル）が使用可能でなければならない。テクスチャルデータにとってＨＴＴＰは、ユーザがＨＴＭＬ形状で満たすことができる有効動作であると仮定している。従って、種々のファイアウォール及びプロキシサーバ計画は、ＨＴＴＰをブロックしない。
【００６７】
ＨＴＴＰの主な目的は、インターネットを通して情報を「プル」することである。ＨＴＴＰサーバにはＵＲＬ（ Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ ）として知られるファイルのアドレスが与えられており、サーバはそのＵＲＬによって参照されたデータを戻す。しかしながら、ＨＴＴＰはインターネットを通して情報を「プッシュ」することも支援する。例えば、多くのＨＴＭＬページは、ユーザがデータを入力し、サーバへ送るためのある形状を含んでいる。この形状は、例えば、インターネットの探索を要求するのに使用される。この場合、ＨＴＴＰはその形状にアクセスするために、サーバからユーザへ情報をプルする。次いでＨＴＴＰは、その形状からのデータ入力をユーザからサーバへプッシュする。ＨＴＴＰは、ブロックするとしても極く稀にブロックする（特に、小さいテクスチャルデータを）だけであり、情報をプッシュ及びプルするのに使用できるから、ＨＴＴＰは殆どのファイアウォール及びプロキシサーバを迂回するのに使用することができる。それにより、ユーザは、バイナリデータをイントラネット上のデスクトップコンピュータからインターネットへ送ることができる。本発明の好ましい実施例では文書をイントラネットからインターネットへ送るようになっているが、当分野に精通していれば、本明細書から、本発明を広域ネットワークのような他の電子通信ネットワークにも適用できることが理解されよう。
【００６８】
図２０は、本発明によるファイアウォール及び／またはプロキシサーバを通してデータを伝送するシステム３１０の概要図である。ＧＩＦフォーマットイメージファイル３１２のような文書またはファイルは、イントラネットシステム内に存在するコンピュータ３１４内に格納される。イントラネットは、１つまたはそれ以上のファイアウォール及び／またはプロキシサーバ３１８によって保護されている。本発明の好ましい実施例では、コンピュータはデスクトップコンピュータである。しかしながら、本発明の代替実施例では、コンピュータはサーバコンピュータである。若干のファイアウォール及び／またはプロキシサーバは、データのサイズに基づいて非テクスチャルデータをＨＴＴＰがプッシュするのをブロックする。例えば、典型的な形状は、サーバへ送られる重大な量の情報を含んでいない。従ってＨＴＴＰプッシュサイズを、例えばＨＴＭＬ形状を完成させるのに必要なテクスチャルデータの量に制限することができる。
【００６９】
従って、本発明の好ましい実施例では、送信コンピュータは、テキストとして送られるバイナリデータを、例えばベース ６４ エンコーディングを使用してエンコードする。もしデータのサイズに基づいてＨＴＴＰプッシュがブロックされれば、送信コンピュータは、サイズ制約に従う小さいパケットにデータを区切ることになろう。以上のように、バイナリファイルはテキストに変換され、送信側コンピュータによって小さい「テキストパケット」３１６に区切られる。次いで、クライアントはこれらのテキストパケットを、１つまたはそれ以上のファイアウォール及び／またはプロキシサーバを通して送り出す。このファイルをファイアウォール／プロキシサーバを通して引渡すことを企てる送信側のマシン上で走るソフトウェアを、「送信クライアント」と呼ぶ。テキストパケットは、テキストパケットを受入れるように構成されているファイアウォールの外側のサーバ３２０によって受信される。サーバはテキストパケットを再組立てし、テキストをＧＩＦファイル３１２の本来のバイナリ表現に戻す。
【００７０】
次いで、バイナリデータまたはファイルは、意図した受信側へ送られる。本発明がファイルを再組立てするのにサーバを使用しているために、受信デバイスがこれらの能力を有する必要がないので有利である。従って、受信側は、インターネット（または別の広域ネットワーク）に電子的に接続されているデスクトップコンピュータ３２２であっても、もしくは、実際にプリンタ、ファクシミリ、またはパーソナルディジタルアシスタントのようなデバイスであっても差し支えない。図２１は、本発明によってファイアウォール及び／またはプロキシサーバを横切ってデータを伝送するアルゴリズムの流れ図の例である。この例では、ＧＩＦファイルは、その本来のバイナリ表現で１つのデスクトップコンピュータから別のデスクトップコンピュータへ送られる。送信側コンピュータは、１つまたはそれ以上のプロキシサーバ及びファイアウォールによって保護されているイントラネットの内側に存在している。受信側コンピュータは、インターネット上で走るサーバ及びインターネットを介して送信側コンピュータに接続されている。
【００７１】
ファイアウォールは、例えばパケットを濾波するように構成されているルータであっても、または専用のファイアウォール装置であってもよい。プロキシサーバは、ファイアウォールに加えて走らせることができる。送信側コンピュータは以下のアルゴリズムを使用して、ＧＩＦファイルをファイアウォール及びプロキシサーバを通してインターネット上のサーバへ転送する。送信側コンピュータは、先ずインターネット（または広域ネットワーク）上に存在している引渡しサーバ（ファイルを引渡す）のアドレスを識別する（ステップ１２００）。引渡しサーバは、送信クライアントソフトウェアと意図した受信側との間の引渡しを処理する連絡係として動作する。本発明の好ましい実施例では、テキストパケットを傍受して本来のファイルを構築する引渡しサーバソフトウェアは、専用引渡しサーバ上で走るようになっている。しかしながら、代替の、そして同じように好ましい実施例では、引渡しサーバソフトウェアは、受信側のイントラネットシステム上を直接走り、それによって連絡係の必要性を排除している。
【００７２】
次に、送信側コンピュータは、インターネットサーバへ情報を送信し、またはインターネットサーバから情報を検索する全ての要求を傍受するプロキシサーバ（もし存在していれば）のアドレスを識別する（ステップ１２０５）。送信側コンピュータは、必要な引渡しパラメタも識別しなければならない（ステップ１２１０）。送信側コンピュータは、ＨＴＴＰアクセスを可能にするためにこの情報を供給しなければならない。送信クライアントソフトウェアは、引渡しサーバとの通信を開始させてその通信のトランザクションに特定の必要パラメタを識別するために、そのトランザクションの型を指定するための所定の構成設定を必要とすることが多い。例えば、ファイル転送トランザクションのためのパラメタは、ファイル名、ファイルのサイズ、及びファイルの型を含む。他の引渡しパラメタは、引渡しサーバのＩＰ、プロキシサーバ（もし１つが存在すれば）のＩＰ、そのプロキシサーバに特定の何等かのアカウント情報（例えば、アカウント名及びパスワード）、及びその引渡しサーバとのセッションの開始（またはログイン）に必要な何等かのアカウント情報を含む。
【００７３】
次に送信側コンピュータは、ファイル（例えば、ＧＩＦファイル）をテキストファイルに変換する（ステップ１２１５）。本発明の好ましい実施例では、送信側コンピュータはベース ６４ ＡＳＣＩＩ（テキスト）エンコーディングを使用して、ファイルの非バイナリ表現を生成する。しかしながら、他のどのような適切なエンコーディング方法も使用することができる。データの型、またはパケットだけではなく、サイズもブロックするファイアウォールまたはプロキシサーバの場合には、ＡＳＣＩＩテキスト表現は小さいテキストパケットの順序付けられたリストに細分しなければならない（ステップ１２２０）。例えば、バイナリ形状の ２０ Ｋのファイルは、ＡＳＣＩＩに変換されると ３０ Ｋに成長する。４Ｋの固定パケットサイズを使用すれば、送信クライアントから引渡しサーバへ送られるのは８パケットになり、最後のパケットは２Ｋでよいことになる。
【００７４】
送信側コンピュータは、直接、またはＨＴＴＰを使用してプロキシサーバ（もし１つが存在すれば）を介しての何れかでインターネットサーバにアクセスする（ステップ１２２５）。次いで、確立されたセッションを参照して、送信側コンピュータは引渡しサーバとのファイル転送トランザクションを開始する（ステップ１２３０）。引渡しサーバと、送信側コンピュータ上に存在する送信クライアントソフトウェアとは、双方向通信リンクまたはＨＴＴＰ導管（ ｃｏｎｄｕｉｔ ） と呼ばれるパイプを介して接続されている。ＨＴＴＰは主として単方向性プロトコルであり、ユーザはサーバにＵＲＬを提示することによってサーバからファイルを検索することができるようになっている。サーバは、ファイルをユーザに送り返すことによって応答する。しかしながら、ＨＴＴＰは、ユーザがサーバ自体に情報を送って例えば形状を満たすことができるようにもなっており、従って双方向性である。この能力をＨＴＴＰ ＰＯＳＴ法と呼んでいる。ＨＴＴＰ ＰＯＳＴ法によってＨＴＴＰプロトコルは双方向性になり、情報が送信クライアント及びサーバへ、及びこれらから流れることを可能にしている。
【００７５】
引渡しプロトコルは、送信クライアントから引渡しサーバへバイナリデータを引渡すのを可能にし、容易にするためにＨＴＴＰ導管のトップに構築されるプロトコルである。送信クライアントと引渡しサーバとの間の全ての引渡しプロトコル通信は、ＨＴＴＰ ＰＯＳＴの内側で発生する。ＨＴＴＰ ＰＯＳＴは、引渡しプロトコルが情報を引渡しサーバへ送ることができるようにする導管である。送信クライアントが引渡しサーバと対話する度に、送信クライアントは引渡しサーバ上のローカルＵＲＬに依頼することによってＨＴＴＰ ＰＯＳＴ動作を開始し、次いでＰＯＳＴ動作を介して引渡しサーバへデータを送り返す。
【００７６】
送信クライアントと引渡しサーバとの間の双方向導管は、以下のＨＴＴＰ対話を使用する。
（１）送信クライアントは、ＨＴＴＰを介してローカルＵＲＬについて引渡しサーバに依頼し、
（２）引渡しサーバは、肯定応答メッセージを送信クライアントへ送り返し、そして
（３）送信クライアントは、ＨＴＴＰ ＰＯＳＴを使用してデータを引渡しサーバへ送る。このデータは送信クライアントと引渡しサーバとの間で対話するのに使用されるプロトコルであり、それ自体は送信クライアントが引渡しサーバへ転送することを望むバイナリデータを周期的に含むことができる。
【００７７】
プロキシサーバが存在する場合には、送信クライアントと引渡しサーバとの間の通信は間接的であることができ、これらの場合にはプロキシサーバを通して行われる。
【００７８】
本発明を実現するために、どのようなメカニズムでもＨＴＴＰのトップに使用できることは理解されよう。更に、ＨＴＴＰの他に、このファイアウォール／プロキシサーバによってブロックされない、及び単方向性通信を支援するようなどのようなプロトコルも本発明を実現するために使用することができる。送信クライアントと引渡しサーバとの間のインタフェースとしてＨＴＴＰ導管を使用する場合には、引渡しプロトコルは以下のものを指定する。
【００７９】
セッション
セッションは、送信クライアントと引渡しサーバとの間の独特な結合（バインディング）及び一連のトランザクションを識別する。セッションは、送信クライアントが引渡しサーバへデータ転送を開始させるために確立される。セッションを確立するために、送信クライアントは、アカウント及び他の識別情報を引渡しサーバに提示する。もし情報が有効であれば、引渡しサーバはセッションＩＤを送信クライアントへ送る。このセッションＩＤは、爾後の送信クライアントと引渡しサーバとの間の全ての通信におけるセッションを認証し、識別するために使用される。
【００８０】
トランザクション
セッションが確立されると、送信クライアントは引渡しサーバと、所与のファイルを構成している全てのバイナリデータの転送のような１またはそれ以上のトランザクションを開始することができる。
ファイル転送トランザクション
送信クライアントは、開始するトランザクションの型を指定し、またそのトランザクションに特定のパラメタを指定する。ファイル転送トランザクションの場合には、パラメタは、ファイル名、ファイルのサイズ、及びファイルの型を含む。もし指定されたパラメタが有効であれば、引渡しサーバはトランザクションＩＤを送り返す。この時点の後に、送信クライアントは、セッションＩＤ及びトランザクションＩＤを参照して引渡しサーバに各テキストパケットを送る。送信クライアントは、各テキストパケットのサイズに対する参照も含む。引渡しサーバは、引渡されるデータの各パケット毎に成功コードを送り返す。データ転送が成功裏に完了すると、送信クライアントはメッセージを引渡しサーバへ送ってトランザクションを終了させる。もし他のトランザクションが未決でなければ、送信クライアントもセッションを終了させることができる。
【００８１】
開始されたファイル転送トランザクション及び引渡しプロトコルを使用し、送信側コンピュータは爾後のＨＴＴＰ要求に関してＨＴＴＰ導管を介して引渡しサーバにテキストパケットを提出する（ステップ１２３５）。サーバとのファイル転送トランザクションが完了し（１２４０）、引渡しサーバとのセッションが完了する（ステップ１２４５）。引渡しトランザクション及びセッションが完了すると、引渡しサーバはテキストパケットを単一のテキストファイルに再組立てする（ステップ１２５０）。引渡しサーバはテキストファイルを本来のＧＩＦファイルに変換し（ステップ１２５５）、本来のＧＩＦを意図した受信側へ転送する（ステップ１２６０）。本来のＧＩＦは直接、または参照によって（即ち、（例えば）Ｅメールアタッチメント（直接）、またはサーバ上の文書へ送られるＶＲＬ（参照）によって）転送することができる。ファクシミリまたはプリンタへの伝送も、（これらはＥメールアタッチメントではないが）直接転送であると見做される。
【００８２】
図２２は、ファイアォール及び／またはプロキシサーバを横切ってネイティブファイルを転送するのに必要な動作の流れ図の例である。送信クライアントは、ベース ６４ エンコーディングを使用してネイティブファイルをＡＳＣＩＩ（テキスト）に変換する（ステップ１３００）。次に送信クライアントはこのテキスト表現を一連の４Ｋパケットに細分する（ステップ１３０５）。送信クライアントは引渡しサーバとのＨＴＴＰ導管を開き、セッションを確立する（ステップ１３１０）。引渡しサーバは、セッションＩＤを戻すことによって応答する。送信クライアントは引渡しサーバとのＨＴＴＰ導管を開き、セッションＩＤを提示してファイル転送トランザクションを開始する（ステップ１３１５）。引渡しサーバはトランザクションＩＤを戻すことによって応答する。次いで送信クライアントは、引渡しサーバとのＨＴＴＰ導管を開き、セッションＩＤ及びトランザクションＩＤを提示して最初のテキストパケットの転送を開始する（ステップ１３２０）。最初のテキストパッケージを受信すると、引渡しサーバは成功コードを送信クライアントへ戻す。このステップは引渡しサーバが失敗を戻すか、または全てのデータ（全てのテキストパケット）が成功裏に伝送されるまで繰り返される（ステップ１３２５）。
【００８３】
送信クライアントは引渡しサーバとのＨＴＴＰ導管を開き、セッションＩＤ及びトランザクションＩＤを提示してそのトランザクションを終了させる（ステップ１３３０）。もしトランザクションが成功裏に終了すれば、引渡しサーバは成功コードを戻す。送信クライアントは引渡しサーバとのＨＴＴＰ導管を開き、セッションＩＤを提示してセッションを終了させる（ステップ１３３５）。引渡しサーバはテキストパケットを再組立てし、テキストをネイティブの表現に変換し、次いでこのネイティブの表現を受信側に転送する（ステップ１３４０）。当業者ならば、送信クライアントのための、及び引渡しサーバソフトウェアのためのソースコードは、公知のプログラミング技術及びハードウェア構成要素を使用して容易に構成することができる。また、送信クライアント及び引渡しサーバ機能は、集積回路及びＥＥＰＲＯＭのようなプログラマブルメモリデバイスを含む他の手段によって達成することもできる。
【００８４】
本発明の好ましい実施例に関連して上述したバイナリデータファイアウォール引渡し技術の例は、考え得る手法の単なる一例に過ぎない。代替実施例では、本発明の教示と矛盾しない他の手法を使用することができる。本発明は、より低いレベルの表現への降格の決定を遅らせ、それによって将来時点には降格させ得る柔軟性を保存しながら、よりリッチな機能の集合を可能にする技術をも提供する。以下に説明する動的文書変換サーバ（ＤＤＣＳ）はこの概念を利用する。
【００８５】
文書変換
図２３は、本発明によるＤＤＣＳを含むアプリケーション例を示す概要図である。ＤＤＣＳのアーキテクチャを説明するためにある例を考える。ＷｏｒｄＰｅｒｆｅｃｔ文書の送信側４１２が、フォーマットされた文書を受信側に分配することを望んでいるものとする。送信側は、その受信側がどのような能力（デスクトップコンピュータ４１４、ファクシミリ４１６、またはプリンタ４１８かどうかを含む）を所有しているのか、または所有していないのかを知らないものとする。このような場合、送信側は文書を低レベル表現に変換し、その表現を送信することを選択できる。しかしながら、もし受信側がより高いレベル表現を受信できるコンピュータを所有していれば、受信側はカラー、スケーラビリティ、または内容のようなこれらの文書の特色を失うかも知れない。従って早めに文書をより低いレベル表現に変換してしまうと、受信側の柔軟性及び機能を制限することになる。
【００８６】
もし送信側が、文書を変換するＤＤＣＳの能力を利用せずに文書を高レベルのまま、例えば ＷｏｒｄＰｅｒｆｅｃｔ文書のポータブル文書表現を送ってから受信側がプリンタであることが判明すれば、引渡しは失敗する。上述した何れの例も最適の技術を提供していない。即ち、「最良とは、データの初期フォーマット及び受信側の能力に基づく最高のレベル表現である」と定義すれば、上例は受信側に対して最良のデータ表現で分配しない。説明中のＤＤＣＳは、この例において最適の結果を達成する。文書の送信側４１２は、ＤＤＣＳサーバ４１０を介して受信側へデータを送信するので、送信側と受信側との間にあるレベルの間接性が導入される。データは、高レベル表現で送信側からＤＤＣＳへ引渡される。ＤＤＣＳサーバはデータを伝播させ、データを意図した受信側の近傍に到達させる。各ステップにおいて、引渡されるデータ及び次のサーバまたは受信側の能力に基づいて、ＤＤＣＳはデータを高レベル表現からより低いレベル表現へ動的に変換する。最終的に、端末ＤＤＣＳサーバ４２０は（もし必要ならば最終データ変換を行って）文書を受信側に引渡す。
【００８７】
上記 ＷｏｒｄＰｅｒｆｅｃｔ文書の例において、送信側４１２が ＷｏｒｄＰｅｒｆｅｃｔでＭａｃｉｎｔｏｓｈコンピュータを走らせており、受信側がファクシミリであるものとしよう。この場合、送信側は高レベル表現の ＷｏｒｄＰｅｒｆｅｃｔ文書を最初のＤＤＣＳサーバ４１０に送る。文書の ＷｏｒｄＰｅｒｆｅｃｔからＰＤＦのようなポータブルの高レベル表現への変換は、ユーザには透過的である。このような変換は、送信側によって、または例えば Ａｄｏｂｅ Ａｃｒｏｂａｔから提供されるＰＤＦフォーマットのような公知のフォーマットで動作している最初のＤＤＣＳによって遂行させることができる。最初のＤＤＣＳサーバはＰＤＦ文書を受入れ、次いで標準ネットワークプロトコルに基づいて受信側への転送を開始する。この場合、送信側がサンフランシスコに位置し、一方受信側のファクシミリがパリにあるものとしよう。ＤＤＣＳサーバはＰＤＦ文書を、パリに位置する別のＤＤＣＳサーバ４２０へ転送する。この第２のＤＤＣＳサーバは、文書を受信側に転送しようとする。引渡しの点において、第２のＤＤＣＳサーバは、データベースをルックアップするか、または受信側との対話によって、受信側がファクシミリであることを学習する。次いで、パリのＤＤＣＳサーバは、このファクシミリがどのような能力を持っているのかを見出す。この例では、ファクシミリは「グループ４」圧縮イメージを支援するものとする。そこで、パリのＤＤＣＳサーバは、公知の技術を使用してＰＤＦ文書を「グループ４」圧縮イメージに動的に変換する。この場合、「グループ４」圧縮、白黒 ２００×１００ ドット／インチが最良表現であると決定される。
【００８８】
これとは対照的に、受信側は Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｌｏｒ Ｄｅｓｋｊｅｔプリンタ４１８であることをパリのＤＤＣＳサーバ４２０が見出したものとしよう。この場合、パリのＤＤＣＳサーバは、普通の技術を使用して文書をＰＤＦから、より低いレベルのＨＰプリンタ制御言語に変換する。先行例とは異なり、この場合の最良表現は、カラー ３６０×３００ ドット／インチである。更に、受信側はＤＯＳシステムで走るパーソナルコンピュータ４１４を有していることをパリのＤＤＣＳサーバ４２０が見出したものとしよう。この場合、パリのＤＤＣＳサーバは、文書のテクスチャル表現を受信側に送る。受信側は Ａｃｒｏｂａｔアプリケーション（ＰＤＦファイルを読むことができるプログラム）を導入した Ｗｉｎｄｏｗｓオペレーティングシステムで走るパーソナルコンピュータを有していることをパリのＤＤＣＳサーバが見出したものとすれば、サーバは文書のＰＤＦ表現を送る。
【００８９】
図２４に、本発明による動的文書変換サーバＤＤＣＳを含むアプリケーションの別の例を示す。この場合、送信側４２２は Ｑｕａｒｋ Ｅｘｐｒｅｓｓ文書を送ることを望んでいる。上述したものと同一のプロセスがここでも遂行され、それによって文書は高レベル表現（この場合には Ｅｎｖｏｙ）に透明的に変換され、最初のＤＤＣＳサーバ４２６に引渡される。ＤＤＣＳサーバはこの文書を、意図した受信側４２４に直接引渡し、この文書を別のサーバに送ることはしない。ＤＤＣＳサーバは、受信側への引渡しを開始する時に、受信側が文書フォーマットを読むことができる Ｅｎｖｏｙアプリケーションを所有していないが、その代わりに文書のＧＩＦビットマップを読むことができる Ｗｅｂブラウザを有していることを見出したものとする。この場合、ＤＤＣＳサーバは高レベル Ｅｎｖｏｙ表現をより低いレベルのＧＩＦ表現に動的に変換し、ＧＩＦを受信側に引渡す。
【００９０】
図２５は、本発明による動的データ変換サーバの現在では好ましい例の概要図である。ＤＤＣＳの好ましい実施例の設計は、図２４の例と全く同一である。本発明のこの実施例では、送信側４２２は、その装置上で走る送信クライアント４３１を有している。本発明のアーキテクチャは、例えば文書のようなデータ４３２が高レベル表現であり、従ってデータはある形状のコンピュータ上で作成されるものと仮定している。データが例えば ｐａｐｅｒのような低レベル表現で開始できるような場合でも（もし送信コンピュータがこの表現を、例えば光学文字認識技術４４３を使用して高レベル表現に変換することができれば）、このアーキテクチャを適用することができる。送信クライアント４３１は、典型的には、先ずデータをより柔軟ではあるが、それでも高レベルの表現に変換する。これは、高レベルのフォーマットのままで分配及び変換を意図するのではなく、編集の目的からである。このようにＤＤＣＳサーバは、ポータブル文書及びＨＴＭＬのようなＳＧＭＬ派生文書を含む分配可能なデータ表現により適している。本発明の一つの好ましい実施例では、送信クライアントは、データを高レベルの表現から高レベルのポータブル表現に変換する。議論の余地があるところではあるが、このような変換は、このデータ変換によってある情報が失われ、それ程高いレベルではなくなる第１の場合を表している。典型的には、この目的のために送信側は、濾波技術または仮想プリンタドライバを使用する。本発明では送信側（クライアント）レベルにおける変換を必要とせず、本発明の他の実施例ではデータがＤＤＣＳサーバへ引渡されるまで変換を遅らせることができる。従って、本発明の１つの新らしい特色は、データをより低いレベルの表現に変換する決定を遅らせ、それによって最大の柔軟性を保存することから導かれる。
【００９１】
どのような形状であっても、高レベル表現は、例えばＨＴＴＰを介して送信側のコンピュータからＤＤＣＳサーバ４２６へ伝送される。サーバは、意図した受信側４２４へ文書を引渡すように動作する。使用される特定の引渡しメカニズムは、例えばＥメール、ＨＴＴＰ引渡しを用いたＥメール通知（ １９９６ 年１０月２４日付 Ｊ． Ｓｍｉｔｈ 、Ｊ． Ｃ． Ｂａｎｄｉｎｉ の米国特許出願第 ０８／７３８，９６６ 号 ”Ｅｌｅｃｔｒｏｎｉｃ Ｄｏｃｕｍｅｎｔ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍ” 参照）、直接ＴＣＰ／ＩＰ、またはファクシミリを含むことができる。サーバが引渡しを開始する時、引渡すデータをより低いレベルの表現に変換するのか否かを決定するために、サーバはＤＤＣＳ設備４４４を使用する。サーバは、表現間の考え得るマッピングを容易にするために、一連のマッピングテーブル４３５、４３６を維持している。テーブル４３５の例は、所与のデータ表現からの考え得るマッピングを含む。
【００９２】
表１は、所与のデータ表現からの考え得るマッピングの例を示している。
【００９３】
サーバが維持している別のマッピングテーブル４３６は、特定の能力を与えられた考え得るデータ表現を含むテーブルである。
【００９４】
表２は、特定の能力を与えられた考え得るデータ表現の例である。
【００９５】
考え得るマッピングを記述している上記テーブルが与えられたサーバは、引渡されるデータについての適切なフォーマット及び受信側の能力を決定しなければならない。幾つかの技術が使用される。
【００９６】
引渡されるデータに関する情報を引き出す主な技術は、情報をピックアプするために（４３９）、または情報を送るために（４３８）そのサーバを使用したことがある特定ユーザの能力のデータベース４３７を、そのサーバ内に維持しておくことを伴う。例えば、もし特定の受信側に文書を送るために、情報の送信側がサーバに ＭＳＷｏｒｄ文書を引渡したものとすれば、サーバはその送信側が ＭＳ Ｗｏｒｄ文書を受信でき、または同様に、Ｅｎｖｏｙ またはＰＤＦ文書も受信できることを知る。サーバはこのような情報をこの能力データベース４３７内に保持する。例えば引渡しメカニズムがＥメール及びＨＴＴＰ引渡しを使用し、ユーザがサーバから文書をピックアップする場合、ＨＴＴＰプロトコルはプラットフォーム及びインターネットＷｅｂブラウザの型及びバージョンに関する受信側の能力を記述する。この情報はこの時点に使用することができるが、例えばＨＴＴＰ引渡しを含まない引渡しに対する将来参照のために、能力データベース内に記録しておくこともできる。
【００９７】
サーバは、引渡しメカニズムの型及び受信側を記述するのに使用したアドレスに基づいて受信側の能力を推論する推論エンジン４４０をも使用する。例えば電話番号アドレスは、受信側がファクシミリを使用していることを暗示している。サーバは、ファクシミリに問合わせ、そのファクシミリが例えばグループ４を支援するのか、またはグループ３を支援するのかを決定し、相応してフォーマットを更新することができる。サーバは、ミシガン大学が開発したインターネット・ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）標準をインターネット・エンジニアリング・タスク・フォースと共に動的に使用し、受信側の能力を問合わせるためのＬＤＡＰ問合わせエンジン４４１を使用することもできる。ＬＤＡＰサーバ４４２は、ディレクトリ及び他のサービスを提供する。ＤＤＣＳサーバは、特定の引渡しに関する能力情報を、ＬＤＡＰサーバに実時間で問合わせる。
【００９８】
データフォーマットが決定され、受信側能力が識別されると、サーバはマッピングテーブルを使用してデータ変換が必要乃至は適切であるか否かを決定する。多くの場合、この決定にはマッピングテーブルをルックアップする以上のものが必要になる。例えば、最良データ表現を見出すためには多重マッピングが必要であることが多い。これらの変換は、変換エンジン４３４によって遂行される。実際のデータ変換プロセスは本発明の範囲外であり、コンピュータソフトウェア産業において広く使用可能である。例えば、Ａｄｏｂｅ Ｓｙｓｔｅｍｓ が最初のバージョンとして Ａｃｒｏｂａｔを出荷した時から、ＰＤＦ文書をどのようにして Ｐｏｓｔｓｃｒｉｐｔ文書に変換するかは知られている。もし ＡｃｒｏｂａｔビューワがＤＤＣＳサーバ上で走っていれば、そのビューワは、（もし必要ならば）特定の型のプリンタに対してある文書を印刷するように指令される。従って、結局は、実際のデータ変換自体は本発明に直接関連するものではなく、選択の問題なのである。
【００９９】
以上に本発明を特定の好ましい実施例に関して説明したが、当業者ならば特許請求の範囲から逸脱することなく種々の変更及び強調を考案できよう。
【図面の簡単な説明】
【図１】１つのバイナリファイルサーバを使用するバイナリファイル引渡しシステムのブロック線図である。
【図２】２つのバイナリファイルサーバを使用するバイナリファイル引渡しシステムのブロック線図である。
【図３】ストアアイテムのキー要素を示すブロック線図である。
【図４】バイナリファイル引渡しサーバを示す概要ブロック線図である。
【図５】バイナリファイルサーバの１実施例のアーキテクチャの例を示す図である。
【図６】バイナリファイル引渡しサーバが使用する異なる型のストアイベントを示す図である。
【図７】バイナリファイル引渡しサーバアーキテクチャ内の特定構成要素のブロック線図である。
【図８】ストアのアーキテクチャを示すブロック線図である。
【図９】ユーザセッションがインターネットクライアントをどのようにしてセッション、トランザクション、及び移送を含む３つの層に編成するかを示す図である。
【図１０】送信側セッションがストアアイテムを作成するか、または別のサーバがストアアイテムを送信した時の引渡しの非繰り返しタスクを示す図である。
【図１１】アカウント管理者アーキテクチャの詳細図である。
【図１２】ロガーアーキテクチャの詳細図である。
【図１３】サーバコネクタアーキテクチャの詳細図である。
【図１４】１つのポータブル文書引渡しサーバを使用するポータブル文書引渡しシステムを示す機能的ブロック線図である。
【図１５】２つのポータブル文書引渡しサーバを使用するポータブル文書引渡しシステムを示す機能的ブロック線図である。
【図１６】ポータブル文書送信クライアントアプリケーション及びポータブル文書受信クライアントアプリケーションがどのように本発明に使用されているかを示す図である。
【図１７】サーバ構成ユーザインタフェースアプリケーションがどのように本発明に使用されているかを示す図である。
【図１８】サーバのファックスゲートウェイによってどのように文書をプリンタへ送ることができるかを示す図である。
【図１９】ＬＡＮを通し、会社専用のサーバの部課ゲートウェイによってどのように文書を部課プリンタへ送ることができるかを示す図である。
【図２０】本発明によりファイアウォール及び／またはプロキシサーバを横切ってデータを伝送するシステムの概要図である。
【図２１】本発明によりファイアウォール及び／またはプロキシサーバを横切ってデータを伝送するアルゴリズムを示す流れ図の例である。
【図２２】本発明によりファイアウォール及び／またはプロキシサーバを横切ってネイティブファイルを転送するのに必要な動作の集合の流れ図の例である。
【図２３】本発明による動的文書変換サーバを含むアプリケーションの例を示す概要図である。
【図２４】本発明による動的文書変換サーバを含むアプリケーションの別の例を示す概要図である。
【図２５】本発明による動的文書変換サーバの現在では好ましい実施例を示す概要図である。
【符号の説明】
１０ バイナリファイル引渡しシステム
１２ バイナリファイルサーバ
１６ 送信側コンピュータ（送信側またはユーザ）
２２ 受信側コンピュータ（受信側）
３４ バイナリファイルの木
３６ 記述子
４２ ストア
４４ ストアクライアント
４６ アカウント管理者
４８ ストアアイテム
５２ インターネット送信側
５４ インターネット受信側
５６ ファックスゲートウェイ
５８ フォワーダ
６０ アーカイバ
６２ フォーマット翻訳者
６４ Ｗｅｂ 発表者
６６ ピックアップ通知者
６８ 作成イベント
６９ 削除イベント
７０ 変更イベント
７２ ユーザセッション
７４ 引渡し構成要素
７６ コンソール
７８ アカウント管理者
８０ サーバコネクタ
８２ ＯＳアクセッサ
８４ メールゲートウェイ
８６ ロガー
８８ サーバアプリケーション
９２ ストア管理者
９４ ストアアイテム管理者
９６ ストアイベント管理者
１０２ セッション管理者
１０４ ＢＦＤセッション管理者
１０６ ＨＴＭＬセッション管理者
１０８ トランザクション管理者
１１０ ＢＦＤトランザクションインタプリタ
１１２ ＨＴＭＬトランザクションインタプリタ
１１４、１１８ 移送管理者
１２０ 非対話式タスク
１２２ 引渡し管理者
１２４ サーバディレクトリ
１３０ アカウント管理者
１３２ ユーザ（ローカル）アカウント状態
１３４ 請求アカウント状態
１３６ 遠隔アカウントディレクトリ
１６０ ポータブル文書引渡しシステム
１６４ 送信側デスクトップ
１６６ 文書
１７０ 受信側デスクトップ
１７２ ファクシミリ
１７８ プリンタ
１９０ デスクトップアプリケーション
１９２ ポータブル文書送信クライアント
１９４ ポータブル文書受信クライアント
１９８ サーバ構成ユーザインタフェース
２００ 会社ＢＦＤサーバ
２０２ 部課ゲートウェイ
２０４ ＬＡＮ
３１０ データ伝送システム
３１４ 送信側コンピュータ
３１８ ファイアウォール／プロキシサーバ
３２０ インターネットサーバ
３２２ 受信側コンピュータ
４１０、４２６ 動的データ変換サーバ（ＤＤＣＳ）
４１２、４２２ 送信側
４１４ デスクトップコンピュータ
４１６ ファクシミリ
４１８ プリンタ
４２０ 端末ＤＤＣＳサーバ
４２４ 受信側
４３１ 送信クライアント
４３２ データ
４３４ 変換エンジン
４３５、４３６ マッピングテーブル
４３７ データベース
４３８ 送信側
４３９ 受信側
４４０ 推論エンジン
４４１ ＬＤＡＰ問合わせエンジン
４４２ ＬＤＡＰサーバ
４４３ 光学文字認識技術
４４４ ＤＤＣＳ設備
【発明の属する技術分野】
本発明は、コンピュータネットワークの分野に関する。より詳しく述べれば本発明は、インターネットを通して電子文書をユーザに引渡す（即ち、デリバリ（ｄｅｌｉｖｅｒｙ））技術に関する。
【０００２】
【発明の背景】
電子文書引渡し
インターネットまたは他のオンライン源から供給されるようなコンピュータ化情報源の開発につれて、電子的に使用可能な情報が急増している。現在では、インターネットへ加入しているユーザは、関心があるかも知れない、またはないかも知れないサイトを訪れるためにインターネットを通して相互にナビゲートしている。このインターネットシステムに固有の問題は、使用可能な情報が「プル」（ｐｕｌｌ ）型インフラストラクチャを通して分配され、情報を受けようとするユーザが適切な情報を探索してダウンロードするためには、関心サイトを手動で探索するか、またはファインダアプリケーションを使用しなければならないことである。情報または文書を公表し、分配することを望むユーザ（分配することを望む情報を有する個々のエンティティ、またはより大きいエンティティの何れかである）の場合、現在の「プル」システムは、「プッシュ」（ ｐｕｓｈ ）方式の受信側または受信側のグループに自由に送って分配することを許さない。
【０００３】
現時点では、簡単な文書を分配するためにファクシミリ技術が広く使用されているが、印刷される文書の質が低いこと、特に、もし受信側が紙コピーが存在することに注意を払わなければ、紙コピーが高価であり、且つ、かさ張ること、例えばテキスト及び図形を編集または処理することができないので、内容が失われること、及び特に、長いまたは複雑な文書の場合、伝送に長時間を要することを含む多くの欠陥を有している。電子メール（Ｅメール）は、コンピュータユーザから別のコンピュータユーザへ電子メッセージを送るための手段を提供する。Ｅメールは、便利さ、フォーマット、及び後刻検索するためにメッセージの格納の長所を有している。そのためにＥメールは基本通信として受入れられ、広く使用されるに至っている。しかしながら、Ｅメールは典型的にはＡＳＣＩＩをベースとするフォーマットであり、長いか、またはフォーマットされた文書の通信の場合には極めて制約されたものである。更にＥメールは、ページレイアウトグリッド、Ｐｏｓｔｓｃｒｉｐｔフォーマットされたオブジェクト、トラッキング及びカーニングを伴う多重フォント、グラフィックス、埋め込み型テーブル及びスプレッドシート、及び他の複雑な情報を含み得る報告、論文、広告、及び美術のような複雑な文書を分配するために選択する媒体ではない。若干のＥメールシステムは、ＡＳＣＩＩをベースとするＥメールメッセージに、ダウンロードされる関連ファイルをＥメールメッセージと共に付加する手段を提供する。関連ファイルの付加を許容する殆どのシステムは、単一のユーザが保護されていないファイルを１人の同僚または友人へ送ることを許容するように設計されており、複数の受信側へ制御された自動分配を許容するようにも、または事前のアカウント、請求、または他のこれらの特色（例えば、領収通知）を行うようにもなっていない。Ｅメールゲートウェイも、アタッチメントの適用性を制限し、機密保護及び領収通知または承認の問題を解消しない。
【０００４】
１９９５年４月１１日付 Ｃ．Ｂａｕｄｏｉｎの米国特許第 ５，４０６，５５７号”Ｉｎｔｅｒｅｎｔｅｒｐｒｉｓｅ Ｅｌｅｃｔｒｏｎｉｃ Ｍａｉｌ Ｈｕｂ”は、共通コアと、複数の入力及び出力モジュールとからなるコンピュータハブを有する会社間通信センターを開示している。入力モジュールは第１のエンドユーザに接続され、第１のエンドユーザによって送られるメッセージを万能フォーマットに変換する。ハブコアはメッセージをキューに入れ、それを出力モジュールへ送って宛先ユーザのフォーマットに変換させる。開示されているハブは簡単なＥメールを中継する技術を示しているが、Ｅメールフォーマットを変換するように設計されているので、元のテキストをベースとするファイルの完全性が失われる。以上のように、開示されている先行技術のシステム及び方法は、文書を引渡す若干の方法を提供してはいるが、プッシュ方式で動作しながら元の電子ファイルの完全性を保存する経済的な、高速文書引渡しシステムを提供することに失敗している。このような電子文書引渡しシステムの開発は、重要な技術的進歩をもたらすことになろう。更に、電子的ポータブル高品質文書を多くの受信側に制御された、経済的な、そしてアカウント可能な方式で分配する能力は、さらなる技術的進歩をもたらすことになろう。
【０００５】
インターネット／イントラネット機密保護
インターネットは、漸増的に通信に使用されつつある。現在では、プラットフォーム、オペレーティングシステム、またはＥメールシステムには無関係に、インターネット上で送信側が特定の受信側に文書を送ることが可能である。たとえ受信側がコンピュータでなく、インターネットに接続されているファクシミリまたはプリンタであるとしても、このような通信が可能である。多くの場合、文書の送信側は、イントラネットと称されるローカルエリアネットワーク上に存在している。送信側のコンピュータは、直接またはイントラネットのサーバを通してインターネットに接続することができる。イントラネットは、ファイアウォール（ｆｉｒｅｗａｌｌ）またはプロキシサーバ（ｐｒｏｘｙ ｓｅｒｖｅｒ）によってインターネットから保護され、絶縁されていることが多い。ファイアウォールは、イントラネットまたはデスクトップコンピュータへのアクセスを制限するソフトウェア及び／またはハードウェアである。プロキシ・サーバは、イントラネットの内側を走るマシンと、イントラネットの外側を走るマシンとの間の要求を遮る専用ソフトウェア及び／またはハードウェアである。
【０００６】
このようなファイアウォールは、幾つかの基本サービスの１つまたはそれ以上を提供する。第１に、ファイアウォールは、イントラネットユーザがインターネット上の特定情報にアクセスすることを阻止する。従って、オフィスの職員は、仕事に関係のないインターネットサイトにアクセスすることを禁止される。第２に、ファイアウォールは、イントラネット上で使用可能な情報に外部からアクセスすることを禁止する。第３に、ファイアウォールは、イントラネットユーザが秘密情報をイントラネットからインターネットへ送るのをブロックする。典型的には、請求されていない外側からのイントラネットへのアクセスをブロックすることは、イントラネットからインターネットへの情報転送をもブロックすることになる。
【０００７】
ファイアウォールによって保護されているイントラネット間で、インターネットを通してデータを転送するためにいろいろな方法が使用されてきた。これらの方法の１つが １９９５ 年５月１６日付 Ａｚｉｚ の米国特許第 ５，４１６，８４２号 ”Ｍｅｔｈｏｄ ａｎｄＡｐｐａｒａｔｕｓ ｆｏｒ Ｋｅｙ−Ｍａｎａｇｅｍｅｎｔ Ｓｃｈｅｍｅ ｆｏｒ Ｕｓｅ Ｗｉｔｈ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌｓ ａｔ Ｓｉｔｅ Ｆｉｒｅｗａｌｌｓ” に開示されている。この方法では、サイト間トラフィックは「スキップ」計画を使用して「インターネットプロトコル」（ＩＰ）層において暗号化され、通信ノードの出所及び行先アドレスの検出を防いでいる。ＩＰパケットは、ファイアウォールサーバだけが「スキップ」計画に関与すればよいように、サイトファイアウォールからサイトファイアウォールまでだけが暗号化される。あるファイアウォールが内部サイトノードから遠隔ファイアウォールへ意図されたＩＣパケットを受信すると、そのファイアウォールはＩＣパケットを暗号化し、それをその遠隔ファイアウォールへ宛てられた別のＩＣパケット内にカプセル封じして送る。遠隔ファイアウォールはカプセル封じされたパケットを解読し、それを明文でこの遠隔ファイアウォールの内側の宛先ノードへ送る。
【０００８】
しかしながらこの方法は、暗号化されたＩＰパケットが、パケットを解読するように構成された遠隔ファイアウォールサーバによって受信される必要がある。このようなファイアウォールサーバを使用していないコンピュータまたはイントラネットシステム、またはファクシミリまたはプリンタのようなデバイスへ、暗号化された情報を直接送ることはできない。コンピュータネットワークを接続する機密保護システムが、１９９６年８月２７日付Ｇｅｌｂ の米国特許第 ５，５５０，９８４号 ”Ｓｅｃｕｒｉｔｙ Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｅｖｅｎｔｉｎｇ Ｕｎａｕｔｈｏｒｉｚｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｂｅｔｗｅｅｎ Ｎｅｔｗｏｒｋｓｂｙ Ｔｒａｎｓｌａｔｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｒｅｃｅｉｖｅｄ ｉｎ ＩＰ Ｐｒｏｔｏｃｏｌ ｔｏ Ｎｏｎ−ＩＰ Ｐｒｏｔｏｃｏｌ ｔｏ Ｒｅｍｏｖｅ Ａｄｄｒｅｓｓ ａｎｄ Ｒｏｕｔｉｎｇ Ｓｅｒｖｉｃｅｓ Ｉｎｆｏｒｍａｔｉｏｎ”に開示されている。しかしながら、Ｇｅｌｂは、どのようにしてファイアウォールまたはプロキシサーバを通して文書を送ることができるのかには言及していない。従って、一連のファイアウォール及び／またはプロキシサーバを通して文書を送る方法及びシステムを提供することが有利であろう。また、もしこのような方法及びシステムが、ファクシミリまたはプリンタのようなデバイスへ文書を伝送することを許容するならば更に有利であろう。もしこのような方法及びシステムが、暗号解除用ファイアウォールによってサービスされるデバイスに受信側コンピュータを必要としなければ、更に有利であろう。
【０００９】
文書変換
２つの異なるシステム間で情報を受渡しするのに伴う多くの複雑性の１つは、例えば能力の差を含むこれらのシステム間の基本的な非互換性に由来する。プリンタは、パーソナルコンピュータとは極めて異なる能力セットを有しているが、プリンタが受け入れることができるデータフォーマットは同一セットである。例えば、パーソナルコンピュータは ＷｏｒｄＰｅｒｆｅｃｔ文書、ポータブル文書（例えば、Ａｄｏｂｅ Ａｃｒｏｂａｔ または Ｎｏｖｅｌｌ Ｅｎｖｏｙ ）、またはＨＴＭＬ文書を処理することができるかも知れない。これに対して、プリンタは、ＰＣＬファイルまたは Ｐｏｓｔｓｃｒｉｐｔ ファイルを受け入れることができるだけかも知れない。ファクシミリも、プリンタと同様に、文書のグループ３圧縮白黒ラスタ表現を受け入れるだけであるかも知れない。このようにいろいろなデバイスは、それらが受入れることができるデータの型に関して、さまざまな能力を有している。
【００１０】
同様に、異なるデータ型は、異なるレベルの柔軟性及び機能を提供する。例えば、Ｅｎｖｏｙ またはＰＤＦファイルは、どのような分解能にもスケールすることができ、数百万の色を支援することができ、そしてテキスト及びフォントを含むことができる。一方、グループ３圧縮ファックスイメージは、分解能が制限され、白黒を支援するだけであり、そしてテキスト及びフォントは含まないので、グループ３圧縮イメージの受信側の能力は、基本動作を除くどのような動作を遂行することも制限される。柔軟性が拡張されているポータブル文書のようなより頑強なデータ表現は、これらの文書をそれ程頑強でない表現に変換することができる。例えば、ポータブル文書は Ｐｏｓｔｓｃｒｉｐｔ ファイルに、またはグループ３圧縮イメージにさえも変換することができる。従って、ポータブル文書は高レベルのデータ表現であり、グループ３圧縮イメージは低レベルのデータ表現であると言うことができる。
【００１１】
殆どの場合、もし受信側のシステムが高レベルのデータ表現を受信することができれば、このような表現が提供する能力が大きいので、このような表現は極上のデータ表現である。従って、このような表現は、特に、もしこのような表現が必要に応じて高レベル表現をより低いレベル表現に変換できるメカニズムを含んでいれば、好ましい共通フォーマットになる。１９９５年６月１３日付 Ｍ． Ｗｉｌｌｉａｍｓ及び Ｒ． Ｙｕｎの米国特許第 ５，４２４，７２４号 ”Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ Ｆｏｒ Ｅｎｈａｎｃｅｄ Ｅｌｅｃｔｒｏｎｉｃ Ｍａｉｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ” は、電子メール文書を、複数のホストシステムに、及び／または単一のホストエージェントを介して外部ネットワークに分配することが可能な強化された電子メール分配方法及び装置を開示している。ホストエージェント参照テーブルが、ローカルネットワーク内の選択されたホストエージェント内に確立される。各ホストエージェント参照テーブルは、選択された宛先ノードの識別（これらのノードのための識別されたホストエージェントに対応付けられている）を含んでいる。ホストエージェント参照テーブルへのリフェラル（ ｒｅｆｅｒｒａｌ ）を使用して、選択されたノードへ宛てられた電子文書のための適切なホストエージェントを決定する。この方法及び装置内には、動的（ダイナミック）なデータ変換の準備はなされていない。従って、文書はその変更されないレベルの表現で、そして宛先ノードにおける処理能力には関係なく、引渡されることになる。
【００１２】
１９８８年６月２８日付 Ｔ． Ｓｃｈｕｌｔｚ 、Ａ． Ｇｒｏｓｓ、Ｂ． Ｐａｐｐａｓ 、Ｇ． Ｓｈｉｆｒｉｎ及び Ｌ．Ｍａｃｋの米国特許第 ４，７５４，４２８号 ”Ａｐｐａｒａｔｕｓ ａｎｄ Ｍｅｔｈｏｄ ｏｆ Ｄｉｓｔｒｉｂｕｔｉｎｇ Ｄｏｃｕｍｅｎｔｓ Ｔｏ Ｒｅｍｏｔｅ Ｔｅｒｍｉｎａｌｓ Ｗｉｔｈ Ｄｉｆｆｅｒｅｎｔ Ｆｏｒｍａｔｓ”、及び １９８７ 年１２月１５日付Ｔ． Ｓｃｈｕｌｔｚ 、Ａ． Ｇｒｏｓｓ、Ｂ． Ｐａｐｐａｓ 、Ｇ． Ｓｈｉｆｒｉｎ及び Ｌ． Ｍａｃｋの米国特許第４，７１３，７８０号 ”Ｅｌｅｃｔｒｏｎｉｃ Ｍａｉｌ”は、常時プリンタに接続され、プリンタ出力を有する源によってローカルサイトから発信された文書を、文書生成源のプリンタ出力に常時接続されているプリンタとは異なり得るプリンタまたはディスプレイデバイスを有する１つまたはそれ以上の遠隔位置に引渡す方法及び装置を開示している。通常プリンタ出力に発生するプリンタコマンド信号は、文字及び位置データ（文書の各ページ上の関連する文字と、それらの水平及び垂直位置とを表す）に変換される。文字及び位置データは遠隔位置へ伝送されてプリンタまたは他のディスプレイデバイスを駆動する形状に再変換され、元のライン対ライン準拠コピーを発生する。
【００１３】
上記 ’４２８ 号及び ’７８０ 号特許は、上流データ変換の使用を開示しているが、下流データ変換を提供していない。即ち、上記 ’４２８ 号及び ’７８０ 号特許では、プリンタへ送られるテキストを、あるプリンタに特定のフォーマットに変換することは許容している。しかしながらこの方法及び装置は、データを高レベルの表現から開始する能力を欠いており、もし変換が必要であると決定されれば、より低いレベルに変換するだけである。従ってこのアプローチは、プリンタフォーマットが未知、または文書発信前に確立される場合、またはインターネットのような異質ネットワークを使用してデータを引渡す場合には、満足できるものではない。１９９６年４月３０日付 Ｌ． Ｈａｒｋｉｎｓ 、Ｋ． Ｈａｙｗａｒｄ、Ｔ． Ｈｅｒｃｅｇ 、Ｊ． Ｌｅｖｉｎｅ 及びＤ． Ｐａｒｓｏｎｓ の米国特許第５，５１３，１２６号 ”Ｎｅｔｗｏｒｋ Ｈａｖｉｎｇ Ｓｅｌｅｃｔｉｖｅｌｙ Ａｃｃｅｓｓｉｂｌｅ Ｒｅｃｉｐｉｅｎｔ Ｐｒｉｏｒｉｔｉｚｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｈａｎｎｅｌ Ｐｒｏｆｉｌｅｓ” は、受信側プロファイル内に定義されているデバイス及び通信チャネルを使用して送信側が情報をネットワーク上の受信側に自動的に分配する方法を開示している。受信側プロファイルは、ネットワーク上の受信側の情報受信の特性及びモードを確立し、このプロファイルは全てのネットワークユーザのネットワークレポジトリに公表されるか、またはネットワーク上の選択されたグループまたは個人によってアクセス可能である。開示されたネットワークはデータ変換を行わないが、チャネルを通して通信する受信側の能力に基づいて所定のデータを送ることを含んでいる。従って、各受信側はデータを交換する前に、先ずフォーマットを確立しなければならない。
【００１４】
１９９５年４月４日付 Ｍ． ＢｌｏｏｍｆｉｅｌｄのＩ．Ｓ．特許第 ５，４０４，２３１号”Ｓｅｎｄｅｒ−Ｂａｓｅｄ Ｆａｃｓｉｍｉｌｅ Ｓｔｏｒｅ ａｎｄ Ｆｏｒｗａｒｄ Ｆａｃｉｌｉｔｙ”は、ファクシミリをベースとする情報を引渡すために、送信側をベースとする蓄積転送サービスを提供するシステムを開示している。このシステムは、ファクシミリビットマップイメージの引渡しだけに関連しており、データ変換には関連していない。現在の技術に伴う制約を考えると、より低いレベル表現まで降格させる能力を保存し、将来時点においてそのようにする柔軟性を与えるようになっているが、適切な場合にはより豊富な機能のセットをも可能ならしめるシステムを提供することが有利であろう。
【００１５】
【発明の概要】
本発明は、電子文書引渡しシステム及びその使用方法を提供する。ポータブルフォーマットであることが好ましい文書は、遠隔サーバへ送られる（例えば、ＨＴＴＰを使用して文書をサーバへ「プッシュ」する）。サーバは意図した受信側へ文書の包括的な通知を送り、受信側はローカルプロトコルを使用して文書をサーバからダウンロードすることができる。好ましい実施例では、本発明は、サーバのネットワーク（蓄積転送手法で文書及び通知を送りながら、経路指定及びアカウント情報を送信側へ送り返す）を使用して、送信側から多数の受信側へポータブル文書を制御された技法で引渡すのに使用される。本発明は、一連のファイアウォール及び／またはプロキシ・サーバを通して、イントラネットの内側のデスクトップコンピュータからインターネット上に存在するサーバへ文書を送る方法及びシステムをも提供する。ファイアウォールは、テキストデータ用のＨＴＴＰが、ユーザがＨＴＭＬ形状で記入可能な有効動作であるものと仮定している。このように、ファイアウォールは、テキストデータ用のＨＴＴＰを妨げない。本発明は、ファイアウォールを通して文書を移動させるＨＴＴＰのこの特色を使用することによって、ファイアウォールによって与えられる機密保護を回避する。
【００１６】
ファイアウォールまたはプロキシサーバによって保護されているイントラネットシステム内のコンピュータは、インターネットにアクセスするためのソフトウェアアプリケーションを使用する。またこのソフトウェアは、テキストとして送られるバイナリデータをエンコードする。このバイナリデータは、より小さいテキストパケットに細分することができる。これらのテキストパケットはＨＴＴＰを使用して、ファイアウォールの外側の、これらのパケットを受入れるように構成されたサーバへ送られる。サーバは、テキストパケットを元のバイナリデータ表現に変換する。インターネットサーバ上に到達したこのバイナリデータは、他のインターネットサーバ、インターネットデスクトップコンピュータ、プリンタ、またはファクシミリへ直接送ることが可能になる。
【００１７】
本発明は、受信側の能力及び引渡される文書の型に基づいて、引渡される文書のフォーマットを動的にカストマイズ（ｃｕｓｔｏｍｉｚｅ） する文書引渡しサーバをも提供する。それによってサーバは受信側の能力には無関係に、フォーマットされた文書を透過的に引渡すことができる。例えば、受信側プラットフォームは、デスクトップコンピュータ、ネットワークコンピュータ、プリンタ、ファクシミリ、またはパーソナルディジタルアシスタントであることができる。サーバは、文書内に含まれる情報を高レベルの表現に維持し、より低いレベル表現への変換の決定を遅らせようとし、それによって引渡しプロセス内の各ステップにおける潜在的なオプションセット及び機能を最大にする。従って、本発明はディジタルの高レベル表現から出発し、必要な場合に限ってより低いレベル表現に変換する。
【００１８】
【実施例】
バイナリファイル引渡し（または、デリバリ）システム１０は会社、出版社、及び個人が文書を電子的に分配することを可能にする。重要なのは、既存の Ｗｅｂをベースとする文書公表技術とは異なり、バイナリファイル引渡しシステム１０は文書を送って確実に分配することができる。現時点での Ｗｅｂは、文書の消費者がサーバから文書を見出し、検索しなければならないような「プル」公表環境であることが特徴である。これに対して「プッシュ」公表は、文書の作成者が消費者に直接文書を引渡すことができる。ファクシミリ（ファックス）、郵便サービス、及び電子メール（Ｅメール）は、全て「プッシュ」公表の例である。図１は、１つのバイナリファイルサーバ１２を使用するバイナリファイル引渡しシステム１０を示すブロック線図である。バイナリファイル引渡しシステム１０によってユーザは、文書をプッシュすることができ、文書の作成者はこれらの文書の宛先へ送ることができる。バイナリファイル引渡しシステム１０がプッシュ公表を達成する１つの方法は、普通はネットワーク上で情報をプルするように実現されているＨＴＴＰと、ＳＭＴＰ（これはテキストだけを支援する）とを組合わせることによってである。更に、バイナリファイル引渡しシステム１０は、送られた文書引渡しのいろいろなアプリケーションを容易にするために、サービスのホストになる。バイナリファイル引渡しシステム１０は、１つのレベルにおいて、電話回線の代わりにネットワークを使用する新世代のファクシミリ技術としての特徴を有し、そして更に、既存のファックスフォーマットより遙かに優れた新しい文書表現のための支援を導入する。別のレベルにおいては、バイナリファイル引渡しシステム１０は、大量の文書及びトランザクションを支援することができる汎用文書引渡しサーバである。全ての場合に、バイナリファイル引渡しシステム１０は、文書引渡しのための完全な、そして頑強な手法を提供する。
【００１９】
バイナリファイル引渡しシステム１０は、１つのエンドポイントから１つまたは複数のエンドポイントへ１組のバイナリファイルを送るために使用される。エンドポイントは、典型的にはインターネットへアクセスできる受信側２２であるが、ファクシミリ１７２またはプロセス１７８（図１４、１５）のような別のエンティティであることもできる。バイナリファイルの引渡しは、信頼できる、アカウント可能な、そして扱い易い手法で達成される。バイナリファイル引渡しシステム１０は、導かれたファイルのために幾つかのレベルの機密保護（Ｅメール等価機密保護から、ファクシミリまたは物理的郵便物より以上の）を提供する。システムは、請求アカウントのクレジット及びデビットを含むユーザアカウント管理をも提供する。システムは、他のあるオーソリティによって制御される、またはされない複数のバイナリファイル引渡しサーバ１２の間で共働することもできる。図２は、インターネットを通して通信する２つのバイナリファイルサーバ１２ａ及び１２ｎを使用するバイナリファイル引渡しシステムを示している。
【００２０】
バイナリファイル引渡しサーバ１２は、３つの主要モードで動作する。これらのモードは、送信側１６が請求の対象であるアカウント１３２を自身で設定するパブリックモード、送信側１６が管理者によって制御され、請求が回収発行を上回る内部アカウント発行であるプライベートモード、及び受信側２２の数は多いが送信側１６の数は僅かであるような公表モードを含むバイナリファイル引渡しサーバ１２は分離した機能構成要素からなり、必要不可欠なプロセスまたは共用ライブラリではない。図４に概要を示すバイナリファイル引渡しサーバ１２は、ストア４２と呼ばれる知的格納コンパートメントを含む。ストア４２は、ストアクライアント４４と呼ばれる１組のクライアント４４ａ−４４ｎによって増補されている。ストアクライアント４４はストア方法を使用し、ストアイベントを聴取するが、他のクライアント４４と会話したり、または他のクライアント４４に関して知ることはない。アカウント管理者４６構成要素は、送信側１６に関する情報を保持する共用サービスである。この設計は、受信アプリケーションの場合に受信側２２に関する情報をも組み入れる（Ｅメール通知とは対照的である）。
【００２１】
クライアント／サーバ汎用アーキテクチャは、よりパイプライン化された構造よりも良好な拡張性を与える。また、それはストアクライアント４４を互いに切り離す。これは、タスクの若干が会話式であり、その他のタスクがよりバックグラウンド向きであるような場合に有用である。
【００２２】
ストア
ストア４２は、１組のストアアイテム４８を含む。図３に示すようにストアアイテム４８は、バイナリファイルの木３４と、１組のストア定義属性及びクライアント定義属性である記述子３６とを含んでいる。バイナリファイルの木３４は、ストア定義属性の一部と見ることができる。ファイル記憶システムは、以下の機能を提供する。
１）ストアアイテム４８の恒久的な格納（例えば、ストアアイテム４８内に含まれるバイナリファイルの木３４はディスクに書き込まれている）、
２）ストア定義属性及びクライアント定義属性で作られた記述子３６へのクライアント読み出し／書き込みアクセス（例えば、クライアント４４はストアアイテム４８の満期日付を書き込むことができる）、
３）ストアイベント６７のクライアント通知（例えば、クライアントは新ストアアイテム４８の作成イベント６８を通知されることができる）、
４）ストア定義属性による内部管理（例えば、ストアアイテム満期日付があるイベントを生成する）。
【００２３】
ストア４２は、ストアアイテム４８へのアクセスを提供し、ストアイベント６７を生成する。ストアアイテム４８はＩＤ、作成日付、ファイルカウント、ファイル名、ファイル日付のようなストア定義属性を有し、またクライアント４４はストアイベント６７を聞くことができる。ストアイベント６７は、ストアアイテム４８の作成６８、削除６９、または変更７０を含むことができる。イベント６７は、クライアントがその仕事をどのようにして他のクライアントの極めて制限された知識に同期させるのかを定義するので、アーキテクチャにおける重要な役割を果たす。
【００２４】
ストアクライアント
ストアクライアント４４は種々雑多であることができ、特定のクライアントに関して以下に詳しく述べる。この枠組の中のストアクライアント４４は、若干のストア方法を使用して、及び／または若干のストアイベント６７を聴取してストアアイテム４８上で有用なタスクを遂行する構成要素である。
アカウント管理者
アカウント管理者４６は、ユーザ及び請求アカウントへの読み出し／書き込みアクセスを与え、クライアント４４またはシステム１０の他の構成要素によって使用される。ストア４２は、アカウントを使用しないか、またはアカウントに関して知らない。
【００２５】
他の構成要素
ストアクライアント４４及びストア４２自体が使用する他の構成要素が、システムのアクセス内に実現されている。例えば、サーバ間通信、ログ管理、及び他の管理サービスであり、これに関しては以下に説明する。図５は、サーバ機能を実現するために使用されるクライアント４４モジュール（５２−６６）を含むバイナリファイルサーバ４２の一実施例のアーキテクチャである。「インターネット送信」５２は、ストアアイテムを作成するのに使用され、属性内を充填する。「インターネット受信」５４は、既存ストアアイテム４８を開き、それらの属性を変更するために使用することができる。「ファックスゲートウェイ」５６は、ストア４２が生成した作成イベント６８を聴取し、関連ストアアイテム４８を処理し、そしてそれらをストア４２から削除する。フォワーダ５８は、ストア４２が生成した作成イベント６８を聴取し、新しいストアアイテム４８の属性を調べ、そして転送が必要か否かを決定する。「アーカイバ」６０は削除イベントを聴取し、そして削除が発生する前にストアアイテム４８を二次プライベートストアへコピーする。「フォーマット翻訳者」６２は、作成を聴取し、属性を調べ、そしてもし翻訳が必要であれば、読み出し、処理し、そしてストアアイテム４８内のファイルへ書き戻す。「Ｗｅｂ 公表者」６４は、作成イベント６８を聴取し、そしてストアアイテム属性が Ｗｅｂ公表を指定しているか否かを検査し、もし指定していれば、必要に応じて属性を読み出す。「ピックアップ通知者」６６は、作成イベント６８について聴取し、次いで受信側２２に通知する。
【００２６】
インターネットをベースとするユーザのための機密保護発行
バイナリファイル引渡しシステム１０は特殊化された機密保護方法を支援する柔軟性を提供する一方で、以下のものを含む現在の工業標準機密保護方法を容易に支援する。
（ａ）安全なサーバ相互接続及びサーバ認証（サーバ（ＨＴＴＰ）内に組み込まれているＳＳＬ ２．０を用いて利用可能）。
（ｂ）「サーバからサーバへ」（ＳＳＬＸのトップに）確保。
（ｃ）エンドポイント専用キーの支援（専用キーは、それら自体のチャネルを使用してユーザによって交換されなければならない）。
（ｄ）ＣｒｙｐｔｏＡＰＩ または標準公開キーを使用するエンドポイント公開キーの支援。システムは、ユーザがＢＦＤ使用だけのために公開キーを生成し、それに伴うユーザアカウント情報を更新することをも援助することができ、従って送信側は公開キーを入手するために受信側と直接通信する必要はない。
（ｅ）ＳＳＬ及びＭＳ ＰＣＴを有するサーバによる「クライアント認証」（エンドユーザはそれら自身の証明書を入手し、サーバはそれを認証することができる）。
【００２７】
バイナリファイル引渡しサーバ１２の重要な面は、それが複数の要求を並列に処理し、殆どの要求に対するレスポンス時間を最小にすることである。従って、正しさ及びシステム性能にとって同期発行が重要である。性能は、同期したデータアクセスを最小にし、可能である場合には常に非同期処理を遅延させることによって、そしてプラットフォームのためにマルチタスキング及びＩＰＣ （ Ｉｎｔｅｒ−Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ）を使用することによって増強される。サーバ１２の一実施例は、１つのプロセス内で低オーバヘッドのマルチタスキングを提供するスレッディングに大きく依存し、利用可能な場合には多重プロセッサ能力を導入する。この実施例におけるＩＰＣは、メールスロットまたはＲＰＣ（ Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ ） に加えて、名前付きのパイプを使用する。
【００２８】
図７は、バイナリファイル引渡しサーバ１２アーキテクチャ内の特定構成要素のブロック線図である。ユーザセッション７２は、送信セッション、受信セッション（これらはユーザがＢＦＤデスクトップアプリケーション１９２、１９８を使用している場合に実現される）、ＨＴＭＬ受信セッション（これらは、ユーザがＢＦＤデスクトップ１６４を使用している場合とは異なり、ＨＴＭＬブラウザによって実現される（ＢＦＤデスクトップセッションはＨＴＭＬによって実現できることに注目されたい））、保守セッション（アカウント設定及び保守セッション（例えば、通知ダウンロード）を実現する）、アカウント設定変更（公衆サーバのエンドユーザとは異なり、管理者によるコンソールサービスによって混乱させられることはない）、ＨＴＭＬ保守セッション（ＨＴＭＬブラウザによってアカウント設定及び保守を実現する）を処理する。
【００２９】
引渡し構成要素７４は、通知及び転送を含む引渡しを行うバックグラウンド作業を実現する。コンソール７６は、特別なユーザインタフェースの代わりにＨＴＭＬインタフェースを通して遂行される管理セッションを実現する。コンソール７６は、ユーザインタフェースをブラウザへ提供し、アカウント、ロギング、性能、及びパラメタ設定を含む全てのサーバプロパティを変更する。
【００３０】
共用構成要素
共用構成要素は、ストア４２、及び何れかのストアクライアント４４によって使用することができ、または、それらはそれら自体上で動作することができる。これらがストアイベント６７を聴取することはないが、これらは効率のために（例えば、コネクタ受信のために）必要に応じてストア方法を使用することができる。共用構成要素は、以下のものを含むことができる。
１）全てのローカルアカウント情報を維持し、請求アカウント及び遠隔アカウント情報を含むローカルアカウントに対して独特なアクセスインタフェースを提供するアカウント管理者、
２）全てのサーバ間通信を処理するサーバコネクタ８０。
３）バウンスしたメールの送信及び受信を処理するメールゲートウェイ８４。
４）型によって分類されている異なるログへのアクセス読み出し／書き込みを管理するロガー８６。最重要なログは、時間の経過と共にストアアイテム４８に何が起こったのかを追跡する送信／受信トランザクションログである。
５）ファイル入力及び出力（Ｉ／Ｏ）、プロセス管理（同期、ロッキング、スレッド、プロセス）、ＩＰＣ（ＲＰＣ、共用メモリ、共用待ち行列、パイプ）、ネットワークアクセス（ＴＣＰ／ＩＰソケット、ＨＴＴＰサーバインタフェーシング、ＰＯＰ／ＳＭＴＰインタフェーシング）のためのオペレーティングシステムに対してプラットフォーム独立インタフェースを提供するオペレーティングシステムアクセッサ８２。特定部分は、必要に応じて実施される。
【００３１】
サーバアプリケーション
サーバアプリケーション８８は、構成パラメタに従ってバイナリファイル引渡しサーバ１２の全ての片を始動及び停止させるのに使用される。またこれはアカウント管理者（４６または７８）、またはロガー８６によってカバーされない、例えば性能プロファイリング、使用情報、及びサーバパラメタ／構成のような、サーバの管理面をも提供する。図８は、ストア４２のアーキテクチャを示すブロック線図である。ストア管理者９２は、グローバル状態を維持し、アクセスをストア４２に同期させ、そしてハウスキーピング機能を提供するために使用される。ストアアイテム管理者９４は、ストアアイテム４８の状態、ロック、及びキャッシュメカニズムを維持するために使用される。ストアイベント管理者９６は、リスナーリスト及びイベントフィルタを維持するために、並びにイベントフィルタ及びイベント優先順位に従ってイベントを発送するために使用される。
【００３２】
図９は、ユーザセッションが、どのようにしてインターネットクライアントをセッション、トランザクション、及び移送を含む３つの層に編成するのかを示している。セッション管理者１０２は、現在活動中のセッション状態の全てを維持し、セッション関連ハウスキーピングを遂行する。これは、ストア４２及びアカウント管理者４６の使用を通してトランザクション管理者１０８から到来するトランザクションを処理する。トランザクション管理者１０８は、移送管理者１１４、１１８から生のデータを受け、１つまたはそれ以上のＢＦＤトランザクションインタプリタ１１０またはＨＴＭＬトランザクションインタプリタ１１２を使用して確認及び処理を遂行する。次いでトランザクション管理者１０８は、データを適切なＢＦＤセッション管理者１０４またはＨＴＭＬセッション管理者１０６に提出し、返答を待機し、次いでその返答を適切な移送管理者１１４または１１８へ送り返す。
【００３３】
図１０は、送信セッションがストアアイテム４８を作成してしまうか、または別のサーバ１２ａ−ｎがストアアイテム４８を転送している場合の引渡しの非対話式タスク１２０を示している。引渡し管理者１２２は、関連ストアイベントを聴取し、転送決定を行い、そして作業を通知者６６及びフォワーダ５８と調和させる。サーバディレクトリは、Ｅメールドメインとサーバドメインとの間の結合を追跡する。通知者６６は、受信側２２へのＥメール通知２０を処理するために使用される。フォワーダ５８は、サーバコネクタ８０を使用してストアアイテム４８を他のサーバ１２ａ−ｎへ転送するために使用される。全てのＥメール通知が受信され得るものではないから、「戻された」Ｅメールのためのサーバメールアカウントを調べ、それを失敗したトランザクションと突き合わせるためにＥメールスキャナが使用される。
【００３４】
図１１は、アカウント管理者アーキテクチャ１３０の詳細を示している。アカウント管理者７８は、ローカルサーバ１２のためにユーザアカウント状態１３２を維持し、ローカルアカウント１３２のために請求アカウント状態１３４を維持し、ローカルアカウント１３２を問い合わせ、そして遠隔アカウントのディレクトリ１３６を維持するために使用される。遠隔アカウントディレクトリ１３６の主目的は、Ｅメールアドレスと、ＢＦＤアカウントまたは非ＢＦＤアカウントの何れかとを結合させることである。図１２は、ロガーアーキテクチャの詳細図である。図１３は、サーバコネクタアーキテクチャの詳細図である。
【００３５】
システム動作
以下の例は、送信側１６から受信側２２へ電子情報を分配するのにバイナリファイル引渡しシステム１０がどのように使用されるのかを示している。仮に公表者であるカリフォルニア州レッドウッド市のサム（ Ｓａｍ ） が、日本の東京にいる仲間のロブ（ Ｒｏｂ ） に文書を送りたいものとする。以下のイベントの進行は、これがどのようにして制御された手法で達成されるかを示す。
サムがカリフォルニア州サンタクララのローカルサーバに接続する
サムのＢＦＤデスクトップは、彼のユーザアカウントが存在しているサンタクララのローカルサーバ１２ａへの接続を開く。セッション管理者１０２は、アカウント管理者７８に問合わせてユーザ１６（サム）を確認する。次いでセッション管理者１０２は、ユーザ１６のために送信セッション状態を作成する。
【００３６】
サムの送信セッション
サムのＢＦＤデスクトップは、ファイル数、ファイルのサイズ、及び意図する受信側のようなトランザクションを送る。セッション管理者１０２は、このデータをセッション状態に付加する。次いでセッション管理者１０２は、ストアアイテム記述子３６をメモリ内に作成し、ストア４２及びストアアイテムＩＤを用いてディスクスペースを確保する。これで、アップロードが開始される。セッション管理者１０２は、非同期Ｉ／Ｏを使用してデータを直接ファイルへスプールする。サムの全てのファイルのアップロード１８が完了すると、セッション管理者１０２はディスクへのストアアイテム記述子３６を非同期で更新し、次いでストアアイテム４８を非同期でストア４２内へ挿入する。セッション管理者１０２は、サムのアップロードに肯定応答で返答し、トランザクションに関する情報を提供する。これで、このセッションは終わる。
【００３７】
サンタクララのストアにおいて
ストアアイテム４８の挿入は、ストア４２によってロガー８６内に非同期でログされる。次いでストアは、登録されたイベントハンドラフィルタに対してストアアイテム記述子３６を走らせる。各突き合わせ毎に、それはイベント及び被通知者（ロブ）をそのイベント待ち行列内に挿入する。これで、そのスレッドは止まる。イベントディスパッチスレッドがイベントをプルし、システムのチューニングパラメタに依存するレートでそれらを非同期で被通知者へ発送する。
【００３８】
サンタクララ引渡しが通知される
引渡し管理者７４は関連イベントを通知し、ストア４２との同期トランザクションを介してストアアイテム４８のロックに伴うスレッドを開始させる。ロックが確保されると、スレッドはストアアイテム記述子３６を読み取り、引渡し管理者７４はそれを解析し、それをどのように処理するかを決定する。引渡し管理者７４は、受信側２２が別のＢＦＤサーバ１２ｎが位置している日本ドメインにあることを見出す。引渡し管理者７４は、サーバディレクトリ１２４に問合わせることによってこれを見出す。次いで、管理者はストアアイテム４８を転送することを決定する。転送管理者８０は、東京への転送を行うことを非同期でコネクタ８０に依頼する。これで、引渡し内のスレッドが止まる。引渡し管理者が、サーバプロトコルを知っていないことに注目されたい。
【００３９】
サンタクララコネクタ８０は、東京コネクタ８０へ転送しかかっている。引渡し要求を処理するスレッドは、結局はコネクタ８０内で始動する。それは、東京サーバ１２ｎとの接続を開始する。もし接続することができなければ、暫時休止する。結局は接続を開き、コネクタ８０はプロトコルインタプリタを入力し、結局はプロトコルインタプリタはストアアイテム記述子及び関連するバイナリデータファイルを転送する。次いで、それは接続を閉じ、東京サーバ１２ｎへの転送の成功をロガー８６内にログする。次に、コネクタ８０は、転送済であるとマークした後に、ストア４２内のストアアイテム４８上のロックを解除する。ロックが解除されると、ストア４２はストアアイテム記述子をイベントフィルタリストに対して走らせ、局部的に処理されるイベントフィルタを見出す。成功裏に転送されたストアアイテム４８は、参照カウントを１だけ減少せしめる。この例では、１つの受信側２２しか存在せず、従ってカウントが０になることを意味する。従って、ストア４２はストアアイテム４８を削除リストへ移動させることができる。そこで、ストア４２のハウスキーピングスレッドは、ある点でストアアイテム４８を消去（パージ）する。
【００４０】
東京コネクタ受信側８０内のスレッドが開始され、接続を処理する。プロトコルインタプリタがそれを転送として理解すると、それはストアアイテムＩＤ３６及び関連するコミットされた貯蔵空間についてストア４２に尋ねる。実際のストアアイテム記述子及びファイルは、それがデータを受信した時に、ディスクに書き込まれている。接続が完了すると、ストアアイテム４８が東京バイナリファイル引渡しサーバ１２ｎのストア４２内に非同期で挿入される。
【００４１】
東京引渡し構成要素が始動
挿入時には、東京ストア４２はイベントを生成しており、そのイベントは引渡しのスレッドによって処理されようとしている。また新しいアイテムの挿入をロガー８６内にログしている。引渡し構成要素７４内の管理者１０２は、これが転送されたものであり、このサーバ１２ｎから受信されるものと理解する。サーバ１２ｎは、ロブのＥメールアドレスに関連するアカウントが存在するか否かを見出すために、アカウント管理者７８に問い合わせる。もし関連アカウントがロブのＥメールに存在しなければ、ＵＲＬ（ストアアイテムＩＤ ３６を指示する）と共にＥメールがロブへ送られる。またサーバ１２ｎは、ロブに通知したことをサンタクララサーバ１２ａに通知するために、コネクタ８０に対する非同期要求を待ち合わせる。もしロブがそこにアカウントを有していれば、未決引渡しに言及するために引渡しはアカウント管理者７８を用いて非同期更新要求を行う（この場合には、シナリオが継続される）。
【００４２】
ロブは新文書を調べるために東京サーバに接続
ロブが受信セッションを開いた時、セッション管理者１０２は同期してロブアカウントの有効性について調べ、そのアカウントがペンディング受信と共にフラグされることを記憶するために、そのプロセス中にセッション状態を更新する。最終的にロブのＢＦＤデスクトップは受信すべき文書を請求する。セッション状態は「ｙｅｓ」を返答する。ロブのデスクトップ１７０は受信を請求し、セッション管理者１０２は同期的に、関連するストアアイテム４８のロックをストア４２に請求する。承認されるとセッション管理者１０２は、返答としてデータの最初の部分を送ることができる。文書がダウンロードされると、セッション管理者１０２は非同期的に、ロガー８６に受信成功をログする。次いで、セッション管理者１０２は非同期的に、サンタクララサーバ１２ａに最終引渡しを通知するようにコネクタ８０に要求する。
【００４３】
東京の受信セッションにおいて、セッション管理者１０２はロックを解除し、ストア４２へ非同期削除要求を行う。これでロブは受信セッションを終了する。サンタクララのコネクタ８０はプロトコルインタプリタを走らせる。プロトコルインタプリタは、通知をロガー８６のキューに入れなければなければならないことを述べる。
サムは状態を調べる
サムは、受信セッションと、それに続く保守セッションとを行うために接続する。保守セッション７２は送られた文書の状態を調べる要求を受信する。保守セッション７２は、非同期的に、送信時にサムデスクトップへ流したストアアイテムＩＤ ３６を使用してロガー８６へ問合わせを依頼する。この問合わせは、突き合わせ記録のリストを戻し、これらの記録は処理されてデスクトップへ流され、デスクトップはユーザインタフェース１６を更新することができる。
【００４４】
ポータブル文書引渡しシステム
電子ポータブル文書は徐々に評判になりつつある。これらのファイルは、それらの元のルック・アンド・フィールを失うことなく異なるプラットフォームに分配することができる。Ａｄｏｂｅ Ｓｙｓｔｅｍの Ａｃｒｏｂａｔ ＰＤＦ（商品名）、及び Ｎｏｖｅｌｌ のＥｎｖｏｙ（商品名）ポータブル文書フォーマットが広く用いられ始めている。本発明の好ましい実施例では、ポータブル文書引渡しシステム１６０は、ポータブル文書技術をインターネットに適用することによって電子文書の引渡しに対する万能手法を達成している。ポータブル文書引渡しシステム１６０は、Ｎｏｖｅｌｌの Ｅｎｖｏｙ（商品名）及び Ａｄｏｂｅ Ｓｙｓｔｅｍ の ＰＤＦ（商品名）を含むポータブル電子文書フォーマットと完全な互換性を有している。
【００４５】
ポータブル文書引渡しシステム１６０からのポータブル文書の受信側２２はそれらの文書からの情報を、見る、探索する、印刷する、保管する、またはエクスポートすることができる。ポータブル文書引渡しシステム１６０と共に Ｅｎｖｏｙ（商品名）または Ａｃｒｏｂａｔ（商品名）を使用して分配される文書は、完全な視覚忠実度を保存し、高分解能出力デバイス上に最高レベルの品質及び分解能をもって生成させることができる。ポータブル文書フォーマットによって文書内の情報の内容及び色を保存することができ、また多くのフォーマットによってファイルをコンパクトな手法で記憶させることを可能にしながら索引し、探索し、そしてハイパーテキストリンキングすることができる。図１４は、バイナリファイル引渡しサーバ１２を使用するポータブル文書引渡しシステム１６０ａを示す機能ブロック図である。図１５は、インターネットを通して通信する２つのバイナリファイル引渡しサーバ１２ａ及び１２ｎを使用するポータブル文書引渡しシステム１６０ａを示す機能ブロック図である。
【００４６】
付加的なサービスを提供するのに加えて、Ｗｅｂ 及び電子メールの制限に対処するために、ポータブル文書引渡しシステム１６０は、現存する電子メールのトップを走るサーバソフトウェア（即ち、 ｈｔｔｐ サーバソフトウェア）、及びデータベースシステムを含む。従って、ポータブル文書引渡しシステム１６０は、電子メール、Ｗｅｂ 、及びデータベースのための工業標準手法を組合わせて会社及びユーザが文書を受信側へ引渡すのを可能にする。以下の説明は、ユニバーサル文書引渡し手法、並びにポータブル文書引渡しシステム１６０の特定構成要素に対する要求に関して詳述するものである。ポータブル文書引渡しシステム１６０は、３つの基本構成要素を組合わせてユニバーサル文書引渡しに対する解決方法を提供する。
【００４７】
１）ポータブル文書送信クライアント。
ポータブル文書送信クライアント（ＰＤＳＣ）１９２は、全てのデスクトップアプリケーション１９０をポータブル文書引渡しシステム１６０に直接統合する。ＰＤＳＣ １９２は本発明の全ての実施例について要求されるものではない。ＢＦＤサーバ１２を直接的にレバレッジすることだけを望んでいる公表者は、そのようにする必要はない。ＰＤＳＣ１９２は、引渡し問題に対してポイント・ツー・ポイントを要求する標準の会社コンピュータユーザのために意図されているのである。
２）バイナリファイルサーバ。
バイナリファイル引渡しサーバ１２は、インターネット標準のトップで作業して受信側に文書を引渡す。ＢＦＤサーバ１２は、ポータブル文書送信クライアント（ＰＤＳＣ）１９２を通して透過的に呼出すことも、またはサーバ構成ユーザインタフェース１９８を使用して直接呼出してカストマイズすることもできる。
【００４８】
３）ポータブル文書受信クライアント。
ポータブル文書受信クライアント（ＰＤＲＣ）１９４は、文書の受信側２２が文書を受信し、見て、印刷するのに使用するソフトウェア構成要素である。ＰＤＲＣソフトウェア１９４を有していない受信側２２には、インターネットを通して直接的にソフトウェアにアクセスするためのリンクが与えられる。殆どの場合、ＰＤＲＣ １９４は、単に、Ｎｅｔｓｃａｐｅ ＮＡＶＩＧＡＴＯＲ（商品名）プラグイン、または Ｍｉｃｒｏｓｏｆｔ ＡｃｔｉｖｅＸ（商品名）制御、または Ｊａｖａ Ａｐｐｌｅｔとして挙動し、従ってＰＤＲＣ １９４を受信側の現存ブラウザと直接統合する。図１６は、ポータブル文書送信クライアントアプリケーション及びポータブル文書受信クライアントアプリケーションを、どのように本発明内に使用するかを示している。図１７は、サーバ構成ユーザインタフェースアプリケーションを、どのように本発明内に使用するかを示している。
【００４９】
ポータブル文書引渡しシステム要求
殆どの基本レベルにおいて、文書引渡し方法は、文書の手順によって文書をクライアントに導く、即ち「プッシュ」することができなければならない。ポータブル文書引渡しシステム１６０は、異なるオペレーティングシステムを用いる異なるコンピュータシステム上で異なる型の受信側が動作するものとして設計されている。Ｅメールシステム及び文書型は、電子ポータブル文書の受信、読み取り、及び使用の全ての便益を得ることができる。いろいろな設計パラメタカテゴリは、ポータブル文書引渡しシステム１６０が主要コンピュータシステム（例えば、ＰＣ、ワークステーション、サーバ）、主要オペレーティングシステム（例えば、Ｍａｃｉｎｔｏｓｈ 、Ｗｉｎ ３．１ 、Ｗｉｎ ’９５ 、ＮＴ、Ｕｎｉｘ、ＯＳ／２）、電子メールシステム（例えば、Ｍｉｃｒｏｓｏｆｔ 、ｃｃ： Ｍａｉｌ、Ｇｒｏｕｐｗｉｓｅ 、Ｎｏｔｅｓ 、Ｅｕｄｏｒａ）、文書型（例えば、ｐａｐｅｒ 、Ｐｏｓｔｓｃｒｉｐｔ、Ｑｕａｒｋ 、ＷｏｒｄＰｅｒｆｅｃｔ 、Ｅｘｃｅｌ ）、及びユーザ型（例えば、ＭＩＳ 、Ｌｅｇａｌ 、Ｆｉｎａｎｃｉａｌ 、Ｃｏｎｓｕｍｅｒｓ／Ｈｏｍｅ、Ｍａｒｋｅｔｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＭａｒＣｏｍ ））を含むようになっている。
【００５０】
ポータブル文書引渡しシステム１６０の独特な面は、全てのコンピュータシステム、オペレーティングシステム、電子メールシステム、及び文書型を用いた手法が提供する互換性のレベルにある。本発明の一実施例では、文書の送信側１６及び受信側２２は共にインターネットに接続されている。本発明の好ましい実施例では、ポータブル文書引渡しシステム１６０が、インターネット引渡し手法だけではなく、ファクシミリ１７２及びプリンタ１７８との後方互換性、及び将来分布印刷アーキテクチャとの前向きの互換性をも提供する。
【００５１】
万能引渡し引渡し手法は、いろいろな計算プラットフォームに対する支援、ファクシミリ１７２との互換性、及び将来分布印刷アーキテクチャとの互換性を要求している誰に対しても、ユーザが文書を分配すことができるようにしなければならない。ポータブル文書引渡しシステム１６０は、複雑なポストスクリプトファイルの変換及び引渡しを支援することができる。文書は、（受信側のプラットフォームまたはＥメールシステムとは無関係に）Ｅメールアカウントとインターネットへのアクセスとを有しているどの受信側へも引渡すことができる。
【００５２】
機密保護
文書引渡しの典型的なアプリケーションは、文書の出所から宛先まで完全な機密保護を要求する。この要求は、文書が開かれた広域ネットワーク上を通って走行し始めるにつれて、より広がり始めている。ポータブル文書引渡しシステム１６０は幾つかのレベルの機密保護を使用する。「ポータブル文書送信クライアント」１９２は認証し、サーバ１２へのアップロード情報への安全ソケットを作成する。従って、非ＢＦＤサーバは、文書を横取りすることはできない。付加的にＰＤＳＣ １９２は、送信側１６が私用及び／または公開暗号を使用して、文書の意図した受信側だけがこれらの文書にアクセスできるようにする。たとえ暗号が使用されない場合でも、ポータブル文書引渡しシステム１６０は無許可のユーザが文書にアクセスしないようにする精緻な（高度な）アルゴリズムを含んでいる。
【００５３】
アカウント管理サービス
多くの場合、文書引渡しアプリケーションは、文書の各送信側１６または受信側２２が維持しなければならないビジネスの要求を満たす。同一群内の十万の受信側２２へ定期的に文書を引渡す場合を考えよう。文書の送信側１６は、大きい定期講読／分配ベースのデータベースを更新し、処理するためのツールを要求する。ポータブル文書引渡しシステム１６０は、公表者がＢＦＤサーバ１２上にアカウントを作成し、次いで特定アカウント１３２、１３４、１３６とのトランザクションを結合させる。システムは、公表者が幾つかのユーザアカウントを単一の請求アカウント１３４に合併することも可能にする。システムは更に、公表者が特定の請求コードを、トランザクション報告内に合併することが可能なトランザクションと結合できるようにする。例えば、法定ファームは、各文書のトランザクションに伴う請求コード及びアカウントと結合させてアカウントを、次いで各クライアント毎の請求コードを作ることができる。ポータブル文書引渡しシステム１６０は、アカウント情報を維持し、自動的に更新する。次いでポータブル文書引渡しシステム１６０報告エンジンは、ユーザが所与のアカウント、または特定の請求コードについての報告を作成することを可能にする。この計画は、クライアント管理並びに請求を容易にする。
【００５４】
トランザクション管理サービス
アカウント管理に関連しているのは、トランザクション管理の要求である。文書の送信側１６及び受信側２２のデータベースを維持する必要があるだけではなく、送信文書のトランザクションを管理するサービスを提供する必要もある。例えば、送信側１６は、文書が実際に引渡され、実際に受信されたか否か、及び多分、誰が文書を受信したかを知りたいであろう。多くの場合、公表者１６は引渡しに対する郵便料金を請求したいであろうから、引渡しトランザクションに関連するアカウント情報を維持し、更新するサービスを要求するであろう。ポータブル文書引渡しシステム１６０は、各送信トランザクションに関連するログを作成し、これらのログを維持することができる。各トランザクション、または文書送信動作は、特定のアカウントに関連付けられる。ユーザ１６は、トランザクション情報をサーバから直接問合わせることができる。
【００５５】
報告
アカウント及びトランザクション管理は、報告の精緻な手段を設けない限り無価値である。例えばユーザ１６は、所与のトランザクションの完全な報告（どの文書が誰に引渡されたか、どれ程多くのユーザが文書の引渡しを確認したか、または請求の目的のために、そのトランザクションに関連する費用のような情報を含む）を準備することができる。
スケーラビリティ及び帯域幅
文書引渡しアプリケーションの範囲及びアプリケーションは広範であるので、ポータブル文書引渡しシステム１６０は、百万の文書または受信側２２にサービスするようにその能力を拡張することができる。引渡しプロセスの幾つかの面は実時間で発生させ、他の面は遅れさせる、またはスケジュールすることができる。多くの場合、ポータブル文書引渡しシステム１６０は、帯域幅の量、または文書引渡しに必要な処理能力を得るために、展開中のサーバ１２ａ−ｎの集合を動的に拡張する。
【００５６】
ポータブル文書引渡しシステム１６０は、ユーザ要求に適合させるようにスケーラブルである。サーバソフトウェアは、毎日百万の文書を送るのを支援するように設計されており、たとえ帯域幅が所与のサーバに専用されていたとしても利用することができる。例えば、１つの現行ＢＦＤサーバ１２は実効的に １０ メガバイト／秒の帯域幅を使用する。ＢＦＤサーバ１２上で走るいろいろなプロセスは非同期で動作するから、多重処理サーバ１２上の最適性能を可能にし、所与のトランザクションのサービスの精緻なスケジューリングを可能にする。実時間で動作させる場合、特に受信側２２がサーバ１２から文書にアクセスする場合には特別な注意が必要である。ＢＦＤサーバ１２は、他のサーバ１２ａ−ｎにワークロードを分配することもできる。本発明の好ましい実施例は、単一のサーバ１２上を走る個々の処理を、サーバ１２ａ−ｎの集まりに分配することができる。この実施例では、アカウント管理プロセスを１つのサーバ（例えば、１２ｄ）上で走らせ、一方ロギング、報告、トランザクション管理、送信、伝播、及び検索プロセスを別のサーバ（例えば、１２ｈ）上で走らせる。
【００５７】
ポータブル文書送信クライアント仕様
ポータブル文書送信クライアント（ＰＤＳＣ）１９２は、どのコンピュータユーザも、ＰＣまたはマッキントッシュコンピュータのようなどのパーソナルコンピュータのデスクトップからでも文書を直接分配することができるようにする。ＰＤＳＣ １９２は、仮想プリンタデバイスを使用することによって全ての応用１９０を直接的に統合し、それによってＰＤＳＣ １９２を全てのアプリケーション及びフォーマットと互換可能にすることができる。重要なことは、ＰＤＳＣ１９２がポータブル文書技術と直接的に統合されるために、文書の送信側１６は文書の意図した受信側の能力に関する仮定を行わないことである。ＰＤＳＣ １９２は、２つの主要モード、即ち印刷、または「ドラッグ・アンド・ドロップ」を使用可能にする。印刷によって送信側１６はどのようなアプリケーション１９０からも簡単に印刷オプションを選択し、ポータブル文書を生成するためにイベントのシーケンスをトリガし、そしてその文書をアドレスして送り出すことができる。ユーザの観点からすれば、ユーザは簡単に印刷コマンドを選択し、標準アドレシングインタフェース及びアドレスブックを使用して文書の宛先について入力要求（もしくはプロンプト）される。例えば、Ｍｉｃｒｏｓｏｆｔ Ｍａｉｌ（商品名）のユーザは標準Ｍｉｃｒｏｓｏｆｔ Ｍａｉｌ （商品名）アドレシング対話によって、文書を送ることができる場所を指示するように入力要求される。文書の宛先を選択すると、ＰＤＳＣ １９２はＢＦＤサーバ１２に自動的に接続され、文書１６６及び意図した受信側２２のリスト、並びに送信をカストマイズするために選択された何等かの他の属性を安全にアップロードする。「ドラッグ・アンド・ドロップ」を使用することにより、ユーザ１６は文書を送り出すためのアプリケーション及び印刷の開始を回避することができ、そして文書は単に、送信側のデスクトップ１６４からアクセス可能なＰＤＳＣ １９２上にドロップさせることができる。
【００５８】
付加的な機能及びカストマイゼーションは、１クリック・アウェイである。アドレシングプロセス中、ユーザ１６は、アドバンスドオプションを呼出すことによってユーザの送信のオプションを自由にカストマイズする。省略時値にすると、各送信側は文書を送り出すための既存パラメタを再使用する。ユーザ１６は、例えば機密保護オプション及び受信証要求を含むユーザの引渡しオプションをカストマイズするために、アドバンスドオプションユーザインタフェース１９３を使用することもできる。例えば、もしユーザ１６が私用及び／または公開キー暗号を含む機密保護をカストマイズすることを望むのであれば、ユーザは単に「公開暗号」または「私用暗号」オプションを調べる。同様に、ユーザは「受信時通知」オプションを選択することができ、それによって文書が実際に受信された時にＢＦＤサーバ１２は引渡しを確認することができる。
【００５９】
ＢＦＤサーバ構成オプション及びユーザインタフェース
ＢＦＤサーバ１２は、送信側デスクトップ１６４から直接構成し、カストマイズすることができる。デスクトップからＢＦＤサーバ１２へのアクセスは、ＨＴＭＬフォームユーザインタフェースを使用して達成される。このユーザインタフェースはサーバ管理者アクセスを与え、ＢＦＤサーバ１２のアドバンスドオプションを制御するために存在する。例えば、サーバ管理者は、特定の文書を受信するように意図されている １００，０００の受信側のデータベースを更新し、次いでこれらの受信側への文書の送信を直接引き起こすことができる。サーバ管理者は、先週中に発生した送信トランザクションに関する報告を生成することができる。デスクトップ１６４からＢＦＤサーバ１２へアクセスするためには、ユーザ１６はＢＦＤサーバ１２上で作成される特別アカウント（ＢＦＤサーバ１２によって意外に早く作成される）を有していなければならない。更に、このアカウントを通してＢＦＤサーバ１２へアクセスするには認証及び機密保護の幾つかの層を通過することを必要とし、従って非請求アクセスが防がれる。
【００６０】
「サーバ構成ユーザインタフェース」１９８によってユーザ１６は、トランザクション管理、アカウント管理、報告機能、文書分配のための直接アップロード及びダウンロード、受信側リストの直接処理、及び送信オプションへの直接アクセスを含むことができるサーバ設定にアクセスし、制御することが可能になる。
【００６１】
ポータブル文書受信クライアント
文書のクライアント２２は、ポータブル文書送信クライアント１９２によって、またはＢＦＤサーバ管理者を介して直接的にＢＦＤサーバ１２によって、受信側２２に送られた文書にアクセスし、処理するためにポータブル文書受信クライアント（ＰＤＲＣ）１９４を利用することができる。文書の受信側２２がＰＤＲＣ １９４を有していない場合には、ソフトウェアをインターネットから直接ダンロードして導入することができる。ポータブル文書引渡しシステム１６０のアーキテクチャはこのプロセスを簡易化し、始めての受信側２２が文書を受信するのに必要なソフトウェアにアクセスすることから１クリック・アウェイできるようにするための新ブラウザアーキテクチャの出現に加えて、専用のソフトウェア及びスクリプトを使用する。
【００６２】
ポータブル文書受信クライアント１９４の最も基本的な場合は、Ｎｅｔｓｃａｐｅ ＮＡＶＩＧＡＴＯＲ（商品名）プラグイン、または Ｍｉｃｒｏｓｏｆｔ ＡｃｔｉｖｅＸ（商品名）制御のようなブラウザ拡張として機能するだけでよい。他のユーザの場合には、ＰＤＲＣ１９４はヘルパーアプリケーションとして作動するスタンドアロンアプリケーションとして挙動する。第３のアプリケーションは、受信側デスクトップ１７０からポータブル文書へ直接アクセスすることを好むポータブル文書引渡しシステム１６０のクライアントのために存在している。この構成では、専用ポータブル文書受信クライアント１９４はインターネットから直接ダウンロードすることができる。この構成要素は、ポータブル文書引渡しシステム１６０の活動を頻繁に監視し、何等かの入力ポータブル文書をＢＦＤサーバ１２から自動的に抽出し、そしてそれらを受信側２２のコンピュータデスクトップ１７０上に即時文書通信のために開く。
【００６３】
ポータブル文書引渡しシステム１６０からのポータブル文書の受信側２２は、送信構成オプションに依存して、それらの文書から情報を見たり、探索したり、印刷したり、保管したり、またはエクスポートすることが許される。ポータブル文書引渡しシステム１６０と共に Ｅｎｖｏｙ（商品名）または Ａｃｒｏｂａｔ（商品名）を使用して分配される文書は、完全な視覚忠実度を保存し、最高レベルの品質で高分解能出力デバイス上に生成することができる。図１８は、文書をファックスゲートウェイ５６によってどのようにプリンタ１７８へ送ることができるかを示している。図１９は、文書をＬＡＮ ２０４を通してどのように専用会社ＢＦＤサーバ２００の部課ゲートウェイ２０２によって部課プリンタ１７８へ送ることができるかを示している。
【００６４】
以下に電子文書引渡しシステム及びその使用方法を、インターネットにおける使用に関連して説明するが、本発明は要望に応じて、インターネット、イントラネット、ＬＡＮ及びＷＡＮ、またはそれらの組合わせを含む広範なネットワークの何れかに適用することができる。また、本発明は要望に応じて、広範なコンピュータプラットフォーム、通信プロトコル、ポータブル文書フォーマット、またはそれらの何れかの組合わせに適用することができる。
【００６５】
インターネット／イントラネット機密保護
本発明は、一連のファイアウォール及び／またはプロキシサーバを通して文書を送るための方法及びシステムをも提供する。ファイアウォール及びプロキシサーバは、実質的に全ての型のデータが、デスクトップコンピュータからインターネットサーバへ分配されるのをブロックする。しかしながら、ファイアウォールは、テクスチャルデータにとってハイパーテキスト転送プロトコル（ＨＴＴＰ）が、ユーザがＨＴＭＬ（ハイパーテキストマークアップ言語）形状で満たすことができる有効動作であると仮定している。従って、ファイアウォールはテクスチャルデータのためのＨＴＴＰをブロックしない。本発明は、ＨＴＴＰのこの特色を使用することによって提供される機密保護を迂回し、ファイアウォールを通して文書を移動させる。
【００６６】
本発明は、イントラネットの内側のデスクトップコンピュータから一連のファイアウォール及び／またはプロキシサーバを通してインターネット上に存在するサーバへバイナリデータを引渡す。インターネット上に到達したデータは、他のインターネットサーバ、インターネットデスクトップコンピュータ、プリンタ、またはファクシミリのような受信側へ直接転送することができる。ファイアウォール及びプロキシサーバを実現するために、いろいろな技術を使用することができる。例えば、専用ハードウェアまたはソフトウェアを使用していろいろなＴＣＰ／ＩＰ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ）ポートをブロックすることができる。送る情報、及び阻止する情報（例えば「不良」情報）の型を解析するためにソフトウェアを使用することができる。しかしながら、イントラネットユーザがインターネットにアクセスする場合、ＨＴＴＰ（インターネット情報にアクセスするための最も基本的なプロトコル）が使用可能でなければならない。テクスチャルデータにとってＨＴＴＰは、ユーザがＨＴＭＬ形状で満たすことができる有効動作であると仮定している。従って、種々のファイアウォール及びプロキシサーバ計画は、ＨＴＴＰをブロックしない。
【００６７】
ＨＴＴＰの主な目的は、インターネットを通して情報を「プル」することである。ＨＴＴＰサーバにはＵＲＬ（ Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ ）として知られるファイルのアドレスが与えられており、サーバはそのＵＲＬによって参照されたデータを戻す。しかしながら、ＨＴＴＰはインターネットを通して情報を「プッシュ」することも支援する。例えば、多くのＨＴＭＬページは、ユーザがデータを入力し、サーバへ送るためのある形状を含んでいる。この形状は、例えば、インターネットの探索を要求するのに使用される。この場合、ＨＴＴＰはその形状にアクセスするために、サーバからユーザへ情報をプルする。次いでＨＴＴＰは、その形状からのデータ入力をユーザからサーバへプッシュする。ＨＴＴＰは、ブロックするとしても極く稀にブロックする（特に、小さいテクスチャルデータを）だけであり、情報をプッシュ及びプルするのに使用できるから、ＨＴＴＰは殆どのファイアウォール及びプロキシサーバを迂回するのに使用することができる。それにより、ユーザは、バイナリデータをイントラネット上のデスクトップコンピュータからインターネットへ送ることができる。本発明の好ましい実施例では文書をイントラネットからインターネットへ送るようになっているが、当分野に精通していれば、本明細書から、本発明を広域ネットワークのような他の電子通信ネットワークにも適用できることが理解されよう。
【００６８】
図２０は、本発明によるファイアウォール及び／またはプロキシサーバを通してデータを伝送するシステム３１０の概要図である。ＧＩＦフォーマットイメージファイル３１２のような文書またはファイルは、イントラネットシステム内に存在するコンピュータ３１４内に格納される。イントラネットは、１つまたはそれ以上のファイアウォール及び／またはプロキシサーバ３１８によって保護されている。本発明の好ましい実施例では、コンピュータはデスクトップコンピュータである。しかしながら、本発明の代替実施例では、コンピュータはサーバコンピュータである。若干のファイアウォール及び／またはプロキシサーバは、データのサイズに基づいて非テクスチャルデータをＨＴＴＰがプッシュするのをブロックする。例えば、典型的な形状は、サーバへ送られる重大な量の情報を含んでいない。従ってＨＴＴＰプッシュサイズを、例えばＨＴＭＬ形状を完成させるのに必要なテクスチャルデータの量に制限することができる。
【００６９】
従って、本発明の好ましい実施例では、送信コンピュータは、テキストとして送られるバイナリデータを、例えばベース ６４ エンコーディングを使用してエンコードする。もしデータのサイズに基づいてＨＴＴＰプッシュがブロックされれば、送信コンピュータは、サイズ制約に従う小さいパケットにデータを区切ることになろう。以上のように、バイナリファイルはテキストに変換され、送信側コンピュータによって小さい「テキストパケット」３１６に区切られる。次いで、クライアントはこれらのテキストパケットを、１つまたはそれ以上のファイアウォール及び／またはプロキシサーバを通して送り出す。このファイルをファイアウォール／プロキシサーバを通して引渡すことを企てる送信側のマシン上で走るソフトウェアを、「送信クライアント」と呼ぶ。テキストパケットは、テキストパケットを受入れるように構成されているファイアウォールの外側のサーバ３２０によって受信される。サーバはテキストパケットを再組立てし、テキストをＧＩＦファイル３１２の本来のバイナリ表現に戻す。
【００７０】
次いで、バイナリデータまたはファイルは、意図した受信側へ送られる。本発明がファイルを再組立てするのにサーバを使用しているために、受信デバイスがこれらの能力を有する必要がないので有利である。従って、受信側は、インターネット（または別の広域ネットワーク）に電子的に接続されているデスクトップコンピュータ３２２であっても、もしくは、実際にプリンタ、ファクシミリ、またはパーソナルディジタルアシスタントのようなデバイスであっても差し支えない。図２１は、本発明によってファイアウォール及び／またはプロキシサーバを横切ってデータを伝送するアルゴリズムの流れ図の例である。この例では、ＧＩＦファイルは、その本来のバイナリ表現で１つのデスクトップコンピュータから別のデスクトップコンピュータへ送られる。送信側コンピュータは、１つまたはそれ以上のプロキシサーバ及びファイアウォールによって保護されているイントラネットの内側に存在している。受信側コンピュータは、インターネット上で走るサーバ及びインターネットを介して送信側コンピュータに接続されている。
【００７１】
ファイアウォールは、例えばパケットを濾波するように構成されているルータであっても、または専用のファイアウォール装置であってもよい。プロキシサーバは、ファイアウォールに加えて走らせることができる。送信側コンピュータは以下のアルゴリズムを使用して、ＧＩＦファイルをファイアウォール及びプロキシサーバを通してインターネット上のサーバへ転送する。送信側コンピュータは、先ずインターネット（または広域ネットワーク）上に存在している引渡しサーバ（ファイルを引渡す）のアドレスを識別する（ステップ１２００）。引渡しサーバは、送信クライアントソフトウェアと意図した受信側との間の引渡しを処理する連絡係として動作する。本発明の好ましい実施例では、テキストパケットを傍受して本来のファイルを構築する引渡しサーバソフトウェアは、専用引渡しサーバ上で走るようになっている。しかしながら、代替の、そして同じように好ましい実施例では、引渡しサーバソフトウェアは、受信側のイントラネットシステム上を直接走り、それによって連絡係の必要性を排除している。
【００７２】
次に、送信側コンピュータは、インターネットサーバへ情報を送信し、またはインターネットサーバから情報を検索する全ての要求を傍受するプロキシサーバ（もし存在していれば）のアドレスを識別する（ステップ１２０５）。送信側コンピュータは、必要な引渡しパラメタも識別しなければならない（ステップ１２１０）。送信側コンピュータは、ＨＴＴＰアクセスを可能にするためにこの情報を供給しなければならない。送信クライアントソフトウェアは、引渡しサーバとの通信を開始させてその通信のトランザクションに特定の必要パラメタを識別するために、そのトランザクションの型を指定するための所定の構成設定を必要とすることが多い。例えば、ファイル転送トランザクションのためのパラメタは、ファイル名、ファイルのサイズ、及びファイルの型を含む。他の引渡しパラメタは、引渡しサーバのＩＰ、プロキシサーバ（もし１つが存在すれば）のＩＰ、そのプロキシサーバに特定の何等かのアカウント情報（例えば、アカウント名及びパスワード）、及びその引渡しサーバとのセッションの開始（またはログイン）に必要な何等かのアカウント情報を含む。
【００７３】
次に送信側コンピュータは、ファイル（例えば、ＧＩＦファイル）をテキストファイルに変換する（ステップ１２１５）。本発明の好ましい実施例では、送信側コンピュータはベース ６４ ＡＳＣＩＩ（テキスト）エンコーディングを使用して、ファイルの非バイナリ表現を生成する。しかしながら、他のどのような適切なエンコーディング方法も使用することができる。データの型、またはパケットだけではなく、サイズもブロックするファイアウォールまたはプロキシサーバの場合には、ＡＳＣＩＩテキスト表現は小さいテキストパケットの順序付けられたリストに細分しなければならない（ステップ１２２０）。例えば、バイナリ形状の ２０ Ｋのファイルは、ＡＳＣＩＩに変換されると ３０ Ｋに成長する。４Ｋの固定パケットサイズを使用すれば、送信クライアントから引渡しサーバへ送られるのは８パケットになり、最後のパケットは２Ｋでよいことになる。
【００７４】
送信側コンピュータは、直接、またはＨＴＴＰを使用してプロキシサーバ（もし１つが存在すれば）を介しての何れかでインターネットサーバにアクセスする（ステップ１２２５）。次いで、確立されたセッションを参照して、送信側コンピュータは引渡しサーバとのファイル転送トランザクションを開始する（ステップ１２３０）。引渡しサーバと、送信側コンピュータ上に存在する送信クライアントソフトウェアとは、双方向通信リンクまたはＨＴＴＰ導管（ ｃｏｎｄｕｉｔ ） と呼ばれるパイプを介して接続されている。ＨＴＴＰは主として単方向性プロトコルであり、ユーザはサーバにＵＲＬを提示することによってサーバからファイルを検索することができるようになっている。サーバは、ファイルをユーザに送り返すことによって応答する。しかしながら、ＨＴＴＰは、ユーザがサーバ自体に情報を送って例えば形状を満たすことができるようにもなっており、従って双方向性である。この能力をＨＴＴＰ ＰＯＳＴ法と呼んでいる。ＨＴＴＰ ＰＯＳＴ法によってＨＴＴＰプロトコルは双方向性になり、情報が送信クライアント及びサーバへ、及びこれらから流れることを可能にしている。
【００７５】
引渡しプロトコルは、送信クライアントから引渡しサーバへバイナリデータを引渡すのを可能にし、容易にするためにＨＴＴＰ導管のトップに構築されるプロトコルである。送信クライアントと引渡しサーバとの間の全ての引渡しプロトコル通信は、ＨＴＴＰ ＰＯＳＴの内側で発生する。ＨＴＴＰ ＰＯＳＴは、引渡しプロトコルが情報を引渡しサーバへ送ることができるようにする導管である。送信クライアントが引渡しサーバと対話する度に、送信クライアントは引渡しサーバ上のローカルＵＲＬに依頼することによってＨＴＴＰ ＰＯＳＴ動作を開始し、次いでＰＯＳＴ動作を介して引渡しサーバへデータを送り返す。
【００７６】
送信クライアントと引渡しサーバとの間の双方向導管は、以下のＨＴＴＰ対話を使用する。
（１）送信クライアントは、ＨＴＴＰを介してローカルＵＲＬについて引渡しサーバに依頼し、
（２）引渡しサーバは、肯定応答メッセージを送信クライアントへ送り返し、そして
（３）送信クライアントは、ＨＴＴＰ ＰＯＳＴを使用してデータを引渡しサーバへ送る。このデータは送信クライアントと引渡しサーバとの間で対話するのに使用されるプロトコルであり、それ自体は送信クライアントが引渡しサーバへ転送することを望むバイナリデータを周期的に含むことができる。
【００７７】
プロキシサーバが存在する場合には、送信クライアントと引渡しサーバとの間の通信は間接的であることができ、これらの場合にはプロキシサーバを通して行われる。
【００７８】
本発明を実現するために、どのようなメカニズムでもＨＴＴＰのトップに使用できることは理解されよう。更に、ＨＴＴＰの他に、このファイアウォール／プロキシサーバによってブロックされない、及び単方向性通信を支援するようなどのようなプロトコルも本発明を実現するために使用することができる。送信クライアントと引渡しサーバとの間のインタフェースとしてＨＴＴＰ導管を使用する場合には、引渡しプロトコルは以下のものを指定する。
【００７９】
セッション
セッションは、送信クライアントと引渡しサーバとの間の独特な結合（バインディング）及び一連のトランザクションを識別する。セッションは、送信クライアントが引渡しサーバへデータ転送を開始させるために確立される。セッションを確立するために、送信クライアントは、アカウント及び他の識別情報を引渡しサーバに提示する。もし情報が有効であれば、引渡しサーバはセッションＩＤを送信クライアントへ送る。このセッションＩＤは、爾後の送信クライアントと引渡しサーバとの間の全ての通信におけるセッションを認証し、識別するために使用される。
【００８０】
トランザクション
セッションが確立されると、送信クライアントは引渡しサーバと、所与のファイルを構成している全てのバイナリデータの転送のような１またはそれ以上のトランザクションを開始することができる。
ファイル転送トランザクション
送信クライアントは、開始するトランザクションの型を指定し、またそのトランザクションに特定のパラメタを指定する。ファイル転送トランザクションの場合には、パラメタは、ファイル名、ファイルのサイズ、及びファイルの型を含む。もし指定されたパラメタが有効であれば、引渡しサーバはトランザクションＩＤを送り返す。この時点の後に、送信クライアントは、セッションＩＤ及びトランザクションＩＤを参照して引渡しサーバに各テキストパケットを送る。送信クライアントは、各テキストパケットのサイズに対する参照も含む。引渡しサーバは、引渡されるデータの各パケット毎に成功コードを送り返す。データ転送が成功裏に完了すると、送信クライアントはメッセージを引渡しサーバへ送ってトランザクションを終了させる。もし他のトランザクションが未決でなければ、送信クライアントもセッションを終了させることができる。
【００８１】
開始されたファイル転送トランザクション及び引渡しプロトコルを使用し、送信側コンピュータは爾後のＨＴＴＰ要求に関してＨＴＴＰ導管を介して引渡しサーバにテキストパケットを提出する（ステップ１２３５）。サーバとのファイル転送トランザクションが完了し（１２４０）、引渡しサーバとのセッションが完了する（ステップ１２４５）。引渡しトランザクション及びセッションが完了すると、引渡しサーバはテキストパケットを単一のテキストファイルに再組立てする（ステップ１２５０）。引渡しサーバはテキストファイルを本来のＧＩＦファイルに変換し（ステップ１２５５）、本来のＧＩＦを意図した受信側へ転送する（ステップ１２６０）。本来のＧＩＦは直接、または参照によって（即ち、（例えば）Ｅメールアタッチメント（直接）、またはサーバ上の文書へ送られるＶＲＬ（参照）によって）転送することができる。ファクシミリまたはプリンタへの伝送も、（これらはＥメールアタッチメントではないが）直接転送であると見做される。
【００８２】
図２２は、ファイアォール及び／またはプロキシサーバを横切ってネイティブファイルを転送するのに必要な動作の流れ図の例である。送信クライアントは、ベース ６４ エンコーディングを使用してネイティブファイルをＡＳＣＩＩ（テキスト）に変換する（ステップ１３００）。次に送信クライアントはこのテキスト表現を一連の４Ｋパケットに細分する（ステップ１３０５）。送信クライアントは引渡しサーバとのＨＴＴＰ導管を開き、セッションを確立する（ステップ１３１０）。引渡しサーバは、セッションＩＤを戻すことによって応答する。送信クライアントは引渡しサーバとのＨＴＴＰ導管を開き、セッションＩＤを提示してファイル転送トランザクションを開始する（ステップ１３１５）。引渡しサーバはトランザクションＩＤを戻すことによって応答する。次いで送信クライアントは、引渡しサーバとのＨＴＴＰ導管を開き、セッションＩＤ及びトランザクションＩＤを提示して最初のテキストパケットの転送を開始する（ステップ１３２０）。最初のテキストパッケージを受信すると、引渡しサーバは成功コードを送信クライアントへ戻す。このステップは引渡しサーバが失敗を戻すか、または全てのデータ（全てのテキストパケット）が成功裏に伝送されるまで繰り返される（ステップ１３２５）。
【００８３】
送信クライアントは引渡しサーバとのＨＴＴＰ導管を開き、セッションＩＤ及びトランザクションＩＤを提示してそのトランザクションを終了させる（ステップ１３３０）。もしトランザクションが成功裏に終了すれば、引渡しサーバは成功コードを戻す。送信クライアントは引渡しサーバとのＨＴＴＰ導管を開き、セッションＩＤを提示してセッションを終了させる（ステップ１３３５）。引渡しサーバはテキストパケットを再組立てし、テキストをネイティブの表現に変換し、次いでこのネイティブの表現を受信側に転送する（ステップ１３４０）。当業者ならば、送信クライアントのための、及び引渡しサーバソフトウェアのためのソースコードは、公知のプログラミング技術及びハードウェア構成要素を使用して容易に構成することができる。また、送信クライアント及び引渡しサーバ機能は、集積回路及びＥＥＰＲＯＭのようなプログラマブルメモリデバイスを含む他の手段によって達成することもできる。
【００８４】
本発明の好ましい実施例に関連して上述したバイナリデータファイアウォール引渡し技術の例は、考え得る手法の単なる一例に過ぎない。代替実施例では、本発明の教示と矛盾しない他の手法を使用することができる。本発明は、より低いレベルの表現への降格の決定を遅らせ、それによって将来時点には降格させ得る柔軟性を保存しながら、よりリッチな機能の集合を可能にする技術をも提供する。以下に説明する動的文書変換サーバ（ＤＤＣＳ）はこの概念を利用する。
【００８５】
文書変換
図２３は、本発明によるＤＤＣＳを含むアプリケーション例を示す概要図である。ＤＤＣＳのアーキテクチャを説明するためにある例を考える。ＷｏｒｄＰｅｒｆｅｃｔ文書の送信側４１２が、フォーマットされた文書を受信側に分配することを望んでいるものとする。送信側は、その受信側がどのような能力（デスクトップコンピュータ４１４、ファクシミリ４１６、またはプリンタ４１８かどうかを含む）を所有しているのか、または所有していないのかを知らないものとする。このような場合、送信側は文書を低レベル表現に変換し、その表現を送信することを選択できる。しかしながら、もし受信側がより高いレベル表現を受信できるコンピュータを所有していれば、受信側はカラー、スケーラビリティ、または内容のようなこれらの文書の特色を失うかも知れない。従って早めに文書をより低いレベル表現に変換してしまうと、受信側の柔軟性及び機能を制限することになる。
【００８６】
もし送信側が、文書を変換するＤＤＣＳの能力を利用せずに文書を高レベルのまま、例えば ＷｏｒｄＰｅｒｆｅｃｔ文書のポータブル文書表現を送ってから受信側がプリンタであることが判明すれば、引渡しは失敗する。上述した何れの例も最適の技術を提供していない。即ち、「最良とは、データの初期フォーマット及び受信側の能力に基づく最高のレベル表現である」と定義すれば、上例は受信側に対して最良のデータ表現で分配しない。説明中のＤＤＣＳは、この例において最適の結果を達成する。文書の送信側４１２は、ＤＤＣＳサーバ４１０を介して受信側へデータを送信するので、送信側と受信側との間にあるレベルの間接性が導入される。データは、高レベル表現で送信側からＤＤＣＳへ引渡される。ＤＤＣＳサーバはデータを伝播させ、データを意図した受信側の近傍に到達させる。各ステップにおいて、引渡されるデータ及び次のサーバまたは受信側の能力に基づいて、ＤＤＣＳはデータを高レベル表現からより低いレベル表現へ動的に変換する。最終的に、端末ＤＤＣＳサーバ４２０は（もし必要ならば最終データ変換を行って）文書を受信側に引渡す。
【００８７】
上記 ＷｏｒｄＰｅｒｆｅｃｔ文書の例において、送信側４１２が ＷｏｒｄＰｅｒｆｅｃｔでＭａｃｉｎｔｏｓｈコンピュータを走らせており、受信側がファクシミリであるものとしよう。この場合、送信側は高レベル表現の ＷｏｒｄＰｅｒｆｅｃｔ文書を最初のＤＤＣＳサーバ４１０に送る。文書の ＷｏｒｄＰｅｒｆｅｃｔからＰＤＦのようなポータブルの高レベル表現への変換は、ユーザには透過的である。このような変換は、送信側によって、または例えば Ａｄｏｂｅ Ａｃｒｏｂａｔから提供されるＰＤＦフォーマットのような公知のフォーマットで動作している最初のＤＤＣＳによって遂行させることができる。最初のＤＤＣＳサーバはＰＤＦ文書を受入れ、次いで標準ネットワークプロトコルに基づいて受信側への転送を開始する。この場合、送信側がサンフランシスコに位置し、一方受信側のファクシミリがパリにあるものとしよう。ＤＤＣＳサーバはＰＤＦ文書を、パリに位置する別のＤＤＣＳサーバ４２０へ転送する。この第２のＤＤＣＳサーバは、文書を受信側に転送しようとする。引渡しの点において、第２のＤＤＣＳサーバは、データベースをルックアップするか、または受信側との対話によって、受信側がファクシミリであることを学習する。次いで、パリのＤＤＣＳサーバは、このファクシミリがどのような能力を持っているのかを見出す。この例では、ファクシミリは「グループ４」圧縮イメージを支援するものとする。そこで、パリのＤＤＣＳサーバは、公知の技術を使用してＰＤＦ文書を「グループ４」圧縮イメージに動的に変換する。この場合、「グループ４」圧縮、白黒 ２００×１００ ドット／インチが最良表現であると決定される。
【００８８】
これとは対照的に、受信側は Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｌｏｒ Ｄｅｓｋｊｅｔプリンタ４１８であることをパリのＤＤＣＳサーバ４２０が見出したものとしよう。この場合、パリのＤＤＣＳサーバは、普通の技術を使用して文書をＰＤＦから、より低いレベルのＨＰプリンタ制御言語に変換する。先行例とは異なり、この場合の最良表現は、カラー ３６０×３００ ドット／インチである。更に、受信側はＤＯＳシステムで走るパーソナルコンピュータ４１４を有していることをパリのＤＤＣＳサーバ４２０が見出したものとしよう。この場合、パリのＤＤＣＳサーバは、文書のテクスチャル表現を受信側に送る。受信側は Ａｃｒｏｂａｔアプリケーション（ＰＤＦファイルを読むことができるプログラム）を導入した Ｗｉｎｄｏｗｓオペレーティングシステムで走るパーソナルコンピュータを有していることをパリのＤＤＣＳサーバが見出したものとすれば、サーバは文書のＰＤＦ表現を送る。
【００８９】
図２４に、本発明による動的文書変換サーバＤＤＣＳを含むアプリケーションの別の例を示す。この場合、送信側４２２は Ｑｕａｒｋ Ｅｘｐｒｅｓｓ文書を送ることを望んでいる。上述したものと同一のプロセスがここでも遂行され、それによって文書は高レベル表現（この場合には Ｅｎｖｏｙ）に透明的に変換され、最初のＤＤＣＳサーバ４２６に引渡される。ＤＤＣＳサーバはこの文書を、意図した受信側４２４に直接引渡し、この文書を別のサーバに送ることはしない。ＤＤＣＳサーバは、受信側への引渡しを開始する時に、受信側が文書フォーマットを読むことができる Ｅｎｖｏｙアプリケーションを所有していないが、その代わりに文書のＧＩＦビットマップを読むことができる Ｗｅｂブラウザを有していることを見出したものとする。この場合、ＤＤＣＳサーバは高レベル Ｅｎｖｏｙ表現をより低いレベルのＧＩＦ表現に動的に変換し、ＧＩＦを受信側に引渡す。
【００９０】
図２５は、本発明による動的データ変換サーバの現在では好ましい例の概要図である。ＤＤＣＳの好ましい実施例の設計は、図２４の例と全く同一である。本発明のこの実施例では、送信側４２２は、その装置上で走る送信クライアント４３１を有している。本発明のアーキテクチャは、例えば文書のようなデータ４３２が高レベル表現であり、従ってデータはある形状のコンピュータ上で作成されるものと仮定している。データが例えば ｐａｐｅｒのような低レベル表現で開始できるような場合でも（もし送信コンピュータがこの表現を、例えば光学文字認識技術４４３を使用して高レベル表現に変換することができれば）、このアーキテクチャを適用することができる。送信クライアント４３１は、典型的には、先ずデータをより柔軟ではあるが、それでも高レベルの表現に変換する。これは、高レベルのフォーマットのままで分配及び変換を意図するのではなく、編集の目的からである。このようにＤＤＣＳサーバは、ポータブル文書及びＨＴＭＬのようなＳＧＭＬ派生文書を含む分配可能なデータ表現により適している。本発明の一つの好ましい実施例では、送信クライアントは、データを高レベルの表現から高レベルのポータブル表現に変換する。議論の余地があるところではあるが、このような変換は、このデータ変換によってある情報が失われ、それ程高いレベルではなくなる第１の場合を表している。典型的には、この目的のために送信側は、濾波技術または仮想プリンタドライバを使用する。本発明では送信側（クライアント）レベルにおける変換を必要とせず、本発明の他の実施例ではデータがＤＤＣＳサーバへ引渡されるまで変換を遅らせることができる。従って、本発明の１つの新らしい特色は、データをより低いレベルの表現に変換する決定を遅らせ、それによって最大の柔軟性を保存することから導かれる。
【００９１】
どのような形状であっても、高レベル表現は、例えばＨＴＴＰを介して送信側のコンピュータからＤＤＣＳサーバ４２６へ伝送される。サーバは、意図した受信側４２４へ文書を引渡すように動作する。使用される特定の引渡しメカニズムは、例えばＥメール、ＨＴＴＰ引渡しを用いたＥメール通知（ １９９６ 年１０月２４日付 Ｊ． Ｓｍｉｔｈ 、Ｊ． Ｃ． Ｂａｎｄｉｎｉ の米国特許出願第 ０８／７３８，９６６ 号 ”Ｅｌｅｃｔｒｏｎｉｃ Ｄｏｃｕｍｅｎｔ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍ” 参照）、直接ＴＣＰ／ＩＰ、またはファクシミリを含むことができる。サーバが引渡しを開始する時、引渡すデータをより低いレベルの表現に変換するのか否かを決定するために、サーバはＤＤＣＳ設備４４４を使用する。サーバは、表現間の考え得るマッピングを容易にするために、一連のマッピングテーブル４３５、４３６を維持している。テーブル４３５の例は、所与のデータ表現からの考え得るマッピングを含む。
【００９２】
表１は、所与のデータ表現からの考え得るマッピングの例を示している。
【００９３】
【００９４】
表２は、特定の能力を与えられた考え得るデータ表現の例である。
【００９５】
【００９６】
引渡されるデータに関する情報を引き出す主な技術は、情報をピックアプするために（４３９）、または情報を送るために（４３８）そのサーバを使用したことがある特定ユーザの能力のデータベース４３７を、そのサーバ内に維持しておくことを伴う。例えば、もし特定の受信側に文書を送るために、情報の送信側がサーバに ＭＳＷｏｒｄ文書を引渡したものとすれば、サーバはその送信側が ＭＳ Ｗｏｒｄ文書を受信でき、または同様に、Ｅｎｖｏｙ またはＰＤＦ文書も受信できることを知る。サーバはこのような情報をこの能力データベース４３７内に保持する。例えば引渡しメカニズムがＥメール及びＨＴＴＰ引渡しを使用し、ユーザがサーバから文書をピックアップする場合、ＨＴＴＰプロトコルはプラットフォーム及びインターネットＷｅｂブラウザの型及びバージョンに関する受信側の能力を記述する。この情報はこの時点に使用することができるが、例えばＨＴＴＰ引渡しを含まない引渡しに対する将来参照のために、能力データベース内に記録しておくこともできる。
【００９７】
サーバは、引渡しメカニズムの型及び受信側を記述するのに使用したアドレスに基づいて受信側の能力を推論する推論エンジン４４０をも使用する。例えば電話番号アドレスは、受信側がファクシミリを使用していることを暗示している。サーバは、ファクシミリに問合わせ、そのファクシミリが例えばグループ４を支援するのか、またはグループ３を支援するのかを決定し、相応してフォーマットを更新することができる。サーバは、ミシガン大学が開発したインターネット・ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）標準をインターネット・エンジニアリング・タスク・フォースと共に動的に使用し、受信側の能力を問合わせるためのＬＤＡＰ問合わせエンジン４４１を使用することもできる。ＬＤＡＰサーバ４４２は、ディレクトリ及び他のサービスを提供する。ＤＤＣＳサーバは、特定の引渡しに関する能力情報を、ＬＤＡＰサーバに実時間で問合わせる。
【００９８】
データフォーマットが決定され、受信側能力が識別されると、サーバはマッピングテーブルを使用してデータ変換が必要乃至は適切であるか否かを決定する。多くの場合、この決定にはマッピングテーブルをルックアップする以上のものが必要になる。例えば、最良データ表現を見出すためには多重マッピングが必要であることが多い。これらの変換は、変換エンジン４３４によって遂行される。実際のデータ変換プロセスは本発明の範囲外であり、コンピュータソフトウェア産業において広く使用可能である。例えば、Ａｄｏｂｅ Ｓｙｓｔｅｍｓ が最初のバージョンとして Ａｃｒｏｂａｔを出荷した時から、ＰＤＦ文書をどのようにして Ｐｏｓｔｓｃｒｉｐｔ文書に変換するかは知られている。もし ＡｃｒｏｂａｔビューワがＤＤＣＳサーバ上で走っていれば、そのビューワは、（もし必要ならば）特定の型のプリンタに対してある文書を印刷するように指令される。従って、結局は、実際のデータ変換自体は本発明に直接関連するものではなく、選択の問題なのである。
【００９９】
以上に本発明を特定の好ましい実施例に関して説明したが、当業者ならば特許請求の範囲から逸脱することなく種々の変更及び強調を考案できよう。
【図面の簡単な説明】
【図１】１つのバイナリファイルサーバを使用するバイナリファイル引渡しシステムのブロック線図である。
【図２】２つのバイナリファイルサーバを使用するバイナリファイル引渡しシステムのブロック線図である。
【図３】ストアアイテムのキー要素を示すブロック線図である。
【図４】バイナリファイル引渡しサーバを示す概要ブロック線図である。
【図５】バイナリファイルサーバの１実施例のアーキテクチャの例を示す図である。
【図６】バイナリファイル引渡しサーバが使用する異なる型のストアイベントを示す図である。
【図７】バイナリファイル引渡しサーバアーキテクチャ内の特定構成要素のブロック線図である。
【図８】ストアのアーキテクチャを示すブロック線図である。
【図９】ユーザセッションがインターネットクライアントをどのようにしてセッション、トランザクション、及び移送を含む３つの層に編成するかを示す図である。
【図１０】送信側セッションがストアアイテムを作成するか、または別のサーバがストアアイテムを送信した時の引渡しの非繰り返しタスクを示す図である。
【図１１】アカウント管理者アーキテクチャの詳細図である。
【図１２】ロガーアーキテクチャの詳細図である。
【図１３】サーバコネクタアーキテクチャの詳細図である。
【図１４】１つのポータブル文書引渡しサーバを使用するポータブル文書引渡しシステムを示す機能的ブロック線図である。
【図１５】２つのポータブル文書引渡しサーバを使用するポータブル文書引渡しシステムを示す機能的ブロック線図である。
【図１６】ポータブル文書送信クライアントアプリケーション及びポータブル文書受信クライアントアプリケーションがどのように本発明に使用されているかを示す図である。
【図１７】サーバ構成ユーザインタフェースアプリケーションがどのように本発明に使用されているかを示す図である。
【図１８】サーバのファックスゲートウェイによってどのように文書をプリンタへ送ることができるかを示す図である。
【図１９】ＬＡＮを通し、会社専用のサーバの部課ゲートウェイによってどのように文書を部課プリンタへ送ることができるかを示す図である。
【図２０】本発明によりファイアウォール及び／またはプロキシサーバを横切ってデータを伝送するシステムの概要図である。
【図２１】本発明によりファイアウォール及び／またはプロキシサーバを横切ってデータを伝送するアルゴリズムを示す流れ図の例である。
【図２２】本発明によりファイアウォール及び／またはプロキシサーバを横切ってネイティブファイルを転送するのに必要な動作の集合の流れ図の例である。
【図２３】本発明による動的文書変換サーバを含むアプリケーションの例を示す概要図である。
【図２４】本発明による動的文書変換サーバを含むアプリケーションの別の例を示す概要図である。
【図２５】本発明による動的文書変換サーバの現在では好ましい実施例を示す概要図である。
【符号の説明】
１０ バイナリファイル引渡しシステム
１２ バイナリファイルサーバ
１６ 送信側コンピュータ（送信側またはユーザ）
２２ 受信側コンピュータ（受信側）
３４ バイナリファイルの木
３６ 記述子
４２ ストア
４４ ストアクライアント
４６ アカウント管理者
４８ ストアアイテム
５２ インターネット送信側
５４ インターネット受信側
５６ ファックスゲートウェイ
５８ フォワーダ
６０ アーカイバ
６２ フォーマット翻訳者
６４ Ｗｅｂ 発表者
６６ ピックアップ通知者
６８ 作成イベント
６９ 削除イベント
７０ 変更イベント
７２ ユーザセッション
７４ 引渡し構成要素
７６ コンソール
７８ アカウント管理者
８０ サーバコネクタ
８２ ＯＳアクセッサ
８４ メールゲートウェイ
８６ ロガー
８８ サーバアプリケーション
９２ ストア管理者
９４ ストアアイテム管理者
９６ ストアイベント管理者
１０２ セッション管理者
１０４ ＢＦＤセッション管理者
１０６ ＨＴＭＬセッション管理者
１０８ トランザクション管理者
１１０ ＢＦＤトランザクションインタプリタ
１１２ ＨＴＭＬトランザクションインタプリタ
１１４、１１８ 移送管理者
１２０ 非対話式タスク
１２２ 引渡し管理者
１２４ サーバディレクトリ
１３０ アカウント管理者
１３２ ユーザ（ローカル）アカウント状態
１３４ 請求アカウント状態
１３６ 遠隔アカウントディレクトリ
１６０ ポータブル文書引渡しシステム
１６４ 送信側デスクトップ
１６６ 文書
１７０ 受信側デスクトップ
１７２ ファクシミリ
１７８ プリンタ
１９０ デスクトップアプリケーション
１９２ ポータブル文書送信クライアント
１９４ ポータブル文書受信クライアント
１９８ サーバ構成ユーザインタフェース
２００ 会社ＢＦＤサーバ
２０２ 部課ゲートウェイ
２０４ ＬＡＮ
３１０ データ伝送システム
３１４ 送信側コンピュータ
３１８ ファイアウォール／プロキシサーバ
３２０ インターネットサーバ
３２２ 受信側コンピュータ
４１０、４２６ 動的データ変換サーバ（ＤＤＣＳ）
４１２、４２２ 送信側
４１４ デスクトップコンピュータ
４１６ ファクシミリ
４１８ プリンタ
４２０ 端末ＤＤＣＳサーバ
４２４ 受信側
４３１ 送信クライアント
４３２ データ
４３４ 変換エンジン
４３５、４３６ マッピングテーブル
４３７ データベース
４３８ 送信側
４３９ 受信側
４４０ 推論エンジン
４４１ ＬＤＡＰ問合わせエンジン
４４２ ＬＤＡＰサーバ
４４３ 光学文字認識技術
４４４ ＤＤＣＳ設備
Claims (57)
- 電子文書を電子ネットワークを介して動的に引渡す方法であって、電子文書の高レベル表現を、動的文書変換サーバを介して受信側へ送る段階と、より低いレベル表現への降格の決定を遅延させる段階と、上記文書を再生する上記受信側の能力に基づいて上記文書にとって最も適切なレベルの表現を決定する段階と、上記文書を、上記文書を再生する上記受信側の能力にとって適切で且つ必要なより低いレベルの表現へ変換する段階と、上記受信側への上記文書の引渡しを完了させる段階と、を備えていることを特徴とする方法。
- 上記文書を送る前に、上記文書を上記文書のポータブル文書表現に変換する段階、を更に備えている請求項１に記載の方法。
- 上記文書は、高いレベルの表現で送信側から上記サーバへ引渡される請求項２に記載の方法。
- 上記サーバは上記文書を上記ネットワークを介して伝播させ、それによって上記文書を意図した受信側により近づけるようになっている請求項１に記載の方法。
- 引渡される文書、及び上記文書を再生する次のサーバまたは上記受信側の能力に基づいて、上記文書を高レベルの表現からより低いレベルの表現に動的に変換する段階、を更に備えている請求項４に記載の方法。
- 第２のサーバが、次いで上記文書を上記受信側へ転送することを企図する請求項１に記載の方法。
- 上記文書を再生する上記受信側の能力を識別するために、データベースのルックアップまたは上記受信側との対話を遂行する段階、を更に備えている請求項６に記載の方法。
- 上記文書は最初のサーバへ引渡され、次いで上記サーバは上記文書を意図した受信側へ直接引渡すようになっている請求項１に記載の方法。
- 上記サーバは高レベル文書表現をより低いレベルの文書表現に動的に変換し、次いで上記より低いレベルの文書表現を上記受信側へ引渡すようになっている請求項８に記載の方法。
- 上記文書の送信側は、送信クライアントを更に備えている請求項１に記載の方法。
- 上記送信クライアントは、上記文書を先ずポータブル表現に変換する請求項１０に記載の方法。
- 引渡される上記文書をより低いレベルの表現に変換するのか否かを決定するためにサーバ設備を使用する段階、を更に備えている請求項１に記載の方法。
- 表現間の潜在的なマッピングを容易にするために一連のマッピングテーブルを維持する段階、を更に備えている請求項１２に記載の方法。
- 所与のデータ表現からの考え得るマッピングを含むテーブルを準備する段階、を更に備えている請求項１３に記載の方法。
- 特定の能力が与えられた考え得るデータ表現を含むテーブルを準備する段階、を更に備えている請求項１３に記載の方法。
- 引渡される上記文書フォーマットに関する情報を導出する段階、を更に備えている請求項１に記載の方法。
- 文書をピックアップするか、または文書を送るために上記サーバを使用したことがある特定ユーザについて、上記サーバ内に能力のデータベースを維持する段階、を更に備えている請求項１６に記載の方法。
- 受信側の能力を推論するための推論エンジンを準備する段階、を更に備えている請求項１に記載の方法。
- 上記推論は、引渡しメカニズムの型、及び上記受信側を記述するのに使用されたアドレスの何れか、または両方に基づいている請求項１８に記載の方法。
- インターネットライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）標準を使用して受信側の能力を動的に問合わせるためにＬＤＡＰ問合わせエンジンを準備する段階、を更に備えている請求項１に記載の方法。
- データフォーマットを決定する段階と、受信側の能力を識別する段階と、少なくとも１つのマッピングテーブルを使用し、データ変換が必要または適切であるか否かを結論づける段階と、を更に備えている請求項１に記載の方法。
- 電子文書の高レベルの表現を受信側へ送る送信側を備えている電子ネットワークを介して電子文書を動的に引渡す装置であって、上記文書を上記受信側へ転送するための動的文書変換サーバ、を備え、上記サーバは更に、上記文書を再生する上記受信側の能力に基づいて上記文書にとって最も適したレベルの表現を決定する機能と、上記文書を、上記文書を再生する上記受信側の能力にとって適切且つ必要なより低いレベルの表現に変換する変換エンジンと、を備え、上記サーバは、適切なより低いレベルの表現への降格の決定を遅延させるようになっている、ことを特徴とする装置。
- 上記文書を送る前に、上記文書を上記文書のポータブル文書表現に変換する送信クライアント、を更に備えている請求項２２に記載の装置。
- 上記文書は、高レベルの表現で送信側から上記サーバへ引渡される請求項２２に記載の装置。
- 上記サーバは上記文書を上記ネットワークを介して伝播させ、それによって上記文書を意図した受信側により近づけるようになっている請求項２２に記載の装置。
- 引渡される文書、及び上記文書を再生する次のサーバまたは上記受信側の能力に基づいて、上記文書を高レベルの表現からより低いレベルの表現に動的に変換する変換エンジン、を更に備えている請求項２５に記載の装置。
- 上記文書を上記受信側へ転送する第２のサーバ、を更に備えている請求項２２に記載の装置。
- 上記文書を再生する上記受信側の能力を識別するために、データベースのルックアップまたは上記受信側との対話を遂行する推論エンジン、を更に備えている請求項２７に記載の装置。
- 上記文書は最初のサーバへ引渡され、次いで上記サーバは上記文書を意図した受信側へ直接引渡すようになっている請求項２２に記載の装置。
- 上記サーバは高レベル文書表現をより低いレベルの文書表現に動的に変換し、次いで上記より低いレベルの文書表現を上記受信側へ引渡すようになっている請求項２９に記載の装置。
- 上記文書の送信側は、送信クライアントを更に備えている請求項２２に記載の装置。
- 上記送信クライアントは、上記文書を先ずポータブル表現に変換する請求項３０に記載の装置。
- 引渡される上記文書をより低いレベルの表現に変換するのか否かを決定するためのサーバ設備、を更に備えている請求項２２に記載の装置。
- 表現間の潜在的なマッピングを容易にするために少なくとも一連のマッピングテーブル、を更に備えている請求項３３に記載の装置。
- 所与のデータ表現からの考え得るマッピングを含むテーブル、を更に備えている請求項３４に記載の装置。
- 特定の能力が与えられた考え得るデータ表現を含むテーブル、を更に備えている請求項３４に記載の装置。
- 引渡される上記文書フォーマットに関する情報を導出するユーザデータベース、を更に備えている請求項２２に記載の装置。
- 文書をピックアップするか、または文書を送るために上記サーバを使用したことがある特定ユーザの能力のデータベース、を更に備えている請求項３７に記載の装置。
- 受信側の能力を推論する推論エンジン、を更に備えている請求項２２に記載の装置。
- 上記推論は、引渡しメカニズムの型、及び上記受信側を記述するのに使用されたアドレスの何れか、または両方に基づいている請求項３４に記載の装置。
- インターネットライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）標準を使用して受信側の能力を動的に問合わせるＬＤＡＰ問合わせエンジン、を更に備えている請求項２２に記載の装置。
- データフォーマットを決定するマッピングテーブルと、受信側の能力を識別するマッピングテーブルと、を更に備え、少なくとも１つの上記マッピングテーブルを使用して、データ変換が必要であるかまたは適切であるかを結論づけるようになっている請求項２２に記載の装置。
- イントラネットから、少なくとも１つのファイアウォールまたはプロキシサーバを通してバイナリデータを引渡す方法であって、送信側コンピュータにおいて上記バイナリデータをテキストに変換する段階と、単方向性通信を支援する非阻止プロトコルを使用し、電子ネットワーク上に存在するファイアウォールまたはプロキシサーバを横切って上記テキストをプッシュする段階と、上記サーバにおいて上記テキストを再組立てし、上記テキストを上記バイナリデータに変換する段階と、上記バイナリデータを上記サーバから上記電子ネットワーク上の受信側へ送る段階と、を備えていることを特徴とする方法。
- 上記電子ネットワークは、インターネットである請求項４３に記載の方法。
- 上記送信側コンピュータは、ベース ６４ ＡＳＣＩＩエンコーディングを使用して上記バイナリデータをテキストに変換する請求項４３に記載の方法。
- 上記テキストを、テキストパケットに細分する段階を更に備えている請求項４３に記載の方法。
- 上記サーバは、上記イントラネットの一部分である請求項４３に記載の方法。
- 上記サーバは、上記イントラネット上の専用サーバである請求項４３に記載の方法。
- 上記送信側コンピュータは、デスクトップコンピュータまたはサーバコンピュータの何れかである請求項４３に記載の方法。
- 上記プロトコルは、ＨＴＴＰである請求項４３に記載の方法。
- 上記受信側は、コンピュータ、ファクシミリ、プリンタ、またはパーソナルディジタル支援装置の１つである請求項４３に記載の方法。
- イントラネット上に存在する送信側コンピュータから、少なくとも１つのファイアウォールまたはプロキシサーバを通してバイナリデータを引渡す方法であって、上記送信側コンピュータが、ＨＴＴＰを使用してインターネットにアクセスする段階と、上記送信側コンピュータが、上記インターネット上に存在していて上記送信側コンピュータからデータを受信するように構成されている引渡しサーバのアドレスを識別する段階と、上記送信側コンピュータが、上記引渡しサーバのための何等かの引渡しプロトコルを識別する段階と、上記送信側コンピュータが、上記バイナリデータをテキストデータに変換する段階と、上記送信側コンピュータが、上記テキストデータをテキストパケットに細分する段階と、上記送信側コンピュータが、上記インターネットにアクセスして上記送信側コンピュータと上記引渡しサーバとの間にセッションを開始する段階と、上記送信側コンピュータが、上記引渡しサーバとデータ転送トランザクションを開始する段階と、上記送信側コンピュータが、上記テキストパケットを上記引渡しサーバへ提出する段階と、上記送信側コンピュータが、上記引渡しサーバとの上記データ転送トランザクションを終了させる段階と、上記送信側コンピュータが、上記引渡しサーバとの上記セッションを終了させる段階と、を備えていることを特徴とする方法。
- 上記引渡しサーバが、上記テキストパケットを単一のテキストファイルに再組立てする段階と、上記引渡しサーバが、上記単一のテキストファイルを元のバイナリデータに変換する段階と、上記引渡しサーバが、上記バイナリデータを上記インターネットを介して受信側へ転送する段階と、を更に備えている請求項５２に記載の方法。
- 上記送信側コンピュータは、ベース ６４ ＡＳＣＩＩエンコーディングを使用して上記バイナリデータをテキストに変換する請求項５２に記載の方法。
- 少なくとも１つのファイアウォールまたはプロキシサーバを通してイントラネットからバイナリデータを引渡すシステムであって、上記バイナリデータをテキストデータに変換し、ＨＴＴＰを使用して上記テキストデータをファイアウォールまたはプロキシサーバを横切って電子ネットワークへ送るコンピュータと、上記テキストデータを受信し、再組立てし、そして上記バイナリデータに変換して上記電子ネットワーク上の受信側に引渡す手段と、を備えていることを特徴とするシステム。
- 上記テキストデータを受信し、再組立てし、そして上記バイナリデータに変換する上記手段は、上記電子ネットワーク上に存在するサーバである請求項５５に記載のシステム。
- 上記テキストデータを受信し、再組立てし、そして上記バイナリデータに変換する上記手段は、上記イントラネット上に存在するコンピュータである請求項５５に記載のシステム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/738,966 US5790790A (en) | 1996-10-24 | 1996-10-24 | Electronic document delivery system in which notification of said electronic document is sent to a recipient thereof |
| US08/792,171 US6119137A (en) | 1997-01-30 | 1997-01-30 | Distributed dynamic document conversion server |
| US08/800,864 US6502191B1 (en) | 1997-02-14 | 1997-02-14 | Method and system for binary data firewall delivery |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP9291270A Division JPH10154110A (ja) | 1996-10-24 | 1997-10-23 | 電子文書引渡しシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004005404A true JP2004005404A (ja) | 2004-01-08 |
| JP2004005404A5 JP2004005404A5 (ja) | 2005-03-10 |
Family
ID=27419243
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP9291270A Pending JPH10154110A (ja) | 1996-10-24 | 1997-10-23 | 電子文書引渡しシステム |
| JP2003012564A Pending JP2004005404A (ja) | 1996-10-24 | 2003-01-21 | 電子文書をネットワークを介して動的に引渡すシステム |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP9291270A Pending JPH10154110A (ja) | 1996-10-24 | 1997-10-23 | 電子文書引渡しシステム |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP0838774A3 (ja) |
| JP (2) | JPH10154110A (ja) |
| TW (1) | TW400487B (ja) |
Families Citing this family (89)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060195595A1 (en) | 2003-12-19 | 2006-08-31 | Mendez Daniel J | System and method for globally and securely accessing unified information in a computer network |
| JP3774547B2 (ja) * | 1997-07-25 | 2006-05-17 | キヤノン株式会社 | 通信装置 |
| EP0907120A3 (en) * | 1997-10-02 | 2004-03-24 | Tumbleweed Software Corporation | Method amd apparatus for delivering documents over an electronic network |
| US6157924A (en) * | 1997-11-07 | 2000-12-05 | Bell & Howell Mail Processing Systems Company | Systems, methods, and computer program products for delivering information in a preferred medium |
| US6343327B2 (en) | 1997-11-12 | 2002-01-29 | Pitney Bowes Inc. | System and method for electronic and physical mass mailing |
| EP0917076A3 (en) * | 1997-11-12 | 1999-06-09 | Pitney Bowes Inc. | System and method for electronic mass mailing |
| US6353824B1 (en) * | 1997-11-18 | 2002-03-05 | Apple Computer, Inc. | Method for dynamic presentation of the contents topically rich capsule overviews corresponding to the plurality of documents, resolving co-referentiality in document segments |
| US6529908B1 (en) * | 1998-05-28 | 2003-03-04 | Netspan Corporation | Web-updated database with record distribution by email |
| US8516055B2 (en) | 1998-05-29 | 2013-08-20 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device in a wireless data network |
| US6463463B1 (en) | 1998-05-29 | 2002-10-08 | Research In Motion Limited | System and method for pushing calendar event messages from a host system to a mobile data communication device |
| US6219694B1 (en) | 1998-05-29 | 2001-04-17 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device having a shared electronic address |
| US6779019B1 (en) | 1998-05-29 | 2004-08-17 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device |
| US6438585B2 (en) * | 1998-05-29 | 2002-08-20 | Research In Motion Limited | System and method for redirecting message attachments between a host system and a mobile data communication device |
| US7209949B2 (en) | 1998-05-29 | 2007-04-24 | Research In Motion Limited | System and method for synchronizing information between a host system and a mobile data communication device |
| US6289461B1 (en) * | 1998-06-09 | 2001-09-11 | Placeware, Inc. | Bi-directional process-to-process byte stream protocol |
| JP2000057072A (ja) * | 1998-08-04 | 2000-02-25 | Mitsubishi Electric Corp | データ転送方式 |
| JP2000076218A (ja) * | 1998-08-27 | 2000-03-14 | Ntt Data Corp | データベース間の同期化システム |
| JP4250266B2 (ja) * | 1998-08-28 | 2009-04-08 | キヤノン株式会社 | 周辺機器及び周辺機器制御方法及び周辺機器制御システム及び周辺機器制御プログラムを記憶した記憶媒体及び周辺機器制御プログラムを送出する送出装置及び周辺機器制御プログラム製品 |
| JP3416552B2 (ja) * | 1999-01-25 | 2003-06-16 | パナソニック コミュニケーションズ株式会社 | ネットワークサーバ装置、および通信端末能力交換方法 |
| GB2347053A (en) * | 1999-02-17 | 2000-08-23 | Argo Interactive Limited | Proxy server filters unwanted email |
| EP1208462A2 (en) * | 1999-02-26 | 2002-05-29 | Atabok, Inc. | Method and apparatus for delivering electronic data through a proxy server |
| AU3607100A (en) * | 1999-02-26 | 2000-09-14 | Click2Send.Com, Inc. | Method and apparatus for network file transfer |
| EP1410546A4 (en) * | 1999-04-24 | 2005-04-27 | Hijk | METHOD FOR IMPROVING THE PRINT QUALITY OF A DOCUMENT PRODUCED USING NETWORK TYPE NETWORK APPLICATIONS |
| AU1180000A (en) * | 1999-04-26 | 2000-11-10 | Outserv Co., Ltd. | E-mail system, e-mail transmission/reception system, and recording medium |
| US6684248B1 (en) | 1999-05-03 | 2004-01-27 | Certifiedmail.Com, Inc. | Method of transferring data from a sender to a recipient during which a unique account for the recipient is automatically created if the account does not previously exist |
| GB2350269B (en) * | 1999-05-20 | 2003-10-22 | Virtual Access Ireland Ltd | An interface apparatus and method |
| JP2001007843A (ja) * | 1999-06-24 | 2001-01-12 | Hitachi Ltd | 電子発送システム |
| US6895557B1 (en) | 1999-07-21 | 2005-05-17 | Ipix Corporation | Web-based media submission tool |
| JP2001053785A (ja) * | 1999-08-09 | 2001-02-23 | Mitsubishi Materials Corp | 情報送信装置、情報保管装置、情報受信装置、及びその使用方法ならびにその記録媒体 |
| US6732162B1 (en) | 1999-11-15 | 2004-05-04 | Internet Pictures Corporation | Method of providing preprocessed images for a plurality of internet web sites |
| JP2001155007A (ja) * | 1999-12-01 | 2001-06-08 | Ntt Comware Corp | データベースの同期システム、データ送受信システム及び電子閲覧システム |
| US20020049852A1 (en) * | 1999-12-06 | 2002-04-25 | Yen-Jen Lee | Global messaging with distributed adaptive streaming control |
| EP1132808A1 (en) * | 2000-01-04 | 2001-09-12 | Océ-Technologies B.V. | Method and system for submitting jobs to a reproduction center |
| WO2001060021A2 (en) * | 2000-02-08 | 2001-08-16 | Internet-Extra Ltd. | Internet content download |
| SG99886A1 (en) * | 2000-02-24 | 2003-11-27 | Ibm | System and method for collaborative multi-device web browsing |
| JP3793941B2 (ja) | 2000-02-24 | 2006-07-05 | 株式会社日立製作所 | 映像配送システムにおけるビデオサーバ装置およびその映像配送方法。 |
| AU2000237175A1 (en) * | 2000-03-02 | 2001-09-12 | Hughes Electronics Corporation | A technique for data compression by decoding binary encoded data |
| JP2001256097A (ja) | 2000-03-14 | 2001-09-21 | Matsushita Electric Ind Co Ltd | ファイルの自動送信システム |
| US7231134B2 (en) | 2000-03-14 | 2007-06-12 | Matsushita Electric Industrial Co., Ltd. | Image and audio reproducing apparatus and method |
| WO2001095085A1 (fr) * | 2000-06-09 | 2001-12-13 | Kobayashi Kirokushi Co., Ltd. | Procede et systeme de commande d'impression et dispositif de connexion specialise |
| US8972717B2 (en) | 2000-06-15 | 2015-03-03 | Zixcorp Systems, Inc. | Automatic delivery selection for electronic content |
| US6732101B1 (en) * | 2000-06-15 | 2004-05-04 | Zix Corporation | Secure message forwarding system detecting user's preferences including security preferences |
| US8447967B1 (en) | 2000-06-29 | 2013-05-21 | Datamotion, Inc. | Controlled message distribution |
| US7251695B2 (en) | 2000-08-17 | 2007-07-31 | Aspen Technology, Inc. | Computer network communication method and apparatus |
| FR2814019B1 (fr) * | 2000-09-12 | 2005-04-15 | Canon Kk | Determination des caracteristiques d'un terminal client lors d'un echange de donnees entre le terminal et un serveur |
| EP1191752A1 (de) * | 2000-09-26 | 2002-03-27 | Daniel Gens | Verfahren und Vorrichtung zum Austausch von Informationen |
| JP3849640B2 (ja) | 2000-10-26 | 2006-11-22 | 松下電器産業株式会社 | 印刷画像指定装置 |
| US7636757B2 (en) | 2000-12-15 | 2009-12-22 | Canon Kabushiki Kaisha | Printing over the internet |
| WO2002052798A2 (en) | 2000-12-22 | 2002-07-04 | Research In Motion Limited | Wireless router system and method |
| US7283808B2 (en) | 2001-01-18 | 2007-10-16 | Research In Motion Limited | System, method and mobile device for remote control of a voice mail system |
| PT1356372E (pt) | 2001-01-29 | 2011-11-09 | ThinPrint AG | Método para o processamento de trabalhos de impressão em redes com base em servidores, e rede com base em servidores correspondente |
| JP2002251359A (ja) * | 2001-02-21 | 2002-09-06 | Mitsubishi Electric Corp | 通信ネットワークシステム |
| GB0107760D0 (en) * | 2001-03-28 | 2001-05-16 | British Telecomm | A method and a system of remotely controlling data transfer via a data transfer network |
| US7039643B2 (en) * | 2001-04-10 | 2006-05-02 | Adobe Systems Incorporated | System, method and apparatus for converting and integrating media files |
| JP2003122713A (ja) * | 2001-10-11 | 2003-04-25 | Sony Corp | 情報処理装置およびプログラム |
| CA2410118C (en) | 2001-10-26 | 2007-12-18 | Research In Motion Limited | System and method for controlling configuration settings for mobile communication devices and services |
| DE60214590T2 (de) | 2001-12-07 | 2007-09-13 | Research In Motion Ltd., Waterloo | Verfahren und vorrichtung zur steuerung der informationsverteilung zu mobilstationen |
| US20030135618A1 (en) * | 2002-01-17 | 2003-07-17 | Ravikumar Pisupati | Computer network for providing services and a method of providing services with a computer network |
| US7124438B2 (en) | 2002-03-08 | 2006-10-17 | Ciphertrust, Inc. | Systems and methods for anomaly detection in patterns of monitored communications |
| US8132250B2 (en) | 2002-03-08 | 2012-03-06 | Mcafee, Inc. | Message profiling systems and methods |
| US8578480B2 (en) | 2002-03-08 | 2013-11-05 | Mcafee, Inc. | Systems and methods for identifying potentially malicious messages |
| US7870203B2 (en) | 2002-03-08 | 2011-01-11 | Mcafee, Inc. | Methods and systems for exposing messaging reputation to an end user |
| US7903549B2 (en) | 2002-03-08 | 2011-03-08 | Secure Computing Corporation | Content-based policy compliance systems and methods |
| US7096498B2 (en) | 2002-03-08 | 2006-08-22 | Cipher Trust, Inc. | Systems and methods for message threat management |
| US7693947B2 (en) | 2002-03-08 | 2010-04-06 | Mcafee, Inc. | Systems and methods for graphically displaying messaging traffic |
| US7694128B2 (en) | 2002-03-08 | 2010-04-06 | Mcafee, Inc. | Systems and methods for secure communication delivery |
| US8561167B2 (en) | 2002-03-08 | 2013-10-15 | Mcafee, Inc. | Web reputation scoring |
| JP3782981B2 (ja) * | 2002-04-26 | 2006-06-07 | インターナショナル・ビジネス・マシーンズ・コーポレーション | セッション中継システム、クライアント端末、セッション中継方法、リモートアクセス方法、セッション中継プログラム及びクライアントプログラム |
| CA2414154A1 (en) * | 2002-12-12 | 2004-06-12 | Mark W. Brooks | System and method for transmitting a file associated with an e-mail |
| JP2005174109A (ja) | 2003-12-12 | 2005-06-30 | Sharp Corp | データ変換装置、データ変換方法、コンピュータをデータ変換装置として機能させるためのプログラム、およびそのプログラムを格納した記録媒体 |
| GB0416857D0 (en) * | 2004-07-29 | 2004-09-01 | Ingenico Uk Ltd | Electronic financial transactions |
| US8635690B2 (en) | 2004-11-05 | 2014-01-21 | Mcafee, Inc. | Reputation based message processing |
| EP1872251B1 (en) | 2005-04-18 | 2015-10-21 | BlackBerry Limited | Method for providing wireless application privilege management |
| US7937480B2 (en) | 2005-06-02 | 2011-05-03 | Mcafee, Inc. | Aggregation of reputation data |
| US8179798B2 (en) | 2007-01-24 | 2012-05-15 | Mcafee, Inc. | Reputation based connection throttling |
| US7949716B2 (en) | 2007-01-24 | 2011-05-24 | Mcafee, Inc. | Correlation and analysis of entity attributes |
| US7779156B2 (en) | 2007-01-24 | 2010-08-17 | Mcafee, Inc. | Reputation based load balancing |
| US8763114B2 (en) | 2007-01-24 | 2014-06-24 | Mcafee, Inc. | Detecting image spam |
| US8214497B2 (en) | 2007-01-24 | 2012-07-03 | Mcafee, Inc. | Multi-dimensional reputation scoring |
| US8745486B2 (en) | 2007-01-25 | 2014-06-03 | Microsoft Corporation | Streamable interactive rendering-independent page layout |
| EP1970800A1 (de) | 2007-03-15 | 2008-09-17 | Brandgroup GmbH | Verfahren zur Erzeugung von Steuerungsdaten für die Herstellung eines Produkts |
| US8179872B2 (en) | 2007-05-09 | 2012-05-15 | Research In Motion Limited | Wireless router system and method |
| US8185930B2 (en) | 2007-11-06 | 2012-05-22 | Mcafee, Inc. | Adjusting filter or classification control settings |
| US8045458B2 (en) | 2007-11-08 | 2011-10-25 | Mcafee, Inc. | Prioritizing network traffic |
| US8160975B2 (en) | 2008-01-25 | 2012-04-17 | Mcafee, Inc. | Granular support vector machine with random granularity |
| US8589503B2 (en) | 2008-04-04 | 2013-11-19 | Mcafee, Inc. | Prioritizing network traffic |
| US20110137947A1 (en) * | 2009-12-03 | 2011-06-09 | International Business Machines Corporation | Dynamic access control for documents in electronic communications within a cloud computing environment |
| US8621638B2 (en) | 2010-05-14 | 2013-12-31 | Mcafee, Inc. | Systems and methods for classification of messaging entities |
| TWI584613B (zh) * | 2015-12-30 | 2017-05-21 | Chunghwa Telecom Co Ltd | Remote data management method for cross - transmission media |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5144557A (en) * | 1990-08-13 | 1992-09-01 | International Business Machines Corporation | Method and system for document distribution by reference to a first group and particular document to a second group of user in a data processing system |
| JPH05274229A (ja) * | 1992-03-25 | 1993-10-22 | Toshiba Corp | ネットワークシステムにおけるデータの変換方式及びそのネットワークシステム |
| US5418908A (en) * | 1992-10-15 | 1995-05-23 | International Business Machines Corporation | System for automatically establishing a link between an electronic mail item and a remotely stored reference through a place mark inserted into the item |
| JPH06152641A (ja) * | 1992-10-30 | 1994-05-31 | Yokogawa Hewlett Packard Ltd | 電子メール送信方法 |
| JP3279825B2 (ja) * | 1994-08-05 | 2002-04-30 | 株式会社リコー | マルチメディアサーバー |
| JPH08265245A (ja) * | 1995-03-23 | 1996-10-11 | Hitachi Ltd | データ配送システム |
| JP3013788B2 (ja) * | 1996-09-30 | 2000-02-28 | 日本電気株式会社 | ファクシミリシステム |
-
1997
- 1997-10-22 TW TW086115643A patent/TW400487B/zh not_active IP Right Cessation
- 1997-10-23 JP JP9291270A patent/JPH10154110A/ja active Pending
- 1997-10-23 EP EP97118452A patent/EP0838774A3/en not_active Withdrawn
-
2003
- 2003-01-21 JP JP2003012564A patent/JP2004005404A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP0838774A3 (en) | 2005-08-31 |
| EP0838774A2 (en) | 1998-04-29 |
| TW400487B (en) | 2000-08-01 |
| JPH10154110A (ja) | 1998-06-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004005404A (ja) | 電子文書をネットワークを介して動的に引渡すシステム | |
| US6192407B1 (en) | Private, trackable URLs for directed document delivery | |
| US5790790A (en) | Electronic document delivery system in which notification of said electronic document is sent to a recipient thereof | |
| EP0869652A2 (en) | Document delivery system | |
| US6594693B1 (en) | Method and apparatus for a structured, synchronized conversation using electronic messages over a computer network | |
| US7051003B1 (en) | Method and apparatus for delivering electronic data through a proxy server | |
| US5951636A (en) | Accessing a post office system from a client computer using applets | |
| US7068680B1 (en) | Communication service architectures for netcentric computing systems | |
| US6748529B2 (en) | Method and apparatus for effecting secure document format conversion | |
| US7277901B2 (en) | Collaborative file update system | |
| US20030023695A1 (en) | Modifying an electronic mail system to produce a secure delivery system | |
| US6990578B1 (en) | Method and apparatus for encrypting electronic messages composed using abbreviated address books | |
| JP4107964B2 (ja) | リモート印刷 | |
| WO2001026321A2 (en) | Communication service architectures for netcentric computing systems | |
| US20030081788A1 (en) | Secure printing to a web-based imaging print service | |
| US20020112184A1 (en) | System and method for secure transmission of data clients | |
| WO2000046952A1 (en) | Method for sending secure email via standard browser | |
| CA2328548A1 (en) | Privacy system | |
| WO2000051029A2 (en) | Method and apparatus for delivering electronic data through a proxy server | |
| Finin et al. | Facilitators and Mediators for Intelligent Agent Protocols. | |
| Pizano et al. | Multimedia messaging systems | |
| WO2002091131A2 (en) | Modifying an electronic mail system to produce a secure delivery system | |
| Logan | The Requirements for a Contemporary X. 400 Mail System for Distributed Networks | |
| Kushida et al. | Mail server for PC users | |
| Griesmer et al. | Evolution of messaging standards |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040406 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040406 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050801 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20051101 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20051107 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060126 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060814 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20061114 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20061127 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070202 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070618 |