JP2016520921A - 課金ゲートウェイ - Google Patents

Abstract

課金ゲートウェイの請求方法及びシステムを開示する。請求は、請求ＡＰＩコールを加盟店サーバから受信して、複数のサーバから選択キャリアサーバを検出して、請求要求を選択キャリアサーバに送信して、請求結果コールバック通知を加盟店サーバに返すことによって処理される。請求要求が失敗すると、加盟店サーバが新規の要求を提示することができ、新規の要求が新規のｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を有するという条件で、新規の要求に基づいて請求要求の承認及び失敗の指示が加盟店サーバに返る。継続方法により、取引を完了するための消費者オプトインの管理が可能になる。取引が完了すると、加盟店サーバからの返金要求は、キャリアサーバへの送信によって処理することができる。取引は、認可ＡＰＩコールを加盟店サーバから受信して、選択キャリアサーバを検出して、認可要求を選択キャリアサーバに送信することによって認可される。次にキャリアサーバは、認可要求に基づいて、資金額を用意することになる。次に、認可要求に基づいて認可された取引が記録される。次に消費者は、取引のキャンセルを要求することができる。キャプチャ要求が受信されると、キャンセル要求が受信されていて、認可された取引がキャンセルされたかどうかを判定する。取引がキャンセルされていない場合は、課金要求がキャリアサーバに送信されて、その結果、キャリアサーバが取引の請求を行う。【選択図】 図５

Description

（関連出願への相互参照）
本出願は、２０１３年４月２９日出願の米国特許出願第１３／８７３，０６８号及び２０１３年４月２９日出願の米国特許出願番号１３／８７３，０９９の優先権を主張するものであり、その開示内容全体は引用により全体が本明細書に各々組み込まれている。

（技術分野）
本発明は、請求を処理するためのシステム及び方法に関する。

商品又はサービスをオンラインで購入する消費者には、精算中に、クレジットカード、デビットカードによる支払い、機関所有の口座からの決済のような支払元の選択を用いるための、或いは、購入代金を携帯電話請求書に課すためのオプションを与えることができることが多い。消費者が自己の電話請求書への請求を選択すると、加盟店サーバは、キャリアサーバと連携する課金サーバに、請求を実行するよう指示する。課金サーバは、通常、キャリアサーバにおいて電話請求書への請求を行う前に請求を確認するために、消費者携帯電話と通信を行う。

課金サーバは、複数の加盟店サーバ及び複数のキャリアサーバと通信する必要がある場合がある。各個別の加盟店サーバの固有の通信要件のために、別の加盟店サーバが追加されるたびに、このような固有の通信を可能にするため、課金サーバにおいて付加的な加盟店固有のコードを作成してアップロードする必要がある。このコードは、請求を処理するためだけに追加する必要があるが、請求不成功の処理、消費者オプトインの制御、キャリアの識別、返金の処理等のために、新規の加盟店サーバ固有のより多くのコードを追加することが必要となる。

本発明は、課金サーバにより、ＭＳＩＳＤＮ及び金額を含む請求ＡＰＩコールを加盟店サーバから受信する段階と、課金サーバにより、複数のキャリアサーバから選択キャリアサーバを判定する段階と、課金サーバにより、ＭＳＩＳＤＮ及び金額を含む請求要求を選択キャリアサーバに送信する段階と、課金サーバにより、請求要求の承認又は失敗の指示を含む請求結果コールバック通知を加盟店サーバに返す段階と、を含む、請求を処理する方法を提供する。

本発明はまた、コンピュータのプロセッサによって実行される場合に請求を処理する方法を実行する命令セットをその上に格納させた、非一時的コンピュータ可読媒体も提供し、本方法は、課金サーバにより、ＭＳＩＳＤＮ及び金額を含む請求ＡＰＩコールを加盟店サーバから受信する段階と、課金サーバにより、複数のキャリアサーバから選択キャリアサーバを判定する段階と、課金サーバにより、ＭＳＩＳＤＮ及び金額を含む請求要求を選択キャリアサーバに送信する段階と、課金サーバにより、請求要求の承認又は失敗の指示を含む請求結果コールバック通知を加盟店サーバに返す段階と、を含む。

本発明はさらに、プロセッサと、プロセッサに接続されたコンピュータ可読媒体と、コンピュータ可読媒体上の命令セットと、を含む課金コンピュータシステムを提供する。命令セットは、ＭＳＩＳＤＮ及び金額を含む請求ＡＰＩコールを加盟店サーバから受信し、複数のキャリアサーバから選択キャリアサーバを判定し、ＭＳＩＳＤＮ及び金額を含む請求要求を選択キャリアサーバに送信し、請求要求の承認又は失敗の指示を含む請求結果コールバック通知を加盟店サーバに返すために、プロセッサにより実行可能なキャリア課金モジュールを含む。

本発明はまた、課金サーバにより、ＭＳＩＳＤＮ及び金額を含む認可要求を含む認可ＡＰＩコールを加盟店サーバから受信する段階と、課金サーバにより、複数のキャリアサーバから選択キャリアサーバを判定する段階と、課金サーバにより、金額に基づいて認可要求を選択キャリアサーバに送信する段階と、課金サーバにより、認可要求に基づいて認可された取引を記録する段階と、課金サーバにより、認可要求を選択キャリアサーバに送信後、キャプチャ要求を含むキャプチャＡＰＩコールを受信する段階と、課金サーバにより、キャプチャ要求に応答して、認可要求後かつキャプチャ要求前に加盟店サーバからキャンセル要求を受信しており、キャプチャ取引がキャンセルされたか否かを判定する段階と、キャプチャされた取引がキャンセルされていない場合は、課金サーバにより、キャプチャ要求に応答して、課金要求を選択キャリアサーバに送信するが、キャプチャされた取引がキャンセルされた場合には送信しない段階と、を含む、請求を処理する方法を提供する。

本発明はさらに、コンピュータのプロセッサによって実行される場合に請求を処理する方法を実行する命令セットをその上に格納させた、非一時的コンピュータ可読媒体も提供し、本方法は、課金サーバにより、ＭＳＩＳＤＮ及び金額を含む認可要求を含む認可ＡＰＩコールを加盟店サーバから受信する段階と、課金サーバにより、複数のキャリアサーバから選択キャリアサーバを判定する段階と、課金サーバにより、金額に基づいて認可要求を選択キャリアサーバに送信する段階と、課金サーバにより、認可要求に基づいて認可された取引を記録する段階と、課金サーバにより、認可要求を選択キャリアサーバに送信後、キャプチャ要求を含むキャプチャＡＰＩコールを受信する段階と、課金サーバにより、キャプチャ要求に応答して、認可要求後かつキャプチャ要求前に加盟店サーバからキャンセル要求を受信しており、キャプチャ取引がキャンセルされたか否かを判定する段階と、キャプチャされた取引がキャンセルされていない場合は、課金サーバにより、キャプチャ要求に応答して、課金要求を選択キャリアサーバに送信するが、キャプチャされた取引がキャンセルされた場合には送信しない段階と、を含む。

本発明はまた、プロセッサと、プロセッサに接続されたコンピュータ可読媒体と、コンピュータ可読媒体上の命令セットと、を含む課金コンピュータシステムを提供する。命令セットは、消費者認可を格納する認可管理モジュールと、認可管理モジュールに接続されてプロセッサによって実行可能なキャリア課金モジュールと、を含み、ＭＳＩＳＤＮ及び金額を含む認可要求を含む認可ＡＰＩコールを加盟店サーバから受信し、複数のキャリアサーバから選択キャリアサーバを判定し、金額に基づいて認可要求を選択キャリアサーバに送信し、認可要求に基づいて認可された取引を記録し、認可要求を選択キャリアサーバに送信後、キャプチャ要求を含むキャプチャＡＰＩコールを受信し、キャプチャ要求に応答して、認可要求後かつキャプチャ要求前に加盟店サーバからキャンセル要求を受信しており、キャプチャ取引がキャンセルされたか否かを判定し、キャプチャされた取引がキャンセルされていない場合は、キャプチャ要求に応答して、課金要求を選択キャリアサーバに送信するが、キャプチャされた取引がキャンセルされた場合には送信しない。

本発明は、添付図面を参照して例示的に説明される。

本発明の実施形態によるデュアルモード課金システムを示すブロック図である。 システムが動作可能な２つのモードを示すフローチャートである。 キャプチャされた取引になる前に認可がキャンセルされる実施例についての認可方法を示す相互作用図である。 キャプチャされてキャプチャ済み取引になる前に認可がキャンセルされない実施例についての認可方法を示す相互作用図である。 消費者携帯電話において消費者による移動体発信のオプトインが実行される場合の請求方法を示す相互作用図である。 消費者携帯電話において消費者によるＰＩＮオプトインが実行される場合の請求方法を示す相互作用図である。 キャプチャ方法の後に返金が処理される方法を示す相互作用図である。 消費者携帯電話のスマートフォン機能を示すブロック図である。 加盟店管理の加入システムの一部を構成するコンピュータシステムの形態のマシンのブロック図である。

添付の図１は、消費者携帯電話１２と、加盟店サーバ１４と、課金サーバ１６と、キャリアサーバ１８とを含む、本発明の実施形態によるデュアルモード課金システム１０を示している。

加盟店サーバ１４は、ユーザインタフェース２０と、課金管理モジュール２２とを含む。ユーザインタフェース２０により、消費者携帯電話１２又は他の消費者デバイスを用いる消費者が、加盟店サーバ１４上のオンラインストアを通じて購入することができる。このような購入の間、消費者は、２４においてコンテンツを購入することができる。システム１０の請求及び継続モードでは、消費者は、２６において、購入のために暗証番号（ＰＩＮ）の入力を求められることがある。システム１０の認可及びキャプチャモードでは、消費者は、購入が認可された後でキャプチャされる前に、２８において購入をキャンセルすることができる。消費者はまた、完了している以前の購入の返金を３０において要求することもできる。

