JP5824064B2 - 金融機関を通したリアルタイム支払い - Google Patents

Description

関連出願の相互参照
本特許出願は、出願日２０１０年１１月３０日、米国仮特許出願第６１／４１８，３１３号に対する優先権を主張する。両出願その全体を参照により本明細書に組み込む。

発明の属する技術分野
本発明は、一般には電子金融取引に関し、詳細には、２つの金融法人を含む金融取引に関する。

一般に、消費者は、自身の銀行口座から振り出した小切手を切るなどすることにより、銀行を通して他者への支払いを行う。しかし、紙の小切手は、詐欺行為のリスク、使用するのにコストがかさむこと（印刷、郵送）、小切手記入の際に誤りを起こしやすいこと、面倒であること（小切手を入手することや受取人の郵送宛先住所が必要）、時間がかかること（小切手の記入および郵送）を含めて、多くの不利な点を有する。米国、カリフォルニア州、サンノゼのＰａｙＰａｌ社等の支払いプロバイダは、ユーザがスマートフォンやＰＣ等のユーザ・デバイスを通して電子的に支払いを行うことを可能にしている。銀行も、デビットカードによる支払いを可能にしている。しかし、こうした支払いは、カード・リーダを伴うＰＯＳのみでしか行うことができない。

より最近では、銀行は、消費者が代金支払いサービスを介して電子的に支払いを行うことを可能にしている。これは一般に、消費者が支払先毎に登録を行うことを必要とするので、時間を消費することがある。登録を行うと、消費者は、指定された支払先に支払いを行うことができる。しかし、支払先の口座が消費者の銀行とは異なるネットワークにあるかのように、支払い送信および支払いの受取りが遅れることがある。

第三者支払いプロバイダは、この支払いプロバイダが保持する口座を通してユーザが他者に直接的に支払いを行うことを可能にする。しかし、こうしたサービスを利用するためには、支払人と受取人との両方が、支払いプロバイダに口座を持たなければならない。したがって、口座を持つ支払人から口座を持たない支払人に支払いを行うことも、口座を持たない支払人から口座を持つ受取人に支払いを行うこともできない。

したがって、先で議論した従来式方法の不利な点を解消する個人対個人の支払いサービスが必要である。

本発明の一実施形態では、ＰａｙＰａｌ等のサービスまたは支払いプロバイダは銀行レール（bank rail）を使用して、銀行顧客が電子メール・アドレスや携帯電話番号等の受取人の識別要素または他の容易に共用可能な識別要素を入力するだけで、銀行サイトを通してリアルタイムの支払い送信を行うことを可能にする。銀行は、その支払いプロバイダに口座を持っている。したがって、顧客が銀行を通じて支払い送信を行うと、支払いプロバイダが、銀行が持つ支払いプロバイダ口座を通して支払いを受取人に送る。銀行は、ユーザの銀行口座からその金額を引き落とす。送り主は、銀行の口座のみ持っていればよく、支払いプロバイダに口座を持たなくてもよい。支払いプロバイダに口座を持つユーザは、銀行口座は持つが、支払いプロバイダに口座を持たないユーザに支払いを行うこともできる。この状況で、支払先は、資金が待機していることの通知を受けることがあり、口座を開設してそのお金を回収することができる。したがって、個人対個人（Ｐ２Ｐ）の支払いを行うために、支払人と支払先との両方が、支払いプロバイダに口座を持つ必要はない。

他の実施形態では、支払いプロバイダは、ユーザの銀行情報を利用して、購入を行うこと、銀行を資金ソースとして追加すること、ユーザの確認または認証を行うことができる。例えば、支払いプロバイダは、銀行との双方向のレールを利用することにより、無作為な保証金または他の手段ではなく銀行を通じてユーザを認証または確認することができる。また、銀行レールを使用することにより、ユーザが支払いプロバイダの口座を通して支払いを行うことを希望しているが、その口座には支払い金額をカバーするのに十分な資金がない場合に、支払いプロバイダが、ユーザの銀行口座の内容を確認することもできる。十分な資金が入手可能である場合、その資金にホールドをかけることもできる。次いで、支払いプロバイダは、支払いを承認することができ、銀行が持つ支払いプロバイダ口座を通して、資金がユーザの銀行口座から引き出され、ユーザが持つ支払いプロバイダ口座に入金される。

他の用途には、保険会社が自動車整備工場等の支払先の電子メール・アドレスまたは電話番号を支払いプロバイダに与えることにより、支払いプロバイダを通してその支払先にリアルタイムの支払いを行うことが可能であることが含まれる。他の用途は、支払いプロバイダを通して、投資信託、株、債券等の売買をするのが可能なことである。配当金の分配を、支払いプロバイダを通して行うこともできる。この結果、分配がより容易かつ即時に行われる。また、このことにより、証券口座に即時に資金を入れることが可能になり、この結果、ユーザが株／債券をすぐに購入することが可能になる。他の使用ケースでは、リアルタイムの資金調達および弁済のために、支払いプロバイダを通して銀行口座に資金供給をし、支払いプロバイダを通して銀行口座に弁済を行う。銀行を通してリアルタイムでお金の移動が所望される場合、他の使用ケースも考えられる。

金融機関は銀行である必要はない。ユーザがお金を得ることまたは預けることを希望している応用例の場合、いかなる店舗または施設を使用してもよい。その店舗が支払いプロバイダに口座を持っている場合、店舗は、ユーザにお金を供給し、店舗が持つ支払いプロバイダ口座に貸方記入を行うことができる。あるいは、店舗は、ユーザからお金を受け取り、ユーザが持つ支払いプロバイダ口座に貸方記入を行い、店舗が持つ支払いプロバイダ口座に適当な金額の借方記入を行うことができる。

他の実施形態では、ユーザが、ユーザの支払いプロバイダ口座を通してユーザの銀行口座を管理することができる。ここでは、銀行のレールを利用して、ユーザの銀行口座をユーザの支払いプロバイダ口座にリンクさせ、これにより、ユーザが、ユーザの支払いプロバイダのアプリケーションまたはサイトを通して様々な銀行取引を、銀行サイトに行かずに行うことが可能になる。

上記は多くの利点をもたらす。金融機関は、様々なバンキング・チャネル（例、ウェブ、携帯電話、ＡＴＭ）を通して顧客がリアルタイムでの支払いを行うことを可能にすることができる。消費者は、これら様々なバンキング・チャネルを通して彼らのバンキング・アプリケーションまたはサイトにログインし、電子メール・アドレスまたは携帯電話番号のみを使用することにより、リアルタイムで誰へでも、どこへでも支払いを送ることができる。銀行顧客は、送金を行うのに（ＰａｙＰａｌ等の）支払いプロバイダの口座を必要としない。受取人が支払いプロバイダの登録された口座所有者である場合、彼らの支払いプロバイダ口座に即座に入金が行われることとなる。受取人が支払いプロバイダに口座を持たない場合は、受取人は、すぐさま簡単に口座を開いて、彼らの資金に迅速にアクセスすることができる。

したがって、銀行顧客は、支払いの即時性から恩恵を受けることができるようになる。自身の取引の電子記録を有することにより、消費者は、銀行での自身の全ての支払い活動をまとめ、より多くの支払先とやり取りすることができ、このことは、銀行にとって、重要な維持および契約ツールとなる可能性がある。１つの統合で、銀行が、多くの様々な銀行チャネルを通して、途切れなくこうした恩恵を顧客にもたらすことが可能になることもある。

