特許 7387130 決済支援装置、決済支援システム、決済支援方法及び決済支援プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-11-17

(45)【発行日】2023-11-28

(54)【発明の名称】決済支援装置、決済支援システム、決済支援方法及び決済支援プログラム

(51)【国際特許分類】

   G06Q 20/22 20120101AFI20231120BHJP

   G06Q 20/38 20120101ALI20231120BHJP

【ＦＩ】

G06Q20/22

G06Q20/38

【請求項の数】 10

(21)【出願番号】P 2019031210

(22)【出願日】2019-02-25

(65)【公開番号】P2020135680

(43)【公開日】2020-08-31

【審査請求日】2022-01-24

(73)【特許権者】

【識別番号】518301327

【氏名又は名称】鳥居 寛

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(74)【代理人】

【識別番号】100187355

【弁理士】

【氏名又は名称】花野井 康治

(72)【発明者】

【氏名】鳥居 寛

【審査官】上田 威

(56)【参考文献】

【文献】国際公開第２０１８／０４２６６６（ＷＯ，Ａ１）

【文献】特開２００１－０７６０６８（ＪＰ，Ａ）

【文献】特開２００８－０６５６６９（ＪＰ，Ａ）

【文献】特開２００７－１４１０５５（ＪＰ，Ａ）

【文献】特開２０１１－２１０１７１（ＪＰ，Ａ）

【文献】特開２００５－２２８１５６（ＪＰ，Ａ）

【文献】特開２００８－１２９６３５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

(57)【特許請求の範囲】

【請求項1】

複数の決済手段のそれぞれに対応する決済プログラムを起動可能な決済支援装置であって、
起動すべき決済プログラムを選択するための基準となる選択基準情報と、前記決済プログラムの識別情報と当該決済プログラムの起動方法を定義した起動定義情報とを互いに関連付けた対応プログラム情報と、を記憶する記憶部と、
撮像したコード情報を復号することにより決済情報を取得する決済情報取得部と、
前記記憶部に記憶された選択基準情報に基づいて決済プログラムを選択する選択部と、
前記決済情報が取得されたことに応じて、前記選択された決済プログラムの起動定義情報を前記記憶部より読み出し、当該起動定義情報を用いて当該決済プログラムを起動させる決済プログラム起動部と
を備える決済支援装置。

【請求項2】

前記選択基準情報は、複数の決済プログラムの優先度情報を含み、
前記選択部は、優先度の高い決済プログラムを優先して選択することを特徴とする請求項１に記載の決済支援装置。

【請求項3】

前記選択部は、決済プログラムの優先度情報と、前記決済情報が当該決済プログラムに対応する所定条件を満たすか否かの判定結果に基づいて、決済プログラムの選択を実行することを特徴とする請求項２に記載の決済支援装置。

【請求項4】

複数の決済手段のそれぞれに対応する決済プログラムを起動可能な決済支援装置であって、
複数の決済プログラムの優先度情報を含み、起動すべき決済プログラムを選択するための基準となる選択基準情報と、前記決済プログラムの識別情報と当該決済プログラムの起動方法を定義した起動定義情報とを互いに関連付けた対応プログラム情報と、を記憶する記憶部と、
外部から決済情報を取得する決済情報取得部と、
前記記憶部に記憶された選択基準情報に含まれる優先度情報と、前記決済情報が当該決済プログラムに対応する所定条件を満たすか否かの判定結果に基づいて決済プログラムを選択する選択部と、
前記決済情報が取得されたことに応じて、前記選択された決済プログラムの起動定義情報を前記記憶部より読み出し、当該起動定義情報を用いて当該決済プログラムを起動させる決済プログラム起動部と
を備える決済支援装置。

【請求項5】

前記起動定義情報は、決済プログラムの起動時に与える引数の定義を示す引数定義情報を含み、
前記決済プログラム起動部は、
前記読み出された起動定義情報に含まれる引数定義情報に前記決済情報を適用して、前記決済プログラムの起動時に前記決済情報を引数として与えるための起動情報を生成し、当該起動情報を用いて前記決済プログラムを起動させる
請求項１乃至４のいずれか１項に記載の決済支援装置。

【請求項6】

複数の決済手段のそれぞれに対応する決済プログラムを起動可能な決済支援装置であって、
起動すべき決済プログラムを選択するための基準となる選択基準情報と、前記決済プログラムの識別情報と当該決済プログラムの起動方法を定義した起動定義情報とを互いに関連付けた対応プログラム情報と、を記憶する記憶部と、
外部から決済情報を取得する決済情報取得部と、
前記記憶部に記憶された選択基準情報に基づいて決済プログラムを選択する選択部と、
前記決済情報が取得されたことに応じて、前記選択された決済プログラムの起動定義情報を前記記憶部より読み出し、当該起動定義情報を用いて当該決済プログラムを起動させる決済プログラム起動部と
を備え、
前記起動定義情報は、決済プログラムの起動時に与える引数の定義を示す引数定義情報を含み、
前記決済プログラム起動部は、
前記読み出された起動定義情報に含まれる引数定義情報に前記決済情報を適用して、前記決済プログラムの起動時に前記決済情報を引数として与えるための起動情報を生成し、当該起動情報を用いて前記決済プログラムを起動させる
決済支援装置。

【請求項7】

ユーザがクライアント端末を用いて実行する、電子商取引サーバにおける電子商取引に伴う決済処理を、複数の決済手段のそれぞれに対応する決済サーバを用いて支援する決済支援システムであって、
複数の決済サーバの優先度情報を含み、前記決済処理を行わせる決済サーバを選択するための基準となる選択基準情報と、前記決済サーバの識別情報と、当該決済サーバへの決済要求方法を定義した決済要求定義情報とを互いに関連付けた対応情報と、を記憶する記憶部と、
前記電子商取引サーバから送信された前記電子商取引の決済情報を取得する決済情報取得部と、
前記記憶部に記憶された選択基準情報に含まれる優先度情報と、前記決済情報が当該決済サーバに対応する所定条件を満たすか否かの判定結果に基づいて決済サーバを選択する選択部と、
前記選択された決済サーバの決済要求定義情報を前記記憶部より読み出し、当該決済要求定義情報と、前記取得された決済情報とを用いて当該決済サーバにおいて前記決済情報に基づく決済処理を行わせるための決済要求情報を生成し、当該決済要求情報を前記決済サーバへ転送させるように前記ユーザのクライアント端末に送信する決済要求部と、
を備える決済支援システム。

【請求項8】

複数の決済手段のそれぞれに対応する決済プログラムを起動可能なコンピュータを用いた決済支援方法であって、
前記コンピュータが、
起動すべき決済プログラムを選択するための基準となる選択基準情報と、前記決済プログラムの識別情報と当該決済プログラムの起動方法を定義した起動定義情報とを互いに関連付けた対応プログラム情報と、を記憶部に格納し、
撮像したコード情報を復号することにより決済情報を取得し、
前記記憶部に記憶された選択基準情報に基づいて決済プログラムを選択し、
前記選択された決済プログラムの起動定義情報を前記記憶部から読み出し、
前記決済情報が取得されたことに応じて、前記読み出した起動定義情報を用いて当該決済プログラムを起動させる
決済支援方法。

【請求項9】

複数の決済手段のそれぞれに対応する決済プログラムを起動可能なコンピュータを用いた決済支援方法であって、
前記コンピュータが、
複数の決済プログラムの優先度情報を含み、起動すべき決済プログラムを選択するための基準となる選択基準情報と、前記決済プログラムの識別情報と当該決済プログラムの起動方法を定義した起動定義情報とを互いに関連付けた対応プログラム情報と、を記憶部に格納し、
外部から決済情報を取得し、
前記記憶部に記憶された選択基準情報に含まれる優先度情報と、前記決済情報が当該決済プログラムに対応する所定条件を満たすか否かの判定結果に基づいて決済プログラムを選択し、
前記選択された決済プログラムの起動定義情報を前記記憶部から読み出し、
前記決済情報が取得されたことに応じて、前記読み出した起動定義情報を用いて当該決済プログラムを起動させる
決済支援方法。

【請求項10】

複数の決済手段のそれぞれに対応する複数の決済プログラムを起動可能なコンピュータに、
起動すべき決済プログラムを選択するための基準となる選択基準情報と、前記決済プログラムの識別情報と当該決済プログラムの起動方法を定義し、かつ、決済プログラムの起動時に与える引数の定義を示す引数定義情報を含む起動定義情報とを互いに関連付けた対応プログラム情報と、を記憶部に格納する処理と、
外部から決済情報を取得する処理と、
前記記憶部に記憶された選択基準情報に基づいて決済プログラムを選択する処理と、
前記選択された決済プログラムの起動定義情報を前記記憶部から読み出す処理と、
前記決済情報が取得されたことに応じて、前記読み出された起動定義情報に含まれる引数定義情報に前記決済情報を適用して、前記決済プログラムの起動時に前記決済情報を引数として与えるための起動情報を生成する処理と、
前記起動情報を用いて当該決済プログラムを起動させる処理と、
を実行させる決済支援プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、決済支援装置、決済支援システム、決済支援方法及び決済支援プログラムに関するものである。

