JP2017069936A - 通信端末、通信システム、出力方法、及びプログラム - Google Patents

Abstract

【課題】通信端末において、例えば、コンテンツ入出力用のリソースが複数実装されている場合、一の通信用のアプリケーションが通信中に一のリソースを利用しても、他の通信用のアプリケーションは他のリソースを利用して通信を開始することもできる。従来のプレゼンス統合管理システムは、複数の通信用のアプリケーションの状態を同期するので、リソースの実装に応じて、通信用のアプリケーション毎に状態を出力することができない。【解決手段】端末１０のセッション制御部（１７ａ，１７ｂ）は、相手側の端末１０との間で送信される呼制御の情報に基づいて映像通信アプリ（Ａ，Ｂ）による通信の制御を行う。端末１０のプレゼンス管理部１２は、セッション制御部（１７ａ，１７ｂ）による制御に応じて、映像通信アプリ（Ａ，Ｂ）による通信の状態を管理する一方で、映像通信アプリ（Ｂ，Ａ）による通信の状態を管理する。【選択図】図１

Description

本発明は、通信端末、通信システム、出力方法、及びプログラムに関する。

近年、当事者の移動の経費や時間を削減する要請等に伴い、インターネットや専用線等の通信ネットワークを介して通話や会議等を行う通信システムが普及している。このような通信システムでは、通信端末間で通信を開始すると、画像データ及び音データ等のコンテンツデータの送受信が行われ、当事者間のコミュニケーションを実現する。

特許文献１には、複数のアプリケーションクライアントプログラムを記憶したメモリ等を有する端末と、上記端末のプレゼンス情報を記憶したメモリ等を有するプレゼンスサーバを備え、プレゼンスサーバは、上記複数のアプリケーションのうちの一のアプリケーションに関する上記端末のプレゼンス情報登録を上記端末から受けた場合に、該一のアプリケーションと同一のグループに属する少なくとも一つの他のアプリケーションに関する上記端末のプレゼンス情報を上記一のアプリケーションと同期させるプレゼンス統合管理システムが開示されている。

通信端末において、例えば、コンテンツ入出力用のリソースが複数実装されている場合、一の通信用のアプリケーションが通信中に一のリソースを利用しても、他の通信用のアプリケーションは他のリソースを利用して通信を開始することもできる。上記のプレゼンス統合管理システムは、複数の通信用のアプリケーションの状態を同期するので、リソースの実装に応じて、通信用のアプリケーション毎に状態を出力することができないという課題が生じる。

請求項１に係る発明の通信端末は、複数の通信用のアプリケーションが起動する通信端末であって、前記複数の通信用のアプリケーションのうち、一方の通信用のアプリケーションによる呼制御のための情報の送信に応じて、前記情報に対応する一方の状態を示す状態情報を出力し、前記一方の状態で利用されるリソースに応じて、前記複数の通信用のアプリケーションのうち他方の通信用のアプリケーションにかかる他方の状態を示す状態情報を出力する出力手段を有する。

以上説明したように本発明によれば、通信端末において、リソースの実装に応じて、通信用のアプリケーション毎に状態を出力することが可能になるという効果を奏する。

本発明の一実施形態に係る通信システムの概略図である。 一実施形態に係る端末のハードウェア構成図である。 一実施形態に係る管理システムのハードウェア構成図である。 一実施形態に係る端末のソフトウェア構成図である。 一実施形態に係る端末、認証サーバ、及び管理システムの各機能ブロック図である。 各管理テーブルを示す概念図である。 一実施形態に係る中継装置管理サーバ及び中継装置の機能ブロック図である。 各管理テーブルを示す概念図である。 一実施形態における認証処理を示すシーケンス図である。 端末間の通信の状態を示す概念図である。 端末間で通信を開始する処理の一例を示すシーケンス図である。 端末間の通信の状態を示す概念図である。 端末間で通信を開始する処理の一例を示すシーケンス図である。 端末の通信の状態を管理する処理の一例を示したシーケンス図である。 図１５は、実施形態の変形例における端末の機能ブロック図である。 図１６は、端末が管理するステートマシンの一例を示す図である。 図１７は、端末に内蔵又は外付けされているデバイスの総数を管理する処理を示すシーケンス図である。 図１８は、プレゼンスを管理する処理を示すフロー図である。

以下、本発明の実施形態について説明する。

＜＜通信システムの概略＞＞
図１は、本発明の一実施形態に係る通信システムの概略図である。図１に示されているように、通信システム１は、通信端末１０、認証サーバ４０、管理システム５０によって構築されている。以下、通信端末１０を単に端末１０と記載する。

管理システム５０は、出版−購読（Publish-Subscribe、以下PubSubと記載する）モデルにおいて、クライアント間でメッセージを交換するために、クライアントから、メッセージの出版（Publish、以下pubと記載する）やメッセージの購読（Subscribe、以下subと記載する）の要求を受け付けるサーバである。管理システム５０は、PubSubモデルに対応するプロトコルとして、例えば、MQTT（MQ Telemetry Transport）や、XMPP（eXtensible Messaging and Presence Protocol）のPubSub拡張（XEP-0060）等を実装しても良い。

端末１０は、例えば、汎用端末であって、任意のクライアントアプリケーションがインストールされている。以下、クライアントアプリケーションをクライアントアプリと表す。また、端末１０は、例えば、専用端末であって、クライアントとして稼働する特定のクライアントアプリが組み込まれている。端末１０が通信ネットワーク２を介して管理システム５０と通信可能に接続することで、各クライアントは、管理システム５０にメッセージのpubやメッセージのsubを要求することができる。端末１０は、例えば、テレビ会議端末、電子黒板、電子看板、電話、タブレット、スマートフォン、カメラ、ＰＣ（personal computer）等であっても良い。

認証サーバ４０は、端末１０上で動作するクライアントアプリである「クライアント」と、そのクライアントを利用する「ユーザ」とをそれぞれ認証し、管理システム５０の利用を認可するサーバである。管理システム５０は、上記の認証及び認可を実現するため、例えば、OAuth 2.0やOpenID connectといった認証、認可のプロトコルを実装する。

図１では、説明を簡単にするために、管理システム５０、及び認証サーバ４０がそれぞれ一つの装置である場合について説明したが、本発明はこのような実施形態に限定されない。管理システム５０、及び認証サーバ４０の少なくとも一方は、複数の装置により構築されていても良い。また、管理システム５０、及び認証サーバ４０が、一つのシステム又は装置によって構築されていても良い。
また、図１では、説明を簡単にするために、通信システム１において、４つの端末１０が設けられている場合について説明したが、本発明はこのような実施形態に限定されない。通信システム１に設けられる端末１０は、２つであっても、３つであっても、５つ以上であっても良い。また、各端末１０は、それぞれ同種であっても、図１のように異種であっても良い。

＜＜ハードウェア構成＞＞
次に、通信システム１を構成する各装置のハードウェア構成を説明する。

図２は、一実施形態に係る端末１０のハードウェア構成図である。なお、端末１０は、通信可能であれば、端末１０のハードウェア構成は図２の構成に限定されない。例えば、端末１０は、図２に記載されていない構成が含まれていても、図２に記載の構成の一部が含まれていなくても良い。また、図２に記載の構成の一部は端末１０に接続可能な外部装置等であっても良い。図２に示されているように、本実施形態の端末１０は、端末１０全体の動作を制御するＣＰＵ(Central Processing Unit)１０１、ＩＰＬ(Initial Program Loader)等のＣＰＵ１０１の駆動に用いられるプログラムを記憶したＲＯＭ(Read Only Memory)１０２、ＣＰＵ１０１のワークエリアとして使用されるＲＡＭ(Random Access Memory)１０３、端末１０の各種端末用のプログラム、画像データ、及び音声データ等の各種データを記憶するフラッシュメモリ１０４、ＣＰＵ１０１の制御にしたがってフラッシュメモリ１０４に対する各種データの読み出し又は書き込みを制御するＳＳＤ（Solid State Drive）１０５、フラッシュメモリやＩＣカード（Integrated Circuit Card）等の記録メディア１０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアＩ／Ｆ１０７、宛先を選択する場合などに操作される操作ボタン１０８、端末１０の電源のＯＮ／ＯＦＦを切り換えるための電源スイッチ１０９、通信ネットワーク２を利用してデータ伝送をするためのネットワークＩ／Ｆ(Interface)１１１を備えている。

また、端末１０は、ＣＰＵ１０１の制御に従って被写体を撮像して画像データを得る内蔵型のカメラ１１２、このカメラ１１２の駆動を制御する撮像素子Ｉ／Ｆ１１３、音声を入力する内蔵型のマイク１１４、音声を出力する内蔵型のスピーカ１１５、ＣＰＵ１０１の制御に従ってマイク１１４及びスピーカ１１５との間で音声信号の入出力を処理する音入出力Ｉ／Ｆ１１６、ＣＰＵ１０１の制御に従って外付けのディスプレイ１２０に画像データを伝送するディスプレイＩ／Ｆ１１７、各種の外部機器を接続するための外部機器接続Ｉ／Ｆ１１８、端末１０の各種機能の異常を知らせるアラームランプ１１９、及び上記各構成要素を図２に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン１１０を備えている。

