JP2002517826A

JP2002517826A - エンタープライズ内または間におけるコラボレーション管理システム及び管理方法

Info

Publication number: JP2002517826A
Application number: JP2000552608A
Authority: JP
Inventors: ランジット・エヌ・ノタニ; アバイ・ブイ・パラスニス; マーク・ビー・ホイップル
Original assignee: アイ２・テクノロジーズ・インコーポレイテッド
Priority date: 1998-06-05
Filing date: 1999-06-03
Publication date: 2002-06-18
Also published as: KR20010052567A; AU5079899A; TWI239461B; EP1082688A1; CA2333737A1; US7039597B1; WO1999063464A1

Abstract

(57)【要約】エンタープライズのコラボレーションのためのコンピュータ実行プロセスが開示されている。そのプロセスは、分配された複数のノードにおいて実行される、ワーク・フローのための予め定義された１組の機能を記憶する。そして、分配されたノードの各々において、ワーク・フローに自動的に働きかけて、予め定義された機能を実行する。

Description

【発明の詳細な説明】

【０００１】発明の技術分野本発明は一般に、サプライチェーン、エンタープライズ、およびサイト・プラ
ンニングに関するものであり、特に、エンタープライズ内または間におけるコラ
ボレーション管理のシステム及び方法に関するものである。

【０００２】発明の背景サプライチェーン、エンタープライズ、およびサイト・プランニングのアプリ
ケーションおよび環境は、意思決定支援と管理業務の補助のために製造エンティ
ティによって広範に使用されている。サプライチェーン、エンタープライズ、お
よびサイト・プランニングのための意思決定支援環境は、一体式シングルドメイ
ン環境から、一体式マルチドメイン環境に進化してきた。従来のプランニング・
ソフトウェア・アプリケーションは、種々の会社から提供される広範囲な製品に
利用できる。これらの意思決定支援ツールにより、エンティティは複雑な製造業
務をより効率的に管理することができる。しかしながら、サプライチェーンは、
一般に、複数の分散型異種プランニング環境を特徴としている。従って、サプラ
イチェーン・プランニングの問題に適用する場合には、一体式のアプリケーショ
ン・アーキテクチャに起因して従来環境の効果に制限がある。また、これらの問
題は、サプライチェーン全体の「所有者」が存在しない場合に悪化する。

【０００３】プランニング環境の次の発展段階に望まれるのは、複数のドメインならびに複
数のエンジンおよび製品にまたがって、製品をサポートするマルチドメイン異種
アーキテクチャを確立することである。種々のプランニング環境をシームレス・
ソリューションに統合することにより、ドメイン間およびエンタープライズ間の
サプライチェーン・プランニングを実現できる。また、いくつかのプランニング
・アプリケーションによって提供される重要機能は、単なる追跡処理ではなく、
対象環境の最適化である。特に、アイ・ツー・テクノロジーズ社（Ｉ２ＴＥＣ
ＨＮＯＬＯＧＩＥＳ）から市販されている製品ＲＨＹＴＨＭファミリが最適化機
能を提供している。しかしながら、エンタープライズまたはサプライチェーン・
レベルのプランニングに関しては、ＳＡＰから入手できるものなど多くの従来ア
プリケーションはエンタープライズ資源プランニング（ＥＲＰ）エンジンを使用
し、最適化を提供するものではない。

【０００４】エンタープライズの成功または失敗は、エンタープライズ内での意思決定の品
質に大いに左右される可能性がある。したがって、エンタープライズの成功には
、エンタープライズ内での最適な意思決定を支援するアイ・ツー・テクノロジー
ズ社の製品ＲＨＹＴＨＭファミリなどの意思決定支援ソフトウェアが特に重要で
ある。一般に、最適な意思決定は、意思決定に達すると考えられる「世界」の広
がりである意思決定支援のドメインに関係している。例えば、行われようとして
いる意思決定は、工場が所定の期間中に生産しなくてはならない所定の品物の数
量であってもよい。「最適な」回答は、意思決定のドメインに依存している。ド
メインは、例えば、工場それ自体のみ、工場を含むサプライチェーン、エンター
プライズ全体、またはマルチエンタープライズ・サプライチェーンであってもよ
い（後の２つは、大きいドメインまたはマルチドメインと考えられる）。一般に
、意思決定支援のドメインが大きいほど、意思決定はより最適なものとなる。し
たがって、意思決定支援ソフトウェアが、意思決定過程で、より大きなドメイン
を範囲に含むことが望ましい。しかしながら、対象範囲をこのように拡大するこ
とによって重大な問題が生じることがある。

【０００５】そのような問題の１つとして、マルチドメインサプライチェインを効率的に計
画し、管理することがある。典型的には、マルチドメインサプライチェインは、
手動で、特別の方法により、定義され、管理される。これは、しばしば、サプラ
イチェインの重要な構成部分の脱落に結びつく。そして、コストと時間をかけて
、サプライチェインに含まれるマルチドメインの間のサプライチェインプランを
作りなおすことになる。さらに、脱落に気付かなければ、サプライチェインプラ
ンのオペレートと管理が非効率なものとなってしまう。

【０００６】発明の開示本発明によれば、エンタープライズ内又は間においてコラボレーションを管理
するシステム及び方法であって、従来のシステム及び方法に関連した不利益と問
題を、実質的に解消し又は減少させるシステム及び方法が開示されている。特に
、本発明は、１又はそれ以上のエンタープライズのマルチ・ノードにまたがって
コラボレーションを管理する、コンピュータで実行する方法を提供する。

【０００７】本発明の一態様によれば、分配されたワーク・フローを管理するためのコンピ
ュータ実行プロセスは、分配された複数のノードにおいて実行される、ワーク・
フローのための予め定義された１組の機能を記憶するステップを有する。そして
、コンピュータプロセスは、分配されたノードの各々において、ワーク・フロー
に自動的に働きかけて、前記予め定義された機能を実行する。

【０００８】特に、本発明の一態様においては、複数のエンタープライズ間においてコラボ
レーションをデザインし、生成するためのコンピュータ実行プロセスは、第１の
エンタープライズから予備的なコラボレーションのデザインを受け取るステップ
を有する。その予備的なコラボレーションのデザインは、予め定義された第２の
エンタープライズに、検査のために自動伝達される。第２のコラボレーションか
ら、予備的なコラボレーションに対する応答が受け取られる。応答を、第１のエ
ンタープライズに、検査のために自動伝達する。

【０００９】また、本発明の他の態様においては、複数の他のエンタープライズに、第１の
エンタープライズによって生成されたコラボレーションを分配するためのコンピ
ュータ実行プロセスは、最初に、コラボレーションを受け取るステップを有する
。予め定義された第１のエンタープライズに、コラボレーションの予め定義され
た第１の部分が、自動伝達される。予め定義された第２のエンタープライズに、
前記コラボレーションの予め定義された第２の部分を自動伝達する。

【００１０】本発明のさらに他の態様においては、複数のエンタープライズに渡るコラボレ
ーションを追跡するための、コンピュータ実行プロセスは、第１のエンタープラ
イズの第１のノードに、第１のノードにおけるコラボレーションのオペレートに
関連した、第１の予め定義された１組のデータについて自動的に質問するステッ
プを有する。第１の１組のデータは、自動的に、管理システムに伝達される。第
２のエンタープライズの第２のノードに、第２のノードにおけるコラボレーショ
ンのオペレートに関連した、第２の予め定義された１組のデータについて自動的
に質問がされる。第２の１組のデータが管理システムに自動的に伝達される。

【００１１】本発明の技術上の利点は、エンタープライズ内のコラボレーションの管理のた
めの、改良された方法及びシステムを提供することである。特に、コラボレーシ
ョンは複数のノードに渡って他のコラボレーションを、生成し、展開し、管理す
るように定義されている。したがって、コラボレーションは、重要な構成部分を
落とすことのないように、効率的に管理され、定義される。

【００１２】本発明ならびにその利点は、同様の参照符号によって同様の特徴を示す添付図
面とともに以下の説明を参照することによって更に完全に理解されるであろう。

【００１３】発明の詳細な説明意思決定支援プロセスの改良には、最適意思決定のためにエンタープライズ・
レベルおよびマルチエンタープライズ・レベルの意思決定支援を提供するための
拡張が含まれる。技術的および概念的には、エンタープライズ・レベルおよびマ
ルチエンタープライズ・レベルの意思決定支援を行うことは、ファクトリ・レベ
ルおよびサプライチェーン・レベルの意思決定支援を行うこととは異なっている
。その理由は、（エンタープライズまたはマルチエンタープライズ内の複数の事
業部門などの）マルチドメイン状況では、異なるドメインが異なる意思決定支援
ソフトウェアをしばしば使用しているからである。また、マルチドメイン状況で
は、あるドメインが別のドメインに特定の意思決定を強制することができない。
すなわち、この環境における最適意思決定支援は、強制とは反対の協定環境でし
ばしば実行される必要がある。

【００１４】マルチドメイン状況における意思決定支援は、強制的な方法ではなく、意思決
定支援への協調的な方法を追求することによって達成できる。そのような環境を
実現するために、大規模な協調的意思決定を実現可能にする手助けとなるインタ
ーネット、Ｗｅｂ、ＪＡＶＡ、ＸＭＬ、ＣＯＲＢＡ等を含む種々の通信および分
散処理技術を利用できる。ＲＨＹＴＨＭ−ＧＬＯＢＡＬＣＯＬＬＡＢＯＲＡＴ
ＩＯＮＭＡＮＡＧＥＲ（ＧＣＭ）やＲＨＹＴＨＭ−ＧＬＯＢＡＬＣＯＬＬ
ＡＢＯＲＡＴＩＯＮＤＥＳＩＧＮＥＲ（ＧＣＤ）など、協調的な意思決定支
援方法を可能にする製品は、アイ・ツー・テクノロジーズ社からすぐに入手でき
る。

