JP6050378B2 - メッセージの追跡およびチェックのための方法ならびにシステム - Google Patents

Description

本発明は、メッセージを追跡およびチェックし、さらに必要に応じて改善措置を取るための方法ならびにシステムに関するものである。

旅行システムでは、多くのメッセージが、ある場所から別の場所へと分散される。旅行システムは、一般に、中央データサーバと、システム全体に分散された幾つかの異なるレベルのキャッシュで構成されるキャッシュアーキテクチャとを含み得る。キャッシュアーキテクチャは、幾つかの異なるプロバイダから更新情報を取得し、その後、それらは、アプリケーションサーバから様々なレベルのキャッシュに伝えられる。システムは、そのメッセージまたはそれらのメッセージの確認は必要ないという前提で動作する。システムは、そのメッセージまたはそれらのメッセージは無事に受信されたと仮定する。データベースアプリケーションサーバは、メッセージを、中央データサーバ上の幾つかの中央キャッシュに送り、これによって、次にメッセージは、多数の計算サーバ上のローカルキャッシュに送られる。これらのメッセージは、キャッシュの内容を無効化する目的のものである。これらは無効化メッセージと呼ばれる。典型的な旅行システムでは、毎日１００，０００件もの数の更新がある場合があり、これは、処理される膨大な数のメッセージに等しい。もしメッセージが受信されないと問題が生じ、その場合、顧客に経済的な影響を及ぼし得る問題が発生する可能性がある。分散キャッシュアーキテクチャにおいてデータ整合性を確保および制御するために、非同期無効化メッセージを用いることができる。これを実現する方法は、難しく、かつ時間がかかり、現在のところ、効果的な方法で実現されていない。

航空旅客のチケットの監査を処理するためのシステムが幾つか提案されている。そのようなシステムの１つは、ノースウェスト航空によって提案されており、それは、エキスパートシステムによる監査プロセスを用いてレポートをレビューするものである。このシステムは、無効化メッセージなどを追跡する問題に関連した課題の多くに対応することができない。同様に、他のシステムで、運賃検証製品およびマッピング・マッチング製品を提供しており、やはり、これらは、無効化メッセージを追跡する問題に対処できていない。

特許文献１は、同じネットワークで接続された少なくとも２つのデバイス間の状態同期化のための方法ならびにシステムを開示している。第１のデバイスは、メッセージに第１の識別子を添付して、そのメッセージを第２のデバイスに送る。そして、第２のデバイスは、そのメッセージに特定のプロセスを適用して、これにより、第１の識別子を第２の識別子に変換する。その後、第１のデバイスは、第２の識別子の伝送を要求する状態要求を、第２のデバイスに送る。そして、第１のデバイスの比較モジュールが、第１の識別子と第２の識別子とを比較することで、第１のデバイスの状態が第２のデバイスの状態と同期しているかどうか判断する。

米国特許第６，６０４，２０５号明細書

本発明の目的は、従来技術に関連した問題のうち少なくとも一部を克服することである。

本発明のさらなる目的は、無効化メッセージを効果的に追跡およびモニタリングし、必要に応じてメッセージを再送することができる方法ならびにシステムを提供することである。

本発明は、添付の請求項に記載の方法ならびにシステムを提供する。

本発明の一態様により、プライシング／ショッピングプラットフォームのキャッシュアーキテクチャにおいてメッセージを追跡するための無効化トラッカシステムを提供し、該システムでは、キャッシュアーキテクチャは複数のレベルを含み、各レベルは１つまたは複数のサーバを有し、キャッシュアーキテクチャ内のすべてのサーバに無効化メッセージを送信するために、あるレベルから別のレベルへと無効化メッセージが伝えられ、また、該無効化トラッカシステムは、キャッシュアーキテクチャ内のサーバに伝えるべきデータをプロバイダ・データベースから受信し、該無効化トラッカシステムは、
‐ キャッシュアーキテクチャ内のサーバに伝えられたすべての無効化メッセージを記録することで、送信済み無効化メッセージのセットを形成するための、記録モジュールと、
‐ キャッシュアーキテクチャ内の各サーバで受信された無効化メッセージを確認し、これを送信済み無効化メッセージのセットと比較することで、１つまたは複数の未送達の無効化メッセージを特定するための、解析モジュールと、
‐ 特定された１つまたは複数の未送達の無効化メッセージを、キャッシュアーキテクチャ内の適切なサーバに再送するための、リプレイモジュールと、を備える。

オプションとして、リプレイモジュールは、所定の条件が満たされたことに基づいて、無効化メッセージを再送する。

オプションとして、上記所定の条件には、複数の反復する未送達の無効化メッセージが含まれる。

オプションとして、合致した未送達の無効化メッセージの数が所定の閾値を超えたときに、上記所定の条件がトリガされる。

オプションとして、上記所定の条件は、サーバが動作していないことが確認されることである。

オプションとして、該システムは、さらに、未送達の無効化メッセージの通知を作成して、ユーザに伝えるための通知モジュールを備える。

オプションとして、該システムは、さらに、レポートを作成して、そのレポートをユーザに伝えるための報告モジュールを備える。