課金サーバ１６は、認可管理モジュール３２と、オプトイン管理モジュール３４と、キャリア課金モジュール３６と、ＳＭＳメッセージングモジュール３８とを含む。加盟店サーバ１４と課金サーバ１６との間の通信は主に、加盟店サーバ１４の課金管理モジュール２２及び課金サーバ１４の認可管理モジュール３２及びオプトイン管理モジュール３４によって行われる。

オプトイン管理モジュール３４は、消費者からのオプトインが要求されるかどうかを判定するために、請求及び継続方法で用いられる。ＳＭＳメッセージングモジュール３８は、オプトイン管理モジュール３４に接続されており、４０において、消費者携帯電話１２を使用中に消費者がユーザインタフェース２０上で入力するためのＰＩＮを含む、購入承認のためのオプトインメッセージを含むショートメッセージサービス（ＳＭＳ）テキストメッセージを消費者携帯電話１２に送信する。オプトイン管理モジュール３４は通常、課金管理モジュール２２から４２で受信する、コンテンツの請求を要求する信号に応答する。消費者がＰＩＮコードを入力した後、課金管理モジュール２２は、４４においてＰＩＮコードをオプトイン管理モジュール３４に提示する。次にオプトイン管理モジュール３４は、キャリア課金モジュール３６と通信して、キャリア課金モジュールが請求をキャリアサーバ１８に送信する。請求が、キャリアサーバ１８によって、課金サーバ１６に対して確認されると、４６において、ＳＭＳメッセージングモジュール３８が、購入確認と共に消費者携帯電話１２にテキストメッセージを送信する。

システム１０の認可及びキャプチャモードでは、加盟店サーバ１４が、５０において、認可要求を認可管理モジュール３２に送信する。次に、認可管理モジュール３２は、認可要求をキャリアサーバ１８に送信する。認可要求の作用は、キャリアサーバ１８が購入のための資金を用意するが、購入は、キャプチャされるまで完了されることはないことである。

取引はまた、認可された後かつキャプチャされる前に、キャリアサーバ１８においてキャンセルすることができる。消費者が、２８において、購入をキャンセルするよう要求すると、課金管理モジュール２２が、５２において、キャンセル要求を認可管理モジュール３２に送信する。次に、認可管理モジュール３２は、キャンセル要求をキャリアサーバ１８に送信して、購入のために保留しておいた資金を解除する。

消費者が購入をキャンセルしない場合、加盟店は、課金サーバによって返されたａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）を用いて以前の認可を参照して、キャプチャ要求を課金サーバに送信して、認可された資金をキャプチャする（消費者に請求する）。次に、認可管理モジュール３２が、キャリア課金モジュール３６と通信して、キャリア課金モジュールが、請求をキャリアサーバ１８に送信する。請求がキャリアサーバ１８によって確認されると課金サーバ１６に戻り、４６において、ＳＭＳメッセージングモジュール３８が、消費者携帯電話１２に購入確認と共にテキストメッセージを送信する。

課金サーバ１６はさらに、キャリア返金モジュール５４を含む。３０において、消費者が加盟店サーバを通じて以前の購入の返金を要求すると、課金管理モジュール２２が、５６において、返金要求をキャリア返金モジュール５４に送信する。次に、キャリア返金モジュール５４は、返金のためにキャリアサーバ１８と通信を行い、キャリアサーバ１８に対し、キャリアサーバ１８上の消費者携帯電話１２の電話番号に相当する口座に有効に資金を追加させる。キャリア返金モジュール５４は、課金サーバと通信して、返金の成功又は失敗を指示するための通知を加盟店サーバに送信する。

課金サーバ１６は、全てが異なる多数の専用ＵＲＬを含む。統一資源位置指定子（ＵＲＬ）の各々によって、加盟店サーバ１４からの別々のアプリケーションプログラマブルインタフェース（ＡＰＩ）コールを課金サーバ１６に対して行えるようになる。加盟店サーバ１４から課金サーバ１６に対して行われる４２、４４、５０、５２、及び５６での要求の全ては、課金サーバ１６の別個の専用ＵＲＬに対する別個のＡＰＩコールである。図示されていないが、課金サーバ１６は、加盟店サーバ１４による課金サーバ１６への各要求の後に、加盟店サーバ１４に返答する。課金サーバ１６が加盟店サーバ１４と通信する場合、これは、この目的のために加盟店サーバ１４において指定されているＵＲＬを介して行われる。課金サーバ１６はポータル（図示せず）を有し、これは、加盟店サーバ１４の通信事業者が、課金サーバ１６が加盟店サーバ１４と通信するために使用する必要があるコールバックＵＲＬを設定するために使用できる。

図２は、システム１０の動作の２つのモードを示している。６０において、システム１０は、認可方法を実行することによって認可モードで動作する。認可モードにおいて、システム１０は、取引を認可して、実際にこの取引の請求を行うことなく、取引のための資金を用意する。認可モードの間は、取引がキャンセルされる可能性が存在したままである。６２において、システム１０は、キャプチャ方法を作動させて、取引がまだキャンセルされていない場合には、認可された取引を請求としてキャプチャする。

６４において、システム１０は、請求方法を実行することによって、請求モードで動作する。請求方法６４により、結果として取引の請求を行うことができる。オプトイン管理モジュール３４が、オプトインが消費者によって要求されると判定する場合、課金サーバ１６は、請求要求が処理される前に、オプトインを消費者から収集する必要があることを示す応答を加盟店サーバ１４に返す。課金サーバ１６からの応答は、消費者の国及びキャリアに関して要求されるオプトインのタイプを示す。オプトインが、課金サーバ１６のＳＭＳメッセージングモジュール３８から消費者によって受信されるＰＩＮコードの入力を消費者に求める場合、加盟店サーバ１４は、消費者携帯電話１２において消費者からＰＩＮコードを収集して、継続方法を用いてＰＩＮコードを課金サーバ１６に返す必要がある。課金サーバ１６は、ＰＩＮコードの妥当性を確認して、次に、請求要求をキャリアサーバ１８に送信することによって請求要求の完了に進む。

６０及び６２に示す認可及びキャプチャ方法、並びに６４及び６６に示す請求及び継続方法の両方は、結果として請求完了をもたらす。請求は、システム１０が６８において返金方法を実行する場合に無効にすることができる。返金方法６８は、取引金額の全額又は一部返金を可能にする。

認可方法は、消費者からの支払いを認可する。可能である場合、認可コールは、実際の請求ではなく、キャリアサーバ１８にあるユーザの口座からの資金の用意をもたらす必要がある。要求はまた、加盟店サーバ１４の取引に関連付けるためのｅｘｔｅｒｎａｌ−ｉｄ（外部ＩＤ）を含むこともできる。

認可要求は、同期要求である。認可を完了するために要求がキャリアサーバ１８に対して行われている間、要求はブロックする。これは、加盟店サーバ１４が、コンテンツ又はサービスへの消費者アクセスを許可するための手段として認可を用いるという使用事例をサポートするために行われる。認可が成功した場合、加盟店サーバ１４は、コンテンツ又はサービスを提供する。この使用事例では、通常、加盟店サーバ１４によって、指定された期間内に消費者がサービスをキャンセルでき、この場合、加盟店サーバ１４は認可をキャプチャすることはない。それ以外の場合で、消費者がキャンセルしない場合は、加盟店サーバ１４が認可をキャプチャして、消費者に請求を行う。

認可は、課金サーバ１４及びキャリアサーバ１８の両方による限度チェック（支払額及び速度（ｖｅｌｏｃｉｔｙ）を含む。資金を用意する能力及び用意の継続時間は、キャリアサーバ１８ごとに異なることになる。

図３は、認可がキャプチャされてキャプチャ済み取引になる前にキャンセルされる実施例の認可方法を示している。１００において、消費者は、消費者携帯電話１２でコンテンツを選択して加盟店サーバ１４から購入する。消費者はまた、電話による支払いを選択する。１０２において、加盟店サーバ１４は、認可要求を含む認可ＡＰＩコールを、課金サーバ１６の専用認可ＵＲＬに送信する。１０４において、課金サーバ１６は、認可要求をキャリアサーバ１８に送信して、１０６において、認可の結果を加盟店サーバ１４に返す。認可が成功した場合、１０８において、加盟店サーバ１４は、コンテンツへのアクセスを許可する。１１０において、例えば、トライアル期間の終了前に、消費者が取引をキャンセルすると仮定する。その後、加盟店サーバ１４が、認可をキャプチャしない場合、加盟店サーバ１４は、１１２においてキャンセル要求を課金サーバ１６に送信して、未決済の認可をキャンセルする。１１４において、課金サーバ１６は、キャリアサーバ１８に認可のキャンセルを通知する。１１６において、課金サーバ１６は、１１２におけるキャンセル要求に、キャンセル確認で応答する。

課金サーバ１６は、図３の全ての動作後に課金サーバ１６と共にデータ構造を更新する。取引は、１０２の後、認可済みで未キャンセル、未キャプチャと記録される。１１２の後、取引は、キャンセルされたことを反映するために更新される。データ構造は、その後のキャプチャを許可又は却下する。

ｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を入力する必要がある。ｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）は、コーリングシステムからの一意的な取引事象を識別する。加盟店サーバ１４が同じｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を有する２つの要求を送出する場合、両方の要求が同じ応答を加盟店サーバに返す必要がある（両方の要求のデータが同一であると仮定すると）。以前に使用されたｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）が入力され、要求のデータが以前の要求とは異なる場合、課金サーバ１６は、後者の要求に関してエラーを返すことになる。従って、コーリングシステムが、同じｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を用いて同一のデータによる複数のキャプチャ要求を課金サーバ１６に送信する場合、課金サーバ１６は、各要求に対して「キャプチャ成功」で応答するが、資金のキャプチャはただ１度しか行われない。

