JP2008226237A - ネットワーク化された商業的やり取りの管理方法 - Google Patents

Abstract

【課題】ネットワーク化された商業的やり取りにおいて、ユーザに対する重要なフィードバックを提供し、情報の取引を可能にする。
【解決手段】複数遠隔地点の複数コンピュータ間のネットワーク経路を提供しこれらの地点での複数のネットワーク・ソフトウェア・インターフェースを提供するネットワーク・サービスを備える商取引管理のためのネットワーク・システムを提供する。該複数地点の複数コンピュータ間では束処理ロジックが用いられる。当該ロジックは、該束に係る内容属性記述子中の所定の状況を発見し、該所定状況発見に呼応して動作を実行すべしという一連の命令に応える。当該複数地点の各々からアクセス可能であって、該束処理ロジックに対する一連の命令のうち少なくとも一部分を規定するように動作可能な束処理ロジック用プログラム・インターフェースも具備される。
【選択図】図１

Description

この発明は商取引の主題に関する情報を管理するための方法及び装置に関する。

購買、アウトソーシングおよび他の産業間相互作用に関係している個人は一般に、様々な競合体から、自組織のための製品およびサービスを理解し選ばなければならない。これらの個人は現在、対面会議、論文出版物および電話対話を含む多種多様な情報源から得られる情報にそれらの意思決定の基礎をおく。彼らは、また、電子的に利用できる（例えばデータベース、プロバイダ・ウェブサイトおよびいわゆるポータル）情報を参照することができる。しかし、豊富なこの各種情報の組み合わせを収集し、管理し理解することは、苦痛をもたらす作業でありうる。しばしば、意思決定の品質は、これらの高い経費のために犠牲になる。例えば、劣ったパートナーは、より良いパートナーを求めるための高いコストを避けるための事業の関係先として選ばれることになるかもしれない。

一旦企業が処理または関係の契約を結ぶと、一般的に、情報は、個人間、ソフトウェア・システム間、及びソフトウェア・システムと個人との間で多数回に亘り交換されなければならない。これらの情報交換はまた、対面会議、論文発表および電話対話を含む多種多様な機構によって起こりうる。また、この豊富な各種情報の組み合わせを収集し、管理し、理解することは、高価でかつ時間がかかることでもありうる。そして、事業関係の質は、これらの高い経費を原因としてしばしば低下する。

本発明は、ネットワーク上のユーザ間で情報を広く共有すること、そして、これらの動作を可能にする技術的枠組に関連した多くの態様を含む。総合的な一実施態様において、本発明は、複数の遠隔地点におけるコンピュータ間をつなぐネットワーク経路を提供し、該複数地点におけるネットワーク・ソフトウェア・インターフェースを提供するネットワーク・サービスを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。複数の地点におけるコンピュータ間で処理ロジックの束が提供される。この論理が束内の内容属性記述子の所定の状況を検出して、かかる内容属性記述子の所定状況の検出に応答する動作を実行するようにという1セットの指示に応える。また、各々の場所からアクセス可能で、束処理ロジックのための指示の一組の少なくとも一部分を定めるために動作中である束処理ロジックのためのプログラム・インターフェースも含まれる。

好適な実施形態において、束処理ロジックは、複数の必須内容分野および複数のユーザ定義分野のうちの少なくとも1つの状況を検出するための論理を含むことができる。本システムはさらに、独立のソフトウェア・アプリケーションへのインターフェースおよび束処理ロジックのプログラム・インターフェースへのインターフェースを有する構成要素を更に含むことができる。本システムは、束において参照されるデータ・エレメントへのピア・ツー・ピア・アクセスを可能にするためのピア・ツー・ピア転送ロジックを更に含むことができる。本システムは、束処理ロジックに応答する警報ロジックを更に含むことができる。本システムは、束処理ロジックに応答する内容混合ロジックを更に含むことができる。本システムは、束の配置を制限するための束内におけるセキュリティ情報に応答する、複数地点コンピュータ間のセキュリティ・ロジックを更に含むことができる。束処理ロジックは、追加的な情報を含む超束内の少なくともいくつかの束で、入れ子構造的に作動可能である。各々の束は、データについてのアクセス権限のあることを識別するセキュリティ情報を含みうるが、この場合、束および超束についての権限を与えられたアクセッサのみが当該束及び超束を見ることができる。

他の一般的実施態様において、本発明は、プログラム・コマンドをネットワーク上の地点から受けとり、ネットワークによるデータ束を配信し、束に用いるコンテンツ属性記述子における所定条件の検出に応答するように動作することを含むネットワーク化商業的相互取引管理方法を提供することを特徴とする。

更なる一般的実施態様において、本発明は、ネットワーク上の複数の地点からプログラミング命令を受け取る手段と、該ネットワークを通じてデータ束を配信する手段と、該束用の内容属性記述子中にある所定状態の検出に呼応して動作を実行する手段とを具備する商取引管理のためのネットワーク・システムを提供することを特徴とする。

また別の実施態様において本発明は、情報を複数の束に組み立てることを含むネットワーク化商取引管理方法であって、それぞれの束はデータ要素参照および該データ要素を説明するメタ・データからなり、各データ要素はネットワークのデータの所有者のノードに存続するネットワーク化商取引管理方法を提供することを特徴とする。本方法はまた、該束の中のメタ・データを該ネットワークを介して配信し、アクセッサがデータ要素を選択するのに続いて、それぞれのデータの所有者のネットワークノードから組み立てるステップにおいて組み立てられた束の中の該データ要素のコピーを該アクセッサのネットワークノードへ配信することを含む。

好適な実施例においては、該データへのアクセス権原を有する者を示すセキュリティ情報を含み得、該配信のステップは、該アクセス権原を有する者にのみ該束を配信する。当該システムは、セキュリティ情報を定めるべく所有者とアクセッサとの間で信頼関係について交渉するステップを更に備えてもよい。本システムは更に、該配信ステップの前に、権限を有するネットワーク化ユーザ・ディレクトリから束を受け取るべきネットワーク化ユーザを選ぶステップを含むことができる。該セキュリティ情報のフォーマットは、組織識別子が該セキュリティ情報に含まれるのを許容することができる。本システムは、所有者の入力に応答してメタ・データ要素のうちの1つを定義するステップを更に含むことができる。本システムは、該アクセッサへのデータ要素のコピーの配信及び該取引に関する情報を記録するステップを更に含みうる。メタ・データは、ティッカー・シンボル識別領域を含んでもよい。当該システムは更に、該複数の束のうちの少なくともいくつかの束を追加的情報を含む超束に入れ子にするステップを含むことができる。各々の束は、該データへのアクセス権を有する者を示すセキュリティ情報を含むことができ、束及びその超束の双方へのアクセス権原を有する者のみが該束および超束を見ることが可能である。本システムは、該束及び超束の双方へのアクセス権原を欠く受取人に対し代替的内容を提示するステップを更に含むことができる。該束および超束は、異なるノードで異なる所有者を有してよく、該配信のステップは該異なるノードで、異なる所有者を有してよく、該配信のステップは該異なるノードから該束及び超束を配信することが可能である。該複数の束は、タイプの異なる一つ以上のファイル参照を含むことができる。該タイプは、オーディオ（音声）・ファイル、ビデオ（映像）・ファイル、グラフ画像ファイル及びフォーマット化された文書ファイルを含むことができる。該複数の束の少なくともいくつかは、他の束への参照を含むことができる。当該他の束への参照は、返信に係る参照を含むことができる。本システムは、該ネットワークの複数の異なるノードに、束バージョン識別信号を周期的に発行することを更に含むことができる。該メタ・データを配信するステップは最新版を配信することができ、本システムは該識別信号に応答して該複数のノードのうちの少なくとも1つから該最新版のコピーを要請するステップを更に含むことができる。本システムは、該メタ・データの部分に基づいて該束にフィルタをかけるステップを更に含むことができる。該コピーを配信するステップは、ピア・ツー・ピア転送を含むことができる。本システムは、該メタ・データの状況の検出に呼応して、ユーザに警告するステップを更に含むことができる。本システムは、該メタ・データの状況の検出に基づいて、内容を混合するステップを更に含むことができる。

更なる総合的実施態様において、本発明は、ネットワーク全体に散在し複数の束からのメタ・データを配信するよう動作可能な複数の束配信サーバと、該束において参照されたデータ要素のコピーをそれぞれのデータの所有者のネットワークノードから、アクセッサのネットワークノードまで検索する検索ロジックを含む商取引管理のためのネットワーク・システムを提供することを特徴とする。

別の総合的実施態様において、本発明は、情報を複数の束に組立てる手段であって、各束はデータ要素および該データ要素を記述するメタ・データからなり、各データ要素はネットワークのデータの所有者のノードに存続するものである手段を備えるネットワーク化商取引管理方法を提供することを特徴とする。本システムは更に、該束の中のメタ・データを該ネットワークを介して配信する手段と、アクセッサがデータ要素を選択するのに続いて、それぞれのデータの所有者のネットワークノードから組立てる手段によって組み立てられた束の中の該データ要素のコピーを該アクセッサのネットワークノードまで配信する手段を具備する。

更なる総合的実施態様において、本発明は、複数の内容属性記述子および少なくとも一つの内容記述子を含むデータ束を受信し、該内容記述子中の所定の状況について調べ、該所定の状況が検出されると該束を修正することを備えるネットワーク化商取引管理方法を提供することを特徴とする。好適な実施形態において、本システムは、該束からの情報をサービスプロバイダに転送するステップを更に備えることもでき、該修正のステップは該サービスプロバイダによって実行される動作に応答して実行されうる。

また別の総合的実施態様において、本発明は、複数のユーザ間の束通過インターフェースと、該束通過インターフェースのための内容変更サービス・インターフェースと、該内容変更サービス・インターフェースに対して与えられる指示に基づき該束通過インターフェースを通過する束に呼応する束修正ロジックとを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

更なる総合的実施態様において、本発明は、複数の内容属性記述子および少なくとも一つの内容記述子を含むデータ束を受信する手段と、該内容記述子中の所定の状況について調べる手段と、該所定の状況が検出されると該束を修正する手段とを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

また別の総合的実施態様において、本発明は、データ処理システムにおけるネットワークの第１のノード上で実行されるコンピュータ・アプリケーション・プログラムがアクセスするためのデータを格納するデータ・メモリであって、該データ・メモリは、ネットワーク・ルーティング領域と、複数のメタ・データ領域記述子と、複数のメタ・データ領域値と、該ネットワーク上の内容要素の位置を識別する情報を含む内容要素への参照とを含むデータ束を備えるデータ・メモリを提供することを特徴とする。

好適な実施形態において、該メタ・データ領域は、固定数及び可変数を含みうる。該メタ・データ領域は、所有権者領域を含むことができる。該メタ・データ領域は、該束のためのバージョン領域を含むことができる。

更なる総合的実施態様において、本発明は、複数の内容属性記述子のための値を含む機械可読フォーマットに従って、第1の複数の異なるネットワーク・ユーザ中の異なるものから、第２の複数の異なるネットワーク・ユーザ中の異なるものに対して情報束を配信し、該内容属性記述子のための値に基づいて配信するステップのトラヒック（交通量）統計を導出することを具備するネットワーク化商取引管理方法を提供することを特徴とする。

