JP6901181B1 - 決済方法及びプログラム - Google Patents

Abstract

【課題】クレジットカード決済等のキャッシュレス決済の確実性、情報セキュリティ、信用を維持しつつ決済の仲介を実現するできる決済方法及びプログラムを提供する。【解決手段】事業者装置が他の装置との間で決済を仲介する方法であって、顧客に対してユニークに割り当てられた電話番号と、課金を識別する第１の識別情報に関連付けられた課金の情報とを、顧客装置１０２から受け取るＳ１２２と、第１の識別情報と課金情報から決済処理を特定し第１の識別情報と、取引相手携帯端末１０４の電話番号に宛てた通信において伝達された第２の識別情報とを比較した比較結果に基づいて、顧客装置１０２に、決済処理を実行させるメッセージを送信するＳ１３２と、を有する。【選択図】図１

Description

本発明は、決済方法及びプログラムに関する。

クレジットカード決済、キャッシュレス決済など、現金が用いられない決済手段が利用される場合には、クレジットカードの情報、キャッシュレス決済に関する情報が不正に利用されないようにすることが重要である。

例えば、クレジットカードの番号などの情報が店舗のシステム内に保存されてしまうと、この保存された情報は、クレジットカードの不正使用などの利用につながる危険性があることが指摘されている。このため、店舗などでは、クレジットカードの番号などの情報が店舗のシステム内に記憶されることを避けると共に、決済会社が提供する専用のハードウエア機器を準備して、この専用のハードウエアによりクレジットカードを読み取らせることで、決済を行わせるようにしている場合がある。

例えば、ＰＯＳシステムによって（または、顧客のモバイル機器によって）一意の一回限りのデジタルコードであって、上記取引を識別するデジタルコードを生成するステップと、上記の一意の一回限りのデジタルコードとともに取引データを、第１デジタルネットワーク経路を介して、ＰＯＳシステムのオーナーの銀行へ送信するステップと、上記の一意の一回限りのデジタルコードおよび上記モバイル機器により発行された課金情報を、第２デジタルネットワーク経路を介して、上記銀行へ並行して送信するステップと、銀行によって（または支払システム／取引ネットワークによって）、ＰＯＳシステムからの取引データとモバイル機器によって発行された課金情報とをマージし、上記マージが成功した場合、上記取引を決済するステップとを有し、マージは、上記コードが合致した場合、常に成功する。このように、銀行は、当該銀行でマージされた、異なる経路を介して、上記取引が承認されたことを通知される技術が存在する（例えば、特許文献１参照）。

また、他の例では、利用者によるクレジットカード決済の要求に基づいて、前記利用者の携帯端末にＳＭＳにおけるショートメッセージを送信する情報管理サーバであって、決済情報を入力させる画面のＵＲＬを取得する識別情報取得部と、前記識別情報取得部で取得した前記ＵＲＬを前記ショートメッセージに付加する識別情報付加部と、前記ＵＲＬを付加した前記ショートメッセージを前記利用者の前記携帯端末に送信する送信部と、を備えている。前記情報管理サーバは、サービス提供事業者の情報端末から利用者情報とサービスに必要な情報とを受信し、前記利用者情報と前記サービスに必要な情報とを組み合わせて第１の情報を生成する制御部を有し、制御部は、前記情報端末から前記利用者情報と前記サービスに必要な情報とを受信して前記第１の情報を生成する度に、前記情報端末が有する個人情報ＤＢから前記携帯端末の電話番号を抽出して前記携帯端末にショートメッセージを送信し、前記画面には、前記利用者情報及び前記サービスに必要な情報が表示される技術が存在する（例えば、特許文献２参照）。

このような従来の技術では、取引相手の機密情報を保護しつつ、取引相手の本人確認を行うために、専用のハードウエアを用意したり、予め取引相手の本人確認を行うための情報をデータベースに格納するシステムを準備するなどの高度なシステムを導入したりすることが必要とされていた。例えば、小規模の店舗、出先の営業スタッフがクレジットカードの決済などを行う場合においても、専用のクレジットカード処理のための機器を準備することが必要であった。

また、クレジットカード以外によるキャッシュレス決済であっても、取引相手は、専用のアプリケーションを自己の携帯端末に予めインストールして事前にクレジットカードを登録するか事前に金銭のチャージ又はオートチャージの設定をするなどして、そのアプリケーションの決済の仕組みが使えるように、そのアプリケーションを使用するために要求される事前準備が必要であった。

また、例えば、ＳＭＳ又はメールなどにより金銭の支払いを要求するメッセージが突然送られてきた場合には、そのメッセージの信頼性に関して、利用者に疑問を抱かせる場合も発生していた。

特許第６０８５０３７号公報 特許第６４３１３７７号公報

開示の技術は、クレジットカード決済等のキャッシュレス決済のセキュリティ、完全性、信用を維持しつつ決済の仲介を実現することができる環境を提供することを目的としている。

開示の技術は、顧客から前記顧客の取引相手への課金の決済処理を仲介する方法であって、前記顧客に対してユニークに割り当てられた電話番号が準備されており、前記課金を識別する第１の識別情報に関連付けられた前記課金の情報を、前記顧客の管理する装置から受け取るステップと、前記第１の識別情報と、前記課金の情報とを含む情報から、決済処理を特定するステップと、前記第１の識別情報と、前記取引相手の管理する携帯端末から前記電話番号に宛てた通信において伝達された第２の識別情報とを比較した比較結果に基づいて、前記顧客の管理する装置に、前記決済処理を実行させるメッセージを送信するステップと、を有する決済を仲介する方法を提供する。
また、開示の技術は、上記方法をコンピュータに実行させるプログラムを提供する。

開示の技術によれば、クレジットカード決済等のキャッシュレス決済のセキュリティ、完全性、信用を維持しつつ決済の仲介を実現する環境を提供することができる。

図１Ａは、顧客に対してユニークな電話番号を割り当てる手順を示す図である。図１Ｂは、事業者装置が他の装置との間で決済の仲介を行うシーケンスの概略を示す図である。 図２Ａは、各装置の情報交換の概要を示す図である。図２Ｂは、事業者装置のハードウエア構成を示す図である。 図３は、事業者装置における決済サービス生成処理フローの概略を示す図である。 図４は、事業者装置における電話着信処理フローの概略を示す図である。 図５は、取引相手携帯端末管理テーブルのエントリ無効化処理の概略を示す図である。 図６は、取引相手携帯端末へのメッセージ送信処理の概要のフローを示す図である。 図７は、事業者装置の機能ブロック図である。 図８は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。 図９は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。 図１０は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。 図１１は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。 図１２は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。 図１３Ａ及び図１３Ｂは、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。図１３Ｃは、取引相手携帯端末に表示された不正な画面の例である。 図１４は、顧客の各々に対応して予め割り当てられた受信用の電話番号を管理する電話番号割当テーブルの例を示す図である。 図１５は、決済サービス管理テーブルの例を示す図である。 図１６は、取引相手携帯端末管理テーブルの例を示す図である。

以下、図面を参照しながら実施の形態について説明する。
本明細書では、以下の用語を用いる。
事業者とは、事業者の顧客が、顧客の取引相手との間で取り交わされた契約に基づく決済を仲介する者を言う。事業者は、クレジットカード会社など実質的にキャッシュレス決済を実行する会社（決済業者）との間に入って決済業者に決済を依頼する企業である。

顧客及び事業者は、顧客の取引相手が管理するクレジットカード番号、キャッシュレス決済の情報など、決済において特定の者以外が取り扱うことがセキュリティ上望ましくない秘密とされることが求められる情報を扱わない者である。
決済業者は、取引相手のクレジットカードの情報又はキャッシュレス決済の情報など、決済において特定の者以外が取り扱うことがセキュリティ上望ましくない秘密とされることが求められる情報を扱うことができる者である。

また、顧客の管理下にある装置を顧客装置と言い、取引相手の管理下にある装置を取引相手携帯端末と言い、事業者の管理下にある装置を事業者装置と言い、決済業者の管理下にある装置を決済業者装置と言う。

以下に示す実施の形態における方法の各ステップは、矛盾の無い限り順番を入れ換えて実行されてもよい。また、複数のステップが同時に実行されてもよい。各ステップは、メモリに記憶されたプログラムを実行することにより実現されてもよい。また各ステップの一部は、オペレーティングシステム或いはハードウエアにより実現されてもよい。また、各ステップが全て実行される必要はなく、特定のステップの実行が省略されてもよい。また、１つのステップが複数回実行されてもよい。また、複数のステップが、繰り返し実行されてもよい。各ステップは排他的なものではなく、矛盾の無い限り組み合わせることができる。

開示の方法をコンピュータに実行させるプログラムは、非一時的（non-transitory）な記憶媒体に格納され得る。非一時的なメモリとしては、ＲＡＭ，ＲＯＭ、ＵＳＢメモリ、ＤＶＤなどが挙げられるが、これらに限定されるものではない。プログラムの一部は、リエントラントなかたちで実行されてもよい。プログラムは、複数の処理対象の各々に対応した複数の相互に独立に処理されるタスクによって実質的に同時に実行されてもよい。
また、各実施形態は、ハードウエアの装置としてインプリメントされ得る。

すなわち、請求項に記載された方法又はプログラムの順序とは異なる順序で実行される技術、或いは一部の処理が同時に実行される技術も、当該請求項に規定された発明の技術的範囲に属することは言うまでもない。
図１Ａは、顧客に対してユニークな電話番号を割り当てる手順を示す図である。事業者は、事業者の顧客に対して、ユニークな電話番号を割り当てる。

この電話番号は、以下のようにして利用される。例えば、顧客と、顧客に割り当てられた電話番号とを関連づけて、事業者の管理する装置の記憶部の電話番号割当テーブル（図１４）に記憶しておく。図１４に、この電話番号割当テーブルの具体例を示す。