電子メール・アドレスまたは携帯電話番号を通してリアルタイムの支払いを行うことができることで、銀行の顧客契約を大幅に増やすことが可能である。銀行は、より多様なユーザ取引を可能にし、多くの顧客の支払いのニーズを満たすことができ、このことにより、銀行アプリケーションが、顧客にとってより適切でトップオブマインドなものになる。

顧客は、従来式の現金および小切手支払いに対し、より都合の良い解決策を持つことにより恩恵を受ける。銀行顧客は、現在、まとまったやり方で支払先を追尾することができる。例えば、クレジットカード、公共料金に加えて、ベビーシッターの支払い、賃貸料支払い、国際支払い等を全て銀行のウェブサイト上で追尾することができる。

金融機関は、増大するオンラインおよびモバイル支払い活動、より収益可能なクロス・セリングの機会、預金の増大から恩恵を得る。金融機関は、支払いが送られる毎に、電子メールの性能をバイラル・マーケティングの機会に活用することもでき、これにより、支払い受取人が「You’ve got funds」電子メール（「資金受取り」電子メール）を受け取るときに、銀行が、サービスを受取人に販売することが可能になる。

電子メール支払いのバイラルな性質により、銀行が、複数のチャネルに渡って、収益の多い顧客区分に到達することが可能になる。銀行は、顧客のより多くの行動に関するデータおよび取引に関するデータを集めることで恩恵を受けることも可能であり、さらに一層多くの顧客との契約を促進する洞察に満ちた個人管理アプリケーションを開発することができる。

銀行は、アプリケーション層およびユーザ体験を完全に制御することもできる。支払いプロバイダの能力は、容易に銀行の既存のウェブサイトに統合することができる。この統合は、単純なＡＰＩベースの統合とすることができるが、これは、複数の銀行チャネル（ウェブ、モバイル、ＡＴＭ）に渡って活用することが可能である。

本開示内容のこれらおよび他の特徴および利点が、以下の実施形態の詳細な説明から、より容易に明らかになるであろう。

バンキング・サイトまたは他の金融機関サイトを通して金融取引を行う際に、ユーザが実行するプロセスの一実施形態を示すフローチャートである。 ユーザにより銀行サイトまたは金融機関サイトを通して開始された金融取引を行うのに際し、銀行または金融機関が実行するプロセスの一実施形態を示すフローチャートである。 ユーザにより銀行サイトまたは金融機関サイトを通して開始された金融取引を行うのに際し、サービス・プロバイダまたは支払いプロバイダが実行するプロセス３００の一実施形態を示すフローチャートである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 本明細書に記載する支払いプロセスの一段階の例示的画面ショットである。 ユーザの金融機関サイトまたはアプリケーションから支払いが送られてきた後に、支払先が見る一例示的画面ショットである。 ユーザの金融機関サイトまたはアプリケーションから支払いが送られてきた後に、支払先が見る画面ショットの例である。 ユーザの金融機関サイトまたはアプリケーションから支払いが送られてきた後に、支払先が見る画面ショットの例である。 ユーザの金融機関を通して支払いを行うためにユーザまたは送り主が見る画像ショットの例である。 ユーザの金融機関を通して支払いを行うためにユーザまたは送り主が見る画像ショットの例である。 ユーザの金融機関を通して支払いを行うためにユーザまたは送り主が見る画像ショットの例である。 本明細書に記載の支払いプロセスで使用されるネットワーク化されたシステムの一実施形態の図である。 本明細書に記載の１つまたは複数のデバイスとして使用可能なデバイスの一実施形態の図である。 本明細書に記載の１つまたは複数のデバイスを実装するのに適したコンピュータ・システムの一実施形態の図である。

本開示内容の実施形態およびそれらの利点は、以下の詳細な説明を参照することにより、最適に理解される。１つまたは複数の図面中に示した同様の要素を識別するために、同様の参照番号を使用していることを理解されたい。図面は、本開示内容の実施形態を例示することが目的であり、実施形態を限定することが目的ではない。

図１は、バンキング・サイトまたは他の金融機関サイトを通して金融取引を行う際に、ユーザが実行するプロセス１００の一実施形態を示すフローチャートである。ステップ１０２で、ユーザは、スマートフォン等のユーザのモバイル・デバイスを通してユーザのバンキング・サイトにログインする。ユーザは、タブレット、ＰＣ、ラップトップ等の他のユーザ・デバイスを通してバンキング・サイトにログインすることもできる。ユーザは、ブラウザまたはモバイル・アプリケーション／モバイル・ブラウザを通すなどしてサイトにアクセスし、要求される情報を入力するが、この情報には、ログイン用のユーザ識別要素（ユーザ名または電子メール・アドレス）およびパスワードまたはＰＩＮが含まれることがある。

銀行サイトにログインすると、ユーザは、自身の銀行口座を通して支払いを行うことを可能にするリンク、タブまたはボタン等を伴うホーム画面を見ることができる。こうした機能を選択すると、ユーザは、支払いについての情報を入力／選択するための画面を見る。以下のステップは説明を行う順序で実行される必要はなく、異なる順序で実行することもでき、全てのステップが必要であるわけではないことに留意されたい。また、２つ以上のステップを別々に実行せずに、これらを組み合わせることもできる。

ステップ１０６で、ユーザは、支払いを１回にするか繰返し式（recurrence）にするかを選択する。ユーザは、バンキング・サイトから、ユーザ・デバイスのディスプレイ上の１回払いまたは繰返し払いのボタンまたはリンクを選択することができる。支払いが繰返し式の場合とは、請求書に対する支払いなどである。繰返し払いは、ローン返済、子供、家族もしくは友人への支援、または慈善的寄付のための定期支払いのためであることもある。

繰返し払いの場合、ユーザは、ステップ１０６で繰返しを設定することができる。例えば、ユーザは、毎月の特定の日の支払い、２ヶ月ごと、または、他の周期、というように繰返しを設定することができる。ユーザは、支払いの繰返しの終了日を設定することもできる。この設定は、カレンダー機能を通して、または、可能であれば、キーパッド、キーボード、マイク等、ユーザ・デバイスのデータ入力を通して、ユーザが繰返し期間および終了日を入力するだけで行うことができる。支払いが直近でなければ、ユーザは支払日を設定することもできる。

ステップ１０８で、ユーザは、支払先または支払いの受取人を選択する。これは、いくつかの方法で行うことができる。例えば、ユーザは、電子メール・アドレスや携帯電話番号等の支払先の識別要素を入力してもよい。ユーザは、識別要素をタイプすること、または、ユーザ・デバイスに吹き込むことができる。あるいは、ユーザは、ユーザ・デバイス上のユーザの連絡先リストやユーザが利用可能な他のリスト等から支払先を選択することもできる。リストから所望の支払先を選択すると、電子メール・アドレスや携帯電話番号等のユーザ識別要素で支払先フィールドを埋めることができる。銀行および／または支払いプロバイダに対して、支払先を識別するために他の識別要素も使用可能であることを留意されたい。

ステップ１１０で、ユーザは、支払いに対する資金ソースを選択することもできる。ユーザがデフォルトの資金ソースを設定している場合、または、利用可能な資金ソースが１つしかない場合には、これはスキップしてもよい。資金ソースの例には、当座預金口座、普通預金口座、マネー・マーケット口座、クレジットカード等のユーザの様々な銀行口座がある。これらの種類の口座はそれぞれ、複数の利用可能なオプションを持つことがある。例えば、ユーザは、個人用当座預金口座、共同当座預金口座、および業務用当座預金口座を持つことができる。ユーザは、利用可能な資金ソースのリストを銀行により提示されることがあり、これにより、ユーザは、特定の資金ソースを表すリンク、ボタンまたはアイコンを、シンプルにクリックすること、タップすること、またはこれら以外の方法で選択することができる。ユーザは、支払い要求毎に自身で変更することの可能なデフォルトの資金ソースを選択することもできる。さらに、ユーザは、全ての資金ソースのうち口座に関連する部分のみを、その種類の支払いについての利用可能な資金ソースとして選択することもできる。

