JP2020506473A - リスクパラメータを調整するための方法、ならびにリスク識別のための方法およびデバイス - Google Patents

Abstract

開示されるものは、リスクパラメータを調整するための方法、ならびにリスク識別のための方法およびデバイスである。一方では、１つの取引に関連する動作データが、少なくとも１つの動作ホッピングシーケンスに変換され、各動作ホッピングシーケンスは、少なくとも１つの動作ホッピングイベントをさらに含み、各動作ホッピングイベントは、リスクパラメータに対応し、次いで、１つの取引に関連する動作データが、実際には複数の独立した動作ホッピングイベントに離散化され、他方では、電子トレーディングサービスを提供するクライアント上に登録された様々なユーザ識別子に対して、様々なユーザ識別子と１対１の対応である様々なリスクパラメータのセットが設定され、様々なリスクパラメータのリアルタイムのオンライン更新がサポートされる。本出願で請求されるリスク識別のための方法を用いて、一方では、高コストの手動の入力が回避され、リスク識別システムが再トレーニングされるために数か月待機することなしに、リスクパラメータがオンラインで動的に更新され、したがって、適時にリスク識別システムのための更新を完了することができる。

Description

本出願は、情報技術の分野に関し、詳細には、リスクパラメータを調整するための方法、ならびにリスク識別のための方法およびデバイスに関する。

オンライン支払い、オンライン送金、および他の電子取引方法の普及に伴い、取引のセキュリティ、および適時で正確な取引リスクの識別を保証することは、極めて重要である。

概して、ユーザは、電子取引サービスを提供するクライアント（例えば、モバイルフォン上にインストールされた電子取引アプリケーション、および電子取引ウェブサイトに対応するブラウザページ）上で、アカウントを登録し、取引パスワードを設定し、アカウントをユーザのバンクカードにリンクさせることができる。ユーザがクライアントにログオンし、クライアントに取引パスワードを入力して、支払いを要求するとき、クライアントは、管理サーバに支払い要求を送信する。管理サーバは、受信された支払い要求においてリスク識別を行う。リスク管理識別の結果が安全である（すなわち、現在の取引が、ユーザによって、またはユーザによって許可された他者によって開始されている）場合、管理サーバは、支払い要求に従って、ユーザのバンクカードにおいて、それに対応して控除を行う。リスク管理識別の結果が安全でない、すなわち、現在の取引が、ユーザのアカウントおよびパスワードを許可なく取得する誰かによって開始されている可能性が高い場合、管理サーバは、現在の取引を凍結するようにクライアントに命令するなどの対策を講じ、アカウントにリンクされたモバイルフォン番号および電子メールアドレスに、リスク警告メッセージを送信することができる。

現在、２つのリスク識別方法がある。第１に、様々なリスク識別ルールが、既知のリスクに従って人為的に定義され、管理サーバが、リスク識別ルールに従って、取引においてリスク識別を行う。第２に、リスク識別システムが、管理サーバ上で人工知能を備える。大量の履歴動作データ（安全な動作データおよび安全でない動作データを含む）が、ランダムフォレスト、論理回帰、およびニューラルネットワークなど、機械学習アルゴリズムを使用して、事前にリスク識別システムに提供される。リスク識別システムは、既知のリスクに従って、リスク識別ルールを取得すること、および新しい取引のリスクをある程度まで識別することが可能であるように、トレーニングされる。

実際には、人為的に定義されたか、または機械学習を通して取得されたリスク識別ルールは、既知のリスクに依存しすぎる。無許可のユーザは、常に何とかしてリスク識別ルールをクラックし、新しいオンライン資産窃盗の手段を絶えず開発しており、リスク識別システムが管理不可能な未知のリスクに絶えず直面するようになっている。リスク識別のための既存の方法では、絶えず現れる資産窃盗の手段に対処するために、リスク識別ルールが頻繁に更新される必要がある。

リスク識別のための既存の方法では、リスク識別ルールの人為的な保守と、機械学習を通したリスク識別ルールの更新の両方が、リスク識別ルールがクラックされた後の改善策にすぎない。すなわち、無許可のユーザが新しい資産窃盗の手段を使用して、リスク識別ルールをバイパスし、ユーザに莫大な損失を引き起こした後、リスク識別ルールの更新は、手動の入力、またはリスク識別システムの再トレーニングを通してのみ達成され得る。

具体的には、一方では、手動の入力のコストは高すぎるものであり、手動の入力における過失および脱落は避けられない。他方では、リスク識別システムの再トレーニングは、しばしばオフラインで行われる必要があり、完了するまで数か月かかる。リスク識別ルールを調整するための既存の方法は、高コストおよび重大な遅延の問題を有することがわかる。

本出願の実施形態は、リスク識別のための既存の方法の高コストおよび重大な遅延の問題を解決するために、リスクパラメータを調整するための方法、ならびにリスク識別のための方法およびデバイスを提供する。

上記の技術的問題を解決するために、本出願の実施形態は、以下のように実施される。

本出願の実施形態によって提供される、リスクパラメータを調整するための方法は、
支払い要求を受信するステップであって、支払い要求が、ユーザ識別子と、ユーザ識別子を通して現在の取引において生成された動作データとを含む、受信するステップと、
動作データに従って、現在の取引において生じた少なくとも１つの動作ホッピングシーケンスを決定するステップであって、動作ホッピングシーケンスが、少なくとも１つの動作ホッピングイベントを含む、決定するステップと、
ユーザ識別子に対応するリスクパラメータのセットから、動作ホッピングシーケンスに含まれた動作ホッピングイベントに対応するリスクパラメータを獲得するステップであって、リスクパラメータのセットに含まれたリスクパラメータが、ユーザ識別子に対応する前の取引において生成された動作データに従って、前の取引におけるリスク識別のために使用されたリスクパラメータを調整することによって取得される、獲得するステップと、
少なくとも１つの動作ホッピングシーケンスに従って、獲得されたリスクパラメータを調整するステップと、
を含む。

本出願の実施形態によって提供される、リスク識別のための方法は、
支払い要求を受信するステップであって、支払い要求が、現在の取引において生成された少なくとも１つの次元の動作データを含む、受信するステップと、
それぞれの次元に関して、それぞれの次元の動作データに従って、現在の取引のリスク度を決定するステップと、
次元に対応する現在の取引の異なるリスク度が取得されるとき、取得された異なるリスク度に従って、現在の取引においてリスク識別を行うステップと、
を含む。

本出願の実施形態によって提供される、リスクパラメータを調整するためのデバイスは、
支払い要求を受信する受信モジュールであって、支払い要求が、ユーザ識別子と、ユーザ識別子を通して現在の取引において生成された動作データとを含む、受信モジュールと、
動作データに従って、現在の取引において生じた少なくとも１つの動作ホッピングシーケンスを決定する、決定モジュールであって、動作ホッピングシーケンスが、少なくとも１つの動作ホッピングイベントを含む、決定モジュールと、
ユーザ識別子に対応するリスクパラメータのセットから、動作ホッピングシーケンスに含まれた動作ホッピングイベントに対応するリスクパラメータを獲得する、獲得モジュールであって、リスクパラメータのセットに含まれたリスクパラメータが、ユーザ識別子に対応する前の取引において生成された動作データに従って、前の取引におけるリスク識別のために使用されたリスクパラメータを調整することによって取得される、獲得モジュールと、
少なくとも１つの動作ホッピングシーケンスに従って、獲得されたリスクパラメータを調整する、調整モジュールと、
を含む。

本出願の実施形態によって提供される、リスク識別のための別のデバイスは、
支払い要求を受信する受信モジュールであって、支払い要求が、現在の取引において生成された少なくとも１つの次元の動作データを含む、受信モジュールと、
それぞれの次元に関して、それぞれの次元の動作データに従って、現在の取引のリスク度を決定する、決定モジュールと、
次元に対応する現在の取引の異なるリスク度が取得されるとき、取得された異なるリスク度に従って、現在の取引においてリスク識別を行う、識別モジュールと、
を含む。

本出願の実施形態によって提供される、リスク識別システムは、
取引要求を受信し、ユーザ識別子を通して現在の取引において生成された動作データを獲得し、動作データに従って、リスク解析を行い、リスク識別モジュールにリスク解析結果を送信する、スマートモジュールであって、リスク解析結果が、上記のリスク識別のための方法によって取得される、スマートモジュールと、
受信されたリスク解析結果に従って、リスク識別を行う、リスク識別モジュールと、
を含む。

本出願の実施形態によって提供される技術的解決策から、本出願の実施形態では、一方では、１つの取引に関連する動作データが、少なくとも１つの動作ホッピングシーケンスに変換され、各動作ホッピングシーケンスは、少なくとも１つの動作ホッピングイベントをさらに含み、各動作ホッピングイベントは、リスクパラメータに対応し、次いで、１つの取引に関連する動作データが、実際には複数の独立した動作ホッピングイベントに離散化され、他方では、電子トレーディングサービスを提供するクライアント上に登録された様々なユーザ識別子に対して、様々なユーザ識別子と１対１の対応である様々なリスクパラメータのセットが設定され、様々なリスクパラメータのリアルタイムのオンライン更新がサポートされることがわかる。このようにして、無許可のユーザが、ユーザのユーザ識別子を取得し、ユーザ識別子を通して、クライアント上で管理サーバへの支払い要求を開始すると、無許可のユーザがリスク識別システムを一時的に欺き、ユーザの資産損害を引き起こす場合でも、管理サーバは、リスク識別システムの手動の入力またはオフライン再トレーニングを待機することなしに、支払い要求に含まれた動作データに従って、オンラインでユーザ識別子を通して開始された取引に関わる各動作ホッピングイベントに対応するリスクパラメータを、適時に動的に更新することができる。本出願で請求されるリスク識別のための方法を用いて、一方では、高コストの手動の入力が回避され、リスク識別システムが再トレーニングされるために数か月待機することなしに、リスクパラメータがオンラインで動的に更新され、したがって、適時にリスク識別システムのための入力を完了することができる。

本出願の実施形態における、または従来技術における技術的解決策についてより明確に説明するために、以下で、実施形態または従来技術について説明するために必要とされる添付の図面を簡単に紹介する。明らかに、以下の説明における添付の図面は、本出願のいくつかの実施形態を示すにすぎず、当業者はなお、創造的な努力なしに、これらの添付の図面から他の図面を導出し得る。

本出願の実施形態によって提供される、リスクパラメータを調整するための方法のフローチャートである。 本出願の実施形態によって提供される、リスク識別のための方法のフローチャートである。 本出願の実施形態によって提供される、リスクパラメータを調整するためのデバイスの図である。 本出願の実施形態によって提供される、リスク識別のためのデバイスの図である。 本出願の実施形態によって提供される、リスク識別システムの図である。 本出願の実施形態によって提供される、リスク識別システムの詳細図である。 本出願の実施形態によって提供される、リスク識別システムの詳細図である。 本出願の実施形態によって提供される、リスク識別システムの詳細図である。 本出願の実施形態によって提供される、リスク識別システムの詳細図である。

当業者が本出願の技術的解決策をより良く理解することを可能にするために、本出願の実施形態の技術的解決策について、本出願の実施形態の添付の図面を参照しながら、以下で明確かつ十分に説明する。説明する実施形態は、本出願の実施形態の全部ではなく、一部にすぎないことは明らかである。当業者によって、創造的な努力なしに、本出願の実施形態に基づいて取得されるすべての他の実施形態は、本出願の保護範囲内に入るものとする。

オンラインリスク識別の技術分野では、背景技術において説明した方法１および方法２の組合せが、通常、オンラインリスク識別のために使用される。すなわち、一方では、リスク識別システムは、リスク識別システムがリスク識別ルールを取得することができるように、リスク識別システムに大量の履歴動作データを提供すること、および機械学習の方法を使用することによってトレーニングされ、他方では、専門家の専門的な経験が、リスク識別ルールに手動で追加される。しかしながら、方法１および方法２の組合せに基づくリスク識別のための方法は、依然として高コストおよび重大な遅延の欠陥を有する。

