JP2016512636A - トークン化された支払いサービス登録 - Google Patents

Abstract

本明細書では、ユーザーを支払いサービスに登録するためのプロセスが開示される。プロセスのいくつかは、トークン化された外部資金振替情報を金融機関から支払いサービスに配信することを伴う。プロセスのいくつかは、外部資金振替情報が支払いサービスによって決して格納されることも処理されることもないが、それでもユーザーの身元が、金融機関の代わりに、支払いサービスによって十分に確認されるように、実行される。

Description

関連出願の相互参照
本出願は、２０１３年３月５日に出願された米国特許出願第１３／７８６，４０８号の一部継続出願である、２０１３年８月１日に出願された、米国特許出願第１３／９５７，２４６号の一部継続出願である、２０１３年９月１９日に出願された米国特許出願第１４／０３１，３８１号からの優先権を主張し、その両方が、参照により全体として本明細書に組み込まれる。

信頼性があって費用のかからないバンキングおよび支払いサービスへのアクセスが、発展途上経済の発展のため、および先進国世界においても支払い処理費用の低減のために重要である。国際通貨基金の金融アクセスサーベイによれば、世界中の多数の国々では、国内総生産の４分の１未満しか市中銀行での預託現在高と一致しない。これらの国々の多くでは、利用可能な支払い処理サービスは、日々の商業生活に対して非常に高価であるか、または支払い処理インフラストラクチャの欠如のために完全に利用不可能である。さらに、従来の支払処理方法に対する十分なインフラストラクチャの有無にかかわらず、支払い処理は、ほぼ全ての商取引の１パーセントを消費し、その結果、先進国経済および発展途上国経済の両方について同様に損失となる。

新規のユーザーを登録することは、支払いサービスの管理に対する費用にとって重大な努力である。第１に、ユーザー数が増加するにつれて、支払いサービスを管理する固定費が減少する。従って、もっと流動的な登録システムが支払いサービスの登録ユーザー数の増加を容易にする範囲で、支払いサービスを管理するユーザーあたりの費用も減少する。第２に、新規ユーザーを登録することは、支払いサービスを不正登録の費用にさらす。新規ユーザーの身元を確認するために適切な注意が払われない場合、支払いサービスを使用する不正振替が行われ得、それは、不正振替の直接的な金銭的損失ならびに支払いサービスにおける信頼喪失の間接的費用を通して、支払いプロセッサに悪影響を及ぼす。最後に、新規ユーザーを登録することは、新規顧客の確認が、一般に、支払いサービスの有給従業員の時間と注意を必要とするので、支払いサービスにとって費用がかかり、また、そのシステムの潜在的なユーザーは、支払いサービスの確認および承認プロセスのナビゲートに関連してストレスおよび時間消費を被るので、潜在的なユーザーにとってもコストがかかる。

費用効率が高い支払い処理システムの開発および保守に対する別の顕著な障害は、支払いサービスが、支払いシステムへのお金の振込みおよび支払いシステムからのお金の引出しに使用できる外部資金振替情報を操作および格納している間に、不正取引のリスクにさらされるという事実である。ユーザーが支払いサービスに登録する場合、ユーザーは一般に、支払いサービスが口座名義人の代わりに金融機関に対して資金の振込みおよび引出しを行うのを可能にする、外部資金振替情報が発行されるか、またはその提供を要求される。支払いサービスの構造およびその関連金融機関との関係に応じて、外部資金振替情報のセキュリティが様々なチャネルを通じて損なわれ得る。その情報は、口座名義人から支払いサービスに移動される間に、支払いサービスのサーバー上に格納されている間に、または口座名義人の代わりに資金の振替を開始するために支払いサービスから金融機関に転送される間に、盗まれ得る。これらの点の全てにおいて、支払いサービスは、外部資金振替情報がセキュリティ侵害されて、口座名義人の承認なしで資金が不正に送金される場合、潜在的な法的責任にさらされる。ある支払いシステムでは、外部資金振替情報は、支払いサービスの口座名義人の支払いシステムにおける実際の資格よりも著しく多くのお金を振り替えることが可能な口座に関連し得る。これらの状況では、不正取引に対する潜在的な法的責任が、支払いサービス自体の予備費を小さくできる。

本明細書では、ユーザーを支払いサービスに登録するためのプロセスが開示される。本プロセスは、ユーザーのグループに対する識別情報の一括アップロードを金融機関から受け取ることを含む。ユーザーのグループは、その金融機関で口座のセットを有する。本プロセスは、その識別情報を使用して、ユーザーのグループからのユーザーの身元を確認することも含む。本プロセスは、ユーザーの身元を確認後、ユーザーに対するトークンの要求を金融機関に送信することも含む。本プロセスは、そのトークンを金融機関に送信することにより、ユーザーの代わりに資金の振替を開始することも含む。トークンは、ユーザーに関連付けられた口座に対するトークン化された外部資金振替情報を含む。口座は、口座のセットからである。

本明細書では、ユーザーを支払いサービスに登録するための別のプロセスも開示される。本プロセスは、ユーザーから登録を意図するメッセージを受け取ることを含む。本プロセスは、ユーザーから識別情報を要求することも含む。本プロセスは、ユーザーから金融機関識別子を要求することも含む。本プロセスは、一時的なコードをユーザーに送信することも含む。本プロセスは、一時的なコードを既知の店頭端末から受け取ることも含む。既知の店頭端末は、支払いサービスで以前に登録された。本プロセスは、識別情報の少なくとも一部を既知の店頭端末に送信することも含む。本プロセスは、身元確認済みメッセージを既知の店頭端末から受信することも含む。本プロセスは、トークン化された外部資金振替情報を、金融機関識別子によって識別された金融機関から受信することも含む。

本明細書では、ユーザーを支払いサービスに登録するための別のプロセスも開示される。本プロセスは、識別情報を既知の端末に送信することも含む。本プロセスは、身元確認済みメッセージを既知の端末から受信することも含む。本プロセスは、トークン化された外部資金振替情報を含むトークンを金融機関から受信することも含む。身元確認済みメッセージは、ユーザーの身元を確認するために実行された、顧客確認手続きのタイプを示す。トークンは、金融機関によって管理される口座からの振替に制限を課す。制限の程度は、顧客確認手続きのタイプによって提供される本人確認のレベルに基づく。

本発明の一実施形態による口座設定システムのブロック図である。 本発明の一実施形態による口座設定方法の流れ図である。 本発明の一実施形態に従って、確認情報の外部ソースを使用する口座設定システムのブロック図である。 本発明の一実施形態に従って、確認情報の外部ソースを使用する口座設定方法の流れ図である。 本発明の一実施形態に従った、口座設定または変更方法の流れ図である。 本発明の一実施形態に従って、口座データを使用する口座変更方法の流れ図である。 本発明の一実施形態に従い、後続の取引方法を含んだ、口座設定方法の流れ図である。 本発明の一実施形態に従い、後続の携帯電話開始取引方法を含んだ、口座設定方法の流れ図である。 本発明の一実施形態に従い、設定された口座を使用する店頭取引システムのブロック図である。 本発明の一実施形態に従い、設定された口座を使用するオンライン販売取引システムのブロック図である。 本発明の一実施形態に従い、設定された口座を使用する個人間での取引システムのブロック図である。 本発明の実施形態に従って、ユーザーを支払いサービスに登録するための方法の流れ図である。 本発明の実施形態に従い、ユーザーへの電話を伴う、ユーザーを支払いサービスに登録するための方法の流れ図である。 本発明の実施形態に従い、人間の顧客サービス担当者による、支払いサービスの潜在的なユーザーへの電話を伴う登録動作を示す、動作フロー図である。 本発明の実施形態に従い、自動化サービスによる、支払いサービスの潜在的なユーザーへの電話を伴う登録動作を示す、動作フロー図である。 本発明の実施形態に従い、金融機関からの情報の一括アップロードを使用する支払いサービスの潜在的なユーザーを登録するための方法の流れ図である。 本発明の実施形態に従った、登録手続きの第２段階を示す動作図である。 本発明の実施形態に従い、金融機関からの識別情報の一括アップロードおよび外部資金振替情報のトークン化を使用する、支払いサービスの潜在的なユーザーを登録するための方法の流れ図である。 本発明の実施形態に従って、支払いサービスの潜在的なユーザーを、金融機関識別子要求および一時的なコードを送信することにより登録するための方法の流れ図である。 本発明の実施形態に従い、トークンを使用してユーザーの口座に制限を課すことを伴う支払いサービスの潜在的なユーザーを登録するための方法の流れ図である。

本開示は、金融取引のために使用される口座に関する。具体的には、本開示は、かかる口座の設定に関する。

本明細書で説明するのは、取引制限の対象であり得るタイプの金融取引口座の作成および使用の方法である。その金融取引口座は、低間接費用、ユーザーからの最小時間関与、および幅広く利用可能な技術を有するシステムを使用して作成できる。取引制限は、事前承認技術を使用して、口座名義人によってカスタマイズできる。このタイプの金融口座は、現金、与信枠、セキュリティ、または同様のものと関連付けられ得る。以下の記述では、説明目的で、多数の例および特定の詳細が、本開示の完全な理解を提供するために記載される。しかし、当業者には、本開示は、請求項によって定義されるとおり、これらの例のみにおけるか、または以下で説明する他の特徴と組み合わせた、特徴の一部または全部を含み得、本明細書で説明する特徴および概念の修正および均等物をさらに含み得ることは明らかであろう。

本文書では、様々なコンピュータ実装方法、プロセス、および手続きが開示される。様々な動作（受信、格納、送信、通信、表示など）が、たとえその動作がユーザーによって認可、開始、もしくはトリガーされる場合であっても、または、たとえハードウェア装置がコンピュータプログラム、ソフトウェア、ファームウェアなどによって制御される場合であっても、ハードウェア装置によって実行されることを理解されたい。さらに、ハードウェア装置は、たとえデータが概念または現実世界のオブジェクトを表し得、従って「データ」それ自体としての明示的なラベル付けが省略されている場合であっても、データについて動作することが理解される。例えば、ハードウェア装置が「レコードを格納している」として記述される場合、ハードウェア装置は、レコードを表すデータを格納していることが理解される。

前述のように、金融機関における典型的な口座に対して、ある制限から外れる取引は、しばしば、追加レベルの本人確認を要求する。口座名義人は、かかる取引が要求されるたびに、この追加の確認を提供する必要がある。以下で説明する実施形態は、口座名義人および金融機関の両方に対するセキュリティをそのまま維持しながら、この追加の努力に対する必要性を取り除く。取引は従って、簡素化される。また、以下で説明する実施形態は、口座名義人および金融機関に対するセキュリティを維持し、かつ全ての適切な金融規制の順守を確実にしながら、口座名義人が、自分の口座に課された制限への何らかの入力を行うのを可能にする。

一実施形態では、口座は、それに関連付けられた追加の確認データを有する。このデータは、保存され、次いで、よりコンパクトな確認情報に対して−例えば、携帯電話番号および／またはユーザー定義の個人識別番号（ＰＩＮ）に対して、入力される。口座名義人は次いで、通常、単にこのコンパクトな確認情報を提供することにより、追加の確認手続きを必要とし得る取引を実行できる。

本明細書で説明する口座は、正規の銀行口座またはクレジットカード口座であり得る。本明細書で説明する口座は、２００７年８月２９日に出願された「Ｐａｙｍｅｎｔ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」に対する米国特許公開第２００９／００２４５３３ Ａ１号、または２０１３年１月３１日に出願された「Ｓｅｌｆ−ａｕｔｈｅｎｔｉｃａｔｉｎｇ ｐｅｅｒ−ｔｏ−ｐｅｅｒ ｔｒａｎｓａｃｔｉｏｎ」に対する米国特許出願第１３／７５５，４２１号に記載された、ＭＯＢＩ口座にも類似し得、それらの特許の両方が、本開示の譲受人によって所有され、両方が参照によりその全体として本明細書に組み込まれる。

