(57)【要約】【課題】  リソースサービスシステムでの処理において、所定のクライアントから大量のデータが送信された場合に、他のクライアントのデータ処理を遅延させないための仕組みを提供する。【解決手段】  通信管理システムは、複数のリソースサービスシステムのいずれかが単位時間あたりに受信した所定のクライアントのデータの数が所定数を超える場合、該リソースサービスシステムから通知を受信し、この通知の受信に応じて、前記受信サービスシステムが前記所定のクライアントのデータを該リソースサーバーに送信しないための設定を行うよう前記受信サービスシステムに対して要求する。この設定に従い、前記所定のクライアントのデータは該リソースサービスシステムに送信されない。【選択図】  図９
2020135442.tif 000002
【特許請求の範囲】
【請求項１】
複数のクライアントのデータを受信する受信サービスシステムと、前記受信サービスシステムから転送されたデータの処理を実行する複数のリソースサービスシステムと、前記受信サービスシステムおよび前記複数のリソースサービスシステムと通信可能な通信管理システムと、を含むシステムであって、
前記受信サービスシステムは、
クライアントのデータを受信する第１の受信手段と、
前記受信したクライアントのデータを前記複数のリソースサービスシステムのいずれかに転送する転送手段と、を有し、
前記複数のリソースサービスシステムそれぞれは、
前記転送手段が転送したデータを受信する第２の受信手段と、
単位時間あたりに前記第２の受信手段が受信した所定のクライアントのデータの数が所定数を超える場合、前記通信管理システムに対して通知する通知手段と、を有し、
前記通信管理システムは、
前記通知手段からの前記通知に応じて、前記所定のクライアントのデータが前記第２の受信手段に送信されないための第１の設定を行うよう前記受信サービスシステムに対して要求する第１の要求手段と、を有し、
前記第１の要求手段による要求に応じて行われた前記第１の設定に従い、前記所定のクライアントのデータは前記第２の受信手段に転送されないことを特徴とするシステム。
【請求項２】
前記通信管理システムは、
前記複数のリソースサービスシステムそれぞれが前記通知をしたか否かを管理する第１の管理手段を更に有し、
前記第１の要求手段は、前記複数のリソースサービスシステムの中で前記通知をしていないリソースサービスシステムがない場合、前記第１の受信手段が前記所定のクライアントのデータを前記転送手段に送信しないための前記第１の設定を行うよう前記受信サービスシステムに対して要求することを特徴とする請求項１に記載のシステム。
【請求項３】
前記複数のリソースサービスシステムのそれぞれは、
単位時間あたりに前記第２の受信手段が受信した所定のクライアントのデータの数を監視する監視手段と、
単位時間あたりに前記第２の受信手段が受信した所定のクライアントのデータの数が前記所定数を超える場合、前記転送手段が前記所定のクライアントのデータを前記第２の受信手段に転送しないための第２の設定を行うよう前記受信サービスシステムに対して要求する第２の要求手段と、をさらに有し、
前記第２の要求手段による要求に応じて行われた前記第２の設定に従い、前記所定のクライアントのデータは前記第２の受信手段に転送されないことを特徴とする請求項１または２に記載のシステム。
【請求項４】
前記複数のリソースサービスシステムのそれぞれは、
単位時間あたりに前記第２の受信手段が受信した所定のクライアントのデータの数が前記所定数を超える場合、前記所定のクライアントのデータを受信する第３の受信手段を起動させる起動手段と、
前記第３の受信手段が起動された場合、前記転送手段が前記所定のクライアントのデータを前記第２の受信手段ではなく前記第３の受信手段に転送するための第３の設定を行うよう前記受信サービスシステムに対して要求する第３の要求手段と、を更に有し、
前記受信サービスシステムの前記転送手段は、前記第３の要求手段による要求に応じて行われた前記第３の設定に従い、前記所定のクライアントのデータを前記第３の受信手段に転送することを特徴とする請求項１乃至３のいずれか１項に記載のシステム。
【請求項５】
前記通知手段は、前記第３の設定が行われたことに応じて、前記通信管理システムに対して通知することを特徴とする請求項４に記載のシステム。
【請求項６】
前記複数のリソースサービスシステムのそれぞれは、
単位時間あたりに前記第２の受信手段が受信した所定のクライアントのデータの数を監視する監視手段と、
前記第２の受信手段が受信したデータの処理を実行する処理手段と、を更に有し、
前記処理手段は、前記第３の受信手段が受信した前記所定のクライアントのデータの処理を実行せず、
前記監視手段は、単位時間あたりに前記第３の受信手段が受信した所定のクライアントのデータの数を監視することを特徴とする請求項４または５に記載のシステム。
【請求項７】
クライアントのデータには、クライアントの識別情報と、データの種別を示すトピックとが含まれ、
前記受信サービスシステムは、
データの種別を示すトピックと、データの転送先と、を対応付けて管理する第２の管理手段を更に有し、
前記転送手段は、前記第１の受信手段が受信したデータに含まれるトピックと対応付けられる転送先に、該データを転送することを特徴とする請求項１乃至６のいずれか１項に記載のシステム。
【請求項８】
複数のクライアントのデータを受信する受信サービスシステム、および前記受信サービスシステムから転送されたデータの処理を実行する複数のリソースサービスシステムと通信可能な通信管理システムであって、
前記複数のリソースサービスシステムのいずれかが単位時間あたりに受信した所定のクライアントのデータの数が所定数を超える場合、該リソースサービスシステムから通知を受信する受信手段と、
前記通知の受信に応じて、前記受信サービスシステムが前記所定のクライアントのデータを該リソースサービスシステムに送信しないための設定を行うよう前記受信サービスシステムに対して要求する要求手段と、を有し、
前記要求に応じて行われた前記設定に従い、前記所定のクライアントのデータが該リソースサービスシステムに送信されないことを特徴とする通信管理サーバー。
【請求項９】
複数のクライアントのデータを受信する受信サービスシステムと、前記受信サービスシステムから転送されたデータの処理を実行する複数のリソースサービスシステムと、前記受信サービスシステムおよび前記複数のリソースサービスシステムと通信可能な通信管理システムと、を含むシステムの制御方法であって、
前記受信サービスシステムが、クライアントのデータを受信する第１の受信工程と、
前記受信サービスシステムが、前記受信したクライアントのデータを前記複数のリソースサービスシステムのいずれかに転送する転送工程と、
前記複数のリソースサービスシステムそれぞれが、前記転送工程で転送されたデータを受信する第２の受信工程と、
前記複数のリソースサービスシステムそれぞれが、単位時間あたりに前記第２の受信工程で受信された所定のクライアントのデータの数が所定数を超える場合、前記通信管理システムに対して通知する通知工程と、
前記通信管理システムが、前記通知工程での前記通知に応じて、前記所定のクライアントのデータが前記第２の受信工程で受信されないための第１の設定を行うよう前記受信サービスシステムに対して要求する第１の要求工程と、を有し、
前記第１の要求工程における要求に応じて行われた前記第１の設定に従い、前記所定のクライアントのデータは前記第２の受信工程で受信されないことを特徴とする制御方法。
【請求項１０】
複数のクライアントのデータを受信する受信サービスシステム、および前記受信サービスシステムから転送されたデータの処理を実行する複数のリソースサービスシステムと通信可能な通信管理システムの制御方法であって、
前記複数のリソースサービスシステムのいずれかが単位時間あたりに受信した所定のクライアントのデータの数が所定数を超える場合、該リソースサービスシステムから通知を受信する受信工程と、
前記通知の受信に応じて、前記受信サービスシステムが前記所定のクライアントのデータを該リソースサービスシステムに送信しないための設定を行うよう前記受信サービスシステムに対して要求する要求工程と、を有し、
前記要求に応じて行われた前記設定に従い、前記所定のクライアントのデータが該リソースサービスシステムに送信されないことを特徴とする制御方法。
【請求項１１】
請求項８に記載の手段としてコンピューターを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントのデータを受信して処理するシステム、通信管理サーバー、制御方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、インターネットに家電製品や自動車などをクライアント端末として接続する「Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ」（以降、ＩｏＴと称する）を実現するシステムが利用されている。また、画像形成装置の多機能化が進み、Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｒｉｎｔｅｒ（以降、ＭＦＰと称する）と呼ばれる複合機もＩｏＴクライアントとして対応することが可能となった。
【０００３】
ＩｏＴシステムは、ＩｏＴクライアントに接続されたセンサー情報など膨大な量のデータを収集、分析することで、ＩｏＴクライアント（単にクライアントとも称する）及びそれを利用するユーザーに対してサービス、付加価値を提供する。ＩｏＴシステムにおいては、前述した膨大な量のデータを、同じく膨大な数のクライアントから受信するようになってきている。
【０００４】
このような膨大なデータをリアルタイムに受信する処理では、刻一刻と変動するトラフィックの監視が重要である。トラフィックのデータを受信するサーバーは、ＡＰＩを備えた従来型のリソースサーバーが単独で対応することは困難である。そこで、データの収集には、受信専用のサービス（データ受信サービス）を利用し、サービスを提供する処理（リソースサービス）は非同期処理として分離して対応することが一般的になりつつある。
【０００５】
ＩｏＴクライアントはデータ受信サービスにデータを送信し、データ受信サービスはデータをバッファリングし、リソースサービスからのデータ受信要求に対してバッファリングからのデータを供給する。このようにして、リソースサービスはＩｏＴクライアントからの変動する膨大なトラフィックを意識することなく、データの処理に専念することができる。
【０００６】
また、ストリーム受信サービスからデータを転送されるリソースサービスは、複数存在することが可能である。リソースサービスはストリーム受信サービスとは非同期で処理を実行しているため、ＩｏＴシステムの開発において、提供するサービスの種類ごとに柔軟にリソースサービスを追加することができる。
【０００７】
ここで、特許文献１では、ＩｏＴシステムではないが、端末装置から受信したデータを転送するエッジ装置と、転送されたデータを分析するサーバーとを備える計算機システムについて記載されている。サーバーは、転送されたデータから抽出したノイズを用いてノイズフィルタを生成し、エッジ装置に設定する。ノイズフィルタが設定されたエッジ装置では、端末装置から受信したデータに含まれるノイズを除去する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１８−１０４２１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
あるクライアントが、たとえばハードディスク故障などで、エラーに関するデータなどを通常よりも高頻度で受信サービスに送信する場合がある。そのような場合であっても、リソースサービスの負荷を考慮することなく受信サービスはデータを受信し、受信サービスにデータが存在する限り、各リソースサービスは非同期でデータ処理を実行し続ける。一方で、各リソースサービスが単位時間あたりに処理可能なデータ量には制限がある。そのため、一部のクライアントが通常よりも高頻度で大量のデータを送信すると、各リソースサービスが処理すべきデータ量が増え、結果として、他の正常なクライアントからのデータの処理に遅延が生じてしまう。
【００１０】
そこで本発明は、リソースサービスシステムでの処理において、所定のクライアントから大量のデータが送信された場合に、他のクライアントのデータ処理を遅延させないための仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明は、複数のクライアントのデータを受信する受信サービスシステムと、前記受信サービスシステムから転送されたデータの処理を実行する複数のリソースサービスシステムと、前記受信サービスシステムおよび前記複数のリソースサービスシステムと通信可能な通信管理システムと、を含むシステムであって、前記受信サービスシステムは、クライアントのデータを受信する第１の受信手段と、前記受信したクライアントのデータを前記複数のリソースサービスシステムのいずれかに転送する転送手段と、を有し、前記複数のリソースサービスシステムそれぞれは、前記転送手段が転送したデータを受信する第２の受信手段と、単位時間あたりに前記第２の受信手段が受信した所定のクライアントのデータの数が所定数を超える場合、前記通信管理システムに対して通知する通知手段と、を有し、前記通信管理システムは、前記通知手段からの前記通知に応じて、前記所定のクライアントのデータが前記第２の受信手段に送信されないための第１の設定を行うよう前記受信サービスシステムに対して要求する第１の要求手段と、を有し、前記第１の要求手段による要求に応じて行われた前記第１の設定に従い、前記所定のクライアントのデータは前記第２の受信手段に転送されないことを特徴とする。
【発明の効果】
【００１２】
本発明により、リソースサービスシステムでの処理において、所定のクライアントから大量のデータが送信された場合に、他のクライアントのデータ処理が遅延することを回避できる。
【図面の簡単な説明】
【００１３】
【図１】システム全体図
【図２】ハードウェア構成図
【図３】ソフトウェア構成図
【図４】クライアント端末が受信サーバーに送信するデータの一例
【図５】リソースサーバーが受信データの通知登録する処理のシーケンス図
【図６】受信データを各リソースサーバー通知する処理のシーケンス図
【図７】リソースサーバーがクライアント端末の異常を検知する処理のシーケンス図
【図８】通信管理サーバーが統合サービスとして除外設定を判断する処理のシーケンス図
【図９】通信管理サーバーが統合サービスとして除外設定を判断する処理のフローチャート
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態について図面を用いて説明する。
【００１５】
（実施例１）
本実施例においては、ネットワーク上の各サーバーにアプリケーションが設置されていることとする。また、各アプリケーションはクライアント端末と連携し、様々な機能を提供することとする。このような機能を提供する実体をサービスと呼称し、機能をクライアント端末に提供することをサービスの提供と呼称する。また、複数のサーバーと複数のアプリケーションから複数のサービスを連携しあい提供するサービスを統合サービスと呼称する。
【００１６】
図１は、本実施例に係る情報処理システムであるデータ収集基盤システムの全体構成を示す図である。本実施例に係る情報処理システムは、クライアント端末のデータを受信する受信サービスシステム、および、受信したデータを処理してサービスを提供する複数のリソースサービスシステムを含む。受信サービスシステムと各リソースサービスシステムとは、非同期でデータ処理を行っている。本実施例に係る情報処理システムで提供されるサービスは、例えば、クライアント端末のデータをバックアップするサービスや、クライアント端末に接続されたセンサー情報から稼働状況を分析するサービスなどがある。
【００１７】
ネットワーク１００は本システムの各構成要素を接続するインターネットである。
【００１８】
ネットワーク１０１、１０２、１０３は本システムの各構成要素を通信可能に接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（以降、ＬＡＮと称する）である。
【００１９】
クライアント端末１０４、１０５は、サービスを利用する画像形成装置などの機器である。ここでは画像形成装置をクライアント端末の例として記載しているが、ＩｏＴ機器や、端末などのデバイスであってもよい。クライアント端末１０４や１０５は、それぞれ異なる場所や顧客内ネットワーク上にある機器であり、このような機器が無数にインターネット１００接続されている。
【００２０】
サーバー１０６〜１１１は、統合サービスを構成している各サーバーであり、複数のサービス機能を有しているサーバー群である。最近ではクラウド環境においてサービスプロセスだけが論理的に動いており、そのプロセスのことをサーバーと呼ぶこともあるが、ここでは視覚的にわかりやすくとらえるため、各サービスをサーバーとして記載している。サーバー１０６〜１１１は、クライアント端末１０４、１０５に対して様々なサービスを提供するサーバーである。
【００２１】
サーバー１０６，１０７は、統合サービスにおけるリソースサーバーであり、クライアント端末１０４，１０５から情報を収集しユーザーにサービスを提供するリソースサービスシステムとして機能するサーバーである。例えば、リソースサーバー１０６、１０７はクライアント端末１０４、１０５をバックアップするサービスであったり、クライアント端末１０４、１０５に接続されたセンサー情報を分析するサービスであったりする。リソースサーバー１０６，１０７は、そのほかにも統合サービス内に多数あってもよい。
【００２２】
サーバー１０８は、統合サービスにおける受信サーバーであり複数のクライアント端末１０４、１０５が送信するデータを受信するサーバーである。この受信サーバー１０８は、クライアント端末１０４や１０５など、市場に無数に設置されているクライアント端末と通信してリソースサーバー１０６，１０７が利用するデバイスデータを受信する。
【００２３】
サーバー１０９は、統合サービスにおける監視サーバーである。監視サーバー１０９は、受信サーバー１０８のデータ受信状況を定期的に確認し、受信サーバー１０８がデータを受信したことを確認する。
【００２４】
受信サーバー１０８が新規データを受信すると、監視サーバー１０９はそのデータを取得し、直ちにデータストレージにコピーを送信する。そして、受信データをメッセージサーバーに送信すべきか破棄すべきかを判断する。破棄すべきと判断した場合は、直ちに受信データを破棄する。破棄すべきでないと判断した場合は、メッセージサーバー１１０へ受信データを送信する。
【００２５】
サーバー１１０は、統合サービスにおけるメッセージサーバーである。メッセージサーバー１１０は、本システムを構成するクライアント端末及び各サーバーで生成されたメッセージを通知するサーバーである。メッセージサーバー１１０は、登録された通知先と、通知する条件に基づき、本システムの構成要素のいずれかが生成したメッセージを通知先に対してプッシュ通知を行う。
【００２６】
サーバー１１１は、統合サービスにおける通信管理サーバーである。この通信管理サーバー１１１は、統合サービスのなかのリソースサーバー１０６、１０７がどのクライアント端末１０４、１０５のどのデータを取得しているのか、または、取得していないのかを統合して管理する通信管理システムとして機能する。そして、統合サービス全体で、ある特定クライアント端末の特定データが利用されていない状態になるのを検知すると、監視サーバー１０９に転送停止指示を発行する。そして、リソースサーバー１０６，１０７で除外している処理を解消し統合サービス全体における不効率を解消する。
【００２７】
サーバー１１２は、統合サービスにおけるデータストレージである。このデータストレージ１１２は、監視サーバー１０９が取得した受信データのコピーを受信する。データストレージ１１２は、統合サービスがクライアント端末１０４，１０５から受信したデータをすべて保管する。そして、保管されるデータは、リソースサーバー１０６，１０７に提供した受信データのバックアップとして利用され、また、多台数のクライアント端末１０４，１０５から収集したデータを統計データとしての解析に利用可能となる。
【００２８】
特に、受信サーバー１０８、監視サーバー１０９、メッセージサーバー１１０、およびデータストレージ１１２が、本実施例における受信サービスシステムとして機能する。また、クライアント端末１０４、１０５及び各サーバー１０６〜１１２はそれぞれ１台または２台で図示しているが、より多数の複数台で構成されていても良い。
【００２９】
図２は、本実施例に係るクライアント端末１０４、１０５、リソースサーバー１０６、１０７、受信サーバー１０８、監視サーバー１０９、メッセージサーバー１１０、通信管理サーバー１１１を構成する情報処理装置の一般的なハードウェア構成である。なお、リソースサーバー１０６、１０７については、図２に示すコンピューターの各ハードウェアの機能はそれぞれ、仮想マシンソフトウェアによってアプリケーションソフトウェアとして実現され、物理ハードウェア要素と同様の挙動をとるものとする。受信サーバー１０８、監視サーバー１０９、メッセージサーバー１１０、通信管理サーバー１１１についても同様である。
【００３０】
ＣＰＵ２０１は、ＲＯＭ２０３のプログラＲＯＭに記憶された、あるいはハードディスクなどの外部メモリ２１１からＲＡＭ２０２にロードされたオペレーティングシステム（以降、ＯＳと呼称する）やアプリケーションなどのプログラムを実行する。またＣＰＵ２０１は、システムバス２０４に接続される各ブロックを制御する。後述する各シーケンスの処理は、ＣＰＵ２０１が実行するプログラムによって実現される。
【００３１】
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリアなどとして機能する。
【００３２】
操作部Ｉ／Ｆ２０５は、操作部２０９からの入力を制御する。
【００３３】
ＣＲＴコントローラー（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。
【００３４】
ディスクコントローラー（ＤＫＣ）２０７は各種データを記憶するハードディスクなどの外部メモリ２１１におけるデータアクセスを制御する。
【００３５】
ネットワークコントローラー２０８は、インターネット１００あるいはＬＡＮ１０１、１０２、１０３を介して接続されたサーバーや他の機器との通信制御処理を実行する。
【００３６】
なお、後述する全ての説明においては、特に断りのない限り実行のハードウェア上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は外部メモリ２１１にインストールされたアプリケーションプログラムである。
【００３７】
図３は、本実施例に係るクライアント端末１０４、１０５、リソースサーバー１０６、１０７、受信サーバー１０８、監視サーバー１０９、メッセージサーバー１１０、通信管理サーバー１１１におけるそれぞれのソフトウェア構成を示す図である。各々のモジュールが実行されることで各々の機能が実現される。なお、図３で示す構成には、ハードウェアの構成を一部含む。
【００３８】
クライアント端末１０４、１０５は、データ送信アプリケーション３１１を持つ。
【００３９】
データ送信アプリケーション３１１は、統合サービスがサービスを提供するために必要なクライアント端末１０４、１０５のデータを受信サーバー１０８に送信する。
【００４０】
リソースサーバー１０６、１０７は、リソースサーバーモジュール３２１、キューモジュール３２２、ストレージ３２３、退避用キューモジュール３２４、受信量監視モジュール３２５を持つ。
【００４１】
リソースサーバーモジュール３２１は、受信サーバー１０８がクライアント端末１０４、１０５のデータを受信した際にメッセージを通知するよう、メッセージサーバー１１０に自身のリソースサーバー内のキューモジュール３２２を登録する。また、リソースサーバーモジュール３２１は、キューモジュール３２２に蓄積された受信データを取得し、そのデータを利用した様々な機能を実現する。例えば、リソースサーバーモジュール３２１は、受信データをストレージ３２３に永続化したり、受信データの内容に任意の値が含まれていた場合、別のリソースサーバーに通知を送信したりする。また、リソースサーバーモジュール３２１は、受信量監視モジュール３２５に受信データを提供し、特定クライアント端末から一定期間内に閾値以上のデータ量を受信していないか確認を行う。この確認処理で受信量監視モジュール３２５は、特定クライアント端末から一定期間に閾値以上のデータを受信していることを検出したとする。ここでの一定期間とは、例えば、１３時から１４時までの６０分といったように定めても良いし、また、一日の中で特定クライアント端末からあるトピックのデータが初めて送られてきた時刻から３０分おきといったように定めてもよい。また、データ受信量の確認では、例えば、データに基づく処理の結果をストレージに書き込んだ回数や、または、キューモジュール３２２に蓄積されているデータの数などが確認される。この検出結果を受けて、リソースサーバーモジュール３２１は、メッセージサーバー１１０に対して特定クライアント端末のデータを受信したら自身の退避用キューモジュール３２４に通知するよう登録変更する。
【００４２】
キューモジュール３２２は、メッセージサーバー１１０からデータを受信し、受信したデータを一時的に格納している。リソースサーバーモジュール３２１がメッセージサーバー１１０へ通知先クライアントとして自身を登録すると、クライアント端末が受信サーバー１０８へデータを送信するたびにメッセージサーバー１１０経由でキューモジュール３２２はデータを受信する。受信したデータはリソースサーバーモジュール３２１が削除指示するまで蓄積される。
【００４３】
ストレージ３２３は、リソースサーバーモジュール３２１が処理したデータを永続化する。
【００４４】
退避用キューモジュール３２４は、メッセージサーバー１１０からデータを受信し、受信したデータを一時的に格納している。退避用キューモジュール３２４には、異常状態となっている特定クライアント端末のデータが格納されているため、リソースサーバーモジュールは退避用キューモジュール３２４内のデータを取得して処理を実行することはない。
【００４５】
受信量監視モジュール３２５は、キューモジュール３２２に送信されたすべてのデータの量を監視し、特定クライアント端末が異常な状態に陥り大量のデータを送信しているかどうかの確認を行う。また、退避用キューモジュール３２４が起動されている場合、受信量監視モジュール３２５は、退避用キューモジュール３２４のデータ受信量も監視する。これは、特定クライアント端末からのデータ受信量が通常程度に落ち着いたことを検知するために行う。特定クライアント端末からのデータ受信量が通常程度に落ち着いたことを検知すると、特定クライアント端末からのデータの転送先をキューモジュール３２２に戻すことができるからである。
【００４６】
受信サーバー１０８は、データ受信モジュール３３１を持つ。
【００４７】
データ受信モジュール３３１は、クライアント端末１０４、１０５からデータの受信を行う。受信データの一例を図４で示す。
【００４８】
クライアント端末１０４、１０５からの受信データ４００は、データ発生時刻４０１、トピックＩＤ４０２、クライアント端末ＩＤ４０３、データ４０４の要素で構成される。
【００４９】
データ発生時刻４０１は、クライアント端末１０４、１０５がデータを生成した時刻が格納される。なお、本実施例においては日時表記をＩＳＯ８６０１標準形式としているが、表記ルールを限定することはない。
【００５０】
トピックＩＤ４０２には、クライアント端末１０４が生成したデータが関連するデータの種別、すなわち、トピックを特定するＩＤが格納される。
【００５１】
クライアント端末ＩＤ４０３は、データを生成したクライアント端末１０４，１０５を一意に特定する識別情報としてデバイスシリアルが格納される。
【００５２】
データ４０４には、トピックによって表されるデータ種別の実データが格納される。
【００５３】
監視サーバー１０９は、データ監視モジュール３４１、フィルタ管理モジュール３４２を持つ。
【００５４】
データ監視モジュール３４１は、受信サーバー１０８がクライアント端末１０４、１０５からデータを受信したかどうか定期的に監視する。受信サーバー１０８がデータを受信したことを検知すると、データ監視モジュール３４１は受信サーバー１０８から受信データを取得する。取得した受信データをコピーし、データストレージ１１２へ送信する。また、取得した受信データからトピックＩＤ４０２を確認し、メッセージサーバー１１０へトピックＩＤ４０２と関連付けて受信データを転送する。
【００５５】
なお、リソースサーバーモジュール３２１およびデータ監視モジュール３４１は、イベント駆動型コンピューティングサービスによってその機能が実現されても良い。クラウドコンピューティングサービスにおいて、特定のコンピューティングリソースに対して発生したイベントに応じて、軽量な処理を実行するサービスが提供されている。このようなサービスは、ハードウェアを関数単位で共有することで、サーバーの利用効率を更に高める、サーバレスと呼ばれる技術である。このサーバレスのサービスを用いると、常駐のサービスを構築して実現するよりも、コストを安く抑えることができる。具体的には、ＡＷＳ  Ｌａｍｂｄａ、Ｇｏｏｇｌｅ  Ｃｌｏｕｄ  Ｆｕｎｃｔｉｏｎｓ、Ｍｉｃｒｏｓｏｆｔ  Ａｚｕｒｅ  Ｆｕｎｃｔｉｏｎｓ等がある。
【００５６】
これらのサービスでは、クラウドコンピューティングサービスに対して所望の処理を実現するためのプログラムコードを、そのプログラムコードを実行する仮想マシンのＣＰＵやメモリ等のスペックを指定して事前に登録する。そして、登録したプログラムコードをコンピューティングリソースとそのコンピューティングリソースに対して発生する特定のイベントと関連付ける。
【００５７】
図３の説明に戻る。フィルタ管理モジュール３４２は、統合サービス全体で特定クライアント端末の特定トピックが不要となっているか否かを管理する。フィルタ管理モジュール３４２は、特定クライアント端末の特定トピックが不要状態になっていると、データを破棄すべきと判断する。
【００５８】
メッセージサーバー１１０は、メッセージモジュール３５１、送信管理モジュール３５２、フィルタ管理モジュール３５３を持つ。
【００５９】
メッセージモジュール３５１は、監視サーバー１０９経由でトピックＩＤとデータを受信する。また、送信管理モジュール３５２で管理される通知先クライアント情報に従い、受信データをクライアントへ通知する。ここでの通知先クライアントは、キューモジュール３２２などが該当する。
【００６０】
送信管理モジュール３５２は、メッセージモジュール３５１が送信する受信データの通知先クライアントを管理する。送信管理モジュール３５２では、トピックと通知先クライアントとが対応付けて管理されている。
【００６１】
フィルタ管理モジュール３５３は、送信管理モジュール３５２で通知先クライアントに設定されているクライアントごとにメッセージ通知方法の制御を行うためのモジュールである。具体的には、特定リソースサーバーが特定クライアント端末の異常を検知した際、特定クライアント端末から受信したデータの通知方法を特定リソースサーバーに通知しないという制御をするために利用される。
【００６２】
通信管理サーバー１１１は、通信管理モジュール３６１、キューモジュール３６２、ストレージ３６３を持つ。
【００６３】
通信管理モジュール３６１は、キューモジュール３６２に蓄積されたリソースサーバー１０６，１０７の登録／除外申請情報を取得し、統合サービス全体で特定クライアント端末からのデータが不要になったのか否かを判断する。特定クライアント端末からの特定トピックＩＤに関連する情報が不要になったと判断すると、通信管理モジュール３６１は、監視サーバー１０９に対して特定クライアント端末の除外申請を発行し、登録を行う。つまり、通信管理モジュール３６１は、特定クライアント端末の特定トピックＩＤに関連する情報をデータ監視モジュール３４１からメッセージモジュール３５１へ転送しないための設定を監視サーバー１０９に対して要求する。
【００６４】
キューモジュール３６２は、通信管理サーバー１１１が管理すべき登録／除外情報をリソースサーバー１０６，１０７から受信する。具体的には、リソースサーバー１０６，１０７が特定クライアント端末の受信データを除外したり、新たな特定クライアント端末の受信データを登録したりした際に、キューモジュール３６２はデータを受信する。
【００６５】
ストレージ３６３は、統合サービス全体で、どのリソースサーバーで、どの特定クライアント端末が除外設定となっているのか設定情報を保管する。
【００６６】
データストレージ１１２は、データストレージモジュール３７１を持つ。データストレージモジュール３７１は、監視サーバー１０９から受信データのコピーを受信し、例えば、バイト当たりの単価が安いストレージなどに保管する。この保管されたデータは、受信データのバックアップデータが必要になった際や収集したデータを統計データとして解析するために取り出す。
【００６７】
図５にて、リソースサーバー１０６、１０７がメッセージサーバー１１０に対してトピックＩＤを登録する処理の流れを説明する。
【００６８】
リソースサーバー１０６，１０７は、自身のサービスを提供するために必要なクライアント端末１０４，１０５のトピックに関する情報をメッセージサーバー１１０に登録を行う。Ｓ５０１からＳ５０４までの処理は、受信データの送信先としてリソースサーバー１０６、１０７をメッセージサーバー１１０へ登録するまでの一連の処理である。また、Ｓ５０５からＳ５０６までの処理は、受信データの送信先としてリソースサーバー１０６、１０７をメッセージサーバー１１０へ登録したことを通信管理サーバー１１１へ通知する処理である。
【００６９】
Ｓ５０１において、リソースサーバー１０６、１０７のリソースサーバーモジュール３２１は、メッセージサーバー１１０に対して受信サーバー１０８がクライアント端末１０４、１０５からデータを受信した際の通知先として自身の登録要求を送信する。本要求の送信においては、リソースサーバー１０６、１０７のクライアントＩＤ、及び、データ種別を表すトピックＩＤ情報、となる。
【００７０】
Ｓ５０２において、メッセージサーバー１１０のメッセージモジュール３５１は、受信した登録要求を送信管理モジュール３５２に渡す。送信管理モジュール３５２は、受信したリソースサーバー１０６、１０７の登録要求に含まれる各情報を保存する。送信管理モジュール３５２が保持する送信管理データの一例を表１に示す。
【００７１】
【表１】
2020135442.tif 000003
【００７２】
送信管理モジュール３５２は、受信したトピックＩＤ、及び、そのメッセージの通知先となるクライアントＩＤとを関連付けて１つのレコードとして保存する。
【００７３】
Ｓ５０３において、送信管理モジュール３５２は送信管理データを保存したことをメッセージモジュール３５１へ応答する。
【００７４】
Ｓ５０４において、応答を受信したメッセージモジュール３５１は、リソースサーバーモジュール３２１へ結果を応答する。
【００７５】
Ｓ５０５において、応答を受信したリソースサーバーモジュール３２１は、通信管理サーバー１１１に対して登録要求が完了したことを示す登録情報を通知する。
【００７６】
Ｓ５０６において、通信管理サーバー１１１のキューモジュール３６２は、登録要求が完了したことを示す登録情報を自身に一時保存する。
【００７７】
Ｓ５０７において、キューモジュール３６２は、保存が完了したことを示す応答をリソースサーバー１０６，１０７に応答する。
【００７８】
図６にて、クライアント端末１０４、１０５がデータを送信してから、受信サーバー１０８、監視サーバー１０９、メッセージサーバー１１０を経由してリソースサーバー１０６、１０７がデータを受信するまでの処理の流れを説明する。
【００７９】
以下、クライアント端末１０４、１０５が受信サーバー１０８へデータ送信を行い、受信サーバーが一時保管するまでの処理に関して説明する。
【００８０】
Ｓ６０１において、クライアント端末１０４、１０５のデータ送信アプリケーション３１１は、受信サーバー１０８のデータ受信モジュール３３１にデータ送信を行う。クライアント端末１０４，１０５の送信するデータには、クライアント端末を識別するためのデバイスシリアルといった情報や、デバイスの状況に応じて障害情報、ステータスその他カウンタなどのあらかじめ定義されたトピックに応じた情報が含まれる。
【００８１】
Ｓ６０１にて、データ受信モジュール３３１は、クライアント端末１０４，１０５からの受信したデータを一旦自身のキューに一時保管する。
【００８２】
Ｓ６０２において、受信サーバー１０８のデータ受信モジュール３３１は、データを受信したことを示す応答をクライアント端末１０４、１０５に返す。
【００８３】
受信処理が完了した際の受信サーバー１０８が保持するデータの一例を表２で示す。
【００８４】
受信サーバー１０８においてデータを一意に識別するＩＤ、データを受信した受信日時、データ自体が１つのレコードとして管理され、受信日時順にソートされて保存されている。これらレコードは受信後一定時間経過すると表２のデータ保持テーブルから自動的に削除される。
【００８５】
【表２】
2020135442.tif 000004
【００８６】
以下、受信データを受信サーバー１０８からメッセージサーバー１１０に送信するまでの処理に関して説明する。
【００８７】
Ｓ６１１において、監視サーバー１０９のデータ監視モジュール３４１は定期的に受信サーバー１０８に対して新しい受信データの有無問い合わせを行う。この問い合わせは、定期的に行われており前回の問い合わせから次の問い合わせまでの間に受信サーバー１０８が受信したデータがあるか否かの確認である。
【００８８】
Ｓ６１２において、受信サーバー１０８に新しい受信データがあった場合、データ監視モジュール３４１は問い合わせの応答とともにデータを取得する。新しい受信データがなかった場合、データ監視モジュール３４１の処理はここで終了し次の定期起動を待つ。また、図示していないが、データを取得するとデータのコピーをデータストレージ１１２に送信する。
【００８９】
Ｓ６１３において、データ監視モジュール３４１は、取得した受信データ内に含まれているクライアント端末の識別子とデータ種別であるトピックＩＤを確認する。データ種別とは、クライアント端末の障害系のデータを表しているのか、または、カウンタ系のデータを表しているのかなど、あらかじめ定められたデータ種のことを指す。
【００９０】
Ｓ６１４において、データ監視モジュール３４１は、受信したデータにおける特定クライアント端末の識別子と特定トピックＩＤが受信除外対象に設定されているか、フィルタ管理モジュール３４２に確認する。
【００９１】
Ｓ６１５において、データ監視モジュール３４１は、フィルタ管理モジュール３４２から除外設定の有無を応答として受信する。ここで、受信データに含まれている特定クライアント端末の識別子と特定トピックＩＤが除外設定に指定されていた場合、Ｓ６２１へ処理を進める。除外設定に指定されていなかった場合、Ｓ６２２へ処理を進める。なお、受信データに含まれている特定クライアント端末の識別子が除外設定に指定されている場合にＳ６２１へ処理を進めても良い。この場合、受信データに含まれているトピックは特に考慮しないものとする。また、図示していないが、データ監視モジュール３４１は、除外設定されている特定クライアント端末における特定トピック情報が、通常のデータ受信頻度に落ち着いていることを検知すると、除外設定を削除し通常の受信状態に戻す。
【００９２】
Ｓ６２１において、データ監視モジュール３４１は、受信データを破棄して、処理を終了する。
【００９３】
Ｓ６２２において、データ監視モジュール３４１は、メッセージサーバー１１０に受信データを送信する。
【００９４】
Ｓ６２３において、メッセージサーバー１１０のメッセージモジュール３５１は、データを受信したことを示す応答をする。
【００９５】
以下、受信データをメッセージサーバー１１０からリソースサーバー１０６，１０７に送信するまでの処理に関して説明する。
【００９６】
Ｓ６３１において、メッセージサーバー１１０のメッセージモジュール３５１はデータを受け取ると、取得した受信データ内に含まれている特定クライアント端末の識別子とデータ種別を表すトピックＩＤを確認する。
【００９７】
Ｓ６３２において、メッセージモジュール３５１は受信データのトピックＩＤの値に該当するレコードが存在するか送信管理モジュール３５２へ問い合わせる。
【００９８】
Ｓ６３３において、送信管理モジュール３５２は、表１の送信管理データテーブルを確認し、メッセージモジュール３５１に結果を応答する。表１の送信管理データテーブルに該当するレコードが存在していた場合は、Ｓ６３４に処理を進める。送信管理データテーブルに該当するレコードが存在しない場合は、受信データを破棄して処理を終了する。
【００９９】
Ｓ６３４において、メッセージモジュール３５１は、フィルタ監視モジュールに対して受信した特定クライアント端末の識別子と特定トピックＩＤと通知先クライアントとが受信除外対象に設定されているかを確認する。ここでの通知先クライアントとは、キューモジュール３２２や退避用キューモジュール３２４が該当する。
【０１００】
Ｓ６３５において、メッセージモジュール３５１は、フィルタ監視モジュールから除外設定の有無を応答として受信する。メッセージモジュール３５１は、Ｓ６３３から得た受信データの送信管理テーブルとＳ６３５から得た送信除外設定の両方の設定から、送信すべきリソースサーバー１０６，１０７を確定させる。受信データを送信する先がない場合には、Ｓ６３６に処理を進める。また、転送先がある場合、Ｓ６３７に処理を進める。
【０１０１】
Ｓ６３６において、メッセージモジュール３５１は、受信データを破棄して、処理を終了する。
【０１０２】
Ｓ６３７において、メッセージモジュール３５１は、リソースサーバー１０６，１０７に対して受信データを配信する。具体的には、本実施例における通常系では、メッセージモジュール３５１は、受信データをメッセージとしてキューモジュール３２２に格納する。そして後に、リソースサーバーモジュール３２１が、キューモジュール３２２に格納されているメッセージを取得して、そのメッセージの処理を実行する。一方、本実施例における異常系では、メッセージモジュール３５１は、所定のクライアントからの受信データをメッセージとして退避用キューモジュール３２４に格納する。ここで、退避用キューモジュール３２４はあくまでも所定のクライアント端末からの単位時間当たりのリクエスト量を確認する目的で設けられるため、リソースサーバーモジュール３２１は退避用キューモジュール３２４内のメッセージの処理を実行しない。
【０１０３】
Ｓ６３８において、リソースサーバー１０６，１０７のキューモジュール３２２はデータを一時保管する。
【０１０４】
Ｓ６３９において、キューモジュール３２２は、メッセージサーバー１１０に対してデータを受信したことを示す応答を送る。
【０１０５】
なお、メッセージモジュール３５１が退避用キューモジュール３２４にデータを格納する場合についても、Ｓ６３７からＳ６３９の処理の流れは上述した内容と同様である。
【０１０６】
以上により、リソースサーバー１０６，１０７によるデータの受信処理を完了する。
【０１０７】
図７にて、リソースサーバー１０６、１０７が異常な量で送信されるデータを検知して、除外設定を行うまでの処理の流れを説明する。
【０１０８】
Ｓ７０１において、リソースサーバー１０６，１０７のリソースサーバーモジュール３２１は定期的にキューモジュール３２２に対して新しい受信データがあるかの問い合わせを行う。この問い合わせは、定期的に行われており前回の問い合わせから次の問い合わせまでの間にメッセージサーバー１１０から新しいデータを受信したか否かの確認である。
【０１０９】
Ｓ７０２において、キューモジュール３２２に新しい受信データがあった場合、リソースサーバーモジュール３２１は問い合わせの応答とともにデータを取得する。新しい受信データがなかった場合、リソースサーバーモジュール３２１の処理はここで終了し次の定期起動を待つ。
【０１１０】
Ｓ７０３において、リソースサーバーモジュール３２１は、取得した受信データ内に含まれている特定クライアント端末の識別子を確認する。
【０１１１】
Ｓ７０４において、リソースサーバーモジュール３２１は、Ｓ７０３にて確認した特定クライアント端末の識別子を利用してストレージ３２３から同一クライアント端末の旧受信データ、すなわち過去に受信したデータを要求する。
【０１１２】
Ｓ７０５において、リソースサーバーモジュール３２１は、ストレージ３２３から特定クライアント端末の過去に受信したデータを取得する。
【０１１３】
Ｓ７０６において、リソースサーバーモジュール３２１は、受信量監視モジュール３２５に今回受信したデータと過去に受信したデータの情報を提供して単位時間当たりの受信量の確認を行う。ここでの単位時間当たりの受信量とは、単位時間あたりにキューモジュール３２２が受信したデータの数のことを指す。なお、Ｓ７０６における処理で確認される対象は、単位時間当たりの受信量として、後述するＳ７１１の書き込み処理が単位時間当たりに行われた回数、つまり単位時間当たりの書き込み処理の対象となったデータの数であってもよい。さらに、キューモジュール３２２に格納されているデータの数などでもよい。
【０１１４】
Ｓ７０７において、リソースサーバーモジュール３２１は、受信量監視モジュール３２５から単位時間当たりの受信量を取得する。ここで、特定クライアント端末からの単位時間当たりのデータ受信量が閾値以上であるか否か、つまり単位時間当たりにキューモジュール３２２が受信した所定のクライアントのデータの数が所定数を超えるか否かが判定される。単位時間当たりのデータ受信量とは、ここで、単位時間当たりの受信量が閾値以下であった場合、Ｓ７１１に処理を進める。また、閾値を上回る場合、Ｓ７２１に処理を進める。なお、ここでのデータ受信量の確認は、データの処理ごとに毎回行われなくても良い。例えば、データ受信量の確認は、一定時間おきに行われても良い。
【０１１５】
Ｓ７１１において、リソースサーバーモジュール３２１は、自身のサービスを行うためデータの加工や受信データ管理をするためのデータ保管などの処理を行うためにストレージ３２３に対して書き込み等処理を行う。
【０１１６】
Ｓ７１２において、リソースサーバーモジュール３２１は、ストレージ３２３から書き込み要求に対する応答を受信する。ここまでの処理が完了するとリソースサーバーはＳ７３１へ処理を進める。
【０１１７】
Ｓ７２１において、リソースサーバーモジュール３２１は、特定のデバイスからの単位時間当たりのデータ受信量が閾値以上になっていることを検知するとメッセージサーバー１１０に対して通知から除外するための除外申請を行う。除外申請では、特定クライアント端末の識別子と特定トピックに関して除外申請を行う。さらに、リソースサーバーモジュール３２１は、退避用キューモジュールを起動させ、特定クライアント端末からの情報を退避用キューモジュールで受信する旨を申請する。特定クライアント端末からの情報を退避用キューモジュールで受信することで、特定クライアント端末の送信頻度が通常状態に戻ったことを検知して自動的に除外設定を解くことが出来るようになる。なお、Ｓ７２１では、退避用キューモジュールを起動させずに、特定クライアント端末からの特定トピックに関する除外申請のみを行っても良い。
【０１１８】
Ｓ７２２において、メッセージサーバー１１０のメッセージモジュール３５１は、特定クライアント端末と特定トピックの受信除外申請情報をフィルタ管理モジュール３５３に通知する。
【０１１９】
Ｓ７２３において、メッセージサーバー１１０のフィルタ管理を行っているフィルタ管理モジュール３５３は、フィルタ設定値を更新してメッセージモジュール３５１に対して応答する。
【０１２０】
Ｓ７２４において、メッセージモジュール３５１はリソースサーバー１０６，１０７に対して受信データ除外申請に対する応答を行う。
【０１２１】
Ｓ７２５において、リソースサーバー１０６，１０７のリソースサーバーモジュール３２１は、通信管理サーバー１１１に対して特定クライアント端末の特定データに対して除外申請を行った旨を通知する。
【０１２２】
Ｓ７２６において、通信管理サーバー１１１は、統合サービス全体における受信データとリソースサーバー１０６，１０７の利用状況を把握しており、Ｓ７２５の通知を通信管理サーバー１１１のキューモジュール３６２にて受け取り、通知に対する応答を行う。ここまでの処理が完了するとリソースサーバーはＳ７３１へ処理を進める。
【０１２３】
Ｓ７３１において、リソースサーバーモジュール３２１は、一連の業務処理が完了すると、キューモジュール３２２に一時的に保管していた受信データの削除要求を行う。
【０１２４】
Ｓ７３２において、キューモジュール３２２は、リソースサーバーモジュール３２１の要求に応じて一時的に保管していた受信データを削除する。
【０１２５】
Ｓ７３３において、リソースサーバーモジュール３２１は、キューモジュール３２２から削除要求に対する応答を受信する。
【０１２６】
以上により、リソースサーバー１０６，１０７による特定デバイスの異常検知、および、除外設定処理を完了する。
【０１２７】
図８において、各リソースサーバーで特定クライアント端末からの特定トピック情報が不要になった後、すべてのリソースサーバーで除外設定が行われてから、統合サービスの上流でフィルタが適用されるまでの処理の流れを説明する。
【０１２８】
Ｓ８０１において、通信管理サーバー１１１の通信管理モジュール３６１は、定期的にキューモジュール３６２に対して新しい登録／除外通知の有無問い合わせを行う。この問い合わせは、定期的に行われており前回の問い合わせから今回の問い合わせまでの間にリソースサーバー１０６，１０７から新しい登録／除外通知を受信したか否かの確認である。キューモジュール３６２は、図５のＳ５０５にてデータ受信の登録を受け付け、さらに、図７のＳ７２５にてデータ受信の除外の通知を受けるけることで、どのリソースサーバーでどのクライアント端末からのデータを受信しているかを統合的に管理する。
【０１２９】
Ｓ８０２において、キューモジュール３６２に新しい登録／除外通知があった場合、通信管理モジュール３６１は問い合わせの応答とともに登録／除外の通知を取得する。
【０１３０】
Ｓ８０３において、通信管理モジュール３６１はＳ８０２にて受信した登録／除外通知から、特定クライアント端末の識別子とトピックＩＤを確定する。
【０１３１】
Ｓ８０４において、通信管理モジュール３６１はストレージ３６３から特定クライアント端末の特定トピックＩＤに関する設定値を取得する。
【０１３２】
通信管理サーバー１１１によって管理されているデータの一例を表３で示す。通信管理サーバー１１１においてクライアント端末を識別するクライアントＩＤ、データ種を一意に識別するトピックＩＤ、リソースサーバー１０６，１０７における受信状態が保存されている。これらのデータは、通信管理モジュール３６１によって、逐次自動的に更新される。
【０１３３】
【表３】
2020135442.tif 000005
【０１３４】
Ｓ８０５において、通信管理モジュール３６１は、ストレージ３６３から特定クライアント端末の特定トピックＩＤに対応する設定値情報を取得する。
【０１３５】
Ｓ８０６において、通信管理モジュール３６１は、取得した登録／削除通知の情報を利用してストレージ３６３から取得した特定クライアント端末の特定トピックＩＤの設定値情報を更新する。
【０１３６】
ここで、特定クライアント端末の特定トピックＩＤに登録されているリソースサーバーがすべて除外設定になった、すなわち、このトピックＩＤが不要である場合に、Ｓ８０７へ処理が進められる。
【０１３７】
Ｓ８０７において、通信管理モジュール３６１は、監視サーバー１０９に対して特定クライアント端末の特定トピックＩＤの登録／削除状態を申請する。Ｓ８０８において、監視サーバー１０９のフィルタ管理モジュール３４２は、特定クライアント端末の特定トピックＩＤの登録／削除状態申請を受け付けて、通信管理サーバー１１１に応答する。
【０１３８】
Ｓ８０９において、通信管理モジュール３６１は、監視サーバー１０９からの応答を受け取るとＳ８０６にて更新した設定情報をストレージ３６３に保管する。Ｓ８１０において、通信管理モジュール３６１は、ストレージ３６３から保管完了を示す応答を受信する。
【０１３９】
なお、上述したように、特定クライアント端末の特定トピックＩＤに登録されている全てのリソースサーバーがＳ７２５の通知を行っていた場合に、Ｓ８０７へ処理を進めるものとして説明した。しかしながら、リソースサーバーモジュール３２１は、Ｓ７２１〜Ｓ７２４の処理を行わずに、Ｓ７２５で単位時間当たりの特定クライアント端末の特定トピックの受信データが一定数以上であることを通信管理サーバー１１１に対して通知してもよい。さらに、通信管理モジュール３６１は、通知を行ったリソースサーバーには特定クライアント端末の特定トピックの受信データが送信されないようにメッセージサーバー１１０に対して設定変更を要求しても良い。
【０１４０】
図９で示すフローチャートは、通信管理サーバー１１１の通信管理モジュール３６１が実施する処理である。通信管理モジュール３６１がリソースサーバー１０６，１０７から特定クライアント端末の特定トピックＩＤについて受信登録、または除外登録通知を受けると、本フローチャートの処理が開始される。
【０１４１】
Ｓ９０１において、通信管理モジュール３６１は、キューモジュール３６２から特定クライアント端末の特定トピックＩＤに関する受信登録通知、または除外設定通知（以下、登録／除外設定）を取得する。
【０１４２】
Ｓ９０２において、通信管理モジュール３６１は、登録／除外設定からクライアント端末の識別子とトピックＩＤを確認する。
【０１４３】
Ｓ９０３において、通信管理モジュール３６１は、ストレージ３６３から特定クライアント端末の特定トピックに関する既存の登録／除外設定を取得する。
【０１４４】
Ｓ９０４において、通信管理モジュール３６１は、新しく取得した登録／除外設定を利用して既存の登録／除外設定を更新する。Ｓ９０４の処理は、Ｓ８０６に対応する処理である。
【０１４５】
Ｓ９０５において、通信管理モジュール３６１は、取得した登録／除外設定を更新したことによって、特定クライアント端末の特定トピックＩＤに登録されているリソースサーバーがすべて除外設定になったか否かを判断する。ここで特定クライアント端末の特定トピックＩＤに登録されているリソースサーバーがすべて除外設定になったことを検知すると処理をＳ９０６に進める。また、特定クライアント端末の特定トピックＩＤに登録されているすべてのリソースサーバーが除外設定に変更したのでなければ、すなわち、以前より除外設定になっているまたは除外設定がそろっていない場合は、処理を終了する。
【０１４６】
なお、本実施例では、リソースサーバーそれぞれでデータ処理能力や処理対象とするデータの種類が異なっているため、Ｓ９０５ではすべてのリソースサーバーが除外設定になっているかどうかの判断をしている。しかしながら、各リソースサーバーがほぼ同等のデータ処理能力を備えている場合などは、一部のリソースサーバーが除外設定になっているかどうかでＳ９０５の判断を行っても良い。
【０１４７】
Ｓ９０６において、通信管理モジュール３６１は、監視サーバー１０９に対して特定クライアント端末の特定トピックＩＤをすべてのサービスに対して除外設定する。Ｓ９０６での処理によって、フィルタ管理モジュール３４２において特定クライアント端末の識別子と特定トピックＩＤの除外設定が管理されることとなり、Ｓ６２１で受信データが破棄される。したがって、特定クライアント端末から受信したデータがリソースサーバー１０６、１０７に送信されなくなるため、各リソースサーバー内の受信量監視モジュール３２５による監視の負荷がなくなる。所定のクライアント端末から受信したデータを複数のリソースサーバーが重複して監視していた負荷がなくなり、結果としてシステム全体のリソース消費量を減らすことができる。
【０１４８】
以上、本実施例で説明したように、一部のクライアントから大量のデータが送信されたことをあるリソースサーバーが検知した場合に、受信サービスシステムは、そのクライアントからの受信データをそのリソースサーバーに対して転送しないようにした。それにより、そのリソースサーバーにおいて、他の正常なクライアントからのデータ処理が遅延せずに済む。
【０１４９】
（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
【０１５０】
ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピューター（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【符号の説明】
【０１５１】
１０６、１０７  リソースサーバー
１０８  受信サーバー
１０９  監視サーバー
１１０  メッセージサーバー
１１１  通信管理サーバー
【図１】
2020135442.tif 000006
【図２】
2020135442.tif 000007
【図３】
2020135442.tif 000008
【図４】
2020135442.tif 000009
【図５】
2020135442.tif 000010
【図６】
2020135442.tif 000011
【図７】
2020135442.tif 000012
【図８】
2020135442.tif 000013
【図９】
2020135442.tif 000014