JP6912591B2 - リスク管理制御方法及びデバイス - Google Patents

Description

本出願は、インターネット情報処理技術及びコンピュータ技術の分野に関連しており、特に、リスク管理制御方法及びデバイスに関連している。

リスク管理制御は、支払いセキュリティ管理の重要な構成要素であり、リスクを伴うトランザクション・イベントに対してどのような管理制御アクション（すなわち、管理制御決定）が取られる必要があるかを決定することを含む。管理制御アクションは、ダイレクト・パス、テキスト・メッセージ検証、顔検証などの、トランザクション・イベントに対するさまざまな検証を実行することを含むが、これらに限定されない。

管理制御決定は、支払いアクションのリスク制御のためのセキュリティ・バルブであり、カスタマー・エクスペリエンスの直接的接点でもある。管理制御決定の健全性は、リスク制御結果及びユーザ・エクスペリエンスに直接影響を与える。理想的な管理制御決定は、一方では、安全なトランザクション・イベントの場合、できるだけ多くのダイレクト・パスが出力されるべきであり、もう一方では、リスクを伴うトランザクション・イベントの場合、回避することが困難である、できるだけ多くの検証モードが出力されるべきであるという、２つの態様を含むことがある。これら２つの態様は、管理制御決定のユーザ・エクスペリエンス及びリスク制御の品質に、それぞれ影響を与える。

従来の管理制御決定は、次の２つのタイプに分類することができる。第一に、管理制御決定のルールベース・モード又はルール・ツリーベース・モードであり、すなわち、管理制御決定のいくつかのルールが、トランザクションの理解に基づいて最初に提供される。それらのルールは、トランザクションの量、トランザクションの状況、リスクの大きさなどの要素を含むが、これらに限定されず、その後、特定のトランザクション・イベントが、ルール又はルール・ツリーと比較され、特定のルール又はルール・ツリーにおける定義が満たされた場合、対応する管理制御モードが出力される。例えば、トランザクション・イベントが、ライドヘイリング・サービス用の低リスク、少量のオフライン・トランザクションである場合、ルール・ツリーでの対応する管理制御アクションが、検証用のテキスト・メッセージを出力することがある。第二に、第１のモードが、ユーザ調査などと組み合わせられ、調査結果に従ってルールを調整する。調査結果は、ある程度まで、特定のタイプのユーザの個人向けの内容を含むことができるため、このモードは、カスタマー・エクスペリエンスを改善することができる。

管理制御決定の上記２つのモードには、次の欠点がある。第一に、ルールベースの管理制御決定方法は、ルール開発者によるトランザクションの理解に大きく依存するが、そのような理解は、必然的に誤りを招きやすい。さらに、このルールベースの方法は、トランザクションの動的変化を考慮せず、それに応じてルールがタイムリーに調整されないことがある。これは、誤検出又は検出漏れにつながる。検出漏れは、管理制御結果及びトランザクションのセキュリティに直接影響を与え、誤検出は、カスタマー・エクスペリエンスに影響を与える。第二に、調査に基づく管理制御決定には、調査コストが高いという欠点があり、調査のサンプル・サイズが、選択バイアスを防ぐほど十分に大きくないことがある。したがって、リスク管理制御結果及びカスタマー・エクスペリエンスには、改善の余地がある。

本出願は、従来の管理制御決定が主観的理解に過度に依存しているという問題を解決するためのリスク管理制御方法及びデバイスを提供する。さらに、本出願は、トランザクションのセキュリティ及びユーザ・エクスペリエンスに同時に対処できないという従来技術における問題も解決できる。本出願は、管理制御決定で、複数のトランザクションの基準を同時に考慮する。例えば、本出願は、管理制御を回避する不正なデバイスによって引き起こされる金銭的損失を最小限に抑え、正規のユーザへの干渉を最小限に抑え、本人確認のコストを最小限に抑えることができる。言い換えると、本出願によって解決される問題は、トランザクションのセキュリティ、ユーザ・エクスペリエンスなどの最適化された基準を使用して、最適な管理制御モードを生成する方法である。

本出願の実施形態は、
管理及び制御される対象イベントを受信することと、
対象イベントに従って候補検証モードのセットを決定することと、
候補検証モードのセットのうち少なくともいくつかの候補検証モードの出力加重を決定することと、
候補検証モードに対応する出力加重に従って、候補検証モードのセットから、対象イベントに対するリスク管理制御の検証モードを決定することと、を含んでいるリスク管理制御方法を提供する。

本出願の実施形態は、
管理及び制御される対象イベントを受信するように構成された受信モジュールと、
候補検証モードのセットを決定し、候補検証モードのセットのうち少なくともいくつかの候補検証モードの出力加重を決定するように構成された処理モジュールと、
候補検証モードに対応する出力加重に従って、候補検証モードのセットから、対象イベントに対するリスク管理制御の検証モードを出力するように構成された出力モジュールと、を備えているリスク管理制御デバイスをさらに提供する。

本出願の実施形態は、本出願に従うリスク管理制御方法を使用する、トランザクション管理制御方法をさらに提供する。

本出願の実施形態は、本出願に従うリスク管理制御デバイスを使用する、トランザクション管理制御デバイスをさらに提供する。

本出願の実施形態によって使用される上記の技術的解決策のうちの少なくとも１つは、以下の有利な効果を実現できる。

本出願の実施形態では、管理制御決定プロセスの間の異なる検証モードが定量化されて重み付けされ、過去の意思決定プロセスにおける主観的理解への過度の依存を防ぐ。定量化プロセスの間に既存のデータを使用することによって、リスクへの適応性、機器の可用性、ユーザの嗜好、状況への適応性などの複数の要因を、管理制御決定で定量的に考慮することができる。一方、定量的モードで複数のトランザクション・インジケータを同時に考慮することで、例えば、管理制御を回避する不正なユーザによって引き起こされる金銭的損失を減らすことができ、正規のユーザへの干渉を減らすことができ、それによってユーザ・エクスペリエンスを改善し、本人認証計算のコストを削減する。

同時に、本出願は、ルール開発者によるトランザクションの理解への依存を最小限に抑えることができるデータに基づく。プロセスが定量化されるため、既存のデータを可能な限り多く利用することができる。本出願の解決策は、調整及び拡張が容易である。新しいトランザクションの状況、新しい本人認証モードなどのためのさまざまな変形を、本出願の定量化の概念に、すべて簡単に組み込むことができる。

本明細書において説明される添付の図面は、本出願のさらなる理解を可能にし、本出願の一部を構成するために使用される。本出願の実施形態例及び実施形態例の説明は、本出願を説明するために使用され、本出願の不適切な限定を構成しない。

本出願のいくつかの実施形態によるリスク管理制御方法のフローチャートである。 本出願のいくつかの実施形態による支払いリスク管理制御方法のフローチャートである。 本出願のいくつかの実施形態によるリスク管理制御デバイスの概略構造図である。 本出願のいくつかの実施形態による支払いリスク管理制御デバイスの概略構造図である。

本出願の目的を達成するために、本出願の実施形態は、リスク管理制御方法を提供する。

