カンファレンス・データの共有を提供する装置および方法
SIPカンファレンスのカンファレンス参加者間でのデータ共有方法が開示される。この方法には、カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答して、SIPメッセージによって、他のカンファレンス参加者に使用される共有データをUAが保存し得るカンファレンシング・サーバのDSS（データ共有サーバ（data sharing server））に関連づけられた保存場所のアドレスをUAに通知するステップと、保存場所のアドレスにデータを保存するステップと、他のカンファレンス参加者に対する共有データへのアクセスおよび共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定するステップとが含まれる。また、SIPカンファレンス・サーバ（10）の一部として、1人以上のSIPカンファレンス参加者により保存される共有データの保存、アクセス制御、および配布を提供するデータ共有サーバ（14）が開示される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に無線通信システムおよびその方法に関し、特に、複数参加型カンファレンスの確立および実施を行なうためのSIP（セッション開始プロトコル（Session Initiation Protocol））を使用する、無線端末および無線ネットワークノードに関する。
【背景技術】
【０００２】
SIP（セッション開始プロトコル（Session Initiation Protocol））は、IETF RFC3261（ローゼンバーグ（Rosenberg）等。2002年6月）で定義されている。一般に、SIPは、1人以上の参加者とのセッションを開始、変更、終了させるための、アプリケーション層制御（シグナリング）プロトコルである。このセッションには、インターネット電話による通話、マルチメディアの配布およびマルチメディア・カンファレンスなどが含まれる。セッションの生成に使用されるSIPインビテーションは、参加者らが一連の互換性のあるメディア形式に一致させることを可能とさせるセッション記述を伝える。SIPは、プロキシサーバと呼ばれるエレメントを使用し、ユーザの現在地への要求のルーティング、サービスに対するユーザの認証および権限の付与、プロバイダの呼ルーティング・ポリシーのインプリメンテーション、およびユーザに対する機能の提供を手助けする。また、SIPは、ユーザがプロキシサーバで使用されるユーザの現在地をアップロードすることが可能となる登録機能も提供する。SIPは、いくつかの異なったトランスポートプロトコル上で動作する。本発明に最も関わる点は、カンファレンス用のSIPの使用についてである。
【０００３】
まず、SIPは、一般的にコンテンツの間接化（content indirection）と称される、データへのアクセスを提供するメカニズムを含むことに注目する。特に、IETFドラフト「draft−ietf−sip−content−indirect−mech−03」の「SIP（セッション開始プロトコル）メッセージにおけるコンテンツの間接化メカニズム（A Mechanism for Content Indirection in Session Initiation Protocol （SIP） Messages）」（S.オルソン（S. Olson）、2003年6月2日）と題される中では、SIPメッセージにおけるコンテンツの間接化用に提供されるメカニズムが記されている。一般的に、SIPの目的は、1人以上の参加者とのセッションの生成、変更、終了を行なうことであり、HTTPと同様にSIPメッセージは、スタートライン、1つ以上のヘッダおよび任意のボディから構文的に構成される。しかし、HTTPとは異なり、SIPは汎用データ伝送として設計されていない。
【０００４】
SIPメッセージボディのコンテンツを間接的に指定することが望ましいであろうということについて、様々な理由がある。間接化を行なうことにより、セルラー式無線アプリケーションなどの、帯域幅が制限されたアプリケーションでは、リソースの限られたリンクにおいて、受信者がコンテンツを取得するか否かを決定することができるようなメタデータを用いて（間接）コンテンツに、注釈をつける手段が提供される。転送されるコンテンツのサイズが大きく、中間に置かれるシグナリング・プロキシをサイズ的に圧倒してしまうことで、ネットワークの待ち時間を無用に増やしてしまうようなことがある。リアルタイム性を要するSIPアプリケーションでは、これは許されないことであろう。間接コンテンツを使用して、コンテンツの転送をSIPシグナリング・ネットワークから、潜在的に分離されたデータ転送チャネルへ移動させることで、これらの問題を緩和させることができる。また、伝達される必要のあるセッション関連のデータ（ボディ）がエンドポイントまたはユーザ・エージェント（UA）に直接ないケースもあるだろう。そのような場合、SIPメッセージが所望のコンテンツに対する間接的な参照を含むことを可能とするようなメカニズムを有することが望ましい。受信者は、この間接的な参照を使用し、HTTP、FTP、またはLDAP等の非SIP転送チャネルを介してコンテンツを取得する。このIETFドラフトには、コンテンツの間接化の目的は、単にSIP MIMEボディ部に対して代替の転送メカニズムを提供することであると述べられている。転送メカニズムの例外として、間接化されたボディ部は、インラインボディ部と同等であり同一の扱いを受けるべきである。
【０００５】
本発明者らは、以前にカンファレンス制御の必要性を認識し、SIPおよびSOAP（シンプル・オブジェクト・アクセス・プロトコル（Simple Object Access Protocol））に基づいた、コンポーネントベースのスケーラブル・カンファレンス制御フレームワークを提案している。これに関しては、NOSSDAV'02、2002年5月12日−14日、アメリカ合衆国、フロリダ州、マイアミビーチに行なわれた「SIPベースのカンファレンス制御フレームワーク（A SIP−based Conference Control Framework）」ペトリ・コスケライネン（Petri Koskelainen）、へニング・シュルツリンヌ（Henning Schulzrinne）、シャオタオ・ウー（Xiaotao Wu）、を参照することができる。
【０００６】
また、「セッション開始プロトコルでのカンファレンシング用フレームワーク（A Framework for Conferencing with the Session Initiation Protocol）」、J.ローゼンバーグ（J. Rosenberg）、draft−ietf−sipping−conferencing−framework−01、2003年10月27日のインターネット・ドラフトも注目される。
【０００７】
本発明を適切な技術的背景に位置させるため、SIPカンファレンスの簡単な説明を示す。まず、多くの役立つ定義を紹介し、次に、図1および図2におけるSIPカンファレンシングの一般的な議論を示す。
【０００８】
一般的に、SIPカンファレンスは複数相手の会話のインスタンスである。疎結合カンファレンスは、参加者間の調整されたシグナリング関係がないカンファレンスである。疎結合カンファレンスは、カンファレンス・メンバーシップの配布にマルチキャストを頻繁に使用する。密結合カンファレンスは、フォーカスと呼ばれる1つのユーザ・エージェントが各参加者とのダイアログを保持するカンファレンスである。フォーカスは、カンファレンスの集中的マネージャの働きをし、カンファレンスURIによってアドレスされる。フォーカスは、カンファレンスURIでアドレスされ、カンファレンス（すなわち、一意の複数相手会話のインスタンス）を識別するSIPユーザ・エージェントである。フォーカスは、カンファレンスの各参加者とのSIPシグナリング関係を保持する。フォーカスは、何らかの方法で、カンファレンスを構成するメディアを各参加者が確実に受け取ることができるようにする役割をする。また、フォーカスは、カンファレンス・ポリシーもインプリメントする。フォーカスは、論理的な役割である。カンファレンスURIは、カンファレンスのフォーカスを識別するURIで、通常はSIP URIである。ユーザまたはオートマトン（automata）をカンファレンスに接続するソフトウェア・エレメントは、参加者と呼ばれる。参加者は、最小で、SIPユーザ・エージェントを含み、また、例えばカンファレンス・ポリシー制御プロトコル・クライアントも含んでも良い。カンファレンス通知サービスは、フォーカスにより提供される、論理的な機能である。フォーカスは、通知者として動作し、カンファレンス状態へのサブスクリプションを受け付け、サブスクライバにその状態への変更について知らせることができる。この状態には、フォーカス自体により保持された状態、カンファレンス・ポリシー、およびメディア・ポリシーが含まれる。カンファレンス・ポリシー・サーバは、カンファレンス・ポリシーを格納および操作することができる論理的な機能である。カンファレンス・ポリシーは、カンファレンスのオペレーションを支配する全体的なルールのセットである。これは、メンバーシップ・ポリシーおよびメディア・ポリシーに分けられる。フォーカスとは異なり、各カンファレンス・ポリシー・サーバのインスタンスはないが、各カンファレンスに対するメンバーシップおよびメディア・ポリシーのインスタンスがある。カンファレンス・ポリシーとは、カンファレンス・ポリシー・サーバにより操作される特定のカンファレンス用のルールのセットである。これには、メンバーシップ・ポリシーおよびメディア・ポリシーが含まれる。各カンファレンスに対するカンファレンス・ポリシーのインスタンスがある。メンバーシップ・ポリシーは、特定のカンファレンスの参加に関するカンファレンス・ポリシー・サーバによって操作されるルールのセットである。これらのルールには、カンファレンスのライフスパンについての指令、誰がカンファレンスに参加できるか誰ができないか、カンファレンスで有効な役割の定義、およびこれらの役割に関連付けられた責務、ならびに誰がどの役割を要求することが許されているかについてのポリシーが含まれる。メディア・ポリシーは、カンファレンスのメディア構成に関して、カンファレンス・ポリシー・サーバにより操作されるルールのセットである。メディア・ポリシーは、カンファレンスのミキシング特性を決定するために、フォーカスにより使用される。メディア・ポリシーには、どの参加者が他のどの参加者からメディアを受け取るかについてのルール、およびメディアが各参加者に対して結合される方法が含まれる。音声の場合、これらのルールに各参加者がミックスされた相対的なボリュームを含めることができる。映像の場合、これらのルールは、映像がタイル型か、映像が声の一番大きい話者を示すかなどを示すことができる。CPCP（カンファレンス・ポリシー制御プロトコル（Conference Policy Control Protocol））は、カンファレンス・ポリシーを操作するため、クライアントに使用されるプロトコルである。ミキサは、同じ形式のメディア・ストリームのセットを受信し、形式特定の方法でそれらのメディアを結合し、その結果を各参加者に再配布するコンポーネントである。これには、RTP（RFC1889参照）を使用して転送されたメディアも含まれる。これらの様々な定義の参照に便利な、draft−ietf−sipping−conferencing−framework−01ドキュメントでは、インスタント・メッセージング・セッションのような非RTPベースのメディアを可能としているため、ミキサは、RFC1889で定義されたミキサの概念のスーパーセットであると考えられている。カンファレンス・サーバは、少なくとも、フォーカスを含む物理的なサーバである。これには、カンファレンス・ポリシー・サーバおよびミキサも含まれても良い。
【０００９】
本願発明の理解に有用な定義を以上にで示したところで、次に図1を参照する。SIPカンファレンスの中心のコンポーネントは、フォーカス1である。フォーカス1は、カンファレンスにおける各参加者2とのSIPシグナリング関係を維持する（図2では、参加者はUA（ユーザ・エージェント）としても示される）。結果は、スター型トポロジーである。フォーカス1は、カンファレンスを構成するメディア・ストリームをカンファレンスの参加者2が確実に利用できるようにする働きをする。フォーカス1は、この機能を1つ以上のミキサ3を使用して行なう。ミキサ3の各々は、多数の入力メディア・ストリームを結合して1つ以上の出力メディア・ストリームを生成する。フォーカス1は、ミキサ3の適切な構成を決定するため、メディア・ポリシーを使用する。フォーカス1は、各カンファレンスに対して、そのインスタンスが存在するところのカンファレンス・ポリシー（メンバーシップおよびメディア・ポリシーより構成）へのアクセスを有する。事実上、カンファレンス・ポリシーは、カンファレンスが動作すべき方法を記述するデータベースとして考えることができる。これらのポリシーを実行する役割を担うのが、フォーカス1である。フォーカス1は、データベースへの読み出しアクセスを行なう必要のみでなく、データベースに変更が加えられた時期も知る必要がある。このような変更は、SIPシグナリングを引き起こす可能性があり（例えば、カンファレンスからのユーザの退出など）、ほとんどの変更で、カンファレンス通知サービスを使用して、サブスクライバに通知が送信されることが要求される。カンファレンスは、フォーカス1を識別するURIにより表される。各カンファレンスは、一意のフォーカス1と、フォーカス1を識別する一意のURIを持つ。カンファレンスURIへの要求は、特定のカンファレンス用のフォーカス1に経由される。ユーザは、通常、カンファレンスURIへINVITEを送信することでカンファレンスに参加する。カンファレンス・ポリシーで許可される限り、INVITEはフォーカス1によって受け付けられ、ユーザはカンファレンスに参加させられる。ユーザは、通常の通話で行なわれるように、BYEを送信することでカンファレンスから退席することができる。同様に、参加者2のカンファレンスへの参加がもはや許可されていないことを示すようにカンファレンス・ポリシーが変更された場合、フォーカス1は当該参加者とのダイアログを終了させることができる。また、フォーカス1がカンファレンスに参加者を参加させる必要があることをカンファレンス・ポリシーが示す場合、フォーカス1はINVITEを開始することもできる。
【００１０】
図2は、カンファレンス機能を示す全体図である。参加者2は、エンハンスされた呼制御機能にアクセスするため、REFERなどの拡張を使用してフォーカス1とインタラクトすることができる。参加者2は、カンファレンスURIへSUBSCRIBEし、フォーカス1に提供されるカンファレンス通知サービスに接続することができる。このメカニズムを通して、参加者（事実上、ダイアログの状態）、メディア・ポリシー、およびメンバーシップ・ポリシーにおける変更を知ることができる。参加者2は、CPCP（カンファレンス・ポリシー制御プロトコル（conference policy control protocol））5を使用して、CPS（カンファレンス・ポリシー・サーバ）4と通信することができる。CPCP5の使用により、参加者2は、カンファレンス・ポリシー6に作用することができる。カンファレンス・ポリシー6は常に利用可能であるが、カンファレンス・ポリシー・サーバ4は、いかなる特定のカンファレンスにおいてでも利用可能である必要はない。フォーカス1とカンファレンス・ポリシー6との間、およびカンファレンス・ポリシー・サーバ4とカンファレンス・ポリシー6との間のインターフェースは、主としてカンファレンスに含まれる論理的役割を示すことを意図している。さらに全体を示すため、図2において、カンファレンス通知サービス7がサブスクリプション・インターフェースを介して、参加者2に接続されている。
【００１１】
draft−ietf−sipping−conferencing−framework−01ドキュメントに記載された全体的なフレームワークにおいて、カンファレンスはURIによって一意に識別され、このURIによってカンファレンスの責務を担うフォーカス1が識別されるとういうことは、基本的なことである。カンファレンスURIは一意であり、2つのカンファレンスが同じカンファレンスURIを持つことはない。カンファレンスURIは、常に、SIPまたはSIPS（セキュアSIP（Secure SIP））URIである。PSTNゲートウェイ上のユーザまたはインターフェースとは対照的に、カンファレンスURIは、これを使用することになるいずれの参加者にも不透明、つまり、URIを見て、フォーカス1を識別しているかどうかを確実に知る方法が無い。しかし、URIを囲むコンテキスト上の情報（例えば、SIPヘッダ・パラメータなど）により、そのURIがカンファレンスを表していることが示されることがある。SIP要求がカンファレンスURIに送信される際、その要求はフォーカス1にルートされ、これはフォーカス1に対してのみである。カンファレンスURIを作成するエレメントまたはシステムは、この性質を保証する役割を果たす。カンファレンスURIは、長期間のカンファレンスもしくはインタレスト・グループを表すことができ、またはアドホック・カンファレンスなどの短期間のカンファレンスを表すこともできる。
【００１２】
本発明以前は、SIPカンファレンシングの一態様は、カンファレンス参加者2間のデータ共有の概念に関して、適切に定義または指定されていなかった。
【非特許文献１】IETF RFC3261（ローゼンバーグ（Rosenberg）等。2002年6月）
【非特許文献２】IETFドラフト「SIP（セッション開始プロトコル）メッセージにおけるコンテンツの間接化メカニズム（A Mechanism for Content Indirection in Session Initiation Protocol （SIP） Messages）」（S.オルソン（S. Olson）、2003年6月2日）
【非特許文献３】「SIPベースのカンファレンス制御フレームワーク（A SIP−based Conference Control Framework）」ペトリ・コスケライネン（Petri Koskelainen）、へニング・シュルツリンヌ（Henning Schulzrinne）、シャオタオ・ウー（Xiaotao Wu）；NOSSDAV'02、2002年5月12日−14日、アメリカ合衆国
【非特許文献４】「セッション開始プロトコルでのカンファレンシング用フレームワーク（A Framework for Conferencing with the Session Initiation Protocol）」、J.ローゼンバーグ（J. Rosenberg）、インターネット・ドラフト、2003年10月27日
【好適な実施形態のまとめ】
【００１３】
これらの教示について現在好適な実施形態によれば、上記およびその他の問題が解決され、他の有利な点が実現される。
【００１４】
本発明は、カンファレンス・ポリシーの操作の概念に関し、ユーザがCPCP（カンファレンス・ポリシー制御プロトコル（Conference Policy Control Protocol））を使用して、CPS（カンファレンス・ポリシー・サーバ（conference policy server））にカンファレンスを作成することができ、ACL（アクセス制御リスト（Access Control Lists））、ダイアルアウト・ユーザ・リスト、およびRTPメディア・ストリームのようなカンファレンス・パラメータを設定することができるものである。
【００１５】
本発明によれば、複数参加型のカンファレンシング、特にデータ共有のための付加的な使用例およびメカニズムが記載されている。本発明によるデータ共有は、アプリケーション共有では一般的に終端端末に特別なアプリケーションを必要とする点において、アプリケーション共有（ドキュメントを共有できる）とは区別することができる。
【００１６】
本発明によるSIPカンファレンシングのデータ共有では、ユーザは、ドキュメント、ファイル、およびデータをCPSにアップロードすることができ、CPCPを使用して、アップロードされたデータに対するアクセス・ポリシーおよび処理オペレーションを設定することができる。例えば、ユーザは音楽ファイルをアップロードし、すべての参加者がこの音楽ファイルに対して読み取りアクセスができるが、削除はできないように指定することができる。
【００１７】
また、CPSは、画像データを含むドキュメントなども、本発明によって拡張されたCPCPを介して提供される命令に基づいて、操作することもできる。ドキュメント処理オペレーションには、例えば、限定されないが、画像のリサイズ、ドキュメントの他形式への変換、およびすべてのカンファレンス参加者に対するドキュメントのプッシュなどを含めることができる。
【００１８】
本発明の1つの態様において、データ共有およびCPCPを新規で自明でない方法によって結びつけることで、ドキュメント操作を可能とし、これによって、IPに対し新しいサービス、すなわちSIPベースのカンファレンシングを作成する。
【００１９】
本発明の1つの態様において、SIPカンファレンスのカンファレンス参加者間でのデータ共有方法が提供される。この方法には、カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答して、SIPメッセージによって、他のカンファレンス参加者に使用される共有データをUAが保存し得るカンファレンシング・サーバのDSS（データ共有サーバ（data sharing server））に関連づけられた保存場所のアドレスをUAに通知するステップと、保存場所のアドレスにデータを保存するステップと、他のカンファレンス参加者に対する、共有データへのアクセスおよび共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定するステップとが含まれる。
【００２０】
また、SIPカンファレンス・サーバの一部として、1人以上のSIPカンファレンス参加者により保存される共有データの保存、アクセス制御、および配布を提供するDSS（データ共有サーバ（Data Sharing Server））が開示される。
【００２１】
したがって、本発明の1つの態様において、カンファレンス参加者であるUAによるデータ共有エレメント作成要求に応じて、他のカンファレンス参加者に使用される共有データをUAが保存し得るDSSに関連づけられた保存場所のアドレスをSIPメッセージでUAに通知する、少なくとも1つのデータ・プロセッサを備えたSIPカンファレンス・サーバが提供される。このデータ・プロセッサは、さらにUAからのデータの受信に応じて、保存場所のアドレスにデータを保存し、他のカンファレンス参加者に対する、共有データへのアクセスおよび共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定する。
【００２２】
さらに、本発明の1つの態様において、カンファレンス参加者として機能するデータ・プロセッサを備え、SIPカンファレンス・サーバとともに動作可能なUAであって、このデータ・プロセッサが、SIPカンファレンス・サーバにデータ共有エレメントの作成を要求し、UAが他のカンファレンス参加者に使用される共有データを保存し得るDSSに関連づけられた保存場所のアドレスを示す通知をSIPメッセージによって受信し、保存場所のアドレスに保存するため、DSSにデータを送信し、CPCP（カンファレンス・ポリシー制御プロトコル（Conference Policy Control Protocol））を介して、CPS（カンファレンス・ポリシー・サーバ（Conference Policy Server））へ情報を送信して、他のカンファレンス参加者に対する、共有データへのアクセスおよび共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定する、UAが提供される。
【００２３】
本発明の好適な実施形態において、データは、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理（Web−based Distributed Authoring and Versioning）、RTP、MIME（多目的インターネット・メール拡張機能（Multipurpose Internet Mail Extensions））カプセル化を持つTCPパイプのうち1つを使用するような非SIPプロシージャを用いて、DSSに送信される。
【００２４】
本発明の好適な実施形態において、UAは、保存場所のアドレスを指定するURI（ユニフォーム・リソース識別子（Uniform Resource Identifier））に含まれるアドレスの通知を受信する。
【００２５】
本発明の好適な実施形態において、データが、そのデータの少なくとも1つの名前とともにDSSに送信され、またそのデータの形式もともに送信されてもよい。共有データには、ファイルおよび実行可能なアプリケーションの少なくとも1つが含まれてもよい。
【００２６】
UAは、携帯電話または携帯電話の一部であってもよい。
【００２７】
これらの教示の上記およびその他の態様は、以下の発明を実施するための最良の形態を添付の図面とともに読むことで明らかになるであろう。
【好適な実施形態の詳細な説明】
【００２８】
図3を参照すると、本発明の一実施形態によるカンファレンシング・サーバ10、さらにUA2とカンファレンシング・サーバ10とのインターフェースが示されている。図3に示される、他のUA2もカンファレンスの参加者であり、カンファレンシング・サーバ10に同様の方法で接続されているものとする。UA2は、SIPダイアログを介してフォーカス1へ、本発明に従って機能するように変更されたCPCP（すなわちCPCP5'と称す）を介してCPS4へ接続されている。カンファレンシング・サーバ10は、さらに、少なくとも1つのミキサ3、ビデオ・サーバ12、本発明によるDSS14（データ共有サーバ（Data Sharing Server））を備えている。UA2は、RTPオーディオ・インターフェース3Aを介しミキサ3に、RTPビデオ・インターフェース12Aを介しビデオ・サーバ12に、DSP（データ共有プロトコル（Data Sharing Protocol））14Aをインプリメントする共有データ・インターフェースを介しDSS14に、それぞれ接続されている。
【００２９】
一般に、DSS14は、CPS4と同一場所に配置するか、図3に示されるようにCPS4に制御される別のサーバとして実装することができる。カンファレンス・ポリシー6（図2に図示）をCPS4およびCPCP5'を介して変更し、どのような形式の共有データがDSS14により保存されるか、どの参加者が共有データを読み出し／書き込み／変更することができるのか、およびDSS14により共有データがどのように作用されるのかを決定することができる。共有データは、ファイルの形態であったり、またはアクティブに動作するアプリケーションであってもよく、DSS14を用いた共有データ・インターフェースを介し、好ましくは、TCP（伝送制御プロトコル（Transmission Control Protocol））などの非SIPメカニズムによって、アクセスされる。動作アプリケーションの限定されない例として、ゲームがある。
【００３０】
DSP14Aは、以下の（限定されない）伝送メカニズムのいずれかを使用してインプリメントしても良い。すなわち、HTTP、ユーザが遠隔Webサーバ上のファイルを共同で編集および管理することを可能とするHTTPプロトコルの拡張セットであるWebDav（Webベースの分散オーサリングおよびバージョン管理（Web−based Distributed Authoring and Versioning）、好ましくはマルチキャスト動作を含む前方誤り訂正を有するRTP、MIME（多目的インターネット・メール拡張機能（Multipurpose Internet Mail Extensions））カプセル化を持つTCPパイプであってもよく、上記のバリエーションのいずれかを使用してインプリメントしても良い。DSP14Aの主な機能は、クライアント（UA2）およびDSS14間でデータを伝達することである。また、DSP14Aは、共有データに関連する名前など（実際のデータに先行するRTPヘッダ、またはMIMEヘッダ内にある）、共有データに関する最小限の情報を伝達することも好ましい。
【００３１】
一般的に、MIMEはそもそも、非US−ASCIIテキスト・メッセージ、非テキスト・メッセージ、マルチパート・メッセージ・ボディ、およびメッセージ・ヘッダ中の非US−ASCII情報を可能とするために、インターネット・メールのフォーマットを拡張することを意図していた。次のRFCでMIMEが定義されている。
RFC 2045： MIMEパート1：インターネット・メッセージ・ボディのフォーマット（Format of Internet Message Bodies）
RFC 2046： MIMEパート2：メディア・タイプ（Media Types）
RFC 2047： MIMEパート3：非ASCIIテキスト用のメッセージ・ヘッダ拡張（Message Header Extensions for Non−ASCII Text）
RFC 2048： MIMEパート4：登録手順（Registration Procedures）
RFC 2049： MIMEパート5：適合性基準と例（Conformance Criteria and Examples）
【００３２】
クライアント（UA2）が発行できるポリシー・コマンドの例には次のようなものが挙げられるが、これらに限定はされない。
a）いずれの参加者もDSS14にある私のファイルを読み出すことができる。
b）参加者x（例えば、私のアシスタント）がDSS14にある私のファイルをアップデートすることができる。
c）私の「近接BLOB（"proximity blob"）」は、毎金曜日にアクティブ化する。
d）参加者yがimage_l用のファイルを読み出した際に私は警告を受けるべきである。
e）JPEGデータは、すべての参加者に送信されるべきである（しかし、小型ディスプレイを持つクライアントにはQCIFに縮小する）。QCIFとは、クォーター・コモン・インターミディエート・フォーマット（Quarter Common Intermediate Format）であり、各フレームに、144行および各行176ピクセルを含み（すなわちフルCIFの解像度の1／4、）、30フレーム／秒（fps）のデータ・レートを指定する、ビデオ・カンファレンシング・フォーマットである（QCIFのサポートがITU H.261のビデオ・カンファレンシング標準で必要とされている。）。
【００３３】
図3の実施形態において、カンファレンシング・サーバ10は、自らの状態に基づいて、自らのメンバーへの出力データを生成する。例えば、フロア制御が使用されている場合、1つのオーディオのみがミキサ3を通過する。典型的な場合では、いずれのUA2もDSS14にデータを保存することでデータを共有でき、上述のように、CPCP5'を用いて他のUAにアクセス権を与える／拒否することができる。カンファレンシング・サーバ10は、DSS14からカンファレンスの参加者へ、データを送信またはプッシュしてもよく、このデータは処理されたものであってもよい（例えば、ビデオ・サーバ12からのQCIFビデオデータとしてのビデオデータ）。
【００３４】
図4は、クライアントUA2およびDSS14間のインタラクションを示す、シグナリングおよびデータ・フロー図である。ステップAでは、UA2がDSS14にデータ共有エレメントを作成するように要求している。この要求は、CPCP5'およびCPS4を介して行なわれる。ステップBでは、UA2は、DSS14内にあるUA2に割り当てられた共有データ保存位置のアドレスを識別するURIを、CPS4およびCPCP5'を介して、DSS14により通知される。ステップCでは、UA2がDSP14Aを介し（例えば、HTTPを使用して）、ステップBで識別されたURIへ共有データを送信する。先に述べたように、データ・コンテンツに加えて、データを識別する情報（データ名、データ形式など）も送信されることが好ましい。
【００３５】
上記は、SIPコンテンツの間接化動作を用いるものであってもよいが、本発明の好適な実施形態において、カンファレンスに参加中のユーザに、データ共有機能の提供およびサポートに必要な様々な情報を伝えるために、SIPペイロード（SDP）が用いられる。例えば、ユーザは、SIPペイロードを介して、RTPオーディオ・ミキサ3およびRTPビデオ・サーバ12のアドレス、さらに本発明の一実施形態に係るDSS14のアドレスを知ることができる。本発明の好適な実施形態において、DSS14内のデータに対する操作およびポリシーの定義には、カンファレンス・ポリシー制御プロトコル5'が用いられている。
【００３６】
図4について、さらに説明すると、ステップDでは、DSP14Aを用いて、データ保存操作の成功をUA2に伝える。ステップEでは、カンファレンス参加者ボブに保存された共有データ・ファイルの読み出しの許可を与える命令、および参加者アリスへの保存された共有データ・ファイルの送信を行なう命令（QCIFを用いて圧縮されている）などの、少なくとも1つのカンファレンス関連の共有データ・ポリシー・コマンドをUA2が送信する。ステップFでは、これらのコマンドの受け取り（実行）が肯定応答され、ステップGでは、参加者ボブがファイルを読み取ったことをクライアントに知らせる、SIP通知メッセージが（SIPダイアログを介して）送信される。
【００３７】
図4に示された上記のコマンド、インタラクション、およびデータ・フローは、例にすぎず、本発明の実施において、限定を意図するものとして読まれるものではない。
【００３８】
上記の実施形態において、SIPカンファレンシング・サーバ10およびUA2の各々が、本発明によるSIP関連のカンファレンス・データ共有手順、およびプロトコルを実行可能な、1つ以上のプログラムされたデジタル・データ・プロセッサを含んでいることを理解されよう。例えば、UA2は、SIPカンファレンシング・サーバ10から受信されるSIPメッセージからURIを抽出し、抽出されたURIの指定するアドレスへ保存されるように、共有するデータをDSS14に順に送信するような、格納されたプログラムに従って動作する、組み込み用マイクロプロセッサを内蔵した携帯電話、または個人用通信機に具現化されても良い。
【００３９】
上記記載は、本発明を実施するため、発明者らにより現時点で考慮された最良の方法および装置について、余すところなく情報を提供する、限定の意図を有しない例を示す記載であるが、前述の記載に鑑みて、添付図面および特許請求の範囲とともに併せ読むことにより、種々の変更および改作などが可能であることは、本願発明に関連する技術の分野における当業者に理解されよう。また、いくつかの例において、当業者は、他の同様または同等のファイル形式、メッセージ形式、データ転送メカニズム、および同種のものの使用を試みることもできよう。しかし、本発明の教示によるこれらすべておよび同等の変更は、本発明の範囲内のものである。
【００４０】
さらに、本発明のいくつかの機能は、対応する他機能を用いることなく利用でき得る。したがって、前述の記載は単に本発明の原理を説明するものに過ぎず、これを限定するものではない。
【図面の簡単な説明】
【００４１】
【図１】1つのフォーカスおよび複数の参加者がスター型トポロジーで並べられた、従来のSIPカンファレンスを示すブロック図である。
【図２】従来技術による、参加者（ユーザ・エージェント）および参加者の様々なカンファレンス機能への接続を示したブロック図である。
【図３】本発明の一実施形態による、カンファレンシング・サーバおよびカンファレンシング・ポリシー・サーバのユーザ・エージェントとのインターフェースを示したブロック図である。
【図４】クライアント・ユーザ・エージェントと図3に示されるカンファレンシング・サーバの一部を形成するデータ共有サーバとの間のインタラクションを示す、シグナリングおよびデータ・フロー図である。
【技術分野】
【０００１】
本発明は、一般的に無線通信システムおよびその方法に関し、特に、複数参加型カンファレンスの確立および実施を行なうためのSIP（セッション開始プロトコル（Session Initiation Protocol））を使用する、無線端末および無線ネットワークノードに関する。
【背景技術】
【０００２】
SIP（セッション開始プロトコル（Session Initiation Protocol））は、IETF RFC3261（ローゼンバーグ（Rosenberg）等。2002年6月）で定義されている。一般に、SIPは、1人以上の参加者とのセッションを開始、変更、終了させるための、アプリケーション層制御（シグナリング）プロトコルである。このセッションには、インターネット電話による通話、マルチメディアの配布およびマルチメディア・カンファレンスなどが含まれる。セッションの生成に使用されるSIPインビテーションは、参加者らが一連の互換性のあるメディア形式に一致させることを可能とさせるセッション記述を伝える。SIPは、プロキシサーバと呼ばれるエレメントを使用し、ユーザの現在地への要求のルーティング、サービスに対するユーザの認証および権限の付与、プロバイダの呼ルーティング・ポリシーのインプリメンテーション、およびユーザに対する機能の提供を手助けする。また、SIPは、ユーザがプロキシサーバで使用されるユーザの現在地をアップロードすることが可能となる登録機能も提供する。SIPは、いくつかの異なったトランスポートプロトコル上で動作する。本発明に最も関わる点は、カンファレンス用のSIPの使用についてである。
【０００３】
まず、SIPは、一般的にコンテンツの間接化（content indirection）と称される、データへのアクセスを提供するメカニズムを含むことに注目する。特に、IETFドラフト「draft−ietf−sip−content−indirect−mech−03」の「SIP（セッション開始プロトコル）メッセージにおけるコンテンツの間接化メカニズム（A Mechanism for Content Indirection in Session Initiation Protocol （SIP） Messages）」（S.オルソン（S. Olson）、2003年6月2日）と題される中では、SIPメッセージにおけるコンテンツの間接化用に提供されるメカニズムが記されている。一般的に、SIPの目的は、1人以上の参加者とのセッションの生成、変更、終了を行なうことであり、HTTPと同様にSIPメッセージは、スタートライン、1つ以上のヘッダおよび任意のボディから構文的に構成される。しかし、HTTPとは異なり、SIPは汎用データ伝送として設計されていない。
【０００４】
SIPメッセージボディのコンテンツを間接的に指定することが望ましいであろうということについて、様々な理由がある。間接化を行なうことにより、セルラー式無線アプリケーションなどの、帯域幅が制限されたアプリケーションでは、リソースの限られたリンクにおいて、受信者がコンテンツを取得するか否かを決定することができるようなメタデータを用いて（間接）コンテンツに、注釈をつける手段が提供される。転送されるコンテンツのサイズが大きく、中間に置かれるシグナリング・プロキシをサイズ的に圧倒してしまうことで、ネットワークの待ち時間を無用に増やしてしまうようなことがある。リアルタイム性を要するSIPアプリケーションでは、これは許されないことであろう。間接コンテンツを使用して、コンテンツの転送をSIPシグナリング・ネットワークから、潜在的に分離されたデータ転送チャネルへ移動させることで、これらの問題を緩和させることができる。また、伝達される必要のあるセッション関連のデータ（ボディ）がエンドポイントまたはユーザ・エージェント（UA）に直接ないケースもあるだろう。そのような場合、SIPメッセージが所望のコンテンツに対する間接的な参照を含むことを可能とするようなメカニズムを有することが望ましい。受信者は、この間接的な参照を使用し、HTTP、FTP、またはLDAP等の非SIP転送チャネルを介してコンテンツを取得する。このIETFドラフトには、コンテンツの間接化の目的は、単にSIP MIMEボディ部に対して代替の転送メカニズムを提供することであると述べられている。転送メカニズムの例外として、間接化されたボディ部は、インラインボディ部と同等であり同一の扱いを受けるべきである。
【０００５】
本発明者らは、以前にカンファレンス制御の必要性を認識し、SIPおよびSOAP（シンプル・オブジェクト・アクセス・プロトコル（Simple Object Access Protocol））に基づいた、コンポーネントベースのスケーラブル・カンファレンス制御フレームワークを提案している。これに関しては、NOSSDAV'02、2002年5月12日−14日、アメリカ合衆国、フロリダ州、マイアミビーチに行なわれた「SIPベースのカンファレンス制御フレームワーク（A SIP−based Conference Control Framework）」ペトリ・コスケライネン（Petri Koskelainen）、へニング・シュルツリンヌ（Henning Schulzrinne）、シャオタオ・ウー（Xiaotao Wu）、を参照することができる。
【０００６】
また、「セッション開始プロトコルでのカンファレンシング用フレームワーク（A Framework for Conferencing with the Session Initiation Protocol）」、J.ローゼンバーグ（J. Rosenberg）、draft−ietf−sipping−conferencing−framework−01、2003年10月27日のインターネット・ドラフトも注目される。
【０００７】
本発明を適切な技術的背景に位置させるため、SIPカンファレンスの簡単な説明を示す。まず、多くの役立つ定義を紹介し、次に、図1および図2におけるSIPカンファレンシングの一般的な議論を示す。
【０００８】
一般的に、SIPカンファレンスは複数相手の会話のインスタンスである。疎結合カンファレンスは、参加者間の調整されたシグナリング関係がないカンファレンスである。疎結合カンファレンスは、カンファレンス・メンバーシップの配布にマルチキャストを頻繁に使用する。密結合カンファレンスは、フォーカスと呼ばれる1つのユーザ・エージェントが各参加者とのダイアログを保持するカンファレンスである。フォーカスは、カンファレンスの集中的マネージャの働きをし、カンファレンスURIによってアドレスされる。フォーカスは、カンファレンスURIでアドレスされ、カンファレンス（すなわち、一意の複数相手会話のインスタンス）を識別するSIPユーザ・エージェントである。フォーカスは、カンファレンスの各参加者とのSIPシグナリング関係を保持する。フォーカスは、何らかの方法で、カンファレンスを構成するメディアを各参加者が確実に受け取ることができるようにする役割をする。また、フォーカスは、カンファレンス・ポリシーもインプリメントする。フォーカスは、論理的な役割である。カンファレンスURIは、カンファレンスのフォーカスを識別するURIで、通常はSIP URIである。ユーザまたはオートマトン（automata）をカンファレンスに接続するソフトウェア・エレメントは、参加者と呼ばれる。参加者は、最小で、SIPユーザ・エージェントを含み、また、例えばカンファレンス・ポリシー制御プロトコル・クライアントも含んでも良い。カンファレンス通知サービスは、フォーカスにより提供される、論理的な機能である。フォーカスは、通知者として動作し、カンファレンス状態へのサブスクリプションを受け付け、サブスクライバにその状態への変更について知らせることができる。この状態には、フォーカス自体により保持された状態、カンファレンス・ポリシー、およびメディア・ポリシーが含まれる。カンファレンス・ポリシー・サーバは、カンファレンス・ポリシーを格納および操作することができる論理的な機能である。カンファレンス・ポリシーは、カンファレンスのオペレーションを支配する全体的なルールのセットである。これは、メンバーシップ・ポリシーおよびメディア・ポリシーに分けられる。フォーカスとは異なり、各カンファレンス・ポリシー・サーバのインスタンスはないが、各カンファレンスに対するメンバーシップおよびメディア・ポリシーのインスタンスがある。カンファレンス・ポリシーとは、カンファレンス・ポリシー・サーバにより操作される特定のカンファレンス用のルールのセットである。これには、メンバーシップ・ポリシーおよびメディア・ポリシーが含まれる。各カンファレンスに対するカンファレンス・ポリシーのインスタンスがある。メンバーシップ・ポリシーは、特定のカンファレンスの参加に関するカンファレンス・ポリシー・サーバによって操作されるルールのセットである。これらのルールには、カンファレンスのライフスパンについての指令、誰がカンファレンスに参加できるか誰ができないか、カンファレンスで有効な役割の定義、およびこれらの役割に関連付けられた責務、ならびに誰がどの役割を要求することが許されているかについてのポリシーが含まれる。メディア・ポリシーは、カンファレンスのメディア構成に関して、カンファレンス・ポリシー・サーバにより操作されるルールのセットである。メディア・ポリシーは、カンファレンスのミキシング特性を決定するために、フォーカスにより使用される。メディア・ポリシーには、どの参加者が他のどの参加者からメディアを受け取るかについてのルール、およびメディアが各参加者に対して結合される方法が含まれる。音声の場合、これらのルールに各参加者がミックスされた相対的なボリュームを含めることができる。映像の場合、これらのルールは、映像がタイル型か、映像が声の一番大きい話者を示すかなどを示すことができる。CPCP（カンファレンス・ポリシー制御プロトコル（Conference Policy Control Protocol））は、カンファレンス・ポリシーを操作するため、クライアントに使用されるプロトコルである。ミキサは、同じ形式のメディア・ストリームのセットを受信し、形式特定の方法でそれらのメディアを結合し、その結果を各参加者に再配布するコンポーネントである。これには、RTP（RFC1889参照）を使用して転送されたメディアも含まれる。これらの様々な定義の参照に便利な、draft−ietf−sipping−conferencing−framework−01ドキュメントでは、インスタント・メッセージング・セッションのような非RTPベースのメディアを可能としているため、ミキサは、RFC1889で定義されたミキサの概念のスーパーセットであると考えられている。カンファレンス・サーバは、少なくとも、フォーカスを含む物理的なサーバである。これには、カンファレンス・ポリシー・サーバおよびミキサも含まれても良い。
【０００９】
本願発明の理解に有用な定義を以上にで示したところで、次に図1を参照する。SIPカンファレンスの中心のコンポーネントは、フォーカス1である。フォーカス1は、カンファレンスにおける各参加者2とのSIPシグナリング関係を維持する（図2では、参加者はUA（ユーザ・エージェント）としても示される）。結果は、スター型トポロジーである。フォーカス1は、カンファレンスを構成するメディア・ストリームをカンファレンスの参加者2が確実に利用できるようにする働きをする。フォーカス1は、この機能を1つ以上のミキサ3を使用して行なう。ミキサ3の各々は、多数の入力メディア・ストリームを結合して1つ以上の出力メディア・ストリームを生成する。フォーカス1は、ミキサ3の適切な構成を決定するため、メディア・ポリシーを使用する。フォーカス1は、各カンファレンスに対して、そのインスタンスが存在するところのカンファレンス・ポリシー（メンバーシップおよびメディア・ポリシーより構成）へのアクセスを有する。事実上、カンファレンス・ポリシーは、カンファレンスが動作すべき方法を記述するデータベースとして考えることができる。これらのポリシーを実行する役割を担うのが、フォーカス1である。フォーカス1は、データベースへの読み出しアクセスを行なう必要のみでなく、データベースに変更が加えられた時期も知る必要がある。このような変更は、SIPシグナリングを引き起こす可能性があり（例えば、カンファレンスからのユーザの退出など）、ほとんどの変更で、カンファレンス通知サービスを使用して、サブスクライバに通知が送信されることが要求される。カンファレンスは、フォーカス1を識別するURIにより表される。各カンファレンスは、一意のフォーカス1と、フォーカス1を識別する一意のURIを持つ。カンファレンスURIへの要求は、特定のカンファレンス用のフォーカス1に経由される。ユーザは、通常、カンファレンスURIへINVITEを送信することでカンファレンスに参加する。カンファレンス・ポリシーで許可される限り、INVITEはフォーカス1によって受け付けられ、ユーザはカンファレンスに参加させられる。ユーザは、通常の通話で行なわれるように、BYEを送信することでカンファレンスから退席することができる。同様に、参加者2のカンファレンスへの参加がもはや許可されていないことを示すようにカンファレンス・ポリシーが変更された場合、フォーカス1は当該参加者とのダイアログを終了させることができる。また、フォーカス1がカンファレンスに参加者を参加させる必要があることをカンファレンス・ポリシーが示す場合、フォーカス1はINVITEを開始することもできる。
【００１０】
図2は、カンファレンス機能を示す全体図である。参加者2は、エンハンスされた呼制御機能にアクセスするため、REFERなどの拡張を使用してフォーカス1とインタラクトすることができる。参加者2は、カンファレンスURIへSUBSCRIBEし、フォーカス1に提供されるカンファレンス通知サービスに接続することができる。このメカニズムを通して、参加者（事実上、ダイアログの状態）、メディア・ポリシー、およびメンバーシップ・ポリシーにおける変更を知ることができる。参加者2は、CPCP（カンファレンス・ポリシー制御プロトコル（conference policy control protocol））5を使用して、CPS（カンファレンス・ポリシー・サーバ）4と通信することができる。CPCP5の使用により、参加者2は、カンファレンス・ポリシー6に作用することができる。カンファレンス・ポリシー6は常に利用可能であるが、カンファレンス・ポリシー・サーバ4は、いかなる特定のカンファレンスにおいてでも利用可能である必要はない。フォーカス1とカンファレンス・ポリシー6との間、およびカンファレンス・ポリシー・サーバ4とカンファレンス・ポリシー6との間のインターフェースは、主としてカンファレンスに含まれる論理的役割を示すことを意図している。さらに全体を示すため、図2において、カンファレンス通知サービス7がサブスクリプション・インターフェースを介して、参加者2に接続されている。
【００１１】
draft−ietf−sipping−conferencing−framework−01ドキュメントに記載された全体的なフレームワークにおいて、カンファレンスはURIによって一意に識別され、このURIによってカンファレンスの責務を担うフォーカス1が識別されるとういうことは、基本的なことである。カンファレンスURIは一意であり、2つのカンファレンスが同じカンファレンスURIを持つことはない。カンファレンスURIは、常に、SIPまたはSIPS（セキュアSIP（Secure SIP））URIである。PSTNゲートウェイ上のユーザまたはインターフェースとは対照的に、カンファレンスURIは、これを使用することになるいずれの参加者にも不透明、つまり、URIを見て、フォーカス1を識別しているかどうかを確実に知る方法が無い。しかし、URIを囲むコンテキスト上の情報（例えば、SIPヘッダ・パラメータなど）により、そのURIがカンファレンスを表していることが示されることがある。SIP要求がカンファレンスURIに送信される際、その要求はフォーカス1にルートされ、これはフォーカス1に対してのみである。カンファレンスURIを作成するエレメントまたはシステムは、この性質を保証する役割を果たす。カンファレンスURIは、長期間のカンファレンスもしくはインタレスト・グループを表すことができ、またはアドホック・カンファレンスなどの短期間のカンファレンスを表すこともできる。
【００１２】
本発明以前は、SIPカンファレンシングの一態様は、カンファレンス参加者2間のデータ共有の概念に関して、適切に定義または指定されていなかった。
【非特許文献１】IETF RFC3261（ローゼンバーグ（Rosenberg）等。2002年6月）
【非特許文献２】IETFドラフト「SIP（セッション開始プロトコル）メッセージにおけるコンテンツの間接化メカニズム（A Mechanism for Content Indirection in Session Initiation Protocol （SIP） Messages）」（S.オルソン（S. Olson）、2003年6月2日）
【非特許文献３】「SIPベースのカンファレンス制御フレームワーク（A SIP−based Conference Control Framework）」ペトリ・コスケライネン（Petri Koskelainen）、へニング・シュルツリンヌ（Henning Schulzrinne）、シャオタオ・ウー（Xiaotao Wu）；NOSSDAV'02、2002年5月12日−14日、アメリカ合衆国
【非特許文献４】「セッション開始プロトコルでのカンファレンシング用フレームワーク（A Framework for Conferencing with the Session Initiation Protocol）」、J.ローゼンバーグ（J. Rosenberg）、インターネット・ドラフト、2003年10月27日
【好適な実施形態のまとめ】
【００１３】
これらの教示について現在好適な実施形態によれば、上記およびその他の問題が解決され、他の有利な点が実現される。
【００１４】
本発明は、カンファレンス・ポリシーの操作の概念に関し、ユーザがCPCP（カンファレンス・ポリシー制御プロトコル（Conference Policy Control Protocol））を使用して、CPS（カンファレンス・ポリシー・サーバ（conference policy server））にカンファレンスを作成することができ、ACL（アクセス制御リスト（Access Control Lists））、ダイアルアウト・ユーザ・リスト、およびRTPメディア・ストリームのようなカンファレンス・パラメータを設定することができるものである。
【００１５】
本発明によれば、複数参加型のカンファレンシング、特にデータ共有のための付加的な使用例およびメカニズムが記載されている。本発明によるデータ共有は、アプリケーション共有では一般的に終端端末に特別なアプリケーションを必要とする点において、アプリケーション共有（ドキュメントを共有できる）とは区別することができる。
【００１６】
本発明によるSIPカンファレンシングのデータ共有では、ユーザは、ドキュメント、ファイル、およびデータをCPSにアップロードすることができ、CPCPを使用して、アップロードされたデータに対するアクセス・ポリシーおよび処理オペレーションを設定することができる。例えば、ユーザは音楽ファイルをアップロードし、すべての参加者がこの音楽ファイルに対して読み取りアクセスができるが、削除はできないように指定することができる。
【００１７】
また、CPSは、画像データを含むドキュメントなども、本発明によって拡張されたCPCPを介して提供される命令に基づいて、操作することもできる。ドキュメント処理オペレーションには、例えば、限定されないが、画像のリサイズ、ドキュメントの他形式への変換、およびすべてのカンファレンス参加者に対するドキュメントのプッシュなどを含めることができる。
【００１８】
本発明の1つの態様において、データ共有およびCPCPを新規で自明でない方法によって結びつけることで、ドキュメント操作を可能とし、これによって、IPに対し新しいサービス、すなわちSIPベースのカンファレンシングを作成する。
【００１９】
本発明の1つの態様において、SIPカンファレンスのカンファレンス参加者間でのデータ共有方法が提供される。この方法には、カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答して、SIPメッセージによって、他のカンファレンス参加者に使用される共有データをUAが保存し得るカンファレンシング・サーバのDSS（データ共有サーバ（data sharing server））に関連づけられた保存場所のアドレスをUAに通知するステップと、保存場所のアドレスにデータを保存するステップと、他のカンファレンス参加者に対する、共有データへのアクセスおよび共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定するステップとが含まれる。
【００２０】
また、SIPカンファレンス・サーバの一部として、1人以上のSIPカンファレンス参加者により保存される共有データの保存、アクセス制御、および配布を提供するDSS（データ共有サーバ（Data Sharing Server））が開示される。
【００２１】
したがって、本発明の1つの態様において、カンファレンス参加者であるUAによるデータ共有エレメント作成要求に応じて、他のカンファレンス参加者に使用される共有データをUAが保存し得るDSSに関連づけられた保存場所のアドレスをSIPメッセージでUAに通知する、少なくとも1つのデータ・プロセッサを備えたSIPカンファレンス・サーバが提供される。このデータ・プロセッサは、さらにUAからのデータの受信に応じて、保存場所のアドレスにデータを保存し、他のカンファレンス参加者に対する、共有データへのアクセスおよび共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定する。
【００２２】
さらに、本発明の1つの態様において、カンファレンス参加者として機能するデータ・プロセッサを備え、SIPカンファレンス・サーバとともに動作可能なUAであって、このデータ・プロセッサが、SIPカンファレンス・サーバにデータ共有エレメントの作成を要求し、UAが他のカンファレンス参加者に使用される共有データを保存し得るDSSに関連づけられた保存場所のアドレスを示す通知をSIPメッセージによって受信し、保存場所のアドレスに保存するため、DSSにデータを送信し、CPCP（カンファレンス・ポリシー制御プロトコル（Conference Policy Control Protocol））を介して、CPS（カンファレンス・ポリシー・サーバ（Conference Policy Server））へ情報を送信して、他のカンファレンス参加者に対する、共有データへのアクセスおよび共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定する、UAが提供される。
【００２３】
本発明の好適な実施形態において、データは、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理（Web−based Distributed Authoring and Versioning）、RTP、MIME（多目的インターネット・メール拡張機能（Multipurpose Internet Mail Extensions））カプセル化を持つTCPパイプのうち1つを使用するような非SIPプロシージャを用いて、DSSに送信される。
【００２４】
本発明の好適な実施形態において、UAは、保存場所のアドレスを指定するURI（ユニフォーム・リソース識別子（Uniform Resource Identifier））に含まれるアドレスの通知を受信する。
【００２５】
本発明の好適な実施形態において、データが、そのデータの少なくとも1つの名前とともにDSSに送信され、またそのデータの形式もともに送信されてもよい。共有データには、ファイルおよび実行可能なアプリケーションの少なくとも1つが含まれてもよい。
【００２６】
UAは、携帯電話または携帯電話の一部であってもよい。
【００２７】
これらの教示の上記およびその他の態様は、以下の発明を実施するための最良の形態を添付の図面とともに読むことで明らかになるであろう。
【好適な実施形態の詳細な説明】
【００２８】
図3を参照すると、本発明の一実施形態によるカンファレンシング・サーバ10、さらにUA2とカンファレンシング・サーバ10とのインターフェースが示されている。図3に示される、他のUA2もカンファレンスの参加者であり、カンファレンシング・サーバ10に同様の方法で接続されているものとする。UA2は、SIPダイアログを介してフォーカス1へ、本発明に従って機能するように変更されたCPCP（すなわちCPCP5'と称す）を介してCPS4へ接続されている。カンファレンシング・サーバ10は、さらに、少なくとも1つのミキサ3、ビデオ・サーバ12、本発明によるDSS14（データ共有サーバ（Data Sharing Server））を備えている。UA2は、RTPオーディオ・インターフェース3Aを介しミキサ3に、RTPビデオ・インターフェース12Aを介しビデオ・サーバ12に、DSP（データ共有プロトコル（Data Sharing Protocol））14Aをインプリメントする共有データ・インターフェースを介しDSS14に、それぞれ接続されている。
【００２９】
一般に、DSS14は、CPS4と同一場所に配置するか、図3に示されるようにCPS4に制御される別のサーバとして実装することができる。カンファレンス・ポリシー6（図2に図示）をCPS4およびCPCP5'を介して変更し、どのような形式の共有データがDSS14により保存されるか、どの参加者が共有データを読み出し／書き込み／変更することができるのか、およびDSS14により共有データがどのように作用されるのかを決定することができる。共有データは、ファイルの形態であったり、またはアクティブに動作するアプリケーションであってもよく、DSS14を用いた共有データ・インターフェースを介し、好ましくは、TCP（伝送制御プロトコル（Transmission Control Protocol））などの非SIPメカニズムによって、アクセスされる。動作アプリケーションの限定されない例として、ゲームがある。
【００３０】
DSP14Aは、以下の（限定されない）伝送メカニズムのいずれかを使用してインプリメントしても良い。すなわち、HTTP、ユーザが遠隔Webサーバ上のファイルを共同で編集および管理することを可能とするHTTPプロトコルの拡張セットであるWebDav（Webベースの分散オーサリングおよびバージョン管理（Web−based Distributed Authoring and Versioning）、好ましくはマルチキャスト動作を含む前方誤り訂正を有するRTP、MIME（多目的インターネット・メール拡張機能（Multipurpose Internet Mail Extensions））カプセル化を持つTCPパイプであってもよく、上記のバリエーションのいずれかを使用してインプリメントしても良い。DSP14Aの主な機能は、クライアント（UA2）およびDSS14間でデータを伝達することである。また、DSP14Aは、共有データに関連する名前など（実際のデータに先行するRTPヘッダ、またはMIMEヘッダ内にある）、共有データに関する最小限の情報を伝達することも好ましい。
【００３１】
一般的に、MIMEはそもそも、非US−ASCIIテキスト・メッセージ、非テキスト・メッセージ、マルチパート・メッセージ・ボディ、およびメッセージ・ヘッダ中の非US−ASCII情報を可能とするために、インターネット・メールのフォーマットを拡張することを意図していた。次のRFCでMIMEが定義されている。
RFC 2045： MIMEパート1：インターネット・メッセージ・ボディのフォーマット（Format of Internet Message Bodies）
RFC 2046： MIMEパート2：メディア・タイプ（Media Types）
RFC 2047： MIMEパート3：非ASCIIテキスト用のメッセージ・ヘッダ拡張（Message Header Extensions for Non−ASCII Text）
RFC 2048： MIMEパート4：登録手順（Registration Procedures）
RFC 2049： MIMEパート5：適合性基準と例（Conformance Criteria and Examples）
【００３２】
クライアント（UA2）が発行できるポリシー・コマンドの例には次のようなものが挙げられるが、これらに限定はされない。
a）いずれの参加者もDSS14にある私のファイルを読み出すことができる。
b）参加者x（例えば、私のアシスタント）がDSS14にある私のファイルをアップデートすることができる。
c）私の「近接BLOB（"proximity blob"）」は、毎金曜日にアクティブ化する。
d）参加者yがimage_l用のファイルを読み出した際に私は警告を受けるべきである。
e）JPEGデータは、すべての参加者に送信されるべきである（しかし、小型ディスプレイを持つクライアントにはQCIFに縮小する）。QCIFとは、クォーター・コモン・インターミディエート・フォーマット（Quarter Common Intermediate Format）であり、各フレームに、144行および各行176ピクセルを含み（すなわちフルCIFの解像度の1／4、）、30フレーム／秒（fps）のデータ・レートを指定する、ビデオ・カンファレンシング・フォーマットである（QCIFのサポートがITU H.261のビデオ・カンファレンシング標準で必要とされている。）。
【００３３】
図3の実施形態において、カンファレンシング・サーバ10は、自らの状態に基づいて、自らのメンバーへの出力データを生成する。例えば、フロア制御が使用されている場合、1つのオーディオのみがミキサ3を通過する。典型的な場合では、いずれのUA2もDSS14にデータを保存することでデータを共有でき、上述のように、CPCP5'を用いて他のUAにアクセス権を与える／拒否することができる。カンファレンシング・サーバ10は、DSS14からカンファレンスの参加者へ、データを送信またはプッシュしてもよく、このデータは処理されたものであってもよい（例えば、ビデオ・サーバ12からのQCIFビデオデータとしてのビデオデータ）。
【００３４】
図4は、クライアントUA2およびDSS14間のインタラクションを示す、シグナリングおよびデータ・フロー図である。ステップAでは、UA2がDSS14にデータ共有エレメントを作成するように要求している。この要求は、CPCP5'およびCPS4を介して行なわれる。ステップBでは、UA2は、DSS14内にあるUA2に割り当てられた共有データ保存位置のアドレスを識別するURIを、CPS4およびCPCP5'を介して、DSS14により通知される。ステップCでは、UA2がDSP14Aを介し（例えば、HTTPを使用して）、ステップBで識別されたURIへ共有データを送信する。先に述べたように、データ・コンテンツに加えて、データを識別する情報（データ名、データ形式など）も送信されることが好ましい。
【００３５】
上記は、SIPコンテンツの間接化動作を用いるものであってもよいが、本発明の好適な実施形態において、カンファレンスに参加中のユーザに、データ共有機能の提供およびサポートに必要な様々な情報を伝えるために、SIPペイロード（SDP）が用いられる。例えば、ユーザは、SIPペイロードを介して、RTPオーディオ・ミキサ3およびRTPビデオ・サーバ12のアドレス、さらに本発明の一実施形態に係るDSS14のアドレスを知ることができる。本発明の好適な実施形態において、DSS14内のデータに対する操作およびポリシーの定義には、カンファレンス・ポリシー制御プロトコル5'が用いられている。
【００３６】
図4について、さらに説明すると、ステップDでは、DSP14Aを用いて、データ保存操作の成功をUA2に伝える。ステップEでは、カンファレンス参加者ボブに保存された共有データ・ファイルの読み出しの許可を与える命令、および参加者アリスへの保存された共有データ・ファイルの送信を行なう命令（QCIFを用いて圧縮されている）などの、少なくとも1つのカンファレンス関連の共有データ・ポリシー・コマンドをUA2が送信する。ステップFでは、これらのコマンドの受け取り（実行）が肯定応答され、ステップGでは、参加者ボブがファイルを読み取ったことをクライアントに知らせる、SIP通知メッセージが（SIPダイアログを介して）送信される。
【００３７】
図4に示された上記のコマンド、インタラクション、およびデータ・フローは、例にすぎず、本発明の実施において、限定を意図するものとして読まれるものではない。
【００３８】
上記の実施形態において、SIPカンファレンシング・サーバ10およびUA2の各々が、本発明によるSIP関連のカンファレンス・データ共有手順、およびプロトコルを実行可能な、1つ以上のプログラムされたデジタル・データ・プロセッサを含んでいることを理解されよう。例えば、UA2は、SIPカンファレンシング・サーバ10から受信されるSIPメッセージからURIを抽出し、抽出されたURIの指定するアドレスへ保存されるように、共有するデータをDSS14に順に送信するような、格納されたプログラムに従って動作する、組み込み用マイクロプロセッサを内蔵した携帯電話、または個人用通信機に具現化されても良い。
【００３９】
上記記載は、本発明を実施するため、発明者らにより現時点で考慮された最良の方法および装置について、余すところなく情報を提供する、限定の意図を有しない例を示す記載であるが、前述の記載に鑑みて、添付図面および特許請求の範囲とともに併せ読むことにより、種々の変更および改作などが可能であることは、本願発明に関連する技術の分野における当業者に理解されよう。また、いくつかの例において、当業者は、他の同様または同等のファイル形式、メッセージ形式、データ転送メカニズム、および同種のものの使用を試みることもできよう。しかし、本発明の教示によるこれらすべておよび同等の変更は、本発明の範囲内のものである。
【００４０】
さらに、本発明のいくつかの機能は、対応する他機能を用いることなく利用でき得る。したがって、前述の記載は単に本発明の原理を説明するものに過ぎず、これを限定するものではない。
【図面の簡単な説明】
【００４１】
【図１】1つのフォーカスおよび複数の参加者がスター型トポロジーで並べられた、従来のSIPカンファレンスを示すブロック図である。
【図２】従来技術による、参加者（ユーザ・エージェント）および参加者の様々なカンファレンス機能への接続を示したブロック図である。
【図３】本発明の一実施形態による、カンファレンシング・サーバおよびカンファレンシング・ポリシー・サーバのユーザ・エージェントとのインターフェースを示したブロック図である。
【図４】クライアント・ユーザ・エージェントと図3に示されるカンファレンシング・サーバの一部を形成するデータ共有サーバとの間のインタラクションを示す、シグナリングおよびデータ・フロー図である。
【特許請求の範囲】
【請求項１】
SIP（セッション開始プロトコル）カンファレンスのカンファレンス参加者間でのデータ共有方法であって、該方法は、
カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答し、他のカンファレンス参加者に使用される共有データを該UAが保存し得るカンファレンシング・サーバのDSS（データ共有サーバ）に関連づけられた保存場所のアドレスを、SIPメッセージによって該UAに通知するステップと、
該保存場所のアドレスに該データを保存するステップと、
該他のカンファレンス参加者に対する、該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御する、少なくとも1つのポリシーを設定するステップと
を含む、データ共有方法。
【請求項２】
前記保存するステップにおいて、非SIPプロシージャを使用する、請求項1に記載の方法。
【請求項３】
前記保存するステップにおいて、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用する、請求項1に記載の方法。
【請求項４】
前記通知するステップにおいて、前記UAに対して、前記保存場所の前記アドレスを指定するURI（ユニフォーム・リソース識別子）が与えられる、請求項1に記載の方法。
【請求項５】
前記保存するステップにおいて、前記保存データの少なくとも1つの名前を提供することをさらに含む、請求項1に記載の方法。
【請求項６】
前記保存するステップにおいて、前記保存データの少なくとも1つの名前および形式を提供することをさらに含む、請求項1に記載の方法。
【請求項７】
前記共有データにファイルおよび実行可能なアプリケーションの少なくとも1つが含まれる、請求項1に記載の方法。
【請求項８】
データ・プロセッサを備えたSIP（セッション開始プロトコル）カンファレンス・サーバであって、該データ・プロセッサは、
カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応じ、他のカンファレンス参加者に使用される共有データを該UAが保存し得るDSS（データ共有サーバ）に関連づけられた保存場所のアドレスをSIPメッセージで該UAに通知し、
さらに該UAからのデータの受信に応じて該保存場所のアドレスに該データを保存し、
該他のカンファレンス参加者に対する該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御する、少なくとも1つのポリシーを設定する、
SIPカンファレンス・サーバ。
【請求項９】
前記データが非SIPプロシージャを使用して受信される、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１０】
前記データが、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用して受信される、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１１】
前記プロセッサが、前記保存場所の前記アドレスを指定するURI（ユニフォーム・リソース識別子）を使用して、前記UAに該アドレスを通知する、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１２】
前記データが、該保存データにの少なくとも1つの名前とともに受信される、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１３】
前記データが、該保存データの少なくとも1つの名前およびその形式とともに受信される、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１４】
前記共有データにファイルおよび実行可能なアプリケーションの少なくとも1つが含まれる、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１５】
カンファレンス参加者として機能するデータ・プロセッサを備え、SIP（セッション開始プロトコル）カンファレンス・サーバとともに動作可能なUA（ユーザ・エージェント）であって、該データ・プロセッサが、
SIPカンファレンス・サーバにデータ共有エレメントの作成を要求し、
他のカンファレンス参加者に使用される共有データを該UAが保存し得るDSS（データ共有サーバ）に関連づけられた保存場所のアドレスを示す通知をSIPメッセージによって受信し、
該保存場所の該アドレスに保存するため、該DSSにデータを送信し、
該他のカンファレンス参加者に対する該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御するための少なくとも1つのポリシーを設定すべく、CPCP（カンファレンス・ポリシー制御プロトコル）を介して、CPS（カンファレンス・ポリシー・サーバ）へ情報を送信する、
UA。
【請求項１６】
前記データが非SIPプロシージャを使用して前記DSSに送信される、請求項15に記載のUA。
【請求項１７】
前記データが、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用して前記DSSに送信される、請求項15に記載のUA。
【請求項１８】
前記UAが、前記保存場所の前記アドレスを指定するURI（ユニフォーム・リソース識別子）に含まれる該アドレスの通知を受信する、請求項15に記載のUA。
【請求項１９】
前記データが、該データの少なくとも1つの名前とともに前記DSSに送信される、請求項15に記載のUA。
【請求項２０】
前記データが、該データの少なくとも1つの名前およびその形式とともに前記DSSに送信される、請求項15に記載のUA。
【請求項２１】
前記共有データにファイルおよび実行可能なアプリケーションの少なくとも1つが含まれる、請求項15に記載のUA。
【請求項２２】
前記UAが携帯電話に含まれる、請求項15に記載のUA。
【請求項２３】
通信ネットワークを使用して実施されるカンファレンスのカンファレンス参加者間でのデータ共有を、少なくとも1つのデータ・プロセッサに指示する、コンピュータが読み出し可能なメディアに一体化されるコンピュータ・プログラムであって、
カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答して、メッセージによって、他のカンファレンス参加者に使用される共有データを該UAが保存し得る保存場所のアドレスを該UAに通知する動作と、
該保存場所の該アドレスに該データを保存する動作と、
他のカンファレンス参加者に対する、該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定する動作と
を含むコンピュータ・プログラム。
【請求項２４】
前記メッセージにSIP（セッション開始プロトコル）メッセージが含まれる、請求項23に記載のコンピュータ・プログラム。
【請求項２５】
前記保存する動作において、非SIPプロシージャを使用する、請求項24に記載のコンピュータ・プログラム。
【請求項２６】
前記保存する動作において、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用する、請求項23に記載のコンピュータ・プログラム。
【請求項２７】
前記通知する動作において、前記UAに対して、前記保存場所の前記アドレスを指定するURI（ユニフォーム・リソース識別子）が与えられる、請求項23に記載のコンピュータ・プログラム。
【請求項２８】
前記保存する動作において、前記保存データの少なくとも1つの名前を提供することをさらに含む、請求項23に記載のコンピュータ・プログラム。
【請求項２９】
前記保存する動作において、前記保存データの少なくとも1つの名前および形式を提供することをさらに含む、請求項23に記載のコンピュータ・プログラム。
【請求項３０】
前記共有データにファイルおよび実行可能なアプリケーションの少なくとも1つが含まれる、請求項23に記載のコンピュータ・プログラム。
【請求項３１】
カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答し、他のカンファレンス参加者に使用される共有データを該UAが保存し得る保存手段に関連づけられた保存場所のアドレスを、メッセージにより該UAに通知するための手段と、
該アドレスに該データを保存するための手段と、
他のカンファレンス参加者に対する、該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定するための手段と
を含むカンファレンス・サーバ。
【請求項３２】
前記メッセージにSIP（セッション開始プロトコル）メッセージが含まれる、請求項31に記載のカンファレンス・サーバ。
【請求項３３】
前記保存するための手段が非SIPプロシージャを使用する、請求項32に記載のカンファレンス・サーバ。
【請求項３４】
前記データが、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用して受信される、請求項31に記載のカンファレンス・サーバ。
【請求項３５】
前記通知するための手段が、前記UAに対して、前記アドレスを指定するURI（ユニフォーム・リソース識別子）を通知する、請求項31に記載のカンファレンス・サーバ。
【請求項３６】
UA（ユーザ・エージェント）の少なくとも1つのデータ・プロセッサに、カンファレンス参加者として、SIP（セッション開始プロトコル）カンファレンス・サーバとともに動作するよう指示する、コンピュータが読み出し可能なメディアに一体化されるコンピュータ・プログラムであって、
データ共有エレメントの作成を要求する動作と、
他のカンファレンス参加者に使用される共有データを該UAが保存し得る保存場所のアドレスについての通知をSIPメッセージによって受信する動作と、
該保存場所の該アドレスに保存用のデータを送信する動作と、
該他のカンファレンス参加者に対して該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御するための少なくとも1つのポリシーを設定すべく、CPCP（カンファレンス・ポリシー制御プロトコル）を介して、CPS（カンファレンス・ポリシー・サーバ）に情報を送信する動作と
を含むコンピュータ・プログラム。
【請求項３７】
前記データが非SIPプロシージャを使用して送信される、請求項36に記載のコンピュータ・プログラム。
【請求項１】
SIP（セッション開始プロトコル）カンファレンスのカンファレンス参加者間でのデータ共有方法であって、該方法は、
カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答し、他のカンファレンス参加者に使用される共有データを該UAが保存し得るカンファレンシング・サーバのDSS（データ共有サーバ）に関連づけられた保存場所のアドレスを、SIPメッセージによって該UAに通知するステップと、
該保存場所のアドレスに該データを保存するステップと、
該他のカンファレンス参加者に対する、該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御する、少なくとも1つのポリシーを設定するステップと
を含む、データ共有方法。
【請求項２】
前記保存するステップにおいて、非SIPプロシージャを使用する、請求項1に記載の方法。
【請求項３】
前記保存するステップにおいて、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用する、請求項1に記載の方法。
【請求項４】
前記通知するステップにおいて、前記UAに対して、前記保存場所の前記アドレスを指定するURI（ユニフォーム・リソース識別子）が与えられる、請求項1に記載の方法。
【請求項５】
前記保存するステップにおいて、前記保存データの少なくとも1つの名前を提供することをさらに含む、請求項1に記載の方法。
【請求項６】
前記保存するステップにおいて、前記保存データの少なくとも1つの名前および形式を提供することをさらに含む、請求項1に記載の方法。
【請求項７】
前記共有データにファイルおよび実行可能なアプリケーションの少なくとも1つが含まれる、請求項1に記載の方法。
【請求項８】
データ・プロセッサを備えたSIP（セッション開始プロトコル）カンファレンス・サーバであって、該データ・プロセッサは、
カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応じ、他のカンファレンス参加者に使用される共有データを該UAが保存し得るDSS（データ共有サーバ）に関連づけられた保存場所のアドレスをSIPメッセージで該UAに通知し、
さらに該UAからのデータの受信に応じて該保存場所のアドレスに該データを保存し、
該他のカンファレンス参加者に対する該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御する、少なくとも1つのポリシーを設定する、
SIPカンファレンス・サーバ。
【請求項９】
前記データが非SIPプロシージャを使用して受信される、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１０】
前記データが、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用して受信される、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１１】
前記プロセッサが、前記保存場所の前記アドレスを指定するURI（ユニフォーム・リソース識別子）を使用して、前記UAに該アドレスを通知する、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１２】
前記データが、該保存データにの少なくとも1つの名前とともに受信される、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１３】
前記データが、該保存データの少なくとも1つの名前およびその形式とともに受信される、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１４】
前記共有データにファイルおよび実行可能なアプリケーションの少なくとも1つが含まれる、請求項8に記載のSIPカンファレンス・サーバ。
【請求項１５】
カンファレンス参加者として機能するデータ・プロセッサを備え、SIP（セッション開始プロトコル）カンファレンス・サーバとともに動作可能なUA（ユーザ・エージェント）であって、該データ・プロセッサが、
SIPカンファレンス・サーバにデータ共有エレメントの作成を要求し、
他のカンファレンス参加者に使用される共有データを該UAが保存し得るDSS（データ共有サーバ）に関連づけられた保存場所のアドレスを示す通知をSIPメッセージによって受信し、
該保存場所の該アドレスに保存するため、該DSSにデータを送信し、
該他のカンファレンス参加者に対する該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御するための少なくとも1つのポリシーを設定すべく、CPCP（カンファレンス・ポリシー制御プロトコル）を介して、CPS（カンファレンス・ポリシー・サーバ）へ情報を送信する、
UA。
【請求項１６】
前記データが非SIPプロシージャを使用して前記DSSに送信される、請求項15に記載のUA。
【請求項１７】
前記データが、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用して前記DSSに送信される、請求項15に記載のUA。
【請求項１８】
前記UAが、前記保存場所の前記アドレスを指定するURI（ユニフォーム・リソース識別子）に含まれる該アドレスの通知を受信する、請求項15に記載のUA。
【請求項１９】
前記データが、該データの少なくとも1つの名前とともに前記DSSに送信される、請求項15に記載のUA。
【請求項２０】
前記データが、該データの少なくとも1つの名前およびその形式とともに前記DSSに送信される、請求項15に記載のUA。
【請求項２１】
前記共有データにファイルおよび実行可能なアプリケーションの少なくとも1つが含まれる、請求項15に記載のUA。
【請求項２２】
前記UAが携帯電話に含まれる、請求項15に記載のUA。
【請求項２３】
通信ネットワークを使用して実施されるカンファレンスのカンファレンス参加者間でのデータ共有を、少なくとも1つのデータ・プロセッサに指示する、コンピュータが読み出し可能なメディアに一体化されるコンピュータ・プログラムであって、
カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答して、メッセージによって、他のカンファレンス参加者に使用される共有データを該UAが保存し得る保存場所のアドレスを該UAに通知する動作と、
該保存場所の該アドレスに該データを保存する動作と、
他のカンファレンス参加者に対する、該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定する動作と
を含むコンピュータ・プログラム。
【請求項２４】
前記メッセージにSIP（セッション開始プロトコル）メッセージが含まれる、請求項23に記載のコンピュータ・プログラム。
【請求項２５】
前記保存する動作において、非SIPプロシージャを使用する、請求項24に記載のコンピュータ・プログラム。
【請求項２６】
前記保存する動作において、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用する、請求項23に記載のコンピュータ・プログラム。
【請求項２７】
前記通知する動作において、前記UAに対して、前記保存場所の前記アドレスを指定するURI（ユニフォーム・リソース識別子）が与えられる、請求項23に記載のコンピュータ・プログラム。
【請求項２８】
前記保存する動作において、前記保存データの少なくとも1つの名前を提供することをさらに含む、請求項23に記載のコンピュータ・プログラム。
【請求項２９】
前記保存する動作において、前記保存データの少なくとも1つの名前および形式を提供することをさらに含む、請求項23に記載のコンピュータ・プログラム。
【請求項３０】
前記共有データにファイルおよび実行可能なアプリケーションの少なくとも1つが含まれる、請求項23に記載のコンピュータ・プログラム。
【請求項３１】
カンファレンス参加者であるUA（ユーザ・エージェント）によるデータ共有エレメント作成要求に応答し、他のカンファレンス参加者に使用される共有データを該UAが保存し得る保存手段に関連づけられた保存場所のアドレスを、メッセージにより該UAに通知するための手段と、
該アドレスに該データを保存するための手段と、
他のカンファレンス参加者に対する、該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御する少なくとも1つのポリシーを設定するための手段と
を含むカンファレンス・サーバ。
【請求項３２】
前記メッセージにSIP（セッション開始プロトコル）メッセージが含まれる、請求項31に記載のカンファレンス・サーバ。
【請求項３３】
前記保存するための手段が非SIPプロシージャを使用する、請求項32に記載のカンファレンス・サーバ。
【請求項３４】
前記データが、HTTP、WebDav（Webベースの分散オーサリングおよびバージョン管理）、RTP、MIME（多目的インターネット・メール拡張機能）カプセル化を持つTCPパイプのうち1つを使用して受信される、請求項31に記載のカンファレンス・サーバ。
【請求項３５】
前記通知するための手段が、前記UAに対して、前記アドレスを指定するURI（ユニフォーム・リソース識別子）を通知する、請求項31に記載のカンファレンス・サーバ。
【請求項３６】
UA（ユーザ・エージェント）の少なくとも1つのデータ・プロセッサに、カンファレンス参加者として、SIP（セッション開始プロトコル）カンファレンス・サーバとともに動作するよう指示する、コンピュータが読み出し可能なメディアに一体化されるコンピュータ・プログラムであって、
データ共有エレメントの作成を要求する動作と、
他のカンファレンス参加者に使用される共有データを該UAが保存し得る保存場所のアドレスについての通知をSIPメッセージによって受信する動作と、
該保存場所の該アドレスに保存用のデータを送信する動作と、
該他のカンファレンス参加者に対して該共有データへのアクセスおよび該共有データの配布の少なくとも1つを制御するための少なくとも1つのポリシーを設定すべく、CPCP（カンファレンス・ポリシー制御プロトコル）を介して、CPS（カンファレンス・ポリシー・サーバ）に情報を送信する動作と
を含むコンピュータ・プログラム。
【請求項３７】
前記データが非SIPプロシージャを使用して送信される、請求項36に記載のコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００８−５００７４８（Ｐ２００８−５００７４８Ａ）
【公表日】平成２０年１月１０日（２００８．１．１０）
【国際特許分類】
【出願番号】特願２００７−５１２５５０（Ｐ２００７−５１２５５０）
【出願日】平成１７年５月２日（２００５．５．２）
【国際出願番号】ＰＣＴ／ＩＢ２００５／００１１８７
【国際公開番号】ＷＯ２００５／１０７２１１
【国際公開日】平成１７年１１月１０日（２００５．１１．１０）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公表日】平成２０年１月１０日（２００８．１．１０）
【国際特許分類】
【出願日】平成１７年５月２日（２００５．５．２）
【国際出願番号】ＰＣＴ／ＩＢ２００５／００１１８７
【国際公開番号】ＷＯ２００５／１０７２１１
【国際公開日】平成１７年１１月１０日（２００５．１１．１０）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]