JP2003526857A - パーソナルデジタル識別を用いてオンライン不正を低減させる方法および装置 - Google Patents

Abstract

(57)【要約】 【解決手段】分散したパーソナルデジタル識別（ＰＤＩ）システムおよびアーキテクチャは、トランザクションを許し、および／またはオンラインサービスや他のネットワークサービスへのアクセスを可能にするに先立って、生体情報データまたは他のトークンを用いて即座に個人を確認する。アーキテクチャは、個人を特定するために必要なテンプレートデータへのアクセスを持つサーバを含み、認証されたルートに対する処理キャパシティは、適切なダウンストリームエンティティ（インターネットサービスプロバイダ、クレジットカード会社など）を要求する。サーバは異なるネットワーク方式によってリクエストしているユーザに接続しており、クライアント／サーバアーキテクチャを形成する。サーバとクライアントはそれぞれ別個のサブシステムを有し、これらのサブシステムは異なるレベルの認証サービスをシステムのユーザに対して提供する。

Description

【発明の詳細な説明】

【０００１】

【関連出願のクロスリファレンス】

本発明は、“パーソナルデジタル識別を用いてオンライン不正を低減させる方
法および装置”と題され、２０００年３月８日に出願された、米国特許出願番号
第６０／１８７，９２７号に基づいて優先権を主張する。第６０／１８７，９２
７号出願も本発明の譲受人に所有され、参照によりここに取り込まれる。

【０００２】

【発明の属する技術分野】

本発明はデータ通信およびＥコマースに関し、特に、ビジネストゥコンシュー
マー（Ｂ２Ｃ）、ビジネストゥビジネス（Ｂ２Ｂ）、およびパーソナルデジタル
識別（ＰＤＩ）技術を用いる他のトランザクションサービスの不正使用を検出し
て低減させる方法と装置に関する。

【０００３】

【従来の技術】

インターネットの使用の増加や、これにともなうＥコマースおよび他のビジネ
ストゥコンシューマー（Ｂ２Ｃ）トランザクションが増加するにつれ、識別を示
すために個人が存在することなく行われる商品やサービスの購入もまた増加する
。オンラインアカウントへのアクセスも、アクセスしているユーザを確認したり
あるいは認証のために、個人が存在することなく許可される。

【０００４】 懸念されるＢ２Ｃトランザクションの問題の１つは、クレジットカードの不正
である。ハッカー、詐欺師、および犯罪者は、従来の認証方法における弱いリン
クを常に見つけ出す。なぜなら、カード発行銀行および消費者を不正から守るた
めの多くの方法が開発されても、それらの方法では実効性のない保護が提供され
るだけだからである。認証されるものは個人ではなく、既に知られているか、所
有されている情報である。したがって、業界がリークを１つ止めた後でも別のリ
ークが発見されて悪用されてしまう。

【０００５】 懸念されつつあるＢ２Ｃの別の問題は、企業のリソースを従業員が不正使用す
ることである。多くの企業において、従業員が企業の設備を使用してインターネ
ットにアクセスすることが容易である。すべての従業員がインターネットサービ
スを不正使用するわけではないが、すべての従業員の累積的な使用が結果的に多
くの時間およびリソースを雇用者から取り上げることになる。

【０００６】 これに関連して、保護者にとっては子どものオンラインアクティビティの監視
が関心事である。さまざまな“ペアレントコントロール”ソフトウェア製品が売
られていて利用可能だが、多くはエンドユーザのＰＣに備えられていて、未成年
者または保護者のどちらかによっていつでもターンオフにすることができ、他の
ソフトウェアアプリケーションによって監視を免れることもできる。

【０００７】 他の大きな問題は、加入／アカウントの不正である。アカウント情報を個人間
で交換することによって、インターネットサービスプロバイダ（ＩＳＰ）が受け
取る収益が減少している。加入料の不払いによる収益の減少に加えて、ＩＳＰサ
ービスにアクセスする正規および無許可のユーザをサポートするための付加的な
容量に対する要求が現れる。

【０００８】 無許可の“加入者”からの収益の減少に加えて、ＩＳＰは他の問題を抱えてい
る。多くのＩＳＰがウェブページをホスト管理している。１つの潜在的な問題は
、侵入者がホストへのアクセスを得ると、侵入者はホストのウェブページ上の情
報を変更することができ、これによりＩＳＰにさらなる責任が課されるおそれが
あることである。さらに、侵入者は公開のウェブサイトを企業の内部ファイルへ
の侵入地点として利用して、競争上慎重な取扱を要する経営情報または、プライ
バシー法で保護される企業の顧客および／または従業員に関する情報のような機
密情報へのアクセスを得ることができる。このことは、有線会社でもあるＩＳＰ
について特に深刻であり、これらの会社は大量の顧客データを保持している。ウ
ェブサイトを利用して侵入者の本当のアイデンティティを隠すことによって、他
のコンピュータシステムへの無許可のアクセスを得る意図で侵入者がＩＳＰウェ
ブサイトに入るとき、“トロイの木馬”として言及される関連した問題が生じる
。侵入者がＩＳＰのウェブサイトから攻撃を開始する場合に、再び、潜在的なＩ
ＳＰの責任が生じる。ＩＳＰが担うことのできる抑制のための努力は、一般常識
的な注意から疑わしいアクティビティをＦＢＩに報告するまでの範囲におよぶ。
より従来的な方法には、コンピュータネットワーク内の監視トレイルの使用、監
視していることを無許可のユーザに警告するログインバナーの告示、キーストロ
ークのレベルの監視、発信者の識別、内部パスワードの設定およびパスワードの
頻繁な変更、各ＰＣへのアンチウイルスソフトウェアのインストール、アクセス
を制限する“ファイアウォール”ソフトウェアのインストール、損傷を受けたか
、または変更されたファイルのバックアップ、古いバックアップを整備すること
によるオリジナルのステータスの実証、ある者に対して不正なアクティビティの
潜在的な証明書を獲得する一人を指名すること、およびテープバックアップとプ
リントアウトを得る手続きの設定が含まれる場合がある。

【０００９】 Ｂ２Ｃトランザクションに加えて、ビジネストゥビジネス（Ｂ２Ｂ）トランザ
クションは、個人がかかわるアクティビティの有効性を認証する場合に同じ問題
が多く生じる。企業または個人のデジタル証明書およびパスワード／個人識別番
号（ＰＩＮ）が現在配布されているが、不正手段を用いれば、共有し悪用するこ
とができる。

【００１０】

【発明が解決しようとする課題】

不正を低減させる従来的な方法のすべてには欠点や限界がある。まず、ファイ
アウォールや他のログインやパスワードは、泥棒がすでにアカウント情報やパス
ワードを知っていたり、あるいはデジタル証明書を有している場合には、無許可
アクセスに対してプロテクトしない。同様に、無許可のユーザが発見されて告発
される場合には、ポストホックな不正検出プロシージャのみが有効である。

【００１１】 したがって、リクエストしている個人が知られていないか、識別を提供するた
めに物理的に存在していない場合に、トランザクションベースの不正を未然に低
減する方法および装置に対する需要が残っている。

【００１２】

【課題を解決するための手段】

一般的に本発明は、保証された環境におけるシステムに前もって提供された既
知のテンプレートを生体情報データ、および／またはプロファイルと比較するこ
とによって、個人または機関が行うトランザクションを認証する方法および装置
を提供する。

【００１３】 トランザクションの認証を達成できない場合、連続するアクションを決定する
ために装置のビジネスルールが用いられる。

【００１４】 本発明の１つの観点にしたがうと、フィナンシャルリソースや他のリソースへ
の無許可アクセスを減らしたり避けたりするために、本発明は、装置プロファイ
リングと生体情報証明書の比較を利用して、商人と消費者の両方を検出して制御
する。適応学習技術によって、本発明を利用して、各消費者／商人に対してダイ
ナミックプロファイルが作成され、および／または更新される。装置のアルゴリ
ズムは、購入パターンや支払方法、購入場所および購入者、ならびにプロファイ
ルを作成する他のさまざまなエレメントのようなトランザクションデータベクト
ルを用いる。履歴プロファイルおよび現トランザクションは、認証の方法を決定
するために用いられる。システムルールは、サービスへのアクセスを認証／許可
するために、時刻、曜日、ログイン場所、または他の設定された基準のような、
満たさなければならない条件を要求する。前もって設定されたビジネスルールお
よびトランザクションの認証のために決定された要求にしたがって、生体情報の
比較、デジタルコードの一致、これらの組み合わせ、または他の方法が行われる
。

【００１５】

【発明の実施の形態】

添付の図面とともに以下の詳細な説明を検討すれば、本発明を実施する最も適
した形態にしたがった本発明のこれらの目的および利点、ならびに他の目的およ
び利点が当業者に明らかになるだろう。

【００１６】 図１は本発明の全体的な構成を示している。ＰＤＩシステム１００は、クライ
アント１０２を使用しインターネット１０４、イントラネット／エクストラネッ
ト環境１０６、および専用または特定通信回線１０８のようなルートを通じてリ
ソースにアクセスしようとする者と対話する。本発明の１つの観点にしたがうと
、時としてシステム１００は、そのような者に対しサービスへのアクセスを許可
するかまたはそのサービスを介したトランザクションを認める前に、指紋または
トークンのような固有の個人識別情報１１０を提供するよう要求する。これによ
り、無許可の個人による不正や悪用から消費者とプロバイダが一様に保護される
。

【００１７】 図１に示すアクセスルート１０４、１０６、および１０８はこれらに限定され
るものではなく、例として示されることを意図している。これらのタイプのアク
セスのすべてが含まれる必要はなく、本発明の概念の範囲内で他のタイプのアク
セスルートが加えられてもよいことが当業者によって理解されるだろう。さらに
、本発明によって他のサービスが提供され、および／または制御されることが可
能であるが、図１に示すように、インターネット１０４のアクセスサービスには
、例えば、オンライン投票、Ｅコマース、オンラインバンキング、オンライント
レーディング、オークション、プレミアムサービス、およびアクセス制御が含ま
れてもよい。イントラネット／エクストラネット環境１０６のアクセスサービス
には、例えば、コーポレートアクセス制御、リソース制御、トランザクションア
カウンタビリティ、トランザクション非レフュータビリティ、ビジネストランザ
クション、フィナンシャルトランザクションが含まれてもよい。専用または特定
通信回線１０８のアクセスサービスには、例えば、現金自動預払機（ＡＴＭ）、
販売時点情報管理システム（ＰＯＳ）端末、抽選端末、資金譲渡端末、および政
府省庁の端末が含まれてもよい。一般的に、識別認証がなされることが望ましい
他のタイプのサービスおよびアクセスルートに対して本発明の原理を拡張するこ
とができ、このことは当業者によって理解されるだろう。

【００１８】 以下でより詳細に説明されるように、従来的な方法では、ポストホック人工知
能またはトラッキングプロシージャを用いて、アカウントがいつ不正または異常
な行動と潜在的に関連するかが判断される。これに対し、本発明のＰＤＩシステ
ム１００では、判断する場合にも、不正行動の検出と識別確認方法が組み合わせ
て用いられ、サービスからの購入、またはサービスへのアクセスが前もって確認
される。例えば、銀行が発行したクレジットカードを用いてインターネットを通
じて物を購入するときには、単にアカウント情報だけではユーザを確認できない
ので、常にＰＤＩ認証が要求される場合がある。あるいは、ＰＤＩシステム１０
０は、消費者に関連した既知の購入場所（ウェブサイト）のリストを生成するこ
とができる。それらのサイトが連続したトランザクションで利用されるときには
、消費者はＰＤＩを入力するよう促されることはない。その行動が消費者の現プ
ロファイルの一部となっているからである。対照的に、消費者のプロファイルの
一部となっていないサイトで消費者が購入トランザクションを開始した場合には
、クレジットカードがその保持者の所有であることを確認・照合するために、消
費者は適切なＰＤＩ認証を入力するよう促される。

【００１９】 ＰＤＩシステム１００は、消費者の自己のＰＤＩプロファイルに加えてビジネ
スルール（すなわち、制約条件）を維持する。特定のドメインのセキュリティ要
件を満たすために、企業（例えば、カード発行銀行、インターネットサービスプ
ロバイダ（ＩＳＰ）または企業のイントラネット）のニーズに基づいて、ＰＤＩ
システム管理者はこれらのビジネスルール（制約条件）を構築する。例えば、ビ
ジネスルールには、履歴プロファイルに関わらず常に認証を要求し、過去に不正
と関連があったものとして識別されているサイトとして記録されたサイトのリス
トが含まれてもよい。逆に、ビジネスルールは、特定のルール設定により、どの
サイトが認証を必要としないか、あるいは認証のみを課すのかを判断できる。こ
のようなサイトは安全であり、概して疑わしい行動と関連していないと判断され
たサイトであると考えられる。

【００２０】 ＰＤＩシステム１００はさらに、カード発行銀行および他のネットワークサー
ビスのための事前のセキュリティを提供する。例えば、アカウントが不正に使用
されている場合、不正を犯している個人は、アカウント保持者の氏名、住所、口
座番号、およびそのアカウントへのアクセスを許容するために一般的に要求され
る他の情報へアクセスするおそれがある。“アカウント”情報が複数の個人に共
有されているケースもある。例えば、ログインやパスワードを要求するサービス
に申し込む個人が、そのログインやパスワードを、そのサービスを不正に利用す
る何人かの個人と、１つの請求可能なアカウントのみで共有する可能性もある。

【００２１】 以下でより詳細に説明されるように、ＰＤＩシステム１００には、消費者とサ
ービスプロバイダを、不正使用、特に、オープンネットワークを通じたトランザ
クションから保護するＰＤＩサービスおよび方法を本発明にしたがって提供する
、ファシリティ／サーバが含まれることが好ましい。ＰＤＩシステム１００では
、固有の本人識別情報を記憶して保持するデータベースが利用される。この本人
識別情報により、ユーザおよび団体のプロファイルが構成される。コンタクト情
報、クレジットカード番号、トランザクションデータ、ビリング情報、および関
連する履歴プロファイルベクトルのような従来情報も記憶することができる。本
発明のＰＤＩシステムには、トランザクション情報を収集して処理し、提示され
たデータに基づいてユーザプロファイル、企業プロファイル、およびデフォルト
プロファイルを構築する手段がさらに含まれてもよいことが理解されるべきであ
る。