ディスプレイ１２０は、被写体の画像や操作用等を表示する液晶や有機ＥＬ(Organic Electroluminescence)によって構成された表示部である。また、ディスプレイ１２０は、ケーブル１２０ｃによってディスプレイＩ／Ｆ１１７に接続される。このケーブル１２０ｃは、アナログＲＧＢ（ＶＧＡ）信号用のケーブルであってもよいし、コンポーネントビデオ用のケーブルであってもよいし、ＨＤＭＩ（登録商標）(High-Definition Multimedia Interface)やＤＶＩ(Digital Video Interactive)信号用のケーブルであってもよい。

カメラ１１２は、レンズや、光を電荷に変換して被写体の画像（映像）を電子化する固体撮像素子を含み、固体撮像素子として、ＣＭＯＳ(Complementary Metal Oxide Semiconductor)や、ＣＣＤ（Charge Coupled Device）等が用いられる。

外部機器接続Ｉ／Ｆ１１８には、筐体１１００の接続口１１３２に差し込まれたＵＳＢ(Universal Serial Bus)ケーブル等によって、外付けカメラ、外付けマイク、及び外付けスピーカ等の外部機器がそれぞれ電気的に接続可能である。外付けカメラが接続された場合には、ＣＰＵ１０１の制御に従って、内蔵型のカメラ１１２に優先して、外付けカメラが駆動する。同じく、外付けマイクが接続された場合や、外付けスピーカが接続された場合には、ＣＰＵ１０１の制御に従って、それぞれが内蔵型のマイク１１４や内蔵型のスピーカ１１５に優先して、外付けマイクや外付けスピーカが駆動する。

なお、記録メディア１０６は、端末１０に対して着脱自在な構成となっている。また、ＣＰＵ１０１の制御にしたがってデータの読み出し又は書き込みを行う不揮発性メモリであれば、フラッシュメモリ１０４に限らず、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）等を用いてもよい。

図３は、一実施形態に係る管理システム５０のハードウェア構成図である。管理システム５０は、管理システム５０全体の動作を制御するＣＰＵ５０１、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶したＲＯＭ５０２、ＣＰＵ５０１のワークエリアとして使用されるＲＡＭ５０３、管理システム５０用のプログラム等の各種データを記憶するＨＤ５０４、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出し又は書き込みを制御するＨＤＤ(Hard Disk Drive)５０５、フラッシュメモリ等の記録メディア５０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ５０７、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示するディスプレイ５０８、通信ネットワーク２を利用してデータ通信するためのネットワークＩ／Ｆ５０９、文字、数値、各種指示などの入力のための複数のキーを備えたキーボード５１１、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行うマウス５１２、着脱可能な記録媒体の一例としてのＣＤ−ＲＯＭ(Compact Disc Read Only Memory)５１３に対する各種データの読み出し又は書き込みを制御するＣＤ−ＲＯＭドライブ５１４、及び、上記各構成要素を図３に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン５１０を備えている。
認証サーバ４０は、管理システム５０と同様のハードウェア構成を有しているため、その説明を省略する。

＜＜ソフトウェア構成＞＞
図４は、一実施形態に係る端末１０のソフトウェア構成図である。図４に示されているように、ＯＳ１０２０、統合クライアントアプリ１０３０、クライアントアプリ（１０３１，１０３２）は、端末１０のＲＡＭ１０３の作業領域１０１０上で動作する。ＯＳ１０２０、及び、統合クライアントアプリ１０３０、クライアントアプリ（１０３１，１０３２）は、端末１０にインストールされている。

ＯＳ１０２０は、基本的な機能を端末１０に提供し、端末１０全体を管理する基本ソフトウェアである。統合クライアントアプリ１０３０は、認証サーバ４０に認証を要求し、管理システム５０にpub要求及びsub要求の少なくとも一つを実行するためのアプリである。統合クライアントアプリ１０３０は、各クライアントアプリ（１０３１，１０３２）から送られてくる情報に基づいて、各クライアントアプリ（１０３１，１０３２）の状態を示すプレゼンスを管理する。これにより、統合クライアントアプリ１０３０は、管理システム５０に対して、自端末の各クライアントのプレゼンスをpub要求する。各クライアントアプリ（１０３１，１０３２）は、他の端末１０の対応する各クライアントアプリとの間でコンテンツデータの送信等による通信を行う。各クライアントアプリ（１０３１，１０３２）は、他の端末１０の各クライアントアプリとの間のセッションを確立するときに、呼制御用のメッセージを、統合クライアントアプリ１０３０を介して、他の端末１０のクライアントアプリとの間で送信する。

なお、図４では少なくとも２つのクライアントアプリ（１０３１，１０３２）が端末１０にインストールされているが、１以上の任意のクライアントアプリが端末１０にインストールされていれば良い。

＜＜機能構成＞＞
次に、本実施形態の機能構成について説明する。図５は、一実施形態に係る通信システム１の一部を構成する端末１０、認証サーバ４０、及び管理システム５０の機能ブロック図である。図５では、端末１０、認証サーバ４０、及び管理システム５０が、通信ネットワーク２を介してデータ通信することができるように接続されている。

＜端末の機能構成＞
端末１０は、pubsub送受信部１１、プレゼンス管理部１２、プレゼンス受信部１３、コンテンツ送受信部（１６ａ，１６ｂ）、セッション制御部（１７ａ，１７ｂ）を有している。これら各部は、図２に示されている各構成要素のいずれかが、フラッシュメモリ１０４からＲＡＭ１０３上に展開されたプログラムに従ったＣＰＵ１０１からの命令によって動作することで実現される機能である。なお、上記の各機能部のうち、pubsub送受信部１１、プレゼンス管理部１２、及びプレゼンス受信部１３は、統合クライアントとしての統合通信クライアントが起動することによって稼働する機能である。コンテンツ送受信部１６ａ及びセッション制御部１７ａは、クライアントアプリ１０３１としての映像通信アプリＡが起動することにより稼働する機能である。コンテンツ送受信部１６ｂ及びセッション制御部１７ｂは、クライアントアプリ１０３２としての映像通信アプリＢが起動することにより稼働する機能である。上記では２つのクライアントアプリが起動する場合について説明するが、３つ以上のクライアントアプリが起動しても良い。この場合、起動するクライアントアプリ毎のコンテンツ送受信部及びセッション制御部が稼働することになる。また、端末１０は、ＲＯＭ１０２、ＲＡＭ１０３、フラッシュメモリ１０４によって構築される記憶部１０００を有している。

（端末の各機能構成）
次に、図２及び図５を用いて、端末１０の各機能構成について詳細に説明する。なお、以下では、端末１０の各機能構成を説明するにあたって、図２に示されている各構成要素のうち、端末１０の各機能構成を実現させるための主な構成要素との関係も説明する。

pubsub送受信部１１及びコンテンツ送受信部（１６ａ，１６ｂ）は、ＣＰＵ１０１からの命令、及びネットワークＩ／Ｆ１１１によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。pubsub送受信部１１は、管理システム５０に対して所定のトピックに関連するメッセージのpub要求又はsub要求をすることで、このトピックに関連するメッセージを送受信する。コンテンツ送受信部（１６ａ，１６ｂ）は、他の端末１０との間でコンテンツデータを送受信する。

プレゼンス管理部１２は、ＣＰＵ１０１からの命令によって実現され、自端末における各クライアントアプリによる通信の状態をプレゼンス情報として管理する。

プレゼンス受信部１３は、ＣＰＵ１０１からの命令によって実現され、各クライアントアプリから送られてくるプレゼンス情報を受信する。

セッション制御部（１７ａ，１７ｂ）は、ＣＰＵ１０１からの命令によって実現され、端末１０間で送信される呼制御の情報に基づいて、各クライアントアプリ（１０３１，１０３２）による通信を制御する。

記憶・読出部１９は、ＣＰＵ１０１からの命令及びＳＳＤ１０５によって実行され、又はＣＰＵ１０１からの命令によって実現され、記憶部１０００に各種データを記憶したり、記憶部１０００に記憶された各種データを抽出したりする処理を行う。

＜認証サーバの機能構成＞
認証サーバ４０は、送受信部４１、ユーザ認証部４２、クライアント認証部４３、トークン発行部４５、及び記憶・読出部４９を有する。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された認証サーバ４０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、認証サーバ４０は、ＨＤ５０４により構築される記憶部４０００を有している。

（ユーザ管理テーブル）
図６（Ａ）は、ユーザ管理テーブルを示す概念図である。記憶部４０００には、ユーザ管理テーブルによってユーザ管理ＤＢ４００１が構築される。ユーザ管理テーブルでは、ユーザＩＤ（identifier, identification）毎に、ユーザ名、及びパスワードが関連付けられて管理されている。

（クライアント管理テーブル）
図６（Ｂ）は、クライアント管理テーブルを示す概念図である。記憶部４０００には、クライアント管理テーブルによってクライアント管理ＤＢ４００２が構築される。クライアント管理テーブルでは、クライアントＩＤ毎に、クライアント名、及びパスワードが関連付けられて管理されている。

（サービス管理テーブル）
図６（Ｃ）は、サービス管理テーブルを示す概念図である。記憶部４０００には、サービス管理テーブルによってサービス管理ＤＢ４００３が構築される。サービス管理テーブルでは、サービスＩＤ毎に、サービス名が関連付けられて管理されている。一実施形態において、サービスＩＤ「Ｓ０１」で識別されるサービス「伝送管理システム」は、管理システム５０である。なお、管理システム５０のPubSubの機能を利用する権利がリソースである。また、管理システム５０を使ったPubSubサービスは、OAuth 2.0のプロトコルにおいて認可の単位となるスコープである。また、管理システム５０はリソースサーバに相当する。

