JP2005202926A - 拡張可能リアルタイムコラボレーションシステムのアーキテクチャ - Google Patents

Abstract

【課題】 拡張可能リアルタイムコラボレーションシステムを提供すること。
【解決手段】 アーキテクチャは、アクティビティオブジェクト、エンドポイントオブジェクト、複数のメディアスタックを有する。これらのオブジェクトは、メッセージの送信および受信に、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ ＰｒｏｔｏｃｏｌまたはＲｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌなどの様々な通信プロトコルを使用することができる。アクティビティオブジェクト、エンドポイントオブジェクト、および複数のメディアスタックは、それぞれ、１つまたは複数のＡＰＩを有し、アプリケーション開発者は、このＡＰＩを使用して、コラボレーション関連機能性にアクセスするかこれを提供することができる。
【選択図】 図２

Description

本明細書に記載の技術は、全般的にはデータ通信に関し、具体的には、拡張可能リアルタイムコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）システムのアーキテクチャに関する。

様々な通信アプリケーションおよび通信プロトコルによって、ソフトウェアプログラムまたはユーザの間の通信が可能になる。例として、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）ＭＥＳＳＥＮＧＥＲおよびＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などのリアルタイム通信アプリケーションが、ユーザの間での通信を可能にし、ユーザが互いにテキスト、ビデオ、または音声データを送信できるようになる。これらのアプリケーションは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、およびＲＴＣＰ（Ｒｅａｌ−Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）などの様々なプロトコルを使用して、セッションを確立し、通信関連情報を送信することができる。ＳＩＰは、デバイスがお互いを発見し、デバイスの間のセッションを確立し、修正し、終了するのに使用することができるアプリケーションレイヤ制御プロトコルである。ＲＴＰは、インターネットを介してオーディオおよびビデオを配信するプロトコルであり、しばしば、ＲＴＣＰおよびＨ．３２３などの他のプロトコルと共にストリーミングメディアシステムおよびビデオ会議システムで使用される。ＲＴＣＰは、クライアントアプリケーションが、ＲＴＰを使用して送信または受信されるデータを監視し、制御できるようにするプロトコルであり、ＲＴＰと共に使用される。ＳＩＰおよびＲＴＰ／ＲＴＣＰは、インターネットで提案された標準規格である。その仕様である「ＲＦＣ ３２６１」および「ＲＦＣ ３５５０」は、それぞれ、インターネットで、ｗｗｗ．ｉｅｔｆ．ｏｒｇの／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔおよびｗｗｗ．ｆａｑｓ．ｏｒｇの／ｒｆｃｓ／ｒｆｃ３５５０．ｈｔｍｌで入手できる。

アプリケーションは、さらに、他のプロトコルを使用することができる。アプリケーションは、上で示されたプロトコルの拡張された版を使用することができ、あるいは、特殊化されたデータを担持するように設計された完全に異なるプロトコルを使用することができる。一例として、ビデオ会議情報を担持する新しいまたは改善されたプロトコルが使用可能になる時に、アプリケーションを作成するか修正するアプリケーション開発者は、新しいまたは改善されたプロトコルを使用して、たとえば性能を改善するか追加の特徴を提供することを望む場合がある。新しいまたは改善されたプロトコルを使用するために、アプリケーション開発者は、アプリケーションのうちで通信プロトコルと相互作用する部分を修正する必要がある場合がある。というのは、プロトコルに対する改善または新しいプロトコルが、既に使用されているプロトコルと異なるインターフェースを有する場合があるからである。例として、あるプロトコルが、新しいセッションを作成するＮｅｗＳｅｓｓｉｏｎインターフェースを有する場合があり、改善された版が、セッションを作成し、起動し、追加パラメータを受け入れるＳｔａｒｔＳｅｓｓｉｏｎメソッド（スタートセッションメソッド）を有する場合がある。ＳｔａｒｔＳｅｓｓｉｏｎは、追加パラメータを受け入れるので、そのインターフェースは、ＮｅｗＳｅｓｓｉｏｎ（ニューセッション）と異なり、したがって、ＮｅｗＳｅｓｓｉｏｎを使用するアプリケーションは、ＳｔａｒｔＳｅｓｓｉｏｎを使用するために修正が必要になる場合がある。プロトコルが異なるインターフェースを有する時に、アプリケーション開発者は、異なるインターフェースを習得し、プロトコルを使用するためにこのインターフェースを使用するようにアプリケーションを修正する必要がある場合がある。

アプリケーション開発者は、その開発者が開発するアプリケーションで使用される多数の通信プロトコルのそれぞれに精通する必要がある場合がある。例として、アプリケーション開発者が、ＳＩＰおよびＲＴＰ／ＲＴＣＰを使用する時に、アプリケーション開発者は、プロトコルに関連するプログラムロジックを提供するために、３つのプロトコルのすべてに精通する必要がある場合がある。３つのプロトコルのすべてに精通してはいないアプリケーション開発者は、これらのプロトコルに精通するために追加の訓練および時間を必要とする場合がある。さらに、アプリケーションが、追加のまたは改善されたプロトコルと共に動作するように修正されなければならない時に、アプリケーション開発者は、プログラムロジックを改訂するか追加し、その結果、アプリケーションがこれらのプロトコルと共に機能できるようにする必要がある場合がある。これは、追加の開発出費および問題につながる可能性がある。