口座設定で提供される追加の確認データは、様々な「顧客確認（ＫＹＣ：ｋｎｏｗ ｙｏｕｒ ｃｕｓｔｏｍｅｒ）」規制を満足することも要求され得る。これらは、どの形式の識別が様々な取引に対して容認可能であるかに関する規制である。例えば、これらの規制は、より高額の取引を行うことを希望している顧客は、より安全な形式の本人確認を提示する必要があることを規定し得る。

本明細書で説明する設定方法は、新規の口座に限定されず、既存の口座が同じ方法を使用して再設定できる。口座名義人は、その口座に関連付けられた追加の確認データを変更し得、かつ／またはその口座に関連付けられた制限が口座利用データに基づき自動的に変更され得る。

以下の説明では、関与する全てのメッセージがいくつかの手段；例えば、有線もしくは無線の音声もしくはデータチャネル、または同様のものを介して送信できることが理解される。これらの手段は、プライベートまたは明確に安全な通信手段；例えば、暗号化された音声もしくはデータチャネル、または同様のものであり得る。通信手段は（ｉ）電子メールメッセージ、音声電話、データメッセージ、テキストメッセージ、他のアプリケーション（例えば、Ｆａｃｅｂｏｏｋ、Ｌｉｎｋｅｄ Ｉｎ、Ｓｋｙｐｅおよび同様のもの）を経由して送信されたメッセージなどの、モバイル機器への、および／またはモバイル機器からのメッセージ、ならびに（ｉｉ）デスクトップコンピュータなどの固定装置もしくはテレビ上で実行しているブラウザへ、および／またはそれらから送信された、同じ種類のメッセージを含む。

図１は、本発明の実施形態の例となるブロック図１００を示す。開始者１１０−例えば、新規の口座を開きたいか、または既存の口座を再設定したいユーザー−は、口座サーバー１３０と、いくつかの通信手段のいずれかを経由し、ネットワーク１２０を通して通信する。ネットワーク１２０は、例えば、インターネットであり得る。口座サーバー１３０は、口座１３５を維持する。口座１３５は、後の取引に関連付けられた１つ以上の制限１３６で設定される。これらの制限１３６は、取引の処理を許可または拒否するために、後の取引からのデータと比較される。

口座１３５と関連付けられ得る制限１３６の多数の例がある。かかる例は、現金引き出しに関する最大限度、もしくは購入に関する最大限度、もしくは他の最大取引限度；取引が表示され得る通貨に関する制限；または取引タイプ（例えば、オンライン購入が制限され得るが、店頭での購入は許可され得る）に関する制限を含むが、それらに限定されない。他の例は：最大預入額制限、所与の期間（例えば、日、週、または月）における取引回数に関する制限、取引場所に関する制限、購入した品目もしくはサービスのタイプに関する制限、または現金を送信する相手に関する制限を含む。

図２は、口座設定プロセスの流れ図２００を示す。流れ図２００によって表されるプロセスは、（例えば、自動音声システムに対する）電話、または一連のテキストメッセージ、またはモバイル機器もしくは固定装置上のウェブサイト、または銀行の支店もしくは金融機関の事務所を通じて対話形式で、または小売業者の店頭（ＰＯＳ）で、またはこれらの任意の組合せで実施され得る。流れ図２００のステップ２１０で、口座サーバー１３０は、開始者１１０から口座１３５を設定する要求を受信する。この要求は、例えば、インターネット接続されたモバイル機器もしくは固定装置から、ウェブサイトフォームを介して、送信され得る；この要求はまた、テキストメッセージまたはモバイル機器から、例えば、自動音声対話システムへの電話を介して送信され得る。ステップ２２０で、口座サーバー１３０は、確認情報に対する要求を開始者１１０に送信する。ステップ２２０で送信された要求は、例えば、異なる確認オプションのリストまたはメニューおよびそれらが対応する口座制限の形式であり得る。かかるメニューは、例えば、ウェブページ上で、または自動音声システムの一部として（操作が電話を通じて行われている場合）、または、ＰＯＳでの小売業者、もしくは銀行での代理人により対話形式で、提示され得る。例えば、１つのメニューオプションは、＄１００、または＄３００の口座の最大取引限度に対応する、既存のＰＩＮをタイプ入力することであり得；別のオプションは、さらに高額の口座取引限度（例えば、＄５００、または＄１０００、または＄１５００）を可能にするために、パスポートまたは運転免許証などの、身元証明文書をスキャンまたは撮影することであり得る。確認情報の他の例は、開始者に提示される一連の確認質問、（例えば、既に設定されている）第２口座の口座番号、開始者の写真、政府発行の識別番号、または信頼された発行元が発行した識別番号を含む。

他の本人確認情報オプション；例えば、指紋、または網膜スキャンなどの、生体認証情報も提示され得る。このタイプの確認情報は、もっと高額の取引限度、例えば、＄５０００または＄１０，０００さえ許可し得る。オプションの異なる組合せが異なる制限に対して利用可能であり得−例えば、写真ＩＤと生体認証情報の両方が、ある通貨を伴う取引に対して要求され得る。また、異なるタイプの取引に対して異なるレベルが設定され得；例えば、ユーザーは、口座を、購入限度に対しては＄５００であるが、現金引き出し限度に対しては＄１００で設定することを欲し得る。このように、口座は複数の制限で設定され得る。他の制限の組合せ−例えば、ＫＹＣ規制と一致した制限−が、利用可能であり得る。口座に関する取引はさらに、開始者の設定選択に基づいていない、いくつかの制限を被り得；例えば、１日あたり＄１０００の現金引き出し限度総額が、金融機関によって決定され得、設定可能でない。口座サーバー１３０は、ステップ２２０で、開始者の携帯電話番号も要求し得、それは、後の各取引に対する開始者の識別の一部として機能し得る。

図２のステップ２３０で、口座サーバー１３０は、確認情報を開始者１１０から受信する。このステップは、例えば、開始者が、異なる確認オプションのメニューから選択し、次いで、そのオプションに関連した情報を提供することを含み得る。例えば、開始者は、＄１０００の最大取引限度に対して、自分のパスポートの画像を提供することを選択し得る。開始者は次いで、要求された文書の画像を；例えば、それをスキャンするか、または自分の携帯電話のカメラで、もしくは固定式コンピュータに取り付けられているか、組み込まれたウェブカメラで、撮影することにより、提出できる。また、開始者は、画像を郵送し得るか、またはそれを認可された代理人に見せてもよい。

要求された確認情報は、提出するための専用ハードウェア；例えば、指紋スキャナ、を必要とし得る。この場合、開始者は、設定手続きを完了するために、銀行の支店などの、事務所を訪問し得る。

図２のステップ２４０で、口座サーバー１３０は、口座１３５を、ステップ２３０で取得した確認情報に基づき設定する。このステップは、例えば、受信した確認情報および関連付けられた取引制限を安全な格納領域に格納すること、および／または開始者が、後の各取引に対する本人確認のために（例えば、自分の携帯電話番号と一緒に）使用する、ＰＩＮなどの、安全なコンパクト識別子を生成することを含み得る。安全なＰＩＮは、例えば、通常の郵便（例えば、米国郵政公社）で、開始者に送られ得るか、または開始者が銀行の支店もしくはＰＯＳにいる場合には、手渡され得る。あるいは、サーバーは、開始者に安全なＰＩＮを選択するように要求し得る。この要求は、前述した手段のいずれか；ウェブサイト、電話／音声メッセージシステム、テキストメッセージ、またはＰＯＳもしくは事務所において対話形式で、および同様のもの、によって送られ得る。開始者は、同様の通信手段を使用して、安全なＰＩＮで応答し得る。サーバーは任意選択で、永久的で安全なＰＩＮを受信するのを待機している間に使用するための一時的な確認コード（または一時的なＰＩＮ）を開始者に送信し得る。

図２で説明する設定方法は、確認プロセスを簡略化するために、外部ソースへのアクセスを利用し得る。図３に示すのは、確認データの外部ソース１５０を含むシステムのブロック図９００であり、それは、開始者１１０と、直接および／またはネットワーク１２０を通じて、通信できる。外部ソース１５０は、ネットワーク１２０を通じて、口座サーバー１３０とも通信し得る。

図４は、図３に示されたシステム９００がどのように動作するかを示す流れ図４００を示す。図２と同様に、ステップ２１０で、開始者１１０が口座を設定するための要求をサーバー１３０に送信し、ステップ２２０で、サーバーが確認情報を開始者から要求する。ステップ２３０で、サーバーが確認情報を受信し；この確認情報は、サーバーが外部ソースから情報を要求するのを可能にする鍵を含み得る。例えば、サーバー１３０が、外部の金融口座、または追加の確認情報を用いて同様に設定された別の口座にアクセスできるように、開始者は、ユーザーＩＤおよびパスワードを送信し得る。ステップ２３２で、サーバー１３０は、この情報を使用して、外部ソース１５０からさらなる確認を要求する；例えば、サーバーは、外部の金融口座の勘定残高を要求し得るか、または別の類似の口座が設定された確認情報を要求し得る。ステップ２３４で、サーバー１３０は、この追加の確認情報を外部ソース１３０から受信する。任意選択として、ステップ２３６および２３８で、サーバーは、それが外部ソースから受信している情報を開始者が確認し、開始者がこの外部データの確認を送信することを要求する。ステップ２４０で、口座が設定されて、コンパクト識別子が生成される。

図２で説明した設定方法がさらに改善され得る。図５は、新規の口座の初期化または既存の口座の再設定に適合する口座設定プロセスの流れ図３００を示す。例えば、口座名義人（開始者）が、既存の口座に関する１日の引き出し限度を増額することを欲し得；口座名義人は従って、さらに安全な形式の本人確認を提出することによりその口座を再設定する必要があり得る。ステップ２１０で、口座サーバー１３０は、開始者１１０から新規の口座を設定するか、または既存の口座を再設定する要求を受信する。ステップ２２０で、口座サーバー１３０は、確認情報に対する要求を開始者１１０に送信する。この場合もやはり、ステップ２２０で送信される要求は、例えば、異なる確認オプションのメニューおよびそれらが対応する口座制限を含むウェブサイトページの形式であり得る。同様に、このステップは、開始者が、新規の口座を作成するのではなく、既存の口座を変更することを欲する場合、携帯電話番号に対する要求、ならびに以前に定義された安全なＰＩＮに対する要求も含み得る。ステップ２３０で、口座サーバー１３０は、確認情報を開始者から受信する。ステップ２３５で、口座サーバー１３０は、口座が存在するかどうかを；例えば、提出された携帯電話番号を既存の口座のそのデータベースと比較することにより、確認する。口座が存在しない場合には、ステップ２３８で作成される。ステップ２４０で、（新規または既存の）口座が同様に、ステップ２３０で受信した確認情報に基づき設定される。

別の実施形態として、既存の口座が、口座利用データに基づき；例えば、口座取引履歴または１日あたりの平均勘定残高に基づき、再設定され得る。図６は、かかる方法に対する流れ図６００を示す。図６のステップ２１０で、開始者が、口座利用データに基づき口座を再設定するように要求する。ステップ２１０は任意選択であり；流れ図６００は、自動的に実行され得、従って、口座が再設定できるかどうかを定期的にチェックすることに留意されたい。例えば、サーバーは、制限がアップグレードされ得るかどうか、またはダウングレードする必要性があるか確認するために、口座利用を毎月チェックし得る。ステップ２６０で、利用データがチェックされて、開始者が制限の変更に対して適格であるかを確認する。例えば、開始者が、１か月間、１日あたり平均で＄１０００を上回る勘定残高を維持している場合、開始者は、最大引出し限度を＄５０だけ増額する資格があり得る。利用データにより開始者が制限の変更に対して適格とされる場合、ステップ２８０で、口座が新しい制限で再設定される。