【００２２】 ＰＤＩシステム１００は通常、クライアント１０２に対して離れた場所に配置
され、クライアント１０２を操作して１０４、１０６、および１０８を通じてサ
ービスのリソースにアクセスしようとするユーザに対して、認証の集中情報源を
提供することができる。または、システムを企業内に備え、あるいは集中させて
、サービスビューロ方式で多くの施設にＰＤＩシステムを提供することもできる
。ＰＤＩシステム１００は、本発明を分かりやすくするために、インターネット
１０４、イントラネット／エクストラネット１０６、および専用回線１０８を通
じてアクセスするサービスプロバイダとは別に示されている。しかしながら、本
発明に採用された配置は、その分散した設計によって非常に柔軟に構成すること
ができることが理解されなければならない。例えば、ＰＤＩシステム１００は電
子店舗のようなサイトに直接存在していてもよく、サービスビューローファシリ
ティのような独立した場所に配置して、複数の場所からのトランザクションを処
理することも可能であり、および／またはサービスがリクエストされているサイ
トに直接備えることも可能である。

【００２３】 図２は、本発明の例示的な構成を示すブロック図である。このような構成によ
って、オンライン小売環境におけるＰＤＩシステム１００の利用が説明される。
上記の例が教示された後でも、他のタイプの環境に対して本発明の原理を拡張す
る方法が当業者に理解されるだろう。

【００２４】 図２に示すように、ＰＤＩシステム１００には複数のサブシステムと通信する
サーバ２０４としてはたらくデジタルコンピュータが含まれ、サブシステムには
、フィルタマネージャー２０８、アイデンティティマネージャー２１０、トラン
ザクションルールマネージャー２１２、ユーザプロファイルマネージャー２１４
、認証マネージャー２１６、および管理サービスマネージャー２１８が含まれる
。これらのサブシステムは１つ以上のプロセッサ上で実行するソフトウェアプロ
セスとして構成されてもよい。サーバ２０４としてはたらくデジタルコンピュー
タは、さらにデータ記憶サブシステム２２０と通信する。サーバ２０４としては
たらくデジタルコンピュータは、さらにデータ記憶サブシステム２２０と通信す
る。このことは、ローカルまたはリモートファイルシステムあるいはデータベー
ス管理システム（ＤＢＭＳ）プロセスおよびスレッドへの機能プロシージャーコ
ールおよびリクエストを使用することにより、永続的なＰＤＩシステム１００の
データへのアクセスを促進する。これらのプロセスおよびスレッドは１つ以上の
プロセッサ上で実行され、１つ以上の機械的および／またはソリッドステート記
憶装置からのデータにアクセスする。ＰＤＩシステム１００の様々なコンポーネ
ントはＬＡＮまたはＷＡＮのようなネットワークによって内部接続され、ＴＣＰ
のようなプロトコルを介して通信することができる。ＰＤＩシステム１００は、
インターネット１０４、イントラネット１０６、および／または専用回線１０８
のようなデータ通信ネットワークを通って、クライアントシステム１０２、電子
店舗２０２、およびクレジット支払いサービス２０６と通信する。以下で詳細に
説明される例示的な構成は、インターネットを介して接続されたネットワークコ
ンポーネントを想定している。

【００２５】 図２は、本発明のＰＤＩシステムアーキテクチャにおいて使用可能なクライア
ント１０２の例をさらに示す。図２でさらに示すように、クライアントシステム
１０２は、デジタルコンピュータ１０２ａ、生体情報収集装置１０２ｂ、業界標
準のウェブブラウザ１０２ｃ、およびＰＤＩクライアントソフトウェア１０２ｄ
からなる。

【００２６】 クライアント１０２はここで、適切なハードウェアおよびソフトウェアを参照
して詳しく説明される。これらのハードウェアおよびソフトウェアは、認証サー
ビスおよびトランザクションのために、ＰＤＩシステム１００にユーザ識別デー
タを提出するサーバ２０４と対話するのに必要とされる。しかしながら、クライ
アント１０２が本発明では必要とされない他の従来的な機能を含んでいてもよい
ことが明らかなので、本発明を複雑しないために、これらの従来的機能について
は説明しない。

【００２７】 デジタルコンピュータ１０２ａは、ＰＣであるか、モデムまたは他のネットワ
ークインターフェースのような、消費者はインターネットにアクセスすることが
できるデータ通信アクセス装置を含む他のタイプのコンピュータであることが好
ましい。デジタルコンピュータ１０２ａについては多くの代替が可能である。こ
れらの代替は、可能であるすべての計算装置を含み、電子コマースや他のアクセ
ストランザクションを制御して、通信ネットワークを通じて計算装置と通信させ
るために用いることができる。計算装置には、サーバ、ワークステーション、ラ
ップトップ、パームヘルドおよびハンドヘルドコンピュータが含まれるが、これ
らに限定されるものではない。

【００２８】 以下でより詳細に説明されるように、ＰＤＩクライアントソフトウェア１０２
ｄは、例えばインターネットエクスプローラまたはネットスケープコミュニケー
タなどの業界標準のブラウザ１０２ｃへのプラグインアプリケーションとして構
成される。指紋が認証生体情報データとして用いられる本発明の例では、収集さ
れたデータをＰＤＩシステム１００との通信用にフォーマットするために、生体
情報収集装置１０２ｂおよびＰＤＩクライアントソフトウェア１０２ｄには、汎
用指紋検査装置や、American Biometrics Corporation、Veridicomなどのベンダ
ーによって提供されたアプリケーションプログラムインターフェースが組み込ま
れる。

【００２９】 この例において、電子店舗２０２は、Amazon.comのようなインターネットベー
スの商業サイトである。クライアントシステム１０２は、業界標準のウェブブラ
ウザ１０２ｃによって電子店舗２０２にアクセスし、電子店舗２０２に商品やサ
ービスの購入をリクエストする。特定の電子店舗２０２は必要な購入フォームを
生成する。このフォームは消費者によって次々と記入され、電子店舗２０２によ
って処理されるよう提出される。消費者からフォームデータが提出されると、認
証判断とさらなる処理のために、電子店舗２０２は購入リクエストをＰＤＩシス
テム１００に転送する。このプロセスは以下でさらに詳しく説明される。

【００３０】 クライアント１０２、電子店舗２０２、ＰＤＩウェブイネーブルドサーバ２０
４、およびクレジット支払いサービス２０６の間の通信は、業界標準のウェブブ
ラウザおよびサーバによって構成された標準ハイパーテキスト転送プロトコル（
ＨＴＴＰ）を用いて行うことができる。ＨＴＭＬフォームデータをシステムコン
ポーネント間で転送するために、コモンゲートウェイインターフェース（ＣＧＩ
）のようなさらなる通信プロトコルが用いられてもよい。一般にＰＤＩシステム
には、ワールドワイドウェブ内で展開される、既知で、かつ受け入れられている
プロトコル標準規格が用いられるのが好ましく、例としては、Ｊａｖａ Ｓｃｒ
ｉｐｔおよび／または他のクライアントサイドのウェブベースアプリケーション
プログラムインターフェース（ＡＰＩ）およびプログラム、ならびにサーバサイ
ドのプロセスおよびＡＰＩ（例えば、Ｃ／Ｃ＋＋、ＣＧＩ、ＰＨＰ、および他の
サーバサイドＡＰＩ、またはこれらを組み合わせたもの）が挙げられる。

【００３１】 図２でさらに示されるＰＤＩシステム１００は、一般的に以下のように動作す
る。ＰＤＩウェブイネーブルドサーバ２０４は、正規の電子店舗のサイトから購
入リクエストを受け取る。リクエストはまず処理され、フィルタマネージャー２
０８を介してビジネスフィルタリングルールをトランザクションに適用させる。
このフィルタリングプロセスは、これらのトランザクションがさらなる認証を保
証するか、またはシステムによって即座に拒絶され得るかをすばやく識別する。
リクエストが評価された後、トランザクションはアイデンティティマネージャー
２１０によって処理される。アイデンティティマネージャーは、消費者を適切に
識別するために要求される情報を、ＰＤＩシステム１００が確実に利用できるよ
うにし、さらに登録情報が利用できるようにする。アイデンティティマネージャ
ー２１０が消費者のコンテクストを検索した後、トランザクションルールマネー
ジャー２１２はリクエストを処理する。例えば、トランザクションルールマネー
ジャー２１２は、リクエストを企業レベル（すなわち、ビジネス）のルールと照
らして処理し、認証が必要かどうかを判断する。必要な場合には、消費者にどの
タイプの認証が要求されるべきかを判断する。この判断の後、ユーザプロファイ
ルマネージャー２１４は、消費者に関連する履歴プロファイル情報に照らして現
リクエストを評価し、これに応じてリクエストを処理する。ユーザプロファイル
マネージャー２１４がリクエストの評価を完了すると、結果データが認証マネー
ジャー２１６に転送される。認証マネージャー２１６は、必要に応じてクライア
ント１０２とのダイアログを開始し、記憶されているテンプレートに照らして認
証データを収集して評価する。認証データが適切に収集、認証された場合には、
クレジットとデビットの許可のためにリクエストをクレジット支払いサービス２
０６に転送する。リクエストが適切に認証されなかった場合、リクエストした者
と電子店舗２０２に通知され、ＰＤＩシステム１００の判断により購入トランザ
クションは完了しない。消費者は、許可された場合にはトランザクションリクエ
ストを再び提出しなければならない。

【００３２】 管理サービスマネージャー２１８によって、システム管理者がＰＤＩシステム
１００を管理することが可能となる。管理には、例えば、（１）ＰＤＩシステム
１００のシステム管理およびＰＤＩシステム１００の加入者／消費者アカウント
に関連した属性を管理すること、（２）変更リクエストおよび問題のレポートを
生成すること、（３）オンラインＰＤＩシステム１００のドキュメンテーション
へアクセスすること、（４）ＰＤＩシステムの様々な側面を詳述するレポートを
生成すること、（５）任意の動作・維持（Ｏ＆Ｍ）アクティビティを実行して、
ＰＤＩシステム１００の状態を確認すること、および（６）ＰＤＩシステム１０
０の処理に影響を与えるルール設定を作成、修正、および削除することが含まれ
る。ルール設定の管理を除き、上記の管理機能は、システム管理の観点から殆ど
すべてのシステムに適用される一般的なものである。一般的に、ルール設定によ
って、ＰＤＩシステム１００を経由するトランザクションの受け入れまたは拒否
、あるいはこれらのトランザクションに適用される認証方法が制御される。

【００３３】 本発明の１つの例では、８つの大きなルールカテゴリがあり、管理マネージャ
ー２１８のルール機能を用いて、関連するビジネスおよび他のルールを作成、修
正、または削除することができる。８つのルールカテゴリとは、（１）しきい値
ベースの関係に関する、行動、（２）例えば、宛先アドレス！＝請求先アドレス
（ship-to-address!=billing address）のような単純なロジックに関する、ブー
ル、（３）すべてのトランザクションに適用されるプロセスと方法に関する、グ
ローバル、（４）特定のカスタマベースのアクティビティに関する、アイデンテ
ィティ、（５）特定のネットワークエレメントベースのアクティビティに関する
、ネットワーク、（６）統合トランザクションコンテンツベースのアクティビテ
ィに関する、プロファイル、（７）単一のトランザクションコンテンツベースの
アクティビティに関する、購入、および（８）統合トランザクション外形ベース
のアクティビティに関する、トランザクションである。

【００３４】 グローバルルールカテゴリによって、様々なルールカテゴリが最大限に制御さ
れる。なぜなら、その制約条件が、ＰＤＩシステムによって処理される各トラン
ザクションのいずれに対しても影響するからである。次に挙げる７つのルールの
うちの１つのみが、いかなるときもアクティブでなければならない。（１）グロ
ーバルな制約条件なし（PDI_AUTH_NONE）、制約条件が各トランザクションのい
ずれにもグローバルに適用されないことを示す。これがデフォルト選択であり、
ダウンストリームルール処理がトランザクションの最終結果を潜在的に決定でき
るようにする。（２）すべてのトランザクションを許可（PDI_AUTH_ALLOW）、各
トランザクションのいずれもが、呼びかけをすることなくシステムが流れるよう
許されることを示す。これにより、ＰＤＩシステム１００ルールおよび認証ロジ
ックが有効にターンオフされる。（３）すべてのトランザクションを拒否（PDI_
AUTH_DENY）、各トランザクションのいずれも呼びかけをすることなく拒否され
ることを示す。これにより、すべてのトランザクションがクレジット支払いサー
ビス２０６へ送られないよう有効にブロックされる。（４）常に最適に利用可能
なものを使用（PDI_AUTH_BEST）、各トランザクションのいずれに対しても、生
体情報収集装置１０２ｂの利用可能性にしたがって、クライアント１０２ａ上で
利用可能な最適の方法が用いられることを示す。（５）常に生体情報を使用（PD
I_AUTH_FP）、各トランザクションのいずれに対しても、リクエストしている個
人を認証するために生体情報サンプルが用いられることを示す。（６）常にデジ
タルコードを使用（PDI_AUTH_DC）、各トランザクションのいずれに対しても、
リクエストしている個人からのデジタルコードの一致が要求されることを示す。
（７）常に生体情報とデジタルコードを使用（PDI_AUTH_FP_DC）、リクエストし
ている個人からのデジタルコードと生体情報サンプルの両方が要求されることを
示す。