表１及び２は、１０２の認可要求及び１０６の認可のための要求及び応答パラメータをそれぞれ示している。

表１

表２

通常の認可フローでは、消費者が、加盟店サーバ１４でサービス製品を選択する。加盟店サーバ１４は、電話番号及び随意的にキャリアサーバ１８のＭＮＣ及びＭＣＣを取得する。加盟店サーバ１４は、課金サーバ１６の専用ＵＲＬに認可ＡＰＩコールを行う。認可ＡＰＩコールは、顧客の識別及び購入明細を含む認可要求を課金サーバ１６に提示する。課金サーバ１６は、要求の妥当性確認を行う。要求の妥当性確認に失敗すると、課金サーバ１６は、適切なエラーメッセージを返して、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）は返さない。課金サーバ１６は、支払限度及び速度のチェックを実行する。支払又は速度チェックに失敗するか、又はＭＳＩＳＤＮがブラックリストに載っている場合、認可は失敗し、適切なエラーメッセージが返される。課金サーバ１６は、選択キャリアサーバ１８を判定して（提供されたＭＮＣ／ＭＣＣを用いて又は課金サーバ１６のデータストア内の複数のキャリアサーバから内部検索を実行して）、これらのダイレクトＡＰＩを用いて認可要求をキャリアサーバ１８に提示する。

キャリアサーバ１８が、認可時の請求のみをサポートする場合、認可要求は、認可及びキャプチャとして扱われることになる。課金サーバ１６は、後続のキャプチャ又はキャンセル要求で用いられるａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）を含む認可応答を加盟店サーバ１４に返す。加盟店サーバ１４がｅｘｔｅｒｎａｌ−ｉｄ（外部ＩＤ）を送出している場合、ｅｘｔｅｒｎａｌ−ｉｄ（外部ＩＤ）が、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）と共に保存される。

認可がリトライ可能なエラーを返す場合、加盟店サーバ１４は、認可応答で返される特定のｒｅｔｒｙ−ｄｅｌａｙ（リトライ遅延）の後に、認可要求をリトライする。

キャリアサーバ１８からの応答が、認可不成功だった場合、課金サーバ１６は、認可が失敗して、要求を終了するという指示を返す。課金サーバ１６は、最終取引結果をコールバックで送信する。

取引が認可された場合、課金サーバ１６内で、取引は認可済みであるが未キャプチャとして記録される。キャンセルＡＰＩコールは、以前に認可された顧客からの取引をキャンセルして、キャリアサーバ１８で用意されているあらゆる資金を解放するキャンセル要求を含む。個別の認可及びキャプチャをサポートしない課金システムを有する加盟店サーバの場合、この要求は、参照される認可コールで指定される全額の返金をもたらす必要がある。

表３及び４は、図３の１１２及び１１６のキャンセル信号のための要求及び応答パラメータをそれぞれ示している。

表３

表４

通常のキャンセルフローでは、加盟店サーバ１４が、以前に取得した認可をキャンセルするためにキャンセル要求を提示して、認可のａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）を送出する。課金サーバ１６は、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）の妥当性を確認して、適切なキャリアサーバ１８に対してキャンセルＡＰＩを起動する。次に、課金サーバ１６は、結果コード及びメッセージをキャリアサーバ１８に返し、次に、認可のキャンセルにより取引が終了されたことを示す最終結果コールバックをキャリアサーバ１８に送信する。

図４は、キャプチャされてキャプチャ済み取引になる前に認可がキャンセルされずに、取引がキャプチャされる実施例についての認可方法を示している。キャプチャＡＰＩコールは、顧客からの以前に認可された支払いを確認するキャプチャ要求を含む。キャプチャＡＰＩコールは、顧客の注文が履行され、キャリアサーバ１８にある顧客の口座からの資金の実際のキャプチャを生じるべきであることを示す。キャリアサーバ１８が個別の認可及びキャプチャ動作をサポートしない場合、このコールは助言である。課金サーバ１６は、キャプチャ事象を履行の指示として記録する。

デフォルトの動作は、認可された金額を全額キャプチャすることである。キャプチャが全額又は一部の金額であるかに関わらず、キャプチャ成功は、取引（認可）を終了させる。キャプチャは、認可の制限時間内に行われる必要がある。

１３０において、消費者は、消費者携帯電話１２でコンテンツを選択して加盟店サーバ１４から購入する。消費者はまた、電話による支払いを選択する。１３２において、加盟店サーバ１４は、認可要求を含む認可ＡＰＩコールを、課金サーバ１６の専用認可ＵＲＬに送信する。１３４において、課金サーバ１６は、認可要求をキャリアサーバ１８に送信して、１３６において、認可の結果を加盟店サーバ１４に返し、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）を含める。認可が成功した場合、１３８において、加盟店サーバ１４は、コンテンツへのアクセスを許可する。

１４０において、加盟店サーバ１４は、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）を参照するキャプチャ要求を課金サーバ１６に送信する。１４２において、課金サーバ１６は、認可された取引がキャンセルされたか否かを判定する。取引がキャンセルされていない場合、課金サーバ１６は、取引に進み、課金要求をキャリアサーバ１８に送信するだけである。従って、認可がキャンセルされた場合、キャプチャが拒否されることになる。１４４において、課金サーバ１６は、課金要求をキャリアサーバ１８に送信して、取引を完了してキャリアサーバ１８上の消費者の口座に請求する。１４６において、課金サーバ１６は、確認テキストメッセージを消費者携帯電話１２に送信する。１４８において、課金サーバ１６は、課金結果通知を加盟店サーバ１４に送信する。１５０において、請求が成功した場合、加盟店サーバ１４は、消費者の購入を履行する。

表５及び６は、図４の１４０及び１４８におけるキャプチャ信号のための要求及び応答パラメータをそれぞれ示している。

表５

表６

キャプチャ要求は、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）とは異なるｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）を返す。このａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）により、単一の認可に対する複数のキャプチャが可能になる。以降の返金は、返金される特定のｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）を参照することができる。

認可のタイムアウト又は消費者のオプトインの期限切れによりキャプチャが失敗する場合、課金サーバ１６は、期限切れを示す結果コード及びメッセージを返す。キャプチャ金額が認可の金額を超えることによりキャプチャが失敗する場合は、課金サーバ１６は、超過金額による失敗を示す結果コード及びメッセージを返し、ｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）は返さない。キャプチャは、正しい金額でリトライすることができる。キャプチャ要求がリトライエラーを返す場合、課金サーバ１６は、エラーを示す結果コード及びメッセージを返し、ｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）は返さずに、ｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）をリトライすることができる。

図５は、認可及び請求方法が適切でない場合に、２段階の認可及びキャプチャ取引方法の代わりに使用可能な請求方法を示している。請求は、認可方法と同じリスクチェックを実行する。請求方法はまた、必要に応じて、消費者認証（オプトイン）も実行することになる。課金サーバ１６において、要求が処理のために承認される場合、すなわち、要求が妥当性確認（フィールドの妥当性確認、セキュリティの妥当性確認）をパスして、リスクチェックをパスして、処理のためにキャリアサーバ１８に提示される場合、請求方法要求は、ｃｈａｒｇｅ−ｉｄ（請求ＩＤ）を返すことになる。請求が完了すると、課金サーバ１６は、取引の最終ステータスと共にコールバック通知を加盟店サーバ１４に送信する。課金サーバ１６は、消費者オプトインを請求要求処理の一部として管理することができる。課金サーバ１６は、特定の市場及びキャリアサーバ１８の要件に基づいて、任意の適切な消費者オプトインフローを実行することになる。

図５の請求方法は、消費者携帯電話１２において消費者による移動体発信のオプトインが実行される場合を示している。２００において、消費者は、消費者携帯電話１２でコンテンツを選択して加盟店サーバ１４から購入する。消費者はまた、電話による支払いを選択する。２０２において、加盟店サーバ１４は、課金サーバ１６の専用ＵＲＬに請求ＡＰＩコールを行う。請求ＡＰＩコールは、請求要求を課金サーバ１６に送信する。

オプトインが要求される市場又はキャリアサーバ１８の場合、２０４において、課金サーバ１６は、請求要求をキャリアサーバ１８に送信する。課金サーバ１６が、請求に関してオプトインが要求されると判定すると、２０６において、課金サーバ１６は、オプトインが要求されるという通知を加盟店サーバ１４に送信して、２０８において、「Ｙ」と応答するための指示と共にテキストメッセージを消費者携帯電話１２に送信する。加盟店サーバ１４は、ユーザインタフェース２０を介して、消費者に対して、ＳＭＳメッセージを送信しており、特定のキーワードで応答する必要があることを表示する。２１０において、消費者は、要求されたキーワードを含む返信テキストメッセージを課金サーバ１６に送信する。課金サーバ１６は、キーワードの妥当性確認を行って、２１２において、確認テキストメッセージを消費者携帯電話１２に送信する。２１４において、課金サーバ１６は、請求要求をキャリアサーバ１８に送信して、２１６において、課金結果通知を加盟店サーバ１４に送信する。２１８において、加盟店サーバ１４は、ユーザインタフェース２０を介して、消費者に対して、請求が成功して購入を履行する、という確認を表示する。

２０６で送信される通知は、加盟店サーバ１４によって表示されるキーワードを含む。キーワードは、課金サーバ１６によって生成される一意のキーワードである。２１０で受信するキーワードは、２０６で送信されたキーワードに対して妥当性確認されて、比較が好ましい場合に取引は継続する。

