JP2008538628A - 信用証明インタフェース - Google Patents

Abstract

【解決手段】
信用証明インタフェースを可能にするシステム及び／又は方法を説明する。これらのシステム及び／又は方法は、ユーザが複数の信用証明の中から選択すること及び選択された信用証明に対して認証メッセージを提出することを可能にする信用証明ユーザインタフェースを構築できる。これらのシステム及び／又は方法はまた、任意の信用証明についての情報を収集し、及びこれら任意の信用証明に対して認証メッセージを提出するためのユーザインタフェースを構築できる。
【選択図】 図２

Description

本発明は、人物の身元を認証するために使用されるユーザインタフェースに関する。

信用証明は、人が自身の言う人物であるか否かを判定するために使用され得る。例えば、ある人が銀行の出納係のところへ行き、彼の名前が「Ｊ．ウォーレン スモーリー」であって、Ｊ．ウォーレン スモーリーが保持するチェックキング口座から２００ドルを引き出したいと言っていると仮定しよう。その銀行の出納係は、この人が本当にＪ．ウォーレン スモーリーかを判定するために信用証明を使用し得る。多くの場合、銀行は、写真及び名前を有するパスポート又は運転免許証のような文書の信用証明を使用する。この人がその文書上に写真撮影されたその人のように見え、及びその文書がＪ．ウォーレン スモーリーの写真であると述べている場合、銀行はこの人物が実際にＪ．ウォーレン スモーリーであることを認証できる。

銀行はまた、特定の人に固有の秘密又は何か別のタイプの信用証明を使用し得る。銀行がＪ．ウォーレン スモーリーの署名−Ｊ．ウォーレン スモーリーを特定するもの―を示す記録を持っていてかつ、この人の署名がその記録上の署名と一致する場合、銀行は、この人物がＪ．ウォーレン スモーリーであると認証し得る。銀行はまた、パスワードのような秘密を使ってこの人物を認証し得る。したがって、この人がＪ．ウォーレン スモーリーの個人識別番号（ＰＩＮ）に一致するＰＩＮを銀行の出納係に提出する場合、銀行は、この人が自分の言う人物であることを認証し得る。

コンピュータもまた、多くの場合、人々を識別する主な信用証明として名前／パスワード対を使用し、人々を識別するために人々と対話する。多くのコンピュータのオペレーティングシステムは、例えば、認証のためにパスワードを提出することをユーザに要求する。この対話を可能にするために、オペレーティングシステムは、グラフィカルユーザインタフェースを表示し得る。このインタフェースは、多様なユーザに関連付けられたアカウントを示し、これらのアカウントの中の１つをその人に選択させ、及びその選択されたアカウント用パスワードを入力させることができる。その後オペレーティングシステムは、入力されたパスワードを受信し、このパスワードがその選択されたアカウントに関連付けられたユーザを識別することを認証する。オペレーティングシステムは、その後その人物をログオンさせて、特定の動作等を許可し得る。

しかし、このグラフィカルユーザインタフェースは、多くの場合、ユーザが認証される単一の信用証明タイプ―ユーザ名及びパスワード―のみを可能とする。別の信用証明タイプが所望されるか又は後に開発された場合、これは問題となるに違いない。ある会社が、優れた又はユーザ名／パスワードの信用証明と併せて少なくとも役立つ信用証明タイプを開発する場合、その会社は、この信用証明タイプの使用を有効にさせるために新規のグラフィカルユーザインタフェースを作成する必要があり得る。その会社が人の親指指紋を基にした信用証明タイプを開発したと仮定しよう。その会社は人の親指を読み取るスキャナ及び読み取った親指が特定の人と一致することを認証可能なソフトウェアを販売する。しかしコンピュータがこの信用証明を使用できるようにするためには、会社はコンピュータで多くの場合使用されている、パスワードを基にしたユーザインタフェースと置き換わる新規のユーザインタフェースを記述する必要があるだろう。この新規のユーザインタフェースは、熟練したプログラマにとっても設計するのに多くの週又は月日の時間がかかり得る。

また、ある会社がたとえこの新規のユーザインタフェースを設計したとしても、別の会社は網膜を基にした信用証明のような別の信用証明タイプを導入してくる。この場合、網膜を読み取る会社は、その網膜を基にした信用証明を使用できるようにコンピュータ用に別のユーザインタフェースを作成する必要があり得る。そうするとこのユーザインタフェースは、親指指紋を基にした信用証明を扱うことができないことがあり得る。会社又は政府がパスワード、親指指紋及び網膜の読み取りを使って人物の認証を望む場合、より多くの時間及び努力を費やすさらに別のユーザインタフェースを作成せずにこれを達成することはできないであろう。

