JP2019197332A - 決済システム - Google Patents

Abstract

【課題】店舗において、顧客が携帯端末により安心かつ手軽に買い物の決済を行うことが可能な、利便性の高い決済システムを提供する。【解決手段】決済システム１において、各店舗は、複数のペイメントシステムに対応したコードシート５のＱＲコードと、顧客の買い物情報を管理する店舗サーバ１３とを有する。顧客が所有する携帯端末３は、ＱＲコードを読み取るカメラ３ｂと、購入商品の金額を入力する表示部３ａと、ＳＮＳ決済サーバ６に購入商品の買い物情報を送信する通信部３ｃとを有する。ＳＮＳ決済サーバ６は、決済処理の結果を携帯端末３及び店舗サーバ１３に送信する通信機能を備えている。【選択図】図２

Description

本発明は、顧客が所有する携帯端末を用いた決済システムに関する。

従来、ユーザの携帯端末により、一度のみ有効なワンタイムパスワードを用いてユーザの認証を行って、店舗で買い物をすることができる決済システムがあった。

例えば、特許文献１のワンタイム認証システムは、ワンタイムパスワードを店舗側端末に読み取らせることで、ワンタイムパスワードに応じた認証を行う。店舗側端末は、コード化された各種情報を取得する装置である。店舗側端末には、ユーザ端末の表示部に表示されたコード情報（バーコード、二次元コード等）を光学的に読み取る読取手段が接続されており、認証用通信経路は、読取手段に接続されている。コード情報には、認証情報であるワンタイムコードの他、電子クーポン情報、ポイント情報、決済情報等の購買情報が含まれ、ＱＲコード（登録商標）として表示される（段落００３７，００４２、図１）。

また、近年では、ソーシャルネットワークキングサービスがペイメントサービスを導入し、ユーザは、予めチャージした金額内でドラッグストアや飲食店で支払いをしたり、他人へ送金したりすることが可能になっている。

特開２０１６−１３６６６４号公報

しかしながら、決済方式やソーシャルネットワークキングサービス毎に異なるコード情報を使用するため、その種類が増えると、ユーザが提示したコード情報が店舗側端末に対応していない等、決済の際に不都合が生じることがある。このようなモバイル決済は、今後ますます普及することが予想されるので、ユーザや店舗が混乱することのない、より利便性の高い決済システムが望まれていた。

本発明は、このような事情に鑑みてなされたものであり、顧客が安心かつ手軽に店舗で買い物の決済を行うことができる、利便性の高い決済システムを提供することを目的とする。

第１発明の決済システムは、顧客が所有する顧客端末を使用して、店舗で買い物の決済をすることが可能な決済システムであって、前記顧客端末から前記顧客の買い物情報を取得して決済処理を行う決済サーバを備え、各店舗は、複数のペイメントシステムに対応した認証コードと、顧客の決済情報を管理する店舗サーバとを有し、前記顧客端末は、前記認証コードを読み取る顧客端末読取部と、前記顧客が購入する購入商品の金額を入力する顧客端末入力部と、前記決済サーバに前記購入商品に関する前記買い物情報を送信する顧客端末通信部とを有し、前記決済サーバは、前記決済処理の結果を前記顧客端末及び前記店舗サーバに送信する通信機能を備えていることを特徴とする。

本発明において、顧客が店舗で買い物をする際、顧客端末の顧客端末読取部により買い物をする店舗の認証コード（例えば、ＱＲコード）を読み取る。この認証コードは、ユーザが利用する複数のペイメントシステムに対応しているので、認証コードがペイメントシステム毎に異なる場合と比較して、店舗側の負担が大幅に削減される（認証コードがペイメントシステム毎に異なる場合、店舗は、取り扱うペイメントシステムの数だけ認証コードを用意する必要がある）。この認証コードにより顧客端末が店舗情報を取得するとともに、顧客の利用するペイメントシステムがその店舗で使用できることが確認される。

その後、顧客は、顧客端末の顧客端末入力部により購入商品の金額を入力し、顧客端末通信部により買い物情報を決済サーバに送信する。すなわち、決済サーバには、商品名、支払金額、ユーザ名等の情報が一時的に蓄えられる。その後、決済サーバにより決済処理が行われ、その結果が顧客端末及び店舗サーバに送信される。これにより、顧客は、現金を持ち歩かなくても、所有する顧客端末により安心かつ手軽に店舗で買い物の決済をすることができる。

第１発明の決済システムにおいて、前記認証コードは、印刷されて店舗内外に掲示されている、又は決済カウンタ付近に置かれていることが好ましい。

この構成によれば、顧客は、予め店舗内に掲示された認証コードを顧客端末で読み取っておくことで、決済をより簡単かつ迅速に行うことができる。

また、第１発明の決済システムにおいて、前記店舗サーバは、決済情報を表示する表示部を備え、前記表示部は、前記複数のペイメントシステムによる決済を１つの画面で表示する決済一覧画面を有していることが好ましい。

この構成によれば、複数の顧客がそれぞれ異なるペイメントシステムで決済を行った場合であっても、店舗サーバでは、決済一覧画面に決済がまとめて表示される。これにより、ペイメントサービスに依らないデータ分析が可能となる。

第２発明の決済システムは、顧客が所有する顧客端末を使用して、店舗で買い物の決済をすることが可能な決済システムであって、各店舗に設置され、顧客が利用する複数のペイメントシステムに対応し、前記顧客端末に表示された認証コードを読取可能な店舗端末と、前記店舗端末から前記認証コードを含む前記顧客の買い物情報を取得して決済処理を行う決済サーバと、からなり、前記店舗端末は、前記認証コードを読み取る店舗端末読取部と、前記顧客が購入する購入商品の金額を入力する店舗端末入力部と、前記決済サーバに前記購入商品に関する前記買い物情報を送信する店舗端末通信部とを有し、前記決済サーバは、前記決済処理の結果を前記顧客端末及び前記店舗端末に送信する通信機能を備えていることを特徴とする。