さらに、様々なプロトコルが、様々な複雑さを提示する。たとえば、アプリケーションにビデオ会議機能を設けるために、そのアプリケーションの開発者は、複数のプロトコルに精通し、ビデオ会議機能を追加するためにこれらのプロトコルを調整するロジックを提供しなければならない。テキストメッセージング、音声メッセージングなどの他のコラボレーション機能のアプリケーションへの追加は、他の類似する問題を提示する。

したがって、開発者トレーニングへの多くの投資なしでアプリケーションにコラボレーション機能を追加することを容易にする拡張可能リアルタイムコラボレーションシステムのアーキテクチャは、かなりの有用性を有する。

本発明の目的は、拡張可能リアルタイムコラボレーションシステムのアーキテクチャを提供することである。

このアーキテクチャは、通信プロトコルを使用するアプリケーションプログラムを記述する統一されたアプリケーションプログラムインターフェース（ＡＰＩ）を表す。このアーキテクチャは、アクティビティオブジェクト、エンドポイントオブジェクト、および複数のメディアスタックを有する。これらのオブジェクトは、情報を含むメッセージの送信および受信に、セッションイニシエーションプロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）またはリアルタイムトランスポートプロトコル（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの様々な通信プロトコルを使用することができる。アクティビティオブジェクト、エンドポイントオブジェクト、および複数のメディアスタックは、それぞれ、１つまたは複数のＡＰＩを有し、アプリケーション開発者は、このＡＰＩを使用して、コラボレーション関連機能性にアクセスするかこれを提供することができる。これらのオブジェクトは、このＡＰＩを、他のオブジェクトによって提供される基礎になる実装にマッピングする。アクティビティオブジェクトを使用することによって、開発者が、そうでなければ完全なコラボレーションサービスを提供するために必要になるものより少ないアプリケーションロジックを提供できるようになる。

一実施形態で、拡張可能リアルタイムコラボレーションシステムのアーキテクチャを提供する。このアーキテクチャは、通信プロトコルを使用してコラボレーションサービスを提供するアプリケーションプログラムを記述するための高水準アプリケーションプログラムインターフェース（ＡＰＩ）を提供する。アプリケーション開発者は、コラボレーションサービスを実装する複数の基礎になるプロトコルに関連する複雑さを習得する必要なしに、ＡＰＩを使用することによってアプリケーションにコラボレーションサービスを追加することができる。

このアーキテクチャには、アクティビティオブジェクト、エンドポイントオブジェクト、および複数のメディアスタックが含まれる。これらのオブジェクトは、ＳＩＰまたはＲＴＰ／ＲＴＣＰなどの様々な通信プロトコルを使用して、メッセージを送信し、受信することができる。アクティビティオブジェクト、エンドポイントオブジェクト、および複数のメディアスタックは、それぞれ、１つまたは複数のＡＰＩを有することができ、アプリケーション開発者は、このＡＰＩを使用して、オブジェクトによって提供される機能性にアクセスするか、これを提供することができる。アプリケーション開発者は、エンドポイントオブジェクトおよびメディアスタックによって提供されるＡＰＩを使用するアプリケーションロジックを提供することを選択することができ、あるいは、アクティビティオブジェクトによって提供されるＡＰＩを使用するアプリケーションロジックを提供することを選択することができる。エンドポイントオブジェクトおよびメディアスタックによって提供されるＡＰＩを使用することによって、アプリケーション開発者は、高い度合の柔軟性を行使できるようになる可能性があるが、アクティビティオブジェクトのＡＰＩだけを使用する場合よりかなり多くのアプリケーションロジックを提供しなければならない場合がある。アプリケーション開発者は、複数の理由から、アクティビティオブジェクトのＡＰＩの使用を選択することができる。アクティビティオブジェクトのＡＰＩは、エンドポイントオブジェクトおよびメディアスタックのＡＰＩより高水準のインターフェースを提供する。さらに、アクティビティオブジェクトは、エンドポイントオブジェクトおよびメディアスタックを調整し、したがって、アプリケーションロジックが、調整を実行するように提供される必要がない場合がある。

アクティビティオブジェクトは、アプリケーションおよび他のオブジェクトにサービスを提供する。アクティビティオブジェクトは、アプリケーションが様々な特定のアクティビティに参加できるようにするオブジェクトであり、アクティビティオブジェクトには、例として、インスタントメッセージング、テレカンファレンス、ビデオ会議、アプリケーション共有、および他のアクティビティを含めることができる。アクティビティオブジェクトは、エンドポイントオブジェクトおよびメディアスタックを含む基礎になるオブジェクトの機能性を提供する「ラッパー」（ｗｒａｐｐｅｒ）オブジェクトと考えることができる。具体的に言うと、アクティビティオブジェクトは、エンドポイントオブジェクトおよびメディアスタックを調整して、アプリケーションなど、アクティビティオブジェクトを使用する他のオブジェクトにシームレスな統合されたセッションを提供する。

