JP2007524929A - エンタープライズコラボレーションシステム及び方法 - Google Patents

Abstract

複数の関係者（クライアント「Ａ」、「Ｂ」及び「Ｃ」）の間のコラボレーションシステム及び方法において、コラボレーションプロセス（プロセス「２」）にコンタクトし、このコンタクトを第１関係者（クライアント「Ｂ」）により行い、１人以上の潜在的な関係者をロールに基づいて適任とし、前記１人以上の潜在的な関係者から第２関係者（クライアント「Ｃ」）を選択し、前記第２関係者をコラボレーションに参加するように招待し、そして前記第２関係者が前記コラボレーションに参加できるかどうかの指示を受け取るシステム及び方法。この要約は、本発明の完全な説明を意図しておらず、又、本発明の範囲を限定するものでもない。本発明の他の特徴、態様及び目的は、明細書、添付図面及び特許請求の範囲を検討することで明らかとなろう。
【選択図】図５

Description

本発明は、一般に、コンピュータネットワークを経て動的なユーザコラボレーションをサポートするシステム及び方法に係る。

優先権の主張：
２００４年５月２０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR ENTERPRISE COLLABORATION」と題する米国仮特許出願第６０／５７３，１８９号（代理人ドケットＮｏ．ＢＥＡＳ−０１６４６ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR ENTERPRISE COLLABORATION」と題する米国特許出願第１１／０５５，０３８号（代理人ドケットＮｏ．ＢＥＡＳ−０１６４６ＵＳ１）；
２００４年５月２０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION SERVER」と題する米国仮特許出願第６０／５７３，１９０号（代理人ドケットＮｏ．ＢＥＡＳ−０１６４７ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION SERVER」と題する米国特許出願第１１／０５５，３２８号（代理人ドケットＮｏ．ＢＥＡＳ−０１６４７ＵＳ１）；
２００４年５月２０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION CLIENT」と題する米国仮特許出願第６０／５７２，９４２号（代理人ドケットＮｏ．ＢＥＡＳ−０１６４８ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION CLIENT」と題する米国特許出願第１１／０５４，９２９号（代理人ドケットＮｏ．ＢＥＡＳ−０１６４８ＵＳ１）；
２００４年５月２０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION PRESENCE FRAMEWORK」と題する米国仮特許出願第６０／５７２，９４１号（代理人ドケットＮｏ．ＢＥＡＳ−０１６４９ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION PRESENCE FRAMEWORK」と題する米国特許出願第１１／０５４，９８２号（代理人ドケットＮｏ．ＢＥＡＳ−０１６４９ＵＳ１）；
２００４年５月２０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION MESSAGING FRAMEWORK」と題する米国仮特許出願第６０／５７２，８３９号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５０ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION MESSAGING FRAMEWORK」と題する米国特許出願第１１／０５５，４３０号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５０ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR DYNAMIC CONFIGURATION OF A COLLABORATION」と題する米国仮特許出願第６０／５７３，３６６号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５１ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR DYNAMIC CONFIGURATION OF A COLLABORATION」と題する米国特許出願第１１／０５５，３２０号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５１ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION SHARED STATE MANAGEMENT」と題する米国仮特許出願第６０／５７４，０１０号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５２ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION SHARED STATE MANAGEMENT」と題する米国特許出願第１１／０５５，０４８号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５２ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION DYNAMIC PAGEFLOWS」と題する米国仮特許出願第６０／５７３，１１４号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５３ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION DYNAMIC PAGEFLOWS」と題する米国特許出願第１１／０５４，７８７号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５３ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATIVE CALL CENTER」と題する米国仮特許出願第６０／５７３，４８４号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５４ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATIVE CALL CENTER」と題する米国特許出願第１１／０５５，４３６号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５４ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATIVE GROUP CHAT」と題する米国仮特許出願第６０／５７３，４８５号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５５ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATIVE GROUP CHAT」と題する米国特許出願第１１／０５５，１３５号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５５ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR AN EMBEDDED COLLABORATION CLIENT」と題する米国仮特許出願第６０／５７３，４８６号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５６ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR AN EMBEDDED COLLABORATION CLIENT」と題する米国特許出願第１１／０５４，８６１号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５６ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION IMPERSONATION」と題する米国仮特許出願第６０／５７４，８６５号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５７ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION IMPERSONATION」と題する米国特許出願第１１／０５５，３２７号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５７ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION INTERCEPTORS」と題する米国仮特許出願第６０／５７３，３６５号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５８ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATION INTERCEPTORS」と題する米国特許出願第１１／０５５，２９０号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５８ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATIVE CO-NAVIGATION」と題する米国仮特許出願第６０／５７３，１４０号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５９ＵＳ０）；
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATIVE CO-NAVIGATION」と題する米国特許出願第１１／０５５，２６９号（代理人ドケットＮｏ．ＢＥＡＳ−０１６５９ＵＳ１）；
２００４年５月２１日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATIVE CONTENT STORAGE」と題する米国仮特許出願第６０／５７３，３１０号（代理人ドケットＮｏ．ＢＥＡＳ−０１６６０ＵＳ０）；及び
２００５年２月１０日に出願されたブロディ・ビュータスク氏等の「SYSTEMS AND METHODS FOR COLLABORATIVE CONTENT STORAGE」と題する米国特許出願第１１／０５５，０４７号（代理人ドケットＮｏ．ＢＥＡＳ−０１６６０ＵＳ１）。

ウェブページは、会社の商品及びサービスへの容易な直感的アクセスを与えることができる。ウェブページの価値は、バックエンドビジネスプロセス及びビジネス対ビジネス統合の複雑さのほとんどをエンドユーザから隠す能力にある。しかしながら、ウェブページは、エンドユーザがこれらビジネスプロセスの状況において互いにコラボレートするのを許す上ではあまり良好ではない。インスタントメッセージングは、ウェブベースのコラボレーションアプリケーションの簡単な例である。しかしながら、インスタントメッセージングは、ユーザがコラボレーション形態でビジネスプロセスと対話できるようにするのではなく、ユーザが互いに対話することしか許さないという点で限界がある。

同様の要素が同じ参照番号で示された添付図面を参照して本発明の態様を一例として説明するが、本発明は、これに限定されない。この開示において、「ある」、「１つの」、「種々の」及び「更なる」実施形態という言い方は、必ずしも同じ実施形態ではなく、少なくとも１つを意味することに注意されたい。以下の説明では、本発明を完全に説明するために、多数の特定の細部を説明する。しかしながら、これらの特定の細部を伴わずに本発明を実施できることが当業者に明らかであろう。他の例では、本発明を不明瞭にしないために、良く知られた特徴は、詳細に述べないことにする。

種々の実施形態において、ビジネスプロセスの状況でユーザ間にコラボレーションを与えるシステム及び方法を説明する。これら実施形態の態様において、コラボレーションプロセスは、統合ソフトウェア開発環境（ＩＤＥ）において開発することもできるし、又は他の適当な手段を使用することにより開発することもできる。ＩＤＥの一例は、カリフォルニア州サンノセのＢＥＡシステムズ・インクから入手できるＷｅｂＬｏｇｉｃ（登録商標）ワークショップである。コラボレーションプロセスは、１つ以上のプログラミング言語で書くことができ、マルチスレッドとすることができ、分離されたプロセスへと細分化でき、及び／又は１つ以上のコンピューティング装置／プロセッサ間に分布させることができる。コラボレーションプロセスは、アプリケーションサーバーにおいてスタンドアローンプログラムとして、及び／又は１つ以上のネットワークを通してアクセスできるリソース（例えば、オブジェクト）として展開することができる。最後に、コラボレーションプロセスは、ソフトウェア、ハードウェア、又はハードウェアコンポーネント（１つ又は複数）及びソフトウェアの組み合せとして実施することができる。

図１は、本発明の種々の実施形態においてコラボレーションプロセスのコンポーネント部分を例示する。この図は、コンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。当業者に明らかなように、この図に示すコンポーネントは、結合することもできるし、又は個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントに分割することもできる。更に、当業者に明らかなように、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピュータ装置間に分布させることもできる。

種々の実施形態において、コラボレーションプロセスは、１つ以上のプログラミング言語（例えば、Ｊａｖａ（登録商標）、Ｃ＃、等）で少なくとも一部分実施することができる。もちろん、本発明の範囲は、特定のプログラミング言語又はパラダイムに制限されない。これら実施形態の態様において、コラボレーションプロセスは、ＢＥＡシステムズ・インクから入手できるＷｅｂＬｏｇｉｃ（登録商標）サーバーのような１つ以上のアプリケーションサーバー１１２に展開されたエンタープライズ・エディション（Ｊ２ＥＥ）コンポーネントである１つ以上のＪａｖａ（登録商標）２プラットホームを含むことができる。説明上、コラボレーションプロセスは、次のコンポーネントの１つ以上を含むことができる。
−制御（制御レイヤー１０８として単独で示されている）；
−ウェブサービス１００；
−ページフロー１０２；
−ビジネスプロセス１０４；及び
−ＪａｖａＳｅｒｖｅｒページ（ＪＳＰ）１０６（その幾つか又は全部が１つ以上のページフローの一部分でよい）。

コンポーネントのロジックを実施するＪａｖａ（登録商標）コードに加えて、各ソースコードファイルは、ランタイム能力を決定するのに使用できるカスタムＪａｖａｄｏｃ注釈を含むことができる。これらの注釈により参照されるインフラストラクチャーは、Ｊ２ＥＥコンポーネントとして実施することができる。これら実施形態の態様において、コラボレーションプロセスは、最終的に、純粋なＪ２ＥＥアプリケーションとして展開することができる。

種々の実施形態において、制御は、ビジネスロジックをカプセル化し、及び／又は１つ以上のリソース１１０へのプログラムアクセスを与える。これら実施形態の態様において、制御モデルは、コラボレーションプロセスが、単純なＪａｖａ（登録商標）オブジェクトであるかのように一貫した単純な仕方でビジネスロジック又はリソースへアクセスするのを可能とする。制御は、データベース、Ｊａｖａ（登録商標）メッセージサービス（ＪＭＳ）待ち行列、及びエンタープライズＪａｖａＢｅａｎｓ^TM（ＥＪＢ）のような共通のリソースへのアクセスを簡単化することができる。しかしながら、本開示は、特定の制御の実施、プログラミング言語、又はプログラミングパラダイムに制限もされないし、又はそれらに依存もしない。当業者であれば、制御は、ライブラリー、サブルーチン、機能、メソッド、マクロ、手順、並びにプログラムロジック及び／又はリソースをカプセル化する他の適当な手段を含む（これらに限定されないが）多数の他の仕方で実施できることが明らかであろう。

これら実施形態の態様において、説明上、制御は、Ｊａｖａ（登録商標）クラスとして実施できると共に、ランタイムにおいてＪ２ＥＥ ＥＪＢコンテナによりマネージすることができる。コンテナは、自動トランザクション、非同期性、状態マネージメント、及び他のサービスを与えることができる。これら実施形態の態様において、制御のＪａｖａ（登録商標）クラス定義は、制御のランタイム振舞いを定義する注釈（例えば、Ｊａｖａｄｏｃ注釈）を含む。制御は、ウェブサービス、ページフロー(pageflow)、ＪＳＰ、ビジネスプロセス、及び他の制御を使用できると共に、それらからも使用され得る。制御の商業的実施形態は、ＢＥＡシステムズ・インクから入手できる。その全体としてこの開示に含まれるＢＥＡ ＷＥＢＬＯＧＩＣ（登録商標）ＷＯＲＫＳＨＯＰ^TM ＨＥＬＰ：ANNOTATIONS REFERENCE（２００３年１１月、バージョン８．１、ＳＰ２）を参照されたい。

種々の実施形態において、ウェブサービスとは、共通のウェブプロトコルを経て拡張可能なマークアップ言語（ＸＭＬ）メッセージを送信することにより機能にアクセスできるところのソフトウェアコンポーネントである。典型的に、これらのメッセージは、ＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）と称される特有のＸＭＬ方言である。メッセージは、通常、ウェブサービスがあるオペレーションを実行するための要求を表わす。サーバーホスティングウェブサービスは、このようなメッセージを受信すると、それを、ウェブサービスビジネスロジックを実施するエンティティへ配送する。オペレーションが完了すると、ウェブサービスは、通常、そのクライアントに応答して、ＸＭＬ又はＳＯＡＰ応答メッセージを送信する。

ウェブサービスはＸＭＬを経て通信できるので、クライアント及びウェブサービスは、一般に、他のものが実施されるところのプログラミング言語やオペレーティングシステムに気付かない。例えば、ＳＯＡＰ及びＸＭＬスキーマは、任意の複雑さのデータ形式を記述するための、言語及びオペレーティングシステムとは独立した仕方を与える。ウェブサービスの第１世代は、通常、ＨＴＴＰを経て呼び出される。しかしながら、ウェブサービスコンセプトの基礎は、メッセージングであり、メッセージを搬送するところのプロトコルは、無関係である。これら実施形態の態様において、ウェブサービスは、Ｊａｖａ（登録商標）ウェブサービス（ＪＷＳ）として指定することができる。ＪＷＳは、ウェブサービスオペレーションとして露出できる１つ以上のメソッドを定義する単一のＪａｖａ（登録商標）クラスを含むことができる。オペレーションは、ウェブサービスのユニフォームリソースロケータ（ＵＲＬ）に対する要求が受け取られたときに呼び出され、この要求は、実行されるべきオペレーションを識別すると共に操作すべきデータを含む適切なＸＭＬ又はＳＯＡＰメッセージを含む。Ｊａｖａｄｏｃ注釈は、ウェブサービス及びそのオペレーションの属性を構成するのに使用できる。

種々の実施形態において、ページフローは、多数のウェブページ、通常、ＪＳＰの間での情報のプレゼンテーション及びフローをマネージすることができる。ページフローは、アプリケーションを通してユーザの対話型経路を制御できると共に、制御を使用してバックエンドリソースにアクセスすることができる。ページフローは、特定のプログラミング言語、ソフトウェアフレームワーク、又はランタイムパラダイムに依存しない。これら実施形態の態様において、ページフローは、オープンソースファシリティであるストラッツ(Struts)フレームワークを、それらのランタイムインフラストラクチャーに対してアパッチ・ジャカルタ・プロジェクト(Apache Jakarta Project)（ｈｔｔｐ：／／ｊａｋａｒｔａ．ａｐａｃｈｅ．ｏｒｇ／ｓｔｒｕｔｓ／）からレバレッジすることができる。ページフローモデルは、ウェブページにわたる情報フローのマネージメントに集中することによりストラッツモデルを改良させる。ページフローは、１つ以上のＪａｖａ（登録商標）ページフロー（ＪＰＦ）として定義することができる。ＪＰＦは、１つ以上のアクションメソッドを定義する単一のＪａｖａ（登録商標）ページフロークラスを含むことができる。アクションは、ＪＰＦに定義されたルールに基づき、且つ個々のウェブページとのユーザ対話に応答して、呼び出すことができる。Ｊａｖａｄｏｃ注釈は、アクションメソッドの属性を構成するのに使用できる。ページフローの商業的実施は、ＢＥＡシステムズ・インクからそれらのＷｅｂＬｏｇｉｃ（登録商標）ポータル製品の一部分として入手できる。

