JP2019050020A - ログイン名が競合する場合にユーザアカウントを管理するための方法、装置、およびシステム - Google Patents

Abstract

【課題】ユーザアカウントを管理するための方法およびシステムを提供する。【解決手段】現ユーザから、ログイン名主要部を含む登録要求を受信し、登録要求と関連付けて受信されたログイン名主要部と同じ競合するログイン名主要部を有する別のユーザに相当する旧ユーザがデータベース内に存在するかどうかを決定し、競合する旧ユーザが存在する場合に、競合する旧ユーザに関係付けられたログインパスワードとは異なるログインパスワードを登録することをユーザに要求するログインパスワード差別化プロセスを実行し、異なるログインパスワードを現ユーザの登録と関連付けてデータベースに格納する。【選択図】図２

Description

［関連技術の相互参照］
本出願は、２０１４年５月６日に出願され名称を「Ａ ＭＥＴＨＯＤ ＡＮＤ Ａ ＤＥＶＩＣＥ ＦＯＲ ＵＳＥＲ ＡＣＣＯＵＮＴ ＭＡＮＡＧＥＭＥＮＴ（ユーザアカウント管理のための方法およびデバイス）」とする中国特許出願第２０１４１０１８８４３０．０号の優先権を主張する。この出願は、あらゆる目的のために、参照によって本明細書に組み込まれる。

本出願は、インターネット技術の分野に関し、特に、ユーザアカウント管理のための方法、ユーザアカウント管理に関係するデバイス、およびユーザアカウント管理に関係するシステムに関する。

現在、インターネットと関連付けて使用される多くのアプリケーションおよび従来のメディアタイプのアプリケーションでは、ユーザ参加のために、特定の身元が要求される。一部の関連技術にしたがった例として、電子商取引やソーシャルネットワーキングのアプリケーションが挙げられる。一部の関連技術にしたがって、ユーザは、このようなアプリケーションにアカウントを登録する。アプリケーション（例えば、アプリケーションに関係付けられたサーバ）へのログインは、ログイン名（「ログインＩＤ」とも呼ばれる）およびログインパスワードによって実現されるのが一般的である。大半のアプリケーションでは、ログイン名は、英数字文字列（Ｔｅｎｃｅｎｔによって発行されているＱＱ番号など）、ニックネーム、またはメールボックス名であるのが一般的である。その他のアプリケーションでは、ログイン名として携帯電話番号が使用できる。

アプリケーションまたはアプリケーションに関係付けられたシステムと関連付けて使用されるログイン名の形態に寄らず、サービスを提供するシステムの大半は、そのシステムにおけるログイン名の一意性に関与する制御メカニズムを有するサービスを提供する。携帯電話番号ログイン名を一例として取り上げると、二重発行された番号の問題は、システムにおけるログイン名の一意性の制御要件と、ユーザエクスペリエンスとの間に矛盾を招く。番号の二重発行は、以下のプロセスを言う。即ち、携帯電話番号の元のユーザが、自身のアカウントを取り消して、その携帯電話番号を放棄した後、その携帯電話番号は、通信事業会社によって回収され、結果として新しいユーザに割り当てられる。電話番号が二度目に発行された後、新しいユーザは、その携帯電話番号では特定のアプリケーションに登録できないという問題に直面する。例えば、携帯電話番号の旧ユーザが、Ａｌｉｐａｙアカウントに登録するためにその電話番号を使用した。したがって、新ユーザが、Ａｌｉｐａｙアカウントに登録するためにこの携帯電話番号を使用すると、Ａｌｉｐａｙサービスシステムは、ログイン名の競合を発見し、競合が解決されるまで一時的に登録を拒絶する。また、もし、旧ユーザが、自身の連絡先情報（例えば、ユーザに連絡をとることができる携帯電話番号の表示）を速やかに変更しないと、業務上のメッセージまたはセキュリティ認証のためのメッセージがユーザの登録電話番号に送信され、その電話番号の新ユーザによって受信されるという問題が起きる恐れがある。したがって、二重発行された電話番号は、ユーザエクスペリエンスを低下させる恐れがあるうえに、セキュリティ上のリスクをもたらす恐れもある。

インターネットの発展に伴って、二重発行された電話番号に関係した問題は、携帯電話番号に限られず、メールボックス、ＱＱ番号、およびその他の技術分野との関係においても直面する恐れがある。例えば、ＱＱ番号の転送は、ＱＱ番号の二重発行を招く恐れがある。別の例として、大規模なＷｅｂｍａｉｌサービスプロバイダは、長期にわたってアイドル状態にあったメールアカウントを回収し、回収されたそれらのメールアカウントを新ユーザの登録に利用可能にすることを頻繁に行う。したがって、二重発行されたユーザ識別子（例えば、二重発行された番号）に関係した問題は、インターネットのアプリケーションに広く拡散している。

現在、二重発行された電話番号に関係した上述の問題に対する解決策は、主に、マニュアル対応に依存している。例えば、携帯電話番号の新ユーザが、Ａｌｉｐａｙのマニュアルカスタマサービスを探し出し、自身がその携帯電話番号の正当な（例えば、合法な）所有者であることを証明する。一部の関連技術にしたがうと、アプリケーションと関連付けて配備されるカスタマサービスシステムは、携帯電話番号の元のユーザによってシステムに未だ格納されている携帯電話番号を変更するために、バックグラウンド処理を必要とする。カスタマサービスシステムは、このような処理を使用して、携帯電話番号を切り離すことができる。携帯電話番号の切り離し後、その携帯電話番号は、システム内に存在しなくなる（例えば、ユーザ登録されていなくなる）。こうして、新ユーザによる携帯電話番号の使用は、一意性の制御要件を満たすようになる。したがって、新ユーザに関係付けられた携帯電話番号の登録が成功する。

二重発行された電話番号に関係した問題を解決するための、マニュアル処理による現手法には、大きな欠点がある。第１に、このようなマニュアル処理は、人件費が高くつく。ＴａｏｂａｏやＳｉｎａ Ｗｅｉｂｏなどの大規模なインターネットアプリケーションでは、ユーザ数が膨大であり、二重発行された番号も相当な量に及ぶ。このような多数のユーザおよび二重発行番号などをマニュアルで処理して問題を解決するために必要な人数を雇用することは、費用効果的ではない。第２に、マニュアル処理は、ユーザエクスペリエンスを悪化させる。マニュアルカスタマサービスは、携帯電話番号の新ユーザに、その携帯電話番号を新ユーザが正当に（例えば、合法に）所有していることを証明するための様々な証拠を提供するように要求するのが一般的である。このような要求がさらに多くの作業要件をユーザに課すことは、疑いようもない。第３に、マニュアル処理では、マニュアルカスタマサービスによる情報のチェックおよび処理の実施に長い時間がかかる。ユーザは、速やかに登録を行うことができない。第４に、旧ユーザのアカウント内の携帯電話番号をどのように適切に修正するかの課題もまた、さらなるマニュアル労力を要する別の問題である。

本発明の様々な実施形態が、以下の詳細な説明および添付の図面で開示される。

本発明の様々な実施形態にしたがった、ユーザアカウント管理デバイスの論理構造およびハードウェア環境の構造ブロック図である。

本出願の様々な実施形態にしたがった、ユーザアカウント管理のための方法のフローチャートである。

本出願の様々な実施形態にしたがった、ログインパスワード差別化プロセスのための誘導プロセスフローに関係したインターフェースの図である。

本出願の様々な実施形態にしたがった、ログインパスワード差別化プロセスのための誘導プロセスフローに関係したインターフェースの図である。

本出願の様々な実施形態にしたがった、ログインパスワード差別化プロセスのための誘導プロセスフローに関係したインターフェースの図である。

本出願の様々な実施形態にしたがった、ユーザの携帯電話番号を修正するようにユーザを誘導するための方法のフローチャートである。

本出願の様々な実施形態にしたがった、ログインパスワード回復に関係したインターフェースの図である。

本出願の様々な実施形態にしたがった、ユーザアカウント管理のためのシステムの構造ブロック図である。

本開示の様々な実施形態にしたがった、オブジェクトのシミュレーションシステムを動作させるためのコンピュータシステムの機能図である。

本発明は、プロセス、装置、システム、合成物、コンピュータ読み取り可能ストレージ媒体に実装されたコンピュータプログラム製品、ならびに／または接続先のメモリに格納された命令および／もしくは接続先のメモリによって提供される命令を実行するように構成されたプロセッサ等のプロセッサを含む、数々の形態で実現できる。本明細書では、これらの実現形態、または本発明がとりえるその他のあらゆる形態が、技術と称されてよい。総じて、開示されるプロセスのステップの順番は、本発明の範囲内で変更されてよい。別途明記されない限り、タスクを実施するように構成されるものとして説明されるプロセッサまたはメモリなどのコンポーネントは、所定時にタスクを実施するように一時的に構成される汎用コンポーネントとして、またはタスクを実施するように製造された特殊コンポーネントとして実装されてよい。本明細書で使用される「プロセッサ」という用語は、コンピュータプログラム命令などのデータを処理するように構成された１つ以上のデバイス、回路、および／または処理コアを言う。

本発明の原理を例示した添付の図面とともに、以下で、本発明の、１つまたは複数の実施形態の詳細な説明が提供される。本発明は、このような実施形態に関連して説明されるが、いずれの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定され、本発明は、数々の代替形態、変更形態、および均等物を包含している。以下の説明では、本発明の完全な理解を与えるために、数々の具体的詳細が明記されている。これらの詳細は、例示を目的として提供されるものであり、本発明は、これらの詳細の一部または全部を伴うことなく特許請求の範囲にしたがって実施されてよい。明瞭を期するために、本発明に関係する技術分野で知られる技工物は、本発明が不必要に不明瞭にされないように、詳細には説明されていない。

本開示の様々な実施形態は、ユーザアカウントを管理するための方法、装置、およびシステムを含む。例えば、これらの方法、装置、およびシステムは、ユーザ識別子の登録、ユーザ識別子に関係付けられたユーザの照合、特定のユーザ識別子に関係付けて登録されたユーザのアップデートなどに関連して使用できる。本明細書で言うユーザ識別子は、電話番号（例えば、携帯電話番号）、メールボックス（例えば、電子メールアカウント）、ユーザ名、ＱＱ番号などを指すことができる。

デバイスは、総じて、（例えば、ユーザによって、）ネットワークシステムにおいて１つまたは複数のサーバと通信するために使用される機器を言う。本開示の様々な実施形態にしたがうと、デバイスは、通信機能を含んでいてよい。例えば、デバイスは、スマートフォン、タブレットパソコン（ＰＣ）、携帯電話、ビデオ電話、電子ブックリーダ、デスクトップＰＣ、ラップトップＰＣ、ネットブックＰＣ、携帯情報端末（ＰＤＡ）、携帯マルチメディアプレーヤ（ＰＭＰ）、ｍｐ３プレーヤ、モバイル医療機器、カメラ、着用可能機器（例えば、頭部装着型デバイス（ＨＭＤ）、電子衣服、電子ブリッジ、電子ネックレス、電子アクセサリ、電子タトゥ、またはスマートウォッチ）などであってよい。

本開示の、一部の実施形態にしたがうと、デバイスは、通信機能を持つスマート家電を含む。スマート家電は、例えば、テレビ、デジタルビデオディスク（ＤＶＤ）プレーヤ、オーディオ機器、冷蔵庫、エアコン、掃除機、オーブン、電子レンジ、食洗器、ドライヤ、空気清浄機、セットトップボックス、ＴＶボックス（例えば、Ｓａｍｓｕｎｇ ＨｏｍｅＳｙｎｃ（商標）、Ａｐｐｌｅ ＴＶ（商標）、またはＧｏｏｇｌｅ ＴＶ（商標））、ゲーム機、電子辞書、電子キー、カムコーダ、電子フォトフレームなどであることができる。

本開示の様々な実施形態にしたがうと、デバイスは、上記デバイスの任意の組み合わせであることができる。また、当業者にならば、本開示の様々な実施形態にしたがったデバイスが上記デバイスに限られないことが明らかである。

一部の実施形態にしたがって、二重発行されたユーザ識別子に関係した問題、即ち登録の競合およびユーザエクスペリエンスの低下が解決され、アプリケーションシステムおよび対応する処理フローの内部でどのようにデータが編成されるかが改善される。

表１を参照すると、一部の実施形態では、システムの各ユーザのアカウント情報を記録するアカウントテーブルは、ログイン名フィールド（例えば、表１のフィールド１）を含む。ログイン名フィールドは、ログイン名主要部に加えて、１つまたは複数のパラメータを含むことができる。パラメータは、ログイン名フィールド内での各エントリの一意性を保証するために使用できる。一例として、パラメータは、アカウント記録内のログイン名フィールドのデータがアプリケーションシステムのデータベーステーブル内で一意であるようにするために使用できる。一部の実施形態では、パラメータは、競合識別パラメータを含むことができる。競合識別パラメータは、ログイン名フィールドに登録されたまたはそれ以外の形で格納されたログイン名データの一意性を保証するために使用できる。一部の実施形態では、ログイン名フィールドに登録されたログイン名データのログイン名主要部は、繰り返しが可能である（そして、ログイン名フィールドに格納されたログイン名データは、そのログイン名フィールドに格納されたその他のログイン名データとの関係において依然として一意であることができる）。ログイン名主要部は、ログイン識別子（例えば、ログイン試行と関連付けてユーザによってエントリされる識別子）に相当することができる。例えば、ログイン識別子は、１つまたは複数の英数字または特殊文字を含む文字列であることができる。ログイン識別子は、ユーザの電話番号に相当することができる。ユーザの視点からすると、ユーザは、引き続きログイン名主要部をログイン名だと見なすことができる。別の言い方をすると、ユーザは、ログイン名フィールドのデータ構造の変化を認識する必要がない。例えば、一部の実施形態では、ユーザは、ログイン名データの一意性を保証するために使用されるパラメータ（例えば、競合識別パラメータ）をエントリするまたはそれ以外の形で認識することを要求されることなしに、ログイン名主要部をログイン名として使用してアプリケーションシステムのサーバとやり取りすることができる。実際は、ユーザがログイン名だと見なしているログイン名主要部は、実は、システムではログイン名主要部である。一部の実施形態では、システムにおいて、ログイン名主要部は、ログイン名データそれ自体であってよい、またはログイン名主要部は、ログイン名データの一部に過ぎないかもしれない。

表１を見ると、第１のユーザ（例えば、Ｋｅｖｉｎ）は、ログイン名としてのユーザ識別子（例えば、携帯電話番号）１８６１１１８０７５１に関係付けて登録可能である。システムにおいて、ユーザアカウント記録のログイン名フィールド内のログイン名データは、「１８６１１１８０７５１」である。しかしながら、第２のユーザ（例えば、Ｔｏｎｙ）もまた、ユーザ識別子（例えば、携帯電話番号）１８６１１１８０７５１をログイン名として使用できる。このシステムでは、ユーザＴｏｎｙのためのユーザアカウント記録のログイン名フィールド内のログイン名データは、「１８６１１１８０７５１｜Ｒ」である。ユーザＴｏｎｙのためのアカウント記録に含まれる文字「Ｒ」は、競合識別パラメータに相当する。競合識別パラメータは、存在する競合のタイプにしたがって選択できる。競合識別パラメータは、英数字または特殊文字であることができる。一部の実施形態では、このようにログイン名データを編成することによって、システムデータベース内でのログイン名の一意性が保証される。

一部の実施形態では、システムのユーザエクスペリエンスを向上させるサービスが、データの編成に基づいて提供可能である（例えば、システムにログインするためにユーザによって使用されるユーザ名識別子が、複数回にわたってエントリされており、データベースに格納されているデータ間の一意性を保証するために、それらのユーザ識別子にパラメータが追加される形でログイン名データが格納される）。この例では、ログイン名フィールドは、「｜」（垂直線）、「 」（空白）、「，」（カンマ）等などのあらかじめ定められた仕切り文字をさらに含む。あらかじめ定められた仕切り文字は、一意性を保証するために使用される１つまたは複数のパラメータの一部であることができる。一部の実施形態では、あらかじめ定められた仕切りは、ユーザ識別子（例えば、ログイン名）と、一意性を保証するために使用される１つまたは複数のパラメータとの間の区切りとして機能できる。一部の実施形態では、あらかじめ定められた仕切り文字の導入（例えば、使用）は、業務上の拡張性を考慮したものであり、ただし、必ずしも必要な選択肢ではない。例えば、中国大陸地域では、全ての携帯電話番号が１１桁である。中国大陸地域に業務が集中しているサービスプロバイダの場合、システムは、携帯電話番号の長さにしたがって携帯電話番号を競合識別パラメータから区別でき、それによって携帯電話番号および競合識別パラメータを精確に決定できるので、実行プロセスにおいて仕切り文字を導入する必要はない。しかしながら、携帯電話番号の桁数は、様々な国／地域間で異なるので、より多くの国／地域にサービスを提供しているサービスプロバイダは、ログイン名主要部と競合識別パラメータとの差別化を助けるために、ログイン名主要部と競合識別パラメータとの間に仕切り文字を導入できる。

