JP2001521717A - ダイナミック・グループ・レジストリ装置及び方法 - Google Patents

Abstract

(57)【要約】 クライアント・エンティティが作成する情報を組織化して共有するための動的グループレジストリが、クライアント内で互いにネットワークで結ばれた複数の共用コンピュータを有する。各共用コンピュータ（２０）は、動的グループレジストリ（０７）と、関数名を含むリソース・ロケータとを格納するためのディスク（０８）と、指示された関数名をロードすることにより共用コンピュータをリソース・ロケータに反応させるウェブ・サーバ（ＷＳ８）と、動的グループレジストリ（０７）を組織化するためのデータベース管理プログラム（ＤＢＭＳ８）とを有する。共用コンピュータ（２０）は、また、クライアントサイド・通信サーバ（ＣＳＳ８）を含む。クライアントサイド・通信サーバ（ＣＳＳ８）は、クライアントサイド・通信サーバに向けられたリソース・ロケータに反応し、かつ、動的クライアント・レジストリ（０７）の組織化においてデータベース管理プログラム（ＤＢＭＳ８）を管理する。また、各共用コンピュータに、クライアントサイド・通信・リソース・ロケータリストが記憶されており、このリストにより、指定された個人およびグループとクライアントとの間で情報がどのように共有されるべきかを動的グループレジストリ（０７）が示すように、クライアントサイド・通信サーバ（ＣＳＳ８）において実行される命令が選択される。

Description

