(57)【特許請求の範囲】
【請求項１】
第１の通信端末と、第２の通信端末と、前記第１の通信端末と前記第２の通信端末とが会議を行うために呼制御を行うための管理システムとがネットワークを介して通信可能な会議システムであって、
第１のユーザによる、前記第１の通信端末と前記第２の通信端末との間で前記会議を行うための会議用トピック発行要求に応じて、トピックを生成する生成手段と、
前記第１のユーザによる前記会議用トピック発行要求に応じて、前記第１のユーザによる前記トピックに対するパブリッシュ及びサブスクライブを認可し、前記第１のユーザによる、第２のユーザへのメッセージを示すトピック名を含み、前記第２のユーザを前記会議に招待するための招待要求に応じて、前記第２のユーザによる前記トピックに対するパブリッシュ及びサブスクライブを認可する認可手段と、
を有する会議システム。
【請求項２】
前記第１のユーザに関連付けられた１又は複数の宛先候補を示す宛先情報を管理する管理手段を有し、
前記認可手段は、前記第１のユーザによる前記会議を行うための前記会議用トピック発行要求に応じて、前記宛先情報によって示される前記１又は複数の宛先候補による情報の送信を認可する請求項１に記載の会議システム。
【請求項３】
前記管理手段は、前記第２のユーザに関連付けられた１又は複数の宛先候補を示す宛先情報を管理し、
前記認可手段は、前記第１のユーザによる前記第２のユーザを前記会議に招待するための前記招待要求に応じて、前記宛先情報によって示される前記第２のユーザに関連付けられた１又は複数の前記宛先候補による情報の送信を認可する請求項２に記載の会議システム。
【請求項４】
前記管理手段は、前記第１のユーザを示す前記トピックに関連付けて、前記トピックに対するパブリッシュが認可される前記第２のユーザの識別情報を管理し、
前記管理手段において管理されている前記第２のユーザの前記識別情報を、前記第１のユーザへ送信する送信手段を有する請求項３に記載の会議システム。
【請求項５】
前記第２のユーザを宛先候補として追加する要求を受け付ける受付手段と、
前記第２のユーザを追加する前記要求に応じて、前記管理手段において、前記第１のユーザを示すトピックに関連付けて、前記第２のユーザの識別情報を追加する追加手段と、
を有する請求項４に記載の会議システム。
【請求項６】
前記受付手段は、前記第２のユーザを前記第１のユーザに関連付けられた前記１又は複数の宛先候補から削除する要求を受け付け、
前記第２のユーザを削除する前記要求に応じて、前記管理手段から、前記第２のユーザの識別情報を削除する削除手段を有する請求項５に記載の会議システム。
【請求項７】
前記認可手段は、前記第１のユーザによる前記会議を行うための前記会議用トピック発行要求に応じて、前記第１のユーザが、前記トピックに対してメッセージをパブリッシュすること及び前記トピックに対してパブリッシュされたメッセージを受信することを認可し、
前記認可手段は、前記第１のユーザによる前記第２のユーザを前記会議に招待するための前記招待要求に応じて、前記第２のユーザが、前記トピックに対してメッセージをパブリッシュすること及び前記トピックに対してパブリッシュされた前記メッセージを受信することを認可する請求項１に記載の会議システム。
【請求項８】
第１の通信端末と、第２の通信端末と、前記第１の通信端末と前記第２の通信端末とが会議を行うために呼制御を行うための管理システムとがネットワークを介して通信可能な会議システムに、
第１のユーザによる、前記第１の通信端末と前記第２の通信端末との間で前記会議を行うための会議用トピック発行要求に応じて、トピックを生成する処理と、
前記第１のユーザによる前記会議用トピック発行要求に応じて、前記第１のユーザによる前記トピックに対するパブリッシュ及びサブスクライブを認可する処理と、
前記第１のユーザによる、第２のユーザへのメッセージを示すトピック名を含み、前記第２のユーザを前記会議に招待するための招待要求に応じて、前記第２のユーザによる前記トピックに対するパブリッシュ及びサブスクライブを認可する処理と、
を実行させる情報送信方法。
【請求項９】
第１の通信端末と、第２の通信端末と、前記第１の通信端末と前記第２の通信端末とが会議を行うために呼制御を行うための管理システムとがネットワークを介して通信可能な会議システムに、
第１のユーザによる、前記第１の通信端末と前記第２の通信端末との間で前記会議を行うための会議用トピック発行要求に応じて、トピックを生成する処理と、
前記第１のユーザによる前記会議用トピック発行要求に応じて、前記第１のユーザによる前記トピックに対するパブリッシュ及びザブスクライブを認可する処理と、
前記第１のユーザによる、第２のユーザへのメッセージを示すトピック名を含み、前記第２のユーザを前記会議に招待するための招待要求に応じて、前記第２のユーザによる前記トピックに対するパブリッシュ及びサブスクライブを認可する処理と、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報送信システム、情報送信方法、及びプログラムに関する。
【背景技術】
【０００２】
近年、当事者の移動の経費や時間を削減する要請等に伴い、インターネットや専用線等の通信ネットワークを介して通話や会議等を行う通信システムが普及している。このような通信システムでは、通信端末間で通信を開始すると、画像データ及び音データ等のコンテンツデータの送受信が行われ、当事者間のコミュニケーションを実現する。また、通信端末間でコンテンツデータを送信する方法として、出版−購読モデル（Publish-Subscribeモデル、以下、PubSubモデルと記載する）が知られている。【０００３】
例えば、特許文献１には、メッセージを発行側クライアントから購読側クライアントに複数のルーティング・ブローカ・マシンを介して配送するコンテンツベースのパブリッシュ・システムまたはサブスクライブ・システムのいずれかにおいてアクセス制御を提供する方法が開示されている。この方法では、ルーティング・ブローカ・マシンは新たなアクセス制御ルールを成立させる開始点を選ぶ。そして、開始点以前のメッセージは、そのメッセージが、アクセス制御バージョン識別子に対応付けられた変更前にサブスクリプション・フィルタとアクセス・フィルタを満たす場合かつその場合に限ってクライアントに配送され、また、開始点以降のメッセージは、そのメッセージがアクセス制御バージョン識別子に対応付けられた変更以降のサブスクリプション・フィルタとアクセス・フィルタの両方を満たす場合にクライアントに配送される。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載されているアクセス制御方法によると、予め設定されているフィルタに基づいて、所定の時点以降のメッセージの配送を制御する。しかしながら、この方法によると、アカウント間で情報を送信するセッション中に、セッションに対応するトピックに対する新たなアカウントによるパブリッシュ及びサブスクライブを認可することができないという課題が生じる。
【課題を解決するための手段】
【０００５】
請求項１に係る発明の情報送信システムは、情報の送信が認可されたアカウントの間で、前記情報を送信させるための情報送信システムである。情報送信システムは、第１のアカウントによるセッションを開始するための要求に応じて、前記セッションに対応するトピックを生成する生成手段と、前記第１のアカウントによる前記セッションを開始するための前記要求に応じて、前記第１のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可し、第２のアカウントを前記セッションに参加させるための要求に応じて、前記第２のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可する認可手段と、を有する。
【発明の効果】
【０００６】
以上説明したように本発明によれば、アカウント間で情報を送信するセッション中に、セッションに対応するトピックに対する新たなアカウントによるパブリッシュ及びサブスクライブを認可することが可能になるという効果を奏する。
【図面の簡単な説明】
【０００７】
【図１】本発明の一実施形態に係る通信システムの概略図である。
【図２】一実施形態に係る端末のハードウェア構成を示すブロック図である。
【図３】一実施形態に係る管理システムのハードウェア構成を示すブロック図である。
【図４】一実施形態に係る端末のソフトウェア構成を示すブロック図である。
【図５】一実施形態に係る端末、認証サーバ、及び管理システムの各機能を示すブロック図である。
【図６Ａ】認証サーバにおいて管理されるユーザ管理テーブルを示す概念図である。
【図６Ｂ】認証サーバにおいて管理されるクライアント管理テーブルを示す概念図である。
【図６Ｃ】認証サーバにおいて管理されるサービス管理テーブルを示す概念図である。
【図６Ｄ】認証サーバにおいて管理されるサービス認可管理テーブルを示す概念図である。
【図７】一実施形態における認証処理を示すシーケンス図である。
【図８】指定可能な宛先候補を更新する処理の一例を示すシーケンス図である。
【図９】宛先リストを取得する処理の一例を示すシーケンス図である。
【図１０】テレビ会議を開始する処理の一例を示すシーケンス図である。
【図１１】端末をセッションに参加させる処理の一例を示すシーケンス図である。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面を参照して説明する。
【０００９】
＜＜通信システムの概略＞＞
図１は、本発明の一実施形態に係る通信システムの概略図である。図１に示されているように、通信システム１は、通信端末１０、認証サーバ４０、管理システム５０によって構築されている。以下、通信端末１０を単に端末１０と記載する。
【００１０】
管理システム５０は、出版−購読（Publish-Subscribe、以下PubSubと記載する）モデルにおいて、クライアント間でメッセージを交換するために、クライアントから、メッセージの出版（Publish、以下pubと適宜記載する）やメッセージの購読（Subscribe、以下subと適宜記載する）の要求を受け付けるサーバである。管理システム５０は、PubSubモデル（Pub-Sub pattern）に対応するプロトコルとして、例えば、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要求の少なくとも一つを実行するためのアプリである。
【００２４】
なお、図４では少なくとも２つのクライアントアプリ（１０３１，１０３２）が端末１０にインストールされているが、１以上の任意の数のクライアントアプリが端末１０にインストールされていれば良い。また、ＯＳ１０２０上で任意のアプリケーションが動作しており、この任意のアプリケーション上でクライアントアプリが動作しても良い。
【００２５】
＜＜機能構成＞＞
次に、本実施形態の機能構成について説明する。図５は、一実施形態に係る通信システム１の一部を構成する端末１０、認証サーバ４０、及び管理システム５０の機能（要素）を示すブロック図である。図５では、端末１０、認証サーバ４０、及び管理システム５０が、通信ネットワーク２を介してデータ通信することができるように接続されている。
【００２６】
＜端末の機能構成＞
端末１０は、送受信部１１、操作入力受付部１２、表示制御部１３、認証要求部１４、pubsub要求部１５、及び記憶・読出部１９を有している。これら各部は、図２に示されている各構成要素のいずれかが、フラッシュメモリ１０４からＲＡＭ１０３上に展開されたプログラムに従ったＣＰＵ１０１からの命令によって動作することで実現される機能である。また、端末１０は、図２に示されているＲＯＭ１０２、ＲＡＭ１０３、フラッシュメモリ１０４によって構築される記憶部１０００を有している。
【００２７】
（端末の各機能構成）
次に、図２及び図５を用いて、端末１０の各機能構成について詳細に説明する。なお、以下では、端末１０の各機能構成を説明するにあたって、図２に示されている各構成要素のうち、端末１０の各機能構成を実現させるための主な構成要素との関係も説明する。
【００２８】
送受信部１１は、ＣＰＵ１０１からの命令、及びネットワークＩ／Ｆ１１１によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。
【００２９】
操作入力受付部１２は、ＣＰＵ１０１からの命令、並びに操作ボタン１０８及び電源スイッチ１０９によって実現され、ユーザによる各種入力を受け付けたり、ユーザによる各種選択を受け付けたりする。
【００３０】
表示制御部１３は、ＣＰＵ１０１からの命令、及びディスプレイＩ／Ｆ１１７によって実現され、通話する際に相手側から送られてきた画像データをディスプレイ１２０に送信するための制御を行う。
【００３１】
認証要求部１４は、ＣＰＵ１０１からの命令によって実現され、認証サーバ４０に対して認証を要求する。
【００３２】
pubsub要求部１５は、ＣＰＵ１０１からの命令によって実現され、管理システム５０に対してメッセージのpub及びsubを要求する。別の言い方をすれば、pubsub要求部１５は、管理システム５０に他の端末１０へメッセージのパブリッシュを要求することができる。また、pubsub要求部１５は、管理システム５０に、他の端末１０によりパブリッシュされたメッセージを受信するための要求をすることができる。別の言い方をすれば、pubsub要求部１５は、管理システム５０を介して、他の端末１０のpubsub要求部１５とメッセージ（情報）を送受信することができる。
【００３３】
記憶・読出部１９は、ＣＰＵ１０１からの命令及びＳＳＤ１０５によって実行され、又はＣＰＵ１０１からの命令によって実現され、記憶部１０００に各種データを記憶したり、記憶部１０００に記憶された各種データを抽出したりする処理を行う。
【００３４】
＜認証サーバの機能構成＞
認証サーバ４０は、送受信部４１、ユーザ認証部４２、クライアント認証部４３、認可部４４、トークン発行部４５、及び記憶・読出部４９を有する。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された認証サーバ４０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、認証サーバ４０は、ＨＤ５０４により構築される記憶部４０００を有している。
【００３５】
（ユーザ管理テーブル）
図６Ａは、ユーザ管理テーブルを示す概念図である。記憶部４０００には、ユーザ管理テーブルによってユーザ管理ＤＢ４００１が構築される。ユーザ管理テーブルでは、ユーザＩＤ（identifier, identification）毎に、ユーザ名、及びパスワードが関連付けられて管理されている。
【００３６】
（クライアント管理テーブル）
図６Ｂは、クライアント管理テーブルを示す概念図である。記憶部４０００には、クライアント管理テーブルによってクライアント管理ＤＢ４００２が構築される。クライアント管理テーブルでは、クライアントＩＤ毎に、クライアント名、及びパスワードが関連付けられて管理されている。なお、テレビ会議アプリは、複数のユーザ間で画像データ及び音データ等のコンテンツデータを交換（送受信）するためのクライアントアプリである。
【００３７】
（サービス管理テーブル）
図６Ｃは、サービス管理テーブルを示す概念図である。記憶部４０００には、サービス管理テーブルによってサービス管理ＤＢ４００３が構築される。サービス管理テーブルでは、サービスＩＤ毎に、サービス名が関連付けられて管理されている。一実施形態において、サービスＩＤ「Ｓ０１」で識別されるサービス「伝送管理システム」は、管理システム５０である。なお、管理システム５０のPubSubの機能を利用する権利がリソースである。また、管理システム５０を使ったPubSubサービスは、OAuth 2.0のプロトコルにおいて認可の単位となるスコープである。また、管理システム５０はリソースサーバに相当する。
【００３８】
（サービス認可管理テーブル）
図６Ｄは、サービス認可管理テーブルを示す概念図である。記憶部４０００には、サービス認可管理テーブルによってサービス認可管理ＤＢ４００４が構築される。サービス認可管理テーブルでは、クライアントＩＤ毎に、サービスＩＤが関連付けられて管理されている。これにより、サービス認可管理テーブルは、どのクライアントがどのサービスにアクセスして利用することができるかを管理することができる。図６Ｄのサービス認可管理テーブルによれば、クライアントＩＤ「Ｃ０１」で識別されるテレビ会議アプリは、サービスＩＤ「Ｓ０１」で識別される伝送管理システム、すなわち、管理システム５０にアクセスして利用することができることを示す。
【００３９】
（認証サーバの各機能構成）
送受信部４１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。
【００４０】
ユーザ認証部４２は、ＣＰＵ５０１からの命令によって実現され、クライアントからの要求に応じてユーザ認証を行う。
【００４１】
クライアント認証部４３は、ＣＰＵ５０１からの命令によって実現され、クライアントからの要求に応じてクライアント認証を行う。
【００４２】
認可部４４は、ＣＰＵ５０１からの命令によって実現され、サービスへのクライアントのアクセス権を指定することで認可する。
【００４３】
トークン発行部４５は、ＣＰＵ５０１からの命令によって実現され、クライアントがサービスへアクセスするときに、サービスで用いられる認可トークンを発行する。
【００４４】
記憶・読出部４９は、ＣＰＵ５０１からの命令及びＨＤＤ５０５によって実行され、又はＣＰＵ５０１からの命令によって実現され、記憶部４０００に各種データを記憶したり、記憶部４０００に記憶された各種データを抽出したりする処理を行う。
【００４５】
＜管理システムの機能構成＞
管理システム５０は、送受信部５１、トークン確認部５２、pubsub処理部５３、及び記憶・読出部５９を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された管理システム５０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、管理システム５０は、ＨＤ５０４により構築される記憶部５０００を有している。
【００４６】
（ユーザ認可管理テーブル）
表１Ａは、ユーザ認可管理テーブルを示す概念図である。記憶部５０００には、ユーザ認可管理テーブルによってユーザ認可管理ＤＢ５００３が構築される。ユーザ認可管理テーブルでは、トピックのトピック名毎に、ユーザ名、及びユーザがトピックに対してpub又はsubする権限を有するかを示す権限情報が関連付けられて管理されている。例えば、表１Ａのユーザ認可管理テーブルにより、ユーザ名"a"のユーザａが、トピック名"Roster/userA"のトピックに対しsubする権限を有し、トピック名"Roster/userM"のトピックに対しpubする権限を有することが示される。別の言い方をすれば、表１Ａに示されるように、ユーザａは、トピック名"Roster/userA"のトピックに対して発行されたメッセージを受信する権限を有し、また、ユーザａは、トピック名"Roster/userM"のトピックに対しメッセージをパブリッシュする権限を有する。なお、本実施形態において、"Roster"で始まるトピック名は、"Roster"の後に記述されるユーザを宛先とするメッセージを示す。すなわち、"Roster/userA"は、ユーザａ宛てのメッセージを示す。
【００４７】
【表１Ａ】
0006583543.tif 000002
（セッション管理テーブル）
表２Ａは、セッション管理テーブルを示す概念図である。記憶部５０００には、セッション管理テーブルによってセッション管理ＤＢ５００４が構築される。セッション管理テーブルでは、端末１０間で確立されるセッションで現在トピックをsubしているユーザ名、及びそのトピックのトピック名が関連付けられて管理されている。
【００４８】
【表２Ａ】
0006583543.tif 000003
（管理システムの各機能構成）
次に、管理システム５０の各機能構成について詳細に説明する。なお、以下では、管理システム５０の各機能構成を説明するにあたって、図３に示されている各構成要素のうち、管理システム５０の各機能構成を実現させるための主な構成要素との関係も説明する。
【００４９】
送受信部５１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して各端末、装置又はシステムと各種データ（または情報）の送受信を行う。
【００５０】
トークン確認部５２は、ＣＰＵ５０１からの命令によって実現され、端末１０のログイン要求に含まれている認可トークンを確認する。
【００５１】
pubsub処理部５３は、ＣＰＵ５０１からの命令によって実現され、クライアントによるpub（pub要求）又はsub（sub要求）にかかる処理を実行する。
【００５２】
記憶・読出部５９は、ＣＰＵ５０１からの命令及びＨＤＤ５０５によって実行され、又はＣＰＵ５０１からの命令によって実現され、記憶部５０００に各種データを記憶したり、記憶部５０００に記憶された各種データを抽出したりする処理を行う。
【００５３】
＜＜処理または動作＞＞
続いて、通信システム１を構成する端末１０、認証サーバ４０、及び管理システム５０の処理または動作について説明する。まずは、図７を用いて、一実施形態における認証処理について説明する。図７は、一実施形態における認証処理を示すシーケンス図である。
【００５４】
端末１０にインストールされている任意のクライアントアプリが起動すると（ステップＳ２１）、起動したクライアントアプリに対応する各機能部により以下の処理が開始される。端末１０のクライアントアプリは、ユーザのユーザＩＤ及びユーザパスワードの取得する（ステップＳ２２）。取得方法は、特に限定されないが、操作入力受付部１２が、ユーザによるユーザＩＤ及びパスワードの入力を受け付ける方法や、記憶・読出部１９が、記憶部１０００に予め記憶されているユーザＩＤ及びパスワードを読み出す方法によって、ユーザＩＤ及びユーザパスワードが取得される。
【００５５】
端末１０の認証要求部１４は、送受信部１１を介して、認証サーバ４０に認証／認可要求を送信する（ステップＳ２３）。この認証／認可要求には、ユーザの認証要求と、クライアントの認証要求と、サービス利用の認可要求とが含まれる。認証サーバ４０へ送信される認証要求には、端末１０において取得されたユーザＩＤ及びユーザパスワード、起動したクライアントのクライアントＩＤ及びクライアントパスワード、及びこれから利用するサービスを示すスコープとしてサービスＩＤが含まれている。クライアントＩＤ及びクライアントパスワードは、記憶部１０００に予め記憶されており、記憶・読出部１９によって読み出されたものでも良い。以下、認証要求に含まれるサービスＩＤは、管理システム５０を示す「Ｓ０１」である場合について説明する。
【００５６】
認証サーバ４０の送受信部４１は、端末１０による認証要求を受信する。認証サーバ４０のユーザ認証部４２は、認証要求に含まれるユーザＩＤ及びユーザパスワードの組が、ユーザ管理テーブル（図６Ａ参照）で管理されているか否かに基づいてユーザ認証を行う（ステップＳ２４）。認証要求に含まれるユーザＩＤ及びユーザパスワードの組がユーザ管理テーブルで管理されている場合には、ユーザ認証部４２はユーザ認証に成功し、認証要求に含まれるユーザＩＤ及びユーザパスワードの組がユーザ管理テーブルで管理されていない場合には、ユーザ認証部４２はユーザ認証に失敗する。
【００５７】
また、認証サーバ４０のクライアント認証部４３は、認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組が、クライアント管理テーブル（図６Ｂ参照）で管理されているか否かに基づいてクライアント認証を行う（ステップＳ２５）。認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組がクライアント管理テーブルで管理されている場合には、クライアント認証部４３はクライアント認証に成功し、認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組がクライアント管理テーブルで管理されていない場合には、クライアント認証部４３はクライアント認証に失敗する。
【００５８】
また、認証サーバ４０の認可部４４は、認証要求に含まれるクライアントＩＤ及びサービスＩＤの組が、サービス認可管理テーブル（図６Ｄ参照）で管理されているか否かに基づいて、要求元のクライアントのサービスへのアクセスを認可する（ステップＳ２６）。認証要求に含まれるクライアントＩＤ及びサービスＩＤの組がサービス認可管理テーブルで管理されている場合には、認可部４４は認可に成功し、認証要求に含まれるクライアントＩＤ及びサービスＩＤの組がサービス認可管理テーブルで管理されていない場合には、認可部４４は認可に失敗する。
【００５９】
ユーザ認証、クライアント認証、及びサービス認可の少なくとも一つに失敗した場合、送受信部４１は、認証又は認可に失敗した旨を示すエラーメッセージを要求元の端末１０へ送信する。
【００６０】
ユーザ認証、クライアント認証、及びサービス認可のすべてに成功した場合、認証サーバ４０のトークン発行部４５は、認証要求してきた端末１０が管理システム５０にアクセス可能であることを示す認可トークンを発行する（ステップＳ２７）。この認可トークンには、ユーザ名、クライアント名、この認可トークンを利用するサービス名、及びトークンの有効期限などが含まれている。
【００６１】
なお、通信システム１において、認証及び認可は、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)で暗号化される。
【００６２】
送受信部４１は、発行された認可トークンを認証結果に含めて端末１０へ送信する。端末１０の送受信部１１は、認証サーバによって送信された認可トークンを含む認証結果を受信する。続いて、端末１０の送受信部１１は受信した認可トークンを管理システム５０へ送信することにより、管理システム５０へログイン要求する（ステップＳ２８）。
【００６３】
管理システム５０の送受信部５１は、端末１０によって送信されたログイン要求を受信する。管理システム５０のトークン確認部５２は、ログイン要求に含まれる認可トークンを確認する（ステップＳ２９）。この場合、トークン確認部５２は、通信システム１で用いられる標準にしたがって、ログイン要求に含まれている認可トークンを解析する。トークン確認部５２は、解析の結果に応じて、認証サーバによる署名が正しいか否かを判断しても良い。認証サーバによる署名が正しいものではないと判断された場合、トークン確認部５２は、ログイン要求に含まれる認可トークンが改竄されていると判断して、認可に失敗する。
【００６４】
続いて、トークン確認部５２は、認可トークンに含まれている有効期限を確認することで、認可トークンの有効期限が切れているか否かを判断する。認可トークンの有効期限が切れていると判断された場合、トークン確認部５２は、認可トークンの期限切れにより認可に失敗する。
【００６５】
続いて、トークン確認部５２は、認可トークンに自管理システムに対応するサービス名が含まれているか否かを確認する。認可トークンに自管理システムに対応するサービス名が含まれていないと判断された場合、トークン確認部５２は、認可に失敗する。
【００６６】
トークン確認部５２が、認可トークンの署名、有効期限、及びサービスの確認のいずれかの過程で認可に失敗すると、送受信部５１は、端末１０へ認可に失敗した旨を示す認可結果情報を送信する。トークン確認部５２が、認可トークンの署名、有効期限、及びサービスのいずれもが正当なものであると判断した場合、認可トークンに示されているユーザ及びクライアントによるサービスの利用を認可する。ユーザ及びクライアントが認可されると、管理システム５０は、端末１０とのセッションを確立する（ステップＳ３０）。この場合、管理システム５０は、端末１０へ、認可に成功した旨を示す認可結果情報を送信する。
【００６７】
セッションが確立すると管理システム５０では、認可トークンに含まれているクライアントのユーザ名、及びクライアント名、並びにクライアントのＩＰアドレス等を関連付けて記憶部１０００において管理する。これにより、相手側のクライアントが情報を送信する毎に管理システム５０へ、ユーザ名、及びクライアント名を送信しなくても、管理システム５０では、送信元のクライアントのユーザ名、及びクライアント名を把握できるようになる。
【００６８】
以下、ユーザ名"a"で端末（第１の通信端末）１０ａが管理システム５０へログインし、ユーザ名"b"で端末（第２の通信端末）１０ｂが管理システム５０へログインしてからの処理について説明する。
【００６９】
図８を用いて、通信の宛先として指定可能な宛先候補を更新する処理について説明する。図８は、指定可能な宛先候補を更新する処理を示すシーケンス図である。なお、以下、一例として、端末１０ａが宛先候補の更新を要求する処理について説明するが、他の端末１０も同様にして、宛先候補の更新を要求することができる。
【００７０】
まず、端末１０ａの操作入力受付部１２は、宛先候補の更新要求の入力をユーザａから受け付ける（ステップＳ３１）。更新要求の入力に応じて、端末１０ａの送受信部１１は、更新要求を管理システム５０へ送信する（ステップＳ３２）。更新要求には、宛先候補の追加又は削除を示す更新情報、及び追加又は削除するユーザ名が含まれる。なお、図８に示す処理において、追加及び削除される宛先候補の数は１または複数であってもよい。
【００７１】
管理システム５０の送受信部５１は、端末１０ａによって送信される更新要求を受信する。更新要求を受信した送受信部５１は、更新要求に含まれる更新情報が宛先候補の追加を示すものであるか判断する（ステップＳ３３）。ここで、更新情報が追加を示すものではないと判断される場合（ステップＳ３３のＮＯ）、後述のステップＳ３６の処理へ進む。
【００７２】
更新情報が宛先候補の追加を示すものであると判断される場合（ステップＳ３３のＹＥＳ）、管理システム５０の送受信部５１は、更新要求に含まれるユーザ名により管理システム５０へログインした端末１０へ更新要求を送信する（ステップＳ３４）。更新要求に含まれるユーザ名が"b"である場合、管理システム５０の送受信部５１は、ユーザ名"b"で管理システム５０へログインした端末１０ｂへ更新要求を送信する。
【００７３】
端末１０ｂの送受信部１１は、管理システム５０によって送信される更新要求を受信する。端末１０ｂの操作入力受付部１２は、ユーザｂから更新要求の承認の入力を受け付ける。承認の入力が受け付けられると、端末１０ｂの送受信部１１は、更新要求の承認を示す承認情報を管理システム５０へ送信する（ステップＳ３５）。
【００７４】
承認情報が受信されると、管理システム５０の記憶・読出部５９は、更新要求に基づきユーザ認可管理テーブルを更新する（ステップＳ３６）。例えば、更新要求に含まれる更新情報が追加であり、更新されるユーザ名が"ｂ"である場合、記憶・読出部５９は、ユーザｂ宛のメッセージを示すトピック名"Roster/userB"に関連付けて、更新要求元のユーザａのユーザ名"a"、及び権限情報"pub"をユーザ認可管理テーブルに追加する。これにより、ユーザａからユーザｂへメッセージを送信可能になる。更に、記憶・読出部５９は、ユーザa宛のメッセージを示すトピック名"Roster/userA"に関連付けて、ユーザｂのユーザ名"b"、及び権限情報"pub"をユーザ認可管理テーブルに追加する。これにより、ユーザｂからユーザａへメッセージを送信可能になる。更新後のユーザ認可管理テーブルを表１Ｂに示す。別の言い方をすれば、ユーザａが、ユーザｂを宛先候補として追加するための更新要求を、管理システム５０に送信すると、ユーザａはユーザｂと情報(メッセージ)を送受信することが可能となる。別の言い方をすれば、ユーザａは、ユーザａに関連付けられた１又は複数の宛先候補と情報(メッセージ)を送受信することができる。
【００７５】
【表１Ｂ】
0006583543.tif 000004
なお、更新情報が削除である場合（ステップＳ３３のＮＯ）、記憶・読出部５９は、ユーザ認可管理テーブルにおいて、"Roster"の後にユーザaを示す情報が記述されるトピック名"Roster/userA"を検索し、検索されたトピック名に関連付けられているユーザ名から、更新要求に含まれるユーザ名を削除する。更に、記憶・読出部５９は、ユーザ認可管理テーブルにおいて、"Roster"の後に更新要求に含まれるユーザ名のユーザを示す情報が記述されるトピック名を検索し、検索されたトピック名に関連付けられているユーザ名から、ユーザａのユーザ名"a"を削除する。別の言い方をすれば、例えば、ユーザａが、ユーザｂを宛先候補からするための更新要求を、管理システム５０に送信すると、ユーザａはユーザｂと情報(メッセージ)を送受信することが不可能となる。
【００７６】
以下、ユーザ認可管理テーブルが表１Ｂに示されるように更新された場合について説明する。
【００７７】
図９を用いて、端末１０が、通信の宛先として指定可能な宛先候補を示した宛先リストを取得する処理について説明する。図９は、宛先リストを取得する処理を示すシーケンス図である。なお、以下、一例として、端末１０ａが宛先リストを取得する処理について説明するが、他の端末１０も同様にして、宛先リストを取得することができる。
【００７８】
管理システム５０へログイン後に、端末１０ａの送受信部１１は、宛先リスト取得要求を管理システム５０へ送信する（ステップＳ３７）。宛先リスト取得要求には、ユーザa宛のメッセージを示すトピック名"Roster/userA"が含まれている。
【００７９】
管理システム５０の送受信部５１は、端末１０ａにより送信される宛先リスト取得要求を受信する。管理システム５０の記憶・読出部５９は、宛先リスト取得要求に含まれるトピック名"Roster/userA"、及び権限情報"pub"の組を検索キーとして利用して、表１Ｂのユーザ認可管理テーブルを検索する。これにより、記憶・読出部５９は、ユーザａへメッセージを送信可能なユーザのユーザ名として"b,m"を読み出す（ステップＳ３８）。なお、他の例として、記憶・読出部５９は、ユーザａのユーザ名"a"を検索キーとして利用して、ユーザ認可管理テーブルを検索し、対応するトピック名を読み出しても良い。これにより、ユーザａによりメッセージを送信可能な宛先候補の情報が取得できる。
【００８０】
管理システム５０の送受信部５１は、ステップＳ３８で読み出されたユーザ名"b,m"を宛先リストとして、宛先リストの要求元の端末１０ａへ送信する（ステップＳ３９）。これにより、端末１０ａの送受信部１１は、宛先リストを取得する。
【００８１】
続いて、図１０を用いて端末１０ａ，１０ｂ間でテレビ会議を開始する処理について説明する。図１０は、テレビ会議を開始する処理の一例を示すシーケンス図である。以下、一例として端末１０ａ，１０ｂ間でテレビ会議を開始する処理を説明するが、他の端末１０間でも同様の処理によりテレビ会議を開始できる。
【００８２】
以下の処理において中継管理サーバ３０は、端末１０、管理システム５０と通信可能に通信ネットワーク２に接続し、端末１０間のコンテンツデータの中継を管理する。中継管理サーバ３０は、例えば、ビデオサーバ、ＭＣＵ（Multi-point Control Unit）、又はＳＩＰサーバである。なお、中継管理サーバ３０のハードウェア構成は管理システム５０と同様であるので説明を省略する。また、中継管理サーバ３０は、中継管理アプリにより、ユーザ名"z"で管理システム５０へログインしている。
【００８３】
端末１０ａのpubsub要求部１５は、ユーザａ宛てのメッセージを受信するため、ユーザａ宛のメッセージを示すトピック名"Roster/userA"が含まれるsub要求を管理システム５０へ送信する（ステップＳ４１−１）。同様に、端末１０ｂのpubsub要求部１５は、ユーザｂ宛てのメッセージを受け取るため、ユーザｂ宛のメッセージを示すトピック名"Roster/userB"が含まれるsub要求を管理システム５０へ送信する（ステップＳ４１−２）。
【００８４】
管理システム５０の送受信部５１は、端末１０ａ，１０ｂによって送信されるsub要求をそれぞれ受信する。管理システム５０のpubsub処理部５３は、各端末１０ａ，１０ｂのユーザがsub要求に係るsub権限を有するか判断する（ステップＳ４２）。この場合、pubsub処理部５３は、sub要求ごとに、sub要求に係るトピック名、sub要求元のユーザ名、及びsub権限を有することを示す権限情報"sub"の組が、表１Ｂのユーザ認可管理テーブルにおいて管理されているか判断する。上記の組がユーザ認可管理テーブルにおいて管理されていれば、pubsub処理部５３は、sub要求に係るsub権限を有し、管理されていなければ、sub要求にかかるsub権限を有しないと判断する。以下、それぞれのsub要求に対して、sub権限を有すると判断された場合について説明する。
【００８５】
pubsub処理部５３は、それぞれのsub要求元のユーザ名"a又はb"、及びsub要求に係るトピック"Roster/userA又はRoster/userB"をセッション管理テーブルに関連付けて登録する（ステップＳ４３）。登録後のセッション管理テーブルを表２Ｂに示す。
【００８６】
【表２Ｂ】
0006583543.tif 000005
sub要求が認可されると、端末１０ａの送受信部１１は、ユーザａが参加するテレビ会議に関するトピックの発行を要求するための会議用トピック発行要求を管理システム５０へ送信する（ステップＳ５１）。
【００８７】
管理システム５０の送受信部５１は、端末１０ａによって送信される会議用トピック発行要求を受信する。会議用トピック発行要求の受信に応じて、pubsub処理部５３は、ユーザａが参加するテレビ会議に関するトピックを発行する（ステップＳ５２）。トピックの発行方法の一例として、pubsub処理部５３は、要求にかかるテレビ会議を識別するためのトピック名として"ConfRoom1"を生成する。
【００８８】
管理システム５０の送受信部５１は、発行されたトピックのトピック名"ConfRoom1"を、発行要求元の端末１０ａ、及び中継管理サーバ３０へ送信する（ステップＳ５３−１，Ｓ５３−２）。
【００８９】
会議用のトピックが発行されると、管理システム５０のpubsub処理部５３は、発行されたトピックに対するpub及びsubを、トピックの発行要求元のユーザa、及び中継管理サーバのユーザzに対して認可する（ステップＳ５４）。
別の言い方をすれば、pubsub処理部５３は、ユーザａ及びユーザｚが、トピック名"ConfRoom1"のトピックに対してメッセージをパブリッシュすることを認可し、かつ、pubsub処理部５３は、ユーザａ及びユーザｚが、トピック名"ConfRoom1"のトピックに対して発行されたメッセージを受信することを認可する。この場合、pubsub処理部５３は、発行されたトピックのトピック名"ConfRoom1"、認可されるユーザのユーザ名"a,z"、pub及びsubする権限を示す権限情報"pub,sub"を関連付けて、ユーザ認可管理テーブルに登録する。表１Ｃは、登録後のユーザ認可管理テーブルの一例を示す。
【００９０】
【表１Ｃ】
0006583543.tif 000006
端末１０ａの送受信部１１は、ステップＳ５３−１で管理システム５０によって送信されるトピック名"ConfRoom1"を受信する。端末１０ａのpubsub要求部１５は、受信されたトピック名"ConfRoom1"を含みこのトピック名のトピックをsubする要求を示すsub要求を管理システム５０へ送信する（ステップＳ５５−１）。
【００９１】
中継管理サーバ３０は、ステップＳ５３−２で管理システム５０によって送信されるトピック名"ConfRoom1"を受信する。中継管理サーバ３０は、受信されたトピック名"ConfRoom1"を含みこのトピック名のトピックをsubする要求を示すsub要求を管理システム５０へ送信する（ステップＳ５５−２）。
【００９２】
管理システム５０の送受信部５１は、端末１０ａ、及び中継管理サーバ３０によって送信されるsub要求をそれぞれ受信する。管理システム５０のpubsub処理部５３は、sub要求元のユーザが、sub要求に係るトピックをsubする権限を有するか判断する（ステップＳ５６）。この場合、pubsub処理部５３は、sub要求ごとに、sub要求に係るトピック名"ConfRoom1"、sub要求元のユーザ名"a又はz"、及びsub権限を有することを示す権限情報"sub"の組が、表１Ｃのユーザ認可管理テーブルにおいて管理されているか判断する。本実施形態では、上記の組が表１Ｃのユーザ認可管理テーブルにおいて管理されているので、pubsub処理部５３は、それぞれのsub要求元がsub権限を有すると判断する。
【００９３】
それぞれsub権限を有すると判断された場合、pubsub処理部５３は、それぞれのsub要求元のユーザ名"a又はz"、及びsub要求に係るトピック"ConfRoom1"をセッション管理テーブルに関連付けて登録する（ステップＳ５７）。登録後のセッション管理テーブルを表２Ｃに示す。
【００９４】
【表２Ｃ】
0006583543.tif 000007
端末１０ａ、及び中継管理サーバ３０は、トピック名"ConfRoom1"のトピックに対して、端末１０ａ及び中継管理サーバ３０間のセッションｓｅｄの呼制御用メッセージをpubすることで、呼制御用メッセージを交換する（ステップＳ５８）。以下一例の処理について説明する。
【００９５】
端末１０ａのpubsub要求部１５は、トピック名"ConfRoom1"、及び呼制御用メッセージとして端末１０ａ側のコンテンツデータを中継する要求を含むpub要求を管理システム５０へ送信する。管理システム５０の送受信部５１は、端末１０ａによって送信されるpub要求を受信する。
【００９６】
管理システム５０のpubsub処理部５３は、表１Ｃのユーザ認可管理テーブルを参照して、pub要求元のユーザ名"a"、及びpub要求に含まれるトピック名"ConfRoom1"の組に対応付けて、pub権限を有することを示す権限情報"pub"が管理されているか確認する。これにより、pubsub処理部５３は、pub要求元が要求にかかるトピック名"ConfRoom1"のトピックへのpub権限を有すると判断する。pub権限を有すると判断された場合、pubsub処理部５３は、pub要求に含まれるトピック名"ConfRoom1"を検索キーとして利用して、表２Ｃのセッション管理テーブルを検索し、対応するユーザ名"z"を読み出す。管理システム５０のpubsub処理部５３は、読み出されたユーザ名"z"により管理システム５０にログインした中継管理サーバ３０へ呼制御用メッセージを送信する。
【００９７】
中継管理サーバ３０が、管理システム５０により送信される中継要求を受信すると、端末１０ａから送られてくる画像データ及び音データを所定の端末１０へ中継開始する。これにより、端末１０ａ及び中継管理サーバ３０間のセッションｓｅｄは確立されて、端末１０ａはテレビ会議を開始できるようになる。
【００９８】
続いて、図１１を用いて、端末１０ａがテレビ会議用のセッションｓｅｄに参加後に、端末１０ｂをこのセッションｓｅｄに参加させる処理を説明する。図１１は、端末１０をセッションに参加させる処理の一例を示すシーケンス図である。
【００９９】
端末１０ａのpubsub要求部１５は、ユーザｂ宛のメッセージを示すトピック名"Roster/userB"、及びユーザｂを会議に招待する旨を示すメッセージ"Invite"を含むpub要求を管理システム５０へ送信する（ステップＳ６１）。管理システム５０の送受信部５１は、端末１０ａによって送信されるpub要求を受信する。
【０１００】
管理システム５０のpubsub処理部５３は、表１Ｃのユーザ認可管理テーブルを参照して、pub要求元のユーザ名"a"、及びpub要求に含まれるトピック名"Roster/userB"の組に対応付けて、pub権限を有することを示す権限情報"pub"が管理されているか確認する(ステップＳ６２)。これにより、pubsub処理部５３は、pub要求元が要求にかかるトピック名"Roster/userB"のトピックへのpub権限を有するか判断する。
【０１０１】
pub権限を有すると判断された場合、管理システム５０のpubsub処理部５３は、pub要求に含まれるトピック名"Roster/userB"を検索キーとして、表２Ｃのセッション管理テーブルを検索し、対応するユーザ名"b"を読み出す。これにより、pubsub処理部５３は、ユーザｂを、メッセージ"Invite"の宛先に特定する（ステップＳ６３）。
【０１０２】
管理システム５０のpubsub処理部５３は、pub要求元のユーザａが参加しているテレビ会議を示すトピックに対するpub及びsubを、メッセージ"Invite"の宛先として特定されたユーザｂに対して認可する（ステップＳ６４）。この場合、pubsub処理部５３は、上記のトピックに対応するトピック名"ConfRoom1"、特定されたユーザｂのユーザ名"b"、pub及びsubする権限を示す権限情報"pub,sub"を関連付けて、ユーザ認可管理テーブルに登録する。表１Ｄは、登録後のユーザ認可管理テーブルの一例を示す。
【０１０３】
【表１Ｄ】
0006583543.tif 000008
管理システム５０のpubsub処理部５３は、ステップＳ６４において特定されたユーザｂの端末１０ｂへ、端末１０ａのpub要求にかかるトピック名"Roster/userB"及びメッセージ"Invite"を送信する（ステップＳ６５）。これにより、端末１０ｂの送受信部１１は、管理システム５０により送信されるトピック名"Roster/userB"及びメッセージ"Invite"を受信する。
【０１０４】
更に、管理システム５０の送受信部５１は、ユーザｂによるpub及びsubが認可されたトピックのトピック名"ConfRoom1"を、ユーザｂの端末１０ｂへ送信する（ステップＳ６６）。
【０１０５】
端末１０ｂの送受信部１１は、管理システム５０によって送信されるトピック名"ConfRoom1"を受信する。端末１０ｂのpubsub要求部１５は、受信されたトピック名"ConfRoom1"を含みこのトピック名のトピックをsubする要求を示すsub要求を管理システム５０へ送信する（ステップＳ６７）。
【０１０６】
管理システム５０の送受信部５１は、端末１０ｂによって送信されたsub要求を受信する。管理システム５０のpubsub処理部５３は、ステップＳ５６と同様にしてユーザｂがトピック名"ConfRoom1"のトピックをsubする権限を有するか判断する（ステップＳ６８）。
【０１０７】
ステップＳ６８でsub権限を有すると判断された場合、pubsub処理部５３は、sub要求元のユーザ名"b"、及びsub要求に係るトピック"ConfRoom1"をセッション管理テーブルに関連付けて登録する（ステップＳ６９）。登録後のセッション管理テーブルを表２Ｄに示す。
【０１０８】
【表２Ｄ】
0006583543.tif 000009
端末１０ａ，１０ｂ、及び中継管理サーバ３０は、トピック名"ConfRoom1"のトピックに対して、上記のセッションｓｅｄの呼制御用メッセージをpubすることで、呼制御用メッセージを交換する（ステップＳ７０）。以下一例の処理について説明する。
【０１０９】
端末１０ｂのpubsub要求部１５は、トピック名"ConfRoom1"、及び呼制御用メッセージとしてセッションｓｅｄへの参加要求を含むpub要求を管理システム５０へ送信する。管理システム５０の送受信部５１は、端末１０ｂによって送信されるpub要求を受信する。
【０１１０】
管理システム５０のpubsub処理部５３は、表１Ｄのユーザ認可管理テーブルを参照して、pub要求元のユーザ名"b"、及びpub要求に含まれるトピック名"ConfRoom1"の組に対応付けて、pub権限を有することを示す権限情報"pub"が管理されているか確認する。これにより、pubsub処理部５３は、pub要求元が要求にかかるトピック名"ConfRoom1"のトピックへのpub権限を有するか判断する。pub権限を有すると判断された場合、pubsub処理部５３は、pub要求に含まれるトピック名"ConfRoom1"を検索キーとして、表２Ｄのセッション管理テーブルを検索し、対応するユーザ名"a,b,z"を読み出す。管理システム５０のpubsub処理部５３は、読み出されたユーザ名"a,z"により管理システム５０にログインした端末１０ａ、中継管理サーバ３０へ呼制御用メッセージとして参加要求を送信する。
【０１１１】
端末１０ａ、及び中継管理サーバ３０が参加要求を受信すると、この参加要求を許可することで、端末１０ｂはセッションｓｅｄへ参加する。これにより、端末１０ａ，１０ｂ間でテレビ会議を開始できる。
【０１１２】
＜＜変形例Ａ＞＞
続いて、上記実施形態に対する変形例Ｂについて上記実施形態と異なる点を説明する。
【０１１３】
管理システム５０のpubsub処理部５３は、ステップＳ５４において、テレビ会議用のトピックに対し、発行要求元のユーザａ、中継管理サーバ３０のユーザｚに加えて、ユーザａによる通信の宛先候補にpub及びsubを認可する。
【０１１４】
ユーザａによる通信の宛先候補を特定する方法を説明する。管理システム５０は、ユーザａを宛先とするメッセージを示すトピック名"Roster/userA"、及び権限情報"pub"の組を検索キーとして表１Ｂのユーザ認可管理テーブルを検索する。これにより、読み出されるユーザ名"b,m"に基づいて、pubsub処理部５３は、ユーザａ，ｍを、宛先候補に特定する。
【０１１５】
pubsub処理部５３は、端末１０ａが参加するテレビ会議を示すトピック名"ConfRoom1"、ステップＳ６４で認可されるユーザのユーザ名"a,b,m,z"、pub及びsubする権限を示す権限情報"pub,sub"を関連付けて、ユーザ認可管理テーブルに登録する。表１Ｅは、登録後のユーザ認可管理テーブルの一例を示す。
【０１１６】
【表１Ｅ】
0006583543.tif 000010
管理システム５０の送受信部５１は、ステップＳ６４における認可に応じて、トピックのトピック名"ConfRoom1"を、認可されたユーザａ，ｂ，ｍ，ｚのユーザ名"a,b,m,z"により管理システム５０へログインした各端末１０及び中継管理サーバ３０へ送信する（ステップＳ６６）。
【０１１７】
変形例Ｂによると、テレビ会議への招待したいユーザが複数いる場合に、招待したいユーザ毎に招待のメッセージ"Invite"を送信しなくても良くなる。
【０１１８】
＜＜変形例Ｂ＞＞
続いて、上記実施形態又は上記変形例Ａに対する変形例Ｂについて、上記実施形態又は上記変形例Ａと異なる点を説明する。
【０１１９】
管理システム５０のpubsub処理部５３は、ステップＳ６４において、テレビ会議用のトピックに対し、招待要求先のユーザｂに加えて、ユーザｂが指定可能な宛先候補にpub及びsubを認可する。
【０１２０】
ユーザｂが指定可能な宛先候補を特定する方法を説明する。管理システム５０は、ユーザｂを宛先とするメッセージを示すトピック名"Roster/userB"、及び権限情報"pub"の組を検索キーとして表１Ｃのユーザ認可管理テーブルを検索する。これにより、読み出されるユーザ名"a,n"に基づいて、pubsub処理部５３は、ユーザａ，ｎを、ユーザｂが指定可能な宛先候補に特定する。
【０１２１】
pubsub処理部５３は、端末１０ａが参加するテレビ会議を示すトピック名"ConfRoom1"、ステップＳ６４で新たに認可されるユーザのユーザ名、pub及びsubする権限を示す権限情報"pub,sub"を関連付けて、ユーザ認可管理テーブルに登録する。表１Ｆは、登録後のユーザ認可管理テーブルの一例を示す。
【０１２２】
【表１Ｆ】
0006583543.tif 000011
管理システム５０の送受信部５１は、ステップＳ６４における認可に応じて、トピックのトピック名"ConfRoom1"を、新たに認可されたユーザのユーザ名により管理システム５０へログインした各端末１０へ送信する（ステップＳ６６）。
【０１２３】
変形例Ｂによると、テレビ会議への招待したいユーザが複数でいる場合に、招待したいユーザ毎に招待のメッセージ"Invite"を送信しなくても良くなる。
【０１２４】
＜＜本実施形態の主な効果＞＞
続いて、上記の実施形態の主な効果を説明する。上記実施形態の情報送信方法によると、管理システム５０（情報送信システムの一例）は呼制御用のメッセージ（情報の一例）のpub（送信の一例）が認可されたユーザ（アカウントの一例）間で、メッセージを送信させる。管理システム５０のpubsub処理部５３（認可手段の一例）は、第１のアカウントによる会議用トピック発行要求（セッションを開始するための要求の一例）に応じて、第１のアカウントによるpub（メッセージの送信の一例）を認可し、第２のアカウントの招待の要求（第２のアカウントをセッションに参加せるための要求の一例）に応じて、第２のアカウントによるpub（メッセージの送信の一例）を認可する。これにより、アカウント間でメッセージを送信するセッション中に、新たなアカウントに対してメッセージの送信を認可することが可能になる。
【０１２５】
管理システム５０のユーザ認可管理ＤＢ５００３（管理手段の一例）は、第１のアカウントに関連付けられた１又は複数の宛先候補を示すユーザ名（宛先情報の一例）を管理する。管理システム５０のpubsub処理部５３は、第１のアカウントによる第２のアカウントの招待の要求に応じて、上記のユーザ名の宛先候補によるpub（情報の送信）を認可する。これにより、セッションに招待する第２のアカウントが複数いる場合に、アカウントごとに、招待のメッセージを送信しなくても、第２のアカウントがセッションに参加可能になる。
【０１２６】
管理システム５０のユーザ認可管理ＤＢ５００３は、第２のアカウントに関連付けられた１又は複数の宛先候補を示すユーザ名を管理する。管理システム５０のpubsub処理部５３は、第１のアカウントによる第２のアカウントの招待の要求に応じて、上記のユーザ名によって示される宛先候補によるpub（情報の送信）を認可する。これにより、セッションに招待する第２のアカウント（他のアカウント）が複数いる場合に、アカウントごとに、招待のメッセージを送信しなくても、第２のアカウントがセッションに参加可能になる。
【０１２７】
管理システム５０のpubsub処理部５３（生成手段の一例）は、会議用トピック発行要求に応じて、テレビ会議用のセッションに対応するトピックを発行（生成の一例）する。管理システム５０のpubsub処理部５３は、第１のアカウントによる会議用トピック発行要求に応じて、第１のアカウントによる、トピックに対するpub及びsubを認可し、第２のアカウントの招待の要求に応じて、第２のアカウントによる、トピックに対するpub及びsubを認可する。別の言い方をすれば、pubsub処理部５３は、会議用トピック発行要求に応じて、第１のアカウントが、生成されたトピックに対してメッセージをパブリッシュすること及び生成されたトピックに対してパブリッシュされたメッセージを受信することを認可してもよい。また、pubsub処理部５３は、第１のアカウントによる、第２のアカウントを招待する要求に応じて、第２のアカウントが、生成されたトピックに対してメッセージをパブリッシュすること及び生成されたトピックに対してパブリッシュされたメッセージを受信することを認可する。これにより、アカウント間で情報を送信するセッション中に、新たなアカウントに対して情報の送信を認可することが可能になる。
【０１２８】
管理システム５０のユーザ認可管理ＤＢ５００３は、第１のアカウントを示すトピックに関連付けて、トピックに対するパブリッシュが認可される第２のアカウントのユーザ名（識別情報の一例）を管理する。管理システム５０の送受信部１１（送信手段の一例）は、ユーザ認可管理ＤＢ５００３において管理されている第２のアカウントのユーザ名を第１のアカウントへ送信する。これにより、ユーザ認可管理ＤＢ５００３により宛先候補を管理できるので、管理システム５０は、別途、宛先リストを管理する負荷を軽減できる。
【０１２９】
管理システム５０の送受信部５１（受付手段の一例）は、第１のアカウントから、第２のアカウントを宛先候補として追加する要求を受け付ける。管理システム５０の記憶・読出部５９（追加手段の一例）は、第２のアカウントを追加する要求に応じて、ユーザ認可管理ＤＢ５００３において、第１のアカウントを示すトピックに関連付けて要求に係る第２のアカウントのユーザ名を追加する。これにより、管理システム５０は、第１のアカウントの宛先候補を更新できる。
【０１３０】
管理システム５０の送受信部５１前記受付手段は、第２のアカウントを第１のアカウントに関連付けられた１又は複数の宛先候補から削除する要求を受け付ける。管理システム５０の記憶・読出部５９（削除手段の一例）は、第２のアカウントを削除する要求に応じて、ユーザ認可管理ＤＢ５００３において、第１のアカウントを示すトピックに関連付けられている、要求に係る第２のアカウントのユーザ名を削除する。これにより、管理システム５０は、第１のアカウントの宛先候補を更新できる。
【０１３１】
＜＜実施形態の補足＞＞
端末１０、認証サーバ４０、及び管理システム５０用の各プログラムは、インストール可能な形式又は実行可能な形式のファイルによって、コンピュータで読み取り可能な記録媒体（記録メディア１０６等）に記録されて流通されるようにしてもよい。また、上記記録媒体の他の例として、ＣＤ−Ｒ(Compact Disc Recordable)、ＤＶＤ(Digital Versatile Disk)、ブルーレイディスク等が挙げられる。
【０１３２】
また、上記実施形態の各プログラムが記憶されたＣＤ−ＲＯＭ等の記録媒体、並びに、これらプログラムが記憶されたＨＤ５０４は、プログラム製品(Program Product)として、国内又は国外へ提供されることができる。
【０１３３】
また、上記実施形態における端末１０、認証サーバ４０、及び管理システム５０は、単一のコンピュータによって構築されてもよいし、各部（機能又は手段）を分割して任意に割り当てられた複数のコンピュータによって構築されていてもよい。また、認証サーバ４０及び管理システム５０は、単一のコンピュータによって構築されていても良い。
【０１３４】
上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路を含むプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC(Application Specific Integrated Circuit)や従来の回路モジュール等のデバイスを含むものとする。
【０１３５】
なお、上記した実施形態に係る情報送信システムは、１以上のプログラムを記憶したデバイスメモリーと、１以上のプロセッサによって実現されてもよい。１以上のプロセッサは、１以上のプログラムを実行することで、実施形態において記載された処理を実行する。例えば、デバイスメモリーと１以上のプロセッサは、実施形態に記載されたような機能を実現（実装）することができる。例えば、デバイスメモリーと１以上のプロセッサは、実施形態において記載されたようなハードウェア要素によって実現（実装）されてもよい。
【０１３６】
以上、本発明を実施形態に基づいて説明したが、本発明は上記実施形態に限定されるものではなく、特許請求の範囲に記載の範囲内で様々な変形が可能である。
【０１３７】
本願は、日本特許庁に２０１６年３月２８日に出願された基礎出願２０１６−０６３７５１号の優先権を主張するものであり、その全内容を参照によりここに援用する。
【符号の説明】
【０１３８】
１  通信システム
２  通信ネットワーク
１０  端末
１１  送受信部
１２  操作入力受付部
１３  表示制御部
１４  認証要求部
１５  pubsub要求部
１９  記憶・読出部
４０  認証サーバ
４１  送受信部
４２  ユーザ認証部
４３  クライアント認証部
４４  認可部
４５  トークン発行部
４９  記憶・読出部
５０  管理システム
５１  送受信部
５２  トークン確認部
５３  pubsub処理部
５９  記憶・読出部
１０００  記憶部
４０００  記憶部
４００１  ユーザ管理ＤＢ
４００２  クライアント管理ＤＢ
４００３  サービス管理ＤＢ
４００４  サービス認可管理ＤＢ
５０００  記憶部
５００３  ユーザ認可管理ＤＢ
５００４  セッション管理ＤＢ
【先行技術文献】
【特許文献】
【０１３９】
【特許文献１】特許第５１６０１３４号公報
【図１】
0006583543.tif 000012
【図２】
0006583543.tif 000013
【図３】
0006583543.tif 000014
【図４】
0006583543.tif 000015
【図５】
0006583543.tif 000016
【図６Ａ】
0006583543.tif 000017
【図６Ｂ】
0006583543.tif 000018
【図６Ｃ】
0006583543.tif 000019
【図６Ｄ】
0006583543.tif 000020
【図７】
0006583543.tif 000021
【図８】
0006583543.tif 000022
【図９】
0006583543.tif 000023
【図１０】
0006583543.tif 000024
【図１１】
0006583543.tif 000025