JP6742641B2 - 損害報告されたアカウントのログイン方法及び装置 - Google Patents

Description

本願は、ネットワーク技術の分野に関し、特に、損害報告されたアカウントのログイン方法及び装置に関する。

ネットワーク技術の急速な発展に伴い、Ｗｅｉｂｏ、タオバオ（Ｔａｏｂａｏ）、及び各種電子銀行などのネットワークサービスプロバイダ（提供者）の数が増大している。ユーザは、ネットワークアカウント及びパスワードを用いて、対応するネットワークサービスのプラットフォームにログインした後、プラットフォームが提供するネットワークサービスを利用することができ、これは人々の生活にとって大きな利便性をもたらす。

ユーザは、上記のネットワークサービスを利用する過程において、自身のネットワークアカウントが漏洩や盗難の恐れがあることを察知すると、一般に、ネットワークサービスプロバイダへ損害報告要求を送るであろう。ネットワークサービスプロバイダは、ユーザのアイデンティティ（同一性）を確認した上で、ネットワークアカウントの損害報告を処理し、ユーザアカウントが盗用されるのを防ぐため、ネットワークアカウントを凍結することができる。その後、ユーザが、ネットワークサービスプロバイダへ損害報告の取り消し要求を送りさえすれば、ネットワークサービスプロバイダはユーザのアイデンティティを確認した上でネットワークアカウントの正常な利用を復元（リストア）する。

従来技術において、損害報告されたネットワークアカウントの損害報告は、一般的に以下の方法で取り消される。
ネットワークサービスプロバイダは、手動電話のプラットフォーム又はインスタントメッセージングサービスのプラットフォームを確立する。損害報告の取り消し要求をする際、ユーザは、電話又はインスタントメッセージングツールに限って顧客サービススタッフと通信が可能であるが、ユーザは、顧客サービススタッフが手動で確認するための種々の身分証明をアップロードしなくてはならない。顧客サービススタッフは、ユーザがアカウントの盗用者でないことを判断した後に、対応するネットワークアカウントの利用を復元する。

しかし、本願を実施する過程において、従来技術には少なくとも以下に述べる課題がある。
ネットワークアカウントの損害報告の取り消し処理において、ユーザは、以後、自身のネットワークアカウント及び対応するネットワークサービスを継続して利用できなくなり、ユーザのネットワークライフに悪影響が生じる。

本願の実施の形態の目的は、ネットワークサーバ上で損害報告されたアカウントにログインすることが可能な、損害報告されたアカウントのログイン方法及び装置を提供することにある。
上記の技術課題を解決するため、本願の実施の形態によって提供される損害報告されたアカウントのログイン方法は以下のように実行される。

損害報告されたアカウントのログイン方法は：
クライアント端末から送信される、操作コードを含むログイン要求を受信するステップと；
前記操作コードが予め設定された条件を満たすか否かを判定するステップと；
満たす場合、前記操作コードに対応する損害報告されたアカウントを取得するステップと；
ネットワークサーバ上で前記損害報告されたアカウントにログインするステップと；を備える。

上記の技術的課題を解決するため、本願の実施の形態によって提供される損害報告されたアカウントのログイン方法は以下のように実行される。

損害報告されたアカウントのログイン装置は：
クライアント端末から送信される、操作コードを含むログイン要求を受信するように構成された要求受付モジュールと；
前記操作コードが予め設定された条件を満たすか否かを判定するように構成された条件判定モジュールと；
前記操作コードが前記予め設定された条件を満たす場合、前記操作コードに対応する損害報告されたアカウントを取得するように構成されたアカウント取得モジュールと；
ネットワークサーバ上で前記損害報告されたアカウントにログインするように構成されたアカウントログインモジュールと；を備える。

本願の実施の形態において提供される技術的解決からは、以下のことが把握される。即ち、本願の実施の形態は、損害報告されたアカウントと関連付けられた操作コードを通してネットワークサーバ上における損害報告されたアカウントへログインすることにより、損害報告されたアカウントの損害報告の取り消し処理期間中であってもユーザが自身のアカウント及び対応するネットワークサービスを継続して利用することができ、これにより、ユーザのネットワークライフに悪影響が生じないことを保証する。

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

図１は、本願の実施の形態に係る損害報告されたアカウントのログイン方法の工程である。 図２は、本願の実施の形態に係る損害報告されたアカウントのログイン方法において操作コードを生成する具体的な工程である。 図３は、本願の実施の形態に係る損害報告されたアカウントのログイン方法において操作コードを送信する具体的な工程である。 図４は、本願の実施の形態に係る損害報告されたアカウントのログイン装置のモジュール図である。

本願の実施の形態は、損害報告されたアカウントのログイン方法及び装置を提供する。

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

従来技術において、ユーザのアイデンティティ情報の手動での確認により、損害報告されたアカウントの損害報告の取り消し処理が行われる間、ユーザは、損害報告されたアカウントを利用できない可能性がある。本願の実施の形態は、上記の課題を解決すべく損害報告されたアカウントのログイン方法を提供する。当該方法を、付帯の図面を参照して以下詳細に説明する。

図１は、本願の実施の形態に係る損害報告されたアカウントのログイン方法の工程である。
ネットワークサービスプロバイダ（提供者）によりインターネットを用いたネットワークサービスが提供される場合、即ち、ユーザによりクライアント端末がネットワークサーバと通信を確立した上でのみネットワークサービスが利用可能な場合、ログイン方法はネットワークサービスプロバイダのサーバによって実行されてもよい。例えば、ネットワークサービスプロバイダがオンライントランザクション（取引）のプラットフォームを提供し、本願の実施の形態において提供されるログイン方法は、オンライントランザクションのプラットフォームのネットワークサーバを用いて実行される。

ネットワークサービスプロバイダによって、ローカルエリアネットワークを用いたネットワークサービス又は単一の機器上で利用可能なネットワークサービスが提供される場合、即ち、ユーザによりクライアント端末がネットワークサーバと通信を確立せずともネットワークサービスが利用可能な場合、ログイン方法は、ユーザが保有するクライアント端末において、専用のオフラインアカウント（ローカルアカウント）ログインモジュールによって実行されてもよい。例えば、ネットワークサービスプロバイダはオフラインで利用可能なゲームのサービスを提供し、ユーザは単一の機器を用いてゲームのサービスを部分的に利用でき、本願の実施の形態において提供されるログイン方法は、そのゲームクライアント端末のオフラインアカウントログインモジュールを用いて実行される。

