JP2017068596A - 管理システム、通信システム、送信制御方法、及びプログラム - Google Patents

Abstract

【課題】クライアントが、サーバへアクセスしたときに、サーバは、クライアントの要求にかかる属性の情報をクライアントへ送信するPubSub（メッセージの出版、メッセージの購読）モデルにおいて、複数のクライアントがサーバへアクセスするときに、サーバがクライアント毎に取得可能な情報を適切に振り分けることができる、管理システムを提供する。【解決手段】管理システム５０の送受信部は、所定の属性の情報を受信する。管理システム５０のpub処理部及びsub処理部は、所定の属性が、所定のクライアントに対応付けられている場合には、所定のクライアントで認証された端末１０へ、送受信部によって受信された情報を送信するように制御する。【選択図】図１

Description

本発明は、管理システム、通信システム、送信制御方法、及びプログラムに関する。

近年、当事者の移動の経費や時間を削減する要請等に伴い、インターネットや専用線等の通信ネットワークを介して通話や会議等を行う通信システムが普及している。このような通信システムでは、通信端末間で通信を開始すると、画像データ及び音データ等のコンテンツデータの送受信が行われ、当事者間のコミュニケーションを実現する。また、通信端末間でコンテンツデータを送信する方法として、出版−購読モデル（Publish-Subscribeモデル、以下、PubSubモデルと記載する）が知られている。

例えば、特許文献１には、アプリケーション・プログラムによって生成されたログ・データをアプリケーション・プログラムのローカルに所在する第１のデータ処理システムのメモリに保存し、第１のデータ処理システム上で実行されるパブリッシャ・プログラムによって実施される、新たに保存されたログ・データをメモリからキャプチャし、キャプチャされたログ・データを一連のパブリケーションとしてパブリッシュ／サブスクライブ・マッチング・エンジンを含む第２のデータ処理システムに繰り返し送信するリモート監視用のシステムが開示されている。

PubSubモデルによると、クライアントが、サーバへアクセスしたときに、サーバは、クライアントの要求にかかる属性の情報をクライアントへ送信する。しかしながら、複数のクライアントがサーバへアクセスするときに、サーバはクライアント毎に取得可能な情報を適切に振り分けることができなくなるという課題が生じる。

請求項１に係る発明の管理システムは、所定の属性の情報を受信する受信手段と、前記所定の属性が、所定のクライアントに対応付けられている場合には、前記所定のクライアントで認証された通信端末へ、前記受信手段によって受信された前記情報を送信するように制御する制御手段と、を有することを特徴とする。

以上説明したように本発明によれば、複数のクライアントが管理システムへアクセスするときに、サーバはクライアント毎に取得可能な情報を適切に振り分けられるようになるという効果を奏する。

本発明の一実施形態に係る通信システムの概略図である。 一実施形態に係る端末のハードウェア構成図である。 一実施形態に係る管理システムのハードウェア構成図である。 一実施形態に係る端末のソフトウェア構成図である。 一実施形態に係る端末、認証サーバ、及び管理システムの各機能ブロック図である。 認証サーバが管理する各管理テーブルを示す概念図である。 管理システムが管理する各管理テーブルを示す概念図である。 一実施形態における認証処理を示すシーケンス図である。 メッセージをpub及びsubする処理の一例を示すシーケンス図である。 メッセージをsubする権限を有するか否かを判断する処理の一例を示したフロー図である。 メッセージをpubする権限を有するか否かを判断する処理の一例を示したフロー図である。 実施形態の変形例に係る通信システムの概略図である。

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

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

管理システム５０は、出版−購読（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要求部１５は、クライアントアプリに従ったＣＰＵ１０１からの命令によって実現され、管理システム５０に対してメッセージのpub要求をする。なお、クライアントアプリがsubに対応する一方でpubには対応していない場合、端末１０においてpub要求部１５は生成されない。また、端末１０においてpubに対応した複数のクライアントアプリがインストールされている場合、端末１０には、起動したクライアントアプリ毎にpub要求部１５が生成される。