オプションとして、無効化トラッカは、さらに、未送達の無効化メッセージの自動検索を制御するためのスーパバイザモジュールを備える。

オプションとして、無効化トラッカシステムは、さらに、キャッシュアーキテクチャの設定およびトポグラフィに関する情報を保存する構成管理モジュールを備える。

本発明の第２の態様により、プライシング・ショッピングプラットフォームのキャッシュアーキテクチャにおいてメッセージを追跡する方法を提供し、該方法では、キャッシュアーキテクチャは複数のレベルを含み、各レベルは１つまたは複数のサーバを有し、キャッシュアーキテクチャ内のすべてのサーバに無効化メッセージを送信するために、あるレベルから別のレベルへと無効化メッセージが伝えられ、また、メッセージは、キャッシュアーキテクチャ内のサーバに伝えるべきデータをプロバイダ・データベースから受信する無効化トラッカシステムによって追跡され、該方法は、
‐ キャッシュアーキテクチャ内のサーバに伝えられたすべての無効化メッセージを、コンピュータによって記録することで、送信済み無効化メッセージのセットを形成することと、
‐ キャッシュアーキテクチャ内の各サーバで受信された無効化メッセージを、コンピュータ内の検出器によって確認し、これを送信済み無効化メッセージのセットと比較することで、１つまたは複数の未送達の無効化メッセージを特定することと、
‐ 特定された１つまたは複数の未送達の無効化メッセージを、キャッシュアーキテクチャ内の適切なサーバに、メッセージングシステムによって再送することと、を含む。

オプションとして、無効化メッセージを再送するステップは、所定の条件に基づいている。

オプションとして、上記所定の条件には、複数の反復する未送達の無効化メッセージが確認されることが含まれる。

オプションとして、上記所定の条件には、合致した未送達の無効化メッセージの数が所定の閾値を超えたときに、メッセージのリプレイをトリガすることが含まれる。

オプションとして、上記所定の条件には、サーバが動作していないことが確認されることが含まれる。

オプションとして、該方法は、未送達の無効化メッセージの通知を作成して、ユーザに伝えるステップを含む。

オプションとして、該方法は、レポートを作成して、それらのレポートをユーザに伝えるステップを含む。

オプションとして、該方法は、スーパバイザモジュールによって、未送達の無効化メッセージの自動検索を制御するステップを含む。

オプションとして、該方法は、構成管理モジュールによって、キャッシュアーキテクチャの設定およびトポグラフィに関する情報を保存するステップを含む。

以下、添付の図面を、例として参照する。

図１は、本発明の一実施形態による無効化トラッカシステムのブロック図である。 図２は、本発明の一実施形態によるプロセスの第１の部分についての、システムのブロック図である。 図３は、本発明の一実施形態によるプロセスの第２の部分についての、システムのブロック図である。 図４は、本発明の一実施形態によるプロセスの第３の部分についての、システムのブロック図である。 図５は、本発明の一実施形態によるプロセスの第４の部分についての、システムのブロック図である。 図６は、本発明の一実施形態によるプロセスの第５の部分についての、システムのブロック図である。 図７は、本発明の一実施形態によるシステムの全体的概観のブロック図である。 図８は、本発明の一実施形態によるシステムの一般的なユースケース図である。 図９は、本発明の一実施形態による具体的なユースケース図である。 図１０は、本発明の一実施形態による具体的なユースケース図である。 図１１は、本発明の一実施形態による具体的なユースケース図である。 図１２は、本発明の一実施形態による具体的なユースケース図である。 図１３は、本発明の一実施形態による具体的なユースケース図である。 図１４は、本発明の一実施形態による具体的なユースケース図である。 図１５は、本発明の一実施形態による具体的なユースケース図である。 図１６は、本発明の一実施形態による具体的なユースケース図である。 図１７は、本発明の一実施形態による具体的なユースケース図である。 図１８は、本発明の一実施形態による具体的なユースケース図である。

本発明は、運賃キャッシングシステムに関連して用いられるように設計された無効化トラッカシステムに関する。プライシング／ショッピングプラットフォーム（ＰＳＰ：Ｐｒｉｃｉｎｇ ａｎｄ Ｓｈｏｐｐｉｎｇ Ｐｌａｔｆｏｒｍ）のキャッシュアーキテクチャは、ＰＳＰコンポーネントに分散させた幾つかのレベルのキャッシュで構成されている。図２に示すように、単一のデータベースアプリケーションサーバ２００が、複数の中央データサーバ２０２と通信し、そしてこれらが、多数の計算サーバ２０４と通信する。図示の例では、３台の中央データサーバと、約１５０台の計算サーバが設けられる。当然のことながら、異なる環境では、異なる数の中央データサーバおよび計算サーバを用いることができる。このキャッシュアーキテクチャは、プロバイダからデータ更新を継続的に取得するデータベースに接続されている。キャッシュは、データベースアプリケーションサーバから送信される無効化メッセージによって更新される。データベースは、マスターファイル・データベースとアクティブイメージ・データベースといったように複数であってもよい。しかしながら、異なる状況では、異なるデータベースを用いることができる。