本願の実施の形態において、ログイン方法は以下の各ステップを含む。

Ｓ１１：操作コードを含むログイン要求がクライアント端末から取得される。
本願の実施の形態において、クライアント端末は携帯電話又はコンピュータ上の専用アプリであってもよく、ブラウザ上の関連するログインページであってもよく、更には銀行のＡＴＭ装置であってもよい。

ネットワークサービスプロバイダが提供するインターネットを用いたネットワークサービスを例にとれば、ユーザは、ユーザのネットワークアカウントに対して損害報告が行われる前は、自身のネットワークアカウントのアカウント名及びパスワードを、クライアント端末のアカウント名及びパスワード入力ウィンドウへ直接入力してもよい。その後、クライアント端末は入力したアカウント名及びパスワードをサーバへ送信する。受信したアカウント名及びパスワードの双方が正確であり合致することをサーバが確認した後、ユーザによって入力されたアカウントをログインに用いてもよい。

本願の実施の形態では、ユーザのネットワークアカウントに対して損害報告されているため、ユーザはクライアント端末上で自身のネットワークアカウントのアカウント名及びパスワードを入力してアカウントにログインすることができない。ユーザはクライアント端末上の元のアカウント名入力ウィンドウ又は新規操作コード入力ウィンドウへ操作コードを入力し、損害報告されたアカウントのログイン要求を送ってもよい。クライアント端末は、操作コードを含むログイン要求を取得すると、ログイン要求をネットワークサーバへ送信する。

当然ながら、ローカルエリアネットワークを用いたネットワークサービス又は単一の機器において利用可能なネットワークサービスがネットワークサービスプロバイダによって提供される場合、ステップＳ１１においてクライアント端末からログイン要求を取得するステップは、具体的には次のように実施される。即ち、クライアント端末のオフラインアカウントログインモジュールは、アカウント名及びパスワードを入力するように構成された、クライアント端末のアカウント入力モジュールから、ログイン要求を取得する。これについてここで詳細には説明しない。

本願の実施の形態において、操作コードは、ＱＲコード（登録商標）やランダム文字列など、種々のタイプのものであってもよい。ＱＲコード（登録商標）としての操作コードを例にとれば、ユーザは、クライアント端末上の元のアカウント名入力ウィンドウ又は新規操作コード入力ウィンドウに直接、都合に合わせてＱＲコード（登録商標）の画像をアップロードしてもよく、これによりユーザエクスペリエンスが大きく改善される。また、ランダムに生成された数字群としての操作コードを例にとれば、ＡＴＭ装置などのクライアント端末やテレフォンバンキングの電話プラットフォームなどを用いてもユーザは直接操作コードを入力できる。

図２を参照するに、本願の実施の形態において、操作コードは以下のように生成される。ユーザは操作コードを保持し、ログイン要求の際、操作コードを使用して自身のネットワークアカウントにログインし、これにより、ユーザは、損害報告期間内及び損害報告の取り消し処理期間内であっても自身のネットワークアカウントにログインできる。
操作コードを生成する具体的な工程は以下の各ステップを含む。

Ｓ２１：対象アカウント名を含むアカウント損害報告要求が取得される。
ユーザは、上記のネットワークサービスを利用する過程において、自身のネットワークアカウントが漏洩や盗難のおそれがあることを察知すると、クライアント端末上の損害報告ウィンドウ又は手動電話ウィンドウを介してサーバへアカウント損害報告要求を送ってもよい。また、アカウント損害報告要求は対象アカウント名を含んでいるため、ネットワークサーバは、損害報告を行う必要のあるユーザのアカウントを明確に認識できる。

Ｓ２２：対象アカウント名に対応するアカウントに対して損害報告される。
損害報告要求を送ったユーザのアイデンティティを確認した後、ネットワークサーバは対象アカウント名のアカウントを取得してもよく、アカウントに対して損害報告が実行される。損害報告がなされた後、アカウントはログインに利用できないため、ユーザのアカウントの安全性が保護される。

Ｓ２３：対象アカウント名に従って操作コードが生成される。
本願の実施の形態において、ネットワークサーバは予め設定されたアルゴリズムを用いて対象アカウント名を変換し一意の操作コードを得てもよい。

ネットワークサービスプロバイダがオンライントランザクションのプラットフォームを提供することを例にとれば、対象アカウント名はユーザによって自ら決められ、プラットフォーム上において一意である。対象アカウント名が一意であるため、予め設定されたアルゴリズムを用いて一意の操作コードを得ることができる。

予め設定されたアルゴリズムは、当分野における一般的な暗号化データ変換アルゴリズムであってもよく、異なる対象アカウント名に基づいて得られる操作コードが繰り返しにならないことを保証できるだけでよい。これに関する詳細な説明をここでは行わない。

当然ながら、本願の他の実施の形態においては、アカウントと操作コードは１対１の対応関係にあることに限定されない。複数のアカウントが同一の操作コードに関連付けられてもよい。例えば、ユーザが複数のアカウントを有しており、ユーザ機器が誤ってなりすましのウェブサイトにアクセスしたりトロイの木馬のウイルスに感染したりした際、ユーザの全てのアカウントが盗難される恐れがあり、その場合、ユーザの全てのアカウントに対して損害報告が行われ、ログイン環境が安全であることが確認されたならば、同一の操作コードを用いて全てのアカウントに対してログインしてもよい。これにより、ユーザが同時に複数の操作コードを記憶するという追加的な負荷が回避される。また、１つのアカウントを複数の操作コードと関連付けて、操作コードを忘れることのリスクを低減してもよい。これに関する詳細な説明はここでは行わない。

Ｓ２４：生成された操作コードが予め設定された操作コード表に記憶される。
操作コードを予め設定された操作コード表に記憶することにより、ユーザ及びネットワークサーバは都合に合わせてクエリ（問合せ）し操作コードを呼び出すことができる。

当然ながら、本願の他の実施の形態においては、ステップＳ２１〜Ｓ２３のみを用いて操作コードを得てもよい。ネットワークサーバがクライアント端末から操作コードを取得した後、予め設定されたアルゴリズムが、操作コードに対応する対象アカウント名を得るために逆に実行されてもよい。対象アカウント名が存在するか否かを対比することにより、操作コードがユーザの損害報告操作の間に生成されたものであるか否かを知ることができる。

図３を参照すると、本願の実施の形態においては、操作コードがユーザに以下のように送信されることにより、以後損害が報告されたアカウントに対するログイン要求があった場合、操作コードを用いてアカウントにログインできる。

