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