(57)【特許請求の範囲】
【請求項１】
クライアント装置とサーバ装置とにネットワークを介して接続され、トランザクションを受付ける情報処理装置において、実行可能なエージェントと、前記実行可能なエージェントがトランザクションの特徴により実行するか否かを示す基準とを記憶するエージェント配列記憶手段と、受付けたトランザクションからトランザクションの特徴を生成して、前記受付けたトランザクションと前記生成したトランザクションの特徴とを対応づけて特徴インデックス記憶手段に記憶する特徴生成手段と、前記基準と前記特徴インデックス記憶手段とにより、前記受け付けたトランザクションで実行可能なエージェントを同定するマッチング手段と、前記マッチング手段により同定されたエージェントを前記エージェント配列記憶手段から読み出して、前記受付けたトランザクションを実行する実行手段とを備えることを特徴とする情報処理装置。
【請求項２】
前記トランザクションは、トランザクションのソース、トランザクションの宛先、トランザクションに関連するデータを同定するフィールドを含むことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記エージェント配列記憶手段には、複数のエージェントが記憶されていることを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
ネットワークを介して受付けたトランザクションを実行する情報処理方法において、実行可能なエージェントと、前記実行可能なエージェントがトランザクションの特徴により実行するか否かを示す基準とをエージェント配列記憶手段に記憶しておき、情報処理装置が、受付けたトランザクションからトランザクションの特徴を生成して、前記受付けたトランザクションと前記生成したトランザクションの特徴とを対応づけて特徴インデックス記憶手段に記憶するステップと、情報処理装置が、前記基準と前記特徴インデックス記憶手段とにより、前記受け付けたトランザクションで実行可能なエージェントを同定するステップと、情報処理装置が、同定されたエージェントを前記エージェント配列記憶手段から読み出して、前記受付けたトランザクションを実行するステップとからなることを特徴とする情報処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報の取り扱い及び処理分野に関するものである。より詳細には、一実施例において、本発明は、インターネットのようなネットワーク上で伝送されるドキュメントにおいて具体化される改善された情報処理を提供するものである。
【０００２】
【従来の技術】
用語“インターネット”は最近広範な利用を勝ち得ているネットワークである世界的なインターネットワークを指している。
【０００３】
任意の２台のコンピュータ（ノード）の通信は、両者がどこかでインターネットに接続されている限り、インターネット上で行うことができる。インターネット上でのデータ通信用の最も一般的なプロトコルはＴＣＰ／ＩＰ（Transport Contorl Protocol /Internet Protocol）である。ＴＣＰ／ＩＰの上のレイヤー（層）における多数の異なったトランスポート（transport）アプリケーションが知られている。ＦＴＰ（File Transfer Protocol）は、ファイルを一方のマシンから別のマシンへ移動させるのに用いられるプロトコルである。その利用故に、典型的なＦＴＰクライアント（client）は、ファイルのリストを表示して、ディレクトリー構造などを通過できるようにするファイルマネージャーに似たイターフェースを有している。ＳＭＴＰ（Simple Mail Transfer Protocol）は、通常、ユーザの対話（interaction）なしで、その最終的な行き先の途中でホストマシン間でｅ−メールを移動させるのに使用されるプロトコルである。ＨＴＴＰ（Hyper Text Transfer Protocol）は、殆どのドキュメントがワールドワイドＷｅｂ（即ち、“ｗｗｗ”又は“Ｗｅｂ”）ドキュメンである場合に、ノード間でドキュメントを伝送するのに使用されるプロトコルである。典型的には、ＨＴＴＰはＷｅｂ（Ｗｅｂ）サーバとＷｅｂブラウザクライアント（client）間で使われている。ＨＴＴＰを用いて伝送されるドキュメントは、グラフィク要素及びフォーム（形式）のような、幾つかのコンポネント（成分）から構成されている。Ｗｅｂブラウザはエンドユーザ（最終利用者）に見せる（ドキュメント，グラフィック又はビデオドキュメント）又は聞かせる（オーディオドキュメント）ために、ドキュメントを表示することができ、かつ、一方の参照ドキュメントから別のものにジャンプすることができるため、エンドユーザは、ＨＴＴＰ形態を用いて提供されるドキュンメントがドキュメント網を形成していることを知る。従って、ワールドワイドＷｅｂ（“ｗｗｗ”又は“Ｗｅｂ”）は、ＨＴＴＰを用いるインターネット上で利用可能な数千の項目によって収集されリンクされたドキュメントの集合体を指すのに用いられている。
【０００４】
基本的には、ＨＴＴＰはドキュメントトランスポートプロトコルである。現在のＨＴＴＰシステムにおいては、ＨＴＴＰクライアント（必ずしもという訳ではないが、通常はブラウザである）は、ＨＴＴＰのサーバに対してドキュメントを要求するためＨＴＴＰ要求（リクエスト）を送り、（もし、そのクラアントがそのドキュメントを読む許可を得ていれば）そのドキュメントを返送する。もし、そのドキュメントが複合ドキュメント（ａcompound document）であれば、ＨＴＴＰクライアントは埋め込まれたドキュメント（典型的にはグラフィックイメージである）への参照を見つけるために返送されたドキュメントを読む。Ｗｅｂサーバは、ドキュメントイメージを形成するのに十分なデータを受け取ると、そのドキュメントのイメージを表示する。Ｗｅｂの益々大きくなる人気は、その一端はドキュメントを見るのに利用者は単にドキュメントを要求すればよいという事実によるものである。これとは対照的に、ＦＴＰでは、ユーザは、ファイルリストからファイルを選び、そのファイルを伝送し、埋め込まれたファイルが必要か否かを決定するためにそのファイルを開き、リストからそれらのファイルを選択し、それらをダウンロードし、かつ、それらから最後にそのドキュメントを可視化しなければならない。
【０００５】
応用例のあるものにおいては、既存のドキュメントを単に伝送すること以上のことが要求される。固定のドキュメントの代わりに、利用者はドキュメントの要求が受け入れられた時に、動的に生成されるドキュメントの受け取りを望むことがある。動的ドキュメント（dynamic document）を生成する一つのメカニズムは、コモン，ゲートウェイ，インターフェース（Common Gateway Interface（ＣＧＩ））スクリプトを用いることである。クライアントは、ＣＧＩスクリプトにより、ＵＲＬ（Uniform Resource Locator）のフォームでドキュメントを要求する。この場合、ＵＲＬはサーバ上のドキュメントでなくサーバのプログラムを参照する。サーバはそのプログラムによってドキュメントを生成し、ブラウザに該ドキュメントを返送する。サーバはその要求をドキュメントではなくてスクリプトを実行する要求であると同定し、かつ、サーバは、おそらくはＵＲＬの一部として認められた推論（argument）を用いて、そのＣＧＩスクリプトを実行する。これにより、ドキュメントを要求しかつ受け取るためのみに設定されたクラアントブラウザは、クライアントサーバ側のコードの実施の結果を表示することを許容することとなる。ＣＧＩスクリプトはブラウザをサーバ側のデータベースにインターフェース接続するのに用いられ、それによって、サーチの要求がＵＲＬとしてサーバに送られ、そのサーチ結果はドキュメントとして返送される。それらは、サーバ側で実行されかつブラウザは一切識別しないため、ユーザはＣＧＩをいつ、どう使用するか制御することはできない。
【０００６】
もし、その計算機能（computing）が、クライアント側のコード（アプレット）を書くために用いられるカリフォルニア（ＣＡ）マウンテン  ビユゥー（Mountain View）のサン  マイクロシステムズ社（Sun Microsystems,Inc.,）によって指定されたＪＡＶＡ言語（Java Language）によるなどして、ドキュメントと共に伝送されるならば、ユーザはプログラムに実行についてより多くの制御手段を持つこととなる。
【０００７】
クライアント側でコードを実施することにより、クライアントはドキュメントを要求し、かつ、返送されたドキュメントはそのドキュメント中に埋め込まれたプログラムコードを含む。クライアントブラウザは、クライアント側のコードを知っていなければならないが、受領と同時にコードを実行する。クライアント側でコードを実行することにより、ドキュメントのアニメーション画像要素のような、そうしなければサーバ上で実施しかつサーバとクライアント間のリンク上に伝送するのに大きな帯域帯が必要となる、簡単なタスクを遂行するに最も適した使用法であることが明らかとなる。
【０００８】
ＪＡＶＡスクリプトとＣＧＩとはその実行の場所（locus）は異なるが、それ以外はそれほどでもない。サーバのオペレータはどのＪＡＶＡスクリプトがドキュメントに付されるか特定するのであるから、それらはなおサーバ制御されるプログラムである。これらの両方法は、いずれもサーバオペレータにより特定されるものであるので、それらは、ユーザに対する融通性を制限している。サーバ側でのコードの実行は、サーバＷｅｂ側の開発者（developer）によってセットされかつ制御されるので、読み取り側の自由裁量で行うことはできない。クライアント側でのコードの実行は、サーバが既にアプレットを含んでいるドキュメントに制限されかつアプレット認識ブラウザとともに用いる場合に制限されている。
【０００９】
ユーザに融通性及び制御を提供するための幾つかの試みがなされてきている。一つの試みは、専用のクライアントエージェント（Client Agent）を提供することである。クライアントエージェントは、蓄積された引用文献を収集し、録音された音響を演奏し、かつ、サーチを実施するようなことを行うため、ブラウザクライアントとして同じマシンで実施される。クライアントエージェントは、もし、ブラウザがクライアントを認識していれば、ブラウザクライアントと共に用いることができる。例えば、リアルオーディオ（Real Aaudio）のオーディオプレーヤーは、簡単なクライアントエージェントである。即ち、ネットスケープＷｅｂブラウザ（Netscape Web bowsers）は、オーディオプレーヤー用フックを持っているので、このクライアントエージェントは、そのＷｅｂブラウザに遭遇したオーディオファイルにコンピュータスピーカへのルートを設定することができる。オーディオプレーヤーを認識できないＷｅｂブラウザについては、その結果は、ブラウザがオーディオファイルを受け取った時に、それをどう処理するのか理解できないということになる。クライアントエージェントは、また、クライアントとネットワークとを接続する帯域幅により、それのできることが制限される。
【００１０】
ローミングエージェント（Roaming Agents）は、クライアント側又はサーバ側エージェントよりもより融通性があるが、広い利用をみていないようである。ローミングエージェントはエージェントの所有者によって特定されたタスクを行うプログラムであり、その実行位置は実行中にエージェントが見い出すものに応じて変わるものである。このローミングエージェントは、各ノードにおいて、ネットワークに十分な計算能力が存在する間は、特別の理由がない限り実行されない。インターネットの成長と商業化によって、安全性が問題であり、かつ、資源は容易に過負荷状態になる。その結果、極めて小数のサーバオペレータのみがシステム上でのローミングエージェントの実行を許可されている。近い将来には、サーバ上で動くことを許されるエージェントのみがサーバオペレータによって特に選別されることになる。そうしなければ、サーバはエージェント用の場所を求めるユーザの殺到によって急激に身動きできなくなるであろうし、又は競争相手のサーバ上でエージェントを動作させている企業でさえも、コンピュータの能力を“盗む”ことになろう。
【００１１】
種々のエージェントシステムの潜在的な問題は、ユーザはサーバのオペレータの自由裁量で提供されたサーバ側のエージェント、又は、エージェントを認識できるクライアントととのみ対話しかつサーバオペレータによって管理されることが多いクライアント側のエージェントに制限されているので、平均的なユーザには一般化されたエージェントを実行する適当な場所はないということである。
【００１２】
サーバ又はクライアント以外の場所（locus）でユーザの情報を処理できる情報組織のための特別のシステムが提案されているが、これらのシステムは全てのサーバ及びクライアントが情報システムを認識していることを要するものである。ＷＷＷインダ（WWWinda），プロスペロ  アンド  テーシーケイＷＷＷロボット（Prospero and TckWWW Robot）がそのような情報システムの例である。
【００１３】
【発明が解決しようとする課題】
必要なものは、ワールド  ワイド  Ｗｅｂのようなドキュメント指向のフレームワークで好ましく動作し、使用されるサーバ又はクライアントとは無関係に、ユーザによって特定された位置で一般的なエージェントの実行を許容するコンピュータシステムである。
【００１４】
【課題を解決するための手段】
請求項１の発明は、クライアント装置とサーバ装置とにネットワークを介して接続され、トランザクションを受付ける情報処理装置において、実行可能なエージェントと、前記実行可能なエージェントがトランザクションの特徴により実行するか否かを示す基準とを記憶するエージェント配列記憶手段と、受付けたトランザクションからトランザクションの特徴を生成して、前記受付けたトランザクションと前記生成したトランザクションの特徴とを対応づけて特徴インデックス記憶手段に記憶する特徴生成手段と、前記基準と前記特徴インデックス記憶手段とにより、前記受け付けたトランザクションで実行可能なエージェントを同定するマッチング手段と、前記マッチング手段により同定されたエージェントを前記エージェント配列記憶手段から読み出して、前記受付けたトランザクションを実行する実行手段とを備えることを特徴としたものである。
【００１５】
請求項２の発明は、請求項１の発明において、前記トランザクションは、トランザクションのソース、トランザクションの宛先、トランザクションに関連するデータを同定するフィールドを含むことを特徴としたものである。
【００１６】
請求項３の発明は、請求項１または２の発明において、前記エージェント配列記憶手段には、複数のエージェントが記憶されていることを特徴としたものである。
【００１７】
請求項４の発明は、ネットワークを介して受付けたトランザクションを実行する情報処理方法において、実行可能なエージェントと、前記実行可能なエージェントがトランザクションの特徴により実行するか否かを示す基準とをエージェント配列記憶手段に記憶しておき、情報処理装置が、受付けたトランザクションからトランザクションの特徴を生成して、前記受付けたトランザクションと前記生成したトランザクションの特徴とを対応づけて特徴インデックス記憶手段に記憶するステップと、情報処理装置が、前記基準と前記特徴インデックス記憶手段とにより、前記受け付けたトランザクションで実行可能なエージェントを同定するステップと、情報処理装置が、同定されたエージェントを前記エージェント配列記憶手段から読み出して、前記受付けたトランザクションを実行するステップとからなることを特徴としたものである。
【００３１】
一実施例においては、使用される計算システムは、“エージェンシー”と指称され、ユーザエージェントのための実行位置を形成する。このエージェンシーは、一以上のＷｅｂと一以上のＷｅｂサーバとの間に挿入される。エージェンシーで実行されるエージェントはドキュメントを転送することによってクライアント及びサーバと対話する。エージェントはエーシェンシーを認識できないクライアント又はサーバに対し透過でき、かつ、好ましくは、例えクライアント又はサーバがエージェンシーを認識している場合であっても、サーバとクライアントの間で透過動作するものである。エージェンシーは、ドキュメント要求がクライアントからサーバに及びその逆に送られ、かつ、ドキュメントはネットワークを移動中に変換されることを必要とするか、又は、状態が保存されることを必要とする多くの応用例において利用することができる。
【００３２】
個人情報エージェンシーは、ユーザによって使用される種々のクライアントとこれらのユーザにアクセスされる種々のサーバとの間に挿入される。個人情報エージェンシーは、ユーザによってアクセスされた全てのドキュメントの履歴を保持する履歴エージェント（History Agent）、ユーザが“ブックマークを付けた”ドキュメントのリストを保持するホットリスト（hotlist）エージェント、及び、ユーザクライアントに送付したドキュメントの複製を受領クライアントに送付するミラー（mirror）エージェントのようなユーザエージェント用の位置（locus）を提供する。ユーザエージェントは、サーバからクライトに向かう参照されたドキュメントにリンクを挿入することによってドキュメントを変換する機械読み取り可能なリンクエージェントのような変換エージェントであり、ここで、リンクはプリントされた後においてさえ機械読み取り可能なものである。
【００３３】
一般に、エージェンシーは、トランザクション上でエージェントを実行し、かつ、新規なエージェント及び新種のトランザクションの受け入れに対し解放である。エージェントによっては、トランザクション上で、特定のトランザクションを知覚しかつ変更するような比較的重要でない活動を行うものがあり、他方、トランザクションを遂行するか又はそれを転送するようなトランザクションを完全に操作するより主要な活動を行う別のエージェントもある。
【００３４】
ある実極例においては、Ｗｅｂエージェンシーは、Ｗｅｂクライアントを実行するようプログラムされたデジタルコンピュータとは別個の好適にプログラムされたデジタルコンピュータであり、他方、他の実施例においては、Ｗｅｂエージェンシー及びＷｅｂクライアントは単一のコンピュータで実行する二つのプロセスである。通常、帯域帯及び利用可能な計算能力で決定されるクライアント，エージェンシー及びサーバについての多くの特定の変更例は、この開示を読んだ後には、当業者に自明であるはずである。
【００３５】
Ｗｅｂエージェンシーの一つの特定の実施例は、ドキュメント指向周辺機器と対話するように設計されている。別の実施例は、複数のＷｅｂクライアント及びＷｅｂサーバについてユーザの状態及び履歴を記録する個人情報エージェンシーである。ユーザの状態を追跡することにより、種々のサーバから受け取った全てのドキュメントをユーザ提示用の一様なフォーマットに変換するための、個人エージェンシーによって使用される一組の好み（a set of preferences）とともに、クロスクライアント履歴リスト（cross-client history list）を作成することができる。
【００３６】
Ｗｅｂエージェンシーの一つの利点は情報表示と情報管理との相互関係を断ち、それによって、これらのタスクを独立のものにすることである。Ｗｅｂエージェンシーの別の利点は、ユーザに対しテキストよりもむしろドキュメントを扱うインターフェース又はグラフィック用ユーザインターフェースを許容することである。
【００３７】
Ｗｅｂエージェンシーのさらに別の利点は、ＨＴＴＰのようなステートレスメッセージ通過プロトコル（a stateless message passing protocol）を用いた場合でも、ドキュメント転送の流れの中で計算動作を行うことができるということである。トキュメントに埋め込まれたもの以外には、エージェンシー，クライアント及びサーバ間で交信すべき共有ステートがないため、実施は極めて簡単である。
【００３８】
本発明の本質及び利点の更なる理解は、明細書の残りの部分及び添付図面を参照することによって得ることができる。
【００３９】
【発明の実施の形態】
ここで、本発明のを実行するための好ましい実施例が、本発明の特定の使用例に関連して詳しく説明される。しかしながら、本発明は、それに限定されるものではない。当業者は、この開示を読んだ後、説明された実施例の他の有用な変更例を理解するであろう。
【００４０】
図１は、本発明が用いられる典型的なシステム環境におけるエージェンシー１０のブロック図である。
ユーザはエージェンシー１０に直接アクセスできるが、ユーザは典型的にはＷｅｂサーバ１４にアクセスするためＷｅｂクライアント１２である種の行動を起こすことによって、エージェンシー１０にアクセスする。以下で説明するように、エージェンシー１０は多くはＷｅｂクライアント１２に透過性であり、同クライアント１２はエージェンシーを見越してプログラムする必要はない。Ｗｅｂクライアント１２及びＷｅｂサーバ１４は、チャンネル１６上でＨＴＴＰのようなハイパーテキストドキュメント透過プロトコルを用いて互いに通信するようプログラムされている。チャンネル１６は、物理的チャンネルである。しかし、典型的には、論理チャンネルである。チャンネル１６は、直接又はインターネットのようなネットワーク１８を介してＷｅｂクライアント１２とＷｅｂサーバ１４を接続している。
【００４１】
Ｗｅｂクライアント１２及びＷｅｂサーバ１４の間には、エージェンシー１０が挿入されている。ある場合には、ドキュメントは要求Ｗｅｂクライアント１２でなく受領（recipient）クライアント２０にルートが定められている。受領クライアント２０は能動Ｗｅｂクライアント１２における活動の受動“コピー”を表示するクライアントとしてのような多くの利用方法がある。
【００４２】
エージェンシー１０は、ＨＴＴＰドキュメント要求とドキュメントを送受するので、それは、単にＨＴＴＰクライアント又はサーバと通信することを期待する、Ｗｅｂサーバ及びクライアントと対話することができる。
図２は、どうやってこれを行うかを示すエージェンシー１０のより詳細な図である。
図２は、主にＨＴＴＰを介してクライアント及びサーバと対話するエージェンシーを示すが、エージェンシーは他のプロトコル及びＷｅｂのない環境において使用するように適用できることを理解されたい。
【００４３】
エージェンシー１０は、外部ソースから受領エージェント３０及びＨＴＴＰインターフェース２８を経てクライアント及びサーバからトランザクション（１７，１７ａ，１７ｂ等）を受け入れるものとして示されている。エージェンシー１０はエージェント３０を用いてトランザクションを処理するリゾルバ（resolver)２４を含んでいる。リゾルバ２４は、エージェント配列（array）２０，特徴計算機（featuer calculator）２１，トランザクション列（quere）２３，マッチチェッカー（match checker）２５，“act_on”プロセッサ２７，ハンドラ（handler）２９及びエージェンシーレジストラル（registrar）３１を含んでいる。
【００４４】
エージェンシー１０は、インストールすべきエージェントを備えたトランザクションを制御する“エージェントインストール”エージェントのような既存の標準的な組をなすエージェントで例示可能であるが、エージェンシーはトランザクション上で動作可能である前に、エージェント配列２０中に１又はそれを越えるエージェント３０を有していなければならない。エージェントレジストラル３１（それ自身エージェントインストールエージェントである）は、エージェント３０を受け入れ、かつ、それらをエージェント配列２０上に置く。図２に示すように、各エージェントは、少なくとも一つの基準（criterion）、act_on()メソッド、及び、handle()メソッドを有しており、その使用法については、以下で説明する。エージェントインストールプロセスの一部として、エージェントはリゾルバ２４によってその基準を“登録（register）する”。それからリゾルバ２４は、基準によって索引が付されたマッチテーブル（match table）中に登録された基準を蓄積する。これによって、任意の所定の基準又は特徴に対して関与するエージェントのリストを迅速かつ容易に検索することを可能にしている。
【００４５】
リゾルバ２４の役割は、トランザクションを受け入れかつエージェントにトランザクションと何らかの作用を行うようにさせることである。エージェントリゾルバ又は“ハンドル（handles）”によって動作が起こされると、トランザクションはリゾルバ２４から削除される。そのようなエージェントの動作は、handle()メソッドと指称され、トランザクション上で動作するが、しかし、トランザクションを完全には制御しないact_onメソッドとは区別される。エージェンシーを開放されかつ拡張自在にするため、操作可能なエージェント，それらの方法又はトランザクションは所定の時間より前にはセットされない。この理由から、リゾルバ２４はトランザクションを処理するに際し、機敏でなければならない。リゾルバ２４はどのトランザクションがどのエージェント上で動作されるか又は満足されるか特定しない。その代わり、エージェント配列２０中のエージェントはどのタイプのトランザクション上で動作又は処理するか特定し、かつ、トランザクションはそれら自身の特徴を特定する。このようにして、リゾルバ２４はトランザクションを、エージェントに含まれる基準及びトランザクション中に含まれる特徴に基礎を置くエージェントに整合させる。このコンセプトは、エージェンシー１０の動作の説明に関連して、以下で説明する。
【００４６】
ここで、エージェンシー１０の動作を説明する。例示に際して、エージェンシー１０は、既にそのエージェント配列中に、エージェントインストールエージェントのような少なからずの標準エージェント３０を持っている。クライアント及びサーバがエージェンシー１０にトランドクション１７を送ると、このトランザクションはＨＴＴＰインターフェース２８によって受け入れられる。典型的なトランザクションは、テーブル１に示されている。しかしながら、全ての要素が全てのトランザクションに存在するわけではないことを理解されたい。
【００４７】
0003719825.tif 000002
【００４８】
トランザクションがリゾルバによって受け取られると、それは最初に特徴計算機（feature calculator）２１によって処理される。特徴計算機２１は、特徴セットを見つけるために、トランザクションのデータ要素（及びおそらくは他の要素も）を走査することによって、トランザクションに対する特徴リストを生成する。トランザクションの特徴の例は、テーブル２に示されている。特徴リストは、トランザクションの特徴の“場所（cache）”である。全ての特徴を一度評価することによって、トランザクションがある特徴を持っているか否かについてエージェントが知る必要がある度ごとに、トランザクションデータを走査しなければならないということはない。もし、トランザクションが変更されれば、勿論、トランザクションは特徴計算機２１又は同等の手順によって再処理されることになろう。
【００４９】
トランザクションの各特徴は、特徴計算機２１において、コードの断片（Ｃ又はPerl関数等）によって表され、その結果、付加的な特徴は、特徴計算機の既知の特徴セットにいつでも追加することができる。例えば、もし、エージェンシーが所定の位置に配置された後、新規なグラフィックドキュメントフォーマットＸＹＺが出てくると、新規な特徴断片ＩＳ_ＸＹＺを特徴計算機２１への挿入のために（おそらくは、“特徴インストーラ”エージェントで指示されるトランザクションを用いて）リゾルバに送ることができる。それから、トランザクションのデータを走査するとき、特徴計算機２１は、もし、ＸＹＺフォーマットを検知すると、新規なコードの断片は、“true”のリターン値（return value）を与え、かつ、特徴計算機は該トランザクションに対する特徴リストにＩＳ_ＸＹＺを付加する。以下で説明するように、エージェントは各々それら自身の基準（criteria）を備えているから、ＸＹＺフォーマットドキュメントに作用し、かつ、処理するようにプログラムされたエージェントはエージェンシー配列に容易にインストールできる。
【００５０】
0003719825.tif 000003
【００５１】
特徴リストが一度生成されかつトランザクションと関連付けられると、トランザクションは、トランザクション列２３に蓄積される。トランザクションはそこからマッチチェッカー２５によって検査される。オブジェクト指向環境においては、マッチチェッカー２５の機能性は各々のエージェントの部分である一組のマッチチェック用メソッドとして実施される。いずれにしても、各々のエージェントはどのドランザクションに整合（マッチング）するのかを見るために、各々トランザクションに整合される。整合はエージェントに特有のブール代数表現であって、ここで、その表現は特徴の関数である。例えば、エージェントに対する基準は、
is_file_request＝true＆＆is_local_source＝＝false
となろう。
【００５２】
エージェントに関与（interest）するこれらのトランザクションは、エージェントに対する基準表現（critaria expression）で示される。もし、基準表現が“false”であれば、エージェントはトランザクションに関与しない。もし、基準表現が、“true”であれば、そのときは、エージェントはトランザクションに関与する。このように、上記の基準表現に対し、もし、トランザクションの特徴リストが、トランザクションがファイル要求であり、かつ、それが非ローカルソース（nonlocal source）であることを示しているとすると、その場合には、エージェントはトランザクションを処理する。ある実施例においては、エージェントはact_on()メソッド及びhandle()メソッドに対し異なった基準表現を持つことができる。効率的な実施においては、各々のエージェントは各々のトランザクションを考慮しない。代わりに、各エージェントは特徴及びこれらの特徴を有するトランザクションへの参照をソートしたテーブルである特徴インデックス３３を考慮する。その方法により、各エージェントには関与するトランザクションを走査することのみが必要となる。勿論、トランザクションを処理する際に、エージェント−特徴インデックスも用いて、無関係なエージェントを無視できるようにすることができる。
【００５３】
もし、エージェントが（全体の基準表現又は特定のact_on基準表現のいずれかによって示された）トランザクションにアクトオン（act on）することに関与すると、エージェントのact_on()メソッドが実施される。これは、act_onプロセッサ２７によって行われるか又はエージェントのact_on()メソッドの実施によって論理的に行われる。スレッデッドプロセス（threaded process）が用いられる場合には、各々のact_on()メソッドは並行処理を可能にするための分離したフォークドプロセス（forked process）である得る。
【００５４】
act_on()メソッドは、Ｉ／Ｏアクションを起こすこと、計算を行うこと、トランザクションを付加するか又はトランザクションのデータ，特徴セット、又は、他のデータ要素を変更することを含む。好ましい実施例においては、Ｉ／Ｏアクションはhandle()メソッドのために保留されており、それによってすべてのact_on()メソッドは、Ｉ／Ｏコール（call）のための処理妨害を心配することなく（同期）コールをブロックし続けることができる。もし、トランザクションがＩ／Ｏに関係するが、そのトランザクションを完全には処理（handling）しないある処理を必要とするならば、その場合には、元のトランザクションの非処理Ｉ／Ｏ（the nonhandling Ｉ／Ｏ）が新規なトランザクションの処理によって生成される。
【００５５】
トランザクションがすべての関与エージェントによって一度アクトオンされると、トランザクションは（実際又は論理的のいずれかにより）ハンドラ２９に進む。act_onプロセッサ２７とともに、ハンドラ２９は論理構造であり得、制御は単にエージェントのhandle()メソッドをコールすることによって行われる。一実施において、トランザクションを処理することに関与する各エージェントは、そのhandle()メソッドのポインターをトランザクションのハンドラの列（queue）にフックする。効率化のためにエージェントのact_on()メソッドは、act_on()メソッドがコールされたときフックを付加することができる。エージェントは、それ自身のhandle()メソッド以外にフックを付加することができる。例えば、エージェントは、コード断片（code snippet）上で別のトランザクションにフックを付加することができる。
【００５６】
全ての関与エージェントがハンドラ列中にフックされているときは、ハンドラ２９はその列を通して歩進しかつ順にhandle()メソッドを実施する。もし、エージェントがそれがトランザクションを実際に完全に処理できることを見い出した場合、そのhandle()メソッドは、“true”リターン値（return value）を返し、かつ、ハンドラ２９はそれにふさわしく列（queue）２３又はハンドラ２９からトランザクションを削除する。もし、エージントがそれがトランザクションを完全には満足させないことを見い出したとすれば、エージェントのhandle()メソッドは、エージェントが非制御トランザクションに対して採るべき任意のステップを実行し、かつ、“false”のリータン値を返し、それによってハンドラ２９が操作のための次のエージェントについてチェックを進めるようにする。いずれのエージェントも“true”を戻すことなくトランザクションのハンドラ列の最後まで達すると、ハンドラ２９はトランザクションのデフォルトhandle()メソッドを実施する。理解されであろうように、エージェンシー１０及びリゾルバ２４のこれらの各々の活動的な要素は、切り離した計算装置又は単に一般目的の計算装置によって実施される異なったプロセス又はルーチンのいずれかであり得る。
【００５７】
トランザクションが一以上の宛先（destination）に向すう場合には、一つのエージェントのact_on()メソッドはそのトランザクションのクローン（clone）をつくり、かつ、マシンフィールドへ向かう各トランザクションを一つの宛先に向けてセットすることができる。
【００５８】
以上で説明したように、トランザクション１７は、リゾルバ２４によって受け入れられ、トランザクションの特徴は、該トランザクションと関連する特徴リストに貯えられ、かつ、トランザクション１７は、トランザクション列上の所定の位置に配置される。この特徴リストは、特徴インデックス３３と相互参照される。それから、リゾルバ２４は、基準表現を有するエージェント配列２０中で、トランザクション１７の特徴で評価したとき、“true”と評価されるエージェント３０を同定する。これらのエージェント３０は、トランザクション１７上で作用して、Ｉ／Ｏを実施し、計算を行い、蓄積状態又は内部データを変更し、新規なトランザクションを生成し、トランザクション１７を変更する。リゾルバ２４は、act_on()メソッドの部分として又はそれとは別に、トランザクションのためのハンドラの列を構築し、かつ、handle()メソッドが“true”の値を返す、又は、もし、handle()メソッドが“true”の値を返さないならば、デフォルトハンドラを実施するまで、列中の各々のハンドラを順に実施する。このように、エージェンシー１０がセットアップされた後に、処理を行っているエージェントが生成される場合であっても、あるいは、エージェンシー１０がセットアップされた後に新規な特徴が実施される場合であっても、トランザクションはエージェンシー１０によって処理可能である。
【００５９】
エージェントは動作の巨大な配列（vast array of operation）を実施でき、かつ、他のエージェントと協働して独特な性格を持ったエージェンシーを形成するよう構築することができる。エージェントの例としては、サーチ結果にフィルターをかけるための、検索されたドキュメントから望まないものを取り除くための、ドキュメントにボタン（buttons）を付加するための、履歴情報を蓄積するための、ユーザの状態を蓄積するための、又は、ユーザの環境設定（configuration）及び初期設定（preference）を蓄積するためのエージェントがある。
【００６０】
実施されるように、エージェンシー１０は、新規なエージェントがエージェントインターフェースの標準に一致している限り、エージェンシー１０が構築されたときには、予期していなかったホストエージェントであり得る。これらのインターフェース標準（standard）は、オブジェクト指向プログラミングの使用により実施され、その際、“エージェント”のラベルを付したオブジェクトのクラスを特定することができる。エージェントは少なくともトランザクションを変更し又はトランザクション列２２に付加するための機能を含んでいる。
【００６１】
ＨＴＴＰインターフェース２８を介して受け取る要求及びデマンドは、直接又はＨＴＴＰインターフェースエージェントを通すかのいずれかにより、トランザクションに変換される。各トランザクションは、トランザクションのソース，トランザクションの宛先及びトランザクションに関連するデータを同定するフィールドを含んでいる。エージェンシー１０は、ドキュメント一指向計算システムで動作するので、データはドキュメント又はドキュメントの参照のフォーム（形式）である。パッキング要求（packing request），応答及びトランザクションに加え、ＨＴＴＰインターフェース２８は、いかにして特定のマシンに到達できるを記述し、かつ、マシンがどのブラウザを使用しているかを記述したマシンのデータベース２８の情報に基づいて応答（レスポンス）及び要求を変換することもできる（即ち、そのようにしてＨＴＴＰインターフェース２８は、適当なブラウザに一致させるため応答（レスポンス）を変更できる）。
【００６２】
リゾルバ２４の処々の要素（エレメント）は、実施形態により、可視要素又はオブジェクトレファレンス（object reference）である。例えば、オブジェクト指向プログラミング環境においては、act_onプロセッサ２７の機能は、トランザクションに作用する各エージェントにおけるメソッドとして内蔵されている。これと同じことがマッチチェッカー２５及びハンドラ２９でも真実である。さらに、トランザクションは、実際には、場所から場所に移動するのでなく、トランザクション列２３上で動作できるものである。実際の要素を移動させ代わりに、ポインタをデータ要素へ向ける操作，メソッド又は機能で十分である場合には、ポインタは実際のデータの代わりに図２の回りで動かされるデータである。
【００６３】
種々のエージェンシーをここで説明することとする。
一つの包括的なエージェンシーは、人が欲する任意のエージェンシーを動かしかつそれらの対話（interaction）を制御するまさに個人的なエージェンシーである。
【００６４】
図１，図２に示すシステムは、バイト（byte）一又はファイル一指向ネットワークで使用することができる。しかし、その利点の多くは、ドキュメント一指向ネットワークで用いることから引き出されるものである。バイト一指向ネットワークにおいては、全てのオブジェクトはバイトセットによって規定され、従って、オブジェクトは一般にそれらが含むバイド又はそれらが入力又は出力するバイトによって見ることができる。ファイル一指向ネットワークにおいては、オブジェクトはファイルとみなされる。ファイル一指向ネットワークの一般的な例は、ファイルサーバが設置されたローカルエリアネットワーク（ＬＡＮ）である。ＬＡＮは遠隔のファイルをローカルファイルのように見せるため、ファイル操作用のローカルな動作システムのコマンド（リストディレクトリ，チェンジディレクトリ，ムーブ／コピー／ディレートファイル等）を書き換える（エミレート（emulate）する）。Unixのようなある種のファイル一指向動作システムにおいては、ファイル操作コマンドを全く簡単に周辺機器の操作に適用できるよう、周辺機器は、ファイルに見えるように作られている。従って、プリンタでのフィルのプリントは、ファイルをプリントを表すファイルに複写することによって行われる。
【００６５】
ドキュメント一指向ネットワークにおいては、全てのオブジェクトがドキュメントのように見える。リンクで結合されたコンポーネント（構成成分）を備えた複合ドキュメントについては、全てのＷｅｂサーバ上の全てのドキュメントは、ユーザに対して、一つの大きなリンクされたドキュメントとして現われる。Ｗｅｂエージェンシーは、このコンセプトをさらに進めたものであって、ネットワーク上でアクセス可能な殆ど全てのものが一つのドキュメントとして出現するようになっている。一度ドキュメントが計算用ユニット（the unit of computing）であるとなると、ドキュメントをより容易に紙等価物に書き換える（エミュレートする）ことができ、その際、ドキュメントは以前に紙を扱った人なら誰にも慣れた範例（paradigm）を使って、余白に書き込まれ、蓄えられ、郵送され、保管所に保管される等のことを行うことができる。ドキュメントを中心とする一つの副次的効果は、ドキュメントを扱うツールが相互交換できるようになるということである。紙ドキュメント領域における類似性（analogy）は、ペンと机が相互交換可能な用品となり、ドキュメントは任意のペンを用いて編集されかつ任意の机の上に貯留しておくことができるということである。
【００６６】
ドキュメント一指向計算システムは、ドキュメントを自分自身の中を通過させるエージェンシーのネットワークのようにみえる（図１，参照）。このシステムにおいて、それらが全て適当な複合ドキュメントであるため、入，出力及び蓄積装置は簡単に扱えるようになる。入力装置は、ドキュメントソースであり、そのため、それらは入力装置からドキュメントを要求するエージェントから眺めたときには、常に更新され、永久に拡張し続けるドキュメントの集合である単一のドキュメント、あるいは、一又はそれを越える宛先へドキュメントを常に送り続けるクライアントとして現われる。出力装置は更新でき、常に拡張するドキュメントとの集合である一つのドキュメント、又は、一つ又はそれを越えるソースから常にドキュメントを要求するクライアントとして現われるドキュメントシンク（sinks）である。蓄積装置は、ドキュメントを蓄積装置に送りかつその後検索される入力装置及び出力装置の両方の様相を有している。
【００６７】
図３は、簡単なエージェンシーの論理ブロックダイアグラムである。
エージェンシー３２は、クライアントＡ，クライアントＢ，サーバＡ，サーバＢ及びサーバＣ間に挿入されている。図示するサンプル要求は、クライアントＢがクライアントＡが何を見ているかを“フォローしながら”、又は、モニタしながら行うドキュメント用の簡単な要求である。クライアントＡは、エージェンシー３２にドキュメント要求を送る（線３４で示す）。ドキュメント要求は、プロキシエージェント３６によって処理され、それがドキュメント要求をサーバＡに送り（線３８）、サーバは要求されたドキュメントをプロキシエージェントに戻す（線４０）。要重なことは、クライアントＡは、プロキシエージェントがそれとサーバＡの間に挿入されたことを知る必要がなく、また、サーバＡはプロキシエージェントを知る必要がないということである。このことが既存のクライアント及びサーバをエージェンー３２とともに利用可能にしている。線３４，３８及び４０は、ＨＴＴＰチャンネルを規定している。
【００６８】
クライアントＡからのドキュメント要求は、実際には、最初に、ドキュメント要求を備えたトランザクションをトランザクション列上に押し上げるエージェンシー３２のＨＴＴＰインターフェース（図示せず，図２，参照）によって受け入れられる。プロキシエージェンシー３６は、ドキュメントを直接要求するか、又は、ドキュメントを検索させるトランザクションを生成することによるかのいずれかにより、ドキュメント要求を処理するエージェントである。いずれによっても、検索されたドキュメントは、ドキュメントが受け取られたときには、トランザクションとして列（queue）上に押し上げられる。該トランザクションは、リゾルバによってホットリストエージェント４２及びフォローエージェント４４と整合されるが、しかし、トランザクションをクライアントに送るデフォルトトランザクションによって処理される。このようにして、ホットリストエージェント４２とフォローエージェント４４は、単にトランザクションを“アクトオン（act on）し”他方プロキシエージェント３６は、トランザクションを処理する。勿論、フォローエージェント４４は、Ｉ／Ｏを実行することを要求されるので、リゾルバは単にフォローエージェント４４をオリジナルトランザクションに“アクトオン”させるというのではなく、フォローエージェント４４によって処理される新規なトランザクションを生成することができる。
【００６９】
ホットリストエージェント４２は、クライアントＡに受け渡されたドキュメントを検査し、かつ、エージェンシー３２によって保守されるホットリストデータベース中にドキュメントへの参照を蓄積する。このホットリストデータベースは、ドキュメント要求を送るクライアントによって、後に一つのドキュメンとして、再びアクセスされ、リゾルバはそのドキュメント要求をトランザクションのハンドラとしてホットリストエージェントに整合させる。
【００７０】
フォローエージェント４４は、クライアントＡに受け渡されたドキュメントを検査し、かつ、クライアントＢについてトランザクションを生成することにより、コピーをクライアントＢを宛先にして送る。これにより、クライアントＢのところのユーザ又はコンピュータは、クライアントＡのところで何が起こっているのかをフォローすることができる。フォローエージェントの一つの応用は、他のユーザを訓練することである。別の応用は、クライアントによって検索される全てのドキュメントのローカルな蓄積である。これは、クライアントＡが検索された全てのドキュメントを蓄積する能力を構築されているか否かに拘りなく行うことができるということを銘記されたい。図３に示す例において、クライアントＢは、図１に示す受領クライアント２０のような“受領（recipient）クライアント”である。
【００７１】
ホットリストエージェント４２と同様に、フォローエージェント４４は、エージェンシー３２に通常のＨＴＴＰドキュメント要求を送ることにより制御することができる。例えば、エージェント４４によって供給される各ドキュメントは、"Stop Following”，“Rewind”，“Refresh”，“Alert”，“Option”等のラベルが付されたＨＴＴＰボタンを含んでいる。従って、各ページは、付加ボタンをそのページ自身に付した状態でクライアントＢの前に現われる。ボタンに対しＵＲＬを適当に割り当てることにより、押された時、それらは適当なメッセージをフォローエージェント４４に送る。“Stop Following”ボタンをクリックすることにより、クライアントＢは、ＨＴＴＰにドキュメント要求を送り、それがＵＲＬを参照し、かつ、それに対し、リゾルバはフォローエージェント４４によって処理可能なトランザクションを生じる。トランザクション列２２上のトランザクションが処理されると、フォローエージェント４４は、トランザクションを受け取り、それに従って反応する。“Rewind”ボタンに対しては、フォローエージェント４４は、ローカルな置き場所（cache）からドキュメントを呼び戻しかつ再送付する。“Alert”ボタンに対しては、フォローエージェント４４は警報（alert）の特徴を表示するクライアントＡにドキュメントを送る。“Option”に対しては、フォローエージェント４４は、クライアントからの更なる入力を得るために、通常、ＨＴＴＰフォーム（形式）のドキュメントをクライアントＢへ戻す。
【００７２】
次に、図４を参照すれば、エージェントとのより複雑な対話セットが示されている。すでに説明したプロキシエージェント３６，ホットリストエージェント４２及びフォローエージェント４４に加えて、図４は、また、全てが通常のＨＴＴＰチャンネルであり得る多数のエージェンシー３２に対する外部接続部４６を示している。インタレスト（interest）エージェント５０，フィルタエージェント５２，スケジュールエージェント５４、及び、インストールエージェント５６もまた図示されている。インタレストエージェント５０は、ユーザの関心を示す活動を遮って、かつ、これらの関心に関連する追加ドキュメントを自動的に集める。フィルターエージェント５２は、プロキシエージェント３６によって検索されたドキュメントを介してシフト（桁移動情報，shift）を受け取り、ドキュメントをクライアントＡに戻す前にフィルタールールに従ってそれらを変更する。フィルターエージェントは、望まない細部を取り除き、または、嫌な資料（material）を除くのに用いることができる。スケジュールエージェント５４は、ドキュメントを受け取りかつそれらをマルチスレッド（複数起動，multithreads）し、それによって、ユーザがドキュメントをロードするのに待たないようにしている。もし、サーバとエージェンシー間の接続がエージェンシーとクライアント間の接続よりも遅いときには、スケジュールエージェント５４は（おそらくは、インタレストエージェント５０の援助によって）、ユーザがフォローしようとするリンク及びエージェンシーにおけるそれらドキュメントの貯留場所を予知しようとする。インストールエージェント５６は、特定のエージェントをエージェント配列中にインストールするための要求を受け取る。明らかなように、クライアント，サーバ又はエージェンシーそれ自身の設計又は実施においてさえ意図しなかったタスクであっても、それら多くのタスクを処理するための他の多くのエージェントをエージェンシー３２によって例示することができる。
【００７３】
図４に示すようなエージェンシー３２を用いたドキュメント検索動作を次に詳細に説明することとする。
クライアントＡは、ＨＴＴＰドキュメント要求（通常、ＵＲＬをその要求の一部として含んでいる）によって、ウインドウＡからサーバＡからのドキュメントを要求する。要求は直接サーバＡに送る代わりに、エージェンシー３２に送られる。エージェンシーＨＴＴＰインターフェース（図示せず）は、要求をエージェンシーのトランザクション列（これまた図示せず，図２，参照）の所定の位置に配置されたトランザクションにフォーマットする。エージェンシーのリゾルバは、ドキュメント要求トランザクションをプロキシエージェント３６に整合させ、かつ、ドキュメント要求を送出しかつサーバＡからドキュメントを検索する。ドキュメントを受け取ると、それに対してトランザクションが生成され、かつ、トランザクション列上に配置される。図３で示したように、リゾルバはトランザクションをホットリスト４２及びフォローエージェント４４に整合させる。リゾルバは、また、トランザクションをインタレストエージェント５０に整合させ、かつ、トランザクションを処理するフィルターエージェントを有している。インタレストエージェント５０は、ユーザがどのタイプのドキュメントを検索しているのか認識するためトランザクションを走査し、かつ、それからドキュメント要求をトランザクション列上に押し上げることによって、それらのドキュメントを独立に獲得する。関心のあるドキュメントは戻され、かつ、インタレストエージェント５０のところで指示されたトランザクションにフォーマットされる。インタレストエージェント５０は、トランザクションをスケジュールエージェント５４に渡すことによって、トランザクションを処理し、スケジュールエージェント５４は、ウインドウＢでクライアントＡに関心のある項目リストを表示する。トランザクション−エージェント整合を適切に整えることにより、スケジュールエージェント５４は、フィルターエージェント５２からウインドウＡに戻る各ドキュメントに変わることができ、かつ、その情報を使って、ドキュメントがクライアントによって検索されたとき、関心項目のリストからその参照を削除するようスケジュールテーブルを更新することができる。
【００７４】
インストールエージェント５６は、考慮すべきエージェントのリゾルバリストへのインストール又は収容のための、エージェントに対する要求であるトランザクションに整合している。
【００７５】
Ｗｅｂエージェントの構造及び動作について説明したので、次に、Ｗｅｂエージェントの多数の例証について説明する。そのエージェントの一つは、図４で示したのと類似した個人情報エージェントである。個人情報エージェントは、ユーザとネットワークの対話全てにわたり包括的に動作するドキュメントのモニタ及び情報フィルター（intelligent filter）として働く。例えば、ユーザは単一の包括的の履歴リストを持ったままで、種々の異なったブラウザを種々の異なった場所で使いたいと思うことがある。これは、個人情報エージェントによって実現される。個人情報エージェントは、ネットワーク上のどこにあってもよく、好ましくは、ユーザがＷｅｂ上でドキュメントを見たいと思う全ての位置から到達できる場所にある。Ｗｅｂエージェンシーへの入出力は、通常、ＨＴＴＰであり、ユーザは任意のブラウザを用いてかつ有利な結果を得ることができる。もし、ユーザがＷｅｂのページデザイナーであれば、フォローエージェントを備えたＷｅｂエージェンシーは、ユーザが同時に多数の異なったブラウザを用いてドキュメントを見ることを可能とし、それによって、ユーザが種々のブラウザにおいて、一つのドキュメントがどのように見えるのかの認識を得ることを可能にする。
【００７６】
個人情報エージェンシーは、個人の注釈（これは、エージェンシーがドキュメントを検索する毎に、ドキュメントに付加される）をドキュメントに付加することをユーザに許容する、ユーザのための外部ドキュメントを特別に作るのにも用いることができ、又は参照のための全ての到来ドキュメントを走査することによって、ドキュメントを貯留し、かつ、ユーザの要求がある前に参照されたドキュメントを得るのに用することができる。エージェンシーの追加機能は、また、ドキュメントを検索する際のドキュメント上のボタンとして付加することができる。
【００７７】
Ｗｅｂエージェンシーの別の応用例は、周辺機器，プリンタ６２及びドキュメント一中心ネットワーク間に挿入された図５に示すプリンタエージェンシー６０のような、周辺エージェンシーである。プリンタエージェンシー６０は、ブラウザ６４上でプレビュー頁７０の部分として、プリントプレビユーイメージを表示させるとともに、ユーザから要求されたときに、ドキュメント６６をプリントするのに用いることができる。入力，出力及び蓄積装置により、これらの装置の制御及び環境設定は、ドキュメントを介して、おそらくは、テーブルとフォーム（形式）を含むドキュメントを介して行われる。このようにして、周辺機器は、Ｗｅｂサーバを書き換える（emulate）ことができ、ドキュメントの蓄積又は出力に対するＨＴＴＰ  ＰＵＴ要求及び環境設定フォームのためのＨＴＴＰ ＰＯＳＴ要求のための宛先になり得る。周辺機器は、また、（出力すべきドキュメント用の）ＨＴＴＰ  ＧＥＴ要求及びＰＵＴ又は（ドキュメント入力用の）ＰＯＳＴ要求用のソースである、Ｗｅｂクライアントをも書き換える（emulate）ことができる。周辺機器はまたプロキシとしても使える。
【００７８】
周辺機器と異なり、周辺エージェンシーは、ドキュメント又はドキュメントに対する要求を変換する（即ち、応答を再発送するための一方のクライアントからの要求を他方からの要求に変換する）ことができる。このようにして、エージェンシーは、演算資源とともに、入力装置，出力装置，蓄積装置を管理するため、周辺機器（多くのユーザ）の代わりに活動するユーザ周辺エージェンシーの代わりに動作するより複雑でかつ新規なＷｅｂクライアントを表している。再び、図５を参照すると、プリンタエージェンシー６０は、プリンタ６２へのドキュメント一中心インターフェースを提供するにの用いられている。ユーザがブラウザ６４又はその他を介して、ＴＴＭＬドキュメント６６をプリンダ６２でプリントすることを要求するとき、ユーザは、プリンタエージェントー６０に単にドキュメント６６に対する要求を送り、プリンタエージェンシー６０はドキュメントを獲得し、かつ、それをプリンタ６２上に出現するようにし（即ち、レンダリングの低解像度バージョン）、制御ボタン６８をドキュメントに取り付け、かつ、ドキュメントのプリントプレビューバージョンをユーザに提供する。図５に示すように、ブラウザ６４の出力７０は、“PRINT”，“OPTION”及び“SATATUS”のラベルの付いた制御ボタン６８を含んでいる。“PRINT”ボタンは、プリンタエージェンシー６０によりドキュメント６２をプリンタ６２に送るタグを含んでおり、他方、“OPTION”及び“SATATUS”ボタンは、プリンタエージェンシー６０によって、それぞれオプション選択フォーム及びプリンタステータス頁を提供させるものである。
【００７９】
Ｗｅｂエージェンシーは、標準Ｗｅｂプロトコルを用いて通信するので、全てのエージェント，クライアント及びサーバは共通のプログラム言語，インターフェース又は動作システムを共有している必要はない。このようにして、プリンタエージェンシー６０とブラウザ６４は、それらが異なったプラットフォームにあるとしても対話することができる。実際、ブラウザ６４は、エージェンシーのコンセプトを知らないとしても、プリンタエージェンシー６０と対話できる。プリンタ用の全てのドキュメントは、プリンタエージェンシー６０に送られるドキュメント要求によって、ユーザに提供できるので、周辺エージェンシーは、ドキュメント要求を処理するのに理想的でもある。プリンタエージェンシー６０は、プリンタのロケーションを示すＷｅｂページをユーザに表示することによって、ユーザにプリンタを選択させるような付加的な環境設定タスクを処理することができるとともに、プリンタのクリック自在なマップを含んでいる。
【００８０】
図５に示すように、プリンタエージェンシー６０は、制御装置によって原ドキュメントにはないプリントプレビューページをフォーマットする、すなわち、前述したボタン制御部６８及びページのＵＲＬを表示する制御部を事前に見ることができる。このことは、ドキュメントをプリントしかつプリントを事前に見るため、ユーザがブラウザの一部として設けられたボタンを使用する必要があった従前のブラウザに対する改良である。ブラウザの全てが全てのプリンタを扱うようプログラムできる訳ではないので（現在のところ、真のプレビュー機能を有するブラウザではない）、ユーザはプリントするページそのものを見ることはできないが、ブラウザが仮定したとおりにプリントすることができる。レンダリングを行うプリンタエージェンシーにより、より正確なプリントプレビューが提供され、他方、ブラウザ製造者は多くの異なったプリンタに対してプリンタエミュレータ（printors emulators）をコード化しなければならないことから解放される。プリンタは機能上、ブラウザ又はホストソフトウェアへ変更を加えることなく変更することができる。
【００８１】
プリンタエージェンシーにより、ＨＴＭＬフォーム（又は、該事項に対する任意の他のフォーム）のドキュメントは、プリンタへ送られ、かつ、Postscript及びAcrobat言語のようなページ記述言語の場合と同様に、ドキュメントの著者の代わりにユーザによって提供されるセッティング（調整）によって再生される。ドキュメントをプリンタエージェンシーに移送するのに必要な帯域幅も、それがＨＴＭＬフォーマットであるため減少している。ドキュメントはプリンタエージェンシーに到達したときには、まだ、ＨＴＭＬフォーマットであるので、プリンタエージェンシーはドキュメントに対しある程度巧妙な処理を行うことができる。例えば、ユーザはプリントすべきドキュメントには一以上のレベルのリンクされたドキュメントが随伴すべきことを指示することができる。無限のリンクセットを持つドキュメントに対しては、ユーザはプリントエージェンシーが全てのドキュメントの“巻（book）”をプリントすることを指示することができる。プリンタエージェンシーは、ユーザのクライアントに対し透過性であるので、それは、レンダリング及びプリントのために全ての必要なドキュメントを透過的に検索することができる。プリンティングエージェンシーは、また、内容のテーブルのようなドキュメント流（ストリーム（stream）)の部分として新規なドキュメントを作ることができる。
【００８２】
図６は、プリンタエージェンシーを用いて何を行うことができるかの一例を示している。プリントすべきドキュメントは、Postscriptファイル又はバイナリーファイルのようなレンダリング命令に対するのとは反対に、プリンタエージェンシー６０は、ドキュメントを解釈できない。図６に示すように、ドキュメントは翻訳されかつページの各リンクに機械読み取り可能なアンダーライン８０が付加されている。図５に示すように、これらは、ドキュメントのプリントプレビューバージョンに含めることもできる。同様のシステムが本願の譲受人に共通に譲渡された特許出願番号第０８／３７２，７８４号で示されている。該出願は全ての目的のために引用によってここに編入する。
【００８３】
付録Ａに示すような、Ｗｅｂによって利用できる他の多くのエージェンシーが存在している。これら及び他のエージェント及びエージェンシーをトランスレーション（翻訳ソフト（translation））として使用することができる。
【００８４】
プリンタエージェンシーの形態の周辺エージェクシーは以上で説明された。入力装置用の周辺エージェンシーは、例えば、Ｗｅｂスキャナーとして用いることもできる。入力装置は、入力装置エージェンシーによって、デジタルスキャナー中で走査されるＨＴＭＬドキュメントのソースであると考えられる。ドキュメントのソースとして、Ｗｅｂスキャナーはクライアントに対しＨＴＴＰサーバとして現われる。ドキュメントはＨＴＴＰ，ＧＥＴ，ＰＵＴ及びＰＯＳＴコマンドを用いてソース化（sourced）される。進歩したＷｅｂスキャナーは要求に応じて提供するよう既に走査された全てのドキュメントのリストを管理することもできる。加えて、進歩したＷｅｂスキャナーはデジタルサインを付し、タイムスタンプを押しかつドキュメントを暗号化することができる。
【００８５】
サーチエージェンシーは利用可能なＷｅｂページのサーチを行うエージェントを有するＷｅｂエージェントである。Ｗｅｂのサーチツールは知られているが、しかし、それらは典型的にはサーバ上でローカルに実施するものであって、サーバが見ることができるドキュメントは限られている。サーチエージェンシーによって、ユーザは任意のドキュメントセットのサーチを実施でき、かつ、サーチ結果をカスタマイズするか、又はフィルターエージェント又は他の処理エージェントに対しサーチ結果をユーザへ提示する前に扱わせることができる。
【００８６】
次に、図７は、トランザクションにアクトオン（act on）し、かつ、それを処理するプロセスを示すフローチャートである。このフローチャートにおいて、各ステップはＳ１からＳ８までのステップ数が付されている。プロセスの実行は、ステップＳ１でスタートし、かつ、他の指示する場合を除き数字順の増大に従って進行する。
【００８７】
ステップＳ１においては、一つのトランザクションがトランザクション列２３から出される（図２，参照）。ステップＳ２では、リゾルバがインタレステッドエージェントのリストを得るために整合したリストを走査する。前に述べたように、各エージェントはトランザクションの特徴の機能である基準（critaria）を有している。従って、各エージェントに対して、既存のトランザクションの特徴リストを用いて基準が評価され得る。もし、エージェントの基準に合致すると、該エージェントは、インタレステッドエージェントのリストに付加される。
【００８８】
次に、リゾルバは各インタレステッドエージェントを呼び出す。より詳しくは、リゾルバは各エージェント（Ｓ３）に対するact_on()メソッドを呼び出す。以上で述べたように、act_on()メソッドは新規なトランザクションを追加し、既存のトランザクションを変更し、又は、トランザクションのハンドル列にフックを付加することができる。各インタレステッドエージェントが一度トランザクション上で活動すると、ポインタはトランザクションのハンドラ列中に最初の見出し（entry）をセットする（Ｓ４）。最初のハンドラ列の見出しが現行のハンドラ列見出しであるので、現行のハンドラ列見出しによって、それに向けられたルーチン又はメソッドが実施される（Ｓ５）。トランザクションが満たされると（Ｓ６）、これは現行のハンドラが“true”の値を戻したとき表示され、もはや他のハンドラは呼び出されず、かつ、トランザクションは、トランザクションスタック（stack）から除去される。他方、もし、現行のハンドラ列見出しが“false”の値を戻したとすれば、そのときにはポインタは次のハンドラ見出しへ動かされる（Ｓ８）。トランザクションと協働するデフォルトハンドラ列見出しがハンドラ列の最後に設けられ、かつ、このデフォルトハンドラ列見出しによって指定されたプログラムコードは、常に、“true”の値を戻すので、トランザクションはその満足が保証される。典型的には、デフォルトハンドラ列見出しはエラーメッセージルーチン又はそれと同等のものである。勿論、少なくとも一つのハンドラ列見出しルーチンの連続した完結を保証しない代替実施例は存在し得る。この実施例において、ハンドラ列の消滅後に不満足なトランザクションを処理する代替方法は存在しないであろう。
【００８９】
以上の説明は、例示のためのものであって、限定のためのものではない。本発明の多くの変形例は、この開示を吟味することにより、当業者には明らかとなろう。従って、本発明の範囲は、前記説明を参照して決定すべきでなく、その代わりに、付記する請求項を均等の全範囲と共に参照して決定すべきである。
【００９０】
次に、本発明の理解をより容易にするために、追加の説明を行う。
１．基盤施設（インフラストラクチュア）
Ａ．エージェンシー・テクノロジー：
１）ベーシック・エージェンシー：
ベーシック・エージェンシーは、１つの情報機器をドキュメントソース，ドキュメントトランスフォーマットおよびドキュメントコンシューマとして機能させる、ＤＯＣＳ（ドキュメント用計算機システム）の重要な構成品の１つである。
【００９１】
最初の試作エージェンシーのプロトタイプは、ＣＥＲＮ httpサーバをベースとして使用して構築し、エージェントをＰＥＲＬに書き込んだ。
第２の試作エージェントは、ＰＥＲＬまたはＪａｖａ内に構築した。これにより、特別目的コード（エージェント）をエージェンシーの内部に直接ロードすることができ、効率がよく変更が容易になる。２つの実験エージェンシー、即ち、perlwwwライブラリとJigsawJavaサーバーを構築したことは実際最良の選択であったろう。
【００９２】
エージェントを走らせるには、幾つかの異なる方法があり、複数のエージェンシーを有することにより下記の利点が生じる。
＊  エージェンシーとしてのエージェント：ＰＥＲＬまたはＪａｖａのいずれかにエージェントを書きことができるので、複数のエージェントを持つことをこの場合有効である。
＊  エージェンシー内部のコード断片としてのエージェント：複数のエージェンシーを有することにより、ＰＥＲＬまたはＪａｖａのいずれかを使用すことができる。
＊  ＣＧＩ（共通出入口のインターフエース）スクリプトとしてのエージェント：ドキュメント上で複数のエージェントを走らせてドキュメント自体を変更させたいという願望がより複雑なＣＧＩスクリプトと成り得る。
＊  フィルタとしてのエージェント：これにより、パイプを発進しドキュメントを発送することができるエージェンシーを要求したりまたはそれを通じて要求することができる。
＊  観覧者としてのエージェント：エージェントは、コマンドライン上でドキュメントを含むファイルの参照を許可されるプログラムである。
【００９３】
２）物理的なエージェンシー（WebWart）：
WebWartの名称は、〈Wall Wart（壁のこぶ）〉に由来し，壁のソケットに差し込む給電プラグを意味する。公式名称は、〈Peripheral Interface Agency（周辺インターフェースエージェンシー）〉または〈Ｗｅｂ Periphera Interface（ウェブ周辺インターフェース）〉等である。このWebWartは我々にエージェンシー制に基づき周辺機器を納得のいくように実演させることを許容する。WebWartは我々が周辺機器を取り付けるエージェンシーの物理的な実施態様である。
【００９４】
最も簡単な場合、試作WebWartはディスプレイのない小ちい箱に入ったＰＣ（パーソナルコンピュータ）であり、価格は、ＲＡＭ（ランダムアクセスメモリ）と計算能力によるが５００ドルから１０００ドル程度である。これらの製品は、ＩＰアドレスとホスト名等をＨＴＴＰを介して設定できるようにする小規模なソフトウェアを有し、ＰＣと区別するために独特な色に塗装する。可搬式WebWartは、若干高価で、リコー（日本）よりラップトップ又はパームトップ型機器としてディスプレイなしで供給される。形状及び目標価格範囲は、プリンタ用追加ネットワークインターフェースのような形状で、３００ドルから５００ドルの範囲内の価格である。
【００９５】
最終的には、WebWartは、現実の製品として、ＰＣＭＣＩＡカード（Ｗｅｂカード）からラックマウントに至る広範な寸法の製品であり得る。理由は２つある。
１．従来の周辺機器とつないで使用する。
２．実験室機器のような特別目的の周辺機器と接続して使用する。
３．WebWart製品は、ＰＩＡおよびＷｅｂファイルの物理的な実施態様である。
３）縮尺可能なエージェンシー：
最小レベルの縮尺可能なエージェンシーは、カメラ，キーボード，ページャ（マジックペンも同様）と同じ程度に小型なネットワーク装置に組み込むことができる非常に軽量なエージェンシーで有り得る。シングルスレッド式であり、簡単なプロとコールを使用し、ＭＩＭＥタイプの制限セットを使用することができる。これは、通常、小型固定式エージェントにのみに接続する。
【００９６】
次のレベルは、通常、ＰＩＡとして働く中間重量エージェンシーであり得る。これは、マルチスレッド式で、ディスク，ネットワーク及び広く種々の言語で書かれたエージェンシーに接続できる。
【００９７】
最高のレベルの縮尺可能なエージェンシーは、ペンティアム搭載パソコンからイカルスまでの範囲のハードウェアで稼働できる、アパッチ（Apache）スケールの大サーバエージェンシーである。
【００９８】
１つのエージェンシーは、単一プログラムというよりは、アーキテクチュアであり、Ｃ、Ｃ＋＋、Ｐｅｒｌ及びＪａｖａを含む種々の言語でのエージェンシーを生み出すことが可能でなければならない。エージェンシーが共通のコードベースを共有することができない場合でも、（ＩＤＬで規定できる）インターフェース及び／または各クラスの共通セットを実行可能なように共有できる。
【００９９】
埋め込みエージェンシー：
WebWidgets、WebWindows及びWebCardsのようなものを可能にする技術は、小さな（tiny)埋め込み可能なエージェンシーである。埋め込み可能なエージェンシーは、電力消費量が小さく、簡単な近距離無線インターフェースを有し、広範囲の単一ハードウェアに接続できることが必要である。
【０１００】
プロトタイプの場合、データ（ドキュメント）と同時にコード（エージェント）をロードする能力を有する必要がある。これは、機密保持のために何らかの方策を実施せねばならないことを意味している。エージェントをドキュメントとしてパッケージすることにより、インストールの方法を容易にする。
【０１０１】
１６ビットのコントロールチップシリーズの１つを、特に、エージェントが少なくとも１メガバイトの各コード及びデータにアクセスする能力を有している場合に使用する。エージェンシーを１２８Ｋに圧縮することは難しいが、可能とすべきである（WebFile WebWalletは、Linuxと標準ＰＩＡアーキテクチュアを用いてインテル社のチップに実装することが可能である。インテルのラップトップ型ＣＰＵモジュールを用い、WebWalletのプロトタイプとすることも可能であろう）。
【０１０２】
Ｂ．ドキュメント指向の計算：
１）インターフォーム（InterForm）：
インターフォーム（インターフェース・フォーム）は、プログラムをＨＴＭＬのユーザ・インターフェースのフォームと、ユーザレベルドキュメントと実行レベルドキュメントの双方と結合させる単一ドキュメントである。
＊  埋め込みコードフラグメント、例えば、〈コード言語＝ＰＥＲＬインターフェース＝ＣＧＩ〉を持つＨＴＭＬドキュメント。
＊  オンザフライでＨＴＭＬを生成する適当なツールキットを持つ種々の言語でのコード。
＊  適当なMakefileを持つ混成ＨＴＭＬ及びコードを内容とするディレクトリ、かようなディレクトリは、.tarファイルに束ね、適当なＣＧＩインターフェースを用いＨＴＴＰを介して送り出すことができる。取り込みすべて適当なインデックス.htmファイルである。“クライアント”端では、エージェンシーのファイル内の正しい場所にかようなパッケージをインストールするための機構を必要とする。“インストール・エージェンシー”はこのために使用する。
【０１０３】
２）ＤＯＦＳプロトタイプ：
エージェンシーは、恣意的な名前の属性をドキュメントと結合させるために拡張したドキュメントのキャッシュ記憶装置を必要とする。このキャッシュ（cache）記憶装置は、WebFileのためのプロトタイプ・ファイルシステムとして使用できる。
【０１０４】
最良の実施例の場合、各ドキュメントは、原ドキュメントと任意の要求追加ドキュメントの両方を含む１つのディレクトリにより代表されるようにする。１つの結果として、キャッシュをＷｅｂプラウザで表示する際に、原ＵＲＬと全ての随伴情報の間に簡単明瞭なマッピングを存在させる。ドキュメントの構文解析ツリー表現を使用することができる。その場合、マップファイルは、各記憶ドキュメントを伴う。
【０１０５】
３）ドキュメント指向ファイルシステム（ＤＯＦＳ）：
より長期には、テキストを含むファイルシステムから構文解析ツリーを含むファイルに移行させたと考える。本来、テキストは、常に、以前から受け継がれてきたアプリケーションによって使用でき、ネットワークで送信される。
【０１０６】
これには２つのバージョンがある。
１．Ｕｎｉｘファイルシステムに保管されるように設計したＤＯＦＳ。
２．専用ディスク，区分ディスクまたはファイルに保管されるように設計したＤＯＦＳ。
【０１０７】
ＤＯＳファイルシステム上でＤＯＦＳを働かせることは、制限が大き過ぎるので、実際的ではないであろう。しかしながら、専用区分バージョンは、ウィンドウズのスワップファイルのように、大きなＤＯＳファイルに容易に保管できた。動的ファイルを持つために、任意レベルのノードをコードで置き換えられるようにすることが必要である（これは、非常に〈Self〉に似ている）。
【０１０８】
表示については幾つかの可能性がある：
１．マップファイルを伴うテキストファイル。これは、
・生テキストを検索するには最速で、
・非常にコンパクトであり、
・シークを用い非常に大きなファイルを取り扱うことができ、
・バッファされない限り低速ランダムアクセスとなる。
２．前記ノードにおいて、２値である直線化した構文解析ツリー。これは、
・構文解析ツリーをメモリに格納するには最速であり、
・バッファされないランダムアクセスは最低速である。
３．ＯＯＤＢ：
・スパースランダムアクセスの場合早く、
・順次、アクセスは最低速で、
・コードヒットが大きいが、
・高価である。
４．ＤＯＦＳ（ドキュメント指向ファイルシステム）：
・徹底したカスタムデザインで、
・特に、構文解析ツリー向きのファイルシステムで、
・httpからワードに一様にアドレスでき、
・小さなファイルを持つ従来のファイルシステムと見なすことができ、
・…又は〈凍結〉リストの処理機またはSelfに似たバーチャルメモリと見なすことができる。
【０１０９】
テキスト＋マップのオプションは、最初のよき妥協解であるように見え、下記の利点が追加される：
＊  マップはプラットフォーム依存２値式とすることができ、
＊  従来のソウトにはインパクトを与えず、
＊  テキストからマップを容易に再構築でき、
＊  そのファイルが変更できなければ、放棄することができ、
＊  ファイルとマップを別々に圧縮することができる。
【０１１０】
前記ドキュメント指向ファイルシステムは、現存“ＷＷＦＳ”に類似のインターフェースを有し、このインターフェースにより前記Ｗｅｂにそれがファイルシステムであるかのようにアクセスすることができる。
例えば、選択子の構文（Syntax）が実働化（implementation）に依存するドキュメント範囲において、〈ＵＲＬ＃＃selector〉を使用してアドレス指定をすることができる。
【０１１１】
４）ドキュメント指向プログラミング言語
ドキュメント指向プログラミング言語は、下記の２通りの異なる方法でドキュメント指向にする。
１．ＳＧＭＬのようなシンタックスを持ち、ドキュメントに容易に埋め込めるようにする。
２．ドキュメント上で直接働く、即ち、ドキュメントが第１類値（first-class value）となる。
この言語は、ＬＩＳＰまたはＳｅｌｆにかなり似ている。即ち、ＬＩＳＰ（リスト処理言語）のようにプログラムとデータが同一の表現を有しＳｅｌｆのようにデータが属性値のリスト構造を有する。
【０１１２】
Ｃ．エージェント・テクノロジー：
エージェントは勿論、Interformsとして実現でき、ドキュメント指向ファイルシステムに記憶できる。本節では、特殊エージェントについて説明する。
【０１１３】
１）WebWidgetインターフェース：
WebWidgetはＷｅｂ使用可能な入力装置である。これはクライアントに似ており、何らかのイベントが発生した時に予め定められたURLにドキュメントを転記(ＰＯＳＴ)するように設計されている。
WebWidgetは下記を含んでいる。
＊  押しボタン（シングルビットを入力する）。
＊  キーボード（シングルキャラクターを入力する）。
＊  キーボード＋１ラインディスプレイ（文字列を入力）。
＊  タッチスクリーン（座標を入力）。
＊  カメラ／スキャナ（イメージ及びそのパラメータを入力）。
＊  マイクロフォン（音声流を入力）。
＊  ビデオカメラ（ビデオ＋オーディオを入力）。
＊  ＧＰＳ受信器（座標を入力）。
【０１１４】
２）WebPrinting：
Ｗｅｂプリンタおよび幾つかのＷｅｂウインドウズのようなページ装置を働かせるために、ＨＭＴＬレンダリングは、下記のようにアドレスを指定する必要がある。
＊  ページ付けとページレイアウト。
＊  スタイルシートの適用。
＊  高速，低速レンダリング。
＊  マルチファイルドキュメントの平面化。
＊  ポストスクリプト，アクロバット及びその他の専有のフォーマットを埋め込みイメージまたは然るべきＭＩＭＥタイプ付き全ドキュメントのいずれかとして処理する。
＊  オプション（InterFormのデザイン）の指定。
【０１１５】
３）オブジェクト・インターフェース：
これは、ＣＯＲＢＡ及びＯＬＥオブジェクトに対するインターフェースを提供する。このオブジェクト・インターフェースは、〈ライブドキュメント〉と対応するサーバ側コード（必要ならばクライアント側コード）を自動的に構成し、任意のオブジェクト・インターフェース名を与える。
【０１１６】
この問題に関しては、実際に幾つかのアスペクトがある。
＊  実行時間インターフェースを使用し、オンザフライ式印刷のフォームを構成し取り扱う。
＊  ＩＤＬ記述を前処理して当該フォームを翻訳（Compile）する。
＊  ドキュメント指向インターフェースフォーム（IntrForm）の総称マークアッフをオブジェクト指向オープンドキュメント（OpenDoc）部分とコンテナに併合する。
【０１１７】
Ｄ．その他のテクノロジー：
１）BodyWeb：
多くのアプリケーション（例えば、WebWallet，WebCard，WebPAD）は、小電力，短距離（１メートル半径），高帯域幅（１００メガビット／秒）のローカルネットワークから恩恵を受ける。かようなネットワークは、携帯または座席の近辺で使う物にはすべて接続できる。使用できる２つの技術は、（ゼロックスが偏在計算プロジェクトで使用している）誘導結合であり、また、無線（radio）である。赤外線は見通し線の問題があるので、ポケットに入れることができない。超音波は帯域幅と干渉の問題がある。スペクトル拡散無線がベストであろう。
【０１１８】
２）ライブドキュメント：
ライブドキュメントは、発行数を高める。
＊  ライプドキュメントのフレームワークの構成方法は？
＊  ライブドキュメントを作成するのに必要な道具（tools）は？
＊  例えば、CORBA ILDの仕様書からライブドキュメントを自動構成できるか？
＊  ユーザに提供しなければならないツールは？  編集及びカスタマイズするためには任意のテキスト・エディタを用いることができるが、幾つかの選択商品から適したものを選択できる筈である。
＊  ライブドキュメントを働かせるために、サーバ側に必要なＤＧＩは？
【０１１９】
２．アプリケーション：
Ａ．エージェンシー：
１）個人情報エージェンシーとエージェント：
個人情報エージェンシー（ＰＩＡ）は、他の場所で説明するが、構成用の僅かなインターフェース・フォーム（Interforms）とキャッシング，注釈，一時記憶装置及びエージェントの記憶装置に用いられるドキュメント指向ファイルシステム（ＤＯＦＳ）を有する簡単なエージェンシーである。
【０１２０】
２）ＰＩＡエージェント：
エージェントも他の場所で説明するが、殆どのエージェントは簡単で、その多くは、ワン・オフ・ハック（One-off hacks）のように、特別に書かれ、そのＵＲＬを回って交換される。
【０１２１】
３）WebFile:
Ｗｅｂファイルは、専用ドキュメントセーバである。なお、バージョンコントロールのためにＣＶＳを使用する選択権をユーザに付与しなければならない。また、機密保護のための暗号を含まねばならない。好ましくは、全ての構成を、Ｗｅｂを使用して行うことである。ＣＶＳリモートアクセスセーバを変更し、Ｒｓｈの代わりにＨＴＴＰを使用するようにすれば有益である。ドキュメントをＷｅｂファイルに取り込む好ましい方法は、代理権を与えて、Ｗｅｂファイルをキャッシュとして有効に使用することである。
【０１２２】
プロトタイプのＷｅｂファイルは、大ディスクを持つWebWartである。プロトタイプ用ソフトウェアは、若干ありふれたものではない。以下のことを実行する必要がある。
＊  ネットワークの管理（ＩＰアドレス，マスク，ゲートウェイ，ノード名等）。
＊  ファイルの操作（ＰＵＴ要求，ＵＲＬからのコピー，改名，削除等）。
＊  リンクの保守（ファイルを移動させる時のリンクの改名等）。
＊  バージョンコントロール（Jigsaw WebサーバはすでにＣＶＳをサポートを有している）。
【０１２３】
４）WebCD-R：
WebCD-Rは、ＷｅｂファアルとＷｅｂプリンタの間のある交点である。全てのＷｅｂサイトを含むドキュメントをその中にロードし代理権を与える。ドキュメントは、次に、ＣＤ−Ｒに書き込むことができる。ＣＤ−Ｒの内容は、本質的に代理キャッシュのイメージでなければならない。ＣＤ−Ｒは、次に、代理サーバを使用して走査され、キャッシュの日付と現在の日付と比較し、ネットワークから変更されたページを得る。
【０１２４】
ソフトウェアの必要条件は、プリンタまたはファイルサーバのいずれの場合よりもかなり簡単であり、その理由は次の通りである。
＊  ファイル操作の必要がない。
＊  バージョンコントロールの必要が全くない。
＊  プリンタの場合よりかなり“スタイル”パラメータが少ない。
＊  ｍｋｉソフトが既に存在する。
一方、代表的な実施例の場合、ソースツリーと宛先.isoファイル用に少なくとも１５００メガバイトのディスクを必要とする。
【０１２５】
５）WebCard：
これは、近距離高帯域幅無線または有線ネットワークへのリンク付ＰＣＭＣＩＡサイズのエージェンシーであり、デジタルカメラ及び掌上型のような現存ＰＣＭＣＩＡ装置をＷｅｂ装置として機能させることができる。このＷｅｂカードはまた小さなポータブル型のＷｅｂファイルとして独立して機能でき、例えば、感知可能データ，デジタルキャッシュまたは個人の識別用のカードとして機能できる。１つの可能な実施例の場合、ＰＣＭＣＩＡのII型フォームファクタとコネクタを有し、フラッシュメモリと充電可能なバッテリを付属させている。また、前記ＰＣＭＣＩＡコネクタより低い帯域を有するＩｒＤＡまたは誘導リンクを持つこともでき、これはスロットとコネクタを必要としない。
Ｗｅｂカードは、より多くのパワーを与えるための“マイクロドッグ”と、イーサネット接続用のスロットとモデム，ページャ，オーディオ，カメラ又はディスク用のスロットを有することが望ましい。
【０１２６】
６）WebWallet
これは、Ｗｅｂファイルの“ノートブック”バージョンである。小形であるが、ＰＣＭＣＩＡサイズではない。実際には、１個のＰＣＭＣＩＡスロットを持つことが好ましい。軽量でバッテリ式でなければならない。シングル・ユーザであれば、ＰＩＡとしても機能する。
【０１２７】
特別仕様として、下記を有することができよう。
＊  ２.５インチ１ギガバイト（予想）の内蔵ディスク。これは、ユーザが完全に個人の場合には十分である。
＊  充電式バッテリ。バックライト式ディスプレイがなく、大電力のＣＰＵが不要であり、ディスクを連続運転しないので、バッテリの寿命は良好である。セルーラ電話のバッテリを使用するのも良い選択である。
＊  ＰＣＭＣＩＡのII型スロット。このスロットは、WebPad，ＲＤＣ−１フラッシュカード，イーサネツト，モデム，カメラ等に使用される。
＊  ＩｒＤＡ誘導リンク。
＊  オーディオ入出力用コネクタ。
＊  高速デジタル入出力装置（多分Fireire）。
＊  モダムまたはリコーネット用直列ポート。
＊  ベルトフックまたはパウチ。WebWelletはカメラまたはパーソナルステレオパウチに挿入できなければならない。
【０１２８】
WebWelletは、ネットワークへの接続に使用できる小形で安価な充電器／ドッキングステーションを必要とする。これは、携帯電話用ベースステーションというよりは受け台であり、または、ユーザ側で何らかの作業または手探りを要するものではなくて、パイロットＰＤＡの受け台であることが必要である。このアイディアは、ユーザがノートブックまたはハンドバックを持って行くのと同じように、WebWelletをどこにでも持ち運べるようにするためである。近距離無線リンクが十分な帯域幅を有している場合は、夜間を除いて受け台に置くことも必要としない。
【０１２９】
使用には、下記を含む。
＊  WebCard及びWebPAD用ドック充電器。
＊  ＲＣＤ−１写真アルバム。
＊  デジタルスクラップブック。
＊  ノートブック（Ｗｅｂウィンドウズ付）。
＊  ＰＡＤ用バックアップ。
＊  デジタルカメラ（ＰＣＭＣＩＡカメラ付）。
＊  ＣＤ品質オーディオレコーダ／プレーヤ。
＊  電話（受話器とセルーラ又はリコーネットモデム付）。
【０１３０】
写真アルバムであることに加え、WebWelletは、ＰＤＡに用いられているような他のＰＣＭＣＩ３１モリカードと一緒に使用できる。WebWeltは、ユーザのドキュメント階層構造中に配置させる前記カードボリュームＩＤを使用することができ、ロード，アンロードまたは前記カード上のファイルと同期するようにプリセットすることができる。
【０１３１】
Ｂ．周辺機器：
１）WebPrinter：
このＷｅｂプリンタは、
＊  ＨＴＭＬを直接印字し、
＊  それ自身のＨＴＴＰの要求をなし、
＊  シームレス走査検索，印字およびプレビュー用プロキシとして使用でき、
＊  印刷またはプレビューするドキュメントの問い合わせ列を与えられるＣＧＩを有する。
【０１３２】
ハードウェアのプロトタイプは、リコーのレーザプリンタとWebWartを用いて構築することができた。各プリンタのホームページへ導くクリック駆動式マップを設けることができる。最終記録（Last-minute）の走査及びフォーマットの引き出し（tweaking）のために各Ｗｅｂプリンタの次にＷｅｂウィンドウズを持つと有益である。〈コントロールパネル〉上に幾つかのプリンタソフトを置くことにより、実際に上手く工夫（cheat）できた。勿論、最終的には、ＭＦＭのスキャナ，プリンタ，ファクシミリ，複写機，ＩＭ３等のＷｅｂで実行可能な完全セットを持ちたいと望んでいる。
【０１３３】
２）WebWindows：
実際のWebWindowsは、プラウザではない！  それは、完全に成熟した情報機器であり、基本的にはサーバのようなものであり、ＰＩＡと密接に稼働するように設計されている。従って、従来のオラクル／サン／アップル／のどのネットワークコンピュータとも全く異なるものである。
【０１３４】
Ｗｅｂウィンドウズは、ＰＩＡとのみ稼働するように設計されている。かように、その〈プラウザ〉のアスペクトは、最小限に削減されている。ＰＩＡはＷｅｂウインドウズと、ＧＥＴ要求に応答するだけでなく、ＰＵＴ要求を送ることにより、相互作用する。Ｗｅｂウィンドウズは、かなりの程度、Ｘサーバに似たディスプレイサーバまたはＷｅｂプリンタとして機能する。この結果、Ｗｅｂウィンドウズは、オプション・メニューまたは他の構成情報を必要としない。即ち、連携ＰＩＡからすべてを取って来る。Ｗｅｂウィンドウズを任意の人数のユーザで使用することも容易である。即ち、ユーザはＰＩＡにログ・インするだけでよい。
【０１３５】
ハードウェアとして、独立型Ｗｅｂウィンドウズを、通常、WebWelletまたはＰＩＡを走らせるＰＣと共に使用する。その他の機器、例えば、Ｗｅｂプリンタと結合したＷｅｂウィンドウズは、現在のユーザのWebWelletを使用し、識別と状態情報を得ることができる。Ｗｅｂウィンドウズは、ネットワーク・コンピュータよりもディスクの必要度は低い。Ｗｅｂウィンドウズは、サーバをすでに内蔵しているので、ＰＩＡと容易に一体化することができる。設計書は、Ｗｅｂウィンドウズのための要求事項の規定と最良の使用法の図解を含んでいる。
【０１３６】
３）WebWindows Mock-up：
Ｗｅｂウィンドウズのモックアッフは、Ｗｅｂウィンドウズではない。Ｗｅｂウインドウズ・モックアップは単純であり、ＧＩ２００またはＷｅｂプラウザを実行するシンクパッド（ThinkPad）である。大衆を説得するために役立つので重要である。ＧＩ２００はリコーにより製造されている事実が説得を助けている。
【０１３７】
追加作業を必要とするのは、下記の通りである。
＊  ＧＩ２００にLinuxを設置する（但し、ＰＩＡを稼働させたい場合）。
＊  プラウザのＰＩＡに接続する。
＊  ２つのウィンドウズを有効に利用する。即ち、１つを作業に（Pushing to）に、もう１つを検索に使用する。
＊  ＧＩ２００を他の機器（例えば、プリンタ）にコントロールパネルとして取り付けることができるように、エレガントな（物理的）支持ブラケットを作製する。
【０１３８】
残念ながら、ＧＩ２００はかなり高価であるので、他の可能性を考慮する必要がある。ＰＣ−１１０はその１つである。即ち、Linuxを実行できることは知られており、（ある場合には有効な）キーボードを有している。新ザウルスＭＩ−１０がもう１つの可能性である。これは、明らかに６６ＭＨｚ４８６カラーディスプレイ，ウィンドウズ９５及びＷｅｂプラウザを有している。
【０１３９】
４）WebImager：
Ｗｅｂイメージャは、イメージ用のＷｅｂ入力装置である。この装置は下記を実行しなければならない。
＊  指定ＵＲＬにイメージを置くかまたは記入する。
＊  イメージの移動トラックを維持する。
＊  環境設定用エージェンシーを使用する。
当然、これはWebCam，ＲＤＣ−１及びＩＭ３と密接に関連する。Ｗｅｂイメージャは、フラットベッド式スキャナ，ファックカモデム，コネクチック・カメラまたはＲＤＣ−１フラッシュカードを入力装置として使用できる。ユーザ・インターフェース・ソウトウェアはいずれの場合も同じである。低レベル・キャプチャ（captuere）ソフトのみ異なる。
【０１４０】
５）WebPAD：
これは、ポケットサイズのシングルユーザ用Ｗｅｂウィンドウズである。これは、研究用というより物理的なプロトタイプのパッケージデザイン用のものである。実際の研究は、それの使い方を研究することから始まる。WebPADによる実験方法は、ＣＲＣにおいて、各人に１個のWebPADを装備、何が開発されるかを見る。ＵＳＲのパイロットＰＤＡを使用してプロトタイプ化することも可能である。特別に、下記を想定する。
＊  ３ｘ５インチを越えないサイズ。
＊  フラッシュメモリ。
＊  ＩｒＤＡまたは誘導リンク。
＊  タッチ式液晶ディスプレイ，小形スピーカ。
＊  再充電可能なバッテリ。
【０１４１】
ＰＣＭＣＩＡコネクタは、ラップトップ，マイクロ・ドックまたは高速接続用WebWalletに挿入することができる。マイクロ・ドックは電力を上げ、イーサネット接続用スロット，モデム，ページャ，オーディオ，カメラまたはディスク用のスロットを提供する。液晶ディスプレイは、下記の幾つかの機能を有している。
＊  デフォルト：ディスプレイ“ビジネスカード”。
＊  機密保持のために署名を用いる。
＊  交換データ量をコントロールする。
＊  制限データエントリのようなＰＤＡのアスペクト。
WebPAD-WebCardの組み合わせは、下記のように機能できる。
＊  デジタル財布／小切手帳／クレジットカード。
＊  ビジネスカードホルダー（日本の慣習である名刺交換に最適）。
＊  名札／バッジ／キー。
＊  個人データ（名前，住所，病歴等）の保管。
＊  時計／カレンダー。
＊  計算機。
【０１４２】
６）その他の機器：
その他の機器には、WebScanner,WebCam,WebFAX及びWebMFMが含まれる。WebFMFは完全にＷｅｂで実行可能で、ＩＭ３，プリンタ，スキャナ，ファクシミリ等と組み合わせて一体化できる。さらなる研究により、印刷ドキュメントの書式を、そのドキュメントを入力装置（ライブペーパ）として使用できるようなフォーマットする方法を知べる。WebFAXの技法はかなりの処理を要する。処理を軽減するためには、下記を必要とする。
＊  全てのリンクをＵＲＬとドキュメントタイトル（既知の場合）及び最終に修正した日付を含む脚註としてフォーマットする。
＊  各脚註の隣にチェックボックスを置き、脚註番号用の小さなバーコードをつける（オプションとして、これらのチェックボックスを行にフォーマットして脚註を削除するかあるいは全ての脚註を最後の単独頁に置くことが可能である）。＊  ２Ｄのバーコードを、ヘッダ，フッタまたはマージンに置き、開始脚註番号と（１）ページの完全なＵＲＬとタイムスタンプまたは（２）プリンタのＵＲＬとハッシュコードのいずれかを付ける。
【図面の簡単な説明】
【図１】  ドキュメント指向コンピュータシステムにおいて、色々なＷｅｂクライアントとサーバ間に挿入された本発明によるエージェンシーのブロック図である。
【図２】  単一のＷｅｂエージェンシーとその内部構造のブロック図である。
【図３】  Ｗｅｂエージェンシーを通してＷｅｂクライアントからＷｅｂサーバへのドキュメントの要求のサンプル要求フローのブロック図である。
【図４】  図３の要求フローよりも複雑なサンプル要求フローのブロック図である。
【図５】  Ｗｅｂプリンタエージェンシーに合わせて環境設定されたＷｅｂエージェンシーのブロック図である。
【図６】  本発明によるＷｅｂプリンタエージェンシーを用いて好適に印刷された、機械読み取り可能なアンカーリンクで印刷されたハイパーテキストページを図示したものである。
【図７】  トランザクションに作用しかつ処理する方法を図示したフロー図である。
【図１】
0003719825.tif 000004
【図２】
0003719825.tif 000005
【図３】
0003719825.tif 000006
【図４】
0003719825.tif 000007
【図５】
0003719825.tif 000008
【図６】
0003719825.tif 000009
【図７】
0003719825.tif 000010