信用証明の提示及び／又は収集を可能にするシステム及び／又は方法（「ツール」）を説明する。実施形態の中には、ツールがユーザに複数の信用証明のタイプの中から選択及び／又は提出を可能にするグラフィックカルな信用証明インタフェースを構築するものがある。別の実施形態の中には、そのツールがまた、任意のタイプの信用証明を収集し、及びこれらの任意のタイプの信用証明を提出するためのユーザインタフェースを構築するものもある。

開示及び図を通して、同等な要素及び特徴の参照には同じ番号が使用されている。

概要
以下の開示では、信用証明インタフェースを可能にする１つ以上のツールを説明する。一実施形態では、ツールは、ユーザが複数タイプの信用証明の中から選択及び／又は提出することを可能にする信用証明インタフェースを作成する。例えばそのユーザが彼又は彼女のパスワードを忘れてしまった場合、これは、ユーザが名前／パスワード信用証明のパスワード認証メッセージの代わりに信用証明の親指指紋認証メッセージを提出することを選択できるという点でユーザを援助し得る。複数の認証メッセージ、例えばパスワード及び網膜の読み取りを提出可能にすることによってユーザが正しく識別されるということがより大きな信頼を可能にもし得る。

別の実施形態では、そのツールは、任意のタイプの信用証明についての情報を収集し、及びこれら任意タイプの信用証明に対する認証メッセージの提出のためのユーザインタフェースを構築する。そうすることによって、信用証明プロバイダは信用証明のユーザインタフェースを構築しないで済ませ、貴重な時間と労力を節約し得るかもしれない。
例示的な動作環境
ツールを詳細に説明する前に、ツールが使用される場所と方法を理解する点で読者を援助するため、典型的な動作環境の以下の考察を提供する。後で提供される説明は、ほんの１つの例のみで構成されているが、ツールの適用をある１つの特定の動作環境に限定するつもりはない。

図１は、１つ以上のプロセッサ（１０４）及び計算機可読媒体（１０６）を有するコンピュータ（１０２）からなる１つの前記動作環境（１００）を一般に例示している。プロセッサは、その計算機可読媒体をアクセス及び／又は実行可能である。計算機可読媒体は、オペレーティングシステム（１０８）、認証リクエスタ（１１０）、信用証明ユーザインタフェース（１１４）を有する信用証明アプリケーション（１１２）、第１の信用証明プロバイダ（１１６）、第２の信用証明プロバイダ（１１８）、第３の信用証明プロバイダ（１２０）、及び認証モジュール（１２２）からなる。

認証リクエスタ（１１０）は、ソフトウェア、アプレット、モジュール、又は人物の認証を要求可能な別の実体からなり得る。そのリクエスタは、オペレーティングシステムのセキュリティ部又はプログラム、例えば母体となる制御ソフトウェアのような制御アクセス（ｃｏｎｔｒｏｌｌｅｄ−ａｃｃｅｓｓ）ソフトウェア等の一部であるか又はそれらからなり得る。

信用証明アプリケーション（１１２）は、信用証明ユーザインタフェース（１１４）を可能にする。信用証明アプリケーションはいくつかの場合の、第１、第２、及び第３の信用証明プロバイダ（１１６）、（１１８）、及び（１２０）のような任意のソースから及び任意のタイプの信用証明を収集することによって、信用証明ユーザインタフェースを構築又は調整し得る。その信用証明ユーザインタフェースはまた、ユーザが１つ又は数種の信用証明の認証メッセージを選択し及び提出可能にするためにも構築され得る。

信用証明プロバイダは、自身の信用証明についての情報を提供する。一実施形態では、信用証明プロバイダは、自身の信用証明についての情報及び、ユーザインタフェースの中で信用証明プロバイダが好むものについての基本情報を提供する。これは、信用証明を説明するテキストを伴ったデータ入力フィールドのプリファランス（ｐｒｅｆｅｒｅｎｃｅ）と、そのフィールドがそのユーザインタフェース等の中でどのように表示されるべきかを示す情報からなり得る。後述する一実施形態では、第１の信用証明プロバイダは、オペレーティングシステム（１０８）と一体か関連付けられていてかつ、名前／パスワード信用証明からなる。

認証モジュール（１２２）は、各信用証明プロバイダと一体となっているか又は個別であり得る。各信用証明プロバイダに１つの複数の認証モジュールか、又は１つの認証モジュールがあり得る。認証モジュールは、信用証明ユーザインタフェースを介して提出された信用証明の認証メッセージが、特定の身元又はその信用証明に関連付けられたアカウントを認証するか否かを判定することができる。それ（認証モジュール）がどのようにそうするかは、提出された信用証明の信用証明プロバイダによるか又は別の方法によって指示され得る。

