(57)【要約】本開示は、ログイン検証の方法、クライアント、サーバ、およびシステムを導入する。ユーザがログインするとき、クライアントは、保護下のアカウントシステムにログインするためのログイン要求をユーザから取得し、このログイン要求は、ログインされる少なくとも１つのアカウントを含み、現在のログインホスト内に記憶される属性情報からログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を決定し、現在の関連したアカウントシステムの少なくともこの属性情報を含むログイン検証情報を生成し、ログイン検証情報をサーバに送信する。サーバは、ログインされたアカウントに対応する事前に記憶された信頼できる属性情報に基づいてユーザのログインアクティビティを検証する。したがって、ログイン検証プロセスは単純化され、サーバを用いたログイン検証の効率が改善される。【特許請求の範囲】
【請求項１】
ログイン検証方法であって、
保護下のアカウントシステムにログインするためのユーザからのログイン要求であって、少なくともログインされる１つのアカウントを含む、ログイン要求を取得することと、
現在のログインホスト内に記憶された属性情報から、前記ログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を決定することと、
少なくとも前記現在の関連したアカウントシステムの前記属性情報を含むログイン検証情報を生成することと、
前記ログイン検証情報をサーバに送信することであって、前記ログイン検証情報内の前記現在の関連したアカウントシステムの前記属性情報は、前記サーバが、前記現在の関連したアカウントシステムの前記属性情報を前記ログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較するとき、かつ共通部分が存在し、前記共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定するための根拠となる、送信することと、を含む、方法。
【請求項２】
前記信頼できる属性情報は、
前記ユーザが最初に前記ログインされるアカウントにログインするために送信したログイン要求を取得することと、
第１のログインホスト内に記憶された属性情報から前記ログインされるアカウントに対応する第１の関連したアカウントシステムの属性情報を決定することと、
前記第１の関連したアカウントシステムの前記属性情報を前記サーバに送信することであって、前記第１の関連したアカウントシステムの前記属性情報は、前記サーバが前記ログインされるアカウントに対応する前記信頼できる属性情報を決定するために使用する根拠となる、送信することと、によって取得される、請求項１に記載の方法。
【請求項３】
前記属性情報は、アカウントシステムに対応するネットワークフローの事前に設定されたメッセージ、または前記事前に設定されたメッセージの事前に設定されたセグメントを含む、請求項１に記載の方法。
【請求項４】
前記現在の関連したアカウントシステムの前記属性情報に対する不可逆処理を実施することをさらに含む、請求項１に記載の方法。
【請求項５】
前記不可逆処理を実施することは、前記現在の関連したアカウントシステムの前記属性情報にハッシュ値操作を適用して、ハッシュ値を取得することを含む、請求項４に記載の方法。
【請求項６】
前記不可逆処理は、前記現在の関連したアカウントシステムの前記属性情報が前記送信中に悪意を持って修正されないことを確実にするように、前記ログイン検証情報を前記サーバに送信する前に実施される、請求項４に記載の方法。
【請求項７】
ログイン検証方法であって、
クライアントから送信されたログイン検証情報を受信することであって、前記ログイン検証情報は、少なくともログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を含み、前記現在の関連したアカウントシステムの前記属性情報は、前記クライアントがログイン要求をユーザから取得した後、現在のログインホスト内に記憶された属性情報から決定される、受信することと、
前記現在の関連したアカウントシステムの前記属性情報を前記ログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較することと、
共通部分が存在し、前記共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定することと、を含む、方法。
【請求項８】
共通部分が存在しないか、または前記共通部分が前記事前に設定された基準を満たさないとき、前記方法は、
前記現在のログインホストが信用されたホストであるかどうかを検証し、肯定的である場合、前記ログインが信頼できることを決定し、肯定的ではない場合、前記ログインが信頼できないことを決定することをさらに含む、請求項７に記載の方法。
【請求項９】
前記ログイン検証情報が前記現在のログインホストの機械属性を含むとき、前記現在のログインホストが信用されたホストであるかどうかを検証することは、
前記現在のログインホストの機械特徴が第１の信頼できる基準を満たすとき、前記現在のログインホストが信用されたホストであることを決定することを含む、請求項８に記載の方法。
【請求項１０】
前記現在のログインホストが信用されたホストであるかどうかを検証することは、
前記現在のログインホストのログイン履歴記録を取得することと、
前記ログイン履歴記録が第２の信頼できる基準を満たすとき、前記現在のログインホストが信用されたホストであることを決定することと、を含む、請求項８に記載の方法。
【請求項１１】
前記現在のログインホストが信用されたホストであるかどうかを検証することは、
前記現在のログインホストに対する第２の検証を実施することと、
前記現在のログインホストが前記第２の検証に合格するとき、前記現在のログインホストが信用されたホストであることを決定することと、を含む、請求項８に記載の方法。
【請求項１２】
前記信頼できる属性情報は、
前記クライアントから前記ログインされるアカウントに対応する第１の関連したアカウントシステムの属性情報を受信することであって、前記第１の関連したアカウントシステムの前記属性情報は、前記ユーザが最初に前記ログインされるアカウントにログインする第１のログインホスト内に記憶された属性情報から決定される、受信することと、
前記第１の関連したアカウントシステムの前記属性情報に基づいて、前記ログインされるアカウントに対応する前記信頼できる属性情報を決定することと、によって取得される、請求項８に記載の方法。
【請求項１３】
前記現在のログインホストが信用されたホストであることを検証し、前記ログインが信頼できることを決定した後、前記方法は、
前記現在の関連したアカウントシステムの前記属性情報を前記ログインされるアカウントに対応する事前に記憶された信頼できる属性情報に追加して、前記ログインされるアカウントに対応する前記信頼できる属性情報を更新することをさらに含む、請求項１２に記載の方法。
【請求項１４】
１つ以上のプロセッサによって実行されるとき、前記１つ以上のプロセッサに、
クライアントから送信されたログイン検証情報を受信することであって、前記ログイン検証情報は、少なくともログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を含み、前記現在の関連したアカウントシステムの前記属性情報は、前記クライアントがユーザからのログイン要求を取得した後、現在のログインホスト内に記憶された属性情報から決定される、受信することと、
前記現在の関連したアカウントシステムの前記属性情報を前記ログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較することと、
共通部分が存在し、前記共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定することと、を含む行為を実施させる実行可能な命令を記憶する、１つ以上のコンピュータ可読媒体。
【請求項１５】
共通部分が存在しないか、または前記共通部分が事前に設定された基準を満たさないとき、前記行為は、
前記現在のログインホストが信用されたホストであるかどうかを検証し、肯定的である場合、前記ログインが信頼できることを決定し、肯定的ではない場合、前記ログインが信頼できないことを決定することをさらに含む、請求項１４に記載の方法。
【請求項１６】
前記ログイン検証情報が前記現在のログインホストの機械属性を含むとき、前記現在のログインホストが信用されたホストであるかどうかを検証することは、
前記現在のログインホストの前記機械特徴が第１の信頼できる基準を満たすとき、前記現在のログインホストが信用されたホストであることを決定することを含む、請求項１５に記載の方法。
【請求項１７】
前記現在のログインホストが信用されたホストであるかどうかを検証することは、
前記現在のログインホストのログイン履歴記録を取得することと、
前記ログイン履歴記録が第２の信頼できる基準を満たすとき、前記現在のログインホストが信用されたホストであることを決定することと、を含む、請求項１５に記載の方法。
【請求項１８】
前記現在のログインホストが信用されたホストであるかどうかを検証することは、
前記現在のログインホストに対する第２の検証を実施することと、
前記現在のログインホストが前記第２の検証に合格するとき、前記現在のログインホストが信用されたホストであることを決定することと、を含む、請求項１５に記載の方法。
【請求項１９】
前記信頼できる属性情報は、
前記クライアントから前記ログインされるアカウントに対応する第１の関連したアカウントシステムの属性情報を受信することであって、前記第１の関連したアカウントシステムの前記属性情報は、前記ユーザが最初に前記ログインされるアカウントにログインする第１のログインホスト内に記憶された属性情報から決定される、受信することと、
前記第１の関連したアカウントシステムの前記属性情報に基づいて、前記ログインされるアカウントに対応する前記信頼できる属性情報を決定することと、によって取得される、請求項１５に記載の方法。
【請求項２０】
前記現在のログインホストが信用されたホストであることを検証し、前記ログインが信頼できることを決定した後、前記方法は、
前記現在の関連したアカウントシステムの前記属性情報を前記ログインされるアカウントに対応する事前に記憶された信頼できる属性情報に追加して、前記ログインされるアカウントに対応する前記信頼できる属性情報を更新することをさらに含む、請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連特許出願の相互参照
本出願は、「Ｍｅｔｈｏｄ，Ｃｌｉｅｎｔ，Ｓｅｒｖｅｒ  ａｎｄ  Ｓｙｓｔｅｍ  ｏｆ  Ｌｏｇｉｎ  Ｖｅｒｉｆｉｃａｔｉｏｎ」と題される、２０１２年７月１９日に出願された中国特許出願第２０１２１０２５１５４２．７号に対する外国優先権を主張し、その全体が参照により本明細書に組み込まれる。
【０００２】
技術の分野
本開示は、インターネット技術の分野に関し、具体的には、ログイン検証の方法、クライアント、サーバ、およびシステムに関する。
【背景技術】
【０００３】
インターネット技術が発達するにつれて、人々の生活は、ネットワークと入り混じっている。ますます多くの人々が、（インスタントメッセージツールである）ＱＱ、ＭＳＮなどのアカウントを用いて他の人々と通信し、かつオンラインショップ、例えばＴａｏｂａｏ上の登録を通じてオンラインショッピングを行うなど、通信、娯楽、および買い物の手段としてネットワークを使用することを選択している。しかしながら、アカウントハッキングが最近では非常に一般的である。多くのＱＱおよびＭＳＮユーザのアカウントが、ハッキングソフトウェア等の不正な方法を用いて他のユーザによってハッキングされ、不正にログインされ、したがってユーザの通常の操作に影響を与え、しかもなお悪いことにユーザに対する経済的損失を引き起こしている。また、ネットワークサーバは、ユーザのアカウントが通常にログインされるか、または不正にログインされるかどうかを区別することができず、したがってネットワークの安全性を大幅に減少させている。
【０００４】
近年、サーバがユーザのログインを正確に検証し、不正ログインの問題を解決するために、いくつかのサービスプロバイダは、デジタル証明書、またはアカウントをハードウェアに結び付けること等の手法を採用している。デジタル証明書は、インターネット通信における通信相手の識別情報を示し、ネットワークを通じてサーバ内のユーザの同一性を検証する方法を提供し、かつユーザの同一性に従ってネットワークリソースのアクセス権限を付与するために使用される一連のデータである。ユーザがデジタル証明書を申請した後、ユーザは、ユーザが別のコンピュータからログインするとき、デジタル証明書のコピーが導入されない場合、アカウントを問い合わすことを除いて全く操作を行うことができない。したがって、ユーザのアカウントの安全性が強化される。しかしながら、ユーザがユーザのコンピュータを変更する場合、ユーザは、サーバによる正確な検証を可能にするためにデジタル証明書を再申請する必要がある。
【０００５】
一方、アカウントをハードウェアに結び付けることとしては、Ｕシールドまたはモバイルデジタル証明書が挙げられる。Ｕシールドは、内蔵マイクロプロセッサを含むＵＳＢキーまたはドライブであり、オンラインデータおよび電子署名の暗号化／復号のための特定のアルゴリズムを利用して、オンライン取引の機密性、真正性、整合性、および否認防止を提供する。ユーザは最初に、Ｕシールドを購入し、アカウントとＵシールドとの間の関連性を確立する必要がある。オンライン取引を行うとき、銀行は、ユーザに文字列Ａを送信し、これは、時間文字列とアドレス文字列と取引情報文字列と返信攻撃対策文字列との組み合わせを暗号化した後に取得される。ユーザのＵシールドは、ユーザの個々の証明書に基づいて文字列Ａに不可逆計算を実施して、新しい文字列Ｂを得て、文字列Ｂを銀行に送信する。銀行もまた、不可逆計算を行う。銀行およびユーザの計算結果が同一である場合、ユーザのログインが正当であると認識され、取引は完了され得る。結果が同一ではない場合、ユーザのログインは、不正であると認識され、取引は失敗する。したがって、ネットワークの安全性が保証される。
【０００６】
しかしながら、上記から分かり得るように、デジタル証明書を適用するプロセスおよびＵシールドとユーザアカウントとの間の関連性を確立するプロセスの両方は、ユーザのログインを検証するときに比較的面倒であり、したがってユーザのログインがサーバ内で信頼できるかどうかの高効率かつ正確な検証を達成することができない。
【発明の概要】
【０００７】
本概要は、下段の発明を実施するための形態にさらに記載されている一連の概念を単純化された形式で導入するために提供されている。本要約は、請求されている主題のあらゆる主要な特徴または重要な特徴を確認することが意図されておらず、請求されている主題の範囲を決定する上での支援として単独に用いられることも意図されていない。例えば、「手法」という用語は、上の文脈によって、および本開示の全体を通して容認される、デバイス（複数可）、システム（複数可）、方法（複数可）、および／またはコンピュータが読み出し可能な命令を指し得る。
【０００８】
本開示の目的は、ユーザと関連付けられたログインが既存の技術の下で、サーバ内で信頼できるかどうかの高効率かつ正確な検証を達成することができない問題を解決するためにログイン検証方法を提供することである。
【０００９】
ログイン検証方法は、
保護下のアカウントシステムにログインするためのユーザからのログイン要求であって、少なくともログインされる１つのアカウントを含む、ログイン要求を取得することと、
現在のログインホスト内に記憶された属性情報から、ログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を決定することと、
現在の関連したアカウントシステムの少なくともこの属性情報を含むログイン検証情報を生成することと、
ログイン検証情報をサーバに送信することであって、検証情報内の現在の関連したアカウントシステムの属性情報は、サーバが、現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較するとき、かつ共通部分が存在し、共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定するための根拠となる、送信することと、を含む。
【００１０】
一実施形態では、信頼できる属性情報は、
ユーザが最初にログインされるアカウントにログインするために送信したログイン要求を取得することと、
第１のログインと関連付けられたホスト内に記憶された属性情報から、ログインされるアカウントに対応する第１の関連したアカウントシステムの属性情報を決定することと、
第１の関連したアカウントシステムの属性情報をサーバに送信することであって、第１の関連したアカウントシステムの属性情報は、サーバがログインされるアカウントに対応する信頼できる属性情報を決定する根拠となる、送信することと、を用いて取得される。
【００１１】
いくつかの実施形態では、属性情報は、アカウントシステムに対応するネットワークフローの事前に設定されたメッセージ、または事前に設定されたメッセージの事前に設定されたセグメントを含む。
【００１２】
一実施形態では、本方法は、
現在の関連したアカウントシステムの属性情報を不可逆的に処理することをさらに含む。
【００１３】
ログイン検証方法は、
クライアントから送信されたログイン検証情報を受信することであって、ログイン検証情報は、ログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報のうちの少なくともログイン検証情報を含み、現在の関連したアカウントシステムの属性情報は、クライアントがログイン要求をユーザから取得した後、現在のログインホスト内に記憶される属性情報から決定される、受信することと、
現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較することと、
共通部分が存在し、共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定することと、を含む。
【００１４】
一実施形態では、共通部分が存在しないか、または共通部分が事前に設定された基準を満たさないとき、本方法は、
現在のログインホストが信用されたホストであるかどうかを検証し、肯定的である場合、ログインが信頼できることを決定し、肯定的ではない場合、ログインが信頼できないことを決定することをさらに含む。
【００１５】
加えて、またはあるいは、ログイン検証情報が現在のログインホストの機械属性を含むとき、現在のログインホストが信用されたホストであるかどうかを検証することは、
現在のログインホストの機械属性が第１の信頼できる基準を満たすとき、現在のログインホストが信用されたホストであることを決定することを含む。
【００１６】
加えて、またはあるいは、現在のログインホストが信用されたホストであるかどうかを検証することは、
現在のログインホストのログイン履歴記録を取得することと、
ログイン履歴記録が第２の信頼できる基準を満たすとき、現在のログインホストが信用されたホストであることを決定することと、を含む。
【００１７】
加えて、またはあるいは、現在のログインホストが信用されたホストであるかどうかを検証することは、
現在のログインホストに対する第２の検証を実施することと、
現在のログインホストが第２の検証に合格するとき、現在のログインホストが信用されたホストであることを決定することと、を含む。
【００１８】
一実施形態では、信頼できる属性情報は、
クライアントからログインされるアカウントに対応する第１の関連したアカウントシステムの属性情報を受信することであって、第１の関連したアカウントシステムの属性情報は、ユーザが最初にログインされるアカウントにログインする第１のログインホスト内に記憶された属性情報から決定される、受信することと、
第１の関連したアカウントシステムの属性情報に基づいて、ログインされるアカウントに対応する信頼できる属性情報を決定することと、を通じて取得される。
【００１９】
いくつかの実施形態では、現在のログインホストが信用されたホストであることを検証し、ログインが信頼できることを決定した後、本方法は、
現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報に追加して、ログインされるアカウントに対応する信頼できる属性情報を更新することをさらに含む。
【００２０】
本開示は、上記方法の実用的な実装および適用のためのログイン検証のクライアント、サーバ、およびシステムをさらに提供する。
【００２１】
ログイン検証のクライアントは、
保護下のアカウントシステムにログインするためのユーザからのログイン要求であって、少なくともログインされる１つのアカウントを含む、ログイン要求を取得するために使用される、ログイン要求獲得モジュールと、
現在のログインホスト内に記憶された属性情報からログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を決定するために使用される、現在の関連したアカウントシステムの属性情報決定モジュールと、
現在の関連したアカウントシステムの少なくともこの属性情報を含むログイン検証情報を生成するために使用される、ログイン検証情報生成モジュールと、
ログイン検証情報をサーバに送信するために使用されるログイン検証情報送信モジュールであって、ログイン検証情報内の現在の関連したアカウントシステムの属性情報は、サーバが、現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較するとき、かつそれらの間の共通部分が存在し、共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定するための根拠となる、ログイン検証情報送信モジュールと、を含む。
【００２２】
ログイン検証のサーバは、
クライアントから送信されたログイン検証情報を受信するために使用されるログイン検証情報受信モジュールであって、ログイン検証情報は、ログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報のうちの少なくともログイン検証情報を含み、現在の関連したアカウントシステムの属性情報は、クライアントがログイン要求をユーザから取得した後、現在のログインホスト内に記憶された属性情報を用いて決定される、ログイン検証情報受信モジュールと、
現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較するために使用される、比較モジュールと、
共通部分が存在し、共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定するために使用される、信頼できるログイン決定モジュールと、を含む。
【００２３】
ログイン検証のシステムは、上述のようなクライアントと、サーバとを含む。
【００２４】
既存の技術と比較すると、本開示は、以下の利点を有する。本開示の実施形態に開示されるログイン検証方法では、ユーザがログインするとき、保護下のアカウントシステムにログインするためのログイン要求をユーザから取得し、現在のログインホスト内に記憶される属性情報からログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を決定し、少なくともこのログイン要求と、不可逆的に処理した後に取得される現在の関連したアカウントシステムの属性情報とを含むログイン検証情報を生成し、ログイン検証情報をサーバに送信する。サーバは、現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較し、それと関連付けられたログインが、共通部分が存在する場合、信頼できるログインであることを決定する。この方法では、サーバは、デジタル証明書またはＵシールドを用いてログイン検証のさらなる操作を実施することなく、ログインされるアカウントに対応する事前に記憶された信頼できる属性情報に基づいて、ユーザのログインアクティビティを検証し、したがってログイン検証プロセスを単純化し、サーバを用いてログイン検証の効率を改善する。
【００２５】
さらに、デジタル証明書またはＵシールドがもはや必要とされないので、ユーザのための費用も減少される。
【００２６】
しかしながら、本開示を実装するいかなる製品も同時にすべての上記利点を達成する必要はない。
【００２７】
本開示の例示的な実施形態の技術的方式をより明確に理解するために、例示的な実施形態を説明するために必要とされる添付の図が簡単に後述される。明らかであろうように、以下の図は、本開示のいくつかの例示的な実施形態のみを構成する。これらの添付の図に基づいて、当業者であれば、独創的に努力することなく、他の図を得ることができる。
【図面の簡単な説明】
【００２８】
【図１】本開示の一実施形態に従う、データ交換を行うとき、ＱＱアカウントシステムとサーバとの間で交換されるメッセージの概略図である。
【図２】本開示の一実施形態に従う、ログイン検証方法を示すフローチャートである。
【図３】本開示の一実施形態に従う、信頼できる属性情報を作成するプロセスを示すフローチャートである。
【図４】本開示の一実施形態に従う、ログイン検証の別の方法を示すフローチャートである。
【図５】本開示の一実施形態に従う、現在のログインホストの機械属性が第１の信頼できる基準を満たすかどうかの決定を示すフローチャートである。
【図６】本開示の一実施形態に従う、現在のログインホストの機械属性が第１の信頼できる基準を満たすかどうかの別の決定を示すフローチャートである。
【図７】本開示の一実施形態に従う、ログイン履歴記録が第２の信頼できる基準を満たすかどうかの決定を示すフローチャートである。
【図８】本開示の一実施形態に従う、ログイン履歴記録が第２の信頼できる基準を満たすかどうかの別の決定を示すフローチャートである。
【図９】本開示の一実施形態に従う、ホストが信用されたホストであるかどうかの決定を示すフローチャートである。
【図１０】本開示の一実施形態に従う、信頼できる属性情報を取得するフローチャートである。
【図１１】本開示の一実施形態に従う、ログイン検証のクライアントの構造図である。
【図１２】本開示の一実施形態に従う、ログイン検証のサーバの構造図である。
【図１３】本開示の一実施形態に従う、ログイン検証のシステムの構造図である。
【図１４】図１２に記載されるような例示的なサーバの構造図である。
【発明を実施するための形態】
【００２９】
例示的な実施形態の技術的方式を、例示的な実施形態の添付の図を用いて、より明確かつ完全に記載する。本明細書に記載の例示的な実施形態は、本開示の例示的な実施形態すべてではなく一部のみを構成する。本開示の例示的な実施形態に基づいて、当業者であれば、依然として本開示の範囲内であるすべての他の例示的な実施形態を得ることができる。
【００３０】
本開示は、様々な異なる汎用または特定のコンピューティングシステム環境または構成、例えば、パーソナルコンピュータ、サーバコンピュータ、モバイルデバイスもしくは携帯用デバイス、タブレット、マルチプロセッサシステム、および／または上記のシステムもしくはデバイス等を含む任意の分散コンピューティング環境に使用され得る。
【００３１】
本開示は、プログラムモジュール等のコンピュータ実行可能な命令の一般的な状況において記載され得る。一般的に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実現するための、ルーチン、プロシージャ、オブジェクト、構成要素、データ構造などを含む。本開示はまた、分散コンピューティング環境で実装されてもよい。これらの分散コンピューティング環境では、通信ネットワークを通じて接続されるリモート処理デバイスがタスクを実行するために使用される。分散コンピューティング環境では、プログラムモジュールは、ローカルまたはリモートコンピューティング記憶デバイス（複数可）を含む１つ以上の記憶媒体であり得る。
【００３２】
本開示の１つの着想は、クライアントによって、保護下のアカウントシステムにログインするためのユーザからのログイン要求であって、少なくともログインされる１つのアカウントを含む、ログイン要求を取得することと、現在のログインホスト内に記憶される属性情報からログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を決定することと、少なくともこのログイン要求と、不可逆処理後に取得される現在の関連したアカウントシステムの属性情報とを含むログイン検証情報を生成することと、ログイン検証情報をサーバに送信することであって、不可逆処理後に取得される現在の関連したアカウントシステムの属性情報は、サーバがログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較する根拠となる、送信することと、それと関連付けられたログインが、共通部分が存在する場合、信頼できるログインであることを決定することとを含むことができる。いくつかの例では、開示される方法は、例えば、Ｕシールド等の他の検証方法とともにさらに使用されてもよい。
【００３３】
ユーザがログインするホストには、通常ＱＱ、ＭＳＮ、ＯｕｔＬｏｏｋ、Ｘｕｎｌｅｉ、またはＡｌｉＰａｙ等のいくつかのアカウントシステムベースのソフトウェアがインストールされる。これらのソフトウェアは、サーバとデータを交換し、ある特定の属性フロー情報を含むデータメッセージを送信する。本開示は、ある特定のフロー属性情報を有するある特定のデータメッセージ、またはデータメッセージのある特定のセグメントを使用し、これらは、ユーザがアカウントシステムに対応する属性情報として、これらのアカウントシステムを通じてサーバと情報を交換するときに送信されたネットワークフローに含まれる。この実施形態では、データメッセージのタイプまたは指定されたセグメントは、条件に基づいて事前に定義され得る。ＱＱアカウントシステムを例に取るとする。図１は、多くのセグメントを有し、かつＱＱアカウントシステムがサーバとデータを交換するときに送信されるメッセージを示す。メッセージ全体に含まれる内容が、ＱＱアカウントシステムに対応する属性情報と見なされ得る。あるいは、特定の位置でセグメント内に含まれる情報が、属性情報であるようにメッセージのセグメントの中から選択されてもよい。例えば、ＱＱ番号である第７〜第１０のバイト内に含まれる情報が、ＱＱアカウントシステムに対応する属性情報として選択される。本開示は、アカウントシステムおよびサーバが属性情報として情報交換を実施するときに送信されるデータメッセージまたはデータメッセージ内のセグメントを使用すると解釈されない。同様に、ログインホスト上のアカウントシステムの操作中に生成されるローカルデータが、属性情報として使用されてもよい。例えば、ＱＱソフトウェアは、ＱＱが動作しているときにローカルシステム時刻を取得する。本開示に開示されるログイン検証方法は、保護下のアカウントシステムとしてアカウントシステムを選択すること、および１つ以上の他のアカウントシステムを保護下のアカウントシステムの関連したアカウントシステムとして設定すること、例えば、ＡｌｉＰａｙを保護下のアカウントシステムとして、ＱＱを関連したアカウントシステムとして設定することに基づいている。ユーザによる保護下のアカウントシステムのログインが信頼できるかどうかを検証することは、関連したアカウントシステムの属性情報を使用して実施される。このプロセスの詳細は、以下の実施形態に示される。
【００３４】
図２は、本開示の一実施形態に従う、ログイン検証方法のフローチャートを示す。このプロセスは、ログイン検証のクライアント内に適用され、以下を含む。
【００３５】
ブロックＳ２０１は、保護下のアカウントシステムにログインするためのユーザからのログイン要求を取得し、ログイン要求は、少なくともログインされる１つのアカウントを含む。
【００３６】
現在保護下にあるアカウントシステムがＡｌｉＰａｙである場合、ホスト上で動作するログイン検証のクライアントが、ユーザがホスト上のＡｌｉＰａｙのアカウントにログインするとき、ユーザのログイン要求を取得する。
【００３７】
ブロックＳ２０２は、現在のログインホスト内に記憶された属性情報から、ログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を決定する。
【００３８】
現在保護下にあるアカウントシステムに対応する関連したアカウントシステムがＱＱであると仮定する。ログインされたＡｌｉＰａｙアカウントに対応するＱＱの現在の属性情報は、現在のログインホスト内に記憶された属性情報から取得される。ＡｌｉＰａｙアカウントに対応するＱＱの現在の属性情報は、現在のホスト内に記憶されるすべてのＱＱアカウントに対応する属性情報、または所定の時間間隔内の現在のホストを通じてログインされるＱＱアカウントに対応する属性情報であってもよい。
【００３９】
ブロックＳ２０３は、現在の関連したアカウントシステムの少なくともこの属性情報を含むログイン検証情報を生成する。
【００４０】
ブロックＳ２０４は、ログイン検証情報をサーバに送信する。
【００４１】
ログイン検証情報内の現在の関連したアカウントシステムの属性情報は、サーバが、現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較するとき、かつそれらの間の共通部分が存在し、共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定するための根拠となる。
【００４２】
それらの間の共通部分は、信頼できる属性情報が現在の関連したアカウントシステムの属性情報のうちの情報を含むか、または現在の関連したアカウントシステムの属性情報が信頼できる属性情報のうちの情報を含むことを意味する。
【００４３】
例えば、サーバにログインされ、かつそのサーバ内に事前に記憶されるアカウントに対応する信頼できる属性情報は、ＱＱ番号Ａ、Ｂ、およびＣを含むことができる。現在のログイン中に送信される現在の関連したアカウントシステムの属性情報がＱＱ番号Ａを含む場合、共通部分がそれらの間に存在する。
【００４４】
共通部分に対する所定の基準は、共通部分内に含まれる関連したアカウント数が所定の値、例えば、３未満ではないことであり得る。この所定の値は、実際の状況に基づいて設定されてもよい。現在の適用のシナリオが高度な信頼性の必要がある場合、所定の値は、比較的大きい値であってもよい。換言すれば、共通部分の値がより高ければ高いほど、それは、より信頼できる。現在の適用のシナリオが高度な信頼性を必要としない場合、所定の値は、より小さい値であってもよい。共通部分内に含まれる関連したアカウント数が所定の値より低い場合、この共通部分は、存在するが、基準を満たさない。
【００４５】
さらに、共通部分に対する基準はまた、共通部分が１つ以上の特定の関連したアカウントの属性情報を含むかどうかであってもよい。例えば、ＱＱ番号Ａが特定の関連したアカウントの属性情報に対応することを仮定する。信頼できる属性情報がＡ、Ｂ、およびＣを含み、現在の関連したアカウントの属性情報が、ＢおよびＣを含む場合、この基準に基づいて決定がなされると、それらの間の共通部分は、それが存在するが、それが特定の関連したアカウントＡを含まないため、事前に設定された基準を満たすことができない。
【００４６】
本開示に開示されるログイン検証方法では、クライアントは、サーバに、保護下のアカウントシステムと関連付けられるログインされるアカウントに対応する、現在のログインホスト内に記憶される現在の関連したアカウントの属性情報を送信し、サーバは、それをログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較することができ、それらの間の共通部分が存在するとき、このログインが信頼できることを決定するようにする。したがって、デジタル証明書またはＵシールドを用いてログイン検証を実施するさらなる操作が必要とされず、それ故にログイン検証プロセスを単純化し、サーバによって行われたログイン検証の効率を改善する。
【００４７】
さらに、Ｕシールドまたはデジタル証明書を購入することが必要とされないので、ユーザの費用が減少される。
【００４８】
さらに、このプロセスは、
現在の関連したアカウントシステムの属性情報に不可逆処理を実施することをさらに含む。
【００４９】
具体的な操作は、ハッシュ値操作をＱＱ属性情報に適用して、対応するハッシュ値を取得することを含むことができる。
【００５０】
現在の関連したアカウントシステムの属性情報に不可逆処理を実施するプロセスは、属性情報が送信プロセス中に悪意を持って修正されないことを確実にするように、ログイン検証情報をサーバに送信する前に追加され、そのようにして属性情報の正確性を確実にし、検証プロセスの正確性をさらに改善することができる。
【００５１】
さらに、上記実施形態では、サーバは、ログインされるアカウントに対応する信頼できる属性情報を事前に記憶する。信頼できる属性情報は、以下のブロックを用いて作成される。このプロセスの詳細は、図３に示され、以下を含む。
【００５２】
ブロックＳ３０１は、ユーザが最初にログインされるアカウントにログインするために送信したログイン要求を取得する。
【００５３】
クライアントは、ユーザが最初にログインされるアカウントを登録するとき、ログイン要求を取得する。
【００５４】
ブロックＳ３０２は、第１のログインホスト内に記憶された属性情報から、ログインされるアカウントに対応する第１の関連したアカウントシステムの属性情報を決定する。
【００５５】
初回の登録のためにユーザによって使用されるホストが３つのＱＱ番号の属性情報を記憶する場合、これらの３つのＱＱ番号の属性情報は、第１の関連したアカウントシステムの属性情報と見なされる。
【００５６】
ブロックＳ３０３は、第１の関連したアカウントシステムの属性情報であって、サーバがログインされるアカウントに対応する信頼できる属性情報を決定する根拠となる、第１の関連したアカウントシステムの属性情報をサーバに送信する。
【００５７】
サーバは、この受信の際に第１の関連したアカウントシステムの属性情報を記憶し、ログインされるアカウントの信頼できる属性情報としてそれを直接使用するか、またはそれを繰り返し更新することなど、それに他の処理を実施し、かつログインされるアカウントの信頼できる属性情報として更新された内容を使用することができる。
【００５８】
本実施形態では、クライアントは、関連したアカウントの属性情報のバックエンドの長期プロセスおよび学習デバイスとして使用されてもよい。このプロセスは、ホスト内に記憶される関連したアカウントの属性情報などを取り出し、不可逆処理後、それをサーバにアップロードする。サーバは属性情報を記憶および維持し、クライアントからアップロードされた属性情報に従ってそれを更新する。
【００５９】
ユーザが最初にアカウントにログインするときに信頼できないログインを有する可能性は非常に低いので、ユーザが信頼できる属性情報として最初にログインを実施するホスト内に記憶される関連したアカウントの属性情報を使用することは、非常に信頼できることであり、検証プロセスの正確性を大幅に確実にすることができる。
【００６０】
さらに、本実施形態は、第１の関連したアカウントシステムの属性情報に不可逆操作のプロセスを行うことをさらに含むことができる。
【００６１】
このプロセスは、属性情報が送信プロセス中に悪意を持って修正されないことを確実にするように、第１の関連したアカウントシステムの属性情報をサーバに送信する前に追加され、そのようにして属性情報の正確性を確実にし、属性情報に基づいて行われる後続の検証プロセスをさらに改善することができる。
【００６２】
図４は、本開示に開示されるログイン検証の別の方法を示すフローチャートであり、これは、ログイン検証のサーバに使用される。詳細は、以下を含む。
【００６３】
ブロックＳ４０１は、クライアントから送信されたログイン検証情報を受信する。
【００６４】
ログイン検証情報は、ログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報のうちの少なくともログイン検証情報を含む。現在の関連したアカウントシステムの属性情報は、クライアントがユーザによって送信されたログイン要求を取得した後、現在のログインホスト内に記憶される属性情報から決定される。
【００６５】
属性情報は、アカウントシステムに対応するネットワークフローの事前に設定されたメッセージ、または事前に設定されたメッセージ内の事前に設定されたセグメントを含む。
【００６６】
ブロックＳ４０２は、現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較する。
【００６７】
現在の関連したアカウントシステムの属性情報が、ＱＱ番号Ａ、Ｂ、Ｃ、およびＤであり、信頼できる属性情報がＱＱ番号ＣおよびＤであると仮定する。
【００６８】
ブロックＳ４０３は、それらの間の共通部分が存在し、かつ共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定する。
【００６９】
ＣおよびＤの共通の共通部分は、２つの属性を比較することによって存在することが見出される。事前に設定された基準が２未満ではない共通部分内に含まれる関連したアカウント数である場合、それらの間の共通部分は存在し、共通部分は、事前に設定された基準を満たし、このログインが信頼できるログインであることを証明する。
【００７０】
さらに、共通部分がなく、共通部分が事前に設定された基準を満たさないとき、本方法は、現在のログインホストが信用されたホストであるかどうかを検証し、肯定的である場合、ログインが信頼できることを決定し、肯定的ではない場合、ログインが信頼できないことを決定することをさらに含む。
【００７１】
具体的には、クライアントからサーバに送信されたログイン検証情報が現在のログインホストの機械属性を含むとき、現在のログインホストが信用されたホストであるかどうかを検証するプロセスは、
現在のログインホストの機械属性が第１の信頼できる基準を満たすかどうかを決定することを含み、現在のログインホストは、肯定的である場合に信用され、そうでなければ信用されない。本実施形態に記載される機械属性は、ホストのＩＤ、ホストのＭＡＣアドレス、ホストのハードディスクのシリアル番号、ホストのＣＰＵのＩＤなどであってもよい。
【００７２】
現在のログインホストの機械属性が第１の信頼できる基準を満たすかどうかを決定する特定の実装が、図５に示され、これは、以下を含む。
【００７３】
ブロックＳ５０１は、ログインされるアカウントに対応する第１のログインと関連付けられた事前に記憶された機械属性を取得する。
【００７４】
ブロックＳ５０２は、第１のログインと関連付けられた機械属性が現在のログインホストの機械属性と同じであるとき、現在のログインホストが信頼できることを決定する。
【００７５】
換言すれば、現在のログインホストは、ユーザが最初にログインされるアカウントにログインするホストであり、それ故に信用されたホストである。ログインはまた、信頼できるログインとして決定される。
【００７６】
現在のログインホストの機械属性が第１の信頼できる基準を満たすかどうかを決定する別の実装プロセスが、図６に示され、これは、以下を含む。
【００７７】
ブロックＳ６０１は、機械属性の現在のログインホストのホストＩＤを取得する。
【００７８】
ブロックＳ６０２は、事前に記憶された公開ホストＩＤの組が現在のログインホストのホストＩＤを含むとき、現在のログインホストが公開ホストであり、現在のログインホストが信用されたホストではないことを決定する。
【００７９】
上記プロセスは、現在のログインホストが公開ホスト、例えば、インターネットカフェ内のホストまたは公衆のコンピュータ室内のホストであるかどうかを決定する。現在のログインホストが公開ホストではない場合、現在のログインホストは、信用されたホストであると決定される。公開ホストであると決定される場合、現在のログインホストは、信用されたホストではないと決定される。
【００８０】
現在のログインホストが信用されたホストであるかどうかを検証するプロセスはまた、
現在のログインホストのログイン履歴記録を取得することと、
現在のログインホストは、ログイン履歴記録が第２の信頼できる基準を満たすとき、信用されたホストであることと、を含むことができる。
【００８１】
ログイン履歴記録が第２の信頼できる基準を満たすかどうかを決定する実装プロセスが、図７に示され、これは、以下を含む。
【００８２】
ブロックＳ７０１は、ログイン履歴記録から、保護下のアカウントシステムに属する過去のログインアカウント数の値を取得する。
【００８３】
ブロックＳ７０２は、この値が所定のログイン番号を超えないとき、現在のログインホストが信用されたホストであることを決定する。
【００８４】
上記プロセスは、現在のログインホストが現在のログインホストのログイン履歴データ内の過去のログインアカウント数を確認することによって公開ホストであるかどうかを決定する。それが公開ホストである場合、それは信頼できない。
【００８５】
ログイン履歴記録が第２の信頼できる基準を満たすかどうかを決定する別の実装プロセスが、図８に示され、これは、以下を含む。
【００８６】
ブロックＳ８０１は、ログイン履歴記録からログインされるアカウントに対応するログイン記録を取得する。
【００８７】
ブロックＳ８０２は、ログイン数が事前に設定された数を超えるか、またはログインと関連付けられた継続時間が事前に設定された時間を超えるとき、現在のログインホストが信用されたホストであることを決定する。
【００８８】
本実施形態では、ホストが信用できるかどうかを決定するために、ユーザが複数回、そのホスト内にログインを実施したかどうか、またはユーザがある期間、そのホストを通じて持続的にログインしたかどうかについて決定がなされる。事前に設定される数は、５回または１０回など、任意の設定値であってもよく、事前に設定される時間は、１週間または１ヶ月など、任意に設定される時間の値であってもよい。
【００８９】
さらに、現在のログインホストが信用されたホストであるかどうかを検証する代替のプロセスが、図９に示され、これは、以下を含む。
【００９０】
ブロックＳ９０１は、現在のログインホストに対する第２の検証を行う。
【００９１】
第２の検証方法は、携帯電話の検証コードを送信するなど、様々な方法で実現されてもよく、本明細書に繰り返し記載されない。
【００９２】
ブロックＳ９０２：現在のログインホストが第２の検証に合格するとき、現在のログインホストは、信用されたホストである。
【００９３】
本実施形態は、現在のログインホストが信用されるかどうかを決定するために図５〜９に示されるプロセスに限定されない。現在のログインホストが信用されるかどうかを検証することができる他の方法もまた、本開示の範囲内である。
【００９４】
さらに、本実施形態は、現在のログインホストが信用されるかどうかを検証するために図５〜９に示される任意の単一のプロセスに限定されない。実際のシナリオに基づいて、当業者は、この任意の決定基準を組み合わせ、組み合わせられた基準に基づいてホストに対する検証を実施し、それによって検証結果の信頼性を改善することができる。
【００９５】
本開示はまた、サーバによって信頼できる属性情報を取得するプロセスを開示し、これは、図１０に示され、以下を含む。
【００９６】
ブロックＳ１００１は、クライアントからログインされるアカウントに対応する第１の関連したアカウントシステムの属性情報を受信する。
【００９７】
第１の関連したアカウントシステムの属性情報は、ユーザが最初にログインされるアカウントにログインするとき、第１のログインホスト内に記憶される属性情報から決定される。
【００９８】
ブロックＳ１００２は、第１の関連したアカウントシステムの属性情報に基づいて、ログインされるアカウントに対応する信頼できる属性情報を決定する。
【００９９】
本実施形態では、ログインされるアカウントに対応する信頼できる属性情報を決定することは、第１の関連したアカウントシステムの属性情報を記憶することと、ログインされるアカウントの信頼できる属性情報としてそれを使用することと、または第１の関連したアカウントシステムの属性情報を連続的に更新することと、ログインされるアカウントの信頼できる属性情報として更新された内容を使用することとを含むことができる。
【０１００】
更新プロセスの詳細は、以下を含む。
【０１０１】
現在のログインホストが信用されたホストであり、ログインが信頼できるログインであることを検証した後、不可逆的に処理された現在の関連したアカウントシステムの属性情報が、ログインされるアカウントに対応する事前に記憶された信頼できる属性情報に追加されて、ログインされるアカウントに対応する信頼できる属性情報を更新する。
【０１０２】
ユーザの第１の関連したアカウントシステムの属性情報がＱＱ番号Ａ、Ｂ、およびＣであると仮定すると、現在のログインホストの現在の関連したアカウントシステムの属性情報は、ＱＱ番号Ｄ、Ｅ、およびＦであり、ログインホストが信用されたホストであるとき、ＱＱ番号Ｄ、Ｅ、およびＦは、更新された信頼できる属性情報として信頼できる属性情報に追加される。
【０１０３】
本開示はまた、ホスト上で動作するログイン検証のクライアントを開示する。この構造は、図１１に示され、これは、
保護下のアカウントシステムにログインするためのユーザからのログイン要求であって、少なくともログインされる１つのアカウントを含む、ログイン要求を取得するために使用される、ログイン要求取得モジュール１１１と、
現在のログインホスト内に記憶された属性情報からログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報を決定するために使用される、現在の関連したアカウントシステムの属性情報決定モジュール１１２と、
不可逆的に処理された現在の関連したアカウントシステムの少なくともこの属性情報を含むログイン検証情報を生成するために使用される、ログイン検証情報生成モジュール１１３と、
ログイン検証情報をサーバに送信するために使用され、ログイン検証情報内の現在の関連したアカウントシステムの属性情報は、サーバが、現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較するとき、かつそれらの間の共通部分が存在し、共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定するための根拠となる、ログイン検証情報送信モジュール１１４と、を含む。
【０１０４】
さらに、現在の関連したアカウントシステムの属性情報は、不可逆的にさらに処理されてもよい。
【０１０５】
さらに、本実施形態は、上述されるような作業プロセスに限定されない。図２および３に示されるプロセスはまた、作業プロセスの詳細に対して参照されてもよい。
【０１０６】
ユーザが保護下のシステムにログインするログイン要求を取得するとき、この実施形態に開示されるログイン検証のクライアントは、現在のログインホストの関連したアカウントの属性情報を主導的に取得し、それをサーバに、ログインが信頼できるかどうかを検証するための根拠となるものとして送信し、そのようにしてログイン検証のプロセスを単純化する目的を達成し、サーバによるログイン検証の効率を改善する。
【０１０７】
本開示はまた、ログイン検証のサーバを開示する。この構造は、図１２に示され、これは、
クライアントから送信されたログイン検証情報を受信するために使用され、ログイン検証情報は、ログインされるアカウントに対応する現在の関連したアカウントシステムの属性情報のうちの少なくともログイン検証情報を含み、現在の関連したアカウントシステムの属性情報は、クライアントがログイン要求をユーザから取得した後、現在のログインホスト内に記憶された属性情報を使用して決定される、ログイン検証情報受信モジュール１２１と、
現在の関連したアカウントシステムの属性情報をログインされるアカウントに対応する事前に記憶された信頼できる属性情報と比較するために使用される、比較モジュール１２２と、
共通部分が存在し、かつ共通部分が事前に設定された基準を満たすとき、ログインが信頼できることを決定するために使用される、信頼できるログイン決定モジュール１２３と、を含む。
【０１０８】
さらに、サーバは、共通部分が存在しないか、または共通部分が事前に設定された基準を満たさないとき、現在のログインホストが信用されたホストであるかどうかを検証するために使用される、ホスト検証モジュール１２４をさらに含む。ホストが信用される場合、このログインは、信頼できるログインである。ホストが信用されない場合、このログインは、信頼できないログインである。
【０１０９】
さらに、本実施形態は、上述されるような作業プロセスに限定されない。図４〜１０に示されるプロセスはまた、作業プロセスの詳細に対して参照されてもよい。
【０１１０】
この実施形態に開示されるログイン検証のサーバは、クライアントから送信された現在の関連したアカウントシステムの属性情報を信頼できる属性情報と比較し、共通部分が存在するかどうかに基づいてログインが信頼できるかどうかを決定し、そのようにして検証プロセスを単純化し、検証の効率を改善し、検証の信頼性をさらに改善する。
【０１１１】
本開示はまた、ログイン検証のシステムを開示する。この構造は、図１３に示され、これは、図１１に示されるようなログイン検証のクライアントと、図１２に示されるようなログイン検証のサーバとを含む。これらの作業プロセスは、本明細書に繰り返し記載されない。
【０１１２】
ログイン検証の例示的なシステムは、ログイン検証のクライアントとログイン検証のサーバとの協調によってユーザのログインアクティビティの検証を達成し、それによって検証プロセスを単純化し、検証の効率を改善する。
【０１１３】
図１４は、上述のようなサーバ等の例示的なサーバ１４００をより詳細に示す。一実施形態では、サーバ１４００は、これらに限定されないが、１つ以上のプロセッサ１４０１と、ネットワークインターフェース１４０２と、メモリ１４０３と、入力／出力インターフェース１４０４とを含むことができる。
【０１１４】
メモリ１４０３としては、ランダムアクセスメモリ（ＲＡＭ）等の揮発性メモリ、および／または読み出し専用メモリ（ＲＯＭ）もしくはフラッシュＲＡＭ等の不揮発性メモリの形態のコンピュータ可読媒体が挙げられ得る。メモリ８０３は、コンピュータ可読媒体の一例である。
【０１１５】
コンピュータ可読媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータ等の情報を格納するための任意の方法または技術で実装される揮発性および不揮発性の、取り外し可能および取り外し不可能な媒体が含まれる。コンピュータ記憶媒体の例は、限定されないが、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、その他のランダムアクセスメモリ（ＲＡＭ）、読み出し専用記憶装置（ＲＯＭ）、電気的に消去可能でプログラム可能な読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリまたはその他のメモリ技法、コンパクトディスク読み出し専用記憶装置（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）またはその他の光学記憶媒体、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、またはコンピュータによるアクセスのための情報を記憶するために使用されるその他のあらゆる非伝送媒体、を含む。本明細書で定義されるように、コンピュータ可読媒体には、変調データ信号および搬送波等の一過性媒体は含まれない。
【０１１６】
メモリ１４０３は、プログラムモジュール１４０５と、プログラムデータ１４０６とを含むことができる。一実施形態では、プログラムモジュール１４０５は、ログイン検証情報受信モジュール１４０７と、比較モジュール１４０８と、信頼できるログイン決定モジュール１４０９と、ホスト検証モジュール１４１０とを含むことができる。プログラムモジュールに関する詳細は、上記前述の実施形態に見出すことができる。
【０１１７】
様々な例示的な実施形態が本開示に漸次記載されることに留意されたい。各例示的な実施形態の要点は、他の例示的な実施形態とは異なり得、例示的な実施形態の同じまたは類似の部分が互いに参照され得る。例示的なシステムの説明は、これらの例示的な装置が例示的な方法のそれらの対応する実施形態に類似するので、比較的単純である。例示的な方法の実施形態において関連した詳細が見出され得る。
【０１１８】
最後に、本文書内の「第１の」および「第２の」等の関係語は、いずれも、１つ実体をもう１つの実体と、または１つの操作を別の操作と区別することのみを意味し、任意の現実世界における関係の存在またはこれらの実体もしくは操作間の順序付けを必ずしも要求または示唆しないことを指摘されるべきである。さらに、「含む」、「有する」、または任意の他の変形などの用語は、「備える」を非排他的に包含することが意図される。したがって、特徴の集積を個別に含むプロセス、方法、物品、またはデバイスは、これらの特徴を含むことができるだけではなく、列挙されない他の特徴、またはこれらのプロセス、方法、物品、もしくはデバイスのあらゆる固有の特徴も含むことができる。任意のさらなる制限なく、「〜を含む」という表現内に定義される特徴は、特徴を列挙するプロセス、方法、物品、またはデバイスが他の同等の特徴を有し得る可能性を排除しない。
【０１１９】
ユーザ同一性を認識する方法およびサーバを、上で本開示に詳細に記載した。例示的な実施形態が、本開示内の本発明の概念および実装を示すために利用される。例示的な実施形態は、本開示の方法および中心概念をより良く理解するためにのみ使用される。本開示内の概念に基づいて、当業者は、例示的な実施形態および適用分野を修正することができる。全体として、本開示内の内容は、本開示に対する限定として解釈されるべきではない。
【図１】
2015525932.tif 000002
【図２】
2015525932.tif 000003
【図３】
2015525932.tif 000004
【図４】
2015525932.tif 000005
【図５】
2015525932.tif 000006
【図６】
2015525932.tif 000007
【図７】
2015525932.tif 000008
【図８】
2015525932.tif 000009
【図９】
2015525932.tif 000010
【図１０】
2015525932.tif 000011
【図１１】
2015525932.tif 000012
【図１２】
2015525932.tif 000013
【図１３】
2015525932.tif 000014
【図１４】
2015525932.tif 000015