(57)【要約】  本出願は、クラウドプラットフォームベースのクライアントアプリケーション情報統計方法および装置を提供する。方法は、事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログをモニタし、事象追跡ログから事象追跡情報を抽出することであって、事象追跡ログが、事前に定義された事象追跡属性に従って作成され、クライアントアプリケーションが、事象追跡ソフトウェア開発キットのアプリケーションプログラミングインタフェースを呼び出すことによって事象追跡属性を事前に定義する、抽出することと、少なくとも１つの次元に従って、事象追跡情報をマージすることと、クエリ要求に従って、マージされた事象追跡情報のクエリを行って提示することを含む。本出願では、事象追跡は、事象追跡ＳＤＫのＡＰＩを使用することによって自己定義することができ、クライアントアプリケーションに関連するデータは異なるアプリケーションシナリオにおけるユーザニーズに応じて自己定義方式で収集することができるため、クライアントアプリケーションの情報収集範囲が拡大され、収集結果の利用率が向上する。事象追跡ログから読み取られた事象追跡情報は異なる次元に従ってマージされ、従って、収集結果の統計の分類が達成される。
2019517040.tif 000002
【特許請求の範囲】
【請求項１】
事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログをモニタし、前記事象追跡ログから事象追跡情報を抽出することであって、前記事象追跡ログが、事前に定義された事象追跡属性に従って作成され、前記クライアントアプリケーションが、前記事象追跡ソフトウェア開発キットのアプリケーションプログラミングインタフェースを呼び出すことによって前記事象追跡属性を事前に定義する、抽出することと、
少なくとも１つの次元に従って、前記事象追跡情報をマージすることと、
クエリ要求に従って、前記マージされた事象追跡情報のクエリを行って提示することと
を含む、クラウドプラットフォームベースのクライアントアプリケーション情報統計方法。
【請求項２】
前記事象追跡属性が、前記事象追跡情報の事象追跡タイプおよび／または事象追跡キーワードを含み、前記事象追跡タイプが、前記事象追跡情報が属する事象追跡カテゴリまたは事象追跡サブカテゴリを含む、請求項１に記載の方法。
【請求項３】
事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログを前記モニタすることが、
前記事象追跡ログのカタログおよび／または前記事象追跡情報の変化状態をモニタすることと、
前記カタログおよび／または前記事象追跡情報が変化した場合は、新しい事象追跡情報が前記事象追跡ログに追加されたと判断することと
を含む、請求項１に記載の方法。
【請求項４】
前記事象追跡ログから事象追跡情報を前記抽出することが、
前記事象追跡ログから前記事象追跡情報を徐々に抽出すること
を含む、請求項１に記載の方法。
【請求項５】
前記事象追跡ログから事象追跡情報を前記抽出した後に、
前記事象追跡情報をメッセージ指向ミドルウェアに送信することであって、前記メッセージ指向ミドルウェアが、前記事象追跡情報を送信し、伝送速度を制御するように構成される、送信すること
をさらに含み、
少なくとも１つの次元に従って、前記事象追跡情報を前記マージする前に、
前記メッセージ指向ミドルウェアから前記事象追跡情報を読み取ること
をさらに含む、請求項１に記載の方法。
【請求項６】
少なくとも１つの次元に従って、前記事象追跡情報を前記マージする前に、
スクリーニングを通じて前記事象追跡属性に対応する事象追跡情報を見つけること
をさらに含む、請求項１に記載の方法。
【請求項７】
少なくとも１つの次元に従って、前記事象追跡情報を前記マージすることが、
アプリケーション次元および／または時間次元に従って、前記事象追跡情報をマージすること
を含む、請求項１に記載の方法。
【請求項８】
前記クエリ要求が、クエリインタフェースを通じて入力されたクエリパラメータを保持し、
クエリ要求に従って、前記マージされた事象追跡情報の前記クエリを行って提示することが、
前記クエリパラメータに従って、前記マージされた事象追跡情報のクエリを行って提示することであって、前記クエリパラメータが、期間、前記事象追跡属性および前記クライアントアプリケーションのアプリケーション識別子の少なくとも１つを含む、クエリを行って提示すること
を含む、請求項１に記載の方法。
【請求項９】
事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログをモニタするように構成された事象追跡ログモニタリングモジュールと、
前記事象追跡ログから事象追跡情報を抽出するように構成された事象追跡情報抽出モジュールであって、前記事象追跡ログが、事前に定義された事象追跡属性に従って作成され、前記クライアントアプリケーションが、前記事象追跡ソフトウェア開発キットのアプリケーションプログラミングインタフェースを呼び出すことによって前記事象追跡属性を事前に定義する、事象追跡情報抽出モジュールと、
少なくとも１つの次元に従って、前記事象追跡情報をマージするように構成された事象追跡情報マージモジュールと、
クエリ要求に従って、前記マージされた事象追跡情報のクエリを行って提示するように構成された事象追跡情報提示モジュールと
を含む、クラウドプラットフォームベースのクライアントアプリケーション情報統計装置。
【請求項１０】
前記事象追跡属性が、前記事象追跡情報の事象追跡タイプおよび／または事象追跡キーワードを含み、前記事象追跡タイプが、前記事象追跡情報が属する事象追跡カテゴリまたは事象追跡サブカテゴリを含む、請求項９に記載の装置。
【請求項１１】
前記事象追跡ログモニタリングモジュールが、前記事象追跡ログのカタログおよび／または前記事象追跡情報の変化状態をモニタすることと、前記カタログおよび／または前記事象追跡情報が変化した場合は、新しい事象追跡情報が前記事象追跡ログに追加されたと判断することとを行うように具体的に構成される、請求項９に記載の装置。
【請求項１２】
前記事象追跡情報読取モジュールが、前記事象追跡ログから前記事象追跡情報を徐々に抽出するように具体的に構成される、請求項９に記載の装置。
【請求項１３】
前記装置が、
前記事象追跡ログから前記事象追跡情報を抽出した後に、前記事象追跡情報をメッセージ指向ミドルウェアに送信することを行うように構成された事象追跡情報送信モジュールをさらに含み、前記メッセージ指向ミドルウェアが、前記事象追跡情報を送信し、伝送速度を制御するように構成され、
前記装置が、
前記少なくとも１つの次元に従って、前記事象追跡情報をマージする前に、前記メッセージ指向ミドルウェアから前記事象追跡情報を読み取るように構成された事象追跡情報抽出モジュールをさらに含む、請求項９に記載の装置。
【請求項１４】
前記装置が、
前記少なくとも１つの次元に従って、前記事象追跡情報をマージする前に、スクリーニングを通じて前記事象追跡属性に対応する事象追跡情報を見つけるように構成された事象追跡情報スクリーニングモジュールをさらに含む、請求項９に記載の装置。
【請求項１５】
前記事象追跡情報マージモジュールが、アプリケーション次元および／または時間次元に従って、前記事象追跡情報をマージするように具体的に構成される、請求項９に記載の装置。
【請求項１６】
前記クエリ要求が、クエリインタフェースを通じて入力されたクエリパラメータを保持し、
前記事象追跡情報提示モジュールが、前記クエリパラメータに従って、前記マージされた事象追跡情報のクエリを行って提示することを行うように具体的に構成され、前記クエリパラメータが、期間、前記事象追跡属性および前記クライアントアプリケーションのアプリケーション識別子の少なくとも１つを含む、請求項９に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
技術分野
本出願は、クラウドプラットフォーム技術の分野に関し、より具体的には、クラウドプラットフォームベースのクライアントアプリケーション情報統計方法および装置に関する。
【背景技術】
【０００２】
背景技術
現在、クライアントアプリケーションの情報統計のための技術的解決法は、一般に、クラスメソッドを使用するアノテーションによってまたは構成ファイルによって、アスペクト指向プログラミング（ＡＯＰ）インターセプションを宣言する。具体的なフローチャートは、図１に示される通りである。クライアントアプリケーションは、Spring（オープンフレームワーク）のアノテーションまたはＡＯＰ構成ファイルを通じてエージェントを構成する必要がある。エージェントは、クライアントアプリケーションの実行メソッドをインターセプトし、インターセプトされたものとして構成された実行メソッドにアクセスした後、アクセスした実行メソッドを記録し、実行メソッドがインターセプトされた回数を計数する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
エージェントベースのインターセプションを通じてクライアントアプリケーションの情報を収集するための既存の方法では、エージェントによってインターセプトされるオブジェクトは、ある特定のシナリオに対して前もってカスタマイズされ、実際のニーズに応じて調整することはできない。それに加えて、エージェントは、クライアントアプリケーションの実行メソッドしかインターセプトすることができず、実行メソッドに関連するパラメータまたはデータをインターセプトすることはできない。従って、エージェントによって得られたインターセプション結果をさらに利用することはできず、エージェントインターセプション結果の低い利用率をもたらす。
【課題を解決するための手段】
【０００４】
発明の概要
上記の問題を考慮して、本出願の実施形態は、上記の問題を克服するためにまたは上記の問題を少なくとも部分的に解決するために、クラウドプラットフォームベースのクライアントアプリケーション情報統方法および対応するクラウドプラットフォームベースのクライアントアプリケーション情報統計装置を提供する。
【０００５】
上記の問題を解決するため、本出願は、
事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログをモニタし、事象追跡ログから事象追跡情報を抽出することであって、事象追跡ログが、事前に定義された事象追跡属性に従って作成され、クライアントアプリケーションが、事象追跡ソフトウェア開発キットのアプリケーションプログラミングインタフェースを呼び出すことによって事象追跡属性を事前に定義する、抽出することと、
少なくとも１つの次元に従って、事象追跡情報をマージすることと、
クエリ要求に従って、マージされた事象追跡情報のクエリを行って（問い合わせを行って）提示することと
を含む、クラウドプラットフォームベースのクライアントアプリケーション情報統計方法を開示する。
【０００６】
好ましくは、事象追跡属性は、事象追跡情報の事象追跡タイプおよび／または事象追跡キーワードを含み、事象追跡タイプは、事象追跡情報が属する事象追跡カテゴリまたは事象追跡サブカテゴリを含む。
【０００７】
好ましくは、事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログをモニタすることが、
事象追跡ログのカタログおよび／または事象追跡情報の変化状態をモニタすることと、
カタログおよび／または事象追跡情報が変化した場合は、新しい事象追跡情報が事象追跡ログに追加されたと判断することと
を含む。
【０００８】
好ましくは、事象追跡ログから事象追跡情報を抽出することが、
事象追跡ログから事象追跡情報を徐々に抽出すること
を含む。
【０００９】
好ましくは、事象追跡ログから事象追跡情報を抽出した後に、方法は、
事象追跡情報をメッセージ指向ミドルウェアに送信することであって、メッセージ指向ミドルウェアが、事象追跡情報を送信し、伝送速度を制御するように構成される、送信すること
をさらに含み、
少なくとも１つの次元に従って、事象追跡情報をマージする前に、方法は、
メッセージ指向ミドルウェアから事象追跡情報を読み取ること
をさらに含む。
【００１０】
好ましくは、少なくとも１つの次元に従って、事象追跡情報をマージする前に、方法は、
事象追跡属性に対応する事象追跡情報をスクリーニングすること
をさらに含む。
【００１１】
好ましくは、少なくとも１つの次元に従って、事象追跡情報をマージすることが、
アプリケーション次元および／または時間次元に従って、事象追跡情報をマージすること
を含む。
【００１２】
好ましくは、クエリ要求は、クエリインタフェースを通じて入力されたクエリパラメータを保持し、
クエリ要求に従って、マージされた事象追跡情報のクエリを行って提示することが、
クエリパラメータに従って、マージされた事象追跡情報のクエリを行って提示することであって、クエリパラメータが、期間、事象追跡属性およびクライアントアプリケーションのアプリケーション識別子の少なくとも１つを含む、クエリを行って提示すること
を含む。
【００１３】
また、本出願は、
事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログをモニタするように構成された事象追跡ログモニタリングモジュールと、
事象追跡ログから事象追跡情報を抽出するように構成された事象追跡情報抽出モジュールであって、事象追跡ログが、事前に定義された事象追跡属性に従って作成され、クライアントアプリケーションが、事象追跡ソフトウェア開発キットのアプリケーションプログラミングインタフェースを呼び出すことによって事象追跡属性を事前に定義する、事象追跡情報抽出モジュールと、
少なくとも１つの次元に従って、事象追跡情報をマージするように構成された事象追跡情報マージモジュールと、
クエリ要求に従って、マージされた事象追跡情報のクエリを行って提示するように構成された事象追跡情報提示モジュールと
を含む、クラウドプラットフォームベースのクライアントアプリケーション情報統計装置も開示する。
【００１４】
好ましくは、事象追跡属性は、事象追跡情報の事象追跡タイプおよび／または事象追跡キーワードを含み、事象追跡タイプは、事象追跡情報が属する事象追跡カテゴリまたは事象追跡サブカテゴリを含む。
【００１５】
好ましくは、事象追跡ログモニタリングモジュールは、事象追跡ログのカタログおよび／または事象追跡情報の変化状態をモニタすることと、カタログおよび／または事象追跡情報が変化した場合は、新しい事象追跡情報が事象追跡ログに追加されたと判断することとを行うように具体的に構成される。
【００１６】
好ましくは、事象追跡情報読取モジュールは、事象追跡ログから事象追跡情報を徐々に抽出するように具体的に構成される。
【００１７】
好ましくは、装置は、
事象追跡ログから事象追跡情報を抽出した後に、事象追跡情報をメッセージ指向ミドルウェアに送信することを行うように構成された事象追跡情報送信モジュールをさらに含み、メッセージ指向ミドルウェアが、事象追跡情報を送信し、伝送速度を制御するように構成され、装置は、
少なくとも１つの次元に従って、事象追跡情報をマージする前に、メッセージ指向ミドルウェアから事象追跡情報を読み取るように構成された事象追跡情報抽出モジュールをさらに含む。
【００１８】
好ましくは、装置は、
少なくとも１つの次元に従って、事象追跡情報をマージする前に、スクリーニングを通じて事象追跡属性に対応する事象追跡情報を見つけるように構成された事象追跡情報スクリーニングモジュールをさらに含む。
【００１９】
好ましくは、事象追跡情報マージモジュールは、アプリケーション次元および／または時間次元に従って、事象追跡情報をマージするように具体的に構成される。
【００２０】
好ましくは、クエリ要求は、クエリインタフェースを通じて入力されたクエリパラメータを保持し、
事象追跡情報提示モジュールは、クエリパラメータに従って、マージされた事象追跡情報のクエリを行って提示することを行うように具体的に構成され、クエリパラメータが、期間、事象追跡属性およびクライアントアプリケーションのアプリケーション識別子の少なくとも１つを含む。
【００２１】
本出願の実施形態は以下の利点を含む。
【００２２】
本出願の実施形態では、クラウドプラットフォームに基づいて、事象追跡ソフトウェア開発キット（ＳＤＫ）のアプリケーションプログラミングインタフェース（ＡＰＩ）を呼び出すことによって、クライアントアプリケーションによって作成された事象追跡ログがモニタされ、事象追跡情報が事象追跡ログから読み取られ、異なる次元に従ってマージされた事象追跡情報のクエリが、ユーザのクエリ要求に従って行われて提示される。本出願の実施形態では、事象追跡は、事象追跡ＳＤＫのＡＰＩを使用することによって自己定義することができ、クライアントアプリケーションに関連するデータは、異なるアプリケーションシナリオにおけるユーザニーズに応じて自己定義方式で収集することができるため、クライアントアプリケーションの情報収集範囲が拡大され、収集結果の利用率が向上する。それに加えて、事象追跡ログから読み取られた事象追跡情報は異なる次元に従ってマージされ、従って、クライアントアプリケーションの収集結果の統計の分類が達成される。
【図面の簡単な説明】
【００２３】
【図１】先行技術におけるクライアントアプリケーションの情報統計の概略フローチャートである。
【図２】本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のステップのフローチャートである。
【図３】本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のLogAgentの概略構造図である。
【図４】本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のマージシステムの概略構造図である。
【図５】本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のメッセージ指向ミドルウェア、JStormおよびマージシステム間の関係を示す概略図である。
【図６】本出願による別のクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のステップのフローチャートである。
【図７】本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のシステム構造の概略論理図である。
【図８】本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計装置の実施形態の構造ブロック図である。
【発明を実施するための形態】
【００２４】
詳細な説明
本出願の上記の目的、特徴および利点をさらに理解し易くするため、本出願は、添付の図面および具体的な実装形態を参照して、以下でさらに詳細に説明する。
【００２５】
本出願の実施形態の主要なアイデアの１つは、サーバ端末に適用することができるクラウドプラットフォームベースのクライアントアプリケーション情報統計方法を提供することである。サーバ端末は、事象追跡ＳＤＫを提供する。クライアントアプリケーションは、事象追跡を自己定義するために事象追跡ＳＤＫのＡＰＩを呼び出す。サーバ端末は、事象追跡ログを組織的にモニタし、インテリジェントエージェントを使用することによって事象追跡ログを収集し、リアルタイムで事象追跡ログのメッセージを自動的にマージし、マージされた結果のクエリを行って提示し、従って、クライアントアプリケーションの情報収集および統計を実装する。
【００２６】
図２を参照すると、本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のステップのフローチャートが示される。方法は、具体的には、以下のステップを含み得る。
【００２７】
ステップ１００：事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログをモニタし、事象追跡ログから事象追跡情報を抽出することであって、事象追跡ログが、事前に定義された事象追跡属性に従って作成され、クライアントアプリケーションが、事象追跡ソフトウェア開発キットのアプリケーションプログラミングインタフェースを呼び出すことによって事象追跡属性を事前に定義する、抽出すること。
【００２８】
事象追跡ソフトウェア開発キットＳＤＫは、サーバ端末によってクライアントアプリケーションに提供される。事象追跡ソフトウェア開発キットは、事象追跡ログを生成する。事象追跡ログは、収集された事象追跡情報を記録するために使用される特定のログファイルである。具体的には、事象追跡属性は、事象追跡ソフトウェア開発キットにおいて自己定義され、自己定義された事象追跡属性を使用することによって、事象追跡ソフトウェア開発キットは、クライアントアプリケーションの実行の間に、自己定義された事象追跡属性に関連するすべての事象追跡メッセージを事象追跡ログに格納する。
【００２９】
事象追跡属性は、事象追跡ソフトウェア開発キットにおいて事前に定義することも、クライアントアプリケーションを使用することによって自己定義することもできる。例えば、事象追跡ＳＤＫは、使用のためにjarパッケージの形態でクライアントアプリケーションに提供することができる。javaクライアントアプリケーションは、事象追跡を自己定義するために、事象追跡ＳＤＫのjarパッケージに依存する必要がある。具体的には、クライアントアプリケーションは、事象追跡属性に従って事象追跡情報を収集するため、事象追跡ＳＤＫにおいて提供されるアプリケーションプログラミングインタフェースＡＰＩにアクセスして、事象追跡ログを作成するために使用される事象追跡属性を構成することができる。クライアントアプリケーションに関連するデータは、異なるアプリケーションシナリオにおけるユーザニーズに応じて自己定義方式で収集することができるため、クライアントアプリケーションの情報収集範囲が拡大され、収集結果の利用率が向上する。
【００３０】
具体的な実装形態では、事象追跡ログの名前およびストレージパスなどの情報もまた、ＳＤＫを使用することによって事前に定義することができる。
【００３１】
事象追跡属性は、事象追跡タイプおよび事象追跡キーワードの少なくとも１つを含み得る。
【００３２】
事象追跡属性は、事象追跡タイプを含み得る。例えば、クラウドプラットフォームに配備されたクライアントアプリケーションの負荷テストを実行する必要があり、ユーザがアプリケーション次元におけるクラウドプラットフォームシステム全体の負荷ステータスを知ることを希望する場合は、自己定義された事象追跡タイプを使用することによってユーザクエリを実行することができ、事象追跡タイプに従って記録された各ユーザクエリを取得することができ、その結果、ユーザクエリに従ってクラウドプラットフォームシステムの最大ＱＰＳ（１秒あたりのクエリ数）がさらに計算される。
【００３３】
また、事象追跡タイプを分類することもでき、例えば、事象追跡情報が属する事象追跡カテゴリ（カテゴリ）または事象追跡サブカテゴリ（サブカテゴリ）として事象追跡タイプを分類することができる。すなわち、取得された事象追跡情報の統計の分類は、事象追跡タイプによって定義される親子関係を使用することによって実装される。例えば、データベース呼び出しに対するクライアントアプリケーションの複数の実行メソッドを解析する必要がある際は、データベース呼び出しに対して事象追跡カテゴリを定義し、特定の実行メソッドの各々に対して事象追跡サブカテゴリを定義することができる。
【００３４】
事象追跡属性は、事象追跡キーワードを含み得る。クライアントアプリケーションは、収集に必要な事象追跡キーワードを定義し、事象追跡キーワードに関連する事象追跡情報をさらに取得する。例えば、クライアントアプリケーションの複数の実行パラメータを解析する必要がある際は、実行パラメータを区別するために、事象追跡ＳＤＫの事象追跡キーワードをそれぞれ定義することができる。事象追跡キーワードは、事象追跡タイプと共に定義することができる。例えば、クライアントアプリケーションは、クラウド環境において１０の仮想マシンには配備され、事象追跡ＳＤＫの事象追跡キーワードは、各仮想マシンのＣＰＵ、メモリおよびディスクなどの実行パラメータを区別するために定義することができる。具体的には、事象追跡タイプは、各仮想マシンに対して定義され、事象追跡タイプ下の事象追跡キーワードは、各仮想マシンの実行パラメータに対して定義される。
【００３５】
事象追跡属性は、クライアントアプリケーションの対象オブジェクト（例えば、実行メソッド）を呼び出すために必要な時間および対象オブジェクトの呼び出しに成功したかどうかをそれぞれ示すために、対象オブジェクトに対する呼び出し時間消費量および呼び出し成功識別子をさらに含み得る。呼び出し時間消費量および呼び出し成功／失敗情報は、解析の間に使用するために事象追跡ログに記録される。
【００３６】
具体的には、ＡＰＩの名前はlogStatであり、事象追跡タイプ、事象追跡サブカテゴリ、事象追跡キーワード、呼び出し時間消費量および呼び出し成功／失敗情報の少なくとも１つを定義することができる。事象追跡タイプおよび事象追跡サブカテゴリが定義される際は、事象追跡ＳＤＫは、結果がlogStat (String category, subCategory)であることを記録し、事象追跡タイプ、事象追跡サブカテゴリおよび呼び出し時間消費量が定義される際は、事象追跡ＳＤＫは、結果がlogStat (String category, subCategory, Long response Time)であることを記録し、事象追跡タイプ、事象追跡キーワード、呼び出し時間消費量および呼び出し成功／失敗情報が定義される際は、事象追跡ＳＤＫは、結果がlogStat (String category, String keyWord, Long responseTime, Boolean success)であることを記録する。
【００３７】
実行メソッドに関連するパラメータの集合体は、説明のための例として使用される。ＳＤＫによって提供されたＡＰＩの具体的なクラスはMonitorServiceであり、ＡＰＩの名前はMonitorServicelogStatであり、クライアントアプリケーションには、メソッド名がinsertMethodおよびupdateMethodであるMySQLデータベースのオペレーションが存在すると想定される。この２つのメソッドに対し、アプリケーションの実行の間の１分あたりの呼び出し回数を計算する必要がある。メソッドが１回呼び出されたことを記録するために事象追跡ＳＤＫが使用される際は、カテゴリはMySQLに設定され、サブカテゴリはInsertおよびUpdateとして定義されると想定される。例えば、メソッドinsertMethodの事象追跡の場合、以下の通りである。
【００３８】
メソッド呼び出し時間消費量を記録する必要がない場合は、事象追跡ＳＤＫは、結果がMonitorService.logStat(“MySQL”,”Insert”)であると記録する。
【００３９】
insertMethodの実行の時間消費量を記録する必要がある場合は、メソッドinsertMethodの実行時間は、メソッドinsertMethodの終了時刻から開始時刻を減ずることによって得ることができる。時間消費量が１０ｍｓであると想定すると、事象追跡ＳＤＫによって記録される結果は、MonitorService.logStat(”MySQL”,”Insert”,”10”)である。
【００４０】
呼び出しが成功したかどうかを記録する必要がある場合は、記録される結果は、呼び出し成功を示すMonitorService.logStat(”MySQL”,”Insert”,”10”, ”true”)または呼び出し失敗を示すMonitorService.logStat(”MySQL”,”Insert”,”10”, ”false”)である。これは、updateMethodの事象追跡にもあてはまる。
【００４１】
事象追跡ログをモニタすることは、新しい事象追跡情報の追加を見つけるために事象追跡ログにおける変化をモニタすることであり得る。ログカタログを有する事象追跡ログの場合、事象追跡ログのカタログにおける変化をモニタすることができる。カタログが変化した際は、新しい事象追跡情報が追加されたと判断される。あるいは、事象追跡情報における変化がモニタされ、事象追跡情報が変化した際は、新しい事象追跡情報が追加されたと判断される。２つの方法は、モニタリングのために組み合わせて使用することができる。
【００４２】
ステップ１００では、LogAgentは、事象追跡ログをモニタするために使用することができる。LogAgentは、事象追跡ログをモニタするように構成され、以下のモジュール、すなわち、事象追跡ログのカタログにおける変化をモニタするように構成されたPathWatchと、事象追跡ログの事象追跡情報における変化をモニタするように構成されたFileWatchと、事象追跡ログにおいてモニタされる事象追跡情報の断片（piece）の数の限度を設定するように構成されたWatchCheckerと、事象追跡ログから事象追跡情報を徐々に読み取るように構成されたLogSeekerとを具体的に含み得る。本出願では、LogAgentを使用することによって事象追跡ログをモニタすることは、具体的には、PathWatchを使用することによって事象追跡ログのカタログの変化状態をモニタすることであり得、カタログが変化した際は、新しい事象追跡情報が事象追跡ログに追加されたことを示す。事象追跡ログをモニタすることは、事象追跡ログのカタログをモニタすることのみならず、PathWatchを使用することによって事象追跡ログのカタログの変化状態をモニタすることに基づいて、FileWatchを使用することによって事象追跡ログの事象追跡情報をモニタすることも含む。モニタリングプロセスでは、WatchCheckerは、モニタされる事象追跡情報の断片の数の限度を設定するためにさらに使用することができる。FileWatchが事象追跡ログの事象追跡情報における変化を検出した後、LogSeekerは、事象追跡情報を徐々に読み取るために使用される。LogAgentの概略構造図は、図３に示される通りである。
【００４３】
ステップ１００では、事象追跡ログから事象追跡情報を読み取ることは、具体的には、事象追跡ログから事象追跡情報を徐々に抽出することであり得る。例えば、事象追跡ログは、事象追跡情報の各断片がセグメントごとに順次配置されるxx.logファイルである。コンテンツのセグメントが事象追跡ログに追加されるたび、事象追跡情報の断片が追加されたと見なされる。事象追跡情報が読み取られる際は、既に読み取られている事象追跡情報は無視され、新しく追加された事象追跡情報のみが読み取られる。事象追跡ログ全体を読み取る必要はないため、データ処理量を低減することができる。
【００４４】
本出願の好ましい実施形態では、ステップ１００において事象追跡ログから事象追跡情報が読み取られた後、読み取られた事象追跡情報は、メッセージ指向ミドルウェアにさらに送信することができる。メッセージ指向ミドルウェアは、MetaQ（待ち行列モデルメッセージ指向ミドルウェア）またはkafka（分散購読メッセージ発行システム）であり得る。メッセージ指向ミドルウェアは、事象追跡情報を送信し、メッセージ指向ミドルウェアのメッセージスタッキング機能を使用することによって事象追跡情報の伝送速度を制御するように構成される。それに応じて、事象追跡情報が処理される前に、メッセージ指向ミドルウェアから事象追跡情報を抽出する必要がある。
【００４５】
ステップ１０２：少なくとも１つの次元に従って、事象追跡情報をマージすること。
【００４６】
事象追跡情報が得られた後、少なくとも１つの次元に従って、事象追跡情報をマージすることができ、従って、クライアントアプリケーションの収集結果の統計の分類が実装される。例えば、事象追跡情報は、１分という最小粒度のクライアントアプリケーションのマージされた情報（すなわち、１分という時間次元における最小単位のクライアントアプリケーションのマージされた情報）を最終的に提供するために、アプリケーション次元および時間次元に従ってマージされる。
【００４７】
事象追跡ログの事象追跡情報をマージするためのマージシステムは、サーバ端末に前もって配備することができる。事象追跡情報をマージする動作は、マージシステムにおいて実行することができる。マージシステムの構造は、図４に示される通りである。マージシステムは、データレシーバを使用してマージされた情報を受信し、データアナライザを使用してマージされた情報を解析し、マージされた情報をデータベースに格納することができる。データベースは、解析済みのマージされた情報を格納するように構成され、マージされた情報のクエリを行うためのデータクエリインタフェースをさらに提供することができる。マージシステムを使用してデータをマージすることにより、リアルタイム性およびデータ処理の正確度を保証することができる。
【００４８】
時間次元に従って事象追跡情報をマージすることは、具体的には、同じ時点でまたは同じ期間内にマージされたデータとしての機能を果たすために、事象追跡情報の各断片に対応する時点または期間に従って、同じ時点または期間に属する事象追跡情報の複数の断片をマージすることであり得る。アプリケーション次元に従って事象追跡情報をマージすることは、具体的には、同じクライアントアプリケーションのマージされた情報としての機能を果たすために、事象追跡情報の各断片に対応するクライアントアプリケーションの識別子に従って、同じクライアントアプリケーションに属する事象追跡情報の複数の断片をマージすることであり得る。事象追跡情報の複数の断片は、同じクライアントアプリケーションまたは異なるクライアントアプリケーションの事象追跡情報であり得る。
【００４９】
また、事象追跡ログは、有益な事象追跡情報に加えて、何らかの冗長情報も含む。従って、本出願の好ましい実施形態では、ステップ１０２の前に、読み取られた事象追跡情報をさらに整理およびフィルタリングすることができる。セパレータなどのいくつかの無意味なキャラクタまたはタグは、整理することによって削除することができ、有益な事象追跡情報は、フィルタリングによって残りの情報から抽出することができる。具体的には、事象追跡属性の事象追跡タイプおよび事象追跡キーワードの少なくとも１つに従ってスクリーニングを実行することができる。
【００５０】
具体的には、リアルタイムコンピューティングフレームワークを使用して、事象追跡情報を読み取り、事象追跡情報を整理およびフィルタリングすることができる。例えば、JStormリアルタイムコンピューティングフレームワークを使用することができる。JStormは、事象追跡属性に対応する事象追跡情報を抽出するために使用される。JStormは、ネットワーク入力／出力、スレッドモデル、リソーススケジューリング、適用性および安定性においてStormの改善を継続することによって開発されたリアルタイムコンピューティングフレームワークであり、Stormより高い実行安定性、より強力なスケジューリング機能およびより高い実行効率のような利点を有する。図５に示されるように、メッセージ指向ミドルウェア、JStormおよびマージシステム間の関係を示す概略図が示される。JStormは、メッセージ指向ミドルウェアから事象追跡情報を取得する。JStormは、スパウト（Spout）を使用して事象追跡情報を整理し、ボルト（Bolt）を使用して事象追跡情報をフィルタリングし、事象追跡キーワードに対応する整理およびフィルタリングされた事象追跡情報をマージシステムに送信する。
【００５１】
ステップ１０４：クエリ要求に従って、マージされた事象追跡情報のクエリを行って提示すること。
【００５２】
本出願を実行するサーバ端末は、事象追跡情報のクエリを行うために、ユーザのためのインタフェースを提供することができる。具体的には、上記のマージシステムが、インタフェースを提供することができる。ユーザは、インタフェースにアクセスして、事象追跡情報に対するクエリ要求を送信することができる。クエリ要求を受信した後、サーバ端末は、必要な事象追跡情報のクエリを行い、その事象追跡情報をユーザに提示する。
【００５３】
具体的には、ユーザは、インタフェースにアクセスして、必要な情報を表すクエリパラメータを入力することができ、サーバ端末は、クエリパラメータを保持するクエリ要求を受信し、クエリパラメータに従って対応する事象追跡情報のさらなるクエリを行う。クエリパラメータは、期間、事象追跡属性およびクライアントアプリケーションのアプリケーション識別子の少なくとも１つを含み得る。例えば、クエリパラメータは、期間、事象追跡属性およびアプリケーション識別子を含み、クエリパラメータに従って、マージシステムにおいて、ある特定の期間内のある特定のアプリケーションのある特定のキーワードに対応する事象追跡情報のクエリを行うことができる。クエリ結果は、グラフ、文書および傾向チャートなどの様々な形態で提示することができる。例えば、時間次元に従ってマージされた事象追跡情報に対して、視覚的な曲線を生成することができ、曲線は、リアルタイムで取得された新しい事象追跡データに従って更新することができる。
【００５４】
結論として、本出願のこの実施形態の技術的解決法では、事象追跡ＳＤＫのＡＰＩを呼び出すことによって、クライアントアプリケーションによって作成された事象追跡ログがモニタされ、事象追跡ログから事象追跡情報が読み取られ、異なる次元に従ってマージされた事象追跡情報のクエリがユーザのクエリ要求に従って行われて提示される。本出願の実施形態では、事象追跡は、事象追跡ＳＤＫのＡＰＩを使用することによって自己定義することができ、クライアントアプリケーションに関連するデータは、異なるアプリケーションシナリオにおけるユーザニーズに応じて自己定義方式で収集することができるため、クライアントアプリケーションの情報収集範囲が拡大され、収集結果の利用率が向上する。それに加えて、事象追跡ログから読み取られた事象追跡情報は、異なる次元に従ってマージされ、従って、クライアントアプリケーションの収集結果の統計の分類が達成される。その上、メッセージ指向ミドルウェアを使用して事象追跡情報を送信し、伝送速度を制御することにより、マージシステムの負荷を軽減することができる。
【００５５】
図６を参照すると、本出願による別のクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のステップのフローチャートが示される。方法は、具体的には、以下のステップを含み得る。
【００５６】
ステップ２００：クライアントアプリケーションは、事象追跡を自己定義するために、サーバ端末によって提供された事象追跡ＳＤＫを呼び出す。
【００５７】
ステップ２０２：事象追跡ＳＤＫは、事象追跡ログを作成する。
【００５８】
ステップ２０４：LogAgentは、事象追跡ログをモニタし、事象追跡ログから事象追跡情報を徐々に読み取り、事象追跡情報をメッセージ指向ミドルウェアに送信する。
【００５９】
ステップ２０６：JStormは、メッセージ指向ミドルウェアから事象追跡情報を読み取り、事象追跡情報のリアルタイム演算を実行し、演算された事象追跡情報をマージシステムに送信する。
【００６０】
ステップ２０８：マージシステムは、アプリケーション次元および／または時間次元に従って、事象追跡情報をマージする。
【００６１】
ステップ２１０：サーバ端末は、クエリ要求に従って、マージされた事象追跡情報のクエリを行って提示する。
【００６２】
結論として、本出願の実施形態のクライアントアプリケーションは、事象追跡ＳＤＫのＡＰＩを使用することによって事象追跡を自己定義することができ、クライアントアプリケーションに関連するデータは、異なるアプリケーションシナリオにおけるユーザニーズに応じて自己定義方式で収集することができるため、クライアントアプリケーションの情報収集範囲が拡大され、収集結果の利用率が向上する。それに加えて、事象追跡ログから読み取られた事象追跡情報は、異なる次元に従ってマージされ、従って、クライアントアプリケーションの収集結果の統計の分類が達成される。
【００６３】
図７を参照すると、本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計方法の実施形態のシステム構造の概略論理図が示される。クライアントアプリケーションは、事象追跡を自己定義するために、事象追跡ＳＤＫのＡＰＩを呼び出し、事象追跡ログが作成される。LogAgentは、事象追跡ログから事象追跡情報を読み取り、同じ事象追跡情報をメッセージ指向ミドルウェアに送信する。JStormは、メッセージ指向ミドルウェアから事象追跡情報をリアルタイムで読み取り、整理およびフィルタリングを実行し、整理およびフィルタリングされた事象追跡情報をマージシステムに送信する。マージシステムは、少なくとも１つの次元に従って、受信した事象追跡情報をマージし、外部からデータクエリ機能およびデータ提示機能を提供する。
【００６４】
結論として、本出願のこの実施形態の技術的解決法では、事象追跡ＳＤＫのＡＰＩを呼び出すことによって、クライアントアプリケーションによって作成された事象追跡ログがモニタされ、事象追跡ログから事象追跡情報が読み取られ、異なる次元に従ってマージされた事象追跡情報のクエリがユーザのクエリ要求に従って行われて提示される。本出願の実施形態では、事象追跡は、事象追跡ＳＤＫのＡＰＩを使用することによって自己定義することができ、クライアントアプリケーションに関連するデータは、異なるアプリケーションシナリオにおけるユーザニーズに応じて自己定義方式で収集することができるため、クライアントアプリケーションの情報収集範囲が拡大され、収集結果の利用率が向上する。それに加えて、事象追跡ログから読み取られた事象追跡情報は、異なる次元に従ってマージされ、従って、クライアントアプリケーションの収集結果の統計の分類が達成される。
【００６５】
簡単にするため、方法の実施形態は、一連の動作の組合せとして説明されることに留意すべきであるが、いくつかのステップは本出願の実施形態に従って異なる順番でまたは同時に実行することができるため、当業者であれば、本出願の実施形態は、説明される動作の順番に限定されないことを理解すべきである。また、当業者であれば、本明細書で説明される実施形態はすべて好ましい実施形態であり、これらの実施形態に関与する動作は必ずしも本出願の実施形態に必要とは限らないことも理解すべきである。
【００６６】
図８を参照すると、本出願によるクラウドプラットフォームベースのクライアントアプリケーション情報統計装置の実施形態の構造ブロック図が示される。装置は、具体的には、以下のモジュール、すなわち、
事象追跡ソフトウェア開発キットを呼び出すことによって、各クライアントアプリケーションによって作成された事象追跡ログをモニタするように構成された事象追跡ログモニタリングモジュール８００と、
事象追跡ログから事象追跡情報を抽出することであって、事象追跡ログが、事前に定義された事象追跡属性に従って作成され、クライアントアプリケーションが、事象追跡ソフトウェア開発キットのアプリケーションプログラミングインタフェースを呼び出すことによって事象追跡属性を事前に定義する、抽出することを行うように構成された事象追跡情報抽出モジュール８０２と、
少なくとも１つの次元に従って、事象追跡情報をマージするように構成された事象追跡情報マージモジュール８０４と、
クエリ要求に従って、マージされた事象追跡情報のクエリを行って提示するように構成された事象追跡情報提示モジュール８０６と
を含み得る。
【００６７】
本出願の実施形態では、好ましくは、事象追跡属性は、事象追跡情報の事象追跡タイプおよび／または事象追跡キーワードを含み、事象追跡タイプは、事象追跡情報が属する事象追跡カテゴリまたは事象追跡サブカテゴリを含む。
【００６８】
本出願の実施形態では、好ましくは、事象追跡ログモニタリングモジュールは、事象追跡ログのカタログおよび／または事象追跡情報の変化状態をモニタすることと、カタログおよび／または事象追跡情報が変化した場合は、新しい事象追跡情報が事象追跡ログに追加されたと判断することとを行うように具体的に構成される。
【００６９】
本出願の実施形態では、好ましくは、事象追跡情報読取モジュールは、事象追跡ログから事象追跡情報を徐々に抽出するように具体的に構成される。
【００７０】
本出願の実施形態では、好ましくは、装置は、
事象追跡ログから事象追跡情報を抽出した後に、事象追跡情報をメッセージ指向ミドルウェアに送信することを行うように構成された事象追跡情報送信モジュールをさらに含み、メッセージ指向ミドルウェアが、事象追跡情報を送信し、伝送速度を制御するように構成され、装置は、
少なくとも１つの次元に従って、事象追跡情報をマージする前に、メッセージ指向ミドルウェアから事象追跡情報を読み取るように構成された事象追跡情報抽出モジュールをさらに含む。
【００７１】
本出願の実施形態では、好ましくは、装置は、
少なくとも１つの次元に従って、事象追跡情報をマージする前に、スクリーニングを通じて事象追跡属性に対応する事象追跡情報を見つけるように構成された事象追跡情報スクリーニングモジュールをさらに含む。
【００７２】
本出願の実施形態では、好ましくは、事象追跡情報マージモジュールは、アプリケーション次元および／または時間次元に従って、事象追跡情報をマージするように具体的に構成される。
【００７３】
本出願の実施形態では、好ましくは、クエリ要求は、クエリインタフェースを通じて入力されたクエリパラメータを保持し、
事象追跡情報提示モジュールは、クエリパラメータに従って、マージされた事象追跡情報のクエリを行って提示することを行うように具体的に構成され、クエリパラメータが、期間、事象追跡属性およびクライアントアプリケーションのアプリケーション識別子の少なくとも１つを含む。
【００７４】
結論として、本出願の実施形態の技術的解決法では、事象追跡ＳＤＫのＡＰＩを呼び出すことによって、クライアントアプリケーションによって作成された事象追跡ログがモニタされ、事象追跡ログから事象追跡情報が読み取られ、異なる次元に従ってマージされた事象追跡情報のクエリがユーザのクエリ要求に従って行われて提示される。本出願の実施形態では、事象追跡は、事象追跡ＳＤＫのＡＰＩを使用することによって自己定義することができ、クライアントアプリケーションに関連するデータは、異なるアプリケーションシナリオにおけるユーザニーズに応じて自己定義方式で収集することができるため、クライアントアプリケーションの情報収集範囲が拡大され、収集結果の利用率が向上する。それに加えて、事象追跡ログから読み取られた事象追跡情報は、異なる次元に従ってマージされ、従って、クライアントアプリケーションの収集結果の統計の分類が達成される。
【００７５】
装置の実施形態は、方法の実施形態と基本的に同様であり、従って、簡潔に説明され、関連部分では、方法の実施形態の説明の一部を参照することができる。
【００７６】
本明細書の実施形態は、漸進的な方法で説明される。各実施形態は、他の実施形態との違いに焦点を置く。実施形態の同じまたは同様の部分では、互いに参照することができる。
【００７７】
当業者によって理解されるように、本出願の実施形態は、方法、システムまたはコンピュータプログラム製品として具体化することができる。それに従って、本出願は、完全なハードウェア実施形態、完全なソフトウェア実施形態、または、ソフトウェアとハードウェアの態様を組み合わせた実施形態の形態を使用することができる。その上、本出願の実施形態は、コンピュータ使用可能プログラムコードを含む１つまたは複数のコンピュータ使用可能記憶媒体（これらに限定されないが、磁気ディスクメモリ、ＣＤ−ＲＯＭ、光メモリなどを含む）上で実装されるコンピュータプログラム製品の形態を使用することができる。
【００７８】
典型的な構成では、演算デバイスは、１つまたは複数の中央処理装置（ＣＰＵ）、入力／出力インタフェース、ネットワークインタフェースおよびメモリを含む。メモリは、コンピュータ可読媒体の以下の形態、すなわち、揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）および／または不揮発性メモリ（例えば、読み取り専用メモリ（ＲＯＭ）またはフラッシュＲＡＭ）を含み得る。メモリは、コンピュータ可読媒体の例である。コンピュータ可読媒体は、揮発性および不揮発性媒体、モバイルおよび非モバイル媒体を含み、情報を格納するためのいかなる方法または技術も使用することができる。情報は、コンピュータ可読命令、データ構造およびプログラムのモジュール、または、他のデータであり得る。コンピュータの記憶媒体の例は、これらに限定されないが、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのＲＡＭ、ＲＯＭ、電気的消去型プログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶装置、カセットテープ、テープディスク記憶装置もしくは他の磁気記憶装置、または、コンピュータアクセス可能情報を格納するために使用できる他の任意の非伝送媒体を含む。本明細書の定義によれば、コンピュータ可読媒体は、例えば、変調データ信号および搬送波などの一時的なコンピュータ可読媒体（一時的な媒体）を含まない。
【００７９】
本出願の実施形態は、本出願の実施形態における方法、端末デバイス（システム）およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して説明される。コンピュータプログラム命令は、フローチャートおよび／またはブロック図の各プロセスおよび／またはブロックならびにフローチャートおよび／またはブロック図のプロセスおよび／またはブロックの組合せを実装できることを理解すべきである。これらのコンピュータプログラム命令は、フローチャートの１つもしくは複数のプロセスおよび／またはブロック図の１つもしくは複数のブロックで指定される機能を実装するように構成された装置が汎用コンピュータまたは他のプログラム可能データ処理デバイスのプロセッサによって実行される命令を使用することによって生成されるように、マシンを生成するために、汎用コンピュータ、専用コンピュータ、埋め込みプロセッサまたは他のプログラム可能データ処理デバイスのプロセッサに提供することができる。
【００８０】
また、これらのコンピュータプログラム命令は、コンピュータ可読メモリに格納された命令が、指示装置を含む製品（指示装置は、フローチャートの１つもしくは複数のプロセスおよび／またはブロック図の１つもしくは複数のブロックで指定される機能を実装する）を生成するように、指定された方法で機能するようにコンピュータまたは他のプログラム可能データ処理デバイスに指示することができるコンピュータ可読メモリに格納することもできる。
【００８１】
また、これらのコンピュータプログラム命令は、コンピュータによって実装される処理を生成するために一連の動作ステップがコンピュータまたは他のプログラム可能デバイス上で実行されるように、ならびに、コンピュータまたは他のプログラム可能デバイス上で実行される命令がフローチャートの１つもしくは複数のプロセスおよび／またはブロック図の１つもしくは複数のブロックで指定される機能を実装するためのステップを提供するように、コンピュータまたは他のプログラム可能データ処理デバイスにロードすることもできる。
【００８２】
本発明の好ましい実施形態について説明してきたが、当業者であれば、本発明の基本的な概念を学習した後に、実施形態の追加の変形形態または変更形態を作成することが可能である。従って、添付の請求項は、本発明の実施形態の範囲内に収まる好ましい実施形態ならびにすべての変形形態または変更形態を含むと解釈すべきである。
【００８３】
最後に、本明細書で使用される場合は、「第１の」および「第２の」などの関係語は、ある実体または動作を別の実体または動作と区別するためだけに使用され、必ずしも実体または動作間の実際の関係または順番を必要とするまたは含意するとは限らないことにさらに留意すべきである。それに加えて、「含む（include、comprise）」という用語または他の任意のその変形例は、非排他的包含を対象とすることが意図され、その結果、要素のリストを含むプロセス、方法、物品または装置は、それらの要素を含むだけではなく、そのようなプロセス、方法、物品または装置に明示的にリストされていないあるいはそのようなプロセス、方法、物品または装置特有のものではない他の要素も含むことができる。「a」、「an」または同様のもので始まる要素は、さらなる制約なしで、その要素を含むプロセス、方法、物品または装置における追加の同一の要素の存在を除外しない。
【００８４】
本出願によって提供されるクラウドプラットフォームベースのクライアントアプリケーション情報の統計的方法および装置については上記で詳細に説明している。具体的な例は、本明細書では、本出願の原理および実装形態を詳細に述べるために使用される。しかし、前述の実施形態の説明は、本出願の方法および主要なアイデアを理解し易くするためだけに使用される。当業者であれば、本出願のアイデアに従って特定の実装形態および適用範囲の変更を行うことができる。従って、本明細書の内容は、本出願を制限するものと解釈すべきではない。
【図１】
2019517040.tif 000003
【図２】
2019517040.tif 000004
【図３】
2019517040.tif 000005
【図４】
2019517040.tif 000006
【図５】
2019517040.tif 000007
【図６】
2019517040.tif 000008
【図７】
2019517040.tif 000009
【図８】
2019517040.tif 000010
【国際調査報告】
2019517040.tif 000011
2019517040.tif 000012
2019517040.tif 000013
2019517040.tif 000014