JP2018536931A - 傍受防止認証および暗号化システムならびに方法 - Google Patents

Abstract

記号のセットからの記号で構成される個々のピンをもつパスコード、およびそのパスコードに対して使用された記号のセットからの少なくとも２つの記号を含むトークンを利用する、傍受防止認証および暗号化システムならびに方法が提供される。ユーザーが事前に選択したピン（記号）の一部または全部をトークンの一部または全部にランダムに挿入した、複数のトークン（トークンセット）がユーザーに提示される。ユーザーは、パスコード内の各ピン位置に対してトークンセットからトークンを選択する。ユーザーは、選択したトークンに基づいて認証される。各選択されたトークンは、ユーザーパスコード内の事前に選択されたピンの１つを含むこともあれば含まないこともあり、また、ユーザーパスコード内の事前に選択されたピンの１つではない他のランダムに生成された記号も含むので、ユーザーがどのトークンを選択したかを観察する人物は、何がユーザーの実際のパスコードであるかを判断できない。【選択図】図１５Ａ

Description

本発明は、認証および暗号化システムならびに方法に関し、より詳細には、傍受防止（ｉｎｔｅｒｃｅｐｔｉｏｎ−ｐｒｏｏｆ）認証および暗号化システムならびに方法に関する。

現代社会において、日常生活では、２〜３例を挙げると、携帯電話、ＰＣ、ノートブック、およびＡＴＭなどの、多種多様な情報機器の使用を必要とする。情報機器は、ユーザーの個人情報を保持し得る。この個人情報を保護する重要性に起因して、これらの機器を安全にロックおよびロック解除する方法がある。

現在のところ、これらの機器をロックおよびロック解除するために最も良く使用される方法は、パスワードベースのチャレンジ認証手順であり、それにより機器は通常、そのサービスにアクセスする前に、ユーザーが身元認証のためにユーザーｉｄおよびパスワードを入力することを要求する。これは、ログインとして知られている。このログインプロセスは、ユーザーの個人情報が盗まれたり、不正に変更されたりするのを防ぐために設計されている。

ネットワークカバレージおよびアクセス可能性の日々の急激な増大に伴い、ハッカーは、ユーザーの個人情報へのアクセスを得るためにユーザーのパスワードを標的にする可能性が高い。加えて、ハッカーは、ユーザーのパスワードを推測して破るのに、ますます洗練されてきている。従って、単純なパスワードはもはや、サイバー攻撃およびスパイ行為からの十分な保護を提供しない。

このような事情に鑑みて、より良い保護を提供するために様々な機構が実装されている。例えば、ユーザーは、パスワードの長さが、理論上は、総当たり探索攻撃および辞書攻撃をかわすのに十分であるような、パスワード長、複雑さ、および予測不可能性の要件を満たすパスワードを作成することを要求される。さらに、ユーザーは、自分のパスワードを定期的に変更して、古いパスワードを無効にすることを要求され、それにより、ユーザーのパスワードが破られる可能性を低下させる。これらの機構は、セキュリティをある程度実際に強化し、従って、ユーザーが自分のアカウントを保護するのを助ける。

しかし、各組織は、パスワード規則の異なるセットを有し得る。一部の組織は、パスワード長が少なくとも６文字または８文字であることを要求する。一部の組織は、大文字と小文字、および数字を混ぜ合わせた使用を要求する。一部の組織は、少なくとも１つの特殊文字を要求するが、ある組織は特殊文字を許可せず、そのため、全ての場所で使用できる非常に強力な黄金のパスワードをちょうど作り出したと考えた時に、その黄金のパスワードを無効にし得る異なるセットの要件を有する次の場所があるだろう。

これらの異なるパスワード規則の結果として、ユーザーが、異なるサイト／組織で設定している複数のパスワードを覚えることは、不可能ではないにしても、困難であり得る。従って、ユーザーは典型的には、自分のパスワードを、自分の情報機器上および／または自分の情報機器上で実行するパスワード記憶アプリケーション内に格納されているファイル内などに、格納する。格納されたパスワードは、ハッカーによって標的にされ得、ハッカーが、パスワードが格納されている装置にアクセスできると、ハッカーは全てのパスワードにアクセスして、ユーザーのパスワードで保護されたアカウント／サイトの全部にアクセスできる。それ故、弱すぎるパスワードを避けるためにパスワードに対して厳格な規則を実装することは、意図したものとは逆の効果となり得る（より多くの情報をさらすリスクが増大する）。

従来のパスワードに関連するこれらの問題を考慮して、これらの問題を解決しようとする新しい方法が開発されてきた。これらの方法は、ハッカーがピークしたり、盗んだりするのをもっと困難にするために、写真、グラフィック画像または異なる形状および色調を使用することを含み得るが、それらに制限されない。いくつかの技術は、ユーザーアクセスを認証するために、ジェスチャおよび入力画面のある位置における情報の位置決めさえ使用する。しかし、これらの方法のいずれも、ユーザーが装置にログインするたびにユーザーのすべての動きを記録できる隠しカメラに打ち勝つことができない。ハッカーがすべての記録を再生してユーザーのすべての動きを分析できる場合、ハッカーは最終的にアクセスできるであろう。

既存の認証方法に関連する主な問題は：
（１）従来のパスワードおよび秘密の質問（最も一般的に使用される方法）はピークを防止できない；
（２）グラフィック画像および写真ベースの方法は、ユーザーが画像または写真ファイルをアップロードすることを必要とし、システムは画像および／または写真を保存して維持する必要がある。これはユーザーおよびシステムの負担を増大させ、ハッカーがログインプロセスを記録して再生すると、画像でさえも認識できる；
（３）新しいグラフィックおよびジェスチャおよび／または位置ベースの認証方法は、人間とコンピュータとの間でのみ使用でき、従って、マシン対マシンでは使用できない、
ことである。

従って、前述した問題を提示しない認証および暗号化システムならびに方法に対する必要性がある。

本発明の目的は、少なくとも前述の問題および／または不都合な点を解決して、少なくとも以下で説明する利点を提供することである。

従って、本発明の目的は、ユーザーの認証のためのシステムおよび方法を提供することである。

本発明の別の目的は、電子装置へのアクセスを試みているユーザーの認証のためのシステムおよび方法を提供することである。

本発明の別の目的は、電子的に格納された情報へのアクセスを要求しているユーザーの認証のためのシステムおよび方法を提供することである。

本発明の別の目的は、ネットワーク上の装置へのアクセスを要求しているユーザーの認証のためのシステムおよび方法を提供することである。

本発明の別の目的は、所定の数の記号を含むパスコードを利用するユーザーの認証のためのシステムおよび方法を提供することである。

本発明の別の目的は、各トークンが、ユーザーパスコードを作成するために使用された記号のセットからの少なくとも２つの記号のグループである、複数のトークンを利用するユーザーの認証のためのシステムおよび方法を提供することである。

本発明の別の目的は、電子情報の暗号化および復号のためのシステムおよび方法を提供することである。

本発明の別の目的は、電子情報を暗号化および復号するために所定の数の記号を含むパスコードを利用する、電子情報の暗号化および復号のためのシステムおよび方法を提供することである。

本発明の別の目的は、各トークンが、パスコードを作成するために使用された記号のセットからの少なくとも２つの記号のグループである、複数のトークンと組み合わせた、所定の数の記号を含むパスコードを利用する、電子情報の暗号化および復号のためのシステムおよび方法を提供することである。

少なくとも前述の目的を、全体または一部において、達成するために、記号のセットから選択された所定の数の記号（「パスコード記号」）を含む所定のパスコードを使用してユーザーを認証する方法が提供され、所定のパスコード記号の各々は、所定のピン位置によって特徴付けられて、トークンセットをユーザーに提示することであって、トークンセットが、少なくとも２つのトークンを含み、トークンセット内の各トークンが、記号のセットに属する少なくとも２つの記号を含む、トークンセットをユーザーに提示することと、所定のパスコード内の各ピン位置に対してトークンセットから１つのトークンを選択することをユーザーに要求することと、ユーザーが選択したトークンに基づいてユーザーを認証することと、を含む。

少なくとも前述の目的を、全体または一部において、達成するために、記号のセットから選択された所定の数の記号（「パスコード記号」）を含む所定のパスコードを使用してユーザーを認証するためのシステムも提供され、所定のパスコード記号の各々は、所定のピン位置によって特徴付けられて、プロセッサと、プロセッサによってアクセス可能なメモリと、トークンセットをユーザーに提示することであって、トークンセットは、少なくとも２つのトークンを含み、トークンセット内の各トークンは、記号のセットに属する少なくとも２つの記号を含む、トークンセットをユーザーに提示すること、所定のパスコード内の各ピン位置に対してトークンセットから１つのトークンを選択することをユーザーに要求すること、およびユーザーが選択したトークンに基づいてユーザーを認証することを行うためにプロセッサによって実行可能なメモリ内に格納されたコンピュータ可読命令のセットを含む認証／暗号化モジュールとを含む。

本発明の追加の利点、目的、および特徴が、以下の記述で一部、説明され、以下を調べると、当業者には一部、明らかになるか、または本発明の実施から学習され得る。本発明の目的および利点は、添付のクレームで具体的に指摘されるように、実現および達成され得る。

本発明は、以下の図面を参照して詳細に説明され、図中、同様の参照番号は同様の要素を指す：

本発明の一実施形態に従い、クライアントシステムによってアクセスされる装置またはサーバーに組み込むことができる例示的な傍受防止認証／暗号化システムを示すブロック図である。 本発明の一実施形態に従い、装置に組み込まれた傍受防止認証／暗号化システムを示すブロック図である。 本発明の一実施形態に従い、クライアント装置によってネットワークを介してアクセスされるサーバーに組み込まれた傍受防止認証／暗号化システムを示すブロック図である。 本発明の一実施形態に従った、傍受防止認証／暗号化システムの１つの例示的なハードウェア実施態様の概略図である。 本発明の一実施形態に従い、４つの次元にグループ化された記号の例を示す。 本発明の一実施形態に従い、５つの次元にグループ化された記号の例を示す。 本発明の一実施形態に従い、ユーザーがパスコードを作成するのを可能にするために、認証／暗号化モジュールによって実装される例示的なプロセスを示す流れ図である。 本発明の一実施形態に従い、ユーザーを認証するために、認証／暗号化モジュールによって実装される例示的なプロセスを示す流れ図である。 本発明の一実施形態に従い、認証／暗号化モジュールによって使用される例示的なトークン生成規則をリストしているテーブルである。 本発明の一実施形態に従い、認証／暗号化モジュールによって使用される例示的なトークン選択規則をリストしているテーブルである。 本発明の一実施形態に従い、認証／暗号化モジュールによって使用される例示的なトークン検証規則をリストしているテーブルである。 本発明の一実施形態に従った、ＧＡＴＥ＿４実施形態におけるユーザーｉｄ作成（登録）プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿４実施形態におけるユーザーｉｄ作成（登録）プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、テキストフォーマットでのＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、テキストフォーマットでのＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、テキストフォーマットでのＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、テキストフォーマットでのＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿５実施形態におけるユーザーｉｄ作成（登録）プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿５実施形態におけるユーザーｉｄ作成（登録）プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、ＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、テキストフォーマットでのＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、テキストフォーマットでのＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、テキストフォーマットでのＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従った、テキストフォーマットでのＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、プレーンテキストメッセージが送信者パスコードで暗号化される、ＧＡＴＥ＿４実施形態を使用するメッセージ暗号化プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、成功裏の復号が行われる、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、成功裏の復号が行われる、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、暗号化された充填文字メッセージが受信者側で無効にされる、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、暗号化された充填文字メッセージが受信者側で無効にされる、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、送信者パスコードとは異なる受信者パスコードのために復号が失敗する、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、プレーンテキストメッセージが送信者パスコードで暗号化される、ＧＡＴＥ＿５実施形態を使用するメッセージ暗号化プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、成功裏の復号が行われる、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、成功裏の復号が行われる、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、暗号化された充填文字メッセージが受信者側で無効にされる、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、暗号化された充填文字メッセージが受信者側で無効にされる、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。 本発明の一実施形態に従い、送信者パスコードとは異なる受信者パスコードのために復号が失敗する、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。

本発明は、特別にプログラムされた装置と共に実装される新規の傍受防止認証および暗号化機構を提供する。認証のために、本発明は、装置のオペレーティングシステムの一部である記号で形成される「パスコード」を利用する。一例として、パスコードはこのように見える：

ユーザーに対して、前述のパスコードは、「私は電子メールを送るのが好きである」ことを意味し得、それは、覚えやすいが、他の人が知るのは困難である。パスコード内の各記号は、他のピンと相対的に対応するピン位置をもつ「ピン」として参照される。前述の例では、記号

は第１のピン位置にあり、記号

は第２のピン位置にあり、記号「２」は第３のピン位置にあり、記号

は第４のピン位置にある。

本発明は、好ましくは、装置のオペレーティングシステムの一部である記号の選択セットを利用し、従って、ユーザーにいかなる写真または画像もアップロードすることを要求しない、好ましくは「インシステム」である。パスコードまたは暗号化されたメッセージを作成するために使用される記号は、本明細書では「次元（ｄｉｍｅｎｓｉｏｎ）」と呼ばれる２つ以上のグループに好ましくはグループ化される異なるタイプである。これは、ユーザーに、自分のパスコードを作成する際に自身を表現するための多種多様な方法を与える。

本発明は、ユーザーのパスコードを構成するピンに対して使用された記号を、ユーザーのパスコードの一部ではない複数の他の記号の中に「隠す」ことによって、新規の傍受防止認証および暗号化機構を提供する。従って、本質的に、針を干し草の山の中に隠すことである。具体的には、本発明は、本明細書で「トークン」と呼ばれるものを利用する。トークンは、少なくとも２つの記号のグループである。ユーザーが事前に選択したピンの一部または全部をトークンの一部または全部にランダムに挿入した、複数のトークン（「トークンセット」）がユーザーに提示される。具体的には、ユーザーのパスコード内の各ピン（事前に選択した記号によって表される）が、ユーザーに提示されるトークンの１つに含まれ得る。ユーザーは、各選択したトークンのピン位置が、それを含むパスコードピンのピン位置に対応するように、パスコードを構成する個々のピンを含むトークンを選択する。各選択されたトークンは、ユーザーのパスコード内の事前に選択したピンの１つだけでなく、ユーザーのパスコード内の事前に選択したピンの１つではない他のランダムに生成された記号も含むので、ユーザーがどのトークンを選択しているかを観察する人物は、何がユーザーの実際のパスコードであるかを判断できない。

ユーザーがパスコードを提供するように要求されるたびに、ランダムに生成されたトークンの別のセットが、ユーザーのパスコード内で個々に事前に選択されたピンを多数のトークンの中にランダムに分散して、生成される。従って、ユーザーは、パスコードを提供するように要求されるたびに、異なるセットのトークンを選択し、それにより、観察者が、トークンの選択に基づいてユーザーのパスコードを判断するのを防ぐ。

説明のための例として、各次元が３６個の記号を含む、４グループの記号（４つの次元）が使用できる。ログインプロセス中、３６個のトークンがユーザーに対して表示され、各トークンは、４つの次元の記号の各々からの１つの記号を含む。所与の記号は、好ましくは１つのトークン内にのみ表示される（すなわち、記号が１つのトークン内に出現する場合、その記号は別のトークン内に再度出現しない）。この例では、３６個のトークンが表示されるので、４つの次元の各々内のすべての記号が表示される（３６個のトークンの各々内の各次元からの１つの記号）。

ユーザーのパスコード内のピン（記号によって表される）の数が変数「Ｎ」によって表される場合、ユーザーはＮ個のトークン（パスコードを構成する個々のピンを含むトークン、それにより各選択されたトークンのピン位置が、それを含むパスコードピンのピン位置に対応する）を選択する必要がある。

前述のように、本発明は、ユーザーが、パスコード内の各ピンに対して、パスコード内のピンの１つを含む、４つの記号を含むトークンを入力するので、ユーザーのパスコードの「ピークおよび傍受」の可能性を低下させる。従って、たとえユーザー入力が、ログイン画面を見ているハッカーによって、またはネットワークトラフィックを傍受しているハッカーによって、観察されても、ハッカーは、各トークン内の４つの記号のどれが、ユーザーのパスコードを構成する事前に選択されたピンの各々に対応するかを判断できないであろう。その結果、ハッカーがユーザーのアカウントにログインしようとしても、ハッカーは、ランダムに生成されたトークンの別のセットを提示され、そのうちのいくつかがユーザーのパスコードを構成するユーザーが事前に選択したピンを含み、ハッカーは、どのトークンを選択すべきかわからない。

しかし、ハッカーがユーザーログインプロセスを十分な回数、観察する場合、各ピンは、ユーザーが入力するトークン内に必ず出現するので、ハッカーは、どの各ピンがパスコード内にあるかを見つけるために、記録した全てのログインセッションを比較でき、ハッカーが、異なるログインセッションからの全ての１番目のトークンを比較すると、ハッカーは、最終的に１番目のピンを判断し、ハッカーが、全てのセッションからの全ての２番目のトークンを比較すると、ハッカーは、最終的に２番目のピンを判断する、等である。