一部の実施形態では、上述されたデータ編成構造の変化に基づくソフトウェア実装にしたがって、ユーザアカウント管理デバイスおよび対応する管理方法が使用できる。

図１は、本発明の様々な実施形態にしたがった、ユーザアカウント管理デバイスの構造ブロック図およびハードウェア環境である。

図１を参照すると、ユーザアカウント管理デバイス１００が提供されている。一部の実施形態では、ユーザアカウント管理デバイス１００は、図２の方法２００を実行するために使用される。一部の実施形態では、ユーザ管理デバイス１００は、図３Ａのインターフェース３００を実現するために使用される。一部の実施形態では、ユーザ管理デバイス１００は、図３Ｂのインターフェース３５０を実現するために使用される。一部の実施形態では、ユーザ管理デバイス１００は、図４の方法４００を実行するために使用される。一部の実施形態では、ユーザ管理デバイス１００は、図５のインターフェース５００を実現するために使用される。一部の実施形態では、ユーザ管理デバイス１００は、図６のシステム６００に実装される。

一部の実施形態では、ユーザアカウント管理デバイス１００は、サーバ上で動作する論理デバイスとして実装できる。一部の実施形態では、ユーザ管理デバイス１００は、プロセッサ１１０と、メモリ１２０と、不揮発性ストレージ１３０とを含む。ユーザ管理デバイス１００は、その他のハードウェア１４０も含むことができる。例えば、その他のハードウェア１４０は、業務上のサービスに必要とされるその他のハードウェアを含むことができる。

プロセッサ１１０は、対応するコンピュータプログラム（例えば、一連の命令）を不揮発性ストレージからメモリへ受信して実行できる。一部の実施形態では、ユーザ管理デバイス１００は、（サーバの）論理層に実装される。一部の実施形態では、ユーザ管理デバイス１００は、論理システムの外部サービスの一部（例えば、Ａｌｉｐａｙサービスシステムの外部サービスの一部）であることができる。一部の実施形態では、ユーザ管理デバイス１００は、論理デバイスとしてまたはソフトウェア／ハードウェアの組み合わせとして実装される。別の言い方をすると、管理方法のプロセスフローを実行するエンティティは、各種の論理ユニットに限定されない。管理方法を実行するエンティティは、ハードウェアまたは論理デバイスであることもできる。

一部の実施形態では、ユーザ管理デバイス１００は、事前設定チェックモジュール１２１と、登録モジュール１２３と、特別登録モジュール１２５と、ログイン管理モジュール１２７とを含む。ユーザ管理デバイス１００は、パスワード回復モジュール１２９を含むことができる。一部の実施形態では、事前設定チェックモジュール１２１、登録モジュール１２３、特別登録モジュール１２５、ログイン管理モジュール１２７、およびパスワード回復モジュール１２９は、メモリ（例えば、メモリ１２０）に格納されて１つまたは複数のプロセッサによって実行可能な命令群として実装できる。

図２は、本出願の様々な実施形態にしたがった、ユーザアカウント管理のための方法のフローチャートである。

図２を見ると、ユーザアカウント管理のための方法２００が提供されている。一部の実施形態では、方法２００は、図１のデバイス１００によって実行できる。一部の実施形態では、方法２００は、図６のシステム６００によって実行できる。一部の実施形態では、方法２００は、図３Ａのインターフェース３００、図３Ｂのインターフェース３５０、または図３Ｃのインターフェース３６０を実現できる。

２０１では、ログイン名主要部が取得される。一部の実施形態では、ログイン名主要部は、登録要求（アプリケーションシステムへの登録を求める要求）と関連付けて取得される。サーバは、ユーザ（例えば、アプリケーションシステムへの登録を試みているユーザ）によって使用されているデバイスからログイン名主要部を取得できる。一部の実施形態では、ログイン名主要部は、ユーザ識別子に相当する。一部の実施形態では、ユーザ管理デバイス１００の事前設定チェックモジュール１２１が、現ユーザから受信された登録要求と関連付けてログイン名主要部を取得する。

２０２では、ログイン名主要部に一致する記録を求めて登録群の検索が行われる。一部の実施形態では、サーバは、ログイン名主要部に一致する記録を求めて登録群（例えば、記録群）の検索を行う。例えば、サーバは、取得されたログイン名主要部に一致する記録を求めてデータベースを検索できる。データベースは、アプリケーションシステムに登録されたユーザ識別子の記録を格納できる。一部の実施形態では、データベースは、アカウントテーブルを含む。取得されたログイン名主要部が登録群に含まれる場合は、取得されたログイン名主要部は、取得されたログイン名主要部に関係付けられた既存の登録と競合する。取得されたログイン名主要部が登録群に含まれない場合は、取得されたログイン名主要部は、既存の登録（例えば、既存の記録）と競合しない。一部の実施形態では、ユーザ管理デバイス１００の事前設定チェックモジュール１２１が、ログイン名主要部に一致する記録を求めてアカウントテーブルを検索する。

２０３では、登録群内にログイン名主要部が存在するかどうかの決定が下される。例えば、サーバは、ログイン名主要部に一致する既存の記録が登録群に含まれるかどうかを決定する。取得されたログイン名主要部が登録群に含まれる場合は、方法２００は、２０５に進むことができる。そうではなく、取得されたログイン名主要部が登録群に含まれない場合は、方法２００は、２０４に進むことができる。一部の実施形態では、競合する旧ユーザがログイン名主要部を使用しているかどうかを決定するために、ユーザ管理デバイス１００の事前設定チェックモジュール１２１が、ログイン名主要部に一致する記録を求めてアカウントテーブルを検索する。

２０４では、ログイン名主要部に基づいて、現ユーザの登録に関係付けられたユーザ記録が作成される。一部の実施形態では、サーバは、取得されたログイン名主要部を使用して登録（例えば、記録）を作成する。少なくとも部分的にログイン名主要部に基づく登録は、（例えば、別のユーザの登録と関連付けた）ログイン名主要部の登録（例えば、記録）が登録群（例えば、登録ユーザまたは登録ユーザ識別子のデータベース）に含まれないとの決定を受けて作成できる。一部の実施形態では、ユーザ管理デバイス１００の登録モジュール１２３が、取得されたログイン名主要部に関する登録を作成できる。登録は、ユーザ識別子、パスワード、生年月日情報、性別情報、好きな数字情報、好きな色情報等、またはそれらの任意の組み合わせを示す、フィールドを含むことができる。ユーザ識別子は、ログイン名主要部などを含むことができる。一部の実施形態では、登録は、アカウントテーブルに格納できる。

２０５では、ログインパスワード差別化プロセスが実行できる。一部の実施形態では、サーバは、既存の登録プロセスからログインパスワード差別化プロセスを呼び出すことができる。一部の実施形態では、プロセスは、少なくとも部分的に取得されたログイン名主要に基づいて、その取得されたログイン名主要部に一致するログイン名主要部を使用している既存の登録から差別化されるように登録を作成できる。既存の登録プロセスに関係付けられたログインパスワード差別化プロセスは、（例えば、別のユーザの登録と関連付けた）ログイン名主要部の登録（例えば、記録）が登録群（例えば、登録ユーザまたは登録ユーザ識別子のデータベース）に含まれるとの決定を受けて呼び出せるまたはそれ以外の形で実行できる。一部の実施形態では、ユーザ管理デバイス１００の特別登録モジュール１２５が、ログイン名主要部の登録が登録群に含まれるとの決定を受けてアクティブ化される。ユーザ管理デバイス１００の特別登録モジュール１２５は、既存の登録プロセスからログインパスワード差別化プロセスを実行できる。ユーザ管理デバイス１００の特別登録モジュール１２５は、（例えば、ログイン名主要部の取得と関連付けて受信された）現ユーザからの登録要求を受けて、ログインパスワード差別化プロセスのための誘導プロセスフローをアクティブ化し、取得されたログイン名主要部に一致する記録に関係付けられた競合する旧ユーザによって使用されているパスワードとは異なるログインパスワードを使用するように現ユーザを誘導できる。

２０６では、ログイン名主要部に関係付けられたユーザ登録が成功したと決定される。一部の実施形態では、サーバは、ユーザ登録が成功したと決定することができる。一部の実施形態では、ログイン名主要部に関係付けられたユーザ登録は、ユーザ登録の成功前に、競合する旧ユーザのパスワードと異なるパスワードの選択ではないその他のさらなる基準を要求することができる。例えば、ユーザ登録は、特定のフィールド（例えば、氏名、住所、ユーザの好みなど）の記入を要求することができる。一部の実施形態では、ログイン名主要部に関係付けられたユーザ登録が成功したかどうかを決定するために、図１に示されたユーザ管理デバイス１００の特別登録モジュール１２５が実装可能である。

２０７では、取得されたログイン名主要部の登録に関係付けられたユーザ記録が作成される。一部の実施形態では、サーバが、記録を作成する。サーバは、記録をメモリ（例えば、登録ユーザまたは登録ユーザ識別子のデータベース）に格納できる。一例として、サーバは、対応するアカウントテーブルに記録を格納できる。

一部の実施形態では、サーバは、取得されたログイン名主要部の登録に対応するパスワードが、取得されたログイン名主要部に一致する記録に関係付けられた競合する旧ユーザによって使用されているパスワードとは異なるとの決定を受けて、ログイン名主要部に関係付けられたユーザ登録に対応する記録を作成する。ユーザが登録に成功すると、サーバは、ユーザによる登録要求内のログイン名主要部と、ログインパスワードとに基づいて、アカウントテーブル内にユーザ記録を作成できる。ログインパスワードは、ログイン名主要部の取得と同時に取得できる（例えば、ログインパスワードは、登録要求の一部として、またはそれ以外の形で登録要求と関連付けて受信できる）。一部の実施形態では、成功したユーザ登録に関係付けられたユーザ記録をアカウントテーブル内に作成することと関連付けて、競合する旧ユーザのログイン名主要部のログイン名フィールド内に競合識別パラメータが導入される。競合識別パラメータは、取得されたログイン名主要部が、成功したユーザ登録に使用される場合における、取得されたログイン名主要部を含む、取得されたログイン名主要部と競合する１つまたは複数の任意のログイン名主要部について、対応するログイン名主要部と関連付けて生成および格納できる。

２０８では、ログイン要求が受信される。一部の実施形態では、サーバは、ログイン要求を受信できる。ログイン要求は、ログイン名主要部と、対応するログインパスワードとを含むことができる。一部の実施形態では、ユーザ管理デバイス１００のログイン管理モジュール１２７が、現ユーザによるログイン要求に関係付けられたログイン名主要部とログインパスワードとを受信する。ログイン要求が受信された場合、サーバ（例えば、図１のログイン管理モジュール１２７）は、それらのログイン名主要部およびログインパスワードが登録ユーザに対応しているかどうかを決定するために、登録群を検索できる（２０９）。例えば、サーバは、ログイン要求に関係付けられた現ユーザの認証を行う。一部の実施形態では、サーバは、ログイン名主要部とログインパスワードとの組み合わせに一致するアカウント記録が存在するかどうかを決定するために、アカウントテーブルを検索する。もし、ログイン名主要部とログインパスワードとの組み合わせに一致するアカウント記憶が存在すると決定したならば、サーバは、ユーザがログインすることを許可する。反対に、もし、ログイン名主要部とログインパスワードとの組み合わせとに一致するものが存在しないと決定したならば、サーバは、ユーザのログインを拒絶する。

２１０では、アクセスが拒否される。一部の実施形態では、サーバは、ユーザから受信されたログイン名主要部およびログインパスワードが有効ではないと決定した場合に（例えば、もし、ログイン名主要部とログインパスワードとの組み合わせが、登録ユーザまたは登録ユーザ識別子のデータベース内に存在しないならば）、（例えば、アプリケーションシステムへの）アクセスを拒否する。

反対に、２１１では、アクセスが提供される。一部の実施形態では、サーバは、ユーザから受信されたログイン名主要部およびログインパスワードが有効であると決定した場合に、ユーザアクセスを許可する。

一部の実施形態では、複数のユーザが登録のために同じログイン名主要部を使用することが許されており、そうして、二重発行されたユーザ識別子（例えば、二重発行された携帯電話番号）に起因する登録およびログインの不便性の問題を軽減している。登録プロセスにおいて、もし、ユーザによって使用されるログイン名主要部が、アカウントテーブル内で一意であるならば（例えば、ログイン名主要部が、旧ユーザなどの別のユーザのための記録と競合しないならば）、登録要求を送信したユーザは、競合する新ユーザではない。したがって、ユーザの登録要求は、２０４における登録プロセスなどの従来の登録プロセスにしたがって処理される。従来の登録プロセスは、照合手段の発行およびその他の処理手続きを要求することがある。

表１に戻り、通し番号２および通し番号３でそれぞれ示された記録は、第１のユーザ（例えば、Ｋｅｖｉｎ）および第２のユーザ（例えば、Ｔｏｎｙ）のアカウント記録（「ユーザ記録」とも呼ばれる）である。ログイン名主要部は携帯電話番号であると想定する。第１のユーザ（Ｋｅｖｉｎ）は、先ず、アカウント登録するために、携帯電話番号１８６１１１８０７５１を使用する。その後しばらくして、第１のユーザ（Ｋｅｖｉｎ）は、この携帯電話番号を使用しなくなった。例えば、第１のユーザは、この携帯電話番号の使用を破棄またはそれ以外の形で放棄することができる。その後、オペレータは、番号を回収し、第２のユーザ（Ｔｏｎｙ）に割り当てる。第２のユーザ（Ｔｏｎｙ）は、この携帯電話番号を使用してアカウント登録することができる。図２の２０５における、既存の登録処理からのログインパスワード差別化処理を経た結果として、第２のユーザ（Ｔｏｎｙ）のログイン名は、携帯電話番号と、それに追加された競合識別パラメータとを含むことになる。競合識別パラメータは、上記携帯電話番号を伴う第２のユーザの登録を、その同じ携帯電話番号を伴う第１のユーザの登録と差別化するために、携帯電話番号に追加できる。したがって、第１のユーザの記録と、第２のユーザの記録とは、アカウントテーブル内で同じではなくなる。例えば、アカウントテーブルに格納された、第１のユーザ（Ｋｅｖｉｎ）のログイン名と、第２のユーザ（Ｔｏｎｙ）のログイン名とが、同じではなくなる。一部の実施形態では、同じフィールド内でのログイン名の一意性が保証される。この時点で、第２のユーザ（Ｔｏｎｙ）は、第１のユーザ（Ｋｅｖｉｎ）に影響を及ぼすことなく第２のユーザのアカウントで登録およびログインすることを許される。

従来の処理手法では、ユーザのユーザ識別子が一意であるゆえに、アプリケーションシステムは、異なるユーザが同じパスワードを有するかどうかの問題を考慮する必要がない。従来の処理手法を使用しているアプリケーションシステムにしたがうと、論理的には、そのアプリケーションシステムの全ユーザが同じログインパスワードを使用することが許される。しかしながら、図２に示された方法２００の２０５および２０６との関係では、ユーザ登録の成功は、少なくとも、特定のログイン名主要部に関係付けられた各アカウントが異なるログインパスワードを有することを必要とする。例えば、もし、第２のユーザ（Ｔｏｎｙ）が、アプリケーションシステムへの登録に成功することを望むならば、その第２のユーザは、第１のユーザ（Ｋｅｖｉｎ）に関係付けられたログインパスワードとは異なるログインパスワードを使用しなければならない。一部の実施形態では、２０８〜２１１のプロセスのようなログインプロセスは、ログイン名とパスワードとの組み合わせの一致に基づく。もし、１８６１１１８０７５１に対応するアカウント記録が複数存在するならば、ログインパスワードを１つずつ比較する必要があるだろう。従来のやり方では、１つのログイン名主要部（１８６１１１８０７５１）が、２つのアカウント記録に存在することはできない。したがって、もし、従来のやり方の検索プロセスが、１８６１１１８０７５１を使用して検索を行って１つのアカウント記録を見つけ出し、しかしながら、その見つけられたアカウント記録に関係付けられたログインパスワードが、ログイン要求と関連付けてユーザから受信されたログインパスワードに一致しないならば、検索プロセスは、その検索から直ちに退出し、ログインの失敗を示す。しかしながら、本出願の様々な実施形態にしたがった検索プロセスは、一致するログイン名主要部を有する全ての記録を見つけるために、プロセスを引き続き進める必要がある。一部の実施形態では、ログイン名主要部（例えば、１８６１１１８０７５１）に対応するいずれのアカウント記録でも、一致するログインパスワードが見つからない場合にのみ、検索プロセスは、ユーザログインが失敗したと決定する。例えば、検索プロセスは、ログイン要求と関連付けて受信されたログインパスワードを、ログイン名主要部を関係付けられた全てのアカウント記録と比較する。

