JP7072537B2 - 代金決済システム、立替払い管理サーバ及びプログラム - Google Patents

Description

本発明は、代金の決済の代行を行なう代金決済システム、立替払い管理サーバ及びプログラムに関する。

近年、外国人の観光を奨励していることから、観光を目的として訪日する外国人（以下、訪日外国人）が増加している。
国際的には、安全面から現金を持ち歩くことを避けるため、買い物などの際に現金で支払うことが少なく、クレジットカードによる決済を行なうことが一般的である。
そのため、訪日外国人は、日本においても、物品を買った際や、サービスの提供を受けた際（以下、買った物品、受けたサービスを総称して商品と示す）など、クレジットカードを用いて決済を行なうことが多い。

しかし、訪日外国人が所持しているクレジットカードが、商品の代金の決済に使用できるか否かは、商品を購入する店舗の各々で、一々確認しないと判らない。
特に、海外で発行されたクレジットカードには、自国内のみで使用可能なものもあり、訪日外国人がそれを認識出来ていない場合もある。
このため、自身の所持するクレジットカードがどの店舗で決済に使用できるかを、訪日外国人に対して通知し、ストレス無く商品の代金の決済をクレジットカードで行なわせることも考えられている（例えば、特許文献１）。

特開２０１６－１８４２６９号公報

従来、訪日外国人は、日本の主な観光地（東京、大阪、京都、奈良などの大都市圏）を訪れることが多かった。
しかしながら、一通り主な観光地を訪れた後、素朴な日本の環境に親しむことを目的として、地方の温泉やスキー場などを訪れるなど、訪日外国人の旅行の趣向が変化してきている。

一方、地方の観光地においては、お土産を買ったり、食事をしたり、サービスを受けたりした際、これら商品の代金の支払を現金でのみ可能な店舗が多い。
特に、規模の小さな店舗においては、クレジットカードの手数料の支払などによる経費の増加を嫌い、クレジットカードの決済端末の導入が進みにくい。
このため、地方の観光地においては、訪日外国人が商品の購入の代金の決済に、クレジットカードを使用することができない場合が多い。

また、訪日外国人に対して、観光用の交通系ＩＣカードを提供して、チャージしたＳＦ（Stored Fare）を、交通機関の利用のみでなく、所定の店舗で電子マネーとして利用可能としている。
しかし、地方の観光地においては、この電子マネーによる決済端末を置いている店舗も少なく、かつチャージされたＳＦが無くなる度に、現金により交通系ＩＣカードにチャージを行なう必要がある。

このため、訪日外国人は、母国通貨を日本円に両替して、交通系ＩＣカードにチャージを行なう手間を要し、かつ、チャージに必要な現金を携帯して観光を行なう必要がある。
結果として、訪日外国人客は、地方の観光地に訪れた際、クレジットカードなどの訪日外国人が携帯する金融手段が利用可能な大型の店舗を利用するため、規模の小さな店舗を訪日外国人が利用することが少ない。この結果、訪日外国人が地方の観光地を多く訪れても、クレジットカード決済が行えない規模の小さな店舗が経済的な恩恵を受けにくい。

本発明は、このような事情に鑑みてなされたもので、クレジットカード、電子マネーや現金などを使用しなくとも商品の購入が行え、所定のタイミングで商品を購入した代金の決済を一括して行なえ、訪日外国人がストレス無く観光を行なうことができる代金決済システム、立替払い管理サーバ及びプログラムを提供することを目的とする。

この発明は上述した課題を解決するためになされたもので、本発明の代金決済システムは、利用者が店舗で購入した商品の代金を示す代金情報コードを生成する店舗端末と、前記代金情報コードに示される前記代金の支払を、第三者の立て替え払いにより行なう決済依頼を、前記利用者から入力される支払の可否に対応して生成する利用者端末と、前記店舗端末を管理し、前記利用者端末からの依頼により、前記代金情報コードを認証し、代金及び当該代金の受取人情報を取得して前記利用者端末へ送信する店舗管理サーバと、前記利用者端末を管理し、当該利用者端末から供給される支払情報に前記第三者の預金口座情報を付加して支払依頼情報を生成する利用者管理サーバと、前記決済依頼により行なわれた前記代金の立替払い情報として、前記支払依頼情報における前記利用者を識別する利用者識別情報とともに、前記代金の金額とを対応付けて、所定のデータベースにおいて管理する立替払い管理サーバとを備え、前記利用者端末が前記代金、前記受取人情報及び前記利用者の本人確認情報に基づき前記支払情報を生成し、利用者管理サーバへ送信することを特徴とする。
本発明の代金決済システムは、前記利用者管理サーバが、前記立替払い管理サーバから供給される前記立て替払いの取引結果の通知を、前記利用者及び前記店舗端末の各々に同一のタイミングで送信することを特徴とする。

本発明の代金決済システムは、前記第三者の所有する金融機関口座である第三者金融機関口座から、前記店舗の所有する金融機関口座である店舗金融機関口座に、前記代金を振込または振替する処理を実行するバンキング連携サーバをさらに有し、前記立替払い管理サーバが、前記立替払い情報に対応して、前記代金を振込または振替する立替払い実行依頼を前記バンキング連携サーバに対して行なうことを特徴とする。

本発明の代金決済システムは、前記立替払い管理サーバが、所定の期間を単位として、前記店舗毎に前記代金を集計し、集計結果の立替払いを行なう前記立替払い実行依頼を、前記バンキング連携サーバに対して行なうことを特徴とする。

本発明の代金決済システムは、前記店舗管理サーバが外部のバンキング連携サーバと連携し、前記立替払い情報に対応して、前記代金を振込または振替する立替払い実行依頼を、前記第三者の所有する金融機関口座である第三者金融機関口座から、前記店舗の所有する金融機関口座である店舗金融機関口座に、前記代金を振込・振替する処理をバンキング連携サーバを介して行なうことを特徴とする。

本発明の代金決済システムは、前記店舗端末が、前記店舗の店員の入力する前記商品の代金を含む情報を前記代金情報コードとして生成し、当該代金情報コードを所定の通信手段により前記利用者端末に送信し、前記利用者端末が、前記代金情報コードから前記代金の金額を抽出し、当該金額を前記利用者に通知して、当該利用者が前記金額の確認を行ない支払を可とする情報を入力した場合、前記決済依頼を生成することを特徴とする。
ここで、代金情報コードは、後述するように、二次元バーコード、あるいはＢｌｕｅｔｏｏｔｈ（登録商標）や赤外線などの伝送方式を通じて提供されるコード情報を用いてもよい。

本発明の代金決済システムは、前記第三者が、少なくとも訪日外国人が宿泊する宿泊施設、前記訪日外国人が利用する旅行事業者を含み、前記立て替え払いした代金を前記利用者である前記訪日外国人から回収するタイミングが、前記宿泊施設の場合、前記訪日外国人のチェックアウト時であるか、または、前記旅行事業者の場合、前記訪日外国人の旅行日程の終了時であることを特徴とする。

本発明の代金決済システムは、前記店舗端末を管理する店舗管理サーバが、前記利用者端末から送信される、前記店舗端末が生成した前記代金情報コードの認証を行ない、前記利用者端末が、前記代金情報コードが認証された場合、当該代金情報コードの示す前記代金を前記利用者に通知し、前記代金情報コードが認証されない場合、前記利用者に警告情報を通知することを特徴とする。

本発明の立替払い管理サーバは、利用者が店舗で購入した商品の代金を示す代金情報コードを生成する店舗端末と、前記代金情報コードに示される前記代金の支払を、第三者の立て替え払いにより行なう決済依頼を、前記利用者から入力される支払の可否に対応して生成する利用者端末と、前記店舗端末を管理し、前記利用者端末からの依頼により、前記代金情報コードを認証し、代金及び当該代金の受取人情報を取得して前記利用者端末へ送信する店舗管理サーバと、前記利用者端末を管理し、当該利用者端末から供給される支払情報に前記第三者の預金口座情報を付加して支払依頼情報を生成する利用者管理サーバの各々にネットワークで接続され、前記利用者端末が前記代金、前記受取人情報及び前記利用者の本人確認情報に基づき前記支払情報を生成し、利用者管理サーバへ送信する代金決済システムにおける立替払い管理サーバであり、前記決済依頼により行なわれた前記代金の立替払い情報として、前記利用者を識別する利用者識別情報とともに、前記代金の金額とを所定のデータベースにおいて対応付けて管理することを特徴とする。

本発明のプログラムは、代金情報コードに示される利用者が購入した商品の代金の支払を、第三者の立て替え払いにより行なう決済依頼を、前記利用者から入力される支払の可否に対応して生成する利用者端末と、店舗端末を管理し、前記利用者端末からの依頼により、前記代金情報コードを認証し、代金及び当該代金の受取人情報を取得して前記利用者端末へ送信する店舗管理サーバと、前記利用者端末を管理し、当該利用者端末から供給される支払情報に前記第三者の預金口座情報を付加して支払依頼情報を生成する利用者管理サーバと、前記決済依頼により行なわれた前記代金の立替払い情報として、前記支払依頼情報における前記利用者を識別する利用者識別情報とともに、前記代金の金額とを対応付けて、所定のデータベースにおいて管理する立替払い管理サーバとの各々にネットワークで接続され、前記利用者端末が前記代金、前記受取人情報及び前記利用者の本人確認情報に基づき前記支払情報を生成し、利用者管理サーバへ送信する代金決済システムにおける前記店舗端末としてコンピュータを機能させるプログラムであり、前記コンピュータに、入力される利用者が購入した商品の代金に対応し、当該代金の情報を含む代金情報コードを生成するステップ、前記代金情報コードを前記利用者端末に接続するステップを実行させるためのプログラムである。