コンピュータ（１０２）におけるこれらの要素の多様な実施形態、及びこれらの要素が、典型的なプロセスを実行し、及び典型的なユーザインタフェースを製造するために、具体的にどのように動作及び内部動作するのかが後でより詳細に説明される。
オペレーティングシステムへのログオン
計算機器が信用証明を使って人物を認証するために使用され得る多くの事例がある。これらの場合の１つが、人がコンピュータのオペレーティングシステムへのログオンすることである。以下の考察は、動作環境（１００）の要素によって、人が１つ以上の信用証明を使ってコンピュータ（１０２）のオペレーティングシステム（１０８）にログオン可能にする典型的な手法を説明する。この考察は、ツールの範囲又は適用性をオペレーティングシステムに人がログオンすることに限定することを意図するものではない。

図２では、人がオペレーティングシステムにログオン可能なための典型的なフロー図（２００）を示す。フロー図（２００）は、環境（１００）の要素、及びユーザ（２０２）の間の通信による及び伴う一連の動作を例示する。−ここで示される要素は、オペレーティングシステム（１０８）、認証リクエスタ（１１０）、信用証明アプリケーション（１１２）、信用証明ユーザインタフェース（１１４）、信用証明プロバイダ（１１６）、（１１８）及び（１２０）及び認証モジュール（１２２）である。動作及び付随する通信は、矢印で記される。フロー図は、コンピュータ要素の動作及びユーザの動作、２者を分ける点線を横断する線によって表示されたコンピュータとユーザの間の通信を示しながら示される。このフロー図は、ある適合した任意のハードウェア、ソフトウェア、ファームウェア、又はこれらの組み合わせで実装され得る。ソフトウェア及びファームウェアの場合、この図は、（そのユーザの指示を除いて）計算機実行可能命令として実装される一連の動作を表す。

矢印（１）でユーザ（２０２）は、コンピュータ（１０２）を起動するか又はさもなければオペレーティングシステム（１０８）へのログオンの要求を示す。この指示を受け取ると、オペレーティングシステムは、直接的に又は間接的に矢印（２）で信用証明アプリケーションとの通信の結果、被認証ユーザ（２０２）に認証用の適切な信用証明を収集することを要求する。ある場合には、例えばユーザがすでにログインしていてかつ、認証が母体となる制御ソフトウェアによって要求されているときはオペレーティングシステムは、認証リクエスタではない。しかし、例示した実施形態では、オペレーティングシステム及び重なっている認証リクエスタの四角形で示されるようにオペレーティングシステムはまた認証リクエスタでもある。

矢印（３）で信用証明アプリケーション（１１２）は、１つ以上の信用証明プロバイダから信用証明情報を受信する。ここで第１、第２及び第３の信用証明プロバイダ（１１６）、（１１８）、及び（１２０）は、信用証明アプリケーションで事前に登録されている。信用証明アプリケーションは、信用証明情報を事前に受信済か又は要求してこの時点で受信している。信用証明アプリケーションは、所定のＡＰＩを介して信用証明ユーザインタフェース（１１４）へその信用証明情報を提出する。

信用証明情報は、その信用証明についての情報及び信用証明アプリケーション（１１２）がユーザに信用証明タイプ（又は１つのタイプが複数のプロバイダを有している場合は、選択したプロバイダ及び信用証明タイプ）を選択させ、及びその選択したタイプの信用証明を提出させるユーザインタフェースを構築又は調整するのに十分な情報からなる。

例示したその実施形態で、第１の信用証明プロバイダ（１１６）は、パスワードタイプの信用証明からなる。プロバイダ（１１６）は、プログラムコード又はオペレーティングシステム（１０８）に関連付けられた又は一体となったデータベースである。パスワード信用証明の信用証明情報は、そのユーザインタフェース内で信用証明を表現（ｒｅｎｄｅｒ）するのに必要なフィールドタイプのリスト（例えばユーザ名のための静的テキストフィールド及びパスワードのための編集ボックスフィールドタイプ）と、各フィールドの（例えば隠された、読み取り専用の、無効の、フォーカスされた）状態と、各フィールドのためのアクセス可能性ラベルと、及びフィールドに関連づけられたデータとからなる。