sub要求部１６は、クライアントアプリに従ったＣＰＵ１０１からの命令によって実現され、管理システム５０に対してメッセージのsub要求をする。なお、クライアントアプリがpubに対応する一方でsubには対応していない場合、端末１０においてsub要求部１６は生成されない。また、端末１０においてsubに対応した複数のクライアントアプリがインストールされている場合、端末１０には、起動したクライアントアプリ毎にsub要求部１６が生成される。

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

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

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

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

なお、chatアプリは、複数のユーザ間でメッセージを交換するためのクライアントアプリである。ログアプリは、端末１０が、管理システム５０に対して端末１０のログをメッセージとしてpubすることを要求するためのクライアントアプリである。ログ管理アプリは、管理システム５０に対して端末１０のログをメッセージとしてsubすることを要求するためのクライアントアプリである。なお、ログ管理アプリは、管理システム５０に対してsub要求するクライアントアプリであるが、ログアプリからログ管理要求を受けるサーバアプリでもある。監視カメラアプリは、端末１０が、管理システム５０に対して撮像画像の画像データをメッセージとしてpubすることを要求するためのクライアントアプリである。監視センターアプリは、管理システム５０に対して撮像画像の画像データをメッセージとしてsubすることを要求するためのクライアントアプリである。なお、監視センターアプリは、管理システム５０に対してsub要求するクライアントアプリであるが、監視アプリから撮像画像の管理要求を受けるサーバアプリでもある。

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

（サービス認可管理テーブル）
図６（Ｄ）は、サービス認可管理テーブルを示す概念図である。記憶部４０００には、サービス認可管理テーブルによってサービス認可管理ＤＢ４００４が構築される。サービス認可管理テーブルでは、クライアントＩＤ毎に、サービスＩＤが関連付けられて管理されている。これにより、サービス認可管理テーブルは、どのクライアントがどのサービスにアクセスして利用することができるかを管理することができる。図６（Ｄ）のサービス認可管理テーブルによれば、クライアントＩＤ「Ｃ０１」で識別されるchatアプリは、サービスＩＤ「Ｓ０１」で識別される伝送管理システム、すなわち、管理システム５０にアクセスして利用することができることを示す。

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

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

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

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

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

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

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

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

（クライアント認可管理テーブル）
図７（Ｂ）は、クライアント認可管理テーブルを示す概念図である。記憶部５０００には、クライアント認可管理テーブルによってクライアント認可管理ＤＢ５００２が構築される。クライアント認可管理テーブルでは、トピックＩＤ毎に、クライアント名、及びpub又はsubする権限を有するか否かを示す権限情報が関連付けられて管理されている。

図７（Ｂ）のクライアント認可管理テーブルにおいて、ログアプリは、トピックＩＤ「Ｔ０１」で識別されるトピック"device_log"に関連付けられるメッセージをpubする権限を有しているが、subする権限を有していないことが示されている。同様に、クライアント認可管理テーブルにおいて、ログ管理アプリは、トピックＩＤ「Ｔ０１」で識別されるトピック"device_log"に関連付けられるメッセージをsubする権限を有しているが、pubする権限を有していないことが示されている。また、図７（Ｂ）のクライアント認可管理テーブルにおいて、chatアプリは、トピックＩＤ「Ｔ０２」で識別される掲示板用のトピック"bulletin_board"に関連付けられるメッセージをpub及びsubする権限を有し、トピックＩＤ「Ｔ０３，Ｔ０４」で識別されるユーザａ，ｂ宛のメッセージをpubする権限を有しているがsubする権限を有していないことが示されている。

管理システム５０のようにPubSubモデルにおいてクライアントからのメッセージの仲介を行うサーバをブローカーと言う。例えば、ログ管理アプリ及びchatアプリが従来のブローカーにアクセスしたときに、ブローカーは、chatアプリに対して、ログ管理アプリ用のトピックのメッセージを送信したり、ログ管理アプリに対してchatアプリ用のトピックのメッセージを送信したりし得る。このため、従来は、クライアント毎にブローカーを設ける必要があり、拡張性が低かった。これに対して、管理システム５０は、クライアント認可管理テーブルを有することで、複数のクライアントが管理システム５０と接続する場合でも、クライアント毎に適切なメッセージを送信できるようになる。