【００３５】 ネットワークルールカテゴリは、与えられたトランザクションに関連するネッ
トワークエレメントに基づき、ルールの作成について規定する。一般的に、その
ようなルールは“＜ドメイン＞が＜値＞と等しい／等しくない場合には、＜認証
＞する”のような形式となっている。ここで＜ドメイン＞は、例えば、商人のド
メイン、商人の住所、商人の名前、クライアントのドメイン、クライアントの住
所でもよい。＜値＞は、ワイルドカードを含む任意のユーザが定義した値でもよ
い。＜認証＞は、PDI_AUTH_ALLOW, PDI_AUTH_DC, PDI_AUTH_BEST, PDI_AUTH_FP,
PDI_AUTH_FP_DC, PDI_AUTH_DENYのようないずれの認証ルールでもよい。

【００３６】 プロファイルルールカテゴリは、トランザクションが要求する個人の、現アク
ティビティと履歴アクティビティの両方に関連するデータの集合に基づいて、ル
ールの作成について規定する。一般的に、そのようなルールは“＜ドメイン＞が
＜時間量＞内で＜量＞を超過する場合には、＜認証＞する”のような形式である
。ここで＜ドメイン＞は、例えば、総量、トランザクションの回数、Ｅサイトに
訪問した回数、ＩＳＰログインサイトの回数、使用されたカードの枚数、認証に
失敗した回数、固有の宛先アドレスの数、固有のコンタクトアドレスの数、固有
のビリングアドレスの数であり、＜量＞は任意のユーザ特定された数値であり、
＜時間量＞は任意のユーザ特定された時間量でもよい。

【００３７】 購入ルールカテゴリは、与えられたトランザクションの特定の購入関連データ
エレメントに基づいて、ルールの作成について規定する。そのようなルールは、
“＜ドメイン＞が＜値＞と等しい／等しくない／より大きい／より小さい場合に
、＜認証＞する”のような形式であることができる。ここで、＜ドメイン＞は、
例えば、購入量、カードタイプ、有効期限、カード番号、請求書送付先の国、宛
先の国であり、＜値＞は、ドメイン特定されたユーザの入力または選択リストの
値であってもよい。

【００３８】 トランザクションルールカテゴリは、与えられたトランザクションおよびユー
ザが定義した期限のネットワークエレメントに基づいて、ルールの作成を規定す
る。一般的に、そのようなルールは、“＜ドメイン＞が＜値＞の＜期限＞に等し
い／等しくない／より大きい／より小さい／間にある／間にない場合に、＜認証
＞する”のような形式であってもよい。ここで＜ドメイン＞は、例えば、任意の
アクティビティ、Ｅコマース、認証局、販売時点情報管理システム、インターネ
ットサービスプロバイダであり、＜期限＞は時刻（ＴＯＤ）、曜日（ＤＯＷ）、
絶対日時（ＡＤ）、ＴＯＤ＋ＡＤ、ＴＯＤ＋ＤＯＷであり、＜値＞は任意のドメ
イン特定された選択リスト値であってもよい。

【００３９】 作成されたビジネスルールおよび他のルールについては上述され、以下でもよ
り詳しく説明される。これらのルールは、少なくともトランザクションルールマ
ネージャー２１２、ユーザプロファイルマネージャー２１４、および認証マネー
ジャー２１６のデータリソース、またはこれらのマネージャーへのデータ入力と
して用いられる要求を提供する。

【００４０】 上述されたルール管理機能の特定のものまたはすべてが、クライアント１０２
を介して、システム管理者と同様にユーザにとっても利用可能であることが注意
されなければならない。例えば、企業が自己のビジネスルールを設定することに
加えて、個人も、パーソナル支出制限のようなパーソナルビジネスルールを、ト
ランザクションごとまたは累積ベースで、オンライン小売環境における特定の時
間間隔にわたって確立することができる。従アカウントに制限を設定し、主アカ
ウントによって決定されるように、システムサービスの正規ユーザを認証、制限
、および制御することもできる。例えば、親や雇用者は、子どもおよび／または
被雇用者用のサブアカウントを作成して、認証方法を要求することができる。こ
の認証方法は、支出制限、アクセス制御、場所、および関連するサブアカウント
のアクティビティを制限して制御する他のプロファイル制約に基づく。他の縦の
関係についてのサービスも、同様に、装置のプロファイル能力を強化させること
ができる。

【００４１】 クレジット支払いサービス２０６は、この例で用いられるように、必要に応じ
て、正常なトランザクション処理および／または認証に対するクレジット認証リ
クエストをＰＤＩシステム１００から受け取る。クレジット支払いサービス２０
６は、例えば、ＣｙｂｅｒＣａｓｈのようなサービスによって実行されることが
できる。サービス２０６はクレジットカードによる購入を認証し、認証された場
合には、消費者と電子店舗２０２のアカウントとの間で適切なクレジット／デビ
ットを送受信する役割を果たす。

【００４２】 図３は、本発明のＰＤＩシステム１００の利用を示す高レベルのトランザクシ
ョンフローチャートである。この例では、すべてのシステムコンポーネントとの
通信はインターネット１０４を通じて行われている。クライアント１０２ａとウ
ェブブラウザ１０２ｃを使用する消費者は、目的とする電子店舗２０２にアクセ
スして、購入トランザクションリクエストを提出する（ブロックＳ３０２）。電
子店舗２０２は、消費者のトランザクション処理リクエストを許可する（ブロッ
クＳ３０４）。電子店舗２０２は、認証判断とさらなる処理を要求する消費者の
トランザクションリクエストデータのすべてまたは一部を、ＰＤＩシステム１０
０に転送する（ブロックＳ３０６）。転送は、電子店舗によるＵＲＬ特定によっ
てなされてもよく、あるいはワールドワイドウェブ上のドキュメントおよび他の
リソースのグローバルアドレスを特定する他の方法によってなされてもよい。

【００４３】 ブロックＳ３０８で、ユーザ認証が要求されていないとＰＤＩシステム１００
が判断すると、ＰＤＩシステム１００は特定の支払いサービスを呼び出し（ブロ
ックＳ３１６）、トランザクションリクエストがクレジット支払いサービス２０
６によって転送されて、処理される。しかしながら、認証が要求される場合には
、クライアントのウェブブラウザ１０２ｃとのダイアログが開始される（ブロッ
クＳ３１０）。消費者は、ウェブブラウザ１０２ｃを用いて、および／またはウ
ェブブラウザ１０２ｃと、生体情報ハードウェア収集装置１０２ｂと、ＰＤＩク
ライアントソフトウェア１０２ｄとを認証の要求にしたがって組み合わせて用い
て、要求された認証情報を提出する。認証データの収集が完了すると、クライア
ントブラウザ１０２ｃはこの情報を直接ＰＤＩシステム１００に提出する（ブロ
ックＳ３１２）。

【００４４】 ＰＤＩシステム１００がクライアント１０２ａから収集された情報を確認する
場合には（ブロックＳ３１４で判断）、トランザクションリクエストはクレジッ
ト支払いサービス２０６に転送される（ブロックＳ３１６）。クレジット支払い
サービス２０６は、消費者と電子店舗２０２の代わりにクレジットカード購入を
認証する。結果としての許可・不許可は、電子店舗に返される（ブロックＳ３２
０）。

【００４５】 システムのビジネスルールにしたがってＰＤＩシステム１００が認証データを
拒否した場合（ブロックＳ３１８）、ブロックＳ３１０からＳ３１４が設定され
た回数だけ繰り返されてもよい。ブロックＳ３１０からＳ３１４を繰り返すべき
ではないとＰＤＩシステム１００が判断した場合、ＰＤＩシステム１００は“拒
否”のリターン結果を電子店舗２０２に返す（ブロックＳ３２０）。

【００４６】 例示的なＰＤＩシステム１００のさまざまなサブシステムの機能は図２で示さ
れ、サブシステムが使用する記憶サブシステム２２０からのさまざまなデータ構
造とともに、ここでより詳しく説明される。なお、さまざまなサブシステムによ
って実行される注文、選択および分類の機能は、以下に与えられる例に限定され
るものではなく、いくつもの代替が可能であることが当業者によって認識される
ことを留意するべきである。

【００４７】 図４は、フィルタマネージャー２０８を具備し、あるいはフィルタマネージャ
ー２０８によってアクセスされるコンポーネントの概略を示している。１つの例
では、このサブシステムはＣＧＩプログラムによって実現され、電子購入トラン
ザクションがＰＤＩウェブイネーブルドサーバ２０４を介して送られるときには
、プライマリ転送ＵＲＬとして動作する。図４に示すように、フィルタマネージ
ャー２０８は、処理中にデータ記憶サブシステム２２０からのいくつかの構成／
パラメータファイルにアクセスする。以下でより詳細に説明するように、これら
のファイル４０２によってＰＤＩシステム１００のビジネスルールが設定され、
どの（もしくは、どのように）トランザクションがＰＤＩによって処理されるか
が判断される。さらに、必要に応じてクライアントブラウザ１０２ｃに返信する
エラーメッセージを作成するために、テンプレートＨＴＭＬファイル４０４が用
いられてもよい。図４には示されていないが、データ記憶装置２２０にはセッシ
ョンデータテーブルがさらに含まれ、個々のトランザクションセッションの現状
態を追跡して保持するためにデータ記憶を取り扱うことを理解しなければならな
い。。データテーブルはトランザクション時間、クライアントＩＰアドレス等を
保持し、ＰＤＩシステム１００が、記憶されているコンポーネントを用いて、同
一クライアントからのトランザクションのみを監視し、さらにこのトランザクシ
ョンに対して、受け取った情報の信頼性を確認させることができるようにする。
さらに、本発明を分かりやすくするために別々に示されているが、ファイル４０
２および４０４はデータ記憶サブシステム２２０の一部として構成されてもよい
ことに注意すべきである。

【００４８】 図５は、フィルタマネージャー２０８の処理フローの例を示す図である。本発
明の１つの例では、クレジットカードトランザクションの処理に用いられる通常
の支払いゲートウェイサービスの代わりに、電子店舗２０２は支払い認証リクエ
ストをＰＤＩシステム１００に転送する。本発明のこの例では、ＰＤＩシステム
１００がそのようなリクエストを電子店舗２０２から受け取ると、ＰＤＩウェブ
イネーブルドサーバ２０４は、ＣＧＩプログラムまたはスクリプトによってフィ
ルタマネージャー２０８を呼び出す。一般的に、この処理がユーザ認証の第１プ
ロセスであり、サービスに関するＰＤＩリクエストの有効性が判断される。ラン
タイム構成ファイル４０２ａは、フィルタマネージャーが使用するビジネスルー
ルを特定する。ＰＤＩシステム１００は、特定の電子店舗が直接ＰＤＩシステム
を利用することを許可または拒否するよう構成されていることが好ましい。この
ように、フィルタマネージャー２０８がリクエストを受け取ると、商人のドメイ
ンアイデンティティが評価される（ブロックＳ４０２）。このアイデンティティ
はウェブブラウザ１０２ｃによって集められたＨＴＭＬ／ＣＧ ＲＥＦＥＲＥＲ
領域の形式か、または送信に先立って店舗によって直接集められる特定フォーム
エレメント、PDI_MERCHANTでもよい。どちらの場合でも、ドメイン通知を介して
、またはプライベートなＰＤＩトークンを介して、商人はＰＤＩシステムに自己
を識別させなければならない。商人のサイトのアイデンティティが判断されると
、フィルタマネージャー２０８は特別なビジネスルールファイルであるＥＳＩＴ
ＥＳ４０２ｆに照会する。このファイルはＰＤＩリクエストが受け入れられる商
人のドメインのすべてをリストアップする。これにより、システムの所有者が、
ＰＤＩのユーザ認証サービスの加入者である特定の店舗からのリクエストのみを
処理できるようになる。ＥＳＩＴＥＳファイルは、任意の特別フォームマッピン
グ要件または、個々の店舗に直接関連するデフォルトの支払いゲートウェイサー
バもリストアップする。これについては以下でより詳細に説明される。

【００４９】 電子店舗のドメインをフィルタリングすることに加え、フィルタマネージャー
２０８には、インターネットサービスプロバイダまたはインターネット接続を提
供する会社に関連するリクエストデータをフィルタリングする機能が含まれても
よい。２つの追加的な構成ファイルであるＩＰ拒否４０２ｅとドメイン拒否４０
２ｄは、オンライン購入トランザクションリクエストを受け入れるべきでないＩ
Ｐアドレスおよび／またはドメインネームを規定する。これらのファイルのフォ
ーマットにより、ＰＤＩシステムの所有者は、ドメインネームおよびＩＰアドレ
スの両方をワイルドカードにすることができる。例えば、エレメント192.6＊は
、４つの部分192.6で始まり、他のアドレスエレメントが続くＩＰアドレスを特
定する。同様に、ドメインネームも＊.name.com形式でよく、どのドメインレベ
ルでもマスキングすることができる。後者の例として＊.name.comは、末尾がす
べてname.comとなっているので、ip1.name.com、ip2.name.comまたはname.comに
一致する。これらのファイルは典型的に、過去の不正行動を示したか、またはあ
る方法でオンライン不正に関連したインターネットサービスプロバイダアドレス
／ドメインで集められる。

【００５０】 ＩＰ拒否ファイル４０２ｅがまず照会され、技術的に知られているように、Ｃ
ＧＩプログラムに入力されているHTML/CGI REMOTE_ADDRフィールド入力に一致さ
せられる（ブロックＳ４０４）。一致が検索された場合には、購入リクエストは
即座にダイナミックエラーページ転送され、クライアントブラウザ１０２ｃ上で
表示される。結果として、購入リクエストは実現されない。ＩＰ拒否ファイル４
０２ｅが照会された後、HTML/CGI REMOTE_HOST入力フィールドに一致したデータ
を利用して、ドメイン拒否ファイル４０２ｄ上で同じ動作が行われる（ブロック
Ｓ４０６）。アドレス一致の場合と同様に、ドメインの一致も同一タイプのダイ
ナミックエラーページをクライアントのブラウザ１０２ｃに生成し、一致すれば
、トランザクションの継続を停止する。