具体的には、オンラインリスクは、ゲームのようなものである。リスク管理職員によって保守されるリスク識別システムが依拠するリスク識別ルールは、常に既知のリスクに基づいて決定される。許可なく、ユーザのユーザ識別子を取得した後、無許可のユーザは、常に何とかしてリスク識別ルールをクラックし、新しい資産窃盗の手段を開発する。無許可のユーザが成功する場合、リスク管理職員は、無許可のユーザの時々の成功が大きいオンラインリスクを引き起こさないように、リスク識別システムを適時に更新して、新しい資産窃盗の手段によって引き起こされる損害の増大を抑制することができる。

しかしながら、実際には、リスク識別のための既存の方法では、リスク識別システムの更新は、手動で、またはシステム再トレーニングを通して実現される。高コストの問題のほかに、手動の更新もまた、ある程度、重大な遅延の問題を有しており、その理由は、新しい資産窃盗の手段が、リスク管理職員の注意を引くのに十分深刻である損害を引き起こすまで、リスク管理職員がリスク識別ルールを更新しないからである。システム再トレーニングでは、遅延の問題はなお一層重大であり、その理由は、リスク識別システムの再トレーニングには、オフライン学習が必要となり、サイクルが数か月に及ぶことが多いが、数か月後には、新しい資産窃盗の手段が、無許可のユーザによって開発されるようになるので、システム再トレーニングの価値が大幅に低減されることになるからである。リスク識別のための既存の方法は、新しいオンラインリスクに対処する際に重大な遅延を有し、したがって、既存のリスク識別システムが常に無許可のユーザに「鼻の差でリードされる」ことを引き起こし、それは極めて受動的であり、適時にオンラインリスクの拡大を防止する際の失敗につながることが多いことがわかる。

しかしながら、本出願で請求されるリスク識別のための方法は、オンラインリスク競争におけるリスク識別システムに対する無許可のユーザの各挑戦に応答して、適時にオンライン的に様々なリスクパラメータの動的な調整を実現することができ、それは、実際の闘いにおいて、無許可のユーザの持続的な試行をリスク識別システムのオンライントレーニングのために使用することに相当する。各リスクパラメータは動作ホッピングイベントに対応し、リスク識別システムは、リスクパラメータのセットに従って、各取引に関わる動作ホッピングイベントのリスクを解析し、取引のリスクを包括的に識別する。言い換えれば、リスクパラメータは、リスク識別ルールの特定の形態であり、リスク識別ルールは、リスクパラメータが調整された後に更新される。

実際には、無許可のユーザが時々成功する場合でも、リスク識別システムは、適時に（多くとも１日を必要とする）リスクパラメータを調整することによって更新され得、無許可のユーザの時々の成功によって取得された新しい資産窃盗の手段は、次の無許可の取引において識別されることになる。加えて、リスクパラメータが常にオンラインで動的に調整され得るので、無許可のユーザがリスク識別システムをクラックすることは、ますます困難である。

本出願の核となる考えは、発生の可能性について独立して評価され得る一連の動作ホッピングイベントに、取引を離散化することである（動作ホッピングイベントの説明について、詳細については下記を参照されたい）。ユーザのユーザ識別子を通してクライアントにログオンした後、ユーザと無許可のユーザの両方によって行われる動作が、一連の最も基本的な動作ホッピングイベントに離散化され得るので、現在の取引の発生の可能性の評価は、取引に関わる各動作ホッピングイベントの発生の可能性をそれぞれ評価することによって、包括的に実現され、したがって、現在の取引のためのリスク識別が実現され得る。同時に、各ユーザ識別子に対応する、動作ホッピングイベントのあらかじめ設定されたセットにおける、指定された少なくとも１つの動作ホッピングイベントに対応するリスクパラメータを調整することによって、指定された動作ホッピングイベントの発生の可能性の期待値が調整され、したがって、リスク識別システムのリスク識別ルールの論理または戦略の調整が実現され得る。

しかしながら、リスク識別のための既存の方法では、人為的にセットアップされたか、または機械学習によって取得されたリスク識別ルールの論理が閉じられているので、リスク識別ルールを調整することができず、リスク識別ルールは、リスク識別システムがオフラインであるという条件下でのみ追加または置換され得、それによって、重大な遅延および高コストが引き起こされる。

要するに、本出願で請求されるリスク識別のための方法は、各取引の動作データに従って、リスクパラメータを動的に調整することによって、オンラインリスクをリアルタイムで記憶することを実現することができ、リスク識別システムは、適応的に学習し、人材への依拠をより少なくすることができ、加えて、リスク識別システムは、無許可のユーザとの「ゲーム」状態を常に維持し、リスクパラメータのセットにおける各リスクパラメータの正確さも、時の試練を経たものとなり、このようにして、リスク識別システムは、常により正確にリスクを識別し、オンラインリスクをある程度まで予測することさえできる。

本出願の様々な実施形態によって提供される技術的解決策について、添付の図面を参照しながら、以下で詳細に説明する。

図１は、本出願の実施形態によって提供される、リスクパラメータを調整するための方法のフローチャートであり、この方法は、以下のステップを含む。

Ｓ１０１：支払い要求を受信する。

この方法の実行体は、電子取引サービスを提供するサービスプロバイダの管理サーバであり得る。管理サーバは、各ユーザの端末デバイス上にインストールされたクライアントと対話し、クライアントによって送信された支払い要求を受信し、取引を凍結させた後にクライアントに命令を送信するなど、クライアントに命令を送信し、端末デバイスの画面上で「取引が凍結されました」というメッセージを表示するように、クライアントに命令する。

本出願の実施形態では、リスク識別システムは、管理サーバ上に配置され得、リスク識別システムは、支払い要求に従って、リスク識別のために使用される。リスクパラメータのオンライン自己学習および自己調整に加えて、リスク識別システムはまた、リスク管理職員によるリスクパラメータの手動の更新、ならびにオフライントレーニングをサポートする。

本出願の実施形態では、支払い要求は、ユーザ識別子と、ユーザ識別子を通して現在の取引において生成された動作データとを含む。ユーザ識別子は、クライアントにログオンするためのユーザ識別子（ユーザのアカウント）であり得る。動作データは、以下のデータを含み得、すなわち、ある人がユーザ識別子を通して、現在の取引を行うことによって行われる動作、現在の取引の時間、現在の取引に関わる業者情報、ロジスティックス情報、支払われる金額、現在の取引において使用される端末デバイスと外界との間の対話によって生成されたデータなどである。手短に言えば、クライアントによって獲得され得る現在の取引に関わるすべてのデータが、本出願で説明する動作データであり得る。

本出願の実施形態における支払いに関わる技術的キャリアには、例えば、近距離通信（ＮＦＣ）、ＷＩＦＩ、３Ｇ／４Ｇ／５Ｇ、販売時点（ＰＯＳ）カードスワイプ技術、２次元コードスキャニング技術、バーコードスキャニング技術、Ｂｌｕｅｔｏｏｔｈ（登録商標）、赤外線、ショートメッセージサービス（ＳＭＳ）、マルチメディアメッセージサービス（ＭＭＳ）などが含まれ得る。

Ｓ１０２：動作データに従って、現在の取引において生じた少なくとも１つの動作ホッピングシーケンスを決定する。

本出願の実施形態では、動作ホッピングシーケンスは、少なくとも１つの動作ホッピングイベントを含むシーケンスであり得、動作ホッピングシーケンスに含まれた動作ホッピングイベントは、論理的に接続される。例えば、動作ホッピングシーケンスは、動作ホッピングイベントＴ１、Ｔ２、およびＴ３を含む。１つの取引において、Ｔ１、Ｔ２、およびＴ３が次々に発生し、Ｔ２はＴ１の後にのみ発生し、Ｔ３はＴ２の後にのみ発生する。

動作ホッピングイベントは、動きの発生、または２つの状態の間の遷移のイベントであり得る。例えば、「クライアントにおけるリンクをクリックすること」は、「リンク上でクリックする動きが発生する」、または「リンクがクリックされない状態から、リンクがクリックされる状態に遷移する」であり得る、動作ホッピングイベントである。説明の便宜上、動作ホッピングイベントについて、２つの状態の間の遷移のイベントとして、以下で説明する。

シャオミンがクライアントを開き、クライアントにおける購入リンクをクリックし、ポップアップ支払いページにおける「支払い」ボタンをクリックすると仮定すると、管理サーバは、シャオミンのユーザ識別子と、シャオミンのユーザ識別子を通して、現在の取引において生成された動作データとを含む、支払い要求を受信することになる。動作データが「シャオミンが、２０１６年１月５日の１７：２０に、シャオリーのｉＰｈｏｎｅ（登録商標）（シリアル番号：ｆ２１５４）を使用して、シャオミンのアカウントでクライアントにログオンし、２０１６年１月５日の１８：０５に、ナイキストアの購入リンクをクリックし、５００元でスニーカー１足の購入を要求した」であると仮定すると、次いで、動作データに従って、少なくとも１つの動作ホッピングシーケンスが決定され得る。動作ホッピングシーケンスは、シャオミン自身がシャオミンのアカウントの現在のユーザである確率を実際に反映することができる。例えば、３つの動作ホッピングシーケンスが決定され得、それぞれ、動作がシャオミンのアカウントでどのように行われたか、動作がシャオミンのアカウントでいつ行われたか、およびｉＰｈｏｎｅ（登録商標） ｆ２１５４が毎日そのアカウントでログオンする回数に関連する。これらの３つの側面から、シャオミン自身がシャオミンのアカウントの現在のユーザである確率が決定され得る。具体的には、動作ホッピングシーケンス１は、以下の動作ホッピングイベント、すなわち、シャオミンがナイキストアの購入リンクをクリックし、スニーカー１足の支払いボタンをクリックしたことを含み、動作ホッピングシーケンス２は、以下の動作ホッピングイベント、すなわち、シャオミンが２０１６年１月５日の１７：２０に購入リンクをクリックし、２０１６年１月５日の１８：０５に支払いボタンをクリックしたことを含み、ホッピングシーケンス３は、以下の動作ホッピングイベント、すなわち、シャオリーのアカウントがｉＰｈｏｎｅ（登録商標） ｆ２１５４からログアウトされ、シャオミンのアカウントがｉＰｈｏｎｅ（登録商標） ｆ２１５４にログオンされたことを含む。

例えば、動作ホッピングシーケンス１に含まれた動作ホッピングイベント「シャオミンがスニーカー１足の支払いボタンをクリックした」では、動作ホッピングイベントは、２つの状態、すなわち、状態１「支払いボタンがクリックされない」−＞状態２「支払いボタンがクリックされる」の間の遷移に対応する。別の例では、動作ホッピングシーケンス３に含まれた動作ホッピングイベント「シャオリーのアカウントがｉＰｈｏｎｅ（登録商標） ｆ２１５４からログアウトされた」では、動作ホッピングイベントは、２つの状態、すなわち、状態１「シャオリーのアカウントがｉＰｈｏｎｅ（登録商標） ｆ２１５４上でアクティブであった」−＞「シャオリーのアカウントがｉＰｈｏｎｅ（登録商標） ｆ２１５４上でアクティブではなかった」の間の遷移に対応する。

同様に、動作ホッピングシーケンスにおける各動作ホッピングイベントは、上記のように２つの状態の間の遷移に対応し得、再度説明しない。

要約すれば、動作データ、動作ホッピングシーケンス、および動作ホッピングイベント（ある状態から別の状態に遷移する）の間の関係が明確であり、すなわち、あるユーザ識別子を使用して開始された現在の取引では、現在の取引に関わる少なくとも１つの動作ホッピングシーケンスが、現在の取引に関わる動作データに従って決定され得る。動作ホッピングシーケンスに含まれた動作ホッピングイベントは、現在の取引に関わる各動作ホッピングシーケンスに従って決定され得る。