一部の実施形態では、登録を要求している現ユーザが、競合する旧ユーザ（例えば、Ｋｅｖｉｎ）に対応する競合する新ユーザ（例えば、Ｔｏｎｙ）に相当する場合は、登録プロセスにおけるログインパスワード差別化プロセスのための誘導プロセスフローを使用し、競合する新ユーザ（Ｔｏｎｙ）を、競合する旧ユーザ（Ｋｅｖｉｎ）によって使用されているログインパスワードとは異なるログインパスワードを使用するように誘導できる。ログインパスワード差別化プロセスのための誘導プロセスフローには、複数の実現形態がある。ログインパスワード差別化プロセスのための誘導プロセスフローを実現するための基準として、以下の例が提供される。一部の実施形態では、ログインパスワード差別化プロセスのための誘導プロセスフローに、２つの主要カテゴリが存在する。ログインパスワード差別化プロセスのための誘導プロセスフローのカテゴリは、１つが拒絶登録誘導モードであり、もう１つがパスワードルール誘導モードである。

ａ ログインパスワード差別化のための拒絶登録誘導モード

一部の実施形態では、もし、登録要求と関連付けて受信されたログインパスワードが、同じログイン名主要部を有する既存の登録に関係付けられたログインパスワードに一致しないならば、サーバは、ユーザ登録を成功であると決定し、もし、登録要求と関連付けて受信されたログインパスワードが、同じログイン名主要部を有する既存の登録に関係付けられたログインパスワードに一致するならば、ユーザ登録を成功ではないと決定する。一部の実施形態では、特別登録モジュール１２５は、新ユーザ（Ｔｏｎｙ）による登録要求内のログインパスワードを取得するようにさらに構成される。特別登録モジュール１２５は、ログインパスワードが、競合する旧ユーザ（Ｋｅｖｉｎ）のログインパスワードと同じであるかどうかをチェックできる。もし、現ユーザのログインパスワードが、競合する旧ユーザのログインパスワードと同じではないと決定したならば、特別登録モジュール１２５は、現ユーザの登録を成功であると判断する。もし、現ユーザのログインパスワードが同じであると決定したならば、特別登録モジュール１２５は、登録要求を拒絶する。特別登録モジュール１２５は、異なるログインパスワードを入力しなおすようにユーザに要求するために、ログインパスワードがセキュリティルールに適合しない（例えば、現ユーザのログインパスワードが、競合する旧ユーザのログインパスワードと同じである）ことを示す警告を、動作可能式に出力できる。総じて、２ユーザが同じログインパスワードを設定する確率は、非常に低い。ユーザ識別子（例えば、携帯電話番号）が二重発行された場合に新ユーザと旧ユーザとが同じログインパスワードを設定する可能性は、さらに低くなる（例えば、同じユーザ識別子の２ユーザが、同じログインパスワードを設定する確率は、ゼロに近くなる）。しかしながら、各種の実施形態は、極めて厳しいセキュリティ要件を伴う一部のアプリケーションシナリオを考慮している。例えば、インターネット金融の用途では、第２のユーザ（Ｔｏｎｙ）が設定するログインパスワードは、チェックおよび誘導を経るだろう。提案されたログインパスワードと、既存のユーザ（例えば、競合するユーザ識別子に関係付けられたユーザ）のログインパスワードとの間にパスワード競合が存在することが見つかると、新ユーザを異なるログインパスワードの使用（例えば、選択）へ誘導するために、そのログインパスワードがセキュリティルールに適合しないことを示す警告が出力されるだろう。

図３Ａは、本出願の様々な実施形態にしたがった、ログインパスワード差別化プロセスのための誘導プロセスフローに関係したインターフェースの図である。

図３Ａを見ると、ログインパスワード差別化プロセスに関連して表示されるインターフェース３００が表示されている。一部の実施形態では、インターフェース３００は、図１のアカウント管理デバイス１００によって実現される。一部の実施形態では、インターフェース３００は、図２の方法２００に関連して実現される。一部の実施形態では、インターフェース３００は、図４の方法４００に関連して実現される。一部の実施形態では、インターフェース３００は、図６のシステム６００に実装される。例えば、インターフェース３００は、端末６１０によって表示できる。

インターフェース３００は、ユーザ識別子フィールド３１０（例えば、携帯電話番号フィールド）と、ログインパスワードフィールド３２０と、ログインパスワード確認フィールド３３０と、ログインパスワード警告３４０ａとを含む。

ユーザ識別子フィールド３１０は、登録要求に関係付けられたユーザ識別子が設定されるフィールドである。ユーザ識別子フィールド３１０内に設定されるユーザ識別子は、ユーザによって入力可能である、または登録要求と関連付けて通信された情報に基づいてサーバによって自動的に入力可能である。

ログインパスワードフィールド３２０は、ログインパスワードがエントリされるフィールドである。ログインパスワードフィールド３２０にエントリされるログインパスワードは、登録要求に関係付けられたユーザによって所望されるログインパスワードに相当することができる。アプリケーションシステム（例えば、サーバ）は、ログインパスワードフィールド３２０にエントリされたログインパスワードがログインパスワード基準を満たすかどうかを決定できる。ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準を満たす場合は、そのログインパスワードは、許容可能であると見なすことができる。反対に、ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準を満たすのではない場合は、そのログインパスワードは、許容可能ではないと見なすことができる。

ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準を満たすのではない場合は、ログインパスワード警告フィールド３４０ａ内に警告が提供できる。ログインパスワード警告フィールド３４０ａは、ログインパスワードフィールド３２０にエントリされたログインパスワードが許容可能ではないという旨の表示を提供できる。ログインパスワード警告フィールド３４０ａは、ログインパスワードフィールド３２０が満たしていない特定のログインパスワード基準の表示を提供できる。ログインパスワード警告フィールド３４０ａに提供される警告は、ログインパスワード基準を満たすパスワードをエントリしなおすようにユーザに要求できる。警告は、様々なログインパスワード基準のガイドラインを提供できる。ログインパスワード基準は、英数字の最大数、英数字の最小数、特殊文字の必要性、大文字の最小数、ログインパスワードと辞書などのワードテーブル内のワードとの差、ログインパスワードフィールド３２０にエントリされたログインパスワードとログインパスワード確認フィールド３３０にエントリされたパスワードとの一致などを含むことができる。

ログインパスワード確認フィールド３３０は、ログインパスワードがエントリされるフィールドである。ログインパスワードフィールド３２０にエントリされるログインパスワードは、登録要求に関係付けられたユーザによって所望されるログインパスワードに相当することができる。

上記の例に戻り、ログインパスワードがセキュリティルールに適合しない場合は、そのことを示す警告（例えば、ログインパスワード警告フィールド３４０ａに提供される）が、異なるログインパスワードを使用（例えば、選択）するように新ユーザを誘導するために（例えば、ログインパスワードフィールド３２０にエントリした）第２のユーザ（Ｔｏｎｙ）に提供される。このような警告を受信すると、現ユーザ（Ｔｏｎｙ）は、通常は、より高いパスワード強度を有するログインパスワードを試みるだろう。第２のユーザが入力するログインパスワードは、したがって、必然的に、第２のユーザがその前に入力したログインパスワード（第１のユーザ（Ｋｅｖｉｎ）のログインパスワードでもあった）とは異なることになる。このようにして、第２のユーザは、異なるパスワードへ誘導される。このような誘導は、極めて単純であり、大半の状況のニーズを満足させることができる。

一部の実施形態では、誘導モードは、そのセキュリティを高めるためにさらに強化される。例えば、第２のユーザ（Ｔｏｎｙ）によって登録要求に入力されたログインパスワードが、第１のユーザ（Ｋｅｖｉｎ）のログインパスワードと厳密に同じであると想定する。この場合、方法またはシステムは、「ログインパスワードがセキュリティルールに適合しない」ことを示す警告を提供する。したがって、第２のユーザ（Ｔｏｎｙ）は、第２のユーザ（Ｔｏｎｙ）によって入力されたログインパスワードが、第１のユーザ（Ｋｅｖｉｎ）によって使用されるログインパスワードと同じでかもしれないと推定でき、これは、第１のユーザ（Ｋｅｖｉｎ）のアカウントを盗用の危険にさらす恐れがある。極めて起きにくいこの種のセキュリティホールを回避するために、サーバ（例えば、ユーザ管理デバイス１００の特別登録モジュール１２５）は、無作為の正の整数Ｎ（例えば、８よりも小さい正の整数）を選択し、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））によってサブミットされた登録要求を最初のＮ回にわたって拒絶するようにさらに構成される。さらに、登録要求が拒絶されるたびに、ログイン名がセキュリティルールに適合しないことを示す警告を（例えば、サーバまたは特別登録モジュール１２５によって）出力できる。Ｎ回の登録要求を拒絶することに相当するＮ回の拒絶が完了した後、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））によって（Ｎ＋１）回目の登録要求がサブミットされた場合は、（Ｎ＋１）回目の登録要求内のログインパスワードが取得され、その（Ｎ＋１）回目の登録要求に関係付けられたログインパスワードが競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））のログインパスワードと同じであるかどうかがチェックされる。一部の実施形態では、サーバ（例えば、特別登録モジュール１２５）は、（Ｎ＋１）回目の登録要求に関係付けられたログインパスワードを受信し、このようなパスワードが競合する旧ユーザのログインパスワードと同じであるかどうかを決定する。（Ｎ＋１）回目の登録要求に関係付けられたログインパスワードと、競合する旧ユーザのログインパスワードとが同じである場合、（Ｎ＋１）回目の登録要求は拒絶でき、ログインパスワードがセキュリティルールに適合しないことを示す警告が（例えば、インターフェース３００などのインターフェース上に）出力できる。（Ｎ＋１）回目の登録要求に関係付けられたログインパスワードと、競合する旧ユーザのログインパスワードとが同じではない場合は、現ユーザの登録は、成功であると決定できる。拒絶メカニズムの回数の無作為性ゆえに、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））は、現ユーザが入力したパスワードをシステムが何故拒絶したかの理由を知ることはできない。ゆえに、第１のユーザ（Ｋｅｖｉｎ）のログインパスワードは、効果的に保護できる。起こりにくい状況ではあるが、現ユーザ（Ｔｏｎｙ）が第１のユーザ（Ｋｅｖｉｎ）のパスワードを容易に予測可能にする状況が回避される。もちろん、現ユーザのユーザエクスペリエンスのために、システムは、説明を（例えば、ページ上やダイアログボックス内に）提供する適切な表示を事前に出力することができるだろう。例えば、表示としては、「現プロセスは、競合する登録に対処するための特殊なプロセスであり、ユーザの皆さまによる寛大な協力を求めております。ログインパスワードの競合に伴うユーザのセキュリティを保証するために、ユーザは、幾つかの異なるログインパスワードを試みることを要求されます。システム側が、妥当なログインパスワードを無作為に選択します」などがありえるだろう。

ｂ ログインパスワード差別化のパスワードルール誘導モード

ログインパスワード差別化プロセスのパスワードルール誘導モードは、多くの実現形態を含むことができる。代表的な実現形態には、長さルール誘導モード、指定文字誘導モード、およびクラス量誘導モードがある。

Ｉ 長さルール誘導モード

一部の実施形態では、現ユーザのログインパスワードは、ログインパスワードがあらかじめ定められた長さ基準（またはルール）に適合するどうかを決定するためにチェックされる。例えば、ユーザ管理デバイス１００の特別登録モジュール１２５は、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））の登録要求に関係付けられたログインパスワードがあらかじめ定められた長さルールに適合するかどうかを決定するようにさらに構成できる。現ユーザの登録要求に関係付けられたログインパスワードがあらかじめ定められた長さルールに適合する場合は、ユーザ登録は、（例えば、その他の登録基準も満たされていると想定して）成功であると見なすことができる。現ユーザの登録要求に関係付けられたログインパスワードがあらかじめ定められた長さルールに適合しない場合は、現ユーザ（Ｔｏｎｙ）は、現ページ上やダイアログボックス内などで、あらかじめ定められた長さルールに適合するログインパスワードを入力しなおすように指示を受けることができる。このとき、競合する旧ユーザのログインパスワードは、あらかじめ定められた長さルールに適合していない。

図３Ｂは、本出願の様々な実施形態にしたがった、ログインパスワード差別化プロセスのための誘導プロセスフローに関係したインターフェースの図である。

図３Ｂを参照すると、ログインパスワード差別化プロセスに関連して表示されるインターフェース３５０が表示されている。一部の実施形態では、インターフェース３５０は、図１のアカウント管理デバイス１００によって実現される。一部の実施形態では、インターフェース３５０は、図２の方法２００に関連して実現される。一部の実施形態では、インターフェース３５０は、図４の方法４００に関連して実現される。一部の実施形態では、インターフェース３５０は、図６のシステム６００に関連して実現される。例えば、インターフェース３５０は、端末６１０によって表示できる。

インターフェース３５０は、ユーザ識別子フィールド３１０（例えば、携帯電話番号フィールド）と、ログインパスワードフィールド３２０と、ログインパスワード確認フィールド３３０と、ログインパスワード警告３４０ｂとを含む。

ユーザ識別子フィールド３１０は、登録要求に関係付けられたユーザ識別子が設定されるフィールドである。ユーザ識別子フィールド３１０内に設定されるユーザ識別子は、ユーザによって入力可能である、または登録要求と関連付けて通信された情報に基づいてサーバによって自動的に入力可能である。

ログインパスワードフィールド３２０は、ログインパスワードがエントリされるフィールドである。ログインパスワードフィールド３２０にエントリされるログインパスワードは、登録要求に関係付けられたユーザによって所望されるログインパスワードに相当することができる。アプリケーションシステム（例えば、サーバ）は、ログインパスワードフィールド３２０にエントリされたログインパスワードがあらかじめ定められた長さルールなどのログインパスワード基準に適合するかどうかを決定できる。ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準に適合する場合は、そのログインパスワードは、許容可能であると見なすことができる。反対に、ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準に適合するのではない場合は、そのログインパスワードは、許容可能ではないと見なすことができる。

ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準に適合するのではない場合は、ログインパスワード警告フィールド３４０ｂ内に警告が提供できる。ログインパスワード警告フィールド３４０ｂは、ログインパスワードフィールド３２０にエントリされたログインパスワードが許容可能ではないという旨の表示を提供できる。例えば、ログインパスワードフィールド３２０にエントリされたログインパスワードがあらかじめ定められた長さルールに適合しない場合は、ログインパスワードフィールド３４０ｂは、ログインパスワードフィールド３２０にエントリされたログインパスワードが（１つまたは複数の）セキュリティルールに適合しないという旨の表示を提供でき、ユーザは、あらかじめ定められた長さ（例えば、あらかじめ定められた最大桁数）を有するログインパスワードをログインパスワードフィールド３２０にエントリするように指示を受けることができる。

ログインパスワード確認フィールド３３０は、ログインパスワードがエントリされるフィールドである。ログインパスワードフィールド３２０にエントリされるログインパスワードは、登録要求に関係付けられたユーザによって所望されるログインパスワードに相当することができる。

上記の例に戻り、競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））によって使用されるログインパスワードが１０桁であると想定する。競合する旧ユーザに関係付けられたユーザ識別子の登録を試みている新ユーザに適用されるパスワード長さルールは、新ユーザに関係付けられたログインパスワードの長さが競合する旧ユーザによって使用されているログインパスワードの長さと同じではないことを要求することができる。例えば、サーバ（例えば、特別処理モジュール）は、１０桁の長さを有さない任意のパスワード長さ間隔を選択できる。例えば、１１桁から１３桁までの長さ間隔が、競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））のユーザ識別子と同じユーザ識別子の登録を試みているユーザのための長さルールとしての役割を果たすことができる。もし、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））が、この長さルール（例えば、１１桁から１３桁までの長さ間隔）に適合しない長さを有するパスワードをサブミットすると、現ユーザに関係付けられた登録要求は、現ユーザによって入力されたパスワードの長さがあらかじめ定められた長さルールに適合するまで拒絶できる。長さルールの結果として、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））のログインパスワードは、競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））のログインパスワードとは長さが異なる必要がある。あらかじめ定められた長さルールは、同じユーザ識別子（例えば、携帯電話番号）に関係付けられた２つのパスワードを異なるものにする。この場合は、理論的に、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））は、競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））のログインパスワードが１１桁から１３桁までの長さ間隔を有するのではないことしか推定できない。現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））が、競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））のログインパスワードを予測できる可能性は小さい。次に、或るユーザ識別子（例えば、携帯電話番号）に関係して２者以上の競合する旧ユーザが存在すると想定した極端な状況について検討する（例えば、携帯電話番号が三度にわたって発行されたゆえに、携帯電話番号の二重発行が二度にわたって発生した）。このような場合、別の競合する旧ユーザ（例えば、第２の競合する旧ユーザ（Ｍｉｋｅ））が存在できる。この別の競合する旧ユーザ（Ｍｉｋｅ）に関係付けられたログインパスワードのパスワード長さは、例えば、１３桁であることができる。したがって、競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））および別の競合する旧ユーザ（例えば、第２の競合するユーザ（Ｍｉｋｅ））に関係付けられたそれぞれのログインパスワードのパスワード長さは、あらかじめ定められた長さルールに適合することができない（なぜならば、あらかじめ定められた長さルールは、現ユーザ（Ｔｏｎｙ）に適用されるので）。したがって、あらかじめ定められた長さルールは、１３桁を超える桁数または１１から１２までの桁数に調整できる。一部の実施形態では、あらかじめ定められた長さルールは、一者または二者以上の競合するユーザが存在するユーザ識別子の登録を試みている現ユーザに、それらの一者または二者以上の競合するユーザに関係付けられたそれぞれのログインパスワードのいずれのパスワード長さとも異なるパスワード長さを有するログインパスワードを選択させる。