好適な実施形態において、当システムは該トラヒック統計を支払い請求額に変換するステップを更に含むことができる。該変換のステップは、目的地を異にするトラヒック（交通量）については、異なる支払い請求額に変換することができる。該変換のステップは、異なるユーザ間のプログラム化束処理ロジックによって要請されるイベントに対して、トラヒックを支払い請求額に換算することができる。該変換ステップは、人間から独立した動作に対してトラヒックを支払い請求額に換算することができる。該導出のステップは、申し出束の提示についての統計およびこれらの申し出束の受け入れ率を導出することができる。該導出のステップは、転送される束のタイプについての統計および該転送に関与しているユーザ用の情報プロフィールを導出することができる。当該システムは、該統計を買い手側ユーザに転送するステップを更に含むことができる。該導出のステップは、ほぼリアルタイムで実質的に連続的に動作することができる。該配信のステップにおいて配信させる束は、データ要素への参照及び該データ要素を記述するメタ・データを含むことができ、各々のデータ要素はネットワークのデータの所有者のノードに存続する。該導出のステップは、互いに通信する権原を与えられた複数組のユーザ間での転送についての統計を導出しうるが、該組同士の通信は許可されない。該導出のステップは、ティッカー・シンボル領域についての統計を導出することができる。

また別の総合的実施態様において、本発明は、複数のネットワーク化されたユーザ間に位置し、束中の機械可読情報に呼応する配信制御入力を含む配信ロジックを備える束通過インターフェースと、該束中の機械可読情報に呼応する制御入力を含む統計収集エンジンとを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

更に別の総合的実施態様において、本発明は、複数の内容属性記述子のための値を含む機械可読フォーマットに従って、第1の複数のさまざまなネットワーク・ユーザのさまざまなものから、第２の複数のさまざまなネットワーク・ユーザのさまざまなものに対して情報束を配信するための手段と、該内容属性記述子のための値に基づいて配信するステップのトラヒック統計を導出する手段とを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

また別の総合的実施態様において、本発明は、第1の複数のさまざまなネットワーク・ユーザ中のさまざまなものと第２の複数のさまざまなネットワーク・ユーザ中のさまざまなものとの間のさまざまなレベルの信頼関係について交渉し、該さまざまなレベルの信頼関係に従って、該第1の複数のさまざまなネットワーク・ユーザ中のさまざまなものから該第２の複数のさまざまなネットワーク・ユーザ中のさまざまなものまで情報束を配信することを備えるネットワーク化商取引管理方法を提供することを特徴とする。

好適な実施例においては、本システムは、該第1の複数のユーザ中の１ユーザがディレクトリ検索ユーティリティを利用して該第２の複数のユーザ中の1人を調べるステップを更に含むことができる。該交渉のステップは、電子名刺の交換を含むことができる。該配信のステップは、第1の束の発信者とのさまざまなレベルの信頼関係に基づいて、該第１の束のさまざまなバージョンをさまざまなユーザに配信することができる。該配信のステップは、該束の受領者に係るさまざまなレベルの警告を含むことができ、該さまざまなレベルの警告の選択は該受領者が第1の束の発信者との間で有するさまざまなレベルの信頼関係に基づく。本システムは、特定の束の受取人からその発信者に対して該受信した特定の束についてのフィードバック情報を更に含み得、該フィードバック情報の量は該発信者及び受取人の間の信頼関係のレベルに依存する。本システムは、該交渉のステップの前に、ネットワーク化されたユーザの間でマーケティング・メッセージを配信するステップを更に含むことができる。該マーケティング・メッセージは、発信者であるユーザが提供できる処理のタイプを表している機械可読な取引型式情報を含むことができる。該機械可読な取引型式情報は、市場セクタ情報を含むことができる。本システムは、プロフィール発行元ユーザが提供可能な取引の種類を表す機械可読取引型式情報を含むネットワークを通じてアクセス可能なプロフィールを発行するステップを更に含むことができる。該機械可読取引型式情報は、市場セクタ情報を含むことができる。

更なる総合的実施態様において、本発明は、複数のネットワーク化されたユーザに勧誘状を発信すべく動作可能な勧誘（招待）状通過インターフェースと、ユーザ間の関係の現状情報を格納するための関係状況記憶装置であって該記憶装置にアクセスする関係状況イベントに応答する記憶装置と、複数のネットワーク化されたユーザに束を発信可能に動作し、該関係状況記憶装置に応答する入力を有する束通過インターフェースとを具備する商取引管理のためのネットワーク・システムを提供することを特徴とする。

また別の実施態様において、本発明は、第1の複数のさまざまなネットワーク・ユーザ中のさまざまなものと、第２の複数のさまざまなネットワーク・ユーザ中のさまざまなものとの間のさまざまなレベルの信頼関係について交渉する手段と、該さまざまなレベルの信頼関係に従って、該第1の複数のさまざまなネットワーク・ユーザ中のさまざまなものから該第２の複数のさまざまなネットワーク・ユーザ中のさまざまなものまで情報束を配信する手段とを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

更なる総合的実施態様において、本発明は、複数の互いに異なるネットワーク化されたユーザ間で機械可読識別情報を交換し、該交信ステップで交信された機械可読識別情報に基づき、受信すべき情報束を同じ機械可読フォーマットのユーザのさまざまなものから選択することであって、該機械可読フォーマットは複数の情報領域用の値を含むものを備えるネットワーク化商取引管理方法を提供することを特徴とする。

好適な実施例において、該機械可読識別情報の交信のステップは、各々についての識別情報を含む電子名刺を交換するステップを含むことができる。該束を選択するステップは、束が選択可能かどうかを決定するためのセキュリティ情報を評価するステップを含むことができる。該機械可読フォーマットは、該情報領域として、取引されたセキュリティ識別子領域、注釈領域および発信者識別領域を含むことができる。該機械可読フォーマットは、該情報領域として、組織提携識別領域、注釈領域および発信者識別領域を含むことができる。該情報束は、テキスト情報束、画像情報束および音声情報束を含むことができる。本システムは、潜在的アクセッサに対し該機械可読識別情報に少なくとも部分的に基づくデータの入手可能性を通知するステップを更に含むことができる。該通知するステップは、遠隔通知方法を選ぶことを含むことができる。該選択するステップは、ほぼリアルタイムで束を選択することができる。本システムは、該受信のステップで受信した複数の束の第1の部分の発信者との間で、当該複数の束の第１の部分の内容に関してコミュニケーションを確立するステップを更に含むことができる。該応答するステップは、該第1の束に関連したユーザ制御動作に応答して起こることができる。該応答するステップは、該第１の束の表示エリアの近くでユーザ制御動作に応答して起こりうる。該応答するステップは、ほぼリアルタイムの双方向通信を含むことができる。該応答するステップは、該第1の束において参照される項目のピア・ツー・ピア転送を要請することを含むことができる。該機械可読識別情報交信ステップは、該複数の情報領域のための値を備えるプロフィールを発信するステップを含むことができる。該プロフィールは、束データの通知、関連、ダウンロードおよびルーティングに係るアクセッサの基準を含む一組の意思決定規則を含むことができる。該プロフールの交信のステップは、該プロフィールのいくつかの配信か全部の配信かの配信の程度を特定する限定配信記録を規定するステップに応答しうる。本システムは、権原を有するユーザのディレクトリから、通信相手となるユーザを選ぶステップを更に含むことができる。

また別の総合的実施態様において、本発明は、複数の情報領域のための値を含む機械可読識別情報を含む勧誘（招待状）をユーザ間でうけ渡すための複数のネットワーク化されたユーザ間における勧誘（状）通過インターフェースと、該複数のネットワーク化されたユーザに対して束を発信するよう動作可能な束通過インターフェースと、該勧誘通過インターフェース及び束通過インターフェースに応答し、該勧誘通過インターフェースから受信した機械可読識別情報に基づき、受信すべき情報束を同じ機械可読フォーマットのユーザのさまざまなものから、該束通過インターフェースを通じて選択するように動作可能なフィルタリング・ロジックとを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

更なる総合的実施態様において、本発明は、複数のネットワーク化されたユーザ間で機械可読識別情報を交換する手段と、交信手段により交信された該機械可読識別情報に基づき、受信すべき情報束を同じ機械可読フォーマットのユーザのさまざまなものから選択する手段であって、該機械可読フォーマットは複数の情報領域用の値を含む手段とを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

更に別の総合的実施態様において、本発明は、ネットワークのノード間で情報束を配信するためのネットワーク・サービスと、該ネットワークの複数のノードに配置され、データ束及び該データ束の各々へのアクセス権原を有する者を識別するセキュリティ情報を含むデータ格納装置と、該セキュリティ情報にアクセスし、該セキュリティ情報に基づいて有権原アクセッサにのみ他のノードからデータ束へのアクセスを許可するように動作可能なセキュリティ行使システムとを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

好適な実施例において、本システムは、独立型ソフトウェア・アプリケーションへのインターフェース及び束処理ロジックのプログラム・インターフェースへのインターフェースを備えるアプリケーション要素を更に含むことができる。本システムは、該束において参照されるデータ要素へのピア・ツー・ピア・アクセスを可能にするピア・ツー・ピア転送ロジックを更に含むことができる。本システムは、勧誘（状）を受け取るための勧誘受信ロジック及び所有者とアクセッサとの間の関係を構築する関係構築ロジックを更に含むことができる。本システムは、ネットワーク化されたユーザのリストに応答するディレクトリ・ロジックを更に含むことができる。該セキュリティのフォーマットは、組織識別子が該セキュリティ情報に含まれるのを可能にする。本システムは、該束のうちの少なくともいくつかの束を追加的情報を含む超束に入れ子にするための入れ子ロジックを更に備え、各束が該データへのアクセス権原を有する者を特定するセキュリティ情報を含み、束及び超束の双方へのアクセス権原を有する者のみが該束及び超束を見ることができるものである。該束および超束が異なるノードで異なる所有者を有することができ、該ネットワーク・サービスが該異なるノードから束および超束を配信する。本システムは、該ネットワークの異なるノードに対して、バージョン特定信号を発するように動作可能なバージョン特定信号ジェネレータを更に含むことができる。

更なる総合的実施態様において、本発明は、ネットワークの複数のノード間で情報束を配信する手段と、データ束及び該ネットワークの複数のノードのデータ束データ格納装置の各々と関連する有権原アクセッサを特定するセキュリティ情報を格納する手段と、該セキュリティ情報にアクセスし、該セキュリティ情報に基づいて有権原アクセッサにのみ他のノードからデータ束へのアクセスを許可する手段とを備える商取引管理のためのネットワークシステムを提供することを特徴とする。

更に別の総合的実施態様において、本発明は、ネットワークの複数ノード間で情報束を配信し、データ束および該ネットワークの複数のノードのデータ束データ格納装置の各々と関連する有権原アクセッサを特定するセキュリティ情報を格納し、該セキュリティ情報にアクセスし、該セキュリティ情報にもとづいて有権原アクセッサにのみ他のノードからデータ束へのアクセスを許可することを備えるネットワーク化商取引管理方法を提供することを特徴とする。

また別の総合的実施態様において、本発明は、複数の情報領域のための値を含む個人的プロフィールを定義すること、同じ機械可読フォーマットのさまざまなネットワーク化されたユーザから情報束を受け取ることであって該機械可読フォーマットは該複数の情報領域の値を含むこと、該情報用の複数の領域の値及び該複数の束用の複数の領域の値に基づき、該さまざまなユーザからの複数の情報束の少なくとも複数の部分を提示することを具備するネットワーク化商取引管理方法を提供することを特徴とする。