アクティビティオブジェクトを使用することの利益の例が、下記の例によって提供される。アプリケーション開発者は、アプリケーションでビデオ会議機能を提供することを望む場合がある。それを行うために、アプリケーション開発者は、まず、ＳＩＰなどのシグナリングプロトコルおよびＲＴＰ／ＲＴＣＰなどのメディアプロトコルに精通しなければならない。次に、アプリケーション開発者は、セッションを作成し、その人とのビデオ会議が望まれる連絡先が現在オンラインであるかどうかを判定し、ビデオ会議に参加する勧誘を送信し、ビデオ会議に関連する様々なパラメータを折衝し、サウンドおよびオーディオのキャプチャリングハードウェアからオーディオおよびビデオをキャプチャし、最後にＲＴＰ／ＲＴＣＰを使用してオーディオ／ビデオデータを交換するアプリケーションロジックを提供しなければならない可能性がある。対照的に、本アーキテクチャのビデオ会議アクティビティオブジェクトを使用することによって、これらのステップの多くが除去される。というのは、ビデオ会議アクティビティオブジェクトが、特にこのアプリケーションプログラムロジックを少数の高水準インターフェースに整理統合するように設計されているからである。本アーキテクチャは、様々な他のコラボレーションアクティビティに関する類似するアクティビティオブジェクトを有する。さらに、本アーキテクチャは、将来に追加のアクティビティオブジェクトを追加するためのサポートを提供する。

エンドポイントオブジェクトは、シグナリングなどの管理サービスを提供する。エンドポイントオブジェクトには、プロファイルコンポーネント、パブリッシュ／サブスクライブ（ｐｕｂｌｉｓｈｉｎｇ／ｓｕｂｓｃｒｉｂｉｎｇ）コンポーネント、シグナリング（ｓｉｇｎａｌｉｎｇ）コンポーネント、およびプロトコルスタックコンポーネントが含まれる。プロファイルコンポーネントは、ＡＰＩを介してユーザの抽象化（ａｂｓｔｒａｃｔｉｏｎ）を提供することができる。パブリッシュ／サブスクライブコンポーネントは、ユーザに関連するプレゼンス情報およびアベイラビリティ情報を追跡するインターフェースを提供する。シグナリングコンポーネントは、セッションの確立または制御に関係する頻繁でないトランザクショナルメッセージの提供または受取に使用することができる。シグナリングコンポーネントは、たとえば帯域幅制限などのメディアパラメータの折衝（ｎｅｇｏｔｉａｔｉｎｇ）にも使用することができる。プロトコルスタックコンポーネントは、データの送信または受信、およびＳＩＰを含む様々なプロトコルのサポートのために、プロファイルコンポーネント、パブリッシュ／サブスクライブコンポーネント、およびシグナリングコンポーネントによって使用される。

前に説明したように、アクティビティオブジェクトは、アプリケーション開発者がコラボレーションサービスをアプリケーションに簡単に追加する機能を提供する。例として、アプリケーションにビデオ会議を追加することを望むアプリケーション開発者は、ビデオ会議アクティビティオブジェクトを作成（または「インスタンス化」（ｉｎｓｔａｎｔｉａｔｅ））するロジックを提供することができる。次に、ビデオ会議アクティビティオブジェクトは、シグナリング用のエンドポイントオブジェクト（ＳＩＰエンドポイントオブジェクトなど）とオーディオ／ビデオデータを搬送するメッセージングメディアスタックをインスタンス化することができる。後続のビデオ会議アクティビティ中（たとえば、オーディオ／ビデオストリームを送信または受信する時）に、アクティビティオブジェクトは、それが作成またはインスタンス化したオブジェクトを調整（ｃｏｏｒｄｉｎａｔｅ）することができる。一実施形態で、アプリケーションは、オブジェクトを作成でき、任意選択として、オブジェクトの表示をアクティビティオブジェクトに供給することができる。その場合に、アクティビティオブジェクトは、これらのオブジェクトを作成する必要がない。

メディアスタックオブジェクトは、オーディオ／ビデオデータストリームの処理など、コンテンツ通信サービスを提供する。例として、メディアスタックオブジェクトは、ＲＴＰ／ＲＴＣＰを使用して、ビデオ会議に関連するオーディオビジュアル情報を送信または受信することができる。

図面に移ると、図１は、一実施形態での拡張可能リアルタイムコラボレーションシステムのアーキテクチャのコンポーネントを示すブロック図である。拡張可能リアルタイムコラボレーションシステムのアーキテクチャに、コラボレーションサービスオブジェクト１０２、複数のエンドポイントオブジェクト１０４、アクティビティオブジェクト１０６、および複数のメディアスタック１０８が含まれる。１つまたは複数のアプリケーション１１０が、このアーキテクチャに関する様々なメソッド、プロパティ、およびイベントにアクセスすることによって、このアーキテクチャを使用することができる。アプリケーションを記述するアプリケーション開発者は、アプリケーションまたはアーキテクチャが使用できるメディアスタック、プロトコル、または他のコンポーネントに関する異なるＡＰＩを習得し、実装する必要なしに、統一されたＡＰＩを使用することによってこのアーキテクチャを使用することができる。

コラボレーションサービスオブジェクト１０２は、アプリケーションが複数のエンドポイントオブジェクトを共有する機能を提供し、複数のエンドポイントオブジェクトにまたがって一貫したＡＰＩを提供することができる。例として、エンドポイントオブジェクト１が、情報の受信（または送信）に関するインターフェースを提供し、エンドポイントオブジェクト２が、同様に、情報の受信（または送信）に関するインターフェースを提供するが、２つのインターフェースが、異なる名前を使用し、同様の機能を実行する場合に、コラボレーションサービスオブジェクトは、両方のインターフェースに共通の名前を提供することができる。アプリケーション開発者は、アプリケーションでこの共通の名前を使用する時に、異なる名前を有するインターフェースを提供する新しいまたは修正されたオブジェクトがコラボレーションサービスオブジェクトと共に使用される時に、アプリケーションを改訂する必要がなくなる可能性がある。