【００１５】コラボレーション・システムとプロセス・コンポーネント図１は、エンタープライズ・コラボレーションをサポートできるコンピュータ
実行アーキテクチャの一実施形態の図である。図示されているように、グローバ
ル意思決定支援アーキテクチャは、基礎をなすリンク・コンポーネント、ビジョ
ン・コンポーネント、グローバル・メッセージング・コンポーネント、およびデ
ータ・ウェアハウス・コンポーネントの上に構築できる。また、意志決定支援ア
ーキテクチャによってサポートされるグローバル・コラボレーション・デザイナ
（ＧＣＤ）およびグローバル・コラボレーション・マネージャ（ＧＣＭ）をコラ
ボレーションに含むことができる。グローバル・コラボレーション・デザイナは
、コラボレーションの設計と具体化に利用でき、グローバル・コラボレーション
・マネージャは、コラボレーションの実行に利用できる。この手法では、コラボ
レーションをモジュールと呼んで、別のバージョンを作ることができる。

【００１６】図２は、グローバル・コラボレーション・フレームワークの構成要素の一実施
形態の図である。図示されているように、フレームワークにより、ハブ・エンタ
ープライズ２はスポーク・エンタープライズ４およびウェブ・エンタープライズ
６と協同作業することができる。ハブ・エンタープライズ２とスポーク・エンタ
ープライズ４はいずれもグローバル・コラボレーション・マネージャ８を含んで
いる。グローバル・コラボレーション・マネージャ８は、それぞれの内部グロー
バル・コラボレーション・ワークスペース１０に連結されて交信している。また
、外部グローバル・コラボレーション・ワークスペース１２が、ハブ・エンター
プライズ２、スポーク・エンタープライズ４、およびウェブ・エンタープライズ
６の間でデータを共有する手段となっている。ハブ・エンタープライズ２は、電
子データ交換（ＥＤＩ）プロセッサ１４を介して付加価値通信網（ＶＡＮ）と協
同作業をすることもできる。また、ハブ・エンタープライズ２は、グローバル・
メッセージ・バス１５を使って他のハブ・エンタープライズと通信したり協同作
業をすることができる。

【００１７】稼働中、コラボレーションの主コントローラは、ハブ・エンタープライズ２の
ＧＣＭエンジン８であってもよい。ハブ／ハブの関係は、グローバル・メッセー
ジ・バス１５によって簡単化でき、また、ハブ／スポーク及びハブ／ウェブの関
係は、外部グローバル・コラボレーション・ワークスペース（ＧＣＷ）１２によ
って簡単化できる。図示されているように、ハブ・エンタープライズ２は、一般
に、内部ＧＣＷ１０と外部ＧＣＷ１２とを持つことができる。内部ＧＣＷ１０は
、内部ユーザ・インタフェースおよびＥＤＩプロセッサ１４とのデータの共有お
よび交換に利用できる。外部ＧＣＷ１２は、スポーク・エンタープライズ４よび
ウェブ・エンタープライズとのデータの共有および交換に利用できる。

【００１８】安全性のために、外部ＧＣＷ１２は、ＤＭＺの中またはハブ・エンタープライ
ズ２の一連のファイアウォールの外側に設置できる。このように、ハブ・エンタ
ープライズ２の保護された一連のネットワークに外側から直接接続する必要が無
い。外部ＧＣＷは、例えば、ＩＩＯＰ、ＨＴＴＰ、およびＨＴＴＰＳの接続を受
け付けることができる。特に、後の２つの接続は、既存のファイアウォール構成
を相互接続するのに有用である。このように、クライアント側（スポーク・ノー
ドまたはウェブ・ノード）にもサーバ側（ハブ・ノード）にもファイアウォール
構成が不要であり、それにより、より速やかに展開できるソリューションを作る
ことができる。

【００１９】図３は、特定のモジュールを構成するあるソフトウェア要素を強調表示させた
、図２のグローバル・コラボレーション・フレームワークの図である。図示され
ているように、グローバル・コラボレーション・マネージャ・モジュールのソフ
トウェアは、ハブ・エンジン８内、スポーク・エンジン８内、ハブ−ユーザ・ユ
ーザ・インタフェース（ＵＩ）内、スポーク−ユーザＵＩ内、およびウェブ−ノ
ードＵＩ内といった場所に存在しうる。また、モジュールは、ハブ・エンタープ
ライズ２およびスポーク・エンタープライズ４上のネイティブ・アプリケーショ
ン１７と通信できる。ネイティブ・アプリケーション１７との通信は、同期式（
点線）であっても、非同期式（実線）であってもよい。ネイティブ・アプリケー
ション１７との非同期通信は、図示されているように、内部ＧＣＷ１０によって
簡単化できる。また、ハブ・エンタープライズ２側にグローバル・シリーズ・デ
ータベース（ＧＳＤＢ）が存在していてもよい。

【００２０】図４は、最適な意志決定を行うためにエンタープライズ内またはエンタープラ
イズ間の協同作業を可能にする、全体が１６で示されたシステムの一実施形態の
ブロック図である。図示されているように、システム１６は、コンピュータ・シ
ステム上で動作するハブ・エンジン内のプロセスとなりうるハブ・ノード１８を
含んでいる。ハブ・ノード１８は、やはりコンピュータ・システム上で動作する
ハブ・エンジン内のプロセスとなりうるスポーク・ノード２０と結合され、これ
と通信を行う。図示されているように、スポーク・ノード２０は、ハブ・ノード
１８のエンタープライズ境界２２の外側にあってもよい。ハブ・ノード１８は、
１つ以上のコンピュータ・システム上で動作するスポーク・エンジン内のプロセ
スとなりうる複数のスポーク・ノード２４と結合され、これと通信を行う。ハブ
・ノード１８は、コンピュータ・システム上で動作するウェブ・ブラウザ内のプ
ロセスとなりうる複数のウェブ・ノード２６と結合され、これと通信を行える。
また、ハブ・ノード１８は、ＥＤＩシステムとのゲートウェイとなりうるＥＤＩ
（電子データ交換）プロキシ２８に連結され、これと通信を行う。

【００２１】ハブ・エンジンおよびスポーク・エンジンは、グローバル・コラボレーション
・ワークスペースと共に、グローバル・コラボレーション・マネージャの基本エ
ンティティとなりうる。この環境では、ハブ・エンジンがコラボレーションの主
コントローラである。ハブ・エンジンは、グローバル・コラボレーションならび
にローカル・コラボレーションの両方と連係動作できる。グローバル・コラボレ
ーションは、ハブ・ノード１８、スポーク・ノード２０と２４、およびウェブ・
ノード２６にまたがるものである。ローカル・コラボレーションは、任意の単一
機能ハブまたはスポーク／スポーク−グループ上で動作できる。これらのコラボ
レーションは分散させることも可能であるが、ここでは単一エンタープライズの
範囲内にとどまっている。ハブ・エンジンは、ハブ−ユーザ・インタフェース（
ＵＩ）ならびにＥＤＩプロキシ２８のＶＡＮ−ＥＤＩプロセッサとも連係動作で
きる。一実施形態において、ハブ・エンジンは、複数のコラボレーションならび
に同一コラボレーションの複数のバージョンと同時に連係動作できるマルチスレ
ッド型のエンジンである。また、ハブ・エンジンは、コラボレーションを動的に
ロードおよび実行できる。

【００２２】スポーク・エンジンは、コラボレーションを開始させるように作用することも
可能である。この環境では、ハブ・エンジンとは異なり、スポーク・エンジンは
独立したエンティティではない。したがって、スポーク・エンジンは、ハブ・エ
ンジンと一緒でなければ、コラボレーションと連係動作できない。また、スポー
ク・エンジンは、別のスポーク・エンジンや別のウェブ・ノードと連係動作する
ことができない。ハブ・エンジンと同様に、スポーク・エンジンもマルチスレッ
ド化が可能で、複数のコラボレーションならびに同一コラボレーションの複数の
バージョンと同時に連係動作できる。スポーク・エンジンも、コラボレーション
を動的にロードおよび実行できる。

【００２３】図５は、グローバル・コラボレーション・ワークスペース３０の使用法の一実
施形態のブロック図である。図５で、グローバル・コラボレーション・ワークス
ペース３０は、コラボレーション内の種々のエンティティ間でデータ／オブジェ
クトを共有するために使用される主エンティティである。図示されているように
、ワークスペース３０は、グローバル・コラボレーション・マネージャ（ＧＣＭ
）３２、ローカル・システム３４、ウェブ・サーバ３６、ウェブ・インタフェー
ス３７、およびネイティブ・アプリケーション３８と接続して機能できる。一般
に、オブジェクトは、一方のエンティティによってグローバル・コラボレーショ
ン・ワークスペース３０に配置され、他方のエンティティによって検索されるこ
とが可能である。検索は、照会または登録によって達成できる。このように、グ
ローバル・コラボレーション・ワークスペース３０は、データベースならびにメ
ッセージ・バスの属性を組み合わせている。

【００２４】グローバル・コラボレーション・ワークスペースは、メモリ内スロットまたは
永久スロットの階層として編成できる。スロットは、待機式のものであっても通
常のものであってもよく、各スロットに細かい許可段階を付けることもできる。
許可段階は、ユーザ別、動作別に割り当てることができる。主な動作は、読出、
書込、取込、および登録である。

【００２５】メモリ内スロットは、データを揮発性メモリに保持する。メモリ内スロットか
らの書込および検索は極めて高速であるが、グローバル・コラボレーション・ワ
ークスペース３０が停止した場合にデータが失われる。メモリ内スロットと共に
使用されるとき、グローバル・コラボレーション・ワークスペース３０は、セキ
ュリティとメッセージング機能とを備えた高速で確実なメモリ内オブジェクト・
データベースと考えることができる。一方、永久スロットは、そのデータを安定
記憶機構に保持する。永久スロットからの書込および検索はメモリ内スロットか
らの場合よりも遅いが、グローバル・コラボレーション・ワークスペース３０が
停止した場合でもデータは失われない。

【００２６】メモリ内スロットを使用するか、永久スロットを使用するかは、アプリケーシ
ョンに応じて決定できる。グローバル・コラボレーション・ワークスペース３０
は、オブジェクトの形でデータを記憶するもので、Ｊａｖａオブジェクト、ＣＯ
ＲＢＡオブジェクト、または任意のバイト・アレイを記憶することができる。グ
ローバル・コラボレーション・ワークスペース３０は、メモリ内の各機能と結合
されて、アイ・ツー・テクノロジーズ社のサプライチェーン・プランナとファク
トリ・プランナなど他のオブジェクト指向メモリ内エンジン間の高速データ共用
機構に適したグローバル・コラボレーション・ワークスペース３０を形成する。

