JP2011526388A - 通信クライアントを使用した支払いの実施 - Google Patents

Abstract

携帯電話機などの通信クライアントを使用して第三者への支払いを行うための方法および装置が開示される。支払いは、通信クライアントとサードパーティのサブシステムとの間で通信を確立するように適合された仲介プラットフォームを通じて行われる。仲介プラットフォームは、通信クライアントから着信リクエストを受信し、通信クライアントが携帯電話番号を有するかどうかを判断し、携帯電話番号がその番号自体とバインドされた支払い口座を有するかどうかをさらに判断する。有する場合には、仲介プラットフォームが通信クライアントからの支払いリクエストを受け入れ、支払いを完了するために支払い口座から引き落としを行う。仲介プラットフォームは、ＰＣなどのネットワーククライアントを通じて第三者に支払いを行う目的で使用されることもある。

Description

本発明は、通信分野に関し、特に通信クライアントを使用した支払い方法およびシステムに関する。

今日では、ネットワーク経由でのオンラインショッピングが主流になった。しかし、すべての人がネットワークを使用して便利に買い物ができるわけではない。さらに、多数の既存電話顧客グループのほんの一部だけが、ワイヤレス通信システムを使用して、単なる通信以外の事業活動を行っている。

今日、通信クライアントを使用した最も広く目にする支払い方法の１つが遠隔ショッピングである。遠隔ショッピングは、固定電話機、携帯電話機、またはパーソナルハンドフォンシステムなどの通信クライアントを利用する。遠隔ショッピング方法のワークフローは、以下の通りである。まず、小売商が、新聞、雑誌、およびテレビなどのメディアを通じて商品情報および関連する支払い方法を広告する。ユーザは、ユーザエンドの通信クライアント（携帯電話機や固定電話機など）を使用して、小売商のコールセンターとの通信を確立する場合があり、購入する商品と対応する支払い方法とを小売商に知らせる場合がある。最後に、ユーザが支払いを行ったことを確認すると、小売商が商品を発送する。あるいは、小売商が対面の手渡しで商品を発送し、支払いを受け取ってもよい。小売商のコールセンターに配備され得る装置は、並列性処理能力を有するスイッチング装置と、複数のユーザからのコールを処理するための一定数の通信クライアントとを含む。ただし、運営費（すなわち、スイッチング装置と通信クライアントとを購入し、維持するための費用、コールに応答する人員を雇用するための費用など）を考慮すると、応答できるユーザコールの件数は極めて限られることがある。これにより、従来の小売商コールセンターでは、ユーザの待ち時間が過剰に長くなることがあり、そのために一部のユーザが取引をあきらめ、こうしてユーザと小売商との間で取引が成立する割合が低下する。全体的な操作モデルという視点から、小売商は仮想小売商とみなされる。小売商から購入される品目の品質の信憑性も品質も、ユーザは判断することができない。小売商の視点から見た場合の最大の課題は、売上高を改善するために、ユーザの不信感をいかにして減らすかである。

ＹｅｅＰａｙおよびＰａｙＥａｓｅなどの仲介プラットフォームは、通信クライアントを使用したテレフォンバンキングという支払い方法を提供してきた。この支払い方法は、ユーザの支払いのセキュリティを改善し、それゆえ、取引が成立する割合をある程度まで改善する。この方法の支払いプロセスは以下の通りである。

まず、ユーザが、テレフォンバンキング用のカード発行者の銀行カードを事前に指定する。

ＹｅｅＰａｙおよびＰａｙＥａｓｅなどの仲介プラットフォームと協同する小売商に対する商品注文を完了したら、ユーザは、仲介プラットフォームの電話支払い方法を選択し、電話番号を残す。

注文完了後、ユーザは、カード発行者のテレフォンバンキングサービスホットラインに電話をかけ、仲介プラットフォームの電話支払いを選択する。発信元の番号が、注文を出すときに残した電話番号と一致すれば、あとはその注文に対する支払いを確認するだけでよい。一致しない場合には、ユーザが、注文を出すときに残した電話番号を最初に入力する。注文情報の音声レポートを聞いたら、ユーザはキーを押して支払いを確認し、完了する。

最後に、ユーザが支払いを確認した後、カード発行者が、そのユーザの銀行カードから対応する金額を引き落とし、引き落とし成功のステータスを仲介プラットフォームに返すと、その後仲介プラットフォームが、ユーザが正常に支払いを行ったことを小売商に通知する。

通信クライアントを使用したこの支払い方法には、いくつかの技術的な欠陥が存在する。この方法は、限られた数の銀行からしかサポートを受けることができず、小売商がコールセンターシステムを有する必要がある上に、このシステムは頻繁に修正または改造する必要があり、小売商の視点から見ると、比較的高い実装費用および取引費用を伴う。

既存の技術は、「カード払い」支払方法（Ｃｈｉｎａｂａｎｋ Ｐａｙｍｅｎｔの商品であるＭＯＴＯＰＡＹなど）と、支払いを行うためにスマートフォン端末を使用した支払い方法とをさらに含む。「カード払い」支払い方法の例示的なワークフローは以下の通りである。ユーザが、電話で小売商への注文を確認し、クレジットカード番号、ＣＶＶ２コード（すなわち、署名欄に記載されている最後の３桁の数字）、および有効期限などのクレジットカード情報を小売商に提供する。小売商はその後、その情報をカード発行者に照合する。正常な照合を示すフィードバックをカード発行者から受信すると、小売商は注文を確定し、引き落としを完了する。かかるワークフローにも、技術的な欠陥がある。ユーザが注文を止めたり、支払いを拒否したりすることがあり、これにより、小売商に大きな取引リスクが生じる。

スマートフォン端末を使用した上述の支払い方法は、ＵｎｉｏｎＰａｙなどの仲介プラットフォームによって提供されるスマートフォン端末を使用する必要があり、一定の場所で買い物をするのに適している。しかし、この支払い方法は、移動するユーザによる購入および支払いを十分にサポートしておらず、小売商が端末装置を購入するための追加費用を要し、ＵｎｉｏｎＰａｙなど、スマートフォン端末を使用した小売商向けの仲介プラットフォームによって定められた要件のため、適切な小売商の範囲が狭い。

要約すると、通信クライアントを使用した既存の支払い方法には、以下の欠陥がある。

第１に、通信クライアントを使用して支払いを行う上記従来の方法はすべて、高セキュリティで低コストという便利な支払い方法を提供する域まで達していない。このため、膨大な数の通信顧客にとって、通信以外のビジネスを開拓する可能性が大幅に制限される。例えば、ＹｅｅＰａｙおよびＰａｙＥａｓｅなどの仲介プラットフォームによって提供されるテレフォンバンキングの通信端末を使用した支払い方法は、支払いについてのセキュリティは高いものの、今のところ、ほんのわずかなカード発行者しか、これらの種類の支払いをサポートしていない。これらの支払い方法は、操業しているバイヤーおよび小売商が被る不便を理由に、使用範囲が狭い。「カード払い」支払い方法は、ユーザが最初に注文を確認し、その後小売商が商品を発送し、最後に小売商がカード発行者を通じて支払いを受け取るというパターンを採用している。不完全な個人信用システムを有し得る今日の社会において、このパターンは、小売商にとっての取引セキュリティが低い。スマートフォン端末を使用した支払い方法は、各小売商が新たなハードウェアに出費する必要があり、そのために取引コストが上昇する。