この信用証明情報は、以下のテキスト（形、色、又はテキストのサイズではない）がユーザに表示されるべきことを示す：
「パスワードで認証しますか？」
その信用情報はまた、パスワード信用証明が選択される場合、例えば以下のテキストを伴ったデータ入力フィールドのようなテキスト及びデータ入力フィールドも表示すす：
「パスワードを提示し、入力キーを押下してください。」
第２の信用証明プロバイダ（１１８）は、親指指紋タイプの信用証明からなる。プロバイダ（１１８）は、その信用証明アプリケーションが、ユーザによるこの生体タイプの信用証明が提出可能なユーザインタフェースを構築するのに十分な信用証明の情報を信用証明アプリケーションに送信する。ここで信用証明の情報は、信用証明データ及び信用証明表示データからなる。表示データは、以下のテキストがユーザにこの信用証明を選択できるようにユーザに対して表示されるべきであるという指示からなる：
「親指読み取りで信用証明をしますか？」
及び信用証明プロバイダの名前：
「Acme Biometrics」
親指読み取りが選択される場合、表示データはまた以下の表示テキストからなる：
「親指読み取り装置上に右親指を置き、少なくとも１秒間保持して下さい。」
第３の信用証明プロバイダ（１２０）は、音声認識タイプの信用証明からなる。プロバイダ（１２０）は、信用証明アプリケーションが音声信用証明の受信を可能にするのに十分な信用証明情報を送信する。その信用証明情報はまた、以下のテキストがユーザにこの信用証明を選択できるように、ユーザに表示されるべき以下のテキストの指示からなる：
「音声読み取りで認証しますか？」
及び信用証明プロバイダの名前：
「Advanced Audio Recognition」
この情報はまた、音声信用証明が選択される場合に表示されるべき別のテキストからなる：
「コンピュータのマイクに以下を言ってください：「One, Two, Buckle My Shoe.」」
矢印（４）で信用証明アプリケーション（１１２）は、その信用証明情報を基に信用証明収集ユーザインタフェースを構築及び／又は調整する。ここで信用証明アプリケーションは、前述した３つの信用証明を表示できるように信用証明ユーザインタフェースを調整する。

矢印（５）で信用証明ユーザインタフェース（１１４）は、選択可能な信用証明をユーザ（２０２）へ表示する。その信用証明ユーザインタフェースは、信用証明を表示し、ユーザが例えばテキスト又は付随するグラフィックスをクリックするか又は信用証明に対して認証メッセージを間接的に提出することによって、直接それらを選択することが可能にする。

図３でログオン信用証明インタフェース（３０２）を示す。ログオン信用証明インタフェースは、３つのタイプの信用証明を提示し、ユーザがこれら３つの中から１つを選択できるようにする。第１は、（３０４）で示す名前／パスワードの信用証明であり、第２は、（３０６）で示す（ユーザの識別子又はアカウント及び親指読み取り認証メッセージからなる）親指信用証明であり、そして第３は、（３０８）で示す（ユーザの識別子又はアカウント及び音声認識認証メッセージからなる）音声認識信用証明である。

ログオン信用証明インタフェースは、受信した信用証明情報の発信者である信用証明プロバイダ向けに調整されている。この実施形態では、「パスワードで認証しますか？」、「親指読み取りで認証しますか？」、「Acme Biometrics」、「音声読み取りで認証しますか？」、及び「Advanced Audio Recognition」といった語句は、そのインタフェースに内蔵されている。これらの各信用証明のオプションはまた、オプションのグラフィックスでも示される。ここでグラフィックスは、信用証明プロバイダによってアクセス可能なように事前に構築されたライブラリから信用証明プロバイダによって選択される。

矢印（６）でユーザ（２０２）は、信用証明の中の１つを選択する。実施形態の中には、ユーザが単一の認証メッセージタイプの代わりに（例えば、選択した信用証明がパスワード及び親指指紋読み取りの双方を要求する）複数の認証メッセージタイプから構築された信用証明を選択し得るものもある。例示した実施形態でユーザは、その信用証明の中の１つである、ここでは親指信用証明（３０６）を選択する。また矢印（６）で信用証明ユーザインタフェースは、そのユーザが選択を受信する。

矢印（７）で信用証明ユーザインタフェース（１１４）は、認証メッセージの提出を可能化する。ある場合では、信用証明ユーザインタフェースは、その信用証明に関連付けられた認証メッセージの提出のためのパスワード又はその同種のもののような、データ入力フィールドを表示することによってそれを実行する。別の場合では、データ入力フィールド又はグラフィカルユーザインタフェースは使用されない。

図４では親指信用証明の認証メッセージの提出用に調整されたログオン信用証明インタフェース（４０２）が示される。信用証明インタフェースは、そのユーザに対する指示（４０４）からなる。ここでこれらは、前の矢印（３）で受信した信用証明情報を基にしている。これらの指示は、親指認証メッセージを提出するために、ユーザが「親指の読み取り装置上に右親指を置いて、少なくとも１秒間保持する。」必要があることをユーザに知らせる。親指読み取り器は、親指認証メッセージを受信できるハードウェア及び／又はソフトウェア、ここでは生体読み取り機器からなる。

また矢印（７）で信用証明ユーザインタフェース（１１４）は、ユーザ（２０２）から親指認証メッセージの提出を受信する。