【００２７】グローバル・コラボレーション・デザイナ（ＧＣＤ）は、コラボレーション設
計者が、グローバル・コラボレーション・マネージャを使用して実行されるコラ
ボレーションを対話式に設計、具体化、および配備できるようにするツールであ
る。グローバル・コラボレーション・デザイナの出力は、グローバル・コラボレ
ーション・マネージャが自動的にロードおよび実行できるコードである。グロー
バル・コラボレーション・デザイナにより、設計者は新しいコラボレーションを
作成し、既存のコラボレーションを検索し、別のバージョンのコラボレーション
を作ることができる。グローバル・コラボレーション・デザイナにより、設計者
は、コラボレーション用のハブ・アンド・スポーク式ネットワークを設計し、コ
ラボレーションの事象およびメッセージを設計することもできる。グローバル・
コラボレーション・デザイナは、標準的なオブジェクト・ライブラリと標準的な
コンポーネント・ライブラリとを統合させて、グローバル・コラボレーション・
デザイナの中でより使いやすくすることができる。グローバル・コラボレーショ
ン・デザイナは、同期、非同期、サブワークフロー、ＡＮＤ分割、ＯＲ分割、同
期結合、ヘテロキャスト（heterocast）分割、ヘテロキャスト結合等を備えた高
度なマルチエンタープライズ・ワークフローを作成するために利用できる。グロ
ーバル・ワークフローおよび局所ワークフローのいずれも作成可能である。グロ
ーバル・コラボレーション・デザイナは、コラボレーションの自動検証と、グロ
ーバル・コラボレーション・マネージャによって実行されるコードの自動コード
生成とを実行できる。生成されたコードは、所望であれば手作業で編集できる。
また、グローバル・コラボレーション・デザイナは、セキュリティ・マネージャ
構成およびグローバル・コラボレーション・ワークスペース構成の生成を含むコ
ラボレーションの具体例を生成できる。

【００２８】図６は、コラボレーションのライフサイクルの一実施形態の図である。図示さ
れているように、ステップ４０で、グローバル・コラボレーション・デザイナを
使用してコラボレーションを設計できる。ステップ４２で、グローバル・コラボ
レーション・デザイナを使用してコラボレーションを具体化できる。次に、ステ
ップ４４で、グローバル・コラボレーション・デザイナとグローバル・コラボレ
ーション・マネージャを使って、具体化されたコラボレーションを配備できる。
配備後、ステップ４６でグローバル・コラボレーション・マネージャを使ってコ
ラボレーションを実行できる。その後、新しい具体例を生成できるし、コラボレ
ーションの新しいバージョンを作成することもできる。新しい具体例を生成する
には、ステップ４２に戻る。新バージョンの場合は、ステップ４８でグローバル
・コラボレーション・デザイナを使用してコラボレーションを修正できる。

【００２９】シングルドメイン意思決定支援からマルチドメイン意思決定支援への拡張は複
雑になりうる。特に、マルチドメイン意思決定支援によって引き起こされる多数
の問題と、エンタープライズ内およびエンタープライズ間のコラボレーションが
最適意思決定を行うことを可能にする本発明のシステムおよびプロセスが、その
ような問題にどのように取り組んだかを以下の考察部分で述べる。

【００３０】表現の異質性コラボレーションの１つの問題は、複数のエンタープライズにわたる異質な表
現間に橋をかけることである。コラボレーションが正常に行われる以前に、エン
タープライズ間の異質な表現に橋をかける必要がある。エンタープライズは、し
ばしば同じデータを別な形で表現する。これらの違いは、意味論的な違いから、
技術的な違い、命名の違い等にまで及ぶ。これらの違いに橋をかける１つの明ら
かな解決策は、標準化である。しかしながら、これにより、どの規格に合わせる
かという問題がすぐに生じる。本発明のシステムおよびプロセスでは、そのよう
な要件を回避できる。

【００３１】取り組む必要がある３つの関連基準カテゴリが存在しうることに注意されたい
。これら３つのカテゴリは、形式基準、転送基準、および意味基準である。形式
基準は、データ／オブジェクトを符号化する技術上の形式のことを言う。例とし
て、ＸＭＬ、ＪａｖａＳｅｒｉａｌＳｔｒｅａｍｓ、ＩＩＯＰＳｅｒｉａ
ｌＳｔｒｅａｍｓ、およびＥＤＩ形式などがある。転送基準は、データを次々
に伝達するために使用される。これらは、ＨＴＴＰ、ＩＩＯＰ、ＲＭＩ、ＤＣＯ
Ｍ、ＦＴＰ，付加価値通信網、ＭＱＳｅｒｉｅｓのような非同期メッセージ
・バス等を含むことができる。第３の意味基準は、データの意味内容を記述する
方法である。例として、ＥＤＩ、Ｉ２ＣＯＭＭＯＮＤＡＴＡＭＯＤＥＬ（
ＣＤＭ）などがある。

【００３２】この見解で基準について考えると、前述の問題は自ずと理解できる。既存の基
準の多くが前述の二つ以上のカテゴリを扱っているが、種々の基準の考察は、ど
のカテゴリが論じられるかの類別を行わないことから、今日、多くの混乱を招い
ている。例えば、ＥＤＩは本質的には意味基準であるが、一般に形式基準（ＥＤ
Ｉファイル形式）および転送基準（付加価値通信網）も含んでいる。これが理解
されれば、ＥＤＩ意味基準を他の２つから切り離せることが明らかになる。した
がって、意味ＥＤＩオブジェクトは、ＪａｖａＳｅｒｉａｌＳｔｒｅａｍｓ
などの別の形式に符号化でき、ＨＴＴＰなどの他の転送基準で転送できる。同様
に、ＸＭＬは本質的には、種々の意味基準を符号化するために利用できる形式基
準である。ＥＤＩをＸＭＬに符号化するための作業が進められている。

【００３３】いくつかの形式基準は、ＸＭＬ、ＥＤＩ形式、ＪａｖａＳｅｒｉａｌＳｔ
ｒｅａｍｓ（Ｊａｖａ言語やＪａｖａプラットフォームとの混乱を避けるために
、Ｊａｖａ形式と呼ぶ）およびＩＩＯＰＳｅｒｉａｌＳｔｒｅａｍｓなど
、現在のグローバル・コラボレーション・マネージャでサポートできる。一実施
形態では、これらのうちのＪａｖａ形式が基本形式であり、その他が派生形式で
ある。基本形式としてＪａｖａ形式が選択されたのは、Ｊａｖａ形式が他の形式
を生成する挙動を含むことができるからである。ＸＭＬ、ＥＤＩ、およびＩＩＯ
Ｐ形式は、Ｊａｖａ形式から派生させることができる。

【００３４】図７Ａ及び７Ｂは、アイ・ツー・テクノロジーズ社からの共通ソフトがリレー
ションシップの両側に存在している状況と、していない状況の図である。例えば
、図示されているように、両側にＲＨＹＴＨＭＧＬＯＢＡＬＣＯＬＬＡＢＯ
ＲＡＴＩＯＮＭＡＮＡＧＥＲがある場合、中間形式に変換しても何も得られな
い。これは不要な非能率を招き、データ（オブジェクトではない）だけが交換可
能であり、アプリケーションの範囲を限定するものである。したがって、両側に
同じソフトウェアが存在する場合、２進Ｊａｖａオブジェクトを直接に交換でき
る。他方、例えば、ＲＨＹＴＨＭＧＬＯＢＡＬＣＯＬＬＡＢＯＲＡＴＩＯＮ
ＭＡＮＡＧＥＲが片側にしか存在しない場合、ＸＭＬまたはＥＤＩ形式の「オ
ブジェクト」を生成（アウトバウンド）および解釈（インバウンド）できる。

【００３５】転送基準に関して述べると、当該グローバル・コラボレーション・マネージャ
は、ＨＴＴＰ、ＩＩＯＰ、および非同期メッセージ・バスを含む種々の転送基準
をサポートできる。以下に多関係タイプの処理について詳述する。

【００３６】意味基準について述べると、当該グローバル・コラボレーション・マネージャ
は主として２つの意味基準、ＥＤＩとＲＨＹＴＨＭ−ＣＤＭ、をサポートできる
。ＥＤＩがサポート可能であるのは、ＥＤＩが一般に最も普及している意味基準
だからである。しかしながら、これには、プランニング・ドメインの深い部分を
範囲に含まないという欠点（数ある中で）がある。他方、ＲＨＹＴＨＭ−ＣＤＭ
は、プランニング・ドメインの深い部分を範囲に含み、マルチエンタープライズ
意思決定支援を実行するのに適切な構造を提供する。また、この形式は、アイ・
ツー・テクノロジーズ社のプランニング・エンジンのすべてによってサポートさ
れている。

【００３７】一般に、ＥＤＩなどの公認基準の問題の１つは、エンタープライズが交換した
い種類のデータ／オブジェクトに十分に対応していない場合があることである。
また、特定のオブジェクト上で標準化するために基準本体を待つことがオプショ
ンでないことがあり、公認基準を使用することによってサプライチェーンが特に
競争に有利な利点を有しない。前述および他の理由により、当該グローバル・コ
ラボレーション・マネージャは、独自のコミュニティ基準をサポートすることに
よって別の標準化法をサポートしている。エンタープライズのコミュニティは、
例えばＲＨＹＴＨＭ−ＧＣＤを利用して、当該コミュニティだけに関連がある基
準セットを考案することができる。ＲＨＹＴＨＭ−ＧＣＤは、これらの独自のコ
ミュニティ基準をサポートし、実施する。ＲＨＹＴＨＭ−ＧＣＤは、独自のコミ
ュニティ基準を構成しうるビルディング・ブロック・オブジェクトから成るライ
ブラリもサポートする。独自のコミュニティ基準は、当該エンタープライズが交
換したい種類のデータ／オブジェクトを正確に対象として含むように設計できる
；特定の基準に同意する必要があるのは関係当事者だけなので、プロセスが基準
本体を待つよりもはるかに速い；パートナーの種々のカテゴリに合わせて種々の
基準を（極端な場合はパートナー毎に別々の基準を）開発できる；競争相手を越
える競争利益をサプライチェーンに与える基準を開発できる等、数多くの利点が
ある。