本発明において、顧客が店舗で買い物をする際、顧客端末に利用するペイメントシステムの認証コード（例えば、ＱＲコード）を表示する。そして、この認証コードを、店員が店舗端末の店舗端末読取部により読み取る。この店舗端末は、ユーザが利用する複数のペイメントシステムに対応しているので、ペイメントシステム毎に使用する店舗端末を変更する場合と比較して、店舗側の負担が大幅に削減される。この認証コードにより店舗端末が顧客情報を取得するとともに、ユーザの使用するペイメントシステムがその店舗で使用できることが確認される。

その後、店員は、店舗端末の店舗端末入力部により購入商品の金額を入力して顧客に確認させ、店舗端末通信部により買い物情報を決済サーバに送信する。すなわち、決済サーバには、商品名、支払金額、ユーザ名等の情報が一時的に蓄えられる。その後、決済サーバにより決済処理が行われ、その結果が顧客端末及び店舗端末に送信される。これにより、顧客は、現金を持ち歩かなくても、所有する顧客端末により安心かつ手軽に店舗で買い物の決済を行うことができる。

本発明によれば、顧客が携帯端末により、安心かつ手軽に店舗で買い物の決済を行うことができる。

本発明の実施の形態１に係る決済システムの概要を説明する図。 決済システムの決済処理時の情報の流れを説明するシーケンス図。 店舗サーバの表示部に表示される決済一覧画面の例。 本発明の実施の形態２に係る決済システムの概要を説明する図。 決済システムの決済処理時の情報の流れを説明するシーケンス図。 本発明の実施の形態３に係る決済システムの概要を説明する図。 決済システムの決済処理時の情報の流れを説明するシーケンス図。 決済システムの決済処理時の資金の流れを説明する図。

以下、図面を参照して、本発明の決済システムの実施形態について説明する。

［実施の形態１］
図１は、本発明の実施の形態１に係る決済システム１において、店舗で行われる顧客（一部、店員）の作業を示した図である。例えば、顧客が飲食店で食事をした後、その支払い（モバイル決済）をする場面において、顧客は、以下に示すように決済処理を行う。

まず、顧客は、自身の所有する携帯端末３（本発明の「顧客端末」）を取り出して、ペイメント機能を有するソーシャルネットワーキングサービス（以下、ＳＮＳという）を起動する。携帯端末３は、主に携帯電話やスマートフォンであるが、タブレット型ＰＣ等のモバイル機器でもよい。

図１（ａ）は、携帯端末３の表示部３ａのメニュー画面（初期画面）を示している。メニュー画面には、「E-mail」、「カメラ」、「カレンダー」等のアプリケーションのアイコンが表示されている。ここで、顧客は、ＳＮＳのアプリケーションの１つである「ＡＡＡ」を起動する。なお、図中の「ＢＢＢ」も他の種類のＳＮＳのアプリケーションであるとする。

顧客が使用するペイメントサービス（本発明の「ペイメントシステム」）は、予めチャージした金額の範囲で支払いが行える決済システムである。その利点としては、顧客が各種サービス提供会社や各店舗から直接提供される店舗情報やお買い得情報を、ＳＮＳを通じで簡単に入手できる点が挙げられる。

また、顧客は、ＳＮＳのチャットサービスを利用して、友人と各種情報を交換することもできる。この他にも、顧客は、商品情報の翻訳や価格情報等の買い物支援サービス、配信されたクーポンを利用して買い物ができる等の利益を受けることができ、結果として各店舗にも集客が見込める等の一定の利益がもたらされる。

顧客が「ＡＡＡ」を起動すると、携帯端末３の表示部３ａは、図１（ｂ）の画面に切替わる。この画面では「ＡＡＡ」で利用できるサービスが列挙されているが、今回の食事代を支払うため、顧客は「ペイメント」を選択する。

その後、携帯端末３の表示部３ａは、図１（ｃ）の画面に切替わる。ここでは、「ＡＡＡ」のペイメントサービスにおける「チャージ」、「送金」等の各機能がアイコンとともに列挙されている。次に、顧客は「スキャン」を選択して、店舗のＰＯＳレジ付近に予め用意されたＱＲコード（登録商標）を読み取る作業を行う。

ＱＲコードの代わりに他のコードを用いてもよい。何れのコードにも店舗情報等が含まれるが、これ以降はＱＲコードの場合を説明する。ＱＲコードは、ネットワーク上では暗号化されているため、情報が盗まれる危険性は非常に低い。

図１（Ａ）は、ＰＯＳレジ付近に備えられたマルチ決済コードが印刷されたコードシート５を示している。マルチ決済コード（本発明の「認証コード」）は、「ＡＡＡ」、「ＢＢＢ」、「ＣＣＣ」等のあらゆるＳＮＳ、又は他のモバイル決済に対応したＱＲコードである。今回、顧客は「ＡＡＡ」のペイメントサービスを利用したが、「ＢＢＢ」のペイメントサービスでも決済が可能である。なお、マルチ決済コードは、店舗内外に貼り出されていてもよいし、店員が所有する店舗決済端末の画面に表示されてもよい。

ＳＮＳのペイメントサービスは個人より好みがあり、国によっても主流のＳＮＳが異なっている。すなわち、顧客が利用するペイメントサービスは、当然にそれぞれ異なっている。しかし、マルチ決済コードは、どの種類のペイメントサービスにも対応しているため、顧客は安心してモバイル決済を行うことができる。また、店舗側としても、ペイメントサービス毎に異なるＱＲコードを用意する必要がないため、利便性が高く、決済時のミスも起こりにくい。