（認証サーバの各機能構成）
送受信部４１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。

ユーザ認証部４２は、ＣＰＵ５０１からの命令によって実現され、クライアントからの要求に応じてユーザ認証を行う。

クライアント認証部４３は、ＣＰＵ５０１からの命令によって実現され、クライアントからの要求に応じてクライアント認証を行う。

トークン発行部４５は、ＣＰＵ５０１からの命令によって実現され、クライアントがサービスへアクセスするときに、サービスで用いられる認可トークンを発行する。

記憶・読出部４９は、ＣＰＵ５０１からの命令及びＨＤＤ５０５によって実行され、又はＣＰＵ５０１からの命令によって実現され、記憶部４０００に各種データを記憶したり、記憶部４０００に記憶された各種データを抽出したりする処理を行う。

＜管理システムの機能構成＞
管理システム５０は、送受信部５１、トークン確認部５２、pubsub処理部５４、及び記憶・読出部５９を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された管理システム５０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能又は手段である。また、管理システム５０は、ＨＤ５０４により構築される記憶部５０００を有している。

（トピック管理テーブル）
図６（Ｄ）は、トピック管理テーブルを示す概念図である。記憶部５０００には、トピック管理テーブルによってトピック管理ＤＢ５００１が構築される。トピック管理テーブルでは、トピック名毎に、クライアントＩＤ、及びユーザＩＤが関連付けられて管理されている。トピックとはメッセージに関連付けられる属性である。クライアントアプリがトピック名を指定したpub要求をすると、管理システム５０は、トピック管理テーブルにおいて、指定されたトピック名に関連付けられているクライアントＩＤ及びユーザＩＤによって特定される相手側のクライアントアプリにメッセージを送信する。

（管理システムの各機能構成）
次に、管理システム５０の各機能構成について詳細に説明する。なお、以下では、管理システム５０の各機能構成を説明するにあたって、図３に示されている各構成要素のうち、管理システム５０の各機能構成を実現させるための主な構成要素との関係も説明する。

送受信部５１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して各端末、装置又はシステムと各種データ（または情報）の送受信を行う。

トークン確認部５２は、ＣＰＵ５０１からの命令によって実現され、端末１０のログイン要求に含まれている認可トークンを確認する。

pubsub処理部５４は、ＣＰＵ５０１からの命令によって実現され、クライアントによるpub要求、及びsub要求を受け付ける。

記憶・読出部５９は、ＣＰＵ５０１からの命令及びＨＤＤ５０５によって実行され、又はＣＰＵ５０１からの命令によって実現され、記憶部５０００に各種データを記憶したり、記憶部５０００に記憶された各種データを抽出したりする処理を行う。

＜その他の機器の機能構成＞
端末１０は、中継装置を介して他の端末１０へコンテンツデータを送信しても良い。その場合、通信システム１には、中継装置及び中継装置管理サーバ等が設けられる。なお、中継装置管理サーバ２０及び中継装置３０は、図３の管理システム５０と同様のハードウェア構成を有しているため、その説明を省略する。中継装置３０は、各端末１０のクライアントアプリとの間でセッションを確立し、通信ネットワーク２を介して一方の端末１０のクライアントアプリから送信されるコンテンツデータを、他方の端末１０のクライアントアプリに中継する。中継装置管理サーバ２０は、中継装置３０によるコンテンツデータの中継を管理する。なお、中継装置管理サーバ２０及び中継装置３０は、それぞれ複数設けられていても良い。

＜中継装置管理サーバの機能構成＞
図７は、中継装置管理サーバ２０及び中継装置３０の機能ブロック図である。中継装置管理サーバ２０は、pubsub送受信部２１、中継指示部２２、及び記憶・読出部２９を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された中継装置管理サーバ２０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能又は手段である。また、中継装置管理サーバ２０は、ＨＤ５０４により構築される記憶部２０００を有している。

（会議室管理テーブル）
図８（Ａ）は、会議室管理テーブルを示す概念図である。記憶部２０００には、会議室管理テーブルによって会議室管理ＤＢ２００１が構築される。会議室管理テーブルでは、会議室ＩＤと、端末１０間でコンテンツデータを送信するためのセッションｓｅｄにおける呼制御用のメッセージを示すトピックのトピックＩＤと、が関連付けられて管理されている。なお、会議室ＩＤとは、端末１０間のテレビ会議用のセッションｓｅｄ毎に割り当てられる識別情報であり、会議ＩＤ、セッションＩＤ等に置き換え可能である。

（中継装置利用管理テーブル）
図８（Ｂ）は、中継装置利用管理テーブルを示す概念図である。記憶部２０００には、中継装置利用管理テーブルによって中継装置利用管理ＤＢ２００２が構築される。中継装置利用管理テーブルでは、中継装置３０を利用する各端末１０側のクライアントＩＤと、ユーザＩＤと、が関連付けられて管理されている。

（中継装置管理サーバの各機能構成）
次に、中継装置管理サーバの各機能構成について詳細に説明する。なお、以下では、中継装置管理サーバ２０の各機能構成を説明するにあたって、図３に示されている各構成要素のうち、中継装置管理サーバ２０の各機能構成を実現させるための主な構成要素との関係も説明する。

pubsub送受信部２１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して各端末、装置又はシステムと各種データ（または情報）の送受信を行う。

中継指示部２２は、ＣＰＵ５０１からの命令によって実現され、中継装置３０に対して端末１０間のコンテンツデータの中継の指示を行う。

記憶・読出部２９は、ＣＰＵ５０１からの命令及びＨＤＤ５０５によって実現され、又はＣＰＵ５０１からの命令によって実現され、記憶部２０００に各種データを記憶したり、記憶部２０００に記憶された各種データを抽出する処理を行う。

＜中継装置の機能構成＞
中継装置３０は、送受信部３１、及び中継部３２を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された中継装置３０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能又は手段である。

次に、中継装置３０の各機能構成について詳細に説明する。なお、以下では、中継装置３０の各機能構成を説明するにあたって、図３に示されている各構成要素のうち、中継装置３０の各機能構成を実現させるための主な構成要素との関係も説明する。

送受信部３１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して各端末、装置又はシステムと各種データ（または情報）の送受信を行う。

中継部３２は、ＣＰＵ５０１からの命令によって実現され、端末１０間でコンテンツデータの中継を行う。

＜＜処理または動作＞＞
続いて、通信システム１を構成する端末１０、認証サーバ４０、及び管理システム５０の処理または動作について説明する。まずは、図９を用いて、一実施形態における認証処理について説明する。図９は、一実施形態における認証処理を示すシーケンス図である。

端末１０にインストールされている任意のクライアントアプリが起動すると（ステップＳ２１）、起動したクライアントアプリに対応する各機能部により以下の処理が開始される。端末１０のクライアントアプリは、ユーザのユーザＩＤ及びユーザパスワードの取得する（ステップＳ２２）。取得方法としては、特に限定されないが、端末１０が、ユーザによるユーザＩＤ及びパスワードの入力を受け付ける方法や、記憶・読出部１９が、記憶部１０００に予め記憶されているユーザＩＤ及びパスワードを読み出す方法等が挙げられる。

端末１０のpubsub送受信部１１は、認証サーバ４０に認証を要求する（ステップＳ２３）。この認証要求には、ユーザの認証要求と、クライアントの認証要求とが含まれる。管理システム５０へ送信される認証要求には、端末１０において取得されたユーザＩＤ及びユーザパスワード、起動したクライアントのクライアントＩＤ及びクライアントパスワード、及びこれから利用するサービスを示すスコープとしてサービスＩＤが含まれている。クライアントＩＤ及びクライアントパスワードは、記憶部１０００に予め記憶されており、記憶・読出部１９によって読み出されたものでも良い。以下、認証要求に含まれるサービスＩＤは、管理システム５０を示す「Ｓ０１」である場合について説明する。

認証サーバ４０の送受信部４１は、端末１０による認証要求を受信する。認証サーバ４０のユーザ認証部４２は、認証要求に含まれるユーザＩＤ及びユーザパスワードの組が、ユーザ管理テーブル（図６（Ａ）参照）で管理されているか否かに基づいてユーザ認証を行う（ステップＳ２４）。認証要求に含まれるユーザＩＤ及びユーザパスワードの組がユーザ管理テーブルで管理されている場合には、ユーザ認証部４２はユーザ認証に成功し、認証要求に含まれるユーザＩＤ及びユーザパスワードの組がユーザ管理テーブルで管理されていない場合には、ユーザ認証部４２はユーザ認証に失敗する。

また、認証サーバ４０のクライアント認証部４３は、認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組が、クライアント管理テーブル（図６（Ｂ）参照）で管理されているか否かに基づいてクライアント認証を行う（ステップＳ２５）。認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組がクライアント管理テーブルで管理されている場合には、クライアント認証部４３はクライアント認証に成功し、認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組がクライアント管理テーブルで管理されていない場合には、クライアント認証部４３はクライアント認証に失敗する。