支払先への支払いとともに、メッセージを任意選択で含めることもできる。ユーザが、こうしたメッセージを含めることを希望する場合、ステップ１１２でそれを入力することができる。メッセージ入力は、デバイス・キーパッドまたはキーボードからメッセージをタイプすること、テキストに変換することまたは音声ファイルとして送信することの可能なメッセージをユーザ・デバイスに吹き込むこと、予め作られているメッセージをリストから選択し、必要に応じて編集すること等の様々な方法で実現することができる。

次に、ユーザは、支払い金額をステップ１１４で入力することができる。やはり、これは、任意の適当な方式で行うことができる。例としては、ディスプレイ・デバイス上の指定のフィールドに金額を入力すること、金額をデバイスに吹き込むこと、金額のリストから選択することがある。一実施形態では、通貨を選択することもでき、デフォルト通貨は、銀行もしくはユーザの所在とされるか、または、ユーザが設定する。

要求された情報または所望の情報が入力または選択された後、ユーザは、ステップ１１６で、この情報を確認するように求められることがある。これには、支払先が正しく識別されているか、適当な金額が表示されているか、正しい資金ソースが識別されているか、メッセージがあればこれが正しいかを確かめることが含まれる。正しくなければ、ユーザは、ステップ１１８で、誤ったフィールドまたは部分を選択し、正しい情報を入力または選択するなどして修正を行うことができる。

ユーザが「確認」ボタン／リンク等を選択するなどすることにより、支払いの詳細を確認すると、支払い要求が処理される。処理の後、ユーザは、支払い要求についての通知を受け取るが、この通知は、同一のユーザ・デバイス上で受け取ることができる。この通知は、バンキング・サイト上などの、支払い要求が作成されたのと同一の画面上またはこれとは異なる画面上にあってもよい。言い換えると、ユーザは、支払いの開始および支払い要求の通知の受取りを全て、ユーザの銀行サイトを通じて行うことができる。通知は、支払いが行われたことの確認、または、支払い要求を完了させることができなかったという否定のうちの１つである場合がある。否定には、資金が不十分であること、有効な支払先でないこと（例、識別不能）等の理由が含まれることがある。ユーザには、理由の修正および支払い要求の再提出の選択肢が与えられることがある。

こうして、ユーザは、支払先の電子メール、携帯電話番号または他の識別要素を入力するだけで、ユーザの銀行または金融機関を通して、支払先に直接の支払いを迅速かつ容易に行うことができる。

図２は、ユーザにより銀行サイトまたは金融機関サイトを通して開始された金融取引を行うのに際し、銀行または金融機関が実行するプロセス２００の一実施形態を示すフローチャートである。ステップ２０２で、銀行は、ブラウザ、モバイル・ブラウザ、または銀行のモバイル・アプリケーションを通して、ユーザ・ログイン情報を、ＰＣやスマートフォン等のユーザ・デバイスを介して受け取る。ログイン情報には、ユーザ・ネームまたは電子メール・アドレスやパスワードまたはＰＩＮ等のユーザ識別要素が含まれる。銀行は、この情報を使用して、ユーザの口座にアクセスし、口座へのアクセスをユーザに提供する。

ユーザが支払いを希望しているという指示を銀行がユーザから受け取ると、銀行は、支払い要求を処理するのに必要な情報をユーザが入力または選択することを可能にする１つまたは複数のページを、ユーザにユーザ・デバイス上で提供する。一実施形態では、銀行は、要求された情報でユーザが返信を行うよう、音声で通知することもできる。これは、対話型ボイス応答（ＩＶＲ）または他の音声技術を通じて行うことが可能である。

図１のプロセスと同様に、銀行が受け取る以下の情報は、異なる順序で受け取ること、部分的にもしくは完全に組み合わせること、および／または、その全ては銀行に必要とされないことがある。ステップ２０４で、銀行は、銀行サイト・ページから銀行サーバへのユーザ・デバイスを介したユーザ通信を通すなどして、ユーザが１回の支払いを希望しているか、繰返し払いを希望しているかを判定する。繰返しが指示される場合、繰返しの詳細をステップ２０６で受け取る。要望があれば、詳細に繰返しの期間および終了日が含まれることがある。

ステップ２０８で、支払先情報が受け取られる。一実施形態では、この情報は、支払先の電子メール・アドレスである。他の実施形態では、この情報は、支払先の携帯電話番号である。これらは、銀行サイトを通したユーザによるマニュアル入力を介して受け取ることも、所望の支払先を、ユーザが連絡先リストを通して選択することで受け取ることもできる。

次に、所望の資金ソースをステップ２１０で受け取る。これは、ユーザが選択したデフォルトの資金ソース、または、ユーザの銀行口座に関連する複数の資金ソースのうちの１つである場合がある。一実施形態では、ユーザは、支払いのために２つ以上の資金ソースを選択することもできる。例えば、ユーザは、１００米ドルの支払いについて、１０米ドルをユーザの当座預金口座から、９０米ドルをユーザの普通預金口座からというように選択することができる。

ユーザが支払いとともに支払先へのメッセージを含めることを希望する場合、メッセージが、ステップ２１２で銀行により受け取られる。メッセージは、支払いが何のためのものかの記述、または、ユーザが支払いとともに伝達を希望する他の何らかの要素である場合がある。メッセージは、テキストまたは音声で送受することが可能である。

ステップ２１４で、銀行は、支払い金額をユーザから受け取る。この額は、ユーザ・デバイスから銀行サイトを通じて受け取られるが、ユーザが金額を入力すること、または、金額のリストから額を選択することにより受け取られることが可能である。任意選択で、通貨を指定することも可能である。

支払い情報が受け取られると、銀行は、ステップ２１６で支払いを処理する。これには、口座に関連する制約が存在するかどうかを判定することが含まれることがある。例えば、この支払いサービスは、使用前にユーザがサービスに明確にサインアップすること、および／または、サービスを承認することを必要とすることがある。このサービスは、支払い金額の限度、特定の期間内に認められる支払い数の限度、誰を支払先とすることができるかについての制約（すなわち、承認された支払先および／または非承認の支払先の指定）等、セキュリティーについての特定の制約をユーザが課することを可能にすることもできる。銀行は、ユーザがどこで要求を作成したかなどのリスク分析を利用することもできるが、この分析は、ユーザ・デバイスから入手可能なＩＰアドレス、デバイスＩＤまたは位置サービス（location service）に基づく場合がある。

支払いを承認することができない場合、ユーザには、修正の機会が与えられることがある。例えば、支払い金額が、特定の資金ソースについて認められている額を超える場合がある。ユーザは、資金ソースを変更すること、または、支払いの一部分を他の資金ソースに割り当てることができる。銀行が支払い要求を最終的に承認することができない場合、ステップ２１８で、それに応じた通知がユーザに行われる。通知は、ユーザのデバイスを介して行うこと、または、ユーザの自宅に電話をかけること、ユーザの自宅住所／請求書送付先住所に郵送を行うこと、ユーザの職場にファックスを送信することなどにより、口座に関連する他のコンタクトを通した他の要素を介して行うことができる。