無効化トラッカシステムならびに方法は、データアプリケーションサーバにより送信された無効化メッセージが、エンドユーザによって受信されたことをチェックすることを伴う。チェックは定期的に行われ、不一致が確認された場合には、無効化メッセージを自動的に再送するか、またはユーザ制御で再送することができる。永続的な問題が確認された場合には、ユーザまたはオペレータに知らせることができるように、アラームメッセージまたはエラーメッセージを生成することができる。無効化トラッカシステムならびに方法は、無効化フローにおいて、すべてのシステムコンポーネントおよびサブシステムについて調査を実施するために用いることができる。

図１を参照すると、無効化トラッカシステムコンポーネントの概観を示している。様々な特徴については、より詳細に図３に記載している。システムは、データコンソールサーバ１００を備え、ここに無効化トラッカ１０２が配置される。システムは、さらに、データベースアプリケーションサーバ１０４と、クライアントデータサーバ（ＣＤＳ：Ｃｌｉｅｎｔ Ｄａｔａ Ｓｅｒｖｅｒ）サブシステム１０６と、価格設定または低運賃検索（ＬＦＳ：Ｌｏｗ Ｆａｒｅ Ｓｅａｒｃｈ）サブシステム１０８（以下、計算サーバと呼ぶ）と、を備える。無効化トラッカシステムは、３つの主要モジュールを有する。無効化トラッカ・スーパバイザ１１０は、所定の時間範囲および所定のエンドユーザまたはターゲットのセットについての、消失した無効化メッセージの全自動での検出およびリプレイまたは再送を管理する。無効化トラッカ検出モジュール１１２は、ターゲット無効化コンポーネントのキーロガー・ファイルからのキーを解析することによって、消失した無効化メッセージを特定する。無効化トラッカ・リプレイモジュール１１４は、消失した無効化メッセージを、要求されたターゲットに対してリプレイまたは再送する。無効化トラッカシステムは、基本的にミドルウェアサービスレベルにある。

論理無効化フローには、４つのタイプのシステムコンポーネントが含まれる。第１のものは、データベースアプリケーションサーバ１１６上にあるデータベースアプリケーションサーバ無効化サービスである。これは、論理キーの配列を、ＣＤＳ ＣＩＸ（Ｃｅｎｔｒａｌ Ｉｎｖａｌｉｄａｔｉｏｎ：集中無効化）サーバキューのメッセージキューへ送信する。ＣＩＸサーバ１１８は、論理エンティティ・キーの配列を含むメッセージを受信して、それらを無効化するとともに、単独キーを含むメッセージにしてＩＩＸ（Ｉｎｄｉｖｉｄｕａｌ Ｉｎｖａｌｉｄａｔｉｏｎ：個別無効化）サーバ１２０に送る。ＩＩＸサーバは、ＣＤＳキャッシュ上で単独無効化メッセージを管理し、それらの無効化メッセージを、価格設定サテライトまたはターゲット１０８上のＬＩＸ（Ｌｏｃａｌ Ｉｎｖａｌｉｄａｔｉｏｎ：ローカル無効化）サーバ１２２に転送する。ＬＩＸサーバは、計算サーバ上で無効化メッセージを処理する。それぞれのサーバは、検出器１１２と通信する適切なキーロガー（１２４，１２６，１２８，１３０）を有する。キーロガーの目的は、それぞれのサーバで受信したすべてのメッセージをローカルで保存することである。

無効化トラッカシステムは、それぞれの無効化システムコンポーネントで、受信したメッセージのキーをログ記録する必要がある。このロギングは、それぞれのサーバに関連付けられたキーロガー・システムコンポーネントを通して実行される。キーがログ記録され、これにより、無効化フローが失敗した場所を特定することが、より容易となる。無効化トラッカシステムコンポーネント間の通信は、標準ミドルウェア通信に基づいている。従って、システムの特定のコンポーネントに関する必要な情報はすべて、無効化トラッカ専用の構成ファイルに保存される。必要な情報には、ホスト名、ターゲットミドルウェア環境、またはターゲットデータベースを含むことができる。無効化トラッカシステムは、ターゲットが無効化に関して動作可能であるかどうか判断することができ、動作可能でない場合は、そのターゲットを無視することができる。

無効化トラッカシステムは、幾つかビスポークプロセスによって、無効化メッセージをモニタリングし、リプレイする。第１のプロセスは、サーバで受信した無効化メッセージが各サーバ上で記録される記録プロセスである。解析プロセスでは、各サーバで受信した無効化メッセージが、定期的に、くまなくチェックされる。メッセージが消失した場合には、対応するデータをリフレッシュするために、リプレイプロセスを用いて、当該メッセージを自動的にリプレイする。メッセージが消失した場合には、通知プロセスを用いて確認する。報告プロセスを用いて、すべてのアクションがログ記録およびアーカイブされ、また、随時、統計レポートが作成される。ビスポークプロセスの各々について、図２〜６を参照して説明する。

図２に戻って、各サーバは、無効化メッセージハンドラ、それぞれ２０６、２０８、２１０と、ロギングハンドラ、それぞれ２１２、２１４、２１６と、圧縮された無効化メッセージのデータベース、それぞれ２１８、２２０、２２２と、を有する。無効化メッセージハンドラ２０６から無効化メッセージハンドラ２０８にメッセージが送信される。次に、無効化メッセージハンドラ２０８は、それらのメッセージを、それぞれの無効化メッセージハンドラ２１０に伝える。