【００５１】 入来する購入リクエストがこれらの拒否ファイルのいずれにも特定されない場
合、次の処理ステージに進んでもよい。ＰＤＩシステムは、ＣｙｂｅｒＣａｓｈ
、ＴｒａｎｓＡｃｔ，ＩＰＡＹや他の多くの既存の支払いゲートウェイサービス
と容易に統合できるよう設計されていることが好ましい。これを達成するために
、ゲートウェイプロトコルが要求するフォームエレメントと電子店舗との間のマ
ッピングが確立されなければならない。フィルタマネージャー２０８プロセスは
、既存のＥＳＩＴＥＳファイル４０２ｆを使用して、与えられた店舗に関連する
任意の特定されたマッピングファイルを検索する。例えば、ＰａｙＤｉｒｅｃｔ
ゲートウェイサービスを利用する電子店舗のすべては同一のローカルマッピング
ファイルを特定するが、ＣｙｂｅｒＣａｓｈを利用可能な店舗は異なるローカル
ファイルを示すであろう。マッピングファイルはフォームエレメントネーム以上
のものではなく、ＰＤＩフォームトークンに対するそれらの関係以上のものでは
ない。例えば、商人のアカウントは、“Estore.com uses /filepath/pay direct
.data”のようなテキストで特定されてもよく、このテキストは、ドメインEstor
e1.com上の電子店舗が、/filepathディレクトリまたはサブディレクトリに位置
するマッピングファイルpaydirect.dataを利用することを示す。

【００５２】 どのローカライズされた“マッピング”フォームファイルが商人と関連するか
をフィルタマネージャー２０８が判断した後、メモリに読み込まれる（ブロック
Ｓ４０８）。このファイルは関係のリストであり、商人が使用する物理的な名前
を決定し、購入パラメータを特定する。例えば、ある店舗は、消費者のファース
トネームを、支払いゲートウェイに特定されるデータ中でFNAME=<値>とすること
ができ、他の店舗はFIRST_NAME=<値>のようなエレメントを使用できる。関連す
るマッピングファイルは、商人によるトークンの呼び名と、対応するＰＤＩシス
テム１００内部レファレンスとの間の関係を作成する。例えば、特定のマッピン
グファイル内に次の入力、PDI_FIRST_NAME=FNAME, PDI_LAST_NAME=LNAMEが存在
してもよい。この入力は、フォーム内のファーストネーム領域を表すためにＦＮ
ＡＭＥトークンを用いて識別し、消費者のラストネームを識別するためにＬＮＡ
ＭＥフォームエレメントを用いる。この方法では、エレメントを表すために用い
られるトークンの名前に関わらず、ＰＤＩシステム１００はフォーム表現の異な
る変数をサポートすることができる。特定の電子店舗に関していずれのマッピン
グファイルも特定されなかった場合、フィルタマネージャー２０８システムはデ
フォルト登録ファイル４０２ｇからデフォルトフォームトークンを読み出す。

【００５３】 ブロックＳ４０８で、フィルタマネージャー２０８が有効なフォームマッピン
グファイルを検索した場合、トランザクション処理が続行され得る。しかしなが
ら、商人のフォームと内部ＰＤＩトークンとの間でマッピング関係が確立しなか
った場合には、ダイナミックエラーページが作成され、クライアントのブラウザ
１０２ｃに送られる。このエラーメッセージは、追加的なサポートを受けるため
に、消費者に店のサイトにコンタクトするよう指示する。なぜなら、ＰＤＩシス
テム１００に対するそのプロトコルが適切にサポートされていないからである。

【００５４】 フィルタマネージャー２０８がトークン変換を行った後、すべての要求された
フォームエレメントが実際に存在しているかが確認される（ブロックＳ４１０）
。ＰＤＩシステム１００は、消費者の登録記録を検索できるように、アイデンテ
ィティパラメータの最小の組が任意の購入リクエストで特定されるよう要求する
。これらのフィールドには、消費者のファーストネーム、ラストネーム、請求書
送付先の住所、通り、町、州などが含まれていてもよい。これらのフォームエレ
メントのどれかが不明な場合は、システムのビジネスルールは次のコースのアク
ションを決定する。これに関しては以下で明らかになる。

【００５５】 ビジネスルールによって、ＰＤＩシステム１００は不明のフォームエレメント
を増やすよう構成され（ブロックＳ４１４で決定）、ＨＴＭＬページ４０４ａを
ダイナミックに作成する。ＨＴＭＬページ４０４ａは、消費者からのこれらの不
明なアイデンティティフォームエレメントをリストアップしてリクエストする。
クライアントのブラウザ１０２ｃによって再提出されたフォームが、（以前のも
のに加えて）すべてのアイデンティティエレメントを含むよう、オリジナルのリ
クエストで与えられたフォームエレメントが、隠しエレメント形式でダイナミッ
クＨＴＭＬページの一部をなす（ブロックＳ４１６）。消費者はその後、不明エ
レメントを供給するよう要求される（ブロックＳ４１８）。不明データが受け取
られると、処理のためにＰＤＩシステム１００に再び転送される（ブロックＳ４
２０）。ビジネスルールによって、ＰＤＩシステム１００が不明フィールドを増
加しないよう構成されている場合には、ダイナミックＨＴＭＬエラーページが作
成され、クライアントのブラウザ１０２ｃに返される。これは、トランザクショ
ンが処理できなかったことを示す（ブロックＳ４２２）。

【００５６】 すべてのフォームエレメントが存在すると（ブロックＳ４１０で判断）、それ
らは別個のトークン／値の対に分析され、メモリに記憶される（ブロックＳ４１
２）。このデータはアイデンティティマネージャー２１０のプロセスＳ５０２へ
の入力となる。

【００５７】 図６は、アイデンティティマネージャー２１０を具備し、あるいは、アイデン
ティティマネージャー２１０によってアクセスされるコンポーネントの概略を示
す。一般的に、アイデンティティマネージャーサービスは、消費者がＰＤＩ登録
されたか、および消費者が適切にＰＤＩシステムに１００に登録されているかを
確認する役割を果たし、ダウンストリーム処理のための消費者のコンテクストを
検索する。図６に示すように、アイデンティティマネージャー２１０による処理
中に、複数の構成ファイル４０２がアクセスされる。以下でより詳細に説明され
るように、これらのファイルのコンテンツによって、このマネージャーのビジネ
スルールおよび構成（ランタイム構成データ４０２ａ）、データ記憶装置２２０
のアクセス方法（データ記憶セキュリティ４０２ｂ）、ならびにデータを変換し
、標準化するためのルールおよび手続き（辞書データ４０２ｈおよびアドレスル
ールデータ４０２ｉ）が決定される。

【００５８】 図７は、アイデンティティマネージャー２１０の処理のフローの例を示す図で
ある。この例において、アイデンティティマネージャー２１０は、フィルタマネ
ージャー２０８が現トランザクションに関連する識別データを抽出して解析した
後に入力される（ブロックＳ５０２）。アイデンティティマネージャー２１０は
まずこのデータを利用して、消費者を正確に識別するのに十分な情報を利用可能
かどうかを判断する（ブロックＳ５０４）。十分な情報が利用できない場合、リ
クエストは不明登録ＨＴＭＬページに転送される（ブロックＳ５０６）。不明登
録ＨＴＭＬページによって、消費者は要求されたデータを増加して提供できるよ
うになる。消費者のせいで不明情報がシステムに登録されていない場合（または
、十分な登録情報がない場合）、クライアントブラウザが代わりにシステム登録
プロセスを行うよう指示してもよい（図７のブロックＳ６０２を参照）。

【００５９】 リクエストされ、抽出されたデータが、アイデンティティ確認のためにＰＤＩ
システム１００によって要求されたコンポーネントをすべて含む場合（ブロック
Ｓ５０４で判断）、辞書データ４０２ｈおよびアドレスルールデータ４０２ｉか
ら検索された、データを変換して標準化するためのルールおよび手続きを利用し
て、適切な加入者データ４２０ａ問合せが作成される。その後、適切な問合せが
記憶装置システム２２０内の加入者データ４２０ａに対して呼び出され、“代表
する”消費者の記録および関連するテンプレートが検索される。ブロックＳ５０
７で問合せに失敗した場合、エラーページＳ５０８を構成するシステムのダイナ
ミックに増加されたレンダリングが、クライアント１０２に返される。

【００６０】 ブロックＳ５０７において、固有の登録入力が検索された場合、消費者が前も
って有効に登録されているかどうかについての判断がなされる（PDI_REGISTERED
）。これは、管理者が管理サービスコンポーネント２１８を介して個人を前もっ
て登録したか、あるいは個人が管理サービスコンポーネント２１８または他のプ
ロセスを介して以前登録しようとしたことがあるかのいずれかを示す。プロセス
はその後、ＰＤＩシステム１００内に消費者が適切に登録されているかどうかを
判断する（ブロックＳ５１０）。“適切に登録されている”とは、消費者が、認
証比較用の登録済デジタルコードおよび／または生体情報テンプレートを持つこ
とを意味する。消費者がＰＤＩシステム１００に正しく登録されていなかった場
合、リクエストは適切な結果コードとともにＰＤＩウェブイネーブルドサーバ２
０４に転送される。ブロックＳ５１０で判断されたように、消費者が正しく登録
され、要求されたテンプレートを利用できる場合には、アイデンティティマネー
ジャー２１０は消費者がブラックリストに載っているかどうかを判断する（ブロ
ックＳ５１２）。ブラックリストには、ＰＤＩシステム１００がトランザクショ
ン／リクエストを即座に拒否すべき消費者のリストが含まれる。消費者情報がＰ
ＤＩブラックリストに存在する場合、適切な結果コード（ＤＥＮＹ）がＰＤＩウ
ェブイネーブルドサーバ２０４に返され、適切なアクションがとられる。消費者
情報がＰＤＩブラックリストに含まれない場合には、さらなる処理・認証判断を
なすトランザクションルールマネージャーにリクエストが転送される（図１０の
ブロックＳ７０２を参照）。

【００６１】 図８は、ＰＤＩシステム内の登録プロセス用の処理フローの例を示す図である
。本発明の１つの例では、消費者は、商品の購入およびクレジット支払いネット
ワーク２０６による認証のために、要求されたフォームデータを、クライアント
ブラウザ１０２ｃを通じて電子店舗２０２に提出する。リクエストおよびフォー
ムデータは、ＰＤＩウェブイネーブルドサーバ２０４に転送される。ＰＤＩウェ
ブイネーブルドサーバ２０４は、リクエストに対してさらなる処理を行う前に、
消費者に関するテンプレートが存在するかどうかをアイデンティティマネージャ
ー２１０を介して判断する。アイデンティティマネージャーが、現リクエストの
ために消費者のパーソナル情報および／またはテンプレートを検出できない場合
には、消費者は登録ページに転送される。システムのビジネスルールによって構
成されるように検出された場合には、以下に説明するように登録プロセスが開始
される。

【００６２】 図８に示すように、ＰＤＩシステム１００はまず、有効な電子店舗２０２から
リクエストが提出されているかどうかを判断する（ブロックＳ６０２）。ＰＤＩ
システム１００がサイトを確認できない場合、消費者はダイナミックＨＴＭＬペ
ージに転送され、その旨が消費者に通知される（ブロックＳ６０４）。リクエス
トが有効なサイトから提出されている場合（ブロックＳ６０２で判断）、リクエ
ストおよびフォームデータがＰＤＩ処理のために浄化され、クライアントが提供
したすべてのフォームデータが、ＰＤＩシステムによって用いられる標準規格に
確実に再フォーマットできるようにされる。例えば、“123 Main Streetと123 M
ain St.”は同一の住所であり、ＰＤＩシステム１００によって“123Main St.”
に浄化される。フォームデータが抽出されると、対応するセッションが位置付け
られ、読み込まれなければならない。消費者によって提出されたフォームデータ
がマッピングも浄化もできなかった場合（ブロックＳ６０６で判断）、消費者は
ダイナミックＨＴＭＬページに転送される（ブロックＳ６０４）。フォームデー
タが正しく浄化され、マッピングされた場合、ＰＤＩシステムはすべての要求さ
れたコンポーネントがフォームデータ内で利用できるかどうかを判断する（ブロ
ックＳ６０８）。要求されたコンポーネントが不明の場合、消費者がダイナミッ
クＨＴＭＬページ通じてそれらのフォームデータを送るよう指示され、要求され
る（ブロックＳ６０４）。リクエストおよびフォームデータが、ＰＤＩ処理のた
めに必要なコンポーネントをすべて含む場合、ＰＤＩシステムは、個人に送られ
た固有の文字列のような登録鍵を使用して、どの消費者が認証され、システムに
登録されたかを判断する（ブロックＳ６１０）。登録鍵は、消費者をＰＤＩシス
テム１００の正当な参加者として識別する。さらに、ｅメール、郵便、および／
または登録鍵が確実に傷つけられないようにする他の受け入れ可能な手段を介し
て送信される。消費者によって提供された登録鍵が有効でない場合、クライアン
ト１０２はダイナミックＨＴＭＬページに転送される（ブロックＳ６０４）。ブ
ロックＳ６１０において、登録鍵がＰＤＩシステム１００によって確認された場
合、システムは登録プロセスを通じてリクエストの処理を継続する。

【００６３】 すべての要求されたコンポーネントが利用可能であるとみなされ（ブロックＳ
６０８）、有効な登録鍵が提供される（ブロックＳ６１０）と、ＰＤＩシステム
１００によって、提出されたフォームデータを用いて、消費者がＰＤＩシステム
内に存在するかどうかが判断される（ブロックＳ６１２）。消費者がＰＤＩシス
テム内に存在する場合、消費者は更新パーソナルオプションページに転送される
（ブロックＳ６１４）。更新パーソナルオプションページでは、登録された消費
者が、データ記憶サブシステム２２０内に記憶された個人情報を更新し、追加し
、および／または変更することができる。