Ｓ３１：対象アカウント名に対応するアカウントにおけるユーザのコンタクトアドレスが取得される。
ユーザのコンタクトアドレスは、登録時にユーザによって記入されたアカウントのデータをスクリーニングすることによって得られる。ユーザのコンタクトアドレスは、ユーザの携帯電話番号、ユーザの電子メールアドレス、ユーザのインスタントメッセージングアカウントの少なくとも１つを含んでもよい。

Ｓ３２：生成された操作コードがユーザのコンタクトアドレスへ送信される。
操作コードを生成し送信することによって、ユーザは、アカウントに対して損害報告を行った後で損害報告されたアカウントと関連付けられた操作コードを得てもよい。ユーザは操作コードを保持し、ログイン要求の際、操作コードを使用してアカウントにログインできる。

当然ながら、本願の他の実施の形態においては、操作コードは、上記したようにユーザへ送信されなくてもよく、その場合、直接ネットワークサーバに記憶される。ユーザは、自身のアカウント名を直接使用してネットワークサーバにクエリでき、それにより操作コードを得ることができる。

Ｓ１２：操作コードが予め設定された条件を満たすか否かが判定され、否定の場合はステップＳ１３が実行され、肯定の場合はステップＳ１４が実行される。
本願の実施の形態において、予め設定された条件は、操作コードが予め設定された操作コード表内にあることを含んでもよい。予め設定された操作コード表は上記のステップＳ２１〜Ｓ２４を用いて得られる。ネットワークサーバによって取得される操作コードが予め設定された操作コード表内に存在する場合は、操作コードがネットワークサーバによって生成されたものであること、即ち操作コードが関連付けられたアカウントを有することを示す。

当然ながら、上記したステップＳ２１〜Ｓ２３のみを用いて操作コードを生成する実施の形態においては、予め設定された条件が、操作コードに対応するアカウント名が予め設定されたアカウント名の表内にあること、に適合できるように調整されてもよい。即ち、アカウント名が登録されたアカウント名である場合、操作コードは予め設定された条件を満たすものと判定される。

本願の実施の形態において、予め設定された条件は、操作コードを用いる回数が予め設定された閾値回数内であるか否か、を更に含んでもよい。
予め設定された閾値回数は、ユーザの要求に応じて定義されてもよい。閾値は１に設定されてもよく、その場合、操作コードは一度用いられると自動的に無効となる。当然ながら、閾値は大きな数字に設定されてもよく、その場合、実際の操作において操作コードは制限なく用いることが可能となる。
当然ながら、操作コードを制限なく用いることが可能であることが予め設定されている場合は、操作コードを用いる回数が予め設定された閾値回数内であるか否かを判定するステップは実行しなくてもよい。これに関する詳細な説明はここでは行わない。

Ｓ１３：操作コードエラーのプロンプトが送信される。
取得した操作コードが予め設定された条件を満たさないことをネットワークサーバが明確に認識している場合、操作コードが正確に記入されているか否かの確認をユーザに気付かせるため、操作コードエラーのプロンプトがクライアント端末又はユーザのコンタクトアドレスへ送信される。

Ｓ１４：操作コードに対応する損害報告されたアカウントが取得される。
本願の実施の形態においては、操作コードを用いて予め設定されたアカウント名の表にクエリしてもよく、上記した予め設定されたアルゴリズムを逆に実行することにより操作コードに対応するアカウント名を得てもよい。それにより、対応する損害報告されたアカウントを得てもよい。

Ｓ１５：ネットワークサーバ上で損害報告されたアカウントがログインされる。
本願の実施の形態においては、ネットワークサーバは操作コードに従って予め設定されたアカウント許可を取得し、予め設定されたアカウント許可を用いて損害報告されたアカウントにログインする。

予め設定されたアカウント許可は、ユーザの要求に応じて予め設定されてもよい。予め設定されたアカウント許可は、例えば、アカウント損害報告の取り消し許可のみを含んでもよく、損害報告の取り消し許可に加えてクエリ許可などを含んでもよい。また、予め設定されたアカウント許可は、ユーザがアカウントを全面的に操作するよう、アカウントの全ての許可を開放するように設定されてもよい。

また、予め設定されたアカウント許可は、アカウントの重要度及びアカウントアクティビティに応じて設定されてもよい。例えば、高いアカウントアクティビティを有し頻繁にクエリ要求を行うＶＩＰユーザに対しては、アカウントクエリ許可を開放してもよい。低いアカウントアクティビティを有する一般的なユーザに対しては、アカウント損害報告の取り消し許可のみを開放する。

Ｓ１６：アカウントログイン情報が生成され、アカウントログイン情報はクライアント端末へ返信される。
アカウントログイン情報は、予め設定されたアカウント許可などのレギュラーデータタイプを含む。ネットワークサーバが損害報告されたアカウントにログインした後、クライアント端末もアカウントログイン情報を取得する。これにより、クライアント端末も損害報告されたアカウントにログインし、ユーザはクライアント端末で継続してネットワークサービスを受けることができる。

当然ながら、本願の他の実施の形態においては、ネットワークサーバ上での損害報告されたアカウントへのログイン、及びアカウントログイン情報の記憶は、上記のステップＳ１１〜Ｓ１５のみを用いて実行してもよい。クライアント端末は実行中の他のアプリケーションによってアカウントログイン情報を取得し、クライアント端末上でも損害報告されたアカウントにログインできる。これに関する詳細な説明はここでは行わない。

図４は本願の実施の形態に係る損害報告されたアカウントのログイン装置のモジュール図である。

ネットワークサービスプロバイダによりインターネットを用いたネットワークサービスが提供される場合、即ち、ユーザによりクライアント端末がネットワークサーバと通信を確立した上でのみネットワークサービスが利用可能な場合、ログイン方法はネットワークサービスプロバイダのサーバによって実行され得る。例えば、ネットワークサービスプロバイダは、オンライントランザクションのプラットフォームを提供し、本願の実施の形態によって提供されるログイン方法が、オンライントランザクションのプラットフォームのネットワークサーバを用いて実行される。

ネットワークサービスプロバイダによって、ローカルエリアネットワークを用いたネットワークサービス又は単一の機器上で利用可能なネットワークサービスが提供される場合、即ち、ユーザによりクライアント端末がネットワークサーバと通信を確立せずともネットワークサービスが利用可能な場合、ログイン方法は、ユーザにより保有されるクライアント端末において、専用のオフラインアカウントログインモジュールによって実行されてもよい。例えば、ネットワークサービスプロバイダはオフラインで利用可能なゲームのサービスを提供し、ユーザは単一の機器を用いてゲームのサービスを部分的に利用でき、本願の実施の形態において提供されるログイン方法は、そのゲームクライアント端末のオフラインアカウントログインモジュールを用いて実行される。