ユーザ認証、及びクライアント認証の少なくとも一つに失敗した場合、送受信部４１は、認証又は認可に失敗した旨を示すエラーメッセージを要求元の端末１０へ送信する。

ユーザ認証、及びクライアント認証に成功した場合、認証サーバ４０のトークン発行部４５は、認証要求してきた端末１０が管理システム５０にアクセス可能であることを示す認可トークンを発行する（ステップＳ２７）。この認可トークンには、ユーザ名、クライアント名、この認可トークンを利用するサービス名、及びトークンの有効期限などが含まれている。

なお、通信システム１において、認証及び認可は、OAuth 2.0及びOpenID Connect等のプロトコルを用いて実行することもできる。この場合、ユーザＩＤ／ユーザパスワードなどの認証情報の授受の方法、認可トークンに含まれる内容は、OAuth 2.0及びOpenID Connect等の仕様によって規定されることになる。その場合、トークン自体はJWT(JSON Web Token)であっても良い。また、認可トークンがその経路上で改竄されないことを保証するため、トークン発行部４５は、認可トークンに対して秘密鍵を用いて署名しても良い。秘密鍵は、ＲＳＡ（Rivest, Shamir, Adleman）暗号を用いたものでも良い。なお、署名に、ＨＭＡＣ(Hash-based Message Authentication Code)のような公開鍵を用いても良い。認可トークンを利用する管理システム５０では、認可トークンが秘密鍵で署名されているか共有鍵で署名されているかに応じて、公開鍵または共有鍵を用いて署名の確認をする。署名は例えばJWS(JSON Web Signature)といった公知の標準を用いることもできる。認可トークンは必要に応じて、例えば、JWE(JSON Web Encryption)で暗号化される。

送受信部４１は、発行された認可トークンを認証結果に含めて端末１０へ送信する。端末１０のpubsub送受信部１１は、認証サーバによって送信された認可トークンを含む認証結果を受信する。続いて、端末１０のpubsub送受信部１１は受信した認可トークンを管理システム５０へ送信することにより、管理システム５０へログイン要求する（ステップＳ２８）。

管理システム５０の送受信部５１は、端末１０によって送信されたログイン要求を受信する。管理システム５０のトークン確認部５２は、ログイン要求に含まれる認可トークンを確認する（ステップＳ２９）。この場合、トークン確認部５２は、通信システム１で用いられる標準にしたがって、ログイン要求に含まれている認可トークンを解析する。トークン確認部５２は、解析の結果に応じて、認証サーバによる署名が正しいか否かを判断しても良い。認証サーバによる署名が正しいものではないと判断された場合、トークン確認部５２３は、ログイン要求に含まれる認可トークンが改竄されていると判断して、認可に失敗する。

続いて、トークン確認部５２は、認可トークンに含まれている有効期限を確認することで、認可トークンの有効期限が切れているか否かを判断する。認可トークンの有効期限が切れていると判断された場合、トークン確認部５２は、認可トークンの期限切れにより認可に失敗する。

続いて、トークン確認部５２は、認可トークンに自管理システムに対応するサービス名が含まれているか否かを確認する。認可トークンに自管理システムに対応するサービス名が含まれていないと判断された場合、トークン確認部５２は、認可に失敗する。

トークン確認部５２が、認可トークンの署名、有効期限、及びサービスの確認のいずれかの過程で認可に失敗すると、送受信部５１は、端末１０へ認可に失敗した旨を示す認可結果情報を送信する。トークン確認部５２が、認可トークンの署名、有効期限、及びサービスのいずれもが正当なものであると判断した場合、認可トークンに示されているユーザ及びクライアントによるサービスの利用を認可する。ユーザ及びクライアントが認可されると、管理システム５０は、端末１０とのセッションを確立する（ステップＳ３０）。この場合、管理システム５０は、端末１０へ、認可に成功した旨を示す認可結果情報を送信する。

セッションが確立すると管理システム５０では、認可トークンに含まれているクライアントのユーザ名、及びクライアント名、並びにクライアントのＩＰアドレス等を関連付けて記憶部１０００において管理する。これにより、相手側のクライアントが情報を送信する毎に管理システム５０へ、ユーザ名、及びクライアント名を送信しなくても、管理システム５０では、送信元のクライアントのユーザ名、及びクライアント名を把握できるようになる。

上記のステップＳ２１乃至Ｓ３０の処理は、端末１０で起動するクライアントアプリ毎に実行される。例えば、映像通信アプリＡ、映像通信アプリＢ、及び統合通信クライアントは、共通のユーザＩＤ及びユーザパスワードを用いて認証サーバ４０へ認証要求しても良い。管理システム５０が、各クライアントアプリの認証に成功した場合には、管理システム５０及び各クライアントアプリ間でそれぞれ別のセッションが同時に確立することになる。

続いて、図１０及び図１１を用いて端末１０間でクライアントアプリ１０３１による通信を開始する処理について説明する。図１０は、端末１０間の通信の状態を示す概念図である。図１１は、端末間で通信を開始する処理の一例を示すシーケンス図である。以下、複数の端末１０の一例としてユーザａが利用する端末１０ａの映像通信アプリＡ及びユーザｂが利用する端末１０ｂの映像通信アプリＡの間でメッセージをpub及びsubする処理について説明する。以下の説明において、ユーザａのユーザＩＤは「Ｕ０１」、ユーザｂのユーザＩＤは「Ｕ０２」、映像通信アプリＡのクライアントＩＤは「Ｃ０１」である。

端末１０ａのクライアントアプリ「映像通信アプリＡ」は、上記のステップＳ２１乃至Ｓ３０と同様の処理により、pubsub送受信部１１を介して、ユーザＩＤ「Ｕ０１」、クライアントＩＤ「Ｃ０１」を用いて管理システム５０へログインする。端末１０ｂのクライアントアプリ「映像通信アプリＡ」は、上記のステップＳ２１乃至Ｓ３０と同様の処理により、pubsub送受信部１１を介して、ユーザＩＤ「Ｕ０２」、クライアントＩＤ「Ｃ０１」を用いて管理システム５０へログインする。これにより、各端末（１０ａ，１０ｂ）と管理システム５０との間でpubsubによるメッセージ送信用のセッションｓｅｉが確立する。

端末１０ａの映像通信アプリＡにより実現されるセッション制御部１７ａは、pubsub送受信部１１を介して、端末１０ａ側の映像通信アプリＡ、及び端末１０ｂ側の映像通信アプリＡがトピック名"ConfRoom1"のメッセージを受け取るためのsub要求を管理システム５０へ送信する（ステップＳ４１）。sub要求には、端末１０ａ側のユーザＩＤ「Ｕ０１」及びクライアントＩＤ「Ｃ０１」、端末１０ｂ側のユーザＩＤ「Ｕ０２」及びクライアントＩＤ「Ｃ０１」、並びにトピック名"ConfRoom1"が含まれている。トピック名"ConfRoom1"で識別されるトピックには、各端末（１０ａ，１０ｂ）の映像通信アプリＡ間の呼制御用のメッセージが含まれる。

管理システム５０の送受信部５１は、端末１０ａの映像通信アプリＡによって送信されたsub要求を受信する。管理システム５０のpubsub処理部５４は、sub要求に含まれているトピック名、ユーザＩＤ、及びクライアントＩＤをトピック管理テーブルに関連付けて登録する（ステップＳ４２）。これにより、端末１０ａの映像通信アプリＡ、及び端末１０ｂの映像通信アプリＡは、それぞれ、トピック名"ConfRoom1"に関連付けられるメッセージを受信可能となる。

続いて、端末１０ａにおいてユーザａによるユーザｂとの通話の開始要求が受け付けられた場合の処理について説明する。端末１０ａのセッション制御部１７ａは、pubsub送受信部１１を介して、ユーザａの映像通信アプリＡが通信の開始要求する旨のメッセージ"Invite U01"をトピック名"ConfRoom1"で管理システム５０へpub要求する（ステップＳ４３）。

管理システム５０の送受信部５１は、上記のpub要求を受信する。続いて、pubsub処理部５４は、pub要求に含まれているトピック名"ConfRoom1"を検索キーとして、トピック管理テーブル（図６（Ｄ））を検索して、対応するクライアントＩＤ及びユーザＩＤの組「Ｃ０１，Ｕ０２」を抽出することによりメッセージの送信先を特定する（ステップＳ４４）。ここで、pubsub処理部５４は、送信先の一つとして、クライアントＩＤ及びユーザＩＤの組「Ｃ０１，Ｕ０２」を用いて管理システム５０へログインした端末１０ｂの映像通信アプリＡを特定する。

管理システム５０のpubsub処理部５４は、特定結果に基づいて端末１０ａの映像通信アプリＡから送られてきたメッセージ及びトピック名を端末１０ｂの映像通信アプリＡへ送信する（ステップＳ４５）。端末１０ｂの映像通信アプリＡにより実現されるセッション制御部１７ａは、pubsub送受信部１１を介して管理システム５０から送られてきたメッセージを受信する。

続いて、端末１０ｂにおいてユーザｂによるユーザａとの通話の開始の許可が受け付けられた場合の処理について説明する。端末１０ｂのセッション制御部１７ａは、pubsub送受信部１１を介して、ユーザｂの映像通信アプリＡが通信の開始を許可する旨のメッセージ"Accept U02"をトピック名"ConfRoom1"で管理システム５０へpub要求する（ステップＳ４６）。