顧客は、顧客にユニークに割り当てられた電話番号を顧客の取引相手に伝達する。そして、取引相手は、取引相手の管理する取引相手携帯端末１０４を用いて、顧客にユニークに割り当てられた電話番号に電話をかけることで、事業者装置１０６は、取引相手携帯端末１０４を操作する取引相手が、いずれの顧客との間で取引を行っているのかを把握することができる。電話は、音声通話であってもよいし、電話番号を宛先としたメッセージ通信等であってもよい。
すなわち、事業者は、掛かってきた電話の電話番号（発信先電話番号）で、上記の電話番号割当テーブルを検索することによって、取引相手携帯端末１０４がいずれの顧客に対する取引相手の管理する取引相手携帯端末１０４であるかを特定することができる。
加えて、事業者は、掛かってきた電話の発信元電話番号から、取引相手の管理する取引相手携帯端末１０４の電話番号を知ることができる。したがって、事業者装置１０６は、発信元電話番号に対して通信を行うことで、取引相手携帯端末１０４との間で、確実な情報交換を実現することができる。

なお、割り当てられる電話番号は、顧客に対して１つの電話番号が割り当てられてもよいし、顧客の支店毎（又は、営業担当者毎など）に異なる電話番号が割り当られてもよい。顧客の支店毎（又は、営業担当者毎など）に異なる電話番号が割り当られている場合には、取引相手携帯端末１０４が、いずれの顧客の支店（又は、営業担当者毎など）に対する取引相手の管理する取引相手携帯端末１０４であるのかを知ることができる。

図１Ｂは、事業者装置１０６が他の装置と間で決済の仲介を行うシーケンスの概略を示す図である。図１Ｂは、シーケンスの概略を示すものであるため、上下に隣接するシーケンスの間に他のシーケンスが入ってもよい。また、矛盾の無い限り、シーケンスの順番が入れ替わってもよい。また、１つのシーケンスが、時系列的に実行される双方向の複数の情報伝達のシーケンスを含んでもよい。

以下に示す実施形態では、顧客と顧客の取引相手とが契約を取り交わし、顧客が取引相手から、所定の金額の料金を請求する場合（課金する場合）を想定している。課金を決済する処理を決済サービスと呼ぶ。取引相手携帯端末１０４と決済業者装置１０８とは、クレジットカード、キャシュレス決済などの決済サービスに利用される秘密の情報をやり取りすることができる。

このような秘密の情報は、顧客装置１０２及び事業者装置１０６には伝達されないようにされる。このようにすることによって、クレジットカード決済又はキャッシュレス決済などの決済サービスに利用される秘密の情報の漏洩を防止することができる。

図１Ｂのシーケンスは、顧客が管理する顧客装置１０２、顧客の取引相手が管理する取引相手携帯端末１０４、事業者が管理する事業者装置１０６及び決済業者が管理する決済業者装置１０８における処理のシーケンスの時間的順序を上から下に記載している。

図２Ａは、各装置の情報交換の概要を示す図である。顧客装置１０２と取引相手携帯端末１０４とは、インターネットなどのネットワーク、ブルートゥース（登録商標）などの近距離無線通信又は光通信（例えば、画面・紙媒体などに表示されたＱＲコード（登録商標）などとこのＱＲコード（登録商標）を撮像するカメラなどの光学系の読取装置との間の通信）などで電子的に情報の交換がなされてもよい。なお、顧客装置１０２と取引相手携帯端末１０４との識別情報などの伝達及びその情報の共有は、上記のような電子的な情報交換により共有される形、又は顧客装置１０２又は取引相手携帯端末１０４のいずれか又は双方の操作者によるキー入力などを受け取る形で実現されてもよい。後者の場合には、識別情報の共有は、ネットワークなどの電子的な情報交換のメカニズムを利用しない形（口頭による伝達、紙媒体に書かれた情報がキー入力されるなど）で実現され得る。

顧客装置１０２と事業者装置１０６とは、通信経路１０２ａを介して接続されている。また、取引相手携帯端末１０４と事業者装置１０６とは、通信経路１０４ａを介して接続されている。取引相手携帯端末１０４と決済業者装置１０８とは、通信経路１０４ｂを介して接続されている。
顧客装置１０２及び取引相手携帯端末１０４には、事業者装置１０６が管理するウェブサイトを閲覧するブラウザなどの汎用の通信ソフトウエアがインストールされていることが望ましい。したがって、顧客装置１０２及び取引相手携帯端末１０４は、事業者装置１０６との接続に際して、接続のための専用のハードウエアを用意したり、汎用のブラウザ以外の専用のソフトウエアをインストールしたりすることは必ずしも必須ではない。
このようにすることによって、顧客装置１０２と取引相手携帯端末１０４は、一般的なセキュリティ機能を有するブラウザソフトウエアがインストールされた汎用的なＰＣ又は携帯端末などの装置で実現され得る。このため、顧客装置１０２及び取引相手携帯端末１０４は、事業者装置１０６との情報交換に関して専用のハードウエアを準備したり又は専用のソフトウエアを予めインストールしたりする手間が省けることとなる。
なお、本実施形態は、所定のハードウエアを予め用意したり又は所定のソフトウエアを予めインストールしたりすることを本実施形態の対象外とするものではない。

事業者装置１０６と決済業者装置１０８との間の通信１０６ａは、あらかじめ定められたセキュアな通信方式で接続されていることが望ましい。事業者装置１０６から決済業者装置１０８には、顧客から取引相手に請求する課金情報と、その課金に関する管理情報を含む情報が伝達される。そして、決済業者装置１０８から事業者装置１０６に例えば管理情報に対応させて決済の結果が報告される。

取引相手携帯端末１０４と決済業者装置１０８との間の通信１０４ｂは、決済業者があらかじめ定めた接続方式で接続され、クレジットカードの番号などの決済に必要な秘密の情報が伝達され得る。取引相手携帯端末１０４と決済業者装置１０８とのセキュアな通信１０４ｂは、顧客装置１０２及び事業者装置１０６が関与しない通信である。このため、顧客装置１０２及び事業者装置１０６は、クレジットカードの情報又はキャッシュレス決済に関する情報など、決済において秘密とされる情報を取り扱う必要がない。したがって、取引相手携帯端末１０４は、決済業者装置１０８との間で、秘密裡にクレジットカードの情報などの決済に必要な秘密情報の授受を安全に行うことができる。決済の結果は、決済業者装置１０８から取引相手携帯端末１０４にも伝達される。

図１Ｂに戻る。
顧客装置１０２と取引相手携帯端末１０４とは、識別情報の共有がなされる。識別情報とは、顧客と取引相手との契約に基づき顧客から取引相手へ課金される決済サービスを事業者装置１０６が特定するために用いられる情報である。

既に述べたように、顧客装置１０２と事業者装置１０６とは、通信経路１０２ａを介して接続されている。また、取引相手携帯端末１０４と事業者装置１０６とは、通信経路１０４ａを介して接続されている。すなわち、事業者装置１０６は、顧客装置１０２が扱う識別情報と、取引相手携帯端末１０４が扱う識別情報とを手掛かりに、通信経路１０２ａと通信経路１０４ａとの別個の通信において、同一の決済サービスを関連付けることができる。

本明細書では、顧客装置１０２が扱う識別情報を第１の識別情報と称する場合がある。また、取引相手携帯端末１０４が扱う識別情報を第２の識別情報と称する場合がある。これらの第１の識別情報と第２の識別情報とが一致していれば、顧客装置１０２が扱う決済サービスと、取引相手携帯端末１０４が扱う決済サービスとが同じ決済サービスであることがわかる（或いは、同じ決済サービスである可能性が非常に高いことがわかる。）なお、ここで、「同じ決済サービスである可能性が非常に高い」ということは、顧客装置１０２が扱う決済サービスＡと取引相手携帯端末１０４が扱う決済サービスＢとが同一の決済サービスとして関連付けられてしまう意図しない事象の発生の可能性がゼロではないことを意味する。

このような意図しない事象の発生は、何らかの人為的ミス、不正行為、通信上のエラー、意図的なネット上の攻撃、識別情報の偶然の一致などで発生する可能性があるということである。したがって、意図しない事象が発生する前に、これを検知し未然に防止するための確実性の担保を図ることが重要である。このような確実性の担保の観点からの実施形態のバリエーションの選択については、この実施形態が利用者にとって使いやすいものか否かの観点、フィッシングの防止の観点、スパムメッセージの拡散防止の観点、不正行為を行う者からのサイト攻撃の防止の観点などの多角的な観点から選択することが望ましい。その説明の詳細は個々の実施形態の構成のバリエーションに付随して説明する。

図１Ｂのシーケンスを例にして以下に説明する。
顧客装置１０２の操作者と取引相手とが契約を結び、顧客から取引相手に課金する場合を想定する。そして、この場合に、顧客装置１０２及び事業者装置１０６がクレジットカード、キャッシュレス決済などの秘密にされるべき情報に関与することなく、取引相手携帯端末１０４と決済業者装置１０８との間での決済サービスを完結させることを実現するシーケンスの例が以下に記載されている。

以下の例では、まず、取引相手携帯端末１０４の携帯電話番号の下４桁を識別情報に用いる例を取り上げる。なお、識別情報は、携帯電話番号の下４桁に限られるものではない、上述のように確実性を考慮した場合には、その他の識別情報が用いられてもよい。
なお例えば、取引相手携帯端末１０４の電話番号の全てを識別情報に用いる場合には、取引相手は、顧客装置を操作する顧客に、取引相手携帯端末１０４の電話番号の全てを伝えることになる。取引相手が、電話番号を顧客に開示したくない場合もあることを想定すると、携帯電話番号の全てを識別情報に用いることが妥当でない実施形態（例えば、携帯電話の電話番号を秘匿したい場合）では、識別情報に、電話番号の一部（例えば、取引相手携帯端末１０４の携帯電話番号の下４桁）を用いることが望ましい。なお、この場合には、電話番号の一部が一致する複数の取引相手携帯端末１０４から電話がかかってきた場合には、識別情報を手掛かりに、顧客装置１０２からの決済サービスを適切な取引相手携帯端末１０４と関連付けることができないことを防止する処理が必要となる。この処理については、後述する。
また、識別情報のその他の例については、実施形態の構成に関するそれぞれの変形例の説明の際において説明する。