支払いが承認可能な場合、ステップ２１６での処理は、ユーザの（１つまたは複数の）銀行口座のうちの指定された１つまたは複数の資金ソースに、適当な金額で借方記入を行うことを含む場合がある。銀行は、支払いプロバイダに、または、アグリゲータ等の第三者が支払いプロバイダへの支払いを行っている場合は、この第三者に資金を送ることができる。ユーザが何らかの種類のオーバードラフトによる保護を有するかのごとく、残高よりも高い金額で、ユーザの口座に借方記入を行うことが可能であることを留意されたい。これを行うことができるかどうかは、銀行により異なる。

処理は、支払いを行うための十分な資金がユーザの（１つまたは複数の）口座にある旨の通知を、支払いプロバイダに送ることを含んでもよい。例えば、銀行サーバが、支払いプロバイダ・サーバに情報を伝達してもよい。この情報には、銀行が送り主、支払い金額、および支払先の識別情報を承認したことの確認が含まれてもよい。これにより、支払いプロバイダが、次いで、支払いプロバイダ側で支払いを処理することが可能になるが、このことは、図３に関連して議論する。

支払いプロバイダは、自体の処理の一部分として、支払いを完了させることができるかどうかを判定する。支払いを完了させることができないかもしれない理由には、受け取られた支払先識別情報では、支払先を適当に識別することができない場合がある。例えば、識別要素が携帯電話番号であることがあるが、その電話番号が使用されていない場合、または、識別要素が電子メール・アドレスであるがことがあるが、それが有効でない場合（その電子メールに送られた電子メールが、送信不能として戻って来るような場合）がある。

支払いプロバイダが支払いを完了させることができない場合、銀行は、ステップ２１８で、支払いを完了させることができなかったことを示す通知を受け取る。この通知には、支払先を識別不能であるなどの理由が含まれることがある。支払先の正確な識別等、支払いが潜在的に完了可能である場合、銀行は、ステップ２２０で、この問題を示し、直す必要のある情報を修正するようユーザに要求する通知を、ユーザに送ることができる。例えば、ユーザは、支払先についての他の識別要素を入力するように求められることがある。次いで、新たに受け取られた情報は、ステップ２１６での再度の処理のために、銀行により支払いプロバイダに伝達することができる。

支払いを最終的に完了させることができない場合、銀行は、ステップ２１８で、こうした通知を、入手可能な理由があればこれとともに、支払いプロバイダから受け取ることができ、ステップ２２０で、支払い要求が拒絶されたことをユーザに知らせる通知が、銀行によりユーザに送られる。この通知とともに理由が提供されてもよい。次いで、ユーザの口座に借方記入された資金を、ユーザの（１つまたは複数の）銀行口座に貸方記入することができる。支払い取引が完了可能であること、または完了したことの通知を支払いプロバイダから銀行が受け取るまで、ユーザの口座に資金の借方記入を行う必要はないことに留意されたい。

支払いプロバイダが支払いを完了することが可能である場合、ステップ２１８で、支払いが承認されたことを銀行に知らせる通知が、支払いプロバイダにより送られ、銀行により受け取られる。確認を受け取ると、銀行は、銀行サイトを通してユーザ・デバイスに送るなどして、支払いが送信されたことの通知をユーザに送信することができる。この通知には、送られた金額、支払先情報、送信時刻／送信日等の他の情報、支払先による支払いの受取りまたは回収が行われたか、もし行われていれば、受取り時刻／受取り日、および、その支払いについての取引番号が含まれることがある。

図３は、ユーザにより銀行サイトまたは金融機関サイトを通して開始された金融取引を行うのに際し、サービス・プロバイダまたは支払いプロバイダが実行するプロセス３００の一実施形態を示すフローチャートである。ここに記載するステップは、異なる順序で実行すること、様々な組合せで組み合わせること、および／または、部分的に省略することができることに留意されたい。ステップ３０２で、支払いプロバイダは、銀行からのユーザ支払い要求をサーバ等で受け取る。この要求は、銀行サイトから支払いプロバイダへのＡＰＩコール等、ユーザ・デバイスを通してユーザの銀行口座からユーザにより出される。次いで、銀行は、銀行サーバから支払いプロバイダ・サーバに送るなどして、要求を支払いプロバイダに送信する。この要求は、ユーザが支払いをカバーするのに十分な資金を有しており、銀行が支払いを行うのが可能であると銀行が判断した後に送信することもできる。この要求には、銀行情報と、電子メール・アドレスや携帯電話番号等の支払先識別情報と、氏名、ユーザ・ネーム、電子メール・アドレス、電話番号等のユーザ情報または支払先情報と、支払い金額と、支払日とが、可能であれば含まれてもよい。

ステップ３０４で、支払いプロバイダは、ステップ３０２で受け取った情報に基づいて、銀行が持つ支払いプロバイダの口座にアクセスする。この情報には、銀行名、口座番号、または、銀行が支払いプロバイダに口座を持っているかどうかの支払いプロバイダによる判定を可能にする他の識別要素が含まれてもよい。支払いプロバイダが、銀行が持つ口座を置いていない場合、または、銀行が持つ口座が停止している場合、支払いプロバイダは、口座を作成するように、または、休止口座を使える状態にするように、銀行に通知を送ることもできる。銀行が持つ口座は、一般には資金ソースを含めて、要求される情報を提供するなどすることにより、他のユーザが持つ支払いプロバイダの口座と同様に、開設することまたは使える状態にすることができる。

次に、ステップ３０６で、支払いプロバイダは、受け取った情報から支払先を確定する。例えば、支払いプロバイダは、銀行またはユーザから銀行サイトを通して、電子メール・アドレスまたは携帯電話番号を受け取ることがある。支払いプロバイダが受取り先の身元を確定することを可能にする他のユーザ識別要素が使用可能であってもよい。

識別が行われると、支払いプロバイダは、ステップ３０８で、支払先が支払いプロバイダに口座を持っているかどうかを判定する。これは、支払いプロバイダが自体のデータベース、または、支払いプロバイダによりアクセス可能な、もしくは支払いプロバイダに管理されるデータベース中を検索して、支払先または支払先識別要素が支払いプロバイダ口座に関連しているかどうかを判定することにより行うことができる。

口座が置かれていなかった場合、または、無効のまたは停止された口座が置かれていた場合、支払いプロバイダは、ステップ３１０で、支払先にコンタクトを取ることができる。支払いプロバイダは、受け取った情報を介して、または、無効のまたは停止された口座からの情報を介して、支払先にコンタクトを取ることができる。例えば、支払先には、携帯電話番号（電話やテキスト等）を用いて、または、電子メール・アドレスを用いて電子メールでコンタクトを取ることができる。このメッセージで、支払先に支払いが行われ、資金を回収するためには、支払先は口座を作成するか、または使える状態にする必要があることを支払先に伝えることができる。このメッセージは、口座を開設するかまたは使える状態にするために支払先を支払いプロバイダに導くための、支払先がアクセスすることの可能なリンクを含むこともある。

ステップ３１２で、支払先は、支払いプロバイダが要求する情報を入力または提供するなどすることにより、口座を開設する（または使える状態にする）ことができる。こうした情報には、住所、電話番号、パスワードまたはＰＩＮ、ユーザ・ネーム、電子メール・アドレス、１つまたは複数のセキュリティー用の質問と答え、１つまたは複数の資金ソース等が含まれることがある。