それ故、ハッカーがパスコード内のピンを時間をかけて見つけるのを防ぐために、ユーザーに提示されるランダムに生成されたトークンの数は、好ましくは、各次元内の記号の数よりも少ない。例えば、１つ以上の次元の各々が３６個の記号を含む場合、ユーザーに対して１６個のトークンだけを提示するように選択し得る。この結果、ユーザーピンがトークン内に出現するかさえ保証されない。この実施形態では、ユーザーがログインを試みていて、ユーザーのパスコード内の１つ以上のピンがいずれのトークン内にも存在しない場合、ユーザーは、任意のトークンを、いずれのトークン内にも存在しないピンに対する「ワイルドカード」トークンとして選択する（それにより、選択されたワイルドカードトークンのピン位置は、不足しているパスコードピンのピン位置に対応する）。実際にはピンを含んでいないユーザーのピンの１つの代わりに、ランダムに選択されたトークンがあり得るので、これは、ハッカーの推測作業をずっと困難にする。

１つ以上の次元内の記号の数よりも少ないトークンを使用する（例えば、１つ以上の次元内の記号の数が３６の場合に１６個のトークンを使用する）別の利益は、事前に選択されたピンがトークン内にあるか否かをユーザーが迅速に見つけるのを簡単にすることであり、画面はユーザーに対してより単純に見える。

本発明は、好ましくは、本システムを組み込む装置のオペレーティングシステムの一部である記号を使用する。従って、特別なグラフィックまたは写真をユーザーによってシステム上にロードすることを要求されず、それ故、それらのプロパティを格納および維持するためのユーザーおよびシステム上の負荷を低減する。

本発明のシステムおよび方法は、ユーザーを認証するためだけでなく、情報の複数の部分を認証するためにも使用でき、従って、メッセージを暗号化するために使用できる。

図１Ａは、本発明の１つの好ましい実施形態に従い、クライアントシステムによってアクセスされる装置またはサーバーに組み込むことができる例示的な傍受防止認証／暗号化システム１００を示すブロック図である。システム１００は、傍受防止認証および／または暗号化機能を提供する認証／暗号化モジュール１１０を含む。システム１００は、任意選択として、ネットワーク１３０に接続できる。

図１Ｂは、本発明の１つの好ましい実施形態に従って、装置１５０に組み込まれた傍受防止認証／暗号化システムを示すブロック図である。装置１５０は、好ましくは、ユーザーインタフェースモジュール１２０を含む。認証／暗号化モジュール１１０は、以下でさらに詳細に説明するように、ユーザーのパスコードの安全な認証および／またはメッセージの暗号化を提供する。認証／暗号化モジュール１１０は、任意選択として、ネットワーク１３０に接続できる。

ユーザーインタフェースモジュール１２０は、例えば、グラフィカルユーザーインタフェース、ウェブベースのインタフェースおよび同様のものなどの、当技術分野で周知の任意のタイプのユーザーインタフェースで実装できる。一般に、ユーザーインタフェースモジュール１２０は、ユーザーが認証モジュール１１０とやり取りできるようにする任意のタイプのインタフェースで実装できる。

図１Ｃは、本発明の１つの好ましい実施形態に従い、クライアント装置１７０によりネットワーク１３０を介してアクセスされるサーバー１６０に組み込まれた傍受防止認証／暗号化システムを示すブロック図である。クライアント装置１７０は、サーバー１６０にネットワーク１３０を経由してアクセスできる任意のタイプのコンピュータまたは装置であり、好ましくは、ユーザーがクライアント装置１７０とやり取りできるようにするユーザーインタフェースモジュール１２０を含む。認証／暗号化モジュール１１０は、以下でさらに詳細に説明するように、ユーザーのパスコードの安全な認証および／またはメッセージの暗号化を提供する。

通信リンク１４０は、認証／暗号化モジュール１１０、ユーザーインタフェースモジュール１２０、ネットワーク１３０およびクライアント装置１７０の間の通信のために使用される。通信リンク１４０は、有線リンク、無線リンク、無線誘導リンク、容量性リンク、または電子構成要素を接続するための当技術分野で周知の任意の他の機構にできる。配線接続されたリンクは、例えば、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡバス、ビデオエレクトロニクススタンダーズアソシエーション（ＶＥＳＡ）ローカルバス、またはＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスなどの、バスで適切に実装できる。

無線リンクの例は、ＷＡＰ（ワイヤレスアプリケーションプロトコル）リンク、ＧＰＲＳ（汎用パケット無線サービス）リンク、ＧＳＭ（グローバルシステムフォーモバイルコミュニケーション）リンク、携帯電話チャネルなどの、ＣＤＭＡ（符号分割多重アクセス）またはＴＤＭＡ（時分割多重アクセス）リンク、ＧＰＳ（全地球測位システム）リンク、ＣＤＰＤ（セルラーデジタルパケットデータ）、ＲＩＭ（Ｒｅｓｅａｒｃｈ ｉｎ Ｍｏｒｔｉｏｎ，Ｌｉｍｉｔｅｄ）全二重ページングタイプ装置、Ｂｌｕｅｔｏｏｔｈ無線リンク、またはＩＥＥＥ８０２．１１ベースの無線周波数リンク（ＷｉＦｉ）を含むが、それらに制限されない。

ネットワーク１３０は、有線または無線ネットワークにでき、例えば、インターネット、イントラネット、ＰＡＮ（パーソナルエリアネットワーク）、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）もしくはＭＡＮ（メトロポリタンエリアネットワーク）、ストレージエリアネットワーク（ＳＡＮ）、フレームリレー接続、高度インテリジェントネットワーク（ＡＩＮ）接続、同期型光ネットワーク（ＳＯＮＥＴ）接続、デジタルＴ１、Ｔ３、Ｅ１もしくはＥ３回戦、デジタルデータサービス（ＤＤＳ）接続、ＤＳＬ（デジタル加入者回線）接続、イーサネット接続、ＩＳＤＮ（総合デジタル通信網）回線、Ｖ．９０、Ｖ．３４ｂｉｓアナログモデム接続などの電話回線ポート、ケーブルモデム、ＡＴＭ（非同期転送モード）接続、ＦＤＤＩ（光ファイバ分散データインタフェース）もしくはＣＤＤＩ（Ｃｏｐｐｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）接続の任意の１つ以上を含み得るか、またはそれとインタフェースをとり得る。

ユーザーインタフェースモジュール１２０は、例えば、グラフィカルユーザーインタフェース、ウェブベースのインタフェースおよび同様のものなどの、当技術分野で周知の任意のタイプのユーザーインタフェースで実装できる。一般に、ユーザーインタフェースモジュール１２０は、ユーザーが認証／暗号化モジュール１１０とやり取りできるようにする任意のタイプのインタフェースで実装できる。

用語「モジュール」は、本明細書では、現実世界の装置、構成要素、または、例えば、特定用途向け集積回路（ＡＳＩＣ）もしくはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含み得る、ハードウェアを使用して実装された構成要素の配列、またはマイクロプロセッサシステムおよび、（実行されている間に）モジュールの機能を実行するためにマイクロプロセッサシステムを専用装置に変換する、モジュールの機能を実装するための命令のセットを意味する。

モジュールは、ある機能がハードウェア単独によって促進され、他の機能がハードウェアとソフトウェアの組合せによって促進される、ハードウェア単独とソフトウェア制御ハードウェアの組合せとしても実装できる。ある実施態様では、モジュールの少なくとも一部、およびいくつかの場合には、モジュールの全部が、オペレーティングシステム、システムプログラム、およびアプリケーションプログラムを実行し、同時に、マルチタスク、マルチスレッディング、分散（例えば、クラウド）処理、もしくは他のかかる技術を使用して、モジュールも実装している、コンピュータまたは装置（例えば、サーバー１６０およびクライアント装置１７０など）のプロセッサ（複数可）上で実行できる。かかるコンピュータまたは装置の例は、パーソナルコンピュータ（例えば、デスクトップコンピュータまたはノートブックコンピュータ）、サーバー、現金自動預払機（ＡＴＭ）、ＰＯＳ端末、電化製品、およびスマートフォン、タブレット、または携帯情報端末（ＰＤＡ）などの、モバイルコンピューティング装置を含むが、それらに制限されない。さらに、サーバー１６０は、Ｗｉｎｄｏｗｓサーバー、Ｌｉｎｕｘサーバー、Ｕｎｉｘサーバーまたは同様のものなど、適切な任意のタイプのサーバーである。

図１Ｄは、本発明の一実施形態に従った、傍受防止認証／暗号化システム１００の１つの例示的なハードウェア実施態様の概略図である。図１Ｄの実施形態では、認証／暗号化モジュール１１０は、ＣＰＵ１１８およびメモリ１１２によって実装される。

ＣＰＵ１１８は、実行のために、メモリ１１２内に格納されたオペレーティングシステムコード１１４および他のプログラムコード１１６にアクセスする。認証／暗号化モジュール１１０の機能を実装するプログラムコード１１６は、ＣＰＵ１１８によるアクセスおよび実行のために、メモリ１１２内、または外部記憶装置（図示せず）上に格納される。

メモリ１２２は、例えば、ランダムアクセスメモリ（ＲＡＭ）、キャッシュメモリ、固定型不揮発性ハードディスクドライブ、取外し可能不揮発性フロッピィディスクドライブなどの、取外し可能／固定型記憶媒体、揮発性／不揮発性記憶媒体、光ディスクドライブ（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または任意の他の光記憶媒体など）、ＵＳＢフラッシュドライブ、およびメモリカードによって実装できる。

認証／暗号化モジュール１１０の機能をここで説明する。認証／暗号化モジュール１１０は、ユーザーログイン要求に応答して、ユーザーが事前に選択したピンをトークン内にランダムに挿入した複数のトークンをユーザーに（ユーザーインタフェースモジュール１２０を介して）表示することによって、パスコード／チャレンジ認証を提供する。前述のように、ユーザーのパスコード内の各ピン（事前に選択された記号によって表される）は、ユーザーに提示されるトークンの１つ内に含まれ得る。少なくとも１つのピンがトークンの１つ内に存在する。ユーザーは、パスコードを構成する個々のピンを含むトークンを選択し、それにより、各選択されたトークンのピン位置が、それを含むパスコードピンのピン位置に対応する。各選択されたトークンは、ユーザーのパスコード内の事前に選択されたピンの１つではないランダムに生成された記号、およびおそらくはユーザーのパスコード内の事前に選択されたピンの１つを含むので、ユーザーがどのトークンを選択したかを観察する人物は、何がユーザーの実際のパスワードであるかを判断できない。

認証／暗号化モジュール機能の２つの例示的な実施形態を以下で説明し、本明細書ではＧｒａｐｈｉｃａｌ Ａｃｃｅｓｓ Ｔａｂｕｌａｒ Ｅｎｔｒｙ＿４（「ＧＡＴＥ＿４））およびＧｒａｐｈｉｃａｌ Ａｃｃｅｓｓ Ｔａｂｕｌａｒ Ｅｎｔｒｙ＿５（「ＧＡＴＥ＿５））と呼ぶ。図２Ａに示すように、ＧＡＴＥ＿４実施形態は、各次元内に３６個の記号が含まれた、４つの次元の記号を使用する。図２Ｂに示すように、ＧＡＴＥ＿５実施形態は、各次元内に２６個の記号が含まれた、５つの次元の記号を使用する。図２Ａおよび図２Ｂに示す記号は、使用され得る記号のタイプの例であり、任意の他のタイプの記号が使用され得、依然として本発明の範囲内に含まれることが理解されよう。

図２Ａおよび図２Ｂに示す記号は、現代のコンピュータオペレーティングシステムで一般的に利用可能であり、作成するか、または本発明を組み込む既存のシステムにアップロード／保存する、いかなる特別なプロセスも必要としない。それらは、ほとんどのコンピュータオペレーティングシステム内で見られる標準的なＵｎｉｃｏｄｅシステムのサブセットである。各記号はＵｎｉｃｏｄｅ ＩＤを有し、良く知られている文字：ａ，ｂ，．．．ｚ，０，１，９，＠，＋，＜，％は全て、Ｕｎｉｃｏｄｅシステムの部分である。例えば：
Ｕｎｉｃｏｄｅ ＼ｕ００６２は文字ｂに対してである
Ｕｎｉｃｏｄｅ ＼ｕ２２０６は文字Δに対してである
Ｕｎｉｃｏｄｅ ＼ｕ００４０は文字＠に対してである
図２Ａおよび図２Ｂの実施形態に示す記号は、それらが多様で、独特であって、覚えやすいために含まれた。

図３は、本発明の一実施形態に従い、ユーザーがパスコードを作成できるようにするために、認証／暗号化モジュール１１０によって実装される例示的なプロセスを示す流れ図である。プロセスはステップ３１０から始まり、そこで、ユーザーは所望のユーザーｉｄを入力するように要求される。ステップ３２０で、認証／暗号化モジュール１１０は、ユーザーｉｄがメモリ１１２内に既に存在するかどうかを判断する。ユーザーｉｄが存在する場合、プロセスはステップ３３０に進む。そうでない場合、プロセスはステップ３４０に進む。

ステップ３３０で、ユーザーは、ユーザーｉｄと関連付けられた既存のパスワードを上書きしたいかどうか尋ねられる。ユーザーが「ｎｏ」を示す場合、プロセスはステップ３１０に飛んで戻る。ユーザーが「ｙｅｓ」を示す場合、プロセスはステップ３４０に進む。

ステップ３４０で、ユーザーが自分のパスコード内の各ピンに対して選択するために利用可能な記号がユーザーに対して表示される。次いで、ステップ３５０で、ユーザーは、表示されている記号の１つを、自分のパスコードに対するピンの１つとして選択するように要求される。ステップ３６０で、プロセスは、ユーザーが、現在選択されているピン（複数可）をパスコードとして保存すべきであると要求しているかどうかを判断する。これは、例えば、ユーザーがパスコードを保存する準備ができている場合にユーザーが選択できるアイコンを表示することによって、実装され得る。パスコードを保存すべきであることをユーザーが示していない場合、プロセスは折り返してステップ３５０に戻り、そこで、ユーザーは、パスコード内の別のピンに対して別の記号を選択する。ステップ３６０で、パスコードを保存すべきであることをユーザーが示している場合、プロセスはステップ３７０に進む。

ステップ３７０で、選択されたパスコードが所定の長さ要件（すなわち、ピンの所定の最小数）に適合するかどうかが判断される。選択されたパスコードが適合する場合、パスコードはステップ３８０で保存される。パスコードが適合しない場合、プロセスは折り返してステップ３５０に戻り、そこで、ユーザーは、追加のピンに対して記号を選択するように促される。

図４は、本発明の一実施形態に従い、ユーザーを認証するために、認証／暗号化モジュール１１０によって実装される例示的なプロセスを示す流れ図である。プロセスはステップ４１０から始まり、そこで、ログイン画面がユーザーに対して提示されて、ユーザーはユーザーｉｄを入力するように促される。プロセスは次いで、ステップ４２０に進み、そこで、認証／暗号化モジュール１１０は、ユーザーによって入力されたユーザーｉｄが存在するかどうかを判断する。存在する場合、プロセスはステップ４３０に進む。存在しない場合、プロセスは折り返してステップ４１０に戻り、そこで、ユーザーは別のユーザーｉｄを入力するように促される。

ステップ４３０で、認証／暗号化モジュールは、ユーザーのパスコードに対して使用されたピン数に基づいて所定の数のトークンを生成する。図４で説明する実施形態では、以下でさらに詳細に説明するように、１６個のトークンが生成されて、好ましくは４×４のトークンテーブルでユーザーに表示される。トークンは、図５に示すトークン生成規則に基づいて生成される。例では、１６個のトークンがテーブル内にあるが、実際には、ユーザーピン数より多い任意の数のトークンにでき、３×４、２×５、または任意の他の組み合わせで提示され、４×４はそれらを表示するのにちょうど好ましい方法である。

プロセスは次いで、ステップ４４０に進み、そこで、ユーザーは、図６に示すトークン選択規則に従って、ユーザーのパスコード内のピンを含むトークンを、ピンがパスコード内に出現する順に選択する。ステップ４５０で、認証／暗号化モジュール１１０は、ユーザーが選択したトークンが、図６に示すトークン選択規則に従うかどうかを判断する。トークン選択規則に従っている場合、プロセスはステップ４６０に進み、そこで、ユーザーが認証されてアクセスを許可される。トークン選択規則に従っていない場合、プロセスはステップ４７０に進み、そこで、ユーザーは認証されず、アクセスを拒否される。

前述のように、図５は、本発明の一実施形態に従い、認証／暗号化モジュール１１０によって使用される例示的なトークン生成規則をリストしているテーブルである。ユーザーのパスコード内のピンの少なくとも１つが、１６個のトークンの少なくとも１つ内にある。時には、ユーザーピンの全部がトークン内で見られ、大抵の場合、１〜Ｎ（Ｎは、Ｎ個のピンをもつユーザーパスコードの長さである）のユーザーが事前に選択したピンが１６個のトークン内にある。

図５に示す実施形態では、３６（ＧＡＴＥ＿４実施形態の場合）でも２６（ＧＡＴＥ＿５実施形態の場合）でもなく、１６個のトークンが生成される。従って、ＧＡＴＥ＿４実施形態の場合には、ユーザーのパスコード内のピンの１６／３６＝４４％だけが１６個のトークンの１つ内に出現し得る。ＧＡＴＥ＿５実施形態の場合には、ユーザーのパスコード内のピンの１６／２６＝６２％だけが１６個のトークンの１つ内に出現し得る。ユーザーのパスコード内のピンの全てがトークンテーブル内に出現し得る可能性があり、少なくとも１つのユーザーピンがトークンテーブル内に存在することが保証される。大抵の場合、ユーザーのパスコード内のピンのいくつかは抜けており、いくつかはトークン内に出現する。代替実施形態では、規則は、ユーザーのパスコード内のピンの少なくとも２または３がトークンテーブル内に存在するように変更できる。