エンドポイントオブジェクト１０４は、他のオブジェクトにシグナリングする機能を提供する。シグナリングを、１つのセッションを有する２つのエンドポイントオブジェクトの間で使用することができ、その結果、たとえば、あるエンドポイントオブジェクトが、アクティビティを行うかセッションに関する情報を交換するように他方のエンドポイントオブジェクトに勧誘または要求することができる。例として、エンドポイントオブジェクトは、セッションの他方のエンドポイントオブジェクトをインスタントメッセージング会話に勧誘することができ、その後、会話に関連するテキストメッセージを送信することができる。エンドポイントオブジェクトは、さらに、図２に関して下で詳細に説明する。

アクティビティオブジェクトは、アプリケーションが様々なコラボレーション関連アクティビティに参加できるようにするコンポーネントである。これらのコンポーネントは、アプリケーション設計者がエンドポイントオブジェクトおよびメディアスタックの調整に使用できるＡＰＩを提供する。アクティビティオブジェクト１０６は、さらに、図３に関して下で詳細に説明する。

メディアスタックオブジェクト１０８は、データストリームの処理などのコンテンツ通信サービスを提供し、他のオブジェクトがデータを送信または受信するＡＰＩを提供する。本アーキテクチャは、データまたはメディアタイプを区別する必要がないという事実のおかげで、事実上無限の数のメディアスタックをサポートすることができる。その結果、要件が変化する時に、新しいメディアスタックを追加でき、あるいは、メディアスタックを修正することができる。メディアスタックの例が、ＲＴＰ／ＲＴＣＰである。このメディアスタックは、オーディオビジュアル情報を送信するのに使用することができる。

図２は、一実施形態での拡張可能リアルタイムコラボレーションシステムのエンドポイントオブジェクトのコンポーネントを示すブロック図である。エンドポイントオブジェクトは、他のオブジェクトにシグナリングする機能など、管理サービスを提供する。シグナリングを、１つのセッションを有する２つのエンドポイントオブジェクトの間で使用することができ、その結果、たとえば、あるエンドポイントオブジェクトが、アクティビティを行うかセッションに関する情報を交換するように他方のエンドポイントオブジェクトに勧誘または要求することができる。例として、エンドポイントオブジェクトは、セッションの他方のエンドポイントオブジェクトをインスタントメッセージング会話に勧誘することができ、その後、会話に関連するテキストメッセージを送信することができる。

本アーキテクチャは、複数の様々なエンドポイントオブジェクトをサポートでき、各様々なエンドポイントオブジェクトを、複数回インスタンス化することができる。例として、ユーザの個人的なインターネットサービスプロバイダアカウント（たとえばＭＳＮ．ＣＯＭ）に関する１つのエンドポイントオブジェクトと、ユーザの会社のインターネットアカウント（たとえばＭＩＣＲＯＳＯＦＴ．ＣＯＭ）に関するもう１つのエンドポイントオブジェクトを設けることができる。ユーザは、複数のデバイス（たとえば、ハンドヘルドコンピューティングデバイスとデスクトップコンピューティングデバイス）でパーソナルアカウントを使用してサービスプロバイダにログインすることができ、一部のデバイス（たとえばデスクトップコンピューティングデバイス）で会社のアカウントを使用してログインすることもできる。したがって、個人アカウントに関連するＵＲＩに関連する２つのインスタンスがある場合がある。エンドポイントオブジェクトの個々のインスタンスは、ＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）およびエンドポイント識別子（ＥＩＤ）の組合せによって一意に識別することができる。例として、エンドポイントオブジェクトを、ＵＲＩ ｕｓｅｒ＠ＭＳＮ．ＣＯＭおよびＥＩＤ「１２３４」によって識別することができる。前に説明したように、ＥＩＤは、同一ＵＲＩに関連するエンドポイントオブジェクトの別のインスタンスからエンドポイントオブジェクトのあるインスタンスを特に区別するのに使用することができる。

エンドポイントオブジェクトは、「データ」インターフェースおよび「シグナリング」インターフェースを提供することができる。データインターフェースには、エンドポイントオブジェクトによってパブリッシュまたはサブスクライブされるデータに関連するメソッド、イベント、およびプロパティを含めることができる。データをパブリッシュまたはサブスクライブすることによって、アプリケーションは、データを提供するか、データに対する変更について通知を受けることができる。シグナリングインターフェースは、エンドポイントオブジェクトのシグナリングの制御に関連するメソッド、イベント、およびプロパティを提供することができる。例として、シグナリング特性に、セッションの作成またはこれへの参加、会話への参加または離脱、勧誘の受け入れまたは拒否、および他のシグナルを含めることができる。

図示のエンドポイントオブジェクト２００には、プロファイルコンポーネント２０１、パブリッシュおよびサブスクライブコンポーネント２０２、シグナリングコンポーネント２０４、およびプロトコルスタックコンポーネント２０６が含まれる。