種々の実施形態において、ビジネスプロセスは、種々のアプリケーションと人間の関係者との一体化、及びビジネスパートナーとエンタープライズとの間の整合された情報交換を可能にする。ビジネスプロセスは、定義されたオーダリングを伴うアクティビティのセットで構成される。説明上、ビジネスプロセスは、潜在的な種々のビジネスシステム（例えば、ビジネス対ビジネスのオーダー発注及び追跡システム、等）とユーザとの対話であって、ビジネスプロセス自体が事象発生及びメッセージ交換により進められるような対話を編成する。これら実施形態の態様において、ビジネスプロセスは、Ｊａｖａ（登録商標）プロセス定義（ＪＰＤ）により指定することができ、これは、参考としてここにその全体を援用する「JAVA（登録商標） COMMUNITY PROCESS JAVA SPECIFICATION REQUEST (JSR) 207: PROCESS DEFINITION FOR JAVA（登録商標）」(www.jcp.orgにおいて入手可能)に適合するものである。これら実施形態の態様において、ビジネスプロセスは、ＥＪＢへとコンパイルされ、そしてアプリケーションサーバーにおいて展開される。エンティティビーンは、ステートフルなプロセスに対して使用することができ、そしてセッションビーンは、ステートレスなプロセスに対して使用することができる。

図２は、本発明の種々の実施形態におけるコンポーネント呼び出しを例示する高レベル図である。これら実施形態の態様において、コンポーネントがコンパイルされるときに、アーティファクトの集合体を発生し、及び／又は展開するように（例えば、アプリケーションサーバーにおいて）構成することができる。これらのアーティファクトは、ディスパッチャー２００及びコンポーネントコンテナ２０２を含むことができる。コンポーネントコンテナは、コンテクストを与えると共に、他のコンポーネントへの一貫したインターフェイスを与える軽量クラスでよい。ウェブティア(tier)は、外部クライアント（例えば、ウェブブラウザ、又はウェブブラウザと一緒に実行されているアプリケーション）からコンポーネントを呼び出すためのプロトコルサポートを与える。トランスポートオブジェクトは、プロトコル特有のフォーマット（２０８、２１０）で呼び出し要求を受け取り、そしてそれらを、ディスパッチャーへ通される一般的な要求オブジェクトへと変換する。ＪＭＳ及びＨＴＴＰのような異なるトランスポートをサポートすることができるが、本開示は、特定のトランスポートに限定されず、又はそれに依存することもない。従って、まだ開発されていない新規なトランスポートも本開示の精神及び範囲内に完全に包含される。

種々の実施形態において、ＨＴＴＰを経て到達するウェブサービス呼び出しは、サーブレット２０６により受け取ることができる。ウェブサービスがその一部分であるコラボレーションプロセスは、ＵＲＬに対する全ての要求（例えば、「．ｊｗｓ」で終わる）をこのサーブレットへルーティングするように構成できる。ＪＷＳ ＵＲＬルーティングと、特定のウェブサービスＵＲＬにおける希望の基本的認証セキュリティとを、標準的なＪ２ＥＥウェブアプリケーション展開記述子において指定することができる。ＪＭＳプロトコルを経て到達するウェブサービス呼び出しは、特定の構成のＪＭＳ待ち行列（図示せず）へ向けることができる。メッセージ駆動ビーン（ＭＤＢ）２０４は、この待ち行列を聴取するように展開することができる。

これら実施形態の態様において、ディスパッチャーは、コラボレーションプロセス内の全てのコンポーネントにより構成されそして使用され得る。これら実施形態の態様において、ディスパッチャーは、到来する要求オブジェクトを受け取り、そしてそれらを適宜にルーティングする。特定のアプリケーションに対するディスパッチャーは、コラボレーションプロセスコンポーネントに関連する注釈を経て開発者が選択したランタイム特徴に基づいて、１つ又は２つのＥＪＢ（図示せず）を含むことができる。
−コンポーネントメソッドの非同期呼び出しを取り扱うメッセージ駆動ビーン。呼び出し要求は、待ち行列に入れられて、後でサービスされる。このビーンは、コラボレーションプロセスが１つ以上のコンポーネントをバッファされたメソッドと共に含む場合に展開することができる。
−到来する同期メソッド呼び出し要求を受け取るためのステートレスセッションビーン。これは、同期要求を適当なコンポーネントコンテナ（２０２）へ直接ルーティングし、そして非同期要求をメッセージ駆動ビーンへルーティングすることができる。同期メソッドは、これを指示する注釈を有することができる。

種々の実施形態において、コンテナ（例えば、コンテナＥＪＢ２０２）は、ウェブサービス、制御及びビジネスプロセス定義で見つかったコードをラップするのに使用できる。コンテナは、コンテクストサービス、制御初期化、及び事象ルーティングのような特殊な機能と、要求呼び出し中のコンテナ特有の前／後処理とを与えることができる。コンテナは、それが収容するコンポーネントのパブリックインターフェイスの鏡像であるビジネスインターフェイスを露出させる。これは、コンポーネントに対するメソッドごとの宣言セキュリティを可能にする。コンポーネントのソースファイルにおいて定義されたコードは、最終的に、コンポーネントメソッドが呼び出されたときにコンテナにより直接実行される。

これら実施形態の態様において、２つの形式のコンテナＥＪＢがある。
−ステートレス（非会話的）コンポーネントメソッド呼び出しを取り扱うステートレスセッションビーン。ステートが要求されないので、これら呼び出しは、このステートレスセッションビーンのプールされたインスタンスにより取り扱うことができる。
−ステートフル（会話的）コンポーネントメソッド呼び出しを取り扱うエンティティビーン。ステートフルメソッドは、特定コンポーネントインスタンスの持続ステートへのアクセスを要求する。このＥＪＢは、ウェブアプリケーションが１つ以上のコンポーネントを会話的メソッドと共に含む場合に存在する（例えば、メソッドは、それらが「会話」をスタートするか、継続するか、又は終了させるかを指示するように注釈が付けられる）。会話をスタートするとマークされたメソッドが読み出されたときには、新たな会話インスタンスを表わすために新たなエンティティビーンインスタンスが生成される。エンティティビーンのデータは、コンポーネントのインスタンスの持続ステートである。継続又は終了メソッドのその後の呼び出しは、エンティティビーンのインスタンスに作用する。

種々の実施形態において、情報をクライアントへ返送することができる。同期メソッド呼び出しのケースでは、コンポーネントメソッドの返送値を、ＸＭＬマッピングを経てＸＭＬ又はＳＯＡＰ応答に変換することができる。この応答は、ディスパッチャーを経て適当なトランスポートオブジェクトに返送することができる。ＨＴＴＰを経て要求が到達する場合には、その応答をＨＴＴＰ応答としてパッケージし、そしてサーブレットにより発信ＨＴＴＰ要求に対する応答として返送することができる。ＪＭＳを経て到達する要求のケースでは、直接的な応答が必要とされない。非同期メソッド呼び出しのケースでは、クライアントは、そのクライアントが会話中にコールバック位置を供給する（例えば、ＵＲＬを経て）場合に、メソッドが呼び出されたコンポーネントからコールバックを任意に受信することができる。コンポーネントのコンテナは、コールバックプロキシーを使用して、コールバック行先へ情報を送信することができる。

種々の実施形態において、ページフローコンポーネントは、コラボレーションプロセスにおいて関連ウェブページのセットにわたりナビゲーション及びデータフローを制御する。これら実施形態の態様において、ページフローは、ストラッツウェブアプリケーションである。しかしながら、ページフローは、制御へのアクセスを与えるような多数の重要なエリアにおいてストラッツを改善する。ページフローの更なる情報については、この参照によりその全体としてこの開示に含まれるＢＥＡシステムズ・インクから入手できるＢＥＡ ＷｅｂＬｏｇｉｃ（登録商標）Ｗｏｒｋｓｈｏｐ^TM Ｈｅｌｐ（２００３年１１月のバージョン８．１、ＳＰ２）を参照されたい。

ストラッツフレームワークは、モデル・ビュー・コントローラ（ＭＶＣ）のパターンをベースとする。ストラッツは、開発者がモデル及びビュー部分に対して適切な技術を選択するのを許すように設計されるが、実際には、Ｊ２ＥＥコンポーネントが各部分に対して使用され、即ちビューは、通常、ＪＳＰ（ＪａｖａＳｅｒｖｅｒページ）として実施され、コントローラは、通常、Ｊａｖａ（登録商標）サーブレットであり、そしてモデルは、通常、１つ以上のＥＪＢ（エンタープライズＪａｖａＢｅａｎｓ）で構成される。

ストラッツフレームワークは、ソフトウェア開発者がデフォールトストラッツ振舞いを増大又は交換できるような多数の拡張性ポイントを与える。ページフローは、これらの拡張性ポイントを利用して、その純粋なストラッツを使用するのがより簡単であるプログラミングモデルを与える。図３は、本発明の種々の実施形態におけるページフロー制御フロー及び拡張性ポイントを例示する。

種々の実施形態において、コラボレーションプロセスは、ＰａｇｅＦｌｏｗＪｓｐＦｉｌｔｅｒ（「^*．ｊｓｐ」へマップされたサーブレットフィルタ）でＪＳＰ要求を遮るように構成される。ＪＳＰに対する到来する要求において、ＪＳＰに対するディレクトリー経路が、登録されたストラッツモジュール（又はオンザフライで動的に登録されるストラッツモジュール）に対応する場合には、そのモジュールが要求において選択される。ストラッツは、ストラッツアプリケーションにおける全アクションユニバーサルリソース識別子（ＵＲＩ）が向けられるところのＡｃｔｉｏｎＳｅｒｖｌｅｔを与える。サーブレットは、特定のＵＲＩパターンをストラッツモジュールに関連付けるマッピングを使用して、到来する要求を適切なモジュールに向ける。ストラッツフレームワークは、カスタムアクションサーブレットの置き換えを許す。これらの実施形態の態様において、ＡｃｔｉｏｎＳｅｒｖｌｅｔは、カスタムＰａｇｅＦｌｏｗＡｃｔｉｏｎＳｅｒｖｌｅｔ３００に置き換えられる。

ページフローがコンパイルされるときには、ストラッツコンフィギュレーションファイルを、ページフローソースファイルにおける注釈に基づいて発生することができる。種々の実施形態において、ページフローは、コンフィギュレーションファイルを使用して、特定のＵＲＩ（又はＵＲＩパターン）に向けられた到来する要求をサーブレットにマップさせる。例えば、「．ｄｏ」又は「．ｊｐｆ」で終わるＵＲＩは、ＰａｇｅＦｌｏｗＡｃｔｉｏｎＳｅｒｖｌｅｔへマップすることができる。到来する要求が到達すると、ＰａｇｅＦｌｏｗＡｃｔｉｏｎＳｅｒｖｌｅｔは、要求のＵＲＩがマップされるところの登録されたストラッツモデルを探す。それが見つかると、要求が、ストラッツモジュールに関連した要求プロセッサへディスパッチされる。見つかったモジュールは、動的に登録されるページフローストラッツモジュールでよい。

又、ストラッツは、各ストラッツモジュールに関連した要求プロセッサオブジェクトも与える。要求プロセッサは、ユーザロール確認、アクションルックアップ、フォームデータマネージメント、アクションディスパッチ、及び要求転送を含む多数のフェーズを通して要求を見張る。ストラッツフレームワークは、カスタム要求プロセッサの置き換えを許す。これら実施形態の態様において、要求プロセッサは、カスタムＰａｇｅＦｌｏｗＲｅｑｕｅｓｔＰｒｏｃｅｓｓｏｒ３０２に置き換えられる。

ストラッツフレームワークは、要求の処理において種々のポイントで拡張を許すように要求プロセッサインターフェイスを定義する。ＰａｇｅＦｌｏｗＲｅｑｕｅｓｔＰｒｏｃｅｓｓｏｒは、これらの拡張性ポイントを利用する。ｐｒｏｃｅｓｓＭａｐｐｉｎｇ（プロセスマッピング）３０４の拡張性ポイントは、ＰａｇｅＦｌｏｗＲｅｑｕｅｓｔＰｒｏｃｅｓｓｏｒが、ストラッツコンフィギュレーションで定義されたアクションマッピングを検査して、要求のＵＲＩに関連したアクションを見出すのを許す。成功の場合には、ｐｒｏｃｅｓｓＭａｐｐｉｎｇが、アクションプロセスに関する情報をカプセル化するＡｃｔｉｏｎＭａｐｐｉｎｇ（アクションマッピング）を返送する。

コラボレーションプロセスは、特定のアクションを実行するためにユーザを特定のセキュリティロールのメンバーとして認証することを要求するように構成されてもよい。ｐｒｏｃｅｓｓＲｏｌｅ（プロセスロール）３０６の拡張性ポイントは、発呼ユーザが適当なロールにあるかどうか決定する。ユーザを、要求されたロールに属するものとして認証できない場合には、ブラウザにエラーを返送することができる。

要求プロセッサは、ターゲットアクションが、ｐｒｏｃｅｓｓＡｃｔｉｏｎＦｏｒｍ（プロセスアクションフォーム）３０８の拡張性ポイントに関連フォームビーンを有するかどうか、そしてフォームビーンが、要求に対して見られるべきかセッションに対して見られるべきか決定する。次いで、要求プロセッサは、要求ステート又はセッションステートにおいてフォームビーンにアクセスするよう試みる。それが見つからない場合には、新たなフォームビーンを生成し、そして適当なステートで記憶することができる。次いで、要求プロセッサは、要求の入力データを、ｐｒｏｃｅｓｓＰｏｐｕｌａｔｅ（プロセスポピュレート）３１０の拡張性ポイントにおけるｐｒｏｃｅｓｓＡｃｔｉｏｎＦｏｒｍで識別されたフォームビーンへマップする。

要求プロセッサは、次いで、適切なアクションオブジェクトを見つける。ストラッツは、アクションマッピングで指定されたクラスを使用してオブジェクトをインスタンス生成し、そしてｐｒｏｃｅｓｓＡｃｔｉｏｎＣｒｅａｔｅ（プロセスアクション生成）３１２の拡張性ポイントにおいてオブジェクトを返送する。種々の実施形態において、各ページフローの基本クラスは、ストラッツアクションクラスから導出される。ＰａｇｅＦｌｏｗＲｅｑｕｅｓｔＰｒｏｃｅｓｓｏｒ（ページフロー要求プロセッサ）は、適切なページフローオブジェクトをインスタンス生成し（もし必要であれば）、それをセッションにおいてキャッシュし、そしてそれをアクションとして返送する。又、ページフローオブジェクトは、適当な時期に呼び出されるライフサイクルメソッドを任意に実施してもよい。これらのメソッドは、ｏｎＣｒｅａｔｅ、ｂｅｆｏｒｅＡｃｔｉｏｎ、ａｆｔｅｒＡｃｔｉｏｎ、及びｏｎＤｅｓｔｒｏｙである。ページフローがインスタンス生成されるときに、そのｏｎＣｒｅａｔｅメソッドが呼び出される。