管理システム５０の送受信部５１は、上記のトピック名"ConfRoom1"に関連付けられるメッセージのpub要求を受信する。続いて、pubsub処理部５４は、ステップＳ４４と同様の処理により、メッセージの送信先の一つとして、クライアントＩＤ及びユーザＩＤの組「Ｃ０１，Ｕ０１」を用いて管理システム５０へログインした端末１０ａの映像通信アプリＡを特定する（ステップＳ４７）。

管理システム５０のpubsub処理部５４は、特定結果に基づいて端末１０ｂの映像通信アプリＡから送られてきたメッセージ及びトピック名を端末１０ａの映像通信アプリＡへ送信する（ステップＳ４８）。端末１０ａのセッション制御部１７ａは、pubsub送受信部１１を介して管理システム５０から送られてきたメッセージを受信する。

続いて、端末１０ａの映像通信アプリＡによって実現されるコンテンツ送受信部１６ａは、端末１０ｂに対して発信する。発信する方法は特に限定されないが、例えば、ユーザＩＤが電話番号やＩＰアドレスのような機器を特定するための宛先情報に対応付けられている場合には、ユーザＩＤ「Ｕ０２」に対応付けられる宛先に発信しても良い。端末１０ｂの映像通信アプリＡによって実現されるコンテンツ送受信部１６ａが着信すると、端末１０ａの映像通信アプリＡ及び端末１０ｂの映像通信アプリＡ間のセッションｓｅｄは確立する。これにより、端末１０ａの映像通信アプリＡ及び端末１０ｂの映像通信アプリＡ間で画像データや映像データ、音データ等のコンテンツデータを確立されたセッションｓｅｄを用いて送信することが可能となる。

続いて、図１２及び図１３を用いて端末１０間でクライアントアプリ１０３２による通信を開始する処理について説明する。図１２は、端末１０間の通信の状態を示す概念図である。図１３は、端末間で通信を開始する処理の一例を示すシーケンス図である。以下、複数の端末１０の一例としてユーザａが利用する端末１０ａの映像通信アプリＢ及びユーザｃが利用する端末１０ｃの映像通信アプリＢの間で通信を開始する処理について説明する。以下の説明において、ユーザａのユーザＩＤは「Ｕ０１」、ユーザｃのユーザＩＤは「Ｕ０３」、映像通信アプリＢのクライアントＩＤは「Ｃ０２」である。また、中継装置管理用アプリのユーザのユーザＩＤは「Ｕ０４」、中継装置管理用アプリのクライアントＩＤは「Ｃ０３」である。

端末１０ａのクライアントアプリ「映像通信アプリＢ」は、上記のステップＳ２１乃至Ｓ３０と同様の処理により、pubsub送受信部１１を介して、ユーザＩＤ「Ｕ０１」、クライアントＩＤ「Ｃ０２」を用いて管理システム５０へログインする。端末１０ｃのクライアントアプリ「映像通信アプリＢ」は、上記のステップＳ２１乃至Ｓ３０と同様の処理により、pubsub送受信部１１を介して、ユーザＩＤ「Ｕ０３」、クライアントＩＤ「Ｃ０２」を用いて管理システム５０へログインする。中継装置管理サーバ２０のクライアントアプリ「中継装置管理用アプリ」は、上記のステップＳ２１乃至Ｓ３０と同様の処理により、pubsub送受信部２１を介して、ユーザＩＤ「Ｕ０４」、クライアントＩＤ「Ｃ０３」を用いて管理システム５０へログインする。これにより、各端末（１０ａ，１０ｂ）及び中継装置管理サーバ２０と管理システム５０との間でpubsub用のメッセージを送信するためのセッションｓｅｉが確立する。なお、端末１０ａは、映像通信アプリＡがユーザＩＤ「Ｕ０１」、クライアントＩＤ「Ｃ０１」を用いて管理システム５０へログインしたときとは、別セッションにより管理システム５０と接続する。

端末１０ａの映像通信アプリＢにより実現されるセッション制御部１７ｂは、pubsub送受信部１１を介して、端末１０ａ側の映像通信アプリＢ、端末１０ｃ側の映像通信アプリＢ、及び中継装置管理サーバ２０側の中継装置管理用アプリがトピック名"ConfRoom2"に関連付けられるメッセージを受け取るためのsub要求を管理システム５０へ送信する（ステップＳ６１）。sub要求には、端末１０ａ側のユーザＩＤ「Ｕ０１」及びクライアントＩＤ「Ｃ０２」、端末１０ｃ側のユーザＩＤ「Ｕ０３」及びクライアントＩＤ「Ｃ０２」、中継装置管理サーバ２０側のユーザＩＤ「Ｕ０４」及びクライアントＩＤ「Ｃ０３」、並びにトピック名"ConfRoom2"が含まれている。トピック名"ConfRoom2"で識別されるトピックには、各端末（１０ａ，１０ｃ）の映像通信アプリＢ間の呼制御用のメッセージが含まれる。

管理システム５０の送受信部５１は、端末１０ａの映像通信アプリＢによって送信されたsub要求を受信する。管理システム５０のpubsub処理部５４は、sub要求に含まれているトピック名、ユーザＩＤ、及びクライアントＩＤをトピック管理テーブルに関連付けて登録する（ステップＳ４３）。これにより、端末１０ａの映像通信アプリＢ、端末１０ｃの映像通信アプリＢ、及び中継装置管理サーバ２０の中継装置管理用アプリは、それぞれ、トピック名"ConfRoom2"に関連付けられるメッセージを受信可能となる。

続いて、端末１０ａにおいてユーザａによるユーザｃとの通話の開始要求が受け付けられた場合の処理について説明する。端末１０ａのセッション制御部１７ｂは、pubsub送受信部１１を介して、ユーザａにより利用されている映像通信アプリＢが通信の開始要求する旨、及び仮想の会議室に入室する旨のメッセージ"Enter/Invite U01"をトピック名"ConfRoom2"で管理システム５０へpub要求する（ステップＳ６３）。

管理システム５０の送受信部５１は、上記のpub要求を受信する。続いて、pubsub処理部５４は、pub要求に含まれているトピック名"ConfRoom2"を検索キーとして、トピック管理テーブル（図６（Ｄ））を検索して、対応するクライアントＩＤ及びユーザＩＤの組（「Ｃ０２，Ｕ０３」「Ｃ０３，Ｕ０４」）を抽出することによりメッセージの送信先を特定する（ステップＳ４４）。ここで、pubsub処理部５４は、送信先の一つとして、クライアントＩＤ及びユーザＩＤの組「Ｃ０２，Ｕ０３」を用いて管理システム５０へログインした、端末１０ｃの映像通信アプリＢを特定する。また、pubsub処理部５４は、送信先の一つとして、クライアントＩＤ及びユーザＩＤの組「Ｃ０３，Ｕ０４」を用いて管理システム５０へログインした、中継装置管理サーバ２０の中継装置管理用アプリを特定する（ステップＳ６４）。

管理システム５０のpubsub処理部５４は、特定結果に基づいて端末１０ａの映像通信アプリＢから送られてきたメッセージ及びトピック名を端末１０ｃの映像通信アプリＢ及び中継装置管理サーバ２０の中継装置管理用アプリへ送信する（ステップＳ６５−１，Ｓ６５−２）。端末１０ｃの映像通信アプリＢにより実現されるセッション制御部１７ｂは、pubsub送受信部１１を介して管理システム５０から送られてきたメッセージを受信する。中継装置管理サーバ２０のpubsub送受信部２１は、管理システム５０から送られてきたメッセージを受信する。

中継装置管理サーバ２０の中継指示部２２は、会議室管理テーブル（図８（Ａ））のトピック名のフィールドを参照して、空きレコードを選択する。例えば、会議室管理テーブルにおける会議室ＩＤ「ＲｏｏｍＡ」に対応付けられるレコードが空きレコードである場合、中継指示部２２は、その空きレコードに受信したメッセージに含まれるトピック名"ConfRoom2"を登録する（ステップＳ６６）。ステップＳ６６の処理の一環として、中継装置管理サーバ２０の中継指示部２２は、メッセージの送信元の端末１０ａ側のクライアントＩＤとユーザＩＤの組「Ｃ０２，Ｕ０１」を中継装置利用管理テーブルに登録する。

中継装置管理サーバ２０の中継指示部２２は、ステップＳ６６で選択されたレコードに対応する会議室ＩＤ「ＲｏｏｍＡ」、及びメッセージの送信元の端末１０ａ側のクライアントＩＤとユーザＩＤの組「Ｃ０２,Ｕ０１」を会議情報として中継装置３０へ送信する（ステップＳ６７）。中継装置３０の送受信部３１は、中継装置管理サーバ２０によって送信された会議情報を受信する。

中継装置３０の送受信部３１は、クライアントＩＤとユーザＩＤの組「Ｃ０２,Ｕ０１」により特定される端末１０ａの映像通信アプリＢへ、会議室ＩＤ「ＲｏｏｍＡ」を送信する。また、中継装置３０は、端末１０ａの映像通信アプリＢと中継装置３０の会議室ＩＤ「ＲｏｏｍＡ」で示されるチャネルとの間のコンテンツデータの送受信の開始を要求する（ステップＳ６８）。これにより、端末１０ａの映像通信アプリＢと中継装置３０との間でコンテンツデータを送信するためのセッションｓｅｄが確立する。