好適な実施形態において、該提示のステップは、該複数の情報束の複数の部分を単一のリスト画面で提示することができる。該提示のステップは、該複数の情報束の複数の部分をカスタマイズ可能な画面で提示することができる。該提示のステップは、該複数の情報束の複数の部分を概略画面で提示することができる。該機械可読フォーマットは、情報領域として、取引されたセキュリティ識別子領域、注釈領域および発信者識別領域を含むことができる。該機械可読フォーマットは、複数の情報領域として、組織的提携先識別領域、注釈領域及び発信者識別領域を含むことができる。該機械可読フォーマットは、情報領域として、取引されたセキュリティ識別子領域、内容領域、注釈領域および発信者識別領域を含みうる。該情報束は、テキスト情報束、グラフィック情報束およびオーディオ情報束を含むことができる。本システムは、該情報領域の値に少なくともある程度基づく警報を規定するステップを更に含むことができる。該警報規定ステップは、遠隔通知方法の選択を含むことができる。本システムは、該受信のステップで受信した複数の束の第１の部分の発信者との間で、当該複数の束の第1の部分の内容に関してコミュニケーションを確立するステップを更に含むことができる。該応答するステップは、該第1の束に関連したユーザ制御動作に応答して起こることができる。該応答するステップは、該第１の束の表示エリアの近くでのユーザ制御動作に応答して起こることができる。該応答するステップは、ほぼリアルタイムの双方向通信を含むことができる。該応答するステップは、ほぼリアルタイムのテキストによる双方向通信を含むことができる。本システムは、該プロフィールをネットワークの他のユーザが利用できるようにするステップを更に含むことができる。該プロフィールを利用可能にするステップは、該プロフィールの配信の範囲を特定する限定配信記録を規定するステップに応答しうる。該プロフィールを利用可能にするステップは、配信されるべき該プロフィールの量を特定する部分的配信記録を規定するステップに応答しうる。本システムは複数の互いに異なるユーザと機械可読識別情報を交信し、該交信のステップで交信された機械可読識別情報に基づいて受信すべき情報束を選択することを更に含むことができる。該機械可読識別情報交信のステップは、各々が識別情報を含む電子名刺を交換するステップを含むことができる。該機械可読識別情報交信のステップは、安全なチャネルを通じて実行されることができる。本システムは、正当権限を有するユーザのディレクトリから通信相手となるべきユーザを選ぶステップを更に含むことができる。本システムは、ソフトウェア・アプリケーションからのメッセージに基づき、ユーザからの入力とは独立に、該複数の領域中の少なくとも１つの値を自動的に調整するステップを更に含むことができる。本システムは、複数の情報領域用の値の追加的な一組を含む追加的な個人プロフィールを規定し、更に、該互いに異なる複数のユーザからの複数の情報束の少なくとも複数の部分を該複数の情報領域の値及び該束の領域値に基づいて提示するステップを更に備えることができる。該提示のステップは、該複数の情報領域の同一セットの値及び該束の領域の値に基づき、該複数の情報および束の少なくとも部分を異なる複数のユーザに提示することができる。該提示のステップは、該異なるユーザ間の束処理ロジックによって実行される評価のステップに呼応して行われうる。

別の総合的実施態様において、本発明は、複数の情報領域のための一組の値の格納を含む個人プロフィール記憶装置と、ネットワークに応答し、同じ機械可読フォーマットをもつ異なるネットワーク化されたユーザからの情報束を受信するように動作可能な束インターフェースであって、該機械可読フォーマットは該複数の情報領域用の値を含む束インターフェースと、該束インターフェースおよび個人プロフィール記憶装置に呼応し、該異なるユーザからの情報束の少なくとも複数の部分を該複数の情報領域の値及び束領域の値にもとづいて提示するように動作可能なフィルタとを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

更なる総合的実施態様において、本発明は、複数の情報領域のための一組の値を含む個人プロフィールを定義する手段と、同じ機械可読フォーマットをもつ異なるネットワーク・ユーザからの情報束を受信する手段と、該異なるユーザからの情報束の少なくとも複数の部分を該複数の情報領域の値及び束領域の値に基づいて提示する手段とを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

また別の総合的実施態様において、本発明は、情報束用の複数の情報領域のための値を含むプロフィールを規定すること、該情報領域の値に関する情報束を受信すること、該受信のステップで受信した束に含まれる情報に基づき該プロフィールを自動的に修正することを備えるネットワーク化商取引管理方法を提示することを特徴とする。好適な実施形態において、該情報領域は複数のセキュリティズ識別子を含むことができ、該受信のステップが特定のセキュリティに関する情報を受信する。

別の総合的実施態様において、本発明は、情報束用の複数の情報領域のための値の格納を含むプロフィール記憶装置と、ネットワークに呼応し、ネットワーク化されたユーザから該複数の情報領域用の値を含む情報束を受信するように動作可能な束インターフェースと、該束インターフェースに呼応し該プロフィールと連絡して該束インターフェースにより受信される束に含まれる情報に基づきプロフィールを修正するためのプロフィール修正ロジックとを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

更に別の総合的実施態様において、本発明は、複数の情報束用の複数の情報領域のための値を含むプロフィールを規定する手段と、該情報領域の値に関係する情報束を受信する手段と、該受信の手段によって受信された束に含まれる情報に基づいて該プロフィールを自動的に修正する手段とを備える商取引管理のためのネットワーク・システムを提供することを特徴とする。

本発明によるシステムは、様々な現在のワールドワイド・ウェブ表現（例えばハイパーテキスト・マークアップ言語（HTML）を使用するもの）が行っているようなデータの静的「画像」ではなく、実データへのアクセスを提供することができるという点で有益である。ウェブと異なって、本発明によるシステムは、接続の発信端と同様に受信端においても知的ソフトウェア・システムを可能にすることができる。実際のデータが受信システムによって利用でき、操作し変形できるので、システムがユーザ（人間のユーザ及びソフトウェア・システム・ユーザ）の間での任意の処理を可能にする。これらの処理は、情報のいかなる交換、配信、購入、販売、或いはこの種の処理の統合を含むことができる。そして、本発明によるシステムは、予想外のやりとりであっても、ユーザがその関係の性質につき交渉し、当該ソフトウェアは結果として生じる調整に対応することでサポートすることが可能である。

本発明によるシステムも、それらの、分散しているが、統一されているという性格から利益を得る。多数のさまざまな機関の別個に設計されたウェブサイトを取扱うよりはむしろ、ユーザは、単一の統一されたインターフェースを用いてそれらの各々とのやりとりを行うことができる。これにより、別の機関により提示された異なるカスタム・インターフェースを理解して使用することに伴うかなりの量の時間と労力を省くことができる。さらに、情報がシステムの全体にわたって配信されるので、各々の会社およびユーザはその情報の制御を保持することができる。

本発明によるシステムは、また、買い手のプライバシーの保護および、情報のフィードバックが売り手に与える利点の間のトレードオフ（かねあい）を控え目で直接的な方法により最適化するのに資することができる。このことは結果として、本システムによるのでなければ、個人的情報や資産情報のかなりの量を様々な個々のプロバイダに公表することを快く思わないユーザによって、本システムが飛躍的に用いられる可能性があることを意味する。本発明によるシステムはまた、適宜、演算処理の中心システムに情報を移動させ、或いは情報のセキュリティがより重要なときには当該情報のサイトに処理の変化を移動させることをも許容する。そして、システム全体としてから統計情報および支払い請求情報を集めることによって、本発明によるシステムは、そのユーザに対する重要なフィードバックを提供することができ、情報の取引を可能にすることができる。

本発明によるシステムは、また、社内ファイアウォール全体に亘るやりとりを単純化することの利点を提供することができる。一旦本発明によるシステムがインストールされると、これにより様々な関係者との間で、安全ではあるが、特徴の豊富な通信が可能となる。ファイアウォール（それは、内部には開かれ外部には閉じることで、地理的にデータを安全にする）のような従来のセキュリティ・システムとは異なり、本発明によるシステムは、各データ要素に一組の有権原受領者を関連づけ、確実に認証された配信を提供することにより、個々のデータ要素を安全にすることができる。このレベルの安全性及び高特徴性インタラクションは、この種のシステムのセットアップが、単一組のユーザ間においてすら複雑さおよび困難さが伴うため、従来は、利用不可能か、もしくは極めて高価につくものであった。

（実施形態の説明）
図1を参照する。本発明に係る図示のシステム10が1以上の売り手側会社a,…,nに属す一連の売り手側ユーザ端末a1,
a2，…, an; …n1, n2, …,nnと、1以上の買い手側会社A,…,Nに属す一連の買い手側ユーザ端末A1, A2, …, An; N1, N2,…,NNとを1以上のネットワーク１２を介して相互接続している。他のネットワーク通信経路がこれらのユーザの間に存在しうるにもかかわらず、一連の集約サーバ（AGS）s1
... sn;S1,…,SNはユーザによって作動される１以上のアプリケーション層app1,…,appn; APP1, …,APPNに対するシステムインターフェースを提供するのが好ましい。これらのサーバは各々会社のうちの1つに対応し、示される実施例における企業制御のサイトに配置されるが、それらはまた、他の方法によっても配置されうる。大企業は多数の集約サーバを使用しうるが、大部分の会社は恐らく1つの集約サーバのみを使用するだろう。小規模の会社は、集約サーバを共有することができる。

本実施例において、集約サーバは一つ以上の管理サーバ16による管理組織14と相互に作用する。管理サーバ16は地域社会に付加価値通信網を提供する。提供されるサービスの種類に従い、管理サーバの機能の中には、１以上の集約サーバ内に配置できるものもある。

多くのアプリケーションが買い手側および売り手側端末で異なる機能を提供する一方で、この識別が必ずしも役立つものではない点に注意されたい。アプリケーションは、例えば、個々のユーザが買い手側および売り手側の機能にアクセスできるように展開することができる。買い手側と売り手側との役割分担がより明白でない商業域のために、ユーザ・インターフェース・システムを開発してもよい。システムの中には、あらゆるユーザが、あつらえられたアプリケーションを特徴を異ならしめつつ用いるようなオプションを設けてもよい。加えて、投資産業に関する多くの実施例が本発明を理解する一助として本出願の範囲内で提供されるが、これは本発明に基づく一般原理の応用分野を当該領域に制限するものとして理解してはならない。

システム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のための接続ポイントが３つある。第１はXIA APIである。XIA APIはローカルCOM構成要素としてまたはSOAPを経た遠隔サービスとして現れるアプリケーション・プログラミング・インターフェース（API）である。これは、束やユーザのような一組のオブジェクトを具象化するためのインターフェースを提供し、これによりアプリケーションがこれらのシステム・オブジェクトを生成し、該システム・オブジェクトと相互作用できるようにする。第２の接続ポイントはXIA警報である。XIA警報は、警報形式のメッセージを配信すべくTIBCOランデブを介して発行される非同期メッセージである。これらは、無線デバイスに対する束の通知、または管理コンソールに送られる単純ネットワーク管理プロトコール（SNMP）タイプ・メッセージのような、ユーザ収束的なものであってもよい。第3の接続ポイントは、XIAトリガを含む。これらは、縦続処理を集約サーバに起こさせうるイベントである。XIAトリガは、所定の一連の作業を遂行すべく他のシステムおよびアプリケーションに同期的あるいは非同期的につながることができる。