本発明のプログラムは、利用者が店舗で購入した商品の代金を示す代金情報コードを生成する店舗端末と、前記店舗端末を管理し、利用者端末からの依頼により、前記代金情報コードを認証し、代金及び当該代金の受取人情報を取得して前記利用者端末へ送信する店舗管理サーバと、前記利用者端末を管理し、当該利用者端末から供給される支払情報に前記第三者の預金口座情報を付加して支払依頼情報を生成する利用者管理サーバと、決済依頼により行なわれた前記代金の立替払い情報として、前記支払依頼情報における前記利用者を識別する利用者識別情報とともに、前記代金の金額とを対応付けて、所定のデータベースにおいて管理する立替払い管理サーバとの各々にネットワークで接続され、前記利用者端末が前記代金、前記受取人情報及び前記利用者の本人確認情報に基づき前記支払情報を生成し、利用者管理サーバへ送信する代金決済システムにおける前記利用者端末としてコンピュータを機能させるプログラムであり、前記コンピュータに、前記代金情報コードを前記店舗端末から受信するステップ、前記代金情報コードから前記代金を抽出するステップ、前記代金の支払の可否に対応して、前記第三者の立て替え払いにより当該代金の支払を行なうことを示す前記決済依頼を生成するステップ、前記決済依頼を前記立替払い管理サーバに出力するステップ、前記利用者から入力される、前記代金の支払の可否に対応して、前記決済依頼を生成するステップを実行させるためのプログラムである。

この発明によれば、クレジットカード、電子マネーや現金などを使用しなくとも商品の購入が行え、所定のタイミングで商品を購入した代金の決済を一括して行なえ、訪日外国人がストレス無く観光を行なうことができる代金決済システム、立替払い管理サーバ及びプログラムを提供することができる。

本実施形態の訪日外国人が商品を購入した際に、第三者が購入の代金の立て替え払いを行い、所定のタイミングにて立て替えられた代金の精算を行なう構成の概念を説明する図である。 本発明の第１の実施形態による代金決済システムの構成例を示す図である。 利用者データベース１０２Ｄにおける利用者データテーブルの構成例を示す図である。 自社登録データ記憶部１０２Ｅにおける自社登録データテーブルの構成例を示す図である。 店舗登録データベース１０３Ｄにおける店舗データテーブルの構成例を示す図である。 事業者登録データベース１０３Ｅにおける事業者登録データテーブルの構成例を示す図である。 取引管理データベース１０１Ｄの取引データテーブルの構成例を示す図である。 代金決済システム１００における店舗が立替払い処理を行なう際の初期登録を説明するシーケンス図である。 代金決済システム１００における立替払い主体が立替払い処理を行なう際の初期登録を説明するシーケンス図である。 代金決済システム１００における利用者が立替払い処理を行なう動作を説明するシーケンス図である。 代金決済システム１００における利用者がバッチ型の立替払い処理のサービスを受ける動作を説明するシーケンス図である。 代金決済システム１００におけるバッチ型の立替払い処理における代金の振込・振替の動作を説明するシーケンス図である。 代金決済システム１００におけるリアルタイム型の立替払い処理の動作を説明するシーケンス図である。

＜第１の実施形態＞
以下、図面を参照して、本発明の第１の実施形態について説明する。
図１は、本実施形態の訪日外国人が商品を購入した際に、第三者（後述する立替払い主体）が購入の代金の立て替え払いを行い、所定のタイミングにて立て替えられた代金の精算を行なう構成の概念を説明する図である。

本実施形態においては、商品の購入の代金の支払には、お土産などの物品の購入の際の代金の支払、飲食店における食事の代金の支払、マッサージ、物品のレンタルなどのサービスを受けた際の対価の支払、すなわち行なった（受けた）行為に対して代金を支払う必要があるもの全てを含むのもとして説明する。
また、図１において、立替払いを行なう第三者としての立替払い主体３０１は、例えば、訪日外国人などの利用者３０２が利用する旅行事業者あるいは宿泊する宿泊施設などを運営する事業者である。ここで、立替払い主体３０１は、処理の流れを判り易く書くために便宜的に、立替払い主体３０１Ａ、３０１Ｂとして、機能単位で分割して記載している。したがって、立替払い主体３０１Ａ及び３０１Ｂの各々は、実態は同一の事業体である。

そして、ステップＡにおいて、立替払い主体３０１は、利用者３０２である訪日外国人に対して、クレジットカードが利用できない店舗においても、商品を購入する際に代金を現金による支払でなく、第三者による立替えにより行なうことができ、所定のタイミングにおいて、立替えたお金の回収が行なわれる立替払いのサービス（以下、立替払いサービス）が利用できることを説明する。

また、この立替払いサービスの処理を行なうために必要な利用者アプリケーションのダウンロード及びインストールの方法を利用者３０２に対して説明し、利用者３０２に対して利用者アプリケーションのダウンロード及びインストールを促す。
これにより、利用者３０２は、利用者アプリケーションをダウンロードし、自身の携帯する携帯端末（例えば、スマートフォンなど、以下、利用者携帯端末）に上記利用者アプリケーションをインストールする（アプリ提供）。

ステップＢにおいて、利用者３０２は、観光地などの店舗で商品を購入し（店舗からの商品・サービスの提供）、上記利用者アプリケーションにより、代金の立替払いのサービスを受けることを、店舗３０３の店員（以下、単に店員）に対して通知する。
これにより、店員は、店舗３０３に備えられた端末（例えば、スマートフォンなど、以下、店舗端末）にインストールされている上記立替払いのサービスを行なう、店舗３０３側の店舗アプリケーションを起動する。
また、上記店舗アプリケーションも、店舗３０３の店員が予めダウンロードし、店舗端末にインストールしておく必要がある。

そして、店員は、店舗アプリケーションの入力画面において、利用者３０２が購入した商品の代金を、例えば２次元バーコード（例えば、ＱＲコード（登録商標））に変換し、表示画面に対して表示する。
そして、利用者は、利用者携帯端末装置（後述する利用者携帯端末１０４）に内蔵される撮像装置により、店舗端末（後述する店舗端末１０５）に表示される２次元バーコードを読み込む（商品の代金情報をＱＲコード（登録商標）などで提示）。本実施形態においては、２次元バーコードとして説明しているが、単なるバーコードを含め、機械読み取りが可能なコードであれば、何れのコードを代金情報コードとして使用しても良い。また、Ｂｌｕｅｔｏｏｔｈ（登録商標）や赤外線（光通信の一例）などの伝送方式を通じて提供されるコード情報でもよい。

ステップＣにおいて、利用者３０２は、利用者アプリケーションにより表示される、利用者携帯端末の表示画面の代金金額を確認し、店舗端末により入力された代金金額が正しいか否かを確認し、確認して正しい金額として納得した場合、立替払いの依頼を示す入力を、利用者携帯端末を介して利用者アプリケーションに対して行なう。

ステップＤにおいて、利用者アプリケーションは、利用者携帯端末から、立替払いにおける取引データを記録して管理する立替払い主体３０１Ｂに対して、２次元バーコードが示す代金の立替え払いを依頼する立替え依頼の情報を出力する。
利用者アプリケーションから立替払いの情報を記録する立替払い依頼が供給された場合、立替払い主体３０１Ｂは、立替払いが行なわれる代金を取引データとして、利用者３０２に対応して記憶して管理する（取引データが記録される）。

ステップＥにおいて、立替払い主体３０１Ｂは、管理している取引データに対応して、立替払いの情報を立替払い主体３０１Ａに対して通知する（取引データの通知）。
また、立替払い主体３０１Ａが取引データを管理する取引データデータベースを参照することにより（取引データの参照）、自身の立替払いを行なう取引データの有無を確認する構成としても良い。

ステップＦにおいて、立替払い主体３０１Ａは、金融機関に対して利用者３０２の使用した代金（ショッピング代金）の立替払いの処理として、金融機関３０５に対して、立替払い主体の口座から店舗の口座に対する口座振込を依頼する。ここで、口座振込としているが、振替などの資金移動であってもよい。

ステップＧにおいて、金融機関３０５は、立替払い主体３０１Ａの口座振込の依頼に対応して、この立替払い主体３０１の口座から、店舗３０３の口座への代金の振込処理を行なう。
これにより、利用者３０２が購入した商品の代金が、立替払い主体３０１Ａよって店舗３０３に対して立替え払いされる。

ステップＨにおいて、立替払い主体３０１Ａは、利用者３０２から立替えた代金の回収を行なう際、所定のタイミングにおいて、立替払い主体３０１Ａが管理する取引データを参照し、利用者３０２毎に立替えた代金を集計する。
そして、立替払い主体３０１Ａは、集計した立替えた代金を、立替え払いサービスを受けた利用者の各々から回収する。

これにより、利用者３０２は、国際ブランドのクレジットカードを所有している場合、このクレジットカードを提供しているカード会社（国際ブランド）など３０６を介して、立替払い主体３０１Ａに対して、要求された立替払いの代金を返却する（立替払い主体３０１Ａの代金回収）。
また、利用者３０２は、クレジットカードではなく、電子マネー、デビッドカードあるいは現金（訪日外国人の携帯するハードカレンシー（所謂、国際通貨））などにより、立替払いの代金を返却しても良い。

以下、図を用いて、本発明の第１の実施形態による決済サービス連携システムの説明を行なう。図２は、本発明の第１の実施形態による決済サービス連携システムの構成例を示す図である。以下、決済サービス連携システムが行なう、上記図１において説明した立替払いの処理を説明する。