【００６４】 ブロックＳ６１２で判断されるように、消費者がＰＤＩシステム１００内に存
在しない場合、リクエストに関連するフォームデータがＰＤＩシステム１００に
取り込まれ（ブロックＳ６１６）、登録プロセスが続行される。新規に収集され
た消費者情報がＰＤＩシステム１００に取り込まれた後、プロセスはクライアン
ト１０２がＰＤＩクライアントソフトウェア１０２ｄを備えているかどうかを判
断する（ブロックＳ６１８）。ＰＤＩクライアントソフトウェア１０２ｃが利用
できない場合、消費者はデジタルコードを提供するよう要求される（ブロックＳ
６２２）。このデジタルコードは、将来の認証のために消費者の記録に更新され
る（ブロックＳ６３０）。

【００６５】 ブロックＳ６２０で判断されるように、ＰＤＩクライアントソフトウェア１０
２ｃが利用できる場合には、消費者はデジタルコードを入力するよう促される（
ブロックＳ６２４）（例えば、個人がコンピュータおよび／または情報へのアク
セスまたは許可を得るために用いるシークレットワードまたはパスフレーズ）。
デジタルコードがうまく収集された後、プロセスは、消費者から生体情報テンプ
レートを収集するために、ＰＤＩクライアントソフトウェアを呼び出す（ブロッ
クＳ６２６）。消費者はブロックＳ６２８で、生体情報収集装置１０２ｂを通じ
て生体情報テンプレートを提供する。デジタルコードおよび生体情報テンプレー
トが正常に消費者から収集され、正確なことが確認された後、消費者の記録は更
新される（ブロックＳ６３０）。ＰＤＩシステム１００が消費者の記録を更新し
た後、システムのビジネスルールによって構成されているダイナミックＨＴＭＬ
ページにリクエストが転送される（ブロックＳ６０４）。

【００６６】 図９は、本発明の１つの例にしたがったトランザクションルールマネージャー
２１２によって利用される、高レベルデータコンポーネントを示す。一般的に、
トランザクションルールマネージャー２１２は、企業レベル（すなわち、ビジネ
ス）のルールに照らしてクライアントのリクエストを処理し、認証が必要かどう
かを判断する役割を果たす。必要である場合には、どのタイプの認証を消費者に
対してリクエストすべきかを判断する。図９に示すように、トランザクションル
ールマネージャー２１２による処理中にいくつかの構成ファイル４０２が用いら
れる。以下でより詳しく説明されるように、これらのファイルのコンテンツは、
記憶システム２２０内に記憶された、マネージャー２１２のビジネスルールおよ
び構成（ランタイム構成データ４０２ａ）、データ記憶装置２２０アクセス方法
（データ記憶セキュリティ４０２ｂ）、エラー通知のダイナミックレンダリング
用のＨＴＭＬテンプレート（テンプレートＨＴＭＬファイル４０４）、および関
連する加入者（サブデータ４２０ａ）、トランザクション（トランザクションデ
ータ４１８ａ）、ベース（ベース４１４）、リンク（リンク４１６）およびルー
ル（アクティブルール４１０ａ−ｇ）データを決定する。

【００６７】 図１０は、トランザクションルールマネージャー２１２の処理フローの例を示
す図である。図１０に示すように、入力がなされると、現トランザクションの金
額は、構成可能なシステムの最高許容額に照らしてチェックされる（ブロックＳ
７０２）。金額がシステムの最高許容額を超える場合、構成可能なダイナミック
ウェブページに対する転送リクエストが、ＰＤＩウェブイネーブルドサーバ２０
４を介してクライアント１０２に返される（ブロックＳ７３４）。トランザクシ
ョン額がシステムの最高許容額を超えない場合、消費者に課された登録限度額が
存在するかどうかをチェックすることにより処理が継続する（ブロックＳ７０４
）。

【００６８】 消費者に課された登録限度額が存在しない場合、処理はプッシュおよび／また
は検索トランザクション関係へ進む（ブロックＳ７１０）。消費者に課された登
録限度額が存在する場合、現トランザクションの金額が審査され（ブロックＳ７
０６）、トランザクションごとの限度額をこえている場合には、構成可能なダイ
ナミックウェブページに対する転送リクエストが、ＰＤＩウェブイネーブルドサ
ーバ２０４を介してクライアント１０２に返される（ブロックＳ７３４）。トラ
ンザクションごとの限度額を超えていない場合には、消費者の月ぎめ限度額を超
えているかどうかをチェックすることにより処理を継続する（ブロックＳ７０８
）。

【００６９】 現トランザクションの金額と当月のトランザクションの金額総和を合計したも
のが消費者の月ぎめ限度額を越える場合には、構成可能なダイナミックウェブペ
ージに対する転送リクエストが、ＰＤＩウェブイネーブルドサーバ２０４を介し
てクライアント１０２に返される（ブロックＳ７３４）。超えない場合には、プ
ッシュおよび／または検索トランザクション関係へと処理が続く（ブロックＳ７
１０）。

【００７０】 プッシュおよび／または検索トランザクション関係ブロックＳ７１０は、現ト
ランザクションからの履歴リンケージアソシエイト関係をデータ記憶サブシステ
ム２２０に記憶し、該サブシステム２２０から履歴リンケージアソシエイト関係
を検索する。これらの関係は、トランザクションルールマネージャーアクティビ
ティブロックの残りの間に用いられる（ブロックＳ７１２−Ｓ７３０）。

【００７１】 データ記憶サブシステム２２０から関係が検索された後（ブロックＳ７１０）
、グローバルな制約条件がデータ記憶サブシステム２２０から検索される（ブロ
ックＳ７１２）。グローバルな制約条件は審査され、グローバル認証方法が要求
されているかどうかを判断する（ブロックＳ７１４）。要求されていれば、処理
はＰＤＩ認証決定ブロックＳ７３２へ進み、要求されていなければ、PDI_AUTH_N
ONEに認証方法を設定し（ブロックＳ７１６）、ネットワークの制約条件を評価
することにより処理が継続する（ブロックＳ７１８）。

【００７２】 図１１に示すように、ネットワークの制約条件は、データ記憶サブシステム２
２０から関連する制約ベクトルを検索することによって、ブロックＳ７１８で評
価される。現トランザクションが１つの制約ベクトルのロジックに一致する場合
には、関連する認証方法が選択される。現認証方法よりも厳しい場合には、現認
証方法が更新される（ブロックＳ７２０）。現認証方法が更新されて利用可能な
最高の認証と等しくなった場合には、フローは直接ＰＤＩ認証決定へと進む（ブ
ロックＳ７３２）。そうでなければ、フローはアイデンティティ制約を評価する
ことにより継続する（ブロックＳ７２２）。

【００７３】 アイデンティティ制約は、関連する制約ベクトルをデータ記憶サブシステム２
２０から取り出すことによって評価される（ブロックＳ７２２）。現トランザク
ションが１つの制約ベクトルのロジックと一致する場合には、関連する認証方法
が選択される。現認証方法よりも厳しい場合には、現認証方法が更新される（ブ
ロックＳ７２０）。現認証方法が更新されて、利用可能な最高の認証と等しくな
った場合には、フローは直接ＰＤＩ認証決定へと進む（ブロックＳ７３２）。そ
うでなければ、フローはブール制約を評価することにより継続する（ブロックＳ
７２４）。

【００７４】 ブール制約は、関連する制約ベクトルをデータ記憶サブシステム２２０から取
り出すことによって評価される（ブロックＳ７２４）。現トランザクションが１
つの制約ベクトルのロジックと一致する場合には、関連する認証方法が選択され
る。現認証方法よりも厳しい場合には、現認証方法が更新される（ブロックＳ７
３２）。現認証方法が更新されて利用可能な最高の認証と等しくなった場合には
、フローは直接ＰＤＩ認証決定へと進む（ブロックＳ７３２）。そうでなければ
、フローはトランザクション制約を評価することにより継続する（ブロックＳ７
２６）。

【００７５】 トランザクション制約は、関連する制約ベクトルをデータ記憶サブシステム２
２０から取り出すことによって評価される（ブロックＳ７２６）。現トランザク
ションが１つの制約ベクトルのロジックと一致する場合には、関連する認証方法
が選択される。現認証方法よりも厳しい場合には、現認証方法が更新される（ブ
ロックＳ７２０）。現認証方法が更新されて利用可能な最高の認証と等しくなっ
た場合には、フローは直接ＰＤＩ認証決定へと進む（ブロックＳ７３２）。そう
でなければ、購入制約を評価することによりフローは継続する（ブロックＳ７２
８）。

【００７６】 購入制約は、関連する制約ベクトルをデータ記憶サブシステム２２０から取り
出すことによって評価される（ブロックＳ７２８）。現トランザクションが１つ
の制約ベクトルのロジックと一致する場合には、関連する認証方法が選択される
。現認証方法よりも厳しい場合には、現認証方法が更新される（ブロックＳ７２
０）。現認証方法が更新されて利用可能な最高の認証と等しくなった場合には、
フローは直接ＰＤＩ認証決定へと進む（ブロックＳ７３２）。そうでなければ、
行動制約にフローは継続する（ブロックＳ７３０）。

【００７７】 行動制約は、関連する制約ベクトルをデータ記憶サブシステム２２０から取り
出すことによって評価される（ブロックＳ７３０）。現トランザクションが１つ
の制約ベクトルのロジックと一致する場合には、関連する認証方法が選択される
。現認証方法よりも厳しい場合には、現トランザクションが更新される。フロー
はＰＤＩ認証決定へと続く（ブロックＳ７３２）。

【００７８】 ＰＤＩ認証が判断されると（Ｓ７３２）、フローはユーザプロファイルマネー
ジャー２１４へと続く。

【００７９】 図１２は、本発明の１つの例にしたがったユーザプロファイルマネージャー２
１４によって用いられる、高レベルデータコンポーネントを示す。図１２に示す
ように、処理中、ユーザプロファイルマネージャー２１４はいくつかの構成／パ
ラメータファイルにアクセスする。以下でより詳しく説明するように、これらの
ファイルはＰＤＩシステム１００のビジネスルールを設定し、どの（および、ど
のように）トランザクションがＰＤＩによって処理されるかを判断する。テンポ
ラリファイルは、必要なユーザ認証がシステムによって確認されるまで、トラン
ザクションフォームデータを記憶するよう用いられる。暗号化鍵もまたテンポラ
リ記憶領域に記憶される。単一のセッションのみに暗号化鍵が有効だからである
。さらに、エラーメッセージ、または必要に応じてクライアントブラウザ１０２
ｃに返す情報収集メッセージを構成するために、テンプレートＨＴＭＬファイル
が用いられてもよい。一連のデータテーブルによって制御されるデータ記憶装置
は、プロファイル情報にアクセスし、トランザクションエレメントを記憶して、
現トランザクションとこれに関連するネットワークエレメントとの間のリンケー
ジ関係を作成する。

【００８０】 図１３は、本発明のシステムアーキテクチャ内の、ユーザプロファイルマネー
ジャー２１４の処理フローの例を示す図である。一般的に、このサブシステムは
、以下に述べるような行動ベースのプロファイルアルゴリズムを用いることによ
って、認証の必要性のために現トランザクションを評価する役割を果たす。本実
施形態では、ユーザプロファイルマネージャー２１４に対する入力は、前もって
評価された、トランザクションルールマネージャー２１２によって判断されるよ
うに、現トランザクションに適用されるべきユーザ認証方法の形式である。

【００８１】 トランザクションルールマネージャー２１２から受け取った認証入力は、例え
ば、以下の識別子のいずれであってもよい。PDI_AUTH_NONE（先行するステップ
ではどのマッチングルールも評価されなかったことを確認する）、PDI_AUTH_ALL
OW（それ以上の識別をすることなく許可されるべきトランザクションを示す）、
PDI_AUTH_DC（個人を認証するために用いられるべきデジタルコードを示す）、P
DI_AUTH_BEST（生体情報収集装置１０２ｂの利用可能性にしたがって、クライア
ント１０２上で利用できる最適の方法が利用されるべきであることを示す）、PD
I_AUTH_FP（生体情報である指紋が個人の認証に用いられるべきであることを示
す）、PDI_AUTH_FP_DC（デジタルコードと生体情報である指紋の両方が個人の認
証に用いられるべきであることを示す）、そして最後には、PDI_AUTH_DENY（ト
ランザクションは完全に拒否されるべきであることを示す）。

【００８２】 ＰＤＩシステム１００のビジネスルールは、認証方法がトランザクションルー
ルマネージャー２１２によって直接特定されている時であっても、行動ベースの
処理が行われるべきであるかどうかを判断する。システムのビジネスルールは、
ランタイム構成ファイル４０２ａによって規定され、トランザクション分析中に
適用されるランタイムパラメータを識別する。現在入力されている特定された認
証方法が利用可能な最高のレベルであることが判断された場合（すなわち、PDI_
AUTH_DENY）、どの追加的な処理も生じない。行動ベースの評価は、前もって入
力された方法に代わることができないからである（ブロックＳ８０２）。しかし
ながら、行動ベースのプロファイル処理が入力認証方法とともに適用されなけれ
ばならないとビジネスルールが要求する場合、あるいは、どの認証方法も前もっ
て判断されていない場合（PDI_AUTH_NONE）、プロファイルアルゴリズムが用意
される（ブロックＳ８０４）。

【００８３】 個々の加入者に対する履歴トランザクション関係の評価は、ＰＤＩシステム１
００のリンケージテーブルから抽出され、ここでそれらが評価される（ブロック
Ｓ８０６）。ユーザプロファイルマネージャー２１４は、トランザクションを有
するすべてのネットワークエレメント間で固有の関係を維持し、トランザクショ
ンを要求する個人に直接このデータを関連付ける。これらの関係へのアクセスは
、データ記憶セキュリティファイル４０２ｂを介しており、ファイル４０２ｂは
、データ記憶システム２２０へのセキュリティアクセスパラメータを規定する。