上記した3つのアクセス・ポイントが集約サーバの入力および出力を定めるのに対して、XIAのイベント・テーブルはあらゆる種類のXIA活動の内部手順フローを表記する。イベント・テーブルは、もの（例えば束タイプ、終点アドレス、発信者、ユーザ役割またはユーザ定義可能な特性さえ）の組合せに基づいて、極めて精密に穀粒化されたレベルで定められることが好ましいといえる。各々のイベント・テーブルは、一連のアクティビティに優先順位、依存度、実行方法および集約サーバによって管理されるあらゆるオブジェクト上のあらゆる動作要件を提供する。

内容混合は、XIAイベント・テーブルがシステムの両方のエンドポイントで用いられるメソッドの例である。XIA
API publishBundlemethod（XIA API発行束メソッド）がコールされると、XIAイベント・テーブルは特定の束タイプおよび終点アドレスをキーに発見され、ジョブ・シーケンスのように実行される。テーブルは、同期的にローカルCOM呼び出し命令がこの材料の公開を許可するコンプライアンス・システムになければならないことを定めることができる。次に、非同期呼び出し命令は、この主題の最新の研究を要請するために別々のサーバ上の調査システムに向けてなされることができる。一旦同期動作が完結すると、メタ・データがネットワークに対して発行される。

メタ・データが受取人の集約サーバに達すると、WAP（表１参照）を使用している無線デバイスに、メタ・データを渡す通知システムに対してランデブを介したXIA警報を発信するXIAテーブルが誘引される。

受取人が束を要請するときには、それらのワークフロー・アプリケーションはXIA API fetehBundlemethod（XIA API束フェッチ・メソッド）をコールしうる。これにより、コア・フィルタリングサービスを交換するか増幅するローカルXIAテーブルが実行され、例えば、ローカル・コンプライアンス・サーバから情報を要求して、ACMEに関する購入を観念することが、ユーザによって管理されている資金の趣意書定義に基づいて可能でないかどうか決定し、これによりユーザがこのような観念に接することすら妨げる。追加的な内容混合はまた、供給されるローカル・ニュースから主題上のシステム統計および主題上の上位5つのニュース見出しに関する非同期的要請を引き起こしている発信者および束タイプに基づいて、XIAテーブルによって動作させることができる。

セキュリティおよびユーザ認証は、ローカルXIA機能がXIAテーブルのカスタム化を経て完全に置換されることができる方法についての他の実施例である。XIAログイン要請のための標準のシーケンスは、完全に取り除かれることができて、ユーザを確認するクライアントに特有の認証シーケンスと取り替えられることができる。この過程は結果的に、集約サーバにひき渡しうる徴証の生成となる。このとき集約サーバはユーザを確認するために、当該徴証をサーバ側徴証と突き合わせる。これは適切な徴証情報を格納すべく、ユーザ・オブジェクトのプロパティをカスタム化させることを必要とする。これによりシステム・ネット・オブジェクトは異なる統合プロジェクトのために増幅可能な伸長特性を有することになる。クライアントおよびサーバ側のセキュリティ定義が同時発生的でない限り、ユーザ確認は完結せず、従って許可されることはない。

XIAは、2つのモードのどちらにおいてでも作動するように構成することができる。第1のモードは、同期モードと呼ばれている。このモードにおいて、XIAは必要な動作を実行すべく、外部システムに文書に対する支配権を渡す。外部システムが集約サーバ中に呼び戻され、文書状況を修正するまで、制御及び処理は再開しない。この時点で、制御はXIAエンジンに再度移される。第２のモードは、非同期モードと呼ばれている。このモードにおいて、外部システムは、文書がシステムを通過し、外部システムが要望または必要に応じて複数の並列処理を始めることができる旨を通知される。XIAは文書処理を継続し、外部システムは、それが「通過する」際には当該文書へのアクセスを制限する。

XIAは、カスタム・コンポーネントを埋め込むことによって既存のデスクトップ・アプリケーションが地域内の他のユーザと相互にやりとりするのに適合させることができる。これにより、必ずしもワークフローを残すことなしに、多くのユーザがインフラストラクチャの協同権限に切れ目なくアクセスすることができる。例えば、売り手側トレーダは、XIAと相互に作用することができる組込形部品で強化された標準の取引端末（例えばロイターズ・アンド・レッグやXTRA端末）を使用するかもしれない。また、販売員は標準のコンタクト管理アプリケーション（例えば同様に強化されたMicrosoft
Outlook（登録商標））を使用するかもしれない。この種のアプリケーションを使用することで、これらのユーザは、標準的な環境下他のあらゆる種類のデータを生成・受信するように、システム束を作成し、受信することができる。

XIAは、アプリケーション・プログラミング・インターフェース（API）セットを超えるものである。多目的APIについては、外部システムは一組のパラメータと機能名をコア・システムに引き渡し、該コア・システムは、外部システムに代わって機能を実行する。しかしXIAについては、その機能の実現にあたりどんな方法が選択されるにせよ、制御が外部システムに引き渡されることができる。実施例は、3つの標準の通信プロトコル、即ちマイクロソフト社（登録商標）の構成オブジェクト・モデル／分散型構成オブジェクト・モデル（COM/DCOM）、TIBCO（登録商標）のランデブ・メッセージ・システム、及びマイクロソフト／IBM（登録商標）のSOAP（単純オブジェクト・アクセス・プロトコル）を介したXIAでの外部システムおよび集約サーバ間の相互作用を開示する。サポートされうる他の技術は、サン・マイクロシステムズ社（登録商標）の遠隔方法呼出し（RMI）および一般のオブジェクト・リクエスト・ブローカ・アーキテクチャ（CORBA）を含む。これらの技術は、従来技術において当業者に容易に理解される様々な公的利用可能文書において明確に定義されている。

情報はシステムからユーザのデスクトップへ、アプリケーションから集約サーバに、ネットワーク全体から他の集約サーバに、更にアプリケーションを経て再びクライアントのデスクトップへと動き、XIAはさまざまな機能及びイベントが集約サーバ及びアプリケーションとの間で起こることを可能にする。XIAと相互に作用するシステムは、一般に、2つのタイプがある。即ち、(１)売り手側コンプライアンス・エンジン及び内容混合のような、集約サーバへの機能を置換し、増幅し、及び／もしくは、修正するもの、
(2)ユーザ向けのユーザ・インターフェースを形成し、束の生成・受け取りを可能にするアプリケーション、である。

XIAプロセスは、外部システムが、通りすぎる情報に対して価値を付加する（「内容混合」と呼ばれる）ことを可能にし、集約サーバの機能性の変更態様を可能にして、適切な外部システムにイベントの通知を提供することができる。例えば、システムはユーザまたはユーザ会社がシステムの異なる位置（発信者企業の集約サーバ、システムのコア基盤および／または受取人企業の集約サーバを含む）で追加的な内容を束に混ぜ入れるのを許可することができる。ユーザアプリケーションはまた、発信者および／または受取人のデスクトップでの混合を許可することができる。

付加された内容は、いかなる互換性を持つデータソースからであってもよいし、束に層として加えられてもよい。それは、文書の作成段階での、または、内容のスナップショットとして、例えばハイパーテキスト転送プロトコル（HTTP）参照のような内容の参照として、加えられることができる。集約サーバに格納されている授与資格を用いることで、内容混合はまた、ユーザに特有にもしうる。内容の追加は、既存の束周辺で超束を築くことで、または束を変形することによって実行することができる。

一つの実施例においては、売り手側証券会社の販売員が、買い手側会社で、ポートフォリオ管理者のための「技術」セクタに関するサンフランシスコの来るべき会議について、投資束を準備する。彼は次に、自身の内部調査システム内から最新の工業報告およびモデルを束に加えて、それを送信する。内容混合の第1のレベルにおいて、売り手側会社は束がその集約サーバを通り過ぎる際に自動的に当該束にその法的否認陳述書を付する。内容混合の第２のレベルは、束がシステムのコア基盤に到着するときに発生し、売り手側会社が天気予報の束への追加を要請したことを検出し、買い手側会社が特定の天気内容サービスの加入者であると結論付ける。この検出により、所与の日付におけるこのサービスから得られるサンフランシスコの天気予報が投資束に加えられる。内容混合の最終レベルは、束が買い手側会社の集約サーバに達するときにであって受取人端末に達する前に発生する。このときに、会社の集約サーバは束には技術セクタが付されていることを感知し、それらの内部システムのうちの1台からの買い手側会社のアナリストから、最新の技術セクタ報告を加える。

他の例では、売り手側会社の販売員は、オンライン・オークション・サイトについて買い手側会社のための束を作成する。彼女は、束に5つの普通株を付け加えて、最直近の評価およびそれらの普通株の推奨が束において表示されなければならないことを示す。売り手側会社がXIAを通してそれらの調査データベースを自社の集約サーバに接続したので、単に束を開けることで、束内部の調査データベースから得る推測および推奨情報へのアクセスが提供される。

更なる実施例においては、会社は管理組織によって提供されるニュースサービスの購読者になることに署名した。この会社によって受け取られるいかなる束も、タグを付けられた普通株についての５つの最新報告を含む。

他の例では、買い手側会社は、自社のアナリストが「売り」推奨とした株に付す束についてポートフォリオ・マネージャが時間を浪費するのを望まない。この種の問題の回避を助けるために、それらはそれらの集約サーバが束が付け加えられるあらゆる株主権についてのそれらの内部アナリスト推奨を表示するようにプログラムすることができる。

更なる実施例において、販売員が内部の情報源（例えばアナリスト）から束を受け取るときに、彼女は束が付け加えられた株主権に興味がある潜在的接触先の一覧を見たいと思う可能性がある。XIAと相互に作用するアプリケーションにおいて実行されうる多くの機能は、１９９９年５月１８日出願、出願番号０９／３１３８２９番（公開番号：PCT/USOO/13385）の「商取引の主題に関する情報を管理するための方法及び装置」と名付けられる出願、及び、１９９９年８月９日出願、出願番号０９／３７０６７１番（公開番号：PCT/USOO/21870）の「イベント情報管理システム」と名付けられる出願の、２つの同時係属中の出願において示される。これらの２つの出願のいずれもが参照取込によって本願明細書中に組み込まれるものである。

アプリケーションがXIAに与える機能は、また、集約サーバが通知作業を遂行するのを許可することができる。機能中で特定状態が検出されるとき、例えば束が特に不安定なセキュリティに関連するとして検出されるときには、XIAは機能と関連する通知処理を始めることができる。これらの処理は、目的地の端末がより目立つ警報ウインドウを発行するよう要求することからポケットベル・メッセージを始めることまで及ぶ。

図4を参照する。システムの構造は、更に詳細に説明される。図示のように、集約サーバは認証及びアクセス制御、協同プロトコル・アダプタ、通知サービス、電話通信サービス、内容配信及び検索サービス、協同サービスおよびデータ配信サービスを含む6つの別々の機能モジュールを含むことができる。これらのモジュールの機能および構造はまた、図示されているのとは異なる方法で分解することができる。しかしながらそれは、論理素子を結合し、分離し、適切なものとして作り直した場合に初めて可能となる。

協同サービスは、管理協同オブジェクトおよび文書のための一まとまりの事業ロジックおよび持続的アプリケーション・サービスである。それは、ユーザ、名刺、関係先、企業、グループ、束および受信ボックスといったオブジェクトを含んで、これらのオブジェクト用の標準的XML DTDを提供する。各々のサービスは、複雑なワークフローまたは商取引のそれらの一部を遂行すべく、適時情報交換可能な方法で、他のサービスと共働する特定の作業または一連の任務を成し遂げる。協同サービスは、集約サーバ（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またはCOM
APIを使用する。