図６は、消費者携帯電話１２において消費者によるＰＩＮコードオプトインが実行される場合の請求方法を示している。図５及び６では、同様の取引に関して同様の参照数字を使用する。２００において、消費者は、コンテンツを選択して加盟店サーバ１４から購入する。消費者はまた、電話による支払いを選択する。２０２において、加盟店サーバ１４は、請求要求を課金サーバ１６に送信する。

オプトインが消費者によって要求されない場合、２０４において、課金サーバは、請求要求をキャリアサーバ１８に送信する。課金サーバ１６が、請求に関してオプトインが要求されると判定すると、２０６において、課金サーバ１６は、オプトインが要求されるという確認を加盟店サーバ１４に送信して、２２６において、ＰＩＮコードと共にテキストメッセージを消費者携帯電話１２に送信する。２２８において、消費者は消費者携帯電話１２で、加盟店サーバ１４によって提供されるユーザインタフェース２０にＰＩＮコードを入力する。２３０において、加盟店サーバ１４は、消費者によって入力されたＰＩＮコードと共に継続要求を課金サーバ１６に送信する。課金サーバ１６は、ＰＩＮコードの妥当性確認を行って、２１２において、確認テキストメッセージを消費者携帯電話１２に送信する。２１４において、課金サーバ１６は、請求要求をキャリアサーバ１８に送信して、２１６において、課金結果通知を加盟店サーバ１４に送信する。２１８において、加盟店サーバ１４は、請求が成功して、購入を履行するという確認を消費者に対して表示する。

２２６で送信されるテキストメッセージは、課金サーバ１６によって生成される固有のＰＩＮコードを含む。２３０で受信するＰＩＮコードが、２２６で送信したＰＩＮコードに対して妥当性確認されて、比較が好ましい場合にだけ取引は継続する。

表７は、図５及び６の２０２における請求要求の要求パラメータを、表８は、図５及び６の２１６における通知の応答パラメータを示している。

表７

表８

通常の認可フローでは、消費者は、加盟店サーバ１４でサービス製品を選択する。加盟店サーバ１４は、電話番号及び任意でキャリアサーバ１８のＭＮＣ及びＭＣＣを取得する。加盟店サーバ１４は、課金サーバ１６の専用ＵＲＬに認可ＡＰＩコールを行う。認可ＡＰＩコールは、顧客の識別及び購入明細を含む認可要求を課金サーバ１６に提示する。課金サーバ１６は、要求の妥当性確認を行う。要求の妥当性確認に失敗すると、課金サーバ１６は、適切なエラーメッセージを返して、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（認可ＩＤ）は返さない。課金サーバ１６は、支払限度及び速度のチェックを実行する。支払又は速度チェックに失敗するか、又はＭＳＩＳＤＮがブラックリストに載っている場合、認可は失敗し、適切なエラーメッセージが返される。課金サーバ１６は、選択キャリアサーバ１８を判定して（送出されたＭＮＣ／ＭＣＣを用いて又は課金サーバ１６のデータストア内の複数のキャリアサーバから内部検索を実行して）、これらのダイレクトＡＰＩを用いて認可要求をキャリアサーバ１８に提示する。

図５及び６から分かるように、継続動作は、消費者のオプトインを待つ請求要求を継続する。請求が、図５の移動体発信のオプトイン（キーワードでの応答）又は図６のようなＰＩＮコード（電話に送信され、加盟店インタフェースで顧客により入力される）のいずれかを通じて付加的なオプトインを顧客から取得する必要があることを示す場合に、継続コールが使用される。

ＰＩＮコード入力の場合、図１のユーザインタフェース２０は、自己の電話に送信されたＰＩＮコードを入力するよう消費者に指示する必要がある。入力されたＰＩＮコードは、継続コールで課金サーバ１６に送信される。このコールからの加盟店サーバ１４への返送成功により、請求要求を継続することができる。どちらのタイプのオプトインでも、取引が完了すると、正常な請求要求処理ごとに、課金サーバ１６は、コールバック通知を加盟店サーバ１４に送信することになる。

加盟店サーバ１４は、キーワードによる応答を必要とする消費者オプトインのためにポーリング手法を使用するよう選択することができる。この場合、加盟店サーバ１４は、消費者の応答が成功するか否かを判定するために反復ベースで（ポーリング）継続要求を送出する。

消費者オプトインを要求する請求は、請求が完了していないことを指示する消費者確認保留（Ｃｏｎｓｕｍｅｒ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｐｅｎｄｉｎｇ）状態に置かれる。消費者が所定の時間内にオプトインしない場合、取引は時間切れとなり、最終の失敗状態に置かれる。課金サーバ１６は、取引の最終状態を伝達するコールバックを加盟店サーバ１４に送信する。

表９及び１０は、加盟店サーバ１４と課金サーバ１６との間の継続要求のための要求及び応答パラメータを示している。

表９

表１０

返金は、図３を参照して説明したキャプチャされた支払いの後に又は図５及び６を参照して説明した請求方法の後のいずれかに処理することができる。図７は、図３のキャプチャ方法後に返金が処理される方法を示している。

３００において、消費者は消費者携帯電話１２で、図１のユーザインタフェース２０を介して加盟店サーバ１４に返金を要求する。３０２において、加盟店サーバ１４は、取引識別子として機能するｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）を含めることによって特定の請求を参照する、返金要求を課金サーバ１６に送信する。課金サーバ１６は、返金コールから同じ選択キャリアサーバ１８を決定して、３０４において、返金要求をキャリアサーバ１８に送信する。返金要求は、返金対象の元の取引の金額、又は一部返金の場合はそれよりも少ない金額を含む。３０６において、課金サーバ１６は、チャージバックの結果及び金額を示すチャージバック通知を加盟店サーバ１４に送信する。３０８において、加盟店サーバ１４は、購入を無効にして、加盟店サーバ１４上のユーザの口座を更新して返金を反映する。

表１１及び１２は、３０２の返金要求及びチャージバック３０６の要求及び応答パラメータをそれぞれ示している。返金が、請求方法に応答している場合、ｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）の代わりにｃｈａｒｇｅ−ｉｄ（請求ＩＤ）となる。

表１１

表１２

３０２で受信した返金要求は、理由コードを含む。課金サーバ１６は、理由コードが妥当な理由コードであるかどうかを判定して、妥当な理由コードがある場合にのみ返金を処理する。次に、課金サーバ１６は、ｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）を用いて、元の請求、及び元の請求が処理された特定のキャリアサーバ１８を判定する。

無効な理由コードが提供される又は理由コードが提供されないために返金が失敗する場合、課金サーバ１６は、ｒｅｆｕｎｄ−ｉｄ（返金ＩＤ）を返さず、結果コード及び結果メッセージを返すだけである。同様に、返金額が、参照された取引の金額を超えるために返金が失敗する場合、課金サーバ１６は、ｒｅｆｕｎｄ−ｉｄ（返金ＩＤ）を返さず、結果コード及び結果メッセージを返すだけである。加盟店サーバ１４によって一部返金が要求される場合、課金サーバ１６は、一部金額の返金を取得して、ｒｅｆｕｎｄ−ｉｄ（返金ＩＤ）を返すが、このｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）に対してそれ以上の返金を取得することはできない。

上述のように、課金サーバ１６は、特定の市場及びキャリアサーバ１８の要件によって要求される、消費者認証（オプトイン）を実行する。課金サーバ１６が管理する消費者オプトインは、請求要求のためにのみ提供される。課金サーバ１６がオプトインを管理する場合、課金サーバ１６は、加盟店サーバ１４からの請求要求に対して、支払いの消費者オプトインが要求されることを指示する応答を提供することになる。消費者オプトインには、ＰＩＮベース及びキーワードによる応答という２つの形態がある。市場及びキャリアサーバ１８に基づいて、課金サーバ１６は、必要なオプトインのタイプを提供することになる。ＰＩＮコードベースのオプトインの場合、加盟店サーバ１４が提供するＰＩＮ入力フォームに消費者がＰＩＮを入力すると、加盟店サーバ１４は、継続要求を使用して継続することになる（ＰＩＮコードを送出することによって）。

課金サーバ１６はまた、加盟店サーバ１４が消費者の固有の識別子をこれらの電話番号と一緒に送出する場合、自動認証をサポートすることができる。この場合、課金サーバ１６は、設定可能な期間中に、消費者に関して消費者認証が以前に処理されたか否かをチェックすることになる。処理されていた場合、課金サーバ１６は、以前の認証を受諾することができ、消費者を再度認証する必要はない。

以下の方法、すなわち、認可、キャプチャ、キャンセル、請求、及び返金は、冪等性をサポートする。冪等方法がコーリングされる場合、複数のコールが行われても、動作は一度だけ実行される。同じｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）に関して２つの請求要求が行われる場合、口座にはただ１度だけ請求されて、両方の要求が同じ応答を取得する。成功した場合、全てのコールが、予期される成功応答を返すことになるが、実際の請求は一度しか行われない。冪等方法に対する全てのコールが、ｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）パラメータ内に固有の値を含む必要がある。

課金サーバ１６ＡＰＩは、同期要求及び非同期要求の両方を含む。認可要求は、同期要求である。認可を完了するために要求がキャリアサーバ１８に対して行われている間、要求はブロックする。同期認可は、ユーザがアプリケーション又はコンテンツへのアクセスを待っている間に、応答を提供する必要性を共有する多くの使用事例をサポートする。

キャプチャ及び請求は、非同期要求である。これらの要求は、課金サーバ１６によって受信されて処理され、課金サーバ１６は、要求が承認されたか否かを示す即時応答を提供する。承認された要求は、要求がうまく処理されたことを示すための応答を返し、応答コード及びメッセージは、取引が進行中であることを示すことになる。成功又は失敗に関わらず、取引の処理が終了すると、課金サーバ１６は、取引処理明細と共にコールバック通知を加盟店サーバ１４に送信することになる。

