(57)【要約】  本人確認方法が開示され、この方法は、被検証デバイスから本人確認要求を受信するステップであって、本人確認要求が、被検証デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される、ステップと、履歴特徴情報とデバイス環境情報とに従って、被検証デバイスの信用性を判定するステップであって、履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ステップと、本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定するステップとを含む。本出願の実施形態における方法によれば、ユーザが意識することなく、現在のユーザが保持するデバイスに適用可能な本人確認ポリシーが、ユーザが保持するデバイスの信用性に従ってユーザに対して選択され得る。したがって、本出願の実施形態は、本人確認のセキュリティおよび信頼性の改善を容易にし、ユーザの使用要件を満たすことができ、ユーザ体験を改善することができる。
2021508889.tif 000002
【特許請求の範囲】
【請求項１】
本人確認方法であって、
被検証デバイスから本人確認要求を受信するステップであって、前記本人確認要求が、前記被検証デバイスのデバイス環境情報を含み、前記被検証デバイスに対応するユーザの本人確認を要求するために使用される、ステップと、
履歴特徴情報と前記デバイス環境情報とに従って、前記被検証デバイスの信用性を判定するステップであって、前記履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ステップと、
本人確認ポリシーに従って本人確認を実行するために、前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人確認を実行するための前記本人確認ポリシーを決定するステップとを含む、
方法。
【請求項２】
履歴特徴情報と前記デバイス環境情報とに従って、前記被検証デバイスの信用性を判定するステップが、
前記デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致する場合、前記デバイス環境情報に従って前記被検証デバイスに対応する特徴ベクトルを決定するステップと、
前記特徴ベクトルをデバイス検証モデルに入力し、前記デバイス検証モデルを使用することによって前記被検証デバイスの前記信用性を判定するステップであって、前記デバイス検証モデルが、前記デバイス環境情報に基づいて、前記本人確認要求を送信するデバイスの信用性ラベルと、前記本人確認要求が信用できる要求として予測される確率とを決定するように構成される、ステップとを含む、
請求項1に記載の方法。
【請求項３】
前記特徴ベクトルをデバイス検証モデルに入力し、前記デバイス検証モデルを使用することによって前記被検証デバイスの前記信用性を判定するステップの前に、前記方法が、
前記履歴デバイスに対応する履歴特徴情報を取得するステップと、
前記履歴特徴情報に対応する時間間隔に従って、第1の履歴特徴情報を含む訓練セットと、第2の履歴特徴情報を含む検証セットとを決定するステップと、
前記第1の履歴特徴情報を使用することによって前記デバイス検証モデルを訓練し、前記第2の履歴特徴情報を使用することによって前記デバイス検証モデルを検証するステップとをさらに含む、
請求項2に記載の方法。
【請求項４】
前記履歴特徴情報に対応する時間間隔に従って、第1の履歴特徴情報を含む訓練セットと、第2の履歴特徴情報を含む検証セットとを決定するステップが、
前記履歴特徴情報に対応する前記時間間隔に従って、以前の時間に生成された第1の履歴特徴情報を前記訓練セットに割り当て、以後の時間に生成された第2の履歴特徴情報を前記検証セットに割り当てるステップをさらに含む、
請求項3に記載の方法。
【請求項５】
前記デバイス検証モデルが、LR(ロジスティック回帰)モデルとXGBoost(極度勾配ブースティング)モデルとを備え、前記第1の履歴特徴情報を使用することによって前記デバイス検証モデルを訓練するステップが、
前記第1の履歴特徴情報に従って、第1の履歴特徴ベクトルと、第2の履歴特徴ベクトルと、前記第1の履歴特徴情報に対応する履歴デバイスの第1の信用性ラベルとを決定するステップと、
前記第1の履歴特徴ベクトルをLRモデルに入力するステップと、
ロジスティック回帰LRモデルの出力が予め設定された条件を満たすまで、前記第1の信用性ラベルと、前記LRモデルによって出力された第1のターゲットラベルとに従って、前記LRモデルのモデルパラメータを調整するステップと、
前記訓練されたLRモデルの出力に従って、前記第1の履歴特徴情報に対応する前記デバイスによって送信された本人確認要求が信用できる要求として予測される第1の確率を計算するステップと、
前記第1の確率と前記第2の履歴特徴ベクトルとをXGBoostモデルに入力するステップと、
前記XGBoostモデルの出力が予め設定された条件を満たすまで、前記XGBoostモデルの前記出力と前記第1の信用性ラベルとに基づいて、前記XGBoostモデルのモデルパラメータを調整するステップであって、前記XGBoostモデルの前記出力が、前記第1の履歴特徴情報に対応する前記履歴デバイスの前記第1の信用性ラベルと、前記履歴デバイスによって送信された本人確認要求が信用できる要求であるとして予測される確率とを含む、ステップとを含む、
請求項3に記載の方法。
【請求項６】
前記第2の履歴特徴情報を使用することによって前記デバイス検証モデルを検証するステップが、
前記第2の履歴特徴情報に従って、第3の履歴特徴ベクトルと、第4の履歴特徴ベクトルと、前記第2の履歴特徴情報に対応する履歴デバイスの第2の信用性ラベルとを決定するステップと、
前記第3の履歴特徴ベクトルを前記訓練されたLRモデルに入力するステップと、
前記訓練されたLRモデルの出力に従って、前記第2の履歴特徴情報に対応する前記デバイスによって送信された本人確認要求が信用できる要求として予測される第2の確率を計算するステップと、
前記第2の確率と前記第4の履歴特徴ベクトルとを前記訓練されたXGBoostモデルに入力し、前記訓練されたXGBoostモデルを使用することによって前記デバイス検証モデルの出力を取得するステップであって、前記デバイス検証モデルの前記出力が、前記第2の履歴特徴情報に対応する前記履歴デバイスの前記第2の信用性ラベルと、前記履歴デバイスによって送信された本人確認要求が信用できる要求として予測される第3の確率とを含む、ステップと、
前記デバイス検証モデルの前記出力と前記第2の信用性ラベルとに従ってバイナリ分類方法を使用することによって前記デバイス検証モデルの評価データを取得するステップと、
前記デバイス検証モデルの前記評価データが予め設定された条件を満たすまで、前記評価データに従って前記LRモデルの前記モデルパラメータおよび/または前記XGBoostモデルの前記モデルパラメータを調整するステップとを含む、
請求項5に記載の方法。
【請求項７】
前記デバイス検証モデルの前記評価データが、F1スコアおよびAUC(曲線下面積)値のうちの少なくとも1つを含む、
請求項6に記載の方法。
【請求項８】
前記LRモデルの前記モデルパラメータが、正則化項、正則化係数、および最大反復数のうちの少なくとも1つを含む、
請求項5から7のいずれか一項に記載の方法。
【請求項９】
前記第1の履歴特徴ベクトルの成分の数が、前記第2の履歴特徴ベクトルの成分の数よりも多い、
請求項5から7のいずれか一項に記載の方法。
【請求項１０】
前記履歴デバイスが、履歴ログインデバイスおよび履歴本人確認デバイスのうちの少なくとも1つを含む、
請求項1から7のいずれか一項に記載の方法。
【請求項１１】
履歴特徴情報と前記デバイス環境情報とに従って、前記被検証デバイスの信用性を判定するステップが、
前記デバイス環境情報内に含まれる情報のタイプが前記予め設定された情報タイプと一致しない場合、前記被検証デバイスが信用できないと判定するステップを含む、
請求項1から7のいずれか一項に記載の方法。
【請求項１２】
前記予め設定された情報タイプが、デバイスの識別ID、ならびに、前記デバイスに対応するWi-Fi接続、LBS(位置ベースのサービス)、およびIP(インターネットプロトコル)アドレスのうちの少なくとも1つを含む、
請求項11に記載の方法。
【請求項１３】
前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人確認を実行するための本人確認ポリシーを決定するステップが、
前記被検証デバイスの前記信用性と、前記本人確認ポリシーと信用性間隔との間の対応関係とに従って、前記ユーザに対する本人確認を実行するための前記本人確認ポリシーを決定するステップを含み、
前記本人確認ポリシーに一致するリスクレベルが、ユーザが保持するデバイスの信用性と負の関係にある、
請求項1から7のいずれか一項に記載の方法。
【請求項１４】
前記本人確認ポリシーは、本人確認情報タイプ、本人確認情報量、および本人確認しきい値範囲のうちの少なくとも1つを含み、
前記本人確認ポリシーに一致する前記リスクレベルが、前記ユーザが保持するデバイスの前記信用性と負の関係にあることが、
前記本人確認ポリシーが前記本人確認情報タイプを含む場合、前記本人確認ポリシー内の前記本人確認情報タイプのセキュリティレベルが、前記ユーザが保持するデバイスの前記信用性と負の関係にあること、
前記本人確認ポリシーが前記本人確認情報量を含む場合、前記本人確認ポリシー内の前記本人確認情報量が、前記ユーザが保持するデバイスの前記信用性と負の関係にあること、および、
前記本人確認ポリシーが前記本人確認しきい値範囲を含む場合、前記本人確認ポリシー内の前記本人確認しきい値範囲が、前記ユーザが保持するデバイスの信用性と正の関係にあること、のうちの少なくとも1つを含む、
請求項13に記載の方法。
【請求項１５】
前記本人確認ポリシーに従って前記本人確認を実行するステップが、
前記本人確認ポリシーに従って、本人確認プロセスと、前記本人確認に必要な情報と、前記本人確認に必要な前記情報の本人確認しきい値範囲とを決定するステップと、
前記本人確認プロセスに従って、前記被検証デバイスに対して前記本人確認に必要な前記情報を報告するように促すステップと、
前記被検証デバイスから前記本人確認に必要な前記情報を受信すると、前記本人確認に必要な前記情報の前記本人確認しきい値範囲に従って前記本人確認を実行するステップとを含む、
請求項1に記載の方法。
【請求項１６】
被検証デバイスから本人確認要求を受信するように構成された要求受信モジュールであって、前記本人確認要求が、前記被検証デバイスのデバイス環境情報を含み、前記被検証デバイスに対応するユーザの本人確認を要求するために使用される、要求受信モジュールと、
履歴特徴情報と前記デバイス環境情報とに従って、前記被検証デバイスの信用性を判定するように構成された信用性判定モジュールであって、前記履歴特徴情報が履歴デバイスのデバイス環境情報を含む、信用性判定モジュールと、
本人確認ポリシーに従って本人確認を実行するために、前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人確認を実行するための前記本人確認ポリシーを決定するように構成された本人確認ポリシー決定モジュールとを備える、
本人確認装置。
【請求項１７】
プロセッサと、
実行されると、前記プロセッサに動作を実行させるコンピュータ実行可能命令を記憶するように構成されたメモリとを備えた、
電子デバイスであって、前記動作が、
被検証デバイスから本人確認要求を受信することであって、前記本人確認要求が、前記被検証デバイスのデバイス環境情報を含み、前記被検証デバイスに対応するユーザの本人確認を要求するために使用される、ことと、
履歴特徴情報と前記デバイス環境情報とに従って、前記被検証デバイスの信用性を判定することであって、前記履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ことと、
本人確認ポリシーに従って本人確認を実行するために、前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人確認を実行するための前記本人確認ポリシーを決定することとを含む、
電子デバイス。
【請求項１８】
複数のアプリケーションを含む電子デバイスによって実行されると、前記電子デバイスに以下の動作を実行させる1つまたは複数のプログラムを記憶するコンピュータ可読記憶媒体であって、前記動作が、
被検証デバイスから本人確認要求を受信することであって、前記本人確認要求が、前記被検証デバイスのデバイス環境情報を含み、前記被検証デバイスに対応するユーザの本人確認を要求するために使用される、ことと、
履歴特徴情報と前記デバイス環境情報とに従って、前記被検証デバイスの信用性を判定することであって、前記履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ことと、
本人確認ポリシーに従って本人確認を実行するために、前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人確認を実行するための前記本人確認ポリシーを決定することとを含む、
コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、コンピュータ技術の分野に関し、特に、本人確認方法および装置に関する。
【背景技術】
【０００２】
モバイルインターネットの人気とモバイル決済サービスの発展とによって、より多くのユーザが、オンラインショッピングおよび決済などの操作のためにスマート端末を使用している。
【０００３】
ユーザサービスおよびリソースのセキュリティを保護するために、ユーザがシステムにログインするか、またはサービスに参加するとき、システムにログインすること、またはサービスに参加することを要求しているユーザが対応する許可を有するかどうかを判断するため、すなわち、システムにログインしているユーザが実際のユーザであるかどうかを判定するために、通常、ユーザの身元が検証される必要がある。したがって、本人確認のセキュリティおよび信頼性において、比較的高い要件が課せられる。
【０００４】
したがって、本人確認のセキュリティおよび信頼性を改善するのを助け、ユーザの使用要件を満たす本人確認方法が緊急に必要とされている。
【発明の概要】
【課題を解決するための手段】
【０００５】
本出願の実施形態は、本人確認のセキュリティおよび信頼性を改善し、ユーザの使用要件を満たす本人確認方法および装置を提供する。
【０００６】
本出願の実施形態は、以下の技術的解決策を採用する。
【０００７】
第1の態様によれば、本出願の実施形態は、本人確認方法を提供し、方法は、
被検証デバイスから本人確認要求を受信するステップであって、本人確認要求が、被検証デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される、ステップと、
履歴特徴情報とデバイス環境情報とに従って、被検証デバイスの信用性を判定するステップであって、履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ステップと、
本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定するステップとを含む。
【０００８】
オプションで、第1の態様において提供される本人確認方法において、履歴特徴情報とデバイス環境情報とに従って、被検証デバイスの信用性を判定するステップは、
デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致する場合、デバイス環境情報に従って被検証デバイスに対応する特徴ベクトルを決定するステップと、
特徴ベクトルをデバイス検証モデルに入力し、デバイス検証モデルを使用することによって被検証デバイスの信用性を判定するステップであって、デバイス検証モデルが、デバイス環境情報に基づいて、本人確認要求を送信するデバイスの信用性ラベルと、本人確認要求が信用できる要求として予測される確率とを決定するように構成される、ステップとを含む。
【０００９】
オプションで、第1の態様において提供される本人確認方法において、特徴ベクトルをデバイス検証モデルに入力し、デバイス検証モデルを使用することによって被検証デバイスの信用性を判定するステップの前に、方法は、
履歴デバイスに対応する履歴特徴情報を取得するステップと、
履歴特徴情報に対応する時間間隔に従って、第1の履歴特徴情報を含む訓練セットと、第2の履歴特徴情報を含む検証セットとを決定するステップと、
第1の履歴特徴情報を使用することによってデバイス検証モデルを訓練し、第2の履歴特徴情報を使用することによってデバイス検証モデルを検証するステップとをさらに含む。
【００１０】
オプションで、第1の態様において提供される本人確認方法において、履歴特徴情報に対応する時間間隔に従って、第1の履歴特徴情報を含む訓練セットと、第2の履歴特徴情報を含む検証セットとを決定するステップは、
履歴特徴情報に対応する時間間隔に従って、以前の時間に(at an earlier moment)生成された第1の履歴特徴情報を訓練セットに割り当て、以後の時間に(at a later moment)生成された第2の履歴特徴情報を検証セットに割り当てるステップをさらに含む。
【００１１】
オプションで、第1の態様において提供される本人確認方法において、デバイス検証モデルは、LR(ロジスティック回帰)モデルとXGBoost(極度勾配ブースティング)モデルとを備え、第1の履歴特徴情報を使用することによってデバイス検証モデルを訓練するステップは、
第1の履歴特徴情報に従って、第1の履歴特徴ベクトルと、第2の履歴特徴ベクトルと、第1の履歴特徴情報に対応する履歴デバイスの第1の信用性ラベルとを決定するステップと、
第1の履歴特徴ベクトルをLRモデルに入力するステップと、LRモデルの出力が予め設定された条件を満たすまで、第1の信用性ラベルと、LRモデルによって出力された第1のターゲットラベルとに従って、LRモデルのモデルパラメータを調整するステップと、
訓練されたLRモデルの出力に従って、第1の履歴特徴情報に対応するデバイスによって送信された本人確認要求が信用できる要求として予測される第1の確率を計算するステップと、
第1の確率と第2の履歴特徴ベクトルとをXGBoostモデルに入力するステップと、XGBoostモデルの出力が予め設定された条件を満たすまで、XGBoostモデルの出力と第1の信用性ラベルとに基づいて、XGBoostモデルのモデルパラメータを調整するステップであって、XGBoostモデルの出力が、第1の履歴特徴情報に対応する履歴デバイスの第1の信用性ラベルと、履歴デバイスによって送信された本人確認要求が信用できる要求であるとして予測される確率とを含む、ステップとを含む。
【００１２】
オプションで、第1の態様において提供される本人確認方法において、第2の履歴特徴情報を使用することによってデバイス検証モデルを検証するステップは、
第2の履歴特徴情報に従って、第3の履歴特徴ベクトルと、第4の履歴特徴ベクトルと、第2の履歴特徴情報に対応する履歴デバイスの第2の信用性ラベルとを決定するステップと、
第3の履歴特徴ベクトルを訓練されたLRモデルに入力するステップと、訓練されたLRモデルの出力に従って、第2の履歴特徴情報に対応するデバイスによって送信された本人確認要求が信用できる要求として予測される第2の確率を計算するステップと、
第2の確率と第4の履歴特徴ベクトルとを訓練されたXGBoostモデルに入力し、訓練されたXGBoostモデルを使用することによってデバイス検証モデルの出力を取得するステップであって、デバイス検証モデルの出力が、第2の履歴特徴情報に対応する履歴デバイスの第2の信用性ラベルと、履歴デバイスによって送信された本人確認要求が信用できる要求として予測される第3の確率とを含む、ステップと、
デバイス検証モデルの出力と第2の信用性ラベルとに従ってバイナリ分類方法を使用することによってデバイス検証モデルの評価データを取得するステップと、
デバイス検証モデルの評価データが予め設定された条件を満たすまで、評価データに従ってLRモデルのモデルパラメータおよび/またはXGBoostモデルのモデルパラメータを調整するステップとを含む。
【００１３】
オプションで、第1の態様において提供される本人確認方法において、デバイス検証モデルの評価データは、F1スコアおよびAUC(曲線下面積)値のうちの少なくとも1つを含む。
【００１４】
オプションで、第1の態様において提供される本人確認方法において、LRモデルのモデルパラメータは、正則化項、正則化係数、および最大反復数のうちの少なくとも1つを含む。
【００１５】
オプションで、第1の態様において提供される本人確認方法において、第1の履歴特徴ベクトルの成分の数は、第2の履歴特徴ベクトルの成分の数よりも多い。
【００１６】
オプションで、第1の態様において提供される本人確認方法において、履歴デバイスは、履歴ログインデバイスおよび履歴本人確認デバイスのうちの少なくとも1つを含む。
【００１７】
オプションで、第1の態様において提供される本人確認方法において、履歴特徴情報とデバイス環境情報とに従って、被検証デバイスの信用性を判定するステップが、
デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致しない場合、被検証デバイスが信用できないと判定するステップを含む。
【００１８】
オプションで、第1の態様において提供される本人確認方法において、予め設定された情報タイプは、デバイスの識別ID、ならびに、デバイスに対応するワイヤレス接続(Wi-Fi)、LBS(位置ベースのサービス)、およびIP(インターネットプロトコル)アドレスのうちの少なくとも1つを含む。
【００１９】
オプションで、第1の態様において提供される本人確認方法において、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定するステップは、
被検証デバイスの信用性と、本人確認ポリシーと信用性間隔との間の対応関係とに従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定するステップを含み、
本人確認ポリシーに一致するリスクレベルが、ユーザが保持するデバイスの信用性と負の関係にある。
【００２０】
オプションで、第1の態様において提供される本人確認方法において、本人確認ポリシーは、本人確認情報タイプ、本人確認情報量、および本人確認しきい値範囲のうちの少なくとも1つを含み、
本人確認ポリシーに一致するリスクレベルが、ユーザが保持するデバイスの信用性と負の関係にあることは、
本人確認ポリシーが本人確認情報タイプを含む場合、本人確認ポリシー内の本人確認情報タイプのセキュリティレベルが、ユーザが保持するデバイスの信用性と負の関係にあること、
本人確認ポリシーが本人確認情報量を含む場合、本人確認ポリシー内の本人確認情報量が、ユーザが保持するデバイスの信用性と負の関係にあること、および、
本人確認ポリシーが本人確認しきい値範囲を含む場合、本人確認ポリシー内の本人確認しきい値範囲が、ユーザが保持するデバイスの信用性と正の関係にあること、のうちの少なくとも1つを含む。
【００２１】
オプションで、第1の態様において提供される本人確認方法において、本人確認ポリシーに従って本人確認を実行するステップが、
本人確認ポリシーに従って、本人確認プロセスと、本人確認に必要な情報と、本人確認に必要な情報の本人確認しきい値範囲とを決定するステップと、
本人確認プロセスに従って、被検証デバイスに対して本人確認に必要な情報を報告するように促すステップと、
被検証デバイスから本人確認に必要な情報を受信すると、本人確認に必要な情報の本人確認しきい値範囲に従って本人確認を実行するステップとを含む。
【００２２】
第1の態様によれば、本出願の実施形態は、本人確認装置を提供し、本人確認装置は、
被検証デバイスから本人確認要求を受信するように構成された要求受信モジュールであって、本人確認要求が、被検証デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される、要求受信モジュールと、
履歴特徴情報とデバイス環境情報とに従って、被検証デバイスの信用性を判定するように構成された信用性判定モジュールであって、履歴特徴情報が履歴デバイスのデバイス環境情報を含む、信用性判定モジュールと、
本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定するように構成された本人確認ポリシー決定モジュールとを含む。
【００２３】
第1の態様によれば、本出願の実施形態は、電子デバイスを提供し、電子デバイスは、
プロセッサと、
実行されると、プロセッサに動作を実行させるコンピュータ実行可能命令を記憶するように構成されたメモリとを含み、動作は、
被検証デバイスから本人確認要求を受信することであって、本人確認要求が、被検証デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される、ことと、
履歴特徴情報とデバイス環境情報とに従って、被検証デバイスの信用性を判定することであって、履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ことと、
本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定することとを含む。
【００２４】
第4の態様によれば、本出願の実施形態は、複数のアプリケーションを含む電子デバイスによって実行されると、電子デバイスに動作を実行させる1つまたは複数のプログラムを記憶するコンピュータ可読記憶媒体を提供し、動作は、
被検証デバイスから本人確認要求を受信することであって、本人確認要求が、被検証デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される、ことと、
履歴特徴情報とデバイス環境情報とに従って、被検証デバイスの信用性を判定することであって、履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ことと、
本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定することとを含む。
【００２５】
本出願の実施形態において採用された少なくとも1つの技術的解決策は、以下の有益な効果を達成することができる。
【００２６】
本出願の実施形態において、検証要求が被検証デバイスから受信された後、検証は、直接実行されないが、被検証デバイスの信用性は、履歴デバイスのデバイス環境情報と被検証デバイスのデバイス環境情報とに従って判定され、ユーザに対する本出願を実行するための本人確認ポリシーは、信用性に従ってさらに決定される。本出願の実施形態における方法によれば、ユーザが意識することなく、現在のユーザが保持するデバイスに適用可能な本人確認ポリシーが、ユーザが保持するデバイスの信用性に従ってユーザに対して選択され得る。したがって、本出願の実施形態は、本人確認のセキュリティおよび信頼性の改善を容易にし、ユーザの使用要件を満たすことができ、ユーザ体験を改善することができる。
【００２７】
本明細書で説明する添付図面は、本出願のさらなる理解を提供するために使用され、本出願の一部を構成する。本出願の例示的な実施形態およびその説明は、本出願を説明するために使用され、本出願に対する不適切な限定を構成しない。
【図面の簡単な説明】
【００２８】
【図１】本出願の実施形態による本人確認方法の概略フローチャートである。
【図２】本出願の実施形態による本人確認方法の第2の概略フローチャートである。
【図３】本出願の実施形態による本人確認方法の第3の概略フローチャートである。
【図４】本出願の実施形態による本人確認方法の第4の概略フローチャートである。
【図５】本出願の実施形態による本人確認方法の第5の概略フローチャートである。
【図６】本出願の実施形態による本人確認方法の第6の概略フローチャートである。
【図７】本出願の実施形態による本人確認装置の概略構成図である。
【図８】本出願の実施形態による電子デバイスの概略構成図である。
【発明を実施するための形態】
【００２９】
本出願の目的、技術的解決策、および利点をより明確にするために、本出願の技術的解決策について、本出願の実施形態を参照して以下に明確かつ完全に説明する。説明する実施形態は、本出願の実施形態のすべてではなく、一部のみであることは明らかである。創造的な努力なしに本出願の実施形態に基づいて当業者が取得するすべての他の実施形態は、本出願の保護範囲内に入るものとする。
【００３０】
インターネット時代においては、モバイルインターネットまたはモバイル決済サービスにかかわらず、ネットワークプラットフォームにアクセスする、またはサービスシステムを使用するユーザの身元を検証する必要があり、すなわち、ネットワークプラットフォームおよびサービスシステムのセキュリティを確実にするために、本人チェックまたは本人確認を実行する必要があり、それによって、ネットワークプラットフォームにアクセスする、またはサービスシステムを使用するユーザが正当な権限を有することを保証する。特定の実施の間、本人確認機能を実装する本人確認システムは、サービスシステムから独立した専用の本人確認システム、またはサービスシステムの一部のいずれかであってもよい。
【００３１】
ユーザの本人確認中、本人確認に本人確認を申し込んでいるユーザによって入力された情報(例えば、ログインパスワード、支払いパスワード、指紋など)が、本人確認システムのバックエンド内に記憶された情報と比較されてもよい。情報が条件(例えば、完全な一貫性、または予め設定された範囲内の偏差など)を満たすことが比較によって判定された場合、本人確認を申し込んでいるユーザの本人確認は、成功したと見なされてもよく、ユーザは、サービスに参加する権限を有すると見なされてもよい。
【００３２】
オプションで、指紋検証、顔検証、声紋検証、虹彩検証などの生物学的検証が、本人確認のために使用されてもよい。特定の実施中、本人確認を申し込んでいるユーザの生物学的特徴は、バックエンド内に記憶された生物学的特徴と比較されてもよく、ユーザの身元は、比較結果に従って検証されてもよい。
【００３３】
オプションで、テキストメッセージコード検証またはセキュリティ質問検証も、本人確認のために使用されてもよい。特定の実施中、本人確認システムは、ランダムに生成されたテキストメッセージ検証コードまたは予め設定されたセキュリティ質問を、本人確認を申し込んでいるユーザに提供してもよい。テキストメッセージコードまたはユーザによってフィードバックされたセキュリティ質問への回答が受信された後、ユーザの身元は、ユーザの回答が、記憶された回答、または本人確認システムによって決定される正しい回答と一致するかどうかを判定することによって検証されてもよい。
【００３４】
技術レベルの改善に伴い、上記の態様のうちの1つのみを改善すること、例えば、パスワード検証のセキュリティを改善するために、より長く、より複雑で、より時間効率の高いパスワードを設計すること、または、サードパーティのパスワード(例えば、テキストメッセージ検証コード)を送信することの安定性を保証するために、帯域幅とサーバの安定性とを改善し、それによって、本人確認のセキュリティおよび信頼性を改善することは、限界費用を増加させる可能性がある。
【００３５】
本人確認のセキュリティおよび信頼性を改善し、ユーザの使用要件を満たすために、本出願の実施形態は、本人確認システムによって実行されるべき本人確認方法を提供する。本人確認システムは、サービスシステムから独立していてもよく、または、サービスプロセスにおいてユーザの身元を検証する機能を実装するためにサービスシステムの一部として使用されてもよいことが理解されよう。本出願のこの実施形態において提供される検証方法において、本人確認を申し込んでいるユーザの潜在的なリスクを判定するために、デバイス環境情報を使用することによって補助的な検証が実行されてもよい。例えば、ユーザによって保持されたデバイスの信用性が、ユーザが保持するデバイスのデバイス環境情報と履歴デバイスのデバイス環境情報とに従って判定され、ユーザに対する本人確認を実行するための本人確認ポリシーが、信用性に従ってさらに判定される。
【００３６】
端末デバイスのより高い信用性は、本人確認を申し込んでいるユーザによるモバイル端末のより合理的で安全な使用を示すことに留意すべきである。したがって、比較的低いリスクレベルに一致する比較的中程度の本人確認ポリシーが、ユーザの身元を検証するために使用されてもよい。相応して、端末デバイスのより低い信用性は、本人確認を申し込んでいるユーザによるモバイル端末の使用が合理的でなく安全ではないことを示す。したがって、比較的高いリスクレベルに合致する比較的厳密な本人確認ポリシーが、ユーザの身元を検証するために使用される必要がある。
【００３７】
本出願のこの実施形態におけるユーザによって保持される端末デバイスおよび被検証デバイスは、パーソナルコンピュータなどのデバイスであってもよく、または、スマートフォンもしくはタブレットコンピュータなどのモバイル端末デバイスであってもよいことが理解されよう。端末デバイスは、本人確認要求を送信し、サービスへの参加を申し込むためにユーザによって使用される。
【００３８】
本出願のこの実施形態における方法によれば、デバイスコア情報は、ユーザが意識することなく持続可能に本人確認を支援するために使用されてもよい。さらに、生物学的特徴検証、セキュリティ質問検証などの強力な検証方法がさらに使用されてもよく、現在のユーザが保持するデバイスに適した本人確認ポリシーが、ユーザが保持するデバイスの判定された信用性に基づいてユーザに対して選択されてもよい。オプションで、生物学的特徴の検証またはセキュリティ質問検証は、デバイスの信用性に従って適切に調整されてもよい。例えば、デバイスのより高い信用性は、顔検証中のより低い比較しきい値を示してもよい。別の例では、デバイスのより高い信用性は、セキュリティ質問検証中のより少ない質問を示してもよい。
【００３９】
したがって、本出願の実施形態において、デバイス環境情報は、本人確認を支援するために使用され、本人確認のセキュリティおよび信頼性を改善するのを助ける。加えて、本人確認ポリシーは、ユーザのユーザ要件がより満たされ得、ユーザ体験が改善され得るように、デバイスの信頼性に従って選択されてもよい。
【００４０】
本出願の実施形態において提供される技術的解決策について、図面を参照して以下に詳細に説明する。
【００４１】
図1を参照すると、本出願の実施形態は、本人確認システムによって実行され得る本人確認方法を提供する。方法は、以下のステップを含んでもよい。
【００４２】
S101:被検証デバイスから本人確認要求を受信し、本人確認要求は、被検証デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される。
【００４３】
ユーザがサービスシステムにログインすること、またはサービスシステムにおいてサービス要求を開始することを望む場合、通常、本人確認が最初に実行される必要があり、すなわち、ユーザの身元が検証される必要があることが理解されよう。本人確認システムは、ステップS101において受信された本人確認要求を実行する。本人確認要求は、保持された端末デバイスを介してユーザによって開始されたログイン要求もしくはサービス要求であってもよく、または、デバイスに対応するユーザに対する本人確認を要求するための専用の本人確認要求であってもよい。
【００４４】
オプションで、被検証デバイスのデバイス環境情報は、被検証デバイスの識別ID、被検証デバイスが接続されているネットワークプラットフォーム上のインターネットプロトコル(IP)アドレスなどを含んでもよい。モバイル通信ネットワークまたはワイヤレスネットワークに接続された被検証デバイスについて、被検証デバイスのデバイス環境情報は、ワイヤレスフィデリティ(Wi-Fi)接続、位置ベースのサービス(LBS)などをさらに含んでもよい。
【００４５】
被検証デバイスが本人確認要求を本人確認システムに送信すると、被検証デバイスは、インターネットまたはモバイルインターネットに確実に接続されることが理解されよう。したがって、被検証デバイスによって本人確認デバイスに送信されるデバイス環境情報は、(保有する識別IDによって具体化される)被検証デバイスの識別情報と、デバイスに対応するIPアドレス、Wi-Fi、LBSなどによって具体化され得る、被検証デバイスを使用することによって本人確認を申し込むときにユーザに対して承認されるネットワーク環境とを反映することができる。
【００４６】
S103:履歴特徴情報とデバイス環境情報とに従って被検証デバイスの信用性を判定し、履歴特徴情報は、履歴デバイスのデバイス環境情報を含む。
【００４７】
被検証デバイスのデバイス環境情報が受信された後、本人確認システムは、被検証デバイスのデバイス環境情報を含む履歴特徴を使用することによって被検証デバイスの信用性を判定するステップS103をさらに実行する。特定のユーザは、通常、1つまたは複数の頻繁に使用される端末デバイス(例えば、スマートフォン、タブレットコンピュータ、ウェアラブルインテリジェントデバイス、ラップトップなど)と、通常接続が確立されている1つまたは複数のネットワーク環境(例えば、ホームネットワーク、オフィスネットワーク、よく行くショッピングモールネットワーク、レストランネットワークなど)とに対応することが理解されよう。接続が頻繁に確立されるこれらの頻繁に使用される端末デバイスおよびネットワーク環境は、上記の履歴特徴情報によって具体化されてもよい。したがって、本人確認システムは、履歴特徴情報と、本人確認を申し込んでいる現在のデバイスのデバイス環境情報とに基づいて、被検証デバイスの信用性を判定してもよい。特定のユーザによる被検証デバイスを介する本人確認の申し込みが合理的であり、ルーチンと一致するかどうかが、信用性を使用することによって判定されてもよい。
【００４８】
被検証デバイスの信用性は、様々な方法において、様々な特定の標準を使用することによって、履歴特徴情報とデバイス環境情報とに従って判定されてもよい。例えば、被検証デバイスの識別IDは、履歴特徴情報内の履歴デバイスの識別IDと比較されてもよい。IDが同じである場合、被検証デバイスが信用できる可能性が高いと考えられてもよい。別の例では、被検証デバイスが接続されているネットワーク環境と、履歴特徴情報内の履歴デバイスが接続されているネットワーク環境との間でマッチングが実行されてもよい。ネットワーク環境が互いに一致する(例えば、被検証デバイスおよび履歴デバイスが同じWi-Fiに接続されている)場合、被検証デバイスが信用できる可能性が高いと考えられてもよい。さらに別の例では、LBSに基づいて決定された被検証デバイスの位置情報と、履歴特徴情報内のLBSに基づいて決定された履歴デバイスの位置情報との間でマッチングが実行されてもよい。位置情報が互いに一致しない(例えば、被検証デバイスの位置が履歴特徴情報内に現れない)場合、被検証デバイスが信用できない可能性が高いと考えられてもよい。
【００４９】
オプションで、本人確認システムが履歴特徴情報とデバイス環境情報とに従って被検証デバイスの信用性を判定する場合、被検証デバイスのデバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致しない場合、本人確認システムは、被検証デバイスが信用できないと直接判定してもよい。予め設定された情報タイプがデバイスの識別ID、ならびに、デバイスに対応するワイヤレス接続(Wi-Fi)、位置ベースのサービス(LBS)、およびインターネットプロトコル(IP)アドレスのうちの少なくとも1つを含んでもよいことが理解されよう。ユーザが異なるタイプのネットワーク環境に接続される可能性がある異なるタイプのデバイスを使用する可能性があるので、ネットワークに通常接続されているときにデバイスが有することができる情報のタイプに従って、異なる予め設定された情報タイプが異なるネットワーク環境に対して予め設定されることに留意すべきである。この場合、被検証デバイスによって本人確認システムに送信されるデバイス環境情報が予め設定された情報タイプにおいて指定されたタイプの情報を欠いている場合、本来報告されることが必要なデバイス環境情報が本人確認システムによる検証から逃れるように隠される結果として、被検証デバイスが違法に使用されると見なされてもよい。したがって、本人確認システムは、被検証デバイスが信用できないと直接判定してもよく、次いで、本人確認のより高いリスクレベルに適用可能な、より厳密な本人確認ポリシーを採用してもよい。
【００５０】
オプションで、本人確認は、デバイス検証モデルを使用することによって、履歴特徴情報とデバイス環境情報とに従って被検証デバイスの信用性を判定してもよい。例えば、デバイス検証モデルの入力は、被検証デバイスのデバイス環境情報に従って決定された特徴ベクトルであり、出力は、被検証デバイスの信用性ラベル、および、被検証デバイスによって送信された本人確認要求が信用できる要求として予測される確率である。したがって、ユーザに対する本人確認を実行するための本人確認ポリシーが、これに基づいて決定され得る。
【００５１】
デバイス検証モデルを構築および訓練するための方法、ならびに、デバイス検証モデルを使用することによって被検証デバイスの信用性を判定する特定の実装形態プロセスについて、例を使用することによって以下に詳細に説明する。
【００５２】
S105:本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定する。
【００５３】
オプションで、ユーザに対する本人確認プロセスを実行するための本人確認ポリシーは、被検証デバイスの信用性と、本人確認ポリシーと信用性間隔との間の対応関係とに従って決定されてもよい。本人確認ポリシーに一致するリスクレベルは、ユーザが保持するデバイスの信用性と負の関係にある。
【００５４】
特定の実施中、ステップS105が実行される前に、本人確認ポリシーと信用性間隔との間の対応関係が予め設定されてもよい。より高いデバイス信頼性は、より信頼性が高く妥当なデバイスと、デバイスがサービスシステムにログインまたはアクセスすることを許可するより低いリスクとを示す。したがって、より低いリスクレベルに一致する本人確認ポリシーが、本人確認を実行するために採用されてもよい。逆に、より低いデバイス信用性は、信用性が低く妥当ではないデバイスと、デバイスがサービスシステムにログインまたはアクセスことを許可するより高いリスクとを示す。したがって、より高いリスクレベルに一致する本人確認ポリシーが、本人確認を実行するために採用されてもよい。
【００５５】
被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定する間、被検証デバイスの信用性が特定の信用性間隔内に入る場合、信用性間隔に対応する本人確認ポリシーが、被検証デバイスを使用することによってユーザに対する本人確認を実行するための本人確認ポリシーとして決定されてもよい。
【００５６】
本人確認情報、本人確認情報量、および本人確認しきい値範囲のうちの1つまたは複数が、異なる本人確認ポリシーにおいて異なってもよいことに留意すべきである。
【００５７】
例えば、本人確認ポリシーが本人確認情報タイプを含む場合、本人確認ポリシー内の本人確認情報タイプのより高いセキュリティレベルは、ユーザが保持するデバイスのより低い信頼性により適用可能である。したがって、本人確認情報タイプのセキュリティレベルは、デバイスの信用性と負の関係にあることが理解されよう。本人確認情報タイプのセキュリティレベルは、複数の基準に従って定義されてもよい。例えば、ユーザの指紋、顔、虹彩、および声紋などの生物学的特性は、独特であり再現不可能であるので、ユーザの固有の生物学的特性情報を含む本人確認情報は、通常、テキストメッセージ検証、パスワード検証、セキュリティ質問検証におけるものなどの本人確認情報よりも高いセキュリティレベルを有すると考えられてもよい。別の例では、一回有効な動的ショートテキストメッセージ検証コードは、固定されたセキュリティ質問におけるものなどの本人確認情報よりも高いセキュリティレベルを有すると考えられてもよい。ユーザが保持するデバイスの信用性が比較的低い場合、本人確認結果の信頼性とサービスシステムのセキュリティとを保証するために、より高いセキュリティレベルを有する本人確認情報が本人確認を実行するために使用されてもよいことが理解されよう。ユーザが保持するデバイスの信用性が比較的高い場合、本人確認システムの本人確認要件を満たすために、より低いセキュリティレベルを有する本人確認情報が本人確認を実行するために使用されてもよい。
【００５８】
別の例では、本人確認ポリシーが本人確認情報量を含む場合、本人確認ポリシー内のより大きい本人確認情報量は、ユーザが保持するデバイスのより低い信用性により適用可能である。したがって、本人確認情報量は、デバイスの信用性と負の関係にあることが理解されよう。より大きい本人確認情報量は、より多くの観点からユーザに対して実行される本人確認を示す可能性があり、より確実な本人確認結果をもたらす可能性がある。オプションで、ユーザが保持するデバイスが比較的低い信用性を有する場合、本人確認情報量は、ユーザに対してより包括的な本人確認を実行し、サービスシステムのセキュリティを保証するために増加されてもよい。オプションで、ユーザが保持するデバイスが比較的高い信用性を有する場合、本人確認情報量は、本人確認プロセスを単純化し、本人確認効率を改善し、ユーザ体験を向上させるために低減されてもよい(例えば、セキュリティ検証質問数が低減されてもよい)。
【００５９】
別の例では、本人確認ポリシーは、本人確認しきい値範囲を含み、本人確認ポリシー内のより大きい本人確認しきい値範囲は、ユーザが保持するデバイスのより高い信頼性により適用可能である。したがって、本人確認しきい値範囲は、デバイスの信用性と正の関係にあることが理解されよう。オプションで、ユーザが保持するデバイスが比較的低い信用性を有する場合、より厳密な本人確認がユーザに対して実行される必要がある。したがって、比較的小さい本人確認しきい値範囲が採用されてもよく、その範囲内に入る情報のないユーザの本人確認は、失敗する。ユーザが保持するデバイスが比較的高い信用性を有する場合、より穏当な本人確認がユーザに対して実行されてもよい。したがって、比較的大きい本人確認しきい値範囲が採用されてもよく、ユーザの本人確認情報は、その範囲内に入る可能性が高く、ユーザの本人確認の成功を容易にし、ユーザ体験を改善する。
【００６０】
シナリオにおいて、本人確認システムが本人確認情報として顔認識情報を使用すると仮定する。ユーザが保持するデバイスが比較的高い信頼性を有する場合、顔比較しきい値が適切に低減されてもよく、すなわち、本人確認が実行されるユーザの顔情報と本人確認システムにおいて受信された顔情報との間の一致度に対する要件が低減されてもよく、通常のサービス処理を実行するための不十分な光または不均一な証明などの貧弱な顔収集環境におけるユーザの本人確認の成功を容易にする。
【００６１】
オプションで、ユーザに対する本人確認を実行するための本人確認ポリシーが決定された後、本人確認ポリシーに従う本人確認中に、本人確認ポロセス、本人確認に必要な情報、および本人確認に必要な情報の本人確認しきい値範囲が、本人確認ポリシーに従って決定されてもよい。次いで、本人確認システムは、本人確認プロセスに従って、被検証デバイスに対して本人確認に必要な情報を報告するように促す。本人確認システムからプロンプトを受信した後、ユーザによって保持された被検証デバイスは、プロンプトに従って、本人確認に必要な情報を報告する。例えば、本人確認に必要な情報が被検証デバイスから受信されると、本人確認は、本人確認に必要な情報の本人確認しきい値範囲に従って実行される。
【００６２】
本出願のこの実施形態の主な実装プロセスについて、例を使用することによって上記で説明した。本出願のこの実施形態において、検証要求が被検証デバイスから受信された後、検証は、直接実行されないが、被検証デバイスの信用性は、履歴デバイスのデバイス環境情報と被検証デバイスのデバイス環境情報とに従って決定され、ユーザに対する本人確認を実行するための本人確認ポリシーは、信用性に従ってさらに決定される。本出願の実施形態における方法によれば、ユーザが意識することなく、現在のユーザが保持するデバイスに適用可能な本人確認ポリシーが、ユーザが保持するデバイスの信用性に従ってユーザに対して選択され得る。したがって、本出願の実施形態は、本人確認のセキュリティおよび信頼性の改善を容易にし、ユーザの使用要件を満たすことができ、ユーザ体験を改善することができる。
【００６３】
履歴特徴情報とデバイス環境情報とに従って被検証デバイスの信用性を判定するステップS103を実行するオプションの方法について、例を使用することによって以下にさらに説明する。例えば、図2を参照すると、以下のステップが実行されてもよい。
【００６４】
S1031:デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致する場合、デバイス環境情報に従って被検証デバイスに対応する特徴ベクトルを決定する。
【００６５】
本人確認システムは、異なるデバイスタイプに従って、信用性を判定するための予め設定された情報タイプを予め設定してもよいことが理解されよう。オプションで、予め設定された情報タイプは、デバイスの識別ID、デバイスが接続されているネットワーク上のIPアドレス、Wi-Fi、およびLBSを含んでもよい。通常ネットワークに接続されているデバイスについて、本人確認システムによって受信されたデバイス環境情報が欠落しており(この場合、デバイス環境情報内に含まれる情報のタイプは、予め設定された情報タイプと一致しない)、本人確認システムが、原因が客観的なネットワーク環境からくるのか、または、違法なユーザによって実行された主観的で意図的な妨害もしくは回避からくるのかを判定することができない場合、本人確認システムは、被検証デバイスが信用できない、すなわち、被検証デバイスの信用性が最も低いレベルであると直接判定してもよい。
【００６６】
デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致する場合、本人確認システムは、受信したデバイス環境情報を有効な情報として判定してもよい。したがって、被検証デバイスに対応する特徴ベクトルは、これに基づいて、デバイス環境情報に従って決定されてもよい。
【００６７】
特徴ベクトルは、複数の方法においてデバイス環境情報に従って決定されてもよい。オプションで、特徴ベクトルは、被検証デバイスのデバイス環境情報と履歴特徴情報とに従って決定されてもよい。
【００６８】
例えば、被検証デバイスのデバイス環境情報が履歴デバイスのデバイス環境情報と一致するかどうかが判定されてもよく、判定結果は、特徴ベクトルの1つまたは複数の成分として使用される。デバイス環境情報内に複数の特定のコンテンツが存在する場合、各特定のコンテンツは、個別に比較されてもよい。比較プロセスは、履歴デバイスのデバイス環境情報が被検証デバイスのデバイス環境情報を含むかどうかを判定することとして理解されてもよく、これは、被検証デバイスがサービスシステムに参加しているかどうか、または、被検証デバイスが接続されているネットワーク環境が他のデバイスを有するユーザによってアクセスされているかどうかを判定することと同等である。すべてのコンテツの比較結果が特徴ベクトル内の異なるサブアイテムとして使用されてもよく、または、比較結果が特徴ベクトル内のサブアイテムとしてまとめて使用されるように、予め設定されたルールを使用することによって比較結果がまとめられてもよいことに留意すべきである。例えば、予め設定されたルールは、複数のコンテンツの比較結果がすべて一致する場合、特徴ベクトル内の成分の値が1であり、複数のコンテンツのいずれかの比較結果が一致しない場合、特徴ベクトル内の成分の値が0であってもよい。
【００６９】
別の例では、被検証デバイスのデバイス環境情報が最大履歴接続時間を有するデバイス環境情報と一致するかどうかが判定されてもよく、判定結果は、特徴ベクトルの1つまたは複数の成分として使用される。さらに別の例では、被検証デバイスのデバイス環境情報は、履歴デバイスのデバイス環境情報の欠損値と比較されてもよく、特徴ベクトル内の1つまたは複数の成分が比較結果に従って決定されてもよい。具体的な比較および判定プロセス、ならびに、比較を通じて得られた判定結果に従って特徴ベクトル内の対応する成分を決定する方法は、前述の例におけるものと同様であり、詳細についてここでは改めて説明しない。
【００７０】
被検証デバイスに対応する特徴ベクトルを決定する際、ユーザが被検証デバイスを使用するときに存在するデバイス環境情報、および、ユーザによって過去に使用されたデバイスのデバイス環境情報が比較のために使用されることが理解されよう。多くの通常の場合、ユーザのデバイス環境情報は、通常、変化しない。ユーザが保持するデバイスが変更されておらず(この場合、デバイスの識別IDが変更されていない)、ネットワーク環境情報(例えば、LBS)が変更されている場合、ユーザが通常の検証要求を送信することが依然として可能である場合がある。しかしながら、デバイスが盗まれるというリスクが依然として存在する。しかしながら、ユーザが保持するデバイスが変更されており(この場合、デバイスの識別IDが変更されている)、ネットワーク環境情報が変更されていない場合、ユーザが変更されたデバイスを用いて本人確認要求を開始する可能性が非常に高い。ユーザに対応するデバイス環境情報(デバイスの識別情報とネットワーク環境情報とを含む)が履歴特徴情報と一致しない場合、被検証デバイスがサービスシステムにアクセスすることを許可することは、より高いリスクをもたらす。したがって、より高いリスクに一致するより厳密な本人確認ポリシーが、ユーザに対する本人確認を実行するために採用されてもよい。
【００７１】
S1033:特徴ベクトルをデバイス検証モデルに入力し、デバイス検証モデルを使用することによって被検証デバイスの信用性を判定する。デバイス検証モデルは、デバイス環境情報に基づいて、本人確認要求を送信するデバイスの信用性ラベルと、本人確認要求が信用できる要求として予測される確率とを決定するように構成される。
【００７２】
対応する特徴ベクトルが被検証デバイスのデバイス環境情報に従って生成された後、デバイス検証モデルは、被検証デバイスの信用性を判定するためにさらに使用されてもよい。デバイスの信用性は、被検証デバイスによって出力されたデバイスの信用性ラベルと、デバイスによって送信された本人確認要求が信用できる要求として予測される確率とにおいて具体化されてもよいことが理解されよう。被検証デバイスの信用性に従って本人確認ポリシーを決定することは、デバイスの信用性ラベルと、デバイスによって送信された本人確認要求が信用できる要求として予測される確率とに従って、信用性ラベルおよび/または本人確認要求が信用できる要求として予測される確率が入る信用性間隔を決定し、信用性間隔に対応する本人確認ポリシーを、保持されている被検証デバイスで本人確認を申し込んでいるユーザのための本人確認ポリシーとしてさらに決定するように具体化されてもよいことに留意すべきである。
【００７３】
オプションで、デバイス検証モデルは、機械学習アルゴリズムを使用することによって、オフラインで確立および訓練されてもよい。例えば、図3を参照すると、特徴ベクトルがデバイス検証モデルに入力され、デバイス検証モデルを使用することによって被検証デバイスの信用性が判定される前に、デバイス検証モデルの訓練および検証を完了するために、以下のステップが実行されてもよい。
【００７４】
S201:履歴デバイスに対応する履歴特徴情報を取得する。
【００７５】
図4を参照すると、ステップS201を実行することによって得られる履歴特徴情報は、履歴デバイスに対応するオフライン履歴特徴情報であってもよいことが理解されよう。履歴デバイスは、サービスシステムにログインした履歴ログインデバイス(履歴ログインデバイスによって生成された履歴特徴情報内の履歴ログイン情報)、または、本人確認を受け(成功した本人確認と失敗した本人確認とを含む)、サービスシステムにおいてサービス処理を実行する履歴本人確認デバイス(履歴本人確認デバイスによって生成された履歴特徴情報内の履歴本人確認情報)のいずれかであってもよい。
【００７６】
デバイス検証モデルの訓練中、異なるユーザに適したデバイス検証モデルが履歴特徴情報の異なるコンテンツに従って訓練されてもよいことに留意すべきである。初めてサービスシステムを使用するユーザについて、ユーザは、システムにログインするだけなので、履歴特徴情報は、履歴本人確認デバイスのデバイス環境情報なしに、履歴ログインデバイスのデバイス環境情報(略して履歴ログイン情報と呼ばれる場合がある)のみを含んでもよい。したがって、そのようなユーザに適したデバイス検証モデルについて、デバイス検証モデルの入力パラメータが、履歴特徴情報内の履歴ログイン情報のみを参照して決定される。本人確認を受けたユーザについて、ユーザは、本人確認操作を実行したので、またはサービスシステムにおいてサービス操作さえ実行したので、履歴特徴情報は、履歴ログイン情報と履歴本人確認情報の両方を含んでもよい。したがって、そのようなユーザに適したデバイス検証モデルについて、デバイス検証モデルの入力パラメータは、履歴ログイン情報と履歴コアボディ情報の両方を参照して決定されてもよい。
【００７７】
S203:履歴特徴情報に対応する時間間隔に従って、第1の履歴特徴情報を含む訓練セットと、第2の履歴特徴情報を含む検証セットとを決定する。
【００７８】
オプションで、履歴特徴情報に対応する時間間隔に従って、以前の時間に生成された第1の履歴特徴情報が訓練セットに割り当てられてもよく、以後の時間に生成された第2の履歴特徴情報が検証セットに割り当てられてもよい。検証セット内の履歴特徴情報は、以後の時間に生成されるので、履歴特徴情報は、ユーザの現在の適用要件をさらに満たす。したがって、以後の時間に生成された履歴特徴情報を検証セットに割り当てることは、デバイス検証モデルによって出力された検証結果が正しいかどうかのより正確な判定を可能にする。例えば、図4を参照すると、最近50日における本人確認/ログインの時において生成された履歴特徴情報が、デバイス検証モデルを訓練するために抽出されてもよい。最近10日において生成された履歴特徴情報が、検証セットを形成するために第2の履歴特徴情報として使用され、最近40日において生成された残りの履歴特徴情報が、訓練セットを形成するために第1の履歴特徴情報として使用される。
【００７９】
オプションで、履歴特徴情報は、ログイン/本人確認のためにユーザによって使用されるデバイスのID、Wi-Fi、LBS、およびIPなどのネットワーク環境情報を含む。履歴特徴情報は、ユーザによって開始された本人確認要求に対応する用途シナリオ、例えば、サービスシステムへのログイン、オンライン支払いの二次検証、または支払いパスワードの変更などをさらに反映してもよい。履歴特徴情報は、デバイスの信用性に従って決定される本人確認ポリシー内の対応する本人確認情報タイプ、例えば、顔検証、指紋検証、またはテキストメッセージ検証コード検証をさらに反映してもよい。履歴特徴情報は、ログイン/本人確認イベントに対応する検証結果をさらに反映してもよい。
【００８０】
S205:第1の履歴特徴情報を使用することによってデバイス検証モデルを訓練する。
【００８１】
オプションで、確立されたデバイス検証モデルは、ロジスティック回帰(LR)モデルと極度勾配ブースティングXGBoostモデルとを含んでもよい。第1の履歴特徴情報を使用することによるデバイス検証モデルの訓練は、一般に、第1段階LRモデル訓練と第2段階XGBoostモデル訓練の2つの部分を含む。XGBoostモデルの入力は、LRモデルの出力を含む。図4を参照すると、デバイス検証モデルの訓練プロセス全体は、順次実行される。
【００８２】
例えば、図4および図5を参照すると、デバイス検証モデルの訓練は、以下のステップを含んでもよい。
【００８３】
S2051:第1の履歴特徴情報に従って、第1の履歴特徴ベクトルと、第2の履歴特徴ベクトルと、第1の履歴特徴情報に対応する履歴デバイスの第1の信用性ラベルとを決定する。
【００８４】
オプションで、履歴特徴情報に対応するデバイスの信用性ラベルは、例えば、黒いサンプルおよび白いサンプルであってもよい。履歴ケースの状態、履歴本人確認要求が許可されたかまたは拒否されたか、または、本人確認が成功したときのサービスシステムおける不正な操作などに従って、信用性ラベルが黒いサンプルであるかまたは白いサンプルであるかが判定されてもよい。
【００８５】
例えば、履歴ケースの状態に従って、デバイスが、複数のケースまたは比較的多額のケースに関与する場合、デバイスの信用性ラベルが、黒いサンプルとしてマークされてもよい。デバイスに対応する履歴特徴情報に対応する本人確認要求も、信用できない要求としてマークされてもよい。本明細書におけるケースとは、不法ユーザが合法ユーザのアカウントに入るためにデバイスを使用し、合法ユーザのアカウント内の金銭を違法に取得することなどを意味する場合がある。
【００８６】
別の例では、履歴デバイスによって送信された履歴本人確認要求が複数回拒否された場合、デバイスが違法に使用されている可能性が高いことを示す。この場合、デバイスの信用性ラベルが黒いサンプルとしてマークされてもよく、デバイスに対応する履歴特徴情報に対応する本人確認要求も信用できない要求としてマークされてもよい。
【００８７】
別の例では、本人確認が成功したが、ユーザがデバイスを使用することによってサービスシステムにおいて違法な操作を実行した場合、デバイスの信用性ラベルが黒いサンプルとしてマークされてもよい。デバイスに対応する履歴特徴情報に対応する本人確認要求も信用できない要求としてマークされてもよい。
【００８８】
デバイスの信用性ラベルの定義およびそれを決定するための方法は、上記の例に限定されないことが理解されよう。具体的な用途要件に応じて、異なる意味が信用性ラベルに与えられる場合があり、信用性ラベルは、異なる方法を使用することによって決定されてもよい。本出願のこの実施形態において、これに制限は課されない。
【００８９】
オプションで、履歴特徴情報に基づいて特徴ベクトルを決定するために、デバイス検証モデルの訓練中、特徴ベクトルを取得するために、オフライン履歴特徴情報を使用することによって、オフライン統計が実行されてもよい。具体化には、特徴ベクトルの累積計算が、異なる時間ウィンドウと異なるユーザプリンシパル(ユーザ識別子を使用することによって区別され得る)に従って実行されてもよい。オプションで、履歴挙動が、時間窓、デバイス識別子、ユーザ識別情報、およびそれらの組合せなどの異なる観点において蓄積されてもよく、特徴ベクトル内の対応する成分が、蓄積された値に従って決定されてもよい。代替的には、履歴特徴情報の部分ごとに、現在のデバイス環境情報が複数回の過去の成功したログインおよび/または成功した本人確認でデバイス環境情報と一致するかどうかにかかわらず、現在のデバイス環境情報が履歴デバイスの環境情報と一致するかどうかが判定され、特徴ベクトル内の対応する成分は、判定結果に従って決定される。特徴ベクトル内の対応する成分はまた、現在のデバイス環境情報および履歴環境情報の欠損値の比較結果、ならびに、予め設定された最近の日数におけるデバイス環境情報の変化などの、いくつかの要因に従って決定されてもよい。
【００９０】
オプションで、履歴特徴情報に基づいて特徴ベクトルを決定するために、デバイス検証モデルの使用段階中、デバイス検証モデルの出力をリアルタイムで監視してデバイス検証モデルを評価するために、特徴ベクトルを取得するためにリアルタイムデバイス環境情報を使用することによってオンラインリアルタイム統計が決定されてもよい。デバイス検証モデルの評価データが予め設定された条件を満たさない場合、デバイス検証モデルは、更新されてもよく、すなわち、更新された履歴特徴情報が、デバイス検証モデルを再訓練するために訓練セットおよび検証セットとして使用される。
【００９１】
特徴ベクトル内のいくつかの成分は、本人確認システムおよびサービスシステムの実際の要件に従って決定されてもよいことに留意すべきである。オプションで、ロジスティック回帰LRモデルに入力される第1の履歴特徴ベクトル内のいくつかの成分は、極度勾配ブースティングXGBoostモデルに入力される第2の履歴特徴ベクトル内のいくつかの成分よりも大きくてもよい。例えば、履歴特徴情報から抽出された第1の履歴特徴ベクトルは、ロジスティック回帰LRモデルに入力される約300成分を有してもよい。履歴特徴情報から抽出された第2の履歴特徴ベクトルについて、特徴ベクトル内の成分の重みが考慮されてもよく、300よりも多い成分から30よりも多い成分が第2の履歴特徴ベクトルの成分として選択され得るように、黒いサンプルと白いサンプルとを区別するために使用され得る特徴が履歴体験に基づいてさらに決定されてもよい。
【００９２】
初めてサービスシステムを使用するユーザに適用可能なデバイス検証モデルについて、訓練中に使用される履歴特徴情報は、履歴本人確認デバイスのデバイス環境情報(略して履歴本人確認情報と呼ばれる場合もある)なしに、履歴ログインデバイスのデバイス環境情報(略して履歴ログイン情報と呼ばれる場合もある)のみを含むことにさらに留意すべきである。相応して、モデルに入力される特徴ベクトルも、履歴本人確認情報を反映する成分なしに、履歴ログイン情報を反映する成分のみを含む。
【００９３】
本人確認を受けたユーザに適用可能なデバイス検証モデルについて、訓練中に使用される履歴特徴情報は、履歴ログイン情報と履歴本人確認情報の両方を含む。したがって、モデルに入力される特徴ベクトルは、履歴ログイン情報を反映する成分と、履歴本人確認情報を反映する成分の両方を含む。
【００９４】
S2053:第1の履歴特徴ベクトルをロジスティック回帰LRモデルに入力し、ロジスティック回帰LRモデルの出力が予め設定された条件を満たすまで、第1の信用性ラベルと、ロジスティック回帰LRモデルによって出力された第1のターゲットラベルとに従って、ロジスティック回帰LRモデルのモデルパラメータを調整する。
【００９５】
オプションで、ロジスティック回帰LRモデルの出力が予め設定された条件を満たすまで、ロジスティック回帰LRモデルの訓練中、正則化項、正則化係数、および最大繰り返し回数などのモデルパラメータのうちの1つまたは複数が調整されてもよい。
【００９６】
第1の履歴特徴ベクトルは、LRモデルに入力され、LRモデルは、第1のターゲットラベルを出力することが理解されよう。第1のターゲットラベルは、ロジスティック回帰LRモデルによって予測された、生成された第1の履歴特徴ベクトル内の履歴特徴情報に対応するデバイスの信用性ラベルである。較正された第1の信用性ラベルに基づいて、ロジスティック回帰LRモデルによって出力された第1のターゲットラベルが正しく正確であるかどうかが判定されてもよく、次いで、ロジスティック回帰LRモデルのモデルパラメータは、ロジスティック回帰LRモデルが十分に正確なターゲットラベルを出力することができるように、判定結果に従って調整される。加えて、最適なロジスティック回帰LRモデルが、正則化項、最大繰り返し回数、および正則化係数などのモデルパラメータを調整することによって得られる。
【００９７】
S2055:訓練されたロジスティック回帰LRモデルの出力に従って、第1の履歴特徴情報に対応するデバイスによって送信された本人確認要求が信用できる要求であるとして予測される第1の確率を計算する。
【００９８】
ロジスティック回帰LRモデルの訓練が完了した後、本人確認要求が白いサンプルとして予測される確率(すなわち、第1の確率)が、ロジスティック回帰LRモデルの出力に従って計算されてもよく、この確率は、極度勾配ブースティングXGBoostモデルを訓練するための極度勾配ブースティングXGBoostモデルの入力パラメータの1つとして使用され、それは、図4に示されている。
【００９９】
S2057:第1の確率と第2の履歴特徴ベクトルとを極度勾配ブースティングXGBoostモデルに入力し、極度勾配ブースティングXGBoostモデルの出力が予め設定された条件を満たすまで、極度勾配ブースティングXGBoostモデルの出力と第1の信用性ラベルとを使用することによって極度勾配ブースティングXGBoostモデルのモデルパラメータを調整する。極度勾配ブースティングXGBoostモデルの出力は、第1の履歴特徴情報に対応する履歴デバイスの信用性ラベルと、履歴デバイスによって送信された本人確認要求が信用できる要求として予測される確率とを含む。
【０１００】
オプションで、極度勾配ブースティングXGBoostのパラメータ調整は、いくつかのツリーおよびステップサイズなどのパラメータの調整を主に含む。
【０１０１】
極度勾配ブースティングXGBoostモデルの出力、すなわち、第1の履歴特徴情報に対応する履歴デバイスの信用性ラベルと、履歴デバイスによって送信された本人確認要求が信用できる要求として予測される確率とを取得するために、ロジスティック回帰LRモデルの出力に従って計算される第1の確率は、極度勾配ブースティングXGBoostモデルの入力パラメータの1つとして使用され、第2の履歴特徴ベクトルは、極度勾配ブースティングXGBoostモデルの残りの入力パラメータとして使用されることが理解されよう。極度勾配ブースティングXGBoostモデルによって出力される信用性ラベルは、極度勾配ブースティングXGBoostモデルによって出力された信用性ラベルが正しく正確であるかどうかが判定され得るように、較正された第1の信用性ラベルと比較され、次いで、極度勾配ブースティングXGBoostモデルのモデルパラメータは、極度勾配ブースティングXGBoostモデルが十分に正しい信用性ラベルを出力することができるように調整される。加えて、ツリーの数およびステップサイズが、最適な極度勾配ブースティングXGBoostモデルを取得するために調整される。
【０１０２】
S207:第2の履歴特徴情報を使用することによってデバイス検証モデルを検証する。
【０１０３】
デバイス検証モデルの検証は、デバイス検証モデルの出力の精度が適用要件を満たすことができるかどうかを判定するために、デバイス検証モデルの訓練が完了した直後に実行されてもよいことが理解されよう。デバイス検証モデルがある期間中に使用された後、デバイス検証モデルの出力が十分に正確ではなく、適用要件を満たすことができない場合、デバイス検証モデルが、適用要件を満たすように、更新された履歴特徴情報を使用することによって再訓練されるように、デバイス検証モデルの出力効果は、定期的または不定期に検証されてもよいことに留意すべきである。
【０１０４】
オプションで、図6を参照すると、デバイス検証モデルの検証中、以下の方法が使用されてもよい。
【０１０５】
S2071:第2の履歴特徴情報に従って、第3の履歴特徴ベクトルと、第4の履歴特徴ベクトルと、第2の履歴特徴情報に対応する履歴デバイスの第2の信用性ラベルとを決定する。
【０１０６】
S2073:第3の履歴特徴ベクトルを訓練されたロジスティック回帰LRモデルに入力し、訓練されたロジスティック回帰LRモデルの出力に従って、第2の履歴特徴情報に対応するデバイスによって送信された本人確認要求が信用できる要求として予測される第2の確率を計算する。
【０１０７】
S2075:第2の確率および第4の履歴特徴ベクトルを訓練された極度勾配ブースティングXGBoostモデルに入力し、訓練された極度勾配ブースティングXGBoostモデルを使用することによってデバイス検証モデルの出力を取得する。デバイス検証モデルの出力は、第2の履歴特徴情報に対応する履歴デバイスの信用性ラベルと、履歴デバイスによって送信された本人確認要求が信用できる要求として予測される第3の確率とを含む。
【０１０８】
S2077:デバイス検証モデルの出力と第2の信用性ラベルとに従ってバイナリ分類法を使用することによってデバイス検証モデルの評価データを取得する。
【０１０９】
S2079:デバイス検証モデルの評価データが予め設定された条件を満たすまで、評価データに従って、ロジスティック回帰LRモデルのモデルパラメータおよび/または極度勾配ブースティングXGBoostモデルのモデルパラメータを調整する。
【０１１０】
検証セット内の第2の履歴特徴情報がデバイス検証モデルの入力として使用されることが理解されよう。デバイス検証モデルにおいて直列にロジスティック回帰LRモデルおよび極度勾配ブースティングXGBoostモデルによって実行された処理の後、第2の履歴特徴情報に対応する履歴デバイスの信用性ラベルと、履歴情報によって送信された本人確認要求が信用できる要求として予測される第3の確率とが出力される。次いで、デバイス検証モデルの評価データは、較正された第2の信用性ラベルに従ってバイナリ分類法を使用することによって取得されてもよい。
【０１１１】
オプションで、デバイス検証モデルの評価データは、F1スコアおよび曲線下面積(AUC)値のうちの少なくとも1つを含んでもよい。例えば、F1スコアは、モデルの精度および再現率を総合的に考慮するパラメータインデックスである。より高いF1は、より堅牢な分類モデル(本明細書では、具体的にはデバイス検証モデルである)を示す。曲線下面積AUC値は、分類モジュールによって出力される所与の正サンプルが正である確率が、分類モデルによって出力される負サンプルが正である確率よりも高い可能性である。F1スコアおよび曲線下面積AUC値は、モデルの訓練を審査するために使用される。モデルによって信用性を予測する効果は、モデルの評価データを使用することによって評価され、ロジスティック回帰LRモデルのモデルパラメータおよび/または極度勾配ブースティングXGBoostモデルのモデルパラメータは、ロジスティック回帰LRモデルと極度勾配ブースティングXGBoostモデルの最適なモデル組合せを得るように連続的に調整される。
【０１１２】
実際の用途において、デバイス検証モデルの評価データについて、モデルの数学的パラメータに加えて、黒いサンプルの誤判断率および白いサンプルの正解率が、モデルの実際の用途シナリオに関してさらに考慮されてもよいことに留意すべきである。黒いサンプルが白いサンプルとして判定された場合、不正ユーザの本人確認が成功し、サービスシステムのセキュリティを脅かす。白いサンプルが黒いサンプルとして判定された場合、サービスシステムのセキュリティは、正当なユーザに対する厳密な本人確認のために影響を受けないが、ユーザ体験は、影響を受ける。したがって、デバイス検証モデルの判断精度および誤判断率も考慮される必要がある。正解率および誤判断率が増加すると、モデル更新がトリガされ、すなわち、デバイス検証モデルは、更新された履歴特徴情報を使用することによって再訓練される。
【０１１３】
本出願の実施形態において、検証要求が被検証デバイスから受信された後、検証は、直接実行されないが、被検証デバイスの信用性は、履歴デバイスのデバイス環境情報と被検証デバイスのデバイス環境情報とに従って決定され、ユーザに対する本人確認を実行するための本人確認ポリシーは、信用性に従ってさらに決定される。本出願の実施形態における方法によれば、ユーザが意識することなく、現在のユーザが保持するデバイスに適用可能な本人確認ポリシーが、ユーザが保持するデバイスの信用性に従ってユーザに対して選択され得る。したがって、本出願の実施形態は、本人確認のセキュリティおよび信頼性における改善を容易にし、ユーザの使用要件を満たすことができ、ユーザ体験を改善することができる。
【０１１４】
本出願の実施形態は、本人確認システムに適用される本人確認装置をさらに提供する。図7を参照すると、本人確認装置は、
被検証デバイスから本人確認要求を受信するように構成された要求受信モジュール101であって、本人確認要求が、被確認デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される、要求受信モジュール101と、
履歴特徴情報とデバイス環境情報とに従って被検証デバイスの信用性を判定するように構成された信用性判定モジュール103であって、履歴特徴情報が履歴デバイスのデバイス環境情報を含む、信用性判定モジュール103と、
本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定するように構成された本人確認ポリシー決定モジュール105とを含んでもよい。
【０１１５】
図7に示す本人確認装置は、前述の実施形態において提供されている本人確認システムによって実行される本人確認方法に対応し、前述の実施形態における本人確認方法を実施することができることが理解されよう。詳細について、ここでは再び説明しない。
【０１１６】
図8は、本出願の実施形態による電子デバイスの構造概略図である。図8を参照すると、ハードウェアレベルにおいて、電子デバイスは、プロセッサを含み、内部バスと、ネットワークインターフェースと、メモリとをオプションで含み、メモリは、ランダムアクセスメモリ(RAM)などの内部メモリを含んでもよく、または、少なくとも1つの磁気ディスクメモリなどの不揮発性メモリをさらに含んでもよい。確かに、電子デバイスは、サービスによって必要とされる他のハードウェアをさらに含んでもよい。
【０１１７】
プロセッサ、ネットワークインターフェース、およびメモリは、内部バスを介して相互に接続されてもよく、内部バスは、業界標準アーキテクチャ(ISA)バス、周辺構成要素相互接続(PCI)バス、または拡張業界標準アーキテクチャ(EISA)バスであってもよい。バスは、アドレスバス、データバス、および制御バスに分割されてもよい。表現の容易さのために、図8においてバスを表すために1本の太線のみが使用されているが、これは、1つのみのバスまたは1つのタイプのみのバスが存在することを意味しない。
【０１１８】
メモリは、プログラムを記憶するように構成される。例えば、プログラムは、プログラムコードを含んでもよく、プログラムコードは、コンピュータ実行可能命令を含む。メモリは、内部メモリと不揮発性メモリとを含んでもよく、命令とデータとをプロセッサに提供してもよい。
【０１１９】
プロセッサは、不揮発性記憶装置から対応するコンピュータプログラムを内部メモリに読み取り、次いで、本人確認装置を形成するためにコンピュータプログラムを実行する。プロセッサは、メモリ内に記憶されたプログラムを実行し、以下の動作、
被検証デバイスから本人確認要求を受信する動作であって、本人確認要求が、被確認デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される、動作と、
履歴特徴情報とデバイス環境情報とに従って被検証デバイスの信用性を判定する動作であって、履歴特徴情報が履歴デバイスのデバイス環境情報を含む、動作と、
本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定する動作と、を実行するために使用される。
【０１２０】
本出願の図1に示す実施形態において開示される本人確認装置によって実行される前述の方法は、プロセッサに適用されてもよく、またはプロセッサによって実施されてもよい。プロセッサは、集積回路チップであってもよく、信号処理能力を有する。実施プロセスにおいて、前述の方法のステップは、プロセッサ内のハードウェア集積論理回路、またはソフトウェアの形態における命令を使用することによって実施されてもよい。プロセッサは、中央処理装置(Central Processing Unit、CPU)、ネットワークプロセッサ(Network Processor、NP)などを含む汎用プロセッサであってもよく、または、さらに、デジタル信号プロセッサ(Digital Signal Processing、DSP)、特定用途向け集積回路(Application-Specific Integrated Circuit、ASIC)、フィールドプログラマブルゲートアレイ(Field-Programmable Gate Array、FPGA)、もしくは別のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理デバイス、もしくは個別ハードウェア構成要素などであってもよい。プロセッサは、本出願の実施形態において開示される方法、ステップ、および論理ブロック図を実装または実行してもよい。汎用プロセッサは、マイクロプロセッサであってもよく、または、プロセッサは、さらに、任意の従来のプロセッサなどであってもよい。本出願の実施形態を参照して開示される方法のステップは、ハードウェア復号プロセッサを使用することによって直接実行および完了されてもよく、または、復号プロセッサ内のハードウェアおよびソフトウェアモジュールの組合せを使用することによって実行および完了されてもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、読み取り専用メモリ、プログラム可能読み取り専用メモリ、電気的消去可能プログラム可能メモリ、またはレジスタなどの、当該分野における成熟した記憶媒体内に配置されてもよい。記憶媒体は、メモリ内に配置され、プロセッサは、メモリ内の情報を読み取り、プロセッサのハードウェアと組み合わせて前述の方法におけるステップを完了する。
【０１２１】
電子デバイスは、図1における本人確認装置によって実行される方法をさらに実行してもよく、図1の実施形態に示す本人確認装置の機能を実装してもよい。これは、本出願の実施形態においてここでは繰り返されない。
【０１２２】
本出願の実施形態は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、1つまたは複数のプログラムを記憶し、1つまたは複数のプログラムは、命令を含み、複数のアプリケーションを含む電子デバイスによって命令が実行されると、電子デバイスは、図1に示す実施形態における本人確認装置によって実行される方法を実行することが可能であり、具体的には、以下のステップ、
被検証デバイスから本人確認要求を受信するステップであって、本人確認要求が、被確認デバイスのデバイス環境情報を含み、被検証デバイスに対応するユーザの本人確認を要求するために使用される、ステップと、
履歴特徴情報とデバイス環境情報とに従って被検証デバイスの信用性を判定するステップであって、履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ステップと、
本人確認ポリシーに従って本人確認を実行するために、被検証デバイスの信用性に従って、ユーザに対する本人確認を実行するための本人確認ポリシーを決定するステップと、を実行するように構成される。
【０１２３】
当業者は、本出願の実施形態が、方法、システム、またはコンピュータプログラム製品として提供されてもよいことを理解すべきである。したがって、本出願は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアの組合せを有する実施形態の形態を使用してもよい。さらに、本出願は、コンピュータ使用可能プログラムコードを含む1つまたは複数のコンピュータ使用可能記憶媒体(限定はしないが、ディスクメモリ、CD-ROM、光学メモリなどを含む)上に実装されたコンピュータプログラム製品の形態を使用してもよい。
【０１２４】
本発明について、本出願の実施形態による方法、デバイス(システム)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して説明する。コンピュータプログラム命令が、フローチャートおよび/またはブロック図内の各プロセスおよび/または各ブロック、ならびに、フローチャートおよび/またはブロック図内のプロセスおよび/またはブロックの組合せを実装するために使用されてもよいことを理解すべきである。これらのコンピュータプログラム命令は、コンピュータ、または、任意の他のプログラム可能データ処理デバイスによって実行される命令がフローチャート内の1つもしくは複数の処理および/またはブロック図内の1つもしくは複数のブロックにおける特定の機能を実装するための装置を生成するように、マシンを生成するために、汎用コンピュータ、専用コンピュータ、組込みコンピュータ、または任意の他のプログラム可能データ処理デバイスのプロセッサに提供されてもよい。
【０１２５】
これらのコンピュータプログラム命令は、コンピュータ可読メモリ内に記憶された命令が命令装置を含む製品を生成するように、特定の方法で機能するようにコンピュータまたは別のプログラム可能データ処理デバイスを導くことができ、命令装置は、フローチャート内の1つもしくは複数の手順および/またはブロック図内の1つもしくは複数のブロックにおいて指定された機能を実装する。
【０１２６】
これらのコンピュータプログラム命令はまた、コンピュータによって実施される処理を生成するために一連の動作ステップがコンピュータまたは別のプログラム可能データ処理デバイス上で実行され、コンピュータまたは別のプログラム可能データ処理デバイス上で実行される命令がフローチャート内の1つもしくは複数の手順および/またはブロック図内の1つもしくは複数のブロックにおいて指定された機能を実行するためのステップを提供するように、コンピュータまたは別のプログラム可能データ処理デバイスにロードされてもよい。
【０１２７】
典型的な構成において、コンピュータデバイスは、1つまたは複数のプロセッサ(CPU)と、入力/出力インターフェースと、ネットワークインターフェースと、内部メモリとを含む。
【０１２８】
内部メモリは、揮発性メモリ、ランダムアクセスメモリ(RAM)、および/または、コンピュータ可読媒体内の不揮発性メモリ、例えば、読み取り専用メモリ(ROM)もしくはフラッシュメモリ(フラッシュRAM)、などの形態を含んでもよい。内部メモリは、コンピュータ可読媒体の一例である。
【０１２９】
コンピュータ可読媒体は、任意の方法または技術を使用することによって情報記憶を実施し得る、永続的、非永続的、可動、および不動の媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであってもよい。コンピュータ記憶媒体の例は、限定はしないが、相変化メモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、別のタイプのRAM、ROM、電気的消去可能プログラム可能読み取り専用メモリ(EEPROM)、フラッシュメモリ、もしくは別のメモリ技術、CD-ROM、デジタル多用途ディスク(DVD)、もしくは別の光メモリ、カセット、磁気テープ、磁気ディスクメモリ、もしくは別の磁気記憶デバイス、または任意の他の非伝送媒体を含み、コンピューティングデバイスによってアクセス可能な情報を記憶するために使用されてもよい。本開示における定義に基づいて、コンピュータ可読媒体は、変調データ信号および搬送波などの、一時的コンピュータ可読媒体(一時的媒体)を含まない。
【０１３０】
「含む」、「備える」、および任意の他の変形の用語は、非排他的な包括をカバーすることを意味することにも留意すべきである。それによって、一連の要素を含むプロセス、方法、物品、またはデバイスは、それらの要素を含むだけでなく、明確にリストされていない他の要素も含み、または、プロセス、方法、物品、およびデバイスの固有の要素も含む。特に明記しない限り、「1つの...を含む」によって限定された要素は、その要素を含むプロセス、方法、物品、またはデバイスにおいて存在する他の同じ要素を除外しない。
【０１３１】
当業者は、本出願の実施形態が、方法、システム、またはコンピュータプログラム製品として提供されてもよいことを理解すべきである。したがって、本出願は、総ハードウェアの実施形態、総ソフトウェアの実施形態、またはソフトウェアとハードウェアを組み合わせた実施形態の形態を使用する場合がある。加えて、本出願は、コンピュータ使用可能プログラムコードを含む、1つまたは複数のコンピュータ使用可能記憶媒体(限定はしないが、ディスクメモリ、CD-ROM、光メモリなどを含む)上に実装されたコンピュータプログラム製品の形態を使用する場合がある。
【０１３２】
前述の説明は、本出願の単なる実施形態であり、本出願を限定することを意図していない。当業者にとって、様々な修正および変更が本出願に対してなされ得る。本出願の趣旨および原理の範囲内でなされた任意の修正、同等の置換、改善などは、本出願の保護範囲内に入るべきである。
【符号の説明】
【０１３３】
101  要求受信モジュール
103  信用性判定モジュール
105  本人確認ポリシー決定モジュール
【図１】
2021508889.tif 000003
【図２】
2021508889.tif 000004
【図３】
2021508889.tif 000005
【図４】
2021508889.tif 000006
【図５】
2021508889.tif 000007
【図６】
2021508889.tif 000008
【図７】
2021508889.tif 000009
【図８】
2021508889.tif 000010
【手続補正書】
【提出日】令和2年8月28日(2020.8.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
本人検証方法であって、
被検証デバイスから本人検証要求を受信するステップであって、前記本人検証要求が、前記被検証デバイスのデバイス環境情報を含み、前記被検証デバイスに対応するユーザの本人検証を要求するために使用される、ステップと、
履歴特徴情報と前記デバイス環境情報とに従って、
前記デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致する場合、前記デバイス環境情報に従って前記被検証デバイスに対応する特徴ベクトルを決定するステップと、
前記特徴ベクトルをデバイス検証モデルに入力するステップと、
前記デバイス検証モデルを使用することによって前記被検証デバイスの信用性を判定するステップであって、前記デバイス検証モデルが、前記デバイス環境情報に基づいて、前記本人検証要求を送信するデバイスの信用性ラベルと、前記本人検証要求が信用できる要求として予測される確率とを決定するように構成される、ステップと、によって、前記被検証デバイスの信用性を判定するステップであって、前記履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ステップと、
本人検証ポリシーに従って本人検証を実行するために、前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人検証を実行するための前記本人検証ポリシーを決定するステップとを含む、
方法。
【請求項２】
前記特徴ベクトルをデバイス検証モデルに入力し、前記デバイス検証モデルを使用することによって前記被検証デバイスの前記信用性を判定するステップの前に、前記方法が、
前記履歴デバイスに対応する履歴特徴情報を取得するステップと、
前記履歴特徴情報に対応する時間間隔に従って、第1の履歴特徴情報を含む訓練セットと、第2の履歴特徴情報を含む検証セットとを決定するステップと、
前記第1の履歴特徴情報を使用することによって前記デバイス検証モデルを訓練し、前記第2の履歴特徴情報を使用することによって前記デバイス検証モデルを検証するステップとをさらに含む、
請求項１に記載の方法。
【請求項３】
前記履歴特徴情報に対応する時間間隔に従って、第1の履歴特徴情報を含む訓練セットと、第2の履歴特徴情報を含む検証セットとを決定するステップが、
前記履歴特徴情報に対応する前記時間間隔に従って、以前の時間に生成された第1の履歴特徴情報を前記訓練セットに割り当て、以後の時間に生成された第2の履歴特徴情報を前記検証セットに割り当てるステップをさらに含む、
請求項２に記載の方法。
【請求項４】
前記デバイス検証モデルが、LR(ロジスティック回帰)モデルとXGBoost(極度勾配ブースティング)モデルとを備え、前記第1の履歴特徴情報を使用することによって前記デバイス検証モデルを訓練するステップが、
前記第1の履歴特徴情報に従って、第1の履歴特徴ベクトルと、第2の履歴特徴ベクトルと、前記第1の履歴特徴情報に対応する履歴デバイスの第1の信用性ラベルとを決定するステップと、
前記第1の履歴特徴ベクトルをLRモデルに入力するステップと、
ロジスティック回帰LRモデルの出力が予め設定された条件を満たすまで、前記第1の信用性ラベルと、前記LRモデルによって出力された第1のターゲットラベルとに従って、前記LRモデルのモデルパラメータを調整するステップと、
前記訓練されたLRモデルの出力に従って、前記第1の履歴特徴情報に対応する前記デバイスによって送信された本人検証要求が信用できる要求として予測される第1の確率を計算するステップと、
前記第1の確率と前記第2の履歴特徴ベクトルとをXGBoostモデルに入力するステップと、
前記XGBoostモデルの出力が予め設定された条件を満たすまで、前記XGBoostモデルの前記出力と前記第1の信用性ラベルとに基づいて、前記XGBoostモデルのモデルパラメータを調整するステップであって、前記XGBoostモデルの前記出力が、前記第1の履歴特徴情報に対応する前記履歴デバイスの前記第1の信用性ラベルと、前記履歴デバイスによって送信された本人検証要求が信用できる要求であるとして予測される確率とを含む、ステップとを含む、
請求項２に記載の方法。
【請求項５】
前記第2の履歴特徴情報を使用することによって前記デバイス検証モデルを検証するステップが、
前記第2の履歴特徴情報に従って、第3の履歴特徴ベクトルと、第4の履歴特徴ベクトルと、前記第2の履歴特徴情報に対応する履歴デバイスの第2の信用性ラベルとを決定するステップと、
前記第3の履歴特徴ベクトルを前記訓練されたLRモデルに入力するステップと、
前記訓練されたLRモデルの出力に従って、前記第2の履歴特徴情報に対応する前記デバイスによって送信された本人検証要求が信用できる要求として予測される第2の確率を計算するステップと、
前記第2の確率と前記第4の履歴特徴ベクトルとを前記訓練されたXGBoostモデルに入力し、前記訓練されたXGBoostモデルを使用することによって前記デバイス検証モデルの出力を取得するステップであって、前記デバイス検証モデルの前記出力が、前記第2の履歴特徴情報に対応する前記履歴デバイスの前記第2の信用性ラベルと、前記履歴デバイスによって送信された本人検証要求が信用できる要求として予測される第3の確率とを含む、ステップと、
前記デバイス検証モデルの前記出力と前記第2の信用性ラベルとに従ってバイナリ分類方法を使用することによって前記デバイス検証モデルの評価データを取得するステップと、
前記デバイス検証モデルの前記評価データが予め設定された条件を満たすまで、前記評価データに従って前記LRモデルの前記モデルパラメータおよび/または前記XGBoostモデルの前記モデルパラメータを調整するステップとを含む、
請求項４に記載の方法。
【請求項６】
前記デバイス検証モデルの前記評価データが、F1スコアおよびAUC(曲線下面積)値のうちの少なくとも1つを含む、
請求項５に記載の方法。
【請求項７】
前記LRモデルの前記モデルパラメータが、正則化項、正則化係数、および最大反復数のうちの少なくとも1つを含む、
請求項４から６のいずれか一項に記載の方法。
【請求項８】
前記第1の履歴特徴ベクトルの成分の数が、前記第2の履歴特徴ベクトルの成分の数よりも多い、
請求項４から６のいずれか一項に記載の方法。
【請求項９】
前記履歴デバイスが、履歴ログインデバイスおよび履歴本人検証デバイスのうちの少なくとも1つを含む、
請求項1および２から６のいずれか一項に記載の方法。
【請求項１０】
履歴特徴情報と前記デバイス環境情報とに従って、前記被検証デバイスの信用性を判定するステップが、
前記デバイス環境情報内に含まれる前記情報の前記タイプが前記予め設定された情報タイプと一致しない場合、前記被検証デバイスが信用できないと判定するステップを含む、
請求項1および２から６のいずれか一項に記載の方法。
【請求項１１】
前記予め設定された情報タイプが、デバイスの識別ID、ならびに、前記デバイスに対応するWi-Fi接続、LBS(位置ベースのサービス)、およびIP(インターネットプロトコル)アドレスのうちの少なくとも1つを含む、
請求項１０に記載の方法。
【請求項１２】
前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人検証を実行するための本人検証ポリシーを決定するステップが、
前記被検証デバイスの前記信用性と、前記本人検証ポリシーと信用性間隔との間の対応関係とに従って、前記ユーザに対する本人検証を実行するための前記本人検証ポリシーを決定するステップを含み、
前記本人検証ポリシーに一致するリスクレベルが、ユーザが保持するデバイスの信用性と負の関係にある、
請求項1および２から６のいずれか一項に記載の方法。
【請求項１３】
前記本人検証ポリシーは、本人検証情報タイプ、本人検証情報量、および本人検証しきい値範囲のうちの少なくとも1つを含み、
前記本人検証ポリシーに一致する前記リスクレベルが、前記ユーザが保持するデバイスの前記信用性と負の関係にあることが、
前記本人検証ポリシーが前記本人検証情報タイプを含む場合、前記本人検証ポリシー内の前記本人検証情報タイプのセキュリティレベルが、前記ユーザが保持するデバイスの前記信用性と負の関係にあること、
前記本人検証ポリシーが前記本人検証情報量を含む場合、前記本人検証ポリシー内の前記本人検証情報量が、前記ユーザが保持するデバイスの前記信用性と負の関係にあること、および、
前記本人検証ポリシーが前記本人検証しきい値範囲を含む場合、前記本人検証ポリシー内の前記本人検証しきい値範囲が、前記ユーザが保持するデバイスの信用性と正の関係にあること、のうちの少なくとも1つを含む、
請求項１２に記載の方法。
【請求項１４】
前記本人検証ポリシーに従って前記本人検証を実行するステップが、
前記本人検証ポリシーに従って、本人検証プロセスと、前記本人検証に必要な情報と、前記本人検証に必要な前記情報の本人検証しきい値範囲とを決定するステップと、
前記本人検証プロセスに従って、前記被検証デバイスに対して前記本人検証に必要な前記情報を報告するように促すステップと、
前記被検証デバイスから前記本人検証に必要な前記情報を受信すると、前記本人検証に必要な前記情報の前記本人検証しきい値範囲に従って前記本人検証を実行するステップとを含む、
請求項１に記載の方法。
【請求項１５】
被検証デバイスから本人検証要求を受信するように構成された要求受信モジュールであって、前記本人検証要求が、前記被検証デバイスのデバイス環境情報を含み、前記被検証デバイスに対応するユーザの本人検証を要求するために使用される、要求受信モジュールと、
履歴特徴情報と前記デバイス環境情報とに従って、
前記デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致する場合、前記デバイス環境情報に従って前記被検証デバイスに対応する特徴ベクトルを決定することと、
前記特徴ベクトルをデバイス検証モデルに入力することと、
前記デバイス検証モデルを使用することによって前記被検証デバイスの信用性を判定することであって、前記デバイス検証モデルが、前記デバイス環境情報に基づいて、前記本人検証要求を送信するデバイスの信用性ラベルと、前記本人検証要求が信用できる要求として予測される確率とを決定するように構成される、こととによって、
前記被検証デバイスの信用性を判定するように構成された信用性判定モジュールであって、前記履歴特徴情報が、履歴デバイスのデバイス環境情報を含む、信用性判定モジュールと、
本人検証ポリシーに従って本人検証を実行するために、前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人検証を実行するための前記本人検証ポリシーを決定するように構成された本人検証ポリシー決定モジュールとを備える、
本人検証装置。
【請求項１６】
プロセッサと、
実行されると、前記プロセッサに以下の動作を実行させるコンピュータ実行可能命令を記憶するように構成されたメモリとを備えた、
電子デバイスであって、前記動作が、
被検証デバイスから本人検証要求を受信することであって、前記本人検証要求が、前記被検証デバイスのデバイス環境情報を含み、前記被検証デバイスに対応するユーザの本人検証を要求するために使用される、ことと、
履歴特徴情報と前記デバイス環境情報とに従って、
前記デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致する場合、前記デバイス環境情報に従って前記被検証デバイスに対応する特徴ベクトルを決定することと、
前記特徴ベクトルをデバイス検証モデルに入力することと、
前記デバイス検証モデルを使用することによって前記被検証デバイスの信用性を判定することであって、前記デバイス検証モデルが、前記デバイス環境情報に基づいて、前記本人検証要求を送信するデバイスの信用性ラベルと、前記本人検証要求が信用できる要求として予測される確率とを決定するように構成される、ことと、
によって、前記被検証デバイスの信用性を判定することであって、前記履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ことと、
本人検証ポリシーに従って本人検証を実行するために、前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人検証を実行するための前記本人検証ポリシーを決定することとを含む、
電子デバイス。
【請求項１７】
複数のアプリケーションを含む電子デバイスによって実行されると、前記電子デバイスに以下の動作を実行させる1つまたは複数のプログラムを記憶するコンピュータ可読記憶媒体であって、前記動作が、
被検証デバイスから本人検証要求を受信することであって、前記本人検証要求が、前記被検証デバイスのデバイス環境情報を含み、前記被検証デバイスに対応するユーザの本人検証を要求するために使用される、ことと、
履歴特徴情報と前記デバイス環境情報とに従って、
前記デバイス環境情報内に含まれる情報のタイプが予め設定された情報タイプと一致する場合、前記デバイス環境情報に従って前記被検証デバイスに対応する特徴ベクトルを決定することと、
前記特徴ベクトルをデバイス検証モデルに入力することと、
前記デバイス検証モデルを使用することによって前記被検証デバイスの信用性を判定することであって、前記デバイス検証モデルが、前記デバイス環境情報に基づいて、前記本人検証要求を送信するデバイスの信用性ラベルと、前記本人検証要求が信用できる要求として予測される確率とを決定するように構成される、ことと、
によって、前記被検証デバイスの信用性を判定することであって、前記履歴特徴情報が履歴デバイスのデバイス環境情報を含む、ことと、
本人検証ポリシーに従って本人検証を実行するために、前記被検証デバイスの前記信用性に従って、前記ユーザに対する本人検証を実行するための前記本人検証ポリシーを決定することとを含む、
コンピュータ可読記憶媒体。
【国際調査報告】
2021508889.tif 000011
2021508889.tif 000012
2021508889.tif 000013
2021508889.tif 000014