【００８４】 ＰＤＩシステム１００は、配置環境にしたがって、ネットワークエレメントの
追加または削除ができるよう設計されていることが好ましい。電子コマーストラ
ンザクションの場合には、ネットワークエレメントは個人ごとに維持され、トラ
ンザクションが識別可能なネットワークエレメントの利用を切断するごとに発生
カウントが増加する。さらに、システムは各エレメントごとに、エレメントが正
常に認証された回数の履歴カウントを維持し、同様に、認証リクエストに失敗し
たトランザクションにエレメントが関連付けられた回数も維持される。この方法
で、各個人のネットワークエレメントは、以前の認証の試行にしたがって自動的
に維持される自己の“スコア”を有する。特定の個人の購入リクエストに関して
より多くのトランザクションが処理されるにしたがい、個人に関連する与えられ
たエレメントの認証が支援される。

【００８５】 例えば、個人がＩＰアドレスを別々に５回利用することによって、システムに
よって維持されるべき、正常なアクセスと失敗したアクセスの両方のあわせて５
回のカウントが生じる。成功と失敗の分布は、個人の以前の購入パターンに関す
る個々のネットワークエレメントの現在のスコアを示す。個人が、ＩＰアドレス
206.168.56.5を過去に５回使用した場合、４回の成功カウントと１回の失敗カウ
ント（あわせて５回）の分布は４／５＊１００＝８０％と計算される。結果とし
て、206.168.56.5を使用する個人に関するＩＰアドレスのリンケージは、このサ
ービスプロバイダのアドレスに起因するトランザクションの場合、過去に８０％
の時間で、正常な認証が生じたことを示す。

【００８６】 ここで用いられるネットワークエレメントには、ＩＰアドレス、電子店舗のド
メインネーム、シッピングアドレス、コンタクト情報、ブラウザソフトウェア、
クレジットカード情報、トランザクション量、時刻、曜日などのコンポーネント
が含まれる。このリストは限定される意図ではなく例示として意図されており、
他のコンポーネントも当業者にとって明らかであるだろう。ネットワークエレメ
ントはデータ記憶サブシステム２２０に記憶され、加入者アイデンティティ記録
に直接関連付けられる。これらのベクトルのそれぞれは、個々の消費者の登録デ
ータと直接のリンケージ関係を有し、履歴使用回数（発生、成功、失敗）は、過
去に消費者によって利用された各ネットワークエレメントに関して維持される。
この方法では、ＰＤＩシステム１００のプロファイルアルゴリズムは、個人に関
係する各ネットワークエレメントの利用スコアを評価し、現トランザクションで
認識されるすべてのネットワークエレメントの組み合わせに基づいて集合スコア
を計算することができる。

【００８７】 ＰＤＩシステム１００の管理者が、任意の与えられたトランザクションに対し
てスコアを計算する方式をカスタマイズできるようにするために、各ネットワー
クエレメントは関連する重み定数を有する。この重み定数は解析中に適用される
。この重みはビジネスルール構成ファイルで規定され、システム内のすべてのネ
ットワークエレメントに対してどの“強さ”が適用されるべきかを判断する。こ
の方法においてシステム管理者は、どのトランザクションコンポーネントが対象
環境においてより重要とみなされるべきかを判断することができ、この判断は一
般的に、履歴不正パターンまたは特定のコンポーネントの利用可能性に基づいて
判断される。

【００８８】 現トランザクションの各ネットワークエレメントが評価され、重み付けされる
にしたがって、対象個々の消費者の履歴認証パターンに基づいて集合スコアが計
算される。このスコアは全体の履歴認証の確実性を表し、請求された個人に関連
したネットワークエレメントの集合に関連する。一般的に、与えられたネットワ
ークエレメントが正常に認証された数の総数を比較し、その値をネットワークエ
レメントに対する試行回数の総数によって割ることによって、最終スコアが計算
される。これによって、すなわち認証の割合が計算される。各ネットワークエレ
メントはそのエレメントに割り当てられた重みの値で乗算され、特定のエレメン
トに対する全体のスコアが判定される。その後、これらすべてのスコアの和を重
みの和で割り算する。最終スコアは０−１００の範囲の割合となる。

【００８９】 このプロセスを完了すると（ブロックＳ８０８）、認証スコアはＰＤＩシステ
ム１００の管理者によって設定されたビジネスルールと比較される。これらのビ
ジネススールは、適用する特定の認証方法に関係したしきい値を特定する。例え
ば、システムのビジネスルールは、与えられたトランザクションがデジタルコー
ドによって認証されるために８０％から８５％の間のスコアが要求されるべきで
あると特定してもよい。この情報は行動データファイル４０２ｊから取り出され
る。

【００９０】 行動ベースの処理から返された結果である認証方法は、上述されたようにトラ
ンザクションルールマネージャー２１２によって特定された入力認証方法と比較
される。２つの認証方法がより厳しく識別され、好ましい認証方法となり現トラ
ンザクションに適用される（ブロックＳ８１０）。

【００９１】 認証方法の分析が完了すると、データ記憶サブシステム２２０に現トランザク
ションが組み込まれる（ブロックＳ８１２）。プロセスのこの時点で、どのユー
ザインタラクションがＰＤＩシステム１００とクライアント１０２マシーンとの
間で要求されるかに基づいて、トランザクションステータスが識別される。イン
タラクションを必要としないトランザクション、すなわちPDI_AUTH_ALLOWまたは
PDI_AUTH_DENYは、事実上完了しているとみなされる。なぜなら、どの認証の証
明書も要求されていないからである。他のトランザクションのすべて、すなわち
PDI_AUTH_BEST、PDI_AUTH_FP、PDI_AUTH_DC、およびPDI_AUTH_FP_DCは、ユーザ
のアイデンティティを確認するために個人からの入力を要求する。これらのトラ
ンザクションは、事実上不完全なものとして記録される。それは、ステータスが
まだ判断されておらず、認証の証明書がまだ収集されていないからである。ＰＤ
Ｉシステム１００における各トランザクションのいずれもが保存され、関連する
認証方法、完了ステータス、ネットワークコンポーネントに対するリンケージお
よび認証に関する理由はトランザクション入力の一部をなす。

【００９２】 上述のように、アイデンティティの証明書を収集するために、特定の認証方法
はＰＤＩシステム１００とクライアント１０２との間のインタラクションを要求
する。ブロックＳ８０２とＳ８０４で説明されたように、識別された認証ステッ
プに基づいて、そのようなインタラクションが必要かどうかを判断するための評
価がなされる（ブロックＳ８１４）。生体情報データ、デジタルコード、または
これら２種類の組み合わせの収集はインタラクティブプロセスであるとみなされ
る。しかしながら、認証方法がPDI_AUTH_ALLOWである場合には（ブロックＳ８１
６で判断）、アイデンティティの収集が要求され、トランザクションは即座にク
レジット支払いシステムまたは電子店舗によって特定された外部の会社に転送さ
れる（ブロックＳ８１８）。最初にＰＤＩシステム１００に提示され、テンポラ
リフォームエレメントデータファイル４０６ｂに記憶されたすべての購入フォー
ムデータは、警告なしで転送される。このケースでは、ＰＤＩシステム１００は
単にパススルーサブシステムであり、電子コマース購入トランザクションがトラ
ンスペアレントとなる。

【００９３】 一方、認証方法がPDI_AUTH_DENYである場合（ブロックＳ８２０で判断）、拒
否メッセージが即座に電子店舗に返され、それ以上の処理は行われない（ブロッ
クＳ８２２）。システムのビジネスルールは、電子店舗に返すために応答コード
が生成されたか、または他のＵＲＬが代わりに呼び出されるかどうかを判断する
。しかしながら、非インタラクティブな認証方法のための最終パスが拒否または
認容トランザクション条件の結果ではない場合、プログラム上の問題がＰＤＩシ
ステム１００内で発生したことが示される。よって、消費者はクライアントブラ
ウザ１０２ｃによってエラーページに転送される（ブロックＳ８２４）。

【００９４】 既に示されているように、特定の認証方法は、消費者とのインタラクションを
要求する。そのような認証方法が特定されると（ブロックＳ８１４で判断）、ア
イデンティティの証明書を収集するために、どのＵＲＬがクライアントブラウザ
１０２ｃシステムにマッピングされるかについての判断がなされる。

【００９５】 図１４においてPDI_AUTH_DCが特定されると（ブロックＳ８２６で判断）、ア
イデンティティの証明書を収集するための対象ＵＲＬは、デジタルコードコレク
ションを特定するＤＣとして記録される（ブロックＳ８３２）。デジタルコード
は常に消費者に対してファイルされている。なぜなら、有効なデジタルコードが
収集され、確認されない限り、上述のＰＤＩ登録プロセスは、登録記録がデータ
記憶サブシステム２２０に組み入れることを認めないからである。

【００９６】 PDI_AUTH_FP_DCが特定されると（ブロックＳ８２８で判断）、デジタルコード
と生体情報データの組み合わせが要求される。このタイプの認証が有効であるこ
とを確認するために、消費者の登録記録が質問され、生体情報テンプレートがフ
ァイルされているかどうかが判断される（ブロックＳ８３０）。そのようなテン
プレートが検索された場合、アイデンティティの証明書を収集するための対象Ｕ
ＲＬはＤＣとして記録される（ブロックＳ８３２）。なぜなら、複数の証明書の
収集が特定されるときには、デジタルコードの収集がまずなされるからである。
しかしながら、生体情報テンプレートが消費者に関してファイルされていない場
合、購入リクエストへの転送が生じる。なぜなら、生体情報登録データが足りな
いことによって認証が完了できないからである（ブロックＳ８３４）。システム
のビジネスルールは、このＵＲＬ転送の場所を決定する。

【００９７】 同じプロセスがPDI_AUTH_FPに適用される（ブロックＳ８３６で判断）。生体
情報の認証が要求される場合、消費者の登録記録が質問され、テンプレートが存
在するかどうかが判断される（ブロックＳ８３８）。テンプレートが検索される
場合、アイデンティティの証明書を収集するための対象ＵＲＬはＢＩＯとして記
録される（ブロックＳ８４０）。PDI_AUTH_FP_DCの例のように、生体情報テンプ
レートが利用できない場合、システムのビジネスルールで決定されているように
、ＰＤＩシステム１００は適切なＵＲＬへ購入リクエストを転送する（ブロック
Ｓ８３４）。

【００９８】 最後に、PDI_AUTH_BESTが特定される場合（ブロックＳ８４２で判断）、生体
情報テンプレートが消費者にとって利用可能かどうかを判断するチェックがなさ
れる（ブロックＳ８４４）。しかしながら、そのようなテンプレートがなければ
、エラーの転送が生成されない。むしろ、デジタルコードが消費者のためにファ
イルされている情報のみである場合は（ブロックＳ８４６）、アイデンティティ
情報を収集するための対象ＵＲＬはＤＣとして記録される（ブロックＳ８３２）
。逆に、生体情報テンプレートが利用できる場合は（ブロックＳ８４８）、対象
ＵＲＬはＢＩＯとして記録される（ブロックＳ８４０）。

【００９９】 アイデンティティの証明書を収集するためにクライアントブラウザ１０２ｃに
マッピングされるべき適切なＵＲＬの判断が完了すると、生体情報認証に関して
セッション鍵が生成されるのが好ましい（ブロックＳ８５０）。公開鍵の暗号化
技術（非対称暗号化）を用いて、ユーザプロファイルマネージャー２１４は２つ
の鍵−公開鍵と秘密鍵−を生成する（ブロックＳ８５０）。生体情報がトランザ
クション認証のために収集され、ＰＤＩシステム１００に返されるのに伴い、こ
れらの鍵は生体情報データを暗号化および解読するために用いられる。公開／秘
密鍵の対の作成に用いられるサイズおよびアルゴリズムは、システムのビジネス
ルールによって特定される。

【０１００】 ＰＤＩシステム１００へ返信するのに先立って生体情報データを暗号化するた
めに用いられてもよいように、生成された公開鍵はクライアントブラウザ１０２
ｃに送られるＵＲＬデータに含まれる。これは、ＢＩＯ ＵＲＬコンテンツをダ
イナミックに更新し、公開鍵データをプラグイン入力パラメータの一部として追
加することによって達成される。秘密鍵は、一方、ＰＤＩシステム１００上の保
護されているディレクトリに記憶され、ファイル名は保存されているセッション
データに対して利用可能なように作成される（ブロックＳ８５２）。これは、テ
ンポラリ秘密鍵データファイル４０６ａへと続く。

【０１０１】 セッションデータ４１８ｂは現在認証を要求しているトランザクションを識別
し、トランザクションの状態の詳細が含まれる。セッションの記録は、適用され
る認証方法、現リクエストが発生したＩＰアドレス、認証リクエストが開始され
た日付／時刻、生体情報の収集が生じた場合には秘密鍵のファイル名、電子店舗
によって送信されたオリジナルの購入フォームエレメント、および消費者からの
任意の再試行のステータスを識別する。各セッションの記録は、ＰＤＩシステム
１００内の他のすべてのセッションの記録からそれを識別する固有の非反復鍵の
値に割り当てられる。アイデンティティの証明書が収集された後、クライアント
１０２から受け取った認証の応答と現トランザクションリクエストとを互いに関
連付けるために用いられるのがこの鍵である。セッション鍵は対象ＵＲＬが生成
された後、このＵＲＬに対して付加され、ＰＤＩホスト上のセッションデータテ
ーブル４１８ｂに記憶される。

【０１０２】 セッションデータがＰＤＩシステム１００内に記憶された後（ブロックＳ８５
２）、ＰＤＩウェブイネーブルドサーバとクライアントブラウザ１０２ｃとの間
でダイアログが開始される。ＰＤＩシステム１００は、以前判断された対象ＵＲ
Ｌに消費者を転送し、これにより証明書の収集プロセスが始まる（ブロックＳ８
５４）。クライアントに戻されるすべてのトランザクションはＰＤＩウェブサー
バを介する（ブロックＳ８５６）。この時点で、ＰＤＩシステム１００によって
制御が解除され、ＰＤＩシステム１００がアイデンティティの証明書を受け取っ
て確認するまで、トランザクションリクエストは不完全な状態のままとなる。