課金サーバ１６は、指定された発行元ＵＲＬ（「コールバックＵＲＬ」）にハイパーテキスト転送プロトコル（ＨＴＴＰ）ＰＯＳＴ要求を送信して、取引状態情報を伝達する。コールバック通知は、非同期である。加盟店サーバ１４は、課金サーバ１６の発行元ポータルを用いて自己のコールバックＵＲＬを設定することができる。コールバック通知は、請求及びキャプチャ要求の完了（成功又は失敗）がある非同期取引、及びキャリアサーバ１８から受信した各返金済みの取引に関する通知を受信するキャリア起因の返金のような、特定の使用事例に関して必要となる場合がある。

図８は、消費者携帯電話１２を示すブロック図であり、便宜上タッチ感知式ディスプレイ１１２０又は「タッチスクリーン」を示している。消費者携帯電話１２は、メモリ１０２０（１又はそれ以上のコンピュータ可読ストレージ媒体を含むことができる）と、メモリコントローラ１２２０と、１又はそれ以上の処理ユニット（ＣＰＵ）１２００と、周辺インタフェース１１８０と、ＲＦ回路構成１０８０と、オーディオ回路構成１１００と、スピーカ１１１０と、マイクロフォン１１３０と、入出力（Ｉ／Ｏ）サブシステム１０６０と、他の入力又は制御デバイス１１６０と、外部ポート１２４０とを含む。これらの構成要素は、１又はそれ以上の通信バス又は信号線１０３０上で通信を行う。

図８に示す種々の構成要素は、ハードウェア、ソフトウェア、或いは１又はそれ以上の信号処理及び／又は特定用途向け集積回路を含むハードウェアとソフトウェアの組合せで実施することができる。

メモリ１０２０は、高速ランダムアクセスメモリを含むことができ、１又はそれ以上の磁気ディスクストレージデバイス、フラッシュメモリデバイス、又は他の不揮発性固体メモリデバイスのような不揮発性メモリを含むこともできる。ＣＰＵ１２００及び周辺インタフェース１１８０のような、消費者携帯電話１２の他の構成要素によるメモリ１０２０へのアクセスは、メモリコントローラ１２２０によって制御される。

周辺インタフェース１１８０は、デバイスの入出力周辺機器をＣＰＵ１２００及びメモリ１０２０に接続する。１又はそれ以上のプロセッサ１２００は、メモリ１０２０内に格納された種々のソフトウェアプログラム及び／又は命令セットを実行又は実施して、消費者携帯電話１２の種々の機能を実行して、データを処理する。

ＲＦ（無線周波数）回路構成１０８０は、電磁信号とも呼ばれるＲＦ信号を送受信する。ＲＦ回路構成１０８０は、電気信号と電磁信号との間の変換を行い、電磁信号を介して通信ネットワーク及び他の通信デバイスと通信する。ＲＦ回路構成１０８０は、アンテナシステム、ＲＦトランシーバ、１又はそれ以上の増幅器、チューナ、１又はそれ以上の発振器、デジタルシグナルプロセッサ、ＣＯＤＥＣチップセット、加入者識別モジュール（ＳＩＭ）カード、メモリ、及びその他を含む、これらの機能を実行するための公知の回路構成を含む。ＲＦ回路構成１０８０は、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）とも呼ばれるインターネット、イントラネットのようなネットワーク、及び／又はセルラー電話ネットワーク、無線ローカルエリアネットワーク（ＬＡＮ）及び／又はメトロポリタン・エリア・ネットワーク（ＭＡＮ）のような無線ネットワーク、及び他のデバイスと無線通信によって通信することができる。無線通信は、当該技術で公知の複数の通信規格、プロトコル、及び技術のいずれかを用いることができる。

オーディオ回路構成１１００、スピーカ１１１０、及びマイクロフォン１１３０は、ユーザと消費者携帯電話１２との間のオーディオインタフェースを提供する。オーディオ回路構成１１００は、周辺インタフェース１１８０からオーディオデータを受信して、オーディオデータを電気信号に変換して、電気信号をスピーカ１１１０に送る。スピーカ１１１０は、電気信号を人間の可聴音波に変換する。オーディオ回路構成１１００はまた、音波からマイクロフォン１１３０によって変換された電気信号も受信する。オーディオ回路構成１１００は、電気信号をオーディオデータに変換して、オーディオデータを処理のために周辺インタフェース１１８０に送信する。また、オーディオ回路構成１１００は、オーディオ回路構成１１００と取り外し可能なオーディオ入出力周辺機器、例えば、出力のみのヘッドフォン、又は出力（例えば、片耳又は両耳用のヘッドフォン）及び入力（例えば、マイクロフォン）の両方を備えたヘッドセット等との間のインタフェースとして機能するヘッドフォンジャックも含む。

Ｉ／Ｏサブシステム１０６０は、タッチスクリーン１１２０及び他の入力／制御デバイス１１６０のような消費者携帯電話１２上の入出力周辺機器を周辺インタフェース１１８０に接続する。Ｉ／Ｏサブシステム１０６０は、他の入力又は制御デバイスのためのディスプレイコントローラ１５６０及び１又はそれ以上の入力コントローラ１６００を含む。１又はそれ以上の入力コントローラ１６００は、他の入力又は制御デバイス１１６０との間で電気信号を送受信する。他の入力／制御デバイス１１６０は、物理的なボタン（例えば、プッシュボタン、ロッカーボタン）、ダイアル、スライダースイッチ、ジョイスティック、クリックホイール、及びインタフェースの一部分を形成するものとして機能するその他の全てを含むことができる。入力コントローラ１６００は、キーボード、赤外線ポート、ＵＳＢポート、及びマウスのようなポインタデバイスのいずれかに接続することができる。１又はそれ以上のボタンは、スピーカ１１１０及び／又はマイクロフォン１１３０の音量制御のためのアップ／ダウンボタンを含むことができる。１又はそれ以上のボタンは、プッシュボタンを含むことができる。プッシュボタンの素早く押すことで、タッチスクリーンのロックを解除すること、又はデバイスのロックを解除するためにタッチスクリーン上でジェスチャーを用いる処理を開始することができる。プッシュボタンの長押しによって、消費者携帯電話１２の電源をオン又はオフに切り替えることができる。タッチスクリーン１１２０は、仮想ボタン又はソフトボタン、及び１又はそれ以上のソフトキーボードを実装するために使用される。

タッチ感知式タッチスクリーン１１２０は、デバイスとユーザとの間の入力インタフェース及び出力インタフェースを提供する。ディスプレイコントローラ１５６０は、タッチスクリーン１１２０との間で電気信号の送受信を行う。タッチスクリーン１１２０は、視覚的な出力をユーザに表示する。視覚的な出力は、グラフィックス、テキスト、アイコン、ビデオ、及びこれらのいずれかの組合せ（まとめて「グラフィックス」と呼ぶ）を含むことができる。一部の実施形態では、視覚的な出力の一部又は全ては、ユーザインタフェースオブジェクトに対応することができ、これの更なる詳細については、以下で説明する。

タッチスクリーン１１２０は、触覚及び／又は触知性の接触に基づいてユーザから入力を受け取るタッチ感知式表面、センサ、又は一連のセンサを有する。タッチスクリーン１１２０及びディスプレイコントローラ１５６０（これと共にメモリ１０２０内のいずれかの関連するモジュール及び／又は命令セット）は、タッチスクリーン１１２０上の接触（及びいずれかの動き又は接触の途切れ）を検出して、検出した接触を、タッチスクリーン上に表示されるユーザインタフェースオブジェクト（例えば、１又はそれ以上のソフトキー、アイコン、ウェブページ、又は画像）との対話に変換する。例示的な実施形態において、タッチスクリーン１１２０とユーザとの間の接触点が、ユーザの指に対応する。

タッチスクリーン１１２０は、ＬＣＤ（液晶ディスプレイ）技術又はＬＰＤ（発行ポリマーディスプレイ）技術を使用することができるが、他の実施形態では、他のディスプレイ技術を使用することができる。タッチスクリーン１１２０及びディスプレイコントローラ１５６０は、現在公知の又は今後開発される複数の接触感知技術のいずれかを用いて接触及び何らかの動き又は動きの中断を検出することができ、本技術は、限定されるものではないが、容量性、抵抗性、赤外線、及び表面弾性波技術、並びに他の近接センサアレイ又はタッチスクリーン１１２０との１又はそれ以上の接触点を判定するための他の素子を含む。

ユーザは、スタイラス、指、及びその他のような任意の適切な物体又は付属物を用いて、タッチスクリーン１１２０との接触を行うことができる。一部の実施形態では、ユーザインタフェースは、指ベースの接触及びジェスチャーで主に機能するよう設計されており、これは、タッチスクリーン上の指の接触の範囲がより大きいために、スタイラスベースの入力よりも精度が大幅に下がる。一部の実施形態では、デバイスは、大まかな指ベースの入力を、正確なポインタ／カーソル位置又はユーザによって所望される動作を実行するためのコマンドに変換する。

消費者携帯電話１２はまた、種々の構成要素に電力供給するための電力システム１６２０も含む。電力システム１６２０は、電力管理システム、１又はそれ以上の電源（例えば、バッテリー、交流（ＡＣ））、充電システム、電力障害検出回路、電力コンバータ又はインバータ、電力ステータスインジケータ（例えば、発光ダイオード（ＬＥＤ））、及び携帯用デバイスにおける電力の生成、管理、及び分配に関連するいずれかの他の構成要素を含むことができる。

メモリ１０２０に格納されたソフトウェア構成要素は、オペレーティングシステム１２６０、通信モジュール（又は命令セット）１２８０、接触／動きモジュール（又は命令セット）１３００、グラフィックスモジュール（又は命令セット）１３２０、テキスト入力モジュール（又は命令セット）１３４０、及びアプリケーション（又は命令セット）１３６０を含む。