当業者が本出願の技術的解決策をよく理解できるようにするために、以下では、本出願の実施形態において添付の図面を参照して、本出願の実施形態における技術的解決策が明確かつ完全に説明される。説明される実施形態が本出願の実施形態すべてではなく一部の実施形態にすぎないということは、明らかである。本出願の実施形態に基づいて、創造的な努力を伴わずに当業者によって得られる他のすべての実施形態は、本出願の範囲に含まれるものとする。

本出願の実施形態では、リスク管理制御は、リスク・イベント自体に従って意思決定を実行するため、又はリスク・イベントに対していずれかの管理制御アクションを選択するための任意のプロセスを含む。２つ以上の任意選択的な管理制御アクションが存在してよい。さまざまな状況において、オンライ・トランザクション及び支払いなどのための、セキュリティ・チェック、アカウントのログイン、本人認証などの複数のリスク・イベントが存在する。前述したイベントごとに、複数の任意選択的な管理制御モードが存在してよいということが、理解されるべきである。言い換えると、リスク及び管理制御決定を含む任意のイベントが、本出願の実施形態における対象イベントになる可能性がある。それらのイベントは、本明細書において限定されない。

図１に示されているように、ステップ１０１で、ユーザはイベント（すなわち、対象イベント）を開始する。リスク管理制御システムがイベントを受信した場合、リスク管理制御システムは、イベントに対して識別を実行する。識別される内容は、デバイス情報、リスク・タイプ情報などを含んでよいが、これらに限定されない。その後のリスク制御によって必要とされるパラメータに従って、識別される内容が決定されるということが、理解されるべきである。本出願の一実施形態では、識別される内容は、定量化において具体的に考慮される要因である。考慮されるそれらの要因は、下の例においてリストされ、ここでは詳述されない。

ステップ１０２で、ステップ１０１の識別結果に従って、候補検証モードのセットが決定される。候補検証モードのセットは、可能性のあるすべての検証モードのセットであるか、又は可能性のあるすべての検証モードの部分的セットであってよい。可能性のあるすべての検証モードの部分的セットが選択された場合、識別結果に従って、いくつかの不適切な検証モードが除外されるのが好ましい。いくつかの不適切な検証モードを除外する理由としては、リスク・タイプの要因及びデバイスの要因などが挙げられる。

さらに、候補検証モードのセットを決定することは、対象イベントに関連付けられたリスク・タイプを識別し、このリスク・タイプに従ってリスク・タイプに関連付けられた第１の検証モードのセットを決定し、対象イベントを開始及び／又は処理するデバイスのデバイス・タイプを識別し、このデバイス・タイプに従ってデバイス・タイプに関連付けられた第２の検証モードのセットを決定することと、第１の検証モードのセット及び第２の検証モードのセットに対して交差プロセスを実行し、交差プロセスの結果として候補検証モードのセットを設定することとを含んでよい。

ステップ１０２で、ステップ１０１で識別された情報に従って、イベントに対して適用可能な管理制御モード（すなわち、第１の検証モードのセット）及び使用可能な管理制御モード（すなわち、第２の検証モードのセット）が決定されるのが好ましい。適用可能な管理制御モードとは、管理制御モードに対するイベントのリスク・タイプの影響を考慮することによって決定される管理制御モードのセットのことを指す。使用可能な管理制御モードとは、イベントにおいて対象イベントを開始及び／又は処理するデバイスのデバイス・タイプを考慮することによって決定される管理制御モードのことを指す。例えば、検証モードのセットは、デバイス内のハードウェア又はソフトウェアが対応する検証モードをサポートするかどうかを考慮した後に決定される。対象イベントを開始するデバイスとは、イベントを起動又は開始する関係者のデバイスのことを指し、対象イベントを処理するデバイスとは、受信されたイベントが完了する前に必要になる受信されたイベントの処理を含んでいる、関係者のデバイスのことを指す。対象イベントを開始及び／又は処理するデバイスを考慮する必要がある理由は、実際の状況では、検証される対象が変化することがあるからである。

当業者は、ステップ１０２でのイベントに対する適用可能な管理制御モード及び使用可能な管理制御モードの決定が、イベントに対する候補検証モードのセットを決定するためであり、このステップでの決定方法が唯一の方法でないということを理解するはずである。例えば、当業者は、適用可能な管理制御モードを省略し、使用可能な管理制御モードのみを候補検証モードのセットとして使用してよい。

ステップ１０３で、ステップ１０２で決定された２つの管理制御モードのセット（すなわち、適用可能な管理制御モード及び使用可能な管理制御モード）に対して交差スクリーニングを実行し、両方のセットに含まれている管理制御モードを、対象イベントに対して候補検証モードのセットとして選択するのが好ましい。適用可能な管理制御モードであると同時に、使用可能な管理制御モードでもある管理制御モードのセットが、候補検証モードのセットとして選択されてよい。

ステップ１０４で、識別されたイベントに従って、定量化される要素のイベント属性加重が決定される。定量化される要素は、意思決定時に考慮する必要がある要因である。さまざまな適用状況では、定量化プロセスの間に、異なる要因を考慮する必要がある。一般に、それらの要因は、対象イベントに対応するユーザ・タイプ、対象イベントに対応する状況タイプ、及び対象イベントに対応するユーザの嗜好を含むが、これらに限定されない。それに応じて、ユーザ・タイプに従ってユーザ・タイプ加重が決定されてよく、状況タイプに従って状況タイプ加重が決定されてよく、嗜好に従って嗜好加重が決定されてよい。一般に、考慮される要素として使用される要素は、管理制御決定に関する考慮に含まれる要因である。各要因のイベント属性加重は、リスク管理制御全体におけるその要因の重要性を表す。イベント属性加重は、通常、すべての要因が考慮された後に決定される。決定されたイベント属性加重は、すべての管理制御モードで同じであり、異なる検証モードに対して変化しない。イベント属性加重は、一般に、考慮される各要素の重要性を反映し、考慮される要素の相対的重要性を反映する。言い換えると、考慮される要素が高いイベント属性加重を有しているということは、管理制御決定に対するこの要素の影響が高いということを示す。

ステップ１０５で、ステップ１０３で決定された候補検証モードのセットに対して、定量的ランク付けが実行される。ステップ１０５で、候補検証モードごとに、管理制御属性加重ベクトルが最初に取得される。管理制御属性加重ベクトルは、定量化されるすべての要素の管理制御属性加重によって形成される。Ｎ個の定量化される要素は、Ｎ個の管理制御属性加重に対応する。すなわち、管理制御属性加重ベクトルは、Ｎ個の次元又は要素を有している。候補検証モードの管理制御属性加重ベクトルが取得された後に、このベクトルに、定量化される要素のイベント属性加重によって形成されたベクトルを乗じて、検証モードごとに出力加重を取得する。イベント属性加重はイベントの属性を反映するが、管理制御属性加重は、さまざまな管理制御モード（すなわち、管理制御モードの属性）間の比較をより反映する。高い管理制御属性加重は、管理制御モードが、その管理制御属性加重に対応する定量化された要素により多くの注意を払うということを示す。

