(57)【特許請求の範囲】
【請求項１】
データを分析し、
前記データの分析結果を取得するための分析結果取得ＡＰＩを用い、
データの分析状況、ネットワークの状況、又は前記データを分析する計算機が動作する計算機リソースの状況に応じて、前記分析結果取得ＡＰＩを用いた前記分析結果の配信方法として、ポーリング型の配信方法又はコネクション型の配信方法のいずれかの配信方法を決定し、
前記ポーリング型の配信方法を決定した場合には、クライアント端末によって前記分析結果の配信要求が一度送信されると、自動的に所定期間毎にポーリングを行うことによって、擬似的にプッシュ型の配信方法を実現する
ことを特徴とするプッシュ型サービス実現方法。
【請求項２】
前記分析結果の配信を要求する分析クエリを記憶させるためのＡＰＩと、前記分析クエリに対する前記分析結果を配信するための前記分析結果取得ＡＰＩとが、異なるネットワークセッションを用いて実行され、
前記分析クエリに対する前記分析結果を配信するための前記分析結果取得ＡＰＩを、所定期間毎にポーリングする前記ポーリング型の配信方法と、前記分析クエリを記憶させる際に用いたネットワークセッションを維持して、該ネットワークセッションをそのまま用いて前記分析結果を配信する前記コネクション型の配信方法とのいずれかに決定する
請求項１記載のプッシュ型サービス実現方法。
【請求項３】
前記分析結果取得ＡＰＩを用いて配信されるメッセージとして、前記決定した配信方法を含む情報を送信する
請求項１又は請求項２記載のプッシュ型サービス実現方法。
【請求項４】
サーバが、前記データの分析状況を監視することにより、前記分析結果が生成される頻度を前記分析結果取得ＡＰＩ毎に推定し、
前記サーバが、推定した前記分析結果の生成頻度に応じて、前記分析結果の配信方法を決定する
請求項１から請求項３のうちのいずれか１項に記載のプッシュ型サービス実現方法。
【請求項５】
前記データを分析する計算機が動作する計算機リソースの状況を監視して、監視結果を出力し、
出力した前記監視結果に基づいて、前記データを分析する計算機が動作する計算機リソースの状況に応じて、前記分析結果の配信方法を決定する
請求項１から請求項４のうちのいずれか１項に記載のプッシュ型サービス実現方法。
【請求項６】
前記分析結果取得ＡＰＩを用いて処理を実行する計算機と前記分析結果取得ＡＰＩを用いた前記分析結果の配信を受ける装置との間のネットワークの状況を監視して、監視結果を出力し、
出力した前記監視結果に基づいて、前記ネットワークの状況に応じて、前記分析結果の配信方法を決定する
請求項１から請求項５のうちのいずれか１項に記載のプッシュ型サービス実現方法。
【請求項７】
前記分析結果取得ＡＰＩを用いて処理を実行する計算機のスレッド、前記分析結果取得ＡＰＩを用いて処理を実行する計算機と前記分析結果取得ＡＰＩを用いた前記分析結果の配信を受ける装置との間のネットワークソケットを監視することによって、前記ネットワークの状況を監視する
請求項６記載のプッシュ型サービス実現方法。
【請求項８】
前記分析結果の配信を要求する分析クエリを記憶させるためのＡＰＩと、前記分析クエリに対する前記分析結果を配信するための前記分析結果取得ＡＰＩとが、異なるネットワークセッションを用いて実行され、
前記分析クエリに対する前記分析結果を配信するための前記分析結果取得ＡＰＩを、所定期間毎にポーリングする前記ポーリング型の配信方法と、前記分析クエリを記憶させる際に用いたネットワークセッションを維持して、該ネットワークセッションをそのまま用いて前記分析結果を配信する前記コネクション型の配信方法とのいずれかに決定し、
前記分析結果取得ＡＰＩを用いた前記分析結果の配信を受ける装置に、前記分析結果取得ＡＰＩを用いて配信された前記分析結果を含むメッセージを解釈して、前記分析結果取得ＡＰＩに対するポーリング制御を行うラッパーが搭載されている
請求項１から請求項７のうちのいずれか１項に記載のプッシュ型サービス実現方法。
【請求項９】
前記ラッパーを用いて、前記分析結果取得ＡＰＩを用いて前記分析結果の配信方法を示す情報を受信し、受信した該情報で示される配信方法に応じて、前記分析結果取得ＡＰＩを繰り返しポーリングする制御を行う
請求項８記載のプッシュ型サービス実現方法。
【請求項１０】
前記分析結果取得ＡＰＩを用いた前記分析結果の配信を受ける装置が、前記分析結果の配信方法を決定するためのサービス要件を設定し、
設定した前記サービス要件に基づいて、前記分析結果取得ＡＰＩを用いた分析結果の配信方法を決定する
請求項１から請求項９のうちのいずれか１項に記載のプッシュ型サービス実現方法。
【請求項１１】
前記サービス要件として、前記分析結果取得ＡＰＩ毎に、要求されるリアルタイム性を示す情報を設定する
請求項１０記載のプッシュ型サービス実現方法。
【請求項１２】
少なくとも、有料サービスユーザに対してユーザＩＤを発行し、
前記有料サービスユーザに対して優先的にリソースを割り当てて、前記分析結果取得ＡＰＩを用いた前記分析結果の配信方法を決定する
請求項１から請求項１１のうちのいずれか１項に記載のプッシュ型サービス実現方法。
【請求項１３】
前記分析結果取得ＡＰＩを利用するために設定された料金の支払いに用いる電子チケットを記憶し、
ユーザが前記電子チケットを購入しているか否かを判定し、
前記電子チケットを購入しているか否かの判定結果に基づいて、前記分析結果取得ＡＰＩを用いた分析結果の配信方法を決定する
請求項１から請求項１１のうちのいずれか１項に記載のプッシュ型サービス実現方法。
【請求項１４】
前記分析結果取得ＡＰＩを利用するための料金を、リソースの状況に応じて動的に決定する
請求項１２又は請求項１３記載のプッシュ型サービス実現方法。
【請求項１５】
データを分析するデータ分析手段と、
前記データ分析手段の分析結果を取得するための分析結果取得ＡＰＩと、
データの分析状況、ネットワークの状況、又は前記データを分析する計算機が動作する計算機リソースの状況に応じて、前記分析結果取得ＡＰＩを用いた前記分析結果の配信方法として、ポーリング型の配信方法又はコネクション型の配信方法のいずれかの配信方法を決定する配信方法決定手段と、
前記ポーリング型の配信方法を決定した場合には、クライアント端末によって前記分析結果の配信要求が一度送信されると、自動的に所定期間毎にポーリングを行うことによって、擬似的にプッシュ型の配信方法を実現する手段とを
備えたことを特徴とするプッシュ型サービス実現システム。
【請求項１６】
データを分析するデータ分析手段と、
前記データ分析手段の分析結果を取得するための分析結果取得ＡＰＩと、
データの分析状況、ネットワークの状況、又は前記データを分析する計算機が動作する計算機リソースの状況に応じて、前記分析結果取得ＡＰＩを用いた前記分析結果の配信方法を決定する配信方法決定手段と、
前記ポーリング型の配信方法を決定した場合には、クライアント端末によって前記分析結果の配信要求が一度送信されると、自動的に所定期間毎にポーリングを行うことによって、擬似的にプッシュ型の配信方法を実現する手段とを
備えたことを特徴とするプッシュ型サービス実現装置。
【請求項１７】
コンピュータに、
データを分析するデータ分析処理と、
データの分析状況、ネットワークの状況、又は前記データを分析する計算機が動作する計算機リソースの状況に応じて、前記データの分析結果を取得するための分析結果取得ＡＰＩを用いた前記分析結果の配信方法を決定する配信方法決定処理と、
前記ポーリング型の配信方法を決定した場合には、クライアント端末によって前記分析結果の配信要求が一度送信されると、自動的に所定期間毎にポーリングを行うことによって、擬似的にプッシュ型の配信方法を実現する処理とを
実行させるためのプッシュ型サービス実現用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プッシュ型のサービスを実現可能なプッシュ型サービス実現方法、プッシュ型サービス実現システム、プッシュ型サービス実現装置、及びプッシュ型サービス実現用プログラムに関する。
【背景技術】
【０００２】
クライアント端末からの要求に応じてサーバ側で分析や検索の処理を行い、クライアント端末に分析結果や検索結果を配信するサービスを提供することが行われている。例えば、特許文献１には、クライアント端末から受信した設定ファイルに基づいて、サーバ装置がデータベース検索ページのＨＴＭＬファイルを生成してクライアント端末に配信し、クライアント端末で表示されたデータベース検索ページによりデータベースの絞り込み検索等を行うことが記載されている。
【０００３】
また、関連する技術として、クライアント端末からのポーリングに応じて、サーバ装置がクライアント端末に対して情報配信することが行われている。例えば、特許文献２には、通信手段の異なる複数のポートから受信した文書を一元的に文書管理するとともに、ネットワークを介して接続される情報処理装置からの文書を取得するためのポーリングに応じて文書を送信するＷｅｂサービスを提供することが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−１４８６４号公報
【特許文献２】特開２００４−２９７７８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１や特許文献２に記載されたような方法を用いて、大規模データストリームをリアルタイムに分析して分析結果をクライアント端末に配信するサービスを提供することが行われている。このようなサービスを提供する場合、大規模データストリームをリアルタイムに分析してマッシュアップ的に分析用のアプリケーションを構築できるようにすることが望ましい。
【０００６】
大規模データストリームをリアルタイムに分析するアプリケーションを対象とはしていないが、マッシュアップ的にアプリケーションを構築できる技術が、Ｗｅｂサービスの技術領域で用いられている。例えば、ＡｔｏｍＰｕｂ（Atom Publishing Protocol）やＳＯＡＰ（Simple Object Access Protocol ）といった国際標準のＡＰＩを用いて、アプリケーションを構築することが行われている。なお、ＡｔｏｍＰｕｂはＲＦＣによってＲＦＣ５０２３として定められており、ＳＯＡＰはＷ３Ｃによって定められている。
【０００７】
ここで、ＡｔｏｍＰｕｂは、ＲＦＣ（Request for Comments）において標準化され、ＳＯＡＰは、Ｗ３Ｃ（World Wide Web Consortium ）で標準化されている。また、これらの標準化されたＡｔｏｍＰｕｂやＳＯＡＰを使って、Ａｍａｚｏｎ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ（米Ａｍａｚｏｎ社によって提供されている）やＧｏｏｇｌｅ  Ｍａｐｓ（米Ｇｏｏｇｌｅ社によって提供されている）といった様々なインターネットサービスベンダーがＡＰＩを公開しており、これらのＡＰＩを使ったＷｅｂ用のアプリケーションは多数存在する。
【０００８】
ＡｔｏｍＰｕｂやＳＯＡＰは、細かな仕様の違いはあるものの、ともに共通して提供するサービスにＵＲＬを割り当てておく。そして、ＡＰＩを利用する側の計算機は、この予め割り当てられたＵＲＬをネットワークを使って呼ぶことで、マッシュアップ的にアプリケーションを構築するためのサービスを受けることができる。すなわち、人がブラウザを用いてＵＲＬを指定してＷｅｂページを見る場合と同じ方法で、計算機がＵＲＬを指定してサービスを受ける（計算機によって自動的に行われる）方法である。
【０００９】
さらに、これらのＡＰＩを使ってより簡単にアプリケーションを構築するためのＧＵＩ開発環境が存在する。例えば、Ｙａｈｏｏ！Ｐｉｐｅｓ（米Ｙａｈｏｏ社によって提供されている）やＭＳ−Ｐｏｐｆｌｙ（米マイクロソフト社によって提供されている）等によるＧＵＩ開発環境である。
【００１０】
上記に示した特許文献１や特許文献２に記載された関連技術では、いずれもインターネットを対象としていることから、クライアント端末からサーバ装置にデータ配信等を要求するいわゆるＰＵＬＬ型のサービスが前提である。しかしながら、処理対象のデータが逐次的／連続的に発生するデータストリーム処理を行う場合には、データ処理のリアルタイム性が要求されるので、サーバ装置からクライアント端末にプッシュ型（ＰＵＳＨ型）のサービスを提供できるようにすることが重要である。
【００１１】
例えば、ＩＣカードの利用ログデータから不正利用を検出して通報するサービスを提供する場合を考える。この場合、予め不正利用のパターンを登録しておき、利用ログデータのデータストリームから不正利用のパターンを検出する。そして、不正利用のパターンを検出すると、クライアント端末に対してアラートを送信（ＰＵＳＨ）する必要がある。
【００１２】
Ｗｅｂを用いる場合、必ずクライアント端末からサーバ装置に対して接続を要求するステップが必要となるため、上記のようなＰＵＳＨ型のサービスを実現するためには、以下の２つの方法が考えられる。
【００１３】
（１）定期的にクライアント端末からサーバ装置に対してポーリングを行うことによって、クライアント端末のユーザから見ると（装置の内部的にはＰＵＬＬ型であるものの）、見た目上ＰＵＳＨ型のサービスを実現する方法。
【００１４】
（２）クライアント端末からサーバ装置へのコネクションを維持し続ける方法。
【００１５】
しかしながら、上記の（１），（２）の方式は、大規模なデータストリームのリアルタイム処理を行う場合、以下に説明するように実現が難しい。
【００１６】
（１）定期的にクライアント端末からサーバ装置に対してポーリングを行う方法：装置の内部的にはＰＵＬＬ型であるため、ポーリング間隔が長いとリアルタイム性が犠牲になる。逆に、ポーリング間隔が短いと、ポーリングが頻繁に行われることになり、サーバ装置に負荷がかかってしまう。一般に、複数のユーザが同じＡＰＩを同時期に利用するため、いつアクセスが集中して、どの程度サーバ装置に負荷がかかるかを予測することは難しい。そのため、このリアルタイム性とサーバ装置負荷軽減とのトレードオフの解消は非常に難しい。
【００１７】
（２）クライアント端末からサーバ装置へのコネクションを維持し続ける方法：コネクションの確立を行うと、スレッドやソケットリソースを消費するため、計算機（マシン）上で消費するスレッドやソケットリソースが必要最小限となるように設計する必要がある。一般に、殆どのオペレーティングシステム（ＯＳ）では、ソケットはページングされないメモリに割り当てる必要がある。例えば、Ｉｎｔｅｌ  ｘ８６（登録商標）マシン上では、非ページングメモリプールの大きさは、物理メモリサイズの１／８までである。そのため、Ｗｉｎｄｏｗｓ（登録商標）を用いる場合には、ソケットに利用可能なメモリ容量は、２５６ＭＢｙｔｅが最大となる。このことから、計算機の環境にもよるが、一般的に、同時に維持可能なコネクション数は、１０００コネクション程度である。つまり、１０００人以上のユーザに対しては、同時には、ＰＵＳＨ型のサービスを提供できないことになる。
【００１８】
以上のように、大規模データストリームのリアルタイム処理を行うことは、ＯＳ等の専門知識や構築ノウハウがないと実現が難しいといえる。
【００１９】
そこで、本発明は、ＡＰＩを組み合わせてマッシュアップ的に簡単にシステムを構築する場合において、ＰＵＳＨ型のサービスを提供できるプッシュ型サービス実現方法、プッシュ型サービス実現システム、プッシュ型サービス実現装置、及びプッシュ型サービス実現用プログラムを提供することを目的とする。
【課題を解決するための手段】
【００２０】
本発明によるプッシュ型サービス実現方法は、データを分析し、データの分析結果を取得するための分析結果取得ＡＰＩを用い、データの分析状況、ネットワークの状況、又はデータを分析する計算機が動作する計算機リソースの状況に応じて、分析結果取得ＡＰＩを用いた分析結果の配信方法として、ポーリング型の配信方法又はコネクション型の配信方法のいずれかの配信方法を決定し、ポーリング型の配信方法を決定した場合には、クライアント端末によって分析結果の配信要求が一度送信されると、自動的に所定期間毎にポーリングを行うことによって、擬似的にプッシュ型の配信方法を実現することを特徴とする。
【００２１】
本発明によるプッシュ型サービス実現システムは、データを分析するデータ分析手段と、データ分析手段の分析結果を取得するための分析結果取得ＡＰＩと、データの分析状況、ネットワークの状況、又はデータを分析する計算機が動作する計算機リソースの状況に応じて、分析結果取得ＡＰＩを用いた分析結果の配信方法として、ポーリング型の配信方法又はコネクション型の配信方法のいずれかの配信方法を決定する配信方法決定手段と、ポーリング型の配信方法を決定した場合には、クライアント端末によって分析結果の配信要求が一度送信されると、自動的に所定期間毎にポーリングを行うことによって、擬似的にプッシュ型の配信方法を実現する手段とを備えたことを特徴とする。
【００２２】
本発明によるプッシュ型サービス実現装置は、データを分析するデータ分析手段と、データ分析手段の分析結果を取得するための分析結果取得ＡＰＩと、データの分析状況、ネットワークの状況、又はデータを分析する計算機が動作する計算機リソースの状況に応じて、分析結果取得ＡＰＩを用いた分析結果の配信方法を決定する配信方法決定手段と、ポーリング型の配信方法を決定した場合には、クライアント端末によって分析結果の配信要求が一度送信されると、自動的に所定期間毎にポーリングを行うことによって、擬似的にプッシュ型の配信方法を実現する手段とを備えたことを特徴とする。
【００２３】
本発明によるプッシュ型サービス実現用プログラムは、コンピュータに、データを分析するデータ分析処理と、データの分析状況、ネットワークの状況、又はデータを分析する計算機が動作する計算機リソースの状況に応じて、データの分析結果を取得するための分析結果取得ＡＰＩを用いた分析結果の配信方法を決定する配信方法決定処理と、ポーリング型の配信方法を決定した場合には、クライアント端末によって分析結果の配信要求が一度送信されると、自動的に所定期間毎にポーリングを行うことによって、擬似的にプッシュ型の配信方法を実現する処理とを実行させるためのものである。
【発明の効果】
【００２４】
本発明によれば、ＡＰＩを組み合わせてマッシュアップ的に簡単にシステムを構築する場合において、ＰＵＳＨ型のサービスを提供することができる。
【図面の簡単な説明】
【００２５】
【図１】本発明によるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。
【図２】ＡＰＩ利用方法判定手段の構成例を示すブロック図である。
【図３】データストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。
【図４】分析ＡＰＩ利用手段が発行するクエリに含まれる項目例を示す説明図である。
【図５】分析ＡＰＩ利用手段が発行する要求クエリの例を示す説明図である。
【図６】コネクション型の通信を行う場合の要求クエリに対する回答例を示す説明図である。
【図７】ポーリング型の通信を行う場合に一旦受信する情報の例を示す説明図である。
【図８】分析ＡＰＩ利用手段がポーリングする際にＵＲＬを指定して送信する情報の例を示す説明図である。
【図９】分析ＡＰＩ利用手段が表示する画面例を示す説明図である。
【図１０】データストリーム分析手段に対して転送されるクエリセットの例を示す説明図である。
【図１１】ポーリング型分析結果記憶手段が記憶するデータストリームの分析結果を一時的に記憶するための回答一時記憶テーブルの一例を示す説明図である。
【図１２】分析対象のデータストリームであるクレジットカードの利用履歴の例を示す説明図である
【図１３】データストリーム分析手段が記憶するクエリ管理テーブルの例を示す説明図である。
【図１４】通信環境監視手段が有する記憶テーブルの例を示す説明図である。
【図１５】分析結果監視手段が有する記憶テーブルの例を示す説明図である。
【図１６】データストリーム分析サービス提供システムを用いて、プッシュ型サービスを提供する処理の一例を示すフローチャートである。
【図１７】第２の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。
【図１８】第２の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。
【図１９】第３の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。
【図２０】第３の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。
【図２１】サービス要件定義手段が設定するサービス要件定義情報の例を示す説明図である。
【図２２】第３の実施形態における分析ＡＰＩ利用手段が発行するクエリに含まれる項目例を示す説明図である。
【図２３】第３の実施形態における要求クエリの例を示す説明図である。
【図２４】第３の実施形態におけるデータストリーム分析サービス提供システムを用いて、プッシュ型サービスを提供する処理の一例を示すフローチャートである。
【図２５】第４の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。
【図２６】第４の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。
【図２７】ユーザＩＤ管理手段が記憶するユーザが有料サービスユーザであるか無料サービスユーザであるかを示すテーブルの例を示す説明図である。
【図２８】第４の実施形態におけるデータストリーム分析サービス提供システムを用いて、プッシュ型サービスを提供する処理の一例を示すフローチャートである。
【図２９】第５の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。
【図３０】第５の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。
【図３１】リソース利用チケット管理手段が管理するチケットの例を示す説明図である。
【図３２】第５の実施形態における要求クエリの例を示す説明図である。
【図３３】リソース利用チケットチェック手段が記憶するテーブルのフィールドの例を示す説明図である。
【図３４】第５の実施形態におけるデータストリーム分析サービス提供システムを用いて、プッシュ型サービスを提供する処理の一例を示すフローチャートである。
【図３５】第６の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。
【図３６】第６の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。
【図３７】第６の実施形態における要求クエリの例を示す説明図である。
【図３８】ＡＰＩ利用価格管理手段が記憶するテーブルの例を示す説明図である。
【図３９】プッシュ型サービス実現システムの最小の構成例を示すブロック図である。
【発明を実施するための形態】
【００２６】
実施形態１．
以下、本発明の第１の実施形態について図面を参照して説明する。図１は、本発明によるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。なお、本実施形態では、プッシュ型サービス実現システムは、プッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムによって実現される。
【００２７】
本発明では、大規模データストリームをリアルタイムに分析するアプリケーションをマッシュアップ的に簡単に構築できるデータストリーム分析装置（システム）や、方法、プログラムを提供する。なお、マッシュアップとは、複数の異なる提供元の技術やコンテンツを複合させて新しいアプリケーションを作ることである。
【００２８】
本発明では、サーバのログデータやセンサから入力したデータ等、連続的に大量発生するデータ（データストリーム）を収集してリアルタイムに（タイムラグを少なく）分析する。そして、その分析結果を、ユーザに提供する装置において、データストリームを分析する手段のＡＰＩを組み合わせてマッシュアップ的に簡単にシステムを構築できるようにする。そして、本発明では、特に、ＰＵＳＨ型のサービスを構築できることを大きな特徴とする。
【００２９】
なお、本実施形態において、データストリーム分析サービス提供システムは、例えば、ＩＣカードの利用ログデータを分析して不正利用を検出する用途に適用できる。また、データストリーム分析サービス提供システムは、例えば、Ｗｅｂデータが発生するログデータに基づいて、Ｗｅｂアクセスの動線解析を行う用途に適用できる。また、データストリーム分析サービス提供システムは、例えば、交通情報（例えば、道路上の自動車の位置情報）を収集し、道路上の渋滞箇所を検出して提供する渋滞情報提供システムの用途に適用できる。また、例えば、データストリーム分析サービス提供システムは、株価の変動を監視し、株価の変動と事前入力した売買ルールとをマッチングして、株式の自動売買を行うアルゴリズムトレードの用途に適用できる。すなわち、データストリーム分析サービス提供システムは、大量のデータが逐次的に発生し、最新のデータをリアルタイムに反映しながら処理を行うあらゆるシステムに適用可能である。
【００３０】
また、本実施形態では、データストリーム分析サービス提供システムは、データストリームとして、時系列に逐次的に発生するデータを入力して分析を実行するものとする。なお、データストリーム分析サービス提供システムは、何らかの順序性をもつデータであれば、例えば、距離が近い順や遠い順等の位置的な順序性をもったデータを逐次的に入力して分析を行うものであってもよい。また、データストリーム分析サービス提供システムは、短い時間間隔（例えば、数秒間隔）で連続して発生されるデータに限らず、逐次的に発生するデータであれば、例えば、数時間や数日等の長い時間間隔で発生するデータや、発生間隔が一定しないようなデータを入力して分析を行うものであってもよい。
【００３１】
なお、本実施形態では、プッシュ型サービス実現方法をデータストリーム分析サービス提供システムに適用する場合を示しているが、プッシュ型サービス実現方法を適用可能な場合は、データストリームの分析や処理を行う場合に限られない。例えば、データストリームの分析結果等によらず、突発的に発生した緊急性の高い情報を、サーバ装置からクライアント端末にプッシュ型（以下、ＰＵＳＨ型ともいう）で配信する用途にも、プッシュ型サービス実現方法を適用可能である。
【００３２】
ただし、一般に、時間間隔が短い入力データを分析して得られた情報程、緊急性を有する場合が多い（例えば、ＩＣカードの不正利用）ことから、本発明によるプッシュ型サービス実現方法は、短い時間間隔で発生するデータストリームを処理する場合に、ＰＵＳＨ型のデータ配信等のサービスを実現できる点で、特に有用である。
【００３３】
図１に示すように、本実施形態では、プッシュ型サービス実現方法は、大規模データストリームをリアルタイムに分析するアプリケーションをマッシュアップ的に簡単に構築できるデータストリーム分析サービス提供システムに適用される。
【００３４】
図１に示すように、データストリーム分析サービス提供システムは、分析ＡＰＩ利用手段１、コネクション通信手段２、データストリーム分析ＡＰＩ３、ＡＰＩ利用方法判定手段４、データストリーム分析手段５、及びポーリング型分析結果記憶手段６を含む。なお、本実施形態において、データストリーム分析サービス提供システムは、具体的には、プログラムに従って動作するパーソナルコンピュータ等の情報処理装置によって実現される。
【００３５】
なお、本実施形態では、データストリーム分析サービス提供システムが備える各手段１〜６は、全て同じ設計者によって設計され構築されるものとする。
【００３６】
データストリーム分析手段５は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。データストリーム分析手段５は、データストリームを分析する機能を備える。
【００３７】
データストリーム分析ＡＰＩ３は、データストリーム分析手段５の分析結果を、インターネット等のネットワークを介してサービスとして公開するための各種ＡＰＩである。なお、データストリーム分析ＡＰＩ３は、具体的には、情報処理装置（サーバ装置）が備える磁気ディスク装置や光ディスク装置等の記憶装置に蓄積されている。
【００３８】
ＡＰＩ利用方法判定手段４は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ、及び磁気ディスク装置や光ディスク装置等の記憶装置によって実現される。ＡＰＩ利用方法判定手段４は、データストリーム分析ＡＰＩ３の利用方法を判定する機能を備える。例えば、ＡＰＩ利用方法判定手段４は、利用する側（例えば、クライアント端末（本実施形態では、後述するマッシュアップＰＣ（Ｐ１）に相当する））のネットワーク環境や、データストリーム分析手段５の計算機リソースの状況、データストリームの分析状況に応じて、最適な利用方法を判定する。
【００３９】
分析ＡＰＩ利用手段１は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。分析ＡＰＩ利用手段１は、ＡＰＩ利用方法判定手段４を利用して、エンドユーザに対するサービス提供を実現する機能を備える。
【００４０】
コネクション通信手段２は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ、及びネットワークインタフェース部によって実現される。コネクション通信手段２は、分析ＡＰＩ利用手段１（例えば、クライアント端末）と、データストリーム分析ＡＰＩ３（具体的には、データストリーム分析ＡＰＩ３を蓄積するサーバ装置（本実施形態では、後述するデータストリーム分析サーバ（Ｐ２）に相当する））との間の通信を行う機能を備える。
【００４１】
ポーリング型分析結果記憶手段６は、具体的には、磁気ディスク装置や光ディスク装置等の記憶装置によって実現される。また、例えば、ポーリング型分析結果記憶手段６は、データを蓄積可能なものであれば、データベースサーバやＷｅｂサーバによって実現されてもよい。ポーリング型分析結果記憶手段６は、データストリーム分析手段５の分析結果を記憶する。
【００４２】
本実施形態では、ＡＰＩ利用方法判定手段４は、ＡＰＩの利用方法として、以下の２種類の利用方法のいずれとするかを判定するものとする。
【００４３】
（１）分析クエリをセットするためのＡＰＩを用いる場合と、分析クエリの結果を得るためのＡＰＩを用いる場合とで、別のネットワークセッションを確立するものとする。そして、分析ＡＰＩ利用手段１（例えば、クライアント端末）が、分析クエリの結果を得るために、定期的に回答を問い合わせ（ポーリングを行い）、ポーリングに応じてサーバ装置から分析結果を配信する（ポーリング型）。
【００４４】
（２）分析ＡＰＩ利用手段１がデータストリーム分析ＡＰＩ３に対して分析クエリをセットしたときに確立されたネットワークセッションをそのまま維持して、その継続して維持しているネットワークセッションを用いて分析結果を得る（コネクション型）。
【００４５】
ＡＰＩ利用方法判定手段４によってＡＰＩの利用方法としてポーリング型が選択された場合には、ポーリング型分析結果記憶手段６は、ポーリング型を用いる場合のデータストリーム分析手段５の分析結果を一時的に記憶しておく。
【００４６】
なお、ＡＰＩ利用方法判定手段４によってポーリング型が選択された場合には、ポーリングに応じてサーバ装置からクライアント端末に対して分析結果の配信を行うことになり、内部的にはＰＵＬＬ型のサービスを行っていることになる。しかし、本実施形態では、クライアント端末から分析結果の配信サービスの提供を要求するためのクエリを一度送信しさえすれば、その後は、自動的にポーリングが行われて分析結果の配信を受けることができる。従って、クライアント端末のユーザから見ると、多少のリアルタイム性が損なわれるものの、見た目上ＰＵＳＨ型の配信サービスが実現されることになる。
【００４７】
図２は、ＡＰＩ利用方法判定手段４の構成例を示すブロック図である。図２に示すように、ＡＰＩ利用方法判定手段４は、回答方法決定手段４０１、分析結果監視手段４０２、通信環境監視手段４０３、及びルール記憶手段４０を含む。
【００４８】
分析結果監視手段４０２は、データストリーム分析手段５を監視することにより、データストリームの分析結果が生成される頻度をＡＰＩ毎に推定する機能を備える。通信環境監視手段４０３は、データストリーム分析ＡＰＩ３が動作する情報処理装置（ＰＣ）と、このデータストリームの分析結果を利用する側の情報処理装置（ＰＣ）との間のネットワークを監視する機能を備える。計算機リソース監視手段４０４は、データストリーム分析手段５が動作する計算機のリソースを監視する機能を備える。
【００４９】
ルール記憶手段４０は、データストリーム分析ＡＰＩ３の利用方法を決定するためのルールを記憶する。回答方法決定手段４０１は、ＡＰＩ利用方法判定手段４のメイン制御部であり、データストリーム分析ＡＰＩ３からの要求に応じて、ルール記憶手段４０が記憶するルールに従って、データストリーム分析ＡＰＩ３の利用方法を決定する機能を備える。
【００５０】
次に、データストリーム分析サービス提供システムの物理構成について説明する。図３は、データストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。図３に示すように、データストリーム分析サービス提供システムは、典型的な物理構成として、マッシュアップＰＣ（Ｐ１）と、データストリーム分析サーバ（Ｐ２）とを含む。
【００５１】
データストリーム分析サーバ（Ｐ２）は、データストリームを分析し、そのデータストリームの分析結果を、データストリーム分析ＡＰＩ３を用いてサービスとして提供する機能を備える。マッシュアップＰＣ（Ｐ１）は、データストリーム分析サーバ（Ｐ２）に接続し、エンドユーザに対して、データストリームの分析アプリケーションを提供する機能を備える。
【００５２】
なお、図３に示す例では、コネクション通信手段２は、当該コネクション通信手段２を含むデータストリーム分析サーバ（Ｐ２）と、マッシュアップＰＣ（Ｐ１）とを、ネットワークを介して接続する制御を行う。
【００５３】
図３に示すように、データストリーム分析サーバＰ２は、データストリーム分析手段５と、データストリーム分析ＡＰＩ３と、ＡＰＩ利用方法判定手段４と、ポーリング型分析結果記憶手段６と、コネクション通信手段２とを含む。また、マッシュアップＰＣ（Ｐ１）は、分析ＡＰＩ利用手段１を含む。
【００５４】
また、図３に示すように、データストリーム分析サービス提供システムは、複数のマッシュアップＰＣ（Ｐ１）を含んでもよい。この場合、データストリーム分析サーバ（Ｐ２）は、複数のマッシュアップＰＣ（Ｐ１）からアクセスされることになる。そのため、データストリーム分析サーバ（Ｐ２）側では、それぞれのマッシュアップＰＣ（Ｐ１）を、ＩＰアドレス等の識別情報で区別して、コネクション通信手段２を用いて通信を行う。
【００５５】
なお、本実施形態では、説明を簡単にするために、データストリーム分析サーバＰ２が１台の情報処理装置を用いて実現される場合を示したが、データストリーム分析サーバＰ２を複数台の情報処理装置を用いて実現しても構わない。例えば、データストリーム分析手段５、データストリーム分析ＡＰＩ３、ＡＰＩ利用方法判定手段４、ポーリング型分析結果記憶手段６、及びデータストリーム分析手段５を、それぞれ別々の情報処理装置（ＰＣ）を用いて実現させても構わない。この場合、例えば、互いの手段２〜６が動作する情報処理装置（ＰＣ）のＩＰアドレス等を事前に交換しておき、ＴＣＰ／ＩＰ等を用いて相互に通信するようにすればよい。
【００５６】
また、マッシュアップＰＣ（Ｐ１）は、エンドユーザが利用するノート型パーソナルコンピュータ（ノートＰＣ）等でも構わないし、あるいは、エンドユーザに対してアプリケーションを提供するためのＷｅｂサーバであっても構わない。マッシュアップＰＣ（Ｐ１）は、予めデータストリーム分析サーバ（Ｐ２）へのアクセス手段（例えば、ＵＲＬ等を知っており）、データストリーム分析サーバＰ２のコネクション通信手段２を介して、データストリーム分析サーバ（Ｐ２）に接続できる。
【００５７】
コネクション通信手段２は、インターネットで広く使われているＴＣＰ／ＩＰを利用して処理を実行することによって実現できる。また、セキュリティの観点から、コネクション通信手段２は、プロキシサーバ等を介して通信を行っても構わない。
【００５８】
コネクション通信手段２を用いたマッシュアップＰＣ（Ｐ１）との間の接続方法は、まず、マッシュアップＰＣ（Ｐ１）側からデータストリーム分析サーバ（Ｐ２）側への接続要求を行う。つまり、本実施形態では、利用形態として、インターネットで広く使われているクライアント・サーバモデルを想定している。具体的には、データストリーム分析サーバ（Ｐ２）がサーバ装置に相当し、マッシュアップＰＣ（Ｐ１）がクライアント端末に相当する。そのため、データストリーム分析サーバ（Ｐ２）が、能動的に、マッシュアップＰＣ（Ｐ１）側に対してメッセージを通知することは、原則としてできない。すなわち、データストリーム分析サーバ（Ｐ２）側から、マッシュアップＰＣ（Ｐ１）側に対してメッセージを通知したい場合には、マッシュアップＰＣ（Ｐ１）からデータストリーム分析サーバ（Ｐ２）に対して行われた通信に対する返信として行う。
【００５９】
本実施形態では、以下の例に示すようなデータストリームの分析を行う場合に、データストリーム分析サービス提供システムを適用するものとする。
【００６０】
解析対象のデータストリーム（解析対象データ）として、クレジットカードの利用ログデータを想定する。また、分析内容としては、利用ログデータから、予め登録された不正利用パターンを検出する分析処理を行うものとする。また、エンドユーザは、クレジットカード会社であるものとする。また、クレジットカード不正利用警告を通知するためのアプリケーションをマッシュアップ的に構築するものとする。
【００６１】
次に、データストリーム分析サービス提供システムが備える各手段１〜６の機能について説明する。
【００６２】
分析ＡＰＩ利用手段１は、サーバ装置（例えば、データストリーム分析サーバ（Ｐ２））によって提供されるデータストリーム分析ＡＰＩ３を利用して、エンドユーザに対してアプリケーションを提供する手段である。分析ＡＰＩ利用手段１は、起動すると、コネクション通信手段２を介して、データストリーム分析ＡＰＩ３に対する分析方法のクエリを発行する。具体的には、分析ＡＰＩ利用手段１は、ネットワークを介して、データストリームの分析結果の配信を要求する旨のクエリを、サーバ装置（例えば、データストリーム分析サーバ（Ｐ２））に対して送信する。
【００６３】
図４は、分析ＡＰＩ利用手段１が発行するクエリに含まれる項目例を示す説明図である。図４に示すように、分析ＡＰＩ利用手段１が発行するクエリは、ユーザＩＤＴ１０１やコマンド名Ｔ１０２等の項目を含む。
【００６４】
ユーザＩＤ（Ｔ１０１）は、エンドユーザを識別するための識別情報である。本実施形態では、エンドユーザが使用するクライアント端末として、複数台のマッシュアップＰＣ（Ｐ１）が用いられる場合を想定している。これらのマッシュアップＰＣ（Ｐ１）のエンドユーザを区別するために、エンドユーザ毎にＩＤを予め割り当てておき、クエリ中のこのユーザＩＤ（Ｔ１０１）のフィールドに含める。図４に示す例では、あるマッシュアップＰＣ（Ｐ１）のエンドユーザに割り与えられたユーザＩＤが「ＵＩＤ０００１」であるものとし、ユーザＩＤ「ＵＩＤ０００１」を含むクエリの例が示されている。
【００６５】
コマンド名（Ｔ１０２）は、クライアント端末（マッシュアップＰＣ（Ｐ１））からサーバ装置（データストリーム分析サーバ（Ｐ２））に対して行う要求に対応するコマンドのコマンド名である。クエリ中のコマンド名（Ｔ１０２）のフィールドには、データストリーム分析ＡＰＩ３として公開されているコマンド名が含まれる。図４に示す例では、以下の２種類のコマンドがクエリで指定されている場合が示されている。
【００６６】
「紛失検出」コマンド：紛失したカードが不正に利用されたことを検出した場合に警告を通知することを要求する旨のコマンドである（図４に示す例１参照）。この場合、データストリーム分析手段５は、クレジットカードの利用ログデータの中から、紛失したカードのリストに含まれるカードの利用がないか否かを調査（判定）する。そして、不正利用を検出すると、データストリーム分析ＡＰＩ３を用いて、不正利用が検出された旨の警告をクライアント端末（マッシュアップＰＣ（Ｐ１））に対して通知する。
【００６７】
「頻度異常」コマンド：クレジットカード毎に利用頻度をカウントし、１日に異常に多くの利用があったことを検出した場合に不正利用がされたものとして警告を通知することを要求する旨のコマンドである（図４に示す例２参照）。
【００６８】
ただし、図４に示したコマンドは、一例であり、データストリーム分析ＡＰＩ３において公開されているコマンドであれば、どのようなコマンドでもよい。また、説明を簡単にするために、図４に示す例では、クエリにおいて、日本語によるコマンド名でコマンドが指定されている場合を示しているが、日本語以外の別の表現でコマンドを指定しても構わない。
【００６９】
分析ＡＰＩ利用手段１は、サーバ装置のコネクション通信手段２を介してデータストリーム分析ＡＰＩ３に対するクエリの発行を行う場合、ＵＲＬを指定してアクセスし、要求クエリの送信を行えばよい。図５は、このＵＲＬを指定してアクセスする場合の要求クエリの例を示す説明図である。
【００７０】
ユーザＩＤ（Ｔ１０１）及びコマンド名（Ｔ１０２）の項目は、具体的には、要求クエリにおいて、それぞれ、ＵＲＬのパラメータとして表現される（図５に示す要求クエリ（Ｔ１０４））参照）。図５に示す例では、要求クエリ内において、ユーザＩＤ（Ｔ１０１）としてＵＩＤパラメータが指定され、コマンド名（Ｔ１０２）としてＣＭＤパラメータが指定されている。また、図５に示す例では、データストリーム分析サーバ（Ｐ２）のＵＲＬが「server.co.jp/setQuery 」であり、分析ＡＰＩ利用手段１は、図５に示すＵＲＬに従って、ＨＴＴＰプロトコルを用いて、データストリーム分析サーバ（Ｐ２）にアクセスすることができる。
【００７１】
また、分析ＡＰＩ利用手段１は、ＡＰＩ利用方法判定手段４の判定結果に応じて、図５に示す要求クエリに対する回答を得る方法として、以下の２種類のいずれかの方法によって、回答（データストリームの分析結果）を得る（受信する）ことができる。
【００７２】
（１）コネクション型：マッシュアップＰＣ（Ｐ１）とデータストリーム分析サーバ（Ｐ２）との間でコネクションをはったまま回答（コネクションを確立したままの状態で分析結果を配信）する方式。この方式を用いれば、データストリーム分析サーバ（Ｐ２）からマッシュアップＰＣ（Ｐ１）に対して回答をＰＵＳＨできるため、ＰＵＳＨ型の通信を行うことができ、特に、リアルタイム性が要求されるクエリに対する回答を行う場合に向いている。
【００７３】
（２）ポーリング型：マッシュアップＰＣ（Ｐ１）からデータストリーム分析サーバ（Ｐ２）に対してクエリを送信してセットした後に、一旦コネクションを切断し、以後、定期的にマッシュアップＰＣ（Ｐ１）からクエリの回答を問い合わせることによって回答を得る方式。この方式を用いる場合、マッシュアップＰＣ（Ｐ１）は、データストリーム分析サーバ（Ｐ２）からの回答をＰＵＬＬ型の通信により得ることになる。そのため、リアルタイム性が要求されるクエリに対する回答を行う場合には向いていない。
【００７４】
コネクション型の通信を行う場合には、マッシュアップＰＣ（Ｐ１）から要求クエリを発行したときに確立したそのコネクションの回答として（要求クエリ発行時に確立したコネクションをそのまま維持して）、分析結果が得られる。図６は、コネクション型の通信を行う場合の要求クエリに対する回答例を示す説明図である。図６に示すように、コネクション型の通信を行う場合、データストリーム分析サーバ（Ｐ２）は、回答として、キー名と値とのペアを含む情報を、マッシュアップＰＣ（Ｐ１）に対して返せば（送信すれば）よい。図６に示す例では、キーとして、コマンド名（Ｔ１０５）とクレジットカードのＩＤ（Ｔ１０６）とを含み、これらキーの右辺側に値（具体的なコマンド名やクレジットカード番号）を含む回答を送信する場合が示されている。ただし、図６に示すデータストリーム分析サーバ（Ｐ２）からマッシュアップＰＣ（Ｐ１）に返信される回答のフォーマットは一例であり、データストリームの分析結果を含むデータであれば、本実施形態で示したものに限られない。
【００７５】
ポーリング型の通信を行う場合には、データストリームの分析結果を示す回答を直接得るのではなく、データストリーム分析サーバ（Ｐ２）から、回答を得るためのポーリング間隔とポーリング先のＵＲＬとを含む情報を受信することになる。図７は、ポーリング型の通信を行う場合に一旦受信する情報の例を示す説明図である。図７に示す例において、POLLING-INTERVAL（Ｔ１０７）は、ポーリング間隔を示している。また、POLLING-URL （Ｔ１０８）は、ポーリング先のＵＲＬを示している。
【００７６】
分析ＡＰＩ利用手段１は、図７に示すポーリング間隔に従って、図７に示す情報に含まれるポーリングＵＲＬで特定されるデータストリーム分析サーバ（Ｐ２）にアクセスする。この際、分析ＡＰＩ利用手段１は、図８に示すように、ＵＩＤとコマンド名とをパラメータとして含む情報を送信することによって、データストリーム分析サーバ（Ｐ２）に対してポーリングを行う。
【００７７】
ポーリングによるアクセスをしたときに、データストリームの分析結果がある場合（例えば、不正利用を検出した旨の情報がポーリング型分析結果記憶手段６に記憶されている場合）には、分析ＡＰＩ利用手段１は、コネクション型の通信を行う場合と同様のフォーマットで、データストリーム分析サーバ（Ｐ２）から回答を得ることができる。分析結果がない場合には、ＮＧといったまだ分析結果が存在しないことを表す記号等を含む情報が、データストリーム分析サーバ（Ｐ２）から回答される。この場合、分析ＡＰＩ利用手段１は、分析結果がまだないことを示す情報を受信した場合には、その情報を無視すればよい。
【００７８】
分析ＡＰＩ利用手段１は、データストリームの分析結果を示す回答を受信すると、例えば、受信した回答に基づいて、データストリームの分析結果をディスプレイ装置等の表示装置に表示する。なお、分析ＡＰＩ利用手段１が分析結果をエンドユーザに提示する方法は、本実施形態で示したものに限られない。例えば、分析ＡＰＩ利用手段１は、データストリームの分析結果を示す情報をファイル出力する等の他の出力方法によって提示してもよい。
【００７９】
図９は、分析ＡＰＩ利用手段１が表示する画面例（Ｄ１）を示す説明図である。図９に示す画面例では、クレジットカードの利用ログデータの分析の結果に基づいて、より緊急度の高い重要警告（不正利用の可能性が極めて高いもの）と、利用方法に不正の疑いがある通常警告（重要警告と比べると不正利用の可能性は低いものも、不正利用された可能性があるもの）とを含む表示画面を表示する場合が示されている。
【００８０】
図９に示す例において、画面Ｄ１は、表示領域Ｄ１０１，Ｄ１０２と、ボタンＤ１０３，Ｄ１０４とを含む。表示領域Ｄ１０１は、重要警告のメッセージを表示するための表示領域である。また、表示領域Ｄ１０２は、通常警告のメッセージを表示するための表示領域である。ボタンＤ１０３は、重要警告の詳細な内容の表示を指示するためのボタンである。また、ボタンＤ１０４は、通常警告の詳細な内容の表示を指示するためのボタンである。
【００８１】
分析ＡＰＩ利用手段１の起動時には、内部的には、上記の図４や図５で説明した要求クエリをデータストリーム分析サーバ（Ｐ２）に対して送信する処理を行うのであるが、画面Ｄ１の表示領域には、まだ何も表示されていない状態である。そして、その後、クレジットカードの利用ログデータを分析した結果、警告が発見された段階で、データストリーム分析サーバ（Ｐ２）から、クエリに対する回答を得て、画面Ｄ１の表示領域Ｄ１０１に重要警告が表示されたり、表示領域Ｄ１０２に通常警告が表示される。
【００８２】
図９に示す例は、図６に示す回答（コネクション型の通信を行う場合の要求クエリに対する回答）を受け取った場合の表示画面の例である。なお、分析ＡＰＩ利用手段１は、回答のコマンドを受信する毎に、受信したコマンドに基づいて、受信した回答に示される警告が重要警告であるか通常警告であるかを判定して、画面Ｄ１に表示すればよい。図６に示す回答の例では、受信した回答で示されるコマンド「紛失検出」が重要警告であると判定され、図９に示すように、表示領域Ｄ１０１に警告が表示されている。
【００８３】
また、図９に示す画面Ｄ１において、詳細表示ボタンＤ１０３，Ｄ１０４をエンドユーザが押す操作を行うと、警告の詳細情報を表示する画面に遷移される。この場合、例えば、警告対象のクレジットカードの番号等に基づいて、クレジットカード情報を管理する管理データベースを検索して抽出した情報を表示するようにすればよい。なお、警告の詳細情報を表示する処理については、本発明とは直接関係がないため、説明を省略する。
【００８４】
なお、図９に示す表示画面の表示方法や利用イメージは一例であり、より分かりやすく表示方法を工夫してもよい。例えば、図９に示した表示内容に加えて、表示日時等を表示しても構わない。
【００８５】
コネクション通信手段２の実現方法は、データストリーム分析サーバ（Ｐ２）と、マッシュアップＰＣ（Ｐ１）とを通信可能とするものであれば、どのような手段を用いて実現しても構わない。例えば、インターネットで広く使われているＴＣＰ／ＩＰに従って通信を行う通信デバイスを用いて実現されても構わない。
【００８６】
データストリーム分析ＡＰＩ３は、分析ＡＰＩ利用手段１からコネクション通信手段２を介して分析の要求を受け付け、ＡＰＩ利用方法判定手段４及びデータストリーム分析手段５を制御するためのものである。このデータストリーム分析ＡＰＩ３を用いて行われる制御には、分析ＡＰＩ利用手段１からの分析要求の回答方法の判定を行うフェーズ（フェーズ１）と、このフェーズ１の判定結果に応じて分析結果の回答の作成を他の手段に依頼するフェーズ（フェーズ２）とを含む。
【００８７】
フェーズ１では、データストリーム分析サーバ（Ｐ２）は、データストリーム分析ＡＰＩ３に従って、分析ＡＰＩ利用手段１からの分析要求をＡＰＩ利用方法判定手段４に渡す（出力する）処理を行う。そして、ＡＰＩ利用方法判定手段４から、要求クエリに対する回答方法として、コネクション型を用いるかポーリング型を用いるかの判定結果を得る（入力する）。
【００８８】
フェーズ２では、データストリーム分析サーバ（Ｐ２）は、データストリーム分析ＡＰＩ３に従って、まず、データストリーム分析手段５に対して分析要求を転送する。この場合、分析ＡＰＩ利用手段１からの分析要求と、フェーズ１で判定した回答方法と、分析ＡＰＩ利用手段１との間の通信コネクションを示すポインタとを含む情報が転送される。なお、コネクションを示すポインタとは、回答方法がコネクション型である場合に利用するコネクション型へのポインタであり、回答方法がポーリング型である場合にはポインタに値が設定されないものとする。図１０は、このデータストリーム分析手段５に対して転送されるクエリセットの例を示す説明図である。
【００８９】
図１０に示すように、データストリーム分析手段５に対して転送される情報のフォーマット（Ｔ３０１）には、分析要求のクエリのフォーマットに、ＴＹＰＥパラメータと、ＳＥＳＳＩＯＮパラメータとが追加されている。ＴＹＰＥパラメータは、回答方法を示すパラメータである。また、ＳＥＳＳＩＯＮパラメータは、現在のデータストリーム分析ＡＰＩ３と分析ＡＰＩ利用手段１との間のコネクションのポインタを示すパラメータである。具体的には、ＹＰＥパラメータの値は、コネクション型を用いる場合にはＣＯＮＮＥＣＴＩＯＮとし、ポーリング型を用いる場合にはＰＯＬＬＩＮＧとしておけばよい。また、ＳＥＳＳＩＯＮパラメータの値は、コネクションを識別するためのＩＤであり、ＩＤを示す数値であることが多い。なお、図１０に示した転送情報のフォーマットは一例であり、データストリーム分析手段５に対して転送される情報として、他のフォーマットを用いた情報を用いてもよい。
【００９０】
データストリーム分析手段５に対して分析要求を転送した後、データストリーム分析サーバ（Ｐ２）は、フェーズ１で得られた回答方法の判定結果に応じて、データストリーム分析ＡＰＩ３に従って、以下のように処理を行う。
【００９１】
（１）回答方法がコネクション型である場合：マッシュアップＰＣ（Ｐ１）との間のコネクションをそのまま維持しておき、データストリーム分析手段５が分析結果を生成した時点で、このコネクションを用いて分析ＡＰＩ利用手段１に対して分析結果を回答する。
【００９２】
（２）回答方法がポーリング型である場合：現状のコネクションを利用して、回答方法としてポーリング型を用いることを分析ＡＰＩ利用手段１に対して回答する。この場合、データストリーム分析サーバ（Ｐ２）は、回答方法として、図７に示す例のように、キーと値とのペアを含むフォーマットの情報を送信することによって回答する。なお、図７に示す例では、この回答には、POLLING-INTERVAL（Ｔ１０７）とPOLLING-URL （Ｔ１０８）との項目が含まれる。POLLING-INTERVAL（Ｔ１０７）は、ポーリング間隔を示している。また、POLLING-URL （Ｔ１０８）は、ポーリングする際にポーリング型分析結果記憶手段６にアクセスするためのＵＲＬを示している。
【００９３】
図７に示す回答の例では、分析ＡＰＩ利用手段１からの要求クエリに対して、ＡＰＩ利用方法判定手段４による判定の結果、回答方法としてポーリング型を用いると判定されたことを表している。また、POLLING-INTERVAL（Ｔ１０７）で指定された間隔で、POLLING-URL （Ｔ１０８）で指定されたアドレスで示されるアクセス先にポーリングする必要があるということを表している。なお、POLLING-URL （Ｔ１０８）で指定されるＵＲＬとして、具体的には、ポーリング型分析結果記憶手段６をＷｅｂサーバで構築し、このＷｅｂサーバのＵＲＬを事前に割り当てればよい。
【００９４】
以上のように処理が実行されることによって、分析ＡＰＩ利用手段１から見れば、データストリーム分析ＡＰＩ３に対して分析要求を出す（送信する）と、分析結果の回答方法としてコネクション型を用いるかポーリング型を用いるかが自動判定される。そして、コネクション型を用いると判定された場合には、分析要求のクエリを送信するために確立したコネクションがそのまま維持され、分析結果がこのコネクションを用いてデータストリーム分析サーバ（Ｐ２）から回答される。一方、ポーリング型を用いると判定された場合には、ポーリング間隔のパラメータを含む回答が得られ、一旦コネクＦションが切断される。以後、ポーリング間隔の指示に従い、繰り返し分析要求を出して（出力して）ポーリングを行い、そのポーリングに対して分析結果が配信される。
【００９５】
ポーリング型分析結果記憶手段６は、回答方法としてポーリング型を用いると判定された場合に、データストリーム分析手段５が処理したデータストリームの分析結果を一時的に記憶する手段である。そして、この記憶メモリ（ポーリング型分析結果記憶手段６）に対して、処理時間毎に、分析ＡＰＩ利用手段１から分析結果があるか否かがポーリングされる。
【００９６】
図１１は、ポーリング型分析結果記憶手段６が記憶するデータストリームの分析結果を一時的に記憶するための回答一時記憶テーブルの一例を示す説明図である。図１１に示すように、ポーリング型分析結果記憶手段６は、日時（Ｔ６０１）、ユーザＩＤ（Ｔ６０２）、コマンド（Ｔ６０３）、及びＣＡＲＤ−ＩＤ（Ｔ６０４）を含む回答一時記憶テーブルを記憶する。図１１において、日時（Ｔ６０１）は、回答一時記憶テーブル中のこのエントリーが追加された日時である。また、ユーザＩＤ（Ｔ６０２）は、ＵＩＤ（ユーザＩＤ）の値である。また、コマンド（Ｔ６０３）は、ＣＭＤ（コマンド）の値である。また、ＣＡＲＤ−ＩＤ（Ｔ６０４）は、データストリーム分析手段５が分析しているデータストリーム中のＣＡＲＤ−ＩＤフィールド（クレジットカード不正利用の分析を行う場合におけるクレジットカード識別子の情報）である。
【００９７】
ＡＰＩ利用手段１からのポーリングを可能とするために、ポーリング型分析結果記憶手段６は、例えば、Ｗｅｂサーバを用いて実装すればよい。この場合、ポーリング型分析結果記憶手段６を実現するＷｅｂサーバは、ＡＰＩ利用手段１からアクセスされると、パラメータとしてＵＩＤとコマンド名とを記憶しているので、パラメータＵＩＤとユーザＩＤフィールドとを照合し、パラメータＣＭＤとコマンドフィールドとを照合させて、分析ＡＰＩ利用手段１から要求された分析結果を検索して回答を返す（出力する）。一方、回答がない場合（分析結果がまだない場合）には、Ｗｅｂサーバは、分析結果がないことを示すＮＧといったコードを含む情報を返せば（送信すれば）よい。
【００９８】
データストリーム分析手段５は、大規模データストリームをリアルタイムに分析する手段である。データストリーム分析手段５は、例えば、内部的に、解析対象であるデータストリームと、解析方法であるクエリを管理するクエリ管理テーブルと、データストリームにクエリを適用して分析処理するための解析アルゴリズムとを有する。以下、一例として、クレジットカードの利用履歴を解析対象のデータストリームとして分析処理する場合を説明する。
【００９９】
図１２は、分析対象のデータストリームであるクレジットカードの利用履歴の例を示す説明図である。図１２に示すように、クレジットカードの利用履歴は、日時（Ｔ５０１）、ＣＡＲＤ−ＩＤ（Ｔ５０２）、利用金額（Ｔ５０３）、及び利用場所（Ｔ５０４）を含む。図１２において、日時（Ｔ５０１）は、クレジットカードを利用した日時である。また、ＣＡＲＤ−ＩＤ（Ｔ５０２）は、利用したクレジットカードを識別するための識別子である。また、利用金額（Ｔ５０３）は、クレジットカード利用金額である。また、利用場所（Ｔ５０４）は、クレジットカード利用場所を識別するための識別子である。なお、図１２に示すフィールドを含む利用履歴のデータは一例であり、利用履歴として、別のフィールドを含む情報を用いても構わない。
【０１００】
次に、クエリ管理テーブルについて説明する。図１３は、クエリ管理テーブルの例を示す説明図である。図１３に示す例では、クエリ管理テーブルは、ユーザＩＤ（Ｔ５１１）、コマンド（Ｔ５１２）、回答タイプ（Ｔ５１３）、及びコネクション（Ｔ５１４）のフィールドを含む。データストリーム分析手段５は、データストリーム分析ＡＰＩ３に従った処理が実行されて、クエリと回答のタイプとを受け取ると（入力すると）、入力したクエリと回答タイプとを図１３に示す管理テーブルに格納する。図１３において、ユーザＩＤ（Ｔ５１１）は、ＵＩＤ（ユーザＩＤ）の値である。また、コマンド（Ｔ５１２）は、ＣＭＤ（コマンド）の値である。また、回答タイプ（Ｔ５１３）は、ＴＹＰＥ（回答方法を示すパラメータ）の値である。また、コネクション（Ｔ５１４）は、ＳＥＳＳＩＯＮ（コネクションを識別するためのＩＤ）の値である。なお、図１３に示すクエリ管理テーブルは一例であり、クエリのフォーマットに応じて、クエリ管理テーブルのフォーマットを適宜変更する必要がある。
【０１０１】
また、データストリーム分析手段５は、解析アルゴリズムに従って、データストリームとしてデータが発生する度に、コマンドを順に適用して処理を実行する。図１３に示す例では。データストリーム分析手段５は、紛失検出というコマンドと、頻度異常というコマンドとを順に適用して処理を実行する。解析アルゴリズムには、このコマンド名に対応して実際にどのような解析処理を実行すべきかが規定されている。例えば、データストリーム分析手段５は、紛失検出というコマンドに従って、紛失届けが出されているクレジットカードのＣＡＲＤ−ＩＤの一覧と、データストリーム中に含まれるＣＡＲＤ−ＩＤとを照らし合わせてマッチングを行い、合致するＣＡＲＤ−ＩＤが存在すれば、不正利用を発見したと判定して回答する。
【０１０２】
データストリーム分析手段５は、コマンドを適用して分析処理を実行した結果、ＣＡＲＤ−ＩＤがマッチ（合致）して不正利用を発見したと判定した場合、不正利用を発見した旨の分析結果を回答する。この場合、データストリーム分析手段５は、回答方法として、マッチしたコマンドに対応する回答タイプによって、以下の方法に従って、分析結果を回答する。
【０１０３】
（１）回答タイプがコネクション型である場合：データストリーム分析手段５は、そのコマンドを含むクエリの送信時に確立されたセッションをそのまま維持して用いて、コネクション通信手段２を介して、分析結果を直ちに分析ＡＰＩ利用手段１に対して回答する。
【０１０４】
（２）回答タイプがポーリング型である場合：データストリーム分析手段５は、ポーリング型分析結果記憶手段６内の回答一時記憶テーブルに、以下に示す情報を格納することにより、分析結果を一時記憶する。データストリーム分析手段５は、回答一時記憶テーブルの日時フィールド（Ｔ６０１）に、現在時刻を取得（例えば、タイマからの時刻信号を入力）して格納させる。また、データストリーム分析手段５は、回答一時記憶テーブルのユーザＩＤフィール（Ｔ６０２）に、マッチしたクエリ中のユーザＩＤ（Ｔ５１１）を格納させる。また、データストリーム分析手段５は、回答一時記憶テーブルのコマンドフィールド（Ｔ６０３）に、マッチしたクエリ中のコマンド（Ｔ５１２）を格納させる。また、データストリーム分析手段５は、回答一時記憶テーブルのカードＩＤフィールド（Ｔ６０３）に、マッチしたデータ中のＣＡＲＤ−ＩＤ（Ｔ５０４）の値を格納させる。
【０１０５】
ＡＰＩ利用方法判定手段４は、データストリーム分析ＡＰＩ３による処理に従ってクエリを受け取り（入力し）、このクエリで要求されている分析結果の回答方法（すなわち、回答方法をコネクション型とするかポーリング型とするかい）を判定する手段である。
【０１０６】
ＡＰＩ利用方法判定手段４の回答方法決定手段４０１は、データストリーム分析ＡＰＩ３との窓口としての役割を果たす。すなわち、回答方法決定手段４０１は、データストリーム分析ＡＰＩ３による処理に従ってクエリを受け取り（入力し）、回答として分析結果の回答方法の決定結果を返す（出力する）。また、回答方法決定手段４０１は、ＡＰＩ利用方法判定手段４の全体のメイン制御を行い、分析結果監視手段４０２や、通信環境監視手段４０３、計算機リソース監視手段４０４を制御する。なお、回答方法決定手段４０１は、分析結果監視手段４０２や、通信環境監視手段４０３、計算機リソース監視手段４０４の監視結果に基づいて、ルール記憶手段４０に記憶するルールに従って、分析結果の回答方法を決定する。
【０１０７】
回答方法決定手段４０１は、データストリーム分析ＡＰＩ３による処理に従ってクエリを受け取ると（入力すると）、分析結果監視手段４０２、通信環境監視手段４０３、及び計算機リソース監視手段４０４に対して、それぞれ、以下に示す情報を問い合わせて取得（入力）し、それら取得した情報に基づいて、回答方法としてコネクション型を用いるかポーリング型を用いるかを判定する。この場合、回答方法決定手段４０１は、通信環境監視手段４０３に対して、分析ＡＰＩ利用手段１と、データストリーム分析ＡＰＩ３を公開するデータストリーム分析サーバ（Ｐ２）との間の通信状態を示す情報を、監視結果として要求して入力する。また、回答方法決定手段４０１は、計算機リソース監視手段４０４に対して、ＣＰＵや、メモリ、ネットワーク等の計算機リソースの利用状況を示す情報を、監視結果として要求して入力する。また、回答方法決定手段４０１は、分析結果監視手段４０２に対して、今回のクエリで要求されている分析結果と同種の過去の分析状況を示す情報を、監視結果として要求して入力する。
【０１０８】
次に、回答方法決定手段４０１が行う分析結果の判定処理について説明する。回答方法決定手段４０１は、ルール記憶手段４０が記憶する以下に示すようなルールを順に適用して、分析結果の回答方法を判定する。
【０１０９】
（１）ルール１：回答方法決定手段４０１は、計算機リソース監視手段４０４から入力した計算機リソースの状況の監視結果に基づいて、リソースが不足していると判定した場合、回答方法としてポーリング型を用いることに決定する。また、回答方法決定手段４０１は、リソースに余裕があると判定した場合、以下のルール２以降のルールを用いた判定を行うと判定する。
【０１１０】
（２）ルール２：回答方法決定手段４０１は、通信環境監視手段４０３から入力した通信環境の監視結果に基づいて、例えば、１０分以内にコネクションが強制切断されると判定した場合、回答方法としてポーリング型を用いることに決定する。例えば、マッシュアップＰＣ（Ｐ１）とデータストリーム分析サーバ（Ｐ２）との間にプロキシサーバが存在する場合には、プロキシサーバによって所定時間（例えば、１０分）を限度にコネクションが強制切断されてコネクション型による通信を行えない場合がある。そのような場合、回答方法決定手段４０１は、コネクション型による通信を行えないと判定して、回答方法としてポーリング型を用いることに決定する。また、回答方法決定手段４０１は、１０分より長い時間コネクションが維持されると判定した場合、以下のルール３以降のルールを用いた判定を行うと判定する。
【０１１１】
（３）ルール３：回答方法決定手段４０１は、分析結果監視手段４０２から入力した過去の分析状況の監視結果に基づいて、例えば、クエリのマッチング頻度（後述する）が１０回／時間以上であると判定した場合、回答方法としてコネクション型を用いることに決定する。また、回答方法決定手段４０１は、マッチング頻度が１０回／時間未満であると判定した場合には、回答方法として、ポーリング型を用いることに決定する。
【０１１２】
なお、上記では、説明を分かりやすくするために、ルールを日本語で記載する場合を示しているが、実際に計算機（コンピュータ）を用いて実現するためには、何らかの計算機言語で記載したルールを用いて処理を行う。また、本実施形態で示したルールの内容は一例であり、回答方法決定手段４０１は、他のルールを用いて、回答方法を判定してもよい。
【０１１３】
また、本実施形態では、上記に示したように、計算機リソース監視手段４０４の監視結果、通信環境監視手段４０３の監視結果、及び分析結果監視手段４０２の監視結果の順に優先してルールを用いた判定を行うことにより、回答方法の判定を行う場合を示したが、いずれの監視結果の順に優先して判定を行うかは、本実施形態で示したものに限られない。例えば、通信環境の監視結果を最も重要視して、通信環境監視手段４０３の監視結果、計算機リソース監視手段４０４の監視結果、及び分析結果監視手段４０２の監視結果に順に優先してルールを用いた判定を行ってもよい。
【０１１４】
また、必ずしも分析結果監視手段４０２、通信環境監視手段４０３、及び計算機リソース監視手段４０４の全ての監視結果について判定を行う必要はなく、いずれか１つ又は２つの監視結果に基づいて判定を行ってもよい。この場合、例えば、ルール１を用いた判定を行う場合には、リソースに余裕があると判定した場合、そのまま回答方法としてコネクション型を用いることに決定してもよい。また、例えば、ルール２を用いた判定を行う場合には、１０分より長い時間コネクションが維持されると判定した場合、そのまま回答方法としてコネクション型を用いることに決定してもよい。
【０１１５】
また、例えば、分析結果監視手段４０２、通信環境監視手段４０３、及び計算機リソース監視手段４０４の全ての監視結果について、コネクション型の適用条件を満たしたことを条件として、回答方法としてコネクション型を用いることに決定し、いずれか１つでもコネクション型の適用条件を満たさなければ、回答方法としてポーリング型を用いることに決定してもよい。また、逆に、例えば、分析結果監視手段４０２、通信環境監視手段４０３、及び計算機リソース監視手段４０４の監視結果のうちのいずれか１つでも、コネクション型の適用条件を満たしたことを条件として、回答方法としてコネクション型を用いることに決定し、１つもコネクション型の適用条件を満たさなければ、回答方法としてポーリング型を用いることに決定してもよい。
【０１１６】
以上のように、回答方法決定手段４０１は、分析結果監視手段４０２や、通信環境監視手段４０３、計算機リソース監視手段４０４の監視結果を様々に組み合わせて用いて、分析結果の回答方法を判定することができる。
【０１１７】
通信環境監視手段４０３は、ユーザ毎に、コネクション通信手段２を介したコネクションの強制切断の有無や時間を監視する。通信環境監視手段４０３は、回答方法決定手段４０１からクエリ中のＵＩＤをパラメータとして含む指示情報が出力されることによって呼び出される。そして、通信環境監視手段４０３は、監視結果として、回答方法決定手段４０１に対して、コネクションが強制切断されるまでの期間を求めて回答する。なお、通信環境監視手段４０３は、例えば、データストリーム分析サーバ（Ｐ２）のスレッドや、マッシュアップＰＣ（Ｐ１）とデータストリーム分析サーバ（Ｐ２）との間のネットワークソケットを監視することによって、通信環境を監視する。
【０１１８】
通常、ＴＣＰ／ＩＰを用いた通信を行う場合には、特に制限なくコネクションを継続することができる。しかし、コネクションを継続して確立したままとすると、計算機のリソースを占有してしまうことになるので、通常の運用では、プロキシサーバやルータが、一定間隔毎にコネクションを強制切断することが行われている。コネクション通信手段２は、コネクションが切断されると、通信先と通信機関とのイベントを発生する。通信環境監視手段４０３は、このコネクション通信手段２が発生するイベントを検知して、所定の記憶テーブルに履歴情報を残す（格納する）。
【０１１９】
図１４は、通信環境監視手段４０３が有する記憶テーブルの例を示す説明図である。図１４に示すように、通信環境監視手段４０３は、ＵＩＤ（Ｔ４０３０１）と、タイムアウト（Ｔ４０３０２）とを含む記憶テーブルを有する（具体的には、記憶装置に記憶している）。図１４において、ＵＩＤ（Ｔ４０３０１）は、クエリ中のＵＩＤである。また、タイムアウト（Ｔ４０３０２）は、コネクションを継続できた時間（秒）である。
【０１２０】
通信環境監視手段４０３は、回答方法決定手段４０１から、クエリ中のＵＩＤを受け取ると（入力すると）、入力したＵＩＤをキーとして、この図１４に示す記憶テーブル中のＵＩＤのフィールド（Ｔ４０３０１）のＵＩＤと合致するものがあるか否かを検索する。そして、通信環境監視手段４０３は、合致するＵＩＤがあれば、その合致したＵＩＤに対応するタイムアウト（Ｔ４０３０２）を、記憶テーブルから抽出し、検索結果のタイムアウトの値を回答方法決定手段４０１に対して回答（出力）する。なお、通信環境監視手段４０３は、複数のレコードが検索された場合には、例えば、それらの平均値（タイムアウト時間の平均値）を求めて返答すればよい。また、レコードが見つからなかった場合には、通信環境監視手段４０３は、強制切断されない通信であると判定し、強制切断されない旨を示すＫＥＥＰといった専用のコードを返せばよい。
【０１２１】
なお、通信環境監視手段４０３が通信環境として監視する情報は、本実施形態で示したものに限らず、例えば、マッシュアップＰＣ（Ｐ１）とデータストリーム分析サーバ（Ｐ２）との間の通信速度や通信データ量を監視してもよい。ただし、一般に、分析ＡＰＩ利用手段１に対して回答すべき分析結果（例えば、クレジットカードの不正利用の検出）が実際に発生する頻度は、それ程高くないことから、コネクションの強制切断の有無や時間を監視することが最も実用的である。
【０１２２】
計算機リソース監視手段４０４は、データストリーム分析サーバ（Ｐ２）の計算機リソースをＯＳのＡＰＩを用いて監視する。計算機リソース監視手段４０４は、回答方法決定手段４０１からの呼出に対して、ＣＰＵや、メモリ、ネットワークのうちのいずれかのリソースに余裕があるか否かを判定する。そして、計算機リソース監視手段４０４は、リソースに余裕がないと判定した場合にはＮＧである旨の監視結果を出力し、リソースに余裕があると判定した場合にはＯＫである旨の監視結果を返答（出力）すればよい。なお、余裕がある／なしの判定は、リソースの種類毎に閾値を予め設定して、閾値判定を行うことにより行えばよい。例えば、メモリについて判定を行う場合、計算機リソース監視手段４０４は、例えば、メモリの記憶領域を既に８０％以上使用していると判定した場合には、リソースに余裕がないと判定し、ＮＧである旨の監視結果を出力すればよい。
【０１２３】
なお、計算機リソース監視手段４０４がリソース環境として監視する情報は、本実施形態で示したものに限らず、例えば、データストリーム分析サーバ（Ｐ２）のＣＰＵ使用率等を監視してもよい。ただし、一般に、分析ＡＰＩ利用手段１に対して回答すべき分析結果（例えば、クレジットカードの不正利用の検出）が実際に発生する頻度は、それ程高くないことから、ＣＰＵ使用率がそれ程高くなることはなく、メモリの記憶容量を監視することが最も実用的である。
【０１２４】
分析結果監視手段４０２は、データストリーム分析手段５内のコマンドのマッチングの頻度（コマンドが合致すると判定される頻度）を監視し、その監視結果を記憶テーブルに記録する。この場合、分析結果監視手段４０２は、回答方法決定手段４０１から、クエリ中のＣＭＤをパラメータとして含む指示情報が出力されることによって呼び出される。そして、分析結果監視手段４０２は、回答方法決定手段４０１に対して、マッチング頻度の監視結果を回答する。
【０１２５】
図１５は、分析結果監視手段４０２が有する記憶テーブルの例を示す説明図である。図１５に示すように、分析結果監視手段４０２は、ＣＭＤ（Ｔ４０２０１）と、頻度（Ｔ４０２０２）とを含む記憶テーブルを有する（具体的には、記憶装置に記憶している）。図１５において、ＣＭＤ（Ｔ４０２０１）は、コマンド名である。また、頻度（Ｔ４０２０２）は、マッチング頻度である。
【０１２６】
分析結果監視手段４０２は、マッチング頻度の計算を行う場合、例えば、ＣＭＤ（コマンド）をカウントするためのカウンタをコマンド種類毎にもっておくようにすればよい。そして、分析結果監視手段４０２は、コマンドのマッチングを行う毎に、マッチングしたＣＭＤ（コマンド）に対応するカウンタをカウントアップし、例えば、１日毎に、カウントアップ後のカウンタの値に基づいて、図１５に示す記憶テーブルを更新すればよい。
【０１２７】
なお、本実施形態において、例えば、データストリーム分析サーバ（Ｐ２）の記憶装置（図示せず）は、マッシュアップＰＣ（Ｐ１）に対するプッシュ型サービスを実現するための各種プログラムを記憶している。例えば、データストリーム分析サーバ（Ｐ２）の記憶装置は、コンピュータに、データを分析するデータ分析処理と、リソースの状況に応じて、データの分析結果を公開するためのＡＰＩを用いた分析結果の配信方法を決定する配信方法決定処理とを実行させるためのプッシュ型サービス実現用プログラムを記憶している。
【０１２８】
次に、動作について説明する。図１６は、データストリーム分析サービス提供システムを用いて、プッシュ型サービスを提供する処理の一例を示すフローチャートである。図１６に示すように、本実施形態では、データストリーム分析サービス提供システムは、データストリーム分析サーバステップ（ステップＳ２０）と、マッシュアップ分析ステップ（ステップＳ２１）とを実行する。
【０１２９】
図１６に示すように、本実施形態では、データストリーム分析サービス提供システムは、データストリーム分析サーバステップ（ステップＳ２０）と、マッシュアップ分析ステップ（ステップＳ２１）とを実行する。データストリーム分析サーバステップ（ステップＳ２０）は、大規模データストリームをリアルタイムに分析するアプリケーションをマッシュアップ的に簡単に構築できるデータストリーム分析装置（例えば、データストリーム分析サーバ（Ｐ２））に関して、データストリームを分析してＡＰＩを通して分析結果をサービスするための処理を実行するステップである。また、マッシュアップ分析ステップ（ステップＳ２１）は、エンドユーザに対してデータストリーム分析結果を提供するために、データストリーム分析サーバステップ（ステップＳ２０）の処理を実行するデータストリーム分析サーバ（Ｐ２）に対してクエリを発行して回答を得るステップである。
【０１３０】
また、マッシュアップ分析ステップ（ステップＳ２１）は、クエリ発行ステップ（ステップＳ１０１）、ポーリング情報受信ステップ（ステップＳ１０２）、判定ステップ（ステップＳ１０３）、ポーリングステップ（ステップＳ１０４）、回答受信ステップ（ステップＳ１０５）、及び分析結果提示ステップ（ステップＳ１０６）を含む。
【０１３１】
クエリ発行ステップ（ステップＳ１０１）は、データストリーム分析のクエリを発行するステップである。また、ポーリング情報受信ステップ（ステップＳ１０２は、クエリ発行ステップ（ステップＳ１０１）で発行したクエリの回答をポーリング型で受信すする場合に、そのポーリング方法を示す情報を受信するステップである。判定ステップ（ステップＳ１０３）は、クエリ発行ステップ（ステップＳ１０１）で発行したクエリの回答をポーリング型で受信するか否かを判定するステップである。ポーリングステップ（ステップＳ１０４）は、クエリ発行ステップ（ステップＳ１０１）で発行したクエリの回答をポーリング型で受信する場合に、クエリの回答を得るためのポーリングを行うステップである。回答受信ステップ（ステップＳ１０５）は、クエリ発行ステップ（ステップＳ１０１）で発行したクエリの回答をコネクション型で受信する場合に、クエリの回答を得るステップである。分析結果提示ステップ（ステップＳ１０６）は、ポーリングステップ（ステップＳ１０４）で得た回答、及び回答受信ステップ（ステップＳ１０５）で得た回答に基づいて、エンドユーザに対してデータストリーム分析結果を提示するステップである。
【０１３２】
また、データストリーム分析サーバステップ（ステップＳ２０）は、クエリ受信ステップ（ステップＳ１）、回答方法判定ステップ（ステップＳ２）、判定ステップ（ステップＳ３）、ポーリング依頼ステップ（ステップＳ４）、クエリセットステップ（ステップＳ５）、データストリーム分析ステップ（ステップＳ６）、判定ステップ（ステップＳ７）、回答一時記憶ステップ（ステップＳ８）、及び回答送信ステップ（Ｓ９）を含む。
【０１３３】
クエリ受信ステップ（ステップＳ１）は、クエリ発行ステップ（ステップＳ１０１）で発行されたクエリを受け取る（受信する）ステップである。回答方法判定ステップ（ステップＳ２）は、クエリ受信ステップ（ステップＳ１）で得たクエリの回答方法のタイプを判定するステップである。判定ステップ（ステップＳ３）は、回答方法判定ステップ（ステップＳ２）において判定された回答タイプがポーリング型であるか否かを判定するステップである。ポーリング依頼ステップ（ステップＳ４）は、回答タイプがポーリング型である場合に、マッシュアップ分析ステップ（ステップＳ２１）を実行するマッシュアップＰＣ（Ｐ１）に対してポーリングを依頼するステップである。クエリセットステップ（ステップＳ５）は、クエリ受信ステップ（ステップＳ１）で得たクエリを、データストリームの分析要求のクエリとしてセットするステップである。
【０１３４】
データストリーム分析ステップ（ステップＳ６）は、クエリセットステップ（ステップＳ５）の結果、セットされているクエリを順にデータストリームに適用して分析処理するステップである。判定ステップ（ステップＳ７）は、回答方法判定ステップ（ステップＳ２）において判定された回答タイプがポーリング型であるか否かを判定するステップである。回答一時記憶ステップ（ステップＳ８）は、回答タイプがポーリング型である場合に、クエリの回答を、マッシュアップ分析ステップ（ステップＳ２１）の処理を実行するマッシュアップＰＣ（Ｐ１）がアクセスできるように、メモリに一時記憶するステップである。回答送信ステップ（ステップＳ９）は、回答タイプがコネクション型である場合に、クエリの回答を、マッシュアップ分析ステップ（ステップＳ２１）の処理を実行するマッシュアップＰＣ（Ｐ１）に回答するステップである。
【０１３５】
以下、実際に処理が行われる順に、各ステップの処理を説明する。
【０１３６】
［クエリ発行ステップ］
まず、最初に、マッシュアップＰＣ（Ｐ１）の分析ＡＰＩ利用手段１は、クエリ発行ステップ（ステップＳ１０１）の処理を実行し、データストリームの分析結果を要求するためのクエリを発行（生成）する。そして、分析ＡＰＩ利用手段１は、発行したクエリを、通信ネットワークを介してデータストリーム分析サーバ（Ｐ２）に対して送信する。
【０１３７】
［クエリ受信ステップ］
次に、データストリーム分析サーバステップ（ステップＳ２０）を実行するデータストリーム分析サーバ（Ｐ２）は、コネクション通信手段２及びデータストリーム分析ＡＰＩ３を用いて、クエリ発行ステップ（ステップＳ１０１）で発行されたクエリを、クエリ受信ステップ（ステップＳ１）の処理を実行して、通信ネットワークを介して受信する。
【０１３８】
［回答方法判定ステップ］
次に、データストリーム分析サーバ（Ｐ２）のＡＰＩ利用方法判定手段４は、受信したクエリに対する分析結果の回答方法を判別するために、回答方法判定ステップ（ステップＳ２）の処理を実行して、データストリームの分析結果の回答方法をポーリング型とするかコネクション型とするかを判定する。次いで、データストリーム分析サーバ（Ｐ２）は、判定された分析結果の回答方法がポーリング型であるか否かを判定し（ステップＳ３）、判定結果がポーリング型である場合（ステップＳ３のＹＥＳ）には、ポーリング依頼ステップ（ステップＳ４）の処理に移行する。ポーリング型でなければ（すなわち、コネクション型であれば）、そのままクエリセットステップ（ステップＳ５）の処理に移行する。
【０１３９】
［ポーリング依頼ステップ］
ポーリング依頼ステップ（ステップＳ４）では、データストリーム分析サーバ（Ｐ２）は、コネクション通信手段２やデータストリーム分析ＡＰＩ３を用いて、クエリ発行ステップ（ステップＳ１０１）で発行されたクエリに対する分析結果の回答方法がポーリング型である旨の情報、及びポーリング間隔やポーリング先のＵＲＬを示す情報（ポーリング情報）を、マッシュアップ分析ステップ（ステップＳ２１）を実行するマッシュアップＰＣ（Ｐ１）に、通信ネットワークを介して送信して、ポーリングを依頼する。
【０１４０】
［ポーリング情報受信ステップ］
次いで、ポーリング依頼ステップ（ステップＳ４）の処理が実行されると、マッシュアップ分析ステップ（ステップＳ２１）を実行するマッシュアップＰＣ（Ｐ１）の分析ＡＰＩ利用手段１は、ポーリング情報受信ステップ（ステップＳ１０２）を実行して、通信ネットワークを介してポーリング情報を受信する。
【０１４１】
［クエリセットステップ］
また、クエリセットアップステップ（ステップＳ５）では、データストリーム分析サーバ（Ｐ２）は、データストリーム分析ＡＰＩ３を用いて、クエリ受信ステップ（ステップＳ１）で受信したクエリを、データストリームの分析要求クエリとしてセットする。
【０１４２】
［データストリーム分析ステップ］
クエリセットステップ（ステップＳ５）でクエリがセットされると、データストリーム分析サーバ（Ｐ２）のデータストリーム分析手段５は、このセットされたクエリに基づいて、データストリーム分析ステップ（ステップＳ６）の処理を実行し、データストリームを分析する。
【０１４３】
［回答一時記憶ステップ］及び［回答送信ステップ］
次いで、回答方法判定ステップ（ステップＳ２）においてポーリング型と判定されている場合には（ステップＳ７のＹＥＳ）、データストリーム分析サーバ（Ｐ２）は、データストリーム分析ステップ（Ｓ６）でデータストリーム分析の結果回答が生成されると、回答一時記憶ステップ（ステップ（Ｓ８）の処理を実行し、分析結果をポーリング型分析結果記憶手段６に一時記憶させる。また、回答方法判定ステップ（ステップＳ２）においてコネクション型と判定されている場合には（ステップＳ７のＮＯ）、データストリーム分析サーバ（Ｐ２）は、回答送信ステップ（ステップＳ９）の処理を実行して、データストリームの分析結果を、通信ネットワークを介してマッシュアップＰＣ（Ｐ１）に送信する。
【０１４４】
［ポーリングステップ］
一方、マッシュアップ分析ステップ（ステップＳ２１）を実行するマッシュアップＰＣ（Ｐ１）の分析ＡＰＩ利用手段１は、ポーリング型である場合には（ステップＳ１０３のＹＥＳ）、ポーリング依頼ステップ（ステップＳ４）で提示（送信）されたポーリング情報に示されるポーリング間隔に基づいて、ポーリングステップ（ステップＳ１０４）の処理を実行し、所定時間毎にポーリングを行う。この場合、データストリーム分析サーバ（Ｐ２）のポーリング型分析結果記憶手段６に分析結果が記憶されている場合には、分析ＡＰＩ利用手段１は、ポーリングに対する応答結果として、分析ＡＰＩ利用手段１から、通信ネットワークを介して、データストリームの分析結果を受信することになる。
【０１４５】
［回答受信ステップ］
回答受信ステップ（ステップＳ１０５）では、マッシュアップＰＣ（Ｐ１）の分析ＡＰＩ利用手段１は、コネクション型である場合に、データストリーム分析ステップ（ステップＳ６）における分析結果を、回答送信ステップ（ステップＳ９）における回答として、通信ネットワークを介して受信する。
【０１４６】
［分析結果提示ステップ］
そして、最後に、マッシュアップＰＣ（Ｐ１）の分析ＡＰＩ利用手段１は、ポーリングステップ（ステップＳ１０４）、及び回答受信ステップ（ステップＳ１０５）で得たクエリに対する回答を、エンドユーザに対して提示する処理を実行する（ステップＳ１０６）。この場合、分析ＡＰＩ利用手段１は、例えば、データストリームの分析結果を、ディスプレイ表示装置等の表示装置に表示させる。
【０１４７】
以上に説明したように、本実施形態によれば、データストリーム分析サービスを提供するＡＰＩの利用方法を、利用する側のネットワーク環境や、データストリーム分析手段５の計算機リソースの状況に応じて判定するＡＰＩ利用方法判定手段５を備える。この場合、ネットワーク環境や計算機リソースに余裕があればコネクション型を選択してＰＵＳＨ型のサービスを提供し、余裕がなければポーリング型を選択する。ただし、ポーリング型を選択した場合であっても、クエリを一度送信しさえすれば、その後は、自動的にポーリングが行われて分析結果の配信を受けることから、ユーザから見ると、見た目上ＰＵＳＨ型のサービスが実現される。そのため、大規模データストリームをリアルタイムに分析するアプリケーションをマッシュアップ的に簡単に構築できるとともに、少なくとも、見た目上ＰＵＳＨ型のサービスの提供を実現することができる。従って、ＡＰＩを組み合わせてマッシュアップ的に簡単にシステムを構築する場合において、ＰＵＳＨ型のサービスを提供することができる。
【０１４８】
なお、本実施形態では、分析結果の利用方法（回答方法）として、コネクション型又はポーリング型のいずれかを選択する場合を示したが、分析結果の利用方法の選択の仕方は、本実施形態で示したものに限られない。例えば、利用方法の種類としてポーリング間隔の異なる複数のポーリング型を設けるようにしてもよい。そして、ＡＰＩ利用方法判定手段４は、ネットワーク環境や計算機リソースに余裕があれば、ポーリング間隔の短いポーリング型を選択するようにし、余裕がなければ、ポーリング間隔の長いポーリング型を選択するようにしてもよい。
【０１４９】
実施形態２．
次に、本発明の第２の実施形態について図面を参照して説明する。第１の実施形態では、データストリーム分析サービス提供システムの各手段１〜６が全て同じ設定者によって設計され構築される場合を説明したが、必ずしも同じ設計者によって設計されるとは限らない。特に、分析ＡＰＩ利用手段１は、一般に、クライアント端末（マッシュアップＰＣ（Ｐ１））側に搭載される。そのため、マッシュアップＰＣ（Ｐ１）とデータストリーム分析サーバ（Ｐ２）とが異なる設計者によって設計されれば、分析ＡＰＩ利用手段１は、他の手段２〜６とは異なる設計者によって設計され構築されるのが一般的である。そこで、本実施形態では、分析ＡＰＩ利用手段１が他の手段２〜６とは異なる設計者によって設計される場合について説明する。
【０１５０】
図１７は、第２の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。図１７に示すように、本実施形態では、データストリーム分析サービス提供システムが、図１で示した構成要素に加えて、データストリーム分析ＡＰＩラッパー７を含む点で、第１の実施形態と異なる。また、本実施形態では、分析ＡＰＩ利用手段１Ａの機能が、第１の実施形態で示した分析ＡＰＩ利用手段１の機能と異なる。
【０１５１】
データストリーム分析ＡＰＩラッパー７は、マッシュアップＰＣ（Ｐ１）上で動作し、データストリーム分析サーバ（Ｐ２）からの分析結果のメッセージを解釈して、データストリーム分析サーバ（Ｐ２）からの呼び出しを制御するためのものである。なお、データストリーム分析ＡＰＩラッパー７は、予めデータストリーム分析サーバ（Ｐ２）の設計者によって提供され、マッシュアップＰＣ（Ｐ１）に搭載される。
【０１５２】
分析ＡＰＩ利用手段１Ａは、第１の実施形態で示した分析ＡＰＩ利用手段１と同様に、エンドユーザに対するサービス提供を実現する機能を備える。ただし、本実施形態では、分析ＡＰＩ利用手段１は、第１の実施形態で示した分析ＡＰＩ利用手段１と異なり、ポーリング型が選択された場合に、データストリーム分析サーバ（Ｐ２）に対して自動的にポーリングする処理や、データストリームの分析結果を受信する処理については行わない。なお、本実施形態では、マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩラッパー７に従って処理を実行することによって、データストリーム分析サーバ（Ｐ２）に対してポーリングを行ったり、データストリームの分析結果を受信したりする。
【０１５３】
次に、データストリーム分析サービス提供システムの物理構成について説明する。図１８は、第２の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。図１８に示すように、本実施形態では、マッシュアップＰＣ（Ｐ１）は、分析ＡＰＩ利用手段１Ａと、データストリーム分析ＡＰＩラッパー７とを含む。なお、データストリーム分析サーバ（Ｐ２）の物理構成については、第１の実施形態で示した構成と同様である。図１８に示すように、データストリーム分析ラッパー７は、コネクション通信手段２と分析ＡＰＩ利用手段１Ａとの間に位置し、マッシュアップＰＣ（Ｐ１）で動作する。
【０１５４】
本実施形態では、第１の実施形態で示したデータストリーム分析サービス提供システムより、さらに簡単にマッシュアップＰＣ（Ｐ１）上で分析ＡＰＩ利用手段１Ａを用いたエンドユーザへのサービスを実現することを目指している。第１の実施形態で示したデータストリーム分析サービス提供システムでは、マッシュアップＰＣ（Ｐ１）側では、クエリの回答受信方法（利用方法）の種類に応じて処理を切り替える必要がある。具体的には、コネクション型である場合にはデータストリーム分析サーバ（Ｐ２）から最初に受信する回答がそのまま分析結果であるが、ポーリング型である場合には別途データストリーム分析サーバ（Ｐ２）にポーリングして分析結果を受け取る必要がある。この場合、ＡＰＩ利用方法判定手段４が判定するクエリの回答の受信方法（利用方法）は、計算機のリソースの状態等に応じて動的に変化するため、同じクエリであってもポーリングが必要な場合もあれば、継続しているコネクションをそのまま用いて回答される場合もある。そのため、分析ＡＰＩ利用手段１Ａは、クエリを発行する度に、毎回、回答の受信方法（利用方法）をチェックする必要があり、マッシュアップＰＣ（Ｐ１）が行うべき処理が煩雑である。
【０１５５】
以上のように、マッシュアップＰＣ（Ｐ１）が行う処理が複雑であることから、マッシュアップＰＣ（Ｐ１）の設計者がデータストリーム分析サーバ（Ｐ２）の設計者と異なる場合には、そのままではデータストリーム分析サービス提供システムを構築することが難しい。
【０１５６】
これに対して、本実施形態では、分析ＡＰＩ利用手段１Ａは、クエリの発行に関しては、第１の実施形態で示した処理と同様の処理に従ってクエリを発行する。ただし、分析ＡＰＩ利用手段１Ａは、発行したクエリをそのままデータストリーム分析サーバ（Ｐ２）に対して送信するのではなく、まず、データストリーム分析ＡＰＩラッパー７に対してクエリを発行する。そして、マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩラッパー７に従って処理を実行することによって、分析ＡＰＩ利用手段１Ａによって発行されたクエリを、通信ネットワークを介してデータストリーム分析サーバ（Ｐ２）に送信する。
【０１５７】
一方、データストリーム分析サーバ（Ｐ２）から回答を受信する場合には、ＡＰＩ利用方法判定手段４による判定結果がコネクション型である場合であっても、ポーリング型である場合であっても、マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩラッパー７に従って処理を実行することによって、データストリームの分析結果を受信する。そして、分析ＡＰＩ利用手段１は、コネクション型であるかポーリング型であるかにかかわらず、第１の実施形態で示したコネクション型の場合と同様に（ポーリング処理等を行う必要なく）、回答（分析結果）だけをデータストリーム分析ＡＰＩラッパー７から得られる。
【０１５８】
以上のことは、具体的には、マッシュアップＰＣ（Ｐ１）が、データストリーム分析ＡＰＩラッパー７に従って、以下のように処理を実行するためである。
【０１５９】
（１）利用方法がコネクション型である場合：
マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩラッパー７に従って、ポーリング等の処理を何もせず、分析ＡＰＩ利用手段１Ａに対して、データストリーム分析サーバ（Ｐ２）からの回答（分析結果）をそのまま出力する。
【０１６０】
（２）利用方法がポーリング型である場合：
マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩラッパー７に従って、ポーリング処理を実行する。そして、マッシュアップＰＣ（Ｐ１）は、ポーリングに対して回答（分析結果）を得られた（受信した）場合には、そのデータストリーム分析サーバ（Ｐ２）から受信した回答（分析結果）を分析ＡＰＩ利用手段１Ａに回答（出力）する。なお、このことは、データストリーム分析ＡＰＩラッパー７が、分析ＡＰＩ利用手段１Ａを備えるマッシュアップＰＣ（Ｐ１）と同じコンピュータ（ＰＣ）上で動作することから、互いに関数呼び出しでデータをやりとりできるため実現できる。従って、本実施形態では、分析ＡＰＩ利用手段１Ａは、データストリーム分析サーバ（Ｐ２）との間の通信形態を特に意識することなく、データストリームの分析結果を取得することができる。
【０１６１】
一方、データストリーム分析ラッパー７を含まない第１の実施形態で示したデータストリーム分析サービス提供システムでは、分析ＡＰＩ利用手段１は、データストリーム分析ＡＰＩ３を利用するために、データストリーム分析サーバ（Ｐ２）と直接通信を行わなければならない。そのため、通信のコネクションが切断されたり、コネクションに大きな計算機リソースを消費したり、双方向の通信ができないといった制約があり、データストリーム分析サーバ（Ｐ２）との通信形態を意識することなく、データストリームの分析結果の提示を行うことはできない。
【０１６２】
以上のように、本実施形態では、分析ＡＰＩ利用手段１Ａは、データストリーム分析サーバ（Ｐ２）との間の通信形態がコネクション型であるかポーリング型であるかについては意識することなく、データストリームの分析結果を提示することができる。従って、マッシュアップＰＣ（Ｐ１）側の設計者は、エンドユーザに対するサービス提供を実現する機能のみを意識して分析ＡＰＩ利用手段１Ａを設計すればよい。そして、データストリーム分析サーバ（Ｐ２）との間の通信に関しては、データストリーム分析サーバ（Ｐ２）の設計者によって提供されたデータストリーム分析ＡＰＩラッパー７を予めマッシュアップＰＣ（Ｐ１）に搭載するようにすればよく、マッシュアップＰＣ（Ｐ１）とデータストリーム分析サーバ（Ｐ２）との設計者が異なる場合であっても、データストリーム分析サービス提供システムを容易に構築することができる。ポイントは、データストリーム分析ＡＰＩラッパー７と分析ＡＰＩ利用手段１Ａとが同じコンピュータ（ＰＣ）上で動作することである。
【０１６３】
［データストリーム分析ＡＰＩラッパー］
マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩラッパー７に従って処理を実行し、分析ＡＰＩ利用手段１Ａからクエリの入力を受け、入力したクエリを、通信ネットワークを介してデータストリーム分析サーバ（Ｐ２）に送信することによって、コネクション通信手段２を介してデータストリーム分析ＡＰＩ３を呼び出す。また、マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩラッパー７に従って処理を実行することによって、コネクション型である場合には、データストリーム分析サーバ（Ｐ２）からの分析結果を分析ＡＰＩ利用手段１Ａに対してそのまま回答（出力）する。また、マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩラッパー７に従って処理を実行することによって、ポーリング型である場合には、ポーリング処理を行い、ポーリングに対して分析結果が得られれば（ポーリングに対する応答として、データストリーム分析サーバ（Ｐ２）から分析結果を受信すれば）、受信した分析結果を分析ＡＰＩ利用手段１Ａに対して回答（出力）する。
【０１６４】
なお、データストリーム分析ＡＰＩラッパー７は、具体的には、マッシュアップＰＣ（Ｐ１）上で動作させるためのプログラムであって、データストリーム分析サーバ（Ｐ２）側の設計者によって提供されるプログラムである。そのため、分析ＡＰＩ利用手段１Ａは、分析結果の提示機能さえ備えていればよく、第１の実施形態で示した分析ＡＰＩ利用手段１と比較して簡単に実現することができる。
【０１６５】
次に、動作について説明する。本実施形態では、図１６に示した処理のうち、ポーリング情報受信ステップ（ステップＳ１０２）、判定ステップ（ステップＳ１０３）、ポーリングステップ（ステップＳ１０４）、及び回答受信ステップ（ステップＳ１０５）の処理を、分析ＡＰＩ利用手段１に代えて、マッシュアップＰＣ（Ｐ１）がデータストリーム分析ＡＰＩラッパー７に従って実行する点で、第１の実施形態と異なる。
【０１６６】
なお、データストリーム分析サービス提供システムが実行する各ステップ（ステップＳ１〜Ｓ９、ステップＳ１０１〜Ｓ１０６）の具体的な処理内容は、第１の実施の形態と同様である。
【０１６７】
以上に説明したように、本実施形態によれば、マッシュアップＰＣ（Ｐ１）は、データストリーム分析ＡＰＩ３により得られた分析結果のメッセージを解釈して、データストリーム分析ＡＰＩ３による呼び出しを制御するためのデータストリーム分析ＡＰＩラッパー７を搭載する。そのため、データストリーム分析サービスを提供するためのデータストリーム分析ＡＰＩ３を利用するために、ポーリングを行う必要が場合であっても、このポーリング処理をエンドユーザが意識する必要をなくし、より簡単にマッシュアップ的にシステムを構築することができる。
【０１６８】
具体的には、予めデータストリーム分析サーバ（Ｐ２）側の設計者によって提供されたデータストリーム分析ＡＰＩラッパー７をマッシュアップＰＣ（Ｐ１）に搭載すれば、マッシュアップＰＣ（Ｐ１）側の設計者は、データストリームの分析結果の提供機能のみを意識してマッシュアップＰＣ（Ｐ１）を構築すればよい。言い換えれば、マッシュアップＰＣ（Ｐ１）側の設計者は、データストリーム分析サーバ（Ｐ２）との間でコネクション型の通信が行われるかポーリング型の通信が行われるかについては意識する必要がなく、容易にシステム設計を行うことができる。
【０１６９】
実施形態３．
次に、本発明の第３の実施形態について図面を参照して説明する。図１９は、第３の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。図１９に示すように、本実施形態では、データストリーム分析サービス提供システムが、図１７で示した構成要素に加えて、サービス要件定義手段８を含む点で、第２の実施形態と異なる。また、本実施形態では、ＡＰＩ利用方法判定手段４Ｂの機能が、第１の実施形態及び第２の実施形態で示したＡＰＩ利用方法判定手段４の機能と異なる。
【０１７０】
なお、図１９に示す例では、第２の実施形態で示したデータストリーム分析サービス提供システムの構成に加えて、サービス要件定義手段８を備える場合を示しているが、第１の実施形態で示したデータストリーム分析サービス提供システムの構成に加えて、サービス要件定義手段８を備えるように構成してもよい。すなわち、データストリーム分析サービス提供システムがデータストリーム分析ＡＰＩラッパー７を含まないとともに、分析ＡＰＩ利用手段１の機能が第１の実施形態で示した機能と同様のものであってもよい。
【０１７１】
サービス要件定義手段８は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ、及びキーボードやマウス等の入力デバイスによって実現される。サービス要件定義手段８は、マッシュアップＰＣ（Ｐ１）上で動作し、分析ＡＰＩ利用手段１Ａが発行するクエリの応答速度の要件（どの程度のリアルタイム性が要求されるかを示す要件。以下、サービス要件ともいう。）を定義する機能を備える。例えば、サービス要件定義手段８は、マッシュアップＰＣ（Ｐ１）のユーザ等の操作に従って、サービス要件を示す情報（以下、サービス要件定義情報ともいう）を入力し、入力したサービス要件定義情報を分析ＡＰＩ利用手段１Ａに出力する。なお、サービス要件定義手段８が入力したサービス要件定義情報は、分析ＡＰＩ利用手段１Ａ、データストリーム分析ＡＰＩラッパー７、コネクション通信手段２、及びデータストリーム分析ＡＰＩ３を用いて、データストリーム分析サーバ（Ｐ２）に送信され、ＡＰＩ利用方法判定手段４Ｂに出力される。
【０１７２】
ＡＰＩ利用方法判定手段４Ｂは、第１の実施形態及び第２の実施形態で示した処理と同様に、データストリーム分析ＡＰＩ３の利用方法を判定する機能を備える。ただし、本実施形態では、ＡＰＩ利用方法判定手段４Ｂは、第１の実施形態及び第２の実施形態で示した判定条件に加えて、マッシュアップＰＣ（Ｐ１）から受信したサービス要件定義情報に示されるサービス要件も考慮して利用方法を判定する点で、第１の実施形態及び第２の実施形態と異なる。
【０１７３】
次に、データストリーム分析サービス提供システムの物理構成について説明する。図２０は、第３の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。図２０に示すように、本実施形態では、マッシュアップＰＣ（Ｐ１）は、分析ＡＰＩ利用手段１Ａと、データストリーム分析ＡＰＩラッパー７と、サービス要件定義手段８とを含む。図２０に示すように、本実施形態では、サービス要件定義手段８は、マッシュアップＰＣ（Ｐ１）上で動作する。また、データストリーム分析サーバ（Ｐ２）は、コネクション通信手段２と、データストリーム分析ＡＰＩ３と、ＡＰＩ利用方法判定手段４Ｂと、データストリーム分析手段５と、ポーリング分析結果記憶手段６とを含む。
【０１７４】
第１の実施形態及び第２の実施形態の発明では、クエリの回答の受信方法（利用方法）をデータストリーム分析サーバ（Ｐ２）側で一方的に決定し、マッシュアップＰＣ（Ｐ１）の分析ＡＰＩ利用手段１Ａ側から、利用方法について希望を出すことができない。そこで、本実施形態では、マッシュアップＰＣ（Ｐ１）側から、利用方法の決定方法についての希望条件を示したサービス要件定義情報を送信し、マッシュアップＰＣ（Ｐ１）側の希望も考慮して利用方法を決定する。
【０１７５】
例えば、分析ＡＰＩ利用手段１Ａ側から見れば、コマンド毎にリアルタイム性の要望が異なる。例えば、紛失届けが出されているカードの不正使用の検出を指定する紛失検出コマンドを含むクエリを送信する場合、緊急性が高く回答の遅延を少なくしたい。そのような場合に、通信環境や計算機リソースの余裕だけを考慮してポーリング型を選択してしまったのでは、マッシュアップＰＣ（Ｐ１）側のユーザのニーズに十分に応えることはできない。一方、利用回数が多いことを警告するための頻度異常コマンドを含むクエリを送信する場合には、緊急性が低く、回答の遅延がある程度許されることが多い。
【０１７６】
ここで、回答の遅延は、ＡＰＩ利用方法判定手段４Ｂによって判定される回答取得方法に大きく依存する。すなわち、利用方法としてコネクション型が選択された場合には遅延が少ないが、ポーリング型が選択された場合には遅延が大きくなってしまう。従って、上記に示した例では、紛失検出コマンドを含むクエリを送信する場合にはコネクション型を選択することが好ましく、頻度異常コマンドを含むクエリを送信する場合にはポーリング型を選択すればよい。
【０１７７】
第１の実施形態及び第２の実施形態で示したデータストリーム分析サービス提供システムでは、分析ＡＰＩ利用手段１Ａ側の都合ではなく、データストリーム分析サーバ（Ｐ２）側の都合だけで、利用方法を決定している。そこで、本実施形態では、利用方法の選択方法について、分析をＡＰＩ利用手段１Ａ側で指定できるようにシステムの機能を拡張する。
【０１７８】
［サービス要件定義手段］
図２１は、サービス要件定義情報の例を示す説明図である。サービス要件定義手段８は、図２１に示すようなテーブル形式のサービス要件定義情報を、ユーザの操作に従って入力し、予め設定しておく。図２１に示すように、サービス要件定義手段８が入力するサービス要件定義情報は、コマンド（Ｔ８０１）及び遅延許可（Ｔ８０２）を含む。コマンド（Ｔ８０１は、クエリのコマンドに対応する。また、遅延許可（Ｔ８０２）は、コマンドに対する回答（分析結果）を得るまでの遅延時間として許可できる時間である。
【０１７９】
［分析ＡＰＩ利用手段］
図２２は、第３の実施形態における分析ＡＰＩ利用手段１Ａが発行するクエリに含まれる項目例を示す説明図である。図２２に示すように、本実施形態では、分析ＡＰＩ利用手段１Ａは、図４で示したクエリに、さらに遅延許可を表す遅延許可フィールド（Ｔ１０３）を追加したクエリを生成する。
【０１８０】
本実施形態では、遅延許可（Ｔ１０３）は、分析対象のクレジットカード利用ログデータを分析した結果として発生した警告を、どの程度マッシュアップＰＣ（Ｐ１）に遅れて通知されても許されるかを設定するためのフィールドである。図２２に示す例では、遅延許可フィールド（Ｔ１０３）に許容される遅延時間の値が設定されており、例１では１分以内を遅延最大時間に設定し、例２では１時間以内を遅延最大時間に設定する場合が示されている。
【０１８１】
図２３は、第３の実施形態における要求クエリの例を示す説明図である。図２３に示すように、分析ＡＰＩ利用手段１Ａは、クエリのパラメータとして、「ＤＥＬＡＹ=」で遅延許可フィールド（Ｔ１０３）指定したクエリを発行する。この場合、分析ＡＰＩ利用手段１Ａは、クエリを生成する際に、サービス要件定義手段８が設定したサービス要件定義情報を検索して、遅延許可の値をクエリにセットする。
【０１８２】
［回答方法決定手段］
ＡＰＩ利用方法判定手段４Ｂの回答方法決定手段４０１は、判定ルールとして、第１の実施形態及び第２の実施形態で示した判定ルールに加えて、ルール２による判定とルール３による判定との間に用いられる以下のルール２．５を追加して用いる。
【０１８３】
ルール２．５：回答方法決定手段４０１は、マッシュアップＰＣ（Ｐ１）から受信したクエリに含まれる遅延許可の値に基づいて、例えば、指定された遅延許可の値が「１分以内」である場合には、緊急性が高いと判定して、回答方法としてコネクション型を用いることに決定する。また、回答方法決定手段４０１は、例えば、指定された遅延許可の値が１分より大きい場合には、緊急性がそれ程高くないと判定して、ルール３以降のルールを用いた判定を行うと判定する。
【０１８４】
次に、動作について説明する。図２４は、第３の実施形態におけるデータストリーム分析サービス提供システムを用いて、プッシュ型サービスを提供する処理の一例を示すフローチャートである。図２４に示すように、本実施形態では、図１６で示した処理ステップに加えて、分析ＡＰＩ利用手段１Ａで発行するクエリの応答速度の要件（サービス要件）を設定するサービス要件定義ステップ（ステップＳ１０７）を含む点で、第の実施形態及び第２の実施形態と異なる。
【０１８５】
［サービス要件定義ステップ］
サービス要件定義ステップ（ステップＳ１０７）では、サービス要件定義手段８は、ユーザ操作に従って、サービス要件定義情報を入力し設定する。そして、分析ＡＰＩ利用手段１Ａは、ステップＳ１０１において、ステップＳ１０７で設定され記憶している要件（サービス要件定義情報）を参照して、クエリを発行すればよい。
【０１８６】
また、データストリーム分析サーバ（Ｐ２）は、ステップＳ１でクエリを受信した後、ステップＳ２では、受信したクエリに含まれるサービス要件の情報（例えば、許容される遅延時間の値）も考慮して、分析結果の回答方法（利用方法）を決定する。
【０１８７】
なお、データストリーム分析サーバ（Ｐ２）が実行するステップＳ３以降の処理や、マッシュアップＰＣ（Ｐ１）が実行するステップＳ１０２以降の処理は、第１の実施形態及び第２の実施形態で示したそれらの処理と同様である。
【０１８８】
以上に説明したように、本実施形態によれば、クライアント端末（マッシュアップＰＣ（Ｐ１））側に、分析ＡＰＩ利用手段１Ａが発行するクエリに対する回答の応答速度の要件を定義するためのサービス要件定義手段８を備える。そして、データストリーム分析サーバ（Ｐ２）は、クエリに含まれるサービス要件（例えば、許容される遅延時間の値）も考慮して、分析結果の回答方法（利用方法）を決定する。そのため、データストリーム分析サービスを提供するためのＡＰＩ毎に、マッシュアップＰＣ（Ｐ１）側の遅延の許容範囲も考慮して、マッシュアップ的に簡単にシステムを構築することができる。
【０１８９】
実施形態４．
次に、本発明の第４の実施形態について図面を参照して説明する。図２５は、第４の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。図２５に示すように、本実施形態では、データストリーム分析サービス提供システムが、図２に示した構成要素に加えて、ユーザＩＤ管理手段９を含む点で、第１の実施形態と異なる。
【０１９０】
なお、図２５に示す例では、第１の実施形態で示したデータストリーム分析サービス提供システムに、ユーザＩＤ管理手段９をさらに加えてシステムを構成する場合を示しているが、第２の実施形態や第３の実施形態で示したデータストリーム分析サービス提供システムに、ユーザＩＤ管理手段９をさらに加えて構成してもよい。例えば、本実施形態において、データストリーム分析サービス提供システムは、第２の実施形態で示したデータストリーム分析ＡＰＩラッパー７や、第３の実施形態で示したサービス要件定義手段８を備えていてもよい。
【０１９１】
ユーザＩＤ管理手段９は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ、及び磁気ディスク装置や光ディスク装置等の記憶装置によって実現される。本実施形態では、分析ＡＰＩ利用方法判定手段１側のユーザを、データストリーム分析ＡＰＩ３を有料で利用する有料サービスユーザと、無料で利用する無料サービスユーザに分ける。ユーザＩＤ管理手段９は、分析ＡＰＩ利用手段１を用いるユーザが、有料サービスユーザであるか無料サービスユーザであるかを記憶し管理する機能を備える。また、ユーザＩＤ管理手段９は、マッシュアップＰＣ（Ｐ１）のユーザに対して、ユーザを識別するためのユーザＩＤを発行する機能を備える。
【０１９２】
なお、本実施形態では、有料サービスユーザと無料サービスユーザとの両方に対してユーザＩＤを発行する場合を示しているが、ユーザＩＤ管理手段９は、少なくとも、有料サービスユーザに対してユーザＩＤを発行するようにすればよい。そのようにしても、ユーザＩＤ管理手段９は、クエリ中にユーザＩＤが含まれるか否かを判定することによって、有料サービスユーザであるか否かを判定することができる。
【０１９３】
また、本実施形態では、ＡＰＩ利用方法判定手段４Ｃの回答方法決定手段４０１は、有料サービスユーザであるか無料サービスユーザを区別して判定するための判定ルールも用いて、分析結果の回答方法（利用方法）を決定する点で、第１の実施形態〜第３の実施形態と異なる。
【０１９４】
次に、データストリーム分析サービス提供システムの物理構成について説明する。図２６は、第４の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。図２６に示すように、本実施形態では、データストリーム分析サーバ（Ｐ２）は、第１の実施形態〜第３の実施形態で示した構成要素に加えて、ユーザＩＤ管理手段９を含む。図２６に示すように、本実施形態では、ユーザＩＤ管理手段９は、データストリーム分析サーバ（Ｐ２）上で動作する。なお、マッシュアップＰＣ（Ｐ１）の物理構成については、第１の実施形態〜第３の実施形態で示した構成と同様である。
【０１９５】
本実施形態では、データストリーム分析ＡＰＩ３の利用サービスのビジネスモデルを提案する。本実施形態では、データストリーム分析ＡＰＩ３の利用サービスを提供する際に、ユーザを有料サービスユーザと無料サービスユーザとに分け、有料サービスユーザを優遇する仕組みを導入することを提案する。よって、本実施形態では、有料サービスユーザが受けるメリットの１つとして、より遅延なく分析結果をユーザに提供できるという利益を受けることができる。具体的には、本実施形態では、有料サービスユーザに対しては、できるだけコネクション型で分析結果を回答するようにし、無料サービスユーザに対しては、ポーリング型が選択される割合が高くなるようにしている。
【０１９６】
［ユーザＩＤ管理手段］
図２７は、ユーザＩＤ管理手段９が記憶するユーザが有料サービスユーザであるか無料サービスユーザであるかを示すテーブルの例を示す説明図である。図２７に示すように、ユーザＩＤ管理手段９は、以下に示すＵＩＤフィールド（Ｔ９０１）とＵｓｅｒＴｙｐｅフィールド（Ｔ９０２）とを含むテーブルを記憶する。言い換えれば、ユーザＩＤ管理手段９は、有料サービスユーザであるか無料サービスユーザであるかを示すＵｓｅｒＴｙｐｅを、ユーザ（ユーザＩＤ）に対応付けて記憶する。ＵＩＤ（Ｔ９０１）は、ユーザを識別するためのＩＤである。また、ＵｓｅｒＴｙｐｅ（Ｔ９０２）は、有料サービスユーザであるか無料サービスユーザであるかを示す情報である。なお、図２７に示すテーブルのフィールド構成は一例であり、各ユーザが有料サービスユーザであるか否かを特定可能であれば、ユーザＩＤ管理手段９は、どのような形式の情報を記憶してもよい。
【０１９７】
本実施形態では、マッシュアップＰＣ（Ｐ１）の各ユーザは、データストリーム分析ＡＰＩ３を利用する前に、予めユーザ登録等を行ってＵＩＤ（ユーザＩＤ）を発行してもらう。この際、ユーザがサービス料金を支払えば、データストリーム分析サーバ（Ｐ２）側では、そのユーザを有料サービスユーザとして登録し、支払わなければ無料サービスユーザとして登録するものとする。なお、本例では、各ユーザを有料／無料の２段階に分ける場合について示しているが、一例であり、有料サービスユーザをさらに金額で応じて複数段階に分けても構わない。
【０１９８】
［回答方法決定手段］
ＡＰＩ利用方法判定手段４Ｃの回答方法決定手段４０１は、判定ルールとして、第１の実施形態〜第３の実施形態で示した判定ルールに加えて、ユーザが有料サービスユーザであるか無料サービスユーザであるかを区別するための以下のルール１．５を追加して用いる。なお、本実施形態では、回答方法決定手段４０１は、マッシュアップＰＣ（Ｐ１）から受信したクエリに含まれるＵＩＤ（ユーザ）に基づいて、そのＵＩＤに対応するＵｓｅｒＴｙｐｅを図２７に示すテーブルから抽出することによって、有料サービスユーザであるか無料サービスユーザであるかを特定する。
【０１９９】
ルール１．５：回答方法決定手段４０１は、もしクエリに含まれるＵＩＤに基づいて無料サービスユーザであると判定した場合には、回答方法としてポーリング型を用いることに決定する。また、回答方法決定手段４０１は、もしクエリに含まれるＵＩＤに基づいて有料サービスユーザであると判定した場合には、ルール２以降のルールを用いた判定を行うと判定する。
【０２００】
ルール１．５は、ルール１を用いた判定の後に適用されるルールである。このルールを用いて行われる判定の意味は、無料サービスユーザであれば無条件に遅延がおおきいポーリング型を選択し、有料サービスユーザであれば、その他の条件を用いてコネクション型とするかポーリング型とするかが判定されるということである。ただし、上記に示した判定ルールは一例であり、ＵｓｅｒＴｙｐｅに応じて他の判定方法を行ってもよい。例えば、逆に、有料サービスユーザであれば無条件にコネクション型を選択するようにしてもよく、無料サービスユーザであっても、通信環境や計算機リソースに余裕があれば、コネクション型が選択されるようにしてもよい。また、例えば、ユーザの支払い金額に応じて細分化したルール等を作って判定を行っても構わない。
【０２０１】
また、本実施形態では、ユーザを有料サービスユーザと無料サービスユーザとに分ける場合を示したが、ユーザタイプの分け方は、本実施形態で示したものに限られない。例えば、ユーザが用いている回線が高速回線であるか否かでタイプ分けするようにしてもよく、この場合、回答方法決定手段４０１は、ＵＩＤに基づいてユーザの使用回線が高速回線であるか否かを判定するようにしてもよい。そして、高速回線でなければ無条件にポーリング型と判定するようにしてもよく、逆に高速回線であれば無条件にコネクション型と判定するようにしてもよい。
【０２０２】
次に、動作について説明する。図２８は、第４の実施形態におけるデータストリーム分析サービス提供システムを用いて、プッシュ型サービスを提供する処理の一例を示すフローチャートである。図２８に示すように、本実施形態では、図１６で示した処理ステップに加えて、クエリ受信ステップ（ステッＳ１）と回答方法判定ステップステップ（Ｓ２）との間に、ユーザが有料サービスユーザであるのか無料サービスユーザであるのかを記憶するユーザＩＤ管理ステップ（ステップＳ１０）を含む点で、第１の実施形態〜第３の実施形態と異なる。
【０２０３】
ユーザＩＤ管理ステップ（ステップＳ１０）では、ユーザＩＤ管理手段９は、マッシュアップＰＣ（Ｐ１）から受信したＵＩＤに基づいて、図２７に示したテーブルを検索し、有料サービスユーザであるか無料サービスユーザであるかを特定する。また、ステップＳ２の回答方法判定ステップでは、ＡＰＩ利用方法判定手段４Ｃは、ユーザＩＤ管理手段９による有料サービスユーザであるか無料サービスユーザであるかの特定結果も考慮して、分析結果の回答方法（利用方法）を選択する。
【０２０４】
以上に説明したように、本実施形態によれば、データストリーム分析サーバ（Ｐ２）側で、有料サービスユーザに対してユーザＩＤを発行するユーザＩＤ管理手段９を備える。そして、マッシュアップＰＣ（Ｐ１）側では、分析ＡＰＩ利用手段１が利用するために、発行されたユーザＩＤを有料サービスユーザ側で記憶する。そのため、大規模データストリームをリアルタイムに分析するアプリケーションをマッシュアップ的に簡単に構築するサービスＡＰＩを有料サービスとして提供することができる。
【０２０５】
実施形態５．
次に、本発明の第５の実施形態について図面を参照して説明する。図２９は、第５の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。図２９に示すように、本実施形態では、データストリーム分析サービス提供システムが、図２に示した構成要素に加えて、リソース利用チケット管理手段１０及びリソース利用チケットチェック手段１１を含む点で、第１の実施形態と異なる。
【０２０６】
なお、図２９に示す例では、第１の実施形態で示したデータストリーム分析サービス提供システムに、リソース利用チケット管理手段１０及びリソース利用チケットチェック手段１１をさらに加えてシステムを構成する場合を示しているが、第２の実施形態や第３の実施形態で示したデータストリーム分析サービス提供システムに、リソース利用チケット管理手段１０及びリソース利用チケットチェック手段１１をさらに加えて構成してもよい。例えば、本実施形態において、データストリーム分析サービス提供システムは、第２の実施形態で示したデータストリーム分析ＡＰＩラッパー７や、第３の実施形態で示したサービス要件定義手段８を備えていてもよい。
【０２０７】
リソース利用チケット管理手段１０は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ、及び磁気ディスク装置や光ディスク装置等の記憶装置によって実現される。本実施形態では、データストリーム分析ＡＰＩ３を利用するための料金が予め設定されている。リソース利用チケット管理手段１０は、このデータストリーム分析ＡＰＩ３の利用料金を支払うために事前に購入したチケット（電子チケット）を記憶し管理する機能を備える。
【０２０８】
リソース利用チケットチェック手段１１は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ、及び磁気ディスク装置や光ディスク装置等の記憶装置によって実現される。リソース利用チケットチェック手段１１は、ＡＰＩ利用方法判定手段４Ｄの回答方法決定手段４０１がＡＰＩ利用方法を判定する際に、ユーザがチケットを購入しているか否かをチェック（判定）する機能を備える。本実施形態では、分析ＡＰＩ利用手段１は、データストリーム分析ＡＰＩ３の利用時に、クエリにチケットを添付して送信する。そして、リソース利用チケットチェック手段１１は、受信したクエリにチケットが含まれるか否かを判定することによって、ユーザがチケットを購入しているか否かを判定する。
【０２０９】
次に、データストリーム分析サービス提供システムの物理構成について説明する。図３０は、第５の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。図３０に示すように、本実施形態では、マッシュアップＰＣ（Ｐ１）は、第１の実施形態〜第３の実施形態で示した構成要素に加えて、リソース利用チケット管理手段１０を含む。また、データストリーム分析サーバ（Ｐ２）は、第１の実施形態〜第３の実施形態で示した構成要素に加えて、リソース利用チケットチェック手段１１を含む。図３０に示すように、本実施形態では、リソース利用チケット管理手段１０は、マッシュアップＰＣ（Ｐ１）上で動作する。また、リソース利用チケットチェック手段１１は、データストリーム分析サーバ（Ｐ２）上で動作する。
【０２１０】
本実施形態では、第４の実施形態と同様に、データストリーム分析ＡＰＩ３の利用サービスのビジネスモデル特許を提案する。第４の実施形態で示したデータストリーム分析サービス提供システムのビジネスモデルでは、有料か無料かはユーザ毎に区別されていたため、クエリ毎にサービス品質を指定することはできない。そこで、本実施形態では、あるクエリについては、料金を支払うことによって遅延の少ないサービスを受けることができるようにし、また別のクエリについては、遅延を許容する代わりに無料で利用することを可能とするといった利用方法を実現することを提案する。
【０２１１】
［リソース利用チケット管理手段］
図３１は、リソース利用チケット管理手段１０が管理するチケットの例を示す説明図である。リソース利用チケット管理手段１０は、予めチケットを購入し、その購入したチケットのＩＤを、図３１に示すようにテーブル形式で登録する。図３１において、チケットＩＤ（Ｔ１００１）は、購入したチケットを識別するためのＩＤである。なお、本実施形態では、例えば、複数（５ライセンス）のチケットを購入すると、それぞれ別々の５つのチケットＩＤが発行されるものとする。
【０２１２】
［分析ＡＰＩ利用手段］
図３２は、第５の実施形態における要求クエリの例を示す説明図である。図３２に示すように、分析ＡＰＩ利用手段１は、有料でデータストリーム分析ＡＰＩ３を利用する場合に、以下のチケットフィールド（Ｔ１１０）フィールドを追加して含むクエリを発行する。図３２において、チケット（Ｔ１１０）は、チケットを識別するためのＩＤである。本実施形態では、分析ＡＰＩ利用手段１は、クエリのパラメータとして、「ＴＩＣＫＥＴ=」でチケットフィールドを指定したクエリを発行する。
【０２１３】
分析ＡＰＩ利用手段１は、クエリを生成する際に、リソース利用チケット管理手段１０に登録されているチケットＩＤを読み込み、読み込んだチケットＩＤを含むクエリを生成する。なお、分析ＡＰＩ利用手段１は、クエリを生成すると、クエリの生成に用いたチケットＩＤを、リソース利用チケット管理手段１０に削除させる。
【０２１４】
［リソース利用チケットチェック手段］
リソース利用チケットチェック手段１１は、予め発行済みのチケットＩＤを記憶しておき、マッシュアップＰＣ（Ｐ１）からクエリを受信したときに、受信したクエリに含まれるチケット（具体的には、チケットＩＤ）が有効であるか否かをチェック（判定）する手段である。
【０２１５】
図３３は、リソース利用チケットチェック手段１１が記憶するテーブルのフィールドの例を示す説明図である。図３３に示すように、リソース利用チケットチェック手段１１は、ユーザＩＤ（Ｔ１１０１）と、チケット（Ｔ１１０２）とを対応付けて含むテーブルを記憶する。ユーザＩＤ（Ｔ１１０１）は、チケットを発行した先のユーザを識別するためのユーザＩＤである。また、チケット（Ｔ１１０２）は、チケットを識別するためのＩＤである。
【０２１６】
リソース利用チケットチェック手段１１は、ＡＰＩ利用方法判定手段４Ｄの回答方法決定手段４０１からクエリのＵＩＤとＴＩＣＫＥＴの値とを受け取り（入力する）。そして、リソース利用チケットチェック手段１１は、図３３に示すテーブルのユーザＩＤフィールド（Ｔ１１０１）及びチケットフィールド（Ｔ１１０２）にそれぞれ合致するものがあるか否かを、入力したＵＩＤ及びＴＩＣＫＥＴの値を用いて検索する。もし合致するユーザＩＤ及びチケットＩＤがあれば、リソース利用チケットチェック手段１１は、チケットを有効に購入済みのユーザであると判定して、回答方法決定手段４０１に対して、ＯＫである旨の判定結果を返答（出力）する。もし合致するユーザＩＤ及びチケットＩＤがなければ、リソース利用チケットチェック手段１１は、チケットを購入していないユーザであると判定して、回答方法決定手段４０１に対して、ＮＧである旨の判定結果を返答（出力）する。
【０２１７】
［回答方法決定手段］
ＡＰＩ利用方法判定手段４Ｄの回答方法決定手段４０１は、判定ルールとして、第１の実施形態及び第３の実施形態で示した判定ルールに加えて、ルール１による判定の後に、以下のルール１．２を追加して用いる。
【０２１８】
ルール１．２：回答方法決定手段４０１は、マッシュアップＰＣ（Ｐ１）から受信したクエリに含まれるチケットの値に関して、値が正しいチケットＩＤである場合（リソース利用チケットチェック手段１１によって、チケットを有効に購入済みのユーザであると判定された場合）には、コネクション型を用いることに決定する。また、回答方法決定手段４０１は、リソース利用チケットチェック手段１１によってチケットを購入していないユーザであると判定された場合には、ルール２以降のルールを用いた判定を行うと判定する。
【０２１９】
このルール１．２を用いて行われる判定の意味は、チケットのＩＤが指定されており、正しいチケットであればコネクション型を選択して利用するということである。一方、チケットが指定されていない場合や、正しくないチケット（例えば、リソース利用チケットチェック手段１１が管理するユーザＩＤとチケットＩＤとが一致しない場合。例えば、第三者によってチケットを不正取得された可能性がある。）であれば、ルール２以降のルールを用いた判定が行われることになる。
【０２２０】
回答方法決定手段４は、このルール１．２を用いた判定を行う際に、リソース利用チケットチェック手段１１に対して、受信したクエリに含まれるチケットのチェックを依頼する。もし、チケットが正しいと判定した場合には、チケットを利用したと判定として、リソース利用チケットチェック手段１１は、当該チケットを図３３に示すテーブルから削除する。
【０２２１】
次に、動作について説明する。図３４は、第５の実施形態におけるデータストリーム分析サービス提供システムを用いて、プッシュ型サービスを提供する処理の一例を示すフローチャートである。図３４に示すように、本実施形態では、図１６で示した処理ステップに加えて、分析ＡＰＩ利用手段１が発行するクエリにチケットを追加するチケット添付ステップ（ステップＳ１０８）を、クエリ発行ステップ（ステップＳ１０１）の前に含む点で、第１の実施形態〜第３の実施形態と異なる。また、本実施形態では、回答方法判定ステップ（ステップＳ２）において、クエリにチケットが添付されていた場合に、このチケットの有効性をチェック（判定）する。
【０２２２】
［クエリ発行ステップ］
チケット添付ステップ（ステップＳ１０８）では、分析ＡＰＩ利用手段１は、リソース利用チケット管理手段１０が記憶しているチケットを、クエリを発行する際に参照し、チケットをクエリに添付する。そして、クエリ発行ステップ（ステップＳ１０１）では、分析ＡＰＩ利用手段１は、チケットを添付したクエリを発行して、通信ネットワークを介してデータストリーム分析サーバ（Ｐ２）に送信する。
【０２２３】
［回答方法判定ステップ］
回答方法判定ステップ（ステップＳ２）では、ＡＰＩ利用方法判定手段４Ｄの回答方法決定手段４０１は、受信したクエリにチケットＩＤが含まれていれば、リソース利用チケットチェック手段１１に対して、クエリに含まれるユーザＩＤ及びチケットＩＤを出力して、チケットを有効に購入したユーザであるか否かの判定を依頼する。そして、回答方法決定手段４０１は、リソース利用チケットチェック手段１１による判定結果も考慮して、分析結果の回答方法（利用方法）を選択する。
【０２２４】
以上に説明したように、本実施形態によれば、データストリーム分析ＡＰＩ３を利用する料金を設定し、マッシュアップＰＣ（Ｐ１）は、この料金を支払うために事前に購入したチケットを記憶するリソース利用チケット管理手段１０を備える。また、データストリーム分析サーバ（Ｐ２）は、回答方法決定手段４０１がＡＰＩ利用方法を判定するために、チケットの購入の有無をチェックするリソース利用チケットチェック手段１１を備える。そのため、大規模データストリームをリアルタイムに分析するアプリケーションをマッシュアップ的に簡単に構築するサービスＡＰＩを、利用するＡＰＩ毎に価格を設定した有料サービスとして提供することができる。
【０２２５】
なお、本実施形態では、予めマッシュアップＰＣ（Ｐ１）に対してチケットを発行することによって、データストリーム分析ＡＰＩ３の利用料金の支払いを行う場合を示したが、マッシュアップＰＣ（Ｐ１）は、例えば、電子マネーを用いて、データストリーム分析ＡＰＩ３の利用料金を支払うようにしてもよい。この場合、例えば、マッシュアップＰＣ（Ｐ１）は、電子チケットに代えて電子マネーの情報を含むクエリを送信するようにすればよい。また、データストリーム分析サーバ（Ｐ２）のリソース利用チケットチェック手段１１は、電子マネーの残高を示す情報をユーザ毎に記憶して管理し、利用料金に応じた残高の有無を判定するようにすればよい。
【０２２６】
実施形態６．
次に、本発明の第６の実施形態について図面を参照して説明する。図３５は、第６の実施形態におけるプッシュ型サービス実現方法を用いたデータストリーム分析サービス提供システムの構成例を示すブロック図である。図３５に示すように、本実施形態では、データストリーム分析サービス提供システムが、図２９に示した構成要素に加えて、ＡＰＩ利用価格管理手段１２を含む点で、第５の実施形態と異なる。
【０２２７】
なお、図３５に示す例では、第５の実施形態で示したデータストリーム分析サービス提供システムに、ＡＰＩ利用価格管理手段１２をさらに加えてシステムを構成する場合を示しているが、第４の実施形態で示したデータストリーム分析サービス提供システムに、ＡＰＩ利用価格管理手段１２をさらに加えて構成してもよい。例えば、本実施形態において、データストリーム分析サービス提供システムは、第５の実施形態で示したリソース利用チケット管理手段１０やリソース利用チケットチェック手段１１に代えて、ユーザＩＤ管理手段９を備えていてもよい。
【０２２８】
ＡＰＩ利用価格管理手段１２は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵ、及び磁気ディスク装置や光ディスク装置等の記憶装置によって実現される。ＡＰＩ利用価格管理手段１２は、データストリーム分析ＡＰＩ３を利用するための利用料金をコマンド毎に設定し管理する機能を備える。本実施形態では、ＡＰＩ利用価格管理手段１２は、リソース利用チケットチェック手段１１がチケット購入の有無をチェックする際に、クエリで指定されたコマンドに対するデータストリーム分析ＡＰＩ３の利用価格もチェック（判定）する。
【０２２９】
次に、データストリーム分析サービス提供システムの物理構成について説明する。図３６は、第６の実施形態におけるデータストリーム分析サービス提供システムの典型的な物理構成例を示すブロック図である。図３６に示すように、本実施形態では、データストリーム分析サーバ（Ｐ２）は、第４の実施形態や第５の実施形態で示した構成要素に加えて、ＡＰＩ利用価格管理手段１２を含む。図３６に示すように、本実施形態では、ＡＰＩ利用価格管理手段１２は、データストリーム分析サーバ（Ｐ２）上で動作する。
【０２３０】
本実施形態では、第４の実施形態や第５の実施形態と同様に、データストリーム分析ＡＰＩ３の利用サービスのビジネスモデル特許を提案する。第４の実施形態や第５の実施形態で示したデータストリーム分析サービス提供システムのビジネスモデルでは、どのクエリに対しても利用価格が同じ価格であることを前提としている。しかし、クエリで指定されたコマンドによる分析処理を実行する場合、計算機リソースを多く利用するコマンドもあれば、そうではないコマンドもあり、コマンド毎にデータストリーム分析ＡＰＩ３の利用料金の価格を変えたいことがある。本実施形態では、そのような場合に、クエリで指定されたコマンド毎に異なる利用料金の設定を実現することを提案する。
【０２３１】
本実施形態では、チケット１つが最小限の価格（データストリーム分析ＡＰＩ３を利用するための単位価格）を表しているものとする。そして、各コマンドに対する利用価格は、このチケットの定数倍の値を指定することによって表すことができるものとする。つまり、分析ＡＰＩ利用手段１は、データストリーム分析ＡＰＩ３を利用する際には、利用する価格分のチケットを添付してクエリを発行する。
【０２３２】
［分析ＡＰＩ利用手段］
分析ＡＰＩ利用手段１は、チケットを複数添付してクエリを発行できるようにする。図３７は、第６の実施形態における要求クエリの例を示す説明図である。図３７に示す例では、分析ＡＰＩ利用手段１が、複数のチケットＩＤをリスト形式で含むクエリを発行する場合が示されている。さらに、分析ＡＰＩ利用手段１は、クエリを生成する際に、複数のチケットを添付した場合には、添付したチケット全てのチケットＩＤを、リソース利用チケット管理手段１０に削除させる。
【０２３３】
［ＡＰＩ利用価格管理手段］
ＡＰＩ利用価格管理手段１２は、コマンド毎のデータストリーム分析ＡＰＩ３の利用価格を記憶し管理する手段である。なお、ＡＰＩ利用価格管理手段１２は、コマンド毎の利用価格を予め設定して記憶装置に記憶しておいてもよいし、消費リソースを監視し、コマンド毎の利用価格を、消費リソースの余裕度合いに応じて自動設定（動的に変化させて設定）してもよい。
【０２３４】
図３８は、ＡＰＩ利用価格管理手段１２が記憶するテーブルの例を示す説明図である。図３８に示すように、ＡＰＩ利用価格管理手段１２は、以下のコマンドフィールド（Ｔ１２０１）と価格フィールド（Ｔ１２０２）とを対応付けて含むテーブルを記憶し管理する。図３８において、コマンド（Ｔ１２０１）は、クエリに含まれうるコマンドである。また、価格（Ｔ１２０２）は、そのコマンドに対してデータストリーム分析ＡＰＩ３を利用する際に必要なチケットの数である。
【０２３５】
［リソース利用チケットチェック手段］
リソース利用チケットチェック手段１１は、予め発行済みにチケットＩＤを記憶しておき、マッシュアップＰＣ（Ｐ１）からクエリを受信したときに、受信したクエリに含まれるチケット（具体的には、チケットＩＤ）が有効であるか否かをチェック（判定）する。また、リソース利用チケットチェック手段１１は、その機能に加えて、受信したクエリに含まれるコマンドに対する利用価格とチケット数とをチェックする。具体的には、リソース利用チケットチェック手段１１は、クエリに含まれるコマンドに対応するチケット数を、ＡＰＩ利用価格管理手段１２が管理する図３８に示すテーブルから抽出する。そして、リソース利用チケットチェック手段１１は、クエリに含まれるチケット数が、抽出したチケット数に合致するか否かを判定する。従って、本実施形態では、リソース利用チケットチェック手段１１は、回答方法決定手段４０１からクエリに含まれるＵＩＤとＴＩＣＫＥＴとの値に加え、コマンド名を受け取り（入力し）、図３８に示すテーブルを検索する。
【０２３６】
もし、ある合致するユーザＩＤ及びチケットＩＤがなければ、リソース利用チケットチェック手段１１は、回答方法決定手段４０１に対して、ＮＧである旨の判定結果を返答（出力）する。もし全てのユーザＩＤ及びチケットＩＤが合致すれば、リソース利用チケットチェック手段１１は、ＡＰＩ利用価格管理手段１２に対して、クエリに含まれるコマンド名をキーに、価格（必要なチケットの枚数）の検索を依頼する。そして、ＡＰＩ利用価格管理手段１２が検索した価格と、クエリに含まれるチケット数とが同じであれば、リソース利用チケットチェック手段１１は、回答方法決定手段４０１に対して、ＯＫである旨の判定結果を返答（出力）する。ＡＰＩ利用価格管理手段１２が検索した価格と、クエリに含まれるチケット数とが同じでなければ、リソース利用チケットチェック手段１１は、回答方法決定手段４０１に対して、ＮＧである旨の判定結果を返答（出力）する。
【０２３７】
次に、動作について説明する。本実施形態では、図３４に示した処理のうち、回答方法判定ステップ（ステップＳ２）において、リソース利用チケットチェック手段１１は、クエリにチケットが添付されていた場合に、このチケットの有効性とコマンドの価格通りのチケットが添付されているか否かをチェック（判定）する。そして、回答方法決定手段４０１は、リソース利用チケットチェック手段１１に判定結果に基づいて、必要数のチケットが添付されているか否かも考量して、分析結果の回答方法（利用方法）を選択する。
【０２３８】
以上に説明したように、本実施形態によれば、データストリーム分析ＡＰＩ３を利用するための利用料金を現在のリソース利用状況から動的に決定するためのＡＰＩ利用価格管理手段１２を備える。そのため、大規模データストリームをリアルタイムに分析するアプリケーションをマッシュアップ的に簡単に構築するサービスＡＰＩを、利用する計算機リソースの消費度合いに応じて価格を設定して利用可能とした有料サービスとして提供することができる。
【０２３９】
次に、本発明によるプッシュ型サービス実現システムの最小構成について説明する。図３９は、プッシュ型サービス実現システムの最小の構成例を示すブロック図である。図３９示すように、プッシュ型サービス実現システムは、最小の構成要素として、データストリーム分析手段５、データストリーム分析ＡＰＩ３、及びＡＰＩ利用方法判定手段４を含む。
【０２４０】
図３９に示す最小構成のプッシュ型サービス実現システムにおいて、データストリーム分析手段５は、データを分析する機能を備える。また、データストリーム分析ＡＰＩ３は、データストリーム分析手段５の分析結果を取得するためのＡＰＩである。また、ＡＰＩ利用方法判定手段４は、リソースの状況に応じて、データストリーム分析ＡＰＩ３を用いた分析結果の配信方法を決定する機能を備える。
【０２４１】
図３９に示す最小構成のプッシュ型サービス実現システムによれば、ＡＰＩを組み合わせてマッシュアップ的に簡単にシステムを構築する場合において、ＰＵＳＨ型のサービスを提供することができる。
【０２４２】
なお、上記に示した各実施形態では、以下の（１）〜（５２）に示すようなプッシュ型サービス実現方法、プッシュ型サービス実現システム、プッシュ型サービス実現装置、及びプッシュ型サービス実現用プログラムの特徴的構成が示されている。
【０２４３】
（１）プッシュ型サービス実現方法は、データを分析し、データの分析結果を取得するためのＡＰＩを用い、リソースの状況に応じて、ＡＰＩを用いた分析結果の配信方法を決定することを特徴とする。
【０２４４】
（２）プッシュ型サービス実現方法は、少なくとも、ネットワークの状況、又はデータを分析する計算機が動作する計算機リソースの状況に応じて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２４５】
（３）プッシュ型サービス実現方法は、分析結果の配信を要求する分析クエリを記憶させるためのＡＰＩと、分析クエリに対する分析結果を配信するためのＡＰＩとが、異なるネットワークセッションを用いて実行され、分析クエリに対する分析結果を配信するためのＡＰＩを、所定期間毎にポーリングするポーリング型の配信方法と、分析クエリを記憶させる際に用いたネットワークセッションを維持して、該ネットワークセッションをそのまま用いて分析結果を配信するコネクション型の配信方法とのいずれかに決定するように構成されていてもよい。
【０２４６】
（４）プッシュ型サービス実現方法は、ＡＰＩを用いて配信されるメッセージとして、決定した配信方法を含む情報を送信するように構成されていてもよい。
【０２４７】
（５）プッシュ型サービス実現方法は、データの分析状況を監視することにより、分析結果が生成される頻度をＡＰＩ毎に推定し、推定した分析結果の生成頻度に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２４８】
（６）プッシュ型サービス実現方法は、データを分析する計算機が動作する計算機リソースの状況を監視して、監視結果を出力し、出力した監視結果に基づいて、データを分析する計算機が動作する計算機リソースの状況に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２４９】
（７）プッシュ型サービス実現方法は、ＡＰＩを用いて処理を実行する計算機とＡＰＩを用いた分析結果の配信を受ける装置との間のネットワークの状況を監視して、監視結果を出力し、出力した監視結果に基づいて、ネットワークの状況に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２５０】
（８）プッシュ型サービス実現方法は、ＡＰＩを用いて処理を実行する計算機のスレッド、ＡＰＩを用いて処理を実行する計算機とＡＰＩを用いた分析結果の配信を受ける装置との間のネットワークソケットを監視することによって、ネットワークの状況を監視するように構成されていてもよい。
【０２５１】
（９）プッシュ型サービス実現方法は、分析結果の配信を要求する分析クエリを記憶させるためのＡＰＩと、分析クエリに対する分析結果を配信するためのＡＰＩとが、異なるネットワークセッションを用いて実行され、分析クエリに対する分析結果を配信するためのＡＰＩを、所定期間毎にポーリングするポーリング型の配信方法と、分析クエリを記憶させる際に用いたネットワークセッションを維持して、該ネットワークセッションをそのまま用いて分析結果を配信するコネクション型の配信方法とのいずれかに決定し、ＡＰＩを用いた分析結果の配信を受ける装置に、ＡＰＩを用いて配信された分析結果を含むメッセージを解釈して、ＡＰＩに対するポーリング制御を行うラッパーが搭載されているように構成されていてもよい。
【０２５２】
（１０）プッシュ型サービス実現方法は、ラッパーを用いて、ＡＰＩを用いて分析結果の配信方法を示す情報を受信し、受信した該情報で示される配信方法に応じて、ＡＰＩを繰り返しポーリングする制御を行うように構成されていてもよい。
【０２５３】
（１１）プッシュ型サービス実現方法は、ＡＰＩを用いた分析結果の配信を受ける装置が、分析結果の配信方法を決定するためのサービス要件を設定し、設定したサービス要件に基づいて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２５４】
（１２）プッシュ型サービス実現方法は、サービス要件として、ＡＰＩ毎に、要求されるリアルタイム性を示す情報を設定するように構成されていてもよい。
【０２５５】
（１３）プッシュ型サービス実現方法は、少なくとも、有料サービスユーザに対してユーザＩＤを発行し、有料サービスユーザに対して優先的にリソースを割り当てて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２５６】
（１４）プッシュ型サービス実現方法は、ＡＰＩを利用するために設定された料金の支払いに用いる電子チケットを記憶し、ユーザが電子チケットを購入しているか否かを判定し、電子チケットを購入しているか否かの判定結果に基づいて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２５７】
（１５）プッシュ型サービス実現方法は、ＡＰＩを利用するための料金を、リソースの状況に応じて動的に決定するように構成されていてもよい。
【０２５８】
（１６）プッシュ型サービス実現システム（例えば、データストリーム分析サービス提供システム）は、データを分析するデータ分析手段（例えば、データストリーム分析手段５によって実現される）と、データ分析手段の分析結果を取得するためのＡＰＩ（例えば、データストリーム分析ＡＰＩ３によって実現される）と、リソースの状況に応じて、ＡＰＩを用いた分析結果の配信方法（データストリーム分析ＡＰＩ３の利用方法（分析結果の回答方法））を決定する配信方法決定手段（例えば、ＡＰＩ利用方法判定手段４によって実現される）とを備えたことを特徴とする。
【０２５９】
（１７）プッシュ型サービス実現システムにおいて、配信方法決定手段は、少なくとも、ネットワークの状況、又はデータ分析手段が動作する計算機リソースの状況に応じて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２６０】
（１８）プッシュ型サービス実現システムにおいて、分析結果の配信を要求する分析クエリを記憶させるためのＡＰＩと、分析クエリに対する分析結果を配信するためのＡＰＩとが、異なるネットワークセッションを用いて実行され、配信方法決定手段は、分析クエリに対する分析結果を配信するためのＡＰＩを、所定期間毎にポーリングするポーリング型の配信方法と、分析クエリを記憶させる際に用いたネットワークセッションを維持して、該ネットワークセッションをそのまま用いて分析結果を配信するコネクション型の配信方法とのいずれかに決定するように構成されていてもよい。
【０２６１】
（１９）プッシュ型サービス実現システムにおいて、ＡＰＩを用いて配信されるメッセージとして、配信方法決定手段が決定した配信方法を含む情報を送信するように構成されていてもよい。
【０２６２】
（２０）プッシュ型サービス実現システムは、データ分析手段による分析状況を監視することにより、分析結果が生成される頻度をＡＰＩ毎に推定する分析結果監視手段（例えば、分析結果監視手段４０２によって実現される）を備え、配信方法決定手段は、分析結果監視手段が推定する分析結果の生成頻度に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２６３】
（２１）プッシュ型サービス実現システムは、データ分析手段が動作する計算機リソースの状況を監視して、監視結果を出力する計算機リソース監視手段（例えば、計算機リソース監視手段４０４によって実現される）を備え、配信方法決定手段は、計算機リソース監視手段が出力する監視結果に基づいて、データ分析手段が動作する計算機リソースの状況に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２６４】
（２２）プッシュ型サービス実現システムは、ＡＰＩを用いて処理を実行する計算機とＡＰＩを用いた分析結果の配信を受ける装置との間のネットワークの状況を監視して、監視結果を出力する通信環境監視手段（例えば、通信環境監視手段４０３によって実現される）を備え、配信方法決定手段は、通信環境監視手段が出力する監視結果に基づいて、ネットワークの状況に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２６５】
（２３）プッシュ型サービス実現システムにおいて、通信環境監視手段は、ＡＰＩを用いて処理を実行する計算機のスレッド、ＡＰＩを用いて処理を実行する計算機とＡＰＩを用いた分析結果の配信を受ける装置との間のネットワークソケットを監視するように構成されていてもよい。
【０２６６】
（２４）プッシュ型サービス実現システムにおいて、分析結果の配信を要求する分析クエリを記憶させるためのＡＰＩと、分析クエリに対する分析結果を配信するためのＡＰＩとが、異なるネットワークセッションを用いて実行され、配信方法決定手段は、分析クエリに対する分析結果を配信するためのＡＰＩを、所定期間毎にポーリングするポーリング型の配信方法と、分析クエリを記憶させる際に用いたネットワークセッションを維持して、該ネットワークセッションをそのまま用いて分析結果を配信するコネクション型の配信方法とのいずれかに決定し、ＡＰＩを用いた分析結果の配信を受ける装置に搭載され、ＡＰＩを用いて配信された分析結果を含むメッセージを解釈して、ＡＰＩに対するポーリング制御を行うラッパー（例えば、データストリーム分析ＡＰＩラッパー７によって実現される）をさらに備えるように構成されていてもよい。
【０２６７】
（２５）プッシュ型サービス実現システムにおいて、ラッパーは、ＡＰＩを用いて分析結果の配信方法を示す情報を受信し、受信した該情報で示される配信方法に応じて、ＡＰＩを繰り返しポーリングする制御を行うように構成されていてもよい。
【０２６８】
（２６）プッシュ型サービス実現システムにおいて、ＡＰＩを用いた分析結果の配信を受ける装置は、分析結果の配信方法を決定するためのサービス要件を設定するサービス要件設定手段（例えば、サービス要件定義手段８によって実現される）を備え、配信方法決定手段は、サービス要件設定手段が設定したサービス要件に基づいて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２６９】
（２７）プッシュ型サービス実現システムにおいて、サービス要件設定手段は、ＡＰＩ毎に、要求されるリアルタイム性を示す情報を設定するように構成されていてもよい。
【０２７０】
（２８）プッシュ型サービス実現システムは、少なくとも、有料サービスユーザに対してユーザＩＤを発行するユーザＩＤ発行手段（例えば、ユーザＩＤ管理手段９によって実現される）を備え、配信方法決定手段は、有料サービスユーザに対して優先的にリソースを割り当てて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２７１】
（２９）プッシュ型サービス実現システムは、ＡＰＩを利用するために設定された料金の支払いに用いる電子チケットを記憶する利用チケット記憶手段（例えば、リソース利用チケット管理手段１０によって実現される）と、ユーザが電子チケットを購入しているか否かを判定する利用チケット判定手段（例えば、リソース利用チケットチェック手段１１によって実現される）とを備え、配信方法決定手段は、利用チケット判定手段の判定結果に基づいて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２７２】
（３０）プッシュ型サービス実現システムは、ＡＰＩを利用するための料金を、リソースの状況に応じて動的に決定する利用価格決定手段（例えば、ＡＰＩ利用価格管理手段１２によって実現される）を備えるように構成されていてもよい。
【０２７３】
（３１）プッシュ型サービス実現装置（例えば、データストリーム分析サーバ（Ｐ２））は、データを分析するデータ分析手段と、データ分析手段の分析結果を取得するためのＡＰＩと、リソースの状況に応じて、ＡＰＩを用いた分析結果の配信方法を決定する配信方法決定手段とを備えたことを特徴とする。
【０２７４】
（３２）プッシュ型サービス実現装置において、配信方法決定手段は、少なくとも、ネットワークの状況、又はデータ分析手段が動作する計算機リソースの状況に応じて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２７５】
（３３）プッシュ型サービス実現装置において、分析結果の配信を要求する分析クエリを記憶させるためのＡＰＩと、分析クエリに対する分析結果を配信するためのＡＰＩとが、異なるネットワークセッションを用いて実行され、配信方法決定手段は、分析クエリに対する分析結果を配信するためのＡＰＩを、所定期間毎にポーリングするポーリング型の配信方法と、分析クエリを記憶させる際に用いたネットワークセッションを維持して、該ネットワークセッションをそのまま用いて分析結果を配信するコネクション型の配信方法とのいずれかに決定するように構成されていてもよい。
【０２７６】
（３４）プッシュ型サービス実現装置において、ＡＰＩを用いて配信されるメッセージとして、配信方法決定手段が決定した配信方法を含む情報を送信するように構成されていてもよい。
【０２７７】
（３５）プッシュ型サービス実現装置は、データ分析手段による分析状況を監視することにより、分析結果が生成される頻度をＡＰＩ毎に推定する分析結果監視手段を備え、配信方法決定手段は、分析結果監視手段が推定する分析結果の生成頻度に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２７８】
（３６）プッシュ型サービス実現装置は、データ分析手段が動作する計算機リソースの状況を監視して、監視結果を出力する計算機リソース監視手段を備え、配信方法決定手段は、計算機リソース監視手段が出力する監視結果に基づいて、データ分析手段が動作する計算機リソースの状況に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２７９】
（３７）プッシュ型サービス実現装置は、ＡＰＩを用いて処理を実行する計算機とＡＰＩを用いた分析結果の配信を受ける装置との間のネットワークの状況を監視して、監視結果を出力する通信環境監視手段を備え、配信方法決定手段は、通信環境監視手段が出力する監視結果に基づいて、ネットワークの状況に応じて、分析結果の配信方法を決定するように構成されていてもよい。
【０２８０】
（３８）プッシュ型サービス実現装置において、通信環境監視手段は、ＡＰＩを用いて処理を実行する計算機のスレッド、ＡＰＩを用いて処理を実行する計算機とＡＰＩを用いた分析結果の配信を受ける装置との間のネットワークソケットを監視するように構成されていてもよい。
【０２８１】
（３９）プッシュ型サービス実現装置は、少なくとも、有料サービスユーザに対してユーザＩＤを発行するユーザＩＤ発行手段を備え、配信方法決定手段は、有料サービスユーザに対して優先的にリソースを割り当てて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２８２】
（４０）プッシュ型サービス実現装置は、ＡＰＩを利用するために設定された料金の支払いに用いる電子チケットを、ユーザが購入しているか否かを判定する利用チケット判定手段を備え、配信方法決定手段は、利用チケット判定手段の判定結果に基づいて、ＡＰＩを用いた分析結果の配信方法を決定するように構成されていてもよい。
【０２８３】
（４１）プッシュ型サービス実現装置は、ＡＰＩを利用するための料金を、リソースの状況に応じて動的に決定する利用価格決定手段を備えるように構成されていてもよい。
【０２８４】
（４２）プッシュ型サービス実現用プログラムは、コンピュータに、データを分析するデータ分析処理と、リソースの状況に応じて、データの分析結果を取得するためのＡＰＩを用いた分析結果の配信方法を決定する配信方法決定処理とを実行させるためのものである。
【０２８５】
（４３）プッシュ型サービス実現用プログラムは、コンピュータに、配信方法決定処理で、少なくとも、ネットワークの状況、又は計算機リソースの状況に応じて、ＡＰＩを用いた分析結果の配信方法を決定する処理を実行させるものであってもよい。
【０２８６】
（４４）プッシュ型サービス実現用プログラムは、分析結果の配信を要求する分析クエリを記憶させるためのＡＰＩと、分析クエリに対する分析結果を配信するためのＡＰＩとが、異なるネットワークセッションを用いて実行されるコンピュータに、配信方法決定処理で、分析クエリに対する分析結果を配信するためのＡＰＩを、所定期間毎にポーリングするポーリング型の配信方法と、分析クエリを記憶させる際に用いたネットワークセッションを維持して、該ネットワークセッションをそのまま用いて分析結果を配信するコネクション型の配信方法とのいずれかに決定する処理を実行させるものであってもよい。
【０２８７】
（４５）プッシュ型サービス実現用プログラムは、コンピュータに、ＡＰＩを用いて配信されるメッセージとして、決定した配信方法を含む情報を送信する処理を実行させるものであってもよい。
【０２８８】
（４６）プッシュ型サービス実現用プログラムは、コンピュータに、データの分析状況を監視することにより、分析結果が生成される頻度をＡＰＩ毎に推定する分析結果監視処理を実行させ、配信方法決定処理で、推定した分析結果の生成頻度に応じて、分析結果の配信方法を決定する処理を実行させるものであってもよい。
【０２８９】
（４７）プッシュ型サービス実現用プログラムは、コンピュータに、計算機リソースの状況を監視して、監視結果を出力する計算機リソース監視処理を実行させ、配信方法決定処理で、出力した監視結果に基づいて、計算機リソースの状況に応じて、分析結果の配信方法を決定する処理を実行させるものであってもよい。
【０２９０】
（４８）プッシュ型サービス実現用プログラムは、コンピュータに、ＡＰＩを用いて処理を実行する計算機とＡＰＩを用いた分析結果の配信を受ける装置との間のネットワークの状況を監視して、監視結果を出力する通信環境監視処理を実行させ、配信方法決定処理で、出力した監視結果に基づいて、ネットワークの状況に応じて、分析結果の配信方法を決定する処理を実行させるものであってもよい。
【０２９１】
（４９）プッシュ型サービス実現用プログラムは、コンピュータに、通信環境監視処理で、ＡＰＩを用いて処理を実行する計算機のスレッド、ＡＰＩを用いて処理を実行する計算機とＡＰＩを用いた分析結果の配信を受ける装置との間のネットワークソケットを監視する処理を実行させるものであってもよい。
【０２９２】
（５０）プッシュ型サービス実現用プログラムは、コンピュータに、少なくとも、有料サービスユーザに対してユーザＩＤを発行するユーザＩＤ発行処理を実行させ、配信方法決定処理で、有料サービスユーザに対して優先的にリソースを割り当てて、ＡＰＩを用いた分析結果の配信方法を決定する処理を実行させるものであってもよい。
【０２９３】
（５１）プッシュ型サービス実現用プログラムは、コンピュータに、ＡＰＩを利用するために設定された料金の支払いに用いる電子チケットを、ユーザが購入しているか否かを判定する利用チケット判定処理を実行させ、配信方法決定処理で、電子チケットを購入しているか否かの判定結果に基づいて、ＡＰＩを用いた分析結果の配信方法を決定する処理を実行させるものであってもよい。
【０２９４】
（５２）プッシュ型サービス実現用プログラムは、コンピュータに、ＡＰＩを利用するための料金を、リソースの状況に応じて動的に決定する利用価格決定処理を実行させるものであってもよい。
【産業上の利用可能性】
【０２９５】
本発明は、大規模データストリームをリアルタイムに分析するアプリケーションをマッシュアップ的に簡単に構築できるデータストリーム分析装置（システム）の用途に適用できる。
【符号の説明】
【０２９６】
１，１Ａ  分析ＡＰＩ利用手段
２  コネクション通信手段
３  データストリーム分析ＡＰＩ
４、４Ｂ〜４Ｄ  ＡＰＩ利用方法判定手段
４０１  回答方法決定手段
４０２  分析結果監視手段
４０３  通信環境監視手段
４０４  計算機リソース監視手段
５  データストリーム分析手段
６  ポーリング型分析結果記憶手段
７  データストリーム分析ＡＰＩラッパー
８  サービス要件定義手段
９  ユーザＩＤ管理手段
１０  リソース利用チケット管理手段
１１  リソース利用チケットチェック手段
１２  ＡＰＩ利用価格管理手段
４０  ルール記憶手段
Ｐ１  マッシュアップＰＣ
Ｐ２  データストリーム分析サーバ
【図１】
0005564925.tif 000002
【図２】
0005564925.tif 000003
【図３】
0005564925.tif 000004
【図４】
0005564925.tif 000005
【図５】
0005564925.tif 000006
【図６】
0005564925.tif 000007
【図７】
0005564925.tif 000008
【図８】
0005564925.tif 000009
【図９】
0005564925.tif 000010
【図１０】
0005564925.tif 000011
【図１１】
0005564925.tif 000012
【図１２】
0005564925.tif 000013
【図１３】
0005564925.tif 000014
【図１４】
0005564925.tif 000015
【図１５】
0005564925.tif 000016
【図１６】
0005564925.tif 000017
【図１７】
0005564925.tif 000018
【図１８】
0005564925.tif 000019
【図１９】
0005564925.tif 000020
【図２０】
0005564925.tif 000021
【図２１】
0005564925.tif 000022
【図２２】
0005564925.tif 000023
【図２３】
0005564925.tif 000024
【図２４】
0005564925.tif 000025
【図２５】
0005564925.tif 000026
【図２６】
0005564925.tif 000027
【図２７】
0005564925.tif 000028
【図２８】
0005564925.tif 000029
【図２９】
0005564925.tif 000030
【図３０】
0005564925.tif 000031
【図３１】
0005564925.tif 000032
【図３２】
0005564925.tif 000033
【図３３】
0005564925.tif 000034
【図３４】
0005564925.tif 000035
【図３５】
0005564925.tif 000036
【図３６】
0005564925.tif 000037
【図３７】
0005564925.tif 000038
【図３８】
0005564925.tif 000039
【図３９】
0005564925.tif 000040