顧客装置１０２はログインＩＤ及びパスワードなどを用いて、事業者装置１０６とセキュアに接続されていることを前提とする。したがって、事業者装置１０６は、顧客装置１０２からの情報を受け取ると、どの顧客装置１０２から伝達された情報であるかを特定することができる。加えて、事業者装置１０６は、適切な顧客装置１０２に適切な情報を送信することができる。

顧客装置１０２を操作する顧客は、取引相手携帯端末１０４を操作する取引相手から、たとえば取引相手携帯端末１０４の携帯電話番号の下４桁を、口頭により、あるいは紙媒体、画面の表示などにて伝えられ得る。（なお、携帯電話の下４桁の伝達は、これらに限られるものではなく、各種の通信、ＱＲコード（登録商標）などの画像を読み取ることで伝達されてもよい。）

シーケンスＳ１２２で、顧客装置１０２の操作者は、伝えられた下４桁を顧客装置１０２に入力すると共に、課金額を入力して、識別情報の下４桁及び課金額を事業者装置１０６に伝達する。

事業者装置１０６は、シーケンスＳ１２２により伝達された、課金額、顧客装置１０２の情報に対して、個別の決済サービスを割り当てるように、この決済サービスに固有の管理情報を付与することが望ましい。この管理情報によって、この決済サービスを識別することができる。このようにすることによって、決済サービスが管理情報により特定されて、以後の処理が行われるようにすることができる。

また、この管理情報は、シーケンスＳ１２２で、事業者装置１０６から顧客装置１０２に伝達されることが望ましい。顧客装置１０２の操作者は、管理情報を特定することにより、事業者装置１０６において取り扱われる課金に関する決済サービスを特定することができるようになる。

シーケンスＳ１２４で、取引相手携帯端末１０４は、顧客に対しユニークに割り当てられた電話番号に宛てた通信をすること（例えば電話をかけること）により、事業者装置１０６に通信することで、第２の識別情報である取引相手携帯端末１０４の下４桁の電話番号を事業者装置１０６に伝えることができる。この通信は、音声電話であってもよいしメッセージ通信などであってもよい。

顧客にユニークに割り当てられた電話番号（発信先電話番号）は、顧客から取引者に口頭にて伝えるか、顧客装置１０２の画面又は紙などの媒体を介して電話番号を取引相手に示すことで、取引相手に伝達されてもよい。あるいは、発信先電話番号の情報が含まれたＱＲコード（登録商標）を取引相手携帯端末１０４が読み取ることで、発信先電話番号が、取引相手携帯端末１０４に伝達されてもよい。あるいは、インターネット又はブルートゥース（登録商標）などの近距離無線通信によって、発信先電話番号が、取引相手携帯端末１０４に伝達されてもよい。取引相手は、取引相手携帯端末１０４を用いて、発信先電話番号宛に音声通話又はＳＭＳなどのメッセージによる発信を行えばよい。

なお、電話番号は、数字で構成されている。このため、メールアドレスなどのように数字以外にアルファベットなどの文字が含まれるアドレスよりも、口頭又は紙媒体などによる伝達によっても、伝達される情報に誤りが生じる可能性が少ないという利点がある。事業者装置１０６は、取引相手携帯端末１０４からの音声電話の着呼または、メッセージ通信の受信に伴って、発信元電話番号を抽出することにより、識別情報である下４桁の番号を知ることができる。したがって、取引相手携帯端末１０４の発信元番号の一部である下４桁の電話番号が識別情報として用いられる場合には、取引相手は、取引相手携帯端末１０４に識別情報を入力しなくてもよい。このことは、識別情報に取引相手携帯端末１０４の発信元番号の一部又は全部が識別情報に用いられるときに当てはまる。

なお、取引相手携帯端末１０４の下４桁の電話番号が識別情報に用いられる場合には、たまたま、複数の決済サービスで、同じ番号が用いられる可能性、あるいは、複数の取引相手携帯端末の発信元電話番号の下４桁が一致する可能性が存在する。すなわち、顧客に対する複数の取引相手携帯端末１０４の下４桁の電話番号が偶然一致する場合があり得る。したがって、取引相手携帯端末１０４の電話番号の下４桁よりも多くの桁数の番号又はすべての桁を識別情報に用いるようにしてもよい。
携帯電話番号は、携帯電話にユニークに付与される番号であるから、取引相手携帯端末１０４のすべての桁を識別情報として用いることで、決済サービスを一意に特定することができる。なお、この場合には、顧客と取引相手が、同時に複数の決済サービスを利用しないことが前提となる。通常、買い物をするとき又はサービスを受けるときに、同じ取引相手により、同時に複数の決済サービスが利用されること（顧客から取引相手に複数の別個の課金の事象が発生すること）は事実上あり得ない事象であるから、全ての桁の携帯電話番号を識別情報に用いることとすれば、決済サービスを一意に特定することができる。
なお、複数の第１の識別情報と、複数の第２の識別情報とが一致する場合もあり得る。この場合、事業者装置１０６は、例えば一意に決済サービスを特定する管理情報を、取引相手携帯端末１０４から事業者装置１０６に送るよう促すよう報知する情報を顧客装置１０２及び取引相手携帯端末１０４の少なくともいずれか１つに送信してもよい。
なお、上記管理情報が取引相手携帯端末１０４から事業者装置１０６に送られてこない場合、あるいはその他の例外的な事象、例えば入力誤り、伝送での誤り、発信先電話番号宛に第三者から間違い電話がかかってきた場合などには、識別情報の一致によって同一の決済サービスを特定できないことがある。このような場合に対処する方法（確実性の確保）については後述する。

処理１４０で、事業者装置１０６は、第１の識別情報と第２の識別情報とを比較する。例えば、顧客に１つの電話番号が割り当てられており、かつその顧客について複数の決済サービスが並行して発生することが無い場合には、事業者装置１０６が第１の識別情報と第２の識別情報とを比較し一致が確認できれば、一致が確認された顧客装置１０２からの情報と、取引相手携帯端末１０４からの情報とが、同一の決済サービスの情報であると判断してもよい。

処理１４０で、識別情報１と識別情報２との一致が得られない場合には、顧客装置１０２及び取引相手携帯端末１０４のいずれかから送られてくる情報が事業者装置１０６に到達するのが遅れている可能性があるため、ある時間幅において識別情報１と識別情報２との一致の確認を繰り返すことが望ましい。そして、その時間幅が経過しても、識別情報１と識別情報２との一致が得られない場合には、事業者装置１０６は、該当する決済サービスについて、対応する取引相手携帯端末１０４が特定できない旨を顧客装置１０２に伝達してもよい。あるいは、この場合に、事業者装置１０６は該当する決済サービスをキャンセルして、該当する決済サービスがキャンセルされたことを顧客装置１０２に伝達してもよい。
このような事象が発生する原因としては、取引相手携帯端末１０４が、顧客に対してユニークに割り当てられた電話番号以外の電話番号に発信してしまった場合、人為的誤り又は伝送誤りなどで、事業者装置１０６に到達した第１の識別情報と第２の識別情報とが異なっている場合などが挙げられる。

シーケンスＳ１２６で、処理１４０で一致が確認された決済サービスの処理を取り扱うＵＲＩの情報を含むＳＭＳなどのメッセージが、取引相手携帯端末１０４の発信元電話番号宛に送信される。ＵＲＩとは、決済サービスの処理が決済業者で行われるインターネットアドレス（ＵＲＬ）或いは、決済業者が決済サービスを実行するためになされる処理を遂行するために必要とされるアクセス情報、所定のＡＰＩで定められた取引相手携帯端末１０４において実行されるコマンド、取引相手携帯端末１０４において決済サービスを扱うプログラムの実行に遷移させる情報などが挙げられる。なお、メッセージは、ＳＭＳに限られるものではなく、ＲＣＳ、ＭＭＳなどであってもよい。或いは、ＳＮＳなどに付随した通信におけるメッセージなどであってもよい。

第１の識別情報と第２の識別情報との一致が検出された場合にだけ、シーケンスＳ１２４において発信元電話番号にメッセージを送信することによって、誤って着信した通話の発信元電話番号に、或いは攻撃などを目的として故意に着信した電話の発信元電話番号に、決済のための上記メッセージが誤って送られてしまうことを避けることができる（或いは、このような状況を十分に防止することができる）。

また、発信元電話番号（又は電話番号に準ずるアドレスを用いた通信の発信元）にメッセージを返すことによって、意図しない宛先へのメッセージ（例えば、スパムメッセージ）を発信してしまうことを避けることができる。また、電話番号を用いた通信又は電話番号に準ずるアドレスを用いた通信に対して対応することとし、通常のメールなどに応答することを避けることで、発信元を詐称した通信に対してメッセージを返してしまうことを避けることができる。また、大量のメールによるＤＯＳ攻撃などを避けることができる。このようにすることで、実施形態の信頼性を損なうなどの不利益を避けることができる。

シーケンスＳ１２８で、取引相手携帯端末１０４は、ＵＲＩに基づいて通信を開始する。この通信によって、取引相手携帯端末１０４は、適切な決済サービスの決済の手続を進めることができる。

事業者装置１０６は、取引相手携帯端末１０４からＵＲＩに基づいてアクセスしてきた接続要求を受け取ってもよい。
シーケンスＳ１３０で、事業者装置１０６は、課金情報と、決済サービスを特定する管理情報を含む情報とともに、取引相手携帯端末１０４からの通信を、決済業者装置１０８にリダイレクトすることができる。

