JP4643430B2 - 通信プログラム、通信方法および通信装置 - Google Patents

Description

本発明は通信プログラム、通信方法および通信装置に関し、特にクライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信プログラム、通信方法および通信装置に関する。

最近、知的生産性の向上には複数人によるコンピュータシステムを活用したコラボレーション（共同作業）が有効であることが認識されている。このコラボレーションを行うことにより、ネットワークを利用したデータの共有が容易になるため、ネットワーク利用者同士での連携による共同作業をスムーズに行うことができる。これに従いアドレス帳等の利用者間のコミュニケーションをサポートする機能を備えたグループウェア製品や、アプリケーションを共有してファイルの編集や閲覧等を行う電子会議支援アプリケーション等が開発されている。

その一方で、近年１人のユーザが、複数の端末装置を所有するようになり、また、コラボレーションを行うことができる機器（ツール）も、多種見受けられる。このようにコラボレーション手段が多様化してきており、それと並行して複数の端末装置やアプリケーションを同時に使用するコミュニケーション（マルチモーダル）を行うのが一般的になってきている。例えば、電話で会話している最中にＰＣ（Personal Computer）のアプリケーションを共有したり、ＵＲＬ（Uniform Resource Locator）や電話番号等の文字情報をインスタントメッセージ（以下、「ＩＭ」という）やチャット等で伝達したりする等のコラボレーションスタイルが定着してきている。

したがって、例えば相手からの電話連絡があったとき、相手は固定ＩＰ（Internet Protocol）電話を使って電話を掛けているのか、ＰＣ上で動作するソフトフォンを使用して電話を掛けているのか等により可能なコラボレーション手段は異なるので、相手の状態を確認しないと適切なコラボレーションを行うことができず、コラボレーションを行う際の手続きが非常に複雑化してきている。

また、複数の端末装置や複数のＩＤ（Idetification）を所有するユーザが、場所や時間に応じて端末装置やＩＤを使い分けた場合、その場その時で使用しているＰＣのＩＰアドレスや、ＩＭまたはチャットのＩＤを自分で調べたり相手に確認を取ったりする必要がある。更に、アプリケーションを共有してコラボレーションを行う場合には、お互いにアプリケーション共有機能を持つアプリケーションをインストールしているか否か、相互接続可能性があるか否かを確認しなければならない。その上、コラボレーション手段が確定した後でも、アクセス先情報をＰＣにユーザが入力してコラボレーションを開始する必要がある。

ＰＣ上で動作するソフトフォンの中には、単なる通話機能やメッセージ機能のほかに、ファイル転送、アプリケーション共有、共有ホワイトボード等のコラボレーション機能を備えているものがある。また、バディリストと呼ばれるユーザの状態監視機能を備えているものがある。このバディリストに、ユーザが予め特定のユーザのＳＩＰ ＵＲＩ（ＩＰ電話やＩＭ等ＳＩＰ（Session Initiation Protocol）を使用して通信するアプリケーションのためのＩＤ）を登録しておくと、そのユーザのソフトフォンの状態（オンライン・オフライン等）を常に確認することができ、それを選択することで、簡単に電話を掛けたり、ＩＭでメッセージを送信したりアプリケーション共有をしたりすることができる。しかし、バディリストは、利用がひとつの端末装置内で閉じており、ソフトフォンによる電話やＩＭしかできない上に、アプリケーション共有は、そのソフトフォンがインストールされているＰＣでしか利用できない。また、相手が使用できるアプリケーションを口頭で確認したり、アプリケーションの共有ができない場合には、手動でフォーマット変換をしたりして、何らかの手段でファイルを送信しなければならず、適切なコラボレーション手段の選択は容易ではない。したがって、一人のユーザが複数の様々な端末装置を同時に利用する場合には、煩雑な手順が必要となる。

このため、電話の通話セッション情報を保持し、別の通信手段によるアクセス要求があると、通話セッションから相手を特定し、コネクションを確立する方法が知られている（例えば、特許文献１参照）。特許文献１によれば、コールセンタにおいて、顧客とオペレータが電話による対応を行っている時に、Ｗｅｂ（World Wide Web）画面を共有したり、Ｗｅｂから電話の予約を行ったりすることができる。そのため、相手のＩＤを指定しなくても、電話を掛けたり、Ｗｅｂページを共有したりすることができる。
特開２００１−９４６７１号公報

しかしながら、特許文献１では、利用環境がコールセンタに限定され、また、コラボレーション方法が、電話とＷｅｂとによるコラボレーションに限定されており、様々なコミュニケーションツールやアプリケーションを駆使する一般のコラボレーションには適用が難しいという問題があった。

このため、複数のユーザがそれぞれ複数の端末装置を使用しながらコラボレーションを行う場合、お互いにどのようなアプリケーションが利用可能か、どの端末装置およびＩＤを使ってアクセスすればよいか等を容易に知ることも、お互いの通信メディアやアプリケーションを簡単に制御することもできず、円滑にコラボレーションを行うことができないという問題があった。

本発明はこのような点に鑑みてなされたものであり、通信相手が利用可能なコミュニケーション手段に応じた自己のコミュニケーション手段の選択および実行を容易に行うことができる通信プログラム、通信方法および通信装置を提供することを目的とする。

本発明では上記問題を解決するために、図１に示すような通信プログラムが提供される。本発明に係る通信プログラムは、クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信プログラムである。

本発明の通信プログラムを実行するコンピュータは以下の機能を有する。
プロファイル管理手段３は、コミュニケーション手段毎の機器種別情報とユーザ識別情報との組にユーザＩＤを関連づけた固有情報３ａを管理する。

アプリ制御手段４は、ユーザ間でいずれかのコミュニケーション手段を用いたセッションが確立すると、プロファイル管理手段３が管理する固有情報３ａを参照し、セッションが確立したコミュニケーション手段の機器種別情報とユーザ識別情報との組にユーザＩＤとの対応付けを行う。

収集手段５は、コミュニケーション手段毎の機器種別情報およびユーザ識別情報に、コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報５ａを収集する。

プレゼンス管理手段６は、アプリ制御手段４でユーザＩＤが特定されると、プレゼンス情報５ａを参照し、セッションが確立したユーザのクライアント端末１、１ａに対して、通信相手が使用可能なコミュニケーション手段における通信相手のユーザ識別情報を通知する。

このような通信プログラムによれば、プロファイル管理手段３により、コミュニケーション手段毎の機器種別情報とユーザ識別情報との組にユーザＩＤを関連づけた固有情報３ａが管理される。また、アプリ制御手段４により、ユーザ間でいずれかのコミュニケーション手段を用いたセッションが確立すると、プロファイル管理手段３が管理する固有情報３ａが参照され、セッションが確立したコミュニケーション手段の機器種別情報とユーザ識別情報との組にユーザＩＤとの対応付けが行われる。また、収集手段５により、コミュニケーション手段毎の機器種別情報およびユーザ識別情報に、コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報５ａが収集される。そして、プレゼンス管理手段６により、アプリ制御手段４によってユーザＩＤが特定されると、プレゼンス情報５ａが参照され、セッションが確立したユーザのクライアント端末１、１ａに対して、通信相手が使用可能なコミュニケーション手段における通信相手のユーザ識別情報が通知される。

また、上記課題を解決するために、クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信方法において、前記コミュニケーション手段毎の前記機器種別情報と前記ユーザ識別情報との組にユーザＩＤを関連づけた固有情報を管理し、ユーザ間でいずれかの前記コミュニケーション手段を用いたセッションが確立すると、前記固有情報を参照し、前記セッションが確立した前記コミュニケーション手段の前記機器種別情報と前記ユーザ識別情報との組に前記ユーザＩＤとの対応付けを行い、前記コミュニケーション手段毎の前記機器種別情報および前記ユーザ識別情報に、前記コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報を収集し、前記ユーザＩＤが特定されると、前記プレゼンス情報を参照し、前記セッションが確立したユーザの前記クライアント端末に対して、通信相手が使用可能な前記コミュニケーション手段における前記通信相手の前記プレゼンス情報を通知する、ことを特徴とする通信方法が提供される。

このような通信方法によれば、コミュニケーション手段毎の機器種別情報とユーザ識別情報との組にユーザＩＤを関連づけた固有情報が管理され、ユーザ間でいずれかのコミュニケーション手段を用いたセッションが確立すると固有情報が参照され、セッションが確立したコミュニケーション手段の機器種別情報とユーザ識別情報との組にユーザＩＤとの対応付けが行われる。また、コミュニケーション手段毎の機器種別情報およびユーザ識別情報に、コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報が収集される。そして、ユーザＩＤが特定されると、プレゼンス情報が参照され、セッションが確立したユーザのクライアント端末に対して、通信相手が使用可能なコミュニケーション手段における通信相手のプレゼンス情報が通知される。

また、上記課題を解決するために、クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信装置において、前記コミュニケーション手段毎の前記機器種別情報と前記ユーザ識別情報との組にユーザＩＤを関連づけた固有情報を管理するプロファイル管理手段と、ユーザ間でいずれかの前記コミュニケーション手段を用いたセッションが確立すると、前記プロファイル管理手段が管理する前記固有情報を参照し、前記セッションが確立した前記コミュニケーション手段の前記機器種別情報と前記ユーザ識別情報との組に前記ユーザＩＤとの対応付けを行うアプリ制御手段と、前記コミュニケーション手段毎の前記機器種別情報および前記ユーザ識別情報に、前記コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報を収集する収集手段と、前記アプリ制御手段で前記ユーザＩＤが特定されると、前記プレゼンス情報を参照し、前記セッションが確立したユーザの前記クライアント端末に対して、通信相手が使用可能な前記コミュニケーション手段における前記通信相手の前記プレゼンス情報を通知するプレゼンス管理手段と、を有することを特徴とする通信装置が提供される。

このような通信装置によれば、上記通信プログラムを実行するコンピュータと同様の処理が実行される。

本発明によれば、ユーザ間でいずれかのコミュニケーション手段を用いたセッションが確立すると、セッションが確立したユーザのクライアント端末に対してお互いのプレゼンス情報を通知するので、ＩＰアドレスやユーザＩＤ等を相手に確認することなく容易かつ確実に所望のコミュニケーション手段を用いたコラボレーションを実現することができる。これにより、コラボレーションの効率化を図ることができる。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。

図１は、本発明の原理説明図である。
図１に示す通信システム４０は、それぞれ同機能を有するクライアント端末１、１ａおよびサーバ２で構成されている。