矢印（８）でこの認証メッセージを受信すると、信用証明ユーザインタフェースは、その信用証明に対する認証メッセージ及び識別子（ここでは提出された認証メッセージ及びアカウント名のような信用証明に関連付けられた識別子）を適切な信用証明プロバイダ（ここでは第２の信用証明プロバイダ（１１８））へ転送する。信用証明ユーザインタフェースは、このデータをその信用証明プロバイダへ直接か又は（図示しない）信用証明アプリケーション（１１２）を介して転送できる。そして、信用証明プロバイダは、認証モジュール（１２２）によって理解できる信用証明の形式で（双方とも信用証明に関連付けられた）識別子と提出された認証メッセージを共にパッケージ化し得る。認証メッセージは、読み取られた親指の形状及び他の定義している特性を示す拡張可能マークアップ言語（ＸＭＬ）のような特定のタイプ又は形式にパッケージ化し得る。

矢印（９）で信用証明プロバイダは、認証メッセージ及び識別子をパッケージ化し、認証リクエスタ（１１０）へこのパッケージ化した信用証明を送信する。それは、（図示された）信用証明アプリケーション（１１２）を介して信用証明プロバイダから転送され得る。この場合、信用証明アプリケーションは、パッケージ化された信用証明を受信し、その後認証リクエスタへそれを送信する。

矢印（１０）では、認証リクエスタ（１１０）は、パッケージ化された信用証明を認証モジュール（１２２）へ提出する。ここで認証モジュールは、第２の信用証明プロバイダ（１１８）から送信されたタイプの信用証明を認証する能力があるものである。また矢印（１０）で認証モジュール（１２２）は、受信した信用証明を解析し、その信用証明を認証するか又は認証するのに失敗し、そしてこの判定を連絡する。それと信用証明のデータベースとを比較し、（もし可能ならば）特定のユーザと一致させ、そうして提出された信用証明を認証するか又は認証を拒否する。拒否する場合、その要素は、そのユーザに失敗を知らせ、ユーザのために支援を与える。信用証明ユーザインタフェースがユーザに知らせる及び援助を与える方法は、デフォルトによるか又は矢印（３）で受信した信用証明情報向けに調整され得る。

認証モジュールが提出を認証する場合、これを認証リクエスタ（１１０）へ連絡する。この例示された実施形態で認証リクエスタは、これをオペレーティングシステム（１０８）へ直接連絡し得る。

認証の受信に応答して、矢印（１１）でオペレーティングシステム（１０８）は、ユーザ（２０２）をそのオペレーティングシステムにログオンさせる。
信用証明ユーザインタフェースの有効化
前述したオペレーティングシステムにユーザがログオンするための典型的なフロー図は、信用証明を使用してコンピュータにユーザを認証させるツールの方法のほんの１つの例である。以下のプロセスは、さらにツールの追加的な実施形態を説明及び提供する。

図５では、信用証明ユーザインタフェースを可能にするためのプロセス（５００）が示される。このプロセスは、任意の適合するハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせで実装され得る。ソフトウェア及びファームウェアの場合、このプロセスは、計算機実行可能命令として実装された一連の操作を示す。

ブロック（５０２）でツールは、信用証明情報を受信する。信用証明情報は、複数の信用証明プロバイダから及び複数のタイプを受信され得る。例えば、信用証明タイプは、親指生体、網膜生体、音声認識、パスワード及びスマートカードからなり得る。信用証明のタイプ及び出所は任意の未知の、タイプ又はプロバイダでさえあり得る。この能力は、信用証明の提出のために、拡張可能なユーザインタフェースをツールが生成することを可能にすることを助けるものであって以下で説明される。

信用証明情報は、ツールが信用証明に対する認証メッセージの提出を可能にするのに十分なタイプ及び形式からなる。そのタイプ及び形式は、公にアクセス可能なウェブサイトのように、公に利用可能であり得る。この情報は、例えば、あるタイプのデータ入力フィールドが必要であることの表示、表示されるべき質問又は指示、示されるべきグラフィックス、認証メッセージが受信するためのハードウェア又はソフトウェアプロトコル等の指示からなる。グラフィックスは、デフォルト又は受信した信用証明情報を基にしてツールによって選択され得る。受信した信用証明情報を基にする場合、グラフィックスは、企業の特別注文のアイコン又はプロバイダ及びツールに利用可能な予め作成されたライブラリからその会社によって選択されたアイコン又はグラフィックスからなり得る。

この情報は、信用証明プロバイダが代わりに自らのユーザインタフェースを作成する場合に多くの場合かかるよりも少ない労力及び大きな信頼性を伴い、信用証明プロバイダによって提供される。その認証情報はまた、ツールが認証を実行する必要がないように、特有の認証メカニズム等を露わにしないタイプでもあり得る。信用証明情報はまた、一実施形態では、ログオンフロー図（２００）中で説明したようなタイプであり及びそのような方法で受信される。