XIA COM APIは、協同サービスにCOMインターフェースを提供する。それは、AGSを離れて存在し、XIAサービスAPIを介してAGSと通信する。クライアントは、クライアント・デスクトップ・アプリケーション（すなわちノーツ（登録商標）、アウトルック（登録商標）、ロイター（登録商標））が典型的である。XIAクライアント・デスクトップ・アプリケーションも、イベント／警報の通知を必要とする。軽量（例えばrvdでない）クライアント側ランデブは、XIA警報をXIA
COM APIに配信するために用いる。警報は、次に、XIA COM APIを通じて、クライアントにCOMイベントとして配信される。

内容配信サービスは内容が遠隔AGSから検索されるようにし、XIAトリガを通じて付加されるデータに混合する。データ配信サービス（DDS）は、配信された多くのデータ格納を同期させるように保つ。それは、ネットワークの全体にわたる多数の場所において「生きている」データ・オブジェクトの概念をサポートする。DDSは、ネットワークの全体にわたってオブジェクトを配信し、オブジェクトの潜在的な整合性を保証する。データ互換性サービスはデータ・アダプタ及びXML
DTDを提供し、ネットXMLデータを1つの改訂版から別の改訂版に変換する。それは、あらゆるAGSに存在する。電話サービスが提供するのは、ボイスメール・メッセージを束に取り付けられるようにすることである。支払い請求及び統計はネット・バックボーン上に存在する一組の情報サービスである。ランデブ・メッセージとしてネットを協同文書（例えば有効なXML文書として表示されるビジネス・オブジェクト）が通過する際、それはこれらのメッセージを聞いて、これに対応させて、その支払い請求および統計データを更新する。支払い請求データは、会計モジュールによって処理される。一実施例において、協同プロトコル・アダプタは、モジュラー式の方法で外部アプリケーションを有するインターフェースに与えられる。

次に、コンテント（内容）配信、検索及び混合サービス、フェッチについて更に詳細に説明する。フェッチは、データ配信のためのいかなる分散コンピューティング環境においても使用しうる点に注意されたい。

システムは、より大きいコミュニティの会員として総てにわたり機能している地球の全体にわたって配信される集約サーバの集まりを用いて設計される。各集約グループ及び各グループ内のそれぞれのサーバは、より大きいコミュニティの独立実体およびメンバとしての役割を担う。集約サーバ（AGSs）の間に配信されることを必要とするデータは２種類ある。集められたメタ・データ（すなわち、束メタ・データ）および該メタ・データが記述する実内容である。フェッチは、内容自体に全体的に関係して、タイムリで安全な方法でのそのデータの格納及び配信のためのフレームワークである。

フェッチは、データを格納し、その記憶空間を管理し、差込可能なコンテンツ源を許可する。「差込可能」とは、インターフェースがデータソースのために定義されることを意味する。よって第三者は、そのインターフェースを実装することができ、フェッチを通じ、システム・コミュニティのための内容源として作用することができる。

異なる集約サーバ上のフェッチ・サービス間のコンテンツ・ストリーミングを含むあらゆる通信は、Tibcoランデブ（RV）（登録商標）において起こる。フェッチは格納記述子を生成するが、それはフェッチ・サービスによって格納される特定の内容部分に対応する識別子である。この記述子は、グローバルに唯一的である。いかなるAGS上ものフェッチは異なるフェッチ・サービスによって生成される格納記述子によって識別される内容の要請にサービスを提供することができる。そして、それが他のAGS上にあってもよい。

フェッチは、誤りを許容し計測することが可能に設計されている。要求されるサービス回数は、実際的な範囲に最小化される。フェッチは、単一の要請への多くの反応を取り扱うことができる。下流のキャッシングを組み込むことができる。フェッチは、また、１つの集約グループ内だが異なるAGSs上のフェッチ・サービスの間で調和することができる。これにより、データソースを共有する場合に1つのフェッチ・サービスが別のフェッチ・サービスを引き継ぐことができるようになる。そして、それは並列の変更態様を避けられるように、修正可能データにロッキングを提供するべく必要とされる。

フェッチは、すでに利用できた内容を収縮（制限）させる能力を有する。それが修正された場合、サーブされた全コンテントはその内容の最も最新のバージョンである。コンテントは、性能を向上させるために外部の集約サーバに取り入れられてもよい。加えて、いかなるAGSも、当該内容のキャッシングは許可されないことを指定することができる。外部キャッシュのデータの暗号化が組み込まれているため、仮に、性能の許す範囲内において物理的にアクセスできてもデータは解読されることができないようになっている。フェッチは内容を格納しえても、それを他のフェッチ・サービスに配信することはできない。フェッチが格納している内容に関する情報は、AGS内部及びAGSの外側で利用できるその情報の部分集合の範囲内で利用できる。フェッチの操作特性は、リスタートなしで修正されることができて、その性能および動作に関する情報を提供することができる。

単に事業規則のみに基づくフェッチを設計することは結果として厳格な要求／応答システムになっている。そのシステムでは、内容が要求されるたびに内容がその所有者から検索されることで、所有者たちが自身のデータについての最終管轄権を保持できるようにしている。所有者が利用可能性を制限させることに決めた瞬間、誰もそれを得ることができないことになる。しかし、このように設計されるシステムは底知れぬパフォーマンスを有する。その理由は、それが不必要にネットワーク全体の大量のデータを繰り返し送っているからである。

単に性能のみを考慮してフェッチを設計することは結果として、コンテンツが所有者から１回送信され、各受取手の集約サーバが関係しているパッケージが削除されるまで、要求に応じてコンテンツを取り込み、サービスすることになる。これは、結果として、コンテンツ所有者が最終的な管轄権を、即ち、自分の瞬時的制限能力を失うことになる。もし所有者のAGSが機能しているが、そのネットワークコネクションを失う場合、所有者が内容を含んでいるパッケージを制限するが、パッケージ内容を利用可能にしておくことは可能である。しかしながらこれは、容認できない。

これらを解決するため、フェッチは、解放証明書を用いて知的キャッシングおよび最適的配信を用いる。即時制限が必要である内容は、解放証明書を必要とするものであるように印をしてもよい。内容が外部キャッシュ（貯蔵）にあり、その集約サーバ上のユーザが内容を要請するときに、コンテンツの入手先であるデータソースの所有者から解放証明書を得るまで、キャッシュは当該格納されたコピーの役割を果たさない。

解放証明書に加えて、追加所有が提供される。いかなるフェッチ・サービスも、それが他のフェッチ・サービスに配信する内容が貯蔵不可能であることを示すように構成されることができる。これにより、キャッシングに関する個々のAGSの事業規則を融通をきかせて容易に変化させることが可能となる。

個々の内容部分の中には、また、貯蔵不可能であることを示すことができるものもある。これが提供されるのは、ある特定の内容部分のためのデータソースが常に内容を修正しているということであってもよいので、外部サーバ上のキャッシングは意味をなさないからである。更新されたコピーが常に必要であるので、内容上のキャッシュ・スペースを使用することは浪費的である。

次に内容の配信について説明する。内容が第一に配信されることができるかどうかについて決定する3つの基本的な内容状態タイプがある。即ち、
・未登録（内容は、AGSの外側に配信されない）
・登録済私的（内容は、AGSの外側に配信されない）
・AGS内登録済公的（内容は、他のAGSsが利用できる）
ここにおいて、アクセスは与えられた全3種類の格納に加え、ネット上の他のフェッチ・サービスの登録された公的格納に対して与えられる。
内容は、次の2つの方法で配信されることができる。即ち、
・要請／反応、
・コンテンツ・プッシュ
もし、IOCD（知的最適内容配信）が可能で、コンテンツがIOCD対応なら、このコンテンツに対する第１の要望がコンテンツ・プッシュを誘発し、このデータの総ての受取人がキャッシングのためにそれを受信するようにする。

要求される前にコンテンツを有する外部サーバの方へ動かすことは、結果的に、以下の2つの方法での性能の大幅な向上をもたらす。
・外部のサーバ上のキャッシュから抜け落ち、再度要求しなければならないという状態でない限り、内容（コンテンツ）が一度だけそのデータソースから物理的に読み込まれる。
・もしも、ユーザがコンテンツを最初に要望した者でないときは、データがすでに該ユーザのキャッシュにあることからデータ転送は不要な可能性がある。
IOCDは、単なるオン／オフ状態を提供するのでなく、むしろ一組の規則に基づいて特定の内容を最適的に配信するように構成することができる。これらの規則は調整器上で可変であり、いかなるコンテンツも規則において使うことができる。規則構文の例としては、次の条件が満たされる場合には、最適的に配信するというものがある。即ち、

（SIZE>=300K MIME-TYPE="application/worldstreetXclient
NUM-RECIPIENTS> 3）

ネットワーク連結性に関係なく即時制限を利用可能にするという要件に加えて、1台のサーバが故障する場合、コンテンツが受取人に利用できるままでなければならないというのは同様に正当である。これは集約グループの概念によって取り扱われる。それは個人としての及び集合的に動作する一群としての集約サーバである。フェッチは、そのデータソース概念に基づきこれらのグループのデータにアクセスする。集約サーバ間でこれらのデータソースを共有できるようにすることは、我々にデータへの冗長的アクセスを与える。

能率的に、かつ高圧的にならずに、サービスを構成するには、フェッチが、誰がアクセスしているかとか、どれくらいの数のアクセスが起こっているかでなく、そのデータストアにアクセスしている他のサーバがあるかどうかの可能性を決定できることが必要である。フェッチが考慮する必要のあるのは、他者がそのデータソースにアクセスしている次の２つの明確な場合のみである。
・フェッチ・サービスの依頼人が若干の内容の特性を編集することを望む場合。このとき、ロッキングが提供される。
・解放証明書がサーバAにより発行されるが、その反応速度が３倍速いことから、外部フェッチ・サービスはコンテンツを供給するためにサーバBを使用することを決める場合、サーバBはそれが外部フェッチ・サービスによって与えられている解放証明書が実際に有効である（それが所有者によって発行された）ということを知っていなければならない。
第一の場合のロッキング及び解放証明書にアクセスしている（集約グループ内の）全サーバは、Tibco（登録商標）のランデブ誤り許容概念を利用するコア誤り許容サービス・フレームワークを用いて実現する。このサービス・フレームワークについては、総てのメソッド・コールはＲＶメッセージに変換され、当該サービスを動かしているサブネット上の他の誰にでも同報される。作動中のサービスのみがメソッド・コールへの応答を発信するが、サービスのインスタンスは総て、自身のメソッドがコールされるように選ぶことができる。これにより、全サービスを一貫した状態に保ことができる。

システムのデフォルト・インスタレーションは、ファイルシステムを使用するデフォルト・データソースを提供する。ほとんどの場合このファイルシステムは、ネットワーク付加記憶（NAS）の形式となり、グループの全集約サーバ間で共有される。