管理制御属性加重ベクトルは、過去のビッグ・データに従って事前に推定されたベクトルであることが好ましい。例えば、管理制御属性加重ベクトルは、遺伝的アルゴリズム又はその他の最適化アルゴリズムを使用して取得されてよい。例えば、過去のビッグ・データ又は過去のビッグ・データ内のいくつかのサンプルが取得された後に、何らかの基準の実際の値が集計されてよい。何らかの基準のしきい値又は制約（例えば、検証モードが決定されるパーセントなど）が与えられるという条件で、管理制御属性加重を取得するように、目標基準（すなわち、パス率などの、事前に設定された基準）が最適化されてよい。例えば、管理制御属性加重ベクトルを取得する最適化プロセスは、次のように表されてよい。
Ｉｎｄｅｘ２＜０．０２％を前提として、Ｍｉｎ Ｉｎｄｅｘ１ （式１）

ここで、Ｉｎｄｅｘ１は目標基準を意味し、Ｉｎｄｅｘ２は制約基準を意味する。言い換えると、上記の最適化プロセスの意味は、特定の制約基準（Ｉｎｄｅｘ２）が０．０２％未満であるという条件で、目標基準（Ｉｎｄｅｘ１）を最小化することによって、前述した管理制御属性加重が最適化され、検証モードの管理制御属性加重ベクトルを取得できるということである。

上記に類似するアルゴリズムを使用して過去のビッグ・データ推定することによって、検証モードごとに管理制御属性加重ベクトルが取得されてよい。例えば、次のようになる。
Ｗ_ｉ＝（ｗ_ｉ１， ｗ_ｉ２， ｗ_ｉ３…） （式２）

ここで、ｗ_ｉ１， ｗ_ｉ２， ｗ_ｉ３…はそれぞれ、第１、第２、第３、…のイベント属性加重の管理制御属性加重である。したがって、検証モードごとに、検証モードに対応する定量化ベクトルを介して、検証モードの加重を計算できる。第ｉの検証モードの場合、出力加重（又は出力スコア）は、次のようになる。
Ｓｃｏｒｅ（ｉ）＝ｗ_ｉ１＊Ｋ_１＋ｗ_ｉ２＊Ｋ_２＋ｗ_ｉ３＊Ｋ_３＋３ｗ （式３）

式３のＫ_１、Ｋ_２、Ｋ_３…は、定量化される各要因のイベント属性加重をそれぞれ表す。

ある対象イベントに関して、合計で３つの決定された候補検証モードが存在すると仮定すると、前述した方法を使用して各候補検証モードの加重が計算されて、Ｓｃｏｒｅ（１）、Ｓｃｏｒｅ（２）、及びＳｃｏｒｅ（３）を取得し、Ｓｃｏｒｅ（１）、Ｓｃｏｒｅ（２）、及びＳｃｏｒｅ（３）が比較されるか、又はランク付けされる。最高の加重を有する検証モードが、最終的に出力される検証モードとして選択される。

定量的ランク付けのプロセスで、定量化パラメータにおいて過去のビッグ・データが考慮されるため、本出願は、ルール開発者によるトランザクションの理解への依存を最小限に抑えることができる。同時に、本出願の定量化パラメータを決定するプロセスで、主要なトランザクション制約がパラメータとして入力されてよく、その後、異なるトランザクション要求に従って定量化パラメータが調整される。

ステップ１０６で、ステップ１０５の定量的ランク付けの結果に従って、最後の管理制御決定（すなわち、管理制御アクション又は検証モードの出力）が行われる。

この方法は、管理制御属性加重をテストすることをさらに含むのが好ましい。テスト・プロセスの間に、過去のサンプル・データ（すなわち、テストに関する過去のイベント）が最初に取得される。このデータは、例示的な管理制御において識別されたイベント及びイベントに対して出力された検証モードを含んでよい。次に、テスト対象の管理制御属性加重ベクトルを使用して、過去のサンプルに対して定量化が実行され（定量化プロセスは、ステップ１０１〜１０６において示された定量化プロセスと同じである）、テスト検証モードを取得する。評価対象の管理制御属性加重ベクトルは、評価される管理制御出力サンプルと例示的な管理制御出力サンプルを比較することによってテストされ得る。さらに、管理制御属性加重ベクトルが、テスト結果に従って調整される（すなわち、管理制御属性加重ベクトルのうち一部又は全部の加重が調整される）。言い換えると、各イベント属性加重の重要性が調整される。

このテストは、例えば、すべての過去のイベントからテスト用のテスト・イベントを取得すること（すなわち、特定の過去のイベントをテスト対象として取得すること）を含むのが好ましい。テスト・イベントごとに決定されて記録された検証モードに従って、指定された条件を満たすテスト・イベントの第１の量が決定される。第１の量は、実際に行われた管理制御モードの量である。各テスト・イベントに対して決定されるテスト検証モードは、管理制御属性加重に基づいて決定され、テスト検証モードに従って、指定された条件を満たすテスト・イベントの第２の量が決定される。第２の量は、本出願の実施形態において定量化方法を使用して決定される管理制御モードの量である。第１の量及び第２の量が比較され、比較結果に従って管理制御属性加重が調整される。テスト・プロセスの間に、異なるテスト・イベントを選択し、テスト・イベントに対して指定された条件を決定することによって、テスト・イベントが属するイベント・カテゴリ内の本出願における管理制御属性加重ベクトルの有効性を確認することができると同時に、管理制御の効果の有効性が第２の量によって示される。

一方、多数のサンプル及び評価プロセスに基づいて、本発明者は、次の４つのテスト・イベントのサンプル及び対応する指定された条件を評価基準として使用することを提案する。

１．テスト・イベントは、検証にパスした安全な過去のイベントであり、指定された条件は、決定される検証モードがダイレクト・パスであることである。この基準は、本人確認に成功した無害のサンプルの定量化ベクトルに基づいて、ダイレクト・パスのより多くの管理制御モードを決定できるかどうかを示す。

２．テスト・イベントは、検証にパスしていない安全な過去のイベントであり、指定された条件は、決定される検証モードがダイレクト・パスであるか、又は例示的な検証モードと異なる検証モードがさらに決定されることである。この基準は、本人確認に失敗した無害のサンプルの定量化ベクトルに基づいて、ダイレクト・パスのより多くの管理制御モード又は例示的な検証モードと異なる検証モードを決定できるかどうかを示す。例示的な検証モードとは、すでに行われた過去のイベントにおいて出力された検証モードのことを指す。

３．テスト・イベントは、ダイレクト・パスしたリスクを伴う過去のイベントであり、指定された条件は、決定される検証モードがダイレクト・パス以外の検証モードであることである。この基準は、例示的な管理制御出力においてリスクを伴っていると識別されたが、ダイレクト・パスした不正なサンプルに対して、ダイレクト・パス以外の検証モードを決定できるかどうかを示す。

４．テスト・イベントは、検証にパスしたリスクを伴う過去のイベントであり、指定された条件は、決定される検証モードが例示的な検証モードと異なる検証モードであることである。この基準は、例示的な管理制御出力においてパスした不正なサンプルに対して、例示的な検証モードと異なる管理制御モードを決定できるかどうかを示す。

