本開示は、一般に、待ち時間を最小化し、メモリ動作の数を減らすことができるデータストリームのリアルタイム処理のためのシステムおよび方法に向けられている。例えば、いくつかの実施形態では、開示されたシステムは、応答時間およびメモリ使用率を低減するために、複雑度の低い関数でアクセスされるように構成された蓄積状態変数を使用することができる。さらに、開示されたシステムおよび方法は、結論の精度を改善する予測モデルを使用して、過去の傾向および複数の関連するイベントを処理することができる。そのような実施形態では、複数の予測モデルは入力として複数の状態変数(複数の考慮事項をカバーする)を使用して、履歴データと複数のデータセットの両方に基づいてより正確な決定を取得することができる。例えば、電子決済の不正行為の検出に使用される場合、開示されたシステムは、複数の状態変数を使用して、トランザクション頻度、トランザクション金額、トランザクション場所、トランザクション業者、またはトランザクション通貨などの変数を独立して監視することができる。このように多様な考慮事項があるが、複雑度の低い動作に基づく迅速な対応により、不正行為の結論と計算は非常に正確になり得る。
さらに、開示されたシステムおよび方法は、リアルタイム処理性能を強化するために、絶対決定の代わりに差分計算を使用するインクリメンタルアーキテクチャを採用することができる。そのような実施形態では、差分計算を採用することにより、ハードウェア要件を低減し、応答の待ち時間を最小限に抑えることができる。例えば、開示されたシステムは、変数を独立して迅速に解析するために、単純な差分論理および並列化されたアーキテクチャで実装され得る。このような配置は、リアルタイムで効率的なデータ処理を容易にすることにより、コンピュータの動作と機能を向上させる。
さらに、開示されたシステムおよび方法は、各イベントを考慮するために必要な計算の数を制限することによって、リアルタイムデータストリーム処理のためのハードウェア要件を緩和することができる。例えば、データストリームの過去の傾向を考慮するために複数の計算を実行する代わりに、開示されたシステムおよび方法は、データストリームの各イベントに対して2つの計算のみを実行するように構成することができ、1つはイベントが発生したとき、もう1つはイベントが期限切れになったときである。差分アーキテクチャにより、開示されたシステムは、各イベントの計算数を制限し、システムの複雑度を軽減し、データストリームの監視に充てられるコンピュータリソースを最小限に抑えることができる。
あるいは、またはさらに、開示されたシステムおよび方法は、履歴情報に基づく連続計算を回避することによって計算要件を低減することができる。変数を絶えずまたは定期的に計算して予測を生成する代わりに、開示されたシステムおよび方法では、データストリーム内の関連するイベント(すなわち、トリガイベント)が受信されたときにのみ計算をトリガすることができる。イベントが受信されたときにのみ計算エンジンを使用するこのアプローチは、リソースを節約し、ハードウェアの使用に関連する技術的な問題を解決する。例えば、疑わしい行為または不正行為を特定することを目的とする実施形態は、コンピュータの使用率を低減するために、減衰関数および定期的な計算を適用する代わりに、トリガイベントを受信したときにのみ「ウェイクアップ」または関与するように構成され得る。さらに、リアルタイムで反応することができる動的状態変数を使用することによって、開示されたシステムおよび方法の計算は、メモリ使用率を最小限に抑えることができる。そのような実施形態では、開示されたシステムおよび方法は、イベントが受信されるかまたは期限切れになるとすぐに、変数を迅速に更新することができる。状態変数を更新するためのこのような配置は、スライディング間隔および定期的な計算に関連する動作を減らす可能性があるため、待ち時間を最小限に抑えることができる。
さらに、開示されたシステムおよび方法は、データストリームの複雑で長期的な解析を処理するのに非常に適している可能性がある。データストリームの過去の傾向を処理する場合、リアルタイム処理システムは、特に複雑な計算を必要とする長い過去の傾向の解析において、長い待ち時間またはパフォーマンスの問題に直面する可能性がある。しかし、開示されたシステムおよび方法では、複雑度が低く、アーキテクチャが異なる状態変数を使用することで、技術的な問題を解決できる可能性がある。リアルタイム解析に使用される変数と関数を構成して時間の複雑度を低くすると、解析された傾向に依存しない応答時間を有するシステムが得られる可能性がある。実際、開示されたシステムおよび方法のいくつかの実装では、変数および関数は、過去の傾向項に関係なく、処理要求への迅速な応答を決定する均一なO(1)複雑度を有するように構成され得る。したがって、開示された方法およびシステムのいくつかの実施形態では、状態変数のデータ構造を複雑度の低い演算器でアクセスできるように配置することにより、履歴解析の複雑度に関係なく、着信データストリームのイベントをわずか数ミリ秒で処理することができる。
開示されたシステムおよび方法のいくつかの実施形態はまた、処理されたデータを格納するために必要なハードウェアを最小化することによって、リアルタイムデータストリーム監視の技術分野を改善することができる。例えば、いくつかの実施形態では、開示された方法は、古いデータを除去しながら解析されたデータの単一のコピーを格納するように構成することができ、システムに必要なメモリ構造を単純化する。あるいは、またはさらに、開示されたシステムおよび方法は、リアルタイム処理用に調整されたメモリストレージアーキテクチャを使用することができる。例えば、開示されたシステムは、予測および/または将来の計算に必要な記憶空間を最小化しながら、記憶されたデータを効率的に処理するために、ファーストインおよびファーストアウトレジスタ、または同様のメモリ構造を含むことができる。さらに、開示されたシステムおよび方法のいくつかの実施形態では、データストリームに関連する計算および決定は、アクセス待ち時間およびメモリ使用率を最小化するために、単一の物理ディスクまたは仮想ディスクに格納され得る。
さらに、開示されたシステムおよび方法は、モデルを単純化し、メモリ使用率を低減するために時間ギャップが追跡されない実施形態を含むことができる。データストリームで解析された各イベントの時刻を追跡する代わりに、開示された方法では、時間減衰関数の時間ギャップは保存されず、むしろ、イベントとエントリ時刻のみが、バイナリ関数として、状態変数へのデータストリーム内のイベントの影響を考慮するかどうかに使用される。
さらに、開示されたシステムおよび方法は、オンライン実装とオフライン実装との間で一貫した結果を生成するように構成され得る。オフライン実装は、外部のネットワークまたはドメインに接続せずに、ローカルデバイスまたはシステム内で実行される。オフライン動作でのリアルタイムキャプチャ用のモデルおよび/またはプロトコルのテストまたは実装は、より簡素でより高速になり得る。例えば、オフラインの実装では、ユーザが解析またはイベントキャプチャモデルのトレーニング用のデータを完全に制御できるため、情報とデータフローの管理がより簡素になり得る。さらに、オフラインの実装では、ユーザは通常、ローカルシステム内で他のモジュールをすばやく統合および/または非アクティブ化することができる。しかし、オフライン実装はロックされている可能性があり、トレーニング済みモデルをエクスポートできない。さらに、オフライン実装では、SQLサービスなどの個別のストレージまたは処理機能を設定する必要がある。対照的に、オンライン実装はネットワーク化されたデバイスで実行され、システムはシステムの他の要素によって生成されたリアルタイムデータを組み込むことができる。例えば、オンライン実装は、リアルタイムのクライアント情報ストリームに接続されたクラウドサービスまたは「ライブ」システム内で実行することができる。オンライン実装は柔軟であり、ユーザは様々な種類のソフトウェアやトレーニング情報を試すことができる。オンライン実装では、専用のコンピュータハードウェアの要件がなくなる場合もある。オフライン実装とオンライン実装の間に一貫性があるため、開発者は実装に新しい特徴をシームレスに統合し、保護された環境で開発し、より高速な反復で問題を修正することができる。開示されたシステムおよび方法は、一貫したオフラインおよびオンライン移行を容易にすることができる。
例えば、開示されたシステムは、データストリームをオフラインおよびオンラインで解析するときに、同様の、または実質的に同様の結果を生成することができる。開示された方法は、オンラインアプリケーションでシームレスに使用できる予測モデルをオフラインで開発およびトレーニングするように構成可能であり得る。システムのオフライン動作とオンライン動作の間に一貫性があると、モデルの構築とモデルの実装が容易になり得る。開示されたシステムおよび方法が交換可能に実行されることにより、開示されたシステムおよび方法は、予測モデルのオフラインおよびオンライン性能の間の非互換性の技術的問題を解決する。
開示されたシステムおよび方法はまた、リアルタイムでマルチソース情報を処理することの技術的問題を解決することができる。例えば、開示されたシステムは、データが処理される前にデータを正規化する特定の場所またはデータ修飾子にフィルタを含むことができる。そのような実施形態では、開示された方法は、処理する必要がないか、またはユーザが必要とするカテゴリの外にあるイベントを識別するために、予めコード化されたフィルタによってデータストリームをスクリーニングすることを含むことができる。このようなフィルタは、後のリアルタイム処理を容易にするために、ドメインまたはサーバー間のインターフェースに配置され得る。
いくつかの実装形態では、開示されたシステムおよび方法は、自動化された電子決済の不正行為検出の技術分野を改善することができる。例えば、開示されたシステムおよび方法は、ユーザが短時間で高頻度トランザクションを実行するときにキャプチャするためのデータトランザクションを伴うデータストリームに適用可能であり得る。そのようなアプリケーションの場合、開示されたシステムおよび方法は、トランザクション情報をリアルタイムで処理し、トランザクションの頻度、発信元、および量を迅速かつ正確に計算することができる。さらに、そのようなアプリケーションの場合、開示されたシステムおよび方法は、異なるソースからのデータストリームに組み込むことができる安定したスケーラブルな解析のためのプラットフォームを提供することができる。
次に、開示された実施形態を詳細に参照し、その例を添付の図面に示す。
図1は、開示された実施形態と一致する、例示的なシステム100のブロック図である。システム100では、ストリーミングサービスまたはオンライン小売業者などのサービスプロバイダ(図示せず)は、データストリームをリアルタイムで処理して、例えば、異常な行為または疑わしい振る舞いを識別し、アラートを生成することができる。システム100は、ストリーム演算器110、リアルタイム状態計算器120、およびクライアント要求インターフェース130を含むことができるサービスシステム105を含むことができる。システム100は、オンラインリソース140、クライアントデバイス150、サードパーティシステム160、クライアントシステム190、およびデータベース180をさらに含むことができる。いくつかの実施形態では、図1に示すように、システム100の構成要素は、ネットワーク170に接続され得る。しかし、他の実施形態では、システム100の構成要素は、ネットワーク170なしで、互いに直接接続されてもよい。例えば、データベース180は、サービスシステム105に直接結合されてもよい。
オンラインリソース140は、ウェブサイトホスティング、ネットワーキング、クラウド、またはバックアップサービスのプロバイダなどのエンティティによって提供される1つまたは複数のサーバーまたはストレージサービスを含むことができる。いくつかの実施形態では、オンラインリソース140は、認証サービス、ドメインネームシステム(DNS)、またはランディングページのためのウェブページを格納するホスティングサービスまたはサーバーに関連付けられ得る。他の実施形態では、オンラインリソース140は、クラウドコンピューティングサービスに関連付けられ得る。さらに他の実施形態では、オンラインリソース140は、例えば、アップルプッシュ通知サービス、Azureモバイルサービス、またはグーグルクラウドメッセージングなどのメッセージングサービスに関連付けることができる。そのような実施形態では、オンラインリソース140は、デジタル権利管理の処理など、開示された実施形態の機能に関連するメッセージおよび通知の配信を処理することができる。
クライアントデバイス150は、開示された実施形態と一致する1つまたは複数の動作を実行するように構成された1つまたは複数のコンピューティングデバイスを含むことができる。例えば、クライアントデバイス150は、デスクトップコンピュータ、ラップトップ、サーバー、モバイルデバイス(例えば、タブレット、スマートフォンなど)、セットトップボックス、ゲームデバイス、ウェアラブルコンピューティングデバイス、またはコンピューティングデバイスの他のタイプを含むことができる。クライアントデバイス150は、以下に説明する機能を実施するための動作を実行するために、クライアントデバイス150に含まれるメモリなどのメモリに格納されたソフトウェア命令を実行するように構成された1つまたは複数のプロセッサを含むことができる。クライアントデバイス150は、有線および/または無線通信用に構成することができ、プロセッサによって実行されると、インターネット関連通信(例えば、TCP/IP)およびコンテンツ表示プロセスを実行するソフトウェアを含むことができる。例えば、クライアントデバイス150は、クライアントデバイス150に含まれるか、またはそれに接続されたディスプレイ装置上のコンテンツを含むインターフェースを生成および表示するブラウザソフトウェアを実行することができる。クライアントデバイス150は、クライアントデバイス150がネットワーク170を介して構成要素と通信することを可能にするアプリケーションを実行し、クライアントデバイス150に含まれるディスプレイ装置を介してインターフェースでコンテンツを生成および表示することができる。
いくつかの実施形態では、図6に関連してさらに開示するように、クライアントデバイス150は、サービスシステム105と相互作用するように特別に構成されたアプリケーションを実行することができる。さらに、クライアントデバイス150は、1つまたは複数のアカウントを格納することができる。例えば、クライアントデバイス150は、ユーザ識別、パスワード、場所、および電子決済情報を含む、ユーザアカウントに関する情報を格納することができる。
開示された実施形態は、クライアントデバイス150の特定の構成に限定されない。例えば、クライアントデバイス150は、モバイルアプリケーションを格納および実行して、サービスシステム105および/またはオンラインリソース140によって提供される機能を提供する動作を実行するモバイルデバイスであってもよい。特定の実施形態では、クライアントデバイス150は、GPSロケーションなどのロケーションサービスに関連するソフトウェア命令を実行するように構成され得る。例えば、クライアントデバイス150は、地理的位置を決定し、位置データおよび位置データに対応するタイムスタンプデータを提供するように構成され得る。クライアントデバイス150は、図6に関連してさらに説明される。
データベース180は、サービスシステム105、ストリーム演算器110、リアルタイム状態計算器120、および/またはクライアント要求インターフェース130にクライアントデバイス150とのトランザクションを実行するためのデータを提供することと一致する動作を実行するための適切なソフトウェアで構成された1つまたは複数のコンピューティングデバイスを含むことができる。データベース180は、例えば、Oracle(商標)データベース、Sybase(登録商標)データベース、または他のリレーショナルデータベース、またはHadoop(商標)シーケンスファイル、HBase(商標)、またはCassandra(商標)などの非リレーショナルデータベースを含むことができる。データベース180は、データベースのメモリデバイスに格納されたデータの要求を受信および処理し、データベースからデータを提供するように構成されたコンピューティング構成要素(例えば、データベース管理システム、データベースサーバーなど)を含むことができる。
データベース180は別々に示されているが、いくつかの実施形態では、データベース180は、サービスシステム105、ストリーム演算器110、リアルタイム状態計算器120、クライアント要求インターフェース130、およびオンラインリソース140のうちの1つまたは複数に含まれるか、そうでなければそれに関連することができる。
データベース180は、ユーザアカウントおよびユーザプリファレンスに関連するデータを収集および/または維持するように構成され得る。例えば、データベース180は、サービスシステム105のユーザのユーザプロファイルに関する情報を格納することができる。データベース180は、例えば、オンラインリソース140を含む様々なソースからデータを収集することができる。データベース180は、図5に関連して以下でさらに説明される。
サードパーティシステム160は、サービスのプロバイダまたはフルフィルメントセンターなどのサービスシステム105に関連するエンティティによって提供される1つまたは複数のサーバーまたはストレージサービスを含むことができる。サードパーティシステム160は、ネットワーク170を介してシステム100に接続され得るが、他の実施形態では、サードパーティシステム160は、システム100のいくつかの要素との直接接続を含むことができる。さらに、サードパーティシステム160は、サービスシステム105、またはシステム100の他の要素からの情報を提供および/または要求するように構成され得る。いくつかの実施形態では、サードパーティシステム160もネットワーク170に結合され得るが、それらはサービスシステム105のクライアントでなくてもよい。代わりに、サードパーティシステム160は、サービスシステム105のユーザまたはクライアントの情報を含むシステムを含むことができる。例えば、サードパーティシステム160は、不正行為記録および/または不正アカウントの記録を備えた政府サーバーを含むことができ、これらは、サービスシステム105によって不正行為決定を行うために使用され得る。
クライアントシステム190は、ネットワーク170を介してサービスシステム105と通信する1つまたは複数のサーバーまたはストレージサービスを含むことができる。クライアントシステム190は、データストリームをサービスシステム105に供給し、サービスシステム105は、開示されたシステムおよび方法を使用してリアルタイムで処理することができる。例えば、クライアントシステム190は、クレジットカード承認要求および/または注文のイベントを伴うデータストリームを送信することができる。そのような実施形態では、クライアントシステム190から送信されるイベントは、ユーザ情報、場所、トランザクション金額、IPアドレス、および/または通貨を含むことができる。さらに、クライアントシステム190は、ウィンドウズ(登録商標)、macOS(登録商標)、またはLinux(登録商標)オペレーティングシステムを動作させることができる。
クライアントシステム190は、異なる通信プロトコルを使用する複数の異なるシステムを含むことができる。例えば、クライアントシステム190は、異なる地理的位置にあるか、特定の通信チャネルおよび/またはポートを使用するか、あるいは異なる媒体を介して通信することができる。例えば、一部のクライアントシステム190はTCPを使用し、他のクライアントシステム190はUDPを使用する場合がある。したがって、いくつかの実施形態では、サービスシステム105は、データを識別して外れ値にし、正規化規則に従ってデータを正規化するためのフィルタおよびノーマライザを含むことができる。正規化規則は、イベントからのすべてのタイムスタンプをGMTに変換すること、またはすべての金額情報を米ドルに変換することが含むことができる。さらに、いくつかの実施形態では、クライアントシステム190は、サービスシステム105から頻繁に情報を引き出すことができるアグリゲータウェブサイトまたは検索エンジンを含むことができる。あるいは、またはさらに、クライアントシステム190は、eコマースウェブサイトをホストすることができる。いくつかの実施形態では、クライアントシステム190は、クライアントデバイス150にサービスを提供することができる。他の実施形態では、クライアントシステム190およびクライアントデバイス150は、同じユーザによって動作されてもよく、地理的に同じ場所に配置されてもよい。さらに他の実施形態では、クライアントシステム190およびクライアントデバイス150は、互いに独立していてもよい。
一構成では、ストリーム演算器110は、例えば、クライアントシステム190から受信したデータストリームの処理と一致する動作を実行するように構成された1つまたは複数のコンピューティングシステムを含むことができる。いくつかの実施形態では、ストリーム演算器110は、クライアントシステム190および/またはクライアントデバイス150から発注または承認要求を受信することができる。例えば、クライアントシステム190は、購入トランザクションのための支払い情報をデータストリームに提供することができる。ストリーム演算器110は、データストリーム内のイベントをキャプチャし、フィルタリングし、解析し、結論を提供するためのインフラストラクチャおよび構成要素を提供することができる。そのような実施形態では、ストリーム演算器110は、トランザクションを検証/拒否するために、リアルタイムでデータストリームからキーおよび値を抽出することができる。さらに、ストリーム演算器110は、データストリーム内のイベントを解決して、それらをユーザアカウントおよび/またはユーザプリファレンスに関連付けることができる。
いくつかの実施形態では、ストリーム演算器110は、異常を決定し、および/または不正行為を検出するための予測モデルにおける入力として使用することができるデータ構造を生成することができる。例えば、ストリーム演算器110は、データストリーム内の異常なまたは稀なイベントの決定を行うために使用され得るキーと値のペアの2次元配列または行列にデータストリームを配置することができる。そのような実施形態では、図8に関連して以下でさらに説明するように、ストリーム演算器110は、データストリームからキーおよび値を抽出し、イベントキーに基づいてイベントに関連するアカウントを識別することができる。さらに、ストリーム演算器110は、データストリーム内のイベントのリアルタイムデータ処理を容易にするために、データストリーム内の情報に対してフィルタリングまたは正規化機能を実行することができる。ストリーム演算器110は、図2に関連してさらに説明される。
リアルタイム状態計算器120は、データストリーム内のイベントに関連する状態変数を決定または生成するように構成された1つまたは複数のコンピューティングシステムを含むことができる。図14A〜図14Cに関連してさらに説明するように、状態変数は、定期的にまたはトリガイベントに基づいて更新されるように構成され得る。いくつかの実施形態では、リアルタイム状態計算器120によって生成された状態変数は、O(1)の複雑度を有する演算器でアクセス可能に構成され得る。例えば、状態変数は、入力サイズに関係なく一定時間で実行される演算器でアクセスできるように構成することができ、例えば、要素にアクセスするための演算器を備えた配列、プッシュおよびポップメソッドのための演算器を備えた固定サイズのスタック、ならびにエンキューおよびデキューメソッドのための演算器を備えた固定サイズのキューを含む。
いくつかの実施形態では、リアルタイム計算器120は、ストリーム演算器から情報を受信し、それをデータストリーム内の抽出されたキーまたは値に基づいて状態変数に関連付けることができる。例えば、ストリーム演算器110が、イベントが電話番号に関連することを識別した後に、リアルタイム計算器120は、電話番号に関連する1つまたは複数の状態変数を識別して、データを処理し、結論を出すことができる。
リアルタイム状態計算器120は、状態変数に対して累積および差分演算を実行するように構成され得る。さらに、リアルタイム状態計算器120は、変数の過去の傾向を決定するための規則を生成するように構成され得る。例えば、リアルタイム状態計算器120は、状態変数に影響を与えるイベントの有効期限規則を決定するように構成され得る。そのような実施形態では、リアルタイム状態計算器120は、24時間より古いイベントはもはや状態変数に影響を及ぼさず、イベントの影響は24時間後に排除され得ると決定することができる。さらに、リアルタイム状態計算器120はまた、アラートを生成するための規則を識別することができる。例えば、リアルタイム状態計算器120は、トランザクション数のしきい値を決定することができる。状態変数に格納されたトランザクション数がしきい値量を超える場合には、リアルタイム状態計算器120は、異常または潜在的に不正な行為のアラートを生成することができる。
リアルタイム状態計算器120はまた、状態変数にイベントを蓄積するためのハードウェアおよびソフトウェアを含むことができる。例えば、リアルタイム状態計算器120は、新しいイベントを追加するか、または期限切れイベントを削除することによって、状態変数を変更するための動作を実行することができる。いくつかの実施形態では、状態変数の変更は、着信イベントによってのみトリガされる。すなわち、リアルタイム状態計算器120は、計算コストおよびメモリ使用率を最小化するために、関連するイベントによってトリガされたときにのみ状態変数を変更するように構成され得る。
さらに、リアルタイム状態計算器120は、データストリームにおける不正または不規則な振る舞いを決定する予測モデルを生成および/または適用するように構成され得る。リアルタイム状態計算器120は、畳み込みニューラルネットワーク(CNN)またはランダムフォレスト(RF)解析などの人工知能モデルを訓練して、データストリームの異常な振る舞いを識別することができる。いくつかの実施形態では、リアルタイム状態計算器120は、イベントに基づいてステータス変数を更新し、それらを、不規則な振る舞いの確率を返す可能性があるCNNまたはRFモデルの入力として使用することができる。そのような実施形態では、リアルタイム状態計算器120は、モデルから生じる確率がしきい値確率を超えるときにアラートを生成することができる。
いくつかの実施形態では、リアルタイム状態計算器120は、サービスシステム105の動作中にメモリ動作を処理するためのハードウェアおよびソフトウェアを含むことができる。例えば、リアルタイム状態計算器120は、アカウントに関する情報と共に状態変数を格納する記憶装置を含むことができる。さらに、リアルタイム状態計算器120は、メモリ使用率を最小化するメモリ動作を実行するように構成され得る。例えば、リアルタイム状態計算器120は、重複した情報を排除するように、または追加情報のスペースを開くために破棄することができる無関係な記録を識別するように構成された記憶装置を含むことができる。リアルタイム状態計算器120は、図3に関連してさらに説明される。
クライアント要求インターフェース130は、ネットワーク170に接続された他のシステムの要求に応答するための動作を実行する1つまたは複数のコンピューティングシステムを含むことができる。例えば、クライアント要求インターフェース130は、クライアントシステム190がサービスシステム105と対話するために使用することができるアプリケーションプログラミングインターフェース(API)のサポートを提供することができる。クライアント要求インターフェース130は、不正なまたは侵害されたアカウントに関連している場合のトランザクションを防ぐように構成され得る。クライアント要求インターフェース130はまた、クライアント要求を処理するためのハードウェアまたはソフトウェアを含むことができ、これは、承認、在庫要求、および/または発注を含むことができる。
いくつかの実施形態では、クライアント要求インターフェース130は、クライアントデバイス150またはクライアントシステム190の認証機能を実行するプロセッサを含むことができる。例えば、クライアント要求インターフェース130は、クライアントIDおよび/または安全なトークンに基づいて要求を識別することができ、次いで、それは、例えば、リアルタイム状態計算器120によって生成されるアラート通知と比較される。いくつかの実施形態では、クライアント要求インターフェース130は、コンテンツおよびパケットコンテンツを異なるフォーマットで符号化するように構成されたプロセッサを含むことができる。いくつかの実施形態では、クライアント要求インターフェース130は、複数の動作および/またはストリームを同時に処理するための複数のコアプロセッサを含むことができる。例えば、クライアント要求インターフェース130は、複数のクライアントデバイス150の要求を同時に処理するための並列処理ユニットを含むことができる。
いくつかの実施形態では、クライアント要求インターフェース130は、システム100内の他のドメインからの特定の要求を、リアルタイムではなく、バッチで処理するように構成され得る。例えば、クライアントシステム190がアカウントのステータスを要求する場合には、クライアント要求インターフェース130は、格納された処理結果に基づいて問い合わせに応答するように構成され得る。しかし、この応答はリアルタイムで処理されなくてもよく、代わりに、状態変数を確認して予測モデルを実行するためのリソースが利用可能になったときに処理されてもよい。したがって、クライアント要求インターフェース130は、クライアント要求に応答するためにサービスシステム105内の他の要素の現在の容量および帯域幅を監視することができる管理要素を含むことができる。あるいは、またはさらに、クライアント要求インターフェース130は、クライアント要求を処理するための専用ハードウェアを含むことができる。例えば、クライアント要求インターフェース130は、プルクライアント要求を処理するように特別に構成された、単純リスクコンピュータ(SRC)アーキテクチャ、または他の再構成可能なコンピューティングシステムを含むことができる。クライアント要求インターフェース130は、図4に関連してさらに説明される。
図1は、サービスシステム105の異なる構成要素としてのストリーム演算器110、リアルタイム状態計算器120、およびクライアント要求インターフェース130を示している。しかし、ストリーム演算器110、リアルタイム状態計算器120、およびクライアント要求インターフェース130のうちの1つまたは複数は、同じコンピューティングシステムに実装されてもよい。例えば、サービスシステム105のすべての要素は、異なる仮想化モジュールを有する単一のサーバーで具体化されてもよい。あるいは、サービスシステム105は、ストリーム演算器110、リアルタイム状態計算器120、およびクライアント要求インターフェース130の役割を実行するために、異なるモジュールを備えた分散コンピューティングフレームワークで具体化されてもよい。
ネットワーク170は、システム100の構成要素間の通信を提供するように構成された任意のタイプのネットワークであってもよい。例えば、ネットワーク170は、インターネット、ローカルエリアネットワーク、近距離無線通信(NFC)、光コードスキャナ、またはシステム100の構成要素間の情報の送受信を可能にする他の適切な接続など、通信を提供し、情報を交換し、および/または情報の交換を容易にする任意のタイプのネットワーク(インフラストラクチャを含む)であってもよい。他の実施形態では、システム100の1つまたは複数の構成要素は、専用の通信リンクを介して直接通信することができる。さらに他の実施形態では、ネットワーク170は、例えば1つまたは複数のネットワークを編成する複数のネットワークを含むことができる。
システム100の機能的構成要素の構成および境界は、説明の便宜上、本明細書で定義されていることを理解されたい。指定された機能とその関係が適切に実行される限り、代替的な境界を定義することができる。代替案(本明細書に記載されているものの同等物、拡張、変形、偏差などを含む)が明らかになるであろう。そのような代替案は、開示された実施形態の範囲内にある。
図2は、開示された実施形態と一致する、例示的なストリーム演算器110(図1)のブロック図を示す。ストリーム演算器110は、通信デバイス210、ストリームメモリ220、ならびに1つまたは複数のストリームプロセッサ230を含むことができる。ストリームメモリ220は、ストリームプログラム222およびストリームデータ224を含むことができる。ストリームプロセッサ230は、フィルタ/ノーマライザ232、ブローカ234、コンパイラ236、およびタイマー238を含むことができる。
いくつかの実施形態では、ストリーム演算器110は、サーバー、汎用コンピュータ、メインフレームコンピュータ、またはこれらの構成要素の任意の組み合わせの形態をとることができる。他の実施形態では、ストリーム演算器110は、仮想マシンであってもよい。開示された実施形態と一致する他の実施態様も可能である。
通信デバイス210は、上記のデータベース180などの1つまたは複数のデータベース、ならびにシステム100の他の要素と直接またはネットワーク170を介して通信するように構成され得る。特に、通信デバイス210は、クライアントシステム190およびクライアントデバイス150からデータストリームを受信するように構成され得る。さらに、通信デバイス210は、リアルタイム状態計算器120に情報を送信するときに対応する状態変数を決定するために、データベース180からユーザアカウント情報を受信するように、構成することができる。さらに、通信デバイス210は、例えば、リアルタイム状態計算器120およびクライアントデバイス150を含む他の構成要素とも通信するように構成され得る。例えば、通信デバイス210を介して、ストリーム演算器110は、データストリーム内のイベントのキーおよび値をリアルタイム状態計算器120に送信することができる。次に、受信したキーおよびイベントに基づいて、サービスシステム105は、異常な振る舞いを識別するために蓄積状態変数を更新することができる。
通信デバイス210は、例えば、通信デバイス210が、インターネットを介して通信するためのネットワークコントローラおよび/または無線アダプタなどの他の構成要素と通信および/または検出することを可能にする1つまたは複数のデジタルおよび/またはアナログデバイスを含むことができる。開示された実施形態と一致する他の実施態様も可能である。
ストリームメモリ220は、データストリームをリアルタイムで処理するためにストリームプロセッサ230によって使用される命令を格納するように構成された1つまたは複数の記憶装置を含むことができる。例えば、ストリームメモリ220は、ストリームプロセッサ230によって実行されたときに動作を実行することができるストリームプログラム222などのソフトウェア命令を格納することができる。開示された実施形態は、専用のタスクを実行するように構成された別個のプログラムまたはコンピュータに限定されない。例えば、ストリームメモリ220は、ストリーム演算器110の機能を実行する単一のストリームプログラム222を含むことができ、またはストリームプログラム222は複数のプログラムを含むことができる。ストリームメモリ220はまた、処理されたストリームから抽出されたキーと値、および/または過去の傾向を解析するために以前に抽出された情報を格納するために使用されるストリームデータ224を格納することができる。例えば、ストリームデータ224は、以前に抽出されたアカウント情報のコピーを含むことができる。
特定の実施形態では、ストリームメモリ220は、データストリームから情報を抽出し、ユーザ認証タスクを実行し、および/またはデータベース180と対話してユーザアカウントのステータスを決定するプロセスを実行するための命令のセットを格納することができる。特定の実施形態では、ストリームメモリ220は、クライアントシステム190から追加情報を要求するための命令のセットを格納することができる。他の命令も可能である。一般に、命令は、開示された実施形態と一致するプロセスを実行するために、ストリームプロセッサ230によって実行され得る。
いくつかの実施形態では、ストリームプロセッサ230は、限定されないが、インテル(商標)によって製造されたPentium(商標)またはXeon(商標)ファミリ、AMD(商標)によって製造されたTurion(商標)ファミリのマイクロプロセッサ、あるいは他のメーカーの様々なプロセッサなどの、1つまたは複数の公知の処理装置を含むことができる。しかし、他の実施形態では、ストリームプロセッサ230は、本開示と一致する機能を実行するように結合および構成された複数のデバイスであってもよい。例えば、ストリームプロセッサ230は、浮動小数点演算、グラフィックス、信号処理、文字列処理、暗号化またはI/Oインターフェースなどの特定のストリーム演算器110を動作させるようにそれぞれ構成された複数のコプロセッサを含むことができる。
いくつかの実施形態では、ストリームプロセッサ230は、ソフトウェアを実行して、ストリームプロセッサ230に記載されている各構成要素に関連する機能を実行することができる。他の実施形態では、ストリームプロセッサ230の各構成要素は、独立したデバイスであってもよい。そのような実施形態では、各構成要素は、データを具体的に処理するか、またはデータストリームを処理する動作を実行するように構成されたハードウェアデバイスであってもよい。例えば、ストリームプロセッサ230内のフィルタ/ノーマライザ232は、フィールドプログラマブルゲートアレイ(FPGA)であってもよいし、コンパイラ236は、中央処理装置(CPU)であってもよい。他のハードウェアの組み合わせも可能である。さらに他の実施形態では、ハードウェアとソフトウェアの組み合わせを使用して、ストリームプロセッサ230を実装することができる。
フィルタ/ノーマライザ232は、データストリームを処理して、サービスシステム105に関係のないイベントを排除することができる。さらに、フィルタ/ノーマライザ232は、ストリーム演算器110によるさらなる処理のために、データストリーム内のイベントを準備することができる。例えば、フィルタ/ノーマライザ232は、時限動作と無関係である場合のデータストリーム内のイベントを排除することができる。そのような実施形態では、フィルタ/ノーマライザ232は、パスワードの変更またはユーザ名要求に関連するイベントを排除することができるが、購入要求またはトランザクション許可要求などの他のイベントを保持することができる。さらに、フィルタ/ノーマライザ232は、サービスシステム105を特定のアプリケーションに合わせて調整するように構成され得る。例えば、電子取引における不正行為を検出するようにサービスシステム105を構成するユーザは、電子トランザクションに関係のないイベントを排除するようにフィルタ/ノーマライザ232を設定することができる。異なるドメイン間の境界にこのようなフィルタを適用すると、無関係なイベントの必要な処理を最小限に抑えることで、コンピュータの動作を改善することができる。そのような実施形態では、フィルタ/ノーマライザ232は、番号または通貨の識別なしに任意のイベントをフィルタリングするなど、パーサーおよびシンボル識別子を含むことができる。あるいは、またはさらに、フィルタ/ノーマライザ232はまた、データストリーム内のイベントのヘッダ情報に基づくフィルタを含むことができる。例えば、フィルタ/ノーマライザ232は、サービスシステム105に関連する小売業者に関連しないIPアドレスから来るイベントを除外することができる。
いくつかの実施形態では、フィルタ/ノーマライザ232は、リアルタイムのアプリケーション制御TCP/IPトレーサを用いて実装され得る。そのような実施形態では、フィルタ/ノーマライザ232は、リアルタイムTCP/IPスタックデータをネットワーク管理アプリケーションに提供して、ヘッダまたはペイロード特性信号をキャプチャするフィルタをセットアップすることができる。フィルタ/ノーマライザ232は、データストリームに複数のフィルタを同時に適用して、複数のトレースインスタンスを開き、各トレースインスタンスに固有のフィルタを設定して、所望のデータを取得することができる。そのような実施形態では、フィルタ/ノーマライザ232は、データトレースタイプのイベントまたはパケットトレースのために設定され得る。両方の構成で、フィルタ/ノーマライザ232は、TCP/IPスタックのグローバル設定に基づいてリアルタイムのTCP/IPネットワーク監視を提供することができる。また、フィルタ/ノーマライザ232は、失われたまたは破棄されたデータをサービスシステム105の他の要素に格納および通知することができる。
フィルタ/ノーマライザ232はまた、着信イベントを変更して、フォーマットまたはデータ配置を標準化し、ダウンストリーム処理を容易にすることができる。例えば、フィルタ/ノーマライザ232は、データストリーム内のイベントを管理することができるので、フィルタ/ノーマライザ232がそれらを正規化した後に、ブローカ234は、キーおよび値を迅速に認識することができる。そのような実施形態では、フィルタ/ノーマライザ232は、生データを取り、それを処理し、解析をより助長するフォーマットでデータを出力することができる。したがって、フィルタ/ノーマライザ232は、データの強化、フィルタリング、および集約を含む多くの目的を果たすことができる。いくつかの実施形態では、フィルタ/ノーマライザ232は、フィルタリングまたは変換のためにApache Spark(商標)を使用して実装されてもよい。しかし、他の分散メモリ最適化システムもフィルタ/ノーマライザ232に適用可能であり得る。
フィルタ/ノーマライザ232は、後の処理を容易にするために、イベントの特定のカテゴリを変更することができる。例えば、フィルタ/ノーマライザ232は、各イベントに関連するタイムスタンプを正規化して、時間差の計算を単純化し、サービスシステム105の他の要素を単一のクロックで動作させることができる。さらに、リアルタイム状態計算器120による集約タスクを容易にするために、フィルタ/ノーマライザ232は、通貨、識別情報(例えば、ユーザ名および電子メールをクライアントIDに変換する)、データのフォーマット(例えば、.docファイルを.txtに変換する)を標準化することができる。これらの準備タスクにより、リアルタイム情報を処理する際のコンピュータのパフォーマンスを向上させることができる。
いくつかの実施形態では、フィルタ/ノーマライザ232は、入力ストリームを出力ストリームに変換する1つまたは複数の演算器で構成され得る。フィルタ/ノーマライザ232の演算器は、データストリーム内の各イベントを処理して、少なくとも1つの態様を変更し、次に、演算器要件を満たす場合にのみイベントを提出することができる。例えば、データストリーム内のすべてのイベントは、アカウント番号、トランザクション日付、トランザクション時刻、トランザクション価格などの情報を含むように構成することができる。そのような実施形態では、イベントは、以下の4変数の「TransactionRecord」タイプによって表すことができる。
TransactionRecord=
rstring account,
rstring date,
rstring time,
decimal64 price;
ここで、rstringは、文字エンコードがわかっている場合に文字列処理をサポートする生バイトのシーケンスであり、decimal64はIEEE754の10進数の64ビット浮動小数点数である。
フィルタ/ノーマライザ232は、イベントでファイルされたデータのそれぞれを読み取り、それらを演算器と比較して、次に、演算器で入力ストリームに対して動作することによって生成された出力ストリームを生成することができる。一般に、フィルタ/ノーマライザ232の演算器は、入力ストリームからイベントを受信することができ、タプルがフィルタパラメータによって指定された基準を満たしている場合にのみ、イベント(「タプル」としても知られる)を出力ストリームに提出することができる。
いくつかの実施形態では、フィルタ/ノーマライザ232の演算器は、以下のステップを実行することができる。(1)入力データストリームからイベントを受信する、(2)アカウント属性の値が既存の顧客である場合には、イベントを出力ストリームに提出する、(3)入力ストリームからのすべてのイベントが処理されるまで、ステップ1からステップ2を繰り返す。フィルタ/ノーマライザ232の演算器は、異なるタイプのデータストリームで動作を実行し、必要に応じてフォーマットを変換することができる。例えば、いくつかの実施形態では、出力ストリームのタイプは、宣言「stream<Type> OutputStream=Filter(InputStream)」内の入力ストリームによって指定される。フォーマット変換には、テキストファイルをある文字エンコーディングシステムから別の文字エンコーディングシステムに変換するなどのデータコーディング変換、あるいは、オフィスファイル形式の変換、または画像形式と音声ファイル形式の変換などのファイル変換が含まれ得る。さらなるフォーマット変換には、通貨、タイムゾーン、および/またはクライアント識別変換が含まれ得る。しかし、他の実施形態では、宣言がなくてもよく、ストリームのタイプは、ブローカ234またはサービスシステム105の他の要素の要件に基づいて、フィルタ/ノーマライザ232によって変更されてもよい。
ブローカ234は、ストリーム処理ソフトウェアを含むことができる。例えば、いくつかの実施形態では、ストリーム演算器110は、Apache Kafka(登録商標)などの処理プラットフォームを実装することができる。そのような実施形態では、ブローカ234は、処理プラットフォーム上で実行されている1つまたは複数のサーバーを含むことができる。ブローカ234は、フィルタ/ノーマライザ232の前または後にデータストリームを処理し、ブローカ234内のトピックにデータを公開することができる。
そのような実施形態では、ブローカ234は、クライアントシステム190からのデータストリーム内のイベントに来るキー値メッセージを抽出および格納するように構成可能であってもよい。ブローカ234は、データを異なる「トピック」内の異なる「パーティション」に分割することができる。パーティション内で、ブローカ234は、それらのオフセット(パーティション内のメッセージの位置)によってキー値メッセージを順序付け、タイマー238によって決定され得るタイムスタンプと共にインデックス付けされ、格納され得る。
ブローカ234は、ストリームからのデータを消費するJavaアプリケーションを書くことを可能にするストリームAPIで動作することができる。いくつかの実施形態では、ストリームAPIは、ストリームプロセッサ230によって提供され、サービスシステム105の他の要素および/またはクライアントデバイス150などのシステム100の他の要素から命令を受信することができる。そのような実施形態では、ストリームAPIは、ブローカ234を使用して、データのストリームを入力トピックから出力トピックに変換することを可能にすることができる。さらに、ブローカ234は、Apache Apex、Apache Flink、Apache Spark、およびApache Stormなどの外部ストリーム処理システムと連動するように構成可能であってもよい。例えば、ブローカ234は、他のシステムからデータを読み書きするための実際の論理を実装するコネクタを実行する接続APIを使用して、他のシステムとの間でデータをインポート/エクスポートするように構成可能であってもよい。接続APIは、ストリームプロセッサ230によって提供されてもよく、カスタムコネクタを構築するために実装されなければならないプログラミングインターフェースを定義することができる。例えば、接続APIは、何らかのソースシステムまたはアプリケーションからKafkaを実行しているプロセッサ230に継続的にプルするか、あるいはKafkaからクライアントシステム190などの何らかのシンクシステムまたはアプリケーションにプッシュするコネクタを実装することを可能にすることができる。あるいは、またはさらに、ブローカ234は、ストリーム処理ライブラリで動作することができる。ライブラリは、スケーラブルで弾力性があり、完全にフォールトトレラントなステートフルなストリーム処理アプリケーションの開発を可能にすることができる。例えば、ブローカ234はまた、クライアントシステム190、またはシステム100の他の要素から受信したデータストリーム内のイベントを編成および処理するための、フィルタ、マップ、グループ化、ウィンドウ処理、集約、結合、およびテーブルの概念のような高レベルの演算器を含むことができる。それに加えて、またはその代わりに、ブローカ234は、より低レベルの開発アプローチのためにカスタム演算器を実装し、フォールトトレランス動作を提供することができる。
いくつかの実施形態では、ブローカ234は、障害リスクを最小限に抑えるために冗長になるように構成されてもよい。例えば、すべてのトピックのパーティションは、ブローカ234のクラスタ全体に分散されてもよい。さらに、イベントのパーティションは、複数のブローカ234に複製されてもよい。このアーキテクチャにより、フォールトトレラントな方法でデータストリームを配信することができる。
ブローカ234は、イベントを処理するための通常のトピックと圧縮されたトピックとの両方をサポートすることができる。通常のトピックは、保持時間またはスペースバウンドで構成することができる。指定された保持時間より古い記録がある場合、またはパーティションのスペースバウンドを超えた場合には、ブローカ234は古いデータを削除してストレージスペースを解放することができる。例えば、ブローカ234は、ストリームメモリ220と結合されてもよく、期限切れになったイベントを削除するための命令を提供することができる。そのような実施形態では、ブローカ234によって開発されたトピックは、7日の保持時間で構成され得る。しかし、他のタイムウィンドウも可能である。例えば、24時間のタイムウィンドウを、特定のデータストリームまたはストリーム内の特定の変数に対して構成することができる。それに加えて、またはその代わりに、タイムウィンドウは動的であってもよく、過去の傾向に基づいてプログラムされてもよい。例えば、ストリーム演算器110が特定の場所からのトランザクションの流入に気付いた場合には、ストリーム演算器110は、タイムウィンドウを変更してそれを減らし、潜在的な同時攻撃を防ぐことができる。他の実施形態では、トピックを圧縮すると、いくつかの記録は期限切れにならない場合がある。代わりに、ブローカ234は、後のメッセージを同じキーを有する古いメッセージの更新として扱い、キーごとに最新のメッセージを保持することを保証することができる。この変数の蓄積は、コンピュータの使用率を減らすために差分演算を実行する際に有益であり得る。
さらに、システム100の異なる要素は、ストリーム演算器110によってサポートされるAPIを使用してブローカ234と対話することができる。例えば、クライアントデバイス150、クライアントシステム190、および/またはオンラインリソース140は、(1)記録のストリームを公開することを可能にするプロデューサAPI、(2)トピックへのサブスクライブを可能にし、記録のストリームを処理することを可能にするコンシューマAPI、(3)トピックを既存のアプリケーションにリンクすることができる再利用可能なプロデューサAPIおよびコンシューマAPIを実行するコネクタAPI、および/または(4)入力ストリームを出力に変換して結果を生成するストリームAPIを用いて、ブローカ234と対話することができる。いくつかの実施形態では、コンシューマおよびプロデューサAPIは、フィルタ/ノーマライザ232などの他のストリーム処理要素上に構築することができ、Javaのコンシューマおよびプロデューサクライアントのためのリファレンス実装を提供することができる。そのような実施形態では、基礎となるメッセージングプロトコルは、開発者が任意のプログラミング言語で独自のコンシューマまたはプロデューサクライアントを書くために使用できるバイナリプロトコルであってもよい。さらに、そのような実施形態では、APIは、ストリームプロセッサ230によって実行および/またはサポートされ得る。しかし、これらのAPIは、サービスシステム105の他の要素によってホストされてもよく、または例えばオンラインリソース140によってリモートでホストされてもよい。
いくつかの実施形態では、ブローカ234は、キー抽出器235と連携して動作することができ、キー抽出器235は、データストリームから来るイベント内のキーを抽出するように構成されたソフトウェアおよび/またはハードウェアを含むことができる。例えば、ブローカ234は、キー抽出器235によって抽出されたキーに基づいて、異なるトピックのイベントを分類および処理することができる。あるいは、キー抽出器235は、独立した要素としてブローカ234なしで動作することができる。
ストリーム演算器110は、キー/値ペアのメッセージを生成することによって、データストリーム内のイベントを処理することができる。キーは、問い合わせまたは結合の目的で、テーブルおよびトピック(例えば、KSQLまたはKtable)のパーティション分割およびモデリングに使用することができる。キーは、イベントの特性を含むことができる。例えば、キーは、IPアドレス、クライアントID、アカウント番号、地理的位置、またはイベントの他の識別情報が含むことができる。値は、パーティションを決定するためにキーを限定することができる。キー抽出器235は、データストリーム内のイベントからキーを抽出するように構成可能であってもよい。例えば、キー抽出器235は、イベントが関連付けられている記録内のパーティションを決定するためのキーを取得することができる(例えば、トランザクションのタイプ)。対照的に、キーに関連する値は、イベントの実際のペイロード(例えば、トランザクションの値)であり得る。図8に関連してさらに説明するように、データストリーム内のイベントから抽出されたキーは、イベントに関連するアカウントまたはユーザを識別するために関連付けられ得る。
キー抽出器235は、タイムスタンプを抽出されたキーに関連付けながら、イベントから一連のget動作を実行するように構成され得る。Get動作は、オブジェクト情報を取得する動作を含み、「Get(byte [] row)」または「Get(int rowOffset、int rowLength)」などのコンストラクタを含むことができる。get動作では、イベントから抽出する変数タイプを指定することもできる。例えば、フィルタ/ノーマライザ232が入力ストリームを処理し、所望の値のみを有する出力ストリームを生成した後に、キー抽出器235は、ターゲットキーワードをイベント内の情報と照合することによって、イベントからキーを取得または得ることができる。例えば、キー抽出器235は、以下の動作を実行することができる。
//Get data stream store named“datastream”
ReadOnlyDatastream<String,Long>=
streams(“datastream”,QueryableTypes.datastream());
//Fetch values for a key(e.g.,“amount”)for all of the events available
long timeFrom=0;//beginning of time=oldest available
long timeTo=System.currentTimeMillis();//now(in processing−time)
StreamIterator<Long> iterator=
stream.fetch(“amount”,timeFrom,timeTo);
while(iterator.hasNext()){
KeyValue<Long,Long> next=iterator.next();
long Timestamp=next.key;
System.out.println(“Count ‘amount’ @ time”+Timestamp+“is”
+next.value).
キー抽出器235は、予測モデル解析のための、またはステートマシンを開発するためのイベントの順序付けを容易にすることができる。例えば、キー抽出器235によって抽出されたキーは、たとえそれらが複数の場所から来ているとしても、イベントパーティションをセットアップし、イベントを状態変数に関連付けるためにイベントを順序付けするために使用され得る。そのような実施形態では、キー抽出器235は、パーティション内のイベントを順序付けることができるが、トピック内のパーティション間では順序付けられない。さらに、キー抽出器235は、ブローカ234のトピックレベルの構成を実装し、「log.cleaner.enable」などのJavaパラメータを指定して、同じキーでエントリを重複排除することができる。そのような実施形態では、キー抽出器235は、ストリームメモリ220に結合されてもよく、キー抽出器235は、所与のキーの最新のインスタンスのみが関連すると仮定し、キーがヌルでない場合にのみ所与のキーの古い複製を削除することができる。例えば、状態変数はリアルタイム状態計算器120によって更新され得るので、繰り返されるキーを有する古いイベントは保持される必要はなく、スペースを節約するために削除され得る。いくつかの実施形態では、ログ圧縮の形式は、「log.cleaner.delete.retention」プロパティなどのJavaパラメータによって制御することができる。
キー抽出器235は、イベントを分類し、それらの解析を容易にすることができるように、データストリーム内の特定の情報をリアルタイムで識別するための構成要素を提供することができる。
コンパイラ236は、プログラミング言語をコンパイルして、ストリームプロセッサ230でストリームプログラム222を実行するためのソフトウェアまたはハードウェアを含むことができる。コンパイラ236は、プラットフォーム中立のバイトコードを含むクラスファイルを出力することができる。あるいは、またはさらに、コンパイラ236は、特定のハードウェア/オペレーティングシステムの組み合わせのために最適化されたネイティブマシンコードを提供することができる。コンパイラ236は、Javaからバイトコードへのコンパイラを含むことができるが、それは実行時間を改善するために実質的に最適化を実行しなくてもよい。いくつかの実施形態では、コンパイラ236は、クラスファイルをロードし、バイトコードを解釈するか、またはジャストインタイムでそれをマシンコードにコンパイルし、場合によっては動的コンパイルを使用してそれを最適化する仮想マシンを含むことができる。さらに、コンパイラ236は、解釈動作を実行して、ブローカ234動作をセットアップおよび構成することができる。例えば、コンパイラ236は、前処理、字句解析、構文解析、意味解析(構文指向変換)、入力プログラムの中間表現への変換、コード最適化、およびコード生成を実行することができる。コンパイラ236は、効率的な設計を促進し、ソース入力からターゲット出力への正しい変換を促進するフェーズでこれらの動作を実装することができる。
タイマー238は、データストリームを処理するためのハードウェアおよび/またはソフトウェアを含むことができる。例えば、タイマー238は、イベントのタイムスタンプを確立するためのタイミング情報を受信するためのAPI方法を含むことができる。タイマー238は、ストリーム時間または実時間のいずれかを含む、スケジューリングのための異なる時間タイプを決定することができる。いくつかの実施形態では、ストリーム時間は、TimestampExtractorを介してイベントタイムを表すように構成される。あるいは、タイマー238は、絶対時間によってトリガされる実時間を実装することができる。
いくつかの実施形態では、タイマー238は、イベントの定期的なスタンプを有するように動作を実装することができる。例えば、
schedule(1000,PunctuationType.STREAM_TIME,(timestamp)−>{
KeyValueIterator<String,Long> iter=this.kvStream();
while(iter.hasNext()){
KeyValue<String,Long> entry=iter.next();
context.forward(entry.key,entry.value.toString());
}
iter.close();
ストリーム演算器110の構成要素は、ハードウェア、ソフトウェア、または両方の組み合わせで実装され得る。例えば、ストリーム演算器110の1つまたは複数の構成要素は、コンピュータソフトウェアに具体化されたコンピュータ処理命令として実装され得るが、ストリーム演算器110の機能の全部または一部は、専用のハードウェアに実装されてもよい。例えば、GPUおよび/またはFPGAのグループは、ストリームプロセッサ230においてマルチメディアコンテンツを迅速に処理するために使用されてもよい。
ここで図3を参照すると、開示された実施形態と一致する、例示的なリアルタイム状態計算器120(図1)のブロック図が示されている。リアルタイム状態計算器120は、計算器プロセッサ340、計算器メモリ350、および通信デバイス360を含むことができる。いくつかの実施形態では、リアルタイム状態計算器120は、データストリームからキャプチャされたイベントに基づいて状態変数を生成、監視、および更新することができる。さらに、リアルタイム状態計算器120は、対応する状態変数が指定されたしきい値を超えたときに、アカウント対するアラートを生成することができる。リアルタイム状態計算器120は、システム100の他の要素にアラートを伝達することができる。例えば、リアルタイム状態計算器120は、ストリーム演算器110またはクライアント要求インターフェース130にアラート通知を提供することができる。
計算器プロセッサ340は、ストリームプロセッサ230と同様のプロセッサとして具体化することができる。計算器プロセッサ340は、状態変数アキュムレータ348を含むことができる。図3に示すように、いくつかの実施形態では、リアルタイム状態計算器はまた、計算器プロセッサ340とは異なるモジュールであり得る、予測モデル生成器342、不正行為/リスク検出サービス344、およびアカウント識別子346を含むことができる。しかし、他の実施形態では、予測モデル生成器342、不正行為/リスク検出サービス344、およびアカウント識別子346が、計算器プロセッサ340に含まれるか、または実装されてもよい。
予測モデル生成器342は、状態変数に基づいて予測モデルを生成または訓練するためのイベント情報を受信することができる。例えば、予測モデル生成器342は、不正行為または異常な振る舞いをもたらした以前のデータストリームから処理されたデータを受信することができる。この情報を用いて、予測モデル生成器342は、複数の状態変数を使用するモデルを解決して、異常または不正な行為をもたらすデータストリーム内のイベントのグループの可能性を決定することができる。
いくつかの実施形態では、予測モデル生成器342は、新しいイベント情報が複数のデータストリームから受信されているときに更新される機械学習モデルを含むことができる。例えば、図12および図13に関連してさらに説明されるように、予測モデル生成器342は、状態変数が不規則な振る舞いおよび/または不正行為の確率といつ相関するかを決定するためにイベント情報を使用するランダムフォレストまたは畳み込みニューラルネットワークモデルを訓練することができる。
モデルのトレーニングに加えて、予測モデル生成器342は、検証タスクも実行することができる。予測モデル生成器342は、検証の目的で、あるパーセンテージのトレーニングデータ(例えば、以前のデータストリーム内のイベント)を保持することができる。検証ホールドアウトが指定されている場合には、別のプロセスが実行され、検証セットに対してモデルが検証される。したがって、予測モデル生成器342は、初期生成とパラメータ調整の両方を実行することができる。
さらに、予測モデル生成器342は、例えば、トレーニングマイクロサービスのためのモデリングAPIを使用して、モデルへのアクセス方法を確立することができる。マイクロサービスは、トレーニング要求の提出、モデル結果の取得、および/またはジョブの一覧表示に使用することができる。予測モデル生成器342はまた、データと対話するためのユーザインターフェースを提供することができる。
不正行為/リスク検出サービス344は、データストリーム内のイベントに基づいて潜在的な不規則性についてのアラートを送信するためのソフトウェアおよび/またはハードウェアを含むことができる。いくつかの実施形態では、不正行為/リスク検出サービス344は、アラートを積極的に生成および送信しなくてもよい。代わりに、不正行為/リスク検出サービス344は、HTTP REST APIを介してリスクがあるかどうかを検出するための要求を受け入れることができる。そのような実施形態では、図15に関連してさらに説明するように、不正行為/リスク検出サービス344は、受動的であり、アキュムレータ348と非同期され得る。そのような構成は、システム100における異常の検出およびアラートのトリガを容易にする特定の技術的利点を提供する。例えば、HTTP REST API構成では、不正行為/リスク検出サービス344は、異なるイベントの、および異なるドメインからの変数を精査することができる。したがって、支払いトランザクションの不正行為を検出するために、不正行為/リスク検出サービス344は、とりわけ、登録、ログイン、返品、注文、クレジットカード更新、クレジットカード認証に関連する変数を調べることができる。さらに、説明された構成では、不正行為/リスク検出サービス344は、より速い応答を有することができる。不正行為/リスク検出サービス344は、分離された変数を操作することができるので、不正行為/リスク検出サービス344は、変数の計算/更新に遅延または渋滞がある場合でも、データベースから既存の変数を検索することができる。ネットワークの輻輳を克服するこの機能は、不正か/不正ではないかの決定が100ミリ秒未満で発生する必要がある支払いトランザクションの検出に役立つことができる。さらに、不正行為/リスク検出サービス344およびアキュムレータ348を分離することにより、システム100はより堅牢になり得る。そのような実施形態では、不正行為/リスク検出サービス344は、不正行為の識別および要求の送信のためのモデルおよび規則を含むことができる。
他の実施形態では、不正行為/リスク検出サービス344は、状態変数の値を監視し、値がしきい値を超えたときにアラートを生成することができる。例えば、アカウントに関連するトランザクションの量を累積する状態変数を監視する場合、不正行為/リスク検出サービス344は、金額キーに関連する値が10,000ドルを超えるとアラートをトリガすることができる。次に、状態変数がしきい値を超えた場合には、それは、その状態変数に関連するアカウントが危険にさらされていることを意味しており、アラートを生成することができる。あるいは、またはさらに、不正行為/リスク検出サービス344は、予測モデルの結果を監視することができる。予測モデルが、しきい値を超えて(例えば、80%を超える確率で)定義された異常または不正行為の可能性が高い場合は常に、アラート生成器はアカウントに関連するアラートを送信することができる。
いくつかの実施形態では、不正行為/リスク検出サービス344は、計算器プロセッサ340によって計算された状態変数のみに基づいてアラートを生成することができる。しかし、他の実施形態では、不正行為/リスク検出サービス344は、クライアントシステム190から来るトランザクションのストリームを直接利用することができる。次に、すべてのキーについて、不正行為/リスク検出サービス344は、キーに関連する値が指定されたしきい値を超えているかどうかを調べるステップを実行することができる。それに加えて、またはその代わりに、不正行為/リスク検出サービス344は、関連するアカウントとの将来の対話のために記録を更新することができる。例えば、不正行為/リスク検出サービス344は、クライアント要求インターフェース130と対話して、クライアント登録を更新し、危険にさらされたアカウントとの将来の対話を防止することができる。
アカウント識別子346は、データストリーム内のイベントから抽出されたキーをアカウントおよび対応する状態変数に関連付ける動作を実行することができる。アカウント識別子346は、イベントから抽出された1つまたは複数のキーに基づいて、関連するアカウントを導出することができる。さらに、いくつかの実施形態では、固有の情報がキーとして抽出されない場合でも、アカウント識別子346は、イベントのアドレスまたは関連する場所がアカウントとイベントとの間の相関を決定するかどうかを判定することができる。アカウント識別子346は、データベースに問い合わせることによって、イベントキーとアカウントとの間の関係を確立することができる。リアルタイム処理中に高速応答時間を必要とするいくつかの実施形態では、アカウント識別子346は、キーをアカウントと相関させるために非リレーショナルデータベース(NOSQLなど)に問い合わせることができる。それに加えて、またはその代わりに、アカウント識別子346は、イベントにおいて複数のキーを使用して、イベントに関連するアカウントを識別してもよい。例えば、アカウント識別子346は、キーがアカウントを識別するのに不十分である場合であっても、トランザクションの場所、金額、および小売業者のタイプを考慮して、それをアカウントに関連付けることができる。
アキュムレータ348は、データストリーム内のイベントに基づいて状態変数を更新するように構成され得る。さらに、アキュムレータ348は、状態変数内の特定のイベントが期限切れになると、それらからの影響を取り除くことができる。さらに、アキュムレータ348は、新しいイベントに基づいて状態変数を更新するときに、タイマーまたはコールバックを関連付けることができる。例えば、イベントが受信され、ストリーム演算器110(図2)がそれをトリガイベントとして識別し、キーがキー抽出器235によって抽出され、アカウントが識別されると、アキュムレータ348は、イベントに基づいてアカウントに関連する状態変数を変更することができる。例えば、図14A〜図14Cに関連してさらに説明するように、アキュムレータ348は、購入金額を監視している変数にトランザクション金額を蓄積することができる。いくつかの実施形態では、アキュムレータ348は、蓄積された変数を格納し、それらを不正行為/リスク検出サービス344に送信することができる。
アキュムレータ348は、変数を迅速に更新し、それらの複雑度を低く保ち、迅速なアクセスおよび迅速な結論を容易にするように構成され得る。いくつかの実施形態では、アキュムレータ348は、アルゴリズムの実行時間が入力のサイズに依存しないO(1)関数を使用して、状態変数を更新することができる。そのような実施形態では、変数を更新するための均一な実行時間を有することは、待ち時間を最小化することによってシステムの動作を改善することができる。
図3は、計算器プロセッサ340に関連するアキュムレータ348、不正行為/リスク検出サービス344、および予測モデル生成器342を示しているが、いくつかの実施形態では、これらの要素の各々は、別個の構成要素であってもよく、ターゲットアプリケーションに合わせて調整された特定のハードウェアを有してもよい。例えば、予測モデル生成器342はFPGAであってもよく、アキュムレータ348はCPUであってもよい。
計算器メモリ350は、開示された実施形態に関連する動作を実行するために計算器プロセッサ340によって使用される命令を格納するように構成された1つまたは複数の記憶装置を含むことができる。例えば、計算器メモリ350は、計算器プロセッサ340によって実行されたときに動作を実行することができるソフトウェア命令を格納することができる。さらに、計算器メモリ350は、計算器プログラム352(関数およびキー抽出方法を指定することができる)、有効期限規則354(イベントが状態変数に影響を与えないようにする時期を決定する)、およびアカウント情報356(イベントから抽出されたキー、アカウント、および対応する状態変数間の相関関係を含む)を含むことができる。
計算器メモリ350はまた、高速アクセスの個別状態ストレージ358を含むことができる。リアルタイム計算中の待ち時間を最小限に抑え、迅速に結論に到達できるようにするために、個別状態ストレージ358をSRAMで実装することができる。あるいは、またはさらに、個別状態ストレージ358は、他の高速アクセスメモリを使用することができる。例えば、個別状態ストレージ358は、処理ユニットとメモリユニットとの間の通信を容易にするために、ハイブリッドトランザクションおよび解析的処理構成にキャッシュメモリを含むことができる。そのような実施形態では、個別状態ストレージ358は、トランザクションワークロードと解析ワークロードの両方をサポートするために単一のデータベースバックエンドを有するように実装され得る。
個別状態ストレージ358は、データストリーム内のイベントに基づいて生成および更新される状態変数を格納することができる。そのような実施形態では、個別状態ストレージ358は、重複を排除するため、またはトリガイベントがある場合にのみ状態変数へのアクセスを許可するためのネイティブ機能を含むことができる。このような構成では、ハードウェア要件を緩和し、データのコピーを1つだけ維持することで、コンピュータの機能を向上させることができる。したがって、個別ストレージ358は、機能の複雑度を均一に保つので、短期および長期の両方の状態変数に対して高いパフォーマンスを促進することができる。また、計算されたデータポイントは、個別状態ストレージ358に格納されてもよく、メモリ使用率を低減し、ハードウェア使用率を改善することができる。
いくつかの実施形態では、個別状態ストレージ358は、アキュムレータ348によって動作および使用されるように構成可能であってもよい。そのような実施形態では、個別状態ストレージ358は、RocksDBなどのキー値データのための高性能の組み込みデータベースであってもよい。次に、すべてのアキュムレータインスタンスは、同じサーバー内にあるRocksDBデータベースに独自の状態ストアを有することができる。個別状態ストレージ358およびアキュムレータ348は、ローカルアクセスを介して互いに通信することができ、ネットワークアクセスを必要としない。この方法での通信は、ネットワークを介したリモートよりも高速である可能性があり、アキュムレータが組み込みデータベースと通信するのに十分である。いくつかの実施形態では、キー抽出器235は、同じキーを有するイベントをアキュムレータ348の特定のインスタンスに送信するように構成され得る。したがって、個別状態ストレージ358は、特定のキーのイベントを格納することができる。
特定の実施形態では、計算器メモリ350は、状態変数を更新し、O(1)の複雑度を強制するためのプロセスを実行するための命令のセットを格納することができる。例えば、サービスシステム105は、クライアントシステム190からデータストリームを受信することができる。この情報に基づいて、リアルタイム状態計算器120は、変数の状態を決定することができる。計算器メモリ350は、処理された状態変数が時間の複雑度を増加させず、同時に実行されるアルゴリズムで使用できることを検証することができる。例えば、計算器プロセッサ340が、問い合わせ動作、または予測モデルを実行する際に遅延を引き起こすような多次元の変数を出力する場合には、計算器メモリ350は、アルゴリズム全体のO(1)の複雑度を強制するために、平均値またはモードなどの演算を切り捨てたり、演算を行わせたりすることによって変数の複雑度を低減することができる。
ここで図4を参照すると、開示された実施形態と一致する、例示的なクライアント要求インターフェース130(図1)のブロック図が示されている。クライアント要求インターフェース130は、インターフェースメモリ430、インターフェースプロセッサ440、および通信デバイス460を含むことができる。いくつかの実施形態では、クライアント要求インターフェース130は、クライアントシステム190からのトランザクションを処理し、承認されたトランザクションに基づいてユーザアカウント記録を変更する要求を受信するように構成され得る。
インターフェースメモリ430は、クライアントシステム190および/またはクライアントデバイス150からのトランザクション許可要求を処理するための命令を格納するように構成された1つまたは複数の記憶装置を含むことができる。インターフェースメモリ430は、インターフェースプログラム432を含むことができ、これは、クライアントシステム190、および例えば、クライアントデバイス150とサービスシステム105との間の対話をサポートするためのAPI管理命令を含むことができる。
インターフェースメモリ430はまた、トランザクションを受け入れるまたは拒否することに関連することができるアカウントに関する情報を格納するアカウント記録434を含むことができる。例えば、アカウント記録434は、とりわけ、アラート通知、利用可能な資金、およびアカウント設定を含む、サービスシステム105のユーザのファイルおよびデータベースを含むことができる。インターフェースメモリ430は、開示された実施形態に関連する機能を実行するためにインターフェースプロセッサ440によって使用される命令を格納する記憶装置をさらに含むことができる。例えば、インターフェースメモリ430は、インターフェースプロセッサ440によって実行されるときに1つまたは複数の動作を実行することができるソフトウェア命令を格納することができる。
インターフェースプロセッサ440は、ストリームプロセッサ230と同様のプロセッサとして具体化することができる。インターフェースプロセッサ440プロセッサは、クライアント認証器442、APIマネージャ444、およびクライアント登録446を含むことができる。
クライアント認証器442は、クライアントデバイス150またはクライアントシステム190から受信した資格情報(クライアントデバイス150から受信したパスワードまたは生体測定データなど)を特定のユーザアカウントに関連する情報と比較するように構成されたハードウェアまたはソフトウェアで実装することができる。あるいは、またはさらに、クライアント認証器442は、イベントにおいてクライアントIDキーを解決して、ユーザアカウントを識別することができる。例えば、クライアント認証器442は、電子メールアドレスまたは電話番号でキーを識別し、要求しているユーザアカウントを識別するように構成され得る。そのような実施形態では、クライアント認証器442は、暗号化および復号化プロセスを実行して、識別ツールを提供および検証することができる。
APIマネージャ444は、サービスシステム105にアクセスするためにシステム100の他の要素にAPIを提供するための動作を実行するように構成されたハードウェアまたはソフトウェアで実装され得る。APIマネージャ444は、ウェブAPIを作成および公開し、それらの使用ポリシーを実施し、アクセスを制御し、使用統計を収集および解析し、そしてパフォーマンスについて報告することができる。APIマネージャ444はまた、サービスシステム105のためのアプリケーションの開発者をサポートするための機構およびツールを提供することができる。APIマネージャ444は、ゲートウェイの動作を実行し、API要求を受信し、セキュリティポリシーを実施し、サービスシステム105のバックエンド構成要素に要求を渡すことができる。それに加えて、またはその代わりに、APIマネージャ444は、公開ツール、開発者ポータル/API、報告および解析機能、ならびに収益化機能を含むことができる。
クライアント登録446は、新しいクライアントを処理し、それらの登録情報に基づいて、それらが既存のアカウントに関連付けられているかどうかを判定するように構成されたハードウェアまたはソフトウェアで実装され得る。状態変数または過去の傾向に関連付けられていない新しいアカウントからの潜在的な不正行為を防ぐために、クライアント登録446は、抽出されたキーに基づいて、新しいアカウントがサービスシステム105で受け入れられるべきかどうかを決定するために新しいアカウントの解析を実行することができる。
通信デバイス460は、1つまたは複数のデジタルおよび/またはアナログデバイスとして具体化されて、クライアント要求インターフェース130とサービスシステム105の他の要素との間、およびクライアント要求インターフェース130とクライアントデバイス150などのシステム100の他の要素との間の通信を可能にする。
ここで図5を参照すると、開示された実施形態と一致する、例示的なデータベース180(図1)のブロック図が示されている。データベース180は、通信デバイス502と、1つまたは複数のデータベースプロセッサ504と、1つまたは複数のデータベースプログラム512およびデータ514を含むデータベースメモリ510と、を含むことができる。データベース180は、HBase、MongoDB(商標)またはCassandra(商標)などのNoSQLデータベースを含むことができる。あるいは、データベース180は、Oracle、MySQL、およびMicrosoft SQL Serverなどのリレーショナルデータベースを含むことができる。
いくつかの実施形態では、データベース180は、サーバー、汎用コンピュータ、メインフレームコンピュータ、またはこれらの構成要素の任意の組み合わせの形態をとることができる。いくつかの実施形態では、データベース180は、サービスシステム105などのシステム100の他の要素内に含まれる。開示された実施形態と一致する他の実施態様も可能である。
いくつかの実施形態では、データベース180は、非リレーショナルデータベースと組み込みデータベースの両方を含むことができる。例えば、データベース180は、Hbaseなどの非リレーショナルデータベース、およびRocksDB(例えば、キー値ストアデータベース)などの組み込みデータベースを含むことができる。非リレーショナルデータベースは、様々な期間の変数値を格納することができるが、埋め込みデータベースは、アキュムレータ348によって生成されたものなどの状態変数と、期限切れイベント、非期限切れイベント(新しいイベントを含む)などの状態変数に影響を与えるイベントと、を格納することができる。そのような実施形態では、埋め込まれた記録は、演算器に対して局所的であってもよく、最小の待ち時間でキー抽出およびイベントディスパッチを容易にするために100%のデータ局所性を有する。
通信デバイス502は、オンラインリソース140、サービスシステム105、リアルタイム状態計算器120、クライアント要求インターフェース130、および/またはクライアントデバイス150などのシステム100の1つまたは複数の構成要素と通信するように構成され得る。特に、通信デバイス502は、リアルタイム状態計算器120、ストリーム演算器110、およびクライアント要求インターフェース130に、ユーザアカウント情報、ユーザの選好と特権、および/または過去の傾向を提供するように構成され得る。
通信デバイス502は、例えば、計算器メモリ350(図3)、インターフェースメモリ430(図4)、およびストリームメモリ220(図2)を含む他の構成要素とも通信するように構成され得る。通信デバイス502は、通信デバイス210(図2)について上述した形態のいずれかをとることができる。
データベースプロセッサ504、データベースメモリ510、データベースプログラム512、およびデータ514は、図2に関連して、それぞれ、ストリームプロセッサ230、ストリームメモリ220、ストリームプログラム222、およびストリームデータ224について上記の形態のいずれかをとることができる。データベース180の構成要素は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの両方の組み合わせで実装され得る。例えば、データベース180の1つまたは複数の構成要素は、コンピュータ処理命令モジュールとして実装され得るが、データベース180の機能のすべてまたは一部は、代わりに、専用の電子ハードウェアに実装されてもよい。
データベースメモリ510は、プログラム512を含むことができ、これは、クライアントシステム190からの問い合わせ、および例えば、クライアントデバイス150とサービスシステム105との間の対話をサポートするための命令を含むことができる。さらに、プログラム512は、情報がサービスシステム105によって処理されるときにリアルタイムで情報を格納するための命令を含むことができる。
データ514は、オンラインリソース140などのウェブサイト、またはクライアントデバイス150からのユーザアカウントに関連するデータであってもよい。データ514は、例えば、コンテンツを取得するためのユーザおよびその資格情報に関連する情報を含むことができる。データ514はまた、データストリーム内のイベントから抽出されたキーをユーザアカウントと相関させるための情報を含む、アカウント記録434(図4)と同様のコンテンツファイルを含むことができる。
ここで図6を参照すると、開示された実施形態と一致する、例示的なクライアントデバイス150(図1)のブロック図が示されている。一実施形態では、クライアントデバイス150は、1つまたは複数のプロセッサ602、1つまたは複数の入力/出力(I/O)デバイス604、ならびに1つまたは複数のメモリ610を含むことができる。いくつかの実施形態では、クライアントデバイス150は、スマートフォンもしくはタブレット、汎用コンピュータ、またはこれらの構成要素の任意の組み合わせなどのモバイルコンピューティングデバイスの形態をとることができる。あるいは、クライアントデバイス150(またはクライアントデバイス150を含むシステム)は、開示された実施形態と一致する1つまたは複数の動作を実行するソフトウェア命令の格納、実行、および/または実装に基づいて、特定の装置、組み込みシステム、専用回路などとして構成されてもよい。いくつかの実施形態によれば、クライアントデバイス150は、開示された実施形態と一致するウェブサイトにアクセスするウェブブラウザまたは同様のコンピューティングデバイスを含むことができる。
プロセッサ602は、1つまたは複数の公知の処理デバイス、例えば、lntel(商標)、NVIDIA(商標)によって製造されたモバイルデバイスマイクロプロセッサ、または他の製造業者による様々なプロセッサを含むことができる。開示された実施形態は、クライアントデバイス150で構成された特定のタイプのプロセッサに限定されない。
メモリ610は、開示された実施形態に関連する機能を実行するためにプロセッサ602によって使用される命令を格納するように構成された1つまたは複数の記憶装置を含むことができる。例えば、メモリ610は、プロセッサ602によって実行されるときに動作を実行することができるプログラム612などの1つまたは複数のソフトウェア命令で構成され得る。開示された実施形態は、専用のタスクを実行するように構成された別個のプログラムまたはコンピュータに限定されない。例えば、メモリ610は、クライアントデバイス150の機能を実行する単一のプログラム612を含むことができ、またはプログラム612は複数のプログラムを含むことができる。メモリ610はまた、データストリームを生成するために使用されるデータ616を格納することができる。すなわち、メモリ610は、トランザクション承認またはコンテンツを要求する一連のデータパケットをサービスシステム105に送信するための命令を含むことができる。
特定の実施形態では、メモリ610は、サービスシステム105にアクセスするための命令を格納することができる。例えば、メモリ610は、TCP/IPを介してサービスシステム105と通信するアプリケーションを含むことができる。さらに、他のソフトウェア構成要素は、サービスシステム105からの情報を要求するか、またはクライアントデバイス150の位置を決定するように構成され得る。例えば、これらのソフトウェア命令は、プロセッサ602によって実行されると、情報を処理してトランザクションのステータスを表示することができる。
I/Oデバイス604は、クライアントデバイス150によってデータを受信および/または送信することを可能にし、クライアントデバイス150がシステム100の他の構成要素などの他のマシンおよびデバイスと通信することを可能にするように構成された1つまたは複数のデバイスを含むことができる。例えば、I/Oデバイス604は、クイックレスポンスコード(QR)などの光学的支払い方法を表示するための、またはユーザに情報を提供するための画面を含むことができる。I/Oデバイス604はまた、NFC通信のための構成要素を含むことができる。I/Oデバイス604はまた、タッチ感応領域、ボタン、またはマイクロフォンなどのユーザがクライアントデバイス150と対話することを可能にする1つまたは複数のデジタルおよび/またはアナログデバイスを含むことができる。I/Oデバイス604はまた、クライアントデバイス150の向きおよび慣性を検出するための1つまたは複数の加速度計を含むことができる。I/Oデバイス604はまた、サービスシステム105と対話するための当技術分野で公知の他の構成要素を含むことができる。
いくつかの実施形態では、クライアントデバイス150はまた、画像をキャプチャし、顔認識などの生体認証プロセスに使用され得るカメラ620を含むことができる。それに加えて、またはその代わりに、クライアントデバイス150は、ユーザがクライアントデバイス150のロックを解除し、および/または認証を実行することを可能にする指紋センサ630を含むことができる。カメラ620および指紋センサ630の両方は、プロセッサ602によって動作されてもよく、暗号化セキュリティを使用して、ユーザが指紋またはカメラ情報に外部からアクセスすることを不可能にすることができる。
クライアントデバイス150の構成要素は、当業者には明らかであるように、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの両方の組み合わせで実装され得る。
ここで図7を参照すると、開示された実施形態と一致する、データストリーム処理フロー700を示すプロセスフロー図が示されている。いくつかの実施形態では、図7に示すように、システム100(図1)の異なる要素は、フロー700の特定のステップを実行することができる。例えば、サービスシステム105の構成要素は、1つまたは複数のステップを実行することができるが、クライアントシステム190などの他のシステムは、他のステップを実行することができる。しかし、他の実施形態では、システム100の代替要素は、説明されたステップを実行することができ、またはシステム100の単一の要素は、説明されたステップの1つまたは複数を実行することができる。
ステップ702で、クライアントシステム190は、データストリームをサービスシステム105に送信することができる。データストリームは、サービスシステム105と相互作用するためのトランザクション要求、発注、または同様のメッセージを含むことができる。データストリームは、異なる通信プロトコルに従って配置されたパケットのシーケンスを含むことができる。例えば、ステップ702のデータストリームのいくつかは、TCP通信であってもよく、他のデータストリームはUDP通信であってもよい。
ステップ704で、フィルタ/ノーマライザ232は、データストリーム内のイベントをフィルタリングおよび正規化した後に、1つまたは複数の出力データストリームを生成することができる。図2に関連してさらに説明されるように、フィルタ/ノーマライザ232は、1つまたは複数のデータストリームを入力として受信し、演算器を適用して、限られたフィールドを有するか、または予測モデルまたは異常検出に使用できないイベントを除去する出力データストリームを生成することができる。それに加えて、またはその代わりに、ステップ704で、フィルタ/ノーマライザ232は、標準に一致するように均一なフォーマットまたは変更された値を有するイベントを有するフィルタリングされたデータストリームを生成することができる。さらに、ステップ704で、フィルタ/ノーマライザ232は、関連するイベントタイムを含まないイベントを識別し、関連するイベントタイムを有さないイベントを削除し、イベントタイムのタイムゾーンおよびイベントの通貨を正規化することによって削除されていないイベントのイベント情報を正規化するための動作を実行することができる。
ステップ706で、ブローカ234は、着信データストリームを受け入れ、要求されたときにそれらをダウンストリームデータに分類することができる。例えば、ステップ706で、ブローカ234は、データストリーム内の異なるイベントのトピックを生成し、タイムスタンプに基づいてイベントのタイマーまたはコールバックを発行することができる。ステップ707で、キー抽出器235は、データストリームを処理して、キーを抽出し、関連するアカウントを識別し、アカウントに関連する状態変数を見つけまたは生成することができる。ステップ707におけるキー/値のペアの抽出は、1つまたは複数のリアルタイム処理要件に従って予め定義され得る。
いくつかの実施形態では、図15に関連してさらに説明するように、フィルタ/ノーマライザ232は、ブローカ234の後に動作することができる。例えば、ステップ702からのデータストリーム内のメッセージが予め定義され、送信者と受信者との間で合意される実施形態では、フィルタ/ノーマライザ232は、ブローカ234の後に配置されてもよい。次に、ユーザは、フィルタ/ノーマライザ232を使用して、実行時に消費するトピック/メッセージを選択できる。さらに他の実施形態では、フィルタ/ノーマライザ232は、ブローカ234の後に配置されてもよい。
ステップ708で、処理されたデータストリームは、アキュムレータ348によって状態変数を修正または更新するために使用され得る。例えば、アキュムレータ348は、処理されたイベントの影響を集約することによって状態変数を変更することができる。そのような実施形態では、新しいトランザクションイベントがサービスシステム105によって処理されると、アキュムレータは、ステップ708で、トランザクションの値を状態変数に追加することができる。変数は、複雑度を増すことなく更新できるため、引き続きO(1)複雑度の演算で動作可能であり、および/または一定の時間複雑度でアクセス可能である。例えば、アキュムレータ348は、状態変数を単一次元に保持することができるので、状態変数を含むいかなる動作も、計算の複雑度を増すことはなく、均一な時間で解決することができる。そのような実施形態では、O(1)複雑度の演算器でアクセスされるように構成可能な状態変数は、例えば、配列、固定サイズのスタック、または固定サイズのキューを含むことができる。これらの変数の配置には、入力サイズに関係なく、一定の時間内に状態変数にアクセスする演算器を使用してアクセスすることができる。例えば、状態変数に配列が含まれている場合、O(1)演算器が配列の要素にアクセスしていることができる。そのような実施形態では、状態変数は、「get(array(0))」などのO(1)複雑度関数でアクセスできる固有の位置を有する配列を有する単一値変数であってもよい。あるいは、またはさらに、状態変数は、プッシュおよびポップ演算器などのO(1)複雑度の演算器を使用してアクセスできる固定サイズのスタックのアーキテクチャを含むことができる。さらに、状態変数は、エンキュー演算器やデキュー演算器などの演算器を使用して、一定の時間でアクセスできる(つまり、入力サイズに関係なく一定時間で実行される)固定サイズのキューを含むことができる。したがって、ステップ708で、アキュムレータ348は、状態変数内のイベントを集約することができるが、O(1)複雑度のアクセス可能性を維持することによって、変数から情報を迅速に取り込む能力を維持することができる。例えば、アキュムレータ348は、状態変数に格納された単一の値にイベントの影響を加算または減算することができる。
さらに、ステップ708で、アキュムレータ348は、影響ウィンドウの外側にあるイベントの影響を排除することができる。例えば、新しいイベントによってトリガされると、アキュムレータ348は、状態変数に新しいイベントを追加し、特定のイベントを削除すべきかどうかを決定することもできる。アキュムレータ348は、例えば、タイムスタンプまたはコールバック関数に基づいて、その変数についてタイムウィンドウの外側にあるイベントを識別することができる。アキュムレータ348の動作を、トリガイベントが対応する状態変数に影響を与える場合だけに制限することにより、アキュムレータ348の使用率を最小化し、ハードウェア使用率を最小化して、コンピュータ動作の効率を改善することが可能である。
ステップ710で、不正行為/リスク検出サービス344は、1つまたは複数の状態変数のステータスが、関連するアカウントに対するアラートを生成すべきかどうかを決定することができる。例えば、ある期間にわたって一連のイベントを蓄積する状態変数がしきい値を超えると、不正行為/リスク検出サービス344は、疑わしい振る舞いを識別し、蓄積または状態変数に関連するアカウントに対するアラートを生成することができる。いくつかの実施形態では、ステップ710で、不正行為/リスク検出サービス344は、異なる値または異なるパラメータを蓄積し得る複数の状態変数を考慮に入れる予測モデル推定からの結果に基づいてアラートをトリガすることができる。
また、ステップ710で、不正行為/リスク検出サービス344は、アラートをクライアント要求インターフェース130に伝達することができる。アラート信号に応答して、クライアント要求インターフェース130は、APIマネージャ444の命令を変更し、アラートに関連するアカウントについてのサービスシステム105へのアクセスを制限することができる。例えば、ステップ710で、サービスシステム105は、レジスタを更新し、APIマネージャ444のフィールドをカスタマイズして、命令を変更し、アクセス可能性を制限することができる。さらに、ステップ710で、サービスシステム105は、API応答へのリンクを追加し、および/またはクライアントシステム190の要求に応じて応答の動作を変更するためにCURIE(またはコンパクトURI)を登録することができる。
ステップ702〜ステップ710は、クライアントシステム190からのデータストリームを絶えず監視するためにリアルタイムで実行され得る。一定期間にわたって一連のイベントを蓄積する状態変数を使用すると、傾向のリアルタイム評価が容易になり、必要な計算の数が減り、ハードウェア要件が緩和される。データストリーム内のイベントから抽出された複数のキーのアキュムレータを維持することにより、一連のイベントが不正または異常な行為に関連する可能性があるかどうかを迅速かつ効率的に判定することができる。
フロー700はまた、クライアントシステム190がAPIを使用してサービスシステム105からのトランザクションを要求するステップ712を含むことができる。いくつかの実施形態では、システム100の他の要素は、サービスシステム105からの情報またはサービスを要求することができる。例えば、サードパーティシステム160はまた、クライアント要求インターフェース130に連絡することによって、サービスシステム105からの情報を要求することができる。クライアント要求インターフェース130が外部ドメインからメッセージを受信すると、クライアント要求インターフェース130は、メッセージに関連するアカウントを識別し、アカウントがアラートに関連するかどうかを判定することができる。アカウントがアラートに関連している場合には、クライアント要求インターフェースは、ステップ714で拒否または警告メッセージで応答することができる。しかし、API要求がアラートの下のアカウントに関連していない場合には、クライアント要求インターフェース130は、クライアントシステム190(または要求を送信したシステム100内の要素)への承認で応答することができる。
したがって、ステップ702〜ステップ710のリアルタイム処理フローで生成されたアラートを使用して、API要求を処理し、および/またはクライアントシステム190と対話するサービスシステム105内の要素に通知および変更することによって、危険にさらされたアカウントからのさらなるトランザクションを防ぐことができる。さらに、いくつかの実施形態では、クライアント要求インターフェース130は、新しいデータストリームが来て、識別されたアカウントに関連付けられている可能性があることを、リアルタイム状態計算器120に通知することができる。この配置により、システム105は、クライアントアカウントを検索または識別する必要がある回数を減らすことができる。
ここで図8を参照すると、開示された実施形態と一致する、アラート生成プロセスを説明するフローチャートが示されている。プロセス800は、クライアントシステム190および/またはシステム100の他のネットワーク化された要素からのデータストリームの受信に応答して、サービスシステム105によってリアルタイムで実行され得る。例えば、プロセス800は、データストリーム内のイベントが受信されているときに、ストリーム演算器110およびリアルタイム状態計算器120によってリアルタイムで実行され得る。
ステップ802で、サービスシステム105は、イベントデータストリームを監視することができる。図11に関連してさらに説明するように、イベントデータストリームを監視するために、サービスシステム105は、ストリームキャプチャアプリケーションを構成し、および/またはKafkaクラスタを設定することができる。データストリームは、サービスシステム105との他の対話のうち、トランザクション、サービス要求、情報要求、発注を含むことができる。
ステップ804で、サービスシステムは、外部ドメインまたはサーバーからイベントを受信および/または識別することができる。識別されたイベントは、ステップ802で監視されるデータストリームの一部であってもよい。イベントは、例えば、電子決済情報、小売業者、製品、および金額を含むトランザクション要求であってもよい。
ステップ806で、サービスシステムは、受信したイベントからイベントキーおよび値を抽出することができる。抽出されたキーは、抽出されたキーを含むことができ、IPアドレス、電子メールアドレス、または電話番号のうちの少なくとも1つを含むことができる。
しかし、図11に関連してさらに説明するように、キー/値ペア抽出の代替方法もまた可能であり得る。さらに、ステップ806におけるキー抽出は、予め定義されたトピックのグループに基づくことができる。予め定義されたトピックは、トランザクション金額、トランザクション場所、アカウント情報などのトランザクションの特性を含むことができる。いくつかの実施形態では、ステップ806は、値を抽出して値の配列を生成することも含むことができる。
ステップ810で、サービスシステム105は、イベントが状態変数に関連しているかどうかを判定することができる。サービスシステム105は、ルックアップテーブルまたは同様のデータ構造を使用して、ステップ808のアカウントに関連する状態変数を識別することができる。状態変数は、一定の時間複雑度でアクセスされるように構成され得る。例えば、入力サイズに関係なく一定時間で実行されるO(1)複雑度を有する演算器を使用する。
いくつかの実施形態では、サービスシステム105は、イベント内のキーが、ステップ808で識別されたアカウントに関連する状態変数を変更すべきかどうかを判定することができる。例えば、イベントがトランザクションであり、状態変数で監視されている金額を含む場合には、サービスシステム105は、イベントが状態変数に関連付けられていると判定することができる(ステップ810:はい)。しかし、イベントが新しいアカウントの要求、またはパスワードを忘れた要求である場合には、サービスシステム105は、イベントが状態変数に関連付けられていないと判定することができる(ステップ810:いいえ)。さらに、ステップ808で識別されたアカウントがどの状態変数にも関連しない場合には、サービスシステム105はまた、イベントが状態変数に関連付けられていないと判定することができる(ステップ810:いいえ)。
サービスシステム105が、イベントが状態変数に関連付けられていないと判定した場合(ステップ810:no)には、プロセス800は、ステップ802に戻り、次のトリガイベントをキャプチャするためにデータストリームの監視を継続することができる。しかし、サービスシステム105が、イベントが状態変数に関連していると判定した場合(ステップ810:はい)には、プロセス800は、ステップ812に進み、そこでサービスシステム812は、識別された状態変数が既存のイベントを含むかどうかを判定する。
識別された状態変数が既存のイベントを含む場合(ステップ812:はい)には、プロセッサ820は、ステップ820に進み、ウィンドウ長を決定または検索することができる。ウィンドウ長は、状態変数に対して予め定義されていてもよく、タイムウィンドウまたはイベント数ウィンドウであってもよい。例えば、ウィンドウは、30分のウィンドウ、30秒のウィンドウ、24時間のウィンドウ、または異なる組み合わせであってもよい。あるいは、またはさらに、ウィンドウ長は、トランザクションの数に基づいてもよい。例えば、状態変数に100イベントしか考慮できない場合、イベント101が処理されると、ウィンドウの外に出るため、イベント1を削除することができる。このような構成により、O(1)複雑度の動作を強制し、待ち時間を短縮することを可能にすることができる。
サービスシステム105は、ステップ822に進み、状態変数に影響を与える既存のイベントのコールバックの記録されたタイムスタンプ、タイマーを決定または識別することができる。例えば、状態変数を更新する場合、アキュムレータ348(図3)は、イベントが期限切れになったときに、累積状態変数からイベントを撤回するためにタイマーまたはコールバックを登録することができる。したがって、ステップ822で、サービスシステム105は、記録されたタイマーまたはタイムスタンプを識別することができる。
ステップ824で、サービスシステム105は、ステップ820で決定されたウィンドウの外側にタイムスタンプ、タイマー、またはコールバックを有するイベントを廃棄することができる。例えば、イベントの有効期限が切れた場合(例えば、タイムスタンプがウィンドウの外にある場合)、サービスシステムは、期限切れイベントからの影響を取り除くために状態変数を更新する必要があると判断することができる。ステップ826で、サービスシステム105は、期限切れイベントの影響を取り除くことによって状態変数を更新することができる。例えば、サービスシステム105は、廃棄されたイベントを差し引くことによって状態変数を更新することができる。あるいは、またはさらに、ステップ824は、状態変数に蓄積された既存のイベントのタイムスタンプを取得し、タイムウィンドウの下限よりも古いタイムスタンプを有する既存のイベントを削除するシーケンスを含むことができる。
識別された状態変数が既存のイベントを含まない場合(ステップ812:はい)、または状態変数が更新されて期限切れイベントの影響を取り除くと(ステップ826の後)、プロセス800はステップ830に進むことができ、そこでサービスシステム105が新しいイベントまたはトリガイベントに基づいて状態変数を更新する。例えば、サービスシステム105は、イベントの量または値に比例して状態変数に追加することによって、トリガイベントの影響を蓄積することができる。したがって、いくつかの実施形態では、プロセス800は、状態変数にトリガイベントを蓄積し、状態変数にイベントのタイムスタンプを登録し、状態変数から期限切れイベントを廃棄することによって、状態変数を更新することができる。さらに、いくつかの実施形態では、トリガイベントに基づく状態変数への増分は、トリガイベントの値に比例することができる。したがって、ステップ830で、サービスシステム105は、トランザクション値に比例するイベントにスコアを割り当て、割り当てられたスコアに基づいて状態変数の値を増加させる動作を実行することができる。
ステップ832で、サービスシステム105は、状態変数におけるトリガイベントの影響について、タイムスタンプ、タイマー、またはコールバックを登録することができる。
ここで図9を参照すると、開示された実施形態と一致する、多変数アラートプロセス900を示すフローチャートが示されている。プロセス900は、データストリームを監視するときにサービスシステム105によって実行され得る。例えば、プロセス900は、データストリーム内のイベントから抽出されたキーおよび値を用いて、リアルタイム状態計算器120によって実行され得る。
ステップ902で、サービスシステム105は、複数の状態変数を収集または受信することができる。これらの状態変数は、O(1)の複雑度を有する演算器を使用してアクセスするように構成され得る。例えば、ステップ902で収集された変数は、1次元配列または固定長スタックであってもよい。さらに、ステップ902の変数は、イベントからのキー/値ペア抽出中に抽出された異なるキーを表すことができる。例えば、ステップ902の状態変数は、トランザクション金額アキュムレータ、トランザクションの頻度、トランザクション起源、または電子トランザクションに関連し得る同様のパラメータを含むことができる。あるいは、またはさらに、ステップ902は、データベースからアカウントに関連する複数の状態変数を検索することを含むことができ、複数の状態変数の各々は、O(1)演算器(array:accessing any elementなどの入力サイズに関係なく一定時間で実行されるアルゴリズムを有する演算器)でアクセスされるように構成される。
ステップ904で、サービスシステム105は、状態変数に基づいて多変数予測のためのモデルおよび/または規則を検索することができる。例えば、サービスシステム105は、複数の状態変数を処理するために、予測モデル生成器342(図3)からランダムフォレストおよび/またはニューラルネットワークモデルを検索することができる。複雑度の低い演算器で変数にアクセスできるため、予測モデルをすばやく実行して予測を提供することができる。ステップ904で検索されるモデルは、オフラインまたはオンラインで開発することができる。例えば、ステップ904のモデルは、以前に収集されたイベントに基づいてオフラインでサービスシステム105によって生成され得るが、検証データセットに基づいて所望の精度を達成すると、オンライン動作のために実装され得る。
ステップ906で、サービスシステム105は、不正行為アセスメントのためのモデルまたは規則を検索することができる。例えば、サービスシステム105は、計算器メモリ350から、不正行為の確率と相関させることができるしきい値確率または累積量に関連する1つまたは複数の規則を検索することができる。いくつかの実施形態では、不正行為アセスメントの規則は、潜在的な不正行為を示すしきい値を指定することができる。
ステップ908で、サービスシステム105は、データストリーム内のイベントに重みまたはスコアを割り当てることができる。例えば、サービスシステム105は、抽出されたキーを用いてイベントに重みを割り当てる動作を実行することができる。いくつかの実施形態では、特定の変数は、他の変数よりも不正行為をより示唆することができる。例えば、トランザクションで費やされた金額に関連するイベントは、トランザクションのタイプのイベントよりも高い予測値を有し得るが、これは、費やされた金額がトランザクションのタイプよりも不正行為を示すことができるためである。対照的に、小売業者のタイプまたは通貨などのパラメータに関連する他のイベントは、不正行為の問い合わせとの関連性が低い場合がある。したがって、サービスシステム105は、実行されている予測またはアセスメントのタイプに基づいて異なるイベントに重みを追加し、関連性の高いイベントに高い重みを割り当て、関連性の低いトランザクションに低い重みを割り当てることができる。ステップ908におけるイベントへの重み付けの割り当ては、図12に関連してさらに説明されるプロセスに基づくことができる。
ステップ910で、サービスシステム105は、ステップ908の修正された変数を用いて、ステップ904〜ステップ906の検索されたモデルを使用して、データストリームのリアルタイム解析を実行することができる。そのような実施形態では、サービスシステム105は、修正された状態変数に基づいて予測または不正行為の確率を計算することができる。例えば、サービスシステム105は、ステップ910で予測モデルを使用して不正行為の確率を計算することができ、予測モデルは、ランダムフォレストまたは畳み込みニューラルネットワークのうちの少なくとも1つを含む。
ステップ915で、サービスシステム105は、予測モデルが定義されたしきい値を超える確率を返したかどうかを判定することができる。例えば、不正行為/リスク検出サービス344は、ステップ910からの結果をリアルタイムで監視して、不正行為または異常の推定確率の1つがしきい値を超えているかどうかを識別することができる。サービスシステム105が、推定された確率がしきい値を超えていると判定した場合(ステップ915:はい)には、プロセス900は、ステップ916に進み、複数の解析された変数に関連するアカウントに対してアラートをトリガすることができる。しかし、サービスシステム105が、推定された予測モデルが定義されたしきい値を超える確率をもたらさなかったと判定した場合(ステップ915:いいえ)には、プロセス900はステップ918に進み、アラートをトリガしない。変数の累積構成が少ないため、様々なストリームにリソースをシームレスに割り当てることができ、リアルタイム処理と予測モデル生成のハードウェア要件が緩和される。
ここで図10を参照すると、開示された実施形態と一致する、クライアント要求プロセス1000への応答を示すフローチャートが示されている。プロセス1000は、例えば、クライアントシステム190またはクライアントデバイス150から要求を受信するときに、サービスシステム105によって実行され得る。例えば、プロセス1000は、ネットワーク170を介してシステム100の構成要素と対話することができるクライアント要求インターフェース130によって実行され得る。
ステップ1002で、サービスシステム105は、APIを使用してトランザクション要求を受信することができる。例えば、クライアントシステム190は、APIマネージャ444(図4)によってサポートされるAPIを使用して、サービスシステム105に要求を送信することができる。要求は、承認要求、発注、または情報の要求のいずれかを含むことができる。
ステップ1004で、サービスシステム105は、ステップ1002の要求をアカウントまたはクライアントに関連付けることができる。例えば、サービスシステム105は、要求内の情報をクライアント登録情報446と相関させることができ、またはインターフェースメモリ430(図4)に問い合わせて、要求を1つまたは複数のアカウントに関連付けることができる。
ステップ1006で、サービスシステム105は、ステップ1004で識別された1つまたは複数のアカウントに対してアラートが発行されたかどうかを判定することができる。例えば、クライアント認証器442(図4)は、不正行為/リスク検出サービス344(図3)が、ステップ1002からの要求に関連するアカウントに対してアラートを生成したかどうかを判定することができる。アカウントがアラートに関連付けられている場合(ステップ1006:はい)には、プロセス1000はステップ1008に進むことができ、サービスシステム105は、トランザクションまたは要求を拒否する応答をクライアントシステム190に送信することができる。この構成により、サービスシステム105は、危険にさらされたアカウントとのさらなる対話を防ぐために、APIおよびインターフェース要素を構成すると同時に、リアルタイムの疑わしい振る舞いを捕捉することができる。しかし、ステップ1006で、サービスシステムが、アカウントがアラートに関連付けられていないと判定した場合(ステップ1006:いいえ)には、プロセス1000は、ステップ1010に進み、トランザクションを受け入れる応答をクライアントシステム190に送信することができる。
いくつかの実施形態では、プロセス1000は、ステップ1012を含むことができ、サービスシステム105は、次のイベントをストリームに追加することができ、イベントが識別されたアカウントに関連付けられるというメッセージをブローカ234(図2)に送信することができる。ステップ1010でトランザクションまたは要求が承認されると、承認を受信したクライアントシステム190に関連するデータストリームに対して新しいイベントが生成され得る。したがって、追加の処理ステップを減らし、計算の複雑度を減らすために、ステップ1012で、サービスシステム105は、識別されたアカウントに関連する新しいイベントが生成され得ることをブローカ234またはリアルタイム状態計算器120(図1)の他の要素に通知することができる。それに応じて、ブローカ234、またはリアルタイム状態計算器120の他の要素は、新しい潜在的なイベントのためにトピックまたはワークフローを初期化することができる。
ここで図11を参照すると、開示された実施形態と一致する、例示的なストリームキャプチャ構成プロセス1100を示すフローチャートが示されている。プロセス1100は、例えば、クライアントシステム190またはクライアントデバイス150によって生成されるデータストリーム内のイベントを処理しながら、サービスシステム105によってリアルタイムで実行され得る。例えば、プロセス1100は、ストリーム演算器110によって実行され得る。
ステップ1102で、サービスシステム105は、1つまたは複数のストリームキャプチャアプリケーションを構成することができる。ストリームキャプチャアプリケーションの構成は、Javaインスタンスの作成、パラメータの設定、およびインスタンスパラメータの構築を含むことができる。例えば、ステップ1102で、サービスシステム105は、以下のような動作を実行することができる。
import java.util.Properties;
import org.apache.kafka.streams.StreamsConfig;
Properties settings=new Properties();
settings.put(StreamsConFigAPPLICATION_ID_CONFIG,“my−first−streams−application”);
settings.put(StreamsConFigBOOTSTRAP_SERVERS_CONFIG,“kafka−broker1:9092”);
settings.put(...,...);
StreamsConfig config=new StreamsConfig(settings);
ステップ1102でストリームキャプチャアプリケーションの構成のために選択されたパラメータは、「application.id」および「bootstrap.servers」などの必要な構成パラメータを含むことができる。それに加えて、またはその代わりに、ステップ1102における構成のためのパラメータは、「default.deserialization.exception.handler」、「default.production.exception.handler」、「default.key.serde」、「default.value.serde」、「num.standby.replicas」、「num.stream.threads」、「partition.grouper」、「processing.guarantee」、「replication.factor」、および「timestamp.extractor」を含むことができる。さらに、キャプチャアプリケーションの構成用のパラメータは、プロデューサ構成パラメータ(例えば「Naming、Default Values、enable.auto.commit、rocksdb.conFigsetter」)または弾力性のための推奨構成パラメータ(例えば「replication.factor」)を含むことができる。
構成されたキャプチャアプリケーションは、特定のタイプのイベントを具体的にキャプチャし、キーを識別し、リアルタイム処理に使用できるキーと値のペアを決定することができる。あるいは、またはさらに、ステップ1104で、サービスシステム105は、1つまたは複数のストリームキャプチャアプリケーションを構成することと、各キャプチャアプリケーションに1つまたは複数のブローカを割り当てることと、各ブローカでイベント情報をO(1)演算器でアクセス可能な変数に変換するように定義することと、を含む、一連の動作を実行することができる。
ステップ1104で、サービスシステム105は、1つまたは複数のブローカ234(図2)を各キャプチャアプリケーションに割り当てることができる。例えば、サービスシステム105は、ブローカ234の現在のパーティション割り当てをチェックして、それらのワークロードを決定することができる。そうするために、サービスシステム105は、ブローカ234の配置を識別するためにスクリプトを使用することができる。サービスシステム105はまた、例えば「reassign−partitions.json」ファイルをフォーマットするためにスクリプト言語を使用してパーティションに基づいて要素を再割り当てすることによって、パーティションに基づいてキャプチャアプリケーションを割り当て続けることができる。
ステップ1104で、サービスシステム105はまた、より弾力性のある計算のためにレプリカブローカ234へのトピックの再割り当てを実行することができ、割り当てを検証することができる。
ステップ1106で、サービスシステム105は、ステップ1104でブローカ234の割り当て中に作成されたトピックに基づいてイベント内の情報を変換するためにシリアライザまたはデシリアライザを定義することができる。例えば、サービスシステム105は、以下のコマンドを実行して、リアルタイムデータストリームで処理するシリアライザおよびデシリアライザをセットアップすることができる。
public class User {
private String clientID;
private int amount;
public User(){
}
public User(String clientID,int amount){
this.clientID=clientID;
this.amount=amount;
}
public String getclientID(){
return this.clientID;
}
public int getamount(){
return this.amount;
}
@Override public String toString(){
return “User(”+clientID+“,”+amount+“)”;
}
@Override public byte[] serialize(String arg0,User arg1){
byte[] retVal=null;
ObjectMapper=new ObjectMapper();
try {retVal=objectMapper.writeValueAsString(arg1).getBytes();
}
ステップ1108で、サービスシステム105は、ステップ1104でのブローカ234の割り当ての結果として、トピックのための1つまたは複数のストリームオブジェクトを作成することができる。ステップ1108で作成されたオブジェクトは、データストリームに基づくことができる。例えば、ステップ1108で作成されたオブジェクトは、単一のプロデューサインスタンスを共有することができる。オブジェクトは、オブジェクトを定義する関数を使用して作成することができる。例えば、ステップ1108で、サービスシステム105は、「ObjectRecord(java.lang.String topic,java.lang.Integer partition,K key,V value)」を使用して、キー/値ペアオブジェクトを生成し、ブローカ234の指定されたトピックおよびパーティションに送信される記録を作成することができる。あるいは、またはさらに、サービスシステム105は、「ObjectRecord(java.lang.String topic,K key,V value)」のコマンドを使用して、ストリーム演算器110および/またはKafkaなどのリアルタイムプロセッサに送信する記録を作成することができる。さらに、ステップ1108で、サービスシステム105は、「ObjectRecord(java.lang.String topic,V value)」などのコマンドを使用してストリームオブジェクトを作成し、キーのない記録を作成することができる。
ステップ1110で、サービスシステム105は、ストリーム内でイベントを順次処理することができる。キー/値のペアならびにトピック構成およびパーティションに基づいて、プロセスは、異なるトピックに基づいて並列化されたブローカ234を使用することによって効率的に実行され得る。ステップ1110で、処理は、定義された順序なしで同時に処理することができるデータのパーティションを使用することによって並行して実行され得る。
ステップ1112で、サービスシステム105は、キー/値イベントをアカウントおよびそれらに関連する状態変数に関連付けることができる。状態変数は、キー/値に基づいて更新することができ、サービスシステム105は、メモリ使用率を最小化するために状態変数の単一のコピーを格納し、O(1)複雑度の演算器を使用してそれらにアクセスする能力を強制するように変数を構成することができる。したがって、ステップ1112で、キャプチャアプリケーションを構成し、順次イベントを処理した後に、サービスシステム105は、データストリームを監視する複雑度の低い状態変数を格納することができる。
ここで図12を参照すると、開示された実施形態と一致する、予測モデル構成プロセス1200を示すフローチャートが示されている。プロセス1200は、サービスシステム105によって実行され得る。例えば、プロセス1200は、計算器プロセッサ340(図3)の予測モデル生成器342によって実行されてもよく、例えば、畳み込みニューラルネットワークを使用して変数を相関させることにより、予測モデルを生成するように構成されてもよい。
ステップ1204で、サービスシステム105は、トレーニングデータセットの特徴に基づいて入力アレイを生成することができる。ステップ1206で、サービスシステム105は、トレーニングデータセットのキー/値に基づいて出力ベクトルを生成することができる。
ステップ1204で、サービスシステムは、ステップ1214における推定出力およびコスト関数を計算することができる。ステップ1220で、サービスシステム105は、コスト関数がユーザによって指定され得る必要な精度のしきい値より小さいかどうかを判定することができる。サービスシステム105が、コスト関数がしきい値を下回っておらず、必要な精度が達成されていないと判定した場合には、サービスシステム105は、ステップ1222に進み、モデルを更新することができる。しかし、コスト関数がしきい値を下回っている場合(ステップ1220:はい)、サービスシステム105はモデルを受け入れることができる。
図13は、開示された実施形態による、予測モデルトレーニングプロセス1300を示す例示的なフローチャートである。いくつかの実施形態では、サービスシステム105は、プロセス1300を実行することができる。例えば、リアルタイム状態計算器120は、プロセス1300を実行することができる。
ステップ1302で、サービスシステム105は、予測モデルの要求を受信することができる。いくつかの実施形態では、要求は、ターゲット状態変数または特定のクライアントシステム190を指定することができる。要求は、クライアントデバイス150に関する情報を含むことができる。
ステップ1304で、サービスシステム105は、モデリングデータセットを生成することができる。サービスシステム105は、データベース180、オンラインリソース140、および/またはクライアントデバイス150からの情報を使用してトレーニングデータセットを生成することができる。例えば、サービスシステム105は、データベース180から、クライアントデバイス150のユーザが不正であると報告したアカウントに関連するトランザクションおよびイベントを検索することができる。
ステップ1306で、サービスシステム105は、ステップ1304で生成されたモデリングデータセットを分割することによって、モデリングデータサブセットを作成することができる。いくつかの実施形態では、サービスシステム105は、トレーニングデータセットをランダムに分割して、ランダムなトレーニングサブセットを作成し、サブセットをテストすることができる。次に、モデリングデータセットのランダムに選択されたサブセットを使用して予測モデルを生成することができる。トレーニングデータサブセットの要素は、独立したトレーニングデータサブセットを作成するために、各サブセットに固有のものとすることができる。あるいは、トレーニングデータサブセットが要素を共有して重複してもよい。他の実施形態では、サービスシステム105は、分割規則を使用してトレーニングデータセットを分割することができる。トレーニングデータセットの分割規則は、分割の数および/または異なるグループ間の比率を示すことができる。例えば、トレーニングデータセットは、テストおよび検証データ用に80/20分割を使用して分割することができる。
モデリングデータセットの分割に基づいて、サービスシステム105は、ステップ1307で分類器を選択することができる。サービスシステム105はまた、ステップ1306のモデリングデータセットを処理して、予測モデルの係数(ステップ1308)およびハイパーパラメータ(ステップ1310)を決定することができる。予測モデルは、パラメトリック、ノンパラメトリック、またはセミパラメトリックであってもよい。いくつかの実施形態では、サービスシステム105は、不正行為の確率を識別するための予測モデルとして複数の決定木を作成することができる。他の実施形態では、サービスシステム105は、ニューラルネットワーク(図12に関連してさらに説明される)、データハンドリングのグループ方法(GMDH)アルゴリズム、ナイーブベイズ分類器、および/または多変量適応回帰スプラインを生成することができる。
ステップ1314で、サービスシステム105は、モデルが完了したかどうか、またはモデルが停止基準に達したかどうかを評価することができる。例えば、サービスシステム105が決定木を生成すると、ステップ1314で、サービスシステム105は、エンドノードについて停止基準が満たされているかどうかを評価することができる。いくつかの実施形態では、停止基準は、モデルに固有であるか、またはハイパーパラメータによって定義され得る。
停止基準が満たされない場合には、サービスシステム105は、ステップ1316に進み、新しい変数またはパラメータを選択して、新しい分類器を決定することができる。あるいは、停止基準が満たされると、サービスシステム105は、ステップ1318に進むことができ、そこでサービスシステム105は、トレーニングデータセットの一部を使用してモデルの精度を計算することができる。
ステップ1320で、サービスシステム105は、モデルの精度が精度しきい値を超えているかどうかを評価することができる。いくつかの実施形態では、モデルの精度しきい値は、予測モデルに設定された最適化目標に基づいて自動的に調整され得る。モデルがしきい値を超えていない場合(ステップ1320:いいえ)には、ステップ1326でモデルを破棄することができる。計算された精度がしきい値を超えている場合(ステップ1320:はい)には、サービスシステム105は、ステップ1322でモデルに加重係数を割り当て、ステップ1324でモデルのセットにモデルを含めることができる。加重係数は、計算された精度に関連付けられてもよい。例えば、加重係数は精度に比例してもよい。
プロセス1300を複数回繰り返して、複数のモデルを生成することができる。いくつかの実施形態では、サービスシステム105は、最小のモデルが生成されるまでプロセスを繰り返すことができる。
図14Aは、開示された実施形態による、時間の関数としての例示的な状態変数の値のグラフを示す。図14Aに示す状態変数は、トランザクション値(例えば、トランザクションに費やされた金額)を累積するように構成され得る。さらに、状態変数は、イベントが30分より古い場合にイベントの影響を取り除くように構成することができる。さらに、図14Aに記載された状態変数は単一の値を格納するので、それが長期または短期のどちらを監視するかに関係なく、時間複雑度は常にO(1)である。
図14Aは、状態変数が時間の関数として4回変化することを示している。時刻1402で、状態変数は0から30,000ドルに変化する。この変化は、データストリーム内のイベントが状態変数の変化をトリガしたときに発生することができる。例えば、ストリーム演算器110は、アカウントに関連するイベントからキー/値を抽出することができる。次に、アカウントは、図14Aに示す状態変数に関連付けられる。したがって、リアルタイム状態計算器120は、トリガイベントに従って、識別されたアカウントに関連する変数を更新することができる。この場合、トリガイベントには30,000ドルのトランザクションが含まれ、状態変数が更新される。例えば、アキュムレータ348は、トリガイベントを受信したときに変数を更新することができる。さらに、図14Aにも示されているように、タイムスタンプをイベントに関連付けることができる。図14Aに示す例では、時刻1402のトランザクションは、「13:01」タイムスタンプに関連付けられ得る。例えば、アキュムレータ348は、状態変数の変更をタイムスタンプまたはコールバックで登録して、それが期限切れになったときに状態変数におけるその影響を削除することができる。
状態変数は、サービスシステム105が同じアカウントに関連する第2のトランザクションイベントを受信する時刻1406で再び更新され得る。第2のトランザクションは60,000ドルになり得る。第1のトランザクション(時刻1402)と第2のトランザクション(時刻1406)を累積すると、状態変数の累積値は90,000ドルになる。絶対値ではなく差分変化に焦点を当てたこの変数の累積により、イベントをリアルタイムで処理するために必要な計算の数が最小限に抑えられる。さらに、単一の値の計算が高速であるため、状態変数は、O(1)アルゴリズムを使用して状態変数を更新、監視、または解析するのを容易にする。
状態変数は、第1のイベントが期限切れになる時刻1410に再び更新され得る。この状態変数は30分のタイムウィンドウで構成されたので、第1のイベント(時刻1402)から30分が経過した後、サービスシステム105は、イベントの影響を除去することができる。したがって、時刻1410で、第1のイベント(30,000ドルの値)の影響が30分後に期限切れになったため、状態変数の値が90,000ドルから60,000ドルに減少することができる。図14Aの例示的な実施形態は、30分の時刻1402でのイベントのコールバック時刻を示しているが、他のコールバック時刻は、システム100の特性に基づいて実装され得る。新しいイベントとコールバックによってトリガされるさらなる計算は、既存の変数を利用して迅速な決定でリアルタイムの決定を行うことができる内部規則エンジンを作成するので、異常または不正な振る舞いを識別するのに十分であり得る。例えば、可変計算速度の99.9パーセンタイルは20ミリ秒以内であり得るので、新しいイベントとコールバックによってトリガされる計算で十分である。
いくつかの実施形態では、図14Aに示すように、有効期限は自動的であってもよい。すなわち、イベントが期限切れになるとすぐに、状態変数が変更される。しかし、コンピュータリソースを節約し、コンピュータの動作を改善するために、他の実施形態では、状態変数はトリガイベントがある場合にのみ更新されてもよい。そのような実施形態では、トリガイベントがサービスシステム105によって受信されると、最初に、変更される変数のいずれかのイベントが期限切れであるかどうかを評価し、期限切れイベントの影響を取り除き、次にトリガイベントに基づいて変数を変更することができる。図14Bに関連してさらに説明されるこの構成は、計算の数およびメモリへのアクセスを最小化することができる。
状態変数は、第2のイベントが期限切れになったときに4回目の更新がされ得る。時刻13:45に、第2のイベントは30分のタイムウィンドウ上にはないので、期限切れになった。したがって、第1および第2のイベントが期限切れになったため、システムサービス105が第2のイベントの影響を除去することができ、状態変数は0ドルの値に戻る。
図14Aに示すような状態変数の構成は、ある期間にわたる一連のイベントの蓄積を可能にする。同様の状態変数は、イベントから抽出される様々なキーに実装され得る。例えば、他の状態変数を使用してトランザクション頻度を監視することができる。さらに、図14Aの状態変数は定量的情報を格納するが、他の状態変数または累積変数は、トランザクションの場所などの定性的情報を格納するか、または、例えば、アクティブアカウントと非アクティブアカウントの間で変化するバイナリ変数を含むことができる。
図14Aは、しきい値1420をさらに示す。変数が所定のしきい値を超えると、異常な振る舞いまたは潜在的な不正行為を示すアラートが生成され得る。例えば、図14Aでは、状態変数は、時刻1406のトリガイベントでしきい値1420を超えた。この時点で、累積金額の状態変数は、アカウントが高速または高価格のトランザクションに関連付けられていることを示す。そのような実施形態では、リアルタイム状態計算器120(図3)は、アカウント内のさらなるトランザクションを防止するために使用され得るアラートを(例えば、不正行為/リスク検出サービス344により)生成することができる。例えば、時刻1406において、累積値がしきい値1420を超えるため、クライアント要求インターフェース130(図4)は、状態変数に関連するアカウントからのそれ以上のトランザクションを拒否するように指示され得る。あるいは、またはさらに、図9に関連してさらに説明するように、しきい値1420を超えた状態変数は、複数の状態変数を使用して予測を行う、または不正行為の確率を評価する予測モデルの入力であってもよい。そのような実施形態では、サービスシステム105は、モデルからの予測が確率しきい値を超えているかどうかを判定することができる。
図14Bは、開示された実施形態による、時間の関数としての例示的な第2の状態変数の値のグラフを示す。図14Aに記載された状態変数と同様に、図14Bに示す状態変数は、トランザクション値(例えば、トランザクションに費やされた金額)を蓄積し、イベントが30分より古い場合にイベントの影響を除去するように構成され得る。しかし、図14Aの状態変数とは異なり、図14Bの状態変数は、トリガイベントが存在する場合にのみ変数を更新するように構成され得る。
図14Aと同様に、図14Bの状態変数は、時刻1422、1426における第1および第2のトランザクションのトリガイベントに基づいて、状態変数が2回変化することを示している。しかし、第1のイベントが時刻1430で期限切れになると、トリガイベントが発生していないため、状態変数は変化しない。したがって、メモリ使用率および計算の数を最小化するために、サービスシステム105は、イベントの1つが期限切れになったときに状態変数をすぐに更新しない。したがって、時刻1430では、第1のイベントがすでに期限切れになっていても、状態変数の値は変化しない。
代わりに、状態変数は、時刻1432に第3のトリガイベントがあるときに更新される。時刻1432において、サービスシステム105は、20,000ドルの金額で第3のトランザクションを受信することができる。状態変数を更新する際に、サービスシステム105は、第1のイベントがすでに期限切れになっていることに気付くことができる。したがって、時刻1432での状態変数の更新は、期限切れイベントの削除および新しいイベントの追加を含むことができる。図14Bの例では、イベントを更新することは、第1のイベントから30,000ドルの影響を除去すること、および20,000ドルを追加することを含む。したがって、状態変数の正味の減少は、時刻1432において10,000ドルである。
さらに、時刻1434において、第2のイベントが期限切れになったとしても、トリガイベントがなかったので、状態変数は変化しない。この構成では、各イベントは2つの計算に関与しており、1つは累積されたとき、もう1つはイベントが期限切れになったときである。しかし、累積動作と有効期限動作は、トリガイベントがある場合にのみ変数に影響を与えるようにバッチ処理される。
図14Bはまた、しきい値1440を示しており、それは図14Aのように第2のトランザクションで超過され、アカウントとの追加のトランザクションを妨げる可能性があるアラートをトリガする。
図14Cは、開示された実施形態による、時間の関数としての例示的な第3の状態変数の値のグラフを示す。図14A〜図14Bに記載されている状態変数とは異なり、図14Cに示されている状態変数は、蓄積の代わりに定期的な監視を有する。このタイプの変数は、不正行為について評価されているウィンドウ内のすべてのイベントを考慮して、および/または利用可能な履歴情報を考慮して、包括的な計算を適用する必要がある場合に使用され得る。これは、Flink(登録商標)またはSpark(登録商標)を使用して実装でき、固定長ウィンドウまたは間隔で使用することができ、ステータスを判定するために変数が監視される。
図14Cは、変数が間隔1450(1450A〜1450Z)ごとに監視されることを示している。各インターフェースにおいて、サービスシステム105は、変数のステータスを評価して、それがしきい値1460を超えたかどうかを決定することができる。トリガイベントは、変数への変更とは無関係であり、代わりに各イベントを個別に監視して異常を判定する。例えば、第1のトランザクションが時刻1456にサービスシステム105に到着すると、サービスシステムは、イベントおよびその情報を状態変数に追加することができる。次に、時刻1458において、新しいイベントがサービスシステム105に到達するとき、金額の累積はない。むしろ、サービスシステム105は、イベントの各々を別々に含み、過去の傾向を評価する包括的な計算を適用することができる。
この手法は、アカウントの継続的な概算と永続的な監視を提供することができるが、メモリを頻繁に使用し、より多くの計算リソースを使用する可能性がある。したがって、いくつかの実施形態では、図14Cに示すような非蓄積状態変数は、決定的に重要な特定のキーに対してのみ使用され得る。
ここで図15を参照すると、開示された実施形態と一致する、パイプラインデータストリーム処理フロー1500を示すプロセスフロー図が示されている。いくつかの実施形態では、図15に示すように、システム100(図1)の異なる要素は、フロー1500の特定のステップを実行することができる。例えば、サービスシステム105の構成要素は、1つまたは複数のステップを実行することができるが、クライアントシステム190などの他のシステムは、他のステップを実行することができる。しかし、他の実施形態では、システム100の代替要素は、説明されたステップを実行することができ、またはシステム100の単一の要素は、説明されたステップの1つまたは複数を実行することができる。
ステップ1502で、クライアントシステム190は、イベントメッセージをサービスシステム105に送信することができる。例えば、支払いクライアントシステム190A、メンバークライアントシステム190B、および出荷クライアントシステム190Cは、ステップ1502で、イベントメッセージをサービスシステム105に送信することができる。いくつかの実施形態では、メッセージは、予測されたスケジュールなしで同時に受信され得る。しかし、他の実施形態では、メッセージは、バッチで、いくつかの所定のスケジュールに従って受信されてもよい。
ステップ1504で、ブローカ234(図2)は、イベントメッセージをデータストリームとして受け入れ、要求されたときにソートされたデータストリームを発信することができる。ステップ1506で、フィルタ/ノーマライザ232(図2)は、フィルタまたは正規化規則に従って、イベントメッセージを変更するか、またはイベントメッセージを破棄するために、ブローカ234のストリームを処理することができる。ステップ1508で、キー抽出器235(図2)は、データストリーム内のイベントメッセージに基づいてイベント/鍵のペアを生成することができる。ステップ1510で、イベント/キーのペアは、状態変数などの変数を提供または更新し、それらをデータベース180に格納することができるアキュムレータ348(図3)によって処理され得る。いくつかの実施形態では、キー抽出器235は、イベントを特定のアキュムレータ348のインスタンスにディスパッチすることによって、アキュムレータ348と密接に動作することができる。リアルタイムデータストリームの処理速度を最大化するために、キー抽出器235は、アキュムレータのインスタンスおよびそれらのそれぞれのサーバー/JVM/スレッドをマッピングすることができる。キー抽出器235は、待ち時間を最小化し、応答時間を改善するために、どのアキュムレータ348のインスタンスにイベントを送信するかを決定することができる。
次に、アキュムレータ348による変数は、データストリームの異常の決定を行うときに、不正行為/リスク検出サービス344によって使用され得る。例えば、ステップ1512で、クライアントシステム190は、HTTP要求を送信することができる(例えば、支払いクライアントシステム190Aは、要求支払いをサービスシステム105に送信することができる)。要求は、不正行為/リスク検出サービス344によって受信することができ、サービス344は、次に、ステップ1514で、データベース180からのHTTP要求に関連する変数を要求することができる。ステップ1516で、データベース180は、変数を不正行為/リスク検出サービス344に返すことができ、不正行為/リスク検出サービス344は、HTTP要求を受け入れるべきかどうかを決定するための予測モデルおよび/または規則を実装することができる。ステップ1518で、ステップ1516の変数に基づいて、不正行為/リスク検出サービス344がHTTP応答を送信することができる。
ここで図16を参照すると、開示された実施形態と一致する、トランザクションイベントに基づく状態変数の更新を示すプロセスフロー図が示されている。いくつかの実施形態では、図16に示すように、システム100(図1)の異なる要素は、フロー1600の特定のステップを実行することができる。例えば、サービスシステム105の構成要素は、1つまたは複数のステップを実行することができるが、クライアントシステム190などの他のシステムは、他のステップを実行することができる。しかし、他の実施形態では、システム100の代替要素は、説明されたステップを実行することができ、またはシステム100の単一の要素は、説明されたステップの1つまたは複数を実行することができる。
ステップ1602で、クライアントシステム190は、トランザクションイベントを含むイベントメッセージを送信することができる。例えば、支払いクライアントシステム190Aは、顧客ID、IPアドレス、クレジットカード番号、小売業者ID、および金額を含むトランザクションイベントを送信することができる。ステップ1604で、キー抽出器235(図2)は、トランザクションイベントのためのイベント/キーのペアを有するデータストリームを生成することができる。キー/ペアイベントに基づいて、アキュムレータ348は、ステップ1602のトランザクションイベントに基づいて変数を更新することができる。例えば、ステップ1606で、アキュムレータ348は、トランザクションイベント/キーのペアに基づいて、トランザクションの量または数を追跡する状態変数を更新することができる。アキュムレータ348はまた、更新された状態変数をデータベース180に格納することができる。
ここで図17を参照すると、開示された実施形態と一致する、トランザクションイベントに基づく状態変数の更新を示すプロセスフロー図が示されている。いくつかの実施形態では、図17に示すように、システム100(図1)の異なる要素は、フロー1700の特定のステップを実行することができる。例えば、サービスシステム105の構成要素は、1つまたは複数のステップを実行することができるが、クライアントシステム190などの他のシステムは、他のステップを実行することができる。しかし、他の実施形態では、システム100の代替要素は、説明されたステップを実行することができ、またはシステム100の単一の要素は、説明されたステップの1つまたは複数を実行することができる。
ステップ1702で、クライアントシステム190は、注文イベントを含むイベントメッセージを送信することができる。例えば、注文クライアントシステム190Dは、注文イベント、および/または注文キャンセルイベントを送信することができる。注文イベントは、顧客ID、IPアドレス、アイテム識別、クライアント情報、および金額が含むことができる。ステップ1704で、キー抽出器235は、注文イベントのためのイベント/キーのペアを有するデータストリームを生成することができる。キー/ペアイベントに基づいて、アキュムレータ348(図3)は、ステップ1702の注文イベントに基づいて変数を更新することができる。例えば、ステップ1706で、アキュムレータ348は、注文イベント/キーのペアに基づいて、トランザクションの量または数を追跡する状態変数を更新することができる。アキュムレータ348はまた、更新された状態変数をデータベース180に格納することができる。
いくつかの実施形態では、フロー1600および1700は、並行して実行することができ、トランザクションおよび注文イベントの両方に関連する状態変数を同時に更新することができる。
ここで図18を参照すると、開示された実施形態と一致する、アラート処理フローを示すプロセスフロー図が示されている。いくつかの実施形態では、図18に示すように、システム100(図1)の異なる要素は、フロー1800の特定のステップを実行することができる。例えば、サービスシステム105の構成要素は、1つまたは複数のステップを実行することができるが、クライアントシステム190などの他のシステムは、他のステップを実行することができる。しかし、他の実施形態では、システム100の代替要素は、説明されたステップを実行することができ、またはシステム100の単一の要素は、説明されたステップの1つまたは複数を実行することができる。
ステップ1802で、クライアントシステム190は、HTTP要求をサービスシステム105に送信することができる。例えば、支払いクライアントシステム190Aは、トランザクションのHTTP要求をサービスシステム105に送信することができる。HTTP要求は、REST APIなどのAPIを使用して送信され得る。ステップ1804で、不正行為/リスク検出サービス344は、ルックアップコマンドを使用してデータベース180から変数を要求することができる。例えば、図16〜図17に関連して前述したように、アキュムレータ348は、状態変数を計算し、データベース180に格納することができる。ステップ1804で、不正行為/リスク検出サービス344は、データベース180から変数を要求することができ、データベース180は、ステップ1806におけるHTTP要求に関連する変数を返すことができる。
不正行為/リスク検出サービス344は、図12〜図13に関連してさらに説明するように、モデルおよび/または予測規則を使用して、ステップ1806で受信された変数に基づいて応答を決定することができる。ステップ1808で、不正行為/リスク検出サービス344は、応答をクライアントシステム190に送信することができる。応答は、不正行為/リスク検出サービス344に格納された状態変数、モデルおよび規則、ならびにHTTP要求で提供された情報に基づくことができる。
本開示の別の態様は、実行されると、1つまたは複数のプロセッサに上記のように方法を実行させる命令を格納する非一時的なコンピュータ可読媒体に向けられている。コンピュータ可読媒体は、揮発性もしくは不揮発性、磁気、半導体、テープ、光学、取り外し可能、取り外し不可能、または他のタイプのコンピュータ可読媒体もしくはコンピュータ可読記憶装置を含むことができる。例えば、コンピュータ可読媒体は、開示されるように、コンピュータ命令が格納されている記憶ユニットまたはメモリモジュールであってもよい。いくつかの実施形態では、コンピュータ可読媒体は、コンピュータ命令が格納されたディスクまたはフラッシュドライブであってもよい。
開示されたシステムおよび関連する方法に対して様々な修正および変形を行うことができることは当業者には明らかであろう。他の実施形態は、開示されたシステムおよび関連する方法の明細書および実施を考慮することから、当業者には明らかであろう。明細書および実施例は例示としてのみみなされることが意図されており、真の範囲は以下の特許請求の範囲およびそれらの同等物によって示されている。
さらに、例示的な実施形態が本明細書で説明されてきたが、本開示に基づいて当業者によって理解されるように、同等の要素、修正、省略、(例えば、様々な実施形態にわたる態様の)組み合わせ、適応、および/または変更を有する任意のおよびすべての実施形態の範囲が可能である。例えば、例示的なシステムに示す構成要素の数および向きは変更されてもよい。さらに、添付の図面に示されている例示的な方法に関して、ステップの順序およびシーケンスを変更することができ、ステップを追加または削除することができる。さらに、コンピュータ化された方法の例示的な実施形態のいくつかは、例示的なスクリプトおよびルーチンを説明するためにJava言語を使用して説明されたが、開示された方法およびシステムは、代替言語を使用して実装されてもよい。開示された実施形態は、Javaに加えて、1つまたは複数のプログラミング言語を使用することができる。例えば、開示された実施形態はまた、Python、C、C++、C#、R、Go、Swift、Ruby、および/またはそれらの組み合わせを使用して実装され得る。
したがって、前述の説明は、例示だけの目的で提示されている。これは、網羅的ではなく、開示された正確な形態または実施形態に限定されない。当業者には、開示された実施形態の明細書および実施を考慮することによって、修正および適合が明らかになろう。
特許請求の範囲は、特許請求の範囲で使用される文言に基づいて広く解釈されるべきであり、本明細書に記載された例に限定されず、これらの例は非排他的であると解釈されるべきである。さらに、開示された方法のステップは、ステップを並べ替えること、および/またはステップを挿入または削除することを含む、任意の方法で修正されてもよい。