無効化メッセージハンドラの各々は、そのそれぞれのロギングハンドラにメッセージを渡し、そこで、データアプリケーションサーバに示すようなモジュール２２４、２２６で、それはログ記録され、圧縮される。メッセージがログ記録および圧縮された後に、データアプリケーションサーバに示すようなデータベース２１８に、圧縮されたメッセージが保存される。同様の構成が、中央データサーバおよび計算サーバに見られる。これで、各サーバ上でのすべての無効化メッセージの記録プロセスが完了する。

この種の典型的なＰＳＰキャッシングシステムの場合、毎秒約１５，０００件のメッセージのローカルレートで、総データ量は、１日当たり４．５ＧＢ程度となる。キャッシングシステムの保存遅延は、典型的には、５日程度となる。送信されたすべてのメッセージは、所定の期間、各サーバの圧縮無効化メッセージデータベースに保存される。

次に図３を参照して、解析プロセスについて以下で説明する。データコンソールサーバ３００は、データアプリケーションサーバ２００、中央データサーバ２０２、および計算サーバ２０４と通信する。データコンソールサーバ内の無効化トラッカシステムは、コーディネータモジュール３０８と、構成マネージャ３１０と、構成データベース３１２と、を有する。また、無効化トラッカは、さらに、リプレイ用メッセージのデータベース３１６および履歴データベース３１８という２つのデータベースと通信する検出器３１４を有する。検出器は、さらに、無効化メッセージコレクタ３２０とも通信する。

サーバ２００、２０２、２０４の各々は、データアプリケーションサーバ２００に２１２として示すロギングハンドラを有する。ロギングハンドラは、圧縮無効化メッセージのデータベース２１８と通信する。ロギングハンドラは、検索モジュール３２４と、圧縮解除モジュール３２６と、シリアライズモジュール３２８と、を含む。他のサーバ２０２および２０４は、同じように構成される。

コーディネータモジュールは、解析のサイクルを定期的にトリガする。コーディネータモジュールは、検出器３１４の解析モジュール３３０と通信する。解析器は、同様に、無効化メッセージコレクタ３２０の収集モジュール３３２と通信する。収集モジュールは、受信または完了した無効化メッセージの詳細をＰＳＰシステムサーバから収集して、記録する。収集は、各層のサーバから、すなわち、データベースアプリケーションサーバ、中央データベースサーバ、および計算サーバから、行われる。次に、解析モジュールは、アルゴリズムを適用することで、受信されなかったメッセージまたは消失したメッセージを検出し、特定し、保存する。前述のように、各メッセージのキーログによって、メッセージおよびそれが消失した場所を特定することが容易となる。消失したメッセージであって、後にリプレイする必要があり得るメッセージを、データベース３１６に保存する。構成マネージャ３１０は、ＰＳＰシステムサーバの設定およびトポグラフィの集中ビューを有し、無効化メッセージの収集を調整することができる。ネットワークの構成を、構成データベース３１２に保存し、ネットワークの変更に応じて更新することができる。履歴データベース３１８を用いて、すべてのアクションの記録を保持する。動作中に、解析モジュール３３０は、まず第１に、データベースアプリケーションサーバで受信したメッセージをチェックする。続いて、中央データサーバにおけるメッセージをチェックし、最後に、計算サーバにおけるメッセージをチェックする。この手順によって、ある特定の無効化メッセージについて障害発生点の特定が可能となる。

検索モジュール３２４は、図３に示すように、データベースアプリケーションサーバ内にある。検索モジュール３２４は、受信した無効化メッセージを識別し、そして転送する。メッセージは、データアプリケーションサーバから中央データサーバへ送信され、次に、中央データサーバから計算サーバへ送信される。

無効化メッセージの受信が解析されたら、プロセスの次の段階は、消失したメッセージが確認された場合に、メッセージをリプレイまたは再送することである。これについて、図４を参照して説明するが、図４では、図３のものと類似の要素は、同一の参照番号を有し、それが無効化メッセージのリプレイのプロセスに関するものでない限り、さらに詳細には説明しない。無効化トラッカは、上述のモジュールに加えて、リプレイモジュール４００と、無効化メッセージ送信モジュール４０２と、を有する。消失した無効化メッセージの解析の後に、ある特定のサーバについて、消失したメッセージ数が特定される。消失したメッセージ数が、ある特定の閾値未満である場合は、送信元またはユーザに通知され、消失したメッセージは再送される。一方、消失したメッセージ数が、ある特定の閾値を超えている場合には、問題のサーバは、もはや動作していない可能性が高く、メッセージを再送しても意味がないので、アラートステータスを、コーディネータまたはユーザに送る。