種々の実施形態において、ＰａｇｅＦｌｏｗＲｅｑｕｅｓｔＰｒｏｃｅｓｓｏｒは、ページフローの実行メソッドを呼び出す。このメソッドは、ページフローに使用可能なコンテクストを確立することを含む多数のステップを、ページフローの呼び出しの周りで実行する。要求、応答、セッション及びアクションマッピングオブジェクトは、全て、ページフローオブジェクトに記憶される。実行メソッドは、ページフローのｂｅｆｏｒｅＡｃｔｉｏｎライフサイクルメソッドを呼び出す。次いで、実行メソッドは、返送されるべきアクションフォワードオブジェクトを予想するページフローアクションメソッドを呼び出す。次いで、コントローラは、ページフローのａｆｔｅｒＡｃｔｉｏｎライフサイクルメソッドをコールし、そしてＡｃｔｉｏｎＦｏｒｗａｒｄオブジェクトを要求プロセッサへ返送する。ＡｃｔｉｏｎＦｏｒｗａｒｄオブジェクトは、ＰａｇｅＦｌｏｗＲｅｑｕｅｓｔＰｒｏｃｅｓｓｏｒがｐｒｏｃｅｓｓＦｏｒｗａｒｄＣｏｎｆｉｇ３１４の拡張性ポイントにおいてクライアントを前進させ又は向け直すことのできる行先を表わす。

種々の実施形態において、インターセプターオブジェクトは、ページフロートポロジーをインターセプトすることによりそれを動的に変更することができる。これは、全ページフローを置き換えたり、又はページフローシーケンスを既存のページフローに挿入したりすることを含む種々の状況に対して有用である。これら実施形態の態様において、インターセプターは、ページフローの開始又は終了に発生し、又はｂｅｆｏｒｅＡｃｔｉｏｎ及びａｆｔｅｒＡｃｔｉｏｎメソッドにおいて評価され、そして行先ページフローを動的に決定できるところのＡｃｔｉｏｎＦｏｒｗａｒｄオブジェクトを生成することができる。説明上、これは、ユーザがウェブページへ初めてナビゲートするときに、ある種の通知が与えられるようなシナリオに有用である。この通知を再検討した後、ユーザは、オリジナルのウェブページに自動的に戻ることができる。アクションの前後に、ページフローは、インターセプトの前後のポステッドフォームデータにアクセスする。インターセプションの後に、ページフローは、更に、インターセプトされたアクションによりポピュレートされるフォームにアクセスすることができる。

種々の実施形態において、インターセプターは、ルール駆動することができる。ルールは、多数の仕方で指定することができる。本発明は、インターセプタールールを指定する方法に依存せず、又はそれに限定されるものではない。説明上、ルールは、影響を受けるページフローの名前、インターセプターがｂｅｆｏｒｅＡｃｔｉｏｎメソッドで生じるかａｆｔｅｒＡｃｔｉｏｎメソッドで生じるか、及びターゲットアクション／ページフローの識別を指定することができる。これら実施形態の態様において、インターセプタールールに対する変更は、オンザフライで検出することができる。又、インターセプタールールは、「１回」フラグにより変更することもでき、これは、ターゲットページフローを最初に通るときだけインターセプションが生じることを意味する。一実施形態では、インターセプションは、ソース及びターゲットアクションと、同様に１回のインターセプションに対する変更とを定義するＸＭＬファイルを経てコンフィギュレーションすることができる。又、このコンフィギュレーション情報は、ランタイムにアクセス可能であり、従って、コンフィギュレーションされたインターセプションのいずれかをプログラムでオン及びオフにすることもできるし、或いはソース及びターゲット情報をプログラムで更新することもできる。

図４は、本発明の種々の実施形態におけるメッセージングレイヤーを例示する。この図は、コンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。当業者に明らかなように、この図に示すコンポーネントは、結合することもできるし、又は個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントに分割することもできる。更に、当業者に明らかなように、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピュータ装置間に分布させることもできる。

コラボレーションシナリオ（以下、「コラボレーション」又は「シナリオ」と称する）は、コラボレーションプロセスの整合のもとで一緒に作用する多数のクライアントユーザ及び／又はプロセス（以下、「クライアント」と称する）を含むことができる。種々の実施形態において、シナリオ関係者（即ちクライアント（１人又は複数）及びコラボレーションプロセス）は、それらの間で知られているプロトコルを使用して相互作用することができる。これら実施形態の態様において、プロトコルは、１つ以上のパブリック及び／又はプライベートネットワーク、共有メモリ、ファイルシステム、分布オブジェクト、及び情報交換に適した他の手段を含む（これらに限定されないが）通信媒体を経て送信することができる。

種々の実施形態において、メッセージングレイヤー４００は、シナリオ関係者に対する通信媒体を与える。関係者は、アプリケーションプログラミングインターフェイス（ＡＰＩ）４０２を利用することによりメッセージングレイヤーを経て互いに対話することができる。ＡＰＩは、基礎となる通信ファシリティへの依存性を生じることなくメッセージング機能を露出する。又、ＡＰＩは、あるタスクを実行するように仕立てられた１つ以上の特殊なＡＰＩ（図示せず）も含むことができる。これら実施形態の態様において、ＡＰＩ機能は、関係者に対して、ソフトウェアライブラリーとして、１つ以上のオブジェクトとして、及び／又は他の適当な手段により、表面化することができる。

又、メッセージングレイヤーは、１つ以上の通信プロバイダー（４０６−４１２）が、ＳＰＩの幾つか又は全部を実施し、ひいては、それらのサービスをＡＰＩに利用できるようにすることにより、メッセージングレイヤーに動的に「プラグイン」するのを許すサービスプロバイダーインターフェイス（ＳＰＩ）４０４も備えている。これら実施形態の態様において、ＳＰＩ機能は、ライブラリーとして、１つ以上のオブジェクトとして、及び／又は他の適当な手段により、表面化することができる。これら実施形態の態様において、プロバイダーは、必要な帯域巾、トランスポート信頼性、プロトコル等のパラメータに基づいてプロバイダー実施を命令するＳＰＩファクトリークラスにより、ランタイムに、動的に生成することができる。種々の実施形態において、多数の通信プロバイダーを、メッセージングレイヤーにより同時にサポートすることができる。これは、あるシナリオ内の多数のトランスポートを利用するのを許す（例えば、インスタントメッセージング及びｅメール）。これら実施形態の更に別の態様において、多数のプロバイダーが共存するときには、プロバイダーが指定されないときに通信に使用するために「デフォールト」トランスポートとして各々呼称することができる。当業者に明らかなように、通信プロバイダーは、ネットワークベースの通信を与えることに限定されず、任意の情報交換方法、例えば、プロセス間通信、プロセッサ間通信、共有メモリ又は他の記憶システムを通しての通信、及び所与のコンピューティング装置内の他の適当な通信リンク（これらに限定されないが）をベースとすることもできる。

ＳＰＩは、ＡＰＩが、プロバイダー独立形態でプロバイダーの機能にアクセスするのを許す。各プロバイダーは、ＳＰＩの幾つか又は全部を実施するので、ＡＰＩへの変更を必要とせずにプロバイダーを変更することができる。これは、新たな通信ファシリティ及び技術が利用可能になったときにそれらを受け容れるのを許す。というのは、基礎となる通信プロバイダーの性質がＳＰＩにより隠されるからである。従って、本開示は、何らかの特定の通信プロトコル又は物理的レイヤートランスポートに限定されない。本開示の精神及び範囲内で多数のこのようなプロバイダーが考えられることが当業者に明らかであろう。

ＳＰＩは、１つ以上の特殊なＳＰＩ（図示せず）を含んでもよい。これら実施形態の態様において、ＳＰＩは、プロバイダーを初期化し、開始し、そして停止する機能を含むことができる。又、ＳＰＩは、特定のタスクに対して仕立てられた特殊なＳＰＩへのアクセスも与えることもできる。これら実施形態の態様において、メッセージプロバイダーＳＰＩは、次のものを含む機能を露出することができる。

−プロバイダーを初期化するための機能。これは、各プロバイダーのサーバー又はもしあれば他のプロセス（例えば、インスタントメッセージングサーバー）を構成することを含んでもよい。
−能力のようなプロバイダー属性を得るための機能。例えば、所与のプロバイダーによりサポートされる暗号化機構及び信頼性。

−ユーザアカウントマネージャーＡＰＩを得るための機能であって、このようなＡＰＩは、ユーザアカウントのマネージに関連した機能を露出する。例えば、ユーザパスワード及びユーザ許可を変更する。
−ユーザ存在マネージャーＡＰＩを得るための機能であって、このようなＡＰＩは、ユーザ存在関連情報を与える機能を露出する。

−接続マネージャーＡＰＩを得るための機能。説明上、このようなＳＰＩは、サーバーにログインする能力、属性のセット（例えば、使用すべき暗号化機構の形式、等）に基づいて有効通信接続を得る能力、接続に対する独特の識別子を得る能力、及びメッセージを送信及び受信する能力のような接続マネージメント機能を露出することができる。

−通信に関連した事象を受け取るための機能。これら実施形態の態様において、このメソッドは、所与のプロバイダー接続を経てメッセージを検索する準備ができたときに通知を受け取るためのメソッド、オブジェクト又は機能（「メッセージリスナー」）の登録を許す。これら実施形態の態様において、多数のメッセージリスナーを所与の接続に関連付けることができる。
−メッセージを処理するメソッド（例えば、情報をパースし、抽出し、等々）。

ＳＰＩプロバイダーの１つの形式は、チャンネル（例えば、４０８及び４１０）である。チャンネルは、メッセージをトランスポートし、そしてそれらを関係者に利用できるようにする役割を果たす。チャンネルは、非同期及び／又は同期通信を与えることができる。非同期通信の場合には、チャンネルは、受信したメッセージを１つ以上の登録されたメッセージリスナーへ向けることができる。種々の実施形態において、チャンネルは、ジャバー・ソフトウェア・ファウンデーション（ｗｗｗ．ｊａｂｂｅｒ．ｏｒｇ）から入手できる拡張可能なメッセージング及び存在プロトコル（ＸＭＰＰ）をベースとすることができる。このＸＭＰＰは、拡張可能なマークアップ言語（ＸＭＬ）をベースとするインスタントメッセージングプロトコルである。ＸＭＰＰベースのチャンネルプロバイダーは、外部ＸＭＰＰサーバーと通信して、メッセージを他の関係者と交換し、そして存在情報を伝播することができる。存在情報は、関係者がシナリオに対して他の関係者を見つけるのを許す。本開示の精神及び範囲内で、同様の又は異なる通信技術をベースとする他の実施も考えられる。メッセージングレイヤーの観点から要求される全てのものは、ＳＰＩに適合する。

存在の概念は、インスタントメッセージング（ＩＭ）の世界で使用される。存在のＩＭサポートは、各人の名簿（「バディー（友人）リスト」とも称する）内の全てのユーザに対して状態（「利用可能」、「利用不能」、「自分のデスクから離れている」、等々）を与えることを中心とする。これら実施形態の態様において、存在情報は、ロールの使用を通してユーザに関する情報又は他の情報に結合することができる。メッセージの送信及び受信に加えて、メッセージングレイヤーＡＰＩは、ＳＰＩプロバイダーのサポートがある場合に（ＸＭＰＰをベースとするプロバイダーの場合と同様に）、存在及び状態情報を関係者に与えることもできる。存在情報は、シナリオ関係者がそれらの存在及び状態を互いに知らしめるために使用できるチャンネルプロバイダー又は特殊目的の存在プロバイダー（４０６）により与えることができる（例えば、その情報を他の関係者へブロードキャストするか、又は中央レポジトリーを更新することにより）。説明上、存在プロバイダーは、チャンネルプロバイダーを利用して、存在情報を通信することができる。種々の実施形態において、２つの形式の存在情報、即ちユーザ存在及びアプリケーション存在、がある。ユーザ存在及び状態は、シナリオに対する関係者の利用性に関する情報を与える。これら実施形態の態様において、ユーザ存在は、ロールをベースとすることができる。アプリケーション存在は、特定のアプリケーションの利用性に関する情報を与える。アプリケーションの存在は、必要なアプリケーションを実行している適当な関係者を見つける必要がある場合に重要となる。

種々の実施形態において、ＡＰＩは、ロール(role)ベースの存在機能を与えることができる。これは、特定のロール及び存在状態へマップするユーザが実行中のシナリオへ動的に招待されるのを許す。これら実施形態の態様において、存在機能は、所与のロールにマップすると共にシナリオへの参加に「利用できる」ユーザのセットを与えることができる。これら実施形態の態様において、ロールは、ユーザの動的なセットである。ロールは、そのメンバーにより共有された属性に基づくことができ、そして１つ以上のメンバーシップ基準により定義することができる。ロールマッピングは、ユーザが所与のロールに対してメンバーシップ基準(Membership Criteria)を満足するかどうか決定するプロセスである。説明上、ロールは、次のように述べることができる。
Role＝PMembers + [Membership Criteria]
但し、ＰＭｅｍｂｅｒｓは、もしあれば、メンバーシップ基準を受けるこのロールの潜在的メンバーのプールを形成するユーザ（１人又は複数）、グループ（１つ又は複数）及び／又は他のロール（１つ又は複数）のセットである。ロールにあるべきユーザ又はプロセスに対して、それらは、ＰＭｅｍｂｅｒｓに属しそしてメンバーシップ基準を満足しなければならない。メンバーシップ基準は、１つ以上の条件を含むことができる。説明上、このような条件は、１つ以上の（おそらくネスト型及び混合型）ブール、数学的、機能的、関連性、及び／又は論理的表現を含むが、これらに限定されない。これらのロールは、ランタイムに動的に評価できるので、シナリオの関係者がアクティブである間にそれらを動的に変更することもできる。これは、システムアドミニストレータに膨大な量の融通性を与える。というのは、作用を受けるプログラムを再コンパイル又は再始動せずに、シナリオの基本的動作パラメータを変更できるからである。
説明上、次のアドミニストレータロールについて考える。
Administrator = Joe, Mary, SuperUser + CurrentTime > 5:00pm

このアドミニストレータロールは、２人のユーザ（Ｊｏｅ及びＭａｒｙ）と、ＳｕｐｅｒＵｓｅｒという名前のユーザグループに属するユーザとをその潜在的メンバーとして有する。メンバーシップ基準は、現在時間が５：００ｐｍ以降であることを要求する条件を含む。従って、ユーザがＪｏｅ、Ｍａｒｙであるか、ＳｕｐｅｒＵｓｅｒグループに属し、そして現在時間が５：００ｐｍ以降である場合には、ユーザがアドミニストレータロールのメンバーである。

種々の実施形態において、メンバーシップ基準は、ユーザのプロパティを少なくとも一部分ベースとすることができる。説明上、以下の表１に定義するロールについて考える。
表１：種々の実施形態におけるロールの例

スーパーバイザー（Ｓｕｐｅｒｖｉｓｏｒ）ロールは、ユーザＪｏｅ、Ｍａｒｒｙ、Ｐａｕｌ及びＴｉｍｏｔｈｙをその潜在的メンバーとして含む。ロールについて適任とするために、これらのユーザは、ジョブタイトル‘マネージャー’、部門‘顧客支援’、及び存在状態‘利用可能’を要求するメンバーシップ基準を満足しなければならない。Ｓｅｒｖｉｃｅ＿Ｒｅｐロールは、システムの全てのユーザがその潜在的なメンバーであるが、スーパーバイザーロールに対して適任ではなく且つ利用可能な者だけであることを指定する。ロールベースシステムの商業的実施形態は、ＢＥＡシステムズ・インクから入手できるＢＥＡ ＷｅｂＬｏｇｉｃ（登録商標）ポータルである。