評価基準１は、無害のサンプルに対して、評価される定量化ベクトルを介して正常な検証モードの出力の数を減らすことができることを示す。無害のサンプルはリスクを伴わないトランザクション・イベントであるため、理想的な結果は、すべての無害のサンプルに対してダイレクト・パスが出力されることであるが、実際にはそれを実現することは困難である。したがって、できるだけ多くのダイレクト・パスを出力するということは、無害のサンプルを含むトランザクションにおいて、定量化ベクトルがユーザ・エクスペリエンスを改善できるということを示す。

評価基準２は、評価基準１に類似している。無害のサンプルに対して、できるだけ多くのダイレクト・パスを出力することは、ユーザ・エクスペリエンスを改善するために達成するべき目標である。一方、本人確認に失敗した無害のサンプルの管理制御のタイプに対して、本人確認のための追加出力又は失敗したトランザクションの出力は、ユーザ・エクスペリエンスの劣化につながる。したがって、評価される定量化ベクトルを介して、例示的な検証モードと異なる管理制御モードを出力して、本人確認の成功の可能性を増やすことができる場合、ユーザ・エクスペリエンスの改善を実現できるということが、理解されるべきである。

評価基準３は、定量化ベクトルのセキュリティを評価する。不正なサンプルに対してダイレクト・パスを出力するモードは、望ましくない。したがって、評価される定量化ベクトルが、例示的な管理制御において、リスクを伴っていると識別されたが、ダイレクト・パスの出力を含んでいる不正なサンプルに対して、テキスト・メッセージ検証又は顔検証などの、ダイレクト・パス以外の結果を出力できる場合、定量化ベクトルが管理制御のセキュリティを改善できることを示しているということが、理解されるべきである。

評価基準４は、同様に、定量化ベクトルのセキュリティを評価する。携帯電話の紛失、ウイルス、又は何らかの管理制御情報を取得するハッカーなどの場合に、管理制御の例示的な出力において、検証にパスする不正なサンプルが発生することがある。このタイプのイベントの発生は、もともと出力されている管理制御モードがリスクを識別できないということを示す。評価される定量化ベクトルを介して、元の管理制御モードと異なる管理制御モードを出力できる場合、少なくとも、リスクを識別する可能性を改善する。携帯電話の紛失を例にとってみると、元の管理制御決定がテキスト・メッセージ検証を出力する場合、金銭的損失を防ぐことができないのは明らかである。しかし、定量化ベクトルを介して生成された管理制御モードが顔検証又は失敗したトランザクションである場合、この損失を防ぐことができ、セキュリティも改善される。

加えて、本出願の実施形態における技術的解決策が適用可能な適用状況として、支払い用のデバイスを使用する特定のトランザクション・イベントにおいて、対象イベントがトランザクション支払いイベントであってよい。このトランザクション・イベントは、例えば、業者が支払いを開始し、ユーザが支払い完了するプロセスであってよい。

図２に示されているように、ステップ２０１で、ユーザがトランザクション活動などのイベントを開始し、通常、リスク制御システムが、イベントの受信時にイベントを識別する。識別される内容は、デバイス情報、リスク・タイプ情報などを含んでよいが、これらに限定されない。その後のリスク制御によって必要とされるパラメータに従って、識別される内容が決定されるということが、理解されるべきである。本出願の一実施形態では、識別される内容は、定量化において具体的に考慮される要因である。考慮されるそれらの要因は、下の例においてリストされ、ここでは詳述されない。

例えば、候補検証モードのセットを決定するステップは、トランザクション支払いイベントに対応するリスク・タイプを識別することと、リスク・タイプ（例えば、トランザクション制限、オンライン／オフライン、リスクの大きさなど）に従ってリスク・タイプに関連付けられた第１の検証モードのセットを決定することと、トランザクション支払いイベントを開始及び／又は処理するデバイス（例えば、携帯電話）のデバイス・タイプを識別することと、デバイス・タイプに従ってデバイス・タイプに関連付けられた第２の検証モードのセットを決定することと、第１の検証モードのセット及び第２の検証モードのセットに対して交差プロセスを実行することと、交差プロセスの結果を候補検証モードのセットとして使用することとを含んでよい。

１つの例では、ステップ２０２で、ステップ２０１での識別結果に従って、イベントに対して適用可能な管理制御モード（すなわち、第１の検証モードのセット）及び使用可能な管理制御モード（すなわち、第２の検証モードのセット）が決定される。候補検証モードのセットは、可能性のあるすべての検証モードのセットであるか、又は可能性のあるすべての検証モードの部分的セットであってよい。可能性のあるすべての検証モードの部分的セットが選択された場合、識別結果に従って、いくつかの不適切な検証モードが除外されるのが好ましい（例えば、支払いを完了するユーザによって使用される携帯電話が、指紋検証用のハードウェアもソフトウェアも含んでいない場合、指紋検証モードはこのユーザには不適切である）。いくつかの不適切な検証モードを除外する理由としては、リスク・タイプの要因及びデバイスの要因などが挙げられる。

ステップ２０２で、ステップ２０１で識別された情報に従って、イベントに対して適用可能な管理制御モード及び使用可能な管理制御モードが決定されるのが好ましい。適用可能な管理制御モードとは、管理制御モードに対するイベントのリスク・タイプの影響を考慮することによって決定される管理制御モードのセットのことを指す。例えば、トランザクションが紛失した携帯電話に関連付けられているというリスクが存在することが、イベントにおいて識別される場合、適用可能な管理制御モードのセットがテキスト・メッセージ検証モードを含むべきでないということが、理解されるべきである。使用可能な管理制御モードとは、対応する検証モードが、イベントにおいて管理及び制御される対象のハードウェア又はソフトウェアによってサポートされるかどうかを考慮することによって決定される、検証モードのセットのことを指す。例えば、イベントにおいて適用可能な携帯電話が、指紋検証をサポートするコンポーネントを含んでいない場合、使用可能な管理制御のセットが指紋検証モードを除外するべきであるということが、理解されるべきである。適用可能な管理制御モード及び使用可能な管理制御モードの決定において、管理制御モードに対するリスク・タイプの影響が考慮されるため、トランザクションのセキュリティをある程度まで改善することができ、そのため、紛失した携帯電話又は盗まれた携帯電話を使用するトランザクションによって引き起こされる金銭的損失を、ある程度まで防ぐことができる。一方、ハードウェア及びソフトウェアが本人確認モードをサポートするかどうかをチェックすることによって、サポートされていない検証モードが出力されず、ユーザ・エクスペリエンスをある程度まで改善することもできる。

ステップ２０３で、ステップ２０２で決定された２つの管理制御モードのセット（すなわち、適用可能な管理制御モード及び使用可能な管理制御モード）に対して交差プロセスを実行し、両方のセットに含まれている管理制御モードを、対象イベントに対して候補検証モードのセットとして選択するのが好ましい。例えば、ある状況では、可能性のあるすべての管理制御モードが、０．ダイレクト・パス、１．テキスト・メッセージ検証、２．知識ベース認証（ＫＢＡ：Ｋｎｏｗｌｅｄｇｅ−Ｂａｓｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）、３．顔検証、４．指紋検証、５．失敗したトランザクションの出力、ならびに６．失敗したトランザクションの出力及び預金残高の凍結を含んでよい。ステップ２０２で、リスク・タイプに従って決定された適用可能な管理制御モードが、０．ダイレクト・パス、１．テキスト・メッセージ検証、３．顔検証、及び５．失敗したトランザクションの出力を含んでよい。ステップ２０２で、イベントにおいてデバイス及びソフトウェアなどの要因に従って決定された使用可能な管理制御モードが、０．ダイレクト・パス、１．テキスト・メッセージ検証、２．知識ベース認証（ＫＢＡ）、及び５．失敗したトランザクションの出力を含んでよい。ステップ２０３で、前述した２つの管理制御モードのセットに対して交差プロセスを実行し、０．ダイレクト・パス、１．テキスト・メッセージ検証、及び５．失敗したトランザクションの出力であってよい、出力検証セットを決定してよい。決定された出力検証セットが、意思決定のための候補セットとして使用され、出力検証セットは、トランザクションのセキュリティ及びユーザ・エクスペリエンスの包括的な考慮を反映する。

