<法的事項の遵守>
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本開示に係るプログラム、情報処理方法、表示方法、端末、サーバ等を実施するための実施形態について、図面を参照して説明する。
<概要>
近年、ネットワークサービスに関連するアプリケーション(アプリケーションソフトウェア)として、電子貨幣による支払い・決済を行うためのアプリケーション(支払いアプリケーション・決済アプリケーション)、電子貨幣による送金/受取を行うためのアプリケーション(送金アプリケーション)といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約したアプリケーションが普及しつつあり、端末20のユーザが、これらのアプリケーションを用いて、電子貨幣に関する各種のサービスを受けることが可能になってきている。
「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末20、または端末20のユーザが所有する電子的な貨幣を意味する。
なお、電子貨幣は、「電子マネー」や「デジタル通貨(デジタル貨幣)」と表現してもよいし、そのようにしなくてもよい。
また、「電子貨幣(電子マネー)」や「デジタル通貨(デジタル貨幣)」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣(電子マネー)」や「デジタル通貨(デジタル貨幣)」には、暗号通貨(暗号資産)を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。
本明細書では、適宜「通信I/Fによって」という表現を使用する。これは、装置が、限定ではなく例として、制御部(プロセッサー等)の制御に基づいて、通信I/Fを介して(通信部を介して)、各種の情報やデータを送受信することを示す。
また、本明細書において、「決済」とは電子的な決済(電子決済)のことを意味する。この一例は、電子貨幣を利用した電子決済である。
また、本明細書において、「決済に関する処理」とは、限定ではなく例として、端末20が実行する決済に関する処理であって、決済を行うためのコード情報をサーバ等から取得する処理(コード情報の生成をサーバ等に依頼する処理や、生成されたコード情報をサーバ等から受信する処理を含む。)、取得したコード情報を表示する処理、決済結果(決済通知を含む。)をサーバ等から取得する処理などの、決済を行う上で何らかの関連のある処理、より具体的には、決済を行う上で関連のある処理として端末20で実行される処理全般を含むものである。
また、本明細書において、「コード情報」とは、コード画像や、エンコード等によってコード画像に格納されている情報(格納情報)、または格納される対象となる情報(格納対象情報)を含むものである。格納情報や格納対象情報には、限定ではなく例として、詳細後述するトークンが含まれる。
また、本明細書では、コード(コード情報)を利用した支払い方法・決済方法であるコード決済として、限定ではなく例として、
(1)利用者提示型
(2)店舗提示型
の2種類を例示する。
利用者提示型とは、限定ではなく例として、端末20の表示部24に表示される支払いコードを利用者(端末20のユーザ)が店舗(限定ではなく例として加盟店)の店員等に提示し、店舗コードリーダ装置50のコードリーダ58で読み取ってもらうことで決済を行う方法である。
店舗提示型とは、限定ではなく例として、店舗(限定ではなく例として加盟店)で提示または掲示される支払い店舗コードを利用者が端末20のカメラ27やコードリーダ(支払いアプリケーションのコードリーダを含む。)で読み取って決済を行う方法である。
なお、以下では、利用者提示型で端末20の表示部24に表示されるコードを「支払いコード」と称するが、これに代えて「利用者提示型コード」等のように称してもよい。
また、以下では、店舗提示型で端末20が読み取るコードを「支払い店舗コード」と称するが、これに代えて「店舗提示型コード」等のように称してもよい。
また、本明細書では、アカウントに基づく決済として、限定ではなく例として、
(A)共通アカウント決済
(B)アカウント連携決済
の2種類を例示する。
「アカウント」とは、限定ではなく例として、電子貨幣による支払い・決済を行うためのアプリケーション(支払いアプリケーション・決済アプリケーション)のアカウントである。
共通アカウント決済は、複数のユーザが共通に使用可能なアカウント(以下、「共通アカウント」と称する。)に基づいて決済を行う手法である。この決済を「共通アカウント決済」と称する。共通アカウント決済は、共通ウォレットを利用することによって実現される。「共通ウォレット」は、複数のユーザによって設定される電子マネー口座の一形態であり、仮想的な1つのウォレットが構成されるものである。
共通アカウント決済は、ユーザが、複数のユーザに共通のアカウント(1つの共通のアカウント)を用いる決済と捉えることもできる。
なお、共通アカウント決済は、共通ウォレット決済と表現してもよい。
アカウント連携決済は、複数のアカウントを連携させて決済を行う手法である。アカウントの連携とは、複数のアカウントが決済に用いられるように関連付けることであり、アカウントを連携させることを「アカウント連携」と称し、アカウント連携を利用した決済を「アカウント連携決済」と称する。
この場合、1人のユーザの複数のアカウントを連携させてもよいし、複数のユーザのアカウントを連携させてもよい。つまり、必ずしも他人のアカウントが連携に必須なわけではなく、限定ではなく例として、自分の複数のアカウントを連携させることも可能である。
アカウント連携決済を実現するために、限定ではなく例として、複数のアカウントを関連付けた上で、限定ではなく例として、関連付けられた各々のアカウントから均等割りで決済が行われるように設定する処理(アカウント連携処理)を実行する。
アカウント連携決済は、ユーザが、自分のアカウントの他、異なるアカウント(自分の別のアカウントまたは他人のアカウント)を用いる決済と捉えることもできる。
なお、アカウント連携は、ウォレット連携と表現してもよい。また、アカウント連携決済は、ウォレット連携決済と表現してもよい。
以下では、あくまでも一例として、友達同士や仲間同士など、複数のユーザがみんなで買い物などの支払いの決済を行う場合を想定した実施例について説明する。
共通アカウント決済は、基本的には複数のユーザで共通に使用することを想定した1つのアカウントから決済を行うものであるが、以下説明する実施例では、共通アカウントと、共通アカウントとは異なるアカウントとに基づいて決済を行う手法についても説明する。
また、アカウント連携は、限定ではなく例として、(B-1)支払いを行う前、(B-2)支払いを行う際のいずれかに行うようにすることができる。
(B-1)支払いを行う前は、限定ではなく例として、事後的な精算(限定ではなく例として割り勘による精算)が面倒な場合に適用することができる。
(B-2)支払いを行う際は、限定ではなく例として、支払いの際に決済を行うアカウントして設定されているアカウント(限定ではなく例として自分のアカウント)の残高が不足している場合に適用することができる。この場合、限定ではなく例として、他のユーザのアカウントとアカウント連携して決済を行うようにすることができる。
共通アカウント決済では、複数のユーザに共通のアカウントを用いるため、詳細は後述するが、一のユーザが他のユーザの支払い分を立て替えて決済を行ったような場合に、事後的な精算(清算)の処理が必要となる場合がある。つまり、決済が完了した後の何らかのタイミングで、送金処理/受金処理等の各々のユーザの金額を調整する処理が必要となる場合がある。
それに対し、アカウント連携決済では、連携するアカウントのユーザの許可を得ておく、またはその場で許可を得た上で、各々のアカウントから金額が消費されるようにすることで、事後的な精算の処理は基本的に不要となる。
以上を踏まえた上で、「共通アカウント決済」と「アカウント連携決済」とのそれぞれの実施例について説明する。
なお、「連携」は、1つの目的のために一緒に物事を行うという意味を含む。このため、複数のユーザが一緒に決済を行うという意味において、共通アカウント決済もアカウント連携決済も、目的は同じであるとも言える。
<システム構成>
図1-1は、本実施例における通信システム1のシステム構成の一例を示す図である。
通信システム1では、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)と、複数の店舗POSシステム40(店舗POSシステム40A,店舗POSシステム40B,店舗POSシステム40C,・・・)とが接続される。
サーバ10は、ネットワーク30を介して、ユーザが所有する端末20に支払いサービスを提供する機能を有する。サーバ10は、支払いサービスサーバや、支払い管理サーバ、決済サービスサーバ、決済管理サーバ等のように表現することもできる。
なお、ネットワーク30に接続されるサーバ10の数や端末20の数は限定されない。
ネットワーク30は、1以上の端末20と、1以上のサーバ10と、1以上の店舗POSシステム40とを接続する役割を担う。すなわち、ネットワーク30は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク30のうちの1つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク30は、限定ではなく例として、アドホック・ネットワーク(ad hoc network)、イントラネット、エクストラネット、仮想プライベート・ネットワーク(virtual private network:VPN)、ローカル・エリア・ネットワーク(local area network:LAN)、ワイヤレスLAN(wireless LAN:WLAN)、広域ネットワーク(wide area network:WAN)、ワイヤレスWAN(wireless WAN:WWAN)、大都市圏ネットワーク(metropolitan area network:MAN)、インターネットの一部、公衆交換電話網(Public Switched Telephone Network:PSTN)の一部、携帯電話網、ISDN(integrated service digital networks)、無線LAN、LTE(long term evolution)、CDMA(code division multiple access)、ブルートゥース(Bluetooth(登録商標))、衛星通信など、または、これらの2つ以上の組合せを含むことができる。ネットワーク30は、1つまたは複数のネットワーク30を含むことができる。
サーバ10(限定ではなく、サーバ、情報処理装置、情報管理装置の一例)は、端末20に対して、所定のサービス(本実施例では支払いサービス)を提供する機能を備える。サーバ10は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ10は、限定ではなく例として、サーバ装置、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ10は情報処理装置と表現されてもよい。サーバ10と端末20とを区別する必要がない場合は、サーバ10と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
[各装置のハードウェア(HW)構成]
通信システム1に含まれる各装置のHW構成について説明する。
(1)端末のHW構成
図1-1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、表示部24、マイク25、スピーカ26、カメラ27、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、マイク25、カメラ27等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信I/F22は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F22は、ネットワーク30を介して、サーバ10等の各種装置との通信を実行する機能を有する。通信I/F22は、各種データを制御部21からの指示に従って、サーバ10等の各種装置に送信する。また、通信I/F22は、サーバ10等の各種装置から送信された各種データを受信し、制御部21に伝達する。また、通信I/F22を単に通信部と表現する場合もある。また、通信I/F22が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部23は、端末20に対する各種操作を入力する装置、および、端末20で処理された処理結果を出力する装置を含む。入出力部23は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部21に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含む。
出力部は、制御部21で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ(音声出力)、レンズ(限定ではなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
表示部24は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部24は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))、ヘッドマウントディスプレイ(HDM:Head Mounted Display)、プロジェクションマッピング、ホログラム、空気中など(真空であってもよいし、そうでなくてもよい)に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部24は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。
入出力部23がタッチパネルの場合、入出力部23と表示部24とは、略同一の大きさおよび形状で対向して配置されていてもよい。
時計部29Aは、端末20の内蔵時計であり、時刻情報(計時情報)を出力する。時計部29Aは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部29Aは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
なお、時計部29Aは、NITZ(Network Identity and Time Zone)規格等を適用したクロックを有していてもよいし、有していなくてもよい。
位置算出用情報検出部29Bは、制御部21が自己の端末20の位置を算出(測定)するために必要な情報(以下、「位置算出用情報」と称する。)を検出(計測)する機能部である。位置算出用情報検出部29Bは、限定ではなく例として、位置算出用センサ部と表現することもできる。
位置算出用情報検出部29Bは、限定ではなく例として、GPS(Global Positioning System)等の衛星測位システムを利用して端末20の位置を算出するためのセンサやユニットである衛星測位センサ(衛星測位ユニット)や、慣性航法システムを利用して端末20の位置を算出するためのセンサやユニットである慣性計測センサ(慣性計測ユニット(IMU(Inertial Measurement Unit)))等を含む。
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むRF(Radio Frequency)信号をデジタル信号に変換するRF受信回路や、RF受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
慣性計測ユニットは、慣性航法演算によって端末20の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、3軸の加速度センサや3軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
制御部21は、限定ではなく例として、位置算出用情報検出部29Bによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末20の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。そして、制御部21は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部28に記憶させる。
制御部21は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
制御部21は、限定ではなく例として、中央処理装置(CPU)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(application-specific integrated circuit)、FPGA(field programmable gate array)を含む。
記憶部28は、端末20が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部28は、限定ではなく例として、HDD(hard disk drive)、SSD(solid state drive)、フラッシュメモリ、RAM(random access memory)、ROM(read only memory)など各種の記憶媒体を含む。また、記憶部28は、メモリ(memory)と表現されてもよいし、されなくてもよい。
端末20は、プログラムPを記憶部28に記憶し、このプログラムPを実行することで、制御部21が、制御部21に含まれる各部としての処理を実行する。つまり、記憶部28に記憶されるプログラムPは、端末20に、制御部21が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
マイク25は、音声データの入力に利用される。スピーカ26は、音声データの出力に利用される。カメラ27は、動画像データの取得に利用される。
(2)サーバのHW構成
図1-1には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、ディスプレイ13、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、ディスプレイ13を取り外すような構成であってもよいし、そうでなくてもよい。
制御部11は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部11は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部11は、これらに限定されない。
記憶部15は、サーバ10が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部15は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部15は、これらに限定されない。また、記憶部15は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信I/F14は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F14は、ネットワーク30を介して、端末20等の各種装置との通信を実行する機能を有する。通信I/F14は、各種データを制御部11からの指示に従って、端末20等の各種装置に送信する。また、通信I/F14は、端末20等の各種装置から送信された各種データを受信し、制御部11に伝達する。また、通信I/F14を単に通信部と表現する場合もある。また、通信I/F14が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部12は、サーバ10に対する各種操作を入力する装置により実現される。入出力部12は、ユーザからの入力を受け付けて、入力に係る情報を制御部11に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部12は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部12、限定ではなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部12は、これらに限定されない。
ディスプレイ13は、代表的にはモニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))で実現される。なお、ディスプレイ13は、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらのディスプレイ13は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイ13は、これらに限定されない。
時計部19は、サーバ10の内蔵時計であり、時刻情報(計時情報)を出力する。時計部19は、限定ではなく例として、ハードウェアクロックとしてのRTC(Real Time Clock)やシステムクロック等を有して構成される。時計部19は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
(3)店舗POSのシステム構成
図1-2には、店舗POSシステム40のシステム構成の一例を示している。
店舗POSシステム40は、サーバ10を運用する事業者と提携している店舗に導入されて使用されるPOSシステムであり、限定ではなく例として、店舗コードリーダ装置50と、コードレジ60と、店舗サーバ70とを含む。
店舗コードリーダ装置50は、POS通信I/F57(限定ではなく例として、店舗内の有線通信I/Fや無線通信I/F)によってコードレジ60や店舗サーバ70と通信接続され、コードレジ60での会計の際に、端末20の表示部24に表示されるコード情報を読み取る。そして、読み取ったコード情報に基づいて、決済要求情報を通信I/F54によってサーバ10に送信し、サーバ10で決済が行われた後、決済結果に関する情報を通信I/F54によってサーバ10から受信する。
店舗コードリーダ装置50は、限定ではなく例として、制御部51と、入出力部52と、表示部53と、通信I/F54と、記憶部55と、音出力部56と、POS通信I/F57と、コードリーダ58、時計部59とを有する。
コードリーダ58は、一次元コード(一次元コード画像)や二次元コード(二次元コード画像)、限定ではなく例として、後述する支払いコード(支払いコード画像)を読み取るためのコードリーダである。
コードレジ60は、限定ではなく例として、POS通信I/F57によって店舗コードリーダ装置50や店舗サーバ70と通信接続され、店舗コードリーダ装置50がサーバ10から受信した決済完了通知等に基づいて、販売した商品の総額や、端末20のユーザの電子貨幣の残高等の情報を印字したレシートを発行する。
また、限定ではなく例として、コードレジ60と一体として、またはコードレジ60と別体として設けられ、客側に表示面が向けられたディスプレイを構成することもできる。
コードレジ60は、支払いアプリケーションに対応可能に構成されたレジであり、支払いアプリケーション対応の据置端末と言うこともできる。
店舗サーバ70は、限定ではなく例として、自店舗に関する店舗情報や、自店舗で販売される商品に関する情報や自店舗で提供されるサービスに関する情報、自店舗での商品の販売やサービスの提供に伴う売上げに関する情報等の各種の情報を管理する。店舗サーバ70は、POS通信I/F57によって店舗コードリーダ装置50やコードレジ60と通信可能に構成されているとともに、ネットワーク30を介してサーバ10等の外部装置と通信可能に構成されている。
なお、店舗サーバ70は、必ずしも店舗コードリーダ装置50と直接的に通信可能に構成されている必要はなく、コードレジ60を介して店舗コードリーダ装置50と通信可能に構成されていてもよい。限定ではなく例として、店舗コードリーダ装置50がサーバ10から受信した決済完了通知等はコードレジ60に送られ、その後、コードレジ60から店舗サーバ70に送られるようにするなどすることもできる。
(4)その他
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
本開示の各実施形態においては、端末20および/またはサーバ10のCPUがプログラムPを実行することにより、実現するものとして説明する。
他の装置についても同様である。
なお、端末20の制御部21、および/または、サーバ10の制御部11は、制御回路を有するCPUだけでなく、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、1または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSIなどと呼称されることもある。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
他の装置についても同様である。
また、本開示の各実施形態のプログラムP(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよいし、そうでなくてもよい。
記憶媒体は、1つまたは複数の半導体ベースの、または他の集積回路(IC)(限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ(FPGA)または特定用途向けIC(ASIC)など)、ハード・ディスク・ドライブ(HDD)、ハイブリッド・ハード・ドライブ(HHD)、光ディスク、光ディスクドライブ(ODD)、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ(FDD)、磁気テープ、固体ドライブ(SSD)、RAMドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの2つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムPを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ(memory)と表現されてもよいし、されなくてもよい。
サーバ10および/または端末20は、記憶媒体に記憶されたプログラムPを読み出し、読み出したプログラムPを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
他の装置についても同様である。
また、本開示のプログラムPは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ10および/または端末20に提供されてもよいし、されなくてもよい。サーバ10および/または端末20は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムPを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
他の装置についても同様である。
また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML5などのマークアップ言語などを用いて実装される。
<第1実施例>
最初に、前述した「(A)共通アカウント決済」の実施例について説明する。
まず、共通アカウント決済の基本的な実施例(第1実施例)として、端末20が、支払いアプリケーションを利用して、サーバ10を介して支払いアプリケーションによる支払いが可能な店舗での支払いを、共通ウォレットの残高(共通ウォレットの電子マネーの残高、以下、「共通ウォレット残高」と称する。)から行う実施例について説明する。
以下では、支払いアプリケーションによる支払いサービスを提供する事業者のことを「支払いサービスの事業者」と称する。
なお、支払いサービスの事業者は、支払いアプリケーションを提供する事業者や、サーバ10の事業者と表現することもできる。
また、決済サービスを提供する事業者という意味で、決済サービスの事業者と表現することもできる。
また、以下では、支払いサービスの事業者と提携し、店舗で提供される物販・サービスに対する支払いにおいて支払いアプリケーションを用いる支払いサービスが利用可能な店舗を「加盟店」と称する。
また、以下では、支払いサービスの事業者によって、サーバ10が運用・管理されることとして説明する。また、以下では、支払いアプリケーションの名称を、適宜「Payment App」と称して図示・説明する。
また、支払いアプリケーションは、いわゆるメッセージングサービス(MS:Messaging Service)の機能を有さない単体のアプリケーションとしてサーバ10によって提供されるようにしてもよいし、MSの機能を有する複合的なアプリケーションとしてサーバ10によって提供されるようにしてもよい。また、メッセージングサービスには、端末20間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス(IMS:Instant Messaging Service)を含めてもよいし、含めなくてもよい。
コンテンツには、単純なテキストや絵文字等を含むメッセージの他、限定ではなく例として、画像情報(静止画像、動画像等を含む。)、操作用情報(ボタン、アイコン等を含む。)、通信用情報・リンク情報(URI、URL等を含む。)など、端末20間で送受信可能な各種の情報を含めることができる。
また、支払いアプリケーションは、いわゆるソーシャルネットワーキングサービス(SNS:Social Networking Service)の機能を有さない単体のアプリケーションとしてサーバ10によって提供されるようにしてもよいし、SNSの機能を有する複合的なアプリケーションとしてサーバ10によって提供されるようにしてもよい。
なお、メッセージングサービス:MS(IMSを含む。)は、ソーシャルネットワーキングサービス:SNSの1つの形態(一形態)と考えることもできる。
このため、MSとSNSとは区別してもよいし、区別しなくてもよい。
<機能構成>
図1-3は、本実施例においてサーバ10の制御部11によって実現される機能の一例を示す図である。
制御部11は、限定ではなく例として、記憶部15に記憶された支払いアプリケーション管理処理プログラム151に従って支払いアプリケーション管理処理を実行するための支払いアプリケーション管理処理部111を機能部として含む。
図1-4は、本実施例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、限定ではなく例として、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム151と、支払いアプリケーションユーザ登録データ153と、ユーザ管理データベース155と、共通ウォレット管理データベース157とが記憶される。
支払いアプリケーションユーザ登録データ153は、支払いアプリケーションを利用する端末20、またはその端末20のユーザに関する登録データであり、そのデータ構成の一例を図1-5に示す。
支払いアプリケーションユーザ登録データ153には、限定ではなく例として、ユーザ名と、支払いアプリケーションIDと、端末電話番号と、その他登録情報とが関連付けて記憶される。
ユーザ名は、支払いアプリケーションを利用する端末20のユーザの名称であり、限定ではなく例として、端末20のユーザが支払いアプリケーションを利用する際に登録する名称が記憶される。
支払いアプリケーションIDは、支払いアプリケーションのアカウント(アカウント情報)であって、端末20、または端末20のユーザを識別可能とするIDである。この支払いアプリケーションIDは、限定ではなく例として、サーバ10によって固有のIDが設定されて記憶される。
端末電話番号は、このユーザ名のユーザの端末20の電話番号であり、限定ではなく例として、端末20のユーザが支払いアプリケーションを利用する際に登録する端末20の電話番号が記憶される。
その他登録情報には、限定ではなく例として、このユーザ名のユーザの端末20のメールアドレス(端末メールアドレス)、支払いアプリケーションにおける各種の認証に利用される認証パスワード等の認証情報、このユーザが使用するアイコンの画像データ(アイコン画像)、ユーザのプロフィール(ユーザプロフィール)等を含めるようにすることができる。
ただし、これらの情報は必須ではない。
ユーザ管理データベース155は、支払いアプリケーションユーザ登録データ153に記憶されたアカウント(アカウント情報)に基づくユーザの管理用のデータベースであり、そのデータ構成の一例を図1-6に示す。
ユーザ管理データベース155には、支払いアプリケーションユーザ登録データ153に記憶された支払いアプリケーションIDごとの管理データとして、ユーザ管理データが記憶される。
各々のユーザ管理データには、限定ではなく例として、支払いアプリケーションIDと、電子マネー口座残高とが記憶される。
ここで、共通ウォレット管理データベース157を参照しながら共通ウォレットについて詳細に説明する。
共通ウォレットとは、支払いアプリケーションを利用する複数のユーザによって、支払いを行う前にあらかじめ設定される電子マネー口座の一形態である。
共通ウォレットでは、設定される複数のユーザがその残高を利用して支払いを行うことが可能である。以下では、共通ウォレットを利用可能なユーザを「共通ウォレットメンバー」と称する。
共通ウォレットを利用するためには、まずユーザが共通ウォレットを生成するための操作を行う。この生成においては、限定ではなく例として、共通ウォレットメンバーの電子マネー口座を特定する情報(限定ではなく例として、支払いアプリケーションID)を必要とする。
共通ウォレット管理データベース157は、サーバ10が共通ウォレットを管理するためのデータベースであり、その一例である第1の共通ウォレット管理データベース157Aのデータ構成例を図1-7に示す。
第1の共通ウォレット管理データベース157Aには、共通ウォレットをユニークに識別するための共通ウォレットIDごとの管理データとして、共通ウォレット管理データが記憶される。
各々の共通ウォレット管理データには、限定ではなく例として、共通ウォレットIDと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーIDとが関連付けて記憶される。
共通ウォレットIDは、支払いアプリケーションにおける共通ウォレットのアカウント(以下、適宜「共通アカウント」と称する。)である。
共通ウォレット名は、共通ウォレットIDで識別される共通ウォレットの名称である。
共通ウォレット残高は、共通ウォレットIDで識別される共通ウォレットを利用して支払いを行う際に用いられる電子マネーの残高である。
共通ウォレットメンバーIDは、共通ウォレットの生成時に指定される、共通ウォレットメンバーの支払いアプリケーションIDである。
なお、共通ウォレットの生成後に共通ウォレットメンバーIDに支払いアプリケーションIDを追加することで、新たな共通ウォレットメンバーを追加することも可能である。また、同一のユーザが保有する複数の支払いアプリケーションIDを共通ウォレットメンバーIDに記憶してもよいし、そうしなくてもよい。
共通ウォレットが生成される場合、その共通ウォレット残高は「0」である。支払いを行う前に、共通ウォレットメンバーは、各々の電子マネー口座から電子マネーを共通ウォレットに送金し、共通ウォレット残高を増加させる。
なお、共通ウォレットメンバーは、支払いサービスに登録する外部金融機関の口座(限定ではなく例として、銀行口座)から、共通ウォレットへチャージする(電子マネーへ変換して送金する)ことも可能である。
共通ウォレットが不要となる場合には、存在する共通ウォレットを取り消すための共通ウォレット破棄操作を行う。共通ウォレット破棄操作が実行されると、共通ウォレット残高を共通ウォレットメンバーの人数で割り勘(均等割り)した額が、共通ウォレットメンバーの各々の電子マネー口座へと送金される。そして、共通ウォレット残高が「0」となった後、第1の共通ウォレット管理データベース157Aからその共通ウォレット管理データのレコードが削除される。
<処理>
(1)利用者提示型のコード決済
図1-8~図1-9は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
一例として、ユーザA.Aの端末20(端末A)と、ユーザB.Bの端末20(端末B)とにより利用可能な電子マネー口座を共通ウォレットとして説明する。実際には、共通ウォレットを用いて支払い可能な端末は2つとは限らないが、端末Bと同様の処理となるため、本明細書では図示を省略する。
なお、この処理は、本開示の手法を実現するための処理の一例に過ぎず、この処理に限定されるものではない。この処理に、別のステップを追加してもよいし、一部のステップを省略(削除)してもよい。
これは、以下説明する各フローチャート(処理)について同様である。
また、各装置が実行する処理の通し番号については、図面には記載するが、明細書では記載を省略する。以降の実施例についても同様である。
まず、端末Aの制御部21は、共通ウォレット作成/選択情報を、通信I/F22によってサーバ10に送信する(A100)。
具体的には、端末Aから利用可能な共通ウォレットを選択する情報(限定ではなく例として、共通ウォレットID)を、通信I/F22によってサーバ10に送信する。選択可能な共通ウォレットIDは、本ステップにおいて、通信I/F22によってサーバ10から受信してもよいし、記憶部28にあらかじめ記憶されたものを呼び出してもよい。
また、端末Aから利用可能な共通ウォレットが存在しない場合には、共通ウォレットを新規に作成するための情報を、通信I/F22によってサーバ10に送信する。ここで、共通ウォレットを新規に作成するための情報には、限定ではなく例として、共通ウォレットを構成するメンバーのアカウント情報(限定ではなく例として、ユーザA.AとユーザB.Bの支払いアプリケーションID)や、共通ウォレットの名称、共通ウォレットへの初期送金額を含む。
通信I/F14によって端末Aから共通ウォレットを選択する情報、もしくは共通ウォレットを新規に作成するための情報を受信すると、サーバ10の制御部11は、要求を受けた共通ウォレットID、もしくは新規に作成され、制御部11によってユニークに(重複がないように)割り当てられる共通ウォレットIDに基づいて、ウォレットからの支払いを認可する支払いトークンを生成する。
以下では、共通ウォレットIDに紐付けられる共通ウォレット残高から支払いを認可する支払いトークンを「共通ウォレット支払いトークン」と称する。ここで、共通ウォレット支払いトークンは、限定ではなく例として、所定の桁数(限定ではなく例として12桁)の整数値によって識別される。また、共通ウォレット支払いトークンは生成から所定の時間内(限定ではなく例として「5分」)に限り認可を行う、有効期限を持つトークンとしてもよいし、そうしなくてもよい。
共通ウォレット支払いトークンが生成されると、サーバ10の制御部11は、共通ウォレット支払いトークンを含むコード情報である共通ウォレットコード情報を生成する。共通ウォレットコード情報は、限定ではなく例として、共通ウォレット支払いトークンの識別子を一次元コード(バーコード等)や二次元コード(QRコード等)としてエンコードした支払いコード(画像情報)を含む。
なお、共通ウォレット支払いトークンが有効期限を持つ場合、共通ウォレットコード情報は、その有効期限を含んでもよい。また、共通ウォレット支払いトークンが生成された共通ウォレットの名称を含んでもよい。
その後、サーバ10の制御部11は、共通ウォレットコード情報を、通信I/F14によって端末Aに送信する(S100a)。
通信I/F22によってサーバ10から共通ウォレットコード情報を受信すると、端末Aの制御部21は、受信した共通ウォレットコード情報を表示部24に表示させる(A110a)。具体的には、共通ウォレットコード情報として、限定ではなく例として、支払いコードを表示部24に表示させる。
なお、共通ウォレットコード情報に共通ウォレット支払いトークンの識別子や有効期限を含む場合、端末Aの制御部21は、識別子や有効期限を表示させてもよいし、表示させなくてもよい。
また、支払いコードの表示中に共通ウォレット支払いトークンの有効期限が切れる場合、端末Aの制御部21は、共通ウォレット支払いトークンの再生成を要請する情報を、通信I/F22によってサーバ10へ送信してもよいし、そのようにしなくてもよい。
この場合、サーバ10の制御部21は、共通ウォレット支払いトークンと、共通ウォレットコード情報とを再生成し、共通ウォレットコード情報を通信I/F14によって端末Aに送信する。そして、通信I/F22によってサーバ10から再生成された共通ウォレットコード情報を受信すると、端末Aの制御部21は、支払いコードと、有効期限とを表示部24に再表示させるようにすることができる。
次いで、サーバ10の制御部11は、共通ウォレット支払いトークンが生成された共通ウォレットに関する情報である共通ウォレット情報を、通信I/F14によって端末Aに送信する(S110)。共通ウォレット情報は、限定ではなく例として、共通ウォレット残高を含む。
通信I/F22によってサーバ10から共通ウォレット情報を受信すると、端末Aの制御部21は、受信された共通ウォレット情報を表示部24に表示させる(A120)。具体的には、共通ウォレット情報として、限定ではなく例として、共通ウォレット残高を表示部24に加えて表示させる。
店舗コードリーダ装置50の制御部51は店舗決済処理を実行し、店舗コードリーダ装置50の入出力部52に対する操作に基づいて、所定の決済予定金額(限定ではなく例として「3,000円」)が制御部51へ入力される。そして、店舗コードリーダ装置50の制御部51は、コードリーダ58を用いて、端末Aの表示部24に表示される支払いコードを読み取る(P140)。この場合、表示部24に表示される支払いコードは、共通ウォレット支払いトークンと関連付けられているため、コードリーダ58の読み取り結果には、支払いトークンとして共通ウォレット支払いトークンが含まれる。
店舗コードリーダ装置50の制御部51は、限定ではなく例として、店舗IDと、決済予定金額と、支払いトークン(この場合には共通ウォレット支払いトークン)とを含む決済要求情報を通信I/F54によってサーバ10に送信する(P150)。
通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、サーバ10の制御部11は、要求を受けた共通ウォレット支払いトークンから共通ウォレットIDを検索し、その共通ウォレットに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する(S170a)。
サーバ10の制御部11は、限定ではなく例として、決済処理の成否と、決済処理後の共通ウォレット残高とを含む決済結果情報を、通信I/F14によって端末Aと店舗コードリーダ装置50とに送信し(S180a)、処理を終了する。
通信I/F22によってサーバ10から決済結果情報を受信すると、端末Aの制御部21は、決済結果情報を表示部24に表示させ(A180)、処理を終了する。
また、通信I/F54によってサーバ10から決済結果情報を受信すると、店舗コードリーダ装置50の制御部51は、決済結果情報を表示部53に表示させ(P160)、処理を終了する。
(2)店舗提示型のコード決済
以下では、「支払い店舗コード」を、限定ではなく例として、加盟店を識別するための加盟店識別情報(限定ではなく例として加盟店に固有に割り振られる店舗ID)を含むコード(一次元コードや二次元コード)として説明する。
なお、支払い店舗コードに、特定の決済予定金額(限定ではなく例として「500円」)の情報を含ませてもよいし、そのようにしなくてもよい。
図1-10~図1-11は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
なお、既出のフローチャート(処理)と同一のステップについては同一の符号を付して再度の説明を省略する。
これは、以下説明する各々のフローチャート(処理)について同様である。
前述した処理と同様に、サーバ10の制御部11によって共通ウォレット支払いトークンが生成されると、サーバ10の制御部11は、共通ウォレット支払いトークンを含むコード読み取り用情報である共通ウォレットコードリーダ情報を生成する。そして、サーバ10の制御部11は、共通ウォレットコードリーダ情報を、通信I/F14によって端末Aに送信する(S100b)。
A100の後、通信I/F22によってサーバ10から共通ウォレットコードリーダ情報を受信すると、端末Aの制御部21は、受信された共通ウォレットコードリーダ情報に基づいて、支払い店舗コードを読み取るためのコードリーダ画面を表示部24に表示させる。また、端末Aの制御部21は、コードを読み取るためにカメラ27を起動させる(A110b)。そして、端末Aの制御部21は、A120に処理を移す。
A120の後、端末Aの制御部21は、カメラ27等を用いて支払い店舗コードを読み取るコード読み取り処理を実行する(A190)。これにより、読み取った支払い店舗コードから店舗IDが取得される。
その後、端末Aの制御部21は、限定ではなく例として、決済予定金額を入力させるための表示画面を表示部24に表示させる。端末Aの入出力部23に対するユーザ操作に基づいて決済予定金額が入力されると、制御部21は、限定ではなく例として、共通ウォレットコードリーダ情報に含まれる共通ウォレット支払いトークンと、店舗IDと、決済予定金額とを含む決済要求情報を、通信I/F22によってサーバ10に送信する(A200)。そして、端末Aの制御部21は、A180に処理を移す。
なお、支払い店舗コードに決済予定金額が含まれている場合には、端末Aにおける決済予定金額の入力は省略することが可能である。
S110の後、通信I/F14によって端末Aから決済要求情報を受信すると、サーバ10の制御部11は、要求を受けた共通ウォレット支払いトークンから共通ウォレットIDを検索し、その共通ウォレットに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う店舗提示型の決済処理を実行する(S170b)。
その後、サーバ10の制御部11は、限定ではなく例として、決済処理の成否および決済処理後の共通ウォレット残高を含む決済結果情報を、通信I/F14によって端末Aに送信する(S180b)。そして、制御部11は、処理を終了する。
<第2実施例>
第2実施例は、端末20が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高から実行するが、支払い時に共通ウォレット残高が不足している場合に、共通ウォレット残高が不足していることに関する情報を表示する実施例である。
また、第2実施例は、共通ウォレット残高が不足している場合に、共通ウォレット(共通アカウント)に代えて、自己のウォレット(自分のユーザアカウント)から決済を行う実施例である。
第2実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
以下では、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによってタッチされた場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。以下では、ディスプレイにその要素が表示された領域と対向するタッチパネルの領域のことを、対向領域とも称する。つまり、対向領域は、受け付け手段として機能する。
図2-1は、端末20で実行される支払いアプリケーションにおいて表示部24に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、支払いアプリケーションを起動する操作がユーザによってなされ、支払いアプリケーションが起動した場合に表示される画面の一例である。
このアプリケーション画面には、限定ではなく例として、支払いアプリケーションのアプリケーション名である「Payment App」が最上段のタイトルバーに表示され、その横に、ユーザA.Aのアイコン画像と、ユーザ名「A.A」の文字とが表示されている。タイトルバーの下には、「Payment App」の階層メニューにおける現在位置が表示される。具体的には、限定ではなく例として、現在実行中の最上位のメニューである「ウォレット メインメニュー」が表示されている。その下には、自分(ユーザA.A)の電子マネー口座残高を表示するための電子マネー口座残高表示領域(以下、単に「残高表示領域」と称する。)241が設けられている。
この例では、残高表示領域241には、「Payment App」で管理されるユーザA.Aの電子マネー口座残高として「25,000円」が表示され、その横に、金額をチャージするためのチャージボタン241Aが表示されている。また、その下には、「ウォレット メインメニュー」から選択可能なサブメニューとして、支払いアプリケーションの各種の機能に対応する複数のアイコンが表示されるアイコン表示領域が設けられている。この例では、アイコン表示領域には、「送金」、「コード支払い」、「コードリーダ」、「クーポン」、「ポイント」および「共通ウォレット」にそれぞれ対応する6つのアイコンが表示されている。以下では、「共通ウォレット」に対応するアイコンを、共通ウォレットアイコンCN1として説明する。
図2-2は、図2-1のアプリケーション画面において共通ウォレットアイコンCN1がタッチ操作された場合に表示される共通ウォレット選択画面の一例を示す図である。
この例では、タイトルバーの下には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「共通ウォレット」が表示されている。
その下には、ユーザに対する操作案内として「共通ウォレットを選択してください」の説明文が表示され、その説明文の下には、複数の共通ウォレットの表示領域が設けられている。この例では、キャンプ資金用の共通ウォレット表示領域であるキャンプ資金表示領域242と、韓国旅行用の共通ウォレット表示領域である韓国旅行表示領域243とが表示されている。また、その下には、共通ウォレットを新規追加・登録するためのユーザ操作可能な新規登録操作領域244が設けられている。
キャンプ資金表示領域242には、上段に、共通ウォレットであることを示す「角財布」の画像とともに、その共通ウォレットの名称(この例では「キャンプ資金」)が表示されている。また、その横には、各種設定アイコンが表示されている。
また、下段には、このキャンプ資金の共通ウォレット残高(ここでは「1,000円」)が表示され、その横には、この共通ウォレットを共同で使用するユーザのアイコン画像およびユーザ名が表示される。この例では、ユーザA.AおよびユーザB.Bのアイコン画像およびユーザ名が表示されている。つまり、このキャンプ資金用の共通ウォレットは、ユーザA.AおよびユーザB.Bの2名からなる共通ウォレットと言える。
同様に、韓国旅行表示領域243には、上段に、共通ウォレットであることを示す角財布の画像とともに、その共通ウォレットの名称(この例では「キャンプ資金」)が表示されている。また、その横には、各種設定アイコンが表示されている。
また下段には、残高(この例では「90,000円」)が表示され、その横には、この共通ウォレットを共同で使用するユーザのアイコン画像およびユーザ名が表示される。この例では、ユーザA.A、ユーザD.DおよびユーザE.Eのアイコンが表示されている。つまり、この韓国旅行用の共通ウォレットは、ユーザA.A、ユーザD.DおよびユーザE.Eの3名からなる共通ウォレットと言える。
新規登録操作領域244には、「+」マークが中央部に表示されており、共通ウォレットを新たに追加・登録するための操作領域であることをユーザが容易に認識できるように構成されている。この「+」マークがタッチ操作されるに限らず、新規登録操作領域244内のいずれかの位置がタッチ操作されることで、共通ウォレットの新規作成・登録が可能となる。
図2-3は、図2-2の共通ウォレット選択画面においてキャンプ資金表示領域242内がタッチ操作された場合に表示されるキャンプ資金支払い画面の一例を示す図である。
この例では、タイトルバーの下に、上記階層メニューにおける現在位置として、現在実行中のサブメニューである「共通ウォレット:キャンプ資金」が表示されている。また、その下には、ユーザに対する操作案内として「メインメニュー」が表示され、その下には、キャンプ資金表示領域242が表示されている。キャンプ資金表示領域242の下には、「メインメニュー」から選択可能なサブメニューである「入金」、「コード支払い」、「コードリーダ」、「おしらせ」、「送金」および「ウォレット破棄」にそれぞれ対応する6つのアイコンが表示されている。
これらのアイコンのうち、「コード支払い」と示されたアイコンは、「利用者提示型」のコード決済を行う際に、サーバ10から支払いコードを取得するための「コード支払いアイコン」である。また、「コードリーダ」と示されたアイコンは、「店舗提示型」のコード決済を行う際に、端末20で端末読み取り用コードを読み取るために、コード支払いアプリケーションの機能として備えられたコードリーダ(以下、「アプリケーションコードリーダ」と称す。)を起動させるためのコードリーダアイコンである。
図2-4は、図2-3のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されるコード支払い画面の一例を示す図である。
この例では、タイトルバーの下には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、ユーザに対する操作案内として「コード支払い」が表示され、その下には、キャンプ資金コード支払い領域2421が表示されている。
キャンプ資金コード支払い領域2421には、上記と同様に角財布の画像および共通ウォレットの名称(キャンプ資金)とともに、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。
その下には、端末20のユーザのウォレット(電子マネー口座)であることを示す、がま口財布の画像とともに「自分のウォレット」の文字が表示され、その横に、その残高(電子マネー口座残高)(この例では「25,000円」)が表示されている。
また、その下には、サーバ10から送信されて端末20が受信したコード(コード画像)であって、共通ウォレットで決済を行うために用いられるコードである支払いコードとして、限定ではなく例としてバーコードで表される一次元の支払いコードと、限定ではなく例としてQRコード(登録商標)で表される二次元の支払いコードとが表示されている。
また、これらの支払いコードには、これらの支払いコードを利用して決済を行うことのできる期間(以下、「コード使用可能期間」と称する。)が定められており、この例では、支払いコードと関連付けて、コード使用可能期間の残り時間がカウントダウン形式で表示されている。コード使用可能期間は任意の期間とすることができるが、限定ではなく例として「5分間」の期間として定めておくことができる。
なお、コード使用可能期間を、端末20において支払いコードが表示される期間(以下、「コード表示期間」と称する。)とし、コード表示期間が終了した場合に、表示中の支払いコードを非表示とするようにしてもよいし、そのようにしなくてもよい。
端末20のユーザは、コード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置50で支払いコードを読み取ってもらうことでコード支払いを行う。
図2-5は、図2-4のコード支払い画面の支払いコードが店舗コードリーダ装置50で読み取られた結果、共通ウォレット残高が不足している場合に端末20の表示部24に表示される共通ウォレット残高不足画面の一例を示す図である。
この共通ウォレット残高不足画面では、現在位置として「キャンプ資金」が表示され、「キャンプ資金」の下には、共通ウォレット残高不足情報表示・操作領域2427が、ポップアップ形式で表示されている。この例では、残高が不足していることを表す画像として「困った顔のロボット」の画像が表示され、その下に、残高不足メッセージとして「共通ウォレット残高不足です」が表示されている。
また、その下には、「支払いしようとする買い物」が文字で表示されており、この例では、AAスポーツ株式会社のロゴ画像とともに、その会社名である「AAスポーツ株式会社」の文字が表示されている。その横には、支払い金額として「3,000円」の文字が表示され、その下には、内訳として、角財布の画像および共通ウォレットの名称(キャンプ資金)とともに、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。
また、その下には、がま口財布の画像および自分のウォレットとともに、自分の電子マネー口座残高(この例では「25,000円」)が表示されている。さらに、その下には、決済残高不足額(=決済予定金額-共通ウォレット残高)を自分のウォレットから支払うか否かをユーザに意思確認するための情報として「自分のウォレット残高から2,000円を支払いますか?」という案内文が表示されている。この例では、支払い金額が「3,000円」であるのに対し、共通ウォレット残高が「1,000円」であるため、「2,000円」不足していることになり、不足分の金額は「2,000円」となる。
また、この例では、共通ウォレット残高不足情報表示・操作領域2427の下部に、自分のウォレット残高からの支払いを実行するための、限定ではなく例として「支払う」と示された支払い実行ボタン242Wと、自分のウォレット残高からの支払いを実行しないための、限定ではなく例として「支払わない」と示された支払い非実行ボタン242Xとが表示されている。
図2-6は、図2-5の共通ウォレット残高不足画面において支払い実行ボタン242Wがタッチ操作された後、サーバ10による決済処理が完了した場合に端末20の表示部24に表示されるコード支払い完了画面の一例を示す図である。
このコード支払い完了画面では、現在位置として「キャンプ資金」が表示され、その下に、決済結果に関する情報が表示されている。具体的には、「コード支払い」の文字とともに、支払い完了メッセージとして「THanK YOU!」の文字が表示され、その下に、感謝の気持ちを示す「笑顔で万歳するロボットの画像」が表示されている。さらに、その下には、支払い金額「3,000円」とともに、「支払いが完了しました。」の文字が表示されている。
また、その下には、支払いの詳細情報として、支払い日は「2020年4月11日」であり、その時刻は「16時30分」であることが表示されている。また、その下には、支払い先が「AAスポーツ株式会社」であることが表示されている。
また、その下には、横線を介して、支払いの内訳が表示されている。この例では、キャンプ資金の共通ウォレットからの支払い金額が「1,000円」であり、自分のウォレットからの支払い金額が「2,000円」であることを示す情報が表示されている。
<処理>
図2-7~図2-8は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
S110の後、サーバ10の制御部11は、端末AのユーザであるユーザA.Aの支払いアプリケーションIDに紐づけられるユーザアカウント情報(限定ではなく例として、電子マネー口座残高)を、通信I/F14によって端末Aに送信する(S120)。
A120の後、通信I/F22によってサーバ10からユーザアカウント情報を受信すると、端末Aの制御部21は、受信されたユーザアカウント情報を表示部24に表示させる(A130)。具体的には、限定ではなく例として、端末AのユーザA.Aの電子マネー口座残高を表示部24に加えて表示させる。
店舗コードリーダ装置50の制御部51は店舗決済処理を実行し、店舗コードリーダ装置50の入出力部52に対する操作に基づいて、所定の決済予定金額(限定ではなく例として「3,000円」)が制御部51へ入力される。そして、店舗コードリーダ装置50の制御部51は、コードリーダ58を用いて、端末Aの表示部24に表示される支払いコードを読み取る(P100)。この場合、表示部24に表示される支払いコードは、共通ウォレット支払いトークンと関連付けられているため、コードリーダ58の読み取り結果には、共通ウォレット支払いトークンが含まれる。
店舗コードリーダ装置50の制御部51は、限定ではなく例として、店舗IDと、決済予定金額と、共通ウォレット支払いトークンとを含む決済要求情報を通信I/F54によってサーバ10に送信する(P110)。
通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、サーバ10の制御部11は、要求を受けた共通ウォレット支払いトークンから共通ウォレットIDを検索し、その共通ウォレットに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する(S250a)。
決済処理で決済が成功した場合(S260a:YES)、サーバ10の制御部11は、S180cに処理を進める。
一方、決済処理で決済が失敗した場合(S260a:NO)、サーバ10の制御部11は、限定ではなく例として、決済が失敗した旨と、その場合の共通ウォレットでの決済残高不足額とを含む決済残高不足情報を、通信I/F14によって端末Aと店舗コードリーダ装置50とに送信する(S270a)。
A130の後、通信I/F22によってサーバ10から決済残高不足情報を受信すると(A270a:YES)、端末Aの制御部21は、受信された決済残高不足情報を表示部24に加えて表示させる(A280)。また、端末Aの制御部21は、受信した決済残高不足情報に含まれる決済残高不足額を、記憶部28に記憶させる(A290)。
その後、限定ではなく例として、表示部24に決済残高不足情報とともに表示されているユーザアカウント情報に対する操作入力(入出力部23に対する操作入力)がなされたことに基づいて、端末Aの制御部21は、自分(ユーザA.A)の電子マネー口座残高から不足分を支払って、共通ウォレット残高と自分の電子マネー口座残高とから決済を行うようにサーバ10に要求する決済要求情報を、通信I/F22によってサーバ10に送信する(A295)。
通信I/F14によって端末Aから決済要求情報を受信すると、サーバ10の制御部11は、決済処理を実行する(S170c)。具体的には、限定ではなく例として、共通ウォレット残高を「0」まで減少させ、不足分をユーザA.Aの電子マネー口座残高から差し引く。
その後、サーバ10の制御部11は、限定ではなく例として、図2-6の支払い完了画面に含まれる各種の情報を含む決済結果情報を、通信I/F14によって端末Aと店舗コードリーダ装置50とに送信し(S180c)、処理を終了する。
一方、サーバ10から決済残高不足情報を受信しなかった場合(A270a:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信し、A180に処理を移す。
P110の後、通信I/F54によってサーバ10から決済残高不足情報を受信すると(P120:YES)、店舗コードリーダ装置50の制御部51は、決済残高不足情報を表示部53に表示させる(P130)。そして、店舗コードリーダ装置50の制御部51は、サーバ10から決済結果情報を受信した後、P160に処理を移す。
<決済残高不足情報の表示>
「決済残高不足情報が表示された」とは、「決済残高不足情報が表示された後」や「決済残高不足情報が一旦表示された場合」を意味し、必ずしも決済残高不足情報が現在も表示されていることを要するわけではない。
つまり、「決済残高不足情報が表示された表示部24に対する入力」とは、
(1)決済残高不足情報が表示された後、決済残高不足情報が表示されている状態で表示部24に対する入力がなされた場合
(2)決済残高不足情報が表示された後、決済残高不足情報が非表示とされ、その後に表示部24に対する入力がなされた場合
を含む概念である。
これは、以下説明する実施例においても同様である。
<端末に対する入力>
上記の処理では、端末20のユーザのユーザアカウント(電子マネー口座)から不足分を支払うか否かの選択を、端末20の入出力部23に対する操作入力に基づいて実現する例を示したが、これに限定されない。これを、端末20のマイク25に対する音入力(音声入力を含む。)等によって実現してもよいし、そのようにしなくてもよい。
これは、端末20に対する各種の入力について同様である。
<第2実施例の効果>
第2実施例は、端末20が、自己の端末20のユーザが決済可能なアカウント(限定ではなく、第1アカウントの一例)に基づいて決済に関する処理を制御部21によって実行する。また、端末20は、決済残高不足情報(限定ではなく、第1決済の金額と、第1アカウントの残高とに基づく、第1アカウントの残高が不足していることに関する第1情報の一例)を表示部24に表示する。そして、端末20は、決済残高不足情報が表示された表示部24に対する入力に基づいて、自己の端末20のユーザのユーザアカウント(限定ではなく、第1アカウントとは異なる第2アカウントの一例)から不足分を支払って決済を行う処理(限定ではなく、第1決済に関する処理の一例)を実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第1アカウントの残高が不足していることを端末のユーザに知らせることができる。また、第1アカウントに基づいて決済を実現することができる他、第1アカウントとは異なる第2アカウントに少なくとも基づいて決済を実現することができる。
また、第2実施例は、自己の端末20のユーザが決済可能なアカウントは、共通アカウント(限定ではなく、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントの一例)である構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントに基づいて決済を実現することができる。
<第2変形例(1)>
第2実施例では、利用者提示型のコード決済について説明したが、これに限定されない。
具体的には、限定ではなく例として、店舗提示型のコード決済を適用することもできる。
<表示画面例>
図2-9は、端末20の表示部24に表示されるコードリーダ画面の一例を示す図である。
図2-3のキャンプ資金支払い画面において「コード支払い」のアイコンではなく「コードリーダ」のアイコンが端末20のユーザA.Aによってタッチ操作された場合、限定ではなく例としてアプリケーションコードリーダが起動され、図2-9に示すような支払い店舗コードを読み取るためのコードリーダ画面が表示部24に表示される。
このコードリーダ画面では、タイトルバーの下に「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。
また、その下には、コード読み取り領域CR1が表示され、その下にはユーザに対する操作案内として「コードリーダ」が表示され、その下にはキャンプ資金コード支払い領域2423が表示されている。
キャンプ資金コード支払い領域2423には、上部に、角財布の画像とともに「キャンプ資金」の文字が表示され、その横に、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。また、その下には、がま口財布の画像とともに「自分のウォレット」の文字が表示され、その横に、自分の電子マネー口座残高(この例では「25,000円」)が表示されている。
図2-10は、図2-9のコードリーダ画面で支払い店舗コードが読み取られた場合に表示される読み取り完了画面の一例を示す図である。
コード読み取り領域CR1内には、読み取られた支払い店舗コードが表示されている。また、画面下部のキャンプ資金コード支払い領域2423には、図2-9と同様の情報が表示されている。
図2-11は、図2-10に続けて表示される支払い金額入力画面の一例を示す図である。読み取られた支払い店舗コードからデコードによって情報が取得されると、支払い金額を入力するための支払い金額入力画面が表示される。
この支払い金額入力画面には、ユーザに対する操作案内として「支払い金額の入力」が表示され、その下に、支払い金額の送金先である「AAスポーツ株式会社」のアイコン画像とともに、その名称「AAスポーツ株式会社」が表示されている。また、その下には、入力された支払い金額を表示するための支払い金額表示領域2424が表示されている。また、その下には、「お支払い金額(税込)を入力してください」の文字が表示され、その下に、支払いボタン242Cが表示されている。
また、画面下部には、支払い金額を入力するためのキーボードが表示されるとともに、支払い金額を消去するための消去ボタンCN4が表示されている。
この例では、支払い金額として「3,000円」が入力されて支払い金額表示領域2424に表示された状態が示されている。
図2-12は、図2-10の支払い金額入力画面において支払いボタン242Cがタッチ操作された後、共通ウォレット残高が不足していたことに基づいて表示される共通ウォレット残高不足画面の一例を示す図である。
この共通ウォレット残高不足画面の構成は、図2-5と同様である。図2-5と異なるのは、共通ウォレット残高不足情報表示・操作領域2427の背景がコードリーダ画面である点である。
図2-12の共通ウォレット残高不足画面で支払い実行ボタン242Wがタッチ操作され、サーバ10による決済処理が完了すると、図2-6と同様のコード支払い完了画面が表示される。
<処理>
図2-13~図2-14は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
A300の後、端末Aの制御部21は、限定ではなく例として、決済予定金額を入力させるための表示画面を表示部24に表示させる。端末Aの入出力部23に対するユーザ操作に基づいて、決済予定金額が入力されると、端末Aの制御部21は、限定ではなく例として、共通ウォレットコードリーダ情報に含まれる共通ウォレット支払いトークンと、店舗IDと、決済予定金額とを含む決済要求情報を、通信I/F22によってサーバ10に送信する(A310)。
なお、支払い店舗コードに決済予定金額が含まれている場合には、端末Aにおける決済予定金額の入力は省略することが可能である。
通信I/F14によって端末Aから決済要求情報を受信すると、サーバ10の制御部11は、要求を受けた共通ウォレット支払いトークンから共通ウォレットIDを検索し、その共通ウォレットに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う店舗提示型の決済処理を実行する(S250b)。
S250bにおいて決済が成功した場合には(S260b:YES)、サーバ10の制御部11は、S180dに処理を移す。
S250bにおいて決済が失敗した場合(S260b:NO)、サーバ10の制御部11は、決済が失敗した旨と、その場合の共通ウォレットでの決済残高不足額とを含む決済残高不足情報を、通信I/F14によって端末Aに送信する(S270b)。
通信I/F22によってサーバ10から決済残高不足情報を受信すると(A270b:YES)、端末Aの制御部21は、決済残高不足情報を表示部24に表示させ(A280)、決済残高不足額を記憶部28に記憶させる(A290)。そして、端末Aの制御部21は、A295に処理を移す。具体的には、端末Aの制御部21は、図2-8のA295と同様の趣旨の決済要求情報を通信I/F22によってサーバ10に送信する。そして、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信し、A180に処理を移す。
通信I/F14によって端末Aから決済要求情報を受信すると、サーバ10の制御部11は、図2-8のS170cと同様の趣旨の店舗提示型の決済処理を実行する(S170d)。そして、サーバ10の制御部11は、決済結果情報を通信I/F14によって端末Aに送信して(S180d)、処理を終了する。
一方、サーバ10から決済残高不足情報を受信しなかった場合(A270b:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信し、A180に処理を移す。
<第2変形例(2)>
第2実施例では、共通ウォレット残高が不足している場合に、端末20のユーザのユーザアカウントから不足分を支払うこととしたが、これに限定されない。
具体的には、共通ウォレット残高が不足している場合に、共通ウォレット残高を使用せず、端末20のユーザのユーザアカウントから全額を支払うようにしてもよいし、そのようにしなくてもよい。つまり、決済を行うアカウントを、共通アカウント(共通ウォレット)から端末20のユーザのユーザアカウント(ユーザの電子マネー口座残高)に変更する(切り替える)ようにしてもよいし、そのようにしなくてもよい。
<第3実施例>
第3実施例は、自分のウォレットから共通ウォレットへの送金を実現する実施例である。
自分のウォレットから共通ウォレットへの送金を可能とすることで、限定ではなく例として、あらかじめ共通ウォレット残高を補充したり、支払いの際に共通ウォレット残高が不足している場合に共通ウォレット残高を補充したりすることが可能となる。
第3実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
端末20の表示部24に表示される表示画面例について説明する。
図3-1~図3-3の表示画面は、図2-1~図2-3の表示画面とそれぞれ同様である。
図3-4は、図3-3のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されるコード支払い画面(送金前)の一例を示す図である。
この例では、タイトルバーの下には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、ユーザに対する操作案内として「コード支払い」が表示され、その下には、キャンプ資金コード支払い領域2421が表示されている。
キャンプ資金コード支払い領域2421には、上記と同様に角財布の画像および共通ウォレットの名称(キャンプ資金)とともに、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。
その下には、丸内にチェックマークを含むチェックマークボタンCN2とともに、「自分のウォレットから送金」の文字が表示され、その横に残高(この例では、25,000円)が表示されている。チェックマークボタンCN2がタッチ操作されると、自分のウォレットから共通ウォレットに送金するための送金用画面が表示される。
また、その下には、サーバ10から送信されて端末20が受信したコード(コード画像)であって、「利用者提示型」で決済を行うために用いられるコードである支払いコードとして、限定ではなく例としてバーコードで表される一次元の支払いコードと、限定ではなく例としてQRコード(登録商標)で表される二次元の支払いコードとが表示されている。
また、これらの支払いコードには、これらの支払いコードを利用して決済を行うことのできる期間(以下、「コード使用可能期間」と称する。)が定められており、この例では、支払いコードと関連付けて、コード使用可能期間の残り時間がカウントダウン形式で表示されている。コード使用可能期間は任意の期間とすることができるが、限定ではなく例として「5分間」の期間として定めておくことができる。
なお、コード使用可能期間を、端末20において支払いコードが表示される期間(以下、「コード表示期間」と称する。)とし、コード表示期間が終了した場合に、表示中の支払いコードを非表示とするようにしてもよいし、そのようにしなくてもよい。
図3-5は、図3-4のコード支払い画面においてチェックマークボタンCN2が端末20のユーザA.Aによってタッチ操作された場合に表示される送金用画面の一例を示す図である。
この例では、タイトルバーの下には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、ユーザに対する操作案内として「送金」が表示され、その下には、送金予定相手であるユーザA.Aのアイコン画像およびユーザ名「A.A」が表示されている。
また、その下には、「送金額」の表示とともに、入力された送金予定金額を表示するための送金予定金額入力領域2422が表示されている。ここでは、送金予定金額として「5,000円」が入力された状態が示されている。また、その下には、送金予定金額入力領域2422への加算金額入力用であり、ここでは、「100円」を加算するための第1加算ボタンBT1と、「1,000円」を加算するための第2加算ボタンBT2と、「10,000円」を加算するための第3加算ボタンBT3とが横方向に並んで表示されている。
限定ではなく例として、送金予定金額として「5,000円」が入力された状態で、第1加算ボタンBT1が1回タッチ操作されると、送金予定金額入力領域2422内は「5,100円」と表示され、続けて第2加算ボタンBT2が1回タッチ操作されると「6,100円」と表示され、続けて第3加算ボタンBT3が1回タッチ操作されると「16,100円」と表示される。
また、この例では、送金予定金額入力領域2422内の左部には消去ボタンCN3が表示されており、消去ボタンCN3がタッチ操作されると、送金予定金額入力領域2422内の金額は消去され、送金予定金額入力領域2422内は「0円」と表示される。
また、この例では、第1加算ボタンBT1の下には、ユーザA.A自身のウォレット内での残高(ここでは「25,000円」)が表示される。
また、この例では、送金用画面下部には、送金予定金額入力領域2422内に入力された金額の送金を実行するための送金ボタン242Aが表示されている。
なお、送金予定金額入力領域2422がタッチされると、表示部24の下部に送金予定額を入力するためのテンキー領域が表示され、テンキー領域への入力に基づいて、送金予定額を細かく入力することも可能である。
図3-6は、図3-5の送金用画面において、送金ボタン242Aがタッチ操作された場合に表示されるコード支払い画面(送金後)の一例を示す図である。
キャンプ資金コード支払い領域2421内は、図3-4と同様であるが、送金後であることから、各々残高の金額が異なるものとなっている。つまり、キャンプ資金の共通ウォレット残高として、送金額が加算された「6,000円」が表示され、自分の電子マネー口座残高として、送金額が減算された「20,000円」が表示されている。また、送金が行われたことを示すチェックマークボタンCN2が反転表示されている。
なお、この例では、支払いコードは、何れも図3-4のものと同じコードとなっている。
端末20のユーザA.Aは、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことでコード支払いを行う。
図3-7は、サーバ10によるコード支払いが完了した場合に端末20に表示されるコード支払い完了画面の一例を示す図である。
このコード支払い完了画面では、現在位置として「キャンプ資金」が表示され、「キャンプ資金」の下中央には、「コード支払い」が表示されている。
また、この例では、その下に、支払い完了メッセージとして「THanK YOU!」の文字が表示され、その下に感謝の気持ちを示す「笑顔で万歳するロボットの画像」が表示され、さらにその下に支払い金額として「3,000円」が大文字で表示され、その下に完了通知として「支払いが完了しました。」の文字が表示されている。
また、その下には、支払い完了情報として、支払い日は「2020年4月11日」であり、その時刻は「16時30分」であることが示されている。また、その下に、支払い先は、AAスポーツ株式会社であることが示されている。
また、コード支払い完了画面下部には、確認ボタン242Bが表示される。
<処理>
図3-8は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
なお、処理の後半については、限定ではなく例として図1-9と同一とすることができるため、ここでは説明を省略する。
A130の後、端末Aの制御部21は、ユーザA.Aの電子マネー口座から共通ウォレットへ送金するか否かを選択させるための情報(限定ではなく例として、選択機能を持つボタン)を表示部24に加えて表示させる。そして、端末Aの制御部21は、入出力部23に対するユーザ操作に基づいて、ユーザA.Aの電子マネー口座から共通ウォレットへ送金することが選択されたか否かを判定する(A140)。
共通ウォレットへ送金することが選択された場合(A140:YES)、端末Aの制御部21は、限定ではなく例として、送金額の入力を促す画面(送金用画面)を表示部24に表示させる。端末Aの入出力部23に対するユーザ操作に基づいて送金額が入力されると、端末Aの制御部21は、送金額を含む送金依頼情報を、通信I/F22によってサーバ10に送信する(A150)。
S120の後、通信I/F14によって端末Aから送金依頼情報を受信すると(S130:YES)、サーバ10の制御部11は、ユーザA.Aの電子マネー口座から共通ウォレットへ送金額を送金する送金処理を実行する(S140)。
そして、サーバ10の制御部11は、送金後の共通ウォレット残高を含む共通ウォレット情報を、通信I/F14によって端末Aに送信する(S150)。
通信I/F22によってサーバ10から共通ウォレット情報を受信すると、端末Aの制御部21は、受信された共通ウォレット情報に基づき、限定ではなく例として、共通ウォレット残高を表示部24に更新して表示させる(A160)。
また、サーバ10の制御部11は、送金後のユーザA.Aの電子マネー口座残高を含むユーザアカウント情報を、通信I/F14によって端末Aに送信する(S160)。そして、サーバ10の制御部11は、図1-9のS170aに処理を移す。
通信I/F22によってサーバ10からユーザアカウント情報を受信すると、端末Aの制御部21は、受信されたユーザアカウント情報に基づき、限定ではなく例として、ユーザA.Aの電子マネー口座残高を表示部24に更新して表示させる(A170)。そして、端末Aの制御部21は、図1-9のA180に処理を移す。
なお、ユーザA.Aの電子マネー口座から共通ウォレットへ送金することが選択されなかった場合(A140:NO)、A150~A170のステップは実行されない。従って、サーバ10の制御部11は、送金依頼情報を受信せず(S130:NO)、S140~S160のステップも実行されない。
なお、前述したように、端末20に対する入力は操作入力に限定されない。
上記の処理では、端末20のユーザのユーザアカウント(電子マネー口座)から共通ウォレットへ送金するか否かの選択を、端末20の入出力部23に対する操作入力に基づいて実現する例を示したが、これに限定されない。これを、端末20のマイク25に対する音入力(音声入力を含む。)等によって実現してもよいし、そのようにしなくてもよい。
<第3実施例の効果>
第3実施例は、端末20が、自己の端末20のユーザが決済可能なアカウント(限定ではなく、第1アカウントの一例)が関連付けられた共通ウォレットコード情報(限定ではなく、第1コード情報の一例)と、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)に関するユーザアカウント情報(限定ではなく、第2アカウント情報の一例)とを表示部24に表示する。そして、端末20は、自己の端末20のユーザによる、そのユーザのユーザアカウントの電子マネー口座から共通ウォレットへ送金することを選択するための入力(操作入力、音入力等)(限定ではなく、第2アカウント情報に対する入力の一例)に基づいて、送金用画面を表示部24に表示する処理、送金依頼情報をサーバ10に送信する処理、更新された共通ウォレット残高をサーバ10から受信する処理、受信された共通ウォレット残高を表示部24に更新して表示させる処理、ユーザアカウントの電子マネー口座残高をサーバ10から受信する処理、受信されたユーザアカウントの電子マネー口座残高を表示部24に更新して表示させる処理、支払いコードを表示部24に表示する処理、決済結果情報をサーバ10から受信する処理、受信された決済結果情報を表示部24に表示する処理等の、決済に関連する処理として端末20で実行される処理(限定ではなく、第1アカウントと、第2アカウントとに基づく第1決済に関する処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第1アカウントが関連付けられた第1コード情報を端末の表示領域に表示して決済に利用させることができるとともに、第1アカウントとは異なる第2アカウントに関する第2アカウント情報を端末のユーザに認識させることができる。また、第2アカウント情報に対する入力に基づいて、第1アカウントと第2アカウントとに基づく決済を実現することができる。
また、第3実施例は、上記の自己の端末20のユーザが決済可能なアカウントは、少なくとも自己の端末20のユーザ(一例としてユーザA.A)(限定ではなく、端末のユーザの一例)と、異なる端末20のユーザ(一例としてユーザB.B)(限定ではなく、端末のユーザとは異なる第1ユーザの一例)とが決済可能な共通アカウントである構成を示している。
このような構成により得られる効果の一例として、第1コード情報を端末の表示領域に表示して決済に利用させることができるとともに、共通アカウントとは異なる第2アカウントに関する第2アカウント情報を端末のユーザに認識させることができる。また、第2アカウント情報に対する入力に基づいて、共通アカウントと第2アカウントとに基づく決済を実現することができる。
また、第3実施例は、端末20が、共通ウォレット残高(限定ではなく、共通アカウントに関連付けられた第1電子貨幣の金額)の情報と、送金用画面(限定ではなく、第2アカウントから共通アカウントへ送金を行うための第1表示の一例)とを表示部24に表示する。そして、端末20は、自己の端末20のユーザによる、送金用画面に対する入力(操作入力、音入力等)に基づいて、自己の端末20のユーザのユーザアカウントから共通アカウントへの送金が実行され、共通アカウントへの送金に基づいて、送金後の共通ウォレット残高(限定ではなく、共通アカウントに関連付けられた第2電子貨幣の金額)の情報を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントに関連づけられた第1電子貨幣の金額を端末のユーザに知らせることができる。また、第1表示に対する入力に基づいて、第2アカウントから共通アカウントへの送金を簡単に実現することができるとともに、共通アカウントへの送金に基づいて、共通アカウントに関連付けられた第2電子貨幣の金額を端末のユーザに知らせることができる。
また、第3実施例は、第1決済に関する処理は、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)から送金された共通アカウントに基づいて実行される構成を示している。
このような構成により得られる効果の一例として、第2アカウントから送金された共通アカウントに基づいて決済を実現することができる。
また、第3実施例は、送金用画面に対する入力(限定ではなく、第1表示に対する入力の一例)は、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)から共通アカウントへ送金する金額の入力を含む構成を示している。
このような構成により得られる効果の一例として、第2アカウントから共通アカウントへ送金する金額の入力に基づいて、第2アカウントから共通アカウントへの送金を実現することができる。
また、第3実施例は、第2アカウントは、自己の端末20のユーザのユーザアカウント(限定ではなく、端末のユーザのアカウントの一例)である構成を示している。
このような構成により得られる効果の一例として、端末のユーザのアカウントを第2アカウントとして決済を実現することができる。
<第3変形例(1)>
第3実施例では、利用者提示型のコード決済について説明したが、これに限定されない。
具体的には、限定ではなく例として、店舗提示型のコード決済を適用することもできる。
<表示画面例>
図3-9は、端末20の表示部24に表示されるコードリーダ画面の一例を示す図である。
図3-3のキャンプ資金支払い画面において「コード支払い」のアイコンではなく「コードリーダ」のアイコンが端末20のユーザA.Aによってタッチ操作された場合、限定ではなく例としてアプリケーションコードリーダが起動され、図3-9に示すような支払い店舗コードを読み取るためのコードリーダ画面が表示部24に表示される。
このコードリーダ画面では、タイトルバーの下に「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。
また、「キャンプ資金」の下には、コード読み取り領域CR1が表示され、その下にはユーザに対する操作案内として「コードリーダ」が表示され、その下にはキャンプ資金コード支払い領域2423が表示されている。
キャンプ資金コード支払い領域2423には、上部に共通ウォレットであることを示す角財布の画像とともに「キャンプ資金」の文字が表示され、その横に、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。また、その下には、チェックマークボタンCN2および自分のウォレットから送金の文字とともに、自分の電子マネー口座残高(この例では「25,000円」)が表示されている。
ここで、図3-9のコードリーダ画面においてチェックマークボタンCN2が端末20のユーザA.Aによってタッチ操作されると、図3-5と同様の送金用画面が表示される。この例では、送金用画面においてユーザA.Aが自分のウォレットから共通ウォレットに「5,000円」を送金する場合を例示する。
図3-10は、図3-5の送金用画面において、送金ボタン242Aがタッチ操作されて自分のウォレットからキャンプ資金へ送金が完了し、その後、支払い店舗コードの読み取りが完了した場合に表示される読み取り完了画面の一例を示す図である。
このコード読み取り領域CR1内には、読み取られた支払い店舗コードが表示されている。また、キャンプ資金コード支払い領域2423には、上記のようにユーザA.Aが自分のウォレットから共通ウォレットに「5,000円」を送金したことに基づき、キャンプ資金の共通ウォレット残高として「6,000円」が表示され、自分の電子マネー口座残高として「20,000円」が表示されている。また、送金が行われたことを示すチェックマークボタンCN2が反転表示されている。
図3-11は、図3-10の読み取り完了画面で読み取られた支払い店舗コードからデコードによって情報が取得された場合に表示される支払い金額入力画面の一例を示す図である。
この支払い金額入力画面には、ユーザに対する操作案内として「支払い金額の入力」が表示され、その下に、支払い金額の送金先である「AAスポーツ株式会社」のアイコン画像とともに、その名称「AAスポーツ株式会社」が表示されている。また、その下には、入力された支払い金額を表示するための支払い金額表示領域2424が表示され、ここでは、支払い金額として「3,000円」が入力されて表示されている。また、その下には、「お支払い金額(税込)を入力してください」の文字が表示され、その下に、支払いボタン242Cが表示されている。
また、画面下方には、支払い金額を入力するためのキーボードが表示されるとともに、支払い金額を消去するための消去ボタンCN4が表示されている。
図3-11に示される支払い金額入力画面において、支払いを実行するための支払いボタン242Cがタッチ操作されてコード支払いが完了すると、図3-7と同様にコード支払い完了画面が表示される。
<処理>
図3-12は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図1-11と同一とすることができるため、ここでは説明を省略する。
図3-8のS100aと同様に共通ウォレット支払いトークンが生成され、サーバ10の制御部11は、共通ウォレット支払いトークンを含むコード読み取り用情報である共通ウォレットコードリーダ情報を生成する。そして、サーバ10の制御部11は、共通ウォレットコードリーダ情報を、通信I/F14によって端末Aに送信する(S100b)。そして、サーバ10の制御部11は、S110に処理を移す。
A100の後、通信I/F22によってサーバ10から共通ウォレットコードリーダ情報を受信すると、端末Aの制御部21は、受信された共通ウォレットコードリーダ情報に基づいて、支払い店舗コードを読み取るためのコードリーダ画面を表示部24に表示させる。また、端末Aの制御部21は、コードを読み取るためにカメラ27を起動させる(A110b)。そして、端末Aの制御部21は、A120に処理を移す。
A170の後、加盟店に提示される支払い店舗コードを、カメラ27等を用いて読み取ると、端末Aの制御部21は、読み取った支払い店舗コードから店舗IDを取得する(A190)。
その後、端末Aの制御部21は、決済予定金額を入力させるための表示画面を表示部24に表示させる。端末Aの入出力部23に対するユーザ操作に基づいて、決済予定金額が入力されると、制御部21は、限定ではなく例として、共通ウォレットコードリーダ情報に含まれる共通ウォレット支払いトークンと、店舗IDと、決済予定金額とを含む決済要求情報を、通信I/F22によってサーバ10に送信する(A200)。そして、端末Aの制御部21は、A180に処理を移す。
なお、支払い店舗コードに決済予定金額が含まれている場合には、端末Aにおける決済予定金額の入力は省略することが可能である。
S160の後、通信I/F14によって端末Aから決済要求情報を受信すると、サーバ10の制御部11は、要求を受けた共通ウォレット支払いトークンから共通ウォレットIDを検索し、その共通ウォレットに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する(S170b)。
その後、サーバ10の制御部11は、限定ではなく例として、決済処理の成否および決済処理後の共通ウォレット残高を含む決済結果情報を、通信I/F14によって端末Aに送信する(S180b)。そして、制御部11は、処理を終了する。
本変形例は、端末20が、共通ウォレットコードリーダ情報に基づく、支払い店舗コード(限定ではなく、コード情報の一例)を読み取るためのコードリーダ画面(限定ではなく、第1コードリーダ情報の一例)と、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)に関するユーザアカウント情報(限定ではなく、第2アカウント情報の一例)とを表示部24に表示する。そして、端末20は、自己の端末20のユーザによる、そのユーザのユーザアカウントの電子マネー口座から共通ウォレットへ送金することを選択するための入力(操作入力、音入力等)(限定ではなく、第2アカウント情報に対する入力の一例)に基づいて、送金用画面を表示部24に表示する処理、送金依頼情報をサーバ10に送信する処理、共通ウォレット残高をサーバ10から受信する処理、受信された共通ウォレット残高を表示部24に更新して表示させる処理、ユーザアカウントの電子マネー口座残高をサーバ10から受信する処理、受信されたユーザアカウントの電子マネー口座残高を表示部24に更新して表示させる処理、支払い店舗コードを読み取る処理、決済要求情報をサーバ10に送信する処理、決済結果情報をサーバ10から受信する処理、受信された決済結果情報を表示部24に表示する処理といった、決済に関連する処理として端末20で実行される処理(限定ではなく、第1アカウントと、第2アカウントとに基づく第1決済に関する処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、コード情報の読み取りに関する表示である第1コードリーダ情報を端末の表示領域に表示して決済に利用させることができるとともに、第1アカウントとは異なる第2アカウントに関する第2アカウント情報を端末のユーザに認識させることができる。また、第2アカウント情報に対する入力に基づいて、第1アカウントと第2アカウントとに基づく決済を実現することができる。
<第3変形例(2)>
第3実施例では、支払い開始時におけるユーザA.Aの電子マネー口座残高内から共通ウォレットへ送金する例を示したが、それに限定されない。
限定ではなく例として、共通ウォレットへの送金前に、ユーザA.Aによってあらかじめ登録される外部金融機関の口座から、ユーザA.Aの電子マネー口座へチャージ(送金)を行ってもよい。
<表示画面例>
図3-13は、図3-3のキャンプ資金支払い画面において「コード支払い」のアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されるコード支払い画面(送金前)の一例を示す図である。
キャンプ資金コード支払い領域2421内の表示は、図3-4とほぼ同様であるが、一部が異なっている。具体的には、限定ではなく例として、「自分のウォレットから送金」に関連付けられた自分の電子マネー口座残高の金額の横に、自分の電子マネー口座にチャージするためのチャージボタンCN5が表示されている。また、この例では、自分の電子マネー口座残高として「1,000円」が表示されている。
また、その下には、共通ウォレットにチャージするための表示として、チェックマークボタンCN2とともに「共通ウォレットへチャージ」の文字が表示されている。
図3-14は、図3-13のコード支払い画面(チャージ前)において、チャージボタンCN5がタッチ操作された場合に表示されるチャージ画面の一例を示す図である。
タイトルバーの下には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「自分のウォレット」が表示されている。また、「自分のウォレット」の下には、ユーザに対する操作案内として「チャージ」が表示され、その下に、銀行口座表示領域2425が設けられている。
この例では、銀行口座表示領域2425内には、「〇×銀行」のロゴ(〇×BANK)とともに、その銀行名「〇×銀行」が表示されている。また、その下には、預金種類および口座番号として「普通預金口座 *******」が表示され、その下には、口座名義人である「A.A」が表示されている。
銀行口座表示領域2425の下には、「チャージ金額」の表示とともに、入力されたチャージ予定金額を表示するためのチャージ予定金額入力領域2426が設けられている。ここでは、チャージ予定金額として「24,000円」が入力されて表示されている。
また、その下には、チャージ予定金額入力領域2426へのチャージ金額入力用であり、この例では「100円」をチャージするための第1チャージボタンBT5と、「1,000円」をチャージするための第2チャージボタンBT6と、「10,000円」をチャージするための第3チャージボタンBT7とが横方向に並んで表示されている。
この例において、第1チャージボタンBT5がタッチ操作されると、チャージ予定金額入力領域2426内は「24,100円」と表示され、続けて第2チャージボタンBT6がタッチ操作されると、「25,100円」と表示され、続けて第3チャージボタンBT7がタッチ操作されると、「35,100円」と表示される。
なお、チャージ予定金額入力領域2426内の左部には、消去ボタンBT8が表示され、消去ボタンBT8がタッチ操作されると、チャージ予定金額入力領域2426内の金額は消去され、チャージ予定金額入力領域2426内は「0円」と表示される。
また、チャージ用画面下部には、チャージ予定金額入力領域2426内に入力された金額のチャージを実行するためのチャージボタン242Dが表示されている。チャージボタン242Dがタッチ操作された場合、自分のウォレットに「24,000円」がチャージされる。
なお、チャージ予定金額入力領域2426がタッチ操作されると、表示部24の下部には送金予定額を入力するためのテンキー領域が表示され、テンキー領域への入力に基づいて、送金予定額を細かく入力することも可能である。
図3-15は、図3-14のチャージ画面において、チャージボタン242Dがタッチ操作された場合に表示されるコード支払い画面の一例を示す図である。
キャンプ資金コード支払い領域2421内は、図3-13と同様であるが、チャージされたことから「自分のウォレットから送金」の文字の横に表示される残高(この例では「25,000円」)の金額が異なっている。
なお、この例では、支払いコードは、何れも図3-13のものと同じコードとなっている。
前述のように、「自分のウォレットから送金」に対応するチェックマークボタンCN2がタッチされ、キャンプ資金に対して送金が実行された後、端末20のユーザA.Aは、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことでコード支払いを行う。サーバ10による決済処理が完了すると、図3-7と同様のコード支払い完了画面が表示される。
<処理>
図3-16は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
A130の後、端末Aの制御部21は、限定ではなく例として、ユーザA.Aの電子マネー口座へチャージを行うか否かの選択用画面を表示部24に表示させる。そして、端末Aの制御部21は、端末Aの入出力部23に対するユーザ操作に基づいて、ユーザA.Aの電子マネー口座へチャージすることが選択されたか否かを判定する(A210)。
ユーザA.Aの電子マネー口座へチャージすることが選択された場合(A210:YES)、端末Aの制御部21は、チャージ金額の入力を促す画面を表示部24に表示させる。端末Aの入出力部23に対するユーザ操作に基づいて、チャージ金額が入力されると、端末Aの制御部21は、チャージ金額を含むチャージ依頼情報を、通信I/F22によってサーバ10に送信する(A220)。
S120の後、通信I/F14によって端末Aからチャージ依頼情報を受信すると(S190:YES)、サーバ10の制御部11は、ユーザA.Aの外部金融機関の口座残高からチャージ金額を減額させ、ユーザA.Aの電子マネー口座残高をチャージ金額だけ増加させるチャージ処理を実行する(S200)。
その後、サーバ10の制御部11は、チャージ処理後のユーザA.Aの電子マネー口座残高を含むユーザアカウント情報を、通信I/F14によって端末Aに送信する(S210)。
なお、S200の処理において、ユーザA.Aの外部金融機関の口座残高がチャージ金額を下回る等の理由でチャージが正常に行われない場合には、チャージが失敗した旨を含むユーザアカウント情報を送信してもよいし、送信しなくてもよい。
通信I/F22によってサーバ10からユーザアカウント情報を受信すると、端末Aの制御部21は、受信されたユーザアカウント情報に基づき、限定ではなく例として、端末AのユーザA.Aの電子マネー口座残高を、表示部24に更新して表示させる(A230)。
一方、ユーザA.Aの電子マネーへチャージすることが選択されない場合(A210:NO)、A220~A230のステップは実行されない。従って、サーバ10の制御部11は、チャージ依頼情報を受信せず(S190:NO)、S200~S210のステップも実行されない。
なお、共通ウォレットへの送金処理(図3-16のA170およびS160)の後に、A210~A230のステップおよびS190~S210のステップを実行することで、ユーザA.Aの電子マネー口座へ電子マネーをチャージしてもよいし、しなくてもよい。
<第3変形例(3)>
第3実施例では、決済処理を行う時点におけるユーザA.Aの電子マネー口座残高内から共通ウォレットへ送金する例を示したが、それに限定されない。
限定ではなく例として、共通ウォレットへの送金前に、ユーザA.Aによってあらかじめ登録される外部金融機関の口座から、共通ウォレットへ電子マネーとしてチャージ(送金)を行ってもよい。
図3-17は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
A130の後、端末Aの制御部21は、限定ではなく例として、共通ウォレットへチャージを行うか否かの選択用画面を表示部24に表示させる。そして、端末Aの制御部21は、端末Aの入出力部23に対するユーザ操作に基づいて、共通ウォレットへチャージすることが選択されたか否かを判定する(A240)。
共通ウォレットへチャージすることが選択された場合(A240:YES)、端末Aの制御部21は、共通ウォレットへのチャージ金額の入力を促す画面を表示部24に表示させる。端末Aの入出力部23に対するユーザ操作に基づいて、共通ウォレットへのチャージ金額が入力されると、端末Aの制御部21は、共通ウォレットへのチャージ金額を含む共通ウォレットチャージ依頼情報を、通信I/F22によってサーバ10に送信する(A250)。
S120の後、通信I/F14によって端末Aから共通ウォレットチャージ依頼情報を受信すると(S220:YES)、サーバ10の制御部11は、ユーザA.Aの外部金融機関の口座残高から共通ウォレットへのチャージ金額を減額させ、共通ウォレット残高を共通ウォレットへのチャージ金額だけ増加させる共通ウォレットチャージ処理を実行する(S230)。
その後、サーバ10の制御部11は、共通ウォレットチャージ処理後の共通ウォレット残高を含む共通ウォレット情報を、通信I/F14によって端末Aに送信する(S240)。
なお、S230の処理において、ユーザA.Aの外部金融機関の口座残高が共通ウォレットへのチャージ金額を下回る等の理由でチャージが正常に行われない場合には、チャージが失敗した旨を含む共通ウォレット情報を送信してもよいし、送信しなくてもよい。
通信I/F22によってサーバ10から共通ウォレット情報を受信すると、端末Aの制御部21は、受信された共通ウォレット情報に基づき、限定ではなく例として、共通ウォレット残高を、表示部24に更新して表示させる(A260)。
一方、共通ウォレットへ電子マネーをチャージすることが選択されない場合(A240:NO)、A250~A260のステップは実行されない。従って、サーバ10の制御部11は、共通ウォレットチャージ依頼情報を受信せず(S220:NO)、S230~S240のステップも実行されない。
なお、共通ウォレットへの送金処理(図3-17のA170およびS160)の後に、A240~A260のステップおよびS220~S240のステップを実行することで、共通ウォレットへ電子マネーをチャージしてもよいし、しなくてもよい。
<第3変形例(4)>
第3実施例において、端末20が、自己の端末20のユーザとは異なる他の共通ウォレットメンバーの端末20に共通ウォレットへの送金を依頼する情報を送信するなどして、共通ウォレットへ送金を行ってもらうようにしてもよいし、そのようにしなくてもよい。
図3-18は、本変形例において端末20の表示部24に表示されるコード支払い画面の一例を示す図であり、ユーザA.Aの端末20(端末A)の表示部24に表示される画面の一例を示している。
このコード支払い画面は、韓国旅行用の共通ウォレットに対応するコード支払い画面であり、韓国旅行用の共通ウォレットの表示領域である韓国旅行表示領域2431内に、前述した自分のウォレットから共通ウォレットに送金するための「自分のウォレットから送金」の項目および共通ウォレットへチャージするための「共通ウォレットへチャージ」の項目に加えて、共通ウォレットへの送金を他の共通ウォレットメンバーに依頼するための「ほかのメンバーへ送金依頼」の項目が設けられている。また、これら各々の項目と関連付けて、その項目に対応する処理を実行させるためのチェックマークボタンCN2が設けられている。
図3-19は、図3-18のコード支払い画面において他のメンバーへ送金依頼の項目に関連付けられたチェックマークボタンCN2がタッチ操作された場合に表示部24に表示されるメンバー選択画面の一例を示す図である。
このメンバー選択画面は、送金を依頼する共通ウォレットメンバー(送金依頼先)を選択するための画面であり、画面中央部に、共通ウォレットメンバーの候補が一覧表示されている。この例では、韓国旅行用の共通ウォレットの共通ウォレットメンバーであって、自己の端末20のユーザ(ユーザA.A)以外の共通ウォレットメンバーとして、ユーザD.Dと、ユーザE.Eとの2名が、アイコン画像およびユーザ名とともに表示されている。
各々の共通ウォレットメンバーには、チェックマークボタンCN2が関連付けて表示されており、チェックマークボタンCN2を「ON」の状態とすることで、その共通ウォレットメンバーを送金依頼先として選択することができるように構成されている。
この場合、1人に限らず、2人以上(全員を含む。)の共通ウォレットメンバーを送金依頼先として選択することも可能である。
また、画面下部には、送金の依頼を実行するための「送金依頼」と示された送金依頼ボタン242Uと、前の画面に戻るための「戻る」と示された戻るボタン242Vとが表示されている。
送金依頼ボタン242Uは、全てのチェックマークボタンCN2が「OFF」の状態では、限定ではなく例としてグレーアウトしており、操作を受付不可の状態となっている。少なくとも1つのチェックマークボタンCN2が「ON」の状態となると、グレーアウトが解除され、操作を受付可能な状態となる。
なお、この例とは異なり、送金依頼先のユーザを、少なくとも自己の端末20のユーザと他の共通ウォレットメンバーとを含むチャットルームの選択に基づいて選択するようにすることも可能である。
以下では、メッセージングアプリケーションにおけるトークルームを例に挙げて説明する。メッセージングアプリケーションを利用したトークは「チャット」の一例であり、トークルームは「チャットルーム」の一例である。
「チャット」とは、コンピュータネットワーク上のデータ通信回線を用いて端末20のユーザ同士がコミュニケーションを行うための手段であり、「チャットルーム」は、このチャットを行うための仮想的な部屋である。チャットには、メッセージングサービス:MS(インスタントメッセージングサービス(IMS)を含む。)、ソーシャルネットワーキングサービス:SNSを利用するものを含む。また、限定ではなく例として、いわゆるショートメッセージサービスを利用するものを含めてもよい。
本明細書において、チャットには、メッセージングサービスを利用したトークが含まれ、チャットルームには、トークを行うためのトークルームが含まれる。トークルームには、一対一でユーザがトークを行うためのトークルームの他、メッセージングサービスにおいて形成された複数のユーザを含むグループでトークを行うためのグループトークルームが含まれる。
図3-20は、本変形例におけるサーバ10の構成の一例を示す図である。
サーバ10は、限定ではなく例として、支払い管理サーバ10Aと、メッセージング管理サーバ10Bとを備える。
支払い管理サーバ10Aは、支払いサービスを提供するサーバ(支払いアプリケーションのアプリケーションサーバ)である。
メッセージング管理サーバ10Bは、メッセージングサービス(MS:Messaging Service)を提供するサーバ(メッセージングアプリケーションのアプリケーションサーバ)である。
なお、支払いアプリケーションは、上記の実施例のように、メッセージングサービスの機能を有さない単体のアプリケーションとしてサーバ10によって提供されるようにしてもよいし、本変形例のように、メッセージングサービスの機能を有する複合的なアプリケーションとしてサーバ10によって提供されるようにしてもよい。
また、メッセージングサービスには、端末20間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス(IMS:Instant Messaging Service)を含めてもよいし、含めなくてもよい。
本変形例において、メッセージング管理サーバ10Bは、メッセージングサービスとして、限定ではなく例として、IMSを提供することとして説明する。
また、以下では、メッセージングアプリケーションと支払いアプリケーションとが複合的なアプリケーションとして構成されており、メッセージングアプリケーションのユーザの情報と、支払いアプリケーションのユーザの情報とが、共通の情報としてサーバ10で管理されていることとして説明する。
また、以下では、メッセージングアプリケーションの名称を、適宜「Messaging App」として図示・説明する。
図3-21は、この場合にユーザA.Aの端末Aで実行されるメッセージングアプリケーションにおけるメンバー選択画面(トークルーム選択画面)の一例を示す図である。
限定ではなく例として、図3-18のコード支払い画面において他のメンバーへ送金依頼の項目に関連付けられたチェックマークボタンCN2がタッチ操作されると、支払いアプリケーションの画面からメッセージングアプリケーションの画面に遷移し、このメンバー選択画面が表示される。
このメンバー選択画面では、画面上部に「Messaging App」の文字が表示され、その横に、自己の端末20のユーザ(この例ではユーザA.A)のアイコン画像およびユーザ名が表示されている。
また、「トークルームから選択」の文字とともに、「送金依頼するトークルームを選んでください」の文字が表示され、その下に、送金依頼先として選択するトークルームの候補が表示されている。
具体的には、限定ではなく例として、メッセージングアプリケーションにおいてユーザA.Aと友だち登録されているユーザであって韓国旅行用の共通ウォレットと関連のあるユーザとの間でユーザA.Aがトークを行うためのトークルームとして、共通ウォレットメンバーであるユーザD.Dのトークルームと、同じく共通ウォレットメンバーであるユーザE.Eのトークルームとが表示されている。
また、この例では、限定ではなく例として、メッセージングアプリケーションにおいてユーザA.Aと友だち登録されているユーザであって韓国旅行用の共通ウォレットと関連のあるユーザとの間でユーザA.Aがグループトークを行うためのグループトークルームとして、限定ではなく例として、ユーザA.AとユーザD.DとユーザE.Eとの3名で構成される「韓国グルメ連合(3)」のグループトークルームが表示されている。
各々のトークルームには、チェックマークボタンCN2が関連付けて表示されており、チェックマークボタンCN2を「ON」の状態とすることで、そのトークルーム(そのトークルームのユーザ)を送金依頼先として選択することができるように構成されている。
この場合、限定ではなく例として、1人に限らず、2人以上(全員を含む。)のユーザを送金依頼先として選択することも可能である。
なお、上記のメッセージングアプリケーションにおけるメンバー選択画面において、グループトークルームは送金依頼先の候補として表示しないようにしてもよい。また。メッセージングアプリケーションにおいてユーザA.Aと友だち登録されている全てのユーザ、支払いアプリケーションにおいてユーザA.Aと共通ウォレットメンバーとなっているユーザ、あらかじめユーザA.Aが選択・設定しておいたユーザ等のトークルームを送金依頼先の候補として表示するようにしてもよいし、そのようにしなくてもよい。
本変形例は、第2アカウントは、自己の端末20のユーザとは異なる他の共通ウォレットメンバー(限定ではなく、第1ユーザの一例)のユーザアカウント(限定ではなく、第1ユーザのアカウントの一例)である構成を示している。
このような構成により得られる効果の一例として、第1ユーザのアカウントを第2アカウントとして、共通アカウントと、第2アカウントとに基づく決済を実現することができる。
また、本変形例は、他の共通ウォレットメンバーのユーザアカウントは、自己の端末20のユーザによる自己の端末20に対する入力に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる端末に対する入力に基づいて、第2アカウントを簡単に選択することができる。
また、本変形例は、他の共通ウォレットメンバーのユーザアカウントは、自己の端末20のユーザと他の共通ウォレットメンバーとを含むトークルーム(限定ではなく、チャットルームの一例)の選択に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる、端末のユーザと第1ユーザとを含むチャットルームの選択に基づいて、第2アカウントを簡単に選択することができる。
<第4実施例>
第4実施例は、端末20が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高から実行するが、支払い時に共通ウォレット残高が不足している場合に、共通ウォレット残高が不足していることに関する情報を表示する実施例である。
また、第4実施例は、共通ウォレット残高が不足している場合に、共通ウォレットに代えて、第3実施例で説明した手法に基づき、自己の端末20のユーザの電子マネー口座から共通ウォレットへ送金を行うことで、共通ウォレットの残高不足を補う実施例である。
第4実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図4-1は、図3-4のコード支払い画面においてチェックマークボタンCN2をタッチ操作せずに、支払いコードでコード支払いした場合であって、共通ウォレット残高が不足した場合に表示される共通ウォレット残高不足画面の一例を示す図である。
この共通ウォレット残高不足画面では、現在位置として「キャンプ資金」が表示され、「キャンプ資金」の下には、共通ウォレット残高不足情報表示・操作領域2427が、ポップアップ形式で表示されている。この例では、残高が不足していることを表す画像として「困った顔のロボット」の画像が表示され、その下に残高不足メッセージとして「共通ウォレット残高不足です」が表示されている。
また、その下には、「支払いしようとする買い物」が文字で表示され、その下に、AAスポーツ株式会社のロゴ画像とともに、その会社名である「AAスポーツ株式会社」の文字が表示されている。その横には、支払い金額として「3,000円」の文字が表示され、その下には、内訳として、角財布の画像および共通ウォレットの名称(キャンプ資金)とともに、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。
また、その下には、端末20のユーザのウォレット(電子マネー口座)であることを示すがま口財布の画像および自分のウォレットとともに、自分の電子マネー口座残高(この例では「25,000円」)が表示されている。さらに、その下には、共通ウォレット残高不足を自分のウォレットから送金するために、「自分のウォレット残高から2,000円を送金しますか?」の案内文が表示されている。
また、この例では、共通ウォレット残高不足情報表示・操作領域2427の下部には、残高不足を補うために、不足金額の送金を実行するための、限定ではなく例として「送金する」と示された送金ボタン242Eが表示されている。また、その下には、不足金額の送金を実行しないための、限定ではなく例として「今はしない」と示されたキャンセルボタン242Fが表示されている。
図4-2は、図4-1の共通ウォレット残高不足画面において、送金ボタン242Eがタッチ操作された場合に表示されるコード支払い画面(送金後)の一例を示す図である。
キャンプ資金コード支払い領域2421内は、図3-4と同様であるが、自分のウォレットから送金後であることから、各々残高の金額が異なるものとなっている。つまり、キャンプ資金の共通ウォレット残高として、送金額が加算された「3,000円」が表示され、自分の電子マネー口座残高として、送金額が減算された「23,000円」が表示されている。
図4-3は、図3-7と同様にサーバ10によるコード支払いが完了した場合に端末20に表示されるコード支払い完了画面の一例を示す図である。
図4-3に示すコード支払い完了画面は、図3-7に示すコード支払い完了画面とは、支払先の下に、下線を介して支払い内訳が追加されている点が異なっている。具体的には、支払い内訳として、角財布の画像およびキャンプ資金の文字とともに、この「キャンプ資金」の共通ウォレット残高(この例では「1,000円」)が表示されている。また、その下に、がま口財布の画像および自分のウォレットの文字とともに、自分の電子マネー口座残高(この例では「2,000円」)が表示されている。
<処理>
図4-4~図4-5は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
店舗コードリーダ装置50の制御部51は店舗決済処理を実行し、店舗コードリーダ装置50の入出力部52に対する操作に基づいて、所定の決済予定金額(限定ではなく例として「3,000円」)が制御部51へ入力される。そして、店舗コードリーダ装置50の制御部51は、コードリーダ58を用いて、端末Aの表示部24に表示される支払いコードを読み取る(P100)。この場合、表示部24に表示される支払いコードは、共通ウォレット支払いトークンと関連付けられているため、コードリーダ58の読み取り結果には、共通ウォレット支払いトークンが含まれる。
店舗コードリーダ装置50の制御部51は、限定ではなく例として、店舗IDと、決済予定金額と、共通ウォレット支払いトークンとを含む決済要求情報を通信I/F54によってサーバ10に送信する(P110)。
S120の後、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、サーバ10の制御部11は、要求を受けた共通ウォレット支払いトークンから共通ウォレットIDを検索し、その共通ウォレットに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する(S250a)。
決済処理で決済が成功した場合(S260a:YES)、サーバ10の制御部11は、S180aに処理を進める。
一方、決済処理で決済が失敗した場合(S260a:NO)、サーバ10の制御部11は、決済が失敗した旨と、その場合の共通ウォレットでの決済残高不足額とを含む決済残高不足情報を、通信I/F14によって端末Aと店舗コードリーダ装置50とに送信する(S270a)。そして、サーバ10の制御部11は、S130に処理を移す。S130~S160の各ステップは、図3-8と同様である。そして、サーバ10の制御部11は、S170aに処理を進める。
A130の後、通信I/F22によってサーバ10から決済残高不足情報を受信すると(A270a:YES)、端末Aの制御部21は、受信された決済残高不足情報を表示部24に表示させる(A280)。
また、端末Aの制御部21は、受信した決済残高不足情報に含まれる決済残高不足額を、記憶部28に記憶させる(A290)。そして、端末Aの制御部21は、A140に処理を移す。A140~A170の各ステップは、図3-8と同様である。そして、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信し、A180に処理を進める。
一方、サーバ10から決済残高不足情報を受信しなかった場合(A270a:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信し、A180に処理を進める。
P110の後、通信I/F54によってサーバ10から決済残高不足を受信すると(P120:YES)、店舗コードリーダ装置50の制御部51は、決済残高不足情報を表示部53に表示させる(P130)。そして、店舗コードリーダ装置50の制御部51は、再度コード読み取り処理を実行する(P140)。そして、店舗コードリーダ装置50の制御部51は、P150に処理を進める。
一方、サーバ10から決済残高不足情報を受信しなかった場合(P120:NO)、店舗コードリーダ装置50の制御部51は、通信I/F54によってサーバ10から決済結果情報を受信し、P160に処理を進める。
なお、本実施例における「決済残高不足情報が表示された」の意味は、第2実施例と同様である。
<第4実施例の効果>
第4実施例は、端末20が、自己の端末20のユーザが決済可能なアカウント(限定ではなく、第1アカウントの一例)に基づいて決済に関する処理を制御部21によって実行する。また、端末20は、決済残高不足情報(限定ではなく、第1決済の金額と、第1アカウントの残高とに基づく、第1アカウントの残高が不足していることに関する第1情報の一例)を表示部24に表示する。そして、端末20は、決済残高不足情報が表示された表示部24に対する入力に基づいて、自己の端末20のユーザのユーザアカウント(限定ではなく、第1アカウントとは異なる第2アカウントの一例)から共通アカウントに送金する処理(限定ではなく、第1決済に関する処理の一例)を実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第1アカウントの残高が不足していることを端末のユーザに知らせることができる。また、第1アカウントに基づいて決済を実現することができる他、第1アカウントとは異なる第2アカウントに少なくとも基づいて決済を実現することができる。
また、第4実施例は、自己の端末20のユーザが決済可能なアカウントは、共通アカウント(限定ではなく、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントの一例)である構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントに基づいて決済を実現することができる。
また、第4実施例は、決済に関する処理は、決済残高不足情報が表示された表示部24に対する入力に基づいて、共通アカウントと、自己の端末20のユーザのユーザアカウントとに基づいて、実行される構成を示している。
このような構成により得られる効果の一例として、共通アカウントと、第2アカウントとに少なくとも基づいて決済を実現することができる。
また、第4実施例は、決済(限定ではなく、第1決済の一例)は、共通ウォレット残高と、自己の端末20のユーザのユーザアカウントの電子マネー口座残高とのうち、共通ウォレット残高(限定ではなく、共通アカウントの残高の一例)から優先的に支払いが行われる構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高から優先的に支払いが行われるため、第2アカウントを付随的なアカウントとすることができる。
また、第4実施例は、決済は、自己の端末20のユーザのユーザアカウントから共通アカウントに送金され、共通アカウントの残高に基づいて行われる構成を示している。
このような構成により得られる効果の一例として、第2アカウントから共通アカウントに送金して金額を補充することができるとともに、共通アカウントの残高に基づいて決済を行わせることができる。
また、第4実施例は、決済に関する処理は、自己の端末20のユーザによる自己の端末20に対する入力に基づいて、自己の端末20のユーザのユーザアカウントから共通アカウントに送金される構成を示している。
このような構成により得られる効果の一例として、端末のユーザが端末に対する入力を行って、第2アカウントから共通アカウントに送金させるようにすることができる。
また、第4実施例は、端末20が、自己の端末20のユーザによる決済残高不足情報が表示された表示部24に対する入力に基づいて、自己の端末20のユーザのユーザアカウントが関連付けられた支払いコード(限定ではなく、第2アカウントと関連づけられた第1コード情報の一例)、または共通ウォレットコードリーダ情報に基づく、支払い店舗コード(限定ではなく、コード情報の一例)を読み取るためのコードリーダ画面(限定ではなく、第1コードリーダ情報の一例)を表示部24に表示する。そして、端末20は、支払いコードが読み取られることに基づいて、またはコードリーダ画面が表示部24に表示された端末20によって支払い店舗コードを読み取ることに基づいて、決済に関する処理を実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる第1情報が表示された表示領域に対する入力に基づいて、第2アカウントと関連づけられた第1コード情報、またはコード情報の読み取りに関する表示であるコードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、第1コード情報が読み取られることに基づいて、またはコードリーダ情報が表示領域に表示された端末によってコード情報を読み取ることに基づいて、簡単に決済を実現することができる。
また、第4実施例は、第2アカウントは、自己の端末20のユーザのユーザアカウント(限定ではなく、端末のユーザのアカウントの一例)である構成を示している。
このような構成により得られる効果の一例として、第1アカウントとは異なる端末のユーザのアカウントに少なくとも基づいて決済を実現することができる。
また、第4実施例は、決済に関する処理は、表示部24に表示された支払いコードが店舗コードリーダ装置50によって読み取られることに基づいて実行される構成を示している。
このような構成により得られる効果の一例として、表示領域に表示されたコード情報が読み取られることに基づいて、簡単に決済を実現することができる。
また、第4実施例は、決済残高不足情報(限定ではなく、第1情報の一例)は、決済予定金額(限定ではなく、第1決済の金額の一例)と、共通ウォレット残高(限定ではなく、共通アカウントの残高の一例)とに基づき、共通ウォレット残高が不足している場合、サーバ10(限定ではなく、第1決済の処理を実行するサーバの一例)から端末20の通信I/F22によって受信される構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高が不足している場合、第1決済の処理を実行するサーバから第1情報を簡単に取得することができる。
また、第4実施例は、サーバ10が、一の端末20のユーザが決済可能なアカウント(限定ではなく、端末のユーザが決済可能な第1アカウントの一例)に基づいて、決済処理(限定ではなく、第1決済に関する処理の一例)を制御部11によって実行する。また、サーバ10は、決済残高不足情報(限定ではなく、第1決済の金額と、第1アカウントの残高とに基づく、第1アカウントの残高が不足していることに関する第1情報の一例)を、一の端末20に通信I/F14によって送信する。そして、サーバ10は、一の端末20のユーザによる、この端末20の表示部24に表示された決済残高不足情報に対する入力に基づいて、この端末20のユーザのユーザアカウント(限定ではなく、第1アカウントとは異なる第2アカウントの一例)に少なくとも基づいて、決済処理を制御部11によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第1アカウントの残高が不足していることを端末に通知することができる。また、第1アカウントに基づいて決済を行うことができる他、第1アカウントとは異なる第2アカウントに少なくとも基づいて決済を行うことができる。
なお、一の端末20のユーザが決済可能なアカウントは、上記と同様に、限定ではなく例として、共通アカウント(限定ではなく、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントの一例)とすることができる。
<第4変形例(1)>
第4実施例では、ユーザA.Aの電子マネー口座から共通ウォレットへ送金することが選択された場合(図4-4のA140:YES)、端末Aの制御部21は、送金額の入力を促す画面を表示部24に表示させることとしたが、これに限定されない。
限定ではなく例として、端末Aの制御部21は、図4-4のA290で記憶する決済残高不足額を送金額として設定し、送金依頼情報をサーバ10に送信することとしてもよいし、そのようにしなくてもよい。
<第4変形例(2)>
第4実施例では、店舗コードリーダ装置50の制御部51は、決済結果情報を表示部53に表示させると(図4-4のP130)、再度コード読み取り処理を実行し、決済要求情報をサーバ10に送信することとしたが、これに限定されない。
限定ではなく例として、サーバ10の制御部11は、図4-4のS130で送金依頼情報を受信する場合(S130:YES)、ユーザアカウント情報を端末20に送信すると(図4-4のS160)、店舗コードリーダ装置50から決済要求情報を受信せずとも、図4-4のS250aの決済処理で使用した決済要求情報に基づいて、図4-5のS170aの決済処理を実行してもよいし、実行しなくてもよい。
この場合、店舗コードリーダ装置50の制御部51は、図4-4のP130のステップの後に通信I/F54によってサーバ10から決済結果情報を受信し、図4-5のP160のステップを実行する。
<第4変形例(3)>
第4実施例では、利用者提示型のコード決済に関して説明したが、これに限定されない。具体的には、店舗提示型のコード決済としてもよい。
<表示画面例>
図4-6は、図3-9のコードリーダ画面からコード支払いを行った場合であって、共通ウォレット残高が不足した場合に表示される共通ウォレット残高不足画面の一例を示す図である。
図4-6が図4-1と異なるのは、共通ウォレット残高不足情報表示・操作領域2427の背景がコードリーダ画面である点である。
図4-6において、自分のウォレット残高から「2,000円」を送金するために送金ボタン242Eがタッチ操作されると、図3-11と同様に、支払い金額入力画面が表示される。ここで、図3-11と同様に「3,000円」が入力されて支払いボタン242Cがタッチ操作されると、図4-3と同様に、コード支払い完了画面が表示される。
<処理>
図4-7~図4-8は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
A130の後、端末Aの制御部21は、カメラ27を用いて加盟店に提示される支払い店舗コードを読み取り、支払い店舗コードから店舗IDを取得する(A300)。
その後、端末Aの制御部21は、決済予定金額を入力させるための表示画面を表示部24に表示させる。端末Aの入出力部23に対するユーザ操作に基づいて、決済予定金額が入力されると、制御部21は、限定ではなく例として、共通ウォレットコードリーダ情報に含まれる共通ウォレット支払いトークンと、店舗IDと、決済予定金額とを含む決済要求情報を、通信I/F22によってサーバ10に送信する(A310)。
なお、支払い店舗コードに決済予定金額が含まれている場合には、端末Aにおける決済予定金額の入力は省略することが可能である。
通信I/F14によって端末Aから決済要求情報を受信すると、サーバ10の制御部11は、要求を受けた共通ウォレット支払いトークンから共通ウォレットIDを検索し、その共通ウォレットに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する(S250b)。
S250bにおいて決済が成功した場合には(S260b:YES)、サーバ10の制御部11は、S180bに処理を移す。
S250bにおいて決済が失敗した場合(S260b:NO)、サーバ10の制御部11は、決済が失敗した旨と、その場合の共通ウォレットでの決済残高不足額とを含む決済残高不足情報を、通信I/F14によって端末Aに送信する(S270b)。そして、サーバ10の制御部11は、S130に処理を移す。また、サーバ10の制御部11は、S160の後、端末Aから決済要求情報を受信して、S170bに処理を移す。
端末Aの制御部21は、通信I/F22によってサーバ10から決済残高不足情報を受信すると(A270b:YES)、決済残高不足情報を表示部24に表示させ(A280)、決済残高不足額を記憶部28に記憶させる(A290)。そして、端末Aの制御部21は、A140に処理を移す。また、端末Aの制御部21は、A170の後、A190に処理を移す。
なお、第4変形例(1)と同様に、ユーザA.Aの電子マネー口座から共通ウォレットへ送金することが選択された場合(図4-7のA140:YES)、端末Aの制御部21は、図4-7のA290で記憶する決済残高不足額を送金額として設定し、送金依頼情報をサーバ10に送信することとしてもよいし、そのようにしなくてもよい。
本変形例は、決済に関する処理は、端末20による支払い店舗コードの読み取りに基づいて実行される構成を示している。
このような構成により得られる効果の一例として、端末によるコード情報の読み取りに基づいて、簡単に決済を実現することができる。
<第4変形例(4)>
第4変形例(3)では、端末Aの制御部21は、決済残高不足情報を表示部53に表示させると(図4-7のA280)、再度コード読み取り処理を実行し(図4-8のA190)、決済要求情報をサーバ10に送信することとしたが、これに限定されない。
限定ではなく例として、端末Aの制御部21は、ユーザアカウント情報を更新すると(図4-7のA170)、図4-7のA310で送信した決済要求情報に基づいて、図4-8のA200の決済要求情報をサーバ10に送信してもよい。
<第4変形例(5)>
第4実施例では、加盟店での支払いにおいて、共通ウォレットの残高不足を端末AのユーザA.Aの電子マネー口座から送金することで立て替えた場合でも、立て替え分を共通ウォレットの他のユーザ(限定ではなく例としてユーザB.B)へ請求しないこととしたが、これを請求するようにしてもよいし、そのようにしなくてもよい。
図4-9は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図4-4、図4-5と同一の処理で実現可能であるため、ここでは説明を省略する。
端末Aの制御部21は、決済結果情報を表示させると(A180)、立て替え分の精算(清算)を行うか否かの選択用画面を表示部24に表示させる(A320)。
なお、端末Aの記憶部28に記憶された決済残高不足額が「0」の場合、または決済が失敗している場合には、精算を行う必要がない(A320:NO)ため、選択用画面を表示部24に表示させず、処理を終了してもよいし、しなくてもよい。
また、端末Aの記憶部28に記憶された決済残高不足額が「0」より大きく、かつ決済が成功している場合には、選択用画面を表示部24に表示させず、自動的に精算を行う(A320:YES)ようにしてもよいし、しなくてもよい。
端末Aの入出力部23に対するユーザ操作に基づいて、精算を行うことが選択された場合(A320:YES)、端末Aの制御部21は、端末Aの記憶部28に記憶された決済残高不足額を、通信I/F22によってサーバ10に送信する(A330)。
一方、精算を行わないことが選択された場合(A320:NO)、端末Aの制御部21は、処理を終了する。
サーバ10の制御部11は、決済結果情報を送信し(S180a)、通信I/F14によって端末Aから決済残高不足額を受信すると、決済残高不足額が「0」より大きいか否かを判定する(S280)。
受信した決済残高不足額が「0」、もしくは決済残高不足額を受信しない場合(S280:NO)、決済残高不足に陥っていない、もしくは精算は不要と判断され、サーバ10の制御部11は、処理を終了する。
受信した決済残高不足額が「0」より大きい場合には(S280:YES)、サーバ10の制御部11は、限定ではなく例として、決済残高不足額を「M」、共通ウォレットメンバーのユーザ数(共通ウォレットの構成ユーザ数)を「N」としたとき、「M÷N」を共通ウォレットの各構成ユーザへの支払い立替額として算出する。そして、サーバ10の制御部11は、支払い立替額を含む支払い立替額請求情報を、通信I/F14によって共通ウォレットの立替者を除く各構成ユーザの端末(ここでは端末B)に送信する(S290)。
端末Bの制御部21は、支払い立替額請求情報を通信I/F22によってサーバ10から受信すると(B100:YES)、受信した支払い立替額と、支払い立替額の請求に応じるか否かの選択用画面を表示部24に表示させる(B110)。なお、端末Bの制御部21は、支払い立替額請求情報を受信しない場合には(B100:NO)、処理を終了する。
端末Bの入出力部23に対するユーザ操作に基づいて、支払い立替額の請求に応じることが選択された場合(B110:YES)、端末Bの制御部21は、支払い立替額の精算を依頼するための精算依頼情報を通信I/F22によってサーバ10に送信する(B120)。
端末Bの入出力部23に対するユーザ操作に基づいて、支払い立替額の請求に応じないことが選択された場合(B110:NO)、端末Bの制御部21は、処理を終了する。
通信I/F14によって端末Bから精算依頼情報を受信した場合(S300:YES)、サーバ10の制御部11は、精算送金処理を実行する(S310)。
一方、精算依頼情報を受信しない場合(S300:NO)、サーバ10の制御部11は、S330に処理を移す。
精算送金処理では、まず端末BのユーザB.Bの電子マネー口座から、共通ウォレットに支払い立替額を送金する。立替者を除く各構成ユーザの送金が完了すると、共通ウォレットから端末AのユーザA.Aの電子マネー口座へ「(N-1)×支払い立替額」で算出される支払い者負担額を送金する。そして、サーバ10の制御部11は、送金結果を含む精算依頼結果情報を、通信I/F14によって共通ウォレットの各構成ユーザの端末(ここでは端末B)に送信する(S320)。
なお、S290において2以上の端末に対して支払い立替額請求情報を送信する場合、サーバ10の制御部11は、送信した全ての端末から精算依頼情報を受信しない限り精算送金処理を実行しなくてもよいし、そうしなくてもよい。
また、精算送金処理において、共通ウォレットを介せず、ユーザの電子マネー口座間で送金を行ってもよいし、そうしなくてもよい。
最後にサーバ10の制御部11は、送金結果を含む精算結果情報を、通信I/F14によって立替者であるユーザA.Aの端末Aに送信して(S330)、処理を終了する。
通信I/F22によってサーバ10から精算依頼結果情報を受信すると、端末Bの制御部21は、精算依頼結果情報を表示部24に表示させ(B130)、処理を終了する。
また、通信I/F22によってサーバ10から精算結果情報を受信すると、端末Aの制御部21は、精算結果情報を表示部24に表示させ(A340)、処理を終了する。
本変形例は、端末20のユーザB.Bの入力に基づいて、支払い立替額請求情報に基づく共通ウォレットへの送金処理が実行される。ユーザA.Aのアカウント(限定ではなく、第1アカウントの一例)は、ユーザA.Aによる決済(限定ではなく、第1決済の一例)によってユーザA.Aの端末20のユーザアカウントから支払われた金額以上、またはそれよりも多くの金額が共通ウォレットに含まれている場合、ユーザA.Aによる決済によってユーザA.Aのユーザアカウントから支払われた金額が共通ウォレットから送金される構成を示している。
このような構成により得られる効果の一例として、第1アカウントは、第1決済によって第1アカウントから支払われた金額以上、またはそれよりも多くの金額が共通アカウントに含まれている場合、第1決済によって第1アカウントから支払われた金額が共通アカウントから送金されるようにすることができる。
<第4変形例(6)>
第4実施例では、端末Aの制御部21は、ユーザA.Aの電子マネー口座から共通ウォレットへ送金することが選択された場合、選択された時点におけるユーザA.Aの電子マネー口座に基づいて送金依頼情報をサーバ10に送信したが、これに限定されない。
<表示画面例>
図4-10は、図3-3のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されるコード支払い画面(送金前)の一例を示す図である。
図4-10が図3-4と異なるのは、キャンプ資金コード支払い領域2421内において「自分のウォレットから送金」の文字の横に表示される自分の電子マネー口座残高(この例では「1,000円」)の金額である。
図4-11は、図4-10に示すコード支払い画面において支払いコードでコード支払いした場合であって、共通ウォレット残高が不足した場合に表示される共通ウォレット残高不足画面の一例を示す図である。
図4-11が図4-1と異なるのは、共通ウォレット残高不足情報表示・操作領域2427において「自分のウォレットから送金」の文字の横に表示される自分の電子マネー口座残高(この例では「1,000円」)の金額である。この例では、決済予定金額が「3,000円」であるのに対し、キャンプ資金の共通ウォレット残高が「1,000円」であり、「2,000円」足りないことになる。このため、自分のウォレット残高から不足分の「2,000円」を送金するか否かが選択される。
図4-12は、図4-11に示す共通ウォレット残高不足画面において、送金ボタン242Eがタッチ操作された場合に表示される自分のウォレット残高不足画面の一例を示す図である。
図4-12は図4-11における共通ウォレット残高不足情報表示・操作領域2427と同様であるが、ロボットの下に表示される「自分のウォレットの残高不足です」の文字が表示されることと、「自分のウォレットへチャージしますか?」の案内文が表示されていることとが異なっている。また、共通ウォレット残高不足情報表示・操作領域2427下部には、残高不足を補うために、不足金額のチャージを実行するためのチャージボタン242Gが表示されていることが異なっている。また、その下には、チャージを実行しないための、限定ではなく例として「今はしない」と示されたキャンセルボタン242Hが表示されている。
図4-12において、自分のウォレットへチャージするためにチャージボタン242Gがタッチ操作されると、限定ではなく例として図3-14と同様のチャージ画面が表示される。そして、このチャージ画面において所望の金額をチャージすることができる。
この例では、自分のウォレットへ「1,000円」をチャージすることで、自分のウォレット残高が「2,000円」となり、上記の不足分を補うことが可能となる。
なお、この場合に、第4変形例(5)で説明したように、ユーザA.Aが支払いで立て替えた分の金額を、他のユーザ(限定ではなく例としてユーザB.B)に請求するようにすることも可能である。
図4-13は、図4-2と同様に、サーバ10によるコード支払いが完了した場合に端末20に表示されるコード支払い完了画面の一例を示す図である。
図4-13が図3-7と異なるのは、コード支払い完了画面下部に、支払い履歴確認ボタン242Jと、立替分請求ボタン242Kとが表示されていることである。
図4-14は、図4-13のコード支払い完了画面において立替分請求ボタン242Kがタッチ操作された場合に、立替分の請求先として共通ウォレットのキャンプ資金のメンバーであるユーザB.Bに対して立替分の請求をするために表示するおしらせ画面の一例を示す図である。
図4-14において、このアプリケーション画面には、限定ではなく例として、支払いアプリケーションのアプリケーション名である「Payment App」が最上段のタイトルバーに表示され、その横に、ユーザB.Bのアイコン画像と、ユーザ名「B.B」の文字とが表示されている。タイトルバーの下には、「Payment App」の階層メニューにおける現在位置として「おしらせ」文字が表示されている。
「おしらせ」の文字の下には、おしらせを意味するベルのアイコン画像が表示され、その横の上下段の内、上段には件名として「共通ウォレット:キャンプ資金」の文字が表示されるとともに、下段にはその内容として「A.Aさんから立替分の請求がとどきました」の文字が表示される。その下には、おしらせ日を示す「今日」の文字が表示され、その下には、キャンプ資金おしらせ表示領域2429が表示されている。
キャンプ資金おしらせ表示領域2429には、上段に、共通ウォレットであることを示す角財布の画像とともに、その共通ウォレットの名称(この例では「キャンプ資金」)が表示されている。また、その横には、おしらせ日時として、「2020年4月11日16時35分」が表示され、その下には、この共通ウォレットを共同で使用するユーザA.AおよびユーザB.Bのアイコン画像が表示されている。
また、キャンプ資金の下には、立替分の請求金額(以下、「立替分請求金額」と称する。)として「立替分請求金額」の文字が表示され、その下に、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。その下段には、「詳細を閉じる」の文字が表示され、その下には、立替分請求金額の詳細情報として、支払い金額の送金先であるAAスポーツ株式会社のロゴ画像とともに、その会社名「AAスポーツ株式会社」の文字が表示されている。また、横には、送金日時として「2020年4月11日16時30分」が表示され、その下には、支払い金額として「3,000円」が表示されている。
また、その下には、「支払い内訳」が文字で表示され、その下に、角財布の画像および共通ウォレットの名称(キャンプ資金)とともに、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。その下には、がま口財布の画像および「A.Aさんの立替」の文字が表示されるとともに、立替額(この例では「2,000円」)が表示されている。また、その下には、共通ウォレットメンバーのアイコン画像とともに、「共通ウォレットのメンバー」の文字が表示され、人数として(この例では「2人」)が表示されている。
また、この例では、キャンプ資金おしらせ表示領域2429下部に、残高不足を補填するための金額の送金を実行するための送金ボタン242Lと、送金を後で行うためのあとでボタン242Mとが並んで表示されている。また、その下には、メニューに戻るためのメニューボタン242Nが表示されている。
図4-15は、図4-13のコード支払い完了画面において、支払い履歴確認ボタン242Jがタッチ操作された場合に表示される支払い履歴画面の一例を示す図である。
図4-15では、支払い履歴が時系列の若い順に段表示されている。
支払い履歴の1段目には、支払い日時として、「2020年4月5日11時12分」と表示され、その下に、支払い先として、「EEスーパー」の文字が表示され、支払い金額として、この例では「5,000円」が表示されている。
支払い履歴の2段目には、支払い日時として「2020年4月11日16時30分」と表示され、その横に、立替分として「立替分請求(2,000円)」が反転表示された立替分請求アイコン242kが表示されている。立替分請求アイコン242kは、立替分請求ボタン242Kと同様の機能をもつアイコンであり、タッチ操作されると図4-14へ遷移する。また、その下には、支払い先として「AAスポーツ株式会社」が表示され、支払い金額として「3,000円」が表示されている。
なお、上記の例において、立替分を請求したことを示す情報を請求元のユーザの端末20の表示部24に表示させたり、立替分が請求されたことを示す情報を請求先のユーザの端末20の表示部24に表示させるようにすることが可能である。
この場合、これらの情報は、支払いアプリケーションのアプリケーション画面に表示させてもよいが、これに代えて、前述したメッセージングアプリケーションのトークルーム画面に表示させるようにすることも可能である。
図4-16は、図4-13のコード支払い完了画面において立替分請求ボタン242Kが操作されたことに基づいてユーザA.Aの端末20(端末A)の表示部24に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
端末Aのユーザ(ユーザA.A)が端末Bのユーザ(ユーザB.B)に対して立替分の請求を行ったことで、その旨を示すメッセージがメッセージング管理サーバ10Bから端末Aに送信されて、ユーザA.AがユーザB.Bとトークを行うためのトークルーム(ユーザB.Bをトーク相手とするトークルーム)に表示される。この例では、画面向かって右側に、ユーザA.Aを発信元とするメッセージとして、ユーザB.Bに対して立替分を請求したこと、および、その詳細情報を含む第1の立替分請求メッセージ2433が吹き出しで表示されている。
図4-17は、図4-13のコード支払い完了画面において立替分請求ボタン242Kが操作されたことに基づいてユーザB.Bの端末20(端末B)の表示部24に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
端末Aのユーザ(ユーザA.A)から端末Bのユーザ(ユーザB.B)に対して立替分の請求が行われたことで、その旨を示すメッセージがメッセージング管理サーバ10Bから端末Bに送信されて、ユーザA.Aとトークを行うためのトークルームに表示される。この例では、画面向かって左側に、ユーザA.Aを発信元とするメッセージとして、ユーザA.AからユーザB.Bに立替分が請求されたこと、および、その詳細情報を含む第2の立替分請求メッセージ2434が吹き出しで表示されている。
<処理>
図4-18は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
端末Aの制御部21は、ユーザA.Aの電子マネー口座から共通ウォレットへ送金することが選択されると(A140:YES)、A290で記憶した決済残高不足額と、A130で表示したユーザアカウント情報とに基づいて、ユーザA.Aの電子マネー口座残高が決済残高不足額より少ないか否かを判定する(A350)。
ユーザA.Aの電子マネー口座残高が決済残高不足額以上である場合には(A350:NO)、端末Aの制御部21は、A150に処理を移す。
電子マネー口座残高不足の場合(A350:YES)、端末Aの制御部21は、A210~A230のステップを実行する。従って、この場合、サーバ10の制御部11は、S270aのステップを実行すると、S190~S210のステップを実行する。
なお、A210のステップにおいて、アカウントにチャージすることが選択されない場合には(A210:NO)、端末Aの制御部21は、A140に戻って処理を実行してもよいし、しなくてもよい。
本変形例は、端末20が、決済予定金額(限定ではなく、第1決済の金額の一例)と、共通ウォレット残高(限定ではなく、共通アカウントの残高の一例)と、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)とに基づき、決済残高不足情報(限定ではなく、第1決済の金額と、共通アカウントの残高と、第2アカウントとに基づく、共通アカウントの残高が不足していることに関する第2情報の一例)を表示部24に表示する。そして、端末20は、自己の端末20のユーザによる決済残高不足情報が表示された表示部24に対する入力に基づいて、自己の端末20のユーザのユーザアカウントの電子マネー口座にチャージする処理(限定ではなく、第2アカウントに対して送金する処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高が不足していることを端末のユーザに知らせることができる。また、端末のユーザによる入力に基づいて、第2アカウントに対して送金することができる。
また、本変形例は、端末20が、決済予定金額(限定ではなく、第1決済の金額の一例)と、共通ウォレット残高(限定ではなく、共通アカウントの残高の一例)と、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)とに基づき、決済残高不足情報(限定ではなく、共通アカウントの残高と、第2アカウントの残高とに基づき、共通アカウントと第2アカウントとの残高が不足していることに関する第1情報の一例)を表示部24に表示する。そして、端末20は、自己の端末20のユーザによる決済残高不足情報が表示された表示部24に対する入力に基づいて、自己の端末20のユーザのユーザアカウントの電子マネー口座にチャージする処理(限定ではなく、第2アカウントに対して送金する処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントと第2アカウントとの残高が不足していることを端末のユーザに知らせることができる。また、端末のユーザによる第1情報に対する入力に基づいて、第2アカウントに対して送金することができる。
<第4変形例(7)>
第4実施例では、決済処理を実行する端末(限定ではなく例として端末A)のユーザ(限定ではなく例としてユーザA.A)の電子マネー口座から共通ウォレットへ送金するか否かを選択するが、送金元の電子マネー口座はこれに限定されない。
限定ではなく例として、共通ウォレットを構成する他のメンバー(限定ではなく例としてユーザB.B)の電子マネー口座から送金を行えるようにしてもよい。
図4-19は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図4-5と同一とすることができるため、ここでは説明を省略する。
A290の後、端末Aの制御部21は、限定ではなく例として、共通ウォレットメンバーである他のユーザ(限定ではなく例としてユーザB.B)の電子マネー口座から共通ウォレットへ送金を依頼するか否かの選択機能を持つボタンを表示部24に加えて表示させる。そして、端末Aの制御部21は、端末Aの入出力部23に対するユーザ操作に基づいて、他のユーザ(限定ではなく例としてユーザB.B)の電子マネー口座から共通ウォレットへ送金を依頼することが選択されたか否かを判定する(A360)。
ユーザB.Bの電子マネー口座から共通ウォレットへ送金を依頼することが選択された場合(A360:YES)、端末Aの制御部21は、送金を依頼することと、限定ではなく例として決済残高不足額と等しい金額の送金要請額とを含む送金要請情報を、通信I/F22によってサーバ10に送信する(A370)。
ユーザB.Bの電子マネー口座から共通ウォレットへ送金を依頼することが選択されない場合(A360:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信し、図4-5のA180のステップを実行する。
通信I/F14によって端末Aから送金要請情報を受信する場合(S340:YES)、サーバ10の制御部11は、送金要請額を含む送金確認情報を、通信I/F14によって端末Bに送信する(S350)。
送金要請情報を受信しない場合(S340:NO)、サーバ10の制御部11は、決済要求情報を通信I/F14によって店舗コードリーダ装置50から受信し、図4-5のS170aのステップを実行する。
通信I/F22によってサーバ10から送金確認情報を受信する場合(B140:YES)、端末Bの制御部21は、送金確認情報に基づいて、ユーザB.Bの電子マネー口座から共通ウォレットへ送金することを認可するか否かの選択用画面を表示部24に表示させる(B150)。
一方、送金確認情報を受信しない場合(B140:NO)、端末Bの制御部21は、処理を終了する。
端末Bの入出力部23に対するユーザ操作に基づいて、共通ウォレットへ送金することを認可することが選択された場合(B150:YES)、端末Bの制御部21は、送金依頼情報を通信I/F22によってサーバ10に送信する(B160)。
一方、共通ウォレットへ送金することを認可しないことが選択された場合(B150:NO)、端末Bの制御部21は、処理を終了する。
通信I/F14によって端末Bから送金依頼情報を受信する場合(S360:YES)、サーバ10の制御部11は、ユーザB.Bの電子マネー口座から共通ウォレットへ、送金要請額を送金する送金処理を実行する(S370)。そして、サーバ10の制御部11は、限定ではなく例として、送金処理の成否と、送金後のユーザB.Bの電子マネー口座残高とを含む送金依頼結果情報を、通信I/F14によって端末Bに送信する(S380)。
次いで、サーバ10の制御部21は、送金後の共通ウォレット残高を含む共通ウォレット情報を、通信I/F14によって端末Aに送信する(S390)。
端末Bから送金依頼情報を受信しない場合(S360:NO)、サーバ10の制御部11は、共通ウォレット残高を含む共通ウォレット情報を、通信I/F14によって端末Aに送信する(S390)。
なお、この場合、送金要請が端末Bによって断られたことを示す情報を共通ウォレット情報に組み入れて送信するようにしてもよいし、そのようにしなくてもよい。
次いで、サーバ10の制御部11は、決済要求情報を通信I/F14によって店舗コードリーダ装置50から受信し、S170aのステップを実行する。
通信I/F22によってサーバ10から送金依頼結果情報を受信すると、端末Bの制御部21は、送金依頼結果情報を表示部24に表示させ(B170)、処理を終了する。
通信I/F22によってサーバ10から共通ウォレット情報を受信すると、端末Aの制御部21は、受信された共通ウォレット情報に基づき、限定ではなく例として、共通ウォレット残高を表示部24に更新して表示させる(A380)。
なお、送金要請が端末Bによって断られたことを示す情報が共通ウォレット情報に含まれる場合には、限定ではなく例として、その旨を表示部24にポップアップ表示等させるようにしてもよいし、そのようにしなくてもよい。
次いで、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信し、A180のステップを実行する。
なお、上記の処理において、端末20の制御部21が、限定ではなく例として、自己の端末20のユーザ(限定ではなく例としてユーザA.A)による、自己の端末20のユーザと他のユーザ(限定ではなく例としてユーザB.B)とを少なくとも含むトークルーム(限定ではなく、チャットルームの一例)の選択に基づいて、他のユーザ(限定ではなく例としてユーザB.B)の電子マネー口座から共通ウォレットへ送金を依頼することが選択されるようにしてもよいし、そのようにしなくてもよい。
この場合は、限定ではなく例として、図3-21で説明したメッセージングアプリケーションにおけるメンバー選択画面(トークルーム選択画面)と同様の画面を端末20の表示部24に表示させて、送金を依頼するトークルームをユーザに選択させるようにすることができる。
本変形例は、第2アカウントは、自己の端末20のユーザとは異なるユーザ(限定ではなく、第1ユーザの一例)のユーザアカウントである構成を示している。
このような構成により得られる効果の一例として、端末のユーザとは異なる第1ユーザのアカウントに少なくとも基づいて決済を実現することができる。
また、本変形例は、自己の端末20のユーザとは異なるユーザのユーザアカウント(限定ではなく、第2アカウントの一例)は、自己の端末20のユーザによる自己の端末20に対する入力に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる端末に対する入力に基づいて第2アカウントを簡単に選択することができる。
また、本変形例は、自己の端末20のユーザとは異なるユーザのユーザアカウント(限定ではなく、第2アカウントの一例)は、自己の端末20のユーザによる、自己の端末20のユーザと他のユーザ(限定ではなく、第1ユーザの一例)とを含むチャットルームの選択に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザと第1ユーザとを含むチャットルームの選択に基づいて第2アカウントを簡単に選択することができる。
また、本変形例は、端末20が、送金要請情報(限定ではなく、第2アカウントに基づく決済の許可の依頼に関する情報の一例)を自己の端末20とは異なる端末20に通信I/F22によって送信する。そして、決済に関する処理は、自己の端末20のユーザとは異なるユーザ(限定ではなく、第1ユーザの一例)による、そのユーザのアカウント(限定ではなく、第2アカウントの一例)による決済の許可に基づいて実行される構成を示している。
このような構成により得られる効果の一例として、第1ユーザによる第2アカウントによる決済の許可がなされたことに基づいて決済を可能とすることができる。逆に、第1ユーザによる第2アカウントによる決済の許可がなされない場合は決済を不可とすることができる。
<第4変形例(8)>
第4変形例(7)では、加盟店での支払いにおいて、共通ウォレットの残高不足を共通ウォレットの他のユーザ(限定ではなく例としてユーザB.B)の電子マネー口座から送金するよう依頼することで立て替えられた場合でも、立て替え分を自身が請求されることはなかったが、請求されるようにしてもよいし、そのようにしなくてもよい。
図4-20~図4-21は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図4-19と同一とすることができるため、ここでは説明を省略する。
端末Aの制御部21は、決済結果情報を表示させると(A180)、立て替え分の精算を行うか否かの選択用画面を表示部24に表示させる(A320)。
精算を行うことが選択された場合(A320:YES)、端末Aの制御部21は、端末Aの記憶部28に記憶された決済残高不足額を、通信I/F22によってサーバ10に送信した後(A330)、A400に処理を移す。
一方、精算を行わないことが選択された場合(A320:NO)、端末Aの制御部21は処理を終了する。
サーバ10の制御部11は、通信I/F14によって端末Aから受信した決済残高不足額が「0」より大きい場合(S280:YES)、決済残高不足額を立替者の端末20(ここでは端末B)に送信する(S400)。
通信I/F22によってサーバ10から決済残高不足額を受信する場合(B180:YES)、端末Bの制御部21は、端末BのユーザB.Bが立て替えた決済残高不足額分の電子マネーを、共通ウォレットの他のメンバーに請求するか否かの選択用画面を表示部24に表示させる(B190)。
一方、決済残高不足額を受信しない場合(B180:NO)、端末Bの制御部21は、処理を終了する。
端末Bの入出力部23に対するユーザ操作に基づいて、立替分を請求することが選択された場合(B190:YES)、端末Bの制御部21は、精算請求情報を通信I/F22によってサーバ10に送信する(B200)。
一方、立替分を請求しないことが選択された場合(B190:NO)、端末Bの制御部21は、B200をスキップして処理を進める。
通信I/F14によって端末Bから精算請求情報を受信する場合(S410:YES)、サーバ10の制御部11は、S420~S450のステップを実行する。
なお、これらのステップは、送信先・受信元を端末Aとし、図4-9のS290~S320と同様にして実行することが可能であるため、詳細については説明を省略する。
精算請求情報を受信しない場合(S410:NO)、サーバ10の制御部11は、S460のステップに処理を移す。
端末Aの制御部21は、支払い立替額請求情報を通信I/F22によってサーバ10から受信すると(A400:YES)、A410~A440のステップを実行する。
なお、これらのステップは、図4-9のB110~B130のステップと同様にして実行することが可能であるため、詳細については説明を省略する。
支払い立替額請求情報を受信しない場合(A400:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から精算結果情報を受信し、A340のステップを実行する。
最後にサーバ10の制御部11は、送金結果を含む精算結果情報を、通信I/F14によって立替者であるユーザB.Bの端末Bと、精算を発案したユーザA.Aの端末Aとに送信し(S460)、処理を終了する。
また、通信I/F22によってサーバ10から精算結果情報を受信すると、端末Bの制御部21は、精算結果情報を表示部24に表示させ(B210)、処理を終了する。
端末Aについても同様である(A340)。
なお、上記の処理では、端末Bが、自己の端末20のユーザ(ユーザB.B)のユーザアカウントから決済残高不足額分の電子マネーを立て替えることとしたが、これに限定されない。
限定ではなく例として、端末Bが、共通ウォレットメンバーであって、ユーザA.AおよびユーザB.B以外のユーザ(限定ではなく例として、端末CのユーザC.C)のユーザアカウントから決済残高不足額分の電子マネーを使用(消費)して決済を行うようにしてもよい。この場合、ユーザB.Bは、あらかじめユーザC.Cから許可を得ておくようにすればよい。
また、精算請求情報を送信した場合(B200)、端末Bの制御部21は、限定ではなく例として、立替分を請求したことを示す情報を端末Bの表示部24に表示させるようにすることができる。
また、支払い立替額請求情報を受信した場合(A400:YES)、端末Aの制御部21は、立替分が請求されたことを示す情報を端末Aの表示部24に表示させるようにすることができる。
この場合、これらの情報は、支払いアプリケーションのアプリケーション画面に表示させてもよいが、これに代えて、前述したメッセージングアプリケーションのトークルーム画面に表示させるようにすることも可能である。これは、限定ではなく例として、図4-16や図4-17に示した画面に倣って同様に構成可能である。
本変形例は、第2の端末20(請求先の端末20)は、支払い立替額請求情報(限定ではなく、第2アカウントによる支払いに基づく金額の請求に関する請求情報の一例)を、サーバ10を介して第1の端末20(請求元の端末20)から通信I/F22によって受信する。そして、第2の端末20は、受信された支払い立替額請求情報に基づく表示(限定ではなく、請求情報に基づく第1表示、第3表示の一例)を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、第2アカウントによる支払いに基づく金額の請求があったことやその内容を端末のユーザに知らせることができる。
また、本変形例は、第1の端末20は、支払い立替額請求情報(限定ではなく、第2アカウントによる支払いに基づく金額の請求に関する請求情報の一例)を、サーバ10を介して第2の端末20に通信I/F22によって送信する。そして、第1の端末20は、送信された支払い立替額請求情報に基づく表示(限定ではなく、請求情報に基づく第2表示の一例)を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、第2アカウントによる支払いに基づく金額を請求した上で、その請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、第2の端末20は、少なくとも第2の端末20のユーザと、第1の端末20のユーザ(限定ではなく、第1ユーザの一例)とが決済可能な共通アカウントと、第1の端末20のユーザのユーザアカウント(限定ではなく、第1アカウントの一例)とに基づき、第1の端末20(限定ではなく、第1端末の一例)によって決済に関する処理(限定ではなく、第1決済に関する処理の一例)が実行され、第1の端末20のユーザによる決済(限定ではなく、第1決済の一例)に基づいて、支払い立替額請求情報(限定ではなく、第1決済に基づく金額の請求に関する請求情報の一例)を、サーバ10を介して第1の端末20から通信I/F22によって受信する。そして、第2の端末20は、受信された支払い立替額請求情報に基づく表示(限定ではなく、請求情報に基づく第1表示の一例)を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントと、共通アカウントとは異なる第1アカウントとに基づき、第1ユーザの第1端末によって第1決済に関する処理が実行されたことに基づき、第1決済に基づく金額の請求を受けて、その請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、第1アカウントは、第1の端末20のユーザ(限定ではなく、第1ユーザの一例)のユーザアカウントである構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントと、第1ユーザのアカウントとに基づき、第1ユーザの第1端末によって第1決済に関する処理が実行されるようにすることができる。
また、本変形例は、支払い立替額請求情報は、第1の端末20のユーザのユーザアカウントによって立て替えられた金額(限定ではなく、第1アカウントによって支払われた金額の一例)に基づき決定される。そして、第2の端末20は、自己の端末20のユーザのユーザアカウントから第1の端末20のユーザのユーザアカウントに対する送金処理(限定ではなく、請求情報に基づく金額の送金に関する処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第1アカウントによって支払われた金額に基づき決定された請求情報に基づく金額を、端末のユーザのアカウントから第1アカウントに対して送金することができる。
また、本変形例は、支払い立替額請求情報は、共通ウォレットメンバー(限定ではなく、共通アカウントによって決済可能なユーザの一例)に基づいて金額が決定される構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザに基づいて決定された請求情報に基づく金額の請求を受けて、その請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、端末20が、共通ウォレットメンバーとメッセージ等(限定ではなく、コンテンツの一例)の送受信が可能なトークルーム(限定ではなく、チャットルームの一例)に支払い立替額請求情報を表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザとコンテンツの送受信が可能なチャットルームへの表示という分かり易い形で、請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、送金ボタン等(限定ではなく、送金情報の一例)に対する操作(限定ではなく、送金情報に対するユーザの入力の一例)に基づいて、支払い立替額請求情報に基づく送金処理が実行される構成を示している。
このような構成により得られる効果の一例として、請求情報に基づく送金を行うための送金情報に対するユーザの入力に基づいて、簡単に送金を実現することができる。
また、本変形例は、支払い立替額請求情報に基づく表示は、第1の端末20のユーザの情報を含む構成を示している。
このような構成により得られる効果の一例として、第1アカウントのユーザの情報を端末のユーザに知らせることができる。
また、本変形例は、共通アカウントと、第2の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)とに基づき、決済に関する処理(限定ではなく、第2決済に関する処理の一例)が実行される。そして、第2の端末20は、第1の端末20のユーザによる決済(限定ではなく、第1決済の一例)と、第2の端末20のユーザによる決済(限定ではなく、第2決済の一例)とに基づく支払い立替額請求情報を、サーバ10を介して通信I/F22によって第1の端末20から受信する。そして、第2の端末20は、自己の端末20のユーザのユーザアカウントから第1の端末20のユーザのユーザアカウントに対する送金処理(限定ではなく、請求情報に基づく金額の送金に関する処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントと、共通アカウントとは異なる第2アカウントとに基づき、第2決済に関する処理が実行され、第1決済と第2決済とに基づく請求を受けて、端末のユーザのアカウントから第1アカウントに対して送金することができる。
また、本変形例は、支払い立替額請求情報(限定ではなく、第1決済に基づく金額の請求に関する請求情報の一例)は、サーバ10(限定ではなく、第1決済に関する処理を実行するサーバの一例)から送信される構成を示している。
このような構成により得られる効果の一例として、第1決済に関する処理を実行するサーバから請求情報を簡単に取得することができる。
また、本変形例は、第1アカウントは、共通アカウントによって決済可能な、第2の端末20のユーザ(限定ではなく、第1ユーザの一例)とは異なるユーザのユーザアカウント(限定ではなく、第1ユーザとは異なるユーザの一例)のユーザアカウントである構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントと、共通アカウントによって決済可能な、第1ユーザとは異なるユーザのアカウントとに基づき、第1ユーザの第1端末によって第1決済に関する処理が実行されたことに基づき、第1決済に基づく金額の請求を受けて、その請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、サーバ10が、少なくとも第2の端末20のユーザ(限定ではなく、端末のユーザの一例)と、第1の端末20のユーザ(限定ではなく、第1ユーザの一例)とが決済可能な共通アカウントと、第1の端末20のユーザのユーザアカウント(限定ではなく、第1アカウントの一例)とに基づき、決済処理(限定ではなく、第1決済に関する処理の一例)を制御部11によって実行する。そして、サーバ10は、この決済(限定ではなく、第1決済の一例)に基づいて、支払い立替額請求情報(限定ではなく、第1決済に基づく金額の請求に関する請求情報の一例)を第2の端末20に通信I/F14によって送信する構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントと、共通アカウントとは異なる第1アカウントとに基づき、第1決済に関する処理を実行して決済を実現することができる。また、第1決済に基づく金額を端末のユーザに請求することができる。
<第4変形例(9)>
上記の実施例では、端末20の表示部24に表示された支払いコードが店舗コードリーダ装置50によって読み取られることに基づき、または支払い店舗コードが端末20で読み取られることに基づいて決済が実現された。つまり、上記の実施例では、コード決済を行う手法を示したが、これに限定されない。コード決済に代えて、無線通信(近距離無線通信を含む。)によって決済を行うようにすることもできる。
図4-22は、本変形例における店舗コードリーダ装置50の構成例を示す図である。
店舗コードリーダ装置50は、図1-2の構成の他に、限定ではなく例として、近距離無線通信I/F581を備える。
近距離無線通信I/F581は、端末20との間で近距離無線通信を行うためのインタフェースである。
ここで、近距離無線通信には、限定ではなく例として、いわゆる非接触式の近距離通信(以下、「非接触式通信」と称する。)や、ブルートゥースを利用した近距離通信(以下、「ブルートゥース通信」と称する。)等が含まれる。
非接触式通信を適用する場合、近距離無線通信I/F581には、限定ではなく例として、端末20に備えられるNFCチップ等の非接触型ICカードに記憶された情報を読み取るためのカードリーダや、情報を読み取る/情報を書き込むためのカードリーダライタを含めることができる。この場合、上記の実施例におけるコード決済(利用者提示型または店舗提示型)に代えて、端末20のユーザが、自己の端末20を店舗のカードリーダやカードリーダライタにかざすことによって、上記の実施例と同様に決済を行うようにすることができる。
この場合、カードリーダで情報を読み取った結果、共通ウォレット残高(第1アカウントの残高)が不足している場合、サーバ10の制御部11は、限定ではなく例として、共通ウォレット残高が不足していることを示す情報(決済残高不足情報)を、通信I/F14によって端末20に送信する。通信I/F22によってサーバ10から決済残高不足情報を受信すると、端末20の制御部21は、決済残高不足情報を表示部24に表示させる。そして、表示した決済残高不足情報に対する自己の端末20のユーザの入力に基づいて、限定ではなく例として、決済を行うアカウントを、共通アカウントから自己の端末20のユーザのユーザアカウント(第2アカウント)に変更・設定する。そして、端末20のユーザが、自己の端末20を店舗のカードリーダに再度かざすことによって、決済を行うようにすることができる。
なお、カードリーダで情報を読み取った結果、共通ウォレット残高(第1アカウントの残高)が不足している場合は、限定ではなく例として、共通ウォレット残高が不足していることを示す情報をカードリーダライタによって端末20の非接触型ICカードに書き込むようにしてもよいし、そうしなくてもよい。これを受けて、端末20の制御部21は、決済残高不足情報を表示部24に表示させ、表示した決済残高不足情報に対する自己の端末20のユーザの入力に基づいて、限定ではなく例として、決済を行うアカウントを、共通アカウントから自己の端末20のユーザのユーザアカウント(第2アカウント)に変更・設定するようにしてもよいし、そうしなくてもよい。そして、端末20のユーザが、自己の端末20を店舗のカードリーダに再度かざすことによって、決済を行うようにすることができるようにしてもよいし、そうしなくてもよい。
また、ブルートゥース通信を適用する場合、近距離無線通信I/F581は、端末20との間でブルートゥース通信を行うためのブルートゥース通信用のモジュール等が含まれる。この場合も、通信方式を非接触式通信に代えてブルートゥース通信とすることによって、上記と同様の手法で決済を行うようにすることができる。
本変形例は、決済に関する処理は、通信I/F22(限定ではなく、端末の通信部の一例)による、店舗コードリーダ装置50(限定ではなく、第1決済によって購入する商品を販売するまたはサービスを提供する店舗の端末の一例)との無線通信により実行される構成を示している。
このような構成により得られる効果の一例として、端末の通信部によって、第1決済によって購入する商品を販売するまたはサービスを提供する店舗の端末との無線通信を行うことによって、簡単に決済を実現することができる。
また、本変形例は、上記の無線通信は、非接触式通信やブルートゥース通信(限定ではなく、近距離通信の一例)である構成を示している。
このような構成により得られる効果の一例として、第1決済によって購入する商品を販売するまたはサービスを提供する店舗の端末との無線通信を近距離通信によって実現することができる。
<第5実施例>
第5実施例は、端末20(限定ではなく例として端末A)が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高から実行する、または共通ウォレット残高と端末20のユーザ(限定ではなく例としてユーザA.A)の電子マネー口座残高とを合算する一時的な支払い用アカウント(以下、「統合アカウント」と称する。)の電子マネー残高から実行する実施例である。
第5実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<データ構成>
図5-1は、本実施例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、支払いアプリケーション管理処理プログラム151と、支払いアプリケーションユーザ登録データ153と、ユーザ管理データベース155と、共通ウォレット管理データベース157との他に、限定ではなく例として、統合アカウント管理データベース159が記憶される。
統合アカウント管理データベース159は、サーバ10が統合アカウントを管理するためのデータベースであり、そのデータ構成の一例を図5-2に示す。
統合アカウント管理データベース159には、統合アカウントごとの管理データとして、統合アカウント管理データが記憶される。
各々の統合アカウント管理データには、限定ではなく例として、その統合アカウントを識別するための識別情報の一例である統合アカウントIDと、その統合アカウントに含まれるユーザのアカウントを示す統合アカウントメンバーIDとが記憶される。統合アカウントメンバーIDには、統合アカウントに統合されている支払いアプリケーションのアカウント(ユーザの支払いアプリケーションIDや共通ウォレットID等を含む。)が記憶される。
図5-2では、限定ではなく例として、「UN0001」で識別される統合アカウントは、「U0001」(すなわちユーザA.A)と、「S0001」(すなわち共通ウォレット「キャンプ資金」)とで構成されることが示されている。
<表示画面例>
図5-3は、図3-3のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されているコード支払い画面(統合前)の一例を示す図である。
図5-3の画面は、図3-4の画面とほぼ同様であるが、キャンプ資金コード支払い領域2421内の一部の表示が異なっている。
図3-4のキャンプ資金コード支払い領域2421内では、チェックマークボタンCN2とともに「自分のウォレットから送金」の文字が表示され、その横に残高(この例では「25,000円」)が表示されていたが、図5-3のキャンプ資金コード支払い領域2421内では、キャンプ資金の共通ウォレットを自分のウォレットと統合するための情報として、「自分のウォレットと統合」の文字とともに、統合を実行するか否かを選択するための(切り替えるための)スライドボタンCN7が配置されている。また、その下には、新たに「自分のウォレット」という文字が表示されおり、その横に自分の電子マネー口座残高(この例では「25,000円」)が表示されている。
スライドボタンCN7は、長円とこの長円内に丸を有する画像となっており、長円内左端に丸が位置する状態(この例では「OFF」)がデフォルトとなっており、限定ではなく例として、丸をタッチ操作またはスライド操作することで、長円内右端に丸が位置する状態(この例では「ON」)に変化するとともに、長円内の色が反転表示される。
図5-4は、図5-3のコード支払い画面(統合前)において、スライドボタンCN7が操作された場合に表示されるコード情報更新中画面の一例を示す図である。
図5-4が図5-3と異なるのは、キャンプ資金コード支払い領域2421内のスライドボタンCN7が「ON」の状態となっており、キャンプ資金コード支払い領域2421に、コード情報を更新中であることを示す更新中情報CJKが重畳表示されていることである。更新中情報CJKには、中央にコード情報更新中を示す2つの回転する矢印が表示されているとともに、その下に「コード情報更新中…」の文字が表示されている。
図5-5は、図5-4の支払いコード情報更新中画面が更新された場合に表示されるコード支払い画面(統合後)の一例を示す図である。
つまり、キャンプ資金コード支払い領域2421内の上部には、財布の画像および共通ウォレットの名称(キャンプ資金)と、加算を示す「+」と、財布の画像および自分のウォレットとの文字が表示されるとともに、共通ウォレット(キャンプ資金)と自分のウォレットとが加算されて統合された統合後の残高(この例では「26,000円」)が表示されている。
また、図5-5のキャンプ資金コード支払い領域2421内に表示される支払いコードは、アカウントが統合されたことによって、図5-3の支払いコードとは異なるコードとなっている。
端末20のユーザA.Aは、前述したように、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことでコード支払いを行う。サーバ10による決済処理が完了すると、図3-7と同様のコード支払い完了画面が表示される。
<処理>
図5-6~図5-7は、実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
端末Aの制御部21は、限定ではなく例として、端末AのユーザA.Aの電子マネー口座残高を、表示部24に加えて表示させると(A130)、ユーザA.Aの電子マネー口座残高と、共通ウォレット残高を合算する統合アカウントによる支払いを実行するか否かの選択機能を持つボタンを表示部24に加えて表示させる(A450a)。
端末Aの入出力部23に対するユーザ操作に基づいて、統合アカウントによる支払いを実行することが選択された場合(A450a:YES)、端末Aの制御部21は、アカウント統合依頼情報を通信I/F22によってサーバ10に送信する(A460)。
統合アカウントによる支払いを実行することが選択されない場合(A450a:NO)、端末Aの制御部21は、決済結果情報を通信I/F22によってサーバ10から受信し、図1-9のA180のステップを実行する。
通信I/F14によって端末Aからアカウント統合依頼情報を受信する場合(S470a:YES)、サーバ10の制御部11は、アカウント統合処理を実行する(S480)。
アカウント統合依頼情報を受信しない場合には(S470a:NO)、サーバ10の制御部11は、決済要求情報を店舗コードリーダ装置50から受信し、図1-9のS170aのステップを実行する。
アカウント統合処理では、サーバ10の制御部11は、統合アカウント管理データベース159に、ユニークな統合アカウントIDを持つ統合アカウント管理データのレコードを追加し、そのレコードの統合アカウントメンバーIDに、ユーザA.Aの支払いアプリケーションIDと、共通ウォレットの共通ウォレットIDを記憶させる。
そして、サーバ10の制御部11は、統合アカウントIDに紐づけられる統合アカウントの残高から支払いを認可する支払いトークンを生成する。以下では、このトークンを「統合アカウント支払いトークン」と称する。
ここで、統合アカウントの残高とは、統合アカウントメンバーIDに記憶されている支払いアプリケーションIDおよび共通ウォレットIDと関連する電子マネーの残高の合計額となる。
また、統合アカウント支払いトークンは、共通ウォレット支払いトークンと同様に、限定ではなく例として、所定桁数(限定ではなく例として12桁)の整数値によって識別される。統合アカウント支払いトークンは有効期限を持つトークンとしてもよいし、そうしなくてもよい。
アカウント統合処理によって統合アカウント支払いトークンが生成されると、サーバ10の制御部11は、統合アカウント支払いトークンを含むコード情報である統合アカウントコード情報を生成する。統合アカウントコード情報には、限定ではなく例として、統合アカウント支払いトークンの識別子を一次元コード(バーコード)や二次元コード(QRコード)としてエンコードした支払いコード(画像情報)を含む。
なお、統合アカウント支払いトークンが有効期限を持つ場合、統合アカウントコード情報には、その有効期限を含んでもよい。
そして、サーバ10の制御部11は、統合アカウントコード情報を、通信I/F14によって端末Aに送信する(S490a)。
なお、通信I/F14によって端末Aからアカウント統合依頼情報を受信しない場合(S470a:NO)、サーバ10の制御部11は、決済要求情報を通信I/F14によって店舗コードリーダ装置50から受信し、図1-9のS170aのステップを実行する。
通信I/F22によってサーバ10から統合アカウントコード情報を受信すると、端末Aの制御部21は、受信した統合アカウントコード情報に基づいて、支払いコードを表示部24に更新して表示させる(A470a)。
なお、統合アカウントコード情報に統合アカウント支払いトークンの識別子や有効期限を含む場合、端末Aの制御部21は、識別子や有効期限を更新して表示させてもよい。
店舗コードリーダ装置50の制御部51は、コードリーダ58を用いて、端末Aの表示部24に表示される支払いコードを読み取る(P140)。この場合、表示部24に表示される支払いコードは、統合アカウント支払いトークンと関連付けられているため、コードリーダ58の読み取り結果には、支払いトークンとして統合アカウント支払いトークンが含まれる。
店舗コードリーダ装置50の制御部51は、限定ではなく例として、店舗IDと、決済予定金額と、支払いトークン(この場合には統合アカウント支払いトークン)とを含む決済要求情報を通信I/F54によってサーバ10に送信する(P150)。
通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、サーバ10の制御部11は、統合アカウント決済処理を実行する(S500a)。
統合アカウント決済処理では、サーバ10の制御部11は、要求を受けた統合アカウント支払いトークンから統合アカウントIDを検索する。サーバ10の制御部11は、さらに統合アカウントIDに紐づけられる統合アカウントメンバーID(ここではユーザA.Aの支払いアプリケーションIDと、共通ウォレットの共通ウォレットID)に基づいて、統合アカウントメンバーIDで指し示されるユーザA.Aの電子マネー口座残高と共通ウォレット残高との合計額を用いて、統合アカウントに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する。
統合アカウントでの決済が成功する場合には、サーバ10の制御部11は、共通ウォレット残高を決済予定金額だけ減少させる。もし共通ウォレット残高が決済予定金額に満たない場合には、共通ウォレット残高を「0」まで減少させ、不足分をユーザA.Aの電子マネー口座残高から差し引く。
なお、統合アカウントでの決済が成功する場合には、サーバ10の制御部11は、ユーザA.Aの電子マネー口座残高を決済予定金額だけ減少させ、もしユーザA.Aの電子マネー口座残高が決済予定金額に満たない場合には、ユーザA.Aの電子マネー口座残高を「0」まで減少させ、不足分を共通ウォレット残高から差し引くようにしてもよいし、しなくてもよい。
次いで、サーバ10の制御部11は、限定ではなく例として、決済処理の成否と、決済処理後の統合アカウント残高とを含む決済結果情報を、通信I/F14によって店舗コードリーダ装置50に送信する(S510)。
また、サーバ10の制御部11は、限定ではなく例として、決済処理の成否と、決済処理後の統合アカウントを構成する電子マネー口座・共通ウォレット残高と、電子マネー口座・共通ウォレットでの支払い額とを含む統合アカウント決済結果情報を、通信I/F14によって端末Aに送信し(S520)、処理を終了する。
通信I/F54によってサーバ10から決済結果情報を受信すると、店舗コードリーダ装置50の制御部51は、決済結果情報を表示部53に表示させ(P160)、処理を終了する。
通信I/F22によってサーバ10から統合アカウント決済結果情報を受信すると、端末Aの制御部21は、統合アカウント決済結果情報を表示部24に表示させ(A480)、処理を終了する。
<統合アカウント支払いトークンとコード情報との関係>
前述したように、統合アカウント支払いトークンは、限定ではなく例として、統合アカウントIDに関連付けられる(紐付けられる)統合アカウントの残高から支払いを認可する支払いトークンである。つまり、統合アカウント支払いトークンには、統合アカウントIDが関連付けられている。そして、この統合アカウント支払いトークンがエンコードされたコード情報が統合アカウントコード情報である。
また、統合アカウントIDには、統合アカウントメンバーIDとして、限定ではなく例として、統合対象の支払いアプリケーションIDと、共通ウォレットの共通ウォレットIDとが関連付けられている。
これらのことから、統合アカウントコード情報(限定ではなく、第1コード情報の一例)には、統合対象の支払いアプリケーションID(限定ではなく、第2アカウントに関する情報の一例)と、共通ウォレットID(限定ではなく、共通アカウントに関する情報の一例)とが含まれる、または関連付けられていると言える。
<第5実施例の効果>
第5実施例は、端末20が、共通ウォレット残高に基づいて決済に関する処理を実行する。また、共通ウォレット残高には、自己の端末20のユーザのユーザアカウントから送金可能である構成を示している。
このような構成により、限定ではなく例として、第3実施例や第4実施例と同様の効果を得ることができる。
また、第5実施例は、端末20が、自己の端末20のユーザのユーザアカウント情報(限定ではなく、第2アカウント情報の一例)に対する入力に基づいて、このユーザアカウント情報と、共通アカウントとが関連付けられた統合アカウントコード情報(限定ではなく、第1コード情報の一例)を表示部24に表示する。そして、端末20は、統合アカウントコード情報が読み取られることに基づいて、決済に関する処理を実行する構成を示している。
このような構成により得られる効果の一例として、第2アカウント情報に対する入力に基づいて、第2アカウントと、共通アカウントとが関連付けられた第1コード情報を端末の表示領域に表示して決済に利用させることができる。また、第1コード情報が読み取られることに基づいて、簡単に決済を実現することができる。
また、第5実施例は、端末20が、共通アカウントが関連付けられた共通ウォレットコード情報(限定ではなく、第1コード情報の一例)と、自己の端末20のユーザのユーザアカウント情報(限定ではなく、第2アカウント情報の一例)とを表示部24に表示する。そして、端末20は、自己の端末20のユーザのユーザアカウント情報に対する入力に基づいて、このユーザアカウント情報と、共通アカウントとが関連付けられた統合アカウントコード情報(限定ではなく、第2コード情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントが関連付けられた第1コード情報を端末の表示領域に表示して決済に利用させることができるとともに、第2アカウント情報を端末のユーザに認識させることができる。また、第2アカウント情報に対する入力に基づいて、第2アカウントと、共通アカウントとが関連付けられた第2コード情報を端末の表示領域に表示して決済に利用させることができる。
また、第5実施例は、共通ウォレットコード情報(限定ではなく、第1コード情報の一例)と、統合アカウントコード情報(限定ではなく、第2コード情報の一例)とは、サーバ10(限定ではなく、第1決済に関する処理を実行するサーバの一例)から端末20に送信される構成を示している。
このような構成により得られる効果の一例として、第1コード情報と第2コード情報とを外部から簡単に取得することができる。
また、第5実施例は、端末20が、共通ウォレット残高(限定ではなく、共通アカウントに関連付けられた第1電子貨幣の金額の一例)の情報と、ユーザアカウントの電子マネー口座残高(限定ではなく、第2アカウントに関連付けられた第2電子貨幣の金額)とが加算された統合アカウントの残高の情報と、統合アカウントコード情報(限定ではなく、第2コード情報の一例)とを表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントに関連づけられた第1電子貨幣の金額と、第2アカウントに関連づけられた第2電子貨幣の金額との加算金額を端末のユーザに知らせることできる。また、第2コード情報を端末の表示領域に表示して決済に利用させることができる。
<第5変形例(1)>
第5実施例では、統合アカウントコード情報を受信すると、端末Aの制御部21は、統合アカウントコード情報を表示部24に更新して表示させることとしたが、支払いコードを更新しなくてもよい。
この場合には、限定ではなく例として、サーバ10の制御部11は、図5-6のS480において、図5-6のS100aで生成した共通ウォレット支払いトークンを削除(無効化)する。そして、図5-6のS100aで生成した共通ウォレット支払いトークンと同一の識別子を持つ統合アカウント支払いトークンを生成すればよい。
<第5変形例(2)>
第5実施例では、利用者提示型のコード決済に関して説明したが、これに限定されない。具体的には、店舗提示型のコード決済としてもよい。
<表示画面例>
図5-8は、図3-3のキャンプ資金支払い画面において「コードリーダ」のアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されるコードリーダ画面(統合前)の一例を示す図である。
図5-8では、タイトルバーの下に、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、コード読み取り領域CR1が表示され、ユーザに対する操作案内として「コードリーダ」が表示され、その下には、キャンプ資金コード支払い領域2423が表示されている。
キャンプ資金コード支払い領域2423の上部には、図3-4と同様に、角財布の画像および共通ウォレットの名称(キャンプ資金)とともに、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。その下には、「自分のウォレットと統合」の文字が表示され、その横にスライドボタンCN7が配置されている。また、その下に、「自分のウォレット」の文字が表示されているとともに、その横に残高(この例では「25,000円」)が表示されている。
図5-9は、図5-8のコードリーダ画面(統合前)においてスライドボタンCN7がタッチ操作された場合に表示される支払いコード情報更新中画面の一例を示す図である。
この例では、スライドボタンCN7がタッチ操作等されて「ON」の状態(長円内を丸が右端に移動して反転表示された状態)となっている。また、図5-4と同様に、更新中情報CJKがポップアップ形式で表示されている。
図5-10は、図5-9の支払いコード情報更新中画面が更新された場合に表示されるコードリーダ画面(統合後)の一例を示す図である。
この画面では、図5-9の画面においてポップアップ形式で表示されていた更新中情報CJKが、アカウントの統合(コード情報の更新)が完了することで消去されている。また、キャンプ資金コード支払い領域2423内の上部には、共通ウォレットと自分のウォレットとが統合されたことを示す情報として、角財布の画像およびキャンプ資金の文字と、がま口財布の画像および自分のウォレットの文字とを「+」で結合した情報が表示されている。また、この情報と関連付けて、ウォレットの統合によって合算された残高(この例では「26,000円」)が表示されている。
図5-10に示すコードリーダ画面で支払い店舗コードの読み取りが完了し、図3-11に示す支払い金額の入力が完了してサーバ10による決済処理が完了すると、図3-7と同様のコード支払い完了画面が表示される。
<処理>
図5-11~図5-12は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
端末Aの制御部21は、ユーザアカウント情報を表示部24に表示させると(A130)、ユーザA.Aの電子マネー口座残高と、共通ウォレット残高を合算する統合アカウントによる支払いを実行するか否かの選択機能を持つボタンを表示部24に加えて表示させる(A450b)。
端末Aの入出力部23に対するユーザ操作に基づいて、統合アカウントによる支払いを実行することが選択された場合(A450b:YES)、端末Aの制御部21は、A460のステップを実行する。
統合アカウントによる支払いを実行することが選択されない場合(A450b:NO)、端末Aの制御部21は、図1-11のA190のステップを実行する。
通信I/F14によって端末Aからアカウント統合依頼情報を受信する場合(S470b:YES)、サーバ10の制御部11は、アカウント統合処理を実行する(S480)。
アカウント統合依頼情報を受信しない場合には(S470b:NO)、サーバ10の制御部11は、決済要求情報を端末Aから受信し、図1-11のS170bのステップを実行する。
サーバ10の制御部11は、S480のステップを実行すると、生成された統合アカウント支払いトークンを含むコード読み取り用情報である統合アカウントコードリーダ情報を生成する。そして、サーバ10の制御部11は、統合アカウントコードリーダ情報を、通信I/F14によって端末Aに送信する(S490b)。
通信I/F22によってサーバ10から統合アカウントコードリーダ情報を受信すると、端末Aの制御部21は、受信された統合アカウントコードリーダ情報に基づいて、支払い店舗コードを読み取るためのコードリーダ画面を表示部24に表示させ、コードを読み取るためにカメラ27を起動させる(A470b)。そして端末Aの制御部21は、A190のステップを実行する。
通信I/F14によって端末Aから決済要求情報を受信すると、サーバ10の制御部11は、統合アカウント店舗提示型決済処理を実行する(S500b)。
統合アカウント店舗提示型決済処理は、統合アカウント決済処理と同様に実行することが可能であるため、詳細な説明は省略する。
そしてサーバ10の制御部11は、S520のステップを実行し、処理を終了する。
通信I/F22によってサーバ10から統合アカウント決済結果情報を受信すると、端末Aの制御部21は、A480のステップを実行し、処理を終了する。
本変形例は、端末20は、自己の端末20のユーザのユーザアカウント情報(限定ではなく、第2アカウント情報の一例)に対する入力に基づいて、統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第1コードリーダ情報の一例)を表示部24に表示する。そして、端末20は、コードリーダ画面が表示部24に表示された端末20によって支払い店舗コードを読み取ることに基づいて、決済に関する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第2アカウント情報に対する入力に基づいて、第1コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、第1コードリーダ情報が表示領域に表示された端末によってコード情報を読み取ることに基づいて、簡単に決済を実現することができる。
また、本変形例は、端末20が、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第1コードリーダ情報の一例)を表示部24に表示する。そして、端末20は、自己の端末20のユーザのユーザアカウント情報(限定ではなく、第2アカウント情報の一例)に対する入力に基づいて、統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第2コードリーダ情報の一例)を表示部24に表示する。そして、端末20は、コードリーダ画面が表示部24に表示された端末20によって支払い店舗コードを読み取ることに基づいて、決済に関する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第1コードリーダ情報を端末の表示領域に表示して決済に利用させることができるとともに、第2アカウント情報を端末のユーザに認識させることができる。また、第2アカウント情報に対する入力に基づいて、第2コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
また、本変形例は、端末20が、共通ウォレット残高(限定ではなく、共通アカウントに関連付けられた第1電子貨幣の金額の一例)の情報と、ユーザアカウントの電子マネー口座残高(限定ではなく、第2アカウントに関連付けられた第2電子貨幣の金額)とが加算された統合アカウントの残高の情報と、統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第2コードリーダ情報の一例)とを表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントに関連づけられた第1電子貨幣の金額と、第2アカウントに関連づけられた第2電子貨幣の金額との加算金額を端末のユーザに知らせることできる。また、第2コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
<第5変形例(3)>
第5実施例では、アカウント統合処理において複数のアカウントは単一のコードに紐づけられるとしていたが、そのようにしなくてもよい。限定ではなく例として、複数の支払いコードを端末に表示させ、それらのコードを用いて決済を行ってもよい。
なお、複数のコードを用いて決済を行う場合には、決済可能な最大金額は複数のコードに紐づけられる複数のアカウントの電子マネー口座残高の合計額とする。
以下では、このような支払い方法を「アカウント並列使用」と称する。
<表示画面例>
図5-13は、コード支払い画面の別例を示す図である。
図5-13では、図5-5とは異なり、バーコードで表される一次元の支払いコードと、同じくバーコードで表される一次元の支払いコードとの2つの支払いコードが上下に並べて表示されている。
上の支払いコードは、限定ではなく例として、ユーザA.Aの支払いアプリケーションIDに紐づけられる電子マネー口座残高から支払いを認可し、アカウント並列使用を選択するフラグを含む支払いトークン(後述する第1並列支払いトークン)が格納された第1並列コード情報である。
それに対し、下の支払いコードは、限定ではなく例として、共通ウォレットIDに紐づけられる共通ウォレット残高から支払いを認可し、アカウント並列使用を選択するフラグを含む支払いトークン(後述する第2並列支払いトークン)が格納された第2並列コード情報である。
なお、第1並列コード情報および第2並列コード情報の表示位置やその並びは、自由に設定変更することが可能である。
また、第1並列コード情報および第2並列コード情報を、上記のように一次元の支払いコードとするのではなく、QRコード等で表される二次元の支払いコードとすることもできる。
<処理>
図5-14~図5-15は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
端末Aの制御部21は、A130のステップを実行すると、ユーザA.Aの電子マネー口座と、共通ウォレットとを用いるアカウント並列使用による支払いを実行するか否かの選択機能を持つボタンを表示部24に加えて表示させる(A490)。
端末Aの入出力部23に対するユーザ操作に基づいて、アカウント並列使用による支払いを実行することが選択された場合(A490:YES)、端末Aの制御部21は、アカウント並列使用依頼情報を通信I/F22によってサーバ10に送信する(A500)。
アカウント並列使用による支払いを実行することが選択されない場合(A490:NO)、端末Aの制御部21は、決済結果情報を通信I/F22によってサーバ10から受信し、図1-9のA180のステップを実行する。
通信I/F14によって端末Aからアカウント並列使用依頼情報を受信する場合(S530:YES)、サーバ10の制御部11は、アカウント並列使用処理を実行する(S540)。
アカウント並列使用依頼情報を受信しない場合には(S530:NO)、サーバ10の制御部11は、決済要求情報を店舗コードリーダ装置50から受信し、図1-9のS170aのステップを実行する。
アカウント並列使用処理では、サーバ10の制御部11は、まずユーザA.Aの支払いアプリケーションIDに紐づけられる電子マネー口座残高から支払いを認可し、アカウント並列使用を選択するフラグを含む支払いトークンを生成する。以下では、この支払いトークンを「第1並列支払いトークン」とする。
また、サーバ10の制御部11は、共通ウォレットIDに紐づけられる共通ウォレット残高から支払いを認可し、アカウント並列使用を選択するフラグを含む支払いトークンを生成する。以下では、この支払いトークンを「第2並列支払いトークン」とする。
第1並列支払いトークン・第2並列支払いトークンは、限定ではなく例として、所定桁数(限定ではなく例として12桁)の整数値によって識別される。これらのトークンは有効期限を持つトークンとしてもよいし、そうしなくてもよい。
そして、サーバ10の制御部11は、第1並列支払いトークンを含むコード情報である第1並列コード情報と、第2並列支払いトークンを含むコード情報である第2並列コード情報とを生成する。
第1並列コード情報・第2並列コード情報には、限定ではなく例として、各々のトークンの識別子を一次元コード(バーコード)や二次元コード(QRコード)としてエンコードした支払いコード(画像情報)を含む。
なお、第1並列支払いトークン・第2並列支払いトークンが有効期限を持つ場合、これらのコード情報には、その有効期限を含んでもよい。
サーバ10の制御部11は、第1並列コード情報を通信I/F14によって端末Aに送信すると(S550)、第2並列コード情報を通信I/F14によって端末Aに送信する(S560)。
通信I/F22によって第1並列コード情報と第2並列コード情報とを受信すると、端末Aの制御部21は、第1並列コード情報と第2並列コード情報とを表示部24に並べて表示させる(A510)。
店舗コードリーダ装置50の制御部51は、コードリーダ58を用いて、端末Aの表示部24に表示される支払いコードをひとつ読み取る(P140)。そして、店舗コードリーダ装置50の制御部51は、限定ではなく例として、店舗IDと、決済予定金額と、支払いトークン(この場合には第1並列支払いトークンまたは第2並列支払いトークン)とを含む決済要求情報を通信I/F54によってサーバ10に送信する(P150)。
通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、サーバ10の制御部11は、受信した第1並列支払いトークンまたは第2並列支払いトークンからアカウント並列使用を選択するフラグを検出する。すると、サーバ10の制御部11は、アカウント並列使用処理で生成されたもう一方の支払いトークンを要求するために、他コード読み込み依頼情報を、通信I/F14によって店舗コードリーダ装置50に送信する(S570)。
通信I/F54によってサーバ10から他コード読み込み依頼情報を受信すると、店舗コードリーダ装置50の制御部51は、もう一方の支払いコードを読み取ることを促す画面を表示部53に表示させる(P170)。
店舗コードリーダ装置50の制御部51は、コードリーダ58を用いて、端末Aの表示部24に表示されるもう一方の支払いコードを読み取る(P180)。そして、店舗コードリーダ装置50の制御部51は、限定ではなく例として、店舗IDと、決済予定金額と、支払いトークン(この場合には第1並列支払いトークンまたは第2並列支払いトークンのうちP150で送信していないトークン)とを含む第2決済要求情報を通信I/F54によってサーバ10に送信する(P190)。
通信I/F14によって端末Aから第2決済要求情報を受信すると、サーバ10の制御部11は、アカウント並列決済処理を実行する(S580)。
アカウント並列決済処理は、第1並列支払いトークンに紐づけられるユーザA.Aの電子マネー口座と、第2並列支払いトークンに紐づけられる共通ウォレットとによる統合アカウントによる支払いとみなすことで、統合アカウント決済処理と同様に実行することが可能であるため、詳細な説明は省略する。
そして、サーバ10の制御部11は、S590、S600のステップを実行し、処理を終了する。また、通信I/F22によってサーバ10からアカウント並列決済結果情報を受信すると、端末Aの制御部21は、A520のステップを実行し、処理を終了する。
なお、S590、S600、A520の各ステップについては、アカウント並列決済処理と同様の統合アカウントによる支払いとみなすことで、S510、S520、A480の各ステップと同様に実行することが可能であるため、再度の説明は省略する。
<第5変形例(4)>
第5実施例では、統合アカウントによる支払い時に、共通ウォレット残高では足りず、ユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分を共通ウォレットの他のユーザ(限定ではなく例としてユーザB.B)へ請求することはなかったが、請求するようにしてもよいし、そのようにしなくてもよい。
図5-16は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図5-6、図5-7と同一の処理で実現可能であるため、ここでは説明を省略する。
端末Aの制御部21は、A480のステップを実行すると、立て替え分の精算を行うか否かの選択用画面を表示部24に表示させる(A530)
なお、A480のステップで用いられる統合アカウント決済結果情報において、ユーザA.Aの電子マネー口座からの支払い額が「0」である、または決済が失敗している場合には、精算を行う必要がない(A530:NO)ため、選択用画面を表示部24に表示させず、処理を終了してもよいし、しなくてもよい。また、ユーザA.Aの電子マネー口座からの支払い額が「0」より大きく、かつ決済が成功している場合には、選択用画面を表示部24に表示させず、自動的に精算を行う(A530:YES)ようにしてもよいし、しなくてもよい。
端末Aの入出力部23に対するユーザ操作に基づいて、精算を行うことが選択された場合(A530:YES)、端末Aの制御部21は、統合アカウント決済結果情報に含まれるユーザA.Aの電子マネー口座からの支払い額を含むユーザアカウント決済額請求情報を、通信I/F22によってサーバ10に送信する(A540)。
そして、通信I/F22によってサーバ10から精算結果情報を受信すると、端末Aの制御部21は、A340のステップを実行して、処理を終了する。
なお、精算を行わないことが選択された場合(A530:NO)、端末Aの制御部21は処理を終了する。
サーバ10の制御部11は、統合アカウント決済結果情報を送信し(S520)、通信I/F14によって端末Aからユーザアカウント決済額請求情報を受信すると(S610:YES)、ユーザアカウント決済額請求情報に含まれるユーザA.Aの電子マネー口座からの支払い額を決済残高不足額として、S290~S330までのステップを実行する。
ユーザアカウント決済額請求情報を受信しない場合には(S610:NO)、サーバ10の制御部11は、処理を終了する。
端末Bの制御部21は、支払い立替額請求情報を通信I/F22によってサーバ10から受信すると(B100:YES)、B110~B130のステップを実行する。支払い立替額請求情報を受信しない場合には(B100:NO)、端末Bの制御部21は、処理を終了する。
<第5変形例(5)>
第5実施例では、支払い開始時におけるユーザA.Aの電子マネー口座の残高と、共通ウォレット残高とを加算する金額を統合アカウントの残高(統合アカウントによる支払いが可能な金額)としていたが、それに限定されない。
限定ではなく例として、共通ウォレットとユーザA.Aの電子マネー口座とを統合する前に、ユーザA.Aによってあらかじめ登録される外部金融機関の口座から、ユーザA.Aの電子マネー口座へチャージ(送金)を行ってもよい。
<表示画面例>
図5-17は、図3-3のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されているコード支払い画面(統合前)の一例を示す図である。
図5-17は、図5-3とは異なり、キャンプ資金コード支払い領域2421内の「自分のウォレット」の横に表示されている残高(この例では「1000円」)の金額が異なるとともに、その横にチャージボタンCN5が表示されている。チャージボタンCN5がタッチ操作されると、図3-14に示すチャージ画面でチャージが行われる。
図5-18は、図3-14のチャージ画面においてチャージが完了した場合に表示されるコード支払い画面(チャージ後)の一例を示す図である。この例では、チャージが行われたことで、残高が「25,000円」となっている。
図5-19は、図5-18のコード支払い画面(統合前)においてスライドボタンCN7がタッチ操作され、アカウントが統合されたことに基づいて表示されるコード支払い画面(統合後)の一例を示す図である。
この例では、図5-19のキャンプ資金コード支払い領域2421の上部に、角財布の画像および共通ウォレットの名称(キャンプ資金)と、加算を示す「+」と、がま口財布の画像および自分のウォレットとの文字が表示されるとともに、共通アカウントと自分のアカウントとが統合されたことに基づく統合後の残高(この例では「26,000円」)が表示されている。
また、図5-19のキャンプ資金コード支払い領域2421内に表示される支払いコードは、共通アカウントと自分のアカウントとが統合されたことによって、図5-18の支払いコードとは異なるコードとなっている。
<処理>
図5-20は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
端末Aの制御部21は、A130のステップを実行すると、A210~A230のステップを実行する。次いで、端末Aの制御部21は、A450aのステップを実行する。
従って、この場合、サーバ10の制御部11は、S120のステップを実行すると、S190~S210のステップを実行する。次いで、サーバ10の制御部11は、A470aのステップを実行する。
なお、共通ウォレットとユーザA.Aの電子マネー口座とを統合した後に、ユーザA.Aの電子マネー口座へチャージを行ってもよい。この場合には、端末Aの制御部21は、A470aのステップを実行すると、A210~A230のステップを実行し、サーバ10から統合アカウント決済結果情報を受信すると、A480のステップを実行すればよい。また、サーバ10の制御部11は、S490aのステップを実行すると、S190~S210のステップを実行し、店舗コードリーダ装置50から決済要求情報を受信すると、S500aの処理を実行すればよい。
<第5変形例(6)>
第5実施例では、決済処理を実行する端末(限定ではなく例として端末A)のユーザ(限定ではなく例としてユーザA.A)の電子マネー口座と共通ウォレットを統合するか否かを選択するが、統合する電子マネー口座はこれに限定されない。限定ではなく例として、共通ウォレットを構成する他のメンバー(限定ではなく例としてユーザB.B)の電子マネー口座と統合を行えるようにしてもよい。
<表示画面例>
図5-21は、図3-3のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されるコード支払い画面(統合前)の一例を示す図である。
図5-21は、図5-3とは異なり、キャンプ資金コード支払い領域2421内に「ウォレット統合」の文字が表示されているが、図5-3のように自分のウォレットの統合に関する表示はなされていない。
図5-22は、図5-21のコード支払い画面(統合前)においてスライドボタンCN7が操作された場合に表示されるコード支払い画面(メンバー統合前)の一例を示す図である。
この例では、図5-18のキャンプ資金コード支払い領域2421内のスライドボタンCN7が「ON」とされた状態が示されている。また、その下には、ユーザに対する操作案内として、「ウォレット統合」の文字を含むウォレット統合案内領域WT1がコード支払い画面に重畳表示されている。
その下には、さらに、統合するユーザ(メンバー)を選択するためのウォレット統合メンバー選択領域WTM1がウォレット統合案内領域WT1に重畳表示されている。
ウォレット統合メンバー選択領域WTM1には、「どのメンバーのウォレットと統合しますか?」の説明文が上部に表示されており、その下には、チェックマークボタンCN2と関連付けて、アカウントの統合対象とするユーザの候補が表示されている。
具体的には、限定ではなく例として、ユーザの候補として、自分に関する情報(自分のアイコン画像、自分であることを示す「自分」、自分の電子マネー口座残高(この例では「25,000円」))が表示されている。また、その下には、他のユーザの候補として、ユーザB.Bに関する情報(ユーザB.Bのアイコン画像、ユーザ名「ユーザB.B」)が表示されている。
限定ではなく例として、ユーザB.Bに関連付けられたチェックマークボタンCN2がタッチ操作されると、ユーザB.Bのユーザアカウント(電子マネー口座)と共通ウォレットとが統合される。
図5-23は、図5-22のコード支払い画面(メンバー統合前)において、ユーザB.Bを選択するためのチェックマークボタンCN2がタッチ操作された場合にユーザB.Bの端末20の表示部24に表示されるおしらせ画面の一例を示す図である。
図5-23では、タイトルバーに、ユーザB.Bのアイコン画像およびそのユーザ名「B.B」が表示されている。また、タイトルバーの下には、「Payment App」の階層メニューにおける現在位置として「おしらせ」文字が表示されている。
「おしらせ」の文字の下には、おしらせを意味する「ベル」のアイコン画像が表示され、その横には、上段に「共通ウォレット:キャンプ資金」の文字が表示され、下段におしらせの概要(この例では「A.Aさんからウォレット統合依頼が届きました」)が表示されている。また、その下には、おしらせ日を示す「今日」の文字が表示されている。
おしらせ日の下には、キャンプ資金おしらせ表示領域2429が設けられている。
キャンプ資金おしらせ表示領域2429には、限定ではなく例として、上段に、共通ウォレットであることを示す角財布の画像とともに、その共通ウォレットの名称(この例では「キャンプ資金」)が表示されている。また、その横には、おしらせ日時として「2020年4月11日16時18分」が表示され、その下には、この共通ウォレットを共同で使用するユーザ(この例では「ユーザA.A」および「ユーザB.B」)のアイコン画像が表示されている。
また、キャンプ資金おしらせ表示領域2429には、限定ではなく例として、ユーザA.Aからの依頼項目として「ウォレット統合依頼」が表示され、その下に、依頼内容として「A.Aさんからウォレット統合依頼が届きました」の文が表示されている。
また、その下には、ウォレット統合依頼の詳細情報として、角財布の画像および共通ウォレットの名称(この例では「キャンプ資金」)とともに、このキャンプ資金の共通ウォレット残高(この例では「1,000円」)が表示されている。また、その下には、がま口財布の画像および「自分のウォレット」(この例ではユーザB.Bのウォレット)の文字とともに、自分のウォレットの残高(この例では「20,000円」)が表示されている。また、その下には、共通ウォレットメンバーを示すアイコン画像とともに「共通ウォレットのメンバー」の文字が表示され、その横に共通ウォレットメンバーの人数(この例では「2人」)が表示されている。
また、キャンプ資金おしらせ表示領域2429の下部には、ウォレット統合を許可するための許可ボタン242Pと、ウォレット統合を断るための拒否ボタン242Qとが表示されている。
図5-24は、図5-23のおしらせ画面において許可ボタン242Pがタッチ操作された場合にユーザA.Aの端末20の表示部24に表示されるコード情報更新画面の一例を示す図である。
このコード情報更新画面では、図5-22とは異なり、キャンプ資金コード支払い領域2421内の「ウォレット統合」の文字の下に、新たに、反転表示されたチェックマークボタンCN2とともに、ユーザB.Bのアイコン画像、そのユーザ名「B.B」、および、ユーザB.Bの電子マネー口座残高(この例では「20,000円」)が表示されている。また、キャンプ資金コード支払い領域2421には、コード情報を更新中であることを示す更新中情報CJKが重畳表示されている。
図5-25は、図5-24のコード情報更新画面の後に、ユーザA.Aの端末20の表示部24に表示されるコード支払い画面(メンバー統合後)の一例を示す図である。
このコード支払い画面では、共通アカウントにユーザB.Bのユーザアカウントが統合された結果が表示されている。具体的には、キャンプ資金コード支払い領域2421内の上部には、角財布の画像および共通ウォレットの名称(キャンプ資金)と、加算を示す「+」と、がま口財布の画像および「B.Bさんのウォレット」とが表示されている。また、アカウント統合後の残高として、共通ウォレット残高とユーザB.Bの電子マネー口座残高とを加算した金額(この例では「21,000円」)が表示されている。
また、アカウントの統合によって、図5-25のキャンプ資金コード支払い領域2421内に表示される支払いコードは、図5-21に示される支払いコードとは異なるコードとなっている。
図5-26は、図5-23のおしらせ画面においてユーザB.Bによって許可ボタン242Pと拒否ボタン242Qとのうちのいずれかが操作されるまでの間にユーザA.Aの端末20の表示部24に表示されるコード支払い画面(統合申請中)の一例を示す図である。
この例では、キャンプ資金コード支払い領域2421において、「ウォレット統合」の文字と関連付けられたスライドボタンCN7が「ON」の状態とされている。
また、その下には、灰色で反転表示されたチェックマークボタンCN2とともに、ユーザB.Bのアイコン画像およびユーザ名「B.B」が表示されている。また、その横には、「申請中」の文字を含む矩形の枠が表示されている。このような表示を行うことで、ユーザA.Aは、アカウントの統合をユーザB.Bに申請中であり、ユーザB.Bによって未だ申請が許可されていないこと(または申請が拒否されていないこと)を知ることができる。
図5-27は、図5-21のコード支払い画面の別例を示す図である。
図5-27が図5-21と異なるのは、「ウォレット統合」の文字の下に、新たにチェックマークボタンCN2とともに、「共通ウォレットへチャージ」の文字が表示されていることである。この例では、チェックマークボタンCN2をタッチ操作することで、ユーザA.Aが共通ウォレットへチャージすることが可能となる。
<処理>
図5-28は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
端末Aの制御部21は、A130のステップを実行すると、限定ではなく例として、共通ウォレットメンバーである他のユーザ(限定ではなく例としてユーザB.B)の電子マネー口座と、共通アカウントとを統合し、支払いを可能にすることを他のユーザ(限定ではなく例としてユーザB.B)へ依頼するか否かの選択機能を持つボタンを表示部24に加えて表示させる(A550)。
端末Aの入出力部23に対するユーザ操作に基づいて、ユーザB.Bの電子マネー口座と共通ウォレットとを統合することを依頼することが選択された場合(A550:YES)、端末Aの制御部21は、アカウント統合要請情報を、通信I/F22によってサーバ10に送信する(A560)。
ユーザB.Bの電子マネー口座と共通ウォレットとを統合することを依頼することが選択されない場合には(A550:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信し、図1-9のA180のステップを実行する。
通信I/F14によって端末Aからアカウント統合要請情報を受信する場合(S620:YES)、サーバ10の制御部11は、アカウント統合確認情報を、通信I/F14によって端末Bに送信する(S630)。
アカウント統合要請情報を受信しない場合には(S620:NO)、サーバ10の制御部11は、決済要求情報を通信I/F14によって店舗コードリーダ装置50から受信し、図1-9のS170aのステップを実行する。
通信I/F22によってサーバ10からアカウント統合確認情報を受信する場合(B220:YES)、端末Bの制御部21は、アカウント統合確認情報に基づいて、ユーザB.Bの電子マネー口座と共通ウォレットとを統合することを認可するか否かの選択用画面を表示部24に表示させる(B230)。アカウント統合確認情報を受信しない場合には(B220:NO)、端末Bの制御部21は、処理を終了する。
端末Bの入出力部23に対するユーザ操作に基づいて、アカウントの統合を認可することが選択された場合(B230:YES)、端末Bの制御部21は、アカウント統合認可情報を通信I/F22によってサーバ10に送信し(B240)、処理を終了する。認可しないことが選択された場合(B230:NO)、端末Bの制御部21は、処理を終了する。
通信I/F14によって端末Bからアカウント統合認可情報を受信する場合(S640:YES)、サーバ10の制御部11は、ユーザB.Bの電子マネー口座と、共通ウォレットとを統合するアカウント統合処理を実行し(S650)、S490aのステップを実行する。
なお、アカウント統合処理については、図5-6のS480のステップと同様に処理を行うことが可能であるため、処理の詳細については説明を省略する。
アカウント統合認可情報を受信しない場合には(S640:NO)、サーバ10の制御部11は、決済要求情報を通信I/F14によって店舗コードリーダ装置50から受信し、図1-9のS170aのステップを実行する。
次いで、サーバ10の制御部11は、ユーザB.Bの電子マネー口座残高を含むユーザアカウント情報を、通信I/F14によって端末Aに送信する(S660)。そして、サーバ10の制御部11は、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、図5-7のS500aのステップを実行する。
通信I/F22によってサーバ10から統合アカウントコード情報を受信する場合(A570)、端末Aの制御部21は、A470aのステップを実行する。次いで、通信I/F22によってサーバ10からユーザアカウント情報を受信すると、端末Aの制御部21は、受信されたユーザアカウント情報に基づき、限定ではなく例として、ユーザB.Bの電子マネー口座残高を表示部24に加えて表示させる(A580)。そして、端末Aの制御部21は、通信I/F22によってサーバ10から統合アカウント決済結果情報を受信すると、図5-7のA480のステップを実行する。
統合アカウントコード情報を受信しない場合には(A570:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から決済結果情報を受信すると、図1-9のA180のステップを実行する。
<第5変形例(7)>
第5変形例(6)では、共通ウォレットと、共通ウォレットの他のユーザ(限定ではなく例としてユーザB.B)の電子マネー口座との統合アカウントによる支払い時に、共通ウォレット残高では足りず、他のユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分が支払いを行った端末AのユーザA.Aへ請求されることはなかったが、請求されるようにしてもよいし、そのようにしなくてもよい。
図5-29は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については限定ではなく例として図5-28と、処理の後半については限定ではなく例として図4-21と、それぞれ同一とすることができるため、ここでは説明を省略する。
端末Aの制御部21は、図5-28のA580のステップを実行すると、通信I/F22によってサーバ10から統合アカウント決済結果情報を受信し、A480のステップを実行する。
次いで、端末Aの制御部21は、立て替え分の精算を行うか否かの選択用画面を表示部24に表示させる(A590)
なお、A480のステップで用いられる統合アカウント決済結果情報において、統合を依頼したユーザB.Bの電子マネー口座からの支払い額が「0」である、または決済が失敗している場合には、精算を行う必要がない(A590:NO)ため、選択用画面を表示部24に表示させず、処理を終了してもよいし、しなくてもよい。また、ユーザB.Bの電子マネー口座からの支払い額が「0」より大きく、かつ決済が成功している場合には、選択用画面を表示部24に表示させず、自動的に精算を行う(A590:YES)ようにしてもよいし、しなくてもよい。
端末Aの入出力部23に対するユーザ操作に基づいて、精算を行うことが選択された場合(A590:YES)、端末Aの制御部21は、統合アカウント決済結果情報に含まれるユーザB.Bの電子マネー口座からの支払い額を含むユーザアカウント決済額請求情報を、通信I/F22によってサーバ10に送信する(A600)。
そして、端末Aの制御部21は、図4-21のA400以降のステップを実行する。
一方、精算を行わないことが選択された場合(A590:NO)、端末Aの制御部21は処理を終了する。
サーバ10の制御部11は、統合アカウント決済結果情報を送信し(S520)、通信I/F14によって端末Aからユーザアカウント決済額請求情報を受信すると(S670:YES)、ユーザアカウント決済額請求情報に含まれるユーザB.Bの電子マネー口座からの支払い額を決済残高不足額として、S400以降のステップを実行する。
ユーザアカウント決済額請求情報を受信しない場合には(S670:NO)、サーバ10の制御部11は、処理を終了する。
通信I/F22によってサーバ10から決済残高不足額を受信すると(B180:YES)、端末Bの制御部21は、図4-21のB190以降のステップを実行する。決済残高不足額を受信しない場合には(B180:NO)、端末Bの制御部21は、処理を終了する。
<第5変形例(8)>
端末20が、共通ウォレットコード情報、または共通ウォレットコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面を表示部24に表示する。そして、端末20が、自己の端末20のユーザのユーザアカウント情報に対する入力に基づいて、このユーザアカウント情報と関連付けられた支払いコード、または支払い店舗コードを読み取るためのコードリーダ画面を表示部24に表示するようにすることができる。
また、この場合、共通ウォレット残高と、自己の端末20のユーザのユーザアカウントの電子マネー口座残高とのうち、限定ではなく例として、共通ウォレット残高から優先的に決済が行われるようにすることができる。
本変形例は、端末20が、共通ウォレットコード情報(限定ではなく、共通アカウントと関連付けられた第1コード情報の一例)、または共通ウォレットコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第1コードリーダ情報の一例)を表示部24に表示する。そして、端末20が、自己の端末20のユーザのユーザアカウント情報(限定ではなく、第2アカウント情報の一例)に対する入力に基づいて、ユーザアカウント情報が関連付けられた支払いコード(限定ではなく、第2アカウントと関連付けられた第3コード情報の一例)、またはユーザアカウント情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第3コードリーダ情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントと関連付けられた第1コード情報、または第1コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、第2アカウント情報に対する入力に基づいて、第2アカウントと関連付けられた第3コード情報、または第3コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
また、本変形例は、決済は、共通ウォレット残高と、自己の端末20のユーザのユーザアカウントの電子マネー口座残高とのうち、共通ウォレット残高(限定ではなく、共通アカウントの残高の一例)から優先的に支払いが行われる構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高から優先的に支払いが行われるため、第2アカウントを付随的なアカウントとすることができる。
<第5変形例(9)>
上記の示した各種の表示画面やユーザインタフェース(UI)はあくまでも一例に過ぎず、これらに限定されない。
<表示画面例>
図5-30は、図3-1のサブメニューにおいて「自分のウォレット」(図示せず)がタッチ操作され、自分のウォレット画面において「コード支払い」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されるコード支払い画面(統合前)の一例を示す図である。このコード支払い画面は、自分のアカウントをベースとして、共通アカウントを統合先として選択するための画面の一例である。
図5-30では、タイトルバーの下に、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「コード支払い」が表示されている。また、その下に設けられたコード支払い領域2451には、がま口財布の画像および「自分のウォレット」の文字とともに、自分の電子マネー口座残高(この例では「25,000円」)が表示されている。
その下には、「ウォレット統合」の文字が表示されるとともに、その横に、スライドボタンCN7が配置されている。このスライドボタンCN7を操作することで、自分のユーザアカウントに統合する共通アカウントを選択することが可能となる。
図5-31は、図5-30のコード支払い画面(統合前)においてスライドボタンCN7がタッチ操作された場合に表示されるコード支払い画面(共通ウォレット統合前)の一例を示す図である。
図5-31では、図5-30のコード支払い領域2451内のスライドボタンCN7が「ON」の状態とされている。また、その下には、ユーザに対する操作案内として、「ウォレット統合」の文字を含むウォレット統合案内領域WT2がコード支払い画面に重畳表示されている。その下には、さらに、統合する共通ウォレットを選択するための共通ウォレット統合選択領域WTM2がウォレット統合案内領域WT2に重畳表示されている。
共通ウォレット統合選択領域WTM2では、上部に「統合する共通ウォレットを選んでください」の説明文が表示されており、その下には、チェックマークボタンCN2とともに、キャンプ資金用の共通ウォレットであることを示す「キャンプ資金」の文字が表示され、その横に、その共通ウォレット残高(この例では「1,000円」)が表示されている。
また、その下には、チェックマークボタンCN2とともに、韓国旅行用の共通ウォレットであることを示す「韓国旅行」の文字が表示され、その横に、その共通ウォレット残高
(この例では「90,000円」)が表示されている。
図5-32は、図5-31のコード支払い画面(共通ウォレット統合前)において韓国旅行用の共通ウォレットに関連付けられたチェックマークボタンCN2がタッチ操作された場合に表示されるコード情報更新画面の一例を示す図である。
図5-32が図5-31と異なるのは、コード支払い領域2451内の「ウォレット統合」の文字の下に、新たに、反転表示されたチェックマークボタンCN2とともに、「韓国旅行」の文字が表示されていることと、その横に、残高(この例では「90,000円」)が表示されていることと、キャンプ資金コード支払い領域2421に、コード情報を更新中であることを示す更新中情報CJKが重畳表示されていることである。
図5-33は、図5-32のコード情報更新画面の後に表示されるコード支払い画面(共通ウォレット統合後)の一例を示す図である。
このコード支払い画面では、コード支払い領域2451内の上部に、がま口財布の画像および自分のウォレットと、加算を示す「+」と、角財布の画像および「韓国旅行」との文字が表示されるとともに、自分のユーザアカウントと共通アカウント(韓国旅行)とが統合された結果としての残高(この例では「115,000円」)が表示されている。また、アカウントが統合されたことにより、コード支払い領域2451内に表示される支払いコードは、図5-30の支払いコードとは異なるコードとなっている。
<第6実施例>
第6実施例は、端末20(限定ではなく例として端末A)が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高から実行するが、支払い時に共通ウォレット残高が不足している場合に、ユーザA.Aの電子マネー口座と共通ウォレットとの統合アカウントに基づいて支払いを実行することで、共通ウォレットの残高不足を補う実施例である。
第6実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<処理>
図6-1~図6-2は、実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
店舗コードリーダ装置50の制御部51は、店舗決済処理としてP100~P160のステップを実行する。
サーバ10の制御部11は、S120のステップを実行すると、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信し、S250aのステップを実行する。また、S270aのステップを実行すると、S470aのステップを実行する。
端末Aの制御部21は、A130のステップを実行すると、A270aのステップを実行する。また、A290のステップを実行すると、A450aのステップを実行する。
図6-2は、以後の説明に要するため便宜上記述するフローであり、各装置のステップは図5-7と同一であるため説明を省略する。
なお、店舗コードリーダ装置50がP130を実行後、図6-2のフローに処理を移すか、図4-5のフローに処理を移すかについて、P130の実行時には店舗コードリーダ装置50は判断を行うことができないため、サーバ10の制御部11の処理によって分岐を行う。図6-2と図4-5とにおいては、店舗コードリーダ装置50の制御部51が実行する処理は同一であるため、サーバ10の分岐結果から直接的な影響は受けない。
<第6実施例の効果>
第6実施例は、端末20は、決済予定金額(限定ではなく、第1決済の金額の一例)と、共通ウォレット残高(限定ではなく、第1アカウントの残高)とに基づき、共通ウォレット残高が不足している場合に、共通アカウント(限定ではなく、第1アカウントの一例)と、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)とに基づいて、決済に関する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第1アカウントの残高が不足している場合であっても、第1アカウントと第2アカウントとに基づいて、適切に決済を行うことができる。
<第6変形例(1)>
第6実施例では、利用者提示型のコード決済に関して説明したが、これに限定されない。具体的には、店舗提示型のコード決済としてもよい。
図6-3は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
端末Aの制御部21は、A130のステップを実行すると、A300のステップを実行する。また、A290のステップを実行すると、A450bのステップを実行する。
サーバ10の制御部11は、S120のステップを実行し、通信I/F14によって端末Aから決済要求情報を受信すると、S250bのステップを実行する。また、S270bのステップを実行すると、S470bのステップを実行する。
<第6変形例(2)>
第6実施例では、アカウント統合処理を用いて複数のアカウントを単一のコードに紐づけていたが、そのようにしなくてもよい。限定ではなく例として、複数のアカウントをアカウント並列使用することにより支払いを行ってもよい。
図6-4~図6-5は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
店舗コードリーダ装置50の制御部51は店舗決済処理としてP100~P160のステップを実行する。
サーバ10の制御部11は、S120のステップを実行すると、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信し、S250aのステップを実行する。また、S270aのステップを実行すると、S530のステップを実行する。
端末Aの制御部21は、A130のステップを実行すると、A270aのステップを実行する。また、A290のステップを実行すると、A490のステップを実行する。
図6-5における各装置のステップは、図5-15と同一であるため説明を省略する。
なお、店舗コードリーダ装置50がP130を実行後、図6-5のフローに処理を移すか、図4-5のフローに処理を移すかについて、P130の実行時には店舗コードリーダ装置50は判断を行うことができないため、サーバ10の制御部11の処理によって分岐を行う。
<第6変形例(3)>
第6実施例では、支払い開始時におけるユーザA.Aの電子マネー口座の残高と、共通ウォレット残高とを加算する金額を統合アカウントの残高(統合アカウントによる支払いが可能な金額)としていたが、それに限定されない。
限定ではなく例として、ユーザA.Aの電子マネー口座の残高と、共通ウォレット残高とを合算しても支払い額に満たない場合には、共通ウォレットとユーザA.Aの電子マネー口座とを統合する前に、ユーザA.Aによってあらかじめ登録される外部金融機関の口座から、ユーザA.Aの電子マネー口座へチャージ(送金)を行ってもよい。
図6-6は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図6-2もしくは図4-5と同一とすることができるため、ここでは説明を省略する。
端末Aの制御部21は、A290のステップを実行すると、A350のステップを実行し、必要に応じてA210~A230のステップを実行する。その後、端末Aの制御部21は、A450a以降のステップを実行する。
なお、端末Aの制御部21は、A350のステップを実行せずに、必ずA210~A230のステップを実行するようにしてもよいし、そのようにしなくてもよい。
サーバ10の制御部11は、S270aのステップを実行すると、S190~S210のステップを実行し、S470a以降のステップを実行する。
店舗コードリーダ装置50の制御部51は、P130のステップを実行すると、P140以降のステップを実行する。
<第6変形例(4)>
第6実施例では、統合アカウントによる支払い時に、共通ウォレット残高では足りず、ユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分を共通ウォレットの他のユーザ(限定ではなく例としてユーザB.B)へ請求することはなかったが、請求するようにしてもよいし、そのようにしなくてもよい。
図6-7は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
端末Aの制御部21は、A480のステップを実行すると、A530~A340のステップを実行し、処理を終了する。
端末Bの制御部21は、B100~B130のステップを実行し、処理を終了する。
サーバ10の制御部11は、S520のステップを実行すると、S610~S330のステップを実行し、処理を終了する。
店舗コードリーダ装置50の制御部51は、P160のステップを実行すると、処理を終了する。
各ステップについては、図5-16と同様に実現することが可能であるため、詳細については説明を省略する。
なお、図6-6の処理の後半から、図6-7のフローへ繋げることで、ユーザA.Aの立て替え分を共通ウォレットの他のユーザ(限定ではなく例としてユーザB.B)へ請求するようにしてもよいし、そうしなくてもよい。
<第6変形例(5)>
第6実施例では、共通ウォレットでの残高不足により支払いが行われなかった場合には、決済処理を実行する端末(限定ではなく例として端末A)のユーザ(限定ではなく例としてユーザA.A)の電子マネー口座と共通ウォレットを統合するか否かを選択するが、統合する電子マネー口座はこれに限定されない。限定ではなく例として、共通ウォレットを構成する他のメンバー(限定ではなく例としてユーザB.B)の電子マネー口座と統合を行えるようにしてもよい。
図6-8は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図6-2と同一とすることができるため、ここでは説明を省略する。
端末Aの制御部21は、A290のステップを実行すると、A550~A580のステップを実行する。通信I/F22によってサーバ10から統合アカウント決済結果情報を受信すると、端末Aの制御部11は、A480以降のステップを実行する。
端末Bの制御部21は、B220~B240のステップを実行し、処理を終了する。
サーバ10の制御部11は、S270aのステップを実行すると、S620~S660のステップを実行する。通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、サーバ10の制御部11は、S500a以降のステップを実行する。
店舗コードリーダ装置50の制御部51は、P130のステップを実行すると、P140以降のステップを実行する。
各ステップについては、図5-28と同様に実現することが可能であるため、詳細については説明を省略する。
<第6変形例(6)>
第6変形例(5)では、他のユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分が支払いを行った端末AのユーザA.Aへ請求されることはなかったが、請求されるようにしてもよいし、そのようにしなくてもよい。
図6-9は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図6-8と、処理の後半については、限定ではなく例として図4-21と、それぞれ同一とすることができるため、ここでは説明を省略する。
端末Aの制御部21は、A580のステップを実行すると、通信I/F22によってサーバ10から統合アカウント決済結果情報を受信し、A480~A600のステップを実行する。A600:YESの場合には、端末Aの制御部21は、A400以降のステップを実行する。
端末Bの制御部21は、B180のステップを実行する。B180:YESの場合には、B190以降のステップを実行する。
サーバ10の制御部11は、S660のステップを実行すると、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信し、S500a~S400のステップを実行する。S400のステップが実行される場合、サーバ10の制御部11は、S410以降のステップを実行する。
店舗コードリーダ装置50の制御部51は、P130のステップを実行すると、P140~P160の処理を実行する。
各ステップについては、図5-29と同様に実現することが可能であるため、詳細については説明を省略する。
<第7実施例>
第7実施例は、端末20(限定ではなく例として端末A)が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高と端末20のユーザ(限定ではなく例としてユーザA.A)の電子マネー口座残高とを合算する統合アカウントの電子マネー残高から実行する実施例である。第5実施例とは異なり、本実施例では、統合アカウントを用いる支払いから処理を開始する。
第7実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<処理>
図7-1は、実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
なお、処理の後半については、限定ではなく例として図5-7と同様に実行することが可能であるため、詳細については説明を省略する。
まず、端末Aの制御部21は、限定ではなく例として、端末Aから利用可能な共通ウォレットと、自身の電子マネー口座とを統合した統合アカウントを選択する情報を、通信I/F22によってサーバ10に送信する(A610)。
統合アカウントを選択する情報は、限定ではなく例として、共通ウォレットIDと、ユーザA.Aの支払いアプリケーションIDとを含む。端末Aの制御部21は、選択可能な共通ウォレットIDを、本ステップにおいて通信I/F22によってサーバ10から受信してもよいし、記憶部28にあらかじめ記憶されたものを呼び出してもよい。また、端末Aの制御部21は、支払いアプリケーションIDではなく、サーバ10の制御部11において支払いアプリケーションIDを特定可能な端末電話番号を送信してもよい。
通信I/F14によって端末Aから統合アカウントを選択する情報を受信すると、サーバ10の制御部11は、統合アカウントを選択する情報に基づいて、S480のステップを実行する。
なお、既に統合アカウントが作成されている場合、端末Aの制御部21は、統合アカウントを選択する情報として、その統合アカウントIDを含む統合アカウントを選択する情報を、通信I/F22によってサーバ10に送信してもよい。端末Aの制御部21は、選択可能な統合アカウントIDを、本ステップにおいて通信I/F22によってサーバ10から受信してもよいし、記憶部28にあらかじめ記憶されたものを呼び出してもよい。この場合、サーバ10の制御部11は、S480のステップにおいて、アカウント統合処理において、統合アカウント管理データのレコード追加を実行しなくてもよい。
そして、サーバ10の制御部11は、S490a~S120の各ステップを実行し、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、S500a以降のステップを実行する。
端末Aの制御部21は、通信I/F22によってサーバ10から統合アカウントコード情報を受信すると、A470a~A130の各ステップを実行し、通信I/F14によって統合アカウント決済結果情報を受信すると、A480以降のステップを実行する。
なお、A610のステップにおいて、端末Aの制御部21は、限定ではなく例として、端末Aから利用可能な共通ウォレットと、自身以外の共通ウォレットメンバーの電子マネー口座とを統合した統合アカウントを選択する情報を、通信I/F22によってサーバ10に送信するようにしてもよいし、そのようにしなくてもよい。この場合、統合アカウントを選択する情報は、限定ではなく例として、共通ウォレットIDと、ユーザB.Bの支払いアプリケーションIDとを含む。
<第7実施例の効果>
第7実施例は、端末20が、自己の端末20のユーザが決済可能な第1アカウントと、自己の端末20のユーザのユーザアカウント(限定ではなく、第1アカウントとは異なる第2アカウントの一例)とが関連付けられた統合アカウントコード情報(限定ではなく、第1コード情報の一例)を表示部24に表示する。そして、端末20は、統合アカウントコード情報が読み取られることに基づいて、決済に関する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第1アカウントと、第1アカウントとは異なる第2アカウントとが関連付けられた第1コード情報、を端末の表示領域に表示して決済に利用させることができる。また、第1コード情報が読み取られることに基づいて、決済を簡単に実現することができる。
また、第7実施例は、第1アカウントは、共通アカウント(限定ではなく、少なくとも端末のユーザと、端末のユーザとは異なる第1ユーザとが決済可能な共通アカウントの一例)である構成を示している。
このような構成により得られる効果の一例として、共通アカウントと、共通アカウントとは異なる第2アカウントとが関連付けられた第1コード情報を端末の表示領域に表示して決済に利用させることができる。また、第1コード情報が読み取られることに基づいて、決済を簡単に実現することができる。
また、第7実施例は、統合アカウントコード情報(限定ではなく、第1コード情報の一例)は、一つのコード(限定ではなく、一つのコード情報の一例)である構成を示している。
このような構成により得られる効果の一例として、複数のコード情報ではなく、一つのコード情報によって簡単に決済を実現することができる。
また、第7実施例は、統合アカウントコード情報(限定ではなく、第1コード情報の一例)は、自己の端末20のユーザの支払いアプリケーションID、または異なる端末20のユーザの支払いアプリケーションID(限定ではなく、第2アカウントに関する情報の一例)と、共通ウォレットID(限定ではなく、共通アカウントに関する情報の一例)とを含む構成を示している。
このような構成により得られる効果の一例として、上記と相まって、第2アカウントに関する情報と、共通アカウントに関する情報とを一つのコード情報に含めることができるため、効率的である。
また、第7実施例は、端末20が、自己の端末20のユーザ(限定ではなく例としてユーザA.A)とは異なる端末20のユーザ(限定ではなく例としてユーザB.B)の支払いアプリケーションID(限定ではなく、第3アカウントの一例)を含む統合アカウントを選択する情報(限定ではなく、第3アカウントに関する第3アカウント情報の一例)と、自己の端末20のユーザの支払いアプリケーションID(限定ではなく、第2アカウントの一例)を含む統合アカウントを選択する情報(限定ではなく、第2アカウントに関する第2アカウント情報の一例)とを表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、第2アカウント情報に加えて、第2アカウントとは異なる第3アカウントに関する第3アカウント情報を端末のユーザに知らせることができる。
また、第7実施例は、端末20が、自己の端末20のユーザ(限定ではなく例としてユーザA.A)の支払いアプリケーションID(限定ではなく、第2アカウントの一例)を含む統合アカウントを選択する情報(限定ではなく、第2アカウントに関する第2アカウント情報の一例)と、異なる端末20のユーザ(限定ではなく例としてユーザB.B)の支払いアプリケーションID(限定ではなく、第3アカウントの一例)を含む統合アカウントを選択する情報(限定ではなく、第3アカウントに関する第3アカウント情報の一例)とを表示部24に表示する。そして、端末20は、表示された、自己の端末20のユーザ(限定ではなく例としてユーザA.A)の支払いアプリケーションID(限定ではなく、第2アカウントの一例)を含む統合アカウントを選択する情報に対する入力に基づいて、共通アカウントと、自己の端末20のユーザのユーザアカウントとが統合された統合アカウントコード情報(限定ではなく、第1コード情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、第2アカウントに関する第2アカウント情報とともに、第2アカウントとは異なる第3アカウントに関する第3アカウント情報を端末のユーザに認識させることができる。また、第2アカウント情報に対する端末のユーザによる入力に基づいて、第1コード情報、または第1コードリーダ情報を表示領域に表示して決済に利用させることができる。
また、第7実施例は、第2アカウントは、自己の端末20のユーザのアカウント(限定ではなく、端末のユーザのアカウントの一例)である構成を示している。
このような構成により得られる効果の一例として、端末のユーザのアカウントを第2アカウントとして決済を実現することができる。
また、第7実施例は、サーバ10が、一の端末20のユーザが決済可能な第1アカウントと、この端末20のユーザのユーザアカウント(限定ではなく、第1アカウントとは異なる第2アカウントの一例)とが関連付けられた統合アカウントコード情報(限定ではなく、第1コード情報の一例)をこの端末20に通信I/F14によって送信する。また、サーバ10は、通信I/F14によって店舗コードリーダ装置50から決済要求情報(限定ではなく、第1コード情報と、商品情報との一例)を受信する。そして、サーバ10は、受信された決済要求情報に基づいて、決済処理(限定ではなく、第1決済に関する処理の一例)を制御部11によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第1アカウントと、第1アカウントとは異なる第2アカウントとが関連付けられた第1コード情報を端末のユーザに取得させることができる。
<第7変形例(1)>
第7実施例では、利用者提示型のコード決済に関して説明したが、これに限定されない。具体的には、店舗提示型のコード決済としてもよい。
図7-2は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図5-12と同様に実行することが可能であるため、詳細については説明を省略する。
端末Aの制御部21は、A610~A130の各ステップを実行すると、A190以降のステップを実行する。
サーバ10の制御部11は、S480~S120の各ステップを実行すると、通信I/F14によって端末Aから決済要求情報を受信し、S500b以降のステップを実行する。
本変形例は、端末20が、自己の端末20のユーザが決済可能な第1アカウントと、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)とが関連付けられた統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第1コードリーダ情報の一例)を表示部24に表示する。そして、端末20は、統合アカウントコードリーダ情報に基づくコードリーダ画面が表示部24に表示された端末20によって支払い店舗コードが読み取られることに基づいて、決済に関する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第1アカウントと、第1アカウントとは異なる第2アカウントとが関連付けられた第1コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、第1コードリーダ情報が表示された端末によってコード情報が読み取られることに基づいて、決済を簡単に実現することができる。
<第7変形例(2)>
アカウント統合処理を用いて複数のアカウントを単一のコードに紐づけていたが、そのようにしなくてもよい。限定ではなく例として、複数のアカウントをアカウント並列使用することにより支払いを行ってもよい。
図7-3は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図5-15と同様に実行することが可能であるため、詳細については説明を省略する。
まず、端末Aの制御部21は、限定ではなく例として、端末Aから利用可能な共通ウォレットと、自身の電子マネー口座とをアカウント並列使用することを選択する情報を、通信I/F22によってサーバ10に送信する(A620)。
アカウント並列使用することを選択する情報には、限定ではなく例として、共通ウォレットIDと、ユーザA.Aの支払いアプリケーションIDとを含む。
通信I/F14によって端末Aからアカウント並列使用することを選択する情報を受信すると、サーバ10の制御部11は、アカウント並列使用することを選択する情報に基づいて、S540のステップを実行する。そして、サーバ10の制御部11は、S550~S120の各ステップを実行し、店舗コードリーダ装置50から決済要求情報を受信すると、S570以降のステップを実行する。
通信I/F22によってサーバ10から第1並列コード情報と第2並列コード情報とを受信すると、端末Aの制御部21は、A510~A130の各ステップを実行し、通信I/F22によってサーバ10からアカウント並列決済結果情報を受信すると、A520以降のステップを実行する。
なお、前述したように、統合アカウントコード情報(限定ではなく、第1コード情報の一例)には、統合対象の支払いアプリケーションID(限定ではなく、第2アカウントに関する情報の一例)と、共通ウォレットID(限定ではなく、共通アカウントに関する情報の一例)とが含まれる、または関連付けられていると言える。
本変形例は、統合アカウントコード情報(限定ではなく、第1コード情報の一例)は、第2コード情報と、第3コード情報とを含み、第2コード情報は、共通ウォレットID(限定ではなく、共通アカウントの一例)に関連付けられ、第3コード情報は、統合対象の支払いアプリケーションID(限定ではなく、第2アカウントの一例)に関連付けられ、第2コード情報は、第3コード情報とは異なる領域に表示される構成を示している。
このような構成により得られる効果の一例として、異なる領域に表示される個別のコード情報に基づいて決済を実現することができる。
<第7変形例(3)>
第7実施例では、初めにコードを提示する統合アカウントでの支払いが失敗すると、処理を終了するが、そのようにしなくてもよい。
限定ではなく例として、統合アカウントでの支払いが失敗すると、自身のアカウントにチャージを実行し、統合アカウントの残高を増加させることで残高不足を補い、再度支払いを行ってもよい。
図7-4~図7-5は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図6-2と同様に実行することが可能であるため、詳細については説明を省略する。
端末Aの制御部21は、A610~A130の各ステップを実行する。そして、サーバ10の制御部11は、S480~S120の各ステップを実行する。店舗コードリーダ装置50の制御部51は、P100~P110の処理を実行する。
サーバ10の制御部11は、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信する。この場合、決済要求情報には、S490aのステップで送信した統合アカウントコード情報に基づく、統合アカウント支払いトークンが含まれる。そのため、サーバ10の制御部11は、統合アカウント決済処理を実行する(S680)。統合アカウント決済処理は、図5-7のS500aのステップと同様に実行することが可能であるため、詳細については説明を省略する。
S680において決済が成功した場合には(S690:YES)、サーバ10の制御部11は、図6-2のS510のステップへ処理を進ませる。
S680において決済が失敗した場合には(S690:NO)、サーバ10の制御部11は、決済が失敗した旨と、その場合の統合アカウントでの決済残高不足額とを含む決済残高不足情報を、通信I/F14によって端末Aと店舗コードリーダ装置50とに送信する(S700)。
ここで、本変形例における決済残高不足情報は、統合アカウントの残高が不足していることを示す情報であるが、統合アカウントは、共通アカウントと、ユーザA.Aのユーザアカウントとを統合したアカウントである。このため、本変形例における決済残高不足情報は、共通ウォレット残高と、ユーザA.Aの電子マネー口座残高とが不足していることを示す情報である。
そして、サーバ10の制御部11は、さらにS190~S210のステップを実行し、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、S500a以降のステップを実行する。
通信I/F22によってサーバ10から決済残高不足情報を受信すると(A610:YES)、端末Aの制御部21は、A280~A290のステップを実行する。端末Aの制御部21は、さらにA210~A230のステップを実行すると、通信I/F22によってサーバ10から統合アカウント決済結果情報を受信し、A480のステップを実行する。
決済残高不足情報を受信しない場合には(A610:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から統合アカウント決済結果情報を受信し、A480以降のステップを実行する。
通信I/F54によってサーバ10から決済残高不足額を受信すると(P200:YES)、店舗コードリーダ装置50の制御部51は、P130以降のステップを実行する。決済残高不足額を受信しない場合には(P200:NO)、店舗コードリーダ装置50の制御部51は、通信I/F54によってサーバ10から決済結果情報を受信し、P160以降のステップを実行する。
本変形例は、端末20が、決済予定金額(限定ではなく、第1決済の金額の一例)と、共通ウォレット残高(限定ではなく、共通アカウントの残高の一例)と、自己の端末20のユーザの電子マネー口座残高(限定ではなく、第2アカウントの残高の一例)とに基づき、共通ウォレット残高と、自己の端末20のユーザの電子マネー口座残高との残高が不足していることを示す決済残高不足情報(限定ではなく、共通アカウントと第2アカウントとの残高が不足していることに関する第1情報の一例)を表示部24に表示する。そして、端末20は、自己の端末20のユーザによる決済残高不足情報に対する入力に基づいて、自己の端末20のユーザの電子マネー口座にチャージする処理(限定ではなく、第2アカウントに対して送金する処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントと第2アカウントとの残高が不足していることを端末のユーザに知らせることができる。また、端末のユーザによる第1情報に対する入力に基づいて、第2アカウントに対して送金することができる。
<第7変形例(4)>
第7実施例ならびに第7変形例(3)では、統合アカウントによる支払い時に、共通ウォレット残高では足りず、ユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分を共通ウォレットの他のユーザ(限定ではなく例としてユーザB.B)へ請求することはなかったが、請求するようにしてもよいし、そのようにしなくてもよい。
この場合には、処理の後半において、図6-2のフローの代わりに図6-7のフローを実行すればよい。
<第7変形例(5)>
第7変形例(3)では、統合アカウントでの支払いが失敗すると、自身のアカウントにチャージを実行し、統合アカウントの残高を増加させることで残高不足を補うが、そのようにしなくてもよい。
限定ではなく例として、他の共通ウォレットメンバーに、共通ウォレットへの送金を依頼することで残高不足を補ってもよい。
図7-6は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する決済連携処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図7-4と、処理の後半については、限定ではなく例として図6-2と、それぞれ同一とすることができるため、ここでは説明を省略する。
端末Aの制御部21は、A290のステップを実行すると、A360~A380のステップを実行し、通信I/F22によってサーバ10から統合アカウント決済結果情報を受信すると、A480以降のステップを実行する。
端末Bの制御部21は、B140~B170のステップを実行し、処理を終了する。
サーバ10の制御部11は、S340~S390のステップを実行すると、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信し、S500a以降のステップを実行する。
なお、処理の各ステップについては、図4-19と同様に実行することが可能であるため、詳細については説明を省略する。
また、処理の後半として、図6-2のフローの代わりに図6-9、図4-21のフローを実行することで、他のユーザの電子マネー口座の残高を使用して立て替えた場合には、立て替え分が支払いを行った端末AのユーザA.Aへ請求されるようにしてもよいし、そのようにしなくてもよい。
また、他の共通ウォレットメンバーに共通ウォレットへの送金を依頼したが、その共通ウォレットメンバーによって共通ウォレットへの送金が認可されなかった場合、送金を依頼した端末20において、統合アカウントコード情報が表示部24に表示されないようにするか、またはそれ以降の決済に関する処理が実行されないようにしてもよい。
<第7変形例(6)>
第7変形例(3)では、統合アカウントでの支払いが失敗すると、自身のアカウントにチャージを実行し、統合アカウントの残高を増加させることで残高不足を補うが、そのようにしなくてもよい。
限定ではなく例として、共通ウォレットと自身の電子マネー口座とで構成される統合アカウントに、さらに他の共通ウォレットメンバーの電子マネー口座を加えてもよい。
図7-7~図7-8は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する決済処理、サーバ10の制御部11が実行する決済管理処理、店舗POSシステム(限定ではなく例として、加盟店S1の店舗POSシステム40)の構成要素である店舗コードリーダ装置50の制御部51が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図7-4と同一とすることができるため、ここでは説明を省略する。
端末Aの制御部21は、A290のステップを実行すると、統合アカウントへ他の電子マネー口座(限定ではなく例としてユーザB.Bの電子マネー口座)をさらに統合するか否かの選択用画面を、表示部24に表示させる(A620)。以下では、統合アカウントへのさらなる電子マネー口座の追加を「アカウント再統合」と称する。
端末Aの入出力部23に対するユーザ操作に基づいて、アカウントを再統合することが選択される場合(A620:YES)、端末Aの制御部21は、統合元の統合アカウントIDと、追加するユーザの支払いアプリケーションIDとを含むアカウント再統合依頼情報を、通信I/F22によってサーバ10に送信する。
端末Aの入出力部23に対するユーザ操作に基づいて、アカウントを再統合することが選択されない場合には(A620:NO)、端末Aの制御部21は、通信I/F22によってサーバ10から統合アカウント決済結果情報を受信し、図6-2のA480のステップを実行する。
通信I/F14によって端末Aからアカウント再統合依頼情報を受信する場合(S710:YES)、サーバ10の制御部11は、アカウント再統合処理を実行する(S720)。
アカウント再統合依頼情報を受信しない場合には(S710:NO)、サーバ10の制御部11は、通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信し、S500a以降のステップを実行する。
アカウント再統合処理では、サーバ10の制御部11は、統合アカウント管理データベース159から統合元の統合アカウントIDを持つ統合アカウント管理データのレコードを検索し、そのレコードの統合アカウントメンバーIDに、ユーザB.Bの支払いアプリケーションIDを加えて記憶させる。統合アカウントの残高は、統合アカウントメンバーIDに追加した支払いアプリケーションIDの電子マネー残高をさらに加えた金額となる。
そして、サーバ10の制御部11は、再統合した統合アカウントの電子マネー残高を含む再統合アカウント情報を、通信I/F14によって端末Aに送信する(S730)。
端末Aの制御部21は、通信I/F22によってサーバ10から再統合アカウント情報を受信すると、再統合した統合アカウントの電子マネー残高を表示部24に更新して表示させる(A640)。そして店舗コードリーダ装置50の制御部11は、P140~P160のステップを実行し、処理を終了する。
なお、サーバ10の制御部11は、アカウント再統合処理を実行すると、統合アカウント支払いトークンと、新たな統合アカウント支払いトークンを含む統合アカウントコード情報とを再生成し、通信I/F14によって端末Aに送信してもよい。この場合、端末Aの制御部21は、通信I/F22によってサーバ10から統合アカウントコード情報を受信すると、統合アカウントコード情報を表示部24に更新して表示させる。
通信I/F14によって店舗コードリーダ装置50から決済要求情報を受信すると、サーバ10の制御部11は、再統合アカウント決済処理を実行する(S740)。
統合アカウント決済処理では、サーバ10の制御部11は、要求を受けた統合アカウント支払いトークンから統合アカウントIDを検索する。サーバ10の制御部11は、さらに統合アカウントIDに紐づけられる統合アカウントメンバーID(ここではユーザA.Aの支払いアプリケーションIDと、ユーザB.Bの支払いアプリケーションIDと、共通ウォレットの共通ウォレットID)に基づいて、統合アカウントメンバーIDで指し示されるユーザA.Aの電子マネー口座残高とユーザB.Bの電子マネー口座残高と共通ウォレット残高との合計額を用いて、統合アカウントに対して、店舗IDで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する。
統合アカウントでの決済が成功する場合には、サーバ10の制御部11は、共通ウォレット残高を決済予定金額だけ減少させる。
一方、共通ウォレット残高が決済予定金額に満たない場合には、サーバ10の制御部11は、限定ではなく例として、共通ウォレット残高を優先的に支払いに使用して「0」とした後、不足分(=決済予定金額-共通ウォレット残高)を、ユーザA.Aの電子マネー口座残高とユーザB.Bの電子マネー口座残高とから割り勘(均等割り)して差し引く。
次いで、サーバ10の制御部11は、限定ではなく例として、決済処理の成否と、決済処理後の再統合した統合アカウント残高とを含む決済結果情報を、通信I/F14によって店舗コードリーダ装置50に送信する(S750)。
また、サーバ10の制御部11は、限定ではなく例として、決済処理の成否と、決済処理後の統合アカウントを構成する各ユーザの電子マネー口座・共通ウォレット残高と、それぞれの電子マネー口座・共通ウォレットでの支払い額とを含む再統合アカウント決済結果情報を、通信I/F14によって端末Aに送信し(S760)、処理を終了する。
通信I/F22によってサーバ10から再統合アカウント決済結果情報を受信すると、端末Aの制御部21は、再統合アカウント決済結果情報を表示部24に表示させ(A650)、処理を終了する。
なお、アカウント再統合においては、統合アカウントに追加可能な電子マネー口座はユーザアカウントに限定されない。別な共通ウォレットを追加してもよいし、そうしなくてもよい。
本変形例は、決済は、共通ウォレット残高と、自己の端末20のユーザのユーザアカウントの電子マネー口座残高と、異なる端末20のユーザのユーザアカウントの電子マネー口座残高とのうち、共通ウォレット残高(限定ではなく、共通アカウントの残高の一例)から優先的に支払いが行われる構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高から優先的に支払いが行われるため、他のアカウントを付随的なアカウントとすることができる。
また、本変形例は、端末20が、自己の端末20のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)および他の共通ウォレットメンバーのユーザアカウントを含む、共通ウォレットメンバーの各々のユーザアカウントと、共通アカウントとに基づいて決済に関する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第2アカウントを含む、共通アカウントによって決済可能なユーザの各々のアカウントと、共通アカウントとに基づいて決済を実現することができる。
また、本変形例は、統合アカウントコード情報(限定ではなく、第1コード情報の一例)は、共通ウォレットメンバーの各々のユーザアカウントが関連付いている構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザの各々のアカウントと関連付いた第1コード情報を決済に利用させることができる。
また、本変形例は、共通ウォレットメンバーの各々のユーザアカウントは、共通ウォレット残高の不足分が割り勘(均等割り)して差し引かれ、決済に基づく支払いが実行される構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザの各々のアカウントに共通アカウントの残高の不足分が均等に割り振られるため、公平な決済を実現することができる。
<第7変形例(7)>
第7変形例(6)では、共通ウォレットと、2以上のユーザの電子マネー口座とを統合するアカウント再統合処理および再統合アカウントを用いる支払いは、一度統合アカウントを用いて支払いを試み、失敗した後に行うこととしたが、それに限定されない。
限定ではなく例として、アカウントの再統合は図6-1の後に行ってもよい。
<第7変形例(8)>
利用者提示型のコード決済を適用する場合、端末20が、自己の端末20のユーザのユーザアカウントが関連付けられたコード情報(支払いコード等)(限定ではなく、第2アカウントに関連付けられた第3コード情報の一例)を表示部24に表示する。また、端末20が、これと同じ画面に、限定ではなく例として、共通ウォレットに関する情報(共通ウォレットID等)(限定ではなく、共通アカウント情報の一例)を表示する。そして、端末20が、表示した共通ウォレットに関する情報に対する自己の端末20のユーザによる入力に基づいて、限定ではなく例として、共通アカウントと、自己の端末20のユーザのユーザアカウントとが関連付けられた統合アカウントコード情報(限定ではなく、第1コード情報の一例)を表示部24に表示するようにしてもよいし、そのようにしなくてもよい。
同様に、店舗提示型のコード決済を適用する場合、端末20が、自己の端末20のユーザのユーザアカウントが関連付けられたコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第2アカウントに関連付けられた第3コードリーダ画面の一例)を表示部24に表示する。また、端末20が、これと同じ画面に、限定ではなく例として、共通ウォレットに関する情報(共通ウォレットID等)を表示する。そして、端末20が、表示した共通ウォレットに関する情報に対する自己の端末20のユーザによる入力に基づいて、限定ではなく例として、共通アカウントと、自己の端末20のユーザのユーザアカウントとが関連付けられた統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第1コードリーダ画面の一例)を表示部24に表示するようにしてもよいし、そのようにしなくてもよい。
このような構成により得られる効果の一例として、第2アカウントに関連付けられた第3コード情報、または第3コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、共通アカウント情報に対する端末のユーザによる入力に基づいて、端末のユーザが決済可能な第1アカウントと、第1アカウントとは異なる第2アカウントとが関連付けられた第1コード情報、またはコード情報の読み取りに関する表示である第1コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
また、上記において、利用者提示型のコード決済を適用する場合、端末20が、自己の端末20のユーザのユーザアカウントが関連付けられたコード情報(支払いコード等)に代えて、限定ではなく例として、共通アカウントが関連付けられた共通ウォレットコード情報(限定ではなく、第1アカウントに関連付けられた第3コード情報の一例)を表示するようにしてもよいし、そのようにしなくてもよい。
また、上記において、店舗提示型のコード決済を適用する場合、端末20が、自己の端末20のユーザのユーザアカウントが関連付けられたコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面に代えて、限定ではなく例として、共通ウォレットコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面(限定ではなく、第1アカウントに関連付けられた第3コード情報の一例)を表示するようにしてもよいし、そのようにしなくてもよい。
このような構成により得られる効果の一例として、第1アカウントに関連付けられた第3コード情報、または第3コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、共通アカウント情報に対する端末のユーザによる入力に基づいて、端末のユーザが決済可能な第1アカウントと、第1アカウントとは異なる第2アカウントとが関連付けられた第1コード情報、またはコード情報の読み取りに関する表示である第1コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
<第7変形例(9)>
第7実施例において、第4変形例(9)と同様に、コード決済に代えて、無線通信(近距離無線通信を含む。)によって決済を行うようにすることもできる。
これは、第4変形例(9)で説明した処理を、第7実施例で説明したアカウント統合に適用することで同様に実現可能である。
<第8実施例>
第8実施例は、前述した立替金額の請求・送金に関連する実施例である。立替金額の請求・送金は、前述した第2実施例~第7実施例のいずれにも適用可能である。
第8実施例では、共通ウォレットメンバーの端末20が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレットの電子マネー残高から実行する。支払い時に共通ウォレットの電子マネー残高が不足している場合には、ユーザの電子マネー口座から共通ウォレットへ送金を行うことで、共通ウォレットの残高不足を補う。
その上で、第8実施例では、共通ウォレットを破棄する場合に、ユーザの電子マネー口座残高から立て替えられた金額を請求する。
第8実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
「共通ウォレットの破棄」とは、共通ウォレットを終了させること、より具体的には、限定ではなく例として、以後共通ウォレットを使用しないために削除することを意味する。
限定でなく例として、共通ウォレットメンバーの代表者の端末20や、他の共通ウォレットメンバーの端末20からの破棄依頼によって、サーバ10で記憶・管理されている共通ウォレットのデータを削除する共通ウォレット破棄処理が実行される。
1回ごとの共通ウォレットメンバーの端末における支払い処理については、限定ではなく例として、第4実施例の図4-4~図4-5と同様に実行することが可能であるため、ここでは詳細な説明を省略する。
<データ構成>
図8-1は、本実施例においてサーバ10の記憶部15に記憶される共通ウォレット管理データベース157の一例である第2の共通ウォレット管理データベース157Bのデータ構成例を示す図である。
第2の共通ウォレット管理データベース157Bには、共通ウォレットIDごとの管理データとして、共通ウォレット管理データが記憶される。
各々の共通ウォレット管理データには、限定ではなく例として、共通ウォレットIDと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーIDと、立替履歴データとが関連付けて記憶される。
共通ウォレットIDと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーIDとは、第1の共通ウォレット管理データベース157Aと同様である。
立替履歴データは、この共通ウォレットを用いて支払いを行い、共通ウォレット残高不足によって決済予定金額の一部または全部がユーザの電子マネー口座残高から立て替えられた場合に、この共通ウォレットに対して実行される立て替え払いの履歴を記録するためのデータであり、限定ではなく例として、立替者IDと、立替者名と、立替日時と、立替金額とが関連付けて記憶される。
立替者IDは、この共通ウォレットの残高不足に対して、自身の電子マネー口座残高を用いて立て替え払いを実行する実行者(立替者)を識別するための識別子であり、限定ではなく例として、立て替え払いを行うユーザの支払いアプリケーションIDが記憶される。
立替者名は、立替者の名称であり、限定ではなく例として、立替者IDに対応するユーザ名が記憶される。
立替日時は、立て替え払いが行われる日時を記録する項目であり、限定ではなく例として、サーバ10の制御部11が、図4-5のS170aのステップを実行した日時が記憶される。
立替金額は、共通ウォレット残高不足が発生して、ユーザの電子マネー口座残高から立て替えられた金額であり、限定ではなく例として、図4-4のS250aのステップで算出される決済残高不足額が記憶される。
共通ウォレットメンバーの端末(限定ではなく例としてユーザA.Aの端末A)において、図4-4~図4-5に従い、決済処理(第1決済処理)が実行されるとする。そして、限定ではなく例として、図4-4のS250aのステップで決済処理が失敗し、決済残高不足額が「1,000円」であったとする。
サーバ10の制御部11は、図4-5のS170aのステップにおいて、決済処理が成功すると、決済処理を実行中の支払いアプリケーションID(この例ではユーザA.Aの支払いアプリケーションIDである「U0001」)と、そのユーザ名(この例では「A.A」)と、決済処理を実行した日時(この例では「2020/5/1/**:**:**」)と、図4-4のS270aのステップで送信した決済残高不足額(=立替金額)(この例では「1,000円」)とを、立替履歴データに関連付けて追記させる。
なお、決済残高不足額が「0」、もしくは、図4-5のS170aのステップにおいて、決済処理が失敗した場合には、立替履歴データへの追記処理は実行されない。
また、端末Bにおいて、図4-4~図4-5に従い、別の決済処理(第2決済処理)が実行されるとする。この場合、限定ではなく例として、決済残高不足額を「3,000円」とし、ユーザB.Bの電子マネー口座から共通ウォレットに送金することで決済処理が成功する場合、サーバ10の制御部11は、決済処理を実行中の支払いアプリケーションID(この例ではユーザB.Bの支払いアプリケーションIDである「U0002」)と、そのユーザ名(この例では「B.B」)と、決済処理を実行した日時(この例では「2020/5/5/**:**:**」)と、決済残高不足額(=立替金額)(この例では「3,000円」)とを、立替履歴データに関連付けて追記させる。
共通ウォレットメンバーのいずれかの端末20(限定ではなく例としてユーザA.Aの端末A)において、共通ウォレットを破棄することが選択されると、端末Aの制御部21は、共通ウォレット破棄要請情報を通信I/F22によってサーバ10に送信する。
通信I/F14によって端末Aから共通ウォレット破棄要請情報を受信すると、サーバ10の制御部11は、立替履歴データに記憶されるそれぞれの立替金額について、立替金額の請求処理を実行する。
限定ではなく例として、図8-1に例示する第2の共通ウォレット管理データベース157Bでは、立替履歴データに基づいて、まず端末Bに対して、「2020/5/1/**:**:**」の支払い立替額である「500円」(=1,000円÷2名)が請求される。次いで、端末Aに対して、「2020/5/5/**:**:**」の支払い立替額である「1,500円」(=3,000円÷2名)が請求される。
個別の請求処理については、限定ではなく例として、図4-9と同様に実行することが可能であるため、詳細については説明を省略する。
なお、限定ではなく例として、端末Aにおいて、共通ウォレットを破棄することが選択される際、自身の立替金額の請求を行わないことが選択される場合、サーバ10の制御部11は、端末Bに対して「2020/5/1/**:**:**」の支払い立替額を請求しない旨を含む情報を送信するなどして、請求処理を実行しないようにしてもよい。
立替履歴データに記憶された全ての立替金額について、立替金額の請求処理が実行されると、サーバ10の制御部11は、共通ウォレット破棄処理を実行する。
なお、端末が実行する支払い処理は、第4実施例に限定されず、第2実施例~第7実施例のいずれにも適用可能である。
アカウント統合処理を伴う場合には、立替金額として、ユーザの電子マネー口座残高によって立て替えられる金額を用いればよい。
<第8実施例の効果>
第8実施例は、支払い立替額請求情報が、共通ウォレットの破棄(限定ではなく、共通アカウントの破棄の一例)に基づいて、第2の端末20(請求を受ける端末20)に送信される構成を示している。
このような構成により得られる効果の一例として、共通アカウントの破棄に基づいて、決済に基づく請求情報が端末に送信されるようにすることができる。
また、第8実施例は、上記の支払い立替額請求情報は、第2の端末20のユーザに対する支払い立替額請求情報(限定ではなく、第1請求情報の一例)であり、共通アカウントと、第2の端末20(請求元の端末20)のユーザのユーザアカウント(限定ではなく、第2アカウントの一例)とに基づき、決済に関する処理(限定ではなく、第2決済に関する処理の一例)が実行され、第2の端末20のユーザによる決済(限定ではなく、第2決済の一例)に基づく、第1の端末20のユーザに対する支払い立替額請求情報(限定ではなく、第1請求情報とは異なる第2請求情報の一例)は、共通ウォレットの破棄に基づいて、第1の端末20(限定ではなく、第1端末の一例)に送信される構成を示している。
このような構成により得られる効果の一例として、第2決済に基づく、第1請求情報とは異なる第2請求情報が、共通アカウントの破棄に基づいて、第1端末に送信されるようにすることができる。
また、本実施例は、端末20が、支払い立替額を請求しない旨を含む情報(限定ではなく、請求情報を変更することに関する情報の一例)を、共通ウォレットメンバーの端末20の少なくとも一つに通信I/F22によって送信する構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザの端末の少なくとも一つに請求情報を変更することに関する情報を送信することによって、請求情報を変更することを通知することができる。
<第8変形例(1)>
第8実施例では、共通ウォレットを破棄する場合に、共通ウォレットを用いてそれまでに実行された立替金額の請求を実行したが、これに限定されない。
本変形例では、共通ウォレットメンバーの端末20が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレットの電子マネー残高から、もしくは共通ウォレットとユーザの電子マネー口座との統合アカウントの電子マネー残高から実行する。そして、共通ウォレット破棄操作を行う際、ユーザアカウントから共通ウォレットへの送金額と、ユーザアカウントによって立て替えられる立替金額とに基づいて、共通ウォレット残高をユーザアカウントに配分して送金(返金)する。
以下では、ユーザアカウントから共通ウォレットへ送金することを「共通ウォレットへの出資」と称し、その送金額を「出資金額」と称する。
1回ごとの共通ウォレットメンバーの端末における支払い処理については、限定ではなく例として、第6実施例の図6-1、図6-2、図4-5と同様に実行することが可能であるため、ここでは詳細については説明を省略する。
図8-2は、サーバ10の記憶部15に記憶される、共通ウォレット管理データベース157の一例である第3の共通ウォレット管理データベース157Cのデータ構成例を示す図である。
第3の共通ウォレット管理データベース157Cには、共通ウォレットIDごとの管理データとして、共通ウォレット管理データが記憶される。
各々の共通ウォレット管理データには、限定ではなく例として、共通ウォレットIDと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーIDと、共通ウォレット生成日時と、出資履歴データと、支払い履歴データとが関連付けて記憶される。
共通ウォレットIDと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーIDとは、第1の共通ウォレット管理データベース157Aと同様である。
共通ウォレット生成日時には、共通ウォレットが生成された日時が記憶される。
出資履歴データは、この共通ウォレットに対して実行される出資の履歴データであり、限定ではなく例として、出資者IDと、出資者名と、出資日時と、出資金額とが関連付けて記憶される。
出資者IDは、この共通ウォレットに対して出資を実行する実行者(出資者)を識別するための識別子であり、限定ではなく例として、出資を行うユーザの支払いアプリケーションIDが記憶される。
出資者名は、出資者の名称であり、限定ではなく例として、出資者IDに対応するユーザ名が記憶される。
出資日時は、出資が行われる日時であり、限定ではなく例として、出資者が共通ウォレットへの出資を実行した日時が記憶される。
出資金額は、出資者が実行したこの共通ウォレットへの出資あたりの出資金額である。
図8-2では、限定ではなく例として、共通ウォレット「キャンプ資金」に対して、ユーザA.Aが「2020/3/11/**:**:**」に「3,000円」を、「2020/4/14/**:**:**」に「3,000円」を出資したことが示されている。また、限定ではなく例として、ユーザB.Bが「2020/3/12/**:**:**」に「3,000円」を、「2020/4/14/**:**:**」に「3,000円」を出資したことが示されている。
支払い履歴データは、この共通ウォレットを用いて実行され、成立した支払いの履歴データであり、限定ではなく例として、支払い者IDと、店舗名と、支払い日時と、支払い金額と、立替金額と、回収フラグとが関連付けて記憶される。
支払い者IDは、加盟店において、この共通ウォレットを用いて支払いを実行する実行者(支払い者)を識別するための識別子であり、限定ではなく例として、支払いを行うユーザの支払いアプリケーションIDが記憶される。
店舗名は、支払いが行われる加盟店を識別するための名称であり、限定ではなく例として、加盟店が支払いアプリケーション利用登録の際に登録を行うその店舗もしくはサービスの名称が記憶される。
支払い日時は、その店舗名の加盟店において、支払いアプリケーションによって支払い者が支払いを実行する日時であり、限定ではなく例として、サーバ10の制御部11において決済処理や統合アカウント決済処理が実行され、成功した日時が記憶される。
支払い金額は、その店舗名の加盟店において、支払いアプリケーションによって支払いが実行される決済予定金額であり、限定ではなく例として、サーバ10の制御部11が通信I/F14によって店舗コードリーダ装置50から受信する決済要求情報に基づく決済予定金額が記憶される。
立替金額は、支払いが共通ウォレットとユーザの電子マネー口座との統合アカウントの電子マネー残高から実行される場合、共通ウォレット残高不足によってユーザの電子マネー口座残高から立て替えられた金額であり、限定ではなく例として、統合アカウント決済処理の結果に基づく支払い者の電子マネー口座からの支払い額が記憶される。なお、統合アカウント決済処理が実行されない場合には、立替金額は「0」とする。
回収フラグは、立替金額が「0」より大きい場合、支払い都度ごとに立替金額の請求が行われ、精算が完了しているか否かを記録するためのフラグ情報であり、限定ではなく例として、サーバ10の制御部11において精算送金処理が実行され、成功した場合には、限定ではなく例として「済」が記憶される。サーバ10の制御部11において精算送金処理が実行されていない、もしくは精算請求処理が失敗した場合には、限定ではなく例として「未」が記憶される。また、立替金額が「0」の場合には、精算を実行する必要がないため、限定ではなく例として「-」が記憶される。
支払い都度ごとの立替金額の請求処理については、限定ではなく例として、図6-7と同様に実行することが可能であるため、詳細については説明を省略する。
限定ではなく例として、図8-2では、支払い履歴データには、共通ウォレット「キャンプ資金」を用いて、支払い者「U0001」(すなわちユーザA.A)が、「2020/4/5/**:**:**」に、店舗「EEスーパー」で、「5,000円」の支払いを行ったことが示されている。また、支払い者「U0001」(すなわちユーザA.A)が、「2020/4/11/**:**:**」に、店舗「AAスポーツ」で、「3,000円」の支払いを行い、ユーザA.Aの電子マネー口座で「2,000円」を立て替え、立替分の精算がまだ完了していない「未」であることが示されている。
通信I/F14によって、限定ではなく例として、端末Aから共通ウォレット破棄要請情報を受信すると、サーバ10の制御部11は、第3の共通ウォレット管理データベース157Cの共通ウォレット管理データに基づいて、共通ウォレット精算破棄処理を実行する。
共通ウォレット精算破棄処理では、まず出資履歴データの出資者IDごとに、出資者ごとの合計出資金額を算出する。次いで、支払い履歴データの支払い者IDごとに、支払い者ごとの合計立替金額を算出する。なお、合計立替金額の算出では、回収フラグ「未」となっている立替金額のみを合算対象とする。
限定ではなく例として、図8-2では、ユーザA.Aの合計出資金額は「6,000円」(=3,000円+3,000円)となり、ユーザB.Bの合計出資金額は「6,000円」(=3,000円+3,000円)となる。また、ユーザA.Aの合計立替金額は「2,000円」となり、ユーザB.Bの合計立替金額は「6,000円」となる。
次に、全ての共通ウォレットメンバーの合計出資金額と、合計立替金額とを合わせた金額を共通ウォレット「キャンプ資金」の総出資金額として算出する。限定ではなく例として、図8-2では、総出資金額は「20,000円」(=6,000円+6,000円+2,000円+6,000円)である。
その後、共通ウォレット精算破棄処理を実行する時点で共通ウォレットから支出した共通ウォレットメンバー1人あたりの平均支払い額を「(総出資金額―共通ウォレット残高)÷共通ウォレットメンバー人数」によって算出する。
限定ではなく例として、図8-2では、平均支払い額は「(20,000円-6,000円)÷2=7,000円」となる。
次いで、共通ウォレットメンバーIDに記憶される支払いアプリケーションIDごとに、共通ウォレット残高を出資額の割合に基づいて返金するための返金予定額を算出する。返金予定額は「(合計出資金額+合計立替金額)-平均支払い額」で算出される。
返金予定額は、それぞれのユーザが共通ウォレットに対して直接的に出資した金額(合計出資金額)と、立て替えることで間接的に出資した金額(合計立替金額)との合計から、共通ウォレットにおける支払い金額を均等割りした金額を減算した金額となる。
限定ではなく例として、図8-2では、ユーザA.Aへの返金予定額は「6,000円+2,000円-7,000円=1,000円」となり、ユーザB.Bへの返金予定額は「6,000円+6,000円-7,000円=5,000円」となる。
最後に、サーバ10の制御部11は、共通ウォレットメンバーのそれぞれの電子マネー口座に対して、共通ウォレット残高を用いて返金予定額を送金する返金処理を実行する。
なお、返金予定額が負になる場合には、返金予定額の絶対値を送金金額として、そのユーザの電子マネー口座から共通ウォレットへ送金することで精算を行う。
共通ウォレット精算破棄処理が実行され、共通ウォレット残高が「0」になると、サーバ10の制御部11は、共通ウォレット破棄処理を実行する。
なお、端末が実行する支払い処理は、第6実施例に限定されず、第2実施例~第7実施例のいずれにも適用可能である。
共通ウォレットへの送金処理を実行する場合には、立替金額として、共通ウォレットでの支払いを成立させるにあたり共通ウォレットへの送金が少なくとも必要となる金額である、決済残高不足額を記憶させればよい。
<表示画面例>
図8-3は、図3-3のキャンプ資金支払い画面において「ウォレット破棄」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合に表示されるキャンプ資金のサマリー表示画面の一例を示す図である。以下説明する表示画面例は、図8-2の例を適用した画面図である。
この例では、タイトルバーの下には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、ユーザに対する操作案内として「ウォレット破棄」が表示され、その下には、キャンプ資金のサマリー表示領域2452が表示されている。
キャンプ資金のサマリー表示領域2452は、3段に分けて表示されており、上段には、現在の日付として「2020年4月15日」が表示され、その下には、角財布の画像および共通ウォレットの名称(キャンプ資金)のサマリーが表示されている。
中段には、キャンプ資金の共通ウォレット残高として、「残高」の文字とともに「6,000円」が表示されている。また、それらの横には、作成日として「2020年3月11日」が表示されており、その下には、キャンプ資金の共通ウォレットメンバーの人数として「2人」が表示されている。そして、その下には、共通ウォレットメンバーである、ユーザA.Aのアイコン画像とユーザB.Bのアイコン画像とが表示されている。
また、下段には、総出資金額として「20,000円」が、総支払い金額として「14,000円」がそれぞれ表示されている。総支払い金額は、限定ではなく例として「総出資金額―共通ウォレット残高」で算出される金額である。
また、キャンプ資金のサマリー表示領域2452の下には、各々のメンバーへの返金予定額がリスト形式で表示されている。
返金予定額の1行目には、ユーザA.Aのアイコン画像とともに、ユーザ名「自分」の文字が表示され、その横に、返金予定額として、この例では「1,000円」が表示されている。また、その横には、自分の返金予定額の修正するための修正ボタンBT9と、自分の返済予定額の詳細を確認するための詳細ボタンBT10とが並べて表示されている。
また、返金予定額の2行目には、ユーザB.Bのアイコン画像とともに、ユーザ名「B.B」の文字が表示され、その横に、返金予定額として、この例では「5,000円」が表示されている。また、その横には、ユーザA.Aと同様に、修正ボタンBT9と、詳細ボタンBT10とが並べて表示されている。
また、画面下部には、共通ウォレットの破棄をキャンセルするためのキャンセルボタン242Rと、共通ウォレットの破棄を実行するための破棄ボタン242Sとが並べて表示されている。
図8-4は、図8-3のキャンプ資金のサマリー表示画面において、自分の行における詳細ボタンBT10がタッチ操作された場合に表示される自分のサマリー表示画面の一例を示す図である。
この例では、自分のサマリー表示領域2453は、2段に分けて表示されており、上段には、現在の日付として「2020年4月15日」が表示され、その下に、ユーザA.Aのアイコン画像とともに、ユーザ名「自分」の文字が表示されている。下段には、出資金額として「出資の金額」の文字が表示されるとともに、その横にユーザA.Aの合計出資金額である「6,000円」が表示されている。
また、その下には、支払い金額として「支払い金額」の文字が表示されるとともに、その横に共通ウォレット「キャンプ資金」を用いたユーザA.Aの支払い金額の合計額である「8,000円」が表示されている。その下には、立替金額として「立替金額」の文字が表示されるとともに、その横にユーザA.Aの合計立替金額である「2,000円」が表示されている。
また、自分のサマリー表示領域2453の下には、自分の利用履歴が、リスト形式にて時系列順に表示されている。1行目には、利用日の日時として「2020年3月11日20時55分」が表示されており、その下に、利用項目として「出資」の文字が表示されるとともに、出資金額として「3,000円」が表示されている。
2行目には、利用日の日時として「2020年4月5日11時12分」が表示されており、その下に、利用項目として「支払い」の文字が表示されるとともに、支払い先として、「EEスーパー」が表示されている。また、その横に、支払い金額として「5,000円」が表示されている。
3行目には、利用日の日時として「2020年4月11日16時30分」が表示されており、その下に、利用項目として「支払い」の文字が表示されるとともに、支払い先として「AAスポーツ」が表示されている。その横には、支払い金額として「3,000円」が表示されている。また、その下には、利用項目として「立替」の文字が表示されるとともに、立替金額として「2,000円」が表示されている。
4行目には、利用日の日時として「2020年4月14日12時21分」が表示されており、その下に、利用項目として「出資」の文字が表示されるとともに、出資金額として「3,000円」が表示されている。
また、自分のサマリー表示領域2453の最下部には、戻るアイコン242Tが表示されている。
図8-5は、図8-3のキャンプ資金のサマリー表示画面において、ユーザB.Bの行における詳細ボタンBT10がタッチ操作された場合に表示されるユーザB.Bのサマリー表示画面の一例を示す図である。
この例では、ユーザB.Bのサマリー表示画面について説明するが、上記の自分のサマリー表示画面と表示形式は同一となっている。
ユーザB.Bのサマリー表示画面では、ユーザB.Bのサマリー表示領域2454は、2段に分けて表示されており、上段には、現在の日付として「2020年4月15日」が表示され、その下に、ユーザB.Bのアイコン画像とともに、ユーザ名「B.B」の文字が表示されている。下段には、出資金額として「出資の金額」の文字が表示されるとともに、その横にユーザB.Bの合計出資金額である「6,000円」が表示されている。
また、その下には、支払い金額として「支払い金額」の文字が表示されるとともに、その横に共通ウォレット「キャンプ資金」を用いたユーザB.Bの支払い金額の合計額である「6,000円」が表示されている。その下には、立替金額として「立替金額」の文字が表示されるとともに、その横にユーザB.Bの合計立替金額である「6,000円」が表示されている。
また、ユーザB.Bのサマリー表示領域2454の下には、ユーザB.Bの利用履歴が、リスト形式にて時系列順に表示されている。1行目には、利用日の日時として「2020年3月12日8時24分」が表示されており、その下に、利用項目として「出資」の文字が表示されるとともに、出資金額として「3,000円」が表示されている。
2行目には、利用日の日時として「2020年4月12日12時5分」が表示されており、その下に、利用項目として「支払い」の文字が表示されるとともに、支払い先として「BBホームセンター」が表示されている。また、その横に、支払い金額として「6,000円」が表示されている。また、その下には、利用項目として「立替」の文字が表示されるとともに、立替金額として「6,000円」が表示されている。
3行目には、利用日の日時として「2020年4月14日15時38分」が表示されており、その下に、利用項目として「出資」の文字が表示されるとともに、出資金額として「3,000円」が表示されている。
また、ユーザB.Bのサマリー表示領域2454の最下部には、戻るアイコン242Tが表示されている。
本変形例は、端末20のユーザの入力に基づいて、支払い立替額請求情報に基づく共通ウォレットへの送金処理が実行される。第1の端末20のユーザアカウント(限定ではなく、第1アカウントの一例)は、第1の端末20のユーザによる決済(限定ではなく、第1決済の一例)によって第1の端末20のユーザアカウントから支払われた金額以上、またはそれよりも多くの金額が共通ウォレットに含まれている場合、第1の端末20のユーザによる決済によって第1の端末20のユーザのユーザアカウントから支払われた金額が共通ウォレットから送金される構成を示している。
このような構成により得られる効果の一例として、第1アカウントは、第1決済によって第1アカウントから支払われた金額以上、またはそれよりも多くの金額が共通アカウントに含まれている場合、第1決済によって第1アカウントから支払われた金額が共通アカウントから送金されるようにすることができる。
また、本変形例は、端末20が、自己の端末20のユーザへの返金予定額の修正するための情報(限定ではなく、返金に関する情報を変更することに関する情報の一例)を、サーバ10を介して他の端末20に通信I/F22によって送信する構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザの端末の少なくとも一つに返金情報を変更することに関する情報を送信することによって、返金情報を変更することを通知することができる。
<第8変形例(2)>
第8変形例(1)では、サーバ10の制御部11が、共通ウォレットメンバーのそれぞれの電子マネー口座に対して、共通ウォレット残高を用いて返金予定額を送金する返金処理を実行することとしたが、これに限定されない。限定ではなく例として、以下のような処理を実行するようにしてもよい。
共通ウォレットを破棄する場合、サーバ10の制御部11は、共通ウォレット残高を均等割りした金額(以下、「1人あたり仮返金額」と称する。)を、各々のユーザに仮返金する仮返金処理を実行する。そして、制御部11は、この1人あたり仮返金額と、第8変形例(1)で説明した返金予定額(=(合計出資金額+合計立替金額)-平均支払い額)とに基づいて、各々のユーザの送金額/受金額を算出・決定する。そして、算出・決定した送金額/受金額に基づく送金処理/受金処理を端末20に実行させることで、最終的な金額を調整する。
図8-2に示した金額の例で説明する。
共通ウォレットを破棄する場合の共通ウォレット残高は「6,000円」であるため、サーバ10の制御部11は、1人あたり仮返金額を「6000円÷2名=3000円」として、ユーザA.AとユーザB.Bとに仮返金する。
その一方、図8-2の例では、ユーザA.Aへの返金予定額は「6,000円+2,000円-7,000円=1,000円」であり、ユーザB.Bへの返金予定額は「6,000円+6,000円-7,000円=5,000円」である。このため、ユーザA.Aは2,000円もらい過ぎである一方、ユーザB.Bは2,000円足りないことになる。そこで、制御部11は、ユーザA.AのユーザアカウントからユーザB.Bのユーザアカウントに対して「2,000円」を送金することを通知する情報を、ユーザA.Aの端末20と、ユーザB.Bの端末20とに通信I/F14によってそれぞれ送信する。そして、制御部11は、ユーザA.Aの電子マネー口座残高から「2,000円」を減算するとともに、ユーザB.Bの電子マネー口座残高に「2,000円」を加算する。そして、制御部11は、共通ウォレット破棄処理を実行する。
本変形例は、共通ウォレットを破棄する場合、第2の端末20は、第1の端末20(限定ではなく、第1端末の一例)から共通ウォレットに対して送金された金額(限定ではなく、第2金額の一例)の情報と、第2の端末20から共通ウォレットに対して送金された金額(限定ではなく、第1金額の一例)の情報とに少なくとも基づき、第2の端末20のユーザのユーザアカウントから第1の端末20のユーザのユーザアカウントへ送金することを通知する情報(限定ではなく、端末のユーザから第1端末の第1ユーザへ送金することに関する情報の一例)、または第1の端末20のユーザのユーザアカウントから第2の端末20のユーザのユーザアカウントへ送金することを通知する情報(限定ではなく、第1端末の第1ユーザから端末のユーザへ送金することに関する情報の一例)を通信I/F22によって受信する構成を示している。
このような構成により得られる効果の一例として、共通アカウントに対する送金を実現することができる。また、共通アカウントを破棄する場合、第1端末から共通アカウントに対して送金された第2金額の情報と、第1金額の情報とに少なくとも基づき、ユーザから第1ユーザへ送金することに関する情報、または第1ユーザからユーザへ送金することに関する情報を受信して、端末のユーザに報知することができる。
また、本変形例は、上記の第2の端末20のユーザのユーザアカウントから第1の端末20のユーザのユーザアカウントへ送金することを通知する情報、または第1の端末20のユーザのユーザアカウントから第2の端末20のユーザのユーザアカウントへ送金することを通知する情報は、第2の端末20から共通ウォレットに送金された金額(限定ではなく、第1金額の一例)と、第1の端末20から共通ウォレットに送金された金額(限定ではなく、第2金額の一例)と、共通ウォレット残高(限定ではなく、共通アカウントの残高の一例)とに基づいて決定される構成を示している。
このような構成により得られる効果の一例として、第1金額と、第2金額と、共通アカウントの残高とに基づいて、ユーザから第1ユーザへ送金することに関する情報、または第1ユーザからユーザへ送金することに関する情報を適切に決定することができる。
また、本変形例は、第1の端末20のユーザのユーザアカウント(限定ではなく、第1アカウントの一例)と、共通アカウントとに基づき、第1の端末20(限定ではなく、第1ユーザの第1端末の一例)によって決済に関する処理が実行され、第2の端末20は、第1の端末20のユーザによる決済に基づく支払い立替額請求情報(限定ではなく、第1決済に基づく金額の請求に関する請求情報の一例)を、共通ウォレットの破棄に基づいて、通信I/F22によって受信する構成を示している。
このような構成により得られる効果の一例として、第1決済に基づく金額の請求に関する請求情報を、共通アカウントの破棄に基づいて受信することができる。
また、本変形例は、サーバ10が、少なくとも第2の端末20のユーザ(限定ではなく、端末のユーザの一例)と、第1の端末20のユーザ(限定ではなく、第1ユーザの一例)とが決済可能な共通アカウントに対して第2の端末20から送金する金額(限定ではなく、第1金額の一例)の情報と、共通アカウントに対して第1の端末20から送金する金額(限定ではなく、第2金額の一例)の情報とを通信I/F22によって受信する。そして、サーバ10は、共通ウォレットの破棄に基づいて、上記の送金する金額の情報に基づき、第2の端末20のユーザのユーザアカウントから第1の端末20のユーザアカウントへの送金処理(限定ではなく、端末のユーザのアカウントから第1端末の第1ユーザのアカウントへ送金することに関する処理の一例)、または第1の端末20のユーザのユーザアカウントから第2の端末20のユーザのユーザアカウントへの送金処理(限定ではなく、第1端末の第1ユーザのアカウントから端末のユーザのアカウントへ送金することに関する処理の一例)を制御部11によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントの破棄に基づいて、第1金額の情報と、第2金額の情報とに少なくとも基づき、ユーザのアカウントから第1ユーザのアカウントへ送金することに関する処理、または第1ユーザのアカウントからユーザのアカウントへ送金することに関する処理をサーバの制御部によって実行して、適切に金額を精算することができる。
<第9実施例>
次に、前述した「(B)アカウント連携決済」の実施例について説明する。第9実施例は、アカウント連携決済を実現する実施例である。
第9実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、アカウント連携の一例として、メッセージングアプリケーションで形成されたグループに含まれるユーザ(以下、「グループメンバー」と称する。)のユーザアカウントを連携する実施例について説明する。これを実現するサーバ10の構成は、図3-20と同様である。
本実施例では、サーバ10がアカウント連携処理を実行することとして説明する。
なお、これに限らず、アカウント連携処理を端末20で実行するようにしてもよいし、そのようにしなくてもよい。
<表示画面例>
以下では、前述したメッセージングアプリケーションにおけるトークルームを例に挙げて表示画面例について説明する。前述したようにメッセージングアプリケーションを利用したトークは「チャット」の一例であり、トークルームは「チャットルーム」の一例である。
以下では、メッセージングアプリケーションにおいて形成されたグループに含まれる複数のグループメンバーのユーザアカウントを連携して、アカウント連携決済を行う場合を例示する。
図9-1は、図5-30と同様に、図3-1のサブメニューにおいて「自分のウォレット」(図示せず)がタッチ操作され、自分のウォレット画面において「コード支払い」と示されたアイコンが端末20のユーザA.Aによってタッチ操作された場合にユーザA.Aの端末20の表示部24に表示されるコード支払い画面(連携前)の一例を示す図である。
自分のウォレットからのコード支払い領域2451内の上部において、がま口財布のアイコン画像ともに「自分のウォレット」の文字が表示されている下に、図5-3では「ウォレット統合」の文字が表示されているのに対し、図9-1では鎖のマークとともに「ウォレット連携」の文字が表示され、その横に、ウォレット連携の「ON/OFF」を切り替えるためのスライドボタンCN7が表示されている。ウォレット連携は、アカウント連携と実質的に同義である。
図9-2は、図9-1においてスライドボタンCN7がタッチ操作された場合に表示されるトークルーム選択画面の一例を示す図である。
この画面には、限定ではなく例として、メッセージアプリケーションのアプリケーション名である「Messaging App」が最上段のタイトルバーに表示され、その横に、ユーザA.Aのアイコン画像と、ユーザ名「A.A」の文字とが表示されている。タイトルバーの下には、「Messaging App」の階層メニューにおける現在位置が表示されている。
具体的には、限定ではなく例として、現在実行中の最上位のメニューである「ウォレット連携」が表示されている。その下には、「トークルームを選択」の文字が表示され、その横に、この画面を閉じるための「×アイコン」が表示されている。また、その下には、ユーザに対する操作案内として「ウォレット連携するトークルームを選んでください」の説明文が表示され、その下には、複数のトークルーム(より具体的にはグループトークルーム)がリスト形式で表示されている。
このリストには、ユーザが選択可能に縦方向に並べられた複数の行アイテムが含まれ、行アイテムには、トークルームのトークルームアイコン画像と関連付けて、そのトークルームの名称が表示されている。
この例では、そのリストにおいて、木のアイコン画像と関連付けて「春の摩周湖キャンプ(2)」の文字が表示された行アイテムと、皿上のナイフおよびフォークのアイコン画像と関連付けて「韓国グルメ連合(3)」の文字が表示された行アイテムと、ボールをキャッチしているグローブのアイコン画像と関連付けて「草野球チーム(10)」の文字が表示された行アイテムとが含まれる。「()内の数字」は、そのグループに含まれるユーザ(グループメンバー)の人数を示している。
図9-3は、図9-2に示すトークルーム選択画面において「草野球チーム(10)」の文字が表示されている行アイテムがタッチ操作された場合に表示されるコード支払い画面(連携後)の一例を示す図である。
図9-3が図9-1と異なるのは、コード支払い領域2451内において、スライドボタンCN7が「ON」の状態とされており、その下に、新たにボールをキャッチしているグローブのアイコン画像とともに「草野球チーム(10)」の文字が表示されていることである。
また、アカウント(ウォレット)が連携されたことで、表示されている支払いコードは図9-1のものとは異なるコードとなっている。
図9-4は、図3-7と同様にサーバ10による決済処理が完了した場合に端末20に表示されるコード支払い完了画面の一例を示す図である。
図9-4のコード支払い完了画面が図3-7のコード支払い完了画面と異なるのは、この画面下部において、支払い先が「AAスポーツ株式会社」であることが示されている部分より下の部分である。具体的には、支払い先の表示の下には、下線を介して、新たに「草野球チーム」のグループに関する情報が表示されている。より具体的には、「草野球チーム」のメンバーの人数として「10人」が表示され、1人あたりの金額として「500円」が表示されている。
また、画面下部には、コード支払いの完了をユーザが確認したことを通知するための確認ボタン242Bが表示されている。
図9-5は、端末20で実行されるメッセージングアプリケーションにおいて表示部24に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面には、限定ではなく例として、メッセージングアプリケーションのアプリケーション名である「Messaging App」が最上段のタイトルバーに表示されている。タイトルバーの下には、「Messaging App」の階層メニューにおける現在位置が表示される。具体的には、限定ではなく例として、現在実行中の最上位のメニューである「草野球チーム(10)」が表示されている。その下には、トークルーム領域2461が設けられており、さらにその下には、アイコン表示領域2471が設けられている。
この例では、トークルーム領域2461において、上部中央に、日付として「今日」の文字が表示されている。その下には、ユーザX.Xのアイコン画像とともに、ユーザ名「X.X」が表示されており、ユーザX.Xから「12時10分」に発信されたメッセージとして「次の試合で使うボールが足りません…」というメッセージが、画面向かって左側に吹き出しで表示されている。
また、その下には、自己の端末20のユーザであるユーザA.Aが「12時33分」に返信したメッセージとして「ちょうどAAスポーツで買い物しているので、購入しておきますね」というメッセージが、画面向かって右側に吹き出しで表示されている。
また、その下には、ユーザY.Yのアイコン画像とともに、ユーザ名「Y.Y」が表示されており、ユーザY.Yから「12時48分」に発信されたメッセージとして「お願いします!」というメッセージが、画面向かって左側に吹き出しで表示されている。
また、アイコン表示領域2471には、限定ではなく例として、「ファイル」、「連絡先」、「位置情報」、「ギフト」、「送金」、「ウォレット連携」にそれぞれ対応する6つのアイコンが表示されている。以下では、「ウォレット連携」に対応するアイコンをウォレット連携アイコンCN8として説明する。
図9-6は、図9-5のトークルーム画面においてウォレット連携アイコンCN8がタッチ操作された場合に表示されるトークルーム画面の一例を示す図である。
図9-6では、図9-5のトークルーム領域2461に表示されていたユーザY.Yから発信された「お願いします!」のメッセージの下に、ユーザA.Aから発信されたメッセージとして、アカウントが連携され、連携されたアカウントから支払いが行われたことを通知するための連携通知メッセージ2462が表示されている。
限定ではなく例としてユーザA.Aの端末20の表示部24に図9-4が表示されると、支払い管理サーバ10Aからメッセージング管理サーバ10Bへ、限定ではなく例としてAPIを介して支払いに関する情報が送信される。すると、限定ではなく例としてメッセージング管理サーバ10Bの制御部によって、連携通知メッセージ2462が生成され、アカウントが連携された各端末に自動的にメッセージが送信される。
この連携通知メッセージ2462では、上段に[Payment App]の文字が表示されており、その下に、鎖のマークとともに、「ウォレット連携支払い」の文字が表示されている。また、その下には、1人あたりの支払い金額が「500円」であることが表示されている。
また、下段には、支払い先は「AAスポーツ株式会社」であり、支払い金額は「5,000円」であり、グループメンバーの人数は「10人」であることが表示されている。また、その下には、詳細内容を確認するための詳細確認アイコンが表示されている。
図9-7は、図9-6に対応するユーザX.Xの端末20の表示部24に表示されるトークルーム画面の一例を示す図であり、ユーザY.Yから発信された「お願いします!」のメッセージの下に、上記の連携通知メッセージ2462が表示されている。
<第9実施例の効果>
第9実施例は、端末20が、自己の端末20のユーザのユーザアカウント(限定ではなく、第1アカウントの一例)と、他のグループメンバーのユーザアカウント(限定ではなく、第2アカウントの一例)とを連携するための処理(限定ではなく、第1アカウントと第2アカウントとを関連付ける処理の一例)を制御部21によって実行する。そして、端末20は、連携された自己の端末20のユーザのユーザアカウントと他のグループメンバーのユーザアカウントとに基づき、決済に関する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第1アカウントと、第1アカウントとは異なる第2アカウントとを関連付けることができる。そして、関連付けられた第1アカウントと、第2アカウントとに基づく決済を実現することができる。
また、第9実施例は、連携する他のグループメンバーのユーザアカウント(限定ではなく、第2アカウントの一例)は、グループトークルーム(限定ではなく、チャットルームの一例)の選択に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、チャットルームの選択という簡単な方法によって、第2アカウントを選択することができる。
<第9変形例(1)>
第9実施例では、グループトークルームを選択することでアカウント連携を行ったが、これに限定されない。当然ではあるが、2人のユーザ間でユーザアカウントを連携するといったことも可能である。
限定ではなく例として、ユーザA.AとユーザB.Bとの2名のユーザアカウントを連携させて決済を行う場合、ユーザA.Aが、自己の端末20で実行される支払いアプリケーション、またはメッセージングアプリケーションにおいて、ユーザB.Bを直接的に選択して、自分のユーザアカウントとユーザB.Bのユーザアカウントとを連携させるようにしてもよい。この場合、ユーザA.AのユーザアカウントとユーザB.Bのユーザアカウントとが連携されて、アカウント連携決済が行われることになる。
なお、ユーザA.Aが勝手にアカウント連携を行うと、ユーザB.Bに不利益を生ずる可能性がある。このため、ユーザA.Aは、ユーザB.Bにアカウント連携の許可を取るようにするとよい。
<第9変形例(2)>
第9実施例において、第4変形例(9)と同様に、コード決済に代えて、無線通信(近距離無線通信を含む。)によって決済を行うようにすることもできる。
前述した非接触式通信を適用する場合、端末20のユーザは、自己の端末20を店舗のカードリーダやカードリーダライタにかざすことによって、上記の実施例と同様に決済を行う。この場合、カードリーダで情報を読み取った結果、自己の端末20のユーザのユーザアカウントの電子マネー口座残高が不足している場合は、限定ではなく例として、サーバ10の制御部11は、その残高が不足していることを示す情報(決済残高不足情報)を通信I/F14によって端末20に送信する。通信I/F22によってサーバ10から決済残高不足情報を受信すると、端末20の制御部21は、決済残高不足情報を表示部24に表示させる。そして、端末20の制御部21は、表示させた決済残高不足情報に対する自己の端末20のユーザの入力に基づいて、アカウント連携処理を実行する。そして、端末20のユーザが、自己の端末20を店舗のカードリーダに再度かざすことによって、アカウント連携決済を行うようにすることができる。
なお、前述したように、あらかじめアカウントを連携しておくようにすることもできる。
これらは、ブルートゥース通信を適用する場合も同様である。
本変形例は、決済に関する処理は、端末20の通信I/F22による、店舗コードリーダ装置50(限定ではなく、決済によって購入する商品を販売するまたはサービスを提供する店舗の端末の一例)との無線通信により実行される構成を示している。
このような構成により得られる効果の一例として、第1決済によって購入する商品を販売するまたはサービスを提供する店舗の端末との無線通信によって決済を実現することができる。
また、本変形例は、上記の無線通信は、近距離通信である構成を示している。
このような構成により得られる効果の一例として、第1決済によって購入する商品を販売するまたはサービスを提供する店舗の端末との無線通信を近距離通信によって実現することができる。
<第9変形例(3)>
第9実施例で説明したアカウント連携決済を、一時的に共通ウォレットを作成し、その共通ウォレットを用いて決済する共通アカウント決済とすることもできる。
具体的には、限定ではなく例として、図9-2のトークルーム選択画面においてアカウント連携決済を行うグループトークルームが選択された場合、サーバ10は、選択されたグループトークルームのメンバーを共通ウォレットメンバーとする一時的な共通ウォレット(共通ウォレット残高=0)を作成する。
作成された共通ウォレットから決済を行おうとすると、共通ウォレット残高が「0」であるため、決済は失敗することになる。この場合、限定ではなく例として、前述した第2実施例~第7実施例で説明した手法を適用して決済を行うようにすることができる。
つまり、この場合、前述した第2実施例~第7実施例で説明した内容を同様に適用することができる。
また、共通ウォレットを破棄する場合は、第8実施例で説明した内容を同様に適用することができる。
<第10実施例>
第10実施例は、前述した各種の実施例における2つのアカウント(第1アカウントと第2アカウント)の組み合わせ(バリエーション)に関する実施例である。
図10は、第1アカウントと第2アカウントとの組み合わせを説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、パターンと、第1アカウントと、第2アカウントとが関連付けて定められている。以下、それぞれのパターンについて説明する。
(1)パターンA
パターンAは、第1アカウントを「第1共通アカウント(第1共通ウォレット)」とするパターンであり、第2アカウントを4種類とする、パターンA1~パターンA4の4通りのパターンが定められている。
第1共通アカウントは、自己の端末20のユーザを含む複数の端末20のユーザが使用可能な共通ウォレットのアカウント(1つ目のアカウント)である。
パターンA1は、第2アカウントを「自分のユーザアカウント(電子マネー口座)」とするパターンである。
パターンA2は、第2アカウントを「他人のユーザアカウント(電子マネー口座)」とするパターンである。
パターンA3は、第2アカウントを「事業者アカウント(事業者ローン口座)」とするパターンである。
事業者は、限定ではなく例として、支払いサービス(支払いアプリケーション)を提供する事業者を含む、金銭の融資・貸与を業とする認可を受けた事業者である。
事業者アカウントは、この事業者の支払いアプリケーションのアカウントである。
事業者ローン口座は、この事業者が利用者(端末20のユーザ)に対して金銭を融資・貸与するための口座である。
パターンA4は、第2アカウントを「第2共通アカウント(第2共通ウォレット)」とするパターンである。
第2共通アカウントは、自己の端末20のユーザを含む複数の端末20のユーザが使用可能な第1共通アカウントとは異なる共通アカウント(2つ目の共通アカウント)である。
(2)パターンB
パターンBは、第1アカウントを「自分の第1ユーザアカウント」とするパターンであり、第2アカウントを4種類とするパターンB1~パターンB4の4通りのパターンが定められている。
自分の第1ユーザアカウントは、自分の支払いアプリケーションのアカウント(1つ目のユーザアカウント)である。
パターンB1は、第2アカウントを「共通アカウント」とするパターンである。
パターンB2は、第2アカウントを「他人のユーザアカウント」とするパターンである。
パターンB3は、第2アカウントを「事業者アカウント」とするパターンである。
パターンB4は、第2アカウントを「自分の第2ユーザアカウント」とするパターンである。
自分の第2ユーザアカウントは、自分の第1ユーザアカウントとは異なる自分の支払いアプリケーションのアカウント(自分の2つ目のユーザアカウント)である。
(3)パターンC
パターンCは、第1アカウントを「第1ユーザアカウント(他人A)」とするパターンであり、第2アカウントを4種類とするパターンC1~パターンC4の4通りのパターンが定められている。
第1ユーザアカウント(他人A)は、他人Aの支払いアプリケーションのアカウントである。
パターンC1は、第2アカウントを「共通アカウント」とするパターンである。
パターンC2は、第2アカウントを「自分のユーザアカウント」とするパターンである。
パターンC3は、第2アカウントを「事業者アカウント」とするパターンである。
パターンC4は、第2アカウントを「第2ユーザアカウント(他人Aまたは他人B)」とするパターンである。
第2ユーザアカウント(他人Aまたは他人B)は、他人Aの第1ユーザアカウントとは異なる他人Aの支払いアプリケーションのアカウント(他人Aの2つ目のユーザアカウント)、または他人Bの支払いアプリケーションのアカウント(他人Bの1つ目のユーザアカウント)である。
(4)パターンD
パターンDは、第1アカウントを「第1事業者アカウント」とするパターンであり、第2アカウントを4種類とするパターンD1~パターンD4の4通りのパターンが定められている。
第1事業者アカウントは、第1事業者の支払いアプリケーションのアカウント(第1事業者の1つ目のアカウント)である。
パターンD1は、第2アカウントを「自分のユーザアカウント」とするパターンである。
パターンD2は、第2アカウントを「他人のユーザアカウント」とするパターンである。
パターンD3は、第2アカウントを「共通アカウント」とするパターンである。
パターンD4は、第2アカウントを「第2事業者アカウント」とするパターンである。
第2事業者アカウントは、第1事業者アカウントとは異なる第1事業者の支払いアプリケーションのアカウント(第1事業者の2つ目のアカウント)、または第2事業者の支払いアプリケーションのアカウント(第2事業者の1つ目のアカウント)である。
共通アカウント決済では、上記のパターンのうち、共通アカウントを含むパターンであるパターンA(パターンA1~パターンA4)、パターンB1、パターンC1、パターンD3のうちのいずれかのパターンを適用可能である。この場合、第2実施例~第8実施例の手法を同様に適用して、共通アカウント決済を行うようにすることができる。
アカウント連携決済では、上記のパターンのうち、共通アカウントを含まないパターンであるパターンB2~パターンB4、パターンC2~パターンC4、パターンD1,D2,D4のうちのいずれかのパターンを適用可能である。この場合、第9実施例の手法を同様に適用して、アカウント連携決済を行うようにすることができる。
また、アカウント連携決済を複数のユーザが一緒に決済を行う手法と捉えるのであれば、共通アカウントを使用しないパターンを第2実施例~第8実施例の手法に適用することも可能である。つまり、上記のパターンのうち、共通アカウントを含まないパターンであるパターンB2~パターンB4、パターンC2~パターンC4、パターンD1,D2,D4のうちのいずれかのパターンを第2実施例~第8実施例に適用することも可能である。
<第10実施例の効果>
第10実施例によれば、第1アカウントと第2アカウントとを種々のアカウントとして設定して決済を実現することができるため、端末のユーザの利便性を向上させることができる。
限定ではなく例として、第2アカウントが事業者アカウント(限定ではなく、事業者のアカウントの一例)であり、決済に関する処理が、この事業者アカウントから残高の不足分を貸与することにより実行されるようにすることで、事業者のアカウントに少なくとも基づいて決済を実現することができる。また、事業者のアカウントから残高の不足分を貸与してもらうことで、残高が不足している場合であっても適切に決済を行うことができる。