オペレーティングシステム１２６０（例えば、Ｄａｒｗｉｎ、ＲＴＸＣ、ＬＩＮＵＸ（登録商標）、ＵＮＩＸ（登録商標）、ＯＳ Ｘ、ＷＩＮＤＯＷＳ（登録商標）、又はＶｘＷｏｒｋｓのような組み込み型のオペレーティングシステム）は、一般的なシステムタスク（例えば、メモリ管理、ストレージデバイス制御、電力管理、その他）を制御して管理するためのソフトウェア構成要素及び／又はドライバを含み、種々のハードウェアとソフトウェア構成要素との間の通信を円滑にする。

通信モジュール１２８０は、１又はそれ以上の外部ポート１２４０上での他のデバイスとの通信を円滑にして、ＲＦ回路構成１０８０及び／又は外部ポート１２４０によって受信されるデータを処理するための種々のソフトウェア構成要素も含む。外部ポート１２４０（例えば、ユニバーサル・シリアル・バス（ＵＳＢ）、ＦＩＲＥＷＩＲＥ、その他）は、他のデバイスに直接、又はネットワーク（例えば、インターネット、無線ＬＡＮ、その他）上で間接的に接続するように構成される。

接触／動きモジュール１３００は、タッチスクリーン１１２０（ディスプレイコントローラ１５６０と連動して）及び他のタッチ感知式デバイス（例えば、タッチパッド又は物理的なクリックホイール）との接触を検出することができる。接触／動きモジュール１３００は、接触が行われたか否かを判定する、接触の動きがあったか否かを判定してタッチスクリーン１１２０を横切る動きの追跡する、及び接触が途切れたか（すなわち、接触が停止したか）否かを判定する等の、接触の検出に関連する様々な動作を実行するための種々のソフトウェア構成要素を含む。接触点の動きを判定する段階は、接触点の速度（大きさ）、速さ（大きさ及び方向）、及び／又は加速度（大きさ及び／又は方向の変化）を判定する段階を含むことができる。これらの動作は、単一接触（例えば、１つの指による接触）に、又は複数の同時接触（例えば、「マルチタッチ」／複数の指による接触）に適用することができる。接触／動きモジュール１３００及びディスプレイコントローラ１５６０はまた、タッチパッド上の接触も検出する。

グラフィックスモジュール１３２０は、タッチスクリーン１１２０上にグラフィックスをレンダリングして表示するための種々の公知のソフトウェア構成要素を含み、表示されるグラフィックスの明度を変えるための構成要素を含む。本明細書で用いる場合、用語「グラフィックス」は、ユーザに表示することができるあらゆるオブジェクトを含み、テキスト、ウェブページ、アイコン（ソフトキーを含むユーザインタフェースオブジェクトなど）、デジタル画像、ビデオ、アニメーション、及び同様のものを含む。

グラフィックスモジュール１３２０の構成要素とすることができるテキスト入力モジュール１３４０は、様々なアプリケーション（例えば、連絡先、電子メール、ＩＭ、ブログ、ブラウザ、及びテキスト入力が必要な任意の他のアプリケーション）でテキストを入力するためのソフトキーボードを提供する。アプリケーション１３６０は、モバイルアプリケーション２０８を含むことができる。

図９は、本明細書で開示する方法論のいずれか１つ又はそれ以上をマシンに実行させるための命令セットをその中で実行可能なコンピュータシステム９００の例示的な形態のマシンの概略図を示している。代替的実施形態において、マシンは、独立型デバイスとして動作すること、又は他のマシンに接続（例えば、ネットワーク接続）することができる。ネットワーク配置において、マシンは、サーバ−クライアントネットワーク環境ではサーバ又はクライアントマシンとして、或いはピアツーピア（又は分散）ネットワーク環境ではピアマシンとして動作することができる。マシンは、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、携帯情報端末（ＰＤＡ）、携帯電話、ウェブアプライアンス、ネットワークルータ、スイッチ又はブリッジ、或いはそのマシンによって行われるべき動作を指定する命令セット（シーケンシャル又はそれ以外）を実行する能力がある任意のマシンとすることができる。さらに、ただ１つのマシンのみを図示しているが、用語「マシン」は、本明細書で説明する方法論のいずれか１つ又はそれ以上を実行するための命令セット（又は複数セット）を個別に又は共同で実行する任意のマシン集合も含むととらえるべきである。

例示的なコンピュータシステム９００は、プロセッサ９３０（例えば、中央処理ユニット（ＣＰＵ））、グラフィックス処理ユニット（ＧＰＵ）、又はその両方）と、メインメモリ９３２（例えば、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリ、同期ＤＲＡＭ（ＳＤＲＡＭ）又はＲａｍｂｕｓ ＤＲＡＭ（ＲＤＲＡＭ）、その他のようなダイナミックランダムアクセスメモリ（ＤＲＡＭ））と、スタティックメモリ９３４（例えば、フラッシュメモリ、スタティックランダムアクセスメモリ（ＳＲＡＭ、その他））とを含み、これらはバス９３６を介して相互に通信するよう構成される。

コンピュータシステム９００は、ビデオディスプレイ９３８（例えば、液晶ディスプレイ（ＬＣＤ）又はブラウン管（ＣＲＴ））をさらに含むことができる。コンピュータシステム９００はまた、英数字入力デバイス９４０（例えば、キーボード）と、カーソル制御デバイス９４２（例えば、マウス）と、ディスクドライブユニット９４４と、信号発生装置９４６（例えば、スピーカ）と、ネットワークインタフェースデバイス９４８とを含むこともできる。

ディスクドライブユニット９４４は、本明細書で説明する方法論又は機能のうちのいずれか１つ又はそれ以上を具現化する１又はそれ以上の命令セット９５２（例えば、ソフトウェア）が格納されたマシン可読媒体９５０を含む。ソフトウェアはまた、完全に又は少なくとも部分的に、メインメモリ９３２内及び／又はプロセッサ９３０内に、コンピュータシステム９００によるこの命令の実行中に常駐することもでき、メモリ９３２及びプロセッサ９３０が、マシン可読媒体を構成することもできる。ソフトウェアはさらに、ネットワークインタフェースデバイス９４８を介してネットワーク９５４上で送受信することができる。

例示的な実施形態では、命令９５２が単一の媒体上にあるように示しているが、用語「マシン可読媒体」は、１又はそれ以上の命令セットを格納する単一媒体又は複数媒体（例えば、集中又は分散データベース又はデータストア、及び／又は関連するキャッシュ及びサーバ）であると理解するよう解釈すべきである。用語「マシン可読媒体」はまた、マシンによって実行するための命令セットを格納し、エンコードし、又は保持する能力があり、本明細書の方法論のいずれか１つ又はそれ以上をマシンに実行させるいずれかの媒体を含むと解釈すべきである。従って、用語「マシン可読媒体」は、限定されるものではないが、固体メモリ、光学及び磁気媒体を含むと解釈すべきである。

特定の例示的な実施形態について説明して添付図面に示してきたが、このような実施形態は、例証にすぎず、本発明を限定するものではないこと、並びに、当業者であれば修正例を想定することができるので、本発明は、図示して説明した特定の構成及び配置に限定されないことを理解されたい。

１２ 消費者携帯電話
１４ 加盟店サーバ
１６ 課金サーバ
１８ キャリアサーバ
２００ 消費者がコンテンツを選択
２０２ 請求（ＭＳＩＳＤＮ、ｃｏｕｎｔｒｙ、ａｍｏｕｎｔ）
２０４ 請求要求
２０６ 請求応答（オプトインが要求される）
２０８ 消費者オプトインＳＭＳ（購入するためには「Ｙ」と応答）
２１０ 消費者が「Ｙ」と応答
２１２ 請求確認ＳＭＳ
２１４ 請求要求
２１６ 課金サーバが課金結果通知を加盟店に送信
２１８ 加盟店が消費者の購入を履行

Claims (40)

1. 請求を処理する方法であって、
   課金サーバにより、ＭＳＩＳＤＮ及び金額を含む請求ＡＰＩコールを加盟店サーバから受信する段階と、
   前記課金サーバにより、複数のキャリアサーバから選択キャリアサーバを判定する段階と、
   前記課金サーバにより、前記ＭＳＩＳＤＮ及び金額を含む請求要求を前記選択キャリアサーバに送信する段階と、
   前記課金サーバにより、前記請求要求の承認又は失敗の指示を含む請求結果コールバック通知を前記加盟店サーバに返す段階と、を含む
   ことを特徴とする方法。
2. 前記請求ＡＰＩコールは、前記課金サーバのＵＲＬで受信される
   ことを特徴とする請求項１に記載の方法。
3. 前記請求ＡＰＩコールは、前記加盟店サーバによって送出されるｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を含み、前記請求結果は、前記ｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を含む
   ことを特徴とする請求項１に記載の方法。
4. 前記請求ＡＰＩコールは、ｍｅｒｃｈａｎｔ−ｉｄ（課金サーバが割り当てる加盟店ＩＤ）、ｃｏｎｓｕｍｅｒ−ｉｐ−ａｄｄｒｅｓｓ（発信側消費者のＩＰアドレス）、ｓｅｒｖｉｃｅ−ｉｄ（加盟店サーバ提供のＩＤ）、ｃｏｕｎｔｒｙ（国名コード）、ｃｕｒｒｅｎｃｙ（通貨コード）、ｉｔｅｍ−ｄｅｓｃｒｉｐｔｉｏｎ（購入される商品の説明）、及びｒｅｑｕｅｓｔ−ｉｄ（加盟店サーバが割り当てる要求ＩＤ。固有であることが必要）を備える
   ことを特徴とする請求項１に記載の方法。