支払先口座が（ステップ３１２で）作成または（ステップ３０８で）識別されると、支払いプロバイダは、支払い処理を続行することができる。ステップ３１４で、支払いプロバイダは、ステップ３０４で識別された銀行が持つ支払いプロバイダ口座に、適当な金額で借方記入を行うことができる。これは、支払いプロバイダにより銀行に送られる決済レポートに応答して行われてもよいが、この場合、次いで、銀行は、支払いプロバイダに（例えば、電信で、またはＡＣＨを介して）支払いを送る。金額は、厳密に支払い金額であることもあるが、請求される手数料または銀行に対する信用に依存し、支払い金額と比べて多いことや少ないこともある。他の実施形態では、支払いプロバイダが、アグリゲータ等の第三者から支払いを得ることもある。この場合、銀行は、この第三者が持つ支払いプロバイダ口座に借方記入を行うこと、または、この第三者に送られる決済レポートに応答して、電信で、またはＡＣＨを介してこの第三者から支払いを受け取ることができる。この第三者は、支払いをカバーするために、銀行から資金を受け取ることもできる。支払いプロバイダは、１日の終わりや、各取引の後等の任意の設定期間で、口座を決済することができる。

次いで、ステップ３１６で、支払先が持つ支払いプロバイダの口座に、支払額での貸方記入を行うことができる。したがって、支払先には、銀行が持つ支払いプロバイダの口座を通して振込みが行われ、銀行は、ユーザまたは送り主が持つ銀行の口座から資金を受け取る。これにより、ユーザが支払いプロバイダ口座を持たなければならないということはなく、ユーザが、銀行口座を通して容易に支払いを行うことが可能になる。ユーザは、煩わしいサインアップ・プロセスを全く経験する必要がなく、どんな支払先であっても容易に電子メール・アドレスまたは電話番号で指定することができる。

支払いが行われ、完了すると、支払いプロバイダは、ステップ３１８で、通知を送ることができる。この通知は、銀行、ユーザ、および／または支払先に送ることができるが、この通知は、支払いが行われた旨を含むことがある。例えば、支払いプロバイダは、銀行サイトを通して、間接的にユーザに通知を送ることができる。通知は、テキスト、音声、電子メール等の任意の適当な方法とすることができる。

他の実施形態では、支払いプロバイダは、ユーザの銀行情報を様々な用途に利用することもできる。一実施形態では、支払いプロバイダは、ユーザの口座情報、氏名、住所、電話番号、ユーザ・ネーム等を取得するなどして、銀行情報を通してユーザを認証することが可能である。

他の実施形態では、支払いプロバイダは、ユーザの（１つまたは複数の）銀行口座からの利用可能な資金についての知識を利用して、支払いプロバイダを通しての購入を承認または拒絶することができる。例えば、ユーザが、アプリまたはウェブページ上のユーザの口座を通すなどして、支払いプロバイダを介して支払い要求を行っているが、ユーザが持つ支払いプロバイダの口座の資金が不十分である場合にも、やはりこの支払い要求を承認することができる。その状況では、支払いプロバイダは、ユーザの銀行口座または他の金融機関口座のうちの１つまたは複数にアクセスして、利用可能な資金を確定することができる。

ユーザが利用可能な十分な資金を有する場合（例えば、現在の残高でも、オーバードラフトによる保護であっても）、支払いプロバイダは、要求された資金を確保し、支払い要求を承認することができる。次いで、支払いプロバイダは、ユーザが持つ支払いプロバイダ口座からの資金のうちのいくらかまたは全てと、支払いプロバイダ自体から、第三者が持つ支払いプロバイダの口座から、または支払いプロバイダの銀行口座からの残りの金額とを利用することにより、ユーザに代わって支払いを行うことができる。次いで、ユーザの（１つまたは複数の）銀行口座からの確保された資金を、適当な関係者に、例えば、銀行、支払いプロバイダ、または第三者に引き渡すことができる。この結果、ユーザは、例え支払いプロバイダに十分な資金がなくても、支払いプロバイダを通して支払いまたは支払い要求を完了させることが可能である場合もある。

図４Ａ〜４Ｊは、先に述べた支払いプロセスの様々な段階の例示的画面ショットである。図４Ａでは、ユーザが、自身のモバイル・デバイスまたはスマートフォンを通して、自身の金融機関（例、銀行）にアクセスする。ログインを行い、適当な支払いオプションまたは機能を選択した後、ユーザは、支払いを１回払いにするか、繰返し払いにするかを選択することを可能にする画面を見ることができる。適当なオプションを選択またはタップすることにより、ユーザは、次のステップに進むことができる。１回払いの場合、ユーザは、直接図４Ｃに進むことができる。ユーザが繰返し払いを選択した場合、ユーザは、図４Ｂの表示を見ることができる。図４Ｂでは、ユーザは、支払いの開始日、支払いの終了日、および、支払いの繰返し頻度を選択することができる。

図４Ｃは、ユーザが、支払先、送金額、資金ソース、注記またはメッセージ、および、支払いが購入のためのものか個人的なものかどうかの指示を指定することを可能にするためのフィールドを有する画面を示す。支払先フィールドをタップまたは選択することにより、ユーザは、図４Ｄの画面を見ることができるが、この画面は、ユーザが支払先を会社または個人として選択することを可能にする。

支払先が会社となる場合、ユーザは、図４Ｅのような、予め入力または選択した会社のリストを見ることができる。次いで、ユーザは、リストされた会社のうちの１つを支払先として容易に選択することが可能であるが、ここで、各会社は、電子メール・アドレスや電話番号等の識別要素を有する。ユーザが支払先として個人を選択した場合、ユーザは、図４Ｆに示すような、ユーザの連絡先リスト内の全員の連絡先のリストまたは他の連絡先リストを見ることができる。次いで、ユーザは、所望の支払先を連絡先リストから選択することができる。ユーザは、支払先の識別要素を手入力し、先の図面に示すリストを使用しないこととしてもよいことに留意されたい。

図４Ｇは、ユーザが支払いを行う準備ができた場合の表示を示す。図示のように、支払先が識別され（図４Ｅから選択された企業で、企業電子メール・アドレスが自動的に挿入されている）、金額が示され、１回払いの支払いオプションが示され、決済日が示される。決済日は、ユーザがカレンダー等から選択することが可能である。全てが正しければ、ユーザは、「支払いを行う」ボタンを選択して、支払い要求を処理することができる。何か修正が必要であれば、ユーザは、適当なフィールドを選択して、情報を訂正することができる。この例では、資金ソースが選択されなかった。その理由は、利用可能な資金ソースまたは予め選択された資金ソースが１つしかないことである場合もある。

ただし、ユーザが複数の利用可能な資金ソースを有し、１つ選択することを望む場合は、図４Ｈが、支払い用の資金ソースをユーザが選択することを可能にする画面である。銀行に対する４つの資金ソースが、利用可能な残高または額とともに示されている。図４Ｈでは、ユーザの個人当座預金口座が、「個人当座」バーをタップするなどして選択されている。

図４Ｉは、ユーザが支払いを行う準備ができた場合のもう１つの表示を示す。支払先が、氏名および電子メール・アドレスで識別され、金額、資金ソースが、ユーザから支払先への注記またはメッセージとともに示されている。ユーザは、支払いを個人向けとして選択してもいる。全てが承認可能であれば、ユーザは、「今すぐ送信」ボタンを選択して、支払い要求を開始することができる。

成功裏にいけば、ユーザは、図４Ｊの通知を見ることができる。この表示は、送金額および支払先の氏名および電子メール・アドレスを含む。銀行サイトから、支払いプロバイダの身元が表示内に含められていることに留意されたい。このことにより、銀行と支払いプロバイダとの両方が、ユーザに自社の印象を与える機会を増やすことが可能になる。