図１（ｄ）に示すように、顧客がコードシート５のマルチ決済コードを携帯端末３の背面側に設けられたカメラ３ｂ（本発明の「顧客端末読込部」、図１（ｇ）参照）で読み取ると、携帯端末３の表示部３ａは、所定のＵＲＬに接続した後、図１（ｅ）の画面に切替わる。ここで、顧客は、店員により通知された食事代金を確認し、表示部３ａ（本発明の「顧客端末入力部」）から支払金額（ここでは、３，６００円）を入力する。

その後、顧客は、携帯端末３の表示部３ａの「Ｏ．Ｋ」ボタンを操作する。このとき、携帯端末３の通信部３ｃ（本発明の「顧客端末通信部」、図１（ｇ）参照）により端末番号、支払金額等の情報が後述するＳＮＳ決済サーバ６に送信される。そして、入力した支払金額が正しく、また支払金額がチャージ金額（残高）を越えていなければ、ＳＮＳ決済サーバ６から携帯端末３に今回の決済処理の情報が送信される。これにより、携帯端末３の表示部３ａは、図１（ｆ）の画面に切替わる。なお、支払金額は、その場で引き落とされる。

図１（ｆ）は、携帯端末３の表示部３ａに「支払い成功」のメッセージと、今回引き落とされた支払金額が表示され、今回の決済処理が完了した旨の表示を示している。その後、顧客は「終了」ボタンを操作して一連の作業を終了する。また、ＳＮＳ決済サーバ６から後述する店舗サーバ１３に今回の決済処理の情報が送信される。

顧客は、携帯端末としてスマートフォンとタブレット型ＰＣの両方を所有している場合があるが、ＳＮＳのＩＤを正しく入力して個人が特定されれば、何れの端末でもペイメントサービスを起動することができる。携帯端末を機種交換したり、故障、紛失したような場合でも、ＳＮＳのアプリケーションを再インストールするだけで決済システム１を利用することができ、ハードウェアに依存しないという利点もある。

次に、図２を参照して、決済システム１の決済処理について、主に情報の流れを説明する。ここでは、決済処理が日本国内で行われるとして、その際に扱われる情報に関連する各処理（図中の（１）〜（８））について詳説する。

（１）ＳＮＳペイメントアプリ起動
顧客は、自身の所有する携帯端末３から今回の決済を行うＳＮＳのペイメントアプリケーションを起動する（図１（ａ），（ｂ）参照）。また、顧客は、ペイメントアプリケーションのＱＲコードをスキャンする機能を選択する（図１（ｃ）参照）。

（２）ＱＲコードからＵＲＬ取得
顧客は、携帯端末３のカメラ３ｂを使用して、コードシート５に印刷されたＱＲコード（マルチ決済コード）を読み取る（図１（ｄ）参照）。これにより、携帯端末３は、決済に関するＵＲＬを取得し、そのＵＲＬに接続する。

（３）支払金額入力
顧客は、携帯端末３を使用して、今回の飲食代の金額（支払金額）を入力する（図１（ｅ）参照）。

（４）決済リクエスト処理
携帯端末３は、今回の決済の取引番号、使用した携帯端末の端末番号、認証コード、支払金額及び必要に応じて商品カテゴリを、決済を管理するＳＮＳ決済サーバ６に送信する。なお、これらの情報は、ＳＮＳ決済サーバ６のデータベースに保存される。

（５）認証処理
ＳＮＳ決済サーバ６は、認証コードから名義人（顧客）、支払いをするカード（現金をチャージしたカード）のカード番号を取得する。また、ＳＮＳ決済サーバ６は、銀行口座又はカードに所定の残高があるかについても確認する。

（６）判定処理
ＳＮＳ決済サーバ６は、カードの残高を照会して決済処理を遂行する。具体的には、カードに支払金額以上の残高が残っていれば、カードのチャージ金額から支払金額を引き落とす。また、カードに支払金額以上の残高が残っていなければ（残高不足）、引き落しができないので、決済中止情報を準備する。

（７）決済リターン処理
ＳＮＳ決済サーバ６は、取引番号、支払金額、ステータスコード及び印刷用決済コードを準備する。ステータスコードとは、例えば、決済処理の成功を「１」、失敗を「０」と定義したコードであり、このコードに基づいて携帯端末３の表示部３ａに特定の表示を出力する。また、印刷用決済コードは、領収書を印刷するために必要なコードである。

（８）決済結果通知
ＳＮＳ決済サーバ６は、今回の決済結果を顧客の携帯端末３に送信し、通知する。これにより、携帯端末３の表示部３ａで決済結果表示が行われ（図１（ｆ）参照）、顧客は、決済が無事に完了したことを認識できるようになる。

また、ＳＮＳ決済サーバ６は、今回の決済結果を店舗の店舗サーバ１３にも送信する。なお、店舗サーバ１３は店舗のＰＯＳレジとネットワーク接続しており、顧客の必要に応じて領収書等を出力可能となっている。これにより、決済システム１による一連の決済処理は終了となる。

店舗サーバ１３では、複数の顧客が上述のモバイル決済を行う度に決済情報が蓄積されていく。ここで、図３に、店舗サーバ１３の表示部１３ａに表示される決済一覧画面の例を示す。

表示部１３ａにおいて、画面の左側の領域αは、「取引検索」の表示となっている。店員は、領域αの「利用期間」、「店舗名」、「ペイメント種別」、「区分（支払／返金）」、「端末番号」及び「支払／返金番号」を入力して「検索」ボタンを操作することで、該当する決済の一覧を閲覧することができる。なお、「利用期間」、「店舗名」、「ペイメント種別」及び「区分」は、プルダウンにより選択することができる。

