JP2002515156A

JP2002515156A - ダイナミック・クライアント・レジストリ装置及び方法

Info

Publication number: JP2002515156A
Application number: JP54590398A
Authority: JP
Inventors: エイ．バットマン、ロナルド; ラマチャンドラン、ラジャ; エイ．バーンズ、トーマス; ジェイ．マローン、トーマス; ディ．クミーク、マイケル; シー．ドウティ、ジョセフ
Original assignee: ピーエフエヌテクノロジーズインコーポレイテッド
Priority date: 1997-03-24
Filing date: 1998-03-24
Publication date: 2002-05-21
Also published as: AU6770198A; EP1019850A1; WO1998043184A1; US6026430A

Abstract

(57)【要約】異なるネットワーク上のクライアント・エンティティからの情報を組織化して選択的に共有するためのレジストリが、ダイナミッククライアント・レジストリ（０７）と、関数名を含むリソース・ロケータとを格納するためのディスク（０８）を有する第１コンピュータと；指示された関数名をロードすることにより第１コンピュータをリソース・ロケータに反応させるウェブ・サーバと；ダイナミッククライアント・レジストリを組織化するためのデータベース管理プログラムとを有する。このシステムは、また、ドメイン・通信サーバを含む。ドメイン・通信サーバは、ウェブ・サーバにより用いられて、ウェブ・サーバに向けられたリソース・ロケータに反応し、かつ、ダイナミッククライアント・レジストリの組織化においてデータベース管理プログラムを管理する。このシステムは、また、第１のコンピュータとネットワークで結ばれた幾つかの第２コンピュータを有する。第２コンピュータの各々が、ダイナミックグループレジストリと、関数名を含むリソース・ロケータとを記憶するためのディスクを有する。第２コンピュータは、また、指示された関数名をロードすることにより第２コンピュータをリソース・ロケータに反応させるウェブ・サーバと、ダイナミックグループレジストリを組織化するためのデータベース管理プログラムとを有する。

Description

