(57)【特許請求の範囲】
【請求項１】
クライアントがコラボレーション・セッションにアクセスする方法であって、
セッション・マネージャにリソース・ロケータ（ＲＬ）を送ることによってコラボレーション・セッションへのアクセスを要求するステップと、
レジストリ内の記憶されたＲＬの位置標識を受信するステップと、
レジストリ内のＲＬの位置標識の受信に応答して、ネットワーク関数セットを提供するために、ＲＬ内で指定されているトランスポート機構を自動的にロードするステップと、
コラボレーション・セッションとの接続を確立するためにトランスポート機構を用いてコラボレーション・セッションにアクセするステップと
を含むコラボレーション・セッションにアクセする方法。
【請求項２】
トランスポート機構を自動的にロードするステップが、
トランスポート機構のタイプに応じてオブジェクト・クラスの新しいインスタンスを生成するステップと、
トランスポート機構に対応したプロトコル・スタックを検索するステップと、
そのプロトコル・スタックを開始するステップと
を有する請求項１記載のコラボレーション・セッションにアクセする方法。
【請求項３】
コラボレーション・セッションを容易にするセッション・マネージャと、
セッション・マネージャにリソース・ロケータ（ＲＬ）を送ることによってコラボレーション・セッションへのアクセスを要求するクライアントと、
セッション・マネージャに接続され、ＲＬからタイプ指定を取り出すパーサと、
ＲＬのタイプ指定に応じてトランスポート機構を自動的にロードするローダであって、
そのトランスポート機構は、クライアントに、コラボレーション・セッションとの接続を確立させるネットワーク関数セットを提供する
コンピュータ・ユーザ間のコラボレーションを容易にする装置。
【請求項４】
搬送信号として具体化され、プロセッサによって実行されるとそのプロセッサにコラボレーション・セッションへアクセスさせる命令シーケンスを表すコンピュータ・データ信号を格納したコンピュータ可読媒体において、
セッション・マネージャにリソース・ロケータ（ＲＬ）を送ることによってコラボレーション・セッションへアクセスすることを実行可能とする第１のコンピュータ・プログラムと、
レジストリ内のＲＬへの位置標識を受信するため実行可能な第１のオペレーティング・システム手順と、
位置標識に対応して、ネットワーク関数セットを提供するトランスポート機構を自動的にロードし、トランスポート機構を使用しててコラボレーション・セッションへの接続を確立するために実行可能な第２のコンピュータ・プログラムと
を含むコンピュータ可読媒体。
【請求項５】
コラボレーション・セッションにアクセスするためのシステムであって、
セッション・マネージャにリソース・ロケータ（ＲＬ）を送ることでコラボレーション・セッションへのアクセスを要求する手段と、
レジストリ内に記憶されたＲＬの位置標識を受信する手段と、
位置標識の受信に応答して、位置標識に応じたトランスポート機構であってネットワーク関数セットを提供するトランスポート機構を自動的にロードする手段と、
トランスポート機構を使用してコラボレーション・セッションとの接続を確立する手段と
を有するシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はマルチポイント・データ配信システム、より詳細に言えばマルチポイント・データ配信システム内のトランスポート機構に関する。
【０００２】
【従来の技術】
ビジネスおよび娯楽の分野でコンピュータが重要になるにつれて、コンピュータ・ユーザ間の通信を向上させることが必要になっている。コンピュータの１つの重要な機能はユーザに情報を分配し、ユーザ間の対話およびコラボレーション（collaboration 共通操作）を可能にすることである。情報分配および対話の従来のシステムは、電子メール（Ｅメール）、メーリング・リスト、掲示板システムまたはワールド・ワイド・ウェブ（ＷＷＷ）での情報の入手、およびビデオ会議を含む。
【０００３】
ユーザは電子メールを使って複数の宛て先に情報を送信できる。しかし、Ｅメールへの返信の収集は容易ではない。さらに、複数の通信主体がＥメールでコラボレーションするのは容易ではない。
【０００４】
メーリング・リストは情報の分配には役立つが、加入者が受信する情報を選択するのは比較的困難である。さらに、返信ができる場合にはメーリング・リストはあまりにも扱いにくくなる場合がある。
【０００５】
掲示板システムまたはワールド・ワイド・ウェブ（ＷＷＷ）ページは情報の公表には役立つ。しかし、一般ユーザが表示情報を変更することは容易ではない。このようにこの環境では情報の公表が可能であるがユーザ間の完全なコラボレーションができない。
【０００６】
ビデオ会議および類似のシステムを使って特定のプロジェクトに対してコラボレーションすることができる。ただし、ビデオ会議は一般にビデオ会議の間は他の処理ができない専用のコンピュータ・システムを必要とする。さらに、一般にビデオ会議への参加は各参加者を収容するのに必要な処理能力とネットワーク帯域幅があるために通常限定されている。したがって、この会議への参加者数は大幅に限定される。以上の点から、ビデオ会議システムによって複数のユーザ間の長時間のコラボレーションを確立することは比較的困難である。
【０００７】
【発明が解決しようとする課題】
異種ネットワークでコンピュータを使って複数のユーザ間でコラボレーションを行おうとするとき、異なるネットワーク・プロトコルが存在することがある。この場合はソフトウエアの多数のバージョンをそれぞれの特定のプロトコル用の一つのソフトウェア・バーションに書く必要がある。したがって、基礎のネットワーク・プロトコルから独立した、コラボレーション用の改良された機構を確立することが有利である。
【０００８】
【課題を解決するための手段】
本発明はマルチポイント・データ配信システム内にトランスポート機構を動的にロードする方法および装置である。マルチポイント・データ配信システムは、ユーザまたはコンピュータ間にポイント・ツー・ポイントおよびポイント・ツー・マルチポイントのメッセージの送信が可能な通信機構を提供する。コラボレーション・セッションに対応するリソース・ロケータ（ＲＬ）はレジストリから要求される。レジストリ内のＲＬの位置標識がレジストリから受信される。レジストリ内の位置標識の受信に応答して、ＲＬ内に規定されたトランスポート機構が動的にロードされコラボレーション・セッションに参加できる。トランスポート機構は使用するトランスポート・プロトコルを識別するプロトコル・スタックである。トランスポート・プロトコルは、送信制御プロトコル（ＴＣＰ）、ユーザ・データグラム・プロトコル（ＵＤＰ）、リモート・メソッド起動（ＲＭＩ）、Ｔ．１２０、共通オブジェクト要求ブローカ・アーキテクチャ（ＣＯＲＢＡ）、スケーラブル・リライアブル・マルチキャスト（ＳＲＭ）、およびその他のトランスポート・レベルの実施形態を含む。
【０００９】
本発明は添付図面の各図において例示されており、限定されるものではない。図中の番号と明細書中の番号は対応しており類似の要素を示している。
【００１０】
【発明の実施の形態】
マルチポイント・データ配信システム内にトランスポート機構を動的にロードする方法および装置について記述する。以下の記述で、説明のために数多くの特定の具体例を提示して本発明を完全に理解できるようにしている。しかしながら、当業者には本発明がこれらの特定の具体例以外の方法でも実施できることは明らかであろう。また別の例では、周知の構造および装置はブロック図の形式で示して本発明を不必要にわかりにくくしないように配慮している。
【００１１】
図１は本発明が実施されるコンピュータ・ネットワークの一実施形態を示すブロック図である。コンピュータ・システム１１０は直接接続１２０を介して直接に、またはネットワーク１３０を介して他のコンピュータ・システム１１０に結合する。一実施形態では、１つまたは複数のコンピュータ・システム１１０は別のコンピュータ・システム１１０上で実行される「セッション」の「クライアント」になることができる。これらの用語については後述する。また別に、１つのコンピュータ・システム１１０はサーバとして動作でき、残りのコンピュータ・システム１１０はクライアントである。また別に、本発明は複数のコンピュータ・システム上に各ブロック部分がある分散システムとして実施できる。また別に、本発明は単一のコンピュータ・システム１１０上でも実施できる。
【００１２】
本発明はコンピュータ・ネットワークでコラボレーション・システムのトランスポート・プロトコルを動的にロードする処理に関連する。一実施形態によれば、コラボレーション・システムは、メモリ内に記憶された命令シーケンスを実行しているプロセッサに応答してコンピュータ・システムによって管理される。命令シーケンスの実行によってコンピュータ・ネットワークは後述するようにユーザがコラボレーション・セッションに参加できるようにコラボレーション・セッションを確立し、新しいセッションを追加し、トランスポート・プロトコルを動的にロードする。別の実施形態では、コンピュータ・ネットワーク内部の回路論理をソフトウェアに代えて用いて、またはソフトウェアと併用して本発明を実施する。このように、本発明はハードウェアとソフトウェアのいかなる特定の組み合わせにも限定されない。
【００１３】
リソース・ロケータ（ＲＬ）という用語が明細書で用いられているが、本発明の精神を変更することなくインターネット上でオブジェクトを指定する別の方法を利用することができる。さらに、ＲＬタイプ内で、別のアクセス方式またはプロトコルを利用できる。このように、ファイル転送プロトコル（ｆｔｐ）、ｔｅｌｎｅｔ等に対応するＲＬを利用できる。しかしながら、簡略化のためＲＬという用語を今後も使用する。
【００１４】
図２は本発明のコラボレーション・システムの一実施形態を示すブロック図である。本発明のコラボレーション・システム２１０は１つまたは複数のコンピュータ・システム１１０に組み込まれている。コラボレーション・システム２１０はサーバ・コンピュータとクライアント・コンピュータに実装される要素を含む。ただしサーバおよびクライアント・コンピュータは同じコンピュータでもかまわない。
【００１５】
アプリケーション・ユーザ・インタフェース２２０はクライアント／ユーザに情報を表示し、ライアント／ユーザから情報を受信するインタフェースである。一実施形態では、インタフェース２２０はワールド・ワイド・ウェブ（ＷＷＷ）ブラウザの一部でもよい。アプリケーション・ユーザ・インタフェース２２０はクライアントとして動作するコンピュータ上にある。
【００１６】
コラボレーション・システム２１０はレジストリ２３０をさらに含む。レジストリ２３０はリモート・セッションおよびクライアントに関する情報を含む。このため、後述するように他のコンピュータ・システムが多様なセッションにリンクしクライアントになることが可能になる。一実施形態では、レジストリ２３０はブートストラップ・ネーム・サーバである。一実施形態では、レジストリ２３０はサーバとして動作するコンピュータに装備される。
【００１７】
コラボレーション・システム２１０はパーサ２４０をさらに含む。パーサ２４０は受信したリソース・ロケータ（ＲＬ）を解析するためのものである。一実施形態では、リソース・ロケータはユニフォーム・リソース・ロケータ（ＵＲＬ）である。パーサ２４０は後述するようにＲＬをコンポーネント部分に分割してさらに処理する。パーサ２４０はクライアント・コンピュータに実装される。
【００１８】
動的ローダ２５０はコラボレーション・システム２１０の一部である。動的ローダはメモリ２７０に記憶されたプロトコル・スタックを動的に（すなわち自動的に）ロードするためのものである。動的ローダ２５０はこれから確立するセッション／クライアントに使用するプロトコルのタイプを指定するＲＬに応答してプロトコル・スタックをロードする。動的ローダ２５０はレジストリ２３０からタイプ指定を受信し、そのタイプに応じてロードする該当プロトコル・スタックを決定し、メモリ２７０からプロトコル・スタックを検索する。このように、動的ローダ２５０はタイプ指定の受信に応答して動的に該当プロトコル・スタックを検索する。一実施形態では、動的ローダ２５０はクライアント・コンピュータに実装される。
【００１９】
コンパレータ２６０は受信したＲＬをレジストリ２３０内のすべてのＲＬと比較する。コンパレータ２６０は受信したＲＬがレジストリ２３０内にすでにあるかどうか判定する。コンパレータ２６０はＲＬが新しいセッションを確立する必要があるか、またはレジストリ２２０内のすでに確立されたセッションに参加するかを決定する。コンパレータ２６０はレジストリ２３０に関連付けられたメモリ２７０内に一致するＲＬが見つかったかどうかの判定を出力する。コンパレータ２６０はサーバ・コンピュータに実装される。
【００２０】
セッション・マネジャ２８０は個々の確立されたセッションを管理する。それぞれの確立されたセッションはレジストリ２２０内にＲＬを備え、少なくとも１つのクライアントを備える。セッションの一例を図３に示す。セッション・マネジャ２８０は問題の特定のセッションのサーバとして動作するコンピュータ上で実施される。一実施形態では、セッションのサーバはレジストリ２３０と同じコンピュータに実装される必要はない。
【００２１】
図３にコラボレーション・コンピュータ処理のセッション３００の概要を示す。このセッションで複数のユーザが１つのアプリケーションを共用できる。このセッション３００は例えばオンライン・チャット・プログラム、共用ホワイト・ボード、ゲーム・システムなどである。
【００２２】
セッション３００は定義された通信パス３８０、３９５を介してメッセージ交換を行うことができる関連クライアント３２０、３３０、３６０の集合である。クライアント３２０、３３０、３６０はマルチパーティ通信のあるインスタンスへの現実の、または潜在的な参加者である。互いにセッション３００に正しく関連付けられると、関連するクライアント３２０、３３０、３６０はポイントツーポイントまたはマルチポイント方式でデータを転送できる。セッション３００はクライアント３２０、３３０、３６０の集合およびそれに関連付けられた通信パス３８０、３９５に関連付けられた状態を維持し、定義されたセッションの管理ポリシをカプセル化するオブジェクト、すなわちマネジャ３１０と対話することができる。
【００２３】
チャネル３８０、３９５は所与のセッション３００内の複数のクライアント３２０、３３０、３６０間の潜在的なマルチパーティ通信パスの特定のインスタンスである。チャネル３８０は複数のクライアント３２０、３３０、３６０間で共用でき、２つのクライアント３２０、３３０は別個のチャネル３９５を確立できる。所与のチャネル３８０からメッセージを受信する際にインタレストを登録するすべてのクライアント・オブジェクト３２０、３３０、３６０はそのチャネル３８０で送信されるメッセージを受信する。チャネル３８０、３９５にオブジェクト・レファレンスを所有するすべてのクライアント３２０は所与のチャネル３８０、３９５でメッセージを送信でき、クライアント３２０は複数のチャネル３８０、３９５にレファレンスを持つことができる。このように、例えば、マルチパーティ通信用のチャネル３８０は２つのクライアント３２０、３３０間の通信用のチャネル３９５から分離することができる。
【００２４】
コンシューマ３２５、３３５、３５５、３６５は所与のチャネル３８０、３９５上で送信されるメッセージを受信する際にそのインタレストを登録したクライアント・オブジェクトである。すべてのクライアント３２０、３３０、３６０はコンシューマ３２５、３３５、３５５、３６５になることができ、所与のクライアント３３０は同時に複数のチャネル３８０、３９５のコンシューマ３３５、３５５になることができる。クライアント３２０、３３０、３６０はチャネル３８０、３９５上にコンシューマ３２５、３３５、３５５、３６５を設定してそのチャネル３８０、３９５上で送信されるデータを受信する。このデータは生データに加えて送信元の名前、送信データの優先度、およびデータが送信されたチャネル３８０、３９５の名前を含む。
【００２５】
オブザーバ３１５、３５０、３９０は他のオブジェクトの状態変化を通知された際にそのインタレストを登録したオブジェクトである。オブザーバ３１５、３５０、３９０はチャネル３８０またはトークン３４０上でセッション３００の変化を監視できる。セッション・オブザーバ３１５はセッション３００に参加する、または離脱するクライアント３２０、３３０、３６０に関する情報を通知される。チャネル・オブザーバ３９０はチャネル３８０、３９５に参加する、離脱する、参加の招待を受けている、および放逐されるクライアント３２０、３３０、３６０に関する情報を通知される。トークン・オブザーバ３５０はトークン３４０に参加する、離脱する、参加の招待を受けている、および放逐されるクライアント３２０、３３０、３６０に関する情報を通知される。トークン・オブザーバ３５０はまた、クライアント３２０、３３０、３６０が他のクライアント３２０、３３０、３６０のトークン３４０を付与するまたは入手しようとする場合に通知を受ける。
【００２６】
マネジャ３１０、３４５、３８５は他の所与のオブジェクトの一定の管理ポリシをカプセル化する。セッション３００、チャネル３８０、またはトークン３４０へのアクセスは生成時にそれにマネジャ３１０、３４５、３８５を割り当てることによって制御される。マネジャ３１０、３４５、３８５はこのリソースに参加しようとしているクライアント３２０、３３０、３６０を認証し、それらの応答に基づいて受入れまたは拒否する。個々のチャネル３９５への送信および受信アクセスは私設チャネル機構によって制御できる。あらゆるクライアント３２０、３３０、３６０は私設チャネル３９５を招集でき、その結果、クライアント３２０、３３０、３６０は空きチャネルの私設チャネル・マネジャ３８５になる。チャネル・マネジャ３８５はクライアント３２０、３３０、３６０をチャネル３８０に参加するよう招待し、またはクライアント３２０、３３０、３６０を強制的に離脱させることができる。
【００２７】
トークン３４０、３７０は一意的な分散アトミック動作を提供する同期化オブジェクトである。トークン３４０、３７０を使って多様な異なるアプリケーションレベルの同期化機構を実施して、例えば、共用リソースへの相互に排他的なアクセスを保証することができる。トークン３４０、３７０は排他アクセスを実施する手段を提供する。例えば、マルチポイント・アプリケーション内でリソースを使って１つのサイトだけが所与の時間に所与のリソースを保持できるように保証するため、トークン３４０、３７０を各リソースに関連付けることができる。あるサイトが特定のリソースを使用したい場合、別のサイトが保持していない場合にのみ付与される該当するトークン３４０、３７０を要求する必要がある。単一のトークン３４０、３７０を使って各クライアント３２０、３３０、３６０に非排他的モードでトークン３４０、３７０を入手させて複数クライアントのイベントを調整することができる。クライアント３２０、３３０、３６０は独自に同じトークン３４０、３７０を禁止または解放できる。例えば、すべてのクライアント３２０、３３０、３６０が一括ファイル転送の受信および処理を完了した時点を知りたいという場合、すべての受信側クライアント３２０、３３０、３６０は非排他的に同じトークン３４０、３７０を捕捉（禁止）し、各クライアント３２０、３３０、３６０は禁止された処理を完了した時点でトークン３４０、３７０を解放する。すべてのクライアント３２０、３３０、３６０はトークン３４０、３７０を自由に試験して、トークン３４０、３７０が空いているか、すなわち、クライアント３２０、３３０、３６０の処理が完了したかどうかを判定する。
【００２８】
動作例
マルチポイント・セッション３００でクライアント３２０、３３０、３６０はセッション３００の異なるメンバにデータを送信してトークン３４０、３７０にアクセスしてリソース競合を解決できる。この例はクライアントＤ３３０に関連して後述する。ただし、この説明はセッションに参加する他のすべてのクライアントに適用されることを理解しなくてはならない。クライアント３３０が実行する最初の処理はセッション３００への参加である。クライアント３３０は最初にどのセッションに参加できるかを判定する。
【００２９】
クライアント３３０は次にセッション３００または複数のセッションに参加する。セッションは通常同じサイトまたは異なるサイトに複数のクライアント３２０、３３０、３６０を備える。アプリケーションまたはアプレットは同じセッション３００に複数のクライアント３２０、３３０、３６０を収容できる。アプレットは、Ｓｕｎ  ＭｉｃｒｏｓｙｓｔｅｍｓTMのＪａｖａTM言語で記述されワールド・ワイド・ウェブ（ＷＷＷ）ドキュメントに添付して分配されウェブ・ブラウザによって実行されるプラットフォームに依存しないプログラムである。Ｓｕｎ、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ、Ｓｕｎのロゴ、およびＪａｖａは米国内およびその他の国のＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ  Ｉｎｃ．の登録商標である。各クライアント３２０、３３０、３６０は異なる種類のデータ、すなわち、音声データとビデオ・データを処理することができる。クライアント３３０は複数のセッションのメンバになることができる。
【００３０】
セッション３００が確立され、クライアント３３０がセッション３００に参加すると、クライアント３３０はデータを受信するのに必要な該当するチャネル３８０、３９５に参加する。これらのチャネル３８０、３９５を使用するかどうかはアプリケーション次第である。クライアントが利用できるリソースを管理するトークン３４０、３７０も提供される。チャネル３８０、３９５はセッション全体で使用できるアドレスである。セッション３００のすべてにクライアント３２０、３３０、３６０はチャネル３８０、３９５に参加して送信データを受信し、クライアント３３０はチャネル３８０、３９５の該当する組み合わせに参加し、またそれらのチャネルを消費することによって、これらのチャネル３８０、３９５へ送信されるメッセージを受信し、他のチャネルへ送信されるメッセージを無視するよう選択できる。クライアント３３０はチャネル参加および離脱方法を使って所望のチャネル３８０、３９５に加入し、離脱する。
【００３１】
参加クライアント３２０、３３０、３６０が共通セッション３００にアタッチし、チャネル３８０、３９５の正しい組み合わせに参加すると、クライアントは真のマルチポイント方式でデータを交換できる。
【００３２】
図４はコラボレーション環境でのさまざまなレベルの対話を示すブロック図である。最下位のレベルはトランスポート・レベル４１０である。トランスポート・レベル４１０を使ってネットワークとのインタフェースがとれ、このレベルは送信制御プロトコル（ＴＣＰ）、ユーザ・データグラム・プロトコル（ＵＤＰ）、リモート・メソッド起動（ＲＭＩ）、Ｔ．１２０、共通オブジェクト要求ブローカ・アーキテクチャ（ＣＯＲＢＡ）、スケーラブル・リライアブル・マルチキャスト（ＳＲＭ）、およびその他のトランスポート・レベル４１０の実施形態を含むことができる。
【００３３】
レジストリ４２０はトランスポート・レベル４１０の１つ上のレベルである。レジストリ４２０はサーバとして動作するコンピュータ・システム上に常駐し、すべての現在のセッションおよびクライアントを追跡するために用いられる。一実施形態では、レジストリ４２０はユーザが所与のホスト上でリモート・セッションを獲得するためのブートストラップ・ネーム・サーバである。レジストリ４２０は実際、すべての利用可能なセッションおよびクライアントのリストを含むレコードである。レジストリ４２０の上にはセッション管理４３０がある。セッション管理４３０は進行中の個々のセッションのマネジャとして動作する。各セッションには独立した管理ブロックがあり、これらの管理ブロックはすべてセッション管理４３０を共に形成する。
【００３４】
レジストリと同じレベルに分散データ共用４４０がある。分散データ共用４４０を使ってさまざまなタイプのデータ・オブジェクトをいくつかのクライアント間で共用できる。分散データ共用４４０を使って共用オブジェクト４５０、共用プリミティブ４６０、トークン４７０およびパブリッシュ／サブスクライブ・タプル４８０の共用が可能である。分散データ共用４４０はチャネルとデータ送信および受信ソフトウェアも含む。
【００３５】
共用オブジェクト４５０はセッション管理４３０の上位に常駐する。共用オブジェクト４５０はセッション、チャネル、データ、トークン、オブザーバ、コンシューマ、マネジャ、およびプリミティブを含む。これらのオブジェクトに関連付けられたすべてのデータはデータ共用４４０を使って共用できる。一実施形態では、共用オブジェクト４５０によってマルチポイント・コラボレーション環境外でもオブジェクトを共用することができる。
【００３６】
共用プリミティブ４６０は分散データ共用４４０およびセッション管理４３０の上位に常駐する。共用プリミティブ４６０を使ってセッションのメンバ間で共用される簡素な名前付きデータ要素を作成して更新できる。共用プリミティブはブール、倍精度、浮動、整数、ｌｏｎｇ型、およびｓｔｒｉｎｇ型を含む。共用プリミティブ４６０は常に最新の内部値を持つ。
【００３７】
トークン４７０は共用プリミティブ４６０の上位に常駐する。トークン４７０は共用リソースへの排他的アクセスを実施する手段を提供する。トークン４７０はそのようなリソースに関連付けられている。あるサイトが特定のリソースを使用したい場合、別のサイトが保持していない場合にのみ付与されるそのリソースのトークンを要求する必要がある。またトークン４７０を使って複数のクライアントが同時に共用できる非排他的トークンを持つことによって複数クライアントのイベントを調整することができる。
【００３８】
パブリシュ／サブスクライブ・タプル４８０は共用プリミティブ４６０の上位に常駐する。パブリシュ／サブスクライブ・タプル４８０はすべてのクライアントと関連付けられている。パブリシュ／サブスクライブ・タプル４８０を使ってクライアントはコラボレーション・システム上に情報を公表し他のクライアントのパブリケーションに参加することができる。
【００３９】
図５はレジストリ４２０でセッションに参加または登録する流れ図である。ブロック５１０でユニバーサル・リソース・ロケータ（ＲＬ）がクライアントから受信される。一実施形態では、リソース・ロケータは次の形式である。
ｃｏｌｌ：／／＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｔｙｐｅ＞／Ｓｅｓｓｉｏｎ／＜ｓｅｓｓｉｏｎ＿ｎａｍｅ＞
または
ｃｏｌｌ：／／＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｔｙｐｅ＞／Ｃｌｉｅｎｔ／＜Ｃｌｉｅｎｔ＿ｎａｍｅ＞
上式でブラケット「＜  ＞」内の情報は実際の名前で代入される。ｈｏｓｔ：ｐｏｒｔはこの特定のコラボレーションの指定サーバの位置を示す。ｈｏｓｔはホスト・コンピュータの名前を示す。ｐｏｒｔは現在のセッションまたはクライアントを確立するコンピュータのポート番号を示す。ｔｙｐｅは例えばＴＣＰ、ＵＤＰ、ＲＭＩ、Ｔ．１２０、ＣＯＲＢＡ、ＳＲＭ、その他のトランスポート・タイプを含むコラボレーション参加のタイプを示す。ＳｅｓｓｉｏｎまたはＣｌｉｅｎｔはＲＬがセッションまたはクライアントのどちらを参照しているかを決定する。セッション名およびクライアント名はあらためて説明するまでもない。
【００４０】
ブロック５２０で、ＲＬが解析される。ＲＬの解析では上記の要素が分離されてＲＬが分析される。
【００４１】
ブロック５３０で、受信したＲＬはレジストリ内のすべてのＲＬと比較される。それぞれの確立されたセッションは他のユーザが同じセッションに参加するためのレジストリ内に記憶されたＲＬを備える。このように、ＲＬの各要素はレジストリ内のすべてのＲＬと比較される。
【００４２】
ブロック５４０で、処理は受信したＲＬがレジストリ内のあるＲＬと同じかどうか判定する。ＲＬがすでにレジストリにある場合、処理は直接ブロック５７０に移行する。そうでない場合、処理はブロック５５０に移行する。
【００４３】
ブロック５５０で、ＲＬ内に指定されたトランスポート機構のタイプが判定される。すなわち、ＴＣＰ、ＵＤＰ、ＲＭＩ、Ｔ．１２０、ＣＯＲＢＡ、ＳＲＭなどの指定されたタイプが識別される。このように、ｃｏｌｌ：／／ｓｔａｒｄ．Ｅｎｇ：４４６１／ＴＣＰ／Ｓｅｓｓｉｏｎ／ＣｈａｔＳｅｓｓｉｏｎ／などのＲＬのタイプは「ＴＣＰ」である。
【００４４】
ブロック５６０で、レジストリに新しいＲＬが追加される。レジストリへのＲＬの追加によってユーザ／クライアントはコラボレーション・セッションへの参加の登録ができる。レジストリ２２０は異なるトランスポート機構のセッションを確立することができる。
【００４５】
ブロック５７０で、確立されたセッションの位置を示す位置標識がユーザに返送される。一実施形態では、位置標識はレジストリ中のＲＬを指すポインタである。別の実施形態では、位置標識はインターネット・アドレスである。一実施形態では、セッションはレジストリが存在する同じサーバ上で確立される。また、ＲＬが示す異なるコンピュータ上でセッションを確立することもできる。
【００４６】
ブロック５８０で、クライアントは位置標識の受信に応答してオブジェクト・クラスオブジェクトおよび該当するプロトコル・スタックを動的にロードする。一実施形態では、オブジェクト・クラスはＳｈａｒｅｄＤａｔａクラスである。それぞれのタイプのトランスポート機能は協働してネットワーク関数セットを提供する層状のプロトコル・セットであるプロトコル・スタックを有する。プロトコル・スタックは国際標準化機構の７つのレイヤ・モデルに準拠することができる。マルチポイント・コラボレーション・システム内の各クライアントでは少なくとも１つのプロトコル・スタックが利用できる。ＲＬ位置標識の受信に応答して、クライアントの動的ローダ２５０が該当するプロトコル・スタックをロードし、クライアントはセッションとの通信が可能になる。一実施形態では、プロトコル・スタックは自動的にロードされる、すなわち、クライアントまたはユーザは現在のシステムと対話せずに新しいプロトコルを選択できる。
【００４７】
上記の明細書で、本発明を特定の実施形態に関連して記述してきた。ただし、本発明のより広汎な精神と範囲を逸脱することなく本発明にさまざまな変更と修正を加えることができるのは明らかであろう。したがって、本明細書および図面は限定的でなく例示的な意味で理解すべきである。本発明は上記の実施形態および例によって限定されるものと解釈すべきではなく、特許請求の範囲およびその同等の内容に従って解釈すべきである。
【図面の簡単な説明】
【図１】  本発明が実施されるコンピュータ・ネットワークの一実施形態を示すブロック図である。
【図２】  本発明の一実施形態の概略図である。
【図３】  セッションの一例を示すブロック図である。
【図４】  アプリケーション・インタフェース全体の一実施形態を示すブロック図である。
【図５】  トランスポート機構を動的にロードする１つの方法を示す流れ図である。
【符号の説明】
２２０  アプリケーション・ユーザ・インタフェース
２３０  レジストリ
２４０  パーサ
２５０  動的ローダ
２６０  コンパレータ
２７０  メモリ
２８０  セッション・マネジャ
【図１】
0004477154.tif 000002
【図２】
0004477154.tif 000003
【図３】
0004477154.tif 000004
【図４】
0004477154.tif 000005
【図５】
0004477154.tif 000006