種々の実施形態において、ロールベースの存在情報は、必要に応じて評価することができる。というのは、このような決定が処理遅延を導入し得るからである。これら実施形態の態様において、ロールベースの存在情報を最新の状態に保つために、異なるメカニズムを使用することができる。最悪の場合の実施形態では、ロールを参照するたびに、ロールのメンバーシップ基準が再計算される。よりインテリジェントな解決策は、いかに頻繁にロールを再計算する必要があるか決定するために、基準それ自体を見ることができる。

説明上、ある基準は、他の基準より頻繁に変化する。例えば、グループメンバーシップは、通常、システムアドミニストレータにより一度確立されるだけであるから、頻繁に変化しない。従って、グループ基準しかもたないロールは、所与のユーザがログインされる間に再評価される必要はなく、ログイン時間に１回だけでよい。一方、日付／時間基準は、グループメンバーシップより頻繁に変化し、従って、メンバーシップ基準が日付／時間情報に依存するロールは、非常に迅速に（例えば、シナリオのライフスパン中に）古いものとなる。これら実施形態の態様において、存在情報は、設定されたインターバルで日付／時間基準に依存するロールを再評価することにより新鮮さを保つことができる。従って、ロールメンバーシップ基準のセットが与えられると、最も変わり易いと考えられる基準が、ロールを再評価する頻度を駆り立てることになる。

種々の実施形態において、メッセージングＡＰＩは、クライアントプロセス及びコラボレーションプロセスが所与のロール（１つ又は複数）に対する存在情報に契約できるような契約(subscription)の特徴をサポートすることができる。これら実施形態の態様において、存在プロバイダー、チャンネルプロバイダー又は他のプロセスは、ロールメンバーシップに対する変化を監視し、そしてこのような変化の通知を受け取るために登録したクライアントプロセス及び／又はコラボレーションプロセスに通知することができる。メッセージングＡＰＩは、所与のプロセスが１つ以上のロールに契約する能力を与える。これら実施形態の態様において、所与のロールにあるユーザは、それらのプライバシーを保護するために契約要求を断るか又は受け容れることができる。これら実施形態の付加的な態様において、ユーザの入力を不要とするようにルール及び／又はロールの使用を介してこのような承認を自動化することができる。説明上、ユーザは、所与のセットのロールにおいてプロセス／ユーザによる契約要求を自動的に受け容れるように選択してもよい。

図４を再び参照すれば、モニタプロバイダー４１２は、アドミニストレーション及びオーデットアクティビティをサポートするためにメッセージングレイヤー監視を与えることができる。非限定例として、モニタプロバイダーは、他のプロバイダーに対するメッセージのフローを追跡することができる。これら実施形態の態様において、モニタプロバイダーは、それがどんなアクティビティを追跡するか決定するルールを使用して構成することができる。ルールは、自然言語で、又はグラフィックで、又は表現により、又は他の適当な手段により表現することができる。ルールは、存在情報からの表現変数、ユーザプロフィール情報（例えば、名前、住所、場所等）、又は他の情報に置き換え得る１つ以上の表現を含むことができる。種々の実施形態において、ルールは、数学的、論理的及びブールの演算子、機能／メソッド呼び出し、マクロ、ＳＱＬ（構造化問合せ言語）、及び他の適当な問合せ言語含むことができる。種々の実施形態において、表現は、変数置き換え、定数フォールディング及び／又はマクロ拡張を実行するために、１回以上、前処理することができる。当業者であれば、本開示の精神及び範囲内で他の多数の形式の表現も考えられることが明らかであろう。

一実施形態では、ＳＰＩの機能がアクセスされるたびに、モニタプロバイダーは、ＳＰＩにより通知され（例えば、事象を経て）、情報を（任意に）ログし及び／又は情報に作用することができる。それとは別に又はそれに加えて、プロバイダーは、特殊なモニタＳＰＩを経て事象が生じたときにその事象をモニタプロバイダーに先を見越して通知することができる。このように、ＡＰＩが関係者により呼び出されるかどうかに関わらず、全ての事象（例えば、メッセージの送信及び受信、存在情報の伝播）を追跡することができる。これら実施形態の態様において、モニタプロバイダーは、ルールをトリガーした事象を他のプロセスに通知することができる（例えば、メッセージを送信することにより）。例えば、プロセス「Ａ」が、所与のプロバイダーにより送信されたメッセージの数がある数を越えたときを知りたい場合には、メッセージの数が限界を越えたときにプロセス「Ａ」に通知がなされることを指定するこの条件でルールを指定することができる。

図５は、本発明の種々の実施形態におけるシナリオ関係者を例示する。この図は、プロセス及びコンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。当業者に明らかなように、この図に示すコンポーネントは、結合することもできるし、又は個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントに分割することもできる。更に、当業者に明らかなように、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピュータ装置間に分布させることもできる。

種々の実施形態において、説明上、シナリオ関係者は、メッセージングレイヤー５０６を使用して１つ以上のネットワーク５２０を経て互いに通信することができる。これら実施形態の態様において、メッセージングレイヤーの基礎となる通信プロバイダー（図示せず）は、１つ以上のＸＭＰＰベースのＩＭサーバー５１０を任意に使用して、メッセージを交換すると共に、存在情報を伝播することができる。この説明では、ビジネスプロセス５００及び５１６により表わされた２つのコラボレーションプロセスと、ウェブブラウザ５０８及び５１２により表わされた２つのクライアントプロセスとがある。必要とされないが、クライアントプロセスのユーザインターフェイスは、ページフロー（サーバーに対して実行される）により駆動することができる。ここで、ブラウザ５０８は、サーバーＡにおいてページフロー５０２により駆動され、一方、ブラウザ５１２は、サーバーＢにおいてページフロー５１４により駆動される。これら実施形態の態様において、ページフロー及びブラウザは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）及び／又はＨＴＴＰのセキュアバージョンであるＨＴＴＰＳを使用して通信することができる。ブラウザは、ＨＴＴＰ及びメッセージングレイヤーの両方と通信できるので、メッセージングレイヤーは、ウェブブラウザがＨＴＴＰストリームの外部のデータを受信できるようにする。

種々の実施形態において、ビジネスプロセスは、ページフローにより開始することもできるし、又はブラウザからのＨＴＴＰ要求により開始することもできる。後者のケースでは、要求のＵＲＩが、ブラウザと通信するサーバーにおいて検査されて、ビジネスプロセスに対応する所定のＵＲＩに一致するかどうか決定する。もしそうであれば、サーバーは、ブラウザに代わってビジネスプロセスを開始することができる。新たに開始されたビジネスプロセスは、次いで、ビジネスプロセスにより要求されるエンドユーザアプリケーションに対応する適当なページフローにブラウザを向け直すことができるが、これに限定されない。

扮装(impersonation)とは、システムの部分がユーザに代わってオペレーションを実行する能力である。この概念は、Ｕｎｉｘ（登録商標）ベースのオペレーティングシステムにおけるユーザの概念と同様である。セキュリティ及び許可の目的に対するＵｎｉｘ（登録商標）プロセスは、特定のユーザ、通常、プロセスをスタートしたユーザの特権で実行される。特権（権利とも称される）は、ユーザがシステムにおいて何ができそして何ができないか支配する。この機構は、ユーザによりスタートされたプロセスが、ユーザに権利が与えられていないオペレーション（例えば、ファイルシステム内の全てのファイルを削除し、システムを再ブートし、等々）を実行するのを防止する。ここで、所与のコラボレーションプロセスは、１つ以上のクライアントプロセスと対話し、各クライアントプロセスは、特定のユーザによりスタートされたものか又は「所有」されたものである。コラボレーションプロセスは、それが所与のユーザとしてあるオペレーションを実行するために、ユーザの特権に基づいてオペレーションを実行することをシステムに命令するコマンドを実行することができる。このように、コラボレーションプロセスは、クライアントプロセスにサービスする間に異なるユーザに「扮装」させ、ひいては、システムの完全性を維持することができる。

ビジネスプロセスは、そのビジネスプロセスと同じコンピューティング装置に存在するかそれとは異なるコンピュータリング装置に存在するかに関わらず、他のビジネスプロセス、ページフロー及びクライアントプロセス（例えば、ウェブブラウザ）と通信することができる。同様に、ページフローは、そのページフローと同じコンピューティング装置に存在するかそれとは異なるコンピュータリング装置に存在するかに関わらず、ビジネスプロセス及びクライアントと通信することができる。又、シナリオ関係者は、非同期の形態で通信を行うことができる。というのは、メッセージングレイヤーは、通信がこれを直接サポートするのを許すからである。この特徴の１つの結論は、ＨＴＴＰ（これは同期プロトコルである）を必要とせずに、そしてクライアントブラウザがウェブページをリフレッシュ又は再ロードさせることなく、情報をコラボレーションプロセスからクライアントウェブブラウザへ転送できることである。

これら実施形態の態様において、シナリオ関係者は、制御レイヤー５０４の制御を利用し、それらのタスクを実行する上でそれらの助けとなり得る。以下の説明は、異なる制御形式に基づく制御機能を示すが、このような機能は、本開示の精神及び範囲から逸脱せずに、少数の制御へと結合するか、又は多数の制御にわたって分散できることが明らかであろう。

種々の実施形態において、メッセージ制御は、メッセージングレイヤーＡＰＩと対話するための高レベルで且つ簡単化された手段をなすことができる。これら実施形態の態様において、メッセージ制御は、コラボレーションプロセスが通信を試みる各クライアントに対して関係者識別子（「関係者ｉｄ」）を自動的に得ることができる。種々の実施形態において、関係者ｉｄは、シナリオに含まれた関係者により、互いを識別するために使用される。関係者ｉｄは、ウェブポータルユーザ及びアプリケーションサーバーに指定できるが、これらに限定されない。これら実施形態の態様において、関係者ｉｄは、プールデータ構造体から引き出しそしてそこへ戻して、それらの再使用を容易にすることができる。他の実施形態では、関係者ｉｄは、シンプル・メール・トランスポート・プロトコル（ＳＭＴＰ）のようなトランスポートが使用されるときに、その性質がより「永久的」なものとなり得る。ＳＭＴＰの場合に、関係者ｉｄは、ｅメールアドレスに等しくすることができる。従って、関係者ｉｄは、ｅメールアドレスが滅多に変化しないので、その性質が過渡的とならない。これら実施形態の態様において、関係者ｉｄは、それに関連したパスワード及び状態をもつことができる。状態は、関係者ｉｄの状態をその生成時に参照することができる。これを使用して、存在情報に依存する判断の基礎とすることができる。

再び図５を参照すれば、クライアントは、それ自身、「リッチＵＩ」アプリケーション５２２と称される１つ以上のクライアントプロセスを含むことができる（「リッチＵＩ」とは、「リッチユーザインターフェイス」を意味する）。種々の実施形態において、アプリケーション識別子（「アプリケーションｉｄ」）は、各クライアントプロセス及び各コラボレーションプロセスに指定することができる。これら実施形態の態様において、関係者ｉｄ(participant id)及びアプリケーションｉｄ(application id)の組み合せを使用して、シナリオメッセージに対する行先（即ち、「routing id」）を指定することができる。
<Routing id> = <Participant id> + <Application id>

図６は、本発明の種々の実施形態における例示的メッセージ制御のクラス図である。ＭｅｓｓａｇｅＣｏｎｔｒｏｌ（メッセージ制御）６００は、関係者によりメッセージを送信及び受信するために使用することができる。これは、関係者ｉｄを使用してＭｅｓｓａｇｅＥｎｔｉｔｙＭａｎａｇｅｒ（メッセージエンティティマネージャー）６０２から得ることのできるＭｅｓｓａｇｅＥｎｔｉｔｙ（メッセージエンティティ）６０４に依存する。生成時に、ＭｅｓｓａｇｅＣｏｎｔｒｏｌは、ＭｅｓｓａｇｅＥｎｔｉｔｙＭａｎａｇｅｒを使用して、それに指定されたＭｅｓｓａｇｅＥｎｔｉｔｙを得ることができる。これは、次いで、そのアプリケーションｉｄと、ＭｅｓｓａｇｅＣｏｎｔｒｏｌへの非同期メッセージ返送に使用できるＭｅｓｓａｇｅＣａｌｌｂａｃｋ（メッセージコールバック）６０８とを登録することができる。

これら実施形態の幾つかにおいて、ＭｅｓｓａｇｅＣｏｎｔｒｏｌは、時々保留及び／又はシリアル化できるコラボレーションプロセス内で使用できるので、ＭｅｓｓａｇｅＣｏｎｔｒｏｌは、Ｐａｒｔｉｃｉｐａｎｔ＿ｉｄオブジェクトをメンバー変数として維持し（即ち、関係者ｉｄ及びその関連情報を記憶するために）、そしてそれを使用して、その関連ＭｅｓｓａｇｅＥｎｔｉｔｙに過渡的にアクセスするだけである。

ＭｅｓｓａｇｅＣｏｎｔｒｏｌは、ＭｅｓｓａｇｅＥｎｔｉｔｙを使用して、メッセージを直接送信及び受信することができる。メッセージの同期的受信は、受信するためのメッセージが得られない場合にオペレーションが不定にブロックしないように時間切れパラメータで実行することができる。メッセージを非同期で受信するために、ＭｅｓｓａｇｅＣａｌｌｂａｃｋを使用することができる。ＭｅｓｓａｇｅＣｏｎｔｒｏｌにおけるｗａｉｔＦｏｒＭｅｓｓａｇｅ（メッセージ待機）メソッドは、コールバックに対する登録メソッドとして働くことができる。ＭｅｓｓａｇｅＣｏｎｔｒｏｌは、次いで、ＭｅｓｓａｇｅＥｎｔｉｔｙにおいてｗａｉｔＦｏｒＭｅｓｓａｇｅを呼び出すことができ、これは、特定のアプリケーションｉｄに対して新たなメッセージが到達したときに、登録されたＭｅｓｓａｇｅＣａｌｌｂａｃｋを使用するようにＭｅｓｓａｇｅＥｎｔｉｔｙを構成する。このコールバックは、次いで、発呼プロセスへコールバックするようにＭｅｓｓａｇｅＣｏｎｔｒｏｌをトリガーすることができる。ＭｅｓｓａｇｅＥｎｔｉｔｙは、Ｃｏｎｎｅｃｔｉｏｎ（接続）６１０オブジェクトを使用して、メッセージングＡＰＩと対話し、メッセージを送信すると共に、コールバックを登録する。

これら実施形態の幾つかにおいて、コールバックがコラボレーションプロセスに対するＭｅｓｓａｇｅＥｎｔｉｔｙに現在登録されず、そしてメッセージがメッセージングレイヤーから到達するときに、メッセージをＭｅｓｓａｇｅＱｕｅｕｅ（メッセージ待ち行列）６０６に入れることができる。メッセージを同期的又は非同期で受信するその後の試みは、この待ち行列からメッセージを消費することができる。