クライアント端末１（１ａ）は、情報管理手段７（７ａ）とアプリ制御ＵＩ８（８ａ）とを備えている。
情報管理手段７（７ａ）は、端末内のコミュニケーション手段２３（２３ａ）からアプリケーションの状態や周辺機器・サービスに関する情報を収集し、サーバ２に登録する。

アプリ制御ＵＩ８（８ａ）は、サーバ２からユーザ自身およびコラボレーション（共同作業）相手の計算機環境情報を取得して表示し、通信相手であるクライアント端末１ａ（１）とのコラボレーションのための操作を行うユーザインタフェースである。

サーバ２は、プロファイル管理手段３とアプリ制御手段４と、収集手段５と、プレゼンス管理手段６とを有している。
プロファイル管理手段３は、コミュニケーション手段毎の機器種別情報とユーザ識別情報との組にユーザＩＤを関連づけた固有情報３ａを管理する。

アプリ制御手段４は、ユーザ間でいずれかのコミュニケーション手段を用いたセッションが確立すると、プロファイル管理手段３が管理する固有情報３ａを参照し、セッションが確立したコミュニケーション手段の機器種別情報とユーザ識別情報との組にユーザＩＤとの対応付けを行う。

また、アプリ制御手段４は、新しいセッションを作成したり、例えばコミュニケーション手段がＶｏＩＰ（Voice over Internet Protocol）やＩＭを用いたものである場合、ＳＩＰサーバやＩＭサーバ等の専用サーバからセッション情報を取得したり、ファイル送信等各種コミュニケーション手段の制御を行う。

収集手段５は、コミュニケーション手段毎の機器種別情報およびユーザ識別情報に、コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報５ａを収集する。

このプレゼンス情報５ａには、情報管理手段７（７ａ）から収集したデータや、図示しない専用サーバを介してコミュニケーション手段２１、２２から収集したデータ等が格納される。

プレゼンス管理手段６は、アプリ制御手段４でユーザＩＤが特定されると、プレゼンス情報５ａを参照し、セッションが確立したユーザのクライアント端末１、１ａに対して、通信相手が使用可能なコミュニケーション手段における双方のプレゼンス情報を通知する。

このような通信システム４０によれば、情報管理手段７、７ａにより、コミュニケーション手段２１、２２、２３、２３ａに関する情報がサーバ２のプレゼンス管理手段６に集約される。そして、例えばコミュニケーション手段２１、２２間のセッションが確立すると、アプリ制御ＵＩ８、８ａに、それぞれ通信相手のプレゼンス情報が通知される。この情報は、例えばＩＰアドレスやユーザＩＤ等の通信相手とコラボレーションをするために必要な情報を含んでいる。そのため、ユーザはアプリ制御ＵＩ８（８ａ）を操作することで、ＩＰアドレスやユーザＩＤ等を相手に確認したり、直接手入力したりしなくても、簡単にコラボレーションを実現することができる。

以下、本発明の実施の形態を具体的に説明する。
図２は、第１の実施の形態のシステム構成例を示す図である。
図２に示す通信システム５００は、既存のセッション情報に基づいて、コラボレーションを動的に追加する機能を持つシステムであり、サーバ１００、クライアント２００、２０１、ＳＩＰサーバ３００およびＩＭサーバ４００が互いにネットワーク１０で接続されている。

また、通信システム５００には、クライアント２００および通信メディア６０で構成されるコラボレーション群５０と、クライアント２０１および通信メディア６５で構成されるコラボレーション群５１とが形成されている。

クライアント２００、２０１には、それぞれＩＭ、電子メールおよびファイル転送手段等のアプリケーションがインストールされている。
通信メディア６０は、携帯電話６１と、ＩＰアドレスを有し、インターネットを利用してリアルタイムの音声通話を行うＩＰ電話６２と、クライアント２００のアプリケーション上で動作するソフトフォン（ソフトウェアフォン）６３とを有している。

クライアント２００が有する各アプリケーションと携帯電話６１とＩＰ電話６２とソフトフォン６３とが、それぞれコラボレーション群５１とのコラボレーションを行うためのコミュニケーションツールを構成している。

通信メディア６５は、通信メディア６０とそれぞれ同機能を有する携帯電話６６と、ＩＰ電話６７と、ソフトフォン６８とを有している。
クライアント２０１が有する各アプリケーションと携帯電話６６とＩＰ電話６７とソフトフォン６８それぞれが、コラボレーション群５０とのコラボレーションを行うためのコミュニケーションツールを構成している。

ユーザＡおよびユーザＢは、それぞれコラボレーション群５０およびコラボレーション群５１のコミュニケーションツールを用いて互いにコラボレーションを行う。
サーバ１００は、クライアント２００、２０１から情報を収集し、管理するコンピュータである。

ＳＩＰサーバ３００は、コミュニケーションツール間で行われるＶｏＩＰのセッション確立、編集、終了等の処理を仲介役として手助けする。また、ＩＭサーバ４００は、ＩＭに関するユーザのプレゼンス情報を管理、参照、ＩＭの送受信機能を有している。すなわち、ＳＩＰサーバ３００およびＩＭサーバ４００は、外部にＶｏＩＰやＩＭに関するイベントやプレゼンス情報を通知する機能を有しており、これらのサーバとしては、例えばＰａｒｌａｙ（登録商標）のようなオープンインタフェースを備えたサーバやＳＩＰシグナリングのプログラムを得るＳＩＰアプリケーションサーバ等が好ましい。

次に、本実施の形態に用いるサーバのハードウェア構成について説明する。
図３は、本実施の形態に用いるサーバのハードウェア構成を示す図である。
サーバ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。また、ＨＤＤ１０３内には、プログラムファイルが格納される。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令にしたがって、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。

通信インタフェース１０６は、ネットワーク１０に接続されている。通信インタフェース１０６は、ネットワーク１０を介して、他のコンピュータとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３にはサーバ１００の構成を示したが、クライアント２００、２０１についても同様のハードウェアで実現することができる。

このようなハードウェア構成のシステムにおいてコラボレーションを行うために、サーバ１００およびクライアント２００、２０１内には、以下のような機能が設けられる。
図４は、サーバおよびクライアントの機能を示すブロック図である。

サーバ１００は、アプリ制御部１１０とプレゼンス管理部１２０とプレゼンスＤＢ（データベース）１３０とプロファイル管理部１４０とプロファイルＤＢ１５０とインタフェース部１６０とを有している。

アプリ制御部１１０は、新しいセッションを作成したり、ＳＩＰサーバ３００やＩＭサーバ４００からセッション情報を取得したり、ファイル送信を行ったりして各種アプリケーションや通信メディア６０、６５の制御を行う。

また、アプリ制御部１１０は、ＳＩＰサーバ３００やＩＭサーバ４００からのプレゼンス情報を取得すると、必要に応じてプレゼンス管理部１２０が読み取り可能なフォーマットに変換を行い、プレゼンス管理部１２０に送信する。通知されるプレゼンス情報は、例えばユーザＡのコミュニケーションツールのＳＩＰ ＵＲＩ、ＩＰアドレスや、コミュニケーションツールが携帯電話６１、ＩＰ電話６２またはソフトフォン６３であればこれらがオンライン、オフラインまたは通話中であるかの情報や、通話中であれば通話相手であるユーザＢの携帯電話６６、ＩＰ電話６７またはソフトフォン６８のＳＩＰ ＵＲＩ等である。

プレゼンス管理部１２０は、アプリ制御部１１０や、後述するローカルアプリ情報管理部２３０からプレゼンス情報を取得すると、ユーザ毎にプレゼンスＤＢ１３０に格納して管理し、状況に応じてクライアント２００、２０１に通知する。

プロファイル管理部１４０は、通信メディア６０またはクライアント２００毎のメディアタイプ（機器種別情報）とメディアＩＤ（ユーザ識別情報）とを組み合わせた情報にユーザＡのユーザＩＤを関連づけた固有情報がそれぞれ関連づけられたユーザプロファイルを取得すると、プロファイルＤＢ１５０に格納して管理する。なお、ユーザプロファイルについては後に詳述する。

インタフェース部１６０は、ＴＣＰ（Transmission Control Protocol）／ＩＰによりネットワーク１０を介したデータ通信を行う。
次に、クライアント２００、２０１について説明する。

なお、クライアント２００、２０１の機能の主要部は互いに等しいため、代表的にクライアント２００の機能について説明する。
クライアント２００は、アプリケーション２１０とアプリ制御ＵＩ２２０とローカルアプリ情報管理部２３０とプロファイル操作ＵＩ２４０とインタフェース部２５０とを有している。

アプリケーション２１０は、クライアント２００にインストールされているアプリケーションである。
アプリ制御ＵＩ２２０は、サーバ１００からユーザＡおよびユーザＢのコミュニケーションツール使用環境情報を取得し、その情報を例えばモニタ１１に表示させる等、コラボレーションのための操作を行うユーザインタフェースである。

ローカルアプリ情報管理部２３０は、例えばレジストリ等を参照したり、特定のフォルダを検索したりすることによりインストールされているアプリケーション２１０の種別や、共有機能を持つか否か等、アプリケーション２１０の状態を収集し、サーバ１００に登録する。

プロファイル操作ＵＩ２４０は、ユーザのキーボード１２やマウス１３を用いた入力によるユーザプロファイルの登録動作があると、プロファイル管理部１４０にその登録情報を送信するユーザインタフェースである。

インタフェース部２５０は、インタフェース部１６０と同様の機能を備えている。
なお、以下ではクライアント２０１が有する機能は、クライアント２００の有する機能の各部の末尾に“ａ”をつけて表す。例えば、クライアント２０１のアプリ制御ＵＩは、アプリ制御ＵＩ２２０ａとする。

図５は、通信システムの動作の概要を説明する図である。
なお、図５においては、ＩＭサーバ４００、サーバ１００の機能の一部の記載およびクライアント２００、２０１の機能の一部の記載を省略している。

クライアント２００が起動すると、ローカルアプリ情報管理部２３０が、クライアント２００内にインストールされているアプリケーション２１０を調べ、その情報をユーザＡのプレゼンス情報として、プレゼンス管理部１２０に通知する。

一方、携帯電話６１、ＩＰ電話６２およびソフトフォン６３のプレゼンス情報は、ＳＩＰサーバ３００またはＩＭサーバ４００から送信され、アプリ制御部１１０を通してプレゼンス管理部１２０に通知される。この動作が、ユーザ毎のコミュニケーションツールに対して行われる。