また、表示部１３ａにおいて、画面の上方の領域βは、ページ選択キーの表示となっている。店員が取引検索を行い、該当する決済の数が多かった場合、決済一覧は、複数のページに亘って表示される。このとき、店員は、領域βの各種キーを操作することで、１ページずつの進退や、最初又は最後のページにジャンプすることができる。また、ダイレクトにページ数を入力して「ＧＯ」ボタンを操作することで、そのページにジャンプすることができる。

また、表示部１３ａにおいて、画面の大部分を占める領域γは、決済一覧画面と、その合計データの表示となっている。決済は、「日時」の欄に早い時刻から順番に並べられる。

ここで、「ペイメント種別」に示すように、顧客が「ＡＡＡ」、「ＢＢＢ」、「ＣＣＣ」等の何れのペイメントサービスを利用しても、１つの決済一覧画面にまとめて表示される。これにより、店舗側としては、ペイメントサービスに依らないデータ分析を行うことができ、どのペイメントサービスが多くの顧客に利用されているか等の情報を得ることができる。

また、決済一覧画面上方の合計データでは、「取引検索」で該当した決済の「総件数」、「総利用額」、「総返金額」及び「差引金額」が表示される。なお、各ペイメントサービスは、商品等を購入する「支払」の他、その「返金」にも対応している。このように、店舗サーバ１３は様々な決済一覧を作成することができるので、有力なマーケティングツールとなる。

以上のように、実施の形態１の決済システム１では、顧客は、自身の所有する携帯端末３を使用して、店舗で支払いをすることができる。各店舗は、複数のペイメントサービスに対応したＱＲコードを店舗内に用意しておき、顧客が携帯端末３のカメラ３ｂでＱＲコードを読み取る。そして、ＳＮＳ決済サーバ６は、携帯端末３から買い物情報を取得して決済処理を行い、決済処理の結果を携帯端末３及び店舗サーバ１３に送信する。これにより、店舗の負担が軽減されるとともに、顧客は、安心かつ手軽に店舗で買い物の決済をすることができる。

［実施の形態２］
図４は、本発明の実施の形態２に係る決済システム２０において、店舗で行われる顧客と店員の作業を示した図である。また、顧客の携帯端末等、上述の実施の形態１と同じ構成については同じ符号を付し、説明を省略する。

例えば、実施の形態１と同様に顧客が飲食店で食事をしたとき、その店舗の店員は、店舗決済端末２（本発明の「店舗端末」）を使用して飲食代の決済処理を開始する。

店舗決済端末２は持ち運びが可能で、タッチパネル方式の画面（表示部２ａ）を採用した専用端末であり、背面側にカメラ２ｂを内蔵している（図４（Ａ），（Ｅ）参照）。なお、店舗決済端末２の開口部２ｄは、領収書（レシート）の排出口である。

店舗決済端末２の代わりに、カメラを内蔵したタブレットＰＣに専用アプリケーションをインストールしたものを用いることもできる。その場合には、ネットワーク接続されたプリンタにより領収書を発行する。

決済処理を開始するにあたり、店員は、店舗決済端末２の店舗側決済用アプリケーションを起動して、店舗決済端末２の表示部２ａから「決済」を選択する（図４（Ａ）参照）。

その後、店舗決済端末２の表示部２ａは、図４（Ｂ）に示す画面に切替わるので、店員は、表示部２ａ（本発明の「店舗端末入力部」）から顧客の食事代金を入力する。顧客は、表示部２ａに表示された支払金額（ここでは、３，６００円）を確認すると、自身の所有する携帯端末３により支払いの準備を開始する。

顧客は、携帯端末３でＳＮＳ（「ＡＡＡ」）のペイメントアプリケーションを起動する（図４（ａ）参照）。その後、携帯端末３の表示部３ａは、図４（ｂ）に示す画面に切替わる。図示するように、携帯端末３の表示部３ａには、自分のＱＲコード（本発明の「識別コード」）が表示される。このＱＲコードには、主に顧客の端末番号等の情報が含まれる。

このＱＲコードについて補足すると、これは、ワンタイムパスワードと同じ機能を有し、特にインターネットに接続したり、サーバに問い合わせることなく生成される。携帯端末３の表示部３ａに表示されたＱＲコードは、例えば、６０秒毎に更新され、顧客が画面をタッチ又はスライド操作を行うことによっても更新される。すなわち、以前の買い物に使用したＱＲコードは、第三者に取得されたとしても再度、使用することはできない。従って、この決済システム２０は、顧客にとって非常に安心して利用できるものである。

次に、店員は、図４（Ｃ）に示すように、店舗決済端末２のカメラ２ｂ（本発明の「店舗端末読取部」、図４（Ｅ）参照）でＱＲコードを読み取る。ここで、店舗決済端末２は、あらゆるＳＮＳのペイメントサービスに対応しているため、顧客が「ＡＡＡ」以外のペイメントサービスを選択した場合でも携帯端末３の表示部３ａに表示されたＱＲコードを読み取ることができる。すなわち、１つの店舗決済端末２であらゆる決済用ＱＲコードに対応できるため、ペイメントシステム毎に店舗決済端末又は決済用アプリケーションを変更する必要がある場合と比較して、店舗側の負担が大幅に削減される。

その後、店舗決済端末２の通信部２ｃ（本発明の「店舗端末通信部」、図４（Ｅ）参照）により端末番号、支払金額等の情報がＳＮＳ決済サーバ６に送信される。そして、入力した支払金額が正しく、また支払金額がチャージ金額（残高）を越えていなければ、ＳＮＳ決済サーバ６から店舗決済端末２及び携帯端末３に今回の決済処理の情報が送信される。

これにより、店舗決済端末２の表示部２ａは、図４（Ｄ）に示す画面に切替わり、決済が終了した旨の表示がなされる。具体的には、決済内容として、決済日時、決済金額及び取引番号が表示される。なお、支払金額は、その場で引き落とされる。