5. 前記選択キャリアサーバは、キャリアの名前、ｍｃｃ（モバイル国別コード）及びｍｎｃ（モバイルネットワークコード）のうちの少なくとも１つを含む前記請求ＡＰＩコールから検出される
   ことを特徴とする請求項１に記載の方法。
6. 前記請求結果コールバック通知は、ｃｈａｒｇｅ−ｉｄ（課金サーバが割り当てる請求ＩＤ）、ｒｅｓｕｌｔ−ｃｏｄｅ（この要求の前記結果）、ｒｅｓｕｌｔ−ｍｅｓｓａｇｅ（前記結果の説明）を含む
   ことを特徴とする請求項１に記載の方法。
7. 前記請求結果コールバック通知は、前記加盟店サーバのＵＲＬに送出される
   ことを特徴とする請求項１に記載の方法。
8. 前記請求要求は、ｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を含み、前記請求要求が失敗すると、前記方法は、
   前記課金サーバが前記請求要求の失敗、ＭＳＩＳＤＮ、及び金額の同じ指示を返さないように、新規のｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を有する請求ＡＰＩコールを、前記課金サーバにより前記加盟店サーバから受信する段階と、
   前記新規のｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）を有する前記請求ＡＰＩコールで受信した前記ＭＳＩＳＤＮ及び金額を含む請求要求を、前記課金サーバにより前記選択キャリアサーバに送信する段階と、
   前記新規のｒｅｑｕｅｓｔ−ｉｄ（要求ＩＤ）に基づいて前記請求要求の承認又は失敗の指示を含む請求結果コールバック通知を、前記課金サーバにより前記加盟店サーバに返す段階と、をさらに含む
   ことを特徴とする請求項１に記載の方法。
9. 前記請求ＡＰＩコールに応答して、前記課金サーバにより、ＰＩＮコードの形式の消費者オプトインが要求されることを示す応答を前記加盟店サーバに返す段階と、
   前記課金サーバにより、前記ＭＳＩＳＤＮの消費者電話にテキストメッセージを送信する段階と、
   ＰＩＮコードを含む継続要求を前記加盟店サーバから前記課金サーバにおいて受信する段階と、
   前記課金サーバにより、前記継続要求で受信した前記ＰＩＮコードを、前記テキストメッセージで送信した前記ＰＩＮコードに対して妥当性確認を行って、前記継続要求の前記ＰＩＮコードの妥当性確認成功の後にのみ、前記キャリアサーバへの前記請求要求が送信される段階と、をさらに含む
   ことを特徴とする請求項１に記載の方法。
10. 前記請求ＡＰＩコールに応答して、前記課金サーバにより、キーワードの形式の消費者オプトインが要求されること指示すると共に前記キーワードを含む応答を、前記加盟店サーバに返す段階と、
    前記課金サーバにより、キーワードの形式の応答が要求されることを指示するテキストメッセージを前記ＭＳＩＳＤＮの消費者電話に送信する段階と、
    キーワードを含むテキストメッセージを前記消費者携帯電話から前記課金サーバにおいて受信する段階と、
    前記テキストメッセージで受信した前記キーワードを、前記加盟店サーバへの前記応答の前記キーワードに対して妥当性確認を行って、前記テキストメッセージ内の前記キーワードの妥当性確認成功の後にのみ、前記キャリアサーバへの前記請求要求が送信される段階と、をさらに含む
    ことを特徴とする請求項１に記載の方法。
11. 前記課金サーバにより、前記加盟店サーバから返金コールを受信する段階と、
    前記課金サーバにより、前記返金コールに応答して、前記選択キャリアサーバを判定する段階と、
    前記加盟店サーバからの前記返金コールに応答して、前記課金サーバにより、金額を含む返金要求を前記選択キャリアに送信する段階と、
    前記加盟店サーバからの前記返金コールに応答して、前記課金サーバにより、チャージバック通知を前記加盟店サーバに送信する段階と、をさらに含む
    ことを特徴とする請求項１に記載の方法。
12. 前記請求結果コールバック通知は、ｃｈａｒｇｅ−ｉｄ（請求ＩＤ）を有し、前記返金コールは、前記請求結果コールバック通知の前記ｃｈａｒｇｅ−ｉｄ（請求ＩＤ）を有する
    ことを特徴とする請求項１１に記載の方法。
13. 前記課金サーバにより、前記返金コールに有効な理由コードが含まれているか否かを判定する段階をさらに含み、前記返金要求が送信されるのは、前記返金コールに有効な理由コードが含まれている場合だけである
    ことを特徴とする請求項１１に記載の方法。
14. 前記返金コールは、ｍｅｒｃｈａｎｔ−ｉｄ（課金サーバが割り当てる加盟店ＩＤ）、ｃｈａｒｇｅ−ｉｄ（返金するための前記支払いの請求ＩＤ）、ｒｅａｓｏｎ−ｃｏｄｅ（課金サーバの理由コード）、及びｒｅｑｕｅｓｔ−ｉｄ（加盟店サーバが割り当てる要求ＩＤ。固有であることが必要）を含む
    ことを特徴とする請求項１１に記載の方法。
15. 前記チャージバック通知は、ｒｅｆｕｎｄ−ｉｄ（課金サーバが作成する返金取引のＩＤ）、ｒｅｓｕｌｔ−ｃｏｄｅ（この要求の前記結果）、及びｒｅｓｕｌｔ−ｍｅｓｓａｇｅ（前記結果の説明）を含む
    ことを特徴とする請求項１１に記載の方法。
16. コンピュータのプロセッサによって実行される場合に請求を処理する方法を実行する命令セットをその上に格納させた、非一時的コンピュータ可読媒体であって、本方法は、
    課金サーバにより、ＭＳＩＳＤＮ及び金額を含む請求ＡＰＩコールを加盟店サーバから受信する段階と、
    前記課金サーバにより、複数のキャリアサーバから選択キャリアサーバを判定する段階と、
    前記課金サーバにより、前記ＭＳＩＳＤＮ及び金額を含む請求要求を前記選択キャリアサーバに送信する段階と、
    前記課金サーバにより、前記請求要求の承認又は失敗の指示を含む請求結果コールバック通知を前記加盟店サーバに返す段階と、を含む
    ことを特徴とする非一時的コンピュータ可読媒体。
17. 課金コンピュータシステムであって、
    プロセッサと、
    前記プロセッサに接続されたコンピュータ可読媒体と、
    前記コンピュータ可読媒体上の命令セットと、を含み、
    ＭＳＩＳＤＮ及び金額を含む請求ＡＰＩコールを加盟店サーバから受信し、複数のキャリアサーバから選択キャリアサーバを判定し、前記ＭＳＩＳＤＮ及び金額を含む請求要求を前記選択キャリアサーバに送信し、前記請求要求の承認又は失敗の指示を含む請求結果コールバック通知を前記加盟店サーバに返すために、前記プロセッサにより実行可能なキャリア課金モジュールを含む
    ことを特徴とする課金コンピュータシステム。
18. 前記命令セットが、
    消費者オプトインを格納するオプトイン管理モジュールと、
    前記オプトイン管理モジュールに接続されたＳＭＳメッセージングモジュールと、
    をさらに含み、
    前記キャリア課金モジュールは、前記請求ＡＰＩコールに応答して、ＰＩＮコードの形式の消費者オプトインが要求されることを示す応答を前記加盟店サーバに返し、前記ＳＭＳメッセージングモジュールは、前記ＭＳＩＳＤＮの消費者携帯電話にテキストメッセージを送信し、前記キャリア課金モジュールは、ＰＩＮコードを含む継続要求を前記加盟店サーバから受信し、前記継続要求で受信した前記ＰＩＮコードを、前記テキストメッセージで送信した前記ＰＩＮコードに対して妥当性確認を行って、前記継続要求の前記ＰＩＮコードの妥当性確認成功の後にのみ、前記キャリアサーバへの前記請求要求が送信される
    ことを特徴とする請求項１７に記載の課金コンピュータシステム。
19. 前記命令セットが、
    オプトイン管理モジュールと、
    前記オプトイン管理モジュールに接続されたＳＭＳメッセージングモジュールと、
    をさらに含み、
    前記キャリア課金モジュールは、前記請求ＡＰＩコールに応答して、キーワードの形式の消費者オプトインが要求されることを指示すると共に前記キーワードを含む応答を、前記加盟店サーバに返し、前記ＳＭＳメッセージングモジュールは、キーワードの形式の応答が要求されることを示すテキストメッセージを前記ＭＳＩＳＤＮの消費者電話に送信し、前記テキストメッセージを含むメッセージを前記消費者携帯電話から受信し、前記キャリア課金モジュールは、前記テキストメッセージで受信した前記キーワードを、前記加盟店サーバへの前記応答の前記キーワードに対して妥当性確認を行って前記テキストメッセージ内の前記キーワードの妥当性確認成功の後にのみ、前記キャリアサーバへの前記請求要求が送信される
    ことを特徴とする請求項１７に記載の課金コンピュータシステム。
20. 前記加盟店サーバから返金コールを受信して、前記返金コールに応答して、前記選択キャリアサーバを判定して、前記加盟店サーバからの前記返金コールに応答して、金額を含む返金要求を前記選択キャリアに送信して、前記加盟店サーバからの前記返金コールに応答して、チャージバック通知を前記加盟店サーバに送信するキャリア返金モジュールをさらに含む
    ことを特徴とする請求項１７に記載の課金コンピュータシステム。