【０１０３】 図１５は、本発明の１つの例にしたがった認証マネージャー２１６を具備し、
または認証マネージャー２１６によってアクセスされるコンポーネントの概要を
示す。一般的にこのサブシステムは、前もってクライアントのワークステーショ
ン１０２に送られた認証リクエストに応じて、ＰＤＩシステム１００へ渡される
ユーザのアイデンティティの証明書を確認する役割を果たす。例えば、与えられ
たトランザクションが、生体情報またはデジタルコードデータの提出を要求する
と判断した場合、クライアントワークステーション１０２は、ウェブイネーブル
ドＰＤＩサーバ２０４に対し、対応するアイデンティティ応答を送信し、ここで
これらの応答は認証マネージャー２１６によって直接処理される。

【０１０４】 図１５に示すように、認証マネージャー２１６による処理の際にはいくつかの
構成ファイルが用いられ、ファイルによってシステムのビジネスルールが特定さ
れる。これについては以下でより詳細に説明される。一般的に、テンポラリデー
タファイル４０６は認証マネージャー２１６によって、暗号化鍵データおよびフ
ォームエレメントデータを記憶するために用いられる。ログファイル４０６は、
システムメッセージ、エラー、および処理上の例外を記録するために用いられる
。テンプレートＨＴＭＬファイル４０４は、必要に応じてクライアントのワーク
ステーション１０２にマッピングされる特定のエラーページを識別する。さらに
データ記憶システム２２０は、セッション、トランザクション、生体情報、およ
び進行中の消費者のトランザクションに関するリンケージ情報を維持する。

【０１０５】 図１６は、認証マネージャー２１６の処理フローの例を示す図である。図１６
に示すように、入力がなされると、クライアントのワークステーション１０２に
よって渡されたＨＴＭＬフォームデータが抽出され、解析される（ブロックＳ９
０２）。データの利用可能性を判断できるように、このフォームデータには、提
示されている認証情報のタイプと値を識別する所定のトークンが含まれているの
が好ましい（ブロックＳ９０４）。例えば、“ＤＣ＝＜値＞”のようなトークン
は、デジタルコードエレメントおよびその対応する値を識別してもよい。同様に
、生体情報データには、生体情報ストリーム、そのバイト長、および送信される
サンプルの数が含まれ、例えば、BIO=<値>、BIO_LENGTH=<値>、BIO_SAMPLES=<値>
となる。

【０１０６】 フォームデータが読み取れない場合、または、認証マネージャー２１６に渡さ
れたデータが破損、またはフォームが不良とみなされる場合には、クライアント
ワークステーションのウェブブラウザ１０２ｃへ返信するために、ダイナミック
エラーページが作成される（ブロックＳ９０６）。

【０１０７】 フォームデータが抽出されると、対応するセッションが位置付けされて読み込
まれなければならない（ブロックＳ９０８）。セッションデータは前もって開始
された電子コマーストランザクションを識別する。このトランザクションは、認
証の証明書の受け取りと確認を要求する。セッション情報は、ウェブイネーブル
ドＰＤＩサーバ２０４とクライアントワークステーション１０２との間でやり取
りされる、隠れたフォームエレメントによって、通常、SESSION＝＜値＞の形式
で記憶される。セッション鍵＜値＞（<session>）は、セッション情報を直接位
置付けるためのルックアップ機構としてはたらく。セッション情報が現トランザ
クションに関して検索され得る場合には、さらなる処理が続く。

【０１０８】 セッションデータが現トランザクションに対して検索できない場合には（ブロ
ックＳ９０８で判断）、エラーに基づいてダイナミックウェブページが構成され
、クライアントワークステーションブラウザ１０２ｃに返される（ブロックＳ９
０６）。ダイナミックエラーページの作成は、ActiveServerPages（ＡＳＰ）の
ような、業界で利用可能な様々な技術によって、またはＣＧＩのスクリプトやプ
ログラムを介して達成できる。

【０１０９】 その後セッションの状態がチェックされ、その有効性が判断される（ブロック
Ｓ９１０）。ユーザの認証の証明書がＰＤＩシステム１００によって収集されて
評価されるときであっても、トランザクションは時間どおりに完了されなければ
ならないので、セッションには有限の有効期限が与えられる。ソースデータをウ
ェブイネーブルドＰＤＩサーバ２０４にカットアンドペーストすることを禁止す
るために、システムに対する認証の応答は、所定の時間期間内に完了されなけれ
ばならない。ランタイム構成ファイル４０２ａで詳しく説明されるように、シス
テムのビジネスルールはこの“有効期限”の長さを決定する。“タイムアウト”
を有するトランザクションは、ダイナミックウェブページに転送され、クライア
ントワークステーション１０２に対してエラーが明示される（ブロックＳ９０６
）。そのようなタイムアウトの一般的な値は、認証の証明書が通常収集される時
間によって、１〜５分の範囲にあってもよい。ユーザ認証は本質的にインタラク
ティブであることから、この値は、インターネットのようなネットワークを介す
る１つまたは複数のダイアログによって完了するのに十分な程長くなければなら
ないが、トランザクションが潜在的なハッカーによってカットアンドペーストさ
れてしまうほど長くてはいけない。

【０１１０】 セッションのタイムアウト確認と同様に、ＩＰアドレスの確認もなされる。ユ
ーザプロファイルマネージャー２１６によってセッションが作成されて記憶され
ると、オリジナルトランザクションのＩＰアドレスは、セッションデータの一部
として記憶される。認証リクエストが対応するセッションに一致するように、オ
リジナルのＩＰアドレスがトランザクションの現ＩＰアドレスと比較される。ク
ライアントのＩＰアドレスが一致する場合には（ブロックＳ９１２で判断）、ト
ランザクションフローの続行が許可される。一方、ＩＰアドレスが一致しない場
合には、ダイナミックウェブページが構成され、クライアントのワークステーシ
ョン１０２に返される（ブロックＳ９０６）。セッションが満了した場合には、
ＩＰアドレスの不一致によってトランザクションは継続することができない。一
致しないＩＰアドレスは潜在的なカットアンドペースト動作であり、有効なユー
ザの証明書の提示を免れる試みを示すかもしれない。クライアントインターネッ
トサービスが切断／再接続するようなイベントの発生にはいくつかの原因がある
。原因の如何に関わらず、ＩＰアドレスの一致はシステムのビジネスルールによ
って決定され、特定されたときには、トランザクション処理が続行を許される前
に必ず一致されなければならない。

【０１１１】 ユーザ認証のタイプは提示されたフォームエレメントによって判断される（ブ
ロックＳ９１４で判断）。認証がデジタルコードの証明書を含む場合、提示され
たデジタルコードとユーザのアイデンティティ記録の一部として記憶されたデジ
タルコードとの間の直接的な比較がなされる（ブロックＳ９４６）。図１７に示
すように、デジタルコードが一致した場合、トランザクション処理は以下に説明
されるように継続する。しかしながら、デジタルコードデータが一致しない場合
、システムのビジネスルールは、認証リクエストが許可されるための再試行の回
数を判定するよう要求される。再試行の回数が超過していない場合（ブロックＳ
９４８で判断）、現トランザクションの記録は更新され、失敗したデジタルコー
ド認証が発生したことを示す（ブロックＳ９５６）。対応するセッション記録も
更新され（ブロックＳ９５８）、システムのビジネスルールに基づいて許可され
る追加的な試行の回数を減少させる。セッションのタイムアウトもリフレッシュ
され、再試行に対してあたかもセッションが新規に開始したかのようなはたらき
をさせることができる（ブロックＳ９５８）。これらの更新が完了すると、ＰＤ
Ｉウェブサーバ２０４とクライアントブラウザ１０２ｃとの間でダイアログが再
び開始される（ブロックＳ９６０）。

【０１１２】 一方、再試行の回数がデジタルコードの収集について超過している場合、ネッ
トワークエレメント間のトランザクション関係が更新され、“認証失敗”として
記録される（ブロックＳ９５０）。例えば、現トランザクションがＩＰアドレス
206.168.56.6にリンケージ関係を有する場合には、個々の加入者のデータ記録が
更新され、このインターネットアドレスからの増加した失敗を示すであろう。個
人ごとの、このタイプの選択されたネットワークエレメント正常／失敗カウント
によって、ユーザプロファイルマネージャー２１６が、適応性のある認証プロフ
ァイルを行うことが可能となる。

【０１１３】 有効なデジタルコードの証明書を提示することなく再試行の最高回数を超えた
場合には、自動的に現トランザクションに関するセッション記録が削除され（ブ
ロックＳ９５２）、クライアントブラウザ１０２ｃに対してダイナミックなエラ
ーページが生成される。このエラーページはトランザクションが認証できなかっ
たことを示す。結果として、オリジナルの購入リクエストが支払いシステムにル
ーティングされることはなく、よってトランザクションがキャンセルされる。

【０１１４】 デジタルコードの証明書が登録されている値と正常に一致すると（ブロックＳ
９４６）、ユーザ認証が完了したかどうかをさらに判断する処理が続けられる。
ＰＤＩシステム１００が、１回の購入リクエストごとに収集するべき証明書の組
み合わせを要求するので（すなわち、PDI_AUTH_FP_DC）、生体情報認証が要求さ
れているかどうかを判断するチェックがまず行われる（ブロックＳ９６２）。こ
のトランザクションに対するセッション記録には適用されるべき必要な認証方法
が含まれる。追加的な認証が要求されない場合には、ネットワークエレメント間
のトランザクション関係が更新され、“正常に認証”として記録される（ブロッ
クＳ９６４）。認証が失敗した場合には、ネットワークエレメントは個人ごとに
更新し、時の経過とともに、適応性のある認証が進歩、強化できるようにする。

【０１１５】 デジタルコード認証が正常に一致し、それ以上の認証が要求されていない場合
には、削除前に最終組のデータがセッション記録から取り出される。セッション
記録は、ユーザプロファイルマネージャー２１２によって抽出されたオリジナル
フォームエレメントの場所を維持し、データ記憶サブシステム２２０内のテンポ
ラリファイルに記憶する（フォームエレメントデータファイル４０６ｂ）。これ
らのフォームエレメントによって、認証マネージャー２１６が、ＰＤＩシステム
１００がオリジナルトランザクションと全く関係がなかったかのように、オリジ
ナルな電子コマースの購入リクエストを再び構成することが可能になる。このデ
ータが抽出されて読み込まれると（ブロックＳ９６６）、関連するセッション記
録が即座に削除される（ブロックＳ９６８）。ＣＧＩスクリプトは、例えば、フ
ォームデータを読込み、電子店舗によってオリジナルに特定された適切な支払い
システムに対して、トランザクションを転送する（ブロックＳ９７０）。

【０１１６】 ブロックＳ９０２で、デジタルコードの受け取りと確認を受け、生体情報の収
集が必要だと判断された場合、現トランザクションが更新され、部分的なユーザ
認証が完了したことを示す（ブロックＳ９７２）。生体情報の証明書が受け取ら
れ、確認されるまで、トランザクションは不完全な状態で残される。生体情報の
暗号化が達成できるよう、この認証リクエストに対してセッション鍵が生成され
る（ブロックＳ９７４）。セッション情報も更新され、リクエストのデジタルコ
ードの部分が完了したことが示される（ブロックＳ９５８）。ここで生体情報の
証明書の収集が行われている。この時点で、ＰＤＩウェブサーバ２０４とクライ
アントブラウザ１０２ｃとの間のダイアログが再び開始され、生体情報の収集が
要求される（ブロックＳ９６０）。

【０１１７】 図１６に戻り、デジタルコードの収集に関する説明のように、ＨＴＭＬフォー
ムデータから抽出されたユーザ認証のタイプが、生体情報データが提示されてい
ることを示してもよい（ブロックＳ９１４）。トランザクション処理を続けるた
めに、提示された生体情報の証明書と与えられた消費者についてファイルされて
いる証明書との比較が行われなければならない。しかしながら、デジタルコード
の比較とは異なり、生体情報データは暗号化され、消費者のプライバシーが保護
される。ブロックＳ９０８で位置付けられた、対応するセッション記録は送信を
解読するために必要な秘密鍵ファイルの場所を識別する。このファイルは対応す
る公開／秘密非対称鍵の対であり、生体情報の認証リクエストが最初に開始され
たときに生成され、その後取り出される（ブロックＳ９１８）。

【０１１８】 秘密鍵ファイルがデータ記憶システム２２０から抽出され、ブロックＳ９０２
で受け取ったＢＩＯフォームエレメントを解読するために用いられる。解読プロ
セスのステータスは、ＢＩＯデータが送信中に修正されたかどうか、または認証
マネージャー２１６に対して情報のカットアンドペーストの試行が行われたかど
うかを判断するために評価される（ブロックＳ９２０）。生体認証のリクエスト
が生成されるたびに固有のセッション鍵が生成されるので、記憶された秘密鍵の
みが、結果のメッセージを解読することができる。ランダム化によって、確実に
セッションキーが潜在的なハッカーによって“推定”されないようになる。

【０１１９】 生体情報データが何らかの方法で損傷すると、クライアントブラウザ１０２に
、電子購入トランザクションがキャンセルされたことを示すダイナミックエラー
メッセージが返される（ブロックＳ９０６）。このタイプのエラーによって、再
試行ロジックが取り出されないようになる。なぜなら、システムは、消費者の行
うトランザクションリクエストの有効性を判断できないからである。

【０１２０】 認証マネージャー２１６は、適切な生体情報データベースから対象消費者に関
して記憶されている生体情報テンプレートを取り出す（ブロックＳ９２２）。消
費者に関する生体情報データは、前もってＰＤＩシステム１００に記録されてい
なければならず、さらに認証マネージャー２１６プロセスにアクセス可能なデー
タストア内に位置していなければならない。この生体情報データベースの物理的
な場所はＰＤＩシステム１００の設計から独立している。なぜなら、配信された
データベースまたはファイルシステム環境内に存在していてもよいからである。
認証マネージャーは、業界標準の関連データベースに対してローカルまたはリモ
ートネットワークリクエストをなすことができることが好ましく、この業界標準
の関連データベースは、ネットワーク環境のどこにも収容されることができる。