本願実施の形態において、ログイン装置は以下の各部を含む。

要求受付モジュール１１はクライアント端末から、操作コードを含むログイン要求を受信するように構成されている。
本願の実施の形態において、クライアント端末は携帯電話又はコンピュータ上の専用アプリであってもよく、ブラウザ上の関連するログインページであってもよく、更には銀行のＡＴＭ装置であってもよい。

ネットワークサービスプロバイダが提供するインターネットを用いたネットワークサービスを例にとれば、ユーザは、ユーザのネットワークアカウントに対して損害報告が行われていない場合、自身のネットワークアカウントのアカウント名及びパスワードをクライアント端末のアカウント名及びパスワード入力ウィンドウに直接入力してもよい。その後、クライアント端末は入力したアカウント名及びパスワードをサーバへ送信する。受信したアカウント名及びパスワードの双方が正確であり合致することをサーバが確認した上で、ユーザによって入力されたアカウントがログインに用いられてもよい。

本願の実施の形態においては、ユーザのネットワークアカウントに対して損害報告が行われている場合、ユーザはクライアント端末上で自身のネットワークアカウントのアカウント名及びパスワードを入力してアカウントにログインすることはできない。ユーザはクライアント端末上の元のアカウント名入力ウィンドウ又は新規操作コード入力ウィンドウに操作コードを入力し、損害報告されたアカウントのログイン要求を送ってもよい。クライアント端末は、操作コードを含むログイン要求を取得すると、ログイン要求をネットワークサーバへ送信する。

当然ながら、ローカルエリアネットワークを用いたネットワークサービス又は単一の機器において利用可能なネットワークサービスがネットワークサービスプロバイダによって提供される場合、要求受付モジュール１１によってクライアント端末からログイン要求を取得するステップは、具体的には次のように実施される。即ち、クライアント端末のオフラインアカウントログインモジュールは、アカウント名及びパスワードを入力するように構成された、クライアント端末のアカウント入力モジュールから、ログイン要求を取得する。これについてここで詳細な説明は行わない。

本願の実施の形態においては、操作コードは、ＱＲコード（登録商標）やランダム文字列など、種々のタイプのものであってよい。ＱＲコード（登録商標）としての操作コードを例にとれば、ユーザは、クライアント端末上の元のアカウント名入力ウィンドウ又は新規操作コード入力ウィンドウに直接、都合に合わせてＱＲコード（登録商標）の画像をアップロードしてもよく、これによりユーザエクスペリエンスが大きく改善される。また、ランダムに生成された数字群としての操作コードを例とれば、ＡＴＭ装置などのクライアント端末やテレフォンバンキングの電話プラットフォームなどを用いてもユーザは直接操作コードを入力できる。

本願の実施の形態においては、ログイン装置は、操作コードを生成するように構成された操作コード生成モジュール２０を含む。ユーザは操作コードを保持し、ログイン要求の際、操作コードを用いて自身のネットワークアカウントにログインし、これにより、ユーザは、損害報告及び損害報告の取り消し処理の期間であっても自身のネットワークアカウントにログインできる。

操作コード生成モジュール２０は、具体的には、先ず対象アカウント名を含むアカウント損害報告要求を取得するように構成されている。
ユーザは、上記のネットワークサービスを利用する過程において、自身のネットワークアカウントが漏洩や盗難の恐れがあることを察知すると、クライアント端末上の損害報告ウィンドウ又は手動電話ウィンドウを介してサーバへアカウント損害報告要求を送ってもよい。また、アカウント損害報告要求は対象アカウント名を含んでいるため、ネットワークサーバは、損害報告を行う必要のあるユーザのアカウントを明確に認識できる。

操作コード生成モジュール２０は、更に、対象アカウント名に対応するアカウントに対して損害報告を行うように構成されている。
損害報告要求を送ったユーザのアイデンティティを確認した後、ネットワークサーバは対象アカウント名のアカウントを取得してもよく、アカウントに対して損害報告が行われる。損害報告が行われた後、アカウントはログインに利用できないため、ユーザのアカウントの安全性が保護される。

操作コード生成モジュール２０は、その後、対象アカウント名に従って操作コードを生成するように構成されている。
本願の実施の形態においては、ネットワークサーバは予め設定されたアルゴリズムを用いて対象アカウント名を変換し一意の操作コードを得てもよい。

ネットワークサービスプロバイダがオンライントランザクションのプラットフォームを提供することを例にとれば、対象アカウント名はユーザによって自ら決められ、プラットフォーム上において一意である。対象アカウント名が一意であるため、予め設定されたアルゴリズムを用いて常に一意の操作コードを得ることができる。

予め設定されたアルゴリズムは、当分野における一般的な暗号化データ変換アルゴリズムであってもよく、相違する対象アカウント名に基づいて得られる複数の操作コードが反復しないことを保証できるだけでもよい。これに関する詳細な説明はここでは行わない。

当然ながら、本願の他の実施の形態においては、アカウントと操作コードは１対１の対応関係にあることに限定されない。複数のアカウントが同一の操作コードに関連付けられてもよい。例えば、ユーザは複数のアカウントを有しており、ユーザ機器が誤ってなりすましのウェブサイトにアクセスしたりトロイの木馬のウイルスに感染したりした際、ユーザの全てのアカウントが盗難される恐れがあり、その場合、ユーザの全てのアカウントに対して損害報告が行われ、ログイン環境が安全であることが確認されたならば、同一の操作コードを用いて全てのアカウントに対してログインしてもよい。これにより、ユーザが同時に複数の操作コードを記憶するという追加的な負荷が回避される。また、１つのアカウントを複数の操作コードと関連付けて、操作コードを忘れることのリスクを低減してもよい。これに関する詳細な説明はここでは行わない。

操作コード生成モジュール２０は、最終的に、生成した操作コードを予め設定された操作コード表に記憶するように構成されている。
操作コードを予め設定された操作コード表に記憶することにより、ユーザ及びネットワークサーバは都合に合わせてクエリし操作コードを呼び出すことができる。