実際には、本出願で請求される技術的解決策の核となる考えは、一方では、１つの取引に関連する動作データが、少なくとも１つの動作ホッピングシーケンスに変換され、各動作ホッピングシーケンスは、少なくとも１つの動作ホッピングイベントをさらに含み、各動作ホッピングイベントは、リスクパラメータに対応し、次いで、１つの取引に関連する動作データが、実際には複数の独立した動作ホッピングイベントに離散化されることである。他方では、電子トレーディングサービスを提供するクライアント上に登録された様々なユーザ識別子に対して、様々なユーザ識別子と１対１の対応である様々なリスクパラメータのセットが設定され、様々なリスクパラメータのリアルタイムのオンライン更新がサポートされる。このようにして、無許可のユーザが、ユーザのユーザ識別子を取得し、ユーザ識別子を通して、クライアント上で管理サーバへの支払い要求を開始すると、無許可のユーザがリスク識別システムを一時的に欺き、ユーザの資産損害を引き起こす場合でも、管理サーバは、リスク識別システムの手動の入力またはオフライン再トレーニングを待機することなしに、支払い要求に含まれた動作データに従って、オンラインでユーザ識別子を通して開始された取引に関わる各動作ホッピングイベントに対応するリスクパラメータを、適時に動的に更新することができる。

本出願の実施形態では、ユーザ識別子を通して現在の取引において生成された動作データに従って、対応する少なくとも１つの動作ホッピングシーケンスを決定すること、および、現在の取引に関わるすべての動作ホッピングイベントをさらに決定することは、現在の取引のリスク識別およびリスクパラメータ調整のために必要なステップであることがわかる。

本出願の実施形態は、強化学習理論において「主要なイベントを少なくとも１つの動作移行シーケンスと見なすこと、すなわち、主要なイベントを複数の動作ホッピングイベントに離散化すること」の考えから、実際に学習する。複数の動作ホッピングイベントが、解析されるべき主要なイベントの動作データから抽出され、機械が、繰り返される試行錯誤を通して、各動作ホッピングイベントに対応する発生確率を決定し、各動作ホッピングイベントの発生確率に従って、主要なイベントの判定を行うようにする。

しかしながら、強化学習理論に端を発した、本出願で請求される技術的解決策によって提供される一実施形態では、取引において発生し得る様々なイベントが、一連の動作ホッピングイベントに離散化される。各動作ホッピングイベントに対応する発生確率は、初期化されたリスクパラメータとして初期化され、取引が発生するとき、リスク識別システムが、取引に関わる各動作ホッピングシーケンスを最初に解析することができるようになる。そのため、関連する動作ホッピングイベントが、それに応じて決定され、取引に関わる動作ホッピングイベントに対応する発生確率が、設定された発生確率から決定され、取引に関わる動作ホッピングイベントに対応する発生確率が、取引が妥当であるか否かを決定するため、および取引のリスクを識別するために、包括的に検討される。

Ｓ１０３：ユーザ識別子に対応するリスクパラメータのセットから、動作ホッピングシーケンスに含まれた動作ホッピングイベントに対応するリスクパラメータを獲得する。

本出願の実施形態では、リスクパラメータは、機械強化学習方法において使用される発生確率であり得るか、または、リスク管理職員が、リスクパラメータがクラックされることを防止するために、ある暗号化アルゴリズムを使用して、リスク確率を暗号化することによって取得されたパラメータであり得る。手短に言えば、動作ホッピングイベントの発生の可能性を解析するために使用され得るいかなるパラメータも、本出願で説明するリスクパラメータであり得る。リスクパラメータの調整が、リスク識別システムが依拠するリスク識別ルールの調整を意味することに注目すべきである。

本出願の実施形態では、ステップＳ１０１の前に、管理サーバ上に配置されたリスク識別システムが、登録されたユーザ識別子ごとに初期化され得、ユーザ識別子に対応する動作ホッピングイベントのセットが決定され得、初期値が、ユーザ識別子に対応する各動作ホッピングイベントに対応するリスクパラメータに割り当てられ得る。

具体的には、異なるノード（すなわち、異なる状態）が定義され得、２つの異なるノードの間の動作ホッピング（すなわち、２つの異なる状態の間の遷移）がトラバースされて、複数の動作ホッピングイベントが取得され得、複数の動作ホッピングイベントが、動作ホッピングイベントのセットに含まれ得る。各ユーザ識別子が動作ホッピングイベントのセットに対応することに注目すべきである。

次いで、初期値が、動作ホッピングイベントのセットにおける各動作イベントに対応するリスクパラメータにランダムに割り当てられ得、各動作イベントに対応するリスクパラメータが、リスク識別システムが絶えずリスクパラメータを更新するプロセスにおいて、対応するユーザ識別子を使用する個人ユーザの属性により適合するようになる。

もちろん、各リスクパラメータの初期値はまた、ユーザ識別子を使用する個人ユーザの属性に従って決定され得る。具体的には、ユーザ識別子を通して生成された履歴動作データが獲得され得、動作ホッピングイベントのセットに含まれた動作ホッピングイベントごとに、以下がそれぞれ実行され、すなわち、履歴動作データに従って、それぞれの動作ホッピングイベントの発生確率を決定すること、および、発生確率を、それぞれの動作ホッピングイベントのためのリスクパラメータの初期値として使用することである。

履歴動作データに含まれない動作ホッピングイベントでは、基準値が、これらの動作ホッピングイベントの発生確率に与えられ得る。リスク識別のための方法を実施することにより、これらの発生確率は、個人ユーザの属性に適合するように徐々に調整されることになる。

ユーザ識別子を通して生成された履歴動作データを獲得することができないとき、設定された数の他のユーザ識別子を使用して生成された履歴動作データが獲得される。動作ホッピングイベントのセットに含まれた動作ホッピングイベントごとに、以下がそれぞれ実行され、すなわち、履歴動作データに従って、それぞれの動作ホッピングイベントの発生確率を決定すること、および、発生確率を、それぞれの動作ホッピングイベントのためのリスクパラメータの初期値として使用することである。

すなわち、新たに登録されたユーザ識別子では、ユーザ識別子に対応する履歴動作データを取得することができないので、他の登録されたユーザ識別子に対応する履歴動作データが、ユーザ識別子に対応する履歴動作データとして使用され得る。ユーザ識別子に対応するホッピングイベントのセットにおける各ホッピングイベントの発生確率は、履歴動作データに従って決定され得る。

リスクオペレーティングシステムにおいて、初期値をリスクパラメータのセットに割り当てた後、前の取引のための将来のリスク識別を識別するために、ユーザ識別子に対応する前の取引において生成された動作データに従って、前の取引におけるリスク識別のために使用されたリスクパラメータを調整することによって、リスクパラメータのセットに含まれたリスクパラメータが取得され得ることは、強調する価値がある。

言い換えれば、現在の取引のためのリスク識別のための方法では、リスク識別が根拠とするリスクパラメータのセットは、前の取引におけるリスク識別を行った後にリスクパラメータのセットを調整することによって取得された最新のリスクパラメータのセットである。調整されたリスクパラメータのセットが、次の取引のためのリスク識別のために使用される。

Ｓ１０４：少なくとも１つの動作ホッピングシーケンスに従って、獲得されたリスクパラメータを調整する。

本出願の実施形態では、現在の取引に関わる動作ホッピングシーケンスが、現在の取引を解析することによって決定されるとき、現在の取引に関わる動作ホッピングイベントもまた決定される。次いで、前述のように、各動作ホッピングイベントに対応するリスクパラメータが、リスクパラメータのセットにおいて包括的に確立されているので、現在の取引に関わる各動作ホッピングイベントに対応するリスクパラメータは、リスクパラメータのセットから決定され得る。動作ホッピングシーケンスのリスク値は、現在の取引に関わる各動作ホッピングイベントに対応するリスクパラメータ（発生確率であり得る）に従って決定され得る。現在の取引の各動作ホッピングシーケンスのリスク値を決定した後、現在の取引の最終的なリスク度が決定され得る。

本出願の実施形態では、少なくとも１つの動作ホッピングシーケンスが動作データに従って決定され、次いで、各動作ホッピングシーケンスのリスク値が決定され、最終的に、現在の取引のリスク度が、各動作ホッピングシーケンスのリスク値に従って決定される理由である。これらの技法は、動作データに関わるすべての動作ホッピングイベントに従って、リスク度を直接決定するとは限らない。これは、動作ホッピングシーケンスは、現在の取引の動作データによって反映される取引論理を反映することができるが、単一の動作ホッピングイベントは、現在の取引の取引論理を反映することができないからである。あるシーケンスにおける動作ホッピングイベントを含む動作ホッピングシーケンスは、取引論理を有する。現在の取引の解析は、実際には、現在の取引論理の解析を含み、現在の取引のためのリスク識別は、実際には、現在の取引論理が妥当であるか否かの判断である。したがって、同じ動作ホッピングイベントを含む２つの動作ホッピングシーケンスでも、それぞれ含まれた動作ホッピングイベントの異なる発生シーケンスのために、異なるリスク値に対応し得る。

本出願の実施形態では、取得されたリスクパラメータは、現在の取引に関わる動作ホッピングイベントにそれぞれ対応する。リスク度は、現在の取引に関わる各動作ホッピングシーケンスのリスク値を統合することによって取得される数値であり得るか、または、現在の取引に関わる各動作ホッピングシーケンスのリスク値を統合した後に評価されるグレードであり得る。

現在の取引のリスク度を決定した後、リスク識別システムは、リスク度に従って、現在の取引のリスク確率を決定し得、また、リスク度に従って、現在の取引を安全または安全でないとして分類し得る。要するに、本出願で請求される技術的解決策では、リスク値、リスク度、およびリスク識別の出力結果の特定の限定はない。

本出願の実施形態では、現在の取引のリスク度を決定した後、現在の取引に対応するリスク度が、設定されたしきい値よりも高いと決定されるとき、獲得されたリスクパラメータが減少され得、現在の取引に対応するリスク度が、設定されたしきい値よりも高くないと決定されるとき、獲得されたリスクパラメータが増加され得る。設定されたしきい値は、リスク管理職員によって最大の管理可能なリスク度として与えられた、あらかじめ設定された値であり得る。現在の取引のリスク度が、設定されたしきい値よりも高い場合、現在の取引のリスクが大きいことを示し、それによって、現在の取引に関わる動作ホッピングイベントの発生の妥当性が低いと推定されるべきであることが示される。すなわち、低い発生確率をもつ動作ホッピングイベントは、リスク管理職員が安全な取引において発生の可能性が低いと考えるであろうイベントである。

同様に、現在の取引のリスク度が、設定されたしきい値よりも低い場合、現在の取引のリスクが高くなく、現在の取引に関わる動作ホッピングイベントの発生が妥当であり、確立された期待値を満たす。言い換えれば、現在の取引に関わる動作ホッピングイベントは、おそらく、無許可のユーザによってではなく、ユーザの動作によって引き起こされており、次いで、現在の取引に関わる動作ホッピングイベントに対応するリスクパラメータは、不変のままであり得るか、または、現在の取引に関わる動作ホッピングイベントに対応するリスクパラメータが増加され得る。

もちろん、本出願の実施形態では、獲得されたリスクパラメータはまた、現在の取引のリスク度に従ってではなく調整され得るので、リスク度の決定を待機する必要がなくなる。各動作ホッピングシーケンスに対応するリスクパラメータは、動作ホッピングシーケンスのリスク値に従って調整され得る。例えば、高いリスク値をもつ動作ホッピングシーケンスはまた、動作ホッピングシーケンスに含まれたすべての動作ホッピングイベントを検討するとき、発生確率が全体的に低いことを示し得る。

例えば、動作ホッピングシーケンスが動作ホッピングイベントＴ１、Ｔ２、Ｔ３、Ｔ４およびＴ５を含むこと、ならびに、動作ホッピングイベントの発生のシーケンスが、シャオミンの場合はＴ１、Ｔ４、Ｔ３、Ｔ５およびＴ２であること、Ｔ１の発生確率（リスクパラメータ）が０．９であること、Ｔ４の発生確率が０．８であること、Ｔ３の発生確率が０．１であること、Ｔ４の発生確率が０．０５であること、ならびにＴ５の発生確率が０．１５であることを仮定すると、Ｔ１およびＴ２の発生確率が高い場合でも、Ｔ１、Ｔ４、Ｔ３、Ｔ５、Ｔ２がこの順序で同時に発生する確率は、極めて低い。さらに、動作ホッピングシーケンスのリスク値が高いと決定される。