第２に、買い物プロセス内で支払いを行うために通信クライアントを使用することは、用途が限られている。

第３に、電話機およびインターネットを使用した既存の買い物方法は、２つの別々のシステムに属し、リソースを共有しないため、リソースの浪費を招く。

携帯電話機などの通信クライアントを使用して支払いを行うための方法および装置が開示される。支払いは、通信クライアントとサードパーティのサブシステムとの間で通信を確立するように適合された仲介プラットフォームを通じて行われる。仲介プラットフォームは、通信クライアントから着信リクエストを受信し、通信クライアントが携帯電話番号を有するかどうかを判断し、その携帯電話番号とバインドされた支払い口座が存在するかどうかをさらに判断する。存在する場合には、仲介プラットフォームが通信クライアントからの支払いリクエストを受け入れ、支払いを完了するために支払い口座から引き落としを行う。

仲介プラットフォームは、支払いカード発行者との通信を確立し、口座再入金サービスを受け入れるために、仲介プラットフォーム自体に口座サブシステムをインストールした。携帯電話番号とバインドされる支払い口座は、支払いカード発行者によって開設されてもよい。

一実施形態において、仲介プラットフォームは、通信クライアントとワイヤレスで通信するように適合されている。仲介プラットフォームは、テキストメッセージングまたはＴＴＳベースの音声プロンプトを通じて通信クライアントと通信するように適合されている場合もある。仲介プラットフォームは、サードパーティのサブシステムと支払いカード発行者のサブシステムにより、口座確認と決済を周期的に行うように適合されている。

サードパーティのサブシステムはサードパーティの払受人に帰属することがあり、支払いリクエストは、少なくともサードパーティのサブシステムの情報を含む。

一実施形態において、方法はさらに、仲介プラットフォームとインターネットとの間で接続を確立し、インターネットを通じて仲介プラットフォームにアクセスするユーザによってリクエストされた操作を実行する。この操作は、ユーザの口座情報の準備、ユーザ識別情報の準備、支払い情報および支払い口座情報の問い合わせ、および携帯電話番号と支払い口座とのバインドを含む１つ以上の処理であり得る。

一実施形態において、方法は、ランダム検証コードをテキストメッセージという形態で携帯電話番号に送信することと、ユーザが返す検証コードを受信することと、ランダム検証コードとユーザが返す検証コードとを比較することとにより、携帯電話番号を検証する。

支払い口座から引き落としを行う前に、引き落としの最大限度額が設定されることがある。引き落としは、この最大限度額を満たす場合に限り、仲介プラットフォームによって行われる。

仲介プラットフォームは、音声プロンプトまたはテキストメッセージングを通じて通信クライアントと通信するように適合され得る。

携帯電話番号が、その番号自体とバインドされた支払い口座を持っていない場合、方法は、通信クライアントのユーザと関連付けられた支払い口座が仲介プラットフォームに存在するかどうかをさらに判断し得る。存在する場合には、システムが支払い口座と携帯電話番号との間でバインド関係を確立し、存在しない場合には、システムが、ユーザと関連付けられた支払い口座を作成し、支払い口座と携帯電話番号とをバインドする。

一実施形態において、方法は、通信クライアントが仲介プラットフォームを通じて電気通信事業者のサブシステムと通信することを可能にする。電気通信事業者のサブシステムは、仲介プラットフォームから送信された口座引き落としの処理結果に基づいてユーザ口座に再入金するかどうかを判断し、ユーザに再入金結果を通知する。別の実施形態において、サードパーティのサブシステムは公共サービスと関連付けられており、方法はさらに、仲介プラットフォームを通じてサードパーティのサブシステムに支払う必要がある注文番号を含む公共サービス支払い情報を通信クライアントが送信することを可能にする。仲介プラットフォームは、サードパーティのサブシステムの検証情報と料金情報とを含む支払い情報をサードパーティのサブシステムから受信し、サードパーティのサブシステムが公共サービスの支払い状況を修正できるようにするために、サードパーティのサブシステムに口座引き落とし処理結果を返す。

本発明の別の態様は、支払いを行うためのシステムである。このシステムは、通信クライアントからのリクエストと、ネットワーククライアントからのリクエストを別々に処理するように適合された仲介プラットフォームを含む。仲介プラットフォームは、データベース、サーバセンター、およびワイヤレス通信サブシステムを含む。仲介プラットフォームにより、ユーザは、ネットワーククライアントと通信クライアントとの一方または両方を使用してサードパーティのサブシステムに支払いを行うことができる。ワイヤレス通信サブシステムは、ワイヤレス通信ネットワークを通じて通信クライアントとの通信を確立するように適合されている。サーバセンターは、ネットワーククライアントおよびサードパーティのサブシステムと別々に通信を確立する目的で使用されるネットワーク通信インタフェースを含む。

一実施形態において、データベースおよびサーバセンターは、口座処理ユニットと口座記憶ユニットとを含む口座サブシステムを備える。口座記憶ユニットは、携帯電話番号と支払い口座との間のバインド関係を記憶し、口座処理ユニットは支払い口座を作成するように、および支払い口座と携帯電話番号との間でバインド関係を作成し、削除するように適合されている。

一実施形態において、データベースは、支払い情報を記憶する目的、およびサードパーティのサブシステムと仲介プラットフォームとの間で同意された符号化規則を記憶する目的で使用される支払い情報記憶ユニットをさらに含む。データベースは、サードパーティのサブシステムの検証コードを記憶する目的で使用されるサードパーティ記憶域をさらに含み得る。

開示された方法およびシステムは、ネットワーククライアントに加え、通信クライアントも使用して支払いを行うための便利で高セキュリティ、そして低コストの方法を提供する。これにより、オンライン支払いのビジネス用途が広がり、多数の通信顧客が、携帯電話および通信回路などの通信装置を使用した便利で高セキュリティ、そして低コストの支払い方法を活用できるようになる。

添付の図を参照しながら、発明を実施するための形態を記述する。図において、異なる図で同じ参照番号が使用されている場合は、類似または同一の項目を表す。

本発明にかかる通信クライアントを使用して支払いを行うための例示的なシステムの構造図である。 本発明にかかる例示的なワイヤレス通信サブシステムの構造図である。 本発明にかかる通信クライアントを使用した支払いのフローチャートである。

本発明について、添付の図を使用して、以下さらに詳しく説明する。

図１は、本発明にかかる通信クライアントを使用して支払いを行うための例示的なシステムの構造図を示す。このシステムは、ユーザによって使用される通信クライアント１、仲介プラットフォーム２、およびサードパーティのサブシステム３を含む。ユーザの通信クライアント１は、携帯電話機、通信能力を有するＰＤＡ、固定電話機などであり得る。サードパーティのサブシステム３は、小売商、小売商との契約に署名した銀行のサブシステム、公共サービスプラットフォーム、電気通信事業者などであり得る。サードパーティのサブシステム３は、仲介プラットフォーム２との契約に事前に署名し、双方によって合意された第三者と処理手順とに対応する検証コードを準備する。サードパーティのサブシステム３は、ネットワークまたは指定された回線を通じて仲介プラットフォーム２と接続する。そのネットワークは、ワイヤレス通信ネットワークまたはインターネットであり得る。仲介プラットフォーム２は、ワイヤレス通信ネットワーク５を通じてユーザの通信クライアント１と接続する。仲介プラットフォーム２は、同一または異なるユーザによってインターネット経由で使用されるネットワーキングクライアント４とさらに接続し得る。