【００３８】多関係タイプコラボレーションを可能にするための別の問題は、多関係タイプの扱いである
。エンタープライズは、そのパートナーとの間に種々のタイプの関係を持ってい
る。関係が異なるケースとして、一方は大きな取引相手間、他方は小さな取引相
手間の場合；サプライチェーンに与える影響がほぼ同等であるエンタープライズ
間と、サプライチェーンに与える影響が等しくないエンタープライズ間の場合；
一方は高度な技術程度を備えたエンタープライズ間、他方は等しくない技術程度
を備えたエンタープライズ間、がある。理解される通り、これらの異なる関係タ
イプは別々に処理されるべきである。

【００３９】当該グローバル・コラボレーション・マネージャは、エンタープライズ間の関
係を、上に説明され図４に記載されているハブ・アンド・スポーク式のネットワ
ークとして構成できる。当該実施形態の４タイプの関係は、ハブ／ウェブ、ハブ
／ＶＡＮ−ＥＤＩ、ハブ／スポーク、およびハブ／ハブである。各関係タイプに
、その適切用途がある。

【００４０】ハブ／ウェブについて述べると、人々が今日の電子商取引について話すとき、
ウェブ・ブラウザといくつかの集中サーバとが通信するアーキテクチャを含意す
ることが多い。このアーキテクチャは、このアーキテクチャをサポートするイン
フラストラクチャが一般に既に所定の位置にある、サーバ側に管理を集中させる
ことができるなど、いくつかの利点を有している。しかしながら、このアーキテ
クチャは、ウェブ・ブラウザ側に人間が存在している必要がある、という大きな
欠点も備えている。そのため、システム間の自動化が不可能である。前述および
他の賛否に基づき、この関係タイプは、エンタープライズが、重要度の低いパー
トナーまたは技術程度の低いパートナーとデータ交換する必要がある場合に適切
でありうる。

【００４１】ハブ／ＶＡＮ−ＥＤＩについて述べると、今日、エンタープライズ間の電子取
引の大部分は、付加価値ネットワーク全体にＥＤＩを送ることによって行われて
いる。この方法の利点は、システム間の統合が可能であり、今日、一般にサポー
トされていることである。この方法の欠点は、独自のＶＡＮにデータを送信する
ための多大なコスト、真の標準化が存在しないことによる高い管理費、真の「基
準」をエンタープライズに適した形に変換するためだけのサード・パーティ・ツ
ールが必要であること、システムと人とを統合するためのサポートが存在しない
こと、独自基準または企業基準のサポートが存在しないことである。前述および
他の賛否両論に基づき、この関係タイプは、レガシーＶＡＮ−ＥＤＩ環境をサポ
ートするときに適切でありうる。

【００４２】ハブ／スポークについて述べると、この関係タイプも、ＶＡＮ−ＥＤＩのよう
にシステム間の統合を可能にする。構造的には、ハブ／スポークは、ハブ・エン
ジンとスポーク・エンジンとの間のコラボレーションである。ハブ／スポーク関
係は、ＶＡＮ−ＥＤＩと比較し、公衆網の利用によりネットワーク費用を削減で
きる、ハブ／スポーク関係インフラストラクチャの大部分を一元的に配備して管
理できるので管理費がＶＡＮ−ＥＤＩよりはるかに安い、（ただのデータに加え
）真のオブジェクトを交換により、更に高度なコラボレーションが可能となる、
ＥＤＩ、Ｉ２−ＣＤＭ、独自コミュニティ基準を含む複数の意味基準をサポート
できる、という利点を有することができる。前述の特徴に基づき、ハブ／スポー
クの関係は、高度なシステム間コラボレーションを実行することを望むエンター
プライズ間に適切でありうる。また、エンタープライズのいずれかにもアイ・ツ
ー・テクノロジーズ社のソフトウェアが存在していない場合にも適切でありうる
。これは、ハブ・エンタープライズによってハブ／スポークの関係が一元的に配
備されるからである。

【００４３】ハブ／ハブについて述べると、この関係は、ハブとスポーク・エンジン間では
なく２つのハブ・エンジン間で実行されることを除き、ハブ／スポークと同様で
ある。この特徴に基づき、ハブ／ハブの関係は、高度なシステム間コラボレーシ
ョンを実行することを望むエンタープライズ間に適切でありうる。また、ハブ／
ハブの関係は、２つのエンタープライズがそれぞれ別々にＲＨＹＴＨＭ−ＧＣＭ
を購入して、ハブ・エンジンをセットアップした場合にも適切でありうる。

【００４４】ハブ・エンジンとスポーク・エンジンの間には、いくつかの違いがある。一般
に、ハブ・エンジンの機能は、スポーク・エンジンの機能のスーパーセットであ
る。次の表に、いくつかの違いの例を示す。

【００４５】

【表１】

【００４６】セキュリティコラボレーションの別の問題は、広範囲なセキュリティを提供するという課題
である。エンタープライズが効率的に協同作業できる以前に、セキュリティの問
題に取り組む必要がある。協同作業環境では、セキュリティに対して数多くの異
なる側面が存在する。マルチエンタープライズ協同作業フレームワークは、これ
ら異なる側面のすべてに取り組むべきである。協同的なセキュリティフレームワ
ークに対する要件として、二者間で交換されるデータは二者のみが見るべきであ
る、二者間で交換されるデータは、不正操作がきかないようになっていなくては
ならない、エンタープライズは、パートナーが、エンタープライズの要求した本
人であることを確認できなくてはらない、フレームワークは相手ネットワークに
新しいセキュリティ・ホールを持ち込んではならない、フレームワークはセット
アップおよび管理が比較的簡単でなくてはならない、といったことを含むことが
できる。

【００４７】安全確実な協同作業フレームワークは、前述の要件に取り組む総合的なセキュ
リティ戦略を実施することによって実現できる。一実施形態において、この戦略
は、技術的セキュリティ、許可フレームワーク、およびデータ分割という３種類
の側面を有する。

【００４８】技術セキュリティは、セキュリティを保証するために使用される技術的手段の
ことである。このセキュリティは、プライバシー、認証、およびデータ保全性を
提供するために利用できる。プライバシーは、無許可の人間がデータを見ること
ができないようにするものである。認証は、コラボレーションの当事者が、本当
にコラボレーション当事者となることを要求した本人であるかどうかの認証を含
む。データ保全性は、無許可の人間が送信データをいずれかの方法で変更できな
いようにすることを含む。

【００４９】厳密なセキュリティ方法は、先に述べた関係タイプに基づいて変わることがで
きる。例えば１つの手法を次の表に詳述する。

【００５０】

【表２】

【００５１】表から分かるように、ハブ／ＶＡＮＥＤＩを除くすべての関係タイプは、Ｓ
ＳＬ３．０を通じてセキュリティを支援できる。

【００５２】ＳＳＬ３．０は、ソケットをベースにしている接続に対する公開鍵暗号をサ
ポートするために使用される業界基準プロトコルであり、プライバシー、サーバ
と同様のクライアント認証、データ保全性、および認可管理を提供する。ＳＳＬ
３．０は、ＲＳＡ法およびディッフィ−ヘルマン法を含むいくつかの公開鍵暗
号化アルゴリズムを組み込むことができる高レベルのプロトコルである。

【００５３】ＳＳＬ接続が完了すると、次の段階はユーザ名−パスワードの認証である。こ
れは、ＳＳＬ３．０自体が提供する認証を越える認証である。パスワードは、
ＰＫＣＳ５パスワードを使用した暗号化（ＲＳＡ標準）を使用して記憶できる。
ユーザまたはスポークの認証がなされると、アクセス・トークンに戻される。こ
のアクセス・トークンは、管理者が指定可能な存続時間を有する。ユーザは、ア
クセス・トークンの有効期限の時間内でシステムにアクセスできる。これは、ア
クセス毎の認証が必要でないという有益な効果がある。アクセスされる各アプリ
ケーションは、セキュリティ・マネージャの署名（セキュリティ・マネージャの
専用鍵を使って暗号化されたダイジェスト）を確認することによって、アクセス
・トークンを認証する。

【００５４】技術的セキュリティ・フレームワークは、セキュリティ機構の一部である。他
の部分は、コラボレーション自体の設計と一緒に行わなくてはならない。フレー
ムワークにより、エンタープライズは、他のエンタープライズが実行可能な種々
のアクティビティに対して簡単に許可を付与することができる。グローバル・コ
ラボレーション・ワークスペースは、階層内の種々のデータ要素に対して別個の
許可を付ける階層許可モデルをサポートできる。特に、ユーザ固有およびスポー
ク固有の読出、書込、取込、および登録許可をサポートできる。従って、エンタ
ープライズは、誰がどのデータを読み出すことができ、誰がどのデータを書き込
むことができ、誰がどのデータを取り込むことができ、誰がどのデータの書込通
知を登録できるか、を細かく調整することができる。

【００５５】コラボレーション・フレームワーク・セキュリティ戦略の第３の要素は、種々
のコラボレーション・ワークスペースにデータを分割する機能である。特に、協
同作業ワークスペースは、内部協同作業ワークスペースと外部協同作業ワークス
ペースに分割され、関係者が真に共有する必要があるデータだけが外部協同作業
ワークスペースにある。その他は、内部協同作業ワークスペースにある。外部協
同作業ワークスペースは、一連のファイアウォールの外側、あるいはエクストラ
ネットまたはＤＭＺの中に存在するように設計されている。コラボレーション・
フレームワークの設計に際し、（そうすることもできるが）一連のファイアウォ
ールを通じて外部協同作業ワークスペースをイントラネットに接続する必要がな
い。

【００５６】一実施形態において、グローバル・コラボレーションは、外部および内部協同
作業ワークスペースの両方を使用できる。局所コラボレーションは内部協同作業
ワークスペースしか使用しないので、相手エンタープライズからは全く見えない
。グローバル・コラボレーションの場合でさえ、関連部分が使用するのは外部コ
ラボレーション・ワークスペースである。また、前述の許可フレームワークのた
めに、それぞれの相手エンタープライズは、それ自身のデータしか見ること（書
込、読出、取込、登録）ができない。