プロファイルコンポーネントは、ＡＰＩを介してユーザの抽象性を提供することができる。プロファイルコンポーネントは、電子アドレス（たとえばＵＲＩ）、サービスプロバイダに関して使用される信任証（ｃｒｅｄｅｎｔｉａｌｓ）、サービスプロバイダの状況、機能、およびポリシなど、ユーザのサービス関連情報を維持する。ユーザは、異なるサービスプロバイダに関する複数のプロファイルを有することができる。ユーザは、サービスプロバイダごとに複数のプロファイルを有することもできる。プロファイルコンポーネントは、他のユーザとのセッションを作成して、たとえばユーザのＵＲＩを供給する時に使用することができる。プロファイルコンポーネントは、サービスプロバイダに関してユーザをログオンまたはログオフするメソッドを提供することができる。

パブリッシュ／サブスクライブコンポーネントは、ユーザに関するプレゼンス情報およびアベイラビリティ情報を追跡するインターフェースを提供する。プレゼンス情報は、ユーザが特定のコンピューティングデバイスの前にいるかどうかに関する。アベイラビリティ情報は、現在のユーザが、メッセージを受け取るために求めに応じられるかどうかまたはそうする意志があるかどうかに関する。例として、携帯電話のユーザは、携帯電話の電源を入れる時に存在する可能性があるが、ユーザが電話で話している時にはメッセージングセッションについて求めに応じられない可能性がある。同様に、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）ＭＥＳＳＥＮＧＥＲで「ビジー」表示をセットしたユーザは、存在するが、メッセージングに関して求めに応じることができない。

もう１つの例として、プレゼンスオブジェクトは、存在し、コンピューティングデバイスを使用してＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）ＭＥＳＳＥＮＧＥＲ会話への参加の求めに応じられ、携帯電話を使用してテレカンファレンスへの参加の求めにも応じられるユーザに関する情報を提供することができる。ユーザが、もはやＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）ＭＥＳＳＥＮＧＥＲにログインしていない時に、プレゼンスオブジェクトは、この情報を更新することができ、その結果、プレゼンスオブジェクトを使用するアプリケーションが、ユーザがもはや存在せず、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）ＭＥＳＳＥＮＧＥＲ会話への参加の求めに応じられないことを判定できる。したがって、プレゼンス情報は、ユーザまたは他のオブジェクトが存在するかどうかを示す。様々なサービスプロバイダまたプロトコルで、異なる機構を使用して、プレゼンス情報を作るか提供することができる。アプリケーション開発者が、プレゼンス情報を作るか提供するかの複数のやり方を意識する必要をなくすために、アプリケーション開発者は、エンドポイントオブジェクトを使用して、プレゼンス情報を作るか使用することができる。

パブリッシュ／サブスクライブコンポーネントは、別のオブジェクトのパブリケーションへのサブスクリプションを作成するサブスクライブインターフェース、サブスクリプションを他のオブジェクトに提供するパブリッシュインターフェース、およびそのパブリケーションがサブスクライブされているサービスに関連する通知を受信する通知インターフェースを提供する。これらのインターフェースによって、アプリケーションが、コンポーネントを使用してプレゼンス情報の提供、受信、または追跡を行えるようになる。例として、ユーザが、パーソナルコンピュータを使用してＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）ＭＥＳＳＥＮＧＥＲ会話に参加し、携帯電話を使用してテレカンファレンスに参加する時に、パブリッシュ／サブスクライブコンポーネントは、両方の場所でのユーザの存在を検出し、報告することができる。ＵＲＩおよびＥＩＤを一緒にして、エンドポイントオブジェクトのインスタンスを一意に識別することができる。ユーザは、複数の場所に同時に存在することができるので、ユーザのＵＲＩを、これらの複数の場所に存在するものとして示すことができる。所与のＵＲＩに関するＥＩＤの追加によって、プレゼンスの特定のインスタンスを一意に識別する機構が提供される。

通知を、様々な情報に関して提供することができる。例として、通知を、ユーザがオンライン、ビジー、求めに応じられる、食事に出かけたなどのいずれであるかに関して提供することができる。通知は、ユーザの地理的位置（たとえば全世界測位システムまたは「ＧＰＳ」によって提供される）、連絡先情報、カレンダ情報、不在メッセージ、オーディオ／ビデオ機能などに関して提供することもできる。

シグナリングコンポーネントは、セッションの確立または制御に関係する頻繁でないトランザクショナルメッセージの提供または受取に使用することができる。このコンポーネントは、たとえばフレーム毎秒などのメディアパラメータの折衝にも使用することができる。

プロトコルスタックオブジェクトは、プロトコルを使用して情報を送信し、受信する責任を負う。例として、ＳＩＰを使用して、シグナリング情報を送信または受信することができる。様々な実施形態で、他のプロトコルを同等に使用することができる。一実施形態で、エンドポイントオブジェクトを、複数のプロトコルと互換にすることができる。その場合に、エンドポイントオブジェクトは、情報の送信または受信に、必要に応じて、たとえば複数のプロトコルを、使用することができる。その代わりに、本アーキテクチャは、別々のエンドポイントオブジェクトとして複数のエンドポイントオブジェクトとプロトコルの組合せをサポートすることができる。その場合に、１つのエンドポイントオブジェクトをＳＩＰに使用でき、別のエンドポイントオブジェクトを他のプロトコルに使用することができる。