図７は、設定プロセスの拡張された流れ図４００を示し、口座設定中に設定された制限に対する後の取引の確認が続く。図７の要素３００は、前述した実施形態のいずれかで説明したように、口座設定プロセスを表す。口座１３５は、取引要求を受け入れる準備ができている。ステップ４１０で、口座サーバー１３０は、口座１３５に関連した取引に対するデータを受信する。データは、例えば、開始者から、または小売業者から、またはその２つの組合せから送信され得る。このデータは、例えば、取引のタイプ、取引の額、および取引の通貨を含み得る。

かかる取引の例として、開始者は、店頭で購入することを欲し得る。小売業者は、取引データの一部−例えば、購入金額−をサーバーに送信し得る。開始者は次いで、サーバーに、例えば、自分の安全なＰＩＮを送信することにより、購入を完了し得る。サーバーは、図７のステップ４１０で、この取引データの両方を受信する。

図７のステップ４２０で、サーバーは、取引データを、口座１３５と関連付けられた事前設定の制限１３６と比較する。店頭購入の例では、この比較は、購入価格を、口座１３５と関連付けられた事前設定の最大購入金額と比較することを含み得る。取引データが事前設定制限の範囲に入る場合−例えば、取引金額がＰＯＳ購入金額制限を下回る場合−ステップ４３０に示すように、取引が処理される。そうでない場合、取引は処理されない。この場合、開始者は、その口座を増額された制限で再設定するために、他の確認情報を提供する機会（図示せず）を与えられ得、実際には、図７のステップ３００を繰り返す。

図８は、図７で説明した拡張されたプロセスに関する変形例を詳述する流れ図５００を示す。この場合も同様に、設定プロセス３００が実行されて、口座１３５は取引要求を受け入れる準備ができている。ステップ４１０で、サーバー１３０は、取引に対するデータを受信し、このデータの全部または一部が開始者のモバイル機器から送信される。店頭での例では、開始者は、例えば、自分の安全なＰＩＮを自分のモバイル機器からテキストメッセージを介して送信し得る。同様に、取引に関するある情報が、別の当事者によってサーバーに送信され得、例えば、小売業者が購入価格情報をサーバーに送信し得る。ステップ４１５で、サーバーは、例えば、開始者の携帯電話番号を含む、発信者ＩＤ情報を使用して、開始者の口座を識別する。前の場合と同様に、サーバーは、ステップ４２０で、取引データを、口座１３５と関連付けられた事前設定の制限１３６と比較し、ステップ４３０で、取引データがその口座に対する事前設定制限の範囲に入る場合、取引が処理される。

図９は、事前設定された口座を使用する店頭取引システムのブロック図９００を示す。このシステムでは、開始者１１０は、小売業者６１０から購入する。開始者１１０および小売業者６１０の両方が、取引情報を口座サーバー１３０に、ネットワーク１２０を経由して送信し得る。例えば、小売業者６１０は、購入価格、および他の製品情報を、サーバー１３０にウェブ対応装置を経由して送信し得、開始者１１０は、例えば、自分のモバイル機器を使用して自分の安全なＰＩＮをサーバー１３０にメール送信することにより、購入を確認し得る。この例では、ネットワーク１２０は、複数の通信チャネルを含み−小売業者６１０はインターネットを使用し得るが、他方、開始者１１０は、移動体通信ネットワークを使用することに留意されたい。

図９に示す例では、一旦、口座サーバー１３０が取引データを小売業者６１０および／または開始者１１０から受信すると、口座サーバー１３０は、開始者の口座１３５を、例えば、発信者ＩＤ情報を使用することにより、識別し得る。サーバー１３０は次いで、取引データを、口座１３５と関連付けられた制限１３６と比較し、取引が制限１３６の範囲に入る場合、サーバー１３０は取引を処理する。この時点で、サーバー１３０は、購入が承認されていること（すなわち、購入価格の資金が小売業者に送金されていること）を示すメッセージを小売業者６１０、および恐らくは開始者１１０に送信し得、小売業者６１０は、購入された製品を開始者１１０に手渡し得る。承認のこの通知は、例えば、小売業者６１０に送信されたウェブベースのメッセージ、および／または開始者１１０に送信されたテキストメッセージであり得る。

図９は、開始者１１０が現金を自分の口座１３５から引き出すシステムも表し得る。この場合、小売業者６１０はレジを有する。前述のように、開始者１１０および小売業者６１０の両方が、取引情報をサーバー１３０に送信し得、そして同様に、サーバー１３０が、この情報、および開始者の口座１３５と関連付けられた制限１３６を使用して、取引を承認または拒否する。取引が承認される場合、通知が、同様に、小売業者６１０および恐らくは開始者１１０に送信され、小売業者６１０が次いで、現金を開始者１１０に手渡すことができる。

図１０は、事前設定された口座を使用するオンライン取引システムのブロック図１０００を示す。この場合、開始者１１０は、例えば、小売業者のウェブサイトを通じて、小売業者６１０からオンライン購入を行う。開始者１１０は、ネットワーク１２０（例えば、インターネット）に接続された、固定装置またはモバイル機器上で小売業者のウェブサイトにアクセスし得る。開始者１１０および小売業者６１０の両方が、取引情報を口座サーバー１３０にインターネットを介して送信し得る。例えば、開始者１１０が、事前設定された自分の口座１３５を使用して、購入に対する支払いを行うことを選択した後、開始者は次いで、ウェブサイトにより、自分の携帯電話番号および安全なＰＩＮを入力するように促され得る。この場合も同様に、サーバー１３０は次いで、取引データを、口座１３５と関連付けられた制限１３６と比較し、取引が制限１３６の範囲に入る場合、サーバー１３０は取引を処理する。サーバー１３０は次いで、確認メッセージを小売業者６１０および開始者１１０に送信し得、小売業者６１０は、製品を顧客に出荷できる。サーバー１３０からの確認メッセージは、開始者１１０および小売業者６１０に、例えば、電子メールメッセージを介して、送信され得る。

図９および図１０に示すシステムの両方に対して、購入データが、事前設定された口座１３５の制限１３６の範囲に入っていない場合、サーバー１３０は購入を拒否し得る。図７に関して前述したように、開始者１１０は、この場合、増額された制限で口座を再設定するために、他の確認情報を提供する機会が与えられ得る。例えば、図１０のオンライン購入に対して、開始者は、自分の口座を再設定できる、ウェブサイトにリダイレクトされ得、必要であれば、追加の確認データを提供する。

図１１は、本発明の例となる事前設定された口座を使用する個人間での取引のブロック図８００を示す。図１１では、開始者１１０は、送金為替を受領者８１０に送信する。開始者１１０および受領者８１０の両方が、口座サーバー１３０にネットワーク１２０（たとえば、移動体通信ネットワーク）を介して接続する。開始者は、取引情報および受領者情報を口座サーバー１３０に送信することにより開始し得る。この情報は、例えば、テキストメッセージで送信され得、例えば、受領者の携帯電話番号および受領者に送金される金額を含み得る。サーバー１３０は、開始者の口座１３５を、例えば、開始者の発信者ＩＤ情報から識別し得る。サーバー１３０は次いで、取引データを、口座１３５と関連付けられた制限１３６と比較し、取引が制限１３６の範囲に入る場合、サーバー１３０は取引を進め得る。例えば、サーバー１３０は次いで、開始者１１０および受領者８１０から追加の確認情報を要求し得る。全ての確認手続きがうまく完了すると、資金が開始者の口座から受領者の口座に移され得る。受領者が口座を有していない場合には、口座を作成するように促され得る。

前述のように、本発明は、取引に関する異なる制限で動作するために、口座を事前設定、および再設定するための多段階ステップシステムを提供する。一特定例では、このシステムは、以下の方法で動作し得る：
１．後の取引のために口座を設定する要求の受信を受け入れるためにシステムを制御するコンピュータコード。この要求は、開始者からウェブサイトを経由して行われ得る。
２．確認情報について開始者を促すためにシステムを制御するコンピュータコード。このプロンプトは、異なる確認オプションおよびそれらの対応する口座制限のメニューの形式であり得る。
３．開始者の確認情報の受信を受け入れるためにシステムを制御するコンピュータコード。これは：
ａ．設定オプションの開始者の選択を受け入れること；
ｂ．適切な確認情報について開始者に促すこと；例えば、開始者の携帯電話番号、および開始者のパスポートの写真またはスキャン；
ｃ．開始者の本人確認情報を受け取ること；例えば、開始者のコンピュータへの組込みカメラで撮られた、開始者のパスポートのアップロードされた写真；
から成り得る。
４．開始者に対する口座が存在するかを確認するためにシステムを制御するコンピュータコード；存在しない場合には、コンピュータコードが新規の口座を作成するようにシステムに命令する。
５．開始者によって提供された確認情報と関連付けられた制限を有する、新規に作成されたか、または既存の口座を設定するため、および開始者が後の取引で使用する安全なコンパクト識別子（例えば、安全なＰＩＮ）を生成するために、システムを制御するコンピュータコード。あるいは、システムは、自己生成したＰＩＮに対する要求を開始者に送信し、続いて開始者のＰＩＮを受信し得る。

本明細書で説明するシステムは、後の取引を、前述の事前設定された制限で確認するための方法も提供する。一特定例では、本システムは取引を以下の方法で確認し得る：
１．口座に関するアクティブな取引に対するデータの受信を受け入れるためにシステムを制御するコンピュータコード；これは、例えば、店頭購入に対するものであり得、この場合、小売業者が購入価格情報をサーバーに送信し、開始者（購入者）が自分のコンパクト身元証明情報をサーバーに自分の携帯電話で送信する。
２．開始者の発信者ＩＤ情報を使用して、開始者の口座を識別するためにシステムを制御するコンピュータコード。
３．取引データを口座の制限と比較するためにシステムを制御するコンピュータコード；例えば、システムは購入価格を、口座に関して事前に設定されたＰＯＳ購入価格制限と比較し得る。
４．取引データが制限の範囲内である場合；例えば、購入価格が、口座に対して設定されたＰＯＳ購入価格制限を下回る場合に、取引を処理するためにシステムを制御するコンピュータコード。この例では、コードは次いで、小売業者および開始者に取引の成功を通知するためにシステムを制御し得る。

図２を参照して説明した口座作成方法の特定の実施態様が、図１２を参照して説明できる。図１２は、ユーザー（例えば、口座申込者）にとって便利であり、ユーザーに対して、費用がかかるか、または複雑な技術へのアクセスを要求しない、口座を作成するための方法１２００を示す。これは、ステップ２１０に関連した口座を設定するための要求が、ＳＭＳおよび音声機能に制限される基本的な携帯電話（すなわち、電話はスマートフォンである必要がない）を使用して実施できるためである。世界銀行の報告書によれば、世界の人口のほぼ４分の３がこの程度の複雑さを備えた電話にアクセスでき、従って、本方法は、広く適用可能であり、支払いサービスを、一人当たり低コストで、広範囲にわたる潜在的なユーザーに提供する可能性がある。同時に、確認情報の要求２２０、および確認情報の受信２３０の各ステップは、ＳＭＳメッセージよりも効率的かつ技術集約的な手続きを使用して実施されるが、このより集約的な技術処理の負荷をシステムのサービスプロバイダ側に負わせる−それは、同様に、ユーザーが、口座を設定するために最も基本的な技術にアクセスするだけであることを保証する。最後に、確認情報に基づき口座を設定して安全なコンパクト識別子を生成する２４０ステップは、口座をじかに確認できる信頼される小売業者または販売員を利用して実施される。全体的な手続きは、その結果、支払いサービスプロバイダに不正登録からの十分な保護をさらに提供しながら、便利で広範囲にアクセス可能な支払い登録手続きを提供する。