ユーザは、通信クライアント１を通じて、支払いを行う、口座を準備する、あるいは本人確認情報を設定または修正するなどの操作を実行し得る。あるいは、ネットワーキングクライアント４を通じて、支払いを行う、口座を準備する、あるいは本人確認情報を設定または修正するなどの操作を完了し得る。開示されたシステムは、仲介プラットフォーム２を通じて既存のネットワーク支払いプラットフォームと電話支払いプラットフォームとを統合することで、リソースの共有とユーザ操作の一層の簡便化とを図る。

仲介プラットフォーム２は、データベース２１、サーバセンター２２、およびワイヤレス通信サブシステム２３を含む。一実施形態において、統合されたデータベース２１とサーバセンター２２とのコンポーネントは、口座サブシステムとして共に機能する。例えば、口座サブシステムは、サーバセンター２２の口座処理ユニット２５１とデータベース２１の口座記憶ユニット２１１とを含み得る。口座記憶ユニット２１１は、ユーザの携帯電話番号と口座との間の少なくともバインド関係を記憶する。実践的な用途においては、複数の用途に関する複数のバインド関係が記憶される。口座処理ユニット２５１は、口座を作成する目的、および口座と携帯電話番号との間のバインド関係を作成または削除する目的で使用される。口座サブシステムは、別々に構成されたサーバであってよく、既存のデータベース２１とサーバセンター２２に組み込まれてもよい。例示されたシステムは一般に、サーバセンター２２の処理ユニット２５に組み込まれた口座処理ユニット２５１を有し、データベース２１にセットアップされた口座記憶ユニット２１１を有することで、ハードウェアの関与の低減を図っている。

図２は、例示的なワイヤレス通信サブシステム２３の構造図を示す。このサブシステムは、仲介プラットフォーム２とユーザの通信クライアント１との間でワイヤレス通信ネットワークを通じて通信を確立する目的で主に使用される。ワイヤレス通信サブシステム２３は、事業者スイッチング装置２３１、受信サーバ２３３、送信サーバ２３４、および音声ゲートウェイ２３５と接続しているユーザスイッチング装置（ユーザＰＢＸ ― 構内電話交換システムなど）２３２を含む。音声ゲートウェイ２３５は、サーバセンター２２と通信する可能性があり、ＴＴＳ（テキストから音声への変換）技術を使用してユーザにコールバックするための確認手順の際に主に使用される。支払い情報を含んでいるテキストは、音声ゲートウェイ２３５を通じて音声に変換され、ユーザの応答方法に関する命令を含む音声メッセージを形成する。この手順により、ユーザはもう１度支払い情報を検証することができ、そのユーザの発信元携帯電話番号と、そのユーザと関連付けられた本当の携帯電話番号との間で不一致が見られた場合にユーザの財産の損失を回避する。これにより、取引の利便性が向上するだけでなく、取引のセキュリティも提供される。

図１に戻ると、データベース２１は、支払い情報記憶ユニット２１２、符号化規則記憶域２１３、およびサードパーティ記憶域２１４を含む。支払い情報記憶ユニット２１２は、支払い情報と各支払いの処理結果とを記憶する目的で使用される。符号化規則記憶域２１３は、サードパーティのサブシステム３と仲介プラットフォーム２との間で合意されている符号化規則を記憶する目的で使用される。かかる符号化規則は、テキストメッセージコンテンツおよび／または音声プロンプトと、ユーザまたは取引に関連するテキストメッセージコンテンツおよび音声プロンプトを生成するための規則とを含み得る。サードパーティ記憶域２１４は、仲介プラットフォーム２との契約に署名したサードパーティのサブシステム３の検証コードと、第三者の処理手順とを記憶する目的で使用される。

サーバセンター２２は、ネットワーク通信インタフェース２４と処理ユニット２５とを含む。ネットワーク通信インタフェース２４は、サードパーティのサブシステム３とネットワーキングクライアント４との通信接続を別々に確立する目的で使用される。処理ユニット２５は、ネットワーククライアント処理ユニット２５２、通信クライアント処理ユニット２５３、支払い処理ユニット２５４、および口座引き落とし／確認処理ユニット２５５を含む。

ネットワーキングクライアント処理ユニット２５２は、インターネットを通じて仲介プラットフォーム２にアクセスするユーザからの操作リクエストを受信する目的、およびそのリクエストに基づいてデータベースで関連データを処理する目的で使用される。リクエストされる操作の例は、ユーザの口座情報を準備することと、ユーザ識別情報を準備することと、支払い情報および口座情報を問い合わせることと、携帯電話番号を口座情報とバインドすることとを含む。

通信クライアント処理ユニット２５３は、ユーザの通信クライアント１からの着信リクエストを受信し、所定の手順に基づいてユーザの本人確認を完了し、ユーザによって準備される携帯電話番号とバインド関係を有する支払い口座の情報を検証することを目的に使用される。

支払い処理ユニット２５４は、サードパーティのサブシステム３からの支払い処理リクエストを受信し、サードパーティのサブシステム３に支払い処理結果を返す目的で使用される。

口座引き落とし／確認処理ユニット２５５は、該当する口座の引き落とし処理および／または口座確認を完了する目的で使用される。

図示するとおり、本発明における仲介プラットフォーム２は、インターネット上でネットワーククライアント４と接続できるだけでなく、ワイヤレス通信ネットワーク（ワイヤレス通信ネットワーク５など）を通じて無線通信クライアント１と接続することもできる。さらに、本発明は、ワイヤレス通信ネットワークを通じた買い物の支払い方法と、仲介プラットフォーム２を使用したインターネット経由での買い物の支払い方法とを統合する。ユーザの視点から見ると、この２つの複合支払い方法は、同じユーザが様々な方法で支払い口座にアクセスし、処理することのできる統一支払い口座を持ち得るため、買い物の利便性を高める。小売商などの第三者に関しては、仲介プラットフォーム２との接続が、良好な拡張性および柔軟性を提供するために、インターネット、ワイヤレス通信ネットワーク、または指定された回線を通じて行われ得る。さらに、大きなグループの顧客（ネットワークユーザおよび電話ユーザなど）に同時に対応することができる。銀行などのカード発行者は、仲介プラットフォーム２との契約に署名するだけでなく、単純なインタフェースを維持することも求められる。これにより、高セキュリティおよび低処理コストが実現される。別の視点から見ると、本明細書に記載されている仲介プラットフォーム２を使用することにより、各種リソースが良好に共有される。

図３は、本発明にかかる通信クライアントを使用した支払いのフローチャートを示す。本記述において、プロセスの記載順序は、制限と解釈されることを意図するものではなく、記載されている任意の数のプロセスブロックを任意の順序で組み合わせて、方法または代替方法を実施してよい。図３のプロセスは、次のように記載されている。

ブロックＳ１１０で、仲介プラットフォーム（仲介プラットフォーム２など）が提供される。仲介プラットフォームは、通信クライアントとサードパーティのサブシステムとの間の通信を確立する目的で使用され、複数のカード発行人との通信を確立し、口座への再入金サービスを受け入れるために仲介プラットフォーム自体にインストールされた口座サブシステムを有する。

ブロックＳ１２０で、仲介プラットフォームは、ユーザの通信クライアントから着信リクエストを受信すると、通信クライアントの番号が携帯電話番号であるかどうかを判断する。携帯電話番号でなければ、プロセスはＳ１３０へと続く。携帯電話番号であれば、プロセスはＳ１４０に進む。