当然ながら、本願の他の実施の形態においては、操作コード生成モジュール２０は上記した３つのステップのみを用いて操作コードを得てもよい。ネットワークサーバがクライアント端末から操作コードを取得した後、予め設定されたアルゴリズムが、操作コードに対応する対象アカウント名を得るために逆に実行されてもよい。対象アカウント名が存在するか否かを対比することにより、操作コードがユーザの損害報告操作の間に生成されたものであるか否かを知ることができる。

本願の実施の形態において、ログイン装置は更に操作コード送信モジュール３０を含む。操作コード送信モジュールは、操作コード生成モジュールが対象アカウント名に従って操作コードを生成した後、ユーザへ操作コードを送信するように構成されている。このため、以後、損害報告されたアカウントに対するログイン要求があった際、操作コードを用いてアカウントにログインできる。

先ず、対象アカウント名に対応するアカウントにおけるユーザのコンタクトアドレスを取得する。
ユーザのコンタクトアドレスは、登録時にユーザによって記入されたアカウントのデータをスクリーニングすることによって得られる。ユーザのコンタクトアドレスは、ユーザの携帯電話番号、ユーザの電子メールアドレス、ユーザのインスタントメッセージングアカウントの少なくとも１つを含んでもよい。
その後、生成された操作コードはユーザのコンタクトアドレスへ送信される。
コードを生成し送信することによって、ユーザは、アカウントに対して損害報告を行った後で、損害報告されたアカウントと関連付けられた操作コードを得てもよい。ユーザは操作コードを保持し、ログイン要求の際、操作コードを用いてアカウントにログインできる。

当然ながら、本願の他の実施の形態においては、操作コードは、上記したようにユーザへ送信されなくてもよく、その場合、直接ネットワークサーバに記憶される。ユーザは、自身のアカウント名を直接用いてネットワークサーバにクエリでき、それにより、その操作コードを得ることができる。

条件判定モジュール１２は操作コードが予め設定された条件を満たすか否かを判定するように構成されている。
本願の実施の形態において、予め設定された条件は、操作コードが予め設定された操作コード表内にあること含んでもよい。予め設定された操作コード表は操作コード生成モジュールによって得られる。ネットワークサーバによって取得される操作コードが予め設定された操作コード表内に位置する場合は、操作コードがネットワークサーバによって生成されたものであること、即ち操作コードが関連付けられたアカウントを有することを示す。

当然ながら、上記した３つのステップのみを用いて操作コード生成モジュールにより操作コードが生成される実施の形態では、予め設定された条件が、操作コードに対応するアカウント名が予め設定されたアカウント名の表内にあること、に適合できるように調整されてもよい。即ち、アカウント名が登録されたアカウント名である場合、操作コードは予め設定された条件を満たすものと判定される。

本願の実施の形態において、予め設定された条件は、操作コードを用いる回数が予め設定された閾値回数内であるか否か、を更に含んでもよい。
予め設定された閾値回数は、ユーザの要求に応じて定義されてもよい。閾値は１に設定されてもよく、その場合、操作コードは一度用いられると自動的に無効となる。当然ながら、閾値は大きな数字に設定されてもよく、その場合、実際の操作において操作コードは制限なく用いることが可能となる。
当然ながら、操作コードを制限なく用いることが可能であることが予め設定されている場合は、操作コードを用いる回数が予め設定された閾値回数内であるか否かを判定するステップは実行しなくてもよい。これに関する詳細な説明はここでは行わない。

エラープロンプトモジュール１３は、操作コードが予め設定された条件を満たさない場合に操作コードエラーのプロンプトを送信するように構成されている。
取得した操作コードが予め設定された条件を満たさないことをネットワークサーバが明確に認識している場合、操作コードが正確に記入されているか否かの確認をユーザにリマインドするため、操作コードエラーのプロンプトがクライアント端末又はユーザのコンタクトアドレスへ送信される。

アカウント取得モジュール１４は、操作コードが予め設定された条件を満たす場合、操作コードに対応する損害報告されたアカウントを取得するように構成されている。
本願の実施の形態においては、操作コードを用いて予め設定されたアカウント名の表にクエリしてもよく、上記した予め設定されたアルゴリズムを逆に実行することにより操作コードに対応するアカウント名も得てもよく、それにより、対応する損害報告されたアカウントを得てもよい。

アカウントログインモジュール１５は、ネットワークサーバ上で損害報告されたアカウントにログインするように構成されている。
本願の実施の形態において、ネットワークサーバは操作コードに従って予め設定されたアカウント許可を取得し、予め設定されたアカウント許可を用いて損害報告されたアカウントにログインする。

予め設定されたアカウント許可はユーザの要求に応じて予め設定されてもよい。予め設定されたアカウント許可は、例えば、アカウント損害報告の取り消し許可のみを含んでもよく、損害報告の取り消し許可に加えてクエリ許可などを含んでもよい。また、予め設定されたアカウント許可は、ユーザがアカウントを全面的に制御するよう、アカウントの全ての許可を開放するように設定されてもよい。

また、予め設定されたアカウント許可は、アカウントの重要度及びアカウントアクティビティに応じて設定されてもよい。例えば、高いアカウントアクティビティを有し頻繁にクエリ要求を行うＶＩＰユーザに対しては、アカウントクエリ許可を開放してもよい。低いアカウントアクティビティを有する一般的なユーザに対しては、アカウント損害報告の取り消し許可のみを開放する。

本願の実施の形態において、ログイン装置は、アカウントログイン情報を生成し、アカウントログイン情報をクライアント端末へ返信するように構成されたクライアント端末指示モジュール１６を更に含む。
アカウントログイン情報は、予め設定されたアカウント許可などのレギュラーデータタイプを含む。ネットワークサーバが損害報告されたアカウントにログインした後、クライアント端末もアカウントログイン情報を取得する。これにより、クライアント端末も損害報告されたアカウントにログインし、ユーザはクライアント端末で継続してネットワークサービスを受けることができる。