本発明を効果的にするのは、この不確実性である。ログインプロセスがピークまたは傍受される場合、ハッカーにとって確かなことは、ユーザーがパスコード長よりも多いか、または少ないトークンを入力すると、ログインは失敗するので、パスコードの長さだけである。成功裏のログインとなる唯一のことは、保証はないが、ユーザーのパスコード内のピンと同じ数のトークンを入力することである。

しかし、たとえハッカーがパスコードの長さを学習しても、ハッカーは、個々のピンの識別を判断することができない。これは、たとえピンが必ずしも１６個のトークンの１つ内に出現しなくても、ユーザーは依然として成功裏にログインできるためである。これは、図６のトークン選択規則に示されるように、ユーザーが、提示されたトークンの１つ内に存在していないピンに対してランダムなトークンを選ぶことができるためである。

さらに、たとえユーザーパスコード内の全てのピンが１６個のトークン内に出現しても、ＧＡＴＥ＿４実施形態内に４つの記号があり、ＧＡＴＥ＿５実施形態内に５つの記号があるので、ハッカーは依然として、各トークン内のどの記号が事前に選択されたピンであるかを見分けることができないであろう。この不確実性は、本発明のシステムおよび方法が、ピークおよび傍受に耐えるようにする。

図６にリストしたトークン選択規則に示すように、有効なトークンを選択するための規則は、以下のように要約できる：
・ユーザーは、ユーザーのパスコード内のＮ個のピンに対応する、Ｎ個のトークンをトークンテーブルから選択しなければならない。従って、ユーザーのパスコードが４つのピンを有する場合、ユーザーは４つのトークンを選択する。同様に、ユーザーのパスコードが６つのピンを有する場合、ユーザーは６つのトークンを選択する必要がある。
・ユーザーのピンが１６個のトークンの１つ内に出現する場合、ユーザーは、ピンを入力するためにそのトークンを選択する必要がある。
・ユーザーのパスコード内のピンの１つが１６個のトークンのいずれにも存在しない場合、ユーザーはそのピンに対して１６個のトークンの任意の１つを選択する必要がある（以下、「ワイルドカードトークン」と呼ぶ）。

前述のように、図７は、本発明の一実施形態に従い、認証／暗号化モジュール１１０によって使用される例示的なトークン検証規則をリストしているテーブルである。これらの規則は、ユーザーがログインプロセスで選択したトークンを検証するためのものである。例えば、規則は、ユーザーによって入力されたトークンの数がユーザーのパスコードの長さに等しいかどうかを判断する。そうでない場合、ユーザーログインは失敗する。そうである場合、規則は、ユーザーのパスコード内の各ピンをチェックして、それが１６個のトークンの１つ内にあるかどうかを確認することを要求する。ユーザーのパスコード内のピンの１つがトークンの１つ内に存在しない場合、ユーザーはランダムなトークンを選択する必要がある。ユーザーのパスコード内のピンがトークンの１つ内に出現する場合、ユーザーはそのトークンを選択する必要がある。

図８Ａは、本発明の一実施形態に従い、図３のステップ３１０で、ユーザーｉｄを入力するための空の登録画面のサンプルスクリーンショットである。図は、ユーザーがユーザーｉｄを入力する前に、ＧＡＴＥ＿４実施形態の登録画面がどのように出現し得るかの例を示す。

図８Ｂは、本発明の一実施形態に従い、システム１００によって提示されるユーザーｉｄを作成するための登録プロセスの実行フレームのサンプルスクリーンショットである。それは、以下のように、ユーザーが図３の登録（ユーザーｉｄを作成する）プロセスを進むときに、ＧＡＴＥ＿４実施形態画面がどのように見え得るかの一例を示す：
・ユーザーが新しいユーザーｉｄ：「ａｄｍｉｎ」（Ｇ４ ２０６）を入力して、「Ｃｈｅｃｋ Ａｖａｉｌａｂｉｌｉｔｙ（利用可能性をチェックする）」ボタン（Ｇ４ ２０８）をクリックする。システムは、ＩＤ「ａｄｍｉｎ」が既にそのメモリ内にあるかどうかを確認する（図３のステップ３２０）。そうである場合、「ユーザーＩｄは既に存在します、既存のパスコードを上書きしますか？」と尋ねるダイアログ（図示せず）を表示する。ユーザーが古いパスコードを上書きしたくない場合、プロセスはダイアログを閉じて、ユーザーが別のユーザーｉｄを入力するのを待つ。ユーザーｉｄ「ａｄｍｉｎ」が存在しない場合、または存在するが、ユーザーが既存のパスコードを上書きしたい場合、システムは、図２Ａに示すような、各々が、事前に定義された次元からの３６個の記号を有する、Ｇ４ ２１２、Ｇ４ ２２２、Ｇ４ ２３２およびＧ４ ２４２におけるボタンを有効にする。例えば、Ｇ４ ２１２は、第１の次元から３６個全部の数字を含み、それらの記号は、Ｇ４ ２１０に見られるようにトークン内の「［１］」（左上）位置に現れる（数字は１〜３６である）。Ｇ４ ２２２は、

の３６個の記号を有し、それらは、任意のトークン内で「［２］」（Ｇ４ ２２０：右上）位置に現れる。Ｇ４ ２３２は、

の３６個の記号を有し、それらは、トークン内の「［３］」（Ｇ４ ２３０：左下）位置に現れ、Ｇ４ ２４２は、

の３６個の記号を有し、それらは、任意のトークン内で「［４］」（Ｇ４ ２４０：右下）位置に現れる。プロセスのこの段階で、システムは、Ｇ４ ２１２、Ｇ４ ２２２、Ｇ４ ２３２およびＧ４ ２４２における前述のボタンを有効にして、ユーザーがそれらの任意の１つをクリックできるようにする。比較として、図８Ａでは、ユーザーがまだユーザーｉｄを入力していないので、それらのボタンは有効にされておらず、薄く見える。ユーザーｉｄがなければ、ユーザーはパスコードを作成できない。
・ユーザーは、１番目のピンを選択するために、Ｇ４ ２２２内の記号の中で

をクリックし、するとそれがＧ４ ２５０に現れる（図３のステップ３５０）。
・ユーザーは、２番目のピンを選択するために、Ｇ４ ２３２内の記号の中で

をクリックし、するとそれがＧ４ ２５２に現れる（図３のステップ３５０）。
・ユーザーは、３番目のピンを選択するために、Ｇ４ ２１２内の記号の中で「２」をクリックし、するとそれがＧ４ ２５４に現れる（図３のステップ３５０）。
・ユーザーは、４番目のピンを選択するために、Ｇ４ ２４２内の記号の中で

をクリックし、するとそれがＧ４ ２５６に現れる（図３のステップ３５０）。
・この例では、ユーザーはパスコード内に４つのピンを有することを選択し、そのためパスコード長は４である。
・この例では、位置Ｇ４ ２５８およびＧ４ ２６０は空白のままである。
・ユーザーは次いで、「Ｓａｖｅ（保存）」ボタン−Ｇ４ ２７０をクリックすることによりユーザーｉｄ作成（登録）プロセスを終了する（図３のステップ３７０）。システムは、パスコード

をユーザーｉｄ「ａｄｍｉｎ」と共にメモリ内に保存する（図３のステップ３８０）。

前述のように、次元の選択肢は、図８Ｂの例に示す記号に限定されない。次元の選択肢は、任意の他の記号を含み得る。前述の例示的な実施形態では４つのユーザーピンがあるが、任意の数のピンが使用され得、依然として本発明の範囲に含まれる。ピンの数が少なすぎる場合、パスコードは脆弱すぎるであろう。ピンの数が多すぎる場合、ユーザーはパスコードを覚えない可能性がある。その結果、好ましい長さは、４〜６ピンである。

図９Ａは、ユーザーが任意の情報を入力する前に、本発明の一実施形態に従い、システム１００によって提示されるログイン画面の実行フレームのサンプルスクリーンショットである。図９Ａは、図９Ｂに対する比較として使用される。

図９Ｂは、本発明の一実施形態に従い、システム１００によって実行されるログインプロセスの実行フレームのサンプルスクリーンショットである。それは、以下のように、ユーザーが図４のログインプロセスを進むときに、ＧＡＴＥ＿４実施形態画面がどのように見え得るかの一例を示す：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ４ ３０６）を入力する（図４のステップ４１０）。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ４ ３０９）をクリックする。システムは、ｉｄ「ａｄｍｉｎ」が既にそのメモリ内にあるかどうかを確認し（図４のステップ４２０）、それが存在しない場合、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。存在する場合、システムは、４×４のテーブル（Ｇ４ ３２０）を表示する。テーブルをより良く説明するために、行は好ましくは、上から下へ次のように示される：Ａ、Ｂ、Ｃ、Ｄ。列も好ましくは、左から右へ次のように示される：１、２、３、４。このテーブル内のトークンは、図５で説明する規則に従って生成される。
・図８Ｂから、ユーザーｉｄ「ａｄｍｉｎ」に関連付けられたパスコードは：

であることが分かっているので、ユーザーは、１番目のピン：

を見つけるために、テーブル内の１６個のトークンを調べることから始める必要がある。記号

は、第２の次元に属するので、この例では、トークンの右上の位置に出現し、そのため、ユーザーは、

が存在するかどうか確認するために、各トークンの右上の位置に目を通すだけで良い。この例では、それは、トークンＤ２内にある。このスクリーンショットはデモモードで撮られており、デモモードでは、プログラムは、ユーザーがプロセスをより良く理解するために、一致している記号を強調表示する。リアルタイムでは、これは強調表示される必要はない。この例示では、Ｄ２内の

が強調表示される。それは、Ｄ２トークン内に見られるので、ユーザーは、図６で説明する規則に従い、このトークンをクリックする必要がある。
・ユーザーがＤ２をクリックすると、そのトークンがパスコードの１番目の位置（Ｇ４ ３５０）にコピーされる（図４のステップ４４０）。
・ユーザーパスコード内の２番目のピンは：

であり、この記号は第３の次元に属する。この例では、第３の次元の記号はトークンの左下側に出現する。従って、ユーザーは、１６個のトークンの各々の左下側を見るだけで良い。この例では、それはトークンＤ３内にある。従って、ユーザーは、Ｄ３をクリックすべきである（図４のステップ４４０）。この例示では、それは強調表示される。
・ユーザーがＤ３をクリックする（図４のステップ４４０）と、そのトークンがパスコードの２番目の位置（Ｇ４ ３５３）にコピーされる。
・パスコード内の３番目のピンは「２」であり、それは第１の次元に属する。従って、この例では、ユーザーは、１６個のトークンの各々の左上の位置を見るだけで良い。この例では、それは存在しない。トークン選択規則（図６）に従い、ユーザーは、そのピンの位置に対してワイルドカードトークン（任意のトークン）を選択できて、選択する必要がある。この例では、ユーザーは、トークンＣ３をランダムにクリックする。そのトークンが３番目のピン位置−Ｇ４ ３５６にコピーされる。
・４番目で最後のピンは

であり、この記号は第４の次元に属する。第４の次元の記号は、この例では、トークンの右下側に出現する。従って、ユーザーは、１６個のトークンの各々の右下側をチェックするだけで良い。この例では、それはトークンＢ３内にあり、そのためユーザーは、Ｂ３をクリックする必要がある（図４のステップ４４０）。この例示では、それは強調表示される。ユーザーがＢ３をクリックすると、トークンがパスコードの４番目の位置（Ｇ４ ３５９）にコピーされる。
・パスコード内には４つのピンしかないので、位置Ｇ４ ３６２およびＧ４ ３６５は空のままにされ、それらは空のまま残されるべきである。ユーザーが一方または両方の場所にトークンを入力すると、ユーザーが元の４つのピンよりも多くのトークンを入力した（図４のステップ４５０）ので、システムは、ユーザーアクセスを拒否する。
・ユーザーが４つ全部のトークンを入力すると、ユーザーは「Ｌｏｇｉｎ」（Ｇ４ ３７０）ボタンをクリックして、ユーザーがトークン選択プロセスを終了していることをシステムに知らせ、システムは、図７で説明する規則（図４のステップ４５０）に従って、入力されたトークンが有効であるかどうかを確認する。
・この例では、ユーザーが入力したトークンは有効であり、システムは、「ログイン成功」というメッセージ（Ｇ４ ３８０）を表示して、ユーザーアクセスを許可する（図４のステップ４６０）。

図９Ｃは、本発明の一実施形態に従い、失敗したログインプロセスに対して、システム１００によって実行されるログインプロセスの実行フレームのサンプルスクリーンショットである。それは、以下のように、ユーザーが失敗したログインプロセス（図４）を経験する場合に、ＧＡＴＥ＿４実施形態画面がどのように見え得るかの一例を示す：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ４ ３０７）を入力する（図４のステップ４１０）。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ４ ３１０）をクリックする。システムは、ｉｄ「ａｄｍｉｎ」が既にそのメモリ内にあるかどうかを確認し（図４のステップ４２０）、それが存在しない場合、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。存在する場合、システムは、４×４のテーブル（Ｇ４ ３２１）を表示する。テーブルをより良く説明するために、行は好ましくは、上から下へ次のように示される：Ａ、Ｂ、Ｃ、Ｄ。列も好ましくは、左から右へ次のように示される：１、２、３、４。このテーブル内のトークンは、図５で説明する規則に従って生成される。
・図８Ｂから、ユーザーｉｄ「ａｄｍｉｎ」に関連付けられたパスコードは：

であることが分かっているので、ユーザーは、１番目のピン：

を見つけるために、テーブル内の１６個のトークンを調べることから始める必要がある。記号

は、第２の次元に属するので、この例では、トークンの右上の位置に出現し、そのため、ユーザーは、

が存在するかどうか確認するために、各トークンの右上の位置に目を通すだけで良い。この例では、それは、トークンＡ１内にある。ユーザーは、図６で説明する規則に従い、このトークンをクリックする必要がある。
・ユーザーがＡ１をクリックすると、そのトークンがパスコードの１番目の位置（Ｇ４ ３５１）にコピーされる（図４のステップ４４０）。
・ユーザーパスコード内の２番目のピンは：

であり、この記号は第３の次元に属する。この例では、第３の次元の記号はトークンの左下側に出現する。従って、ユーザーは、１６個のトークンの各々の左下側を見るだけで良い。この例では、それはトークンＤ１内にある。従って、ユーザーは、Ｄ１をクリックすべきである（図４のステップ４４０）。しかし、この例では、ユーザーはこのトークンをクリックせず、代わりに、Ｂ４をクリックした。これは間違ったトークンであり、システムは、これをエラーとして記録して、ユーザーアクセスを拒否する。
・ユーザーがＢ４をクリックする（図４のステップ４４０）と、そのトークンがパスコードの２番目の位置（Ｇ４ ３５４）にコピーされる。
・パスコード内の３番目のピンは「２」であり、それは第１の次元に属する。従って、この例では、ユーザーは、１６個のトークンの各々の左上の位置を見るだけで良い。この例では、それは存在しない。トークン選択規則（図６）に従い、ユーザーは、そのピンの位置に対してワイルドカードトークン（任意のトークン）を選択できて、選択する必要がある。この例では、ユーザーは、トークンＣ４をランダムにクリックする。そのトークンが３番目のピン位置−Ｇ４ ３５７にコピーされる。
・４番目で最後のピンは

であり、この記号は第４の次元に属する。第４の次元の記号は、この例では、トークンの右下側に出現する。従って、ユーザーは、１６個のトークンの各々の右下側をチェックするだけで良い。この例では、それはトークンＡ２内にあり、そのためユーザーは、Ａ２をクリックする必要がある（図４のステップ４４０）。ユーザーがＡ２をクリックすると、トークンがパスコードの４番目の位置（Ｇ４ ３６０）にコピーされる。
・パスコード内には４つのピンしかないので、位置Ｇ４ ３６３およびＧ４ ３６６は空のままにされ、それらは空のまま残されるべきである。ユーザーが一方または両方の場所にトークンを入力すると、ユーザーが元の４つのピンよりも多くのトークンを入力した（図４のステップ４５０）ので、システムは、ユーザーアクセスを拒否する。
・ユーザーが４つ全部のトークンを入力すると、ユーザーは「Ｌｏｇｉｎ」（Ｇ４ ３７１）ボタンをクリックして、ユーザーがトークン選択プロセスを終了していることをシステムに知らせ、システムは、図７で説明する規則に従って、入力されたトークンが有効であるかどうかを確認する（図４のステップ４５０）。
・この例では、ユーザーが入力したトークンは無効であり、システムは、「ログインが失敗した」というメッセージ（Ｇ４ ３８１）を表示して、ユーザーに対してアクセスを拒否する（図４のステップ４７０）。