図５Ａ〜５Ｃは、ユーザの金融機関サイトまたはアプリケーションから支払いが送られてきた後に、支払先が見る例示的画面ショットである。図５Ａは、支払いの詳細を示す、支払先が受け取る電子メールである。この例では、ユーザまたは送り主が、支払いプロバイダとともに識別されている。支払いの詳細は、金額、通貨、送信日、取引番号、およびメッセージを含む。この電子メールは、支払先が支払いを受け取ったことを支払先に伝える。この電子メールは、支払先のＰＣまたはモバイル・デバイスに送信することができる。したがって、支払先は、支払いプロバイダ・サイトにアクセスするなどすることにより、要望通りに資金を回収することが可能である。

図５Ｂは、支払先が、支払先の口座にアクセスするために、支払いプロバイダ・サイトにログインする様を示す。これは、任意のブラウザまたはモバイル・アプリ・ブラウザを通して行うことが可能である。電子メール・アドレスおよびパスワードを入力した後、支払先は、図５Ｃに示すように、ユーザの口座情報の表示を見ることができる。支払日、送り主、支払い状態、金額が示されるので、支払先は、支払いの詳細を見ること、および、支払いプロバイダ・サイトから口座を管理することができる。

図６Ａ〜６Ｃは、ユーザの金融機関を通して支払いを行うためにユーザまたは送り主が見る例示的画像ショットである。図６Ａでは、ユーザが、「代金支払い」オプションを選択した後、所望の全ての情報をユーザの銀行サイトに入力している。ユーザは、送金先として個人を選択している。詳細としては、支払先の氏名、電子メール・アドレス、支払い金額、資金ソース、支払いの種類、支払先へのメッセージが含まれる。確認を行う前に、詳細は修正することができる。続ける準備ができたら、ユーザは、「続ける」ボタンを選択してもよい。

図６Ｂは、支払いレビュー・ページを示す。詳細を図６Ａと比較すると、ユーザが、支払いにユーザの電子メールを追加し、取引の種類を「個人」から「購入」に変更したことが分かる。ユーザは、支払いを行う準備ができると、「送金する」ボタンを選択してもよい。

支払いの後、ユーザは、図６Ｃに示すような支払いの概要を、他の口座情報とともに見ることができる。以前の支払先、最近の支払い金額、最近の支払日、およびまだ行われていない支払いのリストとともに、支払いが送られたことの確認を見ることができる。また、この画面では、ユーザは、以前の支払い先に支払いを行うこと、ある会社を新たな支払先として追加すること、または、個人を新たな支払先として追加することを迅速かつ容易に行うことが可能である。ユーザは、このページ上で、様々なユーザ口座の現在の残高を見ることも可能である。

図７は、先に述べた支払いプロセスで使用されるネットワーク化されたシステム７００の一実施形態を示す。ネットワーク化されたシステム７００は、ネットワーク７１０を介して通信を行う、金融機関または銀行デバイス７０２と、複数の支払先デバイス７０４と、ユーザ・デバイス７０６（支払人）と、支払いプロバイダ・デバイス７０８とを含む。

銀行デバイス７０２、支払先デバイス７０４、ユーザ・デバイス７０６、および支払いプロバイダ・デバイス７０８（これについては、後でより詳細に議論する）は、それぞれ、１つまたは複数のプロセッサと、メモリと、本明細書に記載する様々なアプリケーション、データおよびステップを実行するために１つまたは複数のコンピュータ可読媒体に格納されたプログラム・コードやプログラム・データ等の命令を実行するための他の適当なコンポーネントとを含むことができる。例えば、こうした命令は、システム７００の様々なコンポーネントの内部および／または外部にあるメモリやデータ格納デバイス等の１つまたは複数のコンピュータ可読媒体に格納することができ、かつ／または、ネットワーク７１０を介してこれにアクセス可能である場合がある。

ネットワーク７１０は、単一のネットワークまたは複数のネットワークの組合せとして実装することができる。例えば、様々な実施形態で、ネットワーク７１０には、インターネットおよび／または１つもしくは複数のイントラネット、地上回線ネットワーク、ワイヤレス・ネットワーク、ならびに／あるいは、他の適当な種類のネットワークが含まれることがある。

支払先デバイス７０４およびユーザ・デバイス７０６は、ネットワーク７１０を介した有線および／または無線通信向けに構成されたハードウェアおよび／またはソフトウェアの任意の適当な組合せを使用することで実装することができる。例えば、一実施形態では、支払先デバイス７０４およびユーザ・デバイス７０６は、インターネットまたはモバイル・キャリア・ネットワークと通信を行うユーザのスマートフォンとして実装することができる。他の実施形態では、支払先デバイス７０４およびユーザ・デバイス７０６は、パーソナル・コンピュータ、ＰＤＡ、ラップトップ・コンピュータ、タブレット、および／または他の種類のコンピューティング・デバイスであることもある。

支払先デバイス７０４およびユーザ・デバイス７０６は、例えば、ネットワーク７１０を介して入手可能な情報をユーザがブラウズすることを可能にするのに都合の良いインタフェースを提供するのに使用することのできる、１つまたは複数のブラウザ・アプリケーションを有することがある。例えば、ブラウザ・アプリケーションは、インターネットを介して入手可能な情報を見るために構成されたウェブ・ブラウザまたはモバイル・アプリとして実装することができる。

支払先デバイス７０４およびユーザ・デバイス７０６は、例えば、ユーザに選択されるオペレーションに応答して、所望のタスクを実行するための処理を行うために使用することのできる１つまたは複数のツールバー・アプリケーションまたはモバイル・アプリも有することがある。一実施形態では、こうしたアプリケーションで、ブラウザ・アプリケーションに関連させてユーザ・インタフェースを表示することができる。

支払先デバイス７０４およびユーザ・デバイス７０６は、特定の実施形態で所望されることのある他のアプリケーションまたはモバイル・アプリを更に含んで、これらデバイスに所望の機能を提供することもできる。具体的には、こうした他のアプリケーションまたはアプリには、支払いプロバイダを通してユーザのバンキング・サイトから行われる、または受け取られる支払いのための支払いアプリケーション／アプリが含まれることがある。また、これら他のアプリケーション／アプリには、ユーザ側セキュリティー機能を実装するためのセキュリティー・アプリケーション、ネットワーク７１０を介して適当なアプリケーション・プログラミング・インタフェース（ＡＰＩ）とインタフェースを取るためのプログラム的ユーザ・アプリケーション、または他の種類のアプリケーションが含まれることもある。電子メール・アプリケーション／アプリ、および／または、テキスト・アプリケーション／アプリが含まれることもあるが、これらにより、ユーザが、電子メールやテキスト・メッセージ等の通知を、ネットワーク７１０を介して送受することが可能になる。支払いデバイス７４０およびユーザ・デバイス７０６は、例えば、オペレーティング・システム・レジストリ・エントリ、ブラウザ・アプリケーションに関連するクッキー、支払先デバイス７０４およびユーザ・デバイス７０６のハードウェアに関連する識別子、または電話番号等の他の適当な識別要素として実装することのできる１つまたは複数のユーザ識別要素および／またはデバイス識別要素を含むこともある。一実施形態では、支払いプロバイダに管理される特定の口座に支払人を関連付けるために、ユーザ識別要素が支払いプロバイダにより使用されることがある。