すべてのアクションと、記録およびリプレイされたメッセージは、履歴データベースに保存される。ある特定のサーバでメッセージが消失したことが確認されたら、無効化メッセージ送信モジュールは、消失したメッセージを、そのメッセージを受信しなかったサーバに送信する。そのサーバがデータアプリケーションサーバであった場合、または中央データサーバのうちの１つであった場合には、そのメッセージは、その後、それぞれ中央データサーバおよび計算サーバに渡される。ある特定のサーバでメッセージが消失した場合、その点より後のサーバはいずれも、同じく、そのメッセージを受け取っていないことになるので、このため、無効化フローの終点である計算サーバ以外のサーバに対してリプレイされるときには、メッセージの受け渡しが行われる。ＰＳＰシステムサーバの範囲内で送信されるメッセージは、リプレイされたメッセージを受信したサーバからの標準の無効化フローに従う。

図５を参照して、無効化トラッカシステムは、リプレイされたメッセージのステータスに基づいて通知を送信するために用いることができる通知モジュール５００を有する。メッセージは、消失メッセージがすべてリプレイされたという事実を含むことができる。あるいは、メッセージが数回リプレイされたことを示すメッセージを送信することができる。消失したメッセージ数が、ある特定の閾値を超えている場合には、特定のサーバが現在動作していないことを示す通知を生成することができる。通知は、メール、ＲＳＳ（ウェブフィード・フォーマット）、ＳＭＳなど、適切な通信プラグインを用いて、送信することができる。

同様に、図６は、本発明の報告プロセスについて記載している。無効化トラッカシステムは、アーカイブデータベース６００と、アーカイブモジュール６０２と、統計モジュール６０４と、レポートデータベース６０６と、を有する。

コーディネータモジュールは、レポートの生成を定期的にトリガすることができる。また、レポートの性質は、予め規定されるか、または特定のユーザまたはプロバイダからの要求に応じて構築および生成することができる。レポートの性質は、構成管理モジュールによって特定することができる。アーカイブデータベースは、履歴データベースよりも長期のデータ保存を含むものであり、アーカイブモジュールは、アーカイブデータベースにアクセスして、適切な統計を用いて必要なレポートを作成することができる。

図２〜６をそれぞれ用いて、無効化トラッカシステムにより実行されるプロセスの一部について説明した。図７は、無効化トラッカシステムの全体的概観を示している。種々の要素は、図２〜６に類似の要素がある場合には一致した番号を付しており、また、同じ説明および記載が各要素に適用される。上記のような無効化トラッカシステムは、完全に自動化されており、高度に構成可能である。また、無効化トラッカシステムは分散されており、スケーラブルであるとともに、グローバルなＰＳＰシステムと統合することが可能である。

本発明は、旅行業界で用いられる膨大な量の無効化メッセージを管理するために用いられる。多数のホストをモニタリングすることができ、持続的なデータフローを追跡することができる。以下、幾つかのユースケース例を参照して、本発明の機能性について、さらに明らかにする。図８は、一般的なユースケース図を示している。無効化トラッカ・スーパバイザ８００は、所定の時間範囲および所定のサーバのセットについての、消失した無効化メッセージの全自動での検出およびリプレイを管理する上位モジュールである。無効化トラッカ検出モジュール８０２は、ターゲット無効化コンポーネントのキーロガー・ファイルからのキーを解析することにより、消失した無効化メッセージを特定する。無効化トラッカ・リプレイモジュール８０４は、消失した無効化メッセージを、要求されたターゲットに対して、無効化プロセス８０６によりリプレイする。ユーザ８０８は、種々のモジュールと通信し、また、プロセスのスケジューリングは、スケジューラシステム８１０によって管理される。

以下の具体的なユースケースでは、ユーザまたは無効化トラッカ・スーパバイザ９００は、幾つかのターゲットと通信し、それらターゲットには、無効化メッセージが送信され、受信されるか、または他の処理が実行される。ユーザおよびターゲットという用語は、以下のセクションでは、このように解釈されるものとする。

図９は、すべてのターゲットが動作しており、消失される無効化メッセージがない場合の、ユースケースを示している。無効化トラッカ検出器９０２は、様々なシステムコンポーネント間で送信および受信された無効化メッセージを受け取って、いずれかのメッセージが消失したかチェックする。メッセージが消失した場合には、消失したキーのリストが提供される。解析の時間範囲は予め規定されており、ユーザが、具体的な調査のために無効化トラッカ検出器を用いる。あるいは、自動的に実行されるように、自動チェックをプログラムすることができる。