その信用証明情報を受信するために、ツールは、信用証明プロバイダのための信用証明レジストリを通して検索し、信用証明情報に関してそれぞれ問い合わせる。信用証明情報は、単一ステップか又はユーザへオプションを提示するのに十分な信用証明情報を受信することかつ、ユーザがその信用証明を選択する場合、その信用証明に対する認証メッセージの提出を可能にするのに十分な追加の信用証明情報を受信することといった複数のステップで受信され得る。

ブロック（５０４）でツールは、ユーザを認証する及び／又は１つ以上の信用証明を収集するための要求を受信する。ツールは、フロー図（２００）に従って、オペレーティングシステム（１０８）のような、オペレーティングシステムからこのリクエストを受信し得る。ツールはまた、例えばユーザがアカウントを切り替えたり、認証が必要な動作を実行したり等を望むときに、制御アクセスソフトウェア又はユーザから直接にこの要求を受信し得る。ツールは、ユーザがログオンした後の操作のみを含む、コンピュータのシステム又はプロセスフローを通して存在する多様な要求をする実体に対して受信及び応答し得る。

ブロック（５０６）でツールは、ユーザが例えば信用証明に対する識別子を選択することによって、認証メッセージの提出及び／又は信用証明それ自身を選択できるようにする。ツールは、グラフィカルユーザインタフェース又は不可視的なインタフェースを介してそれを実行し得る。

信用証明アプリケーションは、ユーザが信用証明を選択（例えば、信用証明の名前又はアイコン上をクリックすることによって信用証明自体を選択）し、及び信用証明に対して認証メッセージを提出することを可能にするのに十分なユーザインタフェースを構築又は調整し得る。信用証明アプリケーションは、しかし、信用証明ユーザインタフェースに対して重大な目に見えるカスタマイズなしで済まし得る。そうすることによって、ユーザは、複数の信用証明及び信用証明プロバイダのそれぞれに対する一貫した外見を見ることができる。またそうすることによって、少量の情報を信用証明プロバイダから受信し得る。信用証明情報が、コンピュータディスプレイ上の所与の解像度（ＤＰＩ）で見るのにどのようにするか、ウィンドウズ（登録商標）にログオンする（ＷｉｎＬｏｇｏｎ）イベントの応答プロトコルや、ローカライズや、キーボードアクセシビリティや、スクロール等について信用証明アプリケーションに指示する情報を含む必要はない。しかしツールは受信した信用証明情報上の一部を基にしてユーザインタフェースを構築又は調整するので、信用証明プロバイダがパスワード入力のためにデータ入力フィールドを必要とすることを示す場合、このデータ入力フィールドを表示し得る。

不可視インタフェースに関してツールは、例えば親指読み取り部上に彼又は彼女の親指をユーザが置くことによって簡単に親指の読み取りの受信を可能にすることによって、ユーザがビジュアルなプロンプト又は指示がなくても信用証明を選択し及び認証メッセージの提出を可能にし得る。この場合、信用証明情報は、例えば、コンピュータのスピーカシステムを介して聞こえるように生成されるべき質問又は指示と、（ここでは特定の親指読み取り器のタイプによって生成されたフォーマットでの親指読み取りからのデータである）受信を可能にする認証メッセージの提出フォーマットと、及び信用証明に対する認証メッセージを受信するためのハードウェアまたはソフトウェアプロトコル、とからなる。

グラフィカルユーザインタフェースに関してツールは、複数の信用証明及び／又は信用証明のソースを示すスクリーン上に表示可能なユーザインタフェースを構築し得る。このタイプのユーザインタフェースの一例が図３中に示されており、そこでは３つの信用証明が提示されている。

図６は、グラフィカルユーザインタフェース（６０４）の一部として名前／パスワード信用証明に対するパスワード認証メッセージの提出を可能にするデータ入力フィールド（６０２）を示す。ここでパスワード認証メッセージは、ユーザが「アビー サラザール」であり、「アビー サラザール」と名付けられたアカウントを使用する権利を持っており、特定のプログラムをブロックしないために彼女の権利を引き上げる要求を認証するために使用され得る。したがって名前「アビー サラザール」を伴う名前／パスワード信用証明は、提出されたパスワードで認証され得る。

ユーザインタフェースは、ユーザが複数の信用証明（例えば図３及び４）から単一の信用証明を選択し、単一の認証メッセージ（例えば図６）を提出し、又は複数の認証メッセージから構成された単一の信用証明を選択（つまりユーザに複数の認証メッセージを提出することを要求）することを可能にする。ある場合ユーザは、例えば最初に信用証明リストから網膜信用証明の選択をせずに単に網膜読み取り器の近くに自らの目を置くことによって、その認証メッセージを有する信用証明を選択する個別の動作をせずに認証メッセージを提出し得る。ユーザが複数の信用証明から１つの信用証明を選択する例がフロー図（２００）の一部として説明され図３及び４中に示される。

