(57)【要約】【課題】  所定のクライアントから大量のデータが送信された場合に、受信サービスにおいて他のクライアントのデータ処理を遅延させないための仕組みを提供することを目的とする。【解決手段】  複数のクライアント端末と、複数のクライアント端末からデータを受信する受信サービスシステムと、を含むシステムであって、受信サービスシステムは、所定の処理の対象となるデータを受信する第１の受信手段と、前記所定の処理の対象とならないデータを受信する第２の受信手段と、を有する。複数のクライアント端末それぞれは、クライアント端末から第１の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えると判定された場合、第２の受信手段に対してデータを送信することを示す第２の送信ルールに従い、クライアント端末で発生したイベントに関するデータを第２の受信手段に対して送信する。【選択図】  図９
2020144763.tif 000002
【特許請求の範囲】
【請求項１】
複数のクライアント端末と、前記複数のクライアント端末からデータを受信する受信サービスシステムと、を含むシステムであって、
前記受信サービスシステムは、
前記複数のクライアント端末から、所定の処理の対象となるデータを受信する第１の受信手段と、
前記複数のクライアント端末のうちの所定のクライアント端末から、前記所定の処理の対象とならないデータを受信する第２の受信手段と、を有し、
前記複数のクライアント端末それぞれは、
前記第１の受信手段に対してデータを送信することを示す第１の送信ルールを保持する保持手段と、
前記第１の送信ルールに従い、前記クライアント端末からデータを前記第１の受信手段に対して送信する第１の送信手段と、を有し、
前記保持手段は、前記クライアント端末から前記第１の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えると判定された場合、前記第２の受信手段に対してデータを送信することを示す第２の送信ルールを保持し、
前記第１の送信手段は、前記第２の送信ルールに従い、前記クライアント端末で発生したイベントに関するデータを前記第２の受信手段に対して送信することを特徴とするシステム。
【請求項２】
前記受信サービスシステムは、
前記第２の送信ルールを前記所定のクライアント端末に対して送信する第２の送信手段を有し、
前記受信サービスシステムの前記第２の送信手段は、前記複数のクライアント端末のうちの所定のクライアント端末から前記第１の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えると判定された場合、前記第２の送信ルールを前記所定のクライアント端末に対して送信し、
前記所定のクライアント端末の前記保持手段は、前記送信された前記第２の送信ルールを保持することを特徴とする請求項１に記載のシステム。
【請求項３】
前記受信サービスシステムの前記第２の送信手段は、前記所定のクライアント端末から前記第２の受信手段に対して送信されるデータ量が所定値以下となった場合、前記保持手段で保持される前記送信ルールを変更するための指示を前記所定のクライアント端末に対して送信し、
前記所定のクライアント端末の前記保持手段は、前記第１の送信ルールを保持することを特徴とする請求項２に記載のシステム。
【請求項４】
前記システムには、前記複数のクライアント端末それぞれの状態情報を管理する状態管理サーバが更に含まれ、
前記受信サービスシステムの前記第２の送信手段は、前記状態管理サーバで管理される前記所定のクライアント端末の状態情報を変更することで、前記第２の送信ルールを前記所定のクライアント端末に対して送信することを特徴とする請求項２または３に記載のシステム。
【請求項５】
前記複数のクライアント端末それぞれは、
前記受信サービスシステムからの指示なしに、前記保持手段が保持する前記送信ルールを変更する変更手段を更に有し、
前記変更手段は、
前記クライアント端末から前記第１の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えると判定された場合、前記保持手段が保持する送信ルールを前記第１の送信ルールから前記第２の送信ルールに変更し、
前記クライアント端末から前記第２の受信手段に対して送信されるデータ量が所定値以下であると判定された場合、前記保持手段が保持する送信ルールを前記第２の送信ルールから前記第１の送信ルールに変更することを特徴とする請求項１に記載のシステム。
【請求項６】
前記受信サービスシステムは、
前記複数のクライアント端末それぞれから前記第１の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えるか否かを判定する第１の判定手段を更に有することを特徴とする請求項１乃至５のいずれか１項に記載のシステム。
【請求項７】
前記受信サービスシステムは、
前記所定のクライアント端末から前記第２の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えるか否かを判定する第２の判定手段を更に有することを特徴とする請求項１乃至６のいずれか１項に記載のシステム。
【請求項８】
前記複数のクライアント端末それぞれは、
前記クライアント端末から前記第１の受信手段または前記第２の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えるか否かを判定する第３の判定手段を更に有することを特徴とする請求項１乃至７のいずれか１項に記載のシステム。
【請求項９】
前記システムには、前記受信サービスシステムから受け取ったクライアント端末のデータについての前記所定の処理を実行するリソースサービスシステムが更に含まれ、
前記リソースサービスシステムは、前記第２の受信手段が受信したデータについての前記所定の処理を実行せず、前記第１の受信手段が受信したデータについての前記所定の処理を実行することを特徴とする請求項１乃至８のいずれか１項に記載のシステム。
【請求項１０】
前記受信サービスシステムは、
前記第１の送信ルールまたは前記第２の送信ルールを前記所定のクライアント端末に対して送信する第２の送信手段と、
前記第２の送信手段が前記所定のクライアント端末に対して送信ルールを送信した場合に、前記第１の送信手段が前記所定のクライアント端末に対して前記送信ルールを送信したことを示すイベントを、前記リソースサービスシステムに対して通知する通知手段と、を更に有することを特徴とする請求項９に記載のシステム。
【請求項１１】
前記保持手段は、前記クライアント端末から前記第１の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えてから一定時間後、前記クライアント端末から前記第２の受信手段に対して単位時間あたりに送信されるデータ量が所定値以下でない場合、前記第１の受信手段および前記第２の受信手段のいずれに対してもデータを送信しないことを示す第３の送信ルールを保持し、
前記第１の送信手段は、前記第３の送信ルールに従い、前記クライアント端末で発生したイベントに関するデータを前記第１の受信手段および前記第２の受信手段のいずれに対しても送信しないことを特徴とする請求項１乃至１０のいずれか１項に記載のシステム。
【請求項１２】
複数のクライアント端末と、前記複数のクライアント端末からデータを受信する受信サービスシステムと、を含むシステムの制御方法であって、
前記複数のクライアント端末それぞれが、前記受信サービスシステムの第１の受信部に対してデータを送信することを示す第１の送信ルールを保持する保持工程と、
前記複数のクライアント端末それぞれが、前記第１の送信ルールに従い、前記クライアント端末からデータを前記第１の受信部に対して送信する第１の送信工程と、
前記受信サービスシステムが、前記複数のクライアント端末から、所定の処理の対象となるデータを前記第１の受信部で受信する第１の受信工程と、
前記受信サービスシステムが、前記複数のクライアント端末のうちの所定のクライアント端末から、前記所定の処理の対象とならないデータを前記第１の受信部とは別の第２の受信部で受信する第２の受信工程と、を有し、
前記保持工程では、前記クライアント端末から前記第１の受信部に対して単位時間あたりに送信されるデータ量が所定値を超えると判定された場合、前記第２の受信部に対してデータを送信することを示す第２の送信ルールが保持され、
前記第１の送信工程では、前記第２の送信ルールに従い、前記クライアント端末で発生したイベントに関するデータが前記第２の受信部に対して送信されることを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のクライアント端末と、前記複数のクライアント端末からデータを受信する受信サービスシステムと、を含むシステムおよび制御方法に関する。
【背景技術】
【０００２】
近年、インターネットに家電製品や自動車などをクライアント端末として接続する「Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ」（以降、ＩｏＴと称する）を実現するシステムが利用されている。また、画像形成装置の多機能化が進み、Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｒｉｎｔｅｒ（以降、ＭＦＰと称する）と呼ばれる複合機もＩｏＴクライアントとして対応することが可能となった。
【０００３】
ＩｏＴシステムは、ＩｏＴクライアントに接続されたセンサー情報など膨大な量のデータを収集、分析することで、ＩｏＴクライアント（単にクライアントとも称する）及びそれを利用するユーザに対してサービス、付加価値を提供する。ＩｏＴシステムにおいては、前述した膨大な量のデータを、同じく膨大な数のクライアントから受信するようになってきている。
【０００４】
このような膨大なデータをリアルタイムに受信する処理では、刻一刻と変動するトラフィックの監視が重要である。トラフィックのデータを受信するサーバは、ＡＰＩを備えた従来型のリソースサーバーが単独で対応することは困難である。そこで、データの収集には、データ受信専用のサービス（受信サービス）を利用し、サービスを提供する処理（リソースサービス）は非同期処理として分離して対応することが一般的になりつつある。
【０００５】
ＩｏＴクライアントは受信サービスにデータを送信し、受信サービスはデータをバッファリングし、リソースサービスからのデータ受信要求に対してバッファリングからのデータを供給する。このようにして、リソースサービスはＩｏＴクライアントからの変動する膨大なトラフィックを意識することなく、データの処理に専念することができる。
【０００６】
また、ストリーム受信サービスからデータを転送されるリソースサービスは、複数存在することが可能である。リソースサービスはストリーム受信サービスとは非同期で処理を実行しているため、ＩｏＴシステムの開発において、提供するサービスの種類ごとに柔軟にリソースサービスを追加することができる。
【０００７】
ここで特許文献１には、監視対象物のセンサが出力するセンサデータをゲートウェイから受信するサーバがセンサデータに基づく処理を行うことで、監視対象物の故障予測を行うデータ収集システムについて記載されている。サーバは、監視対象物に異常または異常の予兆が発生したことを検出した場合、収集するセンサデータの種類や収集頻度を増やすための収集ルールをゲートウェイに送信することが記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１６−１６３２４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
例えばハードディスク故障などを起こしたクライアントが、異常なデータを通常よりも高頻度で大量に受信サービスに送信する場合がある。しかしながら、データの処理を実行する受信サービス内のリソースの量には制限がある。そのため、一部のクライアントが通常よりも高頻度で大量のデータを送信すると、受信サービスが処理すべきデータ量が増え、結果として、受信サービスにおいて他の正常なクライアントからのデータの処理に遅延が生じてしまう。
【００１０】
そこで本発明は、所定のクライアントから大量のデータが送信された場合に、受信サービスにおいて他のクライアントのデータ処理を遅延させないための仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明は、複数のクライアント端末と、前記複数のクライアント端末からデータを受信する受信サービスシステムと、を含むシステムであって、前記受信サービスシステムは、前記複数のクライアント端末から、所定の処理の対象となるデータを受信する第１の受信手段と、前記複数のクライアント端末のうちの所定のクライアント端末から、前記所定の処理の対象とならないデータを受信する第２の受信手段と、を有し、前記複数のクライアント端末それぞれは、前記第１の受信手段に対してデータを送信することを示す第１の送信ルールを保持する保持手段と、前記第１の送信ルールに従い、前記クライアント端末からデータを前記第１の受信手段に対して送信する第１の送信手段と、を有し、前記保持手段は、前記クライアント端末から前記第１の受信手段に対して単位時間あたりに送信されるデータ量が所定値を超えると判定された場合、前記第２の受信手段に対してデータを送信することを示す第２の送信ルールを保持し、前記第１の送信手段は、前記第２の送信ルールに従い、前記クライアント端末で発生したイベントに関するデータを前記第２の受信手段に対して送信することを特徴とする。
【発明の効果】
【００１２】
本発明により、所定のクライアントから大量のデータが送信された場合に、受信サービスにおいて他のクライアントのデータ処理が遅延することを回避できる。
【図面の簡単な説明】
【００１３】
【図１】システム全体図
【図２】ハードウェア構成図
【図３】ソフトウェア構成図
【図４】クライアント端末がストリーム受信サーバにデータを送信するまでの処理のシーケンス
【図５】クライアント端末がストリーム受信サーバにデータを送信する処理のフローチャート
【図６】コレクションフィルタの例を示す図
【図７】イベントデータの例を示す図
【図８】ストリーム処理モジュールの処理のシーケンス
【図９】ストリーム処理モジュールの処理のフローチャート
【図１０】実施例２におけるストリーム処理モジュールの処理のフローチャート
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態について図面を用いて説明する。
【００１５】
（実施例１）
本実施例においては、インターネット上の各サーバにアプリケーションが設置されていることとする。各アプリケーションはクライアント端末と連携し、様々な機能を提供することとする。このような機能を提供する実体をサービスと呼称し、機能をクライアント端末に提供することをサービスの提供と呼称する。
【００１６】
図１は、本実施例に係る情報処理システムであるデータ収集基盤システムの全体構成を示す図である。
【００１７】
ネットワーク１００は本システムの各構成要素を接続するＷｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（以降、ＷＡＮと称する）である。ネットワーク１０１、１１１、１２１は本システムの各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（以降、ＬＡＮと称する）である。クライアント端末１０２は、サービスを利用するためのパソコン、モバイル端末、画像形成装置などの機器である。
【００１８】
第１の認証認可サーバ１１２は、クライアント端末１０２がサービスを利用するために必要となる認証・認可を実現するためのサーバである。第１の認証認可サーバ１１２は、クライアント端末１０２のデータ収集サーバ１１３、データ利用サーバ１１４へのアクセスを制御する。
【００１９】
データ収集サーバ１１３は、クライアント端末１０２のデータを収集するサービスと後述のデータ利用サーバ１１４へ収集したデータを通知するサービスを提供するサーバである。データの収集には後述のストリーム受信サーバ１２３、データの通知には後述のメッセージサーバ１２４を利用する。
【００２０】
データ利用サーバ１１４は、データ収集サーバ１１３で収集したデータを利用したサービスを提供するサーバである。例えば、データ利用サーバ１１４はクライアント端末１０２のデータをバックアップするサービスや、クライアント端末１０２に接続されたセンサー情報を分析するサービスなどがある。データ収集サーバ１１３からのデータの取得は後述のメッセージキューサーバ１２５からメッセージを取得することで行う。
【００２１】
なお、データ利用サーバ１１４は、サーバレスアーキテクチャで実行されるアプリケーションで実現されても良い。具体的には、特定のコンピューティングリソースに対して発生したイベントに応じて、軽量な処理を実行するイベント駆動型コンピューティングサービスという、クラウドコンピューティングサービスで提供されるサービスを指す。例えば、ＡＷＳ  Ｌａｍｂｄａ、Ｇｏｏｇｌｅ  Ｃｌｏｕｄ  Ｆｕｎｃｔｉｏｎｓ、Ａｚｕｒｅ  Ｆｕｎｃｔｉｏｎｓ等がある。
【００２２】
第２の認証認可サーバ１２２は、第１の認証認可サーバ１１２とは異なるサーバであり、ストリーム受信サーバ１２３、メッセージサーバ１２４、メッセージキューサーバ１２５への認証・認可を実現し、アクセスを制御するサーバである。
【００２３】
ストリーム受信サーバ１２３は、ストリームによるデータ受信を行うサーバであり、クライアント端末１０２が送信するストリームデータを受信する。
【００２４】
メッセージサーバ１２４は、本システムを構成する各サーバで生成されたイベントをメッセージとして通知するサーバである。メッセージサーバ１２４は、登録された通知先と、通知する条件に基づき、本システムの構成要素のいずれかが生成したイベントを通知先に対してプッシュ通知を行う。メッセージキューサーバ１２５は、本システムを構成するイベントを送信するサーバからのイベントをメッセージとして格納し、メッセージを受信するサーバに提供するためのサーバである。
【００２５】
退避用ストリーム受信サーバ１２６は、ストリーム受信サーバ１２３と同様の機能を備えており、クライアント端末１０２が送信するストリームデータを受信する。退避用ストリーム受信サーバ１２６は、データを大量に送信する異常状態の１以上のクライアント端末からのデータを受信する役割を担う。ストリーム受信サーバ１２３で受信したデータは、メッセージサーバ１２４がメッセージキューサーバ１２５に格納する対象となる。一方、退避用ストリーム受信サーバ１２６で受信したデータは、メッセージサーバ１２４がメッセージキューサーバ１２５に格納する対象とはならない。
【００２６】
特に、ストリーム受信サーバ１２３、データ収集サーバ１１３、およびメッセージサーバ１２４が、本実施例における受信サービスシステムとして機能する。また、メッセージキューサーバ１２５、およびデータ利用サーバ１１４が、本実施例におけるリソースサービスシステムとして機能する。なお、本実施例において、クライアント端末１０２及び各サーバ１１２乃至１１４、１２２乃至１２５はそれぞれ１台で図示しているが、複数台で構成されていても良い。
【００２７】
図２は、本実施例に係るクライアント端末１０２、及び各サーバ１１２乃至１１４、１２２乃至１２５を構成する情報処理装置の一般的なハードウェア構成である。なお、各サーバ１１２乃至１１４、１２２乃至１２５は、図２に示すコンピューターの各ハードウェアの機能がそれぞれ、仮想マシンソフトウェアによってアプリケーションソフトウェアとして実現され、物理ハードウェア要素と同様の挙動をとるものとする。
【００２８】
ＣＰＵ２０１は、ＲＯＭ２０３のプログラムＲＯＭに記憶された、あるいはハードディスクなどの外部メモリ２１１からＲＡＭ２０２にロードされたオペレーティングシステムやアプリケーションなどのプログラムを実行する。またＣＰＵ２０１は、システムバス２０４に接続される各ブロックを制御する。後述する各シーケンスの処理は、ＣＰＵ２０１が実行するプログラムによって実現される。
【００２９】
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリアなどとして機能する。
【００３０】
操作部Ｉ／Ｆ２０５は、操作部２０９からの入力を制御する。
【００３１】
ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。
【００３２】
ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスクなどの外部メモリ２１１におけるデータアクセスを制御する。
【００３３】
ネットワークコントローラ２０８は、ＷＡＮ１００あるいはＬＡＮ１０１、１０２、１０３を介して接続されたサーバや他の機器との通信制御処理を実行する。
【００３４】
なお、後述する全ての説明においては、特に断りのない限り実行のハードウェア上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は外部メモリ２１１にインストールされたアプリケーションプログラムである。
【００３５】
図３は、本実施例に係るクライアント端末１０２及び各サーバ１１２乃至１１４、１２２乃至１２５のソフトウェア構成を示す図である。各々のモジュールが実行されることで各々の機能を実現する。
【００３６】
図３（Ａ）はクライアント端末１０２のモジュール構成を表す図である。クライアント端末１０２は、トークンプロバイダモジュール３０１、データ送信モジュール３０２、機器内モジュール３０３、データ保持モジュール３０４、コレクションフィルタ受信モジュール３０５を持つ。
【００３７】
トークンプロバイダモジュール３０１は、第１の認証認可サーバ１１２に対して、クライアント端末の認証要求、アクセストークンの発行依頼や取得を行う。
【００３８】
データ送信モジュール３０２は、データ収集サーバ１１３が提供するサービスを利用したり、クライアント端末１０２のイベントデータをストリーム受信サーバ１２３に送信したりする。データ送信モジュール３０２がストリーム受信サーバ１２３に送信するイベントデータは、後述のデータ保持モジュール３０４に格納されているイベントデータをコレクションフィルタの記述に従って送信する。イベントデータの保持するデータについては後述の図７にて説明を行う。
【００３９】
コレクションフィルタとは、データ保持モジュール３０４で保持されているイベントデータのうち、どのイベントデータをどの頻度で送付するかという送信ルールが定義されているファイルである。コレクションフィルタの保持するデータについては後述の図６にて説明を行う。
【００４０】
機器内モジュール３０３は、クライアント端末１０２を構成するモジュールであり、機器の状態をはじめとした各種イベントデータが発生した際に後述するデータ保持モジュール３０４にイベントデータを格納する。各種イベントデータとは例えばジョブの実行がされたときの開始イベント、終了イベント、またセンサーなどの異常を検知したときの異常イベントなどが挙げられる。データ保持モジュール３０４は、機器内モジュール３０３からのイベントデータを保持するモジュールである。コレクションフィルタ受信モジュール３０５は、後述するコレクションフィルタ送信モジュール３２３からコレクションフィルタを受信するモジュールである。
【００４１】
第１の認証認可サーバ１１２は、第１の認証認可モジュール３１１、第１のクライアント管理モジュール３１２を持つ。第１の認証認可モジュール３１１は、クライアント端末１０２からの認証要求に対する処理、認証されたクライアント端末１０２の認可処理を行う。第１のクライアント管理モジュール３１２は、認証処理及び認可処理を行ったクライアント端末の認証情報としてＩＤやシークレットを管理する。また他のサーバからのリクエストに応じて、管理しているクライアント端末１０２の認証情報を削除するＡＰＩを提供する。
【００４２】
データ収集サーバ１１３は、トークン取得モジュール３２１とストリーム処理モジュール３２２を持つ。トークン取得モジュール３２１は、データ収集サーバ１１３、クライアント端末１０２がサーバ１２３乃至１２５のサービスを利用するためのトークンを第２の認証認可サーバ１２２から取得するモジュールである。詳しくは後述の図４のシーケンスの中で説明を行う。
【００４３】
ストリーム処理モジュール３２２は、ストリーム受信サーバ１２３のストリームデータに対する処理を行うモジュールである。ストリーム処理モジュール３２２は受信したストリームデータの内容を、メッセージサーバ１２４、メッセージキューサーバ１２５を利用してデータ利用サーバ１１４にイベントとして通知する。詳しくは図８のシーケンス、図９のフローチャートを用いて説明を行う。コレクションフィルタ送信モジュール３２３は、クライアント端末１０２へコレクションフィルタを送信するためのモジュールである。
【００４４】
データ利用サーバ１１４は、トークン取得モジュール３３１とメッセージ処理モジュール３３２を持つ。トークン取得モジュール３３１は、データ利用サーバ１１４がサーバ１２３乃至１２５のサービスを利用するためのトークンを第２の認証認可サーバ１２２から取得するモジュールである。メッセージ処理モジュール３３２は、メッセージキューサーバ１２５に保持されているメッセージを処理するモジュールである。メッセージ処理モジュール３３２は、メッセージを処理することで、ストリーム処理モジュール３２２からのイベントの通知を受信し処理することができる。
【００４５】
第２の認証認可サーバ１２２は、第２の認証認可モジュール３４１、第２のクライアント管理モジュール３４２を持つ。第２の認証認可モジュール３４１は、クライアントであるクライアント端末１０２や各サーバ１１３、１１４からの認証要求に対する処理、認証されたクライアントの認可処理を行う。第２のクライアント管理モジュール３４２は、認証処理及び認可処理を行った各サーバ１１３、１１４の認証情報としてＩＤやシークレットを管理する。
【００４６】
ストリーム受信サーバ１２３はストリーム受信モジュール３５１を持つ。ストリーム受信モジュール３５１は、ストリーム情報を受信し、保持する機能を提供する。
【００４７】
メッセージサーバ１２４は、メッセージモジュール３６１と送信管理モジュール３６２を持つ。メッセージモジュール３６１は、メッセージの送信の機能を提供する。送信管理モジュール３６２は、メッセージモジュール３６１が受信したメッセージをどの宛先に送信するかの送信先の管理機能を提供する。
【００４８】
メッセージキューサーバ１２５は、メッセージキューモジュール３７１を持つ。メッセージキューモジュール３７１は受信したメッセージをキューに保持する機能を提供する。
【００４９】
第１の認証認可サーバ１１２は、表Ａのクライアント管理テーブルで、クライアントを一意に識別するためのクライアントＩＤとクライアントを認証するための公開鍵、さらにはクライアント端末１０２を一意に識別するためのデバイスシリアルを管理する。
【００５０】
第１の認証認可モジュール３１１は、クライアントＩＤと公開鍵を元にクライアント端末１０２を認証し、クライアント端末１０２のデバイスシリアルを特定する。
【００５１】
【表１】
2020144763.tif 000003
【００５２】
クライアント端末１０２のトークンプロバイダモジュール３０１は表Ｂのクライアント管理テーブルに示すように、自らの端末用のクライアントＩＤと秘密鍵を保持している。
【００５３】
【表２】
2020144763.tif 000004
【００５４】
本実施例では、クライアントＩＤと非対称鍵を用いた認証を前提として説明するが、前述の通り認証方式は特に問わず、クライアントＩＤとシークレットによる認証といった他の方法でも良い。
【００５５】
同様に、第２の認証認可サーバ１２２は、表Ｃのクライアント管理テーブルに示すように、サーバを一意に識別するクライアントＩＤとサーバを認証するためのシークレットを管理しており、第２の認証認可モジュール３４１はその情報をもとにサーバを認証する。
【００５６】
【表３】
2020144763.tif 000005
【００５７】
データ収集サーバ１１３のトークン取得モジュール３２１、データ利用サーバ１１４のトークン取得モジュール３３１は、表Ｄのクライアント管理テーブルに示すように、認証を制御すべきクライアントのクライアントＩＤとシークレットを保持している。
【００５８】
【表４】
2020144763.tif 000006
【００５９】
図４は、クライアント端末１０２がストリーム受信サーバ１２３へイベントを送信する通常の処理の流れを示したシーケンスである。
【００６０】
Ｓ４０１において、クライアント端末１０２のデータ送信モジュール３０２は、トークンプロバイダモジュール３０１にトークンの発行要求を送信する。トークンプロバイダモジュール３０１は、表Ｂで管理するクライアントＩＤと秘密鍵を利用してアサーションを作成し、アサーションとともにトークン発行リクエストを生成する。本実施例では、アサーションはＲＦＣ７５１９にて決められたＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ（以降、ＪＷＴと称する）を想定しており、ＪＷＴにはクライアントＩＤなどの情報が含まれる。
【００６１】
Ｓ４０２において、トークンプロバイダモジュール３０１は第１の認証認可サーバ１１２の第１の認証認可モジュール３１１にアサーションを送信する。
【００６２】
第１の認証認可モジュール３１１は、Ｓ４０２においてアサーションを送信したクライアント端末に該当する公開鍵を表Ａから取得して、アサーションの署名検証を行う。検証に成功した場合、第１の認証認可モジュール３１１は、アクセストークンＡ１を発行し、レスポンスする。レスポンスを受信したトークンプロバイダモジュール３０１は、アクセストークンＡ１をデータ送信モジュール３０２にレスポンスする。アクセストークンＡ１は、第１の認証認可サーバ１１２によってアクセス制御が行われるデータ収集サーバ１１３へのクライアント端末１０２がアクセスするためのものである。
【００６３】
本実施例では、アクセストークンはＪＷＴを想定しており、クライアントＩＤやクライアント端末１０２のデバイスシリアルといった情報、トークンの有効期限などの情報が含まれる。
【００６４】
Ｓ４０３において、データ送信モジュール３０２はＳ４０２のレスポンスとして受信したアクセストークンＡ１を利用して、データ収集サーバ１１３のトークン取得モジュール３２１にトークン発行要求を送信する。
【００６５】
Ｓ４０４において、トークン取得モジュール３２１は受信したトークン発行要求に含まれるアクセストークンＡ１の検証を行う。トークン取得モジュール３２１は第１の認証認可モジュール３１１が発行したＪＷＴを検証するための公開鍵を保持しており、ＪＷＴを検証することでクライアントの認可を行う。ＪＷＴの検証では、トークン取得モジュール３２１はＪＷＴの署名が正しいかを公開鍵を用いて検証し、さらにＪＷＴの有効期間中かどうかを検証する。またアクセストークンＡ１を検証した結果、クライアント情報を取得することが可能であり、アクセス元のクライアント端末１０２をデバイスシリアルで識別できる。なお、トークン取得モジュール３２１は第１の認証認可モジュール３１１にトークンの検証を依頼し、検証結果とクライアント情報を取得するといった別の実施形でも良い。リクエストを受けたトークン取得モジュール３２１はＳ４０５、Ｓ４０６において受信したリクエストに対する処理を行う。
【００６６】
Ｓ４０５において、トークン取得モジュール３２１は第２の認証認可サーバ１２２の第２の認証認可モジュール３４１にトークン発行要求を送信する。トークン発行要求は表ＤのクライアントＩＤとシークレットとともに送信する。トークン発行要求を受信した第２の認証認可モジュール３４１は、表Ｃで管理するクライアントＩＤとシークレットと、トークン発行要求に含まれるクライアントＩＤとシークレットとが一致する場合には、アクセストークンＢを発行してレスポンスする。アクセストークンＢは、第２の認証認可サーバ１２２にアクセスするためのものである。
【００６７】
Ｓ４０６において、アクセストークンＢを取得したトークン取得モジュール３２１は、第２の認証認可モジュール３４１に対して、ＩＤトークン発行要求を送信する。ＩＤトークン発行要求では、トークン取得モジュール３２１はアクセストークンＢとＳ４０４の検証結果から取得したクライアント端末１０２のクライアントＩＤを送信する。第２の認証認可モジュール３４１は、受信したクライアントＩＤ用のＩＤトークンを発行する。
【００６８】
ＩＤトークンとは、クライアント端末１０２を確かに認証したことを証明するトークンである。本実施例では、クライアント端末１０２の認証は、Ｓ４０４においてトークン取得モジュール３２１がアクセストークンＡ１を検証することで確認している。第２の認証認可モジュール３４１はトークン取得モジュール３２１に対してクライアントＩＤとシークレットを提供する形で信頼関係を結んでおり、トークン取得モジュール３２１がクライアント端末１０２を認証した結果を信頼する。第２の認証認可モジュール３４１はその信頼をもとにＩＤトークンを発行している形となる。また、ＩＤトークンはＪＷＴ形式を想定しており、第２の認証認可モジュール３４１は署名を検証することでＩＤトークンを検証可能である。
【００６９】
Ｓ４０７において、ＩＤトークンを受信したクライアント端末１０２のデータ送信モジュール３０２は、第２の認証認可サーバ１２２の第２の認証認可モジュール３４１にトークン発行要求を行う。この要求にはＳ４０４で取得したＩＤトークンを含める。要求を受けた第２の認証認可モジュール３４１はＩＤトークンの検証を行い、アクセストークンＣを発行しレスポンスする。アクセストークンＣは、ストリーム受信サーバ１２３へアクセスするためのものである。
【００７０】
Ｓ４０８において、アクセストークンＣを受信したクライアント端末１０２のデータ送信モジュール３０２は、ストリーム受信サーバ１２３のストリーム受信モジュール３５１にデータ送信を行う。本データ送信ではアクセストークンＣと、アクセストークンＡ１を送信する。データ送信要求を受信したストリーム受信モジュール３５１はアクセストークンＣを検証して問題が無ければ、アクセストークンＡ１とデータのペアを保持する。
【００７１】
以上により、クライアント端末１０２はストリーム受信サーバ１２３へのデータ送信を完了する。
【００７２】
図４で示したＳ４０８にて説明を行ったデータ送信処理について、図５のフローチャートを用いて詳細に説明を行う。図５はコレクションフィルタ６０１に従ってストリーム受信モジュール３５１にイベントデータを送信するデータ送信モジュール３０２の処理のフローチャートである。
【００７３】
コレクションフィルタ６０１は図６に示すようなデータである。図６（Ａ）は通常モード時のコレクションフィルタ、図６（Ｂ）は送信先変更時のコレクションフィルタの例である。コレクションフィルタ６０１には、収集対象のデータグループを表すｃｏｌｌｅｃｔｉｏｎ６０２と、イベントデータをストリーム受信モジュール３５１へ送信する送信タイミング６０３、送信先を表すｒｏｕｔｅ６０４が記載されている。
【００７４】
図６（Ａ）の例では、エラーデータが生成されたら逐次Ｓｔｒｅａｍという識別子で表現されるストリーム受信モジュール３５１へデータを送信することを示す。図６（Ｂ）と図６（Ａ）の違いは、Ｒｏｕｔｅに設定されている値が、ｓｔｒｅａｍか、ｉｒｒｅｇｕｌａｒＳｔｒｅａｍかであり、このｒｏｕｔｅの値を変更することで、あるｃｏｌｌｅｃｔｉｏｎが示すデータの送り先を変更することが可能となる。
【００７５】
図５のフローチャートは、データ送信モジュール３０２がコレクションフィルタ６０１の記述に従って、イベントデータを送信するタイミングで実行される。実行時には引数として実行するコレクションフィルタ６０１のｃｏｌｌｅｃｔｉｏｎ６０２とｒｏｕｔｅ６０４が渡される。
【００７６】
Ｓ５０１において、データ送信モジュール３０２は引数で渡されたｃｏｌｌｅｃｔｉｏｎ６０２とｒｏｕｔｅ６０４を取得する。
【００７７】
Ｓ５０２において、データ送信モジュール３０２はデータ保持モジュール３０４で保持されているイベントデータ７０１から、Ｓ５０１で取得したｃｏｌｌｅｃｔｉｏｎに一致するイベントデータ一覧を取得する。イベントデータ７０１は図７に示すデータであり、クライアント端末１０２内でイベントを一意に識別するイベントＩＤ７０２、クライアント端末１０２を一意に識別するデバイスシリアル７０３、イベントが発生したｃｏｌｌｅｃｔｉｏｎ７０４が記載される。さらに、イベントデータ７０１には、発生したイベント名７０５と発生日時７０６が記載される。Ｓ５０２では、Ｓ５０１で取得したｃｏｌｌｅｃｔｉｏｎに一致するイベントデータを一覧として取得する。
【００７８】
Ｓ５０３において、データ送信モジュール３０２はＳ５０２で取得したイベントデータ一覧をストリーム受信モジュール３５１にアクセストークンＣと、アクセストークンＡ１とともに送信する。この時の送信先は、Ｓ５０１で取得した送信先によって定義された宛先とする。
【００７９】
Ｓ５０４において、データ送信モジュール３０２はＳ５０４で送信したイベントデータ一覧をデータ保持モジュール３０４から削除する。
【００８０】
以上、説明した図５のフローチャートによって、データ送信モジュール３０２は、ｒｏｕｔｅによって指示された送信先に、指定されたｃｏｌｌｅｃｔｉｏｎに含まれるイベントデータを送信することが可能となる。
【００８１】
図４、図５で示した処理が完了した際にストリーム受信サーバ１２３が保持するデータの一例を表Ｅで示す。ストリーム受信サーバ１２３においてデータを一意に識別するＩＤ、データを受信した受信日時、受信したアクセストークン、デバイスシリアル、ｃｏｌｌｅｃｔｉｏｎの情報が１レコードとして管理され、受信日時順にソートされて保存されている。
【００８２】
【表５】
2020144763.tif 000007
【００８３】
以降図８、図９を用いてデータ収集サーバ１１３のストリーム処理モジュール３２２での処理についての説明を行う。
【００８４】
図８と図９はそれぞれデータ収集サーバ１１３のストリーム処理モジュール３２２が提供する処理の一連の流れを示したシーケンスとフローチャートである。
【００８５】
本処理の詳細な説明は図９のフローチャートを用いて説明し、その他のモジュールとの連携部分についてはシーケンスを用いて説明する。本処理は、データ収集サーバ１１３によって定期的に実行される処理である。
【００８６】
Ｓ９０１（Ｓ８０１）において、ストリーム処理モジュール３２２は、第２の認証認可モジュール３４１にトークン発行要求を送信する。本処理はＳ４０５と同様の処理である。第２の認証認可モジュール３４１は、トークン発行要求を受信して、ストリーム受信サーバ１２３、メッセージサーバ１２４にアクセスするために必要なアクセストークンＢを発行しストリーム処理モジュール３２２にレスポンスする。
【００８７】
Ｓ９０２（Ｓ８０２）において、ストリーム処理モジュール３２２はストリーム受信サーバ１２３のストリーム受信モジュール３５１にレコード取得をアクセストークンＢとともに要求する。レコード取得要求を受信したストリーム受信モジュール３５１は、アクセストークンＢを検証し、問題がなければ表Ｅのストリームデータ保持テーブルで管理されるレコードから受信日の古いレコードから順にストリーム処理モジュール３２２にレスポンスする。受信したレコードを移行イベントレコードと称す。
【００８８】
Ｓ９０３において、ストリーム処理モジュール３２２はＳ９０２で受信したイベントレコードからアクセストークンＡ１を取得する。Ｓ９０４において、ストリーム処理モジュール３２２はＳ９０３で取得したアクセストークンＡ１の検証を行う。検証ではアクセストークンＡ１の署名、有効期間のチェックを行う。
【００８９】
Ｓ９０５において、ストリーム処理モジュール３２２はＳ９０４の検証で問題がなければＳ９０６に進む。問題がある場合には処理を終了する。Ｓ９０６において、ストリーム処理モジュール３２２はＳ９０２で取得したイベントレコードのデバイスシリアルを取得する。Ｓ９０７において、ストリーム処理モジュール３２２はＳ９０２で取得したイベントレコードのコレクションを取得する。Ｓ９０８において、ストリーム処理モジュール３２２はＳ９０２で取得したイベントレコードの受信日時を取得する。
【００９０】
Ｓ９０９において、ストリーム処理モジュール３２２は、同じクライアント端末１０２から受信サービスシステムに対して単位時間あたりに送信されるデータ量の流量チェックを行う。本実施例では、同じイベントかつ同じコレクションのデータについての流量チェックとして説明するが、これに限られない。
【００９１】
流量チェックの一例として、図９（Ｂ）のフローチャートを用いて説明する。Ｓ９３１において、ストリーム処理モジュール３２２は、Ｓ９０６乃至Ｓ９０８およびＳ９１０で取得したデバイスシリアル、コレクション、受信日時を１つのレコードとしてイベント履歴テーブルに追加する。イベント履歴テーブルとは、過去に処理したイベントの履歴を管理するテーブルであり、その一例を表Ｆで示す。このイベント履歴テーブルのレコードは受信日時から１時間経過したものは定期的に削除される。
【００９２】
【表６】
2020144763.tif 000008
【００９３】
Ｓ９３２において、ストリーム処理モジュール３２２はＳ９０６乃至Ｓ９０８で取得したデバイスシリアル、エンティティ、イベント名と一致するイベント履歴一覧を表Ｆのイベント履歴テーブルから取得する。
【００９４】
Ｓ９３３において、ストリーム処理モジュール３２２はＳ９３２で取得したイベント履歴一覧が単位時間あたりに発生しているイベント数が閾値を超えているかをチェックする。例えば１分間に同じイベントが閾値１００を超えて発生しているなどをチェックする。もし閾値を超えている場合にはＳ９３４で閾値を超えているという戻り値を返す、超えていない場合にはＳ９３５で閾値を超えていないという戻り値を返す。
【００９５】
Ｓ９１１において、ストリーム処理モジュール３２２はＳ９１１の結果として所定値を超えていると判定された場合にはＳ９１３に進み、所定値以下であると判定された場合はＳ９１２に進む。Ｓ９１２において、ストリーム処理モジュール３２２は同じクライアント端末１０２で同じイベントが大量に発生していないと判定し、データ利用サーバ１１４に対して通常のイベント通知処理を行う。
【００９６】
具体的にはＳ８０３においてストリーム処理モジュール３２２はメッセージサーバ１２４に対して発生したイベントとアクセストークンＢを送信する。Ｓ８０４において、メッセージサーバ１２４のメッセージモジュール３６１はＳ８０６で受信したアクセストークンを検証し、問題がなければイベントを送信管理モジュール３６２の設定に従ってメッセージキューサーバ１２５に送信して処理を終了する。
【００９７】
送信管理モジュール３６２が保持する送信管理データの一例を表Ｇに示す。
【００９８】
【表７】
2020144763.tif 000009
【００９９】
送信管理データはメッセージの格納先を一意に識別するトピックＩＤ、そのメッセージの通知先となるクライアントＩＤとを関連付けて１レコードとして保存される。またメッセージモジュール３６１が保存するデータの一例を表Ｈに示す。
【０１００】
【表８】
2020144763.tif 000010
【０１０１】
メッセージモジュール３６１は受信したイベントのメッセージを該当するトピックＩＤと関連付けて１つのレコードとしてメッセージテーブルに保存される。
【０１０２】
ストリーム処理モジュール３２２は、同じクライアント端末１０２で同じイベントが大量に発生していると判定した場合、Ｓ９１３（Ｓ８０５）に処理を進める。Ｓ９１３において、ストリーム処理モジュール３２２は、クライアント端末１０２に対してコレクションのｒｏｕｔｅを変更したコレクションを設定するように、コレクションフィルタ送信モジュール３２３に要求する。
【０１０３】
なお、本実施例では、上述したようにコレクションフィルタ送信モジュール３２３がコレクションフィルタをコレクションフィルタ受信モジュール３０５に送信する記載にしている。他の実施の形態としては、コレクションフィルタ送信モジュール３２３は、クライアント端末の状態情報を管理する不図示の状態管理サーバに対してコレクションフィルタを設定するように指示しておく。そして、クライアント端末と状態管理サーバで管理するクライアント端末の状態情報とを同期することで、予め設定されたコレクションフィルタがコレクションフィルタ受信モジュール３０５に対して送信される。これにより、コレクションフィルタの設定変更をクライアント端末に適用させることができる。例えば、Ａｍａｚｏｎ  Ｗｅｂ  Ｓｅｒｖｉｃｅ（以降、ＡＷＳと称する）が提供するサービスであるＡＷＳ  ＩｏＴにはＤｅｖｉｃｅ  Ｓｈａｄｏｗというサービスを利用することで、この処理を実現してもよい。
【０１０４】
Ｓ８０６において、コレクションフィルタ送信モジュール３２３はクライアント端末１０２のコレクションフィルタ受信モジュール３０５に対して送信先を変更したコレクションフィルタを送信する。送信先を変更したコレクションフィルタは図６（Ｂ）で示すコレクションフィルタ６０１である。なお、他の形態として、クライアント端末１０２に予め図６（Ｂ）で示すコレクションフィルタを保持させておき、Ｓ８０６でコレクションフィルタ送信モジュール３２３はクライアント端末に対してコレクションフィルタの変更指示を行うようにしても良い。
【０１０５】
このように大量のイベントを送信するクライアントからの送信先を通常のものと変更することで、通常のイベント送信処理の対象から除外することが可能となる。通信先を同じとした場合でも、データベースなどでクライアントやコレクションの情報を管理することで、通常のイベント送信処理の対象から除外することも可能ではある。しかしながら、大量のイベントの一つ一つに対して、対象から除外するか否かのチェックをする必要があるという点で、ストリーム受信サーバ１２３からデータを取得するデータ収集サーバ１１３には負荷がかかる。そのため、退避用ストリーム受信サーバ１２６が大量のイベントを送信するクライアントからデータを受信することで、ストリーム受信サーバ１２３からデータを取得するデータ収集サーバ１１３の負荷を減らすことができる。
【０１０６】
送信先を変更したコレクションフィルタを受け取ったクライアント端末１０２は、コレクションフィルタによって指示されたコレクションを変更後の送信先に送信する。送信フローに関しては、図４，図５を用いて説明したフロート同様であるため、説明を省略する。
【０１０７】
変更された送信先へ送信されたイベントデータに対しては、図９（Ｃ）にて示すフローに従って、流量チェックの処理が行われ、流量が正常に戻った場合には、再度イベントの送信先を通常のものに戻したコレクションフィルタを再設定する処理を行う。
【０１０８】
図９（Ｃ）における、Ｓ９０１乃至Ｓ９１１までの処理は図９に示したものと同じであるため説明を省略する。
【０１０９】
Ｓ９５１において、コレクションフィルタ送信モジュール３２３は、クライアント端末１０２のコレクションフィルタ受信モジュール３０５に対して送信先をもとに戻したコレクションフィルタを送信する。送信先を変更したコレクションフィルタは図６（Ａ）のようなコレクションフィルタ６０１である。なお、クライアント端末が図６（Ａ）のコレクションフィルタをキャッシュしておき、コレクションフィルタ送信モジュール３２３はＳ９５１でコレクションフィルタを送信せずにコレクションフィルタ変更指示のみを行っても良い。
【０１１０】
Ｓ９５１において、ストリーム処理モジュール３２２は、しきい値をこえて発生したイベントは正常な処理には必要ないイベントであるため削除する。ただし、異常に発生したイベントのデータを活用し、後から異常状態の解析などに用いる場合などには、イベントを別途保存しておいても良い。
【０１１１】
なお、Ｓ９３３では、単位時間当たりのイベント数が閾値で示される所定値を超えているかどうかのチェックをストリーム処理モジュールが行うものとして説明した。しかしながら、他の実施形態として、受信サービスシステムではなくクライアント端末が、単位時間当たりのイベント数が閾値を超えているかどうかのチェックを行っても良い。そして、単位時間当たりのイベント数が閾値を超えている場合は、クライアント端末が受信サービスシステムにその旨を通知し、通知を受けた受信サービスシステムがクライアント端末に対してコレクションフィルタを送信してもよい。また、単位時間当たりのイベント数が閾値を超えているとクライアント端末が判定した場合は、クライアント端末が、自装置内で保持するコレクションフィルタを変更して、コレクションフィルタ変更の旨を受信サービスシステムに対して通知しても良い。さらに、クライアント端末は、退避用ストリーム受信サーバ１２６ではなく、受信サービスシステム内の不図示のストレージに対してデータを送信しても良い。その場合、受信サービスシステムは、退避用ストリーム受信サーバ１２６を備えていなくても良い。他にも、単位時間当たりのイベント数が閾値を超えていると判定した受信サービスシステムが、クライアント端末に対してコレクションフィルタを変更するよう指示しても良い。
【０１１２】
以上説明した図８のシーケンス、図９のフローチャートにより、クライアント端末１０２からの想定外の大量データが送付されてきた場合にはクライアント端末１０２に対して送信先を変更したコレクションの設定を行う。そのようにすることで、正常な処理を行う対象からデータを隔離することができるため、正常に動作する他のクライアント端末からのデータの処理を遅延させずにサービス提供を行うことができる。また、異なる送信先に送信されたイベントデータの流量を監視することで、クライアントが正常状態に戻ったことを自動で検知することが出来、正常状態に戻った場合には、該クライアントに対してのサービス提供を再開することが可能となる。
【０１１３】
（実施例２）
本発明に係る第２の実施形態について説明する。以下構成に関しては実施例１と異なる点についてのみ説明する。実施例１においては、イベントの流量を監視し、流量が異常と検知された場合に、イベントの送信先を変更するようにした。しかしながら、異常が長時間続き、デバイスが復旧されない場合、変更した送信先のストリーム受信サーバや、データ収集サーバのリソースの無駄遣いになってしまう。そこで、実施例２においては、イベントの流量異常の状態が、長時間続いた場合には、デバイスに対して、イベントの送信を止めるコレクションの設定を行うようにする。
【０１１４】
図１０を用いて、本実施例におけるイベント送信停止処理に関するフローを説明する。図１０において、Ｓ９０１乃至Ｓ９１１までの処理は図９に示したものと同じであるため説明を省略する。
【０１１５】
Ｓ１００１において、ストリーム処理モジュール３２２は、Ｓ９１１の処理で閾値を超えてイベントが発生していると判断されたデバイス、およびコレクションを表Ｉで、イベントが閾値を超えて発生したと判断されたタイミングからの経過時間を管理する。例えば、現在時刻が２０１８／０９／０２  ０１：００：００  で、経過時間が１時間の場合、表Ｉから、デバイスシリアルがＡＡＡ１２３４５でコレクションがＥｒｒｏｒがしきい値以上、イベント流量が異常であると判断される。イベントが閾値を超えて発生したと判断されたタイミングから一定時間後も異常状態であると判断されたデバイス、コレクションが１つ以上存在した場合には、該デバイス、コレクションの情報を渡して、Ｓ１００２に遷移する。しきい値以上の長時間の異常は発生していないが、イベント流量が異常であると判断されたデバイス、コレクションが１つ異常存在する場合には、それらの情報を渡して、Ｓ１００３に遷移する。表１０の例の場合、ＡＡＡ１２３４６、およびＡＡＡ１２３４７が、Ｓ１００３のステップに渡される。
【０１１６】
【表９】
2020144763.tif 000011
【０１１７】
Ｓ１００２においては、ストリーム処理モジュール３２２は、Ｓ１００１より渡されたデバイスとコレクションの情報を用いて、イベントの送信停止設定依頼を発行する。Ｓ１００３においては、ストリーム処理モジュール３２２は、Ｓ１００１より渡されたデバイス、コレクション情報を元に、表Ｉを検索し、送信変更フラグを確認する。送信変更フラグは、すでにコレクション送信先の変更依頼を発行したかどうかを示すフラグである。まだコレクションフィルタの設定依頼をしていないデバイス、コレクションに対してのみ、送信先変更依頼を行うために、フラグの確認を行う。表Ｉに示した例の場合、ＡＡＡ１２３４６のデバイスに対してはすでに変更しているため、ＡＡＡ１２３４７とそのコレクション情報のみを渡して、Ｓ１００４に遷移する。
【０１１８】
Ｓ１００４では、ストリーム処理モジュール３２２は、Ｓ１００３から渡されたデバイスとコレクションに対して、送信先を変更する処理を行う。この処理自体はＳ９１３で説明したものと同じである。送信先を変更する処理を行った後、表Ｉの送信先変更フラグをＴｒｕｅにする。
【０１１９】
なお、Ｓ１００１、Ｓ１００２、Ｓ１００３、およびＳ１００４の各ステップにおける処理の少なくともいずれかは、クライアント端末で行われても良い。イベントの送信停止の設定を示すコレクションは、クライアント端末で保持されていてもよい。
【０１２０】
以上、実施例２で述べた方法に従って処理をすることで、異常状態が長時間続くデバイスとコレクションに対しては、送信停止を指示し、サーバ側のリソースの無駄遣いを防ぐことが可能となる。
【０１２１】
（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
【０１２２】
ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピューター（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【符号の説明】
【０１２３】
１０２  クライアント端末
１１３  データ収集サーバ
１２３  ストリーム受信サーバ
１２６  退避用ストリーム受信サーバ
【図１】
2020144763.tif 000012
【図２】
2020144763.tif 000013
【図３】
2020144763.tif 000014
【図４】
2020144763.tif 000015
【図５】
2020144763.tif 000016
【図６】
2020144763.tif 000017
【図７】
2020144763.tif 000018
【図８】
2020144763.tif 000019
【図９】
2020144763.tif 000020
【図１０】
2020144763.tif 000021