第１のステップ９０４で、チェックの要求が、ユーザから無効化トラッカ検出器に送られる。この要求は、幾つかの異なる基準に基づくものであり得る。ステップ９０６で、無効化トラッカ検出器は、ソース無効化コンポーネント９０８で、無効化ルートをチェックする。ソース無効化コンポーネントは、ステップ９１０で、該コンポーネントが動作していることを示す。ステップ９１２で、無効化トラッカ検出器は、ソース無効化コンポーネントに対して、特定の時間範囲についてソース無効化リストを構築することを要求し、これがステップ９１４で返される。続いて、無効化トラッカ検出器は、すべてのターゲット無効化コンポーネントの調査を実施する。ターゲット無効化コンポーネントの各々について、以下のステップが実行される。無効化トラッカ検出器は、ステップ９１８で、無効化ルートが動作しているかどうか、ターゲット無効化コンポーネント９１６で確認する。ステップ９２０で、コンポーネントが動作していることを確認する応答が、ターゲット無効化コンポーネントから送信される。無効化トラッカ検出器は、ステップ９２２で、ターゲット無効化コンポーネントからの、特定の時間範囲についてのターゲット無効化リストを要求する。このケースでは、ステップ９２４で、ターゲット無効化コンポーネント９１６は、消失した無効化メッセージがないことを確認する。このようにして、すべてのターゲット無効化コンポーネントがチェックされた後に、無効化トラッカ検出器は、ステップ９２６で、消失したメッセージがあるかどうか判断する。このケースでは、消失したメッセージはないので、無効化トラッカ検出器は、ステップ９２８で、消失したキーがないことをユーザに伝える。ターゲット無効化メッセージのリストは、要求された無効化システムコンポーネントにより所定の時間範囲でログ記録された論理キーに基づいて構築される。リスト自体は、要求された無効化システムで所定の時間についてログ記録された論理キーを含むものである。ステップ９２６は、サーバと宛先無効化システムコンポーネントによりログ記録されたキーのリストが比較される比較ステップを含んでいる。

次に図１０を参照すると、このユースケースは、ターゲットは動作しているが、無効化メッセージが消失する場合に関するものである。ステップ９０４、９０６、９１０、９１２、９１４、９１８、９２０、９２２は、図９で説明したように実行される。ただし、このケースでは、ターゲット無効化コンポーネントのうち１つ以上からメッセージが消失している。従って、ステップ１０００で、消失した無効化メッセージが検出されたという表示が生成される。ステップ１００２で、消失したメッセージのチェックにより、各サーバで消失したキーが特定され、次にステップ１００４で、このことをユーザに伝える。

次に図１１を参照すると、このユースケースは、動作していないターゲットがある場合に関するものである。前述の例と同様に、ステップ９０４、９０６、９１０、９１２、９１４、９１８は上記のように実行される。ターゲット無効化コンポーネントが動作していないので、無効化トラッカ検出器は、ステップ１１００で、ターゲットが動作していないことを確認する。ステップ１１０２で、ユーザは、特定のターゲット無効化コンポーネントが、非動作状態にあって、メッセージを受信していないことを通知される。

図１２は、ソース無効化コンポーネントが動作してない場合のユースケースに関するものである。ステップ９０４および９０６は、上記のように実行される。ソース無効化コンポーネントが動作していないので、無効化トラッカ検出器は、ステップ１２００で、該コンポーネントが動作してないことを通知される。次にステップ１２０２で、このことがユーザに伝えられる。

図１３は、幾つかの無効化メッセージが消失するが、ただし、その数が上述の所定の閾値に達していない場合のユースケースにも関するものである。また、このユースケースは、特定のターゲットで反復して消失した無効化メッセージがない状況に関する。このケースでは、ユーザまたは無効化トラッカ・スーパバイザ９００は、無効化トラッカ・リプレイモジュール１３００および無効化プロセス１３０２と通信する。ユーザは、ステップ１３０６で、リプレイされるべき無効化メッセージのリストを、無効化トラッカ・リプレイモジュール１３００に送信する。閾値（これは、特定のターゲットにリプレイすることができる無効化メッセージの最大数に関連する）、および閾値が測定される遅延が、ユーザにより決定される。各ターゲットに対して既にリプレイされたメッセージのリストは最新のものであり、このことは、ステップ１３０６で提供されるリスト内にあるのは、現時点で処理される消失メッセージのみであること意味する。無効化トラッカ・リプレイモジュールは、ユーザにより、または監視プロセスのスーパバイザにより、制御することができる。リプレイ用メッセージのリストは、反復しない消失メッセージ、および特定のターゲットに到達しなかったメッセージであって閾値に達していないもののみ、含むものでなければならない。反復しない消失メッセージはいずれも、無効化メッセージが送信されるタイミングに基づいて、ユーザにより設定された遅延を伴って、リプレイされる。典型的な遅延は、１秒程度である。リプレイされる情報量を保護するため、システムは、各ターゲットについてのメッセージ数が閾値に達した場合、または所定の時間範囲の間にメッセージが既にリプレイされている場合には、無効化メッセージをリプレイしない。閾値に達している状況では、アラームを発して、これを、電子メールなどの適切な手段によりユーザに送信する。

図１３に戻って、ステップ１３０８は、論理キーをフィルタリングするためのステップに関する。フィルタリングにより、所与のメッセージリストから、ある特定のターゲットについて、無効化すべき論理キーを決定する。ターゲットでは閾値に達しておらず、また、反復して消失した無効化メッセージはないので、フィルタリングにより除外されるキーはない。従って、リスト内のすべてのキーは、リプレイできる状態にあるものとして、マークが付される。消失した無効化メッセージの論理キーのリストが、ステップ１３１０で、無効化プロセスに送られる。同時に、ステップ１３１２で、リプレイされたキーのリストが、保存されるとともに、ユーザに伝えられる。