ステップ１２０１で、登録を意図するメッセージが、ユーザーからＳＭＳメッセージングサービスを介して受信される。メッセージは、口座サーバー１３０により、ネットワーク１２０を経由して受信され得る。ユーザーは開始者１１０であり得る。登録を意図するメッセージは、支払いサービスプロバイダによって広告されたプロンプトに応答して提供され得る。プロンプトは、ユーザーが既にそこにおける口座名義人である金融機関によっても提供されている可能性がある。登録を意図するメッセージは、所与の電話番号に送信された文字「登録（ＲＥＧ）」を含むテキストのように単純であり得る。登録を意図するメッセージは、ユーザーの携帯電話番号または、ユーザーの携帯電話番号が、モバイルオペレータのデータベースもしくは、ユーザーが既に口座名義人であった金融機関のデータベースからアクセスされ得る、何らかの他の種類の個人情報も含み得る。

ステップ１２０２で、確認情報をユーザーから要求するための問合せメッセージが、ユーザーに送信される。例えば、問合せメッセージは、運転免許証番号、納税者識別番号、または社会保障番号などの、政府識別番号に対する要求であり得る。問合せメッセージは、様々なチャネルを通じて配信できる。例えば、問合せメッセージは、ユーザーが登録を意図するメッセージを送信した携帯電話に電話している人間の顧客サービス担当者を介して配信され得る。別の例として、問合せメッセージは、ユーザーの電話上のタッチパッドインタフェースまたは双方向音声応答システムを用いてユーザーと通信する自動電話システムを介して配信され得る。

問合せメッセージによって要求される情報は、様々な形式を取ることができる。問合せメッセージは、異なる種類の個人識別情報を要求し得、政府識別番号に制限されない。例えば、情報は、ユーザーの誕生日、携帯電話番号、姓と名、または個人を識別するために使用され得る任意の他の種類の個人情報であり得る。問合せメッセージによって要求される情報の種類は、実施態様によって決まるであろう。しかし、銀行口座を持たないユーザーがマーケティング活動の対象である状況では、登録プロセスのこの初期段階において、より機密の識別情報を要求することは有益である可能性がある。この特定の実施態様において、より機密性の高い情報がこの段階で要求できる２つの理由がある。第１に、銀行口座を持たないユーザーは、個人情報窃盗のリスクをあまり避けようとせず、従って、促されると、進んで機密情報を提供する傾向が強い。第２に、不正のリスクは、金融機関とのつながりまたは確立された与信枠を証明できないユーザーの方が大きく、より機密性の高い情報を提供すると、一般に、より高いセキュリティの度合いを支払いサービスに提供できる。

ステップ１２０３で、政府識別番号または他の個人識別情報が、第３者によって提供されたデータエントリの集合に対して確認される。例えば、データエントリは、支払いサービスがアクセスできる政府精選（ｇｏｖｅｒｎｍｅｎｔ ｃｕｒａｔｅｄ）データベース内であり得る。図３を参照すると、政府精選データベースは、口座サーバー１３０によりネットワーク１２０を介してアクセスされる確認データの外部ソース１５０であり得る。データエントリは、全ての口座名義人を支払いサービスに登録することを計画していた金融機関などの第３者によって、支払いサービスにまとめてアップロードされたデータベース内でもあり得る。例えば、地方銀行は、既存の顧客の確認がさらに便利にできるように、顧客データの一括アップロードを支払いサービスプロバイダに提供し得る。別の例として、データエントリは、口座サーバー１３０がネットワーク１２０を経由してアクセスできる、信用監視機関によって精選されたデータベース内に保持され得る。

確認ステップ１２０３は、ユーザーに対する追加の識別情報を第３者データベースから引き出すことも伴い得る。政府識別番号または他の個人識別番号が第３者データベースに対して確認される実施形態では、確認されたユーザーに関連する追加の識別情報が、データベースからダウンロードされ、支払いサービスによってローカルに格納され得る。ダウンロードされた個人情報は、口座サーバー１３０内に、特定のユーザーの口座と関連付けられたエントリとして格納され得る。例えば、納税者登録番号を政府データベースに対して確認した後、確認されたユーザーの写真がダウンロードされて、口座サーバー１３０内に格納され得る。別の例として、銀行口座番号を金融機関データベースに対して確認した後、確認されたユーザーの姓名および誕生日がダウンロードされて、口座サーバー１３０内に格納され得る。

ステップ１２０４で、一時的な確認コードがユーザーにＳＭＳメッセージングサービスを介して送信される。一時的な確認コードは、テキストメッセージ送信を経由して配信できる任意の英数字コードであり得る。そのコードは数字だけまたは文字だけにできる。一時的な確認コードは、ユーザーが、自分の口座で制限されたセットの取引を実施するのを可能にし得る。例えば、一時的な確認コードは、登録に対する誘因として提供された、口座への預入の開始または口座からの事前設定額の振替を行うために使用され得る。しかし、一時的な確認コードが、登録プロセスの第２段階を信頼される端末から開始するためにだけ使用できる、プロセス１２００のバージョンに、ある利点が生じる。一時的なコードは、登録手続きを完了するための単純なテキスト命令と共に配信できる。特定の例として、一時的なコードは、開始要求が送信された店頭端末と同じ概略位置に配置されており、支払いサービスに従って動作している店頭端末の住所と共に配信できる。

図１２に戻り、ステップ１２０５で、一時的な確認コードが、既知の店頭端末を介して受信される。一例として、登録プロセスを完了するのを欲している、一時的な確認コードをもつユーザーが、既知の店頭端末を備えた、店舗、支払いセンター（ｐａｙ ｃｅｎｔｅｒ）、または銀行に入り、一時的な確認コードを入力して自分の口座の登録を進めることができる。別の例として、一時的な確認コードをもつユーザーが、支払いサービスを受け入れる店舗である品を購入しようとし、その結果、その品に対する支払いフローの一部として一時的な確認コードを提供し得る。別の例として、自分の口座に入金することを欲している、一時的な確認コードをもつユーザーが、既知の店頭端末を使用してそれを行おうとし、その結果、その取引に対する入金フローの一部として一時的な確認コードを提供しし得る。促されると、ユーザーは一時的な確認コードを既知の店頭端末に入力できる。

ステップ１２０５と組み合わせて使用される店頭端末は、支払いサービスで動作するように、または支払いサービスによって設定されたポリシーに従って操作されるように、事前に設定されているので、「既知の」店頭端末と呼ぶことができる。店頭端末は、支払いサービスによって設定された仕様に従って製造され、支払いサービスを使用して支払いを処理するために、小売業者、支払いセンター、または銀行に提供され得る。店頭端末は、端末を支払い処理サービスと適合させるために、ソフトウェアで特別に設定された、標準的な店頭端末でもあり得る。最後に、店頭端末は、支払いサービスで作業するために特別に変更されていないが、特定の端末が識別されて信頼できるように、支払いサービスに対して自身を証明するように設定されている、標準的な店頭端末であり得る。

店頭端末は、様々な形を取ることができる。例えば、店頭端末は、キーパッドおよびデータをユーザーに表示するための小型モニターを備えた単純な単独ユニットであり得る。その上、店頭端末は、１つだけの形式を使用すると言われてきたが、これは、２つの異なる物理装置を有するシステムを除外することを意図していない。例えば、既知の店頭端末は、販売員または小売業者に対する第１のインタフェースを１つの物理筐体上に、および別の物理筐体上に配置されたユーザーに対する別のインタフェースを含み得る。

既知の店頭端末の使用は、不正登録のリスクを減少させる。支払いサービスは、店頭端末のオペレータと特別な関係を持つことができるので、より高いレベルのセキュリティが登録プロセスに提供される。店頭端末のオペレータは、支払いサービスの認可された代理人であり得る。店頭端末のオペレータは、支払いサービスによって事前に選抜できる。さらに、支払いサービスは、店頭端末が、その端末の不正使用を突き止めるのを支援するために、特定の物理的な位置でのみ使用されることを要求し得る。支払いサービスは、その位置で銀行取引をするか、または買い物をする人々に支払いサービスを提供する条件で、端末が操作されている位置で、あるレベルの監視も要求し得る。既知の店頭端末によって提供される追加されたレベルの保護は、登録手続きが以下でより詳細に説明されるにつれてさらに明らかになる、追加の利益をもたらす。

ステップ１２０６で、個人識別情報が既知の店頭端末に送信される。この情報を配信する目的は、登録プロセスを進めるために、店頭端末のオペレータがユーザーの身分を確認するのを可能にするためである。端末に送信された情報は、ステップ１２０２で送信された問合せメッセージに応答して、登録手続きの初期部中に収集された情報であり得る。端末に送信された情報は、問合せに応答してユーザーにより直接提供された情報であり得るか、または確認ステップ１２０３中にユーザーによって提供された情報に基づきアクセスされた情報であり得る。例えば、ユーザーは、問合せに応答して運転免許証の番号を提供している可能性があり、ステップ１２０６でその同じ番号が既知の店頭端末に配信され得る。別の例として、ユーザーは、ユーザー名および誕生日などの他の個人識別情報にアクセスするために使用された政府識別番号を提供している可能性があり、その他の個人識別情報がステップ１２０６で既知の店頭端末に配信され得る。情報は、ユーザーの写真、ユーザーと関連付けられた生体認証データ、または店舗のポイント口座番号などの、その特定のユーザーを識別するために別の実体によって既に使用されている識別情報も含み得る。

登録手続きの初期段階でユーザーによって提供された情報と、登録手続きの第２段階に対して店頭端末に提供された情報を分離することは、顕著な利益をもたらす。店頭端末は安全であるので、支払いサービスは、この個人情報を確認のために、ユーザーを個人情報窃盗のリスクにさらすことなく、配信できる。さらに、政府識別番号が、機密度の低いデータにアクセスするために使用できるという事実は、支払いサービスに、ユーザーはその機密度のより高い情報にアクセスできるが、他方、店頭端末のオペレータはその情報へのアクセスを提供されていないことが分かっているという安心感を提供する。その結果、高度なセキュリティが支払いサービスプロバイダに提供されているが、他方、支払いシステムのネットワーク内のどのオペレータも機密度のより高い識別情報を提供されていないので、高度なセキュリティをユーザーにも提供する。

店頭端末のオペレータによって実行される確認手続きは、店頭端末に配信される情報の種類によって決まるであろう。例えば、配信された情報が運転免許証番号である場合、確認手続きは、オペレータがユーザーの免許証を物理的に検査すること、およびユーザーの身元を店頭端末によって提示されたインタフェースを介して確認することを伴うであろう。配信された情報がユーザーの姓名および誕生日である場合、確認手続きは、オペレータが、ユーザーが登録手続きの第１段階で識別されたのと同一人物であると確認できる、任意の適切な形式の本人確認を物理的に検査することを伴うであろう。

確認手続きは、さらなる識別情報を支払いサービスによる格納のためにユーザーから収集することも含むことができる。例えば、運転免許証番号が、既知の店頭端末に配信され得、確認手続きは、その運転免許証のスキャンされた画像を支払いサービスにアップロードすることを伴い得る。別の例として、生体認証情報が、ユーザーから既知の店頭端末において、指紋スキャン、ユーザーの顔写真、またはユーザーの網膜のスキャンの形で、収集できる。ユーザーの顔写真は次いで、将来、生体認証の形として画像処理技術と組み合わせて使用され得る。

図１２に戻り、ステップ１２０７で、更新された個人識別番号が既知の店頭端末から受信される。オペレータが、既知の店頭装置に提供された情報に基づきユーザーの身元を確認した後、オペレータは、ユーザーに、支払いサービスを使用する自分の将来の取引全てを認可するために適用できる個人識別番号（ＰＩＮ）などのコンパクト識別子を指定することを要求する手続きをトリガーするであろう。事実上、その手続きで、ユーザーは自分の一時的な確認コードを、支払いシステムで使用できる永久的なＰＩＮと交換するのを許可される。ＰＩＮの店頭端末から口座サーバーへの転送は、その番号がインターセプトされるのを防止するために暗号化できる。加えて、店頭端末のインタフェースは、ＰＩＮが入力されている時に、インタフェースの近くにいる、たちの悪い人達がＰＩＮを見るのを防ぐために、ＰＩＮの番号を見えないようにできる。ユーザーが自分のＰＩＮを設定するためにユーザーに配信される一連のインタフェース要素は、一般に、店頭端末のオペレータがユーザーの身元を確認するまで、ユーザーに対して利用可能にされない。例えば、端末に配信された個人識別データがユーザーの運転免許証番号であり得、店頭端末のオペレータが、ユーザーの免許証を物理的に検査して、そのユーザーが、口座登録手続きの第１段階中に識別された同一人物であると判断するまで、ＰＩＮ作成シーケンスが店頭端末で提供されない。この個人識別番号が受信されて格納された後、そのユーザーに対する登録手続きが完了する。何らかの他の形式のユーザーに関連した個人情報が代わりに支払いシステムに送信される場合、ステップ１２０７は要求されない可能性がある。例えば、既知の店頭端末で収集された任意の生体認証情報が、支払いサービスを使用するユーザーの将来の取引全てを認可するために将来において使用され得る。

