"ネットワーク化された商業的やり取りの管理方法であって、情報を複数の束に組み立てるステップであって、各束はデータ要素、データ要素への参照、及び該データ要素について記述するメタデータを備え、各データ要素はネットワーク中のデータ所有者のノード上に所在し続け、前記複数の束のうち少なくとも一つのバージョンが複数存在し、該複数のバージョンの各々は束バージョン識別信号によって識別されるステップと、前記ネットワークの異なるノードに対して、束バージョン識別信号を周期的に発行するステップであって、該束バージョン識別信号は前記データ要素に対する変更事項をアクセッサの前記ネットワークノードに対して表示するものであるステップと、前記複数の束から前記メタデータ及び前記データ要素参照を前記ネットワークを通じて配信するステップと、前記アクセッサが前記ネットワークを通じて配信された前記メタデータ及び前記データ要素参照を用いて前記データ要素を選定するのに続いて、前記組み立てのステップにおいて組み立てられた前記複数の束中の前記データ要素のコピーを、それぞれのデータ所有者の前記ネットワークノードから前記アクセッサのネットワークノードまで配信するステップとを具備する方法。請求項1記載の方法であって、各束は前記データへのアクセス権限を有するアクセッサを識別するセキュリティ情報を含み、前記配信するステップは該アクセス権限を有するアクセッサのみに前記束を配信することを特徴とする方法。所有者とアクセッサとの間の信頼関係を交渉することで前記セキュリティ情報を規定するステップをさらに含むことを特徴とする請求項2記載の方法。前記配信するステップの前に、受け取る複数の束の配信元であるネットワークユーザを有権限ネットワークユーザのディレクトリから選定するステップをさらに含むことを特徴とする請求項2記載の方法。前記セキュリティ情報の形式は、該セキュリティ情報中に組織識別子が含まれることを許容することを特徴とする請求項2記載の方法。所有者の入力に応答して前記複数のメタデータ要素のうちの一つを規定するステップをさらに含むことを特徴とする請求項1記載の方法。アクセッサへのデータ要素のコピーの前記配信及び前記取引に関する関連情報を記録するステップをさらに含むことを特徴とする請求項1記載の方法。前記メタデータには複数のティッカーシンボル識別領域が含まれることを特徴とする請求項1の方法。前記束の少なくともいくつかを追加的情報を含む超束に入れ子構造にするステップをさらに含むことを特徴とする請求項1記載の方法。請求項9の方法において、各束は前記データへのアクセス権限を有するアクセッサを識別するセキュリティ情報を含み、束及びその超束の双方へのアクセス権限を有するアクセッサのみが該束及び該超束の双方を見ることができることを特徴とする方法。前記束及び前記超束の両方に対するアクセス権限を欠く受信者に対して代替的内容を提示するステップをさらに備える請求項9記載の方法。請求項9の方法において、前記束及び前記超束は異なるノードにおける異なる所有者を有し、前記配信するステップは前記束及び前記超束を該異なるノードから配信することを特徴とする方法。前記束は異なるタイプの1以上のファイルへの添付参照を含むことを特徴とする請求項1記載の方法。前記タイプには音声ファイル、ビデオファイル、グラフィカルイメージファイル、フォーマット化された文書ファイルが含まれることを特徴とする請求項13記載の方法。前記束の少なくとも幾つかは他の束への参照を含むことを特徴とする請求項1記載の方法。前記他の束への参照には返信された参照が含まれることを特徴とする請求項15記載の方法。請求項1記載の方法において、前記メタデータを配信するステップは該メタデータへの更新情報をさらに配信し、前記方法は、前記識別信号に応答して、前記複数のノードの少なくとも一つから前記更新情報のコピーを要求するステップをさらに含むことを特徴とする方法。前記メタデータの複数部分に基づいて前記束をフィルタリングするステップをさらに含むことを特徴とする請求項1記載の方法。請求項1記載の方法において、前記コピーを配信するステップは前記データ要素のピアツーピア転送、及び前記束中で参照された該データ要素へのピアツーピアアクセスを含むことを特徴とする方法。請求項1記載の方法において、前記メタデータ中の諸状況の検出に呼応してユーザに警告するステップをさらに含むことを特徴とする方法。請求項1記載の方法において、前記メタデータ中の諸状況の検出に基づいてコンテンツを混合するステップをさらに含むことを特徴とする方法。実施形態の説明図1を参照する。本発明に係る図示のシステム10が1以上の売り手側会社a...nに属す一連の売り手側ユーザ端末a1a2,...an...n1n2...nnと、1以上の買い手側会社A...Nに属す一連の買い手側ユーザ端末A1A2...AnN1N2...NNとを1以上のネットワーク12を介して相互接続している。他のネットワーク通信経路がこれらのユーザの間に存在しうるにもかかわらず、一連の集約サーバAGSs1snS1...SNはユーザによって作動される1以上のアプリケーション層app1...appnAPP1...APPNに対するシステムインターフェースを提供するのが好ましい。これらのサーバは各々会社のうちの1つに対応し、示される実施例における企業制御のサイトに配置されるが、それらはまた、他の方法によっても配置されうる。大企業は多数の集約サーバを使用しうるが、大部分の会社は恐らく1つの集約サーバのみを使用するだろう。小規模の会社は、集約サーバを共有することができる。本実施例において、集約サーバは一つ以上の管理サーバ16による管理組織14と相互に作用する。管理サーバ16は地域社会に付加価値通信網を提供する。提供されるサービスの種類に従い、管理サーバの機能の中には、1以上の集約サーバ内に配置できるものもある。多くのアプリケーションが買い手側および売り手側端末で異なる機能を提供する一方で、この識別が必ずしも役立つものではない点に注意されたい。アプリケーションは、例えば、個々のユーザが買い手側および売り手側の機能にアクセスできるように展開することができる。買い手側と売り手側との役割分担がより明白でない商業域のために、ユーザインターフェースシステムを開発してもよい。システムの中には、あらゆるユーザが、あつらえられたアプリケーションを特徴を異ならしめつつ用いるようなオプションを設けてもよい。加えて、投資産業に関する多くの実施例が本発明を理解する一助として本出願の範囲内で提供されるが、これは本発明に基づく一般原理の応用分野を当該領域に制限するものとして理解してはならない。システム10は、ユーザ端末としてパソコンを使用して実装される。これらの端末は会社のローカルエリアネットワークLANまたはワイドエリアネットワークWANによって、またはアプリケーションサーバを有する外部ネットワークエクストラネットまたはインターネット全体にネットワーク化される。それ自身は集約サーバと連結される。これらのさまざまなサーバは、一つ以上のサーバ級機器と共存もしくは別個に存在しうる。集約サーバは、会社の広域ネットワークWANの範囲内で、或いは他の会社と共有する設備中の企業ネットワークの外に位置することができる。サーバは、一以上の、好ましくは私的な付加価値通信網VANあるいはインターネットを通じて作動する仮想私的ネットワークVPNのようなネットワークを介して、または、公共インターネット全体を巡らせて相互接続することができる。しかしながら、標準の処理能力のない端末や特殊用途端末または、例えば、ユーザ端末としてのワイヤレス個人データ補助装置PDAのものを採用するシステム、および/または、組織やネットワーク要素の選択が多くの方法によって適切に変えられるシステムといったような代替的実施態様もまた可能である。本システムは、ボイスメールメッセージ、テキスト、及び、様々な種類のサブドキュメントを含みうる多種形式の電子文書を含む全種メッセージ、即ち、例えばテキストベースのHTMLファイル、アドビ登録商標pdfファイル、グラフィカルチャート、オーディオファイルおよび映画といったファイル用の単一電子チャネルを有するインフラストラクチャを提供する。各々のメッセージは束と呼ばれている。束は、その束の内容を表現し、受信権限を持つ者を特定する、ユーザによる拡張可能な多種メタデータセットによって分類される。ツールは、任意の束を構築するための管理組織によって提供されうる。図2を参照する。束は、2つの主要部、即ち、束ヘッダおよび内容を含む。ヘッダは、ルーティングデータおよびメタデータを含む。ルーティングデータは、束のための終点アドレスを特定し、このアドレスによって、集約サーバが束を配信することが可能となる。メタデータは、アイテムのための一連のアイテム記述子および価値情報値を含む。メタデータ項目の中には要求されるもの、カスタマイズされうるものもある。内容コンテンツは、ネットワークの中で異なる種類の文書またはこれらの文書への参照を含むことができる。束は、ユーザおよび/またはアプリケーション開発者が自分自身のデータ型例えば伸長可能なマークアップ言語XMLを定めることができる言語を使用して実行されることができる。例えば、束のためのXMLデータ型定義DTDは、束と呼ばれているルート要素を含みうる。それは更に、誰が束を読む権限を有するかを特定するターゲット、及び、当該束のメタデータ記述子を特定するBLDと呼ばれている要素を有してもよい。束の要素の属性は、例えばID、発信者ID、見出しおよび作成日付といった項目を含んでいてもよい。ターゲット要素の属性は、例えば受取人ID、受取人名、及び受取企業ID等といった情報を含みうる。BLD要素の属性はキーおよび価値情報を含みうる。図2に示される概略につづくパッケージが強力であるにもかかわらず、勧誘招待状のような他のタイプを定めることもできる。図3を参照する。ユーザ端末および他のシステム上で動作しているユーザインターフェースアプリケーションおよび企業内アプリケーションは、一般に、拡張可能な統合アーキテクチャXIAを通じた集約サーバによって提供される基盤と直接的或いは間接的に相互作用する。このアーキテクチャは、情報共有を容易にする多くの統合位置およびイベントチャネルを提供する。集約サーバを管理する同一組織によって、或いは当該サーバを用いる会社の社員によって、または外部コンサルタントによって、XIAと相互作用しうるアプリケーションは提供されうる。中心的なインストラクチャサービスとの異なる種類の相互作用を可能にするXIAのための接続ポイントが3つある。第1はXIAAPIである。XIAAPIはローカルCOM構成要素としてまたはSOAPを経た遠隔サービスとして現れるアプリケーションプログラミングインターフェースAPIである。これは、束やユーザのような一組のオブジェクトを具象化するためのインターフェースを提供し、これによりアプリケーションがこれらのシステムオブジェクトを生成し、該システムオブジェクトと相互作用できるようにする。第2の接続ポイントはXIA警報である。XIA警報は、警報形式のメッセージを配信すべくTIBCOランデブを介して発行される非同期メッセージである。これらは、無線デバイスに対する束の通知、または管理コンソールに送られる単純ネットワーク管理プロトコールSNMPタイプメッセージのような、ユーザ収束的なものであってもよい。第3の接続ポイントは、XIAトリガを含む。これらは、縦続処理を集約サーバに起こさせうるイベントである。XIAトリガは、所定の一連の作業を遂行すべく他のシステムおよびアプリケーションに同期的あるいは非同期的につながることができる。上記した3つのアクセスポイントが集約サーバの入力および出力を定めるのに対して、XIAのイベントテーブルはあらゆる種類のXIA活動の内部手順フローを表記する。イベントテーブルは、もの例えば束タイプ、終点アドレス、発信者、ユーザ役割またはユーザ定義可能な特性さえの組合せに基づいて、極めて精密に穀粒化されたレベルで定められることが好ましいといえる。各々のイベントテーブルは、一連のアクティビティに優先順位、依存度、実行方法および集約サーバによって管理されるあらゆるオブジェクト上のあらゆる動作要件を提供する。内容混合は、XIAイベントテーブルがシステムの両方のエンドポイントで用いられるメソッドの例である。XIAAPIpublishBundlemethodXIAAPI発行束メソッドがコールされると、XIAイベントテーブルは特定の束タイプおよび終点アドレスをキーに発見され、ジョブシーケンスのように実行される。テーブルは、同期的にローカルCOM呼び出し命令がこの材料の公開を許可するコンプライアンスシステムになければならないことを定めることができる。次に、非同期呼び出し命令は、この主題の最新の研究を要請するために別々のサーバ上の調査システムに向けてなされることができる。一旦同期動作が完結すると、メタデータがネットワークに対して発行される。メタデータが受取人の集約サーバに達すると、WAP表1参照を使用している無線デバイスに、メタデータを渡す通知システムに対してランデブを介したXIA警報を発信するXIAテーブルが誘引される。受取人が束を要請するときには、それらのワークフローアプリケーションはXIAAPIfetehBundlemethodXIAAPI束フェッチメソッドをコールしうる。これにより、コアフィルタリングサービスを交換するか増幅するローカルXIAテーブルが実行され、例えば、ローカルコンプライアンスサーバから情報を要求して、ACMEに関する購入を観念することが、ユーザによって管理されている資金の趣意書定義に基づいて可能でないかどうか決定し、これによりユーザがこのような観念に接することすら妨げる。追加的な内容混合はまた、供給されるローカルニュースから主題上のシステム統計および主題上の上位5つのニュース見出しに関する非同期的要請を引き起こしている発信者および束タイプに基づいて、XIAテーブルによって動作させることができる。セキュリティおよびユーザ認証は、ローカルXIA機能がXIAテーブルのカスタム化を経て完全に置換されることができる方法についての他の実施例である。XIAログイン要請のための標準のシーケンスは、完全に取り除かれることができて、ユーザを確認するクライアントに特有の認証シーケンスと取り替えられることができる。この過程は結果的に、集約サーバにひき渡しうる徴証の生成となる。このとき集約サーバはユーザを確認するために、当該徴証をサーバ側徴証と突き合わせる。これは適切な徴証情報を格納すべく、ユーザオブジェクトのプロパティをカスタム化させることを必要とする。これによりシステムネットオブジェクトは異なる統合プロジェクトのために増幅可能な伸長特性を有することになる。クライアントおよびサーバ側のセキュリティ定義が同時発生的でない限り、ユーザ確認は完結せず、従って許可されることはない。XIAは、2つのモードのどちらにおいてでも作動するように構成することができる。第1のモードは、同期モードと呼ばれている。このモードにおいて、XIAは必要な動作を実行すべく、外部システムに文書に対する支配権を渡す。外部システムが集約サーバ中に呼び戻され、文書状況を修正するまで、制御及び処理は再開しない。この時点で、制御はXIAエンジンに再度移される。第2のモードは、非同期モードと呼ばれている。このモードにおいて、外部システムは、文書がシステムを通過し、外部システムが要望または必要に応じて複数の並列処理を始めることができる旨を通知される。XIAは文書処理を継続し、外部システムは、それが通過する際には当該文書へのアクセスを制限する。XIAは、カスタムコンポーネントを埋め込むことによって既存のデスクトップアプリケーションが地域内の他のユーザと相互にやりとりするのに適合させることができる。これにより、必ずしもワークフローを残すことなしに、多くのユーザがインフラストラクチャの協同権限に切れ目なくアクセスすることができる。例えば、売り手側トレーダは、XIAと相互に作用することができる組込形部品で強化された標準の取引端末例えばロイターズアンドレッグやXTRA端末を使用するかもしれない。また、販売員は標準のコンタクト管理アプリケーション例えば同様に強化されたMicrosoftOutlook登録商標を使用するかもしれない。この種のアプリケーションを使用することで、これらのユーザは、標準的な環境下他のあらゆる種類のデータを生成受信するように、システム束を作成し、受信することができる。XIAは、アプリケーションプログラミングインターフェースAPIセットを超えるものである。多目的APIについては、外部システムは一組のパラメータと機能名をコアシステムに引き渡し、該コアシステムは、外部システムに代わって機能を実行する。しかしXIAについては、その機能の実現にあたりどんな方法が選択されるにせよ、制御が外部システムに引き渡されることができる。実施例は、3つの標準の通信プロトコル、即ちマイクロソフト社登録商標の構成オブジェクトモデル/分散型構成オブジェクトモデルCOMDCOM、TIBCO登録商標のランデブメッセージシステム、及びマイクロソフト/IBM登録商標のSOAP単純オブジェクトアクセスプロトコルを介したXIAでの外部システムおよび集約サーバ間の相互作用を開示する。サポートされうる他の技術は、サンマイクロシステムズ社登録商標の遠隔方法呼出しRMIおよび一般のオブジェクトリクエストブローカアーキテクチャCORBAを含む。これらの技術は、従来技術において当業者に容易に理解される様々な公的利用可能文書において明確に定義されている。情報はシステムからユーザのデスクトップへ、アプリケーションから集約サーバに、ネットワーク全体から他の集約サーバに、更にアプリケーションを経て再びクライアントのデスクトップへと動き、XIAはさまざまな機能及びイベントが集約サーバ及びアプリケーションとの間で起こることを可能にする。XIAと相互に作用するシステムは、一般に、2つのタイプがある。即ち、売り手側コンプライアンスエンジン及び内容混合のような、集約サーバへの機能を置換し、増幅し、及び/もしくは、修正するもの、ユーザ向けのユーザインターフェースを形成し、束の生成受け取りを可能にするアプリケーション、である。XIAプロセスは、外部システムが、通りすぎる情報に対して価値を付加する内容混合と呼ばれることを可能にし、集約サーバの機能性の変更態様を可能にして、適切な外部システムにイベントの通知を提供することができる。例えば、システムはユーザまたはユーザ会社がシステムの異なる位置発信者企業の集約サーバ、システムのコア基盤および/または受取人企業の集約サーバを含むで追加的な内容を束に混ぜ入れるのを許可することができる。ユーザアプリケーションはまた、発信者および/または受取人のデスクトップでの混合を許可することができる。付加された内容は、いかなる互換性を持つデータソースからであってもよいし、束に層として加えられてもよい。それは、文書の作成段階での、または、内容のスナップショットとして、例えばハイパーテキスト転送プロトコルHTTP参照のような内容の参照として、加えられることができる。集約サーバに格納されている授与資格を用いることで、内容混合はまた、ユーザに特有にもしうる。内容の追加は、既存の束周辺で超束を築くことで、または束を変形することによって実行することができる。一つの実施例においては、売り手側証券会社の販売員が、買い手側会社で、ポートフォリオ管理者のための技術セクタに関するサンフランシスコの来るべき会議について、投資束を準備する。彼は次に、自身の内部調査システム内から最新の工業報告およびモデルを束に加えて、それを送信する。内容混合の第1のレベルにおいて、売り手側会社は束がその集約サーバを通り過ぎる際に自動的に当該束にその法的否認陳述書を付する。内容混合の第2のレベルは、束がシステムのコア基盤に到着するときに発生し、売り手側会社が天気予報の束への追加を要請したことを検出し、買い手側会社が特定の天気内容サービスの加入者であると結論付ける。この検出により、所与の日付におけるこのサービスから得られるサンフランシスコの天気予報が投資束に加えられる。内容混合の最終レベルは、束が買い手側会社の集約サーバに達するときにであって受取人端末に達する前に発生する。このときに、会社の集約サーバは束には技術セクタが付されていることを感知し、それらの内部システムのうちの1台からの買い手側会社のアナリストから、最新の技術セクタ報告を加える。他の例では、売り手側会社の販売員は、オンラインオークションサイトについて買い手側会社のための束を作成する。彼女は、束に5つの普通株を付け加えて、最直近の評価およびそれらの普通株の推奨が束において表示されなければならないことを示す。売り手側会社がXIAを通してそれらの調査データベースを自社の集約サーバに接続したので、単に束を開けることで、束内部の調査データベースから得る推測および推奨情報へのアクセスが提供される。更なる実施例においては、会社は管理組織によって提供されるニュースサービスの購読者になることに署名した。この会社によって受け取られるいかなる束も、タグを付けられた普通株についての5つの最新報告を含む。他の例では、買い手側会社は、自社のアナリストが売り推奨とした株に付す束についてポートフォリオマネージャが時間を浪費するのを望まない。この種の問題の回避を助けるために、それらはそれらの集約サーバが束が付け加えられるあらゆる株主権についてのそれらの内部アナリスト推奨を表示するようにプログラムすることができる。更なる実施例において、販売員が内部の情報源例えばアナリストから束を受け取るときに、彼女は束が付け加えられた株主権に興味がある潜在的接触先の一覧を見たいと思う可能性がある。XIAと相互に作用するアプリケーションにおいて実行されうる多くの機能は、1999年5月18日出願、出願番号09/313829番公開番号:PCTUSOO13385の商取引の主題に関する情報を管理するための方法及び装置と名付けられる出願、及び、1999年8月9日出願、出願番号09/370671番公開番号:PCTUSOO21870のイベント情報管理システムと名付けられる出願の、2つの同時係属中の出願において示される。これらの2つの出願のいずれもが参照取込によって本願明細書中に組み込まれるものである。アプリケーションがXIAに与える機能は、また、集約サーバが通知作業を遂行するのを許可することができる。機能中で特定状態が検出されるとき、例えば束が特に不安定なセキュリティに関連するとして検出されるときには、XIAは機能と関連する通知処理を始めることができる。これらの処理は、目的地の端末がより目立つ警報ウインドウを発行するよう要求することからポケットベルメッセージを始めることまで及ぶ。図4を参照する。システムの構造は、更に詳細に説明される。図示のように、集約サーバは認証及びアクセス制御、協同プロトコルアダプタ、通知サービス、電話通信サービス、内容配信及び検索サービス、協同サービスおよびデータ配信サービスを含む6つの別々の機能モジュールを含むことができる。これらのモジュールの機能および構造はまた、図示されているのとは異なる方法で分解することができる。しかしながらそれは、論理素子を結合し、分離し、適切なものとして作り直した場合に初めて可能となる。協同サービスは、管理協同オブジェクトおよび文書のための一まとまりの事業ロジックおよび持続的アプリケーションサービスである。それは、ユーザ、名刺、関係先、企業、グループ、束および受信ボックスといったオブジェクトを含んで、これらのオブジェクト用の標準的XMLDTDを提供する。各々のサービスは、複雑なワークフローまたは商取引のそれらの一部を遂行すべく、適時情報交換可能な方法で、他のサービスと共働する特定の作業または一連の任務を成し遂げる。協同サービスは、集約サーバAGSの中心的な機能を提供する。XIAは、クライアントアプリケーションを協同サービスと統合するためのツールキットを提供する。XIAサービスAPIは、協同サービスにHTTP/SOAPインターフェースを提供する。XIAクライアントアプリケーションは、データを要求し、処理を実行するためにこれらのインターフェース例えばAPIを使用する。それは、AGS上にあっても離れていてもよい。データがAGS上で変化するときに、XIAトリガはカスタマイズされた通知および動作を遂行するように許可する。XIAトリガ使用の例は、制限された証券のためのあらゆる出て行く束を点検するコンプライアンスモジュールのサポートであって、束が配信されるのをさえぎる。XIAトリガは、Java登録商標のクラス具象化およびメソッド呼び出しを通じて実行される。そこで特定のトリガ実施態様は、直接Java登録商標を使用することができるか、または、COM、Tibcoランデブ、VBA/VBスクリプトまたは他のプロトコル/Java登録商標から呼び出されることができるツールセットを使用することができる。典型的クライアントは、COM/DCOM/RMI/CORBA/SOAPコンポーネント/サービス及び、ランデブサーバプロセスである。トリガは、特定の客の要求を満たすために各々のAGS上で別々に開発し構成することができる。XIA警報は、特定の協同サービスビジネスオブジェクトに、非同期的変化を配信する。ティブコランデブメッセージは変化を配信するために用いる。そして、それはXML文書として括られる。XIA警報を用いる例は、受信ボックスインボックス通知をユーザのPDAに配信することのサポートである。カスタムメイドのXIA警報依頼人は、特定の警報に会員申込することができて、必要に応じてデータを処理することができる。XIAクライアントアプリケーションは、XIA警報を受信するためにサービスAPIまたはCOMAPIを使用する。XIACOMAPIは、協同サービスにCOMインターフェースを提供する。それは、AGSを離れて存在し、XIAサービスAPIを介してAGSと通信する。クライアントは、クライアントデスクトップアプリケーションすなわちノーツ登録商標、アウトルック登録商標、ロイター登録商標が典型的である。XIAクライアントデスクトップアプリケーションも、イベント/警報の通知を必要とする。軽量例えばrvdでないクライアント側ランデブは、XIA警報をXIACOMAPIに配信するために用いる。警報は、次に、XIACOMAPIを通じて、クライアントにCOMイベントとして配信される。内容配信サービスは内容が遠隔AGSから検索されるようにし、XIAトリガを通じて付加されるデータに混合する。データ配信サービスDDSは、配信された多くのデータ格納を同期させるように保つ。それは、ネットワークの全体にわたる多数の場所において生きているデータオブジェクトの概念をサポートする。DDSは、ネットワークの全体にわたってオブジェクトを配信し、オブジェクトの潜在的な整合性を保証する。データ互換性サービスはデータアダプタ及びXMLDTDを提供し、ネットXMLデータを1つの改訂版から別の改訂版に変換する。それは、あらゆるAGSに存在する。電話サービスが提供するのは、ボイスメールメッセージを束に取り付けられるようにすることである。支払い請求及び統計はネットバックボーン上に存在する一組の情報サービスである。ランデブメッセージとしてネットを協同文書例えば有効なXML文書として表示されるビジネスオブジェクトが通過する際、それはこれらのメッセージを聞いて、これに対応させて、その支払い請求および統計データを更新する。支払い請求データは、会計モジュールによって処理される。一実施例において、協同プロトコルアダプタは、モジュラー式の方法で外部アプリケーションを有するインターフェースに与えられる。次に、コンテント内容配信、検索及び混合サービス、フェッチについて更に詳細に説明する。フェッチは、データ配信のためのいかなる分散コンピューティング環境においても使用しうる点に注意されたい。システムは、より大きいコミュニティの会員として総てにわたり機能している地球の全体にわたって配信される集約サーバの集まりを用いて設計される。各集約グループ及び各グループ内のそれぞれのサーバは、より大きいコミュニティの独立実体およびメンバとしての役割を担う。集約サーバAGSsの間に配信されることを必要とするデータは2種類ある。集められたメタデータすなわち、束メタデータおよび該メタデータが記述する実内容である。フェッチは、内容自体に全体的に関係して、タイムリで安全な方法でのそのデータの格納及び配信のためのフレームワークである。フェッチは、データを格納し、その記憶空間を管理し、差込可能なコンテンツ源を許可する。差込可能とは、インターフェースがデータソースのために定義されることを意味する。よって第三者は、そのインターフェースを実装することができ、フェッチを通じ、システムコミュニティのための内容源として作用することができる。異なる集約サーバ上のフェッチサービス間のコンテンツストリーミングを含むあらゆる通信は、TibcoランデブRV登録商標において起こる。フェッチは格納記述子を生成するが、それはフェッチサービスによって格納される特定の内容部分に対応する識別子である。この記述子は、グローバルに唯一的である。いかなるAGS上ものフェッチは異なるフェッチサービスによって生成される格納記述子によって識別される内容の要請にサービスを提供することができる。そして、それが他のAGS上にあってもよい。フェッチは、誤りを許容し計測することが可能に設計されている。要求されるサービス回数は、実際的な範囲に最小化される。フェッチは、単一の要請への多くの反応を取り扱うことができる。下流のキャッシングを組み込むことができる。フェッチは、また、1つの集約グループ内だが異なるAGSs上のフェッチサービスの間で調和することができる。これにより、データソースを共有する場合に1つのフェッチサービスが別のフェッチサービスを引き継ぐことができるようになる。そして、それは並列の変更態様を避けられるように、修正可能データにロッキングを提供するべく必要とされる。フェッチは、すでに利用できた内容を収縮制限させる能力を有する。それが修正された場合、サーブされた全コンテントはその内容の最も最新のバージョンである。コンテントは、性能を向上させるために外部の集約サーバに取り入れられてもよい。加えて、いかなるAGSも、当該内容のキャッシングは許可されないことを指定することができる。外部キャッシュのデータの暗号化が組み込まれているため、仮に、性能の許す範囲内において物理的にアクセスできてもデータは解読されることができないようになっている。フェッチは内容を格納しえても、それを他のフェッチサービスに配信することはできない。フェッチが格納している内容に関する情報は、AGS内部及びAGSの外側で利用できるその情報の部分集合の範囲内で利用できる。フェッチの操作特性は、リスタートなしで修正されることができて、その性能および動作に関する情報を提供することができる。単に事業規則のみに基づくフェッチを設計することは結果として厳格な要求/応答システムになっている。そのシステムでは、内容が要求されるたびに内容がその所有者から検索されることで、所有者たちが自身のデータについての最終管轄権を保持できるようにしている。所有者が利用可能性を制限させることに決めた瞬間、誰もそれを得ることができないことになる。しかし、このように設計されるシステムは底知れぬパフォーマンスを有する。その理由は、それが不必要にネットワーク全体の大量のデータを繰り返し送っているからである。単に性能のみを考慮してフェッチを設計することは結果として、コンテンツが所有者から1回送信され、各受取手の集約サーバが関係しているパッケージが削除されるまで、要求に応じてコンテンツを取り込み、サービスすることになる。これは、結果として、コンテンツ所有者が最終的な管轄権を、即ち、自分の瞬時的制限能力を失うことになる。もし所有者のAGSが機能しているが、そのネットワークコネクションを失う場合、所有者が内容を含んでいるパッケージを制限するが、パッケージ内容を利用可能にしておくことは可能である。しかしながらこれは、容認できない。これらを解決するため、フェッチは、解放証明書を用いて知的キャッシングおよび最適的配信を用いる。即時制限が必要である内容は、解放証明書を必要とするものであるように印をしてもよい。内容が外部キャッシュ貯蔵にあり、その集約サーバ上のユーザが内容を要請するときに、コンテンツの入手先であるデータソースの所有者から解放証明書を得るまで、キャッシュは当該格納されたコピーの役割を果たさない。解放証明書に加えて、追加所有が提供される。いかなるフェッチサービスも、それが他のフェッチサービスに配信する内容が貯蔵不可能であることを示すように構成されることができる。これにより、キャッシングに関する個々のAGSの事業規則を融通をきかせて容易に変化させることが可能となる。個々の内容部分の中には、また、貯蔵不可能であることを示すことができるものもある。これが提供されるのは、ある特定の内容部分のためのデータソースが常に内容を修正しているということであってもよいので、外部サーバ上のキャッシングは意味をなさないからである。更新されたコピーが常に必要であるので、内容上のキャッシュスペースを使用することは浪費的である。次に内容の配信について説明する。内容が第一に配信されることができるかどうかについて決定する3つの基本的な内容状態タイプがある。即ち、未登録内容は、AGSの外側に配信されない登録済私的内容は、AGSの外側に配信されないAGS内登録済公的内容は、他のAGSsが利用できるここにおいて、アクセスは与えられた全3種類の格納に加え、ネット上の他のフェッチサービスの登録された公的格納に対して与えられる。内容は、次の2つの方法で配信されることができる。即ち、要請/反応、コンテンツプッシュもし、IOCD知的最適内容配信が可能で、コンテンツがIOCD対応なら、このコンテンツに対する第1の要望がコンテンツプッシュを誘発し、このデータの総ての受取人がキャッシングのためにそれを受信するようにする。要求される前にコンテンツを有する外部サーバの方へ動かすことは、結果的に、以下の2つの方法での性能の大幅な向上をもたらす。外部のサーバ上のキャッシュから抜け落ち、再度要求しなければならないという状態でない限り、内容コンテンツが一度だけそのデータソースから物理的に読み込まれる。もしも、ユーザがコンテンツを最初に要望した者でないときは、データがすでに該ユーザのキャッシュにあることからデータ転送は不要な可能性がある。IOCDは、単なるオン/オフ状態を提供するのでなく、むしろ一組の規則に基づいて特定の内容を最適的に配信するように構成することができる。これらの規則は調整器上で可変であり、いかなるコンテンツも規則において使うことができる。規則構文の例としては、次の条件が満たされる場合には、最適的に配信するというものがある。即ち、SIZE300KMIMETYPEapplicationworldstreetXclientNUMRECIPIENTS3ネットワーク連結性に関係なく即時制限を利用可能にするという要件に加えて、1台のサーバが故障する場合、コンテンツが受取人に利用できるままでなければならないというのは同様に正当である。これは集約グループの概念によって取り扱われる。それは個人としての及び集合的に動作する一群としての集約サーバである。フェッチは、そのデータソース概念に基づきこれらのグループのデータにアクセスする。集約サーバ間でこれらのデータソースを共有できるようにすることは、我々にデータへの冗長的アクセスを与える。能率的に、かつ高圧的にならずに、サービスを構成するには、フェッチが、誰がアクセスしているかとか、どれくらいの数のアクセスが起こっているかでなく、そのデータストアにアクセスしている他のサーバがあるかどうかの可能性を決定できることが必要である。フェッチが考慮する必要のあるのは、他者がそのデータソースにアクセスしている次の2つの明確な場合のみである。フェッチサービスの依頼人が若干の内容の特性を編集することを望む場合。このとき、ロッキングが提供される。解放証明書がサーバAにより発行されるが、その反応速度が3倍速いことから、外部フェッチサービスはコンテンツを供給するためにサーバBを使用することを決める場合、サーバBはそれが外部フェッチサービスによって与えられている解放証明書が実際に有効であるそれが所有者によって発行されたということを知っていなければならない。第一の場合のロッキング及び解放証明書にアクセスしている集約グループ内の全サーバは、Tibco登録商標のランデブ誤り許容概念を利用するコア誤り許容サービスフレームワークを用いて実現する。このサービスフレームワークについては、総てのメソッドコールはRVメッセージに変換され、当該サービスを動かしているサブネット上の他の誰にでも同報される。作動中のサービスのみがメソッドコールへの応答を発信するが、サービスのインスタンスは総て、自身のメソッドがコールされるように選ぶことができる。これにより、全サービスを一貫した状態に保ことができる。システムのデフォルトインスタレーションは、ファイルシステムを使用するデフォルトデータソースを提供する。ほとんどの場合このファイルシステムは、ネットワーク付加記憶NASの形式となり、グループの全集約サーバ間で共有される。多くの製品が異なる種類の複製技術例えばデータベース製品またはLDAPベンダーのような同期方法を提供する一方で、システムはユニークな方法を用いて、コミュニティの中の全サーバがデータ配信サービスDDSの正当な一組のデータによって最新に保たれることを保証する。オブジェクトが格納され、削除され、適切に配信されることを確実にするように相互に作用するDDSに対して、4つの概念的な部分がある。これらは、以下の通りである。即ち、協同サービスオブジェクト:これはそれらのインスタンスを堅持し、他の集約サーバにそれらの状況満載の情報を発行するのに資する。データベーススキーマ:これは、物理的な格納を行うメモリオブジェクトを遂次化するテーブル定義および属性から構成される。該スキーマもまた、マイクロソフト登録商標上のSQLサーバに格納されるプロシジャ形式でのデータベースコードを含み、予想済み及び予想外の質問をサポートするよう誘引される。下の線図は、協同サービスオブジェクトとデータベーススキーマとの関係を例示する。DDSエンジン:これは、例えば新規なオブジェクトの作成、既存のオブジェクトに対する変更、またはオブジェクトの全削除のようなオブジェクト動作の発行及び同化にあづかる。これは、発行及び同化に対してそれぞれ責任がある外向けサービスマネージャおよび入り線サービスマネジャの2つの部分から構成される。同期サービス:これは、全集約サーバが正しい順序でオブジェクト動作を受信して、処理することを確実にする。これは、スキーマ関連のデータ例えばGUIDおよびVTDs及び、マネージャ例えばインバウンドサービスマネージャ内諸能力及び、転送サービスから構成され、総ての情報が順番に処理されるということを保証している。ここで示される図示的なDDSフレームワークは、多くの事業および技術的な要件を満たすように設計された。このシステムの他の態様と同様に、これらの要件には、システムのための異なる事業目的および本発明の範囲の外にある技術的な制約が与えられた場合には、様々な変更の余地がある。本実施例における要件は、3つのカテゴリ、即ち、集約サーバ内要件、集約グループ内要件および集約グループ間要件に区分される。集約サーバ内では、アプリケーションロジックを通じて、もしくは臨時質問を通じて、ローカルデータベースに変更を加えることが可能でなければならない。いずれの場合においても、VID、GUID、オリジネータおよびタイムスタンプは適切に維持されなければならず、遠隔サーバは変化を発見しなければならない。DDS関連のいくつかのシナリオにおいて、ビジネスロジックによって定義される動作を誘引することが必要になるかもしれない。これらのフックが役立つかもしれない場合もある。即ちローカルオブジェクトの保存前、ローカルオブジェクトの保存後、及びリモートオブジェクトの保存後である。ローカルオブジェクトの保存前に起こるフックは、セーブを中止するかまたはオブジェクトを修正する能力を有していなければならない。集約グループ内では、集約グループ内の全サーバが同じデータを維持しなければならないおそらく小さい時間のずれはあろう。集約グループは、任意の数のユーザに比例し、任意の大きさの地理的領域にわたることが可能でなければならない。ユーザがグループによって所有されるオブジェクトへの共有変更態様アクセスを持つことが可能でなければならない。これらのユーザが別々の機械にいること、そして、潜在的には、別々の地理的場所にいることが可能でなければならない。ユーザが別々のサーバ上のオブジェクトに並列的に態様変更を加える際には、誰の態様変更が承認されるかについての決定論的な意思決定がされなければならない。総てのサーバは、この判定について同意しなければならない。他のユーザがそれを検索したあとだが再保存する前にオブジェクトが修正された場合には、ユーザがなすいかなる変化も拒絶され、ユーザが当該オブジェクトの汚れたコピーを有したと通知されることを確実にするために最高度の努力を傾けなければならない。サーバが故障する場合、グループ内の他のサーバがそれにつつがなく取って変わることが可能でなければならない。いかなる失敗シナリオにもおいても、全サーバをバックアップし、互いに再同期させることが可能でなければならず、この再同期の結果は予測可能で、合理的であり、整合がとれていなければならない。全サーバは再同期の後に同じデータを含まなければならない。遠隔で見えるいかなるデータも遠隔マシン上で一貫した状態においてなければならない。集約サーバ間でバランスユーザをロードすることが可能でなければならない。集約グループ内では、ただの一つの故障点もあってはならない。グループ内のサーバは、それぞれ独立に作動しなければならない。1台のサーバは、他のサーバに起こっている処理のためのボトルネック隘路であってはならない。オブジェクトを、グループ内には発行されても、ネットワークからは見られない状態で保存することが必要かもしれない。集約グループ間で、集約サーバは、遠隔集約グループによって所有されるデータに関する整合性を維持することが可能でなければならない。集約サーバでは、当該グループが保有するデータを修正することのみを可能にしなければならない。同期が失われるときには、再同期位相のネットワーク洪水を避けるために最高度の努力が傾けられなければならない。いくつかのデータを他のいかなる集約グループにもさらすことなく、ローカル集約グループ全体に亘って同期させることが可能でなければならない。DDSにおけるビジネスオブジェクトは、XML文書として表現するべきである。これらの文書は、DDS外で使うことができる。使用されるXMLフォーマットまたは所与の種類のオブジェクトは、時間とともに変化することができる。異なる集約グループが異なるバージョンのソフトウェアを実行させることが可能でなければならない。新旧のXMLフォーマット間の転換は、自動的に取り扱われなければならない。以下の使用事件は、DDSの動作を例示する。ユーザは、XMLCDとしてXIAを通してオブジェクトを嵌入する。分散オブジェクトは、CDからインスタンスを生成される。カスタム動作が実行されている場合には、オブジェクトは通知エンジンによって送信される。これらのカスタム動作は、セーブの拒否かオブジェクトの修正かのいずれかをすることができる。次に該オブジェクトは、データベースおそらく、多数のテーブルにわたってに保存される。発信者は自動的に現地の発信者にセットされる。そして、新規なGUEDは自動的に生成され、新しいバージョン識別子VIDはVIDサービスから検索される。該オブジェクトが保存されたあと、それはTIBRVメッセージ内で、他の集約サーバに対して同報されるXMLフォーマット化されたCDに変換される。シンクロナイザサービスがTIBRVメッセージ内のCDを受信する。分散オブジェクトは、XMLデータに基づいてインスタンスを生成される。オブジェクトがデータベースに保存されるときに、それは通知エンジンに送られる。遠隔オブジェクトであるので、通知エンジンはそれを修正することができないかまたは変化を拒否することができない。該オブジェクトは発行されない。これは、遠隔ホームに帰属するからである。ソフトウェアの以前のバージョンを実行している集約サーバからの同期サービスへのCD。同期サービスは、オブジェクトタイプおよび遠隔かつローカルタイプバージョン番号に基づいてクラス名を生成する。このクラスは、WorldStreetからロードされて、旧フォーマットから新規なフォーマットまでXMLを翻訳するために用いる。該クラスが利用できない場合、フォーマットは不変であるとみなされる。保管が、それから前の使用事件として進行する。CDが、予想以上に高度のVIDをもって同期サービスに到着する。オブジェクトを保存する代わりに、同期サービスは、再同期要請を、それが受信した最後のVIDより高いVIDを有する全オブジェクトを要請している遠隔サーバに送信する。CDが、予想以上に低度のVIDをもって同期サービスに到着する。おそらく他のサーバが再同期を要求したという理由によりCDは無視される。ローカルオブジェクトが削除される。該削除はTIBRVメッセージとして同報される。そして、該削除されたオブジェクトについての参照が、新VBDを有するdeletedobjectsテーブルに加えられる。CDが、ローカルオブジェクトを表す同期サービスに到着する。該オブジェクトは、すでにデータベースにあるので、無視される。ローカルのインストールがアップグレードされる。サーバは、以前のローカルバージョンより新規なバージョンによって作成された全リモートオブジェクトを要求している特別な再同期要請を発信する。これらのローカルバージョンのオブジェクトが遠隔オブジェクトからのデータの総てを含むことができるというわけではない。これは、それらが保存される前に、翻訳過程を経なければならないからである。オブジェクトが現れるときに、それらはデータベースに再保存される。これは該オブジェクトに対する本当の変更ではないので、通知はあってはならない。また、旧VEDを有しているからといって第5の使用事件内であるとして拒絶されるようなことがあってはならない。データベーススキーマは、DDSをサポートするために特別に準備することが必要である。第1の要件は、データベースのあらゆるテーブルに以下の3本の柱がなければならないということである:発信者guidVID各々のguid/vid一組は、特定のオブジェクトに特有である。該オブジェクトが多数のテーブルそして、いくつかのテーブルの多数の列さえにわたって広げられる場合、同じguid/vidはそのオブジェクトと関連するあらゆる列にあることになる。各々のタイプ/発信者一組に対して、vidの順序は維持される。オブジェクトが修正されるか、更新または削除されるたびに、新しいVIDがシーケンスから割り当てられる。これらのVEDにより、シンクロナイザが、逸失した最新版を検出して、逸失データを検索することができるようになる。VIDの順序性がアプリケーションロジックおよび臨時質問間で共有されなければならないので、新しいVIDは別々のVIDサービスから検索されなければならない。当該VIDはまた、格納された手順によって維持されることが可能だが、これはアプリケーションロジックの余分のデータベース質問を加える。ローカル発信者の一覧を示すテーブルが、維持されなければならない。これが、アプリケーションロジック、同期サービスおよび臨時質問によって、オブジェクトがローカル或いは遠隔かを決定するために用いられよう。臨時質問の同期および削除の再同期をサポートするために、トリガがあらゆるテーブルに必要である。DDS例えばdeletedobjectsをサポートしているワーキングテーブルを除くこれらのトリガは、テーブルが臨時質問によって修正されるときに、新しいVIDが関連したテーブルの総ての関連した列に割り当てられ、伝播されることを確認することが必要となる。それも、オブジェクトが完全に削除される第1テーブルへの入力が削除されるときに、新VIDを有するdeletedobjectsテーブルに1列が加えられることを確実にすることが必要となる。この種のトリガの機能性の輪郭は、次の通りである。処理を開始せよ。臨時質問でなければ、スキップせよ。これが臨時質問であるかどうか発見することができる方法が、次のように2つある:1各アプリケーションプロセスがトリガが確認することができるテーブルに、そのスピッドを入れる格納されたプロシジャをコールする、または2トリガが、該プロセスのDBLIBNAMEをチェックし、同意に達したストリングをチェックすることができる。トリガの挿入されたテーブルからVIDを得る。新しいVIDがすでに、triggersテーブルにある場合、VIDの存在がこのテーブルが他のテーブルのトリガの一部として更新されているという事実の信号を送るので、直ちにリターンする。唯一的なVIDを得る。triggersテーブルに唯一的VIDを入力する。関連した全VIDテーブルのVIDを更新する。triggersテーブルからVIDを削除する。このトリガが削除であって、なおかつ、該削除がマスターオブジェクトを取り除くもはやデータベース中にオブジェクトは存在しないことを意味する場合、このオブジェクトは新VIDを有するdeletedobjectsテーブルに加えられなければならない。処理を終了する。種類関係表を保守整備することによって単一の格納済プロシジャの大部分の過程を自動化することが可能にもなろう。この表の各列は、次の3つの情報を含む。typenametablenameisprimaryこれにより該格納済プロシジャは、総ての関連した表をtypenameによって見つけて、どのものが主たるテーブルであるかを発見することができる。それはまた、システムの種類のリストを発見するために同期サービスおよびVIDサービスによって使われることができよう。DDSエンジンは、DDS内容を含んでいるTIBCOメッセージを発行し、受信するためのAPIを提供する。それは、数種類のメッセージ挿入、更新、削除、再同期、バージョン同期およびハートビートおよびこれらのメッセージを発行し、受信するためのインターフェースとオブジェクトを定義する。それは、メッセージが受け取られる際にどんな動作がとられるべきか、とか、発行されたメッセージの内容の出所については、定義しない。これは、クライアントのDDSエンジンによって定義される。具体的なメッセージクラスは次の6つありうる。InsertMessage挿入メッセージ、UpdateMessage更新メッセージ、DeleteMessage削除メッセージ、ResyncMessage再同期メッセージ、VersionSyncMessageバージョン同期メッセージ、HeartbeatMessageハートビートメッセージ。コントローラクラスには、次の2種があり得る:InboundControllerインバルンドコントローラおよびOutboundControllerアウトバウンドコントローラ。これらのコントローラは、メッセージの聴取/発行を司る。メッセージの処理/生成をカスタマイズするためにコントローラと共に登録できるインターフェースがいくつかありうる。これらには、ChangeCommitterチェンジコミッタ、ChangeFactoryチェンジファクトリおよびLastVersionFactoryラストバージョンファクトリが含まれる。分散ビジネスオブジェクトの構築用のフレームワークが必要である。このフレームワーク上に構築されるビジネスオブジェクトは、該ビジネスオブジェクト開発者によって最小の努力でDDSの以下の態様をサポートしなければならない。即ち、ビジネスオブジェクトを、ローカルデータベースに格納すること。ビジネスオブジェクトをXMLフォーマットに/から、変換すること。格納前/後、及び、発行前/後に通知エンジンに接続すること。効率のために、通知プロセスは、部分的にビジネスオブジェクトクラスそのものに組み込まれることができる。オブジェクトは、このプロセスで修正もしくは拒絶されうる。TIBRVメッセージにおける挿入/更新/削除の発行。総ての分散ビジネスオブジェクトは、以下の特徴を有しなければならない。それらは発行者、guid及びvidヴァージョン識別子の3つの識別特性をもっていなければならない。発信者は、オブジェクトのホームを特定するために用いられる。guidは、独自にネットワーク上の全サーバ全体に亘るオブジェクトを唯一的に識別するために用いられる。vidは、データベースを同期に保つために用いるオブジェクトのためのバージョン番号である。データベーススキーマ及びトリガセクションに、これらの分野に関する詳細なより多くの情報がある。新規な分散オブジェクトは、自動的にGUEDsを生成し、自動的に発信者をセットしなければならない。それらはまた、VIDサービスからそれらの唯一的なVIDを獲得しなければならない。更新された分散ビジネスオブジェクトは、VIDサービスから自動的に新しいVIDを得なければならない。分散ビジネスオブジェクトは、それらが局所的にまたは遠隔で起こったかどうか決定することが可能でなければならない。分散ビジネスオブジェクトは、データベースに自身を格納することが可能でなければならない。これは、既存のデータベースオブジェクト持続フレームワークに基づく。それらのGUIDに基づいて分散オブジェクトを調べることが可能でなければならない。この機能性は、旧式のデータベースオブジェクト持続フレームワークに基づく。データベースオブジェクトからの他の静的検索方法もまた、機能し続けなければならない。分散ビジネスオブジェクトをXML形式で表現することが可能でなければならない。全分散オブジェクトで利用可能なデフォルト反射ベースの方法があるが、個々の種類の分散オブジェクトはカスタムメイドのDTDを使用しているこの挙動を越えるように望むことも可能であるXMLから分散ビジネスオブジェクトを初期化することが可能でなければならない。全分散オブジェクトで利用可能なデフォルト反射ベースの方法があるが、個々の種類の分散オブジェクトはカスタムメイドのDTDを使用しているこの挙動を越えるように望むことも可能である。分散オブジェクトの各々のタイプが唯一的なタイプ名デフォルトでは、クラス名およびタイプバージョン番号を含まねばならない。当該オブジェクトのためのXMLスキーマが変化するいかなる場合も、このバージョン番号は、増加しなければならない。このタイプバージョン番号により、バージョンの不適当な組合せを検出し、自動的にバージョントランスレータを発見することが可能となる。変換器群がネットワークで利用可能であって、当該タイプバージョン番号は正しく定められている場合は、このプロセスは自動的に起こることになる。遠隔シンクロナイザがバージョンに関するコンフリクトを解決することができるように、タイプ名およびタイプバージョン番号が、DDSエンジンによって作成されるTIBRVメッセージに加えられなければならない。分散ビジネスオブジェクトが格納前/後、及び発行前/後で通知エンジンと通信しなければならない。該通知エンジンは、ローカルオブジェクトに対する変化を拒否して、ローカルオブジェクトに修正をすることが可能でなければならない。これらの通知動作は、独立型通知エンジンに向かって対話するというネットワークのオーバーヘッドを避けるために、分散ビジネスオブジェクトのクラスに登録されることも潜在的に可能であろう。レガシーデータベースオブジェクトコードに必要な変化が最小であるような方法で、分散オブジェクトは実行されなければならない。フレームワークの一図解例を図5のクラス線図に示す。システムによって定義される分散コミュニティの重要な側面は、それがピアツーピア方式で作用するために、各々がシステムの協同サービスオブジェクトを格納し、その役割を果たすということである。基盤インフラストラクチャサービスは、これらのオブジェクトがコミュニティの中で安全に、かつ、能率的に配信されることを確実にするための機構を提供する。このシステムは、ワールドストリートネットのオブジェクト及びリクエストの内部トラヒック対応のインフラストラクチャサービスに向けるためのマネージャとして作動する往復の束サービスを含むことができる。各々のインフラストラクチャサービスは、ほとんどいかなるシステムオブジェクト例えば束、ユーザ、プロフィールまたはディレクトリにも適用されうるサービス群を提供する。これらのインフラストラクチャサービスは、以下の通りである。オブジェクト複製および同期サービスは、特定のグループ内で作動しているサーバの総てがそれらが必要とするオブジェクトの正しい一組によって最新に保たれることを確実にする。例えば、集約サーバは、ディレクトリ内で一組のユーザを所有することができる。変化が局所的な場合、当該変化は、この情報にアクセスできなければならない他の総てのサーバに対する複製である。束検出及び検索サービスは、必要なときに、束を最適にとってくる役割を果たす。検出サービスは、束があるかもしれない場所を、それが外部であれ、ローカルキャッシュ内であれ、決定し、適切なセキュリティステップを与えることで、正当権限ある者のみが束コンテンツへアクセスできるようにする。この束内容コンテンツは、発行者とのオンデマンド対話によって取り扱われることができるか、または生きているアクセス期間にもとづくようにしてもよい。ルート最適化は、必要な資源にアクセスするのに最適なネットワーク経路が選択されることを確実にする。各々の集約サーバは、ホップ、音カウントおよび物理的な接続タイプに由来するネットワーク発見的教授法を含んでいる動的なネットワーク経路テーブルを維持する。管理人は、明確に好適な経路を定め、例えばある特定の種類のトラヒックが個人的なネットワーク上のみを流れるように定めることができる。内容混合サービスは、束タイプ、著者発行者、受取人、転送先の装置または他の基準に基づいてカスタムメイドのコンテンツコレクションを作成するために束場所および検索サービスと相互作用する。内容混合サービスは、例えば様々なプレゼンテーションのためのカスタムテンプレート、外部サービスからの特定コンテンツ要求、あるいは、オリジナルの束内でのコンテンツの削除または置換といったものを含むことができる。内容混合の目的は、瞬間的な決定をするのに必要な全情報を受信者に配信するアイデアに対して文脈を形成することである。データ互換性および変換サービスは、異なるバージョンのシステムがDTDの現在の各種セットと相互にやりとりできる能力を提供する。XSL変換を用いることで、XML文書全部の束及びメタデータがこれに当るは、この集約サーバ上で動作するある種バージョンのサービスに必要な方言に翻訳されることができる。その上、これらのサービスは会社内での使用のためにDTDを拡張して利用することで、会社は財産性ある情報を社内使用用として含めつつ外部には公開されないように落とすことができる。電話通信およびメディアサービスは一まとまりの第三者ソフトウェア例えばマイクロソフトMediaServer登録商標およびEnvox登録商標、及び、ハードウェア例えば対話的電話通信カードであり、これらは束コンテンツに対し統合音声メッセージサービス及びストリーミングメディアサービスを提供する。これらは、束XMLの範囲内で埋め込まれる特定のタグを経由して束に織り込まれる。統計エンジンも、外部の会計システムに支払い請求サービスデータを提供する。統計エンジンは、ユーザがいつ束を発行し、いつ束を要求したかを検知する往復束サービスをメタデータが通過するのを通じて、束の活動を追う。この情報は次に統計データベースの範囲内で集計され、このデータは支払い請求目的のためのホスト対象サービスと共有される。図6は、オブジェクトが物理的にあるデータベースに接続される方法を示す。注意すべき重要な点としては、グローバルにユニークな識別子GUED及びバージョン識別子VIDの作成が全体処理の一部分として、データベースの範囲内で実行され、VTDsが無駄にならないことを確実にするということである。一旦記録がうまくデータベースに書き込まれると、メッセージは変化を公表するシステムコミュニティに発送される。図7は、これらの変化が他の集約サーバに発信される過程を例示する。これはすべてが予想通りに起き、シーケンスを外れる情報がない場合の典型的ケースである。オブジェクトに変化を通知するオブジェクトは、当該オブジェクトの所有者になる。というのは、このようなオブジェクト所有権は、財産権的情報を許可を得ない者が編集するのを防止するために、許可証として付与したり無効にしたりできるようにするからである。図8は、オブジェクト変化情報がシーケンスを外れて受け取られる場合のシナリオを例示する。これは、オフラインで動作するかまたはコミュニティ内から一定時間切断されているサーバの結果であってもよい。メッセージがシーケンスから外れて受け取られると、これにより受取人の転送サービスが起動し、受信していなかった可能性のある全変化を要求する。発行サーバのもつ転送サービスは、転送メッセージを一時的に一列に並べ、多数のサーバが一斉に同一の転送シーケンスを要求したとしてもネットワークからあふれないようにする技術を備える。図9を参照すると、システムオペレーションは非信頼相20とそれに続く信頼相22という2つの全体的な位相を含むことができる。非信頼相の間は、買い手側ユーザは、自身との間で信頼関係を結ぶのを奨励するために売り手側ユーザに勧誘状招待状を送ることができるステップ24。同時に、売り手側ユーザは、ネットワーク上の売り手側プロバイダを捜すためのネットワークディレクトリツールを使用することができるステップ26。そして買い手側および売り手側ユーザは、信頼関係を結ぶことができるステップ28。信頼相22の間、売り手側ユーザは、一以上の買い手側ユーザに対して束を準備して、送るステップ30。これらの束がユーザのプロフィールにおける設定にかなう場合、ユーザはその束を受信するステップ32。次にユーザは、束と関連する情報をチェックし、システムを通じて、或いは他のチャネルを介してこの情報に応答することができる。信頼相において、ユーザはインフラ機能へのアクセスを獲得する。この相の範囲内でさえ、信用について段階が存在し得る。その結果、特定の関係には限定的な機能のみが利用可能である。信用は、いずれの関係者のオプションでも制限づけることができる。非信頼相の間、ユーザは勧誘を通して情報交換を行う。例えば、販売員は特定の会社での買い手側連絡先の総てに対し勧誘状を送信するかもしれない。そのユーザは、その会社で自身がやりとりする全個人に対し、名刺を作り上げ送信することによってこれを行うことができる。当該関係の創始者は、彼女の束の品質のサンプルとして、一つ以上のすでに既存の束を勧誘状にリンクする能力を有する。受取人は、勧誘を受領し、結果として生まれる関係に異なる関係レベルを与えることができる。これらのレベルは、情報量および関係存続の間受け取られる束に用いられる通知種類に影響を与えうる。2段システムにおいては、勧誘状の発信者との関係を承認する。しかしながら、受取人は発信者から無関係な情報を受け取りたくないので、関係を承認しても優遇連絡先特権を与えない。システムは、また、ディレクトリ中のあらゆる会社で他の総てのユーザに関する情報を全ユーザが閲覧できるようにするディレクトリ検索ユーティリティを具備することができる。関係を拒絶する異なる方法があり得る。第一は、最終的拒絶として知られている。このような方法で拒絶を発行することにより開始者が再び受取人に勧誘状を送るのを防止できるが、拒否者は必要に応じて関係を始めることができる。非恒久的拒絶タイプは、創始者が所定の期間の間の勧誘状を送るのを防止する。受取人は、関係を評価する機会をもったあとで関係を終了することができる。図10を参照して、システム10によって提供される拡張可能なアーキテクチャフレームワークを使用して実行されうる図示のユーザインターフェースアプリケーションについて説明する。このユーザインターフェースアプリケーションが投資情報サービス産業のために最適化されると共に、多くの他のシステムは他の種類の団体例えば他の産業、政府系組織または非営利団体のために開発されることができる。例えば、この種のシステムが供給チェーン管理のために開発されることができたことが考察される。ここでは、原料および準組立体の提供者はそれらの最終製品に興味がある製造者と相互にやりとりすることができる。他のシステムの組織、特徴集合およびユーザインターフェースがそれらの意図された使用と整合している様々な点において提示されるものと異なることができるにもかかわらず、この種のシステムはまだ本出願において示される原理から利益を得る。実施例に示すように、ユーザインターフェースが自身の端末で作動するアプリケーションにより提供され、会社のアプリケーションサーバによって提供されるXIAとやりとりする。XIAが明確に規定されたプログラムインターフェースを示すので、異なるユーザインターフェースアプリケーションは異なる種類のシステム、異なる会社または異なる人事機能のために容易に設計することができる。加えて、複数のアプリケーションは、いかなる特定の時間においてもXIAとやりとりし、システムとの異なった、あるいは、多数の豊富な特徴を有するやりとりをすることができる。本実施例において、ユーザインターフェースアプリケーションは、管理組織によって供給され、維持される。買い手側ユーザ例えばAlが新規な束を受信すると、束がユーザのフィルタを通過する場合、ユーザインターフェースアプリケーションにより、当該ユーザ端末には短い間隔例えば10秒で新規の束警報ウィンドウ40が生じる。ユーザインターフェースアプリケーションはXIAからの通知に応答してこのウインドウを表示する。そして、それは以下の情報を含むことができる:束ID、束タイプ、会社名、会社ID、受信日時、ティッカー、見出し、非ボイスメール添付ファイルの存否、ボイスメールがある場合ボイスメールID、当該束がユーザのフィルタを通過するか否か。新規な束ウィンドウは、時間領域42、発信者識別領域44、ヘッドライン領域46、ボイスメールアイコン48およびティッカー領域50を有する。ユーザがヘッドライン領域をクリックする場合、システムは束を開く。ユーザが本実施例におけるボイスメールアイコンをクリックする場合、システムは束を開けて、ボイスメールを再生する。しかし、束を開けずに直接添付ファイルを開くことはできない。新規な束ウィンドウは、構成が可変ではなく、常に作動していて、常に同じ基準によって動作開始される。勧誘状が受け取られるときに、勧誘状が束の一種と考えられないこと、そして、新規な束警報ウィンドウが持ち出されない点に注意されたい。図11を参照する。ユーザは、システムトレイ52のアイコンを右クリックすることによって、またはツールバー56中のコントロール54を左クリックすることによって、ユーザインターフェースアプリケーションの異なる一部を呼ぶことができる。異なるパーツは、以下の機能のためのウインドウを含む:受信ボックス、送信ボックス、束作成、束発見、勧誘受信、発信、勧誘状作成、ネット、ディレクトリユーザ閲覧、ユーザ発見、自身プロフィール、連絡先リスト作成、統計および管理。タスクバーは、他の総てのウインドウの上に置かれて、画面の最上段または最下段にドッキング可能である。タスクバーの最新束ウインドウ58はフィルタを通過する最新の受領束のための時間または、本日ではないにしろ、日付、ティッカー、そして、見出しを表示する。ユーザがこの入力で左ボタンをクリックする場合、対応する束が開かれる。ユーザは、また、ユーザのフィルタを通過する最新の10の受領束を表示するウィンドウを開けるアイコンをクリックすることができる。このウインドウにおいて、ユーザはまた、各々の束についてボイスメールインジケータアイコンおよび発信者を参照することができる。ボイスメールアイコンをクリックすることにより、ユーザインターフェースアプリケーションは束を開けて、直ちにボイスメールを動かすことができる。最新の束ウインドウのために、勧誘状は束の一種とみなされず、そして、ユーザが勧誘状を受け取るときに最新束ウインドウは更新されない。これらの特徴を実装するために、ユーザインターフェースアプリケーションはいつ新規な束が受け取られるか、そして、それがユーザフィルタを通過するかどうかについて通知されることを必要とする。変化がある場合、あるいは、スタートアップのときには、ユーザインターフェースアプリケーションはユーザのフィルタを通過した10の最も最近の束について、詳細を入手することが可能である必要がある。これらの詳細は、束ID、見出し、ティッカーシンボル、いつ束が受け取られたか、当該束と関連するあらゆるボイスメールのボイスメールID、発信者名および発信者IDを含みうる。図12および13を参照する。ユーザは、ツールバーまたはシステムトレイを通して受信ボックスウインドウ60にアクセスすることができる。このウインドウは、作成制御62、削除制御64、検索制御66、グループ化制御68、及び、フィルタ制御70を含む。作成制御についてのオプションは束作成及び勧誘状作成であり、これらによりシステムはそれぞれ、束作成ウインドウ図16参照及び勧誘状ウインドウ図19参照を用意することができる。グループ化制御のためのオプションにより、受信ボックスは、多くのオプションに則って、組立式概略図にグループ化できるが、当該オプションには次のものが含まれる:非グループ化、発信者によるグループ化、会社によるグループ化、セクタによるグループ化、ティッカー図13参照によるグループ化およびタイプによるグループ化。フィルタ制御によりユーザは、フィルタ機能をオン/オフすることが可能になる。検索ティッカー制御は検索選択ボックスに拡大することができ、ここでは当該オプションは発信者検索、会社検索、セクタ検索、或いは、ティッカー検索である。新規な束が到着するか、或いは、束が撤回されるときに、受信ボックスは可能ならば自動的にリフレッシュされなければならない。本実施例においては、欄はクリック仕訳可能であるが、ユーザがティッカー欄、添付アイコン欄、ボイスメールアイコン欄または削除チェックボックス欄のためのヘッダをクリックしても、何も起こらない。フィルタが動いている場合、ユーザインターフェースアプリケーションの示す束は、関心先リストにマッチする束、第一順位発信者によって送信された束または応答であった束である。受信ボックスインボックスに示される各々の束のために、ユーザインターフェースアプリケーションは、受信時間、タイプ、対応ティッカーシンボル、非ボイスメール添付アイコン、ボイスメールアイコン、見出し、発信者名および会社名を表示する。束タイプボタンをワン左クリックすることで、ユーザインターフェースアプリケーションは束タイプウインドウによって受信ボックスグループを表示することができる。一度ティッカーシンボルボタンをワン左クリックすると、ユーザインターフェースアプリケーションはユーザに特定のティッカーシンボルを選ばせるポップアップメニューを表示でき、ユーザが1つを選ぶときに、ユーザインターフェースアプリケーションは、当該ティッカーシンボルのための受信ボックスティッカー検索結果ページを示す。ボイスメールアイコンボタンをワン左クリックすると、システムは束を開けて、直ちに音声メールメッセージを奏でる。見出しボタンを左クリックすることで、束詳細ウィンドウ図15参照が開く。発信者名ボタンをワン左クリックすると、システムは受信ボックス発信者検索結果ウインドウを用意し、会社名ボタンをワン左クリックすると、システムは当該会社用の受信ボックス会社検索結果ウィンドウを用意する。連絡先リスト、セクタまたはティッカーによりグループ化することは、それぞれいかなるセクタにもタグ付けされない束および、それぞれいかなるティッカーにもタグ付けされない束のための特別な群が存在することを必要とする。主要部門および副次部門の両方がある場合であっても、部門によるグループ化は、1段階のみのグループ化に結果としてなる。副次的なグループは、図形見出し例えばコンピュータハードウェアをもつ主要グループ内で分離される。発信者によるグループ化により発信者欄は消え、会社によるグループ化により会社欄が消え、束タイプによるグループ化により束タイプは消えるが、ティッカーによるグループ化が行われてもティッカー欄が消えるわけではない。見方によっては、束は二回以上現れることができる。これらは、以下の通りである:ティッカーによるグループ、関心によるグループ、連絡先リストによるグループ、会社によるグループおよびセクタによるグループ。グループ化は、本実施例においてはXIAではなくユーザインターフェースアプリケーションによって取り扱われる。デフォルトでは、検索ボックスは空であり、グループ化は存在せず、フィルタは動作している。検索ボックスが空であって、ユーザがグループを変える場合でも、フィルタは変化せず、図は直ちに更新される。同様に、検索ボックスが空でユーザがフィルタ原因を変更する場合でも、グループは変化せず図は直ちに更新される。ユーザが検索ボックスに検索文字列を入力することによって検索を要請する場合、該検索文字列がXIAに送信される前に、会社ファインダ、セクタファインダ、人間ファインダまたはティッカーファインダはユーザに1つの会社、セクタ、発信者またはティッカーを正確に特定することを強制する。結果がXIAから戻るときに、該グループは束タイプによってセットされ、フィルタは動作しているままにされる。するとユーザは、グループ化を変更し、フィルタをオフにすることができる。束の数は、受信ボックスの左下角に表示される。しかし、例えば、ティッカーによるグループ化のときには、束は二回以上現れることができる。束のはっきりした数は、このような場合に表示される。総ての検索は、確認のためのXIAに送信され得る。検索が正確に1つの目標にマッチする場合、値がXIAから戻され、メッセージを検索するためにさらにXIAに送り返され得る。検索が多数の値を返す場合、検索結果ページはそれらを表示し、ユーザに特定の項目を選ぶことまたは検索をキャンセルすることを強制する。表2は、受信ボックス機能を取り扱うためのユーザインターフェースアプリケーションが利用できる一連の呼び出しの一覧を示す。示される実施例で産業に特有の機能によってはユーザインターフェースアプリケーション内の好適な場所でなくXIAの範囲内に含まれる点に注意されたい。図14を参照する。送信ボックスウィンドウ76が多くの点で受信ボックスウインドウと類似するが、例外は束が送信ボックスから削除できないが、その代わりに撤回することができるという点である。受信ボックスにおいて、システムは一人の発信者を示すが、送信ボックスではシステムは多数の受取人を示す。受信ボックスは受信日を示す一方で、送信ボックスは送信日を示す。送信ボックスメッセージはフィルタリングされない。送信ボックスは、会社、セクタ、ティッカーおよびタイプによってのみグループ化される。システムは送信ボックスに、束の状況表示を示す。会社図においては、送信ボックスは、束の発信者の会社によってではなく受取人の会社によってグループ化を行う。送信ボックスには束検索テキストボックスはない。ユーザが束を撤回しようとするときに、様式警告ダイアログが表示される。ユーザが束を送信するかまたは撤回するとき、送信ボックスウィンドウは開いていれば更新される。しかし、ユーザはユーザインターフェースアプリケーションから撤回を要請したと推定されるので、XIAからの通知なしで送信ボックスウィンドウの更新が可能でなければならない。各々の束のためのXIAから受け取られるのは以下の情報である:束ED、束タイプ、見出し、送信日、受取人リスト名前およびIDのもの、受取人の会社のためのIDのリスト、受取人の会社の略称のリスト、ティッカーリスト、セクタ、ボイスメールIDのリスト、非ボイスメール添付ファイルIDのリストおよび状況。送信ボックスと呼ばれている機能は、送信される総ての束の非グループ化ダンプの返還を要求することができる。束撤回userID、bundleIDListとよばれる機能は、束の集合の撤回を要請することができる。図15を参照する。束詳細ウインドウ80は、ブランド名刺領域82、受信日付領域84、ティッカーシンボル領域86およびセクタ領域88を含む。また、束タイプ識別子90、テキスト領域92、ネットワーク位置領域94、地方領域96および国領域98も含まれる。添付領域100は提供されたボイスメールおよび非ボイスメール添付ファイルに提供され、応答および転送ボタン102、104も同様に提供される。束詳細ウインドウが表示されている束が転送されている場合、ユーザは詳細ウインドウから転送されている束を見たければ、それをしっかり開けなければならない。こうしなければならないのは、被転送束の検索は別の請求対象イベントであるためである。転送された束に対し、ユーザインターフェースアプリケーションは、ユーザがクリックすれば転送されている束を開くことができるアイコンを添付領域に表示する。詳細ウインドウが表示されている束がユーザが送った束に対する応答である場合、ユーザは原物の束にもたどり着くことができるが、ユーザは添付ファイルセクションから明確にそれを開かなければならない。本実施例においては、束詳細ウインドウは、作成日付を表示するが、失効日や送信日は表示しない。束が転送不可能な場合には、転送ボタンは灰色に反転表示されることができる。名刺領域をクリックすることで、ユーザインターフェースアプリケーションは、発信者のための名刺詳細ウインドウを表示する図22参照。添付ファイルまたはボイスメールをクリックすることで、ユーザインターフェースアプリケーションは、適切な関連プログラムと共に該添付ファイルまたはボイスメールをスタートさせる。本実施例においては、このウインドウには削除ボタンがない。そして、束の他の受取人の名前は表示されない。ユーザがこの束の発信者である場合であっても、該ユーザは本実施例におけるこの束の受取人を表示することが可能でない点に留意されたい。束が転送可能な場合に限って、ユーザは束を転送することが可能である。ユーザは、自分の束に応答することが可能であり、撤回ボタンもある。図16を参照する。束作成ウインドウは、その下部に添付セクションを有する。該セクションは左側に、転送させている束か応答されている束かを表すアイコンと共に、各添付ファイル用アイコンボイスメールおよび文書を有する。ユーザは、消去したい添付ファイルを選んで、消去ボタンを押下することによってボイスメール添付ファイルまたは文書添付ファイルを削除することができる。次にユーザは、国、地方およびセクタテキストボックスのための見出しをクリックして適当なピッカウインドウをあげることができる。ユーザは、また、ティッカーを調べることができる。ユーザも、受取人リストを記述するための人間ピッカか人間ファインダかを使用する選択肢を有する。ここで、人間ピッカおよび人間ファインダは、ユーザが、自身が関係を有する人々を選べるようにのみ設定することができる。ボタンはユーザが添付ファイルおよびボイスメールを添付できるようにし、テキストボックスはユーザがURLを入力することができるようにする。束に応答するときに、地方、国、セクタおよびティッカーは最初のメッセージから継承されるが、それらは編集できない。ユーザは受取人リストを編集することができない。応答を得ることができるのは発信者のみである。見出しは編集されることができない。見出しは原見出しにRe:をプラスした形でなければならない。本文および添付ファイルのみが編集できる。応答メッセージは原メッセージの添付ファイルを継承しない。つまり応答メッセージの受取人は最初のメッセージをオープンすることによって添付ファイルを捕えることが可能である。束を転送するときにユーザは、束が転送されていることを表すアイコンと、見出しのFWD:接頭辞を除いて、何でも編集することができる。しかし、地方、国、セクタ、ティッカーおよび見出しは、転送されている束から得られる値にまで初期化される。その束がメールに対する応答である場合、元のメールは添付ファイルセクションのアイコンとして現れる。同様に、束が転送されている場合、転送されている原本は左下隅のアイコンとして現れる。いずれにせよ、このアイコンは削除できない。図17を参照する。勧誘状受け取りウインドウは、受け取られる勧誘状の一覧を示す。それは、含むことができる勧誘状作成及び束作成まで拡大する作成メニューと、受信ビュー及びに送信ビューに拡大する受信ビューメニューを含み得る。承認ボタン及び拒絶ボタンによりユーザは、勧誘状を承認し拒絶することができる。優先承認ボタンはまた、優先関係を形成するために提供されることができる。図18を参照する。送信済勧誘状ウインドウもまた提供される。そこには、ユーザに勧誘状を作成して、無効にして、返事を見ることを許容する制御が含まれる。このウインドウは、ユーザが勧誘状を作成し、無効にする際に、自動的に自身を更新することができる。図19を参照する。勧誘状作成ウインドウは、ユーザが勧誘状を多くの人々に宛てるのを許容するが、システムは各々の受取人のための1枚の別々の勧誘状を作成するわけではない。当該ユーザは、人間ピッカや人間ファインダを用いて、人々を勧誘状に加えることができる。人間ピッカおよびファインダは、ユーザに関係を有しない人々を選ぶことを強制するように設定することができる。図21および22を参照する。ツールバー上のディレクトリエントリを選ぶことでユーザは、発見か閲覧制御を選択することができる。閲覧を選択すると、システムはアドレス帳を持ち出す図20。検索を選択すると、システムは人間ファインダを持ち出す図21。このウインドウによりユーザは、名前の一部分を入力し、誰かを検索結果から選択して、その人のためのユーザ詳細ページへ行くことが可能となる。アドレス帳ウインドウについては4つのビューがある。これらには、ディレクトリによってフィルタされたビューが含まれるが、このビューは次のユーザ群を対象とする:全システム関連、個人的関係先、個人的連絡先リストおよび非関係先。ウインドウの左側において、システムは樹を表示する。この樹の最高レベルは、総ての会社のリストである。会社はアルファベット順に並べられる。但し、ユーザの会社は最上部にくる。会社は社内のグループに拡張可能である。そのグループは各グループ内のグループにまで拡大可能である。ユーザはこの樹には現れない。しかしユーザはこの樹から、会社またはグループを選ぶことができる。グループを選ぶと即座に、当該グループのユーザ全員が右側に現れる。会社を選ぶことで、いかなるグループにも割り当てられなかった当該会社内のユーザ全員が右側に現れる。個人的関係先ビューはシステムディレクトリビューと概略同じだが、システムが提示するのはユーザと関係を有する人々にのみ、ユーザと関係を有する人々を含むか、示されなければならないサブグループを有するグループ、及びユーザと関係を有する人を擁する会社のみである、という点のみが異なっている。非関係先ビューはシステムディレクトリビューと概略同様だが、システムが提示するのは、ユーザとの関係を有する人々、ユーザとの関係を有しない人々を含むか、または、提示しなければならないサブグループを有するグループ、ユーザとの関係を有しない人を擁する会社だけである、という点のみが異なっている。個人的連絡先リストビューは、左側のユーザの連絡先リストにある名前のフラットリストを有する。ユーザが連絡先リストを強調表示する場合、その連絡先リスト上の人間は右側に現れる。総てのビューは、人間、グループおよび会社によって色分けされうる。ユーザが関係を有する人間は緑に色分けされ、そうでない人間は赤に色分けされる。緑のサブグループまたは緑のユーザを含むグループは緑に色分けされ、そうでないグループは赤に色分けされる。ユーザがある会社のメンバーと関係を有する場合、その会社は緑に色分けされ、そうでない場合は赤に色分けされる。ユーザがある連絡先リストのメンバーと関係を有する場合、その連絡先リストは緑に色分けされる。ユーザは、右側の多数の人間を強調表示することができる。誰も強調表示されない場合、または、強調表示される者がユーザとの関係を有する場合、勧誘ボタンはグレイアウトされることができる。誰も強調表示されないかまたは多数が強調表示される場合、詳細ボタンがグレイアウトされることができる。人間ピッカは、アドレス帳に類似したインターフェースを使用する。図22を参照する。名刺ウインドウは、各々のユーザのために提供されることができる。このウインドウは、ユーザが関連する会社の識別子例えばロゴおよび個人に関する情報を提供する。コントロールもまた、受け入れるフィルタを決めるために、或いは、ユーザからの束を拒否するために、提供されうる。関係開始および終了コントロールもまた、提供されうる。例えば、ユーザが名刺詳細ビューにおいて識別されるユーザとの関係を有する場合、関係終了ボタンが表示されうる。関係が存在しない場合、勧誘ボタンが表示されることができ、このボタンによりユーザは、受信ボックスに予め入れこんだ形で勧誘状作成ウインドウに導かれうる。図23を参照する。関心ウインドウは、名刺ビューからアクセスできる。このウインドウは、検索およびフィルタリングのために使われることができる一連の関心カテゴリ値を含む。この情報の中には、ユーザ優先命令および/またはシステム設定に基づき、ユーザとの十分に緊密な関係を有しないユーザが利用可能でないものもあるし、全情報がそのように利用不可能なものかもしれない。したがってこのウインドウによりユーザは、対象とされたユーザグループに対する興味に係る安全な量の情報を公表することが可能となる。図24を参照する。活性度の高い画面は、異なるメトリクスのための最活発な組織を示す。本実施例においては、これらは上位ティッカー、上位セクタ、上位発信者および上位企業を含む。この種のウインドウにおいて表示される統計は、集約サーバが集めるシステムで起こる処理の数についての統計に基づく。類似ビューは、発行およびカバレージギャップのために用いられることができる。公開統計はシステムの活用量に関する情報を提供し、カバレージギャップ統計は企業間のサービスレベルを比較する情報を提供する。フル機能のユーザインターフェースアプリケーションはまた、多くの追加的なウインドウを含むことができる。これによりユーザおよび管理者は、情報を入力して、値を選んで、好みをセットし、さもなくばシステムを制御しシステムとやりとりすることができる。上記に提示したウインドウは例示を目的とするものであり、これらのウインドウの正確な構成は、本発明に利用可能な特徴に実質的に影響を与えることなく変更することができる。ここで示される実施例において、追加的なウインドウは、以下の主題に関することができる:関心先、連絡先リスト、束、個人プロフィール、名刺エディタおよびパスワード変更、関心先リストマネージャ、概要、一般、ティッカー、セクタ、地方、国、連絡先リストマネージャ、統計、最活発、公開、カバレージギャップ、管理ユーザ管理、企業ディレクトリ、ユーザ追加/編集一般、ユーザ追加/編集許可、ユーザ追加/編集グループ、ユーザ追加/編集関心先、管理管理会社、グループディレクトリ、束満了、管理束管理、束管理、参照データファインダおよびピッカ、ティッカーピッカ、セクタピッカ、領域ピッカ、国ピッカ、ユーザ役割セレクタ、及び、束タイプセレクタ。プロフィールがユーザインターフェースアプリケーションからXIAに対して与えられるので、これらは集約サーバに提供される前に自動的に更新されうる。この能力を使用すれば、ポートフォリオ管理システムは、例えば、集約サーバのプロファイリングシステムに直接結ばれることができる。この種のシステムによりプロフィールは、自動的に更新され、位置が確立され監査されるので、情報フローが常に関連性を有することが確実になり、時間のかかるプロフィール保守が除かれる。取引が、例えば、会社型投資信託で行われるので、ファンドのプロフィールは自動的に更新される。それで、ファンドがACME社の株の総てを売却すると、そのプロフィールにはACME社の記載はもはや含まれない。システムのユーザインターフェースがソフトウェアベースのグラフィカルユーザインターフェース要素に基づいているので、それは、他の方法によって、例えば物理的作動制御または聴覚指示メッセージを使用して実行してもよい。該ユーザインターフェース要素の機能と構造は、要素を適宜、結合、分離、作り直すことで、図に示すのとは異なる方法で分解することもできる。そして、システムのユーザインターフェース要素がウインドウに表示されるので、いわゆる当業者であれば、他の種類の表示領域例えば画面、カードまたはページに表示可能であると認識するだろう。特定のデータ――特に、システムと相互にやりとりするアプリケーションを通してダウンロードすることができる束を記載しているメタデータ――が配信される。すなわち、それは様々なサーバに接続される。データが多数の場所において複製される状況においては、以下の問題の起こる可能性がある。データは複数の場所において、または、複数の人によって編集されることができる場合は、2人の人々が同時に同じデータを編集する際に編集衝突が起こる可能性がある。データが編集される際は、該編集がさまざまな二重のサイトに配信される時間のずれがありうる。よって、異なるサーバにおけるデータの使用者は、つじつまのあわないデータをもとに動いていることもありうる。サーバが故障するか、さもなければ編集を受信することができない場合は、サーバは、誤ったデータを保持していることを認識でき、誤ったデータを伝播させることなく正しいデータに時宜よく回復させることが可能でなければならない。システムは、その分散データベースサービスを介してこれらの問題に対処する。配信されたデータは、このソフトウェア層を通じて管理される。あらゆる共有データオブジェクトは、創始サーバ、即ち、所有者であるホームを有する。所有権はサーバ間で譲渡されることができるが、所有者が複数ということはない。所有者だけがオブジェクトを編集することができる。所有者のサーバは、1つのアプリケーションだけまたはユーザだけが一度にオブジェクトを編集することができることを保証しているロッキング機構を備えている。その結果、同時編集による衝突は決してありえない。あらゆるデータオブジェクトは、唯一的な128ビットの識別子を有する。この識別子は、データオブジェクトの身元というだけでなくデータオブジェクトのバージョンも含む。加えて、異なる種類のデータオブジェクトのために、あらゆるサーバは、バージョン識別子を保持する。この識別子は、サーバ及び、そのデータ型にあてはまる総てのデータのバージョンに特有である。データオブジェクトが編集されるか、加えられるか、または削除されるかするときはいつでも、サーバのデータオブジェクトバージョン識別子は1増加する。これらのサーバデータオブジェクトバージョン識別子は、規則的な鼓動でもって概して5秒ごとネットワーク上同報される。ネットワーク上の他のサーバは、それらが各データオブジェクトタイプについてあらゆるサーバから成功裡に受け取ったバージョン最新版の記録を保持し、共有データオブジェクトの変化を捕捉しきれなかった場合には、バージョン識別子からそれを認知することができる。ホームサーバを有する場合、ホームサーバに最後の成功更新に係るバージョン識別子を通信する。するとそれらは、該ホームサーバから総ての失われた最新版を受け取る。更新は典型的には、ネットワークバンド幅を節約するために、全オブジェクトの完全な転送とはせず、編集何が変化したか指し示すこととしてのみ伝達される。その結果、該オブジェクトが正しく保存されることを確実にするために、更新版は常に正しい順序で実行されることになる。たとえば、旧式のサーバが、最後に、創始サーバ20635232146からデータ型4の状態37を受信し、状態44がそのデータ型には最新であることが鼓動からわかったとしよう。するとそれは、変化38、39、40、41、42、43および44を要請して、データ同期を回復するために、順番にそれらを実行するであろう。データは、集約サーバのローカルグループへの、または集約サーバのあらゆる中間関連物への配信において制限されることができる。たとえば、スケーラビリティ、パフォーマンス、グローバルネットワークトラフィックの最小化または他の理由のために、単一の会社は多数の集約サーバを有することを望むかもしれない。この種の場合、分散データベースサービスは会社の集約サーバの範囲内で所有データと同期させるために用いる。交換集約サーバのサブセット全体にわたって同期されうる所有データの例としては、プロフィール及び注視リストを含む。その結果、ユーザは会社の集約サーバのいずれかを通じての交換にアクセスすることができる。本発明によるシステムは、標準のメタデータタグ、即ち事業言語定義BLDを使用することができる。各々のBLDは多数の値を含む特定の値を有しうる特定のキーワードである。キーワードに添付されうる値は、コミュニティ合意によって標準化されていてもよい。たとえば、証券業に供すべく定められるBLDは、セクタ、ティッカー、領域および国を含む。例えば、ロイター計測器コードRICsがセキュリティ識別子株の場合はティッカーとして使われることができるが、こうすることで、典型的メタデータタグはTickerAOL,AON,MSFT,INTCであってもよい。いったんBLDが規定され、当該キーワードがネットワーク全体にわたって特定の目的のために保持されると、統計エンジンが、このキーワードおよび特定の値を含んでいる束に応答するユーザの挙動のみならず、当該目的と関連するこのキーワードおよび値の使用に関する統計を集めるために統計エンジンが動作を開始する。もちろん、ユーザは専用のタグをそれらの束に加えることができる。統計エンジンはこれらの非標準キーワードの使用に関するデータを集めることができるが、キーワードの使用を分析する能力は制限される。全産業のキーBLDには、発信者、企業及び束タイプが含まれる。これらのキーワードに基づく統計によりクライアントは、別の発信者個人もしくは企業の活動及び成功をトレースできる。証券業のためのキーBLDは、ティッカー、セクタ、地域および国である。アプリケーションが束を作成するか、修正するか、またはダウンロードするときはいつでも、使用データは連続的に集められる。統計エンジンは、ほぼリアルタイムで使用データを集めて、統計的断片、すなわち活動の概要を作成する。次にこの活動は、適応するアルゴリズムに従ってコミュニティ会員に配信される。例えば、会員の中には、全統計を購読した者、限定的な統計を購読した者、或いは遅延版もしくは概要版統計を購読した者もいるかもしれない。統計は大きく分けて、2つのタイプ、即ちリアルタイム及びヒストリカルがある。リアルタイム統計は、現在の活動すなわち、直前1時間、直前一日、或いは直前10分間のスナップショットを提供する。それらは、周期的に、たとえば10分ごとに、更新されることができる。統計的断片の実施例には、各BLDキーワード用に最も頻繁に発行された値および各BLD用に最も頻繁にダウンロードされた値が含まれる。例えば、BLDがティッカーである場合、MSFTが最も発行され、IBMが最もダウンロードされるかもしれない。ヒストリカル統計は、統計が時間の経過とともに変化した様子を示す。それらは、日々のパーセンテージ変化に関して、または時間の経過に伴う傾向を提示する図の形で示すことができる。統計的断片の実施例には、以下のものが含まれる:各BLDで最も動きの激しかったもの活動中のパーセンテージの最大増加分、最大減少分、昨年度一年でBLD値活動の該BLDに対する全値の発生総数に対する割合。これらの統計は、会社がそれらの商業的なパートナーの価値を判断し、潜在的パートナーを評価する手助けとして適用することができる。たとえば、証券業で、ウォール街アナリスト群のクライアントにならんと考えているポートフォリオマネージャは、例えば以下のような情報に対するヒストリカル統計を調べることができよう:それらの発行物は、クライアントによってどの位の頻度でダウンロードされたか;彼らは、熱いティッカーについての報告を発表することにおいて、競争相手をリードしたか或いは遅れたか。一旦アナリストが実際にポートフォリオマネージャに仕えると、該マネージャはアナリスト達がもたらす価値を、自社の従業員がどれくらいの頻度で該アナリストによって発表される調査報告を使っているかを見ることによって判断することもできる。会社内で、統計は従業員を評価するために用いることができる。たとえば、ウォール街のある会社は、発行の頻度によって販売員を評価するかもしれない。或いは、収益に対する従業員の生産性に係る統計を収益とリンクさせ、最も効果を生む販売員を見つけることもできよう。その会社はまた、発行物がダウンロードされる頻度によって、アナリストを評価するかもしれない。会社はまた、全体として市場を評価するために統計を使用することができる。これらは、例えば、総てのポートフォリオマネージャが何に注目しているのかについて明らかにすることができる。この情報は、会社が資源を最も有益な機会に向け直し、ほぼリアルタイムでわき起こってくる機会について知ることの助けとなる。あるウォール街の会社はまた、ポートフォリオマネージャの関心が増加したが、そのアナリストが発行した調査報告書の対象となっていない株を探すかもしれない。時間のずれも、有用な情報を表す。システムは、企業およびその競争相手に対して、公開されてから読まれるまで平均してどの位かかるかを明らかにすることができる。本発明はここでは、現状多数の本発明の特定の実施例と関連して記載されている。しかし、本発明の範囲内であると考えられる多数の変更態様は、いわゆる当業者にとって明白な筈である。したがって、本発明の範囲が本願明細書に添付される特許請求の範囲の記載によってのみ、制限されることが意図される。加えて、請求項の提示の順序は、請求項の特定の用語の範囲を制限するものと解釈してはならない。本発明による販売システムのための高水準ブロック図である。図1のシステムのためのソフトウェア相互作用図である。図1のシステムのための束の高水準ブロック図である。図1のシステムの部分ついてのより詳細なブロック図である。図1のシステムの分散型ビジネスオブジェクトの潜在的フレームワークを詳述するための実例階級線図である。図1のシステムにおけるオブジェクトをデータベースまで物理的に連結させる方法を示すブロック図である。図1のシステムの一方の集約サーバから別のサーバに変化が伝達される方法を例示するブロック図である。オブジェクト変化情報が図1のシステムのシーケンスから受け取られるシナリオを例示するブロック図である。図1の販売システムのための高水準状態線図である。図1のシステムのための新規な束警報ウィンドウの画面視図である。図1のシステムのためのツールバーおよびシステムタスクバーの画面視図である。図1のシステムのための受信ボックスウインドウの画面視図である。集合モードにおける図5の受信ボックスウインドウの画面視図である。図1のシステムのための送信ボックスウインドウの画面視図である。図1のシステムのための束詳細ウインドウの画面視図である。図1のシステムのための束作成ウインドウの画面視図である。図1のシステムのための勧誘招待状受信ウインドウの画面視図である。図1のシステムのための勧誘送信ウインドウの画面視図である。図1のシステムのための勧誘生成ウインドウの画面視図である。図1のシステムのためのアドレス帳ウインドウの画面視図である。図1のシステムのための人間ファインダウインドウの画面視図である。図1のシステムのための名刺詳細ウインドウの画面視図である。図1のシステムのための利益詳細ウインドウの画面視図である。図1のシステムのための高度活性統計ウインドウの画面視図である。a1a2...an...n1n2...zn売り手側ユーザ端末A1A2...AN...N1N2...ZN買い手側ユーザ端末s1...snS1...SN集約サーバapp1...appnAPP1...APPNアプリケーション層"