ステップ２０４で、識別されたイベントに従って、定量化される要素の加重（すなわち、イベント属性加重）が決定される。この要素は、意思決定のために考慮される必要がある要因であり、各要素のイベント属性加重は、リスク管理制御全体における要因の重要性を表す。イベント属性加重は、通常、すべての要因が考慮された後に決定される。決定されたイベント属性加重は、すべての管理制御モードで同じであり、異なる検証モードに対して変化しない。それらの要因は、対象イベントに対応するユーザ・タイプ、対象イベントに対応する状況タイプ、及び対象イベントに対応するユーザの嗜好を含むが、これらに限定されない。それに応じて、ユーザ・タイプに従ってユーザ・タイプ加重が決定され、状況タイプに従って状況タイプ加重が決定され、嗜好に従って嗜好加重が決定される。一般に、考慮される要素として使用される要素は、管理制御決定に関する考慮に含まれる要因である。イベントにおいて検証されるユーザのユーザ・タイプを例にとってみると、ユーザ・タイプは、経験又は過去のデータに従って、学生、若年者、中年者、高齢者、身体障害を有するその他の人などに事前に分類されてよく、各ユーザ・タイプに関連付けられた適用可能なユーザ加重（又は、適用可能なユーザ・スコア）が、各タイプのユーザに割り当てられてよい。同様に、イベントにおける状況タイプが、オフライン支払い及びオンライン支払いに分類されてもよく、適用可能な状況加重（又は、適用可能な状況スコア）が、各タイプの状況に割り当てられてよい。同様に、ユーザの嗜好が、テキスト・メッセージ検証に対する嗜好、指紋検証に対する嗜好、顔検証に対する嗜好などに分類されてもよく、ユーザ嗜好加重（又は、ユーザ嗜好スコア）が、各タイプの状況に割り当てられてよい。前述したユーザ・タイプ、状況タイプ、及びユーザの嗜好の分類だけが、分類ではないということが、理解されるべきである。実際、分類は、経験、過去のデータ、計算コストなどのさまざまな態様を包括的に考慮することによって、決定されてよい。例えば、状況タイプでは、ライドヘイリング、ショッピング、食品飲料サービスなどのさまざまなトランザクション・タイプが、オフライン支払いでさらに考慮されてよく、一方、オンライン支払いが、オンライン・ショッピング、クレジット・カードでの支払いなどにさらに分割されてもよい。定量化される各要素の分類ごとに、加重が、次のように事前に設定されてよい。

ステップ２０５で、ステップ２０３で決定された候補検証モードのセットに対して、定量的ランク付けが実行される。ステップ２０５で、候補検証モードごとに、管理制御属性加重ベクトルが最初に取得される。管理制御属性加重ベクトルは、定量化されるすべての要素の管理制御属性加重によって形成される。Ｎ個の定量化される要素は、Ｎ個の管理制御属性加重に対応してよい。候補検証モードの管理制御属性加重ベクトルが取得された後に、このベクトルに、定量化される要素のイベント属性加重によって形成されたベクトルを乗じる。

管理制御属性加重ベクトルは、過去のビッグ・データに従って事前に推定されたベクトルであることが好ましい。例えば、管理制御属性加重ベクトルは、遺伝的アルゴリズム又はその他の最適化アルゴリズムを使用して取得されてよい。例えば、過去のビッグ・データ又は過去のビッグ・データ内のいくつかのサンプルが取得された後に、何らかの基準の実際の値（例えば、金銭的損失の量）が集計されてよい。何らかの基準のしきい値又は制約（例えば、検証モードが送信されるパーセントなど）が与えられるという条件で、目標基準（パス率、金銭的損失の量など）が最適化されてよい。例えば、管理制御属性加重ベクトルを取得する最適化プロセスは、次のように表されてよい。
Ｉｎｄｅｘ２＜０．０３％を前提として、Ｍｉｎ Ｃｏｓｔ１ （式４）

ここで、Ｃｏｓｔ１は目標基準を意味し、Ｉｎｄｅｘ２は制約基準を意味する。例えば、Ｃｏｓｔ１は、トランザクション・セットの金銭的損失の総額を意味し、Ｉｎｄｅｘ２は、すべての管理制御モードにおけるテキスト・メッセージ検証モードの出力のパーセントを意味する。言い換えると、上記の最適化プロセスの意味は、すべての管理制御モードにおけるテキスト・メッセージ検証モードの出力のパーセントが０．０３％未満であるという条件で、トランザクション・セットの金銭的損失の総額を最小限に抑えることを目標にして、前述した管理制御属性加重が最適化されるということである。このようにして、テキスト・メッセージ検証モードの管理制御属性加重ベクトルが取得されてよい。

前述したアルゴリズムに類似するアルゴリズムを使用して過去のビッグ・データ推定することによって、検証モードごとに管理制御属性加重ベクトルが取得されてよい。例えば、定量化プロセスにおいて、３つのイベント属性加重を含む定量化ベクトルは、次のようになる。
Ｗ_ｉ＝（ｗ_ｉ１， ｗ_ｉ２， ｗ_ｉ３…） （式５）

ここで、ｗ_ｉ１， ｗ_ｉ２， ｗ_ｉ３はそれぞれ、第１、第２、第３のイベント属性加重の管理制御属性加重である。したがって、管理制御モードごとに、管理制御モードに対応する定量化ベクトルを介して、管理制御モードによって出力される加重を計算できる。第ｉの検証モードの場合、出力加重（又は出力スコア）は、次のようになる。
Ｓｃｏｒｅ（ｉ）＝ｗ_ｉ１＊Ｋ_１＋ｗ_ｉ２＊Ｋ_２＋ｗ_ｉ３＊Ｋ_３ （式６）

式６のＫ_１、Ｋ_２、及びＫ_３は、定量化される各要因のイベント属性加重をそれぞれ表す。イベント属性加重の値が、表１〜表３に示されている。