ユーザーに対する情報の初期要求が電話音声チャネルを介して送信される支払いサービスにユーザーを登録するためのプロセスが、図１３および図１４を参照して説明できる。図１３は、支払いシステムのためにユーザーを確認するためのプロセス１３００を示す。図１４は、潜在的な口座名義人１４０１、顧客サービス担当者１４０２、および支払いサービスプラットフォーム１４０３間の関連したやりとりの動作図１４００を示す。ステップ１３０１で、登録を意図するメッセージが、ユーザーからテキストメッセージシステムを介して受信される。テキストメッセージシステムは、基本的なテキストメッセージング機能を有する任意の電話で利用でき、電話が、電子メール、または支払いサービスと通信するための専用アプリケーションなどのもっと複雑なメッセージング機能を有することを必要としない。このステップの例が、潜在的な口座名義人１４０１と支払いサービスプラットフォーム１４０３との間の動作的なつながりを示す、図１４における動作フロー線１４０４として示されている。

プロセス１３００のステップ１３０２で、人間の顧客サービス担当者が、個人情報をユーザーから得るためにユーザーに電話をして、登録プロセスを継続する。個人情報は、マネーローンダリングまたは商業的支払い処理規制に準拠するために必要なＫＹＣ詳細を含むことができる。このステップの例が、顧客サービス担当者１４０２と潜在的なユーザー１４０１との間の動作的なつながりを示す、図１４における動作フロー線１４０５として示されている。顧客サービス担当者１４０２は、支払いサービスプラットフォーム１４０３によって生成された通知のために、口座名義人１４０１に連絡すべきことを知るであろう。例えば、支払いサービスプラットフォームは、顧客サービス担当者１４０２に対するタスクリストを更新し得るか、または、顧客サービス担当者が電話すべき潜在的なユーザーの連続するキューを有するように、顧客サービス担当者１４０２に割り当てられた電話から潜在的なユーザー１４０１への電話を自動的に開始し得る。潜在的なユーザーの電話番号は、登録を意図するメッセージから取られ得るか、ユーザーによって提供されてテキストメッセージ自体の一部として入力され得るか、またはユーザーからのテキストメッセージで提供された他の識別情報に基づき支払いサービスプラットフォーム１４０３によって識別され得る。

ステップ１３０３で、顧客サービス担当者は、電話でユーザーから得た個人情報を使用して、そのユーザーを支払いシステムに登録する。このステップの例が、顧客サービス担当者１４０２と支払いサービスプラットフォーム１４０３との間の動作的なつながりを示す、図１４における動作フロー線１４０７として示されている。潜在的なユーザー１４０１から取得される個人情報は、ウェブベースポータルなどの様々なポータルを使用して顧客サービス担当者１４０２によって入力できるので、動作フロー図は、ポータル１４０６を含む。ポータル１４０６が、インターネットを介して一般の人が利用可能な標準的なウェブポータルである状況に対して特定の利益が生じる。ユーザー１４０１は、口座を開設するために必要な個人情報を便利に入力するためのウェブポータルのインスタンスを生成できる高機能装置にアクセスできない可能性がある。しかし、支払いサービスの他の潜在的なユーザーは、代わりに、自分の個人情報をウェブポータルを介して直接入力できるユーザーに焦点を合わせる異なる方法を使用して、支払いシステムに登録することができ得る。同じウェブポータルが、両方の種類の潜在的なユーザーを登録するために使用される場合、全体的な支払いシステムは、ユーザーあたりのコストの著しい削減を達成できる。実際には、顧客サービス担当者１４０２は、口座名義人１４０１にポータル１４０６の使用をごく短期間−ユーザー１４０１に、個人情報の長い文字列を、基本的な携帯電話の制限されたユーザー入力インタフェースで入力する厄介なプロセスを課す必要なく、要求された個人情報を潜在的なユーザー１４０１から収集するのにちょうど十分な長さ−貸しているであろう。

一旦、個人情報が顧客サービス担当者によって入力されると、ステップ１３０４で支払いサービスが一時的な確認コードをテキストメッセージを介してユーザーに送信する。このステップの例が、一時的な確認コードが支払いサービスプラットフォーム１４０３からユーザー１４０１に送信される、動作フロー線１４０８として示されている。顧客サービス担当者１４０２はまた、一時的な確認コード情報をポータル１４０６を介して受信し、その情報を電話を通してユーザー１４０１に伝達し得る。しかし、一時的なコードがＳＭＳを介して直接ユーザーに送信されるプロセスに対して、ある利益が生じる。第１に、登録プロセスを実施している人物が、口座が開かれている名前の人物と同一人物であることを保証するために、さらなるレベルの確実性を提供する、一時的な認可コードが、ユーザーの携帯電話に送信される。第２に、顧客サービス担当者は、たとえ彼らが、自分自身の名前で口座を開いているユーザーが利用し得るのと同じポータルを使用していても、一時的な登録コードにさらされない。これは、潜在的なユーザーに対して別のレベルのセキュリティを提供し、ユーザーを直接登録するため、および顧客サービス担当者１４０２を通して登録するために、同じウェブポータルを使用する有用性も向上させる。

図１３に戻ると、プロセス１３００は、登録プロセスの第２段階が図１２を参照して説明されたのと同様に、登録プロセスの第２段階を扱う。ステップ１３０５で、一時的な登録コードが事前承認された店頭端末を介してユーザーから受信される。前述のように、ユーザーは、支払いシステムを使用して何かを購入するか、口座に入金するか、または、単に口座を登録しようとすることを含め、支払いシステムを伴う何らかの他の種類の取引を実施しようと試みている。ステップ１３０６で、ステップ１３０２で収集された個人情報の一部が、端末のオペレータによるユーザーの身元の確認、およびユーザーからの追加情報の潜在的な収集を容易にするために、端末に提供される。ステップ１３０７で、ユーザーが、ステップ１３０２で得られたＫＹＣ詳細と一致することを承認する確認が、端末オペレータから受信される。このステップは、前述のように、オペレータが、端末に配信された情報を、ユーザーによって提供された物理的な形式の本人確認に対して確認することを含み得る。本ステップは、オペレータが潜在的なユーザーに、一致する情報をオペレータに口頭で提供するように尋ねることも含み得る。これらのアプローチは、一般に、個人情報が配信されたインタフェースが、潜在的なユーザーから分離されていることを必要とし得る。このステップは、ユーザーから収集された任意の追加情報の支払いシステムへの配信も伴い得る。ステップ１３０８で、永久的な登録コードが、ユーザーによって支払いシステムに提供されて、個人情報が提供されたのと同じ店頭端末を介して支払いシステムを使用する、さらなる取引を実行するためにユーザーによって使用される。永久的な登録コードは、ユーザーによって選択されるか、または店頭端末によってランダムに選択されて、支払いサービスに配信され得る。

プロセス１３００および１２００は、近距離無線通信（ＮＦＣ）タグをユーザーに発行することも含み得る。ＮＦＣタグは、小売業者の販促プログラムと関連付けられ得るか、または支払いサービスプロバイダによって店頭端末のオペレータに提供され得る。ＮＦＣタグは、店頭端末が、ユーザーによって提供された永久的なＰＩＮを格納できるように、店頭端末で符号化され得る。ユーザーは次いで、店頭端末において単に読み取り装置の近くで自分のＮＦＣタグを通すことにより自分のＰＩＮを入力することができ得る。代替方法では、永久的なＰＩＮは、ユーザーによって設定可能ではなかったＮＦＣタグと関連付けられた識別子であり得る。ＮＦＣタグは、例えば、製造時またはエンドユーザーに配達される前に焼き付けられた番号を有し得る。この番号は、店頭端末のオペレータによって提供され得るが、登録の最終部分は、その番号がユーザーと関連付けられて、支払いサービスデータベースに登録されるように、完了されている。ＮＦＣタグの番号がユーザーに発行される前に誰もその番号を得ることができないように、登録手続きが完了するまで、ＮＦＣタグに関連付けられた番号がアクセスからロックされ得るので、このアプローチは、ある利益をもたらし得る。例えば、ＮＦＣタグの識別子は、ステップ１３０８で、店頭端末のオペレータによって機械に通されて、端末オペレータが関連付けられた識別子を決して見ることなく、関連付けられた番号が支払いサービスに送信され得る。

プロセス１３００の一実施態様が、図１５を参照して説明できる。図１５は、登録プロセスが、人間の顧客サービス担当者を使うことなく実行される、動作フロー図１５００を示す。この手続きは、自動化システムがユーザーをより迅速にシステムに追加することができ、人間の従業員または請負業者を必要としないので、支払いサービスに対してユーザーあたりの追加の費用対効果をもたらし得る。動作フロー図１５００は、潜在的な口座名義人１５０１、支払いサービスプラットフォーム１５０３、および外部の確認データベース１５０４の間での動作的なつながりを示す。

フロー図１５００によって示されるプロセスは、フロー線１４０５および１４０７がフロー線１５０６および１５０７と置き換えられているので、フロー図１４００におけるプロセスと最も顕著に異なっている。動作フロー線１５０５は、フロー線１４０４を参照して説明されたのと同じ登録を意図するメッセージを伴い得る。しかし、動作フロー線１５０６は、人間の顧客サービス担当者からの電話の代わりに、支払いサービスプラットフォーム１５０３によって制御される自動化システムからユーザー１５０１への電話を伴う。自動化システムは、登録を意図するメッセージの処理後、直ちに電話をトリガーできるか、または通話時間の費用が最低額の時など、指定されたスケジュールに従って電話することができる。動作フロー線１５０６は、政府識別番号または何らかの他の形式の個人識別情報に対する要求を伴う。例えば、要求は、納税者参照番号または社会保障番号に対するものであり得る。動作フロー線１５０７は、潜在的なユーザー１５０１から支払いサービスプラットフォーム１５０３への要求された情報の配信を伴う。情報は、キーパッドまたは双方向音声応答システムを介して情報を入力するユーザー１５０１によって提供され得る。

動作フロー線１５０７の後、フロー図１５００は、図示された様々なステップに進み得る。例えば、ステップ１５０７で取得された情報が直接店頭端末に送信するのに安全であった場合、情報は、登録プロセスの次の段階のために格納され得、手続きは、一時的な登録コードが支払いサービスプラットフォーム１５０３を介してユーザー１５０１に配信されるステップ１５１０に直接移動でき得る。この動作フロー線に従って送信された情報は、動作フロー線１４０８に従って送信された情報と一致し得る。ステップ１５０７で提供された情報が、ＫＹＣ要件を満足するのを確認される必要があったか、または異なるセットの個人情報を取得するため、データベースにアクセスするために使用される必要があった場合、動作フローは動作フロー線１５０８を継続し得る。動作フロー線１５０８で、動作フロー線１５０７で提供された情報が支払いサービスプラットフォーム１５０３から外部データベース１５０４に送信される。例えば、ステップ１５０７で取得された情報は、納税者登録番号であり得、外部データベース１５０４は政府精選データベースであり得る。動作フロー線１５０９で、ユーザーを識別する追加の個人情報が、外部データベース１５０４から支払いサービスプラットフォーム１５０３に対してダウンロードされ得る。この情報は、潜在的なユーザーの姓名およびユーザーの誕生日を含み得る。しかし、追加情報は、外部データベース１５０４によって提供される必要はなく、動作フロー線１５０９は単に、動作フロー線１５０８で提供されたデータを確認する確認応答を含み得る。動作フロー図１４００も、動作フロー線１４０７と１４０９との間に支払いサービスプラットフォーム１４０４によって使用され得る外部データベースを含み得るが、その特定のプロセスの他の特徴を強調するためにその図では省略されたことに留意されたい。