【背景技術】

【0002】

技術の進歩に伴って、店舗と顧客との間で商取引を行う場合に、現金以外の様々な決済方法が用いられるようになった。特許文献１は、その方法の一つとして二次元コードを利用した決済方法について開示している。決済に使用する二次元コードの符号化は、例えば非特許文献１に規定されたような方法が用いられている。

【0003】

決済方法としては、この他にクレジットカードや銀行振込に加え、電子マネーや仮想通貨を用いた決済も広く普及するようになった。

【先行技術文献】

【特許文献】

【0004】

【文献】特許第６２７１８００号公報

【非特許文献】

【0005】

【文献】EMV（登録商標） QR Code Specification for Payment Systems (EMV QRCPS)-Merchant-Presented Mode, Version 1.0, July 2017.

【発明の概要】

【発明が解決しようとする課題】

【0006】

店舗がより多くの顧客と商取引を行うには、様々な決済方法に対応する必要があるため、複数の決済業者と提携しなければならない。しかし、レジにおいて商品やメニューを置くことができるスペースに、複数のクレジットカードや電子マネーの決済端末やそれぞれが異なる二次元コードに対応した複数のリーダを設置することは、店舗内の美観を損ね、乱雑な印象を与え、省スペース化の要請にも反する。

【0007】

かかる問題を解消するために、クレジットカードや電子マネーの決済端末を１台にまとめたり、二次元コードを複数の決済業者において共通化したりする動きが生じるようになってきた。しかしながら、決済を行う場面では、店舗の従業員若しくは顧客が、決済業者の一覧に目を通し、その中から使用したい手段を手動で選択する手間は依然として残り、その負担は大きい。

【0008】

この点は、インターネット上のＥＣ（電子商取引）サイトにおいても同様であり、キャッシュレスの促進や仮想通貨の普及等が進むことにより、更に顧客への負担が増大することが予想される。

【0009】

本開示は、このような課題を解決するためになされたものであり、顧客の利便性を向上させることができる決済支援装置、決済支援システム、決済支援方法及び決済支援プログラムを提供することを目的とする。

【課題を解決するための手段】

【0010】

本開示の第１の態様にかかる決済支援装置は、
複数の決済手段のそれぞれに対応する決済プログラムを起動可能な決済支援装置であって、
起動すべき決済プログラムを選択するための基準となる選択基準情報と、前記決済プログラムの識別情報と当該決済プログラムの起動方法を定義した起動定義情報とを互いに関連付けた対応プログラム情報と、を記憶する記憶部と、
外部から決済情報を取得する決済情報取得部と、
前記記憶部に記憶された選択基準情報に基づいて決済プログラムを選択する選択部と、
前記決済情報が取得されたことに応じて、前記選択された決済プログラムの起動定義情報を前記記憶部より読み出し、当該起動定義情報を用いて当該決済プログラムを起動させる決済プログラム起動部と
を備える。

【0011】

また、本開示の第２の態様にかかる決済支援システムは、
ユーザがクライアント端末を用いて実行する、電子商取引サーバにおける電子商取引に伴う決済処理を、複数の決済手段のそれぞれに対応する決済サーバを用いて支援する決済支援システムであって、
前記決済処理を行わせる決済サーバを選択するための基準となる選択基準情報と、前記決済サーバの識別情報と、当該決済サーバへの決済要求方法を定義した決済要求定義情報とを互いに関連付けた対応情報と、を記憶する記憶部と、
前記電子商取引サーバから送信された前記電子商取引の決済情報を取得する決済情報取得部と、
前記記憶部に記憶された選択基準情報に基づいて決済サーバを選択する選択部と、
前記選択された決済サーバの決済要求定義情報を前記記憶部より読み出し、当該決済要求定義情報と、前記取得された決済情報とを用いて当該決済サーバにおいて前記決済情報に基づく決済処理を行わせるための決済要求情報を生成し、当該決済要求情報を前記決済サーバへ転送させるように前記ユーザのクライアント端末に送信する決済要求部と、
を備える。

【発明の効果】

【0012】

本開示によれば、顧客の利便性の向上が可能な決済支援装置、決済支援システム、決済支援方法及び決済支援プログラムを提供することができる。

【図面の簡単な説明】

【0013】

【図1】実施形態１にかかる決済アプリ起動装置におけるハードウェアの構成を表すブロック図である。

【図2】実施形態１にかかる決済支援システムの構成を表すブロック図である。

【図3】実施形態１にかかる決済処理のシーケンスを表す図である。

【図4】実施形態１にかかる対応アプリテーブルの例である。

【図5】実施形態１にかかる決済情報をアプリ起動引数に変換する際に利用するテーブルの例である。

【図6】実施形態１にかかる決済アプリの画面の例である。

【図7】実施形態２にかかる決済支援システムの構成を表すブロック図である。

【図8】実施形態２にかかる決済アプリの優先順位を設定する画面の例である。

【図9】実施形態２にかかるアプリ決済先テーブルの例である。

【図10】実施形態２にかかる決済処理のシーケンス図である。

【図11】実施形態２にかかる決済アプリの選択処理のフローチャート図である。

【図12】実施形態２にかかる対応アプリテーブルの例である。

【図13】実施形態２において決済情報を記録する際に利用するテーブルの例と記録例である。

【図14】実施形態２において決済情報を記録する際に利用するテーブルの例と記録例である。

【図15】実施形態３にかかる決済支援システムの構成を表すブロック図である。

【図16】実施形態３にかかる決済アプリを登録するページの例である。

【図17】実施形態３の実施例１にかかる決済処理のシーケンス図である。

【図18】実施形態３の実施例２にかかる決済処理のシーケンス図である。

【図19】実施形態３の実施例３にかかる決済処理のシーケンス図である。

【図20】実施形態３の実施例４にかかる決済処理のシーケンス図である。

【図21】実施形態３の実施例５にかかる決済支援システムの構成及び決済処理の流れを示す図である。

【発明を実施するための形態】

【0014】

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、必要に応じて重複説明は省略する。尚、本実施形態では、決済方法として銀行送金やクレジットカードなどを取り上げるが、本発明は決済手段を限定するものではない。

【0015】

＜実施形態１＞
本実施形態では、二次元コードに符号化されたＵＲＩ（Uniform Resource Identifier、統一資源識別子）を読み込むことにより、銀行の送金（決済）アプリを自動的に起動するスマートフォンアプリの例を示す。

【0016】

図１は、本実施形態にかかる決済アプリ起動装置１００におけるハードウェアの構成を表すブロック図である。当該決済アプリ起動装置は、決済支援装置の一例であり、例えば、携帯型端末やスマートフォンである。同図において、ＣＰＵ（Central Processing Unit、中央処理装置）１０１は、本実施形態にかかる決済支援装置の処理が実装されたプログラム１０２１を実行する。プログラムメモリ１０２は、ＣＰＵ１０１により実行されるプログラム１０２１を記憶する。ＲＡＭ（Random Access Memory）１０３は、ＣＰＵ１０１によるプログラム実行時に、各種情報を一時的に記憶する揮発性記憶装置である。尚、ＣＰＵ１０１によるプログラム実行時に、ＲＡＭ１０３がプログラム１０２１を記憶することにより、ＲＡＭ１０３はプログラムメモリ１０２の役目を果たすように実装することもできる。長期記憶装置１０４は、ＲＡＭ１０３に比べてより長期の間、各種情報を記憶する不揮発性記憶装置であり、例えば、ハードディスクやフラッシュメモリ等である。通信部１０５は、他の装置と通信するために利用される。表示装置１０７は、液晶ディスプレイや有機ＥＬディスプレイ等の表示手段である。撮像装置１０８は、少なくとも二次元コード等を撮影し、撮像信号を出力可能なカメラ等の撮像手段である。

【0017】

ＣＰＵ１０１、プログラムメモリ１０２、ＲＡＭ１０３、長期記憶装置１０４、通信部１０５、表示装置１０７及び撮像装置１０８は、バス１０６により接続され、データや制御信号を互いに受け渡すために用いられる。本明細書では、ＣＰＵによるプログラム実行を説明するが、ＦＰＧＡ（Field-Programmable Gate Array）などの集積回路でも同様の機能が実装できる。

【0018】

また、本実施形態において、データベース機能が使用されるが、データベースに保管するデータは、長期記憶装置１０４上やＲＡＭ１０３上などに記憶される。あるいは、他の装置上に記憶され、通信部１０５を利用して、読み書きすることも可能である。

【0019】

図２は、本実施形態にかかる決済支援システムの構成を表すブロック図である。本実施形態では、発明をなるべく分かりやすく説明するために、銀行（以下、「顧客銀行」とする）２０２に口座を保有する顧客２０１が、ある店舗にて支払いをしようとする場面を想定する。言うまでもなく、このような状況に限らず、本発明は決済が必要な様々な場面に適用することができる。

【0020】

顧客２０１は、決済アプリ起動装置１００に、決済アプリケーションプログラム（以下、単に「決済アプリ」とする）を起動するためのアプリケーションプログラム（以下、単に「決済アプリ起動アプリ」とする）２０５や１つ以上の決済アプリをインストールしている。図２の決済アプリ２０８はその決済アプリの１つである。図２に示す決済アプリ起動装置１００は、決済アプリ起動アプリ２０５及び決済アプリ２０８がインストールされた状態を示す。尚、決済アプリ起動アプリ２０５及び１以上の決済アプリ２０８のそれぞれは、ディープリンク機能（例えばｉＯＳ（登録商標）の場合はＵｎｉｖｅｒｓａｌ Ｌｉｎｋｓ、Ａｎｄｒｏｉｄ（登録商標）の場合はＩｎｔｅｎｔ ＵＲＩ）により起動可能なように、予め、ＯＳ（Operating System）やＷｅｂサイトに各種設定（例えば、起動時のＵＲＩの書式設定等）がなされているものとする。また、当該各種設定は、手動又は（各アプリのインストール時等に）自動で行われればよい。但し、１以上の決済アプリ２０８のそれぞれについては、必ずしもディープリンク機能に対応している必要はなく、他の起動手段及び起動時のパラメータ指定により起動可能であってもよい。

【0021】

決済アプリ２０８は、顧客銀行２０２における顧客２０１の口座から、他の銀行若しくは同じ銀行の口座宛ての送金を指示することが可能なソフトウェアプログラムである。そして、決済アプリ２０８は、特定の決済手段に対応する決済プログラムの一形態である。尚、本実施形態にかかる決済アプリ２０８のそれぞれは、異なる決済機関が運用するサーバ装置上で稼働する所定の決済手段に対応する複数の決済処理のそれぞれを行う決済サーバ（プログラム）に対して決済処理を要求するクライアントプログラムを想定するが、これに限定されない。

【0022】

決済アプリ起動アプリ２０５は、決済アプリ２０８を含む複数の決済アプリのそれぞれを起動することが可能なソフトウェアプログラムである。決済アプリ起動アプリ２０５は、アプリ登録部２０５１、登録アプリＩＤ２０５２、選択部２０５３、決済記録部２０５４、決済記録テーブル２０５５、アプリ起動部２０５６、対応アプリテーブル２０５７を備える。

【0023】

コード読取部２０７は、撮像装置１０８によって撮影されることにより入手された提示決済情報２０６を取得し、復号する。さらに、コード読取部２０７は、復号することにより得られた決済情報が予め定められたＵＲＩの形式（例えば、決済アプリ起動アプリ２０５をディープリンク機能により起動するために予め設定された形式）か否かを判定する。

【0024】

アプリ登録部２０５１は、起動対象の決済アプリの登録処理を実行する。

【0025】

登録アプリＩＤ２０５２は、決済アプリの識別子である登録アプリＩＤを記憶するデータベース（記憶部）である。尚、登録アプリＩＤ２０５２は、起動すべき決済プログラムを選択するための基準となる選択基準情報の一例である。

【0026】

選択部２０５３は、復号されたＵＲＩ（Uniform Resource Identifier）を取得し、クエリ（ＵＲＬ:Uniform Resource Locator）パラメータから決済情報（銀行ＩＤ、送金先口座情報（口座種別、口座番号）、金額、通信文（取引ＩＤ等）、手数料負担等）を抽出する。尚、選択部２０５３は、外部から決済情報を取得する決済情報取得部としての機能も有する。

【0027】

決済記録部２０５４は、決済情報を決済記録テーブル２０５５に格納する処理を行う。

【0028】

決済記録テーブル２０５５は、決済情報を記憶するデータベース（記憶部）である。

【0029】

アプリ起動部２０５６は、対応アプリテーブル２０５７に含まれる起動方法に関する情報を参照して該当する決済アプリ２０８を起動する。尚、アプリ起動部２０５６は、決済プログラム起動部の一例である。

【0030】

対応アプリテーブル２０５７は、起動アプリＩＤと、起動アプリの起動方法を互いに関連づけて記憶するデータベース（記憶部）である。ここで、起動方法とは、決済プログラムの起動方法を定義した起動定義情報の一例であり、関連付けられた（起動対象の）起動アプリを起動するための呼び出し情報（プロトコル、ドメイン、又は、実行コマンド等）、起動時に起動アプリに与える引数の定義を示す引数定義情報（引数の書式又は形式、パラメータの種類又は名称、並びに、パラメータのデータ型及びサイズ、順序等）等を含むものとする。例えば、起動方法には、ディープリンク機能により起動するために予め設定されたＵＲＩの書式の定義、起動時にアプリに入力する引数の書式の定義、アプリを起動するためのコマンド（実行ファイル名、コマンドライン引数の定義）等が挙げられる。尚、対応アプリテーブル２０５７は、前記決済プログラムの識別情報と起動定義情報とを互いに関連付けた対応プログラム情報の一例である。

【0031】

ここで、顧客２０１が店舗等にて商品等を購入し、決済する前段階の処理について説明する。

【0032】

まず、決済アプリ起動アプリ２０５が、決済アプリ起動装置１００にインストールされている決済アプリを認識できることが望ましい。しかし、決済アプリ起動装置２０５が決済アプリを認識できない場合には、顧客２０１が予め利用を希望する決済アプリを登録する。決済アプリ起動装置１００は、登録された決済アプリの識別子（識別情報）を保持する。

【0033】

そのために、顧客２０１は、決済において利用を希望する決済アプリを選択することができる。顧客２０１がユーザインタフェース（ＵＩ）上で利用を希望する決済アプリを選択すると、アプリ登録部２０５１は、その識別子を登録アプリＩＤ２０５２としてデータベースに格納する。

【0034】

続いて、顧客２０１が店舗等において決済する段階の処理について説明する。

【0035】

顧客２０１は、決済アプリ起動装置１００の撮像装置１０８を用いて、店舗のレジの表示装置、あるいは商品や商品タグに表示されている提示決済情報２０６を撮影する。提示決済情報２０６は、例えば、決済情報を符号化した二次元コードである。より詳細には、提示決済情報２０６は、決済情報が以下のＵＲＩの形式で符号化されることにより構成されている。

【0036】

https://example.org/payment?bank=Bank1&branch=001
&type=transfer&account=1234567&amount=1000&fee=0&msg=4578947

【0037】

この決済情報は、Bank1銀行の支店番号001の口座番号1234567により特定される振替口座（transfer account）に1000円を通信文4578947を付けて手数料の負担なしで送ることを示す情報を含む。通信文は、例えば決済を識別する情報のために利用することができる。当然、これは決済情報の一例であり、この形式・内容である必要はない。

【0038】

ここで、図３は、実施形態１にかかる決済処理のシーケンスを表す図である。以下では、図２と図３を適宜参照しつつ説明する。
顧客２０１の操作によって提示決済情報２０６が撮影されると（Ｓ１０１）、決済アプリ起動装置１００のＯＳまたは他のアプリ（カメラアプリ等）に実装されているコード読取部２０７は、提示決済情報２０６を復号する。コード読取部２０７は、さらに、復号により得られたＵＲＩが予め定められた形式（例えば、上記ＵＲＩの例のような形式）であると判定した場合に、ディープリンク機能により、決済アプリ起動アプリ２０５を起動する。

【0039】

コード読取部２０７は、復号されたＵＲＩ（決済情報）を決済アプリ起動アプリ２０５に渡す（Ｓ１０２）。選択部２０５３は、当該ＵＲＩを受け取り、クエリ（ＵＲＬ）パラメータから決済情報を抽出する（Ｓ１０３）。選択部２０５３は、抽出された決済情報を決済記録部２０５４に渡す（Ｓ１０４）。

【0040】

決済記録部２０５４は、取得した決済情報を決済記録テーブル２０５５に対して追記し、格納（記録）する（Ｓ１０５）。決済記録テーブル２０５５に格納された決済情報は、家計簿などの記録情報として利用できる。

【0041】

また、選択部２０５３は、データベースから登録アプリＩＤ２０５２を取得し、これを起動すべきアプリ（起動アプリ）として選択する（Ｓ１０６）。選択部２０５３は、登録アプリＩＤ２０５２（決済アプリＩＤ）を、決済情報とともにアプリ起動部２０５６に渡す（Ｓ１０７）。そして、アプリ起動部２０５６は、データベース内の対応アプリテーブル２０５７の「決済アプリＩＤ」列から登録アプリＩＤ２０５２を検索し、検索された決済アプリＩＤに対応付けられた起動方法と決済情報を用いて起動情報を生成し（Ｓ１０８）、起動情報を用いて該当する決済アプリ２０８を起動する（Ｓ１０９）。例えば、アプリ起動部２０５６は、起動方法に含まれる引数定義情報の書式に決済情報を適用して起動情報を生成する。ここで、起動情報は、決済アプリを起動するために用いられる情報であり、決済アプリの起動時に決済情報を引数として与えるための情報である。よって、起動情報には、決済情報が含まれるのが望ましい。起動情報は、例えば、後述する、選択された決済アプリに対応する形式のＵＲＩや、起動コマンドとそのコマンドライン引数を結合した文字列等である。

【0042】

決済アプリ２０８を起動するに当たって、起動情報に決済情報を含める方法が用意されていない、あるいは知らされていない場合には、起動情報に決済情報を含めることができない。その場合は、決済アプリ２０８を起動後に、顧客２０１は、決済情報を何らかの方法により入力する（あるいは読み込ませる）必要が出てくるが、それでも本発明によって自動的に決済アプリ２０８を選択して起動するという利点は生かされる。

【0043】

この場合、例えば、アプリ起動部２０５６は、決済情報が取得されたことに応じて、選択部２０５３により選択された決済プログラムの起動定義情報を記憶部より読み出し、当該起動定義情報を用いて当該決済プログラムを起動させるものとすればよい。

【0044】

図４に、対応アプリテーブル２０５７の一例を示す。「決済アプリＩＤ」の列には、決済アプリの識別子が並ぶ。また、「起動方法」の列には、それぞれの決済アプリを起動するに当たってＯＳに渡す引数の形式が定義されている。対応アプリテーブル２０５７は、決済アプリ起動アプリ２０５のインストール前又は、インストール後に顧客２０１によって手動で入力するようにしてもよい。さらには、インストール後に対応アプリテーブル２０５７をダウンロードすることによってデータベースに格納するようにしてもよい。図４の例では、「起動方法」は、決済アプリをディープリンク機能で起動する際のＵＲＩの書式のうちパラメータ名とパラメータ値の定義であり、決済情報内の各情報を置換するための定義ともいえる。

【0045】

この例では、決済アプリを起動するには、ＵＲＩ形式の引数をＯＳに渡すことを仮定しているが、これはそれぞれのＯＳで定義する方法に合わせるべきである。仮にＵＲＩ形式の引数を渡すとして、アプリ起動部２０５６は、「起動方法」の列にある文字列の｛｝に囲まれた部分を、決済情報から得た文字列に置き換える。具体的には、{bank}の文字列は、決済情報のbankパラメータから得た文字列で置き換える。{branch}、{type}、{account}、{amount}、{fee}、{msg}においても同様である。{type:type_halfwidth1}においては、文字列の変換を行う。データベース内に予め図５に示すようなtype_halfwidth1という名前のテーブルが用意されており、決済情報のtypeパラメータを「入力文字列」の列で検索し、同じ行の「置換文字列」の列にある文字列を用いて、「起動方法」の{type:type_halfwidth1}を置き換える。また、{msg:fullwidth}においては、msgパラメータを全角文字に変換して{msg:fullwidth}を置き換える。

【0046】

上記決済情報の例で、登録アプリＩＤ２０５２が「銀行Ａ」とした場合、アプリ起動部２０５６は、起動方法及び決済情報を用いて以下の引数を起動情報として生成し、ＯＳに起動情報を渡すことでディープリンク機能により、決済アプリ２０８が起動される。

【0047】

【数1】

【0048】

なお、上記ではURIの一部として半角カナ文字や全角文字を記載しており、厳密にはＵＲＬエンコードされるべきであるが、この明細書の記載としては、理解のしやすさを優先してそのままの記載としている。

【0049】

決済アプリ２０８の実装方法は、その開発者に任されるが、イメージしやすくするために、一例を示す。図６は、決済アプリが上記引数で起動された際に表示される画面６００の例である。表示されているのは、決済情報に含まれる決済先に関する情報である。この画面が表示された状態で顧客２０１が承認ボタン６０１を選択すると、決済が実行される。逆に、中止ボタン６０２が選択された場合には、決済が行われない。

【0050】

ここで、テキスト表示６０３において送金手数料が０円と表示されている。これは、上記引数でfeeパラメータが0であるため、送金手数料が売り手負担となったためである。このパラメータが省略される場合、あるいは値が1の場合には、送金手数料が買い手負担となる。

【0051】

以上、本実施形態では、二次元コードに符号化された決済情報を撮像装置で読み込むことで、銀行の決済アプリを自動的に起動するスマートフォンアプリの例を示した。本発明の実施形態によれば、店舗側が指定した金融機関に縛られることなく、顧客は自身が口座を持つ金融機関の決済アプリを使用することができる。また、決済情報をＵＲＩとして符号化することにより、ロックスクリーンやホームスクリーンなどから起動しやすいＯＳのコード読取部（カメラアプリ）を使用することができ、顧客にとってスムーズな決済が可能となる。特に、ＵＲＩを使ったディープリンク機能により決済アプリ起動アプリを起動できるので、カメラアプリだけでなくブラウザや他のアプリからも決済情報を渡して柔軟な決済を行うことができる点も本発明に特有の効果といえる。つまり、購買用ボタン１つで顧客の複数の決済サービスに対応することができるようになる。また、全ての金融機関のために共通の決済アプリを開発するのに比べ、各金融機関の実装の自由度が高く、個々の金融機関の特徴を生かすことができる。また、セキュリティの観点からも、決済の仕組みに関する機密情報を決済アプリ起動アプリの実装者と共有する必要がない点で好ましい。

【0052】

尚、本実施形態により、店舗側は、１つの決済情報に対して１種類の提示決済情報を生成し、顧客に提示するだけで済む。そして、顧客も提示決済情報を読み取る操作を行うことで、予め登録した任意の決済アプリを用いて決済することができる。本実施形態は、いわば店舗側から提示された提示決済情報を顧客が所望する任意の起動情報に変換して、所望の決済アプリを用いて決済することを支援するものといえる。

【0053】

以上、説明したように、本実施形態によれば、決済を行う場面で顧客の利便性を向上することができる。

【0054】

＜実施形態２＞
本実施形態では、二次元コードやバーコードなどをアプリ内に実装された読取部を使用して読み込むことにより、クレジットカードや銀行送金などの決済処理を要求するための決済アプリを自動的に起動するスマートフォンアプリの例を示す。

【0055】

本実施形態にかかる決済アプリ起動装置におけるハードウェア構成は図１と同様であるものとする。ＦＰＧＡなど他の集積回路でも同様の構成で同じ機能が実現できる。

【0056】

図７は、本実施形態にかかる決済支援システムの構成を表すブロック図である。尚、顧客決済機関２０２Ｂは、顧客２０１が希望する決済処理が可能な決済機関を示す。顧客２０１は、予め使用を希望する決済アプリの優先順位を設定する。顧客２０１に提示するＵＩは例えば図８の設定画面８００のように、ドラッグアンドドロップにより決済サービス名８０１の順番を変えることができるようになっている。これに基づいてアプリ登録部２０５１Ｂは、決済サービス名に対応する決済アプリのＩＤに優先順位（優先度）を対応付けて、登録アプリ順位２０５２Ｂとしてデータベース（記憶部）に保存する。ここで、優先度は、例えば図８の画面上で上位であるほど高いものとする。登録アプリ順位２０５２Ｂは、選択基準情報の一例であり、決済プログラムの優先度情報の一例である。

【0057】

本実施形態では、提示決済情報２０６Ｂを読み取る機能を決済アプリ起動アプリ２０５Ｂに実装することにより、ＯＳの読取部が扱えない形式の（例えばＵＲＩ形式でない）情報も読み取れるようにする。例えば、提示決済情報２０６Ｂが、実施形態１と同じＵＲＩ形式（例えば、https://example.comで始まる文字列）の場合には、実施形態１と同じ処理を実行すれば良い。その一方で、非特許文献１に定義される形式（例えば、000201で始まる文字列）である場合には、以下の処理を実行する。

【0058】

以下の説明の前提条件として、非特許文献１にて定義されるデータは、木構造となっており、各ノード（Data Object）は、数字のＩＤに加えて、数字や文字列などの値を持つことを述べておく。特に、非特許文献１において定義される二次元コードは、複数の決済サービスの情報を１つの二次元コードに格納することができるのが特徴であり、本発明を利用しない場合は、顧客が自ら利用したい決済サービスを二次元コードとは別の決済サービス一覧から目視で選ぶことになり、非常に煩雑となる。そこで、本実施形態では、以下に説明する手法によりこの課題を解決することができる。

【0059】

まず、決済先条件テーブル２０５８Ｂには図９のように決済アプリ（「決済アプリＩＤ」の列）とその決済アプリが決済を行うことのできる決済先の条件（「決済先条件」の列）の対応表が記憶されている。「決済先条件」の列は、数字または{}に囲まれた文字列で表される条件が並び、条件はＯＲで結ばれる。つまり、その条件の内１つが満たされれば、決済先として適合する。条件が数字のみの場合、提示決済情報２０６ＢのMerchant Account InformationのIDとしてその数字が含まれるかどうかを調べる。これは決済サービスの特定に相当する。図９の例では、カードＡは２９で表される決済サービスのみに対応することを意味する。{}で囲まれる文字列は、その中のそれぞれの条件がＡＮＤ結合される。中の条件が数字だけの場合は、提示決済情報２０６Ｂの最上位のData ObjectのIDとしてその数字が含まれるかどうかを調べる。（通常は、Merchant Account Informationの存在を意味する。）あるいは、=が含まれる文字列である場合には、最初の=の左側のIDが表すData Object の値が右側の値に一致する場合に条件が満たされる。「決済先条件」の文字列が{33 53=840} {34 53=840} {35 53=840}の場合、Merchant Account InformationのIDが33, 34, 35（決済サービスを表すＩＤ）のいずれかで、Data Object IDが53（通貨を表す）の値が米ドル（840はＩＳＯ４２１７で米ドル）を表す場合に、決済先として適合する。他にも国名など他の条件も当てはめることが可能である。また、正規表現などを使えばより柔軟に条件を記述できることは言うまでもない。決済先条件テーブル２０５８Ｂも選択基準情報の一例であり、本実施形態は複数の選択基準情報を組み合わせた例となっている。

【0060】

さて、本実施形態における決済アプリ起動装置の構成要素間のシーケンス図を図１０に示す。まず、決済情報読取部２０７Ｂは、提示決済情報２０６Ｂを読み取る（Ｓ２０１）。尚、決済情報読取部２０７Ｂは、決済情報取得部の一例である。決済情報読取部２０７Ｂは、読み取った提示決済情報２０６Ｂから決済情報を抽出し（Ｓ２０２）、選択部２０５３Ｂに渡す（Ｓ２０３）。選択部２０５３Ｂは、受け取った決済情報に基づいて決済アプリＩＤを選択し（Ｓ２０４）、選択した決済アプリＩＤを決済情報読取部２０７Ｂに渡す（Ｓ２０５）。尚、選択部２０５３Ｂが実行する、決済アプリＩＤの選択の仕方（決済アプリの選択処理）については、後に述べる。

【0061】

決済情報読取部２０７Ｂは、決済記録部２０５４Ｂに対しても決済情報を渡す（Ｓ２０６）。決済記録部２０５４Ｂは、受け取った決済情報をデータベースの決済記録テーブル２０５５Ｂに記録する（Ｓ２０７）。また、決済情報読取部２０７Ｂは、選択部２０５３Ｂから取得した決済アプリＩＤと決済情報をアプリ起動部２０５６Ｂに渡す（Ｓ２０８）。アプリ起動部２０５６Ｂは、決済アプリＩＤと決済情報とを取得して、後述する方法で起動情報を生成し（Ｓ２０９）、起動情報を用いて決済アプリ２０８を起動する（Ｓ２１０）。

【0062】

続いて、図１１を用いて、選択部２０５３Ｂによる決済アプリの選択処理について説明する。この処理は、ステップＳ１１０１とステップＳ１１０２を含むループの繰り返しであり、登録アプリ順位２０５２Ｂの各要素を優先順位の高い方から変数ｅａｃｈに代入しながら行う。初めのステップＳ１１０１では、決済先条件テーブル２０５８Ｂの「決済アプリＩＤ」の列からｅａｃｈを検索する。そして見つかった行の「決済先条件」の列の値を変数ｃｏｎｄｉｔｉｏｎに代入する。次のステップＳ１１０２では、決済情報がｃｏｎｄｉｔｉｏｎの条件を満たすかどうかの判定が行われる。判定方法は図９で説明したとおりである。もし条件を満たさなければ、ループを繰り返し、最後まで条件が満たされなければ、ステップＳ１１０４において対応する決済アプリが見つからなかった旨を表示装置１０７に表示する。もし条件を満たせば、ステップＳ１１０３において、変数ｅａｃｈの代入されている決済アプリＩＤに対応する決済アプリが起動対象として選択される。

【0063】

選択部２０５３Ｂから決済アプリＩＤを受け取ったアプリ起動部２０５６Ｂは、対応アプリテーブル２０５７Ｂを参照しながら、決済アプリ２０８を起動するための起動方法を特定する。対応アプリテーブル２０５７Ｂは、図１２のように、「決済アプリＩＤ」の列には、決済アプリの識別子が並び、「起動方法」の列には、それぞれの決済アプリを起動するに当たって使用する引数の形式が定義されている。{}に囲まれた文字列は置換する文字列である。{54}のように括弧内が数字だけの場合は、提示決済情報２０６Ｂの木構造のルートにおけるＩＤが54であるData Object（ノード）の値で置き換える。また、{28.05}のように数字がピリオドで連結されている場合、木構造のルートで28のＩＤを持つData Objectの子ノードの内、ＩＤが05であるData Objectの値で置き換える。また、{53:CUR}のようにコロンを含む場合は、{53}に相当する文字列を変換してから置き換える。:CURは、ＩＳＯ４２１７において数字で表される通貨を英大文字で表される通貨に変換することを意味する。例えば、840はUSDに変換される。よって、非特許文献１のAnnex B Examplesに提示されている二次元コードにおいて、カードＡの決済アプリを起動するための引数は、以下の通りとなる。

【0064】

https://carda.example.com/p?ac=A93FO3230Q&c=CNY&am=23.72
となる。

【0065】

アプリ起動部２０５６Ｂは、決済アプリＩＤを使って対応アプリテーブル２０５７Ｂの「決済アプリＩＤ」の列を検索し、「起動方法」の列の値を使って起動用の引数の書式を求めた後、上記の様に、起動方法（起動定義情報）及び決済情報を用いて起動情報を生成し、起動情報を用いて決済アプリ２０８を起動する。その後の動作は決済アプリ２０８の開発者に任されるが、例えば図６のような画面で顧客２０１に決済の承認を得て決済を完了させる。

【0066】

また、決済記録部２０５４Ｂが決済情報を記録する際、情報を整理してから記録した方が後に集計がしやすくなる。図１３は、決済情報を整理するための情報を保持するデータベース内の決済記録テーブル２０５５Ｂの一例である。この例では、決済アプリ毎に記録するべき情報が各行に保持されている。各列は、決済記録テーブル２０５５Ｂの各列に対応し、その列にどのような情報を記録するべきかを保持する。{}で囲まれた文字列の意味は、図１２の場合と同じであり、決済情報からの情報で置き換えられる。（異なる方法であっても良いが説明がしやすいためにここでは同じにする。）ただし、データベースの慣習に従って、内容が数値（金額）に限られる場合には、決済記録テーブル２０５５Ｂの各列は数値（金額）の型として定義するのが効率的である。また、非特許文献１のAnnex B Examplesに提示されている二次元コードの情報を記録する場合には、図１４のように記録されることになる。（この例では、更に記録の際の日時を追加している。）このように記録しておくことにより、後に決済アプリＩＤ毎に金額の総和を取ったりして、家計簿のように使うことが可能となる。前にも触れたが、データベースの内容は、クラウド上に保存されても良い。

【0067】

以上、本実施形態では、二次元コードやバーコードなどをアプリ内に実装された読取部を使用して読み込むことにより、多様な形式の決済情報に応じて多様な決済アプリを起動する例を示した。つまり、コードの形式によって決済先条件を変更できるため、コードの形式に応じて、実質的に起動するアプリを変更できる。この時、コード部分だけでは決済先を特定できない場合があるが、その際には画像にコードとともに写っているロゴなどの画像情報を元に、画像認識を使って特定してもよい。特に、決済時に、店舗が対応する多様な決済サービスの中から１つを選ぶ煩わしさがなく、希望の決済アプリを優先的に使用することができる。そして、対応できる決済アプリが１つもインストールされていない場合にはエラー表示によってそのことを知ることができる。エラーを表示する代わりに、決済アプリのインストールを促すことも考えられる。また、共通した決済記録を行うことにより、複数の決済アプリをまたがった支出の集計が行える点も利点である。

【0068】

＜実施形態３＞
これまでの実施形態ではスマートフォンアプリの例を示していたが、本実施形態ではウェブサーバにおいても同様の構成で複数の決済サービスへのリダイレクトが可能であることを示す。ここでは、表現の統一のため、決済サーバが提供する決済ウェブサービスについても「決済アプリ」と呼ぶことにする。尚、本発明における「決済サーバ」は、ネットワークに接続されたサーバ装置上で稼働するアプリケーションサーバにより制御されるウェブアプリケーションを指すものとし、決済サービス（決済手段）と一対一に対応するものとする。よって、１つのサーバ装置やアプリケーションサーバ内に「決済サーバ」が複数、共存し得るものとする。

【0069】

本実施形態にかかる決済支援装置におけるハードウェア構成は図１と同様である。ＦＰＧＡなど他の集積回路でも同様の構成で同じ機能が実現できる。ただし、ウェブサーバでは個々の構成要素は、機能的には同じでも容量や実装方法などが、スマートフォンとは異なるのが現状では通常である。また、本実施形態では、撮像装置１０８は不要であり、表示装置１０７を利用せず、顧客に情報を提示する場合には、顧客が持つコンピュータの表示装置を利用する。

【0070】

図１５は、本実施形態にかかる決済支援システムの構成を表すブロック図である。本実施形態３にかかる決済支援システムは、顧客コンピュータ１４０２と、ＥＣサーバ１４０３と、決済サーバ１４０４と、決済支援装置１００Ｃとを備え、これらがネットワークＮを介して通信可能に接続されている。ネットワークＮは、例えば、インターネット等の通信ネットワークである。また、決済支援装置１００Ｃは、少なくとも本実施形態３にかかる決済支援システムの一構成要素である。前提として顧客２０１は予め決済支援装置１００Ｃにログインしており、決済支援装置１００Ｃ上の顧客のアカウントと紐付いたＩＤを取得するための認証トークンが、顧客コンピュータ１４０２（クライアント端末）あるいは決済支援装置１００Ｃに保存してあるものとする。

【0071】

また、顧客２０１は、予めアカウントを持つ決済アプリ（決済サービス）を選択し、決済支援装置１００Ｃに登録しておく。顧客２０１には例えば図１６の設定画面８００ＣのようなＵＩを提示し、顧客２０１は決済サービス８０１Ｃのチェックボックス１５０１を有効化することにより決済サービスを順に有効化していく。その結果、アプリ登録部２０５１Ｃは、データベース内の登録決済アプリ２０５２Ｃに、選択された決済サービスに対応する決済アプリＩＤ（決済サービスＩＤ又は決済サーバＩＤ）のリストを顧客ＩＤ１４０１に関連付けて保存しておく。

【0072】

決済手数料テーブル１４０５には、予め、決済アプリＩＤ、決済先ＩＤ、上限金額、決済手数料の組が記録されている。これは決済アプリを使用して決済先に決済を行う場合、上限金額以下の決済額に対して課される決済手数料の一覧となっている。

【0073】

実施形態１，２ではコード情報を撮像することにより決済情報を得ていたが、本実施形態では、顧客コンピュータ１４０２が決済支援装置１００Ｃにアクセスする際のＵＲＩのクエリパラメータから決済情報を得る。本実施形態３は、決済情報の取得の仕方により以下の実施例１から４を挙げて説明する。

【0074】

状況としては、顧客２０１が、何らかの商品を購入するために、ＥＣサーバ１４０３のウェブページを、顧客コンピュータ１４０２を用いて閲覧しているものとする。

【0075】

＜実施例１＞
ここで、図１７に示すシーケンス図を用いて、実施形態３の実施例１にかかる決済処理について説明する。まず、顧客２０１が「購買ボタン」を選択するなど購買のトリガーとなる操作を行う（Ｓ３０１、Ｓ３０２）と、ＥＣサーバ１４０３は、決済先ＩＤ、口座、通貨や金額などを含む決済情報をクエリパラメータとした決済支援装置１００ＣへのＵＲＩを、顧客コンピュータ１４０２に送信する（Ｓ３０３）。これを受信した顧客コンピュータ１４０２は、そのＵＲＩを使って決済支援装置１００Ｃへアクセスする（Ｓ３０４）。例えば、ＥＣサーバ１４０３は、決済支援装置１００Ｃへ転送（リダイレクト）させるように当該ＵＲＩを顧客コンピュータ１４０２に送信してもよい。決済支援装置１００Ｃの決済情報解析部２０７Ｃは、顧客コンピュータ１４０２からアクセスされたＵＲＩのクエリパラメータを解析して決済情報を抽出し（Ｓ３０５）、抽出した決済情報を選択部２０５３Ｃに渡す。尚、決済情報解析部２０７Ｃは、決済情報取得部の一例である。

【0076】

すると、決済支援装置１００Ｃの選択部２０５３Ｃは、保存されている認証トークンを利用して顧客のＩＤを特定し、これをキーとしてデータベースを検索し、登録決済アプリ２０５２Ｃ（１以上の決済アプリＩＤのリスト）を取得する。そして、選択部２０５３Ｃは、取得された決済アプリＩＤのリストと、決済情報に含まれる決済先ＩＤとに基づいて、決済手数料テーブル１４０５から次の３つの条件を同時に充足する行（組み合わせ）の中で、決済手数料が最低の行を検索する。
・決済手数料テーブル１４０５の決済アプリＩＤが、取得された決済アプリＩＤのリストのいずれかと一致する。
・決済手数料テーブル１４０５の決済先ＩＤが、決済情報の決済先ＩＤがと一致する。
・決済手数料テーブル１４０５の上限金額が、決済情報の金額を超える。
つまり、選択部２０５３Ｃは、選択基準情報と決済情報に基づいて決済処理を行わせる決済サーバを選択する（Ｓ３０６）。

【0077】

選択部２０５３Ｃは、検索の結果、この条件に該当する行を１行も見つけることができない場合には、登録された決済アプリでは決済を行うことができないことを意味するので、エラーページを顧客コンピュータ１４０２に返す。なお、選択部２０５３Ｃは、同じ決済手数料の該当する行が複数行見つかった場合には、実施形態２において説明したように、顧客２０１が指定した優先順位に従って１行に絞ることもできる。

【0078】

選択部２０５３Ｃによる検索の結果、条件を充足した行の決済アプリＩＤを取得した場合、取得した決済アプリＩＤ及び決済情報を決済要求部２０５６Ｃへ渡す。決済要求部２０５６Ｃは、実施形態１のアプリ起動部２０５６と同様に、対応アプリテーブル２０５７Ｃから決済アプリＩＤに対応付けられた起動方法（決済要求定義情報）を検索する。尚、対応アプリテーブル２０５７Ｃは、上述した対応アプリＴＢＬ２０５７等と同等の構成であり、「決済アプリＩＤ」列が「決済サーバＩＤ」又は「決済サービスＩＤ」列に置き換わったものである。そして、選択部２０５３Ｃは、検索された決済要求定義情報と決済情報を用いて、取得された決済アプリＩＤに対応する決済サーバに対して決済情報に基づく決済処理を行わせるためのＵＲＩ（決済サーバＵＲＩ、決済要求情報）を生成する（Ｓ３０７）。決済要求部２０５６Ｃは、作成したＵＲＩをリダイレクトさせるように顧客コンピュータ１４０２へ返す（Ｓ３０８）。つまり、決済要求部２０５６Ｃは、決済要求情報を、選択された決済サーバへ転送させるようにクライアント端末へ送信する。

【0079】

決済サーバへのＵＲＩを受けた顧客コンピュータ１４０２は、受信したＵＲＩに基づいて、決済サーバ１４０４にアクセスする（Ｓ３０９）。以後の処理は、決済アプリの開発者に任される。例えば顧客２０１の認証を済ませた後、決済サーバ１４０４は、図６と同様の内容の決済承認ページ（決済詳細）を顧客コンピュータ１４０２に送信し（Ｓ３１０）、顧客コンピュータ１４０２の表示装置に表示させる（Ｓ３１１）。その後、顧客２０１が承認ボタンを選択したら（Ｓ３１２）、顧客コンピュータ１４０２は、決済サーバ１４０４に対して決済承認の旨を送信し（Ｓ３１３）、決済サーバ１４０４は決済を完了させる。

【0080】

＜実施例２＞
続いて、図１８に示すシーケンス図を用いて、実施形態３の実施例２にかかる決済処理の処理例について説明する。尚、実施例２では図１５のうち決済支援装置１００Ｃ及び決済サーバ１４０４が、本実施例２にかかる決済支援装置１００Ｄ及び決済サーバ１４０４Ｄに置き換わるものとする。また、決済支援装置１００Ｄは、実施例１の選択部２０５３Ｃ及び決済要求部２０５６Ｃの代わりに、選択部２０５３Ｄ及び決済要求部２０５６Ｄを備えるものとする。また、ステップＳ３０１からＳ３０６並びにＳ３１０以降は図１７と同様であるため、適宜、図示及び説明を省略する。

【0081】

実施例２の決済支援装置１００Ｄは、決済情報の一部あるいは全てを予め決済サーバ１４０４Ｄに送っておいて決済処理を開始し、顧客コンピュータ１４０２からはその決済処理の識別子（決済処理ＩＤ）を送るという手法を取るものもある。そのため、決済支援装置１００Ｄの選択部２０５３Ｄは、ステップＳ３０６で決済サーバを選択（特定）した後、決済情報を決済サーバ１４０４Ｄに送る（Ｓ３１４）。決済サーバ１４０４Ｄは、受信した決済情報に基づき決済処理ＩＤを発行し、決済情報と決済処理ＩＤを対応付けてデータベース（不図示）に格納し（Ｓ３１５）、決済処理ＩＤを決済支援装置１００Ｄへ返信する（Ｓ３１６）。決済要求部２０５６Ｄは、決済処理ＩＤを受け取った後、対応アプリテーブル２０５７Ｃに基づき決済サーバＵＲＩを生成する（Ｓ３０７ａ）。このとき、決済要求部２０５６Ｄは、決済サーバＵＲＩのパラメータに決済情報の代わりに決済処理ＩＤを設定する。そして、決済要求部２０５６Ｄは、生成した決済サーバＵＲＩを顧客コンピュータ１４０２に返す（Ｓ３０８ａ）。この時、対応アプリテーブル２０５７Ｃの「起動方法」の列には決済情報を入れなくても良くなる。そして、顧客コンピュータ１４０２は、決済処理ＩＤが設定された決済サーバＵＲＩに基づき決済サーバ１４０４Ｄにアクセスする（Ｓ３０９ａ）。決済サーバ１４０４Ｄは、アクセス時に指定された決済処理ＩＤにより前記データベースを検索して決済情報を特定し、当該特定した決済情報を用いて、図１７のステップＳ３１０以降の処理を行う。

【0082】

＜実施例３＞
同様に、決済支援装置も全ての決済情報を顧客コンピュータ１４０２から得る必要はなく、予めＥＣサーバ１４０３から入手しておいても良い。ここで、図１９に示すシーケンス図を用いて、実施形態３の実施例３にかかる決済処理の処理例について説明する。尚、実施例３では図１５のうち決済支援装置１００Ｃ及びＥＣサーバ１４０３が、本実施例３にかかる決済支援装置１００Ｅ及びＥＣサーバ１４０３Ｅに置き換わるものとする。また、決済支援装置１００Ｅは、実施例１の決済情報解析部２０７Ｃの代わりに、決済情報解析部２０７Ｅを備えるものとする。また、ステップＳ３０１、Ｓ３０２、並びに、Ｓ３０６以降は図１７と同様であるため、適宜、図示及び説明を省略する。

【0083】

まず、ＥＣサーバ１４０３Ｅは、ステップＳ３０２の後、決済情報を決済支援装置１００Ｅへ送信する（Ｓ３１４ａ）。そして、決済支援装置１００Ｅの決済情報解析部２０７Ｅは、受け付けた決済情報に決済情報ＩＤを付与して、決済情報と決済情報ＩＤを対応付けてデータベースに格納し（Ｓ３１５ａ）、ＥＣサーバ１４０３Ｅに決済情報ＩＤを返す（Ｓ３１６ａ）。そして、ＥＣサーバ１４０３Ｅは、決済支援装置１００ＥのＵＲＩにこの決済情報ＩＤを付加して、顧客コンピュータ１４０２に送る（Ｓ３０３ａ）。顧客コンピュータ１４０２は、これに基づいて決済支援装置１００Ｅにアクセスし、結果的に決済情報解析部２０７Ｅに決済情報ＩＤを渡す（Ｓ３０４ａ）。決済情報解析部２０７Ｅは、決済情報ＩＤを抽出し（Ｓ３０５ａ）、この決済情報ＩＤを元にデータベースを検索し、先に格納された決済情報を読み出す（Ｓ３０５ｂ）。そして、決済情報解析部２０７Ｅが読み出した決済情報を選択部２０５３Ｃに渡した後の処理は、前述の処理と同様であるためここでは説明を省略する。

【0084】

＜実施例４＞
図２０に示すシーケンス図を用いて、実施形態３の実施例４にかかる決済処理の処理例について説明する。尚、実施例４では図１５のうち決済支援装置１００Ｃ、ＥＣサーバ１４０３及び決済サーバ１４０４が、本実施例４にかかる決済支援装置１００Ｆ、ＥＣサーバ１４０３Ｆ及び複数の決済サーバ１４０４Ｆに置き換わるものとする。また、決済支援装置１００Ｆは、決済情報解析部２０７Ｃ、選択部２０５３Ｃ及び決済要求部２０５６Ｃの代わりに、決済情報解析部２０７Ｆ、選択部２０５３Ｆ及び決済要求部２０５６Ｆを備えるものとする。また、複数の決済サーバ１４０４Ｆは、決済支援装置１００Ｆが選択可能な決済手段に対応する決済サーバであるものとする。また、ステップＳ３０１、Ｓ３０２、並びに、Ｓ３０７ａ以降は図１８と同様であるため、適宜、図示及び説明を省略する。

【0085】

まず、ＥＣサーバ１４０３Ｆは、ステップＳ３０２の後、決済情報を複数の決済サーバ１４０４Ｆのそれぞれへ送信する（Ｓ３１４ｂ）。ここで、ＥＣサーバ１４０３Ｆは、複数の決済サーバ１４０４Ｆの宛先情報のリストを予め保持しているものとする。そして、決済サーバ１４０４Ｆの少なくとも一部は、受け付けた決済情報に決済処理ＩＤを付与して、決済情報と決済処理ＩＤを対応付けてデータベースに格納し（Ｓ３１５ｂ）、ＥＣサーバ１４０３Ｆに決済処理ＩＤを返す（Ｓ３１６ｂ）。そして、ＥＣサーバ１４０３Ｆは、決済支援装置１００ＦのＵＲＩに、ステップＳ３１６ｂにより受け付けた決済処理ＩＤのリストと決済情報の一部（一部決済情報）を付加して、顧客コンピュータ１４０２に送る（Ｓ３０３ｂ）。顧客コンピュータ１４０２は、これに基づいて決済支援装置１００Ｆにアクセスし、結果的に決済情報解析部２０７Ｆに決済処理ＩＤのリストと、決済先など決済サーバ選択に必要な一部決済情報を渡す（Ｓ３０４ｂ）。決済情報解析部２０７Ｆは、決済処理ＩＤのリストと一部決済情報を抽出する（Ｓ３０５ｂ）。そして、決済支援装置１００Ｆの選択部２０５３Ｆは、選択基準情報と一部決済情報に基づいて決済サーバ１４０４Ｆを選択する（Ｓ３０６ｂ）。

【0086】

ここで、決済要求部２０５６Ｆは、Ｓ３０４ｂにて受信した決済処理ＩＤを含めて、決済サーバＵＲＩを生成する（Ｓ３０７ａ）。以降の処理は、図１８と同じである。

【0087】

＜実施例５＞
さて、データベースの情報は必ずしも決済支援装置の中になくても良い。決済情報サーバを用意することによってその考え方を推し進めたものが実施例５である。図２１によって、決済情報を受信する別の方法を説明する。

【0088】

図２１は、実施形態３の実施例５にかかる決済支援システムの構成及び決済処理の流れを示す図である。図２１は、図１５と比べて、ネットワークＮ（不図示）と接続された決済情報サーバ１４０６が追加され、決済支援装置１００Ｃ及びＥＣサーバ１４０３が、決済支援装置１００Ｇ及びＥＣサーバ１４０３Ｇに置き換わるものとする。また、決済情報解析部２０７Ｃ、選択部２０５３Ｃ及び決済要求部２０５６Ｃが決済情報解析部２０７Ｇ、選択部２０５３Ｇ及び決済要求部２０５６Ｇに置き換わる。尚、決済支援装置１００Ｇは、決済情報サーバ１４０６のアクセス先を特定可能な情報を、予め保持しているものとする。