【００５７】図８は、ハブ／スポークおよびハブ／ウェブの場合のセキュリティ構成の一実
施形態のブロック図である。図示されているように、ハブ・エンタープライズ５
０は、内部グローバル・コラボレーション・ワークスペース５２と外部グローバ
ル・コラボレーション・ワークスペース５４に連結され、これらと通信する。ス
ポーク・エンタープライズ５６とウェブ・エンタープライズ５８は、ウェブサー
バ６０を通じて、外部グローバル・コラボレーション・ワークスペース５４に接
続されている。ハブ・エンタープライズ５０と同様に、スポーク・エンタープラ
イズ５６は、内部グローバル・コラボレーション・ワークスペース６２を有する
。エンタープライズ５０、５６、および５８は、関連するファイアウォールによ
って保護でき、また、ウェブ・サーバ６０と外部グローバル・コラボレーション
・ワークスペース５４とによって形成されているエクストラネットは、フィルタ
リング・ルータとＨＴＴＰに適用されるＳＳＬ３．０を介した通信とによって
保護できる。

【００５８】図９は、ハブ／ハブの場合のセキュリティ構成の一実施形態のブロック図であ
る。図示されているように、ハブ・エンタープライズ６４とハブ・エンタープラ
イズ６６は、ＳＳＬ３．０保護ＴＣＰ／ＩＰの接続により通信できる。この通
信は、別々のグローバル・メッセージ・ブローカ６８と６９の間で可能である。
両方のハブ・エンタープライズ６４と６６は、図示されているように、ファイア
ウォールで保護されている。

【００５９】エンタープライズ間のワークフローマルチエンタープライズ意思決定支援の問題の１つは、閉ループのコラボレー
ションが無いことである。その代わり、データは、あるエンタープライズから次
のエンタープライズに、整合のとれたワークフローなしで送られる。閉ループ・
コラボレーションを実現するために、マルチエンタープライズのワークフローの
作成を支援する必要がある。当該グローバル・コラボレーション・マネージャお
よびグローバル・コラボレーション・デザイナにより、高度なマルチエンタープ
ライズ・ワークフローを構築、配備、監視、および変更することが可能になる。

【００６０】一般に、「ワークフロー」は、いくつかのタスクを一緒に実行するデータフロ
ーによってつなぎ合わされた「アクティビティ」セットでありうる。ワークフロ
ーは、一般に、ワークフロー・エンジン上で実行される。「分散型ワークフロー
」とは、複数のワークフロー・エンジン上で実行されるワークフローのことを言
う。言い換えると、ワークフローのいろいろな部分が、別々のエンジン上で実行
される、ということである。「ノード」は、分散型ワークフローの種々のワーク
フロー・エンジンが実行される抽象的なエンティティのことを言い、「ノード・
グループ」は、何らかの特徴毎に分類されたノード・セットでありうる。「マル
チエンタープライズ分散型ワークフロー」は、ノードがエンタープライズである
分散型ワークフローでありうる。

【００６１】ワークフローのパラメータ化は、エンタープライズ・コラボレーションにとっ
て重要でありうる。「パラメトリック・ワークフロー」は、何らかの変数につい
てパラメータ化されたワークフローであり、正規のもの、または分配されるもの
でありうる。種々の値のパラメータ変数を利用してパラメータ・ワークフローを
具体化することにより、ワークフローの種々の具体例ができる。「ノード・グル
ープ内のノードについてパラメータ化された分散型ワークフロー」とは、ワーク
フローのパラメータが、ノード・グループ内のノードである分散型ワークフロー
のことを言う。従って、ワークフローが具体化されるとき、ワークフローは、ノ
ード・グループ内の特定ノードに合わせて調整される。

【００６２】当該グローバル・コラボレーションによってサポートできる、ワークフローに
とって重要ないくつかの特性がある。これらのワークフローは強分類される（st
rongly typed）。強分類を行うことは、堅固で誤りのないワークフローを生成す
る上で不可欠でありうる。本質的に、強分類を行うことによってメッセージタイ
プは設計時に保証される。例えば、資材明細書を送信するようにワークフローを
設計する場合、強分類を行うことにより、資材明細書以外のオブジェクトの送信
が物理的に不可能になる。グローバル・コラボレーション・デザイナを利用して
設計され、グローバル・コラボレーション・マネージャによって実行されるワー
クフローの場合、正しくないタイプのオブジェクトを送ることを不可能にするこ
とさえも可能である。この機能は、堅固で誤りのないワークフローを作る上で重
要である。

【００６３】強分類にもかかわらず、例えば、不適切なオブジェクト・タイプがワークフロ
ーを通過できると考えられる２つの径路がある。ワークフローの設計者側の誤り
によるものと、ワークフローを傷つけようとする誰かの悪意のある試みによるも
のである。その両方の径路に対し、対処可能である。第１のものは、設計時の誤
りが、そのような径路を通過できないようにすることによって対処できる。第２
のものは、前述の公開鍵暗号化または他の暗号化方式（保全特性）を使用するこ
とにより、データフローに対する不正操作を防止することによって対処できる。

【００６４】別の重要特性は、グループについてパラメータ化されたワークフローのサポー
トである。マルチエンタープライズ・ワークフローの中には、多数のエンタープ
ライズを含んでいるものがある。そのような場合、パートナー毎に個別化したワ
ークフローを作成することは無理になる。そうではなく、パートナーのグループ
についてパラメータ化されるワークフローを作成することが有利である。例えば
、調達部門において、２つのグループが第１供給元と第２供給元であってもよい
。第１供給元グループは、あるタイプのワークフローを有し、第２供給元グルー
プは別のタイプのワークフローを有することができる。グループベースのワーク
フローは、実行時に、グループ・メンバー向けに実際のワークフローを作成でき
るという意味で、パラメトリックでありうる。

【００６５】マルチエンタープライズ環境では、エンタープライズは、例えば、潜在的に数
百または数千の他のエンタープライズと協同作業することもできる。それぞれの
コラボレーションまたはマルチエンタープライズ・ワークフローは、潜在的に（
そして、一般に）独自のものである。しかしながら、エンタープライズのパート
ナーとの数千の専用ワークフローを設計することは望ましくないし、実現可能で
もない。他方、これらのワークフローの多くは、基礎となるパラメータ化された
ワークフロー上ではパラメータ的変形例であるに過ぎない。例えば、企業Ａは、
小売業者、代理店、直売所等と（販売に関して）協同作業しているかもしれない
。従って、種々のパートナーをグループ化することは意味がある。グループ化の
例として、ウォールマート社（ＷａｌＭａｒｔ）；シアーズ社（Ｓｅａｒｓ）；
ウォールマート社とシアーズ社を除く他の小売業者（グループ）；第１代理店（
グループ）と第２代理店（グループ）にすることもできる。ここで、例えば、第
１代理店グループの全メンバーとのワークフローは、当該グループの特定代理店
についてパラメータ化された基礎パラメトリック分散型ワークフローを変化させ
たものである。

【００６６】グループについてパラメータ化されたワークフローは、ＨＥＴＥＲＯＣＡＳＴ
ＩＮＧワークフロー定義法によってサポートできる。ＨＥＴＥＲＯＣＡＳＴＩＮ
Ｇワークフロー定義法は一般に、パラメータの差に基づいて異種のワークフロー
を具体化するためにパラメータ化されたワークフロー定義を使用するものである
。このように、ＨＥＴＥＲＯＣＡＳＴＩＮＧ定義法により、非パラメータ的分散
型ワークフローを（ビジュアル・デザイン・ツールを通じて）ノード・グループ
内のノードに対して容易にパラメータ化することができる。この定義を実施する
ために、ＨＥＴＥＲＯＣＡＳＴ分割アクティビティとＨＥＴＥＲＯＣＡＳＴ結合
アクティビティという２つのワークフロー・アクティビティを使用できる。ＨＥ
ＴＥＲＯＣＡＳＴ分割とＨＥＴＥＲＯＣＡＳＴ結合の間のすべてのアクティビテ
ィは、これらのアクティビティに該当するノード・グループのノードについてパ
ラメータ化される。

【００６７】図１０は、複数のグループについてのパラメータ化を含むエンタープライズ間
ワークフロー設計の一実施形態の図である。図示されているように、ワークフロ
ーは、何らかの事象を待つ受信アクティビティ７０から開始できる。アクティビ
ティ７０は、並列アクティビティ７１に連結され、並列アクティビティ７１はサ
ブ・ワークフロー７２とヘテロキャスト分割７３と連結している。サブ・ワーク
フロー自体は、ワークフロー定義を含むことができる。ＨＥＴＥＲＯＣＡＳＴＩ
ＮＧについて述べると、ヘテロキャスト分割７３後のワークフローは、パラメー
タ化される。従って、図１０の例では、アクティビティ７４は、パラメ−タ化ア
クティビティである。アクティビティ７４の後、ヘテロキャスト結合７５は、ア
クティビティ７４からのフローを受け入れる。サブ・ワークフロー７２とヘテロ
キャスト結合７５は、同期または非同期結合７６に連結されており、同期または
非同期結合７６は、さらに統合イベント７７（例えば、マルチキャスティング）
に連結されている。図１０のようなワークフローは、当該グローバル・コラボレ
ーション・デザイナを使用して設計でき、各ワークフローがエンタープライズ間
意思決定支援できるようにする。ワークフローは、当該グローバル・コラボレー
ション・マネージャを通じて具体化および実行できる。

【００６８】図１１は、ワークフローの設計を修正する変更管理の一実施形態の図である。
図示されているように、最初のワークフローの設計は、並列アクティビティ分割
７１に連結されたイベント７０を有することができる。アクティビティ分割７１
とアクティビティ結合７６の間には、例えば、２つのアクティビティ７８があっ
てもよい。このワークフローは、設計後、グローバル・コラボレーション・マネ
ージャによって具体化および実行できる。ワークフローに対して変更を行う必要
がある場合、グローバル・コラボレーション・デザイナは、変更時のトラブルを
著しく軽減する。例えば、新規アクティビティ７９を分割７１と結合７６の間に
追加できる。その後、ワークフローを一元的に再具体化して実行することができ
る。