支払いデバイス７０４は、個人ではなく販売業者に操作される場合は、例えば、オンライン販売業者、デジタル商品の販売者、個人販売者、レストラン、バー、ならびに／または、ネットワーク７１０を介して受け取られる支払いと引き換えに様々な製品および／もしくはサービスを提供する法人もしくは個人に維持されてもよい。この点に関して、支払先デバイス７０４は、支払人による閲覧および購入のために利用可能にすることのできる入手可能な製品および／またはサービス（例えば、これをまとめてアイテムと称する）を識別するデータベースを含むことがある。

支払先デバイス７０４は、支払先によるアイテムの購入を容易にするように構成することのできるチェックアウト・アプリケーション／アプリも含む。チェックアウト・アプリケーション／アプリは、ユーザからの支払い情報および／またはネットワーク７１０を介した支払いサービス・プロバイダからの支払い情報を承認するように構成してもよい。

銀行デバイス７０２は、銀行サイトまたは銀行アプリを通してユーザ・デバイス７０６との情報の送受信を行う等のユーザ・デバイス７０６との通信、支払い確認用の通知を支払先デバイスに送信する等の支払い先デバイス７０４との通信、ならびに／または、支払い要求を送信し、決済レポートを受け取り、および／もしくは資金を送る等の支払いプロバイダ・デバイス７０８との通信を、銀行デバイス７０２が行うことを可能にするためのコンポーネントおよびソフトウェアを含むサーバ等のコンピューティング・デバイスであってもよい。

支払いプロバイダ・デバイス７０８は、通知をユーザ・デバイス７０６に送信して、送られた支払いを確認する等のユーザ・デバイス７０６との通信、支払いの確認のための通知を支払先デバイスに送り、および／もしくは資金を回収するために口座を作成する等の支払い先デバイス７０４との通信、ならびに／または、支払い要求を銀行デバイスから受け取り、決済レポートを送信し、および／もしくは資金の振込みおよび引き出しを含めた支払い要求の処理を行う等の銀行デバイス７０２との通信を、支払いプロバイダ・デバイス７０８が行うことを可能にするためのコンポーネントおよびソフトウェアを含むサーバ等のコンピューティング・デバイスであってもよい。支払いプロバイダ・デバイス７０８は、識別要素、口座番号、残高、資金ソース、パスワード等のユーザ口座についての情報を格納するデータベースを含むこともある。

図８は、ユーザ・デバイス８００の一実施形態を示す。ユーザ・デバイス８００は、本明細書に記載する支払先デバイスおよび／またはユーザ・デバイスのいずれかまたは全てとすることができる。ユーザ・デバイス８００は、ディスプレイ８０４を保持するシャーシ８０２と、ディスプレイ８０４および複数の入力ボタン８０６を含む入力デバイスとを含む。ユーザ・デバイス８００が、本明細書で議論する方法について先に議論した機能を可能にするタッチ画面入力デバイスと複数の入力ボタンとを含んだ携帯電話であることは、当業者であれば理解するであろう。しかし、本開示内容の範囲を逸脱することなく、他の様々な携帯型もしくはモバイル型の支払人デバイスまたはコンピューティング・デバイスを、本明細書に記載する方法において使用することができる。

図９は、例えば、本明細書に記載する様々な支払人デバイス、ユーザ・デバイス、支払先デバイス、銀行デバイス、および支払いプロバイダ・デバイスを実装するのに適したコンピュータ・システム９００の一実施形態を示す。様々な実装形態で、こうしたデバイスは、ネットワーク７１０と通信を行うことの可能なコンピューティング・デバイス（例、コンピュータ、ラップトップ、スマートフォン、ＰＤＡ、タブレット等）を含む場合がある。

本開示内容の様々な実施形態によれば、コンピュータ、スマートフォン、タブレット、ネットワーク・サーバ等のコンピュータ・システム９００は、情報通信用のバス９０２または他の通信メカニズムを含むが、これらは、処理コンポーネント９０４（例、プロセッサ、マイクロ・コントローラ、デジタル信号プロセッサ（ＤＳＰ）等）、システム・メモリ・コンポーネント９０６（例、ＲＡＭ）、静的格納コンポーネント９０８（例、ＲＯＭ）、ディスク・ドライブ・コンポーネント９１０（例、磁気的または光学的）、ネットワーク・インタフェース・コンポーネント９１２（例、モデムまたはイーサーネット・カード）、ディスプレイ・コンポーネント９１４（例、ＣＲＴ、タッチ画面、またはＬＣＤ）、入力コンポーネント９１８（例、キーボード、キーパッド、タッチ画面、または仮想キーボード）、カーソル制御コンポーネント９２０（例、マウス、ポインタ、タッチ画面への入力の制御手段、またはトラックボール）等のサブシステムおよびコンポーネントを相互接続する。一実装形態では、ディスク・ドライブ・コンポーネント９１０が、１つまたは複数のディスク・ドライブ・コンポーネントを有するデータベースを含むこともある。

本開示内容の実施形態によれば、プロセッサ９０４が支払人デバイス、支払先デバイス、ユーザ・デバイス、銀行デバイスおよび／または支払いプロバイダ・デバイスについて本明細書で記載するもののような、システム・メモリ・コンポーネント９０６に含まれる命令からなる１つまたは複数のシーケンスを実行することにより、コンピュータ・システム９００が、特定のオペレーションを行う。こうした命令は、静的格納コンポーネント９０８やディスク・ドライブ・コンポーネント９１０等の他のコンピュータ可読媒体からシステム・メモリ・コンポーネント９０６に読み込むことができる。他の実施形態では、本開示内容を実現するために、ソフトウェア命令の代わりに、またはこれと組み合わせて、ハードウェアにより実現される回路を使用することもある。

ロジックをコンピュータ可読媒体内で符号化することもできるが、この媒体は、実行用の命令のプロセッサ９０４への提供に関与する任意の媒体を指すことがある。こうした媒体は、不揮発性媒体、揮発性媒体および伝送媒体を含めた多くの形式を取ることができるが、これらに限定されない。様々な実装形態で、不揮発性媒体には、ディスク・ドライブ・コンポーネント９０１等の光学ディスクまたは磁気ディスクが含まれ、揮発性媒体には、システム・メモリ・コンポーネント９０６等の動的メモリが含まれ、伝送媒体には、バス９０２を備える線を含め、同軸ケーブル、銅線および光ファイバが含まれる。一例では、伝送媒体は、電波通信中および赤外線データ通信中に生成されるもののような、音波または光波の形を取ることがある。

一般的な形状のコンピュータ可読媒体の中には、例えば、フロッピーディスク、フレキシブル・ディスク、ハードディスク、磁気テープ、他の任意の磁気媒体、ＣＤ-ＲＯＭ、他の任意の光学媒体、パンチ・カード、紙テープ、孔のパターンを伴う他の任意の物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ-ＥＰＲＯＭ、他の任意のメモリ・チップもしくはカートリッジ、搬送波、または、そこから読取りを行うようにコンピュータを適合させる他の任意の媒体が含まれる。

本開示内容の様々な実施形態で、本開示内容を実践するための命令シーケンスの実行は、コンピュータ・システム９００で行うことができる。本開示内容の他の様々な実施形態で、通信リンク９２４によりネットワーク７１０（例えば、ＬＡＮ、ＷＬＡＮ、ＰＴＳＮ、および／または、テレコミュニケーション、モバイル・ネットワーク、携帯電話ネットワークを含めた他の様々な有線もしくは無線ネットワーク等）に結合された複数のコンピュータ・システム９００が、命令シーケンスを実行して、互いに協働して本開示内容を実践することができる。