図９Ｄは、本発明の一実施形態に従い、別の失敗したログインプロセスに対して、システム１００によって実行されるログインプロセスの実行フレームのサンプルスクリーンショットである。それは、以下のように、ユーザーが失敗したログインプロセス（図４）を経験する場合に、ＧＡＴＥ＿４実施形態画面がどのように見え得るかの一例を示す：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ４ ３０８）を入力する（図４のステップ４１０）。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ４ ３１１）をクリックする。システムは、ｉｄ「ａｄｍｉｎ」が既にそのメモリ内にあるかどうかを確認し（図４のステップ４２０）、それが存在しない場合、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。存在する場合、システムは、４×４のテーブル（Ｇ４ ３２２）を表示する。テーブルをより良く説明するために、行は好ましくは、上から下へ次のように示される：Ａ、Ｂ、Ｃ、Ｄ。列も好ましくは、左から右へ次のように示される：１、２、３、４。このテーブル内のトークンは、図５で説明する規則に従って生成される。
・図８Ｂから、ユーザーｉｄ「ａｄｍｉｎ」に関連付けられたパスコードは：

であることが分かっているので、ユーザーは、１番目のピン：

を見つけるために、テーブル内の１６個のトークンを調べることから始める必要がある。記号

は、第２の次元に属するので、この例では、トークンの右上の位置に出現し、そのため、ユーザーは、

が存在するかどうか確認するために、各トークンの右上の位置に目を通すだけで良い。この例では、それは、トークンＢ２内にある。ユーザーは、図６で説明する規則に従い、このトークンをクリックする必要がある。
・ユーザーがＢ２をクリックすると、そのトークンがパスコードの１番目の位置（Ｇ４ ３５２）にコピーされる（図４のステップ４４０）。
・ユーザーパスコード内の２番目のピンは：

であり、この記号は第３の次元に属する。この例では、第３の次元の記号はトークンの左下側に出現する。従って、ユーザーは、１６個のトークンの各々の左下側を見るだけで良い。この例では、それは存在しない。トークン選択規則（図６）に従い、ユーザーは、そのピンの位置に対してワイルドカードトークン（任意のトークン）を選択できて、選択する必要がある。この例では、ユーザーは、トークンＡ４をランダムにクリックする。そのトークンが２番目のピン位置−Ｇ４ ３５５にコピーされる。
・パスコード内の３番目のピンは「２」であり、それは第１の次元に属する。従って、この例では、ユーザーは、１６個のトークンの各々の左上の位置を見るだけで良い。この例では、それは、トークンＢ３内にある。この例では、ユーザーはＢ３をクリックし、そのトークンが３番目のピン位置−Ｇ４ ３５８にコピーされる。
・４番目で最後のピンは

であり、この記号は第４の次元に属する。第４の次元の記号は、この例では、トークンの右下側に出現する。従って、ユーザーは、１６個のトークンの各々の右下側をチェックするだけで良い。この例では、それはトークンＤ１内にあり、そのためユーザーは、Ｄ１をクリックする必要がある（図４のステップ４４０）。ユーザーがＤ１をクリックすると、トークンがパスコードの４番目の位置（Ｇ４ ３６１）にコピーされる。
・パスコード内には４つのピンしかないので、位置Ｇ４ ３６４およびＧ４ ３６７は空のままにすべきである。この例では、ユーザーが余分なトークンＤ２を入力しており、ユーザーが元の４つのピンよりも多くを入力したので、システムは、従って、ユーザーに対してアクセスを拒否する。
・ユーザーが５つ全部のトークンを入力すると、ユーザーは「Ｌｏｇｉｎ」（Ｇ４ ３７２）ボタンをクリックして、ユーザーがトークン選択プロセスを終了していることをシステムに知らせ、システムは、図７で説明する規則に従って、入力されたトークンが有効であるかどうかを確認する（図４のステップ４５０）。
・この例では、ユーザーが多すぎるトークンを入力し、システムは、「ログインが失敗した」というメッセージ（Ｇ４ ３８２）を表示して、ユーザーに対してアクセスを拒否する（図４のステップ４７０）。

図１０Ａは、テキストフォーマットでのＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、プログラム開始時の空の画面を反映している。この画像は、以下の図１０Ｂ、図１０Ｃおよび図１０Ｄに対する比較の基礎として使用される。この画面は、場面の背後で何が起こるかの説明として示すだけである。それは、リアルタイムのユーザーログイン中には表示されない。

図１０Ｂは、テキストフォーマットでのＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、図９Ｂのユーザーログインプロセスが行われているときに場面の背後で何が起こるかを示し、図４のプロセスフローがサンプル実施形態でどのように見えるかを示す。これはデモに過ぎず、リアルタイムのユーザーログイン中には表示されない。図７に示すトークン検証規則を視覚的に説明するために使用される。

３つの列：「クライアント側」（左側）、「ネットワーク接続」（中央）、および「サーバー側」（右側）がある。ユーザーがユーザーｉｄを入力するとプロセスがクライアント側から開始して、情報がネットワーク接続を通してサーバー側に渡る。サーバーは１６個のトークンを生成し、それらをネットワークに渡し、次いで、トークンがクライアント側に渡される。

ユーザーは、図６に示すトークン選択規則に従ってトークンを選択する。選択されたトークンはネットワークに渡され、次いで、検証するためにサーバー側に渡され、アクセスの許可または拒否の結果がネットワークを通してクライアント側に渡される。プロセスフローが、図１０Ｂにおいて矢印によって示されている。以下でさらに詳細に説明する：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ４ ４０６）を入力する。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ４ ４０９）をクリックする。
・ユーザーｉｄ「ａｄｍｉｎ」（Ｇ４ ４０６）がクライアント側（Ｇ４ ４１１）に表示されて、ネットワーク接続（Ｇ４ ４１３）に渡され（Ｇ４ ４２１）、次いでそれはさらにサーバー側（Ｇ４ ４１５）に渡される（Ｇ４ ４２２）。
・サーバー側で、システムは、ユーザーｉｄ「ａｄｍｉｎ」が存在するかどうか、そのメモリを確認し、それが存在しない場合、システムは、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。図８Ｂからの同じ例が使用され、メモリ内のパスコードは：

であり、システムはそれをメモリ内で見つける（Ｇ４ ４１７）。
・システムは、図５に示すトークン生成規則に従って１６個のトークン（Ｇ４ ４２３）を生成する。
・１６個のトークンがネットワークに渡される（Ｇ４ ４２４）。
・ネットワークはそのトークンをクライアント側に渡す（Ｇ４ ４２５）。
・１６個のトークンは、図９Ｂに示すように、４×４のテーブル（図９ＢにおけるＧ４ ３２０）で、ユーザーログイン画面上に表示される。
・ユーザーは４つのトークン：Ｇ４ ３５０、Ｇ４ ３５３、Ｇ４ ３５６およびＧ４ ３５９を選択する（Ｇ４ ４２６）。
・ユーザーが「Ｌｏｇｉｎ」（図９ＢにおけるＧ４ ３７０）をクリックすると、ユーザーが選択した４つのトークンがネットワークに渡される（Ｇ４ ４２７）。
・ユーザーが選択した４つのトークンは、次いで、サーバー側に渡される（Ｇ４ ４２８）。
・サーバー側で、システムは、４つのトークン全部を１つずつチェックし：Ｃ１１、Ｃ１２、Ｃ１３およびＣ１４、この例では、それらは全て正しい。
・成功したログインという上の結果（Ｇ４ ４２９）が、ネットワークに渡される（Ｇ４ ４３０）。
・ネットワークはその結果をクライアント側に渡して（Ｇ４ ４３１）、図９ＢのＧ４ ３８０に示すメッセージを表示する（Ｇ４ ４３２）。

図１０Ｃは、テキストフォーマットでのＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、図９Ｃのユーザーログインプロセスが行われているときに場面の背後で何が起こるかを示し、図４のプロセスフローがサンプル実施形態でどのように見えるかを示す。これはデモに過ぎず、リアルタイムのユーザーログイン中には表示されない。図７に示すトークン検証規則を視覚的に説明するために使用される。

３つの列：「クライアント側」（左側）、「ネットワーク接続」（中央）、および「サーバー側」（右側）がある。ユーザーがユーザーｉｄを入力するとプロセスがクライアント側から開始し、次いで、情報がネットワーク接続を通してサーバー側に渡る。サーバーは１６個のトークンを生成し、それらをネットワークに渡し、次いで、トークンがクライアント側に渡される。

ユーザーは、図６に示すトークン選択規則に従ってトークンを選択する。選択されたトークンはネットワークに渡され、次いで、検証するためにサーバー側に渡され、アクセスの許可または拒否の結果がネットワークを通してクライアント側に渡される。プロセスフローが、図１０Ｃにおいて矢印によって示されている。以下でさらに詳細に説明する：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ４ ５０６）を入力する。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ４ ５０９）をクリックする。
・ユーザーｉｄ「ａｄｍｉｎ」（Ｇ４ ５０６）がクライアント側（Ｇ４ ５１１）に表示されて、ネットワーク接続（Ｇ４ ５１３）に渡され（Ｇ４ ５２１）、次いでそれはさらにサーバー側（Ｇ４ ５１５）に渡される（Ｇ４ ５２２）。
・サーバー側で、システムは、ユーザーｉｄ「ａｄｍｉｎ」が存在するかどうか、そのメモリを確認し、それが存在しない場合、システムは、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。図８Ｂからの同じ例が使用され、メモリ内のパスコードは：

であり、システムはそれをメモリ内で見つける（Ｇ４ ５１７）。
・システムは、図５に示すトークン生成規則に従って１６個のトークン（Ｇ４ ５２３）を生成する。
・１６個のトークンがネットワークに渡される（Ｇ４ ５２４）。
・ネットワークはそのトークンをクライアント側に渡す（Ｇ４ ５２５）。
・１６個のトークンは、図９Ｃに示すように、４×４のテーブル（図９ＣにおけるＧ４ ３２１）で、ユーザーログイン画面上に表示される。
・ユーザーは４つのトークン：Ｇ４ ３５１、Ｇ４ ３５４、Ｇ４ ３５７およびＧ４ ３６０を選択する（Ｇ４ ５２６）。
・ユーザーが「Ｌｏｇｉｎ」（図９ＣにおけるＧ４ ３７１）をクリックすると、ユーザーが選択した４つのトークンがネットワークに渡される（Ｇ４ ５２７）。
・ユーザーが選択した４つのトークンは、次いで、サーバー側に渡される（Ｇ４ ５２８）。
・サーバー側で、システムは、４つのトークン全部を１つずつチェックし：Ｃ２１、Ｃ２２、Ｃ２３およびＣ２４、この例では、２番目のトークンが正しくない（２番目のピン

はＤ１トークン内に存在するが、ユーザーはＢ４トークンを選択し、それは誤っていたため。従って、結果は失敗したログインとなる）。
・失敗したログインという上の結果（Ｇ４ ５２９）が、ネットワークに渡される（Ｇ４ ５３０）。
・ネットワークはその結果をクライアント側に渡して（Ｇ４ ５３１）、図９ＣのＧ４ ３８１に示すメッセージを表示する（Ｇ４ ５３２）。

図１０Ｄは、テキストフォーマットでのＧＡＴＥ＿４実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、図９Ｄのユーザーログインプロセスが行われているときに場面の背後で何が起こるかを示し、図４のプロセスフローがサンプル実施形態でどのように見えるかを示す。これはデモに過ぎず、リアルタイムのユーザーログイン中には表示されない。図７に示すトークン検証規則を視覚的に説明するために使用される。

３つの列：「クライアント側」（左側）、「ネットワーク接続」（中央）、および「サーバー側」（右側）がある。ユーザーがユーザーｉｄを入力するとプロセスがクライアント側から開始し、次いで、情報がネットワーク接続を通してサーバー側に渡る。サーバーは１６個のトークンを生成し、それらをネットワークに渡し、次いで、トークンがクライアント側に渡される。

ユーザーは、図６に示すトークン選択規則に従ってトークンを選択する。選択されたトークンはネットワークに渡され、次いで、検証するためにサーバー側に渡され、アクセスの許可または拒否の結果がネットワークを通してクライアント側に渡される。プロセスフローが、図１０Ｄにおいて矢印によって示されている。以下でさらに詳細に説明する：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ４ ６０６）を入力する。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ４ ６０９）をクリックする。
・ユーザーｉｄ「ａｄｍｉｎ」（Ｇ４ ６０６）がクライアント側（Ｇ４ ６１１）に表示されて、ネットワーク接続（Ｇ４ ６１３）に渡され（Ｇ４ ６２１）、次いでそれはさらにサーバー側（Ｇ４ ６１５）に渡される（Ｇ４ ６２２）。
・サーバー側で、システムは、ユーザーｉｄ「ａｄｍｉｎ」が存在するかどうか、そのメモリを確認し、それが存在しない場合、システムは、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。図８Ｂからの同じ例が使用され、メモリ内のパスコードは：

であり、システムはそれをメモリ内で見つける（Ｇ４ ６１７）。
・システムは、図５に示すトークン生成規則に従って１６個のトークン（Ｇ４ ６２３）を生成する。
・１６個のトークンがネットワークに渡される（Ｇ４ ６２４）。
・ネットワークはそのトークンをクライアント側に渡す（Ｇ４ ６２５）。
・１６個のトークンは、図９Ｄに示すように、４×４のテーブル（図９ＤにおけるＧ４ ３２２）で、ユーザーログイン画面上に表示される。
・ユーザーは５つのトークン：Ｇ４ ３５２、Ｇ４ ３５５、Ｇ４ ３５８、Ｇ４ ３６１およびＧ４ ３６４を選択する（Ｇ４ ６２６）。
・ユーザーが「Ｌｏｇｉｎ」（図９ＤにおけるＧ４ ３７２）をクリックすると、ユーザーが選択した５つのトークンがネットワークに渡される（Ｇ４ ６２７）。
・ユーザーが選択した５つのトークンは、次いで、サーバー側に渡される（Ｇ４ ６２８）。
・サーバー側で、システムは、５つのトークン全部を１つずつチェックし：Ｃ３１、Ｃ３２、Ｃ３３、Ｃ３４およびＣ３５、この例では、５番目のトークンが正しくない（パスコードには４つのピンしかないが、ユーザーは５番目のトークンを入力し、それは誤っていたため。従って、結果は失敗したログインとなる）。
・失敗したログインという上の結果（Ｇ４ ６２９）が、ネットワークに渡される（Ｇ４ ６３０）。
・ネットワークはその結果をクライアント側に渡して（Ｇ４ ６３１）、図９ＤのＧ４ ３８２に示すメッセージを表示する（Ｇ４ ６３２）。

図１１Ａは、ＧＡＴＥ＿５実施形態におけるユーザーｉｄ作成（登録）プロセスのサンプルスクリーンショットである。それは、プログラム開始時の空の画面を反映している。この画像は、以下の図１１Ｂに対する比較の基礎として使用される。

図１１Ｂは、ＧＡＴＥ＿５実施形態におけるユーザーｉｄ作成（登録）プロセスのサンプルスクリーンショットである。それは、記号の各次元がトークン内のどこに位置するかを示す。それは、ユーザーが新しいユーザーｉｄをどのように作成するか、また、ユーザーがユーザーｉｄと関連付けられたパスコードを形成するためにどのようにピンを選択して保存するかも反映している。プロセスは次のように進む：
・ユーザーが新しいユーザーｉｄ：「ａｄｍｉｎ」（Ｇ５ ２０６）を入力して、「Ｃｈｅｃｋ Ａｖａｉｌａｂｉｌｉｔｙ（利用可能性をチェックする）」ボタン（Ｇ５ ２０８）をクリックする。システムは、ｉｄ「ａｄｍｉｎ」が既にそのメモリ内にあるかどうかを確認し、そうである場合、「ユーザーＩｄは既に存在します、既存のパスコードを上書きしますか？」と尋ねるダイアログ（図示せず）を表示する。ユーザーが古いパスコードを上書きしたくない場合、プロセスはダイアログを閉じて、ユーザーが別のユーザーｉｄを入力するのを待つ。ユーザーｉｄ「ａｄｍｉｎ」が存在しない場合、または存在するが、ユーザーが既存のパスコードを上書きしたい場合、システムは、図２Ｂに示すような、各々が、事前に定義された次元からの２６個の記号を有する、Ｇ５ ２１２、Ｇ５ ２２２、Ｇ５ ２３２、Ｇ５ ２４２およびＧ５ ２４８におけるボタンを有効にする。
例えば、Ｇ５ ２１２は、第１の次元から２６個全部の記号を含み、それらの記号は、Ｇ５ ２１０に見られるようにトークン内の「［１］」（左上）位置に現れる。２６個の記号は、

である。Ｇ５ ２２２は、

の２６個の記号を表示し、それらは第２の次元からであり、任意のトークン内の「［２］」（Ｇ５ ２２０：右上）位置に現れる。Ｇ５ ２３２は、１〜２６の数字を表示し、それらは第３の次元からであり、トークン内の「［３］」（Ｇ５ ２３０：中央）位置に現れ、Ｇ５ ２４２は、

の２６個の記号を表示し、それらは第４の次元からであり、任意のトークン内で「［４］」（Ｇ５ ２４０：左下）位置に現れる。Ｇ５ ２４８は、