シーケンスＳ１３２で、取引相手携帯端末１０４と決済業者装置１０８とが直接的に、決済サービスに関する情報の授受を行うことができる。このことにより、クレジットカードなどの情報又はキャッシュレス決済に関する情報など、決済において秘密にされるべき情報を取引相手携帯端末１０４と決済業者装置１０８とが直接的に授受することができる。このようにすることで、秘密にされるべき情報が第三者に漏洩されてしまうことを防止することができる。
この決済サービスの処理において、取引相手携帯端末１０４は、取引相手から決済に必要な情報を受け取り（１５４）、その情報を決済業者装置１０８に伝達することができる。決済サービスが完了した場合には、完了した旨が、決済業者装置１０８から取引相手携帯端末１０４に伝達され得る。なお、決済処理が完了しない場合には、完了しない旨の情報が決済業者装置１０８から取引相手携帯端末１０４に伝達され得る。

シーケンスＳ１３４で、決済サービスが完了した場合には、管理情報と共に完了した旨が、決済業者装置１０８から事業者装置１０６に伝達され得る。なお、決済処理が完了しない場合には、管理情報と共に完了しない旨の情報が決済業者装置１０８から事業者装置１０６に伝達され得る。

シーケンスＳ１３６で、決済サービスが完了した場合には、完了した旨が、事業者装置１０６から顧客装置１０２に伝達され得る。なお、決済処理が完了しない場合には、完了しない旨の情報が事業者装置１０６から顧客装置１０２に伝達され得る。
シーケンスＳ１３８で、決済サービスが完了した場合には、完了した旨が、事業者装置１０６から取引相手携帯端末１０４に伝達されてもよい。なお、決済処理が完了しない場合には、完了しない旨の情報が事業者装置１０６から取引相手携帯端末１０４に伝達されてもよい。

＜実施形態の総括＞
以上のようにして、上記の実施形態において、顧客装置１０２及び事業者装置１０６は、取引相手携帯端末１０４及び決済業者装置１０８との間で授受されるクレジットカードなどの秘密にすべき情報或いはキャッシュレス決済に関する秘密にすべき情報に触れることなく、顧客が取引相手に課金した決済サービスを処理することができる。

なお、上記のように通信経路１０２ａと通信経路１０４ａとの両者の経路を使い分ける理由について補足する。
まず、通信経路１０２ａを介して、顧客装置１０２は、課金情報と第１の識別情報とを含む情報を事業者装置１０６に送る。通信経路１０４aを介して、取引相手携帯端末１０４は、取引相手携帯端末１０４の発信電話番号と第２の識別情報とを含む情報を事業者装置１０６に送る。

取引相手携帯端末１０４が顧客に割り当てられた電話番号に通信を行うことで、事業者装置１０６は、取引相手携帯端末１０４が、どの顧客と関連しているのかを知ることができる。
事業者装置１０６は、第１の識別情報と第２の識別情報とが一致することを確認することで、顧客装置１０２の決済サービスと取引相手携帯端末１０４とを関連付けることができる。

事業者装置１０６は、取引相手携帯端末１０４に、関連付けられた決済サービスを処理するためのＵＲＩを送る。

取引相手携帯端末１０４は、得られたＵＲＩを元に、事業者装置１０６を経由して、リダイレクトなどで、決済業者装置１０８に直接アクセスすることが可能となる。その際、事業者装置１０６は、課金情報と決済サービスを特定する管理情報とを決済業者装置１０８に与える。
以上のように、取引相手携帯端末１０４は、顧客装置１０２及び事業者装置１０６に知られることなく、決済業者装置１０８との直接の通信によって、決済サービスを処理するためのクレジットカードなどの情報又はキャッシュレス決済などの秘密の情報を授受できる。通信経路１０２ａと通信経路１０４aとを用いることによって、顧客装置１０２及び事業者装置１０６は、取引相手携帯端末１０４及び決済業者装置１０８の扱う秘密の情報の漏洩を回避しつつ、決済サービスを簡便に処理することができる。

決済が終了すると、決済業者装置１０８から事業者装置１０６に決済サービスの決済の結果が伝達される。顧客装置１０２又は取引相手携帯端末１０４は、決済の結果を事業者装置１０６から受け取ることができる。
以上が、上記実施形態の処理の総括的な説明である。

以上の実施形態では、取引相手携帯端末１０４の電話番号の一部又は全部を識別情報に用いた。識別情報の機能の１つは、同一の決済サービスの情報が、通信経路１０２ａと通信経路１０４ａとの両者の経路を用いて伝送されるため、これらの経路で送られる決済サービスを関連付けることであった。この機能を担保するには、取引相手携帯端末１０４の電話番号の情報以外に、又はこの情報に加えて、その他の情報を識別情報に用いることも可能である。或いは、複数の情報を組合わせて識別情報として用いることも可能である。
識別情報となり得る情報の例については後述する。

なお、顧客装置１０２からの第１の識別情報と、取引相手携帯端末１０４からの第２の識別情報が一致する場合にのみ、事業者装置１０６から決済サービスの処理のＵＲＩを含むメッセージを取引相手携帯端末１０４に送信することに関する共通する効果の一つは、事業者装置１０６から、決済サービスの処理のＵＲＩを含むメッセージを誤った送信先に送信してしまうことを未然に防止できることが挙げられる。或いは、メッセージを誤った送信先に送信してしまうことの発生確率をゼロに近い値にまで減少させることが可能である。誤った送信先に、決済サービスの処理のＵＲＩを含むメッセージが送られた場合、そのメッセージを受信した携帯端末を管理する者に無用の混乱を与えることとなる。このような状況の発生を防止する（又は減少させる）ためには、顧客装置１０２からの第１の識別情報と、取引相手携帯端末１０４からの第２の識別情報とが一致する場合に、事業者装置１０６から決済サービスの処理のＵＲＩを含むメッセージを取引相手携帯端末１０４に送信することが望ましい。なお、誤った送信先に、決済サービスの処理のＵＲＩを含むメッセージが送られた場合の対処については、後述する。

図２Ｂは、事業者装置１０６のハードウエア構成を示す図である。事業者装置１０６は、ＣＰＵ２５１、ＲＯＭ２５２、ＲＡＭ２５３、ネットワークインターフェース２５５、入力インターフェース２５６、表示インターフェース２５７及び外部メモリインタフェース２５８を有する。

ネットワークインターフェース２５５には、ネットワーク２６５が接続されている。ネットワーク２６５には、顧客装置１０２、取引相手携帯端末１０４、決済業者装置１０８等が接続される。入力インターフェース２５６には、タッチセンサ、カメラ及びマイクなどの入力デバイスが接続され得る。表示インターフェース２５７には、表示部２６７などの出力デバイスが接続され得る。外部メモリインタフェース２５８には、記憶媒体２６８が接続されている。本明細書及び図面に開示された実施形態を実現するコンピュータプログラムは、実体のある（tangible）非一時的でない（nontransitory）メモリである記憶媒体２６８、ＲＯＭ２５２、又はＲＡＭ２５３に記憶され得る。このコンピュータプログラムはＣＰＵ２５１によって実行される。
また、このコンピュータプログラムは、ネットワーク２６５を介してダウンロードされ得る。これらのハードウエアは、バス２５４によって相互に接続されている。
図２Ｂに示される事業者装置１０６のハードウエアの構成は一例であって、その他のハードウエアが存在し得る。

図３は、事業者装置１０６における決済サービス生成処理フローの概略を示す図である。各処理ステップについて順を追って説明する。

以下の処理は、顧客装置１０２からの課金情報の受取のイベントが発生した時に、事業者装置１０６において開始されることが望ましい。

［ステップＳ３５０］事業者装置１０６は、顧客装置から課金情報と、第１の識別情報とを受け取る。

［ステップＳ３５２］事業者装置１０６は、顧客装置から課金情報及び第１の識別情報に対して、ユニークな管理情報を付与する。この管理情報によって、決済サービスを識別することができる。

［ステップＳ３５４］事業者装置１０６は、管理情報、課金情報及び第１の識別情報を含む決済サービスのエントリを決済サービス管理テーブルに作成する。
図１５は、決済サービス管理テーブル１５００の一例を示している。図１５に示す決済サービス管理テーブル１５００の詳細については後述する。

以上のようにして、事業者装置１０６は、決済サービス管理テーブル１５００を作成することで、決済サービスを管理することができる。なお、決済サービスを、図１５のような決済サービス管理テーブル１５００で管理することが必須ではなく、その他の管理手法を用いてもよいことは言うまでもない。

図４は、事業者装置１０６における電話着信処理フローの概略を示す図である。

以下の処理は、顧客に割り当てられた電話番号に対する取引相手携帯端末１０４からの電話の着信のイベントが発生した時に、事業者装置１０６において開始されることが望ましい。なお、イベントは、電話の着信に限定されるものではなく、電話番号宛のメッセージの着信などのイベントであってもよい。

［ステップＳ４５０］事業者装置１０６は、顧客に割り当てられた電話番号に着信した電話の発信元電話番号及び第２の識別情報を取得する。既に述べたように、発信元電話番号が第２の識別情報を含む場合があり得る。
図１６に取引相手携帯端末管理テーブル１６００の例を示す。取引相手携帯端末管理テーブル１６００は、顧客に割り当てられた電話番号の各々に対応して作成されることが望ましい。取引相手携帯端末管理テーブル１６００には、顧客に割り当てられた電話番号に着信した通話から得られた発信元電話番号、第２の識別情報などが格納されている。図１６に示す取引相手携帯端末管理テーブル１６００の詳細は後述する。

図４に戻る。
［ステップＳ４５２］事業者装置１０６は、同じ発信元番号の有効なエントリが、取引相手携帯端末管理テーブル１６００に存在するかをチェックする。このチェックが肯定的な場合（Ｙｅｓ）、処理１４０は終了する。このチェックが否定的な場合（Ｎｏ）、処理はステップＳ４５４に移る。
この処理によって、取引相手携帯端末管理テーブル１６００に既に重複した有効なエントリが重複して格納されることを避けることができる。