ＩＩ 指定文字誘導モード

一部の実施形態では、現ユーザのログインパスワードは、ログインパスワードが指定文字基準（またはルール）に適合するかどうかを決定するためにチェックされる。指定文字基準は、対応するログインパスワードが指定文字を含むことを要求することができる。例えば、ユーザ管理デバイス１００の特別登録モジュール１２５は、現ユーザの登録要求に関係付けられたログインパスワードが指定文字を有するかどうかを決定するようにさらに構成できる。現ユーザの登録要求に関係付けられたログインパスワードが指定文字を含む場合は、ユーザ登録は、（例えば、その他の登録基準も満たされたと想定して）成功であると見なすことができる。現ユーザの登録要求に関係付けられたログインパスワードが指定文字を含まない場合は、現ユーザ（例えば、上記の例を使用すると第２のユーザ（Ｔｏｎｙ））は、現ページ上やダイアログボックス内などで、指定文字を含むログインパスワードを入力しなおすように指示を受けることができる。一部の実施形態では、指定文字は、同じユーザ識別子に関係付けられた競合する旧ユーザのそれぞれのログインパスワードにしたがって選択できる。例えば、指定文字は、競合する旧ユーザによって使用されているログインパスワードに含まれないものであるように選択できる。一部の実施形態では、指定文字誘導モードは、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））がそのログインパスワード内に、競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））のログインパスワードに含まれない文字を使用することを要求する。したがって、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））がユーザ識別子を登録するときに、ログインパスワードは、必然的に、競合する旧ユーザ（Ｋｅｖｉｎ）のログインパスワードとは異なるものになる。この場合、理論的に、現ユーザ（例えば、Ｔｏｎｙ）は、競合する旧ユーザのログインパスワードが指定文字（例えば、「Ａ」）を含まないことしか推定できない。現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））が、競合する旧ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））のログインパスワードを（このインターフェースを使用して）予測できる可能性は小さい。ユーザ識別子に関係付けられた他の登録が（例えば、その後に）ある場合でも、競合する旧ユーザ（または新ユーザ）のいずれかのパスワードが現ユーザ（Ｔｏｎｙ）の登録に使用される指定文字を含むことはない。

図３Ｃは、本出願の様々な実施形態にしたがった、ログインパスワード差別化プロセスのための誘導プロセスフローに関係したインターフェースの図である。

図３Ｃを参照すると、ログインパスワード差別化プロセスに関連して表示されるインターフェース３６０が表示されている。一部の実施形態では、インターフェース３６０は、図１のアカウント管理デバイス１００によって実現される。一部の実施形態では、インターフェース３６０は、図２の方法２００に関連して実現される。一部の実施形態では、インターフェース３６０は、図４の方法４００に関連して実現される。一部の実施形態では、インターフェース３６０は、図６のシステム６００に関連して実現される。例えば、インターフェース３６０は、端末６１０によって表示できる。

インターフェース３６０は、ユーザ識別子フィールド３１０（例えば、携帯電話番号フィールド）と、ログインパスワードフィールド３２０と、ログインパスワード確認フィールド３３０と、ログインパスワード警告３４０ｃとを含む。

ユーザ識別子フィールド３１０は、登録要求に関係付けられたユーザ識別子が設定されるフィールドである。ユーザ識別子フィールド３１０内に設定されるユーザ識別子は、ユーザによって入力可能である、または登録要求と関連付けて通信された情報に基づいてサーバによって自動的に入力可能である。

ログインパスワードフィールド３２０は、ログインパスワードがエントリされるフィールドである。ログインパスワードフィールド３２０にエントリされるログインパスワードは、登録要求に関係付けられたユーザによって所望されるログインパスワードに相当することができる。アプリケーションシステム（例えば、サーバ）は、ログインパスワードフィールド３２０にエントリされたログインパスワードが指定文字ルールなどのログインパスワード基準に適合するかどうかを決定できる。ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準に適合する場合は、そのログインパスワードは、許容可能であると見なすことができる。反対に、ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準に適合するのではない場合は、そのログインパスワードは、許容可能ではないと見なすことができる。

ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準に適合するのではない場合は、ログインパスワード警告フィールド３４０ｃ内に警告が提供できる。ログインパスワード警告フィールド３４０ｃは、ログインパスワードフィールド３２０にエントリされたログインパスワードが許容可能ではないという旨の表示を提供できる。例えば、ログインパスワードフィールド３２０にエントリされたログインパスワードが指定文字ルールに適合しない場合は、ログインパスワードフィールド３４０ｃは、ログインパスワードフィールド３２０にエントリされたログインパスワードが（１つまたは複数の）セキュリティルールに適合しないという旨の表示を提供でき、ユーザは、あらかじめ定められた文字（例えば、ログインパスワードに含めることを要求される指定の文字）を有するログインパスワードをログインパスワードフィールド３２０にエントリするように指示を受けることができる。

ログインパスワード確認フィールド３３０は、ログインパスワードがエントリされるフィールドである。ログインパスワードフィールド３２０にエントリされるログインパスワードは、登録要求に関係付けられたユーザによって所望されるログインパスワードに相当することができる。

III クラス量誘導モード

一部の実施形態では、現ユーザのログインパスワードは、ログインパスワードがあらかじめ定められた文字クラス基準（またはルール）に適合するかどうかを決定するためにチェックされる。あらかじめ定められた文字クラス基準は、対応するログインパスワードがあらかじめ定められた文字クラスを含むことを要求することができる。例えば、ユーザ管理デバイス１００の特別登録モジュール１２５は、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））の登録要求に関係付けられたログインパスワードがあらかじめ定められた文字クラスルールに適合するかどうかを決定するようにさらに構成できる。現ユーザの登録要求に関係付けられたログインパスワードがあらかじめ定められた文字クラスルールに適合する場合は、ユーザ登録は、成功であると見なすことができる。現ユーザの登録要求に関係付けられたログインパスワードがあらかじめ定められた文字クラスルールに適合しない場合は、現ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））は、現ページ上やダイアログボックス内などで、文字クラスルールに適合するログインパスワードを入力しなおすように指示を受けることができる。一部の実施形態では、あらかじめ定められた文字クラスは、同じユーザ識別子に関係付けられた競合する旧ユーザのそれぞれのログインパスワードにしたがって選択できる。例えば、指定文字は、競合する旧ユーザによって使用されているログインパスワードに含まれないものであるように選択できる。一部の実施形態では、指定文字誘導モードは、ログインパスワードが特定のタイプの文字（例えば、文字および数字の両方）を含むことを要求することができる。あらかじめ定められた文字クラスルールは、ログインパスワードが最小数の文字または最小数の数字を含むことを要求することができる。一例として、特別登録モジュールは、現ページ上やダイアログボックス内などに、現ユーザ（Ｔｏｎｙ）によって入力されるパスワードが３クラスの文字、即ち文字、数字、および記号のみを含んでいなければならないことを示すプロンプトを出力できる。一部の実施形態では、同一のユーザ識別子に関係付けられた異なるユーザ（ＫｅｖｉｎおよびＴｏｎｙ）のログインパスワードが、少なくとも１つの文字クラスに関して異なる必要がある。例えば、第１のユーザ（Ｋｅｖｉｎ）のログインパスワードが、第２のユーザ（Ｔｏｎｙ）のログインパスワードとは異なる文字クラスを少なくとも１つは有していなければならない、または第２のユーザ（Ｔｏｎｙ）のログインパスワードが、第１のユーザ（Ｋｅｖｉｎ）のログインパスワードとは異なる文字クラスを少なくとも１つは有していなければならない。したがって、ログインパスワードは異なっていなければならず、第２のユーザ（Ｔｏｎｙ））が第１のユーザ（Ｋｅｖｉｎ）のログインパスワードを予測できる可能性は小さい。

当業者ならば、上記の実施形態を踏まえて、セキュリティおよびユーザエクスペリエンスの包括的なニーズにしたがって、パスワード差別化のための誘導プロセスフローのさらなる実現形態を開発できるだろう。

各種の実施形態の技術的利点は、さらなる用途の実態性に関係付けられた、上述された実施形態に基づく好ましい実施形態の形態で説明される。以下の説明では、携帯電話番号が、ログイン名（例えば、ユーザ識別子）の例としての役割を果たす。実際のレイアウトに近い方式では、各種の実施形態は、実際の使用における本出願の有効性をさらに高めるために、最適化手段を実行する。もちろん、これらの手段は、必須ではない。さらに、ニーズにしたがって、様々な最適化手段を組み合わせたものが柔軟に選択されてもよい。

各種の実施形態は、競合を排除する方法またはメカニズムを含むことができる。例えば、各種の実施形態は、上述された実施形態の基盤の上に構築可能であり、さらに、競合を排除するメカニズムを導入してよい。一部の実施形態では、ステップ２０１〜２０４に関連して説明された基盤に載る競合解決メカニズムが提供される。上述された各種の実施形態は、登録の競合およびログインの競合（例えば、ユーザ識別子の競合）の問題を解決できる。例えば、上述された各種の実施形態は、２ユーザが、ログインするために（例えば、ユーザ識別子として）同じ携帯電話番号を使用することに関係した問題を解決またはそれ以外の形で排除できる。ユーザによって使用されるアプリケーションサービスの観点からすると、しかしながら、携帯電話番号は、例えばユーザが照合メッセージを受信するときなどのように、ユーザにとって極めて重要であることは疑いようもない。もし、アプリケーションが、照合メッセージの受信、および次いでアプリケーション（例えば、ページ上など）へエントリまたはそれ以外の形でのサブミットを要求するならば、この場合の１ユーザ（例えば、第１のユーザ（Ｋｅｖｉｎ））は、対応する照合メッセージを受信できなくなる。照合メッセージは、ショートメッセージサービス（ＳＭＳ）メッセージ、マルチメディアメッセージサービス（ＭＭＳ）メッセージ、電話、電子メール、アプリケーション（アプリ）など、またはこれらの任意の組み合わせを通じて送信できる。照合メッセージは、デバイスにインストールされたアプリ内でプッシュできる。照合メッセージは、英数字の文字列を含むメッセージであることができる。照合メッセージは、無作為に生成できる。一部の実施形態では、照合メッセージは、（例えば、少なくとも同じユーザ識別子に関係付けられたその他のユーザに送信される照合メッセージとの関係のもとで）一意である。携帯電話番号は、一度に１ユーザ（例えば、第２のユーザ（Ｔｏｎｙ））のみによって所有可能であるので、第１のユーザは、その携帯電話番号に対応する照合メッセージを受信することはできない。このような状況では、各種の実施形態は、競合識別パラメータに関係した特別な処理を実施できる。例えば、ユーザが（例えば、アプリケーションやアプリケーションサービスなどへの）ログインに成功した場合は、ユーザログイン名が競合識別パラメータを含むかどうかを決定するために、ユーザログイン名がチェックできる。ユーザログイン名が競合識別パラメータを含むかどうかを決定するために、（例えば、アプリケーションもしくはアプリケーションサービスを運営している、またはアプリケーションもしくはアプリケーションサービスにそれ以外の形で関係付けられた）サーバは、ユーザログイン名をチェックすることができる。ユーザログイン名が競合識別パラメータを含む場合は、競合する旧ユーザをそれに関係付けられた携帯電話番号を修正するように誘導するための、携帯電話番号修正インターフェースがプッシュできる。例えば、ユーザ管理デバイス１００のログイン管理モジュール１２７は、同じユーザ識別子（例えば、携帯電話番号）に関係付けられた競合する旧ユーザに、リンクおよび／またはユーザ識別子修正インターフェース（例えば、携帯電話番号修正インターフェース）を含む通知をプッシュできる。別の一例として、同じユーザ識別子に関係付けられた競合する旧ユーザは、ユーザの携帯電話番号などの通信情報などの対応する自身のアプリケーション設定を編集するように指示を受けることができる。対応する競合する旧ユーザから新しい携帯電話番号が受信された後、対応するアカウント記録は、その新しい携帯電話番号を含むようにアップデートされる。例えば、サーバは、アカウント記録に関係付けられた携帯電話番号を、対応する競合する旧ユーザからサーバが受信した新しい携帯電話番号に対応するように変更するために、対応するアカウント記録をアップデートする。（例えば、競合する旧ユーザに関係付けられた）アカウント記録に関係付けられた携帯電話番号のアップデートは、アカウント記録に関係付けられたログイン名またはユーザ識別子をアップデートまたはそれ以外の形で変更することを含むことができる。一部の実施形態では、アップデートされたアカウント記録に関係付けられた競合する旧ユーザは、その後のログインプロセスでは、アプリケーションまたはアプリケーションサービスにログインするためのログイン名主要部として新しい携帯電話番号を使用する。一部の実施形態では、ユーザが新しい携帯電話番号を入力した後、サーバ（例えば、ユーザ管理デバイス１００のログイン管理モジュール１２７）は、新しい携帯電話番号のために発行された照合手段を送信する。新しい携帯電話番号のために発行された照合手段は、新しい携帯電話番号の照合を行うための照合メッセージであることができる（例えば、照合メッセージは、競合する旧ユーザおよび新しい携帯電話番号の２要素認証として使用できる）。例えば、サーバは、照合コードを含む照合メッセージを新しい携帯電話番号に送信し、競合する旧ユーザによって照合コードがサブミットされたら、競合する旧ユーザによって（例えば、競合する旧ユーザに提供されたインターフェースに）サブミットされたその照合コードが正しいかどうかを決定し、ユーザが新しい携帯電話番号の正当なユーザであるかどうかを確認することができる。照合手段を新しい携帯電話番号または競合する旧ユーザに送信するプロセスは、上述された登録プロセスに類似しており、ここではこれ以上詳しく説明されない。

一部の実施形態では、自身に関係付けられたユーザ識別子（例えば、携帯電話番号）を修正する競合する旧ユーザは、その新しいユーザ識別子が二重発行されたユーザ識別子に相当する状況に遭遇することがある。例えば、競合する旧ユーザによって選択された新しいユーザ識別子は、異なるユーザの登録に関係付けられて登録されたユーザ識別子に相当することがある。第１のユーザ（例えば、Ｋｅｖｉｎ）によって入力された携帯電話番号が、以前と同様に、１８６１１１８０７５１であると想定する。このような携帯電話番号は、元の携帯電話番号と同じであり、新しい携帯電話番号ではない。この場合、システムは、第１のユーザ（Ｋｅｖｉｎ）または第２のユーザ（Ｔｏｎｙ）がこの携帯電話番号の正当なユーザであるかどうかを決定できない。このような問題を解決する単純なやり方は、第１のユーザ（Ｋｅｖｉｎ）に、自身に関係付けられた携帯電話番号を変更するように要求し、自身に関係付けられた携帯電話番号を変更するまでログインを続けることを許可しないことである。しかしながら、実際は、第２のユーザ（Ｔｏｎｙ）は、（例えば、第１のユーザに関係付けられた）携帯電話番号を一時的に使用しているだけかもしれず、第１のユーザ（Ｋｅｖｉｎ）が、携帯電話番号の正当なユーザ（例えば、真の所有者）であるかもしれない。一部の実施形態では、ユーザは、このような競合を解決するために、自身に関係付けられた携帯電話番号を修正するように誘導される。

図４は、本出願の様々な実施形態にしたがった、ユーザの携帯電話番号を修正するようにユーザを誘導するための方法のフローチャートである。

図４を参照すると、ユーザアカウント管理のための方法４００が提供される。一部の実施形態では、方法４００は、図１のデバイス１００によって実行できる。一部の実施形態では、方法４００は、図６のシステム６００によって実行される。一部の実施形態では、方法４００は、図５のインターフェース５００を実現できる。

４０１では、ユーザがログインに成功する。ユーザは、ユーザ識別子およびログインパスワードを提供することによって、ログインに成功することができる。ユーザがサーバにユーザ識別子およびログインパスワードを提供する場合に、サーバは、データベース（例えば、アカウントテーブル）に格納されたユーザ識別子とそれに関係付けられたパスワードとによって、ユーザを認証できる。もし、ユーザから受信されたユーザ識別子およびログインパスワードが、データベースに格納されたユーザ識別子とそれに関係付けられたログインパスワードに一致するならば、サーバは、ユーザのログインを成功させる（例えば、サーバは、アプリケーションまたはアプリケーションサービスへのアクセスを提供できる）。

４０２では、ログイン名フィールドが競合識別パラメータを含むかどうかを決定するために、ログイン名フィールドを分析することができる。一部の実施形態では、サーバは、ログイン名フィールドを、それが競合識別パラメータを含むかどうかを決定するためにチェックする。例えば、現ユーザがログインに成功した場合は、図１のユーザ管理デバイス１００のログイン管理モジュール１２７は、ユーザアカウント記録のログイン名フィールドを、それが競合識別パラメータを含むかどうかを決定するためにチェックする。例えば、アカウントデータベース内にログイン名とパスワードとの一意のペアがあると想定すると（例えば、ＩＤ１２３４とそれに対応するパスワードａｂｃ、およびＩＤ１２３４｜５とそれに対応するパスワードｄｅｆ）、ログイン名とパスワードとの各一意のペアが、それぞれ別個のエントリに相当する。