支払いシステムの潜在的なユーザーを一括登録するプロセス１６００は図１６を参照して説明できる。プロセス１６００は、ユーザー識別情報の一括アップロードを特定の金融機関から受信するステップ１６０１を含む。データをアップロードすることにより、金融機関は支払いサービスに加わっていて、自身の顧客を支払いサービスに移行させるのに関心があるか、または少なくとも支払いサービスをオプションとして自身の顧客に提供したいと欲している。一括アップロードは、支払いシステムのサーバーと金融機関のサーバーとの間の安全なネットワーク接続によって提供され得る。一括アップロードはまた、１５０などの外部の確認ソースを介して提供されて、口座サーバー１３０にネットワーク１２０を経由して提供され得る。一括アップロードは、政府機関または会社に所属している特定の人々に、支払いサービスを備えた口座を提供することに関心のある政府機関または会社によって提供され得る。例えば、政府機関は社会福祉受益者に口座を提供することを欲し得るか、または会社は口座をその従業員に提供することを欲し得る。ユーザー識別情報は、ユーザーの名前および口座番号を含むことができる。ユーザー識別情報は、ユーザーの各々と関連付けられた携帯電話番号のセットも含み得る。

プロセス１６００はステップ１６０２に進み、そこで、一時的な確認コードが、ステップ１６０１で識別情報が支払いサービスに提供された、各ユーザーに送信される。一時的な確認コードは、テキストメッセージを介してユーザーに送信され得る。ステップ１６０１で携帯電話データが提供された場合、その携帯電話データがステップ１６０２でテキストメッセージを送信するために使用され得る。プロセス１６００の特定の実施態様では、一時的な確認コードは、携帯電話番号が提供されたユーザーのみなど、ステップ１６０１で一括アップロード情報が提供されたユーザーの制限された一部に送信され得る。

一時的な確認コードは、支払いシステムに登録するためのインセンティブと共に送信され得る。インセンティブは、一時的な確認コードと同じテキストメッセージで送信され得る。テキストメッセージは、一時的な確認コードを既知の店頭端末を有する場所で提供する際に、現金で引き換えられる金銭支払いに対するオファーを含み得る。テキストメッセージは、支払いサービスを使用する取引手数料の一時的な割引に対するオファーも含み得る。テキストメッセージは、限られた期間内での支払いシステムへの各新規登録者がくじ引きの参加者であるくじ引きへの参加に対するオファーも含み得る。くじ引きの賞は、当選した参加者に関連付けられた支払いサービス口座に預入れされるお金であり得る。

プロセス１６００は次いで、プロセス１２００のステップ１２０５、１２０６、および１２０７、またはプロセス１３００のステップ１３０５、１３０６、１３０７、および１３０８と大部分が合致するステップに進む。これらのステップは、プロセス１６００で、まとめてステップ１６０３と示されている。対応するステップが、ユーザー１７０１、店頭端末１７０２、および支払いサービスプラットフォーム１７０３を伴う登録手続きの第２段階を示す、図１７の動作フロー図１７００によって示されている。フロー図１７００は、口座名義人が購入、現金引き出し、または入金取引を開始する、動作フロー線１７０４から始まる。これには、店頭端末オペレータが、ユーザー１７０１によって提供された情報をもつ店頭端末に提供された識別情報を使用してユーザーの身元を確認する、プロセス１７０５が続く。ユーザーの身元が確認されると、店頭端末オペレータは操作を動作フロー線１７０６に進めるのを許可し、そこで、永久的なＰＩＮがユーザー１７０１により店頭端末で作成される。この動作フロー線は、追加で、または選択的に、ユーザーからの生体認証情報の収集を含み得る。この時点で、プロセスは、所定のＰＩＮ番号の付いたＮＦＣタグが発行されること、またはユーザーによる店頭端末のキーパッド上でのパーソナライズ番号の入力も含み得る。次に、動作フロー線１７０７によって示されるように、永久的なＰＩＮおよび／または生体認証情報が店頭端末１７０２から支払いサービスプラットフォーム１７０３に送信される。このステップは、ＰＩＮがユーザーによって入力されて、支払いサービスプラットフォーム１７０３に安全に送信されることを含むことができるか、またはＮＦＣタグ識別子が店頭端末１７０２上のＮＦＣ読取り装置によって読み取られて、支払いサービスプラットフォーム１７０３に安全に送信されることを含むことができる。最後に、ユーザーの口座が作成されたことを承認する確認メッセージが、ＳＭＳを介してユーザーに送信され得る。この最終ステップがプロセスフロー線１７０８によって示されている。

新規ユーザーがシステムに登録されると、ユーザーは、支払いシステムを、彼らのデータが提供された金融機関によって保持されている口座と組み合わせて使用することが可能であり得る。例えば、登録後、支払いシステムを使用する任意の支払いは、金融機関での口座が支払いに関係することができるだけ十分な資金または与信枠を有していることを確認した承認を店頭端末に送信することを伴い得る。支払いシステムと関連付けられた他の種類の口座も、それらが登録されるとすぐに資金または与信枠を含み得る。例えば、政府機関は、口座が支払いシステムに登録されるとすぐに口座名義人がお金を利用できるように、支払いシステムと関連付けられた口座に資金を提供している可能性がある。同様に、一括アップロード情報を提供する任意の実体は、ユーザーが登録を完了するとすぐに取引を実施するために口座が直ちに使用できるように、支払いシステムの潜在的なユーザーに対して口座を資金または与信枠で事前設定している可能性がある。取引に対する支払いを達成することは、リアルタイムで口座間で送金することを含み得る。支払いを達成することはまた、店頭端末オペレータ、支払いサービス、および金融機関を伴うバッチ決済プロセス中に、承認を提供すること、および次いで、その後に口座間で送金することを含み得る。

前述した登録手続きのある態様は、支払いサービスが不正取引にさらされるのを制限しながら、ユーザーの代わりに効率的に送金するのを可能にする支払いサービスを備えた口座をユーザーが得るのを可能にする。前述した登録手続きのこれらの態様は、外部金融機関と関連付けられている口座（例えば、口座１３６はそれ自体、銀行口座ではないが、支払いサービスによって管理されて銀行口座と関連付けることができる）を基本としたアプローチ群を形成する。それらのアプローチのいくつかでは、ユーザーが絶対に外部資金振替情報を支払いサービスに提供する必要なく、ユーザーの身元が確認されて、そのユーザーに対する口座が作成される。外部資金振替情報の例は、クレジットカード口座番号とセキュリティコード、当座預金口座番号とＡＣＨ銀行支店コード、電信振替サービスを有するオンライン銀行口座に対するユーザー名とパスワードの組合せ、または一般に、資金を、支払いシステムの外部へ、支払いシステムから、もしくは支払いシステムに送金するために使用できる任意の情報を含む。支払いサービスは、支払いサービスによって管理される資金の総額を超える損失に対して有限責任を負うので、これらのアプローチに顕著な利益が生じる。外部資金振替情報を支払いサービスによって管理されるシステム内に決して格納しないことにより、支払いサービスは、その金融債務がいつでも支払いサービスと実際に関連付けられている資金までになるように、金融債務を最小限にできる。あるアプローチでは、特定のユーザーの代わりに送金できる資金の額が、ユーザーの身元に関して支払いシステムに提供された確実性の程度によって設定される。前述のように、異なる制限が、口座登録手続き中に口座申込者によって提供された本人確認のレベルに基づき、口座に設定できる。

前段落で要約したアプローチは、トークン化の使用を通して実装でき、トークン化では、外部資金振替情報を表すトークンが、外部資金振替情報自体の代わりに金融機関から支払いサービスに提供される。トークンは、支払いサービスのメッセージチャネルおよびデータ記憶システムへの最新の攻撃でさえアクセスできない、ＣＯＤＥＣなどの、トークン化ツールを使用して、生成および／または復号できる。特定のアプローチでは、トークン化ツールは、支払いサービスがトークンを復号する手段を決して保持しないように、外部資金源情報と関連付けられた金融機関専用であろう。他の実施形態では、トークン化ツールは、支払いサービスによって開発され得るが、電子的に侵害されにくい安全なチャネルを通して、支払いサービスと関連付けられた金融機関に配信されるであろう。例えば、金融機関と支払いサービスが取引関係に入る時、ＣＯＤＥＣが、支払いサービスによって所有されている、ネットワークから分離されたマシンによって生成されて、物理的な配達サービスにより手で運ばれた記憶装置上で金融機関に配達され得る。エンドユーザーへの配信前の、インターネット、または潜在的に侵害され得る任意のネットワークから完全に隔離された方法でのトークン化ツールの配達は、ネットワークから分離されたチャネル上での配達と呼ぶことができる。

前述したある登録方法は、特に、支払いサービスが外部資金振替情報を絶対に扱う必要がないようにする方法で、外部金融機関と関連付けられている口座を作成する助けとなる。具体的には、有効にされる口座のセットを準備するために、識別情報の一括アップロードが金融機関から支払いサービスに提供される、図１６を参照して説明されたアプローチは、ステップ１６０１で、どの情報が支払いサービスのサーバーにアップロードされるかを制御することにより、支払いサービスが外部資金源情報を扱うのを防ぐことができる。また、図１２および図１３を参照して説明されたアプローチも、支払いサービスが、外部資金振替情報に触れることなく、メンバーを登録するのを可能にする。これら全ての状況で、支払いサービスが、外部資金振替情報をユーザーから受信することなく新規口座名義人を登録するためのポータルとして機能することができ、一方でそれと同時に、支払いサービスおよび金融機関の両方がユーザーの身元を都合よく確認することができる。一旦、ユーザーの身元がこれらのアプローチに従って確認されると、金融機関は、口座名義人の代わりに取引を実施するために、トークンを支払いサービスに発行できる。支払いサービスは従って、金融機関の外部資金振替情報へのアクセスを絶対に得ることなく、まだ、支払いサービスに対する初期段階の登録および支払い処理を取り扱うことができる。

金融機関の代わりに支払いサービスに発行されるトークンは、図２を参照して説明された口座制限を実装するために利用できる。かかるアプローチは、不正取引にさらされる程度が支払いサービスのためにさらに制限できるので、支払いサービスに対してさらなる利益および柔軟性を提供し得る。外部資金振替情報のトークン化は、たちの悪い人達がその情報を取得して支払いシステムの外部で送金するのを防ぐが、トークンを取得することと支払いサービスの振替システムを乗っ取ることの両方を行うことができる人は依然として、支払いシステム内で、次いで別の口座を通じて外部へ、不正に送金を行うことが可能であり得る。図２の口座制限アプローチが適用された場合、これらの種類の攻撃が弱められ得る。図２および図３を参照すると、制限１３６の範囲内であった口座１３５からの振替だけをトークンが認可できるように、トークンがステップ２４０の一部として発行され得る。例えば、トークンは、所与の日に＄１００相当の振替のみを許可でき、口座名義人はその結果、振替を見つけてさらなる損失を防ぐために丸一日持ち得る。