（ユーザ認可管理テーブル）
図７（Ｃ）は、ユーザ認可管理テーブルを示す概念図である。記憶部５０００には、ユーザ認可管理テーブルによってユーザ認可管理ＤＢ５００３が構築される。ユーザ認可管理テーブルでは、トピックＩＤ毎に、ユーザ名、クライアント名、及びpub又はsubする権限を有するか否かを示す権限情報が関連付けられて管理されている。図７（Ｃ）のユーザ認可管理テーブルにより、ユーザａで認証され、chatアプリで認証された端末１０が、トピックＩＤ「０３」によって識別される"message_to/a"に関連付けられるメッセージをsubする権限を有することが示されている。ユーザ認可管理テーブルを用いることで、ユーザａが利用するchatアプリだけが、"message_to/a"に関連付けられるメッセージをsubできるようになる。

（セッション管理テーブル）
図７（Ｄ）は、セッション管理テーブルを示す概念図である。記憶部５０００には、セッション管理テーブルによってセッション管理ＤＢ５００４が構築される。セッション管理テーブルでは、ユーザ名、クライアント名、及びトピックＩＤが関連付けられて管理されている。セッション管理テーブルは、管理システム５０に接続中のクライアントアプリがどのユーザによって使用され、どのトピックのメッセージをsubしているかを示す。これにより、管理システム５０は、メッセージを受信したときに、どのクライアントアプリにどのメッセージを送信すれば良いかを判断することができる。例えば、管理システム５０は、トピックＩＤ「Ｔ０２」で識別されるトピック"bulletin_board"に関連付けられたメッセージのpubを受け付けたとき、ユーザａ，ｂが利用するchatアプリにこのメッセージを送信し、ユーザａが利用するログ管理アプリや監視カメラアプリには送信しなくても良いことを判断できる。

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

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

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

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する処理の一例を示すシーケンス図である。以下、複数の端末１０の一例として端末１０ａ及び端末１０ｂの間でメッセージをpub及びsubする処理について説明する。

以下、管理システム５０側でのユーザａ、クライアントアプリ「chatアプリ」の認証に成功して、管理システム５０から端末１０ａへ認証結果情報が送信されてからの処理について説明する。端末１０ａのsub要求部１６は、ユーザａが掲示板に書かれるメッセージ、及び自分宛のメッセージを受け取るため、sub要求を管理システム５０へ送信する（ステップＳ４１）。sub要求には、掲示板に関するトピック名"bulletin_board"、及びユーザａ宛のメッセージに関するトピック名"message_to/a"が含まれている。

管理システム５０の送受信部５１は、端末１０ａのchatアプリによって送信されたsub要求を受信する。管理システム５０のsub処理部５４は、端末１０ａのchatアプリがsub要求に係るメッセージをsubする権限を有するか否かを判断する（ステップＳ４２）。ステップＳ４２の処理について、図１０を用いて詳細に説明する。図１０は、メッセージをsubする権限を有するか否かを判断する処理の一例を示したフロー図である。

まず、sub処理部５４は、sub要求に含まれるそれぞれのトピック名が、トピック管理テーブル（図７（Ａ）参照）において管理されているか否かを判断する（ステップＳ４２−１）。sub要求に含まれるトピック名がトピック管理テーブルにおいて管理されていないと判断された場合（ステップＳ４２−１のＮＯ）、sub処理部５４は、要求に係るトピックについて、sub要求元はsubする権限がない旨、判断する（ステップＳ４２−５）。