続いて、端末１０ｃにおいてユーザｃによるユーザａとの通話の開始の許可が受け付けられた場合の処理について説明する。端末１０ｃのセッション制御部１７ｂは、pubsub送受信部１１を介して、ユーザｃによって利用されている映像通信アプリＢが会議に参加する旨のメッセージ"Enter U02"をトピック名"ConfRoom2"で管理システム５０へpub要求する（ステップＳ６９）。

管理システム５０の送受信部５１は、上記のトピック名"ConfRoom2"に関連付けられるメッセージのpub要求を受信する。続いて、pubsub処理部５４は、ステップＳ６４と同様の処理により、メッセージの送信先の一つとして、クライアントＩＤ及びユーザＩＤの組「Ｃ０２，Ｕ０１」を用いて管理システム５０へログインした端末１０ａの映像通信アプリＡを特定する（ステップＳ７０）。また、pubsub処理部５４は、ステップＳ６４と同様の処理により、メッセージの送信先の一つとして、クライアントＩＤ及びユーザＩＤの組「Ｃ０３，Ｕ０４」を用いて管理システム５０へログインした、中継装置管理サーバ２０の中継装置管理用アプリを特定する（ステップＳ７０）。

管理システム５０のpubsub処理部５４は、特定結果に基づいて端末１０ｃの映像通信アプリＢから送られてきたメッセージ及びトピック名を端末１０ａの映像通信アプリＢ及び中継装置管理サーバ２０の中継装置管理用アプリへ送信する（ステップＳ７１−１，Ｓ７１−２）。端末１０ａの映像通信アプリＢにより実現されるセッション制御部１７ｂは、pubsub送受信部１１を介して管理システム５０から送られてきたメッセージを受信する。中継装置管理サーバ２０のpubsub送受信部２１は、管理システム５０から送られてきたメッセージを受信する。

中継装置管理サーバ２０の中継指示部２２は、メッセージの送信元の端末１０ｃ側のクライアントＩＤとユーザＩＤの組「Ｃ０２,Ｕ０３」を中継装置利用管理テーブルに登録する（ステップＳ７２）。

中継装置管理サーバ２０の中継指示部２２は、会議室管理テーブル（図８（Ａ）参照）においてトピック名"ConfRoom2"に対応する会議室ＩＤ「ＲｏｏｍＡ」、及びメッセージの送信元の端末１０ｃ側のクライアントＩＤとユーザＩＤの組「Ｃ０２,Ｕ０３」を会議情報として中継装置３０へ送信する（ステップＳ７３）。中継装置３０の送受信部３１は、中継装置管理サーバによって送信された会議情報を受信する。

中継装置３０の送受信部３１は、クライアントＩＤとユーザＩＤの組「Ｃ０２,Ｕ０３」によって特定される端末１０ｃの映像通信アプリＢへ、会議室ＩＤ「ＲｏｏｍＡ」を送信する。また、中継装置３０は、端末１０ｃの映像通信アプリＢと中継装置３０の会議室ＩＤ「ＲｏｏｍＡ」で示されるチャネルとの間でのコンテンツデータの送受信の開始を要求する（ステップＳ７４）。これにより、端末１０ｃの映像通信アプリＢと中継装置３０との間でコンテンツデータを送信するためのセッションｓｅｄが確立する。

端末１０ａと中継装置３０との間のセッションｓｅｄ、及び端末１０ｃと中継装置３０との間のセッションｓｅｄがそれぞれ確立すると、中継部３２は、一方の端末（１０ａ，１０ｃ）から送られてきた画像データ、映像データ、音データ等のコンテンツデータを他方の端末（１０ｃ，１０ａ）へ送信する。これにより、端末（１０ａ，１０ｃ）で通話を開始することができる。

続いて、図１４を用いて端末１０の各クライアントによる通信の状態を管理する処理について説明する。図１４は、端末の通信の状態を管理する処理の一例を示したシーケンス図である。以下の説明において、ユーザａのユーザＩＤは「Ｕ０１」、ユーザｂのユーザＩＤは「Ｕ０２」、ユーザｃのユーザＩＤは「Ｕ０３」、統合通信クライアントのクライアントＩＤは「Ｃ０４」である。

端末１０ａの各クライアントアプリ「映像通信アプリ（Ａ，Ｂ）」は、上記のステップＳ２１乃至Ｓ３０と同様の処理により、pubsub送受信部１１を介して、ユーザＩＤ「Ｕ０１」、クライアントＩＤ「Ｃ０１又はＣ０２」を用いて管理システム５０へログインする。端末（１０ａ，１０ｂ，１０ｃ）の各統合通信クライアントは、上記のステップＳ２１乃至Ｓ３０と同様の処理により、pubsub送受信部１１を介して、ユーザＩＤ「Ｕ０１，Ｕ０２，又はＵ０３」、クライアントＩＤ「Ｃ０４」を用いて管理システム５０へログインする。

端末１０ｂのpubsub送受信部１１は、トピック名"Client1/Presence"に関連付けられるメッセージを受け取るためのsub要求を管理システム５０へ送信する（ステップＳ８１−１）。sub要求には、要求元の端末１０ｂ側のユーザＩＤ「Ｕ０２」及びクライアントＩＤ「Ｃ０４」、並びにトピック名"Client1/Presence"が含まれている。トピック名"Client1/Presence"で識別されるトピックには、各端末１０ａの通信の状態を示すプレゼンス情報が含まれる。

また、端末１０ｃのpubsub送受信部１１は、トピック名"Client1/Presence"に関連付けられるメッセージを受け取るためのsub要求を管理システム５０へ送信する（ステップＳ８１−２）。sub要求には、要求元の端末１０ｃ側のユーザＩＤ「Ｕ０３」及びクライアントＩＤ「Ｃ０４」、並びにトピック名"Client1/Presence"が含まれている。

管理システム５０の送受信部５１は、各端末（１０ｂ，１０ｃ）の統合通信クライアントによって送信されたsub要求を受信する。管理システム５０のpubsub処理部５４は、sub要求に含まれているトピック名、ユーザＩＤ、及びクライアントＩＤをトピック管理テーブルに関連付けて登録する（ステップＳ８２）。これにより、各端末（１０ｂ，１０ｃ）の統合通信クライアントは、それぞれ、トピック名"Client1/Presence"に関連付けられるメッセージを受信可能となる。

一方、端末１０ａでは、映像通信アプリＡにより実現されるセッション制御部１７ａ、及び映像通信アプリＢにより実現されるセッション制御部１７ｂが、pubsub送受信部１１を介して、呼制御用のメッセージを送信又は受信する度に、メッセージに応じた制御を実行する。この制御には、特に限定されないが、発信のメッセージの送信に応じて発信音を鳴らす制御、発信のメッセージの受信に応じて着信音を鳴らす制御、通信の許可の応答の受信に応じて通信を確立するための制御等が挙げられる。そして、この制御に応じた自アプリによる通信の状態を示すプレゼンス情報をプレゼンス受信部１３へ送信する。例えば、映像通信アプリＡによる実現するセッション制御部１７ａは、呼制御用のメッセージに従って通信を確立する制御を行うと、制御によって変更された後の通信の状態を示すプレゼンス情報「会議中」をプレゼンス受信部１３へ送信する（ステップＳ８３）。

プレゼンス受信部１３がプレゼンス情報を受信すると、プレゼンス管理部１２はプレゼンス情報の送信元のクライアントアプリ（映像通信アプリＡ）のクライアントＩＤ、映像通信アプリＡのユーザのユーザＩＤと、送られてきたプレゼンス情報を関連付けて、記憶部１０００に記憶することにより映像通信アプリＡのプレゼンスを管理する（ステップＳ８４）。

なお、プレゼンス管理部１２は、クライアントアプリの機能に応じてクライアントアプリの通信の状態を管理しても良い。例えば、クライアントアプリが３拠点間の通信に対応したものであれば、プレゼンス受信部１３が一回目の「会議中」を示すプレゼンス情報を受信したとき、プレゼンス管理部１２は、クライアントアプリの状態を示すプレゼンス情報として「会議中（会議参加可能）」を管理する。そして、プレゼンス受信部１３が二回目の「会議中」を示すプレゼンス情報を受信したとき、プレゼンス管理部１２は、クライアントアプリの状態を示すプレゼンス情報として「会議中（会議参加不可能）」を管理しても良い。

また、プレゼンス管理部１２は、自端末１０の実装に応じてプレゼンス情報の送信元とは異なるクライアントの通信の状態を管理する。例えば、映像通信アプリＡ、映像通信アプリＢはそれぞれ１つのマイクを占有可能である場合について説明する。映像通信アプリＡによって実現されるセッション制御部１７ａから「会議中」を示すプレゼンス情報がプレゼンス受信部１３へ送信されたとき、端末１０に内蔵されているマイク１１４は、映像通信アプリＡの通信によって占有される。プレゼンス管理部１２は、外部機器接続Ｉ／Ｆに外付けのマイクが接続されているか否かを判断する。ここで接続されていると判断されれば、プレゼンス管理部１２は、映像通信アプリＢのクライアントＩＤ「Ｃ０２」、ユーザＩＤ「Ｕ０１」、及び会議開始可能な状態を示すプレゼンス情報「待機中」を記憶部１０００に記憶して管理する。一方、外部機器接続Ｉ／Ｆ１１８に外付けのマイクが接続されていないと判断された場合には、プレゼンス管理部１２は、映像通信アプリＢのクライアントＩＤ「Ｃ０２」、ユーザＩＤ「Ｕ０１」、及び会議開始不可能であることを示すプレゼンス情報「利用不可」を記憶部１０００に記憶して管理する。

プレゼンス管理部１２によって新たなプレゼンス情報が管理される度、あるいは所定のタイミングで、端末１０ａのpubsub送受信部１１は、記憶部１０００において管理されているクライアントＩＤ、ユーザＩＤ、及びプレゼンス情報の組をトピック名"Client1/Presence"としてPubする要求を管理システム５０へ送信する（ステップＳ８５）

管理システム５０の送受信部５１は、上記のpub要求を受信する。続いて、pubsub処理部５４は、pub要求に含まれているトピック名"Client1/Presence"を検索キーとして、トピック管理テーブル（図６（Ｄ））を検索して、対応するクライアントＩＤ及びユーザＩＤの組（「Ｃ０４，Ｕ０２」「Ｃ０４，Ｕ０３」）を抽出することによりメッセージの送信先を特定する（ステップＳ８６）。ここで、pubsub処理部５４は、送信先として、クライアントＩＤ及びユーザＩＤの組「Ｃ０４，Ｕ０２」を用いて管理システム５０へログインした、端末１０ｂの統合通信クライアント、及びクライアントＩＤ及びユーザＩＤの組「Ｃ０４，Ｕ０３」を用いて管理システム５０へログインした端末１０ｃの統合通信クライアントを特定する。

管理システム５０のpubsub処理部５４は、特定結果に基づいて端末１０ａの統合通信クライアントから送られてきたメッセージ及びトピック名を端末１０ｂの統合通信クライアント及び端末１０ｃの統合通信クライアントへ送信する（ステップＳ８７−１，Ｓ８７−２）。端末（１０ｂ，１０ｃ）のpubsub送受信部１１は管理システム５０から送られてきたメッセージを受信する。これにより、端末（１０ｂ，１０ｃ）では、端末１０ａの通信の状態をクライアントアプリ毎に把握することが可能となる。

上記では映像通信アプリＡにより実現されるセッション制御部１７ａが呼制御に係るメッセージを送信又は受信して、映像通信アプリＡによる通信を制御するときのプレゼンス管理について説明した。映像通信アプリＢにより実現されるセッション制御部１７ｂが呼制御に係るメッセージを送信又は受信して、映像通信アプリＢによる通信を制御するときのプレゼンス管理は、上記ステップＳ８３乃至Ｓ８７−１，Ｓ８７−２の処理と同様であるので説明を省略する（ステップＳ８８乃至Ｓ９２−１，Ｓ９２−２）。

＜＜実施形態の変形例＞＞
続いて、上記実施形態の変形例について、上記実施形態とは異なる点を説明する。
図１５は、実施形態の変形例における端末１０の機能ブロック図である。

（デバイス管理テーブル）
表１は、デバイス管理テーブルを示す概念図である。記憶部１０００には、デバイス管理テーブルによってデバイス管理ＤＢ１００１が構築される。デバイス管理テーブルには、端末１０に内蔵又は外付けされているデバイスのデバイス名と、このデバイスの総数と、デバイスのうちクライアントアプリによって利用されていないデバイスの残数と、が関連付けられて管理されている。

図１６は、端末１０のプレゼンス管理部１２が管理するステートマシンの一例を示す図である。端末１０のプレゼンス管理部１２は、ＣＰＵ１０１からの命令により、図１６に示されているようなステートマシンを管理する。プレゼンス管理部１２は、端末１０で起動するクライアントアプリ毎に、クライアントアプリに対応したステートマシンを管理する。なお、図１６は、映像通信アプリＡに対応するステートマシンである。図１６に示されるステートマシンでは、開始状態から終了状態へ矢印で接続されている。矢印の近傍には、状態遷移の契機となるイベントが記載されている。また、一部のイベントには、スラッシュを挟んでこのイベントにより新たに発生するイベントが記載されている。

端末１０のデバイス管理部１４は、統合クライアントアプリ１０３０に従ったＣＰＵ１０１からの命令によって実現され、端末１０に内蔵又は外付けされているデバイスの数を管理する。

端末１０の通知部１８はＯＳ１０２０に従ったＣＰＵ１０１からの命令によって実現され、ＯＳ１０２０のＰｎＰ(Plug and Play)機能によりデバイスの接続又は接続解除を認識すると、デバイスの接続又は接続解除を示すＰｎＰイベントを統合クライアントアプリ１０３へ通知する。

図１７は、端末１０に内蔵又は外付けされているデバイスの総数を管理する処理を示すシーケンス図である。

端末１０の通知部１８は、端末１０に内蔵のデバイスの接続を認識すると、或いは、外付けのデバイスの接続又は接続解除を認識すると、認識した内容に応じて、デバイスの接続、又は接続解除を示すＰｎＰイベントを統合クライアントアプリ１０３０へ通知する（ステップＳ１０１）。ここで対象となるデバイスは、クライアントアプリとしての映像通信アプリＡ，Ｂが利用可能なデバイスである。例えば、通知部１８は、端末１０の内蔵のカメラ１１２の接続を認識すると、カメラの接続を示すＰｎＰイベントを統合クライアントアプリ１０３０へ送信する。また、通知部１８は、外付けカメラの接続又は接続解除を認識すると、カメラの接続又は接続解除を示すＰｎＰイベントを統合クライアントアプリ１０３０へ送信する。

統合クライアントアプリ１０３０側では、デバイス管理部１４がＰｎＰイベントを受信する。デバイス管理部１４は、ＰｎＰイベントの内容に応じて、自端末に接続しているデバイス数を管理する（ステップＳ１０２）。例えば、デバイス管理部１４は、カメラの接続を示すＰｎＰイベントを受信すると、デバイス管理テーブルにおいてカメラに関連付けられているデバイスの総数及び残数を１つ増やす。また、デバイス管理部１４は、カメラの接続解除を示すＰｎＰイベントを受信すると、デバイス管理テーブルにおいてカメラに関連付けられているデバイスの総数及び残数を１つ減らす。

図１８を用いて、プレゼンス管理部１２が各クライアントアプリのプレゼンス情報を管理する処理について説明する。図１８は、プレゼンスを管理する処理を示すフロー図である。この処理を開始する段階で、映像通信アプリＡ，Ｂのプレゼンス情報が「待機中」である旨、記憶部１０００において管理されているものとする。また、デバイス管理テーブルは表１に示す状態であるものとする。

以下、一例として、ステップＳ８３で端末１０ａの映像通信アプリＡから統合通信クライアントへプレゼンス情報「会議中」が送信されたときにステップＳ８４で実行される各処理について説明する。

端末１０ａのプレゼンス受信部１３は、映像通信アプリＡから送信されるプレゼンス情報「会議中」を受信する。これにより、映像通信アプリＡが「会議中」である旨のイベントが発生する。

プレゼンス管理部１２は、各クライアントアプリに対応するステートマシンに従い、イベントに対応する処理を実行する（ステップＳＡ）。ここで、映像通信アプリＡが「会議中」である旨のイベントが発生しているので、プレゼンス管理部１２は、映像通信アプリＡに対応するステートマシンに従って、記憶部１０００において管理されている映像通信アプリＡのプレゼンス情報を「待機中」から「会議中」へ変更する。また、プレゼンス管理部１２は、映像通信アプリＡに対応するステートマシンに従って、デバイス管理テーブルにおいて管理されるカメラの残数を「１」から「０」に変更する。この段階で、映像通信アプリＡは、残数が変更されたデバイス、すなわち、カメラ１１２の利用を開始する。

この処理により、カメラ残数が「１」から「０」への変更される旨の新たなイベントがエンキューされる。映像通信アプリＡが「会議中」である旨のイベントに対応する処理により、カメラ残数が「１」から「０」への変更される旨のイベントが発生するため、ステップＳＢでプレゼンス管理部１２は、イベントキューが空ではない旨、判断する（ステップＳＢのＮＯ）。

ステップＳＢでＮＯと判断されると、プレゼンス管理部１２は、カメラ残数が「１」から「０」への変更される旨のイベントをデキューする（ステップＳＣ）。

プレゼンス管理部１２は、ステップＳＡに戻って、各クライアントアプリに対応するステートマシンに従い、新たなイベントに対応する処理を実行する。ここで、映像通信アプリＡにより、カメラ残数が「１」から「０」への変更される旨のイベントが発生しているので、プレゼンス管理部１２は、映像通信アプリＢに対応するステートマシンに従って、記憶部１０００において管理されている映像通信アプリＢのプレゼンス情報を「待機中」から「利用不可」へ変更する。

これにより、イベントキューは空きになるので、プレゼンス管理部１２は、ステップＳＢでＹＥＳと判断して、処理を終了する。以後、クライアントアプリ毎のプレゼンス情報を他の端末１０へ送信する処理は、ステップＳ８５乃至Ｓ８７−１，Ｓ８７−２の処理と同様であるので説明を省略する。

