JP2005507106A - オンラインで受信する人物識別子の検証 - Google Patents

オンラインで受信する人物識別子の検証 Download PDF

Info

Publication number
JP2005507106A
JP2005507106A JP2003537232A JP2003537232A JP2005507106A JP 2005507106 A JP2005507106 A JP 2005507106A JP 2003537232 A JP2003537232 A JP 2003537232A JP 2003537232 A JP2003537232 A JP 2003537232A JP 2005507106 A JP2005507106 A JP 2005507106A
Authority
JP
Japan
Prior art keywords
sender
person identifier
person
message
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2003537232A
Other languages
English (en)
Other versions
JP2005507106A5 (ja
Inventor
ザール ウィルフ
シェークド シュバット
Original Assignee
エヌ・ピー・エックス テクノロジース リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by エヌ・ピー・エックス テクノロジース リミテッド filed Critical エヌ・ピー・エックス テクノロジース リミテッド
Publication of JP2005507106A publication Critical patent/JP2005507106A/ja
Publication of JP2005507106A5 publication Critical patent/JP2005507106A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/30—Individual registration on entry or exit not involving the use of a pass
    • G07C9/32—Individual registration on entry or exit not involving the use of a pass in combination with an identity check
    • G07C9/33—Individual registration on entry or exit not involving the use of a pass in combination with an identity check by means of a password
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Human Resources & Organizations (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Finance (AREA)
  • Operations Research (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Software Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

オンライン上で受信される人物識別子を検証するためのシステム及び方法が記載される。該方法は、人物識別子（ＰＩ１）の検証を受信すること、（a）ＰＩ１が同一人物を別の人物識別子として識別するかどうか、（b）ＰＩ１の送信者がＰＩ２の送信者と同一人物であるかどうか、（c）ＰＩ２が該送信者を識別するかどうかを推定することを含む。

Description

【技術分野】
【０００１】
本発明は、特に正当なオンライン商取引を認識する目的で、オンライン・コミュニケーションで受信される人物識別子を検証する方法及びシステムに関する。
【背景技術】
【０００２】
多くのオンライン・サービスにおいて、ユーザに関する識別情報（利用者の識別子）の収集の要求がなされる。この情報は、代金を請求するためのクレジットカード番号、商品を送るための氏名及び住所、ユーザと連絡を取るための電話番号等の項目を通常含む。
【０００３】
様々な理由で、情報収集のための主なチャンネルは、通常HTML形式のようなオンライン・フォームで、手動によりこれら情報を入力することをユーザに要求する。この方法は、ユーザの誠意に依存するので不正行為及び手動入力の際のエラーに非常に影響を受ける。
このような情報へのアクセス権を取得した、悪意のあるユーザと本物のユーザを識別する共通の方法はない。例えば、ある人物のクレジットカードの詳細情報へのアクセスができる者は誰でも、オンライン購入フォームにこれら詳細情報を入力することにより所有者の代わりに取引を行うことができる。
【０００４】
この制限のために、オンライン上のクレジットカードの不正行為は、現実の世界と比較し少なからず増加するので、オンライン取引はそれほど一般的でなく又アクセス可能でもない。この制限を克服するためにいくつかの方法が提案された。そのいくつかは、取引の前にオフラインでユーザ自身の識別を要求することが含まれる。
そのようなシステムの１つは、ビザ、マスターカード及び他の会社が開始したＳＥＴプロジェクトである。該プロジェクトは、オフラインのカード所有者に対する銀行がデジタル証明書を発行すること、これら証明書を購入者のコンピュータにインストールし取引の間確認を行うことに基づく。実際上、何百万人と予想される購入者への証明書の分配は、複雑であり費用がかかることが判明し、ＳＥＴは失敗した。
【０００５】
ビザは、安全な「スリードメインセキュアー（3-DOMAIN SECURE）」又は「スリーディーセキュアー（3D-SECURE）」と呼ばれる同様の対策を近年開始した（米国では「ビザによって検証される（Verified by VISA）」として市場に出ている）。これはＳＥＴに似ているが、発行した銀行がパスワードでオンライン上のカード所有者を証明することを可能にする。
このパスワードは、識別が証明された後、通常オンライン上で割り当てられる（例えば、カード所有者の家へ送られたクレジットカード・ステートメントに書き込まれた暗号）。このシステムは、購入者の登録を非常に単純にするが、まだ多大な労力を要する。「スリードメインセキュアー」はＰＣＴ出願第W001/82246号に記載される。
【０００６】
不正行為を防ぐ別の方法は、パターン認識と人工知能に基づく。ＨＮＣソフトウェア社による「FALCON Fraud Manager for Merchants」（かつてはeFalcon）のような、製品の中には、（ＨＮＣ社に請求することで入手可能な「Falcon Fraud Manager for Merchants White Paper」及び米国特許第５８１９２２６号に特徴が記載される）ソフトウェア、及びサイバーソース社（Cybersource）からのインターネット不正行為スクリーンのように、典型的な詐欺の取引のパラメーターを検知しようとするものもある。
そのようなパラメーターには、私書箱住所への海外発送、同一カードによる頻繁な購入を含む。これらのシステムがある程度まで不正行為を縮小することができる一方、部分的な解決だけにしかならず、また正当な取引が拒絶されることもある（この種のエラーは「偽陽性」として知られている）。
これはオンライン取引において利用可能な決定的な情報が僅かであるための結果であり、このことは、上記の分析の有効性を制限する。ＰＣＴ出願第WO01/33520号、米国特許第6029154号、米国特許第6254000号、米国特許第6095413号及びＰＣＴ出願第WO01/18718号のような、この分野での多くの発明がある。
【０００７】
他の一般的な方法は、クレジットカード発行会社によって運営される住所検証サービス（AVS）である。このサービスは、購入者から提供される住所と、定期的に請求書を発行する会社によって使用され、購入者が示すクレジットカード番号と関連する住所を比較する。一致することは、不正行為のより低い可能性を示す。この方法は、購入者の住所へのアクセスが通常困難でない場合において制限される。販売者は、確認した住所へのみ製品を発送することに決めることができる。しかし、このことはサービスを制限する。
【０００８】
ユーザに関する信頼できる、公表されない個人情報を既に有する会社は、オンライン環境においてその情報に関する質問を購入者にすることにより、ユーザの身元を確認してもよい。例えば、エキファックス（Equifax）の米国特許第6263447号により、クレジットカード会社は、ユーザが請求する、与えられたローンの状態に関する情報をユーザに求めることができる。
ＰＣＴ出願第WO01/41013号は、オンライン・オークション環境におけるこの方法の適用について記載する。
【０００９】
イリノイ州シカゴのオーセンティフィ社（Authentify, Inc.）は、オンラインで用いられた電話番号を検証する方法を提示する。ＰＣＴ出願第WO01/44940号に記載の方法によると、ユーザはオンライン中彼の電話番号を提供し、暗号を受信する。その後、電話呼び出しが該電話番号宛に行われ、ユーザは電話で該暗号を報告する。
これは、その電話番号によって識別された電話でユーザがアクセスすることを検証する。この方法は通話を行うことを必要とする点で制限される。単に電話番号を検証することができるだけという点で更に制限される。
【００１０】
カリフォルニア州パロアルトのペイパル社（PayPal, Inc）は、インターネット・ユーザを認証する別の方法を用いる。ＰＣＴ出願第W002/05224号に記載のこの方法は、販売者の名前フィールドがコードがあるクレジットカード決済の提出に基づく。
ユーザに対する請求書（オンライン上又は書類のいずれかで）を見る際に、該ユーザはオンライン上でこのコードをタイプする。このようにすることにより、ペイパル社は、ユーザがクレジットカードだけではなく請求書へのアクセスを有することを検証する。この方法は、シークレット・コードのためにユーザが積極的にクレジットカード口座をチェックする必要があり、手動でコードをオンラインで提供する必要がある点で制限されている。
更に認証プロセスには通常数日又は数週間かかる点で制限される。課せられている口座の検証者を単に検証することができるにすぎない点で更に制限されている。
【００１１】
インターネット・ユーザを認証する他の方法は、特許出願第W002/08853号、第WO01/57609号に記載される。この方法はネットワーク・アクセス・プロバイダ（NAP）との協力に基づく。NAPはユーザに関する識別情報を保持し、ユーザにネットワーク・アドレスを割り当てる。NAPは従ってネットワーク・アドレスが与えられたユーザの識別情報を検証することができる。
この方法は、識別子の検証が個人のNAPとの協調を必要とする点で制限される。この制限は、各ユーザが単一のNAP（該ユーザのインターネット・サービス・プロバイダ）を有する場合、インターネットにおいて特に重要であり、NAPの総数は多い。
【００１２】
ユーザの能動的な参加、不当な必要条件を必要とせず、リアルタイムでオンラインから受信した人物識別子の認証を正確に検証する方法が明らかに必要である。
【００１３】
（発明の要約）
本発明によると、第１人物識別子（PI1）を検証する方法であって、第１人物識別子を含む検証要求を受信し、（ａ）PI１及び第２人物識別子（PI2）が同一人物条件を満たし、（ｂ）PI1の送信者及びのPI2の送信者が同一送信者条件を満たし、（ｃ）PI2がPI2の前記送信者を識別することを含む検証条件が真であるか否か推定する方法を提供する。
【００１４】
好ましくは、この方法が、PI１がこの送信者を識別するか否かを示唆する検証報告を送信する段階を更に有し、検証報告が推定の結果に基づいて作成されている。
【００１５】
好ましくは、検証要求が（ａ）PI2、（ｂ）PI1に関する第１送信者指示子、（ｃ）PI2に関する第２送信者指示子と、（ｄ）PI2のための検証情報の少なくとも１つを含む。
【００１６】
好ましくは、推定が、（ａ）少なくとも１つのクエリーを少なくとも１つの人物識別子−送信者指示子データベースへ送信し、（ｂ）少なくとも１つのクエリーに対する少なくとも１つの応答を受信することを更に含む。
好ましくは、クエリーが、検証条件として少なくとも１つ記載される条件クエリーである。
【００１７】
好ましくは、推定が更に、前記少なくとも１つのクエリーに対する少なくとも１つの応答が、前記少なくとも１つのクエリーに記載された前記少なくとも１つの検証条件以外の少なくとも１つの検証条件を満たす。
【００１８】
好ましくは、PI1及びPI2が、下記に構成されるグループから選択される２つの人物識別子の間における少なくとも１つの関係を含む同一人物関係を有する場合に、前記同一人物条件が満たされる。（ａ）前記２つの人物識別子が識別部を含む、（ｂ）前記２つの人物識別子がスペルによる相違以外の識別的な部を含む、（ｃ）前記２つの人物識別子の一方が、前記２つの人物識別子の他方の省略形を含む、（ｄ）前記２つの人物識別子が番号が近似する電話番号である、（ｅ）前記２つの人物識別子が地理的に近似する地理的パラメーターを含む、（ｆ）ディレクトリ記録が、前記２つの人物識別子の一方の同一人物関係を有する人物識別子と、前記２つの人物識別子の他方の同一人物関係を有する他の人物識別子を関連させる、（ｇ）前記２つの人物識別子の各々が、第３人物識別子の同一人物関係を夫々有している。
【００１９】
好ましくは、PI1を包含するメッセージ及びPI2を包含するメッセージが、前記第１メッセージ及び第２メッセージの間において、下記に構成されるグループから選択される少なくとも１つの関係を含む同一送信者関係を有している場合に、前記同一送信者条件が満たされる。（ａ）共通の不可欠メッセージに於ける前記第１メッセージ及び第２メッセージの構成員、（ｂ）前記第１メッセージが送信された時刻及び前記第２メッセージが送信された時刻の間における関係、（ｃ）前記第１メッセージの送信者の信頼できるネットワーク・アドレス及び前記第２メッセージの送信者の信頼あるネットワーク・アドレスの間における関係、（ｄ）前記第１メッセージに含まれる第１シークレットと前記第２メッセージに含まれる第２シークレットが共通のシークレットから派生したものである、（ｅ）前記第１メッセージの送信者へ送信された第１シークレット及び前記第２メッセージに包含される第２シークレットが共通のシークレットから派生したものである、（ｆ）各前記メッセージが、夫々第３メッセージの同一送信者関係を有している。
【００２０】
好ましくは、前記第１メッセージの前記送信者の前記信頼あるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼あるネットワーク・アドレスの間における前記関係が下記に構成されるグループから選択される少なくとも１つの関係を含んでいる。（ａ）前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスの識別である、（ｂ）前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスの共通するサブ−ネットワークにおける構成員である、（ｃ）同一組織による、前記第１メッセージの前記送信者の前記信頼あるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスを使用する、（ｄ）２つの関連する組織による、前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスを使用する、（ｅ）共通のインターネット・サービス・プロバイダによる、前記第１メッセージの前記送信者の前記信頼あるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスを使用する、（ｆ）現存する共通のインターネット・サービス・プロバイダ・ポイントによる、前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスを使用する、（ｇ）前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスに近似する地理的な位置に関連する。
【００２１】
好ましくは、少なくとも１つの前記信頼のあるネットワーク・アドレスが、IPアドレス、UDPポート番号を伴うIPアドレス、TCPセッション・ハンドル及び物理的インターフェース識別子からなるグループから選択される信頼できるネットワーク・アドレスである。
【００２２】
好ましくは、少なくとも１つの前記第１及び第２シークレットが、装置により維持されるシークレット、シークレットHTTPクッキー、シークレットHTTPセキュア・クッキー、SMTPヘッダ、HTTPヘッダ、ハードウェア識別子、前記装置にインストールされるソフトウェア要素において維持されるシークレット、オンライン使用のための人物を割り当てるシークレット、ユーザネームとパスワード、シークレットURL、ネットワーク・アドレス、IPアドレス、UDPポート番号及び、TCPセッション・ハンドルからなるグループから選択されるシークレットである。
【００２３】
好ましくは、下記に示す少なくとも１つが真である場合に、PI2が、その前記送信者を識別しているとみなす。（ａ）PI2が、人物識別子の検証のために標準の方法を使用することを検証された、（ｂ）PI2が、PI2を基にする正しいオフライン・アクションを実行することによって検証された、（ｃ）PI2が、正しく口座に課金されることによって検証された、（ｄ）PI2が、メーリング・アドレスへ送信されるオンライン・コードを受信することによって検証された、（ｅ）PI2が、電話呼び出しへ送るオンライン・コードを受信することによって検証された、（ｆ）PI2が、電話呼び出しの間に、オンラインへ送信されたコードを受信することによって、検証された、（ｇ）PI2が不正行為の特殊なタイプの条件において受信された、（ｈ）PI2が、PI1が送信されるかなり前に送信された、（ｉ）PI2が、不正行為者が不正行為を行う気持ちを欠乏させるサービスへ送られた、（ｊ）PI2が、合法的なユーザの典型的且つ有効なオンライン行為と関連する、（ｋ）PI2が、PI2の前記送信者の信用に値する認可されたエージェントであった、（ｌ）PI2が本発明を使用することによって検証された。
【００２４】
好ましくは、推定が、下記に構成されるグループから選択される少なくとも１つの推定方法を使用することに影響を受ける。（ａ）法則に基づいた論理、（ｂ）自動学習テクノロジ、（ｃ）ニューラル・ネットワーク及び（ｄ）確率論的解析。
好ましくは、前記検証報告が、下記に構成されるグループから選択される少なくとも１つの情報要素を含んでいる。（ａ）肯定的な応答、（ｂ）否定的な応答、（ｃ）PI2、（ｄ）PI2に関する送信者指示子、（ｅ）PI2の検証情報、（ｆ）PI1及びPI2が同一人物条件を満たす確率を記載するスコア、（ｇ）PI1の前記送信者及びPI2の前記送信者が同一送信者条件を満たす確率を記載するスコア、（ｈ）PI2がPI2の前記送信者を識別する確率を記載するスコアと、（ｉ）PI1がPI1の前記送信者を識別する確率を記載するスコア。
【００２５】
PI1がPI1の前記送信者を識別する前記確率が記載されるスコアが、下記に構成されるグループから選択される少なくとも１つのパラメータに基づいている。（ａ）PI1及びPI2が同一人物条件を満たす確率、（ｂ）PI1の前記送信者及びPI2の前記送信者が同一人物条件を満たす確率、（ｃ）PI2がPI2の前記送信者を識別する確率、（ｄ）前記同一送信者条件の基本とされるシークレットとのアクセスを得る困難性、（ｅ）PI1の前記送信者のアドレスにおける信頼性、（ｆ）PI2の前記送信者のアドレスにおける信頼性、（ｇ）推定の前記段階において使用される永久のデータ・ソースの正確度及び信頼性、（ｈ）PI1の大衆性、（ｉ）PI2の大衆性、（ｊ）人々が人物識別子を変更する傾向性、（ｋ）PI1の送信及びPI2の送信の間における経過時間、（ｌ）PI2により識別される口座に課金されたときからの経過時間。
【００２６】
好ましくは、前記推定が、更に、（ａ）少なくとも１つの人物識別子ディレクトリへ、少なくとも１つのクエリーを送信し、（ｂ）前記少なくとも１つのクエリーに対する前記少なくとも１つの応答を受信することを含む。
好ましくは、更に、下記に構成されるグループから選択される少なくとも１つの情報要素の少なくとも一部における、少なくとも１つのハッシュを発生する段階を含む。（ａ）PI1、（ｂ）PI2、（ｃ）PI1に関する第１送信者指示子と、（ｄ）PI2に関する第２送信者指示子。
【００２７】
好ましくは、更に、下記に構成されるグループから選択される少なくとも１つの考慮事項に基づいて、少なくとも１つの前記ハッシュのサイズを決定する段階を有する。（ａ）機密情報、（ｂ）偽検証の許容レベル。
好ましくは、PI1の前記送信者からのPI1を受信するエンティティが、PI2の前記送信者からのPI2を受信するエンティティと異なっている。
好ましくは、推定が行われる段階が、PI2以外の少なくとも１つの人物識別子を伴い繰り返される。
【００２８】
好ましくは、推定が行われる前記段階においてPI2として使用するために、複数の人物識別子から１つの人物識別子を選択する段階を更に含む。
好ましくは、PI1の前記送信者から少なくとも１つの送信者指示子を取得する段階を更に含む。
好ましくは、推定の結果と人物識別子を検証する少なくとも他の方法の結果を結合する段階を更に含む。
【００２９】
PI1及びPI2からなるグループから選択される少なくとも１つの人物識別子が、下記に構成されるグループから選択される少なくとも１つの情報要素を含む。フルネーム、ファーストネーム、ミドルネーム、ラストネーム、イニシャルネーム、肩書き、住所、国、州、市、ストリート・アドレス、部屋番号、郵便番号、電話番号、Ｅメール・アドレス、金融口座番号、クレジットカード番号、銀行口座番号、政府発行の識別子、社会保障番号、運転免許書番号、国家ID番号、パスポート番号、個人の特徴、身長、体重、性別、外観、人種及び頭髪の色。
好ましくは、PI1が、インターネット、プライベート・データ・ネットワーク、CATVデータ・ネットワーク及びモバイル・データ・ネットワークからなるグループから選択されるネットワークを介して送信される。
【００３０】
本発明によると、第１人物識別子を検証するシステムであって、（ａ）PI1を含む検証要求を受信する受信手段と、（ｂ）PI1及びPI2が同一人物識別子条件を満たすか否かを推定するため、PI1の送信者及びPI2の送信者が同一送信者条件を満たすか否かを推定するため及びPI2がPI2の前記送信者を識別するか否か推定するための検証推定手段を有する。
好ましくは、システムが、検証報告が前記検証推定手段の出力を基にして形成され、PI1がPI1の前記送信者を識別するか否かを指示する検証報告を送信する報告手段を更に有する。
【００３１】
好ましくは、システムが、人物識別子ディレクトリへクエリーを送信するとともに、前記検証推定手段により使用され且つ該クエリーに対する応答を受信する人物識別子ディレクトリクエリーモジュールを更に含む。
好ましくは、システムが少なくとも１つの人物識別子ディレクトリを含む。
【００３２】
好ましくは、システムが、少なくとも１つの人物識別子送信者指示子データベースへクエリーを送信するとともに、前記検証推定手段により使用され且つ前記クエリーに対する応答を受信する少なくとも１つの人物識別子送信者指示子データベースクエリーモジュールを更に有する。
好ましくは、システムが少なくとも１つの前記人物識別子送信者指示子データベースを含む。
好ましくは、システムが、下記に構成されるグループから選択される少なくとも１つの情報要素の少なくとも一部を有する少なくとも１つのハッシュを発生させるハッシュ発生手段を含む。（ａ）PI1、（ｂ）PI2、（ｃ）PI1に関する第１送信者指示子と、（ｄ）PI2に関する第２送信者指示子。
【００３３】
本発明に関するシステムが、好適にプログラムされたコンピュータであることを理解することができる。このように、発明が、発明の方法を実行するためのコンピュータにより読み出し可能となるコンピュータプログラムを利用する。発明は、本発明の方法を実行するための機械により実行可能な機構のプログラムを明確に実行する機械読み取り可能な記憶素子を利用する。
【００３４】
本発明は、従来技術と比して数点の優位点を有している。１つの優位点はシステム及び方法が、ソフトウェア又はハードウェアのインストール、登録、パスワードの入力等のユーザからのあらゆる活動的な関与を通常必要としないことである。他の優位点は、システム及び方法が、人物識別子を検証する１つの特定のエンティティによる連携に依存しないことである。他の優位点は、容易にアクセスすることができない不許可部分である識別情報を検証するユーザ装置により保持されるシークレットに依存しているので、システム及び方法を欺くことが相対的に困難であることである。
【００３５】
（発明の詳細な説明）
本発明を理解し、どのように実際に実施されるのかを確かめるために、好適な実施形態が付随の図面を参照し本発明を制限しない例示の目的のみで示される。
発明者は、オンライン・コミュニケーションで受信した他の人の識別子の分析を通じて達成された、オンライン・コミュニケーションで受信した人物識別子を検証するための方法を開発した。
（略語の解説）
以下の略語が本明細書中で用いられている。
AVS アドレス検証サービス
CATV ケーブルテレビ
CPU 中央演算装置
DNS ドメイン・ネーム・システム
FPS 不正予報サービス
FTP ファイル転送プロトコル
FVW 頻繁に訪問されるウェブサイト
HTML ハイパーテキスト・マークアップ言語
HTTP ハイパーテキスト転送プロトコル
HTTPS HTTPセキュア
IMC インスタント・メッセージ・クライアント
IMS インスタント・メッセージ・サービス
ISN イニシャル・シーケンス番号
ISP インターネット・サービス・プロバイダ
MAC メディア・アクセス・コントロール
MIME 多目的インターネット・メール拡張子
NAPT ネットワーク・アドレス・ポート変換
OBPS オンライン・ビル・プレゼントメント・システム
OSP オンライン・サービス・プロバイダ
PI 人物識別子
PI2VI PI2 検証情報
PISIDB PI-SIデータベース
POP アクセス・ポイント
PTC PI2は、真条件
RFC コメント要求
SI 送信者指示子
SMTP シンプル・メール転送プロトコル
SPC 同一人物条件
SPR 同一人物関係
SSC 同一送信者条件
SSN 社会保障番号
SSO シングル・サインオン・サービス
SSR 同一人物関係
TCP トランスミッション・コントロール・プロトコル
TLS トランスポート層セキュリティ
UDP ユーザ・データグラム・プロトコル
URL ユニフォーム・リソース・ロケーター
WEBS Ｅメール・サービスに基づくウェブ
【００３６】
（環境）
図１は、システムが稼動する環境を示す。ユーザ１０は、ユーザ・デバイス１２を使用するインターネット２０に接続している。通常、他の多くのユーザも、インターネット２０に接続している。ユーザ１０は、ユーザ・デバイス１２を使ってインターネット２０でメッセージを送受信する人物である。本件発明においては、人（person）という用語は、到達メッセージを送信及び／又は処理するために、メッセージを作成するデバイスも指す。ユーザ・デバイス１２のタイプの例としては、モデムとブラウザを有するＰＣ，双方向テレビの端末、微小ブラウザを有する携帯電話などがある。オンライン・サービス・プロバイダ１４（OSP）も又インターネット２０に接続されており、ユーザ１０に対して役目を果たしている。OSP１４は、例えばオンライン取引やオークション・サイト、オンライン・バンク、オンライン・クレジットカード発行、支払いサービスプロバイダのような電子商業サービスなど、ユーザの情報を検証する必要があるどのようなエンティティであってもよい。
【００３７】
検証システム３０は、本件発明を実行するシステムであり、OSP１４にアクセス可能である。OSP１４は又インターネット２０に接続されるようにしてもよい。ここで使用されている通り、「インターネット」という用語は、ユーザとOSPが通信可能な他のどのようなデータ・ネットワークをも指している。
【００３８】
（情報の関係）
（情報の要素及びエンティティ）
図２は、この発明にかかる、人物識別子の検証を可能にする情報要素とエンティティとの関係を示している。
PI1 １００は、送信者PI1 １０４によって送信され、OSP１４によって受信される人物識別子である。人物識別子（PI）は、情報要素あるいは何人かの人物を示す一連の情報要素である。例えば、名前（ファーストネーム、ミドルネーム、ラストネーム、イニシャルネーム、肩書きなど）やアドレス（国、州、都市、ストリート・アドレス、部屋番号、郵便番号など）、電話番号、金融口座番号（クレジットカード番号、銀行口座番号など）、政府発行の識別子（社会保障番号、運転免許証番号、国民ＩＤ番号、パスポート番号など）、個人の特徴（身長、体重、性別、概観、人種、頭髪の色など）及びそれらの情報要素の組み合わせなどである。更にPIは、以下に示すように、PIディレクトリを通してPIと関連付けられるどのような情報要素とすることもできる。
【００３９】
OSP 14は、PI1 １００を検証しようとする。PI検証は、PIが真か偽かを推定するプロセスである。真のPIは、その送信者を識別する（すなわち、送信者を示す）PIであり、偽PIは、送信者を識別できないPIである。
【００４０】
PI1 １００により識別される人物になりすまそうとする不正行為者によって送信されたものとOSP１４が疑っている場合、あるいはPI1 １００が意図しないエラーを含んでいるとOSP１４が疑っている場合には、PI1 １００は検証を必要としてもよい。単純な理由により、不正の可能性がある場合についてのみ、以下に論じる。意図しないエラーの場合についての拡張解釈は当業者にとっては明らかだからである。
【００４１】
例えば、PI1 １００が、オンライン購入プロセス、あるいはオンライン・バンキング・サービスへの登録、クレジットカードのオンライン申込みなどに関連して提供されたものであるならば、検証を必要としてもよい。
【００４２】
PI2 １０２は、PI2 １０６の送信者によって送信された別のPIである。PI2 １０６は、OSP１４によって受信されるようにしてもよいし、別のオンライン・サービス・プロバイダによって受信されるようにすることもできる。PI2 １０２は、通常PI1 １００よりも前に受信されるが、PI1 １００より後でも受信可能である。
例えば、PI2 １０２は、オンライン購入プロセス、あるいはソフトウェアのインストール、オンライン・サービスへの登録などの間に受信されるようにしてもよい。
下記の通り、PI1 １０４の送信者は、ユーザ１０であり、またPI2 １０６の送信者は、ユーザ１０であってもよいし、そうではなくてもよい。
【００４３】
場合によっては、PI1 １００或るいはPI2 １０２の実際の送信プロセスは、直接PI1 １０４の送信者及びPI2 １０６の送信者によってなされるのではなく、権限が与えられた代理人によって行われるようにしてもよい。例えば、子供を何らかのサービスに登録するため、子供の詳細情報をオンライン・サービスに提供することもあるからである。また別の例を挙げると、企業のシステム・アドミニストレーターが、新規被雇用者の詳細情報をその企業のＥメール・サーバに登録し、被雇用者がＥメールを受信できるようにしてもよい。そのような場合、PIを送信した人物がそのPIを提供する権限が本当に与えられている限り、送信者は技術的に（technically）送信した人物ではなく、PIが提供されているその人物であるとみなす。
【００４４】
（検証条件）
本件発明においては、次の事項をチェックすることにより、PI1 １００を検証する。
１．I1 １００及びPI2 １０２は、同一人物を検証する（同一人物条件−SPC）。
２．I1 １０４の送信者は、PI2 １０６の送信者と同一人物である（同一送信者条件SSC）。
３．PI2 １０２は、PI2 １０６の送信者を識別する（PI2は、真条件であるPTC）。
【００４５】
これらの条件（検証条件）が満たされれば、PI1 １００は、PI2 １０２と同一人物と識別され、PI2 １０６の送信者を識別するが、その送信者は、PI1 １０４の送信者と同一人物である。したがって、PI1 １００は、PI1 １０４の送信者を識別し、このことは、PI1 １００が真であることを意味する。
【００４６】
検証条件を満たすことは、自分自身の人物識別子を提供する場合に比べて、不正行為者が他人の人物識別子を提供する場合の方が、より難しい作業となる。それゆえ、検証条件は、以下に詳細に記す通り、不正行為者にとっての最大の困難さと通常の人々の最小の困難さを示すことにより定義できる。
【００４７】
検証条件の強度は、それが真である確率として定義できる。その検証条件の強度は、不正行為者が首尾よく検証条件を満たすことの困難さに依存している。
【００４８】
（同一送信者条件）
（定義）
検証が成功するには、PI1 １０４の送信者がPI2 １０６の送信者と同一であることが必要である。これが、同一送信者条件（SSC）である。SSCは、PI1 １００を含むメッセージとPI2 １０２を含むメッセージが同一送信者関係（SSR）を有する場合に満たされる。この場合、メッセージを通信メディアを通じて送信された情報として定義する。２つのメッセージが同じSSRを持つかどうかを調べるにはいくつかの方法がある。
【００４９】
（一体メッセージ（integral message））
１つの方法は、一人の送信者を含むことで知られる（あるいは含むと考えられる）一体のメッセージの一部である２つのメッセージに基づく。一体メッセージは、送信中に書き換えることができない（あるいは比較的書き換えが難しい）メッセージである。例えば、パケット交換ネットワークにおいて、不正行為者は、パケットの通り道であるネットワーク装置にアクセスし、送信中にパケットを書き換えようとするが、通常これは困難である。それゆえ、１パケット中の全ての情報は、同じ送信者から送信されたものとみなされる。別の一体メッセージの例は、メッセージの完全な状態を維持するための暗号化手法を用いて署名される情報である（例：RFC2104に記載のHMACアルゴリズム、あるいはイスラエル特許No.4405829に記載されているRSA署名）。
この場合、（SSCの強度を決める）SSRの強度は、ほとんど送信中の一体メッセージを書き換える難しさに依存する。
【００５０】
また別の方法は、２つのメッセージが互いに関連づけされている２つの情報要素間の関係を調べるものである。２つのメッセージが同じ送信者から送信されたかどうかを判定するのに用いられるこのような情報は、全て送信者指示子（SI）とよばれる。SIは、メッセージ内に含めて（例えば、同じ一体メッセージの一部として）受信することができ、メッセージ外に添付して（例えば、どのような物理的接続で、いつ、どのようにメッセージが受信されたか）受信することもできる。PI1 １００を含むメッセージに関連するSIは、SI1と名付けられ、PI2 １０２を含むメッセージに関連するSIは、SI2と名付けられる。
【００５１】
（同一シークレット）
SIの検討の１つの例において、２つのメッセージは、各々が同一シークレットを含んでいるならば、同じ送信者からのものであるとみなされる。シークレットとは、公には（特に不正行為者には）容易にアクセスできない情報要素である。この場合、SIは、同一シークレットの２つの概観（あるいは、以下に記載の通り、その派生物）であり、そのSSRの強度は（傍受や送信者の装置へのアクセス、あるいは推測などにより）シークレットへアクセスできる難しさに依存している。
【００５２】
同一シークレットの派生物が、（シークレットを知らない）一般の人々が容易にアクセスできないものである限りにおいて、シークレットそのもののかわりに、２つのメッセージのいずれか、あるいはその両方に現れる可能性があることを注記しておく。１つの例において、派生物がシークレットの代わりに現れる。なぜならば、それが（以下に記載する）TCPの連続番号のような別の目的にも使用されるからである。また別の例では、送信元が第１の通信においてシークレットを送信する前に、この手法を傍受に対して強化するために、そのシークレットを暗号に置換する。このことにより、第１の通信を盗み取った不正行為者は、暗号化キーを知らないため、派生物を作成することができない。この例において、この手法の実施には、派生物を検証する暗号化キーが必要となる。
【００５３】
単純な理由により、用語「シークレットの派生物」は、シークレットそのものにもあてはまる。
（信頼性のあるアドレス）
また別の例においては、信頼性のあるネットワーク・アドレスが２つのメッセージそれぞれに与えられているならば、２つのメッセージがひとつのSSRを有しており、その２つのアドレスは、２つのランダムなアドレスよりも同一送信者によって使用されやすい。アドレスは、不正行為者が容易に偽造できないものであれば、信頼性があるとみなされる。この場合において、SIは、２つの信頼性のある送信者アドレスであり、そのSSRの強度は、アドレスの信頼性、及び送信者とアドレスとの相関関係に依存している。
【００５４】
（割り当てられたシークレット）
また別の例においては、シークレットが第１のメッセージの送信者に送信され、更にシークレット（またはその派生物）が第２のメッセージで受信されるのであれば、２つのメッセージは同じ送信者からのものであるとみなされる。この手法を用いるのは、シークレットがメッセージの本当の送信者に送信されたことを確かめることができるよう（さもなくば、シークレットが信頼性が弱まる）、「信頼性のあるアドレス」を達成できるか次第である。この場合において、１つのSIは、第１のメッセージの送信者に送信されるシークレットであり、もう一方のSIは、第２のメッセージに現れるシークレットあるいはその派生物である。SSRの強度は、シークレットにアクセスする難しさに依存する。シークレットは、ひとつのアドレスに送信されるので、この難しさは、アドレスの信頼性にも依存し、そのアドレス宛のメッセージを盗み取ることができる可能性にも依存する。
【００５５】
ここで注記しておきたいのは、２つのメッセージが、必ずしも同一エンティティによって受信されたものではないということである。例えば、「同一シークレット手法」において、同じシークレットを含む２つのメッセージは、２つの異なるエンティティに送信することもできる。２つのエンティティは、それらシークレットが符合することを検証するために働き合わなければならない。例えば、ひとつのエンティティが受信したシークレット（あるいはその派生物）を、第２のエンティティに送信し、第２のエンティティは、それを受信したシークレットと比較する。
【００５６】
同一送信者からのメッセージに関連するいくつかのSIは、時間によって変わるようにしてもよい（例えば、ユーザのネットワーク・アドレスが変わるかもようにしてもよい。また同一シークレットを時間によって別のユーザに割り当ててもよい）。このような場合、SSRの強度は、２つのメッセージが送信される間に経過した時間に依存し（時間が短ければ、それだけ強い関係になる）、それゆえ、それぞれのメッセージがいつ送信されたか（これは、通常メッセージが受信された時刻から推定される）を知ることは非常に有用かもしれない。
【００５７】
PI1 １０２及びPI2 １０２は、それぞれに関係する１つ以上のSIを有し、それぞれのSI1は、２つのメッセージが１つのSSRを有するかどうかを調べるためにそれぞれのSI2と組み合わせて使用されるようにしてもよい。更に、SI1及びSI2のそれぞれの一対の組み合わせは、一通り以上に関連させてもよい。例えば、以下に記すように、SI1及びSI2は、「同一シークレット」関係及び「信頼性のあるアドレス」関係を有するようにしてもよい。通常、与えられたPI1 １００及びPI2 １０２のSI1、SI2間のそれぞれの追加の関係の存在は、SSRを強くする。複数関係により示される正確な強度は、それらの相互関係のレベルによる。
【００５８】
一般的に、SIがより共通のものであれば（すなわち、より多くの人のメッセージにふくまれているならば）、SSRは、それだけ弱くなる。なぜならば、異なった人たちからのメッセージが同一人物からのものであるとみなされる可能性が高くなるからである。
SIとして使用されるシークレットは、ユーザ間においてなんらかの形で保持しておくべきである。シークレットは通常、ユーザ・デバイス１２に保存されるか、ユーザ１０によって記憶される。
以下は、これらの手法の実施例である。
【００５９】
（IPアドレス）
インターネット・プロトコル（IP；RFC791参照）データグラム（又はパケット）は、送信者のIPアドレス（「ソース・アドレス」）を、各データダイアグラムの「ソース・アドレス」領域に有する。通常、不正行為者がなりすまそうとする人物のソース・アドレスを見つけるのは簡単なことではないから、ソース・アドレスを、シークレットとして使用することが可能である。例え送信者がこの領域を完全に制御できたとしても「ソース・アドレス」を「信頼性のあるアドレス」として用いることもできる。なぜなら、いくつかのIPネットワークが、なりすましを疑って、IPパケット（すなわち、ソース・アドレスがパケットの送信者に割り当てられていないパケット）の通信を拒否して、不正行為者がこのようなパケットを送信するのを困難にするからである。ネットワーク全てがそのような手段をとるわけではないから、ソース・アドレスは比較的信頼性の弱い「信頼性のあるアドレス」である。
【００６０】
「信頼性のあるアドレス」としてのIPアドレスの信頼性は、「シークレット・ハンドシェイク」を実行することにより増大する。「シークレット・ハンドシェイク」は、あるアドレスにシークレットを送信し、シークレット（又はシークレットから導かれるもの）が返ってくるのを受信するプロセスである。ほとんどのIP環境では他のユーザに送られたメッセージを傍受するのは難しい。従って、このプロセスでは、シークレットが送り返されたメッセージ（及びシークレットを持つ内部メッセージに含まれた全てのメッセージ）はシークレットを受信したときにこれを送信したIPアドレスを用いているユーザに送信されることが分かる。
【００６１】
２つのメッセージに関連した２つのIPアドレスの関係の強さは、ネットワーク上でIPアドレスが割り当てられ用いられた方法に依存している。インターネットでは、IPアドレスはインターネット・サービス・プロバイダ、会社及び他の機関（オーナー）に割り当てられ、これらの機関が自らのユーザにIPアドレスを割り当てる。ユーザへのIPアドレスの割り当ては通常、一時的で、それらの有効期間は様々である。ある場合では、アドレスは、何ヶ月か何年かの間、同一のユーザに割り当てられ使用される。
一方、他の場合ではアドレスは数分の間、同一ユーザに用いられる。従って、同一アドレスが、時間により異なるユーザに対して役目を負うことができる。マルチユーザ・コンピュータで、これらのコンピュータがネットワーク・アドレス・ポート変換（NAPT；RFC2663参照）に接続されているときに、同一のアドレスが一度に何人かのユーザに対する役目を負うこともできる。同じアドレスを使用しているユーザ数を推定することは、関係の強度解析に関して有益である。
【００６２】
２つのIPアドレスが同一で信頼性があるなら、通常、強い関係であるとされる。関係の厳密な強度（２つのメッセージが同じ送信者により送信された可能性の程度）は、２つのメッセージが送信される間に経過した時間（短いほど関係が強い）、IPアドレスが割り当てられた期間（期間が長いほど関係が強い）、該IPアドレスを同時に使用しているユーザの数などに依存している。該IPアドレスの所有者をチェックすることによりIPアドレスが割り当てられた期間を正しく推定することが可能なときもある。前記IPアドレスは、リバース・ドメイン・ネーム検査（リバースDNSクエリーとも呼ばれる；RFC1034及びRFC1035参照）又は「フーイズ」検査（RFC954及びアムステルダムのRIPE、The Netherlands document ripe-238参照）により検出される。例えば、通常、ホーム・ユーザに対して役目を果たすインターネット・サービス・プロバイダ（ISP）により所有されるIPよりも、会社の所有するIPはその使用者（被雇用者）に長期間割り当てられる。
【００６３】
IPアドレス間の別の関係は、ユーザが異なるIPアドレスを割り当てられる場合でさえ、IPアドレスが同一のエンティティによって割り当てられるという仮定に基づく。例えば、異なる場所に接続する時、通常ユーザは同一のISPを使用し、従業員は同一の会社のネットワークを使用する可能性がある。
【００６４】
従って、同一のISP、ISPの同一のポイント・オブ・プレゼンス（POP）、同一の組織、２つの関連する組織によって用いられる２つのIPアドレス、又は同一のサブ・ネットワークに属することは、これらの関係を有さない２つのIPアドレスよりも同一の送信者を示す可能性が高い。
番号が近い（特に多数の最も重要なビットが同一の場合）IPアドレスは、通常複数のIPアドレスが１又はそれ以上の連続するブロックの中で割り当てられるので、更にこの関係を有する。
【００６５】
更に、ユーザが異なるエンティティを介して接続しても、２つのエンティティは接近する地理的位置（例えば、ユーザが自宅で用いるISP POP、彼が職場で用いる企業ネットワーク）に位置すると仮定することができる。
アカマイ テクノロジー社（Akamai Technologies Inc.）のエッジスケープ（EdgeScape）又はインフォスプリット社（InfoSplit Inc）のネットロケータ（NetLocator）のように、製品の中にはIPアドレスに地理的位置を関連させることに特に適しているものもある。
上記の逆のDNS検査及び「フーイズ」検査は、更にIPアドレスに地理的位置を関連させる点で役立てることができる。
【００６６】
当然、大量のIPアドレスが同一の送信者だと考えられるIPアドレス間の関係は、被害者のメッセージに付くSSRを有するメッセージを送信するためのより多くのオプションで不正行為者を示すのでSSRを弱くする。
例えば、IPアドレスが同一である関係は、IPアドレスが同一の所有者を有する関係より折り合いを付けることがより困難である。
【００６７】
ユーザにアドレスを割り当てるエンティティは、同一のユーザに関連するIPアドレスを割り当てることによりIPアドレス間の関係を検出する点で役立てることができることに留意すべきである。
例えば、ISPはユーザ名及びパスワード（しばしば、RFC 1334に記載されたパスワード認証プロトコルかチャレンジ−ハンドシェイク認証プロトコルを用いて行われる）を用いるユーザを識別することが可能であり、次に該ユーザにIPアドレスを割り当て、該アドレスは過去にユーザに割り当てられたIPアドレスと数値が近い。
他の例において、組織のダイナミックホスト構成プロトコル（DHCP、RFC２１３１を参照せよ）サーバは、イーサーネット（登録商標）・メディア・アクセス・コントロール・アドレス（MAC、IEEE 802.11基準に記載される）を用いるパーソナル・コンピュータを識別し、IPアドレスに割り当て、コンピュータが関連する結果を生じるように割り当てられたIPアドレス上の逆のDNS検査が組織のDNSサーバをアップデートすることができる（ダイナミックDNSアップデートはRFC２１３６に記載される）。
【００６８】
（物理インターフェース識別子）
メッセージを受け取るためにいくつかの物理的なコミュニケーション・インターフェースが用いられ、通常同一の送信者からのメッセージが同一のインターフェース（例えば、各インターフェースは、ネットワークにおける地理的に異なるエリアに接続された場合）上で受信される時に、物理的なインターフェース識別子は、SIが示す「信頼できるアドレス」として用いることができる。
この場合SIは受信したメッセージに含まれないが、局所的に発生し、各メッセージと関連する。
【００６９】
（UDPポートナンバー）
ユーザ・データグラム・プロトコル（UDPはRFC７６８を参照せよ）は、しばしばインターネットのようにIPネットワークを越えて通信するために用いられる。
UDPデータグラムは、各データグラムの「ソース・ポート」領域に送信者のUDPポート番号を含んでいる。不正行為者が、騙そうと試みている人物によって用いられるポート番号を発見することは、通常簡単ではないため、UDPソース・ポート番号はシークレットとして用いることができる。
通常はポート番号の意味は、特別のIPアドレスの前後にあるので、UDPソース・ポート番号は、同一のデータグラムのIPソース・アドレスと結合して用いられる。
【００７０】
（TCPセッション・ハンドル）
送信コントロール・プロトコル（TCP、RFC793を参照せよ）は、しばしばインターネットのようなIPネットワーク上で通信するために用いられる。TCPは、「割り当てられたシークレット（Assigned Secret）」方法、「同一のシークレット（Same Secret）」方法及び「信頼できるアドレス」方法を実行する。
TCPは、シークレット・ハンドシェーク機構を含み、該機構の各ホストはイニシャル・シーケンス・ナンバー（ISN）にシークレットを保管し、接続が確立されている間、他のホストへ送信し、接続中他のホストから送信された各TCPは、確認番号（ACKNUM）領域においてISNのデリバティブを含む。
従って、（ａ）TCPセッションの全てのセグメントは、同一の送信者からだと考えられる、（全てのセグメントは統合メッセージにおける、同一のシークレットのデリバティブを含む）、（ｂ）送信者のIPアドレスは、信頼できると考えられる（シークレット・ハンドシェークで検証されるので）、（ｃ）全ての出て行くTCPセグメントは、入ってくるTCPセグメントの送信者に辿り着くと仮定される（セグメントを送信するために用いられるIPアドレスは信頼できるため）。
【００７１】
異なるオペレーティング・システム（各々が異なるバージョン）が、ISNを生じるために異なる機構を用いることが注目される。これら機構のうちのいくつかは他のものより強い（すなわち、生じたISNはそれほど予測可能ではなく、従ってより良いシークレットである）。
このことは、SSRの強さに影響を与える。
【００７２】
TCPセッションは、「TCPセッション・ハンドル」によって識別される。TCPセッション・ハンドルは、ソースIP、デスティネーションIP、ソースTCPポート及びデスティネーションTCPポートを備える。このハンドルは、１つのIPアドレスを伴う１つのホストが並行していくつかのTCPセッションを管理することを可能とする。複数のユーザが同一のIPアドレス（例えばNAPT）を使用する場合において、異なるユーザが同一のIPソースを有するとともに異なるTCPセッション・ハンドルを有してもよい。それゆえ、そのままのIPパケット内で、メッセージのソースIPアドレスに応答することと較べて、TCPセッション上のメッセージに応答することは、唯一のメッセージ送信者に達する可能性が高くなる。
【００７３】
TCP（ハイパーテキスト・トランスファ・プロトコル（Hypertext Transfer Protocol）; HTTP; RFC2616参照）を用いるプロトコルは、いくつかの送信者から１つのTCPセッション（例えば、HTTPプロクシ・ハンドルがいくつかのユーザから１つのHTTPサーバへ要求する場合）へのメッセージを集めてもよい。そのような場合、セッション内で受信された各応答は関連する要求と一致する。例えば、HTTPサーバが、要求を受け取るのと同じ順番で、任意のTCPセッションへの応答を送るように要求される。
【００７４】
（暗号化プロトコル）
トランスポート・レイヤ・セキュリティ（Transport Layer Security）（TLS:RFC2246参照）のような暗号化された通信プロトコルは同一シークレットの方法を実行する。これと関連して、暗号化はメッセージとシークレットを統合する工程として定義される。それゆえ、同じ（或いは関連する）暗号化キーで暗号化された２つのメッセージは同じ送信者からのものと考えられる。
【００７５】
（HTTPクッキー）
HTTPクッキーの構造（米国特許第5774670号及びRFC2109に説明されている）は１HTTP要求を受信するホストが送信者に特定の情報要素（クッキー）を、ある条件に合う連続する各要求に送信させる。クッキーは、それゆえ、「同一のシークレット」及び「割り当てられたシークレット」方法を実行する構造として用いられる。
特に、HTTP応答ないでシークレット（「シークレット・クッキー」）を含むクッキーを割り当てるとき、シークレット・クッキーが送られた同一のシークレット・クッキーを含む連続する全てのHTTP要求が同一の送信者からのものであると考えられる。
【００７６】
もし、HTTP要求が送られる通信チャネルが安全ならば、例えばHTTPセキュア（HTTPS:RFC2818参照）、いくつかのクッキー（「セキュア・クッキー」として知られる）は通信される。セキュア・クッキーは、通常のクッキーと比較して、より安全な環境を提供する。なぜなら、セキュア・クッキーは、クリアの中では決して通信されず、漏話に対して脆弱ではないからである。加えて、安全な通信チャネルを用いるとき、クライアントは通常サーバ認証を用いて、サーバの識別情報が真であることを証明する（認証の例として、RFC2549を参照）。そして、そのことはそのクッキーが合法的なサーバへ送られたことを高い信頼性をもって示す。
【００７７】
（ユーザネームとパスワード）
ユーザネームとパスワードはしばしば、インターネット上で用いられ、特定のサービスへのアクセスを制限する。それらは、ユーザによって選択され、或いはオンライン上でユーザに割り当てられるものである。HTTP基本証明スキーム（HTTP Basic Authentication Scheme）（RFC2069参照）は、HTTPセッション内でユーザネーム及びパスワードを要求し、送る方法である。ユーザネーム及びパスワードは、オンラインフォーム（例えば、Hypertext Markup Language form(HTML; RFC1866参照)）を用いて収集される。ファイル伝送プロトコル（FTP; RFC959参照）、テレネット（Telnet）（RFC854参照）及び他のサービスはユーザネーム及びパスワードを収集するための機構を備える。
【００７８】
ユーザネームとパスワードは、「同一シークレット」及び「割り当てられたシークレット」の方法の実行として用いられる。特に、同じユーザネーム及びパスワードを備えるあらゆるメッセージは、同一送信者からのメッセージであると考えられる。もし、ユーザネーム及びパスワードが割り当てられ（ユーザによって選択されていないとき）、ユーザネーム及びパスワードを備えるメッセージはユーザネーム及びパスワードが割り当てられた人物と同一の送信者からのものであると考えられる。
【００７９】
ユーザネーム及びパスワードの使用が自動的に行われる場合について述べる。例えば、HTMLブラウザが、ユーザがユーザネーム及びパスワードを保存することを提案し、ユーザネーム及びパスワードが要求されたときに自動的にそれらを提供する等のことは通常行われている。
【００８０】
（ソフトウェア・クライアント）
ユーザのデバイスにインストールされたソフトウェア・クライアントは、オンライン・サービス・プロバイダと通信する際に独特の識別子を報告する。この独特の識別子は、クライアントの所有者に個々のサービスを提供するために、オンライン・サービス・プロバイダがクライアントの所有者を識別することを可能とする。そのような識別子はシークレットであり（他人との混同を防止するために）、それゆえこれらのクライアントは「同一シークレット」及び「割り当てられたシークレット」の方法を実行する。
【００８１】
そのような普及しているソフトウェアのクライアントの例として、インスタント・メッセージング・クライアント（Instant Messaging Client）（IMC）がある。例えば、ICQ, AOL Instant Messenger, MSN Messenger及びYahoo!Messengerなどが挙げられ、それぞれ、www.icq.com、www.aol.com/aim、messenger.msn.com及びmessenger.yahoo.comで見ることができる。
これらIMCは、ユーザがインスタント・メッセージング・サービス（Instant Messaging Service）（IMS）に接続するときはいつでも、特有の識別子（ユーザによって選択されたユーザネームやパスワードであり、又クライアントによって割り当てられる大きなランダム数であるなど）を報告する。
【００８２】
（ハードウェア識別子）
例えば、ソフトウェア・クライアントが識別子を実行させるデバイスと関連させるために固有の識別子を必要とする時、ハードウェア識別子は、ソフトウェア・クライアントのために固有の識別子として用いられることが可能である。ハードウェア識別子の例は、インテル・ペンティアム・スリー・プロセッサのシリアル・ナンバー（インテル社の特許出願WO00/51036号）や世界的に固有のイーサネット（登録商標）のMACアドレスである。
【００８３】
いくつかのハードウェア識別子は、ソフトウェアを使用することなく報告され、また例えば、通常は各イーサネット（登録商標）のパケットとともに送受信されるイーサネット（登録商標）のMACアドレスのような「同一シークレット」方式を実装するために用いられる。
【００８４】
（シークレットURL）
ユニフォーム・リソース・ロケーター（URL、RFC１７３８）もまた「同一シークレット」及び「割り当てられたシークレット」方式を実装するために用いられる。例えばHTMLサイトをブラウザで開こうとするユーザは、他のHTMLページ、画像、音声などへとリンクするURLを含むHTMLページを受け取る。これらのHTMLページを提供するホストは、これらのURL（シークレットURL）のそれぞれをシークレットにしておくことが可能である。このようなシークレットURLを含んだ任意のHTTP要求は、HTMLページが送られた先と同一の送信者からであると見なされる。
シークレットURLは、後述するように、SIを取得する過程においても用いられる。
【００８５】
（Ｅメールヘッダ）
シンプル・メール・トランスファー・プロトコル（SMTP、RFC８２１）に基づくＥメール・メッセージはSIの数を含む。これらのSIの多くは、ユーザのＥメールソフトによって自動的に提供された項目である。（SMTP「From」ヘッダ又はSMTP「MAIL FROM：」コマンドでは）送信者の名前及びＥメール・アドレス、（SMTP「Organization」ヘッダでは）送信者の組織、（SMTP「HELO」コマンド又はSMTP「Received：」ヘッダでは）送信者のデバイス識別子、（RFC８２２に述べられた「Date：」ヘッダでは）送信者のデバイスの時間及びタイム・ゾーン、メッセージ本体におけるユーザの署名などが例として挙げられる（簡易にする目的で署名はＥメールヘッダと見なされる）。これらのSIは、（ユーザ又はデバイスによって）ユーザのデバイスに一度もたらされ、その後全てのＥメール・メッセージとともに送信される。従ってこれらは「同一シークレット」方式を実装する。
【００８６】
多くのユーザはウェブ・ベイスド・Ｅメール・サービス（WBES）のＥメール・アカウントを管理する。WBESサイトは、ユーザに、ウェブ・インターフェース（HTTP上のHTML）上のアクセス可能なＥメール・サービスを提供する。マイクロソフトが所有するホットメール（www.hotmail.com）及びヤフーのヤフー・メール（mail.yahoo.com）は、２つの人気のあるWBESの例である。これらの場合、SIはサーバに保存され、ユーザのデバイス上にはない。
【００８７】
予測が困難ではないのため、これらのSIのほとんどは強力なシークレットではなく、またユーザから全てのＥメールの受信者へとさらされることに注意する。
【００８８】
更に、SIの多くは、ユーザのPIと強力に関連付けられ、またこれに応じて後述のように操作される。
Ｅメール・メッセージにおいて理解されるもう１つのSIは、ユーザのデバイス及びこのＥメール・サーバ間の通信において得られ、そして通常はSMTP「Received:」ヘッダで報告されるようなユーザのIPアドレスである。この接続は通常（SMTP及びHTTPの両方が用いられる）TCPで行われ、従ってIPアドレスは「信頼性のあるアドレス」である。しかしながら、IPアドレスは通常ユーザのＥメール・サーバによって報告され（ユーザから直接得ることはない）、アドレスの信頼性はユーザのＥメール・サーバの信頼性に依存する。
【００８９】
（HTTPヘッダ）
Ｅメール・メッセージと同様に、HTTP要求は「同一シークレット」方式を実装するSIの番号を含む。例えば、オペレーティング・システムのタイプ及びバージョンやHTTPクライアントは、HTTP「User-Agent:」ヘッダに提供される。HTTPクライアントに対応するファイルのタイプ、エンコード方法、言語は、HTTP「Accept:」、「Accept−Encoding:」、「Accept−Language:」ヘッダに提供される。
【００９０】
HTTPスタンダードに含まれた「HTTPバリデーション・モデル」は、「同一シークレット」及び「割り当てられたシークレット」方式を実装するために用いられるヘッダの数を定義する。これらのヘッダの内容は、通常ユーザのデバイス（すなわちHTTPクライアント）のキャッシュメモリに蓄えられ、HTTPサーバにいくつかの要求とともに送信される。例えば、任意のURLの要求に応じる時、HTTPサーバはそれぞれのHTTPクライアントに対し「Last-Modified:」ヘッダに異なるタイムスタンプを提供する。同一URLのためのサブシークエント要求に含まれる「If-Modified-Since」ヘッダはその後サーバによって送信されたクライアント固有の時期記録を含む。同様の例では、HTTPサーバはそれぞれのHTTPクライアントに対し、「ETag」ヘッダに異なるエンティティ・タグを提供し、またクライアントは「If-None-Match」ヘッダを用いるサブシークエント要求時にエンティティ・タグを提供する。
【００９１】
（メッセージ・タイムスタンプ）
様々な理由から、同一送信者からのメッセージは、時間的に一様には配信されない。（例、ユーザは睡眠時やネットワークに接続していない時は、メッセージを送信しない）。更に、多くの送信者の活動は周期的である。（例、毎午後又は毎週末）。従って関連する時間（例えば、短時間に、異なる日の同じような時間に、異なる週の同じ曜日に、など）に送信されたメッセージは、同一送信者から送信されたものであると考えられる。
【００９２】
（SIの取得）
いくつかの場合において、固有のSIを取得するために特別な処理が必要とされる。
例えば、クッキーは、HTTP要求とともにのみ所定のドメイン及びURLパス（path）へと送信される。ユーザ・デバイス１２からクッキーを取得するためには、HTTP要求を特定のドメイン及びURLパスに送信しなければならない。本発明が、取得予定のクッキーが他方のオンライン・サービス・プロバイダ（OSPB）によって発行される間に、一方のオンライン・サービス・プロバイダ（OSPA）に送信されたメッセージの結果として生じる時、このことは特に相当する。
【００９３】
OSPA及びOSPBは通常異なるドメイン名を用いるので、ユーザ・デバイス１２はHTTP要求をともなうクッキーをOSPAへと送信しない。従ってユーザ・デバイス１２はHTTP要求を適切なパスを経由しOSPBドメインのホスト名（例SI-obtainer.OSPB.com）へと送信させることとなる。これによりクッキーは送信される。この要求を受け取るコンポーネントは、後述のSI取得手段４２である。クッキーを示すために用いられるホスト名はOSPBのドメインの中にある間、SI取得手段４２はOSPBによって必ずしも制御されるわけではない。OSPBは、SI取得手段４２のホスト名又はIPアドレスを示すドメインのホスト名を定義することのみを必要とする。
【００９４】
SI取得手段４２は（例えば、OSPBと協力する企業によって操作されるため）このような情報を有している間は、通常OSPAは、OSPBのクッキーを示すためにどのドメイン及びパスが必要であるのかを知ろうとしない。この場合、SI取得手段４２は、上述のように、ユーザのデバイスに、HTTP要求をOSPBドメインへと送信させる間は、OSPAは、ユーザのデバイスに、HTTP要求をSI取得手段４２を示す既知のホスト名（例えば、SI-obtainer.com）へと送信させる。
【００９５】
もし取得予定のクッキーがセキュア・クッキーであるなら、ユーザのデバイスでセキュア要求を送信する以外は例えば、要求URL中の「https」プロトコル識別子を特定することによって、同じ手続が実行される。更に、クライアントが要求を操作するサーバのアイデンティティを認証することを可能にするために、OSPBドメインのもとでホスト名を確認するサーバ証明書がSI取得手段４２に対して発行され、またこの証明書はクライアントに提示される。
【００９６】
他の例として、ユーザネーム及びパスワードがユーザ又はデバイスから取得される必要がある。この場合、ユーザネーム及びパスワードを入力する要求がユーザのデバイスに送信される。これは、HTTP基本認証の認証要求又はユーザネーム及びパスワードを入力するためのオンライン・フォームである。これによりユーザはユーザネーム及びパスワードを入力し、又はこれらの詳細を提供する自動的な機構を呼び出す。このような自動的な機構を呼び出すために、クッキーを取得する場合と同様の方法で、ユーザのデバイスがHTTP要求を特定のURL及びパスへと送信することが必要となる。
【００９７】
他の例では、ユーザ・デバイスのIPアドレスを取得するために特別な処理が必要とされる。これは、ユーザ・デバイスからの通信がHTTPプロキシ・サーバ又はネットワーク・アドレス・トランスレーション（NAT、RFC２６６３）を通じて行われているのであれば必要となりうる。これらの条件の下でIPアドレスを取得する方法はPCT出願WO01/13289に述べられている。
他の例では、ユーザ・デバイスに提供されたソフトウェア・クライアントにより、SIが取得される。ユーザ・デバイスを実行するソフトウェアは通常オンライン・サービスと比べ、より高い特権を有するので、ユーザのデバイスに格納されたSI（例、HTTPクッキー、ソフトウェア識別子、ハードウェア識別子、蓄えられたユーザネーム及びパスワード等）に直接アクセスし、これらをSI取得手段４２へと送信することが可能である。
【００９８】
上記の方法のいくつかは、ユーザ・デバイス１２に特別な要求を送信させることを必要とする。これを達成する１つの方法は、HTTPリダイレクト機構を用いることである。また別の方法は、例えば（「ウェブ・ビーコン」としても知られている）画像又はユーザ・デバイスに送信されたHTMLページのポップアップ・ウインドウのようなウェブ対象物へのリンクを組み込むことである。これにより、ウェブ対象物を検索するために要求された要求を送信する。例えばJava（登録商標）Script（Java（登録商標）Scriptの説明としては、developer.netscape.comネットスケープ・ディベロッパーズ・サイトを参照せよ）のようなクライアントサイドのスクリプト言語は、ユーザの干渉を受けることなく、ポップアップ・ウインドウを作成するために用いられることが可能である。しかし、他の方法は、ユーザ・デバイス１２にインストールされたソフトウェア・クライアントに要求された要求を送信するよう要求することである。例えば、このソフトウェア・クライアントによって、又はソフトウェア・クライアントと関連したMINEタイプを介してソフトウェア・クライアントを実行することによって、認識された専用のプロトコルを通じて行われる（MINEタイプはRFC２０４６で説明される）。
【００９９】
SIを表す要求は、同一のユーザからの以前のメッセージを伴うSSRを有する。これは同時に要求され、不正行為者が要求を送信することを防止し、他のユーザのセッションを引き継ぐために、異なるユーザからの要求が混じることはない。これは通常「割り当てられたシークレット」方式及びシークレットURLを用いて実行される。
【０１００】
もし、何らかの理由のために、OSPAによってすでに、ユーザのデバイスが、電子財布、シングル・サインオン・サービス、取引認証サービス又はオンライン広告ネットワークのようなOSPA外部のサービスの要求を送信するならば、このようなサービスは、OSPAへと最小限の変更で又は変更することなく、ユーザのデバイスが任意の要求された要求を送信するために、任意の上記の方式とともに用いられる。この目的のためのこのような外部のサービスを用いることの利点は、複数のオンライン・サービス・プロバイダにより、ユーザのデバイスが同一の外部サービスへ要求を送信する場合よりも大きい。電子財布及びシングル・サインオン・サービスの例は、マイクロソフト・パスポート、AOLクイック・チェックアウト、及びヤフー・ウォレットである。取引認証サービスの例は、「３Ｄセキュア」である。オンライン広告ネットワークの例は、ニューヨーク州、ニューヨークの２４/７リアル・メディアである。
【０１０１】
（SSR連鎖）
SSRはまた、SSRの連鎖に基づく。もしメッセージＡがメッセージＢを伴うSSRを有し、またメッセージBがメッセージCを伴うSSRを有するなら、メッセージA及びメッセージCもまたSSRを有する（全ての３つのメッセージは同一の送信者であると示されているので）。
メッセージA及びメッセージB間のSSRは、メッセージB及びメッセージC間のSSRとは異なるタイプであり、それぞれはまたメッセージBに関連する異なるSIに基づいている。例えば、メッセージCは、同一の固有の識別子を含む間、IMS（メッセージB）へ接続する時、IMCはTCPセッションにおいて固有の識別子を送信し、また、メッセージAはメッセージB（TCP「シークレット・ハンドシェイク」により検証される）と同一のIPアドレスを有する。他の例において、２つのSSRは、同一のHTTP要求に含まれるシークレットURL及びシークレット・クッキーとの「同一シークレット」関係に基づいている。しかしまた他の例において、他の１つは関連するIPアドレス（信頼性のあるアドレス）を有することに基いている間は、１つのSSRは、HTTP要求においてシークレット・クッキーと「同一シークレット」である。
【０１０２】
同一ユーザからのメッセージに関連するSIが長時間かけて変化する時に、SSR連鎖はとりわけ有用である。例えば、上記のようにインターネット・ユーザが使用するIPアドレスを長時間かけて変化する時、同一のユーザにより送信された２つのメッセージのソースIPアドレスは、弱いSSRのみを有するか、SSRを全く持たないことになる。このような場合、ユーザから送信された他のメッセージは、２つのメッセージ間のSSR連鎖を見つけるために用いられる。いくつかのオンライン・サービス・プロバイダはよりこのようなメッセージを受け取りがちである。１つの例は、頻繁に訪れるウェブサイト（a frequently visited website、FVW）である。FVWは多くの異なるユーザからのHTTP要求を受信し、この要求はIPアドレス及びシークレット・クッキーを含む。他の例としては、IMSがある。IMSは、ユーザから、彼らがインターネットに接続する度にログイン・メッセージを受信する。このログイン・メッセージは、IPアドレスと固有の識別子を含んでいるいことを特徴としている。また別の例として、上記のような、多くのユーザからＥメールを受信するオンライン・サービス・プロバイダがある。このＥメールは、上述するように、IPアドレス及びＥメール・ヘッダの複数のシークレットを含んでいることを特徴としている。
SSR連鎖に基づくSSRは、不正行為者により攻撃の可能性を与え（いかなるリンクも攻撃されうる）、このため比較的脆弱である。
【０１０３】
SSRの一例において、メッセージDは、IPアドレスＤからのHTTP要求Dで受信され、またIMCがIPアドレスＥからTCPのIMSへと接続する時、メッセージEが送信される。逆のDNSクエリーは、IPアドレスD及びIPアドレスＥが同一企業へと割り当てられていることを示す。
【０１０４】
この場合のSSR連鎖は以下の通りである。（ａ）メッセージDはHTTP要求Dに含まれた（あるTCPセッションにおける同一HTTP要求）。（ｂ）HTTP要求ＤはIPアドレスＤから送信された（TCPセッションにおいて現れるIPアドレス）。（ｃ）IPアドレスＤ及びIPアドレスＥは同一企業に割り当てられた（信頼できるアドレス）。（ｄ）メッセージＥはIPアドレスＥからIMSへと送信された（TCPセッションにおいて現れるIPアドレス）。
メッセージD及びメッセージEは同一送信者から派生していると考えられる。
【０１０５】
SSR連鎖の他の例において、メッセージAはIPアドレスＡからのHTTP要求Aで受信される。メッセージAの送信とほぼ同時にIPアドレスAから送信され、FVWで受信されるHTTP要求Bは、メッセージB及びシークレット・クッキーを含む。FVWで受信されるHTTP要求Cは、メッセージC及びHTTP要求Bと同一のシークレット・クッキーを含んでいる。
【０１０６】
この場合のSSR連鎖は以下の通りである。（ａ）メッセージＡはHTTP要求Ａに含まれた（あるTCPセッションにおける同一HTTP要求）。（ｂ）HTTP要求ＡはIPアドレスAから送信された（TCPセッションにおいて現れるIPアドレス）。（ｃ）HTTP要求A及びHTTP要求BはともにIPアドレスAから派生し、ほぼ同時に送信された（「信頼性のあるアドレス」）。（ｄ）HTTP要求B及びHTTP要求Cは同一のシークレット・クッキーを含む（「同一シークレット」）。（ｇ）メッセージCはHTTP要求Cに含まれた（あるTCPセッションにおける同一HTTP要求）。
メッセージA及びメッセージCは同一送信者から派生していると考えられる。
【０１０７】
SSR連鎖の他の例として、メッセージFがHTTPS要求Fで受信される。メッセージFに対する応答において、セキュア・シークレット・クッキーがドメイン「f.com」へと制限されて割り当てられる。メッセージGがHTTP要求Gで受信される。メッセージGに対する応答において、ユーザのデバイスはドメイン「f.com」のシークレットHTTPS・URLにリダイレクトされ、これによりこのURLはシークレット・クッキーを送信する。
【０１０８】
この場合のSSR連鎖は以下の通りである。（ａ）メッセージＦはHTTPＳ要求Ｆに含まれた（暗号手段による「インテグラル・メッセージ（Integral Message）」）。（ｂ）シークレットHTTPS・URLとともに送信されたセキュア・シークレット・クッキーは、HTTPS要求Fに対する応答に割り当てられた同一クッキーである（「割り当てられたシークレット」）。（ｃ）シークレットHTTPS・URLはHTTPS要求Ｇの送信者に送信された同一シークレットURLである（「割り当てられたシークレット」）。（ｄ）メッセージGはHTTP要求Gに含まれた（あるTCPセッションにおける同一HTTP要求）。
メッセージF及びメッセージGは同一送信者から派生していると考えられる。
【０１０９】
SSR連鎖の他の例において、メッセージＨはIPアドレスＨからHTTP要求Hで受信される。Ｅメール・メッセージＩはIPアドレスHからHTTP要求Hの送信とほぼ同じ時に送信された。Ｅメール・メッセージJはIPアドレスJから送信され、Ｅメール・メッセージIと同一の送信者名、送信者デバイス識別子、タイム・ゾーン及び個人署名を有する。HTTP要求Ｋは、Ｅメール・メッセージJの送信とほぼ同じ時にIPアドレスJから送信され、シークレット・クッキーを含んでいる。HTTP要求ＬはメッセージL及びHTTP要求Kと同一のシークレット・クッキーを含んでいる。
【０１１０】
この場合のSSR連鎖は以下の通りである。（ａ）メッセージＨはHTTP要求Ｆに含まれた（あるTCPセッションにおける同一HTTP要求）。（ｂ）HTTP要求ＨがIPアドレスHから送信された（TCPセッションに現れるIPアドレス）（ｃ）HTTP要求H及びＥメール・メッセージIはともにIPアドレスHから派生し、ほぼ同じ時に送信された（「信頼性のあるアドレス」）。（ｄ）Ｅメール・メッセージI及びＥメール・メッセージJは、上述のように、同一のSIを有する（「同一シークレット」）。（ｅ）HTTP要求K及びＥメール・メッセージＪはともにIPアドレスＪから派生し、ほぼ同じ時に送信された（「信頼性のあるアドレス」）。（ｆ）HTTP要求Ｌ及びHTTP要求Ｋは同一シークレット・クッキーを含んでいる（「同一シークレット」）。（ｇ）メッセージＬはHTTP要求Ｌに含まれた（あるTCPセッションにおける同一HTTP要求）。
【０１１１】
メッセージH及びメッセージLは同一送信者から派生していると考えられる。
【０１１２】
（同一人物条件）
（定義）
正しい検証はPI1 １００及びPI2 １０２が同一人物を識別することを必要とする。これが同一人物条件（Same Person Condition、SPC）である。もしPI1 １００及びPI2 １０２が同一人物関係（Same Person Relation、SPR）を有するなら、SPCは満たされる。（SPRの強さを測定する）SPRの強さは、複数の要因により変化しまたこれらに依存している。概して、もしPI1 １００及びPI2 １０２の具体性がより低い（すなわち、多くの人に関連する）のであれば、異なる人々が同一人物だと考えられる場合が多くなるので、SPRはより弱くなる。例えば、PI2 １０２はクレジットカード番号の下４桁であり、PI1 １００はこの４桁で終わるカード番号である。この場合、PI1 １００はPI2 １０２として作られた番号とは実際には異なるカード番号であるが、PI・１００及びPI2 １０２は同一人物と識別すると考えられる。これは、PI2 １０２の下４桁と適合する任意のカードが使用できるという点において、不正行為者にいくらか融通を与えることになる。PI2 １０２が具体性がより少なくなるにつれ（例、桁数がより少ない）、適合するカードを見つけることがより容易となり、攻撃をより容易にし、SPRはより脆弱になる。
【０１１３】
PI１・１０１又はPI2 １０２がどれくらい具体性を持つかを推定する場合、該当する集団において様々な人物識別子の大衆性を示すデータベースを用いることが有益である。例えば、もしPI2 １０２が名前を含むなら、様々な名前の大衆性の記述はPI2 １０２がどれくらい具体性を持っているかを推定することにおいて助けとなる。
【０１１４】
人は時々PIの一部を変更する（例、所在地住所の変更やクレジットカード番号の変更）。このような場合、SPRの強さは、２つのPIの送信間に経過した時間及び人々がこのようなPIを変更する傾向性に依存する。
【０１１５】
PI1 １００及びPI2 １０２が同一人物を識別するかどうかを推定する１つの方法は、同一部分を含むかどうかをチェックすることによって、これらを文字の類似性を調べることである。例えば、PI1 １００及びPI2 １０２は完全に同一（例、同一のフルネーム）となりうる。他の例では、PI2 １０２はPI1 １００の全て又は一部を含んでいる（例、PI2 １０２はクレジットカード番号を含んでおり、PI1 １００はこのカード番号の下４桁を含んでいる）。また他の例において、PI1 １００はPI2 １０２の全て又は一部を含む。概して、もしPI1 １００及びPI2 １０２の同一の部分が多く、また統計的により重要であれば、SPRはより強くなる。
【０１１６】
いくつかの場合、SPRを有することを示しているPI1 １００及びPI2 １０２の間の関係を見つけるために、より複雑な手続が必要とされる。例えば、PI1 １００及びPI2 １０２は意味は同じだがスペルの差異を伴う同一部分（例。「Forty-Second St.」及び「42nd street」）を有する。他の例では、PI1 １００はPI2 １０２の省略形を含んでおり、又はこの逆もまた同様である（例。Ｅメール「jhdoe2002@mail.com」及び名前「John Henry Doe」）。また別の例において、PI1 １００及びPI2 １０２は数字が近似する電話番号を含んでいる（すなわち、例えば555-1280と555-1281のように下数桁のみが異なる番号）。（電話会社はしばしば同一の顧客に連続する電話番号を割り当てるので）これらの番号は任意のランダムに選ばれたどの２つの番号よりも同一に扱われる。他の例において、PI1 １００及びPI2 １０２は地理的に近似する地理的パラメータを含む。人は遠い場所よりもより近い場所（近所の家やインターネット・カフェ、仕事場などの周辺）付近へと行きがちであるので、これらの番号は、任意のランダムに選ばれたどの２つの地理的パラメータよりも同一に扱われる。このようなパラメータの例は、同じ通りの連続した家番号又は地理上の計算によって近似すると理解される２つの緯度／経度調整である。
【０１１７】
（PIディレクトリの使用）
いくつかの場合において、SPRを検出するためにPIディレクトリの使用が必要とされる。
PIディレクトリは、それぞれが２又は３以上のPIに関連する記録を含むデータベースである。同一記録の各PIによって識別される少なくとも１人の人間がいることを特徴としている。この文脈において、データベースは、記録の内容についてのクエリーに応答可能な任意のシステム又はシステムの組み合わせである。
【０１１８】
例えば、ホワイト・ページ・ディレクトリのそれぞれの記録は、特定の名前、住所、電話番号によって識別される１人の人に関して格納されている。
他の例としては、クレジットカード発行銀行のデータベースがある。このデータベースのそれぞれの記録は、名前、クレジットカード番号、請求書あて先住所（クレジットカードの請求書が送付される住所）によって識別される１人の人に関して格納されている。
【０１１９】
他の例は、住所と地理パラメータ（例、緯度及び経度）を関連させる地理的ディレクトリ、又は携帯電話番号と携帯電話の現在の地理的位置を関連させる地理的ディレクトリである。
【０１２０】
他の例は、それぞれのＥメール・アドレスとこのアドレスを使用する人の名前を関連づけるＥメール・ディレクトリである。アドレス・フィールド（From、To、CC）は通常受信者の、又は送信者の名前を、Ｅメール・アドレスと同様に含むので、Ｅメール・ディレクトリは、Ｅメール・メッセージを分析することによって自動的に作成される。この場合、ディレクトリへの間違った又は不正な記録の追加を防ぐため、Ｅメール・メッセージは、信頼できるソースからであるのか検証されるべきである。
【０１２１】
他のPIディレクトリは、より具体性が少ない。例えば名前と国の間の相関関係（ある国においてのある名前の大衆性）を示すディレクトリである。このようなPIディレクトリにおいてそれぞれの記録はある国においてある名前を有する人々の数（又は一部分）を表す。
【０１２２】
いくつかのPIディレクトリは時期が異なるという以外は同一タイプのPIに関連する。例えば、住所変更データベースのそれぞれの記録は、時期が異なる同一人物（又は家族）の住所を含んでいる。
【０１２３】
いくつかのPIディレクトリは、オンラインでの識別のために特別に作成されている。例えば、後述のような、コードがユーザのメールアドレスに送信される場合、各コードとコードが送信される名前を関連付けてPIディレクトリが作成される。他の例において、上述のペイパル・システム（PayPal System）は、各クレジットカード番号をクレジットカードの課金をする際に用いられるシークレット・コードと関連付けてPIディレクトリを使用する。
【０１２４】
情報要素をPIディレクトリのPIと関連付けることによって、この情報要素がPIとなることに注意する。例えば、政府のデータベースがID番号を各国民に割り当てて作成される時（例、フルネーム、誕生日、両親の名前によって識別される）、このそれぞれのIDはPIになる。
【０１２５】
PIディレクトリを用いる時、もし記録が、PI1 １００とSPRを有するPIと、PI2 １０２とSPRを有する他のPIとを関連付けるならば、PI1 １００及びPI2 １０２はSPRを有する。
PIディレクトリへのアクセスは、２つの方法で実行される。第１の方法では、いくつかの（しかし全てではない）PIが該当する１つの記録（クエリーでPIとSPRを有するPIを含む記録）又は複数の記録を位置付けるためにクエリーとして与えられ、またもし見つかったなら、この１つの記録又は複数の記録は検索され、応答で送信される。データ移動を最小化し、又は情報の機密性を保持するために、応答で送信される記録の数を制限すること（例、最も新しい記録のみ）、又は各記録から送信されたPIの数を制限すること（例、クエリーに既に現れているPIを送信しないこと）が可能である。
【０１２６】
例えば、もしPI1 １００が電話番号であり、PI2 １０２がフルネーム及び住所であるなら、PI2 １０２とSPRを有するPI（例、スペルの差異を伴う同一の名前及び住所）を含む記録を見つけるために、PI2 １０２を含むクエリーはホワイト・ページ・ディレクトリに送信される。この応答は名前及び住所と関連する全ての電話番号を含んでいる。上述のように、検索した数はその後PI1 １００とのSPRのためにチェックされる。別のホワイト・ページ例では、クエリーは電話番号であり、この返答は関連する名前及び住所を含んでいる（概して「リバース・フォン検査（reverse phone lookup）」として知られている）。
【０１２７】
第２の方法では、少なくとも２つのPIがクエリーとして与えられ、またこの応答は、これらのPIによって識別された人が存在するかどうか（又はどのくらいこのような人が存在するか）を示すことによって、該当する記録が存在するかどうかを記す。例えば、もしPI1 １００がクレジットカード番号をんでおり、PI2 １０２が住所を含んでいるなら、クエリーは、PI1 １００及びPI2 １０２を含む上述のＡＶＳサービスへと送信される。この応答は、記録が存在するかどうかを記すYes/Noアンサーである。このYes/Noアンサーにおいて、カード番号はPI1 １００とSPR（すなわちPI1 １００と同一）を有し、また住所はPI2 １０２とのSPRを有する。このような記録を見つけることは、通常PI2 １０２がPI1 １００によって識別されるクレジットカード口座の所有者の請求書宛先住所であることを示す。
【０１２８】
２つの方法の任意の組み合わせも、当然のことながら可能である。例えば、クエリーは２つのPI及びこの記録が存在するかどうかを記した応答を含んでおり、またもし記録が存在するなら同一記録からの第３のPIも含んでいる。
【０１２９】
いくつかの場合において、クエリーへの応答は明確に提供されるのではなく、むしろ他のアクションから促される。例えば、処理のために取引を提示するオンライン取引業者は住所情報を含んでおり、またこの取引は住所がAVSチェックを通る時のみ許可される。この場合、正しい取引許可はAVSの適合を示す。
【０１３０】
いくつかの場合においては、PIディレクトリに対する明白なクエリーがなく、応答は他のアクションの結果として受信される。例えば、OSP１４は、オンライン購入手続の一部としてユーザ１０からＥメールを受信する。このＥメールは、ユーザ１０の名前及びＥメールアドレス間の関連性を含んでおり、従ってＥメール・ディレクトリからの応答に相当する。
【０１３１】
PIディレクトリへのアクセスは任意の利用可能なプラットフォーム上で実行されることに注意する。例えば、クレジットカード番号及びカード所有者の名前間の適合を検証するために、人はマニュアルに従って、発行銀行に対し声による電話の呼び出しを行う。
【０１３２】
PIディレクトリの使用は、特に１対１の関係を表さないPIディレクトリを用いる時に、PI1 １００及びPI2 １０２間のSPRを脆弱にすることに注意する。このようなディレクトリは、異なる人が同一人物として識別される場合を増加する。１つのタイプのPI（例、SSN）がディレクトリに関連する他のタイプのPI（例、このSSNを有する人の住所）と代わる時、識別されたグループは、第２PI（例、この人と同じ住所に住んでいる人々）とディレクトリ関連する第１タイプのPIを有する全ての人に広がり、彼らは異なるとは言えない。
【０１３３】
PIディレクトリは、PI2 １０２、PI1 １００又はこの両方によって識別される人々の全番号（又は一部）を見つけるために用いられる。上述のように、これらの番号は、SPRの強さを推定する際に助けとなる。
【０１３４】
一例として、PI1 １００は社会保障番号（Social Security Number、SSN）であり、PI2 １０２はクレジットカード番号である。クレジットカード発行者のデータベースは、SSNとクレジットカード番号を関連付けるPIディレクトリとして使用される。PIディレクトリは、一人の人のみがこのSSN及びクレジットカード番号とともに存在することを示す。これはカードが一人の人間のみに発行されたことを示す。これは通常強いSPRを示している。
【０１３５】
他の例において、PI2 １０２はアパートの住所であり、PI1 １００はフルネームである。ホワイト・ページ・ディレクトリは、この名前を有する一人の人間がこの住所に住んでいることを示す。しかし、また複数の人間がこの住所に住んでいることも示す。従って、SPRは１つ前の場合ほど強くはない。
【０１３６】
他の例において、PI2 １０２はファースト・ネームであり、PI1 １００は国である。異なる国における名前の大衆性を表すPIディレクトリは多くの人々がある国においてある名前を有し、一方で小数の人々がこの国外でこの名前を有していることを示す。これはSPRが存在するがこの前２つの場合よりも強くはないことを示す。
【０１３７】
PIディレクトリの正確性及び信頼性はSPRの強さに影響を与えるということに注意する。PIディレクトリにおいて紛失、期限切れ、又は誤りのある記録の可能性はSPRを推定する際に考慮されるべきである。
【０１３８】
（ＳＰＲ連鎖）
SPRはまたSPRの連鎖に基づく。もしPIAがPIBとSPRを有し、PIBがPICとSPRを有するなら、PIA及びPICもまたSPRを有する（全ての３つのPIは同一人物を識別するために用いられるため）。それぞれのSPRはタイプが異なり、またPIディレクトリに基づいている。
【０１３９】
例えば、PI2 １０２は名前であり、PI1 １００はクレジットカード番号である。ホワイト・ページ・ディレクトリは該名前と関連する１つの住所（又は複数の住所）を見つけるために用いられる。次に、AVSサービスは、住所（又は複数のうちの住所の１つ）がPI2 １０２のクレジットカード番号の請求書宛先住所であることを検証するために用いられる。これは第３PI（住所）を経由するPI1 １００及びPI2 １０２間のSPRを示す。
【０１４０】
（上記の１つのPIディレクトリの使用と比較すると）SPR連鎖又は複数のPIディレクトリの使用は更にSPRを脆弱にする。最後の例において、該当するグループは、カードと関連した任意の住所と同一の住所を有するある人と、同一の名前を有する任意の人へと範囲が広げられる。
【０１４１】
更に、SPR連鎖を用いる時にSPRの強さを推定する際、人物識別子の適合部分のみが考慮される。例えば、PI「john2002」は、PI「bobdoe」の一部を含むPI「John Doe」の一部を含んでいる。しかし、PIの各組の同一部分は完全に異なる（「john」が第１組、「doe」が第２組）ので、「john2002」と「bobdoe」間には明白なSPRはない。
【０１４２】
PIディレクトリ・クエリーへの応答が、他のクエリーで用いられる多くのPIを含んでいる場合（例、後述のような、他のPIディレクトリに送信された、又はPISIDB）、クエリーの数を絞るため付加PIはOSP１４によって提供される。上記のAVS例において、ユーザの住所は、この人物の名前に従って提供される。ホワイト・ページ・ディレクトリの名前と関連した住所を有するAVSクエリーを作成する代わりに、名前が提供される住所と関連することを検証するために、１つのクエリーが作成され、またAVSクエリーが、提供される住所がカードと関連することを検証するために作成される。
【０１４３】
（PI２の真となる条件）
正しい検証は、PI2 １０２がPI２・１０６の送信者を識別することを必要とする。これがPI２の真となる条件（True Condition、TC）である。PI２が真である確率（PI２検証レベルという）は複数の要因で変化し、またこの要因に依存する。特に、PI2 １０２が真であることを検証するために用いられる方法及び不正行為をする影響が考慮される。いくつかこのような方法が存在する。
【０１４４】
（既存の検証方法）
PI2 １０２は、人物識別子を検証するための任意の既存の方法を用いて変化する。例えば、もしPI2 １０２が通常不正行為者がアクセスできない情報（例。有効なクレジットカード番号又は銀行口座番号）を含んでいるならば、又は（例えば、銀行口座番号と適合するPIN、又は上述のようなEquifaxアンケートに対する正確な応答）このような情報がPI2 １０２へと提供されるならば、このPI2 １０２は真であると考えられる。
【０１４５】
（正しいオフライン・アクション）
PI2 １０２を検証する他の方法は、PI2 １０２に基づく正しいオフライン・アクションを実行することである。
例えば、もしPI2 １０２がオンライン購入の間に受信したクレジットカード番号であれば、購入商品のためにカードに課金し、また真偽を問われることがないことはPI2 １０２を検証する。
【０１４６】
真偽の問合せは通常即座に報告されないので、PI2 １０２が真であると考えられるまでにかなりの期間が課金後経過することに注意する（通常２、３か月）。
【０１４７】
（ハードウェア識別子）
例えば、ソフトウェア・クライアントが識別子を実行させるデバイスと関連させるために固有の識別子を必要とする時、ハードウェア識別子は、ソフトウェア・クライアントのために固有の識別子として用いられることが可能である。ハードウェア識別子の例は、インテル・ペンティアム・スリー・プロセッサのシリアル・ナンバー（インテル社の特許出願WO００/５１０３６）や世界的に固有のイーサネット（登録商標）のMACアドレスである。
【０１４８】
いくつかのハードウェア識別子は、ソフトウェアを使用することなく報告され、また例えば、通常は各イーサネット（登録商標）のパケットとともに送受信されるイーサネット（登録商標）のMACアドレスのような「同一シークレット」方式を実装するために用いられる。
【０１４９】
（シークレットURL）
ユニフォーム・リソース・ロケーター（URL、RFC１７３８）もまた「同一シークレット」及び「割り当てられたシークレット」方式を実装するために用いられる。例えばHTMLサイトをブラウザで開こうとするユーザは、他のHTMLページ、画像、音声などへとリンクするURLを含むHTMLページを受け取る。これらのHTMLページを提供するホストは、これらのURL（シークレットURL）のそれぞれをシークレットにしておくことが可能である。このようなシークレットURLを含んだ任意のHTTP要求は、HTMLページが送られた先と同一の送信者からであると見なされる。
シークレットURLは、後述するように、SIを取得する過程においても用いられる。
【０１５０】
（Ｅメールヘッダ）
シンプル・メール・トランスファー・プロトコル（SMTP、RFC８２１）に基づくＥメール・メッセージはSIの数を含む。これらのSIの多くは、ユーザのＥメールソフトによって自動的に提供された項目である。（SMTP「From」ヘッダ又はSMTP「MAIL FROM：」コマンドでは）送信者の名前及びＥメール・アドレス、（SMTP「Organization」ヘッダでは）送信者の組織、（SMTP「HELO」コマンド又はSMTP「Received：」ヘッダでは）送信者のデバイス識別子、（RFC８２２に述べられた「Date：」ヘッダでは）送信者のデバイスの時間及びタイム・ゾーン、メッセージ本体におけるユーザの署名などが例として挙げられる（簡易にする目的で署名はＥメールヘッダと見なされる）。これらのSIは、（ユーザ又はデバイスによって）ユーザのデバイスに一度もたらされ、その後全てのＥメール・メッセージとともに送信される。従ってこれらは「同一シークレット」方式を実装する。
【０１５１】
多くのユーザはウェブ・ベースド・Ｅメール・サービス（WBES）のＥメール・アカウントを管理する。WBESサイトは、ユーザに、ウェブ・インターフェース（HTTP上のHTML）上のアクセス可能なＥメール・サービスを提供する。マイクロソフトが所有するホットメール（www.hotmail.com）及びヤフーのヤフー・メール（mail.yahoo.com）は、２つの人気のあるWBESの例である。これらの場合、SIはサーバに保存され、ユーザのデバイス上にはない。
【０１５２】
予測が困難でいので、これらのSIのほとんどは強力なシークレットではなく、またユーザから全てのＥメールの受信者へとさらされることに注意する。
【０１５３】
更に、SIの多くは、ユーザのPIと強力に関連付けられ、またこれに応じて後述のように操作される。
Ｅメール・メッセージにおいて理解されるもう１つのSIは、ユーザのデバイス及びこのＥメール・サーバ間の通信において得られ、そして通常はSMTP「Received:」ヘッダで報告されるようなユーザのIPアドレスである。この接続は通常（SMTP及びHTTPの両方が用いられる）TCPで行われ、従ってIPアドレスは「信頼性のあるアドレス」である。しかしながら、IPアドレスは通常ユーザのＥメール・サーバによって報告され（ユーザから直接得ることはない）、アドレスの信頼性はユーザのＥメール・サーバの信頼性に依存する。
【０１５４】
（HTTPヘッダ）
Ｅメール・メッセージと同様に、HTTP要求は「同一シークレット」方式を実装するSIの番号を含む。例えば、オペレーティング・システムのタイプ及びバージョンやHTTPクライアントは、HTTP「User-Agent:」ヘッダに提供される。HTTPクライアントに対応するファイルのタイプ、エンコード方法、言語は、HTTP「Accept:」、「Accept−Encoding:」、「Accept−Language:」ヘッダに提供される。
【０１５５】
HTTPスタンダードに含まれた「HTTPバリデーション・モデル」は、「同一シークレット」及び「割り当てられたシークレット」方式を実装するために用いられるヘッダの数を定義する。これらのヘッダの内容は、通常ユーザのデバイス（すなわちHTTPクライアント）のキャッシュメモリに蓄えられ、HTTPサーバにいくつかの要求とともに送信される。例えば、任意のURLの要求に応じる時、HTTPサーバはそれぞれのHTTPクライアントに対し「Last-Modified:」ヘッダに異なるタイムスタンプを提供する。同一URLのためのサブシークエント要求に含まれる「If-Modified-Since」ヘッダはその後サーバによって送信されたクライアント固有の時期記録を含む。同様の例では、HTTPサーバはそれぞれのHTTPクライアントに対し、「ETag」ヘッダに異なるエンティティ・タグを提供し、またクライアントは「If-None-Match」ヘッダを用いるサブシークエント要求時にエンティティ・タグを提供する。
【０１５６】
（メッセージ・タイムスタンプ）
様々な理由から、同一送信者からのメッセージは、時間的に一様には配信されない。（例、ユーザは睡眠時やネットワークに接続していない時は、メッセージを送信しない）。更に、多くの送信者の活動は周期的である。（例、毎午後又は毎週末）。従って関連する時間（例えば、短時間に、異なる日の同じような時間に、異なる週の同じ曜日に、など）に送信されたメッセージは、同一送信者から送信されたものであると考えられる。
【０１５７】
（SIの取得）
いくつかの場合において、固有のSIを取得するために特別な処理が必要とされる。
例えば、クッキーは、HTTP要求とともにのみ所定のドメイン及びURLパス（path）へと送信される。ユーザ・デバイス１２からクッキーを取得するためには、HTTP要求を特定のドメイン及びURLパスに送信しなければならない。本発明が、取得予定のクッキーが他方のオンライン・サービス・プロバイダ（OSPB）によって発行される間に、一方のオンライン・サービス・プロバイダ（OSPA）に送信されたメッセージの結果として生じる時、このことは特に相当する。
【０１５８】
OSPA及びOSPBは通常異なるドメイン名を用いるので、ユーザ・デバイス１２はHTTP要求をともなうクッキーをOSPAへと送信しない。従ってユーザ・デバイス１２はHTTP要求を適切なパスを経由しOSPBドメインのホスト名（例、SI-obtainer.OSPB.com）へと送信させることとなる。これによりクッキーは送信される。この要求を受け取るコンポーネントは、後述のSI取得手段４２である。クッキーを示すために用いられるホスト名はOSPBのドメインの中にある間、SI取得手段４２はOSPBによって必ずしも制御されるわけではない。OSPBは、SI取得手段４２のホスト名又はIPアドレスを示すドメインのホスト名を定義することのみを必要とする。
【０１５９】
SI取得手段４２は（例えば、OSPBと協力する企業によって操作されるため）このような情報を有している間は、通常OSPAは、OSPBのクッキーを示すためにどのドメイン及びパスが必要であるのかを知ろうとしない。この場合、SI取得手段４２は、上述のように、ユーザのデバイスに、HTTP要求をOSPBドメインへと送信させる間は、OSPAは、ユーザのデバイスに、HTTP要求をSI取得手段４２を示す既知のホスト名（例えば、SI-obtainer.com）へと送信させる。
【０１６０】
もし取得予定のクッキーがセキュア・クッキーであるなら、ユーザのデバイスでセキュア要求を送信する以外は例えば、要求URL中の「https」プロトコル識別子を特定することによって、同じ手続が実行される。更に、クライアントが要求を操作するサーバのアイデンティティを認証することを可能にするために、OSPBドメインのもとでホスト名を確認するサーバ証明書がSI取得手段４２に対して発行され、またこの証明書はクライアントに提示される。
【０１６１】
他の例として、ユーザネーム及びパスワードがユーザ又はデバイスから取得される必要がある。この場合、ユーザネーム及びパスワードを入力する要求がユーザのデバイスに送信される。これは、HTTP基本認証の認証要求又はユーザネーム及びパスワードを入力するためのオンライン・フォームである。これによりユーザはユーザネーム及びパスワードを入力し、又はこれらの詳細を提供する自動的な機構を呼び出す。このような自動的な機構を呼び出すために、クッキーを取得する場合と同様の方法で、ユーザのデバイスがHTTP要求を特定のURL及びパスへと送信することが必要となる。
【０１６２】
他の例では、ユーザ・デバイスのIPアドレスを取得するために特別な処理が必要とされる。これは、ユーザ・デバイスからの通信がHTTPプロキシ・サーバ又はネットワーク・アドレス・トランスレーション（NAT、RFC２６６３）を通じて行われているのであれば必要となりうる。これらの条件の下でIPアドレスを取得する方法はPCT出願WO０１／１３２８９に述べられている。
他の例では、ユーザ・デバイスに提供されたソフトウェア・クライアントにより、SIが取得される。ユーザ・デバイスを実行するソフトウェアは通常オンライン・サービスと比べ、より高い特権を有するので、ユーザのデバイスに格納されたSI（例、HTTPクッキー、ソフトウェア識別子、ハードウェア識別子、蓄えられたユーザネーム及びパスワード等）に直接アクセスし、これらをSI取得手段４２へと送信することが可能である。
【０１６３】
上記の方法のいくつかは、ユーザ・デバイス１２に特別な要求を送信させることを必要とする。これを達成する１つの方法は、HTTPリダイレクト機構を用いることである。また別の方法は、例えば（「ウェブ・ビーコン」としても知られている）画像又はユーザ・デバイスに送信されたHTMLページのポップアップ・ウインドウのようなウェブ対象物へのリンクを組み込むことである。これにより、ウェブ対象物を検索するために要求された要求を送信する。例えばJava（登録商標）Script（Java（登録商標）Scriptの説明としては、developer.netscape.comネットスケープ・ディベロッパーズ・サイトを参照せよ）のようなクライアントサイドのスクリプト言語は、ユーザの干渉を受けることなく、ポップアップ・ウインドウを作成するために用いられることが可能である。しかし、他の方法は、ユーザ・デバイス１２にインストールされたソフトウェア・クライアントに要求された要求を送信するよう要求することである。例えば、このソフトウェア・クライアントによって、又はソフトウェア・クライアントと関連したMINEタイプを介してソフトウェア・クライアントを実行することによって、認識された専用のプロトコルを通じて行われる（MINEタイプの説明はRFC２０４６です）。
【０１６４】
SIをさらす要求は、同一のユーザからの以前のメッセージを伴うSSRを有する。これは平行に要求され、不正行為者が要求を送信することを防止し、他のユーザのセッションを引き継ぐために、異なるユーザからの要求が混じることはない。これは通常「割り当てられたシークレット」方式及びシークレットURLを用いて実行される。
【０１６５】
もし、何らかの理由のために、OSPAによってすでに、ユーザのデバイスが、電子財布、シングル・サインオン・サービス、取引認証サービス又はオンライン広告ネットワークのようなOSPA外部のサービスの要求を送信するならば、このようなサービスは、OSPAへと最小限の変更で又は変更することなく、ユーザのデバイスが任意の要求された要求を送信するために、任意の上記の方式とともに用いられる。この目的のためのこのような外部のサービスを用いることの利点は、複数のオンライン・サービス・プロバイダにより、ユーザのデバイスが同一の外部サービスへ要求を送信する場合よりも大きい。電子財布及びシングル・サインオン・サービスの例は、マイクロソフト・パスポート、AOLクイック・チェックアウト、及びヤフー・ウォレットである。取引認証サービスの例は、「３Dセキュア」である。オンライン広告ネットワークの例は、ニューヨーク州、ニューヨークの２４/７リアル・メディアである。
【０１６６】
（SSR連鎖）
SSRはまた、SSRの連鎖に基づいている。もしメッセージＡがメッセージＢを伴うSSRを有し、またメッセージBがメッセージCを伴うSSRを有するなら、メッセージA及びメッセージCもまたSSRを有する（全ての３つのメッセージは同一の送信者であると示されているので）。
メッセージA及びメッセージB間のSSRは、メッセージB及びメッセージC間のSSRとは異なるタイプであり、それぞれはまたメッセージBに関連する異なるSIに基づいている。例えば、メッセージCは、同一の固有の識別子を含む間、IMS（メッセージB）へ接続する時、IMCはTCPセッションにおいて固有の識別子を送信し、また、メッセージAはメッセージB（TCP「シークレット・ハンドシェイク」により検証される）と同一のIPアドレスを有する。他の例において、２つのSSRは、同一のHTTP要求に含まれるシークレットURL及びシークレット・クッキーとの「同一シークレット」関係に基づいている。しかしまた他の例において、他の１つは関連するIPアドレス（信頼性のあるアドレス）を有することに基いている間は、１つのSSRは、HTTP要求においてシークレット・クッキーと「同一シークレット」である。
【０１６７】
同一ユーザからのメッセージに関連するSIが長時間かけて変化する時に、SSR連鎖はとりわけ有用である。例えば、上記のようにインターネット・ユーザが使用するIPアドレスを長時間かけて変化する時、同一のユーザにより送信された２つのメッセージのソースIPアドレスは、弱いSSRのみを有するか、SSRを全く持たないことになる。このような場合、ユーザから送信された他のメッセージは、２つのメッセージ間のSSR連鎖を見つけるために用いられる。いくつかのオンライン・サービス・プロバイダはよりこのようなメッセージを受け取りがちである。１つの例は、頻繁に訪れるウェブサイト（a frequently visited website、FVW）である。FVWは多くの異なるユーザからのHTTP要求を受信し、この要求はIPアドレス及びシークレット・クッキーを含む。他の例としては、IMSがある。IMSは、ユーザから、彼らがインターネットに接続する度にログイン・メッセージを受信する。このログイン・メッセージは、IPアドレスと固有の識別子を含んでいるいことを特徴としている。また別の例として、上記のような、多くのユーザからＥメールを受信するオンライン・サービス・プロバイダがある。このＥメールは、上述するように、IPアドレス及びＥメール・ヘッダの複数のシークレットを含んでいることを特徴としている。
SSR連鎖に基づくSSRは、不正行為者により攻撃の可能性を与え（いかなるリンクも攻撃されうる）、このため比較的脆弱である。
【０１６８】
SSRの一例において、メッセージDは、IPアドレスＤからのHTTP要求Dで受信され、またIMCがIPアドレスＥからTCPのIMSへと接続する時、メッセージEが送信される。逆のDNSクエリーは、IPアドレスD及びIPアドレスＥが同一企業へと割り当てられていることを示す。
【０１６９】
この場合のSSR連鎖は以下の通りである。（ａ）メッセージDはHTTP要求Dに含まれた（あるTCPセッションにおける同一HTTP要求）。（ｂ）HTTP要求ＤはIPアドレスＤから送信された（TCPセッションにおいて現れるIPアドレス）。（ｃ）IPアドレスＤ及びIPアドレスＥは同一企業に割り当てられた（信頼性のあるアドレス）。（ｄ）メッセージＥはIPアドレスＥからIMSへと送信された（TCPセッションにおいて現れるIPアドレス）。
メッセージD及びメッセージEは同一送信者から派生していると考えられる。
【０１７０】
SSR連鎖の他の例において、メッセージAはIPアドレスＡからのHTTP要求Aで受信される。メッセージAの送信とほぼ同時にIPアドレスAから送信され、FVWで受信されるHTTP要求Bは、メッセージB及びシークレット・クッキーを含む。FVWで受信されるHTTP要求Cは、メッセージC及びHTTP要求Bと同一のシークレット・クッキーを含んでいる。
【０１７１】
この場合のSSR連鎖は以下の通りである。（ａ）メッセージＡはHTTP要求Ａに含まれた（あるTCPセッションにおける同一HTTP要求）。（ｂ）HTTP要求ＡはIPアドレスAから送信された（TCPセッションにおいて現れるIPアドレス）。（ｃ）HTTP要求A及びHTTP要求BはともにIPアドレスAから派生し、ほぼ同時に送信された（「信頼性のあるアドレス」）。（ｄ）HTTP要求B及びHTTP要求Cは同一のシークレット・クッキーを含む（「同一シークレット」）。（ｇ）メッセージCはHTTP要求Cに含まれた（あるTCPセッションにおける同一HTTP要求）。
メッセージA及びメッセージCは同一送信者から派生していると考えられる。
【０１７２】
SSR連鎖の他の例として、メッセージFがHTTPS要求Fで受信される。メッセージFに対する応答において、セキュア・シークレット・クッキーがドメイン「f.com」へと制限されて割り当てられる。メッセージGがHTTP要求Gで受信される。メッセージGに対する応答において、ユーザのデバイスはドメイン「f.com」のシークレットHTTPS・URLにリダイレクトされ、これによりこのURLはシークレット・クッキーを送信する。
【０１７３】
この場合のSSR連鎖は以下の通りである。（ａ）メッセージＦはHTTPＳ要求Ｆに含まれた（暗号手段による「インテグラル・メッセージ（Integral Message）」）。（ｂ）シークレットHTTPS・URLとともに送信されたセキュア・シークレット・クッキーは、HTTPS要求Fに対する応答に割り当てられた同一クッキーである（「割り当てられたシークレット」）。（ｃ）シークレットHTTPS・URLはHTTPS要求Ｇの送信者に送信された同一シークレットURLである（「割り当てられたシークレット」）。（ｄ）メッセージGはHTTP要求Gに含まれた（あるTCPセッションにおける同一HTTP要求）。
メッセージF及びメッセージGは同一送信者から派生していると考えられる。
【０１７４】
SSR連鎖の他の例において、メッセージＨはIPアドレスＨからHTTP要求Hで受信される。Ｅメール・メッセージＩはIPアドレスHからHTTP要求Hの送信とほぼ同じ時に送信された。Ｅメール・メッセージJはIPアドレスJから送信され、Ｅメール・メッセージIと同一の送信者名、送信者デバイス識別子、タイム・ゾーン及び個人署名を有する。HTTP要求Ｋは、Ｅメール・メッセージJの送信とほぼ同じ時にIPアドレスJから送信され、シークレット・クッキーを含んでいる。HTTP要求ＬはメッセージL及びHTTP要求Kと同一のシークレット・クッキーを含んでいる。
【０１７５】
この場合のSSR連鎖は以下の通りである。（ａ）メッセージＨはHTTP要求Ｆに含まれた（あるTCPセッションにおける同一HTTP要求）。（ｂ）HTTP要求ＨがIPアドレスHから送信された（TCPセッションに現れるIPアドレス）（ｃ）HTTP要求H及びＥメール・メッセージIはともにIPアドレスHから派生し、ほぼ同じ時に送信された（「信頼性のあるアドレス」）。（ｄ）Ｅメール・メッセージI及びＥメール・メッセージJは、上述のように、同一のSIを有する（「同一シークレット」）。（ｅ）HTTP要求K及びＥメール・メッセージＪはともにIPアドレスＪから派生し、ほぼ同じ時に送信された（「信頼性のあるアドレス」）。（ｆ）HTTP要求Ｌ及びHTTP要求Ｋは同一シークレット・クッキーを含んでいる（「同一シークレット」）。（ｇ）メッセージＬはHTTP要求Ｌに含まれた（あるTCPセッションにおける同一HTTP要求）。
【０１７６】
メッセージH及びメッセージLは同一送信者から派生していると考えられる。
【０１７７】
（同一人物条件）
（定義）
正しい検証はPI1 １００及びPI2 １０２が同一人物を識別することを必要とする。これが同一人物条件（Same Person Condition、SPC）である。もしPI1 １００及びPI2 １０２が同一人物関係（Same Person Relation、SPR）を有するなら、SPCは満たされる。（SPRの強さを測定する）SPRの強さは、複数の要因により変化しまたこれらに依存している。概して、もしPI1 １００及びPI2 １０２の具体性がより低い（すなわち、多くの人に関連する）のであれば、異なる人々が同一人物だと考えられる場合が多くなるので、SPRはより弱くなる。例えば、PI2 １０２はクレジットカード番号の下４桁であり、PI1 １００はこの４桁で終わるカード番号である。この場合、PI1 １００はPI2 １０２として作られた番号とは実際には異なるカード番号であるが、PI・１００及びPI2 １０２は同一人物と識別すると考えられる。これは、PI2 １０２の下４桁と適合する任意のカードが使用できるという点において、不正行為者にいくらか融通を与えることになる。PI2 １０２が具体性がより少なくなるにつれ（例、桁数がより少ない）、適合するカードを見つけることがより容易となり、攻撃をより容易にし、SPRはより脆弱になる。
【０１７８】
PI１・１０１又はPI2 １０２がどれくらい具体性を持つかを推定する場合、該当する集団において様々な人物識別子の大衆性を示すデータベースを用いることが有益である。例えば、もしPI2 １０２が名前を含むなら、様々な名前の大衆性の記述はPI2 １０２がどれくらい具体性を持っているかを推定することにおいて助けとなる。
【０１７９】
人は時々PIの一部を変更する（例、所在地住所の変更やクレジットカード番号の変更）。このような場合、SPRの強さは、２つのPIの送信間に経過した時間及び人々がこのようなPIを変更する傾向性に依存する。
【０１８０】
PI1 １００及びPI2 １０２が同一人物を識別するかどうかを推定する１つの方法は、同一部分を含むかどうかをチェックすることによって、これらを文字の類似性を調べることである。例えば、PI1 １００及びPI2 １０２は完全に同一（例。同一のフルネーム）となりうる。他の例では、PI2 １０２はPI1 １００の全て又は一部を含んでいる（例。PI2 １０２はクレジットカード番号を含んでおり、PI1 １００はこのカード番号の下４桁を含んでいる）。また他の例において、PI1 １００はPI2 １０２の全て又は一部を含む。概して、もしPI1 １００及びPI2 １０２の同一の部分が多く、また統計的により重要であれば、SPRはより強くなる。
【０１８１】
いくつかの場合、SPRを有することを示しているPI1 １００及びPI2 １０２の間の関係を見つけるために、より複雑な手続が必要とされる。例えば、PI1 １００及びPI2 １０２は意味は同じだがスペルの差異を伴う同一部分（例。「Forty-Second St.」及び「42nd street」）を有する。他の例では、PI1 １００はPI2 １０２の省略形を含んでおり、又はこの逆もまた同様である（例。Ｅメール「jhdoe2002@mail.com」及び名前「John Henry Doe」）。また別の例において、PI1 １００及びPI2 １０２は数字が近似する電話番号を含んでいる（すなわち、例えば555-1280と555-1281のように下数桁のみが異なる番号）。（電話会社はしばしば同一の顧客に連続する電話番号を割り当てるので）これらの番号は任意のランダムに選ばれたどの２つの番号よりも同一に扱われる。他の例において、PI1 １００及びPI2 １０２は地理的に近似する地理的パラメータを含む。人は遠い場所よりもより近い場所（近所の家やインターネット・カフェ、仕事場などの周辺）付近へと行きがちであるので、これらの番号は、任意のランダムに選ばれたどの２つの地理的パラメータよりも同一に扱われる。このようなパラメータの例は、同じ通りの連続した家番号又は地理上の計算によって近似すると理解される２つの緯度／経度調整である。
【０１８２】
PIディレクトリの使用
いくつかの場合において、SPRを検出するためにPIディレクトリの使用が必要とされる。
PIディレクトリは、それぞれが２又は３以上のPIに関連する記録を含むデータベースである。同一記録の各PIによって識別される少なくとも１人の人間がいることを特徴としている。この文脈において、データベースは、記録の内容についてのクエリーに応答可能な任意のシステム又はシステムの組み合わせである。
【０１８３】
例えば、ホワイト・ページ・ディレクトリのそれぞれの記録は、特定の名前、住所、電話番号によって識別される１人の人に関して格納されている。
他の例としては、クレジットカード発行銀行のデータベースがある。このデータベースのそれぞれの記録は、名前、クレジットカード番号、請求書あて先住所（クレジットカードの請求書が送付される住所）によって識別される１人の人に関して格納されている。
【０１８４】
他の例は、住所と地理パラメータ（例。緯度及び経度）を関連させる地理的ディレクトリ、又は携帯電話番号と携帯電話の現在の地理的位置を関連させる地理的ディレクトリである。
【０１８５】
他の例は、それぞれのＥメール・アドレスとこのアドレスを使用する人の名前を関連づけるＥメール・ディレクトリである。アドレス・フィールド（From、To、CC）は通常受信者の、又は送信者の名前を、Ｅメール・アドレスと同様に含むので、Ｅメール・ディレクトリは、Ｅメール・メッセージを分析することによって自動的に作成される。この場合、ディレクトリへの間違った又は不正な記録の追加を防ぐため、Ｅメール・メッセージは、信頼できるソースからであるのか検証されるべきである。
【０１８６】
他のPIディレクトリは、より具体性が少ない。例えば名前と国の間の相関関係（ある国においてのある名前の大衆性）を示すディレクトリである。このようなPIディレクトリにおいてそれぞれの記録はある国においてある名前を有する人々の数（又は一部分）を表す。
【０１８７】
いくつかのPIディレクトリは時期が異なるという以外は同一タイプのPIに関連する。例えば、住所変更データベースのそれぞれの記録は、時期が異なる同一人物（又は家族）の住所を含んでいる。
【０１８８】
いくつかのPIディレクトリは、オンラインでの識別のために特別に作成されている。例えば、後述のような、コードがユーザのメールアドレスに送信される場合、各コードとコードが送信される名前を関連付けてPIディレクトリが作成される。他の例において、上述のペイパル・システム（PayPal System）は、各クレジットカード番号をクレジットカードの課金をする際に用いられるシークレット・コードと関連付けてPIディレクトリを使用する。
【０１８９】
情報要素をPIディレクトリのPIと関連付けることによって、この情報要素がPIとなることに注意する。例えば、政府のデータベースがID番号を各国民に割り当てて作成される時（例。フルネーム、誕生日、両親の名前によって識別される）、このそれぞれのIDはPIになる。
【０１９０】
PIディレクトリを用いる時、もし記録が、PI1 １００とSPRを有するPIと、PI2 １０２とSPRを有する他のPIとを関連付けるならば、PI1 １００及びPI2 １０２はSPRを有する。
PIディレクトリへのアクセスは、２つの方法で実行される。第１の方法では、いくつかの（しかし全てではない）PIが該当する１つの記録（クエリーでPIとSPRを有するPIを含む記録）又は複数の記録を位置付けるためにクエリーとして与えられ、またもし見つかったなら、この１つの記録又は複数の記録は検索され、応答で送信される。データ移動を最小化し、又は情報の機密性を保持するために、応答で送信される記録の数を制限すること（例。最も新しい記録のみ）、又は各記録から送信されたPIの数を制限すること（例。クエリーに既に現れているPIを送信しないこと）が可能である。
【０１９１】
例えば、もしPI1 １００が電話番号であり、PI2 １０２がフルネーム及び住所であるなら、PI2 １０２とSPRを有するPI（例。スペルの差異を伴う同一の名前及び住所）を含む記録を見つけるために、PI2 １０２を含むクエリーはホワイト・ページ・ディレクトリに送信される。この応答は名前及び住所と関連する全ての電話番号を含んでいる。上述のように、検索した数はその後PI1 １００とのSPRのためにチェックされる。別のホワイト・ページ例では、クエリーは電話番号であり、この返答は関連する名前及び住所を含んでいる（概して「リバース・フォン検査（reverse phone lookup）」として知られている）。
【０１９２】
第２の方法では、少なくとも２つのPIがクエリーとして与えられ、またこの応答は、これらのPIによって識別された人が存在するかどうか（又はどのくらいこのような人が存在するか）を示すことによって、該当する記録が存在するかどうかを記す。例えば、もしPI1 １００がクレジットカード番号をんでおり、PI2 １０２が住所を含んでいるなら、クエリーは、PI1 １００及びPI2 １０２を含む上述のＡＶＳサービスへと送信される。この応答は、記録が存在するかどうかを記すYes/Noアンサーである。このYes/Noアンサーにおいて、カード番号はPI1 １００とSPR（すなわちPI1 １００と同一）を有し、また住所はPI2 １０２とのSPRを有する。このような記録を見つけることは、通常PI2 １０２がPI1 １００によって識別されるクレジットカード口座の所有者の請求書宛先住所であることを示す。
【０１９３】
２つの方法の任意の組み合わせも、当然のことながら可能である。例えば、クエリーは２つのPI及びこの記録が存在するかどうかを記した応答を含んでおり、またもし記録が存在するなら同一記録からの第３のPIも含んでいる。
【０１９４】
いくつかの場合において、クエリーへの応答は明確に提供されるのではなく、むしろ他のアクションから促される。例えば、処理のために取引を提示するオンライン取引業者は住所情報を含んでおり、またこの取引は住所がAVSチェックを通る時のみ許可される。この場合、正しい取引許可はAVSの適合を示す。
【０１９５】
いくつかの場合においては、PIディレクトリに対する明白なクエリーがなく、応答は他のアクションの結果として受信される。例えば、OSP１４は、オンライン購入手続の一部としてユーザ１０からＥメールを受信する。このＥメールは、ユーザ１０の名前及びＥメールアドレス間の関連性を含んでおり、従ってＥメール・ディレクトリからの応答に相当する。
【０１９６】
PIディレクトリへのアクセスは任意の利用可能なプラットフォーム上で実行されることに注意する。例えば、クレジットカード番号及びカード所有者の名前間の適合を検証するために、人はマニュアルに従って、発行銀行に対し声による電話の呼び出しを行う。
【０１９７】
PIディレクトリの使用は、特に１対１の関係を表さないPIディレクトリを用いる時に、PI1 １００及びPI2 １０２間のSPRを脆弱にすることを注意する。このようなディレクトリは、異なる人が同一人物として識別される場合を増加する。１つのタイプのPI（例。SSN）がディレクトリに関連する他のタイプのPI（例。このSSNを有する人の住所）と代わる時、識別されたグループは、第２PI（例。この人と同じ住所に住んでいる人々）とディレクトリ関連する第１タイプのPIを有する全ての人に広がり、彼らは異なるとは言えない。
【０１９８】
PIディレクトリは、PI2 １０２、PI1 １００又はこの両方によって識別される人々の全番号（又は一部）を見つけるために用いられる。上述のように、これらの番号は、SPRの強さを推定する際に助けとなる。
【０１９９】
一例として、PI1 １００は社会保障番号（Social Security Number、SSN）であり、PI2 １０２はクレジットカード番号である。クレジットカード発行者のデータベースは、SSNとクレジットカード番号を関連付けるPIディレクトリとして使用される。PIディレクトリは、一人の人のみがこのSSN及びクレジットカード番号とともに存在することを示す。これはカードが一人の人間のみに発行されたことを示す。これは通常強いSPRを示している。
【０２００】
他の例において、PI2 １０２はアパートの住所であり、PI1 １００はフルネームである。ホワイト・ページ・ディレクトリは、この名前を有する一人の人間がこの住所に住んでいることを示す。しかし、また複数の人間がこの住所に住んでいることも示す。従って、SPRは１つ前の場合ほど強くはない。
【０２０１】
他の例において、PI2 １０２はファースト・ネームであり、PI1 １００は国である。異なる国における名前の大衆性を表すPIディレクトリは多くの人々がある国においてある名前を有し、一方で小数の人々がこの国外でこの名前を有していることを示す。これはSPRが存在するがこの前２つの場合よりも強くはないことを示す。
【０２０２】
PIディレクトリの正確性及び信頼性はSPRの強さに影響を与えるということに注意する。PIディレクトリにおいて紛失、期限切れ、又は誤りのある記録の可能性はSPRを推定する際に考慮されるべきである。
【０２０３】
（ＳＰＲ連鎖）
SPRはまたSPRの連鎖に基づく。もしPIAがPIBとSPRを有し、PIBがPICとSPRを有するなら、PIA及びPICもまたSPRを有する（全ての３つのPIは同一人物を識別するために用いられるため）。それぞれのSPRはタイプが異なり、またPIディレクトリに基づいている。
【０２０４】
例えば、PI2 １０２は名前であり、PI1 １００はクレジットカード番号である。ホワイト・ページ・ディレクトリは該名前と関連する１つの住所（又は複数の住所）を見つけるために用いられる。次に、AVSサービスは、住所（又は複数のうちの住所の１つ）がPI2 １０２のクレジットカード番号の請求書宛先住所であることを検証するために用いられる。これは第３PI（住所）を経由するPI1 １００及びPI2 １０２間のSPRを示す。
【０２０５】
（上記の１つのPIディレクトリの使用と比較すると）SPR連鎖又は複数のPIディレクトリの使用は更にSPRを脆弱にする。最後の例において、該当するグループは、カードと関連した任意の住所と同一の住所を有するある人と、同一の名前を有する任意の人へと範囲が広げられる。
【０２０６】
更に、SPR連鎖を用いる時にSPRの強さを推定する際、人物識別子の適合部分のみが考慮される。例えば、PI「john2002」は、PI「bobdoe」の一部を含むPI「John Doe」の一部を含んでいる。しかし、PIの各組の同一部分は完全に異なる（「john」が第１組、「doe」が第２組）ので、「john2002」と「bobdoe」間には明白なSPRはない。
【０２０７】
PIディレクトリ・クエリーへの応答が、他のクエリーで用いられる多くのPIを含んでいる場合（例。後述のような、他のPIディレクトリに送信された、又はPISIDB）、クエリーの数を絞るため付加PIはOSP１４によって提供される。上記のAVS例において、ユーザの住所は、この人物の名前に従って提供される。ホワイト・ページ・ディレクトリの名前と関連した住所を有するAVSクエリーを作成する代わりに、名前が提供される住所と関連することを検証するために、１つのクエリーが作成され、またAVSクエリーが、提供される住所がカードと関連することを検証するために作成される。
【０２０８】
PI２の真となる条件
正しい検証は、PI2 １０２がPI2・１０６の送信者を識別することを必要とする。これがPI２の真となる条件（True Condition、TC）である。PI2が真である確率（PI２検証レベルという）は複数の要因で変化し、またこの要因に依存する。特に、PI2 １０２が真であることを検証するために用いられる方法及び不正行為をする影響が考慮される。いくつかこのような方法が存在する。
【０２０９】
既存の検証方法
PI2 １０２は、人物識別子を検証するための任意の既存の方法を用いて変化する。例えば、もしPI2 １０２が通常不正行為者がアクセスできない情報（例。有効なクレジットカード番号又は銀行口座番号）を含んでいるならば、又は（例えば、銀行口座番号と適合するPIN、又は上述のようなEquifaxアンケートに対する正確な応答）このような情報がPI2 １０２へと提供されるならば、このPI2 １０２は真であると考えられる。
【０２１０】
正しいオフライン・アクション
PI2 １０２を検証する他の方法は、PI2 １０２に基づく正しいオフライン・アクションを実行することである。
例えば、もしPI2 １０２がオンライン購入の間に受信したクレジットカード番号であれば、購入商品のためにカードに課金し、また真偽を問われることがないことはPI2 １０２を検証する。
【０２１１】
真偽の問合せは通常即座に報告されないので、PI2 １０２が真であると考えられるまでにかなりの期間が課金後経過することに注意する（通常２、３か月）。
【０２１２】
真偽が発生したかどうかの検出は、真偽されている取引を追跡し続け、PI2 １０２に従ってマークすることにより行うことができる。或いは、十分な時間の経過後は、アカウントが有効であることをチェックしてもよい（例えば、クレジットカード認証取引を送信することによって）。アカウントは通常、権限の無い使用に従わないようにブロックされているから、このことは真偽が発生しなかったことを保証する。
【０２１３】
オフライン処理による検証システムの他の例では、一意の暗号をメールアドレスに送信し、受信者にこの暗号をオンラインに提供するように要求する。この一意の暗号は、ユーザを識別し、本発明では、PI2 １０２として使用される。このコードを送信した当事者は、PIディレクトリを作成する。このPIディレクトリは、当事者に送信されてきたアドレスと一緒に当事者が送信した各暗号に関連している。暗号が提出されているときの通信では、送信者を識別し、従ってPI2 １０２を検証する。このことは、通常、送信者がPIディレクトリにある暗号に関連づいたアドレスの持ち主であることを意味する。署名されたメール又は他の信頼性のあるメールサービスを用いるとこの方法はより強度が増す。ユーザは、暗号をオンラインに手動入力で送る（例えば、フォームに暗号をタイプする）ことができ、或いは暗号をコンピュータが読み取ることのできるメディアに保存して自動的に供給させることもできる。
【０２１４】
同様に、暗号は特定の電話番号に電話することにより送ることができる。返された暗号で通信すると、暗号の送信者が、前記電話番号にアクセスしている人物であると識別される。暗号は声で又はデータ通信セッション（例えばモデムを用いた）によって、電話で提供される。
【０２１５】
或いは、暗号は、電話番号のやり取りを含む通信（PI2 １０２）を返答することによってオンライン上に提示される。次に上記認証システムにおいて記載したのと同様に、ユーザは暗号をこの電話番号（すなわちどこからかけてきたか分かる電話番号）との電話中に提供する。これは、送信者の暗号が権限を与えられていないユーザに受信されない限りPI2 １０２を検証する。
【０２１６】
（不正の中でも非典型的な使用パターン）
PI2 １０２を検証する別の方法は、受信したものが非典型的な不正かどうか状況を解析することである。
このような方法の１つは、PI1 １００とPI2 １０２が送られてきたときのタイムスタンプを解析することである。オンラインは、通常短時間（例えば、クレジットカードを盗んでそれが使用停止になるまでの間）で起こる詐欺行為を識別するから、もしも、PI2 １０２がPI1 １００の送信前後で無視できないくらい長い時間、送信され、ＳＰＣとＳＳＣが真だとみなされた場合、PI2 １０２は真である（従ってPI1 １００も同様に検証される。そうでなければ、長い期間に、不正行為者が２度、同一人物になりすましたことを意味し、これは、非典型的である（すなわち、不正行為者は被害者の身元を予め知っているか、情報を取得しこの情報を使用して不正を犯す間のかなり長い期間、不正行為者が待機していたことを暗示する）。したがって、このかなり長い時間とは、１人の犠牲者に対する典型的な１回の詐欺行為時間よりも、はるかに長い時間である。
【０２１７】
他の方法では、不正行為者に不正をする気にさせないようなサービスが提供されると、PI2 １０２が、真とみなされる。例えば、不正行為者が、他人のクレジットカードの詳細にアクセスしたら、このカードに登録された名前で、否応無く無料でオンライン上の日付を付けるサービスに登録される。従って、無料の日付を付けるオンライン・サービスにおいて受け取ったPI2 １０２は、（例えば、このサービスの登録中）真とみなされる。
【０２１８】
他の方法では、PI2 １０２は、本物のユーザによる明らかに通常のオンライン活動であるときとPI2 １０２が関連付けられた場合、PI2 １０２は、真であるとみなされる。不正行為者は、不正の目的だけのために被害者になりすますので「明らかに通常のオンライン活動」は、不正目的のために必要以上量の個人情報を1回で盗むようなオンライン使用時を明確にする。例えば、PI2 １０２は、ウェブ上のＥメール・サービスに登録している間提供される。そしてこのＥメール・アカウントに関連したものは、他の本物のユーザからのたくさんの有意義なメッセージを受信したり送信されたときに、PI2 １０２が真とみなされる。
【０２１９】
更に他の方法では、PI2の送信者 106に使用されたデバイス上からクッキー及び他の一意な情報要素が消去されていないとみなされるときは、PI2 １０２は、真であるとされる。将来の不正行為に関する調査を難しくするために、不正行為者はこのような情報要素を自らのデバイスからを消す傾向があるため、この方法を使用することができる。デバイスから情報要素が消去されているかのチェックは、上述したSIを取得するための方法（及び特にクッキー又はユーザ名とパスワードを取得するための方法）を用いることによってなされる。このとき、いかなるSIも取得できなかった場合、デバイスから情報要素が消されているとみなすことができる。
【０２２０】
不正が非典型的と考えられるとき、PI2 １０２を送信して不正行為者が利益を得ても、本発明の実施により、この利益を利益でなくすることは、注目すべきことである。これは、PI1 １００の誤検証に基づいて不正取引が受理される可能性を高めるような特殊なタイプの不正の時、特にあてはまる。
【０２２１】
不正行為者が本発明に気づいた場合、彼らは、正常な状態を真似ようとするから、もはや不正に関して特殊なタイプではなくなる。従って、不正が特殊なタイプの時にPI2 １０２を受信したときは、PI2 １０２の時点で本発明に気づいた不正行為者の番号に注意を払うべきである。
【０２２２】
（信頼性のある権限を与えられたエージェント）
他の方法では、PI2 １０２が（上述の）PI2の送信者 106の権限を与えられたエージェントにより提供され、このエージェントが信頼性のあるとされる場合、このPI2 １０２は真とみなされる。例えば、大きな会社のシステム・アドミニストレーターは、会社のｅメール・サーバー上に新しい社員を登録するときの詳細を提供する際に信頼がおけるとされる。システム・アドミニストレーターだけが登録作業を行っていれば、登録中に会社に送信されてきたPI2 １０２は、真とされる。
【０２２３】
（帰納法）
別の方法では、PI2 １０２の検証に対して帰納的に本発明を使用する。この場合、PI2 １０２を他のPI（PI3）の条件を満たすように検証する。すなわち、PI2 １０２をPI3の時と同一の人物を識別するはずであり、PI2の送信者１０６とPI3の送信者は同一人物である。そして、PI3が真とされる。
このことは、PI1 １００のPI2 １０２による検証、PI2 １０２のPI3による検証・・・というように検証連鎖を効果的に作り出す。
【０２２４】
（システム）
図３は、検証システム３０の構成要素を示す。
受信手段３２は、検証要求６０を受信する役割を果たし、報告手段３４は、検証報告６２を送信する役割を果たす。
検証推定手段３６は、上記にて詳細に説明した通り、検証条件が真であるかを推定する役割を果たす。
【０２２５】
検証システム３０は、PIディレクトリ・クエリー・モジュール５４を有していても良く、このＰＩディレクトリ・クエリー・モジュールは、少なくとも１つのPIディレクトリ５６にクエリーを送信するために使用される。
PIディレクトリ・クエリー・モジュール５４とPIディレクトリ５６は、上記にて詳細に説明した通り、検証推定手段３６がSPCをチェックするのを支援する。
検証システム３０は、PI-SIデータベース（PISIDB）クエリー・モジュール５０を有していても良く、このPI-SIデータベース（PISIDB）クエリー・モジュール５０は、少なくとも１つのPISIDB５２をクエリーするのに使用される。
【０２２６】
検証システム３０は、少なくとも１つ以上のPISIDB５２を有していても良い。PISIDB５２は、データベースであり、PI-SI記録を含んでいる。各PI-SI記録は、検証条件推定時のPI2 １０２とSI2として用いられるPIとSIを含んでいる。このようなSIは、それぞれ、同じ記録にあるPIの送信者の印である。各記録は、このようなSIを別途にいくつか有していてもよい。
各記録は、PI2検証情報（PI2VI）を有していても良い。PI2VIは、PI2が真であるかの決定に関連した情報である。例えば、PI2VIは、標準的なオンライン上での検証プロセスの結果や、PI2が送信された（又は受信された）時間、本発明を用いたPI2の検証結果などを含んでいる。PI2VIは、例えば次のようなときには、削除しても良い。すなわち、PISIDB 52が検証済みのPIの記録だけを含んでいることが分かっているときや、PIの内容をもとにこのPIが真であるとされるときなどである。
【０２２７】
通常、PISIDB５２は、標準関係データーベースであり、従って、複数のSIと複数のPIの関連付けは簡単である。その他場合、PISIDB５２は、テキスト形式のログファイルであり、この場合、関連付けられた複数のSIと複数のPIが、連続した２つのテキスト型の区切り文字の間に記録されることが、関連であるとされる（例えば、これらのSIとPIが同じ回線上にあろうと無かろうと、連続した２つの空の回線間に存在する場合などである）。
【０２２８】
PISIDB５２の例としては、各記録がクレジットカード番号（PI2 １０２）とこのカード番号を受信（SI2）したIPアドレスを有しているデーターベースが挙げられる。他の例としては、次のようなデーターベースが挙げらる。すなわち、通信によって受信した名前とホーム・アドレス（PI2 １０２）、この通信（SI2）の送信手段によって送信された一意のクッキー、及び名前とアドレスが受信（PI2VI）された時間を含む各記録が存在するデータベースである。また他の例としては、IMSが所有するデータべースが挙げられ、このデータベースにおいては、各記録が名前と年齢（PI2 １０２）、登録中のユーザのIMCに割り当てられた一意の識別子（SI2）及び登録の登録時間（PI2VI）を含む各記録が存在する。
【０２２９】
検証システム３０は、ハッシュ発生手段４０を有していても良く、下記にて詳細に説明するように、ハッシュ発生手段４０は、PI及びその他の情報要素のハッシュを生成するために用いる。
検証システム３０は、SI取得手段４２を有していても良く、上記にて詳細に説明したように、SI取得手段４２は、SIを取得するために用いる。
【０２３０】
検証システム３０は、OSP１４や単独の操作者などに物理的に位置させることができる。検証システム３０の要素は、いくつかの異なった場所に割り当てることができる。例えば、PISIDB５２がオンライン・サービス・プロバイダによって所有され、このプロバイダがPISIDB５２を自らの回線内に配置するように要求したら、検証システム３０の構成要素は、PISIDB５２以外は全て、どこにでも位置することが可能である。PISIDB５２は、オンライン・サービス・プロバイダのところに残り、PISIDBクエリー・モジュール５０がPISIDB５２と一体となってこのネットワーク全体を通じて通信する。
【０２３１】
検証システム３０の２つの要素が同じデバイス上に存在する場合、或いは地理的に近接したデバイス上にある場合、これらは、それぞれ、内部データ・バス、又はローカル・エリア・ネットワークを介して通信する。これらが、互いに遠く離れたところに位置している場合、これらは、使用できるワイド・エリア・ネットワークのどれかを通して通信する。このワイド・エリア・ネットワークとしては、例えば、インターネット、個人のデータ・ネットワーク、ケーブルテレビ・データ・ネットワーク及び、モバイル・データ・ネットワークを挙げることができる。或いは、２つの要素は、同一の中央演算装置（CPU）上で動作する２つのソフトウェア、或いは、１つのソフトウェア中の２つの部分であっても良く、この場合、これらは、CPU中の内部要素を用いて通信する。公的なネットワークを介した通信は全て、トランスポート層セキュリティ（TLS：RFC2246参照）プロトコルといった安全な認証された通信チャネルを使用するのが好ましい。同一通信の選択肢とは、検証システム３０（例えばユーザ・デバイス１２とOSP１４）と通信するエンティティに当てはまる。
【０２３２】
例えばユーザ・デバイス１２とOSP１４の間の通信に対してHTTPSのような安全な通信チャネルを用いることは、大抵、有益である。例えば、ユーザ・デバイス１２に安全でない接続を使用しているPI1 １００とSI1を受信し、SI1がシークレットなら、不正行為者はPI1とSI1に関連づいたものの両方を傍受により取得し、これらを使用してユーザ１０に成りすます。ユーザ・デバイス１２への安全な接続はこの不正行為をより難しくする。
【０２３３】
（プロセス）
図４は、本発明の好ましい実施形態に即した典型的な検証プロセスを示す。
OSP１４が受信したPI１００の検証を望んだとき、OSP１４は、検証システム３０の受信手段３２に、検証要求６０を送信する（段階２０２）。検証要求６０は、PI1 １００を有し、任意にSI1及び／又はPI2 １０２及び／又はSI2及び／又はPI2VIを有することもできる。検証要求６０は、更に情報を有することができ、この情報（例えば、上述の狭域PIディレクトリ・クエリーに用いるPI）は、検証システム３０のタスクを支援する。
【０２３４】
次に、検証推定３６は、各検証条件が真であるかどうかを推定する（段階２０４）。上述のように、通常は、情報要素PI1 １００、PI2 １０２、SI1、SI2と時にPI2VIを調査することにより該検証推定を行う。全ての要求された情報が取得可能であれば、検証推定３６は、直接検証条件をチェックできる。
【０２３５】
いくつかの情報要素が行方不明であれば、検証推定３６は、行方不明の情報要素と関連した検証条件をチェックするために、PISIDBクエリー・モジュール５０を使用する。行方不明情報要素に関連した検証条件のチェックは、行方不明情報要素を取り出すことによって、関連した検証条件を満たす情報要素が存在しているかクエリーすること（条件クエリー）によって、或いは両方を組み合わせることによって、可能である。特に、検証推定３６はPISIDBクエリー・モジュール５０に、いくつかの検証条件を満たすPI-SI記録をクエリーすることを指示し、次にこのような記録（複数の場合がある）から残りの検証条件をチェックするために必要な要素を取り出すことを指示する。
【０２３６】
検証推定３６は、次の（ａ）〜（ｃ）を調査することにより、検証条件のチェックを進めていく。すなわち（ａ）検証要求６０において提供された情報要素；（ｂ）PISIDBクエリー・モジュール５０によって取り出された情報要素と；（ｃ）条件クエリーの結果。条件クエリーの結果の検討が、関連した条件を真であるかの推定に相当するとされることは、本発明の背景において着目すべきである。
【０２３７】
例えば、PISIDBクエリー・モジュール５２がある記録を取り出す。この記録においては、PI1 １００における人と検証されたことが示されたPI2VIにおける人とが同一人であることを識別する。次に検証条件３６は、取り出された記録内のSI2と、PI1の送信者１０４を示すSI1、及びPI2の送信者１０６が同じ人物であることを確認する。
他の例では、PISIDBクエリー・モジュール５０がある記録を取り出す。この記録では、PI1の送信者１０４とPI2の送信者１０６が同一人物であることをSI2とSI1が指示し、次に検証推定３６が、取り出された記録中のPI2 １０２がPI1 １００と同じ人物であること識別しているかの確認と、PI2VI検証済みを取り出された記録中のPI2VIが示していることの確認とを行う。他の例では、PISIDBクエリー・モジュール５０がある記録の存在を単に確認するだけで、記録からいかなる情報も取り出さない。この記録においては、全ての検証条件が満たされている。
【０２３８】
時には、PI2 １０２及び／又はPI2 １０２に関連したPI2VIがユーザ・デバイス中に保存されている。例えば、ユーザ１０のフルネームとこれが提供された時間がクッキーに保存されており、このクッキーは、上記した方法のいずれかを使用することにより、取得できる。他の場合では、名前と時間がユーザ・デバイス１２にインストールされたクライアントソフトウェアによって保存され、ユーザ・デバイス１２は、何らかの独自のプロトコルでの識別要求を受信したときに、名前と時間を送信する。ユーザ・デバイス１２（又は、他の信頼性のない発信元）から、PI2 １０２又はPI2VIを受信したとき、データを何らかの形で守らねばならない。なぜなら、不正行為者が簡単にこのようなデータを捏造し、システムに対して不正を働くからである。データ保護手段の例としては、HMACアルゴリズム、又はRSAサインアルゴリズムが挙げられる。このような手段を使用するときは、検証システム３０がデータの所有者（すなわちそのデータを保護している人々）にデータ内容の信頼性を検証するように要求せねばならない。或いは、データの所有者がデータ保護方法（例えば関連する暗号カギ）の必要な詳細部分を提供し、データの信頼性を検証できるようにすることができる。
【０２３９】
最後に、報告手段３４が、検証推定手段３６の推定に従って、検証報告６２をOSP１４（段階２０６）に送信する。このとき、報告手段３４は、PI1 １００が真であるかどうか指摘する。
検証報告６２は、全ての検証条件が満たされたら、陽性報告を出すことができる。検証条件が全て満たされなかった場合は、陰性報告を出すことができる。検証報告６２は、PI1 １００が真である確率を示すスコアを提供することができる。何を送信して返答するかを決定する方法及び、どのように上記スコアを計算するかを決定する方法は、後述する。
【０２４０】
検証報告６２は、検証プロセスで得られる更なる情報を有することができ、この情報としては、プロセス（例えばPI2 １０２、SI2、PI2VI）で用いた情報要素、SPR強度、SSR強度、或いは、PI2検証レベルが挙げられる。
【０２４１】
PI1 １００がPIのセット（例えば名前と住所）であれば、検証報告６２は、各PI1 １００のサブセットによって、又はいくつかのサブセット（例えばPI2 １０２が、複数のPIの中でただ１つにしか適合しない場合）によって、分割して報告することができる。
いくつかの場合では、PISIDB５２を複数回クエリーすると、好都合である。例えば、SSRがIPアドレスの類似性に基づいているとき、OSP１４の検証要求６０の送信後においてのみ、FVWは、ユーザ１０からのメッセージを受け取る。前記ユーザ１０からのメッセージは、自らの名前（PI2 １０２）及び、現在のIPアドレス（SI2）を有する。この場合、PISIDB５２中の関連した記録は、検証要求６０の送信後に作られ、検証報告６２は、この記録が検出されたとき（他の検証報告６２がすでに送信されていたとしても）に、送信される。或いは、PISIDBクエリー・モジュール５０から他のクエリーを受信していることが明らかでないときに、PISIDB５２は、当該の最新情報を送信することができる。
【０２４２】
（PI1の検証レベル）
本発明により達成された検証レベルは、完全ではなく、偽であるPI1 １００が真とされ得るし、真であるPI １００が真とされ得る。このような間違いの可能性は、多岐にわたり、多くの要素に依存する。
OSP１４は、自らの検証レベル要求を決定せねばならない。このような要求の確定は、不正行為（「偽陰性」により生じ得る損害の大きさに制約され、同様に、真であるものを拒否する（「偽陽性」）の可能性にも制約される。このような要求は、通常、関連するリスクと利益によって、決定する。例えば、オンライン上の販売者は、輸送費が高く利益の低い商品（例えばテレビ）は、輸送費が安く利益の高い商品（例えばソフトウェア製品）よりも、高い検証レベルを要求するものとせねばならない。
【０２４３】
本発明は３つの検証条件に依存するから、PI1 １００の検証レベルは、SSR強度、SPR強度及び、PI2 １０２の検証レベルに依存する。これらが高いほどPI1 １００の検証レベルは高い。
PI1 １００の検証レベルの推定において、全ての起こり得る不正行為のシナリオを考慮に入れ、不正行為を困難にすべきである。なぜならほとんどの不正行為者は、これらの関連のうち、少なくとも１つに依存して攻撃を仕掛けてくるから、PI1 １００が偽であるのに真とされる確率は、これらの関係が危うくなる確率に依存する。
【０２４４】
検証プロセスにおいて使用する外部のデータ源の正確さと信用性は、PI1 １００検証レベルに影響すると言える。PIディレクトリ５６、PISIDB５２、DNS及び「フーイズ」は、全てこのようなデータ源の例である。
PI1 １００の検証レベルと検証レベル要求を確定するための方法がいくつか存在する。
【０２４５】
その１つの方法として、どの場合を受理し、どの場合を拒否するかを決めるルールに基づいた論理を使用することである。例えば、システムを次の場合のときのみ陽性報告するように設定することができる。すなわち（ａ）PI1 １００はカード番号である、（ｂ）安全なクッキーをユーザ・デバイス 12から取得する、（ｃ）クッキーがPISIDB５２における名前（PI2 １０２）に関連している、（ｄ）名前がカード発行者の所にあるPI1 １００に関連したカード所有者の名前と一致している、（ｅ）PI2 １０２が、少なくともPI1 １００が提供される６ヶ月前に提供されている、という場合である。
【０２４６】
他の方法は、ニューラル・ネットワークのような自動学習技術を用いる方法である。例えば、ニューラル・ネットワークは、全ての関連するパラメータ（例えば、どのようにPI2 １０２を検証するか、SSRの手法、SPRの強度など）を入力として受信でき、PI1 １００が真か偽かの推定を作成することができる。このような技術を使用しているシステムは、トレーニング段階を必要とし、この段階で入力を必要な応答と連動するように準備し、システムは将来、入力に対し正確な応答を返すように自らを調整する。
【０２４７】
他の方法は、確率論的解析を用いる方法である。この方法では、全ての関係する情報を、起こりうる仮定（真のPI1 １００又は、偽のPI1 １００）のそれぞれを援護する証拠として検証する。標準の条件付き確率計算（例えば、ベイズ理論）を用いて、PI1 １００が偽である確立を計算することができる。この可能性は、受容可能なリスクの最大値を表す閾値と比較することができ、可能性がこの閾値を越えるとPI1 １００が偽とされる。
【０２４８】
（PI-SI相関）
SIとしてシークレットを使用する場合、不正行為者が被害者の身元を通常知っているという事実に基づいて、シークレットの強度を検証する。不正行為者が被害者の身元を知っているということは、PI1 １００により識別される人のPIに関連したシークレットの強度を弱くする。
例えば、ユーザネーム、ｅメールアドレス、又は「ｆｒｏｍ欄」の名前すなわち、ＳＭＴＰヘッダーは全て送信者の名前、又は名前から派生したもの（例えば、John Smith氏のユーザネームにありそうなものは、johnsmith、john_smith、jsmith、johnsなどである。）を含んでいることが多い。従って、これらは、強いシークレットとは考えられない、なぜなら、被害者の名前を知っていれば不正行為者は比較的簡単にこれらを推測することができるからである。
【０２４９】
他の例では、被害者の家の住所を知った不正行為者がその住所に近いISPPOPに接続して、このPOPからIPアドレスを割り当てられる。このことは、前記IPアドレスと、PI2 １０２を提供するために被害者が過去に用いたIPアドレスとが関連していると、本発明が検出してしまう可能性を高めてしまう。このことは、シークレットとしてのIPアドレスの強度を弱めてしまうが、「信頼できるアドレス」としての強度は弱めない（「信頼できるアドレス」としては例えば、被害者は指定されたアドレスを所有することができ、被害者のISPは、この指定されたアドレスを他の使用者に割り当てないので、不正行為者は、この固有のIPアドレスを知っていても使用することができない）。
【０２５０】
シークレットの強度に影響する他の関連性は、ユーザになりすます可能性の高い人物と、このユーザのSIとして用いたシークレットにアクセスできる人物の間にある。この相関関係が強いと、シークレットは弱くなる。
例えば、生徒は自分の先生からクレジットカードを盗むかもしれない。そして、このクレジットカードを使って学校の図書館にあるコンピュータからオンラインで買い物をするかもしれない。このコンピュータを以前にカードを盗まれた先生が使用したことがあるかも知れず、この先生に割り当てられたシークレット・クッキーがコンピュータにある可能性がある。このコンピュータへのアクセス権を持つ生徒は、行き当たりばったりの不正行為者よりも先生になりすまし易く、シークレットは弱いので、このことを捉えておかねばならない。
【０２５１】
同様に、子供は両親のコンピュータから両親のクレジットカードを使ってオンラインで買い物をするかもしれない。
このような関連性は、PI2 １０２が同一人物と識別していないときでさえ、PI1 １００は正しい検証結果を出すこともできる。このことは、ユーザが他のユーザのシークレットに、両者が同じPIによって識別されたときと同じ理由で、アクセスできたときにも起こりうる。例えば、父親が家族のコンピュータを使って、自分の名字（PI2 １０２）を与えられ、シークレット・クッキーを受信したオンライン・サービスに登録する。子供は彼のフルネーム（PI1 １００）を送信しながら、同じコンピュータを使って違うオンライン・サービスに登録する。シークレット・クッキーが取得され、PI2 １０２が読み出され、PI1 １００（同じ苗字）に合致すると判断される。この場合、PI1 １００とPI2 １０２が違う送信者によって送信され、違う人物であると識別されても、同じコンピュータを同じ苗字の人が用いたという事実から、PI1 １００の検証が正確であるとみなされる。
【０２５２】
（その他）
（ハッシュ）
OSP１４が検証システム３０の全ての構成要素をコントロールしていない場合、OSP１４が検証システム３０に対するユーザ１０の重大な識別情報を表示しないことが要求されることもある。このような場合、PI1 １００（又はその一部）を検証要求６０における検証システム３０に送信する前に、ハッシュすることができる。この状況においてハッシュを行うと、１つの情報セット（情報源）から他（ハッシュ）に、マッピングする方法と定義することができ、次のようなマッピングである。すなわち（ａ）同じ発信元からの情報は常に同じハッシュ値となり、（ｂ）ハッシュから発信元情報を推測することが難しい。１つの一般的なハッシュ法は、ＭＤ５メッセージダイジェストアルゴリズム（MD5；RFC 1321参照）である。
【０２５３】
ハッシュされたPI1 １００を受信すると、検証システム３０は、PI1 １００とPI2 １０２とを比較する前に、PI1 １００をハッシュした方法と同じ方法でPI2 １０２（又はPIディレクトリからのPI）をハッシュしなければならない。同じ情報は常に同じハッシュ値となるから、PI1 １００はPI2 １０２と識別できるままであることができ、ハッシュからオリジナルの情報を推測することが難しいから、情報の機密性は保たれる。
【０２５４】
２つの似た異なる情報はハッシュされると通常は似たままにならないので、部分比較、又は、比較的複雑なプロセスを必要とする比較はハッシュされたPIで行うことが出来ないことに注意しなければならない。PI1 １００の一部とPI2 １０２の一部だけ（例えば、電話番号の最後の数字のみ）がハッシュされた場合、或いは、PI1 １００とPI2 １０２がハッシュされる前に処理される（例えば、スペリングが異なるのを防ぐための決まった綴り方にする単語の書き直し）場合、このような比較が可能なままとなる。
【０２５５】
PISIDB５２が検証システム３０の外側にある場合、PISIDB５２からのPI2 １０２を検証システム５０に明らかにしないように要求することもできる。このような場合、PISIDBクエリー・モジュール５０への返答で情報を送信する前に、同じ方法でこの情報をハッシュすることができる。
PI1 １００がPISIDB５２の所有者に明らかにならないことが必要な場合（検証システム３０がハッシュされていないPI1 １００を受け取った場合）もある。この場合、検証システム３０は、PI1 １００をPISIDB５２のクエリーにおいて送信する前にハッシュし、PISIDB５２は、PI-SIのPIをPI1 １００と比較する前にハッシュする。
【０２５６】
発信元情報のセットが比較的小さい場合、ハッシュから発信元情報を検索することが可能なことに注目すべきである。例えば、北アメリカには電話番号の種類が１００億に満たないから、あり得る電話番号全てのハッシュを検討してハッシュからある電話番号を推定することができ得る。このような場合には、ハッシュサイズを小さくして、各ハッシュのあり得る発信元情報インスタンスを多くすることができる。（例えば、１００億の電話番号があり、ハッシュサイズが３桁の１０進数である場合、各ハッシュ値は平均して１００億の電話番号のある１つのハッシュとなることができる）。しかし、この方法は、２つの異なった情報インスタンスが異なる場合に同一とみなされる可能性が大きくなる。従って、情報の信頼性と間違った検証に対する受容レベルとの最も良いバランスが作れるように、ハッシュサイズを定めるべきである。
また、似たプロセスがSI1とSI2、又は他の情報要素に対して用いられることも注目すべきである。
【０２５７】
（複数のPIとの検証）
追加のPI（PI2 １０２以外の）との検証条件をチェックすることにより、PI1 １００を比較的良く検証することができる。通常、この検証には、追加のPIに関連した追加のSI（SI2以外の）とSI1との関連を見出すことが含まれている。
【０２５８】
例えば、PI1 １００と同じクレジットカード番号が、SI1と類似するIPアドレスから与えられる場合と、それが正しく課金された場合の２つの場合を見出したときには、そのような場合の一方のみを見出した場合と比較して、PI1の検証レベルが増加する。
追加のPIのそれぞれは、同じエンティティ或いは異なるエンティティに送られ、同じPISIDB５２或いは異なるPISIDB５２から取り出されてもよい。
【０２５９】
更には、検証システム３０が１以上のPISIDB５２へアクセスすることは、関連するPI-SIの記録を見出す確率を増加させ、それにより、検証システム３０が上手く使用される場合が増加する。
唯一のアクセス可能なPISIDB５２、各PISIDB５２内の記録の集合、或いはSI取得手段により入手可能なSIの集合が用いられることが、性能及び経済的観点から要求される。同様の観点から、選択された要素が特定順序で使用されることが要求される。
【０２６０】
いずれの集合を用いるかということ及びどのような順序で用いるかということは、OSP１４とPISIDB５２の所有者との間の関係（あるOSP１４の使用者が特定のPISIDB５２に登録されているらしいということの知識）や、どのSIが以前の同様の検証過程の間で有用であったかという知識や、他の好適な要素に基づいて、決定されればよい。
【０２６１】
例えば、もし検証システム３０がユーザ・デバイス１２からいくつかのクッキーを得ようとするならば、それらを平行して得ることは効率的ではない。なぜなら、それぞれのクッキーを得ることは、ユーザ・デバイス１２が異なる要求をインターネットに送り、各ユーザ・デバイス１２を稼動させ、それぞれ接続される必要を生ずるためである。したがって、肯定的な検証結果をより生ずるようなクッキーを最初に得ることは、より効率的である。
【０２６２】
どのSIを得るか決定するときには、PISIDB５２へのクエリーが用いられる。例えば、もし検証システム３０がいくつかのPISIDB５２にアクセスし（尚、ここにおいてSIがクッキーとなる）、異なるPISIDB５２のクッキーが異なるドメインに限定されているならば、PI1 １００と合致するPI2 １０２に対する各PISIDB５２への最初の問い合わせは有益なものとなる。そして、肯定的な応答をもたらすPISIDB５２の唯一のクッキーを得ることとなる。これにより、ユーザ・デバイス１２とのインタラクションは大幅に低減することとなる。
【０２６３】
検証報告６２は、検証過程において１以上のPIが用いられたことを示してもよい。例えば、各使用されたPIに対して別個の応答をもたらすことや、用いられたPI(SI)のリストを供給することによって、PI1 １００の検証レベルを表すスコアとして示してもよい。
【０２６４】
（他の方法との組み合わせ）
本発明が他の人物識別子検証方法を用いる場合には、そのような方法と組み合わせてもよい。例えば、本発明の方法の結果が、パターン認識、PI1 １００が真の確率を代表するスコアを発生させることに基づいた不正手段予測モデルの結果と組み合わされてもよい。そのような組み合わせは、ベイエスの理論のような条件付確率計算を用いて通常行われている。
【０２６５】
（多数のOSP）
上記のシステム及び方法は、単独のOSP１４を仮定したものである。しかしながら、多数のオンライン・サービス・プロバイダがそのようなサービスを用いると仮定する方が合理的である。このような場合における主だった差異は、検証システム３０が、検証報告６２が検証要求６０に合致する送信者に送信されたか確認するということである。当業者であれば、このような変更は容易に行うことが可能である。
【０２６６】
（拡張可能な環境）
本発明は、主としてインターネットに関連して述べられてきたが、当業者であれば、同じ送信者からの２つのメッセージが同じ送信者からのものであると決定できるあらゆる環境に、本発明を拡張することが可能である。
【０２６７】
（例）
上記において、本発明のいくつかの選択可能な操作が説明されてきた。これら様々な選択可能な操作の理解を助けるために、以下にいくつかの本発明の包括的な例を示す。
【０２６８】
（オンライン取引会社）
取引者Ａは、オンライン上の取引者である。彼は、HTTPSコネクションを介して、ユーザから製品の購入したい旨のオーダを受けている。このオーダは詳細な支払い情報を含み、クレジットカード番号及びカードに付された名前を備えている。
【０２６９】
取引者Ａは、２４ビットの支払い詳細情報に関するハッシュを作る。そして検証要求６０中にあるハッシュを検証システム３０の受信手段３２に送る。取引者Ａは、検証システム３０のSI取得手段４２を示すHTMLページに埋め込まれたイメージを、ユーザに供給する。PISIDBクエリー・モジュール５０はこのハッシュを含むクエリーを作り出し、それを取引者Ｂ、Ｃ及びＤに送る。取引者の各PISIDB５２は与えられたハッシュに合致する過去の購入から支払い詳細情報記録が含まれているか否かをチェックする。取引者Ｂ及びＣがPISIDBクエリー・モジュール５０に、そのような記録を保有していると応答する。SI取得手段４２は取引者Ｃのクッキーを得ることとし、取引者Ｃのドメイン下にある他のもう１つのSI取得手段４２のアドレスに対して、そのユーザをリダイレクトする。
ユーザのデバイスはSI取得手段４２に対して取引者Ｃのクッキーを送り、PISIDBクエリー・モジュール５０は、ハッシュ及び取引者Ｃに対するクッキーを含むクエリーを送る。
【０２７０】
取引者Ｃは、PISIDBクエリー・モジュール５０に対して、ハッシュとクッキーが合致する記録が存在し、該記録中のクレジットカード口座が１０年前に正しく課金されたということを応答する。
【０２７１】
検証推定手段３６は支払い詳細情報が真であるか決定するための法則に基づいた論理を用い、報告手段３４は取引者Ａに肯定的応答を含む検証報告６２を送る。
取引者Ａはユーザに製品を供給することを決定する。
この例において、以下の項目が実行された。
OSP１４がオンライン取引者である。
PI1 １００は取引者Ａに与えられたクレジットカード番号及び該カードに付された名前である。
PI2 １０２は取引者Ｃに与えられたクレジットカード番号及び該カードに付された名前である。
PISIDB５２は取引者Ｃの取引データベースである。
PI2VIは、後のPI2 １０２の受領が行われた結果及び時期である。
SPRはPI1 １００とPI2 １０２が同一であることに基づいたものである。
SSRは以下の事項に基づいたものである。（ａ）PI1 １００がHTTPS要求内に含まれていること、（ｂ）シークレットURLがHTTP要求の送信者に送られたこと、（ｃ）シークレット・クッキーがシークレットURLを伴って受け取られたこと、（ｄ）同じシークレット・クッキーが取引者Ｃによって、PI2 １０２を供給したユーザに割り当てられたこと
【０２７２】
PTCは取引者ＣがPI2 １０２のクレジットカード口座に課金し、１０ヶ月の間何ら支障がなかったことに基づいたものである。
ハッシュは、そのような情報を有さないエンティティに対して、PI1 １００の漏洩を防ぐために用いられた。
PI1 １００のハッシュは、どのクッキーを得るか決定するために、いくつかのPISIDB５２の所有者に対して送られた。
法則に基づいた論理は、肯定的或いは否定的検証報告６２を提供するか否かを決定するために用いられた。
【０２７３】
（不正取引メッセージサービス）
あるオンライン取引者がHTTPSコネクションを介して、ユーザから製品購入のオーダを受けたものとする。このオーダは、支払い詳細情報を含み、クレジットカード番号及び請求書アドレス（このアドレスはそのカードのカード発行者に登録されているものである）を含んでいる。取引者は、検証要求６０内の支払い詳細情報及びユーザのIP（HTTPSコネクションからの）を不正予測サービス（FPS）に送る。
【０２７４】
FPSは、請求書アドレスがカードと一致するか否か、そのアドレスが不正取引事故が生じたものであるか否かなどの詳細な検討によって取引が不正なものであるかどうか予測する。FPSは検証システム３０を操作し、検証システム３０を用いて、他の方法が高い危険性を伴う取引と判断する取引であるか検証する。FPSはこの取引が高い危険性を伴うと判断すると、検証要求６０を検証システム３０の受信手段３２に転送する。
【０２７５】
検証システム３０は、PISIDBクエリー・モジュール５０を介してクエリーを、IPアドレスを含むIMSに送る。IMSは、IMSが最近そのIP（唯一の識別子を送るもの）にログインされたことを見出す。IMSは、どのような名前で、いつそのユーザ（その唯一の識別子を割り当てられたユーザ）がそのIMSに登録されたかをチェックし、その名前及びその名前がもたらされた時期をPISIDBクエリー・モジュール５０に応答する。
【０２７６】
PI ディレクトリ・クエリー・モジュール５４は、以下の項目をAVSサービスを用いてチェックする。（ａ）その名前を有する人物が特定された請求書アドレスに住んでいるかどうか、（ｂ）請求書アドレスがクレジットカード番号と合致するかどうか。
検証推定手段３６は、その名前の多さ、その請求書アドレスに住んでいる人口数、その名前がそのIMSに提供された時期、その取引が不正なものであることの確率に対するそのFPSの予備的推定に関する情報をネットワークに供給する。
【０２７７】
ニューラル・ネットワークは、後に続く段階で受け取る情報に基づいて、その取引が不正なものである（そのクレジットカード番号がその番号を供給されたユーザに属するものではない）という確率の最新の推定を示す０と１との間の少数を提供する。
報告手段３４は少数を含む検証報告６２を取引者に送る。取引者は、その危険性が許容できるものと判断し、ユーザに製品を提供する。
この例において、以下の項目が実行される。
OSP１４はオンライン取引者である。
PI1 １００は取引者に提供されたクレジット番号である。請求書アドレスは、ホワイト・ページ・ディレクトリ及びAVSの使用を助けるものである。
PI2 １０２はIMSへの登録に用いられたフルネームである。
PISIDB５２は、登録されたユーザのIMSデータベースであり、IMSデータベースは、登録者の名前に関連付けられたIMCの唯一の識別子と連動している。
PI2VIはPI2 １０２を受け取ったときを表す受領日時である。
SPRは２つのPIディレクトリに基づくものである。請求書アドレス（ホワイト・ページ）と名前を関連付けるとともに、請求書アドレスとクレジットカード番号（AVSを介してアクセス可能なクレジットカード発行者の請求書アドレスディレクトリ）と関連付ける。
【０２７８】
SSRは以下の事項に基づく。（ａ）PI1 １００はHTTPS要求に含まれている。（ｂ）HTTPSセッションからのIPアドレスはIMCからIMSへ送られたログイン・メッセージからのIPアドレスと一致する。（ｃ）唯一の識別子を含んだログイン・メッセージである。（ｄ）その唯一の識別子がPI2 １０２が提供されたユーザに割り当てられている。
PTCはPI2 １０２がPI1 １００より十分以前に受け取られていることに基づく。
ニューラル・ネットワークはデータを解析し、PI1 １００が真である確率を推定するために用いられる。
ニューラル・ネットワークは、検証システム３０の結果とFPSの予備的結果を組合わせる。
【０２７９】
この例は、上記不正伝達サービスに似ているが、IMSが匿名サービスである点が異なる。ユーザが匿名サービスに登録したときのいかなるPIも提供されない。
しかしながら、IMCは接続時の唯一のシークレット識別子を報告する。
この場合において、FPSは取引が行われたときのカード番号及びIPアドレスを含む正しく終えた全ての過去の取引のPISIDB５２を維持する。
【０２８０】
このIMS記録は、過去の例としてのPISIDB５２として用いられず、同じユーザに属する異なる時期における２つの異なるIPアドレスを関連付けるものとして用いられる。特に、現行取引に対して報告されたIPアドレス（IPA）にログインされたIMCが、他のもう１つのIPアドレス（IPB）に以前ログインされたということを見出す。
PISIDBクエリー・モジュール５０は、IPBに関連したカード番号をPISIDB５２から取り出し、検証推定手段３６は取引者によって報告されたカード番号と取り出されたカード番号とを比較する。
【０２８１】
もしそれらが合致するならば、報告手段３４は肯定的応答を含む検証報告６２を取引者に送り、取引者はユーザに製品を提供することを決定する。
この例において、以下の項目が実行された。
OSP１４はオンライン取引者である。
PI1 １００はカード番号である。
PI2 １０２はカード番号である。
PISIDB５２は過去の取引及びその取引に関連するIPアドレスに対するFPSデータベースである。
PI2VIは、PISIDB５２が正しく終わった取引のみを含むので、詳細としては送られない。
SPRはPI1 １００とPI2 １０２が一致していることに基づいている。
SSRは以下のことに基づいている。（ａ）PI1 １００はHTTPS要求内に含まれている。（ｂ）HTTPSセッションからのIPアドレスは、IMCからIMSへ送られたログイン・メッセージからのIPアドレスと一致している。（ｃ）IMCログイン・メッセージ内で報告された唯一のシークレット識別子が過去のログイン・メッセージ内で報告された識別子と一致している。（ｄ）過去のログイン・メッセージからのIPアドレスは、PI2 １０２を含む過去の取引のIPアドレスと一致している。
PTCはPI2 １０２に基づいた正しい取引に基づいている。
法則に基づいた論理は、肯定的或いは否定的検証報告６２を送るかどうか決定するために用いられる。
【０２８２】
（ウェブ・ベースド・Eメール・サービス）
多くのユーザが自身のEメール・アカウントに頻繁にアクセスするので、WBESサイト（Web-based Email service）は頻繁に訪れられるウェブサイトであり、そのウェブサイトは多くのユーザの現在のIPアドレスを知るものとなる。更に、そのウェブサイトは、入ってくるEメールを解析することによって、ユーザ及び他のユーザの現在及び過去のIPアドレスに関する情報を得ることが可能である。いずれの場合においても、上記のように、登録やEメール送受信において提供されるので、該ウェブサイトはユーザのフルネームを備えるものとなる。
【０２８３】
WBESは検証システム３０の使用によって、PISIDB５２を作り出すために、この情報を用いることができる。多くの場合、WBESを所有する会社は、他の目的に対する多くのオンライン取引者との関係（例えば、マイクロソフトによるパスポートサービス或いはヤフーによるヤフーショッピング）を有しており、これらはこの目的のために拡張可能である。
【０２８４】
この例において、オンライン取引者はHTTPSコネクションを介して、製品購入のオーダを受ける。このオーダは品物を送るためのショッピング詳細情報を含んでいる。ショッピング詳細情報は氏名と住所を含んでいる。取引者は、検証要求６０内のショッピング詳細情報とユーザのIP（HTTPコネクションからの）をWBESによって動作される検証システム３０の受信手段３２に送られる。
【０２８５】
PISIDBクエリー・モジュール５０は、その名前を備えるユーザがそのWBESにログインしたかどうか及びその名前を備えるユーザからのEメールが受け取られたかどうかをチェックする。購入オーダ前１８ヶ月にその名前からのEメール記録が、そのユーザからそのオンライン取引者に送られたかを見出す。
【０２８６】
検証推定手段３６は、EメールからのIPアドレス及び検証要求６０内のIPアドレスが同一であることを見出す。そのPIディレクトリクエリーモジュール５４は、その名前を備える人物が特定されたショッピングアドレスに住んでいることを、ホワイト・ページ・ディレクトリをチェックすることによって見出す。そのEメールが購入オーダより十分以前に送られたものであるので、ショッピングアドレスはその品物を要求しているユーザの本当の住所であることを見出す。通常、このことはその取引が正当なものであることを示すものである（多くの不正取引者は盗品をその本当の住所に送付したりしないためである）。
【０２８７】
報告手段３４は肯定的応答を含む検証報告６２を取引者に送り、取引者はユーザに品物をユーザに提供することを決定する。
この例において、以下の項目が実行された。
OSP１４はオンライン取引者である。
PI1 １００はショッピングアドレスである。ショッピングアドレスに在住する全ての氏名をクエリーする代わりに、フルネームはPISIDB５２に対するクエリーの数に制限して提供される。
PI2 １０２はフルネームである。
PISIDB５２は、過去のログイン及びEメールのやり取りのWBESデータベースであり、名前とIPアドレスを関連付ける。
PI2VIはEメールが受け取られた時期である。
SPRはホワイト・ページ・ディレクトリに基づいている。
SSRは以下の項目に基づく。（ａ）PI1 １００はHTTPS要求内に含まれる。（ｂ）HTTPSセッションからのIPアドレスはEメールメッセージからのIPアドレスと一致している。（ｃ）PI2 １０２はEメールメッセージ内に含まれる。
PTCは、PI1 １００の１８ヶ月以前に受け取られたPI2 １０２に基づく。
法則に基づいた論理は肯定的或いは否定的検証報告６２を供給するか否かを決定するために用いられる。
【０２８８】
（シングル サイン−オン サービス）
シングル サイン−オン サービス（SSO）は、１つのユーザネームとパスワードとを用いて、ユーザがログインすること或いはユーザが、ユーザ自身が多数のオンライン・サービスに対して真性を証明することを可能とするものである。SSOサービスは１つのPISIDB５２を維持する。PISIDB５２内において、各記録は、SIとしてユーザネーム及びパスワードを含む。また各記録は、サービスに対する登録の間に付与されたユーザのPI（フルネーム、住所、電話番号及びクレジットカード詳細情報）を含む。いくつかの場合において、ユーザネームはPIとして用いられてもよい（例えば、もしユーザネームが、「john＿doe」といったユーザの名前に由来するような場合）。
【０２８９】
SSOの例は、Microsoft. Net Passport (www.passport.com) AOLScreenName (my.screenname.aol.com)やLiberty Alliance (www.projectlibｓerty.org)を含む。
この例において、オンライン取引者は、HTTPSコネクションを介して、ユーザから製品購入オーダを受け取る。このオーダは支払い詳細情報を含み、支払い詳細情報は、クレジットカード番号を備える。
【０２９０】
取引者は、シークレットURLを用いて、ユーザをユーザ識別のためのSSOへリダイレクトする。SSOは検証システム３０のSI取得手段４２を用いて、ユーザネームとパスワードを収集する。もしユーザが正しく認証されるならば、PISIDBクエリー・モジュール５０はユーザネームに関連するフルネーム、パスワード及びフルネームが該SSOに提供された時期の記録を得る。フルネーム、時期記録及びシークレットURLからの秘密情報は取引者に送られる。
【０２９１】
取引者は検証要求６０内のクレジットカード番号、フルネーム及び時期記録を検証システム３０の受信手段３２に送る。
検証推定手段３６はPIディレクトリクエリーモジュール５４を用い、フルネームがクレジットカード発行者のデータベースにあるクレジットカード番号に関連するカード所有者の名前と合致するか否かチェックする。また、時期記録を用いて、そのフルネームが購入オーダより十分以前に提供されたか否かをチェックする。
【０２９２】
両条件が満足された場合には、報告手段３４は肯定的応答を含む検証報告６２を取引者に送る。そして、取引者はユーザに製品を送ることを決定する。
この例において、以下の項目が実行された。
OSP１４はオンライン取引者である。
PI1 １００はクレジットカード番号である。
PI2 １０２はフルネームである。
PISIDB５２は登録されたユーザのSSOデータベースであり、ユーザネーム及びパスワードをユーザのPIと関連付ける。
PI2VIはフルネームがSSOに提供された時期である。
SPRはクレジットカード発行者のデータベースに基づく。
SSRは、以下の事項に基づく。（ａ）PI1 １００はHTTPS要求に含まれる。（ｂ）シークレットURLはHTTPS要求の送信者に送られる。（ｃ）ユーザネーム及びパスワードは同じシークレットURLを伴って受け取られる。（ｄ）PI2 １０２は同じユーザネーム及びパスワードを伴って受け取られる。
PTCはPI1 １００より十分に以前に受け取られたPI2 １０２に基づく。
法則に基づいた論理は、肯定的或いは否定的な検証報告６２を送るか否かを決定するために用いられる。
【０２９３】
企業のEメールシステムは、ユーザネーム及びパスワードを用いて、ユーザがそのユーザのメールボックスにアクセスすることを可能とする。そのシステムは１つのPISIDB５２を維持し、各記録は１つのSIとして、ユーザネーム及びパスワードを含む。ユーザネームに企業のドメインネームを合体させ、ユーザのEメールアドレスを作り出すこと（例えば、「john＿doe@acme.com」がAcme Inc.に勤務するJohn Doeを意味する）によって、ユーザネームは１つのPIとして機能する。
【０２９４】
この例において、HTTPSコネクションを介して、ユーザから製品購入オーダを受ける。このオーダは支払い詳細情報を含み、支払い詳細情報は、クレジットカード番号、カード所有者の名前及びEメールアドレスを含む。
取引者は支払い詳細情報を提供するユーザに安全なシークレット・クッキーを割り当てる。取引者は、ユーザによって提供されたEメールアドレスへシークレットURSを伴ったHTTPSリンクを含むEメールを送る。Eメールにアクセスするために、ユーザはユーザネームとパスワードを企業のEメールシステムに提供する。リンクをクリックすることによって、ユーザは安全なシークレット・クッキーを伴ってシークレットURLを取引者へ送る。このことは、支払い詳細情報を提供したユーザが、ユーザが提供したEメールアドレスにアクセスしたことを証明する。
【０２９５】
取引者は、クレジットカード番号、カード所有者の名前、Eメールアドレス及びシークレットURLが安全なシークレット・クッキーを伴って受け取られたことを示すフラッグを含む検証要求６０を検証システム３０の受信手段３２に送る。
検証推定手段３６は、Eメールアドレスがカード所有者の名前に似ていることを見出す（その代わりとして、PIディレクトリクエリーモジュール５４が、Eメールディレクトリ内にあるカード所有者の名前に関連したEメールアドレスを見つけてもよい）。検証推定手段３６は、そのEメールアドレスが信頼できる企業のものであるか否か決定する（例えば、Eメールドメイン、ビジネスデータベースクエリー或いはオフラインで接触することなどに関係する「フーイズ」情報をチェックするなど）。企業のEメールアドレスであるので、そのEメールアドレスがそのユーザの信頼できる認可されたエージェント（例えば、Eメールサーバシステムのアドミニストレイタ）によって作られたことが推測される。それゆえ、そのEメールアドレスが、ユーザの本当の名前の信頼できる指標であることが推測される。PIディレクトリクエリーモジュールは、クレジットカード発行者のデータベースクエリーにより、カード所有者の名前とクレジットカードの名前が一致していることを見出す。
【０２９６】
報告手段３４は肯定的応答を含む検証レポート６２を取引者に送る。取引者は製品をユーザに提供することを決定する。
この例において、以下の項目が実行された。
OSP14は、オンライン取引者である。
PI1 １００はクレジットカード番号である。カード所有者の名前が提供され、例えEメールアドレスからユーザの名前が明らかにならない場合であっても（例えば、「jdoe@mail.com」がJohn Doe, Jane Doe, Jeff Doeなどのいずれであってもよい）、検証推定手段３６がSPCをチェックすることが可能となる。Eメールアドレスが提供され、取引者がユーザにEメールを送ることが可能となる。これによって検証プロセスが可能となる。
PI2 １０２は企業のEメールサーバにあるユーザに割り当てられたEメールアドレスである。
PISIDB５２は、企業のEメールサーバのユーザネーム−パスワードのデータベースである。
PI2VIは、Eメールアドレスのドメインであり、Eメールサーバが信頼できる企業のものであることを示す。
SPRはEメールアドレスがカード所有者の名前に似ていること（或いはEメールディレクトリに関連していること）及びカード所有者の名前がクレジットカード発行者のデータベース内のクレジットカード番号に一致することに基づく。
SSRは、以下の事項に基づく。（ａ）PI1 １００はHTTPS要求内に含まれている。（ｂ）安全なシークレット・クッキーがHTTPS要求の送信者に送られる。（ｃ）ユーザネーム及びパスワードがEメールサーバに受け取られる。（ｄ）シークレットURLがEメールサーバからユーザネーム及びパスワードの送信者に送られる。（ｅ）安全なシークレット・クッキー及びシークレットURLが同じHTTPS要求内で受け取られる。（ｆ）Eメールサーバシステムのアドミニストレイタがユーザを登録したときと同じユーザネーム及びパスワードを伴って、PI2 １０２が受け取られる。
PTCはPI2 １０２がユーザの信頼できる認可されたエージェントから受け取られた。
法則に基づく論理は、肯定的或いは否定的な検証報告６２を送るか否かを決定するために用いられる。
【０２９７】
（公衆のEメール検証）
この例において、上述の企業Eメール検証方法と同じ方法が用いられるが、Eメールサーバが公衆のもの（例えば、WBES）であり、それ故、PI2 １０２（選択されたEメールアドレス）が信頼できる認可されたエージェントから提供されないという点が異なる。代わりに、PTCが、PI2 １０２がEメールサーバに提供された時期を表すデータベースにアクセスすることによってチェックされる。そのようなデータベースは、Eメールサーバの操作者によって提供され、過去のある時期においてそのEメールアドレスが送受信可能であったことの指標によって作られる（廃止されたEメールアドレスが再利用されておらず、他のユーザに割り当てられていないことを仮定して）。そのような指標は、Eメールアドレスに送られたEメールメッセージ或いはEメールアドレスが直接市場取引データベースに含まれていることが見出されているEメールメッセージを含む。
【０２９８】
この例において、以下の項目が実行された。
OSP14はオンライン取引者である。
PI1 １００はクレジットカード番号である。カード所有者の名前が提供され、検証推定手段３６が、たとえEメールアドレスからユーザネームが明らかにならない場合であっても、SPCをチェックすることを可能にする。１つのEメールアドレスが提供され、取引者がユーザにEメールを送ることを可能にする。これにより、検証プロセスが可能となる。
PI2 １０２は公衆のEメールサーバのユーザによって選択されたEメールアドレスである。
PISIDB５２は公衆のEメールサーバのユーザネーム−パスワードデータベースである。
PI2VIは、Eメールアカウントがその購入オーダより十分以前に作られたものであることを示す指標である。
SPRは、カード所有者の名前に似ている（或いはEメールディレクトリ内のカード所有者の名前に関連している）Eメールアドレスであること及びカード所有者の名前がクレジットカード発行者のデータベースのクレジットカード番号に合致することに基づく。
SSRは以下の項目に基づく。（ａ）PI1 １００はHTTPS要求に含まれる。（ｂ）安全なシークレット・クッキーはHTTPS要求の送信者に送られる。（c）ユーザネームとパスワードがEメールサーバによって受け取られる。（ｄ）シークレットURLがEメールサーバからユーザネームとパスワードの送信者へ送られる。（ｅ）安全なシークレット・クッキー及びシークレットURSが同じHTTPS要求内で受け取られる。（ｆ）PI2 １０２はユーザが公衆のEメールサーバに登録されたときと同じユーザネーム及びパスワードとともに受け取られる。
PTCはPI1 １００の十分以前に受け取られたPI2 １０２に基づく。
法則に基づく論理は、肯定的或いは否定的な検証報告を提供するか否かを決定するために用いられる。
【０２９９】
（発行者側の認証）
クレジットカード発行者は、しばしばオンライン・クレジットカード取引における購入者の真性を証明するために最適な集合体であると見られる。クレジットカード組織（例えばVisa及びMasterCardからのセット（SET）、及び上記のVisaからの３Ｄセキュア（3D secure））によって提案される支払計画において、発行者はユーザのオンラインでの真性証明に責任を持つことになる。
【０３００】
本発明は、そのような支払計画における証明方法として用いられることができる。例えば、発行者のオンライン・ビル・プレゼントメント・システム（OBPS;発行者の顧客が、顧客のオンライン口座状態を見ることができるシステム）を利用することによって可能となる。ユーザがOBPSを訪れると、ユーザが身元証明（即ち、ユーザのクレジットカード番号、有効期限及び月々の状況を示すコード）を要求する。もし認証が成功し、安全なシークレット・クッキーがユーザに発行され、PISIDB５２内のユーザの口座識別子（即ち、クレジットカード番号）に関連付けられる。
【０３０１】
３Ｄセキュアの場合において、オンライン取引者は、HTTPSコネクションを介して、ユーザから製品購入オーダを受ける。このオーダはクレジットカード番号を含む。オンライン取引者は、ポップアップ・ウインドウを開くことによって、ユーザがHTTPS要求を検証システム３０のSI取得手段４２に送らせる（検証システム３０は、発行者の３Ｄセキュアサーバに統合され、そのドメインを用いている）。取引者は、検証要求６０内のクレジットカード番号を検証システム３０の受信手段３２に送る。検証要求６０及びHTTPS要求はともに同じ秘密情報を含み、検証システム３０が上述の如く、これらを関連付けることを可能にする。
【０３０２】
ユーザがHTTPS要求を発行者のドメインへ、安全なコネクションを介して送るので、発行者のOBPSによって発行された安全なシークレット・クッキーが明かされる（もし、３Dセキュアサーバによって用いられるドメインがOBPSのドメインと異なるならば、ユーザのデバイスはOBPSドメインに接続される）。クッキー内の識別子はPISIDBクエリー・モジュール５０によって、PISIDB５２から関連するクレジットカード番号を得るためのキーとして用いられる。検証推定手段３６は、検証要求６０内で報告されたクレジットカード番号と、得られたクレジットカード番号を比較する。
もし合致するならば、報告手段３４は肯定的応答を含む検証報告６２を取引者に送り、取引者はユーザに製品を提供することを決定する。
この例において、以下の項目が実行される。
OSP１４はオンライン取引者である。
PI1 １００は取引者に提供されたクレジットカード番号である。
PI2 １０２はOBPSへの登録において提供されたクレジットカード番号である。
PISIDB５２は、発行者のOBPSデータベースであり、該データベースはユーザのクレジットカード番号を伴うクッキーと関連している。
PISIDB５２は唯一の検証された記録を含むので、明確には送られない。
SPRはPI1 １００とPI2 １０２とが一致していることに基づく。
SSRは以下の事項に基づく。（ａ）PI1 １００は取引者へのHTTPS要求に含まれている。（ｂ）シークレットURLはHTTPS要求の送信者に送られる。（ｃ）安全なシークレット・クッキーはシークレット・クッキーとともに送られる。（ｄ）ユーザがPI2 １０２を提供されたとき、同じシークレット・クッキーが、OBPSによって割り当てられる。
PTCはユーザがOBPSに登録されたときに行われた認証プロセスに基づく（例えば、月々の状態からコードを提供するなど）。
法則に基づいた論理は、肯定的或いは否定的検証報告を提供するか否かを決定するために用いられる。
【図面の簡単な説明】
【０３０３】
【図１】システムが作動する環境について示す。
【図２】人物識別子の検証を可能にするエンティティと情報要素の関係について示す。
【図３】本発明の好適な実施例に基づくシステムの構成要素について示す。
【図４】本発明の好適な実施例に基づく典型的な検証プロセスを示す。

Claims (32)

  1. 第１人物識別子を検証する方法であって、
    ａ．第１人物識別子を含む検証要求を受信し、
    ｂ．ｉ 第１人物識別子及び第２人物識別子が同一人物条件を満たし、
    ｉｉ 第１人物識別子の送信者及び前記第２人物識別子の送信者が同一送信者条件を満たし、
    ｉｉｉ 前記第２人物識別子が該第２人物識別子の前記送信者を識別する、
    ことを含む検証条件が真であるか否かを推定する方法。
  2. 前記第１人物識別子が第１人物識別子の前記送信者を識別するか否かを示唆する検証報告を送信する段階を更に有し、
    前記検証報告が前記推定の結果に基づいて作成されていることを特徴とする請求項１記載の方法。
  3. 前記検証要求が、
    ａ．前記第２人物識別子、
    ｂ．前記第１人物識別子に関する第１送信者指示子、
    ｃ．前記第２人物識別子に関する第２送信者指示子、
    ｄ．前記第２人物識別子のための検証情報、
    からなる群より選択される少なくとも１つの情報要素を更に含んでいることを特徴とする請求項１記載の方法。
  4. 前記推定が更に、
    ａ．少なくとも１つのクエリーを、少なくとも１つの人物識別子−送信者指示子データベースへ送信し、
    ｂ．少なくとも１つのクエリーに対する少なくとも１つの応答を受信することを含む、
    ことを特徴とする請求項１記載の方法。
  5. 前記少なくとも１つのクエリーの少なくとも１つが、少なくとも１つの前記検証条件として記載される条件を有するクエリーであることを特徴とする請求項４記載の方法。
  6. 前記推定が更に、前記少なくとも１つのクエリーに対する少なくとも１つの応答が、前記少なくとも１つのクエリーに記載された前記少なくとも１つの検証条件以外の少なくとも１つの検証条件を満たすことを特徴とする請求項５記載の方法。
  7. 第１人物識別子及び第２人物識別子が、
    ａ．前記２つの人物識別子が識別部を含む、
    ｂ．前記２つの人物識別子がスペルによる相違以外の識別部を含む、
    ｃ．前記２つの人物識別子の一方が、前記２つの人物識別子の他方の省略形を含む、
    ｄ．前記２つの人物識別子が番号が近似する電話番号である、
    ｅ．前記２つの人物識別子が地理的に近似するパラメータを含む、
    ｆ．ディレクトリ記録が、前記２つの人物識別子の一方の同一人物関係を有する人物識別子と、前記２つの人物識別子の他方の同一人物関係を有する他の人物識別子を関連している、
    ｇ．前記２つの人物識別子の各々が、第３人物識別子の同一人物関係を夫々有している、
    ことからなる群から選択される２つの人物識別子の間における少なくとも１つの関係を含む同一人物関係を有する場合に、前記同一人物条件が満たされることを特徴とする請求項１記載の方法。
  8. 前記第１人物識別子を包含するメッセージ及び前記第２人物識別子を包含するメッセージが、前記第１メッセージ及び第２メッセージの間において、
    ａ．共通の不可欠メッセージに於ける前記第１メッセージ及び前記第２メッセージの構成員、
    ｂ．前記第１メッセージが送信された時刻及び前記第２メッセージが送信された時刻の間における関係、
    ｃ．前記第１メッセージの送信者の信頼できるネットワーク・アドレス及び前記第２メッセージの送信者の信頼できるネットワーク・アドレスの間における関係、
    ｄ．前記第１メッセージに含まれる第１シークレットと前記第２メッセージに含まれる第２シークレットが共通のシークレットから派生したものである、
    ｅ．前記第１メッセージの送信者へ送信された第１シークレット及び前記第２メッセージに包含される第２シークレットが共通のシークレットから派生したものである、
    ｆ．各前記メッセージが、夫々第３メッセージの同一送信者関係を有している、
    ことからなる群から選択される少なくとも１つの関係を含む同一送信者関係を有している場合に、前記同一送信者条件が満たされることを特徴とする請求項１記載の方法。
  9. 前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスの間における前記関係が、
    ａ．前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスの識別である、
    ｂ．前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスの共通するサブ−ネットワークにおける構成員である、
    ｃ．共通の組織による、前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスを使用する、
    ｄ．２つの関連する組織による、前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスを使用する、
    ｅ．共通のインターネット・サービス・プロバイダによる、前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスを使用する、
    ｆ．現存する共通のインターネット・サービス・プロバイダ・ポイントによる、前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスを使用する、
    ｇ．前記第１メッセージの前記送信者の前記信頼できるネットワーク・アドレス及び前記第２メッセージの前記送信者の前記信頼できるネットワーク・アドレスの近似の地理的な位置に関連する、
    ことからなる群から選択される少なくとも１つの関係を含んでいることを特徴とする請求項８に記載の方法。
  10. 少なくとも１つの前記信頼できるネットワーク・アドレスが、IPアドレス、UDPポート番号を伴うIPアドレス、TCPセッション・ハンドル及び物理的インターフェース識別子からなる群から選択される信頼できるネットワーク・アドレスであることを特徴とする請求項８記載の方法。
  11. 少なくとも１つの前記第１及び第２シークレットが、装置により維持されるシークレット、シークレットHTTPクッキー、シークレットHTTPセキュア・クッキー、SMTPヘッダ、HTTPヘッダ、ハードウエア識別子、前記装置にインストールされるソフトウェア要素において維持されるシークレット、オンライン使用のための人物を割り当てるシークレット、ユーザネームとパスワード、シークレットURL、ネットワーク・アドレス、IPアドレス、UDPポート番号及び、TCPセッション・ハンドルからなる群から選択されるシークレットであることを特徴とする請求項８記載の方法。
  12. 少なくとも１つの人物識別子条件が真であり、前記第２人物識別子条件が、
    ａ．前記第２人物識別子が、人物識別子の検証のために標準の方法を使用することを検証された、
    ｂ．前記第２人物識別子が、前記第２人物識別子を基にする正しいオフライン・アクションを実行することによって検証された、
    ｃ．前記第２人物識別子が、正しく口座に課金されることによって検証された、
    ｄ．前記第２人物識別子が、メーリング・アドレスへ送信されるオンライン・コードを受信することによって検証された、
    ｅ．前記第２人物識別子が、電話呼び出しへ送るオンライン・コードを受信することによって検証された、
    ｆ．前記第２人物識別子が、電話呼び出しの間に、オンラインへ送信されたコードを受信することによって、検証された
    ｇ．前記第２人物識別子が不正行為の特殊なタイプの条件において受信された、
    ｈ．前記第２人物識別子が、第１人物識別子が送信される一定期間以前に送信された、
    ｉ．前記第２人物識別子が、第１人物識別子が送信された一定期間後に送信された、
    ｊ．前記第２人物識別子が、不正行為者が不正行為を行う気持ちを無くさせるサービスへ送られた、
    ｋ．前記第２人物識別子が、合法的なユーザの典型的且つ有効なオンライン行為と関連する、
    ｌ．前記第２人物識別子が、前記第２人物識別子の前記送信者の信用に値する認可された代理人であった、
    ｍ．前記第２人物識別子が、本発明を使用することによって検証された、
    ことから選択される条件である場合に、前記第２人物識別子が前記第２人物識別子の前記送信者を識別しているとみなすことを特徴とする請求項１記載の方法。
  13. 前記推定が、
    ａ．法則に基づいた論理、
    ｂ．自動学習技術、
    ｃ．ニューラル・ネットワーク、
    ｄ．確率論的解析、
    からなる群から選択される少なくとも１つの推定方法を使用することに影響を受けることを特徴とする請求項１記載の方法。
  14. 前記検証報告は、
    ａ．肯定的な応答、
    ｂ．否定的な応答、
    ｃ．前記第２人物識別子、
    ｄ．前記第２人物識別子に関する送信者指示子、
    ｅ．前記第２人物識別子の検証情報、
    ｆ．前記第１人物識別子及び前記第２人物識別子が同一人物条件を満たす確率を記載するスコア、
    ｇ．前記第１人物識別子の前記送信者及び前記第２人物識別子の前記送信者が同一送信者条件を満たす確率を記載するスコア、
    ｈ．前記第２人物識別子が前記第２人物識別子の前記送信者を識別する確率を記載するスコアと、
    ｉ．前記第１人物識別子が前記第１人物識別子の前記送信者を識別する確率を記載するスコア、
    からなる群から選択される少なくとも１つの情報要素を含んでいることを特徴とする請求項２記載の方法。
  15. 前記第１人物識別子が該第１人物識別子の前記送信者を識別する前記確率が記載されるスコアが、
    ａ．前記第１人物識別子及び前記第２人物識別子が同一人物条件を満たす確率、
    ｂ．前記第１人物識別子の前記送信者及び前記第２人物識別子の前記送信者が同一人物条件を満たす確率、
    ｃ．前記第２人物識別子が前記第２人物識別子の前記送信者を識別する確率、
    ｄ．前記同一送信者条件の基本とされるシークレットとのアクセスを得る困難性、
    ｅ．前記第１人物識別子の前記送信者のアドレスにおける信頼性、
    ｆ．前記第２人物識別子の前記送信者のアドレスにおける信頼性、
    ｇ．推定の前記段階において使用される永久のデータ・ソースの正確度及び信頼性、
    ｈ．前記第１人物識別子の普及性、
    ｉ．前記第２人物識別子の普及性、
    ｊ．人々が人物識別子を変更する傾向、
    ｋ．第１人物識別子の送信及び第２人物識別子の送信の間における経過時間、
    ｌ．前記第２人物識別子により識別される口座を課金したときからの経過時間、
    からなる群から選択される少なくとも１つのパラメータに基づいていることを特徴とする請求項１４記載の方法。
  16. 前記推定が更に、
    ａ．少なくとも１つの人物識別子ディレクトリへ、少なくとも１つのクエリーを送信し、
    ｂ．前記少なくとも１つのクエリーに対する前記少なくとも１つの応答を受信することを含む、
    ことを特徴とする請求項１記載の方法。
  17. 更に、
    ａ．前記第１人物識別子、
    ｂ．前記第２人物識別子、
    ｃ．第１人物識別子に関する第１送信者指示子、
    ｄ．前記第２人物識別子に関する第２送信者指示子、
    からなる群から選択される少なくとも１つの情報要素の少なくとも一部における、少なくとも１つのハッシュを発生する段階を含むことを特徴とする請求項１記載の方法。
  18. 更に、
    ａ．機密情報、
    ｂ．偽検証の許容レベル、
    からなる群から選択される少なくとも１つの考慮事項に基づいて、少なくとも１つの前記ハッシュのサイズを決定する段階を有することを特徴とする請求項１７記載の方法。
  19. 前記第１人物識別子の前記送信者からの前記第１人物識別子を受信するエンティティが、前記第２人物識別子の前記送信者からの前記第２人物識別子を受信するエンティティと異なっていることを特徴とする請求項１記載の方法。
  20. 推定が行われる段階が、前記第２人物識別子以外の少なくとも１つの人物識別子を伴い繰り返されることを特徴とする請求項１記載の方法。
  21. 推定が行われる前記段階において前記第２人物識別子として使用するために、複数の人物識別子から１つの人物識別子を選択する段階を更に含むことを特徴とする請求項１記載の方法。
  22. 第１人物識別子の前記送信者から少なくとも１つの送信者指示子を取得する段階を更に含むことを特徴とする請求項１記載の方法。
  23. 前記推定の結果と人物識別子を検証する少なくとも他の方法の結果を結合する段階を更に含むことを特徴とする請求項１記載の方法。
  24. 前記第１人物識別子及び前記第２人物識別子からなる群から選択される少なくとも１つの人物識別子が、下記に構成される群から選択される少なくとも１つの情報要素を含むことを特徴とする請求項１記載の方法。
    フルネーム、ファーストネーム、ミドルネーム、ラストネーム、イニシャルネーム、肩書き、住所、国、州、市、ストリート・アドレス、部屋番号、郵便番号、電話番号、Ｅメール・アドレス、金融口座番号、クレジットカード番号、銀行口座番号、政府発行の識別子、社会保障番号、運転免許書番号、国家ID番号、パスポート番号、個人の特徴、身長、体重、性別、外観、人種及び頭髪の色。
  25. 第１人物識別子は、インターネット、プライベイト・データ・ネットワーク、CATVデータ・ネットワーク及びモバイル・データ・ネットワークからなる群から選択されるネットワークを介して送信されることを特徴とする請求項１記載の方法。
  26. 第１人物識別子を検証するシステムであって、
    ａ．第１人物識別子を含む検証要求を受信する受信手段と、
    ｂ．第１人物識別子及び第２人物識別子が同一人物識別子条件を満たすか否かを推定するため、前記第１人物識別子の送信者及び前記第２人物識別子の送信者が同一送信者条件を満たすか否かを推定するため及び前記第２人物識別子が前記第２人物識別子の前記送信者を識別するか否か推定するための検証推定手段、
    を有することを特徴とするシステム。
  27. 検証報告が前記検証推定手段の出力を基にして形成され、第１人物識別子が該第１人物識別子の前記送信者を識別するか否かを指示する検証報告を送信する報告手段を更に有することを特徴とする請求項２６記載のシステム。
  28. 人物識別子ディレクトリへクエリーを送信するとともに、前記検証推定手段により使用され且つ該クエリーに対する応答を受信する人物識別子ディレクトリ・クエリー・モジュールを更に含むことを特徴とする請求項２６記載のシステム。
  29. 少なくとも１つの人物識別子ディレクトリを含むことを特徴とする請求項２８記載のシステム。
  30. 少なくとも１つの人物識別子送信者指示子データベースへクエリーを送信するとともに、前記検証推定手段により使用され且つ前記クエリーに対する応答を受信する少なくとも１つの人物識別子送信者指示子データベース・クエリー・モジュールを更に有することを特徴とする請求項２６記載のシステム。
  31. 少なくとも１つの前記人物識別子送信者指示子データベースを含むことを特徴とする請求項３０記載のシステム。
  32. ａ．第１人物識別子、
    ｂ．前記第２人物識別子、
    ｃ．第１人物識別子に関する第１送信者指示子、
    ｄ．前記第２人物識別子に関する第２送信者指示子、
    からなる群から選択される少なくとも１つの情報要素の少なくとも一部を有する少なくとも１つのハッシュを発生させるハッシュ発生手段を含むことを特徴とする請求項２６記載のシステム。
JP2003537232A 2001-10-17 2002-10-16 オンラインで受信する人物識別子の検証 Pending JP2005507106A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US32951801P 2001-10-17 2001-10-17
US37454802P 2002-04-23 2002-04-23
PCT/US2002/032825 WO2003034633A2 (en) 2001-10-17 2002-10-16 Verification of a person identifier received online

Publications (2)

Publication Number Publication Date
JP2005507106A true JP2005507106A (ja) 2005-03-10
JP2005507106A5 JP2005507106A5 (ja) 2005-12-15

Family

ID=26986834

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003537232A Pending JP2005507106A (ja) 2001-10-17 2002-10-16 オンラインで受信する人物識別子の検証

Country Status (9)

Country Link
US (2) US8650103B2 (ja)
EP (1) EP1436746A4 (ja)
JP (1) JP2005507106A (ja)
CN (1) CN1666205A (ja)
AU (1) AU2002340207B2 (ja)
CA (1) CA2463891C (ja)
IL (2) IL161437A0 (ja)
NZ (1) NZ532258A (ja)
WO (1) WO2003034633A2 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014197424A (ja) * 2014-07-08 2014-10-16 ヤフー株式会社 広告配信装置、広告配信方法、端末推定装置、端末推定方法およびプログラム
JP2016119125A (ja) * 2016-03-16 2016-06-30 ヤフー株式会社 広告配信装置、広告配信方法、端末推定装置、端末推定方法およびプログラム
US10936532B2 (en) 2018-08-06 2021-03-02 Toshiba Memory Corporation Electronic device and data transmitting/receiving method
KR102440878B1 (ko) * 2021-12-09 2022-09-05 한국인터넷진흥원 가상 자산 부정 거래 탐지를 위한 탐지 모델의 학습 방법, 탐지 모델을 이용한 가상 자산 부정 거래의 탐지 방법 및 이들을 수행하는 장치 및 컴퓨터 프로그램
JP7565816B2 (ja) 2021-02-05 2024-10-11 東芝テック株式会社 サーバ装置及びプログラム

Families Citing this family (126)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8650103B2 (en) * 2001-10-17 2014-02-11 Ebay, Inc. Verification of a person identifier received online
KR100464755B1 (ko) * 2002-05-25 2005-01-06 주식회사 파수닷컴 이메일 주소와 하드웨어 정보를 이용한 사용자 인증방법
US20040243704A1 (en) * 2003-04-14 2004-12-02 Alfredo Botelho System and method for determining the unique web users and calculating the reach, frequency and effective reach of user web access
US7409710B1 (en) * 2003-10-14 2008-08-05 Sun Microsystems, Inc. Method and system for dynamically generating a web-based user interface
US7647375B1 (en) 2003-12-22 2010-01-12 Aol Llc Enabling mapping identification of online identities between different messaging services
US7734708B1 (en) 2003-12-22 2010-06-08 Aol Inc. Enabling identification of online identities between different messaging services
CN1965309B (zh) * 2004-01-09 2010-11-17 Npx科技有限公司 中继设备确定方法和系统
US7565356B1 (en) * 2004-04-30 2009-07-21 Sun Microsystems, Inc. Liberty discovery service enhancements
US8781975B2 (en) * 2004-05-21 2014-07-15 Emc Corporation System and method of fraud reduction
US7603700B2 (en) * 2004-08-31 2009-10-13 Aol Llc Authenticating a client using linked authentication credentials
US8484456B2 (en) * 2004-12-08 2013-07-09 Alien Camel Pty Ltd. Trusted electronic messaging system
US8718605B2 (en) * 2005-01-21 2014-05-06 Resource Consortium Limited Method and apparatus for providing information in response to the grant of a subscriber's permission
US7724728B2 (en) * 2005-04-19 2010-05-25 Cisco Technology, Inc. Policy-based processing of packets
US8302175B2 (en) * 2005-04-20 2012-10-30 Docaccount Ab Method and system for electronic reauthentication of a communication party
US20090235337A1 (en) * 2005-04-20 2009-09-17 Peter Holm Method and device for identification of a communication party
US7665658B2 (en) * 2005-06-07 2010-02-23 First Data Corporation Dynamic aggregation of payment transactions
WO2006133515A1 (en) * 2005-06-16 2006-12-21 Cerebrus Solutions Limited A method of confirming the identity of a person
US8726369B1 (en) * 2005-08-11 2014-05-13 Aaron T. Emigh Trusted path, authentication and data security
US20070055673A1 (en) * 2005-09-07 2007-03-08 Rieffanaugh Neal K Jr Verified personal credit search system and method thereof
WO2007061946A2 (en) 2005-11-18 2007-05-31 Lu Larry L Promoting interoperability of presence-based systems through the use of ubiquitous online identities
US9459622B2 (en) 2007-01-12 2016-10-04 Legalforce, Inc. Driverless vehicle commerce network and community
US20070156836A1 (en) * 2006-01-05 2007-07-05 Lenovo(Singapore) Pte. Ltd. System and method for electronic chat identity validation
US9037516B2 (en) 2006-03-17 2015-05-19 Fatdoor, Inc. Direct mailing in a geo-spatial environment
US9064288B2 (en) 2006-03-17 2015-06-23 Fatdoor, Inc. Government structures and neighborhood leads in a geo-spatial environment
US9002754B2 (en) 2006-03-17 2015-04-07 Fatdoor, Inc. Campaign in a geo-spatial environment
US8965409B2 (en) 2006-03-17 2015-02-24 Fatdoor, Inc. User-generated community publication in an online neighborhood social network
US9098545B2 (en) * 2007-07-10 2015-08-04 Raj Abhyanker Hot news neighborhood banter in a geo-spatial social network
US9373149B2 (en) 2006-03-17 2016-06-21 Fatdoor, Inc. Autonomous neighborhood vehicle commerce network and community
US9070101B2 (en) 2007-01-12 2015-06-30 Fatdoor, Inc. Peer-to-peer neighborhood delivery multi-copter and method
US8732091B1 (en) * 2006-03-17 2014-05-20 Raj Abhyanker Security in a geo-spatial environment
JP2007257086A (ja) * 2006-03-20 2007-10-04 Fujitsu Ltd 行動記録支援プログラム、システム、装置、および方法
EP2506184A1 (en) * 2006-03-29 2012-10-03 The Bank of Tokyo-Mitsubishi UFJ, Ltd. Apparatus, method, and program for validating user
ATE398884T1 (de) * 2006-04-04 2008-07-15 Mueller Marken Gmbh & Co Betr Automatische verifizierung von messenger- kontaktdaten
US7941370B2 (en) * 2006-04-25 2011-05-10 Uc Group Limited Systems and methods for funding payback requests for financial transactions
US20080040275A1 (en) * 2006-04-25 2008-02-14 Uc Group Limited Systems and methods for identifying potentially fraudulent financial transactions and compulsive spending behavior
US20080021999A1 (en) * 2006-07-18 2008-01-24 Aspect Software, Inc. Remote expert screen pop via data message
US20080033941A1 (en) * 2006-08-07 2008-02-07 Dale Parrish Verfied network identity with authenticated biographical information
US11075899B2 (en) * 2006-08-09 2021-07-27 Ravenwhite Security, Inc. Cloud authentication
US8844003B1 (en) 2006-08-09 2014-09-23 Ravenwhite Inc. Performing authentication
WO2008052310A1 (en) * 2006-10-04 2008-05-08 Pgmx Inc Method and system of securing accounts
US8863245B1 (en) 2006-10-19 2014-10-14 Fatdoor, Inc. Nextdoor neighborhood social network method, apparatus, and system
US8365258B2 (en) * 2006-11-16 2013-01-29 Phonefactor, Inc. Multi factor authentication
US9762576B2 (en) 2006-11-16 2017-09-12 Phonefactor, Inc. Enhanced multi factor authentication
US11257080B2 (en) 2007-05-04 2022-02-22 Michael Sasha John Fraud deterrence for secure transactions
US20080313019A1 (en) * 2007-06-14 2008-12-18 Jeffers Martin C System and method for extracting contact information from website traffic statistics
US20080320576A1 (en) * 2007-06-22 2008-12-25 Microsoft Corporation Unified online verification service
US8359355B2 (en) * 2007-10-16 2013-01-22 International Business Machines Corporation System and method for verifying access to content
JP4936549B2 (ja) * 2007-10-30 2012-05-23 キヤノン株式会社 サーバ装置、管理システム、管理方法、記憶媒体、プログラム
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US20100106611A1 (en) * 2008-10-24 2010-04-29 Uc Group Ltd. Financial transactions systems and methods
US8386573B2 (en) * 2008-12-31 2013-02-26 International Business Machines Corporation System and method for caching linked email data for offline use
US8589502B2 (en) * 2008-12-31 2013-11-19 International Business Machines Corporation System and method for allowing access to content
US8744956B1 (en) 2010-07-01 2014-06-03 Experian Information Solutions, Inc. Systems and methods for permission arbitrated transaction services
US8931058B2 (en) 2010-07-01 2015-01-06 Experian Information Solutions, Inc. Systems and methods for permission arbitrated transaction services
US8407341B2 (en) * 2010-07-09 2013-03-26 Bank Of America Corporation Monitoring communications
US9172693B2 (en) * 2010-11-11 2015-10-27 Paypal, Inc. Quick payment using mobile device binding
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US8839357B2 (en) * 2010-12-22 2014-09-16 Canon U.S.A., Inc. Method, system, and computer-readable storage medium for authenticating a computing device
KR101923611B1 (ko) * 2011-04-11 2018-11-29 삼성전자주식회사 서비스 서버, 사용자 단말 장치, 그 서비스 제공 방법 및 제어 방법
US20120310778A1 (en) 2011-06-03 2012-12-06 Uc Group Limited Systems and methods for clearing and settling transaction activity
US20120317172A1 (en) * 2011-06-13 2012-12-13 International Business Machines Corporation Mobile web app infrastructure
US9665854B1 (en) 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
US9159055B2 (en) 2011-09-07 2015-10-13 Elwha Llc Computational systems and methods for identifying a communications partner
US10523618B2 (en) * 2011-09-07 2019-12-31 Elwha Llc Computational systems and methods for identifying a communications partner
US9432190B2 (en) 2011-09-07 2016-08-30 Elwha Llc Computational systems and methods for double-encrypting data for subsequent anonymous storage
US10546306B2 (en) 2011-09-07 2020-01-28 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9473647B2 (en) 2011-09-07 2016-10-18 Elwha Llc Computational systems and methods for identifying a communications partner
US9747561B2 (en) 2011-09-07 2017-08-29 Elwha Llc Computational systems and methods for linking users of devices
US9690853B2 (en) 2011-09-07 2017-06-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9195848B2 (en) 2011-09-07 2015-11-24 Elwha, Llc Computational systems and methods for anonymized storage of double-encrypted data
US10198729B2 (en) 2011-09-07 2019-02-05 Elwha Llc Computational systems and methods for regulating information flow during interactions
US10074113B2 (en) 2011-09-07 2018-09-11 Elwha Llc Computational systems and methods for disambiguating search terms corresponding to network members
US10606989B2 (en) 2011-09-07 2020-03-31 Elwha Llc Computational systems and methods for verifying personal information during transactions
US9928485B2 (en) 2011-09-07 2018-03-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9491146B2 (en) 2011-09-07 2016-11-08 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
WO2013116726A1 (en) 2012-02-03 2013-08-08 Ebay Inc. Adding card to mobile wallet using nfc
WO2013142290A1 (en) * 2012-03-22 2013-09-26 Socialogue, Inc. Internet identity management
EP2856383A1 (en) * 2012-04-05 2015-04-08 Thakker, Mitesh L. Systems and methods to input or access data using remote submitting mechanism
US9430778B2 (en) * 2012-07-30 2016-08-30 Kount Inc. Authenticating users for accurate online audience measurement
US8856894B1 (en) 2012-11-28 2014-10-07 Consumerinfo.Com, Inc. Always on authentication
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US10164989B2 (en) * 2013-03-15 2018-12-25 Nominum, Inc. Distinguishing human-driven DNS queries from machine-to-machine DNS queries
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
FR3003976B1 (fr) * 2013-03-28 2016-08-26 Cie Ind Et Financiere D'ingenierie Ingenico Procede de delivrance d'une assertion de localisation
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US10277628B1 (en) * 2013-09-16 2019-04-30 ZapFraud, Inc. Detecting phishing attempts
US9817987B2 (en) 2013-12-23 2017-11-14 Dropbox, Inc. Restricting access to content
US9515833B2 (en) * 2014-01-06 2016-12-06 Lett.rs LLC Electronic personal signature generation and distribution for personal communication
US20150199742A1 (en) * 2014-01-10 2015-07-16 Raj Abhyanker Trade recommendations in a neighborhood environment with conflict resolution
US9439367B2 (en) 2014-02-07 2016-09-13 Arthi Abhyanker Network enabled gardening with a remotely controllable positioning extension
US9457901B2 (en) 2014-04-22 2016-10-04 Fatdoor, Inc. Quadcopter with a printable payload extension system and method
US9004396B1 (en) 2014-04-24 2015-04-14 Fatdoor, Inc. Skyteboard quadcopter and method
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US9022324B1 (en) 2014-05-05 2015-05-05 Fatdoor, Inc. Coordination of aerial vehicles through a central server
US9441981B2 (en) 2014-06-20 2016-09-13 Fatdoor, Inc. Variable bus stops across a bus route in a regional transportation network
US9971985B2 (en) 2014-06-20 2018-05-15 Raj Abhyanker Train based community
US9451020B2 (en) 2014-07-18 2016-09-20 Legalforce, Inc. Distributed communication of independent autonomous vehicles to provide redundancy and performance
US20160086182A1 (en) * 2014-09-24 2016-03-24 Mastercard International Incorporated System, Method and Apparatus to Detect Fraud in Travel Transactions
US10832176B2 (en) 2014-12-08 2020-11-10 Mastercard International Incorporated Cardholder travel detection with internet service
US20160189158A1 (en) * 2014-12-29 2016-06-30 Ebay Inc. Authenticating requests to access accounts based on prior requests
US9721253B2 (en) 2015-05-06 2017-08-01 Forter Ltd. Gating decision system and methods for determining whether to allow material implications to result from online activities
US10255561B2 (en) 2015-05-14 2019-04-09 Mastercard International Incorporated System, method and apparatus for detecting absent airline itineraries
US10817593B1 (en) * 2015-12-29 2020-10-27 Wells Fargo Bank, N.A. User information gathering and distribution system
CN108780474B (zh) 2016-03-14 2022-07-19 株式会社理光 服务提供系统、服务递送系统、服务提供方法和记录介质
EP3438838A4 (en) * 2016-03-29 2019-03-13 Ricoh Company, Ltd. SERVICE DELIVERY SYSTEM, SERVICE PACKING SYSTEM, SERVICE PROCESSING AND PROGRAM
JP6620883B2 (ja) 2016-03-29 2019-12-18 株式会社リコー サービス提供システム、サービス授受システム、サービス提供方法、及びプログラム
JP6638808B2 (ja) * 2016-03-29 2020-01-29 株式会社リコー サービス提供システム、サービス授受システム、サービス提供方法、及びプログラム
US10542010B2 (en) * 2016-05-27 2020-01-21 Microsoft Technology Licensing, Llc Account verification in deferred provisioning systems
US20180089676A1 (en) * 2016-09-23 2018-03-29 Paypal, Inc. Dynamic Multi-Website Data Collection and Data Sharing
US20180089742A1 (en) * 2016-09-23 2018-03-29 Paypal, Inc. Dynamic Website Personalization and Data Sharing
US20180330325A1 (en) 2017-05-12 2018-11-15 Zippy Inc. Method for indicating delivery location and software for same
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US11003999B1 (en) * 2018-11-09 2021-05-11 Bottomline Technologies, Inc. Customized automated account opening decisioning using machine learning
US12015918B2 (en) 2018-11-27 2024-06-18 Zumigo, Inc. Identity authentication using mobile carrier account information and credit bureau information
US11379616B2 (en) * 2019-03-25 2022-07-05 Identiq Protocol Ltd. System and method for providing anonymous validation of a query among a plurality of nodes in a network
US12067637B1 (en) 2019-03-29 2024-08-20 Block, Inc. Gradated service access based on identity verification (IDV)
KR102127171B1 (ko) 2019-08-30 2020-06-26 주식회사 카카오뱅크 신분증 인식 모델을 이용한 분산 학습 방법, 서버, 어플리케이션 및 이를 통한 신분증 인식 방법
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data
US20210090077A1 (en) * 2019-09-19 2021-03-25 Bank Of America Corporation System architectures for point-of-sale data obfuscation, data removal and data encryption
CN110807181A (zh) * 2019-11-14 2020-02-18 北京融易做科技有限公司 企业内部数据库登录验证方法、装置及系统
US11528267B2 (en) * 2019-12-06 2022-12-13 Bank Of America Corporation System for automated image authentication and external database verification
US20210182808A1 (en) * 2019-12-12 2021-06-17 Visa International Service Association Method, System, and Computer Program Product for Distributing Data from Multiple Data Sources
TWI768280B (zh) * 2020-01-13 2022-06-21 玉山商業銀行股份有限公司 線上交易處理系統及方法
EP4250205A1 (en) * 2022-03-24 2023-09-27 Dunamu Inc. A method of verifying originator or beneficiary and an electronic device performing thereof
CN115987940B (zh) * 2022-12-05 2024-04-19 中国联合网络通信集团有限公司 一种电信标识方法、装置及计算机可读存储介质

Family Cites Families (93)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4053710A (en) * 1976-03-01 1977-10-11 Ncr Corporation Automatic speaker verification systems employing moment invariants
JPH0561834A (ja) 1991-09-03 1993-03-12 Nec Corp データベースシステムの機密保護方式
US5819226A (en) * 1992-09-08 1998-10-06 Hnc Software Inc. Fraud detection using predictive modeling
US5544255A (en) * 1994-08-31 1996-08-06 Peripheral Vision Limited Method and system for the capture, storage, transport and authentication of handwritten signatures
US5826241A (en) 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5774525A (en) * 1995-01-23 1998-06-30 International Business Machines Corporation Method and apparatus utilizing dynamic questioning to provide secure access control
US5570093A (en) * 1995-02-10 1996-10-29 Applied Concepts, Inc. Police traffic radar using absolute signal strength information to improve target signal processing accuracy
US5657389A (en) * 1995-05-08 1997-08-12 Image Data, Llc Positive identification system and method
US6070141A (en) * 1995-05-08 2000-05-30 Image Data, Llc System and method of assessing the quality of an identification transaction using an identificaion quality score
US5790677A (en) 1995-06-29 1998-08-04 Microsoft Corporation System and method for secure electronic commerce transactions
JP3506293B2 (ja) 1995-10-30 2004-03-15 株式会社リコー 話者識別システム
US5757917A (en) 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5940476A (en) * 1996-06-28 1999-08-17 Distributed Software Development, Inc. System and method for identifying an unidentified caller
US5684951A (en) * 1996-03-20 1997-11-04 Synopsys, Inc. Method and system for user authorization over a multi-user computer system
US7159116B2 (en) * 1999-12-07 2007-01-02 Blue Spike, Inc. Systems, methods and devices for trusted transactions
JP3488347B2 (ja) * 1996-08-29 2004-01-19 株式会社日立製作所 アドレス自動配布システム及びアドレス配布サーバ
US6819783B2 (en) * 1996-09-04 2004-11-16 Centerframe, Llc Obtaining person-specific images in a public venue
US6195657B1 (en) * 1996-09-26 2001-02-27 Imana, Inc. Software, method and apparatus for efficient categorization and recommendation of subjects according to multidimensional semantics
US7094149B2 (en) * 1996-12-18 2006-08-22 Walker Digital, Llc Methods and systems for facilitating play at a gaming device by means of third party offers
US6182222B1 (en) * 1997-03-25 2001-01-30 Electronic Data Systems Corporation Secure data storage system and method
US6119103A (en) 1997-05-27 2000-09-12 Visa International Service Association Financial risk prediction systems and methods therefor
US5913212A (en) * 1997-06-13 1999-06-15 Tele-Publishing, Inc. Personal journal
US6029154A (en) * 1997-07-28 2000-02-22 Internet Commerce Services Corporation Method and system for detecting fraud in a credit card transaction over the internet
US20020007411A1 (en) 1998-08-10 2002-01-17 Shvat Shaked Automatic network user identification
US5966351A (en) * 1997-10-29 1999-10-12 Siemens Information And Communications Networks, Inc. System and method for changing the priority of voice mail messages within the recipient's mailbox
US6095413A (en) * 1997-11-17 2000-08-01 Automated Transaction Corporation System and method for enhanced fraud detection in automated electronic credit card processing
US6233565B1 (en) * 1998-02-13 2001-05-15 Saranac Software, Inc. Methods and apparatus for internet based financial transactions with evidence of payment
US6038333A (en) * 1998-03-16 2000-03-14 Hewlett-Packard Company Person identifier and management system
US5913210A (en) * 1998-03-27 1999-06-15 Call; Charles G. Methods and apparatus for disseminating product information via the internet
US6484260B1 (en) * 1998-04-24 2002-11-19 Identix, Inc. Personal identification system
CA2357003C (en) 1998-05-21 2002-04-09 Equifax Inc. System and method for authentication of network users and issuing a digital certificate
AU4091199A (en) 1998-05-21 1999-12-06 Equifax, Inc. System and method for authentication of network users
AU4162199A (en) 1998-06-11 1999-12-30 Aqi Ltd. Method, apparatus and system for securing credit card transactions
IL125826A (en) * 1998-08-17 2001-05-20 Ur Jonathan Shem Method for preventing unauthorized use of credit cards in remote payments and an optional supplemental-code card for use therein
JP2000067005A (ja) 1998-08-26 2000-03-03 Nippon Telegr & Teleph Corp <Ntt> 本人確認方法及びその方法を用いた装置及び本人確認装置制御プログラムを記録した記録媒体
US6254000B1 (en) * 1998-11-13 2001-07-03 First Data Corporation System and method for providing a card transaction authorization fraud warning
US6173269B1 (en) * 1998-12-16 2001-01-09 Zowi.Com, Inc Method and apparatus for executing electronic commercial transactions with minors
WO2000062214A1 (en) 1999-04-08 2000-10-19 Cleartogo.Com Credit card security technique
AU5777000A (en) 1999-06-30 2001-01-31 Catalog City, Inc. Method and system for sharing cookie information during internet transactions
JP2001052181A (ja) 1999-08-13 2001-02-23 Nippon Telegr & Teleph Corp <Ntt> 個人認証方法及び個人認証プログラムを記録した記録媒体
WO2001015379A1 (en) 1999-08-25 2001-03-01 Secucell Ltd. Apparatus and method for receiving identification information via a first and a second communication network
AU7357400A (en) 1999-09-09 2001-04-10 Hugh Gibbs Taylor Jr. System and method for evaluating credit risks
US6853988B1 (en) * 1999-09-20 2005-02-08 Security First Corporation Cryptographic server with provisions for interoperability between cryptographic systems
WO2001033520A1 (en) 1999-11-04 2001-05-10 David Felger A method of billing a purchase made over a computer network
US6466917B1 (en) 1999-12-03 2002-10-15 Ebay Inc. Method and apparatus for verifying the identity of a participant within an on-line auction environment
WO2001044977A2 (en) 1999-12-14 2001-06-21 Imandi.Com Inc. Combined offline and online verification of user legitimacy for electronic commerce
US6934858B2 (en) 1999-12-15 2005-08-23 Authentify, Inc. System and method of using the public switched telephone network in providing authentication or authorization for online transactions
WO2001044975A2 (en) 1999-12-17 2001-06-21 Zack Network, Inc. Identifying web users in a proxy server
WO2001057609A2 (en) 2000-01-31 2001-08-09 Trivnet Ltd. Applications of automatic internet identification methods
JP2003523589A (ja) * 2000-02-18 2003-08-05 サイパック アクチボラゲット 識別および認証のための方法およびデバイス
EP1128628A1 (en) * 2000-02-23 2001-08-29 Tradesafely.com Limited Method and apparatus for Internet web site authentication
AU2001243658B2 (en) 2000-03-15 2005-12-15 Mastercard International Incorporated Method and system for secure payments over a computer network
EP1134707A1 (en) 2000-03-17 2001-09-19 Tradesafely.com Limited Payment authorisation method and apparatus
CA2398355A1 (en) 2000-03-17 2001-09-20 Michael Hawkes Payment authorisation method and apparatus
US7778934B2 (en) 2000-04-17 2010-08-17 Verisign, Inc. Authenticated payment
WO2001082246A2 (en) 2000-04-24 2001-11-01 Visa International Service Association Online payer authentication service
US7577834B1 (en) * 2000-05-09 2009-08-18 Sun Microsystems, Inc. Message authentication using message gates in a distributed computing environment
US6300872B1 (en) * 2000-06-20 2001-10-09 Philips Electronics North America Corp. Object proximity/security adaptive event detection
GB0015147D0 (en) * 2000-06-21 2000-08-09 Jacobs Michael Tracking system
FI115355B (fi) 2000-06-22 2005-04-15 Icl Invia Oyj Järjestely suojatun järjestelmän käyttäjän tunnistamiseen ja todentamiseen
JP4903346B2 (ja) 2000-06-22 2012-03-28 マスターカード インターナシヨナル インコーポレーテツド 擬似或いは代理口座番号なしでコンピュータネットワークを越えて安全な支払いを処理するための改善された方法およびシステム
CA2412184C (en) 2000-07-10 2015-04-07 Paypal, Inc. System and method for verifying a financial instrument
AU8348901A (en) 2000-07-10 2002-01-21 Mastercard International Inc Method and system for conducting secure electronic commerce transactions with authorization request data loop-back
US8380628B1 (en) 2000-07-17 2013-02-19 Harris Intellectual Property, Lp System and method for verifying commercial transactions
US7076727B1 (en) * 2000-08-16 2006-07-11 Sparta Systems, Inc. Configuring activities to perform operations on user-defined fields
US7216132B1 (en) * 2000-08-16 2007-05-08 Sparta Systems, Inc. System and method for automated process control
US7266764B1 (en) * 2000-08-16 2007-09-04 Sparta Systems, Inc. Graphical user interface for automated process control
JP4654498B2 (ja) * 2000-08-31 2011-03-23 ソニー株式会社 個人認証システム、個人認証方法、および情報処理装置、並びにプログラム提供媒体
NO20004542L (no) 2000-09-12 2002-03-13 Autencia As System og fremgangsmåte for identitetsverifisering
CA2423957A1 (en) 2000-09-27 2002-04-04 Mastercard International Inc. A universal and interoperable system and method utilizing a universal cardholder authentication field (ucaf) for authentication data collection and validation
AU2001294775A1 (en) 2000-09-29 2002-04-08 Hnc Software, Inc. Score based decisioning
GB2368227B (en) * 2000-10-17 2003-12-10 Hewlett Packard Co Contact center
US7082409B1 (en) * 2000-11-22 2006-07-25 Richard Sutton Cherry Fully integrated on-line interactive purchasing club incorporating extremely rapid fulfillment
US20020073138A1 (en) * 2000-12-08 2002-06-13 Gilbert Eric S. De-identification and linkage of data records
AU2002248615A1 (en) 2001-03-12 2002-09-24 Geotrust, Inc. System and method for providing secure transactions
US20020147691A1 (en) * 2001-04-05 2002-10-10 Davis Dustin M. Method and system for consummating a transaction in a biometric verification system based on prior transactional histories
EP1442350A2 (en) 2001-04-12 2004-08-04 Netdesigns Limited User identity verification system
US7542931B2 (en) 2001-06-01 2009-06-02 American Express Travel Related Services Company, Inc. System and method for global automated address verification
US6957259B1 (en) * 2001-06-25 2005-10-18 Bellsouth Intellectual Property Corporation System and method for regulating emails by maintaining, updating and comparing the profile information for the email source to the target email statistics
AU2002326635A1 (en) 2001-08-15 2003-03-03 Shea Writer Methods for verifying cardholder authenticity and for creating billing address database
WO2003021473A1 (en) * 2001-08-30 2003-03-13 Privasource, Inc. Data source privacy screening systems and methods
US7111789B2 (en) * 2001-08-31 2006-09-26 Arcot Systems, Inc. Enhancements to multi-party authentication and other protocols
US20030061163A1 (en) 2001-09-27 2003-03-27 Durfield Richard C. Method and apparatus for verification/authorization by credit or debit card owner of use of card concurrently with merchant transaction
US7325143B2 (en) * 2001-10-15 2008-01-29 Linux Foundation Digital identity creation and coalescence for service authorization
US8650103B2 (en) * 2001-10-17 2014-02-11 Ebay, Inc. Verification of a person identifier received online
WO2003042893A1 (en) 2001-11-15 2003-05-22 First Data Corporation Online payments
GB2383497B (en) 2001-12-21 2005-09-07 Nec Technologies Transaction verification using a mobile telephone network
US7046779B2 (en) * 2002-02-15 2006-05-16 Multimedia Telesys, Inc. Video conference system and methods for use at multi-station sites
US7015817B2 (en) * 2002-05-14 2006-03-21 Shuan Michael Copley Personal tracking device
US6853739B2 (en) * 2002-05-15 2005-02-08 Bio Com, Llc Identity verification system
US6937702B1 (en) * 2002-05-28 2005-08-30 West Corporation Method, apparatus, and computer readable media for minimizing the risk of fraudulent access to call center resources
JP4363868B2 (ja) * 2002-08-23 2009-11-11 株式会社東芝 検索キーワード分析プログラム及びシステム並びに方法
US7613776B1 (en) * 2003-03-26 2009-11-03 Aol Llc Identifying and using identities deemed to be known to a user

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014197424A (ja) * 2014-07-08 2014-10-16 ヤフー株式会社 広告配信装置、広告配信方法、端末推定装置、端末推定方法およびプログラム
JP2016119125A (ja) * 2016-03-16 2016-06-30 ヤフー株式会社 広告配信装置、広告配信方法、端末推定装置、端末推定方法およびプログラム
US10936532B2 (en) 2018-08-06 2021-03-02 Toshiba Memory Corporation Electronic device and data transmitting/receiving method
JP7565816B2 (ja) 2021-02-05 2024-10-11 東芝テック株式会社 サーバ装置及びプログラム
KR102440878B1 (ko) * 2021-12-09 2022-09-05 한국인터넷진흥원 가상 자산 부정 거래 탐지를 위한 탐지 모델의 학습 방법, 탐지 모델을 이용한 가상 자산 부정 거래의 탐지 방법 및 이들을 수행하는 장치 및 컴퓨터 프로그램
WO2023106572A1 (ko) * 2021-12-09 2023-06-15 한국인터넷진흥원 가상 자산 부정 거래 탐지를 위한 탐지 모델의 학습 방법, 탐지 모델을 이용한 가상 자산 부정 거래의 탐지 방법 및 이들을 수행하는 장치 및 컴퓨터 프로그램

Also Published As

Publication number Publication date
AU2002340207B2 (en) 2008-07-31
NZ532258A (en) 2006-04-28
EP1436746A4 (en) 2007-10-10
US20140222690A1 (en) 2014-08-07
IL161437A0 (en) 2004-09-27
EP1436746A2 (en) 2004-07-14
WO2003034633A2 (en) 2003-04-24
CA2463891C (en) 2012-07-17
WO2003034633A3 (en) 2003-11-13
US8650103B2 (en) 2014-02-11
IL161437A (en) 2010-11-30
CA2463891A1 (en) 2003-04-24
CN1666205A (zh) 2005-09-07
US20040243832A1 (en) 2004-12-02

Similar Documents

Publication Publication Date Title
US8650103B2 (en) Verification of a person identifier received online
AU2002340207A1 (en) Verification of a person identifier received online
US7562222B2 (en) System and method for authenticating entities to users
Ramzan Phishing attacks and countermeasures
US9015263B2 (en) Domain name searching with reputation rating
US7346775B2 (en) System and method for authentication of users and web sites
US10999298B2 (en) Method and system for identifying users and detecting fraud by use of the internet
US8880435B1 (en) Detection and tracking of unauthorized computer access attempts
US20150213131A1 (en) Domain name searching with reputation rating
US20080028443A1 (en) Domain name related reputation and secure certificates
US20100174795A1 (en) Tracking domain name related reputation
US20060200487A1 (en) Domain name related reputation and secure certificates
US20080021890A1 (en) Presenting search engine results based on domain name related reputation
US20080022013A1 (en) Publishing domain name related reputation in whois records
US20070006286A1 (en) System and method for security in global computer transactions that enable reverse-authentication of a server by a client
US20090083184A1 (en) Methods and Apparatus for Detecting Fraud with Time Based Computer Tags
US20180007066A1 (en) Detection of phishing dropboxes
US20070250916A1 (en) B2C Authentication
JP2008521149A (ja) オンライン詐欺の可能性に関連するデータを解析するための方法およびシステム
WO2007058732A2 (en) B2c authentication system and methods
US20060143695A1 (en) Anonymous Spoof resistant authentication and enrollment methods
US20030126080A1 (en) Method and apparatus for communicating over a public computer network
WO2005094264A2 (en) Method and apparatus for authenticating entities by non-registered users
ZA200402931B (en) Verification of a person identifier received online.
Ceesay Mitigating phishing attacks: a detection, response and evaluation framework

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050929

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081203

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20090303

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20090403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090415

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090428

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20090428

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20090430

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20090430

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20090430

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20090512

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090512

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20090310

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20090526

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090602

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20090602

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090630