図２において、本実施形態の代金決済システム１００は、立替払い管理サーバ１０１、利用者管理サーバ１０２、店舗管理サーバ１０３、利用者携帯端末１０４、店舗端末１０５及び管理端末１０６の各々を備えている。立替払い管理サーバ１０１、利用者管理サーバ１０２、店舗管理サーバ１０３、利用者携帯端末１０４、店舗端末１０５及び管理端末１０６の各々は、インターネットを含む情報通信ネットワーク５００を介して接続されている。また、代金決済システム１００は、例えば、情報通信ネットワーク５００を介して、ダウンロードサーバ２０１、カード会社サーバ２０２、カード決済管理サーバ２０３、バンキング連携サーバ２０４、金融機関サーバ２０５それぞれと接続されている。

店舗端末１０５は、店舗アプリケーションプログラムがインストールされており、店舗アプリケーションが起動された場合、店舗の店員が入力する利用者３０２が購入した商品の代金情報を、所定の代金情報コードに変換する。
そして、店舗端末１０５は、店員の操作により、上記代金情報コードを利用者携帯端末１０４に送信する。
ここで、代金情報コードは、二次元コード等の機械読み取りが可能なコードを表示し、利用者携帯端末１０１で読み取ることで取得される構成でもよい。なお、送信は、Ｂｌｕｅｔｏｏｔｈ（登録商標）や赤外線などの伝送方式を通じて送信し、利用者携帯端末１０４で代金情報コードの供給を受ける構成であってもよい。

利用者携帯端末１０４は、利用者アプリケーションプログラムがインストールされている。この利用者アプリケーションが、店舗端末１０５から供給される代金情報コードから、利用者が購入した商品の代金情報を抽出する。
そして、利用者携帯端末１０４は、抽出した表示画面に代金情報を表示し、利用者からこの代金を承認して支払うことを示す入力が行なわれた場合、この代金の立替払いを依頼する情報を利用者管理サーバ１０２に送信する。

利用者管理サーバ１０２は、例えば、立替払い主体３０１が備えており、利用者アプリケーションがインストールされた利用者携帯端末１０４の各々を、利用者データベース１０２Ｄにおける利用者データテーブルにより管理する。
また、利用者管理サーバ１０２は、立替払い主体３０１の情報を、自社登録データ記憶部１０２Ｅにおける自社登録データテーブルにより管理する。
また、利用者管理サーバ１０２は、利用者携帯端末１０４から立替払いを依頼する情報が供給された場合、店舗管理サーバ１０３を介して立替払い管理サーバ１０１に対して、この立替払いを依頼する情報に対応させて決済依頼を送信する。

図３は、利用者データベース１０２Ｄにおける利用者データテーブルの構成例を示す図である。利用者データテーブルは、例えば、レコード毎に、本人確認情報に対応して、基本属性情報（居住地、生年月日、性別、旅行目的）、アプリ識別番号、クレジットカード情報、有効性確認フラグ、アプリ利用パスワードの各々の欄が設けられている。
本人確認情報は、利用者の各々を識別する識別情報（利用者識別情報）であり、例えばパスポート番号などが使用される。また、本人識別情報としては、セキュリティの観点から、利用者がダウンロードした利用者アプリケーションのアプリ識別情報を用いても良い。基本属性情報において、居住地は、訪日外国人である利用者の居住する場所を示す情報である（例えば、アメリカに居住していれば、居住地はアメリカである）。生年月日は、利用者の誕生日を示している。性別は、利用者が女性か、または男性かが記載されている。旅行目的は、日本に旅行に来た目的である。

また、アプリ識別番号は、利用者が利用している利用者アプリケーションを識別する識別番号である。クレジットカード情報は、利用者が保有するクレジットカードの情報であり、例えば国際ブランドのクレジットカードの種類及びクレジットカード番号などが記載されている。有効性確認フラグは、利用者のクレジットカードが有効であることが確認されたことを示すフラグである。アプリ利用パスワードは、利用者携帯端末１０４において利用者アプリケーションを起動する際に、認証として入力させるパスワードである。

図４は、自社登録データ記憶部１０２Ｅにおける自社登録データテーブルの構成例を示す図である。自社登録データテーブルは、例えば、レコードに、事業者識別情報に対応して、基本属性情報（店舗名、代表者氏名、生年月日、性別、取引目的）、預金口座情報（銀行、店舗、科目、口座）、暗証番号の各々の欄が設けられている。ここで、暗証番号は、例えば、ＣＤ（cash dispenser、現金自動支払機）暗証番号などを含む情報である。また、暗証番号としては、ＣＤ暗証番号に限らず、利用者の認証ができる認証情報であればいずれでも良く、例えば、トークンと呼ばれる有効期限付き情報も含まれる。

事業者識別情報は、立替払いを行なう立替払い主体となる第三者の事業者の各々を識別する識別情報である。基本属性情報において、店舗名は、立替払い主体の事業者名、会社名及び支店名などである。代表者名は、店舗の代表者の氏名である。生年月日は、店舗の代表者の誕生日である。性別は、店舗の代表者が女性か、または男性かが記載されている。取引目的は、店舗の行なう事業の目的（事業目的）の種類が記載されている（例えば、旅行事業、宿泊業など）。

預金口座情報において、銀行は、事業者が口座を有している銀行名である。店舗は、口座を有する支店名である。科目は、口座の預金科目の種別である普通預金、当座預金などが記載されている。口座は、事業者の有する口座の口座番号が記載されている。暗証番号は、事業者の口座に対して預金の引き出しや預け入れなどの処理を行なう際、認証を行なうための情報が記載されている。

図２に戻り、店舗管理サーバ１０３は、例えば、店舗３０３及び立替払い主体３０１の口座を有する金融機関３０５が備えており、当該金融機関３０５に口座を有し、かつ店舗アプリケーションがインストールされた店舗端末１０５を備えた店舗の各々を、店舗登録データベース１０３Ｄにおける店舗データテーブルにより管理する。
また、店舗管理サーバ１０３は、口座を有する立替払い主体３０１の情報を、事業者登録データベース１０３Ｅにおける事業者登録データテーブルにより管理する。

図５は、店舗登録データベース１０３Ｄにおける店舗データテーブルの構成例を示す図である。店舗データテーブルは、例えば、レコード毎に、店舗識別情報に対応して、基本属性情報（店舗名、代表者氏名、生年月日、性別、取引目的）、アプリ利用パスワード、預金口座情報（銀行、店舗、科目、口座）、暗証番号の各々の欄が設けられている。
店舗識別情報は、店舗の各々を識別する識別情報である。基本属性情報において、店舗名は、店舗の名称び支店名などである。代表者氏名は、店舗の代表者の氏名である。生年月日は、店舗の代表者の誕生日である。性別は、店舗の代表者が女性か、または男性かが記載されている。取引目的は、店舗の行なう事業の目的（事業目的）の種類が記載されている（例えば、小売業、飲食業、マッサージ、レンタル業など）。また、店舗データテーブルに対して、店舗の属性情報として、地域や商店街などを特定する情報を付加し、地域単位あるいは商店街単位で代金の集計などの処理ができる構成としてもよい。

預金口座情報において、銀行は、店舗が口座を有している銀行名である。店舗は、口座を有する支店名である。科目は、口座の預金科目の種別である普通預金、当座預金などが記載されている。口座は、店舗の有する口座の口座番号が記載されている。暗証番号は、店舗の口座に対して預金の引き出しや預け入れを行なう際、認証を行うための情報が記載されている。

図６は、事業者登録データベース１０３Ｅにおける事業者登録データテーブルの構成例を示す図である。事業者登録データテーブルは、例えば、レコード毎に、事業者識別情報に対応して、基本属性情報（事業者名、代表者氏名、生年月日、性別）、預金口座情報（銀行、店舗、科目、口座）の各々の欄が設けられている。
事業者識別情報は、すでに述べたように、立替払い主体となる事業者の各々を識別する識別情報である。

基本属性情報において、事業者名は、事業者の名称び支店名などである。代表者氏名は、事業者の代表者の氏名である。生年月日は、事業者の代表者の誕生日である。性別は、事業者の代表者が女性か、または男性かが記載されている。預金口座情報において、銀行は、店舗が口座を有している銀行名である。店舗は、口座を有する支店名である。科目は、口座の預金科目の種別である普通預金、当座預金などが記載されている。口座は、店舗の有する口座の口座番号が記載されている。

図２に戻り、立替払い管理サーバ１０１は、例えば、立替払い主体３０１が備えており、立替払い主体３０１が行なった利用者３０２の購入した商品の代金の立て替え払いを行なった情報を取引データとして、取引管理データベース１０１Ｄの取引データテーブルにおいて管理する。
また、立替払い管理サーバ１０１は、バンキング連携サーバ２０４を介して、立替払いの処理として、立替払い主体３０１の口座から、店舗３０３の口座への振込・振替処理を、金融機関サーバ２０５に依頼する。

図７は、取引管理データベース１０１Ｄの取引データテーブルの構成例を示す図である。取引データテーブルは、例えば、レコード毎に、取引ＩＤ（Identification、日付・時刻、通番）に対応して、代金金額、受取人情報（銀行、店舗、科目、口座）、利用者識別情報、依頼人情報（銀行、店舗、科目、口座）の各々の欄が設けられている。
取引ＩＤは、取引データの各々を識別する識別情報（取引データ識別情報）である。取引ＩＤにおいて、日付・時刻は、立替払いが処理された日時を示している。通番は、取引の各々を識別するための番号であり、例えば、立替払い管理サーバ１０１が行なう立替払いの取引の時系列的な順番を示している。また、取引データテーブルに対して、取引データの属性情報として、各店舗の地域や商店街などを特定する情報を付加し、地域単位あるいは商店街単位で代金の集計などの処理ができる構成としてもよい。

代金金額は、利用者が購入した商品の金額であり、立替払いの対象となる金額である。
受取人情報は、代金の振込先の口座に関する情報である。この受取人情報において、銀行は、受取人（店舗）が口座を有している銀行名である。店舗は、銀行の支店名である。科目は、口座の預金科目の種別である普通預金、当座預金などが記載されている。口座は、受取人の有する口座の口座番号が記載されている。

また、本人確認情報は、立替払いのサービスを利用する利用者の各々を識別する識別情報（利用者識別情報）であり、例えばパスポート番号などを用いる。
依頼人情報は、代金の振込元の口座に関する情報である。この依頼人情報において、銀行は、依頼人が口座を有している銀行名である。店舗は、口座を有する支店名である。科目は、口座の預金科目の種別である普通預金、当座預金などが記載されている。口座は、依頼人の有する口座の口座番号が記載されている。
振込日時は、立替払い主体の口座から店舗の口座に対して、立替払いを行なった代金が振込まれた日時を示している。

図２に戻り、ダウンロードサーバ２０１は、利用者アプリケーションプログラム及び店舗アプリケーションプログラムのダウンロードに関する処理を管理するサーバで有り、例えば、プログラムのダウンロードセンタに設けられている。
そして、ダウンロードサーバ２０１は、利用者携帯端末１０４及び店舗端末１０５の各々からのダウンロードのアクセスに対応して、利用者アプリケーションプログラム、店舗アプリケーションプログラムそれぞれを供給する。

カード会社サーバ２０２は、例えば、利用者が保有する国際ブランドのクレジットカードを発行したカード会社に備えられており、利用者が利用した支払に対応したクレジットカード決済の処理を行なう。
カード会社サーバ２０２は、クレジットカード決済において、利用者の支払先に対する代金の支払い、及びこの支払った代金を利用者が保有する金融機関の口座から引き落とすなどの処理を行なう。

カード決済管理サーバ２０３は、例えば、複数のカード会社に対するクレジット決済の要求の代行を行なう決済代行会社に備えられており、店舗や事業者からのクレジット決済の要求を、対応するカード会社のカード会社サーバ２０２に対して行なう。

バンキング連携サーバ２０４は、インターネットバンキングシステムにおいて、対応する金融機関の金融機関サーバ２０５と連携し、口座振込や口座振替などの所定のバンキングの処理を金融機関サーバ２０５に依頼するサーバである。

金融機関サーバ２０５は、各金融機関に設けられたサーバであり、口座振込や口座振替などの処理を行なう。

以下、図を用いて本実施形態の代金決済システム１００における立替払いの処理の動作について説明する。
図８は、代金決済システム１００における店舗が立替払い処理を行なう際の初期登録を説明するシーケンス図である。
ステップＦ１０１：店舗３０３の店員は、店舗３０３に備えられている店舗端末１０５を操作し、ダウンロードセンターのダウンロードサーバ２０１にアクセスする。
そして、上記店員は、店舗アプリケーションプログラムをダウンロードサーバ２０１からダウンロードを行なう処理を行なう。

ステップＦ１０２：店員は、ダウンロードした店舗アプリケーションプログラムを、店舗端末１０５にインストールする処理を行なう。
これにより、店舗アプリケーションは、店舗端末１０５において起動して使用可能となる。

ステップＦ１０３：店員は、店舗端末１０５において店舗アプリケーションを起動させ、店舗アプリケーションをアクティベートするための初期設定を行なう。
この初期設定において、店員は、店舗管理サーバ１０３に対して、店舗３０３の登録の処理を行なう。このとき、店員は、基本属性情報、アプリ利用パスワード、預金口座情報及び暗証番号などの情報を、店舗管理サーバ１０３により店舗端末１０５の表示画面に表示される初期設定画面の所定の欄に対して入力する。
これにより、店舗端末１０５は、店舗アプリケーションの制御により、店員が初期設定画面で入力した基本属性情報、アプリ利用パスワード、預金口座情報及び暗証番号などの情報を、店舗管理サーバ１０３に対して送信する。

ステップＦ１０４：店舗管理サーバ１０３は、基本属性情報、預金口座情報及び暗証番号などの情報を、初期設定を行なっている店舗３０３の認証を要求する認証依頼情報に添付して、金融機関サーバ２０５へ送信する。
そして、金融機関サーバ２０５は、受信した認証依頼情報から、基本属性情報、預金口座情報及び暗証番号などの情報を抽出し、この店舗の口座が存在するか否かの確認を行なう。

ステップＦ１０５：金融機関サーバ２０５は、自身の管理する口座において、上記店舗の口座が存在している場合、認証が正常に完了したことを、店舗管理サーバ１０３に対して送信する。
そして、店舗管理サーバ１０３は、認証が正常に完了したことが通知された場合、店舗３０３に対して店舗識別情報を付与し、これに対応して、基本属性情報、アプリ利用パスワード、預金口座情報及び暗証番号などの情報を、店舗登録データベース１０３Ｄの店舗登録データテーブルに書き込んで、店舗３０３の登録を行なう。
また、店舗管理サーバ１０３は、店舗端末１０５との間で、以降送受信する代金情報コードを暗号化する暗号化鍵を交換する（店舗端末１０５が秘密鍵を保有し、店舗管理サーバ１０３が公開鍵を保有する）。

ステップＦ１０５：店舗管理サーバ１０３は、店舗３０３が認証された後に登録が終了した場合、正常に登録処理が終了したことを示す登録結果表示を店舗端末１０５に対して送信する。
そして、店員は、店舗端末１０５の表示画面に表示される登録結果表示を確認し、店舗アプリケーションが正常に初期設定（アクティベート）されたことを確認する。
一方、店舗管理サーバ１０３は、店舗３０３が認証されないために登録を行なわなかった場合、登録処理が不成功に終了したことを示す登録結果表示を店舗端末１０５に対して送信する。
これにより、店員は、初期設定画面に入力した、基本属性情報、預金口座情報及び暗証番号などの情報に誤りが無いか否かの確認の処理を行なう。

図９は、代金決済システム１００における立替払い主体が立替払い処理を行なう際の初期登録を説明するシーケンス図である。
ステップＦ２０１：立替払い主体３０１の担当者は、事業所に備えられている管理端末１０６を操作し、利用者管理サーバ１０２にアクセスして、立替払い処理を行なうための事業者登録を行なう。
このとき、上記担当者は、利用者管理サーバ１０２により管理端末１０６の表示画面に表示される事業者登録画面における所定の欄に対して、基本属性情報（事業者名、代表者氏名、生年月日、性別）、預金口座情報（銀行、店舗、科目、口座）、暗証番号の各々の情報を入力する。
これにより、管理端末１０６は、基本属性情報（事業者名、代表者氏名、生年月日、性別）、預金口座情報（銀行、店舗、科目、口座）、暗証番号の各々の情報を、利用者管理サーバ１０２に対して送信する。

ステップＦ２０２：利用者管理サーバ１０２は、基本属性情報（事業者名、代表者氏名、生年月日、性別）、預金口座情報（銀行、店舗、科目、口座）、暗証番号の各々の情報を、初期設定を行なっている立替払い主体３０１の認証を要求する認証依頼情報に添付して、店舗管理サーバ１０３へ送信する。

ステップＦ２０３：店舗管理サーバ１０３は、基本属性情報（事業者名、代表者氏名、生年月日、性別）、預金口座情報（銀行、店舗、科目、口座）、暗証番号の各々の情報が添付された認証依頼情報を、金融機関サーバ２０５へ送信する。
そして、金融機関サーバ２０５は、受信した認証依頼情報から、基本属性情報（事業者名、代表者氏名、生年月日、性別）、預金口座情報（銀行、店舗、科目、口座）、暗証番号の各々の情報を抽出し、この事業者（立替払い主体３０１）の口座が存在するか否かを確認を行なう。

ステップＦ２０４：次に、金融機関サーバ２０５は、自身の管理する口座において、上記事業者（立替払い主体３０１）の口座が存在している場合、認証が正常に完了したことを店舗管理サーバ１０３に対して送信する。

ステップＦ２０５：店舗管理サーバ１０３は、認証が正常に完了した場合、事業者（立替払い主体３０１）に対して事業者識別情報を付与する。
また、店舗管理サーバ１０３は、上記事業者識別情報に対応して、基本属性情報（事業者名、代表者氏名、生年月日、性別）、預金口座情報（銀行、店舗、科目、口座）、暗証番号等の各々の情報を、事業者登録データベース１０３Ｅの事業者登録データテーブルに書き込んで、事業者（立替払い主体３０１）の登録を行なう。ここで、店舗管理サーバ１０３は、利用者管理サーバ１０２との間で、以降送受信する代金情報コードを暗号化する暗号化鍵を交換する（利用者管理サーバ１０２が秘密鍵を保有し、店舗管理サーバが公開鍵を保有する）。
そして、店舗管理サーバ１０３は、事業者識別情報、基本属性情報（事業者名、代表者氏名、生年月日、性別）、預金口座情報（銀行、店舗、科目、口座）、暗証番号等の各々の情報を登録結果情報として利用者管理サーバ１０２に対して送信する。

ステップＦ２０６：そして、利用者管理サーバ１０２は、登録結果情報の結果として、店舗管理サーバ１０３が事業者（立替払い主体３０１）の登録を行なったことを示している場合、自社登録データ記憶部１０２Ｅの自社登録データテーブルに対して、事業者識別情報（第三者識別情報）に対応して、基本属性情報（店舗名、代表者氏名、生年月日、性別、取引目的）、預金口座情報（銀行、店舗、科目、口座）、暗証番号の各々を書き込んで記憶させる。

また、利用者管理サーバ１０２は、登録された事業者（立替払い主体３０１）の管理端末１０６に対して、正常に登録処理が終了したことを示す登録結果表示を送信する。
そして、担当者は、管理端末１０６の表示画面に表示される登録結果表示を確認し、店舗アプリケーションが正常に初期設定（アクティベート）されたことを確認する。
一方、利用者管理サーバ１０２は、事業者（立替払い主体３０１）が認証されないために登録を行なわれなかった場合、登録処理が不成功に終了したことを示す登録結果表示を管理端末１０６に対して送信する。
これにより、担当者は、事業者登録画面に入力した、事業者識別情報、基本属性情報、預金口座情報及び暗証番号などの情報に誤りが無いか否かの確認の処理を行なう。

図１０は、代金決済システム１００における利用者が立替払い処理を行なう際の動作を説明するシーケンス図である。
ステップＦ３０１：訪日外国人などの利用者は、事業者（立替払い主体３０１）からの情報提供（インターネット、あるいは対面で直接に説明）により、現金やクレジットカードを用いることなく、商品の購入を行なうことができる立替払いのサービスの存在を知る。
そして、立替払いのサービスを受ける場合、利用者は、スマートフォンなどの利用者携帯端末１０４に対して、利用者アプリケーションプログラムのダウンロードを行なう。
このとき、利用者は、利用者携帯端末１０４を操作し、ダウンロードセンターのダウンロードサーバ２０１にアクセスする。
そして、上記利用者は、利用者アプリケーションプログラムをダウンロードサーバ２０１からダウンロードを行なう処理を行なう。

ステップＦ３０２：利用者は、ダウンロードした利用者アプリケーションプログラムを、利用者携帯端末１０４にインストールする処理を行なう。
これにより、利用者アプリケーションは、利用者携帯端末１０４において起動して使用可能となる。

ステップＦ３０３：利用者は、利用者携帯端末１０４において利用者アプリケーションを起動させ、利用者アプリケーションをアクティベートするための初期設定を行なう。
この初期設定において、利用者は、利用者管理サーバ１０２に対して、立替払いサービスを受ける訪日外国人としての利用者の登録の処理を行なう。このとき、利用者は、基本属性情報（居住地、生年月日、性別、旅行目的）、本人確認情報、クレジットカード情報、アプリ利用パスワードなどの情報を、利用者管理サーバ１０２により利用者携帯端末１０４の表示画面に表示される初期設定画面の所定の欄に対して入力する。
これにより、利用者携帯端末１０４は、利用者アプリケーションの制御により、利用者が初期設定画面で入力した基本属性情報、本人確認情報、クレジットカード情報、アプリ利用パスワードなどの情報を、利用者管理サーバ１０２に対して送信する。

ステップＦ３０４：事業者（立替払い主体３０１）は、利用者管理サーバ１０２が受信した、基本属性情報、本人確認情報をもとに、本人確認結果の判定を行なう。
事業者（立替払い主体３０１）は、本人確認結果、サービス提供可能と判定できる場合に、初期設定を行なっている利用者の保有するクレジットカードの有効性の確認を要求する有効性確認依頼情報を、立替管理サーバ１０１によりカード決済管理サーバ２０３に対して送信する。
また、このとき、利用者管理サーバ１０２は、上記有効性確認依頼情報に対応して、基本属性情報、アプリ識別情報、事業者識別情報、本人確認情報、クレジットカード情報、有効性確認フラグ、アプリ利用パスワードなどの情報を、利用者データベース１０２Ｄの利用者データテーブルに書き込んで、利用者の仮登録を行なう。ここで、有効性確認フラグは、有効性が確認される前であるため、非有効を示すフラグ（フラグビットが立っていない状態）となっている。

ステップＦ３０５：そして、カード決済管理サーバ２０３は、クレジットカード情報に含まれるカード会社名に対応したカード会社のカード会社サーバ２０２に対して、上記有効性確認依頼情報を送信する。
そして、カード会社サーバ２０２は、受信した有効性確認依頼情報から、クレジットカード情報を抽出し、利用者のクレジットカードが有効か否かの確認を行なう。

ステップＦ３０６：カード会社サーバ２０２は、利用者のクレジットカードの有効性の確認結果を、カード決済管理サーバ２０３に対して送信する（確認結果の通知）。

ステップＦ３０７：カード決済管理サーバ２０３は、利用者のクレジットカードの有効性の確認結果を、利用者管理サーバ１０２に対して送信する（確認結果の通知）。

ステップＦ３０７：利用者管理サーバ１０２は、有効性の確認結果として、利用者の保有するクレジットカードが有効であることを示している場合、利用者データベース１０２Ｄにおける利用者データテーブルにおける有効性確認フラグを、有効性が確認されたため、有効を示すフラグ（フラグビットが立っている状態）に書き換える。
一方、利用者管理サーバ１０２は、有効性の確認結果として、利用者の保有するクレジットカードが有効でないことを示している場合、利用者データベース１０２Ｄにおける利用者データテーブルにおける有効性確認フラグを、有効性が確認されなかったため、書き換えを行なわずに非有効を示すフラグのままとする。

ステップＦ３０８：利用者管理サーバ１０２は、登録された利用者の利用者携帯端末１０４に対して、正常に登録処理が終了したことを示す登録結果表示を送信する。
そして、利用者は、利用者携帯端末１０４の表示画面に表示される登録結果表示を確認し、利用者アプリケーションが正常に初期設定（アクティベート）されたことを確認する。
一方、利用者管理サーバ１０２は、利用者の保有するクレジットカードの有効性が確認されないために登録が終了しなかった場合、登録処理が不成功に終了したことを示す登録結果表示を利用者携帯端末１０４に対して送信する。
これにより、利用者は、初期設定画面に入力した、基本属性情報、本人確認情報、クレジットカード情報などの情報に誤りが無いか否かの確認の処理を行なう。

図１１は、代金決済システム１００における利用者がバッチ型の立替払い処理のサービスを受ける動作を説明するシーケンス図である。
ステップＦ４０１：利用者が店舗３０３で商品を購入して、立替払いのサービスを利用することを、店員に対して伝える。
店員は、店舗端末１０５において、立替払いサービスの処理を行なうため、店舗アプリケーションを起動させる。また、利用者も、利用者携帯端末１０４において、立替払いサービスの処理を行なうため、利用者アプリケーションを起動させる。

そして、店員は、店舗アプリケーションによる、店舗端末１０５の表示画面における代金の入力欄に対して、代金金額（振込金額）を入力する。
これにより、店舗端末１０５において、店舗アプリケーションは、入力された代金金額（振込金額）と、予め内部に登録されている受取人情報（銀行、店舗、科目、口座）の情報とを代金情報として、この代金情報を秘密鍵により暗号化する。
そして、店舗アプリケーションは、この代金情報から代金情報コードを生成し、店舗端末１０５の表示画面に表示する（代金情報コードの提供）。

ステップＦ４０２：利用者は、利用者携帯端末１０４に内蔵された撮像装置により、店舗端末１０５の表示画面に表示されている代金情報コードを撮像する。
そして、利用者携帯端末１０４において、利用者アプリケーションは、代金情報コード及びこの代金情報コードの検証依頼を利用者管理サーバ１０２に送信する。

ステップＦ４０３：利用者管理サーバ１０２は、利用者携帯端末１０４から入力した代金情報コード及びこの代金情報コードの検証依頼を、店舗管理サーバ１０３に送信する。
これにより、店舗管理サーバ１０３は、利用者管理サーバ１０２から入力した代金情報コードの検証を行なう。
そして、店舗管理サーバ１０３は、代金情報コードが認識可能か否かの検証、すなわち、偽造された代金情報コードではないことの検証を、得られた代金情報を公開鍵により復号することにより行い、復号ができた場合は検証結果を成功として、代金金額及び受取人情報を得る。

ステップＦ４０４：店舗管理サーバ１０３は、代金情報コードの検証結果と、代金情報として得た代金金額及び受取人情報を請求情報との各々を、利用者管理サーバ１０２に対して送信する。

ステップＦ４０５：利用者管理サーバ１０２は、検証結果が代金情報コードを認識可能であることを示す場合、店舗管理サーバ１０３から供給された請求情報（代金金額、受取人情報）を、利用者携帯端末１０４に対して送信する。
利用者携帯端末１０４が請求情報を受信した際、利用者アプリケーションは、利用者携帯端末１０４の表示画面に、請求情報における代金金額を表示する。
これにより、利用者は、利用者携帯端末１０４の表示画面に表示される代金金額を、自身が購入した商品の金額と比較して正しいか否かを確認する（請求情報の通知）。

ステップＦ４０６：次に、利用者は、利用者携帯端末１０４の表示画面に表示された代金金額の支払を了承した場合、例えば、上記表示画面の支払ボタンを押下する。
これにより、利用者携帯端末１０４において、利用者アプリケーションは、商品の代金金額及び代金の受取人情報と、予め利用者携帯端末１０４内に登録されている利用者の本人確認情報（パスポート番号など）を付加して、支払情報を生成する。ここで、本人確認情報は、セキュリティの観点からアプリ識別情報を用いてもよい。
そして、利用者アプリケーションは、生成した支払情報を、利用者携帯端末１０４から利用者管理サーバ１０２に対して送信する（支払依頼）。