ブロックＳ１３０で、仲介プラットフォームは、通信クライアントの番号が携帯電話番号でないと判断したため、ユーザに支払い方法とバインドされている携帯電話番号を入力するように命令し、その後、ユーザによって入力された携帯電話番号を受信する。仲介プラットフォームは、自動テキストメッセージングまたはＴＴＳベースの音声プロンプトを使用してユーザに命令し得る。ユーザによって入力された携帯電話番号を正常に検証すると、プロセスはＳ１４０へ進む。

具体的には、ユーザの通信クライアントから着信リクエストを受信すると、仲介プラットフォームは発信者（すなわちユーザ）の電話番号を解析し、その番号が携帯電話番号であるかどうかを判断する。それが携帯電話番号でない場合、仲介プラットフォームは、例えば音声プロンプトを通じて、検証すべき携帯電話番号を入力するか、いったん電話を切り、以前に登録された携帯電話機を使用して再度電話をかけるように命令し得る。

ユーザによって入力された携帯電話番号を受信すると、仲介プラットフォームは、携帯電話番号を検証する。この番号検証は、利用可能な任意の方法を用いて実施してよい。一般に利用可能な例示的な方法は以下の通りである。仲介プラットフォームは、携帯電話番号と関連付けられている通信クライアントにランダム検証コードを送信し、検証すべき受信検証コードをユーザが入力するのを待つ。ランダム検証コードは、テキストメッセージの形式であり得る。当のユーザが、登録された携帯電話番号と関連付けられた通信クライアントを所有または制御している場合に限り、ユーザは、正しい検証コードを知っており、そのコードを入力する。仲介プラットフォームは、ユーザが入力した検証コードを発信者（すなわちユーザ）の通信クライアントを通じて受信した後、受信した検証コードをランダム検証コードと比較する。受信した検証コードがランダム検証コードと同じであれば、その番号の番号検証は成功とみなされる。

ブロックＳ１４０で、口座サブシステムは、携帯電話番号とバインドされている支払い口座の情報が存在するかどうかを判断する。かかる口座情報が存在する場合、口座サブシステムは、ユーザの通信クライアントからの支払いリクエストを受け入れる。支払いリクエストは、少なくともサードパーティの払受人のサードパーティのサブシステムの情報を含み得る。

口座サブシステムは、携帯電話番号とバインドされている支払い口座の情報を事前に判断する場合がある。かかる支払い口座は、口座名が携帯電話番号である口座か、仲介プラットフォームにある同じユーザの既存口座（Ａｌｉｐａｙ．ｃｏｍの既存口座など）など、別の口座であり得る。かかる口座が存在する場合、ユーザは音声プロンプトにより、例えば、「携帯電話機に再入金するには１を押す、公共料金を支払うには２を押す、買物をするには３を押すなど」という具合に支払いリクエストを入力するよう命令され得る。口座システムは、ユーザによって押されたキーを通じて、ユーザと、関連する第三者とによってリクエストされた支払い項目を判断する。

携帯電話番号とバインドされた支払い口座の情報を口座サブシステムが持っていない場合、口座サブシステムは、ユーザに関連する別の口座が仲介プラットフォームに存在するかどうかを判断する。かかる口座が仲介プラットフォームに存在する場合には、ユーザが本人確認を通過した後に、口座サブシステムが口座と携帯電話番号との間のバインド関係を作成する。存在しない場合、口座サブシステムは、いったん電話を切るか、本人確認情報を入力するようユーザに命令し得る。その後ユーザから本人確認情報を受信し、記憶すると、口座サブシステムは、新しい口座を作成し、それを携帯電話番号とバインドする。

ブロックＳ１５０で、ユーザの通信クライアントは、仲介プラットフォームを通じてサードパーティのサブシステムと双方向の支払い手順を確立し、支払われる金額を確認する。

仲介プラットフォームを通じてサードパーティのサブシステムにアクセスすると、ユーザの通信クライアントは、サードパーティのサブシステムと双方向の支払い手順を直接確立することがあり、サードパーティのサブシステムに、必要な支払い情報（現在の支払いのシリアル番号、支払い金額、第三者の検証コードなど）を仲介プラットフォームに送信させる。あるいは、ユーザの通信クライアントは、仲介プラットフォームを通じてサードパーティのサブシステムと双方向支払い手順を間接的に確立することがあり、サードパーティのサブシステムに、必要な支払い情報を仲介プラットフォームに送信させる。

ブロックＳ１６０で、仲介プラットフォームは、テキストメッセージングまたは音声プロンプトを通じてユーザとの通信を確立し、ユーザが支払いを確認したことを示すフィードバックを受信すると、バインドされている口座から引き落としを行い、引き落としの処理結果をサードパーティのサブシステムおよびユーザに返す。通信クライアントを使用した仲介プラットフォームからユーザへの通信は、自動テキストメッセージングまたはＴＴＳベースの音声プロンプトに基づいている場合がある。

仲介プラットフォームは、以下に記載する例示的な手順に従って、音声プロンプトを通じたユーザとの通信を確立し得る。

（Ａ１）音声情報を動的音声と静的音声とに事前に分類し、動的音声および静的音声の再生順序を決める。

（Ａ２）すべての静的音声を事前に記録および記憶する。

（Ａ３）各動的な音声の各動的パラメータに対応する音声を事前に記録および記憶して、動的パラメータ音声プロファイルを記憶ユニットで確立する。

（Ａ４）ユーザが支払いを確認する必要がある場合には、支払い金額を含む現在の支払い確認用音声メッセージの動的パラメータを判断する。

（Ａ５）現在の支払い確認用音声メッセージの音声パラメータの各々に対応する音声を、動的パラメータ音声プロファイルから見つける。

（Ａ６）所定の再生順序に従って、現在の支払い確認用音声メッセージを作成する。作成された音声メッセージは、ユーザが聞く通信クライアントに送信される。

あるいは、または加えて、仲介プラットフォームは、以下に述べる例示的な手順に従って、テキストメッセージングを通じてユーザと通信を確立し得る。

（Ｂ１）テキスト情報を動的テキスト部分と静的テキスト部分とに事前に分類し、動的テキスト部分と静的テキスト部分との組み合わせ順序を決める。

（Ｂ２）ユーザが支払いを確認する必要がある場合には、支払い金額を含む現在の支払い確認用テキストメッセージの各動的テキスト部分のパラメータを判断する。

（Ｂ３）所定の組合せ順序に従って、現在の支払い確認用テキストメッセージを作成し、テキスト情報を送信する。作成されたテキストメッセージは、ユーザが参照する通信クライアントに送信される。

仲介プラットフォームは、バインドされている口座から引き落としを行い、引き落としの処理結果を、以下に記載する例示的な手順に従ってサードパーティのサブシステムおよびユーザに返す。

（Ｃ１）仲介プラットフォームが、ユーザによる支払いをリクエストするフィードバックを受信した場合には、プロセスが下記のＣ２へと続く。受信しなかった場合には、支払いプロセスが終了し、処理結果はサードパーティのサブシステムに送信されるか、サードパーティのサブシステムおよびユーザに別々に送信される。

（Ｃ２）口座が十分な残高があることを仲介プラットフォームが把握した場合、または十分な残高のある支払いカード口座をユーザが開設した場合には、仲介プラットフォームが引き落としを行い、サードパーティのサブシステムに、またはサードパーティのサブシステムとユーザとに別々に処理結果を送る。その後プロセスは終了する。