図１４のユースケースは、少なくとも１つのターゲットにおいて、消失した無効化メッセージの数が閾値に達しているか、または超えている場合に関する。ステップ１３０６は、上記のように実行される。ステップ１４００で、フィルタリングを適用する。このケースでは、少なくとも１つのターゲットにおいて、消失した無効化メッセージの数が閾値に達しているか、または超えているので、それらの無効化メッセージの論理キーはすべて、フィルタリングにより除外される。従って、システムは、無効化メッセージをリプレイしない。代わりに、ステップ１４０２で、消失したメッセージは、それらをリプレイするには多すぎることを示すメッセージが、ユーザに送信される。

図１５は、ある特定のターゲットにおいて、反復して消失した無効化メッセージがある場合のユースケースに関する。ステップ１３０６は、上記のように実行される。ステップ１５００で、無効化メッセージのリストにフィルタリングを適用する。このケースでは、リストに幾つかの反復するエラーが含まれる。これらは、ステップ１５００で、フィルタリングにより除外され、ステップ１５０２で、反復して消失したメッセージについてのアラームを生成する。リストにある他のメッセージは、ステップ１５０４で、無効化プロセスに送られて、問題のターゲットに対してリプレイされる。ステップ１５０６で、ユーザは、リプレイされたメッセージについて通知され、それらを保存することができる。

図１６は、複数のターゲットで消失した無効化メッセージがある場合のユースケースを開示している。メッセージ１３０６が上述のように送信され、ステップ１６００で、フィルタリングが適用される。フィルタリングにより、ボックス１（ターゲット１）において消失したメッセージが多すぎることが確認され、ステップ１６０２で、アラームメッセージが生成される。さらに、ステップ１６０４で、フィルタリングにより、ボックス２（ターゲット２）に、複数の反復して消失したメッセージがあることが確認される。次にステップ１６０６で、無効化トラッカ・リプレイモジュールは、無効化プロセス１３０２によってリプレイされるべきメッセージのリストを生成する。ステップ１６０６では、ボックス１に対してリプレイするためのメッセージは含まれず、ボックス２に対するメッセージは、反復しない消失キーに関するもののみであり、そして他のすべてのボックス（ターゲット）に対しては、消失したキーがすべてリプレイされる。ステップ１６０８で、ユーザは、リプレイされたメッセージを通知されるので、それらを保存することができる。

図１７は、無効化トラッカ・スーパバイザ１７００に関わるユースケースに関する。プロセスはスケジューラシステム１７０２により調整されて、定期的にプロセスが実行される。システムは、さらに、無効化トラッカ検出器９０２および無効化トラッカ・リプレイモジュール１３００を用いる。チェックされるべきシステムコンポーネントの時間範囲およびリストが生成され、無効化トラッカ・リプレイモジュールは、非アクティブ化される。消失したメッセージがある場合には、消失した無効化メッセージのリストが、プロセスの結果として生成される。このユースケースは、無効化メッセージフローを監視するプロセスであって、完全に自動化されたプロセスについて説明するものである。消失した無効化メッセージを含むレポートを生成することができる。第１のステップ１７０４で、システムのスケジューラは、ある特定の時間範囲について、無効化メッセージのチェック要求を生成する。ステップ１７０６で、無効化トラッカ・スーパバイザは、所定の期間にわたる無効化フローのグローバルなチェックを、無効化トラッカ検出器に要求する。無効化トラッカ検出器は、ステップ１７０８で、キーまたは消失したメッセージを特定して、それらをリストで返す。

図１８は、無効化トラッカ・スーパバイザにより自動リプレイを発生させる場合のユースケースを示している。ステップ１７０４、１７０６、１７０８は、上記のように進められる。このユースケースは、無効化メッセージフローを監視するプロセスであって、スケジューラシステムによりスケジューリングされ、完全に自動化されたプロセスについて説明するものである。レポートが生成され、反復するエラーの場合には、ユーザに送るためのアラームを、無効化トラッカ・リプレイモジュールにより生成することができる。監視プロセスは、無効化トラッカ検出器および無効化トラッカ・リプレイモジュールのユースケースで既に説明した機能を用いる。ステップ１８００で、リプレイ用無効化メッセージのリストが、無効化トラッカ・スーパバイザから無効化トラッカ・リプレイモジュールに送信される。反復しない無効化メッセージのみが、リプレイされる。メッセージがリプレイされたことの確認が、ステップ１８０２で、無効化トラッカ・スーパバイザに送信され、ステップ１８０４で、ユーザに送信される。

機能エンティティならびにプロセス自体の一部またはすべてを、ソフトウェア、またはソフトウェアも使用できる１つ以上のモジュールおよび／もしくはデバイス、またはそれらの組み合わせで実現することができることは、当業者であれば理解できるであろう。ソフトウェアは、任意の適切なコンピュータまたは他のマシンで作動させることができる。本発明の動作は、無効化メッセージをモニタリングして再送するなど、必要に応じて、数多くの変形が提供される。

システムならびに方法は、本発明の様々なステップおよび機能を実行するように構成されたコンピュータなど、特定のマシン上で動作する。本発明は、さらに、数多くの変形に関するものであり、それには、キーロギングデータをモニタリングし、これを用いてメッセージを再送またはリプレイする機能が含まれる。