図７は、本発明の種々の実施形態における例示的存在制御のクラス図である。ＰｒｅｓｅｎｃｅＣｏｎｔｒｏｌ（存在制御）７００は、アプリケーション及びユーザ存在情報を関係者に与えることができる。これら実施形態の態様において、ＡｐｐｌｉｃａｔｉｏｎＰｒｅｓｅｎｃｅＭａｎａｇｅｒ（アプリケーション存在マネージャー）７０６のインスタンスは、全シナリオの現在存在状態を維持する役割を果たす。ＳｃｅｎａｒｉｏｓＰｏｒｔａｌＳｅｒｖｌｅｔ（シナリオポータルサーブレット）７０２は、関係者エンドユーザ識別子（例えば、ウェブポータルユーザのログイン名）と、所与のエンドユーザに関連した関係者ｉｄと、所与の関係者ｉｄに対して現在得られるアプリケーション形式との間の関連付けと共に、ＡｐｐｌｉｃａｔｉｏｎＰｒｅｓｅｎｃｅＭａｎａｇｅｒをポピュレーションする役割を果たす。種々の実施形態において、ＳｃｅｎａｒｉｏｓＰｏｒｔａｌＳｅｒｖｌｅｔは、エンドユーザを行先とするＨＴＭＬ応答を検査して、そのエンドユーザに対してどんなアプリケーション形式が利用でき／存在するか決定するサーブレット／プロセス／スレッドである。このような応答は、エンドユーザのウェブブラウザ又は他のクライアントプロセスに存在を有するアプリケーションを開始し、レンダーし及び／又はそれと対話するためのインストラクションを含むことができる。一実施形態では、ＳｃｅｎａｒｉｏｓＰｏｒｔａｌＳｅｒｖｌｅｔ又はシステムの他の部分は、ＨＴＭＬ応答を検査して、アプリケーションが所与のクライアントプロセスに対する範囲に入ったり出たりするとき（即ち、アクティブであるか又は保留されるとき）を決定することにより、アプリケーション状態を追跡することもできる。説明上、アプリケーションが第１の応答においてレンダーされるが、その後の応答ではレンダーされない場合には、アプリケーションの状態が「保留」状態（即ち「アクティブ」でない）をもつことになる。というのは、それがもはや現在ウェブページにないからである。更に別の実施形態では、アプリケーション形式及び状態情報をクライアントプロセスから得ることができ、これは、どのアプリケーションが存在しそしてどんな状態であるかをメッセージングレイヤーに知らせる。この情報は、他の関係者へ中継又はブロードキャストされ、全ての関係者に変化を通知することができる。

ＡｐｐｌｉｃａｔｉｏｎＰｒｅｓｅｎｃｅＭａｎａｇｅｒの情報は、ＳｃｅｎａｒｉｏｓＰｏｒｔａｌＳｅｒｖｌｅｔに関連付けることのできるＡｐｐＰｒｅｓｅｎｃｅＥｎｔｉｔｙ７０４インスタンスにより更新することができる。例えば、ＡｐｐＰｒｅｓｅｎｃｅＥｎｔｉｔｙは、アプリケーションがもはや存在しないときにメッセージングＡＰＩから通知を受け取り（例えば、コールバックを経て）、それを反映するようにＡｐｐｌｉｃａｔｉｏｎＰｒｅｓｅｎｃｅＭａｎａｇｅｒを更新することができる。種々の実施形態において、ＡｐｐＰｒｅｓｅｎｃｅＥｎｔｉｔｙは、特定のクライアントエンティティに関連したアプリケーション形式の通知を受け取り、そしてそれに応じてＡｐｐｌｉｃａｔｉｏｎＰｒｅｓｅｎｃｅＭａｎａｇｅｒを更新することができる。

ＰｒｅｓｅｎｃｅＣｏｎｔｒｏｌは、所与のユーザの存在状態を与えるｇｅｔＵｓｅｒＳｔａｔｕｓ（ユーザ状態を得る）メソッドをサポートするためにメッセージングＡＰＩに直接依存する。又、ＰｒｅｓｅｎｃｅＣｏｎｔｒｏｌは、アプリケーション存在情報を得るためにＡｐｐｌｉｃａｔｉｏｎＰｒｅｓｅｎｃｅＭａｎａｇｅｒにも依存する。ＰｒｅｓｅｎｃｅＣｏｎｔｒｏｌのｇｅｔＵｓｅｒＷｉｔｈＲｏｌｅ（ロールでユーザを得る）メソッドは、コラボレーションプロセスが、ａｐｐＴｙｐｅに一致するアクティブなアプリケーションを有する特定のロールで利用可能なユーザのリストを得るのを許す。これは、ロール及びアプリケーション形式に基づいて適当なコラボレーション候補のリストを見出すのに有用である。ｇｅｔＵｓｅｒＳｔａｔｕｓの別の変形を設け、これを使用して、関係者ｉｄ及びアプリケーション形式を与えることに基づきユーザのリアルタイム状態を決定することもできる。

種々の実施形態において、シナリオ制御は、シナリオセッション生成及び最終決定、関係者及びグループ結合、並びに共有状態へのアクセス、を含むシナリオ関連アクティビティに対する抽象を与えることができる。シナリオセッションは、シナリオに関与した関係者に対する論理的ランタイムコンテクストである。セッションは、シナリオの任意の段階中に確立できるが、通常、早期の段階に生成される。シナリオセッションは、ＨＴＴＰセッション又はポータルログインセッションに必ずしも等しくない。ポータルログインセッション（匿名のユーザ）がない場合や、ＨＴＴＰセッションのスパン内で多数のシナリオセッションが生じる場合もあり得る。

シナリオセッションは、セッションの関係者が情報を容易に共有するのを許す共有ステートメカニズムを与える。これら実施形態の態様において、セッションは、持続マップとして実施することができる。シナリオセッションは、ストリング識別子キーによりアクセスされるオブジェクト属性を記憶しそして得るのに使用できるという点で、ＨＴＴＰセッション又はＨＴＴＰＳｅｒｖｌｅｔＲｅｑｕｅｓｔｓと同様である。セッションの全関係者は、これらセッション属性をポピュレートしそして検索してもよいが、これら実施形態の態様において、属性データの全視程は、属性を生成するアクターによりセットされる権利情報に依存し得る。

各セッションには、セッションインスタンスを得るために他のコンテクストに使用できる独特なｉｄが指定される。いかなる関係者もセッションにアタッチすることができるが、種々の実施形態では、セッションは、全ての関係者がそこからデタッチするまで持続する。更に別の実施形態では、セッションは、そのアタッチされた関係者がもはや存在しないか又はインアクティブであることをシステムが検出したときにそのリソースを自動的に開放することができる。これら実施形態の態様において、ある関係者がセッションからデタッチしたときに、そのセッションにアタッチしている他の関係者に通知することができ、従って、それらは、そこからデタッチするか又は他のアクションをとる機会をもつことができる。

種々の実施形態において、シナリオ制御は、次の機能を与えることができる。
−シナリオセッションを生成しそしてそれに対応するシナリオセッションｉｄを与える。
−シナリオセッションにアタッチしそしてそこからデタッチする。
−共有ステート値を記憶し、検索しそして削除する。
−デフォールト関係者を結合する。
−関係者ｉｄを関係者に指定する。
−メッセージングアクティビティのためにＭｅｓｓａｇｅＣｏｎｔｒｏｌにより使用されるべき関係者ｉｄを与える。
−シナリオ内で使用されるべきパースされた入力引数のセットを与える。これらの引数は、ビジネスプロセスを発生したＨＴＴＰ要求から到来し得る。
−シナリオユーザをシナリオエイリアスに結合する。
−シナリオグループをシナリオグループエイリアスに結合する。

種々の実施形態において、共有ステート機能は、識別子を使用して、共有ステートデータを含む持続マップにアクセスする共有ステート制御として表面化することができる。制御は、関係者がシナリオセッション内の共通の情報セットにアクセスしそしてそれを共有するのを許す。例えば、シナリオがドキュメントレビュープロセスのコンセプトに関して構築される場合、共有ステートの１つのコンポーネントは、コンテンツマネージメントシステムにおけるドキュメントへのリファレンスとなり得る。これら実施形態の態様において、共有ステート制御は、関係者がシリアル化可能なオブジェクトをストリングキーに関連付けるのを許す持続収集機能をサポートする。関係者は、適切な持続マップを探索しそしてロードのために制御により使用されるシナリオセッションｉｄをリファレンスする。

説明上、ビジネスプロセスは、通常、セッションの共有ステートをポピュレートし、一方、ページフローは、通常、共有ステートに関連した情報をＨＴＭＬドキュメントにレンダリングするためにその共有ステートから消費する。又、他のエンティティも、それらがセッションｉｄを得る手段をもつ限り、共有ステート制御を使用することができる。これは、ＨＴＴＰ要求を実行するのではなく、メッセージングレイヤーを使用して帯域外のデータを検索するクライアントプロセスからの非同期データ要求を取り扱うのに有用となる。

種々の実施形態において、共有ステート制御は、次の機能を与えることができる。
−制御を、セッションｉｄに基づくセッションに結合する。
−シナリオセッションを生成しそしてそれに対応するシナリオセッションｉｄを与える。
−シナリオセッションにアタッチしそしてそこからデタッチする。
−共有ステート値を記憶し、検索し、そして削除する。
−全ての現在値キーを含むセットを返送する。

共有ステートは、コラボレーションプロセスの全ライフサイクル中持続できると共に、フェイルオーバー及び負荷バランスの目的でサーバークラスター内のいかなるノードからアクセスすることもできる。

種々の実施形態において、共有ステート制御は、コンテンツレポジトリー又はコンテンツマネージメントシステムにおけるドキュメント及びライフサイクルへのレファレンスを操作するのに使用できる。これは、共有情報がシナリオセッションより長く生きるのを許す。というのは、それが個別のシステムに存在するからである。コンテンツレポジトリーは、構造化コンテンツ及び非構造化コンテンツ（例えば、デジタルで走査されるペーパードキュメント、ＸＭＬ、ポータブルドキュメントフォーマット、ＨＴＭＬ、電子メール、イメージ、ビデオ及びオーディオストリーム、生のバイナリーデータ、等）を、サーチ可能なコーパスに関連付けることができる。コンテンツレポジトリーは、コンテンツマネージメントシステムに結合し又はそれと一体化することができる。コンテンツマネージメントシステムは、コンテンツライフサイクルマネージメント、バージョニング、コンテンツ再検討及び承認、自動コンテンツ分類、事象駆動のコンテンツ処理、プロセス追跡、及び他のシステムへのコンテンツ配送を行うことができる。

種々の実施形態において、クライアントは、エンドユーザと１つ以上のコラボレーションプロセスとの対話をサポートすることができる。これら実施形態の態様において、クライアントプロセスは、ユーザインターフェイスも与えることができる。非限定例として、ユーザインターフェイスは、次のものの１つ以上を含むことができる。１）ディスプレイ装置にレンダリングされるか又はユーザの網膜に投影されるグラフィックユーザインターフェイス（ＧＵＩ）（例えば、ハイパーテキストマークアップ言語でレンダリングされる）；２）サウンド及び／又はボイスコマンドに応答する能力；３）リモートコントロール装置（例えば、セルラー電話、ＰＤＡ、又は他の適当なリモートコントロール）からの入力に応答する能力；４）ジェスチャー（例えば、顔面等）に応答する能力；５）同じ又は別のコンピューティング装置のプロセスからのコマンドに応答する能力；及び６）コンピュータマウス及び／又はキーボードからの入力に応答する能力。この開示は、特定のＵＩに限定されない。当業者であれば、本開示の精神及び範囲内で多数の他のユーザインターフェイスも考えられることが明らかであろう。これら実施形態の態様において、１つのこのようなユーザインターフェイスは、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）コーポレーションから入手できるＭｉｃｒｏｓｏｆｔ（登録商標）インターネットエクスプローラのようなウェブブラウザの助けでレンダリングすることができる。

一実施形態において、クライアントプロセスは、ミニマリストＪａｖａＳｃｒｉｐｔ／ａｐｐｌｅｔを使用して実施することができる。この実施形態は、ウェブページ内に埋め込まれたＪａｖａ（登録商標）アプレット及びＪａｖａＳｃｒｉｐｔ機能の組み合せを使用して、コラボレーション機能をイネーブルすることができる。アプレットは、メッセージングレイヤーを経てメッセージを送信及び受信することができる。シナリオメッセージが到着すると、アプレットは、メッセージを取り扱うためにページのＪａｖａＳｃｒｉｐｔ機能をコールすることができる。ページに埋め込まれたＪａｖａＳｃｒｉｐｔは、ユーザインターフェイス更新、ユーザ対話、データ取り扱い、及びメッセージ送信（アプレットを経て）を全て行う役割を果たすことができる。この解決策の１つの効果は、ウェブブラウザの変更を必要としないことである。

別の実施形態では、重量のクライアントを、ブラウザヘルパーで増大されるか又はその目的でプラグインされたウェブブラウザ内で、又はそれに関連して、ダウンロードして実行することができる。クライアント側のプログラミングモデルは、クライアント側のページフローと、全アプリケーションを実行するための能力のリッチセットとを備え、これは、潜在的にサーバーとの対話を伴わずに多数のページで構成される。非同期通信は、シナリオに必要な事象の両方向通知を許す。クライアントは、持続的又は半持続的データ記憶の効果を得ることができる。クライアント内のユーザインターフェイスエレメントは、制御を使用して表わすことができると共に、ローカルデータ記憶に結合することができる（直接的、又はスクリプトを経て間接的に）。再使用可能な制御は、コードの再使用及びストリームラインアプリケーション開発を最大にする。

更に別の実施形態では、軽量のクライアントを、ブラウザヘルパーで増大されるか又はその目的でプラグインされたウェブブラウザ内で、又はそれに関連して、ダウンロードして実行することができる。ブラウザヘルパーは、ページに埋め込まれたダイナミックＨＴＭＬ（ＤＨＴＭＬ）及びＪａｖａＳｃｒｉｐｔと共に作用して、クライアントデータ記憶装置に結合される非同期通信及びユーザインターフェイスデータを与える。クライアント側のプログラミングモデルは、クライアント側のページフローを含まない。コラボレーションプロセスは、ページの再ロードを強制せずに、新たなＪａｖａＳｃｒｉｐｔをブラウザへプッシュダウンすることができ、そしてクライアントは、ＨＴＭＬドキュメントにおいて異なるＤＩＶセクションをアクチベートすることによりコンテンツの多数の「ページ」を示すことができる。クライアント内のユーザインターフェイスエレメントのドキュメントオブジェクトモデル（ＤＯＭ）は、ユーザインターフェイスエレメントを読み取って操作するのに使用できる。データは、ローカルデータ記憶装置から必要に応じてＤＯＭプロパティに結合することができる。

図８は、本発明の種々の実施形態におけるウェブブラウザ及びアプリケーションサーバーを例示する。この図は、コンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。当業者に明らかなように、この図に示すコンポーネントは、結合することもできるし、又は個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントに分割することもできる。更に、当業者に明らかなように、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピュータ装置間に分布させることもできる。

