(57)【要約】  本発明の観点は、商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供するシステムと方法に向けられている。方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進される。方法は、値と；顧客の識別情報と；プロバイダと顧客の既存のアカウントとを識別するのに十分な情報とを顧客から受け取ることと、プロバイダの支払プラットフォームにアクセスすることと、顧客のアカウントへと支払を提供するために、プロバイダによって要求される情報を決定することと、顧客のアカウントへと支払を提供するために、プロバイダによって要求される情報を通信することと、顧客のアカウントへと値を提供することとを含む。【選択図】図７
2013538400.tif 000002
【特許請求の範囲】
【請求項１】
商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供する方法において、前記方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進され、
前記方法は、
値と；前記顧客の識別情報と；前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報とを顧客から受け取ることと、
前記プロバイダの支払プラットフォームにアクセスすることと、
前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を決定することと、
前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を通信することと、
前記顧客のアカウントへと値を提供することと
を含む方法。
【請求項２】
前記値と；前記顧客の識別情報と；前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報とは、インターネット、自動音声認識（ＩＶＲ）システム、ショートメッセージサービス（ＳＭＳ）を介して送られるメッセージ、メディアメッセージサービス（ＭＭＳ）を介して送られるメッセージ、移動体デバイス上で実行されるアプリケーション、キオスク、ポイントオブセールデバイス、および、マーチャントロケーションからなるグループのうちから選択される方法を介して受け取られる、請求項１記載の方法。
【請求項３】
前記顧客から受け取られた値は、記憶値アカウントへのアクセスを含む、請求項１記載の方法。
【請求項４】
前記記憶値アカウントは、閉ループ記憶値アカウントである、請求項３記載の方法。
【請求項５】
前記顧客から受信された値は、前記顧客によってポイントオブセールデバイスに対して行われた支払を含み、前記プロセッサは、後の時間において、前記ポイントオブセールデバイスとともに精算する、請求項１記載の方法。
【請求項６】
前記顧客の識別情報は、前記顧客のアカウントへと支払を行うために、前記プロバイダによって要求される情報を含む、請求項１記載の方法。
【請求項７】
前記識別情報は、ログイン情報およびパスワードを含む、請求項６記載の方法。
【請求項８】
前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報は、アカウント番号を含む、請求項１記載の方法。
【請求項９】
前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報は、前記プロバイダに伴う前記顧客のアカウントに関係するしるしを含む、請求項１記載の方法。
【請求項１０】
前記しるしは電話番号を含む、請求項９記載の方法。
【請求項１１】
前記プロバイダの支払プラットフォームにアクセスするステップは、インターネットを介して達成される、請求項１記載の方法。
【請求項１２】
前記プロバイダの支払プラットフォームにアクセスするステップは、前記プロバイダにより管理されている、または、前記プロバイダに関係する、支払ウェブページにアクセスすることを含む、請求項１記載の方法。
【請求項１３】
前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を決定するステップは、前記プロセッサによって実行される、ウェブスクラッピング、または、ウェブデータ抽出プログラムによって達成される、請求項１記載の方法。
【請求項１４】
前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を決定するステップは、前記顧客のアカウントへと支払を行うために、前記プロバイダによって必要とされる特定の情報を決定することを含む、請求項１記載の方法。
【請求項１５】
前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を通信するステップは、前記顧客から受信された識別情報を、前記プロバイダの支払プラットフォームへと挿入することを含む、請求項１記載の方法。
【請求項１６】
前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を通信するステップは、
前記プロバイダの支払プラットフォームにより要求される情報のそれぞれの断片を識別することと、
前記顧客から受信された識別情報から、適切な情報を決定することと、
前記プロバイダの支払プラットフォームにより要求される情報のそれぞれの断片に応答して、前記適切な情報を提供することと
を含む、請求項１記載の方法。
【請求項１７】
前記プロバイダによって要求される情報を通信するステップは、オンラインフォームへと自動入力することを含む、請求項１６記載の方法。
【請求項１８】
前記顧客のアカウントへと値を提供するステップは、前記顧客から受け取られた値を、前記プロバイダに伴う前記顧客のアカウントへと送信することを含む、請求項１記載の方法。
【請求項１９】
前記顧客のアカウントへと提供される値は、適用可能な手数料および税金が減額された、前記顧客から受け取られた値の残金である、請求項１８記載の方法。
【請求項２０】
前記値は、ポイントオブセールデバイスにおいて、前記顧客から受け取られ、前記適用可能な手数料および税金は、前記顧客のアカウントに関係するロケーション、前記ポイントオブセールデバイスのロケーション、前記プロセッサのロケーション、および、前記プロバイダのロケーションからなるグループから選択される１つ以上の要因に基づいて計算される、請求項１９記載の方法。
【請求項２１】
前記顧客のアカウントへと値を提供するステップは、仮想プリペイドデビットカード番号を生成することと、前記仮想プリペイドデビットカード番号を前記プロバイダの支払プラットフォームに提供することとを含む、請求項１記載の方法。
【請求項２２】
前記仮想プリペイドデビットカード番号は、前記プロバイダに対して行われる支払に等しい額で資金付けされる、請求項２１記載の方法。
【請求項２３】
商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供する方法において、前記方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進され、
前記方法は、
値と；前記顧客の名前および住所を含む前記顧客の識別情報と；前記既存の顧客のアカウントのアカウント番号を含む、前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報と；前記プロバイダに伴う前記既存の顧客のアカウントに支払を行う額の識別とを顧客から受け取ることと、
前記プロセッサによって、インターネットを介して、前記プロバイダの支払ウェブサイトにアクセスすることと、
支払を行うのに前記プロバイダによって要求される情報を決定するために、前記支払ウェブサイトをスクラッピングすることと、
前記プロバイダが、前記顧客の代わりに動作して、前記顧客から受け取った識別情報を、前記支払ウェブサイトへと入力することと、
前記顧客から受け取った値の形式において、前記プロバイダが支払を受け入れるか否かを決定することと、
前記顧客から受け取った値の形式で、前記プロバイダが支払を受け入れるという決定があると、顧客から受け取った値を、前記プロバイダに搬送することと、
前記顧客から受け取った値の形式で、前記プロバイダが支払を受け入れないという決定があると、仮想プリペイドデビットカード番号を生成して、前記仮想プリペイドデビットカード番号を、プロバイダに搬送することと、
前記顧客に対して支払の確認を提供することと
を含む方法。
【請求項２４】
前記値と；前記顧客の識別情報と；前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報とは、インターネット、自動音声認識（ＩＶＲ）システム、ショートメッセージサービス（ＳＭＳ）を介して送られるメッセージ、メディアメッセージサービス（ＭＭＳ）を介して送られるメッセージ、移動体デバイス上で実行されるアプリケーション、キオスク、ポイントオブセールデバイス、および、マーチャントロケーションからなるグループのうちから選択される方法を介して受け取られる、請求項２３記載の方法。
【請求項２５】
前記顧客から受け取られた値は、前記顧客によってポイントオブセールデバイスに対して行われた支払を含み、前記プロセッサは、後の時間において、前記ポイントオブセールデバイスとともに精算する、請求項２３記載の方法。
【請求項２６】
前記顧客から受け取られた値は、記憶値アカウントへのアクセスを含む、請求項２３記載の方法。
【請求項２７】
前記記憶値アカウントは、閉ループ記憶値アカウントである、請求項２６記載の方法。
【請求項２８】
前記顧客から受け取られた値は、マーチャントのみにより償還可能である閉ループ記憶値カードを使用して、前記マーチャントにおいて、前記顧客により行われた支払を含む、請求項２７記載の方法。
【請求項２９】
商品またはサービスのプロバイダに伴う顧客の既存の顧客のアカウントへと支払を提供するプロセッサにおいて、前記プロセッサは、前記顧客、および、前記プロバイダとともに選択的に通信し、
前記プロセッサは、
前記プロセッサと前記顧客との間の選択的な通信を提供する顧客インターフェースと、
前記プロセッサと前記プロバイダとの間の選択的な通信を提供するプロバイダインターフェースと、
前記プロバイダインターフェースと通信する、ウェブデータ抽出モジュールと、
前記顧客インターフェース、前記プロバイダインターフェース、前記ウェブデータ抽出モジュールと通信する処理モジュールと
を具備し、
前記顧客インターフェースは、
値と；前記顧客の名前および住所を含む前記顧客の識別情報と；前記既存の顧客のアカウントのアカウント番号を含む、前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報と；前記プロバイダに伴う前記既存の顧客のアカウントに支払を行う額の識別とを顧客から受け取るように構成されており、
前記プロバイダインターフェースは、
前記プロバイダの支払プラットフォームまたはウェブサイトにアクセスし、
前記プロバイダの支払プラットフォームまたはウェブサイトに情報を提供するように構成されており、
前記ウェブデータ抽出モジュールは、支払を行うために、前記プロバイダによって要求される情報を決定するように構成されており、
前記処理モジュールは、
前記顧客から受け取った識別情報を、支払プラットフォームまたはウェブサイトへと入力し、
前記支払プラットフォームまたはウェブサイトへと値を提供するように構成されている装置。
【請求項３０】
前記処理モジュールは、
前記顧客から受け取った値の形式において、前記プロバイダが支払を受け入れるか否かを決定するようにと、
前記顧客から受け取った値の形式で、前記プロバイダが支払を受け入れるという決定があると、顧客から受け取った値を、プロバイダに搬送するようにと、
前記顧客から受け取った値の形式で、前記プロバイダが支払を受け入れないという決定があると、仮想プリペイドデビットカード番号を生成して、前記仮想プリペイドデビットカード番号を、前記プロバイダに搬送するように
さらに構成されている、請求項２９記載のシステム。
【請求項３１】
前記顧客からの値を受け入れて、適用可能な手数料または税金を減額し、残りの値を、前記プロバイダの支払プラットフォームまたはウェブサイトにより受け入れ可能な種類のものへと交換するように構成されている、値交換モジュールをさらに具備する、請求項２９記載のシステム。
【請求項３２】
前記既存の顧客のアカウントへと行われることになる支払の額で資金付けされた関係するアカウントを伴う、プリペイドデビットカード番号を生成させるように構成されている仮想プリペイドデビットカード生成機をさらに具備する、請求項２９記載のシステム。
【請求項３３】
前記プロセッサと、前記顧客のファイナンシャルアカウントとの間の選択的な通信を提供する、ファイナンシャルアカウントインターフェースをさらに具備し、前記ファイナンシャルアカウントインターフェースは、前記プロセッサに値を送金するように構成されている、請求項２９記載のシステム。
【請求項３４】
前記顧客インターフェースは、
インターネット、自動音声認識（ＩＶＲ）システム、ショートメッセージサービス（ＳＭＳ）を介して送られるメッセージ、メディアメッセージサービス（ＭＭＳ）を介して送られるメッセージ、移動体デバイス上で実行されるアプリケーション、キオスク、ポイントオブセールデバイス、および、マーチャントロケーションからなるグループのうちから選択される方法を介して、前記顧客との通信を提供する、請求項２９記載のシステム。
【請求項３５】
前記顧客インターフェースは、前記既存の顧客のアカウントに対する支払が、うまく行われた後に、支払の確認を前記顧客に提供するようにさらに構成されている、請求項２９記載のシステム。
【発明の詳細な説明】
【関連出願】
【０００１】
本出願は、２００９年９月２２日に出願され、（ここで参照によりその全体が組み込まれている）米国特許出願シリアル番号第１２／５６４，４７４号に対する優先権を主張し、第１２／５６４，４７４号出願は、２００７年２月７日に出願され、（ここで参照によりその全体が組み込まれている）米国特許出願シリアル番号第１１／６７２，０８２号の継続出願であり、第１１／６７２，０８２号出願は、２００７年１月１６日に出願され、（ここで参照によりその全体が組み込まれている）米国仮特許出願第６０／８８５，０４４号に基づいている。
【発明の背景】
【０００２】
本発明は、一般的に、第三者の請求者に、または、指示された受取人に、顧客の勘定を支払うのに利用されるシステムおよび方法に向けられている。より詳細には、本発明は、典型的な支払チャネルを回避して、代わりに、受取人自身の支払プラットフォームを利用するシステムおよび方法に向けられている。
【０００３】
顧客のファイナンシャルアカウントにリンクされている繰り返し発生する支払プランから、最大手の金融機関により提供されるオンライン勘定支払にわたる、数多くの勘定支払プログラムおよびプランがある。このような勘定支払システムは、銀行を利用していない母集団にフォーカスしていることが多く、為替またはウェスタンユニオンのような、従来技術の方法より効率的で、費用の掛からない勘定支払の方法を提供してもよい。
【０００４】
支払プロセッサによって維持および動作される、多くの勘定支払システムは、顧客に、支払われることになるアカウントに関する情報を入力することと、支払プロセッサに対して資金を提供することとを要求する。一般的に、支払プロセッサは、従来の方法、典型的に値の送金を通して、顧客によって、識別された勘定を支払う。このような値の送金は、典型的に、勘定アグリゲータの使用を通して達成される。勘定アグリゲータは、一般的に、１つの会社からの支払記録を集めて、この記録を、別の勘定システムへポストする。典型的に、顧客が、その電力会社に対する勘定を支払うために、勘定支払プロセッサ“Ａ”を使用する場合、取引は、典型的に、以下のようである：（ｉ）顧客が支払プロセッサ“Ａ”に対して、金銭（通貨）を支払う、（ｉｉ）支払プロセッサ“Ａ”は、勘定アグリゲータ（例えば、ＲＰＳ、チェックフリー）に支払う、（ｉｉｉ）勘定アグリゲータが電力会社に支払う。
【０００５】
このプロセスは、勘定アグリゲータによって提供される、手形交換所機能に対して有用であることが多いが、これは、余分な値の送金を含んでおり、それに伴う手数料、費用、チャージ、および、リスクのすべてを含む。
【０００６】
したがって、勘定アグリゲータを不要にするシステムが望ましい。しかしながら、ほとんどの勘定アグリゲータによって提供される接続を回避するために、受取人（または、支払われることになる商品またはサービスのプロバイダ）の支払プラットフォームに対するいくつかのリンクが、維持および／またはアクセスされなければならない。ますます多くのプロバイダが、支払を受け入れる追加の手段として、インターネットを介して、顧客によって典型的に、アクセスされる、それら自身の支払プラットフォームを維持する方向に進んでいる。したがって、代わりに、プロバイダまたは受取人の支払プラットフォームに直接アクセスすることによって、勘定アグリゲータを使用することを回避できるシステムが望ましい。
【０００７】
勘定アグリゲータの欠点に加えて、ほとんどの勘定支払システムは、特定の方法で、典型的には、アカウントセットアップまたは支払の時間において現金で、勘定支払システムに資金付けすることを要求する。記憶値カードのユビキタスな性質からして、支払オプションとして記憶値カードを利用する勘定支払システムが望ましい。しかしながら、数多くのプロバイダまたは受取人は、記憶値、特に、閉ループシステムに関連した記憶値を受け入れないかもしれない。したがって、典型的に、顧客からの閉ループ記憶値を受け入れるが、プロバイダまたは受取人に対して、開ループ記憶値（例えば、プリペイドＶｉｓａ（登録商標）デビットカード番号）を提供するシステムと方法を維持することが望ましい。
【発明の概要】
【０００８】
本発明の観点は、商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供する方法を含んでもよい。方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進され、方法は、値と；顧客の識別情報と；プロバイダと顧客の既存のアカウントとを識別するのに十分な情報とを顧客から受け取ることと、プロバイダの支払プラットフォームにアクセスすることと、顧客のアカウントへと支払を提供するために、プロバイダによって要求される情報を決定することと、顧客のアカウントへと支払を提供するために、プロバイダによって要求される情報を通信することと、顧客のアカウントへと値を提供することとを含む。
【０００９】
本発明の、他の観点は、商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供する方法を含んでもよい。方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進され、方法は、値と；顧客の名前および住所を含む顧客の識別情報と；既存の顧客のアカウントのアカウント番号を含む、プロバイダと顧客の既存のアカウントとを識別するのに十分な情報と；プロバイダに伴う既存の顧客のアカウントに支払を行う額の識別とを顧客から受け取ることと、プロセッサによって、インターネットを介して、プロバイダの支払ウェブサイトにアクセスすることと、支払を行うのにプロバイダによって要求される情報を決定するために、支払ウェブサイトをスクラッピングすることと、プロバイダが、顧客の代わりに動作して、顧客から受け取った識別情報を、支払ウェブサイトへと入力することと、顧客から受け取った値の形式において、プロバイダが支払を受け入れるか否かを決定することと、顧客から受け取った値の形式で、プロバイダが支払を受け入れるという決定があると、顧客から受け取った値を、プロバイダに搬送することと、顧客から受け取った値の形式で、プロバイダが支払を受け入れないという決定があると、仮想プリペイドデビットカード番号を生成して、仮想プリペイドデビットカード番号を、プロバイダに搬送することと、顧客に対して支払の確認を提供することとを含む。
【００１０】
本発明の、他の観点は、商品またはサービスのプロバイダに伴う顧客の既存の顧客のアカウントへと支払を提供するプロセッサを含んでもよい。プロセッサは、顧客、および、プロバイダとともに選択的に通信し、プロセッサは、プロセッサと顧客との間の選択的な通信を提供する顧客インターフェースと、プロセッサとプロバイダとの間の選択的な通信を提供するプロバイダインターフェースと、プロバイダインターフェースと通信する、ウェブデータ抽出モジュールと、顧客インターフェース、プロバイダインターフェース、ウェブデータ抽出モジュールと通信する処理モジュールとを具備し、顧客インターフェースは、値と；顧客の名前および住所を含む顧客の識別情報と；既存の顧客のアカウントのアカウント番号を含む、プロバイダと顧客の既存のアカウントとを識別するのに十分な情報と；プロバイダに伴う既存の顧客のアカウントに支払を行う額の識別とを顧客から受け取るように構成されており、プロバイダインターフェースは、プロバイダの支払プラットフォームまたはウェブサイトにアクセスし、プロバイダの支払プラットフォームまたはウェブサイトに情報を提供するように構成されており、ウェブデータ抽出モジュールは、支払を行うために、プロバイダによって要求される情報を決定するように構成されており、処理モジュールは、顧客から受け取った識別情報を、支払プラットフォームまたはウェブサイトへと入力し、支払プラットフォームまたはウェブサイトへと値を提供するように構成されている。
【００１１】
これらのおよび他の観点は、以下の図面を考慮して、本発明の以下の詳細な説明から明らかになるだろうが、本発明の新規な概念の精神と範囲から逸脱することなく、変形および修正を生じさせるだろう。
【図面の簡単な説明】
【００１２】
本発明は、同一の参照識別子が同一のエレメントを表すのに使用されている、添付の図面とともに、以下の詳細な説明を読むことによって、より完全に理解されることができる。添付の図面は、ある例示的な実施形態を図示し、以下の詳細な説明を理解するのを支援してもよい。本発明の何らかの実施形態を詳細に説明する前に、本発明は、以下の詳細な説明に述べる、または、図面に図示する、コンポーネントの配置および構成の詳細に、その応用において制約されないことを理解すべきである。図示された実施形態は、例として理解されるべきものであり、決して、本発明の全体の範囲を制限するものではない。また、ここで用いられる語法および用語法は、説明の目的のためのものであり、制限的なものとしてみなされるべきでないことを理解すべきである。詳細な説明は、以下の図面に対する参照を行うだろう。  
【図１】図１は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法を図示する。
【図２】図２は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法を図示する。
【図３】図３は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法を図示する。
【図４】図４は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法の一部として、請求者により受け入れられる資金付けオプションを決定するプロセスを図示する。
【図５】図５は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法を図示する。
【図６】図６は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にするシステムを図示する。
【図７】図７は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にするシステムを図示する。
【００１３】
本発明の何らかの実施形態を詳細に説明する前に、本発明は、以下の詳細な説明に述べる、または、図面に図示する、コンポーネントの配置および構成の詳細に、その応用において制約されないことを理解すべきである。本発明は、他の実施形態が可能であり、そして、さまざまな方法において実施または実行されてもよい。また、ここで用いられる語法および用語法は、説明の目的のためのものであり、制限的なものとしてみなされるべきでないことを理解すべきである。
【発明の詳細な説明】
【００１４】
この説明において、例示される事項は、添付の図面を参照して開示される、さまざまな例示的な実施形態の包括的な理解において支援するために提供されている。したがって、当業者は、特許請求された発明の精神および範囲から逸脱することなく、ここで記述した例示的な実施形態のさまざまな変更および修正を行うことができることを理解するだろう。周知の機能および構成の説明は、明瞭さと分かり易さのために、省略した。さらに、ここで使用するように、単数形は、複数形において解釈されてもよく、また、代わりに、複数形の何らかの用語は、単数形であるとして解釈されてもよい。“Ｓ”で始まる参照図面（例えば、Ｓ１００）は、ステップを表す。
【００１５】
一般的に、本発明は、勘定支払プログラムを実行するシステムおよび方法に向けられていてもよい。特に、本発明は、顧客が、さまざまな個人およびアカウント識別情報をプロセッサに提供し、プロセッサが、顧客として動作して、直接の支払を提供するために、請求者の支払プラットフォーム（例えば、支払ウェブページ）を利用する、勘定支払プログラムに向けられている。ここで説明するシステムと方法はまた、プロセッサが、仮想プリペイドデビットカード（例えば、Ｖｉｓａのブランド付けされたデビットカード番号）を、支払として請求者に提供しながら、（例えば、ウォールマート（登録商標）ギフトカードのような、閉ループ記憶値を含む）記憶値を支払として受け入れることに備える。
【００１６】
図１を参照して、本発明のいくつかの実施形態にしたがった、勘定の支払の方法１０をここで説明する。図１に図示した方法は、一般的に、顧客、プロセッサ、および、請求者の間で促進される。
【００１７】
顧客は、支払を行うために勘定支払システムを利用する、何らかの当事者であってもよい。支払を行う当事者は、債務を引き起こした、すなわち、支払から利益を受けることになる当事者と同一であってもよいとして、以下の説明は提示するが、必ずしもそうでなくてもよい。言い換えると、ここで提示する、勘定支払システムおよび方法は、商品またはサービスのプロバイダに伴う既存の顧客アカウントに対して支払を提供する手段を提供する。しかしながら、既存のアカウントに支払を提供する“顧客”は、既存のアカウントを所有する、または、そうでなければ既存のアカウントから利益を受ける当事者と、同一でなくてもよい。このことの例は、親が、その親の子供、または、扶養家族名義において維持されているアカウントへと支払を行うことであってもよい。
【００１８】
プロセッサは、顧客からの通信を受け取って、請求者と対話する当事者、より詳細には、請求者の支払プラットフォームまたはウェブサイトと対話する当事者である。以下の説明では、プロセッサを、別個の中間システムとして提示するかもしれないが、プロセッサは、１つ以上の請求者に関係していてもよく、または、小売業者もしくはマーチャントに関係付けられていてもよく、小売業者もしくはマーチャントの一部であってもよいことが企図されている。
【００１９】
請求者は、既存の顧客のアカウントを保持する当事者である。一般的にいうと、請求者は、商品またはサービスのプロバイダであってもよいが、プロバイダの勘定と収集の側面は、別個の無関係の当事者へとアウトソーシングされてもよい。本発明は、このシナリオもまたカバーすることを意図しており、したがって、用語“請求者”および“商品またはサービスのプロバイダ”は、関連することを意図している。“請求者”は、“商品またはサービスのプロバイダ”であってもよいが、“商品またはサービスのプロバイダ”は、“請求者”である必要はない。
【００２０】
顧客、プロセッサ、および、請求者の間の通信は、このような通信が直接であるかのように、以下で説明する。しかしながら、このような通信は、追加の当事者またはデバイスを要求してもよい。例えば、顧客は、インターネット、電話（例えば、自動音声認識（ＩＶＲ）システム）、メッセージングシステム（例えば、ショートメッセージサービス（ＳＭＳ）、または、メディアメッセージサービス（ＭＭＳ））、さまざまな電子デバイス上で実行されるアプリケーションもしくはアプレット、ポイントオブセール端末もしくはデバイス、あるいは、マーチャント通信を介して、対話してもよい。中間デバイスまたは当事者が利用される環境（例えば、マーチャントまたはマーチャントロケーションにおける、ポイントオブセールデバイスの使用）では、精算は、中間当事者とプロセッサとの間で確立される、通常サイクル上で発生してもよい。このような環境では、プロセッサが支払を行ったが、顧客からまだ収集していないときの時間期間があってもよい。
【００２１】
プロセッサと通信している顧客の例は、様々な通信のチャネルを含んでもよい。例えば、顧客は、プロセッサと登録してもよく、第１のチャネル、例えば、インターネットを介して、何らかの初期情報を提供してもよいが、次に、第２のチャネル、例えば、マーチャントにおけるインレーン取引の間に、マーチャントのポイントオブセールデバイスおよびマーチャント対プロセッサ通信リンクを介して、勘定の支払を要求してもよい。
【００２２】
図１は、本発明の非常に基本的な意味で、３つのステップを含む、いくつかの実施形態を表す。第１に、Ｓ１１０において、プロセッサは、顧客からのさまざまな情報の断片を受信し、情報は、例として、（ｉ）個人識別情報；（ｉｉ）請求者アカウント情報；および（ｉｉｉ）資金アカウント情報を含む。
【００２３】
個人識別情報は、顧客アカウントに対して支払を行うために、請求者によって要求される情報を含んでいてもよい。例えば、個人識別情報は、顧客の名前、住所、生年月日、ログイン情報、および、パスワード情報を含んでもよい。
【００２４】
請求者アカウント情報は、プロセッサが、特定の請求者と、請求者に伴う、特定のアカウントとを識別するのに十分な情報を含んでもよい。例えば、請求者アカウント情報は、請求者の識別子と、既存の顧客アカウントのアカウント番号とを含んでいてもよい。いくつかの環境では、また、本発明のいくつかの実施形態にしたがうと、請求者アカウント情報は、特定のデバイスに関係付けられた情報であってもよく、次に、特定のデバイスは、アカウントに関係付けられている。例えば、請求者アカウント情報は、電子デバイスの電話番号を含んでもよい。このような電話番号は、プロバイダと、プロバイダとともにある、顧客のアカウント番号を決定するのに十分であってもよい。
【００２５】
資金アカウント情報は、勘定支払取引を資金付けするのに使用される、情報、または、値自体を含んでもよい。資金アカウント情報は、ファイナンシャルアカウント情報（例えば、当座預金アカウント情報）、記憶値アカウント情報（例えば、記憶値アカウント番号）、または、そこからの値が、支払のために引き落とされてもよい、他の任意のタイプのアカウント情報を含んでもよい。
【００２６】
“記憶値”は、典型的に、その中に保持される値を有する、関係するアカウントを有するしるしを指す。したがって、プリペイドＶｉｓａデビットカード、または、ウォールマートギフトカード上のアカウント番号のような、記憶値アカウント番号の支給は、値を運ぶとして考えられてもよい。“記憶値”は、当業者の一人が理解するように、“開ループ”、または、“閉ループ”として規定されてもよい。例えば、“閉ループ”記憶値は、一般的に、第１の例において、記憶値を発行または提供する当事者（または、その代表者）によって制限されることが多い、制限された数の当事者によって、償還されてもよい。例として、ウォールマートギフトカードは、ウォールマートにおいてのみ償還可能であって、他の場所では使用できないため、ウォールマートギフトカードは、閉ループ記憶値カードである。プリペイドＶｉｓａ、ＭａｓｔｅｒＣａｒｄ（登録商標）、Ｄｉｓｃｏｖｅｒ（登録商標）、または、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標）記憶値カードは、“開ループ”として考慮される。このような値は、Ｖｉｓａ、ＭａｓｔｅｒＣａｒｄ、Ｄｉｓｃｏｖｅｒ、または、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓを受け入れるロケーションにおいてのみ償還されてもよいが、償還のロケーションは、記憶値を発行または提供した当事者に結び付けられてはいない。
【００２７】
Ｓ１２０において、プロセッサは、請求者の支払プラットフォームに直接アクセスして、請求者に、支払を行うために要求される情報を提供してもよい。例えば、プロセッサは、顧客の名前、住所、および／または、アカウント番号を提供することを要求されてもよい。
【００２８】
Ｓ１３０において、プロセッサは、請求者の支払プラットフォーム上で、支払を提供してもよい。例えば、いくつかの実施形態では、プロセッサは、顧客によって識別された資金アカウントからの値の、請求者に対する値（マイナス、適用可能な手数料または税金）の直接の送金を促進してもよい。本発明のいくつかの実施形態では、プロセッサは、１つのフォーマットにおいて、顧客からの値を受け取ってもよく、請求者によって受け入れられるフォーマットにおける値に対して、このような受け取った値を交換してもよい。例えば、顧客は、プロセッサに、閉ループ記憶値を提供してもよく、プロセッサは、開ループ記憶値を使用して、請求者に支払ってもよい。
【００２９】
図１に図示した方法１０から理解されるように、プロセッサは、顧客の立場に立っており、請求者と直接勘定支払取引を実行する。勘定支払システムは、複数の請求者とともに、様々な取引を実行してもよいので、本発明のいくつかの実施形態にしたがった方法およびシステムが、顧客にとって利益のあるものであってもよく、また、有利であってもよい。例えば、個人識別情報が、プロセッサによって保存されてもよい。複数の請求者に伴う、様々な請求者アカウント情報は、プロセッサによって保存されてもよい。したがって、複数の請求者に対する将来の勘定支払取引は、顧客およびプロセッサの間の単一の取引によって実行されてもよい。さらに、プロセッサは、請求者とともに直接、作動するので、顧客アカウントに対する支払は、伝統的な支払技術（例えば、小切手を送ること、または、支払アグリゲータを利用すること）にしたがった場合にかかることになるよりも、すばやくポストされてもよい。
【００３０】
図２は、請求者の支払プラットフォームを利用して、顧客の勘定の支払を促進する方法２０を図示する。図２に図示した方法は、方法の登録コンポーネント（顧客からプロセッサに対する情報の支給）を、方法の支払コンポーネント（勘定を支払うための、顧客からプロセッサに対する値の支給）から分ける。
【００３１】
Ｓ２１０において、プロセッサは、顧客から（ｉ）個人識別情報と；（ｉｉ）請求者アカウント情報とを受信する。上記のように、この情報は、何らかの方法で、また、何らかのチャネルを介して、顧客から受信されてもよい。
【００３２】
Ｓ２２０において、プロセッサは、顧客から資金を受け取ってもよい。このステップＳ２２０は、実際の資金の受け取り、または、その中で実際の資金もしくは値が見受けられてもよい、アカウント情報の受け取りを含んでもよい。Ｓ２１０およびＳ２２０の間で、かなりの時間期間が経過してもよいことと、顧客とプロセッサとの間の通信のチャネルは、Ｓ２１０およびＳ２２０において同一である必要はないこととに留意すべきである。
【００３３】
Ｓ２３０において、プロセッサは、請求者の支払プラットフォームにアクセスしてもよい。本発明のいくつかの実施形態にしたがうと、支払プラットフォームは、それを通して顧客が、請求者に伴う、彼または彼女のアカウントへと支払を行ってもよいインターネットウェブサイトであってもよい。
【００３４】
Ｓ２４０において、プロセッサは、顧客のアカウント中への支払を行うために、請求者によって要求される情報を決定してもよい。この情報は、何らかの方法において決定され、収集されてもよい。本発明のいくつかの実施形態にしたがうと、この情報は、ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出のプログラムもしくはモジュールの使用を通して収集されてもよい。ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出は、一般的には、コンピュータソフトウェアを使用して、特定のウェブサイトから情報を自動的に収集および抽出するプロセスである。通常は、このようなソフトウェアプログラムは、ウェブサイト探査をシミュレートする。ウェブスクラッピングモジュールは、一般的に、構造化されていないウェブコンテンツを収集し、それを、記憶および解析可能な、構造化されたデータへと変換する。本発明のいくつかの実施形態にしたがうと、この情報は、請求者の支払プラットフォームによって直接、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、収集されてもよい。
【００３５】
Ｓ２５０において、プロセッサは、請求者の支払プラットフォームへと、要求される情報を提供してもよい。いくつかの実施形態では、このことは、（“名前”フィールドへと顧客の名前を挿入することや、または、“アカウント番号”フィールドへと顧客のアカウント番号を挿入することのような）ウェブページ上の要求されるフィールドへと、適切な情報を挿入することを含んでもよい。いくつかの実施形態では、支払プラットフォームは、最初に、複数の情報を要求してもよいが、将来の取引に対しては、顧客からのログインおよびパスワードのみを要求してもよい。このような状況では、プロセッサがログインおよびパスワードを確立するか、プロセッサが、Ｓ２１０において、顧客から既存のログインおよびパスワードを受信するかのいずれかである。いくつかの実施形態では、支払プロセッサによって要求される情報は、要求される方法において整えられてもよく、例えば、ＡＰＩを介して、支払プラットフォームに直接送信されてもよい。
【００３６】
Ｓ２６０において、プロセッサは、支払プラットフォームへと、値または値のしるしを提供してもよい。例えば、顧客がプロセッサに、銀行アカウント情報を提供した場合、プロセッサは、顧客の銀行アカウントから、支払プラットフォームに対する送金を促進してもよい。顧客が、支払プラットフォームによって受け入れられないフォーマットにおいて、例えば、閉ループギフトカードの形式で、プロセッサに対して値を提供した場合、プロセッサは、この受け取った値を、支払プラットフォームが受け入れる値へと交換してもよい。例えば、いくつかの実施形態では、プロセッサは、１つのフォーマットにおいて、値を受信してもよいが、支払プラットフォームに対して、生成された開ループ仮想プリペイドカード番号の形式で、支払を提供してもよい。制限的でない例として、顧客は、ウォールマートギフトカードを介して、プロセッサに支払を提供してもよく、次に、プロセッサは、仮想プリペイドＶｉｓａデビットカードを生成して、請求者に対する支払の正確な額で、仮想プリペイドＶｉｓａデビットカードを資金付けして、仮想プリペイドＶｉｓａデビットカードアカウント番号を請求者に提供してもよい。
【００３７】
副次的な留意点として、開ループ仮想プリペイドデビットカード番号の生成および支給は、追加の、または、付随的な利点を有していてもよい。例えば、Ｖｉｓａブランド付けされた記憶値カードのケースでは、このような記憶値カードが償還されるとき、記憶値カードを発行した当事者は、交換手数料を受ける資格を与えられてもよい。交換手数料は、受取人がＶｉｓａまたはＭａｓｔｅｒＣａｒｄのようなカードネットワークを使用して、支払を受け入れた時に、受取人の銀行（または、受納している銀行）が、発行した銀行に支払う手数料である。発行した銀行が受納する銀行に支払う額から、発行した銀行は交換手数料を減額することが多い。交換手数料は、変化してもよいが、取引の値の約１．５％−２．０％であることが多い。プロセッサは、発行した銀行であるため、取引の費用は、交換手数料の額だけ減額される。この交換手数料は、支払取引を実行することに対する、プロセッサへの支払として使用されてもよく、交換手数料を減額することにより、様々な請求者との関係を向上させるために、または、オフセットされた支払を提供するために、レバレッジされてもよい。
【００３８】
Ｓ２７０において、プロセッサは、支払の確認を顧客に送る。この確認は、何らかの通信チャネルを介してのものであってもよく、必ずしもそうではないが、顧客から受信された支払命令と同一のフォーマットにおけるものであってもよい。本発明にしたがったいくつかの実施形態では、確認は、ＳＭＳ、ＭＭＳ、電子メール、アプリケーション通知、ソーシャルネットワーキングページ上のメッセージング、電話通話、ページ、ファックス、または、他の任意の通信を介して送られてもよい。
【００３９】
図３にしたがうと、本発明のいくつかの実施形態にしたがって、請求者の支払プラットフォームを利用して、顧客勘定の支払を促進する方法３０をここで説明することにする。Ｓ３０５において、顧客が、プロセッサに、（ｉ）個人識別情報と、（ｉｉ）請求者アカウント情報と、（ｉｉｉ）資金アカウント情報とのような情報を提供する。
【００４０】
Ｓ３１０において、プロセッサは、Ｓ３０５において送られた顧客からの情報を受信し、情報が有効であり、資金アカウントが適切に資金付けされている（すなわち、それに関係付けられている値を有する）ことを確認してもよい。
【００４１】
Ｓ３１５において、プロセッサは、顧客から受信された情報に基づいて、請求者を識別してもよく、請求者の支払プラットフォーム（例えば、支払が受信され、顧客アカウントに適用されることを可能にする請求者のウェブサイト）にアクセスしてもよい。
【００４２】
Ｓ３２０において、例えば、ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出プログラムの使用を通して、請求者に支払を提供するために必要とされる情報を決定してもよい。
【００４３】
Ｓ３２５において、プロセッサは、適切なフォーマットで、支払プラットフォームへと必要とされる情報を提供してもよい。例えば、プロセッサは、ブランクフィールドを備えるウェブベースのフォームに記入してもよく、または、支払プラットフォームの周知のＡＰＩに基づいて、送金をアセンブルしてもよい。
【００４４】
Ｓ３３０において、プロセッサは、顧客から請求者に支払うべき額を決定してもよい。この決定は、通信を介して、または、ウェブページ上でポストされた支払うべき額を通して、また、プロセッサが再び、ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出プログラムのサービスを利用してのように、支払プラットフォームから受信された情報に基づいていてもよい。
【００４５】
Ｓ３３５において、プロセッサは、顧客によって提供された（または、顧客によって識別されるアカウントに関係づけられている）資金付けの額が、請求者に支払うべき額より多いか、または、等しいかを決定してもよい。資金の額が不十分であるという決定があると、取引は終了してもよく、または、プロセッサが不足について顧客に通知して、追加の資金源、または、請求者に対して行うための支払の額における減額のいずれかを要求する。
【００４６】
資金付けの額が十分であるという決定があると、プロセッサは、請求者に対して支払うべき額（または、顧客によって指示された、他の何らかの額）を資金アカウントから減算してもよい。Ｓ３４５において、プロセッサは、請求者の支払プラットフォームに支払を提供してもよい。Ｓ３５０において、プロセッサは、支払が行われたことを顧客に確認してもよく、最終の支払額について顧客に通知してもよい。
【００４７】
Ｓ３４５においてプロセッサによって支払プラットフォームへと提供された値の形式は、Ｓ３０５において顧客から受信された値と、同一の形式でなくてもよい。図４を参照して、本発明のいくつかの実施形態にしたがって、請求者の支払プラットフォームを利用して、顧客の勘定の支払を促進する方法の一部として、請求者４０によって受け入れられる資金付けオプションを決定するプロセスを、以下で記述することにする。
【００４８】
Ｓ４１０において、プロセッサは、請求者および／または請求者の支払プラットフォームによって受け入れられる、資金付けオプションのタイプを決定してもよい。例えば、いくつかの請求者は、直接のアカウント送金を受け入れてもよい一方で、他の請求者は、ＶｉｓａまたはＭａｓｔｅｒＣａｒｄの形式における支払のみを受け入れてもよい。いくつかの請求者は、閉ループ記憶値のいくつかの形式を受け入れてもよい（例えば、ＢｅｓｔＢｕｙ系列のクレジットの支払は、ＢｅｓｔＢｕｙ閉ループギフトカードとともに行われてもよい）一方で、他の請求者は、何の閉ループ記憶値も受け入れないかもしれない。
【００４９】
Ｓ４２０において、許容される場合、プロセッサは、支払プラットフォームに対する、顧客のアカウント（例えば、小切手アカウントのようなファイナンシャルアカウント）からの直接の値の送金を促進してもよい。
【００５０】
支払プラットフォームが値の直接送金を受け入れない場合、または、顧客によって提供されたフォーマットにおける値を受け入れない場合、プロセッサは、提出された値を交換する必要があるかもしれない。Ｓ４３０において、プロセッサは、顧客指示された、資金源から、適切な値の額を減算してもよい。この額は、支払の額、プラス、適用可能な手数料または税金を含んでいてもよい。
【００５１】
適切な手数料または税金は、いくつかの要因に基づいていてもよい。発信元またはセットアップ手数料があってもよく、それぞれのアカウント、それぞれの請求者、および／または、それぞれの支払取引に関係するサービス手数料があってもよい。値の交換が要求されるときに適用される手数料があってもよい。適用可能な税金は、制限的でないが、顧客アカウントに関係するロケーション、支払要求の発信元のロケーション（例えば、（ＩＳＰにより決定される）発信しているコンピュータのロケーション、発信しているポイントオブセールデバイスまたはロケーション、開始された支払取引が受信された電話の交換ロケーション等）、プロセッサのロケーション、および、プロバイダのロケーションを含む、複数の要因に基づいていてもよい。
【００５２】
Ｓ４４０において、プロセッサは、Ｖｉｓａブランド付けされたプリペイドデビットカードのような、仮想開ループプリペイド記憶値カードまたはデビットカードを生成させてもよい。プロセッサは、支払取引の正確な額で、仮想開ループプリペイド記憶値カードまたはデビットカードを資金付けしてもよい。
【００５３】
Ｓ４５０において、プロセッサは、仮想開ループプリペイド記憶値カードまたはデビットカードのアカウント番号（例えば、仮想カード番号）を、支払プラットフォームに提供してもよい。Ｓ４６０において、プロセッサは、支払プラットフォームによる、資金の受け取りの確認を受信してもよい。
【００５４】
図５を参照して、本発明のいくつかの実施形態にしたがって、本発明のいくつかの実施形態にしたがって、請求者の支払プラットフォームを利用して、顧客の勘定の支払を促進する方法５０を、以下で記述することにする。Ｓ５１０において、顧客がプロセッサに情報を提供する。このような情報は、個人識別情報（例えば、名前、住所等）、請求者アカウント情報（例えば、請求者の名前、顧客のアカウント番号）を含んでもよい。オプション的に、Ｓ５１１において、顧客がプロセッサに、将来の支払に対して使用されることになるファイナンシャルアカウント情報を提供してもよい。例えば、顧客は、Ｓ５１１において、顧客の小切手アカウントを識別して、アクセスするのに十分な情報を提供してもよい。
【００５５】
Ｓ５２０において、プロセッサが情報を受け取って、情報が、識別された請求者の支払プラットフォームにアクセスして、支払取引を実行するために、有効および十分であることを確認してもよい。例えば、Ｓ５２１において、請求者の識別に基づいて、プロセッサは、データベースまたは他の記録を参照して、請求者によって何の情報が要求されるかを決定してもよい。代わりに、Ｓ５２２において、プロセッサは、請求者の支払プラットフォームにアクセスして、Ｓ５２３において、支払取引を実行するのに、請求者によって必要とされる情報を決定してもよい。この決定は、ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出のプログラムもしくはモジュールの使用を介して実行されてもよい。
【００５６】
Ｓ５２４において、プロセッサは、顧客から受信された情報を、支払プラットフォームにより支払取引を実行するために要求される情報に、比較してもよい。Ｓ５２５において、受信された情報が十分である場合、プロセスは継続してもよい。受信された情報が不足している場合、Ｓ５２６において、顧客からのさらなる情報が要求されてもよく、プロセスはＳ５２０に戻ってもよい。
【００５７】
さらなるオプションステップが、プロセスに含まれてもよい。例えば、Ｓ５２７で、プロセッサは、支払プラットフォームにおいて、顧客支払アカウントを作成してもよい。Ｓ５２７は、ログインおよび／またはパスワードの作成（または、割り当て）を含んでいてもよい。顧客支払アカウントは、将来の取引に対して、さまざまな情報を継続的に再入力する必要性を防止してもよい。Ｓ５２８において、プロセッサは、顧客支払アカウントについて顧客に通知してもよく、アクセスのために必要とされるログインおよび／またはパスワードを顧客に提供してもよい。
【００５８】
Ｓ５３０において、プロセッサは、勘定を支払うための顧客からの要求を受信してもよい。この要求は、顧客が支払うことを望む、特定の請求者の識別を含んでいてもよい。オプション的ステップＳ５３１において、プロセッサは、顧客から請求者に借りのある額および／または支払うべき額を決定してもよい。オプション的ステップＳ５３２において、プロセッサは、この額を顧客に知らせる。
【００５９】
Ｓ５４０において、プロセッサは、請求者に対して支払うための値の額の表示を顧客から受信してもよい。Ｓ５１１において、顧客がファイナンシャルアカウントに関する情報を提供していない場合、または、顧客が、このようなファイナンシャルアカウントを資金源として使用しないことを選んだ場合、Ｓ５４１において、プロセッサは、顧客から、値、または、値のしるしを受信してもよい。
【００６０】
Ｓ５５０において、プロセッサは、顧客から受信された値、または、顧客によって識別された資金源もしくはファイナンシャルアカウントが、Ｓ５４０において、顧客から受信された、表示された支払の額より多い値を有しているか、または、これに等しい値を有しているか否かを決定してもよい。受信された値が十分でない場合、または、資金源もしくはファイナンシャルアカウントが十分な値の額で資金付けされていない場合、Ｓ５５１において、顧客は不足について知らされ、プロセスは、Ｓ５４０に戻ってもよく、ここで、顧客は、請求者に支払うための値の額の新しい表示を提供する。
【００６１】
Ｓ５６０において、受信された値が十分である場合、または、資金源もしくはファイナンシャルアカウントが十分な値の額で資金付けされている場合、プロセッサは、支払プラットフォームが顧客によってプロセッサに提供されるフォーマットにおける値を受け入れるか否かを決定してもよい。支払プラットフォームが、顧客によってプロセッサに提供されるフォーマットにおける値を受け入れない場合、プロセッサは、請求者に行われることになる支払の額で資金付けされた（あるいは、支払の額に関係付けられた）、仮想開ループプリペイド記憶値カードまたはデビットカード番号を生成させる。
【００６２】
Ｓ５７０において、請求者の支払プラットフォームに、プロセッサからの値が送金される。この値は、顧客によってプロバイダに提供されるフォーマットにおける値であってもよく、あるいは、仮想開ループプリペイド記憶値カードまたはデビットカード番号における値であってもよい。
【００６３】
Ｓ５８０において、プロセッサは、顧客に、支払取引が実行されたことの確認を提供してもよい。この確認は、何らかの通信チャネルを介して贈られてもよく、何らかのフォーマットにおけるものであってもよい。
【００６４】
図６を参照して、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にするシステム６０をここで説明する。一般的に、システム６０は、１人以上の顧客６１０、プロセッサ６２０、および、請求者の１つ以上の支払プラットフォーム６３０を備える。１人以上の顧客６１０は、（これらに制限されるわけではないが、）インターネット、自動音声認識（ＩＶＲ）システム、メッセージング（ＳＭＳ、ＭＭＳ）、電子デバイス上で実行されるアプリケーションもしくはアプレット、キオスクからの通信、ポイントオブセールデバイス、端末、または、ロケーション、等のような、何らかの様々な通信チャネル６１５を通して、プロセッサ６２０と通信してもよい。
【００６５】
プロセッサ６２０は、顧客インターフェース６２１、請求者インターフェース６２２、処理モジュール６２３、ウェブデータ抽出モジュール６２４、値交換モジュール６２５、データベース６２６を備えてもよい。顧客インターフェースは、１人以上の顧客６１０とのインバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの顧客６１０は、異なる通信チャネル６１５を利用してもよいので、顧客通信インターフェース６２１は、異なる顧客の異なる通信チャネルにより、複数のインターフェースを集合的に識別してもよい。
【００６６】
顧客インターフェース６２１は、プロセッサと顧客との間の選択可能な通信を提供してもよく、顧客から、値、顧客の識別情報、プロバイダと顧客の既存のアカウントを識別するのに十分な情報、および、プロバイダに伴う既存の顧客のアカウントに対して行うための支払の額の識別を受け取るように構成されていてもよい。
【００６７】
請求者インターフェース６２２は、１つ以上の請求者および支払プラットフォーム６３０により、インバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの請求者６３０が、異なる通信属性を要求するかもしれない（例えば、何人かの請求者は、ＡＰＩを介した通信および支払取引を受け入れてもよく、他の請求者は、特定のウェブサイトまたはウェブベースの支払フォームを介した通信および支払取引を要求してもよい）ので、請求者インターフェース６２２は、複数の請求者による複数のインターフェースを集合的に識別してもよい。
【００６８】
請求者インターフェースは、プロセッサとプロバイダとの間の選択的な通信を提供してもよく、プロバイダの支払プラットフォームまたはウェブサイトにアクセスするように構成されていてもよく、プロバイダの支払プラットフォームまたはウェブサイトへと情報を提供してもよい。
【００６９】
処理モジュール６２３は、顧客インターフェース６２１、請求者インターフェース６２２、ウェブデータ抽出モジュール６２４、値交換モジュール６２５、データベース６２６を含む、プロセッサ６２０のそれぞれのコンポーネントと通信してもよい。処理モジュールは、すべての要求される決定および計算を実行するように構成されていてもよい。例えば、処理モジュール６２３は、顧客から受信された識別情報を、支払プラットフォームまたはウェブサイトへと、少なくとも入力するように、また、支払プラットフォームまたはウェブサイトへと値を提供するように構成されていてもよい。
【００７０】
ウェブデータ抽出モジュール６２４は、支払を行うために請求者によって要求された情報を決定するように構成されていてもよい。これは、支払プラットフォームのウェブページをスクラッピングすることと、何の情報が要求されているか、また、このような情報を適切に挿入するための場所を決定することとにより、実行されてもよい。
【００７１】
値交換モジュール６２５は、顧客によって提供された通りの第１のフォーマットで、値を受け入れて、（何らかの適用可能な手数料または税金をマイナスし、）請求者または支払プラットフォームによって受け入れられる、第２のフォーマットの値へと、それを交換するための手段を提供してもよい。例えば、値交換モジュール６２５は、閉ループ記憶値を受け入れて、これを、仮想開ループ記憶値またはデビットカードへと交換してもよい。
【００７２】
データベース６２６は、処理モジュール６２３に結合されていてもよく、顧客から受信された情報を記憶してもよく、また、請求者に伴う、既存の顧客アカウントに関する情報も記憶してもよい。例えば、特定のログインおよびパスワード情報を備える顧客支払アカウントが確立される、または、利用される場合、データベースは、特定の請求者および特定の顧客に関係する記録中に、要求されるログインおよびパスワード情報を記憶してもよい。データベースはまた、記録保持の目的のために、または、繰り返し発生する、もしくは、定期的な支払のために利用されてもよい、過去の取引情報を記憶してもよい。
【００７３】
図７を参照して、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にするシステム７０をここで説明する。一般的に、システム７０は、１人以上の顧客７１０、プロセッサ７２０、１つ以上の請求者７３０、および、１つ以上の金融機関７４０を備えていてもよい。１人以上の顧客７１０は、（これらに制限されるわけではないが、）インターネット、自動音声認識（ＩＶＲ）システム、メッセージング（ＳＭＳ、ＭＭＳ）、電子デバイス上で実行されるアプリケーションもしくはアプレット、キオスクからの通信、ポイントオブセールデバイス、端末、または、ロケーション、等のような、何らかのさまざまな通信チャネル７１５を通して、プロセッサ７２０と通信してもよい。
【００７４】
１つ以上の請求者７３０は、１人以上の顧客７１０に対して商品もしくはサービスを販売するプロバイダを含んでいてもよく、あるいは、プロバイダのために、または、プロバイダの代理で請求機能を実行する商品もしくはサービスのプロバイダとは別個のエンティティを含んでいてもよい。１つ以上の金融機関７４０は、１人以上の顧客７１０が、１つ以上の請求者７３０に対して、支払を行うために使用されてもよいファイナンシャルアカウントをそこに有する金融機関を含んでもよい。
【００７５】
プロセッサ７２０は、顧客インターフェース７２１、請求者インターフェース７２２、資金源インターフェース７２３、処理モジュール７２４、ウェブデータ抽出モジュール７２５、ウェブアプリケーションモジュール７２６、値交換モジュール７２７、仮想プリペイドデビットカード生成機７２８、および、データベース７２９を備えてもよい。
【００７６】
顧客インターフェース７２１は、１人以上の顧客７１０とのインバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの顧客７１０は、異なる通信チャネル７１５を利用してもよいので、顧客通信インターフェース７２１は、異なる顧客の異なる通信チャネルにより、複数のインターフェースを集合的に識別してもよい。
【００７７】
顧客インターフェース７２１は、プロセッサと顧客との間の選択可能な通信を提供してもよく、顧客から、値、顧客の識別情報、プロバイダと顧客の既存のアカウントを識別するのに十分な情報、および、プロバイダとともに既存の顧客のアカウントに対して行うための支払の額の識別を受け取るように構成されていてもよい。
【００７８】
請求者インターフェース７２２は、１つ以上の請求者および支払プラットフォーム７３０により、インバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの請求者７３０が、異なる通信属性を要求するかもしれない（例えば、何人かの請求者は、ＡＰＩを介した通信および支払取引を受け入れてもよく、他の請求者は、特定のウェブサイトまたはウェブベースの支払フォームを介した通信および支払取引を要求してもよい）ので、請求者インターフェース７２２は、複数の請求者による複数のインターフェースを集合的に識別してもよい。
【００７９】
請求者インターフェース７２２は、プロセッサ７２０とプロバイダまたは請求者７３０との間の選択的な通信を提供してもよく、プロバイダまたは請求者の支払プラットフォームもしくはウェブサイトにアクセスするように構成されていてもよく、プロバイダまたは請求者の支払プラットフォームもしくはウェブサイトへと情報を提供してもよい。
【００８０】
資金源インターフェース７２３は、１つ以上の資金源とのインバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの請求者７３０が、異なる通信属性を要求するかもしれない（例えば、何人かの請求者は、ＡＰＩを介した通信および支払取引を受け入れてもよく、他の請求者は、特定のウェブサイトもしくはウェブベースの支払フォームを介した通信および支払取引を要求してもよい）ので、資金源インターフェース７２３は、複数の請求者による複数のインターフェースを集合的に識別してもよい。
【００８１】
処理モジュール７２４は、プロセッサ７２０の、他のすべてのコンポーネントと通信してもよい。処理モジュール７２４は、図１−５において、また、それらに付随する説明において述べたように、支払取引を実行するのに必要な、すべての決定を実行してもよい。
【００８２】
ウェブデータ抽出モジュール７２５は、支払を行うために請求者によって要求された情報を決定するように構成されていてもよい。これは、支払プラットフォームのウェブページをスクラッピングすることと、何の情報が要求されているか、また、このような情報を適切に挿入するための場所を決定することとにより、実行されてもよい。
【００８３】
ウェブアプリケーションモジュール７２６は、請求者の支払プラットフォームウェブサイトと対話してもよく、さまざまな請求者の支払プラットフォームシステム中、または、さまざまな請求者の支払プラットフォームシステム上で、適切なフィールド、ボックス、もしくは、エントリエリアへと、適切な情報を挿入するために利用されてもよい。
【００８４】
値交換モジュール７２７は、顧客によって提供された通りの第１のフォーマットで、値を受け入れて、（何らかの適用可能な手数料または税金をマイナスし、）請求者または支払プラットフォームによって受け入れられる第２のフォーマットの値へと、それを交換するための手段を提供してもよい。顧客から受け取られた値が、仮想開ループ記憶値またはデビットカードへと交換されることになるとき、値交換モジュール７２７は、仮想プリペイドデビットカード生成機７２８と対話してもよい。仮想プリペイドデビットカード生成機７２８は、請求者に対して行われることになる支払に等しい額において資金付けされた、請求者によって受け入れられてもよい仮想デビットカード（例えば、ＶｉｓａまたはＭａｓｔｅｒＣａｒｄブランド付けされたプリペイドデビットカード）を生成してもよい。
【００８５】
データベース７２９は、処理モジュール７２４に結合されていてもよく、顧客から受信された情報を記憶してもよく、また、請求者に伴う、既存の顧客アカウントに関する情報も記憶してもよい。例えば、特定のログインおよびパスワード情報を備える顧客支払アカウントが確立される、または、利用される場合、データベースは、特定の請求者および特定の顧客に関係する記録中に、要求されるログインおよびパスワード情報を記憶してもよい。データベースはまた、記録保持の目的のために、または、繰り返し発生する、もしくは、定期的な支払のために利用されてもよい、過去の取引情報を記憶してもよい。
【００８６】
ここで示し、記述した、本発明の特定の実施形態は、単に例示的なものであることが理解されるだろう。数々の変形、変更、置換、および、同等物が、本発明の精神と範囲を逸脱することなく、当業者にとって、ここで、あり得るものとなるだろう。例として、プロセッサは、金融機関、資金源、マーチャント、または、請求者によって維持もしくは管理されてもよい。したがって、ここで記述し、添付の図面において示したすべての主題は、単に例示的なものであり、制限的な意味におけるものでないとしてみなされることが意図されており、本発明の範囲は、添付の特許請求の範囲のみによって、決定されるだろうことが意図されている。
【図１】
2013538400.tif 000003
【図２】
2013538400.tif 000004
【図３】
2013538400.tif 000005
【図４】
2013538400.tif 000006
【図５】
2013538400.tif 000007
【図６】
2013538400.tif 000008
【図７】
2013538400.tif 000009
【国際調査報告】
2013538400.tif 000010