JP2002515156A

JP2002515156A - Dynamic client registry device and method

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: WO1998043184A1; EP1019850A1; US6026430A; AU6770198A

Abstract

(57)【要約】異なるネットワーク上のクライアント・エンティティからの情報を組織化して選択的に共有するためのレジストリが、ダイナミッククライアント・レジストリ（０７）と、関数名を含むリソース・ロケータとを格納するためのディスク（０８）を有する第１コンピュータと；指示された関数名をロードすることにより第１コンピュータをリソース・ロケータに反応させるウェブ・サーバと；ダイナミッククライアント・レジストリを組織化するためのデータベース管理プログラムとを有する。このシステムは、また、ドメイン・通信サーバを含む。ドメイン・通信サーバは、ウェブ・サーバにより用いられて、ウェブ・サーバに向けられたリソース・ロケータに反応し、かつ、ダイナミッククライアント・レジストリの組織化においてデータベース管理プログラムを管理する。このシステムは、また、第１のコンピュータとネットワークで結ばれた幾つかの第２コンピュータを有する。第２コンピュータの各々が、ダイナミックグループレジストリと、関数名を含むリソース・ロケータとを記憶するためのディスクを有する。第２コンピュータは、また、指示された関数名をロードすることにより第２コンピュータをリソース・ロケータに反応させるウェブ・サーバと、ダイナミックグループレジストリを組織化するためのデータベース管理プログラムとを有する。 (57) [Summary] A registry for organizing and selectively sharing information from client entities on different networks stores a dynamic client registry (07) and a resource locator including a function name. Computer having a disk (08) for loading; a web server for causing the first computer to respond to the resource locator by loading the indicated function name; and database management for organizing a dynamic client registry With a program. The system also includes a domain and communication server. The domain communication server is used by the web server to respond to resource locators directed to the web server and manage the database manager in organizing the dynamic client registry. The system also has a number of second computers networked with the first computer. Each of the second computers has a disk for storing a dynamic group registry and a resource locator containing function names. The second computer also has a web server that causes the second computer to respond to the resource locator by loading the indicated function name, and a database management program for organizing a dynamic group registry.

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オペレーティング・システムで稼働できるが、他のプログラミング言語及びオペレーティング・システムも使用できることは明らかである。さらに、好適な実施例はソフトウェア・プログラムによって実現しているが、本発明のある部分又は全てのロジックをファームウェア又はハードウェア回路で実現できることも明らかである。上記の実施例が例証に過ぎないことを十分に認識し、そして本発明の範囲での教示から他のシステムも実現可能である。DETAILED DESCRIPTION OF THE INVENTION Dynamic Client Registry Apparatus and Method Technical field The present invention relates generally to the field of networking computer systems, and more particularly, to the field of systems for providing control over the distribution, redistribution, access security, filtering, organization and display of information across different networks. Background art Today, in most industries and occupations, the need for inter-company and intra-company communication is growing rapidly. Most companies, businesses and institutions want their employees to be able to communicate internally with other employees and on the outside with business customers, sellers, information sources, etc. throughout the working day. Depending on the nature of the information and the relationships between the parties, these communications may need to take the form of one-to-one communiqués in some cases and one-to-many broadcasts in other cases. It needs to take the form, many-to-many communication, and even many-to-one communication. Some of these categories may provide good information for all stakeholders if the data flow is interactive and cooperative, and recipients may comment on those already received. , Share, and create. At present, it is difficult and expensive to easily achieve and manage such a large volume of communications, especially where extremely sensitive, confidential and proprietary information is only available internally. Even more so when they have to be selectively communicated externally to the business partners considered by these companies. The financial industry, for example, the investing bank, communicates time-sensitive information to all clients of its investment management company and gives them comments about it, during which time its competitors access the information You may want to make sure you stop. Investors can also share news from sellers of financial news services, as well as analytics and exclusive reports from other third-party sellers who select it, on the same network that provides the distribution of their proprietary information. You may want to get it. Ten or twelve years ago, tools for dealing with such communications would have been generally limited to telephone, facsimile, overnight mail, and more recently e-mail. Each of these media has limitations and drawbacks. Overnight mail is expensive and very slow for some information. Telephones are, of course, very fast, but many telephone conversations are limited to one-to-one communications because telephones are a synchronous form of communication that requires partners to communicate simultaneously. is there. This is not always efficient. For sponsors to send market analysis reports to clients on a one-to-one basis, the process is slow and cumbersome, with some clients getting information long before others get information. That is inevitable. Certain conference calls ensure that several clients obtain the same information at about the same time, and certain conference calls are interactive, so comments from various clients can be expressed. Can be done. However, if the number of people in a conference call begins to exceed a certain critical amount, the call can be confused without salvation. Voices of other clients may be mistaken for voices of analysts of the sponsoring company, for example. In either type of telephony communication, the recipient must take notes to learn more or go out to the analyst after the day. Voice telephony conversations are less appropriate when the information is not only timely but also needs to be recorded precisely and accurately for later reference. Modern facsimile machines allow selected groups of clients to broadcast information across telephone lines and to send charts, graphs, and other images. This also gives the client an accurate record for later reference. However, facsimile transmissions are not interactive, thus losing any client comments that may have been provided. Recipients of facsimile transmissions typically have only a hard copy and do not have an electronic copy of the information if they do not use a receiving fax modem. Thus, the availability to recipients can be significantly reduced, especially if such transmissions take several orders to arrive at a common fax machine or mail room and reach the individual. Emails sent through gateways between internal collaborative networks are often slow, emails sent in plain text format (which may have visual information usually sent as attachments) and fixed data are usually indexed It has not been. As a result, finding the information desired or needed in a stream of email messages can take a long time. Recipients cannot use or view the attachments unless they use the same computer software and hardware. In many companies and facilities, emailing in or out attachments as messages will not be tolerated for confidential reasons. E-mail technology is essentially a storage and shipping process that necessarily produces many copies of the same document on the same network, an inefficient use of network resources. With these problems encountered, companies and facilities with computers and telecommunications networks distributed internally to the private sector take another approach to handling intra-company communications. By building an independent, isolated external network to communicate with key business partners, information about selected customers and vendors from the company's own internal network is obtained. Information selected from the company's internal network is sent to a special external network, which in turn is sent to trading partners. This allows many documents and files to be transferred to and from external sources in secret form. However, if there is a facility such as an investment bank that wants to do so for all customers and all vendors, the cost and complexity will increase dramatically. If an investment bank uses one type of computer system and network software for its internal and external networks, and the customer or vendor uses another type, then for each individual on both sides of the communication, those systems will It is necessary to have a network management device that works together and deploys programs to provide security. This means computers, bridges (network devices that connect two networks using two different types of media, such as a 10Base T cable and FDDI connections), routers (connect two or more networks, and send messages). Special purpose equipment that routes to the correct internal protocol address), software and terminals, as well as asset costs to the cost of deploying software to handle connections to and from the outside will usually be included. To avoid extreme costs for equipment and special deployments, companies limit the number of companies authorized for this type of access as well as this type of information that can be sent and received. Other companies, such as First Call, have provided network and distribution services to provide another means by which connections can be controlled. For example, if an investment bank wants to communicate to a client about its research, First Call will deliver the content for a fee and charge its payee. This measure, while eliminating the need for significant capital and development costs on both the seller and buyer sides of the information so distributed, also effectively controls their control over the information and its flow. To eliminate. For example, from the customer's perspective, the central source of information is First Call, not a bank or supplier. Since the information distributed by First Call is sent to everyone who bought the service, it was not practical for the provider to provide certain information for a particular recipient. Under this method, two-way communication was not practical either. And the Internet-a worldwide system of linked computer networks that allows thousands of existing corporate and organizational networks to communicate using standard communication protocols or signals. did. This aspect of the Internet, known as the World Wide Web, is a hypertext link on the World Wide Web that allows users to move from one hypertext link to another. These communications are further simplified by providing what is known as a link and using the HyperText Transport Protocol (HTTP). (Hypertext is information that is referred to as a node and embedded in the node. A method for creating and publishing text that is broken into small units with hypertext links or what are called hypertext anchors.When a text reader clicks on a hyperlink, the hypertext software (browser) Or also known as a web browser) To display the node associated with the link. Is what a collection of these nodes "web", Worldwide Web is a large-scale hypertext system). The Internet and the Worldwide Web have facilitated the widespread dissemination of certain information. However, the vast majority of the information published on the Internet's World Wide Web appears to be neither sensitive nor confidential in nature because of the ease of access to that information. Seems to be. The company's internal network not only has highly confidential business files on the same computer that forms the internal network, but is also vulnerable to attack, theft, or abuse if a connection is made between the inside and the Internet It also has files on top secret technologies and products. Thus, most companies build a "firewall" between the internal network and any gateway to the outside world (see FIG. 2, where companies C1 through C9 have firewalls F1 through F9, respectively). Is shown). Firewall is a protection technique in which a user places a specially programmed computer system between his internal network and the Internet. This special "firewall" computer prevents unauthorized persons from accessing the internal network. However, the firewall can also prevent users of the company's internal computers from accessing the Internet directly. This is because access to the Internet provided by a firewall computer is usually indirect and is performed by a software program called a proxy server. Therefore, when a user wants to obtain a file from a vendor, the user sends an FTP (File Transfer Protocol) request to the proxy server of the firewall computer. The proxy server makes a second FTP request under its own name and actually uses it to request a file outside the network. This allows internal names and addresses to remain within the company. The use of firewalls and proxy servers can be somewhat slower and may limit the type of information that can be sent or received for less confidential or less proprietary information. The use of firewalls reduces the risk of internal network users bringing information from the Internet and distributing the information internally. However, once the information is brought into a company's private network, the problem of distributing the information internally still arises. The largest private networks are a combination of the following:-a local area network (LAN)-a set of networks located within a fairly small physical area, usually within two miles, and linked together by high-speed cables or other connection means. A computer and a wide area network (WAN)-a group of local area networks linked together via high-speed long-distance communication lines or satellites that transmit data quickly over long distances and form the "backbone" of the internal network. It is constructed by combination. The private internal network uses complex hardware and software to internally transmit, transfer, and receive messages. As a first step in building an "intranet", the information distributed and distributed within the corporate network uses client / server technology, web browsers, and hypertext technology used on the Internet on an internal basis, It will be easily created. In a typical client / server technology, one computer acts as a "back end" or server to perform complex tasks for the user, while a small computer or terminal communicates with the user on the "front end". End ”or“ client ”. In the client / server method, a client requests data from a server. A web server is a program that operates as a server function for hypertext information. In a large private network, a server computer may have web server software running on the computer to handle hypertext communications in a corporate network. At a web server site, one or more people can create a document in hypertext format and make the document available at the server. In many businesses, employees will have personal computers at their desks connected to the internal network. In an "intranet", such employees would use a web browser on their personal computers to view hypertext documents available on the web server. The above is a development in internal communication over private networks, but at the same time each person forms a hypertext markup language (HTML), a hypertext link in the document that creates and maintains the "internal" web page. You need to be familiar with the language used. If a more interactive approach is desired, information technology in the scripting arena, such as CGI, PERL, which can create formats, documents and procedures to enable users to request information from the server ( IT) Specialists are needed. Applications that need to distribute information internally are also available from IBM's Lotus Notes software. ^TM Any known working group software can be used on the internal network. However, this also requires special programming and scripting techniques in response to organization-specific requirements. It is becoming increasingly common to connect an intranet to the Internet to form a so-called “extranet”. However, the Internet is basically a passive communication system. There is no automatic notification to the customer that a new report is available on a particular Internet web page outside the customer's intranet. Typically, customers must regularly search the Internet to see if a web page has changed or if the change is what they want to see. Some web page sites that offer fee services use e-mail to notify prospective users that new data is available. As mentioned above, the e-mail is slow, so if the data is also time sensitive, this notification may not reach the customer until late in the day, at which point the value may already be low. One attempt to make the Internet more interactive has been proposed by Intermind. This is a form of hypertext and is called hypercommunication. This approach creates a number of directories at different sites, similar to a "speed dial button" on a typical telephone. If a user wants to get information from a site connected by hypercommunication, by "pressing" the "speed dial" button of that site, the site is automatically connected through a directory created by Intermind software. This approach also allows the publisher of the information to take a questionnaire as to whether the recipient is available. If the recipient is receivable and the publisher has new data to give to the recipient, the publisher "dial" the "sound button" and send the data. This will help solve the problem of notifying the customer that there is new information. However, even with such a directory, making the information created internally via the Internet selectively available to external business partners was done manually individually by the authors of the internal information. In that case, it becomes inefficient. Commingling internal information with an external information source on the same intranet or manually using a “speed button” is time-consuming and inefficient. This approach does not allow for control of data issuance, data heading, or any of the organized presentations. Also, this approach does not solve the security problem of having access to the website by others without "firewalls" or similar access defenses. Another means that has become available to publishers of information with the advent of the Internet and web browsers is a topology that provides highly secure access over the Internet. This connection typically uses encryption and security sockets to connect to more limited information through a demilitarized zone or DMZ. Because individual companies want to protect the privacy of internal data on their networks, they may have firewalls around their networks with a "demilitarized zone" (DMZ) on the outside, or other companies with whom they want to connect. Have as part of the firewall for each. As shown in FIG. 2b, D1 which is, by way of example, the DMZ of company A can be placed outside firewall F1 between firewall F1 and gateway G1 to company A's Internet. is there. In the DMZ D1, an area IC separately provided for mutual communication with the company C is shown. As seen in FIG. 2b, the DMZ of each company that desires direct and highly confidential communication with other companies must be configured so that the intended communication target is identified. If a customer needs to obtain information from 20 different external publishers, it will need to make 20 different connections between the customer's firewall and the publisher's firewall to obtain 20 identifiers and passwords There may be cases. This is shown in simplified form in FIG. For ease of illustration, the companies C1 to C3 are investment banks competing with each other, the companies C5 to C9 are their customers, C4 is a news source, and the network arrangement using the above DMZ arrangement is greatly simplified. It is. Note that bank C1 has news source C4 and DMZs D4-D9 for five customers C5-C9. Customer C5 has a DMZ D1-D3 for each of the investment banks from which customer C5 obtains data, as well as for news source C4. As FIG. 2 shows, this approach makes the connections D and DMZ D a maze. A simplified version of the DMZ is shown in FIG. 2b, where company C1 has an application that communicates with company C3 in its DMZ D1. Company C2 has applications C1 and C3 for communicating with companies C1 and C3 in its DMZ D2, respectively. With the DMZ approach, each customer needs to obtain a different user identifier and password to gain access to each other's corporate network. For each individual at each customer site, someone from the information technology department of the investment bank must provide a user identifier and password. This requires additional network management and maintenance efforts. Such a situation setting in which the customer uses a web browser to gather information from the provider's network is called a "pull" model, because the customer still has to actively search for information. In order to simplify this management task as much as possible, it makes sense to generalize the information transmitted by the source of the information so that the information is transmitted in a one-to-many or broadcast format. In this type of approach, one publisher organizes the information in one format and another publisher organizes the data in a completely different format. It is therefore extremely difficult for customers to find and organize data from 20 different sources. For more active sources of information, a "push" model of communication is desirable. It is desirable that the provider be able to notify the user that the data is there and send it out automatically, rather than waiting for the customer to search for information on the network That's what it means. Workgroup software such as Lotus Notes was generally considered to be a more effective solution to this type of business-to-business communication. Unfortunately, this usually requires a significant amount of software development and management overhead. In the example of a customer obtaining reports and data from 20 different investment banks, the information to be integrated at the employee's desk on the customer site typically arrives in a variety of mutually incompatible formats. If a customer wants to get morning analysis from each bank, the information specialist at the customer site will probably need to find out what format is used by each bank, and the network addressing schemes, protocols used for each bank , Packets, boats, and sockets must be understood by the customer's programmer, and one or more of the Lotus Notes Workgroup application programs on the customer's desk must be created or modified to convert the data into an internal format and capture it. There must be. One attempt to address at least some of these problems is a technique known as "Subject-Based Addressing Techniques" described in U.S. Pat. No. 5,577,798 assigned to Tibco. Using this approach and the example of a direct network-to-network connection via the DMZ shown in FIG. 2a, the publisher C1 provides a server for publishing information by subject on his site. Set up. Customer C5 typically has a “client” application on its DMZD5. A client application refers to a series of messages received using a human-readable subject name. Subject-based addressing eliminates the need for customer programmers to understand all network addresses, protocols, packets, ports, and socket details, and further changes that must be made to workgroup software Some of them will be easier. However, with subject-based addressing, there is a need to build a translation or translation layer software at the site to obtain a network feed and understand how the transferred data is formatted. This does not mean that the need to change workgroup software, such as the Lotus Notes application, is not eliminated. Indeed, both subject-based addressing and workgroup software such as Lotus Notes typically require a large amount of additional programming development work by the user to function effectively. . From the information publisher's point of view, the “push” model, which relies on network-to-network private connections through multiple firewalls, DMZs and workgroup programs, and uses subject-based addressing, No measures have been taken to address delivery management issues that are essential for If the investment bank C1 in FIG. 2a delivered the morning analytics as a subject, after the data leaves the bank's network and is distributed over the Internet, the investment bank will normally manage the replication of the analytics information Cannot be done at all. In most cases of subject-based addressing, the publisher cannot even know which company is consuming his or her information. For example, a set of programs may be created at a customer site, such as customer C8 (FIG. 2a), for publication management and distribution performed using either software, such as Lotus Notes, or subject-based addressing. Even so, adapting the program to work with the customer C9 network or between several different customer networks is not always a simple or straightforward task. If it is desired or necessary to send and receive information over the Internet or a wide area network linking several different companies, the distribution management problem becomes a very complex problem. As mentioned above, it is difficult to index and organize information received from many different sources, so that each recipient's desktop is similarly categorized. Some profiling or "filtering" systems (e.g., from Individual or Pointcast) collect data from public sources and provide information tailored to the needs of individual users. Filtering or sifting the data to select the, but these systems usually do not manage replication and do not allow any interaction with the data. A profiling system is typically a one-to-many, one-way distribution model that does not allow interaction. In businesses and large institutions with intranets where browsers are used, individual information recipients can organize what they see through bookmark management. However, bookmarks are usually very specially formed, and no two sets of bookmarks can be identical. Also, as with external profiling systems, intranets using browsers and bookmarks typically can only send information in one direction. The company C8 of FIG. 2 that has obtained the analysis information delivered by the bank C1 typically uses CGI scripting or other programming or scripting language for the purpose of enabling comments and replies on the relevant web pages by the bank C1. Therefore, unless a special form sheet has been created, the browser cannot be used to comment and respond. Again, custom programming or scripting adds cost and typically makes standardization between companies difficult. In most intranet systems currently connected to the Internet, individual users cannot request information based on both source and subject. Further, in most intranet systems, individual users cannot function as both information creators and viewers. As shown in FIG. 2a, connecting multiple information consumers on the Internet to external information sources via multiple DMZs and secure sockets is a complex and cumbersome task, and is a setup for information publishers. In addition, costs are required to perform the management. From the perspective of the information consumer on the Internet, it must be noted that transmissions on such a distribution model are performed at "Internet speed". That is, if, for example, a request for information is made from customer C8 and then sent over the Internet, it is in a packet formatted in TCP-IP format and may be encoded by secure socket technology. There is. In either case, after the information request is sent out of the customer C8 backbone network, the transmission rate is the average rate on the Internet transmission link. This rate is typically much lower than the transmission rate within the customer's own internal network. Therefore, from the customer's point of view, the speed at which business-to-business communication can be performed can also be a problem. While using a device such as a DMZ or a proxy server improves security issues, the DMZ also creates content backlogs that are an obstacle to all business-to-business communications. Tends to form. For example, if only people who are authorized to transfer data to the company's DMZ outside the company's firewall are information technology professionals, selectively transmit large amounts of information to the outside world. For businesses that need or want it, this can be a significant labor and / or obstacle to labor. Similarly, current security technologies offer a variety of encoding options (thus causing standardization issues between companies), but issues such as personal identification are not It is left to the management of the technology (IT) department. IT professionals must provide user identifiers and passwords to all external individuals who are authorized to access information (authentication) in the corporate DMZ. Currently this is usually done by manual letters of reference or manual data entry in each company and individual. As mentioned above, if documents must be created using HTML, or special CGI (common gateway interface) scripts need to be created and maintained to fit the data into the appropriate format In some cases, all of these circumstances create a tendency for policy and content management issues to be placed in the hands of IT professionals, rather than the creators and viewers of the information. IT professionals in the enterprise are overwhelmed by requests to add new users and individuals, register data types that can be transferred, implement and maintain changes and updates to scripts, programs, networks and systems as a whole. It is an object of the present invention to provide a universal domain routing and publication control system that enables the selective transfer of valuable information in such a way that management of the duplication and publication of information is allowed. Another object of the present invention is to provide a system capable of selectively distributing information between different types of users or networks. Still another object of the present invention is to provide a system that allows a user to comment on received information and to interact with the information. Yet another object of the present invention is to minimize or eliminate the need for software development by users and information providers. It is yet another object of the present invention to reduce the need to administer the system with special administrative procedures and specially trained personnel. It is yet another object of the present invention to provide a system that allows a user to access information, most often at the speed of the user's internal network. It is yet another object of the present invention to provide dynamic distributed network resource registries that facilitate standardization and organization of information by subject or source, or a combination thereof. Disclosure of the invention These and other objects are achieved by a registry for organizing information from client entities on different networks for selective sharing, the registry for storing a dynamic client registry and a resource locator including function names. A first computer with a disk and a web server that causes the first computer to respond to the resource locator by loading the indicated function name into the first computer. The database management program organizes a dynamic client registry. The domain communication server responds to the resource locator directed to it by the web server and manages the database management program in the organization of the dynamic client registry. Some second computers are networked with the first computer, and each second computer has a disk that stores a resource locator containing a dynamic group registry and function names. Each second computer comprises a web server, which causes the second computer to respond to the resource locator by loading the indicated function name. Each second computer has a database management program for organizing a dynamic group registry. The client-side communication server in each second computer, when loaded by the web server program, responds to a resource locator directed to the client-side communication server and manages a database management program in the organization of the dynamic group registry. . The domain communication resource locator list stored in all computers allows certain functions to be selected for execution in the domain communication server. The client-side communication resource locator list stored in all the computers allows a predetermined function to be selected for execution in each client-side communication server, thus providing a communication between the first computer and each second computer. Performs the selected function to selectively send information to the second computer. One aspect of the present invention is to allow one company to reliably communicate with another company outside its private network without requiring the use of a DMZ anywhere. is there. One aspect of the present invention is to provide a dynamically configurable relative configuration domain routing and publication control system. Another aspect of the present invention is that it allows users to restrict and enforce their own policies for distributing and redistributing information over a network. Yet another aspect of the present invention is to eliminate the need for further software development by the user. Yet another aspect of the present invention is that it does not require additional skilled information technology personnel to manage the system, but instead allows users to manage it themselves. Another aspect of the present invention is to allow users in a private network to receive information from outside the network at the speed of the private network most of the time. Another aspect of the present invention is to provide information promulgators with a simple way to create selective distribution to various clients. BRIEF DESCRIPTION OF THE FIGURES FIG. 1 is a schematic diagram of the present invention, showing a domain / communication server and several client-side / communication servers. FIG. 1a is another schematic diagram of the present invention, showing a virtual connection between a domain communication server and several client-side communication servers. FIG. 2a is a schematic diagram of a private network communicating with the outside on the Internet using the prior art. FIG. 2b is a schematic diagram of a private network communicating with the outside on the Internet using the prior art. FIG. 3 is a schematic diagram of the present invention, showing several domains communicating with each other. FIG. 4 is a schematic diagram of a client-side communication server according to the method and apparatus of the present invention. FIG. 5 is a schematic diagram illustrating the interconnection of a domain communication server and several client-side communication servers according to the method and apparatus of the present invention. FIG. 6a is a block diagram of an exemplary dynamic client registry in a domain communication server according to the method and apparatus of the present invention. FIG. 6b is a detailed block diagram showing the fields of the dynamic client registry in the domain communication server of the present invention. FIG. 7a is a block diagram of an exemplary dynamic group registry in a client-side communication server according to the method and apparatus of the present invention. FIG. 7b is a detailed block diagram showing the fields of the dynamic group registry in the client-side communication server of the present invention. FIG. 8a is a list of global resource locators (URLs) of major domain and communication servers used in the preferred embodiment of the present invention. FIG. 8b is a list of URLs of major client-side communication servers used in the preferred embodiment of the present invention. FIG. 9 is a detailed layout diagram of an exemplary domain client list according to the method and apparatus of the present invention. FIG. 10 is a detailed layout diagram of an exemplary client source list of the present invention. FIG. 11 is a detailed layout diagram of an exemplary client object list of the present invention. FIG. 12 is a detailed layout diagram of an exemplary object destination list of the present invention. FIG. 13 is a detailed layout diagram of an exemplary index according to the method and apparatus of the present invention. FIG. 14 is a flowchart of a startup procedure in the client-side communication server according to the method and apparatus of the present invention. FIG. 15 is a flowchart of initialization of a shared object by a client-side communication server according to the method and apparatus of the present invention. FIG. 16 is a more detailed flowchart of the initialization of a shared object by a client-side communication server according to the method and apparatus of the present invention. FIG. 17 is a flowchart illustrating initialization of a shared object by an administrator server of a client-side communication server according to the method and apparatus of the present invention. FIG. 18 is a flowchart illustrating initialization of a shared object by the tool server of the client-side communication server according to the method and apparatus of the present invention. FIG. 19 is a flowchart illustrating initialization of a shared object by an agent server of a client-side communication server according to the method and apparatus of the present invention. FIG. 20a is a flowchart illustrating initialization of a dynamic client registry by a domain communication server according to the method and apparatus of the present invention. FIG. 20b is a flowchart illustrating the creation of a group by a client-side communication server according to the method and apparatus of the present invention. FIG. 21 is a flowchart illustrating initialization of a client-side communication server according to the method and apparatus of the present invention. FIG. 22 is a block diagram of an exemplary user screen display of a desktop terminal for adding users according to the method and apparatus of the present invention. FIG. 23 is a block diagram of an exemplary user screen display for entering new user accounting information in accordance with the methods and apparatus of the present invention. FIG. 24 is a block diagram of an exemplary user screen display for authorizing content creation for a new user in accordance with the methods and apparatus of the present invention. FIG. 25a is a block diagram of an exemplary user screen display for selecting a content type according to the method and apparatus of the present invention. FIG. 25b is a block diagram of an exemplary user screen display for selecting a content type according to the method and apparatus of the present invention. FIG. 25c is a block diagram of an exemplary user screen display for a user to select a distribution option according to the method and apparatus of the present invention. FIG. 26a is a block diagram of an exemplary user screen display for granting redistribution rights, generally in accordance with the methods and apparatus of the present invention. FIG. 26b is a block diagram of an exemplary user screen display for granting redistribution rights, particularly in accordance with the methods and apparatus of the present invention. FIG. 26c is a block diagram of an exemplary user screen display for assigning group access according to the method and apparatus of the present invention. FIG. 26d is a block diagram of an exemplary user screen display for assigning a user internal group access in accordance with the methods and apparatus of the present invention. FIG. 26e is a block diagram of an exemplary user screen display for assigning external group access to a user according to the method and apparatus of the present invention. FIG. 27 is pseudo-code in SQL format showing the creation of a domain client table. FIG. 28 is a pseudo code in an SQL format showing creation of a client source table. FIG. 29 is pseudo-code in SQL format showing the creation of a client object table. FIG. 30 is a pseudo code in an SQL format showing creation of an object destination table. FIG. 31 is a pseudo code in an SQL format showing creation of an index table. FIG. 31b is a pseudo code in SQL format showing the creation of a channel content table. FIG. 31c is pseudo-code in SQL format showing the creation of a channel template table. FIG. 32A is a pseudo code in an SQL format showing the creation of the work group table 70. FIG. 32B is a pseudo code in an SQL format showing creation of a work group content table. FIG. 33 is pseudo-code in SQL format showing the creation of a workgroup base content table. FIG. 34 is a pseudo code in an SQL format showing creation of a master list table of a work group. FIG. 35 is a pseudo code in an SQL format showing creation of a special content table of a work group. FIG. 36 is a pseudo code in an SQL format showing creation of a work group author member table. FIG. 37 is a pseudo code in an SQL format showing creation of a view member table of a work group. FIG. 38 is a pseudo code in an SQL format showing creation of an address book table. FIG. 39 is a pseudo code in an SQL format showing creation of a copyright table. FIG. 40 is a pseudo code in an SQL format showing creation of a viewer table. FIG. 41 is a pseudo code in an SQL format showing creation of an attribute table of a work group content list. FIG. 42 is a pseudo code in an SQL format showing creation of a reference table for a work group content list. FIG. 43 is a pseudo code in an SQL format showing creation of a management message table of the client server. FIG. 44 is a pseudo code in an SQL format showing creation of a content table of the client server. FIG. 45 is a pseudo code in an SQL format showing creation of a content base table of the client server. FIG. 46 is a pseudo code in an SQL format showing creation of a special content table of the client server. FIG. 47 is a pseudo code in an SQL format showing creation of a distribution queue table of the client server. FIG. 47a is a pseudo-code in SQL format showing the creation of a replication queue table for a client server. FIG. 47b is pseudo-code in SQL format showing the creation of a duplicate destination queue table for the client server. BEST MODE FOR CARRYING OUT THE INVENTION FIG. 1 is a schematic block diagram showing a preferred embodiment of the present invention. The domain communication server A1 communicates with a plurality of client communication servers C1 to C9. Each of these client-side communication servers is placed under the protection of a firewall F at each company site in a preferred embodiment. That is, it is assumed that the company C-1 includes the client-side communication server C1, the company C-2 includes the client-side communication server C2, and the company C-9 similarly includes the client-side communication server. I do. A plurality of temporary logical connections or "pipes" P are formed between each client-side communication server in this domain and the domain communication server A1. In a preferred embodiment, the pipe P is formed over the Internet using a conventional TCP-IP networking protocol and a plurality of secure sockets of Netscape cape Corporation with encryption technology. Connection. However, other networks, protocols, and encryption techniques can be used, as will be apparent to those skilled in the art. FIG. 1 also shows that each client-side communication server C has only one actual connection pipe P with the domain communication server A1. However, it is possible to distribute information from the client-side communication server C1 to any or all of the other client-side communication servers C2 to C9 in accordance with the registration style of each client in the domain communication server A1. It is possible. As described above, the present invention provides an intelligent extranet in which a community including the companies C-1 to C-9 is linked on the network by the domain communication server A1. The extranet provided by the present invention is such that each member client C has a business or institution that is external to C (authorized to communicate with C) and a partner business in which the other client has one of its own internal network or intranet. It allows you to communicate as if you were a part. In this regard, the present invention provides a virtual community for a corporate intranet. Using a more specific example where the corporate community is the financial industry, C1, C2 and C3 are client-side communication servers of three different investment banks, C5-C9 are client-side communication servers of an investment management company, and C4 is In the case of a client-side communication server of a news broadcasting organization, the investment bank in the client-side communication server C1 communicates directly with only the domain server A1 to any other client communicating with the domain communication server A1. But you can still send information. That is, if necessary, the bank C-1 in the client-side communication server C1 sends its own analysis report to only the client-side communication servers C-5 to C-9 in the customers C-5 to C-9. , And the news broadcast organization C-4 can transmit its own information to all other clients communicating with the domain communication server A1. Thus, a preferred embodiment of the present invention also functions as a relational information manager for companies or organizations participating in the community. Therefore, according to the present invention, the customer of the investment bank C-1 can receive valuable information in a timely manner from the commission advisor through a secure connection. FIG. 1a shows some of the types of communication that can be performed. In this example, four different clients C1 to C4 are shown. Client C1 is the only investment bank in Pennsylvania, USA, that has only client-side communication server C1-PA functioning as a "smart intranet" in the method and apparatus of the present invention. The client-side communication server C1-PA is connected to the bank's internal local area network (Local Area Network) C1-Lan, which also has two terminals T1 and T2. As will be apparent to those skilled in the art, terminal T may be a computer, minicomputer, workstation, personal computer, CRT terminal with keyboard, television terminal with Internet function, keyboard or touch screen and display device, personal computer. The device can be connected to any type of network, such as digital assistance or any device that allows a user to communicate with the network and view the displayed information. In a preferred embodiment, a personal computer connectable to a network is used with standard web browser software running on the personal computer. In one preferred embodiment, the term "smart intranet" is used to describe, according to the present invention, an internal network of a company, i.e., the company's "intranet", to participating companies that are internal to the company and external to the company. On the other hand, it shows an aspect in which information management (information creation, access, and duplication) can be performed in one-to-one, group-to-group, and site-to-site. Also in FIG. 1a, client C2 is an investment bank C2 with offices in Hong Kong, New York and London, all of which are interconnected via a bank wide area network C2WAN to form an internal network. The entire bank's network is protected against intrusions from outside by a firewall F2. The investment bank C2's sites in Hong Kong, New York and London have their own local area networks connected: C2-HK Lan in Hong Kong, C2-NY Lan in New York, and C2-LN Lan in London. Included with Terminal T using a standard commercial web browser. As shown in FIG. 1a, each site of client C2 is connected to the local area network at that site and to the wide area network C2WAN of client C2 to establish a smart intranet for client C2 according to the method and apparatus of the present invention. It has a client-side communication server (C2-HK, C2-NY, C2-LN) to be formed. Similarly, client C4 has multiple sites interconnected by a wide area network under the protection of a firewall to form a smart intranet for C4, and client C3 has a domain as the smart intranet for C3. It has a single site in Boston that is in communication with the communication server A1. Also in FIG. 1a, the logical or virtual flow of communication of the smart intranet at the client C2 is shown by dotted lines representing a plurality of "pipes" P2 connecting each LAN within the client C2. As used herein, the term pipe is used to mean a logical connection managed by software, not necessarily a physical connection implemented by hardware. As will be apparent to those skilled in the art, there are numerous ways for multiple local area networks within a client to be interconnected on a wide area network to form an internal network. . In a preferred embodiment of the present invention, as shown in FIG. 1a, these logically interconnected pipes P2 also exist outside the client C2, extend to the domain communication server A1, and through the server A1, It is connected to C1 and C3, but not to client C4. That is, in one preferred embodiment of the present invention, clients such as client C2 are authorized external sites and as if those sites were internal to client C2 or part of C2's smart intranet. Or, it is possible to communicate logically (via the present invention) as if C2 is internal to an external site or part of their smart intranet. However, except for the domain communication server A1, the client C2 does not physically connect to any of these external sites, so that the client C2 never loses the protection function provided by the firewall F2. In one preferred embodiment, all physical transmissions between the client C2 and the domain communication server A1 occur over the Internet using Netscape Corporation's Secure Sockets Layer (SSL) technology and encryption. 1a, each client C is provided with its own "pipe" P from P1 to P6, as shown in legend 00. For example, three sites at client C2 are in internal communication with each other on "pipe" P2. In a preferred embodiment of the invention, client C2 also appears to be communicating with clients C1, C3 and C5 on pipe P2, but in practice client C2 sends C2 to domain communication server A1. It has only one actual pipe to connect. As will be apparent to those skilled in the art, the only pipe between the network of client C2 and the domain communication server A1 may be physically connected, if necessary, using a high-speed line of T1 or T3. It can also be implemented as a simple direct connection. According to the present invention, client C2 can externally communicate with clients C1, C3 and C5 via a domain communication server A1 on a series of "virtual pipes" VP2. The term virtual pipe is used herein to refer to each client as physically communicating with only the domain communication server, and simply "virtually" communicating with other clients or companies. Only when two (or more) clients communicate directly over the Internet (or other network) when the communication is established. Virtual pipes are dynamically created and managed by the logic of the domain communication server of the present invention in cooperation with the client-side communication server at each site. From the above, the term intelligent extranet is used. Also in FIG. 1a, the domain communication server A1 functions as a primary domain communication server for the clients shown, but also connects to a plurality of regional or alternative domain communication servers A2 and A3 at the same time. Note that this has been done. Thus, even if the link to the primary domain communication server A1 of the computer system or physical communication goes down for some reason, in a preferred embodiment of the present invention, the communication is performed via the alternative domain communication server A2 or A3. It is possible to continue. In a preferred embodiment of the present invention, the multiple domain servers keep each other updated by auto-replicating all relevant tables and data so that they are mirror-like to each other. Role. As will be apparent to those skilled in the art, different domains may also be linked together by providing a hyper or super domain communication server that maps together a community of domain communication servers. . Similarly, domain routing in the present invention may also be used internally to create additional domain communication servers for downloading workloads from one another within large internal networks. Can be used. For example, a company that has multiple client-side communication servers at multiple locations in the United States and Europe may have multiple client-side communication servers in Europe mapped to a corporate domain communication server in the United States. May be selected to be connected to A corporate domain communication server in the United States may be further mapped to a plurality of external domain communication servers in the manner described above. By internally using multiple domain communication servers to download work, response time and processing power in the network can be improved. Next, FIG. 3 shows a plurality of connections in a plurality of domain communication servers. Here, the domain communication server A1 that can function as a main domain communication server for a network composed of a plurality of clients is an alternative domain communication server for a plurality of networks controlled by the domain communication server A2 or A3 or both. May also work. Also, the domain communication servers A2 and A3 can function as regional domain communication servers for a single network controlled by the domain communication server A1. Further, FIG. 4 schematically shows a preferred embodiment of the present invention. As shown in FIG. 4, at location C8-BO of client C8 in Boston, computer 20 is connected to domain communication server A1 under the protection of firewall F8 and to client C8's local area network C8Lan. ing. In a preferred embodiment of the present invention, the AOL is used to handle TCP-IP communication protocols between the computer 20, the firewall F8 and the Internet and client requests from a plurality of browsers BR in a plurality of terminals T1 to T4. Server (AOLserver ^TM The standard web server software WS from America Online Corporation (known as American Online Corporation) is installed on the computer 20. As will be apparent to those skilled in the art, any web server software or similar program that handles common communication protocols and transport layer activities can be used with the network protocols used. It can be used as suitable. Similarly, in this example, the database management software DBMS, DBMS 8 stores and maintains a client-side dynamic group registry 07 located on a local electronic storage medium such as a disk 08 connected to the computer 20. Used for In a preferred embodiment, Illustra provided by Informix Corporation ^TM ) With object-oriented relational database software, With the ability to use relational technology for objects, The software is used. However, As will be apparent to those skilled in the art, Any commercially available database management software, It can be used to store and maintain the data of the client-side dynamic group registry 07 stored on the disk 08. Similarly, Any number of electronic storage media can be used instead of disks. For example, On computers with sufficient random access memory, The internal memory can be used as an electronic storage medium. Also in FIG. A client-side communication server CSS (CSS 8 in this figure) running on computer 20 at the Boston site of client C8 is shown. In a preferred embodiment, Using the client-side communication server CSS at each customer or client site, While controlling all content created internally by the client, All contents distributed from the outside of the client to the domain controlled by the domain communication server A1 are received. A given customer's client-side communication server Although it may be composed of two or more servers running on another computer 20, In a preferred embodiment, Each server of the above clients, Using the replication function, Make sure that the authorized information belonging to each site is the same. Note that each customer is not necessarily authorized to access all of the domain's content. In fact, The present invention It is designed to be limited so that it can command and control access to the contents of the entire domain. Also, In a preferred embodiment, A given customer's client-side communication server CSS, Communication with other customers outside of the client must use the Domain Communications server. Now, Looking at FIG. A diagram of several clients communicating with the domain communication server A1 is shown. As you can see from this figure, Client C8, It has the address of the domain communication server A1 on the local disk 08 connected to the computer 20 of the client C8. In this computer 20, The client-side communication server software CSS8 is running. In FIG. Domain communication server A1, A computer 20, A local storage medium with a dynamic client registry 06 stored therein (in this case, Note also that the disc 40) is included. Also, In the domain communication server A1, A conventional Webserver WS is stored in the computer 20. It can be seen that the program is being executed together with the conventional database management program DBMS. In a preferred embodiment of the present invention, Domain communication server software DSS, Executes in cooperation with Webserver WS and database software DBMS. Domain communication server software DSS All clients that are part of this domain in the dynamic client registry 06 on disk 40 (in this case, It can be seen that the list of C1-C8) is held. In a preferred embodiment, Webserver WS, AOLserver product from America Online. I mean, This product can also use object-oriented technology. On open systems, such as Unix or similar operating systems, Shared objects can be created in the C ++ language. In the C ++ programming language, Shared objects are simply compiled code. AOLserver is Web server WS has the ability to dynamically initialize a shared object from a URL registered in WS. Therefore, These shared objects have callbacks. Which shared object to load depends on It is specified in the initialization file used to start the NSD process of AOLserver (executable form of AOLserver). Similarly, In a preferred embodiment, The DBMS software used in the domain communication server A1 is: Illustra software as described above. Also, In a preferred embodiment, Computers used as domain communication servers or client-side communication servers From the main frame to a mini computer, To your workstation or computer, Any of a number of commercially available types may be used. A preferred embodiment of the present invention is It is designed to work with many existing devices as "middleware" (meaning software that cannot be replaced or replaced with existing operating system software or general basic communication software). "Middleware" is not a substitute for application software such as a web browser, It runs "in the middle". In a preferred embodiment, The characteristics and scope of the domain It can be determined according to several different factors. As shown in FIG. Domain communication server Because it is possible to connect the intranets of several different companies or organizations so that they can operate closely, One company operates a domain communication server for one industry segment, Meanwhile, Companies in that segment may have their own client-side communication servers. For example, In FIG. Domain communication server A1 It may be a computer system of the investment banking industry segment of the financial industry, located at the corporate headquarters of the applicant's agent, Meanwhile, Clients C1-C8, It can also be an investment bank and investment management company. But, As will be readily apparent to those skilled in the art, The industry segment is In the law industry, In the automobile manufacturing industry, It can be in the pharmaceutical industry, It can be any of many other large or small industry segments. For example, If the industry segment is automotive, The domain communication server A1 will be operated by the service company. Therefore, Car manufacturers You will be able to communicate closely with suppliers and dealers. Looking again at FIG. in this case, Clients C1 and C2 are competing car manufacturers, Clients C3-C5 may be major parts suppliers, on the other hand, Clients C6-C8 may be dealers. In a preferred embodiment of the present invention, The manufacturer C1 will ensure that the supplier C3, C4, Can communicate closely with C5, on the other hand, Its competitor, manufacturer C2, can also communicate closely with these suppliers. Further, in FIG. In a preferred embodiment of the present invention, Note that the domain communication server A1 and the client side communication servers C1-C8 can be started and shut down independently of each other. For example, The computer 20 which is a part of the domain communication server A1 Even if you have not contacted the client-side communication server, You can boot automatically. When this automatic start occurs, The domain communication server A1 is automatically initialized, Check the server for any messages. If there is no message, The server A1 waits until receiving the message. The client communication servers C1-C8 can also boot their computers at different times. For example, When the computer 20 of the client side communication server C8 is booted before the computer of the domain communication server A1, The client side communication server C8 is automatically initialized, To register with domain communication server A1, Send a message containing the following unique Uniform Resource Locator (s) (URL (s)) Attempt to register with domain communication server A1. In a preferred embodiment, If the domain communication server A1 has not been booted yet, These messages are queued at client-side communication server C8, Will be sent again later. As will be readily apparent to those skilled in the art, Instead of queuing registration messages, Playback can be easily performed at time intervals. In a preferred embodiment, The URL sent by the client side communication server and the domain communication server is at least, The name of the function performed by the recipient (for example, In this case, it is common to include registration. In many cases, These servers are also object-oriented or contain objects. Also, In a preferred embodiment, Client-side communication servers within the same company or client Even if the domain communication server A1 normally used by the client is not running, Can communicate with each other. About client C2, To illustrate this case, Going back to Figure 1a, Client-side communication server C2-HK, C2-NY and C2-LN are all Even when the domain communication server A1 is not running yet, The clients C2 can communicate with each other within the Wide Area Network C2WAN. in short, Internal users and groups set up according to the method and apparatus of the present invention and authorized to create and view content, Even when the domain communication server A1 is offline or down, The invention and the organization and indexing features of the invention can be used to communicate with each other. Normal, Messages that would have been sent to the domain communication server A1 by the client-side communication server of client C2 are queued, Sent when the domain communication server A1 is started. As will be readily apparent to those skilled in the art, If desired, Other methods may be used for communication between the client side communication server and the domain communication server. For example, A method of commanding the domain communication server to operate before the client side communication servers can communicate with each other can also be used. Starting the client-side communication server Turning now to FIG. An overview of the flowchart of the initialization of the communication server on the client side is shown. At step 400, the user initiates a new client-side communication server startup. In step 402, After creating the server shared object, Step 404, 406, 408 and 410 respectively, a client-side server shared object, An admin server supplied object, Tools server shared object, Create an agent server shared object. Once the shared object has been created in step 412 of FIG. Continue processing. In step 414 of FIG. URL's used by the client-side communication server (the main ones listed in FIG. 8B) are registered with the web server WS. next, A work group object is created in step 416. Another aspect of the present invention is shown in the flowchart of FIG. As shown there, In step 420, the client-side communication server is initialized, Then, in step 422, The URLS is registered in the web server WS executed on the computer 20. In step 424, The client communication server calls the registration function on the domain communication server. In step 426, The domain communication server calls the ad hoc content work function on the client side communication server, Then, in step 428, the client-side communication server calls a work function on the domain server. next, In step 430, the domain communication server calls the ad hoc content consumer function on the client side communication server, Finally, the client communication server calls the index function on the domain communication server. Starting the Domain Communication Server Referring now to FIG. The initialization of the domain communication is greatly simplified and shown in appearance (details are provided below). In step 500, The domain communication server initializes itself and the dynamic client registry 06. Next, the domain communication server in step 502, Check for messages (such as register requests coming from the client communication server). If there is no message, The domain communication server will wait until there is some activity. (As seen below, In the preferred embodiment, the domain communication server periodically checks whether the client-side communication server is still active. ). Also in FIG. 20a, When a message such as a registration request from its own domain communication server comes from the client side communication server, The domain communication server in step 504, As described in detail below, Handle the message in the format specified by the message itself. Client-side communication server dynamic group registration Next, referring to FIG. A flowchart is shown depicting the process used by the client-side communication server to initialize or update the dynamic group registration 07. Beginning at step 800, The user gives a name to the group to be included in the group registration 07, Step 805 then indicates whether the type of access to this group is general or restricted (these terms are described in more detail below). next, In step 810, the client-side communication server Whether this group is the base content (specified by subject) selected in step 815, Or, check if the ad hoc content is the selected ad hoc content (identified by source). As shown in detail below, Preferred embodiments utilize other types of content-mixed or uncoupled mixed content as well as system content. These processes are the same. The ability to group content in multiple ways without departing from the spirit of the invention It will be clear to those skilled in the art. Further in FIG. In step 825, the client-side communication server configures a content list. In a preferred embodiment, The client-side communication server then proceeds to step 830, Check if a rolling link format or a fixed link format is desired, In step 875 or 840, the content list is updated to list the titles, Specify the number of lines to be displayed according to the format. Next, In step 845, the user specifies the subject and / or source of the content to be displayed on this content list for this group in dynamic group registration 07. In step 850, The user selects a qualified member, Step 855 reviews the members, Finally, at step 860, the user can review the configuration of the group. FIG. The communication server on the client side Create a client-side communication server shared object (compiled C ++ code) to communicate with other client-side communication servers within your company (see steps 905 and 910) or outside your company (see steps 915 and 910) The flowchart for the decision is shown. Figures 22 to 26 are block diagrams of interactive displays created in accordance with the present invention for browser use at the end. These figures illustrate the preferred embodiment of the present invention. It is an illustration of the above steps of creating a group on dynamic group registration 07. For example, FIG. It shows how the user enters a new username, FIG. 23 shows an example of how to account for information specific to a user-inputtable item such as a user name. In FIG. It shows how the client-side communication server initiates the process of establishing authorization (details below). Figures 25a and 25b show 1 illustrates an example of a method of arranging contents in a map by the whole area. As shown, The user is asked to specify his or her choice for this choice. next, In FIG. 25c, Sample distribution options are shown. next, In FIG. 26a, the client-side communication server allows the user to specify whether the new group member has redistribution authorization (this term is described in detail below). If you want to specify The user, as shown in FIG. Extend this redistribution right on a limited or unrestricted basis to internal members only, Or you can specify to extend to external members on a limited or unlimited basis. next, FIG. 26c shows a sample screen display asking if new members should access the restricted group. If the user responds yes to the screen, Figure 26d shows how the user is asked to specify, Determine which restricted groups new members will have access to, Also which ability-ie Reviewer or Contributor Or a redistributor or an administrator, Or all of these, Or it is decided whether it is some combination or not. In FIG. 26e, A sample screen display is shown asking the new user to specify what kind of external group access they have. Returning to the financial group example, The display in FIG. New member is another participating company-company C1, located in the same intelligent extranet It has been shown that it is very easy to "authorize" the creation and distribution of documents to C2 and C3. After the user has answered the questions about adding new members, The client communication server ends the dynamic group registration reflecting these changes. As will be apparent to those skilled in the art, The communication server on the client side is self-contained, Much better than current intranet management tools, It can also be used to easily provide simple in-house tools. The client communication server also works with strong publishing controls. Just answer the question that appears on the screen asking if you want to add new members and groups to the client-side communication server, Users can better organize personal and group information known to client-side communication servers, Index, You can control. Returning to the example financial group shown in FIG. If this client side communication server is Hong Kong, Assuming that it is set up in bank C2 with branches in New York and London, (Of FIG. 1a), Duplicate itself and Hong Kong client-side server C2-HK, New York has a client-side server C2-NY, And London can have a C2-LN. As you can see from the discussion below, The London viewer calls on the specific information he is entitled to receive, You can see and comment inside it, And if he has this kind of redistribution right, Hong Kong and New York colleagues can view this comment. Turning now to FIG. 6a, Typical client information maintained by the domain communication server A1 in the dynamic client registration 06 is shown. The dynamic client registration 06 includes a domain client table 60 (shown here in simplified form), Domain client source list 66, A domain client object table 62 and a domain client object destination list 68, And an index table 64 and a channel table 61, Channel content table 63, A channel template table 65 is included. Domain client table 60 lists all client-side communication servers in the specified domain. As mentioned above, A client can have one or more client-side communication servers (for example, The client has multiple sites across the world, such as clients C2 and C4 in FIG. 1a). Therefore, In one preferred embodiment, as shown in FIG. 6B, The entries in the domain client table 60 of the dynamic client registry 06 are: For each client server, Original client side communication server name 60a, An indicator 60b indicating whether the server is in an active state, Unique company identification means 60c indicating the name of the organization, company or customer who owns this server; A corporate logo (logo) 60e that can be played back on videos related to this company, And In one preferred embodiment, the server location in the corporate intranet, It includes a domain client side identifying means 60f for forming a unique key in combination with the company identifying means field 60c. While this may seem obvious to those skilled in the field, If desired For each client-side communication server, More information than the above information or less information than the above information, Alternatively, a configuration including information other than the above information is also possible. For example, In some cases, in addition to the logo, It is also possible to include the address of a corporate web page on the WWW. Alternatively, Without departing from the spirit of the invention, It is also possible to delete the logo field or the tentatively illustrated web page address field. Returning to FIG. 6a, In one preferred embodiment, Each entry in the domain client table 60 is: It is linked to a domain client source list 66 (schematically shown in the figure). The domain client source list 66 5 is a list of all connections between client-side communication servers in the domain. Still referring to FIG. Taking the automotive domain as an example, Competitors C1-PA and C2 are two competing manufacturers, If C3 is a parts supplier for both, The domain client source list 66 can also be configured as shown. In column 66a, Unique company identification means, That is, the DSC company ID is It is displayed next to each source DSC and each company ID in the column 66b. Therefore, Company C1-PA, It is possible to receive content from C1-PA itself and supplier C3. Company C1-PA, Note that it is not shown as being entitled to receive any source information from competitor C2. Similarly, Company C2 It is possible to receive source content from yourself and supplier C3, Not from company C1. This means It shows how the virtual pipe is formed. Still referring to FIG. A domain client object table 62 is also shown. The domain client object table is Domain communication server, All distributed objects received from any legitimate client-side communication server in a given domain, Contains. When receiving such an object, Domain communication server For the above object, Notify all client-side communication servers that have legitimate access rights to enable retrieval of an object. Each entry in the domain client object table 62 is: It points to a different domain client object embedding table 68 that lists all client side communication server sites that are allowed to receive the domain client object and embed the object. In one preferred embodiment, The domain client Iohandle Large object handle in domain client object table 60 pointing to distributed content sent to client side communication server. Briefly explaining FIG. 6B, Along with the domain client object embedded table entry The domain client target table 68a is A list of all server names of a plurality of client-side communication servers in which this object is embedded is displayed. Column 68c received by the domain client is For each target client-side communication server, It contains the time at which the object was received by the domain communication server. The table 68d processed by the domain client is: For each client-side communication server, It contains the time at which the object was processed by the client-side communication server. In one preferred embodiment, This field is Initially set to Null, Updated when the client-side communication server looks up the domain client object. Returning to FIG. 6a again, In one preferred embodiment, One object is It can be any type of information transmitted to the client. For example, In the investment finance business domain, It may be a morning analysis prepared by one investment bank C1-PA for its clients. At its simplest, Object 62 may be in simple ASCII text format, Adobe Acrobat readable worldwide ^TM It may be in PDF format or Microsoft Word ^TM Or Corel's Wordperfect ^TM Microsoft Excel, even if the format is specific to a word processing program such as ^TM Or IBM's Lotus1-2-3 ^TM It may be a spreadsheet program such as a spreadsheet. Similarly, if a company already has existing HTML pages, these pages can also be objects. Of course, it should be noted that in one preferred embodiment of the present invention, the objects that are the content for all communications can be of any form for any practical purpose. For example, an object may be a full color movie with sound, or a complex object such as a CAD / CAM VLSI drawing of a chipset or a mechanical drawing of a car under development. In the latter example, CAD / CAM or mechanical drafting, which is usually confidential, according to the invention, the design department of a company, such as an automobile manufacturer, enters into planning with a contract engineering company. By exchanging drawings accordingly and annotating them, it is possible to work very closely and safely. In a preferred embodiment of the present invention, the object to be transmitted is encrypted by the transmitting client-side communication server, and the receiving client-side communication server of only the client who is authorized to receive the object is used, because the secure socket transmission technology is used. Will be decrypted. In one preferred embodiment, this encryption and decryption of the transmitted object is an automatic by-product of using secure socket technology and its equivalents or improvements. As would be apparent to one skilled in the art, other encryption techniques could be used instead of secure sockets or similar techniques. For example, techniques such as direct encryption using software such as PGP based on the RSA encryption algorithm can be used. 6A, the illustrated domain client object table 62 includes an ASCII text report 62a, a slide presentation 62b, a word processing document 62c, a movie 62d, and a multiple report 62e. In one preferred aspect of the invention, the objects are displayed as text or files. The first item, that is, the ASCII text format report 62a is processed as ASCII text in the present invention. All other objects in the domain client table 62 are treated as files. In the case of the slide presentation 62b, for example, the object is transmitted as a file to the domain communication server A1, from which all appropriate client-side communication servers also receive the object as a file. At a client site, when a terminal T accesses an object, the terminal has a suitable application program for viewing (opening) the file available at either the client site or its corresponding server. Is needed. Therefore, the slide presentation 62b according to FIG. ^TM Viewers at the client site, when created using Microsoft's Powerpoint software to view slides ^TM (Usually this requirement is achieved by copying the installed application software on the terminal or, if the terminal is a computer, on the terminal's server). ). This is usually an advantage, not a problem, because for many business personal computer users, there are commercially available products, such as word processors, spreadsheets and presentation software, that are practically near standard. by. As will be apparent to those having skill in the art, according to the present invention, the user will continue to use the "standard" product, as well as specially developed software programs that work on files. It becomes possible. This is important for many users who have made significant investments in current application software and traditional developments. 6a, an index table 64 is also shown as part of the dynamic client registry 06. The value of the index is the same for a given domain. As shown in FIG. 6a, a display index is shown for the financial market segment domain, including mortgages, brokers, newly issued receivables, research, and other indexes that can orderly display the content of the domain. Referring now to FIG. 6b, there is shown an index entry including an index ID 64a, an index description 64b, an index base type 64c, and an index parent ID 64d. The index ID 64a is unique index identification means. In one preferred embodiment, the index based type 64c is used to determine which format (text or file) is used as the default format for the index, but the total content for the index is in which format Can also be taken. The index description 64b is an explanatory label attached to the index. Further, the index parent ID 64d is the index ID of the entry source. Referring back to FIG. 6a, in the index table 64, it can be seen that the index 11, ie, the newly issued receivable, is the index ID, ie, the subordinate item (“child”) of the mortgage. Further, the index 61, ie, education, is a sub-item of newly issued bonds. In one preferred embodiment, the index can have as many levels (hierarchies) as needed. 6a, in one preferred embodiment, a channel content table 63 and a channel template 65 are also created. In one preferred embodiment of the present invention, the channel is a combination of various indices. For example, one channel may consist of all indexes including the latest information items. Another channel may consist of the most frequently used indices. As will be apparent to those having skill in the art, the number and content of the channel groupings can vary between industries or over time. As can be seen, the channel table 61 is used to organize domain content into related categories. The channel is then sent to the client-side communication server at startup and used during setup operations and group management. In another preferred embodiment, this function can be included in the client side communication server using the client side communication server or the internal domain communication server. Referring now to FIG. 6b, the channel table 61 includes a channel ID field 61a, a channel name field 61b, and a channel description field 61c. For the latest information item, channel ID 1 may be assigned along with a channel description such as the channel name “hot news item”, “new information from newly issued receivables, mortgages and research indexes”. As will be apparent to those skilled in the art, if the domain is in another industry segment, such as the automotive industry, the index and channel will represent different topics and combinations of topics . In one preferred embodiment, the channel content table 63 is used to determine the content that makes up the channel. Referring again to FIG. 6b, the channel content table 63 includes a channel ID field 63a, a channel content ID 63b that forms a unique key with the channel ID field, whether the content is basic content, special content or other types of content (described below). And a channel content source field 63d indicating one or a plurality of sources related to the content for the channel. In one preferred embodiment, the channel template table 65 is used to organize channel content. Each template includes a channel template ID field 65a, a channel template field 65b that forms a unique key together with the channel template ID field 65a, a channel template attribute field 65c that defines the attribute of the content list, and an ID in the channel content table 63 It includes a channel template source field 65d to be described. Referring now to FIG. 7a, the structure and contents of the dynamic group registry 07 of the present invention are illustrated. In a preferred embodiment, the dynamic group registry 07 is used at each client to handle all content created internally at the client and content created within the domain received by the client. As described above, each client-side communication server must use a domain communication server to communicate with client-side communication servers of other farms. As shown in FIG. 7, the main entry of the client-side dynamic group registry 07 is the group table 70. The group table 70 is a list of all groups set in a specific firmware or client. It should be noted that although the term workgroup appears in figures or in the text, the term group is generally preferred and can be interchangeably interpreted. The group is used to form the type and source of the content (specified in the content table 90 and the specific content table 94) that can be used in the group, and each time information is received, the respective content for the group is used. Create a list. The CS content table 90 includes an object ID 90a, an author ID 90b, a content link object ID 90c, a content headline 90d, a content file name 90f, content information 90g, a content time stamp 90h, a content origin site 90i, a content origin object 90j, and a content data attribute 90k. To form content. Upon content creation, this content is automatically added to all groups that have requested the content of that particular type. The specific content table 94 forms specific content according to the source of the information, or is added to the group when the publisher designates the specific content to a certain group. As is evident from table 70 of FIG. 7, in the preferred embodiment there are two types of groups, shared and limited. The sharing group can be accessed by clients or all viewers in the farm, but can only have base content. The limited group can be viewed only by members of the group specified in the work group viewing member table 82. Limited groups are allowed for base content, specific content, and other types of content that may be developed in the future. Specific content can be added to the group only by the group's author and publisher (workgroup author member table 80 and workgroup viewing member table 82). Further, in the group table 70 of FIG. 7a, in the preferred embodiment, all groups have a community indicated by the field WG community, of which "known". The community is used to "advertise" to other groups in the farm or client. The community includes creators of content advertised inside the domain (for farms or clients only) or outside the domain. Internal groups are not known outside of the firm or client. External groups are known inside the firm or client. If a workgroup is set as the creator in the preferred embodiment using the value "2" in the WG community field of the group table 70, the group is advertised as a source of specific content for other groups. Further, in FIG. 7a, in the preferred embodiment, groups only within the firm or client are indicated by using a "0" in the WG community field of the group table 70. As shown in group table 70, work group WG1, which is a firm wide group, is the only internal group listed in this particular example. The external group is indicated using the value “0” in the WG community field of the group table 70. To set a value in the WG community field, the preferred embodiment XORs those values to determine all alternatives. In the preferred embodiment, the WG group ID is always unique because it consists of a firm ID, a site ID and a number. As will be apparent to those skilled in the art, many methods can be used to create a unique group ID or WG group ID. 7a, the workgroup base content table 74 is used to determine the base content that each workgroup wants to receive when a certain base content is created internally or externally. The base content is selected by content type (WGBC index ID) and received by both shared and restricted workgroups. When a specific content type is received, the workgroup's content list headline is updated. Work master list table 76 provides descriptive text information about the list. Referring again to FIG. 7a, the workgroup specific content table 78 is used to determine the base content that the workgroup wants to receive when each certain base content is created internally or externally. The specific content is determined by the source, not the index of the content. The source of the particular content is the group that has already “advertised” itself, as described above. A mixed content is a combination of a specific content and a base content. Also, in FIG. 7a, the workgroup author member table 80 includes a list of authors and groups that specify that these authors are allowed to add specific content to their respective groups. Authors are selected from a list of authors in the farm or client. The group is also selected from the list of groups in the farm or client. Entries in this table exist only in the group that has designated the creator of the new content. In the example of the work group author member table 80 shown here, there is a work group author identifier WGAMauthorID. This field is linked to the ViewerID of the viewer table shown below. The workgroup author identifier WGAM authorID identifies the unique group within this client to which the member belongs. This value is linked to WGgroupID in the group table 70. In the example shown in FIG. 7a, the same author, tburns, is listed as a member of workgroup 2WG2 and workgroup WG3. The field workgroup author member restrict MGAMrestrict is set true in the preferred embodiment if the author is considered to be individually "authorized" to send to each workgroup that uses the contents of this workgroup. Boolean value. If this value is set to false, the author can send to any workgroup that uses the contents of this workgroup. 7a, the workgroup browsing member table 82 contains a list of browsers of all workgroups. Only viewer members of a workgroup have access to view the workgroup content. All viewers of a workgroup are selected from a list of valid viewers for the firm or client. The workgroup administrator (specified in the WGVadmin field) is allowed to determine the members for the group and the attributes of any members. Distribution of the group's content is controlled by the viewer attribute field WGVM attribute. In the example shown here, the viewers of work group 2WG2, tmalone and tburns are administrators for work group 2WG2. In the preferred embodiment, there are five possible values that can be set in the viewer attribute field WGVMMattribute. That is, Distribute None (no distribution) Distribute Internal (internal distribution) Distribute External (external distribution) Distribute Internal Restricted (restricted internal distribution) Distribute External with preferred choices , These values are also exclusive ORed. As will be apparent to those skilled in the art, various other methods can be used to indicate the attribute of a member. Referring again to FIG. 7a, the address book table 84 contains, as members of the address book group identifier ABgroupID, a list of groups for which an author or publisher is permitted to distribute content. In other words, ABgroupID is a unique ID of a workgroup that has been permitted to distribute the content of the workgroup to the designated author or publisher. This value is linked to the GroupID of the group table 70. The address book destination field ABdestination includes a firm ID and a workgroup ID of a group to which the author or publisher can distribute content. In the preferred embodiment, the address book attribute field ABattribute of the address book table 84 is set to true if the workgroup allows this author or publisher to add notes to the content, otherwise not. Is a boolean value set to false. 7a, an author rights table 88 is used to determine the types of content that an author can create. This table contains three fields. That is, the author identifier AuthorID, the author index identifier AuthorIndexID, and the author attribute AuthorAttribute. In the preferred embodiment, the content types (specified in the author attribute field) that the author can create are determined by the firm or client. This allows the client to define and implement its own internal policies for such situations without having to accept policies set by others or restrictions of certain external systems. All authors must be valid viewers of the firm or client. In the preferred embodiment, each author has minimal authoring attributes for internal broadcasts for the specified content. In the preferred embodiment, possible values are as follows: Internal Broadcast 0 Internal Selective 1 External Broadcast 2 External Selective 4 These values are exclusive choices in the preferred embodiment because they are exclusive choices in the preferred embodiment. Is taken. As will be apparent to those skilled in the art, other methods of defining and implementing such values are possible. In FIG. 7a, the viewer table 86 contains a list of all authorized users or viewers at the authorized client or company. This table is used to determine if a particular user or viewer is a member of the client's intranet and, if the user or viewer is on this table, the client's intranet is authorized and used for access. Users or viewers added to this table are allowed access to all common client or corporate workgroups, as specified in the WG Member field of the group table 70. Referring to FIG. 8a, returning to the domain communication server, a list of the main domain communication server URLs is shown. As noted above, in the preferred embodiment, the domain communication server is implemented using AOL server software. This is because shared objects can be dynamically loaded when creating a virtual server. In the preferred embodiment of the present invention, object-oriented programming techniques are used, since procedures can be created for objects whose exact type is not known until the program is actually executed. Also, object oriented technology allows system practitioners to define and use shared objects, for example, compiled C ++ code called by one or more functions or programs. For example, at the AOL server, which shared object to load is specified by the initialization file used at the start of the AOL server's NSD process. In the preferred embodiment of the present invention, a shared object named 'domainserver.so' (or known in the NT version as 'domainserver.dll') is a shared object that is loaded when the AOL server starts. As indicated. In the preferred embodiment, an AOL server application program interface (API) is used. This is because it is an interface for developing a shared object that can be loaded by the AOL server. The API is ANSI-C, a standard programming language interface. Therefore, a C ++ wrapper function is required to bridge between C based on the AOL server and C ++ based on the domain communication server object. There are two functions defined by the domain communication server, termed "go" and "stop". As will be apparent to those skilled in the art, a server or program with similar functionality can be used instead. At the start of the virtual server, the AOL server NSD parent process looks for a function named NS_ModuleInit. It is defined (per AOL server documentation) for all shared objects that are loaded and contain the required start code. The NS_ModuleInit function domain communication server of the present invention has two responsibilities. One is to register a shutdown procedure "stop" that is called by the parent NSD at shutdown, and the second is to call a C ++ wrapper function "go" that creates an example of a domain server object. It is because of the shutdown procedure "stop" that the domain server objects generated by calling "go" are wiped out. As described above, a domain communication server according to the method and apparatus of the present invention can distribute and collect content with various client-side communication servers depending on its domain. It also controls which client-side communication servers are communicating with each other and functions as a switching point. Creating a domain communication server is all that is required by the wrapper function go0. When creating a domain communication server object, the following steps are performed. First, the domain communication server saves local variables that identify the "recognized" name of the virtual server (among others) and access the underlying database manager. Next, the valid categories used by the domain to organize all of the contents of the domain are loaded from the table index (see FIG. 6b) and stored internally as index objects. Third, the domain communication server provides a virtual pipe (as shown in FIG. 1a) of all valid domain clients known in this domain, their network addresses, and which clients can communicate with each other. To determine. Valid clients, client communication servers, and each virtual pipe are found in the Domain Client and D Client source tables and are stored internally as Domain Client objects. Fourth, when a new group is created at the client-side communication server site, the domain communication server determines a predefined template to be used by clients of the domain. In configuring what is consumed by the client-side communication server, these templates are used to organize the domain index objects and network producers into a more organized format. Information on these templates is shown in the channel, channel content, and channel template tables shown in FIG. 6a and stored internally as channel objects. Finally, the domain communication server stores the URL (Uniform Resource Locators) handled by the domain communication server shown in FIG. 8 and the corresponding callback function in the domain communication server called by the AOL server parent NSD process when the URL is requested. , AOL server parent NSD process to register. These registered URLs are used to communicate using a domain between the domain communication server and the active client-side communication server. As a result, information is exchanged between the client-side communication server and the domain communication server via the registered URL. All information exchanged is in a form known in the art as a persistent object (ie, an object that can be re-stored from a stream) and is retrieved and / or distributed via each URL . The following is a list of URLs, registered legal methods, and the event classes associated with the preferred embodiment respectively. URL method Event class / Register GET CSS registration / Indexes GET CSS registration and registration change / Consumer GET CSS registration and registration change / Producers GET CSS registration and registration change / Channels GET CSS registration and registration change / Unregister GET CSS registration / Status GET status / DistributeObject GET Content copy / CollectObject GET Content copy / Refresh GET Registration change / FirmLogo GET CSS registration / InternalServers GET CSS registration Status / ReloadIndexes POST status / Status / CSSStatus GET status After startup, the domain communication server will be Check the status of each valid client-side communication server and incorporate a timer procedure that pings a server that has not recorded any activity in the last 5 minutes. In the preferred embodiment, a ping is simply a message asking for a status returned from the client-side communication server. An example of a domain communication server that attempts to ping a client-side communication server is as follows. https://validCSS.com:84/Ping In response to this URL, the client communication server of the preferred embodiment returns an HTTP status code 200 signaling the domain communication server. When the client communication server is pinged, it determines the current situation, starts and starts the client communication server, and ensures that it is registered with the domain communication server. When the client communication server responds to the ping message, the domain communication server checks whether the client communication server is already registered and registers with the client communication server (when the client communication server is longer than the domain server). If it is running, re-register). If the client-side communication server is currently registered, the domain server records the last contact time with the client-side communication server and keeps the client-side communication until the lag of 5 minutes or more that occurs before the contact is re-established. Do not ping to server. If the client communication server does not respond to the ping, the domain communication server records that the client communication server is not registered and attempts to ping the client communication server every 60 seconds until a response is returned. . Once initialized, the domain communication server simply responds to events generated by the domain. The domain communication server can verify that the event is valid, as well as inform the client-side communication server of the effect of this event. As mentioned above, this is done via URL handling. The following is a list showing the events associated with the event classes that can occur in the domain. 1. Registration of the client-side communication server Registration of the client-side communication server with the domain communication server is performed when the client-side communication server requests the "Register" URL from the domain communication server (when the address of the domain communication server is (If found in the initialization file used to start the domain communication server). In the preferred embodiment, the URL format is "DomainServer: / Reglster? ID = CSS", where Domain Server is the protocol, the machine name (and port) of the requesting party, and the ID variable is the CSS's protocol. Machine name (or port). Because the protocol is specified in this method, it is trivial whether the domain uses the standard HTTP or SSL layer. In another preferred embodiment, the present invention implements the X.500 Lightweight Directory Access Protocol (LDAP). One example of a client-side communication server attempting registration is as follows. https://myDomainServe.com:81/Register?ID=https://valid CSS.com:84 Next, the domain communication server checks the internal collection of DClient Objects (loaded at startup). This proves that the location specified by the ID is a valid location for this domain. If the request is validated, the domain communication server returns from the dynamic client registry 06 to the client-side communication server "virtual pipe" available to this client-side communication server by passing the list of ClientSource Objects. . The dynamic client registry 06 serves as a repository that enables the virtual community of the Internet to be formed. In the preferred embodiment, validation requires that the domain communication server request a ContentProducer and a ContentConsumer Object from the register client-side communication server site. The response from the client-side communication server is in the form of a stream for each object (streaming is the data input / output format used by most open systems). Objects are recreated and collected locally at the domain communication server. It is the responsibility of the domain communication server to determine which ContentProducer and ContentConsumer are available on which client-side communication server, by consulting a list of already established "virtual pipes". An example of a domain communication server that requests registration of ContentProducer Objects to the client side communication server is as follows. https: // validCSS> com: 84 / AdhocContentProducers An example of a domain communication server that requests ContentConsumer Objects from a client-side communication server is as follows. https://validCSS.com:84/AdhocContentConsumers As shown in FIG. 8a, in the preferred embodiment, registration of the client-side communication server then uses additional URLs handled by the domain communication server to add additional information about the domain. Request information. Before returning the requested information, a validity check is performed on all potential recipients. This information includes: ● A list of Index Objects used by the domain is requested by the Indexes URL 106 in Figure 8a. Index Objects are used to organize content by subject matter within a given domain, and are centrally hosted by a domain communication server in the Dynamic Client Registry 06. Index Objects is used by the client-side communication server as part of its dynamic group registry 07. The response to the Indexes URL 106 in FIG. 8a causes the domain communication server to repeat the collection of the Index Objects and return them to a stream format. The stream format is translated back to Index Objects at the client-side communication server site and collected locally. An example of a client-side communication server requesting an index is as follows. https: // myDomainServercom: 81 / Indexes? ID = https: ..validCSS.com: 84 ● By requesting the InternalServers URL 126 in FIG. 8a, the InternalServer Objects are collected. InternalServerObjects are used by the client-side communication server in determining the site of all other client-side communication servers that appear to be of the same company, so that the responsibility of the client-side communication server repeats between them. You. In response to the InternalServers URL 126, the domain communication server requests the validated DomainClient to repeat the collection of VirtualServer Objects and return it in a stream format. This stream format is retranslated into InternalServer Objects at the client-side communication server site and collected locally. Only client-side communication servers from the same company are returned (this includes client-side communication server requests). An example of a CSS requesting an internal server is as follows: https://myDomainServer.com:81/InternalServers=https://validCSS.com:84 ● A list of ContentProducer Objects is retrieved from the Producers URL 110 in FIG. 8a. ContentProducers are used by client-side communication servers as part of the dynamic group registry 07 as a usable source of adhoc and mixed content. ContentProducer Objects contains information about the producer and what it creates. It is the responsibility of the domain communication server to determine which ContentProducers are available to the requesting client-side communication server by examining the list of already established virtual pipes. In response to the producer URL 110 of FIG. 8a, the domain communication server causes all other client-side communication servers in the domain to return ContentProducers available in the requesting client-side communication server in a stream format. For multiple internal server sites, the stream also includes internal producers. This stream format is retranslated into a ContentProducer Object in the client-side communication server and collected locally. An example of a client-side communication server requesting ContentProducers is as follows. https://myDomainServer.com:81/Producers?ID=https://validCSS.com:84 ● A list of ContentConsumer Objects is requested via the Consumers URL 108 in FIG. 8a. ContentConsumers are used by client-side communication servers as part of a "domain registry" to determine which of its producing groups have consumers requesting content. In response to the Consumers URL 108 in FIG. 8a, the domain communication server causes all other client-side communication servers in the domain to return ContentConsumers available in the requesting client-side communication server in a stream format. For multiple internal server sites, the stream also includes internal consuming groups. This stream format is translated back to ContentConsumer Objects at the client-side communication server site and collected locally. An example of a client-side communication server requesting ContentConsumers is as follows. https://myDomainServer.com:81/Consumer?ID=http://validCSS.com:84 A list of ClientInfoChannel Objects is collected via the Channels URL 128 in FIG. 8a. ClientInfoChannel Objects is used as a template for creating a new group on the client-side communication server. The InfoChannel Object organizes the content portion of the domain into pre-configured views to facilitate group creation at the client-side communication server site. In response to the Channels URL 128 in FIG. 8a, the domain communication server causes the Infochannel object available at the requesting client-side communication server to be returned in a stream format. This stream format is translated back to ClientInfoChannel Objects at the client-side communication server site and collected locally. An example of a client-side communication server requesting Channels is as follows. https://myDomainServer.com:81/Channels?ID=https://validCSS.com:84 A list of Logo Objects is collected via the FirmLogo URL 116 in FIG. 8a. Lo go Objects are used to make the content even more "highlighting." The registering client-side communication server requests any Logo Objects that do not currently have a "current" Logo Object. The state of the Logo Object is determined from the list of ClientSource Objects received from Register URL 102 in FIG. 8a. In response to the FirmLogo URL 116 in FIG. 8a, the domain communication server returns the associated LogoObject of the specified client-side communication server in a file format. This object is stored on the local file system and is provided whenever viewing content originating from this source. An example of a client-side communication server requesting LogoObjects is as follows. https: //myDomainServer.com.81/FirmLogo? ID = https: //validCSS.com: 84 & SRC = https // myCSS2.com.85 The registration of the client-side communication server is Trigger the domain communication server to notify all other client-side communication servers (with virtual pipes) that a change has occurred in the dynamic client registry 06 that may be of interest to the client. This causes all Registry Change events at each corresponding client-side communication server. This change includes the availability of both additional consumers and producers found in the registering client-side communication server. This notification is made by requesting a / Refresh URL at each client-side communication server and by explaining that both / Producers and / Consumers have changed and should be refreshed at the convenience of the client-side communication server. (See "Registry Changes" below for a detailed description.) In the preferred embodiment, registration is always initiated by the client-side communication server. However, also in the preferred embodiment, the domain communication server can request any client-side communication server to re-register whenever the domain communication server determines that it is appropriate. 2. Unregister Client-Side Communication Server Unregistering the client-side communication server occurs when the client-side communication server needs to notify the domain communication server that it is no longer available for the domain. This event is controlled by the client-side communication server and can occur at any time, but in the preferred embodiment occurs whenever the client-side communication server attempts a normal shutdown. The client-side communication server notifies the domain communication server that it wants to cancel the registration via the Unregister URL 104 in FIG. 8a. The format of this URL is Domainserver: / Unregister = ID: CSS ", where Domain Server is the protocol, the machine name (and port) of the requesting party, ID Variable is the protocol of the client-side communication server, The machine name (and port) is an example of a CSS that attempts to unregister: https://myDomainServer.com:81/Deregister?ID=https://validCSS.com:84 The domain communication server verifies that the location specified by the ID is a valid location for this domain by examining its internal collection of DClient Objects (loaded at startup). The domain communication server returns an HTTP status code of 200 and the client-side communication server considers the domain deemed to have been deregistered. All content addressed to this client-side communication server is queued until the client-side communication server becomes available to the domain again.In a preferred embodiment, the client-side communication server is deregistered. Is also initiated by the domain communication server, which means that the client-side communication server has been requested by the domain communication server after a specified time (usually 5 minutes) has elapsed since the last contact from the client-side communication server. / Ping URL does not respond. As can be appreciated by those skilled in the art, this interval can be short or long, and similarly, the preferred embodiment uses this approach, Client-side emails that have been unregistered for this reason It will be apparent to those skilled in the art that messages may be queued for the server, but other techniques may be used to defer the message for an unresponsive client-side communication server. In the example, unregistering the client-side communication server causes a change in the domain registry that the client may be interested in for all other client-side communication servers that have virtual pipes to the registering client-side communication server. The domain communication server is triggered to notify that. This change includes the invalidation of both additional consumers and producers in deregistering client-side communication servers. Notifications should be made at each client-side communication site by requesting a / Refresh URL and that both / Producerst and / Consumers have changed and should be refreshed due to the client-side communication server. Executed in 3. Content Replication This event occurs whenever there is a need to send content from one client-side communication server in a domain to another client-side communication server. It should be mentioned that in the preferred embodiment the domain communication server is only responsible for content replication (external replication) between client-side communication servers of different companies. Content replication (internal replication) between client-side communication servers of the same company is performed directly between two (or more) client-side communication servers. In the preferred embodiment, there are three types of content that can be replicated across the domain: base content, Adhoc content, and mixed content. (The preferred embodiment further provides a fourth type of content known as System Content, but this type is not replicated.) The type of content is determined by how the content is organized . Base content is content composed of topics or subject matter. Subject matter must be defined in the IndexObjects of one or more domains. The origin of the content (ie, where it was created) is irrelevant. Base content can include one or more associated indices. On the other hand, the Adhoc content is not the subject matter but the content constituted by the starting point. The origin must be one or more "producing" groups at a given client-side communication server in the domain. Mixed content is a combination of both adhoc content and base content. Mixed content has an origin and an associated subject matter. In a preferred embodiment, the mixed content may be of two distinct types, uncoupleable and decoupleable. Uncoupled mixed content cannot be separated into base and adhoc parts, but must be treated as a whole, whereas decoupleable content can be separated into subcomponents and these can be treated separately It is. The type of content is determined by creating a client-side communication server at the time of content creation. The type of content replication can be in two suitable modes, broadcast or selective distribution, based on the available destinations allowed for producing individual at the client-side communication server site, Controlled by the communication server. Broadcasting content has the effect of distributing the (base) content to all other client-side communication servers in the domain where the first client-side communication server has established a virtual pipe. Selective distributions replicate only (adhoc and / or mixed content) to the specified client-side communication server, not the entire domain. In a preferred embodiment, the type of replication specified refers to the type of content to be replicated. That is, only the base content can be broadcast, and only the Adhoc content and the mixed content can be selectively distributed. The flow of content is controlled by the DistributeObject URL 112 in FIG. 8a and the Collect Object URL 114 in FIG. 8a for collecting and distributing content across the domain. Only the client-side communication server needs to understand (to process) this type, and since the content is encapsulated in a DistributedObject, the type of content has nothing to do with the replication process. DistributedObject consists of four parts: origin, target, data, and signature. The origin and target are used by the domain communication server to determine who can receive the object, and the signature and data portions are used by the client-side communication server to recover the object for processing. In a preferred embodiment, replication is initiated by a client-side communication server that has been predetermined to distribute content to the outside world. In the preferred embodiment, the client-side communication server stores the DistributedObject locally and also notifies the domain communication server that the DistributedObject is waiting to be propagated at the client-side communication server site. The client-side communication server specifies a unique identifier for the DistributedObject to be used by the domain communication server when collecting objects. The client side communication server does this via the DistributeObject URL 112 in FIG. 8a. An example of a client-side communication server that attempts to notify a domain communication server to distribute an Object is as follows. https://myDomainServer.com:81/DistributeObject?ID=https:ValidCSS.com:84&OID=3043.201e In response to the DistributeObject URL 112 in FIG. 8a, the domain communication server informs that the notification has been delivered. While sending an HTTP status code 200 to the client-side communication server. After sending the notification, the domain communication server requests a DistributeObject from the original client-side communication server, using a unique match specified in advance. This is accomplished by requesting the Collectobject URL 114 in FIG. 8a. An example of a domain communication server that collects Distributed Objects from a client side communication server is as follows. https://validCSS.com:84/CollectObject?OID=3043.201e The response from the client-side communication server is a stream-type DistributeObject. This stream is captured by the domain communication server and recreated in the DistributeObject at the domain communication server site. The client again communicates locally the time at which the domain communication server searched for the DistributeObject for auditing purposes. After searching for the DistributeObject, the domain communication server determines the source and the specified list of available targets. The domain communication server maps its target with its destination with which the originating client-side communication server has established a virtual pipe. Next, as shown in FIG. 6a, the DistributeObject is stored in the DCOBJECTS table 62 by the domain communication server, and each validated destination is stored in the DCobjectdestinations table. Next, the domain communication server notifies each client side communication server destination that the DistributeObject is waiting. This is done through the use of ReceiveObject URL 212, the client-side server URL in FIG. 8b. The unique identifier for the specified Distribute Object is sent at this URL and is used by the receiving client-side communication server when requesting the object. An example of the domain communication server that notifies the client-side communication server that the Distribute Object can be used is as follows. https://validCSS.com:84/ReceiveObject?LOH=1010982029384 In response to this URL, the client-side communication server returns an HTTP status code 200 while sending a signal to the domain communication server that the notification is indicated. . After sending the notification, the client-side communication server requests a DistributeObject from the domain communication server using the specified unique match. This is accomplished by requesting the CollectObject URL 114 in FIG. 8a. An example of a client-side communication server that attempts to search for a DistributeObject from a domain communication server is as follows. http://myDomainServer.com:81/CollectObject?ID=https://validCSS.com:84&LOH=1010982029384 The response from the domain communication server is the requested DistributeObject in stream format. This stream is captured by the client-side communication server and recreated in the DistributeObject at the client communication server site. The domain communication server locally indicates the time at which the client-side communication server searched for the DistributeObject for auditing purposes. After receiving the DistributeObject, the client-side communication server determines whether further processing is necessary, and if necessary, performs the processing. 4. Modifying the Dynamic Client Registry In a preferred embodiment, as shown in FIG. 5, the dynamic client registry 06 determines when and how many resources are available in a specified domain at a specified time. used. The dynamic client registry 06 is made up of four objects: a content producer, a content consumer, an index object, and a channel. The dynamic client registry 06 is quite dynamic, registry changes are controlled by the domain communicator server and can be made at any time. This domain communication server needs to notify all client-side communication servers about the change. This notification is performed via the Refresh URL 118 in FIG. 8A. In the preferred embodiment, changes to the dynamic client registry 06 occur as a result of four different events. The first event is to register a new client-side communication server in the domain. This causes the domain communication server to notify all of the client-side communication servers that are "associated" with this new client-side communication server. This notification consists of a list of ContentProducers and ContentConsumers included in the registered client communication server. These are available for all existing client-side communication servers. It is up to the domain communication server to determine which client-side communication server recognizes which producer and consumer (based on the configured virtual pipe). In a preferred embodiment, the client-side communication server can selectively notify only those subsets that the domain communication server indicates to be available. The second event that modifies the dynamic client registry 06 is the opposite of the first event. That is, the registration of the communication server on the client side is canceled. In each event, the domain communication server notifies all relevant client communication servers of the change of the ContentProducers and ContentConsumers objects. An example of a domain communication server (particularly ContentProducers) that would notify the client-side communication server about changes in the dynamic client registry 06 would be as follows: http://ValidCSS.com:84/Refresh?URL=/Producers An example of a domain communication server (particularly ContentConsumers) that would notify the client-side communication server about changes in the dynamic client registry 06 would be as follows: http://ValidCSS.com:84/Refresh?URL=/ The third type of modification to the Consumers Dynamic Client Registry 06 is a change in the IndexObjects used in the domain. This change occurs only through status events (listed below) that are processed by the domain communication server. All active client-side communication servers are notified of changes to this type of dynamic client registry 06. An example of a domain communication server that would notify the client communication server about changes in the dynamic client registry 06 (especially IndexObjects) would be: http://validCSS.com:84/Refresh?URL=Indexes The last change type is a change in the Channels used by the domain. This change occurs only through status events (listed below) that are processed by the domain communication server. All active client-side communication servers are notified of changes to this type of dynamic client registry 06. An example of a domain communication server (particularly Channels) that would notify the client communication server about changes in the dynamic client registry 06 would be as follows: http://validCSS.com:84/Refresh?URL=Channel In response to this URL, the client communication server returns an HTTP status code 200 that informs the domain communication server. This is the code received by the client communication server. After sending this notification, the client communication server requests the URL (with the necessary parameters) specified by the domain communication server. 5. Domain Shutdown This event occurs when the domain communication server must notify all active client-side communication servers that the domain is unavailable. This notification is processed via the DomainShutdown URL 130 in FIG. 8a. An example of a domain communication server that would notify the client side communication server about a domain shutdown would be: http://validCSS.com:84/DomainShutdown In a preferred embodiment, a notification is sent to the client communication server so that the domain communication server can use the Allow the client-side communication server to queue all the content that must be replicated externally until it signals that it is possible. The client-side communication server will use an alternate domain communication server (one of the client-side communication servers) until the first domain communication server returns to the domain to avoid queuing the content. (If specified when starting the communication server). When the domain communication server returns to the domain, the client-side communication server notifies the domain communication server of the currently queued content by initiating content replication (event 3 above). Notification that the domain communication server has returned is made by the domain communication server requesting that each client-side communication server be re-registered (event 1). 5. Status In the preferred embodiment, the event is triggered in response to a partial change in the dynamic client registry 06 currently hosted by the domain communication server as host and an inquiry about the current status of the domain. , Processed by the domain communication server (ie, Channels and Index objects). These events are not available to any client-side communication server, but are only available to the domain communication server administrator. The status event indicates the current status of all client communication servers in the domain. The status of the client communication server includes the virtual pipes currently established for other client communication servers, the content producers of the client communication server (both internal and external), and Includes the client-side communication server's content consumers (including those consumed by consumers). The domain communication server is notified via these events to re-read the domain index or channel. As described above, in the preferred embodiment, the system further uses DistributedObject objects. DistributedObject is used when replicating data from one client-side communication server in a specified domain to another client-side communication server. A DistributedObject consists of four components: an origin, a target, a signature, and data to be copied (content). Both the origin and target fields are set by the client-side communication server that creates the data when targeting the data, and are evaluated by the domain communication server. The signature is used by the receiving client-side communication server to reconstruct the original type from the data and understand how to process the data. DistributedObjects are persistent. The origin and target are in IdObject format. Multiple origins and targets can be specified. In a preferred embodiment, the IdObject is used to set the origin or target of the content in the domain. The IdObject consists of a firm, workgroup, and user confirmation, and is used when both the domain communication server and the client-side communication server set the origin or target of the content. Using this object, you can use wildcard abbreviations to indicate all possible matches, and check if the specified IdObject is "equal to" another IdObject. A valid IdObject has the following format, and an example wildcard is shown below. IdObject equivalency ^*** All users FIRM of all groups in all farms. ^* . ^* FIRM.GROUP All users of a specific group in a specific farm FIRM.GROUP.USER Specific users of a specific group in a specific farm FIRM.GROUP.USER A domain field when using multiple domain communication servers Can be inserted before the farm field. In a preferred embodiment of the present invention, information on leadership analysis and similar statistics about the type of information used, copied, accessed, or referenced by the user can be maintained, if necessary. Obviously, analysis programs that track usage, traffic, response time, etc. can be implemented without departing from the spirit of the invention. In a preferred embodiment of the present invention, the system can provide, for example, a distribution summary that the user can review at the end of the day, and any information that the user has sent at the end of the day or other time periods. Further, in a preferred embodiment, the system provides a search function so that a user can search for information based on the type and / or source of the information, and publication within a production time frame, and the like. Obviously, many different search functions can be implemented without departing from the spirit of the invention. In the preferred embodiment, the producer objects (recording the farm name, group name, etc.) create a list of each producer with which the receiving consumers can communicate one-to-one. Similarly, consumer objects among other items have lists that indicate individuals who want to communicate one-on-one. The one-to-one communication function of the present invention can perform highly secure one-to-one communication of "looking into your own eyes" if necessary. Obviously, various combinations for managing this one-to-one relationship are possible and further changes may be sought. Similarly, in the preferred embodiment, comments can be tagged with one or more index values. Although the preferred embodiment of the present invention can run programs written in the C ++ programming language on a personal computer or NT or Unix operating system, it should be apparent that other programming languages and operating systems can be used. Further, while the preferred embodiment is implemented by a software program, it is apparent that some or all of the logic of the present invention can be implemented by firmware or hardware circuits. It will be appreciated that the above embodiments are illustrative only, and other systems are feasible from the teachings within the scope of the present invention.

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ０６Ｆ 15/00 ３３０Ｇ０６Ｆ 15/00 ３３０Ｄ (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者ラマチャンドラン、ラジャアメリカ合衆国 02134 マサチューセッツ州オールストンフランクリンストリート 65 (72)発明者バーンズ、トーマスエイ. アメリカ合衆国 02332 マサチューセッツ州ダックスベリサリーレーン８ (72)発明者マローン、トーマスジェイ. アメリカ合衆国 02127 マサチューセッツ州サウスボストンイーストセブンスストリート 545 (72)発明者クミーク、マイケルディ. アメリカ合衆国 02114 マサチューセッツ州ボストンウエストシーダーストリート 90 アパートメント１エム (72)発明者ドウティ、ジョセフシー. アメリカ合衆国 02131 マサチューセッツ州ウエストロックスベリグレッターストリート 34 【要約の続き】指示された関数名をロードすることにより第２コンピュータをリソース・ロケータに反応させるウェブ・サーバと、ダイナミックグループレジストリを組織化するためのデータベース管理プログラムとを有する。──────────────────────────────────────────────────続き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) G06F 15/00 330 G06F 15/00 330D (81) Designated countries EP (AT, BE, CH, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), OA (BF, BJ, CF, CG, CI, CM, GA, GN, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB GE, GH, GM, GW, HU, ID, IL, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN , MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, US, UZ, VN, YU, ZW (72) Inventor Ramachandran, Rajah United States of America 02134 Massachusetts, Allston Franklin Street 65 (72) Inventor Burns, Thomas A. United States 02332 Duxbury, Sally Lane, Mass. 8 (72) Inventor Malone Thomas Jay, United States 02127 South Boston, Mass., East Boston Seventh Street 545 (72) United States 02114 Boston West Cedar Street, Massachusetts 90 Apartment 1m (72) Inventor, Douty, Joseph Sea. United States 02131 West Rocksbury Glitter Street, Massachusetts 34 34 [Continued Summary] A web server for loading the second computer to react to the resource locator; and a database management program for organizing a dynamic group registry.

Claims

[Claims] 1. Clients on different networks for selective sharing Registry for organizing information from entities Resources to store dynamic client registries and feature names A first computer having an electronic storage medium for storing a slocator; The first computer further executes the resource when executed by the first computer. By loading the function name shown in the locator to the first computer, Server program that causes a first computer to respond to a resource locator The first computer further comprising a dynamic client registry. Having a database management program to organize the Locating by the web server program in response to an appropriate resource locator Domain communication server executed by the first computer when loaded -The program and its domain communication server program are the same domain communication server -Respond to the resource locator directed to the program, and Database management program in the client registry organization To manage A plurality of second computers having a communication relationship with the first computer; Computers store dynamic group registries and include feature names An electronic storage medium for storing the resource locator, wherein each second computer has a second When executed by a computer, the function name shown in the resource locator By loading it on a second computer, the second computer Each second computer comprising a web server program for responding to the locator Also provides database money to organize dynamic group registries. Management program, A client-side communication server program stored in each second computer; The client-side communication server program responds to the appropriate resource locator Each second computer when loaded by a web server program By Resources that are directed to the client-side communication server program. Responsive to slocators and within the dynamic group registry organization Managing the database management program to A domain communication resource location stored in the first and each second computer; List and its domain communication resource locator list in the first computer. Certain functions are selected for execution in the domain communication server To do Client-side communication resources stored in the first and second computers The locator list and its client-side communication resource locator list are To execute in the client-side communication server in the computer. Function is selected, so that selective access by each second computer is And store information in the dynamic client registry Communication between the first computer and each second computer for indexing Causes the dynamic execution of the selected predetermined function Registry with. 2. The selected predetermined function further includes a function of generating a plurality of virtual pipes. Only, the virtual pipe allows the user to A user at a second client entity on a different network, and both As if the client entity were on the same network 2. The apparatus of claim 1, wherein said apparatus allows communication to be performed. 3. The predetermined function selected may further include the client entity Claims that include the ability to register with a domain communication server program 1 device. 4. The selected function selected may further include a client entity providing domain communication support. ー 2. The method according to claim 1, further comprising: a function for recovering content information from the bar program. Equipment. 5. Clients on different networks for selective sharing Computer implemented registry for organizing information from entities The method Dynamic client register on a first computer with electronic storage Storing the resource locator containing the function name and the function name. The first computer further, when executed by the first computer, By loading the function name indicated in the resource locator to the first computer Web server that causes the first computer to respond to the resource locator A first computer further comprising a dynamic client layer. Have a database management program to organize the registry When, Responding to the appropriate resource locator by the web server program Loading a domain communication server program on a first computer, To respond to a resource locator directed to the communication server program; and The database management in the organization of the dynamic client registry A process for managing the A communication relationship is established between the first computer and a plurality of second computers. And each said second computer stores a dynamic group registry. And an electronic storage medium for storing a resource locator including a function name. The second computer, when executed by the second computer, executes a resource log. By loading the function name shown in the Web server program that lets two computers respond to a resource locator And each second computer further organizes a dynamic group registry. Providing a database management program for Execute the client-side communication server program stored in each second computer. line To the client-side communication server program To respond to a resource locator, and to Executed to manage the database management program throughout the organization And Location for execution in the domain communication server in the first computer. A domain library in the first and each second computer so that a certain function is selected. Storing a source locator list; A client-side communication resource locator in said first and second computers; The list of client-side communication resource locators in the 2 to be executed in the client-side communication server in the computer Function is selected, so that selective access by each second computer is possible. Store information in the dynamic client registry for Between the first computer and each second computer to index the information The communication causes the selected function to be executed dynamically When Method consisting of. 6. The step of selecting a predetermined function further includes a function of generating a plurality of virtual pipes. The virtual pipe, which allows the user to access one client To a second client entity on a different network User and both client entities as if they were on the same network 6. The method of claim 5, wherein the communication is allowed as if on a network. 7. The step of selecting a given function further comprises the client entity Select a function that allows you to register with the domain communication server program 7. The method of claim 6, comprising the step of: 8. The step of selecting a predetermined function further includes the step of allowing the client entity Faith Select features that allow you to recover content information from server programs 7. The method of claim 6, comprising the step of: