JP2020004304A - 情報処理方法 - Google Patents

Abstract

【課題】専用アプリのインストールが不要で、個人情報の保護が可能で、国内外のＮＦＣ決済端末の規格の違いによる弊害を解消可能な情報処理方法（決済方法）を提供する。【解決手段】店舗において商品を購入し又は役務の提供を受ける場合、ＵＲＬ情報を含む二次元コードを携帯端末が読み取る。携帯端末が二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバーにアクセスし、ウェブページに含まれる決済仲介用情報を受信し、決済仲介サーバーから受信した選択可能な支払い手段を表示する。ユーザによる支払い手段の選択を受け付け、選択された支払手段に対し、ユーザをの識別情報を送信し、選択された支払い手段による支払いを指示する。支払い指示に基づいて、前記識別情報による支払い名義に対し決済処理をリクエストし、リクエストに基づいて、決済サーバーが決済を実行する。【選択図】図２

Description

本発明は、商品を購入し又は役務の提供を受ける場合に、二次元コードと携帯端末を利用して代金の支払いを実行するための情報処理方法（決済方法）に関するものである。

スマートフォンを利用した決済方法が種々提案されているが、これまで提案されてきた決済方法には次のような問題があった。

・決済専用のアプリケーションのインストールが面倒である。
・決済専用のアプリケーションの設定に個人情報の入力が必要であり、その入力が煩雑で、しかも、入力した個人情報が洩れて悪用される危険性がある。
・店舗等に個人情報が洩れて悪用される危険性がある。
・国内外のNFC決済端末の規格の違いによる弊害がある。

そこで上述した従来技術の問題点に鑑み、この出願の発明の目的は、
・決済専用のアプリケーションのインストールが不要で、
・個人情報の保護が可能で、
・国内外のNFC決済端末の規格の違いによる弊害を解消可能な
新たな情報処理方法（決済方法）を提供することにある。