【発明の詳細な説明】ダイナミック・クライアント・レジストリ装置及び方法技術分野本発明は、概略、ネットワーキング・コンピュータ・システムの分野に関し、特に、異なったネットワークを横切る情報の配給、再配給、アクセス・セキュリティ、フィルタリング、組織及び表示に対する制御を提供するためのシステムの分野に関する。背景技術今日、殆どの産業及び職業において、会社相互通信及び会社内通信の必要性が急速に高まっている。殆どの会社、企業及び機関は、就業日を通して、従業員が、内部では他の従業員と通信し、外部では、企業の顧客、売主、情報源等と通信することができることを望んでいる。情報の本質及び当事者間の関係に依存して、これらの通信は、或る場合には１対１のコミュニケの形態を取ることが必要であり、他の場合には１対多数の一斉通信の形態を取ることが必要であり、多数対多数の通信、及び多数対１の通信の形態さえ取ることが必要である。これらのカテゴリの幾つかは、データの流れが相互作用的かつ協力的である場合には、全ての関係者にとって良好な情報を提供するかも知れず、レシピエントが、既に受領したものにコメントし、共有し、そして創設することを可能とする。現在のところ、このような大量の通信を容易に成就し管理することは困難でありかつ費用が嵩み、特に、極度に敏感で、機密的であり、独占的である情報が、内部だけではなく、これらの会社によって考慮されたビジネスパートナーに対して外部にも選択的に通信されなければならない場合にはなおさらのことである。金融産業、例えば、出資銀行は、その出資管理企業のすべてのクライアントに時間的に敏感な情報を通信し、彼等にそれに関するコメントを与えるが、その間、銀行の競争相手がその情報にアクセスすることは確実に阻止することを望むかもしれない。また、出資銀行は、その独占情報の配給を提供している同じネットワーク上で、金融ニュース・サービスの売主からニュース供給、並びにそれを選択した他の第三者の売主からの分析や独占リポートを受けることを望むかもしれない。１０年もしくは１２年前、このような通信を扱うツールは、概して、電話、ファクシミリ、オーバーナイト・メイル、より最近では電子メールに制限されていただろう。これらのメディアの各々は、制限を有しかつ欠点がある。オーバーナイト・メイルは費用が嵩み、或る種の情報に対しては非常にゆっくりしている。電話は、勿論、非常に早いが、多くの電話による会話は１対１の通信に制限され、その理由は、電話は、パートナーが同時に通信することを必要とする同期形態の通信であるからである。これは必ずしも効率的ではない。出資会社が１対１ベースでクライアントに市場分析リポートを送信するためには、プロセスはゆっくりで厄介であり、或るクライアントが情報を取得してから長い間経ってから他のクライアントが情報を得るということが避けられない。或る電話会議呼出しは、幾人かのクライアントが略同時刻に同じ情報を取得するのを確実にし、かつ或る会議呼出しは相互作用的であり、それ故、種々のクライアントからのコメントが表現され得る。しかしながら，会議呼出しの人の数が或る臨界量を超え始める場合には、その呼出しは、救い様のなく混乱し得る。他のクライアントの声が、例えば出資会社の分析者の声と間違われ得る。いずれの型の音声電話による情報通信においても、レシピエントは、詳細を覚えるためにノートを取るか、またはその日の後で、分析者のところに出かけて行かなければならない。情報がタイムリーであるだけでなく、後で参照するために精密かつ正確に記録されることが必要である場合には、音声電話による会話はあまり適切なものではない。現代のファクシミリ機械は、選択されたクライアントのグループに対し、電話線を渡って情報を一斉通信することを可能とし、また、チャートやグラフ並びに他の画像を送信することを可能とする。これは、また、後で参照するためにクライアントに正確な記録を与える。しかしながら、ファクシミリ送信は、相互作用的ではなく、従って、提供されているかもしれない何等かのクライアントのコメントが失われる。ファクシミリ送信のレシピエントは、通常、ハードコピーだけを有し、受信用のファックス・モデムを使用しない場合は、情報の電子コピーは有さない。従って、このような送信が共通のファックス機械もしくはメール室に入って来て、個々の人に届くまでに数次間かかる場合には特に、レシピエントに対する利用性は相当に下げられ得る。内部共同ネットワーク間のゲートウェイを通って送られる電子メールは、しばしば遅く、普通のテキストフォーマット（通常添付として送られるビジュアル情報を有することがある）及び固定データのようにして送られる電子メールは通常インデキシングされていない。その結果、電子メールメッセージのストリームに望まれる又は必要とされる情報を見つけだすことは、長い時間がかかる。受領者は、同じコンピュータソフトウェア及びハードウェアを使用しない限り、添付した物を使用したり又は見たりすることができない。多くの会社や施設では、内又は外への添付物をメッセージとしてＥメールすることは秘密上の理由により許容されないであろう。Ｅメール技術は本質的には、同じネットワーク上で同じ文書の多くのコピーを必然的に生成する格納及び発送プロセス、即ちネットワーク資源の非効率的な使用である。これらの問題に遭遇によって、プラーベートに内部に分配されたコンピュータ及び電気通信ネットワークを有する会社及び施設は、会社内通信を取り扱うために別のアプローチをとる。キービジネスパートナーと通信するために独立し、孤立した外部ネットワークを構築することにより、会社自身の内部ネットワークからの選択された顧客及びベンダーの情報が得られる。会社の内部ネットワークから選択された情報は、特別の外部ネットワークに送られ、続いて取引パートナーに送られる。このことは、多くの文書及びファイルを外部ソースへ及びから秘密形式で転送することができる。しかしながら、もしそのようにすることを全ての顧客及び全てのベンダーに対して望む投資銀行のような施設がある場合、費用及び複雑さが劇的に増大する。もし、投資銀行がある一つのタイプのコンピュータシステム及びネットワークソフトウェアをその内部及び外部ネットワーク用として使用し、顧客あるいはベンダーが別のタイプを使用していた場合、通信の両側の個々について、それらシステムが共に動作し、安全性を提供するためにプログラムを展開するようなネットワーク管理装置を持つ必要がある。このことは、コンピュータ、ブリッジ(１０ベースＴケーブル及びＦＤＤＩ接続のような２つの異なるタイプのメディアを用いて２つのネットワークを接続するネットワーク装置)、ルータ(２つ以上のネットワークを接続し、メッセージを正しい内部プロトコルアドレスにルーティングする特別な目的の装置)、ソフトウェア及び端子、更に外部へ及びからの接続を取り扱うためのソフトウェアを展開するためのコストに対する資産経費を通常含むことになる。装備及び特別な展開のために極端なコストを避けるために、会社は、送受信することができるこの種の情報と同様にこの種のアクセスが認可された会社の数を制限する。接続を支配することが可能な別の手段を供給するために、例えばFirst Call社のような他の会社がネットワークと分配サービスを提供した。例えば、投資銀行が顧客へその調査に関して伝達したい場合、First Call社が有料にてその内容を配達し、かつその受取人にも料金を課する。この手段は、そのように分配される情報の売り手側と買い手側の双方の部分における多大な資本支出及び開発費用の必要性を排除する一方で、情報及びその流れにおける彼らの支配をも効果的に排除する。例えば、顧客の目からみた場合、情報の中心源はFirst Call社であり、銀行又は供給者ではない。First Call社が分配する情報は、そのサービスを買った全ての人に送られるので、プロバイダーにとっては、特定の受取人のためにある情報を提供する場合は実用的ではなかった。この方法の下では、双方向通信も実用的ではなかった。そして、インターネット−即ち、何千もの既存の法人及び組織のネットワークが標準的な通信プロトコル又は通信シグナルを用いて通信を行うことを可能にするリンクされたコンピュータ・ネットワークの全世界的なシステムが到来した。 World Wide Webとして知られているインターネットのこの一面は、World Wide W ebにおいて、ユーザが一つのハイパーテキスト・リンクから別のハイパーテキスト・リンクへと移ることを可能にする目的にて、ハイパーテキスト・リンクとして公知であるものを提供するとともにHyperText Transport Protocol(HTTP)を用いることによってこれらの通信を更に一層簡略化した(ハイパーテキストとは、情報を、ノードと称され、かつ、同ノードに埋め込まれたハイパーテキスト・リンク又はハイパーテキスト・アンカーと称されるものを備えた小さなユニットに分けるテキストを作成及び公表するための方法である。テキストの読者がハイパーリンクをクリックすると、ハイパーテキストのソフトウェア（ブラウザ、又は webブラウザとしても公知である）は、そのリンクに関連したノードを表示する。これらのノードを集めたものが"web"であり、Worldwide Webは、規模の大きなハイパーテキストシステムである)。インターネット及びWorldwide Webによって、ある種の情報の広範囲への普及が容易になった。しかしながら、インターネットのWorld Wide Webに公表された情報の大部分は、その情報へのアクセスが万人にとって容易であるために、その性質において感受性の高いものではなく、機密性の高いものでもないように思われる。会社の内部ネットワークは内部ネットワークを形成する同じコンピュータについて、秘密性の高い業務上のファイルを有するだけでなく、接続が内部とインターネットとの間でなされた場合に、攻撃や盗難、又は濫用されやすい極秘の技術及び製品に関するファイルをも有する。従って、大部分の会社は内部ネットワークと、外部の世界へ通じる任意のゲートウェイとの間に「ファイヤーウォール」を構築する(図２を参照すると、会社Ｃ１からＣ９が、各々ファイヤーウォールＦ１からＦ９を有する状態で示されている)。ファイヤーウォールは、ユーザが特別にプログラムされたコンピュータシステムを、自身の内部ネットワークとインターネットとの間に設ける防護技術である。この特別な「ファイヤーウォール」コンピュータは、許可されていない者が、内部ネットワークへアクセスするのを防止する。しかしながら、ファイヤーウォールは、会社の内部コンピュータのユーザがインターネットに直接アクセスするのも防止することができる。なぜならば、ファイヤーウォールコンピュータによって提供されたインターネットへのアクセスは通常間接的なものであり、プロキシサーバと呼ばれるソフトウェアプログラムによって行われるからである。従って、ユーザがベンダーからファイルを入手したい場合には、ユーザはＦＴＰ（ファイル転送プロトコル）リクエストをファイヤーウォールコンピュータのプロキシサーバへ送信する。プロキシサーバは自身の名の下に第２のＦＴＰリクエストを作成し、ネットワークの外にあるファイルを要求するためにそれを実際に利用する。これにより、内部の名前やアドレスは会社内にとどめておくことが可能となる。ファイヤーウォールとプロキシサーバを使用すると、動作が幾分遅くなることがあり、また、機密性又は専有性の低い情報については、送信又は受信可能な情報の種類が制限されることがある。ファイヤーウォールの使用は、内部ネットワークユーザーがインターネットから情報を持ち込み、該情報を内部に配信する際の危険性を軽減するものである。しかしながら、情報が一企業のプライベートネットワーク内にひとたび持ち込まれれば、該情報を内部に配信する問題が依然として生ずる。最も大規模なプライベートネットワークは以下の組み合わせ、即ち、 ―ローカルエリアネットワーク（ＬＡＮ）−かなり小さな物理領域内、通常２マイル以内に配置され、高速ケーブル又は他の接続手段により互いにリンクされた一組のコンピュータと、 ―ワイドエリアネットワーク（ＷＡＮ）−データを迅速に長距離伝送し、内部ネットワークの「バックボーン」を形成する高速長距離通信ライン又は衛星を介して互いにリンクされたローカルエリアネットワークのグループとの組み合わせにより構築される。上記プライベート内部ネットワークは、内部でメッセージを伝送、転送及び受信するために、複雑なハードウェア及びソフトウェアを使用する。「イントラネット」を構築する第一段階として、企業ネットワーク内で分配及び配信された情報は、クライアント／サーバー技術、ウェブブラウザ、及びインターネットで使用されるハイパーテキスト技術を、内部基準において利用して、より簡単に作成されてなる。典型的なクライアント／サーバー技術において、一コンピューターは、ユーザーにとって複雑なタスクを実行するための「バックエンド」又はサーバーとして動作するものであり、一方、小型コンピュータ又は端末は、ユーザーと通信する「フロントエンド」又は「クライアント」である。クライアント／サーバー法において、クライアントはサーバーからのデータを要求する。ウェブサーバーは、ハイパーテキスト情報のためのサーバー機能として動作するプログラムである。大規模プライベートネットワークにおいて、サーバーコンピュータは、社内ネットワークにおいてハイパーテキスト通信を取り扱うために、該コンピューター上で機能するウェブサーバーソフトウェアを有していてもよい。ウェブサーバーサイトにおいて、一又は複数の人間がハイパーテキスト形式でドキュメントを作成し、該ドキュメントを該サーバーにおいて利用可能にすることも可能である。多くの企業において、従業員は、各自の机に、内部ネットワークに接続されたパーソナルコンピュータを具備することになると思われる。「イントラネット」においては、このような従業員が、各自のパーソナルコンピュータ上でウェブブラウザを使用して、該ウェブサーバーにおいてハイパーテキストドキュメントが利用可能なものを見るようになると思われる。上記事項は、プライベートネットワークを介する内部通信における進展ではあるが、同時に各人がハイパーテキストマークアップランゲージ(ＨＴＭＬ)、即ち、「内部」ウェブページを作成及び維持するドキュメント内にハイパーテキストリンクを形成するために使用される言語に精通することが要求される。よりインタラクティブなアプローチが所望される場合には、ユーザーのサーバーへの情報要求を可能にするための形式、ドキュメント及び手順を作成することのできる、ＣＧＩ、ＰＥＲＬのようなスクリプト作成分野における情報技術（ＩＴ）専門家が必要とされる。また、内部において情報を分配することを必要とするアプリケーションも、IB M社のソフトウェアLotus Notes^TMのようなワーキンググループソフトウェアとして公知のものを内部ネットワーク上で使用することができる。しかしながら、このことも、組織独自の要求に応じて特別なプログラム及びスクリプト作成技術を要求するものである。イントラネットをインターネットに接続して、いわゆる「エクストラネット」を形成することが益々一般的になりつつある。しかし、インターネットは基本的には受動的な通信システムである。顧客のイントラネットの外部にある特定のインターネットウェブページ上において新たなレポートが利用可能であることが顧客に対して自動的に通知されることはない。通常、顧客はウェブページが変わったか、その変化が顧客が見たいものであるかを確認するために定期的にインターネットを検索しなければならない。料金サービスを行っているウェブページサイトの中には見込みユーザに新しいデータが存在することを通知するためにｅ-メールを利用したものがある。上述したように、ｅ-メールは遅いため、データが時間感受性でもある場合、この通知がその日の遅くまで顧客に届かない場合があり、その時点ではすでに価値が低くなっている可能性がある。インターネットをよりインタラクティブにする試みの一つがIntermind社から提案されている。これはハイパーテキストの一形態であり、ハイパーコミュニケーションと呼ばれるものである。このアプローチでは、一般的な電話機の「スピードダイアルボタン」に似た要領で、異なるサイトに多数のディレクトリが作られる。ハイパーコミュニケーションによって接続されたサイトからユーザが情報を得たい場合、そのサイトの「スピードダイアル」ボタンを「押す」ことにより、Intermind社製ソフトウェアによって作られたディレクトリを通じて自動的にサイトに接続される。このアプローチにより情報の発行元は、受け手が受信可能であるかについてアンケートをとることも可能である。受け手が受信可能であり、発行元が受け手に与えるための新たなデータを持っている場合、発行元は「スビードボタン」を「ダイアル」してデータを送る。これは顧客に新たな情報があることを通知する問題の解決を助けるものである。しかし、こうしたディレクトリを用いた場合でも、インターネットを介して内部で作成された情報を外部のビジネスパートナーに対して選択的に利用可能とすることは、内部の情報の作者が個々に手動で行った場合には非効率となる。内部の情報を同じイントラネット上の外部の情報源とコミングリングさせることも、手動で行った場合には「スピードボタン」を用いても手間がかかり非効率である。このアプローチでは、データの発行の制御、データの見出し付け及びオーガナイズドされたプレゼンテーションのいずれも行うことができない。また、「防火壁」や同様のアクセス防御がなく他者によるウェブサイトへのアクセスが可能であることによるセキュリティの問題もこのアプローチでは解決されない。インターネット及びウェブブラウザの到来によって情報の発行者にとって利用可能となった別の手段に、インターネットを介し、機密性の高いアクセスを与える一接続形態がある。この接続では通常、暗号化及び機密保持ソケットを利用し、非武装地帯すなわちDMZを介して、より限られた情報へ接続される。個々の企業は企業のネットワーク上の内部データのプライバシーの保護を望むため、「非武装地帯」（DMZ）を外側に備えた防火壁をネットワークの周囲に有するか、その企業が接続したい他の企業のそれぞれに対する防火壁の一部として有する。図２ｂに示されるように、例として企業ＡのDMZであるD１は、防火壁F1と企業ＡのインターネットへのゲートウェイG1との間となるように防火壁F１の外側に配置することが可能である。DMZ D1内には企業Ｃとの相互の通信のために別に配される領域ICが示されている。図２ｂに見られるように、他の企業との直接かつ高い機密性を有する通信を望む各企業のDMZは、想定される通信対象者が特定されるように構成されなければならない。顧客が２０個の異なる外部の発行元から情報を得る必要がある場合、顧客の防火壁と発行元の防火壁との間に２０の異なる接続を行って２０個の識別子及びパスワードを取得する必要がある場合が考えられる。これを図２に簡略化して示した。図示を容易にする目的で、企業C１〜C３を互いに競合する投資銀行とし、企業C５〜C９をその顧客、C４をニュースソースとして、上記のDMZ配置を利用したネットワーク配置を大幅に簡略化して示してある。銀行C１はニュースソースC４及び５つの顧客C５〜C９のためのDMZ D４〜D９を有する点に留意されたい。顧客 C５は、ニュースソースC４に対するの同様、顧客C５がデータを得る投資銀行のそれぞれに対してDMZ D1〜D３を有する。図２が示すように、このアプローチにより接続Ｄ及びDMZ Dは迷路となる。DMZを簡略化したものが図２ｂに示されているが、企業C１はそのDMZ D１において企業C３と通信するアプリケーションを有する。企業C２はそのDMZ D２において企業C１及びC３と通信するためのアプリケーションC１及びC３をそれぞれ有する。 DMZによるアプローチでは、お互いの企業のネットワークへのアクセスを得るうえで個々の顧客は異なるユーザ識別子及びパスワードを取得する必要がある。各顧客サイトの各個人に対し、投資銀行の情報技術部門の誰かがユーザ識別子及びパスワードを付与しなければならない。このことは更なるネットワーク管理及び保守労力を必要とする。顧客がウェブブラウザを使用して供給元のネットワークから情報を集めるようなこうした状況設定は「プル」モデルと呼ばれるが、これは顧客は依然、情報を能動的に探索しなければならないことによる。この管理業務をできるだけ簡素化するうえで、情報の発行元が発信される情報を一般化して、情報が１対多数すなわちブロードキャストフォーマットにて送信されるようにすることは理に適っている。この種のアプローチにおいては、ある発行元は情報をある形式でまとめ、別の発行元はデータを全く異なる形式で構成するということになる。したがって顧客が２０の異なる発行元からのデータを見出し付けし、意味をなすように組織化することは極めて困難となる。情報の提供元がより能動的であるためには、通信の「プッシュ」モデルが望ましい。これは、顧客がネットワーク上の情報を探索するの待っているのではなく、提供元がユーザに対してデータがそこにあることを通知し、自動的に発信することが可能であることが望ましいということである。ロータスノートなどのワークグループソフトウェアはこうした種類の企業間通信に対するより有効な解決策であると一般的に考えられていた。残念なことに、通常これは相当量のソフトウェア開発及び管理用オーバヘッドを必要とする。２０の異なる投資銀行からレポート及びデータを得る顧客の例では、顧客サイト上で従業員の机上において統合されるべき情報は通常各種の互いに不適合なフォーマットにて届く。顧客が各銀行から午前の分析を得たい場合、顧客サイトの情報スペシャリストは恐らく、各銀行によってどんなフォーマットが使用されているかを調べなければならず、各銀行に対して用いられるネットワークアドレススキーム、プロトコル、パケット、ボート、およびソケットを顧客のプログラマーに理解させなければならず、更に、顧客の机上のロータスノートワークグループアプリケーションプログラムの１以上を作るかあるいは改変してデータを内部フォーマットに変換して取り込まなければならない。これらの問題点の少なくとも一部を解決するための１つの試みとして、ティブコ（Tibco）に譲渡された米国特許第5,577,798号に記載されている「サブジェクトに基づくアドレッシング技術」として知られる技術がある。このアプローチと、図２ａに示されているＤＭＺを介してのネットワーク対ネットワークの直接接続の例とを用いて、公表者（publisher）Ｃ１は自身のサイトに、サブジェクトによる情報を公表するためのサーバーをセットアップする。顧客Ｃ５は、通常、そのＤＭＺＤ５に「クライアント」アプリケーションを備えている。クライアントアプリケーションとは、人による読み取りが可能なサブジェクトネームを用いて受け取られる一連のメッセージを意味している。サブジェクトに基づくアドレッシングによって、全てのネットワークアドレス、プロトコル、パケット、ポート及びソケットの詳細を顧客のプログラマーが理解しなくてはならない必要性がなくなり、更に、ワークグループソフトウェアに対して成されなければならない変更のうちのいくつかが容易になる。しかしながら、サブジェクトに基づくアドレッシングによって、ネットワークフィード（network feed）を得ると共に、転送されたデータがどのようにフォーマットされているかを理解するために、サイトにて変換即ち翻訳層ソフトウェアを構築する必要性がなくなるわけではなく、従って、ロータスノート（Lotus Notes）アプリケーション等のワークグループソフトウェアを変更する必要性がなくなるわけでもない。実際に、サブジェクトに基づくアドレッシング及びロータスノート等のワークグループソフトウェアでは、いずれも、通常、効果的に機能させるためには、多量の付加的なプログラミング開発作業がユーザによって成されることが必要である。情報公表者の立場から考えると、複数のファイヤーウォール、ＤＭＺ及びワークグループプログラムを介してのネットワーク対ネットワークの私的な接続に依存すると共に、サブジェクトに基づくアドレッシングを用いる「プッシュ」モデルは、公表者にとって不可欠である配信管理問題への対策が講じられていない。図２ａの投資銀行Ｃ１がサブジェクトとして午前の分析情報を配信した場合、データが同銀行のネットワークを出てインターネット上に配信された後は、通常、同投資銀行が分析情報の複製を管理することは全くできなくなる。サブジェクトに基づくアドレッシングでは殆どの場合、公表者は、いずれの企業によって自身の情報が消費されているかを知ることさえあり得ない。例えば、或る一連のプログラムが、顧客Ｃ８（図２a）等、或る顧客サイトにおいて、ロータスノート等のソフトウェア又はサブジェクトに基づくアドレッシングのいずれかを用いて行われる公表管理及び配信に向けて作成されたとしても、顧客Ｃ９のネットワークと共に、又は異なる数件の顧客ネットワーク間で機能させるべく、同プログラムを適合させるのは必ずしも単純又は簡単な作業ではない。インターネット又は異なる幾つかの企業をリンクさせる広域ネットワーク上にて、情報を送受信することを所望すれば、又はその必要が生じれば、配信管理問題は非常に複雑な問題となる。前述したように、各受信者のデスクトップにおいて同じように分類されるように、異なる多くのソースから受け取った情報に索引を付けたり、これを組織化することは困難である。いくつかのプロファイリング即ち「フィルタリング」システム（例えば、インディビデュアル（Individual）社又はポイントキャスト（Po intcast）社製のもの）は、公的ソースからデータを収集し、個々のユーザの要求に合った情報を選択すべく、それらデータに対してフィルタリング又はふるい分け（sift）を行うが、これらのシステムは通常複製を管理することはなく、データに対するインタラクション（interaction）を許容することもない。プロファイリングシステムは通常、一対多数の、インタラクションを許容しない一方向性配信モデルである。ブラウザが用いられているイントラネットを備えた企業及び大規模な機関においては、個々の情報受信者は目にするものをブックマーク管理によって組織化することができる。しかしながら、ブックマークは通常、非常に特殊に形成されており、２組のブックマークが同一であることはあり得ない。また、外部プロファイリングシステムの場合と同様に、ブラウザ及びブックマークを用いるイントラネットは、通常、一方向にしか情報を送ることができない。銀行Ｃ１によって配信された分析情報を入手した図２の企業Ｃ８は、通常、銀行Ｃ１によって、該当するウェブページにおいてコメント及び返答を可能にする目的で、ＣＧＩスクリプティング又はその他のプログラミング即ちスクリプティング言語を用いて、特殊なフォームシートが作成されていない限りは、コメント及び返答を行うためにブラウザを使用することはできない。この点でも、カスタムプログラミング即ちスクリプティングはコストを上昇させるものであり、通常、企業間における標準化を困難にさせるものである。現在インターネットに接続されている殆どのイントラネットシステムでは、個々のユーザは、ソース及びサブジェクトの両方に基づいて情報を要求することはできない。更に、殆どの同イントラネットシステムでは、個々のユーザが、情報の作成者及び閲覧者の両者として機能することはできない。図２ａに示すように、インターネット上の複数の情報消費者を、複数のＤＭＺ及びセキュアソケットを介して外部の情報ソースに接続することは複雑で煩雑な作業であり、情報公表者のためのセットアップ及び管理を行うためにもコストがかかる。インターネット上の情報消費者の立場から考えれば、このような配信モデル上での送信は「インターネット速度」にて行われることに留意しなければならない。即ち、例えば顧客Ｃ８から情報の要求が成された後、それがインターネット上に送られるとすれば、それはＴＣＰ−ＩＰ形式でフォーマットされたパケットにおいてであり、セキュアソケット技術によって記号化される可能性がある。いずれの場合も、その情報要求が顧客Ｃ８の基幹ネットワークから外部に送られた後は、その送信速度はインターネット送信リンクにおける平均速度である。この速度は、通常、顧客自身の内部ネットワーク内における送信速度よりもかなり遅い。従って、顧客の立場から考えると、企業間通信の実行速度もまた、問題であり得る。ＤＭＺ又はプロキシ（proxy）サーバー等の装置を用いることで、安全保障上の問題が改善される一方で、ＤＭＺはまた、全ての企業間通信に対して障害となるコンテントバックログ（content backlogs）を形成する傾向にある。例えば、企業のファイヤーウォールの保護域外で同企業のＤＭＺにデータを転送することを認可された人物のみが情報技術の専門家であるならば、大量の情報を外部に対して選択的に送信する必要がある又はそれを所望する企業にとって、この作業は労働上の大変な手間又は障害、若しくはその両方となる。同様に、現在の安全保障技術によって、種々の記号化の選択肢が提供される（その結果、企業間における標準化の問題を引き起こしている）が、個人識別（identification）等の問題は各企業の情報技術（ＩＴ）部門の管理に委ねられている。ＩＴ専門家は、企業のＤＭＺ内の情報（認証情報(authentication)）にアクセスすることを認可された外部の全個人に対して、ユーザ識別子及びパスワードを与えなければならない。現在これは、通常、各企業及び個人における手動参照文字（manual letters o f reference）又は手動データ入力によって成されている。前述のように、文書がＨＴＭＬを用いて作成されなければならない場合、又はデータを適切なフォーマットに適合するために、特殊なＣＧＩ（コモンゲートウェイインターフェイス(common gateway interface)）スクリプトを作成し維持する必要がある場合は、これらの事情の全てによって、ポリシー及びコンテント管理の問題が、情報の作成者及び閲覧者ではなくＩＴ部門の専門家の手に預けられる傾向が作り出される。企業内のＩＴ専門家は、新規のユーザ及び個人の追加、転送され得るデータ型の登録、スクリプト、プログラム、ネットワーク及びシステム全体に対する変更及び更新の実施及び維持等の要請に圧倒されている。本発明の目的は、情報の複製及び公表の管理が許容されるような態様で、貴重な情報を選択的に転送することを可能にする汎用ドメインルーティング及び公表制御システムを提供することにある。本発明の別の目的は、異なる型におけるユーザ又はネットワーク間にて、選択的に情報を配信することが可能なシステムを提供することにある。本発明の更に別の目的は、ユーザが、受信した情報についてコメントしたり、その情報に対してインタラクト（interact）することを許容するシステムを提供することにある。本発明の更に別の目的は、ユーザ及び情報提供者によるソフトウェア開発の必要性を最小化する、又は解消することにある。本発明の更に別の目的は、特殊な管理手順及び特殊な訓練を受けた人員によってシステムを管理する必要性を軽減することにある。本発明の更に別の目的は、殆どの場合、ユーザの内部ネットワークにおける速度で、ユーザが情報にアクセスできるように許容するシステムを提供することにある。本発明の更に別の目的は、サブジェクト又はソース、若しくはその組み合わせによる情報の標準化及び組織化を容易にするダイナミック配信ネットワークリソースレジストリ（dynamic distributed network resource registries）を提供することにある。発明の開示これら及び他の目的は、選択的シェアリングのために異なるネットワーク上におけるクライアントエンティティから情報を組織するためのレジストリによって達成され、そのレジストリはダイナミッククライアントレジストリ及び機能名を含むリソースロケータを格納するためのディスクを備えた第１コンピュータと、示される機能名を第１コンピュータにロードすることにより、リソースロケータに第１コンピュータを応答させるウェブサーバーとを備えている。データベースマネージメントプログラムはダイナミッククライアントレジストリを組織する。ドメイン通信サーバーは前記ダイナミッククライアントレジストリの組織中に、ウェブサーバーにより、それに向けられたリソースロケータに応答し、かつ、データベースマネージメントプログラムを管理する。いくつかの第２コンピュータは第１コンピュータとネットワークを結んでおり、各第２コンピュータはダイナミックグループレジストリ及び機能名を含むリソースロケータを格納するディスクを備えている。各第２コンピュータはウェブサーバーを備え、そのウェブサーバーは、示される機能名をロードすることにより、第２コンピュータをしてリソースロケータに応答させる。各第２コンピュータは、ダイナミックグループレジストリを組織するためのデータベースマネージメントプログラムを備える。各第２コンピュータ内のクライアント側通信サーバーは、ウェブサーバープログラムによってロードされたとき、クライアント側通信サーバーに向けられたリソースロケータに応答し、かつ、ダイナミックグループレジストリの組織中にデータベースマネージメントプログラムを管理する。すべてのコンピュータ内に格納されたドメイン通信リソースロケータリストは、ドメイン通信サーバー中において実行するために所定の機能が選択されるようにする。すべてのコンピュータ内に格納されたクライアント側通信リソースロケータリストは、各クライアント側通信サーバー中において実行するために所定の機能が選択されるようにし、よって、第１コンピュータと各第２コンピュータとの間の通信により、第２コンピュータに対して情報を選択的に差し向けるために、選択された機能が実行される。本発明の一態様は、或る会社が、いかなる場所においてもDMZの使用を必要とすることなく、その私用のネットワークの外側で他の企業と確実に通信を行うことを可能とすることである。本発明の一態様は、動的に形成可能な相対配置ドメイン・ルーティング及びパブリケーション制御システムを提供することである。本発明のもう１つの態様は、ユーザが、ネットワーク上への情報の配給及び再配給のためにかれら独自のポリシーを限定して実行することを可能とすることである。本発明のさらにもう１つの態様は、ユーザによりさらにソフトウエアを開発する必要を無くすことである。本発明のさらにもう１つの態様は、システムを管理するために追加の熟練した情報技術職員を必要とせず、代わりにユーザが彼等自身でそれを管理することを可能とすることである。本発明のもう１つの態様は、私用ネットワークにおけるユーザが、殆どの時間において私用ネットワークの速度でネットワークの外側から情報を受け取ることを可能とすることである。本発明のもう１つの態様は、種々のクライアントへの選択的な配給を生成するための簡単な方法を、情報公布者に与えることである。図面の簡単な説明図１は、本発明の概略図であり、ドメイン・通信サーバと、幾つかのクライアントサイド・通信サーバを示す。図１ａは、本発明の別の概略図であり、ドメイン・通信サーバと幾つかのクライアントサイド・通信サーバとの事実上の連結を示す。図２ａは、先行技術を用いたインターネット上で外部と通信するプライベートネットワークの概略図である。図２ｂは、先行技術を用いたインターネット上で外部と通信するプライベートネットワークの概略図である。図３は、本発明の概略図であり、互いに連絡する幾つかのドメインを示す。図４は、本発明の方法及び装置に従うクライアントサイド・通信サーバの概略図である。図５は、本発明の方法及び装置に従うドメイン・通信サーバと幾つかのクライアントサイド・通信サーバとの相互連結を示す概略図である。図６ａは、本発明の方法及び装置に従うドメイン・通信サーバにおける例示的な動的クライアント・レジストリのブロック線図である。図６ｂは、本発明のドメイン・通信サーバにおける動的クライアント・レジストリのフィールドを示す詳細なブロック線図である。図７ａは、本発明の方法及び装置に従うクライアントサイド・通信サーバにおける例示的な動的グループレジストリのブロック線図である。図７ｂは、本発明のクライアントサイド・通信サーバにおける動的グループレジストリのフィールドを示す詳細なブロック線図である。図８ａは、本発明の好ましい実施形態において用いられる、主要なドメイン・通信サーバの全域資源位置指示子（ＵＲＬ）のリストである。図８ｂは、本発明の好ましい実施形態において用いられる、主要なクライアントサイド・通信サーバのＵＲＬのリストである。図９は、本発明の方法及び装置に従う例示的なドメイン・クライアントリストの詳細な配置図である。図１０は、本発明の例示的なクライアント・ソースリストの詳細な配置図である。図１１は、本発明の例示的なクライアント・オブジェクトリストの詳細な配置図である。図１２は、本発明の例示的なオブジェクト宛先リストの詳細な配置図である。図１３は、本発明の方法及び装置に従う例示的なインデックスの詳細な配置図である。図１４は、本発明の方法及び装置に従うクライアントサイド・通信サーバにおける起動手続きのフローチャートである。図１５は、本発明の方法及び装置に従うクライアントサイド・通信サーバによる共有オブジェクトの初期化のフローチャートである。図１６は、本発明の方法及び装置に従うクライアントサイド・通信サーバによる共有オブジェクトの初期化のさらに詳細なフローチャートである。図１７は、本発明の方法及び装置に従うクライアントサイド・通信サーバの管理者サーバによる共有オブジェクトの初期化を示すフローチャートである。図１８は、本発明の方法及び装置に従うクライアントサイド・通信サーバのツールサーバによる共有オブジェクトの初期化を示すフローチャートである。図１９は、本発明の方法及び装置に従うクライアントサイド・通信サーバのエージェントサーバによる共有オブジェクトの初期化を示すフローチャートである。図２０ａは、本発明の方法及び装置に従うドメイン・通信サーバによる動的クライアント・レジストリの初期化を示すフローチャートである。図２０ｂは、本発明の方法及び装置に従うクライアントサイド・通信サーバによるグループの作成を示すフローチャートである。図２１は、本発明の方法及び装置に従うクライアントサイド・通信サーバの初期化を示すフローチャートである。図２２は、本発明の方法及び装置に従う、ユーザを追加するためのデスクトップターミナルの例示的な利用者画面表示のブロック線図である。図２３は、本発明の方法及び装置に従う、新しいユーザの会計情報を入力するための例示的な利用者画面表示のブロック線図である。図２４は、本発明の方法及び装置に従う、新しいユーザのための内容作成を認可するための例示的な利用者画面表示のブロック線図である。図２５ａは、本発明の方法及び装置に従う、内容種別を選択するための例示的な利用者画面表示のブロック線図である。図２５ｂは、本発明の方法及び装置に従う、内容種別を選択するための例示的な利用者画面表示のブロック線図である。図２５ｃは、本発明の方法及び装置に従う、ユーザが分配オプションを選択するための例示的な利用者画面表示のブロック線図である。図２６ａは、概して本発明の方法及び装置に従う、再分配権を認可するための例示的な利用者画面表示のブロック線図である。図２６ｂは、特に本発明の方法及び装置に従う、再分配権を認可するための例示的な利用者画面表示のブロック線図である。図２６ｃは、本発明の方法及び装置に従う、グループアクセスを割り当てるための例示的な利用者画面表示のブロック線図である。図２６ｄは、本発明の方法及び装置に従う、ユーザに内部でのグループアクセスを割り当てるための例示的な利用者画面表示のブロック線図である。図２６ｅは、本発明の方法及び装置に従う、ユーザに外部へのグループアクセスを割り当てるための例示的な利用者画面表示のブロック線図である。図２７は、ドメイン・クライアント・テーブルの作成を示すＳＱＬ書式の疑似コードである。図２８は、クライアント・ソーステーブルの作成を示すＳＱＬ書式の疑似コードである。図２９は、クライアント・オブジェクト・テーブルの作成を示すＳＱＬ書式の疑似コードである。図３０は、オブジェクト宛先テーブルの作成を示すＳＱＬ書式の疑似コードである。図３１は、索引テーブルの作成を示すＳＱＬ書式の疑似コードである。図３１ｂは、チャネル内容テーブルの作成を示すＳＱＬ書式の疑似コードである。図３１ｃは、チャネルテンプレートテーブルの作成を示すＳＱＬ書式の疑似コードである。図３２ａは、ワークグループテーブル７０の作成を示すＳＱＬ書式の疑似コードである。図３２ｂは、ワークグループ内容テーブルの作成を示すＳＱＬ書式の疑似コードである。図３３は、ワークグループのベース内容テーブルの作成を示すＳＱＬ書式の疑似コードである。図３４は、ワークグループのマスタリスト・テーブルの作成を示すＳＱＬ書式の疑似コードである。図３５は、ワークグループの特別内容テーブルの作成を示すＳＱＬ書式の疑似コードである。図３６は、ワークグループの著者メンバーテーブルの作成を示すＳＱＬ書式の疑似コードである。図３７は、ワークグループのビューメンバーテーブルの作成を示すＳＱＬ書式の疑似コードである。図３８は、アドレスブックテーブルの作成を示すＳＱＬ書式の疑似コードである。図３９は、著作権テーブルの作成を示すＳＱＬ書式の疑似コードである。図４０は、ビューアテーブルの作成を示すＳＱＬ書式の疑似コードである。図４１は、ワークグループ内容リストの属性テーブルの作成を示すＳＱＬ書式の疑似コードである。図４２は、ワークグループ内容リストの基準テーブルの作成を示すＳＱＬ書式の疑似コードである。図４３は、クライアントサーバの管理メッセージテーブルの作成を示すＳＱＬ書式の疑似コードである。図４４は、クライアントサーバの内容テーブルの作成を示すＳＱＬ書式の疑似コードである。図４５は、クライアントサーバの内容ベーステーブルの作成を示すＳＱＬ書式の疑似コードである。図４６は、クライアントサーバの特別な内容テーブルの作成を示すＳＱＬ書式の疑似コードである。図４７は、クライアントサーバの分配待ち行列テーブルの作成を示すＳＱＬ書式の疑似コードである。図４７ａは、クライアントサーバの複製待ち行列テーブルの作成を示すＳＱＬ書式の疑似コードである。図４７ｂは、クライアントサーバの複製宛先待ち行列テーブルの作成を示すＳＱＬ書式の疑似コードである。本発明を実施するための最良の形態図１に、本発明における好適な一実施形態を概略ブロック図にて示す。ドメイン通信サーバーＡ１は、複数のクライアント側通信サーバーＣ１〜Ｃ９とコミュニケートしている。これらクライアント側通信サーバーは、それぞれ、好適な一実施形態における各企業サイトにてファイヤーウォールＦの保護下に配置されている。即ち、企業Ｃ−１はクライアント側通信サーバーＣ１を備えていると共に、企業Ｃ −２はクライアント側通信サーバーＣ２を備え、以下企業Ｃ−９まで同様にクライアント側通信サーバーを備えているものと想定する。複数の一時論理接続（Te mporary logical connections）又は「パイプ」Ｐは、このドメインにおける各クライアント側通信サーバーとドメイン通信サーバーＡ１との間に形成されている。好適な一実施形態において、パイプＰは、従来のTCP-IPネットワーキングプロトコルと、暗号化テクノロジーを伴うネットスケープコーポレーション（Nets cape Corporation）の複数のセキュアソケット（secure sockets）とを用いて、インターネット上で形成される接続である。しかしながら、当該技術分野の従事者には明らかであるように、その他のネットワーク、プロトコル、及び暗号化技術を用いることも可能である。同じく図１において、それぞれのクライアント側通信サーバーＣは、ドメイン通信サーバーＡ１との実際の接続パイプＰを１つしか備えていないことが示されている。しかしながら、それぞれのクライアントによるドメイン通信サーバーＡ１への登録様式に応じて、クライアント側通信サーバーＣ１から、その他のクライアント側通信サーバーＣ２〜Ｃ９のいずれか又は全てに対して、情報を配信することが可能である。このように、本発明は、企業Ｃ−１〜Ｃ−９からなるコミュニティを、ドメイン通信サーバーＡ１によってネットワーク上でリンクするインテリジェントエクストラネットを提供する。本発明によって提供されるエクストラネットは、それぞれの会員クライアントＣが、Ｃにとって外部である（Ｃとコミュニケートすることを認可した）企業又は機関と、相手の企業がクライアント自身の内部ネットワーク又はイントラネットの一部を成しているかの如くコミュニケートすることを可能にする。この点において、本発明は、企業イントラネットの仮想コミュニティを提供する。企業のコミュニティが金融産業であるより具体的な例を用いると、Ｃ１，Ｃ２及びＣ３が３つの異なる投資銀行のクライアント側通信サーバー、Ｃ５〜Ｃ９までが投資管理会社のクライアント側通信サーバー、Ｃ４がニュース放送機関のクライアント側通信サーバーである場合、クライアント側通信サーバーＣ１における投資銀行は、ドメインサーバーＡ１のみと直接コミュニケートすることによって、ドメイン通信サーバーＡ１とコミュニケートしている他のクライアントのいずれに対してでも、情報を送信することができる。即ち、クライアント側通信サーバーＣ１における銀行Ｃ−１は、必要であれば、顧客Ｃ−５〜Ｃ−９におけるクライアント側通信サーバーＣ−５〜Ｃ−９のみに対して、自社の午前の分析報告を配信することが可能であり、ニュース放送機関Ｃ−４は、ドメイン通信サーバーＡ１とコミュニケートしているその他全てのクライアントに対して、自社の情報を伝送することができる。このように、本発明における好適な一実施形態はまた、同コミュニティに参加している企業又は団体のための関係情報マネジャーとしても機能する。従って、本発明によって、投資銀行Ｃ−１の顧客は、安全保障された接続を通じて、委託アドヴァイザーからタイミング良く貴重な情報を受け取ることができる。図１ａには、実施可能なコミュニケーションの型のいくつかを示す。この例では、異なる４つのクライアントＣ１〜Ｃ４が示されている。クライアントＣ１は、唯一クライアント側通信サーバーＣ１−ＰＡを本発明の方法及び装置における「スマートイントラネット」として機能させている、在米国ペンシルヴァニア州の投資銀行である。クライアント側通信サーバーＣ１−ＰＡは、同銀行の内部ローカルエリアネットワーク（Local Area Network）Ｃ１−Ｌａｎに接続されており、Ｃ１−Ｌａｎはまた、２つのターミナルＴ１及びＴ２を備えている。当該技術分野の従事者には明らかであるように、ターミナルＴは、コンピュータ、ミニコンピュータ、ワークステーション、パーソナルコンピュータ、キーボード付きＣＲＴターミナル、インターネット機能付きテレビジョンターミナル、キーボード又はタッチスクリーン及びディスプレイ装置、パーソナルディジタルアシスタンス、又はユーザがネットワークとコミュニケートして表示された情報を見ることを許容する任意の装置等、あらゆる型のネットワークに接続可能な装置であり得る。好適な一実施形態では、ネットワークに接続可能なパーソナルコンピュータが、同パソコンにて実行される標準的なウェブブラウザソフトウェアと共に用いられている。好適な一実施形態では、「スマートイントラネット」という用語は、本発明によって、或る企業の内部ネットワーク、即ち同企業の「イントラネット」が、その企業内部において、及び同企業にとって外部である参加企業に対して、一対一、グループ対グループ、及びサイト対サイトにおいて情報管理（情報の作成、アクセス及び複製）を実施することが可能になる態様を表している。同じく図１ａにおいて、クライアントＣ２は、香港、ニューヨーク及びロンドンにオフィスをもつ投資銀行Ｃ２であり、内部ネットワークを形成すべくその全オフィスが銀行の広域ネットワークＣ２ＷＡＮを介して相互に接続されている。同銀行のネットワーク全体が、ファイヤーウォールＦ２によって、外部からの侵入に対して保護されている。同投資銀行Ｃ２の香港、ニューヨーク及びロンドンにおけるサイトは、それぞれ独自のローカルエリアネットワーク、即ち、香港におけるＣ２−ＨＫＬａｎ、ニューヨークにおけるＣ２−ＮＹＬａｎ、ロンドンにおけるＣ２−ＬＮＬａｎを、各ローカルエリアネットワークに接続された標準的な市販のウェブブラウザを用いるターミナルＴと共に備えている。図１ａに示すように、クライアントＣ２の各サイトは、そのサイトにおけるローカルエリアネットワークに接続されると共に、クライアントＣ２の広域ネットワークＣ２ＷＡＮに接続されて、本発明の方法及び装置によるクライアントＣ２のスマートイントラネットを形成するクライアント側通信サーバー（Ｃ２−ＨＫ，Ｃ２− ＮＹ，Ｃ２−ＬＮ）を備えている。同様に、クライアントＣ４は、Ｃ４のスマートイントラネットを形成すべく、ファイヤーウォールの保護下で広域ネットワークによって相互に接続された複数のサイトを有しており、クライアントＣ３は、Ｃ３のスマートイントラネットとして、ドメイン通信サーバーＡ１とコミュニケートされた在ボストンの単一のサイトを備えている。同じく図１ａに、クライアントＣ２におけるスマートイントラネットのコミュニケーションの論理即ち仮想フローを、クライアントＣ２内の各ＬＡＮを接続する複数の「パイプ」Ｐ２を表す点線によって示す。本明細書では、パイプという用語は、必ずしもハードウェアによって実現される物理的な接続ではなく、ソフトウェアによって管理される論理接続を意味すべく用いられる。当該技術分野の従事者には明らかであるように、或るクライアント内における複数のローカルエリアネットワークが、内部ネットワークを形成すべく広域ネットワーク上で相互に接続されるには、多数の方式が存在する。本発明の好適な一実施形態においては、図１ａに示すように、これらの論理内部接続パイプＰ２はクライアントＣ２の外部にも存在し、ドメイン通信サーバーＡ１まで延びると共に、同サーバーＡ１を介してクライアントＣ１及びC３に接続されているが、クライアントＣ４には接続されていない。即ち、本発明の好適な一実施形態では、クライアントＣ２等のクライアントは、認可された外部のサイトと、それらのサイトがクライアントＣ２の内部又はＣ２のスマートイントラネットの一部であるかのように、又はＣ２が外部サイトにとっての内部又はそれらのスマートイントラネットの一部であるかのように、(本発明を介して)論理的にコミュニケートすることが可能である。しかしながら、クライアントＣ２はドメイン通信サーバーＡ１を除き、これら外部サイトのいずれとも物理的接続を行うことはないため、クライアントＣ２はファイヤーウォールＦ２によって得られる保護機能を失うことは一切ない。好適な一実施形態では、クライアントＣ２とドメイン通信サーバーＡ１との間における全ての物理的な伝送は、ネットスケープコーポレーションのセキュアソケットレイヤー（ＳＳＬ）の技術及び暗号化を用いてインターネット上にて行われる。更に図１ａには、各クライアントＣは、レジェンド（legend）００に示されるように、Ｐ１〜Ｐ６までの独自の「パイプ」Ｐを備えている。例えば、クライアントＣ２における３つのサイトは、「パイプ」Ｐ２上で相互に内部コミュニケートしている。本発明の好適な一実施形態において、クライアントＣ２はまた、パイプＰ２上でクライアントＣ１，Ｃ３及びＣ５ともコミュニケートしているように見えるが、実際には、クライアントＣ２は、Ｃ２をドメイン通信サーバーＡ１に接続する実際のパイプを１つしか備えていない。当該技術分野の従事者には明らかであるように、クライアントＣ２のネットワークとドメイン通信サーバーＡ１との間における唯一の同パイプは、必要であれば、Ｔ１又はＴ３の高速ラインを用いて、物理的な直接接続として実施することも可能である。本発明によって、クライアントＣ２は、一連の「仮想パイプ」ＶＰ２上で、ドメイン通信サーバーＡ１を介して、クライアントＣ１，Ｃ３及びＣ５と外部コミュニケートすることができる。仮想パイプという用語は、本明細書では、それぞれのクライアントが、実際には、ドメイン通信サーバーのみと物理的にコミュニケートしており、かつその他のクライアント又は会社とは単に「仮想」的にコミュニケートしているに過ぎない際に、２つ（又はそれ以上）のクライアントがインターネット（又はその他のネットワーク）上で直接的にコミュニケートする場合と同様に、コミュニケーションが成立することを指している。仮想パイプは、各サイトにおけるクライアント側通信サーバーと協働する本発明のドメイン通信サーバーの論理（lo gic）によって、動的に（dynamically）創造されると共に管理される。以上のようなことから、インテリジェントエクストラネットという用語を用いる。同じく図１ａにおいて、ドメイン通信サーバーＡ１は、図示されている複数のクライアント用の主要なドメイン通信サーバーとして機能しているが、同時に複数の地域（regional）即ち代替ドメイン通信サーバーＡ２及びＡ３にも接続されていることに留意されたい。従って、コンピュータシステム又は物理的コミュニケーションの主要なドメイン通信サーバーＡ１へのリンクが何らかの事由によりダウンしても、本発明の好適な一実施形態では、代替ドメイン通信サーバーＡ２又はＡ３を介して、コミュニケーションを継続させることが可能である。本発明の好適な一実施形態では、複数のドメインサーバーは全ての関連する表及びデータを自動複製することにより、互いを常に更新された状態に維持しており、その結果、相互に鏡のような役割を担っている。当該技術分野の従事者には明らかであるように、異なる複数のドメインはまた、複数のドメイン通信サーバーから成るコミュニティを一緒にマッピングするハイパー即ちスーパードメイン通信サーバーを備えることによって、相互にリンクされ得る。同様に、本発明におけるドメインルーティング（routing）はまた、大規模な複数の内部ネットワーク内にて互いからワークロードをダウンロードするための付加的なドメイン通信サーバーを形成すべく、内部的に（internally）用いられ得る。例えば、米国及び欧州における複数の場所に複数のクライアント側通信サーバーを備えている企業は、欧州における複数のクライアント側通信サーバーを、米国における企業内ドメイン通信サーバーにマッピングされている欧州のドメイン通信サーバーに接続させることを選択し得る。米国における企業内ドメイン通信サーバーは、更に、前述したような態様で、複数の外部ドメイン通信サーバーにマッピングされ得る。ワーク（work）をダウンロードするために複数のドメイン通信サーバーを内部的に用いることによって、応答所用時間とネットワーク内の処理能力を改善することができる。次に、図３において、複数のドメイン通信サーバーにおける複数のコネクションを示す。ここで、複数のクライアントから成るネットワーク用の主要なドメイン通信サーバーとして機能し得るドメイン通信サーバーＡ１は、ドメイン通信サーバーＡ２又はＡ３、若しくはその両者によって制御される複数のネットワーク用の代替ドメイン通信サーバーとしても機能し得る。また、ドメイン通信サーバーＡ２及びＡ３は、ドメイン通信サーバーＡ１によって制御される単一ネットワーク用の地域ドメイン通信サーバーとして機能することも可能である。更に、図４に、本発明の好適な一実施形態を概略的に示す。図４に示すように、クライアントＣ８のボストンにおけるロケーションＣ８−ＢＯでは、コンピュータ２０は、ファイヤーウォールＦ８の保護下にてドメイン通信サーバーＡ１に接続されると共に、クライアントＣ８のローカルエリアネットワークＣ８Ｌａｎに接続されている。本発明の好適な一実施形態では、コンピュータ２０，ファイヤーウォールＦ８及びインターネット間におけるＴＣＰ−ＩＰ通信プロトコルと、複数のターミナルＴ１〜Ｔ４における複数のブラウザＢＲからのクライアントの要請とを扱うために、ＡＯＬサーバー（AOLserver^TM）として知られているアメリカオンラインコーポレーション（America Online Corporation）製の標準的なウェブサーバーソフトウェアＷＳが、コンピュータ２０にインストールされている。当該技術分野の当事者には明らかであるように、一般的な通信プロトコル及びトランスポート層アクティビティを扱うものであれば、任意のウェブサーバーソフトウェア又はこれに類似するプログラムを、使用されているネットワークプロトコルに適するものとして用いることが可能である。同様に、この例では、データベース管理ソフトウェアＤＢＭＳ，ＤＢＭＳ８が、コンピュータ２０に接続されているディスク０８等のローカル電子保存媒体に配置されているクライアント側ダイナミックグループレジストリ（dynamic group registry）０７を保存維持するために用いられている。好適な一実施形態では、インフォーミックスコーポレーション（Informix Corporation）によって提供されるイラストラ（Illustra^TM）オブジェクト向け（object-oriented）リレーショナルデータベースソフトウェアによって、オブジェクト向けリレーショナル技術の使用が可能になることから、同ソフトウェアが用いられている。しかしながら、当該技術分野の従事者には明らかであるように、市販されている任意のデータベース管理ソフトウェアを、ディスク０８に保存されているクライアント側ダイナミックグループレジストリ０７のデータを保存維持するために用いることが可能である。同様に、任意の複数の電子保存媒体を複数のディスクの替わりに用いることができる。例えば、十分なランダムアクセスメモリを備えているコンピュータでは、内部メモリを電子保存媒体として用いることが可能である。また図４には、クライアントＣ８のボストンサイトのコンピュータ２０上で実行中のクライアントサイドコミュニケーションサーバーＣＳＳ（本図ではＣＳＳ８）が示されている。好ましい実施態様においては、各カスタマーまたはクライアントのサイトでクライアントサイドコミュニケーションサーバーＣＳＳを用いて、クライアントが内部で作成した全てのコンテンツを制御すると共に、クライアントの外部から但しドメインコミュニケーションサーバーＡ１が制御するドメイン内に配信された全てのコンテンツを受信する。所与のカスタマーのクライアントサイドコミュニケーションサーバーは、他のコンピュータ２０上で実行する２つ以上のサーバーから構成してもよいが、好ましい実施態様では、上記クライアントの各サーバーは、複製機能を使って、確実に各サイトに属するオーソライズド情報が同一になるようにする。各カスタマーが必ずしもドメインのコンテンツ全てにアクセスするようにオーソライズされるわけではないことに留意されたい。実際、本発明は、ドメイン全体のコンテンツにアクセスすることを指令且つ制御できるように限定設計されている。また、好ましい実施態様においては、所与のカスタマーのクライアントサイドコミュニケーションサーバーＣＳＳは、クライアントの外の他のカスタマーとの通信にはドメインコミュニケーションズサーバーを使わなければならない。さて、図５を見ると、ドメインコミュニケーションサーバーＡ１と通信中のいくつかのクライアントの略図が示されている。この図からわかるように、クライアントＣ８は、クライアントＣ８のコンピュータ２０に接続されたローカルディスク０８上にドメインコミュニケーションサーバーＡ１のアドレスを有している。このコンピュータ２０では、クライアントサイドコミュニケーションサーバーソフトウエアＣＳＳ８が実行中である。図５では、ドメインコミュニケーションサーバーＡ１は、コンピュータ２０と、内部に格納されたダイナミッククライアントレジストリー０６を有するローカル記憶媒体（この場合、ディスク４０）とを含むことにも留意されたい。また、ドメインコミュニケーションサーバーＡ１では、従来のＷｅｂｓｅｒｖｅｒＷＳがコンピュータ２０内で、従来のデータベースマネージメントプログラムＤＢＭＳと一緒に実行中であるのがわかる。本発明の好ましい実施態様においては、ドメインコミュニケーションサーバーソフトウエアＤＳＳも、ＷｅｂｓｅｒｖｅｒＷＳおよびデータベースソフトウエアＤＢＭＳと協同して実行する。ドメインコミュニケーションサーバーソフトウエアＤＳＳが、ディスク４０上のダイナミッククライアントレジストリー０６におけるこのドメインの一部である全てのクライアント（この場合、Ｃ１−Ｃ８）のリストを保持していることがわかる。好ましい実施態様において、ＷｅｂｓｅｒｖｅｒＷＳは、ＡｍｅｒｉｃａＯｎｌｉｎｅ社のＡＯＬｓｅｒｖｅｒ製品である。というのは、この製品もオブジェクト指向テクノロジーが使用できるからである。Ｕｎｉｘまたは類似のオペレーティングシステムなどのオープンシステムにおいては、共有オブジェクトをＣ＋＋言語で作り出すことができる。Ｃ＋＋プログラミング言語において、共有オブジェクトは平易にコンパイルされたコードである。ＡＯＬｓｅｒｖｅｒは、ＷｅｂｓｅｒｖｅｒＷＳにレジスターされたＵＲＬから共有オブジェクトをダイナミックにイニシャライズする能力を有している。従って、これらの共有オブジェクトはコールバックを有する。どの共有オブジェクトをロードするかは、ＡＯＬｓｅｒｖｅｒのＮＳＤプロセス（ＡＯＬｓｅｒｖｅｒの実行可能形態）の起動に用いられるイニシャライゼーションファイル内に指定されている。同様に、好ましい実施態様において、ドメインコミュニケーションサーバーＡ１で使用されるＤＢＭＳソフトウエアは、上述のＩｌｌｕｓｔｒａソフトウエアである。また、好ましい実施態様では、ドメインコミュニケーションサーバーまたはクライアントサイドコミュニケーションサーバーとして用いられるコンピュータは、メーンフレームからミニコンピュータ、ワークステーションまたはパソコンにいたるまで、多くの市販タイプのもののいずれを用いてもよい。本発明の好ましい実施態様は、「ミドルウエア」(現存のオペレーティングシステムソフトウエアまたは一般的なベーシックコミュニケーションソフトウエアと交換または置換できないソフトウエアを意味する）として多くの現存の装置と共に稼動するように設計されている。「ミドルウエア」はウェブブラウザなどのアプリケーションソフトウエアの代替物ではなく、「中間」で稼動するのである。好ましい実施態様において、ドメインの特性や範囲は、いくつかの異なるファクターにしたがって決定することができる。図５に示されているように、ドメインコミュニケーションサーバーは、いくつかの異なる会社または団体のイントラネットを緊密に操作できるように接続することが可能なので、１つの会社が１つの産業セグメントのドメインコミュニケーションサーバーを操作し、また一方、そのセグメントに属する会社は各自のクライアントサイドコミュニケーションサーバーを持つということも考えられる。例えば、図５では、ドメインコミュニケーションサーバーＡ１を、申込者の代理人の法人本部に設置された金融業界の投資銀行産業セグメントのコンピュータシステムとすることもできるし、また一方、クライアントＣ１−Ｃ８を、投資銀行および投資管理会社とすることもできる。しかし、当業者には容易にわかるように、産業セグメントは、法律を扱う産業でも、自動車製造業でも、製薬業であってもよいし、他の多くの大手または小規模の産業セグメントのいずれであってもよい。例えば、産業セグメントが自動車製造業の場合、ドメインコミュニケーションサーバーＡ１はサービス会社が操作することになろう。従って、自動車製造業者は、サプライアーやディーラーと密接なコミュニケーションをはかることができよう。もう一度図５を見ると、この場合、クライアントＣ１およびＣ２は競合する自動車製造業者であり、クライアントＣ３−Ｃ５は大手のパーツサプライアーであってよく、一方、クライアントＣ６−Ｃ８はディーラーであってよい。本発明の好ましい実施態様において、製造業者Ｃ１は確実な方法でサプライアーＣ３、Ｃ４、Ｃ５と緊密なコミュニケーションをとることができ、一方、その競合業者である製造業者Ｃ２もまたこれらのサプライアーと密接にコミュニケートできる。さらに図５では、本発明の好ましい実施態様において、ドメインコミュニケーションサーバーＡ１とクライアントサイドコミュニケーションサーバーＣ１−Ｃ８はそれぞれ互いに独立に起動およびシャットダウン可能であることに注目されたい。例えば、ドメインコミュニケーションサーバーＡ１の一部であるコンピュータ２０は、クライアントサイドコミュニケーションサーバーと連絡していなくても、自動的にブーツ（起動）できる。この自動起動が起こると、ドメインコミュニケーションサーバーＡ１は自動的にイニシャライズされ、サーバーに何かメッセージが入っていないかどうかをチェックする。メッセージがなければ、サーバーＡ１はメッセ−ジを受信するまで待つ。クライアントコミュニケーションサーバーＣ１−Ｃ８もそれぞれ異なる時期に各自のコンピュータをブーツさせることができる。例えば、クライアントサイドコミュニケーションサーバーＣ８のコンピュータ２０がドメインコミュニケーションサーバーＡ１のコンピュータより前にブーツされると、クライアントサイドコミュニケーションサーバーＣ８は自動的にイニシャライズされ、ドメインコミュニケーションサーバーＡ１にレジスターするために、下記の固有のＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ（ｓ）(ＵＲＬ(ｓ))を含むメッセージを送って、ドメインコミュニケーションサーバーＡ１にレジスターされるように試みる。好ましい実施態様においては、ドメインコミュニケーションサーバーＡ１がまだブーツされていない場合、これらのメッセージはクライアントサイドコミュニケーションサーバーＣ８で待ち行列に入り、後で再び送信される。当業者には容易にわかるように、レジストレーションメッセージを待ち行列に入れる代わりに、時間間隔をおいて簡単に再生させることができる。好ましい実施態様において、クライアントサイドコミュニケーションサーバー及びドメインコミュニケーションサーバーによって送信されるＵＲＬは、少なくとも、受信者によって行なわれるファンクションの名前（例えば、この場合はレジストレーション）を含んでいるのが普通である。多くの場合、これらのサーバーもオブジェクトを指向するかまたはオブジェクトを含んでいる。また、好ましい実施態様において、同一の会社またはクライアント内にあるクライアントサイドコミュニケーションサーバーは、通常そのクライアントが使用しているドメインコミュニケーションサーバーＡ１が稼動していなくても、互いに通信することができる。クライアントＣ２について、このケースを示すために、ちょっと図１ａに戻って見ると、クライアントサイドコミュニケーションサーバーＣ２−ＨＫ、Ｃ２−ＮＹおよびＣ２−ＬＮはどれもみな、ドメインコミュニケーションサーバーＡ１がまだ稼動していないときでも、クライアントＣ２のＷｉｄｅＡｒｅａＮｅｔｗｏｒｋＣ２ＷＡＮ内部で互いに通信することができる。要するに、本発明の方法および装置に従って設定され且つコンテンツを作成したり見たりするようにオーソライズされている内部ユーザーおよびグループは、ドメインコミュニケーションサーバーＡ１がオフラインであったりダウンしているときでも、本発明ならびに本発明の組織化および索引特性を用いれば互いに通信することができる。通常、クライアントＣ２のクライアントサイドコミュニケーションサーバーによってドメインコミュニケーションサーバーＡ１に送られたであろうメッセージは待ち行列に入り、ドメインコミュニケーションサーバーＡ１が起動されると送信される。当業者には容易にわかるように、所望の場合には、クライアントサイドコミュニケーションサーバーとドメインコミュニケーションサーバーとの通信に他の方法を用いてもよい。例えば、クライアントサイドコミュニケーションサーバーが互いに通信可能になる前にドメインコミュニケーションサーバーを操作可能するように命令する方法を用いることもできる。クライアント側コミュニケーションサーバーの始動ここで図１４に移ると、クライアント側のコミュニケーションサーバーの初期化の流れ図の概略が示されている。ステップ４００でユーザーは新しいクライアント側コミュニケーションサーバーのスタートアップを開始する。ステップ４０２で、サーバー共有オブジェクトを作成した後、ステップ４０４、４０６、４０８と４１０それぞれでクライアント側サーバー共有オブジェクト、アドムインサーバー供給オブジェクト、ツールスサーバー共有オブジェクト、エージェントサーバー共有オブジェクトを作成する。共有オブジェクトが図１５のステップ４１２で作成されたら、さらに加工を続ける。図１５のステップ４１４では、クライアント側コミュニケーションサーバー（図８ｂにリストされた内の主要なもの）で利用されるＵＲＬ’ｓをｗｅｂサーバーＷＳで登録される。次に、作業グループオブジェクトをステップ４１６が作られる。本発明の別の観点を図１６の流れ図に示す。そこに示されるように、ステップ４２０ではクライアント側コミュニケーションサーバーが初期化され、ついでステップ４２２で、そのコンピューター２０上で実行されるｗｅｂサーバーＷＳでそのＵＲＬＳが登録される。ステップ４２４では、クライアント側コミュニケーションサーバーはドメインコミュニケーションサーバー上の登録機能を呼ぶ。ステップ４２６では、ドメインコミュニケーションサーバーがクライアント側コミュニケーションサーバー上のアドホックコンテント作業機能を呼び出し、次いでステップ４２８でクライアント側コミュニケーションサーバーはドメインサーバー上の作業機能を呼び出す。次に、ステップ４３０でドメインコミュニケーションサーバーはクライアント側コミュニケーションサーバー上にアドホックコンテントコンシューマー機能を呼び出し、最後にクライアント側コミュニケーションサーバーはドメインコミュニケーションサーバー上にインデックス機能を呼び出す。ドメインコミュニケーションサーバーの始動次に図２０ａを参照すると、ドメインコミュニケーションの初期化の極めて単純化され外観が示されている(詳細は以下に提供される)。ステップ５００で、ドメインコミュニケーションサーバーはそれ自身とダイナミッククライアントレジストリー０６を初期化する。次にドメインコミュニケーションサーバーはステップ５０２で、メッセージ（クライアント側コミュニケーションサーバーから来るレジスタの要求の様な）があるかチェックする。メッセージが無い場合には、ドメインコミュニケーションサーバーは何かアクティビティーがあるまで待機するだろう。(以下に見られる如く、好適な実施態様ではドメインコミュニケーションサーバーは実際にクライアント側コミュニケーションサーバーがまだアクティブか定期的にチェックを入れる。)。また図２０ａでは、クライアント側コミュニケーションサーバーからの自身のドメインコミュニケーションサーバーによる登録要求の様なメッセージがやって来ると、ドメインコミュニケーションサーバーはステップ５０４で、以下詳細に記述される如く、メッセージ自体により指定された様式でメッセージを取り扱う。クライアント側コミュニケーションサーバーダイナミックグループ登録次に図２０ｂを見ると、クライアント側コミュニケーションサーバーがダイナミックグループ登録０７の初期化または更新に使用するプロセスを描いた流れ図が示されている。ステップ８００に始まり、ユーザーはグループ登録０７に入れるグループに名称を与え、ついでステップ８０５でこのグループへのアクセスのタイプが一般か制限されたものか（これら用語は下記に詳細記す）を指示する。次に、ステップ８１０でクライアント側コミュニケーションサーバーは、このグループがステップ８１５で選択されるベースコンテント（主題により特定される）か、またはアドホックコンテントが選択されるアドホックコンテント（ソースで特定される）であるかチェックする。以下詳細に示す如く、好適な実施態様ではその他のタイプのコンテント−混合コンテントや非脱連結型混合コンテントならびにシステムコンテントも利用される。これらの処理は同様である。コンテントを本発明の精神より逸脱することなく複数の方法でグループ分けできることは、当業者には明らかであろう。さらに図２０ｂでは、ステップ８２５でクライアント側コミュニケーションサーバーはコンテントリストをコンフィギュレートする。好適な実施態様では、クライアント側コミュニケーションサーバーは次にステップ８３０で、ローリングリンクフォーマットが望まれるか固定リンクフォーマットが望まれるかチェックし、ステップ８７５または８４０でコンテントリストを更新しタイトルをリスト化し、フォーマットに従い表示する行数を指定する。つぎに、ステップ８４５ではユーザーはダイナミックグループ登録０７内のこのグループのこのコンテントリスト上に表示するコンテントの主題と／またはソースを指定する。ステップ８５０では、ユーザーは認定化メンバーを選択し、ステップ８５５でメンバーをレビューして、最後にステップ８６０でユーザーはグループのコンフィギュレーションをレビューできる。図２１は、クライアント側コミュニケーションサーバーが、自身の会社内（ステップ９０５と９１０参照）または会社外（ステップ９１５と９１０参照）の他のクライアント側コミュニケーションサーバーと通信するためのクライアント側コミュニケーションサーバー共有オブジェクト（コンパイルされたＣ＋＋コード）を作成するか決める流れ図を示す。図２２から２６は末端でのブラウザー使用向けに本発明により作成されるインターラクティブ表示のブロック図である。これらの図は本発明の好適な実施態様に於ける、ダイナミックグループ登録０７上にグループを作成する上記ステップの例示である。例えば図２２は、どの様にユーザーが新しいユーザー名を入力するかを示しており、そして図２３はユーザー名等のユーザー入力可能なものに特異的な情報をどの様にアカウントするか例示している。図２４には、どの様にクライアント側コミュニケーションサーバーが認定権（詳細は下記）を確立するプロセスを開始するかを示している。図２５ａと２５ｂは、全域によるコンテントの地図的配置法の１例を例示している。示す様に、ユーザーはこの選択に対する彼または彼女の選択を指定するよう求められる。次に、図２５ｃでは、サンプル分布オプションが示されている。次に、図２６ａではクライアント側コミュニケーションサーバーはユーザーが新しいグループメンバーが再分布認定権（この語は以下に詳細記す）を持つかどうか指定させることができる。もし指定させる場合には、ユーザーは図２６ｂに示す様に、この再分布権を限定または非限定ベースに内部メンバーだけまで拡張するか、または限定または非限定ベースに外部メンバーまで拡張するか指定することができる。次に、図２６ｃには新しいメンバーを制限グループにアクセスさせるか尋ねるサンプルスクリーン表示が示されている。もしユーザーがスクリーンに対してはいと回答した場合、図２６ｄにはどの様にユーザーが指定を求められて、新しいメンバーにどの制限グループをアクセスさせるかが決められるか、またどの能力 −即ち、レビュアーかコントリビューターか、あるいはリディストリビューターかアドミニストレイターか、あるいはこれらの全てか、または幾つかの組み合わせなのかが決められ様子が示されている。図２６ｅには、新しいユーザーがどの種類の外部グループアクセスを持つか指定するように求めるサンプルスクリーン表示が示されている。関連して財務集団例に戻ると、図２６ｅのディスプレイには、新しいメンバーが他の参加会社−同一インテリジェントエクストラネット内にある会社Ｃ１、Ｃ２とＣ３に対して書類を作成し配布することを”許可する”ことが極めて容易であることが示されている。ユーザーが新しいメンバーを加えることに関する質問に回答し終わると、クライアント側コミュニケーションサーバーはこれら変更を反映するダイナミックグループ登録を終了する。当業者に明らかなように、クライアント側コミュニケーションサーバーは自己独立型の存在であり、現行のイントラネット管理ツールに比べ遥かに優れ、また簡便な社内ツールを簡単に提供するのに使用できる。クライアント側コミュニケーションサーバーはまた強力な発行コントロールをしても作動する。新しいメンバーとグループをクライアント側コミュニケーションサーバーに加えるかどうかのスクリーン表示に現れる質問に答えるだけで、ユーザーはクライアント側コミュニケーションサーバーに認知されている個人やグループの情報をこれまで以上に組織化し、索引し、コントロールすることができる。図１ａに示された財務集団例に戻ると、もしこのクライアント側コミュニケーションサーバーがホンコン、ニューヨークとロンドンに支店を持つ銀行Ｃ２に設定されているとすると、(図１ａの)、それ自身を複製してホンコンにクライアント側サーバーＣ２−ＨＫが、ニューヨークにはクライアント側サーバーＣ２−ＮＹが、そしてロンドンにはＣ２−ＬＮを置くことができる。以下の論議より分かるように、ロンドンの閲覧者は彼に受け取り権が認められている指定情報を呼び出し、見てその内部にコメントすることができ、そしてもし彼がこの種の再配布権を持っていれば、ホンコンやニューヨークの同僚にこのコメントを閲覧させることができる。次に図６ａを見ると、ダイナミッククライアント登録０６内のドメインコミュニケーションサーバーＡ１により保持されている典型的なクライアント情報が示されている。ダイナミッククライアント登録０６はドメインクライアント表６０ (ここでは略式形式で示されている)、ドメインクライアントソースリスト６６、ドメインクライアントオブジェクト表６２とドメインクライアントオブジェクト行き先リスト６８、そして索引表６４とチャンネル表６１、チャンネルコンテント表６３，チャンネルテンプレート表６５を含んでいる。ドメインクライアント表６０は指定ドメイン内にある全てのクライアント側コミュニケーションサーバーをリストしている。上記の如く、クライアントは１つ以上のクライアント側コミュニケーションサーバーを持つことができる(例えば、クライアントが図１ａのクライアントＣ２やＣ４の様に世界をまたぎ複数のサイトを持つ場合)。したがって、一好適態様において図６Ｂに示されるように、ダイナミッククライアントレジストリ０６のドメインクライアントテーブル６０におけるエントリーは、各クライアントサーバーについて、独自クライアントサイドコミュニケーションサーバーネーム６０ａ、サーバーがアクティブな状態であるか否かを示すインジケーター６０ｂ、このサーバーを所有する団体や企業あるいは顧客の名前を示す独自企業識別手段６０ｃ、この企業に関連する映像において再生することのできる企業ロゴ（logo）６０ｅ、並びに、一好適態様において企業のイントラネット内のサーバーロケーションであり、企業識別手段フィールド６０ｃとの組み合わせにより独自の鍵を形成するドメインクライアントサイド識別手段６０ｆを含むものである。当該分野の技能を持つ者には自明なことと思われるが、所望により、各クライアントサイドコミュニケーションサーバーに関して、上記情報より多くの情報又は上記情報より少ない情報、あるいは上記情報以外の情報を包含する構成も可能である。例えば、場合によりロゴに加えて、ＷＷＷ上の企業ウェブページのアドレスを含むことも可能である。代替的に、本発明の精神から逸脱することなく、ロゴフィールド又は仮に例示したウェブページアドレスフィールドを削除することも可能である。図６ａに戻ると、一好適態様において、ドメインクライアントテーブル６０内の各エントリーは、ドメインクライアントソースリスト６６（同図に略式表示）にリンクしている。ドメインクライアントソースリスト６６は、該ドメイン内のクライアントサイドコミュニケーションサーバー間の全接続のリストである。更に図６ａに関し、自動車ドメインを例にとると、競争者Ｃ１−ＰＡとＣ２とが二つの競合製造企業であり、Ｃ３が両者に対する部品供給企業である場合、ドメインクライアントソースリスト６６は図示の如く構成することも可能である。コラム６６ａにおいて、独自企業識別手段、即ちＤＳＣ企業ＩＤは、コラム６６ｂ内の各ソースＤＳＣ各企業ＩＤの隣に表示される。したがって、企業Ｃ１−ＰＡは、Ｃ１−ＰＡ自身と供給者Ｃ３からコンテントを受け取ることが可能である。企業Ｃ１−ＰＡが、競合他社Ｃ２から何らのソース情報を受け取る権利を与えられているものとして示されていないことに注目されたい。同様に、企業Ｃ２は、自身と供給企業Ｃ３からソースコンテントを受け取ることが可能であるが、企業Ｃ１からはできない。このことは、上記仮想パイプが如何に形成されるかを示している。更に図６ａに関し、ドメインクライアントオブジェクトテーブル６２が同様に示されている。ドメインクライアントオブジェクトテーブルは、ドメインコミュニケーションサーバーが、与えられたドメイン内における任意の正当なクライアントサイドコミュニケーションサーバーから受け取った全ての分散オブジェクトを、含んでいる。上記のようなオブジェクトを受け取るに際して、ドメインコミュニケーションサーバーは、上記オブジェクトに対し、一オブジェクトの検索を可能にする正当なアクセス権を持つ全てのクライアントサイドコミュニケーションサーバーを通知する。ドメインクライアントオブジェクトテーブル６２内の各エントリーは、ドメインクライアントオブジェクトの受け取りを許可され該オブジェクトが埋め込まれる全てのクライアントサイドコミュニケーションサーバーサイトを一覧表示する異なるドメインクライアントオブジェクト埋め込みテーブル６８を指すものである。一好適態様において、ドメインクライアントIohandleは、クライアントサイドコミュニケーションサーバーに送られる分散コンテントを指すドメインクライアントオブジェクトテーブル６０内の大型オブジェクトハンドルである。図６ｂについて簡単に説明すると、ドメインクライアントオブジェクト埋め込みテーブルエントリーと共に、ドメインクライアントターゲットテーブル６８ａは、このオブジェクトの埋め込み先である複数のクライアントサイドコミュニケーションサーバーの全サーバー名を一覧表示するものである。ドメインクライアントに受け取られたコラム６８ｃは、各ターゲットクライアントサイドコミュニケーションサーバーに関し、オブジェクトがドメインコミュニケーションサーバーによって受け取られた時刻を含むものである。ドメインクライアントで処理されたテーブル６８ｄは、各クライアントサイドコミュニケーションサーバーに関し、オブジェクトがクライアントサイドコミュニケーションサーバーによって処理された時刻を含むものである。一好適態様において、このフィールドは、Null（ゼロ）に初期設定され、クライアントサイドコミュニケーションサーバーがドメインクライアントオブジェクトを検索するときにアップデートされる。再び図６ａに戻ると、一好適態様において、一オブジェクトは、クライアントに伝送される任意種類の情報とすることができる。例えば、投資金融業務ドメインにおいて、一投資銀行Ｃ１−ＰＡがそのクライアントのために準備した朝の分析であってもよい。最も簡単には、オブジェクト６２は簡単なアスキーテキスト形式であってもよく、世界共通に読み取り可能なAdobe Acrobat^TMＰＤＦ形式であってもよく、あるいはMicrosoft Word^TM若しくはCorel's Wordperfect^TMのようなワード処理プログラムに特有の形式であっても、Microsoft社のExcel^TM若しくはIBM社のLotus1-2-3^TMスプレッドシートのようなスプレッドシートプログラムであってもよい。同様に、或る企業が既に既存HTML形式のページを有している場合は、これらのページもオブジェクトとすることが可能である。当然に、本発明の一好適態様において、全コミュニケーションに関するコンテントであるオブジェクトは、あらゆる実際上の目的に関して、任意の形式とすることが可能であることが注目されるべきである。例えば、或るオブジェクトが、サウンドを伴うフルカラームービー、あるいは、チップセットのＣＡＤ／ＣＡＭＶＬＳＩ図面若しくは開発中の自動車の機械製図のような複雑なものであってもよい。後者の例、即ち通常は極秘であるＣＡＤ／ＣＡＭ又は機械製図において、本発明によれば、自動車製造企業のような或る企業の設計部門が、請負エンジニアリング会社との間で、計画の進行に応じて図面を交換し、それに注釈をつけることにより非常に緊密且つ安全に仕事を進めていくことが可能となる。本発明の一好適態様においては、セキュアソケット伝送技術を利用するので、伝送されるオブジェクトは送り側クライアントサイドコミュニケーションサーバーで暗号化され、オブジェクトの受け取りを認められたクライアントのみの受け側クライアントサイドコミュニケーションサーバーで解読される。一好適態様において、伝送オブジェクトのこの暗号化及び解読は、セキュアソケット技術及びその同等物若しくは改良物の利用に伴う自動的な副産物である。当該分野の技能を有する者にとっては自明であると思われるが、セキュアソケット又は類似の技術の代わりに、他の暗号化技術を使用することも可能である。例えば、ＲＳＡ暗号化アルゴリズムに基づくＰＧＰのようなソフトウエアを使用する直接暗号化のような技術を利用することも可能である。更に図６ａに関し説明すると、図示のドメインクライアントオブジェクトテーブル６２には、アスキーテキスト形式リポート６２ａ、スライドプレゼンテーション６２ｂ、ワード処理ドキュメント６２ｃ、ムービー６２ｄ、及びマルチプルリポート６２ｅが含まれている。本発明の一好適態様において、オブジェクトはテキスト又はファイルとして表示される。前記第一の項目、即ちアスキーテキスト形式リポート６２ａは、本発明においてはアスキーテキストとして処理される。ドメインクライアントテーブル６２内の他の全オブジェクトはファイルとして処理される。スライドプレゼンテーション６２ｂの場合は、例えば、オブジェクトはドメインコミュニケーションサーバーＡ１へファイルとして伝送され、該ドメインコミュニケーションサーバーから、適当な全クライアントサイドコミュニケーションサーバーが該オブジェクトをやはりファイルとして受け取るものである。クライアントサイトにおいて、端末Ｔがオブジェクトにアクセスするとき、該端末は、該クライアントサイト又はそれに対応するサーバーのいずれかで利用可能な前記ファイルを見る（開く）ための適当なアプリケーションプログラムを有していることが必要とされる。したがって、図６ａに係るスライドプレゼンテーション６２ｂが、Microsoft 社のソフトウエアPowerpoint^TMを使用して作成されたものであるとき、クライアントサイトのビューアーは、スライドをみるために該サイトでMicrosoft社のソフトウエアPowerpoint^TMを利用できる状態にあることが必要とされる(通常この要件は、端末あるいはこの端末がコンピュータである場合にはこの端末のサーバーで、インストールされたアプリケーションソフトウエアを、コピーすることにより達成される)。通常このことは問題ではなく利点であり、その理由は、多くのビジネスパーソナルコンピュータユーザーにとって、ワードプロセッサ、スプレッドシート及びプレゼンテーションソフトウエアのような、実際上標準状態にほぼ達している市販製品が存在することによる。当該分野の技能を持つ者にとって自明なことと思われるが、本発明によれば、ユーザーが上記「標準」製品、更にはファイル上で機能する特別に開発されたソフトウエアプログラムをも使用し続けることが可能になる。このことは、現行のアプリケーションソフトウエア及び従来の開発品に大きな投資をした多数のユーザーにとって重要である。更に図６ａにおいては、ダイナミッククライアントレジストリ０６の一部としてインデックステーブル６４も示されている。該インデックスの値は、与えられた一ドメインに関し同一である。図６ａに示されるように、抵当、取次者、新規発行債権、リサーチ及び当該ドメインのコンテントを秩序正しく表示しうる他のインデックスを含む、金融市場セグメントドメインに対する表示インデックスが示される。ここで図６ｂを参照すると、インデックスＩＤ６４ａ、インデックスデスクリプション６４ｂ、インデックスベースタイプ６４ｃ及びインデックスペアレントＩＤ６４ｄを含むインデックスエントリーが示されている。インデックスＩＤ６４ａは独自のインデックス識別手段である。一好適態様において、インデックスベースタイプ６４ｃは、該インデックスに対するデフォルト形式として、どちらの形式（テキスト又はファイル）が使用されるかを決定するために使用されるが、該インデックスに対する全コンテントはどちらの形式も採りうるものである。インデックスデスクリプション６４ｂは、該インデックスに添付された説明的ラベルである。更にインデックスペアレントＩＤ６４ｄは、このエントリー元のインデックスＩＤである。再び図６ａに戻ると、インデックステーブル６４においては、インデックス１１、即ち新規発行債権がインデックスＩＤ、即ち抵当の下位項目（"child"）であることが解る。更に、インデックス６１、即ち教育は、新規発行債券の下位項目である。一好適態様において、インデックスは必要なだけの多くのレベル（階層）を有することが可能である。更に図６ａに言及すると、一好適態様においては、チャネルコンテントテーブル６３及びチャネルテンプレート６５も作成される。本発明の一好適態様において、チャネルは各種インデックスの組み合わせである。例えば、一チャネルは、最新情報項目を含むような全インデックスからなるものであってもよい。別な一チャネルは、最も頻繁に使用されるインデックスで構成されてもよい。当該分野の技能を有する者にとっては自明なことと思われるが、上記チャネルグループ分けの数及びコンテントは、産業間、あるいは経時と共に変化しうるものである。図面から分かるように、チャネルテーブル６１は、ドメインコンテントを関連カテゴリーへ体系化するために使用される。上記チャネルは次いで、スタートアップ時にクライアントサイドコミュニケーションサーバーへ送られ、セットアップ動作中及びグループ管理の間中使用される。他の好適一態様において、この機能を前記クライアントサイドコミュニケーションサーバー又は内部用ドメインコミュニケーションサーバーを利用するクライアントサイドコミュニケーションサーバー内に包含することが可能である。ここで図６ｂに言及すると、チャネルテーブル６１は、チャネルＩＤフィールド６１ａ、チャネルネームフィールド６１ｂ、及びチャネルデスクリプションフィールド６１ｃを含んでいる。最新情報項目に関して、チャネル名「ホットニュースアイテム」、「新規発行債権、抵当及びリサーチインデックスからの最新情報」のようなチャネルデスクリプションと共に、チャネルＩＤ１が割り当てられてもよい。当該分野の技能を有する者にとっては自明なことと思われるが、ドメインが自動車製造業等の他産業セグメントにある場合は、該インデックス及びチャネルは、異なるトピック及びトピックの組み合わせを表示するものである。一好適態様において、チャネルコンテントテーブル６３は、チャネルを構成するコンテントを決定するために使用される。再び図６ｂにおいて、チャネルコンテントテーブル６３は、チャネルＩＤフィールド６３ａ、チャネルＩＤフィールドと共に独自の鍵を形成するチャネルコンテントＩＤ６３ｂ、コンテントが基本コンテントであるか特別コンテントあるいは他の種類のコンテント（以下に記載）であるかを表示するチャネルタイプフィールド６３ｃ、及び当該チャネル用コンテントに係る一又は複数のソースを表示するチャネルコンテントソースフィールド６３ｄを含んでいる。一好適態様において、チャネルテンプレートテーブル６５は、チャネルコンテントを体系化するために使用される。各テンプレートは、チャネルテンプレートＩＤフィールド６５ａ、チャネルテンプレートＩＤフィールド６５ａと共に独自の鍵を形成するチャネルテンプレートフィールド６５ｂ、コンテントリストの属性を規定するチャネルテンプレート属性フィールド６５ｃ、及びチャネルコンテントテーブル６３内にあるＩＤを説明するチャネルテンプレートソースフィールド６５ｄを含んでいる。ここで第７ａ図を参照すると、本発明の動的グループレジストリ０７の構造と内容がの例示されている。好ましい実施例では、動的グループレジストリ０７は各クライアントにおいて、該クライアントで内部的に作成された全てのコンテントおよび該クライアントによって受信されたドメイン内で作成されたコンテントを取り扱うために使用される。上記のように、各クライアント側通信サーバは、他のファームのクライアント側通信サーバと通信するために、ドメイン通信サーバを使用しなければならない。第７図に示すように、クライアント側動的グループレジストリ０７の主エントリはグループテーブル７０である。グループテーブル７０は特定のファームまたはクライアント内で設定された全グループのリストである。注意されたいのは、ワークグループという用語は図中または本テキスト内に現れるが、グループという用語が一般に好ましく、これと交換可能に解釈可能である。グループは、該グループで使用できるコンテント（コンテントテーブル９０および特定コンテントテーブル９４に指定される）のタイプとソースとを形成するために使用され、情報が受信されるたびに、該グループに関するそれぞれのコンテントリストを作成する。ＣＳコンテントテーブル９０は、オブジェクトＩＤ９０ａ、オーサＩＤ９０ｂ、コンテントリンクオブジェクトＩＤ９０ｃ、コンテントヘッドライン９０ｄ、コンテントファイル名９０ｆ、コンテント情報９０ｇ、コンテントタイムスタンプ９０ｈ、コンテントオリジンサイト９０ｉ、コンテントオリジンオブジェクト９０ｊおよびコンテントデータ属性９０ｋによりコンテントを形成する。コンテント作成時に、このコンテントは該特定タイプのコンテントを要求した全グループに自動的に付加される。特定コンテントテーブル９４は該情報のソースにより特定コンテントを形成し、またはパブリッシャが該特定コンテントをあるグループに指定したときに該グループに付加される。第７図のテーブル７０から明らかなように、好ましい実施例では、共有と限定の２個のタイプのグループがある。共有グループはクライアントまたはファーム内の全閲覧者からアクセスできるが、ベースコンテントのみをとり得る。限定グループは、ワークグループ閲覧メンバテーブル８２に指定されたグループのメンバのみが閲覧できる。限定グループはベースコンテント、特定コンテントおよび以降に開発されると考えられる他のタイプのコンテントに対して許されている。特定コンテントは、該グループのオーサおよびパブリッシャ（ワークグループオーサメンバテーブル８０およびワークグループ閲覧メンバテーブル８２）のみによって該グループに付加され得る。さらに第７ａ図のグループテーブル７０において、好ましい実施例では、全グループはフィールドＷＧコミュニティで示されるコミュニティを有し、この中では「既知」である。該コミュニティはファームまたはクライアント内の他のグループに「アドバタイズ」するために使用される。該コミュニティは、該ドメインの内部（ファームまたはクライアントに対してのみ）または該ドメインの外部にアドバタイズされたコンテントの作成者を含む。内部グループは該ファームまたはクライアントの外部では知られていない。外部グループは該ファームまたはクライアントの内部で知られている。ワークグループが、好ましい実施例において、グループテーブル７０のＷＧコミュニティフィールドに値「２」を使って作成者としてセットされれば、該グループは他のグループに対する特定コンテントのソースとしてアドバタイズされる。さらに第７ａ図において、好ましい実施例では、該ファームまたはクライアントの内部のみのグループは、グループテーブル７０のＷＧコミュニティフィールドに「０」を使ってそのことが示されている。グループテーブル７０に示されるように、ファームワイドグループであるワークグループＷＧ１は、この特定な例にリストされたただ１個の内部グループである。外部グループは、グループテーブル７０のＷＧコミュニティフィールドに値「０」を使って示されている。ＷＧコミュニティフィールドに値をセットするために、好ましい実施例はそれらの値の排他的論理和をとって全ての選択肢を決定する。好ましい実施例では、ＷＧグループＩＤはファームＩＤ、サイトＩＤおよびある番号から成るので常に一意的である。当業者には自明であろうが、一意的なグループＩＤまたはＷＧグループＩＤの作成には多くの方法が使用できる。さらに第７ａ図において、ワークグループベースコンテントテーブル７４は、あるベースコンテントが内部的にまたは外部的に作成されたときに、各ワークグループが受信を望むベースコンテントを決定するために使用される。ベースコンテントはコンテントタイプ（ＷＧＢＣインデックスＩＤ）によって選択され、共有と限定の両ワークグループによって受信される。特定コンテントタイプが受信されると、該ワークグループのコンテントリストヘッドラインが更新される。ワークマスタリストテーブル７６は該リストに関する記述テキスト情報を提供する。再び第７ａ図において、ワークグループ特定コンテントテーブル７８は、各あるベースコンテントが内部的にまたは外部的に作成されたときに、ワークグループが受信を望むベースコンテントを決定するために使用される。特定コンテントは該コンテントのインデックスでなくソースによって決定される。該特定コンテントのソースは、上記のように、既に自身を「アドバタイズ」したグループである。ミックスコンテントは特定コンテントとベースコンテントの組み合わせである。また第７ａ図において、ワークグループオーサメンバテーブル８０は、オーサとこれらのオーサがそれぞれのグループに特定コンテントを付加するのを許すことを指定したグループとから成るリストを含む。オーサはファームまたはクライアント内のオーサのリストから選択される。グループもファームまたはクライアント内のグループのリストから選択される。このテーブルへのエントリは新しいコンテントの作成者であることを指定したグループにのみ存在する。ここに示すワークグループオーサメンバテーブル８０の例では、ワークグループオーサ識別子ＷＧＡＭａｕｔｈｏｒＩＤがある。このフィールドは、以下に示す閲覧者テーブルのＶｉｅｗｅｒＩＤにリンクされる。ワークグループオーサ識別子ＷＧＡＭａｕｔｈｏｒＩＤは該メンバが属するこのクライアント内の一意的なグループを識別する。この値は、グループテーブル７０のＷＧｇｒｏｕｐＩＤにリンクされる。第７ａ図に示す例では、同一のオーサ、ｔｂｕｒｎｓはワークグループ２ＷＧ２とワークグループＷＧ３とのメンバとしてリストされている。フィールドワークグループオーサメンバリストリクトＭＧＡＭｒｅｓｔｒｉｃｔは、好ましい実施例では、オーサが本ワークグループの内容を使用する各ワークグループに送信を個別に「許可」されていると考えられる場合に、真にセットされるブール値である。この値が偽にセットされていれば、オーサは本ワークグループの内容を使用するいずれのワークグループにも送信できる。さらに第７ａ図において、ワークグループ閲覧メンバテーブル８２は全ワークグループの閲覧者のリストを含む。あるワークグループの閲覧者メンバだけがワークグループのコンテントを閲覧するためにアクセスできる。あるワークグループの全閲覧者はファームまたはクライアントの有効な閲覧者のリストから選択される。ワークグループのアドミニストレータ（ＷＧＶａｄｍｉｎフィールドに指定される）は該グループに関するメンバと任意のメンバの属性とを決定することが許されている。グループのコンテントの配布は閲覧者属性フィールドＷＧＶＭａｔｔｒｉｂｕｔｅによって制御される。ここで示す例では、ワークグループ２ＷＧ２の閲覧者、ｔｍａｌｏｎｅとｔｂｕｒｎｓはワークグループ２ＷＧ２に対するアドミニストレータである。好ましい実施例では、閲覧者属性フィールドＷＧＶＭａｔｔｒｉｂｕｔｅにセット可能な値はが５個である。すなわち、ＤｉｓｔｒｉｂｕｔｅＮｏｎｅ（配布なし）ＤｉｓｔｒｉｂｕｔｅＩｎｔｅｒｎａｌ（内部配布）ＤｉｓｔｒｉｂｕｔｅＥｘｔｅｒｎａｌ（外部配布）ＤｉｓｔｒｉｂｕｔｅＩｎｔｅｒｎａｌＲｅｓｔｒｉｃｔｅｄ（制限付き内部配布）ＤｉｓｔｒｉｂｕｔｅＥｘｔｅｒｎａｌＲｅｓｔｒｉｃｔｅｄ（制限付き外部配布）好ましい実施例では、全選択肢を決定するために、これらの値も排他的論理和をとられる。当業者には自明であるが、あるメンバの属性を示す方法として、他の各種方法が使用できる。再び第７ａ図において、住所録テーブル８４は、住所録グループ識別子ＡＢｇｒｏｕｐＩＤのメンバとして、あるオーサまたはパブリッシャがコンテントの配布を許されているグループのリストを含む。言い換えれば、ＡＢｇｒｏｕｐＩＤは、指示されたオーサまたはパブリッシャにワークグループのコンテントの配布を許可したワークグループの一意的なＩＤである。この値はグループテーブル７０のＧｒｏｕｐＩＤにリンクされる。住所録送り先フィールドＡＢｄｅｓｔｉｎａｔｉｏｎは、該オーサまたはパブリッシャがコンテントを配布できるグループのファームＩＤとワークグループＩＤとを含む。好ましい実施例では、住所録テーブル８４の住所録属性フィールドＡＢａｔｔｒｉｂｕｔｅは、ワークグループがこのオーサまたはパブリッシャにノート（注意事項）を該コンテントに付加することを許す場合には真にセットされ、許さない場合には偽にセットされるブール値である。さらに第７ａ図において、オーサ権利テーブル８８は、あるオーサが作成可能なコンテントのタイプを決定するのに使用される。このテーブルは３個のフィールドを含む。すなわち、オーサ識別子ＡｕｔｈｏｒＩＤ、オーサインデックス識別子ＡｕｔｈｏｒＩｎｄｅｘＩＤ、オーサ属性ＡｕｔｈｏｒＡｔｔｒｉｂｕｔｅである。好ましい実施例では、オーサが作成できるコンテントタイプ（オーサ属性フィールドに指定される）はファームまたはクライアントによって決定される。これによりクライアントは自身の内部的方針を、他者が設定した方針の受け入れもしくは特定な外部システムの制限の受け入れを余儀なくされることなく、上記のような事態に対して定義し実施できる。全てのオーサは該ファームまたはクライアントの有効な閲覧者でなくてはならない。好ましい実施例では、各オーサは指定されたコンテントについて内部ブロードキャストに関して最小限のオーサ属性を持つ。好ましい実施例において、可能な値は以下のとうりである。ＩｎｔｅｒｎａｌＢｒｏａｄｃａｓｔ（内部ブロードキヤスト）０ＩｎｔｅｒｎａｌＳｅｌｅｃｔｉｖｅ（内部セレクテイブ）１ＥｘｔｅｒｎａｌＢｒｏａｄｃａｓｔ（外部ブロードキャスト）２ＥｘｔｅｒｎａｌＳｅｌｅｃｔｉｖｅ（外部セレクティブ）４これらの値は、好ましい実施例では、全選択肢を決定するために排他的論理和をとられる。当業者には自明であるが、このような値の定義および実施については、他の方法の使用も可能である。図７ａにおいて、ビゥーアーテーブル８６は、許可されたクライアントまたは企業における正当なユーザーまたはビゥーアー全員のリストを含む。このテーブルは、特定のユーザーまたはビゥーアーがクライアントのイントラネットのメンバーであるか決定するのに使用され、ユーザーまたはビゥーアーがこのテーブルに載っていればクライアントのイントラネットが許可されアクセスするのに使用される。このテーブルに加えられたユーザーまたはビゥーアーは、グループテーブル７０のＷＧ会員フィールドに明記されるように、共通のクライアントまたは企業のワークグループすべてに対してアクセスが許可される。図８ａを参照すると、ドメイン通信サーバーの話に戻るが、主なドメイン通信サーバーＵＲＬのリストが示されている。前記のように，好適な実施例において、ドメイン通信サーバーはＡＯＬサーバーソフトウェアを用いて実行される。仮想サーバーを作成する際、共用オブジェクトを動的に（ダイナミックに）ロードできるからである。本発明の好適な実施例においては、オブジェクト指向プログラミング技術が用いられるが、プログラムが実際に実行されるまで正確なタイプがわからないオブジェクトに対するプロシージャを作成できるからである。また、オブジェクト指向技術によれば、システム実行者は共用オブジェクト例えば、ひとつ以上のファンクションまたはプログラムで呼び出されるコンパイルされたＣ++コードを定義し使用することができる。例えば、ＡＯＬサーバーにおいて、どの共用オブジェクトをロードするかは、ＡＯＬサーバーのＮＳＤプロセスの開始時に使用される初期化ファイルによって特定される。本発明の好適な実施例において、‘domainserver.so’（または、ＮＴヴァージョンでは‘domainserver. dll’として知られている）と名付けられた共用オブジェクトは、ＡＯＬサーバーが始動するときロードされる共用オブジェクトとして指示される。好適な実施例において、ＡＯＬサーバーアプリケーションプログラムインターフェイス（ＡＰＩ）が用いられる。ＡＯＬサーバーによってロード可能な共用オブジェクトを開発できるインターフェイスだからである。ＡＰＩはＡＮＳＩ−Ｃであり、標準プログラミング言語インターフェイスである。従って、ＡＯＬサーバーに基づいたＣとドメイン通信サーバーのオブジェクトに基づいたＣ＋＋との間の橋渡しのためＣ＋＋ラッパーファンクションを要する。ドメイン通信サーバーによって定義されるファンクションには、“ゴー(go)”と“ストップ(stop)”と名付けられた二つがある。当業者には明らかなように，同様の機能を備えたサーバーもしくはプログラムを代わりに用いることができる。仮想サーバーの開始時、ＡＯＬサーバーＮＳＤペアレントプロセスでは、NS_M oduleInitと名付けられたファンクションを探す。これは、ロードされ必要な開始コードを含んでいる共用オブジェクトの全てに対し（ＡＯＬサーバードキュメンテイションごとに）定義されている。本発明のNS_ModuleInitファンクションのドメイン通信サーバーは二つの責任を負っている。ひとつは，シャットダウン時にペアレントＮＳＤによって呼び出されるシャットダウンプロシージャ“ストップ”を登録することと，二つめは、ドメインサーバーオブジェクトの一例を作成するＣ＋＋ラッパーファンクション“ゴー”を呼び出すことである。“ゴー” を呼び出すことによって発生したドメインサーバーオブジェクトを一掃するのはシャットダウンプロシージャ“ストップ”のためである。上記のように、本発明の方法と装置によるドメイン通信サーバーは、そのドメインによって様々なクライアント側通信サーバーとの内容の分配および収集ができる。また、どのクライアント側通信サーバーが互いに通信しているが制御し、スイッチングポイントとして機能する。ドメイン通信サーバーの作成は、ラッパーファンクションｇｏ０によって必要とされる全てである。ドメイン通信サーバーオブジェクトを作成する際、次の工程が行われる。まず、ドメイン通信サーバーは、仮想サーバーの“認識された”名前を（他のものから）特定し基本的なデータベースマネージャーにアクセスするローカル変数をセーブする。次に、ドメインによって使用される、ドメインの内容の全てを組織化するための有効なカテゴリーがテーブルインデックスからロードされ、(図６ｂ参照)インデックスオブジェクトとして内部に記憶される。第三に、ドメイン通信サーバーは、このドメインで知られている全ての有効なドメインクライアント、それらのネットワークアドレス、およびどのクライアントが互いに通信可能であるかという(図１ａに示されるような)仮想パイプを決定する。有効なクライアント、クライアント通信サーバー、および各仮想パイプは、ドメインクライアントとＤクライアントソースの各テーブルにおいて見られ、ドメインクライアントオブジェクトとして内部に記憶される。第四に、クライアント側通信サーバーサイトで新たなグループが作成されるとき、ドメイン通信サーバーは、ドメインのクライアントによって使用される、前もって定義されたテンプレートを決定する。クライアント側通信サーバーによって何が消費されるか設定する際、これらのテンプレートは、ドメインのインデックスオブジェクトおよびネットワークプロデューサーを更に組織化したフォーマットに組織化するのに使用される。これらのテンプレートに関する情報は、図６ａに示されるチャネル、チャネル内容、およびチャネルテンプレートの各テーブルに示され，チャネルオブジェクトとして内部に格納される。最後に、ドメイン通信サーバーは，図８に示されるドメイン通信サーバーが扱うＵＲＬ(Uniform Resource Locators)と、ＵＲＬが要求されるとＡＯＬサーバーペアレントＮＳＤプロセスが呼び出すドメイン通信サーバーにおける対応するコールバックファンクションとを、ＡＯＬサーバーペアレントＮＳＤプロセスで登録する。これらの登録されたＵＲＬは、ドメイン通信サーバーと有効なクライアント側通信サーバー間でドメインを用いて通信するのに使用される。この結果，登録されたＵＲＬを介して，クライアント側通信サーバーとドメイン通信サーバー間で情報がやり取りされる。やり取りされる情報は全て、永続的なオブジェクトとして従来の技術で知られている形式（すなはち、ストリーム形から再格納可能なオブジェクト）であり、各ＵＲＬを介して検索され及びまたは分散される。下記は、ＵＲＬ、登録されている合法的な方法、及び好適な実施例にそれぞれ関連したイベントクラスの一覧である。ＵＲＬ方法イベントクラス /Register GET CSS登録 /Indexes GET CSS登録及び登録変更 /Consumer GET CSS登録及び登録変更 /Producers GET CSS登録及び登録変更 /Channels GET CSS登録及び登録変更 /Unregister GET CSS登録 /Status GET 状況 /DistributeObject GET 内容複写 /CollectObject GET 内容複写 /Refresh GET 登録変更 /FirmLogo GET CSS登録 /InternalServers GET CSS登録 Status/ReloadIndexes POST 状況 /Status/CSSStatus GET 状況スタートアップ後、ドメイン通信サーバーは、６０秒ごとにドメインにおける各有効なクライアント側通信サーバーの現状をチェックし、過去５分間に何も動きが記録されていないサーバーをピングするタイマープロシージャを組み込む。好適な実施例において、ピングとは単にクライアント側通信サーバーから戻される状況を求めるメッセージである。クライアント側通信サーバーをピングしようと試みるドメイン通信サーバーの一例は、下記のとおりである。 https://validCSS.com:84/Ping このＵＲＬに応答して、好適な実施例のクライアント側通信サーバーは、ドメイン通信サーバーに合図するＨＴＴＰ状況コード２００を返す。クライアント側通信サーバーをピングすると、現状況を決定し、クライアント側通信サーバーを立ち上げ、起動し、ドメイン通信サーバーに登録することを確保する。クライアント側通信サーバーがピングメッセージに応答すると、ドメイン通信サーバーは、クライアント側通信サーバーが現在すでに登録されているかどうかチェックし、その際クライアント通信サーバーに登録する(クライアント側通信サーバーがドメインサーバーよりも長く稼動しているのならば、再登録する)よう試みるか問う。もしクライアント側通信サーバーが現在登録されているなら、ドメインサーバーは、クライアント側通信サーバーに最後にコンタクトした時間を記録し、コンタクト前に発生する５分以上のラグが再び確立されるまでクライアント側通信サーバーにピングしない。もしクライアント側通信サーバーがピングに応答しなければ、ドメイン通信サーバーはクライアント側通信サーバーが登録されていないものと記録し、応答が戻ってくるまで６０秒ごとにクライアント側通信サーバーをピングするよう試みる。一旦初期化されると、単に、ドメイン通信サーバーはドメインによって発生したイベントに応答する。ドメイン通信サーバーは、クライアント側通信サーバーにこのイベントの効果を知らせるのはもちろんのこと、イベントが有効であることを確証することができる。上記に述べたように、これはＵＲＬの扱いを介して行われる。以下は、ドメイン内で発生し得る事象クラスと関連する動作を示すリストである。 1. クライアントサイド通信サーバのレジストレーションドメイン通信サーバでのクライアントサイド通信サーバのレジストレーションは、クライアントサイド通信サーバが、そのドメイン通信サーバから"Register" URLをリクエストする際に（ドメイン通信サーバのアドレスが、ドメイン通信サーバを起動する際に使用する初期化設定ファイル内に見つかった際に）開始する。好ましい実施例において、このURL様式は"DomainServer:/Reglster?ID=CSS"であり、ここで、Domain Serverはプロトコル、リクエストを行う側のマシンネーム（およびポート）であり、ID変数はCSS'sプロトコル、マシンネーム（またはポート）である。この方法ではプロトコルが指定されているので、ドメインが標準HTTPまたはSSLレイヤのどちらを使用するかはトリビアルである。別の好ましい実施例では、本発明はX.500 Lightweight Directory Access Protocol(LDAP) を実現する。レジストレーションを試みるクライアントサイド通信サーバの１例は次のようなものである。 https://myDomainServe.com:81/Register?ID=https://valid CSS.com:84 次に、ドメイン通信サーバは、DClient Objects（スタートアップの時点でロードしている）の内部コレクションをチェックすることにより、IDによって指定されたロケーションがこのドメインの有効なロケーションであることを証明する。リクエストの妥当性が検査されると、ドメイン通信サーバは、ClientSource Objectsのリストをパッシングすることにより、ダイナミッククライアントレジストリ06から、このクライアントサイド通信サーバが使用可能なクライアントサイド通信サーバ「仮想パイプ」へ戻る。ダイナミッククライアントレジストリ06は、形成するインターネットの仮想コミュニティを可能にするリポジトリとしての役割を果たす。好ましい実施例において、妥当性検査には、ドメイン通信サーバがレジスタクライアントサイド通信サーバサイトからContentProducerとContentConsumer Obj ectをリクエストすることが必要である。クライアントサイド通信サーバからの返答は、各オブジェクトのストリーム形式である(ストリーミングは、ほとんどのオープンシステムで使用されるデータの入力/出力形式である)。オブジェクトが、ドメイン通信サーバにおいて再度作成されて局所的に収集される。どのCont entProducerとContentConsumerがどのクライアントサイド通信サーバで使用可能であるかを、既に確立されている「仮想パイプ」のリストを調べながら決定することはドメイン通信サーバの責任である。クライアントサイド通信サーバにContentProducer Objectsの登録をリクエストするドメイン通信サーバの１例は次のとおりである。 https://validCSS>com:84/AdhocContentProducers クライアントサイド通信サーバにContentConsumer Objectsをリクエストするドメイン通信サーバの１例は次のとおりである。 https://validCSS.com:84/AdhocContentConsumers 第8a図に示すように、好ましい実施例において、クライアントサイド通信サーバの登録は次に、ドメイン通信サーバが扱う他のURLsを使って、ドメインに関する追加の情報をリクエストする。リクエストした情報を返す前に、全ての潜在受取側についての妥当性の検査が行われる。この情報には以下が含まれる。 ●ドメインが使用するIndex Objectsのリストが、第8a図のIndexes URL 106によってリクエストされる。Index Objectsは、与えられたドメイン内にサブジェクト・マター別のコンテンツを編成するために使用され、また、ダイナミッククライアントレジストリ06内のドメイン通信サーバによって集中的にホストされる。Index Objectsは、クライアントサイド通信サーバによって、そのダイナミックグループレジストリ07の１部として使用される。第8a図のIndexes URL 106への応答が、ドメイン通信サーバにそのIndex Objec tsの収集を繰り返させ、これらをストリーム形式に戻させる。ストリーム形式は、クライアントサイド通信サーバサイトにおいてIndex Objectsに翻訳し直され、局所的に収集される。インデックスをリクエストするクライアントサイド通信サーバの１例は次のとおりである。 https://myDomainServercom:81/Indexes?ID=https:..validCSS.com:84 ●第8a図のInternalServers URL 126をリクエストすることによって、Interna lServer Objectsが収集される。同一の企業のものと思われ、そのためクライアントサイド通信サーバの責任がそれらの間で反復するその他全てのクライアントサイド通信サーバのサイトを決定する上で、InternalServerObjec tsがクライアントサイド通信サーバによって使用される。 InternalServers URL 126への応答によって、ドメイン通信サーバが妥当性が確認されたDomainClientに、VirtualServer Objectsの収集を繰り返し、これをストリーム形式で返すよう要求する。このストリーム形式は、クライアントサイド通信サーバサイトにおいてInternalServer Objectsに翻訳し直され、局所的に収集される。同一企業のクライアントサイド通信サーバのみが返される(これにはクライアントサイド通信サーバのリクエストも含まれる)。内部サーバをリクエストするCSSの１例は次のとおりである。 https://myDomainServer.com:81/InternalServers=https://validCSS.com:84 ●ContentProducer Objectのリストが第8a図のProducers URL 110から検索される。ContentProducersは、adhoc and mixed contentの使用可能なソースとしてのダイナミックグループレジストリ07の１部としてクライアントサイド通信サーバによって使用される。ContentProducer Objectsは、プロデューサについての情報と、それが作成するものついての情報を含んでいる。既に確立されている仮想パイプのリストを調べることで、リクエストをしているクライアントサイド通信サーバにどのContentProducersが使用可能であるかを決定することはドメイン通信サーバの責任である。第8a図のProducers URL 110への応答によって、ドメイン通信サーバが、ドメイン内のその他全てのクライアントサイド通信サーバから、リクエストしているクライアントサイド通信サーバで使用可能なContentProducersをストリーム形式において返させる。複数の内部サーバのサイトについて、ストリームは内部プロデューサも含んでいる。このストリーム形式は、クライアントサイド通信サーバにおいてContentProducer Objectに翻訳し直され、局所的に収集される。 ContentProducersをリクエストするクライアントサイド通信サーバの１例は次のとおりである。 https://myDomainServer.com:81/Producers?ID=https://validCSS.com:84 ●第8a図のConsumers URL 108を介して、ContentConsumer Objectsのリストがリクエストされる。そのプロデュースグループのどれがコンテンツをリクエストするコンシューマを有するかを決定するために、ContentConsumersが「ドメインレジストリ」の１部としてクライアントサイド通信サーバによって使用される。第8a図のConsumers URL 108への応答によって、ドメイン通信サーバが、ドメイン内のその他全てのクライアントサイド通信サーバから、リクエストしているクライアントサイド通信サーバで使用可能なContentConsumersをストリーム形式において返させる。複数の内部サーバのサイトについて、ストリームは内部コンシューミンググループも含んでいる。このストリーム形式は、クライアントサイド通信サーバサイトにいおてContentConsumer Objectsに翻訳し直され、局所的に収集される。 ContentConsumersをリクエストするクライアントサイド通信サーバの１例は次のとおりである。 https://myDomainServer.com:81/Consumer?ID=http://validCSS.com:84 ●ClientInfoChannel Objectsのリストが、第8a図のChannels URL 128を介して収集される。ClientInfoChannel Objectsは、クライアントサイド通信サーバにおいて、新規グループを作成するためのテンプレートとして使用される。InfoChannel Objectが、クライアントサイド通信サーバサイトにいおてグループの作成を容易にするための、事前に構成されたビュー内にドメインのコンテンツの部分を構成する。第8a図のChannels URL 128への応答によって、ドメイン通信サーバが、リクエストしているクライアントサイド通信サーバで使用可能なInfochannelオブジェクトをストリーム形式返させる。このストリーム形式は、クライアントサイド通信サーバサイトにおいてClientInfoChannel Objectsに翻訳し直され、局所的に収集される。 Channelsをリクエストしているクライアントサイド通信サーバの１例は次のとおりである。 https://myDomainServer.com:81/Channels?ID=https://validCSS.com:84 ●Logo Objectsのリストが第8a図のFirmLogo URL 116を介して収集される。Lo go Objectsは、コンテンツをさらに「目立たせる」ために使用される。レジスタリングクライアントサイド通信サーバが、現在「カレント」Logo Object を持っていないあらゆるLogo Objectsをリクエストする。第8a図のRegister URL 102から受信したClientSource ObjectsのリストからLogo Objectの状態が決定される。第8a図のFirmLogo URL 116への応答によって、ドメイン通信サーバが、指定されたクライアントサイド通信サーバの関連するLogoObjectをファイル形式において返す。このオブジェクトはローカルファイルシステム上に記憶され、このソースに起因するコンテンツを見る際にはいつでもこのオブジェクトが供給される。 LogoObjectsをリクエストしているクライアントサイド通信サーバの１例は次のとおりである。 https://myDomainServer.com.81/FirmLogo?ID=https://validCSS.com:84&SRC= https//myCSS2.com.85 クライアントサイド通信サーバのレジストレーションは、（レジスタリングクライアントサイド通信サーバへの仮想パイプを有する）その他全てのクライアントサイド通信サーバに対して、ダイナミッククライアントレジストリ06内で、クライアントが関心を持つかもしれない変更が生じたことを通知するためにドメイン通信サーバをトリガする。これは、各々の対応するクライアントサイド通信サーバにおいて、全てのRegistry Change事象を生じさせる。この変更には、レジスタリングクライアントサイド通信サーバ内で見つかった追加コンシューマとプロデューサの両方の可用性が含まれる。この通知は、各クライアントサイド通信サーバにおいて/Refresh URLをリクエストすることによって、また、/Producers と/Consumersの両方が変更され、クライアントサイド通信サーバの都合でリフレッシュされるべきであると説明することによって行われる(詳細な説明については、以下に示す「レジストリの変更」を参照のこと)。好ましい実施例において、レジストレーションは常にクライアントサイド通信サーバによって開始される。しかし、やはり好ましい実施例において、ドメイン通信サーバは、任意のクライアントサイド通信サーバに、ドメイン通信サーバが適切であると判断すればいつでも再登録を行うように要求することができる。 2. クライアントサイド通信サーバ登録抹消クライアントサイド通信サーバの登録抹消は、クライアントサイド通信サーバがドメイン通信サーバに、ドメインにとってこれ以上使用可能でないことを通知する必要がある場合に行われる。この事象は、クライアントサイド通信サーバによって制御され、いつでも発生可能であり、しかし好ましい実施例においては、クライアントサイド通信サーバが通常のシャットダウンを試みた際に必ず起こる。クライアントサイド通信サーバは、第8a図のUnregister URL 104を介して登録抹消を希望することをドメイン通信サーバに通知する。このURLのフォーマットはDomainserver:/Unregister=ID:CSS"であり、ここで、Domain Serverはプロトコル、リクエストをする側のマシンネーム（およびポート）であり、ID Variabl eはクライアントサイド通信サーバのプロトコル、マシンネーム（およびポート）である。登録抹消を試みるCSSの１例は次のとおりである。 https://myDomainServer.com:81/Deregister?ID=https://validCSS.com:84 次に、ドメイン通信サーバは、IDによって指定されたロケーションがこのドメインにとって有効なロケーションであることを、DClient Objects（スタートアップでロードされている）のその内部収集を調べることにより確認する。リクエストの妥当性が検査されると、ドメイン通信サーバがHTTP状態コード200を返し、ドメインによって登録が抹消されたとみなされたとクライアントサイド通信サーバに知らせる。このクライアントサイド通信サーバに宛てられた全てのコンテンツが、クライアントサイド通信サーバがドメインに再び使用可能になるまで、待ち行列に入れられる。好ましい実施例において、クライアントサイド通信サーバの登録抹消もドメイン通信サーバによって開始される。これは、クライアントサイド通信サーバからの最後の交信から指定した時間（通常は５分間）が経過した際に、クライアントサイド通信サーバが、ドメイン通信サーバによってリクエストされた/Ping URLに応答しない場合に起こる。当業者には明確であるように、このインターバルには短い時間または長い時間を指定することができる。また同様に、好ましい実施例ではこのアプローチを使用し、この理由で登録抹消されたクライアントサイド通信サーバのためにメッセージを待ち行列に入れるが、無応答のクライアントサイド通信サーバのためにメッセージを保留させるのに別の技術の使用も可能であることが当業者には明らかであろう。好ましい実施例では、クライアントサイド通信サーバの登録抹消によって、レジスタリングクライアントサイド通信サーバへの仮想パイプを有するその他全てのクライアントサイド通信サーバに対して、ドメインレジストリ内でクライアントが関心を持つかもしれない変更が生じたことを通知するためにドメイン通信サーバがトリガされる。この変更には、クライアントサイド通信サーバの登録抹消における追加コンシューマおよびプロデューサの両方の無効性が含まれる。通知は各クライアントサイド通信サイトにおいて/Refresh URLをリクエストすることにより、また、/Producerstと/Consumersの両方が変更されており、クライアントサイド通信サーバの都合でリフレッシュされるべきであることを通知することで実行される。 3. コンテンツリプリケーションこの事象は、ドメイン内のあるクライアントサイド通信サーバから別のクライアントサイド通信サーバへコンテンツを送る必要がある際には常に発生する。好ましい実施例においてドメイン通信サーバは、異なる企業のクライアントサイド通信サーバ間のコンテンツリプリケーション（外部リプリケーション）のみに責任があることに言及すべきである。同じ企業のクライアントサイド通信サーバ間のコンテンツリプリケーション（内部リプリケーション）は、２つ（またはそれ以上）のクライアントサイド通信サーバ間で直接行われる。好ましい実施例では、ドメイン全体にかけてリプリケートできる３つのタイプのコンテンツ、すなわちベースコンテンツ、Adhocコンテンツ、混合コンテンツを設けている。（好ましい実施例ではさらに、System Contentとして知られる４番目のタイプのコンテンツを設けているが、このタイプはリプリケートされない。）コンテンツのタイプは、そのコンテンツがどのように構成されているかによって決定される。ベースコンテンツは、トピックまたはサブジェクト・マターによって構成されたコンテンツである。サブジェクト・マターは、１つ以上のドメインのIndexObjects内で定義されなければならない。コンテンツの起点（すなわち、作成された場所）は関係ない。ベースコンテンツは、１つ以上の関連するインデックスを備えることができる。これに対してAdhocコンテンツは、サブジェクト・マターではなく、その起点によって構成されているコンテンツである。起点は、ドメイン内の与えられたクライアントサイド通信サーバにおける１つ以上の「プロデューシング」グループでなくてはならない。混合コンテンツは、adhoc コンテンツとベースコンテンツの両方を組み合わせたものである。混合コンテンツは、起点と、これに関連するサブジェクト・マターを有する。好ましい実施例において、混合コンテンツは２つの個別のタイプ、アンカップラブルとデカップラブルであってよい。アンカップラブルな混合コンテンツは、ベースとadhoc部分に分けることはできずに全体として扱わなければならないのに対し、デカップラブルの方はサブコンポーネントに分けることができ、これらを個別に扱うことが可能である。コンテンツのタイプは、コンテンツ作成の時間においてクライアントサイド通信サーバを生成することによって決定する。コンテンツのリプリケーションのタイプは２つの適切なモード、ブロードキャストまたはセレクティブ・ディストリビューションであることができ、クライアントサイド通信サーバサイトにおけるプロデューシング・インディビジュアルに許可された、使用可能な宛先に基づいて、クライアントサイド通信サーバによって制御される。ブロードキャスティングコンテンツは、（ベース）コンテンツを、最初のクライアントサイド通信サーバが仮想パイプを確立したドメイン内のその他全てのクライアントサイド通信サーバへ分配する効果を備えている。セレクティブ・ディストリビューションは、ドメイン全体ではなく、（adhocおよび/または混合コンテンツ）のみを指定されたクライアントサイド通信サーバにリプリケートする。好ましい実施例において、指定されたリプリケーションのタイプが、リプリケーとされるコンテンツのタイプを言及する。つまり、ベースコンテンツのみがブロードキャストされることができ、Adhocコンテンツと混合コンテンツのみが選択的に分配されることができる。コンテンツの流れは、ドメイン全体にかけてコンテントを収集および分配するための、第8a図のDistributeObject URL 112と第8a図のCollect Object URL 114 によって制御される。クライアントサイド通信サーバのみがこのタイプについて理解していればよく(処理するために)、コンテンツはDistributedObject内にエンカプセルされているため、コンテントのタイプはリプリケーションプロセスとは関係ない。DistributedObjectは起点、ターゲット、データ、シグネチャの４つの部分から成っている。起点とターゲットは、誰がオブジェクトを受信できるかを決定するためにドメイン通信サーバによって使用され、シグネチャとデータ部分は、処理のためにオブジェクトを復元するために、クライアントサイド通信サーバによって使用される。好ましい実施例において、リプリケーションは、コンテントを外部に分配するように事前に決定されているクライアントサイド通信サーバによって開始される。好ましい実施例では、クライアントサイド通信サーバはDistributedObjectを局所的に記憶し、また、クライアントサイド通信サーバサイトでDistributedObj ectが伝搬されるべく待機しているとドメイン通信サーバに通知する。クライアントサイド通信サーバは、オブジェクトを収集する際にドメイン通信サーバが使用すべきDi stributedObjectに独特の識別子を指定する。クライアントサイド通信サーバは、第8a図のDistributeObject URL 112を介してこれを行う。 ObjectをDistributeするようにドメイン通信サーバに通知を試みるクライアントサイド通信サーバの１例は次のとおりである。 https://myDomainServer.com:81/DistributeObject?ID=https:ValidCSS.com:8 4& OID=3043.201e 第8a図のDistributeObject URL 112に応答して、ドメイン通信サーバは、その通知が届けられた旨の信号をクライアントサイド通信サーバに送りながら、HTTP 状態コード200を返す。通知の送信の後、ドメイン通信サーバは、事前に指定されている独特の一致を使って、オリジナルのクライアントサイド通信サーバから DistributeObjectをリクエストする。これは、第8a図のCollectobject URL 114 をリクエストすることで達成される。クライアントサイド通信サーバからDistributed Objectを収集するドメイン通信サーバの１例は次のとおりである。 https://validCSS.com:84/CollectObject?OID=3043.201e クライアントサイド通信サーバからの応答は、ストリーム形式のDistributeOb jectである。このストリームはドメイン通信サーバによって捕獲され、ドメイン通信サーバサイトでDistributeObject内に再度作成される。クライアント再度通信サーバは、ドメイン通信サーバが監査目的でDistributeObjectを検索した時間を局所的に表記する。DistributeObjectを検索した後、ドメイン通信サーバはソースと、指定された使用可能なターゲットのリストとを決定する。ドメイン通信サーバはそのターゲットを、起点のクライアントサイド通信サーバが仮想パイプを確立したその宛先と共にマップする。次にDistributeObjectは、第6a図に示すように、ドメイン通信サーバによってDCOBJECTSテーブル62内に記憶され、妥当性を検査された各宛先が、DCobjectdestinationsテーブル内に記憶される。次にドメイン通信サーバが、DistributeObjectが待機している旨を各クライアントサイド通信サーバ宛先に通知する。これは、第8b図のReceiveObject URL 212 、クライアントサイドサーバURLの使用を介して行われる。指定したDistributeO bjectのための独特の識別子がこのURLにおいて送信され、受信したクライアントサイド通信サーバによって、オブジェクトをリクエストする際に使用される。 Distribute Objectが使用可能である旨をクライアントサイド通信サーバに通知するドメイン通信サーバの１例は次のとおりである。 https://validCSS.com:84/ReceiveObject?LOH=1010982029384 このURLに応答して、クライアントサイド通信サーバはドメイン通信サーバに、通知が表記された旨の信号を送りながら、HTTP状態コード200を返す。通知を送信した後、クライアントサイド通信サーバは、指定された独特の一致を使って、ドメイン通信サーバからDistributeObjectをリクエストする。これは、第8a図のCollectObject URL 114をリクエストすることで達成される。ドメイン通信サーバからのDistributeObjectの検索を試みるクライアントサイド通信サーバの１例は次のとおりである。 http://myDomainServer.com:81/CollectObject?ID=https://validCSS.com:84&LO H=1010982029384 ドメイン通信サーバからの応答は、ストリーム形式におけるリクエストしたDi stributeObjectである。このストリームはクライアントサイド通信サーバによって捕獲され、クライアント通信サーバサイトでDistributeObject内に再度作成される。ドメイン通信サーバは、クライアントサイド通信サーバが監査目的でDist ributeObjectを検索した時間を局所的に表記する。DistributeObjectを受信した後、クライアントサイド通信サーバは、これ以上の処理が必要であるかを決定し、必要である場合には処理を行う。 4. ダイナミック・クライエント・レジストリの変更好適な実施例では、図５に示すように、ダイナミック・クライエント・レジストリ06は、指定時点の指定ドメイン内においてどのリソースをいくつ使用可能かを調べる場合に使用される。ダイナミック・クライエント・レジストリ06は、４つのオブジェクト、つまりコンテント・プロデューサ、コンテント・コンシューマ、インデックス・オブジェクト、及びチャネルから成っている。ダイナミック・クライエント・レジストリ06は全く動的であり、レジストリの変更は、ドメイン・コミュニケータ・サーバによって制御され、そして任意の時間に行える。このドメイン・コミュニケーション・サーバーは、全てのクライエント側コミュニケーション・サーバに対して変更について通知する必要がある。この通知は、図 8aのRefresh URL 118を介して行われる。好適な実施例では、ダイナミック・クライエント・レジストリ06の変更は、４つの異なるイベントの結果として発生する。最初のイベントは、新しいクライエント側コミュニケーション・サーバをドメイン内に登録することである。これによって、ドメイン・コミュニケーション・サーバは、この新しいクライエント側コミュニケーション・サーバに「関連する」クライエント側コミュニケーション・サーバのすべてに通知する。この通知は、登録したクライエント側コミュニケーション・サーバが含むContentProducers及びContentConsumersのリストから成っている。これらは、全ての既存クライエント側コミュニケーション・サーバで使用可能である。どのようなクライエント側コミュニケーション・サーバがどのようなプロデューサとコンシューマ(設定したバーチャル・パイプに基づく)を認識するかは、ドメイン・コミュニケーション・サーバで決める必要がある。好適な実施例では、クライエント側コミュニケーション・サーバは、選択的にドメイン・コミュニケーション・サーバが使用可能と通知するサブセットにのみ通知できる。ダイナミック・クライエント・レジストリ06を変更する２番目のイベントは、最初のイベントの反対である。つまり、クライエント側コミュニケーション・サーバの登録を解除する。いずれのイベントにおいてもドメイン・コミュニケーション・サーバは、ContentProducers及びContentConsumersオブジェクトの変更について、関連する全てのクライエント側コミュニケーション・サーバに通知する。ダイナミック・クライエント・レジストリ06の変更についてクライエント側コミュニケーション・サーバに通知するドメイン・コミュニケーション・サーバの例は、(特にContentProducers)は、以下のようになるはずである。 http://ValidCSS.com:84/Refresh?URL=/Producers ダイナミック・クライエント・レジストリ06の変更についてクライエント側コミュニケーション・サーバに通知するドメイン・コミュニケーション・サーバの例は、(特にContentConsumers)は、以下のようになるはずである。 http://ValidCSS.com:84/Refresh?URL=/Consumers ダイナミック・クライエント・レジストリ06を変更する３番目のタイプは、ドメインで使用するIndexObjects内での変更である。この変更は、ドメイン・コミュニケーション・サーバで処理するステータス・イベント(以下にリストされている)を介してのみ発生する。全ての有効なクライエント側コミュニケーション・サーバは、このタイプのダイナミック・クライエント・レジストリ06の変更について通知される。ダイナミック・クライエント・レジストリ06の変更についてクライエント側コミュニケーション・サーバに通知するドメイン・コミュニケーション・サーバの例は、 (特にIndexObjects)は、以下のようになるはずである。 http://validCSS.com:84/Refresh?URL=Indexes 最後の変更タイプは、ドメインで使用するChannels内での変更である。この変更は、ドメイン・コミュニケーション・サーバで処理するステータス・イベント (以下にリストされている)を介してのみ発生する。全ての有効なクライエント側コミュニケーション・サーバは、このタイプのダイナミック・クライエント・レジストリ06の変更について通知される。ダイナミック・クライエント・レジストリ06の変更についてクライエント側コミュニケーション・サーバに通知するドメイン・コミュニケーション・サーバの例は、 (特にChannels)は、以下のようになるはずである。 http://validCSS.com:84/Refresh?URL=Channel このURLに応じて、クライエント側コミュニケーション・サーバは、ドメイン・コミュニケーション・サーバに通知するHTTPステータス・コード200を返す。これは、クライエント側コミュニケーション・サーバが受信したコードである。この通知を送信した後、クライエント側コミュニケーション・サーバは、ドメイン・コミュニケーション・サーバが指定したURL(必要なパラメータと共に)を要求する。 5. ドメインのシャットダウンこのイベントは、ドメイン・コミュニケーション・サーバが全ての有効なクライエント側コミュニケーション・サーバにドメインが使用不可能である旨を通知しなければならないときに発生する。この通知は、図8aのDomainShutdown URL 1 30を介して処理される。ドメイン・シャットダウンについてクライエント側コミュニケーション・サーバに通知するドメイン・コミュニケーション・サーバの例は、以下のようになるはずである。 http://validCSS.com:84/DomainShutdown 好適な実施例では、通知をクライエント側コミュニケーション・サーバに送信して、ドメイン・コミュニケーション・サーバがクライエント側コミュニケーション・サーバに対して、ドメインが再度使用可能である旨を通知するまで、クライエント側コミュニケーション・サーバが外部的に複製しなければならない全てのコンテントの列を作れるようにする。クライエント側コミュニケーション・サーバは、最初のドメイン・コミュニケーション・サーバがコンテントの列を作るのを避けるためにドメインに戻るまで、代替のドメイン・コミュニケーション・サーバ(1つのドメイン・コミュニケーション・サーバがクライエント側コミュニケーション・サーバを開始する場合に指定されている場合)を使用できる。ドメイン・コミュニケーション・サーバがドメインに戻ると、クライエント側コミュニケーション・サーバは、コンテントの複製を開始することによって現在列を作っているコンテントについてドメイン・コミュニケーション・サーバに通知する(上記のイベント3)。ドメイン・コミュニケーション・サーバが戻った旨の通知は、各クライエント側コミュニケーション・サーバを再登録することを要求するドメイン・コミュニケーション・サーバによって行われる(イベント1)。 5. ステータス好適な実施例では、イベントは、ドメイン・コミュニケーション・サーバが現在中心的にホストとして機能させているダイナミック・クライエント・レジストリ 06の部分変更とドメインのカレント・ステータスについての問い合わせに応じて、ドメイン・コミュニケーション・サーバが処理する(つまり、Channels及びInd exオブジェクト)。これらのイベントは、いずれのクライエント側コミュニケーション・サーバも使用できないが、ドメイン・コミュニケーション・サーバのアドミニストレータだけが使用できる。ステータス・イベントは、ドメイン内の全てのクライエント側コミュニケーション・サーバのカレント・ステータスを表示する。クライエント側コミュニケーション・サーバのステータスには、他のクライエント側コミュニケーション・サーバに対して現在確立しているバーチャル・パイプ、クライエント側コミュニケーション・サーバのコンテント・プロデューサ (内部及び外部の両方)、及びクライエント側コミュニケーション・サーバのコンテント・コンシューマ(コンシューマが消費しているものも含む)を含む。ドメイン・コミュニケーション・サーバは、これらのイベントを介してドメインのインデックス又はチャネルを再度読み込むように通知される。上述のように、好適な実施例では、さらに本システムはDistributedObjectオブジェクトを使用する。DistributedObjectは、指定ドメイン内の１つのクライエント側コミュニケーション・サーバから他のクライエント側コミュニケーション・サーバにデータを複製する場合に使用される。DistributedObjectは、オリジン、ターゲット、シグネチャ、及び複製されるデータ(コンテント)の４つのコンポーネントから成っている。オリジン及びターゲットの両フィールドは、データのターゲットを設定する時に、データを作成するクライエント側コミュニケーション・サーバによって設定され、ドメイン・コミュニケーション・サーバによって評価される。シグネチャは、そのデータから元のタイプを再構築し、そしてデータの処理方法を理解するために、受信するクライエント側コミュニケーション・サーバが使用する。DistributedObjectは永続的である。オリジン及びターゲットはIdObject形式である。複数のオリジン及びターゲットを指定できる。好適な実施例では、IdObjectは、ドメイン内のコンテントのオリジン又はターゲットを設定する場合に使用される。IdObjectは、ファーム、ワークグループ、及びユーザ確認から成っており、ドメイン・コミュニケーション・サーバ及びクライエント側コミュニケーション・サーバの両方がコンテントのオリジン又はターゲットを設定する場合に使用する。このオブジェクトを使用すると、起りうる全ての合致を示すためにワイルド・カードの省略形を使用でき、指定したIdObje ctが他のIdObjectに「等しい」かどうかを調べることができる。有効なIdObjectは、以下の形式であり、ワイルド・カード例を以下に示す。 IdObject 同値^*** 全てのファーム内にある全グループの全ユーザ FIRM.^*.^* 特定ファームでの全グループの全ユーザ FIRM.GROUP 特定ファームでの特定グループの全ユーザ FIRM.GROUP.USER 特定ファームでの特定グループの特定ユーザ複数のドメイン・コミュニケーション・サーバを使用する場合、ドメイン・フィールドは、ファーム・フィールドの前に挿入できることは明らかである。本発明の好適な実施例では、必要であれば、ユーザによる使用、複製、アクセス、又は参照された情報のタイプについてのリーダーシップ分析及び類似統計の情報を保持できる。本発明の精神から逸脱することなく、使用、通信量、応答時間などを追跡する分析プログラムも実現できることは明らかである。本発明の好適な実施例では、本システムは、例えば、ユーザが１日の終わりに精査できる分布概要、及びユーザがその日又は他の時間帯の終わりに送った全ての情報を提供できる。さらに、好適な実施例では、本システムは検索機能を提供するので、ユーザは情報のタイプ又はソース、或はそれらの両方、及び作成阻タイム・フレーム内での出版などに基づく情報を検索できる。本発明の精神から逸脱することなく、多くの異なった検索機能を実現できることは明らかである。好適な実施例では、プロデューサ・オブジェクト(ファーム名、グループ名などを記録する)は、受信するコンシューマが１対１で通信できる各プロデューサのリストを作成する。同様に、他のアイテム間のコンシューマ・オブジェクトには、１対１で通信したい個人を示すリストがある。本発明の１対１通信機能は、必要であれば、「あなただけの目を見つめて」の１対１での高度な機密通信を行える。この１対１の関係を管理する各種の組合せが可能であり、さらに変化を求め得ることは明らかである。同様に、好適な実施例では、コメントには１つ以上にインデックス値の付いたタグを付けることができる。本発明の好適な実施例は、C++プログラミング言語で書いたプログラムをパーソナル・コンピュータ、或はNT又はUnixオペレーティング・システムで稼働できるが、他のプログラミング言語及びオペレーティング・システムも使用できることは明らかである。さらに、好適な実施例はソフトウェア・プログラムによって実現しているが、本発明のある部分又は全てのロジックをファームウェア又はハードウェア回路で実現できることも明らかである。上記の実施例が例証に過ぎないことを十分に認識し、そして本発明の範囲での教示から他のシステムも実現可能である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ０６Ｆ 15/00 ３３０Ｇ０６Ｆ 15/00 ３３０Ｄ (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者ラマチャンドラン、ラジャアメリカ合衆国 02134 マサチューセッツ州オールストンフランクリンストリート 65 (72)発明者バーンズ、トーマスエイ. アメリカ合衆国 02332 マサチューセッツ州ダックスベリサリーレーン８ (72)発明者マローン、トーマスジェイ. アメリカ合衆国 02127 マサチューセッツ州サウスボストンイーストセブンスストリート 545 (72)発明者クミーク、マイケルディ. アメリカ合衆国 02114 マサチューセッツ州ボストンウエストシーダーストリート 90 アパートメント１エム (72)発明者ドウティ、ジョセフシー. アメリカ合衆国 02131 マサチューセッツ州ウエストロックスベリグレッターストリート 34 【要約の続き】指示された関数名をロードすることにより第２コンピュータをリソース・ロケータに反応させるウェブ・サーバと、ダイナミックグループレジストリを組織化するためのデータベース管理プログラムとを有する。

Claims

【特許請求の範囲】１．選択的シェアリングのために異なるネットワーク上におけるクライアントエンティティから情報を組織するためのレジストリであって、ダイナミッククライアントレジストリを格納するため、及び機能名を含むリソースロケータを格納するための電子記憶媒体を備えた第１コンピュータと、その第１コンピュータは更に、第１コンピュータによって実行されたときに、リソースロケータ内に示される機能名を第１コンピュータにロードすることにより、その第１コンピュータをしてリソースロケータに応答させるウェブサーバープログラムを備え、その第１コンピュータは更に、ダイナミッククライアントレジストリを組織するためのデータベースマネージメントプログラムを備えることと、適切なリソースロケータに応答して前記ウェブサーバープログラムによってロードされたとき、前記第１コンピュータによって実行されるドメイン通信サーバープログラムと、そのドメイン通信サーバープログラムは同ドメイン通信サーバープログラムに向けられたリソースロケータに応答可能であり、前記ダイナミッククライアントレジストリの組織中に前記データベースマネジメントプログラムを管理することと、前記第１コンピュータと通信関係を有する複数の第２コンピュータと、各第２コンピュータはダイナミックグループレジストリを格納すると共に機能名を含むリソースロケータを格納する電子記憶媒体を備え、各第２コンピュータは同第２コンピュータによって実行されたとき、リソースロケータ内に示される機能名を第２コンピュータにロードすることにより、その第２コンピュータをしてリソースロケータに応答させるウェブサーバープログラムを備え、各第２コンピュータは更に、ダイナミックグループレジストリを組織するためのデータベースマネージメントプログラムを備えることと、各第２コンピュータに格納されたクライアント側通信サーバープログラムと、そのクライアント側通信サーバープログラムは、適切なリソースロケータに応答してウェブサーバープログラムによってロードされたとき、各第２コンピュータによって実行され、更に、クライアント側通信サーバープログラムに向けられたリソースロケータに応答可能であり、かつ、ダイナミックグループレジストリの組織中に前記データベースマネージメントプログラムを管理することと、前記第１及び各第２コンピュータ内に格納されたドメイン通信リソースロケータリストと、そのドメイン通信リソースロケータリストは第１コンピュータ内のドメイン通信サーバー中において実行するために所定の機能が選択されるようにすることと、前記第１及び各第２コンピュータ内に格納されたクライアント側通信リソースロケータリストと、そのクライアント側通信リソースロケータリストは各第２コンピュータ内のクライアント側通信サーバー中において実行するために所定の機能が選択されるようにし、よって、各第２コンピュータによる選択的アクセスについてダイナミッククライアントレジストリ中に情報を格納し、かつその情報に索引をつけるために、前記第１コンピュータと各第２コンピュータとの間の通信により、選択された所定の機能のダイナミックな実行が引き起こされることとを備えたレジストリ。２.選択された所定の機能は更に、複数のバーチャルパイプを生成する機能を含み、同バーチャルパイプは、ユーザが一つのクライアントエンティティにおいて異なるネットワーク上の第２のクライアントエンティティにおけるユーザと、両方のクライアントエンティティがあたかも同一のネットワーク上にあるかのように通信することを許容する請求項１の装置。３．選択された所定の機能は更に、クライアントエンティティがそれ自身を前記ドメイン通信サーバープログラムに登録することを可能にする機能を含む請求項１の装置。４．選択された所定の機能は更に、クライアントエンティティがドメイン通信サーバープログラムからの内容情報を復旧することを可能にする機能を含む請求項１の装置。５．選択的シェアリングのために異なるネットワーク上におけるクライアントエンティティから情報を組織するためのコンピュータにより実施されるレジストリ方法であって、電子的記憶装置を備えた第１コンピュータ上にダイナミッククライアントレジストリを格納し、かつ、機能名を含んだリソースロケータを格納する工程と、前記第１コンピュータは更に、その第１コンピュータによって実行されたときに、リソースロケータ内に示される機能名を第１コンピュータにロードすることにより、その第１コンピュータをしてリソースロケータに応答させるウェブサーバープログラムを備え、その第１コンピュータは更に、ダイナミッククライアントレジストリを組織するためのデータベースマネージメントプログラムを備えることと、適切なリソースロケータに応答して前記ウェブサーバープログラムにより前記第１コンピュータにドメイン通信サーバープログラムをロードし、前記ドメイン通信サーバープログラムに向けられたリソースロケータに応答するため、及び、前記ダイナミッククライアントレジストリの組織中に前記データベースマネージメントプログラムを管理するための工程と、前記第１コンピュータと複数の第２コンピュータとによって通信関係を確立する工程と、各々の前記第２コンピュータはダイナミックグループレジストリを格納すると共に機能名を含むリソースロケータを格納する電子記憶媒体を備え、各第２コンピュータは、同第２コンピュータによって実行されるとき、リソースロケータ内に示される機能名を第２コンピュータにロードすることにより、その第２コンピュータをしてリソースロケータに応答させるウェブサーバープログラムを備え、各第２コンピュータは更に、ダイナミックグループレジストリを組織するためのデータベースマネージメントプログラムを備えることと、各第２コンピュータに格納されたクライアント側通信サーバープログラムを実行する工程と、その工程は同クライアント側通信サーバープログラムに向けられたリソースロケータに応答するため、及び前記ダイナミックグループレジストリの組織中に前記データベースマネージメントプログラムを管理するために実行されることと、前記第１コンピュータ内のドメイン通信サーバー中において実行するために所定の機能が選択されるように、前記第１及び各第２コンピュータ内にドメインリソースロケータリストを格納する工程と、前記第１及び各第２コンピュータ内にクライアント側通信リソースロケータリストを格納する工程と、そのクライアント側通信リソースロケータリストは各第２コンピュータ内のクライアント側通信サーバー中において実行するために所定の機能が選択されるようにし、よって、各第２コンピュータによる選択的アクセスについてダイナミッククライアントレジストリ中に情報を格納し、かつその情報に索引をつけるために、前記第１コンピュータと各第２コンピュータとの間の通信により、選択された所定の機能のダイナミックな実行が引き起こされることとからなる方法。６．所定の機能を選択する工程は更に、複数のバーチャルパイプを生成する機能を選択する工程を含み、同バーチャルパイプは、ユーザが一つのクライアントエンティティにおいて異なるネットワーク上の第２のクライアントエンティティにおけるユーザと、両方のクライアントエンティティがあたかも同一のネットワーク上に存在するかのように通信することを許容する請求項５の方法。７．所定の機能を選択する工程は更に、クライアントエンティティがそれ自身を前記ドメイン通信サーバープログラムに登録することを可能にする機能を選択する工程を含む請求項６の方法。８．所定の機能を選択する工程は更に、クライアントエンティティがドメイン通信サーバープログラムからの内容情報を復旧することを可能にする機能を選択する工程を含む請求項６の方法。