この説明において、アプリケーションサーバー８３０は、コラボレーションプロセス８００、８０２及び８０４を備え、これらは全て同時に実行することができる。クライアントウェブブラウザ８３２は、１つ以上のリッチＵＩクライアント８２４、８２６及び８２８を備え、これらも、同時に実行することができる。関係者と関係者との間の通信は、メッセージングレイヤー８０８によりサポートされる。先に述べたように、メッセージングレイヤーは、異なる通信プロバイダーが関係者に均一にサービスを提供するのを許す拡張可能な通信プラットホームを与える。この図には示されていないが、メッセージングプロバイダーは、関係者が多数のそして異なる基礎的な通信チャンネルを利用するのを許す。

これら実施形態の態様において、コラボレーションプロセスは、メッセージングレイヤーを経てメッセージを送信及び受信するためにメッセージマネージャー８０６に登録される。登録の後、メッセージマネージャーは、ルーティング情報をコラボレーションプロセスに与えることができ、次いで、該プロセスは、その情報を、それとの通信を希望する関係者へ与えることができる。これら実施形態の態様において、ルーティング情報は、コラボレーションプロセスに対してクライアントが行う第１の要求に応答して埋め込むことができる。ルーティング情報は、コラボレーションプロセスに対するルーティングｉｄと、それとの通信を確立するために関係者により要求される他の情報とを含むことができる。更に別の態様において、ルーティング情報は、ＸＭＰＰサーバーの名前と、サーバーに対して使用すべきＩＭ識別子とを含むことができる。メッセージルーティングの目的で、メッセージマネージャーは、一時的又は持続的マップ８１０においてクライアントプロセスのルーティングｉｄと、それに対応するユニバーサルリソース識別子（ＵＲＩ）との間の関連性を維持することができる。これら実施形態の態様において、メッセージマネージャーは、関係者からメッセージを受け取るときにマップをポピュレートすることができる（例えば、メッセージングレイヤーからソースＵＲＩを、そしてメッセージそれ自体からソースルーティングｉｄを得る）。マップは、メッセージの送信時に関係者のＵＲＩをルックアップするためにメッセージマネージャーにより使用することができる。

メッセージマネージャーは、コラボレーションプロセスから出て行くメッセージを受け容れ、そしてそれらをメッセージングレイヤーに与える。メッセージマネージャーは、コラボレーションプロセスのルーティング情報、行先関係者のルーティング情報（例えば、存在制御又はメッセージングレイヤーＡＰＩから得た）、及びメッセージコンテンツに基づいてメッセージを構成することができる。これら実施形態の態様において、デフォールト通信プロバイダーは、メッセージを送信するのに使用できる。更に別の態様において、デフォールト通信プロバイダーは、行先関係者が使用するＸＭＰＰサーバーを経てメッセージを送信することができる。又、メッセージマネージャーは、メッセージングレイヤーから到来するメッセージを受け容れそしてそれらを適切なコラボレーションプロセス（１つ又は複数）へルーティングすることができる。

種々の実施形態において、メッセージマネージャーは、メッセージングレイヤーの通信プロバイダーをその初期化の一部分としてインスタンス生成することができる。ＸＭＰＰサーバーに接続するときに使用すべきＸＭＰＰサーバーアドレス及びＩＭ識別子のようなコンフィギュレーション情報を各プロバイダーに供給することができる。当業者であれば、本開示は、コンフィギュレーション情報を搬送するための特定の手段に依存せず又はそれに限定されず、且つ多数のこのような仕方が本開示の精神及び範囲内で存在することが明らかであろう。又、コンフィギュレーション情報は、１つのプロバイダーをデフォールトトランスポートとして指定することもできる。

種々の実施形態において、ウェブブラウザヘルパー８１６（例えば、非同期通信を与えそして情報を表示するためのブラウザプラグイン又は他の適当な手段）は、リッチＵＩとコラボレーションプロセスとの間の非同期通信を容易にすることができる。ブラウザヘルパーは、コラボレーションプロセスが、例えば、現在ウェブページを再ロードさせることなく、ウェブブラウザにコンテンツをプッシュするのを許す。ブラウザヘルパーは、メッセージをリッチＵＩクライアントへ／からルーティングできると共に、メッセージングレイヤーを初期化できるという点で、サーバーのメッセージマネージャーと同様に機能する。これら実施形態の態様において、ブラウザヘルパーは、そのホストブラウザのスクリプトエンジンへ露出され、従って、リッチＵＩイネーブルページがロードされるか又はメッセージを送信する必要があるときにそれが呼び出されるようにする。

説明上、リッチＵＩクライアントは、コラボレーションプロセスから表示すべきデータレコードの初期セットを受け取り、そしてデータセットが変化するときに、コラボレーションプロセスは、更新されたデータをリッチＵＩクライアントに送信することができる。更新されたデータが到着すると、リッチＵＩクライアントは、データを合体するようにそのユーザインターフェイスを更新することができる。種々の実施形態において、グラフィックユーザインターフェイスは、ＤＨＴＭＬを使用することにより適切に更新することができる。又、コラボレーションプロセスは、例えば、エンドユーザにある事象を通知する必要がある場合に、実行可能なコード（例えば、インストラクション）をクライアントに送信するように選択を行ってもよい。これら実施形態の態様において、コラボレーションプロセスは、エンドユーザのウェブページの何かをハイライトするためのカスタムＪａｖａＳｃｒｉｐｔ機能を発生するか、又は警告ボックスを表示し、次いで、その機能を実行するためのインストラクションと非同期でリッチＵＩクライアントにコードを送信することができる。

これら実施形態の態様において、ブラウザヘルパーは、ルーティング情報８２０を使用してコラボレーションプロセスとメッセージを交換することができる。当業者であれば、本開示は、ルーティング情報を搬送するための特定の手段に依存せず又はそれに限定されず、且つ多数のこのような仕方が本開示の精神及び範囲内で存在することが明らかであろう。メッセージルーティングの目的で、ブラウザヘルパーは、一時的又は持続的マップ８２０においてコラボレーションプロセスのルーティングｉｄと、それに対応するユニバーサルリソース識別子（ＵＲＩ）との間の関連性を維持することができる。これら実施形態の態様において、ブラウザヘルパーは、コラボレーションプロセスからメッセージを受け取るときにマップをポピュレートすることができる（例えば、メッセージングレイヤーからソースＵＲＩを、そしてメッセージそれ自体からソースルーティングｉｄを得る）。マップは、メッセージの送信時にコラボレーションプロセスのＵＲＩをルックアップするためにブラウザヘルパーにより使用することができる。

ブラウザヘルパーは、メッセージを受信すると、メッセージからルーティング情報を抽出すると共に、メッセージ本体と、それを送信した関係者のルーティング情報とでリッチＵＩクライアントを呼び出すことができる（例えば、スクリプトメソッドを経て）。これら実施形態の更に別の態様において、ブラウザヘルパーは、ＸＰａｔｈと称されるオープンソースＣ＋＋ＸＭＬパージングライブラリーを使用して、到来するメッセージをパースすることができる。これら実施形態の態様において、リッチＵＩクライアントは、スコープト(scoped)ＪａｖａＳｃｒｉｐｔメソッド及びＤＨＴＭＬディスプレイコンポーネントとして表わすことができる。各リッチＵＩクライアントは、それ自身のアプリケーションｉｄを有し、そしてそれが通信するコラボレーションプロセスのアプリケーションｉｄが分かる。所与のリッチＵＩクライアントは、２つ以上のコラボレーションプロセスと通信することができ、そしてそれと逆のことも言える。メッセージに応答するために、リッチＵＩクライアントは、ブラウザヘルパーにおけるメソッドを呼び出し、そしてそれに、メッセージ本体と、行先関係者のルーティング情報とを与えることができる。次いで、ヘルパーは、この情報に基づいてメッセージを構成し、そしてメッセージングレイヤーを経て行先関係者へそれを送信する。

種々の実施形態において、関係者と関係者との間に送信されるメッセージは、いかなるフォーマットでいかなるプロトコルを使用していかなる情報を含むこともできる。これら実施形態の態様において、ＸＭＬフラグメントは、関係者を行先とする情報ペイロードと共にルーティング情報を含むことができる。これら実施形態の更に別の態様において、ルーティング情報は、ソースのアプリケーションｉｄを含むと共に、ある場合には、そのアプリケーションにより使用されるＩＭ識別子を含むことができる。ペイロードは、メッセージに含まれた情報の形式を行先関係者に指示する形式フィールドを含むことができる。

図９は、本発明の種々の実施形態に基づくリッチＵＩクライアント初期化のフローチャートである。この図は、説明上、機能的ステップを特定の順序で示しているが、プロセスは、必ずしも、ステップの特定の順序又は配列に限定されるものではない。当業者であれば、この図に示された種々のステップは、省略し、再配列し、並列に実行し、組み合せ、及び／又は種々の仕方で適応できることが明らかであろう。

ステップ９００において、リッチＵＩクライアントは、ウェブブラウザへ送信されるウェブページにおいてレンダリングされることが決定される。（所与のページにはリッチＵＩクライアントが２つ以上存在することがあり、この場合、このフローチャートのステップを各々のクライアントに対して実行できることに注意されたい。）この決定がなされると（例えば、ＪＳＰタグ又は他の証拠の使用を検出することにより）、システムは、ステップ９０２において初期化する上でリッチＵＩクライアントを助けるためにページに情報を含ませ又は「埋め込む」ことができる。これら実施形態の態様において、この情報は、表２に示すパラメータの幾つか又は全部を含むことができる。この情報は、「リッチＵＩヘッダー」と称されるもので、所与のページにおける各リッチＵＩクライアントに対して一度含ませることができる。

表２：種々の実施形態におけるリッチＵＩヘッダー情報の例

このページがウェブブラウザにより受信されると、リッチＵＩクライアントは、ステップ９０４において、ブラウザヘルパーにより初期化することができる。これに付随して、与えられた通信プロトコル及びコンフィギュレーションパラメータに基づいてメッセージングレイヤーを初期化することができる。時間切れ周期が指定された場合には、ブラウザヘルパーが、オープンしている通信セッションを閉じ及び／又はシナリオセッションからデタッチするまでに経過しなければならないインアクティビティの周期を決定する。これら実施形態の態様において、有効なアクティビティは、エンドユーザとウェブブラウザ又は他のユーザインターフェイスとの対話、ウェブブラウザのアクティビティ（例えば、ページロード、リフレッシュ、再指向、等）、及び送信又は受信されるアプリケーション／フレームワークメッセージを含むことができる。更に、シードデータが存在する場合には、それをデータ記憶装置８１４に入れることができ、このデータ記憶装置は、ブラウザヘルパー及び全てのリッチＵＩクライアントによりアクセスすることができる。コラボレーションプロセスのルーティングｉｄが存在する場合には、ステップ９０６において、新たに初期化されるリッチＵＩクライアントをそれに関連付けることができる。最終的に、リッチＵＩクライアントは、ステップ９０８において、ウェブブラウザでレンダリングすることができる。

これらの実施形態の態様において、リッチＵＩクライアントは、初期化されると、ブラウザヘルパーを経てメッセージを受信及び送信することができる。メッセージは、ソース及び行先ルーティングｉｄを含むエンベロープでカプセル化することができ、この場合、行先ルーティングｉｄは、メッセージの最終的な行先を指定する。ブラウザヘルパーにより受信されたメッセージは、アプリケーションメッセージ、及びフレームワークメッセージ、の２つのカテゴリーに入る。アプリケーションメッセージは、リッチＵＩクライアントのためのもので、一方、フレームワークメッセージは、ブラウザヘルパーそれ自身により消費されるもので、関係者の制御に使用される。これら実施形態の更に別の態様において、フレームワークメッセージの一形式は、ブラウザヘルパーが全てのリッチＵＩクライアントを終了させると共に、シナリオセッションからデタッチさせる。フレームワークメッセージは、たとえブラウザが「オフサイト」ページを現在表示しているか又はページ遷移状態にあっても、ブラウザヘルパーにより常時受信して処理することができる。

種々の実施形態において、説明上、ページ遷移がブラウザにおいて生じると、ブラウザヘルパーは、リッチＵＩクライアントがそれらのシナリオセッション（もしあれば）にアタッチされたままになるのを許す。ブラウザヘルパーにより受信される全てのアプリケーションメッセージは、後で検査するために待ち行列８２２に入れられる。しかしながら、ページ遷移中に受信されるフレームワークメッセージは、ブラウザヘルパーにより直ちに処理することができる。新たなページがブラウザによりロードされると、ブラウザヘルパーは、関係者ｉｄに対してそれを検査する。これら実施形態の態様において、ブラウザヘルパーは、図１０に示すように、新たなページに対して反応する。

図１０は、本発明の種々の実施形態に基づくリッチＵＩクライアント初期化のフローチャートである。この図は、説明上、機能的ステップを特定の順序で示しているが、プロセスは、必ずしも、ステップの特定の順序又は配列に限定されるものではない。当業者であれば、この図に示された種々のステップは、省略し、再配列し、並列に実行し、組み合せ、及び／又は種々の仕方で適応できることが明らかであろう。

ヘッダー情報に加えて、ブラウザに送信されるページは、リッチＵＩヘッダーを含まないページにおけるウェブブラウザの関係者ｉｄを含むことができ、従って、ブラウザヘルパーは、そのリッチＵＩクライアントのステートを維持することができる。ページ遷移の際に、アクティブなリッチＵＩクライアントが保留され、そしてステップ１０００において、新たなページが検査される。ページにエンコードされた関係者ｉｄがない場合には（１００２）、ブラウザヘルパーは、ステップ１００８において、「オフサイトブラウジング」モードに入る。これは、ブラウザが予期せずに外部のウェブサイトに再指向された場合、又はユーザが、リッチＵＩに対してイネーブルされないウェブサイトの一部分に入る場合に、生じ得る。オフサイトブラウジングモードにあるときに、ブラウザヘルパーは、そのリッチＵＩクライアントが依存するところのメッセージングレイヤー通信セッションを維持することができる。受信した全てのアプリケーションメッセージは、廃棄するか、又は後で処理するために待ち行列に入れることができるが、フレームワークメッセージは、直ちに処理することができる。

ステップ１０１６において、ブラウザヘルパーは、ページがブラウザへ埋め込まれた関係者ｉｄと共にロードされるのを待機するか、又は時間切れが生じるのを待機する。時間切れが生じる前に、ページがブラウザへ埋め込まれた関係者ｉｄと共にロードされた場合には、オフサイトブラウジングモードが終了となり、ステップ１０００において処理が再開される。さもなければ、ステップ１０１８において、メッセージングレイヤー通信セッション及び／又はシナリオセッションを閉じ及び／又はデタッチすることができる。

ステップ１００４は、新たなページにエンコードされた関係者ｉｄが現在使用中の関係者ｉｄに一致しない場合に適用される。非限定例として、これは、ユーザがウェブページを適切に去らず、同じページにブラウズして戻るようにマネージするときに生じ得る。この場合に、リッチＵＩクライアントにより使用されるメッセージングレイヤー通信セッション及び／又はシナリオセッションを、ステップ１０１０において、閉じ及び／又はデタッチすることができる。更に、待ち行列８２２のメッセージを廃棄することもできる。ステップ１０１４において、ブラウザヘルパーは、もしあれば、新たなページにエンコードされた情報を使用して新たなメッセージングレイヤー通信セッションを開始する。