多くの製品が異なる種類の複製技術（例えばデータベース製品またはLDAPベンダーのような同期方法）を提供する一方で、システムはユニークな方法を用いて、コミュニティの中の全サーバがデータ配信サービス（DDS）の正当な一組のデータによって最新に保たれることを保証する。オブジェクトが格納され、削除され、適切に配信されることを確実にするように相互に作用するDDSに対して、4つの概念的な部分がある。これらは、以下の通りである。即ち、
・協同サービス・オブジェクト：これはそれらのインスタンスを堅持し、他の集約サーバにそれらの状況満載の情報を発行するのに資する。
・データベース・スキーマ：これは、物理的な格納を行うメモリ・オブジェクトを遂次化するテーブル定義および属性から構成される。該スキーマもまた、マイクロソフト（登録商標）上のSQLサーバに格納されるプロシジャ形式でのデータベース・コードを含み、予想済み及び予想外の質問をサポートするよう誘引される。下の線図は、協同サービス・オブジェクトとデータベース・スキーマとの関係を例示する。
・ＤＤＳエンジン：これは、例えば新規なオブジェクトの作成、既存のオブジェクトに対する変更、またはオブジェクトの全削除のようなオブジェクト動作の発行及び同化にあづかる。これは、発行及び同化に対してそれぞれ責任がある外向けサービス・マネージャおよび入り線サービス・マネジャの２つの部分から構成される。
・同期サービス：これは、全集約サーバが正しい順序でオブジェクト動作を受信して、処理することを確実にする。これは、スキーマ関連のデータ（例えばGUIDおよびVTDs）及び、マネージャ（例えばインバウンド・サービス・マネージャ内諸能力及び、転送サービス）から構成され、総ての情報が順番に処理されるということを保証している。

ここで示される図示的なDDSフレームワークは、多くの事業および技術的な要件を満たすように設計された。このシステムの他の態様と同様に、これらの要件には、システムのための異なる事業目的および本発明の範囲の外にある技術的な制約が与えられた場合には、様々な変更の余地がある。本実施例における要件は、3つのカテゴリ、即ち、集約サーバ内要件、集約グループ内要件および集約グループ間要件に区分される。

集約サーバ内では、アプリケーション・ロジックを通じて、もしくは臨時質問を通じて、ローカル・データベースに変更を加えることが可能でなければならない。いずれの場合においても、ＶＩＤ、GUID、オリジネータおよびタイムスタンプは適切に維持されなければならず、遠隔サーバは変化を発見しなければならない。DDS関連のいくつかのシナリオにおいて、ビジネス・ロジックによって定義される動作を誘引することが必要になるかもしれない。これらのフックが役立つかもしれない場合もある。即ちローカル・オブジェクトの保存前、ローカル・オブジェクトの保存後、及びリモート・オブジェクトの保存後である。ローカル・オブジェクトの保存前に起こるフックは、セーブを中止するかまたはオブジェクトを修正する能力を有していなければならない。

集約グループ内では、集約グループ内の全サーバが同じデータを維持しなければならない（おそらく小さい時間のずれはあろう）。集約グループは、任意の数のユーザに比例し、任意の大きさの地理的領域にわたることが可能でなければならない。ユーザがグループによって所有されるオブジェクトへの共有変更態様アクセスを持つことが可能でなければならない。これらのユーザが別々の機械にいること、そして、潜在的には、別々の地理的場所にいることが可能でなければならない。ユーザが別々のサーバ上のオブジェクトに並列的に態様変更を加える際には、誰の態様変更が承認されるかについての決定論的な意思決定がされなければならない。総てのサーバは、この判定について同意しなければならない。他のユーザがそれを検索したあとだが再保存する前にオブジェクトが修正された場合には、ユーザがなすいかなる変化も拒絶され、ユーザが当該オブジェクトの「汚れた」コピーを有したと通知されることを確実にするために最高度の努力を傾けなければならない。サーバが故障する場合、グループ内の他のサーバがそれにつつがなく取って変わることが可能でなければならない。いかなる失敗シナリオにもおいても、全サーバをバックアップし、互いに再同期させることが可能でなければならず、この再同期の結果は予測可能で、合理的であり、整合がとれていなければならない。全サーバは再同期の後に同じデータを含まなければならない。遠隔で見えるいかなるデータも遠隔マシン上で一貫した状態においてなければならない。集約サーバ間でバランス・ユーザをロードすることが可能でなければならない。集約グループ内では、ただの一つの故障点もあってはならない。グループ内のサーバは、それぞれ独立に作動しなければならない。1台のサーバは、他のサーバに起こっている処理のためのボトルネック（隘路）であってはならない。オブジェクトを、グループ内には発行されても、ネットワークからは見られない状態で保存することが必要かもしれない。

集約グループ間で、集約サーバは、遠隔集約グループによって所有されるデータに関する整合性を維持することが可能でなければならない。集約サーバでは、当該グループが保有するデータを修正することのみを可能にしなければならない。同期が失われるときには、再同期位相のネットワーク「洪水」を避けるために最高度の努力が傾けられなければならない。いくつかのデータを他のいかなる集約グループにもさらすことなく、ローカル集約グループ全体に亘って同期させることが可能でなければならない。ＤＤＳにおけるビジネス・オブジェクトは、ＸＭＬ文書として表現するべきである。これらの文書は、ＤＤＳ外で使うことができる。使用されるＸＭＬフォーマットまたは所与の種類のオブジェクトは、時間とともに変化することができる。異なる集約グループが異なるバージョンのソフトウェアを実行させることが可能でなければならない。新旧のＸＭＬフォーマット間の転換は、自動的に取り扱われなければならない。

以下の使用事件は、ＤＤＳの動作を例示する。
・ユーザは、ＸＭＬ ＣＤとしてＸＩＡを通してオブジェクトを嵌入する。分散オブジェクトは、ＣＤからインスタンスを生成される。カスタム動作が実行されている場合には、オブジェクトは通知エンジンによって送信される。これらのカスタム動作は、セーブの拒否かオブジェクトの修正かのいずれかをすることができる。次に該オブジェクトは、データベース（おそらく、多数のテーブルにわたって）に保存される。発信者は自動的に現地の発信者にセットされる。そして、新規なＧＵＥＤは自動的に生成され、新しいバージョン識別子（ＶＩＤ）はＶＩＤサービスから検索される。該オブジェクトが保存されたあと、それはＴＩＢＲＶメッセージ内で、他の集約サーバに対して同報されるＸＭＬフォーマット化されたＣＤに変換される。
・シンクロナイザ・サービスがＴＩＢＲＶメッセージ内のＣＤを受信する。分散オブジェクトは、ＸＭＬデータに基づいてインスタンスを生成される。オブジェクトがデータベースに保存されるときに、それは通知エンジンに送られる。遠隔オブジェクトであるので、通知エンジンはそれを修正することができないかまたは変化を拒否することができない。該オブジェクトは発行されない。これは、遠隔ホームに帰属するからである。
・ソフトウェアの以前のバージョンを実行している集約サーバからの同期サービスへのＣＤ。同期サービスは、オブジェクト・タイプおよび遠隔かつローカル・タイプ・バージョン番号に基づいてクラス名を生成する。このクラスは、ＷｏｒｌｄＳｔｒｅｅｔからロードされて、旧フォーマットから新規なフォーマットまでＸＭＬを翻訳するために用いる。該クラスが利用できない場合、フォーマットは不変であるとみなされる。保管が、それから前の使用事件として進行する。
・ＣＤが、予想以上に高度のＶＩＤをもって同期サービスに到着する。オブジェクトを保存する代わりに、同期サービスは、再同期要請を、それが受信した最後のＶＩＤより高いＶＩＤを有する全オブジェクトを要請している遠隔サーバに送信する。
・ＣＤが、予想以上に低度のＶＩＤをもって同期サービスに到着する。（おそらく他のサーバが再同期を要求したという理由によりCDは無視される。）
・ローカル・オブジェクトが削除される。該削除はTIBRVメッセージとして同報される。そして、該削除されたオブジェクトについての参照が、新ＶＢＤを有するdeleted_objectsテーブルに加えられる。
・ＣＤが、ローカル・オブジェクトを表す同期サービスに到着する。該オブジェクトは、すでにデータベースにあるので、無視される。
・ローカルのインストールがアップグレードされる。サーバは、以前のローカル・バージョンより新規なバージョンによって作成された全リモート・オブジェクトを要求している特別な再同期要請を発信する。（これらのローカル・バージョンのオブジェクトが遠隔オブジェクトからのデータの総てを含むことができるというわけではない。これは、それらが保存される前に、翻訳過程を経なければならないからである。）オブジェクトが現れるときに、それらはデータベースに再保存される。（これは該オブジェクトに対する本当の変更ではないので、通知はあってはならない。また、旧ＶＥＤを有しているからといって第5の使用事件内であるとして拒絶されるようなことがあってはならない。）

データベース・スキーマは、DDSをサポートするために特別に準備することが必要である。第1の要件は、データベースのあらゆるテーブルに以下の3本の柱がなければならないということである：
発信者
guid
ＶＩＤ
各々のguid／vid一組は、特定のオブジェクトに特有である。該オブジェクトが多数のテーブル（そして、いくつかのテーブルの多数の列さえ）にわたって広げられる場合、同じguid／vidはそのオブジェクトと関連するあらゆる列にあることになる。各々のタイプ／発信者一組に対して、vidの順序は維持される。オブジェクトが修正されるか、更新または削除されるたびに、新しいVIDがシーケンスから割り当てられる。これらのVEDにより、シンクロナイザが、逸失した最新版を検出して、逸失データを検索することができるようになる。VIDの順序性がアプリケーション・ロジックおよび臨時質問間で共有されなければならないので、新しいVIDは別々のVIDサービスから検索されなければならない。（当該VIDはまた、格納された手順によって維持されることが可能だが、これはアプリケーション・ロジックの余分のデータベース質問を加える。）

ローカル発信者の一覧を示すテーブルが、維持されなければならない。これが、アプリケーション・ロジック、同期サービスおよび臨時質問によって、オブジェクトがローカル或いは遠隔かを決定するために用いられよう。

臨時質問の同期および削除の再同期をサポートするために、トリガがあらゆるテーブルに必要である。（DDS（例えば_deleted_objects）をサポートしているワーキングテーブルを除く）これらのトリガは、テーブルが臨時質問によって修正されるときに、新しいVIDが関連したテーブルの総ての関連した列に割り当てられ、伝播されることを確認することが必要となる。それも、オブジェクトが完全に削除される（第１テーブルへの入力が削除される）ときに、新VIDを有する_deleted_objectsテーブルに１列が加えられることを確実にすることが必要となる。この種のトリガの機能性の輪郭は、次の通りである。
・処理を開始せよ。
・臨時質問でなければ、スキップせよ。これが臨時質問であるかどうか発見することができる方法が、次のように２つある：1）各アプリケーション・プロセスがトリガが確認することができるテーブルに、そのスピッドを入れる格納されたプロシジャをコールする、または2）トリガが、該プロセスのDBLIB_NAMEをチェックし、同意に達したストリングをチェックすることができる。
・トリガの挿入されたテーブルからVIDを得る。新しいVIDがすでに、_triggersテーブルにある場合、VIDの存在がこのテーブルが他のテーブルのトリガの一部として更新されているという事実の信号を送るので、直ちにリターンする。
・唯一的なVIDを得る。
・_triggersテーブルに唯一的VIDを入力する。
・関連した全VIDテーブルのVIDを更新する。
・_triggersテーブルからVIDを削除する。
・このトリガが削除であって、なおかつ、該削除が「マスター」オブジェクトを取り除く（もはやデータベース中にオブジェクトは存在しないことを意味する）場合、このオブジェクトは新VIDを有する_deleted_objectsテーブルに加えられなければならない。
・処理を終了する。
種類関係表を保守整備することによって単一の格納済プロシジャの大部分の過程を自動化することが可能にもなろう。この表の各列は、次の3つの情報を含む。
type_name
table_name
is_primary