【発明の詳細な説明】 ダイナミック・グループ・レジストリ装置及び方法技術分野 本発明は、概略、ネットワーキング・コンピュータ・システムの分野に関し、 特に、異なったネットワークを横切る情報の配給、再配給、アクセス・セキュリ ティ、フィルタリング、組織及び表示に対する制御を提供するためのシステムの 分野に関する。背景技術 今日、殆どの産業及び職業において、会社相互通信及び会社内通信の必要性が 急速に高まっている。殆どの会社、企業及び機関は、就業日を通して、従業員が 、内部では他の従業員と通信し、外部では、企業の顧客、売主、情報源等と通信 することができることを望んでいる。情報の本質及び当事者間の関係に依存して 、これらの通信は、或る場合には１対１のコミュニケの形態を取ることが必要で あり、他の場合には１対多数の一斉通信の形態を取ることが必要であり、多数対 多数の通信、及び多数対１の通信の形態さえ取ることが必要である。これらのカ テゴリの幾つかは、データの流れが相互作用的かつ協力的である場合には、全て の関係者にとって良好な情報を提供するかも知れず、レシピエントが、既に受領 したものにコメントし、共有し、そして創設することを可能とする。 現在のところ、このような大量の通信を容易に成就し管理することは困難であ りかつ費用が嵩み、特に、極度に敏感で、機密的であり、独占的である情報が、 内部だけではなく、これらの会社によって考慮されたビジネスパートナーに対し て外部にも選択的に通信されなければならない場合にはなおさらのことである。 金融産業、例えば、出資銀行は、その出資管理企業のすべてのクライアントに 時間的に敏感な情報を通信し、彼等にそれに関するコメントを与えるが、その間 、銀行の競争相手がその情報にアクセスすることは確実に阻止することを望むか もしれない。また、出資銀行は、その独占情報の配給を提供している同じネット ワーク上で、金融ニュース・サービスの売主からニュース供給、並びにそれを選 択した他の第三者の売主からの分析や独占リポートを受けることを望むかもしれ ない。 １０年もしくは１２年前、このような通信を扱うツールは、概して、電話、フ ァクシミリ、オーバーナイト・メイル、より最近では電子メールに制限されてい ただろう。これらのメディアの各々は、制限を有しかつ欠点がある。オーバーナ イト・メイルは費用が嵩み、或る種の情報に対しては非常にゆっくりしている。 電話は、勿論、非常に早いが、多くの電話による会話は１対１の通信に制限され 、その理由は、電話は、パートナーが同時に通信することを必要とする同期形態 の通信であるからである。これは必ずしも効率的ではない。出資会社が１対１ベ ースでクライアントに市場分析リポートを送信するためには、プロセスはゆっく りで厄介であり、或るクライアントが情報を取得してから長い間経ってから他の クライアントが情報を得るということが避けられない。 或る電話会議呼出しは、幾人かのクライアントが略同時刻に同じ情報を取得す るのを確実にし、かつ或る会議呼出しは相互作用的であり、それ故、種々のクラ イアントからのコメントが表現され得る。しかしながら，会議呼出しの人の数が 或る臨界量を超え始める場合には、その呼出しは、救い様のなく混乱し得る。他 のクライアントの声が、例えば出資会社の分析者の声と間違われ得る。いずれの 型の音声電話による情報通信においても、レシピエントは、詳細を覚えるために ノートを取るか、またはその日の後で、分析者のところに出かけて行かなければ ならない。情報がタイムリーであるだけでなく、後で参照するために精密かつ正 確に記録されることが必要である場合には、音声電話による会話はあまり適切な ものではない。 現代のファクシミリ機械は、選択されたクライアントのグループに対し、電話 線を渡って情報を一斉通信することを可能とし、また、チャートやグラフ並びに 他の画像を送信することを可能とする。これは、また、後で参照するためにクラ イアントに正確な記録を与える。しかしながら、ファクシミリ送信は、相互作用 的ではなく、従って、提供されているかもしれない何等かのクライアントのコメ ントが失われる。ファクシミリ送信のレシピエントは、通常、ハードコピーだけ を有し、受信用のファックス・モデムを使用しない場合は、情報の電子コピーは 有さない。従って、このような送信が共通のファックス機械もしくはメール室に 入って来て、個々の人に届くまでに数次間かかる場合には特に、レシピエントに 対する利用性は相当に下げられ得る。 内部共同ネットワーク間のゲートウェイを通って送られる電子メールは、しば しば遅く、普通のテキストフォーマット（通常添付として送られるビジュアル情 報を有することがある）及び固定データのようにして送られる電子メールは通常 インデキシングされていない。その結果、電子メールメッセージのストリームに 望まれる又は必要とされる情報を見つけだすことは、長い時間がかかる。受領者 は、同じコンピュータソフトウェア及びハードウェアを使用しない限り、添付し た物を使用したり又は見たりすることができない。多くの会社や施設では、内又 は外への添付物をメッセージとしてＥメールすることは秘密上の理由により許容 されないであろう。Ｅメール技術は本質的には、同じネットワーク上で同じ文書 の多くのコピーを必然的に生成する格納及び発送プロセス、即ちネットワーク資 源の非効率的な使用である。 これらの問題に遭遇によって、プラーベートに内部に分配されたコンピュータ 及び電気通信ネットワークを有する会社及び施設は、会社内通信を取り扱うため に別のアプローチをとる。キービジネスパートナーと通信するために独立し、孤 立した外部ネットワークを構築することにより、会社自身の内部ネットワークか らの選択された顧客及びベンダーの情報が得られる。会社の内部ネットワークか ら選択された情報は、特別の外部ネットワークに送られ、続いて取引パートナー に送られる。このことは、多くの文書及びファイルを外部ソースへ及びから秘密 形式で転送することができる。しかしながら、もしそのようにすることを全ての 顧客及び全てのベンダーに対して望む投資銀行のような施設がある場合、費用及 び複雑さが劇的に増大する。もし、投資銀行がある一つのタイプのコンピュータ システム及びネットワークソフトウェアをその内部及び外部ネットワーク用とし て使用し、顧客あるいはベンダーが別のタイプを使用していた場合、通信の両側 の個々について、それらシステムが共に動作し、安全性を提供するためにプログ ラムを展開するようなネットワーク管理装置を持つ必要がある。このことは、コ ンピュータ、ブリッジ(１０ベース Ｔ ケーブル及びＦＤＤＩ接続のような２ つの異なるタイプのメディアを用いて２つのネットワークを接続するネットワー ク装置)、ルータ(２つ以上のネットワークを接続し、メッセージを正しい内部プ ロトコルアドレスにルーティングする特別な目的の装置)、ソフトウェア及び端 子、更に外部へ及びからの接続を取り扱うためのソフトウェアを展開するための コストに対する資産経費を通常含むことになる。装備及び特別な展開のために極 端なコストを避けるために、会社は、送受信することができるこの種の情報と同 様にこの種のアクセスが認可された会社の数を制限する。 接続を支配することが可能な別の手段を供給するために、例えばFirst Call社 のような他の会社がネットワークと分配サービスを提供した。例えば、投資銀行 が顧客へその調査に関して伝達したい場合、First Call社が有料にてその内容を 配達し、かつその受取人にも料金を課する。この手段は、そのように分配される 情報の売り手側と買い手側の双方の部分における多大な資本支出及び開発費用の 必要性を排除する一方で、情報及びその流れにおける彼らの支配をも効果的に排 除する。例えば、顧客の目からみた場合、情報の中心源はFirst Call社であり、 銀行又は供給者ではない。First Call社が分配する情報は、そのサービスを買っ た全ての人に送られるので、プロバイダーにとっては、特定の受取人のためにあ る情報を提供する場合は実用的ではなかった。この方法の下では、双方向通信も 実用的ではなかった。 そして、インターネット−即ち、何千もの既存の法人及び組織のネットワーク が標準的な通信プロトコル又は通信シグナルを用いて通信を行うことを可能にす るリンクされたコンピュータ・ネットワークの全世界的なシステムが到来した。 World Wide Webとして知られているインターネットのこの一面は、World Wide W ebにおいて、ユーザが一つのハイパーテキスト・リンクから別のハイパーテキス ト・リンクへと移ることを可能にする目的にて、ハイパーテキスト・リンクとし て公知であるものを提供するとともにHyperText Transport Protocol(HTTP)を用 いることによってこれらの通信を更に一層簡略化した(ハイパーテキストとは、 情報を、ノードと称され、かつ、同ノードに埋め込まれたハイパーテキスト・リ ンク又はハイパーテキスト・アンカーと称されるものを備えた小さなユニットに 分けるテキストを作成及び公表するための方法である。テキストの読者がハイパ ーリンクをクリックすると、ハイパーテキストのソフトウェア（ブラウザ、又は webブラウザとしても公知である）は、そのリンクに関連したノードを表示する 。これらのノードを集めたものが"web"であり、Worldwide Webは、規模の大きな ハイパーテキストシステムである)。インターネット及びWorldwide Webによって 、ある種の情報の広範囲への普及が容易になった。しかしながら、インターネッ トのWorld Wide Webに公表された情報の大部分は、その情報へのアクセスが万人 にとって容易であるために、その性質において感受性の高いものではなく、機密 性の高いものでもないように思われる。 会社の内部ネットワークは内部ネットワークを形成する同じコンピュータにつ いて、秘密性の高い業務上のファイルを有するだけでなく、接続が内部とインタ ーネットとの間でなされた場合に、攻撃や盗難、又は濫用されやすい極秘の技術 及び製品に関するファイルをも有する。従って、大部分の会社は内部ネットワー クと、外部の世界へ通じる任意のゲートウェイとの間に「ファイヤーウォール」 を構築する(図２を参照すると、会社Ｃ１からＣ９が、各々ファイヤーウォール Ｆ１からＦ９を有する状態で示されている)。ファイヤーウォールは、ユーザが 特別にプログラムされたコンピュータシステムを、自身の内部ネットワークとイ ンターネットとの間に設ける防護技術である。この特別な「ファイヤーウォール 」コンピュータは、許可されていない者が、内部ネットワークへアクセスするの を防止する。しかしながら、ファイヤーウォールは、会社の内部コンピュータの ユーザがインターネットに直接アクセスするのも防止することができる。なぜな らば、ファイヤーウォールコンピュータによって提供されたインターネットへの アクセスは通常間接的なものであり、プロキシサーバと呼ばれるソフトウェアプ ログラムによって行われるからである。 従って、ユーザがベンダーからファイルを入手したい場合には、ユーザはＦＴ Ｐ（ファイル転送プロトコル）リクエストをファイヤーウォールコンピュータの プロキシサーバへ送信する。プロキシサーバは自身の名の下に第２のＦＴＰリク エストを作成し、ネットワークの外にあるファイルを要求するためにそれを実際 に利用する。これにより、内部の名前やアドレスは会社内にとどめておくことが 可能となる。ファイヤーウォールとプロキシサーバを使用すると、動作が幾分遅 くなることがあり、また、機密性又は専有性の低い情報については、送信又は受 信可能な情報の種類が制限されることがある。 ファイヤーウォールの使用は、内部ネットワークユーザーがインターネットか ら情報を持ち込み、該情報を内部に配信する際の危険性を軽減するものである。 しかしながら、情報が一企業のプライベートネットワーク内にひとたび持ち込ま れれば、該情報を内部に配信する問題が依然として生ずる。 最も大規模なプライベートネットワークは以下の組み合わせ、即ち、 −− ローカルエリアネットワーク（ＬＡＮ）− かなり小さな物理領域内、通 常２マイル以内に配置され、高速ケーブル又は他の接続手段により互いにリンク された一組のコンピュータと、 −− ワイドエリアネットワーク（ＷＡＮ）− データを迅速に長距離伝送し、 内部ネットワークの「バックボーン」を形成する高速長距離通信ライン又は衛星 を介して互いにリンクされたローカルエリアネットワークのグループ との組み合わせにより構築される。 上記プライベート内部ネットワークは、内部でメッセージを伝送、転送及び受 信するために、複雑なハードウェア及びソフトウェアを使用する。 「イントラネット」を構築する第一段階として、企業ネットワーク内で分配及 び配信された情報は、クライアント／サーバー技術、ウェブブラウザ、及びイン ターネットで使用されるハイパーテキスト技術を、内部基準において利用して、 より簡単に作成されてなる。典型的なクライアント／サーバー技術において、一 コンピューターは、ユーザーにとって複雑なタスクを実行するための「バックエ ンド」又はサーバーとして動作するものであり、一方、小型コンピュータ又は端 末は、ユーザーと通信する「フロントエンド」又は「クライアント」である。ク ライアント／サーバー法において、クライアントはサーバーからのデータを要求 する。ウェブサーバーは、ハイパーテキスト情報のためのサーバー機能として動 作するプログラムである。大規模プライベートネットワークにおいて、サーバー コンピュータは、社内ネットワークにおいてハイパーテキスト通信を取り扱うた めに、該コンピューター上で機能するウェブサーバーソフトウェアを有していて もよい。ウェブサーバーサイトにおいて、一又は複数の人間がハイパーテキスト 形式でドキュメントを作成し、該ドキュメントを該サーバーにおいて利用可能に することも可能である。多くの企業において、従業員は、各自の机に、内部ネッ トワークに接続されたパーソナルコンピュータを具備することになると思われる 。「イントラネット」においては、このような従業員が、各自のパーソナルコン ピュータ上でウェブブラウザを使用して、該ウェブサーバーにおいてハイパーテ キストドキュメントが利用可能なものを見るようになると思われる。 上記事項は、プライベートネットワークを介する内部通信における進展ではあ るが、同時に各人がハイパーテキストマークアップランゲージ(ＨＴＭＬ)、即ち 、「内部」ウェブページを作成及び維持するドキュメント内にハイパーテキスト リンクを形成するために使用される言語に精通することが要求される。よりイン タラクティブなアプローチが所望される場合には、ユーザーのサーバーへの情報 要求を可能にするための形式、ドキュメント及び手順を作成することのできる、 ＣＧＩ、ＰＥＲＬのようなスクリプト作成分野における情報技術（ＩＴ）専門家 が必要とされる。 また、内部において情報を分配することを必要とするアプリケーションも、IB M社のソフトウェアLotus Notes^TMのようなワーキンググループソフトウェアと して公知のものを内部ネットワーク上で使用することができる。しかしながら、 このことも、組織独自の要求に応じて特別なプログラム及びスクリプト作成技術 を要求するものである。 イントラネットをインターネットに接続して、いわゆる「エクストラネット」 を形成することが益々一般的になりつつある。しかし、インターネットは基本的 には受動的な通信システムである。顧客のイントラネットの外部にある特定のイ ンターネットウェブページ上において新たなレポートが利用可能であることが顧 客に対して自動的に通知されることはない。通常、顧客はウェブページが変わっ たか、その変化が顧客が見たいものであるかを確認するために定期的にインター ネットを検索しなければならない。料金サービスを行っているウェブページサイ トの中には見込みユーザに新しいデータが存在することを通知するためにe-メー ルを利用したものがある。上述したように、e-メールは遅いため、データが時間 感受性でもある場合、この通知がその日の遅くまで顧客に届かない場合があり、 その時点ではすでに価値が低くなっている可能性がある。 インターネットをよりインタラクティブにする試みの一つがIntermind社から 提案されている。これはハイパーテキストの一形態であり、ハイパーコミュニケ ーションと呼ばれるものである。このアプローチでは、一般的な電話機の「スピ ードダイアルボタン」に似た要領で、異なるサイトに多数のディレクトリが作ら れる。ハイパーコミュニケーションによって接続されたサイトからユーザが情報 を得たい場合、そのサイトの「スピードダイアル」ボタンを「押す」ことにより 、Intermind社製ソフトウェアによって作られたディレクトリを通じて自動的に サイトに接続される。このアプローチにより情報の発行元は、受け手が受信可能 であるかについてアンケートをとることも可能である。受け手が受信可能であり 、発行元が受け手に与えるための新たなデータを持っている場合、発行元は「ス ピードボタン」を「ダイアル」してデータを送る。これは顧客に新たな情報があ ることを通知する問題の解決を助けるものである。 しかし、こうしたディレクトリを用いた場合でも、インターネットを介して内 部で作成された情報を外部のビジネスパートナーに対して選択的に利用可能とす ることは、内部の情報の作者が個々に手動で行った場合には非効率となる。内部 の情報を同じイントラネット上の外部の情報源とコミングリングさせることも、 手動で行った場合には「スピードボタン」を用いても手間がかかり非効率である 。このアプローチでは、データの発行の制御、データの見出し付け及びオーガナ イ ズドされたプレゼンテーションのいずれも行うことができない。また、「防火壁 」や同様のアクセス防御がなく他者によるウェブサイトへのアクセスが可能であ ることによるセキュリティの問題もこのアプローチでは解決されない。 インターネット及びウェブブラウザの到来によって情報の発行者にとって利用 可能となった別の手段に、インターネットを介し、機密性の高いアクセスを与え る一接続形態がある。この接続では通常、暗号化及び機密保持ソケットを利用し 、非武装地帯すなわちDMZを介して、より限られた情報へ接続される。個々の企 業は企業のネットワーク上の内部データのプライバシーの保護を望むため、「非 武装地帯」(DMZ)を外側に備えた防火壁をネットワークの周囲に有するか、その 企業が接続したい他の企業のそれぞれに対する防火壁の一部として有する。図２ ｂに示されるように、例として企業ＡのDMZであるD１は、防火壁F１と企業Ａの インターネットへのゲートウェイG１との間となるように防火壁F１の外側に配置 することが可能である。DMZ D１内には企業Ｃとの相互の通信のために別に配さ れる領域ICが示されている。図２ｂに見られるように、他の企業との直接かつ高 い機密性を有する通信を望む各企業のDMZは、想定される通信対象者が特定され るように構成されなければならない。 顧客が２０個の異なる外部の発行元から情報を得る必要がある場合、顧客の防 火壁と発行元の防火壁との間に２０の異なる接続を行って２０個の識別子及びパ スワードを取得する必要がある場合が考えられる。これを図２に簡略化して示し た。図示を容易にする目的で、企業C１〜C３を互いに競合する投資銀行とし、企 業C５〜C９をその顧客、C4をニュースソースとして、上記のDMZ配置を利用した ネットワーク配置を大幅に簡略化して示してある。銀行C1はニュースソースC4及 び５つの顧客C５〜C９のためのDMZ D４〜D９を有する点に留意されたい。顧客C5 は、ニュースソースC4に対するの同様、顧客C5がデータを得る投資銀行のそれぞ れに対してDMZ D１〜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）社又はポイントキャスト （Pointcast）社製のもの）は、公的ソースからデータを収集し、個々のユーザ の要求に合った情報を選択すべく、それらデータに対してフィルタリング又はふ るい分け（sift）を行うが、これらのシステムは通常複製を管理することはなく 、データに対するインタラクション（interaction）を許容することもない。プ ロファイリングシステムは通常、一対多数の、インタラクションを許容しない一 方向性配信モデルである。 ブラウザが用いられているイントラネットを備えた企業及び大規模な機関にお いては、個々の情報受信者は目にするものをブックマーク管理によって組織化す ることができる。しかしながら、ブックマークは通常、非常に特殊に形成されて おり、２組のブックマークが同一であることはあり得ない。また、外部プロファ イリングシステムの場合と同様に、ブラウザ及びブックマークを用いるイントラ ネットは、通常、一方向にしか情報を送ることができない。銀行Ｃ１によって配 信された分析情報を入手した図２の企業Ｃ８は、通常、銀行Ｃ１によって、該当 するウェブページにおいてコメント及び返答を可能にする目的で、ＣＧＩスクリ プティング又はその他のプログラミング即ちスクリプティング言語を用いて、特 殊なフォームシートが作成されていない限りは、コメント及び返答を行うために ブラウザを使用することはできない。この点でも、カスタムプログラミング即ち スクリプティングはコストを上昇させるものであり、通常、企業間における標準 化を困難にさせるものである。 現在インターネットに接続されている殆どのイントラネットシステムでは、個 々のユーザは、ソース及びサブジェクトの両方に基づいて情報を要求することは できない。更に、殆どの同イントラネットシステムでは、個々のユーザが、情報 の作成者及び閲覧者の両者として機能することはできない。 図２ａに示すように、インターネット上の複数の情報消費者を、複数のＤＭＺ 及びセキュアソケットを介して外部の情報ソースに接続することは複雑で煩雑な 作業であり、情報公表者のためのセットアップ及び管理を行うためにもコストが かかる。インターネット上の情報消費者の立場から考えれば、このような配信モ デル上での送信は「インターネット速度」にて行われることに留意しなければな らない。即ち、例えば顧客Ｃ８から情報の要求が成された後、それがインターネ ット上に送られるとすれば、それはＴＣＰ−ＩＰ形式でフォーマットされたパケ ットにおいてであり、セキュアソケット技術によって記号化される可能性がある 。いずれの場合も、その情報要求が顧客Ｃ８の基幹ネットワークから外部に送ら れた後は、その送信速度はインターネット送信リンクにおける平均速度である。 この速度は、通常、顧客自身の内部ネットワーク内における送信速度よりもかな り遅い。従って、顧客の立場から考えると、企業間通信の実行速度もまた、問題 であり得る。 ＤＭＺ又はプロキシ（proxy）サーバー等の装置を用いることで、安全保障上 の問題が改善される一方で、ＤＭＺはまた、全ての企業間通信に対して障害とな るコンテントバックログ（content backlogs）を形成する傾向にある。例えば、 企業のファイヤーウォールの保護域外で同企業のＤＭＺにデータを転送すること を認可された人物のみが情報技術の専門家であるならば、大量の情報を外部に対 して選択的に送信する必要がある又はそれを所望する企業にとって、この作業は 労働上の大変な手間又は障害、若しくはその両方となる。同様に、現在の安全保 障技術によって、種々の記号化の選択肢が提供される（その結果、企業間におけ る標準化の問題を引き起こしている）が、個人識別（identification）等の問題 は各企業の情報技術（ＩＴ）部門の管理に委ねられている。ＩＴ専門家は、企業 のＤＭＺ内の情報（認証情報(authentication)）にアクセスすることを認可され た外部の全個人に対して、ユーザ識別子及びパスワードを与えなければならない 。現在これは、通常、各企業及び個人における手動参照文字（manual letters o f reference）又は手動データ入力によって成されている。 前述のように、文書がＨＴＭＬを用いて作成されなければならない場合、又は データを適切なフォーマットに適合するために、特殊なＣＧＩ（コモンゲートウ ェイインターフェイス(common gateway interface)）スクリプトを作成し維持す る必要がある場合は、これらの事情の全てによって、ポリシー及びコンテント管 理の問題が、情報の作成者及び閲覧者ではなくＩＴ部門の専門家の手に預けられ る傾向が作り出される。企業内のＩＴ専門家は、新規のユーザ及び個人の追加、 転送され得るデータ型の登録、スクリプト、プログラム、ネットワーク及びシス テム全体に対する変更及び更新の実施及び維持等の要請に圧倒されている。 本発明の目的は、情報の複製及び公表の管理が許容されるような態様で、貴重 な情報を選択的に転送することを可能にする汎用ドメインルーティング及び公表 制御システムを提供することにある。 本発明の別の目的は、異なる型におけるユーザ又はネットワーク間にて、選択 的に情報を配信することが可能なシステムを提供することにある。 本発明の更に別の目的は、ユーザが、受信した情報についてコメントしたり、 その情報に対してインタラクト（interact）することを許容するシステムを提供 することにある。 本発明の更に別の目的は、ユーザ及び情報提供者によるソフトウェア開発の必 要性を最小化する、又は解消することにある。 本発明の更に別の目的は、特殊な管理手順及び特殊な訓練を受けた人員によっ てシステムを管理する必要性を軽減することにある。 本発明の更に別の目的は、殆どの場合、ユーザの内部ネットワークにおける速 度で、ユーザが情報にアクセスできるように許容するシステムを提供することに ある。 本発明の更に別の目的は、サブジェクト又はソース、若しくはその組み合わせ による情報の標準化及び組織化を容易にするダイナミック配信ネットワークリソ ースレジストリ（dynamic distributed network resource registries）を提供 することにある。発明の開示 これら及び他の目的は、クライアント・エンティティが作成する情報を組織化 して共有するための動的グループ・レジストリによって達成される。該レジスト リは、クライアントの内側で一緒にネットワーク化された複数個のパブリケーシ ョン・コンピュータを有する。各パブリケーション・コンピュータは、動的グル ープ・レジストリ、及び機能名を含むリソース・ロケータを記憶するためのディ スクと、指示された機能名をロードすることによりパブリケーション・コンピュ ータをリソース・ロケータに反応させるウェブ・サーバと、動的グループ・レジ ストリを組織化するためのデータベース管理プログラムとを有する。パブリケー ション・コンピュータは、また、クライアント・サイド・通信サーバを含む。ク ライアント・サイド・通信サーバは、クライアント・サイド・通信サーバに向け られたリソース・ロケータに反応し、かつ、動的グループ・レジストリを組織す る際にデータベース管理プログラムを管理する。また、各パブリケーション・コ ンピュータに、クライアント・サイド・通信・リソース・ロケータ・リストが記 憶されており、このリストにより、指定された個人及びグループの中で情報がク ライアント・エンティティとどのように共有されるべきかを動的グループ・レジ ストリが示すように、クライアント・サイド・通信サーバにおいて実行される機 能が選択される。 本発明の一態様は、或る会社が、いかなる場所においてもDMZの使用を必要と することなく、その私用のネットワークの外側で他の企業と確実に通信を行うこ とを可能とすることである。 本発明の一態様は、動的に形成可能な相対配置ドメイン・ルーティング及びパ ブリケーション制御システムを提供することである。 本発明のもう１つの態様は、ユーザが、ネットワーク上への情報の配給及び再 配給のためにかれら独自のポリシーを限定して実行することを可能とすることで ある。 本発明のさらにもう１つの態様は、ユーザによりさらにソフトウエアを開発す る必要を無くすことである。 本発明のさらにもう１つの態様は、システムを管理するために追加の熟練した 情報技術職員を必要とせず、代わりにユーザが彼等自身でそれを管理することを 可能とすることである。 本発明のもう１つの態様は、私用ネットワークにおけるユーザが、殆どの時間 において私用ネットワークの速度でネットワークの外側から情報を受け取ること を可能とすることである。 本発明のもう１つの態様は、種々のクライアントへの選択的な配給を生成する ための簡単な方法を、情報公布者に与えることである。図面の簡単な説明 図１は、本発明の概略図であり、ドメイン・通信サーバと、幾つかのクライア ントサイド・通信サーバを示す。 図１ａは、本発明の別の概略図であり、ドメイン・通信サーバと幾つかのクラ イアントサイド・通信サーバとの事実上の連結を示す。 図２ａは、先行技術を用いたインターネット上で外部と通信するプライベート ネットワークの概略図である。 図２ｂは、先行技術を用いたインターネット上で外部と通信するプライベート ネットワークの概略図である。 図３は、本発明の概略図であり、互いに連絡する幾つかのドメインを示す。 図４は、本発明の方法及び装置に従うクライアントサイド・通信サーバの概略 図である。 図５は、本発明の方法及び装置に従うドメイン・通信サーバと幾つかのクライ アントサイド・通信サーバとの相互連結を示す概略図である。 図６ａは、本発明の方法及び装置に従うドメイン・通信サーバにおける例示的 な動的クライアント・レジストリのブロック線図である。 図６ｂは、本発明のドメイン・通信サーバにおける動的クライアント・レジス トリのフィールドを示す詳細なブロック線図である。 図７ａは、本発明の方法及び装置に従うクライアントサイド・通信サーバにお ける例示的な動的グループレジストリのブロック線図である。 図７ｂは、本発明のクライアントサイド・通信サーバにおける動的グループレ ジストリのフィールドを示す詳細なブロック線図である。 図８ａは、本発明の好ましい実施形態において用いられる、主要なドメイン・ 通信サーバの全域資源位置指示子（ＵＲＬ）のリストである。 図８ｂは、本発明の好ましい実施形態において用いられる、主要なクライアン トサイド・通信サーバのＵＲＬのリストである。 図９は、本発明の方法及び装置に従う例示的なドメイン・クライアントリスト の詳細な配置図である。 図１０は、本発明の例示的なクライアント・ソースリストの詳細な配置図であ る。 図１１は、本発明の例示的なクライアント・オブジェクトリストの詳細な配置 図である。 図１２は、本発明の例示的なオブジェクト宛先リストの詳細な配置図である。 図１３は、本発明の方法及び装置に従う例示的なインデックスの詳細な配置図 である。 図１４は、本発明の方法及び装置に従うクライアントサイド・通信サーバにお ける起動手続きのフローチャートである。 図１５は、本発明の方法及び装置に従うクライアントサイド・通信サーバによ る共有オブジェクトの初期化のフローチャートである。 図１６は、本発明の方法及び装置に従うクライアントサイド・通信サーバによ る共有オブジェクトの初期化のさらに詳細なフローチャートである。 図１７は、本発明の方法及び装置に従うクライアントサイド・通信サーバの管 理者サーバによる共有オブジェクトの初期化を示すフローチャートである。 図１８は、本発明の方法及び装置に従うクライアントサイド・通信サーバのツ ールサーバによる共有オブジェクトの初期化を示すフローチャートである。 図１９は、本発明の方法及び装置に従うクライアントサイド・通信サーバのエ ージェントサーバによる共有オブジェクトの初期化を示すフローチャートである 。 図２０ａは、本発明の方法及び装置に従うドメイン・通信サーバによる動的ク ライアント・レジストリの初期化を示すフローチャートである。 図２０ｂは、本発明の方法及び装置に従うクライアントサイド・通信サーバに よるグループの作成を示すフローチャートである。 図２１は、本発明の方法及び装置に従うクライアントサイド・通信サーバの初 期化を示すフローチャートである。 図２２は、本発明の方法及び装置に従う、ユーザを追加するためのデスクトッ プターミナルの例示的な利用者画面表示のブロック線図である。 図２３は、本発明の方法及び装置に従う、新しいユーザの会計情報を入力する ための例示的な利用者画面表示のブロック線図である。 図２４は、本発明の方法及び装置に従う、新しいユーザのための内容作成を認 可するための例示的な利用者画面表示のブロック線図である。 図２５ａは、本発明の方法及び装置に従う、内容種別を選択するための例示的 な利用者画面表示のブロック線図である。 図２５ｂは、本発明の方法及び装置に従う、内容種別を選択するための例示的 な利用者画面表示のブロック線図である。 図２５ｃは、本発明の方法及び装置に従う、ユーザが分配オプションを選択す るための例示的な利用者画面表示のブロック線図である。 図２６ａは、概して本発明の方法及び装置に従う、再分配権を認可するための 例示的な利用者画面表示のブロック線図である。 図２６ｂは、特に本発明の方法及び装置に従う、再分配権を認可するための例 示的な利用者画面表示のブロック線図である。 図２６ｃは、本発明の方法及び装置に従う、グループアクセスを割り当てるた めの例示的な利用者画面表示のブロック線図である。 図２６ｄは、本発明の方法及び装置に従う、ユーザに内部でのグループアクセ スを割り当てるための例示的な利用者画面表示のブロック線図である。 図２６ｅは、本発明の方法及び装置に従う、ユーザに外部へのグループアクセ スを割り当てるための例示的な利用者画面表示のブロック線図である。 図２７は、ドメイン・クライアント・テーブルの作成を示すＳＱＬ書式の疑似 コードである。 図２８は、クライアント・ソーステーブルの作成を示すＳＱＬ書式の疑似コー ドである。 図２９は、クライアント・オブジェクト・テーブルの作成を示すＳＱＬ書式の 疑似コードである。 図３０は、オブジェクト宛先テーブルの作成を示すＳＱＬ書式の疑似コードで ある。 図３１は、索引テーブルの作成を示すＳＱＬ書式の疑似コードである。 図３１ｂは、チャネル内容テーブルの作成を示すＳＱＬ書式の疑似コードであ る。 図３１ｃは、チャネルテンプレートテーブルの作成を示すＳＱＬ書式の疑似コ ードである。 図３２ａは、ワークグループテーブル７０の作成を示すＳＱＬ書式の疑似コー ドである。 図３２ｂは、ワークグループ内容テーブルの作成を示すＳＱＬ書式の疑似コー ドである。 図３３は、ワークグループのベース内容テーブルの作成を示すＳＱＬ書式の疑 似コードである。 図３４は、ワークグループのマスタリスト・テーブルの作成を示すＳＱＬ書式 の疑似コードである。 図３５は、ワークグループの特別内容テーブルの作成を示すＳＱＬ書式の疑似 コードである。 図３６は、ワークグループの著者メンバーテーブルの作成を示すＳＱＬ書式の 疑似コードである。 図３７は、ワークグループのビューメンバーテーブルの作成を示すＳＱＬ書式 の疑似コードである。 図３８は、アドレスブックテーブルの作成を示すＳＱＬ書式の疑似コードであ る。 図３９は、著作権テーブルの作成を示すＳＱＬ書式の疑似コードである。 図４０は、ビューアテーブルの作成を示すＳＱＬ書式の疑似コードである。 図４１は、ワークグループ内容リストの属性テーブルの作成を示すＳＱＬ書式 の疑似コードである。 図４２は、ワークグループ内容リストの基準テーブルの作成を示すＳＱＬ書式 の疑似コードである。 図４３は、クライアントサーバの管理メッセージテーブルの作成を示すＳＱＬ 書式の疑似コードである。 図４４は、クライアントサーバの内容テーブルの作成を示すＳＱＬ書式の疑似 コードである。 図４５は、クライアントサーバの内容ベーステーブルの作成を示すＳＱＬ書式 の疑似コードである。 図４６は、クライアントサーバの特別な内容テーブルの作成を示すＳＱＬ書式 の疑似コードである。 図４７は、クライアントサーバの分配待ち行列テーブルの作成を示すＳＱＬ書 式の疑似コードである。 図４７ａは、クライアントサーバの複製待ち行列テーブルの作成を示すＳＱＬ 書式の疑似コードである。 図４７ｂは、クライアントサーバの複製宛先待ち行列テーブルの作成を示すＳ ＱＬ書式の疑似コードである。本発明を実施するための最良の形態 図１に、本発明における好適な一実施形態を概略ブロック図にて示す。ドメイ ン通信サーバーＡ１は、複数のクライアント側通信サーバーＣ１〜Ｃ９とコミュ ニケートしている。これらクライアント側通信サーバーは、それぞれ、好適な一 実施形態における各企業サイトにてファイヤーウォールＦの保護下に配置されて いる。即ち、企業Ｃ−１はクライアント側通信サーバーＣ１を備えていると共に 、企業Ｃ−２はクライアント側通信サーバーＣ２を備え、以下企業Ｃ−９まで同 様にクライアント側通信サーバーを備えているものと想定する。複数の一時論理 接続（Temporary logical connections）又は「パイプ」Ｐは、このドメインに おける各クライアント側通信サーバーとドメイン通信サーバーＡ１との間に形成 されている。好適な一実施形態において、パイプＰは、従来のTCP-IPネットワー キングプロトコルと、暗号化テクノロジーを伴うネットスケープコーポレーショ ン（Netscape Corporation）の複数のセキュアソケット（secure sockets）とを 用いて、インターネット上で形成される接続である。しかしながら、当該技術分 野の従事者には明らかであるように、その他のネットワーク、プロトコル、及び 暗号化技術を用いることも可能である。 同じく図１において、それぞれのクライアント側通信サーバーＣは、ドメイン 通信サーバーＡ１との実際の接続パイプＰを１つしか備えていないことが示され ている。しかしながら、それぞれのクライアントによるドメイン通信サーバーＡ １への登録様式に応じて、クライアント側通信サーバーＣ１から、その他のクラ イアント側通信サーバーＣ２〜Ｃ９のいずれか又は全てに対して、情報を配信す ることが可能である。このように、本発明は、企業Ｃ−１〜Ｃ−９からなるコミ ュニティを、ドメイン通信サーバーＡ１によってネットワーク上でリンクするイ ンテリジェントエクストラネットを提供する。 本発明によって提供されるエクストラネットは、それぞれの会員クライアント Ｃが、Ｃにとって外部である（Ｃとコミュニケートすることを認可した）企業又 は機関と、相手の企業がクライアント自身の内部ネットワーク又はイントラネッ トの一部を成しているかの如くコミュニケートすることを可能にする。この点に おいて、本発明は、企業イントラネットの仮想コミュニティを提供する。 企業のコミュニティが金融産業であるより具体的な例を用いると、Ｃ１，Ｃ２ 及びＣ３が３つの異なる投資銀行のクライアント側通信サーバー、Ｃ５〜Ｃ９ま でが投資管理会社のクライアント側通信サーバー、Ｃ４がニュース放送機関のク ライアント側通信サーバーである場合、クライアント側通信サーバーＣ１におけ る投資銀行は、ドメインサーバーＡ１のみと直接コミュニケートすることによっ て、ドメイン通信サーバーＡ１とコミュニケートしている他のクライアントのい ずれに対してでも、情報を送信することができる。即ち、クライアント側通信サ ーバーＣ１における銀行Ｃ−１は、必要であれば、顧客Ｃ−５〜Ｃ−９における クライアント側通信サーバーＣ−５〜Ｃ−９のみに対して、自社の午前の分析報 告を配信することが可能であり、ニュース放送機関Ｃ−４は、ドメイン通信サー バーＡ１とコミュニケートしているその他全てのクライアントに対して、自社の 情報を伝送することができる。このように、本発明における好適な一実施形態は また、同コミュニティに参加している企業又は団体のための関係情報マネジャー としても機能する。従って、本発明によって、投資銀行Ｃ−１の顧客は、安全保 障された接続を通じて、委託アドヴァイザーからタイミング良く貴重な情報を受 け取ることができる。 図１ａには、実施可能なコミュニケーションの型のいくつかを示す。 この例では、異なる４つのクライアントＣ１〜Ｃ４が示されている。クライアン トＣ１は、唯一クライアント側通信サーバーＣ１−ＰＡを本発明の方法及び装置 における「スマートイントラネット」として機能させている、在米国ペンシルヴ ァニア州の投資銀行である。クライアント側通信サーバーＣ１−ＰＡは、同銀行 の内部ローカルエリアネットワーク（Local Area Network）Ｃ１−Ｌａｎに接続 されており、Ｃ１−Ｌａｎはまた、２つのターミナルＴ１及びＴ２を備えている 。 当該技術分野の従事者には明らかであるように、ターミナルＴは、コンピュー タ、ミニコンピュータ、ワークステーション、パーソナルコンピュータ、キーボ ード付きＣＲＴターミナル、インターネット機能付きテレビジョンターミナル、 キーボード又はタッチスクリーン及びディスプレイ装置、パーソナルディジタル アシスタンス、又はユーザがネットワークとコミュニケートして表示された情報 を見ることを許容する任意の装置等、あらゆる型のネットワークに接続可能な装 置であり得る。好適な一実施形態では、ネットワークに接続可能なパーソナルコ ンピュータが、同パソコンにて実行される標準的なウェブブラウザソフトウェア と共に用いられている。 好適な一実施形態では、「スマートイントラネット」という用語は、本発明に よって、或る企業の内部ネットワーク、即ち同企業の「イントラネット」が、そ の企業内部において、及び同企業にとって外部である参加企業に対して、一対一 、グループ対グループ、及びサイト対サイトにおいて情報管理（情報の作成、ア クセス及び複製）を実施することが可能になる態様を表している。 同じく図１ａにおいて、クライアントＣ２は、香港、ニューヨーク及びロンド ンにオフィスをもつ投資銀行Ｃ２であり、内部ネットワークを形成すべくその全 オフィスが銀行の広域ネットワークＣ２ＷＡＮを介して相互に接続されている。 同銀行のネットワーク全体が、ファイヤーウォールＦ２によって、外部からの侵 入に対して保護されている。同投資銀行Ｃ２の香港、ニューヨーク及びロンドン におけるサイトは、それぞれ独自のローカルエリアネットワーク、即ち、香港に おけるＣ２−ＨＫＬａｎ、ニューヨークにおけるＣ２−ＮＹＬａｎ、ロンドンに おけるＣ２−ＬＮＬａｎを、各ローカルエリアネットワークに接続された標準的 な市販のウェブブラウザを用いるターミナルＴと共に備えている。 図１ａに示すように、クライアントＣ２の各サイトは、そのサイトにおけるロ ーカルエリアネットワークに接続されると共に、クライアントＣ２の広域ネット ワークＣ２ＷＡＮに接続されて、本発明の方法及び装置によるクライアントＣ２ のスマートイントラネットを形成するクライアント側通信サーバー(Ｃ２−ＨＫ ，Ｃ２−ＮＹ，Ｃ２−ＬＮ)を備えている。 同様に、クライアントＣ４は、Ｃ４のスマートイントラネットを形成すべく、 ファイヤーウォールの保護下で広域ネットワークによって相互に接続された複数 のサイトを有しており、クライアントＣ３は、Ｃ３のスマートイントラネットと して、ドメイン通信サーバーＡ１とコミュニケートされた在ボストンの単一のサ イトを備えている。 同じく図１ａに、クライアントＣ２におけるスマートイントラネットのコミュ ニケーションの論理即ち仮想フローを、クライアントＣ２内の各ＬＡＮを接続す る複数の「パイプ」Ｐ２を表す点線によって示す。本明細書では、パイプという 用語は、必ずしもハードウェアによって実現される物理的な接続ではなく、ソフ トウェアによって管理される論理接続を意味すべく用いられる。当該技術分野の 従事者には明らかであるように、或るクライアント内における複数のローカルエ リアネットワークが、内部ネットワークを形成すべく広域ネットワーク上で相互 に接続されるには、多数の方式が存在する。 本発明の好適な一実施形態においては、図１ａに示すように、これらの論理内 部接続パイプＰ２はクライアントＣ２の外部にも存在し、ドメイン通信サーバー Ａ１まで延びると共に、同サーバーＡ１を介してクライアントＣ１及びＣ３に接 続されているが、クライアントＣ４には接続されていない。即ち、本発明の好適 な一実施形態では、クライアントＣ２等のクライアントは、認可された外部のサ イトと、それらのサイトがクライアントＣ２の内部又はＣ２のスマートイントラ ネットの一部であるかのように、又はＣ２が外部サイトにとっての内部又はそれ らのスマートイントラネットの一部であるかのように、（本発明を介して）論理 的にコミュニケートすることが可能である。しかしながら、クライアントＣ２は ドメイン通信サーバーＡ１を除き、これら外部サイトのいずれとも物理的接続を 行うことはないため、クライアントＣ２はファイヤーウォールＦ２によって得ら れる保護機能を失うことは一切ない。好適な一実施形態では、クライアントＣ２ とドメイン通信サーバーＡ１との間における全ての物理的な伝送は、ネットスケ ープコーポレーションのセキュアソケットレイヤー（ＳＳＬ）の技術及び暗号化 を用いてインターネット上にて行われる。 更に図１ａには、各クライアントＣは、レジェンド（legend）００に示される ように、Ｐ１〜Ｐ６までの独自の「パイプ」Ｐを備えている。例えば、クライア ントＣ２における３つのサイトは、「パイプ」Ｐ２上で相互に内部コミュニケー トしている。本発明の好適な一実施形態において、クライアントＣ２はまた、パ イプＰ２上でクライアントＣ１，Ｃ３及びＣ５ともコミュニケートしているよう に見えるが、実際には、クライアントＣ２は、Ｃ２をドメイン通信サーバーＡ１ に接続する実際のパイプを１つしか備えていない。当該技術分野の従事者には明 らかであるように、クライアントＣ２のネットワークとドメイン通信サーバーＡ １との間における唯一の同パイプは、必要であれば、Ｔ１又はＴ３の高速ライン を用いて、物理的な直接接続として実施することも可能である。本発明によって 、クライアントＣ２は、一連の「仮想パイプ」ＶＰ２上で、ドメイン通信サーバ ーＡ１を介して、クライアントＣ１，Ｃ３及びＣ５と外部コミュニケートするこ とができる。仮想パイプという用語は、本明細書では、それぞれのクライアン トが、実際には、ドメイン通信サーバーのみと物理的にコミュニケートしており 、かつその他のクライアント又は会社とは単に「仮想」的にコミュニケートして いるに過ぎない際に、２つ（又はそれ以上）のクライアントがインターネット（ 又はその他のネットワーク）上で直接的にコミュニケートする場合と同様に、コ ミュニケーションが成立することを指している。仮想パイプは、各サイトにおけ るクライアント側通信サーバーと協働する本発明のドメイン通信サーバーの論理 （logic）によって、動的に（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"）で あることが解る。更に、インデックス６１、即ち教育は、新規発行債券の下位項 目である。一好適態様において、インデックスは必要なだけの多くのレベル（階 層）を有することが可能である。 更に図６ａに言及すると、一好適態様においては、チャネルコンテントテーブ ル６３及びチャネルテンプレート６５も作成される。本発明の一好適態様におい て、チャネルは各種インデックスの組み合わせである。例えば、一チャネルは、 最新情報項目を含むような全インデックスからなるものであってもよい。別な一 チャネルは、最も頻繁に使用されるインデックスで構成されてもよい。当該分野 の技能を有する者にとっては自明なことと思われるが、上記チャネルグループ分 けの数及びコンテントは、産業間、あるいは経時と共に変化しうるものである。 図面から分かるように、チャネルテーブル６１は、ドメインコンテントを関連カ テゴリーへ体系化するために使用される。上記チャネルは次いで、スタートアッ プ時にクライアントサイドコミュニケーションサーバーへ送られ、セットアップ 動作中及びグループ管理の間中使用される。他の好適一態様において、この機能 を前記クライアントサイドコミュニケーションサーバー又は内部用ドメインコミ ュニケーションサーバーを利用するクライアントサイドコミュニケーションサー バー内に包含することが可能である。 ここで図６ｂに言及すると、チャネルテーブル６１は、チャネルＩＤフィール ド６１ａ、チャネルネームフィールド６１ｂ、及びチャネルデスクリプションフ ィールド６１ｃを含んでいる。最新情報項目に関して、チャネル名「ホットニュ ースアイテム」、「新規発行債権、抵当及びリサーチインデックスからの最新情 報」のようなチャネルデスクリプションと共に、チャネルＩＤ１が割り当てられ てもよい。当該分野の技能を有する者にとっては自明なことと思われるが、ドメ インが自動車製造業等の他産業セグメントにある場合は、該インデックス及びチ ャネルは、異なるトピック及びトピックの組み合わせを表示するものである。一 好適態様において、チャネルコンテントテーブル６３は、チャネルを構成するコ ンテントを決定するために使用される。再び図６ｂにおいて、チャネルコンテン トテーブル６３は、チャネルＩＤフィールド６３ａ、チャネルＩＤフィールドと 共に独自の鍵を形成するチャネルコンテントＩＤ６３ｂ、コンテントが基本コン テントであるか特別コンテントあるいは他の種類のコンテント（以下に記載）で あるかを表示するチャネルタイプフィールド６３ｃ、及び当該チャネル用コンテ ントに係る一又は複数のソースを表示するチャネルコンテントソースフィールド ６３ｄを含んでいる。一好適態様において、チャネルテンプレートテーブル６５ は、チャネルコンテントを体系化するために使用される。各テンプレートは、チ ャネルテンプレートＩＤフィールド６５ａ、チャネルテンプレートＩＤフィール ド６５ａと共に独自の鍵を形成するチャネルテンプレートフィールド６５ｂ、コ ンテントリストの属性を規定するチャネルテンプレート属性フィールド６５ｃ、 及びチャネルコンテントテーブル６３内にあるＩＤを説明するチャネルテンプレ ートソースフィールド６５ｄを含んでいる。 ここで第７ａ図を参照すると、本発明の動的グループレジストリ０７の構造と 内容がの例示されている。好ましい実施例では、動的グループレジストリ０７は 各クライアントにおいて、該クライアントで内部的に作成された全てのコンテン トおよび該クライアントによって受信されたドメイン内で作成されたコンテント を取り扱うために使用される。上記のように、各クライアント側通信サーバは、 他のファームのクライアント側通信サーバと通信するために、ドメイン通信サー バを使用しなければならない。 第７図に示すように、クライアント側動的グループレジストリ０７の主エント リはグループテーブル７０である。グループテーブル７０は特定のファームまた はクライアント内で設定された全グループのリストである。注意されたいのは、 ワークグループという用語は図中または本テキスト内に現れるが、 グループという用語が一般に好ましく、これと交換可能に解釈可能である。グル ープは、該グループで使用できるコンテント（コンテントテーブル９０および特 定コンテントテーブル９４に指定される）のタイプとソースとを形成するために 使用され、情報が受信されるたびに、該グループに関するそれぞれのコンテント リストを作成する。ＣＳコンテントテーブル９０は、オブジェクトＩＤ９０ａ、 オーサＩＤ９０ｂ、コンテントリンクオブジェクトＩＤ９０ｃ、コンテントヘッ ドライン９０ｄ、コンテントファイル名９０ｆ、コンテント情報９０ｇ、コンテ ントタイムスタンプ９０ｈ、コンテントオリジンサイト９０ｉ、コンテントオリ ジンオブジェクト９０ｊおよびコンテントデータ属性９０ｋによりコンテントを 形成する。コンテント作成時に、このコンテントは該特定タイプのコンテントを 要求した全グループに自動的に付加される。特定コンテントテーブル９４は該情 報のソースにより特定コンテントを形成し、またはパブリッシャが該特定コンテ ントをあるグループに指定したときに該グループに付加される。 第７図のテーブル７０から明らかなように、好ましい実施例では、共有と限定 の２個のタイプのグループがある。共有グループはクライアントまたはファーム 内の全閲覧者からアクセスできるが、ベースコンテントのみをとり得る。限定グ ループは、ワークグループ閲覧メンバテーブル８２に指定されたグループのメン バのみが閲覧できる。限定グループはベースコンテント、特定コンテントおよび 以降に開発されると考えられる他のタイプのコンテントに対して許されている。 特定コンテントは、該グループのオーサおよびパブリッシャ（ワークグループオ ーサメンバテーブル８０およびワークグループ閲覧メンバテーブル８２）のみに よって該グループに付加され得る。 さらに第７ａ図のグループテーブル７０において、好ましい実施例では、全グ ループはフィールドＷＧコミュニティで示されるコミュニティを有し、この中で は「既知」である。該コミュニティはファームまたはクライアント内の他のグル ープに「アドバタイズ」するために使用される。該コミュニティは、該ドメイン の内部（ファームまたはクライアントに対してのみ）または該ドメインの外部に アドバタイズされたコンテントの作成者を含む。内部グループは該ファームまた はクライアントの外部では知られていない。外部グループは該ファームまたはク ライアントの内部で知られている。ワークグループが、好ましい実施例において 、グループテーブル７０のＷＧコミュニティフィールドに値「２」を使って作成 者としてセットされれば、該グループは他のグループに対する特定コンテントの ソースとしてアドバタイズされる。 さらに第７ａ図において、好ましい実施例では、該ファームまたはクライアン トの内部のみのグループは、グループテーブル７０のＷＧコミュニティフィール ドに「０」を使ってそのことが示されている。グループテーブル７０に示される ように、ファームワイドグループであるワークグループＷＧ１は、この特定な例 にリストされたただ１個の内部グループである。外部グループは、グループテー ブル７０のＷＧコミュニティフィールドに値「０」を使って示されている。ＷＧ コミュニティフィールドに値をセットするために、好ましい実施例はそれらの値 の排他的論理和をとって全ての選択肢を決定する。好ましい実施例では、ＷＧグ ループＩＤはファームＩＤ、サイトＩＤおよびある番号から成るので常に一意的 である。当業者には自明であろうが、一意的なグループＩＤまたはＷＧグループ ＩＤの作成には多くの方法が使用できる。 さらに第７ａ図において、ワークグループベースコンテントテーブル７４は、 あるベースコンテントが内部的にまたは外部的に作成されたときに、各ワークグ ループが受信を望むベースコンテントを決定するために使用される。ベースコン テントはコンテントタイプ（ＷＧＢＣインデックスＩＤ）によって選択され、共 有と限定の両ワークグループによって受信される。特定コンテントタイプが受信 されると、該ワークグループのコンテントリストヘッドラインが更新される。 ワークマスタリストテーブル７６は該リストに関する記述テキスト情報を提供 する。 再び第７ａ図において、ワークグループ特定コンテントテーブル７８は、各あ るベースコンテントが内部的にまたは外部的に作成されたときに、ワークグルー プが受信を望むベースコンテントを決定するために使用される。特定コンテント は該コンテントのインデックスでなくソースによって決定される。該特定コンテ ントのソースは、上記のように、既に自身を「アドバタイズ」したグループであ る。ミックスコンテントは特定コンテントとベースコンテントの組み合わせであ る。 また第７ａ図において、ワークグループオーサメンバテーブル８０は、オーサ とこれらのオーサがそれぞれのグループに特定コンテントを付加するのを許すこ とを指定したグループとから成るリストを含む。オーサはファームまたはクライ アント内のオーサのリストから選択される。グループもファームまたはクライア ント内のグループのリストから選択される。このテーブルへのエントリは新しい コンテントの作成者であることを指定したグループにのみ存在する。ここに示す ワークグループオーサメンバテーブル８０の例では、ワークグループオーサ識別 子ＷＧＡＭａｕｔｈｏｒＩＤがある。このフィールドは、以下に示す閲覧者テー ブルのＶｉｅｗｅｒＩＤにリンクされる。ワークグループオーサ識別子ＷＧＡＭ ａｕｔｈｏｒＩＤは該メンバが属するこのクライアント内の一意的なグループを 識別する。この値は、グループテーブル７０のＷＧｇｒｏｕｐＩＤにリンクされ る。 第７ａ図に示す例では、同一のオーサ、ｔｂｕｒｎｓはワークグループ２ＷＧ ２とワークグループＷＧ３とのメンバとしてリストされている。フィールドワー クグループオーサメンバリストリクトＭＧＡＭｒｅｓｔｒｉｃｔは、好ましい実 施例では、オーサが本ワークグループの内容を使用する各ワークグループに送信 を個別に「許可」されていると考えられる場合に、真にセットされるブール値で ある。この値が偽にセットされていれば、オーサは本ワークグループの内容を使 用するいずれのワークグループにも送信できる。 さらに第７ａ図において、ワークグループ閲覧メンバテーブル８２は全ワーク グループの閲覧者のリストを含む。あるワークグループの閲覧者メンバだけがワ ークグループのコンテントを閲覧するためにアクセスできる。あるワークグルー プの全閲覧者はファームまたはクライアントの有効な閲覧者のリストから選択さ れる。ワークグループのアドミニストレータ（ＷＧＶａｄｍｉｎフィールドに指 定される）は該グループに関するメンバと任意のメンバの属性とを決定すること が許されている。グループのコンテントの配布は閲覧者属性フィールドＷＧＶＭ ａｔｔｒｉｂｕｔｅによって制御される。ここで示す例では、ワークグループ２ ＷＧ２の閲覧者、ｔｍａｌｏｎｅとｔｂｕｒｎｓはワークグループ２ＷＧ２に対 するアドミニストレータである。好ましい実施例では、閲覧者属性フィールドＷ ＧＶＭａｔｔｒｉｂｕｔｅにセット可能な値はが５個である。すなわち、 Ｄｉｓｔｒｉｂｕｔｅ Ｎｏｎｅ（配布なし） Ｄｉｓｔｒｉｂｕｔｅ Ｉｎｔｅｒｎａｌ（内部配布） Ｄｉｓｔｒｉｂｕｔｅ Ｅｘｔｅｒｎａｌ（外部配布） Ｄｉｓｔｒｉｂｕｔｅ Ｉｎｔｅｒｎａｌ Ｒｅｓｔｒｉｃｔｅｄ（制限付き内部 配布） Ｄｉｓｔｒｉｂｕｔｅ Ｅｘｔｅｒｎａｌ Ｒｅｓｔｒｉｃｔｅｄ（制限付き外部 配布） 好ましい実施例では、全選択肢を決定するために、これらの値も排他的論理和 をとられる。当業者には自明であるが、あるメンバの属性を示す方法として、他 の各種方法が使用できる。 再び第７ａ図において、住所録テーブル８４は、住所録グループ識別子ＡＢｇ ｒｏｕｐＩＤのメンバとして、あるオーサまたはパブリッシャがコンテントの配 布を許されているグループのリストを含む。言い換えれば、ＡＢｇｒｏｕｐＩＤ は、指示されたオーサまたはパブリッシャにワークグループのコンテントの配布 を許可したワークグループの一意的なＩＤである。この値はグループテーブル７ ０のＧｒｏｕｐＩＤにリンクされる。住所録送り先フィールドＡＢｄｅｓｔｉｎ ａｔｉｏｎは、該オーサまたはパブリッシャがコンテントを配布できるグループ のファームＩＤとワークグループＩＤとを含む。好ましい実施例では、住所録テ ーブル８４の住所録属性フィールドＡＢａｔｔｒｉｂｕｔｅは、ワークグループ がこのオーサまたはパブリッシャにノート（注意事項）を該コンテントに付加す ることを許す場合には真にセットされ、許さない場合には偽にセットされるブー ル値である。 さらに第７ａ図において、オーサ権利テーブル８８は、あるオーサが作成可能 なコンテントのタイプを決定するのに使用される。このテーブルは３個のフィー ルドを含む。すなわち、オーサ識別子ＡｕｔｈｏｒＩＤ、オーサインデックス識 別子ＡｕｔｈｏｒＩｎｄｅｘＩＤ、オーサ属性ＡｕｔｈｏｒＡｔｔｒｉｂｕｔｅ である。好ましい実施例では、オーサが作成できるコンテントタイプ(オーサ属 性フィールドに指定される)はファームまたはクライアントによって決定される 。これによりクライアントは自身の内部的方針を、他者が設定した方針の受け入 れもしくは特定な外部システムの制限の受け入れを余儀なくされることなく、上 記のような事態に対して定義し実施できる。全てのオーサは該ファームまたはク ライアントの有効な閲覧者でなくてはならない。 好ましい実施例では、各オーサは指定されたコンテントについて内部ブロード キャストに関して最小限のオーサ属性を持つ。好ましい実施例において、可能な 値は以下のとうりである。 Ｉｎｔｅｒｎａｌ Ｂｒｏａｄｃａｓｔ（内部ブロードキャスト） ０ Ｉｎｔｅｒｎａｌ Ｓｅｌｅｃｔｉｖｅ（内部セレクティブ）１ Ｅｘｔｅｒｎａｌ Ｂｒｏａｄｃａｓｔ（外部ブロードキャスト） ２ Ｅｘｔｅｒｎａｌ Ｓｅｌｅｃｔｉｖｅ（外部セレクティブ）４ これらの値は、好ましい実施例では、全選択肢を決定するために排他的論理和 をとられる。当業者には自明であるが、このような値の定義および実施について は、他の方法の使用も可能である。 図７ａにおいて、ビゥーアーテーブル８６は、許可されたクライアントまたは 企業における正当なユーザーまたはビゥーアー全員のリストを含む。このテーブ ルは、特定のユーザーまたはビゥーアーがクライアントのイントラネットのメン バーであるか決定するのに使用され、ユーザーまたはビゥーアーがこのテーブル に載っていればクライアントのイントラネットが許可されアクセスするのに使用 される。このテーブルに加えられたユーザーまたはビゥーアーは、グループテー ブル７０のＷＧ会員フィールドに明記されるように、共通のクライアントまたは 企業のワークグループすべてに対してアクセスが許可される。 図８ａを参照すると、ドメイン通信サーバーの話に戻るが、主なドメイン通信 サーバーＵＲＬのリストが示されている。前記のように，好適な実施例において 、ドメイン通信サーバーはＡＯＬサーバーソフトウェアを用いて実行される。仮 想サーバーを作成する際、共用オブジェクトを動的にロードできるからである。 本発明の好適な実施例においては、オブジェクト指向プログラミング技術が用い られるが、プログラムが実際に実行されるまで正確なタイプがわからないオブジ ェクトに対するプロシージャを作成できるからである。また、オブジェクト指向 技術によれば、システム実行者は共用オブジェクト、例えば、ひとつ以上のファ ンクションまたはプログラムで呼び出されるコンパイルされたＣ++コードを定義 し使用することができる。例えば、ＡＯＬサーバーにおいて、どの共用オブジェ クトをロードするかは、ＡＯＬサーバーのＮＳＤプロセスの開始時に使用される 初期化ファイルによって特定される。本発明の好適な実施例において、‘domain server.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:/Register?ID=CSS"で あり、ここで、Domain Serverはプロトコル、リクエストを行う側のマシンネー ム（およびポート）であり、ID変数はCSS'sプロトコル、マシンネーム（または ポート）である。この方法ではプロトコルが指定されているので、ドメインが標 準HTTPまたはSSLレイヤのどちらを使用するかはトリビアルである。別の好まし い実施例では、本発明はX.500Lightweight Directory Access Protocol(LDAP)を 実現する。 レジストレーションを試みるクライアントサイド通信サーバの１例は次のよう なものである。 https://myDomainServe.com:81/Register?ID=https://validCSS. com:84 次に、ドメイン通信サーバは、DClient Objects（スタートアップの時点でロ ードしている）の内部コレクションをチェックすることにより、IDによって指定 されたロケーションがこのドメインの有効なロケーションであることを証明する 。リクエストの妥当性が検査されると、ドメイン通信サーバは、ClientSource O bjectsのリストをパッシングすることにより、ダイナミッククライアントレジス トリ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 URL106によっ てリクエストされる。Index Objectsは、与えられたドメイン内にサブジェクト ・マター別のコンテンツを編成するために使用され、また、ダイナミッククライ アントレジストリ06内のドメイン通信サーバによって集中的にホストされる。In dex Objectsは、クライアントサイド通信サーバによって、そのダイナミックグ ループレジストリ07の１部として使用される。 第8a図のIndexes URL106への応答が、ドメイン通信サーバにそのIndex Ob jectsの収集を繰り返させ、これらをストリーム形式に戻させる。ストリーム形 式は、クライアントサイド通信サーバサイトにおいてIndex Objectsに翻訳し直 され、局所的に収集される。 インデックスをリクエストするクライアントサイド通信サーバの１例は次 のとおりである。 https://myDomainServercom:81/Indexes?ID=https://validCSS.com:84 第8a図のInternalServers URL126をリクエストすることによって、InternalServ er Objectsが収集される。同一の企業のものと思われ、そのためクライアントサ イド通信サーバの責任がそれらの間で反復するその他全てのクライアントサイド 通信サーバのサイトを決定する上で、InternalServer Objectsがクライアントサ イド通信サーバによって使用される。 InternalServers URL126への応答によって、ドメイン通信サーバが妥当性 が確認されたDomainClientに、VirtualServer Objectsの収集を繰り返し、これ をストリーム形式で返すよう要求する。このストリーム形式は、クライアントサ イド通信サーバサイトにおいてInternalServer Objectsに翻訳し直され、局所的 に収集される。同一企業のクライアントサイド通信サーバのみが返される(これ にはクライアントサイド通信サーバのリクエストも含まれる)。 内部サーバをリクエストするCSSの１例は次のとおりである。 https://myDomainServer.com:81/InternalServers=https://validCSS.c om:84 ContentProducer Objectのリストが第8a図のProducers URL110から検索される。 ContentProducersは、adhoc and mixed contentの使用可能なソースとしてのダ イナミックグループレジストリ07の１部としてクライアントサイド通信サーバに よって使用される。ContentProducer Objectsは、プロデューサについての情報 と、それが作成するものついての情報を含んでいる。既に確立されている仮想パ イプのリストを調べることで、リクエストをしているクライアントサイド通信サ ーバにどのContentProducersが使用可能であるかを決定することはドメイン通信 サーバの責任である。 第8a図のProducers URL110への応答によって、ドメイン通信サーバが、ド メイン内のその他全てのクライアントサイド通信サーバから、リクエストしてい るクライアントサイド通信サーバで使用可能なContentProducersをストリーム形 式において返させる。複数の内部サーバのサイトについて、ストリームは内部プ ロデューサも含んでいる。このストリーム形式は、クライアントサイド通信サー バにおいてContentProducer Objectに翻訳し直され、局所的に収集される。 ContentProducersをリクエストするクライアントサイド通信サーバの１例 は次のとおりである。 https://myDomainServer.com:81/Producers?ID=https://validCSS.com:84 第8a図のConsumers URL108を介して、ContentConsumer Objectsのリストがリク エストされる。そのプロデュースグループのどれがコンテンツをリクエストする コンシューマを有するかを決定するために、ContentConsumersが「ドメインレジ ストリ」の１部としてクライアントサイド通信サーバによって使用される。 第8a図のConsumers URL108への応答によって、ドメイン通信サーバが、ド メイン内のその他全てのクライアントサイド通信サーバから、リクエストしてい るクライアントサイド通信サーバで使用可能なContentConsumersをストリーム形 式において返させる。複数の内部サーバのサイトについて、ストリームは内部コ ンシューミンググループも含んでいる。このストリーム形式は、クライアントサ イド通信サーバサイトにいおてContentConsumer Objectsに翻訳 し直され、局所的に収集される。 ContentConsumersをリクエストするクライアントサイド通信サーバの１例 は次のとおりである。 https://myDomainServer.com:81/Consumer?ID=http://validCSS.com:84 ClientInfoChannel Objectsのリストが、第8a図のChannels URL128を介して収集 される。ClientInfoChannel Objectsは、クライアントサイド通信サーバにおい て、新規グループを作成するためのテンプレートとして使用される。InfoChanne l Objectが、クライアントサイド通信サーバサイトにいおてグループの作成を容 易にするための、事前に構成されたビュー内にドメインのコンテンツの部分を構 成する。 第8a図のChannels URL128への応答によって、ドメイン通信サーバが、リ クエストしているクライアントサイド通信サーバで使用可能なInfochannelオブ ジェクトをストリーム形式返させる。このストリーム形式は、クライアントサイ ド通信サーバサイトにおいてClientInfoChannel Objectsに翻訳し直され、局所 的に収集される。 Channelsをリクエストしているクライアントサイド通信サーバの１例は次 のとおりである。 https://myDomainServer.com:81/Channels?ID=https://validCSS.com:84 Logo Objectsのリストが第8a図のFirmLogo URL116を介して収集される。Logo Ob jectsは、コンテンツをさらに「目立たせる」ために使用される。レジスタリン グクライアントサイド通信サーバが、現在「カレント」Logo Objectを持ってい ないあらゆるLogo Objectsをリクエストする。第8a図のRegister URL102から受 信したClientSource ObjectsのリストからLogo Objectの状態が決定される。 第8a図のFirmLogo URL116への応答によって、ドメイン通信サーバが、指 定されたクライアントサイド通信サーバの関連するLogoObjectをファイル形式に おいて返す。このオブジェクトはローカルファイルシステム上に記憶され、この ソースに起因するコンテンツを見る際にはいつでもこのオブジェクトが供給され る。 LogoObjectsをリクエストしているクライアントサイド通信サーバの１例 は次のとおりである。 https://myDomainServer.com.81/FirmLogo?ID=https://validCSS.com:84& SRC=https//myCSS2.com.85 クライアントサイド通信サーバのレジストレーションは、（レジスタリン グクライアントサイド通信サーバへの仮想パイプを有する）その他全てのクライ アントサイド通信サーバに対して、ダイナミッククライアントレジストリ06内で 、クライアントが関心を持つかもしれない変更が生じたことを通知するためにド メイン通信サーバをトリガする。これは、各々の対応するクライアントサイド通 信サーバにおいて、全てのRegistry Change事象を生じさせる。この変更には、 レジスタリングクライアントサイド通信サーバ内で見つかった追加コンシュ ーマとプロデューサの両方の可用性が含まれる。この通知は、各クライアントサ イド通信サーバにおいて/Refresh URLをリクエストすることによって、また、/P roducersと/Consumersの両方が変更され、クライアントサイド通信サーバの都合 でリフレッシュされるべきであると説明することによって行われる(詳細な説明 については、以下に示す「レジストリの変更」を参照のこと)。 好ましい実施例において、レジストレーションは常にクライアントサイド 通信サーバによって開始される。しかし、やはり好ましい実施例において、ドメ イン通信サーバは、任意のクライアントサイド通信サーバに、ドメイン通信サー バが適切であると判断すればいつでも再登録を行うように要求することができる 。 クライアントサイド通信サーバ登録抹消 クライアントサイド通信サーバの登録抹消は、クライアントサイド通信サ ーバがドメイン通信サーバに、ドメインにとってこれ以上使用可能でないことを 通知する必要がある場合に行われる。この事象は、クライアントサイド通信サー バによって制御され、いつでも発生可能であり、しかし好ましい実施例において は、クライアントサイド通信サーバが通常のシャットダウンを試みた際に必ず起 こる。クライアントサイド通信サーバは、第8a図のUnregister URL104を介して 登録抹消を希望することをドメイン通信サーバに通知する。このURLのフォーマ ットはDomainserver:/Unregister?ID=CSS"であり、ここで、DomainServerはプロ トコル、リクエストをする側のマシンネーム（およびポート）であり、ID Varia bleはクライアントサイド通信サーバのプロトコル、マシンネーム（およびポー ト）である。 登録抹消を試みるCSSの１例は次のとおりである。 https://myDomainServer.com:81/Deregister?ID=https://validCSS.com:8 4 次に、ドメイン通信サーバは、IDによって指定されたロケーションがこの ドメインにとって有効なロケーションであることを、DClient Objects（スター トアップでロードされている）のその内部収集を調べることにより確認する。リ クエストの妥当性が検査されると、ドメイン通信サーバがHTTP状態コード200を 返し、ドメインによって登録が抹消されたとみなされたとクライアントサイド通 信サーバに知らせる。このクライアントサイド通信サーバに宛てられた全てのコ ンテンツが、クライアントサイド通信サーバがドメインに再び使用可能になるま で、待ち行列に入れられる。 好ましい実施例において、クライアントサイド通信サーバの登録抹消もド メイン通信サーバによって開始される。これは、クライアントサイド通信サーバ からの最後の交信から指定した時間（通常は５分間）が経過した際に、クライア ントサイド通信サーバが、ドメイン通信サーバによってリクエストされた/Ping URLに応答しない場合に起こる。当業者には明確であるように、このインターバ ルには短い時間または長い時間を指定することができる。また同様に、好ましい 実施例ではこのアプローチを使用し、この理由で登録抹消されたクライアントサ イド通信サーバのためにメッセージを待ち行列に入れるが、無応答のクライアン トサイド通信サーバのためにメッセージを保留させるのに別の技術の使用も可能 であることが当業者には明らかであろう。 好ましい実施例では、クライアントサイド通信サーバの登録抹消によって 、レジスタリングクライアントサイド通信サーバへの仮想パイプを有するその他 全てのクライアントサイド通信サーバに対して、ドメインレジストリ内でクラ イアントが関心を持つかもしれない変更が生じたことを通知するためにドメイン 通信サーバがトリガされる。この変更には、クライアントサイド通信サーバの登 録抹消における追加コンシューマおよびプロデューサの両方の無効性が含まれる 。通知は各クライアントサイド通信サイトにおいて/Refresh URLをリクエストす ることにより、また、/Producerstと/Consumersの両方が変更されており、クラ イアントサイド通信サーバの都合でリフレッシュされるべきであることを通知す ることで実行される。 3． コンテンツリプリケーション この事象は、ドメイン内のあるクライアントサイド通信サーバから別の クライアントサイド通信サーバへコンテンツを送る必要がある際には常に発生す る。好ましい実施例においてドメイン通信サーバは、異なる企業のクライアント サイド通信サーバ間のコンテンツリプリケーション（外部リプリケーション）の みに責任があることに言及すべきである。同じ企業のクライアントサイド通信サ ーバ間のコンテンツリプリケーション（内部リプリケーション）は、２つ（また はそれ以上）のクライアントサイド通信サーバ間で直接行われる。 好ましい実施例では、ドメイン全体にかけてリプリケートできる３つのタ イプのコンテンツ、すなわちベースコンテンツ、Adhocコンテンツ、混合コンテ ンツを設けている。（好ましい実施例ではさらに、System Contentとして知られ る４番目のタイプのコンテンツを設けているが、このタイプはリプリケートされ ない。）コンテンツのタイプは、そのコンテンツがどのように構成されているか によって決定される。ベースコンテンツは、トピックまたはサブジェクト・マタ ーによって構成されたコンテンツである。サブジェクト・マターは、１つ以上の ドメインのIndex Objects内で定義されなければならない。コンテンツの起点（ すなわち、作成された場所）は関係ない。ベースコンテンツは、１つ以 上の関連するインデックスを備えることができる。これに対してAdhocコンテン ツは、サブジェクト・マターではなく、その起点によって構成されているコンテ ンツである。起点は、ドメイン内の与えられたクライアントサイド通信サーバに おける１つ以上の「プロデューシング」グループでなくてはならない。混合コン テンツは、adhocコンテンツとベースコンテンツの両方を組み合わせたものであ る。混合コンテンツは、起点と、これに関連するサブジェクト・マターを有する 。 好ましい実施例において、混合コンテンツは２つの個別のタイプ、アンカ ップラブルとデカップラブルであってよい。アンカップラブルな混合コンテンツ は、ベースとadhoc部分に分けることはできずに全体として扱わなければならな いのに対し、デカップラブルの方はサブコンポーネントに分けることができ、こ れらを個別に扱うことが可能である。コンテンツのタイプは、コンテンツ作成の 時間においてクライアントサイド通信サーバを生成することによって決定する。 コンテンツのリプリケーションのタイプは２つの適切なモード、ブロード キャストまたはセレクティブ・ディストリビューションであることができ、クラ イアントサイド通信サーバサイトにおけるプロデューシング・インディビジュア ルに許可された、使用可能な宛先に基づいて、クライアントサイド通信サーバに よって制御される。ブロードキャスティングコンテンツは、（ベース）コンテン ツを、最初のクライアントサイド通信サーバが仮想パイプを確立したドメイン内 のその他全てのクライアントサイド通信サーバへ分配する効果を備えている。セ レクティブ・ディストリビューションは、ドメイン全体ではなく、（adhocおよ び/または混合コンテンツ）のみを指定されたクライアントサイド通信サーバに リプリケートする。好ましい実施例において、指定されたリプリケーションのタ イプが、リプリケーとされるコンテンツのタイプを言及する。つまり、ベースコ ンテンツのみがブロードキャストされることができ、Adhocコンテンツと混 合コンテンツのみが選択的に分配されることができる。 コンテンツの流れは、ドメイン全体にかけてコンテントを収集および分配 するための、第8a図のDistributeObject URL112と第8a図のCollect Object URL1 14によって制御される。クライアントサイド通信サーバのみがこのタイプについ て理解していればよく(処理するために)、コンテンツはDistributedObject内に エンカプセルされているため、コンテントのタイプはリプリケーションプロセス とは関係ない。DistributedObjectは起点、ターゲット、データ、シグネチャの ４つの部分から成っている。起点とターゲットは、誰がオブジェクトを受信でき るかを決定するためにドメイン通信サーバによって使用され、シグネチャとデー タ部分は、処理のためにオブジェクトを復元するために、クライアントサイド通 信サーバによって使用される。 好ましい実施例において、リプリケーションは、コンテントを外部に分配 するように事前に決定されているクライアントサイド通信サーバによって開始さ れる。好ましい実施例では、クライアントサイド通信サーバはDistributedObjec tを局所的に記憶し、また、クライアントサイド通信サーバサイトでDistributed Objectが伝搬されるべく待機しているとドメイン通信サーバに通知する。クライ アントサイド通信サーバは、オブジェクトを収集する際にドメイン通信サーバが 使用すべきDistributedObjectに独特の識別子を指定する。クライアントサイド 通信サーバは、第8a図のDistributeObject URL112を介してこれを行う。 ObjectをDistributeするようにドメイン通信サーバに通知を試みるクライ アントサイド通信サーバの１例は次のとおりである。 https://myDomainServer.com:81/DistributeObject?ID=https://ValidC S S.com:84& OID=3043.201e 第8a図のDistributeObject URL112に応答して、ドメイン通信サーバは、 その通知が届けられた旨の信号をクライアントサイド通信サーバに送りながら、 HTTP状態コード200を返す。通知の送信の後、ドメイン通信サーバは、事前に指 定されている独特の一致を使って、オリジナルのクライアントサイド通信サーバ からDistributeObjectをリクエストする。これは、第8a図のCollectobject URL1 14をリクエストすることで達成される。 クライアントサイド通信サーバからDistributed Objectを収集するドメイ ン通信サーバの１例は次のとおりである。 https://validCSS.com:84/CollectObject?OID=3043.201e クライアントサイド通信サーバからの応答は、ストリーム形式のDistribu teObjectである。このストリームはドメイン通信サーバによって捕獲され、ドメ イン通信サーバサイトでDistributeObject内に再度作成される。クライアント再 度通信サーバは、ドメイン通信サーバが監査目的でDistributeObjectを検索した 時間を局所的に表記する。DistributeObjectを検索した後、ドメイン通信サーバ はソースと、指定された使用可能なターゲットのリストとを決定する。ドメイン 通信サーバはそのターゲットを、起点のクライアントサイド通信サーバが仮想パ イプを確立したその宛先と共にマップする。次にDistributeObjectは、第6a図に 示すように、ドメイン通信サーバによってDCOBJECTSテーブル62内に記憶され、 妥当性を検査された各宛先が、DCobjectdestinationsテーブル内に記憶される。 次にドメイン通信サーバが、DistributeObjectが待機している旨を各クライアン トサイド通信サーバ宛先に通知する。これは、第8b図の ReceiveObject URL212、クライアントサイドサーバURLの使用を介して行われる 。指定したDistributeObjectのための独特の識別子がこのURLにおいて送信され 、受信したクライアントサイド通信サーバによって、オブジェクトをリクエスト する際に使用される。 Distribute Objectが使用可能である旨をクライアントサイド通信サーバ に通知するドメイン通信サーバの１例は次のとおりである。 https://validCSS.com:84/ReceiveObject?LOH=1010982029384 このURLに応答して、クライアントサイド通信サーバはドメイン通信サー バに、通知が表記された旨の信号を送りながら、HTTP状態コード200を返す。通 知を送信した後、クライアントサイド通信サーバは、指定された独特の一致を使 って、ドメイン通信サーバからDistributeObjectをリクエストする。これは、第 8a図のCollectObject URL114をリクエストすることで達成される。 ドメイン通信サーバからのDistributeObjectの検索を試みるクライアント サイド通信サーバの１例は次のとおりである。 http://myDomainServer.com:81/CollectObject?ID=https://validCSS.com :84&LOH=1010982029384 ドメイン通信サーバからの応答は、ストリーム形式におけるリクエストし たDistributeObjectである。このストリームはクライアントサイド通信サーバに よって捕獲され、クライアント通信サーバサイトでDistributeObject内に再度作 成される。ドメイン通信サーバは、クライアントサイド通信サーバが監査目的で DistributeObjectを検索した時間を局所的に表記する。DistributeObject を受信した後、クライアントサイド通信サーバは、これ以上の処理が必要である かを決定し、必要である場合には処理を行う。 4． ダイナミック・クライエント・レジストリの変更 好適な実施例では、図５に示すように、ダイナミック・クライエント・レジス トリ06は、指定時点の指定ドメイン内においてどのリソースをいくつ使用可能か を調べる場合に使用される。ダイナミック・クライエント・レジストリ06は、４ つのオブジェクト、つまりコンテント・プロデューサ、コンテント・コンシュー マ、インデックス・オブジェクト、及びチャネルから成っている。ダイナミック ・クライエント・レジストリ06は全く動的であり、レジストリの変更は、ドメイ ン・コミュニケータ・サーバによって制御され、そして任意の時間に行える。こ のドメイン・コミュニケーション・サーバーは、全てのクライエント側コミュニ ケーション・サーバに対して変更について通知する必要がある。この通知は、図 8aのRefresh URL118を介して行われる。 好適な実施例では、ダイナミック・クライエント・レジストリ06の変更は、４ つの異なるイベントの結果として発生する。最初のイベントは、新しいクライエ ント側コミュニケーション・サーバをドメイン内に登録することである。これに よって、ドメイン・コミュニケーション・サーバは、この新しいクライエント側 コミュニケーション・サーバに「関連する」クライエント側コミュニケーション・ サーバのすべてに通知する。この通知は、登録したクライエント側コミュニケー ション・サーバが含むContentProducers及びContentConsumersのリストから成っ ている。これらは、全ての既存クライエント側コミュニケーション・サーバで使 用可能である。どのようなクライエント側コミュニケーション・サーバがどのよ うなプロデューサとコンシューマ(設定したバーチャル・パイプに基づく)を認識 するかは、ドメイン・コミュニケーション・サーバで決める必要がある。好適な 実施例では、クライエント側コミュニケーション・サーバは、選択 的にドメイン・コミュニケーション・サーバが使用可能と通知するサブセットに のみ通知できる。 ダイナミック・クライエント・レジストリ06を変更する２番目のイベントは、 最初のイベントの反対である。つまり、クライエント側コミュニケーション・サ ーバの登録を解除する。いずれのイベントにおいてもドメイン・コミュニケーシ ョン・サーバは、ContentProducers及びContentConsumersオブジェクトの変更に ついて、関連する全てのクライエント側コミュニケーション・サーバに通知する 。 ダイナミック・クライエント・レジストリ06の変更についてクライエント側コ ミュニケーション・サーバに通知するドメイン・コミュニケーション・サーバの 例は、(特にContentProducers)は、以下のようになるはずである。 http://VaidCSS.com:84/Refresh?URL=/Producer ダイナミック・クライエント・レジストリ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 URL13 0を介して処理される。 ドメイン・シャットダウンについてクライエント側コミュニケーション・サー バに通知するドメイン・コミュニケーション・サーバの例は、以下のようになる はずである。 http://validCSS.com:84/DomainShutdown 好適な実施例では、通知をクライエント側コミュニケーション・サーバに送信 して、ドメイン・コミュニケーション・サーバがクライエント側コミュニケーシ ョン・サーバに対して、ドメインが再度使用可能である旨を通知するまで、クラ イエント側コミュニケーション・サーバが外部的に複製しなければならない全て のコンテントの列を作れるようにする。クライエント側コミュニケーション・サ ーバは、最初のドメイン・コミュニケーション・サーバがコンテントの列を作る のを避けるためにドメインに戻るまで、代替のドメイン・コミュニケーション・ サーバ(1つのドメイン・コミュニケーション・サーバがクライエント側コミュニ ケーション・サーバを開始する場合に指定されている場合)を使用できる。ドメ イン・コミュニケーション・サーバがドメインに戻ると、クライエント側コミュ ニケーション・サーバは、コンテントの複製を開始することによって現在列を作 っているコンテントについてドメイン・コミュニケーション・サーバに通知す る(上記のイベント3)。ドメイン・コミュニケーション・サーバが戻った旨の通 知は、各クライエント側コミュニケーション・サーバを再登録することを要求す るドメイン・コミュニケーション・サーバによって行われる(イベント1)。 5． ステータス 好適な実施例では、イベントは、ドメイン・コミュニケーション・サーバが現 在中心的にホストとして機能させているダイナミック・クライエント・レジスト リ06の部分変更とドメインのカレント・ステータスについての問い合わせに応じ て、ドメイン・コミュニケーション・サーバが処理する(つまり、Channels及びI ndexオブジェクト)。これらのイベントは、いずれのクライエント側コミュニケ ーション・サーバも使用できないが、ドメイン・コミュニケーション・サーバの アドミニストレータだけが使用できる。ステータス・イベントは、ドメイン内の 全てのクライエント側コミュニケーション・サーバのカレント・ステータスを表 示する。クライエント側コミュニケーション・サーバのステータスには、他のク ライエント側コミュニケーション・サーバに対して現在確立しているバーチャル ・パイプ、クライエント側コミュニケーション・サーバのコンテント・プロデュ ーサ(内部及び外部の両方)、及びクライエント側コミュニケーション・サーバの コンテント・コンシューマ(コンシューマが消費しているものも含む)を含む。ド メイン・コミュニケーション・サーバは、これらのイベントを介してドメインの インデックス又はチャネルを再度読み込むように通知される。 上述のように、好適な実施例では、さらに本システムはDistributedObjectオ ブジェクトを使用する。DistributedObjectは、指定ドメイン内の１つのクライ エント側コミュニケーション・サーバから他のクライエント側コミュニケーショ ン・サーバにデータを複製する場合に使用される。DistributedObjectは、オリ ジン、ターゲット、シグネチャ、及び複製されるデータ(コンテント)の４つの コンポーネントから成っている。オリジン及びターゲットの両フィールドは、デ ータのターゲットを設定する時に、データを作成するクライエント側コミュニケ ーション・サーバによって設定され、ドメイン・コミュニケーション・サーバに よって評価される。シグネチャは、そのデータから元のタイプを再構築し、そし てデータの処理方法を理解するために、受信するクライエント側コミュニケーシ ョン・サーバが使用する。DistributedObjectは永続的である。オリジン及びタ ーゲットはIdObject形式である。複数のオリジン及びターゲットを指定できる。 好適な実施例では、IdObjectは、ドメイン内のコンテントのオリジン又はター ゲットを設定する場合に使用される。IdObjectは、ファーム、ワークグループ、 及びユーザ確認から成っており、ドメイン・コミュニケーション・サーバ及びク ライエント側コミュニケーション・サーバの両方がコンテントのオリジン又はタ ーゲットを設定する場合に使用する。このオブジェクトを使用すると、起りうる 全ての合致を示すためにワイルド・カードの省略形を使用でき、指定したIdObje ctが他のIdObjectに「等しい」かどうかを調べることができる。有効なIdObjectは 、以下の形式であり、ワイルド・カード例を以下に示す。 IdObject 同値^*** 全てのファーム内にある全グループの全ユーザ FIRM.^*.^* 特定ファームでの全グループの全ユーザ FIRM.GROUP 特定ファームでの特定グループの全ユーザ FIRM.GROUP.USER 特定ファームでの特定グループの特定ユーザ 複数のドメイン・コミュニケーション・サーバを使用する場合、ドメイン・フ ィールドは、ファーム・フィールドの前に挿入できることは明らかである。 本発明の好適な実施例では、必要であれば、ユーザによる使用、複製、アクセ ス、又は参照された情報のタイプについてのリーダーシップ分析及び類似統計の 情報を保持できる。本発明の精神から逸脱することなく、使用、通信量、応答時 間などを追跡する分析プログラムも実現できることは明らかである。 本発明の好適な実施例では、本システムは、例えば、ユーザが１日の終わりに 精査できる分布概要、及びユーザがその日又は他の時間帯の終わりに送った全て の情報を提供できる。 さらに、好適な実施例では、本システムは検索機能を提供するので、ユーザは 情報のタイプ又はソース、成はそれらの両方、及び作成日、タイム・フレーム内 での出版などに基づく情報を検索できる。本発明の精神から逸脱することなく、 多くの異なった検索機能を実現できることは明らかである。 好適な実施例では、プロデューサ・オブジェクト(ファーム名、グループ名な どを記録する)は、受信するコンシューマが１対１で通信できる各プロデューサ のリストを作成する。同様に、他のアイテム間のコンシューマ・オブジェクトに は、１対１で通信したい個人を示すリストがある。本発明の１対１通信機能は、 必要であれば、「あなただけの目を見つめて」の１対１での高度な機密通信を行え る。この１対１の関係を管理する各種の組合せが可能であり、さらに変化を求め 得ることは明らかである。 同様に、好適な実施例では、コメントには１つ以上にインデックス値の付いた タグを付けることができる。 本発明の好適な実施例は、C++プログラミング言語で書いたプログラムをパー ソナル・コンピュータ、或はNT又はUnixオペレーティング・システムで稼働でき るが、他のプログラミング言語及びオペレーティング・システムも使用でき ることは明らかである。さらに、好適な実施例はソフトウェア・プログラムによ って実現しているが、本発明のある部分又は全てのロジックをファームウェア又 はハードウェア回路で実現できることも明らかである。 上記の実施例が例証に過ぎないことを十分に認識し、そして本発明の範囲での 教示から他のシステムも実現可能である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，Ｍ Ｗ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，Ｅ Ｓ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ， ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，Ｍ Ｇ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ， ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，Ｖ Ｎ，ＹＵ，ＺＷ (72)発明者 ラマチャンドラン、ラジャ アメリカ合衆国 02134 マサチューセッ ツ州 オールストン フランクリン スト リート 65 (72)発明者 バーンズ、トーマス エイ. アメリカ合衆国 02332 マサチューセッ ツ州 ダックスベリ サリー レーン ８ (72)発明者 マローン、トーマス ジェイ. アメリカ合衆国 02127 マサチューセッ ツ州 サウス ボストン イースト セブ ンス ストリート 545 (72)発明者 クミーク、マイケル ディ. アメリカ合衆国 02114 マサチューセッ ツ州 ボストン ウエスト シーダー ス トリート 90 アパートメント １エム (72)発明者 ドウティ、ジョセフ シー. アメリカ合衆国 02131 マサチューセッ ツ州 ウエスト ロックスベリ グレッタ ー ストリート 34 【要約の続き】 個人およびグループとクライアントとの間で情報がどの ように共有されるべきかを動的グループレジストリ（０ ７）が示すように、クライアントサイド・通信サーバ （ＣＳＳ８）において実行される命令が選択される。