【００６９】特に、ＨＥＴＥＲＯＣＡＳＴ法により、ノード・グループのノードについてパ
ラメータ化した分散型ワークフローを構築できる。これにより、個々のグループ
・メンバーの個々のワークフローの設計に莫大な生産利得を与えることができる
。また、この手法により、数百または数千の可能なパートナーと共に、高度なエ
ンタープライズ間ワークフローの設計および試作が高速化される。この手法は、
全く同じメッセージを種々のノード（パートナー）に送出する従来の「マルチキ
ャスト」と区別されるべきである。本質的には、マルチキャストでは、複数のノ
ードに対して全く同じように実行される単一ワークフローが設計される。これは
、ワークフロー実行対象のノードに基づいてワークフローが違ったように実行さ
れるＨＥＴＥＲＯＣＡＳＴＩＮＧ法とは異なっている。

【００７０】第３の重要特性は、役割ベースのワークフローのサポートである。役割ベース
のワークフローにより、一般的な役割を利用してワークフローを指定できる。こ
の機能により、種々の筋書で具体化できる一般的な、すなわちテンプレート付き
のワークフローを作ることができる。例えば、役割タイプを、パートナー役、ス
ポーク役、スポーク・グループ役、ウェブ役、ウェブ・グループ役、ユーザ役に
してもよい。役割の例として、パートナー役とは、パートナーが果たす種々の役
割のことを言う。したがって、調達の場合のパートナーの役割の１つは、第１供
給元と第２供給元である。

【００７１】役割ベースのワークフローは、ワークフローの設計および実行に３段階の概念
をもたらすことができる。設計段階は、役割ベースのワークフローを規定する段
階である。具体化段階は、役割を具体例に割り当てる段階である。例えば、第１
供給元を第１の会社に割り当て、ＰＯ承認者をジョン・ドゥに割り当てることも
できる。第３の実行時段階は、具体化されたワークフローを実行する段階である
。

【００７２】更に別の重要な特徴は、自動化ワークフローとユーザ指向ワークフローとの統
合である。ワークフローは、自動化されたシステム間ワークフローとユーザ・イ
ンタフェース・ワークフローという２つの種類があると説明されることが多い。
完全に自動化されたワークフローも存在しているし、完全にユーザ駆動のワーク
フローも存在しているが、大部分のワークフローは、自動化要素とユーザ・イン
タフェース要素とを持っている。当該グローバル・コラボレーション・マネージ
ャおよびグローバル・コラボレーション・デザイナは、ワークフローのタイプに
このような人工的な区別をする必要がない。そのため、ワークフローは部分的に
自動化し、他の部分をユーザと相互作用させることができる。自動化部分とユー
ザ部分の両方とも、複数のエンタープライズをつなぐことができる。

【００７３】外界との統合図１２は、ワークフローと外界との統合の一実施形態の図である。既出部分に
記載されているように、高度なエンタープライズ間およびエンタープライズ内ワ
ークフローを作成できる。これらのワークフローは、種々の構成でつなぎ合わさ
れている複数のアクティビティから作ることができる。ワークフローの種々のア
クティビティが何を行うかについては何ら制限はないが、これらのアクティビテ
ィの主要タスクのうちの１つは、外界との統合である。図１２に、コンポーネン
トベースの統合法を利用して、どのようにワークフローと外界とを統合させるこ
とができるかを示す。コンポーネントは、アクセッサ８０、トランスフォーマ８
２、転送オブジェクト８４、アダプタおよびフロー８６を含むことができる。

【００７４】グローバル・コラボレーション・マネージャは、コンポーネント・ベースの統
合モデルをサポートできる。コンポーネント・ベースの統合モデルを採用するこ
とにより、統合を行う際に柔軟性がもたらされる。コンポーネントには、単純コ
ンポーネント（ｐｒｉｍｉｔｉｖｅｃｏｍｐｏｎｅｎｔ）と複合コンポーネン
ト（ｃｏｍｐｏｕｎｄｃｏｍｐｏｎｅｎｔ）の２タイプがある。単純コンポー
ネントとして、アクセッサ８０、トランスフォーマ８２、および転送オブジェク
ト８４などがある。複合コンポーネントは、アダプタおよびフロー８６などであ
る。複合コンポーネントは、単純コンポーネントで構築されている。この手法で
は、アクセッサ８０は、ＳＣＰ（サプライチェーン・プランナ）、ＳＡＰ、リレ
ーショナル・データベース、ウェブ・サーバ、ｅメール、メッセージ・バスなど
の外部ソースにアクセスするために使用される。アクセッサ８０は、データソー
スおよびデータ宛先と読出、書込、または通信を行うために使用できる。トラン
スフォーマ８２は、データをある形態から別の形態に変換するために使用できる
。転送オブジェクト８４は、アクティビティ間またはエンタープライズ間で受け
渡し可能なオブジェクトである。転送オブジェクト８４は、必要に応じてＥＤＩ
、ＸＭＬ、ＣＯＲＢＡ構造等に変換できるものでもよい。アクセッサ８０とトラ
ンスフォーマ８２は、一緒に連なってフローを形成できる。図１３に示されてい
るように、フロー全体を１回のアクティビティで実行できる。

【００７５】図１３は、１回のアクティビティ９２で実行されるデータフローの一実施形態
の図である。図示されているように、データソース９０は、アクセッサ・コンポ
ーネント９４からアクセス可能であり、また、アクセッサ・コンポーネント９４
にデータを供給できる。また、アクセッサ・コンポーネント９４は、第２のアク
セッサ・コンポーネント１００にデータを供給するトランスフォーマ・コンポー
ネント９６と９８を通じてデータを受け渡すことができる。その後、データはデ
ータ宛先１０２に記憶される。

【００７６】図１４は、複数のアクティビティ１０４と１０６に関して分割されたデータフ
ローの一実施形態の図である。図示されているように、図１４のフローは、トラ
ンスフォーマ・コンポーネント９６と９８が、別々のアクティビティ１０４と１
０６の中にあり、転送オブジェクトによって連絡されている点が図１３のものと
異なっている。マルチエンタープライズのデータフローは、図１３でなく図１４
のモデルを基礎とすることができる。

【００７７】変換について述べると、一実施形態において、Ｉ２ＣＤＭを使用した変換と
直接変換との２種類の基本変換タイプがサポートされる。Ｉ２ＣＤＭを使用し
た変換は、アイ・ツー・テクノロジー社のＣＯＭＭＯＮＤＡＴＡＭＯＤＥＬ
（ＣＤＭ）に基づくものである。ＣＤＭは、リレーショナル形にもオブジェクト
形にも利用可能な抽象スキーマである。

【００７８】図１５は、Ｉ２−ＣＤＭをベースにした変換モデルの一実施形態のブロック図
である。図示されているように、トランスフォーマとアクセッサを結合して、ア
プリケーション・データをＣＤＭデータ・オブジェクト１１０に変換したり、そ
の逆を行ったりすることができる。例えば、ＳＣＰアクセッサによってＳＣＰデ
ータ１１４からＳＵＰＰＬＹＣＨＡＩＮＰＬＡＮＮＥＲ（ＳＣＰ）オブジ
ェクト１１２を作成できる。その後、ＳＣＰオブジェクト１１２は、ＳＣＰ−Ｃ
ＤＭトランスフォーマによってＣＤＭオブジェクト１１０に変換できる。同様に
、ＳＡＰアクセッサによってＳＡＰデータ１１８からＳＡＰオブジェクト１１６
を作成できる。その後、ＳＡＰオブジェクト１１６は、ＳＡＰ−ＣＤＭトランス
フォーマによってＣＤＭオブジェクト１１０に変換できる。他のアクセッサおよ
びトランスフォーマでそうであるように、ＳＡＰアクセッサおよびトランスフォ
ーマを組み合わせて、ＣＤＭベースの変換に利用できる標準的なＳＡＰ−ＣＤＭ
アダプタ１２０にすることができる。別の例として、ＢＡＡＮアクセッサによっ
て、ＢＡＡＮデータ１２４からＢＡＡＮオブジェクト１２２を作成できる。その
後、ＢＡＡＮオブジェクト１２２は、ＢＡＡＮ−ＣＤＭトランスフォーマによっ
てＣＤＭオブジェクト１１０に変換できる。これらの変換は別の方向にも働く。

【００７９】図１６は、直接変換の一実施形態の図である。直接トランスフォーマの場合、
オブジェクトは、中間形式を通らずに一つの形態から別の形態に変換される。例
えば、図１６に示されているように、ＳＵＰＰＬＹＣＨＡＩＮＰＬＡＮＮＥ
Ｒ（ＳＣＰ）アクセッサがＳＣＰデータ１３０にアクセスしてＳＣＰオブジェ
クト１３２が作成される。ＳＣＰオブジェクト１３２は、ＦＡＣＴＯＲＹＰＬ
ＡＮＮＥＲ（ＦＰ）オブジェクト１３４に直接に変換される。ＦＰオブジェク
ト１３４は、その後、ＦＰアクセッサを通じてＦＰデータ１３６となりうる。こ
のデータフローは、別の方向にも作用しうる。

【００８０】これらのプロセスには、アクセスおよび変換可能な、リレーショナル・レベル
（テーブル）、汎用オブジェクト・レベル（ツリー、グラフ、マトリックス等）
および特定オブジェクト・レベル（資材明細書、プラン等）などの細分化された
種々のレベルが存在している。アクセス権は１つのレベル（例えば、テーブル）
でしか得られないが、別のレベル（例えば、汎用オブジェクト）での変換が適し
ていることもある。例えば、階層集約（変換の形態）は、しばしばツリー・オブ
ジェクトに適している。しかしながら、表の形でしかデータにアクセスできない
こともある。この場合、例えば、データにテーブル・レベルでアクセスし、ツリ
ーに変換し、そしてそれに階層集約を適用しなくてはならない。

【００８１】図１７は、異なるアクセスおよび変換レベルの一実施形態の図である。図示さ
れているように、アクセスおよび変換は３つのレベルを持つことができる。第１
のレベル１４０は、表のアクセスおよび変換を含むことができる。第２のレベル
１４２は、汎用オブジェクト（ツリー、グラフ等）のアクセスと変換を含むこと
ができ、第３のレベルは、特定オブジェクト（資材明細書、プラン等）のアクセ
スと変換を含むことができる。アプリケーション形式間の変換の他に、図示され
ているように３レベル間の変換があってもよい。