なお、図１８に示される処理は、ステートマシンに示されているいずれかのイベントが発生する度に実行される。このイベントには、ステップＳ８８における映像通信アプリＢから統合クライアントへのプレゼンス情報の送信や、ステップＳ１０１におけるＰｎＰイベントの発生等が挙げられる。

＜＜本実施形態の主な効果＞＞
続いて、上記の実施形態の主な効果を説明する。上記実施形態の出力方法によると、端末１０のプレゼンス管理部１２は、映像通信アプリＡ（一方の通信用のアプリケーションの一例）による呼制御用のメッセージ（呼制御のための情報の一例）の送信に応じて、映像通信アプリＡ側のプレゼンス情報（一方の状態の一例）を記憶部１０００において管理する。また、端末１０のプレゼンス管理部１２は、このプレゼンスのときに、映像通信アプリＡにより利用されるデバイス（リソースの一例）に応じて、映像通信アプリＢ（他方の通信用のアプリケーションの一例）側のプレゼンス情報（他方の状態の一例）を記憶部１０００において管理する。端末１０のpubsub送受信部１１（出力手段の一例）は、記憶部１０００において管理される映像通信アプリＡ，Ｂ側のプレゼンス情報（状態情報の一例）を管理システム５０へ送信することにより出力する。これにより、端末１０では、実装するリソースに応じて、各クライアントアプリの状態を出力することができる。

端末１０のデバイス管理ＤＢ１００１（リソース管理手段の一例）は、映像通信アプリＡ，Ｂによって利用可能なデバイスの残数を管理する。端末１０のpubsub送受信部１１は、デバイス管理ＤＢ１００１において管理されているデバイスの残数に基づいて、映像通信アプリＢ側のプレゼンス情報を送信する。これにより、端末１０は、デバイスが複数ある場合に、利用可能なデバイスの残数に応じて、プレゼンス情報を出力することができる。

端末１０のデバイス管理部１４（更新手段の一例）は、デバイスの接続、又は接続解除（リソースの追加又は削除の一例）、若しくは、デバイスの利用の開始又は停止に応じて、デバイス管理ＤＢ１００１において管理される利用可能なデバイスの残数を更新する。これにより、端末１０のデバイス管理ＤＢ１００１では、動的にデバイスの残数を管理することができる。

端末１０のpubsub送受信部１１（送信手段の一例）は、パブリッシュサブスクライブサーバとしての管理システム５０へ、映像通信アプリＡ，Ｂごとに、呼制御用のメッセージのpub要求、及びsub要求を送信する。これにより、端末１０の統合クライアントは、各クライアントにより送受信される呼制御用のメッセージを統合して管理できるので、各映像通信アプリＡ，Ｂ側のプレゼンス情報を正確に出力できるようになる。

端末１０のpubsub送受信部１１は、管理システム５０へ、プレゼンス情報のpub要求及びsub要求を送信する。これにより、端末１０は、管理システム５０と接続する通信先の端末１０へ各プレゼンス情報を送信することができるとともに、相手側のプレゼンス情報を取得できるようになる。

端末１０のpubsub送受信部１１は、共通のユーザＩＤ（アカウントの一例）により管理システム５０へpub要求又はsub要求を送信する。これにより、端末１０は、各クライアントアプリによる通信を、１対１の通信と同様に管理することが可能となる。

通信システム１は、各端末１０間のコンテンツデータの中継を管理する中継装置管理サーバ２０（中継管理装置の一例）を更に備えている。中継装置管理サーバ２０は、映像通信アプリＢによる呼制御用のメッセージのsub要求を管理システム５０へ送信する。これにより、中継装置管理サーバ２０は、端末１０間で送信される呼制御用のメッセージを取得できるようになるので、取得された呼制御用のメッセージに基づいて、中継装置３０へ中継開始の指示を送信できるようになる。

＜＜実施形態の補足＞＞
端末１０、中継装置管理サーバ２０、中継装置３０、認証サーバ４０、及び管理システム５０用の各プログラムは、インストール可能な形式又は実行可能な形式のファイルによって、コンピュータで読み取り可能な記録媒体（記録メディア１０６等）に記録されて流通されるようにしてもよい。また、上記記録媒体の他の例として、ＣＤ−Ｒ(Compact Disc Recordable)、ＤＶＤ(Digital Versatile Disk)、ブルーレイディスク等が挙げられる。

また、上記実施形態の各プログラムが記憶されたＣＤ−ＲＯＭ等の記録媒体、並びに、これらプログラムが記憶されたＨＤ５０４は、プログラム製品(Program Product)として、国内又は国外へ提供されることができる。

また、上記実施形態における端末１０、中継装置管理サーバ２０、中継装置３０、認証サーバ４０、及び管理システム５０は、単一のコンピュータによって構築されてもよいし、各部（機能又は手段）を分割して任意に割り当てられた複数のコンピュータによって構築されていてもよい。また、認証サーバ４０及び管理システム５０は、単一のコンピュータによって構築されていても良い。

上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路を含むプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC(Application Specific Integrated Circuit)や従来の回路モジュール等のデバイスを含むものとする。

１ 通信システム
２ 通信ネットワーク
１０ 端末
１１ pubsub送受信部
１２ プレゼンス管理部
１３ プレゼンス受信部
１４ デバイス管理部
１６ａ，１６ｂ コンテンツ送受信部
１７ａ，１７ｂ セッション制御部
１８ 通知部
２０ 中継装置管理サーバ
２１ pubsub送受信部
２２ 中継指示部
２９ 記憶・読出部
３０ 中継装置
３１ 送受信部
３２ 中継部
４０ 認証サーバ
４１ 送受信部
４２ ユーザ認証部
４３ クライアント認証部
４５ トークン発行部
４９ 記憶・読出部
５０ 管理システム
５１ 送受信部
５２ トークン確認部
５４ pubsub処理部
５９ 記憶・読出部
１０００ 記憶部
１００１ デバイス管理ＤＢ
２００１ 会議室管理ＤＢ
２００２ 中継装置利用管理ＤＢ
４０００ 記憶部
４００１ ユーザ管理ＤＢ
４００２ クライアント管理ＤＢ
４００３ サービス管理ＤＢ
５０００ 記憶部
５００１ トピック管理ＤＢ

特開２００６−１７４１９３号公報

Claims (11)

1. 複数の通信用のアプリケーションが起動する通信端末であって、
   前記複数の通信用のアプリケーションのうち、一方の通信用のアプリケーションによる呼制御のための情報の送信に応じて、前記情報に対応する一方の状態を示す状態情報を出力し、前記一方の状態で利用されるリソースに応じて、前記複数の通信用のアプリケーションのうち他方の通信用のアプリケーションにかかる他方の状態を示す状態情報を出力する出力手段
   を有する通信端末。
2. 利用可能なリソースの数を管理するリソース管理手段を有しており、
   前記出力手段は、前記リソース管理手段において管理されている前記利用可能なリソースの数に応じて前記他方の状態を示す状態情報を出力する請求項１に記載の通信端末。
3. 前記リソースの追加又は削除、若しくは、前記リソースの利用の開始又は停止に応じて、前記リソース管理手段において管理される前記利用可能なリソースの数を更新する更新手段を有する請求項２に記載の通信端末。
4. 前記複数の通信用のアプリケーションごとに、前記呼制御のための情報をパブリッシュする要求、及び前記呼制御のための情報をサブスクライブする要求をパブリッシュサブスクライブサーバへ送信する送信手段を有する請求項１乃至３のいずれか一項に記載の通信端末。
5. 前記送信手段は、前記状態情報をパブリッシュする要求、及び前記状態情報をサブスクライブする要求を前記パブリッシュサブスクライブサーバへ送信する請求項４に記載の通信端末。
6. 前記送信手段は、共通のアカウントにより前記パブリッシュサブスクライブサーバへ、それぞれの前記要求を送信する請求項５に記載の通信端末。
7. 請求項１乃至６のいずれか一項に記載の通信端末と、
   前記複数の通信用のアプリケーションの通信先の通信端末と、
   を有する通信システム。
8. 請求項４乃至６のいずれか一項に記載の通信端末と、
   前記パブリッシュサブスクライブサーバと、
   を有する通信システム。
9. 通信端末間のコンテンツデータの中継を管理する中継管理装置を更に備えており、
   前記中継管理装置は、前記呼制御のための情報をサブスクライブする要求を前記パブリッシュサブスクライブサーバへ送信する請求項８に記載の通信システム。
10. 複数の通信用のアプリケーションが起動する通信端末に、
    前記複数の通信用のアプリケーションのうち、一方の通信用のアプリケーションによる呼制御のための情報の送信に応じて、前記情報に対応する一方の状態を示す状態情報を出力する処理と、
    前記一方の状態で利用されるリソースに応じて、前記複数の通信用のアプリケーションのうち他方の通信用のアプリケーションにかかる他方の状態を示す状態情報を出力する処理と、
    を実行させる出力方法。
11. 複数の通信用のアプリケーションが起動する通信端末に、
    前記複数の通信用のアプリケーションのうち、一方の通信用のアプリケーションによる呼制御のための情報の送信に応じて、前記情報に対応する前記一方の状態を示す状態情報を出力する処理と、
    前記一方の状態で利用されるリソースに応じて、前記複数の通信用のアプリケーションのうち他方の通信用のアプリケーションにかかる他方の状態を示す状態情報を出力する処理と、
    を実行させるプログラム。

Images