「高齢者がライドヘイリング料金のオフライン支払いを行う」というトランザクション・イベントの場合、ステップ２０３で決定される出力検証セットは、０．ダイレクト・パス、１．テキスト・メッセージ検証、及び５．失敗したトランザクションの定量化される要素の加重の出力である。管理制御属性加重ベクトルＷ_０、Ｗ_１、及びＷ_５が、それぞれ取得される。管理制御属性加重ベクトルはそれぞれ、（ｗ_０１， ｗ_０２， ｗ_０３）， （ｗ_１１， ｗ_１２， ｗ_１３）、及び（ｗ_５１， ｗ_５２， ｗ_５３）である。定量化される要素のイベント属性加重によって形成されるベクトルは、（Ｘ_４， Ｙ_１， Ｚ_１）である。次に、検証モードごとに、式６に従って出力加重又は出力スコアが計算される。テキスト・メッセージ検証モードを例にとってみると、次のようになる。
Ｓｃｏｒｅ（１）＝ ｗ_１１＊Ｘ_４ ＋ ｗ_１２＊Ｙ_１＋ ｗ_１３＊Ｚ_１ （式７）

同様に、他の２つの候補検証モードの加重が計算され、Ｓｃｏｒｅ（０）及びＳｃｏｒｅ（５）を取得する。次に、Ｓｃｏｒｅ（０）、Ｓｃｏｒｅ（１）、及びＳｃｏｒｅ（５）が比較されるか、又はランク付けされ、最高の加重を有する１つが、最終的に出力される検証モードとして選択される。

定量的ランク付けのプロセスで、定量化パラメータにおいて過去のビッグ・データ（特に、過去のビッグ・データ内の個人向けの要求）が完全に考慮されるため、本出願は、ルール開発者によるトランザクションの理解への依存を最小限に抑えることができる。同時に、本出願の定量化パラメータを決定するプロセスで、主要なトランザクション制約がパラメータとして入力されてよく、その後、異なるトランザクション要求に従って定量化パラメータが調整される。

ステップ２０６で、ステップ２０５での定量的ランク付けの結果（すなわち、どの管理制御アクション又は検証モードが出力されるか）に従って、最終的な管理制御決定がリスク制御システムにフィードバックされる。

この方法は、管理制御属性加重を決定する前に、管理制御属性加重を評価することをさらに含むのが好ましい。この評価プロセスは、本出願の第１の実施形態に類似しているが、過去のイベントがトランザクション支払いイベントであり、検証モードが、トランザクション支払いイベントに適用可能な検証モードであり、関連する指定された条件が、トランザクション支払いにおいて望ましい条件であるという点が異なる。

図３に示されているように、本出願は、管理及び制御される対象イベントを受信するための受信モジュール３０１と、出力検証モードのセットを決定し、対象イベントに従って少なくとも１つのイベント属性加重を決定し、少なくとも１つの事前に設定された管理制御属性加重を取得し、イベント属性加重及び少なくとも１つの事前に設定された管理制御属性加重に従って候補検証モードのセットのうち少なくともいくつかの候補検証モードの出力加重を決定するための処理モジュール３０２と、候補検証モードに対応する出力加重に従って対象イベントの検証モードを出力するように構成された出力モジュール３０３と、を備えている、リスク管理制御デバイスをさらに提供する。

処理モジュールは、対象イベントに対応するリスク・タイプを識別し、このリスク・タイプに従ってリスク・タイプに関連付けられた第１の検証モードのセットを決定することと、対象イベントを開始及び／又は処理するデバイスのデバイス・タイプを識別し、このデバイス・タイプに従ってデバイス・タイプに関連付けられた第２の検証モードのセットを決定することと、第１の検証モードのセット及び第２の検証モードのセットに対して交差プロセスを実行し、交差プロセスの結果を候補検証モードのセットとして使用することとを実行するようにさらに構成されるのが好ましい。

処理モジュールは、対象イベントのユーザ・タイプに関連付けられた加重を決定し、対象イベントの状況に関連付けられた加重を決定し、対象イベントのユーザの嗜好に関連付けられた加重を決定するようにさらに構成されるのが好ましい。

処理モジュールは、候補検証モードに関連付けられた管理制御の過去の記録に従って決定された管理制御属性加重のうちの少なくとも１つを取得するようにさらに構成されるのが好ましい。

候補検証モードに関連付けられた管理制御の過去の記録に従って決定された管理制御属性加重のうちの少なくとも１つを取得することは、過去の各イベントのイベント属性加重を決定することと、制約及びイベント属性加重に基づいて基準を最適化する方式で、事前に設定された基準及び制約に従って管理制御属性加重を決定することとを含むのが好ましい。

処理モジュールは、式

を使用して第ｉの検証モードの出力加重Ｓ_ｉを決定するようにさらに構成されるのが好ましく、Ｗ_ｉｊは第ｊの管理制御属性加重、Ｋ_ｊは第ｊのイベント属性加重、ｎはイベント属性加重の総数を表す。

処理モジュールは、
テスト用のテスト・イベントを過去のイベントから取得することと、
テスト・イベントごとに決定されて記録された検証モードに従って、指定された条件を満たすテスト・イベントの第１の量を決定することと、
管理制御属性加重に基づいてテスト・イベントごとに決定されるテスト検証モードを決定することと、
テスト検証モードに従って、指定された条件を満たすテスト・イベントの第２の量を決定することと、
第１の量及び第２の量を比較し、比較結果に従って管理制御属性加重を調整することと、を実行するように、さらに構成されるのが好ましい。

図４に示されているように、本出願は、トランザクション支払いイベントのリスク管理制御のためのデバイスをさらに提供し、このデバイスは、過去のイベントがトランザクション支払いイベントであり、検証モードが、トランザクション支払いイベントに適用可能な検証モードであり、関連する指定された条件が、トランザクション支払いにおいて望ましい条件であるという点が、図３に示されている実施形態とは異なる。

本出願は、本出願に従ってリスク管理制御方法を使用する、トランザクション管理制御方法をさらに開示する。

本出願は、本出願に従ってリスク管理制御デバイスを含んでいる、トランザクション管理制御デバイスをさらに開示する。

１９９０年代においては、技術に対する改良は、ハードウェアの改良（例えば、ダイオード、トランジスタ、スイッチなどの、回路構造に対する改良）又はソフトウェアの改良（方法のフローに対する改良）に、明瞭に分類することができる。しかし、技術的発展に伴って、方法のフローに対する現在の多くの改良は、ハードウェア回路構造に対する直接的改良と見なされることがある。設計者は、改良された方法のフローをハードウェア回路にプログラムすることによって、対応するハードウェア回路構造をほぼ必ず取得する。したがって、ハードウェア・モジュールを使用して方法のフローに対する改良を実現できないという結論を下すことはできない。例えば、プログラマブル論理デバイス（ＰＬＤ：Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）（例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ））は、集積回路の論理機能が、デバイスをプログラムすることによってユーザによって決定されるような、集積回路である。設計者は、デジタル・システムを１つのＰＬＤに「統合する」ように、自力でプログラムする。設計者は、専用ＩＣチップを設計して製造するように、チップ製造業者に依頼する必要がない。さらに現在、このタイプのプログラミングは、ＩＣチップを手動で製造するのではなく、「論理コンパイラ」ソフトウェアによって大部分が実装されている。この論理コンパイラ・ソフトウェアは、プログラムの開発及び記述に使用されるソフトウェア・コンパイラに類似しているが、コンパイルの前に、ハードウェア記述言語（ＨＤＬ：Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）と呼ばれる特定のプログラミング言語が、ソース・コードの記述に使用されなければならない。ＨＤＬは１つではなく、ＡＢＥＬ（Ａｄｖａｎｃｅｄ Ｂｏｏｌｅａｎ Ｅｘｐｒｅｓｓｉｏｎ Ｌａｎｇｕａｇｅ）、ＡＨＤＬ（Ａｌｔｅｒａ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、Ｃｏｎｆｌｕｅｎｃｅ、ＣＵＰＬ（Ｃｏｒｎｅｌｌ Ｕｎｉｖｅｒｓｉｔｙ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅ）、ＨＤＣａｌ、ＪＨＤＬ（Ｊａｖａ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、Ｌａｖａ、Ｌｏｌａ、ＭｙＨＤＬ、ＰＡＬＡＳＭ、ＲＨＤＬ（Ｒｕｂｙ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）などの、多くのタイプのＨＤＬが存在する。現在最もよく使用されているＨＤＬとしては、ＶＨＤＬ（Ｖｅｒｙ−Ｈｉｇｈ−Ｓｐｅｅｄ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）及びＶｅｒｉｌｏｇなどがある。当業者は、上記のＨＤＬを使用して、わずかな論理プログラミングを方法のフローに対して実行し、方法のフローをＩＣにプログラムすることによって、論理的方法のフローを実装するためのハードウェア回路を取得することが極めて簡単であるということも、認識するはずである。

