特許第5694534号(P5694534)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ イー2インタラクティブ,インコーポレーテッド・ディー/ビー/エー・イー2インタラクティブ,インコーポレーテッドの特許一覧

特許5694534支払プラットフォームを利用した、顧客勘定の支払のシステムと方法
<>
  • 特許5694534-支払プラットフォームを利用した、顧客勘定の支払のシステムと方法 図000002
  • 特許5694534-支払プラットフォームを利用した、顧客勘定の支払のシステムと方法 図000003
  • 特許5694534-支払プラットフォームを利用した、顧客勘定の支払のシステムと方法 図000004
  • 特許5694534-支払プラットフォームを利用した、顧客勘定の支払のシステムと方法 図000005
  • 特許5694534-支払プラットフォームを利用した、顧客勘定の支払のシステムと方法 図000006
  • 特許5694534-支払プラットフォームを利用した、顧客勘定の支払のシステムと方法 図000007
  • 特許5694534-支払プラットフォームを利用した、顧客勘定の支払のシステムと方法 図000008
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5694534
(24)【登録日】2015年2月13日
(45)【発行日】2015年4月1日
(54)【発明の名称】支払プラットフォームを利用した、顧客勘定の支払のシステムと方法
(51)【国際特許分類】
   G06Q 20/16 20120101AFI20150312BHJP
【FI】
   G06Q20/16 100