図３は、一実施形態での拡張可能リアルタイムコラボレーションシステムのアクティビティオブジェクトを示すブロック図である。アクティビティオブジェクトは、アプリケーションおよび他のオブジェクトにサービスを提供する。アクティビティオブジェクトは、アプリケーションが様々な特定のアクティビティに参加できるようにするオブジェクトであり、アクティビティオブジェクトには、例として、インスタントメッセージング、テレカンファレンス、ビデオ会議、アプリケーション共有、および他のアクティビティを含めることができる。アクティビティオブジェクトは、エンドポイントオブジェクトおよびメディアスタックを含む基礎になるオブジェクトの機能性を提供する「ラッパー」オブジェクトと考えることができる。具体的に言うと、アクティビティオブジェクトは、エンドポイントオブジェクトおよびメディアスタックを調整して、アプリケーションなど、アクティビティオブジェクトを使用してオブジェクトにシームレスな統合されたセッションを提供する。

各アクティビティオブジェクトは、オブジェクトを使用するアプリケーションが様々なアクティビティに参加できるようにする機能性を提供する。例として、アクティビティオブジェクトは、シグナリング情報およびメディア情報をカプセル化することができる。それを行う際に、アクティビティオブジェクトは、シグナリングとメディアの間のブリッジとして働き、その結果、アクティビティオブジェクトを使用するアプリケーションに、統合されたビューが与えられる。たとえば、アプリケーション開発者は、別々のＳＩＰおよびＲＴＰ／ＲＴＣＰの接続およびセッションをセットアップする必要があるのではなく、単にビデオ会議を要求する。アクティビティの図示の例を、下で説明する。

コラボレーションセッションアクティビティオブジェクト３０４は、アプリケーションが、アプリケーションのユーザにコラボレーションサービスを提供できるようにする。例として、コラボレーションセッションアクティビティオブジェクトは、２つの異なるコンピュータを使用する２人のユーザが、共有文書を作成することによってコラボレートできるようにすることができる。

アプリケーション共有アクティビティオブジェクト３１０は、アプリケーション共有アクティビティオブジェクトを使用するアプリケーションが、異なるコンピューティングデバイスを使用するユーザの間のアプリケーション共有に関連する機能性を提供できるようにする。例として、２人のユーザが、「ホワイトボード」アプリケーションを共有でき、たとえば、これを使用して、一方のユーザが、他方のユーザが見、操作できるビジュアル情報を提供することができる。

メッセージングアクティビティオブジェクト３０６は、アプリケーションがそのアプリケーションのユーザにメッセージング機能性を提供する能力を提供する。例として、アプリケーション開発者が、その開発者が作成しつつあるアプリケーション内でメッセージングを使用可能にすることを求める場合がある。具体的な例として、２人のユーザが、同時に文書を編集することによって１つの文書に対してコラボレーションしている時に、ユーザが、互いにテキストメッセージを送信できることまたはコラボレーション中にビデオ会議に参加できることを求める場合がある。そのような場合に、アプリケーション開発者は、コラボレーションセッションアクティビティオブジェクトならびにメッセージングアクティビティオブジェクトまたはビデオ会議アクティビティオブジェクトを使用して、ユーザが、コラボレートでき、コラボレート中に互いにメッセージを交換できるようにすることができる。

ビデオ会議アクティビティオブジェクト３０８は、ビデオ会議機能をアプリケーションに提供する。ビデオ会議に、オーディオビジュアル情報の送信および受信を含めることができる。

追加のアクティビティオブジェクトも企図されており、これらは、アクティビティオブジェクト３１２として表されている。

アプリケーション開発者は、オブジェクトによって提供されるＡＰＩを使用することによって、上で説明したアーキテクチャのオブジェクト（およびリストされないか説明されなかったオブジェクト）を使用することができる。これらのオブジェクトは、使い易いＡＰＩを提供することができ、その結果、アプリケーション開発者は、アクティビティオブジェクトに関連するサービスを提供する基礎になるコンポーネントによって提供されるＡＰＩを参照する必要がなくなる可能性がある。例として、メッセージングサービスプロバイダは、開発者が使用できるＡＰＩを提供することができる。それを行うために、開発者は、ＡＰＩを習得するために時間を費やす必要がある場合があり、このＡＰＩが、非常に複雑である可能性がある。その代わりに、開発者は、本アーキテクチャのオブジェクトによって提供される、より単純なＡＰＩを使用することを望む可能性がある。さらに、オブジェクトは、複数の異なるオブジェクトを使用するのに必要になる可能性があるステップをカプセル化することができる。例として、２台のコンピュータの間でメッセージを交換することを求めるアプリケーション開発者は、ＳＩＰによって提供されるＡＰＩならびにメッセージングサービスを提供する別の低水準オブジェクトによって公開されるＡＰＩを使用する必要がある可能性がある。対照的に、アプリケーション開発者は、メッセージングアクティビティオブジェクトを使用することだけが必要であり、これによって、はるかに簡単にメッセージング機能性をアプリケーションに追加することができる。さらに、このフレームワークは、複数のオブジェクトを調整するように動作することができ、これによって、アプリケーション開発者に要求されるプログラミングロジックが減る。

一実施形態で、コラボレーションセッションに、アクティビティオブジェクトが含まれ、使用される。

図４は、一実施形態のクリエートサーバエンドポイント（ｃｒｅａｔｅ＿ｓｅｒｖｅｒ＿ｅｎｄｐｏｉｎｔ）ルーチンを示す流れ図である。このルーチンは、サーバに接続されるエンドポイントオブジェクトを作成するために、アプリケーションによって呼び出される。サーバに接続されるエンドポイントが作成される時に、作成されたエンドポイントがもはや動作しなくなった後であっても、そのエンドポイントがパブリッシュする情報を、サブスクライブするオブジェクトから使用可能にすることができる。したがって、サーバに接続されたエンドポイントは、「ＵＲＩごと」の情報を提供することができ、これは、オブジェクトの寿命の後でも情報が使用可能になることを意味する。