Claims (1)

1. 【特許請求の範囲】 １． クライアント・エンティティが作成する情報を組織化して共有するための 動的グループレジストリであって、 クライアント・エンティティの内側で互いに通信関係にある複数個のパブリケ ーション・コンピュータを備え、パブリケーション・コンピュータの各々は、動 的グループ・レジストリを記憶しかつ機能名を含むリソース・ロケータを記憶す るための電子記憶媒体を有し、各パブリケーション・コンピュータはさらにウェ ブ・サーバを含み、該ウェブ・サーバは、パブリケーション・コンピュータによ って実行されるときに、リソース・ロケータによって示された機能名をパブリケ ーション・コンピュータにロードすることによって、パブリケーション・コンピ ュータがリソース・ロケータに応答するようにし、各パブリケーション・コンピ ュータはさらに、動的グループ・レジストリを組織するためのデータベース管理 プログラムを含んでおり、 各パブリケーション・コンピュータに記憶されるクライアント・サイド通信サ ーバ・プログラムを備え、該プログラムは、適切なリソース・ロケータに応答す るウェブ・サーバ・プログラムによってロードされるとき各パブリケーション・ コンピュータによって実行されると共に、クライアント・サイド通信サーバ・プ ログラムに向けられたリソース・ロケータにさらに応答し、そして動的グループ ・レジストリを組織する際にデータベース管理プログラムに向かい、 各パブリケーション・コンピュータに記憶されたクライアント・サイド通信リ ソース・ロケータ・リストを備え、該リストは、各パブリケーション・コンピュ ータ内のクライアント・サイド通信サーバで実行するよう所定の機能が選択され るようにし、これにより、指定された個人及びグループの中で情報がいかにクラ イアント・エンティティと共用されるべきかを動的グループ・レジストリが示す ようにした動的グループ・レジストリ。 ２． 所定の機能は、さらに、内容の生成器及び生成される内容に関する情報を 含む内容生成器機能を備える請求項１に記載の装置。 ３． 所定の機能は、さらに、内容の消費者を識別する内容消費者機能を備える 請求項１に記載の装置。 ４． 所定の機能は、さらに、グループ及びそのメンバーを識別するグループ機 能を備える請求項１に記載の装置。 ５． 所定の機能は、さらに、グループのメンバーがいずれの種類のアクセスを 有するかを識別するアクセス種類機能を備える請求項４に記載の装置。 ６． 共有のためにクライアント・エンティティにより創成される情報を組織す るための、コンピュータにより履行される動的グループ・レジストリ方法であっ て、 クライアント・エンティティの内側で互いに通信関係にある複数個のパブリケ ーション・コンピュータを創設する段階を含み、パブリケーション・コンピュー タの各々は、動的グループ・レジストリを記憶するためのかつ機能名を含むリソ ース・ロケータを記憶するための電子記憶媒体を有し、各パブリケーション・コ ンピュータはさらにウェブ・サーバ・プログラムを備え、該ウェブ・サーバは、 パブリケーション・コンピュータによって実行されるときに、リソース・ロケー タによって示された機能名をパブリケーション・コンピュータにロードすること によって、パブリケーション・コンピュータがリソース・ロケータに応答するよ うにし、各パブリケーション・コンピュータはさらに、動的グループ・レジスト リを組織するためのデータベース管理プログラムを含んでおり、 各パブリケーション・コンピュータ内のクライアント・サイド通信サーバ・プ ログラムを実行して、クライアント・サイド通信サーバ・プログラムに向けられ たリソース・ロケータに応答し、そして動的グループ・レジストリを組織する際 にデータベース管理プログラムに向かう段階を含み、 各パブリケーション・コンピュータにクライアント・サイド通信リソース・ロ ケータ・リストを記憶して、各パブリケーション・コンピュータ内のクライアン ト・サイド通信サーバで実行するよう所定の機能が選択されるようにし、これに より、指定された個人及びグループの中で情報がいかにクライアント・エンティ ティと共用されるべきかを動的グループ・レジストリが示す段階を含む方法。 ７． 所定の機能を選択する段階は、さらに、内容の生成器及び生成される内容 に関する情報を含む内容生成器機能を選択する段階を含む請求項６に記載の方法 。 ８． 所定の機能を選択する段階は、さらに、内容の消費者を識別する内容消費 者機能を選択する段階を含む請求項６に記載の方法。 ９． 所定の機能を選択する段階は、さらに、グループ及びそのメンバーを識別 するグループ機能を選択する段階を含む請求項６に記載の方法。 １０． 所定の機能を選択する段階は、さらに、グループのメンバーがどの種類 のアクセスを有するかを識別するアクセス種類機能を選択する段階を含む請求項 ９に記載の方法。