の２６個の記号を表示し、それらは第５の次元からであり、任意のトークン内で「［５］」（Ｇ５ ２４６：右下）位置に現れる。
プロセスのこの段階で、システムは、Ｇ５ ２１２、Ｇ５ ２２２、Ｇ５ ２３２、Ｇ５ ２４２およびＧ５ ２４８における前述のボタンを有効にして、ユーザーがそれらのどれでもクリックできるようにする。比較として、図１１Ａでは、ユーザーがまだユーザーｉｄを入力していないので、それらのボタンは有効にされておらず、薄く見える。ユーザーｉｄがなければ、ユーザーがピンを選択することは許可されない。
・ユーザーは、１番目のピンを選択するために、Ｇ５ ２４８内の記号の中で「＄」をクリックし、するとそれがＧ５ ２５０に現れる。
・ユーザーは、２番目のピンを選択するために、Ｇ５ ２４２内の記号の中で「＝」をクリックし、するとそれがＧ５ ２５２に現れる。
・ユーザーは、３番目のピンを選択するために、Ｇ５ ２１２内の記号の中で

をクリックし、するとそれがＧ５ ２５４に現れる。
・ユーザーは、４番目のピンを選択するために、Ｇ５ ２１２内の記号の中で

をクリックし、するとそれがＧ５ ２５６に現れる。
・ユーザーは、５番目のピンを選択するために、Ｇ５ ２３２内の記号の中で「２」をクリックし、するとそれがＧ５ ２５８に現れる。
・ユーザーは、６番目のピンを選択するために、Ｇ５ ２４２内の記号の中で

をクリックし、するとそれがＧ５ ２６０に現れる。
・この例では、ユーザーは自分のパスコード内に６つのピンを有することを選択し、そのためユーザーのパスコード長は６である。
・ユーザーは次いで、「Ｓａｖｅ（保存）」ボタン（Ｇ５ ２７０）をクリックすることによりユーザーｉｄ作成（登録）プロセスを終了する。システムは、パスコード

をユーザーｉｄ「ａｄｍｉｎ」と共にメモリ内に保存する。

図１２Ａは、ＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、プログラム開始時の空の画面を反映している。この画像は、以下の図１２Ｂ、図１２Ｃおよび図１２Ｄに対する比較の基礎として使用される。

図１２Ｂは、ＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、ユーザーがパスコードをそれから選択する１６個のトークンの４×４のテーブルを示している。それは、トークン選択プロセスがどのように機能するかを反映し、ユーザーが選択し、ユーザーピンをユーザーのパスコードの一部としてそれらの中に有する、トークン内の記号を強調表示する。それは、成功したログインプロセスがどのように見え得るかも示す。この例は図１１Ｂの例に従っており、そのため、同じパスコードが使用される。プロセスは、次のように進む：
・ユーザーが新しいユーザーｉｄ：「ａｄｍｉｎ」（Ｇ５ ３０６）を入力する。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ５ ３０９）をクリックする。システムは、ｉｄ「ａｄｍｉｎ」が既にそのメモリ内にあるかどうかを確認し、それが存在しない場合、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。存在する場合、システムは、４×４のテーブル（Ｇ５ ３２０）を表示し、テーブルをより良く説明するために、行は上から下へ：Ａ、Ｂ、Ｃ、Ｄと示され、列も左から右へ：１、２、３、４と示される。このテーブル内のトークンは、図５で説明する規則に従って生成される。
・図１１Ｂから、ユーザーｉｄ：「ａｄｍｉｎ」に関連付けられたパスコードは：

であることが分かっているので、ユーザーは、１番目のピン：「＄」を見つけるために、テーブル内の１６個のトークンを調べることから始める必要がある。
記号＄は、第５の次元に属するので、トークンの右下の位置にだけ出現し、そのため、ユーザーは、＄が存在するかどうか確認するために、各トークンの右下の位置に目を通すだけで良い。我々の例では、それは、トークンＢ４内にあり、画面はデモモードで撮られており、デモモードでは、プログラムは、ユーザーがプロセスをより良く理解するために、一致している記号を強調表示する。リアルタイムでは、それは強調表示されない。我々の事例では、Ｂ４内の＄が強調表示され、それは、Ｂ４トークン内に見られるので、ユーザーは、図６で説明する規則に従い、このトークンをクリックする必要がある。
・ユーザーがＢ４をクリックすると、そのトークンがパスコードの１番目の位置（Ｇ５ ３５０）にコピーされる。
・ユーザーパスコード内の２番目のピンは：「＝」であり、この記号は第４の次元に属し、第４の次元の記号はトークンの左下側にだけ出現するので、ユーザーは、１６個のトークンの各々の左下側を見るだけで良く、我々の事例では、それはトークンＤ２内にあり、そのため、ユーザーは、Ｄ２をクリックすべきである。それは、スクリーンショット内で強調表示される。
・ユーザーがＤ２をクリックすると、そのトークンがパスコードの２番目の位置（Ｇ５ ３５３）にコピーされる。
・パスコード内の３番目のピンは：

であり、それは第１の次元に属するので、ユーザーは、１６個のトークンの各々の左上の位置を見るだけで良く、我々の事例では、それはトークンＤ４内にあり、そのため、ユーザーは、Ｄ４をクリックすべきである。それは、スクリーンショット内で強調表示される。
・ユーザーがＤ４をクリックすると、そのトークンがパスコードの３番目の位置（Ｇ５ ３５６）にコピーされる。
・４番目のピンは

であり、この記号は第１の次元に属し、第１の次元の記号は、トークンの左上側にだけ出現するので、ユーザーは、１６個のトークンの各々の左上側をチェックするだけで良く、我々の事例では、それは存在せず、トークン選択規則に従い、ユーザーは、そのピンの位置に対してワイルドカードトークン（任意のトークン）を選択できて、選択する必要があるので、ユーザーは、ランダムなトークンＡ４をクリックし、そのトークンが４番目のピン位置Ｇ５ ３５９にコピーされる。
・パスコード内の５番目のピンは：「２」であり、それは第３の次元に属するので、ユーザーは、１６個のトークンの各々の中央を見るだけで良く、我々の事例では、それはトークンＤ２内にあり、そのため、ユーザーは、Ｄ２をクリックすべきである。それは、スクリーンショット内で強調表示される。ユーザークリックの後、そのトークンがパスコードの５番目の位置（Ｇ５ ３６２）にコピーされる。
・６番目で最後のピンは：

であり、この記号は第４の次元に属し、第４の次元の記号はトークンの左下側にだけ出現するので、ユーザーは、１６個のトークンの各々の左下側をチェックするだけで良く、我々の事例では、それはトークンＡ４内にあり、そのため、ユーザーは、Ａ４をクリックする必要がある。それは、デモプログラムによっても強調表示される。ユーザークリックの後、そのトークンがパスコードの６番目で最後の位置（Ｇ５ ３６５）にコピーされる。
・ユーザーが６つ全部のトークンを入力すると、ユーザーは「Ｌｏｇｉｎ」（Ｇ５ ３７０）ボタンをクリックして、ユーザーがトークン選択プロセスを終了していることをシステムに知らせ、システムは、図７で説明する規則に従って、入力されたトークンが有効であるかどうかを確認する。
・この例では、ユーザーが入力したトークンは有効であり、システムは、「ログイン成功」というメッセージを表示して、ユーザーアクセスを許可した（Ｇ５ ３８０）。
・この例では、Ｇ５ ３５３とＧ５ ３６２におけるトークンが同じで、Ｇ５ ３５９とＧ５ ３６５におけるトークンもそうであるが、それは単なる偶然の一致で、このような状況は頻繁に起こり得る。これは、パスコードを推測しようと試みている人物を非常にうまく混乱させ得る。

図１２Ｃは、ＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、ユーザーがそれからパスコードを選択する１６個のトークンの４×４のテーブルを示している。それは、トークン選択プロセスがどのように機能するかを反映する。それは、３つの誤ったピンで失敗したログインがどのように見え得るかも示す。このプロセス例は図１１Ｂの例に従っており、そのため、同じパスコードが使用される。プロセスは、次のように進む：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ５ ３０７）を入力する。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ５ ３１０）をクリックする。システムは、ｉｄ「ａｄｍｉｎ」が既にそのメモリ内にあるかどうかを確認し、それが存在しない場合、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。存在する場合、システムは、４×４のテーブル（Ｇ５ ３２１）を表示し、テーブルをより良く説明するために、行は上から下へ：Ａ、Ｂ、Ｃ、Ｄと示され、列も左から右へ：１、２、３、４と示される。このテーブル内のトークンは、図５で説明する規則に従って生成される。
・図１１Ｂから、ユーザーｉｄ「ａｄｍｉｎ」に関連付けられたパスコードが：

であることが分かっているので、ユーザーは、１番目のピン：「＄」を見つけるために、テーブル内の１６個のトークンを調べることから始める必要がある。
記号＄は、第５の次元に属するので、トークンの右下の位置にだけ出現し、そのため、ユーザーは、＄が存在するかどうか確認するために、各トークンの右下の位置に目を通すだけで良い。我々の例では、それは、トークンＡ２内にあり、ユーザーは、図６で説明する規則に従い、このトークンをクリックする必要がある。
・ユーザーがＡ２をクリックすると、そのトークンがパスコードの１番目の位置（Ｇ５ ３５１）にコピーされる。
・ユーザーパスコード内の２番目のピンは：「＝」であり、この記号は第４の次元に属し、第４の次元の記号はトークンの左下側にだけ出現するので、ユーザーは、１６個のトークンの各々の左下側を見るだけで良く、我々の事例では、それは存在せず、トークン選択規則に従い、ユーザーは、そのピンの位置に対してワイルドカードトークン（任意のトークン）を選択できて、選択する必要があるので、ユーザーは、ランダムなトークンＡ３をクリックする。
・ユーザーがＡ３をクリックすると、そのトークンがパスコードの２番目の位置（Ｇ５ ３５４）にコピーされる。
・パスコード内の３番目のピンは：

であり、それは第１の次元に属するので、ユーザーは、１６個のトークンの各々の左上の位置を見るだけで良く、我々の事例では、それはトークンＣ１内にあり、ユーザーは、Ｃ１をクリックする必要がある。我々の事例では、ユーザーは実際にＣ１をクリックする。
・ユーザーがＣ１をクリックすると、そのトークンがパスコードの３番目の位置（Ｇ５ ３５７）にコピーされる。
・４番目のピンは：

であり、この記号は第１の次元に属し、ユーザーは、１６個のトークンの各々の左上の位置を見るだけで良く、我々の事例では、それはトークンＤ２内にあり、ユーザーは、Ｄ２をクリックする必要がある。我々の事例では、ユーザーはＤ２をクリックせず、代わりに、ユーザーは、Ｃ２をクリックした。これは間違いであり、システムはユーザーアクセスを拒否するであろう。
・ユーザーがＣ２をクリックすると、そのトークンがパスコードの４番目の位置（Ｇ５ ３６０）にコピーされる。
・パスコード内の５番目のピンは：「２」であり、それは第３の次元に属するので、ユーザーは、１６個のトークンの各々の中央を見るだけで良く、我々の事例では、それはトークンＣ３内にあり、図６におけるトークン選択規則に従い、ユーザーはこのトークンを選択する必要があるが、例ではユーザーは代わりにトークンＢ２を選択し、これは間違いで、システムはチェックして通知するであろう。
・ユーザーが間違ったトークンＢ２をクリックすると、それはパスコードの５番目の位置（Ｇ５ ３６３）にコピーされる。
・６番目で最後のピンは：

であり、この記号は第４の次元に属し、第４の次元の記号はトークンの左下側にだけ出現するので、ユーザーは、１６個のトークンの各々の左下側をチェックするだけで良く、我々の事例では、それはトークンＤ１内にあり、ユーザーは、Ｄ１をクリックする必要がある。我々の事例では、ユーザーはＤ１をクリックせず、代わりに、ユーザーはトークンＣ４をクリックし、これは間違いで、システムはそれを通知する。
・ユーザーが間違ったトークンＣ４をクリックすると、それはパスコードの６番目の位置（Ｇ５ ３６６）にコピーされる。
・ユーザーが６つ全部のトークンを入力した後、ユーザーは「Ｌｏｇｉｎ」（Ｇ５ ３７１）ボタンをクリックして、ユーザーがトークン選択プロセスを終了していることをシステムに知らせ、システムは、図７で説明する規則に従って、入力されたトークンが有効であるかどうかを確認する。
・この例では、ユーザーが入力したトークンは無効であり、システムは、「ログインが失敗した」というメッセージを表示して、ユーザーアクセスを拒否した（Ｇ５ ３８１）。

図１２Ｄは、ＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、ユーザーがそれからパスコードを選択する、１６個のトークンの４×４のテーブルを示している。それは、トークン選択プロセスがどのように機能するかを反映する。それは、見当たらないピンがある失敗したログインがどのように見え得るかも示す。このプロセス例は図１１Ｂの例に従っており、そのため、同じパスコードが使用される。プロセスは、次のように進む：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ５ ３０８）を入力する。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ５ ３１１）をクリックする。システムは、ｉｄ「ａｄｍｉｎ」が既にそのメモリ内にあるかどうかを確認し、それが存在しない場合、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。存在する場合、システムは、４×４のテーブル（Ｇ５ ３２２）を表示し、テーブルをより良く説明するために、行は上から下へ：Ａ、Ｂ、Ｃ、Ｄと示され、列も左から右へ：１、２、３、４と示される。このテーブル内のトークンは、図５で説明する規則に従って生成される。
・図１１Ｂから、ユーザーｉｄ「ａｄｍｉｎ」に関連付けられたパスコードは：

であることが分かっているので、ユーザーは、１番目のピン：「＄」を見つけるために、テーブル内の１６個のトークンを調べることから始める必要がある。
記号＄は、第５の次元に属するので、トークンの右下の位置にだけ出現し、ユーザーは、＄が存在するかどうか確認するために、各トークンの右下の位置に目を通すだけで良い。我々の例では、それは、それは存在せず、ユーザーは、そのピンの位置にワイルドカードトークン（任意のトークン）を選択できて、選択する必要があるので、ユーザーは、ランダムなトークンＤ３をクリックする。
・ユーザーがＤ３をクリックすると、そのトークンがパスコードの１番目の位置（Ｇ５ ３５２）にコピーされる。
・ユーザーパスコード内の２番目のピンは：「＝」であり、この記号は第４の次元に属し、第４の次元の記号はトークンの左下側にだけ出現するので、ユーザーは、１６個のトークンの各々の左下側を見るだけで良く、我々の事例では、それはトークンＣ１内にあり、ユーザーは、このトークンをクリックする必要がある。
・ユーザーがＣ１をクリックすると、そのトークンがパスコードの２番目の位置（Ｇ５ ３５５）にコピーされる。
・パスコード内の３番目のピンは：

であり、それは第１の次元に属するので、ユーザーは、１６個のトークンの各々の左上の位置を見るだけで良く、我々の事例では、それはトークンＡ１内にあり、そのため、ユーザーはＡ１をクリックする必要がある。我々の事例では、ユーザーは実際にＡ１をクリックする。
・ユーザーがＡ１をクリックすると、そのトークンがパスコードの３番目の位置（Ｇ５ ３５８）にコピーされる。
・４番目のピンは：

であり、この記号は第１の次元に属し、ユーザーは、１６個のトークンの各々の左上の位置を見るだけで良く、我々の事例では、それはトークンＤ３内にあり、そのため、ユーザーはＤ３をクリックする必要がある。我々の事例では、ユーザーは実際にＤ３をクリックした。
・ユーザーがＤ３をクリックすると、そのトークンがパスコードの４番目の位置（Ｇ５ ３６１）にコピーされる。
・パスコード内の５番目のピンは：「２」であり、それは第３の次元に属するので、ユーザーは、１６個のトークンの各々の中央を見るだけで良く、我々の事例では、それはトークンＣ４内にあり、図６におけるトークン選択規則に従い、ユーザーはこのトークンを選択する必要があるが、例では、ユーザーはトークンＣ４を選択した。
・ユーザーがトークンＣ４をクリックすると、それはパスコードの５番目の位置（Ｇ５ ３６４）にコピーされる。
・６番目で最後のピンは：

であり、この記号は第４の次元に属し、第４の次元の記号はトークンの左下側にだけ出現するので、ユーザーは、１６個のトークンの各々の左下側をチェックするだけで良く、我々の事例では、それはトークンＣ２内にあり、そのため、ユーザーはＣ２をクリックする必要がある。しかし、我々の事例では、ユーザーはＣ２をクリックせず、代わりに、ユーザーは最後の位置を空のままにして、５つのピンだけを入力した。これは間違いである。
・ユーザーが上の５つのトークンを入力した後、ユーザーは「Ｌｏｇｉｎ」（Ｇ５ ３７２）ボタンをクリックして、ユーザーがトークン選択プロセスを終了していることをシステムに知らせ、システムは、図７で説明する規則に従って、入力されたトークンが有効であるかどうかを確認する。
・この例では、元のパスコードには６つのピンがあるが、ユーザーは、我々の例では、５つのトークンしか入力していないので、ユーザーが入力したトークンは無効であり、そのため、ユーザーのアクセス要求は拒否されて、システムは、「ログインが失敗した」というメッセージを表示した（Ｇ５ ３８２）。

図１３Ａは、テキストフォーマットでのＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、プログラム開始時の空の画面を反映している。この画像は、以下の図１３Ｂ、図１３Ｃおよび図１３Ｄに対する比較の基礎として使用される。この画面は、場面の背後で何が起こるかの説明として示すだけである。それは、リアルタイムのユーザーログイン中には表示されない。

図１３Ｂは、テキストフォーマットでのＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、図１２Ｂのユーザーログインプロセスが行われているときに場面の背後で何が起こるかを示し、図４のプロセスフローがサンプル実施形態でどのように見えるかを示す。これはデモに過ぎず、リアルタイムのユーザーログイン中には表示されない。図７に示すトークン検証規則を視覚的に説明するために使用される。