sub要求に含まれるトピック名がトピック管理テーブルにおいて管理されていると判断された場合（ステップＳ４２−１のＹＥＳ）、sub処理部５４は、sub要求に含まれるトピック名毎に、このトピックのトピックＩＤ、sub要求元のクライアント名、及びsub権限有りを示す権限情報"sub"の組が、クライアント認可管理テーブルにおいて管理されているか否かを判断する（ステップＳ４２−２）。sub要求に含まれるトピック名"bulletin_board"に関しては、"bulletin_board"のトピックＩＤ"T02"、sub要求元のクライアント名"chatアプリ"、及びsub権限有りを示す権限情報"sub"の組がクライアント認可管理テーブルにおいて管理されているとsub処理部５４によって判断される（ステップＳ４２−２のＹＥＳ）。一方、sub要求に含まれるトピック名"message_to/a"に関しては、"message to/a"のトピックＩＤ"T03"、sub要求元のクライアント名"chatアプリ"、及びsub権限有りを示す権限情報"sub"の組が、クライアント認可管理テーブルにおいて管理されていないとsub処理部５４によって判断される（ステップＳ４２−２のＮＯ）。ステップＳ４２−２においてＮＯと判断された場合、sub処理部５４は、sub要求に係るトピックのトピックＩＤ、sub要求元のユーザ名、sub要求元のクライアント名、及びsub権限有りを示す権限情報"sub"の組が、ユーザ認可管理テーブルにおいて管理されているか否かを判断する（ステップＳ４２−３）。sub要求に含まれるトピック名"message_to/a"に関して、"message_to/a"のトピックＩＤ"T03"、sub要求元のユーザ名"a"、sub要求元のクライアント名"chatアプリ"、及びsub権限有りを示す権限情報"sub"の組がユーザ認可管理テーブルにおいて管理されているとsub処理部５４によって判断される（ステップＳ４２−３のＹＥＳ）。

ステップＳ４２−３においてＮＯと判断された場合、sub処理部５４は、要求に係るトピックについて、sub要求元はsubする権限がない旨、判断する（ステップＳ４２−５）。

一方、ステップＳ４２−２又はステップＳ４２−３においてＹＥＳと判断された場合、要求に係るトピック"bulletin_board"及び"message_to/a"について、sub要求元のchatアプリはsubする権限がある旨、判断する（ステップＳ４２−４）。この場合、sub処理部５４は、sub要求元のユーザ名"a"、クライアント名"chatアプリ"、sub要求に係るトピック"bulletin_board, message_to/a"のトピックＩＤ"T02, T03"をセッション管理テーブルに関連付けて登録する（図７（Ｄ）参照）（ステップＳ４３）。

管理システム５０の送受信部５１は、ステップＳ４２−４又はＳ４２−５における判断結果に基づいて、sub要求の許可又は拒否を示す情報を端末１０ａへ送信しても良い。

上記のステップＳ４１乃至Ｓ４３の処理は、端末１０ａで起動するクライアントアプリ毎に実行される。例えば、ユーザａによって端末１０ａにおいてchatアプリ及びログ管理アプリが起動された場合、各chatアプリ及びログ管理アプリは、管理システム５０へそれぞれsub要求を送信することができる。それぞれのsub要求が許可されると、セッション管理テーブルには、共通のユーザ名に対して、chatアプリ又はログ管理アプリを示すクライアントＩＤと、各クライアントアプリの要求に係るトピックのトピックＩＤが関連付けられて管理されることになる（図７（Ｄ）参照）。

続いて、管理システム５０側でのユーザｂ、クライアントアプリ「chatアプリ」の認証に成功して、管理システム５０から端末１０ｂへ認証結果情報が送信されてからの処理について説明する。端末１０ｂの操作入力受付部１２がユーザｂから掲示板用のメッセージ「こんにちは」の入力を受け付けると、pub要求部１６は、pub要求を管理システム５０へ送信する（ステップＳ４４）。pub要求には、掲示板に関するトピック名"bulletin_board"、及び入力されたメッセージ「こんにちは」が含まれている。