最後に、携帯端末３の表示部３ａに「支払い成功」のメッセージと、今回引き落とされた支払金額が表示され、今回の決済処理が完了した旨の表示がなされる。その後、顧客は、「終了」ボタンを操作して一連の作業を終了する。なお、通常、店舗には、店舗決済端末２の他に店舗サーバ１３があるので、ＳＮＳ決済サーバ６から店舗サーバ１３にも今回の決済処理の情報が送信されるようにしてもよい。

次に、図５を参照して、決済システム２０の決済処理について、主に情報の流れを説明する。ここでも、決済処理が日本国内で行われるとして、その際に扱われる情報に関連する各処理（図中の（１）〜（１０））について詳説する。

（１）ＳＮＳペイメントアプリ起動
顧客は、自身の所有する携帯端末３から今回の決済を行うＳＮＳのペイメントアプリケーションを起動する。

（２）ＱＲコード表示
顧客は、ペイメントアプリのＱＲコードを表示する機能を選択し、携帯端末３の表示部３ａに自分のＱＲコードを表示する（図４（ｂ）参照）。

（３）支払金額入力
店員は、店舗決済端末２の表示部２ａから「決済」を選択して（図４（Ａ）参照）、今回の飲食代の金額（支払金額）を入力する（図４（Ｂ）参照）。

（４）ＱＲコードから認証コード取得
店員は、店舗決済端末２のカメラ２ｂを使用して、携帯端末３の表示部３ａに表示されたＱＲコード（マルチ決済コード）を読み取る（図４（Ｃ）参照）。これにより、店舗決済端末２は、決済に関する認証コードを取得する。

（５）決済リクエスト処理
店舗決済端末２は、今回の決済の取引番号、使用した携帯端末の端末番号、認証コード、支払金額及び必要に応じて商品カテゴリを、決済を管理するＳＮＳ決済サーバ６に送信する。なお、これらの情報は、ＳＮＳ決済サーバ６のデータベースに保存される。

（６）認証処理
ＳＮＳ決済サーバ６は、認証コードから名義人（顧客）、支払いをするカード（現金をチャージしたカード）のカード番号を取得する。また、ＳＮＳ決済サーバ６は、銀行口座又はカードに所定の残高があるかについても確認する。

（７）判定処理
ＳＮＳ決済サーバ６は、カードの残高を照会して決済処理を遂行する。具体的には、カードに支払金額以上の残高が残っていれば、カードのチャージ金額から支払金額を引き落とす。また、カードに支払金額以上の残高が残っていなければ（残高不足）、引き落しができないので、決済中止情報を準備する。

（８）決済リターン処理
ＳＮＳ決済サーバ６は、取引番号、支払金額、ステータスコード及び印刷用決済コードを準備する。

（９）決済結果通知
ＳＮＳ決済サーバ６は、今回の決済結果を店舗決済端末２及び携帯端末３に送信する。これにより、店舗決済端末２の表示部２ａで決済結果表示が行われる（図４（Ｄ）参照）。また、携帯端末３の表示部３ａでも決済結果表示が行われるので（図４（ｃ）参照）、顧客は、決済が無事に完了したことを認識できるようになる。

（１０）領収書印刷処理
店員は、店舗決済端末２のプリンタにより決済処理の明細（店舗、日時、端末番号、金額）、取引番号、ＱＲコードを印刷して、領収書とする。返金処理は、店舗決済端末２により印刷された領収書のＱＲコードを読み取るのが最も簡単であるが、取引番号からも決済処理を特定することができる。これにより、決済システム２０による一連の決済処理は終了となる。

以上のように、実施の形態２の決済システム２０では、顧客は、自身の所有する携帯端末３を使用して、店舗で支払いをすることができる。店舗決済端末２は各店舗に設置され、顧客が利用する複数のペイメントサービスに対応し、顧客の携帯端末３に表示されたＱＲコードを読取可能となっている。店舗決済端末２は、カメラ２ｂでＱＲコードを読み取り、金額情報とともにＳＮＳ決済サーバ６に買い物情報を送信する。そして、ＳＮＳ決済サーバ６は、店舗決済端末２から顧客の買い物情報を取得して決済処理を行い、決済処理の結果を店舗決済端末２及び携帯端末３に送信する送信する。これにより、店舗の負担が軽減されるとともに、顧客は、安心かつ手軽に店舗で買い物の決済をすることができる。

以上の決済システム１，２０の説明においては、日本国内での決済、商取引の例を示したが、これに限られるものではない。例えば、海外からの観光客がＳＮＳのペイメントサービスを利用した場合、すなわち、国境を越えた決済処理においても決済システム１，２０を利用することができる。

［実施の形態３］
図６は、本発明の実施の形態３に係る決済システム３０において、店舗で行われる顧客と店員の作業を示した図である。以下では、決済システム２０による決済処理が日本国内で、海外からの観光客（顧客）により行われるとする。また、顧客の携帯端末、店舗決済端末等、上述の実施の形態１,２と同じ構成については同じ符号を付し、説明を省略する。

例えば、日本にある電気量販店で買い物をするため、中国から訪問した顧客が商品を購入する場合、その店舗の店員は、店舗決済端末２を使用して買い物の決済処理を開始する。

買い物の決済処理を開始する場合、店員は、店舗決済端末２の店舗側決済用アプリケーションを起動して、図６（Ａ）に示す店舗決済端末２の表示部２ａから「決済」を選択する。

その後、店舗決済端末２の表示部２ａは、図６（Ｂ）に示す画面に切替わるので、店員は、顧客が購入する商品の金額を入力する。このとき、店員は、日本の通貨である円でその金額を入力する。顧客は、表示部２ａに表示された支払金額（ここでは、１２，８００円）を確認すると、自身の所有する携帯端末３により支払いの準備を開始する。