ここで、ＳＩＰサーバ３００およびＩＭサーバ４００が、どのユーザのプレゼンス情報を通知するかは、ユーザＡおよびユーザＢがプロファイル管理部１４０に自分のＳＩＰ ＵＲＩを登録するときに（後述するユーザプロファイルの登録フェーズで）アプリ制御部１１０が、ＳＩＰサーバ３００およびＩＭサーバ４００に指示を行う。

プレゼンス管理部１２０は、アプリ制御部１１０やローカルアプリ情報管理部２３０から通知されてくるプレゼンス情報を、ユーザ毎に分類し管理する。そして、ユーザＡのコミュニケーションツールと、ユーザＢのコミュニケーションツールとのセッションが確立した場合、（クライアントが起動した時点で既にセッションが確立している場合を含む）プレゼンス管理部１２０が、双方のプレゼンス情報を、クライアント２００のアプリ制御ＵＩ２２０およびクライアント２０１のアプリ制御ＵＩ２２０ａに送信する。

ここで、例えばアプリ制御ＵＩ２２０がユーザＢのプレゼンス情報を受信すると、その旨をモニタ１１上にポップアップさせる等して、ユーザＢのプレゼンス情報、すなわちユーザＢが使用可能なコミュニケーションツールを表示させる。この表示方法としては、特に限定されないが、例えばクライアント２００とクライアント２０１（送信元と宛先）のプレゼンスをすべて一覧で表示する方法や、お互いに共通に使用可能なコミュニケーションツールのみを強調表示する方法等が挙げられる。これにより、ユーザＡは、ユーザＢがどのようなアプリケーション２１０ａや通信メディア６５を使用可能なのかを知ることができる。

図６は、第１の実施の形態のアプリ制御ＵＩの操作画面を示す図である。
アプリ制御ＵＩ２２０は、操作画面１１ａにコラボレーションの状態を確認するためのアイコン等のコラボレーション確認部１４を表示させる。そして、ユーザＢが使用するコミュニケーションツールとのコラボレーションが確立すると、吹き出し１５を表示させることにより、ユーザＡに通知させる。また、ユーザＡがコラボレーション確認部１４を選択（クリック）すると、ユーザＢが現在使用可能なコミュニケーションツールを示すコミュニケーションツール使用環境画面１６を操作画面１１ａ上に表示させる。

また、コミュニケーションツール使用環境画面１６では、コミュニケーションツール毎に項目およびその項目に関連するアイコン１６ａ〜１６ｆが表示される。例えば、図６に示すように、音声通信手段としてソフトフォン、固定ＩＰ電話、携帯ＩＰ電話が使用可能な場合は、これらは電話の各項目として表示されている。

その後、ユーザＡにより、例えばアイコン１６ａをダブルクリックする等してコミュニケーションツール使用環境画面１６に表示されたコミュニケーションツールが選択されると、アプリ制御ＵＩ２２０が、サーバ１００を介してアプリ制御ＵＩ２２０ａに対応する処理を実行させる。例えばアプリ制御ＵＩ２２０がファイル送信等を行い、アプリ制御ＵＩ２２０ａが、そのファイルに対応したリアクションをとる。

ユーザＡは、コミュニケーションツール使用環境画面１６の各項目を選択することにより、選択したコミュニケーションツールを用いてユーザＢとコラボレーションを開始することができる。

ところで、通信システム５００は、このようなコラボレーションを行うために、ユーザプロファイルの登録フェーズ、プレゼンス収集・通知フェーズ、コラボレーション手段の追加フェーズの３つのフェーズを実行する。以下、各フェーズについて順を追って説明する。

＜ユーザプロファイルの登録フェーズ＞
ユーザプロファイルの登録フェーズは、ユーザＡが、各種通信メディアに付与されるユーザＩＤに関する情報であるユーザプロファイルをサーバ１００に登録する際に実行されるフェーズである。

ユーザＡは、プロファイル操作ＵＩ２４０を操作して、サーバ１００のプロファイル管理部１４０にアクセスし、プロファイルＤＢ１５０に、ユーザプロファイルを格納する。
この際、メディアに関する情報の更新があった場合、イベント通知要求を行うことにより、イベント情報（例えばＩＰ電話であれば、通話中になった場合やログインした場合等の情報）を確実にＳＩＰサーバ３００に通知する。なお、イベント通知要求については後に詳述する。

次に、プロファイルＤＢ１５０に格納されるユーザプロファイルについて説明する。
本実施の形態では、ユーザプロファイルはテーブル化されて格納されている。
なお、ユーザプロファイルは例えばＸＭＬ（eXtensible Markup Language）で表現してもよい。

図７は、ユーザプロファイルテーブルを示す図である。
ユーザプロファイルテーブル１５１には、ユーザＩＤ、メディアタイプ、メディアＩＤ、説明の欄（属性）が設けられている。各欄の横方向に並べられた項目が互いに関連づけられて１つのユーザプロファイルを構成している。

ユーザＩＤの欄には、通信システム５００におけるユーザＡの識別子であるユーザＩＤ“ｆｏｏ”およびユーザＢの識別子であるユーザＩＤ“ｇｏｏ”が設定されている。
メディアタイプの欄には、ユーザＡが利用可能な通信メディア６０およびアプリケーション２１０の機器種別情報がユーザＩＤ“ｆｏｏ”に関連づけられて設定されている。また、ユーザＢが利用可能な通信メディア６５およびアプリケーション２１０ａの機器種別情報が、ユーザＩＤ“ｇｏｏ”に関連づけられて設定されている。

ここで、例えばユーザＩＤ“ｆｏｏ”の“ｖｏｉｐ”は携帯電話６１、ＩＰ電話６２およびソフトフォン６３のメディアタイプを意味し、“ｉｍ”はインスタントメッセージのメディアタイプを意味し、“ｍａｉｌ”は携帯電話６１のメールアドレスのメディアタイプを意味し、“ｃｏｌｌａｂｏ”はクライアント２００のクライアントプログラムに対して割り振られたメディアタイプを意味している。すなわち、“ｃｏｌｌａｂｏ”はアプリ制御ＵＩ２２０、ローカルアプリ情報管理部２３０およびプロファイル操作ＵＩ２４０を含む概念である。

メディアＩＤの欄には、通信メディアまたはアプリケーションを特定する（通信メディアおよびアプリケーション固有の）ＩＤが設定されている。
説明の欄には、メディアＩＤが具体的にどのメディアに付与されているＩＤかの説明が設定（記入）されている。なお、この説明の欄に設定された説明が、コミュニケーションツール使用環境画面１６の各項目に記載される。

このように、ローカルアプリ情報管理部２３０およびローカルアプリ情報管理部２３０ａからプレゼンス管理部１２０にプレゼンス情報が通知されるコミュニケーションツールと、ＳＩＰサーバ３００またはＩＭサーバ４００からプレゼンス管理部１２０にプレゼンス情報が通知されるコミュニケーションツールとは別個に設定される。

次に、ユーザプロファイルの登録フェーズの処理シークエンス（処理動作）について、ＩＰ電話の登録フェーズを例にとって説明する。
図８は、ユーザプロファイルの登録フェーズの処理シークエンスを示す図である。

まず、プロファイル操作ＵＩ２４０が、ユーザＡによるユーザＩＤおよびパスワードの入力により、ログイン要求を確認すると、そのログイン情報（認証情報）をプロファイル管理部１４０に送信する（ステップＳ１１）。

次に、認証が行われると、プロファイル操作ＵＩ２４０が、既に取得しているユーザプロファイルがあれば、それをプロファイル管理部１４０に送信する（ステップＳ１２）。
その後、ユーザＡによりプロファイル操作ＵＩ２４０が操作されてユーザプロファイルの更新（登録・削除）があると、プロファイル操作ＵＩ２４０が、更新されたメディアタイプ、メディアＩＤおよび説明の情報を含むユーザプロファイルをプロファイル管理部１４０に送信する（ステップＳ１３）。

そして、プロファイル管理部１４０が、ＳＩＰサーバ３００に対してイベント通知要求を行う（ステップＳ１４）。このイベント通知要求は、ＳＩＰ ＵＲＩの登録ならば、ＳＩＰサーバ３００またはＩＭサーバ４００に対して情報の伝達要求（subscribe）を実施し、イベントを送信するように指示する。また、ＳＩＰ ＵＲＩの変更ならば、古いＳＩＰ ＵＲＩを削除（unsubscribe）してから新しいＳＩＰ ＵＲＩの伝達要求を実施する。また、ＳＩＰ ＵＲＩの削除ならば該当するＳＩＰ ＵＲＩを削除する。

その後、プロファイル管理部１４０が、ユーザプロファイルテーブル１５１を更新する（ステップＳ１５）。
以上で、ユーザプロファイルの登録フェーズの処理シークエンスを終了する。

＜プレゼンス収集・通知フェーズ＞
プレゼンス収集・通知フェーズは、ユーザＡが利用する通信メディア６０およびアプリケーション２１０の現在状態（オンライン、オフライン、通話中、インストール済み等）とユーザＢが利用する通信メディア６０およびアプリケーション２１０ａの現在状態とをプレゼンス情報としてサーバ１００が取得し、その後サーバ１００が、通信を行っているクライアント２００、２０１に対し、取得した通信相手のプレゼンス情報をそれぞれ通知するフェーズである。このプレゼンス情報の収集方法は、コミュニケーションツールにより異なる。

通信メディア６０、６５のプレゼンス情報は、ＳＩＰサーバ３００およびＩＭサーバ４００がコールイベント（イベント）を起こすことによりアプリ制御部１１０に通知する。アプリ制御部１１０は、イベントが通知されるとそのイベントの形式をチェックし、変換が必要ならば、プレゼンスＤＢ１３０に書き込むためのフォーマットに変換する。例えば、プレゼンスＤＢ１３０にＸＭＬ形式のファイルが格納されているときは、スキーマ変換を行う。また、アプリ制御部１１０は、プロファイル管理部１４０を介してユーザプロファイルテーブル１５１を参照し、ＶｏＩＰやＩＭのＳＩＰ ＵＲＩからユーザＩＤを検索することによりクライアント２００との対応付けを行い、ユーザ単位でプレゼンスを取得できるようにしておく。その後、アプリ制御部１１０がプレゼンス管理部１２０にプレゼンス情報を送信する。プレゼンス管理部１２０は、受け取ったプレゼンス情報をプレゼンスＤＢ１３０に格納する。