【請求項の数】25
【全頁数】24
(21)【出願番号】特願2013-525913(P2013-525913)
(86)(22)【出願日】2011年7月11日
(65)【公表番号】特表2013-538400(P2013-538400A)
(43)【公表日】2013年10月10日
(86)【国際出願番号】US2011043525
(87)【国際公開番号】WO2012027026
(87)【国際公開日】20120301
【審査請求日】2013年4月26日
(31)【優先権主張番号】12/807,046
(32)【優先日】2010年8月26日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】505161378
【氏名又は名称】イー2インタラクティブ,インコーポレーテッド・ディー/ビー/エー・イー2インタラクティブ,インコーポレーテッド
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100109830
【弁理士】
【氏名又は名称】福原 淑弘
(74)【代理人】
【識別番号】100088683
【弁理士】
【氏名又は名称】中村 誠
(74)【代理人】
【識別番号】100103034
【弁理士】
【氏名又は名称】野河 信久
(74)【代理人】
【識別番号】100095441
【弁理士】
【氏名又は名称】白根 俊郎
(74)【代理人】
【識別番号】100075672
【弁理士】
【氏名又は名称】峰 隆司
(74)【代理人】
【識別番号】100119976
【弁理士】
【氏名又は名称】幸長 保次郎
(74)【代理人】
【識別番号】100153051
【弁理士】
【氏名又は名称】河野 直樹
(74)【代理人】
【識別番号】100140176
【弁理士】
【氏名又は名称】砂川 克
(74)【代理人】
【識別番号】100158805
【弁理士】
【氏名又は名称】井関 守三
(74)【代理人】
【識別番号】100124394
【弁理士】
【氏名又は名称】佐藤 立志
(74)【代理人】
【識別番号】100112807
【弁理士】
【氏名又は名称】岡田 貴志
(74)【代理人】
【識別番号】100111073
【弁理士】
【氏名又は名称】堀内 美保子
(74)【代理人】
【識別番号】100134290
【弁理士】
【氏名又は名称】竹内 将訓
(72)【発明者】
【氏名】スミス、メリル・ブルックス
(72)【発明者】
【氏名】グレーブス、フィリップ・クライグ
(72)【発明者】
【氏名】チャキリス、フィル・エム.
【審査官】 山本 雅士
(56)【参考文献】
【文献】 米国特許出願公開第2003/0191711(US,A1)
【文献】 特表2009−512024(JP,A)
【文献】 米国特許出願公開第2009/0204522(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 − 50/34
(57)【特許請求の範囲】
【請求項1】
商品またはサービスのプロバイダに関する既存の顧客アカウントへ支払を提供するコンピュータ化された方法において、
前記方法は、顧客、商品またはサービスのプロバイダ、および、中央プロセッサの間で促進され、
前記方法は、
値と;前記顧客の識別情報と;前記プロバイダと前記既存の客アカウントとを識別するのに十分な情報とを、前記顧客から、前記中央プロセッサにおいて受け取ることと、
前記プロバイダの支払プラットフォームに前記中央プロセッサによりアクセスすることと、
前記プロバイダの前記支払プラットフォームを利用して前記既存の客アカウントへ支払を提供するために、前記プロバイダの前記支払プラットフォームによって要求される情報を前記中央プロセッサにより決定することと、
前記既存の客アカウントへ支払を提供するために、前記プロバイダの前記支払プラットフォームによって要求される情報を前記中央プロセッサから前記プロバイダの前記支払プラットフォームへ通信することと、
前記顧客から受け取った値の形式で、前記プロバイダが前記支払プラットフォームを介して支払を受け入れるか否かを、前記中央プロセッサにより決定することと、
前記顧客から受け取った値の形式で、前記プロバイダが前記支払プラットフォームを介して支払を受け入れないという決定があると、前記プロバイダの前記支払プラットフォームに提供される値に等しい額が資金付けされた仮想プリペイドデビットカード番号を、前記中央プロセッサにより生成することと、
関係付けられた値を前記既存の客アカウントへ搬送するために、前記仮想プリペイドデビットカード番号を前記プロバイダの前記支払プラットフォームに、前記中央プロセッサにより提供することと
を含む方法。
【請求項2】
前記値と;前記顧客の識別情報と;前記プロバイダと前記既存の顧客アカウントとを識別するのに十分な情報は
インターネット、自動音声認識(IVR)システム、ショートメッセージサービス(SMS)を介して送られるメッセージ、メディアメッセージサービス(MMS)を介して送られるメッセージ、移動体デバイス上で実行されるアプリケーション、キオスク、ポイントオブセールデバイス、またはマーチャントロケーションからの通信と、からなるグループのうちから選択されるやり方を介して受け取られる、請求項1記載の方法。
【請求項3】
前記顧客から受け取った値は、記憶値アカウントへのアクセスを含む、請求項1記載の方法。
【請求項4】
前記記憶値アカウントは、閉ループ記憶値アカウントである、請求項3記載の方法。
【請求項5】
前記顧客から受け取った値は、前記顧客によってポイントオブセールデバイスに対して行われた支払を含み、
前記中央プロセッサは、後の時間において、前記ポイントオブセールデバイスとともに精算する、請求項1記載の方法。
【請求項6】
前記顧客の識別情報は、前記既存の客アカウントへ支払を行うために、前記プロバイダの前記支払プラットフォームによって要求される情報を含む、請求項1記載の方法。
【請求項7】
前記識別情報は、ログイン情報およびパスワードを含む、請求項6記載の方法。
【請求項8】
前記プロバイダと前記既存の顧客アカウントとを識別するのに十分な情報は、アカウント番号を含む、請求項1記載の方法。
【請求項9】
前記プロバイダと前記既存の顧客アカウントとを識別するのに十分な情報は、前記プロバイダに関する前記顧客のアカウントに関係するしるしを含む、請求項1記載の方法。
【請求項10】
前記しるしは電話番号を含む、請求項9記載の方法。
【請求項11】
前記プロバイダの支払プラットフォームにアクセスするステップは、インターネットを介して前記中央プロセッサにより達成される、請求項1記載の方法。
【請求項12】
前記プロバイダの支払プラットフォームにアクセスするステップは、前記プロバイダにより管理されている支払ウェブページ、または、前記プロバイダに関係する支払ウェブページに、前記中央プロセッサによりアクセスすることを含む、請求項1記載の方法。
【請求項13】
記プロバイダの前記支払プラットフォームによって要求される情報を決定するステップは、前記プロセッサによって実行される、ウェブスクラッピング、または、ウェブデータ抽出プログラムを介して、前記中央プロセッサによって達成される、請求項1記載の方法。
【請求項14】
前記既存の客アカウントへ支払を提供するために、前記プロバイダの前記支払プラットフォームによって要求される情報を前記中央プロセッサから前記プロバイダの前記支払プラットフォームへ通信するステップは、
前記顧客から受信された識別情報を適切なフィールドへ前記プロバイダの前記支払プラットフォームにおいて挿入すること
を含む、請求項1記載の方法。
【請求項15】
記プロバイダの前記支払プラットフォームによって要求される情報を前記中央プロセッサから前記プロバイダの前記支払プラットフォームへ通信するステップは、
前記プロバイダの前記支払プラットフォームにより要求される情報のそれぞれの断片を識別することと、
前記顧客から受信された識別情報から、適切な情報を決定することと、
前記プロバイダの前記支払プラットフォームにより要求される情報のそれぞれの断片に応答して、前記適切な情報を提供することと
を含む、請求項1記載の方法。
【請求項16】
前記プロバイダの前記支払プラットフォームによって要求される情報を通信するステップは、
オンラインフォームへ自動入力すること
を含む、請求項15記載の方法。
【請求項17】
前記既存の客アカウントへ値搬送するステップは、
前記顧客から受け取った値を、前記プロバイダに関する前記既存の客アカウントへ送信すること
を含む、請求項1記載の方法。
【請求項18】
前記既存の客アカウントへ搬送される値は、適用可能な手数料および税金が減額された、前記顧客から受け取った値の残りである、請求項17記載の方法。
【請求項19】
値は、ポイントオブセールデバイスにおいて、前記顧客から受け取られ、
前記適用可能な手数料および税金は、前記既存の客アカウントに関係するロケーション、前記ポイントオブセールデバイスのロケーション、前記中央プロセッサのロケーションと、前記プロバイダのロケーションと、からなるグループから選択される1つ以上の要因に基づいて計算される、請求項18記載の方法。
【請求項20】
商品またはサービスのプロバイダに関する既存の顧客アカウントへ支払を提供するコンピュータ化された方法において、
前記方法は、顧客、商品またはサービスのプロバイダ、および、中央プロセッサの間で促進され、
前記方法は、
値と;前記顧客の名前および住所を含む前記顧客の識別情報と;前記既存の顧客アカウントのアカウント番号を含む前記既存の顧客アカウントと前記プロバイダとを識別するのに十分な情報と;前記既存の顧客アカウントに支払を行う額の識別とを、前記顧客から前記中央プロセッサにより受け取ることと
ンターネットを介して、前記プロバイダの支払ウェブサイトに、前記中央プロセッサによりアクセスすることと、
支払を行うのに前記プロバイダによって要求される情報を決定するために、前記支払ウェブサイトを前記中央プロセッサによりスクラッピングすることと、
前記中央プロセッサが、前記顧客の代わりに動作して、前記顧客から受け取った識別情報を、前記支払ウェブサイトへ入力することと、
前記顧客から受け取った値の形式、前記プロバイダが前記支払ウェブサイトを介して支払を受け入れるか否かを、前記中央プロセッサにより決定することと、
前記顧客から受け取った値の形式で、前記プロバイダが前記支払ウェブサイトを介して支払を受け入れるという決定があると、前記顧客から受け取った値を、前記支払ウェブサイトを介して前記プロバイダに搬送することと、
前記顧客から受け取った値の形式で、前記プロバイダが前記支払ウェブサイトを介して支払を受け入れないという決定があると、前記プロバイダに対して行われる支払に等しい額が資金付けされた仮想プリペイドデビットカード番号を生成して、前記仮想プリペイドデビットカード番号を、前記支払ウェブサイトを介して前記プロバイダに搬送することと、
前記顧客に対して支払の確認を提供することと
を含む方法。
【請求項21】
前記値と;前記顧客の識別情報と;前記既存の顧客アカウントと前記プロバイダとを識別するのに十分な情報と;前記既存の顧客アカウントに支払を行う額の識別とは
インターネット、自動音声認識(IVR)システム、ショートメッセージサービス(SMS)を介して送られるメッセージ、メディアメッセージサービス(MMS)を介して送られるメッセージ、移動体デバイス上で実行されるアプリケーション、キオスク、ポイントオブセールデバイス、またはマーチャントロケーションとからの通信と、からなるグループのうちから選択されるやり方を介して受け取られる、請求項20記載の方法。
【請求項22】
前記顧客から受け取った値は、前記顧客によってポイントオブセールデバイスに対して行われた支払を含み、
前記中央プロセッサは、後の時間において、前記ポイントオブセールデバイスとともに精算する、請求項20記載の方法。
【請求項23】
前記顧客から受け取った値は、記憶値アカウントへのアクセスを含む、請求項20記載の方法。
【請求項24】
前記記憶値アカウントは、閉ループ記憶値アカウントである、請求項23記載の方法。
【請求項25】
前記顧客から受け取った値は、マーチャントのみにより引き換え可能である閉ループ記憶値カードを使用して、前記マーチャントにおいて、前記顧客により行われた支払を含む、請求項24記載の方法。
【発明の詳細な説明】
【関連出願】
【0001】
本出願は、2009年9月22日に出願され、(ここで参照によりその全体が組み込まれている)米国特許出願シリアル番号第12/564,474号に対する優先権を主張し、第12/564,474号出願は、2007年2月7日に出願され、(ここで参照によりその全体が組み込まれている)米国特許出願シリアル番号第11/672,082号の継続出願であり、第11/672,082号出願は、2007年1月16日に出願され、(ここで参照によりその全体が組み込まれている)米国仮特許出願第60/885,044号に基づいている。
【発明の背景】
【0002】
本発明は、一般的に、第三者の請求者に、または、指示された受取人に、顧客の勘定を支払うのに利用されるシステムおよび方法に向けられている。より詳細には、本発明は、典型的な支払チャネルを回避して、代わりに、受取人自身の支払プラットフォームを利用するシステムおよび方法に向けられている。
【0003】
顧客のファイナンシャルアカウントにリンクされている繰り返し発生する支払プランから、最大手の金融機関により提供されるオンライン勘定支払にわたる、数多くの勘定支払プログラムおよびプランがある。このような勘定支払システムは、銀行を利用していない母集団にフォーカスしていることが多く、為替またはウェスタンユニオンのような、従来技術の方法より効率的で、費用の掛からない勘定支払の方法を提供してもよい。
【0004】
支払プロセッサによって維持および動作される、多くの勘定支払システムは、顧客に、支払われることになるアカウントに関する情報を入力することと、支払プロセッサに対して資金を提供することとを要求する。一般的に、支払プロセッサは、従来の方法、典型的に値の送金を通して、顧客によって、識別された勘定を支払う。このような値の送金は、典型的に、勘定アグリゲータの使用を通して達成される。勘定アグリゲータは、一般的に、1つの会社からの支払記録を集めて、この記録を、別の勘定システムへポストする。典型的に、顧客が、その電力会社に対する勘定を支払うために、勘定支払プロセッサ“A”を使用する場合、取引は、典型的に、以下のようである:(i)顧客が支払プロセッサ“A”に対して、金銭(通貨)を支払う、(ii)支払プロセッサ“A”は、勘定アグリゲータ(例えば、RPS、チェックフリー)に支払う、(iii)勘定アグリゲータが電力会社に支払う。
【0005】
このプロセスは、勘定アグリゲータによって提供される、手形交換所機能に対して有用であることが多いが、これは、余分な値の送金を含んでおり、それに伴う手数料、費用、チャージ、および、リスクのすべてを含む。
【0006】
したがって、勘定アグリゲータを不要にするシステムが望ましい。しかしながら、ほとんどの勘定アグリゲータによって提供される接続を回避するために、受取人(または、支払われることになる商品またはサービスのプロバイダ)の支払プラットフォームに対するいくつかのリンクが、維持および/またはアクセスされなければならない。ますます多くのプロバイダが、支払を受け入れる追加の手段として、インターネットを介して、顧客によって典型的に、アクセスされる、それら自身の支払プラットフォームを維持する方向に進んでいる。したがって、代わりに、プロバイダまたは受取人の支払プラットフォームに直接アクセスすることによって、勘定アグリゲータを使用することを回避できるシステムが望ましい。
【0007】
勘定アグリゲータの欠点に加えて、ほとんどの勘定支払システムは、特定の方法で、典型的には、アカウントセットアップまたは支払の時間において現金で、勘定支払システムに資金付けすることを要求する。記憶値カードのユビキタスな性質からして、支払オプションとして記憶値カードを利用する勘定支払システムが望ましい。しかしながら、数多くのプロバイダまたは受取人は、記憶値、特に、閉ループシステムに関連した記憶値を受け入れないかもしれない。したがって、典型的に、顧客からの閉ループ記憶値を受け入れるが、プロバイダまたは受取人に対して、開ループ記憶値(例えば、プリペイドVisa(登録商標)デビットカード番号)を提供するシステムと方法を維持することが望ましい。
【発明の概要】
【0008】
本発明の観点は、商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供する方法を含んでもよい。方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進され、方法は、値と;顧客の識別情報と;プロバイダと顧客の既存のアカウントとを識別するのに十分な情報とを顧客から受け取ることと、プロバイダの支払プラットフォームにアクセスすることと、顧客のアカウントへと支払を提供するために、プロバイダによって要求される情報を決定することと、顧客のアカウントへと支払を提供するために、プロバイダによって要求される情報を通信することと、顧客のアカウントへと値を提供することとを含む。
【0009】
本発明の、他の観点は、商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供する方法を含んでもよい。方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進され、方法は、値と;顧客の名前および住所を含む顧客の識別情報と;既存の顧客のアカウントのアカウント番号を含む、プロバイダと顧客の既存のアカウントとを識別するのに十分な情報と;プロバイダに伴う既存の顧客のアカウントに支払を行う額の識別とを顧客から受け取ることと、プロセッサによって、インターネットを介して、プロバイダの支払ウェブサイトにアクセスすることと、支払を行うのにプロバイダによって要求される情報を決定するために、支払ウェブサイトをスクラッピングすることと、プロバイダが、顧客の代わりに動作して、顧客から受け取った識別情報を、支払ウェブサイトへと入力することと、顧客から受け取った値の形式において、プロバイダが支払を受け入れるか否かを決定することと、顧客から受け取った値の形式で、プロバイダが支払を受け入れるという決定があると、顧客から受け取った値を、プロバイダに搬送することと、顧客から受け取った値の形式で、プロバイダが支払を受け入れないという決定があると、仮想プリペイドデビットカード番号を生成して、仮想プリペイドデビットカード番号を、プロバイダに搬送することと、顧客に対して支払の確認を提供することとを含む。
【0010】
本発明の、他の観点は、商品またはサービスのプロバイダに伴う顧客の既存の顧客のアカウントへと支払を提供するプロセッサを含んでもよい。プロセッサは、顧客、および、プロバイダとともに選択的に通信し、プロセッサは、プロセッサと顧客との間の選択的な通信を提供する顧客インターフェースと、プロセッサとプロバイダとの間の選択的な通信を提供するプロバイダインターフェースと、プロバイダインターフェースと通信する、ウェブデータ抽出モジュールと、顧客インターフェース、プロバイダインターフェース、ウェブデータ抽出モジュールと通信する処理モジュールとを具備し、顧客インターフェースは、値と;顧客の名前および住所を含む顧客の識別情報と;既存の顧客のアカウントのアカウント番号を含む、プロバイダと顧客の既存のアカウントとを識別するのに十分な情報と;プロバイダに伴う既存の顧客のアカウントに支払を行う額の識別とを顧客から受け取るように構成されており、プロバイダインターフェースは、プロバイダの支払プラットフォームまたはウェブサイトにアクセスし、プロバイダの支払プラットフォームまたはウェブサイトに情報を提供するように構成されており、ウェブデータ抽出モジュールは、支払を行うために、プロバイダによって要求される情報を決定するように構成されており、処理モジュールは、顧客から受け取った識別情報を、支払プラットフォームまたはウェブサイトへと入力し、支払プラットフォームまたはウェブサイトへと値を提供するように構成されている。
【0011】
これらのおよび他の観点は、以下の図面を考慮して、本発明の以下の詳細な説明から明らかになるだろうが、本発明の新規な概念の精神と範囲から逸脱することなく、変形および修正を生じさせるだろう。
【図面の簡単な説明】
【0012】
本発明は、同一の参照識別子が同一のエレメントを表すのに使用されている、添付の図面とともに、以下の詳細な説明を読むことによって、より完全に理解されることができる。添付の図面は、ある例示的な実施形態を図示し、以下の詳細な説明を理解するのを支援してもよい。本発明の何らかの実施形態を詳細に説明する前に、本発明は、以下の詳細な説明に述べる、または、図面に図示する、コンポーネントの配置および構成の詳細に、その応用において制約されないことを理解すべきである。図示された実施形態は、例として理解されるべきものであり、決して、本発明の全体の範囲を制限するものではない。また、ここで用いられる語法および用語法は、説明の目的のためのものであり、制限的なものとしてみなされるべきでないことを理解すべきである。詳細な説明は、以下の図面に対する参照を行うだろう。
図1図1は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法を図示する。
図2図2は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法を図示する。
図3図3は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法を図示する。
図4図4は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法の一部として、請求者により受け入れられる資金付けオプションを決定するプロセスを図示する。
図5図5は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にする方法を図示する。
図6図6は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にするシステムを図示する。
図7図7は、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にするシステムを図示する。
【0013】
本発明の何らかの実施形態を詳細に説明する前に、本発明は、以下の詳細な説明に述べる、または、図面に図示する、コンポーネントの配置および構成の詳細に、その応用において制約されないことを理解すべきである。本発明は、他の実施形態が可能であり、そして、さまざまな方法において実施または実行されてもよい。また、ここで用いられる語法および用語法は、説明の目的のためのものであり、制限的なものとしてみなされるべきでないことを理解すべきである。
【発明の詳細な説明】
【0014】
この説明において、例示される事項は、添付の図面を参照して開示される、さまざまな例示的な実施形態の包括的な理解において支援するために提供されている。したがって、当業者は、特許請求された発明の精神および範囲から逸脱することなく、ここで記述した例示的な実施形態のさまざまな変更および修正を行うことができることを理解するだろう。周知の機能および構成の説明は、明瞭さと分かり易さのために、省略した。さらに、ここで使用するように、単数形は、複数形において解釈されてもよく、また、代わりに、複数形の何らかの用語は、単数形であるとして解釈されてもよい。“S”で始まる参照図面(例えば、S100)は、ステップを表す。
【0015】
一般的に、本発明は、勘定支払プログラムを実行するシステムおよび方法に向けられていてもよい。特に、本発明は、顧客が、さまざまな個人およびアカウント識別情報をプロセッサに提供し、プロセッサが、顧客として動作して、直接の支払を提供するために、請求者の支払プラットフォーム(例えば、支払ウェブページ)を利用する、勘定支払プログラムに向けられている。ここで説明するシステムと方法はまた、プロセッサが、仮想プリペイドデビットカード(例えば、Visaのブランド付けされたデビットカード番号)を、支払として請求者に提供しながら、(例えば、ウォールマート(登録商標)ギフトカードのような、閉ループ記憶値を含む)記憶値を支払として受け入れることに備える。
【0016】
図1を参照して、本発明のいくつかの実施形態にしたがった、勘定の支払の方法10をここで説明する。図1に図示した方法は、一般的に、顧客、プロセッサ、および、請求者の間で促進される。
【0017】
顧客は、支払を行うために勘定支払システムを利用する、何らかの当事者であってもよい。支払を行う当事者は、債務を引き起こした、すなわち、支払から利益を受けることになる当事者と同一であってもよいとして、以下の説明は提示するが、必ずしもそうでなくてもよい。言い換えると、ここで提示する、勘定支払システムおよび方法は、商品またはサービスのプロバイダに伴う既存の顧客アカウントに対して支払を提供する手段を提供する。しかしながら、既存のアカウントに支払を提供する“顧客”は、既存のアカウントを所有する、または、そうでなければ既存のアカウントから利益を受ける当事者と、同一でなくてもよい。このことの例は、親が、その親の子供、または、扶養家族名義において維持されているアカウントへと支払を行うことであってもよい。
【0018】
プロセッサは、顧客からの通信を受け取って、請求者と対話する当事者、より詳細には、請求者の支払プラットフォームまたはウェブサイトと対話する当事者である。以下の説明では、プロセッサを、別個の中間システムとして提示するかもしれないが、プロセッサは、1つ以上の請求者に関係していてもよく、または、小売業者もしくはマーチャントに関係付けられていてもよく、小売業者もしくはマーチャントの一部であってもよいことが企図されている。
【0019】
請求者は、既存の顧客のアカウントを保持する当事者である。一般的にいうと、請求者は、商品またはサービスのプロバイダであってもよいが、プロバイダの勘定と収集の側面は、別個の無関係の当事者へとアウトソーシングされてもよい。本発明は、このシナリオもまたカバーすることを意図しており、したがって、用語“請求者”および“商品またはサービスのプロバイダ”は、関連することを意図している。“請求者”は、“商品またはサービスのプロバイダ”であってもよいが、“商品またはサービスのプロバイダ”は、“請求者”である必要はない。
【0020】
顧客、プロセッサ、および、請求者の間の通信は、このような通信が直接であるかのように、以下で説明する。しかしながら、このような通信は、追加の当事者またはデバイスを要求してもよい。例えば、顧客は、インターネット、電話(例えば、自動音声認識(IVR)システム)、メッセージングシステム(例えば、ショートメッセージサービス(SMS)、または、メディアメッセージサービス(MMS))、さまざまな電子デバイス上で実行されるアプリケーションもしくはアプレット、ポイントオブセール端末もしくはデバイス、あるいは、マーチャント通信を介して、対話してもよい。中間デバイスまたは当事者が利用される環境(例えば、マーチャントまたはマーチャントロケーションにおける、ポイントオブセールデバイスの使用)では、精算は、中間当事者とプロセッサとの間で確立される、通常サイクル上で発生してもよい。このような環境では、プロセッサが支払を行ったが、顧客からまだ収集していないときの時間期間があってもよい。
【0021】
プロセッサと通信している顧客の例は、様々な通信のチャネルを含んでもよい。例えば、顧客は、プロセッサと登録してもよく、第1のチャネル、例えば、インターネットを介して、何らかの初期情報を提供してもよいが、次に、第2のチャネル、例えば、マーチャントにおけるインレーン取引の間に、マーチャントのポイントオブセールデバイスおよびマーチャント対プロセッサ通信リンクを介して、勘定の支払を要求してもよい。
【0022】
図1は、本発明の非常に基本的な意味で、3つのステップを含む、いくつかの実施形態を表す。第1に、S110において、プロセッサは、顧客からのさまざまな情報の断片を受信し、情報は、例として、(i)個人識別情報;(ii)請求者アカウント情報;および(iii)資金アカウント情報を含む。
【0023】
個人識別情報は、顧客アカウントに対して支払を行うために、請求者によって要求される情報を含んでいてもよい。例えば、個人識別情報は、顧客の名前、住所、生年月日、ログイン情報、および、パスワード情報を含んでもよい。
【0024】
請求者アカウント情報は、プロセッサが、特定の請求者と、請求者に伴う、特定のアカウントとを識別するのに十分な情報を含んでもよい。例えば、請求者アカウント情報は、請求者の識別子と、既存の顧客アカウントのアカウント番号とを含んでいてもよい。いくつかの環境では、また、本発明のいくつかの実施形態にしたがうと、請求者アカウント情報は、特定のデバイスに関係付けられた情報であってもよく、次に、特定のデバイスは、アカウントに関係付けられている。例えば、請求者アカウント情報は、電子デバイスの電話番号を含んでもよい。このような電話番号は、プロバイダと、プロバイダとともにある、顧客のアカウント番号を決定するのに十分であってもよい。
【0025】
資金アカウント情報は、勘定支払取引を資金付けするのに使用される、情報、または、値自体を含んでもよい。資金アカウント情報は、ファイナンシャルアカウント情報(例えば、当座預金アカウント情報)、記憶値アカウント情報(例えば、記憶値アカウント番号)、または、そこからの値が、支払のために引き落とされてもよい、他の任意のタイプのアカウント情報を含んでもよい。
【0026】
“記憶値”は、典型的に、その中に保持される値を有する、関係するアカウントを有するしるしを指す。したがって、プリペイドVisaデビットカード、または、ウォールマートギフトカード上のアカウント番号のような、記憶値アカウント番号の支給は、値を運ぶとして考えられてもよい。“記憶値”は、当業者の一人が理解するように、“開ループ”、または、“閉ループ”として規定されてもよい。例えば、“閉ループ”記憶値は、一般的に、第1の例において、記憶値を発行または提供する当事者(または、その代表者)によって制限されることが多い、制限された数の当事者によって、償還されてもよい。例として、ウォールマートギフトカードは、ウォールマートにおいてのみ償還可能であって、他の場所では使用できないため、ウォールマートギフトカードは、閉ループ記憶値カードである。プリペイドVisa、MasterCard(登録商標)、Discover(登録商標)、または、American Express(登録商標)記憶値カードは、“開ループ”として考慮される。このような値は、Visa、MasterCard、Discover、または、American Expressを受け入れるロケーションにおいてのみ償還されてもよいが、償還のロケーションは、記憶値を発行または提供した当事者に結び付けられてはいない。
【0027】
S120において、プロセッサは、請求者の支払プラットフォームに直接アクセスして、請求者に、支払を行うために要求される情報を提供してもよい。例えば、プロセッサは、顧客の名前、住所、および/または、アカウント番号を提供することを要求されてもよい。
【0028】
S130において、プロセッサは、請求者の支払プラットフォーム上で、支払を提供してもよい。例えば、いくつかの実施形態では、プロセッサは、顧客によって識別された資金アカウントからの値の、請求者に対する値(マイナス、適用可能な手数料または税金)の直接の送金を促進してもよい。本発明のいくつかの実施形態では、プロセッサは、1つのフォーマットにおいて、顧客からの値を受け取ってもよく、請求者によって受け入れられるフォーマットにおける値に対して、このような受け取った値を交換してもよい。例えば、顧客は、プロセッサに、閉ループ記憶値を提供してもよく、プロセッサは、開ループ記憶値を使用して、請求者に支払ってもよい。
【0029】
図1に図示した方法10から理解されるように、プロセッサは、顧客の立場に立っており、請求者と直接勘定支払取引を実行する。勘定支払システムは、複数の請求者とともに、様々な取引を実行してもよいので、本発明のいくつかの実施形態にしたがった方法およびシステムが、顧客にとって利益のあるものであってもよく、また、有利であってもよい。例えば、個人識別情報が、プロセッサによって保存されてもよい。複数の請求者に伴う、様々な請求者アカウント情報は、プロセッサによって保存されてもよい。したがって、複数の請求者に対する将来の勘定支払取引は、顧客およびプロセッサの間の単一の取引によって実行されてもよい。さらに、プロセッサは、請求者とともに直接、作動するので、顧客アカウントに対する支払は、伝統的な支払技術(例えば、小切手を送ること、または、支払アグリゲータを利用すること)にしたがった場合にかかることになるよりも、すばやくポストされてもよい。
【0030】
図2は、請求者の支払プラットフォームを利用して、顧客の勘定の支払を促進する方法20を図示する。図2に図示した方法は、方法の登録コンポーネント(顧客からプロセッサに対する情報の支給)を、方法の支払コンポーネント(勘定を支払うための、顧客からプロセッサに対する値の支給)から分ける。
【0031】
S210において、プロセッサは、顧客から(i)個人識別情報と;(ii)請求者アカウント情報とを受信する。上記のように、この情報は、何らかの方法で、また、何らかのチャネルを介して、顧客から受信されてもよい。
【0032】
S220において、プロセッサは、顧客から資金を受け取ってもよい。このステップS220は、実際の資金の受け取り、または、その中で実際の資金もしくは値が見受けられてもよい、アカウント情報の受け取りを含んでもよい。S210およびS220の間で、かなりの時間期間が経過してもよいことと、顧客とプロセッサとの間の通信のチャネルは、S210およびS220において同一である必要はないこととに留意すべきである。
【0033】
S230において、プロセッサは、請求者の支払プラットフォームにアクセスしてもよい。本発明のいくつかの実施形態にしたがうと、支払プラットフォームは、それを通して顧客が、請求者に伴う、彼または彼女のアカウントへと支払を行ってもよいインターネットウェブサイトであってもよい。
【0034】
S240において、プロセッサは、顧客のアカウント中への支払を行うために、請求者によって要求される情報を決定してもよい。この情報は、何らかの方法において決定され、収集されてもよい。本発明のいくつかの実施形態にしたがうと、この情報は、ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出のプログラムもしくはモジュールの使用を通して収集されてもよい。ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出は、一般的には、コンピュータソフトウェアを使用して、特定のウェブサイトから情報を自動的に収集および抽出するプロセスである。通常は、このようなソフトウェアプログラムは、ウェブサイト探査をシミュレートする。ウェブスクラッピングモジュールは、一般的に、構造化されていないウェブコンテンツを収集し、それを、記憶および解析可能な、構造化されたデータへと変換する。本発明のいくつかの実施形態にしたがうと、この情報は、請求者の支払プラットフォームによって直接、アプリケーションプログラミングインターフェース(API)を介して、収集されてもよい。
【0035】
S250において、プロセッサは、請求者の支払プラットフォームへと、要求される情報を提供してもよい。いくつかの実施形態では、このことは、(“名前”フィールドへと顧客の名前を挿入することや、または、“アカウント番号”フィールドへと顧客のアカウント番号を挿入することのような)ウェブページ上の要求されるフィールドへと、適切な情報を挿入することを含んでもよい。いくつかの実施形態では、支払プラットフォームは、最初に、複数の情報を要求してもよいが、将来の取引に対しては、顧客からのログインおよびパスワードのみを要求してもよい。このような状況では、プロセッサがログインおよびパスワードを確立するか、プロセッサが、S210において、顧客から既存のログインおよびパスワードを受信するかのいずれかである。いくつかの実施形態では、支払プロセッサによって要求される情報は、要求される方法において整えられてもよく、例えば、APIを介して、支払プラットフォームに直接送信されてもよい。
【0036】
S260において、プロセッサは、支払プラットフォームへと、値または値のしるしを提供してもよい。例えば、顧客がプロセッサに、銀行アカウント情報を提供した場合、プロセッサは、顧客の銀行アカウントから、支払プラットフォームに対する送金を促進してもよい。顧客が、支払プラットフォームによって受け入れられないフォーマットにおいて、例えば、閉ループギフトカードの形式で、プロセッサに対して値を提供した場合、プロセッサは、この受け取った値を、支払プラットフォームが受け入れる値へと交換してもよい。例えば、いくつかの実施形態では、プロセッサは、1つのフォーマットにおいて、値を受信してもよいが、支払プラットフォームに対して、生成された開ループ仮想プリペイドカード番号の形式で、支払を提供してもよい。制限的でない例として、顧客は、ウォールマートギフトカードを介して、プロセッサに支払を提供してもよく、次に、プロセッサは、仮想プリペイドVisaデビットカードを生成して、請求者に対する支払の正確な額で、仮想プリペイドVisaデビットカードを資金付けして、仮想プリペイドVisaデビットカードアカウント番号を請求者に提供してもよい。
【0037】
副次的な留意点として、開ループ仮想プリペイドデビットカード番号の生成および支給は、追加の、または、付随的な利点を有していてもよい。例えば、Visaブランド付けされた記憶値カードのケースでは、このような記憶値カードが償還されるとき、記憶値カードを発行した当事者は、交換手数料を受ける資格を与えられてもよい。交換手数料は、受取人がVisaまたはMasterCardのようなカードネットワークを使用して、支払を受け入れた時に、受取人の銀行(または、受納している銀行)が、発行した銀行に支払う手数料である。発行した銀行が受納する銀行に支払う額から、発行した銀行は交換手数料を減額することが多い。交換手数料は、変化してもよいが、取引の値の約1.5%−2.0%であることが多い。プロセッサは、発行した銀行であるため、取引の費用は、交換手数料の額だけ減額される。この交換手数料は、支払取引を実行することに対する、プロセッサへの支払として使用されてもよく、交換手数料を減額することにより、様々な請求者との関係を向上させるために、または、オフセットされた支払を提供するために、レバレッジされてもよい。
【0038】
S270において、プロセッサは、支払の確認を顧客に送る。この確認は、何らかの通信チャネルを介してのものであってもよく、必ずしもそうではないが、顧客から受信された支払命令と同一のフォーマットにおけるものであってもよい。本発明にしたがったいくつかの実施形態では、確認は、SMS、MMS、電子メール、アプリケーション通知、ソーシャルネットワーキングページ上のメッセージング、電話通話、ページ、ファックス、または、他の任意の通信を介して送られてもよい。
【0039】
図3にしたがうと、本発明のいくつかの実施形態にしたがって、請求者の支払プラットフォームを利用して、顧客勘定の支払を促進する方法30をここで説明することにする。S305において、顧客が、プロセッサに、(i)個人識別情報と、(ii)請求者アカウント情報と、(iii)資金アカウント情報とのような情報を提供する。
【0040】
S310において、プロセッサは、S305において送られた顧客からの情報を受信し、情報が有効であり、資金アカウントが適切に資金付けされている(すなわち、それに関係付けられている値を有する)ことを確認してもよい。
【0041】
S315において、プロセッサは、顧客から受信された情報に基づいて、請求者を識別してもよく、請求者の支払プラットフォーム(例えば、支払が受信され、顧客アカウントに適用されることを可能にする請求者のウェブサイト)にアクセスしてもよい。
【0042】
S320において、例えば、ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出プログラムの使用を通して、請求者に支払を提供するために必要とされる情報を決定してもよい。
【0043】
S325において、プロセッサは、適切なフォーマットで、支払プラットフォームへと必要とされる情報を提供してもよい。例えば、プロセッサは、ブランクフィールドを備えるウェブベースのフォームに記入してもよく、または、支払プラットフォームの周知のAPIに基づいて、送金をアセンブルしてもよい。
【0044】
S330において、プロセッサは、顧客から請求者に支払うべき額を決定してもよい。この決定は、通信を介して、または、ウェブページ上でポストされた支払うべき額を通して、また、プロセッサが再び、ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出プログラムのサービスを利用してのように、支払プラットフォームから受信された情報に基づいていてもよい。
【0045】
S335において、プロセッサは、顧客によって提供された(または、顧客によって識別されるアカウントに関係づけられている)資金付けの額が、請求者に支払うべき額より多いか、または、等しいかを決定してもよい。資金の額が不十分であるという決定があると、取引は終了してもよく、または、プロセッサが不足について顧客に通知して、追加の資金源、または、請求者に対して行うための支払の額における減額のいずれかを要求する。
【0046】
資金付けの額が十分であるという決定があると、プロセッサは、請求者に対して支払うべき額(または、顧客によって指示された、他の何らかの額)を資金アカウントから減算してもよい。S345において、プロセッサは、請求者の支払プラットフォームに支払を提供してもよい。S350において、プロセッサは、支払が行われたことを顧客に確認してもよく、最終の支払額について顧客に通知してもよい。
【0047】
S345においてプロセッサによって支払プラットフォームへと提供された値の形式は、S305において顧客から受信された値と、同一の形式でなくてもよい。図4を参照して、本発明のいくつかの実施形態にしたがって、請求者の支払プラットフォームを利用して、顧客の勘定の支払を促進する方法の一部として、請求者40によって受け入れられる資金付けオプションを決定するプロセスを、以下で記述することにする。
【0048】
S410において、プロセッサは、請求者および/または請求者の支払プラットフォームによって受け入れられる、資金付けオプションのタイプを決定してもよい。例えば、いくつかの請求者は、直接のアカウント送金を受け入れてもよい一方で、他の請求者は、VisaまたはMasterCardの形式における支払のみを受け入れてもよい。いくつかの請求者は、閉ループ記憶値のいくつかの形式を受け入れてもよい(例えば、BestBuy系列のクレジットの支払は、BestBuy閉ループギフトカードとともに行われてもよい)一方で、他の請求者は、何の閉ループ記憶値も受け入れないかもしれない。
【0049】
S420において、許容される場合、プロセッサは、支払プラットフォームに対する、顧客のアカウント(例えば、小切手アカウントのようなファイナンシャルアカウント)からの直接の値の送金を促進してもよい。
【0050】
支払プラットフォームが値の直接送金を受け入れない場合、または、顧客によって提供されたフォーマットにおける値を受け入れない場合、プロセッサは、提出された値を交換する必要があるかもしれない。S430において、プロセッサは、顧客指示された、資金源から、適切な値の額を減算してもよい。この額は、支払の額、プラス、適用可能な手数料または税金を含んでいてもよい。
【0051】
適切な手数料または税金は、いくつかの要因に基づいていてもよい。発信元またはセットアップ手数料があってもよく、それぞれのアカウント、それぞれの請求者、および/または、それぞれの支払取引に関係するサービス手数料があってもよい。値の交換が要求されるときに適用される手数料があってもよい。適用可能な税金は、制限的でないが、顧客アカウントに関係するロケーション、支払要求の発信元のロケーション(例えば、(ISPにより決定される)発信しているコンピュータのロケーション、発信しているポイントオブセールデバイスまたはロケーション、開始された支払取引が受信された電話の交換ロケーション等)、プロセッサのロケーション、および、プロバイダのロケーションを含む、複数の要因に基づいていてもよい。
【0052】
S440において、プロセッサは、Visaブランド付けされたプリペイドデビットカードのような、仮想開ループプリペイド記憶値カードまたはデビットカードを生成させてもよい。プロセッサは、支払取引の正確な額で、仮想開ループプリペイド記憶値カードまたはデビットカードを資金付けしてもよい。
【0053】
S450において、プロセッサは、仮想開ループプリペイド記憶値カードまたはデビットカードのアカウント番号(例えば、仮想カード番号)を、支払プラットフォームに提供してもよい。S460において、プロセッサは、支払プラットフォームによる、資金の受け取りの確認を受信してもよい。
【0054】
図5を参照して、本発明のいくつかの実施形態にしたがって、本発明のいくつかの実施形態にしたがって、請求者の支払プラットフォームを利用して、顧客の勘定の支払を促進する方法50を、以下で記述することにする。S510において、顧客がプロセッサに情報を提供する。このような情報は、個人識別情報(例えば、名前、住所等)、請求者アカウント情報(例えば、請求者の名前、顧客のアカウント番号)を含んでもよい。オプション的に、S511において、顧客がプロセッサに、将来の支払に対して使用されることになるファイナンシャルアカウント情報を提供してもよい。例えば、顧客は、S511において、顧客の小切手アカウントを識別して、アクセスするのに十分な情報を提供してもよい。
【0055】
S520において、プロセッサが情報を受け取って、情報が、識別された請求者の支払プラットフォームにアクセスして、支払取引を実行するために、有効および十分であることを確認してもよい。例えば、S521において、請求者の識別に基づいて、プロセッサは、データベースまたは他の記録を参照して、請求者によって何の情報が要求されるかを決定してもよい。代わりに、S522において、プロセッサは、請求者の支払プラットフォームにアクセスして、S523において、支払取引を実行するのに、請求者によって必要とされる情報を決定してもよい。この決定は、ウェブスクラッピング、ウェブハーベスティング、または、ウェブデータ抽出のプログラムもしくはモジュールの使用を介して実行されてもよい。
【0056】
S524において、プロセッサは、顧客から受信された情報を、支払プラットフォームにより支払取引を実行するために要求される情報に、比較してもよい。S525において、受信された情報が十分である場合、プロセスは継続してもよい。受信された情報が不足している場合、S526において、顧客からのさらなる情報が要求されてもよく、プロセスはS520に戻ってもよい。
【0057】
さらなるオプションステップが、プロセスに含まれてもよい。例えば、S527で、プロセッサは、支払プラットフォームにおいて、顧客支払アカウントを作成してもよい。S527は、ログインおよび/またはパスワードの作成(または、割り当て)を含んでいてもよい。顧客支払アカウントは、将来の取引に対して、さまざまな情報を継続的に再入力する必要性を防止してもよい。S528において、プロセッサは、顧客支払アカウントについて顧客に通知してもよく、アクセスのために必要とされるログインおよび/またはパスワードを顧客に提供してもよい。
【0058】
S530において、プロセッサは、勘定を支払うための顧客からの要求を受信してもよい。この要求は、顧客が支払うことを望む、特定の請求者の識別を含んでいてもよい。オプション的ステップS531において、プロセッサは、顧客から請求者に借りのある額および/または支払うべき額を決定してもよい。オプション的ステップS532において、プロセッサは、この額を顧客に知らせる。
【0059】
S540において、プロセッサは、請求者に対して支払うための値の額の表示を顧客から受信してもよい。S511において、顧客がファイナンシャルアカウントに関する情報を提供していない場合、または、顧客が、このようなファイナンシャルアカウントを資金源として使用しないことを選んだ場合、S541において、プロセッサは、顧客から、値、または、値のしるしを受信してもよい。
【0060】
S550において、プロセッサは、顧客から受信された値、または、顧客によって識別された資金源もしくはファイナンシャルアカウントが、S540において、顧客から受信された、表示された支払の額より多い値を有しているか、または、これに等しい値を有しているか否かを決定してもよい。受信された値が十分でない場合、または、資金源もしくはファイナンシャルアカウントが十分な値の額で資金付けされていない場合、S551において、顧客は不足について知らされ、プロセスは、S540に戻ってもよく、ここで、顧客は、請求者に支払うための値の額の新しい表示を提供する。
【0061】
S560において、受信された値が十分である場合、または、資金源もしくはファイナンシャルアカウントが十分な値の額で資金付けされている場合、プロセッサは、支払プラットフォームが顧客によってプロセッサに提供されるフォーマットにおける値を受け入れるか否かを決定してもよい。支払プラットフォームが、顧客によってプロセッサに提供されるフォーマットにおける値を受け入れない場合、プロセッサは、請求者に行われることになる支払の額で資金付けされた(あるいは、支払の額に関係付けられた)、仮想開ループプリペイド記憶値カードまたはデビットカード番号を生成させる。
【0062】
S570において、請求者の支払プラットフォームに、プロセッサからの値が送金される。この値は、顧客によってプロバイダに提供されるフォーマットにおける値であってもよく、あるいは、仮想開ループプリペイド記憶値カードまたはデビットカード番号における値であってもよい。
【0063】
S580において、プロセッサは、顧客に、支払取引が実行されたことの確認を提供してもよい。この確認は、何らかの通信チャネルを介して贈られてもよく、何らかのフォーマットにおけるものであってもよい。
【0064】
図6を参照して、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にするシステム60をここで説明する。一般的に、システム60は、1人以上の顧客610、プロセッサ620、および、請求者の1つ以上の支払プラットフォーム630を備える。1人以上の顧客610は、(これらに制限されるわけではないが、)インターネット、自動音声認識(IVR)システム、メッセージング(例えば、SMSまたはMMS)、電子デバイス上で実行されるアプリケーションもしくはアプレット、キオスク、ポイントオブセールデバイス、端末、または、ロケーションからの通信、等のような、何らかの様々な通信チャネル615を通して、プロセッサ620と通信してもよい。
【0065】
プロセッサ620は、顧客インターフェース621、請求者インターフェース622、処理モジュール623、ウェブデータ抽出モジュール624、値交換モジュール625、データベース626を備えてもよい。顧客インターフェースは、1人以上の顧客610とのインバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの顧客610は、異なる通信チャネル615を利用してもよいので、顧客通信インターフェース621は、異なる顧客の異なる通信チャネルにより、複数のインターフェースを集合的に識別してもよい。
【0066】
顧客インターフェース621は、プロセッサと顧客との間の選択可能な通信を提供してもよく、顧客から、値、顧客の識別情報、プロバイダと顧客の既存のアカウントを識別するのに十分な情報、および、プロバイダに伴う既存の顧客のアカウントに対して行うための支払の額の識別を受け取るように構成されていてもよい。
【0067】
請求者インターフェース622は、1つ以上の請求者および支払プラットフォーム630により、インバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの請求者630が、異なる通信属性を要求するかもしれない(例えば、何人かの請求者は、APIを介した通信および支払取引を受け入れてもよく、他の請求者は、特定のウェブサイトまたはウェブベースの支払フォームを介した通信および支払取引を要求してもよい)ので、請求者インターフェース622は、複数の請求者による複数のインターフェースを集合的に識別してもよい。
【0068】
請求者インターフェースは、プロセッサとプロバイダとの間の選択的な通信を提供してもよく、プロバイダの支払プラットフォームまたはウェブサイトにアクセスするように構成されていてもよく、プロバイダの支払プラットフォームまたはウェブサイトへと情報を提供してもよい。
【0069】
処理モジュール623は、顧客インターフェース621、請求者インターフェース622、ウェブデータ抽出モジュール624、値交換モジュール625、データベース626を含む、プロセッサ620のそれぞれのコンポーネントと通信してもよい。処理モジュールは、すべての要求される決定および計算を実行するように構成されていてもよい。例えば、処理モジュール623は、顧客から受信された識別情報を、支払プラットフォームまたはウェブサイトへと、少なくとも入力するように、また、支払プラットフォームまたはウェブサイトへと値を提供するように構成されていてもよい。
【0070】
ウェブデータ抽出モジュール624は、支払を行うために請求者によって要求された情報を決定するように構成されていてもよい。これは、支払プラットフォームのウェブページをスクラッピングすることと、何の情報が要求されているか、また、このような情報を適切に挿入するための場所を決定することとにより、実行されてもよい。
【0071】
値交換モジュール625は、顧客によって提供された通りの第1のフォーマットで、値を受け入れて、(何らかの適用可能な手数料または税金をマイナスし、)請求者または支払プラットフォームによって受け入れられる、第2のフォーマットの値へと、それを交換するための手段を提供してもよい。例えば、値交換モジュール625は、閉ループ記憶値を受け入れて、これを、仮想開ループ記憶値またはデビットカードへと交換してもよい。
【0072】
データベース626は、処理モジュール623に結合されていてもよく、顧客から受信された情報を記憶してもよく、また、請求者に伴う、既存の顧客アカウントに関する情報も記憶してもよい。例えば、特定のログインおよびパスワード情報を備える顧客支払アカウントが確立される、または、利用される場合、データベースは、特定の請求者および特定の顧客に関係する記録中に、要求されるログインおよびパスワード情報を記憶してもよい。データベースはまた、記録保持の目的のために、または、繰り返し発生する、もしくは、定期的な支払のために利用されてもよい、過去の取引情報を記憶してもよい。
【0073】
図7を参照して、本発明のいくつかの実施形態にしたがった、請求者の支払プラットフォームを利用した、顧客の勘定の支払を容易にするシステム70をここで説明する。一般的に、システム70は、1人以上の顧客710、プロセッサ720、1つ以上の請求者730、および、1つ以上の金融機関740を備えていてもよい。1人以上の顧客710は、(これらに制限されるわけではないが、)インターネット、自動音声認識(IVR)システム、メッセージング(例えば、SMSまたはMMS)、電子デバイス上で実行されるアプリケーションもしくはアプレット、キオスク、ポイントオブセールデバイス、端末、または、ロケーションからの通信、等のような、何らかのさまざまな通信チャネル715を通して、プロセッサ720と通信してもよい。
【0074】
1つ以上の請求者730は、1人以上の顧客710に対して商品もしくはサービスを販売するプロバイダを含んでいてもよく、あるいは、プロバイダのために、または、プロバイダの代理で請求機能を実行する商品もしくはサービスのプロバイダとは別個のエンティティを含んでいてもよい。1つ以上の金融機関740は、1人以上の顧客710が、1つ以上の請求者730に対して、支払を行うために使用されてもよいファイナンシャルアカウントをそこに有する金融機関を含んでもよい。
【0075】
プロセッサ720は、顧客インターフェース721、請求者インターフェース722、資金源インターフェース723、処理モジュール724、ウェブデータ抽出モジュール725、ウェブアプリケーションモジュール726、値交換モジュール727、仮想プリペイドデビットカード生成機728、および、データベース729を備えてもよい。
【0076】
顧客インターフェース721は、1人以上の顧客710とのインバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの顧客710は、異なる通信チャネル715を利用してもよいので、顧客通信インターフェース721は、異なる顧客の異なる通信チャネルにより、複数のインターフェースを集合的に識別してもよい。
【0077】
顧客インターフェース721は、プロセッサと顧客との間の選択可能な通信を提供してもよく、顧客から、値、顧客の識別情報、プロバイダと顧客の既存のアカウントを識別するのに十分な情報、および、プロバイダとともに既存の顧客のアカウントに対して行うための支払の額の識別を受け取るように構成されていてもよい。
【0078】
請求者インターフェース722は、1つ以上の請求者および支払プラットフォーム730により、インバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの請求者730が、異なる通信属性を要求するかもしれない(例えば、何人かの請求者は、APIを介した通信および支払取引を受け入れてもよく、他の請求者は、特定のウェブサイトまたはウェブベースの支払フォームを介した通信および支払取引を要求してもよい)ので、請求者インターフェース722は、複数の請求者による複数のインターフェースを集合的に識別してもよい。
【0079】
請求者インターフェース722は、プロセッサ720とプロバイダまたは請求者730との間の選択的な通信を提供してもよく、プロバイダまたは請求者の支払プラットフォームもしくはウェブサイトにアクセスするように構成されていてもよく、プロバイダまたは請求者の支払プラットフォームもしくはウェブサイトへと情報を提供してもよい。
【0080】
資金源インターフェース723は、1つ以上の資金源とのインバウンドの、および、アウトバウンドのすべての通信を取り扱ってもよい。それぞれの請求者730が、異なる通信属性を要求するかもしれない(例えば、何人かの請求者は、APIを介した通信および支払取引を受け入れてもよく、他の請求者は、特定のウェブサイトもしくはウェブベースの支払フォームを介した通信および支払取引を要求してもよい)ので、資金源インターフェース723は、複数の請求者による複数のインターフェースを集合的に識別してもよい。
【0081】
処理モジュール724は、プロセッサ720の、他のすべてのコンポーネントと通信してもよい。処理モジュール724は、図1−5において、また、それらに付随する説明において述べたように、支払取引を実行するのに必要な、すべての決定を実行してもよい。
【0082】
ウェブデータ抽出モジュール725は、支払を行うために請求者によって要求された情報を決定するように構成されていてもよい。これは、支払プラットフォームのウェブページをスクラッピングすることと、何の情報が要求されているか、また、このような情報を適切に挿入するための場所を決定することとにより、実行されてもよい。
【0083】
ウェブアプリケーションモジュール726は、請求者の支払プラットフォームウェブサイトと対話してもよく、さまざまな請求者の支払プラットフォームシステム中、または、さまざまな請求者の支払プラットフォームシステム上で、適切なフィールド、ボックス、もしくは、エントリエリアへと、適切な情報を挿入するために利用されてもよい。
【0084】
値交換モジュール727は、顧客によって提供された通りの第1のフォーマットで、値を受け入れて、(何らかの適用可能な手数料または税金をマイナスし、)請求者または支払プラットフォームによって受け入れられる第2のフォーマットの値へと、それを交換するための手段を提供してもよい。顧客から受け取られた値が、仮想開ループ記憶値またはデビットカードへと交換されることになるとき、値交換モジュール727は、仮想プリペイドデビットカード生成機728と対話してもよい。仮想プリペイドデビットカード生成機728は、請求者に対して行われることになる支払に等しい額において資金付けされた、請求者によって受け入れられてもよい仮想デビットカード(例えば、VisaまたはMasterCardブランド付けされたプリペイドデビットカード)を生成してもよい。
【0085】
データベース729は、処理モジュール724に結合されていてもよく、顧客から受信された情報を記憶してもよく、また、請求者に伴う、既存の顧客アカウントに関する情報も記憶してもよい。例えば、特定のログインおよびパスワード情報を備える顧客支払アカウントが確立される、または、利用される場合、データベースは、特定の請求者および特定の顧客に関係する記録中に、要求されるログインおよびパスワード情報を記憶してもよい。データベースはまた、記録保持の目的のために、または、繰り返し発生する、もしくは、定期的な支払のために利用されてもよい、過去の取引情報を記憶してもよい。
【0086】
ここで示し、記述した、本発明の特定の実施形態は、単に例示的なものであることが理解されるだろう。数々の変形、変更、置換、および、同等物が、本発明の精神と範囲を逸脱することなく、当業者にとって、ここで、あり得るものとなるだろう。例として、プロセッサは、金融機関、資金源、マーチャント、または、請求者によって維持もしくは管理されてもよい。したがって、ここで記述し、添付の図面において示したすべての主題は、単に例示的なものであり、制限的な意味におけるものでないとしてみなされることが意図されており、本発明の範囲は、添付の特許請求の範囲のみによって、決定されるだろうことが意図されている。
以下に、本願出願時の特許請求の範囲に記載された発明を付記する。
[1]商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供する方法において、前記方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進され、
前記方法は、
値と;前記顧客の識別情報と;前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報とを顧客から受け取ることと、
前記プロバイダの支払プラットフォームにアクセスすることと、
前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を決定することと、
前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を通信することと、
前記顧客のアカウントへと値を提供することと
を含む方法。
[2]前記値と;前記顧客の識別情報と;前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報とは、インターネット、自動音声認識(IVR)システム、ショートメッセージサービス(SMS)を介して送られるメッセージ、メディアメッセージサービス(MMS)を介して送られるメッセージ、移動体デバイス上で実行されるアプリケーション、キオスク、ポイントオブセールデバイス、および、マーチャントロケーションからなるグループのうちから選択される方法を介して受け取られる、前記[1]記載の方法。
[3]前記顧客から受け取られた値は、記憶値アカウントへのアクセスを含む、前記[1]記載の方法。
[4]前記記憶値アカウントは、閉ループ記憶値アカウントである、前記[3]記載の方法。
[5]前記顧客から受信された値は、前記顧客によってポイントオブセールデバイスに対して行われた支払を含み、前記プロセッサは、後の時間において、前記ポイントオブセールデバイスとともに精算する、前記[1]記載の方法。
[6]前記顧客の識別情報は、前記顧客のアカウントへと支払を行うために、前記プロバイダによって要求される情報を含む、前記[1]記載の方法。
[7]前記識別情報は、ログイン情報およびパスワードを含む、前記[6]記載の方法。
[8]前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報は、アカウント番号を含む、前記[1]記載の方法。
[9]前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報は、前記プロバイダに伴う前記顧客のアカウントに関係するしるしを含む、前記[1]記載の方法。
[10]前記しるしは電話番号を含む、前記[9]記載の方法。
[11]前記プロバイダの支払プラットフォームにアクセスするステップは、インターネットを介して達成される、前記[1]記載の方法。
[12]前記プロバイダの支払プラットフォームにアクセスするステップは、前記プロバイダにより管理されている、または、前記プロバイダに関係する、支払ウェブページにアクセスすることを含む、前記[1]記載の方法。
[13]前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を決定するステップは、前記プロセッサによって実行される、ウェブスクラッピング、または、ウェブデータ抽出プログラムによって達成される、前記[1]記載の方法。
[14]前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を決定するステップは、前記顧客のアカウントへと支払を行うために、前記プロバイダによって必要とされる特定の情報を決定することを含む、前記[1]記載の方法。
[15]前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を通信するステップは、前記顧客から受信された識別情報を、前記プロバイダの支払プラットフォームへと挿入することを含む、前記[1]記載の方法。
[16]前記顧客のアカウントへと支払を提供するために、前記プロバイダによって要求される情報を通信するステップは、
前記プロバイダの支払プラットフォームにより要求される情報のそれぞれの断片を識別することと、
前記顧客から受信された識別情報から、適切な情報を決定することと、
前記プロバイダの支払プラットフォームにより要求される情報のそれぞれの断片に応答して、前記適切な情報を提供することと
を含む、前記[1]記載の方法。
[17]前記プロバイダによって要求される情報を通信するステップは、オンラインフォームへと自動入力することを含む、前記[16]記載の方法。
[18]前記顧客のアカウントへと値を提供するステップは、前記顧客から受け取られた値を、前記プロバイダに伴う前記顧客のアカウントへと送信することを含む、前記[1]記載の方法。
[19]前記顧客のアカウントへと提供される値は、適用可能な手数料および税金が減額された、前記顧客から受け取られた値の残金である、前記[18]記載の方法。
[20]前記値は、ポイントオブセールデバイスにおいて、前記顧客から受け取られ、前記適用可能な手数料および税金は、前記顧客のアカウントに関係するロケーション、前記ポイントオブセールデバイスのロケーション、前記プロセッサのロケーション、および、前記プロバイダのロケーションからなるグループから選択される1つ以上の要因に基づいて計算される、前記[19]記載の方法。
[21]前記顧客のアカウントへと値を提供するステップは、仮想プリペイドデビットカード番号を生成することと、前記仮想プリペイドデビットカード番号を前記プロバイダの支払プラットフォームに提供することとを含む、前記[1]記載の方法。
[22]前記仮想プリペイドデビットカード番号は、前記プロバイダに対して行われる支払に等しい額で資金付けされる、前記[21]記載の方法。
[23]商品またはサービスのプロバイダに伴う既存の顧客のアカウントへと支払を提供する方法において、前記方法は、顧客、商品またはサービスのプロバイダ、および、プロセッサの間で促進され、
前記方法は、
値と;前記顧客の名前および住所を含む前記顧客の識別情報と;前記既存の顧客のアカウントのアカウント番号を含む、前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報と;前記プロバイダに伴う前記既存の顧客のアカウントに支払を行う額の識別とを顧客から受け取ることと、
前記プロセッサによって、インターネットを介して、前記プロバイダの支払ウェブサイトにアクセスすることと、
支払を行うのに前記プロバイダによって要求される情報を決定するために、前記支払ウェブサイトをスクラッピングすることと、
前記プロバイダが、前記顧客の代わりに動作して、前記顧客から受け取った識別情報を、前記支払ウェブサイトへと入力することと、
前記顧客から受け取った値の形式において、前記プロバイダが支払を受け入れるか否かを決定することと、
前記顧客から受け取った値の形式で、前記プロバイダが支払を受け入れるという決定があると、顧客から受け取った値を、前記プロバイダに搬送することと、
前記顧客から受け取った値の形式で、前記プロバイダが支払を受け入れないという決定があると、仮想プリペイドデビットカード番号を生成して、前記仮想プリペイドデビットカード番号を、プロバイダに搬送することと、
前記顧客に対して支払の確認を提供することと
を含む方法。
[24]前記値と;前記顧客の識別情報と;前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報とは、インターネット、自動音声認識(IVR)システム、ショートメッセージサービス(SMS)を介して送られるメッセージ、メディアメッセージサービス(MMS)を介して送られるメッセージ、移動体デバイス上で実行されるアプリケーション、キオスク、ポイントオブセールデバイス、および、マーチャントロケーションからなるグループのうちから選択される方法を介して受け取られる、前記[23]記載の方法。
[25]前記顧客から受け取られた値は、前記顧客によってポイントオブセールデバイスに対して行われた支払を含み、前記プロセッサは、後の時間において、前記ポイントオブセールデバイスとともに精算する、前記[23]記載の方法。
[26]前記顧客から受け取られた値は、記憶値アカウントへのアクセスを含む、前記[23]記載の方法。
[27]前記記憶値アカウントは、閉ループ記憶値アカウントである、前記[26]記載の方法。
[28]前記顧客から受け取られた値は、マーチャントのみにより償還可能である閉ループ記憶値カードを使用して、前記マーチャントにおいて、前記顧客により行われた支払を含む、前記[27]記載の方法。
[29]商品またはサービスのプロバイダに伴う顧客の既存の顧客のアカウントへと支払を提供するプロセッサにおいて、前記プロセッサは、前記顧客、および、前記プロバイダとともに選択的に通信し、
前記プロセッサは、
前記プロセッサと前記顧客との間の選択的な通信を提供する顧客インターフェースと、
前記プロセッサと前記プロバイダとの間の選択的な通信を提供するプロバイダインターフェースと、
前記プロバイダインターフェースと通信する、ウェブデータ抽出モジュールと、
前記顧客インターフェース、前記プロバイダインターフェース、前記ウェブデータ抽出モジュールと通信する処理モジュールと
を具備し、
前記顧客インターフェースは、
値と;前記顧客の名前および住所を含む前記顧客の識別情報と;前記既存の顧客のアカウントのアカウント番号を含む、前記プロバイダと前記顧客の既存のアカウントとを識別するのに十分な情報と;前記プロバイダに伴う前記既存の顧客のアカウントに支払を行う額の識別とを顧客から受け取るように構成されており、
前記プロバイダインターフェースは、
前記プロバイダの支払プラットフォームまたはウェブサイトにアクセスし、
前記プロバイダの支払プラットフォームまたはウェブサイトに情報を提供するように構成されており、
前記ウェブデータ抽出モジュールは、支払を行うために、前記プロバイダによって要求される情報を決定するように構成されており、
前記処理モジュールは、
前記顧客から受け取った識別情報を、支払プラットフォームまたはウェブサイトへと入力し、
前記支払プラットフォームまたはウェブサイトへと値を提供するように構成されている装置。
[30]前記処理モジュールは、
前記顧客から受け取った値の形式において、前記プロバイダが支払を受け入れるか否かを決定するようにと、
前記顧客から受け取った値の形式で、前記プロバイダが支払を受け入れるという決定があると、顧客から受け取った値を、プロバイダに搬送するようにと、
前記顧客から受け取った値の形式で、前記プロバイダが支払を受け入れないという決定があると、仮想プリペイドデビットカード番号を生成して、前記仮想プリペイドデビットカード番号を、前記プロバイダに搬送するように
さらに構成されている、前記[29]記載のシステム。
[31]前記顧客からの値を受け入れて、適用可能な手数料または税金を減額し、残りの値を、前記プロバイダの支払プラットフォームまたはウェブサイトにより受け入れ可能な種類のものへと交換するように構成されている、値交換モジュールをさらに具備する、前記[29]記載のシステム。
[32]前記既存の顧客のアカウントへと行われることになる支払の額で資金付けされた関係するアカウントを伴う、プリペイドデビットカード番号を生成させるように構成されている仮想プリペイドデビットカード生成機をさらに具備する、前記[29]記載のシステム。
[33]前記プロセッサと、前記顧客のファイナンシャルアカウントとの間の選択的な通信を提供する、ファイナンシャルアカウントインターフェースをさらに具備し、前記ファイナンシャルアカウントインターフェースは、前記プロセッサに値を送金するように構成されている、前記[29]記載のシステム。
[34]前記顧客インターフェースは、
インターネット、自動音声認識(IVR)システム、ショートメッセージサービス(SMS)を介して送られるメッセージ、メディアメッセージサービス(MMS)を介して送られるメッセージ、移動体デバイス上で実行されるアプリケーション、キオスク、ポイントオブセールデバイス、および、マーチャントロケーションからなるグループのうちから選択される方法を介して、前記顧客との通信を提供する、前記[29]記載のシステム。
[35]前記顧客インターフェースは、前記既存の顧客のアカウントに対する支払が、うまく行われた後に、支払の確認を前記顧客に提供するようにさらに構成されている、前記[29]記載のシステム。
図1
図2
図3
図4
図5
図6
図7