【００８２】コラボレーションの配備マルチエンタープライズ・コラボレーション・システムの重要要素の１つは、
コラボレーション配備の容易さである。前述のように、当該グローバル・コラボ
レーション・マネージャは、ハブ／ウェブ、ハブ／スポーク、ハブ／ハブ、およ
びハブ／ＶＡＮ−ＥＤＩという４種類のパートナー関係をサポートできる。これ
らの４種類のうち、ハブ／ウェブは、従来のウェブ・アプリケーションのあらゆ
る配備特性を有する。ハブ／ＶＡＮ−ＥＤＩは、既存のＶＡＮ−ＥＤＩインフラ
ストラクチャに影響を及ぼす範囲まで配備可能である。ハブ／ウェブ関係は高度
に配備可能であるが、関係のウェブ側に人間を要するという問題がある。すなわ
ち、これは、システム間コラボレーションには適合しない可能性がある。

【００８３】ハブ／スポーク・ソリューションは、システム間コラボレーション環境に最大
の配備可能性を与えることができる。ハブ／スポーク領域において、スポーク・
エンジンはウェブ・ブラウザと類似し、コラボレーションのスポーク部はウェブ
・ページまたはアプレットと類似している。ウェブ・ページまたはアプレットと
同様に、コラボレーションのスポーク部は、集中的に設計されて遠隔スポーク・
エンジンに配備される。ウェブ・ページまたはアプレットと異なり、遠隔から実
行する必要のある統合業務が依然として存在している。この遠隔統合は不可避で
あるが、コラボレーションのスポーク部によって制限し正確に規定できる。

【００８４】配備可能性の別の側面は、バージョン管理処理である。設計および配備された
コラボレーションは、時間の経過に伴って（種々の方法で）変更が必要になるこ
とが多い。初期バージョンのように、コラボレーションの後続バージョンを簡単
に配備できることが重要である。当該グローバル・コラボレーション・マネージ
ャは、コラボレーションのバージョン管理と集中再配備とを完全にサポートでき
る。また、コラボレーションの種々のバージョンは、互いに影響を及ぼすことな
く同時に実行可能である。これにより、既存バージョンを段階的に体好く廃止し
ながら、別のバージョンを段階的に導入していくことができる。

【００８５】当該グローバル・コラボレーション・マネージャの配備特性の別の要素は、既
存のインフラストラクチャの強化である。この要素は、例えば、既存のウェブ・
プロトコルに基づいたハブ／スポーク関係のサポートで明らかである。既存のウ
ェブ・プロトコルに基づいてハブ／スポークをサポートすることは、既存のウェ
ブ・インフラストラクチャの変更または再構成が必要ないため、高速配備にとっ
て重要である。これに関する大幅な時間の節約は、既に所定の場所にあるかも知
れない、注意深く設計されたファイアウォールおよびセキュリティ・インフラス
トラクチャを修正する必要が無くなることに起因する。

【００８６】多コラボレーション対多コラボレーションのサポート本発明のハブ／スポークアーキテクチャは、扱いやすさと配備しやすさを提供
するものである。しかしながら、実際には、エンタープライズは、更に別のエン
タープライズと協同作業を行う数多くのエンタープライズと協同作業する。従っ
て、エンタープライズはしばしば協同作業ウェブまたはグラフを形成する。これ
は、スポーク・エンジンの代わりにハブ・エンジンを随時使用する機能を介して
サポートできる。この代用機能により、多コラボレーション対多コラボレーショ
ン・ウェブは、一度にではなく有機的に成長することができる。

【００８７】図１８は、コラボレーション内のスポーク・エンジンの代わりにハブ・エンジ
ンを使っている一実施形態の図である。図示されているように、エンタープライ
ズ（ＥＩ）は、それ自体にハブ・エンジン１５０を配備し、そのパートナー・サ
イトの全部にスポーク・エンジン１５２を配備することもできる。特に、スポー
ク・エンジン１５４は、パートナー側（Ｅ２）にあってもよい。パートナー側（
Ｅ２）が、自己のコラボレーションの設計および制御を希望する場合、スポーク
・エンジン１５４とハブ・エンジン１５６を交換できる。Ｅ１から見ると、Ｅ２
は、依然としてＥ１のコラボレーション内のスポークでありうる。しかしながら
、今やこのスポークは、スポーク・エンジン１５８によりそれ自体のコラボレー
ションを制御できるハブ・エンジン１５６上で動作している。また、スポーク・
エンジン１６０と１６２は、Ｅ３に代わってハブ・エンジン１５０およびハブ・
エンジン１５６の両方と対話する第３のエンティティ（Ｅ３）と対応付けること
もできる。

【００８８】フレームワークの拡張本願のフレームワークの重要側面は拡張性である。拡張性無くしては、フレー
ムワークは直面する新しい状況や課題を処理しえない。この拡張性に対して、い
くつかの異なる次元がある。例えば、拡張性の主領域の１つは、意味オブジェク
ト基準の領域にある。サポートしている基準が、特定の問題に対して不十分な場
合、フレームワークに新しい意味基準を増補できる。更に、フレームワークは独
自の意味基準を構築できる。また、フレームワークは、新しいアクセッサ、トラ
ンスフォーマ、アダプタ等によって拡張できる。基準コンポーネント・ライブラ
リは、習慣的に拡張することも、エンド・ユーザが拡張することも可能である。

【００８９】コラボレーション管理本発明によれば、エンタープライズ内又は間におけるコラボレーションを管理
する。概略をいえば、本件発明は、ワークフローや、１又は２以上のエンタープ
ライズのノード間に分配されるコラボレーションやワークフローを管理するため
のコンピュータ実行プロセスを提供するものである。コンピュータで実行される
プロセスは、分配された各ノードでコラボレーションを実行するための、１組の
予め定義された機能を保存することによって、コラボレーションを管理する。コ
ンピュータ実行プロセスは、自動的に、各々のノードにおいて、コラボレーショ
ンに対して作用して、予め定義された機能を実行させる。ここで、「各々」とは、
特定されたアイテムの少なくとも１つのサブセットの各々を指す。他のシステム
・コラボレーションに関して、又は複数のノードに亙ってコラボレーションを管
理することができる他の適当なプロセスに関して前述したように、コンピュータ
実行プロセスは、グローバル・コラボレーション・デザイナ及びグローバル・コ
ラボレーション・マネージャによって生成され加工される高次のコラボレーショ
ンであっても良い。予め定義された機能は、コラボレーションを生成し、展開し
、モニタし、若しくは相互作用するものであっても良い。

【００９０】図１９は、本発明の実施形態の１つを示しており、複数のエンタープライズ間
のコラボレーションの生成を行うための、フローチャートを示している。図１９
について言えば、コラボレーションを生成する方法は、ステップ１６０で始まり
、そのステップでは最初のエンタープライズから予備的なコラボレーションを受
け取る。そのコラボレーションが予備的であるのは、そのコラボレーションに含
まれる他のエンタープライズによって、コメントされ又は変更される可能性があ
るからである。予備的なコラボレーションは、最初のエンタープライズによって
、生成され、または提供される。

【００９１】ステップ１６２に進むと、予備的なコラボレーションは、自動的に、コラボレ
ーションに含まれる第二のエンタープライズに伝達される。予備的なコラボレー
ションは、第２のエンタープライズの、ハブ、スポーク、又は他の適当なノード
に伝達することができる。ここで、イベントが「自動的」であるのは、イベントが
コンピュータプロセスによって事前に定義され実行されるからである。そのイベ
ントは、ユーザの動作や他の適当なイベントに続いてすぐに、又はそれに応じて
、行われても良い。

【００９２】ステップ１６４では、予備的なコラボレーションに対する応答は、第２のエン
タープライズによって受け取られる。その応答は、予備的なコラボレーションに
対するコメントや、予備的なコラボレーションの修正など、であっても良い。予
備的なコラボレーションの変更は、予備的なコラボレーションの修正又は追加で
あっても良い。許容できる応答のタイプは、第２のエンタープライズによって承
認された特権によって制御されるものであっても良い。

【００９３】次に、ステップ１６６において、応答が、自動的に最初のエンタープライズに
伝達され、プロセスが終了する。予備的なコラボレーションが第２のエンタープ
ライズに伝達され、応答が第２のエンタープライズから伝達されたのと同様にし
て、予備的なコラボレーションは、他のエンタープライズの幾つにでも伝達され
て良く、応答を、それらのエンタープライズから受け取っても良い。異なるエン
タープライズは、予備的なコラボレーションを修正し、又は単にコメントする異
なる特権を承認されても良い。含まれている全ての又は多数のエンタープライズ
によるレビューと応答は、含まれているエンタープライズによって注意深く考慮
され、最適化された最終のコラボレーションにつながる。

【００９４】コラボレーションの設計の中に複数のエンタープライズを含めることに加えて
、設計のプロセスを複数のステージに細分化しても良い。例えば、第１のステー
ジにおいて、選ばれた数のエンタープライズだけについて、予備的なコラボレー
ションの変更を許可しても良い。これらのエンタープライズが、予備的なコラボ
レーション及びそれに対する変更に基づくコラボレーションに同意した後に、そ
の結果のコラボレーションを、コメントや他の制限された応答のために、他のエ
ンタープライズに伝達しても良い。

【００９５】他の実施形態では、コラボレーションの設計は、一般的ステージと特殊ステー
ジに分けても良い。この実施形態では、予備的なコラボレーションは、エンター
プライズ間のコラボレーションのアウトラインである。含まれているエンタープ
ライズの間でコラボレーションのアウトラインが同意されると、コラボレーショ
ンの特殊なディテールが、エンタープライズ間に、伝達され、応答の対象となる
。このようにして、１又は２以上のエンタープライズの分配されたノード内で又
は間で、コラボレーションが効率的に生成される。

【００９６】図２０は、本発明の実施形態の１つを示しており、最初のエンタープライズに
よって生成されたコラボレーションを他の複数のエンタープライズに展開するた
めの、フロー図である。図２０について説明すると、その方法はステップ１７０
において始まり、そこで、コラボレーションが最初のエンタープライズによって
生成される。次に、ステップ１７２において、予め定義されたコラボレーション
の最初の部分が、自動的に第２のエンタープライズに転送され、オペレートされ
る。コラボレーションの最初の部分は、第２のエンタープライズのスポークや他
の適当なノードに伝達される。