一方、アプリケーション２１０のプレゼンス情報は、ローカルアプリ情報管理部２３０が、クライアント２００のレジストリ等を参照したり、特定のフォルダを検索したり、コラボレーションに使用するアプリケーションをユーザが登録したりすることにより、システムやアプリケーションソフトの設定データが記録されているデータベースから取得する。アプリケーション２１０ａについても同様にして取得する。

プレゼンスＤＢ１３０には、プレゼンス情報が例えばテーブル化されて格納されている。
図９は、プレゼンステーブルを示す図である。

プレゼンステーブル１３１には、メディアＩＤ、メディアタイプ、現在状態、状態オプション、コンタクトおよびタイムスタンプの欄が設けられている。各欄の横方向に並べられた項目が互いに関連づけられて、１つのプレゼンス情報を構成している。例えば、メディアＩＤ“ｆｏｏ＠ｐｃ１”、メディアタイプ“ｃｏｌｌａｂｏ”、現在状態“ｏｐｅｎ”、状態オプション“なし”、コンタクト“ｃｏｌｌａｂｏ：１０．２０．３０．４０：１０１０”、タイムスタンプ“２００５−０６−０８Ｔ０１：０１：４７Ｚ”が１つのプレゼンス情報を構成している。

メディアＩＤの欄には、通信メディア６０やクライアント２００にインストールされているアプリケーション（Ｎｏｔｅｐａｄ、Ａｃｒｏｂａｔ（登録商標）等）を識別するＩＤが設定されている。通信メディアのＩＤおよびクライアント２００のＩＤに関しては、ユーザプロファイルテーブル１５１のメディアＩＤの欄に設定されたものと同じメディアＩＤが設定される。アプリケーションのメディアＩＤの欄には、クライアント２００のＩＤ、すなわち“ｆｏｏ＠ｐｃ１”の後ろに、アプリケーションの識別情報（；Ｎｏｔｅｐａｄ、；Ａｃｒｏｂａｔ（登録商標）；ＮｅｔＭｅｅｔｉｎｇ（登録商標））が付加されたメディアＩＤが設定されている。

メディアタイプの欄には、通信メディアやアプリケーションの種類が設定される。ここで、“ｃｏｌｌａｂｏ”はクライアントのメディアタイプ、すなわちクライアント２００を意味し、“ａｐｐｌｉｃａｔｉｏｎ／＊”（＊は拡張子）は、アプリケーションを意味する。

現在状態の欄には、通信メディアやアプリケーションの現在状態が設定されている。通信メディアの現在状態としては、そのアプリケーションが使用可能な場合は“ｏｐｅｎ”（オンライン）が設定されており、アプリケーションが使用不可能な場合は“ｃｌｏｓｅｄ”（オフライン）が設定されており、他のアプリケーションとの間でセッションが確立中の場合は“ｃｏｎｎｅｃｔｅｄ”が設定されている。アプリケーションの現在状態としては、“ｉｎｓｔａｌｌｅｄ”（インストール済み）が設定されている。

状態オプションの欄には、通信メディアの現在状態が“ｃｏｎｎｅｃｔｅｄ”の場合にセッション確立中の相手のメディアＩＤが設定される。
コンタクトの欄には、メディアタイプが“ｃｏｌｌａｂｏ”または“ａｐｐｌｉｃａｔｉｏｎ”の場合にクライアント２００のＩＰアドレスと窓口となるユーザインタフェースのポート番号とが設定されている。このＩＰアドレスとポート番号とは、クライアント２００がサーバ１００にログインする時に設定される。

タイムスタンプには、プレゼンスを更新した日時が設定されている。
このプレゼンス収集・通知フェーズによれば、クライアント２００の起動時やユーザからのリクエストにより、アプリ制御ＵＩ２２０からローカルアプリ情報管理部２３０に対して、アプリケーションの状態情報の登録が指示されると、ローカルアプリ情報管理部２３０は、クライアント２００内のアプリケーション２１０の現在状態を収集し、プレゼンス管理部１２０に送信する。プレゼンス管理部１２０はアプリケーションの現在状態を受け取ると、プレゼンスＤＢ１３０に格納する。これによりプレゼンスＤＢ１３０の内容が更新される。

そして、プレゼンスを更新するときに、現在状態が“ｃｏｎｎｅｃｔｅｄ”であることが予め分かっているため、プレゼンス管理部１２０がプレゼンスＤＢ１３０を更新した後に、状態オプションの欄に設定されたＳＩＰ ＵＲＩからクライアント２００、２０１（通信している両者のクライアント）の現在状態を検索し、クライアント２００のアプリ制御ＵＩ２２０に対して通信を行っている両者のプレゼンス情報を送信し、クライアント２０１のアプリ制御ＵＩ２２０ａに対して、通信を行っている両者のプレゼンス情報を送信する。プレゼンス情報を受信したアプリ制御ＵＩ２２０は、その情報をモニタ１１に表示させる。

次に、通信メディア６０のプレゼンス収集・通知フェーズの処理シークエンスについて、ＩＰ電話の登録フェーズを例にとって説明する。
図１０は、通信メディアのプレゼンス収集・通知フェーズの処理シークエンスを示す図である。

まず、ユーザＡが、ＩＰ電話６２を用いてＩＰ電話６７に通話要求を行うことにより、ＩＰ電話６２のユーザエージェント（以下、ＵＡ１という）とＩＰ電話６７のユーザエージェント（以下、ＵＡ２という）との間で音声を交換するためのＶｏＩＰセッションを確立するための発呼処理（ｏｎｅ−ｃａｌｌのＳＩＰシグナリング）が実行される（ステップＳ２１〜Ｓ２６）。具体的には、ＵＡ１がＳＩＰサーバ３００に、ＵＡ２に対する接続要求（INVITE）を送信する（ステップＳ２１）。

次に、ＳＩＰサーバ３００が、ＩＰ電話６７のＩＰアドレスを確認し、ＩＰ電話６７に対する接続要求を送信する（ステップＳ２２）。
例えば受話器のオフフック等によってＩＰ電話６７の接続が確認されると、ＵＡ２が、接続要求に対して成功応答（２００ＯＫ）をＳＩＰサーバ３００に返す（ステップＳ２３）。

そして、ＳＩＰサーバ３００がＵＡ１に成功応答を返す（ステップＳ２４）。
次に、ＵＡ１は、ＳＩＰサーバ３００（ＵＡ２）からの成功応答を元にＡＣＫ応答（セッション確立了解）をＳＩＰサーバ３００に送信する（ステップＳ２５）。

次に、ＳＩＰサーバ３００が、ＡＣＫ応答をＵＡ２へ送信する（ステップＳ２６）。これにより、ＩＰ電話６２とＩＰ電話６７との間にセッションが確立する。確立されたセッション上で、音声データがやりとりされ、通話状態となる。

次に、ＳＩＰサーバ３００が、アプリ制御部１１０にコールイベントを通知する（ステップＳ２７）。
そして、アプリ制御部１１０がコールイベントを受けると、必要に応じてプレゼンステーブル１３１に書き込むためのスキーマ変換を行い、プレゼンス管理部１２０にプレゼンスの更新をかける（ステップＳ２８）。これにより、プレゼンステーブル１３１のＩＰ電話６２およびＩＰ電話６７のプレゼンスの欄が“ｏｐｅｎ”から“ｃｏｎｎｅｃｔｅｄ”に設定される。

次に、プレゼンス管理部１２０が、プレゼンステーブル１３１のユーザＩＤが“ｆｏｏ”でメディアタイプの欄が“ｃｏｌｌａｂｏ”の現在状態の欄をチェックする（ステップＳ２９）。

そして、ユーザＡおよびユーザＢのプレゼンス情報をクライアント２００に対して通知する（ステップＳ３０）。
次に、プレゼンス管理部１２０が、プレゼンステーブル１３１のユーザＩＤが“ｇｏｏ”でメディアタイプの欄が“ｃｏｌｌａｂｏ”の現在状態の欄をチェックする（ステップＳ３１）。

そして、ユーザＡおよびユーザＢのプレゼンス情報をクライアント２０１に対して通知する（ステップＳ３２）。
これにより、図６に示す吹き出し１５が表示される。

なお、通話が終了した場合は、ＳＩＰサーバ３００が再びコールイベントをアプリ制御部１１０に通知することにより、現在状態の欄が“ｃｏｎｎｅｃｔｅｄ”から“ｏｐｅｎ”に更新される。

また、通信メディアとしてＩＭを用いた場合は、ＩＭサーバ４００を中継してステップＳ２１〜Ｓ２６の代わりに、通常のＩＭのメッセージ送信処理を行い、Ｓ２７の代わりにメッセージ送信イベントを通知することによりプレゼンスが“ｃｏｎｎｅｃｔｅｄ”に変更される。ＶｏＩＰと異なり、ＩＭには明示的に会話の終了を行うことができないので、メッセージの送信後、ある一定時間経過したならば、会話を終了したと見なし、プレゼンスを“ｃｏｎｎｅｃｔｅｄ”から“ｏｐｅｎ”に更新する。

次に、アプリケーション２１０のプレゼンス収集・通知の処理シークエンスについて説明する。
図１１は、アプリケーションのプレゼンス収集・通知の処理シークエンスを示す図である。

まず、クライアント２００が起動されると、アプリ制御ＵＩ２２０が、サーバ１００のアドレス、ＩＤ、パスワード等の設定ファイルを読み込む（ステップＳ４１）。
次に、アプリ制御ＵＩ２２０が、モニタ１１にプレゼンス情報を表示させるための操作画面１１ａを作成する（ステップＳ４２）。通常、この画面は、タスクトレイの中にアイコンとして表示されている。

次に、アプリ制御ＵＩ２２０が、ローカルアプリ情報管理部２３０のインスタンスを生成する（ステップＳ４３）。
次に、アプリ制御ＵＩ２２０が、ローカルアプリ情報管理部２３０にアプリ情報登録を指示する（ステップＳ４４）。

次に、ローカルアプリ情報管理部２３０が、クライアント２００内にインストールされているアプリケーション２１０を調べ、プレゼンス管理部１２０に認証情報とともにプレゼンス更新要求を送信する（ステップＳ４５）。