３つの列：「クライアント側」（左側）、「ネットワーク接続」（中央）、および「サーバー側」（右側）がある。ユーザーがユーザーｉｄを入力するとプロセスがクライアント側から開始し、次いで、情報がネットワーク接続を通してサーバー側に渡る。サーバーは１６個のトークンを生成し、それらをネットワークに渡し、次いで、トークンがクライアント側に渡される。

ユーザーは、図６に示すトークン選択規則に従ってトークンを選択し、次いで、選択されたトークンがネットワークに渡され、その後、検証するためにサーバー側に渡される。アクセスの許可または拒否の結果がネットワークを通してクライアント側に渡される。プロセスフローが、図１３Ｂにおいて矢印によって示されている。プロセスは次のように進む：
・ユーザーがユーザーｉｄ「ａｄｍｉｎ」（Ｇ５ ４０６）を入力する。
・ユーザーは「Ｅｎｔｅｒ」（Ｇ５ ４０９）をクリックする。
・ユーザーｉｄ「ａｄｍｉｎ」（Ｇ５ ４０６）がクライアント側（Ｇ５ ４１１）に表示されて、ネットワーク接続（Ｇ５ ４１３）に渡され（Ｇ５ ４２１）、次いでそれはさらにサーバー側（Ｇ５ ４１５）に渡される（Ｇ５ ４２２）。
・サーバー側で、システムは、ユーザーｉｄ「ａｄｍｉｎ」が存在するかどうか、そのメモリを確認し、それが存在しない場合、システムは、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。図１１Ｂからの同じ例が使用され、そのため、メモリ内のパスコードは：

であり、システムはそれをメモリ内で見つける（Ｇ５ ４１７）。
・システムは、図５に従って１６個のトークン（Ｇ５ ４２３）を生成する。
・１６個のトークンがネットワークに渡される（Ｇ５ ４２４）。
・ネットワークはそのトークンをクライアント側に渡す（Ｇ５ ４２５）。
・１６個のトークンは、図１２Ｂに示すように、４×４のテーブル（Ｇ５ ３２０）で、ユーザーログイン画面上に表示される。
・ユーザーは６つのトークン：Ｇ５ ３５０、Ｇ５ ３５３、Ｇ５ ３５６、Ｇ５ ３５９、Ｇ５ ３６２およびＧ５ ３６５を選択する（Ｇ５ ４２６）。
・ユーザーが図１２Ｂにおける「Ｌｏｇｉｎ」（Ｇ５ ３７０）をクリックすると、ユーザーが選択した６つのトークンがネットワークに渡される（Ｇ５ ４２７）。
・ユーザーが選択した６つのトークンは、次いで、サーバー側に渡される（Ｇ５ ４２８）。
・サーバー側で、システムは、６つのトークン全部を１つずつチェックし：Ｋ１１、Ｋ１２、Ｋ１３、Ｋ１４、Ｋ１５およびＫ１６、我々の例では、それらは全て正しい。
・成功したログインという上の結果（Ｇ５ ４２９）が、ネットワークに渡される（Ｇ５ ４３０）。
・ネットワークはその結果をクライアント側に渡して（Ｇ５ ４３１）、図１２ＢのＧ５ ３８０に示すメッセージを表示する（Ｇ５ ４３２）。

図１３Ｃは、テキストフォーマットでのＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、図１２Ｃのユーザーログインプロセスが行われているときに場面の背後で何が起こるかを示し、図４のプロセスフローがサンプル実施形態でどのように見えるかを示す。これはデモに過ぎず、リアルタイムのユーザーログイン中には表示されない。それは、図７に示すトークン検証規則を視覚的に説明するために使用される。

３つの列：「クライアント側」（左側）、「ネットワーク接続」（中央）、および「サーバー側」（右側）がある。ユーザーがユーザーｉｄを入力するとプロセスがクライアント側から開始し、次いで、情報がネットワーク接続を通してサーバー側に渡る。サーバーは１６個のトークンを生成し、それらをネットワークに渡し、次いで、トークンがクライアント側に渡される。

ユーザーは、図６に示すトークン選択規則に従ってトークンを選択する。選択されたトークンはネットワークに渡され、次いで、検証するためにサーバー側に渡され、アクセスの許可または拒否の結果がネットワークを通してクライアント側に渡される。プロセスフローが、図１３Ｃにおいて矢印によって示されている。以下でさらに詳細に説明する：
・ユーザーがユーザーｉｄ：「ａｄｍｉｎ」（Ｇ５ ５０６）を入力する。
・ユーザーは「Ｅｎｔｅｒ」ボタン（Ｇ５ ５０９）をクリックする。
・ユーザーｉｄ「ａｄｍｉｎ」（Ｇ５ ５０６）がクライアント側（Ｇ５ ５１１）に表示されて、ネットワーク接続（Ｇ５ ５１３）に渡され（Ｇ５ ５２１）、次いでそれは再度サーバー側（Ｇ５ ５１５）に渡される（Ｇ５ ５２２）。
・サーバー側で、システムは、ユーザーｉｄ「ａｄｍｉｎ」が存在するかどうか、そのメモリを確認し、それが存在しない場合、システムは、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。図１１Ｂからの同じ例が使用され、メモリ内のパスコードは：

であり、システムはそれをメモリ内で見つける（Ｇ５ ５１７）。
・システムは、図５に示すトークン生成規則に従って１６個のトークン（Ｇ５ ５２３）を生成する。
・１６個のトークンがネットワークに渡される（Ｇ５ ５２４）。
・ネットワークはそのトークンをクライアント側に渡す（Ｇ５ ５２５）。
・１６個のトークンは、図１２Ｃに示すように、４×４のテーブル（図１２ＣにおけるＧ５ ３２１）で、ユーザーログイン画面上に表示される。
・ユーザーは６つのトークン：Ｇ５ ３５１、Ｇ５ ３５４、Ｇ５ ３５７、Ｇ５ ３６０、Ｇ５ ３６３およびＧ５ ３６６を選択する（Ｇ５ ５２６）。
・ユーザーが「Ｌｏｇｉｎ」（図１２ＣにおけるＧ５ ３７１）をクリックすると、ユーザーが選択した６つのトークンがネットワークに渡される（Ｇ５ ５２７）。
・ユーザーが選択した６つのトークンは、次いで、サーバー側に渡される（Ｇ５ ５２８）。
・サーバー側で、システムは、６つのトークン全部を１つずつチェックする：Ｋ２１、Ｋ２２、Ｋ２３、Ｋ２４、Ｋ２５およびＫ２６。この例では、最後の３つの選択されたトークが正しくない（ユーザーは、４番目、５番目および６番目のトークンに対して、それぞれ、Ｄ２トークン、Ｃ３トークンおよびＤ１トークンを選択する必要があったが、代わりに、ユーザーは、Ｃ２トークン、Ｂ２トークンおよびＣ４トークンを選択し、それらは誤っている。従って、結果は失敗したログインとなる）。
・失敗したログインという上の結果（Ｇ５ ５２９）が、ネットワークに渡される（Ｇ５ ５３０）。
・ネットワークはその結果をクライアント側に渡して（Ｇ５ ５３１）、図１２ＣのＧ５ ３８１に示すメッセージを表示する（Ｇ５ ５３２）。

図１３Ｄは、テキストフォーマットでのＧＡＴＥ＿５実施形態におけるユーザーログインプロセスのサンプルスクリーンショットである。それは、図１２Ｄのユーザーログインプロセスが行われているときに場面の背後で何が起こるかを示し、図４のプロセスフローがサンプル実施形態でどのように見えるかを示す。これはデモに過ぎず、リアルタイムのユーザーログイン中には表示されない。それは、図７に示すトークン検証規則を視覚的に説明するために使用される。

３つの列：「クライアント側」（左側）、「ネットワーク接続」（中央）、および「サーバー側」（右側）がある。ユーザーがユーザーｉｄを入力するとプロセスがクライアント側から開始し、次いで、情報がネットワーク接続を通してサーバー側に渡る。サーバーは１６個のトークンを生成し、それらをネットワークに渡し、次いで、トークンがクライアント側に渡される。

ユーザーは、図６に示すトークン選択規則に従ってトークンを選択し、次いで、選択されたトークンがネットワークに渡され、その後、検証するためにサーバー側に渡される。アクセスの許可または拒否の結果がネットワークを通してクライアント側に渡される。プロセスフローが、図１３Ｄにおいて矢印によって示されている。プロセスは次のように進む：
・ユーザーがユーザーｉｄ「ａｄｍｉｎ」（Ｇ５ ６０６）を入力する。
・ユーザーは「Ｅｎｔｅｒ」（Ｇ５ ６０９）をクリックする。
・ユーザーｉｄ「ａｄｍｉｎ」（Ｇ５ ６０６）がクライアント側（Ｇ５ ６１１）に表示されて、ネットワーク接続（Ｇ５ ６１３）に渡され（Ｇ５ ６２１）、次いでそれはさらにサーバー側（Ｇ５ ６１５）に渡される（Ｇ５ ６２２）。
・サーバー側で、システムは、ユーザーｉｄ「ａｄｍｉｎ」が存在するかどうか、そのメモリを確認し、それが存在しない場合、システムは、「ユーザーＩｄが存在しません、有効なユーザーＩｄを入力してください」というメッセージ（図示せず）を表示する。図１１Ｂからの同じ例が使用され、従って、メモリ内のパスコードは：

であり、システムはそれをメモリ内で見つける（Ｇ５ ６１７）。
・システムは、図５のトークン生成規則に従って１６個のトークン（Ｇ５ ６２３）を生成する。
・１６個のトークンがネットワークに渡される（Ｇ５ ６２４）。
・ネットワークはそのトークンをクライアント側に渡す（Ｇ５ ６２５）。
・１６個のトークンは、図１２Ｄに示すように、４×４のテーブル（Ｇ５ ３２２）で、ユーザーログイン画面上に表示される。
・ユーザーは５つのトークン：Ｇ５ ３５２、Ｇ５ ３５５、Ｇ５ ３５８、Ｇ５ ３６１およびＧ５ ３６４を選択する（Ｇ５ ６２６）。Ｇ５ ３６７に留意すると、「

ｉｎｐｕｔ ｍｉｓｓｉｎｇ（入力が不足している）」と表示されており、システムは

記号を最後のピンとして予期し、従って、６番目のトークンがあるはずだが、まだ、６番目のトークンからの入力が不足しており、これはエラーで、システムはユーザーアクセスを拒否することを意味する。
・ユーザーが図１２Ｄにおける「Ｌｏｇｉｎ」（Ｇ５ ３７２）をクリックした後、ユーザーが選択した５つのトークンがネットワークに渡される（Ｇ５ ６２７）。
・ユーザーが選択した５つのトークンは、次いで、サーバー側に渡される（Ｇ５ ６２８）。
・サーバー側で、システムは、５つのトークン全部を１つずつチェックし：Ｋ３１、Ｋ３２、Ｋ３３、Ｋ３４およびＫ３５、我々の例では、５つ全部のトークンは正しいが、６番目のトークンが不足しており（ユーザーはＣ２をクリックせず、代わりに、最後の位置を空のままにして、５つのピンだけを入力した）、従って、Ｋ３６は、エラーを表す［ｘ］と印を付けられた。これは誤りである。従って、結果は失敗したログインとなる。
・失敗したログインという上の結果（Ｇ５ ６２９）が、ネットワークに渡される（Ｇ５ ６３０）。
・ネットワークはその結果をクライアント側に渡して（Ｇ５ ６３１）、図１２ＤのＧ５ ３８２に示すメッセージを表示する（Ｇ５ ６３２）。

本方法は、パスコードを推測するのをさらに一層困難にするために次の特徴を使用するように拡張できる：ある数のピンを「隠し」として割り当て、それにより、それらの隠しピンが選択テーブル内に現れた場合に、それらは選択できない。代わりに、ユーザーは、これらのピンを有していない任意の他のトークンを選択し、それらのピンを有するトークンを避ける必要がある。

そのため、例えば、ユーザーがパスコード「１２３（＄＃）４５６」を有する場合、パスコードの長さは８で、真ん中の２つのピンは、「（」と「）」の間に示された隠しピンである。ピン１、２、３、４、５、６に関しては、前述の規則に従う。「＄」および「＃」に関しては、「隠しピン規則」に従い、それは：それらのいずれも１６個のトークンのどれにも現れない場合、ユーザーは、それらの位置にワイルドカードトークンを選択できて、選択する必要があるが、それらのいずれかが選択テーブル内の１６個のトークンの１つに実際に現れる場合、ユーザーは、そのピンを避けて、任意の他の１５個のトークンから１つを選択する必要がある。

ピンを隠しピンにするために、パスコード作成（登録）画面内の各ピンの下にチェックボックスを表示することができ、それにより、ユーザーがピンの下のボックスをチェックすると、そのピンが隠しピンになり、トークン検証プロセス中、ユーザーログインを検証するために前述の隠しピン規則を使用する。

本発明は、１６個のトークンをもつ選択テーブル［図５で説明するトークン生成規則に従う送信者パスコードとともに生成された］およびいくつかのトークンをもつ鍵をメッセージと一緒に添付するために任意の通信プロセスも使用できる。その鍵がそのテーブルに対して有効である場合、そのメッセージは真のメッセージである。その鍵が選択テーブルに対して無効である場合、添付されたメッセージは偽のメッセージである。真のメッセージを保持して偽のメッセージをドロップすることにより、最終的な［元の］正しいメッセージを得る。受信者は、同じパスコードを使用してメッセージを復号し、そのためプロセスは以下の例のように進み得る：
・Ｍｅｓｓａｇｅ＿１：Ｉ ｗｉｌｌ ｇｏ ｈｏｍｅ ａｔ ７ｐｍ［＋１６個のトークンをもつトークンテーブル＋無効な鍵］――＞メッセージを捨てる
Ｍｅｓｓａｇｅ＿２：Ｉ ｗｉｌｌ ｇｏ ｈｏｍｅ ａｔ ３ｐｍ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞Ｉ ｗｉｌｌ ｇｏ ｈｏｍｅ ａｔ ３ｐｍ
Ｍｅｓｓａｇｅ＿３：Ｗｅ ｗｉｌｌ ａｂａｎｄｏｎ ａｔｔａｃｋ ｏｎ ｔｈｅ ３ｒｄ［＋１６個のトークンをもつトークンテーブル＋無効な鍵］――＞メッセージを捨てる
Ｍｅｓｓａｇｅ＿４：Ｗｅ ｗｉｌｌ ａｔｔａｃｋ ａｔ ｎｏｏｎ ｏｎ ｔｈｅ ３ｒｄ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞Ｗｅ ｗｉｌｌ ａｔｔａｃｋ ａｔ ｎｏｏｎ ｏｎ ｔｈｅ ３ｒｄ
従って、正しい最終的なメッセージは：Ｉ ｗｉｌｌ ｇｏ ｈｏｍｅ ａｔ ３ｐｍ．Ｗｅ ｗｉｌｌ ａｔｔａｃｋ ａｔ ｎｏｏｎ ｏｎ ｔｈｅ ３ｒｄである。
・Ｍｅｓｓａｇｅ＿１：Ｉ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞Ｉ
Ｍｅｓｓａｇｅ＿２：ｗｉｌｌ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞ｗｉｌｌ
Ｍｅｓｓａｇｅ＿３：ｎｏｔ ［＋１６個のトークンをもつトークンテーブル＋無効な鍵］――＞メッセージを捨てる
Ｍｅｓｓａｇｅ＿４：ｇｏ ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞ｇｏ
従って、正しい最終的なメッセージは：Ｉ ｗｉｌｌ ｇｏである。
・Ｍｅｓｓａｇｅ＿１：ｕ［＋１６個のトークンをもつトークンテーブル＋無効な鍵］――＞メッセージを捨てる
Ｍｅｓｓａｇｅ＿２：ｎ［＋１６個のトークンをもつトークンテーブル＋無効な鍵］――＞メッセージを捨てる
Ｍｅｓｓａｇｅ＿３：ｔ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞ｔ
Ｍｅｓｓａｇｅ＿４：ｒ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞ｒ
Ｍｅｓｓａｇｅ＿５：ｕ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞ｕ
Ｍｅｓｓａｇｅ＿６：ｅ［＋１６個のトークンをもつトークンテーブル＋有効な鍵］＝＝＞ｅ
従って、正しい最終的なメッセージは：ｔｒｕｅである。

本発明は、フィッシングも打ち破ることができ、フィッシングは、多くの場合、悪意のある理由のために、電子通信において信頼できる実体を装うことにより、ユーザー名、パスワード、およびクレジットカード詳細などの、機密情報を取得しようとする試みである。本発明を用いると、ユーザーとサーバーとの間で渡される全ての情報はトークンの形であって、各トークンは、複数の記号を有するので、明白なユーザーピンは漏れない。