ブロック（５０８）でツールは、ユーザから認証メッセージの提出を受信する。実施形態の中には、ツールがブロック（５１２）へ直接進むものもある。しかし、別の実施形態の中には、ツールが（以下のブロック（５１０）である）継続する処理の前に認証メッセージの提出を予備的にチェックする。信用証明情報が、例えばパスワード認証メッセージがスペースも算術記号も含まないことを指示している場合、ツールは、スペース及び算術記号について提出されたパスワードをチェックし得る。いずれも存在しない場合、ツールはブロック（５１２）へ進み得る。いずれかが存在する場合、ツールは提出されたパスワードが不正な形式であることを示し得る。ツールは、例えば「空白及び算術記号は許されていません、パスワードを再度入力してください。」又はデフォルトの方式で例えば「パスワードが不適切な形式です、再入力してください。」という記述を使って、信用証明情報によって指示されるように実行し得る。この予備的なチェックは、信用証明の認証に必要とされる時間とリソースをいくらか低減し得る。例えば、ユーザが真でない認証メッセージを提出し、かつ再提出しなければならない場合、そのユーザは２つの認証プロセスを通して待たなければならない。一方、提出された認証メッセージがフォーマット等によって正しくないものであると即座に判定される場合、その認証プロセスの中の１つの実行がユーザに認証メッセージの再提出を指示することによって回避され得る。

ブロック（５１２）でツールは、認証のために提出された認証メッセージに関連付けられた信用証明を提出する。その信用証明は、フロー図（２００）中に記述されるように、個別の認証ソフトウェアへ送信され得る。

ツールによって提出された信用証明は、ユーザの認証を要求したプログラムのような他のプログラムが、現在禁止されているタスク等を許可するためにユーザの権利を引き上げ、ユーザにオペレーティングシステムにログオンさせるような多様な行動を許可することを可能にし得る。

また、本ツールは違った時間に違ったようにユーザインタフェースを調整し得る。ユーザインタフェースは、少なくともこの意味で柔軟でありかつ、拡張可能である。ツールは、例えば、新規のプロバイダから新規の信用証明を受信し得る。これに応答して、ツールは、これらの新規の信用証明に対する認証メッセージの選択及び提出を許可するようにユーザインタフェースを調整する。また、信用証明プロバイダは、信用証明情報の送信を中止し、又はシステム管理者は、もっと少ない信用証明を有するユーザインタフェースを望んでいるかもしれない。この変更に応答して、ツールは、信用証明の表示を中止するためにユーザインタフェースを変更し得る。
結論
信用証明インタフェースを可能化するシステム及び／又は方法が説明された。この信用証明インタフェースは、信用証明プロバイダがそれらの信用証明用ユーザインタフェースを構築せずに済ませることができるようにして貴重な時間と労力を節約できるかもしれない。本発明は、構造的な特徴及び／又は方法論的な段階に特定された言葉で説明してきたが、添付する請求項内に定義された本発明が説明された特定の特徴又は手順に限定される必要はないことを理解すべきである。むしろ、その請求された発明を実装するのに好ましい形式として特定の特徴及び手順が開示されている。

多様な実施形態が動作可能な典型的な動作環境を例示している。 ユーザがオペレーティングシステムにログオン可能な信用証明ユーザインタフェースを構築するための典型的なフロー図である。 ３つの信用証明タイプを選択可能な典型的なグラフィカルユーザインタフェースを例示している。 親指の信用証明の提出を扱う典型的なグラフィカルユーザインタフェースを例示している。 信用証明ユーザインタフェースを使用して信用証明を収集するための典型的なプロセスを例示している。 パスワードの信用証明の提出を扱う典型的なグラフィカルユーザインタフェースを例示している。

Claims (20)

1. 計算機可読命令を有する１つ以上の計算機可読媒体であって、計算機器によって実行されるときに前記計算機器に実行させる動作が、
   複数の信用証明プロバイダから複数の信用証明のための複数の信用証明情報セットを受信することと、
   ユーザを認証するためのリクエストを受信することと、及び
   前記信用証明の中の１つに対する認証メッセージの提出を可能にすること、とからなり、前記認証メッセージが前記ユーザを認証可能であることを特徴とする媒体。