ユーザアカウント記録のログイン名フィールドが競合識別パラメータを含まない場合は、方法４００は終了できる。

ユーザアカウント記録のログイン名フィールドが競合識別パラメータを含む場合は、４０３において、ユーザ識別子修正インターフェースが現ユーザに提供される。例えば、４０３において、サーバは、ユーザ識別子修正インターフェース（例えば、ユーザログイン名主要部修正インターフェース）を現ユーザに送信する。ユーザ識別子修正インターフェースは、現ユーザのアカウント記録に関係付けられたログイン名主要部の修正に現ユーザを誘導するように構成できる。

４０４では、ユーザ識別子修正インターフェースを通じてユーザ識別子が受信できる。一部の実施形態では、ユーザ識別子修正インターフェースを通じてログイン名主要部が受信される。サーバは、現ユーザがユーザ識別子修正インターフェースにユーザ識別子をサブミットすることによって、現ユーザからユーザ識別子を受信できる。ユーザ識別子修正インターフェースは、ウェブページ（例えば、ＨＴＭＬページなど）や、ユーザがログインに成功したアプリケーション内で提示されるページなどであることができる。一部の実施形態では、ユーザ管理デバイス１００の特別登録モジュール１２５が、ログイン名主要部修正インターフェースを通じて現ユーザによって入力されたログイン名主要部を取得する。

４０５では、競合する新ユーザのための検索が実施できる。サーバは、ユーザ識別子修正インターフェースを通じてユーザ識別子を受信すると、競合する新ユーザを検索できる。例えば、サーバは、受信されたログイン名主要部を使用している（例えば、受信されたログイン名主要部に関係付けられた）競合する新ユーザが存在するかどうかを決定するために、アカウントテーブルを検索できる。一部の実施形態では、ユーザ管理デバイス１００の特別登録モジュール１２５が、競合する新ユーザが存在するかどうかを決定するために、データベース（例えば、アカウントテーブル）を検索する。

競合する新ユーザを検索した結果、４０６では、競合する新ユーザが存在するかどうかが決定される。データベース（例えば、アカウントテーブル）内に競合する新ユーザが存在しないと決定された場合は、現ユーザのアカウント記録がアップデートされる。例えば、対応する現ユーザのアカウント記録内で、ユーザ識別子（例えば、ログイン名主要部）がアップデートされる。一部の実施形態では、サーバは、現ユーザに関係付けられたアカウント記録をアップデートする。例えば、ユーザ管理デバイス１００の特別登録モジュール１２５が、現ユーザに関係付けられたアカウント記録をアップデートできる。

競合する新ユーザが存在する場合は、４０８において、競合する新ユーザのためのログイン名フィールドおよび競合する旧ユーザのためのログイン名フィールドがアップデートできる。例えば、競合する新ユーザのログイン名フィールドに、競合識別パラメータが追加できる。サーバ（例えば、ユーザ管理デバイス１００の特別登録モジュール１２５）が、競合する新ユーザのログイン名フィールドに、競合識別パラメータを追加できる。一部の実施形態では、競合識別パラメータの追加は、競合識別パラメータが追加されるアカウント記録に関係付けられたユーザを、競合する旧ユーザにする。一部の実施形態では、競合識別パラメータは、現ユーザアカウント記録のログイン名フィールドから削除される。

表１および表２を参照し、第１のユーザ（例えば、Ｋｅｖｉｎ）および第２のユーザ（Ｔｏｎｙ）を例として使用し、第１のユーザ（Ｋｅｖｉｎ）が、競合する旧ユーザに相当すると想定する。第１のユーザによってログイン名修正インターフェース上にサブミットされた携帯電話番号は、変更されている。例えば、第１のユーザ（例えば、通し番号２に関係付けられたユーザ）によってサブミットされた携帯電話番号は、１８６１１２２３３４４になっている。この場合、４０２、４０３、４０４、および４０５にしたがって行われた処理の結果として、第１のユーザ（Ｋｅｖｉｎ）のログイン名主要部と、第２のユーザ（Ｔｏｎｙ）のログイン名主要部との間に、もはや競合は存在しない。第１のユーザ（Ｋｅｖｉｎ）のログイン名（例えば、ログイン名主要部）は、一意に使用される携帯電話番号になる。この場合、アカウントテーブルは、表１から表２の例にアップデートされる。

しかしながら、もし、第１のユーザ（Ｋｅｖｉｎ）によって入力されたログインパスワードが、以前と同様に、１８６１１１８０７５１であると想定するならば、第１のユーザ（Ｋｅｖｉｎ）は、自分がこの携帯電話番号を使用している（例えば、この携帯電話番号の正当なユーザまたは所有者である）ことを示している。そして、例えば、第２のユーザも、自分がまだこの携帯電話番号を使用していることを示している。この場合、システムは、この携帯電話番号の真のユーザ（例えば、真のまたは正当な所有者）を決定することができない。したがって、サーバ（例えば、システム）は、方法４００の４０４または４０５に先立って、第１のユーザに照合手段を発行できる。照合プロセスは、既知のテキスト／ＳＭＳベースの照合方式を含むことができ、これに関しては、これ以上詳しく説明されない。例えば、幾つかの関連技術が、照合プロセスを説明している。照合に成功した場合は、第１のユーザ（Ｋｅｖｉｎ）が、競合する新ユーザになり（例えば、競合する新ユーザであると見なされ）、第２のユーザ（Ｔｏｎｙ）が、競合する新ユーザから競合する旧ユーザになる（例えば、競合する旧ユーザであると見なされる）。表１および表３を参照すると、照合に成功した場合、表１は、表３に対応するようにアップデートされる。例えば、第１のユーザに対応するアカウント記録は、競合識別パラメータを削除するようにアップデートでき、第２のユーザに対応するアカウント記録は、競合識別パラメータを追加するようにアップデートできる。このような設計は、「偽の二重発行番号」の問題を効果的に解決できるだろう。真の二重発行ユーザ識別子（例えば、携帯電話番号）は、携帯電話番号の所有者が変わることに相当する。しかしながら、「偽の二重発行ユーザ識別子」の場合、そのユーザ識別子（例えば、携帯電話番号）の二重発行は、ユーザ識別子（例えば、携帯電話番号）の又貸しに起因する。この種の又貸しは、サーバ（例えば、アプリケーションシステム）に、このようなユーザ識別子の使用をユーザ識別子（例えば、携帯電話番号）の二重発行の発生として捉えさせる。例えば、第１のユーザ（Ｋｅｖｉｎ）が、１８６１１１８０７５１の真の所有者であると見なされる。第１のユーザ（Ｋｅｖｉｎ）は、この携帯電話番号を使用して、Ａｌｉｐａｙシステムなどのサーバまたはアプリケーションに登録する。Ａｌｉｐａｙシステムは、アカウント記録を有する。第２のユーザ（Ｔｏｎｙ）が、第１のユーザ（Ｋｅｖｉｎ）の弟であり、第１のユーザの識別子（例えば、第１のユーザのアカウント記録に関係付けられた携帯電話番号）を一時的に使用すると仮定する。何らかの特別なまたは一時的な用途上の必要性がある場合、第２のユーザ（Ｔｏｎｙ）は、第１のユーザ（Ｋｅｖｉｎ）の携帯電話番号を一時的に使用してＡｌｉｐａｙアカウントに登録することがある。一部の実施形態では、プロセスは、方法２００の２０１〜２０８の処理をトリガする。その結果、第１のユーザ（Ｋｅｖｉｎ）は、Ａｌｉｐａｙシステムとの関係では競合する旧ユーザになり、その一方で、第２のユーザ（Ｔｏｎｙ）は、携帯電話番号を強制的に掌握して競合する新ユーザになる。第１のユーザ（Ｋｅｖｉｎ）が引き続きＡｌｉｐａｙシステムにログインする場合、Ａｌｉｐａｙシステムは、方法４００の４０３において、競合する旧ユーザである第１のユーザ（Ｋｅｖｉｎ）にユーザ識別子修正インターフェースを提供し、第１のユーザ（Ｋｅｖｉｎ）を、そのアカウント記録に関係付けられた携帯電話番号の修正に誘導する。この時点で、第１のユーザ（Ｋｅｖｉｎ）は、携帯電話番号「１８６１１１８０７５１」の真のユーザ（例えば、正当な所有者）であるので、第１のユーザは、依然として「１８６１１１８０７５１」をユーザ識別子修正インターフェースに入力するだろう。第１のユーザが依然として同じ携帯電話番号を入力する場合、Ａｌｉｐａｙシステムは、この時点で、第１のユーザ（Ｋｅｖｉｎ）が携帯電話番号の「逆掌握」を実行していると見なすだろう。第１のユーザが携帯電話番号の「逆掌握」を実行していると決定した場合、Ａｌｉｐａｙシステムは、照合メッセージを通じて第１のユーザによる携帯電話番号の「逆掌握」を立証しようと試みる。例えば、システムは、テキストメッセージまたはＳＭＳメッセージを携帯電話番号に送信することによって、第１のユーザに照合手段を送信できる。第１のユーザは、照合メッセージに含まれる情報を使用して、携帯電話番号の正当な使用または所有を立証できる。第１のユーザが照合にパスした場合は、第１のユーザ（Ｋｅｖｉｎ）は、競合する新ユーザになり（例えば、競合する新ユーザであると見なされ）、第２のユーザ（Ｔｏｎｙ）は、競合する旧ユーザになる（例えば、競合する旧ユーザであると見なされる）。第２のユーザ（Ｔｏｎｙ）が引き続きＡｌｉｐａｙシステムにログインする場合、Ａｌｉｐａｙシステムは、第２のユーザ（Ｔｏｎｙ）にユーザ識別子修正インターフェースを提供し、第２のユーザを、その携帯電話番号を修正するためのプロセスに誘導する。例えば、ユーザ識別子修正インターフェースは、第２のユーザにその携帯電話番号をアップデートするように指示することができる。第２のユーザ（Ｔｏｎｙ）が、自身のアカウント記録に関係付けられた携帯電話番号を修正した場合（例えば、もし、アカウント記録に関係付けられた携帯電話番号が、「１８６２２２２３３３３」に修正されたならば）、競合（例えば、第１のユーザのアカウント記録に関係付けられた携帯電話番号と、第２のユーザのアカウント記録に関係付けられた携帯電話番号との競合）は解消される（例えば、存在しなくなる）。

一部の実施形態は、メインアカウントに関係する独立したサブアカウントを作成するためのメカニズム（例えば、方法またはシステム）を提供する。例えば、一部の実施形態は、特定のユーザ識別子に関係付けられた、メインアカウントに対するサブアカウントの作成を可能にする。一例として、ユーザ（例えば、Ｊａｃｋ）が、１３９８８８８８８８８に相当する電話番号を有すると想定する。ユーザ（Ｊａｃｋ）は、この電話番号を使用して、第１のサブユーザ（例えば、Ｊａｃｋ１）に関係付けられたＡｌｉｐａｙアカウントを登録できる。例えば、ユーザは、自身の会社のための事務用品を購入するために、第１のサブユーザに関係付けられたアカウントを使用してよい。しかしながら、ユーザ（Ｊａｃｋ）は、携帯電話番号を使用して、別のＡｌｉｐａｙアカウントも登録したいかもしれない。一例として、ユーザは、この電話番号を使用して、第２のサブユーザ（Ｊａｃｋ２）に関係付けられたＡｌｉｐａｙアカウントを登録できる。例えば、ユーザは、自身のための個人的用品を購入するために、第２のサブユーザ（Ｊａｃｋ２）に関係付けられたアカウントを使用できる。したがって、法人使用を個人使用と差別化できる（例えば、会社による購入を個人による消費と明確に差別化できる）。従来の技術は、サブユーザに関係付けられたアカウントをメインアカウントに関係付けることを許していない。一部の実施形態では、サーバ（例えば、ユーザ管理デバイス１００の特別登録モジュール１２５）は、（メインアカウントとしてセットアップされた）現アカウントを通した現ユーザによるユーザログインの成功に続いて、同ユーザによって送信されたサブアカウント作成要求を受信すると、サブアカウント作成インターフェースをユーザにプッシュし、該インターフェース上でユーザによって入力されたログインパスワードが、ユーザが現時点でログインしているアカウント（例えば、メインアカウントまたは別のサブアカウント）のログインパスワードと同じであるかどうかをチェックする。サブアカウントの作成と関連付けてユーザによって入力されたログインパスワードが、ユーザが現時点でログインしているアカウント（またはメインアカウントに関係付けられたユーザ識別子に関係付けられた別のアカウント）に関係付けられたログインパスワードと同じである場合は、ユーザは、ログインパスワードを入力しなおすように（例えば、サーバによって）指示される。例えば、ユーザは、別のログインパスワードを選択するように指示される。そうではなく、サブアカウントの作成と関連付けてユーザによって入力されたログインパスワードが、ユーザが現時点でログインしているアカウント（またはメインアカウントに関係付けられたユーザ識別子に関係付けられた別のアカウント）に関係付けられたログインパスワードと同じでない場合は、現時点でログインされているアカウントのログイン名主要部（例えば、ユーザ識別子）と、ユーザによって入力されたログインパスワードとに基づいて、サブアカウントが（例えば、サーバによって）作成され、サブアカウントログイン名フィールドに、関係性識別パラメータが追加される。表４を参照すると、関係性識別パラメータとして、文字「Ｔ」が使用できる。サブアカウントの作成が成功した後、ユーザ（Ｊａｃｋ）は、２つのアカウントのそれぞれへの別々のログインのために、「１３９８８８８８８８８」を使用できる。一例として、パスワード「ａａａａａａ」を入力することによって、ユーザは、メインアカウント（Ｊａｃｋ）にログインでき、パスワード「ｄｄｄｄｄｄ」を入力することによって、ユーザは、サブアカウント（Ｊａｃｋ１）にログインできる。

図５は、本出願の様々な実施形態にしたがった、ログインパスワード回復に関係したインターフェースの図である。

図５を参照すると、ログインパスワード回復のためのプロセスと関連付けて表示されるインターネット３００が表示されている。一部の実施形態では、インターフェース５００は、図１のアカウント管理デバイス１００によって実現される。一部の実施形態では、インターフェース５００は、図２の方法２００に関連して実現される。一部の実施形態では、インターフェース５００は、図４の方法４００に関連して実現される。一部の実施形態では、インターフェース５００は、図６のシステム６００に実装される。例えば、インターフェース５００は、端末６１０によって表示できる。

インターフェース５００は、第２のユーザ（Ｔｏｎｙ）に対応する第１の照合サブインターフェース５１０と、第１のユーザ（Ｋｅｖｉｎ）に対応する第２の照合サブインターフェース５２０とを含むことができる。第１の照合サブインターフェース５１０は、第１の照合フィールド５１１と、第２の照合フィールド５１２と、照合プロセスを進めることができるサブミットフィールド５１３（例えば、ボタン）とを含むことができる。第２の照合サブインターフェース５２０は、第１の照合フィールド５２１と、第２の照合フィールド５２２と、照合プロセスを進めることができるサブミットフィールド５２３（例えば、ボタン）とを含むことができる。

図１に戻り、ユーザ管理デバイス１００は、パスワード回復モジュール１２９を含むことができる。パスワード回復モジュール１２９は、ユーザパスワード回復要求を受信すると、ユーザによって使用されているログイン名主要部がアカウントテーブル内の複数のアカウント記録に対応するかどうかを決定できる。ログイン名主要部が、アカウントテーブル内の複数のアカウント記録に対応する場合は、サーバ（例えば、パスワード回復モジュール１２９）は、インターフェース５００などの選択的回復検証インターフェースをユーザに送信できる。一部の実施形態では、選択的回復検証インターフェース（例えば、インターフェース５００）は、複数のアカウント記録のうちの複数に対応する照合選択肢を含む。例えば、選択的回復検証インターフェースは、複数のアカウント記録のうちの各アカウント記録に対応する照合選択肢を含むことができる。任意の一アカウントに対応する照合選択肢の検証が成功したと決定されると、そのアカウントのためのパスワードリセットインターフェースが現ユーザに送信される。一部の実施形態では、各照合選択肢は、ログイン名とは関係がない照合選択肢である。