ここで、店舗決済端末２の表示部２ａで、その日の為替レートにより、中国の通貨である人民元（以下、元という）の金額を併せて表示するようにしてもよい。なお、店舗決済端末２では、店員が今回顧客が購入しする「商品カテゴリ」を入力することができ、その情報がデータベースに保存される等の機能も有する。この情報は、各店舗が顧客の消費動向を調べたり、販売戦略を立てる際に用いることができる。

次に、顧客は、図６（ａ）に示すように、携帯端末３でＳＮＳ（「ＣＣＣ」）のペイメントアプリケーションを起動する。また、顧客は、予め登録した中国の取引銀行の口座を１つ選択する。図６（ｂ）に示すように、銀行口座は複数登録することができ、購入する商品や支払金額に応じて銀行口座を切替えることができる。

顧客が銀行口座を１つ選択した場合、携帯端末３の表示部３ａは、図６（ｃ）に示す画面に切替わる。図示するように、携帯端末３の表示部３ａには、自分のＱＲコードが表示される。このＱＲコードには、主に顧客が選択した銀行口座の情報等が含まれる。

次に、店員は、図６（Ｃ）に示すように、店舗決済端末２のカメラ２ｂでＱＲコードを読み取る。ここで、店舗決済端末２は、あらゆるＳＮＳのペイメントサービスに対応しているため、顧客が「ＣＣＣ」以外のペイメントサービスを選択した場合でも携帯端末３の表示部３ａに表示されたＱＲコードを読み取ることができる。また、詳細は後述するが、この作業により認証が進んでゆき、顧客が選択した銀行口座に支払金額以上の残高が残っていれば、その金額が直ちに引き落とされる（デビット決済方式）。

その後、店舗決済端末２の表示部２ａに、決済が終了した旨の表示がなされる。具体的には、図６（Ｄ）に示すように、決済内容として、決済日時（日本時間）、決済金額及び取引番号が表示される。また、顧客が表示部２ａを見て決済処理の終了が確認できるように、「支付成功」との表示がなされる。

店舗決済端末２の表示部２ａは、基本的に店舗の店員が使用するツールであるため、日本語で表示されるが（図６（Ａ），（Ｂ）参照）、領収書の印刷処理等、店舗決済端末２を使用する各処理で、中国語による説明を表示してもよい。このように、店舗決済端末２は、必ずしも外国語が堪能でない店員と顧客とのコミュニケーションツールとしても機能するので、主要な言語をカバーしていることが好ましい。

最後に、顧客の携帯端末３にも決済処理が完了した旨が通知され、携帯端末３の表示部３ａには銀行口座から引き落とされた金額が表示される。ここで、顧客取引銀行は中国にあるので、決済は元で処理される。従って、図６（ｄ）に示すように、元による金額（￥６７３．６）が表示される。これにより、顧客は、今回の買い物で幾らを使ったのかが非常に分かり易い。

次に、図７を参照して、決済システム３０の決済処理について、主に情報の流れを説明する。ここでは、日本が第１国、中国が第２国であるとして、決済処理で扱われる情報に関連する各処理（図中の（１）〜（１２））について説明する。

（１）ＳＮＳペイメントアプリ起動
顧客は、自身の所有する携帯端末３から今回の決済を行うＳＮＳのペイメントアプリケーションを起動する（図６（ａ）参照）。

（２）ＱＲコード表示
顧客は、ペイメントアプリケーションの中で支払金額が引き落とされる銀行口座を選択する（図６（ｂ）参照）。その後、携帯端末３の表示部３ａにＱＲコードが表示される（図６（ｃ）参照）。

（３）支払金額入力
店員は、店舗決済端末２を使用して、顧客が購入する商品の金額を入力する。ここでは、円で金額（支払金額）を入力する（図６（Ｂ）参照）。

（４）ＱＲコードから認証コード取得
店員は、店舗決済端末２のカメラ２ｂを使用して、携帯端末３の表示部３ａに表示されたＱＲコードを読み取る（図６（Ｃ）参照）。これにより、店舗決済端末２は、認証コード（銀行口座の情報等）を取得する。

（５）決済リクエスト処理１
店舗決済端末２は、今回の買い物の取引番号、使用した携帯端末３の端末番号、認証コード、支払金額(円)及び商品カテゴリを、日本で決済を管理するＡ社決済サーバ６’に送信する。なお、これらの情報は、Ａ社決済サーバ６’のデータベース（後述するＡ社取引明細データベース６’ｂ）に保存される。なお、Ａ社は、ペイメントサービスの日本代理店の立場である。

（６）決済リクエスト処理２
Ａ社決済サーバ６’は、店舗決済端末２から送信された情報のうち取引番号、認証コード及び支払金額(円)を、中国で決済を管理するＢ社決済サーバ７に送信する。なお、これらの情報は、国境を越えてＢ社決済サーバ７のデータベース（後述するＢ社取引明細データベース７ｂ）に保存される。

ここで、Ａ社決済サーバ６’は、インターネットの専用回線でＢ社決済サーバ７に接続されており、Ｂ社決済サーバ７以外のサーバとは通信できないようになっている（店舗決済端末２とは通信可能）。これにより、顧客の買い物に関する情報が誤って他のサーバに送信されることがなく、セキュリティの高い取引を可能としている。

（７）認証処理
Ｂ社決済サーバ７は、認証コードから名義人（顧客）、支払いをするため選択された取引銀行名及びその銀行の口座番号を取得する。また、Ｂ社決済サーバ７は、その銀行口座に所定の残高があるか（口座情報）についても確認する。

（８）決済リクエスト処理３
Ｂ社決済サーバ７は、口座情報及び支払金額（元）を、顧客が中国で取引する顧客取引銀行の顧客取引銀行サーバ８に送信する。ここで、支払金額（元）は、その日の為替レートで円から変換した元に変換された金額である。