これにより該格納済プロシジャは、総ての関連した表を（type_nameによって）見つけて、どのものが主たるテーブルであるかを発見することができる。それはまた、システムの種類のリストを発見するために同期サービスおよびVIDサービスによって使われることができよう。

DDSエンジンは、DDS内容を含んでいるTIBCOメッセージを発行し、受信するためのAPIを提供する。それは、数種類のメッセージ（挿入、更新、削除、再同期、バージョン同期およびハートビート）およびこれらのメッセージを発行し、受信するためのインターフェースとオブジェクトを定義する。それは、メッセージが受け取られる際にどんな動作がとられるべきか、とか、発行されたメッセージの内容の出所については、定義しない。これは、クライアントのDDSエンジンによって定義される。

具体的なメッセージ・クラスは次の６つありうる。InsertMessage（挿入メッセージ）、UpdateMessage（更新メッセージ）、DeleteMessage（削除メッセージ）、ResyncMessage（再同期メッセージ）、VersionSyncMessage（バージョン同期メッセージ）、HeartbeatMessage（ハートビートメッセージ）。コントローラ・クラスには、次の2種があり得る：InboundController（インバルンド・コントローラ）およびOutboundController（アウトバウンド・コントローラ）。これらのコントローラは、メッセージの聴取／発行を司る。メッセージの処理／生成をカスタマイズするためにコントローラと共に登録できるインターフェースがいくつかありうる。これらには、ChangeCommitter（チェンジ・コミッタ）、ChangeFactory（チェンジ・ファクトリ）およびLastVersionFactory（ラストバージョン・ファクトリ）が含まれる。

分散ビジネス・オブジェクトの構築用のフレームワークが必要である。このフレームワーク上に構築されるビジネス・オブジェクトは、該ビジネス・オブジェクト開発者によって最小の努力でDDSの以下の態様をサポートしなければならない。即ち、
・ビジネス・オブジェクトを、ローカル・データベースに格納すること。
・ビジネス・オブジェクトをXMLフォーマットに／から、変換すること。
・格納前／後、及び、発行前／後に通知エンジンに接続すること。（効率のために、通知プロセスは、部分的にビジネス・オブジェクト・クラスそのものに組み込まれることができる。）オブジェクトは、このプロセスで修正もしくは拒絶されうる。
・TIBRVメッセージにおける挿入／更新／削除の発行。
総ての分散ビジネス・オブジェクトは、以下の特徴を有しなければならない。
・それらは発行者、guid及びvid（ヴァージョン識別子）の３つの識別特性をもっていなければならない。発信者は、オブジェクトの「ホーム」を特定するために用いられる。guidは、独自にネットワーク上の全サーバ全体に亘るオブジェクトを唯一的に識別するために用いられる。vidは、データベースを同期に保つために用いるオブジェクトのためのバージョン番号である。「データベース・スキーマ及びトリガ」セクションに、これらの分野に関する詳細なより多くの情報がある。
・新規な分散オブジェクトは、自動的にGUEDsを生成し、自動的に発信者をセットしなければならない。それらはまた、VIDサービスからそれらの唯一的なVIDを獲得しなければならない。
・更新された分散ビジネス・オブジェクトは、VIDサービスから自動的に新しいVIDを得なければならない。
・分散ビジネス・オブジェクトは、それらが局所的にまたは遠隔で起こったかどうか決定することが可能でなければならない。
・分散ビジネス・オブジェクトは、データベースに自身を格納することが可能でなければならない。これは、既存のデータベース・オブジェクト持続フレームワークに基づく。
・それらのGUIDに基づいて分散オブジェクトを調べることが可能でなければならない。この機能性は、旧式のデータベース・オブジェクト持続フレームワークに基づく。データベース・オブジェクトからの他の静的検索方法もまた、機能し続けなければならない。
・分散ビジネス・オブジェクトをXML形式で表現することが可能でなければならない。全分散オブジェクトで利用可能なデフォルト反射ベースの方法があるが、個々の種類の分散オブジェクトはカスタムメイドのDTDを使用しているこの挙動を越えるように望むことも可能である
・XMLから分散ビジネス・オブジェクトを初期化することが可能でなければならない。全分散オブジェクトで利用可能なデフォルト反射ベースの方法があるが、個々の種類の分散オブジェクトはカスタムメイドのDTDを使用しているこの挙動を越えるように望むことも可能である。
・分散オブジェクトの各々のタイプが唯一的なタイプ名（デフォルトでは、クラス名）およびタイプ・バージョン番号を含まねばならない。当該オブジェクトのためのXMLスキーマが変化するいかなる場合も、このバージョン番号は、増加しなければならない。このタイプ・バージョン番号により、バージョンの不適当な組合せを検出し、自動的にバージョン・トランスレータを発見することが可能となる。変換器群がネットワークで利用可能であって、当該タイプ・バージョン番号は正しく定められている場合は、このプロセスは自動的に起こることになる。
・遠隔シンクロナイザがバージョンに関するコンフリクトを解決することができるように、タイプ名およびタイプ・バージョン番号が、DDSエンジンによって作成されるTIBRVメッセージに加えられなければならない。
・分散ビジネス・オブジェクトが格納前／後、及び発行前／後で通知エンジンと通信しなければならない。該通知エンジンは、ローカル・オブジェクトに対する変化を拒否して、ローカル・オブジェクトに修正をすることが可能でなければならない。これらの通知動作は、独立型通知エンジンに向かって対話するというネットワークのオーバーヘッドを避けるために、分散ビジネス・オブジェクトのクラスに登録されることも潜在的に可能であろう。
レガシー・データベース・オブジェクト・コードに必要な変化が最小であるような方法で、分散オブジェクトは実行されなければならない。フレームワークの一図解例を図5のクラス線図に示す。

システムによって定義される分散コミュニティの重要な側面は、それがピア・ツー・ピア方式で作用するために、各々がシステムの協同サービス・オブジェクトを格納し、その役割を果たすということである。基盤（インフラストラクチャ）サービスは、これらのオブジェクトがコミュニティの中で安全に、かつ、能率的に配信されることを確実にするための機構を提供する。

このシステムは、ワールドストリート・ネットのオブジェクト及びリクエストの内部トラヒック対応のインフラストラクチャ・サービスに向けるためのマネージャとして作動する往復の束サービスを含むことができる。各々のインフラストラクチャ・サービスは、ほとんどいかなるシステム・オブジェクト（例えば束、ユーザ、プロフィールまたはディレクトリ）にも適用されうるサービス群を提供する。これらのインフラストラクチャ・サービスは、以下の通りである。
・オブジェクト複製および同期サービスは、特定のグループ内で作動しているサーバの総てがそれらが必要とするオブジェクトの正しい一組によって最新に保たれることを確実にする。例えば、集約サーバは、ディレクトリ内で一組のユーザを所有することができる。変化が局所的な場合、当該変化は、この情報にアクセスできなければならない他の総てのサーバに対する複製である。
・束検出及び検索サービスは、必要なときに、束を最適にとってくる役割を果たす。検出サービスは、束があるかもしれない場所を、それが外部であれ、ローカル・キャッシュ内であれ、決定し、適切なセキュリティ・ステップを与えることで、正当権限ある者のみが束コンテンツへアクセスできるようにする。この束内容（コンテンツ）は、発行者とのオン・デマンド対話によって取り扱われることができるか、または生きているアクセス期間にもとづくようにしてもよい。
・ルート最適化は、必要な資源にアクセスするのに最適なネットワーク経路が選択されることを確実にする。各々の集約サーバは、ホップ、音カウントおよび物理的な接続タイプに由来するネットワーク発見的教授法を含んでいる動的なネットワーク経路テーブルを維持する。管理人は、明確に好適な経路を定め、例えばある特定の種類のトラヒックが個人的なネットワーク上のみを流れるように定めることができる。
・内容混合サービスは、束タイプ、著者（発行者）、受取人、転送先の装置または他の基準に基づいてカスタムメイドのコンテンツ・コレクションを作成するために束場所および検索サービスと相互作用する。内容混合サービスは、例えば様々なプレゼンテーションのためのカスタム・テンプレート、外部サービスからの特定コンテンツ要求、あるいは、オリジナルの束内でのコンテンツの削除または置換といったものを含むことができる。内容混合の目的は、瞬間的な決定をするのに必要な全情報を受信者に配信するアイデアに対して文脈を形成することである。
・データ互換性および変換サービスは、異なるバージョンのシステムがDTDの現在の各種セットと相互にやりとりできる能力を提供する。XSL変換を用いることで、XML文書（全部の束及びメタ・データがこれに当る）は、この集約サーバ上で動作するある種バージョンのサービスに必要な方言に翻訳されることができる。その上、これらのサービスは会社内での使用のためにDTDを拡張して利用することで、会社は財産性ある情報を社内使用用として含めつつ外部には公開されないように落とすことができる。
・電話通信およびメディア・サービスは一まとまりの第三者ソフトウェア（例えばマイクロソフトMedia Server（登録商標）およびEnvox（登録商標））、及び、ハードウェア（例えば対話的電話通信カード）であり、これらは束コンテンツに対し統合音声メッセージ・サービス及びストリーミングメディア・サービスを提供する。これらは、束XMLの範囲内で埋め込まれる特定のタグを経由して束に織り込まれる。
・統計エンジンも、外部の会計システムに支払い請求サービス・データを提供する。統計エンジンは、ユーザがいつ束を発行し、いつ束を要求したかを検知する往復束サービスをメタ・データが通過するのを通じて、束の活動を追う。この情報は次に統計データベースの範囲内で集計され、このデータは支払い請求目的のためのホスト対象サービスと共有される。

図6は、オブジェクトが物理的にあるデータベースに接続される方法を示す。注意すべき重要な点としては、グローバルにユニークな識別子（GUED）及びバージョン識別子（VID）の作成が全体処理の一部分として、データベースの範囲内で実行され、VTDsが無駄にならないことを確実にするということである。一旦記録がうまくデータベースに書き込まれると、メッセージは変化を公表するシステム・コミュニティに発送される。

図7は、これらの変化が他の集約サーバに発信される過程を例示する。これはすべてが予想通りに起き、シーケンスを外れる情報がない場合の典型的ケースである。オブジェクトに変化を通知するオブジェクトは、当該オブジェクトの所有者になる。というのは、このようなオブジェクト所有権は、財産権的情報を許可を得ない者が編集するのを防止するために、許可証として付与したり無効にしたりできるようにするからである。

図8は、オブジェクト変化情報がシーケンスを外れて受け取られる場合のシナリオを例示する。これは、オフラインで動作するかまたはコミュニティ内から一定時間切断されているサーバの結果であってもよい。メッセージがシーケンスから外れて受け取られると、これにより受取人の転送サービスが起動し、受信していなかった可能性のある全変化を要求する。発行サーバのもつ転送サービスは、転送メッセージを一時的に一列に並べ、多数のサーバが一斉に同一の転送シーケンスを要求したとしてもネットワークからあふれないようにする技術を備える。