当然ながら、本願の他の実施の形態において、ネットワークサーバ上での損害報告されたアカウントへのログイン、及びアカウントログイン情報の記憶は、要求受付モジュール１１、条件判定モジュール１２、エラープロンプトモジュール１３、アカウント取得モジュール１４、アカウントログインモジュール１５のみを用いて実行してもよい。クライアント端末は実行中の他のアプリケーションによってアカウントログイン情報を取得し、クライアント端末上でも損害報告されたアカウントにログインできる。これに関する詳細な説明はここでは行わない。１９９０年代、技術の改良は、ハードウェアの改良（例えばダイオード、トランジスタ、スイッチなどの回路構造の改良）又はソフトウェアの改良（方法手順の改良）に明確に区分できた。しかし、技術の発展とともに、現在の多くの方法手順の改良はハードウェア回路構造の直接的な改良として理解することができる。設計者のほとんどは、改良した方法手順をハードウェア回路にプログラミングし、対応するハードウェア回路構造を得る。よって、方法手順の改良がハードウェアエンティティのモジュールによって実行できないと推定することはできない。例えば、ＰＬＤは（プログラマブルロジックデバイス）（例えば、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ））そのような集積回路であり、その論理関数はユーザによりプログラミングデバイスを通じて決定される。設計者は、チップのメーカが専用の集積回路チップ２を設計及び製造せずとも、自らデジタルシステムをＰＬＤに「集積」するためのプログラミングを行う。また、現在、プログラミングのほとんどは、手動で集積回路チップを製造する代わりに「論理コンパイラ」ソフトウェアを用いて実行される。このソフトウェアは、プログラムを開発及び作成するために用いられるソフトウェアコンパイラに類似しており、コンパイリングの前のオリジナルコードも、ＨＤＬ（ハードウェア記述言語）と呼ばれる特定のプログラミング言語を用いて作成する必要がある。ＨＤＬには、ＡＢＥＬ（Ａｄｖａｎｃｅｄ Ｂｏｏｌｅａｎ Ｅｘｐｒｅｓｓｉｏｎ Ｌａｎｇｕａｇｅ）、ＡＨＤＬ（Ａｌｔｅｒａ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、コンフルエンス（Ｃｏｎｆｌｕｅｎｃｅ）、ＣＵＰＬ（Ｃｏｒｎｅｌｌ Ｕｎｉｖｅｒｓｉｔｙ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅ）、ＨＤＣａｌ、ＪＨＤＬ（Ｊａｖａ（登録商標） Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、Ｌａｖａ、Ｌｏｌａ、ＭｙＨＤＬ、ＰＡＬＡＳＭ、ＲＨＤＬ（Ｒｕｂｙ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）など、多くのタイプがあり、中でもＶＨＤＬ（Ｖｅｒｙ−Ｈｉｇｈ−Ｓｐｅｅｄ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）及びＶｅｒｉｌｏｇ２が現在最も一般的に用いられている。当業者であれば、論理方法手順を実行するためのハードウェア回路が、上記した各ハードウェア記述言語を用いて方法手順を若干論理プログラミングしそれを集積回路にプログラミングするだけで、容易に得られるものであることは理解されよう。

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

上記の実施の形態で例示したシステム、装置、モジュール、又はユニットは、コンピュータチップ又はエンティティを用いて具体的に実行されもよく、特定の機能を有する製品によって実行されてもよい。

説明を容易にするために、装置を説明するときには、それぞれの説明のために機能的に種々のユニットに分割する。当然のことながら、本願が実施されるとき、ユニットの機能は、同一のソフトウェア又は複数のソフトウェア及び／又はハードウェアで実施されてもよい。

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

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

これらのコンピュータプログラム命令は、コンピュータ又は任意の他のプログラム可能なデータ処理デバイスを特定方法で作動するよう命令できるコンピュータで読取り可能なメモリに格納することもでき、コンピュータで読取り可能なメモリに格納された命令は、命令装置を含む製造物を生成する。この命令装置は、フローチャートの１つ以上の工程における、及び／又は、ブロック図の１つ以上のブロックにおける特定機能を実施する装置である。

これらのコンピュータプログラム命令は、コンピュータ又は別のプログラム可能なデータ処理端末デバイスにロードされて、一連の動作及びステップがコンピュータ又は別のプログラム可能な端末デバイス上で実行され、それによってコンピュータ実装処理を生成する。したがって、コンピュータ又は別のプログラム可能なデバイス上で実行される命令は、フローチャート内の１つ以上のプロセス及び／又はブロック図の１つ以上のブロックで特定の機能を実装するステップを提供する。

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

メモリは、読み出し専用メモリ（ＲＯＭ）又はフラッシュＲＡＭなどのコンピュータ可読媒体における、揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）及び／又は不揮発性メモリなどを含むことができる。メモリは、コンピュータ可読媒体の一例である。

コンピュータ可読媒体は、不揮発性及び揮発性媒体ならびに可動及び非可動媒体を含み、任意の方法又は技術によって情報記憶を実施することができる。情報は、コンピュータ可読命令、データ構造、及び、プログラム又は他のデータのモジュールであってもよい。コンピュータ記憶媒体は、例えば、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのＲＡＭ、ＲＯＭ、電気的消去再書込可能読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、又は他のメモリ技術、コンパクトディスク読取り専用メモリ（ＣＤ‐ＲＯＭ）、デジタル多目的ディスク（ＤＶＤ）、又は他の光学記憶装置、カセットテープ、磁気テープ／磁気ディスク記憶装置、又は他の磁気記憶装置、又は任意の他の非伝送媒体を非限定的に含み、コンピューティングデバイスによってアクセスされる情報を格納するために使用することができる。本明細書の定義によれば、コンピュータ可読媒体は、変調データ信号及び搬送波などの一時媒体を含まない。

用語「含む」、「備える」、又はこれらの他の派生形は、非排他的な包含をカバーすることを意図し、一連の要素を含む工程、方法、商品、デバイスは、要素を含むだけでなく、明確に示されていない任意の他の要素をも含むか、あるいは、その工程、方法、商品、デバイスに固有な要素を更に含む点にも留意されたい。さらなる限定のない場合に、表現「〜を含む（including a/an...）」によって定義される要素は、その要素を含む工程、方法、生産物、デバイスがその他の同じ要素を更に有することを除外するものではない。

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

本願は、コンピュータによって実行されるコンピュータ実行可能命令、例えば、プログラムモジュールの一般的な文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行したり、特定の抽象データ型を実装するために使用されるルーティング、プログラム、オブジェクト、アセンブリ、データ構造などを含む。本願は、分散コンピューティング環境でも実装することができ、分散コンピュータ環境では、通信ネットワークを介して接続されたリモート処理デバイスを使用してタスクを実行する。分散型コンピュータ環境では、プログラムモジュールは、記憶装置を含むローカル及びリモートのコンピュータ記憶媒体に配置されてもよい。

本明細書の様々な実施の形態は、進歩的な方法で説明されている。実施の形態間で同じ又は同様の部分は、互いに参照することができる。各実施の形態において、他の実施の形態とは異なる部分が重点的に記載されている。特に、装置の実施の形態は、方法の実施の形態と基本的に同様であるので、簡単に説明し、関連する部分については、方法の実施の形態における部分的な説明を参照することができる。