ステップＦ４０７：利用者管理サーバ１０２は、利用者携帯端末１０４から上記支払情報が供給された場合、自社登録データ記憶部１０２Ｅにおける自社登録データテーブルを参照して、事業者（立替払い主体）の預金口座情報（すなわち、自身の口座情報）を読み出す。
そして、利用者管理サーバ１０２は、利用者携帯端末１０４から供給された支払情報に対して、読み出した預金口座情報を事業者の依頼人情報として付加し、支払依頼情報を生成する。
利用者管理サーバ１０２は、生成した支払依頼情報を立替払い管理サーバ１０１に対して出力する（立替払い依頼）。

ステップＦ４０８：立替払い管理サーバ１０１は、利用者管理サーバ１０２から支払依頼情報が供給された場合、取引管理データベース１０１Ｄに対する立替払いに関する当該支払依頼情報の記録を行なう。
このとき、立替払い管理サーバ１０１は、支払依頼情報から代金金額、受取人情報、本人確認情報及び依頼人情報の各々を抽出する。ここで、本人確認情報は、セキュリティの観点からアプリ識別情報を用いてもよい。
ここで、立替払い管理サーバ１０１は、この支払依頼情報に対応して取引ＩＤ（日付・時刻、通番）を付加する。

次に、立替払い管理サーバ１０１は、取引管理データベース１０１Ｄにおける取引管理データテーブルに対して、上記取引ＩＤに対応したレコードを生成する。
そして、立替払い管理サーバ１０１は、上記取引管理データテーブルにおける生成したレコードに対して、取引ＩＤに対応させて、代金金額、受取人情報（銀行、店舗、科目、口座）、本人確認情報（パスポート番号など）及び依頼人情報（銀行、店舗、科目、口座）の各々を書き込んで記憶させる（支払情報の記録）。ここで、本人確認情報は、セキュリティの観点からアプリ識別情報を用いてもよい。

本実施形態においては、例えば、この立替払い管理サーバ１０１が支払依頼情報の記録が行なわれた時点において、事業者（立替払い主体）が利用者から依頼された立替払いを承認（立替承認）したこととすることもできる。このとき、立替承認に関して、立替払いの上限の金額を予め設定しておき、この上限の金額以下であることをチェックしてもよい。
立替払い管理サーバ１０１は、取引管理データベース１０１Ｄに対する立替払いに関する当該支払依頼情報の記録が終了した後、立替払いの処理が正常に終了したことを示す立替結果を、利用者管理サーバ１０２に対して送信する。

ステップＦ４０９：
利用者管理サーバ１０２は、立替払い管理サーバ１０１から供給された立替結果を、支払情報を送信した利用者携帯端末１０４に対して送信する（取引結果通知）。
そして、利用者携帯端末１０４が立替結果を受信した場合、利用者アプリケーションは、入力した立替結果を、利用者携帯端末１０４の表示画面に取引結果として表示し、利用者に対して立替払いが正常に終了したことを通知する。
これにより、利用者は、利用者携帯端末１０４の表示画面に表示された取引結果により、立替払いが正常に終了したことを確認する。

また、図１１には示されていないが、店舗アプリケーションとは別に、利用者管理サーバ１０２から取引結果が通知される通知用アプリケーションを店舗端末１０５にインストールしておく構成としても良い。
すなわち、店舗３０３の店員は、上記通知用アプリケーションをインストールした場合、この通知用アプリケーションの初期設定において、店舗端末１０５が利用者携帯端末１０４とともに、取引結果の通知先として指定しておく。

そして、上述したステップＦ４０９において、利用者管理サーバ１０２は、立替払い管理サーバ１０１から供給された立替結果を、支払情報を送信した利用者携帯端末１０４と、当該支払情報に対応した代金の受取人である店舗３０３の店舗端末１０５との各々に対して送信する。
これにより、店舗３０３の店員は、対面している利用者が取引結果を確認した同じタイミングにおいて、利用者に対して販売した商品の代金が、店舗３０３の口座に振込まれる見込みが確定したことを確認することができる。

図１２は、代金決済システム１００におけるバッチ処理の立替払い処理における代金の振込・振替の動作を説明するシーケンス図である。このバッチ処理の代金の振込・振替の動作は、所定のタイミング、例えば毎日午前０時、日曜日の午後５時などの任意に設定された時点に行なう。
ステップＦ５０１：立替払い管理サーバ１０１は、所定のタイミングとなった際、取引管理データベース１０１Ｄにおける取引データテーブルを参照して、受取人情報における口座毎に代金金額を加算（合計）する集計処理を行なう（取引データの集計処理）。

すなわち、立替払い管理サーバ１０１は、上記取引データテーブルにおいて、同一の口座（店舗３０３の銀行口座）の代金金額の積算を行ない、店舗３０３の口座に振込む集計金額を示す精算データを算出する（精算データの作成）。
そして、立替払い管理サーバ１０１は、依頼人情報の口座から受取人情報の口座に対して、集計データの示す金額の振込・振替を行なう情報（振込・振替情報）を生成する。この振込・振替情報は、口座の振込・振替を行なう振込・振替指定日、集計データの示す金額である振込金額、依頼人情報及び受取人情報とを含んでいる。
立替払い管理サーバ１０１は、生成した上記振込・振替情報をバンキング連携サーバ２０４に対して送信する（振込・振替依頼）。

ステップＦ５０２：バンキング連携サーバ２０４は、立替払い管理サーバ１０１から情報通信ネットワーク５００を介して振込・振替情報が供給された場合、金融機関サーバ２０５に対してアクセスし、振込・振替処理の依頼を行なう。
これにより、金融機関サーバ２０５は、依頼人情報における口座から受取人情報における口座に対して、振込・振替情報における振込金額を振込む処理を行なう。

ステップＦ５０３：金融機関サーバ２０５は、依頼人情報における口座から受取人情報における口座に対する振込が終了した後、バンキング連携サーバ２０４に対して、振込・振替結果を送信する。

ステップＦ５０４：バンキング連携サーバ２０４は、情報通信ネットワーク５００を介して、振込元の口座と、振込先の口座と、振込金額と、振込日時との各々を含む振込・振替結果を、立替払い管理サーバ１０１に対して送信する。
立替払い管理サーバ１０１は、取引管理データベース１０１Ｄにおける取引管理データテーブルにおいて、振込・振替を行なった受取人情報の口座に対して、振込日時を記入して、立替払いが終了したことを記録する。

上述したように、立替払いのサービスを提供した後、立替払い主体３０１は、立替えた代金を利用者の各々から回収する必要がある。
このため、立替払い主体３０１の担当者は、管理端末１０６に利用者の本人確認情報などを入力して、立替払い管理サーバ１０１に対して、利用者毎の立替えた代金の積算の処理を行なわせる。
このとき、立替払い管理サーバ１０１は、取引管理データベース１０１Ｄにおける取引管理データテーブルを参照し、本人確認情報に基づき、利用者毎に立替えた代金を積算して、利用者毎の総立替金額を算出する。
そして、立替払い主体の事業者は、立替払いのサービスを供給した後、所定のタイミングにおいて、上記利用者毎の総立替金額に対応して、利用者の各々から立替えた代金の回収を行なう。

例えば、立替払い主体の事業者が宿泊施設である場合、所定のタイミングは利用者のチェックアウト時であり、一方、立替払い主体の事業者が旅行業者である場合、事業者の提供する旅行のプログラムが終了する時点である。この旅行のプログラムが終了する時点とは、駅に送り届ける際、あるいは空港に送り届ける際など、または電車の切符や飛行機の搭乗券などを配布する際など、旅行の最後に利用者が集合したときである。
この代金の回収において、事業者は、旅行者からクレジットカード、電子マネー、あるいは現金（利用者の保持するハードカレンシーな通貨により、例えば、ドル、ユーロ、イギリスポンド、スイスフランなどの通貨）により、利用者に対して立替えた代金を回収する。

上述したように、本実施形態によれば、利用者アプリケーションをダウンロード／インストールを行なうことにより、商品の購入に対して立替払い（いわゆる、立替払い主体に対する付け（ツケ）払い）のサービスを受けることができ、クレジットカードが使用できない店舗においても、現金を利用することなく商品の購入が行なえるため、訪日外国人が母国通過を円に両替する手間を省くことが可能となり、現金を持ち歩いたり、両替を常に行なうというストレスを受けることなく安心して地方の観光地を観光することができる。

また、本実施形態によれば、店舗アプリケーションをダウンロード／インストールを行なうことにより、クレジットカードが使用できない店舗においても、訪日外国人などの立替払いのサービスを受ける利用者に対して、商品の販売に対して現金のやりとりを行なわずに商品の販売を行なうことが可能となり、現金を携帯しない訪日外国人を顧客として取り込め、地方の観光地の店舗においても、クレジットカード端末を導入するための経費をかけずとも、売上を増加させることができる。

また、本実施形態によれば、立替払い管理サーバ１０１が立替え払い主体の口座から店舗の口座に対する代金の振替・振込を、所定の周期毎にバッチ処理により行なうため、振込・振替を依頼する回数を低減することができ、立替払い管理サーバ１０１とバンキング連携サーバ２０４との間の通信資源を有効に利用することができ、他銀行間の振込・振替が行われる場合、振込手数料の低減を実現することができる。

＜第２の実施形態＞
以下、図面を参照して、本発明の第２の実施形態について説明する。第２の実施形態は、システムの構成としては第１の実施形態と同様である。
第１の実施形態においては、利用者３０２が購入した商品の代金を立替払いする際、所定のタイミングにおけるバッチ処理により、複数の代金を集計して纏めて、立替払い主体の口座から店舗の口座への振込を行なっている。
しかし、第２の実施形態においては、利用者３０２が商品を購入した際、代金の支払を立替払いで行なう場合、リアルタイムに立替払い主体の口座から店舗の口座への振込を行なう。
以下、第１の実施形態と異なる動作のみを説明する。