本出願の実施形態では、１つの動作ホッピングイベントが、ユーザの各動作に従って定義され得、１つの動作ホッピングイベントはまた、取引に関わる２つの状態ごとの遷移に従って定義され得るか、または、１つの動作ホッピングイベントはまた、ユーザによって使用された端末デバイスの次元、現在の取引における指定された業者の次元、ユーザの現在の位置の次元、および他の利用可能な次元など、ユーザの次元以外の他の次元に従って定義され得る。例えば、「シャオミンが購入リンクをクリックした」または「購入リンクがクリックされなかった−＞購入リンクがクリックされた」は、動作ホッピングイベントであり得、「モバイルフォンが２次元コードをスキャンしなかった−＞モバイルフォンが２次元コードをスキャンした」は、動作ホッピングイベントであり得、「ナイキストアが毎分１足のスニーカーを販売した−＞ナイキストアが毎分１０足のスニーカーを販売した」は、動作ホッピングイベントであり得る。

手短に言えば、本出願は、動作ホッピングイベントをどのように定義するかについて限定しない。本出願の核心は、１つの取引を、独立して評価され得る一連の動作ホッピングイベントに離散化し、各動作ホッピングイベントのリスクパラメータを調整することによって、リスク識別システムの戦略を調整するようにすることである。

同じ理由で、本出願は、何の特定のアルゴリズムまたは方法が、各動作ホッピングイベントの報酬関数値、各動作ホッピングシーケンスのリスク値、および現在の取引のリスク度を計算および統合するために使用されるかについて限定せず、リスク管理職員は、ビジネスの状況に従って柔軟に判定を行うことができる。

要約すれば、図１に示すリスク識別のための方法を通して、各ユーザ識別子に対応するリスクパラメータが、電子取引サービスを提供するクライアント上に登録されたユーザ識別子ごとにそれぞれ設定される。リスクパラメータのオンラインのリアルタイム更新がサポートされる。このようにして、無許可のユーザが、ユーザのユーザ識別子を取得し、ユーザ識別子を通して、クライアント上で管理サーバへの支払い要求を開始すると、無許可のユーザが、ユーザ識別子に対応するリスクパラメータを一時的にクラックし、ユーザの資産損害を引き起こす場合でも、管理サーバは、リスク識別システムの手動の入力またはオフライン再トレーニングを待機することなしに、支払い要求に含まれた動作データに従って、オンラインでユーザ識別子に対応するリスクパラメータを、適時に動的に更新することができる。本出願で請求されるリスク識別のための方法を用いて、一方では、高コストの手動の入力が回避され、他方では、リスク識別システムが再トレーニングされるために数か月待機することなしに、リスクパラメータがオンラインで動的に更新され、したがって、適時にリスク識別システムのための更新を完了することができる。同時に、リスク識別システムの自己学習が、オンラインでリスクパラメータのセットにおけるリスクパラメータを動的に調整することによって実現される。

加えて、リスク識別のための既存の方法には、正確さが低いという問題もある。リスク識別のための既存の方法には、明らかな限定があり、すなわち、クライアントおよび管理サーバは、一括で異なるユーザによって開始された取引のリスクを識別するために、いくつかのリスク識別ルールに依拠する。

具体的には、背景技術において述べたように、リスク識別のための既存の方法の中の方法１と方法２の両方において、リスク識別のためにクライアントおよび管理サーバによって使用されるリスク識別ルールは、すべてのユーザに適用可能な共通のルールである。しかしながら、各ユーザは、共通のリスク識別ルールが当てはまらない、自分自身の特性を有する。例えば、一部のユーザは、当座貸越消費を好み、一度にバンクカード残高の８０％以上を使うことが多い。別の例では、一部のユーザは、２５歳未満であるが、経済力が強く、一度にＲＭＢ５，０００元を超えて送金する確率が高い。これらのユーザの場合、リスク識別のための既存の方法は不正確であり得る。

これらの２つの方法が組み合わせられる、すなわち、専門家の経験と履歴動作データの両方が、トレーニングのためにリスク識別システムに与えられる場合でも、リスク識別の正確さはある程度まで改善され得るが、背景技術において述べた問題は依然として存在しており、個人ユーザの属性を考慮することができないリスク識別のための方法の正確さは、依然として高くない。

すなわち、各ユーザによって生成された大量の履歴動作データを収集することによって、各ユーザに適用可能なリスク識別ルールが、動作データから抽出され得るが、ユーザの取引傾向は大きく変動し、ユーザの毎日の取引機会は固定されないので、異なるユーザに適用可能な１つのリスク識別ルールは大まかであることが多く、ユーザのいくつかの個別化された取引機会を省略しなければならない。

リスク識別ルール「ＲＭＢ５，０００元以上の送金を伴う取引は、午前１２：００と午前７：００との間は安全ではない」という一例を挙げると、経験によって、午前１２：００と午前７：００との間に多額のオンライン送金を行うことは常識に合わないので、このリスク識別ルールは、一般的に正確である。しかしながら、現代社会では、人々は、様々な仕事−休息のスケジュールを有している。一部のユーザは、ちょうど夜にアクティブであるので、午前１２：００と午前７：００との間に多額のオンライン取引を行うことがまったく可能である。そのため、これらのユーザの場合、このリスク識別ルールは不正確であり、これらのユーザによって行われた取引が、このリスク識別ルールに従って凍結される場合、ユーザにとってトラブルを引き起こすことになる。

この理由で、本出願で請求される技術的解決策では、ユーザ識別子ごとにリスクパラメータのセットを設定することによって、電子取引サービスを提供するクライアントを使用して、個別化されたリスク識別戦略がユーザごとにカスタマイズされる。各ユーザ識別子に対応するリスクパラメータのセットがカスタマイズされるので、一方では、リスク識別システムによって依拠されたリスク識別ルールは、各ユーザの個別化された特性に適合し、したがって、ある程度までリスク識別の正確さを改善する。他方では、無許可のユーザがリスク識別システムをバイパスすることがより困難である。無許可のユーザは、ユーザのユーザ識別子を取得することが必要であるのみでなく、無許可の取引をうまく実施するために、ユーザの毎日の取引傾向のある理解をも有していなければならない。

ユーザの個別化された取引傾向のみがリスク識別のために検査される場合、リスク識別の正確さが依然として高くないことを、実験が示すことに注目すべきである。すなわち、ユーザの取引傾向は、ユーザ識別子に対応するリスク識別ルールとして、事前に対応するユーザ識別子を通して、クライアント上のユーザの履歴取引に従って解析される。トレーダーがユーザ識別子を通して、オンライントレーディングを行うとき、ユーザ識別子を通して今回行われたトレーディング動作に従って判断され得る、トレーダーがユーザ識別子に対応するユーザであるか否かを決定する際に、リスク識別の正確さは依然として高くない。その理由は、次の通りである。

第１に、個別化されたリスク識別ルールは、既存の技術における「一括」の手法および大まかなリスク識別ルールの欠陥を克服するが、新しい欠点が引き起こされる。すなわち、個別化されたリスク識別ルールは、安定性が不十分である。すなわち、ビジネスの常識および統計に基づいて、ユーザグループの共通の取引傾向を精緻化することによって取得された、既存の技術におけるリスク識別ルールは、異なるユーザの個別化されたトレーディング機会に適合するためには大まかであり、困難であるが、統計的に安定している（大部分のユーザの共通の取引傾向が、共通のリスク識別ルールへと精緻化され得る）。反対に、個別化されたリスク識別ルールは、あるユーザの取引傾向に従って取得される。個々の取引傾向は、グループの取引傾向のように統計的に安定していない。個別化されたリスク識別ルールは、より具体的かつ詳細である。しかしながら、個人は、感情または予想外のイベントの影響下で取引傾向を変更することが多く、したがって、個別化されたリスク識別ルールが容易にゆがめられ、不安定になることを引き起こす。

例えば、シャオミンは、以前、正午に会社の階下のマクドナルドで食事をし、クライアントを通してオンラインで支払いをしていた。しかしながら、時々、シャオミンは、忙しすぎて階下に行けず、クライアントを通して、他のレストランからテイクアウトを注文しなければならないか、または、シャオミンは、最近は洋食のファーストフードを食べ飽きており、数日連続で中華料理を食べ、クライアントを通してオンラインで支払いをしている。数日連続で中華料理を食べるためのシャオミンの支払いの動きは、履歴データに基づいて取得されたオンライントレーディングの面から、シャオミンのためのリスク識別ルールに従って、安全でないトレーディングの動きとして判断される可能性が高いが、実際には、シャオミンのアカウントは盗まれていなかった。

第２に、モバイルフォンと比較して、クライアント上でユーザによって使用されるアカウントおよびパスワードは、盗まれる可能性がより高い。実際に、多数のオンライン資産窃盗の事件が、アカウントおよびパスワードが盗まれることによって引き起こされる。また、ユーザのアカウントおよびパスワードを用いてクライアントにログオンすると、無許可のユーザはまた、無許可の支払いおよび送金を行うために、ユーザの取引記録を見て、ユーザの取引傾向を模倣することもでき、それは、ユーザの取引傾向に従って取得されたリスク識別ルールによってほとんどカバーされない。

上記に鑑みて、本出願で請求される技術的解決策によって提供された好ましい実施形態では、リスク識別の信頼性を高めるために、ユーザの取引傾向のほかに、検査の少なくとも１つの他の次元が、リスク識別のために必要とされる。

概して、ユーザによる１つの取引に関わる次元には、（個別化された取引傾向に対応する）ユーザ識別子、端末デバイス（端末デバイスを使用するユーザの傾向に従って、端末デバイスと外界との間のデータ対話の法則が取得される）、業者（現在の取引に関わる業者）、位置（現在の取引の位置）、ロジスティックス（現在の取引において指定されたロジスティックス住所、荷受人情報など）、媒体（現在のネットワーク環境）などが含まれ得る。

本出願で請求されるリスク識別のための方法はまた、少なくとも２つの次元から、ユーザ識別子を通した現在の取引のリスク度を検査することによって、現在の取引のリスクを包括的に識別することもできることがわかる。本出願で請求される技術的解決策の好ましい実施形態は、少なくとも２つの次元においてリスク識別を行い、次いで、各次元の重みに従って、全体的なリスク識別を行うので、一方では、解決策のためのリスク識別のための方法は、個別化されたリスク識別を実現することができ、他方では、すべての次元の協調は、リスク識別ルールの個別化によって引き起こされる誤りを最小限に抑え、リスク識別システムの安定性を高め、したがって、リスク識別の正確さを向上させることもできる。

もちろん、本出願で請求される技術的解決策はまた、現在の取引を検査するために他の次元を採用することもでき、上記の次元の下で現在の取引を検査するための方法は、上記の例に限定されないことがある。要するに、ユーザ識別子を通して行われた現在の取引のリスクが、少なくとも２つの次元から検査され得る限り、本出願の多数の実施形態があり得、本出願にはこれに対する制限がない。複数の次元に基づくリスク識別のための別の方法について、添付の図面を参照しながら、以下で説明する。

図２は、本出願の実施形態によって提供される、リスク識別のための方法のフローチャートであり、この方法は、以下のステップを含む。

Ｓ２０１：支払い要求を受信する。

本出願の実施形態では、支払い要求は、現在の取引において生成された少なくとも１つの次元の動作データを搬送し得、また、ユーザ識別子と、ユーザ識別子を通して現在の取引において生成された動作データとを搬送し得る。

Ｓ２０２：それぞれの次元に関して、それぞれの次元の動作データに従って、現在の取引のリスク度を決定する。

前述のように、ユーザによる１つの取引に関わる少なくとも４つの次元があり、すなわち、（個別化された取引傾向に対応する）ユーザ識別子、端末デバイス（端末デバイスを使用するユーザの傾向に従って、端末デバイスと外界との間のデータ対話の法則が取得される）、業者（現在の取引に関わる業者）、位置（現在の取引の位置）、ロジスティックス（現在の取引において指定されたロジスティックス住所、荷受人情報など）、および媒体（現在のネットワーク環境）である。