本発明について、旅行環境における無効化メッセージの使用に関連して説明した。しかしながら、本発明を他の環境に適用することができることは理解されるであろう。本発明は、当然のことながら、請求項で規定される発明が対象とする範囲から逸脱することなく様々に変更することができる。

Claims (15)

1. プライシング／ショッピングプラットフォームのキャッシュアーキテクチャにおいてメッセージを追跡するための無効化トラッカシステムであって、前記キャッシュアーキテクチャは複数のレベルを含み、各レベルは１つまたは複数のサーバを有し、前記キャッシュアーキテクチャ内のすべてのサーバに無効化メッセージを送信するために、あるレベルから別のレベルへと無効化メッセージが伝えられ、また、当該無効化トラッカシステムは、前記キャッシュアーキテクチャ内のサーバに伝えるべきデータをプロバイダ・データベースから受信し、当該無効化トラッカシステムは、
   前記キャッシュアーキテクチャ内のサーバに伝えられたすべての無効化メッセージを記録することで、送信済み無効化メッセージのセットを形成するための、記録モジュールと、
   無効化メッセージが伝えられるサーバの順に、前記キャッシュアーキテクチャ内の各サーバで受信された無効化メッセージを確認し、これを前記送信済み無効化メッセージのセットと比較することで、１つまたは複数の未送達の無効化メッセージおよび前記無効化メッセージが消失した１つまたは複数のサーバを特定するための、解析モジュールと、
   前記特定された１つまたは複数の未送達の無効化メッセージを、前記特定されたサーバから無効化メッセージが伝えられるべき１つまたは複数のサーバに再送するための、リプレイモジュールと、を備えるシステム。
2. 前記リプレイモジュールは、所定の条件が満たされたことに基づいて、無効化メッセージを再送する、請求項１に記載のシステム。
3. 前記所定の条件には、消失した無効化メッセージの数が閾値未満であることが含まれる、請求項２に記載のシステム。
4. 未送達の無効化メッセージの通知を作成して、ユーザに伝えるための、通知モジュールをさらに備える、請求項１ないし３のいずれか１項に記載のシステム。
5. レポートを作成して、該レポートをユーザに伝えるための、報告モジュールをさらに備える、請求項１ないし４のいずれか１項に記載のシステム。
6. 当該無効化トラッカシステムは、未送達の無効化メッセージの自動検索を制御するための、スーパバイザモジュールをさらに備える、請求項１ないし５のいずれか１項に記載のシステム。
7. 当該無効化トラッカシステムは、前記キャッシュアーキテクチャの設定およびトポグラフィに関する情報を保存する構成管理モジュールをさらに備える、請求項１ないし６のいずれか１項に記載のシステム。
8. プライシング／ショッピングプラットフォームのキャッシュアーキテクチャにおいてメッセージを追跡する方法であって、前記キャッシュアーキテクチャは複数のレベルを含み、各レベルは１つまたは複数のサーバを有し、前記キャッシュアーキテクチャ内のすべてのサーバに無効化メッセージを送信するために、あるレベルから別のレベルへと無効化メッセージが伝えられ、また、それらのメッセージは、前記キャッシュアーキテクチャ内のサーバに伝えるべきデータをプロバイダ・データベースから受信する無効化トラッカシステムによって追跡され、当該方法は、
   前記キャッシュアーキテクチャ内のサーバに伝えられたすべての無効化メッセージを、コンピュータによって記録することで、送信済み無効化メッセージのセットを形成することと、
   無効化メッセージが伝えられるサーバの順に、前記キャッシュアーキテクチャ内の各サーバで受信された無効化メッセージを、コンピュータ内の検出器によって確認し、これを前記送信済み無効化メッセージのセットと比較することで、１つまたは複数の未送達の無効化メッセージおよび前記無効化メッセージが消失した１つまたは複数のサーバを特定することと、
   前記特定された１つまたは複数の未送達の無効化メッセージを、前記特定されたサーバから無効化メッセージが伝えられるべき１つまたは複数のサーバに、メッセージングシステムによって再送することと、を含む、方法。
9. 無効化メッセージをリプレイすることは、所定の条件に基づいている、請求項８に記載の方法。
10. 前記所定の条件には、消失した無効化メッセージの数が閾値未満であることが含まれる、請求項９に記載の方法。
11. 通知モジュールによって、未送達の無効化メッセージの通知を作成して、ユーザに伝えるステップをさらに含む、請求項８ないし１０のいずれか１項に記載の方法。
12. 報告モジュールによって、レポートを作成して、該レポートをユーザに伝えるステップをさらに含む、請求項８ないし１１のいずれか１項に記載の方法。
13. スーパバイザモジュールによって、未送達の無効化メッセージの自動検索を制御することをさらに含む、請求項８ないし１２のいずれか１項に記載の方法。
14. 構成管理モジュールによって、前記キャッシュアーキテクチャの設定およびトポグラフィに関する情報を保存することをさらに含む、請求項８ないし１３のいずれか１項に記載の方法。
15. コンピュータプログラムであって、該コンピュータプログラムがコンピュータシステム上で実行されることで、請求項８ないし１４のいずれか１項に記載の方法のステップを実行するための命令を含む、コンピュータプログラム。

Images