一例として、第２のユーザ（Ｔｏｎｙ）が、第２のユーザに関係付けられたログインパスワードを忘れた、または第１のユーザ（Ｋｅｖｉｎ）が、第１のユーザに関係付けられたログインパスワードを忘れたと想定する。自身に関係付けられたログインパスワードを忘れたユーザは、パスワード回復要求をサブミットできる。パスワード回復要求は、対応するページ（例えば、ウェブページや、アプリケーション内で提供されたページなど）上でサブミットできる。従来の慣例にしたがうと、ユーザは、自身の携帯電話番号をインターフェース上に入力するように要求されることがある。しかしながら、ユーザの携帯電話番号が１８６１１１８０７５１であると想定すると、その携帯電話番号１８６１１１８０７５１は、第２のユーザ（Ｔｏｎｙ）および第１のユーザ（Ｋｅｖｉｎ）によって同時に使用されているので、サーバ（例えば、アプリケーションシステム）は、どのユーザがパスワード回復を要求しているかを決定できない。別の言い方をすると、もし、２つ以上のユーザアカウントが特定のユーザ識別子に関係付けられ、そのユーザ識別子が、パスワード回復要求に関係付けられたアカウントの識別に関連して使用されているならば、サーバは、どのユーザアカウントがパスワード回復要求に関係付けられているか、即ちパスワード回復要求をサブミットしているかを決定できない。一部の実施形態では、携帯電話番号が回避され（例えば、パスワード回復の目的のためとしては度外視され）、その代わりに、ユーザは、リンク先のメールボックス（例えば、ユーザの電子メールアドレス）またはその他の情報を入力することによって自身の身元を裏付けることを許可される。しかしながら、リンク先のメールアドレスを有さないユーザもいるだろう。代替の識別フィールドまたは代替の通信手段を使用したパスワード回復の提供は、適用性が十分に広範でない。一部の実施形態では、第２のユーザ（Ｔｏｎｙ）または第１のユーザ（Ｋｅｖｉｎ）は、パスワード回復に関係付けられた問題をマニュアルカスタマサービスを通じて解決することを要求されることがある（例えば、ユーザは、ヘルプデスクに連絡するように求められることがある）。しかしながら、パスワード回復を提供するためのこのようなマニュアルカスタマサービスは、ユーザエクスペリエンスに悪影響を及ぼすうえに、費用的に実現不可能である。

一部の実施形態では、パスワード回復は、携帯電話番号にまたはユーザ識別子に関係付けられたその他の通信手段に照合通知を送信することでは解決されない。なぜならば、別のユーザが、照合通知を通じてコンタクトを試みて、目的とされるユーザパスワードをリセットしかねないからである。例えば、ユーザ管理デバイス１００のパスワード回復モジュール１２９は、照合通知を１８６１１１８０７５１に送信することによってユーザの照合を行うことはない。なぜならば、このような照合プロセスは、第２のユーザ（Ｔｏｎｙ）が第１のユーザ（Ｋｅｖｉｎ）のログインパスワードをリセットする事態または第１のユーザ（Ｋｅｖｉｎ）が第２のユーザ（Ｔｏｎｙ）のログインパスワードをリセットする事態を招きかねないからである。

図５に示すように、パスワード回復のために、インターフェース５００がユーザに提供できる。一部の実施形態では、インターフェース５００は、選択的回復検証インターフェースに相当する。一例として、パスワード回復モジュール１２９は、選択的回復検証インターフェースを生成できる。選択的回復検証インターフェースは、一者または二者以上のユーザに対応する照合選択肢を含むことができる。例えば、選択的回復検証インターフェースは、第２のユーザ（Ｔｏｎｙ）および第１のユーザ（Ｋｅｖｉｎ）に対応する照合手段を含むことができる。選択的回復検証インターフェースは、現ユーザに提供できる。例えば、現ユーザは、選択的回復検証インターフェースを含むページへリダイレクトできる。選択的回復検証インターフェースを含むページは、ウェブページや、アプリケーション内のページなどであることができる。

一部の実施形態では、各ユーザが、通常は、自身の照合選択肢（例えば、１つのパスワード質問、または複数のパスワード質問を組み合わせたもの）を知っているので、様々な照合選択肢が、１つのメニューで提供可能である。ユーザが照合選択肢（例えば、ユーザがアプリケーションへの登録時などに最初に設定した質問）を忘れたかもしれない可能性を考慮して、ユーザは、ユーザアカウントに対応するインターフェースの提供を受けることができる。一部の実施形態では、選択的回復検証インターフェースは、ユーザアカウントに対応する照合サブインターフェース（例えば、図５で言うと、第２のユーザ（Ｔｏｎｙ）に対応する第１の照合サブインターフェース５１０および第１のユーザ（Ｋｅｖｉｎ）に対応する第２の照合サブインターフェース５２０）を含む。ユーザのそれぞれのサブインターフェースには、各ユーザの照合選択肢が提供される。例えば、第１のユーザのための照合選択肢は、第１のユーザに対応する第２の照合サブインターフェース５２０に提供される。一部の実施形態では、現ユーザは、自身に提供された照合サブインターフェースで照合を完成させることを選択できる。同じ原理により、１つの携帯電話番号をメインアカウントおよびサブアカウントが使用している場合も、パスワード回復処理に上述のプロセスフローを用いることができる。

図５に示すように、左側の照合サブインターフェース（例えば、第１の照合サブインターフェース５１０）が第２のユーザ（Ｔｏｎｙ）のためのアカウントに対応し、右側の照合サブインターフェース（例えば、第２の照合サブインターフェース５２０）が第１のユーザ（Ｋｅｖｉｎ）のためのアカウントに対応すると想定する。第２のユーザ（Ｔｏｎｙ）が現ユーザに相当する場合は、現ユーザは、第１の照合フィールド５１１および第２の照合フィールド５１２に提供された照合選択肢（例えば、「母親の誕生日」および「父親の出生地」）を完成させる。右側のサブインターフェースに提供された照合選択肢は、第２のユーザ（Ｔｏｎｙ）に関係付けられた照合選択肢に相当しないので、第２のユーザが、第２の照合サブインターフェース５２０の第１の照合フィールド５２１および第２の照合フィールド５２２に提供された照合選択肢を完成できる可能性は、非常に低い。反対に、第１のユーザ（Ｋｅｖｉｎ）が現ユーザに相当する場合は、現ユーザは、第２の照合サブインターフェース５２０の第１の照合フィールド５２１および第２の照合フィールド５２２に提供された照合選択肢（例えば、「小学校三年生のときの担任は？」および「いちばんお気に入りの映画は？」）を完成させる。

一部の実施形態では、照合選択肢は、１つのパスワード質問、または複数のパスワード質問を組み合わせのみならず、その他の形態の照合手段であることもできる。本出願は、照合選択肢のタイプまたはあり方に対し、特別な制約を課していない。一部の実施形態では、同じページ上に、二者または三者以上の競合するユーザ（例えば、同じユーザ識別子またはその他のログイン名に対応する二者または三者以上のユーザ）の照合選択肢が提供される。例えば、サーバは、ログイン名が競合するユーザの、複数の照合選択肢を分類し、同じページ上に列挙することができる。この手法は、照合選択肢の動作を通して現ユーザによって行われるパスワード回復に影響を及ぼさないのが一般的である。実際、ユーザが任意の照合サブインターフェース下で照合選択肢を動作させて照合に成功する限り、サーバ（例えば、アプリケーションシステム）は、現ユーザに対応するアカウント記録を決定することができる。一部の実施形態では、（例えば、もし、ユーザが登録時に適切な設定を行っていれば、）各アカウント記録が、１つまたは複数の対応する照合選択肢を有するのが一般的である。

前述のように、アカウントテーブルに含まれるユーザに関係付けられたログイン名フィールドは、競合識別パラメータまたは関係性識別パラメータを含むことができる。一部の実施形態では、競合識別パラメータは、関係性識別パラメータとは競合しない。一部の実施形態では、各タイプのパラメータのための文字選択と、各タイプのパラメータのための対応する位置とが定義できる。例えば、競合識別パラメータは、定義された第１の文字選択と、第１の対応する文字位置とに関係付けることができる。別の例として、関係性識別パラメータは、定義された第２の文字選択と、第２の対応する文字位置とに関係付けることができる。表５に示すように、競合識別パラメータのための選択された文字は、「Ｒ」であることができ、競合識別パラメータのための選択された文字位置は、仕切り文字「｜」の右側であることができる。反対に、関係性識別パラメータのための選択された文字は、「Ｔ」であることができ、関係性識別パラメータのための選択された文字位置は、競合識別パラメータ「Ｒ」の右側であることができる。各種の実施形態は、実際の業務上の用途のニーズに見合ったその他のデータ形式および定義を使用できる。場合によっては、番号の三重発行が発生するかもしれない、または１つのメインアカウントに基づいて複数の関連のサブアカウントを作成することをシステムがユーザに許可するかもしれない。このような場合、１つの競合識別パラメータではユーザ識別子の二重発行に関係した問題を解決するのに十分でないのが一般的である。一部の実施形態では、対応するフィールド（例えば、ログイン名フィールド）における識別パラメータの後ろに、幾つかの文字からなる乱数を含む文字列を追加できる。幾つかの文字からなる乱数の文字列は、１つのユーザ識別子（例えば、ログイン名主要部）に関係付けられた複数のアカウントを差別化できる。一部の実施形態では、便宜のために、従来のアカウント（例えば、競合する旧ユーザのアカウントまたはサブアカウントではないアカウント）に識別パラメータが導入される。例えば、表５に示すように、文字「Ａ」が、通常のアカウントを示すために使用できる。表５に示すように、「１３９００１００１１０｜Ａ９８７６８８ａｂ」は、通常のアカウントを表している。しかしながら、「１８６１１１８０７５１｜Ｒｋｔｔｄｉｈｓｓ」は、競合する旧ユーザを表している。さらに、表５に示すように、「１３９８８８８８８８８｜ＲＴ０２０８ａｄｋｚ」は、競合する旧ユーザを表している。また、ログイン名フィールドが「１３９８８８８８８８８｜ＲＴ０２０８ａｄｋｚ」であるユーザアカウントは、別のユーザのサブアカウントでもある（例えば、なぜならば、このフィールドに含まれる文字列は、仕切り文字「｜」の後ろに文字「Ｒ」および文字「Ｔ」を含むからである）。

図６は、本出願の様々な実施形態にしたがった、ユーザアカウント管理のためのシステムの構造ブロック図である。

図６に示すように、ユーザアカウント管理のためのシステム６００が提供される。一部の実施形態では、システム６００は、図２の方法２００を実行できる。一部の実施形態では、システム６００は、図４の方法４００を実行できる。一部の実施形態では、システム６００は、図３Ａのインターフェース３００、図３Ｂのインターフェース３５０、または図３Ｃのインターフェース３６０を実現できる。一部の実施形態では、システム６００は、図５のインターフェース５００を実現できる。

システム６００は、端末６１０と、サーバ６２０とを含むことができる。一部の実施形態では、システム６００は、端末６１０とサーバ６２０とがそれを通じて通信できるネットワーク６３０を含む。一部の実施形態では、端末６１０は、サーバに６２０にログインする。例えば、サーバ６２０は、端末（例えば、現ユーザ）がログインするアプリケーションまたはアプリケーションシステムを運営できる。

端末６１０は、サーバ６２０からインターフェースまたはページを受信できる。サーバ６２０からインターフェースまたはページを受信する場合に、端末６１０は、そのインターフェースをユーザに表示できる。端末６１０は、入力（例えば、ユーザ識別子、ログイン名主要部、ログインパスワードなどの情報のエントリ）をユーザから受信できる。端末６１０は、ユーザ識別子およびログインパスワードなどの情報をサーバ６２０に通信できる。例えば、端末６１０は、ログイン名およびログインパスワードを、登録要求やアクセス要求などと関連付けてサーバ６２０に通信できる。

サーバ６２０は、端末６１０（例えば、ユーザ）を認証できる。例えば、サーバ６２０は、端末６１０からログイン情報（例えば、ログイン名やログインパスワードなど）を受信できる。ログイン情報を受信すると、サーバ６２０は、端末の認証を行ったり、アプリケーションまたはアプリケーションシステムへのアクセスを提供したりできる。

一部の実施形態では、サーバ６２０は、ユーザアカウントを管理できる。例えば、サーバ６２０は、アプリケーションまたはアプリケーションシステムに関係付けられたユーザアカウントを管理できる。サーバ６２０は、データベース（例えば、アカウントテーブル）などにユーザ記録を格納するおよびデータベース（例えば、アカウントテーブル）内のユーザ記録をアップデートすることができる。

一部の実施形態では、サーバ６２０は、図２の方法２００を実行するために使用できる。一部の実施形態では、サーバ６２０は、図４の方法４００を実行するために使用できる。

図７は、本開示の様々な実施形態にしたがった、オブジェクトのシミュレーションシステムを動作させるためのコンピュータシステムの機能図である。

図７に示すように、ウェブサイトにアクセスするためのまたはウェブサイトにアクセスしている端末がモバイル端末であるかどうかを決定するためのコンピュータシステム７００が提供される。ビデオコールの実行には、その他のコンピュータシステムアーキテクチャおよびコンピュータシステム構成も使用できることが明らかである。後述のような様々なサブシステムを含むコンピュータシステム７００は、少なくとも１つのマイクロプロセッササブシステム（プロセッサまたは中央演算処理装置（ＣＰＵ）とも呼ばれる）７０２を含む。例えば、プロセッサ７０２は、シングルチッププロセッサによってまたは複数のプロセッサによって実現できる。一部の実施形態では、プロセッサ７０２は、コンピュータシステム７００の動作を制御する汎用デジタルプロセッサである。メモリ７１０から取り出された命令を使用して、プロセッサ７０２は、入力データの受信および操作、ならびに出力デバイス（例えば、ディスプレイ７１８）へのデータの出力および表示を制御する。

プロセッサ７０２は、メモリ７１０に双方向に接続され、該メモリ７１０は、通常はランダムアクセスメモリ（ＲＡＭ）である第１の一次ストレージと、通常は読み出し専用メモリ（ＲＯＭ）である第２の一次ストレージエリアとを含むことができる。当該分野で周知のように、一次ストレージは、汎用ストレージエリアとしておよびスクラッチパッドメモリとして使用でき、入力データおよび処理済みデータを格納するためにも使用できる。一次ストレージは、プロセッサ７０２上で起きるプロセスのためのその他のデータおよび命令に追加して、プログラミング命令およびデータも、データオブジェクトおよびテキストオブジェクトの形態で格納できる。やはり当該分野で周知のように、一次ストレージは、通常は、プロセッサ７０２がその機能（例えば、プログラムド命令）を実施するために使用する基本的な動作命令、プログラムコード、データ、およびオブジェクトを含む。例えば、メモリ７１０は、例えば、データアクセスが双方向または単方向のいずれである必要があるかに応じ、後述の任意の適切なコンピュータ読み取り可能ストレージ媒体を含むことができる。例えば、プロセッサ７０２は、頻繁に必要とされるデータを直接的に且つ非常に迅速に取り出してキャッシュメモリ（不図示）に格納することもできる。

着脱式大容量ストレージデバイス７１２は、コンピュータシステム７００のための追加のデータストレージ容量を提供し、双方向（読み出し／書き込み）にまたは単方向（読み出しのみ）のいずれかでプロセッサ７０２に接続される。例えば、ストレージ７１２は、磁気テープ、フラッシュメモリ、ＰＣカード、ポータブル大容量ストレージデバイス、ホログラフィックストレージデバイス、およびその他のストレージデバイスなどの、コンピュータ読み取り可能媒体を含むこともできる。例えば、固定大容量ストレージ７２０も、追加のデータストレージ容量を提供できる。大容量ストレージ７２０として最も一般的な例は、ハードディスクドライブである。大容量ストレージ７１２および固定大容量ストレージ７２０は、一般に、プロセッサ７０２によって通常は能動的に使用されていない追加のプログラミング命令やデータといったものを格納する。大容量ストレージ７１２および７２０に保持される情報は、必要に応じて、仮想メモリとしてメモリ７１０（例えば、ＲＡＭ）の一部に標準的に組み込み可能であることがわかる。

バス７１４は、プロセッサ７０２がストレージサブシステムにアクセスすることを可能にすることに加えて、その他のサブシステムおよびデバイスへのアクセスを可能にするためにも使用できる。図に示されるように、これらとしては、ディスプレイ７１８、ネットワークインターフェース７１６、キーボード７０４、およびポインティングデバイス７０６はもちろん、必要に応じて、補助入出力デバイスインターフェース、サウンドカード、スピーカ、およびその他のサブシステムが挙げられる。例えば、ポインティングデバイス７０６は、マウス、スタイラス、トラックボール、またはタブレットであってよく、グラフィカルユーザインターフェースとのやり取りに有用である。

ネットワークインターフェース７１６は、図に示されるようなネットワーク接続を使用してプロセッサ７０２が別のコンピュータ、コンピュータネットワーク、または電気通信ネットワークに接続されることを可能にする。例えば、ネットワークインターフェース７１６を通じて、プロセッサ７０２は、方法／プロセスのステップを実施する過程において、別のネットワークから情報（例えば、データオブジェクトもしくはプログラム命令）を受信できるまたは別のネットワークに情報を出力できる。情報は、プロセッサ上で実行される一連の命令として表されることが多く、別のネットワークから受信できるまたは別のネットワークに出力できる。コンピュータシステム７００を外部ネットワークに接続するためにおよびデータを標準プロトコルにしたがって転送するために、インターフェースカードまたは類似のデバイス、およびプロセッサ７０２によって実現される（例えば、プロセッサ７０２上で実行される／実施される）適切なソフトウェアが使用できる。例えば、本明細書で開示される様々なプロセスの実施形態は、プロセッサ７０２上で実行できる、または処理の一部を共有するリモートプロセッサと協働でインターネット、イントラネットネットワーク、もしくはローカルエリアネットワークなどのネットワークで実施できる。プロセッサ７０２には、ネットワークインターフェース７１６を通じて追加の大容量ストレージデバイス（不図示）も接続できる。