【００９７】ステップ１７４に進むと、予め定義されたコラボレーションの第２の部分が、
自動的に第３のエンタープライズに伝達され、オペレートされる。コラボレーシ
ョンの第２の部分は、第３のエンタープライズのスポークや他の適当なノードに
伝達される。同様にして、コラボレーションの他の部分は、自動的に他のエンタ
ープライズに伝達され、オペレートされる。このようにして、コラボレーション
は、ユーザとの関りを最小限に抑えながら、エンタープライズ内又は間に展開さ
れる。

【００９８】ある実施形態では、コラボレーションは、展開されても、そのコラボレーショ
ンを全ての又は十分な数のエンタープライズが承認するまでの間は、どのエンタ
ープライズによっても実行されない。この実施形態では、プロセスは、個々に、
そこに含まれるエンタープライズからの承認を要請し、受領しても良い。このよ
うにして、コラボレーションが、１つ又はほんの数個のコラボレーションのため
だけに早まって実行されることがなくなり、古いバージョンのコラボレーション
のオペレートが、早まって中断されることもなくなる。

【００９９】図２１は、本発明の実施形態の１つとして、複数のエンタープライズにまたが
ってコラボレーションを管理する方法を示している。図２１について説明すると
、その方法はステップ１８０から始まり、第１のノードに対して、第１のノード
におけるコラボレーションのオペレートに関連したデータについての質問が発せ
られる。質問は、エージェントによって、又は他の適当な機構によって発せられ
ることができる。好ましくは、エージェントは、第１のノードにおいて、ネット
ワーク・リソースの使用を最小限にするように、操作を行う。

【０１００】ステップ１８２に進んで、第１のノードからのデータは、自動的に管理システ
ムに伝達される。データの伝達は、周期的であっても良く、又は予め定義された
イベントに対する応答であっても良い。管理システムは、ハブ、スポーク、又は
システムの他の適当なノードにおくことができる。

【０１０１】ステップ１８４において、第２のノードに対して、第２のノードにおけるコラ
ボレーションのオペレータに関連したデータについての質問が発せられる。第１
のノードについて説明したように、質問は、ローカル・エージェントによって発
せられても良い。ステップ１８６において、第２のノードからのデータが、自動
的に管理システムに伝達される。付加的なノードにおけるコラボレーションの操
作は、同様に管理することができる。このようにして、多数のエンタープライズ
にまたがった、コラボレーションの操作は、ハブ、即ち中央のロケーションによ
って管理され又は追跡され、又は含まれるエンタープライズに個別に管理される
。

【０１０２】以上、本発明を詳細に説明したが、添付の請求項に記載の本発明の精神および
範囲から逸脱せずに本発明に対して種々の変更、置換、および修正を行えること
を理解されたい。

【図面の簡単な説明】

【図１】エンタープライズ・コラボレーションをサポートできるコンピュ
ータ実行アーキテクチャの一実施形態の図である。

【図２】グローバル・コラボレーション・フレームワークの構成要素の一
実施形態の図である。

【図３】特定のモジュールを構成するあるソフトウェア要素を強調表示さ
せた、図２のグローバル・コラボレーション・フレームワークの図である。

【図４】最適な意思決定を行うためにエンタープライズ内またはエンター
プライズ間のコラボレーションを可能にするシステムの一実施形態のブロック図
である。

【図５】グローバル・コラボレーション・ワークスペースの使用法の一実
施形態のブロック図である。

【図６】コラボレーションのライフサイクルの一実施形態の図である。

【図７Ａ】共通ソフトがリレーションシップの両側に存在している状況の
図である。

【図７Ｂ】共通ソフトがリレーションシップの両側に存在していない状況
の図である。

【図８】ハブ／スポークおよびハブ／ウェブの場合のセキュリティ構成の
一実施形態のブロック図である。

【図９】ハブ／ハブの場合のセキュリティ構成の一実施形態のブロック図
である。

【図１０】複数のグループに対するパラメータ化を含むエンタープライズ
間ワークフロー設計の一実施形態の図である。

【図１１】ワークフローの設計を修正する変更管理の一実施形態の図であ
る。

【図１２】ワークフローと外界との統合の一実施形態の図である。

【図１３】１回のアクティビティで実行されるデータフローの一実施形態
の図である。

【図１４】複数のアクティビティに関して分割されたデータフローの一実
施形態の図である。

【図１５】ＣＯＭＭＯＮＤＡＴＡＭＯＤＥＬをベースにした変換モデ
ルの一実施形態のブロック図である。

【図１６】直接変換の一実施形態の図である。

【図１７】異なるアクセスおよび変換レベルの一実施形態の図である。

【図１８】コラボレーション内のスポーク・エンジンの代わりにハブ・エ
ンジンを使用した一実施形態の図である。

【図１９】本発明の実施形態の１つとして、複数のエンタープライズの間
でコラボレーションを生成するためのコンピュータ実行プログラムを示すフロー
図である。

【図２０】本発明の実施形態の１つとして、複数のエンタープライズにコ
ラボレーションを展開するためのコンピュータ実行プログラムを示すフロー図で
ある。

【図２１】本発明の実施形態の１つとして、複数のエンタープライズにま
たがって、コラボレーションを管理するためのコンピュータ実行プログラムを示
すフロー図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者マーク・ビー・ホイップルアメリカ合衆国75208テキサス州ダラス、ノース・クリントン・アベニュー110番

Claims

【特許請求の範囲】

【請求項１】分配された複数のノードにおいて実行される、ワーク・フロ
ーのための予め定義された１組の機能を記憶するステップと、分配されたノードの各々において、ワーク・フローに自動的に働きかけて、前
記予め定義された機能を実行するステップとを備えることを特徴とする、分配されたワーク・フローを管理するためのコンピュータによって実行される
方法。
【請求項２】前記１組の予め定義された機能が、複数のエンタープライズ
の間にワークフローを生成させるように動作可能であることを特徴とする請求項
１記載の方法。
【請求項３】前記１組の予め定義された機能が、前記分配されたノードの
各々の操作に関連したデータを管理システムに伝達するように動作可能であるこ
とを特徴とする請求項１記載の方法。
【請求項４】前記１組の予め定義された機能が、前記分配されたノードに
前記ワーク・フローを展開するように動作可能であることを特徴とする請求項１
記載の方法。
【請求項５】第１のエンタープライズから予備的なコラボレーションを受
け取るステップと、前記予備的なコラボレーションを、予め定義された第２のエンタープライズに
、検査のために自動伝達するステップと、前記第２のコラボレーションから、前記予備的なコラボレーションに対する応
答を受け取るステップと、前記応答を、前記第１のエンタープライズに、検査のために自動伝達するステ
ップを備えることを特徴とする、複数のエンタープライズ間にコラボレーションを生成するためのコンピュータ
によって実行の方法。
【請求項６】前記応答が、前記予備的なコラボレーションに対するコメン
トであることを特徴とする請求項５記載の方法。
【請求項７】前記応答が、前記予備的なコラボレーションの変更であるこ
とを特徴とする請求項５記載の方法。
【請求項８】前記変更が、前記予備的なコラボレーションに対する追加で
あることを特徴とする請求項７記載の方法。
【請求項９】前記変更が、前記予備的なコラボレーションの修正であるこ
とを特徴とする請求項７記載の方法。
【請求項１０】前記予備的なコラボレーションと応答に基づくコラボレー
ションについての承認を、前記第１及び第２のエンタープライズから受け取るス
テップと、前記コラボレーションを、予め定義された第３のエンタープライズに、検査の
ために自動伝達するステップと、前記第３のエンタープライズから、前記コラボレーションに対する応答を受け
取るステップと、前記応答を、第１のエンタープライズに、検査のために自動伝達するステップ
とを備えることを特徴とする請求項５記載の方法。
【請求項１１】前記応答が、コメントであることを特徴とする請求項１０
記載の方法。
【請求項１２】前記応答が、前記コラボレーションの変更であることを特
徴とする請求項１０記載の方法。
【請求項１３】前記変更が、コラボレーションに対する追加であることを
特徴とする請求項１２記載の方法。
【請求項１４】前記変更が、前記コラボレーションの修正であることを特
徴とする請求項１２記載の方法。
【請求項１５】コラボレーションを受け取るステップと、予め定義された第２のエンタープライズに、前記コラボレーションの予め定義
された第１の部分を、自動伝達するステップと、予め定義された第３のエンタープライズに、前記コラボレーションの予め定義
された第２の部分を自動伝達するステップとを備えたことを特徴とする、複数の他のエンタープライズに、第１のエンタープライズによって生成された
コラボレーションを分配するための、コンピュータによって実行する方法。
【請求項１６】前記第２のエンタープライズのノードにおいて、前記コラ
ボレーションの第１の部分をオペレートするための前記第２のエンタープライズ
による承認を要請するステップと、前記第３のエンタープライズのノードにおいて、前記コラボレーションの第２
の部分をオペレートするための、第３のエンタープライズによる承認を要請する
ステップとを、さらに備えたことを特徴とする請求項１５記載の方法。
【請求項１７】前記第２のエンタープライズからの承認の受領に応答して
、その承認を前記第３のエンタープライズに通知することを特徴とする請求項１
６記載の方法。
【請求項１８】前記第２及び第３のエンタープライズからの承認の受領に
応答して、前記第２及び第３のコラボレーションに信号を伝達して前記コラボレ
ーションをオペレートさせることを特徴とする請求項１６記載の方法。
【請求項１９】前記コラボレーションが伝達された全てのエンタープライ
ズからの前記コラボレーションをオペレートするための承認の受領に応答して、
前記全てのエンタープライズに信号を伝達して前記コラボレーションをオペレー
トさせることを特徴とする請求項１６記載の方法。
【請求項２０】第１のエンタープライズの第１のノードに、第１のノード
におけるコラボレーションのオペレートに関連した、第１の予め定義された１組
のデータについて自動的に質問するステップと、前記第１の１組のデータを管理システムに伝達するステップと、第２のエンタープライズの第２のノードに、第２のノードにおけるコラボレー
ションのオペレートに関連した、第２の予め定義された１組のデータについて自
動的に質問するステップと、前記第２の１組のデータを管理システムに伝達するステップを備えたことを特
徴とする、複数のエンタープライズに渡るコラボレーションを管理するための、コンピュ
ータにより実行する方法。