JP2017098780A - 管理システム、通信システム、通信制御方法、及びプログラム - Google Patents
管理システム、通信システム、通信制御方法、及びプログラム Download PDFInfo
- Publication number
- JP2017098780A JP2017098780A JP2015229814A JP2015229814A JP2017098780A JP 2017098780 A JP2017098780 A JP 2017098780A JP 2015229814 A JP2015229814 A JP 2015229814A JP 2015229814 A JP2015229814 A JP 2015229814A JP 2017098780 A JP2017098780 A JP 2017098780A
- Authority
- JP
- Japan
- Prior art keywords
- service
- client
- pub
- request
- sub
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
Abstract
【課題】クライアントが利用するサービス毎にメッセージへのアクセスを制御する管理システム、通信システム、通信制御方法及びプログラムを提供する。【解決手段】管理システム５０の送受信部５１は、トピックに対するメッセージのpub要求を第１のクライアントで認証された端末１０から受け付ける一方で、トピックに対するメッセージのsub要求を第２のクライアントで認証された端末１０から受け付ける。管理システム５０のpub処理部５３及びsub処理部５４は、トピックが、第１のクライアント又は第２のクライアントによって利用される各サービスに対応付けられているかに基づいて、端末１０へのメッセージの配信を制御する。【選択図】図５
Description
本発明は、管理システム、通信システム、通信制御方法、及びプログラムに関する。
近年、当事者の移動の経費や時間を削減する要請等に伴い、インターネットや専用線等の通信ネットワークを介して通話や会議等を行う通信システムが普及している。このような通信システムでは、通信端末間で通信を開始すると、画像データ及び音データ等のコンテンツデータの送受信が行われ、当事者間のコミュニケーションを実現する。また、通信端末間でコンテンツデータを送信する方法として、出版−購読モデル（Publish-Subscribeモデル、以下、PubSubモデルと記載する）が知られている。
例えば、特許文献１には、メッセージを発行側クライアントから購読側クライアントに複数のルーティング・ブローカ・マシンを介して配送するコンテンツベースのパブリッシュ・システムまたはサブスクライブ・システムのいずれかにおいてアクセス制御を提供する方法が開示されている。この方法では、ルーティング・ブローカ・マシンは新たなアクセス制御ルールを成立させる開始点を選ぶ。そして、開始点以前のメッセージは、そのメッセージが、アクセス制御バージョン識別子に対応付けられた変更前にサブスクリプション・フィルタとアクセス・フィルタを満たす場合かつその場合に限ってクライアントに配送され、また、開始点以降のメッセージは、そのメッセージがアクセス制御バージョン識別子に対応付けられた変更以降のサブスクリプション・フィルタとアクセス・フィルタの両方を満たす場合にクライアントに配送される。
特許文献１のパブリッシュ・システムまたはサブスクライブ・システムによると、新たなアクセス制御ルールを成立させる開始点の前後で、クライアントによるメッセージへのアクセス制御のルールを変更することができる。しかしながら、従来のPubSubモデルの通信システムによると、クライアントが利用するサービス毎にメッセージへのアクセスを制御することができないという課題が生じる。
請求項１に係る発明の管理システムは、所定の属性の情報を配信する要求を、第１のクライアントで認証された第１の通信端末から受け付ける一方で、前記所定の属性の情報を受信する要求を、第２のクライアントで認証された第２の通信端末から受け付ける受付手段と、前記第１のクライアントによって利用される第１のサービス又は前記第２のクライアントによって利用される第２のサービスが、前記所定の属性に対応付けられているかに基づいて、前記第２の通信端末への前記所定の属性の情報の配信を制御する配信制御手段と、を有することを特徴とする。
以上説明したように本発明によれば、通信システムにおいて、クライアントが利用するサービス毎にメッセージへのアクセスを制御することが可能になるという効果を奏する。
以下、本発明の実施形態について説明する。
＜＜通信システムの概略＞＞
図１は、本発明の一実施形態に係る通信システムの概略図である。図１に示されているように、通信システム１は、通信端末１０、認証サーバ４０、管理システム５０によって構築されている。以下、通信端末１０を単に端末１０と記載する。
図１は、本発明の一実施形態に係る通信システムの概略図である。図１に示されているように、通信システム１は、通信端末１０、認証サーバ４０、管理システム５０によって構築されている。以下、通信端末１０を単に端末１０と記載する。
管理システム５０は、出版−購読（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要求部１５、sub要求部１６、及び記憶・読出部１９を有している。これら各部は、図２に示されている各構成要素のいずれかが、フラッシュメモリ１０４からＲＡＭ１０３上に展開されたプログラムに従ったＣＰＵ１０１からの命令によって動作することで実現される機能である。また、端末１０は、図２に示されているＲＯＭ１０２、ＲＡＭ１０３、フラッシュメモリ１０４によって構築される記憶部１０００を有している。
端末１０は、送受信部１１、操作入力受付部１２、表示制御部１３、認証要求部１４、pub要求部１５、sub要求部１６、及び記憶・読出部１９を有している。これら各部は、図２に示されている各構成要素のいずれかが、フラッシュメモリ１０４からＲＡＭ１０３上に展開されたプログラムに従ったＣＰＵ１０１からの命令によって動作することで実現される機能である。また、端末１０は、図２に示されているＲＯＭ１０２、ＲＡＭ１０３、フラッシュメモリ１０４によって構築される記憶部１０００を有している。
（端末の各機能構成）
次に、図２及び図５を用いて、端末１０の各機能構成について詳細に説明する。なお、以下では、端末１０の各機能構成を説明するにあたって、図２に示されている各構成要素のうち、端末１０の各機能構成を実現させるための主な構成要素との関係も説明する。
次に、図２及び図５を用いて、端末１０の各機能構成について詳細に説明する。なお、以下では、端末１０の各機能構成を説明するにあたって、図２に示されている各構成要素のうち、端末１０の各機能構成を実現させるための主な構成要素との関係も説明する。
送受信部１１は、ＣＰＵ１０１からの命令、及びネットワークＩ／Ｆ１１１によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。
操作入力受付部１２は、ＣＰＵ１０１からの命令、並びに操作ボタン１０８及び電源スイッチ１０９によって実現され、ユーザによる各種入力を受け付けたり、ユーザによる各種選択を受け付けたりする。
表示制御部１３は、ＣＰＵ１０１からの命令、及びディスプレイＩ／Ｆ１１７によって実現され、通話する際に相手側から送られてきた画像データをディスプレイ１２０に送信するための制御を行う。
認証要求部１４は、クライアントアプリに従ったＣＰＵ１０１からの命令によって実現され、認証サーバ４０に対して認証を要求する。なお、端末１０において複数のクライアントアプリがインストールされている場合、端末１０には、起動したクライアントアプリ毎に認証要求部１４が生成される。
pub要求部１５は、クライアントアプリに従ったＣＰＵ１０１からの命令によって実現され、管理システム５０に対してメッセージのpub要求をする。なお、クライアントアプリがsubに対応する一方でpubには対応していない場合、端末１０においてpub要求部１５は生成されない。また、端末１０においてpubに対応した複数のクライアントアプリがインストールされている場合、端末１０には、起動したクライアントアプリ毎にpub要求部１５が生成される。
sub要求部１６は、クライアントアプリに従ったＣＰＵ１０１からの命令によって実現され、管理システム５０に対してメッセージのsub要求をする。なお、クライアントアプリがpubに対応する一方でsubには対応していない場合、端末１０においてsub要求部１６は生成されない。また、端末１０においてsubに対応した複数のクライアントアプリがインストールされている場合、端末１０には、起動したクライアントアプリ毎にsub要求部１６が生成される。
記憶・読出部１９は、ＣＰＵ１０１からの命令及びＳＳＤ１０５によって実行され、又はＣＰＵ１０１からの命令によって実現され、記憶部１０００に各種データを記憶したり、記憶部１０００に記憶された各種データを抽出したりする処理を行う。
＜認証サーバの機能構成＞
認証サーバ４０は、送受信部４１、ユーザ認証部４２、クライアント認証部４３、認可部４４、トークン発行部４５、及び記憶・読出部４９を有する。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された認証サーバ４０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、認証サーバ４０は、ＨＤ５０４により構築される記憶部４０００を有している。
認証サーバ４０は、送受信部４１、ユーザ認証部４２、クライアント認証部４３、認可部４４、トークン発行部４５、及び記憶・読出部４９を有する。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された認証サーバ４０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、認証サーバ４０は、ＨＤ５０４により構築される記憶部４０００を有している。
（ユーザ管理テーブル）
図６Ａは、ユーザ管理テーブルを示す概念図である。記憶部４０００には、ユーザ管理テーブルによってユーザ管理ＤＢ４００１が構築される。ユーザ管理テーブルでは、ユーザＩＤ（identifier, identification）毎に、ユーザ名、及びパスワードが関連付けられて管理されている。
図６Ａは、ユーザ管理テーブルを示す概念図である。記憶部４０００には、ユーザ管理テーブルによってユーザ管理ＤＢ４００１が構築される。ユーザ管理テーブルでは、ユーザＩＤ（identifier, identification）毎に、ユーザ名、及びパスワードが関連付けられて管理されている。
（クライアント管理テーブル）
図６Ｂは、クライアント管理テーブルを示す概念図である。記憶部４０００には、クライアント管理テーブルによってクライアント管理ＤＢ４００２が構築される。クライアント管理テーブルでは、クライアントＩＤ毎に、クライアント名、及びパスワードが関連付けられて管理されている。
図６Ｂは、クライアント管理テーブルを示す概念図である。記憶部４０００には、クライアント管理テーブルによってクライアント管理ＤＢ４００２が構築される。クライアント管理テーブルでは、クライアントＩＤ毎に、クライアント名、及びパスワードが関連付けられて管理されている。
（サービス管理テーブル）
図６Ｃは、サービス管理テーブルを示す概念図である。記憶部４０００には、サービス管理テーブルによってサービス管理ＤＢ４００３が構築される。サービス管理テーブルでは、サービスＩＤ毎に、サービス名が関連付けられて管理されている。
図６Ｃは、サービス管理テーブルを示す概念図である。記憶部４０００には、サービス管理テーブルによってサービス管理ＤＢ４００３が構築される。サービス管理テーブルでは、サービスＩＤ毎に、サービス名が関連付けられて管理されている。
（サービス認可管理テーブル）
図６Ｄは、サービス認可管理テーブルを示す概念図である。記憶部４０００には、サービス認可管理テーブルによってサービス認可管理ＤＢ４００４が構築される。サービス認可管理テーブルでは、サービスのサービスＩＤ、及びこのサービスへのアクセスが認可されるクライアントのクライアントＩＤが関連付けられて管理されている。
図６Ｄは、サービス認可管理テーブルを示す概念図である。記憶部４０００には、サービス認可管理テーブルによってサービス認可管理ＤＢ４００４が構築される。サービス認可管理テーブルでは、サービスのサービスＩＤ、及びこのサービスへのアクセスが認可されるクライアントのクライアントＩＤが関連付けられて管理されている。
（認証サーバの各機能構成）
送受信部４１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。
送受信部４１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。
ユーザ認証部４２は、ＣＰＵ５０１からの命令によって実現され、クライアントからの要求に応じてユーザ認証を行う。
クライアント認証部４３は、ＣＰＵ５０１からの命令によって実現され、クライアントからの要求に応じてクライアント認証を行う。
認可部４４は、ＣＰＵ５０１からの命令によって実現され、サービスへのクライアントのアクセス権を指定することで認可する。
トークン発行部４５は、ＣＰＵ５０１からの命令によって実現され、クライアントがサービスへアクセスするときに、サービスで用いられる認可トークンを発行する。
記憶・読出部４９は、ＣＰＵ５０１からの命令及びＨＤＤ５０５によって実行され、又はＣＰＵ５０１からの命令によって実現され、記憶部４０００に各種データを記憶したり、記憶部４０００に記憶された各種データを抽出したりする処理を行う。
＜管理システムの機能構成＞
管理システム５０は、送受信部５１、トークン確認部５２、pub処理部５３、sub処理部５４、及び記憶・読出部５９を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された管理システム５０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、管理システム５０は、ＨＤ５０４により構築される記憶部５０００を有している。
管理システム５０は、送受信部５１、トークン確認部５２、pub処理部５３、sub処理部５４、及び記憶・読出部５９を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された管理システム５０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、管理システム５０は、ＨＤ５０４により構築される記憶部５０００を有している。
（トピック管理テーブル）
図７Ａは、トピック管理テーブルを示す概念図である。記憶部５０００には、トピック管理テーブルによってトピック管理ＤＢ５００１が構築される。トピック管理テーブルでは、トピックＩＤ毎に、トピック名が関連付けられて管理されている。トピックとはメッセージに関連付けられる属性である。クライアントアプリがトピックを指定してsub要求すると、管理システム５０は、そのトピックに関連付けてpubされたメッセージを、そのトピックに対するsub要求元のクライアントアプリへ送信する。
図７Ａは、トピック管理テーブルを示す概念図である。記憶部５０００には、トピック管理テーブルによってトピック管理ＤＢ５００１が構築される。トピック管理テーブルでは、トピックＩＤ毎に、トピック名が関連付けられて管理されている。トピックとはメッセージに関連付けられる属性である。クライアントアプリがトピックを指定してsub要求すると、管理システム５０は、そのトピックに関連付けてpubされたメッセージを、そのトピックに対するsub要求元のクライアントアプリへ送信する。
（ユーザトピック管理テーブル）
図７Ｂは、ユーザトピック管理テーブルを示す概念図である。記憶部５０００には、ユーザトピック管理テーブルによってユーザトピック管理ＤＢ５００２が構築される。ユーザトピック管理テーブルでは、ユーザのユーザＩＤ、トピックのトピックＩＤ、及び、ユーザがトピックのpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。なお、権限情報"pub"はpubを拒否する権限があることを示し、権限情報"sub"はsubを拒否する権限があることを示し、権限情報"pubsub"はpub及びsubを拒否する権限があることを示す。
図７Ｂは、ユーザトピック管理テーブルを示す概念図である。記憶部５０００には、ユーザトピック管理テーブルによってユーザトピック管理ＤＢ５００２が構築される。ユーザトピック管理テーブルでは、ユーザのユーザＩＤ、トピックのトピックＩＤ、及び、ユーザがトピックのpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。なお、権限情報"pub"はpubを拒否する権限があることを示し、権限情報"sub"はsubを拒否する権限があることを示し、権限情報"pubsub"はpub及びsubを拒否する権限があることを示す。
（ユーザサービス管理テーブル）
図７Ｃは、ユーザサービス管理テーブルを示す概念図である。記憶部５０００には、ユーザサービス管理テーブルによってユーザサービス管理ＤＢ５００３が構築される。ユーザサービス管理テーブルでは、ユーザのユーザＩＤ、サービスのサービスＩＤ、及び、ユーザがサービスを利用してpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。
図７Ｃは、ユーザサービス管理テーブルを示す概念図である。記憶部５０００には、ユーザサービス管理テーブルによってユーザサービス管理ＤＢ５００３が構築される。ユーザサービス管理テーブルでは、ユーザのユーザＩＤ、サービスのサービスＩＤ、及び、ユーザがサービスを利用してpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。
（ユーザクライアント管理テーブル）
図７Ｄは、ユーザクライアント管理テーブルを示す概念図である。記憶部５０００には、ユーザクライアント管理テーブルによってユーザクライアント管理ＤＢ５００４が構築される。ユーザクライアント管理テーブルでは、ユーザのユーザＩＤ、クライアントのクライアントＩＤ、及び、ユーザがクライアントからpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。
図７Ｄは、ユーザクライアント管理テーブルを示す概念図である。記憶部５０００には、ユーザクライアント管理テーブルによってユーザクライアント管理ＤＢ５００４が構築される。ユーザクライアント管理テーブルでは、ユーザのユーザＩＤ、クライアントのクライアントＩＤ、及び、ユーザがクライアントからpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。
（クライアントトピック管理テーブル）
図７Ｅは、クライアントトピック管理テーブルを示す概念図である。記憶部５０００には、クライアントトピック管理テーブルによってクライアントトピック管理ＤＢ５００５が構築される。クライアントトピック管理テーブルでは、トピックのトピックＩＤ、クライアントのクライアントＩＤ、及び、クライアントからトピックのpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。
図７Ｅは、クライアントトピック管理テーブルを示す概念図である。記憶部５０００には、クライアントトピック管理テーブルによってクライアントトピック管理ＤＢ５００５が構築される。クライアントトピック管理テーブルでは、トピックのトピックＩＤ、クライアントのクライアントＩＤ、及び、クライアントからトピックのpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。
（クライアントサービス管理テーブル）
図７Ｆは、クライアントサービス管理テーブルを示す概念図である。記憶部５０００には、クライアントサービス管理テーブルによってクライアントサービス管理ＤＢ５００６が構築される。クライアントサービス管理テーブルでは、サービスのサービスＩＤ、このサービスへのアクセスが認可されるクライアントのクライアントＩＤが関連付けられて管理されている。
図７Ｆは、クライアントサービス管理テーブルを示す概念図である。記憶部５０００には、クライアントサービス管理テーブルによってクライアントサービス管理ＤＢ５００６が構築される。クライアントサービス管理テーブルでは、サービスのサービスＩＤ、このサービスへのアクセスが認可されるクライアントのクライアントＩＤが関連付けられて管理されている。
（サービストピック管理テーブル）
図７Ｇは、サービストピック管理テーブルを示す概念図である。記憶部５０００には、サービストピック管理テーブルによってサービストピック管理ＤＢ５００７が構築される。サービストピック管理テーブルでは、サービスのサービスＩＤ、トピックのトピックＩＤ、及び、サービスを利用してトピックのpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。
図７Ｇは、サービストピック管理テーブルを示す概念図である。記憶部５０００には、サービストピック管理テーブルによってサービストピック管理ＤＢ５００７が構築される。サービストピック管理テーブルでは、サービスのサービスＩＤ、トピックのトピックＩＤ、及び、サービスを利用してトピックのpub又はsubを要求するときに、要求を拒否する権限を示す権限情報が関連付けられて管理されている。
（サービス継承管理テーブル）
図７Ｈは、サービス継承管理テーブルを示す概念図である。記憶部５０００には、サービス継承管理テーブルによってサービス継承管理ＤＢ５００８が構築される。サービス継承管理テーブルでは、継承されるサービスのサービスＩＤ、及び継承するサービスのサービスＩＤが関連付けられて管理されている。サービス継承管理テーブルにおいて関連付けられているサービス間で、トピックに対するpub又はsubする権限が継承される。
図７Ｈは、サービス継承管理テーブルを示す概念図である。記憶部５０００には、サービス継承管理テーブルによってサービス継承管理ＤＢ５００８が構築される。サービス継承管理テーブルでは、継承されるサービスのサービスＩＤ、及び継承するサービスのサービスＩＤが関連付けられて管理されている。サービス継承管理テーブルにおいて関連付けられているサービス間で、トピックに対するpub又はsubする権限が継承される。
図１２Ａは、一実施形態に係るpub又はsubする権限を示す概念図である。各ユーザは、ユーザクライアント管理テーブルにおいて関連付けられていないクライアントからメッセージをpub又はsubする権限を有する。また、各クライアントは、クライアントサービス管理テーブルにおいて関連付けられているサービスを利用することができる。また、各サービスを利用することで、サービストピック管理テーブルにおいてサービスに関連付けられていない特定のトピックのメッセージをpub及びsubする権限が得られる。また、pub又はsubする権限は、サービス継承管理テーブルにおいて関連付けられているサービス間で継承される。このように、pub又はsubする権限をサービスと関連付けておくことで、サービス毎にプラットフォームを構築しなくても良くなるだけでなく、新たなサービスを提供開始するときに既存のサービスに対する権限を継承可能となる。
図１２Ｂは、比較例に係るpub又はsubする権限を示す概念図である。pub又はsubする権限がサービスと関連付けられていない比較例では、どのサービスを利用した場合でも、要求元は、要求に係るトピックをpub又はsubすることが可能となる。このため、サービス毎にプラットフォームを構築するか、共通のトピックが扱われるサービス毎にプラットフォームを構築する必要が生じるため、拡張性が低下する。
（セッション管理テーブル）
図７Ｉは、セッション管理テーブルを示す概念図である。記憶部５０００には、セッション管理テーブルによってセッション管理ＤＢ５０１４が構築される。後述するように、ユーザＩＤ及びクライアントＩＤによってログイン認証されると、端末１０と管理システム５０との間のセッションが確立される。また、端末１０は、サービスへのアクセスが認可される。セッション管理テーブルでは、ログイン認証に用いられる端末１０側のユーザＩＤ、クライアントＩＤ、認可されたサービスのサービスＩＤ、確立されたセッションを利用してsubするトピックＩＤが関連付けられて管理される。
図７Ｉは、セッション管理テーブルを示す概念図である。記憶部５０００には、セッション管理テーブルによってセッション管理ＤＢ５０１４が構築される。後述するように、ユーザＩＤ及びクライアントＩＤによってログイン認証されると、端末１０と管理システム５０との間のセッションが確立される。また、端末１０は、サービスへのアクセスが認可される。セッション管理テーブルでは、ログイン認証に用いられる端末１０側のユーザＩＤ、クライアントＩＤ、認可されたサービスのサービスＩＤ、確立されたセッションを利用してsubするトピックＩＤが関連付けられて管理される。
（管理システムの各機能構成）
次に、管理システム５０の各機能構成について詳細に説明する。なお、以下では、管理システム５０の各機能構成を説明するにあたって、図３に示されている各構成要素のうち、管理システム５０の各機能構成を実現させるための主な構成要素との関係も説明する。
次に、管理システム５０の各機能構成について詳細に説明する。なお、以下では、管理システム５０の各機能構成を説明するにあたって、図３に示されている各構成要素のうち、管理システム５０の各機能構成を実現させるための主な構成要素との関係も説明する。
送受信部５１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して各端末、装置又はシステムと各種データ（または情報）の送受信を行う。
トークン確認部５２は、ＣＰＵ５０１からの命令によって実現され、端末１０のログイン要求に含まれている認可トークンを確認する。
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)で暗号化される。
送受信部４１は、発行された認可トークンを認証結果に含めて端末１０へ送信する。端末１０の送受信部１１は、認証サーバによって送信された認可トークンを含む認証結果を受信する。続いて、端末１０の送受信部１１は受信した認可トークンを管理システム５０へ送信することにより、管理システム５０へログイン要求する（ステップＳ２８）。
管理システム５０の送受信部５１は、端末１０によって送信されたログイン要求を受信する。管理システム５０のトークン確認部５２は、ログイン要求に含まれる認可トークンを確認する（ステップＳ２９）。この場合、トークン確認部５２は、通信システム１で用いられる標準にしたがって、ログイン要求に含まれている認可トークンを解析する。トークン確認部５２は、解析の結果に応じて、認証サーバによる署名が正しいか否かを判断しても良い。認証サーバによる署名が正しいものではないと判断された場合、トークン確認部５２は、ログイン要求に含まれる認可トークンが改竄されていると判断して、認可に失敗する。
続いて、トークン確認部５２は、認可トークンに含まれている有効期限を確認することで、認可トークンの有効期限が切れているか否かを判断する。認可トークンの有効期限が切れていると判断された場合、トークン確認部５２は、認可トークンの期限切れにより認可に失敗する。
続いて、トークン確認部５２は、認可トークンに自管理システムに対応するサービス名が含まれているか否かを確認する。認可トークンに自管理システムに対応するサービス名が含まれていないと判断された場合、トークン確認部５２は、認可に失敗する。
トークン確認部５２が、認可トークンの署名、有効期限、及びサービスの確認のいずれかの過程で認可に失敗すると、送受信部５１は、端末１０へ認可に失敗した旨を示す認可結果情報を送信する。トークン確認部５２が、認可トークンの署名、有効期限、及びサービスのいずれもが正当なものであると判断した場合、認可トークンに示されているユーザ及びクライアントによるサービスの利用を認可する。ユーザ及びクライアントが認可されると、管理システム５０は、端末１０とのセッションを確立する（ステップＳ３０）。この場合、管理システム５０は、端末１０へ、認可に成功した旨を示す認可結果情報を送信する。
セッションが確立すると管理システム５０では、認可トークンに含まれているユーザＩＤ、クライアントＩＤ、及びサービスＩＤ、並びにクライアントのＩＰアドレス等を関連付けて記憶部１０００において管理する。これにより、相手側のクライアントが情報を送信する毎に管理システム５０へ、ユーザＩＤ、クライアントＩＤ、及びサービスＩＤを送信しなくても、管理システム５０では、端末１０が認証／認可要求で送信したユーザＩＤ、クライアントＩＤ、及びサービスＩＤを把握できるようになる。
上記のステップＳ２１乃至Ｓ３０の処理は、端末１０で起動するクライアントアプリ毎に実行される。例えば、カメラアプリ及びＯＳ２用テレビ会議アプリ等の各クライアントアプリは、それぞれ認証サーバ４０へ認証要求しても良い。管理システム５０が、各クライアントアプリの認証に成功した場合には、管理システム５０及び各クライアントアプリ間でそれぞれ別のセッションが同時に確立することになる。
続いて、図９を用いて端末１０間でメッセージをpub及びsubする処理について説明する。図９は、メッセージをpub及びsubする処理の一例を示すシーケンス図である。以下、複数の端末１０の一例として端末１０ａ及び端末１０ｂの間でメッセージをpub及びsubする処理について説明する。
まず、ユーザ"User1"のユーザＩＤ"U01"、クライアント「専用端末用テレビ会議アプリ」のクライアントＩＤ"C02"で認証され、サービス「テレビ会議サービス」へのアクセスが認可された端末１０ａが、トピック"video"に対してsub要求する処理について説明する。端末１０ａのsub要求部１６は、テレビ会議サービスにおける映像を受け取るため、sub要求を管理システム５０へ送信する（ステップＳ４１）。sub要求には、映像に関するトピック名"video"が含まれている。
管理システム５０の送受信部５１は、端末１０ａによって送信されたsub要求を受信する。管理システム５０のsub処理部５４は、端末１０ａの専用端末用テレビ会議アプリがテレビ会議サービスを利用してsub要求に係るメッセージをsubする権限を有するか否かを判断する（ステップＳ４２）。ステップＳ４２の処理について、図１０を用いて詳細に説明する。図１０は、メッセージをsubする権限を有するか判断する処理の一例を示したフロー図である。
記憶・読出部５９は、sub要求に含まれるトピック名に対応するトピックＩＤをトピック管理テーブルから取得する（ステップＳ４２−１）。例えば、sub要求に含まれるトピック名が"video"であれば、トピック管理テーブルからトピックＩＤ"T04"が取得される。
sub処理部５４は、クライアントサービス管理テーブルを参照して、sub要求元のクライアントのクライアントＩＤに関連付けられているサービスＩＤがあるか判断する（ステップＳ４２−２）。sub要求元のクライアントＩＤは、端末１０ａが先に管理システム５０へログインするときに、管理システム５０へ送信される認可トークンに含まれている。例えば、sub要求元のクライアント「専用端末用テレビ会議アプリ」のクライアントＩＤが"C02"である場合、クライアントサービス管理テーブルにこのクライアントＩＤに関連付けられているサービスＩＤがあると判断される。ステップＳ４２−２においてＮＯと判断された場合、ステップＳ４２−１４に進み、sub要求元のユーザ、クライアント、及びトピックの関係に応じたsub権限の判断を行う。このように、ステップＳ４２−２の判断を行うことで、サービスを利用してsubする処理と、サービスを利用せずにsubする処理を共通のプラットフォームで実現できるようになる。
ステップＳ４２−２においてＹＥＳと判断された場合、sub処理部５４は、sub要求元のユーザ、クライアント、利用するサービス、及びトピックの関係に応じたsub権限の判断を開始する。まず、sub処理部５４は、sub要求元のユーザのユーザＩＤ、及びsub要求元に対して認可されたサービスのサービスＩＤの組を検索キーとして、ユーザサービス管理テーブルを検索する（ステップＳ４２−３）。sub要求元のユーザのユーザＩＤ、及びsub要求元に対して認可されたサービスのサービスＩＤは、sub要求元が先に管理システム５０へログインするときに、管理システム５０へ送信される認可トークンに含まれている。なお、sub要求元のユーザのユーザＩＤが"U01"であり、認可されたサービスのサービスＩＤが"S02"である場合、ユーザサービス管理テーブルからはこれらの組に対応する権限情報"pub"が取得される。
sub処理部５４は、ステップＳ４２−３で権限情報"sub"又は"pubsub"が取得されたか判断する（ステップＳ４２−４）。権限情報"sub"又は"pubsub"が取得された場合（ステップＳ４２−４のＹＥＳ）、ステップＳ４２−７へ進み、継承されるサービスの確認を行う。
権限情報"sub"又は"pubsub"が取得されなかった場合（ステップＳ４２−４のＮＯ）、sub処理部５４は、sub要求元に対して認可されたサービスのサービスＩＤ、及びステップＳ４２−１で取得されたトピックＩＤの組を検索キーとして、サービストピック管理テーブルを検索する（ステップＳ４２−５）。例えば、sub要求元に対して認可されたサービスのサービスＩＤが"S02"、取得されたトピックＩＤが"T04"である場合、これらの組に対応する権限情報"pubsub"は取得されない。
sub処理部５４は、ステップＳ４２−５で権限情報"sub"又は"pubsub"が取得されたか判断する（ステップＳ４２−６）。権限情報"sub"又は"pubsub"が取得されなかった場合（ステップＳ４２−６のＮＯ）、ステップＳ４２−１４に進み、sub要求元のユーザ、クライアント、及びトピックの関係に応じたsub権限の判断を行う。
権限情報"sub"又は"pubsub"が取得された場合（ステップＳ４２−４，Ｓ４２−６のＹＥＳ）、sub処理部５４は、sub要求元に対して認可されたサービスのサービスＩＤを検索キーとしてサービス継承管理テーブルにおける継承するサービスのフィールドを検索する（ステップＳ４２−７）。
sub処理部５４は、ステップＳ４２−７で対応する継承されるサービスのサービスＩＤが取得されたか判断する（ステップＳ４２−８）。ステップＳ４２−８でＮＯと判断された場合、sub処理部５４は、sub要求元に対して継承されるサービスはないため、sub要求元にsub権限はないと判断する（ステップＳ４２−１３）。この場合、送受信部５１は、sub要求を拒否する旨を示す情報をsub要求元の端末１０ａへ送信して処理を終了する。
ステップＳ４２−８においてＹＥＳと判断された場合、sub要求元のユーザ、クライアント、継承されるサービス、及びトピックの関係に応じたsub権限の判断を開始する。まず、sub処理部５４は、sub要求元のユーザのユーザＩＤ、及びステップＳ４２−７で取得された継承されるサービスのサービスＩＤの組を検索キーとして、ユーザサービス管理テーブルを検索する（ステップＳ４２−９）。
sub処理部５４は、ステップＳ４２−９で権限情報"sub"又は"pubsub"が取得されたか判断する（ステップＳ４２−１０）。権限情報"sub"又は"pubsub"が取得された場合（ステップＳ４２−１０のＹＥＳ）、sub処理部５４は、sub要求元にsub権限はないと判断する（ステップＳ４２−１３）。この場合、送受信部５１は、sub要求を拒否する旨を示す情報をsub要求元の端末１０ａへ送信して処理を終了する。
権限情報"sub"又は"pubsub"が取得されなかった場合（ステップＳ４２−１０のＮＯ）、sub処理部５４は、ステップＳ４２−７で取得された継承されるサービスのサービスＩＤ、及びステップＳ４２−１で取得されたトピックＩＤの組を検索キーとして、サービストピック管理テーブルを検索する（ステップＳ４２−１１）。
sub処理部５４は、ステップＳ４２−１１で権限情報"sub"又は"pubsub"が取得されたか判断する（ステップＳ４２−１２）。権限情報"sub"又は"pubsub"が取得されなかった場合（ステップＳ４２−１２のＮＯ）、ステップＳ４２−１４に進み、sub要求元のユーザ、クライアント、及びトピックの関係に応じたsub権限の判断を行う。
権限情報"sub"又は"pubsub"が取得された場合（ステップＳ４２−１２のＹＥＳ）、sub処理部５４は、sub要求元にsub権限はないと判断する（ステップＳ４２−１３）。この場合、送受信部５１は、sub要求を拒否する旨を示す情報をsub要求元の端末１０ａへ送信して処理を終了する。
ステップＳ４２−２，Ｓ４２−６，Ｓ４２−１２でＮＯと判断された場合、sub処理部５４は、sub要求元のユーザのユーザＩＤ、sub要求元のクライアントのクライアントＩＤの組を検索キーとして、ユーザクライアント管理テーブルを検索する（ステップＳ４２−１４）。例えば、sub要求元のユーザのユーザＩＤ"U01"、sub要求元のクライアントのクライアントＩＤ"C02"である場合、ユーザクライアント管理テーブルからこれらの組に対応する権限情報"pub"が取得される。
sub処理部５４は、ステップＳ４２−１４で権限情報"sub"又は"pubsub"が取得されたか判断する（ステップＳ４２−１５）。権限情報"sub"又は"pubsub"が取得された場合（ステップＳ４２−１５のＹＥＳ）、sub処理部５４は、sub要求元にsub権限はないと判断する（ステップＳ４２−１３）。この場合、送受信部５１は、sub要求を拒否する旨を示す情報をsub要求元の端末１０ａへ送信して処理を終了する。
権限情報"sub"又は"pubsub"が取得されなかった場合（ステップＳ４２−１５のＮＯ）、sub処理部５４は、sub要求元のクライアントのクライアントＩＤ、ステップＳ４２−１で取得されたトピックのトピックＩＤの組を検索キーとして、クライアントトピック管理テーブルを検索する（ステップＳ４２−１６）。例えば、sub要求元のクライアントのクライアントＩＤ"C02"、取得されたトピックのトピックＩＤが"T04"である場合、クライアントトピック管理テーブルからこれらの組に対応する権限情報"pub"が取得される。
sub処理部５４は、ステップＳ４２−１６で権限情報"sub"又は"pubsub"が取得されたか判断する（ステップＳ４２−１７）。権限情報"sub"又は"pubsub"が取得された場合（ステップＳ４２−１７のＹＥＳ）、sub処理部５４は、sub要求元にsub権限はないと判断する（ステップＳ４２−１３）。この場合、送受信部５１は、sub要求を拒否する旨を示す情報をsub要求元の端末１０ａへ送信して処理を終了する。
権限情報"sub"又は"pubsub"が取得されなかった場合（ステップＳ４２−１７のＮＯ）、sub処理部５４は、sub要求元のユーザのユーザＩＤ、ステップＳ４２−１で取得されたトピックのトピックＩＤの組を検索キーとして、ユーザトピック管理テーブルを検索する（ステップＳ４２−１８）。例えば、sub要求元のユーザのユーザＩＤ"U01"、取得されたトピックのトピックＩＤが"T04"である場合、ユーザトピック管理テーブルからこれらの組に対応する権限情報"pub"が取得される。
sub処理部５４は、ステップＳ４２−１８で権限情報"sub"又は"pubsub"が取得されたか判断する（ステップＳ４２−１９）。権限情報"sub"又は"pubsub"が取得された場合（ステップＳ４２−１９のＹＥＳ）、sub処理部５４は、sub要求元にsub権限はないと判断する（ステップＳ４２−１３）。この場合、送受信部５１は、sub要求を拒否する旨を示す情報をsub要求元の端末１０ａへ送信して処理を終了する。
権限情報"sub"又は"pubsub"が取得されなかった場合（ステップＳ４２−１９のＮＯ）、sub処理部５４は、sub要求元はsub権限を有すると判断する（ステップＳ４２−２０）。
ステップＳ４２−２０において、sub要求元にsub権限はあると判断された場合、sub処理部５４は、sub要求元のユーザＩＤ、クライアントＩＤ、sub要求元に対して認可されたサービスのサービスＩＤ、及びsub要求に係るトピックのトピックＩＤをセッション管理テーブルに関連付けて登録する（ステップＳ４３）。
続いて、ユーザ"User2"のユーザＩＤ"U02"、クライアント「ＯＳ２用連携アプリ」のクライアントＩＤ"C05"で認証され、サービス「テレビ会議連携サービス」へのアクセスが認可された端末１０ｂが、トピック"video"に対してpub要求する処理について説明する。端末１０ｂのpub要求部１５は、テレビ会議サービスにおける映像を配信するため、pub要求を管理システム５０へ送信する（ステップＳ４４）。pub要求には、映像に関するトピック名"video"、及びメッセージとして自端末で撮像された映像の映像データが含まれている。
管理システム５０の送受信部５１は、端末１０ｂによって送信されたpub要求を受信する。管理システム５０のpub処理部５３は、端末１０ｂのＯＳ２用連携アプリがテレビ会議連携サービスを利用してpub要求に係るメッセージをpubする権限を有するか否かを判断する（ステップＳ４５）。ステップＳ４５の処理について、図１１を用いて詳細に説明する。図１１は、メッセージをpubする権限を有するか判断する処理の一例を示したフロー図である。
記憶・読出部５９は、pub要求に含まれるトピック名に対応するトピックＩＤをトピック管理テーブルから取得する（ステップＳ４５−１）。例えば、pub要求に含まれるトピック名が"video"であれば、トピック管理テーブルからトピックＩＤ"T04"が取得される。
pub処理部５３は、クライアントサービス管理テーブルを参照して、pub要求元のクライアントのクライアントＩＤに関連付けられているサービスＩＤがあるか判断する（ステップＳ４５−２）。pub要求元のクライアントＩＤは、端末１０ｂが先に管理システム５０へログインするときに、管理システム５０へ送信される認可トークンに含まれている。例えば、pub要求元のクライアント「ＯＳ２用連携アプリ」のクライアントＩＤが"C05"である場合、クライアントサービス管理テーブルにこのクライアントＩＤに関連付けられているサービスＩＤがあると判断される。なお、ステップＳ４５−２においてＮＯと判断された場合、ステップＳ４５−１４に進み、pub要求元のユーザ、クライアント、及びトピックの関係に応じたpub権限の判断を行う。このように、ステップＳ４５−２の判断を行うことで、サービスを利用してpubする処理と、サービスを利用せずにpubする処理を共通のプラットフォームで実現できるようになる。
ステップＳ４５−２においてＹＥＳと判断された場合、pub処理部５３は、pub要求元のユーザ、クライアント、利用するサービス、及びトピックの関係に応じたpub権限の判断を開始する。まず、pub処理部５３は、pub要求元のユーザのユーザＩＤ、及びpub要求元に対して認可されたサービスのサービスＩＤの組を検索キーとして、ユーザサービス管理テーブルを検索する（ステップＳ４５−３）。pub要求元のユーザのユーザＩＤ、及びpub要求元に対して認可されたサービスのサービスＩＤは、pub要求元が先に管理システム５０へログインするときに、管理システム５０へ送信される認可トークンに含まれている。例えば、pub要求元のユーザのユーザＩＤが"U02"であり、認可されたサービスのサービスＩＤが"S03"である場合、ユーザサービス管理テーブルからはこれらの組に対応する権限情報は取得されない。
pub処理部５３は、ステップＳ４５−３で権限情報"pub"又は"pubsub"が取得されたか判断する（ステップＳ４５−４）。権限情報"pub"又は"pubsub"が取得された場合（ステップＳ４５−４のＹＥＳ）、ステップＳ４５−７へ進み、継承されるサービスの確認を行う。
権限情報"pub"又は"pubsub"が取得されなかった場合（ステップＳ４５−４のＮＯ）、pub処理部５３は、pub要求元に対して認可されたサービスのサービスＩＤ、及びステップＳ４５−１で取得されたトピックＩＤの組を検索キーとして、サービストピック管理テーブルを検索する（ステップＳ４５−５）。なお、pub要求元に対して認可されたサービスのサービスＩＤが"S03"、取得されたトピックＩＤが"T04"である場合、これらの組に対応する権限情報"pubsub"が取得される。
pub処理部５３は、ステップＳ４５−５で対応する権限情報"pub"又は"pubsub"が取得されたか判断する（ステップＳ４５−６）。権限情報"pub"又は"pubsub"が取得されなかった場合（ステップＳ４５−６のＮＯ）、ステップＳ４５−１４に進み、pub要求元のユーザ、クライアント、及びトピックの関係に応じたpub権限の判断を行う。
権限情報"pub"又は"pubsub"が取得された場合（ステップＳ４５−４，Ｓ４５−６のＹＥＳ）、pub処理部５３は、pub要求元に対して認可されたサービスのサービスＩＤを検索キーとしてサービス継承管理テーブルにおける継承するサービスのフィールドを検索する（ステップＳ４５−７）。例えば、pub要求元に対して認可されたサービスのサービスＩＤ"S03"に対応する、継承されるサービスのサービスＩＤ"S02"が取得される。
pub処理部５３は、ステップＳ４５−７で対応する継承されるサービスのサービスＩＤが取得されたか判断する（ステップＳ４５−８）。ステップＳ４５−８でＮＯと判断された場合、pub処理部５３は、pub要求元に対して継承されるサービスはないため、pub要求元にpub権限はないと判断する（ステップＳ４５−１３）。この場合、送受信部５１は、pub要求を拒否する旨を示す情報をpub要求元の端末１０ｂへ送信して処理を終了する。
ステップＳ４５−８においてＹＥＳと判断された場合、pub要求元のユーザ、クライアント、継承されるサービス、及びトピックの関係に応じたpub権限の判断を開始する。まず、pub処理部５３は、pub要求元のユーザのユーザＩＤ、及びステップＳ４５−７で取得された継承されるサービスのサービスＩＤの組を検索キーとして、ユーザサービス管理テーブルを検索する（ステップＳ４５−９）。pub要求元のユーザＩＤが"U02"、継承されるサービスのサービスＩＤが"S02"である場合、ユーザサービス管理テーブルからはこれらの組に対応する権限情報"sub"が取得される。
pub処理部５３は、ステップＳ４５−９で権限情報"pub"又は"pubsub"が取得されたか判断する（ステップＳ４５−１０）。権限情報"pub"又は"pubsub"が取得された場合（ステップＳ４５−１０のＹＥＳ）、pub処理部５３は、pub要求元にpub権限はないと判断する（ステップＳ４５−１３）。この場合、送受信部５１は、pub要求を拒否する旨を示す情報をpub要求元の端末１０ｂへ送信して処理を終了する。
権限情報"pub"又は"pubsub"が取得されなかった場合（ステップＳ４５−１０のＮＯ）、pub処理部５３は、ステップＳ４５−７で取得された継承されるサービスのサービスＩＤ、及びステップＳ４５−１で取得されたトピックＩＤの組を検索キーとして、サービストピック管理テーブルを検索する（ステップＳ４５−１１）。継承されるサービスのサービスＩＤが"S02"、取得されたトピックＩＤが"T04"である場合、サービストピック管理テーブルからはこれらの組に対応する権限情報は取得されない。
pub処理部５３は、ステップＳ４５−１１で権限情報"pub"又は"pubsub"が取得されたか判断する（ステップＳ４５−１２）。権限情報"pub"又は"pubsub"が取得されなかった場合（ステップＳ４５−１２のＮＯ）、ステップＳ４５−１４に進み、pub要求元のユーザ、クライアント、及びトピックの関係に応じたpub権限の判断を行う。
権限情報"pub"又は"pubsub"が取得された場合（ステップＳ４５−１２のＹＥＳ）、pub処理部５３は、pub要求元にpub権限はないと判断する（ステップＳ４５−１３）。この場合、送受信部５１は、pub要求を拒否する旨を示す情報をpub要求元の端末１０ｂへ送信して処理を終了する。
ステップＳ４５−２，Ｓ４５−６，Ｓ４５−１２でＮＯと判断された場合、pub処理部５３は、pub要求元のユーザのユーザＩＤ、pub要求元のクライアントのクライアントＩＤの組を検索キーとして、ユーザクライアント管理テーブルを検索する（ステップＳ４５−１４）。例えば、pub要求元のユーザのユーザＩＤ"U02"、pub要求元のクライアントのクライアントＩＤ"C05"である場合、ユーザクライアント管理テーブルからこれらの組に対応する権限情報"sub"が取得される。
pub処理部５３は、ステップＳ４５−１４で権限情報"pub"又は"pubsub"が取得されたか判断する（ステップＳ４５−１５）。権限情報"pub"又は"pubsub"が取得された場合（ステップＳ４５−１５のＹＥＳ）、pub処理部５３は、pub要求元にpub権限はないと判断する（ステップＳ４５−１３）。この場合、送受信部５１は、pub要求を拒否する旨を示す情報をpub要求元の端末１０ｂへ送信して処理を終了する。
権限情報"pub"又は"pubsub"が取得されなかった場合（ステップＳ４５−１５のＮＯ）、pub処理部５３は、pub要求元のクライアントのクライアントＩＤ、ステップＳ４５−１で取得されたトピックのトピックＩＤの組を検索キーとして、クライアントトピック管理テーブルを検索する（ステップＳ４５−１６）。例えば、pub要求元のクライアントのクライアントＩＤ"C05"、取得されたトピックのトピックＩＤが"T04"である場合、クライアントトピック管理テーブルからこれらの組に対応する権限情報は取得されない。
pub処理部５３は、ステップＳ４５−１６で権限情報"pub"又は"pubsub"が取得されたか判断する（ステップＳ４５−１７）。権限情報"pub"又は"pubsub"が取得された場合（ステップＳ４５−１７のＹＥＳ）、pub処理部５３は、pub要求元にpub権限はないと判断する（ステップＳ４５−１３）。この場合、送受信部５１は、pub要求を拒否する旨を示す情報をpub要求元の端末１０ｂへ送信して処理を終了する。
権限情報"pub"又は"pubsub"が取得されなかった場合（ステップＳ４５−１７のＮＯ）、pub処理部５３は、pub要求元のユーザのユーザＩＤ、ステップＳ４５−１で取得されたトピックのトピックＩＤの組を検索キーとして、ユーザトピック管理テーブルを検索する（ステップＳ４５−１８）。例えば、pub要求元のユーザのユーザＩＤ"U02"、取得されたトピックのトピックＩＤが"T04"である場合、ユーザトピック管理テーブルからこれらの組に対応する権限情報は取得されない。
pub処理部５３は、ステップＳ４５−１８で権限情報"pub"又は"pubsub"が取得されたか判断する（ステップＳ４５−１９）。権限情報"pub"又は"pubsub"が取得された場合（ステップＳ４５−１９のＹＥＳ）、pub処理部５３は、pub要求元にpub権限はないと判断する（ステップＳ４５−１３）。この場合、送受信部５１は、pub要求を拒否する旨を示す情報をpub要求元の端末１０ｂへ送信して処理を終了する。
権限情報"pub"又は"pubsub"が取得されなかった場合（ステップＳ４５−１９のＮＯ）、pub処理部５３は、pub要求元はpub権限を有すると判断する（ステップＳ４５−２０）。
ステップＳ４５−２０においてpub要求元はpub権限を有すると判断された場合、pub処理部５３は、pub要求に係るトピックのトピックＩＤを検索キーとして、セッション管理テーブルを検索し、対応するユーザＩＤ及びクライアントＩＤ、及びサービスＩＤを取得する（ステップＳ４６）。例えば、pub要求に係るトピックのトピックＩＤが"T04"である場合、セッション管理テーブルからは、ユーザＩＤ"U01"、クライアントＩＤ"C02"、及びサービスＩＤ"S02"が取得される。これにより、pub処理部５３は、ユーザＩＤ"U01"、クライアントＩＤ"C02"で認証され、サービスＩＤ"S02"のサービスの利用が認可された端末１０ａをメッセージの配信先として特定する。
送受信部５１は、pub要求に係るメッセージ、即ち、映像データを、特定された端末１０ａへ送信する。これにより、端末１０ａは、端末１０ｂが送信した映像データをメッセージとして受信することができる。
管理システム５０は、pub要求に係るメッセージを記憶部５０００において管理しても良い。これにより、pub要求時には管理システム５０と接続していないクライアントが、後に管理システム５０と接続したときに、管理システム５０は、記憶部５０００において管理されているメッセージをクライアントに送信することもできる。
＜＜本実施形態の主な効果＞＞
続いて、上記実施形態の主な効果を説明する。上記実施形態の通信制御方法によると、管理システム５０の送受信部５１（受付手段の一例）は、ＯＳ２用連携アプリ（第１のクライアントの一例）で認証された端末１０ｂ（第１の通信端末の一例）からトピック"video"（所定の属性の一例）に対するメッセージ（情報の一例）のpub要求（配信の要求の一例）を受け付ける一方で、専用端末用テレビ会議アプリ（第２のクライアントの一例）で認証された端末１０ａ（第２の通信端末の一例）からトピック"video"に対するメッセージのsub要求（受信の要求の一例）を受け付ける（受付処理の一例）。なお、トピックは、PubSubモデルにおいて、subする情報を特定するため、予め定められた属性である。また、メッセージは、PubSubモデルにおいて、pub又はsubすることが可能な情報であり、テキストの他、画像データ、映像データ、音データ等のコンテンツデータも含まれる。管理システム５０のpub処理部５３及びsub処理部５４（配信制御手段の一例）は、ＯＳ２用連携アプリによって利用されるテレビ会議連携サービス（第１のサービスの一例）、又は専用端末用テレビ会議アプリによって利用されるテレビ会議サービス（第２のサービスの一例）が、トピック"video"に対応付けられているかに基づいて、端末１０ａへのトピック"video"のメッセージの配信を制御する（配信制御処理の一例）。上記実施形態の通信システム１によると、クライアントが利用するサービス毎にメッセージへのアクセスを制御することができる。
続いて、上記実施形態の主な効果を説明する。上記実施形態の通信制御方法によると、管理システム５０の送受信部５１（受付手段の一例）は、ＯＳ２用連携アプリ（第１のクライアントの一例）で認証された端末１０ｂ（第１の通信端末の一例）からトピック"video"（所定の属性の一例）に対するメッセージ（情報の一例）のpub要求（配信の要求の一例）を受け付ける一方で、専用端末用テレビ会議アプリ（第２のクライアントの一例）で認証された端末１０ａ（第２の通信端末の一例）からトピック"video"に対するメッセージのsub要求（受信の要求の一例）を受け付ける（受付処理の一例）。なお、トピックは、PubSubモデルにおいて、subする情報を特定するため、予め定められた属性である。また、メッセージは、PubSubモデルにおいて、pub又はsubすることが可能な情報であり、テキストの他、画像データ、映像データ、音データ等のコンテンツデータも含まれる。管理システム５０のpub処理部５３及びsub処理部５４（配信制御手段の一例）は、ＯＳ２用連携アプリによって利用されるテレビ会議連携サービス（第１のサービスの一例）、又は専用端末用テレビ会議アプリによって利用されるテレビ会議サービス（第２のサービスの一例）が、トピック"video"に対応付けられているかに基づいて、端末１０ａへのトピック"video"のメッセージの配信を制御する（配信制御処理の一例）。上記実施形態の通信システム１によると、クライアントが利用するサービス毎にメッセージへのアクセスを制御することができる。
管理システム５０の送受信部５１は、ユーザＩＤ"U02"（第１のアカウントの一例）を用いて認証された端末１０ｂからトピック"video"に対するメッセージのpub要求を受け付ける一方で、ユーザＩＤ"U01"（第２のアカウントの一例）を用いて認証された端末１０ａからトピック"video"に対するメッセージのsub要求を受け付ける。なお、アカウントはサービス等を利用する権限であって、通信システム１では、ユーザＩＤをアカウントとして用いている。管理システム５０のpub処理部５３及びsub処理部５４は、ユーザＩＤ"U02"がテレビ会議サービスに対応付けられているか、又は、ユーザＩＤ"U01"がテレビ会議連携サービスに対応付けられているかに基づいて、端末１０ａへのトピック"video"のメッセージの配信を制御する。上記実施形態の通信システム１によると、更に、ユーザが利用するサービス毎にメッセージへのアクセスを制御することができる。
テレビ会議連携サービスがテレビ会議サービス（第３のサービスの一例）を継承するサービスとして対応付けられている場合、管理システム５０のpub処理部５３及びsub処理部５４は、トピック"video"がテレビ会議サービスに対応付けられているかに基づいて、端末１０ａへのトピック"video"のメッセージの配信を制御する。上記実施形態の通信システム１によると、所定のサービスを利用するときに設定されるpub権限又はsub権限を特定のサービスに継承させることができる。
管理システム５０のpub処理部５３及びsub処理部５４は、ユーザＩＤ"U02"がテレビ会議サービスに対応付けられているかに基づいて、端末１０ａへのトピック"video"のメッセージの配信を制御する。上記実施形態の通信システム１によると、更に、ユーザが利用するサービス毎にメッセージへのアクセスを制御することができる。
管理システム５０のpub処理部５３及びsub処理部５４は、トピック"video"がテレビ会議サービス又はテレビ会議連携サービスに対応付けられている場合には、端末１０ａへトピック"video"のメッセージの配信しないように制御し、トピック"video"がテレビ会議サービス及びテレビ会議連携サービスのいずれにも対応付けられていない場合には、端末１０ａへのトピック"video"のメッセージの配信するように制御する。これにより、管理システム５０は、pub要求元、及びsub要求元が利用するサービスに応じて適切にメッセージを配信できるようになる。
管理システム５０のサービストピック管理ＤＢ５００７（属性管理手段の一例）は、トピックのトピックＩＤ（属性情報の一例）、及びサービスのサービスＩＤ（サービス情報の一例）を関連付けて管理する。管理システム５０のpub処理部５３及びsub処理部５４は、サービストピック管理ＤＢ５００７において、所定のトピックのトピックＩＤに関連付けられて、pub要求元、又はsub要求元が利用する各サービスのサービスＩＤが管理されているかに基づいて、sub要求元への所定のトピックのメッセージの配信を制御する。これにより、通信システム１は、クライアントが利用するサービス毎にメッセージへのアクセスを制御することができる。
＜＜実施形態の補足＞＞
端末１０、認証サーバ４０、及び管理システム５０用の各プログラムは、インストール可能な形式又は実行可能な形式のファイルによって、コンピュータで読み取り可能な記録媒体（記録メディア１０６等）に記録されて流通されるようにしてもよい。また、上記記録媒体の他の例として、ＣＤ−Ｒ(Compact Disc Recordable)、ＤＶＤ(Digital Versatile Disk)、ブルーレイディスク等が挙げられる。
端末１０、認証サーバ４０、及び管理システム５０用の各プログラムは、インストール可能な形式又は実行可能な形式のファイルによって、コンピュータで読み取り可能な記録媒体（記録メディア１０６等）に記録されて流通されるようにしてもよい。また、上記記録媒体の他の例として、ＣＤ−Ｒ(Compact Disc Recordable)、ＤＶＤ(Digital Versatile Disk)、ブルーレイディスク等が挙げられる。
また、上記実施形態の各プログラムが記憶されたＣＤ−ＲＯＭ等の記録媒体、並びに、これらプログラムが記憶されたＨＤ５０４は、プログラム製品(Program Product)として、国内又は国外へ提供されることができる。
また、上記実施形態における端末１０、認証サーバ４０、及び管理システム５０は、単一のコンピュータによって構築されてもよいし、各部（機能又は手段）を分割して任意に割り当てられた複数のコンピュータによって構築されていてもよい。また、認証サーバ４０及び管理システム５０は、単一のコンピュータによって構築されていても良い。
１ 通信システム
２ 通信ネットワーク
１０ 端末
１１ 送受信部
１２ 操作入力受付部
１３ 表示制御部
１４ 認証要求部
１５ pub要求部
１６ sub要求部
１９ 記憶・読出部
４０ 認証サーバ
４１ 送受信部
４２ ユーザ認証部
４３ クライアント認証部
４４ 認可部
４５ トークン発行部
４９ 記憶・読出部
５０ 管理システム
５１ 送受信部
５２ トークン確認部
５３ pub処理部
５４ sub処理部
５９ 記憶・読出部
１０００ 記憶部
４０００ 記憶部
４００１ ユーザ管理ＤＢ
４００２ クライアント管理ＤＢ
４００３ サービス管理ＤＢ
４００４ サービス認可管理ＤＢ
５０００ 記憶部
５００１ トピック管理ＤＢ
５００２ ユーザトピック管理ＤＢ
５００３ ユーザサービス管理ＤＢ
５００４ ユーザクライアント管理ＤＢ
５００５ クライアントトピック管理ＤＢ
５００６ クライアントサービス管理ＤＢ
５００７ サービストピック管理ＤＢ
５００８ サービス継承管理ＤＢ
５０１４ セッション管理ＤＢ
２ 通信ネットワーク
１０ 端末
１１ 送受信部
１２ 操作入力受付部
１３ 表示制御部
１４ 認証要求部
１５ pub要求部
１６ sub要求部
１９ 記憶・読出部
４０ 認証サーバ
４１ 送受信部
４２ ユーザ認証部
４３ クライアント認証部
４４ 認可部
４５ トークン発行部
４９ 記憶・読出部
５０ 管理システム
５１ 送受信部
５２ トークン確認部
５３ pub処理部
５４ sub処理部
５９ 記憶・読出部
１０００ 記憶部
４０００ 記憶部
４００１ ユーザ管理ＤＢ
４００２ クライアント管理ＤＢ
４００３ サービス管理ＤＢ
４００４ サービス認可管理ＤＢ
５０００ 記憶部
５００１ トピック管理ＤＢ
５００２ ユーザトピック管理ＤＢ
５００３ ユーザサービス管理ＤＢ
５００４ ユーザクライアント管理ＤＢ
５００５ クライアントトピック管理ＤＢ
５００６ クライアントサービス管理ＤＢ
５００７ サービストピック管理ＤＢ
５００８ サービス継承管理ＤＢ
５０１４ セッション管理ＤＢ
Claims (10)
- 所定の属性の情報を配信する要求を、第１のクライアントで認証された第１の通信端末から受け付ける一方で、前記所定の属性の情報を受信する要求を、第２のクライアントで認証された第２の通信端末から受け付ける受付手段と、
前記第１のクライアントによって利用される第１のサービス又は前記第２のクライアントによって利用される第２のサービスが、前記所定の属性に対応付けられているかに基づいて、前記第２の通信端末への前記所定の属性の情報の配信を制御する配信制御手段と、
を有することを特徴とする管理システム。 - 前記受付手段は、前記所定の属性の情報を配信する要求を、第１のアカウントで認証された前記第１の通信端末から受け付ける一方で、前記所定の属性の情報を受信する要求を、第２のアカウントで認証された前記第２の通信端末から受け付け、
前記配信制御手段は、前記第１のアカウントが前記第１のサービスに対応付けられているか、又は、前記第２のアカウントが前記第２のサービスに対応付けられているかに基づいて、前記第２の通信端末への前記所定の属性の情報の配信を制御することを特徴とする請求項１に記載の管理システム。 - 前記配信制御手段は、前記第１のサービスが第３のサービスに対応付けられている場合に、前記第３のサービスが前記所定の属性に対応付けられているかに基づいて、前記第２の通信端末への前記所定の属性の情報の配信を制御することを特徴とする請求項２に記載の管理システム。
- 前記配信制御手段は、前記第１のアカウントが前記第３のサービスに対応付けられているかに基づいて、前記第２の通信端末への前記所定の属性の情報の配信を制御することを特徴とする請求項３に記載の管理システム。
- 前記配信制御手段は、前記第１のサービス又は前記第２のサービスが、前記所定の属性に対応付けられている場合には、前記第２の通信端末へ前記所定の属性の情報を配信しないように制御し、前記第１のサービス及び前記第２のサービスが、いずれも前記所定の属性に対応付けられていない場合には、前記第２の通信端末へ前記所定の属性の情報を配信するように制御することを特徴とする請求項１乃至４のいずれか一項に記載の管理システム。
- 属性を示す属性情報、及びサービスを示すサービス情報を関連付けて管理する属性管理手段を有しており、
前記配信制御手段は、前記属性管理手段において、前記所定の属性を示す属性情報に関連付けられて前記第１のサービスを示すサービス情報、又は第２のサービスを示すサービス情報がそれぞれ管理されているかに基づいて、前記第２の通信端末への前記所定の属性の情報の配信を制御することを特徴とする請求項１乃至５のいずれか一項に記載の管理システム。 - 請求項１乃至５のいずれか一項に記載の管理システムと、
前記第１の通信端末と、
前記第２の通信端末と、
を有することを特徴とする通信システム。 - 管理システムが、
所定の属性の情報を配信する要求を、第１のクライアントで認証された第１の通信端末から受け付ける一方で、前記所定の属性の情報を受信する要求を、第２のクライアントで認証された第２の通信端末から受け付ける受付処理と、
前記第１のクライアントによって利用される第１のサービス又は前記第２のクライアントによって利用される第２のサービスが、前記所定の属性に対応付けられているかに基づいて、前記第２の通信端末への前記所定の属性の情報の配信を制御する配信制御処理と、
を実行することを特徴とする通信制御方法。 - 前記第１の通信端末が、
前記第１のクライアントで認証されてから前記所定の属性の情報を配信する要求を前記管理システムへ送信する処理を実行し、
前記第２の通信端末が、
前記第２のクライアントで認証されてから前記所定の属性の情報を受信する要求を前記管理システムへ送信する処理を実行する
ことを特徴とする請求項８に記載の通信制御方法。 - 管理システムに、
所定の属性の情報を配信する要求を、第１のクライアントで認証された第１の通信端末から受け付ける一方で、前記所定の属性の情報を受信する要求を、第２のクライアントで認証された第２の通信端末から受け付ける受付処理と、
前記第１のクライアントによって利用される第１のサービス又は前記第２のクライアントによって利用される第２のサービスが、前記所定の属性に対応付けられているかに基づいて、前記第２の通信端末への前記所定の属性の情報の配信を制御する配信制御処理と、
を実行させることを特徴とするプログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015229814A JP2017098780A (ja) | 2015-11-25 | 2015-11-25 | 管理システム、通信システム、通信制御方法、及びプログラム |
| US15/341,349 US10498716B2 (en) | 2015-11-25 | 2016-11-02 | Management system, communication control method, and communication system |
| EP16199428.0A EP3174265B1 (en) | 2015-11-25 | 2016-11-18 | Management system, communication control method, and communication system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015229814A JP2017098780A (ja) | 2015-11-25 | 2015-11-25 | 管理システム、通信システム、通信制御方法、及びプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2017098780A true JP2017098780A (ja) | 2017-06-01 |
Family
ID=58803825
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015229814A Pending JP2017098780A (ja) | 2015-11-25 | 2015-11-25 | 管理システム、通信システム、通信制御方法、及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2017098780A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPWO2017170176A1 (ja) * | 2016-03-28 | 2019-02-14 | 株式会社リコー | 情報送信システム、情報送信方法、及びプログラム |
| JP2020135199A (ja) * | 2019-02-15 | 2020-08-31 | 富士電機株式会社 | 機器制御システム及び機器制御方法 |
| JP7508818B2 (ja) | 2020-03-18 | 2024-07-02 | 富士電機株式会社 | 機器制御システム及び機器制御方法 |
-
2015
- 2015-11-25 JP JP2015229814A patent/JP2017098780A/ja active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPWO2017170176A1 (ja) * | 2016-03-28 | 2019-02-14 | 株式会社リコー | 情報送信システム、情報送信方法、及びプログラム |
| JP2020135199A (ja) * | 2019-02-15 | 2020-08-31 | 富士電機株式会社 | 機器制御システム及び機器制御方法 |
| JP7508818B2 (ja) | 2020-03-18 | 2024-07-02 | 富士電機株式会社 | 機器制御システム及び機器制御方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2017068596A (ja) | 管理システム、通信システム、送信制御方法、及びプログラム | |
| US10778455B2 (en) | Conference system, information transmission method, and storage medium | |
| US10498716B2 (en) | Management system, communication control method, and communication system | |
| US10681094B2 (en) | Control system, communication control method, and program product | |
| JP2017091369A (ja) | 管理システム、管理方法、及びプログラム | |
| JP6724431B2 (ja) | 通信システム、情報送信方法、及びプログラム | |
| JP2014179806A (ja) | 通信システム、通信管理装置、及びプログラム | |
| CN106233267B (zh) | 访问管理系统、通信系统、记录介质和访问管理方法 | |
| JP2017097652A (ja) | 管理システム、通信システム、通信制御方法、及びプログラム | |
| EP3261317B1 (en) | Authentication system, communication system, and authentication and authorization method | |
| JP6107977B2 (ja) | アクセス制御装置、通信システム、プログラム、及びアクセス制御方法 | |
| US20170339135A1 (en) | Authentication system, communication system, and authentication method | |
| JP6724423B2 (ja) | 通信端末、通信システム、出力方法、及びプログラム | |
| EP3151481B1 (en) | Communication terminal, communication system, and output method | |
| JP2017098780A (ja) | 管理システム、通信システム、通信制御方法、及びプログラム | |
| US10728254B2 (en) | Management system, communication system, and management method | |
| JP2017211769A (ja) | 管理システム、通信システム、認可方法、及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20180209 |