図１３は、代金決済システム１００におけるリアルタイム型の立替払い処理の動作を説明するシーケンス図である。
ステップＦ６０１：利用者が店舗３０３で商品を購入して、立替払いのサービスを利用することを、店員に対して伝える。
店員は、店舗端末１０５において、立替払いサービスの処理を行なうため、店舗アプリケーションを起動させる。また、利用者も、利用者携帯端末１０４において、立替払いサービスの処理を行なうため、利用者アプリケーションを起動させる。

そして、店員は、店舗アプリケーションによる、店舗端末１０５の表示画面における代金の入力欄に対して、代金金額（振込金額）を入力する。
これにより、店舗端末１０５において、店舗アプリケーションは、入力された代金金額（振込金額）と、予め内部に登録されている受取人情報（銀行、店舗、科目、口座）の情報とを代金情報として、この代金情報を秘密鍵により暗号化する。
そして、店舗アプリケーションは、この代金情報から代金情報コードを生成し、店舗端末１０５の表示画面に表示する（代金情報コードの提供）。

ステップＦ６０２：利用者は、利用者携帯端末１０４に内蔵された撮像装置により、店舗端末１０５の表示画面に表示されている代金情報コードを撮像する。
そして、利用者携帯端末１０４において、利用者アプリケーションは、代金情報コード及びこの代金情報コードの検証依頼を利用者管理サーバ１０２に送信する。

ステップＦ６０３：利用者管理サーバ１０２は、利用者携帯端末１０４から入力した代金情報コード及びこの代金情報コードの検証依頼を、店舗管理サーバ１０３に送信する。
これにより、店舗管理サーバ１０３は、利用者管理サーバ１０２から入力した代金情報コードの検証を行なう。
そして、店舗管理サーバ１０３は、代金情報コードが認識可能か否かの検証、すなわち、偽造された代金情報コードではないことの検証を、得られた代金情報を公開鍵により復号することにより行い、復号ができた場合は検証結果を成功として、代金金額及び受取人情報を得る。

ステップＦ６０４：店舗管理サーバ１０３は、代金情報コードの検証結果と、代金情報として得た代金金額及び受取人情報を請求情報との各々を、利用者管理サーバ１０２に対して送信する。

ステップＦ６０５：利用者管理サーバ１０２は、検証結果が代金情報コードを認識可能であることを示す場合、店舗管理サーバ１０３から供給された請求情報（代金金額、受取人情報）を、利用者携帯端末１０４に対して送信する。
利用者携帯端末１０４が請求情報を受信した際、利用者アプリケーションは、利用者携帯端末１０４の表示画面に、請求情報における代金金額を表示する。
これにより、利用者は、利用者携帯端末１０４の表示画面に表示される代金金額を、自身が購入した商品の金額と比較して正しいか否かを確認する（請求情報の通知）。

ステップＦ６０６：次に、利用者は、利用者携帯端末１０４の表示画面に表示された代金金額の支払を了承した場合、例えば、上記表示画面の支払ボタンを押下する。
これにより、利用者携帯端末１０４において、利用者アプリケーションは、商品の代金金額及び代金の受取人情報と、予め利用者携帯端末１０４内に登録されている利用者の本人確認情報（パスポート番号など）を付加して、支払情報を生成する。ここで、本人確認情報は、セキュリティの観点からアプリ識別情報を用いてもよい。
そして、利用者アプリケーションは、生成した支払情報を、利用者携帯端末１０４から利用者管理サーバ１０２に対して送信する（支払依頼）。

ステップＦ６０７：利用者管理サーバ１０２は、利用者携帯端末１０４から上記支払情報が供給された場合、自社登録データ記憶部１０２Ｅにおける自社登録データテーブルを参照して、事業者（立替払い主体）の預金口座情報（すなわち、自身の口座情報）を読み出す。
そして、利用者管理サーバ１０２は、利用者携帯端末１０４から供給された支払情報に対して、読み出した預金口座情報を事業者の依頼人情報として付加し、支払依頼情報を生成する。
利用者管理サーバ１０２は、生成した支払依頼情報を立替払い管理サーバ１０１に対して出力する（立替払い依頼）。

ステップＦ６０８：立替払い管理サーバ１０１は、利用者管理サーバ１０２から支払依頼情報が供給された場合、取引管理データベース１０１Ｄに対する立替払いに関する当該支払依頼情報の記録を行なう。
このとき、立替払い管理サーバ１０１は、支払依頼情報から代金金額、受取人情報、本人確認情報及び依頼人情報の各々を抽出する。ここで、本人確認情報は、セキュリティの観点からアプリ識別情報を用いてもよい。
ここで、立替払い管理サーバ１０１は、この支払依頼情報に対応して取引ＩＤ（日付・時刻、通番）を付加する。

次に、立替払い管理サーバ１０１は、取引管理データベース１０１Ｄにおける取引管理データテーブルに対して、上記取引ＩＤに対応したレコードを生成する。
そして、立替払い管理サーバ１０１は、上記取引管理データテーブルにおける生成したレコードに対して、取引ＩＤに対応させて、代金金額、受取人情報（銀行、店舗、科目、口座）、本人確認情報（パスポート番号など）及び依頼人情報（銀行、店舗、科目、口座）の各々を書き込んで記憶させる（支払情報の記録）。ここで、本人確認情報は、セキュリティの観点からアプリ識別情報を用いてもよい。

本実施形態においては、例えば、この立替払い管理サーバ１０１が支払依頼情報の記録が行なわれた時点において、事業者（立替払い主体）が利用者から依頼された立替払いを承認（立替承認）したこととすることもできる。
そして、立替払い管理サーバ１０１は、取引管理データベース１０１Ｄに対する立替払いに関する当該支払依頼情報の記録が終了した後、依頼人情報の口座から受取人情報の口座に対して金額の振込を行なう情報（振込・振替情報）を生成する。この振替・振込情報は、口座の振込・振替を行なう振込・振替指定日、集計データの示す金額である振込金額、依頼人情報及び受取人情報とを含んでいる。
立替払い管理サーバ１０１は、生成した上記振込・振替情報をバンキング連携サーバ２０４に対して送信する（振込・振替依頼）。

ステップＦ６０９：バンキング連携サーバ２０４は、立替払い管理サーバ１０１から情報通信ネットワーク５００を介して振込・振替情報が供給された場合、金融機関サーバ２０５に対してアクセスし、振込・振替処理の依頼を行なう。
これにより、金融機関サーバ２０５は、依頼人情報における口座から受取人情報における口座に対して、振込・振替情報における振込金額（代金）を振込む処理を行なう。

ステップＦ６１０：金融機関サーバ２０５は、依頼人情報における口座から受取人情報における口座に対する代金の振込が終了した後、バンキング連携サーバ２０４に対して、振込処理が終了したことを示す振込・振替結果を送信する。

ステップＦ６１１：バンキング連携サーバ２０４は、情報通信ネットワーク５００を介して、振込元（立替払い主体）の口座と、振込先（店舗）の口座と、振込金額と、振込日時との各々を含む振込・振替結果を、立替払い管理サーバ１０１に対して送信する。
立替払い管理サーバ１０１は、取引管理データベース１０１Ｄにおける取引管理データテーブルにおいて、振込・振替を行なった受取人情報の口座に対して、振込日時を記入して、立替払いが終了したことを記録する。
そして、立替払い管理サーバ１０１は、上記記録が終了した後、立替払いの処理が正常に終了したことを示す立替結果を、利用者管理サーバ１０２に対して送信する。

ステップＦ６１２：
利用者管理サーバ１０２は、立替払い管理サーバ１０１から供給された立替結果を、支払情報を送信した利用者携帯端末１０４に対して送信する（取引結果通知）。
そして、利用者携帯端末１０４が立替結果を受信した場合、利用者アプリケーションは、入力した立替結果を、利用者携帯端末１０４の表示画面に取引結果として表示し、利用者に対して立替払いが正常に終了したことを通知する。
これにより、利用者は、利用者携帯端末１０４の表示画面に表示された取引結果により、立替払いが正常に終了したことを確認する。

また、図１４には示されていないが、店舗アプリケーションとは別に、利用者管理サーバ１０２から取引結果が通知される通知用アプリケーションを店舗端末１０５にインストールしておく構成としても良い。
すなわち、店舗３０３の店員は、上記通知用アプリケーションをインストールした場合、この通知用アプリケーションの初期設定において、店舗端末１０５が利用者携帯端末１４０とともに、取引結果の通知先として指定しておく。

そして、上述したステップＦ６１２において、利用者管理サーバ１０２は、立替払い管理サーバ１０１から供給された立替結果を、支払情報を送信した利用者携帯端末１０４と、当該支払情報に対応した代金の受取人である店舗３０３の店舗端末１０５との各々に対して送信する。
これにより、店舗３０３の店員は、対面している利用者が取引結果を確認した同じタイミングにおいて、利用者に対して販売した商品の代金が、店舗３０３の口座に振込まれたことを確認することができる。

上述したように、本実施形態によれば、第１の実施形態と同様に、利用者アプリケーションをダウンロード／インストールを行なうことにより、商品の購入に対して立替払い（いわゆる、立替払い主体に対する付け（ツケ）払い）のサービスを受けることができ、クレジットカードが使用できない店舗においても、現金を利用することなく商品の購入が行なえるため、訪日外国人が母国通過を円に両替する手間を省くことが可能となり、現金を持ち歩いたり、両替を常に行なうというストレスを受けることなく安心して、観光地（特に、地方の観光地）を観光することができる。