例示的な支払いカード口座は、ＡｌｉＰａｙおよび参加している銀行によって共同で提供される新型のオンライン支払いサービスであるＡｌｉＰａｙ ＣａｒｄＰａｓｓである。カード所有者が銀行のカウンターでＡｌｉＰａｙ口座を銀行預金口座または銀行カード口座とバインドした後、ユーザはＡｌｉＰａｙ口座にログインし、その銀行預金口座または銀行カード口座を使用してＡｌｉＰａｙでカード所有者のオンライン支払い処理を直接完了してもよい。このようにして、ユーザはオンライン銀行口座を開設することを必要とせずに、安全で便利なオンライン支払いサービスを享受する。

（Ｃ３）支払いカード口座に十分に残高がないことを仲介プラットフォームが把握し、ユーザが十分な残高を有する支払いカード口座を開設していない場合、仲介プラットフォームは、ユーザに口座に再入金するように命令する。

（Ｃ４）ユーザが口座に再入金した後、支払いプロセスは以前に合意した音声コールバック方法で継続し得る。仲介プラットフォームはその後、口座に十分な残高があるか、あるいはユーザが支払いカード口座を開設したかを再び確認する。残高が十分であるか、支払いカードが開かれた場合には、プロセスが上記Ｃ２に進む。それ以外の場合には、プロセスが上記Ｃ３に進む。

ブロックＳ１７０で、仲介プラットフォームは、サードパーティのサブシステムおよびカード発行者のサブシステムでの口座確認と決済とを周期的に実行する。

ユーザは、事前（口座を申し込む時など）に引き落としの最大限度額を設定してよい。ユーザが本人確認に通り、支払いが最大限度額要件を満たしている場合には、仲介プラットフォームが引き落としを行う。この種の設定は、セキュリティを高めるとともに、支払いリスクを下げる。支払い金額が最大限度額より大きい場合には、支払いのセキュリティを高めるために、より厳格な本人確認が用いられることがある。様々な本人確認方法が使用され得る。例えば、パスワードを入力する必要があり、予め記憶されたパスワードと比較されることがある。パスワードが一致すれば、本人確認は成功とみなされる。あるいは、予め記憶された本人確認情報と比較される本人の識別情報カードの最後の４桁をユーザが入力する。正しく一致すれば、本人確認は成功である。本人確認技術は一般に公知であるので、本明細書ではその詳細を記載しない。

開示された方法はさらに、仲介プラットフォームにインターネットとの接続を確立させることがあり、インターネットを通じて仲介プラットフォームにアクセスするユーザによってリクエストされるいかなる操作も実行し得る。かかる操作の例は、ユーザの口座情報を準備することと、ユーザ識別情報を準備することと、支払い情報および口座情報を問い合わせることと、携帯電話番号を口座情報とバインドすることとを含む。

本明細書に開示される方法およびシステムは、既存の支払い口座（ＡｌｉＰａｙユーザなど）を持っている両方の用途または既存の支払い口座を持ってない用途の両方によって使用され得る。これは、例示的な支払い口座としてＡｌｉＰａｙを使用して例示されている。既存のＡｌｉＰａｙユーザは、携帯電話番号と既存のＡｌｉＰａｙ口座との間で事前にバインド関係を確立するだけで、携帯電話番号を使用して便利に支払いを行うことができる。既存の非ＡｌｉＰａｙユーザは、携帯電話番号から電話をかけるだけで、ＡｌｉＰａｙに口座を作成し得る。口座名は、携帯電話番号であってよい。ユーザは、利用可能なＡｌｉＰａｙ口座再入金方法（電話を使用した再入金など）を用いて口座に入金または再入金し、便利に支払いを行ってよい。さらに、開示された方法は、コールバック技術を使用して、取引のセキュリティを高める。ユーザとサードパーティにとっては、ハードウェア装置を追加する必要がなく、そのため追加費用がかからない。

この方法について、例示的な実装として電話ＡｌｉＰａｙを使用して、以下でさらに説明する。

まず、通話料無料の電話番号が事前に開設される。

ワイヤレス通信サブシステムが、Ａｌｉｐａｙ．ｃｏｍのサーバシステムに追加されて、通信事業者のスイッチング装置との間で確立された接続を通じて電話クライアントと通信する。さらに、携帯電話機への通話時間の再入金、公共サービスの支払い、ＡｌｉＰａｙ口座への再入金、小売商への注文、口座および取引の問い合わせ、システムの構成などの機能がＡｌｉｐａｙ．ｃｏｍで開発された。システム構成は、本人確認情報の準備、口座および携帯電話番号のバインド、ＡｌｉＰａｙサービスの終了または開始などの機能を許容し得る。

ユーザが電話機を使用して通話料無料の電話番号にかけた後、ＡｌｉＰａｙは、その発信元電話番号が携帯電話番号であるかどうかを判断する。携帯電話番号でない場合には、登録されている携帯電話番号がユーザによって入力され、番号検証プロセスを使用して検証され得る。携帯電話番号である場合またはその他の場合には、ユーザによって入力された携帯電話番号が検証され、プロセスは次のステップへと続く。

システムは、その携帯電話番号とバインドされているＡｌｉＰａｙ口座を検索する。かかる口座が見つからない場合には、その携帯電話番号を口座名として使用した口座が作成される。

ＡｌｉＰａｙは、音声プロンプトを使用して、実行する操作を選択するようユーザに命令する。例えば、携帯電話機に通話時間を再入金するには「１」を、公共サービスの支払いを行うには「２」を、小売商に注文を出すには「３」を、という具合に選択する。

処理は、ユーザによって選択された操作に従って完了される。例えば「１」が選択された場合、ユーザの通信クライアントは、仲介プラットフォームを通じて電気通信事業者のサブシステムとの通信を確立し、ユーザの通信クライアントは、通話時間を再入金する必要のある携帯電話番号と再入金額とを電気通信事業者のサブシステムに照合し、電気通信事業者のサブシステムは、電気通信事業者のサブシステムの検証情報と再入金額とを含む支払い情報を仲介プラットフォームに送信し、電気通信事業者のサブシステムは、返された引き落とし処理結果に基づいて再入金するかどうかを判断し、再入金結果をユーザに通知する。

「２」が選択された場合、ユーザの通信クライアントは、支払う必要がある注文番号を含む公共サービス支払い情報を仲介プラットフォームに送信し、仲介プラットフォームは、支払う必要がある注文番号を含む公共サービス支払い情報を、関連するサードパーティのサブシステムに送信し、サードパーティのサブシステムは、サードパーティのサブシステムの検証情報と料金情報とを含む支払い情報を仲介プラットフォームに送信し、サードパーティのサブシステムは、返された引き落とし処理結果に基づいて、自身の側のデータベースで公共サービスの支払い状態を修正する。

応用実施例
１．携帯電話機の通話時間の再入金
（１）当のユーザの携帯電話機への再入金
（Ｓ１１）ユーザがキーを押して携帯電話番号を確認する。ユーザの携帯電話番号の領域または通信事業者に、直接再入金サービスを提供しているプロバイダがない場合には、再入金がその時点でサポートされていないことをシステムがユーザに通知し、「＊」キーを押して戻るようユーザに命令する。

（Ｓ１２）ユーザが再入金額を入力する。ユーザによって入力された再入金額が指定された値（５０または１００など）のいずれかでない場合には、システムが入力エラーを通知し、新たな入力をリクエストする。