このルーチンは、ブロック４０２で開始される。ブロック４０４で、このルーチンは、新しいエンドポイントオブジェクトを作成し、そのエンドポイントがアプリケーションに関連することを示す。示されるアプリケーションは、エンドポイントを作成するように動作する作成関数（ａ ｃｒｅａｔｅ ｆｕｎｃｔｉｏｎ）へのパラメータとして供給することができる。エンドポイントを作成する時に、「フレンドリ」（ｆｒｉｅｎｄｌｙ）名を提供することができ、その結果、エンドポイントを、フレンドリ名によって参照できるようになる。その代わりに、新たに作成されるエンドポイントを、そのエンドポイントに関連する一意識別子によって参照することができる。この一意識別子は、オブジェクトが作成される時にシステムによって生成することができる。

ブロック４０６で、エンドポイントを作成する時に、アプリケーションが、新たに作成されたエンドポイントオブジェクトをサーバに登録して、サーバがこのエンドポイントにメッセージをルーティングできるようにすることができる。エンドポイントオブジェクトから登録要求を受け取る時に、サーバは、エンドポイントに呼び掛け（ｃｈａｌｌｅｎｇｅ）を発行することができる。呼び掛けに、サーバによって使用されるアドレス体系「レルム（ｒｅａｌｍ）」を含めることができる。レルムによって、サーバに関連するドメイン名を示すことができる。例として、サーバは、レルム「ＭＩＣＲＯＳＯＦＴ．ｃｏｍ」を伴う呼び掛けを発行することができる。

ブロック４０８で、ルーチンが、アプリケーションに関連する信任証（たとえば、ユーザｉｄおよびパスワード）を提供することによって呼び掛けに応答する。この信任証は、ユーザによってまたは自動的に供給することができる。サーバは、ルーチンが供給する信任証を検証することができる。信任証は、レルムに関連するものとすることができる。たとえば、アプリケーションが、サーバのレルム（「ＭＩＣＲＯＳＯＦＴ．ｃｏｍ」）に関連しない信任証を供給する場合に、サーバは、アプリケーションを認証しないものとすることができる。

登録が成功の場合には、エンドポイントは、他のオブジェクトからメッセージを受け取る準備ができている可能性がある。そうでない場合には、エンドポイントは、メッセージを受け取ることができない可能性がある。

このルーチンは、ブロック４１２で呼出し元にリターンする。

一実施形態で、サーバは、メッセージ送信のために成功裡に登録されないがメッセージを受信しないエンドポイントをイネーブルすることができる。代替案では、弱いセキュリティモデルで、サーバが、すべてのエンドポイントがメッセージ送信または受信することをイネーブルすることができる。

一実施形態で、サーバは、エンドポイントがメッセージ送信を試みる時にエンドポイントに呼び掛けするが、メッセージ受信時に呼び掛けしないものとすることができる。

代替ルーチン（図示せず）では、ピアツーピアエンドポイントを作成することができる。ピアツーピアエンドポイントは、サーバに関連しないエンドポイントである。エンドポイントが、サーバに関連しない時には、そのエンドポイントがパブリッシュする情報は、そのエンドポイントが動作を停止した後に使用可能でなくなる可能性がある。

図５は、一実施形態での拡張可能リアルタイムコラボレーションシステムのアーキテクチャを示すアーキテクチャ図である。このアーキテクチャには、アクティビティオブジェクト５０２、エンドポイント５０４、および複数のメディアスタックオブジェクト５０６が含まれる。これらのオブジェクトは、上で詳細に説明した。このアーキテクチャ図には、一実施形態のアクティビティオブジェクト、エンドポイントオブジェクト、およびメディアスタックオブジェクトの間の関係が示されている。具体的に言うと、このアーキテクチャ図には、アクティビティオブジェクトによって提供される機能性に、エンドポイントオブジェクトおよびメディアスタックオブジェクトによって提供される機能性が含まれることが示されている。

一実施形態で、複数のアクティビティオブジェクトを、対応するメディアスタックオブジェクトと共に使用することができる。

アプリケーションは、このアーキテクチャのオブジェクトのメソッドを呼び出すことができ、あるいは、機能性を実装する基礎になるオブジェクトのメソッドを直接に呼び出すことができる。このアーキテクチャのオブジェクトのメソッドを呼び出すことによって、アプリケーション開発者は、より少ないロジックを提供することが必要になる可能性があり、基礎になるコンポーネントが変更される時にアプリケーションロジックを改訂する必要がなくなる可能性がある。

以下では、このアーキテクチャによって提供されるいくつかのＡＰＩを提示する。

アプリケーションは、新しい「ＣｏｌｌａｂｏｒａｔｉｏｎＥｎｄｐｏｉｎｔ」（コラボレーションエンドポイント）を作成することによって、エンドポイントオブジェクトを作成することができる。アプリケーションは、次のパラメータを供給することができる：エンドポイントオブジェクトに関連するＵＲＩ、エンドポイントオブジェクトに関連するサーバ、およびネットワーク信任証の表示。