管理システム５０の送受信部５１は、端末１０ｂのchatアプリによって送信されたpub要求を受信する。管理システム５０のpub処理部５３は、端末１０ｂのchatアプリがpub要求に係るトピックのメッセージをpubする権限を有するか否かを判断する（ステップＳ４５）。ステップＳ４５の処理について、図１１を用いて詳細に説明する。図１１は、メッセージをpubする権限を有するか否かを判断する処理の一例を示したフロー図である。

まず、pub処理部５３は、pub要求に含まれるトピック名が、トピック管理テーブル（図７（Ａ）参照）において管理されているか否かを判断する（ステップＳ４５−１）。pub要求に含まれるトピック名がトピック管理テーブルにおいて管理されていないと判断された場合（ステップＳ４５−１のＮＯ）、pub処理部５３は、要求に係るトピックについて、pub要求元はpubする権限がない旨、判断する（ステップＳ４５−５）。

pub要求に含まれるトピック名がトピック管理テーブルにおいて管理されていると判断された場合（ステップＳ４５−１のＹＥＳ）、pub処理部５３は、pub要求に含まれるトピック名毎に、このトピックのトピックＩＤ、pub要求元のクライアント名、及びpub権限有りを示す権限情報"pub"の組が、クライアント認可管理テーブルにおいて管理されているか否かを判断する（ステップＳ４５−２）。pub要求に係るトピック"bulletin_board"に関しては、"bulletin_board"のトピックＩＤ"T02"、pub要求元のクライアント名"chatアプリ"、及びpub権限有りを示す権限情報"pub"の組がクライアント認可管理テーブルにおいて管理されているとpub処理部５３によって判断される（ステップＳ４５−２のＹＥＳ）。ステップＳ４５−２においてＮＯと判断された場合、pub処理部５３は、pub要求に係るトピックのトピックＩＤ、pub要求元のユーザ名、pub要求元のクライアント名、及びpub権限有りを示す権限情報"pub"の組が、ユーザ認可管理テーブルにおいて管理されているか否かを判断する（ステップＳ４５−３）。

なお、ステップＳ４５−３においてＮＯと判断された場合、pub処理部５３は、要求に係るトピックについて、pub要求元はpubする権限がない旨、判断する（ステップＳ４５−５）。

一方、ステップＳ４５−２又はステップＳ４５−３においてＹＥＳと判断された場合、要求に係るトピック"bulletin_board"について、pub要求元はpubする権限がある旨、判断する（ステップＳ４５−４）。

管理システム５０の送受信部５１は、ステップＳ４５−４又はＳ４５−５における判断結果に基づいて、pub要求の許可又は拒否を示す情報を端末１０ｂへ送信しても良い。

一方、ステップＳ４５−２又はステップＳ４５−３においてＹＥＳと判断された場合、pub処理部５３は、pubが許可されたメッセージに係る"bulletin_board"のトピックＩＤ"T02"を検索キーとして、セッション管理テーブルを検索し、対応するユーザ名及びクライアント名の組（ａ，chatアプリ）及び（ｂ，chatアプリ）を取得する（ステップＳ４６）。これにより、pub処理部５３は、メッセージの送信先として、ユーザａが使用しているchatアプリ、及びユーザｂが使用しているchatアプリを特定する。

送受信部５１は、pub要求されたメッセージに送信元を追加したメッセージ「こんにちは（from b）」を、特定された送信先として、端末１０ａのユーザａが使用しているchatアプリ、及び端末１０ｂのユーザｂが使用しているchatアプリへ送信する。なお、端末１０ａのchatアプリ及びログ管理アプリがそれぞれ管理システム５０と接続している場合、管理システム５０は、端末１０ａのchatアプリとのセッションを利用してメッセージを送信する。これにより、ログ管理アプリがchatアプリ用のメッセージを受信することを防ぐことができる。

管理システム５０は、pub要求に係るメッセージを記憶部５０００において管理しても良い。これにより、pub要求時には管理システム５０と接続していないクライアントが、後に管理システム５０と接続したときに、管理システム５０は、記憶部５０００において管理されているメッセージをクライアントに送信することもできる。