ステップ１００６において、新たなページにエンコードされた関係者ｉｄが現在の関係者ｉｄに一致する場合には、ブラウザヘルパーは、新たなページを検査して、どのリッチＵＩクライアントが存在するか決定することができる。各クライアントは、ステップ１０１２において初期化することができる。次いで、待ち行列８２２のアプリケーションメッセージは、適当なリッチＵＩクライアント（１つ又は複数）により受信順に（又はプライオリティ順に）処理することができる。一実施形態では、新たなページに存在しないリッチＵＩクライアントへ送信されるメッセージが廃棄される。

各クライアントプロセスは、１つ以上のコラボレーションプロセスに関連付けることができる。これら実施形態の態様において、クライアントプロセス（例えば、リッチＵＩプロセス）は、それらの振舞いをある程度支配するステートを有する。説明上、以下の表３にステートの例を示す。

表３：種々の実施形態におけるクライアントプロセスステートの例

種々の実施形態において、同じウェブブラウザのリッチＵＩクライアントは、互いにメッセージを送信及び受信することができる。一実施形態では、これは、メッセージングレイヤーにループバック機能を追加することにより達成でき、ここで、メッセージングレイヤーは、ルーティングｉｄがローカルである（即ち、メッセージングレイヤーのプロセススペースにおいてリッチＵＩクライアントを識別する）かどうか検出することができる。行先ルーティングｉｄがローカルであるメッセージは、チャンネルを経てメッセージを送信せずにローカル行先リッチＵＩクライアントへメッセージを配送することによりブラウザへ「ループバック」される。別の実施形態では、ブラウザヘルパーは、それ自体、ローカル通信がメッセージングレイヤーに到達する前にそれをキャッチして再指向することができる。関係者の観点から、ローカル通信のための通信メカニズムには認識できるような相違は必要とされない。

種々の実施形態において、クライアントプロセスがアクティブステートであるときに、それは、「関連付け」又は「非関連付け」と考えてもよい。非関連付けのクライアントプロセスは、現在、コラボレーションプロセスに関連付けされていない。一実施形態では、それらは、コラボレーションプロセスからメッセージを受信してもよいが、コラボレーションプロセスへメッセージを送信することはできない。コラボレーションプロセスからメッセージを受信する非関連付けのクライアントプロセスは、それら自体をメッセージ送信者に関連付けるように常に選択することができる。種々の実施形態において、関連付けのクライアントプロセスは、単一のコラボレーションプロセスに関連付けされて、クライアントプロセスから送信されたメッセージをその特定のコラボレーションプロセスに自動的に向けることができる（例えば、ブラウザヘルパー又は他の適当な手段により）。関連付けされるかどうかに関わらず、クライアントプロセスは、同じプロセススペース内でメッセージを他のクライアントプロセスへ送信し及びそこから受信することができると共に、それに関連付けされたものだけではない任意のコラボレーションプロセスからメッセージを受信することができる。

種々の実施形態において、ブラウザヘルパーは、各関連付けされたクライアントプロセス（例えば、リッチＵＩクライアント）のコラボレーションプロセスに対してルーティングｉｄを追跡する役割を果たす。これら実施形態の態様において、ブラウザヘルパーは、そのリッチＵＩクライアントへの機能を与えることができる。この機能は、ヘルパーにより任意の仕方で実施できるが、一実施形態では、リッチＵＩクライアントがコールできるコール可能なＪａｖａＳｃｒｉｐｔファンクション、及びヘルパー呼び出しのリッチＵＩクライアントファンクションコールバックとして実施できる。更に別の態様では、リッチＵＩクライアント開始の機能は、リッチＵＩクライアントがコールできるファンクションとして表わされ、そしてブラウザヘルパー開始の機能は、ヘルパーがリッチＵＩクライアントにおいて呼び出すファンクション、メソッド、又は起きた「事象」により表わすことができる。種々の実施形態では、クライアント開始の機能は、次のものを含むことができる。

−クライアントプロセスをコラボレーションクライアントプロセスのルーティングｉｄに関連付ける能力。これは、クライアントプロセスを「関連付け」ステートに入れる。クライアントプロセスが別のルーティングｉｄに既に関連付けされている場合には、新たに指定されたルーティングｉｄがクライアントプロセスの新たなデフォールト通信エンドポイントとなる。
−クライアントプロセスとコラボレーションプロセスとの関連付けが存在する場合に、そのような関連付けを除去する能力。これは、クライアントプロセスのインスタンスを「非関連付け」ステートに入れる。
−関連付けされたコラボレーションプロセスへメッセージを送信する能力。
−同じプロセススペース（例えば、同じウェブブラウザ）における別のクライアントプロセスへメッセージを送信する能力。

種々の実施形態において、ブラウザヘルパー開始の機能は、次のものを含むことができる。
−クライアント開始機能のいずれか。
−クライアントプロセスインスタンスを初めて初期化するか、又はそのデータ記憶装置がコラボレーションプロセスによりリセットされた後に初期化する能力。
−ページリフレッシュの後にクライアントプロセスインスタンスを初期化する能力。
−クライアントプロセスを保留するか又はアンロードする能力。
−コラボレーションプロセス又は別のクライアントプロセスにより送信されたクライアントプロセスへ送信されるメッセージを配送する能力。

図１１は、本発明の種々の実施形態に基づくリッチＵＩクライアントページローディングのフローチャートである。この図は、説明上、機能的ステップを特定の順序で示しているが、プロセスは、必ずしも、ステップの特定の順序又は配列に限定されるものではない。当業者であれば、この図に示された種々のステップは、省略し、再配列し、並列に実行し、組み合せ、及び／又は種々の仕方で適応できることが明らかであろう。所与のページにはリッチＵＩヘッダーが２つ以上の存在することがあり、この場合に、このフローチャートのステップは、このような各ヘッダーに対して実行することができる。図９及びそれに付随する説明を参照されたい。

種々の実施形態において、新たなページがブラウザにロードされると、ブラウザヘルパーは、リッチＵＩクライアントが適切に動作することを保証する役割を果たす。ステップ１１００において、ルーティングｉｄがリッチＵＩヘッダーに見つかると、それに対応するリッチＵＩクライアントがルーティングｉｄに関連付けられる。ステップ１１０２において、リッチＵＩヘッダーで指定されたアプリケーションｉｄが、保留されたリッチＵＩクライアントのアプリケーションｉｄに一致すると、ステップ１１０４において、ヘッダーがシードデータを含むかどうか決定される。もしそうであれば、データは、ステップ１１０８において、データ記憶装置にコピーされる。このコピーは、そのクライアントに対する既存のシードデータに置き換わる。もしそうでなければ、このステップは、スキップされる。ステップ１１１２において、保留されたリッチＵＩクライアントが、保留ステートから出される。ステップ１１１６において、現在アクティブなリッチＵＩクライアントは、リッチＵＩクライアントが保留されていた間に待ち行列に入れられていたものを含むメッセージを送信及び受信することができる。ステップ１１０３において、リッチＵＩヘッダーのアプリケーションＩＤは、保留されたクライアントのアプリケーションＩＤに一致しない。ステップ１１０６において、ヘッダーがシードデータを含むかどうか決定される。もしそうであれば、データが、ステップ１１０８において、データ記憶装置へコピーされる。もしそうでなければ、このステップは、スキップされる。ステップ１１１４において、リッチＵＩクライアントが生成されそして初期化される。

種々の実施形態において、上述したシステム及び方法は、無制限の様々なシナリオをアッセンブルするのに使用できる。説明上、１つのこのようなシナリオは、顧客コールセンターである。このアプリケーションでは、顧客サービス代表者（ＣＳＲ）は、顧客からのコールを受けて種々のアクションを実行するというタスクをもつ。１つのこのようなアクションは、顧客が払い戻しを希望する場合の払い戻し要求である。この例では、経験が６ヶ月未満のＣＳＲは、マネージャーのリアルタイムの承認なしに、＄１０００．００を越える金額の払い戻しを処理することができない。クライアントプロセス（例えば、リッチＵＩクライアント）を使用することにより、ＣＳＲは、支援を受けるためにリアルタイムでマネージャーにコンタクトすることができる。又、マネージャーは、「ヘルパー」クライアントと称するクライアントプロセス（例えば、リッチＵＩクライアント）も使用し、これは、彼等が多数の異なるＣＳＲとの多数の「会話」に関与するのを許す。各会話は、ＣＳＲ−マネージャー接続をマネージするコラボレーションプロセスにより表わされる。

ＣＳＲクライアントプロセスがヘルプを要求すると、コラボレーションプロセスが生成される（まだ退出していない場合）。コラボレーションプロセスは、存在情報を使用することにより、ヘルパークライアントを実行する利用可能なマネージャーを動的に探索することができる。コラボレーションプロセスと通信するために、マネージャーのヘルパークライアントは、それ自身をコラボレーションプロセスのルーティングｉｄに関連付けることができる。クライアントプロセスは、いつでもコラボレーションプロセスからメッセージを受信できるので、コラボレーションプロセスは、ヘルプを要求するためのメッセージをマネージャーヘルパークライアントに送信することができる。個々のヘルパークライアントは、その要求メッセージを評価し、そしてそれら自体をコラボレーションプロセスに関連付けるべきかどうか選択することができる。ヘルプセッションが完了すると、マネージャーのヘルパークライアントは、コラボレーションプロセスから解離してもよいし又は必要に応じて別のものと再関連付けしてもよい。

これら実施形態の態様において、コラボレーションプロセスとの関連付け（又は再関連付け）に関するクライアントベースの判断をサポートするために、クライアントは、サーバーからの関連付け要求を受け取って評価する役割を果たす。サーバーは、クライアントへ送信される関連付け要求に任意のデータを含んでもよいので、関連付け要求メッセージに対する標準的な形態はない。むしろ、クライアントにより受信されるメッセージは、潜在的に、関連付け要求であり、クライアントは、ブラウザヘルパーにより与えられる関連付け機能を呼び出すことによりそれ自身の判断で関連付け（又は再関連付け）することができる。

図１２ａ−ｃは、本発明の種々の実施形態に基づくコラボレーション顧客コールセンターシナリオを例示する図である。この図は、コンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。当業者に明らかなように、この図に示すコンポーネントは、結合することもできるし、又は個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントに分割することもできる。更に、当業者に明らかなように、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピューティング装置間に分布させることもできる。

図１２ａには、３つのリッチＵＩクライアント（「Ａ」、「Ｂ」及び「Ｃ」）と、２つのコラボレーションプロセス（「１」及び「２」）とが示されている。点線の包囲は、２つの間の関連付けを指示するのに使用される。例えば、クライアント「Ａ」は、コラボレーションプロセス「１」に関連付けされ、一方、クライアント「Ｂ」は、コラボレーションプロセス「２」に関連付けられる。クライアント「Ｃ」は、非関連付けである。各リッチＵＩプロセスは、同じウェブブラウザを共有することもできるし、又は異なるブラウザを利用することもできる。

このシナリオにおいて、クライアント「Ｂ」と対話しているエンドユーザＣＳＲが顧客からのコールを受ける。ＣＳＲは、氏名と、コールに関するある詳細とを含む顧客情報を収集することができる。この情報は、共有ステート制御の使用によりシナリオセッションの共有ステートに入れることができる。次いで、顧客が＄１０００を越える金額の払い戻しを要求し、そしてＣＳＲが経験６ヶ月未満である場合には、クライアント「Ｂ」は、マネージャーと関連付けして承認を得るように試みる。この場合に、「Ｂ」は、ヘルプ要求（例えば、メッセージ制御を使用する）をコラボレーションプロセス「２」へ送信する。コラボレーションプロセスは、ユーザがマネージャーで、「利用可能」の存在状態を有し、且つマネージャークライアントを実行させることを要求するロールを使用して、利用可能なマネージャーを探索する。種々の実施形態において、コラボレーションプロセスは、この努力において存在制御を使用することができる。

次いで、コラボレーションプロセスは、メッセージ制御を使用してロールにより識別される利用可能なマネージャーの１つへ関連付け要求を送信する。これら実施形態の態様において、マネージャーがある時間フレーム内に応答する場合には、マネージャーの状態が「ビジー」に変更される。応答がないか又は否定応答の場合には、コラボレーションプロセスは、要求を受け容れるまで、識別されたマネージャーの別の者へ関連付け要求を送信することができる。一実施形態では、コラボレーションプロセスは、関連付け要求を任意の順序で送信することができる。説明上、コラボレーションプロセスは、関連付け要求を、「最もビジーでない」マネージャーに最初に送信することができる。別の実施形態では、コラボレーションプロセスは、オーダリングに続いて関連付け要求を、シナリオ関係者の１つ以上のプロパティに基づいて送信することができる。本開示の精神及び範囲内で他の構成（例えば、ラウンドロビン）も考えられる。

図１２ｂにおいて、マネージャーのクライアント「Ｃ」は、それ自身をコラボレーションプロセス「２」に関連付けている。ここで、クライアント「Ｂ」及び「Ｃ」の両方は、周囲の点線で示されたように、コラボレーションプロセス「２」に関連付けられる。この点において、「Ｂ」は、その払い戻し要求を、コラボレーションプロセス「２」を経て「Ｃ」へ送信することができる。共有ステート制御を使用して、マネージャーのリッチＵＩクライアントは、要求に関する関係情報を検査し、次いで、コラボレーションプロセス「２」を経て「Ｂ」へ肯定又は否定応答することができる。その後、クライアント「Ｂ」及び「Ｃ」は、図１２ｃに示すように、コラボレーションプロセスから解離することができる。

図１２ｃは、クライアント「Ａ」がコラボレーションプロセス「１」からヘルプを要求したことも示している。（「Ａ」は、コラボレーションプロセス「２」からヘルプを要求することもできた。）コラボレーションプロセス「１」は、次いで、マネージャーが存在しそしてマネージャークライアントを実行することを示す。コラボレーションプロセスは、関連付け要求を「Ｃ」へ送信する。「Ｃ」が要求に対して肯定応答する場合には、「Ａ」及び「Ｃ」の両方がコラボレーションプロセス「１」に関連付けされ、従って、ダイアログをもつことができる。

更に、説明上、別の考えられるシナリオは、グループチャットである。このアプリケーションでは、ユーザは、それに対応し得る他のユーザを表示するアクティブな「バディー(buddy)」リストを有する。このバディーリストは、各ユーザの状態（例えば、「オンライン」、「オフライン」、「ビジー」、等）を表示することもできる。又、バディーリストは、存在に基づきルールに従ってユーザを表示するルール駆動でもよい。例えば、ルールは、バディーリスト上の人々が存在し、「オンライン」の状態を有し、そしてロサンジェルスエリアに住んでいることを特定してもよい。任意の基準が考えられる。バディーリストは、そのリストに手動で追加されたユーザ及びルールの組み合せに基づいてもよい。

第２のユーザとチャットするために、第１のユーザは、それらのバディーリストから第２のユーザを選択する。第２のユーザは、次いで、それらがチャットしたいかどうか調べるためにコラボレーションプロセスによりコンタクトされる。もしそうであれば、両ユーザのブラウザ（又は他の適当なアプリケーション）においてチャットウインドウがアクチベートされる。又、第１及び／又は第２のユーザは、各バディーリストから付加的なユーザを選択することによりそれらをチャットに加えることもできる。チャットウインドウは、ユーザがリアルタイムでメッセージを交換するのを許す。種々の実施形態において、各ユーザは、１つおきのユーザのメッセージをそれらのチャットウインドウで見る。これら実施形態の態様において、これは、全てのメッセージをコラボレーションプロセスへ送信し、このコラボレーションプロセスが、次いで、そのメッセージを全ての関連ユーザ（即ちグループチャットに含まれたユーザ）にブロードキャストすることにより達成できる。