次に、プレゼンス管理部１２０が、認証情報に基づいて認証を行い（ステップＳ４６）、認証が行われると、ユーザＩＤに基づいて、現在状態が“ｏｐｅｎ”のクライアントを検索する（ステップＳ４７）。

そして、プレゼンス管理部１２０は、現在状態が“ｏｐｅｎ”のクライアントを発見すると、アプリ制御ＵＩ２２０にプレゼンス通知を行う（ステップＳ４８）。これにより、操作画面１１ａに通信メディアおよびアプリケーションの状態が表示される。

また、プレゼンス管理部１２０が、セッションの状態を調べ、セッションが確立している場合には、通信相手を特定し、通信相手の現在状態が“ｏｐｅｎ”のクライアントを継続して検索する（ステップＳ４９）。

そして、プレゼンス管理部１２０が、アプリ制御ＵＩ２２０ａにプレゼンス通知を行う（ステップＳ５０）。
以上で、アプリケーションのプレゼンス収集・通知動作を終了する。

＜コラボレーションの追加フェーズ＞
コラボレーションの追加フェーズでは、ユーザＡがコミュニケーションツール使用環境画面１６に表示されたコミュニケーションツールから希望するものを選択したときに実行されるフェーズである。その手順は、コミュニケーションツールの種別に応じて異なる。

例えば、コミュニケーションツールがＩＰ電話の場合は、アプリ制御ＵＩ２２０が、認証情報、ユーザＡ（発側）のユーザＩＤ“ｆｏｏ”、ユーザＢ（着側）のユーザＩＤ“ｇｏｏ”を含む情報をアプリ制御部１１０に渡す発呼処理を行い、ＳＩＰサーバ３００のＡＰＩ（Application Program Interface）を呼び出す。その結果、ＩＰ電話６２とＩＰ電話６７との間でＳＩＰセッションが確立する。

また、例えばコミュニケーションツールがＩＭの場合は、アプリ制御ＵＩ２２０から、認証情報、発側ユーザＩＤ、着側ユーザＩＤを含む情報をアプリ制御部１１０に渡すＩＭ送信処理を行い、ＩＭサーバ４００のＡＰＩを呼び出す。その結果クライアント２０１に接続されたモニタに、ユーザＢ宛のメッセージを送信するための画面が表示される。

また、例えばコミュニケーションツールがファイル送信の場合は、アプリ制御ＵＩ２２０が、認証情報、送信先ＵＲＩ、ファイル名およびコンテンツを含む情報をアプリ制御部１１０に渡すファイル送信を指示する。アプリ制御部１１０は、送信先ＵＲＩにより示されるクライアント２０１に対して指定されたファイルを送信し、アプリ制御ＵＩ２２０ａが、受信したファイルをクライアント２０１に接続されたモニタに表示する。

また、例えばコミュニケーションツールがネットワーク会議ツールやコミュニケーションツール等のアプリケーション共有ツールの場合は、アプリ制御ＵＩ２２０は、クライアント２００内の共有アプリケーションのＡＰＩを使って、アプリケーション共有を実施する。なお、ＡＰＩはアプリケーション毎に異なる可能性があるので、拡張・変更可能なようにドライバをプラグイン可能にしておいてもよい。

次に、コミュニケーションツールの追加フェーズの処理シークエンスについてＩＰ電話６２を追加する場合を例として説明する。
図１２は、ＩＰ電話のコラボレーション追加フェーズの処理シークエンスを示す図である。

まず、ユーザＡがコミュニケーションツール使用環境画面１６に表示されたコミュニケーションツールからＩＰ電話６２を選択すると、アプリ制御ＵＩ２２０が、アプリ制御部１１０に対して発呼処理を行う（ステップＳ５１）。

次に、アプリ制御部１１０が、第三者発呼を実行し、ＳＩＰサーバ３００内の第三者発呼サーバのＡＰＩを呼び出す（ステップＳ５２）。
次に、ＳＩＰシグナリングを行う（ステップＳ５３〜Ｓ５８）。具体的には、まず、ＳＩＰサーバ３００が、ＵＡ１に対する接続要求（INVITE）を送信し（ステップＳ５３）、その後ＵＡ２に対する接続要求（INVITE）を送信する（ステップＳ５４）。

ＵＡ１は、接続要求を受けると、その接続要求に対して成功応答（２００ＯＫ）をＳＩＰサーバ３００に返す（ステップＳ５５）。また、ＵＡ２は、接続要求を受けると、その接続要求に対して成功応答（２００ＯＫ）をＳＩＰサーバ３００に返す（ステップＳ５６）。

次に、ＳＩＰサーバ３００はＵＡ１およびＵＡ２からの成功応答を元にＡＣＫ応答をＵＡ１およびＵＡ２に送信する（ステップＳ５７、Ｓ５８）。
次に、ＳＩＰサーバ３００が、アプリ制御部１１０にコールイベントを通知する（ステップＳ５９）。

次に、アプリ制御部１１０が、プレゼンス更新および通知を行う（ステップＳ６０〜Ｓ６４）。この動作は、図１０のステップＳ２８〜Ｓ３２と同様であるため、その説明を省略する。

次に、コミュニケーションツールの追加フェーズの処理シークエンス（処理動作）についてファイル送信を行う場合を例として説明する。
図１３は、ファイル送信を行う場合のコラボレーション追加フェーズの処理シークエンスを示す図である。

まず、ユーザＡがコミュニケーションツール使用環境画面１６に表示されたコミュニケーションツールからファイル送信を選択すると、アプリ制御ＵＩ２２０が、アプリ制御部１１０にファイルを送信する（ステップＳ７１）。

次に、アプリ制御部１１０が、認証を行い（ステップＳ７２）、認証されるとクライアント２０１のアプリ制御ＵＩ２２０ａにファイルを送信する（ステップＳ７３）。
次に、アプリ制御ＵＩ２２０ａが、アプリケーション２１０ａにアプリ起動命令を送信する（ステップＳ７４）。これにより送信したファイルに対応するアプリケーション２１０ａを起動する。

一方、ステップＳ７１において、ユーザＡがファイルの共有を希望するオプションを付加している場合は、アプリ制御ＵＩ２２０が、送信したファイルに対応するアプリケーション２１０を起動する（ステップＳ７５）。

以上述べたように、通信システム５００によれば、クライアントのローカルアプリ情報管理部２３０、ＳＩＰサーバ３００およびＩＭサーバ４００により、ユーザが利用するコミュニケーションツールに関するプレゼンス情報がプレゼンス管理部１２０に集約される。そして、ユーザＡおよびユーザＢ間でいずれかのコミュニケーションツールを用いたセッションが確立すると、通信を行っているユーザＡが使用するクライアント２００のアプリ制御ＵＩ２２０およびユーザＢが使用するクライアント２００ａのアプリ制御ＵＩ２２０ａに、双方のプレゼンス情報が送信される。プレゼンス情報は、ＩＰアドレスやユーザＩＤ等の相手とコラボレーションをするために必要な情報を含んでいる。そのため、ユーザＡはアプリ制御ＵＩ２２０を操作することで、ＩＰアドレスやユーザＩＤ等を相手に確認したり、直接手入力したりすることなく、容易かつ確実にコラボレーションを行うことができる。その結果、コラボレーションを円滑にかつ効率的に行うことができる。

なお、本実施の形態では、電子メールは、ユーザＡがユーザプロファイルテーブル１５１に登録するものとしたが、これに限らず、例えばＡｐａｃｈｅ Ｊａｍｅｓ（Java（登録商標） Apache Mail Enterprise Server）のようにプログラム可能なメールサーバを利用し、ＶｏＩＰやＩＭと同じような仕組みでプレゼンス情報を取得してもよく、また、メールアプリケーションに、プレゼンス情報を登録するプラグインを組み込んでもよい。

また、本実施の形態ではＳＩＰサーバ３００およびＩＭサーバ４００が、外部にＶｏＩＰやＩＭに関するイベントやプレゼンスを通知する機能を有していたが、これに限らず通信メディア６０、６５（ＳＩＰ端末側）がイベントやプレゼンス情報を通知する機能を有していてもよく、その場合はＳＩＰサーバ３００およびＩＭサーバ４００は外部にイベントやプレゼンスを通知する機能を有している必要はない。

次に、通信システムの第２の実施の形態について説明する。
図１４は、第２の実施の形態のシステムを示すブロック図である。
以下、第２の実施の形態の通信システム５００ａについて、前述した第１の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。

第１の実施の形態のコラボレーション追加フェーズでは、コミュニケーションツールは、ユーザが選択するものとしていたが、第２の実施の形態のコラボレーション追加フェーズでは、コミュニケーションツールの位置の情報や、メディアタイプをさらに細かく分類する端末種別の情報に関するプリファレンス情報に基づいて、使用するコミュニケーションツールを選択する点が異なっている。

第２の実施の形態の通信システム５００ａは、プリファレンス管理要求を受け付けるプリファレンス管理部１７０およびその管理データを格納するプリファレンスＤＢ１８０をさらに有するサーバ１００ａと、プリファレンス管理要求を実行するためのプリファレンス操作ＵＩ２６０をさらに有するクライアント２００ａと、プリファレンス管理要求を実行するためのプリファレンス操作ＵＩ２６０ａをさらに有するクライアント２０１ａとを備えている。

図１５は、第２の実施の形態のユーザプロファイルテーブルを示す図である。
ユーザプロファイルテーブル１５１ａは、ユーザプロファイルテーブル１５１に比べて端末種別および位置の欄（属性）が追加されている。

これらの情報は、例えばユーザＡがプロファイル操作ＵＩ２４０を用いて設定する。
端末種別の欄には、コミュニケーションツールの種別が設定される。例えば、携帯電話６１であれば“ｍｏｂｉｌｅ”が設定され、固定ＩＰ電話６２であれば“ｆｉｘｅｄ”が設定され、ソフトフォン６３であれば“ｓｏｆｔ”が設定される。

位置の欄には、メディアタイプが“ｃｏｌｌａｂｏ”および“ｍｏｂｉｌｅ”以外のコミュニケーションツールに対して位置情報が設定される。
具体的には端末種別が“ｓｏｆｔ”または“ｆｉｘｅｄ”のコミュニケーションツールに関しては、位置関係が最も近いクライアント２００のメディアＩＤが設定される。よって、ソフトフォン６３は、そのソフトウェアがインストールされているクライアント２００のメディアＩＤ“ｆｏｏ＠ｐｃ１”が設定される。また、固定ＩＰ電話６２は、クライアント２００のメディアＩＤ“ｆｏｏ＠ｐｃ１”が設定される。また、携帯電話６１のメールであれば、携帯のメディアＩＤである“ｓｉｐ：ｆｏｏ＠ｍｏｂｉｌｅ．＊＊＊．ｃｏｍ”が設定される。