（Ｓ１３）ユーザによって入力された再入金額により、同日中の累積再入金額が口座の支払い限度額（２，０００ドルなど）を超える場合には、再入金額が支払い限度額を超えたことをシステムが示し、新たな入力をリクエストする。

（Ｓ１４）ユーザが自ら限度額を設定し、現在の再入金額がそのユーザ定義の限度額以上である場合には、システムが、本人確認情報を入力するようユーザにリクエストするプロンプトを出し、ユーザが再入金情報を確認した後に検証を行う。

（Ｓ１５）ユーザの口座に十分な残高がないものの、（ＡｐｌｉＰａｙ ＣａｒｄＰａｓｓなどの）支払いカード口座とバインドされている場合には、各種状況に応じて以下の手順が実行される。

ａ）デフォルトでバインドされている支払いカード口座が有効化された場合には、システムが、デフォルトの支払いカード口座に対する引き落としリクエストを開始する。引き落としに成功した場合には、口座内のそれぞれの資金が凍結され、再入金リクエストが開始される。同時に、再入金リクエストが提出されたことをシステムがユーザに通知し、再入金結果を待つようユーザに求める。引き落としに失敗した場合には、システムが失敗とその理由（十分な残高以外など）とをユーザに通知し、適切な処理（カード口座への再入金など）を促す。引き落としのステータスが適時に返されない場合には、システムが、ユーザにその旨を通知するか、残高が不十分であり、口座に再入金する必要があることを通知する。正常に引き落とされた金額は、ユーザがアクセスするＡｌｉＰａｙ口座に、再入金額として預け入れられる。

ｂ）デフォルトでバインドされている支払いカード口座が有効化されなかった場合には、システムがデフォルトの支払いカード口座を有効化して、デフォルトの支払いカード口座に対する引き落としリクエストを開始する。引き落としの状態が返された後の手順は上記と同じである。

ｃ）デフォルトでバインドされている支払いカード口座が無効化されており、郵便支払いカード口座である場合には、システムがカードを有効化せず、残高が不十分であり、再入金する必要があることをユーザに通知する。

（Ｓ１６）ユーザの口座に十分な残高がなく、無効化されている複数の支払いカード口座とバインドされている場合には、システムが、残高が不十分であり、再入金する必要があることをユーザに通知するか、支払いカード有効化メニューにアクセスして有効化するようユーザに命令する。

（Ｓ１７）ユーザの口座に十分な残高がなく、どの支払いカード口座ともバインドされていない場合には、システムが、残高が不十分であり、再入金する必要があることをユーザに通知する。

（Ｓ１８）取引が正常に成立したことを示すメッセージを小売商が返した場合には、支払いが行われ、再入金リクエストが提出されたことをシステムがユーザに提示し、再入金オペレータの再入金テキストリマインダに注意するか、販売者のカスタマーサービス電話番号に直接電話をかけるようユーザに求める。同時にシステムは、ユーザの口座内の資金が凍結されている間、小売商からの命令によって取引が進み、支払いが完了するのを待つ。（システムは、取引を自動的に終了し、７日後にそのユーザの口座の資金の凍結を解除する。）
（Ｓ１９）取引が成立しなかったことを示すメッセージを小売商が返した場合には、口座への再入金が失敗し、資金の凍結が解除されていることをシステムがユーザに通知する。

（Ｓ２０）取引が成立したかどうかを示すステータスを小売商が返さなかった場合には、支払いが行われ、再入金リクエストが提出されたことをシステムがユーザに提示し、再入金オペレータの再入金テキストリマインダを待つか、販売者のカスタマーサービス電話番号に直接電話をかけるようユーザに求める。同時にシステムは、ユーザの口座内の資金が凍結されている間、小売商からの命令によって取引が進み、支払いが完了するのを待つ。（システムは、取引を自動的に終了し、７日以内にそのユーザの口座の資金の凍結を解除する。）
（Ｓ２１）累積再入金額は、同日中の累計（２，０００ドルなど）の支払い限度額によって制限される。

（２）別のユーザの携帯電話機への再入金
（Ｓ４１）ユーザが、電話をかける目的で使用する現在の携帯電話番号と同じ再入金対象携帯電話番号を入力した場合、システムはコールバックするのではなく、「当のユーザの携帯電話機に再入金」するためのキーを押して再入金を完了するよう命令する。

（Ｓ４２）別のユーザの携帯電話番号の毎回の再入金において、１回の再入金額が一定の限度額（２００ドルなど）を超えることはできない。蓄積再入金額は、同日中の累計（２，０００ドルなど）の支払い限度額によって制限される。

（Ｓ４３）ユーザは、再入金情報を確認したら、いったん電話を切り、支払いを完了するためにシステムからコールバックを受ける必要がある。

（Ｓ４４）システムがコールバックしなかった場合、またはユーザが何らかの事情でシステムからコールバックを受けなかった場合には、システムが、口座への再入金の失敗をユーザに伝えるためのテキストメッセージを送信し、再入金を再開するようユーザに求める。

他のユーザ操作は、「当のユーザの携帯電話機への再入金」の操作と同じである。

２．商品の注文
開示された方法およびシステムは、くじ、航空券、テレビショッピング、カタログ販売、直接販売など、各種ビジネスにおいて消費者または代理店による商品注文をサポートしている。

（１）本人確認情報を持っているユーザの場合
（Ｓ６１）ＡｌｉＰａｙおよび小売商は、契約に署名し、その後小売商のシリアル番号をその小売商に手動で割り当てる。各小売商は対応する一意のシリアル番号を有する。この番号は、例えば４桁の数字を有し得る。

（Ｓ６２）正しい小売商のシリアル番号が入力された場合には、システムが、注文商品の任意の数量を入力するようユーザに引き続き命令する。間違った小売商シリアル番号が入力された場合には、システムが、指定された小売商が存在せず、再入力が必要であることを示すプロンプトを出す。

（Ｓ６３）システムは、商品名と注文数量を分析対象の小売商に提出し、以下の状況を処理する。

ａ）小売商が分析の成功と商品の詳細とを示す結果を返す。システムは、商品の詳細をユーザに報告し、ユーザに確認用のキーを押すようリクエストする。

ｂ）小売商は分析の失敗を示す結果を返す。システムは、ユーザによって注文された商品が存在せず、再入力が必要であることを示すプロンプトをユーザに出す。

ｃ）小売商が分析結果を返さない。システムは、システムがビジーであることをユーザに提示し、後でもう１度試してみるようユーザに求める。

（Ｓ６４）小売商が商品名の解析成功のステータスを返した後、システムは、以下の異なる状況に応じて取引限度額と支払い限度額を判断する。

ａ）現在注文されている商品に対して支払う必要がある金額が取引限度額（ホワイトリストの小売商の場合で５，０００、通常の小売商で２，０００など）を超えている場合には、金額がシステムの限度額を超えていることをシステムがユーザに知らせ、＊キーを押して戻るようユーザに命令する。

ｂ）現在注文されている商品に対する金額を増額した後に累積金額が１日の支払い限度額（ホワイトリストの小売商の場合で５，０００ドル、通常の小売商で２，０００ドルなど）を超える場合には、システムがユーザに知らせ、その商品に対するユーザの支払い金額がシステムの限度額を超えていることをユーザに知らせ、＊キーを押して戻るようユーザに命令する。