コンピュータシステム７００と協働して、補助入出力デバイスインターフェース（不図示）が使用できる。補助入出力デバイスインターフェースは、プロセッサ７０２がマイク、タッチセンサ式ディスプレイ、トランスデューサカードリーダ、テープリーダ、音声または手書き文字認識装置、生体認証リーダ、カメラ、ポータブル大容量ストレージデバイス、およびその他のコンピュータなどの他のデバイスにデータを送信することを、およびさらに一般的にはこれらの他のデバイスからデータを受信することを可能にする、汎用ならびに専用のインターフェースを含むことができる。

図７に示されるコンピュータシステムは、本明細書で開示される様々な実施形態での使用に適したコンピュータシステムの一例に過ぎない。このような使用に適したその他のコンピュータシステムは、より多くの、またはより少ないサブシステムを含むことができる。また、バス７１４は、サブシステムをリンクする働きをする任意の相互接続方式を例示したものである。異なる設定のサブシステムを有するその他のコンピュータアーキテクチャも利用できる。

上述されたモジュールは、１つ以上の汎用プロセッサ上で実行されるソフトウェアコンポーネントとして、またはプログラマブルロジックデバイス、および／もしくは特定の機能を実施するように設計された特殊用途向け集積回路などのハードウェアとして、またはそれらの組み合わせとして実装できる。一部の実施形態では、これらのモジュールは、本発明の実施形態で説明される方法を（パソコン、サーバ、ネットワーク機器等などの）コンピュータデバイスに実行させるための幾つかの命令を含み尚且つ（光ディスク、フラッシュストレージデバイス、モバイルハードディスク等などの）不揮発性ストレージ媒体に格納できるソフトウェア製品の形態で具現化できる。モジュールは、１つのデバイス上に実装されてよい、または複数のデバイスに分散されてよい。モジュールの機能は、互いに合体されてよい、または複数のサブモジュールにさらに分割されてよい。

代表的な１つの構成では、サーバなどの計算機器が、１つまたは複数のプロセッサ（ＣＰＵ）と、入力／出力インターフェースと、ネットワークインターフェースと、メモリとを含む。

メモリは、コンピュータ読み取り可能媒体内の揮発性ストレージデバイス、ランダムアクセスメモリ（ＲＡＭ）、および／または読み取り専用メモリ（ＲＯＭ）もしくはフラッシュメモリ（フラッシュＲＡＭ）などの不揮発性メモリの形態を含んでいてよい。メモリは、コンピュータ読み取り可能媒体の一例である。

永久および非永久の、着脱式および非着脱式の媒体を含む、コンピュータ読み取り可能媒体は、任意の方法または技術によって情報の格納を実現してよい。情報は、コンピュータ読み取り可能コマンド、データ構造、プログラムモジュール、またはその他のデータであることができる。コンピュータストレージ媒体の非限定的な例としては、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、その他のタイプのランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気的に消去可能なプログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくはその他のメモリ技術、読み出し専用のコンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多機能光ディスク（ＤＶＤ）、カセットタイプの磁気テープ、磁気テープおよび磁気ディスクストレージ、またはその他の磁気ストレージ機器が挙げられ、或いは、その他の任意の非伝達性の媒体が、コンピュータ機器によってアクセス可能な情報を格納するために使用されてよい。本文献で定義されるコンピュータ読み取り可能媒体は、変調データ信号および搬送波などの一時的なコンピュータ読み取り可能媒体（一過性の媒体）を含まない。

また、用語「を含む」または「を内包する」またはこれらの任意の変形が、非排他的な意味で捉えられることに留意せよ。したがって、一連の要素を含むプロセス、方法、商品、または機器は、これらの要素を含むのみならず、明示されていないその他の要素、またはこのようなプロセス、方法、商品、もしくは機器に本来備わっている要素も含む。さらなる制限がなければ、「…を含む」という表現は、上記要素を含むプロセス、方法、商品、または機器内にさらなる同一要素が存在することを排除しない。

上記の説明は、本出願の好ましい実施形態に過ぎず、本出願を制限する働きをするものではない。実施されるあらゆる変更形態、等価な代替形態、または改善が、本出願の保護範囲に内包されるとされる。

以上の実施形態は、理解を明瞭にする目的で幾らか詳細に説明されてきたが、本発明は、提供された詳細に限定されない。本発明を実現するには、数々の代替手法がある。開示された実施形態は、例示的なものであり、限定的なものではない。

ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準に適合するのではない場合は、ログインパスワード警告フィールド３４０ｂ内に警告が提供できる。ログインパスワード警告フィールド３４０ｂは、ログインパスワードフィールド３２０にエントリされたログインパスワードが許容可能ではないという旨の表示を提供できる。例えば、ログインパスワードフィールド３２０にエントリされたログインパスワードがあらかじめ定められた長さルールに適合しない場合は、ログインパスワード警告フィールド３４０ｂは、ログインパスワードフィールド３２０にエントリされたログインパスワードが（１つまたは複数の）セキュリティルールに適合しないという旨の表示を提供でき、ユーザは、あらかじめ定められた長さ（例えば、あらかじめ定められた最大桁数）を有するログインパスワードをログインパスワードフィールド３２０にエントリするように指示を受けることができる。

ログインパスワードフィールド３２０にエントリされたログインパスワードが全てのログインパスワード基準に適合するのではない場合は、ログインパスワード警告フィールド３４０ｃ内に警告が提供できる。ログインパスワード警告フィールド３４０ｃは、ログインパスワードフィールド３２０にエントリされたログインパスワードが許容可能ではないという旨の表示を提供できる。例えば、ログインパスワードフィールド３２０にエントリされたログインパスワードが指定文字ルールに適合しない場合は、ログインパスワード警告フィールド３４０ｃは、ログインパスワードフィールド３２０にエントリされたログインパスワードが（１つまたは複数の）セキュリティルールに適合しないという旨の表示を提供でき、ユーザは、あらかじめ定められた文字（例えば、ログインパスワードに含めることを要求される指定の文字）を有するログインパスワードをログインパスワードフィールド３２０にエントリするように指示を受けることができる。

ユーザアカウント記録のログイン名フィールドが競合識別パラメータを含む場合は、４０３において、ユーザ識別子修正インターフェースが現ユーザに提供される。例えば、４０３において、サーバは、ユーザ識別子修正インターフェース（例えば、ログイン名主要部修正インターフェース）を現ユーザに送信する。ユーザ識別子修正インターフェースは、現ユーザのアカウント記録に関係付けられたログイン名主要部の修正に現ユーザを誘導するように構成できる。

以上の実施形態は、理解を明瞭にする目的で幾らか詳細に説明されてきたが、本発明は、提供された詳細に限定されない。本発明を実現するには、数々の代替手法がある。開示された実施形態は、例示的なものであり、限定的なものではない。
本発明は、たとえば、以下のような態様で実現することもできる。
適用例１：
方法であって、
現ユーザから登録要求を受信することであって、前記登録要求は、ログイン名主要部を含む、登録要求の受信と、
競合する旧ユーザがデータベース内に存在するかどうかを決定することであって、前記競合する旧ユーザは、前記登録要求と関連付けて受信された前記ログイン名主要部と同じ競合するログイン名主要部を有する別のユーザに相当する、決定と、
前記競合する旧ユーザが存在する場合に、前記競合する旧ユーザに関係付けられたログインパスワードとは異なるログインパスワードを登録することをユーザに要求するログインパスワード差別化プロセスを実行することと、
前記異なるログインパスワードを前記現ユーザの登録と関連付けて前記データベースに格納することと、
を備える方法。
適用例２：
適用例１の方法であって、
前記競合する旧ユーザが存在するかどうかを決定することは、前記登録要求と関連付けて受信された前記ログイン名主要部に関係付けられたアカウントを求めて、アカウント記録を格納しているアカウントテーブルを検索することを含む、方法。
適用例３：
適用例１の方法であって、さらに、
前記競合する旧ユーザが存在しない場合に、前記登録要求と関連付けて受信された前記ログイン名主要部に関係付けられたアカウント記録を作成することを備える方法。
適用例４：
適用例１の方法であって、
前記ログインパスワード差別化プロセスは、少なくとも部分的に、前記競合する旧ユーザのアカウントに関係付けられた前記ログインパスワードに基づいて、ログインパスワードルールを決定することを含む、方法。
適用例５：
適用例４の方法であって、
前記ログインパスワード差別化プロセスは、
前記現ユーザからログインパスワードを受信することと、
前記現ユーザからの前記ログインパスワードが前記ログインパスワードルールに適合するかどうかを決定することと、
前記現ユーザから受信された前記ログインパスワードが前記ログインパスワードルールに適合する場合に、前記現ユーザのためのアカウントを作成することと、
を含む、方法。
適用例６：
適用例５の方法であって、
前記現ユーザのためのアカウントを作成することは、
少なくとも部分的に、前記ログイン名主要部と、前記現ユーザから受信された前記ログインパスワードとに基づいて、前記現ユーザの前記登録に関係付けられたユーザ記録をアカウントテーブル内に作成することと、
前記競合する旧ユーザの前記ログイン名主要部のログイン名フィールドに競合識別パラメータを導入することと、
を含む、方法。
適用例７：
適用例６の方法であって、
前記競合する旧ユーザの前記ログイン名主要部のログイン名フィールドに競合識別パラメータを導入することは、
前記アカウントテーブル内の、前記競合する旧ユーザに対応するアカウント記録を、前記ログイン名フィールド内に前記競合識別パラメータを含むようにアップデートすることを含む、方法。
適用例８：
適用例１の方法であって、さらに、
ユーザからログイン要求を受信することであって、前記ログイン要求と関連付けてログイン名主要部およびログインパスワードが受信される、ログイン要求の受信と、
前記ログイン要求と関連付けて受信された前記ログイン名主要部と前記ログインパスワードとの組み合わせに一致するアカウントが存在するかどうかを決定することと、
前記ログイン名主要部および前記ログインパスワードに関係付けられたアカウントが存在する場合に、前記ユーザがログインすることを許可することと、
前記ログイン名主要部および前記ログインパスワードに関係付けられたアカウントが存在しない場合に、前記ユーザのログインを拒絶することと、
を備える方法。
適用例９：
適用例１の方法であって、さらに、
ユーザがログインに成功した場合に、前記ユーザに関係付けられたユーザアカウント記録が競合識別パラメータを含むかどうかを決定することと、
前記ユーザアカウント記録が前記競合識別パラメータを含む場合に、ログイン名主要部修正インターフェースを前記ユーザに提供することと、
を備える方法。
適用例１０：
適用例９の方法であって、
前記ログイン名主要部修正インターフェースは、前記ユーザを、前記ユーザのユーザアカウント記録に関係付けられたログイン名主要部を修正するように誘導する、方法。
適用例１１：
適用例９の方法であって、さらに
前記ログイン名主要部修正インターフェースに入力された修正されたログイン名主要部を受信することと、
競合する新ユーザが存在するかどうかを決定することであって、前記競合する新ユーザは、前記修正されたログイン名主要部と同じである競合するログイン名主要部を有する別のユーザに相当する、決定と、
前記競合する新ユーザが存在する場合に、前記競合する新ユーザに関係付けられたユーザアカウント記録のログイン名フィールドを、競合識別パラメータを含むようにアップデートすることと、
前記競合する新ユーザが存在しない場合に、前記現ユーザの前記アカウント記録内の前記ログイン名主要部を、前記修正されたログイン名主要部を使用してアップデートすることと、
を備える方法。
適用例１２：
適用例１１の方法であって、
前記競合する新ユーザが存在する場合に、前記競合する新ユーザの前記ユーザアカウント記録は、前記競合する新ユーザが競合する旧ユーザに変換されるようにおよび前記現ユーザの前記アカウント記録からの前記ログイン名主要部から競合識別パラメータが削除されるようにアップデートされる、方法。
適用例１３：
適用例１の方法であって、
前記ログインパスワード差別化プロセスは、拒絶登録誘導モードまたはパスワードルール誘導モードのプロセスを含む、方法。
適用例１４：
適用例１３の方法であって、
前記拒絶登録モードは、
前記登録要求と関連付けて前記現ユーザから受信された前記ログインパスワードが、前記競合する旧ユーザのアカウントに関係付けられたログインパスワードと同じであるかどうかを決定することと、
前記登録要求と関連付けて受信された前記ログインパスワードが、前記競合する旧ユーザの前記アカウントに関係付けられた前記ログインパスワードと同じである場合に、登録を拒絶し、前記登録要求と関連付けて受信された前記ログインパスワードが前記現ユーザに対するセキュリティルールに適合しないという旨の表示を提供することと、
を含む、方法。
適用例１５：
適用例１４の方法であって、さらに、
正の整数Ｎを選択することと、
前記現ユーザから受信されたＮ回の登録要求を拒絶し、前記Ｎ回の各登録要求の受信を受けて、前記ログインパスワードが前記セキュリティルールに適合しないという旨の表示を提供することと、
（Ｎ＋１）回目の登録要求を前記現ユーザから受信することと、
前記（Ｎ＋１）回目の登録要求と関連付けて前記現ユーザから受信されたログインパスワードが、前記競合する旧ユーザの前記アカウントに関係付けられた前記ログインパスワードと同じであるかどうかを決定することと、
前記（Ｎ＋１）回目の登録要求と関連付けて受信された前記ログインパスワードが、前記競合する旧ユーザの前記アカウントに関係付けられた前記ログインパスワードと同じである場合に、前記（Ｎ＋１）回目の登録要求と関連付けて受信された前記ログインパスワードが前記セキュリティルールに適合しないという旨の表示を提供することと、
前記（Ｎ＋１）回目の登録要求と関連付けて受信された前記ログインパスワードが、前記競合する旧ユーザの前記アカウントに関係付けられた前記ログインパスワードと同じではない場合に、前記現ユーザを登録することと、
を備える方法。
適用例１６：
適用例１３の方法であって、
前記パスワードルール誘導モードは、長さルール誘導モード、指定文字誘導モード、または文字クラス誘導モードに相当する、方法。
適用例１７：
適用例１６の方法であって、
前記長さルール誘導モードは、
前記登録要求と関連付けて前記現ユーザから受信された前記ログインパスワードが指定文字を含むかどうかを決定することと、
前記ログインパスワードが前記指定文字を含む場合に、前記ユーザを登録することと、
前記ログインパスワードが前記指定文字を含まない場合に、前記指定文字を含むログインパスワードを入力するように前記現ユーザに指示することであって、前記競合する旧ユーザのアカウントに関係付けられた前記ログインパスワードは、前記指定文字を含まない、前記現ユーザへの指示と、
を含む、方法。
適用例１８：
適用例１６の方法であって、
前記指定文字誘導モードは、
前記登録要求と関連付けて前記現ユーザから受信された前記ログインパスワードがあらかじめ定められた長さルールに適合するかどうかを決定することと、
前記ログインパスワードが前記あらかじめ定められた長さルールに適合する場合に、前記ユーザを登録することと、
前記ログインパスワードが前記あらかじめ定められた長さルールに適合しない場合に、前記あらかじめ定められた長さルールに適合するログインパスワードを入力するように前記現ユーザに指示することであって、前記競合する旧ユーザのアカウントに関係付けられた前記ログインパスワードは、前記あらかじめ定められた長さルールに適合しない、前記現ユーザへの指示と、
を含む、方法。
適用例１９：
適用例１６の方法であって、
前記文字クラス誘導モードは、
前記登録要求と関連付けて前記現ユーザから受信された前記ログインパスワードがあらかじめ定められた文字クラスルールに適合するかどうかを決定することと、
前記ログインパスワードが前記あらかじめ定められた文字クラスルールに適合する場合に、前記ユーザを登録することと、
前記ログインパスワードが前記あらかじめ定められた文字クラスルールに適合しない場合に、前記あらかじめ定められた文字クラスルールに適合するログインパスワードを入力するように前記現ユーザに指示することであって、前記競合する旧ユーザのアカウントに関係付けられた前記ログインパスワードは、前記あらかじめ定められた文字クラスルールに適合しない、前記現ユーザへの指示と、
を含む、方法。
適用例２０：
適用例１の方法であって、さらに、
パスワード回復要求を受信することであって、前記回復要求と関連付けてログイン名主要部が受信される、パスワード回復要求の受信と、
前記ログイン名主要部に複数のアカウントが関係付けられているかどうかを決定することと、
前記回復要求と関連付けて受信された前記ログイン名主要部に複数のアカウントが関係付けられているとの決定を受けて、前記パスワード回復要求の送信元であるユーザに、選択的回復検証インターフェースを提供することであって、前記選択的回復検証インターフェースは、前記ログイン名主要部に関係付けられた前記複数のアカウントの各アカウントに対応する照合選択肢を含む、選択的回復検証インターフェースの提供と、
前記複数のアカウントのいずれかに対応する照合選択肢の検証が成功したとの決定を受けて、前記検証にパスしたアカウントのためのパスワードリセットインターフェースを、前記パスワード回復要求の送信元である前記ユーザに提供することであって、各照合選択肢は、前記ログイン名主要部とは関係がない照合選択肢である、パスワードリセットインターフェースの提供と、
を備える方法。
適用例２１：
適用例１の方法であって、さらに、
成功したユーザログイン後に、ユーザからサブアカウント作成要求を受信することと、
前記サブアカウント作成要求の送信元である前記ユーザに、サブアカウント作成インターフェースをプッシュすることと、
前記サブアカウント作成インターフェースへのログインパスワード入力を受信することと、
前記サブアカウント作成インターフェースに入力された前記ログインパスワードが、前記ユーザが現時点でログインしているアカウントに関係付けられたログインパスワードと同じであるかどうかを決定することと、
前記サブアカウント作成インターフェースに入力された前記ログインパスワードが同じである場合に、前記ログインパスワードを入力しなおすように前記ユーザに指示することと、
前記サブアカウント作成インターフェースに入力された前記ログインパスワードが同じではない場合に、前記現時点でログインされているアカウントの前記ログイン名主要部と、前記ユーザによって前記サブアカウント作成インターフェースに入力された前記ログインパスワードと、に基づいて、サブアカウントを作成し、サブアカウントログイン名フィールドに関係性識別パラメータを追加することと、
を備える方法。
適用例２２：
適用例１の方法であって、
ユーザアカウントを格納しているアカウントテーブルのログイン名フィールドは、ログイン名主要部と、乱数文字列と、仕切り文字とを含み、前記ログイン名主要部と前記乱数文字列との間には、競合識別パラメータが位置し、前記仕切り文字は、前記競合識別パラメータと前記ログイン名主要部との間に位置する、方法。
適用例２３：
デバイスであって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに接続され、前記少なくとも１つのプロセッサに命令を提供するように構成されたメモリと、を備え、
前記少なくとも１つのプロセッサは、
現ユーザから登録要求を受信することであって、前記登録要求は、ログイン名主要部を含む、登録要求の受信と、
競合する旧ユーザがデータベース内に存在するかどうかを決定することであって、前記競合する旧ユーザは、前記登録要求と関連付けて受信された前記ログイン名主要部と同じ競合するログイン名主要部を有する別のユーザに相当する、決定と、
前記競合する旧ユーザが存在する場合に、前記競合する旧ユーザに関係付けられたログインパスワードとは異なるログインパスワードを登録することをユーザに要求するログインパスワード差別化プロセスを実行することと、
前記異なるログインパスワードを前記現ユーザの登録と関連付けて前記データベースに格納することと、を行うように構成される、デバイス。
適用例２４：
非一過性のコンピュータ読み取り可能ストレージ媒体に記録された、取引を生成するためのコンピュータプログラム製品であって、
現ユーザから登録要求を受信するためのコンピュータ命令であって、前記登録要求は、ログイン名主要部を含む、コンピュータ命令と、
競合する旧ユーザがデータベース内に存在するかどうかを決定するためのコンピュータ命令であって、前記競合する旧ユーザは、前記登録要求と関連付けて受信された前記ログイン名主要部と同じ競合するログイン名主要部を有する別のユーザに相当する、コンピュータ命令と、
前記競合する旧ユーザが存在する場合に、前記競合する旧ユーザに関係付けられたログインパスワードとは異なるログインパスワードを登録することをユーザに要求するログインパスワード差別化プロセスを実行するためのコンピュータ命令と、
前記異なるログインパスワードを前記現ユーザの登録と関連付けて前記データベースに格納するためのコンピュータ命令と、
を備えるコンピュータプログラム製品。