（９）判定処理
顧客取引銀行サーバ８は、顧客取引銀行の銀行口座の残高を照会して決済処理を遂行する。具体的には、支払金額(元)以上の残高が残っていれば、Ｂ社取引銀行サーバに対して送金通知をする。また、支払金額(元)以上の残高が残っていなければ（残高不足）、引き落しができないので、決済中止情報を送信する。

残高が残っている場合には、買い物の支払金額(元)が即時引き落とされるが、資金の流れについては、詳細を後述する。なお、送金の可否に関する決済処理の情報は、Ｂ社決済サーバ７のデータベースに保存される。

（１０）決済結果通知１
Ｂ社決済サーバ７は、今回の決済結果を顧客の携帯端末３に送信し、通知する。これにより、携帯端末３の表示部３ａで決済結果表示が行われ（図６（ｄ）参照）、顧客は、決済が無事に完了したと認識できるようになる。

（１１）決済結果通知２
Ｂ社決済サーバ７は、今回の決済結果をＡ社決済サーバ６’にも送信し、通知する。なお、決済結果の情報は、国境を越えてＡ社決済サーバ６’のデータベースに保存される。

（１２）決済リターン処理
Ａ社決済サーバ６’は、取引番号、支払金額（円）、ステータスコード及び印刷用決済コードを店舗決済端末２に送信する。これにより、店舗決済端末２の表示部２ａで決済結果表示が行われる（図６（Ｄ）参照）。

（１３）領収書印刷処理
店員は、店舗決済端末２のプリンタにより決済処理の明細（店舗、日時、端末番号、金額）、取引番号、ＱＲコードを印刷して、領収書とする。返金処理は、店舗決済端末２により印刷されたＱＲコードを読み取るのが最も簡単であるが、取引番号からも決済処理を特定することができる。これにより、決済システム１による一連の決済処理は終了となる。

最後に、図８を参照して、決済システム３０の決済処理について、主に資金の流れを説明する。図７とは異なり、中国を国境の左側、日本を国境の右側に表示したが、資金は中国側から日本側に流れる。

まず、顧客取引銀行口座８ａからＢ社取引銀行口座９ａ（元口座）に、買い物の支払金額が元で即時入金される。この入金は、上述したように顧客取引銀行サーバ８からＢ社取引銀行サーバ９に、送金が通知された後に行われる。

次に、Ｂ社取引銀行口座９ａで為替の変換が行われる。例えば、午前０時の為替レートで元を円に両替する。Ｂ社取引銀行口座９ａには元口座と円口座があり、翌日、資金は元口座から円口座に移動する。これにより、Ｂ社取引銀行口座９ａから日本側の銀行への送金準備がなされたことになる。

Ｂ社決済サーバ７のＢ社管理システム７ａは、Ｂ社取引銀行口座９ａに対して、所定の条件が成立した場合に送金指示を行う。Ｂ社管理システム７ａは、Ｂ社取引明細データベース７ｂの決済処理データ（取引明細）を管理しており、例えば、円口座の残高が６０万円を超えた時点でＢ社取引銀行口座９ａに送金指示を行う。なお、Ｂ社取引銀行口座９ａは、一連の作業による手数料分の金額を差し引くが、これがＢ社の利益となる。

次に、Ｂ社取引銀行口座９ａ（円口座）から送金された資金は、Ａ社信託銀行口座１０ａに入金される。そして、Ａ社信託銀行口座１０ａは、買い物の支払金額(円)を、例えば、月末に１回、店舗取引銀行の店舗取引銀行口座１１ａに振り込む。また、日本における決済処理はＡ社の作業となるので、Ａ社信託銀行口座１０ａは、手数料分の金額をＡ社取引銀行のＡ社取引銀行口座１２ａに振り込む。なお、Ａ社信託銀行による処理によっても所定の手数料が発生する。

ここで、Ａ社決済サーバ６’のＡ社管理システム６’ａは、Ｂ社管理システム７ａから取引明細（円）のデータが転送されてくる。Ａ社管理システム６’ａは、取引明細（円）のデータをＡ社取引明細データベース６’ｂで管理しており、振込金額や手数料の計算をすることができる。情報の流れとしては、Ａ社信託銀行のＡ社信託銀行サーバ１０は、Ａ社管理システムから振込指示（送金指示）を受けて店舗取引銀行の店舗取引銀行サーバ１１（図示省略）へ振込通知をする。また、Ａ社信託銀行サーバ１０は、手数料の振込指示を受けてＡ社取引銀行のＡ社取引銀行サーバ１２（図示省略）へ振込通知をする。

Ａ社決済サーバ６’（Ａ社管理システム６’ａ）に保存された決済情報は、Ａ社信託銀行サーバ１０及び店舗取引銀行サーバ１１からアクセスして確認することができる。また、加盟店である店舗１３’は、店舗取引銀行に振り込まれた金額が振込予定額より少ないと判断した場合には、直接、Ａ社管理システム６’ａに問い合わせることで、後に不足分が追加で振り込まれる。

Ａ社信託銀行口座１０ａの代わりに普通銀行口座を利用することも可能であるが、Ａ社の判断で口座の資金が比較的自由に管理できるとすると、都合により振り込みが遅れたり、手数料を多く取ったりするリスクも考えられる。このため、預けた資金が確実に保全、管理される信託銀行を採用することで、特に各店舗にとって安心して運用されるシステムとなっている。

決済システム３０において、日本のＡ社信託銀行は、中国のＢ社取引銀行口座９ａから送金された資金がＡ社信託銀行口座１０ａに蓄えられると、確実に店舗取引銀行口座１１ａに届けられるという一連の業務が委託されている。

最終的に店舗取引銀行口座１１ａに振り込まれる買い物の支払金額は、日本で決済を管理するＡ社、中国で決済を管理するＢ社の手数料分（例えば、合計で約３％分）を差し引いた金額となる。しかし、円建ての決済のため、各店舗には、為替手数料や為替差損は発生しない。