（Ｓ６５）システムがコールバックしなかった場合、またはユーザがコールを受信しなかった場合には、注文に失敗したことを示すテキストメッセージをシステムがユーザに送信する。ユーザがコールを受信した後に支払いを確認しなかった場合には、ユーザからの注文が失敗したことを示す音声プロンプトをシステムが送信する。

（Ｓ６６）ユーザがシステムからコールバックを受信し、キーを押して支払いを確認した後、プロセスは、以下の例示的な状況を有する。

ａ）口座に十分な残高がある。システムが命令を小売商に提出する。システムは、任意で口座の資金を凍結することがあり、携帯電話番号および本人確認情報を含むユーザ情報を任意で小売商に送信することがある。

ｂ）口座に十分な残高がなく、支払いカード口座とバインドされない場合には、注文に失敗したことと、ユーザ残高が不十分であり、再入金する必要があることとをシステムが示す。

ｃ）口座に十分な残高がないが、有効化されたデフォルトでバインドされている支払いカード口座がある場合には、システムが引き落としリクエストを銀行に提出し、以下の異なる状況に従って進む。

− 引き落としに成功した場合には、システムが注文を小売商に提出する。システムは、任意で口座の資金を凍結することがあり、携帯電話番号および本人確認情報を含むユーザ情報を任意で小売商に送信することがある。

− 引き落としに失敗した場合には、注文および支払いに失敗したことをシステムが示し、後でもう１度試すか口座に再入金するようユーザに命令する。

− 引き落としステータスが適時に返されなかった場合には、注文に失敗したことをシステムが示し、口座残高の変更に注意を払うようにユーザに命令する。

ｄ）口座に十分な残高がなく、デフォルトでバインドされている支払いカード口座が郵便支払いカードである場合には、注文に失敗したことと、ユーザの口座の残高が不十分であり、再入金する必要があることとをシステムが示す。

ｅ）口座に十分な残高がなく、デフォルトでバインドされている支払いカード口座が有効化されていない場合には、システムが、デフォルトの支払いカード口座を有効化し、引き落としリクエストを開始して、デフォルトの支払いカード口座と関連付けられている銀行に提出する。

ｆ）ユーザの口座に十分な残高がなく、無効化された複数の支払いカード口座とバインドされた場合には、注文に失敗したことと、ユーザが十分な残高を持っておらず、口座に再入金する必要があることとをシステムが示す。

（Ｓ６７）システムが小売商に注文を提出した後、小売商は以下のステータスを返す。

ａ）小売商は、注文の提出成功のステータスを返す。以下の例示的な方法のいずれかによって支払いが処理される。

− 支払い凍結方法：注文に成功し、支払いが処理されているので、小売商からのコールを待つようシステムがユーザに通知する。システムは、発送に成功して取引が進んだかどうかに関する小売商からのステータス情報を待ち、「支払いの凍結を解除して転送する」または「取引の凍結を解除して終了する」操作を実行する。小売商が取引を進めるための時間が、設定された最長期間（７日など）よりも長くてはらならい。最長期間よりも長かった場合には、システムが取引を自動的に終了する。

− 支払い凍結解除方法：システムが小売商に支払いを行う。正常に支払われると、システムが、注文および支払いに成功したことをユーザに通知し、小売商のカスタマーサービス電話番号に直接電話をかけて商品の発送を確認するようユーザに求める。

ｂ）小売商が注文の提出失敗のステータスを返す。以下の例示的な方法のいずれかによって支払いが処理される。

− 支払い凍結方法：システムが、注文された商品が一時的に品切れになっていることをユーザに通知し、注文と支払いに失敗し、取引が終了し、資金の凍結が解除されたことをユーザに示す。

− 支払い凍結解除方法：注文された商品が一時的に品切れであり、現在の支払いに失敗したことをシステムがユーザに通知する。

ｃ）小売商が注文の提出に関するステータスを適時に返さない。以下の例示的な方法のいずれかによって支払いが処理される。

− 支払い凍結方法：システムが、注文が処理中であることをユーザに通知し、口座残高のいかなる変化にも気をつけ、小売商のカスタマーサービス電話番号に直接電話をかけるようユーザに命令する。システムは、発送に成功して取引が進んだかどうかに関する小売商からのステータス情報を待ち、「支払いの凍結を解除して転送する」または「取引の凍結を解除して終了する」操作を実行する。小売商が取引を進めるための時間が、予め設定された最長期間（７日など）よりも長くてはらならい。最長期間よりも長かった場合には、システムが取引を自動的に終了する。

− 支払い凍結解除方法：注文された商品が処理中であり、支払いが行われていないことをシステムがユーザに通知する。

（２）本人確認情報を持たないユーザの場合
本人確認情報を持たないユーザ、またはｎｕｌｌ値（００００など）の識別情報カード情報を有するユーザの場合には、プロセスが注文を出すための手順に入れるように完全な識別情報カード情報を入力するよう、システムがユーザにリクエストする。注文を出すための手順は、上記支払い手順と同じである。

既存の技術と比較して、開示された方法およびシステムは、以下の潜在的利点を有する。

第１に、開示された方法およびシステムは、ワイヤレス通信ネットワークおよびインターネットを利用するために、電話ベースの支払い方法とネットワークベースの支払い方法とを組み合わせている。この方法およびシステムは、リソースの利用率に加え、効率も改善する。支払い口座を携帯電話番号と直接バインドすることにより、利便性を高めている。ユーザと第三者にとっては、装置を追加する必要がなく、コスト増がない。加えて、仲介プラットフォームがテキストメッセージングまたは音声プロンプトを通じてユーザとの通信を確立し、ユーザが支払いを行ったことを確認したことを示すフィードバックを受信した後にようやく、バインドされている口座の引き落としを仲介プラットフォームで行うため、取引のセキュリティが高まる。具体的には、ユーザが仲介プラットフォームに支払いを行うと、仲介プラットフォームが、ＴＴＳ技術を用いたユーザコールバックに関する検証手順を使用する。この手順を通じて、ユーザは、購入した商品の情報を検証することができ、ユーザの発信元携帯電話番号と、記憶されている検証済み携帯電話番号との間で不一致が見られた場合でも、財産の損失が回避される。

第２に、開示された方法およびシステムは、仲介プラットフォームによるコールバックを使用して検証を行うため、通話費用が発生し、過剰に長く無効な待機につながることもある電話をユーザがかける手間を省く。所定の期間内に仲介プラットフォームからコールバックを受けることで、従来の小売商のコールセンターで非常によく見られるユーザの無駄な待ち時間を減らすことができる。これによって運営費が削減されるだけでなく、ユーザの取引経験が改善され、ユーザと小売商との間で取引が成立する割合も向上する。

第３に、開示された方法およびシステムは、電話を使用した買い物を可能にすることに加え、事業範囲も拡大する。例えば、携帯電話口座に再入金すること、および公共サービスの支払いを行うことが、電話を使用して、仲介プラットフォームを通じて実行できる。

本明細書で述べられている潜在的利点および効果は、添付の請求の範囲に対する限定または制限として解釈されるべきでないと理解される。

上記の内容は、構造的な特徴および／または方法論的な行為に特有の言語で記載したものの、添付の請求の範囲において定義される内容は、記載されているその特定の特徴または行為に必ずしも制限されるものではないことを理解すべきであり、むしろ、その特定の特徴および行為は、請求項を実装する例示的な形態として開示される。

Claims (16)

