ユーザ認証を実行する際に使用する装置、方法、およびシステム
【課題】 動的なユーザ認証を可能にする認証機構を提供する。
【解決手段】 この動的なユーザ認証は共用コンテキストを用いて複数の検査オブジェクトを組み合わせるとともに、変動するユーザの選好および取引／用途の要件に適合するように対話（相互作用）の構成をカスタマイズ可能にするものである。このような機構によれば、高度の柔軟性、正確性、利便性、および頑強性が得られる。本発明の説明目的の一側面では、ユーザ認証用の自動化された手法は次に示すステップ群／オペレーション群を備えている。まず、ユーザの入力を取得する。このユーザの入力の少なくとも一部分は少なくとも２つの検査オブジェクトに関連付けられている。次いで、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査する。本発明のユーザ認証手法は少なくとも１つの検査サーバに接続された少なくとも１つのクライアント装置を備えた柔軟かつ分散型のアーキテクチャにおいて実現するのが望ましい。前記クライアント装置と前記検査サーバは本発明のユーザ認証手法を協働して実行する。
【解決手段】 この動的なユーザ認証は共用コンテキストを用いて複数の検査オブジェクトを組み合わせるとともに、変動するユーザの選好および取引／用途の要件に適合するように対話（相互作用）の構成をカスタマイズ可能にするものである。このような機構によれば、高度の柔軟性、正確性、利便性、および頑強性が得られる。本発明の説明目的の一側面では、ユーザ認証用の自動化された手法は次に示すステップ群／オペレーション群を備えている。まず、ユーザの入力を取得する。このユーザの入力の少なくとも一部分は少なくとも２つの検査オブジェクトに関連付けられている。次いで、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査する。本発明のユーザ認証手法は少なくとも１つの検査サーバに接続された少なくとも１つのクライアント装置を備えた柔軟かつ分散型のアーキテクチャにおいて実現するのが望ましい。前記クライアント装置と前記検査サーバは本発明のユーザ認証手法を協働して実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は認証手法に関し、特にカスタマイズ可能であるとともに状況に応じて使い分ける（context-dependent)、複数の検査オブジェクト（verification object)との相互作用を用いた動的ユーザ認証方式を提供する。
【背景技術】
【０００２】
物理的アクセスおよび論理的アクセスの双方の場合において、ユーザのアイデンティティ（ＩＤ）確認請求を認証することは、システムのセキュリティ、ネットワークのセキュリティ、サービスのセキュリティ、および施設のセキュリティを保証する際における重要なステップである。既存のユーザ認証方式は、単一の検査オブジェクト（たとえばパスワードや個人識別番号（personal identification number: ＰＩＮ）など）をユーザが知っていることに基づいて行う場合が多い。既存のユーザ認証方式では、単一の検査オブジェクト（たとえばキーやカードなど）を所持していることに基づいて行うこともある。既存の他の認証手法としては、生体統計学上の（biometric)特徴（たとえば指紋、声紋、虹彩〔こうさい〕走査情報、または顔走査情報）の１つを検査オブジェクトとして使用するものがある。
【０００３】
検査は通常、アクセスを試みる時点においてユーザから取得した検査オブジェクトと事前に格納しておいたオブジェクトとを比較することにより行う。したがって、指紋の場合、アクセスを試みる時点においてユーザから取得した指紋が（おそらく事前に当該ユーザから取得し）事前に格納しておいた指紋と一致するなら、アクセスを許可する。一致しないなら、アクセスを拒否する。
【０００４】
しかし、これら既存の認証手法には多くの難点がある。たとえば、キーまたはパスワードは盗まれる可能性があるし、生体統計学上の特徴はたとえば偽の指紋を使用されると破綻（はたん）する可能性がある。
【０００５】
より最近の手法では、複数の生体統計学的認識手法（たとえば顔認識と声紋認識など）を使用することを試みている。しかし、このような手法は生体統計学上の特徴の各々を順次かつ個別に取得して解析した後、最終出力を所定の静的な態様で組み合わせるだけであるから、生体情報群間の相互作用をなんら利用していない。
【０００６】
また、既存の認証手法には様々なユーザに特有の制約または要件、様々な取引に特有の制約または要件、あるいは、様々な用途に特有の制約または要件を取り扱うのに十分な柔軟性がない。たとえば、ユーザに特有の制約には、指を欠損したユーザは指紋認識システムを使用できない、というものがある。取引に特有の制約には、１００万ドルの取引は１０ドルの取引に比してより高度の認証が必要になるはずだ、というものがある。用途に特有の制約には、銀行取引なる用途を基準にしたセキュリティ上の質問は旅行なる用途には適していない、というものがある。既存の認証手法はこのような種類の制約または要件を取り扱うのに十分な柔軟性がまったくない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、セキュリティと認証に対する関心が高まりつつあるとともに、既存の認証システムに欠陥があることから、高度の柔軟性、高度の正確性、高度の利便性、および／または、高度の頑強性を実現しうる認証機構（authentication framework) が明確に求められている。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）
【課題を解決するための手段】
【０００８】
本発明は柔軟性、正確性、利便性、および頑強性を既存の認証機構に比して高めうる改良された認証機構を提供する。これは、たとえば動的なユーザ認証を可能にすることによって達成される。この動的なユーザ認証は共用コンテキストを用いて複数の検査オブジェクトを組み合わせるとともに、変動するユーザの選好および取引／用途の要件に適合するように対話（相互作用）の構成をカスタマイズ可能にするものである。このような機構によれば、高度の柔軟性、正確性、利便性、および頑強性が得られるので好都合である。
【０００９】
本発明の一側面において、ユーザ認証用の自動化された手法は次に示すステップ群／オペレーション群を備えている。まず、ユーザの入力を取得する。前記ユーザの入力の少なくとも一部分は少なくとも２つの検査オブジェクトに関連付けられている。次いで、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査する。
【００１０】
前記ユーザを検査するステップ／オペレーションは前記少なくとも２つの検査オブジェクトに個別に対応する少なくとも２つの検査エンジンによって実行するのが望ましい。前記少なくとも２つの検査エンジンは前記少なくとも２つの検査オブジェクトと少なくとも１つのユーザ・モデルとを個別に比較する。前記ユーザ・モデルはユーザを登録するセッションに合わせて取得するデータに基づいて事前に作成しておく。
【００１１】
また、前記少なくとも２つの検査オブジェクトにわたって共用されている前記コンテキストは前記ユーザを検査するステップ／オペレーションに付随する少なくとも１つの変数を備えている。たとえば、前記コンテキスト変数は、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数
のうちの少なくとも１つのものを表している。さらに、前記少なくとも２つの検査オブジェクトは、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している。
【００１２】
本発明の別の側面では、ユーザを認証する手法は次に示す点でカスタマイズ可能である。すなわち、前記手法が検査ポリシー、検査オブジェクトの型、ユーザ・モデル、および／または、前記コンテキストに付随する変数を、付加する、変更する、および／または、削除するステップ群／オペレーション群を備えている点においてである。これらのタスクは管理セッションにおいて実行する。
【００１３】
本発明のさらに別の側面では、ユーザ認証手法を少なくとも１つの検査サーバに接続された少なくとも１つのクライアント装置を備えた柔軟かつ分散型のアーキテクチャにおいて実現する。前記クライアント装置と前記検査サーバはここで説明した本発明に係るユーザ認証手法を協働して実行する。
【００１４】
前記クライアント装置と前記検査サーバとの間の通信インタフェースはＸＭＬ（Extensible Markup Language) によって実装する。前記クライアント装置と前記検査サーバとの間のそのような通信インタフェースは検査セッション、登録セッション、および／または管理セッションをサポートしている。
【００１５】
本発明のさらなる側面では、ユーザ認証手法は少なくとも１つの検査ポリシーの使用と、前記少なくとも１つの検査ポリシーに従ってユーザを検査するオペレーションを実行する検査手段とを備えている。前記少なくとも１つの検査ポリシーは前記検査手段によってステート・マシン（状態遷移機械）として実装可能である。理解すべき点を挙げると、ここで参照している検査手段は多数のインプリメンテーション（たとえばハードウェア、ソフトウェア、および／またはそれらの組み合わせで実装しうる検査モジュール）において実現することができる。
【００１６】
本発明のさらに別の側面では、ユーザ認証手法は少なくとも１つの検査オブジェクトの使用と、前記少なくとも１つの検査オブジェクトによってユーザを検査するオペレーションを実行する検査手段とを備えている。前記少なくとも１つの検査オブジェクトは、
（ｉ）関連する検査エンジンを使用しない検査に使用しうる状態、
（ｉｉ）前記少なくとも１つの検査オブジェクトに関するデータを用いて事前に登録する必要がない状態、
（ｉｉｉ）動的である状態、
（ｉｖ）暗黙である状態、
（ｖ）別のオブジェクトから少なくとも１つのプロパティを継承しうる状態、
（ｖｉ）複数の入力を特徴としている状態、
（ｖｉｉ）重み付けられている状態、および、
（ｖｉｉｉ）操作可能である状態、
のうちの少なくとも１つの状態にある。暗黙は、前記オブジェクトがユーザの入力（たとえば発信者電話番号に基づくオブジェクトなど）を必要としない、ということを意味しているのが望ましい。継承は、１つのオブジェクトが別のオブジェクトからプロパティを継承しうる（たとえば、あるオブジェクトが色を呼び出された場合、親オブジェクト〔色〕からプロパティを継承している車の色を呼び出して新たなオブジェクトを生成することができる）、ということを意味しているのが望ましい。
【００１７】
本発明のさらに別の側面では、ユーザ認証手法は少なくとも１つのユーザ・モデルの使用と、前記少なくとも１つのユーザ・モデルに従ってユーザを検査するオペレーションを実行する検査手段とを備えている。前記少なくとも１つのユーザ・モデルは、
（ｉ）ユーザの少なくとも１つの選好を表している状態、および、
（ｉｉ）引き続くユーザの検査で使用するために変更しうる状態
のうちの１つの状態にある。
【００１８】
本発明のこれらの目的および他の目的、特徴、ならびに利点は以下に示すそれらの説明を目的とする、添付図面とともに読むべき実施形態の詳細な説明から明らかになる。
【発明を実施するための最良の形態】
【００１９】
以下の記述においては、典型的なクライアント−サーバ型のシステム・アーキテクチャを用いて本発明を説明する。しかし、理解すべき点を挙げると、本発明は特定のシステム・アーキテクチャを備えた用途に限定されない。それどころか、本発明は一般に、高度の柔軟性、高度の正確性、高度の利便性、および／または、高度の頑強性を実現しうる認証機構を備えることが望まれるすべてのシステム・アーキテクチャに適用することができる。すなわち、本発明の手法は単一のコンピュータ・システムにおいて、または、適切なネットワークで接続された複数のコンピュータ・システムにおいて実現することができる。これらの実例は後述する。
【００２０】
ここで例を用いて詳細に説明するように、本発明は多くの検査オブジェクトを含み、きわめて多岐にわたる、ユーザに特有の制約、取引に特有の制約、用途に特有の制約、および、他の関連する要件を取り扱いうるように認証プロセスを完全にカスタマイズすることを可能にする新たなプログラミング・モデルを提供するものである。
【００２１】
また、本発明によれは、ユーザとシステムとの間の相互作用の変化にリアルタイムで応答して変更しうる動的ユーザ認証プロセスを実現することが可能になる。このようにアーキテクチャがきわめて柔軟であるから、新たな検査オブジェクトと検査ポリシーをいつでも付加することが可能になる。さらに、共通のコンテキストと関連するデータ構造とを備えているから、認証相互作用全体がこの共用のコンテキストに基づいて動作することが可能になる。
【００２２】
一実施形態では、相互作用の構成はＸＭＬ（eXtensible Markup Language）を用いて統計型ステート・マシン（状態遷移機械）として実装した認証ポリシーに基づいている。また、関連する認証オブジェクト（たとえば尋ねるべき質問、実行すべきアクション、など）を指定している１つのファイルと、ユーザ・プロファイル（たとえばユーザが選択した認証オブジェクトと正しい応答、ユーザの選好、など）を含むファイル群とが存在する。この両者もＸＭＬを用いて実装する。
【００２３】
認証相互作用全体は（ユーザの選好、および取引上の要件または用途上の要件に基づいて選択した）現に効力を有する認証ポリシー基づいて動的に決める。その際、共用コンテキストに基づいたオペレーションを使用し、さらに現に効力を有する認証オブジェクトおよび当該ユーザのプロファイルも利用する。
【００２４】
このような方法によって、既存の認証システムに比して顕著に改良された認証機能が実現するとともに、きわめて高度な正確性、柔軟性、利便性、および頑健性が保証されるようになる。
【００２５】
また、以下において実例を用いて詳細に説明するように、本発明の認証手法は次に示すコンポーネントを利用している。すなわち、（１）検査オブジェクトおよび検査エンジン、（２）検査ポリシーおよび検査ポリシー・マネージャ、ならびに（３）ユーザ・モデルである。
【００２６】
検査オブジェクトとは次に示すような、ユーザのアイデンティティ（ＩＤ）を検査する目的で使用することのできるオブジェクト（対象）のことである。すなわち、ユーザの生体統計学上の特徴（たとえば声紋、指紋、顔走査情報、虹彩走査情報、手書き署名、キーボードの運動力学的情報（keyboard dynamics)など）、ユーザの知識（たとえばパスワード、パスフレーズ（passphrase）、個人的な質問に対する回答など）、およびユーザの所有物（たとえばキー（鍵）、カード、トークン、資格証明書、発信者電話番号（caller-id)情報を送信する携帯電話機または家庭用電話機（home telephone) 、クライアント・ソフトウェアを備えたパーソナル・コンピュータまたはハンドヘルド型コンピュータ、ユーザの居場所など）などである。理解すべき点を挙げると、上掲したオブジェクトの例のリストはこれで尽きることを意図していない、また、本発明を特定のオブジェクトに限定する意図はない。
【００２７】
検査オブジェクトとユーザ・モデル中に格納されている表記とを照合するために検査エンジンを使用する。検査エンジンの例として、次に示すものが挙げられる。すなわち、ユーザの指紋を照合する指紋認識システム、質問に対する口頭による回答を評価する会話システム（たとえば音声応答システムなど）、ユーザの口頭の発声を抽出して認識する会話システム（たとえば〔自然な理解手法を含む〕音声認識システムまたは声紋認識システム）（この会話システムには合成した質問と催促を生成する音声合成システムも含まれる）、ユーザの電話番号を抽出して照合する発信者電話番号認識システム、ユーザのバッジまたはカードを走査するバッジ読み取り装置、ユーザのＰＩＮを確認するＰＩＮ確認システム、ユーザの顔走査情報を抽出して照合する顔認識システム、ユーザの虹彩走査情報を抽出して照合する虹彩認識システム、ユーザの手書き情報を認識する手書き認識システム、ユーザのキーボードの運動力学的情報を照合するキーボード運動力学認識装置、ならびに、ここで検討した、および／または別の状況において既知でありうる他の属性に特有の（modality-specific)エンジンである。理解すべき点を挙げると、これらの種類のエンジンは周知であるから、このようなエンジンの詳細なさらなる説明は不必要であるので、ここには提示しない。再度理解すべき点を挙げると、上掲したエンジンの例のリストはこれで尽きることを意図していない、また、本発明を特定のエンジンに限定する意図はない。
【００２８】
検査エンジンは通常、ユーザの入力とユーザが登録したときに生成したユーザのモデルとを比較することによりユーザの検査を行うが、本発明はユーザの登録を必要とする検査エンジンに限定されない。ユーザが登録することを必要としない非監視型の検査エンジンを使用してもよい。非監視型の検査エンジンを使用する場合、当該検査エンジンが比較するユーザ属性群を備えた単一のユーザ・モデルを使用する。たとえば、次に示す検査エンジンを使用することができる。すなわち、音調（acoustic accent)の認識、言語の特定、および顔の特徴の検出（たとえば目の色や眼鏡の検出など）などである。この場合、個々の検査エンジンはユーザの登録を必要としないから、単一のユーザ・モデルを用いて、ユーザが話す会話のアクセント、言語、目の色、および、ユーザが眼鏡を着用しているか否かを明確に識別することが可能になる。
【００２９】
したがって、本発明は次に示す点を認識することに基づいている。すなわち、個々の検査エンジンを用いても、事前に定義した静的な態様で処理する単純な検査ステップ群を実行することはできるけれども、より高度の正確性と柔軟性を達成するために複数の検査オブジェクトを用いて動的なユーザ認証を行う場合にはより一般的な機構が必要になる。本発明はそのような改良された認証機構を提供するものである。
【００３０】
この目標および他の目標を達成するために、本発明では検査ポリシーなる概念を導入する。検査ポリシーは、ユーザと認証システムを含むシステム全体との間の相互作用、および様々な検査エンジン群間の相互作用を規整するものである。リアルタイムで変更しうるようにすることに対する需要を含むきわめて多様な需要、すなわちユーザに特有の認証に対する需要、取引に特有の認証に対する需要、または用途に特有の認証に対する需要を満たすこめに、任意個数の検査ポリシー群を作成することができる。
【００３１】
後述するように、このような検査ポリシーは検査ポリシー・マネージャが管理する。検査ポリシー・マネージャはすべての検査オブジェクトにわたって共用される共通のコンテキストに基づくオペレーションを用いることにより、認証システムのプログラム可能性を最大限に達成している。
【００３２】
本発明の一実施形態では、上記検査ポリシーを、少なくとも１つの検査オブジェクトを処理する有限ステート・マシン（有限状態機械）としてを実装している。初期状態から開始し、様々な検査オブジェクトを処理する時に他の状態への遷移が起こり、そして、ユーザを受容または拒絶する終端状態を備えている。ある場合には、ユーザの受容を許可する複数の状態を備えている。その場合、この複数の状態の各々は処理中のトランザクションのセキュリティに対する需要が異なることに対応するために、各状態はそれ自身に固有のセキュリティ・レベル（たとえば低セキュリティ、中セキュリティ、高セキュリティなど）を備えている。検査ポリシー・マネージャを設けると、新たな検査オブジェクトをいつでも付加しうるようになる。それには、検査オブジェクトのリポジトリに新たな検査オブジェクトへの指示部を備えるようにする。以後、検査ポリシーが行う当該新たな検査オブジェクトに対する呼び出しを利用することが可能になる。
【００３３】
ユーザ・モデルは通常、ユーザがシステムに登録するときに生成するが、その際、当該ユーザが提供した入力（たとえば声の標本、指紋の標本、個人的な質問に対する回答など）、または他の手段を用いて取得した入力（たとえば過去の取引の詳細、最近の請求書の差引残高、発行済みのキーまたはバッジの通し番号、スマートカードまたはクライアント・ソフトウェアに含まれている暗号化キーなど）を使用する。
【００３４】
ユーザ・モデルは必要なとき（たとえば新たな請求書が発行され差引残高が変更されたとき、または、より多くの声の標本が利用可能になったとき、など）にはリアルタイムで更新する。個々のユーザ・モデルは当該ユーザに関係するすべての検査オブジェクト（たとえば検査オブジェクトに関するユーザの選好〔たとえばあるユーザは数字に関する質問よりも色に関する質問を好む〕など）に関する情報を含んでいる。ユーザ・モデルは検査オブジェクトの重要な処理（たとえばユーザに当該ユーザの社会保障番号の第１桁と第３桁を付加するか否かを質問すること、など）もサポートしているのが望ましい。この場合にも、上述したいかなる例も本発明を限定することを意図していない。
【００３５】
以上、本発明の原理と特徴の一部を一般的に説明したから、以下ではこれらの原理と特徴を説明する実施形態を図面を用いて提示する。
【００３６】
まず、図を参照する。図１は本発明の一実施形態に従い複数の検査オブジェクトを用いてカスタマイズ可能な検査機構を実現している認証システムのクライアント−サーバ・アーキテクチャを示すブロック図である。図示するように、認証システム１００はネットワーク・アダプタ１０６を介して接続された検査クライアント装置１０２と検査サーバ１０４とを備えている。検査クライアント１０２それに付随するコンテキスト１０８とアプリケーション１１０とを備えている。検査サーバ１０４は検査ポリシー・マネージャ１１２と複数の検査エンジン（１１４−１）〜（１１４−Ｎ）（ただし、Ｎは［２、３、４、・・・］のうちの任意の整数であり、本発明の特定の実現例がサポートしうる検査オブジェクトのファミリすなわち種別の個数を表している）とを備えている。認証システム１００はさらにデータ・マネージャ１１６、検査オブジェクト・ストア１１８、検査ポリシー・ストア１２０、およびユーザ・モデル・ストア１２２も備えている。データ・マネージャ１１６と検査オブジェクトストア１１８は検査サーバを表すボックスの外部に示されているが、それらは検査サーバ上に実装してもよいということを理解すべきである。
【００３７】
検査クライアント装置１０２はユーザにインタフェースを提供して当該ユーザから入力を収集すること、ネットワーク・アダプタ１０６を介して検査サーバ１０４と通信すること、および、アプリケーション１１０と通信することを担当する。本発明の一実施形態では、検査クライアント装置１０２はコンテキスト１０８を取得してそれを保持することも担当する。
【００３８】
別の実施形態では、コンテキスト１０８はシステム１００の他のコンテキストがアクセスしうる中央データベース（図示せず）に格納する。そのような実現例によれば、検査クライアント装置１０２と検査サーバ１０４との間において状態非保持オペレーション（stateless operation)を実現することが可能になる。その結果、検査プロセス中の様々な局面に対して様々なサーバを使用しうるようになるから、検査プロセスの最中にある特定のサーバから保護することが可能になるとともに、サーバのリソースの負荷均衡を改善することも可能になる。
【００３９】
コンテキスト１０８には関連する、たとえば次に示すような変数をすべて記録して検査プロセスの用に供している。すなわち、（１）ユーザの名前、（２）現に効力を有する検査ポリシーの現在の状態、（３）呼び出した検査オブジェクトに付随する履歴、およびその呼び出しに付随するスコア（score)と結果、（４）取引に特有の要件（たとえば必要な正確性のレベル、取引の性質など）、（５）ユーザに特有の要件（たとえば風邪を引いているユーザは声紋の一致を信頼したがらない、など）、および（６）他の物理的変数および論理的変数（たとえばネットワーク接続の種別〔リモート（遠隔）かローカルか〕、音声チャネルの品質、など）である。
【００４０】
コンテキスト１０８には外部の検査源（図示せず）が出す検査スコアを表す他の変数も記録する。たとえば、銀行内にいる顧客は入り口で自分の銀行カードを機械にスッと通した（swipe)後に銀行に入ったのであるが、その情報はコンテキスト１０８に外部のスコアとして格納することが可能性であり、引き続くカウンタまたはＡＴＭ（automated teller machine: 現金自動預け払い機）における認証プロセスで使用することが可能性である。
【００４１】
コンテキスト１０８に始めに格納する変数は検査オブジェクトと初期作成（initial build)時に既知の他の要件とに関連する、システムのデフォルトの変数である。しかし、システム１００に追加の検査オブジェクトを付加するとき、または、新たな要件が発見されたときには、コンテキスト１０８にユーザが定義した
変数を付加する。
【００４２】
ネットワーク・アダプタ１０６はクライアント装置１０２と検査サーバ１０４との間の通信を可能にするものである。ネットワーク・アダプタ１０６はネットワーク・トランスポート・プロトコル（たとえば標準のＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol)やＳＳＬ（Secure Sockets Layer) プロトコルなど）を実装している。理解すべき点を挙げると、認証システム１００を単一のコンピュータ・システムに実装する実施形態では、ネットワーク・アダプタは必要ない。
【００４３】
図示するように、検査サーバ１０４は検査ポリシー・マネージャ１１２と１組の検査エンジン（１１４−１）〜（１１４−Ｎ）とを備えている。各検査エンジンは１つの所定の検査オブジェクトまたは１つのファミリ（種別）の検査オブジェクト群を処理する。たとえば、指紋検査エンジンは特定の指紋または様々な種類の指紋群（たとえば親指の指紋、人指し指の指紋、など）を処理する。同様に、知識検査エンジンは様々な種類の要求−応答型の質問（challenge-response question)を処理する。
【００４４】
アーキテクチャが柔軟であるから、新たな検査エンジンと新たな検査オブジェクトとを容易に付加することが可能になる。付加する検査エンジンは新たな種別のものでもあっても既存の種別のものであってもよい。たとえば、付加する前は声紋認識エンジンと指紋認識エンジンとを備えていた検査サーバに顔認識エンジンを付加することができるし、あるいは、第２の声紋認識エンジン（これは、たとえば異なる製造業者製のものでもよい）を付加することもできる。同様に、新たな検査エンジンに新たな検査オブジェクトを付加してもよいし、あるいは、既存の検査エンジンに新たな検査オブジェクトを付加してもよい（たとえば既存の知識検査エンジンに新たな質問を付加すること、など）。
【００４５】
検査ポリシー・マネージャ１１２は所定のユーザ用の検査ポリシーを解釈するとともに、認証プロセス全体を統御する。ポリシー・マネージャ１１２は検査クライアント装置１０２から現在のコンテキスト１０８を受領し、当該コンテキストを処理し、現在の検査オブジェクトの更新済みの状態を取り込み、そして、更新済みのコンテキストを、検査プロセスの間にとるべき次のステップの指示とともに検査クライアント装置１０２に返す。
【００４６】
本発明の一実施形態では、検査ポリシー・マネージャ１１２は有限ステート・マシン中にある状態群を呼び出し、当該ステート・マシンの条件群を解釈し、そして次の状態に分岐する任に当たる。検査ポリシー・マネージャ１１２は認証プロセスのために最終的な受容判定または拒絶判定を行う実体（entity: エンティティ）である。現在のトランザクションが中間判定を必要とするなら、検査ポリシー・マネージャ１１２がそのような判定を行うこともありうる（ただし、現に効力を有する検査ポリシーがそれを許可している場合に限る）。
【００４７】
データ・マネージャ１１６なるコンポーネントは外部の記憶リソース群を制御するが、それらには検査オブジェクト・ストア１１８、検査ポリシー・ストア１２０、ユーザ・モデル・ストア１２２が含まれる。これらのリソースには検査サーバ１０４が（検査ポリシー・マネージャ１１２または個別の検査エンジン〔１１４−１〕〜〔１１４−Ｎ〕を用いて）直接にアクセスする。別の実施形態では、このようなリソースには検査クライアント装置１０２がアクセスするとともに、それらはネットワーク・アダプタ１０６を介して検査サーバ１０４に供給される。
【００４８】
アプリケーション１１０はアクセスを許可する前にユーザの認証を必要とするアプリケーションである。アプリケーションの例としては銀行取引アプリケーション、旅行アプリケーション、および電子メール・アプリケーションなどが挙げられる。アプリケーション１１０はアプリケーションに特有の情報と要件、およびトランザクションに特有の情報と要件を提供する任に当たる。理解すべき点を挙げると、本発明は特定のアプリケーションに限定されない。
【００４９】
本発明の一実施形態では、検査クライアント装置１０２はＸＭＬで記述したメッセージ・インタフェースを用いて検査サーバ１０４と通信する。上記インタフェースがサポートする機能の例には次に示すオペレーションが含まれる。
通信チャネルを開く；
検査セッションまたは登録セッションを閉じる；
ユーザの登録を開始し、ユーザ・モデルを作成する；
ユーザの登録を終了し、登録セッションを閉じる；
検査オブジェクトのスコア付け（scoring)を開始する；
検査オブジェクトのスコア付けを終了する。；
検査セッションを開始する；
検査セッションを継続してポリシー中の次の状態を決める、あるいは判定を出力する；
新たな検査オブジェクトを付加する；
新たな検査ポリシーを付加する；
検査ポリシーを削除する；
コンテキストを削除する；
検査オブジェクトを更新して既存の検査オブジェクトを変更する；
ユーザ・モデルを更新して既存のユーザ・モデルを変更する；
検査ポリシーを更新して既存の検査ポリシーを変更する；
ユーザ・モデルに照会してユーザ・モデル中の情報を取得する；
検査オブジェクトに照会して検査オブジェクト中の情報を取得する；
検査ポリシーに照会して検査ポリシー中の情報を取得する；
アクティブな検査オブジェクトから成るリストを取得する；
コンテキスト変数を付加する；
コンテキスト変数に現在の値をセットする；
コンテキスト変数用に現在の値を取得する；
すべてのコンテキスト変数から成るリストとそれらの現在値とを取得する；
【００５０】
理解すべき点を挙げると、上掲したオペレーションのリストはこれで尽きているということを意図しておらず、また本発明をこれら特定のオペレーション例に限定する意図はない。
【００５１】
さらに理解すべき点を挙げると、別の実施形態では、検査サーバに付随するコンポーネント群自体がネットワーク・アダプタ１０６を介して相互に通信する。したがって、たとえば、少なくとも１つの検査エンジン１１４が、ネットワーク・アダプタ１０６を介して検査ポリシー・マネージャ１１２と通信する。また、検査ポリシー・マネージャ１１２とデータ・マネージャ１１６とについても同様の分散型の構成が存在するし、データ・マネージャ１１６とデータ・ストア１１８、１２０、１２２とについても同様の分散型の構成が存在する。したがって、次に示す点を理解すべきである。すなわち、図１に示すコンポーネント群の相互接続は説明を意図するものであるから、他の適切な相互接続を用いて本発明の認証機能を実現することができる。
【００５２】
次に、図２を参照する。図２は本発明の一実施形態に従い複数の検査オブジェクトを用いてカスタマイズ可能な検査機構を実現する典型的なコンピューティング・システム環境を示すブロック図である。一例として、コンピューティング・システム２００はユーザが（模式的に「クライアント」またはクライアント装置と呼ばれる）コンピュータ・システム２０２を用いて（模式的に「サーバ」と呼ばれる）別のコンピュータ・システム２０４とネットワーク２０６を介して通信する分散コンピューティング・システムの少なくとも一部分を示すものである。このネットワークとしては、その両端でコンピュータ・システム群が通信しうる適切な任意のネットワーク（たとえばインターネットすなわちワールド・ワイド・ウェブ（World Wide Web）、ＬＡＮ（local area network）など）を使用することができる。しかし、本発明は特定の種別のネットワークに限定されない。事実、コンピュータ・システム群はネットワークなしに直接にリンクしうる、という点を理解すべきである。
【００５３】
また、説明を簡易にするために、図２には２つのコンピュータ・システムしか示されていないけれども、ネットワークは複数のクライアント装置と複数のサーバとをリンクすることができる。しかし、本発明の手法は単一のコンピュータ・システムに実装することができる、という点も認識すべきである。その場合、たとえばユーザが、認証オペレーションを実行しているコンピュータ・システムと直接に対話（相互作用）する。
【００５４】
図１を参照して次に示す点を理解すべきである。すなわち、クライアント装置１０２はコンピュータ・システム２０２を用いて実現することができる。そして、検査サーバ１０４（およびそのコンポーネント群）、データ・マネージャ１１６、ならびに個別のオブジェクト・ストア、ポリシー・ストア、およびユーザ・モデル・ストア（１１８、１２０、１２２）はコンピュータ・システム２０４を用いて実現することができる。したがって、ネットワーク・アダプタ１０６はネットワーク２０６によって実現することができる。
【００５５】
したがって、図２はネットワークを介して通信する各コンピュータ・システム用の典型的なアーキテクチャを一般的に示している、という点を理解すべきである。図示するように、コンピュータ・システム２０２はプロセッサ（２０８−Ａ）、メモリ（２１０−Ａ）、およびＩ／Ｏ装置（２１２−Ａ）を備えている。そして、これらはすべてコンピュータ・バス（２１４−Ａ）を介して接続されている。同様に、コンピュータ・システム２０４はプロセッサ（２０８−Ｂ）、メモリ（２１０−Ｂ）、およびＩ／Ｏ装置（２１２−Ｂ）を備えている。そして、これらはすべてコンピュータ・バス（２１４−Ｂ）を介して接続されている。
【００５６】
理解すべき点を挙げると、ここで使用する用語「プロセッサ」はＣＰＵ（central processing unit:中央処理装置）または他の処理回路などの処理装置を少なくとも１つ含むことを意図している。また、ここで使用する用語「メモリ（記憶装置）」はプロセッサまたはＣＰＵに付随するメモリ（たとえばＲＡＭ、ＲＯＭ、固定的かつ永続的な記憶装置〔たとえばハード・ディスク駆動装置など〕、または着脱可能かつ永続的な記憶装置〔たとえばディスケット(R) やＣＤ−ＲＯＭなど〕）を含むことを意図している。さらに、ここで使用する用語「Ｉ／Ｏ装置」は処理装置にデータを入力する入力装置（たとえばキーボードやマウスなど）および処理装置に付随する結果を提示する出力装置（たとえばＣＲＴディスプイ装置など）を含むことを意図している。また、コンピュータ・システム２０２に付随するＩ／Ｏ装置は認証システムがサポートしている検査オブジェクトに付随する特定のデータを収集するのに必要な装置（たとえば声紋認識用の音声データ、および／または発せられた質問に対する回答を捕獲するマイクロフォン、そのような質問をユーザに出力するスピーカ、顔スキャナ（走査器）、虹彩スキャナ、指紋スキャナなど）を含むものと理解される。
【００５７】
さらに理解すべき点を挙げると、図２に示すクライアント・コンピュータ・システムには本発明に係る手法を実現しうるようにプログラムされたコンピュータ・システム（たとえばパーソナル・コンピュータ、ＰＤＡ（personal digital assistant）、携帯電話機など）が含まれる。同様に、図２に示すサーバ・コンピュータ・システムには本発明に係る手法を実現しうるようにプログラムされたコンピュータ・システム（たとえばパーソナル・コンピュータ、マイクロコンピュータ、ミニコンピュータなど）が含まれる。しかし、本発明は特定のコンピュータ・アーキテクチャに限定されない。
【００５８】
したがって、ここで説明する、本発明の手順（methodology)を実行するソフトウェア命令群すなわちコードは関連する記憶装置（たとえばＲＯＭ、固定型記憶装置、着脱可能型記憶装置など）のうちの少なくとも１つに格納しておき、使用しうる状態になったらＲＡＭ中にロードし、ＣＰＵが実行する。
【００５９】
次に、図３を参照する。図３は検査オブジェクトから成るレジストリの一例を示す図である。この特定の実施形態では、レジストリ３００はＸＭＬを用いて表し、検査オブジェクトストア１１８（図１）に格納しておく。
【００６０】
この仕様には登録済みの検査オブジェクトの記述がすべて含まれている。それらは新たな検査オブジェクトを付加するときに更新することができる。この例における第１のオブジェクトはＤＯＢ（Date-of-Birth:誕生日）オブジェクトである。これはＱＡ（Question-Answer:質問−回答）型（type) である。このオブジェクトを処理する任に当たる検査エンジンは知識検査エンジンである。このオブジェクトを呼び出すと必要な応答をユーザに促す提案型プロンプト（suggested prompt) も含まれている。しかし、必要な場合には、検査クライアントはこのプロンプトを変更または置換することができる。「perplexity（難度）」は検査オブジェクトに付随する困難性を表す量であるが、検査ポリシー・マネージャが検査判断を行う際に任意事項として使用する。
【００６１】
この例における第２のオブジェクト３０４は発信者電番号（Caller-ID)である。これは電話接続の場合において、呼（こ）を発した電話の電話番号と関連するユーザ・モデル中の電話番号とを照合しようとするものである。プロンプトが指定されていないのは、この情報がユーザの明示的な入力がまったくなくとも電話のインフラストラクチャから自動的に取得しうるものだからである。
【００６２】
この例における第３のオブジェクト３０６は声紋（Voiceprint）オブジェクトである。この場合、型（type) が指定されていないのは、この声紋認識エンジンが１つの型の検査オブジェクトを処理するものだからである。声紋は盗まれることのない生体統計学上の特徴であるから、この例では難度（perplexity）を高く指定している。
【００６３】
第４のオブジェクト３０８と第５のオブジェクト３１０はこの仕様の階層的な特質を示すものである。すなわち、ＣＡＲ＿ＣＯＬＯＲ（車の色）オブジェクトは親オブジェクトＣＯＬＯＲ（色）からデフォルトのプロパティを継承している。
【００６４】
この例における最後の２つのオブジェクト３１２、３１４は将来の応答が動的に変動する動的検査オブジェクトの例である。この例では、正確な応答はユーザ・モデルではなくアプリケーションから取得する。現在の差引残高（ＣＵＲ＿ＢＡＬＡＮＣＥ）オブジェクト３１２は数値型（ＡＰＰ＿ＮＵＭ）の、用途に特有のオブジェクトである。最終取引日（ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＥ）オブジェクト３１４はストリング（string）型の、用途に特有のオブジェクトである。
【００６５】
次に、図４を参照する。図４はユーザ・モデルの一例を示す図である。この特定の実施形態では、ユーザ・モデル４００はＸＭＬを用いて表し、ユーザ・モデル・ストア１２２（図１）に格納しておく。
【００６６】
ユーザ・モデルにはユーザが登録データを提供する際に目的とした検査オブジェクトの記述が含まれている。第１のオブジェクト４０２は発信者電話番号（Caller-ID)である。この場合、当該ユーザの正しい応答は「914-945-3000」である。このオブジェクトにおける当該ユーザの選好を含めるのは任意事項であるが、使用可能な場合にはより選好度の高いオブジェクトを選択する際に検査ポリシーがそれを使用する。
【００６７】
第２のオブジェクト（ＤＯＢ〔誕生日〕４０４）と第３のオブジェクト（ＣＯＬＯＲ〔色〕４０６）は類似している。第４のオブジェクト（車の色すなわちＣＡＲ＿ＣＯＬＯＲ（４０８））はこの例では２つの応答を有しているが、それはこのユーザが２台の車を所有しており、いずれの応答も正しい回答として受容されるからである。第５のオブジェクト４１０はモデルのパラメータを必要とする声紋オブジェクトである。これは１つのファイルに格納するとともに、ファイル名を含める。最後の２つのオブジェクト（ＣＵＲ＿ＢＡＬＡＮＣＥ〔現在の差引残高〕４１２とＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＥ〔最終取引日〕４１４）は動的検査オブジェクトであるから、正しい応答を含んでいない。したがって、現在の正しい応答はアプリケーションから取得する必要がある。
【００６８】
上述したように、本発明によれば、オブジェクトはすべてリアルタイムで更新または削除することができるし、新たなオブジェクトをリアルタイムで付加することもできる。
【００６９】
次に、図５および図６を参照する。図５および図６は検査ポリシーの一例を示す図である。この特定の実施形態では、検査ポリシー５００を有限ステート・マシンとして実装し、ＸＭＬを用いて表している。対応する有限ステート・マシン図を図７に示す。検査ポリシー５００は検査ポリシー・ストア１２０（図１）に格納するのが望ましい。
【００７０】
検査ポリシー５００は銀行取引なる用途に付随する単純なポリシーを示すものである。より詳細に述べれば、このポリシーは次に示す状況を規整するものである。すなわち、ユーザ（おそらく銀行の顧客）が自分の銀行口座へのアクセス権を取得しようとすると、認証システムが複数の検査オブジェクト（たとえば当該銀行の顧客の電話番号、当該銀行の顧客の誕生日、当該銀行の顧客の車の色、当該銀行の顧客の声紋、など）を用いて当該ユーザのアイデンティティ（ＩＤ）を検査しようとする、という状況である。しかし、上述したように、本発明は特定のポリシーまたは特定の用途に限定されない。次に示す、説明を目的とした記述では検査ポリシー５００の左側に記載した行番号（たとえば第１〜５３行）を参照する。
【００７１】
まず、図５において、コンテキスト変数（たとえば「curBalance（現在の差引残高）」〔第４行〕や「lastTransactionDate （最終取引日）」〔第６行〕など）をデフォルト値で初期化して動的検査オブジェクト（たとえば「ＣＵＲ＿ＢＡＬＡＮＣＥ（現在の差引残高）」や「ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＥ（最終取引日）」など）を処理しうるようにする。これらの変数は引き続いて、アプリケーションが出す入力を用いて更新することになる。次いで、変数「minVoiceprintScore（最小声紋スコア）」（第５行）を用いて、声紋の一致にとって受容しうる最小スコアを指定する。この変数用のデフォルト値は検査ポリシーを用いて指定する。ポリシーが異なると、デフォルト値も異なる（たとえばポリシーがより厳格になると、最小スコアはより大きくなる）。別の実施形態では、このデフォルト値は、（ユーザに特有の要件の根拠をなす）ユーザ・モデル、あるいは、（取引に特有の要件または用途に特有の要件の根拠をなす）アプリケーションから取得した値によって上書きする。
【００７２】
続いて、上記ポリシーに関連する１組の条件を指定する。これは状態遷移を決めるため、または検査オブジェクトを評価するために引き続いて使用することになる。上記条件群を定義するのに使用する式はコンテキスト変数、数値定数、およびストリング・リテラル（ストリング定数）を含んでいる。上記式は次に示すオペレーションを含んでいる。すなわち、論理ＡＮＤ（＆）、論理ＯＲ（｜）、等号（＝）、不等号（！＝）、未満（＜）、以下（＜＝）、超（超える）（＞）、以上（＞＝）、乗算（＊）、除算（／）、加算（＋）、および減算（−）である。
【００７３】
たとえば、条件「ＯＮＥ＿ＯＫ（１つ可）」（第１０行）（これは後刻、状態遷移を決めるのに使用する条件である）が満たされるのは、その時までに呼び出した検査オブジェクトの総数が「１」（＿curObjectNum = 1）であり、かつ、それは一致であった、すなわち、不一致はなかった（＿curWrongNum = 0)場合である。異なる種類の別の例としては条件「ＣＵＲ＿ＢＡＬＡＮＣＥ＿ＴＥＳＴ（現在の差引残高の検査）」（第１５行）が挙げられる。この条件は現在の差引残高（「ＣＵＲ＿ＢＡＬＡＮＣＥ」）検査オブジェクトを評価するのに使用する。この場合、たとえば５パーセントの誤差が許容されているが、それは概略の回答で十分だからである。
【００７４】
上記条件群に従って、１組の状態を定義する。この例には、４つの状態、すなわちＡＣＣＥＰＴ（受容）（第２２行）、ＲＥＪＥＣＴ（拒絶）（第２４行）、ＳＴＡＲＴ（開始）（第２７行）、およびＡＣＣＯＵＮＴ（口座）（第４０行）がある。ＡＣＣＥＰＴ（受容）とＲＥＪＥＣＴ（拒絶）は最終の検査判定を行う終端状態である。ＳＴＡＲＴ（開始）は初期状態であり、検査オブジェクト「ＣＡＬＬＥＲ＿ＩＤ（発信者電話番号）」、「ＤＯＢ（誕生日）」、および「ＣＡＲ＿ＣＯＬＯＲ（車の色）」を含んでいる。デフォルトでは検査オブジェクトを無作為に選択しているが、任意事項として、相対重みを指定してオブジェクトを選択する確率を変更してもよい。ＡＣＣＯＵＮＴ（口座）への遷移が起こるのは最初の２つの条件（ＯＮＥ＿ＯＫ〔１つ可〕またはＴＷＯ＿ＯＫ＿ＯＮＥ＿ＢＡＤ〔２つ可で１つ不可〕）のうちの１つが満たされる場合である。ＲＥＪＥＣＴ（拒絶）への遷移が起こるのは第３の条件（ＴＷＯ＿ＢＡＤ〔２つ不可〕）が満たされる場合である。
【００７５】
ＡＣＣＯＵＮＴ（口座）状態では、重みが指定されていないから、３つのオブジェクトの確率はすべて等しく無作為に選択される。また、これらのオブジェクトには異なる検査を使用する必要がある。それらは事前に定義しておいたリストから選択する。満たされる条件に従って、ＡＣＣＥＰＴ（受容）状態またはＲＥＪＥＣＴ（拒絶）状態への遷移が起こる。対応する最終判定は検査クライアント装置１０２（図１）に送付する。
【００７６】
別の実施形態では、中間状態において中間判定を行ってもよい。たとえば、ＳＴＡＲＴ（開始）状態においてある条件が満たされたら、セキュリティの低い取引用のユーザを受容する判定を行うことができる。そして、取引用のユーザを受容する最終判定はＡＣＣＥＰＴ（受容）状態において行うことができる。
【００７７】
次に、図７を参照する。図７は図５および図６の検査ポリシーの例における状態遷移を示す状態遷移図である。したがって、状態図６００は検査ポリシー５００に付随する４つの状態、すなわちＳＴＡＲＴ（開始）（状態６０２）、ＡＣＣＯＵＮＴ（口座）（状態６０４）、ＡＣＣＥＰＴ（受容）（状態６０６）、およびＲＥＪＥＣＴ（拒絶）（状態６０８）を示している。状態間の矢印は図５および図６の検査ポリシー５００について上述した、当該状態間を遷移するための条件を表している。
【００７８】
最後に、図８を参照する。図８は図５および図６の検査ポリシーの例における検査クライアント装置と検査サーバとの間の検査セッションを示すフロー図である。たとえば、このようなセッションは図１の検査クライアント装置１０２と検査サーバ１０４との間で行われる。
【００７９】
一実施形態では、３種類のセッションがある（これらはすべて開始セッション（opening session)と終了セッション（closing session)を備えている。
（１）管理セッション（administrative session）。ここでは、ポリシーの付加／更新／削除、オブジェクトの付加／更新／削除、コンテキスト変数の付加などのオペレーションを行う。
（２）登録セッション。ここでは、ユーザ・モデルの作成／更新／削除などのオペレーションを行う。
（３）検査セッション。ここでは、検査オブジェクトのスコア付け、検査セッションの継続と次状態の決定、検査判定の出力、コンテキストの更新／削除、コンテキスト変数の値のセット／取得、ユーザ・モデル／検査オブジェクト／検査ポリシーへの照会、などのオペレーションを行う。
【００８０】
管理セッションにおけるオペレーションは認証システムの管理者（administrator)がクライアント装置を用いて、あるいは直接に検査サーバにおいて実行する。登録セッションおよび検査セッションはユーザがクライアント装置を用いて、あるいは直接に検査サーバにおいて実行する。
【００８１】
図８のフロー図は図５および図６の検査ポリシー５００を用いた場合の検査セッションにおけるオペレーション・フロー７００の一例を示すものである。
【００８２】
図示するようにステップ７０２において、クライアントはサーバとの間で検査セッションを開始するが、その際、ポリシー名（ＳＩＭＰＬＥ＿ＢＡＮＫ＿ＰＯＬＩＣＹ〔単純な銀行ポリシー〕）とユーザ名（John Doe〔ジョン・ドウ〕）をデフォルトのコンテキストを用いて宣明する。サーバは参照されたポリシーとユーザ・モデルを検索・取得する。
【００８３】
サーバは当該ポリシーと当該ユーザ・モデルを処理して、呼び出すべき最初の検査オブジェクト（この例ではＤＯＢ〔誕生日〕）を決める。次いで、サーバはコンテキストを更新した後、当該オブジェクトとコンテキストとを求める要求をクライアントに送付する（ステップ７０４）。
【００８４】
クライアントは呼び出した検査オブジェクトに対する応答（「ＤＯＢ＝08-02-1975」）を取得した後、当該応答を現在のコンテキストとともにサーバに送付する（ステップ７０６）。上述したように、複数のサーバを使用する実施形態では、当該応答を最初のサーバに送付する必要はなく、認証システム中の別のサーバに送付することができる。これは、そのような実施形態に存在する、ステートレス（atateless:状態不保持）のクライアント−サーバにおける通信の特質に起因する。
【００８５】
次いで、（最初の）サーバ（または他のサーバ）は当該検査オブジェクトをスコア付けし、コンテキストを更新し、ポリシー中の次の状態を決定し、利用可能なオブジェクトから成るリストから次の検査オブジェクト（この例ではＣＵＲ＿ＢＡＬＡＮＣＥ〔現在の差引残高〕）を選択し、それを更新済みのコンテキストとともにクライアントに送付する（ステップ７０８）。
【００８６】
ＣＵＲ＿ＢＡＬＡＮＣＥ（現在の差引残高）オブジェクトは回答が頻繁に変化する動的オブジェクトであるから、クライアントはアプリケーションから取得する現在値（curBalance = 10000) を用いて関連するコンテキスト変数を更新する（ステップ７１０）。ステップ７１２において、サーバはステップ７１０に対する確認応答を返す。
【００８７】
クライアントは呼び出した検査オブジェクト（ＣＵＲ＿ＢＡＬＡＮＣＥ＝１００００〔現在の差引残高＝１００００））に対する応答を取得した後、当該応答を現在のコンテキストとともにサーバに送付する（ステップ７１４）。
【００８８】
次いで、サーバは当該検査オブジェクトをスコア付けし、当該ポリシーが満たされているものと判断した後、「ＡＣＣＥＰＴ（受容）」判定を出力する（ステップ７１６）。次いで、クライアントは検査セッションを終了する。
【００８９】
理解すべき点を挙げると、登録セッションと管理セッションにおいては、これらのセッションにおいて実行するオペレーションに特有の、クライアントとサーバとの間における要求−応答対を個別に設けることになる。さらに理解すべき点を挙げると、認証システムを単一のコンピュータ・システムに実装する実施形態では、ユーザは特定のセッションに付随するトランザクションを実行する際に当該単一のコンピュータ・システムと直接に対話（相互作用）する。
【００９０】
以上、ここでは本発明の説明を目的とした実施形態群を図面を参照して記述したが、理解すべき点を挙げると、本発明はそれら実施形態群に示された通りのものに限定されず、本発明の範囲または本旨の範囲内で当業者は他の様々な変形と変更をなすことができる。
【図面の簡単な説明】
【００９１】
【図１】本発明の一実施形態に従い複数の検査オブジェクトを使用するカスタマイズ可能な検査機構を実現する認証システムのクライアント−サーバ型のアーキテクチャを示す図である。
【図２】本発明の一実施形態に従い複数の検査オブジェクトを使用するカスタマイズ可能な検査機構を実現する典型的なコンピューティング・システムの環境を示すブロック図である。
【図３】本発明の一実施形態に従い複数の検査オブジェクトの典型的な仕様を示す図である。
【図４】本発明の一実施形態に従い複数の検査オブジェクトを含むユーザ・モデルの典型的な仕様を示す図である。
【図５】本発明の一実施形態に従い複数の検査オブジェクトを用いて動的なユーザ認証を行うカスタマイズ可能な検査ポリシーの典型的な仕様を示す図である。
【図６】本発明の一実施形態に従い複数の検査オブジェクトを用いて動的なユーザ認証を行うカスタマイズ可能な検査ポリシーの典型的な仕様を示す図である。
【図７】図５および図６の検査ポリシーの例における状態遷移を示す状態遷移図である。
【図８】図５および図６の検査ポリシーの例における検査クライアント装置と検査サーバとの間の検査セッションを示すフロー図である。
【符号の説明】
【００９２】
１００ 認証システム
１０２ 検査クライアント
１０４ 検査サーバ
１０６ ネットワーク・アダプタ
１０８ コンテキスト
１１０ アプリケーション
１１２ 検査ポリシー・マネージャ
１１４−１ 検査エンジン＃１
１１４−Ｎ 検査エンジン＃Ｎ
１１６ データ・マネージャ
１１８ 検査オブジェクト・ストア
１２０ 検査ポリシー・ストア
１２２ ユーザ・モデル・ストア
２００ コンピューティング・システム
２０２ コンピュータ・システム（クライアント）
２０４ コンピュータ・システム（サーバ）
２０６ ネットワーク
２０８−Ａ プロセッサ
２０８−Ｂ プロセッサ
２１０−Ａ メモリ
２１０−Ｂ メモリ
２１２−Ａ Ｉ／Ｏ装置
２１２−Ｂ Ｉ／Ｏ装置
２１４−Ａ コンピュータ・バス
２１４−Ｂ コンピュータ・バス
６００ 状態図
６０２ ＳＴＡＲＴ（開始）状態
６０４ ＡＣＣＯＵＮＴ（口座）状態
６０６ ＡＣＣＥＰＴ（受容）状態
６０８ ＲＥＪＥＣＴ（拒絶）状態
【技術分野】
【０００１】
本発明は認証手法に関し、特にカスタマイズ可能であるとともに状況に応じて使い分ける（context-dependent)、複数の検査オブジェクト（verification object)との相互作用を用いた動的ユーザ認証方式を提供する。
【背景技術】
【０００２】
物理的アクセスおよび論理的アクセスの双方の場合において、ユーザのアイデンティティ（ＩＤ）確認請求を認証することは、システムのセキュリティ、ネットワークのセキュリティ、サービスのセキュリティ、および施設のセキュリティを保証する際における重要なステップである。既存のユーザ認証方式は、単一の検査オブジェクト（たとえばパスワードや個人識別番号（personal identification number: ＰＩＮ）など）をユーザが知っていることに基づいて行う場合が多い。既存のユーザ認証方式では、単一の検査オブジェクト（たとえばキーやカードなど）を所持していることに基づいて行うこともある。既存の他の認証手法としては、生体統計学上の（biometric)特徴（たとえば指紋、声紋、虹彩〔こうさい〕走査情報、または顔走査情報）の１つを検査オブジェクトとして使用するものがある。
【０００３】
検査は通常、アクセスを試みる時点においてユーザから取得した検査オブジェクトと事前に格納しておいたオブジェクトとを比較することにより行う。したがって、指紋の場合、アクセスを試みる時点においてユーザから取得した指紋が（おそらく事前に当該ユーザから取得し）事前に格納しておいた指紋と一致するなら、アクセスを許可する。一致しないなら、アクセスを拒否する。
【０００４】
しかし、これら既存の認証手法には多くの難点がある。たとえば、キーまたはパスワードは盗まれる可能性があるし、生体統計学上の特徴はたとえば偽の指紋を使用されると破綻（はたん）する可能性がある。
【０００５】
より最近の手法では、複数の生体統計学的認識手法（たとえば顔認識と声紋認識など）を使用することを試みている。しかし、このような手法は生体統計学上の特徴の各々を順次かつ個別に取得して解析した後、最終出力を所定の静的な態様で組み合わせるだけであるから、生体情報群間の相互作用をなんら利用していない。
【０００６】
また、既存の認証手法には様々なユーザに特有の制約または要件、様々な取引に特有の制約または要件、あるいは、様々な用途に特有の制約または要件を取り扱うのに十分な柔軟性がない。たとえば、ユーザに特有の制約には、指を欠損したユーザは指紋認識システムを使用できない、というものがある。取引に特有の制約には、１００万ドルの取引は１０ドルの取引に比してより高度の認証が必要になるはずだ、というものがある。用途に特有の制約には、銀行取引なる用途を基準にしたセキュリティ上の質問は旅行なる用途には適していない、というものがある。既存の認証手法はこのような種類の制約または要件を取り扱うのに十分な柔軟性がまったくない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、セキュリティと認証に対する関心が高まりつつあるとともに、既存の認証システムに欠陥があることから、高度の柔軟性、高度の正確性、高度の利便性、および／または、高度の頑強性を実現しうる認証機構（authentication framework) が明確に求められている。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）
【課題を解決するための手段】
【０００８】
本発明は柔軟性、正確性、利便性、および頑強性を既存の認証機構に比して高めうる改良された認証機構を提供する。これは、たとえば動的なユーザ認証を可能にすることによって達成される。この動的なユーザ認証は共用コンテキストを用いて複数の検査オブジェクトを組み合わせるとともに、変動するユーザの選好および取引／用途の要件に適合するように対話（相互作用）の構成をカスタマイズ可能にするものである。このような機構によれば、高度の柔軟性、正確性、利便性、および頑強性が得られるので好都合である。
【０００９】
本発明の一側面において、ユーザ認証用の自動化された手法は次に示すステップ群／オペレーション群を備えている。まず、ユーザの入力を取得する。前記ユーザの入力の少なくとも一部分は少なくとも２つの検査オブジェクトに関連付けられている。次いで、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査する。
【００１０】
前記ユーザを検査するステップ／オペレーションは前記少なくとも２つの検査オブジェクトに個別に対応する少なくとも２つの検査エンジンによって実行するのが望ましい。前記少なくとも２つの検査エンジンは前記少なくとも２つの検査オブジェクトと少なくとも１つのユーザ・モデルとを個別に比較する。前記ユーザ・モデルはユーザを登録するセッションに合わせて取得するデータに基づいて事前に作成しておく。
【００１１】
また、前記少なくとも２つの検査オブジェクトにわたって共用されている前記コンテキストは前記ユーザを検査するステップ／オペレーションに付随する少なくとも１つの変数を備えている。たとえば、前記コンテキスト変数は、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数
のうちの少なくとも１つのものを表している。さらに、前記少なくとも２つの検査オブジェクトは、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している。
【００１２】
本発明の別の側面では、ユーザを認証する手法は次に示す点でカスタマイズ可能である。すなわち、前記手法が検査ポリシー、検査オブジェクトの型、ユーザ・モデル、および／または、前記コンテキストに付随する変数を、付加する、変更する、および／または、削除するステップ群／オペレーション群を備えている点においてである。これらのタスクは管理セッションにおいて実行する。
【００１３】
本発明のさらに別の側面では、ユーザ認証手法を少なくとも１つの検査サーバに接続された少なくとも１つのクライアント装置を備えた柔軟かつ分散型のアーキテクチャにおいて実現する。前記クライアント装置と前記検査サーバはここで説明した本発明に係るユーザ認証手法を協働して実行する。
【００１４】
前記クライアント装置と前記検査サーバとの間の通信インタフェースはＸＭＬ（Extensible Markup Language) によって実装する。前記クライアント装置と前記検査サーバとの間のそのような通信インタフェースは検査セッション、登録セッション、および／または管理セッションをサポートしている。
【００１５】
本発明のさらなる側面では、ユーザ認証手法は少なくとも１つの検査ポリシーの使用と、前記少なくとも１つの検査ポリシーに従ってユーザを検査するオペレーションを実行する検査手段とを備えている。前記少なくとも１つの検査ポリシーは前記検査手段によってステート・マシン（状態遷移機械）として実装可能である。理解すべき点を挙げると、ここで参照している検査手段は多数のインプリメンテーション（たとえばハードウェア、ソフトウェア、および／またはそれらの組み合わせで実装しうる検査モジュール）において実現することができる。
【００１６】
本発明のさらに別の側面では、ユーザ認証手法は少なくとも１つの検査オブジェクトの使用と、前記少なくとも１つの検査オブジェクトによってユーザを検査するオペレーションを実行する検査手段とを備えている。前記少なくとも１つの検査オブジェクトは、
（ｉ）関連する検査エンジンを使用しない検査に使用しうる状態、
（ｉｉ）前記少なくとも１つの検査オブジェクトに関するデータを用いて事前に登録する必要がない状態、
（ｉｉｉ）動的である状態、
（ｉｖ）暗黙である状態、
（ｖ）別のオブジェクトから少なくとも１つのプロパティを継承しうる状態、
（ｖｉ）複数の入力を特徴としている状態、
（ｖｉｉ）重み付けられている状態、および、
（ｖｉｉｉ）操作可能である状態、
のうちの少なくとも１つの状態にある。暗黙は、前記オブジェクトがユーザの入力（たとえば発信者電話番号に基づくオブジェクトなど）を必要としない、ということを意味しているのが望ましい。継承は、１つのオブジェクトが別のオブジェクトからプロパティを継承しうる（たとえば、あるオブジェクトが色を呼び出された場合、親オブジェクト〔色〕からプロパティを継承している車の色を呼び出して新たなオブジェクトを生成することができる）、ということを意味しているのが望ましい。
【００１７】
本発明のさらに別の側面では、ユーザ認証手法は少なくとも１つのユーザ・モデルの使用と、前記少なくとも１つのユーザ・モデルに従ってユーザを検査するオペレーションを実行する検査手段とを備えている。前記少なくとも１つのユーザ・モデルは、
（ｉ）ユーザの少なくとも１つの選好を表している状態、および、
（ｉｉ）引き続くユーザの検査で使用するために変更しうる状態
のうちの１つの状態にある。
【００１８】
本発明のこれらの目的および他の目的、特徴、ならびに利点は以下に示すそれらの説明を目的とする、添付図面とともに読むべき実施形態の詳細な説明から明らかになる。
【発明を実施するための最良の形態】
【００１９】
以下の記述においては、典型的なクライアント−サーバ型のシステム・アーキテクチャを用いて本発明を説明する。しかし、理解すべき点を挙げると、本発明は特定のシステム・アーキテクチャを備えた用途に限定されない。それどころか、本発明は一般に、高度の柔軟性、高度の正確性、高度の利便性、および／または、高度の頑強性を実現しうる認証機構を備えることが望まれるすべてのシステム・アーキテクチャに適用することができる。すなわち、本発明の手法は単一のコンピュータ・システムにおいて、または、適切なネットワークで接続された複数のコンピュータ・システムにおいて実現することができる。これらの実例は後述する。
【００２０】
ここで例を用いて詳細に説明するように、本発明は多くの検査オブジェクトを含み、きわめて多岐にわたる、ユーザに特有の制約、取引に特有の制約、用途に特有の制約、および、他の関連する要件を取り扱いうるように認証プロセスを完全にカスタマイズすることを可能にする新たなプログラミング・モデルを提供するものである。
【００２１】
また、本発明によれは、ユーザとシステムとの間の相互作用の変化にリアルタイムで応答して変更しうる動的ユーザ認証プロセスを実現することが可能になる。このようにアーキテクチャがきわめて柔軟であるから、新たな検査オブジェクトと検査ポリシーをいつでも付加することが可能になる。さらに、共通のコンテキストと関連するデータ構造とを備えているから、認証相互作用全体がこの共用のコンテキストに基づいて動作することが可能になる。
【００２２】
一実施形態では、相互作用の構成はＸＭＬ（eXtensible Markup Language）を用いて統計型ステート・マシン（状態遷移機械）として実装した認証ポリシーに基づいている。また、関連する認証オブジェクト（たとえば尋ねるべき質問、実行すべきアクション、など）を指定している１つのファイルと、ユーザ・プロファイル（たとえばユーザが選択した認証オブジェクトと正しい応答、ユーザの選好、など）を含むファイル群とが存在する。この両者もＸＭＬを用いて実装する。
【００２３】
認証相互作用全体は（ユーザの選好、および取引上の要件または用途上の要件に基づいて選択した）現に効力を有する認証ポリシー基づいて動的に決める。その際、共用コンテキストに基づいたオペレーションを使用し、さらに現に効力を有する認証オブジェクトおよび当該ユーザのプロファイルも利用する。
【００２４】
このような方法によって、既存の認証システムに比して顕著に改良された認証機能が実現するとともに、きわめて高度な正確性、柔軟性、利便性、および頑健性が保証されるようになる。
【００２５】
また、以下において実例を用いて詳細に説明するように、本発明の認証手法は次に示すコンポーネントを利用している。すなわち、（１）検査オブジェクトおよび検査エンジン、（２）検査ポリシーおよび検査ポリシー・マネージャ、ならびに（３）ユーザ・モデルである。
【００２６】
検査オブジェクトとは次に示すような、ユーザのアイデンティティ（ＩＤ）を検査する目的で使用することのできるオブジェクト（対象）のことである。すなわち、ユーザの生体統計学上の特徴（たとえば声紋、指紋、顔走査情報、虹彩走査情報、手書き署名、キーボードの運動力学的情報（keyboard dynamics)など）、ユーザの知識（たとえばパスワード、パスフレーズ（passphrase）、個人的な質問に対する回答など）、およびユーザの所有物（たとえばキー（鍵）、カード、トークン、資格証明書、発信者電話番号（caller-id)情報を送信する携帯電話機または家庭用電話機（home telephone) 、クライアント・ソフトウェアを備えたパーソナル・コンピュータまたはハンドヘルド型コンピュータ、ユーザの居場所など）などである。理解すべき点を挙げると、上掲したオブジェクトの例のリストはこれで尽きることを意図していない、また、本発明を特定のオブジェクトに限定する意図はない。
【００２７】
検査オブジェクトとユーザ・モデル中に格納されている表記とを照合するために検査エンジンを使用する。検査エンジンの例として、次に示すものが挙げられる。すなわち、ユーザの指紋を照合する指紋認識システム、質問に対する口頭による回答を評価する会話システム（たとえば音声応答システムなど）、ユーザの口頭の発声を抽出して認識する会話システム（たとえば〔自然な理解手法を含む〕音声認識システムまたは声紋認識システム）（この会話システムには合成した質問と催促を生成する音声合成システムも含まれる）、ユーザの電話番号を抽出して照合する発信者電話番号認識システム、ユーザのバッジまたはカードを走査するバッジ読み取り装置、ユーザのＰＩＮを確認するＰＩＮ確認システム、ユーザの顔走査情報を抽出して照合する顔認識システム、ユーザの虹彩走査情報を抽出して照合する虹彩認識システム、ユーザの手書き情報を認識する手書き認識システム、ユーザのキーボードの運動力学的情報を照合するキーボード運動力学認識装置、ならびに、ここで検討した、および／または別の状況において既知でありうる他の属性に特有の（modality-specific)エンジンである。理解すべき点を挙げると、これらの種類のエンジンは周知であるから、このようなエンジンの詳細なさらなる説明は不必要であるので、ここには提示しない。再度理解すべき点を挙げると、上掲したエンジンの例のリストはこれで尽きることを意図していない、また、本発明を特定のエンジンに限定する意図はない。
【００２８】
検査エンジンは通常、ユーザの入力とユーザが登録したときに生成したユーザのモデルとを比較することによりユーザの検査を行うが、本発明はユーザの登録を必要とする検査エンジンに限定されない。ユーザが登録することを必要としない非監視型の検査エンジンを使用してもよい。非監視型の検査エンジンを使用する場合、当該検査エンジンが比較するユーザ属性群を備えた単一のユーザ・モデルを使用する。たとえば、次に示す検査エンジンを使用することができる。すなわち、音調（acoustic accent)の認識、言語の特定、および顔の特徴の検出（たとえば目の色や眼鏡の検出など）などである。この場合、個々の検査エンジンはユーザの登録を必要としないから、単一のユーザ・モデルを用いて、ユーザが話す会話のアクセント、言語、目の色、および、ユーザが眼鏡を着用しているか否かを明確に識別することが可能になる。
【００２９】
したがって、本発明は次に示す点を認識することに基づいている。すなわち、個々の検査エンジンを用いても、事前に定義した静的な態様で処理する単純な検査ステップ群を実行することはできるけれども、より高度の正確性と柔軟性を達成するために複数の検査オブジェクトを用いて動的なユーザ認証を行う場合にはより一般的な機構が必要になる。本発明はそのような改良された認証機構を提供するものである。
【００３０】
この目標および他の目標を達成するために、本発明では検査ポリシーなる概念を導入する。検査ポリシーは、ユーザと認証システムを含むシステム全体との間の相互作用、および様々な検査エンジン群間の相互作用を規整するものである。リアルタイムで変更しうるようにすることに対する需要を含むきわめて多様な需要、すなわちユーザに特有の認証に対する需要、取引に特有の認証に対する需要、または用途に特有の認証に対する需要を満たすこめに、任意個数の検査ポリシー群を作成することができる。
【００３１】
後述するように、このような検査ポリシーは検査ポリシー・マネージャが管理する。検査ポリシー・マネージャはすべての検査オブジェクトにわたって共用される共通のコンテキストに基づくオペレーションを用いることにより、認証システムのプログラム可能性を最大限に達成している。
【００３２】
本発明の一実施形態では、上記検査ポリシーを、少なくとも１つの検査オブジェクトを処理する有限ステート・マシン（有限状態機械）としてを実装している。初期状態から開始し、様々な検査オブジェクトを処理する時に他の状態への遷移が起こり、そして、ユーザを受容または拒絶する終端状態を備えている。ある場合には、ユーザの受容を許可する複数の状態を備えている。その場合、この複数の状態の各々は処理中のトランザクションのセキュリティに対する需要が異なることに対応するために、各状態はそれ自身に固有のセキュリティ・レベル（たとえば低セキュリティ、中セキュリティ、高セキュリティなど）を備えている。検査ポリシー・マネージャを設けると、新たな検査オブジェクトをいつでも付加しうるようになる。それには、検査オブジェクトのリポジトリに新たな検査オブジェクトへの指示部を備えるようにする。以後、検査ポリシーが行う当該新たな検査オブジェクトに対する呼び出しを利用することが可能になる。
【００３３】
ユーザ・モデルは通常、ユーザがシステムに登録するときに生成するが、その際、当該ユーザが提供した入力（たとえば声の標本、指紋の標本、個人的な質問に対する回答など）、または他の手段を用いて取得した入力（たとえば過去の取引の詳細、最近の請求書の差引残高、発行済みのキーまたはバッジの通し番号、スマートカードまたはクライアント・ソフトウェアに含まれている暗号化キーなど）を使用する。
【００３４】
ユーザ・モデルは必要なとき（たとえば新たな請求書が発行され差引残高が変更されたとき、または、より多くの声の標本が利用可能になったとき、など）にはリアルタイムで更新する。個々のユーザ・モデルは当該ユーザに関係するすべての検査オブジェクト（たとえば検査オブジェクトに関するユーザの選好〔たとえばあるユーザは数字に関する質問よりも色に関する質問を好む〕など）に関する情報を含んでいる。ユーザ・モデルは検査オブジェクトの重要な処理（たとえばユーザに当該ユーザの社会保障番号の第１桁と第３桁を付加するか否かを質問すること、など）もサポートしているのが望ましい。この場合にも、上述したいかなる例も本発明を限定することを意図していない。
【００３５】
以上、本発明の原理と特徴の一部を一般的に説明したから、以下ではこれらの原理と特徴を説明する実施形態を図面を用いて提示する。
【００３６】
まず、図を参照する。図１は本発明の一実施形態に従い複数の検査オブジェクトを用いてカスタマイズ可能な検査機構を実現している認証システムのクライアント−サーバ・アーキテクチャを示すブロック図である。図示するように、認証システム１００はネットワーク・アダプタ１０６を介して接続された検査クライアント装置１０２と検査サーバ１０４とを備えている。検査クライアント１０２それに付随するコンテキスト１０８とアプリケーション１１０とを備えている。検査サーバ１０４は検査ポリシー・マネージャ１１２と複数の検査エンジン（１１４−１）〜（１１４−Ｎ）（ただし、Ｎは［２、３、４、・・・］のうちの任意の整数であり、本発明の特定の実現例がサポートしうる検査オブジェクトのファミリすなわち種別の個数を表している）とを備えている。認証システム１００はさらにデータ・マネージャ１１６、検査オブジェクト・ストア１１８、検査ポリシー・ストア１２０、およびユーザ・モデル・ストア１２２も備えている。データ・マネージャ１１６と検査オブジェクトストア１１８は検査サーバを表すボックスの外部に示されているが、それらは検査サーバ上に実装してもよいということを理解すべきである。
【００３７】
検査クライアント装置１０２はユーザにインタフェースを提供して当該ユーザから入力を収集すること、ネットワーク・アダプタ１０６を介して検査サーバ１０４と通信すること、および、アプリケーション１１０と通信することを担当する。本発明の一実施形態では、検査クライアント装置１０２はコンテキスト１０８を取得してそれを保持することも担当する。
【００３８】
別の実施形態では、コンテキスト１０８はシステム１００の他のコンテキストがアクセスしうる中央データベース（図示せず）に格納する。そのような実現例によれば、検査クライアント装置１０２と検査サーバ１０４との間において状態非保持オペレーション（stateless operation)を実現することが可能になる。その結果、検査プロセス中の様々な局面に対して様々なサーバを使用しうるようになるから、検査プロセスの最中にある特定のサーバから保護することが可能になるとともに、サーバのリソースの負荷均衡を改善することも可能になる。
【００３９】
コンテキスト１０８には関連する、たとえば次に示すような変数をすべて記録して検査プロセスの用に供している。すなわち、（１）ユーザの名前、（２）現に効力を有する検査ポリシーの現在の状態、（３）呼び出した検査オブジェクトに付随する履歴、およびその呼び出しに付随するスコア（score)と結果、（４）取引に特有の要件（たとえば必要な正確性のレベル、取引の性質など）、（５）ユーザに特有の要件（たとえば風邪を引いているユーザは声紋の一致を信頼したがらない、など）、および（６）他の物理的変数および論理的変数（たとえばネットワーク接続の種別〔リモート（遠隔）かローカルか〕、音声チャネルの品質、など）である。
【００４０】
コンテキスト１０８には外部の検査源（図示せず）が出す検査スコアを表す他の変数も記録する。たとえば、銀行内にいる顧客は入り口で自分の銀行カードを機械にスッと通した（swipe)後に銀行に入ったのであるが、その情報はコンテキスト１０８に外部のスコアとして格納することが可能性であり、引き続くカウンタまたはＡＴＭ（automated teller machine: 現金自動預け払い機）における認証プロセスで使用することが可能性である。
【００４１】
コンテキスト１０８に始めに格納する変数は検査オブジェクトと初期作成（initial build)時に既知の他の要件とに関連する、システムのデフォルトの変数である。しかし、システム１００に追加の検査オブジェクトを付加するとき、または、新たな要件が発見されたときには、コンテキスト１０８にユーザが定義した
変数を付加する。
【００４２】
ネットワーク・アダプタ１０６はクライアント装置１０２と検査サーバ１０４との間の通信を可能にするものである。ネットワーク・アダプタ１０６はネットワーク・トランスポート・プロトコル（たとえば標準のＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol)やＳＳＬ（Secure Sockets Layer) プロトコルなど）を実装している。理解すべき点を挙げると、認証システム１００を単一のコンピュータ・システムに実装する実施形態では、ネットワーク・アダプタは必要ない。
【００４３】
図示するように、検査サーバ１０４は検査ポリシー・マネージャ１１２と１組の検査エンジン（１１４−１）〜（１１４−Ｎ）とを備えている。各検査エンジンは１つの所定の検査オブジェクトまたは１つのファミリ（種別）の検査オブジェクト群を処理する。たとえば、指紋検査エンジンは特定の指紋または様々な種類の指紋群（たとえば親指の指紋、人指し指の指紋、など）を処理する。同様に、知識検査エンジンは様々な種類の要求−応答型の質問（challenge-response question)を処理する。
【００４４】
アーキテクチャが柔軟であるから、新たな検査エンジンと新たな検査オブジェクトとを容易に付加することが可能になる。付加する検査エンジンは新たな種別のものでもあっても既存の種別のものであってもよい。たとえば、付加する前は声紋認識エンジンと指紋認識エンジンとを備えていた検査サーバに顔認識エンジンを付加することができるし、あるいは、第２の声紋認識エンジン（これは、たとえば異なる製造業者製のものでもよい）を付加することもできる。同様に、新たな検査エンジンに新たな検査オブジェクトを付加してもよいし、あるいは、既存の検査エンジンに新たな検査オブジェクトを付加してもよい（たとえば既存の知識検査エンジンに新たな質問を付加すること、など）。
【００４５】
検査ポリシー・マネージャ１１２は所定のユーザ用の検査ポリシーを解釈するとともに、認証プロセス全体を統御する。ポリシー・マネージャ１１２は検査クライアント装置１０２から現在のコンテキスト１０８を受領し、当該コンテキストを処理し、現在の検査オブジェクトの更新済みの状態を取り込み、そして、更新済みのコンテキストを、検査プロセスの間にとるべき次のステップの指示とともに検査クライアント装置１０２に返す。
【００４６】
本発明の一実施形態では、検査ポリシー・マネージャ１１２は有限ステート・マシン中にある状態群を呼び出し、当該ステート・マシンの条件群を解釈し、そして次の状態に分岐する任に当たる。検査ポリシー・マネージャ１１２は認証プロセスのために最終的な受容判定または拒絶判定を行う実体（entity: エンティティ）である。現在のトランザクションが中間判定を必要とするなら、検査ポリシー・マネージャ１１２がそのような判定を行うこともありうる（ただし、現に効力を有する検査ポリシーがそれを許可している場合に限る）。
【００４７】
データ・マネージャ１１６なるコンポーネントは外部の記憶リソース群を制御するが、それらには検査オブジェクト・ストア１１８、検査ポリシー・ストア１２０、ユーザ・モデル・ストア１２２が含まれる。これらのリソースには検査サーバ１０４が（検査ポリシー・マネージャ１１２または個別の検査エンジン〔１１４−１〕〜〔１１４−Ｎ〕を用いて）直接にアクセスする。別の実施形態では、このようなリソースには検査クライアント装置１０２がアクセスするとともに、それらはネットワーク・アダプタ１０６を介して検査サーバ１０４に供給される。
【００４８】
アプリケーション１１０はアクセスを許可する前にユーザの認証を必要とするアプリケーションである。アプリケーションの例としては銀行取引アプリケーション、旅行アプリケーション、および電子メール・アプリケーションなどが挙げられる。アプリケーション１１０はアプリケーションに特有の情報と要件、およびトランザクションに特有の情報と要件を提供する任に当たる。理解すべき点を挙げると、本発明は特定のアプリケーションに限定されない。
【００４９】
本発明の一実施形態では、検査クライアント装置１０２はＸＭＬで記述したメッセージ・インタフェースを用いて検査サーバ１０４と通信する。上記インタフェースがサポートする機能の例には次に示すオペレーションが含まれる。
通信チャネルを開く；
検査セッションまたは登録セッションを閉じる；
ユーザの登録を開始し、ユーザ・モデルを作成する；
ユーザの登録を終了し、登録セッションを閉じる；
検査オブジェクトのスコア付け（scoring)を開始する；
検査オブジェクトのスコア付けを終了する。；
検査セッションを開始する；
検査セッションを継続してポリシー中の次の状態を決める、あるいは判定を出力する；
新たな検査オブジェクトを付加する；
新たな検査ポリシーを付加する；
検査ポリシーを削除する；
コンテキストを削除する；
検査オブジェクトを更新して既存の検査オブジェクトを変更する；
ユーザ・モデルを更新して既存のユーザ・モデルを変更する；
検査ポリシーを更新して既存の検査ポリシーを変更する；
ユーザ・モデルに照会してユーザ・モデル中の情報を取得する；
検査オブジェクトに照会して検査オブジェクト中の情報を取得する；
検査ポリシーに照会して検査ポリシー中の情報を取得する；
アクティブな検査オブジェクトから成るリストを取得する；
コンテキスト変数を付加する；
コンテキスト変数に現在の値をセットする；
コンテキスト変数用に現在の値を取得する；
すべてのコンテキスト変数から成るリストとそれらの現在値とを取得する；
【００５０】
理解すべき点を挙げると、上掲したオペレーションのリストはこれで尽きているということを意図しておらず、また本発明をこれら特定のオペレーション例に限定する意図はない。
【００５１】
さらに理解すべき点を挙げると、別の実施形態では、検査サーバに付随するコンポーネント群自体がネットワーク・アダプタ１０６を介して相互に通信する。したがって、たとえば、少なくとも１つの検査エンジン１１４が、ネットワーク・アダプタ１０６を介して検査ポリシー・マネージャ１１２と通信する。また、検査ポリシー・マネージャ１１２とデータ・マネージャ１１６とについても同様の分散型の構成が存在するし、データ・マネージャ１１６とデータ・ストア１１８、１２０、１２２とについても同様の分散型の構成が存在する。したがって、次に示す点を理解すべきである。すなわち、図１に示すコンポーネント群の相互接続は説明を意図するものであるから、他の適切な相互接続を用いて本発明の認証機能を実現することができる。
【００５２】
次に、図２を参照する。図２は本発明の一実施形態に従い複数の検査オブジェクトを用いてカスタマイズ可能な検査機構を実現する典型的なコンピューティング・システム環境を示すブロック図である。一例として、コンピューティング・システム２００はユーザが（模式的に「クライアント」またはクライアント装置と呼ばれる）コンピュータ・システム２０２を用いて（模式的に「サーバ」と呼ばれる）別のコンピュータ・システム２０４とネットワーク２０６を介して通信する分散コンピューティング・システムの少なくとも一部分を示すものである。このネットワークとしては、その両端でコンピュータ・システム群が通信しうる適切な任意のネットワーク（たとえばインターネットすなわちワールド・ワイド・ウェブ（World Wide Web）、ＬＡＮ（local area network）など）を使用することができる。しかし、本発明は特定の種別のネットワークに限定されない。事実、コンピュータ・システム群はネットワークなしに直接にリンクしうる、という点を理解すべきである。
【００５３】
また、説明を簡易にするために、図２には２つのコンピュータ・システムしか示されていないけれども、ネットワークは複数のクライアント装置と複数のサーバとをリンクすることができる。しかし、本発明の手法は単一のコンピュータ・システムに実装することができる、という点も認識すべきである。その場合、たとえばユーザが、認証オペレーションを実行しているコンピュータ・システムと直接に対話（相互作用）する。
【００５４】
図１を参照して次に示す点を理解すべきである。すなわち、クライアント装置１０２はコンピュータ・システム２０２を用いて実現することができる。そして、検査サーバ１０４（およびそのコンポーネント群）、データ・マネージャ１１６、ならびに個別のオブジェクト・ストア、ポリシー・ストア、およびユーザ・モデル・ストア（１１８、１２０、１２２）はコンピュータ・システム２０４を用いて実現することができる。したがって、ネットワーク・アダプタ１０６はネットワーク２０６によって実現することができる。
【００５５】
したがって、図２はネットワークを介して通信する各コンピュータ・システム用の典型的なアーキテクチャを一般的に示している、という点を理解すべきである。図示するように、コンピュータ・システム２０２はプロセッサ（２０８−Ａ）、メモリ（２１０−Ａ）、およびＩ／Ｏ装置（２１２−Ａ）を備えている。そして、これらはすべてコンピュータ・バス（２１４−Ａ）を介して接続されている。同様に、コンピュータ・システム２０４はプロセッサ（２０８−Ｂ）、メモリ（２１０−Ｂ）、およびＩ／Ｏ装置（２１２−Ｂ）を備えている。そして、これらはすべてコンピュータ・バス（２１４−Ｂ）を介して接続されている。
【００５６】
理解すべき点を挙げると、ここで使用する用語「プロセッサ」はＣＰＵ（central processing unit:中央処理装置）または他の処理回路などの処理装置を少なくとも１つ含むことを意図している。また、ここで使用する用語「メモリ（記憶装置）」はプロセッサまたはＣＰＵに付随するメモリ（たとえばＲＡＭ、ＲＯＭ、固定的かつ永続的な記憶装置〔たとえばハード・ディスク駆動装置など〕、または着脱可能かつ永続的な記憶装置〔たとえばディスケット(R) やＣＤ−ＲＯＭなど〕）を含むことを意図している。さらに、ここで使用する用語「Ｉ／Ｏ装置」は処理装置にデータを入力する入力装置（たとえばキーボードやマウスなど）および処理装置に付随する結果を提示する出力装置（たとえばＣＲＴディスプイ装置など）を含むことを意図している。また、コンピュータ・システム２０２に付随するＩ／Ｏ装置は認証システムがサポートしている検査オブジェクトに付随する特定のデータを収集するのに必要な装置（たとえば声紋認識用の音声データ、および／または発せられた質問に対する回答を捕獲するマイクロフォン、そのような質問をユーザに出力するスピーカ、顔スキャナ（走査器）、虹彩スキャナ、指紋スキャナなど）を含むものと理解される。
【００５７】
さらに理解すべき点を挙げると、図２に示すクライアント・コンピュータ・システムには本発明に係る手法を実現しうるようにプログラムされたコンピュータ・システム（たとえばパーソナル・コンピュータ、ＰＤＡ（personal digital assistant）、携帯電話機など）が含まれる。同様に、図２に示すサーバ・コンピュータ・システムには本発明に係る手法を実現しうるようにプログラムされたコンピュータ・システム（たとえばパーソナル・コンピュータ、マイクロコンピュータ、ミニコンピュータなど）が含まれる。しかし、本発明は特定のコンピュータ・アーキテクチャに限定されない。
【００５８】
したがって、ここで説明する、本発明の手順（methodology)を実行するソフトウェア命令群すなわちコードは関連する記憶装置（たとえばＲＯＭ、固定型記憶装置、着脱可能型記憶装置など）のうちの少なくとも１つに格納しておき、使用しうる状態になったらＲＡＭ中にロードし、ＣＰＵが実行する。
【００５９】
次に、図３を参照する。図３は検査オブジェクトから成るレジストリの一例を示す図である。この特定の実施形態では、レジストリ３００はＸＭＬを用いて表し、検査オブジェクトストア１１８（図１）に格納しておく。
【００６０】
この仕様には登録済みの検査オブジェクトの記述がすべて含まれている。それらは新たな検査オブジェクトを付加するときに更新することができる。この例における第１のオブジェクトはＤＯＢ（Date-of-Birth:誕生日）オブジェクトである。これはＱＡ（Question-Answer:質問−回答）型（type) である。このオブジェクトを処理する任に当たる検査エンジンは知識検査エンジンである。このオブジェクトを呼び出すと必要な応答をユーザに促す提案型プロンプト（suggested prompt) も含まれている。しかし、必要な場合には、検査クライアントはこのプロンプトを変更または置換することができる。「perplexity（難度）」は検査オブジェクトに付随する困難性を表す量であるが、検査ポリシー・マネージャが検査判断を行う際に任意事項として使用する。
【００６１】
この例における第２のオブジェクト３０４は発信者電番号（Caller-ID)である。これは電話接続の場合において、呼（こ）を発した電話の電話番号と関連するユーザ・モデル中の電話番号とを照合しようとするものである。プロンプトが指定されていないのは、この情報がユーザの明示的な入力がまったくなくとも電話のインフラストラクチャから自動的に取得しうるものだからである。
【００６２】
この例における第３のオブジェクト３０６は声紋（Voiceprint）オブジェクトである。この場合、型（type) が指定されていないのは、この声紋認識エンジンが１つの型の検査オブジェクトを処理するものだからである。声紋は盗まれることのない生体統計学上の特徴であるから、この例では難度（perplexity）を高く指定している。
【００６３】
第４のオブジェクト３０８と第５のオブジェクト３１０はこの仕様の階層的な特質を示すものである。すなわち、ＣＡＲ＿ＣＯＬＯＲ（車の色）オブジェクトは親オブジェクトＣＯＬＯＲ（色）からデフォルトのプロパティを継承している。
【００６４】
この例における最後の２つのオブジェクト３１２、３１４は将来の応答が動的に変動する動的検査オブジェクトの例である。この例では、正確な応答はユーザ・モデルではなくアプリケーションから取得する。現在の差引残高（ＣＵＲ＿ＢＡＬＡＮＣＥ）オブジェクト３１２は数値型（ＡＰＰ＿ＮＵＭ）の、用途に特有のオブジェクトである。最終取引日（ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＥ）オブジェクト３１４はストリング（string）型の、用途に特有のオブジェクトである。
【００６５】
次に、図４を参照する。図４はユーザ・モデルの一例を示す図である。この特定の実施形態では、ユーザ・モデル４００はＸＭＬを用いて表し、ユーザ・モデル・ストア１２２（図１）に格納しておく。
【００６６】
ユーザ・モデルにはユーザが登録データを提供する際に目的とした検査オブジェクトの記述が含まれている。第１のオブジェクト４０２は発信者電話番号（Caller-ID)である。この場合、当該ユーザの正しい応答は「914-945-3000」である。このオブジェクトにおける当該ユーザの選好を含めるのは任意事項であるが、使用可能な場合にはより選好度の高いオブジェクトを選択する際に検査ポリシーがそれを使用する。
【００６７】
第２のオブジェクト（ＤＯＢ〔誕生日〕４０４）と第３のオブジェクト（ＣＯＬＯＲ〔色〕４０６）は類似している。第４のオブジェクト（車の色すなわちＣＡＲ＿ＣＯＬＯＲ（４０８））はこの例では２つの応答を有しているが、それはこのユーザが２台の車を所有しており、いずれの応答も正しい回答として受容されるからである。第５のオブジェクト４１０はモデルのパラメータを必要とする声紋オブジェクトである。これは１つのファイルに格納するとともに、ファイル名を含める。最後の２つのオブジェクト（ＣＵＲ＿ＢＡＬＡＮＣＥ〔現在の差引残高〕４１２とＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＥ〔最終取引日〕４１４）は動的検査オブジェクトであるから、正しい応答を含んでいない。したがって、現在の正しい応答はアプリケーションから取得する必要がある。
【００６８】
上述したように、本発明によれば、オブジェクトはすべてリアルタイムで更新または削除することができるし、新たなオブジェクトをリアルタイムで付加することもできる。
【００６９】
次に、図５および図６を参照する。図５および図６は検査ポリシーの一例を示す図である。この特定の実施形態では、検査ポリシー５００を有限ステート・マシンとして実装し、ＸＭＬを用いて表している。対応する有限ステート・マシン図を図７に示す。検査ポリシー５００は検査ポリシー・ストア１２０（図１）に格納するのが望ましい。
【００７０】
検査ポリシー５００は銀行取引なる用途に付随する単純なポリシーを示すものである。より詳細に述べれば、このポリシーは次に示す状況を規整するものである。すなわち、ユーザ（おそらく銀行の顧客）が自分の銀行口座へのアクセス権を取得しようとすると、認証システムが複数の検査オブジェクト（たとえば当該銀行の顧客の電話番号、当該銀行の顧客の誕生日、当該銀行の顧客の車の色、当該銀行の顧客の声紋、など）を用いて当該ユーザのアイデンティティ（ＩＤ）を検査しようとする、という状況である。しかし、上述したように、本発明は特定のポリシーまたは特定の用途に限定されない。次に示す、説明を目的とした記述では検査ポリシー５００の左側に記載した行番号（たとえば第１〜５３行）を参照する。
【００７１】
まず、図５において、コンテキスト変数（たとえば「curBalance（現在の差引残高）」〔第４行〕や「lastTransactionDate （最終取引日）」〔第６行〕など）をデフォルト値で初期化して動的検査オブジェクト（たとえば「ＣＵＲ＿ＢＡＬＡＮＣＥ（現在の差引残高）」や「ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＥ（最終取引日）」など）を処理しうるようにする。これらの変数は引き続いて、アプリケーションが出す入力を用いて更新することになる。次いで、変数「minVoiceprintScore（最小声紋スコア）」（第５行）を用いて、声紋の一致にとって受容しうる最小スコアを指定する。この変数用のデフォルト値は検査ポリシーを用いて指定する。ポリシーが異なると、デフォルト値も異なる（たとえばポリシーがより厳格になると、最小スコアはより大きくなる）。別の実施形態では、このデフォルト値は、（ユーザに特有の要件の根拠をなす）ユーザ・モデル、あるいは、（取引に特有の要件または用途に特有の要件の根拠をなす）アプリケーションから取得した値によって上書きする。
【００７２】
続いて、上記ポリシーに関連する１組の条件を指定する。これは状態遷移を決めるため、または検査オブジェクトを評価するために引き続いて使用することになる。上記条件群を定義するのに使用する式はコンテキスト変数、数値定数、およびストリング・リテラル（ストリング定数）を含んでいる。上記式は次に示すオペレーションを含んでいる。すなわち、論理ＡＮＤ（＆）、論理ＯＲ（｜）、等号（＝）、不等号（！＝）、未満（＜）、以下（＜＝）、超（超える）（＞）、以上（＞＝）、乗算（＊）、除算（／）、加算（＋）、および減算（−）である。
【００７３】
たとえば、条件「ＯＮＥ＿ＯＫ（１つ可）」（第１０行）（これは後刻、状態遷移を決めるのに使用する条件である）が満たされるのは、その時までに呼び出した検査オブジェクトの総数が「１」（＿curObjectNum = 1）であり、かつ、それは一致であった、すなわち、不一致はなかった（＿curWrongNum = 0)場合である。異なる種類の別の例としては条件「ＣＵＲ＿ＢＡＬＡＮＣＥ＿ＴＥＳＴ（現在の差引残高の検査）」（第１５行）が挙げられる。この条件は現在の差引残高（「ＣＵＲ＿ＢＡＬＡＮＣＥ」）検査オブジェクトを評価するのに使用する。この場合、たとえば５パーセントの誤差が許容されているが、それは概略の回答で十分だからである。
【００７４】
上記条件群に従って、１組の状態を定義する。この例には、４つの状態、すなわちＡＣＣＥＰＴ（受容）（第２２行）、ＲＥＪＥＣＴ（拒絶）（第２４行）、ＳＴＡＲＴ（開始）（第２７行）、およびＡＣＣＯＵＮＴ（口座）（第４０行）がある。ＡＣＣＥＰＴ（受容）とＲＥＪＥＣＴ（拒絶）は最終の検査判定を行う終端状態である。ＳＴＡＲＴ（開始）は初期状態であり、検査オブジェクト「ＣＡＬＬＥＲ＿ＩＤ（発信者電話番号）」、「ＤＯＢ（誕生日）」、および「ＣＡＲ＿ＣＯＬＯＲ（車の色）」を含んでいる。デフォルトでは検査オブジェクトを無作為に選択しているが、任意事項として、相対重みを指定してオブジェクトを選択する確率を変更してもよい。ＡＣＣＯＵＮＴ（口座）への遷移が起こるのは最初の２つの条件（ＯＮＥ＿ＯＫ〔１つ可〕またはＴＷＯ＿ＯＫ＿ＯＮＥ＿ＢＡＤ〔２つ可で１つ不可〕）のうちの１つが満たされる場合である。ＲＥＪＥＣＴ（拒絶）への遷移が起こるのは第３の条件（ＴＷＯ＿ＢＡＤ〔２つ不可〕）が満たされる場合である。
【００７５】
ＡＣＣＯＵＮＴ（口座）状態では、重みが指定されていないから、３つのオブジェクトの確率はすべて等しく無作為に選択される。また、これらのオブジェクトには異なる検査を使用する必要がある。それらは事前に定義しておいたリストから選択する。満たされる条件に従って、ＡＣＣＥＰＴ（受容）状態またはＲＥＪＥＣＴ（拒絶）状態への遷移が起こる。対応する最終判定は検査クライアント装置１０２（図１）に送付する。
【００７６】
別の実施形態では、中間状態において中間判定を行ってもよい。たとえば、ＳＴＡＲＴ（開始）状態においてある条件が満たされたら、セキュリティの低い取引用のユーザを受容する判定を行うことができる。そして、取引用のユーザを受容する最終判定はＡＣＣＥＰＴ（受容）状態において行うことができる。
【００７７】
次に、図７を参照する。図７は図５および図６の検査ポリシーの例における状態遷移を示す状態遷移図である。したがって、状態図６００は検査ポリシー５００に付随する４つの状態、すなわちＳＴＡＲＴ（開始）（状態６０２）、ＡＣＣＯＵＮＴ（口座）（状態６０４）、ＡＣＣＥＰＴ（受容）（状態６０６）、およびＲＥＪＥＣＴ（拒絶）（状態６０８）を示している。状態間の矢印は図５および図６の検査ポリシー５００について上述した、当該状態間を遷移するための条件を表している。
【００７８】
最後に、図８を参照する。図８は図５および図６の検査ポリシーの例における検査クライアント装置と検査サーバとの間の検査セッションを示すフロー図である。たとえば、このようなセッションは図１の検査クライアント装置１０２と検査サーバ１０４との間で行われる。
【００７９】
一実施形態では、３種類のセッションがある（これらはすべて開始セッション（opening session)と終了セッション（closing session)を備えている。
（１）管理セッション（administrative session）。ここでは、ポリシーの付加／更新／削除、オブジェクトの付加／更新／削除、コンテキスト変数の付加などのオペレーションを行う。
（２）登録セッション。ここでは、ユーザ・モデルの作成／更新／削除などのオペレーションを行う。
（３）検査セッション。ここでは、検査オブジェクトのスコア付け、検査セッションの継続と次状態の決定、検査判定の出力、コンテキストの更新／削除、コンテキスト変数の値のセット／取得、ユーザ・モデル／検査オブジェクト／検査ポリシーへの照会、などのオペレーションを行う。
【００８０】
管理セッションにおけるオペレーションは認証システムの管理者（administrator)がクライアント装置を用いて、あるいは直接に検査サーバにおいて実行する。登録セッションおよび検査セッションはユーザがクライアント装置を用いて、あるいは直接に検査サーバにおいて実行する。
【００８１】
図８のフロー図は図５および図６の検査ポリシー５００を用いた場合の検査セッションにおけるオペレーション・フロー７００の一例を示すものである。
【００８２】
図示するようにステップ７０２において、クライアントはサーバとの間で検査セッションを開始するが、その際、ポリシー名（ＳＩＭＰＬＥ＿ＢＡＮＫ＿ＰＯＬＩＣＹ〔単純な銀行ポリシー〕）とユーザ名（John Doe〔ジョン・ドウ〕）をデフォルトのコンテキストを用いて宣明する。サーバは参照されたポリシーとユーザ・モデルを検索・取得する。
【００８３】
サーバは当該ポリシーと当該ユーザ・モデルを処理して、呼び出すべき最初の検査オブジェクト（この例ではＤＯＢ〔誕生日〕）を決める。次いで、サーバはコンテキストを更新した後、当該オブジェクトとコンテキストとを求める要求をクライアントに送付する（ステップ７０４）。
【００８４】
クライアントは呼び出した検査オブジェクトに対する応答（「ＤＯＢ＝08-02-1975」）を取得した後、当該応答を現在のコンテキストとともにサーバに送付する（ステップ７０６）。上述したように、複数のサーバを使用する実施形態では、当該応答を最初のサーバに送付する必要はなく、認証システム中の別のサーバに送付することができる。これは、そのような実施形態に存在する、ステートレス（atateless:状態不保持）のクライアント−サーバにおける通信の特質に起因する。
【００８５】
次いで、（最初の）サーバ（または他のサーバ）は当該検査オブジェクトをスコア付けし、コンテキストを更新し、ポリシー中の次の状態を決定し、利用可能なオブジェクトから成るリストから次の検査オブジェクト（この例ではＣＵＲ＿ＢＡＬＡＮＣＥ〔現在の差引残高〕）を選択し、それを更新済みのコンテキストとともにクライアントに送付する（ステップ７０８）。
【００８６】
ＣＵＲ＿ＢＡＬＡＮＣＥ（現在の差引残高）オブジェクトは回答が頻繁に変化する動的オブジェクトであるから、クライアントはアプリケーションから取得する現在値（curBalance = 10000) を用いて関連するコンテキスト変数を更新する（ステップ７１０）。ステップ７１２において、サーバはステップ７１０に対する確認応答を返す。
【００８７】
クライアントは呼び出した検査オブジェクト（ＣＵＲ＿ＢＡＬＡＮＣＥ＝１００００〔現在の差引残高＝１００００））に対する応答を取得した後、当該応答を現在のコンテキストとともにサーバに送付する（ステップ７１４）。
【００８８】
次いで、サーバは当該検査オブジェクトをスコア付けし、当該ポリシーが満たされているものと判断した後、「ＡＣＣＥＰＴ（受容）」判定を出力する（ステップ７１６）。次いで、クライアントは検査セッションを終了する。
【００８９】
理解すべき点を挙げると、登録セッションと管理セッションにおいては、これらのセッションにおいて実行するオペレーションに特有の、クライアントとサーバとの間における要求−応答対を個別に設けることになる。さらに理解すべき点を挙げると、認証システムを単一のコンピュータ・システムに実装する実施形態では、ユーザは特定のセッションに付随するトランザクションを実行する際に当該単一のコンピュータ・システムと直接に対話（相互作用）する。
【００９０】
以上、ここでは本発明の説明を目的とした実施形態群を図面を参照して記述したが、理解すべき点を挙げると、本発明はそれら実施形態群に示された通りのものに限定されず、本発明の範囲または本旨の範囲内で当業者は他の様々な変形と変更をなすことができる。
【図面の簡単な説明】
【００９１】
【図１】本発明の一実施形態に従い複数の検査オブジェクトを使用するカスタマイズ可能な検査機構を実現する認証システムのクライアント−サーバ型のアーキテクチャを示す図である。
【図２】本発明の一実施形態に従い複数の検査オブジェクトを使用するカスタマイズ可能な検査機構を実現する典型的なコンピューティング・システムの環境を示すブロック図である。
【図３】本発明の一実施形態に従い複数の検査オブジェクトの典型的な仕様を示す図である。
【図４】本発明の一実施形態に従い複数の検査オブジェクトを含むユーザ・モデルの典型的な仕様を示す図である。
【図５】本発明の一実施形態に従い複数の検査オブジェクトを用いて動的なユーザ認証を行うカスタマイズ可能な検査ポリシーの典型的な仕様を示す図である。
【図６】本発明の一実施形態に従い複数の検査オブジェクトを用いて動的なユーザ認証を行うカスタマイズ可能な検査ポリシーの典型的な仕様を示す図である。
【図７】図５および図６の検査ポリシーの例における状態遷移を示す状態遷移図である。
【図８】図５および図６の検査ポリシーの例における検査クライアント装置と検査サーバとの間の検査セッションを示すフロー図である。
【符号の説明】
【００９２】
１００ 認証システム
１０２ 検査クライアント
１０４ 検査サーバ
１０６ ネットワーク・アダプタ
１０８ コンテキスト
１１０ アプリケーション
１１２ 検査ポリシー・マネージャ
１１４−１ 検査エンジン＃１
１１４−Ｎ 検査エンジン＃Ｎ
１１６ データ・マネージャ
１１８ 検査オブジェクト・ストア
１２０ 検査ポリシー・ストア
１２２ ユーザ・モデル・ストア
２００ コンピューティング・システム
２０２ コンピュータ・システム（クライアント）
２０４ コンピュータ・システム（サーバ）
２０６ ネットワーク
２０８−Ａ プロセッサ
２０８−Ｂ プロセッサ
２１０−Ａ メモリ
２１０−Ｂ メモリ
２１２−Ａ Ｉ／Ｏ装置
２１２−Ｂ Ｉ／Ｏ装置
２１４−Ａ コンピュータ・バス
２１４−Ｂ コンピュータ・バス
６００ 状態図
６０２ ＳＴＡＲＴ（開始）状態
６０４ ＡＣＣＯＵＮＴ（口座）状態
６０６ ＡＣＣＥＰＴ（受容）状態
６０８ ＲＥＪＥＣＴ（拒絶）状態
【特許請求の範囲】
【請求項１】
ユーザ認証を行う際に使用する装置であって、
少なくとも１つのプロセッサであって、
（ｉ）その少なくとも一部分が少なくとも２つの検査オブジェクトに関連付けられている、ユーザの入力を取得するオペレーションを実行し、かつ、
（ｉｉ）少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査するオペレーションを実行する
少なくとも１つのプロセッサと、
前記ユーザの入力のうちの少なくとも１つと前記ユーザを検査するオペレーションに付随する結果とを格納する、前記少なくとも１つのプロセッサに接続されたメモリと
を備えた
装置。
【請求項２】
前記少なくとも１つのプロセッサがさらに、前記少なくとも２つの検査オブジェクトに個別に対応する少なくとも２つの検査プロセスによって前記ユーザを検査するオペレーションを実行する、
請求項１に記載の装置。
【請求項３】
前記少なくとも２つの検査プロセスが前記少なくとも２つの検査オブジェクトと少なくとも１つのユーザ・モデルとを個別に比較する、
請求項２に記載の装置。
【請求項４】
前記少なくとも１つのユーザ・モデルが、前記メモリに事前に格納されているとともに、前記少なくとも１つのプロセッサによってアクセス可能である、
請求項３に記載の装置。
【請求項５】
前記少なくとも１つのユーザ・モデルが、前記少なくとも２つの検査オブジェクトにわたって共用されている、
請求項４に記載の装置。
【請求項６】
前記少なくとも１つのユーザ・モデルがＸＭＬ（Extensible Markup Language) で実装されている、
請求項３に記載の装置。
【請求項７】
前記少なくとも１つの検査ポリシーが、前記メモリに事前に格納されているとともに、前記少なくとも１つのプロセッサによってアクセス可能である、
請求項１に記載の装置。
【請求項８】
前記少なくとも１つの検査ポリシーがＸＭＬ（Extensible Markup Language) で実装されている、
請求項１に記載の装置。
【請求項９】
前記コンテキストが、前記ユーザを検査するオペレーションに関連付けられた少なくとも１つの変数を備えている、
請求項１に記載の装置。
【請求項１０】
前記少なくとも１つのコンテキスト変数が、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数
のうちの少なくとも１つのものを表している、
請求項９に記載の装置。
【請求項１１】
前記少なくとも２つの検査オブジェクトが、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している、
請求項１に記載の装置。
【請求項１２】
前記少なくとも１つのプロセッサがさらに、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
前記コンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加、
変更、および、
削除
のうちの少なくとも１つを行うことを受容するオペレーションを実行して、
前記ユーザを検査するオペレーションにおける引き続く使用に備えている、
請求項１に記載の装置。
【請求項１３】
少なくとも１つのクライアント装置に従って動作するユーザ認証システムであって、
前記少なくとも１つのクライアント装置に接続された少なくとも１つのサーバ
を備え、
前記少なくとも１つのサーバは前記少なくとも１つのクライアント装置からユーザの入力を取得し、
前記ユーザの入力の少なくとも一部分は少なくとも２つの検査オブジェクトに関連付けられており、
さらに、
前記少なくとも１つのサーバは、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査する、
ユーザ認証システム。
【請求項１４】
さらに、
前記ユーザは事前にデータを登録し、
前記データのうちの少なくとも一部分を用いてユーザ・モデルを作成し、
前記少なくとも１つのサーバが、前記ユーザを検査するオペレーションの間に前記少なくとも１つのユーザ・モデルを利用する、
請求項１３に記載のシステム。
【請求項１５】
前記少なくとも１つのサーバがさらに、前記ユーザを検査するオペレーションを実行する少なくとも２つの検査エンジンを備え、
前記少なくとも２つの検査エンジンは前記少なくとも２つの検査オブジェクトに個別に対応している、
請求項１３に記載のシステム。
【請求項１６】
前記コンテキストが、前記ユーザを検査するオペレーションに関連付けられた少なくとも１つの変数を備えているとともに、前記少なくとも１つのクライアント装置および少なくとも１つのサーバにおいて保持されている、
請求項１３に記載のシステム。
【請求項１７】
前記少なくとも１つのコンテキスト変数が、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数のうちの少なくとも１つのものを表している、
請求項１６に記載のシステム。
【請求項１８】
前記少なくとも２つの検査オブジェクトが、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している、
請求項１３に記載のシステム。
【請求項１９】
前記少なくとも１つのサーバが、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
前記コンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加、
変更、および、
削除
のうちの少なくとも１つを行うことを受容するオペレーションを実行して、
前記ユーザを検査するオペレーションにおける引き続く使用に備えている、
請求項１３に記載のシステム。
【請求項２０】
ユーザを認証する自動化された方法であって、
その一部分が少なくとも２つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップと、
少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査するステップと
を備えた
方法。
【請求項２１】
前記ユーザを検査する前記ステップを、前記少なくとも２つの検査オブジェクトに個別に対応する少なくとも２つの検査エンジンによって実行する、
請求項２０に記載の方法。
【請求項２２】
前記少なくとも２つの検査エンジンが前記少なくとも２つの検査オブジェクトと少なくとも１つのユーザ・モデルとを個別に比較する、
請求項２１に記載の方法。
【請求項２３】
前記少なくとも１つのユーザ・モデルが前記少なくとも２つの検査オブジェクトにわたって共用されている、
請求項２２に記載の方法。
【請求項２４】
前記少なくとも１つのユーザ・モデルを、ユーザを登録するセッションに合わせて事前に作成する、
請求項２２に記載の方法。
【請求項２５】
前記コンテキストが、前記ユーザを検査する前記ステップに関連付けられた少なくとも１つの変数を備えている、
請求項２０に記載の方法。
【請求項２６】
前記少なくとも１つのコンテキスト変数が、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数
のうちの少なくとも１つのものを表している、
請求項２５に記載の方法。
【請求項２７】
前記少なくとも２つの検査オブジェクトが、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している、
請求項２０に記載の方法。
【請求項２８】
さらに、
前記ユーザを検査するオペレーションにおいて引き続いて使用するために、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
前記コンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加、
変更、および、
削除
のうちの１つを実行することを受容するステップ
を備えた、
請求項２０に記載の方法。
【請求項２９】
ユーザを認証する際に使用する製品であって、
実行したときに、
その一部分が少なくとも２つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップと、
少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査するステップと
を実現する少なくとも１つのプログラムを含むマシン読み取り可能な媒体
を備えた
製品。
【請求項３０】
前記ユーザを検査する前記ステップを、前記少なくとも２つの検査オブジェクトに個別に対応する少なくとも２つの検査エンジンによって実行する、
請求項２９に記載の製品。
【請求項３１】
前記少なくとも２つの検査エンジンが前記少なくとも２つの検査オブジェクトと少なくとも１つのユーザ・モデルとを個別に比較する、
請求項３０に記載の製品。
【請求項３２】
前記少なくとも１つのユーザ・モデルが前記少なくとも２つの検査オブジェクトにわたって共用されている、
請求項３０に記載の製品。
【請求項３３】
前記少なくとも１つのユーザ・モデルを、ユーザを登録するセッションに合わせて事前に作成する、
請求項３２に記載の製品。
【請求項３４】
前記コンテキストが、前記ユーザを検査する前記ステップに関連付けられた少なくとも１つの変数を備えている、
請求項３２に記載の製品。
【請求項３５】
前記少なくとも１つのコンテキスト変数が、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数
のうちの少なくとも１つのものを表している、
請求項３２に記載の製品。
【請求項３６】
前記少なくとも２つの検査オブジェクトが、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している、
請求項２９に記載の製品。
【請求項３７】
さらに、
前記ユーザを検査するオペレーションにおいて引き続いて使用するために、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
前記コンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加、
変更、および、
削除
のうちの１つを実行することを受容するステップ
を備えた、
請求項２９に記載の製品。
【請求項３８】
検査マネージャと、
前記検査マネージャに接続された検査手段と
を備え、
前記検査マネージャは、
（ｉ）前記検査手段によってユーザを検査するステップと、
（ｉｉ）引き続いてユーザを検査するために前記ユーザ検査手段をカスタマイズするステップと
を制御するオペレーションを実行する、
認証システム。
【請求項３９】
前記ユーザ検査手段をカスタマイズするオペレーションが、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
検査のコンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加するステップ、
変更するステップ、および、
削除するステップ
のうちの少なくとも１つのステップを備えている、
請求項３８に記載のシステム。
【請求項４０】
前記ユーザ検査手段をカスタマイズするオペレーションがさらに、
ユーザに特有の制約、用途に特有の制約、および取引に特有の制約のうちの少なくとも１つを処理しうるように前記ユーザ検査手段をカスタマイズするステップ
を備えている、
請求項３８に記載のシステム。
【請求項４１】
検査マネージャと、
前記検査マネージャに接続された少なくとも２つの検査エンジンと
を備え、
前記検査マネージャは、
（ｉ）その少なくとも一部分が少なくとも２つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップと、
（ｉｉ）前記少なくとも２つの検査エンジンを使用し、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査するステップと
を制御するオペレーションを実行する、
認証システム。
【請求項４２】
前記検査ポリシー・マネージャがさらに、
少なくとも１つの新たな検査エンジンに対して、
付加、
変更、および、
削除
のうちの少なくとも１つを行うように制御するオペレーションを実行する、
請求項４１に記載のシステム。
【請求項４３】
前記少なくとも１つの新たな検査エンジンが既存の検査オブジェクトおよび新たな検査オブジェクトのうちの一方に対応している、
請求項４２に記載のシステム。
【請求項４４】
前記検査マネージャと前記少なくとも２つの検査エンジンのうちの少なくとも１つとがネットワークを介して接続されている、
請求項４１に記載のシステム。
【請求項４５】
前記検査マネージャと前記少なくとも２つの検査エンジンとが検査サーバに関連付けられており、
さらに、
前記認証システムが、前記検査サーバと通信するクライアント装置を備えている、
請求項４１に記載のシステム。
【請求項４６】
前記コンテキストを、前記クライアント装置および前記検査サーバがアクセスしうる中央部に格納しうるようして、前記クライアント装置および前記検査サーバが状態不保持の通信に参加しうるようにした、
請求項４５に記載のシステム。
【請求項４７】
前記認証システムがさらに、
前記検査ポリシーと、前記少なくとも２つの検査ポリシーの仕様と、ユーザ認証を実行するのに使用するユーザ・モデルとのうちの少なくとも１つを格納するデータ記憶手段
を備えた、
請求項４１に記載のシステム。
【請求項４８】
前記データ記憶手段が前記検査マネージャと、前記少なくとも２つの検査エンジンと、前記検査マネージャに接続されたクライアント装置とのうちの１つにとってアクセス可能である、
請求項４７に記載のシステム。
【請求項４９】
少なくとも１つのクライアント装置によって動作するユーザ認証システムであって、
前記少なくとも１つのクライアントに接続された少なくとも１つのサーバ
を備え、
前記少なくとも１つのサーバが前記少なくとも１つのクライアント装置からユーザの入力を取得し、前記ユーザの入力の少なくとも一部分に基づいて前記ユーザを検査し、
さらに、
前記少なくとも１つのクライアント装置と前記少なくとも１つのサーバとの間の通信インタフェースがＸＭＬ（Extensible Markup Language）によって実装されている、
システム。
【請求項５０】
前記少なくとも１つのクライアント装置と前記少なくとも１つのサーバとの間の通信インタフェースが検査セッション、登録セッション、および管理セッションのうちの１つをサポートしている、
請求項４９に記載のシステム。
【請求項５１】
少なくとも１つの検査ポリシーと、
前記少なくとも１つの検査ポリシーに従ってユーザを検査するオペレーションを実行する検査手段と
を備え、
前記少なくとも１つの検査ポリシーが前記検査手段によってステート・マシンとして実装可能である、
認証システム。
【請求項５２】
前記ステート・マシンが終端状態と判定を出力する中間状態とのうちの少なくとも１つを備えている、
請求項５１に記載のシステム。
【請求項５３】
前記少なくとも１つの検査ポリシーが動的である、
請求項５１に記載のシステム。
【請求項５４】
前記少なくとも１つの検査ポリシーが、少なくとも１つの異なる状態へ分岐しうる少なくとも１つの条件に基づいている、
請求項５１に記載のシステム。
【請求項５５】
少なくとも１つの検査オブジェクトと、
前記少なくとも１つの検査オブジェクトによってユーザを検査するオペレーションを実行する検査手段と
を備え、
前記少なくとも１つの検査オブジェクトが、
（ｉ）関連する検査エンジンを使用しない検査に使用しうる状態、
（ｉｉ）前記少なくとも１つの検査オブジェクトに関するデータを用いて事前に登録する必要がない状態、
（ｉｉｉ）動的である状態、
（ｉｖ）暗黙である状態、
（ｖ）別のオブジェクトから少なくとも１つのプロパティを継承しうる状態、
（ｖｉ）複数の入力を特徴としている状態、
（ｖｉｉ）重み付けられている状態、および、
（ｖｉｉｉ）操作可能である状態、
のうちの少なくとも１つの状態にある、
認証システム。
【請求項５６】
前記検査オブジェクトはそれに関連付けられた難度値を有する、
請求項５５に記載のシステム。
【請求項５７】
前記検査手段に関連付けられた検査ポリシーが前記難度値を使用する、
請求項５６に記載のシステム。
【請求項５８】
少なくとも１つのユーザ・モデルと、
前記少なくとも１つのユーザ・モデルによってユーザを検査するオペレーションを実行する検査手段と
を備え、
前記少なくとも１つのユーザ・モデルが、
（ｉ）ユーザの少なくとも１つの選好を表している状態、および、
（ｉｉ）引き続くユーザの検査において使用するために変更しうる状態、
のうちの少なくとも１つの状態にある、
認証システム。
【請求項５９】
検査マネージャと、
前記検査マネージャに接続された少なくとも１つの検査エンジンと
を備え、
前記検査マネージャが、
（ｉ）その少なくとも一部分が少なくとも１つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップと、
（ｉｉ）外部ソースに関連付けられたデータを取得するステップと、
（ｉｉｉ）前記少なくとも１つの検査オブジェクトに基づいて前記少なくとも１つの検査エンジンを使用するとともに前記外部ソースの前記データを使用し、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトと前記外部ソースの前記データとにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記ユーザを検査するステップと
を制御するオペレーションを実行する、
認証システム。
【請求項６０】
少なくとも１つの検査ポリシーと、
前記少なくとも１つの検査ポリシーに従ってユーザを検査するオペレーションを実行する検査手段と
を備え、
前記少なくとも１つの検査ポリシーが少なくとも１つの検査オブジェクト、少なくとも１つのコンテキスト変数、および外部ソースのデータに基づいている、
認証システム。
【請求項６１】
ユーザを認証する自動化された方法であって、
前記検査手段によって前記ユーザを検査するステップと、
引き続くユーザの検査のために前記ユーザ検査手段をカスタマイズするステップと
を備えた
方法。
【請求項６２】
ユーザを認証する自動化された方法であって、
ユーザの入力を取得するステップと、
少なくとも１つの検査ポリシーに従い前記ユーザの前記入力の少なくとも一部分に基づいて前記ユーザを検査するステップと
を備え、
前記少なくとも１つの検査ポリシーがステート・マシンとして実装可能である、
方法。
【請求項６３】
検査する前記ステップがさらに、
中間判定および最終判定のうちの少なくとも１つを出力するステップ
を備えた、
請求項６２に記載の方法。
【請求項６４】
ユーザを認証する自動化された方法であって、
その一部分が少なくとも１つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップステップと、
前記少なくとも１つの検査オブジェクトによって前記ユーザを検査するステップであって、
前記少なくとも１つの検査オブジェクトが、
（ｉ）関連する検査エンジンを使用しない検査に使用しうる状態、
（ｉｉ）前記少なくとも１つの検査オブジェクトに関するデータを用いて事前
に登録する必要がない状態、
（ｉｉｉ）動的である状態、
（ｉｖ）暗黙である状態、
（ｖ）別のオブジェクトから少なくとも１つのプロパティを継承しうる状態、
（ｖｉ）複数の入力を特徴としている状態、
（ｖｉｉ）重み付けられている状態、および、
（ｖｉｉｉ）操作可能である状態、
のうちの少なくとも１つの状態にある、
ステップと
を備えた
方法。
【請求項６５】
ユーザを認証する自動化された方法であって、
少なくとも１つのユーザ・モデルを取得するステップと、
前記少なくとも１つのユーザ・モデルによってユーザを検査するステップであって、
前記少なくとも１つのユーザ・モデルが、
（ｉ）ユーザの少なくとも１つの選好を表している状態、および、
（ｉｉ）引き続くユーザの検査において使用するために変更しうる状態、
のうちの少なくとも１つの状態にある、
ステップと
を備えた
方法。
【請求項６６】
ユーザを認証する自動化された方法であって、
少なくとも１つの検査ポリシーを取得するステップと、
前記少なくとも１つの検査ポリシーに従ってユーザを検査するステップであって、前記少なくとも１つの検査ポリシーが少なくとも１つの検査オブジェクト、少なくとも１つのコンテキスト変数、および外部ソースのデータに基づいている、ステップと
を備えた
方法。
【請求項１】
ユーザ認証を行う際に使用する装置であって、
少なくとも１つのプロセッサであって、
（ｉ）その少なくとも一部分が少なくとも２つの検査オブジェクトに関連付けられている、ユーザの入力を取得するオペレーションを実行し、かつ、
（ｉｉ）少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査するオペレーションを実行する
少なくとも１つのプロセッサと、
前記ユーザの入力のうちの少なくとも１つと前記ユーザを検査するオペレーションに付随する結果とを格納する、前記少なくとも１つのプロセッサに接続されたメモリと
を備えた
装置。
【請求項２】
前記少なくとも１つのプロセッサがさらに、前記少なくとも２つの検査オブジェクトに個別に対応する少なくとも２つの検査プロセスによって前記ユーザを検査するオペレーションを実行する、
請求項１に記載の装置。
【請求項３】
前記少なくとも２つの検査プロセスが前記少なくとも２つの検査オブジェクトと少なくとも１つのユーザ・モデルとを個別に比較する、
請求項２に記載の装置。
【請求項４】
前記少なくとも１つのユーザ・モデルが、前記メモリに事前に格納されているとともに、前記少なくとも１つのプロセッサによってアクセス可能である、
請求項３に記載の装置。
【請求項５】
前記少なくとも１つのユーザ・モデルが、前記少なくとも２つの検査オブジェクトにわたって共用されている、
請求項４に記載の装置。
【請求項６】
前記少なくとも１つのユーザ・モデルがＸＭＬ（Extensible Markup Language) で実装されている、
請求項３に記載の装置。
【請求項７】
前記少なくとも１つの検査ポリシーが、前記メモリに事前に格納されているとともに、前記少なくとも１つのプロセッサによってアクセス可能である、
請求項１に記載の装置。
【請求項８】
前記少なくとも１つの検査ポリシーがＸＭＬ（Extensible Markup Language) で実装されている、
請求項１に記載の装置。
【請求項９】
前記コンテキストが、前記ユーザを検査するオペレーションに関連付けられた少なくとも１つの変数を備えている、
請求項１に記載の装置。
【請求項１０】
前記少なくとも１つのコンテキスト変数が、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数
のうちの少なくとも１つのものを表している、
請求項９に記載の装置。
【請求項１１】
前記少なくとも２つの検査オブジェクトが、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している、
請求項１に記載の装置。
【請求項１２】
前記少なくとも１つのプロセッサがさらに、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
前記コンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加、
変更、および、
削除
のうちの少なくとも１つを行うことを受容するオペレーションを実行して、
前記ユーザを検査するオペレーションにおける引き続く使用に備えている、
請求項１に記載の装置。
【請求項１３】
少なくとも１つのクライアント装置に従って動作するユーザ認証システムであって、
前記少なくとも１つのクライアント装置に接続された少なくとも１つのサーバ
を備え、
前記少なくとも１つのサーバは前記少なくとも１つのクライアント装置からユーザの入力を取得し、
前記ユーザの入力の少なくとも一部分は少なくとも２つの検査オブジェクトに関連付けられており、
さらに、
前記少なくとも１つのサーバは、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査する、
ユーザ認証システム。
【請求項１４】
さらに、
前記ユーザは事前にデータを登録し、
前記データのうちの少なくとも一部分を用いてユーザ・モデルを作成し、
前記少なくとも１つのサーバが、前記ユーザを検査するオペレーションの間に前記少なくとも１つのユーザ・モデルを利用する、
請求項１３に記載のシステム。
【請求項１５】
前記少なくとも１つのサーバがさらに、前記ユーザを検査するオペレーションを実行する少なくとも２つの検査エンジンを備え、
前記少なくとも２つの検査エンジンは前記少なくとも２つの検査オブジェクトに個別に対応している、
請求項１３に記載のシステム。
【請求項１６】
前記コンテキストが、前記ユーザを検査するオペレーションに関連付けられた少なくとも１つの変数を備えているとともに、前記少なくとも１つのクライアント装置および少なくとも１つのサーバにおいて保持されている、
請求項１３に記載のシステム。
【請求項１７】
前記少なくとも１つのコンテキスト変数が、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数のうちの少なくとも１つのものを表している、
請求項１６に記載のシステム。
【請求項１８】
前記少なくとも２つの検査オブジェクトが、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している、
請求項１３に記載のシステム。
【請求項１９】
前記少なくとも１つのサーバが、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
前記コンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加、
変更、および、
削除
のうちの少なくとも１つを行うことを受容するオペレーションを実行して、
前記ユーザを検査するオペレーションにおける引き続く使用に備えている、
請求項１３に記載のシステム。
【請求項２０】
ユーザを認証する自動化された方法であって、
その一部分が少なくとも２つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップと、
少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査するステップと
を備えた
方法。
【請求項２１】
前記ユーザを検査する前記ステップを、前記少なくとも２つの検査オブジェクトに個別に対応する少なくとも２つの検査エンジンによって実行する、
請求項２０に記載の方法。
【請求項２２】
前記少なくとも２つの検査エンジンが前記少なくとも２つの検査オブジェクトと少なくとも１つのユーザ・モデルとを個別に比較する、
請求項２１に記載の方法。
【請求項２３】
前記少なくとも１つのユーザ・モデルが前記少なくとも２つの検査オブジェクトにわたって共用されている、
請求項２２に記載の方法。
【請求項２４】
前記少なくとも１つのユーザ・モデルを、ユーザを登録するセッションに合わせて事前に作成する、
請求項２２に記載の方法。
【請求項２５】
前記コンテキストが、前記ユーザを検査する前記ステップに関連付けられた少なくとも１つの変数を備えている、
請求項２０に記載の方法。
【請求項２６】
前記少なくとも１つのコンテキスト変数が、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数
のうちの少なくとも１つのものを表している、
請求項２５に記載の方法。
【請求項２７】
前記少なくとも２つの検査オブジェクトが、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している、
請求項２０に記載の方法。
【請求項２８】
さらに、
前記ユーザを検査するオペレーションにおいて引き続いて使用するために、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
前記コンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加、
変更、および、
削除
のうちの１つを実行することを受容するステップ
を備えた、
請求項２０に記載の方法。
【請求項２９】
ユーザを認証する際に使用する製品であって、
実行したときに、
その一部分が少なくとも２つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップと、
少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査するステップと
を実現する少なくとも１つのプログラムを含むマシン読み取り可能な媒体
を備えた
製品。
【請求項３０】
前記ユーザを検査する前記ステップを、前記少なくとも２つの検査オブジェクトに個別に対応する少なくとも２つの検査エンジンによって実行する、
請求項２９に記載の製品。
【請求項３１】
前記少なくとも２つの検査エンジンが前記少なくとも２つの検査オブジェクトと少なくとも１つのユーザ・モデルとを個別に比較する、
請求項３０に記載の製品。
【請求項３２】
前記少なくとも１つのユーザ・モデルが前記少なくとも２つの検査オブジェクトにわたって共用されている、
請求項３０に記載の製品。
【請求項３３】
前記少なくとも１つのユーザ・モデルを、ユーザを登録するセッションに合わせて事前に作成する、
請求項３２に記載の製品。
【請求項３４】
前記コンテキストが、前記ユーザを検査する前記ステップに関連付けられた少なくとも１つの変数を備えている、
請求項３２に記載の製品。
【請求項３５】
前記少なくとも１つのコンテキスト変数が、
（ｉ）ユーザの名前、
（ｉｉ）前記少なくとも１つの検査ポリシーの現在の状態、
（ｉｉｉ）前記少なくとも２つの検査オブジェクトの履歴、
（ｉｖ）用途に特有の要件、
（ｖ）ユーザに特有の要件、および、
（ｖｉ）物理変数または論理変数
のうちの少なくとも１つのものを表している、
請求項３２に記載の製品。
【請求項３６】
前記少なくとも２つの検査オブジェクトが、前記ユーザのアイデンティティ（ＩＤ）、前記ユーザの知識、および前記ユーザの所有物を検査するのに使用しうる、少なくとも１つのオブジェクトの型を表している、
請求項２９に記載の製品。
【請求項３７】
さらに、
前記ユーザを検査するオペレーションにおいて引き続いて使用するために、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
前記コンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加、
変更、および、
削除
のうちの１つを実行することを受容するステップ
を備えた、
請求項２９に記載の製品。
【請求項３８】
検査マネージャと、
前記検査マネージャに接続された検査手段と
を備え、
前記検査マネージャは、
（ｉ）前記検査手段によってユーザを検査するステップと、
（ｉｉ）引き続いてユーザを検査するために前記ユーザ検査手段をカスタマイズするステップと
を制御するオペレーションを実行する、
認証システム。
【請求項３９】
前記ユーザ検査手段をカスタマイズするオペレーションが、
検査ポリシー、
検査オブジェクトの型、
ユーザ・モデル、および、
検査のコンテキストに付随する変数
のうちの少なくとも１つのものに対して、
追加するステップ、
変更するステップ、および、
削除するステップ
のうちの少なくとも１つのステップを備えている、
請求項３８に記載のシステム。
【請求項４０】
前記ユーザ検査手段をカスタマイズするオペレーションがさらに、
ユーザに特有の制約、用途に特有の制約、および取引に特有の制約のうちの少なくとも１つを処理しうるように前記ユーザ検査手段をカスタマイズするステップ
を備えている、
請求項３８に記載のシステム。
【請求項４１】
検査マネージャと、
前記検査マネージャに接続された少なくとも２つの検査エンジンと
を備え、
前記検査マネージャは、
（ｉ）その少なくとも一部分が少なくとも２つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップと、
（ｉｉ）前記少なくとも２つの検査エンジンを使用し、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記少なくとも２つの検査オブジェクトに基づいて前記ユーザを検査するステップと
を制御するオペレーションを実行する、
認証システム。
【請求項４２】
前記検査ポリシー・マネージャがさらに、
少なくとも１つの新たな検査エンジンに対して、
付加、
変更、および、
削除
のうちの少なくとも１つを行うように制御するオペレーションを実行する、
請求項４１に記載のシステム。
【請求項４３】
前記少なくとも１つの新たな検査エンジンが既存の検査オブジェクトおよび新たな検査オブジェクトのうちの一方に対応している、
請求項４２に記載のシステム。
【請求項４４】
前記検査マネージャと前記少なくとも２つの検査エンジンのうちの少なくとも１つとがネットワークを介して接続されている、
請求項４１に記載のシステム。
【請求項４５】
前記検査マネージャと前記少なくとも２つの検査エンジンとが検査サーバに関連付けられており、
さらに、
前記認証システムが、前記検査サーバと通信するクライアント装置を備えている、
請求項４１に記載のシステム。
【請求項４６】
前記コンテキストを、前記クライアント装置および前記検査サーバがアクセスしうる中央部に格納しうるようして、前記クライアント装置および前記検査サーバが状態不保持の通信に参加しうるようにした、
請求項４５に記載のシステム。
【請求項４７】
前記認証システムがさらに、
前記検査ポリシーと、前記少なくとも２つの検査ポリシーの仕様と、ユーザ認証を実行するのに使用するユーザ・モデルとのうちの少なくとも１つを格納するデータ記憶手段
を備えた、
請求項４１に記載のシステム。
【請求項４８】
前記データ記憶手段が前記検査マネージャと、前記少なくとも２つの検査エンジンと、前記検査マネージャに接続されたクライアント装置とのうちの１つにとってアクセス可能である、
請求項４７に記載のシステム。
【請求項４９】
少なくとも１つのクライアント装置によって動作するユーザ認証システムであって、
前記少なくとも１つのクライアントに接続された少なくとも１つのサーバ
を備え、
前記少なくとも１つのサーバが前記少なくとも１つのクライアント装置からユーザの入力を取得し、前記ユーザの入力の少なくとも一部分に基づいて前記ユーザを検査し、
さらに、
前記少なくとも１つのクライアント装置と前記少なくとも１つのサーバとの間の通信インタフェースがＸＭＬ（Extensible Markup Language）によって実装されている、
システム。
【請求項５０】
前記少なくとも１つのクライアント装置と前記少なくとも１つのサーバとの間の通信インタフェースが検査セッション、登録セッション、および管理セッションのうちの１つをサポートしている、
請求項４９に記載のシステム。
【請求項５１】
少なくとも１つの検査ポリシーと、
前記少なくとも１つの検査ポリシーに従ってユーザを検査するオペレーションを実行する検査手段と
を備え、
前記少なくとも１つの検査ポリシーが前記検査手段によってステート・マシンとして実装可能である、
認証システム。
【請求項５２】
前記ステート・マシンが終端状態と判定を出力する中間状態とのうちの少なくとも１つを備えている、
請求項５１に記載のシステム。
【請求項５３】
前記少なくとも１つの検査ポリシーが動的である、
請求項５１に記載のシステム。
【請求項５４】
前記少なくとも１つの検査ポリシーが、少なくとも１つの異なる状態へ分岐しうる少なくとも１つの条件に基づいている、
請求項５１に記載のシステム。
【請求項５５】
少なくとも１つの検査オブジェクトと、
前記少なくとも１つの検査オブジェクトによってユーザを検査するオペレーションを実行する検査手段と
を備え、
前記少なくとも１つの検査オブジェクトが、
（ｉ）関連する検査エンジンを使用しない検査に使用しうる状態、
（ｉｉ）前記少なくとも１つの検査オブジェクトに関するデータを用いて事前に登録する必要がない状態、
（ｉｉｉ）動的である状態、
（ｉｖ）暗黙である状態、
（ｖ）別のオブジェクトから少なくとも１つのプロパティを継承しうる状態、
（ｖｉ）複数の入力を特徴としている状態、
（ｖｉｉ）重み付けられている状態、および、
（ｖｉｉｉ）操作可能である状態、
のうちの少なくとも１つの状態にある、
認証システム。
【請求項５６】
前記検査オブジェクトはそれに関連付けられた難度値を有する、
請求項５５に記載のシステム。
【請求項５７】
前記検査手段に関連付けられた検査ポリシーが前記難度値を使用する、
請求項５６に記載のシステム。
【請求項５８】
少なくとも１つのユーザ・モデルと、
前記少なくとも１つのユーザ・モデルによってユーザを検査するオペレーションを実行する検査手段と
を備え、
前記少なくとも１つのユーザ・モデルが、
（ｉ）ユーザの少なくとも１つの選好を表している状態、および、
（ｉｉ）引き続くユーザの検査において使用するために変更しうる状態、
のうちの少なくとも１つの状態にある、
認証システム。
【請求項５９】
検査マネージャと、
前記検査マネージャに接続された少なくとも１つの検査エンジンと
を備え、
前記検査マネージャが、
（ｉ）その少なくとも一部分が少なくとも１つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップと、
（ｉｉ）外部ソースに関連付けられたデータを取得するステップと、
（ｉｉｉ）前記少なくとも１つの検査オブジェクトに基づいて前記少なくとも１つの検査エンジンを使用するとともに前記外部ソースの前記データを使用し、少なくとも１つの検査ポリシーに従い、前記少なくとも２つの検査オブジェクトと前記外部ソースの前記データとにわたって共用されているコンテキストに基づいてオペレーションを行うことにより、前記ユーザを検査するステップと
を制御するオペレーションを実行する、
認証システム。
【請求項６０】
少なくとも１つの検査ポリシーと、
前記少なくとも１つの検査ポリシーに従ってユーザを検査するオペレーションを実行する検査手段と
を備え、
前記少なくとも１つの検査ポリシーが少なくとも１つの検査オブジェクト、少なくとも１つのコンテキスト変数、および外部ソースのデータに基づいている、
認証システム。
【請求項６１】
ユーザを認証する自動化された方法であって、
前記検査手段によって前記ユーザを検査するステップと、
引き続くユーザの検査のために前記ユーザ検査手段をカスタマイズするステップと
を備えた
方法。
【請求項６２】
ユーザを認証する自動化された方法であって、
ユーザの入力を取得するステップと、
少なくとも１つの検査ポリシーに従い前記ユーザの前記入力の少なくとも一部分に基づいて前記ユーザを検査するステップと
を備え、
前記少なくとも１つの検査ポリシーがステート・マシンとして実装可能である、
方法。
【請求項６３】
検査する前記ステップがさらに、
中間判定および最終判定のうちの少なくとも１つを出力するステップ
を備えた、
請求項６２に記載の方法。
【請求項６４】
ユーザを認証する自動化された方法であって、
その一部分が少なくとも１つの検査オブジェクトに関連付けられている、ユーザの入力を取得するステップステップと、
前記少なくとも１つの検査オブジェクトによって前記ユーザを検査するステップであって、
前記少なくとも１つの検査オブジェクトが、
（ｉ）関連する検査エンジンを使用しない検査に使用しうる状態、
（ｉｉ）前記少なくとも１つの検査オブジェクトに関するデータを用いて事前
に登録する必要がない状態、
（ｉｉｉ）動的である状態、
（ｉｖ）暗黙である状態、
（ｖ）別のオブジェクトから少なくとも１つのプロパティを継承しうる状態、
（ｖｉ）複数の入力を特徴としている状態、
（ｖｉｉ）重み付けられている状態、および、
（ｖｉｉｉ）操作可能である状態、
のうちの少なくとも１つの状態にある、
ステップと
を備えた
方法。
【請求項６５】
ユーザを認証する自動化された方法であって、
少なくとも１つのユーザ・モデルを取得するステップと、
前記少なくとも１つのユーザ・モデルによってユーザを検査するステップであって、
前記少なくとも１つのユーザ・モデルが、
（ｉ）ユーザの少なくとも１つの選好を表している状態、および、
（ｉｉ）引き続くユーザの検査において使用するために変更しうる状態、
のうちの少なくとも１つの状態にある、
ステップと
を備えた
方法。
【請求項６６】
ユーザを認証する自動化された方法であって、
少なくとも１つの検査ポリシーを取得するステップと、
前記少なくとも１つの検査ポリシーに従ってユーザを検査するステップであって、前記少なくとも１つの検査ポリシーが少なくとも１つの検査オブジェクト、少なくとも１つのコンテキスト変数、および外部ソースのデータに基づいている、ステップと
を備えた
方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２００６−５０５０５１（Ｐ２００６−５０５０５１Ａ）
【公表日】平成１８年２月９日（２００６．２．９）
【国際特許分類】
【出願番号】特願２００４−５４９９２２（Ｐ２００４−５４９９２２）
【出願日】平成１５年７月２１日（２００３．７．２１）
【国際出願番号】ＰＣＴ／ＵＳ２００３／０２２６８６
【国際公開番号】ＷＯ２００４／０４２５４０
【国際公開日】平成１６年５月２１日（２００４．５．２１）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成１８年２月９日（２００６．２．９）
【国際特許分類】
【出願日】平成１５年７月２１日（２００３．７．２１）
【国際出願番号】ＰＣＴ／ＵＳ２００３／０２２６８６
【国際公開番号】ＷＯ２００４／０４２５４０
【国際公開日】平成１６年５月２１日（２００４．５．２１）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]