［ステップＳ４５４］事業者装置１０６は、発信元電話番号及び第２の識別情報を含むエントリを取引相手携帯端末管理テーブル１６００に作成する。
以上の処理によって、事業者装置１０６は、取引相手携帯端末１０４から顧客に割り当てられた電話番号宛に掛かってきた電話着信により得られた発信元電話番号及び第２の識別情報を含むエントリを、取引相手携帯端末管理テーブル１６００に格納することができる。なお、発信元電話番号及び第２の識別情報を含む情報は、取引相手携帯端末管理テーブル１６００を用いずに、他の管理手法により管理してもよいことは言うまでもない。

図５は、事業者装置１０６によって行われる、取引相手携帯端末管理テーブル１６００のエントリ無効化処理の概略を示す図である。

顧客に対しユニークに割り当てられた電話番号宛に着信する電話には、顧客の取引相手からの電話以外に、誤って着信した電話、顧客の取引相手でない者が故意に掛けた電話などが存在する可能性がある。このような電話の発信元電話番号に決済サービスのためのメッセージを送る必要はない。そのため、このような電話によって取引相手携帯端末管理テーブル１６００に生成されたエントリは、決済サービスに利用されないまま取引相手携帯端末管理テーブル１６００に長い時間存在することとなる可能性がある。
このような状況を避けるために、所定の時間を定めて、決済サービスに利用されないまま、その所定の時間以上、取引相手携帯端末管理テーブル１６００に存在しているエントリは、削除しておくことが望ましい。なぜなら、そのような決済サービスに利用される可能性が小さくなったエントリだからである。
なお、仮に削除されるべきでないエントリが誤って削除された場合には、取引相手携帯端末１０４から、同じ電話番号に再度電話をかけることとすればよい。

図５の具体的な処理フローは以下のとおりである。
以下の処理は、割り込み処理により所定の間隔で実行されることが望ましい。
［ステップＳ５５２］取引相手携帯端末管理テーブルに、エントリが作成されてから所定の時間が経過しており、かつ対応する決済サービスが対応付けされていないエントリが存在するかをチェックする。チェック結果が肯定的であれば（Ｙｅｓ）、処理は、ステップＳ５５４に移る。チェック結果が否定的であれば（Ｎｏ）、処理１４０は終了する。

［ステップＳ５５４］取引相手携帯端末管理テーブル１６００の該当するエントリを無効化する。
以上の処理により、取引相手携帯端末管理テーブル１６００に存在する不要なエントリを効果的に削除することができ、決済処理の信頼性を向上することができる。

図６は、事業者装置１０６によって行われる取引相手携帯端末へのメッセージ送信処理の概要のフローを示す図である。この処理は、事業者装置１０６において実行される。
この処理は、決済サービス管理テーブル１５００に決済サービスのエントリが作成されたイベントにより開始されることが望ましい。なお、決済サービス管理テーブル１５００のエントリと取引相手携帯端末管理テーブル１６００のエントリとのペアが破棄された場合にも、この一連の処理が開始されることが望ましい。

［ステップＳ６５２］決済サービス管理テーブルのエントリの第１の識別情報と、取引相手携帯端末管理テーブルのエントリの第２の識別情報とが一致する新たなエントリのペアが存在するかがチェックされる。なお、過去にエントリのペアが存在していたが、ペアが破棄されたエントリ同士について、再度ペアを作ることは除外される。なぜなら、過去にペアが破棄されたエントリ同士は、ペアが容認されないエントリ同士だからである。すなわち、第１の識別情報と第２の識別情報とが一致していても、破棄されたペアについての取引相手携帯端末１０４は、対応する決済サービスを扱うことが適切ではないと既に判断されたからである。チェック結果が肯定的（Ｙｅｓ）であれば処理はステップＳ６５６に移る。チェック結果が否定的（Ｎｏ）であれば処理はステップＳ６５４に移る。

［ステップＳ６５４］決済サービスのエントリが作成されてから所定の時間が経過したかがチェックされる。チェック結果が肯定的（Ｙｅｓ）であれば処理はステップＳ６６４に移る。チェック結果が否定的（Ｎｏ）であれば処理はステップＳ６５２に戻る。

［ステップＳ６５６］決済サービス管理テーブル１５００のエントリと、取引相手携帯端末管理テーブル１６００のエントリとのペアを作成する。ペアを作成することで、取引相手携帯端末１０４と、決済サービスとが関連付けられることになる。なお、ペアを作成するとは、例えば、決済サービス管理テーブル１５００のエントリ及び取引相手携帯端末管理テーブル１６００のエントリが相互に関連付けられるように、夫々のエントリに関連付けの情報を格納することで実現することができる。なお、実施形態は、この例に限定されるものではない。

［ステップＳ６５８］ペアの取引相手携帯端末管理テーブル１６００の中の発信元電話番号に宛てて、決済サービス管理テーブル１５００の対応するエントリで特定される決済サービスのＵＲＩを含むメッセージを送信する。

［ステップＳ６６０］顧客装置１０２からのペアの容認の是非の連絡を受け取る。
［ステップＳ６６２］顧客装置から受け取った連絡が、ペアを容認する連絡かがチェックされる。チェック結果が肯定的（Ｙｅｓ）であれば処理は終了する。チェック結果が否定的（Ｎｏ）であれば処理はステップＳ６６６に移る。

［ステップＳ６６４］決済サービスのタイムアウトを含むメッセージを顧客装置１０２に伝達する。この場合には、決済サービスが生成されてから、所定の時間が経過しても、決済ッサービスを取り扱う取引相手携帯端末１０４が見つからない状況であることになる。この場合の原因としては、取引相手携帯端末１０４が、誤った電話番号に電話をかけている場合、顧客装置１０２から送られる第１の識別情報又は取引相手携帯端末１０４から送られる第２の識別情報のいずれか又は双方に誤りが発生している場合などが考えられる。この場合には、タイムアウトを含むメッセージを顧客装置１０２に送ることとし、顧客装置１０２は、他の手段を用いて、取引相手携帯端末１０４が、適切なＵＲＩを取得できるようにする。適切なＵＲＩを取引相手携帯端末１０４に伝達する例としては、顧客装置１０２などに、適切なＵＲＩを含む機会読み取り可能なコード（例えばＱＲコード（登録商標））を表示させ、取引相手携帯端末１０４が、このＱＲコード（登録商標）を読み取るようにしてもよい。この具体例は後述する。

［ステップＳ６６６］決済サービス管理テーブル１５００のエントリと、取引相手携帯端末管理テーブル１６００のエントリとのペアを破棄する。破棄されたペアが再びペアとならないように、該当する決済サービス管理テーブル１５００のエントリと、該当する取引相手携帯端末管理テーブル１６００のエントリには、破棄されたペアがわかるように、各々のエントリに破棄されたエントリを記憶するようにすることが望ましい。
破棄されたペアの決済サービス管理テーブル１５００のエントリと、取引相手携帯端末管理テーブル１６００のエントリは、他のペアの組合せが可能となるように、各エントリの状態（ステータス）を変更することが望ましい。このエントリの状態（ステータス）の変更の詳細については、後述する。処理は、ステップＳ６５２に戻る。

図７は、事業者装置１０６の機能ブロック図である。事業者装置１０６は、電話番号割当テーブル７０２、顧客装置通信部７０４、取引相手携帯端末通信部７０６、決済業者装置通信部７０８、決済サービス制御部７１０及び決済記憶部７２０を有する。

決済サービス制御部７１０は、事業者装置１０６において、決済サービス全体を制御する。
図１４は、電話番号割当テーブル７０２の一例を示している。電話番号割当テーブル７０２は、複数の顧客の各々に対してユニークに割り当てられた電話番号を、顧客のＩＤに対応付けて記憶するエントリを持つ。例えば、取引相手携帯端末１０４から、電話番号099-1234-1234宛てに掛かってきた電話を受信した場合を想定する。電話番号099-1234-1234によって、電話番号割当テーブル７０２を検索して、顧客ＩＤであるＡ１２を得ることによって、取引相手に課金を行っている顧客の顧客ＩＤがＡ１２であることを特定することができる。

図７に戻る。顧客装置通信部７０４は、顧客装置１０２との間での通信を行い、その通信の内容を決済サービス制御部７１０に渡す。また、決済サービス制御部７１０の指示に基づき、顧客装置通信部７０４は、顧客装置１０２に、決済サービスの管理情報、決済サービスの処理結果などを伝達する。

取引相手携帯端末通信部７０６は、取引相手携帯端末１０４との間で通信を行い、その通信の内容を決済サービス制御部７１０に渡す。また、決済サービス制御部７１０の指示に基づき、取引相手携帯端末通信部７０６は、取引相手携帯端末１０４に決済サービスに関するＵＲＩを含むメッセージなどを送信する。

決済業者装置通信部７０８は、顧客から取引相手に対する課金情報、決済サービスに関する管理情報などを、決済業者装置１０８に伝達する。また、取引相手携帯端末１０４から事業者装置１０６に対する通信を、決済業者装置１０８にリダイレクトすることができる。
なお、決済業者装置１０８は、クレジットカード会社の装置又はキャッシュレス決済業者の装置などに接続されていてもよい。
なお、決済記憶部７２０は、既に述べた決済サービス管理テーブル１５００及び取引相手携帯端末管理テーブル１６００を記憶することができ、課金情報、決済サービスに関する管理情報、顧客装置１０２及び取引相手携帯端末１０４などを関連付けて記憶することができる。