また、ユーザＡがクライアント２００とは別のクライアントを利用可能な場合、そのクライアントのメディアＩＤ（図１５中ではｆｏｏ＠ｐｃ２）も設定することができる。
また、ユーザＡは、プリファレンス操作ＵＩ２６０を使用し、サーバ１００ａのプリファレンス管理部１７０にアクセスし、プリファレンスＤＢ１８０に、コミュニケーションツールの優先順位を予め登録しておく。この情報は例えばテーブル化されて格納される。

図１６は、プリファレンステーブルを示す図である。
プリファレンステーブル１８１にはユーザＩＤとプリファレンスの欄が設けられている。各欄の横方向に並べられた項目が互いに関連づけられている。

図１６では、ユーザＩＤ“ｆｏｏ”のプリファレンスの欄には優先度が高い順に“ｍｏｂｉｌｅ”、“ｆｉｘｅｄ”、“ｓｏｆｔ”が設定されている。
そして、例えばコラボレーションの追加フェーズで、メディアタイプ“ｖｏｉｐ”が選択された場合、図１２の発呼処理（Ｓ５１）において、アプリ制御部１１０がプロファイルテーブル１５１ａとプレゼンステーブル１３１とプリファレンステーブル１８１とを参照し、クライアントと位置を同じにするＶｏＩＰ端末を検索する。そして、見つかったＶｏＩＰ端末の内、状態が“ｏｐｅｎ”で優先順位が一番高い端末を選択して発呼を行う。

次に、第２の実施の形態のコラボレーション追加フェーズについてＩＰ電話６２を用いた場合について詳しく説明する。
第２の実施の形態のコラボレーション追加フェーズは、図１２に示すステップＳ５２〜Ｓ６４については第１の実施の形態と同様の処理を行い、以下の動作が、ステップＳ５１の直後に実行され、適切な発呼先が決定される。

図１７は、第２の実施の形態のコラボレーション追加フェーズの処理シークエンスを説明するフローチャートである。
まず、アプリ制御部１１０が、現在状態が“ｃｏｎｎｅｃｔｅｄ”のＩＭセッション情報を取得する（ステップＳ８１）。

次に、アプリ制御部１１０が、ＩＭセッション情報からメディアＩＤを取得する（ステップＳ８２）。
次に、アプリ制御部１１０が、プロファイル管理部１４０にユーザプロファイルテーブル１５１ａを取り出すよう指示を行い、アプリ制御部１１０が、取り出したメディアの位置情報を取得したか否かを判断する（ステップＳ８３）。

メディアの位置情報が取得できない場合（ステップＳ８３のＮｏ）、例えばモニタ１１にエラーである旨を報知する等の所定のエラー処理を実行して動作を終了する（ステップＳ８４）。一方、メディアの位置情報が取得できた場合（ステップＳ８３のＹｅｓ）、位置情報が一致するメディアタイプ“ｖｏｉｐ”のコミュニケーションツールを取得したか否かを判断する（ステップＳ８５）。取得できない場合（ステップＳ８５のＮｏ）、ステップＳ８４に移行して所定のエラー処理を実行して動作を終了する。一方、取得した場合（ステップＳ８５のＹｅｓ）、その中から現在状態が“ｏｐｅｎ”のコミュニケーションツールの一覧を求める（ステップＳ８６）。現在状態が“ｏｐｅｎ”のコミュニケーションツールがない場合（ステップＳ８６のＮｏ）、ステップＳ８４に移行して所定のエラー処理を実行して動作を終了する。一方、現在状態が“ｏｐｅｎ”のコミュニケーションツールがあれば（ステップＳ８６のＹｅｓ）、プリファレンス情報を参照して発呼を行うコミュニケーションツールを決定する（ステップＳ８７）。

以上で、第２の実施の形態のコラボレーション追加フェーズの処理シークエンスを終了する。
この第２の実施形態の通信システム５００ａによれば、第１の実施の形態の通信システム５００と同様の効果が得られる。

そして、第２の実施形態の通信システム５００ａによれば、ユーザＡがコミュニケーションツールの優先順位を予めプリファレンステーブル１８１に設定しておくことにより、ユーザＡは、所望の端末を用いてコラボレーションを行うことができる。具体的には、例えばユーザＢからユーザＡへの通話でのコラボレーション要求が行われたときに、ユーザＡは、携帯電話６１、固定ＩＰ電話６２およびソフトフォン６３のうち所望の端末に着信させることができる。

次に、通信システムの第３の実施の形態について説明する。
第３の実施の形態では、コラボレーションを行うクライアント２００およびクライアント２０１の各両者の使用環境に応じて、アプリケーション共有が可能ならアプリケーション共有を行い、不可能ならアプリケーション共有の代替手段の一例としてファイル送信を行う。またファイル送信の際、クライアント２００から送信したファイルをクライアント２０１が表示できない場合には、ファイル形式をクライアント２０１が表示できる形式に変換して送信する等、両者の使用環境を最大限活用できる方法でコラボレーションを行うものである。

図１８は、第３の実施の形態のシステムを示すブロック図である。
以下、第３の実施の形態の通信システム５００ｂについて、前述した第１の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。

通信システム５００ｂは、ファイル形式変換部１９０と、ファイル形式の変換規則をテーブル化したアプリケーションデータプロファイルテーブルを備えるプロファイルＤＢ１５０ａと、ファイル提供部１９１とをさらに有するサーバ１００ｂを備えている。

ファイル形式変換部１９０は、アプリ制御部１１０の指示に応じて入力されるファイルの形式を変換し、アプリ制御ＵＩ２２０に送信する。
図１９は、アプリケーションデータプロファイルテーブルを示す図である。

アプリケーションデータプロファイルテーブル１５２には、アプリタイプ、変換方法の欄が設けられている。また、変換方法は、ターゲットタイプおよびプログラムの各項目に分割されている。各欄の横方向に並べられた項目が互いに関連づけられている。

アプリタイプの欄には、ファイルの拡張子が設定されている。
ターゲットタイプの欄には、アプリタイプの拡張子を変換するファイルの拡張子が設定されている。

プログラムの欄には、そのターゲットタイプの拡張子に変換するためのプログラムの格納先が設定されている。
再び図１８に戻って説明する。

ファイル提供部１９１は、アプリ制御部１１０からのファイルの提供があると、ファイルをＨＴＭＬ（Hyper Text Markup Language）に変換し、保持する機能を備えている。また、ファイル提供部１９１はＷｅｂサーバの機能を持ち、ブラウザを使って提供されたファイルを読み込み、ファイルにアクセスするためのＵＲＬをクライアント２０１に送信する。

次に、第３の実施の形態のコラボレーション追加フェーズの処理シークエンスについて説明する。
なお、以下では、コラボレーションが成立した場合にアプリケーション共有を行う場合について説明する。

図２０および図２１は、第３の実施の形態のコラボレーション追加フェーズの処理シークエンスを説明するフローチャートである。
ユーザＡにより、クライアント２００からアプリケーション共有が選択されると、まず、アプリ制御部１１０が、現在状態が“ｃｏｎｎｅｃｔｅｄ”のＶｏＩＰセッション情報を取得する（ステップＳ９１）。

次に、アプリ制御部１１０が、ＶｏＩＰセッション情報からメディアＩＤを取得する（ステップＳ９２）。
次に、アプリ制御部１１０が、プロファイル管理部１４０にユーザプロファイルテーブル１５１ａを取り出すよう指示を行い、アプリ制御部１１０が、取り出したメディアの位置情報を取得したか否かを判断する（ステップＳ９３）。メディア情報の位置情報が取得できない場合（ステップＳ９３のＮｏ）、エラー処理を実行して判定動作を終了する（ステップＳ９４）。一方、メディア情報の位置情報が取得できた場合（ステップＳ９３のＹｅｓ）、位置情報が一致するアプリケーション２１０のメディアＩＤを取得する（ステップＳ９５）。

アプリケーションのメディアＩＤを取得できない場合（ステップＳ９５のＮｏ）、ステップＳ９４に移行してエラー処理を実行して判定動作を終了する。
一方、アプリケーションのメディアＩＤを取得できた場合（ステップＳ９５のＹｅｓ）、アプリ制御部１１０が、プレゼンスＤＢ１３０を参照することにより、共有したいデータのアプリケーションが利用可能か否か、すなわち現在状態が“ｉｎｓｔａｌｌｅｄ”か否かを確認する（図１６のステップＳ９６）。共有したいデータのアプリケーションが利用可能の場合（ステップＳ９６のＹｅｓ）、共有したいデータのアプリケーションを共有するための共有用アプリケーション（例えば、メッセンジャー機能を有するアプリケーション）が利用可能か否かを確認する（ステップＳ９７）。共有用アプリケーションが利用可能である場合（ステップＳ９７のＹｅｓ）、共有用アプリケーションを用いて共有処理を実行し（ステップＳ９８）、判定動作を終了する。また、共有用アプリケーションが利用可能ではない場合（ステップＳ９７のＮｏ）、ステップＳ９９に移行する。

一方、共有したいデータのアプリケーションが利用可能ではない場合（ステップＳ９６のＮｏ）、アプリ制御部１１０が、アプリケーションデータプロファイルテーブル１５２を参照する（ステップＳ９９）。

次に、アプリ制御部１１０が、共有したいデータが、相手のクライアントの環境において表示可能なデータ形式に変換可能か否かを確認する（ステップＳ１００）。
変換可能である場合（ステップＳ１００のＹｅｓ）、アプリ制御部１１０が、ファイル形式変換部１９０にデータを送信し、ファイル形式変換部１９０が、ファイル形式変換および送信処理を実行し（ステップＳ１０１）、判定動作を終了する。また、変換可能ではない場合（ステップＳ１００のＮｏ）、アプリ制御部１１０が、データをファイル提供部１９１に送信し、ファイル提供部１９１がＨＴＭＬ変換を行い、ＵＲＬをクライアント２０１に送信する（ステップＳ１０２）。

これにより、ＵＲＬを受け取ったアプリ制御ＵＩ２２０ａはブラウザを起動し、受信したＵＲＬのドキュメントを表示する。
以上で第３の実施の形態のコラボレーション追加フェーズを終了する。