21. 課金サーバにより、ＭＳＩＳＤＮ及び金額を含む認可要求を含む認可ＡＰＩコールを加盟店サーバから受信する段階と、
    前記課金サーバにより、複数のキャリアサーバから選択キャリアサーバを判定する段階と、
    前記課金サーバにより、前記金額に基づいて認可要求を前記選択キャリアサーバに送信する段階と、
    前記課金サーバにより、前記認可要求に基づいて認可された取引を記録する段階と、
    前記課金サーバにより、前記認可要求を前記選択キャリアサーバに送信後、キャプチャ要求を含むキャプチャＡＰＩコールを受信する段階と、
    前記課金サーバにより、前記キャプチャ要求に応答して、前記認可要求後かつ前記キャプチャ要求前に前記加盟店サーバからキャンセル要求を受信しており、前記キャプチャ取引がキャンセルされたか否かを判定する段階と、
    前記キャプチャされた取引がキャンセルされていない場合は、前記課金サーバにより、前記キャプチャ要求に応答して、課金要求を前記選択キャリアサーバに送信するが、前記キャプチャされた取引がキャンセルされた場合には送信しない段階と、を含む
    ことを特徴とする方法。
22. 前記認可ＡＰＩコール及びキャプチャＡＰＩコールは、前記課金サーバにある少なくとも１つのＵＲＬで受信される
    ことを特徴とする請求項２１に記載の方法。
23. 前記認可ＡＰＩコール及び前記キャプチャＡＰＩコールは、前記課金サーバにある異なるＵＲＬで受信される
    ことを特徴とする請求項２１に記載の方法。
24. 前記選択キャリアサーバは、キャリア名、ｍｃｃ（モバイル国名コード）、ｍｎｃ（モバイルネットワークコード）のうちの少なくとも１つを含む前記認可ＡＰＩコールから検出される
    ことを特徴とする請求項２１に記載の方法。
25. 前記認可ＡＰＩコールは、ｍｅｒｃｈａｎｔ−ｉｄ（課金サーバが割り当てる加盟店ＩＤ）、ｃｏｎｓｕｍｅｒ−ｉｐ−ａｄｄｒｅｓｓ（発信側消費者のＩＰアドレス）、ｓｅｒｖｉｃｅ−ｉｄ（加盟店サーバ提供のＩＤ）、ｃｏｕｎｔｒｙ（国名コード）、ｃｕｒｒｅｎｃｙ（通貨コード）、ｉｔｅｍ−ｄｅｓｃｒｉｐｔｉｏｎ（購入される商品の説明）、及びｒｅｑｕｅｓｔ−ｉｄ（加盟店サーバが割り当てる要求ＩＤ。固有であることが必要）を含む
    ことを特徴とする請求項２１に記載の方法。
26. 前記課金サーバにより、前記認可要求を前記選択キャリアサーバに送信後で、前記キャプチャ要求の受信前に、認可応答を前記加盟店サーバに送信する段階をさらに含む
    ことを特徴とする請求項２１に記載の方法。
27. 前記認可応答は、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（課金サーバが割り当てる認可ＩＤ）、ｒｅｓｕｌｔ−ｃｏｄｅ（この要求の前記結果）、及びｒｅｓｕｌｔ ｍｅｓｓａｇｅ（前記結果の説明）を含む
    ことを特徴とする請求項２６に記載の方法。
28. 前記キャプチャ要求は、ｍｅｒｃｈａｎｔ−ｉｄ（課金サーバが割り当てる加盟店ＩＤ）、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（課金サーバが割り当てる認可ＩＤ）、及びｒｅｑｕｅｓｔ−ｉｄ（加盟店サーバが割り当てる要求ＩＤ。固有であることが必要）を含む
    ことを特徴とする請求項２１に記載の方法。
29. 前記課金サーバにより、前記課金要求の前記選択キャリアサーバへの送信後、キャプチャ応答通知を前記加盟店サーバに送信する段階をさらに含む
    ことを特徴とする請求項２１に記載の方法。
30. 前記キャプチャ応答は、ｃａｐｔｕｒｅ−ｉｄ（このキャプチャ要求の一意のＩＤ）、ｒｅｓｕｌｔ−ｃｏｄｅ（この要求の前記結果）、及びｒｅｓｕｌｔ ｍｅｓｓａｇｅ（前記結果の説明）を含む
    ことを特徴とする請求項２９に記載の方法。
31. 前記課金サーバにより、前記加盟店サーバからキャンセル要求を受信する段階と、
    前記課金サーバにより、前記課金要求の送信を許可しないために、前記キャプチャされた取引をキャンセルする段階と、
    前記課金サーバにより、前記キャプチャされた取引の前記キャンセル後にキャンセル応答を前記加盟店サーバに送信する段階と、をさらに含む
    ことを特徴とする請求項２１に記載の方法。
32. 前記キャンセル要求は、ｍｅｒｃｈａｎｔ−ｉｄ（課金サーバが割り当てる加盟店ＩＤ）、ａｕｔｈｏｒｉｚａｔｉｏｎ−ｉｄ（課金サーバが割り当てる認可ＩＤ）、及びｒｅｑｕｅｓｔ−ｉｄ（加盟店サーバが割り当てる要求ＩＤ）を含む
    ことを特徴とする請求項３１に記載の方法。
33. 前記キャンセル応答は、ｒｅｓｕｌｔ−ｃｏｄｅ（この要求の前記結果）、及びｒｅｓｕｌｔ ｍｅｓｓａｇｅ（前記結果の説明）を含む
    ことを特徴とする請求項３２に記載の方法。
34. 前記課金サーバにより、前記加盟店サーバから返金コールを受信する段階と、
    前記課金サーバにより、前記返金コールに応答して、前記選択キャリアサーバを判定する段階と、
    前記加盟店サーバからの前記返金コールに応答して、前記課金サーバにより、金額を含む返金要求を前記選択キャリアに送信する段階と、
    前記加盟店サーバからの前記返金コールに応答して、前記課金サーバにより、チャージバック通知を前記加盟店サーバに送信する段階と、をさらに含む
    ことを特徴とする請求項２１に記載の方法。
35. 前記請求結果コールバック通知は、ｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）を有し、前記返金コールは、前記請求結果コールバック通知の前記ｃａｐｔｕｒｅ−ｉｄ（キャプチャＩＤ）を有する
    ことを特徴とする請求項３４に記載の方法。
36. 前記返金コールに有効な理由コードが含まれているか否かを判定する段階をさらに含み、前記返金要求が送信されるのは、前記返金コールに有効な理由コードが含まれている場合だけである
    ことを特徴とする請求項３４に記載の方法。
37. 前記返金コールは、ｍｅｒｃｈａｎｔ−ｉｄ（課金サーバが割り当てる加盟店ＩＤ）、ｃａｐｔｕｒｅ−ｉｄ（返金するための前記支払いのキャプチャＩＤ）、ｒｅａｓｏｎ−ｃｏｄｅ（課金サーバの理由コード）、及びｒｅｑｕｅｓｔ−ｉｄ（加盟店サーバが割り当てる要求ＩＤ）を含む
    ことを特徴とする請求項３４に記載の方法。
38. 前記チャージバック通知は、ｒｅｆｕｎｄ−ｉｄ（課金サーバが作成する返金取引のＩＤ）、ｒｅｓｕｌｔ−ｃｏｄｅ（この要求の前記結果）、及びｒｅｓｕｌｔ−ｍｅｓｓａｇｅ（前記結果の説明）を含む
    ことを特徴とする請求項３４に記載の方法。
39. コンピュータのプロセッサによって実行される場合に請求を処理する方法を実行する命令セットをその上に格納させた、非一時的コンピュータ可読媒体であって、本方法は、
    課金サーバにより、ＭＳＩＳＤＮ及び金額を含む認可要求を含む認可ＡＰＩコールを加盟店サーバから受信する段階と、
    前記課金サーバにより、複数のキャリアサーバから選択キャリアサーバを判定する段階と、
    前記課金サーバにより、前記金額に基づいて認可要求を前記選択キャリアサーバに送信する段階と、
    前記課金サーバにより、前記認可要求に基づいて認可された取引を記録する段階と、
    前記課金サーバにより、前記認可要求を前記選択キャリアサーバに送信後、キャプチャ要求を含むキャプチャＡＰＩコールを受信する段階と、
    前記課金サーバにより、前記キャプチャ要求に応答して、前記認可要求後かつ前記キャプチャ要求前に前記加盟店サーバからキャンセル要求を受信していて、前記キャプチャ取引がキャンセルされたか否かを判定する段階と、
    前記キャプチャされた取引がキャンセルされていない場合は、前記課金サーバにより、前記キャプチャ要求に応答して、課金要求を前記選択キャリアサーバに送信するが、前記キャプチャされた取引がキャンセルされた場合には送信しない段階と、を含む
    ことを特徴とする非一時的コンピュータ可読媒体。
40. 課金コンピュータシステムであって、
    プロセッサと、
    前記プロセッサに接続されたコンピュータ可読媒体と、
    前記コンピュータ可読媒体上の命令セットと、
    を含み、
    前記命令セットは、
    消費者認可を格納する認可管理モジュールと、
    前記認可管理モジュールに接続されて前記プロセッサによって実行可能なキャリア課金モジュールと、
    を含み、ＭＳＩＳＤＮ及び金額を含む認可要求を含む認可ＡＰＩコールを加盟店サーバから受信し、複数のキャリアサーバから選択キャリアサーバを判定し、前記金額に基づいて認可要求を前記選択キャリアサーバに送信し、前記認可要求に基づいて認可された取引を記録し、前記認可要求を前記選択キャリアサーバに送信後、キャプチャ要求を含むキャプチャＡＰＩコールを受信し、前記キャプチャ要求に応答して、前記認可要求後かつ前記キャプチャ要求前に前記加盟店サーバからキャンセル要求を受信しており、前記キャプチャ取引がキャンセルされたか否かを判定し、前記キャプチャされた取引がキャンセルされていない場合は、前記キャプチャ要求に応答して、課金要求を前記選択キャリアサーバに送信するが、前記キャプチャされた取引がキャンセルされた場合には送信しない
    ことを特徴とする課金コンピュータシステム。

Images