図８ないし図１３は、事業者装置１０６が顧客装置１０２に表示させる表示画面と、事業者装置１０６が取引相手携帯端末１０４に表示させる表示画面の例を示す図である。これらの図は、上から下に向かって、時間が経過する順序に略描かれている。そして、サイドバイサイドで並んでいる顧客装置表示画面と取引相手携帯端末表示画面の表示時刻は、略同時刻であるように描かれていることに留意すべきである。なお、画面の表示の内容及びその表示のタイミングは、これらの例に限定されるものではない。そして、画面遷移の矢印に記載されているＡないしＥ及びＰないしＴは、各図の画面遷移の矢印の対応を分かりやすくするために記載している。なお、画面遷移は一例を示すものであって、画面遷移の内容及び順番は、矛盾の無い限り入れ換えることができる。また、矛盾がない範囲において、全ての画面が表示されることが必須ではない点に留意すべきである。

図８を用いて、顧客装置１０２が顧客による操作によって、事業者装置１０６にログインしていることを前提として、以下に説明する。
顧客装置表示画面８００では、発信先電話番号８０１が表示されている。この発信先電番号８０１は、予め顧客に割り当てられた電話番号であり、取引相手に伝えることで、取引相手携帯端末１０４からこの電話番号に発信するための電話番号である。
具体的な電話番号は、0057-00-01であり（８１０）、取引相手携帯端末表示画面８５０には、取引相手によるキー入力により、発信先電話番号0057-00-01が入力され（８５２）、電話発信が行われている。なお、この発信先電話番号は、予め顧客に割り当てられているため、紙などの媒体に記載されていてもよい。この場合には、顧客は、この紙の媒体を取引相手に提示することによって、発信先電話番号８０１を取引相手に伝達することが可能である。その他の手段によって、発信先電話番号８０１を取引相手に伝達されてもよい。
顧客装置表示画面８００では、さらに、課金額８０２、取引相手携帯端末１０４の下４桁８０４が顧客によって入力されている。取引相手携帯端末１０４の下４桁８０４は、第１の識別情報の一例である。また、第２の識別情報は、取引相手携帯端末１０４の発信元電話番号の下４桁となる。
顧客により登録ボタン８０６がタッチされることによって、課金額８０２と取引相手携帯端末１０４の下４桁（すなわち第２の識別情報）を含む情報が、事業者装置１０６に到達する。

顧客装置表示画面８１０では、事業者装置１０６によって、この決済サービスに対する管理情報８１４すなわち987-62が割り当てられたことが表示されている。また、取引相手携帯端末１０４にメッセージが送信済みであることを示す表示「携帯にメッセージ送信済」８１５が表示されている。
そして、顧客に対して問い合わせのメッセージ「携帯にメッセージがとどいていますか？」８１６が表示されている。顧客に対して、答えることを促すＹｅｓボタン８１８と、Ｎｏボタン８１９が表示されている。
取引相手携帯端末表示画面８６０には、メッセージ８６２が届いており、表示されている。メッセージ８６２には、決済サービスを処理する具体的なＵＲＩ８６３が含まれていることがわかる。
顧客は、取引相手の所持する取引相手携帯端末１０４にメッセージが着信していることを確認することができたため、Ｙｅｓボタン８１８をタッチし、Ｙｅｓボタン８１８が反転表示されると共に、Ｙｅｓボタン８１８がタッチされたことが、事業者装置１０６に伝達される。
顧客装置１０２は、Ｙｅｓボタン８１８がタッチされるまで、取引相手携帯端末１０４によるＵＲＩ８６３へのアクセスを禁止してもよい。このようにすることによって、メッセージ８６２が、他の端末に送信され、この取引相手携帯端末１０４に届かない場合であっても、他の端末からのＵＲＩ８６３へのアクセスを禁止することができる。

顧客装置表示画面８２０では、事業者装置１０６によって、管理情報８１４に対応付けられたシンボル８２２が表示されている。
取引相手携帯端末表示画面８７０では、ＵＲＩへのアクセスが成功して、管理情報８７４及びこの管理情報８７４に対応したシンボル８７２が表示されている。
顧客は、顧客装置表示画面８１０に表示されたシンボル８２２又は管理情報８１４のいずれかと、取引相手携帯端末表示画面８７０に表示されたシンボル８７２又は管理情報８７４の一致を確認することによって、取引相手携帯端末１０４が、顧客装置１０２と同じ決済サービスを処理していることを確認することができる。顧客は、シンボル８２２とシンボル８７２とが一致していることを認識することによって、管理情報８１４と管理情報８７４との一致を確認することよりも、容易にこのことを確認できる。
顧客に対して問い合わせのメッセージ「携帯に表示されたシンボルは同じですか？」８２６が表示されてもよい。顧客は、この問い合わせに対してＹｅｓボタン８２８又はＮｏボタン８２９のいずれかをタッチすることで、この問い合わせに答えることができると共に、取引相手携帯端末１０４が、顧客装置１０２と同じ決済サービスの処理を行っているか否かを、事業者装置１０６に伝達することができる。
事業者装置１０６は、このＹｅｓボタン８２８がタッチされるまで、取引相手携帯端末１０４による決済処理の進行を禁止するようにしてもよい。このようにすることによって、誤った（又は別の）決済サービスの処理が、取引相手携帯端末１０４によって行われてしまうことを未然に防止することができる。

顧客装置表示画面８３０では、取引相手携帯端末１０４で決済サービスが進行していることを示すメッセージ「携帯で決済処理が行われています」８２６が表示されている。
取引相手携帯端末表示画面８８０では、決済サービスに移行することを示すメッセージ「お支払処理を開始します」８８７が表示されている。
取引相手により、Ｎｅｘｔボタン８８８がタッチされることによって、事業者装置１０６は、課金額、管理情報を含む決済サービスに関する情報を決済業者装置１０８に伝達すると共に、取引相手携帯端末１０４からの通信を、決済業者装置１０８にリダイレクトする。
以上の処理によって、取引相手携帯端末１０４は、決済業者装置１０８とダイレクトに通信を行うことができる。取引相手携帯端末１０４と決済業者装置１０８とは、決済サービスの決済に必要なクレジットカードの番号などの秘密の情報を安全に交換することができる。
その後の処理については、図１２及び図１３を用いて後述する。

図９は、図８の顧客装置表示画面８００及び取引相手携帯端末表示画面８５０の後の画面の例であって、事業者装置１０６からメッセージが届かない場合の例を示している。
取引相手携帯端末表示画面９６０では、メッセージが届いていないことがわかる。このようにメッセージが届かない場合には、顧客は例えば１分などの一定の時間、待つことが望ましい。その一定の時間、取引相手携帯端末１０４にメッセージが到達しない場合には、顧客装置表示画面９１０の問いかけのメッセージ「携帯にメッセージが届いていますか？」に応答して、顧客によって、Ｎｏボタン９１９がタッチされることとなる。
顧客装置表示画面９１０では、これに対処するため、決済サービスを処理するＵＲＩの情報を含むＱＲコード９１７（登録商標）が表示されるようにしてもよい。
取引相手は、取引相手携帯端末１０４がＱＲコード９１７（登録商標）を撮像して、決済サービスを処理するＵＲＩを含む情報を読み取らせてもよい。
このようにすることによって、メッセージが到達しない場合であっても、決済サービスの処理を進めることができる。

なお、上記の例は一例であって、この例に限られるものではない。メッセージが到達しない原因として考えられるのは、第１の識別情報又は第２の識別情報に誤りが含まれている場合、取引相手携帯端末１０４が、誤った電話番号に電話発信を行っている場合、メッセージが誤って他の携帯端末に送信されている場合などが挙げあられる。なお、他の誤った携帯端末にメッセージが送信された場合には、図６で説明したように、ペアの破棄が行われる場合がある。この場合には、その破棄の後に、新たなペアが作成され、メッセージが到達する場合がある。したがって、上述のように、メッセージが到達しない場合であっても、顧客は、一定の時間待つことが望ましい。
また、取引相手携帯端末１０４が誤った電話番号宛に発信してしまったことが分かった場合には、取引相手携帯端末１０４から、正しい電話番号にかけ直すことで、メッセージが到達すこともあり得る。

また、取引相手が、取引相手携帯端末１０４の発信元電話番号の下４桁を誤って顧客に伝えた場合、或いは、顧客によって誤った下４桁が顧客装置１０２に入力された場合には、下４桁の再入力ができるようにしてもよい。あるいは、既に生成された決済サービスを顧客の指示に基づいて無効化して、正しいい下４桁と課金額が入力されるようにして、事業者装置１０６は、新たな決済サービスを生成するようにしてもよい。
取引相手携帯端末表示画面９７０では、ＱＲコード９１７（登録商標）がカメラによって撮像されている様子が表示されている。取引相手携帯端末１０４は、ＱＲコード９１７（登録商標）に含まれる決済サービス処理のＵＲＩによって、例えば図８における取引相手携帯端末表示画面８７０に遷移することができる。

図１０は、メッセージによって誤った決済サービス処理のＵＲＩが送られた例外的ケースへの対応に関する画面遷移の例を示す図である。
取引相手携帯端末表示画面１０６０では、メッセージが表示されている。しかしながら、メッセージ１０６２の管理情報は、顧客装置表示画面１０１０の管理情報８１４とは異なっている。
このケースの場合には、メッセージが取引相手携帯端末表示画面１０６０に表示されたため、顧客は、顧客装置表示画面１０１０の問い合わせのメッセージ「携帯にメッセージがとどいていますか？」１０１６に対して、誤ってＹｅｓボタン１０１８をタッチしてしまったことを示している。顧客は、取引相手のメッセージ中の管理情報までチェックすることができない場合もあり得るため、このような状況が発生することがあり得る。

図１０の顧客装置表示画面１０２０に表示されたシンボル１０２２と、取引相手携帯端末表示画面１０７０に表示されたシンボル１０７２とは、この場合、異なったものとなる。したがって、顧客は、取引相手携帯端末表示画面１０７０に表示されたシンボルを確認することによって、容易に取引相手携帯端末１０４が誤った決済サービスの処理を開始しようとしていることが認識できる。
この場合には、問い合わせのメッセージ「携帯に表示されたシンボルは同じですか？」１０２６に応答して、顧客によって、Ｎｏボタンがタッチされる。この状況は、図６のフローにおけるステップＳ６６２で、Ｎｏの場合の例である。この場合、ペアの破棄が行われる。したがって、その後、図６のステップＳ６５２に示す新たなペアがあるかがチェックされることとなる。
図１０の顧客装置表示画面１０３０のシンボル１０２２と、取引相手携帯端末表示画面１０８０のシンボル１０８２が一致することが顧客によって確認されることで、Ｙｅｓボタン１０２８がタッチされる。この結果が、事業者装置１０６に伝達される。