例えば、ユーザ識別子の少なくとも１つの次元の動作データは、毎日、端末デバイスを通してログオンされるアカウントの数など、現在の取引に関わる端末デバイス次元の下のユーザ識別子の動作データ、またはシャオミンの毎日の購入傾向、およびシャオミンがクライアントにログオンした後に通常行う一連のアクション傾向など、現在の取引に関わるユーザ識別子次元の下の動作データ、または、毎日、業者とトレードされた顧客の特性、およびその位置の近くでトレードすることが多いユーザの特性など、現在の取引に関わる業者次元および位置次元の下の動作データであり得る。

ユーザ識別子（アカウント）次元は、ユーザの個別化された取引傾向を反映することができる。無許可のユーザが、トレーディングのためにユーザのアカウントを取得するとき、リスク識別システムは、ユーザ識別子次元からリスクを識別することができる。しかしながら、上述の２つの理由のために、ユーザ識別子次元からのみ行われたリスク識別の正確さは、高くない。

加えて、端末デバイス次元は、リスク識別の正確さを向上させるために、良い補足として使用され得る。現代社会では、モバイルフォンなどの端末デバイスはとても普及しているので、人々はほとんど端末デバイスを置くことがなく、端末デバイスが盗まれることはほとんどあり得ない。また、モバイルフォンが盗まれる場合でも、無許可のユーザは、モバイルフォンのパスワードでロックされた画面インターフェースのせいで、無許可の支払いまたは送金を行うために、モバイルフォンのオペレーティングシステムにおいて、クライアントへのアクセスを有することがほとんどできない。したがって、無許可のユーザは、ネットワークハッカー技術を用いて、ユーザのユーザ識別子を取得し、他の端末デバイス上でユーザ識別子を使用することが多い。すなわち、無許可のユーザが、無許可の取引のために他の端末デバイス上でユーザの取引傾向を模倣するために、盗まれたユーザ識別子を使用することができる場合でも、無許可のユーザは、ユーザによって使用されることが多い端末デバイスを使用せず、したがって、容易に発覚する。取引は、端末デバイス次元から、リスク識別システムによって異常として識別される。

他方では、テストは、端末デバイス次元およびユーザ識別子次元を組み合わせることによって、およびビジネスの経験に従って、リスク識別における異なる重みを２つの次元に与えて、「重複保険」を形成することで、リスク識別の正確さを効果的に向上させることができることを証明している。

例えば、自分のｉＰｈｏｎｅ（登録商標）（シリアル番号がＡであると仮定する）を使用するシャオミンの傾向は、毎日ｉＰｈｏｎｅ（登録商標） Ａにおいてクライアントにログオンされるアカウントの数が２を超えないことである。無許可のユーザは、無許可の取引のために頻繁に異なるアカウントでログオンするために、自分自身のモバイルフォンを使用することが多いので、無許可のユーザがシャオミンのアカウントを取得し、自分自身のｉＰｈｏｎｅ（登録商標） Ｂを用いて、シャオミンのアカウントでログオンし、シャオミンの取引傾向を模倣し、シャオミンが行くことが多い業者のところでお金を使う場合、ユーザ識別子次元からでも、リスク識別システムは、この取引のリスクを識別することができない。しかしながら、端末デバイス次元から、リスク識別システムは、それを通してシャオミンのアカウントが現在の取引においてログオンされているｉＰｈｏｎｅ（登録商標） Ｂが、シャオミンによって通常使用されているｉＰｈｏｎｅ（登録商標） Ａではなく、毎日、ｉＰｈｏｎｅ（登録商標） Ｂを通してログオンされる多数のアカウントがあることを識別することができる。したがって、ｉＰｈｏｎｅ（登録商標） Ｂが、おそらく、無許可の取引を実施するために、無許可のユーザによって使用された端末デバイスであると判断され、この取引が、端末デバイス次元から高リスクの取引として識別される。加えて、リスク識別システムは、無許可のユーザによって行われている現在の取引の動作データに従って、シャオミンのユーザ識別子に対応する端末デバイス次元のリスクパラメータのセットを調整することができるので、リスク識別におけるリスクパラメータ「毎日ｉＰｈｏｎｅ（登録商標） Ａにおいてクライアントにログオンされるアカウントの数が２を超えない」の割合が増加される。

加えて、無許可の取引に関わる業者は、無許可のユーザが盗品を販売する相手の業者であることが多く、そのため、現在の取引に関わる業者が、無許可のユーザが盗品を販売する相手の業者である確率を判断することを助けるために、業者を次元にする。例えば、宝石店Ａの平均の毎日の売上高はＲＭＢ５００，０００元であるが、毎日の売上高が一定期間にＲＭＢ２００万元で安定し、集約的な方法でオンラインで盗品を販売する犯罪者がいることが疑われる。シャオミンのアカウントが、この一定期間中に同じ犯罪者の集団によって盗まれる場合、リスク識別システムは、現在の取引に関わる業者が宝石店Ａであることを検出するとき、業者次元から、シャオミンのアカウントは窃盗のリスクが高いと決定し得る。すなわち、高いリスク度が業者次元から出力される。

同様に、ロジスティックス次元から、現在の取引によって指定されたロジスティックス情報と、平時にユーザによって指定されるロジスティックス情報との間の差が大きすぎるか否かが識別され得、媒体次元から、現在の取引のネットワーク環境がＷＩＦＩであるか、モバイルデータであるか、モバイルデータのサービスプロバイダがＣｈｉｎａ Ｍｏｂｉｌｅであるか、Ｃｈｉｎａ Ｕｎｉｃｏｍであるか、Ｃｈｉｎａ Ｔｅｌｅｃｏｍであるか、および、この情報とユーザの通常の媒体情報との間の差が大きすぎるか否かが識別され得る。

本出願の実施形態では、上記の次元の各々について、現在の取引のリスク度が、次元の動作データに従って決定され得る。具体的には、図１に示すリスクパラメータを調整するための方法、およびリスク識別のための方法が、動作データに従ってリスク度を決定するため、およびリスク識別を行うために採用され得る。すなわち、現在の取引において生成されたデバイス次元の少なくとも１つの動作ホッピングシーケンスは、次元（デバイス次元、ユーザ次元、業者次元、および位置次元のうちのいずれか１つ）の動作データに従って決定され得、デバイス次元の動作ホッピングシーケンスは、デバイス次元の少なくとも１つの動作ホッピングイベントを含み、デバイス次元の動作ホッピングシーケンスに含まれたデバイス次元の動作ホッピングイベントに対応するリスクパラメータは、デバイス次元の少なくとも１つの動作ホッピングシーケンスに従って決定される。リスクパラメータに従って、現在の取引のリスク度が決定される。

Ｓ２０３：次元に対応する現在の取引の異なるリスク度が取得されるとき、取得された異なるリスク度に従って、現在の取引においてリスク識別を行う。

本出願の実施形態では、取得される異なるリスク度が、特定の戦略ルールに従って計算されて、現在の取引のリスク係数が取得され得、リスク識別が、決定されたリスク係数に従って、現在の取引において行われ得る。

特定の戦略ルールは、異なるリスク度のための異なる重みを設定し、リスク度を統合して、リスク係数を取得することであり得るか、または、リスク度を単に加算して、リスク係数を取得し得る。手短に言えば、特定の戦略ルールは、総体的に現在の取引のリスクを反映するために、異なるリスク度を統合し得る。

図２に示す方法および図１に示す方法が同じ発明的概念に基づくことに注目すべきである。図２に示す方法では、現在の取引のリスク度が２つ以上の次元から決定され得、異なる次元におけるリスク度がリスク識別のためにさらに統合され得ることを除いて、図２に示す方法において各次元におけるリスク度を決定するための方法は、まさしく、図１に示す方法において現在の取引のリスク度を決定するための方法である。

リスク識別が現在の取引において行われるとき、検査される次元が多いほど、リスク識別の正確さが高くなる。最終的に、リスク識別システムは、各次元の決定されたリスク結果に従って、総体的に現在の取引のリスクを識別することができる。

図２に示すリスク識別のための方法では、サーバが現在の取引の支払い要求を受信するとき、図１に示すリスク識別のための方法が、少なくとも２つの次元の各々において一度実行される。各次元におけるリスク度が出力され、最終的に、現在の取引のリスク結果が、各次元におけるリスク度に従って決定され（例えば、現在の取引のリスク確率を決定するために、異なる次元におけるリスク度が正規化される）、したがって、現在の取引のためのリスク識別が実現され得る。各次元のリスクパラメータはまた、それぞれの次元の取引特性に従って調整され得る。

図１に示すリスクパラメータを調整するための方法に基づいて、本出願の実施形態はまた、対応して、図３に示すように、リスクパラメータを調整するためのデバイスを提供し、デバイスは、
支払い要求を受信する受信モジュール３０１であって、支払い要求が、ユーザ識別子と、ユーザ識別子を通して現在の取引において生成された動作データとを含む、受信モジュール３０１と、
動作データに従って、現在の取引において生じた少なくとも１つの動作ホッピングシーケンスを決定する、決定モジュール３０２であって、動作ホッピングシーケンスが、少なくとも１つの動作ホッピングイベントを含む、決定モジュール３０２と、
ユーザ識別子に対応するリスクパラメータのセットから、動作ホッピングシーケンスに含まれた動作ホッピングイベントに対応するリスクパラメータを獲得する、獲得モジュール３０３であって、リスクパラメータのセットに含まれたリスクパラメータが、ユーザ識別子に対応する前の取引において生成された動作データに従って、前の取引におけるリスク識別のために使用されたリスクパラメータを調整することによって取得される、獲得モジュール３０３と、
少なくとも１つの動作ホッピングシーケンスに従って、獲得されたリスクパラメータを調整する、調整モジュール３０４と、
を含む。

デバイスは、獲得されたリスクパラメータおよび少なくとも１つの動作ホッピングシーケンスに従って、現在の取引のリスク度を決定し、リスク度に従って、現在の取引においてリスク識別を行う、識別モジュール３０５をさらに含む。

調整モジュール３０４は、現在の取引に対応するリスク度が、設定されたしきい値よりも高いと決定するとき、獲得されたリスクパラメータを減少させ、現在の取引に対応するリスク度が、設定されたしきい値よりも高くないと決定するとき、獲得されたリスクパラメータを増加させ、調整されたリスクパラメータが、ユーザ識別子に対応する次の取引のためのリスク識別のために使用される。

デバイスは、リスク識別システムが初期化されるとき、支払い要求を受信する前に、ユーザ識別子に対応する動作ホッピングイベントのセットと、動作ホッピングイベントのセットに含まれた対応する動作ホッピングイベントのリスクパラメータの各々のための初期値とを決定する、初期化モジュール３０６をさらに含む。

初期化モジュール３０６は、異なるノードを定義し、異なるノードの間の動作ホッピングをトラバースして、複数の動作ホッピングイベントを取得する。複数の動作ホッピングイベントは、ノードのうちの２つを伴う。複数の動作ホッピングイベントに従って、動作ホッピングイベントのセットが取得される。

初期化モジュール３０６は、ユーザ識別子を通して生成された履歴動作データを獲得する。動作ホッピングイベントのセットに含まれた動作ホッピングイベントごとに、以下がそれぞれ実行され、すなわち、履歴動作データに従って、それぞれの動作ホッピングイベントの発生確率を決定すること、および、発生確率を、それぞれの動作ホッピングイベントのためのリスクパラメータの初期値として使用することである。

ユーザ識別子を通して生成された履歴動作データを獲得することができないとき、初期化モジュール３０６は、設定された数の他のユーザ識別子を使用して生成された履歴動作データを獲得する。動作ホッピングイベントのセットに含まれた動作ホッピングイベントごとに、以下がそれぞれ実行され、すなわち、履歴動作データに従って、それぞれの動作ホッピングイベントの発生確率を決定すること、および、発生確率を、それぞれの動作ホッピングイベントのためのリスクパラメータの初期値として使用することである。