【0089】

ＥＣサーバ１４０３Ｇがトリガーを受けた（Ｓ４０１、Ｓ４０２）後、決済情報を決済情報サーバ１４０６に送信する（Ｓ４０３）。決済情報サーバ１４０６は、受け付けた決済情報に決済情報ＩＤを付与して、決済情報と決済情報ＩＤを対応付けてデータベース（不図示）に格納し、ＥＣサーバ１４０３Ｇに決済情報ＩＤを返す（Ｓ４０４）。尚、決済情報ＩＤは、決済情報サーバ１４０６の宛先情報を含むものであっても良い。そして、ＥＣサーバ１４０３Ｇは、決済情報サーバ１４０６から決済情報ＩＤを得る。ＥＣサーバ１４０３Ｇは、この決済情報ＩＤを決済支援装置１００Ｇへの決済支援装置ＵＲＩに付加し、顧客コンピュータ１４０２に渡す（Ｓ４０５）。決済支援装置ＵＲＩを受け取った顧客コンピュータ１４０２は、これに基づいて決済支援装置１００Ｇにアクセスする（Ｓ４０６）。決済支援装置１００Ｇの決済情報解析部２０７Ｇは、決済支援装置ＵＲＩから決済情報ＩＤを抽出し、決済情報サーバ１４０６を特定し、決済情報ＩＤを決済情報サーバ１４０６に送信する（Ｓ４０７）、決済情報サーバ１４０６は、受信した決済情報ＩＤを元にデータベースを検索し、先に格納された決済情報を読み出し、読み出した決済情報を決済情報解析部２０７Ｇへ返信する（Ｓ４０８）。決済情報解析部２０７Ｇは、決済情報サーバ１４０６から受信した決済情報を選択部２０５３Ｇに渡す（Ｓ４０９）。その後、選択部２０５３Ｇは、決済サーバを選択し、決済要求部２０５６Ｇは、決済情報を含めた決済サーバＵＲＩを生成し、生成したＵＲＩにリダイレクトさせるように顧客コンピュータ１４０２へ返す（Ｓ４１０）。決済サーバへのＵＲＩを受けた顧客コンピュータ１４０２は、受信したＵＲＩに基づいて、決済サーバ１４０４にアクセスする（Ｓ４１１）。以後は図１７と同じである。

【0090】

ここで、実施例５の利点は、決済情報の情報量の制限が緩和されることである。つまり、決済支援装置ＵＲＩの長さ制限に捕らわれることがないため、ＥＣサーバ１４０３Ｇが指定できる決済アプリ数の制限が緩和される。これは決済支援装置ＵＲＩが二次元コードとして符号化されている場合にも意味がある。また、ここで決済情報ＩＤがＵＲＩである場合、決済情報解析部２０７ＦはこのＵＲＩを元に決済情報サーバ１４０６にアクセスできる。このため、決済情報サーバ１４０６は、予め決済支援装置１００Ｇが知るサーバである必要がない。また、ＥＣサーバ１４０３Ｇが決済情報を決済情報サーバ１４０６に登録する方法を示したが、ＥＣサーバ１４０３Ｇがこれを直接行う必要がなく、特に決済情報が商品の値段のように固定の場合には、決済情報は予め決済情報サーバ１４０６に記憶されていれば良い。

【0091】

以上の実施例で決済処理ＩＤや決済情報ＩＤを用いたが、これらによって決済情報を得ることができるので、決済処理ＩＤや決済情報ＩＤも広義の決済情報と捉えることができる。また、これらＩＤは、決済情報を暗号化したものであっても良い。その場合、データベースに決済情報を記憶する必要がなく、ＩＤを復号するだけで決済情報を得ることができる。特に、実施例４のように、結果的に選択されない複数の決済サーバに決済情報を送り付ける場合でも、記憶領域を使用しなくて済むので、有効である。

【0092】

本実施形態では、ウェブページの送受信をもってウェブアプリを実装する例を示したが、ＨＴＭＬやｈｔｔｐｓに限らず、ｊｓｏｎ（JavaScript（登録商標） Object Notation）など他の形式・プロトコルで同様の情報を送受信しても良い点に触れておく。つまり、ウェブアプリだけでなくＡＰＩの実装としても同様の効果が得られる。

【0093】

以上、本実施形態では、本発明をウェブアプリとして実装する例を示した。これにより、スマートフォンアプリ以外の形でも本発明を実施できることを示した。更に、決済アプリを選択するに当たって優先順位を利用すること以外にも方法があることを示した。そして、決済情報サーバを導入することによって、対応できる決済アプリの数の制限を緩和し、ＵＲＩを短くしたり、二次元コードの面積を削減したりすることができることを示した。

【0094】

＜その他の実施形態＞
以上、決済アプリ２０８を起動するのにＵＲＩ形式を利用したが、実際には、ＯＳが定義する形式でアプリを起動するべきなのは言うまでもない。もし、ＵＲＩ形式のように１つの引数で他のアプリが起動できないのならば、図１３又は図１４で示したように複数の引数において引数生成の処理を繰り返せば良い。

【0095】

本明細書では、いくつかの実施形態を示したが、紙面の都合で全ての要素の組み合わせを並べることができなかった。それぞれの実施形態で以下の構成要素は特に入れ替え可能であることをここに述べておく。

【0096】

例えば、実施形態１における提示決済情報２０６は、決済手段を特定する情報（例えば、決済サービスの識別情報）を明示的には含まないものであってもよい。この場合、選択部２０５３は、復号された提示決済情報２０６を解析して決済手段を特定し、特定した決済手段と選択基準情報とに基づいて、決済に用いる決済プログラムを選択する。そして、アプリ起動部２０５６は、選択された決済プログラムに対応する起動定義情報を対応アプリテーブル２０５７から読み出し、当該起動定義情報を用いて当該選択された決済プログラムを起動させるものであればよい。この場合、記憶部は、複数種類の決済手段ごとの提示決済情報の書式を予め保持しており、選択部２０５３は、記憶部に保持された書式を参照して、復号されたＵＲＩを解析して決済手段を特定するとよい。

【0097】

例えば、実施形態３においてＥＣサイトによる決済情報（また決済情報ＩＤ）の提示を、実施の形態１，２にて説明したように、提示決済情報による決済情報（または決済情報ＩＤ）の提示を行うようにしてもよい。さらには、電子メールなどのメッセージによって決済情報（または決済情報ＩＤ）を提示するようにしてもよい。
また、実施の形態１，２における決済アプリ起動アプリの起動処理と、実施の形態３における決済支援装置へのアクセス処理とを入れ替えてもよい。
さらには、実施の形態１，２における決済アプリの起動処理と、実施の形態３の実施例２又は４における決済サーバへのアクセス処理を入れ替えてもよい。

【0098】

また、決済情報を撮像装置１０８によって読み取る方式を説明したが、通信部１０５を用いて電子的に決済情報を受け取ることも可能である。あるいは、撮像装置１０８であっても、二次元コードやバーコード以外の情報を読み取っても良い。例えば、ＯＣＲ（光学的文字認識）によって、決済情報を文字として読み取っても良い。あるいは、画像に写っているロゴなどに対して、機械学習や画像特徴量などを用いた画像認識を適用して、決済先などの決済情報を特定しても良い。

【0099】

また、決済アプリ２０８の具体例として、銀行やクレジットカードの決済アプリを挙げたが、他の決済方法でも良い。例えば、仮想通貨による決済を行う場合には、口座の代わりにブロックチェーン上のアドレスを利用すれば良い。また、その場合、決済手段は、特定の仮想通貨による送金が挙げられ、決済機関は、仮想通貨の取引所であってもよく、決済アプリ２０８は、特定の仮想通貨の送金を指示するプログラムであってもよい。

【0100】

また、情報をクエリパラメータとして渡す方法をこれまで説明してきたが、パスパラメータを利用しても、ＵＲＩのパスの一部として同じ情報を入れることも可能である。あるいは、別のプロトコルを定義し同じ情報を送るのも同値であると考える。

【0101】

尚、上述の実施の形態では、ハードウェアの構成として説明したが、これに限定されるものではない。本開示は、任意の処理を、ＣＰＵにコンピュータプログラムを実行させることにより実現することも可能である。

【0102】

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ ｓｔｏｒａｇｅ ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ－ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

【0103】

尚、本開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】