ＮｅｔｗｏｒｋＣｒｅｄｅｎｔｉａｌメソッド（ネットワーククレデンシャルメソッド）によって、ネットワーク信任証の表示が提供される。このメソッドは、パラメータとして、ユーザアカウントの表示、パスワード、およびアカウントが関連するドメインを受け入れる。

Ｅｎｔｅｒメソッド（エンターメソッド）によって、エンドポイントが登録され、成功または失敗の表示が供給される。このメソッドは、パラメータを必要としない。

Ｐｕｂｌｉｓｈメソッド（パブリッシュメソッド）によって、プレゼンス情報がパブリッシュされる。例として、アプリケーションは、ユーザが、オンライン、オフライン、ビジー、通話中などであることを示すことができる。このアーキテクチャは、事実上無制限の数のプレゼンス表示を提供するのに十分に柔軟である。たとえば、アプリケーションは、ユーザのＧＰＳ位置をパブリッシュすることを選択することができる。

逆に、Ｓｕｂｓｃｒｉｂｅメソッド（サブスクライブメソッド）によって、あるエンドポイントオブジェクトのパブリケーションがサブスクライブされる。

Ｉｎｖｉｔｅメソッド（インバイトメソッド）によって、ユーザがコラボレーションセッションに勧誘される。このメソッドは、勧誘されなければならないＵＲＩの表示を受け取る。

Ａｃｃｅｐｔメソッド（アクセプトメソッド）は、勧誘を受け入れる。逆に、Ｄｅｃｌｉｎｅメソッド（デクラインメソッド）は、勧誘を拒否する。

メッセージングアクティビティオブジェクトは、ＩｎｓｔａｎｔＭｅｓｓａｇｉｎｇＡｃｔｉｖｉｔｙクラス（インスタントメッセージングアクティビティクラス）から作成することができる。このアクティビティオブジェクトは、たとえばメッセージを送信するメッセージ、ＳｅｎｄＭｅｓｓａｇｅ（センドメッセージ）を含む、様々なメソッドをサポートする。

ＳｅｎｄＭｅｓｓａｇｅメソッドによって、メッセージが送信される。このメソッドは、パラメータとしてメッセージ文字列を受け取る。

このメソッドを、本アーキテクチャの様々なオブジェクトによって提供することができる。本アーキテクチャは、さらに、ユーザのプロパティの検索、連絡先のリストへのユーザの追加、会話への参加者の追加または除去などに関するメソッド、プロパティ、およびイベントを提供することができる。

本アーキテクチャが実装されるコンピューティングデバイスに、中央処理装置、メモリ、入力デバイス（たとえば、キーボードおよびポインティングデバイス）、出力デバイス（たとえば、ディスプレイデバイス）、および記憶デバイス（たとえば、ディスクドライブ）を含めることができる。メモリおよび記憶デバイスは、システムを実施する命令を含めることができるコンピュータ可読メディアである。さらに、データ構造およびメッセージ構造を、信号リンクまたは通信リンクなどのデータ伝送メディアを介して保管または伝送することができる。インターネット、ローカルエリアネットワーク、広域ネットワーク、またはポイントツーポイントダイヤルアップ接続など、様々な通信リンクを使用することができる。

本アーキテクチャは、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムが動作するコンピューティングデバイスを含む様々なオペレーティング環境で実施することができる。このオペレーティング環境は、適切なオペレーティング環境の１つの例にすぎず、本システムの使用の範囲または機能性に関する制限を暗示することを意図されたものではない。使用に適する可能性がある他の周知のコンピューティングシステム、環境、および構成に、パーソナルコンピュータ、サーバコンピュータ、「スマート」携帯電話を含むハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブル民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれる。

本アーキテクチャを、１つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通常、プログラムモジュールの機能性は、様々な実施形態で望み通りに組み合わせるか分配することができる。

前述から、本発明の特定の実施形態を、例示のために本明細書で説明したことと、本発明の趣旨および範囲から逸脱せずに様々な修正を行うことができることを諒解されたい。したがって、本発明は、請求項による以外には制限されない。

一実施形態での拡張可能リアルタイムコラボレーションシステムのアーキテクチャのコンポーネントを示すブロック図である。 一実施形態での拡張可能リアルタイムコラボレーションシステムのエンドポイントオブジェクトのコンポーネントを示すブロック図である。 一実施形態での拡張可能リアルタイムコラボレーションシステムのアクティビティオブジェクトを示すブロック図である。 一実施形態のｃｒｅａｔｅ＿ｓｅｒｖｅｒ＿ｅｎｄｐｏｉｎｔルーチンを示す流れ図である。 一実施形態での拡張可能リアルタイムコラボレーションシステムのアーキテクチャを示すアーキテクチャ図である。

符号の説明

１１０ アプリケーション１〜ｎ
１０２ コラボレーションサービス
１０４ エンドポイント１〜ｎ
１０６ アクティビティ
１０８ メディアスタック１〜ｍ
２００ エンドポイント
２０１ プロファイル
２０２ パブリッシュおよびサブスクライブ
２０４ シグナリング
２０６ プロトコルスタック
３００ アクティビティ
３０４ コラボレーションセッション
３０６ メッセージング
３０８ ビデオ会議
３１０ アプリケーション共有
３１２ 他
５０２ アクティビティオブジェクト
５０４ エンドポイント
５０６ メディアスタック１〜ｍ

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