1. 通信クライアントを使用して支払いを行う方法であって、
   通信クライアントとサードパーティのサブシステムとの間で通信を確立するように適合されている仲介プラットフォームを提供することであって、前記仲介プラットフォームが、支払いカード発行者との通信を確立し、口座再入金サービスを受け入れるために、口座サブシステムを仲介プラットフォーム自体にインストールしたことと、
   前記仲介プラットフォームで前記通信クライアントから着信リクエストを受信すると、前記通信クライアントが携帯電話番号を有するかどうかを判断し、有しなければ前記ユーザに携帯電話番号を入力するように命令することと、
   前記携帯電話番号がその番号自体とバインドされた支払い口座を有するかどうかを判断し、有すれば前記通信クライアントからの支払いリクエストを受け入れることと、
   前記支払い口座から引き落としを行い、前記引き落としの処理結果を前記サードパーティのサブシステムと前記通信クライアントとに返すことと、
   を含む方法。
2. 前記仲介プラットフォームは、前記通信クライアントとワイヤレスで通信するように適合されている、請求項１に記載の方法。
3. 前記仲介プラットフォームは、自動テキストメッセージングまたはＴＴＳベースの音声プロンプトを使用して前記通信クライアントと通信するように適合されている、請求項１に記載の方法。
4. 前記サードパーティのサブシステムはサードパーティの払受人に帰属し、前記支払いリクエストは前記サードパーティのサブシステムの少なくとも情報を含む、請求項１に記載の方法。
5. 前記携帯電話番号とバインドされた前記支払い口座は、前記支払いカード発行者によって開設される、請求項１に記載の方法。
6. 前記仲介プラットフォームは、前記サードパーティのサブシステムと前記カード発行者のサブシステムとによって口座の確認と決済を周期的に行うように適合されている、請求項１に記載の方法。
7. 前記仲介プラットフォームとインターネットの間で接続を確立することと、前記インターネットを通じて前記仲介プラットフォームにアクセスするユーザによってリクエストされる操作を実行することとを更に含む方法であって、前記操作は、前記ユーザの口座情報を準備することと、ユーザ識別情報を準備することと、支払い情報と前記支払い口座情報とを問い合わせることと、前記携帯電話番号を前記支払い口座とバインドすることと、を含む１つ以上の処理を備える、請求項１に記載の方法。
8. 前記携帯電話番号を検証することをさらに含む、請求項１に記載の方法。
9. 前記携帯電話番号を検証することが、
   ランダム検証コードをテキストメッセージの形式で前記携帯電話番号に送信することと、
   ユーザが返す検証コードを受信することと、
   前記ランダム検証コードを前記ユーザが返す検証コードと比較することと、
   を含む、請求項８に記載の方法。
10. 前記支払い口座から引き落としを行うことが、
    前記引き落としの最大限度額を予め設定することと、
    前記引き落としが前記最大限度額を満たす場合に前記仲介プラットフォームによって前記引き落としを行うことと、
    を含む、請求項１に記載の方法。
11. 前記仲介プラットフォームは、
    音声情報を動的音声と静的音声とに分類し、前記動的音声と前記静的音声との再生順序を決めることと、
    前記静的音声を記録し、記憶することと、
    動的パラメータ音声プロファイルを確立するために各動的な音声の動的なパラメータの各々に対応する音声を記録し、記憶することと、
    現在の音声メッセージの動的パラメータを判断することと、
    前記動的パラメータ音声プロファイルから前記音声パラメータの各々に対応する前記それぞれの記憶された音声を見つけることと、
    前記所定の再生順序に従って前記現在の音声メッセージを作成することと、
    を含むプロセスを使用して、音声プロンプトを通じて前記通信クライアントと通信するように適合されている、請求項１に記載の方法。
12. 前記仲介プラットフォームは、
    テキスト情報を動的テキスト部分と静的テキスト部分とに分類し、前記動的テキスト部分と前記静的テキスト部分との組み合わせ順序を事前に決めることと、
    現在のテキストメッセージの各動的テキスト部分のパラメータを判断することと、
    前記通信クライアントに送信される前記現在のテキストメッセージを形成することと、
    を含むプロセスを使用して、テキストメッセージングを通じて前記通信クライアントと通信するように適合されている、請求項１に記載の方法。
13. 前記携帯電話番号がその番号自体とバインドされた支払い口座を持っていない場合、
    前記通信クライアントの前記ユーザと関連付けられた支払い口座が前記仲介プラットフォームに存在するかどうかを判断することと、
    存在する場合には、前記支払い口座と前記携帯電話番号との間でバインド関係を確立することと、
    存在しない場合には、前記ユーザと関連付けられた支払い口座を作成し、前記支払い口座を前記携帯電話番号とバインドすることと、
    をさらに含む、請求項に記載の方法。
14. 前記通信クライアントが前記仲介プラットフォームを通じて電気通信事業者のサブシステムと通信することを可能にすることをさらに含み、前記電気通信事業者のサブシステムは、前記仲介プラットフォームから送信される口座引き落としの処理結果に基づいてユーザ口座に再入金するかどうかを判断し、前記ユーザに再入金結果を通知する、請求項１に記載の方法。
15. 前記サードパーティのサブシステムは公共サービスと関連付けられており、
    前記仲介プラットフォームを通じて前記サードパーティのサブシステムに支払う必要がある注文番号を含む公共サービス支払い情報を前記通信クライアントが送信することを可能にすることと、
    前記サードパーティのサブシステムの検証情報と料金情報とを含む支払い情報を前記サードパーティのサブシステムから前記仲介プラットフォームで受信することと、
    前記サードパーティのサブシステムが前記公共サービスのいかなる支払いステータスも修正できるように、口座引き落とし処理結果を前記仲介プラットフォームから前記サードパーティのサブシステムに返すことと、
    をさらに含む、請求項１に記載の方法。
16. ネットワーククライアントからのリクエストと、通信クライアントからのリクエストとを別々に処理するように適合された仲介プラットフォームを備え、前記仲介プラットフォームは、
    データベースと、
    サーバセンターと、
    ワイヤレス通信サブシステムと、
    を含む、支払いを行うシステムであって、前記仲介プラットフォームは、
    ユーザが前記ネットワーククライアントと前記通信クライアントのどちらか一方または両方を使用してサードパーティのサブシステムに支払いを行うことを可能にするように適合されており、
    前記ワイヤレス通信サブシステムは、ワイヤレス通信ネットワークを通じて前記通信クライアントとの通信を確立するように適合されており、
    前記サーバセンターは、前記ネットワーククライアントと前記サードパーティのサブシステムとの通信を別々に確立する目的で使用されるネットワーク通信インタフェースを含み、
    前記データベースと前記サーバセンターとは、口座処理ユニットと口座記憶ユニットとを含む口座サブシステムを備え、前記口座記憶ユニットは携帯電話番号と支払い口座との間のバインド関係を記憶し、前記口座処理ユニットは、前記支払い口座を作成するよう、および前記支払い口座と前記携帯電話番号との間の前記バインド関係を作成し、削除するように適合されており、
    前記データベースは、支払い情報を記憶することと、前記サードパーティのサブシステムと前記仲介プラットフォームとの間で合意された符号化規則を記憶することとを目的に使用される支払い情報記憶ユニットをさらに含み、
    前記データベースは、前記サードパーティのサブシステムの検証コードを記憶することを目的に使用されるサードパーティ記憶域をさらに含む、システム。