図9を参照すると、システム・オペレーションは非信頼相２０とそれに続く信頼相２２という2つの全体的な位相を含むことができる。非信頼相の間は、買い手側ユーザは、自身との間で信頼関係を結ぶのを奨励するために売り手側ユーザに勧誘状（招待状）を送ることができる（ステップ24）。同時に、売り手側ユーザは、ネットワーク上の売り手側プロバイダを捜すためのネットワーク・ディレクトリ・ツールを使用することができる（ステップ26）。そして買い手側および売り手側ユーザは、信頼関係を結ぶことができる（ステップ28）。

信頼相22の間、売り手側ユーザは、一以上の買い手側ユーザに対して束を準備して、送る（ステップ30）。これらの束がユーザのプロフィールにおける設定にかなう場合、ユーザはその束を受信する（ステップ３２）。次にユーザは、束と関連する情報をチェックし、システムを通じて、或いは他のチャネルを介してこの情報に応答することができる。

信頼相において、ユーザはインフラ機能へのアクセスを獲得する。この相の範囲内でさえ、信用について段階が存在し得る。その結果、特定の関係には限定的な機能のみが利用可能である。信用は、いずれの関係者のオプションでも制限づけることができる。非信頼相の間、ユーザは勧誘を通して情報交換を行う。例えば、販売員は特定の会社での買い手側連絡先の総てに対し勧誘状を送信するかもしれない。そのユーザは、その会社で自身がやりとりする全個人に対し、名刺を作り上げ送信することによってこれを行うことができる。当該関係の創始者は、彼（女）の束の品質のサンプルとして、一つ以上のすでに既存の束を勧誘（状）にリンクする能力を有する。

受取人は、勧誘(招待)を受領し、結果として生まれる関係に異なる関係レベルを与えることができる。これらのレベルは、情報量および関係存続の間受け取られる束に用いられる通知種類に影響を与えうる。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)と呼ばれている機能は、送信される総ての束の非グループ化ダンプの返還を要求することができる。束撤回(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つのアプリケーションだけまたはユーザだけが一度にオブジェクトを編集することができることを保証している「ロッキング」機構を備えている。その結果、同時編集による衝突は決してありえない。

あらゆるデータ・オブジェクトは、唯一的な１２８ビットの識別子を有する。この識別子は、データ・オブジェクトの身元というだけでなくデータ・オブジェクトのバージョンも含む。加えて、異なる種類のデータ・オブジェクトのために、あらゆるサーバは、バージョン識別子を保持する。この識別子は、サーバ及び、そのデータ型にあてはまる総てのデータのバージョンに特有である。データ・オブジェクトが編集されるか、加えられるか、または削除されるかするときはいつでも、サーバのデータ・オブジェクト・バージョン識別子は＋１増加する。

これらのサーバ・データオブジェクト・バージョン識別子は、規則的な鼓動でもって（概して5秒ごと）ネットワーク上同報される。ネットワーク上の他のサーバは、それらが各データオブジェクト・タイプについてあらゆるサーバから成功裡に受け取ったバージョン最新版の記録を保持し、共有データ・オブジェクトの変化を捕捉しきれなかった場合には、バージョン識別子からそれを認知することができる。ホームサーバを有する場合、ホームサーバに最後の成功更新に係るバージョン識別子を通信する。するとそれらは、該ホームサーバから総ての失われた最新版を受け取る。

更新は典型的には、ネットワーク・バンド幅を節約するために、全オブジェクトの完全な転送とはせず、編集（何が変化したか指し示すこと）としてのみ伝達される。その結果、該オブジェクトが正しく保存されることを確実にするために、更新版は常に正しい順序で実行されることになる。

たとえば、旧式のサーバが、最後に、創始サーバ206.35.232.146からデータ型4の状態37を受信し、状態44がそのデータ型には最新であることが鼓動からわかったとしよう。するとそれは、変化38、39、40、41、42、43および44を要請して、データ同期を回復するために、順番にそれらを実行するであろう。

データは、集約サーバのローカル・グループへの、または集約サーバのあらゆる中間関連物への配信において制限されることができる。たとえば、スケーラビリティ、パフォーマンス、グローバル・ネットワーク・トラフィックの最小化または他の理由のために、単一の会社は多数の集約サーバを有することを望むかもしれない。この種の場合、分散データベース・サービスは会社の集約サーバの範囲内で所有データと同期させるために用いる。交換集約サーバのサブセット全体にわたって同期されうる所有データの例としては、プロフィール及び注視リストを含む。その結果、ユーザは会社の集約サーバのいずれかを通じての交換にアクセスすることができる。

本発明によるシステムは、標準のメタ・データ・タグ、即ち事業言語定義（BLD）を使用することができる。各々のBLDは多数の値を含む特定の値を有しうる特定のキーワードである。キーワードに添付されうる値は、コミュニティ合意によって標準化されていてもよい。たとえば、証券業に供すべく定められるBLDは、セクタ、ティッカー、領域および国を含む。例えば、ロイター計測器コード（RICs）がセキュリティ識別子（株の場合はティッカー）として使われることができるが、こうすることで、典型的メタ・データ・タグは「Ticker==
AOL，AON，MSFT，INTC」であってもよい。

いったんBLDが規定され、当該キーワードがネットワーク全体にわたって特定の目的のために保持されると、統計エンジンが、このキーワードおよび特定の値を含んでいる束に応答するユーザの挙動のみならず、当該目的と関連するこのキーワードおよび値の使用に関する統計を集めるために統計エンジンが動作を開始する。もちろん、ユーザは専用のタグをそれらの束に加えることができる。統計エンジンはこれらの非標準キーワードの使用に関するデータを集めることができるが、キーワードの使用を分析する能力は制限される。

全産業のキーBLDには、発信者、企業及び束タイプが含まれる。これらのキーワードに基づく統計によりクライアントは、別の発信者個人もしくは企業の活動及び成功をトレースできる。証券業のためのキーBLDは、ティッカー、セクタ、地域および国である。

アプリケーションが束を作成するか、修正するか、またはダウンロードするときはいつでも、使用データは連続的に集められる。統計エンジンは、ほぼリアルタイムで使用データを集めて、統計的「断片」、すなわち活動の概要を作成する。次にこの活動は、適応するアルゴリズムに従ってコミュニティ会員に配信される。例えば、会員の中には、全統計を購読した者、限定的な統計を購読した者、或いは遅延版もしくは概要版統計を購読した者もいるかもしれない。

統計は大きく分けて、2つのタイプ、即ちリアルタイム及びヒストリカルがある。リアルタイム統計は、現在の活動（すなわち、直前１時間、直前一日、或いは直前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のシステムのための高度活性統計ウインドウの画面視図である。

符号の説明

a1,a2,…,an;…n1,n2,…zn 売り手側ユーザ端末
A1,A2,…,AN;…N1,N2,…ZN 買い手側ユーザ端末
s1,…,sn;S1,…,SN 集約サーバ
app1,…,appn;APP1,…,APPN アプリケーション層

Claims (21)

1. ネットワーク化された商業的やり取りの管理方法であって、
   情報を複数の束に組み立てるステップであって、各束はデータ要素、データ要素への参照、及び該データ要素について記述するメタ・データを備え、各データ要素はネットワーク中のデータ所有者のノード上に所在し続け、前記複数の束のうち少なくとも一つのバージョンが複数存在し、該複数のバージョンの各々は束バージョン識別信号によって識別されるステップと、
   前記ネットワークの異なるノードに対して、束バージョン識別信号を周期的に発行するステップであって、該束バージョン識別信号は前記データ要素に対する変更事項をアクセッサの前記ネットワーク・ノードに対して表示するものであるステップと、
   前記複数の束から前記メタ・データ及び前記データ要素参照を前記ネットワークを通じて配信するステップと、
   前記アクセッサが前記ネットワークを通じて配信された前記メタ・データ及び前記データ要素参照を用いて前記データ要素を選定するのに続いて、前記組み立てのステップにおいて組み立てられた前記複数の束中の前記データ要素のコピーを、それぞれのデータ所有者の前記ネットワーク・ノードから前記アクセッサのネットワーク・ノードまで配信するステップと
   を具備する方法。
2. 請求項１記載の方法であって、各束は前記データへのアクセス権限を有するアクセッサを識別するセキュリティ情報を含み、前記配信するステップは該アクセス権限を有するアクセッサのみに前記束を配信することを特徴とする方法。
3. 所有者とアクセッサとの間の信頼関係を交渉することで前記セキュリティ情報を規定するステップをさらに含むことを特徴とする請求項２記載の方法。
4. 前記配信するステップの前に、受け取る複数の束の配信元であるネットワーク・ユーザを有権限ネットワーク・ユーザのディレクトリから選定するステップをさらに含むことを特徴とする請求項２記載の方法。
5. 前記セキュリティ情報の形式は、該セキュリティ情報中に組織識別子が含まれることを許容することを特徴とする請求項２記載の方法。
6. 所有者の入力に応答して前記複数のメタ・データ要素のうちの一つを規定するステップをさらに含むことを特徴とする請求項１記載の方法。
7. アクセッサへのデータ要素のコピーの前記配信及び前記取引に関する関連情報を記録するステップをさらに含むことを特徴とする請求項１記載の方法。
8. 前記メタ・データには複数のティッカー・シンボル識別領域が含まれることを特徴とする請求項１の方法。
9. 前記束の少なくともいくつかを追加的情報を含む超束に入れ子構造にするステップをさらに含むことを特徴とする請求項１記載の方法。
10. 請求項９の方法において、各束は前記データへのアクセス権限を有するアクセッサを識別するセキュリティ情報を含み、束及びその超束の双方へのアクセス権限を有するアクセッサのみが該束及び該超束の双方を見ることができることを特徴とする方法。
11. 前記束及び前記超束の両方に対するアクセス権限を欠く受信者に対して代替的内容を提示するステップをさらに備える請求項９記載の方法。
12. 請求項９の方法において、前記束及び前記超束は異なるノードにおける異なる所有者を有し、前記配信するステップは前記束及び前記超束を該異なるノードから配信することを特徴とする方法。
13. 前記束は異なるタイプの１以上のファイルへの添付参照を含むことを特徴とする請求項１記載の方法。
14. 前記タイプには音声ファイル、ビデオ・ファイル、グラフィカル・イメージ・ファイル、フォーマット化された文書ファイルが含まれることを特徴とする請求項１３記載の方法。
15. 前記束の少なくとも幾つかは他の束への参照を含むことを特徴とする請求項１記載の方法。
16. 前記他の束への参照には返信された参照が含まれることを特徴とする請求項１５記載の方法。
17. 請求項１記載の方法において、前記メタ・データを配信するステップは該メタ・データへの更新情報をさらに配信し、前記方法は、前記識別信号に応答して、前記複数のノードの少なくとも一つから前記更新情報のコピーを要求するステップをさらに含むことを特徴とする方法。
18. 前記メタ・データの複数部分に基づいて前記束をフィルタリングするステップをさらに含むことを特徴とする請求項１記載の方法。
19. 請求項１記載の方法において、前記コピーを配信するステップは前記データ要素のピア・ツー・ピア転送、及び前記束中で参照された該データ要素へのピア・ツー・ピア・アクセスを含むことを特徴とする方法。
20. 請求項１記載の方法において、前記メタ・データ中の諸状況の検出に呼応してユーザに警告するステップをさらに含むことを特徴とする方法。
21. 請求項１記載の方法において、前記メタ・データ中の諸状況の検出に基づいてコンテンツを混合するステップをさらに含むことを特徴とする方法。

Images