最後に、Ａ社管理システムについて補足すると、店舗１３’の店舗サーバ１３は、Ａ社管理システムのＡ社取引明細データベース６’ｂでクラウド管理されている決済情報にインターネットを利用してアクセス可能である。決済情報としては、店舗別売上、端末別売上、取引履歴、商品管理等の情報があり、店舗１３’は、自己の店舗で行われた決済情報を閲覧することができる。これにより、各店舗は、海外から訪日した顧客の消費動向を把握し、販売戦略を立てるのに役立てることができる。

以上のように、実施の形態３の決済システム３０は、第１国で顧客が行った買い物情報を顧客が利用するペイメントサービスのＱＲコードにより店舗決済端末２から取得するＡ社決済サーバ６’と、その買い物情報を取得するＢ社決済サーバ７と、その買い物情報を取得して買い物の決済処理を行う顧客取引銀行サーバ８を有している。Ｂ社決済サーバ７は、顧客取引銀行サーバ８から決済情報を取得し、その決済情報を顧客の携帯端末３に送信する。携帯端末３では、決済処理による支払いが正常に行われた場合に、第２国の通貨による支払情報が表示可能となるので、顧客は海外の店舗で、安心かつ手軽に買い物の決済をすることができ、店舗の負担も軽減される。

ＳＮＳのペイメントサービスは、これから益々増加する傾向にあるが、実施の形態１の決済システム１においては、マルチ決済コードを更新することで新たなサービスを容易に追加することができる。また、実施の形態２，３の決済システム２０，３０においては、店舗決済端末２の店舗側決済用アプリケーションを更新することで、１つの店舗側決済用アプリケーションで新たなペイメントサービスに対応することができる。

上記説明は、本発明の実施形態の一部であり、これ以外にも種々な実施形態が考えられる。実施の形態３において、第１国、第２国は、何れの国であってもよい。例えば、第１国が日本、第２国が米国であれば、図６の携帯端末３に表示される言語は英語で、貨幣はドルの表示となる。

実施の形態２，３の店舗決済端末２には、さらに様々な機能を持たせてもよい。例えば、店舗決済端末２を使用する処理の中で、「決済が終了しました。」や「領収書をお渡しするので、少々お待ちください。」に相当する外国語のフレーズを予め蓄えておき、各処理の終了時に音声出力するようにしてもよい。また、顧客が購入する商品の金額（円）を入力する時点で、第２国の通貨の相当額を表示するようにすれば、店舗決済端末２は、顧客にとってより便利なツールとなる。

１，２０，３０ 決済システム
２ 店舗決済端末（店舗端末）
２ａ 表示部（店舗端末入力部）
２ｂ カメラ（店舗端末読取部）
２ｃ 通信部（店舗端末通信部）
２ｄ 開口部
３ 携帯端末（顧客端末）
３ａ 表示部（顧客端末入力部）
３ｂ カメラ（顧客端末読取部）
３ｃ 通信部（顧客端末通信部）
５ コードシート
６ ＳＮＳ決済サーバ（決済サーバ）
６’ Ａ社決済サーバ
６’ａ Ａ社管理システム
６’ｂ Ａ社取引明細データベース
７ Ｂ社決済サーバ
７ａ Ｂ社管理システム
７ｂ Ｂ社取引明細データベース
８ 顧客取引銀行サーバ
８ａ 顧客取引銀行口座
９ Ｂ社取引銀行サーバ
９ａ Ｂ社取引銀行口座
１０ Ａ社信託銀行サーバ
１０ａ Ａ社信託銀行口座
１１ 店舗取引銀行サーバ
１１ａ 店舗取引銀行口座
１２ Ａ社取引銀行サーバ
１２ａ Ａ社取引銀行口座
１３ 店舗サーバ
１３’ 店舗
１３ａ 表示部

Claims (4)

1. 顧客が所有する顧客端末を使用して、店舗で買い物の決済をすることが可能な決済システムであって、
   前記顧客端末から前記顧客の買い物情報を取得して決済処理を行う決済サーバを備え、
   各店舗は、複数のペイメントシステムに対応した認証コードと、顧客の決済情報を管理する店舗サーバとを有し、
   前記顧客端末は、前記認証コードを読み取る顧客端末読取部と、前記顧客が購入する購入商品の金額を入力する顧客端末入力部と、前記決済サーバに前記購入商品に関する前記買い物情報を送信する顧客端末通信部とを有し、
   前記決済サーバは、前記決済処理の結果を前記顧客端末及び前記店舗サーバに送信する通信機能を備えていることを特徴とする決済システム。
2. 前記認証コードは、印刷されて店舗内外に掲示されている、又は決済カウンタ付近に置かれていることを特徴とする請求項１に記載の決済システム。
3. 前記店舗サーバは、決済情報を表示する表示部を備え、
   前記表示部は、前記複数のペイメントシステムによる決済を１つの画面で表示する決済一覧画面を有していることを特徴とする請求項１又は２に記載の決済システム。
4. 顧客が所有する顧客端末を使用して、店舗で買い物の決済をすることが可能な決済システムであって、
   各店舗に設置され、顧客が利用する複数のペイメントシステムに対応し、前記顧客端末に表示された認証コードを読取可能な店舗端末と、
   前記店舗端末から前記認証コードを含む前記顧客の買い物情報を取得して決済処理を行う決済サーバと、からなり、
   前記店舗端末は、前記認証コードを読み取る店舗端末読取部と、前記顧客が購入する購入商品の金額を入力する店舗端末入力部と、前記決済サーバに前記購入商品に関する前記買い物情報を送信する店舗端末通信部とを有し、
   前記決済サーバは、前記決済処理の結果を前記顧客端末及び前記店舗端末に送信する通信機能を備えていることを特徴とする決済システム。