コントローラが、任意の適切な方式で実装されてよい。例えば、コントローラは、マイクロプロセッサ又はプロセッサ、ならびに（マイクロ）プロセッサによって実行されることが可能なコンピュータ可読プログラム・コード（例えば、ソフトウェア又はファームウェア）を格納するコンピュータ可読媒体、論理ゲート、スイッチ、特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、プログラマブル・ロジック・コントローラ、及び組み込みマイクロコントローラなどの形態であってよい。コントローラの例としては、ＡＲＣ ６２５Ｄ、Ａｔｍｅｌ ＡＴ９１ＳＡＭ、Ｍｉｃｒｏｃｈｉｐ ＰＩＣ１８Ｆ２６Ｋ２０、及びＳｉｌｉｃｏｎｅ Ｌａｂｓ Ｃ８０５１Ｆ３２０などのマイクロコントローラが挙げられるが、これらに限定されない。メモリ・コントローラが、メモリの制御ロジックの一部としてさらに実装されてよい。当業者は、コントローラが純粋なコンピュータ可読プログラム・コードの方式で実装されることに加えて、コントローラが、論理ゲート、スイッチ、ＡＳＩＣ、プログラマブル・ロジック・コントローラ、及び組み込みマイクロコントローラの形態で同じ機能を実装できるようにするために、方法のステップで論理プログラミングを実行することが、全体的に実現可能であるということも、認識するはずである。したがって、そのようなコントローラは、ハードウェア部分と見なされてよく、コントローラに含まれ、さまざまな機能を実現するように構成されたデバイスも、ハードウェア部分内の構造と見なされてよい。代替として、さまざまな機能を実現するように構成されたデバイスは、方法を実装するためのソフトウェア・モジュール及びハードウェア部分内の構造の両方であると見なされてもよい。

上記実施形態において説明されたシステム、装置、モジュール、又はユニットは、コンピュータ・チップ又は実体によって実装されるか、又は機能を含んでいる製品によって実装されてよい。通常の実装デバイスは、コンピュータである。１つの例では、コンピュータは、例えば、パーソナル・コンピュータ、ラップトップ・コンピュータ、携帯電話、カメラ付き携帯電話、スマートフォン、パーソナル・デジタル・アシスタント、メディア・プレーヤー、ナビゲーション・デバイス、電子メール・デバイス、ゲーム機、タブレット・コンピュータ、ウェアラブル・デバイス、又はこれらのデバイスの任意の組み合わせであってよい。

説明の都合上、上記のデバイスは、説明のために、機能に従ってさまざまなユニットに分割される。ユニットの機能は、本出願が実装されるときに、１つ又は複数のソフトウェア及び／又はハードウェアにおいて実装されてよい。

当業者は、本発明の実施形態を、方法、システム、又はコンピュータ・プログラム製品として提供できるということを理解するはずである。したがって、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、又はソフトウェアとハードウェアを組み合わせた実施形態として実装されてよい。さらに、本発明は、コンピュータ使用可能なプログラム・コードを含む１つ又は複数のコンピュータ使用可能な記憶媒体（磁気ディスク・メモリ、ＣＤ−ＲＯＭ、光メモリなどを含むが、これらに限定されない）上に実装されるコンピュータ・プログラム製品の形態であってよい。

本発明は、本発明の実施形態に従って、方法、デバイス（システム）、及びコンピュータ・プログラム製品のフローチャート及び／又はブロック図を参照して説明される。コンピュータ・プログラム命令を使用して、フローチャート及び／又はブロック図における各プロセス及び／又は各ブロック、ならびにフローチャート及び／又はブロック図におけるプロセス及び／又はブロックの組み合わせを実装できるということが、理解されるべきである。これらのコンピュータ・プログラム命令は、マシンを生成するために、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又はその他のプログラム可能データ処理デバイスのプロセッサに提供されてよく、このマシンは、コンピュータ又はその他のプログラム可能データ処理デバイスのプロセッサによって実行される命令に、フローチャート内の１つ又は複数のプロセス及び／又はブロック図内の１つ又は複数のブロックにおいて指定された機能を実装するための装置を生成させる。

それらのコンピュータ・プログラム命令は、コンピュータ可読メモリに格納されてもよく、コンピュータ又はその他のプログラム可能データ処理デバイスに対して、特定の方式で動作するように指示することができ、このコンピュータ又はその他のプログラム可能データ処理デバイスは、コンピュータ可読メモリに格納された命令に、命令装置を含んでいる製品を生成させる。命令装置は、フローチャート内の１つ又は複数のプロセス及び／又はブロック図内の１つ又は複数のブロックにおいて指定された機能を実装する。

これらのコンピュータ・プログラム命令は、コンピュータ又はその他のプログラム可能データ処理デバイスに読み込まれてもよく、このコンピュータ又はその他のプログラム可能データ処理デバイスは、一連の動作ステップに、コンピュータ上又はその他のプログラム可能デバイス上で実行させ、それによって、コンピュータ実装処理を生成する。したがって、コンピュータ上又はその他のプログラム可能デバイス上で実行される命令は、フローチャート内の１つ又は複数のプロセス及び／又はブロック図内の１つ又は複数のブロックにおいて指定された機能を実装するためのステップを提供する。

標準的な構成において、計算デバイスは、１つ又は複数のプロセッサ（ＣＰＵ）、入出力インターフェイス、ネットワーク・インターフェイス、及びメモリを含む。

メモリは、揮発性メモリ、ランダム・アクセス・メモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、及び／又は不揮発性メモリ（例えば、読み取り専用メモリ（ＲＯＭ：Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）又はフラッシュＲＡＭ）などの、コンピュータ可読媒体を含んでよい。メモリは、コンピュータ可読媒体の例である。