識別モジュール３０５は、各動作ホッピングシーケンスに含まれた動作ホッピングイベントを決定し、各動作ホッピングイベントに対応するリスクパラメータに従って、動作ホッピングシーケンスのリスク値を決定する。各動作ホッピングシーケンスのリスク値を取得した後、各動作ホッピングシーケンスのリスク値に従って、現在の取引のリスク度を決定する。

図２に示すリスク識別のための方法に基づいて、本出願はまた、対応して、図４に示すように、リスク識別のためのデバイスを提供し、デバイスは、
支払い要求を受信する受信モジュール４０１であって、支払い要求が、現在の取引において生成された少なくとも１つの次元の動作データを含む、受信モジュール４０１と、
それぞれの次元に関して、それぞれの次元の動作データに従って、現在の取引のリスク度を決定する、決定モジュール４０２と、
次元に対応する現在の取引の異なるリスク度が取得されるとき、取得された異なるリスク度に従って、現在の取引においてリスク識別を行う、識別モジュール４０３と、
を含む。

それぞれの次元の動作データが、デバイス次元の動作データである場合、決定モジュール４０２は、デバイス次元の動作データに従って、現在の取引において生成されたデバイス次元の少なくとも１つの動作ホッピングシーケンスを決定することであって、デバイス次元の動作ホッピングシーケンスが、デバイス次元の少なくとも１つの動作ホッピングイベントを含む、決定すること、デバイス次元の少なくとも１つの動作ホッピングシーケンスに従って、デバイス次元の動作ホッピングシーケンスに含まれたデバイス次元の動作ホッピングイベントに対応するリスクパラメータを決定すること、および、リスクパラメータに従って、現在の取引のリスク度を決定することを行う。

それぞれの次元の動作データが、ユーザ次元の動作データである場合、決定モジュール４０２は、ユーザ次元の動作データに従って、現在の取引において生成されたユーザ次元の少なくとも１つの動作ホッピングシーケンスを決定することであって、ユーザ次元の動作ホッピングシーケンスが、ユーザ次元の少なくとも１つの動作ホッピングイベントを含む、決定すること、ユーザ次元の少なくとも１つの動作ホッピングシーケンスに従って、ユーザ次元の動作ホッピングシーケンスに含まれたユーザ次元の動作ホッピングイベントに対応するリスクパラメータを決定すること、および、リスクパラメータに従って、現在の取引のリスク度を決定することを行う。

それぞれの次元の動作データが、業者次元の動作データである場合、決定モジュール４０２は、業者次元の動作データに従って、現在の取引において生成された業者次元の少なくとも１つの動作ホッピングシーケンスを決定することであって、業者次元の動作ホッピングシーケンスが、業者次元の少なくとも１つの動作ホッピングイベントを含む、決定すること、業者次元の少なくとも１つの動作ホッピングシーケンスに従って、業者次元の動作ホッピングシーケンスに含まれた業者次元の動作ホッピングイベントに対応するリスクパラメータを決定すること、および、リスクパラメータに従って、現在の取引のリスク度を決定することを行う。

それぞれの次元の動作データが、位置次元の動作データである場合、決定モジュール４０２は、位置次元の動作データに従って、現在の取引において生成された位置次元の少なくとも１つの動作ホッピングシーケンスを決定することであって、位置次元の動作ホッピングシーケンスが、位置次元の少なくとも１つの動作ホッピングイベントを含む、決定すること、位置次元の少なくとも１つの動作ホッピングシーケンスに従って、位置次元の動作ホッピングシーケンスに含まれた位置次元の動作ホッピングイベントに対応するリスクパラメータを決定すること、および、リスクパラメータに従って、現在の取引のリスク度を決定することを行う。

識別モジュール４０３は、特定の戦略ルールに従って取得された異なるリスク度を計算して、現在の取引のリスク係数を取得し、決定されたリスク係数に従って、現在の取引においてリスク識別を行う。

図５は、本出願の実施形態によって提供される、リスク識別システムの図であり、システムは、
ユーザ識別子を通して現在の取引において生成された動作データを獲得し、動作データに従って、リスク解析を行い、リスク識別モジュールにリスク解析結果を送信する、スマートモジュール５０１であって、スマートモジュールの数が少なくとも１つであり、リスク解析結果が、リスク識別のための上記の方法によって取得される、スマートモジュール５０１と、
受信されたリスク解析結果に従って、リスク識別を行う、リスク識別モジュール５０２と、
を含む。

スマートモジュール５０１は、
ユーザ識別子を通して現在の取引において生成された動作データを獲得し、動作データに従って、少なくとも１つの動作ホッピングシーケンスを決定し、解析ユニットに少なくとも１つの動作ホッピングシーケンスを送信する、獲得ユニット５０１１と、
受信された動作ホッピングシーケンスに従って、リスク解析を行い、送信ユニットにリスク解析結果を出力する、解析ユニット５０１２と、
受信されたリスク解析結果に従って、リスク度を決定し、リスク識別モジュールにリスク度を送信する、送信ユニット５０１３と、
を特に含む。

図６ａ、図６ｂ、図６ｃ、および図６ｄは、本出願の実施形態によって提供される、リスク識別システムの詳細図である。図６ａ、図６ｂ、図６ｃ、および図６ｄに示すリスク識別システムのスマートモジュールの数は、多くともユーザ、端末デバイス、業者、および位置の４つの次元にそれぞれ対応する４つであるが、これは本出願の限定を構成するものではないことを強調する価値がある。

図６ａからわかるように、リスク識別システムは、１つの次元の動作データを収集し、収集された動作データに従って、現在の取引においてリスクがあるか否かを識別することができる。具体的な識別方法については、上記の実施形態において説明した。図６ａにおける１つの次元の動作データは、一例として、ユーザ次元の動作データを含む。

図６ｂからわかるように、リスク識別システムは、２つの次元の動作データを収集し、収集された動作データに従って、現在の取引においてリスクがあるか否かを識別することができる。具体的な識別方法については、上記の実施形態において説明した。図６ｂにおける２つの次元の動作データは、一例として、ユーザ次元の動作データと、デバイス次元の動作データとを含む。

図６ｃからわかるように、リスク識別システムは、３つの次元の動作データを収集し、収集された動作データに従って、現在の取引においてリスクがあるか否かを識別することができる。具体的な識別方法については、上記の実施形態において説明した。図６ｃにおける３つの次元の動作データは、一例として、ユーザ次元の動作データと、デバイス次元の動作データと、業者次元の動作データとを含む。

図６ｄからわかるように、リスク識別システムは、４つの次元の動作データを収集し、収集された動作データに従って、現在の取引においてリスクがあるか否かを識別することができる。具体的な識別方法については、上記の実施形態において説明した。図６ｄにおける４つの次元の動作データは、一例として、ユーザ次元の動作データと、デバイス次元の動作データと、業者次元の動作データと、位置次元の動作データとを含む。

図６ａ、図６ｂ、図６ｃ、および図６ｄに示すリスク識別システムでは、解析ユニットは、受信された動作ホッピングシーケンスごとのリスク値を決定し、リスク解析結果として、送信ユニットにリスク値を出力する。送信ユニットは、各受信されたリスク解析結果に従って、リスク度を決定し、最終判定のために、リスク識別モジュールにリスク度を送信し、現在の取引のためにリスク評価（例えば、リスク確率）を出力することができる。

図６ａ、図６ｂ、図６ｃ、および図６ｄに示すリスク識別システムでは、スマートモジュールは、互いに通信およびリンクすることができる。例えば、無許可のユーザがある業者に盗品を販売するときである。何か異常なものを発見した後、業者次元に対応するスマートモジュールは、他のスマートモジュールにこの新しいリスクを通知することができ、他のスマートモジュールは、この新しいリスクに従って、適時にそれらのリスク識別戦略を調整することができる。リスク識別システムが、このモジュール間のフィードバック機構を有するので、各モジュールのリスクパラメータのセットを常に最新に保つことができ、最新のオンラインリスクにより迅速に対応し、より正確にリスク識別を達成することができる。

図６ａ、図６ｂ、図６ｃ、および図６ｄに示すリスク識別システムは、強力なロバスト性を有する。すなわち、リスク識別システムは、２つ以上のスマートモジュールを含み得るので、１つのスマートモジュールにおいて異常が発生するとき、他のスマートモジュールが影響を受けることはない。リスク識別モジュールは、リスク識別のために、少なくとも１つのスマートモジュールによって送信されたリスク度を、依然として受信し得る。

加えて、図６ａ、図６ｂ、図６ｃ、および図６ｄに示すリスク識別システムはまた、対応するテストシステムを有し、すなわち、Ａ／Ｂテストオンラインモードを採用し得る。テストシステムおよびリスク識別システムは、同じアーキテクチャを有する。テストシステムは、数個のユーザ識別子に対応する取引におけるリスク識別のみを行う。新しいリスクが発生するとき、更新が最初にテストシステムにおいて行われ得る。テストシステムの性能が安定するか否かを観察した後、リスク管理職員は、リスク識別システム上で同じ更新を行うか否かを判定することができる。

１９９０年代では、技術の改善は、ハードウェア改善（例えば、ダイオード、トランジスタ、またはスイッチなどの回路構造の改善）とソフトウェア改善（方法手順の改善）との間で明確に区別され得る。しかしながら、技術の発展とともに、多数の方法手順の改善は、ハードウェア回路構造の直接的な改善と見なされ得る。ほとんどすべての設計職員は、改善された方法手順をハードウェア回路にプログラムして、対応するハードウェア回路構造を取得する。したがって、それは、方法手順の改善を、ハードウェアエンティティモジュールを使用することによって実施することができないという意味ではない。例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのプログラマブル論理デバイス（ＰＬＤ）は、その論理機能が、デバイスをプログラミングすることによってユーザによって決定される、集積回路のタイプである。設計者は、チップメーカーが専用集積回路チップを設計および準備することを必要とすることなしに、任意のプログラミングを行って、デジタルシステムを単一のＰＬＤに「集積」する。加えて、集積回路チップを手動で作成するのではなく、プログラミングは、大部分が、プログラムを書くために使用されるソフトウェアコンパイラと同様である「論理コンパイラソフトウェアを使用することによって実装される。コンパイル前の元のコードはまた、ハードウェア記述言語（ＨＤＬ）と呼ばれる、特定のプログラミング言語においても書かれる。Ａｄｖａｎｃｅｄ Ｂｏｏｌｅａｎ Ｅｘｐｒｅｓｓｉｏｎ Ｌａｎｇｕａｇｅ（ＡＢＥＬ）、Ａｌｔｅｒａ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＡＨＤＬ）、Ｃｏｎｆｌｕｅｎｃｅ、コーネル大学プログラミング言語（ＣＵＰＬ）、ＨＤＣａｌ、Ｊａｖａ（登録商標） Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＪＨＤＬ）、Ｌａｖａ、Ｌｏｌａ、ＭｙＨＤＬ、ＰＡＬＡＳＭ、Ｒｕｂｙ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＲＨＤＬ）など、多数のタイプのＨＤＬがある。現在、超高速集積回路ハードウェア記述言語（ＶＨＤＬ）およびＶｅｒｉｌｏｇが、最も一般的に使用されている。また、方法手順が、前述のハードウェア記述言語を使用することによって論理的にプログラムされ、次いで、集積回路にプログラムされる限り、論理的方法手順を実装するハードウェア回路が容易に取得され得ることも、当業者には理解されよう。