Claims (24)

1. 方法であって、
   現ユーザから登録要求を受信することであって、前記登録要求は、ログイン名主要部を含む、登録要求の受信と、
   競合する旧ユーザがデータベース内に存在するかどうかを決定することであって、前記競合する旧ユーザは、前記登録要求と関連付けて受信された前記ログイン名主要部と同じ競合するログイン名主要部を有する別のユーザに相当する、決定と、
   前記競合する旧ユーザが存在する場合に、前記競合する旧ユーザに関係付けられたログインパスワードとは異なるログインパスワードを登録することをユーザに要求するログインパスワード差別化プロセスを実行することと、
   前記異なるログインパスワードを前記現ユーザの登録と関連付けて前記データベースに格納することと、
   を備える方法。
2. 請求項１に記載の方法であって、
   前記競合する旧ユーザが存在するかどうかを決定することは、前記登録要求と関連付けて受信された前記ログイン名主要部に関係付けられたアカウントを求めて、アカウント記録を格納しているアカウントテーブルを検索することを含む、方法。
3. 請求項１に記載の方法であって、さらに、
   前記競合する旧ユーザが存在しない場合に、前記登録要求と関連付けて受信された前記ログイン名主要部に関係付けられたアカウント記録を作成することを備える方法。
4. 請求項１に記載の方法であって、
   前記ログインパスワード差別化プロセスは、少なくとも部分的に、前記競合する旧ユーザのアカウントに関係付けられた前記ログインパスワードに基づいて、ログインパスワードルールを決定することを含む、方法。
5. 請求項４に記載の方法であって、
   前記ログインパスワード差別化プロセスは、
   前記現ユーザからログインパスワードを受信することと、
   前記現ユーザからの前記ログインパスワードが前記ログインパスワードルールに適合するかどうかを決定することと、
   前記現ユーザから受信された前記ログインパスワードが前記ログインパスワードルールに適合する場合に、前記現ユーザのためのアカウントを作成することと、
   を含む、方法。
6. 請求項５に記載の方法であって、
   前記現ユーザのためのアカウントを作成することは、
   少なくとも部分的に、前記ログイン名主要部と、前記現ユーザから受信された前記ログインパスワードとに基づいて、前記現ユーザの前記登録に関係付けられたユーザ記録をアカウントテーブル内に作成することと、
   前記競合する旧ユーザの前記ログイン名主要部のログイン名フィールドに競合識別パラメータを導入することと、
   を含む、方法。
7. 請求項６に記載の方法であって、
   前記競合する旧ユーザの前記ログイン名主要部のログイン名フィールドに競合識別パラメータを導入することは、
   前記アカウントテーブル内の、前記競合する旧ユーザに対応するアカウント記録を、前記ログイン名フィールド内に前記競合識別パラメータを含むようにアップデートすることを含む、方法。
8. 請求項１に記載の方法であって、さらに、
   ユーザからログイン要求を受信することであって、前記ログイン要求と関連付けてログイン名主要部およびログインパスワードが受信される、ログイン要求の受信と、
   前記ログイン要求と関連付けて受信された前記ログイン名主要部と前記ログインパスワードとの組み合わせに一致するアカウントが存在するかどうかを決定することと、
   前記ログイン名主要部および前記ログインパスワードに関係付けられたアカウントが存在する場合に、前記ユーザがログインすることを許可することと、
   前記ログイン名主要部および前記ログインパスワードに関係付けられたアカウントが存在しない場合に、前記ユーザのログインを拒絶することと、
   を備える方法。
9. 請求項１に記載の方法であって、さらに、
   ユーザがログインに成功した場合に、前記ユーザに関係付けられたユーザアカウント記録が競合識別パラメータを含むかどうかを決定することと、
   前記ユーザアカウント記録が前記競合識別パラメータを含む場合に、ログイン名主要部修正インターフェースを前記ユーザに提供することと、
   を備える方法。
10. 請求項９に記載の方法であって、
    前記ログイン名主要部修正インターフェースは、前記ユーザを、前記ユーザのユーザアカウント記録に関係付けられたログイン名主要部を修正するように誘導する、方法。
11. 請求項９に記載の方法であって、さらに
    前記ログイン名主要部修正インターフェースに入力された修正されたログイン名主要部を受信することと、
    競合する新ユーザが存在するかどうかを決定することであって、前記競合する新ユーザは、前記修正されたログイン名主要部と同じである競合するログイン名主要部を有する別のユーザに相当する、決定と、
    前記競合する新ユーザが存在する場合に、前記競合する新ユーザに関係付けられたユーザアカウント記録のログイン名フィールドを、競合識別パラメータを含むようにアップデートすることと、
    前記競合する新ユーザが存在しない場合に、前記現ユーザの前記アカウント記録内の前記ログイン名主要部を、前記修正されたログイン名主要部を使用してアップデートすることと、
    を備える方法。
12. 請求項１１に記載の方法であって、
    前記競合する新ユーザが存在する場合に、前記競合する新ユーザの前記ユーザアカウント記録は、前記競合する新ユーザが競合する旧ユーザに変換されるようにおよび前記現ユーザの前記アカウント記録からの前記ログイン名主要部から競合識別パラメータが削除されるようにアップデートされる、方法。
13. 請求項１に記載の方法であって、
    前記ログインパスワード差別化プロセスは、拒絶登録誘導モードまたはパスワードルール誘導モードのプロセスを含む、方法。
14. 請求項１３に記載の方法であって、
    前記拒絶登録モードは、
    前記登録要求と関連付けて前記現ユーザから受信された前記ログインパスワードが、前記競合する旧ユーザのアカウントに関係付けられたログインパスワードと同じであるかどうかを決定することと、
    前記登録要求と関連付けて受信された前記ログインパスワードが、前記競合する旧ユーザの前記アカウントに関係付けられた前記ログインパスワードと同じである場合に、登録を拒絶し、前記登録要求と関連付けて受信された前記ログインパスワードが前記現ユーザに対するセキュリティルールに適合しないという旨の表示を提供することと、
    を含む、方法。
15. 請求項１４に記載の方法であって、さらに、
    正の整数Ｎを選択することと、
    前記現ユーザから受信されたＮ回の登録要求を拒絶し、前記Ｎ回の各登録要求の受信を受けて、前記ログインパスワードが前記セキュリティルールに適合しないという旨の表示を提供することと、
    （Ｎ＋１）回目の登録要求を前記現ユーザから受信することと、
    前記（Ｎ＋１）回目の登録要求と関連付けて前記現ユーザから受信されたログインパスワードが、前記競合する旧ユーザの前記アカウントに関係付けられた前記ログインパスワードと同じであるかどうかを決定することと、
    前記（Ｎ＋１）回目の登録要求と関連付けて受信された前記ログインパスワードが、前記競合する旧ユーザの前記アカウントに関係付けられた前記ログインパスワードと同じである場合に、前記（Ｎ＋１）回目の登録要求と関連付けて受信された前記ログインパスワードが前記セキュリティルールに適合しないという旨の表示を提供することと、
    前記（Ｎ＋１）回目の登録要求と関連付けて受信された前記ログインパスワードが、前記競合する旧ユーザの前記アカウントに関係付けられた前記ログインパスワードと同じではない場合に、前記現ユーザを登録することと、
    を備える方法。
16. 請求項１３に記載の方法であって、
    前記パスワードルール誘導モードは、長さルール誘導モード、指定文字誘導モード、または文字クラス誘導モードに相当する、方法。
17. 請求項１６に記載の方法であって、
    前記長さルール誘導モードは、
    前記登録要求と関連付けて前記現ユーザから受信された前記ログインパスワードが指定文字を含むかどうかを決定することと、
    前記ログインパスワードが前記指定文字を含む場合に、前記ユーザを登録することと、
    前記ログインパスワードが前記指定文字を含まない場合に、前記指定文字を含むログインパスワードを入力するように前記現ユーザに指示することであって、前記競合する旧ユーザのアカウントに関係付けられた前記ログインパスワードは、前記指定文字を含まない、前記現ユーザへの指示と、
    を含む、方法。
18. 請求項１６に記載の方法であって、
    前記指定文字誘導モードは、
    前記登録要求と関連付けて前記現ユーザから受信された前記ログインパスワードがあらかじめ定められた長さルールに適合するかどうかを決定することと、
    前記ログインパスワードが前記あらかじめ定められた長さルールに適合する場合に、前記ユーザを登録することと、
    前記ログインパスワードが前記あらかじめ定められた長さルールに適合しない場合に、前記あらかじめ定められた長さルールに適合するログインパスワードを入力するように前記現ユーザに指示することであって、前記競合する旧ユーザのアカウントに関係付けられた前記ログインパスワードは、前記あらかじめ定められた長さルールに適合しない、前記現ユーザへの指示と、
    を含む、方法。
19. 請求項１６に記載の方法であって、
    前記文字クラス誘導モードは、
    前記登録要求と関連付けて前記現ユーザから受信された前記ログインパスワードがあらかじめ定められた文字クラスルールに適合するかどうかを決定することと、
    前記ログインパスワードが前記あらかじめ定められた文字クラスルールに適合する場合に、前記ユーザを登録することと、
    前記ログインパスワードが前記あらかじめ定められた文字クラスルールに適合しない場合に、前記あらかじめ定められた文字クラスルールに適合するログインパスワードを入力するように前記現ユーザに指示することであって、前記競合する旧ユーザのアカウントに関係付けられた前記ログインパスワードは、前記あらかじめ定められた文字クラスルールに適合しない、前記現ユーザへの指示と、
    を含む、方法。
20. 請求項１に記載の方法であって、さらに、
    パスワード回復要求を受信することであって、前記回復要求と関連付けてログイン名主要部が受信される、パスワード回復要求の受信と、
    前記ログイン名主要部に複数のアカウントが関係付けられているかどうかを決定することと、
    前記回復要求と関連付けて受信された前記ログイン名主要部に複数のアカウントが関係付けられているとの決定を受けて、前記パスワード回復要求の送信元であるユーザに、選択的回復検証インターフェースを提供することであって、前記選択的回復検証インターフェースは、前記ログイン名主要部に関係付けられた前記複数のアカウントの各アカウントに対応する照合選択肢を含む、選択的回復検証インターフェースの提供と、
    前記複数のアカウントのいずれかに対応する照合選択肢の検証が成功したとの決定を受けて、前記検証にパスしたアカウントのためのパスワードリセットインターフェースを、前記パスワード回復要求の送信元である前記ユーザに提供することであって、各照合選択肢は、前記ログイン名主要部とは関係がない照合選択肢である、パスワードリセットインターフェースの提供と、
    を備える方法。
21. 請求項１に記載の方法であって、さらに、
    成功したユーザログイン後に、ユーザからサブアカウント作成要求を受信することと、
    前記サブアカウント作成要求の送信元である前記ユーザに、サブアカウント作成インターフェースをプッシュすることと、
    前記サブアカウント作成インターフェースへのログインパスワード入力を受信することと、
    前記サブアカウント作成インターフェースに入力された前記ログインパスワードが、前記ユーザが現時点でログインしているアカウントに関係付けられたログインパスワードと同じであるかどうかを決定することと、
    前記サブアカウント作成インターフェースに入力された前記ログインパスワードが同じである場合に、前記ログインパスワードを入力しなおすように前記ユーザに指示することと、
    前記サブアカウント作成インターフェースに入力された前記ログインパスワードが同じではない場合に、前記現時点でログインされているアカウントの前記ログイン名主要部と、前記ユーザによって前記サブアカウント作成インターフェースに入力された前記ログインパスワードと、に基づいて、サブアカウントを作成し、サブアカウントログイン名フィールドに関係性識別パラメータを追加することと、
    を備える方法。
22. 請求項１に記載の方法であって、
    ユーザアカウントを格納しているアカウントテーブルのログイン名フィールドは、ログイン名主要部と、乱数文字列と、仕切り文字とを含み、前記ログイン名主要部と前記乱数文字列との間には、競合識別パラメータが位置し、前記仕切り文字は、前記競合識別パラメータと前記ログイン名主要部との間に位置する、方法。
23. デバイスであって、
    少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに接続され、前記少なくとも１つのプロセッサに命令を提供するように構成されたメモリと、を備え、
    前記少なくとも１つのプロセッサは、
    現ユーザから登録要求を受信することであって、前記登録要求は、ログイン名主要部を含む、登録要求の受信と、
    競合する旧ユーザがデータベース内に存在するかどうかを決定することであって、前記競合する旧ユーザは、前記登録要求と関連付けて受信された前記ログイン名主要部と同じ競合するログイン名主要部を有する別のユーザに相当する、決定と、
    前記競合する旧ユーザが存在する場合に、前記競合する旧ユーザに関係付けられたログインパスワードとは異なるログインパスワードを登録することをユーザに要求するログインパスワード差別化プロセスを実行することと、
    前記異なるログインパスワードを前記現ユーザの登録と関連付けて前記データベースに格納することと、を行うように構成される、デバイス。
24. 非一過性のコンピュータ読み取り可能ストレージ媒体に記録された、取引を生成するためのコンピュータプログラム製品であって、
    現ユーザから登録要求を受信するためのコンピュータ命令であって、前記登録要求は、ログイン名主要部を含む、コンピュータ命令と、
    競合する旧ユーザがデータベース内に存在するかどうかを決定するためのコンピュータ命令であって、前記競合する旧ユーザは、前記登録要求と関連付けて受信された前記ログイン名主要部と同じ競合するログイン名主要部を有する別のユーザに相当する、コンピュータ命令と、
    前記競合する旧ユーザが存在する場合に、前記競合する旧ユーザに関係付けられたログインパスワードとは異なるログインパスワードを登録することをユーザに要求するログインパスワード差別化プロセスを実行するためのコンピュータ命令と、
    前記異なるログインパスワードを前記現ユーザの登録と関連付けて前記データベースに格納するためのコンピュータ命令と、
    を備えるコンピュータプログラム製品。

Images