この第３の実施形態の通信システム５００ｂによれば、第１の実施の形態の通信システム５００と同様の効果が得られる。
ユーザのパソコンにアプリケーション共有機能を持つアプリケーションがインストールされていなければ、アプリケーション共有は実施できないが、第３の実施形態の通信システム５００ｂによれば、ファイルを送信することで、目的とする情報の共有を達成することができる。

次に、通信システムの第４の実施の形態について説明する。
第１の実施の形態〜第３の実施の形態では、コラボレーションツールとして、通信メディア６０とアプリケーション２１０を対象にしていたが、第４の実施の形態では、コラボレーションツールとしてネットワーク１０に接続されている他の機器やサービスをも利用する点が異なっている。

以下、第４の実施の形態の通信システムについて、前述した第１の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。
第４の実施の形態の通信システムは、ローカルアプリ情報管理部２３０が、ＵＰｎＰ（Universal Plug and Play）の機能を有している。

ローカルアプリ情報管理部２３０は、ＵＰｎＰプロトコルによって同一セグメント内でコミュニケーションツールを発見し、得られた情報をプレゼンス情報としてプレゼンスＤＢ１３０に格納（登録）する。格納時には、プレゼンステーブル１３１の現在情報およびタイムスタンプの欄には第１の実施の形態と同様にして設定を行う。そして、メディアＩＤの欄にはＵＰｎＰアクションのＵＲＬを設定し、メディアタイプの欄には“ｕｐｎｐ／（サービスのデバイスタイプ）”を設定し、状態オプションの欄にはアクションに必要なパラメータを設定し、コンタクトの欄にはメディアＩＤと同じくＵＰｎＰアクションのＵＲＬを設定する。

そして、第１の実施の形態と同様に、セッションが確立し、プレゼンス情報が通知され、コミュニケーションツールとしてＵＰｎＰサービスが選択されると、ＵＰｎＰアクションのＵＲＬを呼び出しサービスを実行する。

この第４の実施形態の通信システムによれば、第１の実施の形態の通信システム５００と同様の効果が得られる。
そして、第４の実施形態の通信システムによれば、第３の実施の形態で説明したように、例えばアプリケーション共有ができない場合の代替手段としてファイルを送信する代わりに、ＵＰｎＰ対応のプリンタを発見していれば、そのファイルを印刷して情報を共有することができる等、さらにお互いの計算機環境を最大限に生かせるコラボレーションを実現することができる。

なお、本実施の形態ではコントロールポイントの機能としてＵＰｎＰを用いたが、本発明ではこれに限定されない。
次に、通信システムの第５の実施の形態について説明する。

以下、第５の実施の形態の通信システム５００ｃについて、前述した第１〜第４の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。
第１〜第４の実施の形態では、セッションが確立したときに、サーバ１００がクライアント２００にユーザＢのプレゼンス情報を通知し、クライアント２０１にユーザＡのプレゼンス情報を通知したが、第５の実施の形態では、クライアントがプレゼンス情報を要求したときに、サーバ１００がクライアント２００にユーザＢのプレゼンス情報を通知し、クライアント２０１にユーザＡのプレゼンス情報を通知する。

図２２は、第５の実施の形態のシステムを示すブロック図である。
第５の実施の形態のクライアント２００ｂ、２０１ｂは、コラボレーションを行うユーザを登録したユーザリスト管理ＤＢ２７０、２７０ａをさらに備えている。

ユーザリストは、例えばユーザＡが、予めユーザリスト管理ＤＢ２７０に登録しておく。なお、ユーザリストは、サーバ１００で管理してもよいし、直接ユーザＩＤを手入力してもよい。

アプリ制御ＵＩ２２０は、コラボレーションを開始する前処理としてユーザリスト管理ＤＢ２７０を操作画面１１ａに表示させる。ユーザＡがコラボレーションを行うユーザを指定すると、アプリ制御ＵＩ２２０がプレゼンス管理部１２０にプレゼンス情報を要求する。または、バディリスト（ユーザリスト）のように、プレゼンス情報を予め読み込んでおいてもよい。そして、アプリ制御ＵＩ２２０が、プレゼンス情報を取得すると、ユーザＡおよびユーザＢが利用可能なコミュニケーションツールを操作画面１１ａに表示する。

図２３は、表示画面に表示されるコミュニケーションツール使用環境画面を示す図である。
操作画面１１ａに表示されたコミュニケーションツール使用環境画面１７は、ユーザＡのコミュニケーションツール群１８とユーザＢのコミュニケーションツール群１９とを有している。

ユーザＡは、例えばマウス１３等を用いて自分が使用するコミュニケーションツール（図２３では固定ＩＰ電話）と、コラボレーションを希望するユーザＢのコミュニケーションツール（図２３では携帯電話）を指定することによりコラボレーションが開始される。

この第５の実施形態の通信システム５００ｃによれば、第１の実施の形態の通信５００と同様の効果が得られる。
そして、第５の実施形態の通信システム５００ｃによれば、さらに、容易にコラボレーションを図ることができる。

以上、本発明の好適な実施の形態について詳述したが、本発明は、その特定の実施の形態に限定されるものではない。
なお前述した各実施の形態では、ユーザＡとユーザＢとの間（クライアント２００、２０１間）での通信例を説明したが、本発明ではこれに限らず、複数ユーザ間（３つ以上のクライアント間）でのコラボレーションも行うことができる。

また、上記のサーバ１００やクライアント２００、２０１の処理機能は、コンピュータによって（コンピュータに所定の通信プログラムを実行させることにより）実現することができる。その場合、サーバ１００やクライアント２００、２０１が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクとしては、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。光磁気記録媒体としては、例えば、ＭＯ（Magneto-Optical disk）等が挙げられる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

通信プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

（付記１） クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信プログラムにおいて、
コンピュータを、
ユーザ毎に、前記コミュニケーション手段毎の前記機器種別情報と前記ユーザ識別情報との組にユーザＩＤを関連づけた固有情報を管理するプロファイル管理手段、
ユーザ間でいずれかの前記コミュニケーション手段を用いたセッションが確立すると、前記プロファイル管理手段が管理する前記固有情報を参照し、前記セッションが確立した前記コミュニケーション手段の前記機器種別情報と前記ユーザ識別情報との組に前記ユーザＩＤとの対応付けを行うアプリ制御手段、
前記コミュニケーション手段毎の前記機器種別情報および前記ユーザ識別情報に、前記コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報を収集する収集手段、
前記アプリ制御手段で前記ユーザＩＤが特定されると、前記プレゼンス情報を参照し、前記セッションが確立したユーザの前記クライアント端末に対して、通信相手が使用可能な前記コミュニケーション手段における前記通信相手の前記プレゼンス情報を通知するプレゼンス管理手段、
として機能させることを特徴とする通信プログラム。

（付記２） 前記アプリ制御手段は、前記セッションの確立中の前記クライアント端末により前記ユーザの前記通信相手が使用可能な前記コミュニケーション手段の使用要求があると、前記使用要求に応じて前記通信相手の前記クライアント端末に前記使用要求に対応する処理を実行させることを特徴とする付記１記載の通信プログラム。

（付記３） 前記固有情報は、前記コミュニケーション手段毎の前記クライアント端末との位置関係を示す位置情報をさらに有し、
前記コンピュータを、さらに共通の前記機器種別情報を有する前記コミュニケーション手段の優先順位情報を管理するプリファレンス管理手段として機能させ、
前記アプリ制御手段は、前記セッションが確立したユーザのユーザＩＤに関連する前記共通の前記位置情報を有する前記機器種別情報が複数あるときは、前記優先順位に従い前記通信相手の前記クライアント端末に対応する処理を実行させることを特徴とする付記２記載の通信プログラム。

（付記４） 前記アプリ制御手段は、前記セッションの確立中のユーザの前記クライアント端末により前記コミュニケーション手段を用いたデータの通信要求があると、
前記セッションの確立中の通信相手の前記クライアント端末のユーザの前記コミュニケーション手段が使用可能か否かを判断し、
前記通信相手の前記クライアント端末が前記コミュニケーション手段を実行できない場合に、代替手段を用いて前記データを前記通信相手の前記クライアント端末に送信することを特徴とする付記１記載の通信プログラム。

（付記５） 前記代替手段は、ファイル形式を変換するファイル形式変換手段を有し、
前記通信相手の前記クライアント端末が前記コミュニケーション手段を実行できない場合に、前記ファイル形式変換手段が、前記データを所定のファイル形式に変換して前記通信相手の前記クライアント端末に送信することを特徴とする付記４記載の通信プログラム。

（付記６） 前記代替手段は、ファイル形式をＨＴＭＬ形式に変換して保持するＨＴＭＬ変換手段を有し、
前記通信相手の前記クライアント端末が前記コミュニケーション手段を実行できない場合に、前記ＨＴＭＬ変換手段が、前記データをＨＴＭＬ形式に変換して保持し、前記ＨＴＭＬ形式のＵＲＬを前記通信相手の前記クライアント端末に送信することを特徴とする付記４記載の通信プログラム。

（付記７） 収集手段は、前記クライアント端末の同一セグメント内の前記コミュニケーション手段の前記プレゼンス情報を収集することを特徴とする付記１記載の通信プログラム。

（付記８） 前記コミュニケーション手段は、ＩＰアドレスを備えていることを特徴とする付記１記載の通信プログラム。
（付記９） 前記収集手段は、前記コミュニケーション手段がセッション開始プロトコルを用いる場合、セッション開始プロトコルサーバから前記プレゼンス情報を取得することを特徴とする付記１記載の通信プログラム。

（付記１０） 前記プレゼンス管理手段は、前記通信相手に前記プレゼンス情報を通知する際に、ユーザ自身の前記プレゼンス情報を通知することを特徴とする付記１記載の通信プログラム。

（付記１１） クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信方法において、
ユーザ毎に、前記コミュニケーション手段毎の前記機器種別情報と前記ユーザ識別情報との組にユーザＩＤを関連づけた固有情報を管理し、
ユーザ間でいずれかの前記コミュニケーション手段を用いたセッションが確立すると、前記固有情報を参照し、前記セッションが確立した前記コミュニケーション手段の前記機器種別情報と前記ユーザ識別情報との組に前記ユーザＩＤとの対応付けを行い、
前記コミュニケーション手段毎の前記機器種別情報および前記ユーザ識別情報に、前記コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報を収集し、
前記ユーザＩＤが特定されると、前記プレゼンス情報を参照し、前記セッションが確立したユーザの前記クライアント端末に対して、通信相手が使用可能な前記コミュニケーション手段における前記通信相手および自分の前記プレゼンス情報を通知する、
ことを特徴とする通信方法。