図１１は、所定の時間が経過しても決済サービスの処理の一致が確認できない場合の例を示す図である。
顧客装置表示画面１１３０のシンボル１１２２と、取引相手携帯端末表示画面１１８０のシンボル１１８２が異なっている。したがって、顧客によって、Ｎｏボタン１１２９がタッチされる。そして、所定の時間が経過しても、シンボルが一致しない状態となったと仮定する。この事例は、図６におけるステップＳ６６４の具体例である。
この場合、顧客装置表示画面１１４０では、ＵＲＩを含むＱＲコード１１３８（登録商標）が表示されるようにしてもよい。取引相手は、取引相手携帯端末表示画面１１９０に示されるように、取引相手携帯端末１０４のカメラがＱＲコード１１３８（登録商標）を読み込んで（１１９３）、決済サービスを処理するＵＲＩを含む情報を読み取らせてもよい。
以上のようにすることによって、顧客装置１０２と取引相手携帯端末１０４とが、同じ決済サービスを処理することが担保される。

図１２は、決済が無事完了する場合の画面遷移の例を示す図である。図１２は図８の処理の続きである。
取引相手携帯端末１０４では、決済１２００が行われている。ここで、例えば、取引相手によって、取引相手携帯端末１０４にクレジットカード番号などの入力がなされる。決済１２００において、取引相手携帯端末１０４は、決済業者装置１０８とセキュア―に接続することができる。決済１２００において通信されるクレジットカードの番号など、秘密にされるべき情報は、顧客装置１０２及び事業者装置１０６には伝達されないようにすることができる。
決済１２００が終了すると、決済業者装置１０８から、事業者装置１０６に、決済の結果が伝達される。

図１２において、事業者装置１０６は、顧客装置表示画面１２３０で、決済が無事完了したことを示す表示「決済完了」１２３６を表示させる。また、この決済サービスの管理情報８１４に対応するシンボル１２３２ａが表示されてもよい。また、決済が無事に完了したことを示すシンボル１２３２ｂが表示されてもよい。
事業者装置１０６は、取引相手携帯端末表示画面１２９０で、決済が無事完了したことを示す表示「決済完了」１２９６を表示させる。また、この決済サービスの管理情報８１４に対応するシンボル１２９２ａが表示されてもよい。また、決済が無事に完了したことを示すシンボル１２９２ｂが表示されてもよい。

このように、顧客は、決済サービスの管理情報８１４に対応するシンボル１２３２ａと同じシンボル１２９２ｂが取引相手携帯端末表示画面１２９０に表示されていることを確認することで、取引相手携帯端末１０４での決済サービスを特定することが容易にできる。すなわち、顧客装置１０２及び取引相手携帯端末１０４が、同じ決済サービスに対して処理を行っていることが確認されることで、取引相手携帯端末１０４が、正しい決済サービスに対して、処理を行ったことを確認することができる。
加えて、顧客が、決済が無事完了したことを示すシンボル１２３２ｂ及びシンボル１２９２ｂを確認することで、決済が無事完了していることも容易に確認することができる。

図１３は、決済が失敗する場合の画面遷移の例を示す図である。図１３は図８の処理の続きである。図１３Ａは、顧客装置表示画面の例を示す図であり、図１３Ｂ及び図１３Ｃは、取引相手携帯端末表示画面の例を示す図である。
決済１３００が実行された後、決済業者装置１０８は、事業者装置１０６に決済の結果を伝達する。
図１３Ａでは、事業者装置１０６は、顧客装置表示画面１３３０で、決済が失敗したことを示す表示「決済失敗」１３３６を表示させる。また、この決済サービスの管理情報８１４に対応するシンボル１３３２ａが表示されてもよい。また、決済が失敗したことを示すシンボル１３３２ｂが表示されてもよい。

図１３Ｂでは、事業者装置１０６は、取引相手携帯端末表示画面１３９０で、決済が失敗したことを示す表示「決済失敗」１３９６を表示させる。また、この決済サービスの管理情報８１４に対応するシンボル１３９２ａが表示されてもよい。また、決済が失敗したことを示すシンボル１３９２ｂが表示されてもよい。
このように、顧客は、決済サービスの管理情報８１４に対応するシンボル１３３２ａと同じシンボル１３９２ｂが取引相手携帯端末表示画面１３９０に表示されていることを確認することで、取引相手携帯端末１０４での決済サービスを特定することが容易にできる。加えて、決済が失敗したことを示すシンボル１３３２ｂ及びシンボル１３９２ｂを確認することで、決済が失敗していることも容易に確認することができる。

図１３Ｃは、取引相手が不正を行った例を示している。取引相手は、例えば取引相手携帯端末１０４に予め保存されていた過去の決済完了の取引相手携帯端末表示画面１３９５を提示していると仮定する。この場合、決済サービスの管理番号１３９６は、顧客装置１０２の本来の管理番号８１４と異なっており、決済サービスの管理番号１３９７に対応するシンボル１２９３ａも、シンボル１２２３ａと異なっている。したがって、顧客は取引相手携帯端末１０４に表示された取引相手携帯端末表示画面１３９５が、異なる決済サービスに基づく画面であることを容易に認識することができる。
また、決済の結果を示す表示「決済完了」１３７９が表示されており、その表示に対応するシンボル１３９３ｂが決済完了を示すシンボルであることは認識されるが、上述のように、シンボル１３３２ａとシンボル１３９３ａとが異なることから、顧客は、この取引相手携帯端末表示画面１３９５は異なる決済サービスの結果を示す画面であり、偽装された画面であることが容易に認識でき、不正を防止することができる。

図１４は、顧客の各々に対応して予め割り当てられた受信用の電話番号を管理する電話番号割当テーブル７０２の例を示す図である。
電話番号割当テーブルには、顧客の各々に割り当てられた顧客ＩＤに対応して、予め割り当てられた受信用電話番号が保存されている。この電話番号は、顧客が予め紙などの媒体に記載して、顧客の取引相手に伝達してもよい。或いは、顧客装置１０２が事業者装置１０６にログインした際に、ログイン後の顧客装置１０２の画面に表示されるようにしてもよい。取引相手によってこの電話番号が、取引相手携帯端末１０４に入力されることで、取引相手携帯端末１０４から事業者装置１０６に電話が発信される。事業者装置１０６は、受けた着信した電話番号によって電話番号割当テーブル７０２を検索し顧客ＩＤを得ることで、いずれの顧客に対する取引相手の取引相手携帯端末１０４からの電話であるかを認識することができる。また、事業者装置１０６は、発信元電話番号により、取引相手携帯端末１０４を管理することができると共に、発信元電話番号宛に決済サービスを処理するＵＲＩを含むメッセージを送ることができる。

図１５は、決済サービス管理テーブル１５００の例を示す図である。
事業者装置１０６は、顧客装置１０２によって提供された課金及び第１の識別情報を含む情報に基づいて、決済サービスのエントリを、決済サービス管理テーブル１５００に生成する。
決済サービス管理テーブル１５００は、決済処理のステータス、第１の識別情報、課金額、決済サービス管理情報、決済サービスＵＲＩ、シンボル特定情報、発信元電話番号である取引相手携帯端末１０４の電話番号、過去にペアがキャンセルされた取引相手携帯端末１０４の電話番号などが記憶される。事業者装置１０６は、過去にペアがキャンセルされた取引相手携帯端末１０４の電話番号を記憶しておくことで、ペアとすべきでなかった取引相手携帯端末１０４を再度ペアにしてしまうことを避けることができる。
なお、決済サービス管理テーブル１５００には、各決済サービスのエントリの生成時刻が保存されてもよい。
また、シンボル特定情報は、シンボル特定情報に対応して、１つまたは複数のシンボルが割り当てられてもよい。シンボルは、上述したように、決裁サービス管理情報（決済結果など）を人間が識別しやすいように図形などで表現した情報である。

ステータス情報には、例えば以下のステータスが保存されてもよい。
ステータス１：取引相手携帯端末の割当不可（決済サービス開始済・完了済、決済サービス未割当時間切れ等）
ステータス２：取引相手携帯端末の割当可能（決済サービス開始前のため、取引相手携帯端末の再割り当ての可能性あり）
ステータス３：取引相手携帯端末の割当可能（取引相手携帯端末が未割当）
上記ステータス２の場合には、既に述べたようにペアが破棄された場合、ステータス３に変更されることが望ましい。

図１６は、取引相手携帯端末管理テーブル１６００の例を示す図である。
事業者装置１０６は、取引相手携帯端末１０４からの電話の着信によって得られた発信元電話番号、第２の識別情報を含む情報に基づいて、取引相手携帯端末１０４のエントリを、取引相手携帯端末管理テーブル１６００に生成する。
取引相手携帯端末管理テーブル１６００は、決済処理のステータス、着信時刻、発信元電話番号、第２の識別情報、決済サービス管理情報、メッセージ送信の有無、過去にペアがキャンセルされた決済サービスの管理情報などが記憶される。事業者装置１０６は、過去にペアがキャンセルされた決済サービスの管理情報を記憶しておくことで、ペアとすべきでなかった決済サービスを再度ペアにしてしまうことを避けることができる。
第２の識別情報には、例えば発信元電話番号の下４桁が格納されてもよい。なお、第２の識別情報は、上記の例に限られるものではない。
ステータス情報には、例えば以下のステータスが保存されてもよい。
ステータス１：決済サービス割当不可（決済サービス開始済・完了済、決済サービス未割当時間切れ等）
ステータス２：決済サービス割当可能（決済サービス開始前のため、決済サービス再割り当ての可能性あり）
ステータス３：決済サービス割当可能（決済サービスが未割当）
上記ステータス２の場合には、既に述べたようにペアが破棄された場合、ステータス３に変更されることが望ましい。