【０１２１】 生体情報テンプレートが消費者に関して回復されると、生体情報テンプレート
は提示された生体情報の証明書と比較される（ブロックＳ９２４）。生体情報デ
ータに一致するしきい値はシステムのビジネスルールによって規定され、ＰＤＩ
所有者に適用可能な確実性レベルを決定するために用いられる。しきい値の一致
は典型的には、１００万分の１または５００分の１（1:1000000または1:500）の
ような確実性の割合として表される。この確実性レベルは、生体情報の比較の成
功／失敗ステータスを判断するために用いられる。

【０１２２】 生体情報の一致が生じた場合（ブロックＳ９２６で判断）、ネットワークエレ
メントと消費者との間のトランザクションの関係が更新され、“正常な認証”と
して記録される（ブロックＳ９２８）。オリジナル購入トランザクションに関し
て保存されたフォームデータはセッションデータから抽出され、ＣＧＩスクリプ
トによって読み込まれ、電子店舗によって元々特定されている適切な支払いシス
テムに転送される（ブロックＳ９３２）。送信に先立ち、セッションが即座に削
除される（ブロックＳ９３０）。

【０１２３】 消費者のテンプレートに一致しない生体情報データ（ブロックＳ９２６で判断
）は、実行されるべきデジタルコード認証に類似した再試行ロジックを生じさせ
る。再試行の設定回数はＰＤＩシステム１００のビジネスルールによって確立さ
れ、追加的なユーザ認証リクエストが開始されるべきかどうかを制御する。再試
行の回数がすべて行われた場合（ブロックＳ９３４で判断）、ネットワークエレ
メントと消費者の間のトランザクションの関係が“認証失敗”ステータスに対し
て更新され（ブロックＳ９４２）、どのトランザクションコンポーネントも認証
できなかったことを示す。その後セッションが削除され（ブロックＳ９４４）、
トランザクションが停止されたことを示すダイナミックＨＴＭＬページがクライ
アントブラウザ１０２ｃに送信される（ブロックＳ９０６）。

【０１２４】 再試行の回数が超過していない場合（ブロックＳ９３４で判断）、現トランザ
クション記録が更新され、失敗の生体情報認証が発生したことを示す（ブロック
Ｓ９３６）。対応するセッション記録もまた更新され、システムのビジネスルー
ルに基づいて許可される追加的な試行の回数が減少する（ブロックＳ９３８）。
セッションのタイムアウトもまたリフレッシュされ、セッションが新規に開始す
るかのように再試行を機能させることができる。これらの更新が完了すると、Ｐ
ＤＩウェブサーバ２０４とクライアントブラウザ１０２ｃとの間のダイアログが
再び開始される（ブロックＳ９４０）。

【０１２５】 図１８は、ＰＤＩクライアントソフトウェア１０２ｄに対する制御フローの例
を示す図であり、ソフトウェア１０２ｄはクライアントワークステーション１０
２上に組み込まれている。一般的に、このソフトウェアによって、標準的なプラ
グインまたはＣＯＭインターフェースエレメントの使用を介して、ワークステー
ションが生体情報を収集するためにＰＤＩウェブサーバ２０４とクライアントブ
ラウザ１０２ｃとの間で通信することが可能となる。

【０１２６】 本発明の１つの例では、Netscape Communicatorのようなブラウザは、ＰＤＩ
クライアントソフトウェア１０２ｄを標準的なプラグインモジュールとして読込
み、例えばＰＤＩシステム１００に割り当てられたＭＩＭＥタイプに応答して、
ブラウザによって取り出される。消費者のブラウザが、必要なＰＤＩクライアン
トソフトウェア１０２ｄを有していない場合には、ＰＤＩ登録プロセスはこの条
件を検出できることが好ましく、指示をダウンロードして組み込むために、適切
なウェブの位置に消費者を転送することができる。

【０１２７】 割り当てられたＭＩＭＥタイプに応答したＰＤＩクライアントソフトウェア１
０２ｄの呼び出しには、ＰＤＩシステム１００によって送られたデータエレメン
トが含まれる。ユーザ認証が特定の購入トランザクションに関連付けられなけれ
ばならないので、セッション情報は直接クライアントブラウザ１０２ｃに送られ
、順番にＰＤＩクライアントソフトウェア１０２ｄへと渡される。例えば、ＰＤ
Ｉウェブサーバ２０４は、所定のＭＩＭＥタイプを特定することによって消費者
のコンピュータの生体情報ユーザ認証リクエストを開始し、リクエストに沿った
特定の状態変数を渡す。これらの状態変数にはSESSION（セッション）が含まれ
、これは購入トランザクションとENCRYPTION（暗号化）のコンテクストを識別し
、ENCRYPTIONは返されたデータに割り当てられるべき暗号化アルゴリズム／鍵サ
イズを明示する。

【０１２８】 本発明のＰＤＩクライアントソフトウェア１０２ｄには、ユーザ認証の証明書
の収集をサポートする機能が含まれていることが好ましい。ＰＤＩシステム１０
０からリクエストされた証明書の性質によっては、ＰＤＩクライアントソフトウ
ェア１０２ｄは、クライアントワークステーション１０２上のハードウェア装置
と通信することが必要とされてもよい。例えば、ＰＤＩシステムは、消費者のハ
ードウェア収集装置１０２ｂから直接指紋の生体情報データを獲得するよう構成
することができる。この状態では、ＰＤＩクライアントソフトウェア１０２ｄは
指紋読み取り装置を直接制御する。対照的に、ＰＤＩシステム１００は、標準的
なＨＴＭＬフォームの入力を通じて収集されるデジタルコードの供給のような、
単純なユーザ認証を要求してもよい。

【０１２９】 図１８に示すように、ＭＩＭＥタイプアプリケーション／x-pdi（ファイル拡
張子pdi）に応答して、例えば、ウェブブラウザ１０２ｃによって、ＰＤＩクラ
イアントソフトウェア１０２ｄを読み込むための試行がなされる。適切なプラグ
インモジュールが検索されなかった場合、またはバージョンの不一致によって正
しく読み込まれなかった場合（ブロックＳ１００２で判断）、ブラウザは、クラ
イアントソフトウェアをダウンロードするために、消費者をＰＤＩ制御の場所に
転送するよう指示される（ブロックＳ１００４）。ダウンロードされ、インスト
ールされると、消費者は、継続するためにブラウザを再スタートしなければなら
ない（ブロックＳ１００６）。

【０１３０】 適切なＰＤＩプラグインモジュールがブラウザによって読み込まれると（ブロ
ック１００８）、ＰＤＩソフトウェアと生体情報ハードウェア装置１０２ｂとの
間の通信が正しく行われているかどうかを判断する内部チェックが実行される。
これは、ハードウェアユニットを制御するドライバファイルをオープンすること
を伴う（ブロックＳ１０１０）。ドライバが正しくオープンできない場合には、
ステータスメッセージが即座にＰＤＩウェブサーバ２０４に返される（ブロック
Ｓ１０１２）。このフィードバックは、クライアントコンピュータ１０２上のハ
ードウェアまたはソフトウェアのエラーによって、ユーザ認証を続行できないこ
とを消費者に知らせるために用いられる。このようなエラーデータは、問題のあ
る装置を報告することを容易にするために用いられてもよく、消費者の注意によ
って、消費者に起因して生じたインストールの問題が処理できるようにする。

【０１３１】 生体情報装置１０２ｂおよびＰＤＩクライアントソフトウェア１０２ｄの間の
正常な通信がチェックされ、装置が収集およびアイデンティティリクエストに応
答していることが確認される（ブロックＳ１０１４）。この通信が失敗するか、
またはエラーが検出された場合、上述のようにＰＤＩウェブサーバ２０４とソフ
トウェアの間の同一のステータスメッセージが開始される。例えば、生じたエラ
ーの性質を明示する固有のステータスコードがＰＤＩシステムに返される（ブロ
ックＳ１０１２）。

【０１３２】 ハードウェア１０２ｂユニットの生体情報の収集は、すべての確認チェックが
通常どおり完了した後、本発明によって開始される（ブロックＳ１０１６）。こ
のプロセスは、現在見ているウェブページ内に直接フィードバック機構を消費者
に提供するか、またはクライアントワークステーション１０２上に別個のウィン
ドウをマッピングする。このフィードバック機構は、ハードウェアユニット上に
提示されている現指紋画像を消費者に示し、圧力とカバーレッジパラメータも同
様に示される。このフィードバックデータによって、消費者はＰＤＩクライアン
トソフトウェア１０２ｄによって提供された情報にしたがって、指の位置、圧力
の感覚、カバーレッジの配置等を調整することができる。指紋の生体情報データ
の提示は、多くの場合消費者の側で実行されることが要求されるので、このフィ
ードバックによって個人がより容易にハードウェア装置を利用できるようになる
。

【０１３３】 本発明によって、消費者は現生体情報の収集を中止することもでき、ＰＤＩに
よるクライアントブラウザ１０２ｃの制御が解除される。しかしながら、ユーザ
認証リクエストを中止することによって、認証プロセスが消費者によって手動で
停止されたことを示すステータスデータがＰＤＩウェブサーバ２０４に送られる
（ブロックＳ１０１８／Ｓ１０１２）。中止された生体情報の収集は成功しなか
ったユーザ認証とみなされ、ＰＤＩシステム１００は、システムのビジネスルー
ルに基づいて次の動作コースを決定する。

【０１３４】 ブロックＳ１０１８で判断したように、生体情報データがうまく収集されると
、情報は詳細ポイントにカプセル化される。これが指紋情報のデジタル特徴であ
る。このデータがデジタル方式で変換される方法は生体情報ユニットのハードウ
ェア製造者によって決定され、ベンダーに供給される。このユーザ認証情報のト
ランザクションに先立ち、詳細ポイントが暗号化されなければならない。暗号化
はＰＤＩウェブサーバ２０４によって送信されたパラメータによって行われ、こ
のパラメータは、使用する暗号化アルゴリズムおよび鍵サイズの性質をＰＤＩク
ライアントソフトウェア１０２ｄに指示する（ブロックＳ１０２０）。

【０１３５】 暗号化プロセスが完了すると、生体情報データはＰＤＩウェブサーバ２０４に
転送される。生体情報データには、リクエストに含まれるすべてのオリジナルセ
ッション情報が含まれる（ブロックＳ１０２２）。結果として、このユーザ認証
情報は特定の購入トランザクションに関連付けられ、提出された証明書の評価が
続けられる。

【０１３６】 上述の検討は、指紋を生体情報の認証データとして用いる本発明の例を参照し
ているが、声紋、アイパターン（網膜または虹彩）、フェイスパターン（例えば
、赤外線または視覚）、筆跡、キーストロークの入力パターン、歩き方、動作の
仕方のプロファイルなどの他のタイプの生体情報および個人識別の証明書（すな
わち、タグ）も可能であることに注意しなければならない。

【０１３７】 上記の図で示された処理の例は、例示として意図されたものであってこれらに
限定されるものではない。上述の例によって教示された後でも、上記方法に対し
て代替や削除を含む多くの変更がなされてもよいことが当業者によって認められ
るであろう。

【０１３８】 さらに、好ましい実施形態を参照して本発明が詳細に説明されたが、請求項に
よって定義される本発明の精神および範囲内で、ここに記された例に対して様々
な代替および変更がなされてもよいことが当業者によって認められるであろう。

【図面の簡単な説明】

【図１】 図１は、本発明の全体的な構成を示すブロック図である。

【図２】 図２は、好ましい実施形態にしたがった本発明の例示的な構成をさらに示すブ
ロック図である。

【図３】 図３は、本発明の１つの実施形態にしたがった、ＰＤＩシステムにより実現さ
れる例示的な方法を示す高レベルのフローチャートである。

【図４】 図４は、フィルタマネージャープロセスの例をさらに示す。

【図５】 図５は、フィルタマネージャープロセスの例をさらに示す。

【図６】 図６は、アイデンティティマネージャープロセスの例をさらに示す。

【図７】 図７は、アイデンティティマネージャープロセスの例をさらに示す。

【図８】 図８は、登録プロセスの例を示すフローチャートである。

【図９】 図９は、トランザクションルールマネージャープロセスの例をさらに示す。

【図１０】 図１０は、トランザクションルールマネージャープロセスの例をさらに示す。

【図１１】 図１１は、トランザクションルールマネージャープロセスの例をさらに示す。

【図１２】 図１２は、ユーザプロファイルマネージャープロセスの例をさらに示す。

【図１３】 図１３は、ユーザプロファイルマネージャープロセスの例をさらに示す。

【図１４】 図１４は、ユーザプロファイルマネージャープロセスの例をさらに示す。

【図１５】 図１５は、認証マネージャープロセスの例をさらに示す。

【図１６】 図１６は、認証マネージャープロセスの例をさらに示す。

【図１７】 図１７は、認証マネージャープロセスの例をさらに示す。

【図１８】 図１８は、クライアントソフトウェアプロセスの例を示すフローチャートであ
る。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ， ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，Ｊ Ｐ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ， ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，Ｒ Ｏ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ， ＹＵ，ＺＡ，ＺＷ (72)発明者 ハンキンソン、マイケル・エル アメリカ合衆国、コロラド州 80470 パ イン、マウント・エバンス・ブールバード 2186 Ｆターム(参考） 5B085 AE02 AE09 AE15 AE23 AE25 BC01 BE01 BE04 BG01 BG02 BG07

Claims (45)

【特許請求の範囲】
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. 【請求項４２】 制御装置に結合され、リクエストが不正な行動を示すかど
    うかを判断するよう構成されたユーザプロファイルサブシステムをさらに具備す
    る請求項３９記載の装置。
43. 【請求項４３】 不正な行動は、衝突違反、速度違反、カスタマイズドトリ
    ガのうち１つ以上である請求項４２記載の装置。
44. 【請求項４４】 表示は生体情報であり、複数のユーザのそれぞれに対する
    複数の生体情報を記憶するデータベースをさらに具備する請求項３９記載の装置
    。
45. 【請求項４５】 生体情報は、指紋、声紋、掌紋、アイスキャン、および筆
    跡のサンプルのうちの１つ以上である請求項４４記載の装置。