上記の説明は、本願の実施の形態に過ぎず、本願を限定するものではない。当業者であれば、本願は様々な変更および変形を有することができる。本願の精神および原理の範囲内でなされた任意の修正、均等物との置換、改良などは、すべて本願の特許請求の範囲に含まれるべきである。
［第１の局面］
損害報告されたアカウントのログイン方法であって：
クライアント端末から送信される、操作コードを含むログイン要求を受信するステップと；
前記操作コードが予め設定された条件を満たすか否かを判定するステップと；
満たす場合、前記操作コードに対応する損害報告されたアカウントを取得するステップと；
ネットワークサーバ上で前記損害報告されたアカウントにログインするステップと；を備える、
損害報告されたアカウントのログイン方法。
［第２の局面］
クライアント端末から送信されるログイン要求を受信する前記ステップの前に：
対象アカウント名を含むアカウント損害報告要求を取得するステップと；
前記対象アカウント名に対応するアカウントに対して損害報告を行うステップと；
前記対象アカウント名に従って操作コードを生成するステップと；を更に備える、
第１の局面に記載の方法。
［第３の局面］
前記対象アカウント名に従って操作コードを生成する前記ステップの後に：
前記対象アカウント名に対応する前記アカウントにおけるユーザのコンタクトアドレスを取得するステップと；
前記生成した操作コードを前記ユーザのコンタクトアドレスへ送信するステップと；を更に備える、
第２の局面に記載の方法。
［第４の局面］
前記ユーザのコンタクトアドレスは、ユーザの携帯電話番号、ユーザの電子メールアドレス、ユーザのインスタントメッセージングアカウントのうち少なくとも１つを含む、
第２の局面に記載の方法。
［第５の局面］
前記対象アカウント名に従って操作コードを生成する前記ステップは：
具体的に、予め設定されたアルゴリズムを用いて前記対象アカウント名を変換し、一意の操作コードを得るステップを備える、
第２の局面に記載の方法。
［第６の局面］
前記対象アカウント名に従って操作コードを生成する前記ステップの後に：
前記生成した操作コードを予め設定された操作コード表に記憶するステップを更に備える、
第２の局面に記載の方法。
［第７の局面］
前記予め設定された条件には、前記操作コードが予め設定された操作コード表内にあることが含まれる、
第１の局面に記載の方法。
［第８の局面］
前記予め設定された条件には、前記操作コードを用いる回数が予め設定された閾値回数内であることが含まれる、
第７の局面に記載の方法。
［第９の局面］
前記操作コードは、ＱＲコード（登録商標）を含む、
第１の局面に記載の方法。
［第１０の局面］
前記操作コードに対応する損害報告されたアカウントを取得する前記ステップは：
具体的に、前記操作コードに従ってアカウント表をクエリすることによって対応する損害報告されたアカウントを取得するステップを備える、
第１の局面に記載の方法。
［第１１の局面］
ネットワークサーバ上で前記損害報告されたアカウントにログインする前記ステップは：
前記操作コードに従って予め設定されたアカウント許可を取得するステップと；
前記予め設定されたアカウント許可を用いて前記ネットワーク上で前記損害報告されたアカウントにログインするステップと；を備える、
第１の局面に記載の方法。
［第１２の局面］
前記予め設定されたアカウント許可は、アカウント損害報告の取り消し許可を含む、
第１１の局面に記載の方法。
［第１３の局面］
ネットワークサーバ上で前記損害報告されたアカウントにログインする前記ステップの後に、前記アカウント損害報告取り消し方法は：アカウントログイン情報を生成し、前記アカウントログイン情報を前記クライアント端末へ返信するステップを更に備える、
第１の局面に記載の方法。
［第１４の局面］
損害報告されたアカウントのログイン装置であって：
クライアント端末から送信される、操作コードを含むログイン要求を受信するように構成された要求受付モジュールと；
前記操作コードが予め設定された条件を満たすか否かを判定するように構成された条件判定モジュールと；
前記操作コードが前記予め設定された条件を満たす場合、前記操作コードに対応する損害報告されたアカウントを取得するように構成されたアカウント取得モジュールと；
ネットワークサーバ上で前記損害報告されたアカウントにログインするように構成されたアカウントログインモジュールと；を備える、
損害報告されたアカウントのログイン装置。
［第１５の局面］
操作コード生成モジュールを更に備え、
前記要求受付モジュールが前記クライアント端末から送信される前記ログイン要求を受信する前に、前記操作コード生成モジュールは：
対象アカウント名を備えるアカウント損害報告要求を取得し、
前記対象アカウント名に対応するアカウントに対して損害報告を行い、
前記対象アカウント名に従って操作コードを生成するように構成された、
第１４の局面に記載の装置。
［第１６の局面］
操作コード送信モジュールを更に備え、
前記操作コード生成モジュールが前記対象アカウント名に従って前記操作コードを生成した後に、前記操作コード送信モジュールは：
前記対象アカウント名に対応する前記アカウントにおけるユーザのコンタクトアドレスを取得し、
前記生成した操作コードを前記ユーザのコンタクトアドレスへ送信するように構成された、
第１５の局面に記載の装置。
［第１７の局面］
前記ユーザのコンタクトアドレスは、ユーザの携帯電話番号、ユーザの電子メールアドレス、ユーザのインスタントメッセージングアカウントのうち少なくとも１つを含む、
第１５の局面に記載の装置。
［第１８の局面］
前記操作コード送信モジュールは、具体的に、予め設定されたアルゴリズムを用いて前記対象アカウント名を変換し、一意の操作コードを得るように構成された、
第１５の局面に記載の装置。
［第１９の局面］
操作コード記憶モジュールを更に備え、
前記操作コード生成モジュールが前記対象アカウント名に従って前記操作コードを生成した後に、
前記操作コード記憶モジュールは、前記生成した操作コードを予め設定された操作コード表に記憶するように構成された、
第１５の局面に記載の装置。
［第２０の局面］
前記予め設定された条件には、前記操作コードが予め設定された操作コード表内にあることが含まれる、
第１４の局面に記載の装置。
［第２１の局面］
前記予め設定された条件には、前記操作コードを用いる回数が予め設定された閾値回数内であることが含まれる、
第２０の局面に記載の装置。
［第２２の局面］
前記操作コードは、ＱＲコード（登録商標）を含む、
第１４の局面に記載の前記装置。
［第２３の局面］
前記アカウント取得モジュールは、具体的に、前記操作コードに従ってアカウント表をクエリすることによって対応する損害報告されたアカウントを取得するように構成された、
第１４の局面に記載の装置。
［第２４の局面］
前記アカウントログインモジュールは、具合的に：
前記操作コードに従って予め設定されたアカウント許可を取得し、
前記予め設定されたアカウント許可を用いて前記ネットワークサーバ上で前記損害報告されたアカウントにログインするように構成された、
第１４の局面に記載の装置。
［第２５の局面］
前記予め設定されたアカウント許可は、アカウント損害報告の取り消し許可を含む、
第２４の局面に記載の装置。
［第２６の局面］
クライアント端末ログイン指示モジュールを更に備え、
前記アカウントログインモジュールが前記ネットワークサーバ上で前記損害報告されたアカウントにログインした後に、前記クライアント端末ログイン指示モジュールはアカウントログイン情報を生成し、前記アカウントログイン情報を前記クライアント端末へ返信するように構成された、
第１４の局面に記載の装置。