チャットに含まれるユーザは、同じシナリオセッションの一部分であるから、それらは全てセッションの共有ステートにアクセスすることができる。共有ステート制御は、ユーザが、それらのメッセージと共に他の種類の情報（例えば、サウンド、映像、ビデオ、ファイル、等）をシームレスに交換することができる。更に別の実施形態では、チャットユーザは、同時にナビゲートできるウェブページの共通ビューを共有することもできる。これら実施形態の態様において、チャットウインドウは、いずれかのユーザがＵＲＬを指定するのを許すテキストフィールド又は他のユーザインターフェイスを有する。ＵＲＬは、指定されると、コラボレーションプロセスを経て全てのユーザへ送信することができる。これは、ＵＲＬをウェブページの各ユーザの共通ビューへロードさせる。

種々の実施形態において、グループチャットは、グループ内のあるユーザから他のユーザへメッセージを中継するように働くコラボレーションプロセスにより容易にされる。チャットクライアントプロセスは、加入すべき新たなユーザを招待するときに、チャット要求をコラボレーションプロセスへ送信し、このコラボレーションプロセスがその招待を新たなユーザへ転送することにより、行うことができる（新たなユーザが利用できそしてチャットクライアントそれ自体を実行していると仮定する）。新たなユーザが招待を断る場合には、コラボレーションプロセスがクライアントプロセスに失敗を通知することができる。さもなければ、新たなユーザは、それ自身をコラボレーションプロセスに関連付け、従って、グループチャットの一部分となる。この点において、新たなユーザは、メッセージをグループに送信すると共に、グループ内の他のユーザからメッセージを受信することができる。

図１３ａ−ｅは、本発明の種々の実施形態に基づくグループチャットシナリオを例示する図である。この図は、コンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。当業者に明らかなように、この図に示すコンポーネントは、結合することもできるし、又は個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントに分割することもできる。更に、当業者に明らかなように、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピューティング装置間に分布させることもできる。

図１３ａには、３つのリッチＵＩグループチャットクライアント（「Ａ」、「Ｂ」及び「Ｃ」）と、２つのグループチャットコラボレーションプロセス（「１」及び「２」）とが示されている。点線の包囲は、２つの間の関連付けを指示するのに使用される。例えば、クライアント「Ａ」は、コラボレーションプロセス「１」に関連付けされ、一方、クライアント「Ｂ」は、コラボレーションプロセス「２」に関連付けられる。クライアント「Ｃ」は、非関連付けである。各リッチＵＩクライアントは、同じウェブブラウザを共有することもできるし、又は異なるブラウザを利用することもできる。

図１３ａを参照すれば、チャットクライアント「Ｂ」と対話するユーザは、２人のユーザをチャットに招待する。これは、クライアント「Ｂ」がそれに代わってユーザを招待するための要求をコラボレーションプロセス「２」に行うようにさせる。コラボレーションプロセスは、これらユーザがチャットクライアント「Ａ」及び「Ｃ」に対応することを決定する。従って、コラボレーションプロセスは、関連付け要求を「Ａ」及び「Ｂ」に送信する。そのいずれからも応答がないか又は否定応答がある場合には、コラボレーションプロセスは、その通知を「Ｂ」へ与えることができる。「Ａ」及び「Ｃ」の一方又は両方が肯定応答する場合には、それら自体をコラボレーションプロセス「２」に関連付ける。これが図１３ｂに示されている。「Ａ」、「Ｂ」又は「Ｃ」によりここで送信されるチャットメッセージは、コラボレーションプロセス「２」によりグループ内の他の者に転送される。

図１３ｃは、クライアント「Ａ」がそれ自身をコラボレーションプロセス「２」から解離するところを示している。これは、チャットからの退出を希望するクライアント「Ａ」のエンドユーザの結果である。図１３ｄは、クライアント「Ａ」がもはやコラボレーションプロセス「２」に関連付けされず、そしてコラボレーションプロセス「１」を経てクライアント「Ｄ」をグループチャットに招待するよう試みるところを示している。クライアント「Ｄ」が招待を受け容れ、そして両クライアントがコラボレーションプロセス「１」に関連付けされる（図１３ｅ）。コラボレーションプロセス「２」により指令されるグループチャットは、コラボレーションプロセス「１」により指令されるグループチャットとは独立している。更に別の実施形態では、クライアントは、２つ以上のコラボレーションプロセスに関連付けることができる。このように、クライアントは、２つ以上のグループチャットに参加することができる。

種々の実施形態は、コンピュータ分野の当業者に明らかなように、本開示の教示に基づいてプログラムされた従来の汎用又は特殊なデジタルコンピュータ又はプロセッサ（１つ又は複数）を使用して実施することができる。ソフトウェア分野の当業者に明らかなように、熟練したプログラマーであれば、本開示の教示に基づいて適切なソフトウェアコードを容易に準備することができよう。又、本発明は、当業者に容易に明らかなように、集積回路を準備するか、又は従来のコンポーネント回路の適切なネットワークを相互接続することにより、実施することもできる。

種々の実施形態は、命令が記憶された記憶媒体（メディア）であると共に／ここに示す特徴のいずれかを実行するように汎用又は特殊なコンピューティングプロセッサ／装置をプログラムするのに使用できるコンピュータプログラム製品を包含する。記憶媒体は、フロッピー（登録商標）ディスク、光学的ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、磁気−光学ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気又は光学カード、ナノシステム（分子メモリ、ＩＣを含む）を含む任意の形式の物理的メディア；ペーパー又はペーパーベースのメディア；並びに命令及び／又はデータを記憶するのに適した任意の形式のメディア又はデバイスを包含し得るが、これらに限定されない。種々の実施形態は、１つ以上のパブリック及び／又はプライベートネットワークを経て送信できるコンピュータプログラム製品を包含し、この送信は、ここに示す特徴のいずれかを実行するようにコンピューティング装置をプログラムするのに使用できるインストラクションを含む。

コンピュータ読み取り可能な媒体（メディア）の１つ以上に記憶されるものであるが、本開示は、汎用／特殊なコンピュータ又はマイクロプロセッサのハードウェアを制御すると共に、コンピュータ又はマイクロプロセッサが本発明の結果を利用して人間のユーザ又は他のメカニズムと対話できるようにするためのソフトウェアも包含する。このようなソフトウェアは、装置ドライバ、オペレーティングシステム、実行環境／コンテナ、及びアプリケーションを含むが、これらに限定されない。

以上、本発明の好ましい実施形態を詳細に説明したが、これは、単なる例示に過ぎない。これは、本発明を余すところなく示すものでもないし、又、ここに開示した正確な形態に制限するものでもない。当業者であれば、多数の変更や修正が明らかであろう。これら実施形態は、本発明の原理及びその実際の応用を説明するために選ばれたものであり、従って、当業者であれば、本発明、種々の実施形態、並びに意図された特定の用途に適する種々の変更を理解することができよう。従って、本発明の範囲は、特許請求の範囲によって限定されるものとする。

本発明の種々の実施形態におけるコラボレーションプロセスのコンポーネント部分を例示する図である。 本発明の種々の実施形態におけるコンポーネント呼び出しの高レベル図である。 本発明の種々の実施形態におけるページフロー制御の流れ及び拡張ポイントを例示する図である。 本発明の種々の実施形態におけるメッセージングレイヤーを例示する図である。 本発明の種々の実施形態におけるシナリオ関係者を例示する図である。 本発明の種々の実施形態における例示的メッセージ制御のクラス図である。 本発明の種々の実施形態における例示的存在制御のクラス図である。 本発明の種々の実施形態におけるウェブブラウザ及びアプリケーションサーバーを例示する図である。 本発明の種々の実施形態に基づくリッチＵＩクライアント初期化のフローチャートである。 本発明の種々の実施形態に基づくリッチＵＩクライアント初期化のフローチャートである。 本発明の種々の実施形態に基づくリッチＵＩクライアントページローディングのフローチャートである。 本発明の種々の実施形態に基づくコラボレーション顧客コールセンターシナリオを例示する図である。 本発明の種々の実施形態に基づくコラボレーション顧客コールセンターシナリオを例示する図である。 本発明の種々の実施形態に基づくコラボレーション顧客コールセンターシナリオを例示する図である。 本発明の種々の実施形態に基づくグループチャットシナリオを例示する図である。 本発明の種々の実施形態に基づくグループチャットシナリオを例示する図である。 本発明の種々の実施形態に基づくグループチャットシナリオを例示する図である。 本発明の種々の実施形態に基づくグループチャットシナリオを例示する図である。 本発明の種々の実施形態に基づくグループチャットシナリオを例示する図である。

Claims (24)

1. 複数の関係者の間のコラボレーション方法において、
   コラボレーションプロセスにコンタクトするステップであって、このコンタクトを第１関係者により行うようなステップと、
   １人以上の潜在的な関係者をロールに基づいて適任とするステップと、
   前記１人以上の潜在的な関係者から第２関係者を選択するステップと、
   前記第２関係者をコラボレーションに参加するように招待するステップと、
   前記第２関係者が前記コラボレーションに参加できるかどうかの指示を受け取るステップと、
   を備えた方法。
2. 前記ロールは動的に評価され、そして前記ロールは存在情報に基づくものである、請求項１に記載の方法。
3. 前記ロールは前記潜在的関係者の１つ以上の属性に基づくものである、請求項１に記載の方法。
4. 前記選択するステップは、最もビジーでない潜在的関係者を選ぶことを含む、請求項１に記載の方法。
5. メッセージングレイヤーを含むコラボレーションプロセスと、
   第１メッセージングレイヤーを含む第１クライアントであって、この第１クライアント及び前記コラボレーションプロセスがそれらの各メッセージングレイヤーを経て通信できるような第１クライアントと、
   第２メッセージングレイヤーを含む第２クライアントであって、各メッセージングレイヤーを経てコラボレーションプロセスと通信できるような第２クライアントと、
   前記第１クライアント及び前記第２クライアントの少なくとも１つを動的に識別するためのロールと、
   を備え、前記ロールは、前記第１クライアント及び前記第２クライアントの少なくとも一方に対する存在情報に基づくものであるコラボレーションシステム。
6. 前記ロールは動的に評価され、そして前記ロールは存在情報に基づくものである、請求項５に記載のシステム。
7. 前記ロールは前記潜在的関係者の１つ以上の属性に基づくものである、請求項５に記載のシステム。
8. コラボレーションを確立する方法において、
   ロールを評価して潜在的関係者のセットを動的に決定するステップと、
   前記潜在的関係者のセットから第１関係者を選択するステップと、
   前記第１関係者をコラボレーションに参加するように招待するステップと、
   前記招待に対する回答を受け取るステップと、
   前記回答が前記コラボレーションへの参加の希望を指示する場合に前記第１関係者を前記コラボレーションに含ませるステップと、
   を備えた方法。
9. 前記ロールは存在及び状態情報に基づくものである、請求項８に記載の方法。
10. 前記第１関係者は、情報を他の関係者と共有できるところの共有ステートにアクセスできる、請求項８に記載の方法。
11. 前記ロールは前記潜在的関係者の１つ以上の属性に基づくものである、請求項８に記載の方法。
12. 前記第１関係者は、ウェブブラウジングを行うことのできるプロセスと一体化される、請求項８に記載の方法。
13. 存在情報を与える方法において、
    ユーザの動的セットを定義するロールを定義するステップであって、前記ユーザのセットは時間と共に変化し得るものであり、且つ前記ロールは前記ユーザのセットの少なくとも１人のメンバーの存在情報に基づくようなステップと、
    加入者により前記ロールに契約するステップであって、前記加入者は、前記ユーザの動的セットに対する変化の通知を受け取るようなステップと、
    前記ユーザの動的セットの変化を加入者に通知するステップと、
    を備え、前記契約するステップは、前記ユーザのセットの少なくとも１人のメンバーから契約の許可を得ることを含むものである方法。
14. 前記ロールは、潜在的メンバー及びメンバーシップ基準のセットにより定義される、請求項１３に記載の方法。
15. 前記ロールは、１つ以上の演算及び／又は論理的表現を含むことができる、請求項１３に記載の方法。
16. コラボレーション中に複数の関係者の間に情報を搬送するステップと、
    プロセスがコラボレーションの一部分を受け持てるようにする機能のセットを露出させるステップと、
    を備え、前記機能のセットは、
    メッセージの送信及び受信を容易にするための第１機能、及び
    ユーザ存在情報の伝播及びユーザ存在の決定を容易にするための第２機能と、
    を含み、前記第２機能は、ロールに基づきユーザ存在を決定するための１つ以上の機能を含み、更に、前記ロールは動的に評価できる、
    というようにした方法。
17. 前記コラボレーションは、ビジネスプロセスにより整合される、請求項１６に記載の方法。
18. 複数の関係者及びビジネスプロセスを伴うインタラクティブなグループチャットを与える方法において、
    前記ビジネスプロセスを開始して、前記複数の関係者を整合するステップと、
    ロールの動的な評価に基づいて前記複数の関係者を決定するステップであって、前記ロールが前記複数の関係者に対する存在情報に基づくものであるようなステップと、
    前記複数の関係者の各々を前記グループチャットに参加させるステップと、
    前記複数の関係者の１人から他の者へメッセージを分配するステップと、
    を備えた方法。
19. 前記ビジネスプロセスは、前記複数の関係者が１つ以上のエンタープライズビジネスシステムと対話するのを許す、請求項１８に記載の方法。
20. 前記複数の関係者の各々は、それらの間で情報を共有できる共有ステートにアクセスできる、請求項１８に記載の方法。
21. 前記複数の関係者の少なくとも１人は、ウェブブラウジングを行うことのできるプロセスと一体化される、請求項１８に記載の方法。
22. 前記ロールの評価に基づいて前記グループチャットに前記関係者を動的に追加するステップを更に備えた、請求項１８に記載の方法。
23. 第１プロセスと通信するステップであって、前記第１プロセスがコラボレーションプロセスであるようなステップと、
    第２プロセスと通信するステップであって、前記第２プロセスが、第１ウェブページをアッセンブルできると共に、複数のウェブページにわたりナビゲーションを動的に制御できるようなステップと、
    前記第１プロセスから受け取った情報を反映するように前記第１ウェブページを更新するステップであって、該更新が第２プロセスとの通信を必要としないようなステップと、
    を備え、前記第２プロセスは、前記複数のウェブページにわたるナビゲーションの流れを動的に変更できるようにした方法。
24. コラボレーション中に複数の関係者の間で情報を共有するステップと、
    前記複数の関係者の中の関係者が情報を共有できるようにする機能のセットを露出させるステップと、
    を備え、前記機能のセットは、
    前記複数の関係者と対話するためのコンテクストの確立を容易にするための第１機能、及び
    共有ステートからの１つ以上の値の検索及び記憶を容易にするための第２機能と、
    を含み、前記共有ステートは前記コンテクスト内でアクセス可能である、
    というようにした方法。

Images