なお、上記のステップＳ４４乃至Ｓ４７−１，Ｓ４７−２の処理は、端末１０ｂで起動するクライアントアプリ毎に実行される。すなわち、クライアントアプリおよびユーザが管理システム５０において認証された場合には、そのユーザが利用するクライアントアプリ毎にメッセージのpub要求をすることができる。

＜＜実施形態の変形例＞＞
続いて、実施形態の変形例について上記の実施形態と異なる点を説明する。図１２は実施形態の変形例に係る通信システムの概略図である。変形例では端末１０としての端末（１０ｃ，１０ｄ，１０ｅ）が通信ネットワーク２を介して、他の端末１０及び装置と通信可能となるように接続している。なお、端末（１０ｃ，１０ｄ）は、通信機能を備えた監視カメラである。端末（１０ｃ，１０ｄ）は、同一の店舗３００に設置されていても良い。端末１０ｅは、汎用のＰＣである。

端末（１０ｃ，１０ｄ）には、クライアントアプリとして監視カメラアプリがインストールされている。ステップＳ２１乃至Ｓ３０と同様の処理により、各端末（１０ｃ，１０ｄ）の監視カメラアプリは、共通のユーザａの権限により、認証サーバ４０へ認証／認可要求し、結果として、それぞれ管理システム５０とのセッションが確立している。

端末１０ｅには、クライアントアプリとして監視センターアプリがインストールされている。ステップＳ２１乃至Ｓ３０と同様の処理により、端末１０ｅの監視センターアプリは、ユーザａの権限により、認証サーバへ認証／認可要求し、結果として、管理システム５０とのセッションが確立している。

ステップＳ４１乃至Ｓ４３と同様の処理により、端末１０ｅの監視センターアプリは、トピック「surveillance/mart」に対するsub要求をして、管理システム５０によって認可されている。ステップＳ４４と同様の処理により、端末（１０ｃ，１０ｄ）の監視カメラアプリは、管理システム５０へ、トピック「surveillance/mart」に対するpub要求をする。この場合、上記の実施形態とは異なり、各監視カメラアプリは自端末で撮像された画像の画像データをトピック「surveillance/mart」に係るメッセージとして管理システム５０へ送信する。管理システム５０は、ステップＳ４５と同様の処理により、端末（１０ｃ，１０ｄ）の監視カメラアプリのpub要求を認可する。更に、管理システム５０は、ステップＳ４６と同様の処理により、メッセージの送信先として、ユーザａが利用する端末１０ｅの監視センターアプリに特定する。これにより、管理システム５０は、ステップＳ４７−１と同様の処理により、端末（１０ｃ，１０ｄ）の監視カメラアプリから送られてきたメッセージ（画像データ）を、端末１０ｅの監視センターアプリへ送信する。なお、端末（１０ｃ，１０ｄ）の監視カメラアプリは、定期的（例えば、５秒）に、「surveillance/mart」に対するpub要求を行っても良い。これにより、端末１０ｅの監視センターアプリは定期的にメッセージとしての撮像画像の画像データを受信することができるので、店舗３００を遠隔監視することができる。

＜＜本実施形態の主な効果＞＞
続いて、上記の実施形態の主な効果を説明する。上記実施形態の送信制御方法によると、管理システム５０の送受信部５１（受信手段の一例）は、所定の属性の情報を受信する（受信処理の一例）。なお、属性とは、PubSubモデルにおいて、subする情報を特定するための例えばトピック等の属性である。また、上記の情報は、PubSubモデルにおいて、pub又はsubすることが可能なメッセージや画像データなどの情報である。管理システム５０のpub処理部５３及びsub処理部５４（制御手段の一例）は、クライアント認可管理ＤＢ５００２において、所定の属性が、所定のクライアントに対応付けられている場合には、所定のクライアントで認証された端末１０へ、送受信部５１によって受信された情報を送信するように制御する（制御処理の一例）。また、管理システム５０のpub処理部５３及びsub処理部５４（制御手段の一例）は、ユーザ認可管理ＤＢ５００３において、所定の属性が、所定のアカウント、及び所定のクライアントの双方に対応付けられている場合には、所定のアカウントで認証され、かつ所定のクライアントで認証された端末１０へ、送受信部５１によって受信された情報を送信するように制御し（制御処理の一例）、ユーザ認可管理ＤＢ５００３において、所定の属性が、所定のアカウント、及び所定のクライアントの双方に対応付けられていない場合には、所定のアカウントで認証され、かつ所定のクライアントで認証された端末１０へ、送受信部５１によって受信された情報を送信しないように制御する（制御処理の一例）。なお、アカウントはサービスを利用する権限であって、例えば、ユーザＩＤをアカウントとして用いることができる。上記の実施形態によると複数のクライアントが、管理システム５０へ接続する場合でも、クライアント毎、或いはクライアント及びアカウント毎に適切な情報を購読することが可能となる。