図１６の一括アップロード登録アプローチをもつ、外部資金源情報のトークン化を利用する特定のアプローチが、図１８を参照して説明できる。図１８は、ユーザーを支払いサービスに登録するための方法１８００を示す。ステップ１８０１で、ユーザー識別情報の一括アップロードが支払いサービスによって受信される。識別情報は、各ユーザーが口座を有する金融機関から受信される。ステップ１８０１は、方法１６００からのステップ１６０１の特性を示し得る。識別情報は携帯電話番号を含み得る。識別情報は、政府識別番号などの、ユーザーからの非公開のユーザー識別情報の任意の一部、または金融機関およびユーザーが以前に選択した秘密の質問に対する応答を含み得る。実際には、非公開の識別情報は、金融機関とユーザーとの間で共有された任意の種類の機密情報であり得る。しかし、方法１８００における非公開の識別情報は、金融機関と関連付けられた外部資金振替情報にできない。ステップ１８０１で受信された識別情報は、ステップ１８０２でユーザーの身元を確認するために使用される。一旦、ユーザーの身元が確認されると、ステップ１８０３で、支払いサービスがユーザーに対するトークンを金融機関から要求する。しかし、トークンに対する要求は送信もでき、識別情報が最初に受信された後であるが、ユーザーの身元が確認される前に、トークンが金融機関から受信できる。かかる状況では、ユーザーの身元が確認されるまで口座が有効にされないであろうが、トークンは既に支払いサービスによる使用のために利用可能であろう。トークンは、トークン化された外部資金振替情報を含み得る。要求に応答して、トークンが生成され、トークンをユーザーと関連付ける方法で支払いシステムのサーバー上での格納のために支払いサービスに返される。ステップ１８０４で、支払いサービスは、振替要求と共にトークンを金融機関に送信することにより、ユーザーの代わりに振替を開始できる。

トークンは、ステップ１８０３での要求に応答して様々な方法で生成できる。トークンは、金融機関自身によって生成され得るか、または金融機関の代わりに第３者によって生成され得る。トークンは、支払いサービスによって開発されたか、または標準化された、トークン化ツールを使用して生成され得る。支払いサービスによって開発されたか、または標準化されたトークン化ツールを伴うアプローチは、支払いサービスが、複数の金融機関と関連付けられた状況で、支払いサービスと各金融機関との間の取引チャネルがそれにより、標準化に対しても対応可能であり得るという点において、ある利益を示し得る。支払いサービスは、複数のトークン記憶および配信システムを管理する必要もなく、代わりに、ネットワークと関連付けられた金融機関の全てに対応する１つのシステムを使用し得る。支払いサービスにトークン化ツールを生成させることに関連した潜在的な問題は、トークン化ツールおよびトークンの両方が支払いサービスから盗まれ得ることである。そのため、トークン化ツールが支払いサービスによって開発されるアプローチでは、支払いサービスの内部システムへの成功した攻撃が、トークンおよびトークン化ツール自体の両方を危険にさらさないように、トークン化ツールが、外部ネットワークから分離されているシステムを使用して開発されることを要求する。同じ理由から、かかるアプローチは、トークン化ツールが、安全な配達サービスによる手渡しまたは支払いサービスの従業員による手渡しなどの、ネットワークから分離されたチャネルを使用して配達されることを要求する。トークンは同様に、金融機関専用のトークン化ツールによって生成され得、従って、支払いサービスに知られていない。トークン化ツールは、そのツールが安全であり、支払いサービス自体がそのツールを提供されている限り、実体のネットワークによっても共有され得る。

ユーザーの身元を確認するステップ１８０２は、様々な方法で実行できる。いくつかのアプローチでは、方法１８００は、非公開の識別情報を受信するステップ１８０５を含むことができる。非公開情報は、その機密度のレベルとして見なされる特性を有する。機密度のレベルは、情報と関連付けられたプライバシーの度合いを反映し、それにより、指紋パターン、社会保障番号、または金融機関によってその口座名義人に提供されたコードなどの、個人に関する非公開の事実が高レベルの機密度を有し得、運転免許証番号は中レベルの機密度を有し得、他方、ユーザーの自宅住所は低レベルの機密度を有し得る。ステップ１８０６で、この非公開の識別情報が、ユーザー識別情報の一括アップロードに対して比較され、２つの値が一致すれば、ユーザーの身元が確認される。その情報は、ステップ１８０５で、電話、テキストメッセージ、ウェブインタフェース、または対面取引など、任意のチャネルを使用して受け取ることができる。

ステップ１８０２の代替バージョンが、ステップ１６０２と同様に一時的なコードをユーザーに送信することを含むステップ１８０７から始まる。ステップ１６０２と同様、このステップは、ステップ１８０１でアップロードされた情報に含まれていた携帯電話番号を使用して実施され得る。ステップ１８０２のこのバージョンは、次いで、一時的なコードが、確認手続きを完了するプロセスで使用される、ステップ１８０８で完了し得る。ステップ１８０８は、図１２のステップ１２０５から１２０７または図１３のステップ１３０５から１３０７に従って実行され得る。具体的には、ステップ１８０８は、一時的な確認コードを既知の店頭端末から受け取ることを含み得る。一時的な確認コードの受信は、ステップ１８０１でアップロードされた識別情報の一部の、既知の店頭端末への配信をトリガーし得る。その情報の既知の店頭端末への配信は、ユーザーの身元を、例えば、政府発行の身分証明書を調べることにより、直接確認するために使用され得る。これらの特定のアプローチでは、ステップ１８０８は、ユーザーの身元を確認したという確認を既知の店頭端末のオペレータから受信することも含み得る。一時的な確認コードの受信はまた、既知の店頭端末に、網膜スキャン、指紋取得、またはステップ１８０１でアップロードされた画像との画像照合のためのユーザーの顔写真など、支払いサービスによる確認のために生体認証入力プロセスを開始するように促し得る。

ステップ１８０３での要求に応答して配信されるトークンは制限的であり得る。口座の制限的な特質が、口座１３５の使用に関する制限１３６を実装するために使用できる。例えば、トークンは、所定回数の使用に制限され得るか、所与の期間中に所定回数の使用に制限され得るか、出金ではなく支払いシステムへの送金のためだけに使用され得るか、残高がなくなるまで所定ドル数の金額の振替に制限され得るか、または、次の期間の開始時にチャージする必要があるまで所与の期間中に所定ドル数の金額の振替に制限され得る。

トークンが口座を制限する度合いは、ステップ１８０２が実行された方法によって決まり得る。例えば、制限の程度は、ステップ１８０５および１８０６で利用された非公開情報の機密度のレベルに基づき得る。非公開情報の機密度のレベルは、その結果、各量のレベルにおける異なる段階が、口座に課される制限の異なる段階となるという意味において、図２で前述したように身元確認のレベルに類似し得る。制限の程度と情報の機密度のレベルとの間の関係は、支払いサービスまたは金融機関によって設定され得る。複数の金融機関を有する支払いサービス内の異なる金融機関は、各々、金融機関によって要求されるセキュリティのレベルに基づき、情報と制限の程度との間の異なる関係を有し得る。

ステップ１８０６での比較のためにステップ１８０１で口座名義人の住所だけをアップロードする用意があった金融機関は、自身のユーザーに支払いサービスを通じてかなりの程度制限された口座のみを提供するのを許可され得るように、支払いサービスは、機密度のあるレベルを有する非公開情報に対して要求される最低限の制限を設定し得るが、ステップ１８０６での比較のためにステップ１８０１で口座名義人の社会保障番号をアップロードした金融機関は、自身のユーザーに、そのトークンがいかなる制限も有していない口座を提供するのを許可され得る。

トークンが口座を制限する程度は、ステップ１８０８が実行された方法にも基づき得る。制限の程度は、一時的なコードが受け取られたチャネルによって影響され得る。一時的なコードがウェブポータルまたは自動電話サービスを通して受け取られた場合、トークンは、口座を高い程度まで制限し得るが、他方、一時的なコードが既知の店頭端末を通して受け取られた場合、制限の程度ははるかに低いであろう。制限の程度は、ユーザーの身元を確認するために使用された既知の店頭端末の状態によっても影響され得る。例えば、不正が起こりやすいか、または以前に不正な口座を作るために使用されたことのあるエリア内の既知の店頭端末は、高度に制限的なトークンをもつ口座を作成するためにだけ使用され得る。前述のように、制限の程度は、既知の店頭端末のオペレータによって実行されたＫＹＣ手続きによって提供された確認のレベルによっても影響され得る。例えば、免許証が提示され、店頭端末のオペレータによって調べられて視覚的に確認された場合、トークンは中程度まで制限し得、他方、免許証がスキャンされて確認のために支払いサービスに送信された場合、トークンは全く制限しないであろう。

支払いサービスのユーザーに対して口座を登録するためのプロセス１９００が、図１９を参照して説明できる。方法１８００と対照的に、方法１９００は、金融機関に、新規口座名義人に対する登録を受け入れるために支払いサービスを準備するように要求しない。代わりに、プロセス１９００は、ユーザーに、口座を有する金融機関を確認するのを委ねる。特定のアプローチでは、金融機関が支払いサービスに対するトークンを生成して、支払いサービス一般の必要な登録フローを辿る準備ができているように、金融機関は、支払いサービスと事前に確立された関係を有する金融機関である必要がある。プロセス１９００は、登録を意図するメッセージがユーザーから受信される、ステップ１９０１から始まる。本明細書で以前に開示した他の方法と同様に、この登録を意図するメッセージは、携帯電話を介して送信されるテキストメッセージを含め、多数のチャネルから受信され得る。しかし、本明細書で説明した他のアプローチとは異なり、ステップ１９００は、プロセスがユーザー識別情報および金融機関識別子をユーザーから要求する、ステップ１９０２および１９０３が続く。これらのステップは、いずれの順番でも実行でき、同時にも実行できる。金融機関識別子および識別データが、ステップ１２０２および１３０２を参照して説明された手続きを使用して取得できる。例えば、支払いサービスの従業員が、ステップ１９０２および１９０３に対する情報を得るためにユーザーに電話し得る。情報を入力するためにウェブポータルが使用される場合、支払いサービスに対応する金融機関を表示するプロンプトに応答して、金融機関識別子が受信され得る。ユーザーがテキストインタフェースを介して促されている状況では、識別子は、ユーザーが入力すると、支払いサービスと関連付けられている利用可能な金融機関が自動的に記入できる、テキストボックスに応答しても受信され得る。

プロセス１９００は、一時的な確認コードがユーザーに送信されるステップ１９０４に進む。このステップに先行して、ステップ１９０２で受信された識別情報が確認され得る。識別情報は、外部データベースに対して確認され得る。具体的には、確認ステップは、ステップ１２０３に従って実施できる。識別情報の確認に使用される第３者データベースは、政府データベースまたは金融機関データベースであり得る。かかるアプローチでは、金融機関は、支払いサービスの有用性を自分の顧客に提供したいため、支払いサービスに、確認目的のためにそのデータベースへのアクセスを提供する意欲があるので、金融機関は、有益に、ステップ１９０３で識別された金融機関であり得る。どちらのアプローチでも、金融機関データベースの管理者が、データを確認するために識別データを支払いサービスから取得して、支払いサービスに金融機関のデータベースへのアクセスを提供するのを回避し得ることに留意すべきである。支払いサービスは一般に、金融機関によって保持されている外部資金振替情報を支払いサービスからさらに分離するために、かかるデータベースへの直接アクセスを与えられるべきでない。

プロセス１９００は、トークンが支払いサービスにより金融機関から受信されるステップ１９０６で終了する。トークンは、前述のように、トークン化された外部資金振替情報を含む。トークンは、確認ステップ１９０５が完了した後に送信できる。例えば、ステップ１９０５は、既知の店頭端末から身元確認済みメッセージを受信することを含み得、ステップ１９０６で配信されるトークンは、支払いサービスが口座名義人の身元を確認した後、支払いサービスに配信され得る。結果として、支払いサービスは、トークン化された情報が支払いサービスに対して有用であると判断される前に、外部資金振替情報のトークン化バージョンでさえ受信しないようにされる。逆に、関連付けられたユーザー口座が有効にされる場合にトークンが支払いサービスによる即時使用のために利用可能になるように、トークンは、確認ステップ１９０５の完了前に送信できる。