コントローラは、任意の好適な方法で実装され得、例えば、コントローラは、例えば、マイクロプロセッサまたはプロセッサ、および、プロセッサによって実行可能なコンピュータ可読プログラムコード（例えば、ソフトウェアまたはファームウェア）を記憶するコンピュータ可読媒体、論理ゲート、スイッチ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理コントローラ、ならびに組込みマイクロコントローラの形態をとることができる。コントローラの例には、限定はしないが、以下のマイクロコントローラ、すなわち、ＡＲＣ ６２５Ｄ、Ａｔｍｅｌ ＡＴ９１ＳＡＭ、Ｍｉｃｒｏｃｈｉｐ ＰＩＣ１８Ｆ２６Ｋ２０、およびＳｉｌｉｃｏｎｅ Ｌａｂｓ Ｃ８０５１Ｆ３２０が含まれる。メモリコントローラもまた、メモリ制御論理の一部として実装され得る。また、純粋なコンピュータ可読プログラムコードの形態においてコントローラを実装することに加えて、同じ機能を達成するために、論理ゲート、スイッチ、特定用途向け集積回路、プログラマブル論理コントローラ、および組込みマイクロコントローラの形態、ならびに他の形態において、コントローラを実装することも可能であることは、当業者には諒解されよう。したがって、そのようなコントローラを、ハードウェア構成要素と見なすことができ、様々な機能を実装するためにその中に含まれる装置もまた、ハードウェア構成要素の内部の構造と見なすことができる。代替的に、様々な機能を実装するように構成された装置を、ハードウェア構成要素の内部で方法および構造を実装する両方のソフトウェアモジュールと見なすことができる。

前述の実施形態において説明するシステム、装置、モジュール、またはユニットは、コンピュータチップもしくはエンティティによって特別に実装されるか、またはある機能を有する製品によって実装され得る。典型的な実装デバイスは、コンピュータである。具体的には、コンピュータは、例えば、パーソナルコンピュータ、ラップトップコンピュータ、セルラーフォン、カメラフォン、スマートフォン、携帯情報端末、メディアプレーヤ、ナビゲーションデバイス、電子メールデバイス、ゲーム機、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスのうちのいずれかの組合せであり得る。

説明しやすいように、装置について説明するとき、装置は、別個に説明する機能に従って、ユニットに分割される。もちろん、本出願の実装形態では、ユニットの機能は、ソフトウェアおよび／またはハードウェアのうちの同じものまたは複数のものにおいて実装され得る。

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

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

これらのコンピュータプログラム命令は、コンピュータ可読メモリにおいてさらに記憶され得、コンピュータプログラム命令は、コンピュータまたは任意の他のプログラマブルデータ処理デバイスに、特定の方法で作動するように命令することができ、コンピュータ可読メモリにおいて記憶された命令が、命令装置を含む人工物を生成するようになる。命令装置は、フローチャートにおける１つもしくは複数のプロセスにおける、および／またはブロック図における１つもしくは複数のブロックにおける、指定された機能を実装する。

これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイスにさらにロードされ得、一連の動作およびステップが、コンピュータまたは別のプログラマブルデバイス上で実行され、それによってコンピュータ実装処理を生成するようになる。したがって、コンピュータまたは別のプログラマブルデバイス上で実行された命令は、フローチャートにおける１つもしくは複数のプロセスにおける、および／またはブロック図における１つもしくは複数のブロックにおける、特定の機能を実施するためのステップを提供する。

典型的な構成では、コンピューティングデバイスは、１つまたは複数のプロセッサ（ＣＰＵ）と、入出力インターフェースと、ネットワークインターフェースと、メモリとを含む。

メモリには、コンピュータ可読媒体の中でも、ランダムアクセスメモリ（ＲＡＭ）などの非永続的メモリ、および／または、読取り専用メモリ（ＲＯＭ）もしくはフラッシュメモリ（フラッシュＲＡＭ）などの不揮発性メモリが含まれ得る。メモリは、コンピュータ可読媒体の一例である。

コンピュータ可読媒体には、任意の方法または技術を使用することによって、情報記憶を実行し得る、永続的、非永続的、移動可能、および移動不可な媒体が含まれる。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであり得る。コンピュータ記憶媒体の例には、限定はしないが、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ストレージ、カセット磁気テープ、テープおよびディスクストレージもしくは他の磁気記憶デバイス、または、コンピューティングデバイスがアクセスすることができる情報を記憶するように構成され得る任意の他の非伝送媒体が含まれる。本開示における定義に基づいて、コンピュータ可読媒体は、被変調データ信号および搬送波など、一時的コンピュータ可読媒体（一時的媒体）を含まない。

また、「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」という用語、および任意の他の変形態は、非排他的包含をカバーするものであることにも留意されたい。それによって、一連の要素を含むプロセス、方法、物品、またはデバイスは、それらの要素を含むのみではなく、明確にリストされない他の要素をも含むか、または、プロセス、方法、物品、およびデバイスの固有の要素を含む。さらなる限定なしに、「１つの．．．．．．を含む」という句によって定義される要素は、その要素を含むプロセス、方法、物品、またはデバイスにおける他の同じ要素を除外しない。

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

本出願は、コンピュータ、例えば、プログラムモジュールによって実行されるコンピュータ実行可能命令の一般的な状況において説明され得る。一般に、プログラムモジュールには、特定のタスクを実行するため、または特定の抽象データ型を実装するための、ルーチン、プログラム、オブジェクト、構成要素、データ構造などが含まれる。本出願はまた、通信ネットワークを通して接続されるリモート処理デバイスによって、タスクが行われる、分散コンピューティング環境においても実施され得る。分散コンピューティング環境では、プログラムモジュールは、記憶デバイスを含む、ローカルとリモートの両方のコンピュータ記憶媒体に位置し得る。

本開示の実施形態について、すべて進行形で説明している。実施形態における同じまたは同様の部分については、これらの実施形態への参照が行われ得る。各実施形態は、他の実施形態との差異に焦点を当てる。特に、システム実施形態は、基本的に方法実施形態と同様であり、したがって簡単に説明し、関連する部分については、方法実施形態における部分的な説明への参照が行われ得る。

前述の説明は、本出願の実施形態にすぎず、本出願を限定するものではない。当業者にとって、様々な修正および変形を本出願に行うことができる。本出願の趣旨および原理から逸脱することなしに行われたいかなる修正、等価な置換、または改善も、本出願の特許請求の範囲内に入るものである。

Claims (30)

1. リスクパラメータを調整するための方法であって、
   支払い要求を受信するステップであって、前記支払い要求が、ユーザ識別子と、前記ユーザ識別子を通して現在の取引において生成された動作データとを含む、ステップと、
   前記動作データに従って、前記現在の取引において生じた少なくとも１つの動作ホッピングシーケンスを決定するステップであって、前記動作ホッピングシーケンスが、少なくとも１つの動作ホッピングイベントを含む、ステップと、
   前記ユーザ識別子に対応するリスクパラメータのセットから、前記動作ホッピングシーケンスに含まれた前記動作ホッピングイベントに対応するリスクパラメータを獲得するステップであって、前記リスクパラメータのセットに含まれたリスクパラメータが、前記ユーザ識別子に対応する前の取引において生成された動作データに従って、前記前の取引におけるリスク識別のために使用されたリスクパラメータを調整することによって取得される、ステップと、
   前記少なくとも１つの動作ホッピングシーケンスに従って、前記獲得されたリスクパラメータを調整するステップと、
   を含む方法。
2. 前記獲得されたリスクパラメータおよび前記少なくとも１つの動作ホッピングシーケンスに従って、前記現在の取引のリスク度を決定するステップと、
   前記リスク度に従って、前記現在の取引においてリスク識別を行うステップと、
   をさらに含む、請求項１に記載の方法。
3. 前記少なくとも１つの動作ホッピングシーケンスに従って、前記獲得されたリスクパラメータを調整するステップが、
   前記現在の取引に対応する前記リスク度が、設定されたしきい値よりも高いと決定するとき、前記獲得されたリスクパラメータを減少させるステップと、
   前記現在の取引に対応する前記リスク度が、前記設定されたしきい値よりも高くないと決定するとき、前記獲得されたリスクパラメータを増加させるステップと、
   を含み、
   前記調整されたリスクパラメータが、前記ユーザ識別子に対応する次の取引のためのリスク識別のために使用される、請求項２に記載の方法。
4. 前記支払い要求を受信する前に、
   リスク識別システムが初期化されるとき、前記ユーザ識別子に対応する動作ホッピングイベントのセットと、前記動作ホッピングイベントのセットに含まれた対応する動作ホッピングイベントの前記リスクパラメータの各々のための初期値とを決定するステップをさらに含む、請求項２に記載の方法。
5. 前記動作ホッピングイベントのセットを決定するステップが、
   異なるノードを定義するステップと、
   前記異なるノードの間の動作ホッピングをトラバースして、複数の動作ホッピングイベントを取得するステップであって、前記複数の動作ホッピングイベントが、前記ノードのうちの２つを伴う、ステップと、
   前記複数の動作ホッピングイベントに従って、前記動作ホッピングイベントのセットを取得するステップと、
   を含む、請求項４に記載の方法。
6. 前記動作ホッピングイベントのセットに含まれた対応する動作ホッピングイベントの前記リスクパラメータの各々のための前記初期値を決定するステップが、
   前記ユーザ識別子を通して生成された履歴動作データを獲得するステップと、
   前記動作ホッピングイベントのセットに含まれた動作ホッピングイベントごとに、
   前記履歴動作データに従って、それぞれの動作ホッピングイベントの発生確率を決定するステップと、
   前記発生確率を、前記それぞれの動作ホッピングイベントのための前記リスクパラメータの前記初期値として使用するステップと、
   を実行するステップを含む、請求項４に記載の方法。
7. 前記動作ホッピングイベントのセットに含まれた対応する動作ホッピングイベントの前記リスクパラメータの各々のための前記初期値を決定するステップが、
   前記ユーザ識別子を通して生成された前記履歴動作データを獲得することができないとき、設定された数の他のユーザ識別子を使用して生成された履歴動作データを獲得するステップと、
   前記動作ホッピングイベントのセットに含まれた動作ホッピングイベントごとに、
   前記履歴動作データに従って、それぞれの動作ホッピングイベントの発生確率を決定するステップと、
   前記発生確率を、前記それぞれの動作ホッピングイベントのための前記リスクパラメータの前記初期値として使用するステップと、
   を実行するステップを含む、請求項４に記載の方法。
8. 前記獲得されたリスクパラメータおよび前記少なくとも１つの動作ホッピングシーケンスに従って、前記現在の取引の前記リスク度を決定するステップが、
   各動作ホッピングシーケンスに含まれた動作ホッピングイベントを決定し、各動作ホッピングイベントに対応する前記リスクパラメータに従って、前記動作ホッピングシーケンスのリスク値を決定するステップと、
   各動作ホッピングシーケンスの前記リスク値を取得した後、各動作ホッピングシーケンスの前記リスク値に従って、前記現在の取引の前記リスク度を決定するステップと、
   を含む、請求項６または７に記載の方法。
9. リスク識別のための方法であって、
   支払い要求を受信するステップであって、前記支払い要求が、現在の取引において生成された少なくとも１つの次元の動作データを含む、受信するステップと、
   それぞれの次元に関して、前記それぞれの次元の前記動作データに従って、前記現在の取引のリスク度を決定するステップと、
   次元に対応する前記現在の取引の異なるリスク度が取得されるとき、前記取得された異なるリスク度に従って、前記現在の取引においてリスク識別を行うステップと、
   を含む方法。
10. 前記それぞれの次元の前記動作データに従って、前記現在の取引の前記リスク度を決定するステップが、
    前記それぞれの次元の前記動作データが、デバイス次元の前記動作データである場合、前記デバイス次元の前記動作データに従って、前記現在の取引において生成された前記デバイス次元の少なくとも１つの動作ホッピングシーケンスを決定するステップであって、前記デバイス次元の前記動作ホッピングシーケンスが、前記デバイス次元の少なくとも１つの動作ホッピングイベントを含む、ステップと、
    前記デバイス次元の前記少なくとも１つの動作ホッピングシーケンスに従って、前記デバイス次元の前記動作ホッピングシーケンスに含まれた前記デバイス次元の前記動作ホッピングイベントに対応するリスクパラメータを決定するステップと、
    前記リスクパラメータに従って、前記現在の取引の前記リスク度を決定するステップと、
    を特に含む、請求項９に記載の方法。