上記目的は、
店舗において商品を購入し又は役務の提供を受ける場合に、携帯端末を利用して代金の支払いを実行するための方法であって、
(a) ＵＲＬ情報（ウェブサイトのアドレス情報）を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
(b) 二次元コードを読み取った携帯端末がその読み取り完了と同時にウェブブラウザを自動的に起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバー（第１のサーバー）にアクセスするステップと、
(c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記ウェブページに含まれる決済仲介用情報を受信するステップと、
(d) 決済仲介サーバーから受信した前記決済仲介用情報には、携帯端末のユーザが選択可能な支払い手段が少なくとも一つ含まれており、携帯端末がウェブブラウザ上に前記決済仲介用情報を表示するステップと、
(e) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
(f) ユーザによって選択された支払手段に対応する決済代行サーバー（第２のサーバー）に対し、携帯端末が、当該携帯端末のユーザを識別するための識別情報を送信するステップと、
(g) 携帯端末が前記決済代行サーバーに対し、選択された支払い手段による支払い（決済代行）をリクエストするステップと、
(h) 携帯端末からの支払いのリクエスト（決済代行のリクエスト）に基づいて、決済代行サーバーが決済サーバー（第３のサーバー）に対し、前記識別情報によって識別される個人又は法人を支払い名義とする決済処理をリクエストするステップと、
(i) 決済代行サーバーからのリクエストに基づいて、決済サーバーが決済を実行するステップと、
を含む情報処理方法によって達成される。

また上記目的は、
店舗において商品を購入し又は役務の提供を受ける場合に、携帯端末を利用して代金の支払いを実行するための方法であって、
(a) ＵＲＬ情報（ウェブサイトのアドレス情報）を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
(b) 二次元コードを読み取った携帯端末がその読み取り完了と同時にウェブブラウザを自動的に起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバー（第１のサーバー）にアクセスするステップと、
(c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記ウェブページに含まれる決済仲介用情報を受信するステップと、
(d1) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、前記商品又は前記役務の対価として支払う金額を入力可能な金額入力欄（金額入力用ボックス）を表示するステップと、
(d2) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、携帯端末のユーザが選択可能な少なくとも一つの支払い手段を表示するステップと、
(e1) 携帯端末が、ユーザによる金額入力欄への金額の入力を受け付けるステップと、
(e2) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
(f) ユーザによって選択された支払手段に対応する決済代行サーバー（第２のサーバー）に対し、携帯端末が、当該携帯端末のユーザを識別するための識別情報を送信するステップと、
(g) 携帯端末が前記決済代行サーバーに対し、選択された支払い手段による入力額の支払い（決済代行）をリクエストするステップと、
(h) 携帯端末からの支払いのリクエスト（決済代行のリクエスト）に基づいて、決済代行サーバーが決済サーバー（第３のサーバー）に対し、前記識別情報によって識別される個人又は法人を支払い名義とする決済処理をリクエストするステップと、
(i) 決済代行サーバーからのリクエストに基づいて、決済サーバーが決済を実行するステップと、
を含む情報処理方法によって達成される。

また上記目的は、
店舗において商品を購入し又は役務の提供を受ける場合に、携帯端末を利用して代金の支払いを実行するための方法であって、
(a) ＵＲＬ情報（ウェブサイトのアドレス情報）を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
(b) 二次元コードを読み取った携帯端末がその読み取り完了と同時にウェブブラウザを自動的に起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバー（第１のサーバー）にアクセスするステップと、
(c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記ウェブページに含まれる決済仲介用情報を受信するステップと、
(d) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、前記商品又は前記役務の対価として支払う金額を入力可能な金額入力欄（金額入力用ボックス）と、携帯端末のユーザが選択可能な少なくとも一つの支払い手段を表示するステップと、
(e1) 携帯端末が、ユーザによる金額入力欄への金額の入力を受け付けるステップと、
(e2) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
(f) ユーザによって選択された支払手段に対応する決済代行サーバー（第２のサーバー）に対し、携帯端末が、当該携帯端末のユーザを識別するための識別情報を送信するステップと、
(g) 携帯端末が前記決済代行サーバーに対し、選択された支払い手段による入力額の支払い（決済代行）をリクエストするステップと、
(h) 携帯端末からの支払いのリクエスト（決済代行のリクエスト）に基づいて、決済代行サーバーが決済サーバー（第３のサーバー）に対し、前記識別情報によって識別される個人又は法人を支払い名義とする決済処理をリクエストするステップと、
(i) 決済代行サーバーからのリクエストに基づいて、決済サーバーが決済を実行するステップと、
を含む情報処理方法によって達成される。

また上記目的は、
店舗において商品を購入し又は役務の提供を受ける場合に、携帯端末を利用して代金の支払いを実行するための方法であって、
(a) ＵＲＬ情報（ウェブサイトのアドレス情報）を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
(b) 二次元コードを読み取った携帯端末がその読み取り完了と同時にウェブブラウザを自動的に起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバー（第１のサーバー）にアクセスするステップと、
(c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記ウェブページに含まれる決済仲介用情報を受信するステップと、
(d1) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、前記商品又は前記役務の対価として支払う金額を表示するステップと、
(d2) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、携帯端末のユーザが選択可能な少なくとも一つの支払い手段を表示するステップと、
(e) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
(f) ユーザによって選択された支払手段に対応する決済代行サーバー（第２のサーバー）に対し、携帯端末が、当該携帯端末のユーザを識別するための識別情報を送信するステップと、
(g) 携帯端末が前記決済代行サーバーに対し、選択された支払い手段による代金の支払い（決済代行）をリクエストするステップと、
(h) 携帯端末からの支払いのリクエスト（決済代行のリクエスト）に基づいて、決済代行サーバーが決済サーバー（第３のサーバー）に対し、前記識別情報によって識別される個人又は法人を支払い名義とする決済処理をリクエストするステップと、
(i) 決済代行サーバーからのリクエストに基づいて、決済サーバーが決済を実行するステップと、
を含む情報処理方法によって達成される。

また上記目的は、
店舗において商品を購入し又は役務の提供を受ける場合に、携帯端末を利用して代金の支払いを実行するための方法であって、
(a) ＵＲＬ情報（ウェブサイトのアドレス情報）を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
(b) 二次元コードを読み取った携帯端末がその読み取り完了と同時にウェブブラウザを自動的に起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバー（第１のサーバー）にアクセスするステップと、
(c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記ウェブページに含まれる決済仲介用情報を受信するステップと、
(d) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、前記商品又は前記役務の対価として支払う金額と、携帯端末のユーザが選択可能な少なくとも一つの支払い手段を表示するステップと、
(e) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
(f) ユーザによって選択された支払手段に対応する決済代行サーバー（第２のサーバー）に対し、携帯端末が、当該携帯端末のユーザを識別するための識別情報を送信するステップと、
(g) 携帯端末が前記決済代行サーバーに対し、選択された支払い手段による代金の支払い（決済代行）をリクエストするステップと、
(h) 携帯端末からの支払いの指示（決済代行のリクエスト）に基づいて、決済代行サーバーが決済サーバー（第３のサーバー）に対し、前記識別情報によって識別される個人又は法人を支払い名義とする決済処理をリクエストするステップと、
(i) 決済代行サーバーからのリクエストに基づいて、決済サーバーが決済を実行するステップと、
を含む情報処理方法によって達成される。

上記情報処理方法では、携帯端末が二次元コードの読み取りを完了すると、該携帯端末は、前記ステップ(b),(c),(d)の一連の処理を自動的に実行する。

また、上記情報処理方法のステップ(c)において、携帯端末が決済仲介サーバーから受信する決済仲介用情報には、携帯端末のユーザが選択可能な支払い手段を携帯端末に表示させるための基準金額情報（仮の金額）が含まれている。
そして、ステップ(d2)において、前記基準金額情報（仮の金額）に基づいて、携帯端末のユーザが選択可能な少なくとも一つの支払い手段（基準金額情報に対応した支払い手段）を表示する。

また、上記情報処理方法の前記ステップ(d)において、
決済仲介サーバーから受信した前記決済仲介用情報には、携帯端末のユーザが選択可能な支払い手段が複数含まれており、携帯端末がウェブブラウザ上に前記決済仲介用情報を表示する。

また、上記情報処理方法のステップ(d)において、
携帯端末は、ウェブブラウザ上に、支払い手段を選択可能に表示する。

また、上記情報処理方法のステップ(c)において、携帯端末が決済仲介サーバーから受信する決済仲介用情報には、少なくとも、
・商品または役務に関する説明、
・ユーザが選択可能な少なくとも１つの支払手段、
・支払い金額
が含まれる。

また、上記情報処理方法のステップ(c)において、携帯端末が決済仲介サーバーから受信する決済仲介用情報には、少なくとも、
・商品または役務に関する説明、
・ユーザが選択可能な少なくとも１つの支払手段、
・ユーザが金額を入力可能な金額入力欄（金額入力用ボックス）
が含まれる。

また、上記情報処理方法のステップ(e1)において、ユーザによる金額入力欄への支払金額の入力を受け付けると、
前記ステップ(d2)において表示した支払い手段の変わりに、
前記入力された支払金額に基づいて、携帯端末のユーザが選択可能な少なくとも一つの支払い手段（入力された支払金額に対応した専用の支払い手段）をあらたに表示する。

また、上記情報処理方法のステップ(d)において、
携帯端末がウェブブラウザ上に表示する
金額入力欄（金額入力用ボックス）と、
少なくとも一つの支払い手段は、
画面を遷移させることなく、同一のページ内にすべて表示される。

また、上記情報処理方法のステップ(d)において、
携帯端末がウェブブラウザ上に表示する
金額入力欄（金額入力用ボックス）と、
少なくとも一つの支払い手段は、
同一の画面、または、同一のウェブページ内に、または、同一のＵＲＬのウェブページ内にすべて表示される。

また、上記情報処理方法のステップ(d)において、
携帯端末がウェブブラウザ上に表示する
支払う金額と、
少なくとも一つの支払い手段は、
画面を遷移させることなく、同一のページ内にすべて表示される。

また、上記情報処理方法のステップ(d)において、
携帯端末がウェブブラウザ上に表示する
支払う金額と、
少なくとも一つの支払い手段は、
同一の画面、または、同一のウェブページ内に、または、同一のＵＲＬのウェブページ内にすべて表示される。

・決済専用のアプリケーションのインストールが不要である。
・複数の支払い手段の中から適切なものを選択することができる。
・店舗及び、決済仲介会社が個人情報を保有しないので、個人情報を保護することができる。
・国内外のNFC決済端末の規格の違いによる弊害を解消することができる。
・画面の遷移による機会損失（離脱）を防ぐことができる。

具体的には以下のとおりである。

携帯端末を利用して支払を実行するにあたって、該携帯端末は、二次元コードを読み取るカメラと、ウェブブラウザと、インターネットにアクセス可能な通信機能を備えていれば足りる。これらの機能は、携帯端末が工場出荷時の状態で具備している。したがって、決済専用のアプリケーションのインストールが不要である。なお、ウェブブラウザについては、携帯端末に新たにインストールしたものを使うこともできる。

例えば Apple Pay や Google Pay などの複数の支払い手段（支払先）が用意されているので、利用者は、複数の支払い手段のなかから適切なものを選ぶことができる。

携帯端末を利用した支払いにおいて、店舗や決済仲介会社（決済仲介サーバーの運営者）に、住所、氏名、電話番号、クレジットカード番号などの個人情報を開示する必要がない。したがって、個人情報を保護することができる。

携帯端末を利用した支払いにおいて、ＮＦＣなどの近距離無線通信を一切利用しない。したがって、国内外のＮＦＣ決済端末の規格の違いによる弊害を解消することが可能である。

携帯端末がウェブブラウザ上に表示する金額入力欄（または支払い額）と支払い手段は、同一の画面内にすべて表示されるので、画面の遷移による機会損失（離脱）を防ぐことができる。

本発明の実施形態（第１の実施形態）の概要を示す図である。 本発明の実施形態（第１の実施形態）における携帯端末の画面遷移を示す図である。 本発明の実施形態（第１の実施形態）における情報処理の流れを示すフローチャートである。 本発明の実施形態（第２の実施形態）の概要を示す図である。 本発明の実施形態（第２の実施形態）における携帯端末の画面遷移を示す図である。 本発明の実施形態（第２の実施形態）における情報処理の流れを示すフローチャートである。 支払い手段の一例であるApple Pay の仕組み（Apple Payでバーチャルカードが発行される仕組み）の概要を示す図である。

（情報処理方法で利用するシステム構成等の概要）
本発明に係る情報処理方法は、店舗において商品を購入し又は役務の提供を受ける場合に、携帯端末と二次元コードを利用して代金の支払いを実行するための方法である。

ここでいう「店舗」には、例えば、
・店員がいる実店舗、
・店員が不在の実店舗、
・企業や個人宅に仮設された仮店舗（置き菓子や置きクスリなどを揃えた出張店舗）
などが含まれる。

この情報処理方法の実施には、
・インターネットと、
・携帯端末と、
・第１のサーバーである決済仲介サーバーと、
・第１のサーバーとは異なる第２のサーバーである決済代行サーバーと、
・第１及び第２のサーバーとは異なる第３のサーバーである決済サーバーと、
を用いる。

携帯端末は、インターネットにアクセス可能な無線通信機能を備えた携帯型の情報端末であって、具体例として、スマートフォン、タブレット端末、携帯電話などが挙げられる。後述する実施形態では、携帯端末としてスマートフォンを利用している。

携帯端末は、主として、
・インターネットにアクセス可能な通信部と、
・ＱＲコード（登録商標）などの二次元コードを読み取る際に利用するカメラと、
・ウェブブラウザ等のソフトウェアを格納するストレージと、
・ウェブページ等の各種情報を表示するための表示部（タッチスクリーンを具備するディスプレイ）、
・上記各部を制御し、後述するステップを実行するためのプロセッサ、などを具備している。

決済仲介サーバー（第１のサーバー）は、決済仲介業者が運営するサーバー装置である。決済代行サーバー（第２のサーバー）は、決済代行業者が運営するサーバー装置である。決済サーバー（第３のサーバー）は、決済業者が運営するサーバー装置である。
これらのサーバー装置は、インターネットにアクセス可能な通信部を有している。

「決済仲介業者」とは、データの形式を変換する事などにより、決済代行業者と加盟店の間のデータのやりとりを仲介し、利用者が決済サービスを円滑に使用できるようにするための媒介機能、操作手順、インタフェイスの提供を担う業者である。ただし、決済仲介業者の契約内容が統一されているわけではないため、あくまで一つの事例としての説明となる。

「決済代行業者」とは、下記の加盟店業務を代理する権利を決済業者から与えられている加盟店の代理業者である。ただし、決済代行業者の契約内容が統一されているわけではないため、あくまで一つの事例としての説明となる。 (1) 信用販売の申込み受付け (2) 加盟店に関する届け出 (3) 加盟店の申請 (4) 売上承認の取得(5) 売上請求に関する事項 (6) その他、決済代行事業者および加盟店が合意し、決済会社が承認した業務。

「決済業者」とは、与信処理を行って利用者のカード利用可能枠を確保、その後売上確定処理をすることで決済を完了させ、販売代金の請求および支払いを担う業者である。ただし、決済業者の契約内容が統一されているわけではないため、あくまで一つの事例としての説明となる。

（情報処理方法の概要）
本発明に係る情報処理方法は、店舗において商品を購入し又は役務の提供を受ける場合に、携帯端末を利用して代金の支払いを実行するための方法であって、
(a) ＵＲＬ情報（ウェブサイトのアドレス情報）を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
(b) 二次元コードを読み取った携帯端末がその読み取り完了と同時にウェブブラウザを自動的に起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバー（第１のサーバー）にアクセスするステップと、
(c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記ウェブページに含まれる決済仲介用情報を受信するステップと、
(d) 決済仲介サーバーから受信した前記決済仲介用情報には、携帯端末のユーザが選択可能な支払い手段が少なくとも一つ含まれており、携帯端末がウェブブラウザ上に前記決済仲介用情報を表示するステップと、
(e) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
(f) ユーザによって選択された支払手段に対応する決済代行サーバー（第２のサーバー）に対し、携帯端末が、当該携帯端末のユーザを識別するための識別情報を送信するステップと、
(g) 携帯端末が前記決済代行サーバーに対し、選択された支払い手段による支払い（決済代行）をリクエストするステップと、
(h) 携帯端末からの支払いのリクエスト（決済代行のリクエスト）に基づいて、決済代行サーバーが決済サーバー（第３のサーバー）に対し、前記識別情報によって識別される個人又は法人を支払い名義とする決済処理をリクエストするステップと、
(i) 決済代行サーバーからのリクエストに基づいて、決済サーバーが決済を実行するステップと、
を含んでいる。

携帯端末が二次元コードの読み取りを完了すると、該携帯端末は、前記ステップ(b),(c),(d)の一連の処理を自動的に実行する。つまり、携帯端末のユーザが、該携帯端末のカメラを二次元コードに翳すだけで、携帯端末は、前記ステップ(a),(b),(c),(d)の一連の処理を自動的に実行することになる。したがって、ユーザは、煩わしい操作を一切行うことなく、「支払手段の選択」まで自動的に辿り着けることができるので、簡単かつ確実に支払い処理を進めることができる。

ウェブブラウザは、携帯端末が工場出荷時の状態で具備している、インターネット上のウェブサイトを閲覧するためのソフトウェア（アプリケーション）である。
カメラは、携帯端末が工場出荷時の状態で具備している機能である。
カメラを利用して二次元コードを読み取る機能は、携帯端末が工場出荷時の状態で具備している機能である。
すなわち、携帯端末は、本発明を実施するのに必要な機能を、（専用のアプリ等をインストールすることなく）工場出荷時の状態で初めから備えている。
ただし、本発明を実施するにあたって、ウェブブラウザや、二次元コードを読み取るためのアプリケーションなどは、新たに携帯端末にインストールしたものを使ってもよい。

二次元コードに含まれるＵＲＬ情報は、ウェブサイトのアドレス情報であって、例えば、次のいずれかのユニークＵＲＬで構成されている。
(1) 商品又は役務を提供する事業者ごとに割り当てられたユニークＵＲＬ。
(2) 商品又は役務を提供する店舗ごとに割り当てられたユニークＵＲＬ。
(3) 店舗で提供する商品ごとに割り当てられたユニークＵＲＬ。
(4) 店舗で提供する役務ごとに割り当てられたユニークＵＲＬ。

二次元コードの具体例としては、ＱＲコード（登録商標）が挙げられる。

前記ステップ(d)において、決済仲介サーバーから受信した決済仲介用情報には、携帯端末のユーザが選択可能な支払い手段が複数含まれており、携帯端末がウェブブラウザ上に前記決済仲介用情報を表示する。つまり、携帯端末が、ウェブブラウザ上に、支払い手段を選択可能に表示する。
このように、支払手段に複数の選択肢があることで、より多くの者が、本発明を利用して支払いを行うことができるようになる。

後述する第１実施形態の場合、前記ステップ(c)において、携帯端末が決済仲介サーバーから受信する決済仲介用情報には、少なくとも、
・商品または役務に関する説明に関する情報、
・ユーザが選択可能な少なくとも１つの支払手段に関する情報、
・ユーザが金額を入力可能な金額入力欄（金額入力用ボックス）に関する情報
が含まれる。

後述する第２実施形態の場合、前記ステップ(c)において、携帯端末が決済仲介サーバーから受信する決済仲介用情報には、少なくとも、
・商品または役務に関する情報、
・ユーザが選択可能な少なくとも１つの支払手段に関する情報、
・支払い金額に関する情報
が含まれる。

（情報処理方法の第１実施形態）
情報処理方法の第１実施形態は、店舗において役務の提供（例えば飲食物の提供）を受ける場合に、携帯端末と二次元コードを利用して代金の支払いを実行するための方法に関するものである。本実施形態では、役務の提供に対する金額として5,000円を支払う場合を想定している。5,000円は支払い金額の一例であり、役務の種類や内容などによって支払金額が異なることは言うまでもない。

第１実施形態に係る情報処理方法の流れを、図１〜図３に基づいて説明する。

飲食店等の店舗において役務の提供を受けたユーザ（携帯端末のユーザ）は、当該店舗に設置されたレジ３において、その役務の代金を支払う。その店舗内のレジ横には、ＵＲＬ情報（ウェブサイトのアドレス情報）を含む決済用の二次元コード５が表示されている。図１参照。

二次元コードに含まれるＵＲＬ情報は、例えば、当該店舗で提供する役務ごとに割り当てられたユニークＵＲＬで構成されている。つまり、当該店舗で提供可能な役務ごとに、異なる二次元コード（異なるＵＲＬ情報）が割り当てられている。

なお、本実施形態では、図１に例示するように二次元コードを店舗内のレジ横に表示しているが、二次元コードの表示場所は特に限定されず、店舗のどこに表示されていてもよい。つまり、レジが具備するディスプレイや、店舗に置かれたメニュー表などに、二次元コードを表示させることも可能である。

本実施形態の情報処理方法に従って支払を行う場合には、はじめに図１及び図２(a)に示すように、レジ横に表示された二次元コード５を携帯端末７で読み取る。図３のステップS101。この読み取りの際には、携帯端末のカメラ機能（カメラ・アプリケーション）をあらかじめ起動させておき、そのカメラレンズを読み取り対象の二次元コードに向ける。なお、本実施形態で利用する携帯端末は、スマートフォンで構成されている。

ステップS101において二次元コード５を読み取った携帯端末７は、その読み取り完了と同時にウェブブラウザを自動的に起動させ、さらに、二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバーに自動的にアクセスする。図３のステップS103。

ＵＲＬ情報に対応するウェブページには「決済仲介用情報」が含まれている。したがって、携帯端末は決済仲介サーバーにアクセスすると同時に、当該決済仲介サーバーから、ウェブページに含まれる決済仲介用情報を受信する。図３のステップS105。

なお、このステップにおいて、携帯端末が決済仲介サーバーから受信する「決済仲介用情報」には、
・ ユーザが利用した役務に関する情報、
・ ユーザが選択可能な複数の支払手段に関する情報、
・ ユーザが金額を入力可能な金額入力欄（金額入力用ボックス）に関する情報、
・ 携帯端末のユーザが選択可能な支払い手段を携帯端末に表示させるための「基準金額情報（仮の金額）」、
などが含まれている。

「基準金額情報」は、図２(b)に示すように、選択可能な支払い手段１５を携帯端末に表示させるための仮の金額に関する情報である。この「基準金額情報」が在ることによって、図２(b)に示すように支払い手段１５（支払い方法を示すボタン画像）を携帯端末に表示させることができる。
「基準金額情報」を構成する金額は、実際に支払う金額ではないので、特に限定されずいかなる額でもよい。例えば、設定可能な最低額を基準金額としてもよい。本実施形態では、「基準金額情報」を構成する金額の一例として50円を想定している。
「基準金額情報」を構成する金額は、実際に支払う金額ではないので、基準金額情報（本実施形態の場合では50円）は、携帯端末には表示されない。したがって、図２(b)に示す実施形態では、金額入力欄１３（金額入力用ボックス）には、基準金額情報（本実施形態の場合では50円）が表示されていない。
ただし、基準金額情報（本実施形態の場合では50円）を金額入力欄１３に表示させてもよい。この場合には、表示された基準金額情報を支払金額に変更することを促すメッセージを表示させる。

続いて携帯端末は、決済仲介サーバーから受信した決済仲介用情報に基づいて、図２(b)に示すようにウェブブラウザ上に、ユーザが利用した役務に関する説明１１を表示する。図３のステップS107。

またステップS107において携帯端末は、決済仲介サーバーから受信した決済仲介用情報に基づいて、図２(b)に示すようにウェブブラウザ上に、役務の対価として支払う金額を入力可能な金額入力欄１３（金額入力用ボックス）を表示する。図３のステップS107。

またステップS107において携帯端末は、決済仲介サーバーから受信した決済仲介用情報に基づいて、図２(b)に示すようにウェブブラウザ上に、携帯端末のユーザが選択可能な複数の支払い手段１５を表示する。図３のステップS107。
具体的には、決済仲介サーバーから受信した決済仲介用情報に含まれる「基準金額情報（仮の金額）」に基づいて、携帯端末のユーザが選択可能な複数の支払い手段１５（基準金額情報に対応した支払い手段）を表示する。
本実施形態の場合では、図２(b)に示すようにウェブブラウザ上に、携帯端末のユーザが選択可能な４種の支払い手段１５が表示される。支払い手段１５は、携帯端末の画面上（ウェブブラウザ上）に、支払い方法を示すボタン画像の形態で表示される。支払い手段を示す各ボタン画像はタッチ操作によって選択することができる。
選択可能な複数の支払い手段１５には、図２(b)に例示するように、例えば「Apple Pay」、「Google Pay」、「Alipay」、「銀行口座引き落とし」などが含まれる。これらの一つ一つが支払い手段を構成する。

以上説明したとおり、本実施形態では、決済仲介サーバーから受信した決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、次の情報を表示する。
・ ユーザが利用した役務に関する説明１１。
・ 役務の対価として支払う金額を入力可能な金額入力欄１３（金額入力用ボックス）。
・ 携帯端末のユーザが選択可能な支払い手段１５。

これらの情報は、図２(b)に示すとおり、画面を遷移させることなく、同一のページ内にすべて表示される。つまり、同一の画面、別言すれば、同一のウェブページ内に（同一のＵＲＬのウェブページ内に）すべて表示される。このように、決済に最低限必要なすべての情報を同一のページ内にまとめて表示することで、（必要な情報を得るための）煩わしい画面遷移操作が一切不要になるので、必要な情報を探し回る必要が無い。したがって、滞りなく速やかに、決済処理を進めることができる。また、画面の遷移による機会損失（離脱）を防ぐことができる。

なお、ステップS101において携帯端末７が二次元コード５の読み取りを完了すると、該携帯端末は、以後のステップ S103 - S107 の一連の処理をすべて自動的に実行する。したがって、カメラを起動させた状態の携帯端末７を、二次元コード５の前に翳せば、あとは、図２(b)に示すような情報が携帯端末７に自動的に表示されることになる。

次に携帯端末は、ユーザによる金額入力欄１３への金額の入力を受け付ける。図３のステップS109。ユーザによる金額の入力は、例えば、携帯端末が具備するタッチスクリーンやソフトウェア・キーボードなどを利用して行われる。このように、本実施形態では、携帯端末のユーザが自己の操作によって、店舗に支払う金額を入力するようになっている。これにより、利用客によって支払金額が様々である飲食店などにおいても、本発明を利用して簡単に支払いを行うことができるようになる。
図３(c)に例示する実施形態では、ユーザが「金額入力欄１３」に金額として5,000円を入力し、続いて、「完了ボタン１７」をタッチすることによって、当該金額（5,000円）の受け付けが行われる。完了ボタン１７は、入力金額を確定させる役割を担っている。なお、完了ボタン１７をタッチする前に、金額入力欄１３への入力金額に誤りが無いか、店員が目視で確認してもよい。また、入力金額が誤っている場合には、店員がユーザに対し、入力金額の訂正を指摘してもよい。
上記のとおり完了ボタン１７をタッチすることによって、携帯端末がユーザによる金額入力欄への支払金額の入力を受け付けると、
ステップS107において表示した支払い手段１５の変わりに、
前記入力された支払金額に基づいて、携帯端末のユーザが選択可能な支払い手段１６（入力された支払金額に対応した専用の支払い手段）をあらたに表示する。
図３のステップS109, S111。
つまり、図２(b)(c)に表示する画面では、決済仲介サーバーから受信した決済仲介用情報に含まれる基準金額情報（一例として50円）に基づいて、当該基準金額情報（50円）に対応した専用の支払い手段１５が表示されている。そして、携帯端末がユーザによる金額入力欄１３への支払金額（5,000円）の入力を受け付けると、図２(b)(c)で表示していた支払い手段１５の変わりに、図２(d)に示すように、前記入力された支払金額（5,000円）に基づいて、当該支払金額（5,000円）に対応した専用の支払い手段１６をあらたに表示する。
したがって、携帯端末が金額の入力を受け付けると、携帯端末の画面は図２(c)から図２(d)に遷移し、「基準金額情報（仮の金額）」はその役目を終える。図３のステップS111。
なお、図２(b)(c)の画面で表示される支払い手段１５は、基準金額情報（一例として50円）に対応しているのに対し、
図２(d)の画面で表示される支払い手段１６は、入力された支払金額（5,000円）に対応しているので、
両者（支払い手段１５，１６）は機能的に異なるものであるが、
両者の外観（ボタン画像の外観）は変化させることなく同一であってもよい。

次に携帯端末は、ユーザによる支払い手段１６の選択を受け付ける。図３のステップS113。ユーザによる支払い手段１６の選択は、図２(d)に示すように、携帯端末が具備するタッチスクリーンを利用して行われる。
なお、図２(d)に示す実施形態では、ユーザの操作指によるタッチ操作によって、支払手段として「Apple Pay」が選択されている。

次に携帯端末は、ユーザによって選択された支払手段に対応する決済代行サーバーに対し、当該携帯端末のユーザを識別するための識別情報を送信するとともに、本人認証をリクエストする。図３のステップS115。
例えば、図２(d)に示すように、ユーザのタッチ操作によって、支払手段として「Apple Pay」が選択された場合には、「Apple Pay」に対応する決済代行サーバーに対し識別情報を送信するとともに、本人認証をリクエストする。

続いて、決済代行サーバーは、携帯端末からのリクエストに基づいて、本人認証を実行し、その結果を当該携帯端末に送信する。図３のステップS117。

そして、決済代行サーバーから認証結果を受信すると、携帯端末は図２(e)に示すように、決済の承認待ちの状態でスタンバイする。図３のステップS119。

次に携帯端末は、ユーザが決済承認を行うことによって支払を許可すると、それに応じて、決済代行サーバーに対し、選択された支払い手段による入力額の支払い（すなわち決済代行）をリクエストする。図３のステップS121, S123。
なお、図２(e)に示す実施形態では、ユーザによる決済承認のための手段として、物理ボタンのダブルクリックを採用しているが、決済承認の手段はこれに限定されない。

そして、携帯端末からの支払いのリクエスト（決済代行のリクエスト）に基づいて、決済代行サーバーが決済サーバーに対し、前記識別情報によって識別される個人又は法人を支払い名義とする決済処理をリクエストする。図３のステップS125, S127。

続いて、決済代行サーバーからのリクエストに基づいて、決済サーバーが決済を実行する。図３のステップS129。

決済サーバーにおいて決済処理が完了すると、決済サーバーから決済代行サーバーに対し決済処理の結果が送信され、さらに、決済代行サーバーから携帯端末に対し決済処理の結果が送信される。図３のステップS131, S133。

携帯端末では、決済代行サーバーから受信した決済処理の結果に基づいて、支払完了を画面に表示する。図３のステップS135。

（情報処理方法の第２実施形態）
情報処理方法の第２実施形態は、店舗において商品を購入する場合に、携帯端末と二次元コードを利用して代金の支払いを実行するための方法に関するものである。本実施形態では、商品購入の代金として300円を支払う場合を想定している。300円は購入代金の一例であり、商品の種類や内容などによって購入代金が異なることは言うまでもない。

第２実施形態に係る情報処理方法の流れを、図４〜図６に基づいて説明する。

図４に示すとおり、ユーザ（携帯端末のユーザ）が購入しようとする商品４には、ＵＲＬ情報（ウェブサイトのアドレス情報）を含む決済用の二次元コード５が表示されている。本実施形態の場合では、二次元コード５は、一例として商品４の外箱に表示されている。

二次元コードに含まれるＵＲＬ情報は、例えば、商品ごとに割り当てられたユニークＵＲＬで構成されている。つまり、店舗で購入可能な商品ごとに、異なる二次元コード（異なるＵＲＬ情報）が割り当てられている。

本実施形態の情報処理方法に従って支払を行う場合には、はじめに図４及び図５(a)に示すように、商品に表示された二次元コード５を携帯端末７で読み取る。図６のステップS201。この読み取りの際には、携帯端末のカメラ機能（カメラ・アプリケーション）をあらかじめ起動させておき、そのカメラレンズを読み取り対象の二次元コードに向ける。なお、本実施形態で利用する携帯端末は、スマートフォンで構成されている。

ステップS201において二次元コード５を読み取った携帯端末７は、その読み取り完了と同時にウェブブラウザを自動的に起動させ、さらに、二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバーに自動的にアクセスする。図６のステップS203。

ＵＲＬ情報に対応するウェブページには「決済仲介用情報」が含まれている。したがって、携帯端末は決済仲介サーバーにアクセスすると同時に、当該決済仲介サーバーから、ウェブページに含まれる決済仲介用情報を受信する。図６のステップS205。

なお、このステップにおいて、携帯端末が決済仲介サーバーから受信する「決済仲介用情報」には、
・ ユーザが購入する商品に関する情報、
・ ユーザが選択可能な複数の支払手段に関する情報、
・ 商品の対価として支払う金額（金額表示ボックス）に関する情報、
などが含まれている。

続いて携帯端末は、決済仲介サーバーから受信した決済仲介用情報に基づいて、図５(b)に示すようにウェブブラウザ上に、ユーザが購入する商品に関する説明１１を表示する。図６のステップS207。

またステップS207において携帯端末は、決済仲介サーバーから受信した決済仲介用情報に基づいて、図５(b)に示すようにウェブブラウザ上に、商品の対価として支払う金額１４（金額表示ボックス）を表示する。図６のステップS207。
なお、前述した第１実施形態では、支払金額をユーザが自分で入力するのに対し、第２実施形態では、（ユーザが入力するのではなく）支払金額が変更不可能な状態ではじめから設定されている。

またステップS207において携帯端末は、決済仲介サーバーから受信した決済仲介用情報に基づいて、図５(b)に示すようにウェブブラウザ上に、携帯端末のユーザが選択可能な複数の支払い手段１５を表示する。図６のステップS207。
本実施形態の場合では、図５(b)に示すようにウェブブラウザ上に、携帯端末のユーザが選択可能な４種の支払い手段１５が表示される。支払い手段１５は、携帯端末の画面上（ウェブブラウザ上）に、支払い方法を示すボタン画像の形態で表示される。支払い手段を示す各ボタン画像はタッチ操作によって選択することができる。
選択可能な複数の支払い手段１５には、図５(b)に例示するように、例えば「Apple Pay」、「Google Pay」、「Alipay」、「銀行口座引き落とし」などが含まれる。これらの一つ一つが支払い手段を構成する。

以上説明したとおり、本実施形態では、決済仲介サーバーから受信した決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、次の情報を表示する。
・ ユーザが購入する商品に関する説明１１。
・ 商品の対価として支払う金額１４（金額表示ボックス）。
・ 携帯端末のユーザが選択可能な支払い手段１５。

これらの情報は、図５(b)に示すとおり、画面を遷移させることなく、同一のページ内にすべて表示される。つまり、同一の画面、別言すれば、同一のウェブページ内に（同一のＵＲＬのウェブページ内に）すべて表示される。このように、決済に最低限必要なすべての情報を同一のページ内にまとめて表示することで、（必要な情報を得るための）煩わしい画面遷移操作が一切不要になるので、必要な情報を探し回る必要が無い。したがって、滞りなく速やかに、決済処理を進めることができる。また、画面の遷移による機会損失（離脱）を防ぐことができる。

なお、ステップS201において携帯端末７が二次元コード５の読み取りを完了すると、該携帯端末は、以後のステップ S203 - S207 の一連の処理をすべて自動的に実行する。したがって、カメラを起動させた状態の携帯端末７を、二次元コード５の前に翳せば、あとは、図５(b)に示すような情報が携帯端末７に自動的に表示されることになる。

次に携帯端末は、ユーザによる支払い手段１５の選択を受け付ける。図６のステップS213。ユーザによる支払い手段１５の選択は、図５(c)に示すように、携帯端末が具備するタッチスクリーンを利用して行われる。

次に携帯端末は、ユーザによって選択された支払手段に対応する決済代行サーバーに対し、当該携帯端末のユーザを識別するための識別情報を送信するとともに、本人認証をリクエストする。図６のステップS215。
例えば、図５(c)に示すように、ユーザのタッチ操作によって、支払手段として「Apple Pay」が選択された場合には、「Apple Pay」に対応する決済代行サーバーに対し識別情報を送信する。

続いて、決済代行サーバーは、携帯端末からのリクエストに基づいて、本人認証を実行し、その結果を当該携帯端末に送信する。図６のステップS217。

そして、決済代行サーバーから認証結果を受信すると、携帯端末は図５(d)に示すように、決済の承認待ちの状態でスタンバイする。図６のステップS219。

次に携帯端末は、ユーザが決済承認を行うことによって支払を許可すると、それに応じて、決済代行サーバーに対し、選択された支払い手段による代金の支払い（すなわち決済代行）をリクエストする。図６のステップS221, S223。

そして、携帯端末からの支払いのリクエスト（決済代行のリクエスト）に基づいて、決済代行サーバーが決済サーバーに対し、前記識別情報によって識別される個人又は法人を支払い名義とする決済処理をリクエストする。図６のステップS225, S227。

続いて、決済代行サーバーからのリクエストに基づいて、決済サーバーが決済を実行する。図６のステップS229。

決済サーバーにおいて決済処理が完了すると、決済サーバーから決済代行サーバーに対し決済処理の結果が送信され、さらに、決済代行サーバーから携帯端末に対し決済処理の結果が送信される。図６のステップS231, S233。

携帯端末では、決済代行サーバーから受信した決済処理の結果に基づいて、支払完了を画面に表示する。図６のステップS235。

（支払い手段の一例であるApple Pay の仕組み）
図７に、支払い手段の一例である Apple Pay の仕組み（Apple Pay でバーチャルカードが発行される仕組み）の概要を示す。
Apple Pay の初期登録を行う際、ユーザから登録依頼があったタイミングで、カードを発行するクレジットカード発行会社（決済会社）は、あらかじめ割り当てられた番号から採番を行う。そして、クレジットカード会員番号の代わりとなるトークンを生成し、クレジットカード国際ブランド、Apple を介して、ユーザの携帯端末（iPhone(登録商標)）へ書き込みを行う。これにより、ユーザは、クレジットカードの代わりに携帯端末を利用して決済を行うことが可能になる。

３ レジ
４ 商品
５ 二次元コード（ＱＲコード）
７ 携帯端末（スマートフォン）
１１ ユーザが利用した役務に関する説明／ユーザが購入する商品に関する説明
１３ 金額入力欄（金額入力用ボックス）
１４ 商品の対価として支払う金額（金額表示ボックス）
１５ 支払い手段（支払い方法を示すボタン画像）
１６ 支払い手段（支払い方法を示すボタン画像）
１７ 完了ボタン

Claims (5)

1. 携帯端末を利用して支払いを実行するための方法であって、
   (a) ＵＲＬ情報を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
   (b) 二次元コードを読み取った携帯端末がウェブブラウザを起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバーにアクセスするステップと、
   (c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記決済仲介用情報を受信するステップと、
   (d) 決済仲介サーバーから受信した前記決済仲介用情報には、携帯端末のユーザが選択可能な支払い手段が少なくとも一つ含まれており、携帯端末がウェブブラウザ上に前記決済仲介用情報を表示するステップと、
   (e) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
   (g) 携帯端末が決済代行サーバーに対し、選択された支払い手段による支払いをリクエストするステップと、
   (h) 携帯端末からの支払いのリクエストに基づいて、決済代行サーバーが決済サーバーに対し、決済処理をリクエストするステップと、
   を含む情報処理方法。
2. 携帯端末を利用して支払いを実行するための方法であって、
   (a) ＵＲＬ情報を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
   (b) 二次元コードを読み取った携帯端末がウェブブラウザを起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバーにアクセスするステップと、
   (c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記決済仲介用情報を受信するステップと、
   (d1) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、支払い金額を入力可能な金額入力欄を表示するステップと、
   (d2) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、選択可能な少なくとも一つの支払い手段を表示するステップと、
   (e1) 携帯端末が、ユーザによる金額入力欄への金額の入力を受け付けるステップと、
   (e2) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
   (g) 携帯端末が決済代行サーバーに対し、選択された支払い手段による入力額の支払いをリクエストするステップと、
   (h) 携帯端末からの支払いのリクエストに基づいて、決済代行サーバーが決済サーバーに対し、決済処理をリクエストするステップと、
   を含む情報処理方法。
3. 携帯端末を利用して支払いを実行するための方法であって、
   (a) ＵＲＬ情報を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
   (b) 二次元コードを読み取った携帯端末がウェブブラウザを起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバーにアクセスするステップと、
   (c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記決済仲介用情報を受信するステップと、
   (d) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、支払い金額を入力可能な金額入力欄と、
   選択可能な少なくとも一つの支払い手段を表示するステップと、
   (e1) 携帯端末が、ユーザによる金額入力欄への金額の入力を受け付けるステップと、
   (e2) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
   (g) 携帯端末が決済代行サーバーに対し、選択された支払い手段による入力額の支払いをリクエストするステップと、
   (h) 携帯端末からの支払いのリクエストに基づいて、決済代行サーバーが決済サーバーに対し、決済処理をリクエストするステップと、
   を含む情報処理方法。
4. 携帯端末を利用して支払いを実行するための方法であって、
   (a) ＵＲＬ情報を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
   (b) 二次元コードを読み取った携帯端末がウェブブラウザを起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバーにアクセスするステップと、
   (c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記決済仲介用情報を受信するステップと、
   (d1) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、支払い金額を表示するステップと、
   (d2) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、選択可能な少なくとも一つの支払い手段を表示するステップと、
   (e) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
   (g) 携帯端末が決済代行サーバーに対し、選択された支払い手段による代金の支払いをリクエストするステップと、
   (h) 携帯端末からの支払いのリクエストに基づいて、決済代行サーバーが決済サーバーに対し、決済処理をリクエストするステップと、
   を含む情報処理方法。
5. 携帯端末を利用して支払いを実行するための方法であって、
   (a) ＵＲＬ情報を含む決済用の二次元コードが商品に又は店舗内に表示されており、前記二次元コードを携帯端末が読み取るステップと、
   (b) 二次元コードを読み取った携帯端末がウェブブラウザを起動させ、前記二次元コード含まれるＵＲＬ情報に基づいて決済仲介サーバーにアクセスするステップと、
   (c) 前記ＵＲＬ情報に対応するウェブページには決済仲介用情報が含まれ、携帯端末が決済仲介サーバーから、前記決済仲介用情報を受信するステップと、
   (d) 決済仲介サーバーから受信した前記決済仲介用情報に基づいて、携帯端末がウェブブラウザ上に、支払い金額と、選択可能な少なくとも一つの支払い手段を表示するステップと、
   (e) 携帯端末が、ユーザによる支払い手段の選択を受け付けるステップと、
   (g) 携帯端末が決済代行サーバーに対し、選択された支払い手段による代金の支払いをリクエストするステップと、
   (h) 携帯端末からの支払いの指示に基づいて、決済代行サーバーが決済サーバーに対し、決済処理をリクエストするステップと、
   を含む情報処理方法。