図１４は、ＧＡＴＥ＿４実施形態を使用するメッセージ暗号化プロセスのサンプルスクリーンショットである。それは、プレーンテキストメッセージが送信者パスコードでどのように暗号化されるか、および暗号化されたメッセージがどのように見え得るかを示す。プロセスは次のように進む：
・メッセージ送信者がプレーンテキストメッセージ「ｓｅｃｒｅｔ」をＧ４ ７００で入力する。
・送信者は、パスコード「１２３」をＧ４ ７０２で入力して、「Ｅｎｃｒｙｐｔ（暗号化）」ボタン［Ｇ４ ７０３］をクリックする。
・元のメッセージ「ｓｅｃｒｅｔ」が何らかのランダムな充填文字と混合されて、Ｇ４ ７０４に示すような、次の結果のメッセージ「ｓＬｅＱＷＮｃｒＭｆＹｅＭｔＨＱｒ」に変わる。
・受信者は、受信者側で同じパスコード「１２３」［Ｇ４ ７０６］を使用してメッセージを復号する。

図１５Ａは、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、暗号化された元のメッセージが受信者パスコードでどのように成功裏に復号され得るかの例を示す。プロセスは次のように進む：
・結果のメッセージ内の各文字［Ｇ４ ７０４］には、テーブル内の各トークンが４つの記号を有する、４×４のトークンテーブルが添付され、メッセージ内の各文字には「鍵」も添付され、鍵はいくつかのトークンをその中に有し、鍵中のトークンの数は２〜６の範囲であり得る。
・受信者は同じパスコード「１２３」［Ｇ４ ７０６］を使用してメッセージを復号し、復号されたメッセージがＧ４ ７０４に強調表示された文字として示される。結果の復号されたメッセージは「ｓｅｃｒｅｔ」［Ｇ４ ７０８］である。
・図１５Ａは、各文字に対してそれがどのように見え得るかの例を示す。スクリーンショットでは、メッセージ内の１番目の文字「ｓ」［Ｇ４ ７１０］は、ユーザーがそれ［Ｇ４ ７１０］をクリックした後、例として表示され、Ｇ４ ７１２は、現在表示している文字が「ｓ」であることを示す。この文字に添付された４×４のトークンテーブルがテーブルＧ４ ７１４に示される。
・「ｓ」に添付された鍵トークンも、Ｇ４ ７２０、Ｇ４ ７２２およびＧ４ ７２４として示される。
・メッセージ内の充填文字：Ｌ、Ｑ、Ｗ、Ｎ、Ｍ、ｆ、Ｙ、Ｍ、Ｈ、Ｑおよびｒは、トークンテーブルおよび無効な鍵が意図的に添付されており、そのため、それらは受信者側で無効にされる。
・示した例では、ユーザーはＧ４ ７０４内の各文字をクリックして、その内容および鍵トークンを表示することができ、次いで、「Ｃｈｅｃｋ（チェックする）」ボタン［Ｇ４ ７２６］をクリックしてその文字が有効であるかどうかを確認する。スクリーンショットでは、文字「ｓ」は有効であり、チェックは成功した［Ｇ４ ７３０］ことが示される。

図１５Ｂは、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、図１５Ａに示すプロセスが行われているときに場面の背後で何が起こるかを示し、メッセージが受信者側でどのように検証されるかを示す。プロセスは次のように進む：
・メッセージ文字「ｓ」［Ｇ４ ７５０］が送信者パスコード「１２３」［Ｇ４ ７５２］で暗号化されて、１６個のトークン［Ｇ４ ７５４］、およびいくつかのトークン［Ｇ４ ７２０、Ｇ４ ７２２およびＧ４ ７２４］をもつ鍵が添付される。この情報はネットワーク［Ｇ４ ７５６］に送信され、次いで受信者［Ｇ４ ７５８］に送信される。
・受信者側で、メッセージを復号するために、同じパスコードが使用される「１２３」［Ｇ４ ７６０］。鍵トークンは、各鍵トークンをチェックするために検証プロセスＧ４ ７６４、Ｇ４ ７６６を経る［Ｇ４ ７６２］。Ｃ５１、Ｃ５２およびＣ５３から、それらが全て有効であることがわかり、そのため、図１５Ａ［Ｇ４ ７３０］に示すように、メッセージが有効である［Ｇ４ ７７０］という最終的結論に達する［Ｇ４ ７６８］。

図１６Ａは、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、暗号化された充填文字メッセージが受信者パスコードによって復号されて、無効な情報としてどのように認識されるかの例を示す。プロセスは次のように進む：
・図１６Ａは、元のメッセージの一部ではない各充填文字に関してそれがどのように見え得るかの例を示す。それは、メッセージ［Ｇ４ ７０４］内の２番目の文字「Ｌ」［Ｇ４ ７１１］の内容を、ユーザーがそれをクリックした後に示す。Ｇ４ ７１３は、文字が「Ｌ」であることを示す。この文字に添付された１６個のトークンの４×４のテーブルがＧ４ ７１５に示されている。「Ｌ」に添付された４つの鍵トークンが、Ｇ４ ７２１、Ｇ４ ７２３、Ｇ４ ７２５およびＧ４ ７２７として示されている。
・文字「Ｌ」は充填文字で、元のメッセージの一部ではないので、送信者は意図的に４×４のトークンテーブルおよび有効でない鍵を添付する。送信者パスコード［Ｇ４ ７０２］および受信者パスコード［Ｇ４ ７０６］が同じで、３つのピン「１」、「２」および「３」を有し、従って有効な鍵は、３つのトークンよりも多くも、少なくもないはずであることが明らかにわかる。この例では、それは４つの鍵トークンを有し、そのためそれは無効であり、文字「Ｌ」は無視されるべきであって、最終的な復号されたメッセージの一部ではないであろう。
・スクリーンショットでは、ユーザーが「Ｃｈｅｃｋ（チェックする）」ボタンＧ４ ７２６をクリックすると、検証プロセスが失敗している［Ｇ４ ７３１］ことが示される。

図１６Ｂは、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、図１６Ａに示すプロセスが行われているときに場面の背後で何が起こるか、および充填文字メッセージが受信者側でどのように無効にされるかを示す。プロセスは次のように進む：
・メッセージ文字「Ｌ」［Ｇ４ ７５１］が、送信者パスコード「１２３」［Ｇ４ ７５２］で暗号化されて、１６個のトークンの４×４のテーブル［Ｇ４ ７５２］、およびいくつかのトークン［Ｇ４ ７２１、Ｇ４ ７２３、Ｇ４ ７２５およびＧ４ ７２７］をもつ鍵を添付される。前述の情報はネットワーク［Ｇ４ ７５７］に送信され、次いで受信者［Ｇ４ ７５９］に送信される。
・受信者側で、メッセージを復号するために同じパスコードが使用される「１２３」［Ｇ４ ７６０］。鍵トークンは、Ｃ６１、Ｃ６２、Ｃ６３およびＣ６４から、各鍵トークンをチェックするために、検証プロセスＧ４ ７６５、Ｇ４ ７６７を経る［Ｇ４ ７６３］。最後の２つの鍵トークンは、無効であることが分かる。
・３番目のパスコード「３」が３番目のトークン［Ｇ４ ７９０］内に現れていて、それが選択されるべきである。しかし、８番目のトークン［Ｇ４ ７９２］が選択されて、３番目の鍵トークンＧ４ ７２５内に現れている。これは正しくない。
・送信者パスコードは受信者パスコードと等しくて、３つのピンを有するが、添付された鍵は４つのトークンを有する。最後のトークン［Ｇ４ ７２７］も無効である。
・図１６Ａ［Ｇ４ ７３１］に示すように、メッセージは無効である［Ｇ４ ７７１］という最終的結論に達する［Ｇ４ ７６９］。

図１７は、ＧＡＴＥ＿４実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、暗号化された元のメッセージが、送信者パスコードとは異なる受信者パスコードによってどのように成功裏に復号されない可能性があるかの例を示す。プロセスは次のように進む：
・ユーザーがプレーンテキストメッセージ「ｓｅｃｒｅｔ」をＧ４ ７００に入力し、次いで、パスコード「１２３」［Ｇ４ ７０２］を入力して、「Ｅｎｃｒｙｐｔ（暗号化）」ボタン［Ｇ４ ７０３］をクリックする。
・メッセージが暗号化され、送信されて、受信され、「ｓＬｅＱＷＮｃｒＭｆＹｅＭｔＨＱｒ」［Ｇ４ ７０５］としてＧ４ ７０５に現れる。
・受信者は、パスコード「５６７」［Ｇ４ ７０７］を使用して、送信者から受信した、パスコード「１２３」［Ｇ４ ７０２］で暗号化された、メッセージを復号する。
・復号されたメッセージがＧ４ ７０５で強調表示される：「ｅｃｒＱ」。
・結果のメッセージは「ｅｃｒＱ」として示される［Ｇ４ ７０９］。
・受信者はメッセージを復号するために異なるパスコードを使用したので、結果のメッセージは、送信者からの元のメッセージ：「ｓｅｃｒｅｔ」と異なっている。

図１８は、ＧＡＴＥ＿５実施形態を使用するメッセージ暗号化プロセスのサンプルスクリーンショットである。それは、プレーンテキストメッセージが送信者パスコードでどのように暗号化されるか、および暗号化されたメッセージがどのように見え得るかを示す。プロセスは次のように進む：
・メッセージ送信者がプレーンテキストメッセージ「ＦＹＥＯ」をＧ５ ７００で入力する。
・送信者は、パスコード「１２３」をＧ５ ７０２で入力して、「Ｅｎｃｒｙｐｔ（暗号化）」ボタン［Ｇ５ ７０３］をクリックする。
・元のメッセージ「ＦＹＥＯ」が何らかのランダムな充填文字と混合されて、次の結果のメッセージ「ＦＩＰＲｏｊｃＹｎＥｂＡＯ」［Ｇ５ ７０４］に変わる。
・受信者は、受信者側で同じパスコード「１２３」［Ｇ５ ７０６］を使用してメッセージを復号する。

図１９Ａは、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、暗号化された元のメッセージが受信者パスコードでどのように成功裏に復号され得るかの例を示す。プロセスは次のように進む：
・受信したメッセージ内の各文字［Ｇ５ ７０４］には、テーブル内の各トークンが５つの記号を有する、４×４のトークンテーブルが添付され、メッセージ内の各文字には「鍵」も添付され、鍵はいくつかのトークンをその中に有し、鍵中のトークンの数は２〜６の範囲であり得る。
・受信者は同じパスコード「１２３」［Ｇ５ ７０６］を使用してメッセージを復号し、復号されたメッセージがＧ５ ７０４に強調表示された文字として示される。結果の復号されたメッセージは「ＦＹＥＯ」［Ｇ５ ７０８］である。
・図１９Ａは、各文字に対してそれがどのように見え得るかの例を示す。スクリーンショットでは、メッセージ内の１番目の文字「Ｆ」［Ｇ５ ７１０］が、例として表示される。Ｇ５ ７１２は、現在表示している文字が「Ｆ」であることを示し、この文字に添付された４×４のトークンテーブルがテーブルＧ５ ７１４に示される。
・「Ｆ」に添付された鍵トークンも、Ｇ５ ７２０、Ｇ５ ７２２およびＧ５ ７２４として示される。
・メッセージ内の充填文字：Ｉ、Ｐ、Ｒ、ｏ、ｊ、ｃ、ｎ、ｂおよびＡは、トークンテーブルおよび無効な鍵が意図的に添付されており、そのため、それらは受信者側で無効にされる。
・この例では、ユーザーはＧ５ ７０４内の各文字をクリックして、その内容および鍵トークンを表示することができ、次いで「Ｃｈｅｃｋ（チェックする）」ボタン［Ｇ５ ７２６］をクリックしてその文字が有効であるかどうかを確認する。スクリーンショットでは、文字「Ｆ」は有効であり、チェックは成功した［Ｇ５ ７３０］ことが示される。

図１９Ｂは、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、図１９Ａに示すプロセスが行われているときに場面の背後で何が起こるかを示し、メッセージが受信者側でどのように検証されるかを示す。プロセスは次のように進む：
・メッセージ文字「Ｆ」［Ｇ５ ７５０］が送信者パスコード「１２３」［Ｇ５ ７５２］で暗号化されて、１６個のトークンの４×４のテーブル［Ｇ５ ７５４］、およびいくつかのトークン［Ｇ５ ７２０、Ｇ５ ７２２およびＧ５ ７２４］をもつ鍵が添付される。この情報はネットワーク［Ｇ５ ７５６］に送信され、次いで受信者［Ｇ５ ７５８］に送信される。
・受信者側で、メッセージを復号するために、同じパスコード「１２３」［Ｇ４ ７６０］が使用される。鍵トークンは、各鍵トークンをチェックするために検証プロセスＧ５ ７６４、Ｇ５ ７６６を経る［Ｇ５ ７６２］。Ｋ５１、Ｋ５２およびＫ５３から、それらが全て有効であることがわかり、そのため、図１９Ａ［Ｇ５ ７３０］に示すように、メッセージは有効である［Ｇ５ ７７０］という最終的結論に達する［Ｇ５ ７６８］。

図２０Ａは、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、暗号化された充填文字メッセージが受信者パスコードによって復号されて、無効な情報としてどのように認識されるかの例を示す。プロセスは次のように進む：
・図２０Ａは、元のメッセージの一部ではない各充填文字に関してそれがどのように見え得るかの例を示す。それは、メッセージ［Ｇ５ ７０４］内の３番目の文字「Ｐ」［Ｇ５ ７１１］の内容を示す。Ｇ５ ７１３は、文字が「Ｐ」であることを示し、この文字に添付された１６個のトークンの４×４のテーブルがＧ５ ７１５に示されている。「Ｐ」に添付された３つの鍵トークンが、Ｇ５ ７２１、Ｇ５ ７２３およびＧ５ ７２５として示されている。
・送信者パスコード［Ｇ５ ７０２］および受信者パスコード［Ｇ５ ７０６］が同じで、３つのピン「１」、「２」および「３」を有することが明らかに分かるので、文字「Ｐ」は充填文字で、元のメッセージの一部ではないため、送信者は、４×４のトークンテーブルおよび認証されない鍵をそれに意図的に添付する。パスコード内の１番目のピン「１」が４×４のテーブル内の最後のトークン［Ｇ５ ７１６］内に現れ、そのトークンが１番目の鍵トークンとして選択されるべきである。しかし、テーブル内の２番目のトークン［Ｇ５ ７１８］が選択されて、１番目の鍵トークン位置Ｇ５ ７２１に表示される。これは誤っており、このメッセージは無効にされるであろう。
・スクリーンショットでは、ユーザーが「Ｃｈｅｃｋ（チェックする）」ボタンＧ５ ７２６をクリックすると、この文字「Ｐ」に対して検証プロセスが失敗している［Ｇ５ ７３１］ことが示される。

図２０Ｂは、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、図２０Ａに示すプロセスが行われているときに場面の背後で何が起こるか、および充填文字メッセージが受信者側でどのように無効にされるかを示す。プロセスは次のように進む：
・メッセージ文字「Ｐ」［Ｇ５ ７５１］が、送信者パスコード「１２３」［Ｇ５ ７５２］で暗号化されて、１６個のトークンの４×４のテーブル［Ｇ５ ７５５］、およびいくつかのトークン［Ｇ５ ７２１、Ｇ５ ７２３およびＧ５ ７２５］をもつ鍵を添付される。この情報はネットワーク［Ｇ５ ７５７］に送信され、次いで受信者［Ｇ５ ７５９］に送信される。
・受信者側で、メッセージを復号するために同じパスコード「１２３」［Ｇ５ ７６０］が使用される。鍵トークンは、各鍵トークンをチェックするために、検証プロセスＧ５ ７６５、Ｇ５ ７６７を経る［Ｇ５ ７６３］。Ｋ６１、Ｋ６２およびＫ６３から、１番目のトークンは、無効であることが分かる。
・１番目のパスコード「１」が最後のトークン［Ｇ５ ７９０］内に現れていて、それが選択されるべきである。しかし、２番目のトークン［Ｇ５ ７９２］が選択されて、１番目の鍵トークン位置［Ｇ５ ７２１］内に現れている。これは従って無効である。
・図２０Ａ［Ｇ５ ７３１］に示すように、メッセージは無効である［Ｇ５ ７７１］という最終的結論に達する［Ｇ５ ７６９］。

図２１は、ＧＡＴＥ＿５実施形態を使用するメッセージ復号プロセスのサンプルスクリーンショットである。それは、暗号化された元のメッセージが、送信者パスコードとは異なる受信者パスコードによってどのように成功裏に復号されない可能性があるかの例を示す。プロセスは次のように進む：
・ユーザーがプレーンテキストメッセージ「ＦＹＥＯ」をＧ５ ７００に入力し、次いで、パスコード「１２３」［Ｇ５ ７０２］を入力して、「Ｅｎｃｒｙｐｔ（暗号化）」ボタン［Ｇ５ ７０３］をクリックする。
・メッセージが暗号化され、送信されて、受信され、「ＦＩＰＲｏｊｃＹｎＥｂＡＯ」［Ｇ５ ７０５］としてＧ５ ７０５に現れる。
・受信者は、パスコード「６８０」［Ｇ５ ７０７］を使用して、送信者から受信した、パスコード「１２３」［Ｇ５ ７０２］で暗号化される、メッセージを復号する。
・復号されたメッセージがＧ５ ７０５で強調表示される：「ｎＥ」。
・結果のメッセージは「ｎＥ」として示される［Ｇ５ ７０９］。
・受信者はメッセージを復号するために異なるパスコードを使用したので、結果のメッセージは、送信者からの元のメッセージ：「ＦＹＥＯ」［Ｇ５ ７００］と異なっている。