管理システムのクライアント認可管理ＤＢ５００２（管理手段の一例）は、クライアントの識別情報、及び属性を示す属性情報を対応付けて管理する。所定のアカウント、及び所定の属性を示す属性情報がクライアント認可管理ＤＢ５００２において対応付けて管理されている場合、pub処理部５３及びsub処理部５４は、送受信部５１によって受信された情報を送信するように制御する。また、管理システム５０のユーザ認可管理ＤＢ５００３は、アカウント、クライアントの識別情報、及び属性を示す属性情報を対応付けて管理する。所定のアカウント、所定のクライアントの識別情報、及び所定の属性を示す属性情報がユーザ認可管理ＤＢにおいて対応付けて管理されている場合、pub処理部５３及びsub処理部５４は、送受信部５１によって受信された情報を送信するように制御する。このように、管理システム５０において、クライアントの識別情報、及び属性、或いはアカウント、クライアントの識別情報、及び属性を示す属性情報を予め関連付けておくことで、pub処理部５３及びsub処理部５４が情報を送信するか否かを判断することが可能となる。

認証サーバ４０（認証システムの一例）の送受信部４１（受付手段の一例）は、所定のクライアント、及び所定のアカウントによる認証要求を受け付ける（受付処理の一例）。認証サーバ４０のユーザ認証部４２は、所定のアカウントを認証する。認証サーバ４０のクライアント認証部４３（認証手段の一例）は、所定のクライアントを認証する（認証処理の一例）。これにより、所定のアカウント、及び所定のクライアントが認証された場合に、管理システム５０において、上記の情報をsub可能に制御させることができる。

認証サーバ４０のトークン発行部４５（発行手段の一例）は、ユーザ認証部４２によって所定のアカウントが認証され、クライアント認証部４３によって所定のクライアントが認証された場合に、認可トークンを発行する。管理システム５０は、トークン発行部４５によって発行された認可トークンに基づいて、サービスの利用を認可する。これにより、管理システム５０と、認証サーバ４０が別装置であっても、セキュリティを確保することができる。

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

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

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

１ 通信システム
２ 通信ネットワーク
１０ 端末
１１ 送受信部
１２ 操作入力受付部
１３ 表示制御部
１４ 認証要求部
１５ pub要求部
１６ sub要求部
１９ 記憶・読出部
４０ 認証サーバ
４１ 送受信部
４２ ユーザ認証部
４３ クライアント認証部
４４ 認可部
４５ トークン発行部
４９ 記憶・読出部
５０ 管理システム
５１ 送受信部
５２ トークン確認部
５３ pub処理部
５４ sub処理部
５９ 記憶・読出部
１０００ 記憶部
４０００ 記憶部
４００１ ユーザ管理ＤＢ
４００２ クライアント管理ＤＢ
４００３ サービス管理ＤＢ
４００４ サービス認可管理ＤＢ
５０００ 記憶部
５００１ トピック管理ＤＢ
５００２ クライアント認可管理ＤＢ
５００３ ユーザ認可管理ＤＢ
５００４ セッション管理ＤＢ

特表２００９−５１９５０９号公報

Claims (10)