2. 前記複数の信用証明の中の少なくとも１つが生体タイプの信用証明からなる請求項１記載の媒体。
3. 前記リクエストを受信する前記動作が、前記計算機器のオペレーティングシステムから前記リクエストを受信することからなり、前記オペレーティングシステムのリクエストが、前記ユーザを前記オペレーティングシステムへログオンさせるか否かを判定するために作成されることを特徴とする請求項１記載の媒体。
4. 前記ユーザが前記計算機器のオペレーティングシステムへログオンされ、そして前記リクエストを受信する前記動作が、制御アクセスソフトウェアから前記リクエストを受信することからなり、前記制御アクセスソフトウェアのリクエストが現在禁止されているタスクを許可するか否かを判定するために生成されることを特徴とする請求項１記載の媒体。
5. 前記提出を可能にする動作が、前記複数の信用証明情報セット用に調整されたグラフィカルユーザインタフェースを提示することからなる請求項１記載の媒体。
6. さらに前記ユーザから前記信用証明の中の１つに対する前記認証メッセージの提出を受信することと、及び前記信用証明を使用して前記ユーザを認証することが可能な実体へ前記信用証明を提供すること、とを含むことを特徴とする請求項１記載の媒体。
7. さらに前記信用証明を選択可能にすることを含む請求項１記載の媒体。
8. 前記リクエストを受信する前記動作が、複数の信用証明情報セットの受信の前記動作より前に実行されることを特徴とする請求項１記載の媒体。
9. 計算機可読命令を有する１つ以上の計算機可読媒体であって、計算機器によって実行されるときに前記計算機器に実行させる動作が、
   ２つ以上の信用証明に関連付けられた情報セットを収集することからなり、前記各信用証明がユーザを認証可能であって、
   グラフィカルユーザインタフェースを前記２つ以上の信用証明に関連付けられた前記情報セット用に調整することと、及び
   前記グラフィカルユーザインタフェースを提示すること、とからなり、前記グラフィカルユーザインタフェースが前記２つの信用証明の中の少なくとも１つを選択可能なことを特徴とする媒体。
10. 情報セットを収集する前記動作が、信用証明プロバイダから情報セットをリクエストすることと、及び特定の形式を有していること、とからなる請求項９記載の媒体。
11. 情報セットを収集する前記動作が２つ以上の信用証明プロバイダから情報セットを受信することからなる請求項９記載の媒体。
12. 情報セットを収集する前記動作が前記信用証明の１つに関連付けられた情報セットを収集することからなり、前記信用証明に対する認証メッセージの提出が可能なことを示す前記情報セットがデータ入力のフィールド及びテキストの指示を要求することを特徴とする請求項９記載の媒体。
13. 前記情報セット用に前記グラフィカルユーザインタフェースを調整する前記動作が、前記データ入力のフィールド及び前記テキストの指示を追加することからなる請求項９記載の媒体。
14. 前記グラフィカルユーザインタフェースを調整する前記動作が、ローカライズ、キーボードアクセシビリティ、及びスクロール指示からなる前記情報セットなしで実行されることを特徴とする請求項９記載の媒体。
15. 前記信用証明の中の１つが２以上の認証メッセージを必要とし、及びさらに前記認証メッセージの提出を可能にすることと、前記認証メッセージの提出を受信することと、及び前記信用証明を効率的に認証可能にする認証メッセージを必要とする前記信用証明と共に、前記提出された認証メッセージをパッケージ化すること、とからなる請求項９記載の媒体。
16. 前記グラフィカルユーザインタフェースを調整する前記動作より前に、さらにユーザを認証するためのリクエストを受信することからなり、前記リクエストが前記計算機器のオペレーティングシステムから受信されることを特徴とする請求項９記載の媒体。
17. 前記信用証明の中からの１つの選択の受信に応答して、さらに前記選択された信用証明に対する認証メッセージの提出を可能にするために前記グラフィカルユーザインタフェースを変更することからなる請求項９記載の媒体。
18. 計算機可読命令を有する１つ以上の計算機可読媒体であって、計算機器によって実行されるときに前記計算機器に実行させる動作が、
    信用証明プロバイダの第１のセットからの第１の情報セットの受信に応答して、ユーザを認証するのに利用され、第１の信用証明セットを表示し前記第１の情報セットを基本とする、第１のグラフィカルユーザインタフェースを提示することと、
    信用証明プロバイダの第２のセットからの第２の情報セットの受信に応答して、前記ユーザを認証するのに利用され、第２の信用証明セットを表示し前記第２の情報セットを基本とする、第２のグラフィカルユーザインタフェースを提示することと、からなり、
    前記第１の情報セット及び前記第２の情報セットが異なる場合、前記第１のグラフィカルユーザインタフェース及び前記第２のグラフィカルユーザインタフェースもまた異なることを特徴とする媒体。
19. 前記第１のグラフィカルユーザインタフェース及び前記第２のグラフィカルユーザインタフェースの双方共に前記ユーザが認証メッセージを提出できるようにする能力があることを特徴する請求項１８記載の媒体。
20. さらに前記ユーザによって提出された認証メッセージに関連付けられた信用証明を、当該信用証明の認証が可能な実体へ提出することからなり、前記信用証明が提出された前記認証メッセージを含み、前記実体が前記信用証明を認証する場合前記ユーザがオペレーティングシステムにログオンすることを許可するために効率的な調整をする前記動作と、からなる請求項１９記載の媒体。

Images