Claims (14)

1. 損害報告されたアカウントへのログイン方法であって、前記ログイン方法は、ネットワークサーバによって実行され、前記ログイン方法は、
   前記損害報告されたアカウントを取得するために、ネットワークサーバ上のアカウントに対し損害報告を実行するステップであって、損害報告を実行する前記ステップは、前記損害報告されたアカウントの損害報告の取り消し処理期間中にアカウント名とパスワードの入力に基づいて、前記アカウントへのログインを無効にすることを含み、前記アカウントは、前記アカウント名と前記パスワードで登録されている、前記実行するステップと；
   クライアント端末からのログイン要求を受信するステップであって、前記ログイン要求は、前記損害報告されたアカウントに関連付けられた操作コードを含む、前記受信するステップ（Ｓ１１）と；
   前記操作コードが予め設定された条件を満たすか否かを判定するステップ（Ｓ１２）であって、前記操作コードが予め設定された条件を満たすか否かを判定する前記ステップは、前記操作コードが使用された回数が予め設定された回数の閾値内か否かを判定するステップを更に備え、前記閾値は１より大きい、前記判定するステップと；
   満たす場合、前記操作コードに対応する損害報告されたアカウントを取得し（Ｓ１４）、前記操作コードに従って、予め設定されたアカウント許可を取得するステップと；
   前記予め設定されたアカウント許可に基づいて、前記損害報告の取り消し処理期間中に前記ネットワークサーバ上で前記損害報告されたアカウントにログインするステップ（Ｓ１５）と；を備える、
   ログイン方法。
2. 前記損害報告されたアカウントに対し、アカウントログイン情報を生成するステップ（Ｓ１６）であって、前記アカウントログイン情報は、前記予め設定されたアカウント許可を含む、前記生成するステップと；
   前記クライアント端末に前記アカウントログイン情報を提供するステップと；を更に備える、
   請求項１に記載のログイン方法。
3. 前記アカウントログイン情報は、前記クライアント端末上のユーザインタラクションのために損害報告されたアカウントにログインするために使用される、
   請求項２に記載のログイン方法。
4. 前記操作コードは、前記クライアント端末上の操作コード入力ウィンドウを介して提供される、
   請求項３に記載のログイン方法。
5. ネットワークサーバ上のアカウントに対し、損害報告を実行する前記ステップは：
   アカウント損害報告要求を取得するステップであって、前記損害報告要求は、前記損害報告されたアカウントの前記アカウント名を備える、前記取得するステップ（Ｓ２１）と；
   前記アカウント名に従って、前記操作コードを生成するステップ（Ｓ２３）と；を更に備える、
   請求項１に記載のログイン方法。
6. 前記アカウント名に従って、前記操作コードを生成する前記ステップの後に、
   前記ログイン方法は；
   前記アカウント名に対応するアカウントに関連付けられたユーザのコンタクトアドレスを取得するステップ（Ｓ３１）と；
   前記生成した操作コードを前記ユーザのコンタクトアドレスへ送信するステップ（Ｓ３２）と；を更に備える、
   請求項５に記載のログイン方法。
7. 前記ユーザのコンタクトアドレスは、ユーザの携帯電話番号、ユーザの電子メールアドレス、ユーザのインスタントメッセージングアカウントのうち少なくとも１つを含む、
   請求項６に記載のログイン方法。
8. 前記アカウント名に従って、前記操作コードを生成する前記ステップは：
   前記操作コードを得るために、予め設定されたアルゴリズムに従って前記アカウント名を変換するステップであって、前記生成された操作コードは、前記ネットワークサーバのオンライントランザクションのプラットフォームで一意に定義される、前記変換するステップ：を備える、
   請求項５に記載のログイン方法。
9. 前記アカウント名に従って、前記操作コードを生成する前記ステップの後に、
   前記ログイン方法は：
   前記生成した操作コードを予め設定された操作コード表に記憶するステップ（Ｓ２４）；を更に備える、
   請求項５に記載のログイン方法。
10. 前記損害報告されたアカウントのアカウント名を含むクエリ要求を受信するステップと；
    前記アカウント名に基づいて、前記損害報告されたアカウントの操作コードを取得するステップと；
    前記クライアント端末のユーザに前記操作コードを提供するステップと；を更に備える、
    請求項１に記載のログイン方法。
11. 前記予め設定された条件には、前記操作コードが予め設定された操作コード表内にあることが含まれる、
    請求項１に記載のログイン方法。
12. 前記操作コードに対応する、前記損害報告されたアカウントを取得する前記ステップは：
    前記対応するアカウント名を以下のいずれかのステップにより取得するステップを備える、
    前記操作コードに従ってアカウント名の表をクエリするステップであって、前記アカウントの表は、前記ネットワークサーバのアカウントの登録されたアカウント名と対応する操作コードを含む、前記クエリするステップ；又は、
    前記対応する損害報告されたアカウントを取得するために、前記操作コードに予め設定されたアルゴリズムを逆に実行するステップ；
    請求項４に記載のログイン方法。
13. 前記予め設定されたアルゴリズムは、前記アカウント名に従って、前記操作コードを生成する場合に実行される、
    請求項８又は請求項１２に記載のログイン方法。
14. 請求項１〜１３のいずれか１項に記載の方法に係るステップを実行するように構成された、複数のモジュールを備える、
    損害報告されたアカウントへのログイン装置。

Images