(57)【要約】【課題】オンデマンド・ビジネス・コラボレーションなどの適用例で用いられるハイパーチェーン情報管理技法を提供すること。【解決手段】そのような技法によれば、ハイパーチェーン・アノテーション方法が提供される。そのようなアノテーション方法は、緩やかに結合されたビジネス・プロセス間の、または対話パートナと事業体の間の対話を可能にする。連携のためのアノテーション付き情報構成要素およびプロセス構成要素は、リンクとして表すことができる。さらに、オンデマンド・メッセージ交換、埋め込みステータス／状態情報、柔軟なコラボレーション用ビジネス・メッセージ交換パターン、およびコラボレーション用ディレクトリを実現するための技法が提供される。【選択図】図１【特許請求の範囲】
【請求項１】
少なくとも１つのエンティティが少なくとも１つの他のエンティティとのコラボレーション用情報交換に参加する際に使用する方法であって、
前記コラボレーション用情報交換に関連する情報への１つまたは複数のリンクを含むアノテーション・データを取得するステップと、
前記アノテーション・データの少なくとも一部を前記少なくとも１つの他のエンティティに送り、その結果、前記少なくとも１つの他のエンティティが、前記１つまたは複数のリンクのうちの少なくとも１つを選択することによって、前記コラボレーション用情報交換に関連する情報の少なくとも一部へアクセス可能にするステップと
を含む方法。
【請求項２】
前記リンクの選択が、前記少なくとも１つの他のエンティティが必要に応じて前記情報へアクセス可能にする、請求項１に記載の方法。
【請求項３】
前記リンクが、前記アノテーション・データを受け取った時刻と異なる時刻に、前記少なくとも１つの他のエンティティによって選択可能な、請求項１に記載の方法。
【請求項４】
前記少なくとも１つのエンティティと前記少なくとも１つの他のエンティティの間で転送されるメッセージに情報を埋め込むステップをさらに含む、請求項１乃至３のいずれかに記載の方法。
【請求項５】
前記埋め込まれた情報が、ステータス追跡機能を可能にする、請求項４に記載の方法。
【請求項６】
前記埋め込まれた情報の少なくとも一部が、１つまたは複数のエンティティにステータスまたはアクションについて通知するために利用される、請求項４または５に記載の方法。
【請求項７】
前記通知が、アラート・タイプの形をとる、請求項６に記載の方法。
【請求項８】
前記少なくとも１つのエンティティと前記少なくとも１つの他のエンティティの間で交換されるメッセージが、１つまたは複数のメッセージ交換パターンによって管理される、請求項１乃至７のいずれかに記載の方法。
【請求項９】
前記１つまたは複数のメッセージ交換パターンが、コンストラクト又はプリミティブを含む、請求項８に記載の方法。
【請求項１０】
前記１つまたは複数のメッセージ交換パターンが、非構造的情報交換フロー又は非決定的情報交換フローを制御する、請求項８に記載の方法。
【請求項１１】
前記取得するステップが、記憶から前記アノテーション・データを検索するステップをさらに含む、請求項１乃至１０のいずれかに記載の方法。
【請求項１２】
前記取得するステップが、前記アノテーション・データを生成するステップをさらに含む、請求項１乃至１１のいずれかに記載の方法。
【請求項１３】
前記アノテーション・データが、（ｉ）組織的データ・エンティティの指示と、（ｉｉ）連携エンティティの仕様と、（ｉｉｉ）連携エンティティに関係するコンテンツ・タイプの仕様と、（ｉｖ）アクセス制御情報の仕様と、（ｖ）組織的データ・エンティティのための依存情報の仕様と、（ｖｉ）コラボレーション活動を定義するビジネス・コンストラクトのタイプの仕様のうちの１つまたは複数を含む、請求項１乃至１２のいずれかに記載の方法。
【請求項１４】
受信メッセージに埋め込まれた前記アノテーション・データおよびステータス情報の少なくとも一部が、通知される個人または当局を決定するのに使用される、請求項１３に記載の方法。
【請求項１５】
前記コラボレーション用情報交換が、設計コラボレーション・アプリケーションに従って実行される、請求項１乃至１４のいずれかに記載の方法。
【請求項１６】
少なくとも１つの連携エンティティが、前記設計コラボレーション・アプリケーションと通信する、請求項１５に記載の方法。
【請求項１７】
プロジェクト、タスク、および人員割当ての少なくとも１つの変化に基づいて、前記アノテーション・データおよび組織的データの少なくとも一方を修正する、請求項１乃至１６のいずれかに記載の方法。
【請求項１８】
少なくとも１つのエンティティが少なくとも１つの他のエンティティとのコラボレーション用情報交換に参加する際に使用する装置であって、
メモリと、
前記メモリに結合され、（ｉ）前記コラボレーション用情報交換に関連する情報への１つまたは複数のリンクを含むアノテーション・データを取得し、（ｉｉ）前記アノテーション・データの少なくとも一部を前記少なくとも１つの他のエンティティに送り、その結果、前記少なくとも１つの他のエンティティが、前記１つまたは複数のリンクのうちの少なくとも１つを選択することによって、前記コラボレーション用情報交換に関連する情報の少なくとも一部にアクセス可能に動作する少なくとも１つのプロセッサと
を含む装置。
【請求項１９】
前記リンクの選択が、前記少なくとも１つの他のエンティティが必要に応じて前記情報へアクセス可能にする、請求項１８に記載の装置。
【請求項２０】
前記リンクが、前記アノテーション・データを受け取った時刻と異なる時刻に、前記少なくとも１つの他のエンティティによって選択可能な、請求項１８に記載の装置。
【請求項２１】
前記少なくとも１つのプロセッサが、前記少なくとも１つのエンティティと前記少なくとも１つの他のエンティティの間で転送されるメッセージに情報を埋め込むように動作する、請求項１８乃至２０のいずれかに記載の装置。
【請求項２２】
前記少なくとも１つのエンティティと前記少なくとも１つの他のエンティティの間で交換されるメッセージが、１つまたは複数のメッセージ交換パターンによって管理される、請求項１８乃至２１のいずれかに記載の装置。
【請求項２３】
前記取得する動作が、記憶から前記アノテーション・データを検索することをさらに含む、請求項１８乃至２２のいずれかに記載の装置。
【請求項２４】
前記取得する動作が、前記アノテーション・データを生成することをさらに含む、請求項１８乃至２３のいずれかに記載の装置。
【請求項２５】
前記アノテーション・データが、（ｉ）組織的データ・エンティティの指示と、（ｉｉ）連携エンティティの仕様と、（ｉｉｉ）連携エンティティに関係するコンテンツ・タイプの仕様と、（ｉｖ）アクセス制御情報の仕様と、（ｖ）組織的データ・エンティティのための依存情報の仕様と、（ｖｉ）コラボレーション活動を定義するビジネス・コンストラクトのタイプの仕様のうちの１つまたは複数を含む、請求項１８乃至２４のいずれかに記載の装置。
【請求項２６】
前記コラボレーション用情報交換が、設計コラボレーション・アプリケーションに従って実行される、請求項１８乃至２５のいずれかに記載の装置。
【請求項２７】
少なくとも１つのエンティティが少なくとも１つの他のエンティティとのコラボレーション用情報交換に参加する際に使用する製造品であって、  実行されたときに、前記コラボレーション用情報交換に関連する情報への１つまたは複数のリンクを含むアノテーション・データを取得するステップと、
前記アノテーション・データの少なくとも一部を前記少なくとも１つの他のエンティティに送り、その結果、前記少なくとも１つの他のエンティティが、前記１つまたは複数のリンクのうちの少なくとも１つを選択することによって、前記コラボレーション用情報交換に関連する情報の少なくとも一部へアクセス可能にするステップと
を実施する１つまたは複数のプログラムを含むマシン可読媒体を含む製造品。
【請求項２８】
１つのエンティティが少なくとも１つの他のエンティティとのコラボレーション用情報交換に参加する際に使用する装置であって、
前記コラボレーション用情報交換に関連する情報への１つまたは複数のリンクを含むアノテーション・データを生成するためのアノテーション・データ生成ツールと、
生成したアノテーション・データを保存するための、前記アノテーション・データ生成ツールに結合されるコラボレーション用ディレクトリと、  前記アノテーション・データを管理し、その結果、前記少なくとも１つの他のエンティティが、前記１つのエンティティからアノテーション・データの少なくとも一部を受け取ったときに、前記１つまたは複数のリンクのうちの少なくとも１つを選択することによって、前記コラボレーション用情報交換に関連する情報の少なくとも一部へアクセス可能にする、前記コラボレーション用ディレクトリに結合されるアノテーション・データ・マネージャと
を含む装置。
【請求項２９】
前記アノテーション・データ・マネージャが、前記１つのエンティティと前記少なくとも１つの他のエンティティの間で発生し得る反復的アクションを表すコラボレーション・パターンに応答する、請求項２８に記載の装置。
【請求項３０】
前記コラボレーション用情報交換に参加する際に使用されるウェブベースのインタフェースをさらに含む、請求項２８または２９に記載の装置。
【請求項３１】
前記コラボレーション用ディレクトリが、複数の組織のコラボレーション用リソースを管理するためのハブとして機能し、それらの組織はビジネス・コラボレーションを実行するための中心場所としてハブを使用する、請求項２８乃至３０に記載の装置。
【請求項３２】
ビジネス・コラボレーション・システムを配備する方法であって、
少なくとも１つのビジネス・コラボレーション・プロセス・テンプレートを定義することと、
少なくとも１組のデータ構造を作成することと、
少なくとも１組のビジネス・コンストラクトの上で動作することができる情報交換用の少なくとも１つの他の連携エンティティを選択することと、
ビジネス・コンストラクトの選択された組をサポートするためにプロセス・テンプレートをカスタマイズすることと、
初期のコラボレーション用データ・エンティティを有するビジネス・コンストラクト内で少なくとも１組の活動を生成すること
のうちの１つまたは複数で使用される少なくとも１つのオンデマンド・ビジネス・コラボレーション・ハイパーチェーンベース管理装置を配備するステップ
を含む方法。
【請求項３３】
少なくとも１つのエンティティが少なくとも１つの他のエンティティとのコラボレーション用情報交換に参加することを可能にするため、サービス提供業者によってサービスを提供する方法であって、
前記少なくとも１つのエンティティが、
（ｉ）前記コラボレーション用情報交換に関連する情報への１つまたは複数のリンクを含むアノテーション・データを取得し、
（ｉｉ）前記アノテーション・データの少なくとも一部を前記少なくとも１つの他のエンティティに送り、その結果、前記少なくとも１つの他のエンティティが、前記１つまたは複数のリンクのうちの少なくとも１つを選択することによって、前記コラボレーション用情報交換に関連する情報の少なくとも一部へアクセス可能にするコラボレーション用情報交換システムを配備するステップ
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、情報管理技法に関し、より詳細には、オンデマンド・ビジネス・コラボレーションなどの適用例で用いられる情報ハイパーチェーン管理のための技法に関する。
【背景技術】
【０００２】
今日、事業体または企業は、もはや独立した存在ではない。したがって、企業は、自らが必要とするすべてのものを生産する必要はない。その結果、企業は、事業の一部を事業パートナにアウトソーシングすることができる。
【０００３】
例えば、技術設計コラボレーション・シナリオの場合、設計プロセスには、多くの人手によるまたは半自動化された作業が存在する。設計コラボレーションに参加する各企業は、作業の円滑な進行を維持するため、ロジスティック・サービス提供業者および顧客と共に仕事を行う必要がある。企業は一般に、日々の作業プロセスまたは新製品設計プロセスの一部として、実績が明らかなサービスおよび製品を利用することができる。
【０００４】
例えば、新製品設計の場合、製品を設計する企業は、構成部品供給業者、電子製造サービス（ＥＭＳ）、または契約製造業者と共に仕事を行って、協同で製品を設計しなければならない。構成部品設計作業の一部は、特定用途向け集積回路（ＡＳＩＣ）、バッテリ、またはマザーボードといった特別な構成部品の製作を専門とする設計パートナにアウトソーシングしてもよい。
【０００５】
この種のアウトソーシング・モデルは、情報テクノロジ（ＩＴ）産業および事業転換産業において、ますます有用なものとなっている。それは、業務を専門化した企業が、独力で達成し得るよりも革新的で高品質な製品またはサービスを生み出すことを可能にするアウトソーシング・モデルである。
【０００６】
しかし、効果的なアウトソーシング・モデルに対する本当の技術的な障害は、ビジネス・プロセス表現およびデータ変換ではない。本当の問題は、２以上の緩やかに結合されたビジネス・プロセス間の対話であり、そのようなビジネス・プロセスは、各企業独自のビジネス・プロセス、または複数の企業にわたる公的プロセスであることができる。
【０００７】
例えば、上記の技術設計コラボレーション・シナリオに戻ると、複数の人手によるまたは半自動化された作業が、製品設計プロセスには存在する。参加者は、電話、ファックス、または電子メールを使用して、材料表（ＢＯＭ）ファイルだけでなく、コンピュータ支援設計（ＣＡＤ）ファイルなどの設計仕様書および設計ファイルも交換し合う。その結果生じる問題は、進行中のプロジェクト、タスク、および交換された文書のステータスの監視に関連する情報など、リアルタイムな情報を設計ネットワークから取得するのが非常に難しいということである。
【０００８】
その上、設計文書および設計仕様のフォーマットが異なる様々な設計システムおよび製品開発管理（ＰＤＭ）システムが存在する。さらに、従来のワークフローは、既知のプロセスの詳細なステップを文書化するだけである。製品の技術革新がなければ、実際のところ、誰も個々の構成部品の設計の詳細についてすべてを知ることはない。したがって、それは、担当領域の構成部品を専門とする複数の業務提携者が参加する非決定的ワークフローである。さらに、製品設計プロセスの全ライフサイクルの間には、多くの例外的業務に対処する必要がある。
【０００９】
さらに、現在の企業間（Ｂ２Ｂ）アプリケーション・シナリオでは、膨大な数の文書を異なる企業の受け手に送らなければならない。文書は、適切な対応が取れる適切な人に届けられる必要がある。しかし、各文書は、任意の受け手に届けられることもできる。元の送り手の視点からは、彼または彼女は、他の誰が受け手になるか分からないこともある。したがって、複数の企業にまたがる文書送達チャネルは、または１つの組織内の文書送達チャネルでさえも、非構造的かつ非決定的な情報交換フローを形成する。
【００１０】
したがって、明白なように、ビジネス・プロセス統合の必要性が急速に増大している中、どのようにして非構造的かつ非決定的な情報交換を統一された方法で効率的かつ効果的に管理するかが、挑戦的な問題となっている。より具体的に、既存の情報交換技法が抱える問題の例を以下に示す。
１）交換される本当の文書から切り離された制御情報を表現する統一的なアノテーション・メカニズムの欠如。
２）非構造的かつ非決定的な情報交換フローの全局面をカバーする包括的なコラボレーション・パターンの欠如。
３）複数の情報源からデータを知的に集約するばかりでなく、非構造的関係グラフからリソースを動的に見つける効率的なオンデマンド情報メカニズムの欠如。
４）コラボレーション環境におけるデータ交換に関連する主要問題に対処する視覚的制御用の追跡可能情報埋め込みメカニズムの欠如。
【００１１】
したがって、オンデマンド・ビジネス・コラボレーションなどの適用例向けの改良された情報管理技法が必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明は、オンデマンド・ビジネス・コラボレーションなどの適用例向けのハイパーチェーン情報管理技法を提供する。
【課題を解決するための手段】
【００１３】
本発明の第１の態様では、アノテーション方法が提供される。例えば、少なくとも１つのエンティティが少なくとも１つの他のエンティティとのコラボレーション用情報交換に参加する際に使用する方法は、（ｉ）コラボレーション用情報交換に関連する情報への１つまたは複数のリンクを含むアノテーション・データを取得するステップと、（ｉｉ）アノテーション・データの少なくとも一部を少なくとも１つの他のエンティティに送り、その結果、少なくとも１つの他のエンティティが、１つまたは複数のリンクのうちの少なくとも１つを選択することによって、コラボレーション用情報交換に関連する情報の少なくとも一部にアクセスできるようにするステップとを含む。そのようなアノテーション方法は、緩やかに結合されたビジネス・プロセス間の、または対話パートナと事業体の間の対話を可能にすることができる。連携のためのアノテーション付き情報構成要素およびプロセス構成要素は、リンクとして表すことができる。そのようなアノテーション方法は、サービス提供業者によって顧客に提供されるサービスとして使用可能にすることもできる。
【００１４】
本発明の第２の態様では、オンデマンド・メッセージ交換が提供される。データは、送信前に集約されることを必要としない。したがって、データは、後で必要に基づいて検索されることができ、すなわち、断片化されたデータとして送信される。例えば、スキーマをもたないハイパーチェーン・アノテーション・データを最初に送信し、その後で詳細情報を取り込むことができる。そのような詳細情報の例として、機会データ、プロジェクト管理通知、設計ファイル、設計仕様、受け手の役割に基づくＢＯＭファイルを挙げることができる（オンデマンド・データ・アクセス／転送）。
【００１５】
本発明の第３の態様では、ステータス／状態情報が送信メッセージに埋め込まれる。この機能は、コラボレーション・プロセス（例えば、プロジェクト／製品管理）と文書（例えば、設計ファイル、ＢＯＭファイルなど）の両方ためのステータス追跡を可能にする。そのような情報は、ステータスについて、または取られたもしくは取る必要があるアクションについて、事業体または当局に（メッセージ交換によって）通知するのに使用することができる。アノテーション・データもこの目的で使用することができる。通知は、電子的なもの（例えば、電子メール）、または従来方式によるもの（例えば、郵便）とすることができる。
【００１６】
本発明の第４の態様では、柔軟なコラボレーション用ビジネス・メッセージ交換パターンが提供される。そのようなパターンは、複数のコラボレーション用ビジネス・プリミティブとビジネス・コンストラクトとを含むコラボレーション用ビジネス・コンストラクトを含む。したがって、ペイロード情報は、オペークであることができ、定義済タイプである必要はない。さらに、例えば、標準ボディを通す必要なしに複数の双務的提携を可能にする、非標準的なデータを含むための標準化された方法が提供される。
【００１７】
本発明の第５の態様では、コラボレーション用ディレクトリが提供される。これは、パートナ、プロジェクト、およびサービス・プロファイリング用のオントロジ持続記憶を含むことができる。アクセス制御要求は、識別情報管理ディレクトリ統合機能を利用することができる。さらに、本発明は、コラボレーション用ディレクトリにおいてウェブ・サービス使用可能ユーティリティを提供する。
【００１８】
本発明の上記およびその他の目的、特徴、および利点は、添付の図面と関連させて読まれるべき、以下に示す本発明の説明的な実施形態の詳細な説明から明らかとなるであろう。
【発明を実施するための最良の形態】
【００１９】
以下の説明は、例示的な技術設計コラボレーションの適用例を使用して、本発明を説明するものである。しかし、本発明は何か特定の適用例での利用に限定されるものではないことを理解されたい。むしろ、本発明はより一般に、例えば、企業間アプリケーションなどのコラボレーション環境において、効率的かつ効果的な情報管理技法を提供するのが望ましい任意の適用例に適用することができる。
【００２０】
例えば、「ハイパーチェーン」という用語は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）ファイルの個々のオブジェクトで使用されるようなハイパーリンクの概念を、ビジネス・プロセス、コラボレーション領域、アウトソーシングの異種のデータ・ストリームのための文書交換支援、プロセス追跡、視覚的制御などの概念を含む業務情報管理アプリケーションに拡張するアノテーション技術を一般に指し示すものと考えることができる。
【００２１】
ハイパーチェーン・アノテーション・データは、必要に基づいてリンクを辿り、文書をダウンロードすることで、ユーザによって使用されることができる。そのようなメカニズムは基本的に、階層的アノテーション・リンケージとして機能することができる。業務提携環境のあらゆる文書は、一定の属性によってアノテーションを付けることができる。任意の文書を交換する前に、ハイパーチェーン・アノテーションを交換することができる。ハイパーチェーン・アノテーションの受け手は、文書交換が要求（必要）に基づいたものになるように、しかるべく行動することができ、これは有利には、業務提携コミュニティ間での不必要な通信トラフィックを減らすことができる。
【００２２】
以下で図を用いて説明されるように、本発明は、オンデマンド情報交換モデルを提供する。そのようなモデルは、個々の受け手に合わせて作成され、送達および交換される情報の監視および追跡機能をサポートする。そのようなモデルは、オンデマンド情報交換モデル（ＯＤＩＥＭ）と本明細書で呼ぶハイパーチェーン・アノテーション技術によって実装される。
【００２３】
ＯＤＩＥＭに基づくハイパーチェーンは、事前定義されたコラボレーション・プリミティブおよびビジネス・コンストラクトを用いてビジネス・プロセスの動的コンフィギュレーションおよびインスタンス生成を自動化するようなｅビジネス・ソリューションを可能にするのに役立つ。その上、ハイパーチェーン技術は、中心ハブを必要としない業務提携（例えば、Ｂ２Ｂ）の分散化された柔軟で安全なピアツーピア構成をサポートする基礎を提供する。
【００２４】
発明者らは、一般的な業務提携用のハイパーチェーンに基づく情報管理を説明するための一例として技術設計コラボレーションのシナリオを使用する。上で述べたように、ビジネス・プロセス統合の必要性が急速に増大する中、非構造的情報（例えば、事前定義されていない情報表現構造）の交換を効率的かつ効果的に管理することは、重要な問題となっている。
【００２５】
より詳細には、本発明は、以下で図を用いて、リソース記述フレームワークすなわちＲＤＦ（http://www.w3.org/RDF）との関連で説明される。すなわち、本発明は、一連の設計データすなわち設計チェーン、関連する設計文書、および関連するアクションにアノテーションを施すための、「ハイパーチェーンＲＤＦ」と呼ばれるアノテーション表現を提供する。ハイパーチェーンＲＤＦは、メタ・データ交換に対処する機構を有するモデリング・システムであり、スキーマをもたないに近い。
【００２６】
したがって、ハイパーチェーンＲＤＦを使用する１つの利点は、ハイパーチェーンＲＤＦは固定的な事前定義されたスキーマをもたずに、様々なフォーマットのデータに対応することができるので、各アプリケーションごとにスキーマを事前定義する必要がないということである。したがって、ハイパーチェーンＲＤＦは、柔軟であり、ステータス追跡、ファイル交換などのアクションばかりでなく、設計データ、仕様、要件、材料表、パートナ・プロフィール、検査、設計、およびプロジェクト評価などのビジネス・プロセス、アクセス制御、提携パターンなど、業務提携で必要とされる様々なデータ・タイプにアノテーションを施すのに適している。
【００２７】
これ以降の詳細な説明は、最初がコラボレーション・システムの主要コンポーネントについての説明、その次が拡張された業務提携を可能にするのに用いられるメカニズムについての説明という順序で行われる。次に、拡張された業務提携のためのオントロジおよびオンデマンド情報送達モデルの詳細な構造についての説明が行われる。
【００２８】
最初に図１を参照すると、この図は、本発明の実施形態による、本発明を実施することができる分散ピアツーピア・コラボレーション・システムの例示的な構成を示している。図示されたように、コラボレーション・システム１００は、インターネットなどの分散ネットワーク１１８を介して、１つまたは複数の供給業者１１２、１つまたは複数のサービス提供業者１１４、および１つまたは複数の契約製造業者１１６と連携する、（プロジェクト・マネージャ、設計技師、および仕入／見積り請求（ＲＦＱ）マネージャがいる）製品会社１１０を含む。各事業体または企業は、ファイアウォール１２０によって保護されることができる。企業は、ＷｅｂＳｐｈｅｒｅ（ＷｅｂＳｐｈｅｒｅはインターナショナル・ビジネス・マシーンズの登録商標）ビジネス・インテグレーション・コネクト（ＷＢＩコネクト）などのＢ２Ｂゲートウェイのコラボレーション・エクステンション（ＣＥ）チャネルを介して通信する。しかし、企業は、そのようなチャネルを介して通信するようには限定されておらず、したがって、その他のチャネルおよび接続メカニズムを介して通信することができる。
【００２９】
そのような構成は、複数の企業にわたるビジネス・プロセス統合のためにウェブ・サービス技術およびゲートウェイ・ソフトウェアを利用する分散情報管理ソリューションの一例である。システムは一般に、以下のように動作する。最初に、実データをダウンロードまたは交換することができるロケーションを指示するハイパーリンクによって、交換される文書にアノテーションが施される。ハイパーリンクは、受け手がさらに情報の詳細を調べて、必要に基づいて情報をダウンロードするために取ることができるアクションの論理チェーン（ハイパーチェーン）を形成する。
【００３０】
すなわち、受け手が望むレベルの交換文書を直ちに送りつける代わりに、送り手は最初にアノテーションだけを送る。受け手はアノテーションを受けると、ハイパーチェーンを辿り、プロジェクト・マネージャ、設計技師、または仕入／ＲＦＱマネージャといった企業内での自らの役割および利用権に基づいて、必要とされるデータだけをダウンロードするためのアクションを起こすことができる。
【００３１】
一般に、上記の作業の実施を可能にするオンデマンド情報交換モデルは、以下の目標を達成するように設計される。（ｉ）事前定義されたスキーマを必要とすることなく、様々な非構造的データの情報交換用の柔軟かつ統一のとれたアノテーション表現を提供する。（ｉｉ）アノテーション・データ生成プロセスを自動化する。（ｉｉｉ）アノテーション・データに基づく情報交換のためのビジネス・コラボレーション・インタラクション・パターンを捕捉し、自動化する。もちろん、そのような本発明によるモデルは、様々な他の目標を達成することもできる。
【００３２】
ここで図２を参照すると、この図は、本発明の実施形態による、オンデマンド情報交換モデルに基づくハイパーチェーン構成を示している。上記の目標を考慮して、そのようなハイパーチェーン構成は、中心ハブを必要とせずに、柔軟な、分散化され、セキュリティ保護が施され、制御されたピアツーピア・ビジネス・コラボレーションをサポートする。
【００３３】
図２に示すように、ハイパーチェーン構成２００は、以下の主要コンポーネントを含む。
（１）コラボレーション・パターン２１０。このコンポーネントは、特定のビジネス・プロセスに関して提携する企業間で発生する反復的なアクションを表す。
（２）スキーマをもたないアノテーション構造２２０。このコンポーネントは、アノテーションのデータ・フォーマットを表す。
（３）アノテーション記憶２３０。このコンポーネントは、視覚的制御、情報送達および管理のためにアノテーション・データを保存する。
（４）アノテーション生成２４０。アノテーションを捕捉し、作成し、自動化するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）ベースのメカニズム。
（５）ハイパーチェーン・マネージャ２５０。このコンポーネントは、アノテーションを作成し、管理する。
【００３４】
どのようにオンデマンド・コンテンツが送達されるかを記述するのは送達方針であることを理解されたい。本発明は特定の送達方針／メカニズムに限定されるものではないが、使用できる４つのタイプの送達メカニズムについて説明する。
（１）スケジュールされたコンテンツ送達。所定の周期的なスケジュールで、情報コンテンツが受け手に送達されることができる。
（２）オンデマンドのコンテンツ送達。例えば、アノテーション・データと共に提供されたハイパーチェーン・リンクをクリックして、データをダウンロードしたり、１つまたは複数のファイルを１つの場所から別の場所に移動させるファイル転送サービスをトリガしたりする、ユーザ・リクエストに基づいた１回限りの送達。
（３）アクセス制御に基づいたコンテンツ送達。受け手の役割および利用権に応じてコンテンツを送達する。
（４）プッシュ・ベースのコンテンツ送達。アノテーション・データを添付ファイルと一緒に送る（一般に、このモデルは小さなサイズのファイルの転送に適する）。
【００３５】
本発明の情報交換モデルの基本的原理は、最初にスキーマをもたないハイパーチェーン・アノテーション・データを送り、次に受け手がハイパーチェーンを辿り、受け手の役割に基づいて、設計ファイル、設計仕様、ＢＯＭファイルなどの詳細な情報を、自己検索またはエージェント・ベースのファイル転送サービスを介して取り出すというものである（オンデマンド・ファイル転送）。なお、モデルは、設計ファイル、設計プロセス、およびＢＯＭに関連する処理しやすい情報をサポートする。
【００３６】
図２に示されるように、「業務提携者（１，２，．．．，Ｍ，Ｎ，．．．）」は、１つまたは複数の外部の事業体とのビジネス・コラボレーション・プロセスに参加する事業体である。「アプリケーション」（ｌ，２，３、．．．）は、バックエンド・アプリケーションを表し、ハイパーチェーン・マネージャは、アクション・マネージャ・コンポーネント（以下で説明）を用いて、これらのアプリケーションと既存のビジネス・プロセスとを統合する。「コラボレーション用ディレクトリ」は、ハイパーチェーン・マネージャによって管理されるアノテーション／メタ・データばかりでなく、プロジェクト、タスク、ユーザ、組織、文書などのビジネス・コラボレーション用のリソースを保存する。「ハイパーチェーン・ダッシュボード」は、人がそれを介してコラボレーション用ディレクトリに保存されたコラボレーション・リソースと対話する、管理および監視機能を提供するグラフィカル・ユーザ・インタフェース（ＧＵＩ）である。
【００３７】
以降のセクションでは、本発明によるハイパーチェーン構成の主要コンポーネントについて詳細に説明する。
【００３８】
Ｉ．オンデマンド・ビジネス・コラボレーション・オントロジ
オントロジすなわち一般に共有される知識は、交換される情報にアノテーションを施すため、ビジネス・セマンティクスを定義する。オントロジはコラボレーション基盤も提供する。そのような共有される共通知識がないと、参加者は、交換される情報を解読することができない。既存のコラボレーション・ソリューションは通常、各業務提携者サイドで事前設定された固定の知識に基づいており、これはコラボレーションの柔軟性および拡張性を低下させる。
【００３９】
ビジネス・コラボレーション・オントロジは、複数の産業にわたる基本オントロジに基づいている。本発明によれば、すべての業務提携者は、ビジネス情報を交換するために、基本オントロジを使用する。ビジネス・コラボレーション・オントロジは、明確化の目的でリソース記述フレームワーク（ＲＤＦ）モデルを使用する。アノテーションはオントロジの一部である。例えば、我々は、「サイト」、「組織」、「プロジェクト」、「タスク」、「要件」、「トランザクション」、「文書」、「アノテーション」などのＲＤＦリソースをＲＤＦスキーマで定義する。ＲＤＦスキーマは、すべての業務提携者が理解する必要がある基本オントロジ定義として働く。
【００４０】
発明者らは、一般的なビジネス・コラボレーションおよび技術設計コラボレーション向けの拡張用の基本リソースを、説明のために提案する。ビジネス・コラボレーション・オントロジは、追加のアノテーションのために拡張可能である。業務提携者は、自らのオントロジを定義することができ、追加のアノテーションを基本オントロジに追加することができる。基本および拡張オントロジは、一括されて、リソースおよびモデルを作成するのに用いられる１つの全体的なオントロジになる。コラボレーション・オントロジは、事前定義されたスキーマを必要とすることなく、様々な非構造的データの情報交換用の柔軟かつ統一のとれたアノテーション表現を提供する。その上、コラボレーション・プリミティブの一部としてのアノテーションを施されたステータスおよびアクセス制御によって、交換される文書ばかりでなく、プロセスも追跡し、監視し、制御することができる。
【００４１】
ＲＤＦに基づくビジネス・コラボレーション・オントロジは、すべての新たに追加されたエンティティをリソースとして取り扱う。したがって、既存のリソースを処理するのに用いる同じメカニズムを、新たに追加されたリソースを処理するのに用いることができる。ビジネス・コラボレーション・オントロジの拡張性および柔軟性という特徴は、アノテーション・データのスキーマについて考慮せずに、任意のアノテーションを定義することを可能にする。したがって、上で述べたように、ビジネス・コラボレーション・オントロジに準拠するハイパーチェーン・アノテーション・データは、スキーマをもたない。
【００４２】
ＩＩ．アノテーション構造
Ａ．ビジネス・コラボレーション・チェーン用の基本アノテーション
本発明によれば、アノテーション・データは、複数の組織にわたる全体的または部分的なビジネス・コラボレーションにアノテーションを施すのに使用される。アノテーション・データは、分散された情報へのリンクを提供し、コラボレーション・プロセスに関して、「可用性」や「実行可能性」ばかりでなく、「コンテンツ」、「構造的」、「ルーティング」、「ロケーション」、「有効期間／契約の継続」などを指定することによって、コラボレーション環境におけるデータ交換に関連する問題に対処する。ビジネス・コラボレーション用の様々なリソースのアノテーション・データは、グラフィカル・ユーザ・インタフェース（ＧＵＩ）またはアプリケーションによって作成され、永続的ストレージに保存される。その後、実行時に交換される情報にアノテーションを施すため、アノテーション・データを検索することができる。
【００４３】
今度は図３を参照すると、この図は、本発明の実施形態による、設計ハイパーチェーンの一例を示している。より詳細には、図３に示されるように、設計ハイパーチェーン３００は、アップストリームおよびダウンストリーム・データに関連があり、これらに平行なアノテーション・データを示している。
【００４４】
ハイパーチェーン３００には、３つの業務提携者３０２、３０４、３０６が示されている。各業務提携者は、後続の業務提携者に送られる設計ファイルまたはＣＡＤ（コンピュータ支援設計）ファイル３０８を記述するため、追加のアノテーション／メタ・データを追加する。設計コラボレーション・シナリオでは、通常、我々は、ローカル設計環境において基本情報を捕捉するため、設計ファイル（例えば、ＣＡＤファイル）および設計ファイル用のメタ・データ３１０を使用する。設計ハイパーチェーン・アノテーション・データは、分散環境における全設計チェーンとの関係ばかりでなく、特定の設計ファイル、既存のメタ・データ、それらの間の関係についての追加情報を捕捉する。
【００４５】
拡張されたビジネス・コラボレーション用のデータに効果的にアノテーションを施すため、コラボレーション用交換プロトコル（ＣｘＰ）が使用される。ＣｘＰは、アノテーション・データ用の階層的なトップダウン・アプローチを使用する。例えば、設計プロセス・モデルに基づく技術設計コラボレーション・シナリオでは、アノテーション・データは、例えば、設計コラボレーション・プロセス用のアノテーションで始まり、ＣｘＰに特有の設計活動のためのアノテーション、さらに技術設計コラボレーション・シナリオに関与する事業体によって使用される設計ツール用のアノテーションへと続く、階層的な表現に分割される。
【００４６】
技術設計コラボレーション・シナリオでは、階層的アノテーションは、以下のように利用される。ビジネス・プロセス・レベルのアノテーションは、下位レベルの設計コラボレーション・プリミティブに対する全体的メッセージとして機能する。それは、アノテーション・データに応答して何らかのアクションを取るよう受け手に命令する。
【００４７】
例えば、設計パートナＡは、設計パートナＢに設計要求（ＲＦＤ）を送りたい場合、それがＲＦＤ用であることを示すタグが付されたビジネス・プロセス・アノテーション・メッセージを送り出す。パートナＢは、アノテーション・メッセージを受け取ると、ビジネス・プロセス・アノテーションから受け取った情報に基づいて対応するアクションをとる。アクションは、設計要件に関するより多くの情報を検索するため、設計ファイルの設計活動アノテーション・リンクを使用すること、または設計プロセスについてより多くの情報を取得するため、設計プロセスの設計活動アノテーション・リンクを使用することなどとすることができる。アノテーション・データを処理する「プロセス」は、アノテーション内の主要情報（例えば、１組のアクションならびに対応する制約および方針を含むファイルを指示するアクション・リンク）に基づいて変化する。したがって、各プリミティブごとに、例えば、順序に従って、最初に１つのビジネス・プロセス・アノテーション・メッセージが送られ、それに異なるレベルの情報要求または応答あるいはその両方が続くといった、業務提携者間の１つまたは複数の対話が存在する。
【００４８】
ビジネス・プロセス・アノテーションを受け取った後、パートナは、アノテーションを調べ、それを自らのアノテーション記憶にマージすることができる。アノテーションが施されたリソースの１つについてより多くを知りたい場合、パートナは、例えば、設計ファイル・アノテーション・リンクなどのアノテーション・リンクを取得して、より多くの情報を要求することができる。送り手は、設計ファイル用のアノテーションを生成し、それをパートナに送り返す。設計ファイル用のアノテーションおよびツール・アノテーションは、設計コラボレーション用のデータ・ホルダとして機能する。それらは、ある方法で何らかの「データ」を使ってアクションを取るよう受け手に命令する。パートナは、アノテーションに基づいて、実際の設計ファイルを検索するかどうかを決定することができる。
【００４９】
設計活動アノテーションとツール・アノテーションの違いは、設計活動アノテーション・データは、拡張されたビジネス・コラボレーション基盤に特有であって、すべての設計活動に共通であり、ツール・アノテーション・データは、様々な設計ツールに特有であって、拡張されたビジネス・コラボレーション基盤からは透過的なことである。
【００５０】
今度は図４を参照すると、この図は、本発明の実施形態による、階層的なアノテーション構造を示している。より詳細には、図４は、ハイパーチェーン・マネージャ用に定義されるエンティティ・クラスの階層的なアノテーション構造４００を説明している。
【００５１】
図示されたように、ルート・クラス（４０２）はＳｉｔｅであり、事業体を表す０以上のＯｒｇａｎｉｚａｔｉｏｎクラス（４０４）に関連づけることができる。各Ｏｒｇａｎｉｚａｔｉｏｎクラスは、０以上のＰｒｏｊｅｃｔ（４０６）クラスに関連づけることができ、各Ｐｒｏｊｅｃｔクラスは、０以上のＣｏｌｌａｂＳｐａｃｅ（４０７）のほか、０以上のＴａｓｋ（４０８）クラスにも関連づけることができる。各Ｔａｓｋクラスは、０以上のＴｒａｎｓａｃｔｉｏｎ（４１０）クラスに関連づけることができ、各Ｔｒａｎｓａｃｔｉｏｎクラスは、０以上の（ＣｘＰ）Ｍｅｓｓａｇｅ（４１２）クラスに関連づけることができる。さらに各Ｔａｓｋクラスは、パートナに送られる要件を表す０以上のＲｅｑｕｉｒｅｍｅｎｔ（４１４）クラスに関連づけることができる。各Ｒｅｑｕｉｒｅｍｅｎｔクラスは、０以上のＡｎｎｏｔａｔｉｏｎ（４１６、要件を記述するためにメタ・データを含むことができる）、Ｓｐｅｃｉｆｉｃａｔｉｏｎ（４１８）、およびＲｅｆｅｒｅｎｃｅ（４２０）クラスに関連づけることができる。
【００５２】
Ａｎｎｏｔａｔｉｏｎ  Ｐｒｏｐｅｒｔｙ（４２１）は、実際のアノテーションが、例えば、ファイル名、作成者名、価格などから作成されるＪａｖａ（登録商標）クラスである。そのため、リレーションシップに「使用」と記されている。さらに、「Ｃｏｌｌａｂｓｐａｃｅ」は、拡張されたビジネス・コラボレーション・プロセスの一部である人的なコラボレーション・プロセスを実行するエージェントまたはブローカを表す。人的なコラボレーション・プロセス例は、チャット・プログラムを起動し、ディスカッション・フォーラムでディスカッション・スレッドを生成することなどができる。「０．．＊」は、結合関係が１対０以上であることを、すなわち、ソース・クラスを直線的な矢印（−＞）で指し示されるターゲット・タイプの０以上のインスタンスに関連づけることができることを意味する。この例では、Ｓｉｔｅは、事業体を表す０以上のＯｒｇａｎｉｚａｔｉｏｎクラス（４０４）に関連づけることができる。「１」は、１対１の結合関係を表す。
【００５３】
Ｂ．情報交換フロー用のアノテーション
今度は図５を参照すると、この図は、本発明の実施形態による、設計要求例のハイパーチェーン・アノテーション・データ・グラフ５００を示している。より詳細には、図５に示されるように、ＲＤＦモデル（またはＲＤＦグラフ）を使用する設計コラボレーション図は、設計要求（ＲＦＤ）メッセージ交換プロトコル用のアノテーション・データモデルを示しており、情報交換用の複数の属性を定義する。
【００５４】
グラフ５００は、全設計チェーンのＲＦＤメッセージ用のサンプル・ビジネス・プロセス・アノテーション・データ・インスタンスを示している。最も左のノードから始まるので、ＲＦＤ  Ｍｅｓｓａｇｅ５０２がルートであり、それは、メッセージの交換コンテキスト、ＲＦＤＴｒａｎｓａｃｔｉｏｎ、要求者、ＰＤＴ、および応答者、ＭｙＣｏｍｐｕｔｅｒＣｏｒｐを定義する「ｔｒａｎｓａｃｔｉｏｎ」（５０４）リソースを指し示す。ＲＦＤ  Ｍｅｓｓａｇｅは、ｒｅｑｕｉｒｅｍｅｎｔ（５０６）コンテナも指し示し、ｒｅｑｕｉｒｅｍｅｎｔコンテナは、例えば、Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｄｏｃｕｍｅｎｔ、ＤｅｓｉｇｎＦｉｌｅ、ＢＯＭ  Ｆｉｌｅなどの実際のフィールド５０８へのリンクを各々が含む、ｄｅｓｉｇｎ  ｓｐｅｃｉｆｉｃａｔｉｏｎ、ｒｅｆｅｒｅｎｃｅ、およびｄｅｓｉｇｎＰｒｏｃｅｓｓなどの複数のアノテーションまたはメタ・データをグループ化する。その上、「ｔｒａｎｓａｃｔｉｏｎ」リソースおよび「ｒｅｑｕｉｒｅｍｅｎｔ」リソースは共に、「ｔａｓｋ」（５１０）リソースを指し示し、「ｔａｓｋ」リソースは、「ｐｒｏｊｅｃｔ」（５１２）リソースを指し示し、両方のリソースは、ＲＦＤメッセージがどのプロジェクトおよびタスクに結び付けられるかを定義する。
【００５５】
アノテーション・データ・グラフ５００に基づいて、拡張マークアップ言語（ＸＭＬ）ファイルまたはデータ・ストリームが、アクセス制御情報ばかりでなく、設計ファイル、設計プロセスなどの設計要求（ＲＦＤ）プロトコルに関連するアノテーション情報を捕捉するため、ＲＤＦインスタンスを定義する。ＸＭＬデータ・ストリームがリレーショナル・データベースに保存できることに留意されたい。
【００５６】
以下の例は、全設計チェーンのＲＦＤメッセージ用のサンプル・ビジネス・プロセス・アノテーション・データ・インスタンスを示している。「ｔｒａｎｓａｃｔｉｏｎ」リソースは、メッセージの交換コンテキスト、ＲＦＤＴｒａｎｓａｃｔｉｏｎ、要求者、ＰＤＴ、および応答者、ＭｙＣｏｍｐｕｔｅｒＣｏｒｐを定義する。「Ｔａｓｋ」リソース、Ｔ６１ＭｏｔｈｅｒＢｏａｒｄＤｅｓｉｇｎ、および「Ｐｒｏｊｅｃｔ」リソース、Ｔ６１ＢｏａｒｄＤｅｓｉｇｎは、メッセージがどのプロジェクトおよびタスクに結び付けられるかを定義する。複数のコンテナが、以下のアノテーションまたはメタ・データ、すなわち、設計仕様アノテーション、Ｔ６１Ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｐｄｆ、設計ファイル・アノテーション、Ｔ２１ＭｏｔｈｅｒＢｏａｒｄＤｅｓｉｇｎＦｉｌｅ．ｃａｔ、ＢＯＭファイル・アノテーション、Ｔ２１ＢＯＭＦｉｌｅ．ｂｏｍ、設計プロセス・アノテーション、ｏｕｔｓｏｕｒｃｉｎｇＣｏｎｓｔｒａｉｎｔ、およびアクセス制御などのその他の関連アノテーションをグループ化するために定義される。例示的なアノテーション・データ・インスタンスは以下の通りである。
【００５７】
<rdf:RDF
<cbpm:RFD rdf:ID="007">
<cbpm:transaction>
<cbpm:Transaction
rdf:about=?http://www.pdt.com/dc/directory/transaction#007001?>
<rdf:type>&cbpm;RFDTransaction</rdf:type>
<cbpm:requester
rdf:resource="http://www.pdt.com/dc/directory/Organization#PDT"/>
<cbpm:responder
rdf:resource="http://www.pdt.com/dc/directory/Organization#MyComputerCorp"/>
<!--anything about theTransaction-->
</cbpm:Transaction>
</cbpm:transaction>
<cbpm:task>s
<cbpm:Task
rdf:about="http://www.pdt.com/dc/directory/task#T61MotherBoardDesign">
<!--anything about thetask-->
<cbpm:forProject>
<cbpm:Project
rdf:about="http://www.pdt.com/dc/directory/project#T61BoardDesign">
<!--anything about theproject-->
</cbpm:Project>
</cbpm:forProject>
</cbpm:Task>
</cbpm:task>
<cbpm:requirement>
<cbpm:Requirement
rdf:about="http://www.pdt.com/dc/directory/requirement#00d034334">
<!--anything about therequirement-->
<cbpm:specification>
<rdf:Bag>
<rdf:li>
<cbpm:Specification
rdf:about="http://www.pdt.com/pdf/T61Specification.pdf"/>
</rdf:li>
</rdf:Bag>
</cbpm:specification><cbpm:reference>
<rdf:Bag>
<rdf:li>
<cbpm:DesignFile
rdf:about="http://www.pdt.com/pdf/T21MotherBoardDesignFile.cat"/>
</rdf:li>
<rdf:li>
<cbpm:BOMFile
rdf:about="http://www.pdt.com/pdf/T21BOMFile.bom"/>
</rdf:li>
</rdf:Bag>
</cbpm:reference>
<cbpm:designProcess>
<rdf:Bag>
<rdf:li>
<cbpm:OutsourcingConstaints
rdf:about="http://www.pdt.com/outsourcingConstraint"/>
</rdf:li>
<rdf:li>
<cbpm:AccessControlrdf:about="http://www.pdt.com/accessControl"/>
</rdf:li>
</rdf:Bag>
</cbpm:designProcess>
</cbpm:Requirement>
</cbpm:requirement>
</rdf:RDF>
【００５８】
Ｃ．設計活動アノテーション
設計活動アノテーションは主に、設計コラボレーション・プロセスにおける制約にフォーカスする。例えば、設計要件、設計コンフィギュレーション／仕様、設計ファイル、ＢＯＭ、設計プロセスなどの複数のタイプの活動アノテーションが存在し、各々は異なる目的をもつ。したがって、各々は異なるフォーマットの異なるアノテーション・データを含む。しかし、それらはすべて、同じ設計ルールに従うべきである。
【００５９】
以下の例では、サンプル活動設計ファイルが示されている。その情報は、以下のもの、すなわち、設計要件、設計コンフィギュレーション／仕様、設計ファイル、およびツールなどを含むことができる。
【００６０】
<cbpm:DesignFilerdf:about="http://www.nec.com/AmpSubMinDconn9PosRearPanelMtg.CATPart">
<cbpm:fileName>Amp Sub Min D conn 9 Pos Front Panel Mtg.CATPart </cbpm:fileName>
<cbpm:fileSize>239K bytes </cbpm:fileSize>
<cbpm:lastModifiedTime>9/25/2002, 6:00PM </cbpm:lastModifiedTime>
<cbpm:lastVersionNumner>V5.1 </cbpm:lastVersionNumner>
<cbpm:location>ftp://ftp.nec.com/dc/designfile/AmpSubMinDconn9PosRearPanelMtg.CATPart</cbpm:location>
<cbpm:designTool>CATIA V5 </cbpm:designTool>
<cbpm:format>CATPart </cbpm:format>
<cbpm:designPartnerID>ABC </cbpm:designPartnerID>
<cbpm:designProjectID>ThinkPadT61 </cbpm:designProjectID>
<cbpm:accessControl>
... ...
</cbpm:accessControl>
</cbpm:Specification>
【００６１】
以下の例は、制約を表現するために、ＯＡＳＩＳ拡張可能アクセス制御マークアップ言語（ＸＡＣＭＬ）［セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）、http://xml.coverpages.org/saml.html］を使用して、アクセス制御ばかりでなく、複数の制約が指定される、設計活動アノテーションを示している。
【００６２】
<cbpm:design-activity-annotation>
<cbpm:desc>
<cbpm:checkpointConstraints>.. . </cbpm:checkpoint constraints>
<cbpm:outsourcingConstraints>...(XACML) </cbpm:outsourcingConstraints>
<cbpm:acl> ... (XACML) </cbpm:acl>
<cbpm:documentFormatConstraints>http://temporg.com/tempuri/documentFormatContraints.htm</cbpm:documentFormatConstraints>
</cbpm:desc>
</cbpm:design-activity-annotation>
【００６３】
Ｄ．ツール・アノテーション
ツール・アノテーションは、設計ツール用のものであり、プラットホームに依存する。ＢＯＭファイルに関係するそのようなツール・アノテーションの例は、処理プラットホーム、設計ステータス（進行中または再設計）、検査ステータス、修正履歴、ダウンロード用パスワードなどとすることができる。以下は、例示的なツール・アノテーション・データ・インスタンスである。
【００６４】
<cbpm:design-process-low-level-annotation>
<cbpm:bomDesc>
<cbpm:fileProperty>
<cbpm:filename>CDRom</cbpm:filename>
<cbpm:fileSize>1020K</cbpm:fileSize>
<cbpm:creationTool>MSEXCEL</cbpm:creationTool>
<cbpm:documentId>ThinkPad-Bom-010</cbpm:documentId>
</cbpm:fileProperty>
</cbpm:processingPlatform>
<cbpm:DevelopmentPlatformID>UNIX（登録商標）</cbpm:DevelopmentPlatformID/>
<cbpm:ParentDesignToolID>CATIAPP</cbpm:ParentDesignToolID/>
<cbpm:AccessibleParty>http://temporg.com/tempuri/acl/ThinkPad-Bom-010AccessList</cbpm:AccessibleParty>
</cbpm:processingPlatform>
</cbpm:bomDesc>
</cbpm:tool-annotation>
【００６５】
ＩＩＩ．アノテーション記憶
設計コラボレーション・オントロジは、ＲＤＦスキーマ・フォーマットで定義され、ＲＤＦフォーマットで保存される。アノテーションは、オントロジの一部分である。
【００６６】
設計コラボレーションではアノテーションに対する多様な要件が存在し、新しい要件が果てしなく現れる。電子ビジネス・コラボレーション用の事前定義されたアノテーションに加えて、ユーザはカスタムメードのアノテーションを定義することができる。以下は、アノテーション定義の保存サンプルである。
【００６７】
<rdf:RDF
xmlns:daml='http://www.daml.org/2001/03/daml+oil#'
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'>
<daml:DatatypePropertyrdf:about='http://www.ibm.com/ibm/pdt#fileName'
rdfs:label='fileName'>
<rdfs:comment>The name of a file, huh?</rdfs:comment>
<rdfs:domainrdf:resource='http://www.w3.org/2000/01/rdf-schema#Resource'/>
<rdfs:range rdf:resource='http://www.w3.org/2000/10/XMLSchema#string'/>
<rdfs:isDefinedBy rdf:resource='urn:Organization:PDT@PDT'/>
</daml:DatatypeProperty>
<daml:DatatypePropertyrdf:about='http://www.ibm.com/ibm/pdt#fileSize'
rdfs:label='fileSize'>
<rdfs:comment>The size of a file</rdfs:comment>
<rdfs:domainrdf:resource='http://www.ibm.com/cbpm#Document'/>
<rdfs:range rdf:resource='http://www.w3.org/2000/10/XMLSchema#string'/>
<rdfs:isDefinedBy rdf:resource='urn:Organization:PDT@PDT'/>
</daml:DatatypeProperty>
<daml:DatatypePropertyrdf:about='http://www.ibm.com/ibm/pdt#format'
rdfs:label='format'>
<rdfs:comment>The format of a file, huh?</rdfs:comment>
<rdfs:domainrdf:resource='http://www.ibm.com/cbpm#Document'/>
<rdfs:range rdf:resource='http://www.w3.org/2000/10/XMLSchema#string'/>
<rdfs:isDefinedBy rdf:resource='urn:Organization:PDT@PDT'/>
</daml:DatatypeProperty>
</rdf:RDF>
【００６８】
これらのアノテーション定義は、設計コラボレーション・プロセスにおける情報交換中に、様々な要素に適用される。以下は、設計プロジェクト用のＲＦＤプリミティブの間の、アノテーションを施された情報の（ＲＤＦ表現での）保存である。
【００６９】
<rdf:RDF
xmlns:RDFNsId1='http://www.ibm.com/ibm/pdt#'
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:RDFNsId2='http://www.ibm.com/cbpm#'>
<RDFNsId2:RFD
rdf:about='urn:RFD:task1_RFD1@task1_RFD1@CPUDesign@SuperComputer@PDT@PDT'
RDFNsId2:identifier='task1_RFD1'
RDFNsId2:description=''
RDFNsId2:status='Received'>
<RDFNsId2:creationTime>Dec 10, 2002 8:12:21 PM</RDFNsId2:creationTime>
<RDFNsId2:transaction>
<RDFNsId2:RFDTransaction
rdf:about='urn:Transaction:task1_RFD1@CPUDesign@SuperComputer@PDT@PDT'
RDFNsId2:status='Created'
RDFNsId2:identifier='task1_RFD1'>
<RDFNsId2:requester>
<RDFNsId2:Organization rdf:about='urn:Organization:PDT@PDT'
RDFNsId2:identifier='PDT'
RDFNsId2:schemaExtensionURL='http://www.ibm.com/ibm/pdt'>
</RDFNsId2:Organization>
</RDFNsId2:requester>
<RDFNsId2:creationTime>Dec 10, 2002 8:12:21 PM</RDFNsId2:creationTime>
<RDFNsId2:forTask>
<RDFNsId2:OursourcingTask
rdf:about='urn:Task:CPUDesign@SuperComputer@PDT@PDT'
RDFNsId2:identifier='CPUDesign'
RDFNsId2:status='RFDReceived'>
<RDFNsId2:performer>
<RDFNsId2:Organization rdf:about='urn:Organization:ABC@ABC'
RDFNsId2:schemaExtensionURL='http://www.ibm.com/ibm/nec'
RDFNsId2:identifier='MYASIC'>
</RDFNsId2:Organization>
</RDFNsId2:performer>
<RDFNsId2:description>I am designing the fastest CPU in theworld</RDFNsId2:description>
<RDFNsId2:name>Designing a CPU</RDFNsId2:name>
<RDFNsId2:forProject>
[0259]<RDFNsId2:Project rdf:about='urn:Project:SuperComputer@PDT@PDT'
RDFNsId2:status='Created'
RDFNsId2:identifier='SuperComputer'>
</RDFNsId2:Project>
</RDFNsId2:forProject>
<RDFNsId2:creationTime>Dec 10, 2002 8:12:21PM</RDFNsId2:creationTime>
</RDFNsId2:OursourcingTask>
</RDFNsId2:forTask>
<RDFNsId2:responder rdf:resource='urn:Organization: MYASIC @ MYASIC />
</RDFNsId2:RFDTransaction>
</RDFNsId2:transaction>
<RDFNsId2:requirement>
<RDFNsId2:DesignRequirement
rdf:about='urn:DesignRequirement:req1@CPUDesign@SuperComputer@PDT@PDT'
RDFNsId2:description='desc'
RDFNsId1:TFTSize='14.1'
RDFNsId2:identifier='req1'
RDFNsId1:cpuFrequency='2.5G'>
<RDFNsId2:name>requirement 1</RDFNsId2:name>
<RDFNsId2:reference>
<rdf:Bag>
<rdf:li>
<RDFNsId2:DesignFile
rdf:about='urn:Document:Ref1@req1@CPUDesign@SuperComputer@PDT@PDT'
RDFNsId1:fileAuthor='robert'
RDFNsId1:fileName='cpurequirementRef1.doc'
RDFNsId2:identifier='Ref1'>
<RDFNsId2:name>ref 1</RDFNsId2:name>
<RDFNsId2:description>This is ref 1</RDFNsId2:description>
</RDFNsId2:DesignFile>
</rdf:li>
</rdf:Bag>
</RDFNsId2:reference>
<RDFNsId2:specification>
<rdf:Bag>
<rdf:li>
<RDFNsId2:Specification
rdf:about='urn:Document:Spec1@req1@CPUDesign@SuperComputer@PDT@PDT'
RDFNsId1:fileAuthor='robert'
RDFNsId2:identifier='Spec1'
RDFNsId1:fileName='cpurequirement.doc'>
<RDFNsId2:description>This is doc 1</RDFNsId2:description>
<RDFNsId2:name>doc 1</RDFNsId2:name>
</RDFNsId2:Specification>
</rdf:li>
</rdf:Bag>
</RDFNsId2:specification>
<RDFNsId2:forTask
rdf:resource='urn:Task:CPUDesign@SuperComputer@PDT@PDT'/>
</RDFNsId2:DesignRequirement>
</RDFNsId2:requirement>
</RDFNsId2:RFD>
<RDFNsId2:ReceiptAck
rdf:about='urn:ReceiptAck:task1_RFD1ReceiptAck@task1_RFD1@CPUDesign@SuperComputer@PDT@PDT'
RDFNsId2:identifier='task1_RFD1ReceiptAck'
RDFNsId2:status='Created'>
<RDFNsId2:transaction
rdf:resource='urn:Transaction:task1_RFD1@CPUDesign@SuperComputer@PDT@PDT'/>
<RDFNsId2:creationTime>Dec 10, 2002 8:04:02PM</RDFNsId2:creationTime>
</RDFNsId2:ReceiptAck>
<RDFNsId2:Individual rdf:about='urn:Individual:Mike@PDT@PDT'
RDFNsId2:identifier= Mike >
<RDFNsId2:memberOf rdf:resource='urn:Organization:PDT@PDT'/>
<RDFNsId2:description>This is an user.</RDFNsId2:description>
<RDFNsId2:name> Mike Josh</RDFNsId2:name>
</RDFNsId2:Individual>
</rdf:RDF>
【００７０】
アノテーションは、各企業サイトに配備することができるコラボレーション・ディレクトリ（図２の２３０）に保存することができる。埋め込みステータス情報をもつデータ（例えば、プロジェクト、タスク、交換される文書など）は、複数のコラボレーション・ディレクトリに保存されるので、これらの分散されたコラボレーション・ディレクトリからの情報は、アノテーション・データに収められたアクセス制御方針に基づいて集約することができる。
【００７１】
コラボレーション・ディレクトリの別の実施形態は、ハブとして機能するコラボレーション・ディレクトリを含む。そのようなハブは、ビジネス・コラボレーションを実行するための中心場所としてハブを使用する複数の組織のコラボレーション用リソースを管理する。
【００７２】
ＩＶ．アノテーション生成
アノテーション生成は、オンデマンド情報交換モデルの主要な機能である。それは、図２のアノテーション・ツール２４０によって実行されることができる。上で述べたように、ビジネス・コラボレーションで使用される様々なリソースのアノテーション・データはすべて、例えば、プレーン・テキスト・ファイルまたはリレーショナル・データベースなどのアノテーション記憶に保存される。アノテーション生成プロセスは、アノテーションを生成するため、記憶上で処理を行うことができる。説明的な一実施形態では、アノテーションの生成は以下のステップを含む。
（１）拡張されたビジネス・コラボレーション・ポータルの使用によって情報を収集する。情報は、パートナ、プロジェクト、タスク、仕様アノテーション、参照設計ファイル・アノテーション、その他の関連アノテーションなど様々なリソースの記述を含む。
（２）収集されたすべての情報をアノテーション記憶に保存する。
（３）交換されるアノテーション・メッセージを編成するため、必要なデータを記憶から抽出する。
【００７３】
ＲＦＤメッセージ作成を例にとって、プロセスを説明する。
【００７４】
最初に、例えば、図１０に示されているように、ユーザは、新しいタスクをアウトソーシング・タスクまたは内部タスクとして生成する。
【００７５】
次に、ユーザは、設計タスクのための設計要件を明確化することができる。要件は、仕様、参照設計ファイル、設計プロセス制約などを含むことができる。図１１は、設計要件アノテーション／メタ・データを含む設計要求（ＲＦＤ）メッセージの作成を示している。図１２は、仕様文書の作成を示している。
【００７６】
情報が収集され、アノテーション記憶に保存された後、アノテーション生成プロセスが開始する。アノテーション生成モジュール（図２の２４０）は、必要とされるデータをストレージ（図２の２３０）から抽出し、ＲＦＤメッセージ・データ・モデルに基づいてＲＦＤアノテーション・メッセージを作成する。生成されたＲＦＤメッセージは、設計パートナに送られる。
【００７７】
ＲＦＤメッセージを受け取った後、パートナは、アノテーションを調べ、それを自らのアノテーション記憶にマージすることができる。パートナは、アノテーションが施されたリソースの１つについてより多くを知りたい場合、アノテーション・リンク（例えば、設計ファイル・アノテーション・リンク）を取得し、より多くの情報を要求することができる。送り手は、設計ファイル用のアノテーションを生成し、それをパートナに送り返す。パートナは、アノテーションに基づいて実際の設計ファイルを検索するかどうかを決定することができる。このように、オンデマンド情報交換は実行される。
【００７８】
Ｖ．コラボレーション・パターン
ＣｘＰは、業界特有のオントロジを定義することによって設計コラボレーション・プロセスにアノテーションを施すため、リソース定義フレームワーク（ＲＤＦ）を使用し、コラボレーション・プロセス間でのピアツーピア対話を可能にする。ＣｘＰは、図２の２１０として参照される典型的なコラボレーション・パターンである。ＣｘＰは、２つのパーティ間または複数のパーティ間で交換されるメッセージと、いくつかの事前定義されたメッセージ交換シーケンスと、いくつかの事前定義されたメッセージ交換シーケンスによって構成されるビジネス目標指向プロトコルとを含む。ＲＤＦは、ウェブ・リソースのメタ・データ（または属性）を表現するための汎用言語および共通フレームワークであり、ＸＭＬ構文で定義される。ＣｘＰは、１組の標準プロトコルの上位に構築され、拡張されたビジネス・コラボレーション・プロセスのために必要とされる特徴を追加する。
【００７９】
全体的なプロトコル構成は、図６のコンテキストで説明することができる。より詳細には、図６は、本発明の実施形態による、コラボレーション・プリミティブおよびビジネス・コンストラクトの一例を示す図である。図示されるように、プロトコル構成６００において、以下の要素、すなわち、ビジネス・シナリオ６０２、ビジネス・コンストラクト６０４、コラボレーション・プリミティブ６０６、メッセージング・レイヤ６０８、およびトランスポート・レイヤ６１０が定義される。各レイヤに対応する説明は、複数のビジネス・コンストラクト６１２、複数のプリミティブ６１４（例えば、設計要求（ＲＦＤ）プリミティブおよび設計提出（ＤＳ）プリミティブ）、複数のＣｘＰメッセージ６１６（例えば、ＲＦＤプリミティブ、ＤＳプリミティブ）、ＲＤＦアノテーションを有するＣｘＰメッセージ６１８、および標準的なトランスポート・プロトコル６２０である。メッセージング・レイヤ６０８では、ＲＤＦは、ハイパーチェーン・アノテーションと呼ばれるビジネス・コラボレーション・アノテーションを表現するのに使用される。その上、１組のプリミティブは、パーティ間での通信およびコラボレーションを助けるコラボレーション・プリミティブ６０６として定義される。
【００８０】
ビジネス・コンストラクト６０４は、単一のビジネス目標に役立つメッセージ交換シーケンスの基本単位である。例えば、設計要求が初期化されるとき、ＲＦＤビジネス・コンストラクトが使用される（例えば、設計センタ）。図７に示される製品設計チーム（ＰＤＴ）は、マザーボードの設計を行うため、または機械的および電気的設計を行うため、その設計パートナにＲＦＤを送ることができる。それに続いて、受諾または拒否プリミティブを、設計パートナから受け取ることができる。その後、設計パートナは、ＤＳプリミティブによって、設計結果を提出することができる。
【００８１】
ビジネス・シナリオ６０２は、早期デザインイン・シナリオなどのより複雑なビジネス目標に役立つ。各ビジネス・シナリオは、対応するビジネス・コンテキストに応じて複数のビジネス・コンストラクトを含むことができる。
【００８２】
コラボレーション・プリミティブ、ビジネス・コンストラクト、およびビジネス・シナリオの詳細について以下で説明する。
【００８３】
これらのプロトコルに基づいて、業務提携者は、設計コラボレーション（ＤＣ）プロセスを自分たちが望むように定義することができる。以下は、ＴｈｉｎｋＰａｄ設計作業プロセスであり、それには複数の業務提携者が関係しており、複数のプロトコルから構成される。図７は、ＰＤＴとＡＢＣの間の、全部のプロセスの一部分だけを示している。図７の例を以下で説明する。
【００８４】
ＣｘＰで、原子メッセージが、取引パートナ間での情報の基本交換として定義される（例えば、ＲＦＤメッセージ）。１組の構成されたメッセージがプリミティブを形成する。例えば、ＲＦＤプリミティブは、例えば、ＲＦＤＭｅｓｓａｇｅおよびＡｃｋＭｅｓｓａｇｅの２つのメッセージさらに、１つまたは複数のプリミティブが、ビジネス・コンストラクトを形成する。例えば、ＲＦＤビジネス・コンストラクトは、例えば、ＲＦＤプリミティブおよび受諾／拒否プリミティブの２つのプリミティブを含むことができる。シナリオは、設計初期化、技術変更管理、および機会開始など、ビジネス・パートナ間での複雑な対話を表現するビジネス・コンストラクトのシーケンスである。その上、ＣｘＰプリミティブおよびビジネス・コンストラクトは、特定のコラボレーション目標をターゲットとしており、たとえ構成可能であるとしても、比較的固定的である。一方、ビジネス・シナリオは、様々な方法で構成することができ、したがって、非常に柔軟性がある。
【００８５】
設計コラボレーション・プリミティブは、特定のマイクロ設計コラボレーション目標のための１群のメッセージ交換である。複数のコア設計コラボレーション・プリミティブが、ＣｘＰのために定義される。
−ＲＦＤ（設計要求）
−受諾／拒否（要求を受諾する、または拒否する）
−ＤＳ（設計提出）
−ＲＦＩ（情報要求）
−ＩＳ（情報提出）
−ＲＦＵ（更新要求）
−ＵＳ（更新提出）
【００８６】
例としてＲＦＤを取り上げると、各業務提携者は、パートナに設計タスクを実行するよう要求するため、ＲＦＤプリミティブを使用する。ＲＦＤプリミティブは、ＲＦＤ、ＲＦＤ＿Ｒｅｃｅｉｐｔ＿Ａｃｋ、およびＲＦＤ＿Ａｃｃｅｐｔａｎｃｅ＿Ａｃｋメッセージの３つのメッセージを含む。これは図８に示されている。
【００８７】
ＲＦＤメッセージ：送り手（例えば、設計センタ）によって、受け手（例えば、設計パートナ）に送られる。仕様、参照、およびアノテーションを含む要件を含む。
【００８８】
ＲＦＤ＿Ｒｅｃｅｉｐｔ＿Ａｃｋメッセージ：ＲＦＤメッセージが受け手によって受け取られたことを示すＲＦＤメッセージに対する応答が、受け手によって送られる。
【００８９】
以下は一例である。
【００９０】
<RDFNsId2:RFD
rdf:about='urn:RFD:SoundCard_test1@SoundCard_test1@SoundCard@Workstation@PDT@PDT'
RDFNsId2:description="
RDFNsId2:identifier='SoundCard_test1'
RDFNsId2:status='Accepted'>
<RDFNsId2:requirement>
<RDFNsId2:DesignRequirementrdf:about='urn:DesignRequirement:test1@SoundCard@Workstation@PDT@PDT'
RDFNsId1:cpuFrequency='500'
RDFNsId2:identifier='test1'
RDFNsId2:name='test1'
RDFNsId2:description='test1'>
<RDFNsId2:specification>
<rdf:Bag>
<rdf:li>
<RDFNsId2:Specificationrdf:about='urn:Document:test@test1@SoundCard@Workstation@PDT@PDT'
RDFNsId2:identifier='test'
RDFNsId2:name='test'
RDFNsId2:description='d:\there'/>
</rdf:li>
<rdf:li>
<RDFNsId2:Specification rdf:about='urn:Document:@test1@SoundCard@Workstation@PDT@PDT'
RDFNsId2:description="
RDFNsId2:name="
RDFNsId2:identifier="/>
</rdf:li>
</rdf:Bag>
</RDFNsId2:specification>
<RDFNsId2:reference
rdf:type='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/>
<RDFNsId2:forTask rdf:resource='urn:Task:SoundCard@Workstation@PDT@PDT'/>
</RDFNsId2:DesignRequirement>
</RDFNsId2:requirement>
<RDFNsId2:transactionrdf:resource='urn:Transaction:SoundCard_test1@SoundCard@Workstation@PDT@PDT'/>
<RDFNsId2:creationTime>Jan 16, 20035:10:17 PM</RDFNsId2:creationTime>
</RDFNsId2:RFD>
【００９１】
各設計パートナは、ＲＦＤまたはＲＦＵを受け取った後、要求を受諾または拒否することができる。ＲＦＤに対する受諾プリミティブの一例は以下のようになる。
【００９２】
<RDFNsId2:AcceptanceAckrdf:about='urn:AcceptanceAck:SoundCard_test1AcceptanceAck@SoundCard_test1@SoundCard@Workstation@PDT@PDT'
RDFNsId2:identifier='SoundCard_test1AcceptanceAck'
RDFNsId2:ack='Accept'
RDFNsId2:status='Sent'>
<RDFNsId2:transactionrdf:resource='urn:Transaction:SoundCard_test1@SoundCard@Workstation@PDT@PDT'/>
<RDFNsId2:creationTime>Jan 16, 20035:38:38 PM</RDFNsId2:creationTime>
</RDFNsId2:AcceptanceAck>
【００９３】
Ａ．ビジネス・コンストラクト
ビジネス・コンストラクトは、ビジネス・コンストラクトのために選択的に構成することができる１群のコラボレーション・プリミティブを含む。一度構成されると、ビジネス・コンストラクトは、単一の設計コラボレーション目標を達成するために比較的固定的な方式で組織される。以下のビジネス・コンストラクトは、先に説明されたプリミティブに基づく。
−ＲＦＤビジネス・コンストラクト（ＲＦＤプリミティブ＋受諾／拒否プリミティブ＋ＤＳプリミティブ）
−ＲＦＵビジネス・コンストラクト（ＲＦＵプリミティブ＋ＵＳプリミティブ）
−ＲＦＩビジネス・コンストラクト（ＲＦＩプリミティブ＋ＩＳプリミティブ）
−ＵＳビジネス・コンストラクト（ＵＳプリミティブ）
−ＩＳビジネス・コンストラクト（ＩＳプリミティブ）
【００９４】
これらのビジネス・コンストラクトに基づいて、業務提携者は、どのような複雑なビジネス・シナリオでも望むように定義することができる。
【００９５】
ビジネス・コンストラクトは、コラボレーション・プリミティブに基づく複数の対話メッセージをしばしば伴うので、非常に複雑になることが多い。
【００９６】
ビジネス・プロセス実行言語（ＢＰＥＬ４ＷＳ）（http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/）などのビジネス・プロセス・モデリング言語用の標準プロトコルは、ＣｘＰビジネス・コンストラクトおよびビジネス・シナリオを表現するのに使用することができる。一度ＢＰＥＬ４ＷＳによって表現されると、複数のビジネス・コンストラクトは、動的に構成することができるビジネス・シナリオを形成することができる。
【００９７】
Ｂ．例：ＲＦＤビジネス・コンストラクト
ＲＦＤビジネス・コンストラクトは、１つのＲＦＤプリミティブ、１つの受諾／拒否プリミティブ、および１つのＤＳプリミティブを含むことができる。ＲＦＤマイクロフローは、以下のようにＢＰＥＬ４ＷＳを使用して表現することができる。
【００９８】
<process name="RFDmicroflow"
targetNamespace="urn:samples:BusinessConstructs"
xmlns:tns="urn:samples:BusinessConstructs"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">
<partners>
<partner name="RFDoriginator"
serviceLinkType="tns:RFDoriginatingSLT"
myRole="RFDoriginating"/>
<partner name="RFDreceiver"
serviceLinkType="tns:RFDreceivingSLT"
myRole="RFDreceiving"/>
<partnername="buyer" 
serviceLinkType="tns:buyingSLT"
MyRole="buying"/>
</partners>
<variables>
<variable name="RFDinvoke" messageType="tns:RFDinvoke"/>
<variable name="RFDmsg" messageType="tns:RFDmsg"/>
<variable name="RFD_Receipt_Ack" messageType="tns:RFD_Receipt_Ack"/>
<variable name="Accept" messageType="tns:Accept"/>
<variable name="DSinvoke" messageType="tns:DSinvoke"/>
<variable name="DSmsg" messageType="tns:DSmsg"/>
<variable name="DS_Receipt_Ack" messageType="tns:DS_Receipt_Ack"/>
</variables>
<correlationSets>
<correlationSet name="POIdentifier"properties="POIdentifier"/>
<correlationSet name="RFDIdentifier" properties="RFDIdentifier"/>
</correlationSets>
<sequence>
<receive partner="buyer" portType="tns:buyerPT"
operation="purchase" variable="RFDinvoke"
createInstance="yes" name="ReceivePurchase">
<correlations>
<correlation set="POIdentifier"initiate="yes"/>
</correlations>
</receive>
<invoke name="invokeRFDoriginator"
partner="RFDoriginator" portType="tns:RFDoriginatorPT"
operation="sendRFD" inputVariable="RFDinvoke"outputVariable="RFDmsg">
</invoke>
<invoke name="invokeRFDreceiver"
partner="RFDreceiver" portType="tns:RFDreceiverPT"
operation="receiveRFD" inputVariable="RFDmsg" outputVariable="RFD_Receipt_Ack">
</invoke>
<invoke name="invokeRFD_Accept_Ack"
partner="RFDreceiver" portType="tns:RFDreceiver"
operation="sendRFD_Accept" inputVariable="RFDmsg" outputVariable="RFD_Accept_Ack">
</invoke>
<invoke name="invokeRFD_Accept_receive"
partner="RFDoriginator" portType="tns:RFDoriginator"
operation="receive_Accept" inputVariable="Accept">
</invoke>
<invoke name="invokeDS"
partner="RFDreceiver" portType="tns:RFDreceiver"
operation="submitDS" inputVariable="DSinvoke"outputVariable="DSmsg">
</invoke>
<invoke name="invokeDS_Receipt_Ack"
partner="RFDoriginator" portType="tns:RFDoriginator"
operation="receiveDS" inputVariable="DSmsg" outputVariable="DS_Receipt_Ack">
</invoke>
</sequence>
</process>
【００９９】
ビジネス・コラボレーションまたは設計コラボレーション・パターンは、プリミティブ・プロトコルに基づく複数の対話メッセージをしばしば伴うので、非常に複雑になることがある。設計アウトソーシングを例にとる。図７において、右手サイドは、ＴｈｉｎｋＰａｄ設計の一部を異なる設計パートナに、例えば、ＡＳＩＣチップ設計はＡＢＣに、マザーボード設計はＸＹＺに、機械的および電気的設計はＹＡＰにアウトソーシングする設計センタ、製品設計チームを示している。図７の左手サイドは、製品設計チームとＡＢＣの間の設計コラボレーション・パターンを示している。２つのパートナ間の様々なメッセージ・フローは、設計要求（ＲＦＤ）７０２から始まり、更新要求（ＲＦＵ）７０４、７０６が続き、さらにＲＦＤの受諾７０８、設計提示７１０、設計検査７１２、さらなるＲＦＵおよび中間再検査７１４、７１６、７１８、最後に設計受諾７２０で終了する。
【０１００】
図７に示されたサンプルの設計コラボレーション・パターンは、コラボレーション・メッセージ・フローおよび文書交換において必要とされる様々なデータ・フォーマットをサポートするためのＲＤＦの柔軟性および融通性を示している。
【０１０１】
ＶＩ．ハイパーチェーン・マネージャ
今度は図９を参照すると、この図は、本発明の実施形態による、ハイパーチェーン・マネージャを示している。図９に示されるように、ハイパーチェーン・マネージャ（図２の２５０）は、ＣｘＰエンジンとして機能する。図９の構成９００は、拡張されたビジネス・コラボレーション・ポータル／ダッシュボード９１０と、拡張されたビジネス・コラボレーション（ｅＢＣ）マネージャ９２０と、ハイパーチェーン・マネージャ９３０と、ＷＢＩ／Ｃ  Ｅｘｐｒｅｓｓレイヤ９５０とを含み、ＷＢＩ／Ｃ  Ｅｘｐｒｅｓｓレイヤ９５０は、ハイパーチェーン・マネージャと、ホスティング・ビジネス・アプリケーション用の典型的なＪａｖａ（登録商標）ベースのウェブ・アプリケーション・サーバであるＷｅｂｓｐｈｅｒｅレイヤ９６０などのより低レベルのウェブ・アプリケーション・サーバとの間のゲートウェイとして機能する。したがって、ＣｘＰエンジン（ハイパーチェーン・マネージャ）は、一例として、ＷｅｂＳｐｈｅｒｅと共にＪ２ＥＥプラットホーム上に存在する。
ポータルまたはダッシュボード９１０は、ｅＢＣマネージャ９２０によって提供されるアプリケーション・プログラミング・インタフェース（ＡＰＩ）レイヤを介して、ＣｘＰエンジンにアクセスすることができるアプリケーションを含む。
【０１０２】
ハイパーチェーン・マネージャ９３０は、（マネージャおよびディレクトリを有する）コラボレーション用ディレクトリ９３２と、アノテーション・マネージャ９３４と、メッセージ・センダ９３６と、メッセージ・レシーバ９３８と、アクション・マネージャ９４０とを含む。
【０１０３】
コラボレーション・ディレクトリ・マネージャ・コンポーネントは、ＣｘＰエンジンによって追跡される、組織（パートナ）、ユーザ、プロジェクト、タスクなどのリソースを管理し、リソースはＲＤＦベースである。ＣｘＰメッセージは、メッセージ・センダおよびレシーバ・モジュールによって送信および受信され、それらは、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）メッセージ、またはメッセージ・キューイング（ＭＱ）メッセージなどのその他のプロトコル・メッセージである。
【０１０４】
アノテーション・マネージャは、ＣｘＰメッセージによって交換される文書用に生成されたメタ・データまたはアノテーションを処理する。アノテーションの例は、ファイル名、ファイル・タイプ、バージョン、作成者名などである。その上、アノテーションは、文書に関して実行される「アクション」を指定するのに使用することもできる。そのようなアクションの例は、文書「検査」、「ＲＦＴＰ」（高信頼ファイル転送）実行、統合業務ソフト（ＥＲＰ）およびＰＤＭなどのレガシ・アプリケーションへのアクション送信とすることができる。
【０１０５】
受信メッセージ内のアノテーションは、アクション・マネージャに転送され、アクション・マネージャは、ＲＦＴＰなどのコンポーネントばかりでなく、バックエンド・レガシ・アプリケーションへの統合レイヤである。アクション・マネージャは、文書に関する適切なアクションを起動する。
【０１０６】
今度は図１０を参照すると、この図は、本発明の実施形態による、ハイパーチェーン・マネージャのアクション・マネージャを示している。図１０に示すように、アクション・マネージャ９４０は、着信要求を処理し、アクション処理用のサービスを分散サービス・グリッド９９０から自動的に割り当てる役割をもつ。アクション・マネージャはまた、複数の情報源からデータを知的に集約する。
【０１０７】
アクション・マネージャの主要コンポーネントについて以下で説明する。
【０１０８】
コミュニケータ９７２は、要求を受け取り、応答を提示するため、他の業務提携者と通信する。コミュニケータは、監視および他の業務提携者と対話するためのウェブ・サービス定義言語（ＷＳＤＬ）インタフェースとすることができる。
【０１０９】
アノテーション・データ・パーサ９７４は、設計ハイパーチェーン・アノテーション・データを構文解析する。
【０１１０】
イベント捕捉モジュール９７６は、ＣａｄｅｎｃｅおよびＣａｔｉａなどのコンピュータ支援設計（ＣＡＤ）ツールからイベントを捕捉し、次にイベントをマスタ・コントローラに受け渡す。
【０１１１】
マスタ・コントローラ９７８は、（ｉ）イベント捕捉モジュールによって捕捉されたイベントを処理し（例えば、ステータス情報を抽出／更新するためにＩＤ＆ＤＥのプロジェクト・マネージャと通信し）、（ｉｉ）センダ／レシーバ検証（例えば、アクセス制御リスト）を実行し、（ｉｉｉ）設計ハイパーチェーン・アノテーション・データに基づいて、設計データ、ＢＯＭデータ、およびその他のメタ・データを取り込み、（ｉｖ）アノテーション・データで定義されたアクションをアクション・ハンドラに受け渡す。
【０１１２】
アクション・ハンドラ９８０は、（ｉ）設計データ・アノテーション、設計データ追跡、設計プロセス追跡、および異種のデータ源にわたる設計データ集約を処理し、（ｉｉ）コラボレーション・プロセスを設計データおよびメタ・データと同期させ、（ｉｉｉ）結果、提案された変更を分析し、（ｉｖ）アノテーション・データ配布器（アクセス制御ベースの、個別送達、バッチ送達（例えば、放送））として機能し、（ｖ）コラボレーション・ステータス追跡（例えば、誰が設計文書を検査したか、ステータスは何か、いつ検査されたか、どこでか、どのブラウザでか）を実行する。
【０１１３】
スマート・アダプタ９８２は、アクション処理用のサービスを分散サービス・グリッド９９０から割り当てる。サービス・グリッド９９０は、必要とされるアクション・タイプおよびアクション・ハンドラからの本当の要件に基づいて、設計ハイパーチェーン・エンジンにおいてオンデマンドのサービス配備および送達モデルを提供する。すなわち、設計チェーン内の設計パーティは、必要とするときはいつでも、サービス・グリッド９９０に配備された特定のサービスを要求することができる。サービス・グリッド９９０のサービスの例は、設計プロセス追跡サービス、設計ファイル追跡サービス、複数の情報源からのデータ集約サービス、設計ファイル／メタ・データ送達サービス、データ・アノテーティング・サービス、アノテーション・データ配布サービス、データとプロジェクトの同期サービス、結果分析サービスを含むが、これらに限定されるものではない。サービス・グリッド９９０は、スマート・アダプタ９８２を介してアクション・マネージャ９４０に接続され、アクション・マネージャは、アクション・ハンドラ９８０からのアクション・コマンドを構文解析し、サービス・グリッドに配備された対応するサービスを起動し、サービス・グリッド９９０からの実行結果をアクション・ハンドラ９８０に受け渡す。
【０１１４】
最後に図１４を参照すると、このブロック図は、本発明の実施形態による、本発明の１つまたは複数のコンポーネント／方法（例えば、図１から図１３のコンテキストで説明されたコンポーネント／方法）をそれによって実施することができるコンピューティング・システムの説明的なハードウェア実装を示している。例えば、図１４のそのようなコンピューティング・システムは、ハイパーチェーン・マネージャ、コラボレーション用ディレクトリ、アノテーション・ツールなどを実施することができる。
【０１１５】
そのような個々のコンポーネント／方法が、１つのそのようなコンピュータ・システムで、または２以上のそのようなコンピュータ・システムで実施することができることを理解されたい。分散コンピューティング・システムでの実施の場合、個々のコンピュータ・システムまたはデバイスあるいはその両方は、例えば、インターネットまたはワールドワイドウェブなどの適切なネットワークを介して接続することができる。しかし、システムは、私設またはローカル・ネットワークによって実現することもできる。本発明は、特定のネットワークに限定されるものではない。
【０１１６】
図示されるように、コンピュータ・システム１３００は、コンピュータ・バス１３１０または代替接続構成を介して結合される、プロセッサ１３０２、メモリ１３０４、Ｉ／Ｏ装置１３０６、およびネットワーク・インタフェース１３０８によって実装することができる。
【０１１７】
本明細書で用いられる「プロセッサ」という用語は、例えば、ＣＰＵ（中央処理装置）またはその他の処理回路あるいはその両方を含む処理装置など、任意の処理装置を含むことが意図されている。「プロセッサ」という用語は、２以上の処理装置を指示することができること、また処理装置に関連づけられた様々な要素は、他の処理装置によって共用されることができることも理解されたい。
【０１１８】
本明細書で用いられる「メモリ」という用語は、例えば、ＲＡＭ、ＲＯＭ、固定メモリ装置（例えば、ハードディスク）、着脱可能メモリ装置（例えば、ディスケット）、フラッシュメモリなど、プロセッサまたはＣＰＵに関連づけられるメモリを含むことが意図されている。
【０１１９】
本明細書で用いられる「入出力装置」または「Ｉ／Ｏ装置」という用語は、例えば、処理装置にデータを入力するための１つまたは複数の入力装置（例えば、キーボード、マウスなど）、または処理装置に関連づけられた結果を提示するための１つまたは複数の出力装置（例えばスピーカ、ディスプレイなど）、あるいはその両方を含むことが意図されている。そのような出力装置は、図１１〜図１３に示されるグラフィカル・ユーザ・インタフェースのようなグラフィカル・ユーザ・インタフェースを提示するのにも使用することができる。
【０１２０】
さらに、本明細書で用いられる「ネットワーク・インタフェース」という用語は、例えば、コンピュータ・システムが別のコンピュータ・システムと適切な通信プロトコルによって通信することを可能にする１つまたは複数のトランシーバを含むことが意図されている。
【０１２１】
したがって、本明細書で説明された方法を実行するための命令またはコードを含むソフトウェア・コンポーネントは、１つまたは複数の関連メモリ装置（例えば、ＲＯＭ、固定または着脱可能メモリ）に保存することができ、利用される準備ができているときは、一部または全部を（例えば、ＲＡＭに）ロードし、ＣＰＵによって実行することができる。
【０１２２】
有利には、本明細書で詳細に説明されたように、本発明は、（ｉ）事前定義されたスキーマを必要とすることのない様々な非構造的データの情報交換のための柔軟かつ統一のとれたアノテーション表現、（ｉｉ）アノテーション・データに基づく非構造的かつ非決定的情報交換フローのすべての態様をカバーするコラボレーション・パターン使用可能フレームワーク、（ｉｉｉ）複数の情報源からデータを知的に集約するばかりでなく、非構造的関係グラフからリソースを動的に見つける効率的なオンデマンド情報マネージャ、および（ｉｖ）コラボレーション環境におけるデータ交換に関連する主要問題に対処する視覚的制御のための追跡可能な情報埋め込みメカニズムを提供する。
【０１２３】
例えば、本明細書で説明された詳細に基づいて、本発明は、オンデマンド・ビジネス・コラボレーションにデータ構造を提供する。さらに、本発明は、（ｉ）コラボレーション交換機能のためのデータ・コンテンツ・コンテナの仕様；プロジェクト、タスク（プロジェクトおよびタスクは階層的とすることができ、すべてのエンティティおよびアノテーションは階層的とすることができる）、ならびに関連する仕様および関連する制御活動仕様データを含むが、これらに限定されない、組織的データ・エンティティを示すアノテーション・メカニズム、（ｉｉ）プロファイル・データまたはプロフィール・データ・アクセス・リンクを含むが、これらに限定されない、連携エンティティ（個人を含む）を一意に指定するアノテーション・メカニズム、（ｉｉｉ）製品仕様などの仕様または仕様への構造ポインタを含むが、これらに限定されない、連携エンティティおよびコラボレーション活動に関係するコンテンツ・タイプを一意に指定するアノテーション・メカニズム、（ｉｖ）プロファイル・データで指定されるコンテンツに対する権限に基づくアクセス制限に関する任意のアクセス制御情報を指定するアノテーション・メカニズム、（ｖ）組織的データ・エンティティのための依存情報を指定するアノテーション・メカニズム、（ｖｉ）コラボレーション活動を定義するビジネス・コンストラクトのタイプを指定するアノテーション・メカニズム、（ｖｉｉ）コラボレーション活動に特有の共用記憶およびインスタント・メッセージ交換を容易にするための連携エンティティのためのコラボレーション用共用空間を指示するメカニズム、および（ｖｉｉｉ）組織的データ・エンティティまたはコラボレーション活動の定義を完了するためにさらなるデータが必要なことを名前／値ペアを用いて示す追加のアノテーション特性を含むビジネス・コラボレーション交換機能のためのデータ仕様モデルを提供する。
【０１２４】
本発明は、オンデマンド・ビジネス・コラボレーションにデータ生成および記憶基盤をさらに提供する。例えば、オンデマンド・ビジネス・コラボレーションのためのデータ構造を生成する方法は、（ｉ）手動、グラフィック編集、またはコンピュータ支援ソフトウェア工学技術の使用を含む自動化技法を使用して、データ構造を初期化するために１つまたは複数のデータ・コンテンツ・コンテナを生成するステップと、（ｉｉ）先に述べたように、組織的データ・エンティティに関連する組織的データの初期の組を権限情報の初期の組を有するコンテンツ・コンテナにアタッチするステップと（代替として、そのような情報は、ディレクトリまたは連携エンティティ間の以前のプロジェクトから抽出または配布することもできる）、（ｉｉｉ）先に述べたように、同様に初期のコラボレーション活動をアタッチするステップと、（ｉｖ）同様に組織的データ・エンティティに関連する依存情報の初期のアノテーションをアタッチするステップと、（ｖ）コラボレーション活動に関連づけられた１つまたは複数のビジネス・コンストラクトを指示するステップと、
（ｖｉ）組織的エンティティおよびコラボレーション活動の初期化を完了するために必要なアノテーションを追加し、コラボレーション用空間を指示するステップと、（ｖｉｉ）初期データ構造の生成プロセスを完了するために必要に応じて上記の初期化およびアノテーション活動を繰り返すステップとを含む。
【０１２５】
さらに、本発明は、データ構造およびその他の情報をコラボレーション用ディレクトリに集中してまたは分散して保存するための技法を提供する。そのように限定されるものではないが、コラボレーション用ディレクトリは、（ｉ）権限記憶ディレクトリ、（ｉｉ）仕様記憶領域、（ｉｉｉ）ビジネス・コンストラクト仕様記憶領域、（ｉｖ）権限に基づいてデータ検索を収集、制限、および実行するためのアクセス機構を含み、またはそれらに結合され、あるいはその両方が行われる。
【０１２６】
さらにまた、本発明は、オンデマンド・ビジネス・コラボレーションにコラボレーション用ビジネス・コンストラクトおよびパターンも提供する。例えば、ビジネス・コラボレーション・プリミティブが定義され、（ｉ）アタッチされたビジネス活動文書またはリンクをもつまたはもたない要求メッセージ、（ｉｉ）アタッチされたビジネス活動文書またはリンクをもつまたはもたない応答メッセージ、および（ｉｉｉ）要求、応答メッセージ交換関係の論理シーケンスを含む１群のメッセージ交換構造を含むことができる。また、ビジネス・コンストラクト活動が定義され、（ｉ）複数のビジネス・コラボレーション・プリミティブ、（ｉｉ）１組の一貫した活動アノテーション・データ、（ｉｉｉ）活動リンクまたは文書もしくは文書リンクのための１組の情報源、（ｉｖ）ビジネス・コラボレーション・プリミティブの相対実行シーケンスを定義する論理フローを含むことができる。またビジネス・コラボレーション・プロセス・テンプレートが定義され、（ｉ）連携エンティティおよび参加者が係わる権利があるコラボレーション活動、（ｉｉ）開始から終了までビジネス・プロセスを完了させるためにビジネス・シナリオで必要とされるビジネス・コンストラクトの１つまたは複数の完全な組、（ｉｉｉ）ビジネス・コンストラクト、リンク、または文書がそこから送られ、またはそこに届く１組のアプリケーションおよびアプリケーション・インタフェース、および（ｉｖ）連携エンティティと共にビジネス・コンストラクトを活動化および配備するための論理フローの組を含む。
【０１２７】
本発明は、（ｉ）コラボレーション用ディレクトリ・インスタンス、（ｉｉ）利用可能なビジネス・コンストラクトサービスならびにサービス発見および検索メカニズムを指示するビジネス・コンストラクト記憶、（ｉｉｉ）コラボレーション用ビジネス・プリミティブを処理するメッセージ・センダおよびメッセージ・レシーバ、コラボレーション活動の実行中に連携エンティティでの安全な文書交換を管理するファイル転送ハンドラ、オンデマンド・ビジネス・コラボレーション用のデータ構造の作成、集約、解釈を処理するアノテーション・マネージャを含むハイパーチェーン管理エンジン、（ｉｖ）コラボレーション機能を開始するのに必要とされるデータを捕捉するメカニズム、および（ｖ）コラボレーション活動および関連するコラボレーション用ビジネス・プロセスのステータス、ならびに交換されるコラボレーション用データ・エンティティを表示し、複数の連携エンティティおよび活動から最小限のデータ捕捉および集約を実行し、権限制限に基づいてユーザに活動を提示および表示し、権限機能に基づいてユーザにアクション要件を表示する作業監視ダッシュボードを含むコラボレーション管理装置も提供することができる。
【０１２８】
さらにまた、本発明は、（ｉ）少なくとも１つのコラボレーション管理装置を配備するステップと、（ｉｉ）少なくとも１つのビジネス・コラボレーション・プロセス・テンプレートを定義するステップと、（ｉｉｉ）少なくとも１組のデータ構造を作成するステップと、（ｉｖ）ビジネス・コンストラクトの少なくとも１つの完全な組の上で動作することができる情報交換用の少なくとも１つの他の連携エンティティを選択するステップと、（ｖ）ビジネス・コンストラクトの選択された組をサポートするためにプロセス・テンプレート（パターン）をカスタマイズするステップと、（ｖｉ）初期のコラボレーション用データ・エンティティを有するビジネス・コンストラクト内で少なくとも１組の活動を生成するステップと、（ｖｉｉ）ビジネス・コンストラクト活動が進行し、追加のデータ・エンティティを必要になったときに、必要に応じてコラボレーション用データ・エンティティを拡大するステップと、（ｖｉｉｉ）ビジネス・プロセス・テンプレートが実行され、必要に応じてコラボレーション活動に基づくとき、追加のコラボレーション用エンティティを含むステップとを含むことができるオンデマンド・ビジネス・コラボレーション・ソリューションを配備するための方法を提供する。コラボレーション管理装置のサブコンポーネントは、ビジネス・コラボレーション・プロセス実行テンプレートによって必要とされるように、参加エンティティ・サイトに配備されることができる。プロセスでは、データ・エンティティの配備は、連携エンティティの権限によって制限される。１つまたは複数の配備ステップは、追加のエンティティが参加させられ、追加のビジネス・コンストラクトが呼び出されたときに繰り返すことができる。
【０１２９】
本発明の説明的な実施形態が添付の図面を参照しながら本明細書で説明されたが、本発明はそれらの正確な実施形態に限定されるものではないこと、本発明の範囲から逸脱することなく当業者によって様々なその他の変更および修正が行われ得ることを理解されたい。
【図面の簡単な説明】
【０１３０】
【図１】本発明の実施形態による、本発明を実施することができる分散ピアツーピア・コラボレーション・システムの例示的な構成を示した図である。
【図２】本発明の実施形態による、オンデマンド情報交換モデルに基づくハイパーチェーン構成を示した図である。
【図３】本発明の実施形態による、設計ハイパーチェーンの例を示した図である。
【図４】本発明の実施形態による、階層的なアノテーション構造を示した図である。
【図５】本発明の実施形態による、設計要求例のハイパーチェーン・アノテーション・データ・グラフを示した図である。
【図６】本発明の実施形態による、コラボレーション・プリミティブおよびビジネス・コンストラクトの例を示した図である。
【図７】本発明の実施形態による、ビジネス・コンストラクトによって構成されるアウトソーシング・シナリオを示した図である。
【図８】本発明の実施形態による、例示的なコラボレーション・パターンを示した図である。
【図９】本発明の実施形態による、ハイパーチェーン・マネージャを示した図である。
【図１０】本発明の実施形態による、ハイパーチェーン・マネージャのアクション・マネージャを示した図である。
【図１１】本発明の実施形態による、リソースのためのアノテーション生成に関連するグラフィカル・ユーザ・インタフェースを示した図である。
【図１２】本発明の実施形態による、アウトソーシング作業の生成に関連するグラフィカル・ユーザ・インタフェースを示した図である。
【図１３】本発明の実施形態による、設計要件のためのアノテーション生成に関連するグラフィカル・ユーザ・インタフェースを示した図である。
【図１４】本発明の実施形態による、本発明の１つまたは複数のコンポーネント／方法をそれによって実施することができるコンピューティング・システムの説明的なハードウェア実装を示した図である。
【符号の説明】
【０１３１】
１００  コラボレーション・システム
１１０  製品会社
１１２  供給業者
１１４  サービス提供業者
１１６  契約製造業者
１１８  分散ネットワーク
１２０  ファイアウォール
２００  ハイパーチェーン構成
２１０  コラボレーション・パターン
２２０  アノテーション構造
２３０  アノテーション記憶
２４０  アノテーション生成
２５０  ハイパーチェーン・マネージャ
３００  設計ハイパーチェーン
３０２  業務提携者
３０４  業務提携者
３０６  業務提携者
３０８  ＣＡＤファイル
３１０  メタ・データ
４００  アノテーション構造
５００  ハイパーチェーン・アノテーション・データ・グラフ
５０８  フィールド
６００  プロトコル構成
６０２  ビジネス・シナリオ
６０４  ビジネス・コンストラクト
６０６  コラボレーション・プリミティブ
６０８  メッセージング・レイヤ
６１０  トランスポート・レイヤ
７０２  ＲＦＤ
７０４  ＲＦＵ
７０６  ＲＦＵ
７０８  ＲＦＤ受諾
７１０  設計提示
７１２  設計検査
７１４  ＲＦＵ
７１６  中間再検査
７１８  ＲＦＵ
７２０  設計受諾
９１０  拡張されたビジネス・コラボレーション・ポータル／ダッシュボード
９２０  拡張されたビジネス・コラボレーション（ｅＢＣ）マネージャ
９３０  ハイパーチェーン・マネージャ
９５０  ＷＢＩ／Ｃ  Ｅｘｐｒｅｓｓレイヤ
９６０  Ｗｅｂｓｐｈｅｒｅレイヤ
９３２  コラボレーション用ディレクトリ
９３４  アノテーション・マネージャ
９３６  メッセージ・センダ
９３８  メッセージ・レシーバ
９４０  アクション・マネージャ
９４０  アクション・マネージャ
９７２  コミュニケータ
９７４  アノテーション・データ・パーサ
９７６  イベント捕捉モジュール
９７８  マスタ・コントローラ
９８０  アクション・ハンドラ
９８２  スマート・アダプタ
９９０分散サービス・グリッド
１３００  コンピュータ・システム
１３１０  コンピュータ・バス
１３０２  プロセッサ
１３０４  メモリ
１３０６  Ｉ／Ｏ装置
１３０８  ネットワーク・インタフェース
【図１】
2007506170.tif 000002
【図２】
2007506170.tif 000003
【図３】
2007506170.tif 000004
【図４】
2007506170.tif 000005
【図５】
2007506170.tif 000006
【図６】
2007506170.tif 000007
【図７】
2007506170.tif 000008
【図８】
2007506170.tif 000009
【図９】
2007506170.tif 000010
【図１０】
2007506170.tif 000011
【図１１】
2007506170.tif 000012
【図１２】
2007506170.tif 000013
【図１３】
2007506170.tif 000014
【図１４】
2007506170.tif 000015