＜識別情報に用いることができる情報の例＞
（１）取引相手携帯端末１０４の電話番号の一部又は全部を識別情報に用いる。
この点については、上述の実施形態に記載した。顧客が、複数の決済サービスの取り扱いを並行して行わない場合には、取引相手携帯端末１０４の電話番号のうちの一部の情報（例えば、電話番号の末尾４桁）を識別情報とすることも可能である。なお、顧客にユニークに割り当てられた電話番号に、偶然に又は故意にかかってきた第三者からの通話の発信元電話番号の下４桁が、取引相手携帯端末１０４の電話番号の下４桁と一致する確率は、１万分の１程度であるから、十分実用に耐える識別情報であると判断できる。電話番号の桁数をより多くすることで、このような誤りの確率はさらに低くなる。取引相手携帯端末１０４の電話番号を識別情報に用いれば、このような誤りの発生する確率は、小さくなる。なお、このような誤りを未然に防止する確実性の担保の例としては、既に述べたように、管理情報及び決済結果を文字又はシンボル画像で画面に表示させることによって、容易にしかも確実に回避することができる。

上記の確実性の担保については、以下に示す例においても、同様に適用できる。
（２）決済サービスの各々に付与されたユニークな管理情報を識別情報に用いる。
この場合には、決済サービスごとにユニークに割り当てられた情報を識別情報に用いることができるため、原理的には、誤った決済サービスに対する処理が、取引相手携帯端末１０４によってなされることはない。しかしながら、管理情報の入力間違いが発生する可能性がある。この場合には、上記と同様に、確実性の担保を図ることが望ましい。
なお、管理情報は、上述の（２）の例においては、事業者装置１０６から顧客装置１０２に伝達されるため、顧客は顧客装置１０２に、識別情報（すなわち管理情報）を入力する手間が省けると共に、顧客装置１０２は、識別情報を事業者装置１０６に送信することを省くことができる。
顧客は、管理情報を取引相手に伝達し、取引相手は、電話をかけたのちに、ＩＶＲの指示などに基づき、キー入力などで、識別情報（すなわち管理番号）を入力するとよい。この場合には、取引相手の手間が増加する場合があるが、入力内容が正確であれば、確実性を容易に担保することができる。
なお、事業者装置１０６が生成するストリングを顧客装置１０２に送信して、このストリングを識別情報に用いてもよい。このストリングは、決済サービスを特定する管理情報と異なるものであってもよい。このストリングは、顧客装置１０２に表示され、取引相手携帯端末１０４に、顧客がキー入力するようにしてもよい。決済サービスを管理する情報は、桁数が長くなる場合がある。このため、識別情報に適した長さのストリングを事業者装置１０６が生成し、顧客装置１０２に伝達するようにしてもよい。あるいは、事業者装置が顧客装置に１桁毎にストリングを送り、そのストリングを顧客が取引相手に伝えて、取引相手のキー入力により、そのストリングの情報を事業者装置１０６に送るようにしてもよい。確認を取るこのストリングは、所定の時間の間において、重複しないユニークなストリングとすることで、ストリングの長さを短くすることができる。或いは、決済サービスの管理情報の一部の情報を識別情報に用いるようにしてもよい。

（３）顧客又は取引相手が自由に選んだランダムなストリングを識別情報に用いる。
この場合、一定の確率で、異なる決済サービス間で、識別情報が偶然に一致する場合が発生する。このため、上記と同様に、確実性を担保することが望ましい。なお、ストリングを口頭で顧客及び取引相手の間で伝える場合には、アルファベットよりも番号を用いることが望ましい。アルファベットは、聞き間違える確率が数字よりも高いからである。
なお、このストリングは、顧客装置１０２又は取引相手携帯端末１０４により生成されてもよい。

（４）上記の情報を複数組み合わせて、識別情報に用いる。
情報を組み合わせることで、識別情報のユニーク性は増すこととなる。その半面、識別情報の桁数が多くなるために、識別情報の入力負担が増し、利便性を犠牲にすることとなる場合もある。また、識別情報を口頭で伝達する場合には、伝達の際の誤りが発生する確率が高くなる。

＜識別情報の伝達方法＞
識別情報を口頭で共有する場合には、聞き間違えが発生する場合があるが、操作者が耳で聴きとって、キーを操作して入力することができるため、単純な作業であり、アプリケーション（たとえばＱＲコード（登録商標）読み取りソフトなど）を起動する手間が省けるというメリットがある。
逆に、ＱＲコード（登録商標）の読取あるいはネットワーク又は近距離無線通信を用いて識別情報の共有を行う場合には、識別情報の共有がより確実に行える。ただし、アプリケーションの起動を行う場合には、そのアプリケーションの起動が煩雑である場合がある。したがって、シンプルで簡単なＵＩを優先するのであれば、口頭で伝えた識別情報をキー入力させることが望ましい。逆に、確実に識別情報を共有させることに重点を置く場合には、電子的な手段により、識別情報を共有させることを選ぶこととしてもよい。

上記の実施形態では、シンボルを用いて、管理情報の一致などを人間が確認しやすくする例を示したが、シンボルを用いない他の実施形態を採用することも可能である。例えば、顧客装置１０２と、取引相手携帯端末１０４とが、事業者装置１０６を介して、音声通話、チャット、などの連絡が成功したことを確認できるようにすることで、顧客装置１０２の決済サービスと取引相手携帯端末１０４の決済サービスとの一致を確認できるようにしてもよい。
上記実施形態における決済サービスは、決済処理の一例である。顧客装置は、顧客の管理する装置の一例である。取引相手携帯端末は、取引相手の管理する携帯端末の一例である。

７０２ 電話番号割当テーブル
７０４ 顧客装置通信部
７０６ 取引相手携帯端末通信部
７０８ 決済業者装置通信部
７１０ 決済サービス制御部
７２０ 決済記憶部

Claims (12)

1. 顧客から前記顧客の取引相手への課金の決済処理を仲介する方法であって、
   前記顧客に対してユニークに割り当てられた電話番号が準備されており、
   前記課金を識別する第１の識別情報に関連付けられた前記課金の情報を、前記顧客の管理する装置から受け取るステップと、
   前記第１の識別情報と、前記課金の情報とを含む情報から、決済処理を特定するステップと、
   前記第１の識別情報と、前記取引相手の管理する携帯端末から前記電話番号に宛てた通信において伝達された第２の識別情報とを比較した比較結果に基づいて、前記顧客の管理する装置及び前記取引相手の管理する携帯端末に、前記決済処理に係るメッセージを送信するステップと、
   を有する決済を仲介する方法であって、
   前記決済処理に係るメッセージを送信するステップは、
   前記比較結果に基づいて、前記取引相手の管理する携帯端末が前記決済処理を取り扱うように、前記決済処理を扱うＵＲＩを含むメッセージを、前記通信の発信元電話番号に送信するステップと、
   前記決済処理に関する情報を、前記決済処理を実行するシステムに提供するステップと、
   前記取引相手の管理する携帯端末と前記決済処理を実行するシステムとの間でなされた前記決済処理の結果を、前記決済処理を実行するシステムから受信するステップと、
   前記決済処理の結果のメッセージを少なくとも前記顧客の管理する装置に伝達するステップと、
   を含む、
   決済を仲介する方法。
2. 前記第１の識別情報は、前記発信元電話番号の一部分を含む、
   請求項１に記載の決済を仲介する方法。
3. 前記第１の識別情報は、前記顧客又は前記取引相手によって指定された第１のストリングを含む、
   請求項１又は２に記載の決済を仲介する方法。
4. 前記第１の識別情報は、前記顧客の管理する装置により生成された第２のストリングを含む、
   請求項１ないし３のうちいずれか１項に記載の決済を仲介する方法。
5. 前記顧客の管理する前記装置に、第３のストリングを送信するステップを更に有し、
   前記第１の識別情報は、前記第３のストリングを含む、
   請求項１ないし４のうちいずれか１項に記載の決済を仲介する方法。
6. 前記メッセージは、ＳＭＳ、ＲＣＳ及びＭＭＳのうちのいずれかによって転送される、
   請求項１ないし５のうちいずれか１項に記載の決済を仲介する方法。
7. 前記通信は、音声通話又はＳＭＳ、ＲＣＳ若しくはＭＭＳによるメッセージ通信である、
   請求項１ないし６のうちいずれか１項に記載の決済を仲介する方法。
8. 前記決済処理を実行するシステムに提供するステップは、
   前記顧客の管理する装置からの指示を待って、前記決済処理に関する情報を、決済処理を実行するシステムに提供するステップ、
   を含む、請求項１ないし７のうちいずれか１項に記載の決済を仲介する方法。
9. 前記顧客の管理する装置が取り扱う前記決済処理が、前記取引相手の管理する携帯端末が取り扱う決済処理と同一の決済処理であることがわかるように、前記顧客の管理する装置及び前記取引相手の管理する携帯端末のうちの少なくともいずれか１つに、前記決済処理を識別する情報を送信するステップ、
   を更に有する、請求項１ないし８のうちいずれか１項に記載の決済を仲介する方法。
10. 前記決済処理を識別する情報は、前記決済処理に割り当てられたシンボルの情報である、
    請求項９に記載の決済を仲介する方法。
11. 前記シンボルの情報は、
    前記決済処理の結果が完了したか又は未決済で終了したかに応じて、それぞれ異なる第２のシンボルの情報又は第３のシンボルの情報を含む、
    請求項１０に記載の決済を仲介する方法。
12. 請求項１ないし１１のうちいずれか１項に記載の決済を仲介する方法をコンピュータに実行させるプログラム。

Images