11. 前記それぞれの次元の前記動作データに従って、前記現在の取引の前記リスク度を決定するステップが、
    前記それぞれの次元の前記動作データが、ユーザ次元の前記動作データである場合、前記ユーザ次元の前記動作データに従って、前記現在の取引において生成された前記ユーザ次元の少なくとも１つの動作ホッピングシーケンスを決定するステップであって、前記ユーザ次元の前記動作ホッピングシーケンスが、前記ユーザ次元の少なくとも１つの動作ホッピングイベントを含む、ステップと、
    前記ユーザ次元の前記少なくとも１つの動作ホッピングシーケンスに従って、前記ユーザ次元の前記動作ホッピングシーケンスに含まれた前記ユーザ次元の前記動作ホッピングイベントに対応するリスクパラメータを決定するステップと、
    前記リスクパラメータに従って、前記現在の取引の前記リスク度を決定するステップと、
    をさらに含む、請求項１０に記載の方法。
12. 前記それぞれの次元の前記動作データに従って、前記現在の取引の前記リスク度を決定するステップが、
    前記それぞれの次元の前記動作データが、業者次元の前記動作データである場合、前記業者次元の前記動作データに従って、前記現在の取引において生成された前記業者次元の少なくとも１つの動作ホッピングシーケンスを決定するステップであって、前記業者次元の前記動作ホッピングシーケンスが、前記業者次元の少なくとも１つの動作ホッピングイベントを含む、ステップと、
    前記業者次元の前記少なくとも１つの動作ホッピングシーケンスに従って、前記業者次元の前記動作ホッピングシーケンスに含まれた前記業者次元の前記動作ホッピングイベントに対応するリスクパラメータを決定するステップと、
    前記リスクパラメータに従って、前記現在の取引の前記リスク度を決定するステップと、
    をさらに含む、請求項１１に記載の方法。
13. 前記それぞれの次元の前記動作データに従って、前記現在の取引の前記リスク度を決定するステップが、
    前記それぞれの次元の前記動作データが、位置次元の前記動作データである場合、前記位置次元の前記動作データに従って、前記現在の取引において生成された前記位置次元の少なくとも１つの動作ホッピングシーケンスを決定するステップであって、前記位置次元の前記動作ホッピングシーケンスが、前記位置次元の少なくとも１つの動作ホッピングイベントを含む、ステップと、
    前記位置次元の前記少なくとも１つの動作ホッピングシーケンスに従って、前記位置次元の前記動作ホッピングシーケンスに含まれた前記位置次元の前記動作ホッピングイベントに対応するリスクパラメータを決定するステップと、
    前記リスクパラメータに従って、前記現在の取引の前記リスク度を決定するステップと、
    をさらに含む、請求項１２に記載の方法。
14. 前記取得された異なるリスク度に従って、前記現在の取引においてリスク識別を行うステップが、
    特定の戦略ルールに従って取得された前記異なるリスク度を計算して、前記現在の取引のリスク係数を取得するステップと、
    前記決定されたリスク係数に従って、前記現在の取引においてリスク識別を行うステップと、
    をさらに含む、請求項９に記載の方法。
15. リスクパラメータを調整するためのデバイスであって、
    支払い要求を受信する受信モジュールであって、前記支払い要求が、ユーザ識別子と、前記ユーザ識別子を通して現在の取引において生成された動作データとを含む、受信モジュールと、
    前記動作データに従って、前記現在の取引において生じた少なくとも１つの動作ホッピングシーケンスを決定する、決定モジュールであって、前記動作ホッピングシーケンスが、少なくとも１つの動作ホッピングイベントを含む、決定モジュールと、
    前記ユーザ識別子に対応するリスクパラメータのセットから、前記動作ホッピングシーケンスに含まれた前記動作ホッピングイベントに対応するリスクパラメータを獲得する、獲得モジュールであって、前記リスクパラメータのセットに含まれたリスクパラメータが、前記ユーザ識別子に対応する前の取引において生成された動作データに従って、前記前の取引におけるリスク識別のために使用されたリスクパラメータを調整することによって取得される、獲得モジュールと、
    前記少なくとも１つの動作ホッピングシーケンスに従って、前記獲得されたリスクパラメータを調整する、調整モジュールと、
    を備えるデバイス。
16. 前記デバイスが、識別モジュールをさらに備え、
    前記識別モジュールが、前記獲得されたリスクパラメータおよび前記少なくとも１つの動作ホッピングシーケンスに従って、前記現在の取引のリスク度を決定し、前記リスク度に従って、前記現在の取引においてリスク識別を行う、請求項１５に記載のデバイス。
17. 前記調整モジュールが、前記現在の取引に対応する前記リスク度が、設定されたしきい値よりも高いと決定するとき、前記獲得されたリスクパラメータを減少させ、前記現在の取引に対応する前記リスク度が、前記設定されたしきい値よりも高くないと決定するとき、前記獲得されたリスクパラメータを増加させ、前記調整されたリスクパラメータが、前記ユーザ識別子に対応する次の取引のためのリスク識別のために使用される、請求項１６に記載のデバイス。
18. 前記デバイスが、初期化モジュールをさらに備え、
    前記初期化モジュールが、リスク識別システムが初期化されるとき、前記支払い要求を受信する前に、前記ユーザ識別子に対応する動作ホッピングイベントのセットと、前記動作ホッピングイベントのセットに含まれた対応する動作ホッピングイベントの前記リスクパラメータの各々のための初期値とを決定する、請求項１６に記載のデバイス。
19. 前記初期化モジュールが、異なるノードを定義すること、前記異なるノードの間の動作ホッピングをトラバースして、複数の動作ホッピングイベントを取得することであって、前記複数の動作ホッピングイベントが、前記ノードのうちの２つを伴う、取得すること、および、前記複数の動作ホッピングイベントに従って、前記動作ホッピングイベントのセットを取得することを行う、請求項１８に記載のデバイス。
20. 前記初期化モジュールが、前記ユーザ識別子を通して生成された履歴動作データを獲得し、前記動作ホッピングイベントのセットに含まれた動作ホッピングイベントごとに、前記初期化モジュールが、前記履歴動作データに従って、それぞれの動作ホッピングイベントの発生確率を決定すること、および、前記発生確率を、前記それぞれの動作ホッピングイベントのための前記リスクパラメータの前記初期値として使用することを実行する、請求項１９に記載のデバイス。
21. 前記ユーザ識別子を通して生成された前記履歴動作データを獲得することができないとき、前記初期化モジュールが、設定された数の他のユーザ識別子を使用して生成された履歴動作データを獲得し、前記動作ホッピングイベントのセットに含まれた動作ホッピングイベントごとに、前記初期化モジュールが、前記履歴動作データに従って、それぞれの動作ホッピングイベントの発生確率を決定すること、および、前記発生確率を、前記それぞれの動作ホッピングイベントのための前記リスクパラメータの前記初期値として使用することを実行する、請求項１９に記載のデバイス。
22. 前記識別モジュールが、各動作ホッピングシーケンスに含まれた前記動作ホッピングイベントを決定し、各動作ホッピングイベントに対応する前記リスクパラメータに従って、前記動作ホッピングシーケンスのリスク値を決定すること、および、各動作ホッピングシーケンスの前記リスク値を取得した後、各動作ホッピングシーケンスの前記リスク値に従って、前記現在の取引のリスク度を決定することを行う、請求項１９または２０に記載のデバイス。
23. リスク識別のためのデバイスであって、
    支払い要求を受信する受信モジュールであって、前記支払い要求が、現在の取引において生成された少なくとも１つの次元の動作データを含む、受信モジュールと、
    それぞれの次元に関して、前記それぞれの次元の前記動作データに従って、前記現在の取引のリスク度を決定する、決定モジュールと、
    次元に対応する前記現在の取引の異なるリスク度が取得されるとき、前記取得された異なるリスク度に従って、前記現在の取引においてリスク識別を行う、識別モジュールと、
    を備えるデバイス。
24. 前記それぞれの次元の前記動作データが、デバイス次元の前記動作データである場合、前記決定モジュールが、前記デバイス次元の前記動作データに従って、前記現在の取引において生成された前記デバイス次元の少なくとも１つの動作ホッピングシーケンスを決定することであって、前記デバイス次元の前記動作ホッピングシーケンスが、前記デバイス次元の少なくとも１つの動作ホッピングイベントを含む、決定すること、前記デバイス次元の前記少なくとも１つの動作ホッピングシーケンスに従って、前記デバイス次元の前記動作ホッピングシーケンスに含まれた前記デバイス次元の前記動作ホッピングイベントに対応するリスクパラメータを決定すること、および、前記リスクパラメータに従って、前記現在の取引の前記リスク度を決定することを行う、請求項２３に記載のデバイス。
25. 前記それぞれの次元の前記動作データが、ユーザ次元の前記動作データである場合、前記決定モジュールが、前記ユーザ次元の前記動作データに従って、前記現在の取引において生成された前記ユーザ次元の少なくとも１つの動作ホッピングシーケンスを決定することであって、前記ユーザ次元の前記動作ホッピングシーケンスが、前記ユーザ次元の少なくとも１つの動作ホッピングイベントを含む、決定すること、前記ユーザ次元の前記少なくとも１つの動作ホッピングシーケンスに従って、前記ユーザ次元の前記動作ホッピングシーケンスに含まれた前記ユーザ次元の前記動作ホッピングイベントに対応するリスクパラメータを決定すること、および、前記リスクパラメータに従って、前記現在の取引の前記リスク度を決定することを行う、請求項２４に記載のデバイス。
26. 前記それぞれの次元の前記動作データが、業者次元の前記動作データである場合、前記決定モジュールが、前記業者次元の前記動作データに従って、前記現在の取引において生成された前記業者次元の少なくとも１つの動作ホッピングシーケンスを決定することであって、前記業者次元の前記動作ホッピングシーケンスが、前記業者次元の少なくとも１つの動作ホッピングイベントを含む、決定すること、前記業者次元の前記少なくとも１つの動作ホッピングシーケンスに従って、前記業者次元の前記動作ホッピングシーケンスに含まれた前記業者次元の前記動作ホッピングイベントに対応するリスクパラメータを決定すること、および、前記リスクパラメータに従って、前記現在の取引の前記リスク度を決定することを行う、請求項２５に記載のデバイス。
27. 前記それぞれの次元の前記動作データが、位置次元の前記動作データである場合、前記決定モジュールが、前記位置次元の前記動作データに従って、前記現在の取引において生成された前記位置次元の少なくとも１つの動作ホッピングシーケンスを決定することであって、前記位置次元の前記動作ホッピングシーケンスが、前記位置次元の少なくとも１つの動作ホッピングイベントを含む、決定すること、前記位置次元の前記少なくとも１つの動作ホッピングシーケンスに従って、前記位置次元の前記動作ホッピングシーケンスに含まれた前記位置次元の前記動作ホッピングイベントに対応するリスクパラメータを決定すること、および、前記リスクパラメータに従って、前記現在の取引の前記リスク度を決定することを行う、請求項２６に記載のデバイス。
28. 前記識別モジュールが、特定の戦略ルールに従って取得された前記異なるリスク度を計算して、前記現在の取引のリスク係数を取得し、前記決定されたリスク係数に従って、前記現在の取引においてリスク識別を行う、請求項２３に記載のデバイス。
29. リスク識別システムであって、
    取引要求を受信し、ユーザ識別子を通して現在の取引において生成された動作データを獲得し、前記動作データに従って、リスク解析を行い、リスク識別モジュールにリスク解析結果を送信する、少なくとも１つのスマートモジュールであって、前記リスク解析結果が、請求項１から８に記載の方法によって取得される、スマートモジュールと、
    前記受信されたリスク解析結果に従って、リスク識別を行う、前記リスク識別モジュールと、
    を備える、リスク識別システム。
30. 前記スマートモジュールが、
    前記ユーザ識別子を通して前記現在の取引において生成された前記動作データを獲得し、前記動作データに従って、少なくとも１つの動作ホッピングシーケンスを決定し、解析ユニットに前記少なくとも１つの動作ホッピングシーケンスを送信する、獲得ユニットと、
    前記受信された動作ホッピングシーケンスに従って、リスク解析を行い、送信ユニットに前記リスク解析結果を出力する、前記解析ユニットと、
    前記受信されたリスク解析結果に従って、リスク度を決定し、前記リスク識別モジュールに前記リスク度を送信する、前記送信ユニットと、
    を特に備える、請求項２９に記載のシステム。