（付記１２） クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信装置において、
ユーザ毎に、前記コミュニケーション手段毎の前記機器種別情報と前記ユーザ識別情報との組にユーザＩＤを関連づけた固有情報を管理するプロファイル管理手段と、
ユーザ間でいずれかの前記コミュニケーション手段を用いたセッションが確立すると、前記プロファイル管理手段が管理する前記固有情報を参照し、前記セッションが確立した前記コミュニケーション手段の前記機器種別情報と前記ユーザ識別情報との組に前記ユーザＩＤとの対応付けを行うアプリ制御手段と、
前記コミュニケーション手段毎の前記機器種別情報および前記ユーザ識別情報に、前記コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報を収集する収集手段と、
前記アプリ制御手段で前記ユーザＩＤが特定されると、前記プレゼンス情報を参照し、前記セッションが確立したユーザの前記クライアント端末に対して、通信相手が使用可能な前記コミュニケーション手段における前記通信相手の前記プレゼンス情報を通知するプレゼンス管理手段と、
を有することを特徴とする通信装置。

本発明の原理説明図である。 第１の実施の形態のシステム構成例を示す図である。 本実施の形態に用いるサーバのハードウェア構成を示す図である。 サーバおよびクライアントの機能を示すブロック図である。 通信システムの動作の概要を説明する図である。 第１の実施の形態のアプリ制御ＵＩの操作画面を示す図である。 ユーザプロファイルテーブルを示す図である。 ユーザプロファイルの登録フェーズの処理シークエンスを示す図である。 プレゼンステーブルを示す図である。 通信メディアのプレゼンス収集・通知フェーズの処理シークエンスを示す図である（ＶｏＩＰの例）。 アプリケーションのプレゼンス収集・通知の処理シークエンスを示す図である。 ＩＰ電話のコラボレーション追加フェーズの処理シークエンスを示す図である。 ファイル送信を行う場合のコラボレーション追加フェーズの処理シークエンスを示す図である。 第２の実施の形態のシステムを示すブロック図である。 第２の実施の形態のユーザプロファイルテーブルを示す図である。 プリファレンステーブルを示す図である。 第２の実施の形態のコラボレーション追加フェーズの処理シークエンスを説明するフローチャートである。 第３の実施の形態のシステムを示すブロック図である。 アプリケーションデータプロファイルテーブルを示す図である。 第３の実施の形態のコラボレーション追加フェーズの処理シークエンスを説明するフローチャートである。 第３の実施の形態のコラボレーション追加フェーズの処理シークエンスを説明するフローチャートである。 第５の実施の形態のシステムを示すブロック図である。 第５の実施の形態のアプリ制御ＵＩの操作画面を示す図である。

符号の説明

１、１ａ クライアント端末
２ サーバ
３ プロファイル管理手段
３ａ 固有情報
４ アプリ制御手段
５ 収集手段
５ａ プレゼンス情報
６ プレゼンス管理手段
７、７ａ 情報管理手段
８、８ａ アプリ制御ＵＩ
２１、２２、２３、２３ａ コミュニケーション手段
６０、６５ 通信メディア
１００ サーバ
１１０ アプリ制御部
１２０ プレゼンス管理部
１３０ プレゼンスＤＢ
１４０ プロファイル管理部
１５０、１５０ａ プロファイルＤＢ
１６０、２５０ インタフェース部
１７０ プリファレンス管理部
１８０ プリファレンスＤＢ
１９０ ファイル形式変換部
１９１ ファイル提供部
２００、２０１ クライアント
２１０ アプリケーション
２２０ アプリ制御ＵＩ
２３０ ローカルアプリ情報管理部
２４０ プロファイル操作ＵＩ
２６０ プリファレンス操作ＵＩ
３００ ＳＩＰサーバ
４００ ＩＭサーバ
４０、５００、５００ａ、５００ｂ、５００ｃ 通信システム

Claims (10)

1. クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信プログラムにおいて、
   コンピュータを、
   ユーザ毎に、前記コミュニケーション手段毎の前記機器種別情報と前記ユーザ識別情報との組にユーザＩＤを関連づけた固有情報を管理するプロファイル管理手段、
   前記プロファイル管理手段が管理する前記固有情報に基づき前記コミュニケーション手段毎の前記機器種別情報および前記ユーザ識別情報に対して、前記コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報を収集する収集手段、
   ユーザ間でいずれかの前記コミュニケーション手段を用いたセッションが確立すると、前記プロファイル管理手段が管理する前記固有情報を参照し、前記セッションが確立した前記コミュニケーション手段の前記機器種別情報と前記ユーザ識別情報との組から前記ユーザＩＤを特定するアプリ制御手段、
   前記収集手段により収集された前記プレゼンス情報を管理し、前記アプリ制御手段で前記ユーザＩＤが特定されると、前記ユーザＩＤに対する前記プレゼンス情報一式を参照し、前記セッションが確立したユーザの前記クライアント端末に対して、通信相手が使用可能な前記コミュニケーション手段における前記通信相手の前記プレゼンス情報を通知するプレゼンス管理手段、
   として機能させることを特徴とする通信プログラム。
2. 前記アプリ制御手段は、前記セッションの確立中の前記クライアント端末により前記ユーザの前記通信相手が使用可能な前記コミュニケーション手段の使用要求があると、前記使用要求に応じて前記通信相手の前記クライアント端末に前記使用要求に対応する処理を実行させることを特徴とする請求項１記載の通信プログラム。
3. 前記固有情報は、前記コミュニケーション手段毎の前記クライアント端末との位置関係を示す位置情報をさらに有し、
   前記コンピュータを、さらに共通の前記機器種別情報を有する前記コミュニケーション手段の優先順位情報を管理するプリファレンス管理手段として機能させ、
   前記アプリ制御手段は、前記セッションが確立したユーザのユーザＩＤに関連する前記共通の前記位置情報を有する前記機器種別情報が複数あるときは、前記優先順位に従い前記通信相手の前記クライアント端末に対応する処理を実行させることを特徴とする請求項２記載の通信プログラム。
4. 前記アプリ制御手段は、前記セッションの確立中のユーザの前記クライアント端末により前記コミュニケーション手段を用いたデータの通信要求があると、前記セッションの確立中の通信相手の前記クライアント端末のユーザの前記コミュニケーション手段が使用可能か否かを判断し、
   前記通信相手の前記クライアント端末が前記コミュニケーション手段を実行できない場合に、代替手段を用いて前記データを前記通信相手の前記クライアント端末に送信することを特徴とする請求項１記載の通信プログラム。
5. 前記代替手段は、ファイル形式を変換するファイル形式変換手段を有し、
   前記通信相手の前記クライアント端末が前記コミュニケーション手段を実行できない場合に、前記ファイル形式変換手段が、前記データを所定のファイル形式に変換して前記通信相手の前記クライアント端末に送信することを特徴とする請求項４記載の通信プログラム。
6. 前記代替手段は、ファイル形式をＨＴＭＬ形式に変換して保持するＨＴＭＬ変換手段を有し、
   前記通信相手の前記クライアント端末が前記コミュニケーション手段を実行できない場合に、前記ＨＴＭＬ変換手段が、前記データをＨＴＭＬ形式に変換して保持し、前記ＨＴＭＬ形式のＵＲＬを前記通信相手の前記クライアント端末に送信することを特徴とする請求項４記載の通信プログラム。
7. 前記収集手段は、前記クライアント端末の同一セグメント内の前記コミュニケーション手段の前記プレゼンス情報を収集することを特徴とする請求項１記載の通信プログラム。
8. 前記プレゼンス管理手段は、前記通信相手に前記プレゼンス情報を通知する際に、ユーザ自身の前記プレゼンス情報を通知することを特徴とする請求項１記載の通信プログラム。
9. クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信方法において、
   ユーザ毎に管理されている、前記コミュニケーション手段毎の前記機器種別情報と前記ユーザ識別情報との組にユーザＩＤを関連づけた固有情報に基づき前記コミュニケーション手段毎の前記機器種別情報および前記ユーザ識別情報に対して、前記コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報を収集し、
   ユーザ間でいずれかの前記コミュニケーション手段を用いたセッションが確立すると、前記固有情報を参照し、前記セッションが確立した前記コミュニケーション手段の前記機器種別情報と前記ユーザ識別情報との組から前記ユーザＩＤを特定し、
   収集された前記プレゼンス情報を管理し、前記ユーザＩＤが特定されると、前記ユーザＩＤに対する前記プレゼンス情報一式を参照し、前記セッションが確立したユーザの前記クライアント端末に対して、通信相手が使用可能な前記コミュニケーション手段における前記通信相手の前記プレゼンス情報を通知する、
   ことを特徴とする通信方法。
10. クライアント端末間で、機器種別情報およびユーザ識別情報を備えた複数種別のコミュニケーション手段を用いてコラボレーションを行う通信装置において、
    ユーザ毎に、前記コミュニケーション手段毎の前記機器種別情報と前記ユーザ識別情報との組にユーザＩＤを関連づけた固有情報を管理するプロファイル管理手段と、
    前記プロファイル管理手段が管理する前記固有情報に基づき前記コミュニケーション手段毎の前記機器種別情報および前記ユーザ識別情報に対して、前記コミュニケーション手段が使用可能か否かを示す状態情報を関連づけたプレゼンス情報を収集する収集手段と、
    ユーザ間でいずれかの前記コミュニケーション手段を用いたセッションが確立すると、前記プロファイル管理手段が管理する前記固有情報を参照し、前記セッションが確立した前記コミュニケーション手段の前記機器種別情報と前記ユーザ識別情報との組から前記ユーザＩＤを特定するアプリ制御手段と、
    前記収集手段により収集された前記プレゼンス情報を管理し、前記アプリ制御手段で前記ユーザＩＤが特定されると、前記ユーザＩＤに対する前記プレゼンス情報一式を参照し、前記セッションが確立したユーザの前記クライアント端末に対して、通信相手が使用可能な前記コミュニケーション手段における前記通信相手の前記プレゼンス情報を通知するプレゼンス管理手段と、
    を有することを特徴とする通信装置。
    

Images