以下のステップは、好ましくは、パスコード内の各ピンに対して、各有効なメッセージに対する１６個のトークンをもつ４×４のテーブルに対して有効な鍵トークンを生成するために使用される：
・１６個全てのトークンを調べる：（ａ）ピンがトークン内で見つかる場合、そのトークンを選ぶ；および（ｂ）ピンがどのトークン内にもない場合、テーブル内の１６個のトークンからランダムなトークンを選ぶ。

以下のステップは、好ましくは、各無効なメッセージに対する１６個のトークンをもつ４×４のテーブルに対して無効な鍵トークンを生成するために使用される：
＜１＞ブーリアン型「Ｄｏｎｅ＿Ｆｉｘｉｎｇ」を偽に設定する
＜２＞１６個のトークン全てを調べて、パスコード内の各ピンに対して、以下のステップ＜３＞および＜４＞を実行する
＜３＞＜Ａ＞ピンがトークン内で見つかる場合：
（１）Ｄｏｎｅ＿Ｆｉｘｉｎｇが偽に等しい場合、誤ったトークンを意図的に選ぶために、これ以外の任意の他のトークンを選んで、Ｄｏｎｅ＿Ｆｉｘｉｎｇを真に設定する。
（２）Ｄｏｎｅ＿Ｆｉｘｉｎｇが真に等しい場合、そのトークンを選ぶ。
＜Ｂ＞ピンがどのトークン内でも見つからない場合、１６からランダムなトークンを選ぶ。
＜４＞上で生成された鍵トークンをベクトルに保存する。
＜５＞乱数Ｎを−１〜１の範囲で生成する
＜Ａ＞Ｎ＝−１の場合、最後の鍵トークンをベクトルから削除する。
＜Ｂ＞Ｎ＝０の場合、何もしない
＜Ｃ＞Ｎ＝１およびユーザーピン長＜６の場合、テーブル内の１６からのランダムなトークンをベクトルに追加する。
＜６＞ベクトル内のトークンが最終の鍵トークンである。

前述の実施形態および利点は例に過ぎず、本発明を制限するとして解釈されないものとする。本発明の説明は、例示を目的としており、クレームの範囲を制限するものではない。多くの代替、修正、および変形が当業者には明らかであろう。様々な変更が、以下のクレームで定義するように、本発明の精神および範囲から逸脱することなく、行われ得る。

例えば、本発明は、記号の４つの次元および５つの次元がそれぞれ使用される、ＧＡＴＥ＿４およびＧＡＴＥ＿５実施形態に関連して説明してきたが、任意の数の次元（１つだけの次元を含め）が使用され得、依然として本発明の範囲に含まれる。一般に、各トークンが２つ以上の記号を有する限り、任意の数の次元に分類された任意の数の記号が使用され得る。さらに、前述のＧＡＴＥ＿４およびＧＡＴＥ＿５実施形態、ならびに関連したスクリーンショットは、例示を意図し、本発明の範囲を制限することは意図していない。

Claims (42)

1. 記号のセットから選択された所定の数の記号（「パスコード記号」）を含む所定の電子的に格納されたパスコード（「パスコード」）を使用して、電子的に格納された情報にユーザーがアクセスするのを許可する（「認証する」）方法であって、前記パスコード記号の各々が所定のピン位置によって特徴付けられ、
   トークンセットを電子装置のユーザーインタフェースを介して前記ユーザーに提示することであって、前記トークンセットが少なくとも２つのトークンを含み、かつ前記トークンセット内の各トークンが、記号の前記セットに属する少なくとも２つの記号を含む、トークンセットを前記ユーザーに提示することと、
   前記ユーザーが、前記ユーザーインタフェースを介して、前記パスコード内の各ピン位置に対して、前記トークンセットから１つのトークンを選択することを要求することと、
   前記ユーザーが選択した前記トークンに基づいて前記ユーザーを認証することであって、前記ユーザーは、
   前記ユーザーによって選択されたトークンの数が前記パスコード内の記号の数に等しく、
   選択された前記トークンの少なくとも１つが前記パスコード記号のそれぞれ１つを含み、かつ
   前記パスコード記号のそれぞれ１つを含む前記選択されたトークンの各々の前記ピン位置が、前記パスコード内のそのそれぞれのパスコード記号の前記ピン位置に対応する
   場合に、認証される、前記ユーザーを認証することと
   を含む、方法。
2. 前記ユーザーによって選択されたトークンの前記数が前記パスコード内の記号の前記数に等しく、
   選択された各トークンが、前記パスコード記号のそれぞれ１つを含み、かつ
   前記パスコード内の前記記号のどれが前記選択されたトークンの各々内に含まれるかに基づいて、前記選択されたトークンの各々の前記ピン位置が前記パスコード記号の各々の前記ピン位置に対応する
   場合に、前記ユーザーが認証される、請求項１に記載の方法。
3. 記号の前記セット内の記号の前記数が、前記ユーザーに提示されるトークンの数に等しい、請求項１に記載の方法。
4. 記号の前記セット内の記号の前記数が、前記ユーザーに提示されるトークンの前記数より大きい、請求項１に記載の方法。
5. 記号の前記セットが、少なくとも２つのサブセット（「次元」）に分割され、各トークンが、少なくとも２つの次元の各々からの１つの記号を含む、請求項１に記載の方法。
6. 各トークンが、記号の前記セットに属する４つの記号を含む、請求項１に記載の方法。
7. 記号の各セットが、４つのサブセット（「次元」）に分割され、各トークンが、記号の各次元からの１つの記号を含む、請求項６に記載の方法。
8. 各トークンが、記号の前記セットに属する５つの記号を含む、請求項１に記載の方法。
9. 記号の各セットが、５つのサブセット（「次元」）に分割され、各トークンが、記号の各次元からの１つの記号を含む、請求項８に記載の方法。
10. 記号の前記セットがＵｎｉｃｏｄｅシステムに基づく、請求項１に記載の方法。
11. 記号のセットから選択された所定の数の記号（「パスコード記号」）を含む所定の電子的に格納されたパスコード（「パスコード」）を使用して、電子的に格納された情報にユーザーがアクセスするのを許可する（「認証する」）ためのシステムであって、前記パスコード記号の各々が、所定のピン位置によって特徴付けられて、
    プロセッサと、
    前記プロセッサによってアクセス可能なメモリと、
    前記プロセッサによって
    トークンセットを前記ユーザーに提示することであって、前記トークンセットが、少なくとも２つのトークンを含み、前記トークンセット内の各トークンは、記号の前記セットに属する少なくとも２つの記号を含む、トークンセットを前記ユーザーに提示することと、
    前記パスコード内の各ピン位置に対してユーザーインタフェースを介して前記トークンセットから１つのトークンを選択することをユーザーに要求することと、
    前記ユーザーが選択した前記トークンに基づいて前記ユーザーを認証することであって、前記プロセッサは、
    前記ユーザーによって選択されたトークンの前記数が前記パスコード内の記号の前記数に等しく、
    選択された前記トークンの少なくとも１つが前記パスコード記号のそれぞれ１つを含み、かつ
    前記パスコード記号のそれぞれ１つを含む前記選択されたトークンの各々の前記ピン位置が、前記パスコード内のそのそれぞれのパスコード記号の前記ピン位置に対応する
    場合に、前記ユーザーが認証されると判断する、前記ユーザーを認証することと
    を行うために実行可能な、メモリ内に格納されたコンピュータ可読命令のセットを含む認証／暗号化モジュールと
    を備える、システム。
12. 前記ユーザーによって選択されたトークンの前記数が前記パスコード内の記号の前記数に等しく、
    選択された各トークンが、前記パスコード記号のそれぞれ１つを含み、かつ
    前記パスコード内の前記記号のどれが前記選択されたトークンの各々内に含まれるかに基づいて、前記選択されたトークンの各々の前記ピン位置が前記パスコード記号の各々の前記ピン位置に対応する
    場合に、前記ユーザーが認証される、と前記プロセッサが判断する、
    請求項１１に記載のシステム。
13. 記号の前記セット内の記号の前記数が、前記ユーザーに提示されるトークンの前記数に等しい、請求項１１に記載のシステム。
14. 記号の前記セット内の記号の前記数が、前記ユーザーに提示されるトークンの前記数より大きい、請求項１１に記載のシステム。
15. 記号の前記セットが、少なくとも２つのサブセット（「次元」）に分割され、各トークンが、少なくとも２つの次元の各々からの１つの記号を含む、請求項１１に記載のシステム。
16. 各トークンが、記号の前記セットに属する４つの記号を含む、請求項１１に記載のシステム。
17. 記号の各セットが、４つのサブセット（「次元」）に分割され、各トークンが、記号の各次元からの１つの記号を含む、請求項１５に記載のシステム。
18. 各トークンが、記号の前記セットに属する５つの記号を含む、請求項１１に記載のシステム。
19. 記号の各セットが、５つのサブセット（「次元」）に分割され、各トークンが、記号の各次元からの１つの記号を含む、請求項１８に記載のシステム。
20. 記号の前記セットがＵｎｉｃｏｄｅシステムに基づく、請求項１１に記載のシステム。
21. 記号のセットから選択された所定の数の記号（「パスコード記号」）を含む所定の電子的に格納されたパスコード（「パスコード」）を利用する情報のための暗号化／復号方法であって、前記パスコード記号の各々が所定のピン位置によって特徴付けられ、
    暗号化すべき元の情報（「元の情報」）を受信することであって、前記元の情報は、所定数の元の情報要素をそれぞれの情報要素位置内に含み、元の情報要素は情報要素のセットから選択される、暗号化すべき元の情報（「元の情報」）を受信することと、
    暗号化された情報を生成するために、情報要素の前記セットからランダムに選択された情報要素「（ランダムな情報要素）」を前記元の情報にランダムな情報要素位置で挿入することと、
    各元の情報要素およびランダムな情報要素に対してトークンセットを生成することであって、各トークンセットが少なくとも２つのトークンを含み、各トークンセット内の各トークンが、記号の前記セットに属する少なくとも２つの記号を含む、各元の情報要素およびランダムな情報要素に対してトークンセットを生成することと、
    前記暗号化された情報内の各元の情報要素およびランダムな情報要素に対してそれぞれの鍵を生成することであって、各鍵は少なくとも２つの鍵トークンを含み、各鍵トークンは、記号の前記セットからの少なくとも２つの記号を含み、かつ、各鍵トークン内の記号の前記数が各トークンセットの各トークン内の記号の前記数に等しい、前記暗号化された情報内の各元の情報要素およびランダムな情報要素に対してそれぞれの鍵を生成することと
    を含み、
    前記鍵トークンおよびトークンセットは、それらが前記暗号化された情報を復号するために前記パスコードと一緒に合わせて使用できるように、生成される、
    情報のための暗号化／復号方法。
22. 復号プロセス中に、前記暗号化された情報内の情報要素は、
    前記情報要素の対応する鍵内の鍵トークンの数が、前記パスコード内の記号の前記数に等しく、
    前記情報要素の対応する鍵内の前記鍵トークンの少なくとも１つが、前記パスコード記号のそれぞれ１つを含み、かつ
    前記パスコード記号のそれぞれ１つを含む前記情報要素の対応する鍵内の前記鍵トークンの各々のピン位置が、前記パスコード内のそのそれぞれのパスコード記号の前記ピン位置に対応する、場合に、
    有効な情報要素であると判断される、請求項２１に記載の方法。
23. 復号プロセス中に、前記暗号化された情報内の情報要素は、
    前記情報要素の対応する鍵内の鍵トークンの数が、前記パスコード内の記号の前記数に等しく、
    前記情報要素の対応する鍵内の各鍵トークンが、前記パスコード記号のそれぞれ１つを含み、かつ
    前記パスコード記号のそれぞれ１つを含む前記情報要素の対応する鍵内の前記鍵トークンの各々のピン位置が、前記パスコード内のそのそれぞれのパスコード記号の前記ピン位置に対応する、場合に、
    有効な情報要素であると判断される、請求項２１に記載の方法。
24. 記号の前記セットが、少なくとも２つのサブセット（「次元」）に分割され、各トークンおよび各鍵トークンが、前記少なくとも２つの次元の各々からの１つの記号を含む、請求項２１に記載の方法。
25. 記号の前記セット内の記号の前記数が、前記トークンセット内のトークンの前記数に等しい、請求項２１に記載の方法。
26. 記号の前記セット内の記号の前記数が、前記トークンセット内のトークンの前記数より大きい、請求項２１に記載の方法。
27. 各鍵トークンが、記号の前記セットに属する４つの記号を含む、請求項２１に記載の方法。
28. 記号の各セットが、４つのサブセット（「次元」）に分割され、各トークンおよび各鍵トークンが、記号の各次元からの１つの記号を含む、請求項２７に記載の方法。
29. 各鍵トークンが、記号の前記セットに属する５つの記号を含む、請求項２１に記載の方法。
30. 記号の各セットが、５つのサブセット（「次元」）に分割され、各トークンおよび各鍵トークンが、記号の各次元からの１つの記号を含む、請求項２９に記載の方法。
31. 情報要素の前記セットがＵｎｉｃｏｄｅシステムに基づく、請求項２１に記載の方法。
32. 記号のセットから選択された所定の数の記号（「パスコード記号」）を含む所定の電子的に格納されたパスコード（「パスコード」）を利用する情報の暗号化／復号のためのシステムであって、前記パスコード記号の各々が、所定のピン位置によって特徴付けられて、
    プロセッサと、
    前記プロセッサによってアクセス可能なメモリと、
    前記プロセッサによって
    暗号化すべき元の情報（「元の情報」）を受信することであって、前記元の情報は、所定数の元の情報要素をそれぞれの情報要素位置内に含み、前記元の情報要素は情報要素のセットから選択される、暗号化すべき元の情報（「元の情報」）を受信することと、
    暗号化された情報を生成するために、情報要素の前記セットからランダムに選択された情報要素「（ランダムな情報要素）」を前記元の情報にランダムな情報要素位置で挿入することと、
    各元の情報要素およびランダムな情報要素に対してトークンセットを生成することであって、各トークンセットが少なくとも２つのトークンを含み、各トークンセット内の各トークンが、記号の前記セットに属する少なくとも２つの記号を含む、各元の情報およびランダムな情報要素に対してトークンセットを生成することと、
    前記暗号化された情報内の各元の情報要素およびランダムな情報要素に対してそれぞれの鍵を生成することであって、各鍵は少なくとも２つの鍵トークンを含み、各鍵トークンは、記号の前記セットからの少なくとも２つの記号を含み、かつ、各鍵トークン内の記号の前記数が各トークンセットの各トークン内の記号の前記数に等しく、
    前記鍵トークンおよびトークンセットは、それらが前記暗号化された情報を復号するために前記パスコードと一緒に合わせて使用できるように、生成されることと
    を行うために実行可能な、メモリ内に格納されたコンピュータ可読命令のセットを含む認証／暗号化モジュールと
    を備える、システム。
33. 復号プロセス中に、前記プロセッサが、前記暗号化された情報内の情報要素は、
    前記情報要素の対応する鍵内の鍵トークンの前記数が、前記パスコード内の記号の前記数に等しく、
    前記情報要素の対応する鍵内の前記鍵トークンの少なくとも１つが、前記パスコード記号のそれぞれ１つを含み、かつ
    前記パスコード記号のそれぞれ１つを含む前記情報要素の対応する鍵内の前記鍵トークンの各々のピン位置が、前記パスコード内のそのそれぞれのパスコード記号の前記ピン位置に対応する、場合に、
    有効な情報要素であると判断する、請求項３２に記載のシステム。
34. 復号プロセス中に、前記プロセッサが、前記暗号化された情報内の情報要素は、
    前記情報要素の対応する鍵内の鍵トークンの前記数が、前記パスコード内の記号の前記数に等しく、
    前記情報要素の対応する鍵内の各鍵トークンが、前記パスコード記号のそれぞれ１つを含み、かつ
    前記パスコード記号のそれぞれ１つを含む前記情報要素の対応する鍵内の前記鍵トークンの各々のピン位置が、前記パスコード内のそのそれぞれのパスコード記号の前記ピン位置に対応する、場合に、
    有効な情報要素であると判断する、請求項３２に記載のシステム。
35. 記号の前記セットが、少なくとも２つのサブセット（「次元」）に分割され、各トークンおよび各鍵トークンが、前記少なくとも２つの次元の各々からの１つの記号を含む、請求項３２に記載のシステム。
36. 記号の前記セット内の記号の前記数が、前記トークンセット内のトークンの前記数に等しい、請求項３２に記載のシステム。
37. 記号の前記セット内の記号の前記数が、前記トークンセット内のトークンの前記数より大きい、請求項３２に記載のシステム。
38. 各鍵トークンが、記号の前記セットに属する４つの記号を含む、請求項３２に記載のシステム。
39. 記号の各セットが、４つのサブセット（「次元」）に分割され、各トークンおよび各鍵トークンが、記号の各次元からの１つの記号を含む、請求項３８に記載のシステム。
40. 各鍵トークンが、記号の前記セットに属する５つの記号を含む、請求項３２に記載のシステム。
41. 記号の各セットが、５つのサブセット（「次元」）に分割され、各トークンおよび各鍵トークンが、記号の各次元からの１つの記号を含む、請求項４０に記載のシステム。
42. 情報要素の前記セットがＵｎｉｃｏｄｅシステムに基づく、請求項３２に記載のシステム。

Images