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