また、本実施形態によれば、第１の実施形態と同様に、店舗アプリケーションをダウンロード／インストールを行なうことにより、クレジットカードが使用できない店舗においても、訪日外国人などの立替払いのサービスを受ける利用者に対して、商品の販売に対して現金のやりとりを行なわずに商品の販売を行なうことが可能となり、現金を携帯しない訪日外国人を顧客として取り込め、地方の観光地の店舗においても、クレジットカード端末を導入するための経費をかけずとも、売上を増加させることができる。

また、本実施形態によれば、立替え払いにおける立替払い主体の口座から、店舗の口座への振込み・振替の処理が、利用者が立替払いのサービスを用いて商品を購入する毎にリアルタイムに行なわれるため、店舗が自身の口座に代金が振込・振替られたことを、商品を販売する毎に確認できるため、店舗が安心して立替払いのサービスを利用し、訪日外国人に対する売上を向上させることが可能となる。

また、図２に示す立替払い管理サーバ１０１、利用者管理サーバ１０２、店舗管理サーバ１０３、利用者アプリケーション及び店舗アプリケーションの各々の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、商品の購入にを立替え払いに行なうサービスにおける連携を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１００…代金決済システム
１０１…立替払い管理サーバ
１０１Ｄ…取引管理データベース
１０２…利用者管理サーバ
１０２Ｄ…利用者データベース
１０２Ｅ…自社登録データ記憶部
１０３…店舗管理サーバ
１０３Ｄ…店舗登録データベース
１０３Ｅ…事業者登録データベース
１０４…利用者携帯端末
１０５…店舗端末
１０６…管理端末
２０１…ダウンロードサーバ
２０２…カード会社サーバ
２０３…カード決済管理サーバ
２０４…バンキング連携サーバ
２０５…金融機関サーバ
３０１…立替払い主体
３０２…利用者
３０３…店舗
３０５…金融機関
３０６…カード会社
５００…情報通信ネットワーク

Claims (11)

1. 利用者が店舗で購入した商品の代金を示す代金情報コードを生成する店舗端末と、
   前記代金情報コードに示される前記代金の支払を、第三者の立て替え払いにより行なう決済依頼を、前記利用者から入力される支払の可否に対応して生成する利用者端末と、
   前記店舗端末を管理し、前記利用者端末からの依頼により、前記代金情報コードを認証し、代金及び当該代金の受取人情報を取得して前記利用者端末へ送信する店舗管理サーバと、
   前記利用者端末を管理し、当該利用者端末から供給される支払情報に前記第三者の預金口座情報を付加して支払依頼情報を生成する利用者管理サーバと、
   前記決済依頼により行なわれた前記代金の立替払い情報として、前記支払依頼情報における前記利用者を識別する利用者識別情報とともに、前記代金の金額とを対応付けて、所定のデータベースにおいて管理する立替払い管理サーバとを備え、
   前記利用者端末が前記代金、前記受取人情報及び前記利用者の本人確認情報に基づき前記支払情報を生成し、利用者管理サーバへ送信する
   ことを特徴とする代金決済システム。
2. 前記利用者管理サーバが、
   前記立替払い管理サーバから供給される前記立て替払いの取引結果の通知を、前記利用者及び前記店舗端末の各々に同一のタイミングで送信する
   ことを特徴とする請求項１に記載の代金決済システム。
3. 前記第三者の所有する金融機関口座である第三者金融機関口座から、前記店舗の所有する金融機関口座である店舗金融機関口座に、前記代金を振込または振替する処理を実行するバンキング連携サーバをさらに有し、
   前記立替払い管理サーバが、
   前記立替払い情報に対応して、前記代金を振込または振替する立替払い実行依頼を前記バンキング連携サーバに対して行なう
   ことを特徴とする請求項１または請求項２に記載の代金決済システム。
4. 前記立替払い管理サーバが、
   所定の期間を単位として、前記店舗毎に前記代金を集計し、集計結果の立替払いを行なう前記立替払い実行依頼を、前記バンキング連携サーバに対して行なう
   ことを特徴とする請求項３に記載の代金決済システム。
5. 前記店舗管理サーバが外部のバンキング連携サーバと連携し、前記立替払い情報に対応して、前記代金を振込または振替する立替払い実行依頼を、前記第三者の所有する金融機関口座である第三者金融機関口座から、前記店舗の所有する金融機関口座である店舗金融機関口座に、前記代金を振込・振替する処理をバンキング連携サーバを介して行なう
   ことを特徴とする請求項１または請求項２に記載の代金決済システム。
6. 前記店舗端末が、
   前記店舗の店員の入力する前記商品の代金を含む情報を前記代金情報コードとして生成し、当該代金情報コードを所定の通信手段により前記利用者端末に送信し、 前記利用者端末が、
   前記代金情報コードから前記代金の金額を抽出し、当該金額を前記利用者に通知して、当該利用者が前記金額の確認を行ない支払を可とする情報を入力した場合、前記決済依頼を生成する
   ことを特徴とする請求項１から請求項５のいずれか一項に記載の代金決済システム。
7. 前記第三者が、少なくとも訪日外国人が宿泊する宿泊施設、前記訪日外国人が利用する旅行事業者を含み、
   前記立て替え払いした代金を前記利用者である前記訪日外国人から回収するタイミングが、
   前記宿泊施設の場合、前記訪日外国人のチェックアウト時であるか、または、前記旅行事業者の場合、前記訪日外国人の旅行日程の終了時であることを特徴とする請求項１から請求項６のいずれか一項に記載の代金決済システム。
8. 前記店舗端末を管理する店舗管理サーバが、
   前記利用者端末から送信される、前記店舗端末が生成した前記代金情報コードの認証を行ない、
   前記利用者端末が、
   前記代金情報コードが認証された場合、当該代金情報コードの示す前記代金を前記利用者に通知し、
   前記代金情報コードが認証されない場合、前記利用者に警告情報を通知する ことを特徴とする請求項１から請求項７のいずれか一項に記載の代金決済システム。
9. 利用者が店舗で購入した商品の代金を示す代金情報コードを生成する店舗端末と、前記代金情報コードに示される前記代金の支払を、第三者の立て替え払いにより行なう決済依頼を、前記利用者から入力される支払の可否に対応して生成する利用者端末と、前記店舗端末を管理し、前記利用者端末からの依頼により、前記代金情報コードを認証し、代金及び当該代金の受取人情報を取得して前記利用者端末へ送信する店舗管理サーバと、前記利用者端末を管理し、当該利用者端末から供給される支払情報に前記第三者の預金口座情報を付加して支払依頼情報を生成する利用者管理サーバの各々にネットワークで接続され、前記利用者端末が前記代金、前記受取人情報及び前記利用者の本人確認情報に基づき前記支払情報を生成し、利用者管理サーバへ送信する代金決済システムにおける立替払い管理サーバであり、
   前記決済依頼により行なわれた前記代金の立替払い情報として、前記利用者を識別する利用者識別情報とともに、前記代金の金額とを所定のデータベースにおいて対応付けて管理する
   ことを特徴とする立替払い管理サーバ。
10. 代金情報コードに示される利用者が購入した商品の代金の支払を、第三者の立て替え払いにより行なう決済依頼を、前記利用者から入力される支払の可否に対応して生成する利用者端末と、店舗端末を管理し、前記利用者端末からの依頼により、前記代金情報コードを認証し、代金及び当該代金の受取人情報を取得して前記利用者端末へ送信する店舗管理サーバと、前記利用者端末を管理し、当該利用者端末から供給される支払情報に前記第三者の預金口座情報を付加して支払依頼情報を生成する利用者管理サーバと、前記決済依頼により行なわれた前記代金の立替払い情報として、前記支払依頼情報における前記利用者を識別する利用者識別情報とともに、前記代金の金額とを対応付けて、所定のデータベースにおいて管理する立替払い管理サーバとの各々にネットワークで接続され、前記利用者端末が前記代金、前記受取人情報及び前記利用者の本人確認情報に基づき前記支払情報を生成し、利用者管理サーバへ送信する代金決済システムにおける前記店舗端末としてコンピュータを機能させるプログラムであり、
    前記コンピュータに、
    入力される利用者が購入した商品の代金に対応し、当該代金の情報を含む代金情報コードを生成するステップ、
    前記代金情報コードを前記利用者端末に接続するステップ
    を実行させるためのプログラム。
11. 利用者が店舗で購入した商品の代金を示す代金情報コードを生成する店舗端末と、前記店舗端末を管理し、利用者端末からの依頼により、前記代金情報コードを認証し、代金及び当該代金の受取人情報を取得して前記利用者端末へ送信する店舗管理サーバと、前記利用者端末を管理し、当該利用者端末から供給される支払情報に第三者の預金口座情報を付加して支払依頼情報を生成する利用者管理サーバと、決済依頼により行なわれた前記代金の立替払い情報として、前記支払依頼情報における前記利用者を識別する利用者識別情報とともに、前記代金の金額とを対応付けて、所定のデータベースにおいて管理する立替払い管理サーバとの各々にネットワークで接続され、前記利用者端末が前記代金、前記受取人情報及び前記利用者の本人確認情報に基づき前記支払情報を生成し、利用者管理サーバへ送信する代金決済システムにおける前記利用者端末としてコンピュータを機能させるプログラムであり、
    前記コンピュータに、
    前記代金情報コードを前記店舗端末から受信するステップ、 前記代金情報コードから前記代金を抽出するステップ、
    前記代金の支払の可否に対応して、前記第三者の立て替え払いにより当該代金の支払を行なうことを示す前記決済依頼を生成するステップ、
    前記決済依頼を前記立替払い管理サーバに出力するステップ、
    前記利用者から入力される、前記代金の支払の可否に対応して、前記決済依頼を生成するステップ
    を実行させるためのプログラム。

Images