コンピュータ・システム９００は、１つまたは複数のプログラム（すなわち、アプリケーション・コード）を含め、メッセージ、データ、情報および命令を、通信リンク９２４およびネットワーク・インタフェース・コンポーネント９１２を通して送受することができる。ネットワーク・インタフェース・コンポーネント９１２は、通信リンク９２４を介した送信および受信を可能にするためのアンテナを含むことがあるが、このアンテナは、分離していても一体化されていてもよい。受信されるプログラム・コードは、それが受信されたとき、および／または、それが実行のためにディスク・ドライブ・コンポーネント９１０または他の何らかの不揮発性格納コンポーネントに格納されたときに、プロセッサ８０４で実行することができる。

適切であれば、本開示内容で実現される様々な実施形態を、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合せを使用して実施することもできる。また、適切であれば、本開示内容の範囲から逸脱することなく、本明細書で記載する様々なハードウェア・コンポーネントおよび／またはソフトウェア・コンポーネントを、ソフトウェア、ハードウェア、および／またはこれらの両方を含む複合コンポーネントに組み合わせることもできる。適切であれば、本開示内容の範囲から逸脱することなく、本明細書で記載する様々なハードウェア・コンポーネントおよび／またはソフトウェア・コンポーネントを、ソフトウェア、ハードウェアまたはこれらの両方を含む複数のサブコンポーネントに分離することができる。さらに、適切であれば、ソフトウェア・コンポーネントをハードウェア・コンポーネントとして実装すること、ハードウェア・コンポーネントをソフトウェア・コンポーネントとして実装することもできることが企図される。

本開示内容によれば、プログラム・コードやデータ等のソフトウェアを、１つまたは複数のコンピュータ可読媒体上に格納することができる。本明細書で特定するソフトウェアを、１つまたは複数の汎用または特定用途のコンピュータおよび／またはコンピュータ・システムを使用して実装することができることも企図されるが、こうしたコンピュータ、コンピュータ・システムは、ネットワーク化されていてもされていなくてもよい。適当であれば、本明細書で説明した特徴を実現するために、本明細書に記載する様々なステップの順序を変更すること、複合ステップに組み合わせること、および／または、複数のサブステップに分離することができる。

先に述べた開示内容は、開示した厳密な形態または特定の使用分野に、本開示内容を限定することを意図しない。よって、本開示内容に対する様々な代替実施形態および／または修正形態が、それらが本明細書中で明示されたか暗示されたかに関わらず、本開示内容に鑑みて使用可能であることが企図される。このようにして記載した本開示内容の実施形態をもって、当業者は、本開示内容の範囲から逸脱することなく、形式および詳細について変更を加えることができることを理解するであろう。したがって、本開示内容は、特許請求の範囲によってのみ限定される。

Claims (12)

1. 金融機関サーバから送信された支払い要求を支払いプロバイダサーバのプロセッサで受け取ることであって、前記支払い要求が、前記金融機関サーバにより維持されているウェブページから生成されたものであって、前記ウェブページのユーザにより開始されるものであり、前記ユーザが、前記金融機関サーバにより維持されている機関口座と前記支払いプロバイダサーバにより維持されている支払い口座とを持つことと、
   前記プロセッサにより、前記支払い要求に含まれる支払先識別要素から支払先を確定することであって、前記支払先識別要素が、電子メール・アドレスまたは電話番号であり、前記支払先は前記金融機関に口座を持たないことと、
   前記支払い要求を、
   前記支払い口座に、前記支払い要求を満たすには不十分な第１の金額の借方記入を行い、
   前記支払いプロバイダサーバにより維持されている前記金融機関の口座に、第２の金額の借方記入を行い、
   前記支払いプロバイダサーバにより維持されている前記支払先の口座に、前記支払い要求を満たす借方記入された前記第１の金額及び借方記入された前記第２の金額の貸方記入を行うことにより処理することと
   を含む方法。
2. 前記処理することには、前記金融機関から第３の金額の支払いを受ける第三者が持つ前記支払いプロバイダの第３の口座に前記第３の金額の借方記入を行うことを含む、
   請求項１に記載の方法。
3. 前記支払い要求が、支払い金額及び前記機関口座に関連する資金ソースの指示を更に含む、
   請求項１に記載の方法。
4. 前記支払い要求が、複数回払いの支払いの繰返しの指示を更に含む、
   請求項３に記載の方法。
5. 前記支払先識別要素が、前記金融機関の前記ウェブページを通して前記ユーザがアクセス可能なリストから選択される、
   請求項１に記載の方法。
6. 支払いプロバイダに口座を持つ複数のユーザについて口座情報を格納するコンピュータ・ストレージであって、前記口座情報が、電子メール・アドレスおよび／または電話番号からなる支払先識別要素を含む、コンピュータ・ストレージと、
   プロセッサと
   を備えるシステムであって、
   前記プロセッサが、
   金融機関サーバから送信される支払い要求を受け取り、前記支払い要求が、前記金融機関サーバにより維持されているウェブページから生成されたものであって、前記ウェブページのユーザにより開始されるものであり、前記ユーザが、前記金融機関サーバにより維持されている機関口座と前記支払いプロバイダのサーバにより維持されている支払い口座とを持ち、
   前記支払い要求に含まれる支払先識別要素から支払先を確定し、前記支払先識別要素が、電子メール・アドレスまたは電話番号であり、前記支払先は前記金融機関に口座を持たず、
   前記支払い要求を、
   前記支払い口座に、前記支払い要求を満たすには不十分な第１の金額の借方記入を行い、
   前記支払いプロバイダサーバにより維持されている前記金融機関の口座に、第２の金額の借方記入を行い、
   前記支払いプロバイダサーバにより維持されている前記支払先の口座に、前記支払い要求を満たす借方記入された前記第１の金額及び借方記入された前記第２の金額の貸方記入を行うことにより処理するように動作可能である、システム。
7. 前記プロセッサが、前記金融機関から第３の金額の支払いを受ける第三者が持つ前記支払いプロバイダの第３の口座に前記第３の金額の借方記入を行うように更に動作可能である、
   請求項６に記載のシステム。
8. 前記支払い要求が、支払い金額及び前記機関口座に関連する資金ソースの指示を更に含む、
   請求項６に記載のシステム。
9. ユーザにより開始された支払い要求を金融機関サーバのプロセッサで受け取ることであって、前記支払い要求が、前記金融機関サーバにより維持されているウェブページから生成されたものであり、前記ユーザが、前記金融機関サーバにより維持されている機関口座を持つことと、
   前記プロセッサで、前記支払い要求を支払いプロバイダサーバに送ることであって、前記支払い要求が、電子メール・アドレスおよび／または電話番号からなる支払先識別要素を含み、前記ユーザは、前記支払いプロバイダサーバにより維持されている支払い口座を持つことと、
   前記支払い口座に、前記支払い要求を満たすには不十分な第１の金額の借方記入を行うことと、
   前記機関口座に第２の金額の借方記入を行うことと、
   前記支払いプロバイダサーバにより維持されている前記支払先の口座に、前記支払い要求を満たす借方記入された前記第１の金額及び借方記入された前記第２の金額の貸方記入を行うことと、
   を含む方法。
10. 前記金融機関が持つ前記支払いプロバイダサーバにより維持されている前記金融機関の口座から前記支払いプロバイダサーバに資金を送ることを更に含む、
    請求項９に記載の方法。
11. 前記支払いプロバイダサーバにより維持されている口座を有する第三者に資金を送ることを更に含む、
    請求項９に記載の方法。
12. 前記支払い要求が、支払い金額及び前記機関口座に関連する資金ソースの指示を更に含む、
    請求項９に記載の方法。