ユーザーを支払いサービスに登録するためのプロセス２０００が、図２０を参照して説明できる。本プロセスは、識別情報を既知の端末に送信するステップ２００１を含む。端末は前述のように既知の店頭端末であり得る。しかし、端末は店頭取引のために利用される必要はない。例えば、既知の端末は、プロセス２０００を完了するためだけに確保されて、支払いサービスの認可された代理人によってのみ操作され得る。識別情報は、ステップ１３０６および１２０６で送信された識別情報であり得る。プロセス２０００は、身元確認済みメッセージを既知の端末から受信するステップ２００２に進む。身元確認済みメッセージは、端末のオペレータが、ステップ２００１で送信された情報を使用して、潜在的な口座名義人の身元を確認したことを確認するであろう。ステップ２００３で、トークン化された外部資金振替情報を含むトークンが、身元確認済みメッセージの受信後に、金融機関によって受信される。金融機関は、ユーザーが既に口座を有していた金融機関であり得るか、または支払いサービスを通してユーザーと新しい関係を始めている金融機関であり得る。金融機関がそのユーザーに対して以前に口座を開設していなかった場合、金融機関は、ステップ２００３トークンを送信する前に、口座を開設するであろう。

ステップ２００３で受信されたトークンは、ある制限を口座に課すので、無制限のトークンではない。制限は、口座を所定ドル数の金額の振替に制限するか、または、口座が支払いシステムの外部へ送金するのを制限するなど、前述した特性のいずれかを取り得る。この制限の程度は、ステップ２００１と２００２との間でユーザーの身元を確認するためにどのタイプのＫＹＣ手続きが実行されたかに基づき得る。この制限の程度は、前述した情報の機密度のレベルと一致し、この特徴によって、身元証明文書をスキャンしてそれを身元確認済みメッセージに含めると、高レベルの確実性を提供し、従って、ステップ２００３であまり制限のないトークンが送信されることになるが、他方、政府識別番号を送信して、端末のオペレータにユーザーの身元証明文書を調べることによりユーザーの身元を確認させるだけでは、低レベルの確実性を提供し、従って、ステップ２００３でより制限的なトークンが送信されることになる。そのため、ステップ２００２で受信された身元確認済みメッセージは、支払いサービスおよび金融機関が、どの程度の制限をトークンが口座に課すべきかを知り得るように、どのタイプのＫＹＣ手続きが実行されたかを示す。

身元確認済みメッセージは、どの手続きが実行されたかを示す、端末のオペレータからの明確なメッセージを含み得る。例えば、オペレータは、身元確認済みメッセージを準備する際に、ユーザーの指紋を確認したか、または政府発行の身分証明書だけを確認したかを選択する必要があり得る。身元確認済みメッセージが特定のオペレータから受信される度に、支払いサービスがどのＫＹＣ手続きが適用されたかを知り得るように、身元確認済みメッセージは、端末のオペレータと支払いサービスとの間で事前に設定された取り決めに基づき、どの手続きが使用されたかも暗黙的に示し得る。

識別情報は、金融機関で保持されている口座の口座番号を含み得る。このアプローチは、好ましくは、端末および金融機関がトークン化情報のためのＣＯＤＥＣを共有したシステムと組み合わされ得る。この場合、支払いサービスは、ステップ２００１でトークン化された形式の識別情報を端末に配信し得る。トークンは、任意の取引を認可するために使用されず、代わりに、端末のオペレータが身元確認済みメッセージ２００２を生成するために使用され得るだけなので、トークンは、好ましくは、十分に制限されたものであり得る。この手続きの結果として、確認ステップ２００２は、ユーザーは彼らが口座番号を知っていることが分かっているので、金融機関に対して高程度の確実性を含み得る。ユーザーは既に口座番号自体を有しているので、事実上、支払いサービスにトークン化された形式の口座番号をユーザーの代わりに提供することにリスクはない。確認情報は、その情報を端末のオペレータによる観察または後の発見から分離された方法で、端末に送信され得る。例えば、確認情報は、一時的に格納された値を、ＫＹＣ手続き中にユーザーによって入力されたものと比較し得る比較器回路によってのみアクセスできる、端末上のメモリ内に一時的に格納され得る。このメモリは、次いで、成功した確認または確認における一定数の失敗した試みに続いて、パージされ得る。このアプローチは、金融機関が既に、それらの取引を処理するために独自のＣＯＤＥＣを使用する端末のネットワークを有していた状況を含め、様々な状況で実装できる。

前述の説明は、本発明の態様が実装され得る方法例と共に、様々な実施形態を示す。例えば、直接対話、米国郵便、電話、テキストメッセージ、暗号化されているか暗号化されていないかに関わらず、有線または無線音声またはデータチャネルを通じたデータメッセージまたは電子メール、および同様のものは全て、通信手段と見なされ得る。モバイル機器は、携帯電話、双方向ポケベル、タブレットまたはノートブックコンピュータ、および同様のものであり得る。コンパクト識別子は、ＰＩＮ、擬似ランダムコード、または同様のものであり得る。安全な本人確認は、取引している当事者の一方の写真、またはパスポート、免許証などの身元証明文書の写真、または公共料金の請求書、もしくは同様のもの、または指紋もしくは網膜スキャンなどの生体認証情報であり得る。

前述の例および実施形態は、唯一の実施形態と見なされるべきでなく、以下の請求項によって定義される通り、本開示の柔軟性および利点を例示するために提示されている。前述の開示および以下の請求項に基づき、他の構成、実施形態、実施態様および均等物が、当業者には明らかであり、請求項によって定義されるように本開示の精神および範囲から逸脱することなく、採用され得る。

Claims (21)

1. ユーザーを支払いサービスに登録するためのプロセスであって、
   ユーザーのグループに対する識別情報の一括アップロードを金融機関から受信することであって、前記ユーザーのグループが、前記金融機関で口座のセットを有する、ユーザーのグループに対する識別情報の一括アップロードを金融機関から受信することと、
   前記ユーザーのグループからのユーザーの身元を前記識別情報を使用して確認することと、
   前記ユーザーの前記身元を確認後、前記ユーザーに対するトークンの要求を前記金融機関に送信することと、
   前記ユーザーの代わりに、前記トークンを前記金融機関に送信することにより、資金の振替を開始することであって、前記トークンが、前記ユーザーと関連付けられた口座に対するトークン化された外部資金振替情報を含み、前記口座が前記口座のセットからである、前記ユーザーの代わりに、前記トークンを前記金融機関に送信することにより、資金の振替を開始することと
   を含む、プロセス。
2. 前記トークンが、前記支払いサービスから前記金融機関へネットワークから分離されたチャネル上で配信されたトークン化ツールを使用して、前記金融機関によって生成される、請求項１に記載のプロセス。
3. 前記口座がクレジットカード口座であり、かつ
   前記金融機関がクレジットカード口座発行者である、
   請求項１に記載のプロセス。
4. 非公開の識別情報を前記ユーザーから受け取ることであって、前記非公開の識別情報が、機密度のレベルを有する、非公開の識別情報を前記ユーザーから受け取ることと、
   前記非公開の識別情報を前記識別情報の一括アップロードに対して比較することと
   をさらに含み、
   前記トークンが前記口座からの振替に制限を課し、かつ
   前記制限の程度が前記機密度のレベルに基づく、
   請求項１に記載のプロセス。
5. 前記確認することが、
   一時的なコードを前記ユーザーの１人に、前記識別情報を使用し、テキストメッセージを介して、送信することであって、前記識別情報が、携帯電話番号のセットを含む、一時的なコードを前記ユーザーの１人に送信することと、
   前記一時的なコードを前記ユーザーから既知の店頭端末を介して受信することと
   を含む、請求項１に記載のプロセス。
6. 前記識別情報の少なくとも一部を前記既知の店頭端末に配信することと、
   確認メッセージを前記既知の店頭端末のオペレータから受信することであって、前記確認メッセージが、前記オペレータが前記ユーザーを（ｉ）顧客確認手続きおよび（ｉｉ）前記識別情報の前記一部を使用して、確認したことを確認する、確認メッセージを前記既知の店頭端末のオペレータから受信することと
   をさらに含む、請求項５に記載のプロセス。
7. 前記トークンが前記口座からの振替に制限を課し、かつ
   前記制限が、前記顧客確認手続きによって提供された確認のレベルに基づく、
   請求項６に記載のプロセス。
8. 支払いサービスのユーザーに対して口座を登録するためのプロセスであって、
   登録を意図するメッセージを前記ユーザーから受信することと、
   識別情報を前記ユーザーから要求することと、
   金融機関識別子を前記ユーザーから要求することと、
   一時的なコードを前記ユーザーに送信することと、
   前記一時的なコードを既知の店頭端末から受け取ることであって、前記既知の店頭端末が以前に前記支払いサービスで登録されている、前記一時的なコードを既知の店頭端末から受け取ることと、
   前記識別情報の少なくとも一部を前記既知の店頭端末に送信することと、
   身元確認済みメッセージを前記既知の店頭端末から受け取ることと、
   トークン化された外部資金振替情報を、前記金融機関識別子で識別された金融機関から受信することと
   を含む、プロセス。
9. 前記登録を意図する方法が、前記ユーザーと関連付けられた携帯電話から送信されたテキストメッセージを介して受信され、かつ
   前記一時的なコードがテキストメッセージを介して前記携帯電話に送信される、
   請求項８に記載のプロセス。
10. 前記身元確認済みメッセージが、前記ユーザーの身元を確認するために実行された顧客確認手続きのタイプを示し、
    前記トークン化された外部資金振替情報が、前記金融機関によって管理される口座からの振替に制限を課し、
    前記制限の程度が、前記顧客確認手続きのタイプによって提供された確認のレベルに基づく、
    請求項９に記載のプロセス。
11. 前記識別情報および前記金融機関識別子が双方向音声応答システムを介して要求される、
    請求項９に記載のプロセス。
12. 前記一時的なコードを前記ユーザーに送信する前に、前記識別情報を政府データベースに対して確認すること
    をさらに含む、請求項８に記載のプロセス。
13. 前記識別情報の前記一部が、政府識別番号である、
    請求項１２に記載のプロセス。
14. 前記一時的なコードを前記ユーザーに送信する前に、前記識別情報を、前記金融機関によって管理される金融機関データベースに対して確認すること
    をさらに含む、請求項８に記載のプロセス。
15. 前記識別情報の前記一部が、政府識別番号である、
    請求項１４に記載のプロセス。
16. ユーザーを支払いサービスに登録するためのプロセスであって、
    識別情報を既知の端末に送信することと、
    身元確認済みメッセージを前記既知の端末から受信することと、
    トークン化された外部資金振替情報を含むトークンを金融機関から受信することと
    を含み、
    前記身元確認済みメッセージが、前記ユーザーの身元を確認するために実行された顧客確認手続きのタイプを示し、
    前記トークンが、前記金融機関によって管理される口座からの振替に制限を課し、
    前記制限の程度が、前記顧客確認手続きのタイプによって提供された本人確認のレベルに基づく、
    ユーザーを支払いサービスに登録するためのプロセス。
17. 前記トークンを前記金融機関から前記受信することが、前記身元確認済みメッセージを前記既知の端末から受信した後に実行される、
    請求項１６に記載のプロセス。
18. 前記識別情報が、前記金融機関で保持されている口座に対する口座番号であり、かつ
    前記既知の端末および前記金融機関が、前記トークンを生成するために使用されたＣＯＤＥＣを共有する、
    請求項１６に記載のプロセス。
19. 前記身元確認済みメッセージが、前記既知の端末のオペレータの身元に間接的に基づく前記顧客確認手続きのタイプを示す、
    請求項１６に記載のプロセス。
20. 前記制限の前記程度が前記端末の位置にも基づく、
    請求項１６に記載のプロセス。
21. 前記制限が、前記金融機関によって管理される前記口座から所与の日に行うことができる振替回数を制限する、
    請求項１６に記載のプロセス。

Images