1. 所定の属性の情報を受信する受信手段と、
   前記所定の属性が、所定のクライアントに対応付けられている場合には、前記所定のクライアントで認証された通信端末へ、前記受信手段によって受信された前記情報を送信するように制御する制御手段と、
   を有することを特徴とする管理システム。
2. 所定の属性の情報を受信する受信手段と、
   前記所定の属性が、所定のアカウント及び所定のクライアントの双方に対応付けられている場合には、前記所定のアカウントで認証され、前記所定のクライアントで認証された通信端末へ、前記受信手段によって受信された前記情報を送信し、前記所定の属性が、前記所定のアカウント及び前記所定のクライアントの双方に対応付けられていない場合には、前記所定のアカウントで認証され、前記所定のクライアントで認証された前記通信端末へ、前記受信手段によって受信された前記情報を送信しないように制御する制御手段と、
   を有することを特徴とする請求項１に記載の管理システム。
3. 前記クライアントの識別情報、及び前記属性を示す属性情報を対応付けて管理する管理手段を有しており、
   前記所定のクライアントの識別情報、及び前記所定の属性を示す属性情報が前記管理手段において対応付けて管理されている場合、前記制御手段は、前記受信手段によって受信された前記情報を送信するように制御することを特徴とする請求項１に記載の管理システム。
4. 所定のクライアントによる認証要求を受け付ける受付手段と、
   前記所定のクライアントを認証する認証手段と、
   所定の属性の情報を受信する受信手段と、
   前記所定の属性が、前記所定のクライアントに対応付けられている場合には、前記認証手段によって前記所定のクライアントで認証された通信端末へ、前記受信手段によって受信された前記情報を送信するように制御する制御手段と、
   を有することを特徴とする通信システム。
5. 所定のクライアントによる認証要求を受け付ける受付手段と、
   前記所定のクライアントを認証する認証手段と、
   を有する認証システム、及び
   所定の属性の情報を受信する受信手段と、
   前記所定の属性が、所定のクライアントに対応付けられている場合には、前記認証手段によって前記所定のクライアントで認証された通信端末へ、前記受信手段によって受信された前記情報を送信するように制御する制御手段と、
   を有する管理システム
   を備えることを特徴とする通信システム。
6. 前記認証システムは、前記認証手段によって前記所定のクライアントが認証された場合に、認可トークンを発行する発行手段を有しており、
   前記管理システムは、前記発行手段によって発行された前記認可トークンに基づいて、サービスの利用を認可することを特徴とする請求項５に記載の通信システム。
7. 管理システムが、
   所定の属性の情報を受信する受信処理と、
   前記所定の属性が、所定のクライアントに対応付けられている場合には、前記所定のクライアントで認証された通信端末へ、前記受信処理によって受信された前記情報を送信するように制御する制御処理と、
   を実行することを特徴とする送信制御方法。
8. 通信システムが、
   所定のクライアントによる認証要求を受け付ける受付処理と、
   前記所定のクライアントを認証する認証処理と、
   所定の属性の情報を受信する受信処理と、
   前記所定の属性が、前記所定のクライアントに対応付けられている場合には、前記認証処理によって前記所定のクライアントで認証された通信端末へ、前記受信処理によって受信された前記情報を送信するように制御する制御処理と、
   を実行することを特徴とする送信制御方法。
9. 認証システムが、
   所定のクライアントによる認証要求を受け付ける受付処理と、
   前記所定のクライアントを認証する認証処理と、
   を実行し、
   管理システムが、
   所定の属性の情報を受信する受信処理と、
   前記所定の属性が、前記所定のクライアントに対応付けられている場合には、前記認証処理によって前記所定のクライアントで認証された通信端末へ、前記受信処理によって受信された前記情報を送信するように制御する
   ことを特徴とする送信制御方法。
10. 管理システムに、
    所定の属性の情報を受信する受信処理と、
    前記所定の属性が、所定のクライアントに対応付けられている場合には、前記所定のクライアントで認証された通信端末へ、前記受信処理によって受信された前記情報を送信するように制御する制御処理と、
    を実行させることを特徴とするプログラム。

Images