コンピュータ可読媒体は、任意の方法又は技術によって情報の格納を実施できる、永続的媒体、揮発性媒体、移動できる媒体、及び固定された媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラム・モジュール、又はその他のデータであってよい。コンピュータの記憶媒体の例としては、相変化ランダム・アクセス・メモリ（ＰＲＡＭ：Ｐｈａｓｅ−ｃｈａｎｇｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｉｅｓ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｉｅｓ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ：Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｉｅｓ）、その他のタイプのランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ：Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｉｅ）、フラッシュ・メモリ、又はその他のメモリ技術、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ：Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｉｅｓ）、デジタル多用途ディスク（ＤＶＤ：Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃｓ）、又はその他の光メモリ、カセット、カセット・メモリ、及びディスク・メモリ、又はその他の磁気メモリ・デバイス、あるいは計算デバイスによってアクセス可能な情報を格納するために使用できる任意のその他の非送信媒体などが挙げられるが、これらに限定されない。本明細書における定義に従って、コンピュータ可読媒体は、変調データ信号及び搬送波などの一時的媒体を含まない。

「含んでいる」、「備えている」という用語、又はこれらの用語の任意のその他の変形は、非排他的含有を包含するよう意図されており、一連の要素を含んでいるプロセス、方法、商品、又はデバイスに、それらの要素を含ませるだけでなく、明確にリストされていないその他の要素も含ませ、あるいはプロセス、方法、商品、又はデバイスに固有の要素をさらに含ませるということに、さらに注意するべきである。他に限定が存在しない場合、「１つの〜を備えている」という記述によって定義された要素は、前述の要素を備えているプロセス、方法、商品、又はデバイスが追加の同一の要素をさらに備えることを除外しない。

当業者は、本出願の実施形態を、方法、システム、又はコンピュータ・プログラム製品として提供できるということを理解するはずである。したがって、本出願は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、又はソフトウェアとハードウェアを組み合わせた実施形態として実装されてよい。さらに、本出願は、コンピュータ使用可能なプログラム・コードを含む１つ又は複数のコンピュータ使用可能な記憶媒体（磁気ディスク・メモリ、ＣＤ−ＲＯＭ、光メモリなどを含むが、これらに限定されない）上に実装されるコンピュータ・プログラム製品の形態であってよい。

本出願は、プログラム・モジュールなどの、コンピュータによって実行されるコンピュータ実行可能命令の通常の文脈において説明されてよい。一般に、プログラム・モジュールは、特定のタスクを実行するか、又は特定の抽象データ型を実装するために、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本出願は、分散コンピューティング環境において実践されてもよい。それらの分散コンピューティング環境では、通信ネットワークを介して接続されたリモート処理デバイスが、タスクを実行する。分散コンピューティング環境において、プログラム・モジュールは、ストレージ・デバイスを含む、ローカル及びリモートのコンピュータの記憶媒体に配置されてよい。

本明細書の実施形態は、各実施形態と他の実施形態との差異に重点を置いて、漸進的な方式で説明されており、各実施形態は、同一の部分又は類似する部分に関して相互に参照されてよい。特に、システムの実施形態は、システムの実施形態が方法の実施形態にかなり類似しているため、比較的単純な方式で説明されている。方法の実施形態の説明が、関連する部分に関して参照されてよい。

上記の説明は本出願の実施形態にすぎず、本出願を限定するために使用されない。当業者にとっては、本出願に、さまざまな修正及び変更が存在してよい。本出願の思想及び原理の範囲内で行われる任意の修正、同等の置き換え、又は改良は、本出願の特許請求の範囲に包含されるものとする。

Claims (6)

1. コンピュータによって、管理及び制御される対象イベントを受信することと、
   前記コンピュータによって、前記対象イベントに従って候補検証モードのセットを決定することと、
   前記コンピュータによって、前記候補検証モードのセットのうち少なくともいくつかの候補検証モードの出力加重を決定することと、
   前記コンピュータによって、前記候補検証モードに対応する前記出力加重に従って、前記候補検証モードのセットから、前記対象イベントに対するリスク管理制御の検証モードを決定することと、を含んでおり、
   前記コンピュータによって、候補検証モードのセットを前記決定することが、
   前記コンピュータによって、前記対象イベントに対応するリスク・タイプを識別し、前記リスク・タイプに従って前記リスク・タイプに関連付けられた第１の検証モードのセットを決定することと、
   前記コンピュータによって、前記対象イベントを開始及び／又は処理するデバイスのデバイス・タイプを識別し、前記デバイス・タイプに従って前記デバイス・タイプに関連付けられた第２の検証モードのセットを決定することと、
   前記コンピュータによって、前記第１の検証モードのセット及び前記第２の検証モードのセットに対して交差プロセスを実行し、前記候補検証モードのセットを前記交差プロセスの結果として設定することとを含んでいる、オンライン・トランザクション及び支払いのためにリスク・イベントを管理する方法。
2. 前記コンピュータによって、前記候補検証モードのセットのうち少なくともいくつかの候補検証モードの出力加重を前記決定することが、式
   

   

   を使用して、前記コンピュータによって、第ｉの検証モードの出力加重Ｓ_ｉを決定することを含んでおり、
   Ｗ_ｉｊが第ｊの管理制御属性加重であり、Ｋ_ｊが第ｊのイベント属性加重であり、ｎがイベント属性加重の総数を表している、請求項１に記載のオンライン・トランザクション及び支払いのためにリスク・イベントを管理する方法。
3. 管理及び制御される対象イベントを受信するように構成された受信モジュールと、
   候補検証モードのセットを決定し、候補検証モードのセットのうち少なくともいくつかの候補検証モードの出力加重を決定するように構成された処理モジュールと、
   前記候補検証モードに対応する前記出力加重に従って、前記候補検証モードのセットから、前記対象イベントに対するリスク管理制御の検証モードを出力するように構成された出力モジュールと、を備え、
   前記処理モジュールが、
   前記対象イベントに対応するリスク・タイプを識別し、前記リスク・タイプに従って前記リスク・タイプに関連付けられた第１の検証モードのセットを決定することと、
   前記対象イベントを開始及び／又は処理するデバイスのデバイス・タイプを識別し、前記デバイス・タイプに従って前記デバイス・タイプに関連付けられた第２の検証モードのセットを決定することと、
   前記第１の検証モードのセット及び前記第２の検証モードのセットに対して交差プロセスを実行し、前記候補検証モードのセットを前記交差プロセスの結果として設定することとを実行するようにさらに構成されている、オンライン・トランザクション及び支払いのためにリスク・イベントを管理するデバイス。
4. 前記処理モジュールが、式
   

   

   を使用して、第ｉの検証モードの出力加重Ｓ_ｉを決定するようにさらに構成されており、
   Ｗ_ｉｊが第ｊの管理制御属性加重であり、Ｋ_ｊが第ｊのイベント属性加重であり、ｎがイベント属性加重の総数を表している、請求項３に記載のオンライン・トランザクション及び支払いのためにリスク・イベントを管理するデバイス。
5. 請求項１又は２に記載の前記オンライン・トランザクション及び支払いのためにリスク・イベントを管理する方法を含んでいる、コンピュータによって実行されるトランザクション管理制御方法。
6. 請求項３又は４に記載の前記オンライン・トランザクション及び支払いのためにリスク・イベントを管理するデバイスを含んでいる、トランザクション管理制御デバイス。

Images