<法的事項の遵守>
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本開示に係る手法を実現するための実施形態について、図面を参照して説明する。
[システム構成]
図1は、本開示の一実施形態に係る通信システム1の構成の一例を示す図である。
図1に開示されるように、通信システム1では、ネットワーク30を介してサーバ10と、端末20(端末20A,端末20B,端末20C,・・・)と、銀行サーバ40(銀行サーバ40A,銀行サーバ40B,銀行サーバ40C,・・・)と、ATM50(ATM50A,ATM50B,ATM50C,・・・)とが接続される。
サーバ10は、ユーザが所有する端末20に、ネットワーク30を介して、所定のサービスを提供する。具体的には、限定ではなく例として、サーバ10は、端末20または端末20のユーザの預金残高照会、預金残高の引き出し、預け入れなどに関するサービスを提供する。
なお、ネットワーク30に接続される端末20の数は限定されない。
ネットワーク30は、1以上の端末20と、1以上のサーバ10と、1以上の銀行サーバ40と、1以上のATM50とを接続する役割を担う。すなわち、ネットワーク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を含むことができる。
端末20(端末20A,端末20B,端末20C,・・・)(限定ではなく、端末、情報処理装置の一例)は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末20は、限定ではなく例として、スマートフォン、携帯電話(フィーチャーフォン)、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA・(personal digital assistant)、電子メールクライアントなど)、ウェアラブル端末(メガネ型デバイス、時計型デバイスなど)、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末20は情報処理端末と表現されてもよい。
端末20A、端末20Bおよび端末20Cの構成は基本的には同一であるため、以下の説明においては、端末20について説明する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定ではなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応付けられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
サーバ10(限定ではなく、サーバ、情報処理装置、情報管理装置の一例)は、端末20に対して、所定のサービスを提供する機能を備える。サーバ10は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ10は、限定ではなく例として、サーバ装置、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ10は情報処理装置と表現されてもよい。サーバ10と端末20とを区別する必要がない場合は、サーバ10と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
[各装置のハードウェア(HW)構成]
通信システム1に含まれる各装置のHW構成について説明する。
(1)端末のHW構成
図1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、表示部24、マイク25、スピーカ26、カメラ27を備える。端末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とは、略同一の大きさおよび形状で対向して配置されていてもよい。
制御部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には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、ディスプレイ13を備える。サーバ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は、これらに限定されない。
(3)ATMの構成
ATM(automatic teller machine)50(限定ではなく、現金自動支払機の一例)は、制御部(CPU)、記憶部、カードリーダ、入出金機、入出力部、ディスプレイ、スピーカ、通信I/F(インタフェース)を備える。ATM50のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。
入出力部は、ATM50に対する各種操作を入力する装置により実現される。入出力部は、預金者からの入力を受け付けて、入力に係る情報を制御部に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部は、代表的にはタッチパネルまたはボタンで実現される。
ディスプレイは、代表的にはモニタ(限定ではなく例として、液晶ディスプレイやOELD)で実現される。ディスプレイは、制御部からの指示に従って、預金者に提供できるサービス(限定ではなく例として、入金、出金(払い戻し)、振込、通帳記帳など)の一覧、およびサービスの提供に必要な操作内容などを表示する。入出力部がタッチパネルの場合、入出力部とディスプレイとは、略同一の大きさおよび形状で対向して配置されていてもよい。スピーカは、操作の進行状況を報知する音声、および入出力部に対する操作に応答して発される反応音の出力に利用される。
カードリーダは、預金者によって挿入された、磁気ストライプを有するキャッシュカードから、その磁気ストライプに記録された内容を読み取り、読み取った内容を制御部へ伝達する。入出金機は、制御部からの指示に従って、ATM本体内に蓄積された現金をATM本体の現金取り出し口へ排出する。また、入出金機は、制御部からの指示に従って、現金投入口に投入された現金をATM本体の内部に蓄積する。なお、現金取り出し口と現金投入口とは、同じ装置によって実現してもよい。
なお、ATM50の制御部、記憶部および通信I/Fは、限定ではなく例として、サーバ10の制御部、記憶部および通信I/Fとそれぞれ同様とすることができるため、説明を省略する。また、カードリーダ、入出金機、入出力部、ディスプレイ、スピーカを備えるATM本体(不図示)と、制御部、記憶部、通信I/Fを備えるATM運用サーバ(不図示)とが、それぞれ別体として設置される構成であってもよいし、そのようにしなくてもよい。
(4)その他
銀行サーバ40のHW構成や、各機能部を構成する部品や回路等は、限定ではなく例として、サーバ10やATM50と同様に構成することができるため、説明を省略する。
サーバ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などのマークアップ言語などを用いて実装される。
<実施例>
近年、ネットワークサービスに関連するアプリケーション(アプリケーションソフトウェア)として、電子マネーによる電子決済用のアプリケーション(決済アプリケーション)、電子マネーの送金用のアプリケーション(送金アプリケーション)といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約した支払いアプリケーション等のアプリケーションが普及しつつあり、端末20のユーザが、これらのアプリケーションを用いて、電子マネーに関する各種のサービスを受けることが可能になってきている。
以下説明する実施例は、限定ではなく例として、端末20のユーザが銀行に口座(以下、「銀行口座」と称する。)を有しており、そのユーザが自身の銀行口座から所望の金額の現金をATM50に出金させる操作を端末20とATM50とに行うことで、ATM50から現金が出金されるサービス(ユーザがATM50から現金を引き出すサービス)(以下、「引き出しサービス」とも称する。)が提供される実施例である。以下では、引き出しサービスを提供する事業者のことを「引き出しサービスの事業者」とも称する。また、ユーザは、預金者と表現してもよいし、しなくてもよい。また、引き出しサービスによってATM50に現金を出金させることを「ATM出金」とも称する。
なお、引き出しサービスの事業者は、支払いアプリケーションの事業者や、サーバ10の事業者と表現してもよいし、しなくてもよい。また、預金者のアカウントは、預金者に関連付けられたアカウントとしてもよいし、預金者の端末20に関連付けられたアカウントとしてもよい。以下では、これらを包括的に「預金者のアカウント」とも称する。
また、本実施例では、支払いアプリケーション内で引き出しサービスを含む各種のサービスが提供されることとし、送金サービスの事業者によって、サーバ10が運用・管理されることとして説明する。以下では、一例として、支払いアプリケーションの名称を「Payment App」と称して図示・説明する。
また、本実施例では、限定ではなく例として、引き出しサービスの事業者と提携している銀行を、図1では「提携銀行B1」、「提携銀行B2」、・・・のように示している。
本実施例において、「電子マネー」とは、物理的貨幣と区別される電子的な貨幣であって、支払いアプリケーションにおいて管理される端末20または端末20のユーザが所有する電子的な貨幣である。電子マネーは、「電子貨幣」と表現してもよいし、しなくてもよい。
また、本実施例における「API」とは、限定ではなく例として、引き出しサービスに関する機能をサーバ10で利用可能とするために、銀行サーバ40等によって公開される、プログラムコンポーネントにデータを送信する際のデータ構造や、プログラムコンポーネントで処理を行う際の命令方法等が記述されたものである。限定ではなく例として、預金者の口座に関する情報を銀行サーバ40から受信したり、電子マネーの送金の命令を銀行サーバ40に送信したりするためのデータ構造や命令方法等がこれに含まれる。
<機能構成>
(1)サーバの機能構成
図2−1は、本実施例におけるサーバ10の制御部11により実現される機能の一例を示す図である。
制御部11は、主要な機能部として、限定ではなく例として、支払いアプリケーション管理処理部111を含む。
支払いアプリケーション管理処理部111は、記憶部15に記憶されている支払いアプリケーション管理処理プログラム151に従って、端末20で実行される支払いアプリケーションに関するデータ等を管理する支払いアプリケーション管理処理を実行する機能を有している。
支払いアプリケーション管理処理部111は、限定ではなく例として、残高照会サービスを提供・管理するための処理を実行する残高照会サービス管理処理部1111と、引き出しサービスを提供・管理するための処理を実行する引き出しサービス管理処理部1112とを機能部として含む。
残高照会サービスは、預金者の銀行口座の残高(以下、「銀行口座残高」と称する。)を、支払いアプリケーションを利用して照会させるためのサービスである。
引き出しサービスは、預金者の銀行口座残高を、支払いアプリケーションを利用してATM50から現金で引き出させる(出金させる)ためのサービスである。
残高照会サービス管理処理部1111は、限定ではなく例として、残高照会サービスによる情報の送受信を管理する。具体的には、残高照会サービス管理処理部1111は、限定ではなく例として、残高照会サービスにおいて、識別子によって特定される端末20または端末20のユーザのアカウントの指示によって、選択された銀行口座残高および取引履歴などの情報を、提携銀行が提供するAPIを介して銀行サーバ40から取得し、その情報を端末20へ送信する。
引き出しサービス管理処理部1112は、限定ではなく例として、引き出しサービスによる現金の引き出しを管理する。具体的には、引き出しサービス管理処理部1112は、限定ではなく例として、識別子によって特定される端末20または端末20のユーザのアカウントの指示によって、APIを介して、電子マネーの口座への振替(口座振替)を銀行サーバ40に依頼し、サーバ10からATM50へ引き出し(出金)金額に関する情報を送信してATM50から現金を出金させる。
図2−2は、本実施例におけるサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、サーバ10のメイン処理として実行されるサーバメイン処理プログラムの他、限定ではなく例として、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム151が記憶される。
支払いアプリケーション管理処理プログラム151は、残高照会サービス管理処理および引き出しサービス管理処理として実行される提携銀行サービス管理処理プログラム1511をサブルーチンプログラムとして含む。
また、記憶部15には、支払いアプリケーションユーザ登録データ153と、提携銀行データ154と、ユーザ管理データベース155とが記憶される。
支払いアプリケーションユーザ登録データ153は、支払いアプリケーションによるサービスを利用する端末20または端末20のユーザの登録データであり、そのデータ構成の一例を図2−3に示す。
支払いアプリケーションユーザ登録データ153には、限定ではなく例として、ユーザ名と、端末電話番号と、端末メールアドレスと、支払いアプリケーションIDと、認証パスワードと、その他登録情報とが関連付けて記憶される。
ユーザ名は、支払いアプリケーションによるサービスを利用する端末20のユーザの名称であり、限定ではなく例として、端末20のユーザが支払いアプリケーションを最初に利用する際に登録する名称が記憶される。
端末電話番号は、このユーザ名のユーザの端末20の電話番号であり、限定ではなく例として、端末20のユーザが支払いアプリケーションを利用する際に最初に登録する端末20の電話番号が記憶される。
端末メールアドレスは、このユーザ名のユーザの端末20のメールアドレスであり、限定ではなく例として、端末20のユーザが支払いアプリケーションを利用する際に最初に登録する端末20のメールアドレスが記憶される。
端末電話番号や端末メールアドレスは、端末20を識別するための識別情報(以下、「端末識別情報」とも称する。)の一例である。
支払いアプリケーションIDは、端末20または端末20のユーザを識別するための識別情報として機能するIDであり、サーバ10によって、支払いアプリケーションを利用する端末20毎または端末20のユーザ毎に固有に設定されるIDである。
認証パスワードは、このユーザ名のユーザの端末20において、支払いアプリケーションの機能として設けられた各種の機能を利用する際に実行する認証処理で、端末20に入力を要求する認証用のパスワードであり、限定ではなく例として、ユーザによって設定されたパスワードが記憶される。
その他登録情報は、このユーザ名のユーザのその他の登録情報であり、限定ではなく例として、支払いアプリケーションにおいてユーザが使用するアイコンの画像データであるユーザアイコン画像等の情報がこれに含まれる。
なお、上記の各種のユーザ情報は、サーバ10が提供可能な他のアプリケーションと支払いアプリケーションとで共通のユーザ情報としてサーバ10で記憶・管理するようにしてもよいし、別のユーザ情報としてサーバ10で記憶・管理するようにしてもよい。
提携銀行データ154は、提携銀行の管理データであり、そのデータ構成の一例を図2−4に示す。
提携銀行データ154には、限定ではなく例として、提携銀行IDと、提携銀行名と、提携銀行サーバURIと、その他提携銀行情報とが関連付けて記憶される。
提携銀行IDには、提携銀行を識別するための識別情報として機能するIDであって、サーバ10によって、提携銀行毎に固有に設定されるIDが記憶される。
提携銀行名には、前述した提携銀行の名称(限定ではなく例として、提携銀行の商号、愛称または通称など)が記憶される。
提携銀行サーバURIには、提携銀行が管理する銀行サーバ40へのアクセス方法およびアクセス先を含むURI(Uniform Resource Identifier)が記憶される。
その他提携銀行情報は、この提携銀行IDを有する提携銀行のその他の登録情報であり、限定ではなく例として、支払いアプリケーションにおいて使用される、提携銀行を記号化したアイコンの画像データである提携銀行アイコン画像、およびその提携銀行のキャッシュカードの外観を模した画像データであるカードデザイン画像等の情報がこれに含まれる。
以下では、カードデザイン画像には、大きいサイズの画像と小さいサイズの画像との2種類があることとして説明する。便宜的に、大きいサイズの画像を「大サイズキャッシュカード画像」と称し、小さいサイズの画像を「小サイズキャッシュカード画像」と称する。
本実施例において、サーバ10は、端末20または端末20のユーザの電子マネーを、電子マネーの口座(以下、「電子マネー口座」と称する。)によって管理する。電子マネー口座の電子マネーの残高を「電子マネー口座残高」と称する。
本実施例では、電子マネー口座の電子マネー(より具体的には、電子マネー口座残高)の入出金として、「チャージ」、「引き出し」および「振込」の3つの入出金があることとして説明する。
「チャージ」は、提携銀行であって、端末20のユーザが利用する銀行としてサーバ10に登録されている銀行の銀行サーバ40が管理する銀行口座から、サーバ10へ現金の口座振替を行い、その結果、電子マネー口座の電子マネー(具体的には、電子マネー口座残高)が補充(増額)されることを意味する。
サーバ10で管理されるユーザの電子マネー口座は、そのユーザの1以上の銀行口座と関連付けることが可能であり、端末20のユーザは、限定ではなく例として、銀行口座残高を使用して、電子マネー口座への電子マネーのチャージ(入金)を行うことができる。限定ではなく例として、ユーザにより、端末20を用いて、電子マネーのチャージ額として「10,000円」を選択する操作が行われると、サーバ10は、そのユーザの電子マネー口座残高に「10,000円」を加算する。
「引き出し」は、提携銀行であって、端末20のユーザが利用する銀行としてサーバ10に登録されている銀行の銀行サーバ40が管理する銀行口座の銀行口座残高を用いて、その提携銀行またはその提携銀行とは異なる銀行が管理するATM50から現金を出金させる機能である。本実施例における引き出しは「ATM引き出し」や「ATM出金」と表現することもできる。
電子マネーを介して引き出しを実現するフローの概要を説明する。限定ではなく例として、ユーザにより、端末20を用いて、そのユーザが利用する銀行口座から「10,000円」を引き出す操作が行われると、サーバ10は、銀行サーバ40と通信を行って、そのユーザの銀行口座残高から「10,000円」を減算させるとともに、そのユーザの電子マネー口座残高に「10,000円」を一時的に加算させる。そして、サーバ10は、ATM50と通信を行って、ATM50に現金の1万円を払い出させ、そのユーザの電子マネー口座残高から「10,000円」を減算する。
「振込」は、提携銀行であって、端末20のユーザが利用する銀行としてサーバ10に登録されている銀行の銀行サーバ40が管理する銀行口座から、その銀行口座と異なる銀行口座であって、サーバ10に登録されている提携銀行の銀行口座へ電子マネーを介して資金を移動させる機能である。
電子マネーを介して振込を実現するフローの概要を説明する。限定ではなく例として、ユーザにより、端末20を用いて、そのユーザが利用する銀行の口座から対象の口座へ「10,000円」を振り込む操作が行われると、サーバ10は、銀行サーバ40と通信を行って、そのユーザの銀行口座残高から「10,000円」を減算させるとともに、そのユーザの電子マネー口座残高に「10,000円」を一時的に加算させる。そして、サーバ10は、対象の口座を有する提携銀行が管理する銀行サーバ40と通信を行って、その対象の口座残高に「10,000円」を加算させるとともに、そのユーザの電子マネー口座残高から「10,000円」を減算する。
なお、銀行口座で管理される貨幣は、限定ではなく例として、デジタル情報で管理される貨幣という意味で、デジタル貨幣(デジタル通貨)と表現することができる。
ユーザ管理データベース155は、支払いアプリケーションユーザ登録データ153に登録されているユーザに関する管理データを蓄積したデータベースであり、そのデータ構成の一例を図2−5に示す。
ユーザ管理データベース155には、支払いアプリケーションユーザ登録データ153に記憶されている支払いアプリケーションIDごとの管理データとしてユーザ管理データが記憶される。
各ユーザ管理データには、限定ではなく例として、支払いアプリケーションIDと、電子マネー口座残高と、提携銀行認証データとが記憶される。
電子マネー口座残高は、この支払いアプリケーションIDのユーザの電子マネーの口座の残高の金額である。
提携銀行認証データには、限定ではなく例として、銀行IDと、銀行名と、アクセストークンとが関連付けて記憶される。
銀行IDには、この支払いアプリケーションIDのユーザが口座を有する提携銀行の提携銀行IDであって、そのユーザの登録操作によって登録されたものが記憶される。この登録操作の詳細については、後述する。
銀行名には、上記の銀行IDを有する提携銀行の名称(限定ではなく例として、提携銀行の商号、愛称または通称など)が記憶される。
アクセストークンは、上記の銀行IDを有する提携銀行が管理する銀行サーバ40によって発行された認証用のデータである。本実施例では、サーバ10は、銀行サーバ40から与えられたアクセストークンによって、この支払いアプリケーションIDのユーザの口座残高の情報を取得する処理、およびその提携銀行の口座から電子マネー口座へ電子マネーを送金する処理を、その銀行サーバ40との間で行うことが可能となる。
なお、1つの銀行IDに対して1つのアクセストークンが関連付けられる構成に限らず、1つの銀行IDに対して2つ以上のアクセストークンが関連付けられる構成であってもよいし、そのようにしなくてもよい。1つの銀行IDに対して2つ以上のアクセストークンが関連付けられる場合、限定ではなく例として、1つの銀行IDに対して、口座残高の照会用のアクセストークンと、電子マネーの振替用のアクセストークンとを関連付けるように、用途ごとにアクセストークンを設定することができる。これにより、サーバ10の銀行サーバ40に対するアクセスを用途ごとに許可させることができる。また、サーバ10による口座残高の照会の許可及び不許可をユーザに選択させることができるとともに、サーバ10による電子マネーの振替の許可及び不許可をユーザに選択させることができる。
(2)端末の機能構成
図2−6は、本実施例における端末20の制御部21により実現される機能の一例を示す図である。
制御部21は、主要な機能部として、限定ではなく例として、支払いアプリケーション処理部211を含む。
支払いアプリケーション処理部211は、記憶部28に記憶されている支払いアプリケーションプログラム282に従って、支払いアプリケーションの各種の機能に基づく処理を行う機能を有している。
図2−7は、本実施例における端末20の記憶部28に記憶される情報の一例を示す図である。
記憶部28には、限定ではなく例として、端末メイン処理として実行される端末メイン処理プログラム281と、支払いアプリケーション処理として実行される支払いアプリケーションプログラム282と、支払いアプリケーションデータ283とが記憶される。
文中の支払いアプリケーションとは、この支払いアプリケーションプログラム282を意味する。なお、支払いアプリケーションは、メッセージングサービス(MS)の機能を有さない単体のアプリケーションとして提供されても構わないし、MSの機能を有する複合的なアプリケーションとして提供されても構わない。
支払いアプリケーションデータ283は、支払いアプリケーションの各種の機能を実現するためのデータであり、限定ではなく例として、支払いアプリケーションIDのデータである支払いアプリケーションIDデータ2831がこれに含まれる。
<表示画面例>
本実施例におけるカード登録サービス、残高照会サービスおよび引き出しサービス等について表示画面例を参照して説明する。また、本実施例では、端末20が、表示部24として機能する縦長のディスプレイを有するスマートフォンである場合について説明する。
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置される。アイコン、ボタン、アイテムまたは入力欄などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによってタッチされた場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。以下では、ディスプレイにその要素が表示された領域と対向するタッチパネルの領域のことを、対向領域とも称する。つまり、対向領域は、受け付け手段として機能する。
(1)端末の表示画面
図3−1は、端末20で実行される支払いアプリケーションにおいて表示部24に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、支払いアプリケーションを起動する操作がユーザによってなされ、支払いアプリケーションが起動した場合に表示される画面の一例である。
本実施例では、このアプリケーション画面には、支払いアプリケーションのアプリケーション名である「Payment App」が最上段のタイトルバーに表示される。タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置が表示され、具体的には、現在実行中の最上位のメニューである「ウォレット メインメニュー」が表示される。「ウォレット メインメニュー」の画面には、「Payment App」によって管理される電子マネー口座残高として「¥25,000」が表示され、その下に、「ウォレット メインメニュー」から選択可能なサブメニューである「入金」、「コード支払い」、「コードリーダー」、「クーポン」、「マイカード」および「送金」にそれぞれ対応する6つのアイコンが表示される。
図3−2は、図3−1に示すアプリケーション画面において「マイカード」のアイコンがタッチされた場合に表示されるマイカード画面の一例を示す図である。
タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「マイカード」が表示される。また、「マイカード」の右側には、ソート用のアイコン(以下、「ソートアイコン」と称する。)が表示される。ここでは、初期状態として、この端末20のユーザのアカウントには、キャッシュカードについてのマイカードが1枚も登録されていない状態である。
以下では、キャッシュカードについてのマイカードのことを「仮想キャッシュカード」とも称する。このため、「マイカード」の下側には、ユーザに対する操作案内として「+マークタップでカードを追加」の説明文が表示され、その説明文の下側には、仮想キャッシュカードのアイコンが表示されない代わりに、仮想キャッシュカードを新たに登録するための「+」のマークを有するアイコンが表示される。以下では、この「+」のマークを有するアイコンのことを「マイカード追加用アイコン」と称する。
なお、2枚以上の仮想キャッシュカードが登録されている場合、ソートアイコンがタッチされると、その仮想キャッシュカードのアイコンの順番を並べ替えることが可能となる。
図3−3は、図3−2に示すマイカード画面においてマイカード追加用アイコンがタッチされた場合に表示されるカード追加画面の一例を示す図である。
タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「カードを追加」が表示される。また、「カードを追加」の右側には、カメラのアイコンとソートアイコンとが表示される。「カードを追加」の下側には、ユーザに対する操作案内として「追加するカードを選んでください」の説明文が表示され、その説明文の下側には、追加可能なキャッシュカードを発行する提携銀行のリストが表示される。このリストには、ユーザによって選択可能なように縦方向に並べられた複数の列アイテムが含まれ、その列アイテムには、提携銀行の提携銀行アイコン画像を含むアイコンと、そのアイコンの右側に位置する、その提携銀行の名称の文字列とが表示される。本実施例では、そのリストにおいて、「PP銀行」の列アイテム、「QQ銀行」の列アイテム、「RR銀行」の列アイテムおよび「SS銀行」の列アイテムなどが、限定ではなく例として、提携銀行名のアルファベット順に上から並べられる。
「カードを追加」の右側に位置するソートアイコンがタッチされると、リストにおける列アイテムの順番を並べ替えることが可能となる。限定ではなく例として、ソートアイコンがタッチされると、リストにおける列アイテムの順番が、アルファベットの逆順に上から並べられる。
なお、ソートの指標は、アルファベットの他に、五十音および登録日時などの他の指標に変更することが可能な構成にしてもよいし、そのようにしなくてもよい。
「カードを追加」の右側に位置するカメラのアイコンがタッチされると、端末20のカメラ27が使用可能となる。そして、ユーザが自身のキャッシュカードをカメラ27で撮像すると、端末20は、撮像結果に基づき、そのキャッシュカードに刻印された銀行名または図柄に基づき、そのキャッシュカードを発行した提携銀行を認識する。そして、端末20は、限定ではなく例として、その提携銀行の列アイテムだけをリストに表示する。これにより、ユーザは、カメラ27で撮像したキャッシュカードを発行した提携銀行の列アイテムをリストに簡易に表示させることができる。特に、リストに非常に多くの提携銀行が含まれる場合に、リストから所望の提携銀行を手動で選ばなくて済むため、ユーザによる目的の列アイテムの探索時間を省略することができる。
なお、カメラ27として、端末20の機能として備えられたOS標準のカメラアプリを用いるのではなく、支払いアプリケーションの機能として備えられたカメラ(アプリケーションカメラ)を用いるようにしてもよいし、そのようにしなくてもよい。以下同様である。
図3−4は、図3−3に示すカード追加画面において「QQ銀行」の列アイテムがタッチされた場合に表示されるカード情報入力画面の一例を示す図である。
タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「カード情報を入力」が表示される。また、「カードを追加」の右側には、カメラのアイコンが表示される。「カード情報を入力」の下側には、ユーザに対する操作案内として「必要事項を入力してください」の説明文が表示され、その説明文の下側には、「カードを追加」の画面でユーザが選択した提携銀行の名称(限定でなく例として、QQ銀行)およびアイコンが表示される。
提携銀行の名称およびアイコンの下側には、残高照会サービスおよび引き出しサービスなどをその提携銀行から受けるために入力が必要な項目のリストが表示される。以下では、このリストのことを「入力リスト」とも称する。
入力リストには、限定ではなく例として、項目ごとに縦方向に並べられた7つの列アイテムが含まれ、その列アイテムには、項目と、その項目の右側に位置する、ヘルプ用のアイコンと、そのアイコンの右側に位置する入力欄とが含まれる。本実施例では、「店番号」、「口座種別」、「口座番号」、「姓」、「名」、「暗証番号」および「生年月日」を項目としてそれぞれ含む7つの列アイテムが、上から順に表示される。図3−4には、7つの列アイテムの入力欄にユーザによってそれぞれ値が入力された状態が示される。入力リストの下側には、「認証」の文字列を含む認証ボタンが表示される。限定ではなく例として、ユーザが認証ボタンをタッチすることで、入力リストに入力された情報に基づき、銀行サーバ40による認証が実行される。
「カード情報を入力」の右側に位置するカメラのアイコンがタッチされると、端末20のカメラ27が使用可能となり、ユーザが自身のキャッシュカードをカメラ27で撮像すると、端末20は、撮像結果に基づき、そのキャッシュカードに刻印された数字および文字などから、店番号、口座種別、口座番号、姓および名を認識する。そして、端末20は、限定ではなく例として、認識した店番号、口座種別、口座番号、姓および名を入力リストにおける対応の入力欄にそれぞれ書き込む。これにより、そのキャッシュカードの口座についての情報を入力リストに表示させることができるので、ユーザによる入力操作の負担を軽減することができる。
こうした個人情報を入力する代わりに、提携銀行のオンラインバンキングのIDとパスワードを入力する画面を表示するように構成しても構わない。この場合、図3−3に示すカード追加画面において「QQ銀行」の列アイテムがタッチされると、予め提携銀行のウェブサイトやアプリケーションによって登録されたオンラインバンキングのIDとパスワードを入力する画面が表示部24に表示される。ユーザがIDとパスワードを入力してログインボタンを押下すると、認証処理が行われる。
なお、図3−3に示す「カードを追加」のサブメニューを実行中にキャッシュカードを撮像した場合、端末20は、その撮像結果に基づき、そのキャッシュカードに刻印された数字および文字などから、店番号、口座種別、口座番号、姓および名を認識し、「カード情報を入力」のサブメニューを実行中に、認識したこれらの情報を、対応の各入力欄にそれぞれ自動的に書き込む構成にしてもよいし、そのようにしなくてもよい。
図3−5は、図3−4に示すカード情報入力画面において認証ボタンがタッチされた場合に表示されるマイカード画面の一例を示す図である。
タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「マイカード」が表示される。図3−5は、図3−2に示すマイカード画面と同様の、「マイカード」のサブメニューを実行中のアプリケーション画面である。ここでは、「QQ銀行」の仮想キャッシュカードに加えて、「RR銀行」の仮想キャッシュカードが登録されていることとする。このため、図3−2に示すマイカード画面と異なり、「+マークタップでカードを追加」の説明文の下側には、QQ銀行の小サイズキャッシュカード画像および提携銀行名を含む、「QQ銀行」の仮想キャッシュカードのアイコンと、RR銀行の小サイズキャッシュカード画像および提携銀行名を含む、「RR銀行」の仮想キャッシュカードのアイコンと、マイカード追加用アイコンと、が表示される。本実施例では、これらの仮想キャッシュカードがアルファベット順にZ型パターンで並べられる。
「マイカード」の右側に位置するソートアイコンがタッチされると、登録されている仮想キャッシュカードの順番を並べ替えることが可能となる。限定ではなく例として、ソートアイコンがタッチされると、「QQ銀行」の仮想キャッシュカードのアイコンと、「RR銀行」の仮想キャッシュカードのアイコンとがアルファベットの逆順にZ型パターンで並べられる。
なお、ソートの指標は、アルファベットの他に、五十音および登録日時などの他の指標に変更することが可能な構成にしてもよいし、そのようにしなくてもよい。
このように、登録された複数の銀行口座がマイカード画面に表示されるため、登録された複数の金融機関の口座をユーザが容易に把握できるようにすることができる。
図3−6は、図3−5に示すマイカード画面において「QQ銀行」の仮想キャッシュカードのアイコンがタッチされた場合に表示される口座詳細画面の一例を示す図である。
タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「QQ銀行」が表示される。「QQ銀行」の下側には、QQ銀行についての仮想キャッシュカードの画像が表示される。この画像には、キャッシュカードを模した大サイズキャッシュカード画像の中に、店番号、口座番号、銀行の名称、口座種別、姓および名、ならびに口座残高の額をそれぞれ示す文字列が含まれる。
また、大サイズキャッシュカード画像の右側上部には、口座情報の再読み込みを行う円形のアイコンが含まれている。
なお、図3−6において仮想キャッシュカードの画像がユーザによってタッチされると、端末20のクリップボード(アプリケーション間で共有可能な記憶領域)へ店番号、口座番号、口座残高等の情報がコピーされるようにしてもよいし、しなくてもよい。
仮想キャッシュカードの画像の下側には、取引履歴表示ボックス、提供サービス表示ボックスおよびお知らせ表示ボックスが上から順に表示される。取引履歴表示ボックスには、例えば直近の3つの取引内容(取引履歴)として、限定ではなく例として、「振込」、「預入」および「引出」が上側から下側へ時系列順に表示される。また、3つの取引内容の下側には、口座残高の時系列推移のグラフが表示される。
なお、「振込」、「預入」および「引出」の全てを表示させるのではなく、これらのうちの少なくとも1つを表示させるようにしてもよいし、そのようにしなくてもよい。
また、取引履歴表示ボックスにおいて直近の3つの取引内容を表示する構成に限らず、直近の2つ以下または直近の4つ以上の取引内容を表示する構成であってもよいし、そのようにしなくてもよい。
このように、対象金融機関の口座への入金の履歴と、対象金融機関の口座からの出金の履歴とのうちの少なくともいずれかがに表示されるため、対象金融機関の口座の取引履歴をユーザが確認できるようにすることができる。
提供サービス表示ボックスには、提携銀行におけるユーザの銀行口座からこの支払いアプリケーションIDのユーザの電子マネー口座へ電子マネーを送金(チャージ)するチャージサービスを実行するための「チャージボタン」と、引き出しサービスを実行するための「ATM出金ボタン」と、提携銀行におけるユーザの銀行口座から、この支払いアプリケーションIDのユーザの電子マネー口座を経由して他の銀行の銀行口座へ電子マネーを送金する振込サービスを実行するための「振込ボタン」とが上から順に表示される。
本実施例では、ATM出金ボタンをタッチした場合に行われる引き出しサービスでは、ATM50から出金可能な現金は、仮想キャッシュカードの画像内に表示される口座残高を出金の上限とする。つまり、ユーザによって選択された銀行の口座残高が表示部24に表示され、この口座残高を出金の上限とする出金指示が入出力部23で受け付けられる。
これにより、対象金融機関の口座残高をユーザに確認させることができるとともに、その口座残高を出金の上限とする出金を現金自動支払機に行わせることができる。
なお、引き出しサービスに貸付サービスを追加し、口座残高を超える現金をATM50から出金可能にしてもよいし、しなくてもよい。
また、上記の各ボタンの左側には、限定ではなく例として、そのボタンに応じたサービスを説明するための図柄が表示される。具体的には、チャージボタンの左側には、提携銀行におけるユーザの銀行口座からこの支払いアプリケーションIDのユーザの電子マネー口座へ電子マネーが移動する様子を示す図柄が表示される。
このように、チャージボタンの操作を不要として、ATM出金ボタンを操作するだけで、電子マネーのチャージと、チャージされた金額のATM50からの出金を実現するための画面が表示部24に表示されるため、ユーザは別途チャージ指示を行うことなく、出金指示を行うだけで、チャージされた対象金額を現金自動支払機から簡単に出金させることができる。
ここで、ATM出金ボタンの左側には、提携銀行におけるユーザの銀行口座から直接に現金が引き出される様子を示す図柄が表示される。但し、実際には、上述したようにユーザの銀行口座から出金額相当がユーザの電子マネー口座にチャージされ、その電子マネー口座からその出金額相当の電子マネーがATM50へ送金されてATM50から現金が出金されるが、この図柄では、ユーザの銀行口座からの電子マネーがユーザの電子マネー口座に送金されることが秘匿される。
これにより、実際には電子マネー口座を経由しているにも関わらず、ユーザは、それを意識することなく、自身の銀行口座の預金をATM50から現金で引き出すことができる。
また、チャージ操作が入出力部23によって受け付けられ、ATM出金を受け付けるためのボタンとして、チャージボタンとは異なるボタンが表示部24に表示されるため、出金とチャージは異なる指示によって行うことをユーザに認識させることができる。
また、銀行口座を選択するためのマイカード画面(限定ではなく、第1画面の一例)が表示部24に表示されるとともに、マイカード画面において選択された銀行口座の口座情報と、少なくともATM出金ボタンとを含む口座詳細画面(限定ではなく、第2画面の一例)が表示部24に表示されるため、対象金融機関の口座の選択と、口座情報の確認・出金指示とを一連の操作によって実現させることができる。
お知らせ表示ボックスには、提携銀行(限定ではなく例として、QQ銀行)および引き出しサービスの事業者などからの通知事項が表示される。
図3−7は、図3−6に示す口座詳細画面においてATM出金ボタンがタッチされた場合に表示される出金額入力画面の一例を示す図である。
タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「出金額入力」が表示される。「出金額入力」の下側には、ユーザに対する操作案内として「出金額を入力してください」の説明文が表示され、その説明文の下側には、1000円未満の引き出しができない旨の注意事項と、口座種別および口座残高と、出金額(限定ではなく、対象金額の一例)の入力欄と、が上から順に表示される。その入力欄の下側には、クリアボタンと、確認ボタンとが横方向に並んで表示される。クリアボタンがタッチされると、出金額の入力欄に入力された金額が消去される。確認ボタンがタッチされると、出金額の入力欄に入力された金額によって引き出しサービスが進行する。
図3−8は、図3−7に示す出金額入力画面において、出金額の入力欄に「10,000円」が入力された状態で確認ボタンがタッチされた場合に表示されるコード読み取り画面の一例を示す図である。
タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「二次元コード読み取り」が表示される。「二次元コード読み取り」の下側には、ユーザに対する操作案内として「二次元コードを画面内のフレームにあわせてください」の説明文が表示され、その説明文の下側には、出金額(限定ではなく例として、10,000円)が表示される。「二次元コード読み取り」のサブメニューの実行中では、端末20のカメラ27が使用可能となり、カメラ27の撮像結果である画像と、枠(フレーム)とが上記の出金額の下側に表示される。
ユーザは、ATM50のディスプレイに表示された二次元コードの画像が端末20のカメラ27の視野内に収まるように端末20の位置および向きを調整し、その二次元コードの画像がカメラ27によって撮像され、その撮像結果である画像が上記の枠内に収まるように、端末20の位置および向きを微調整する。この二次元コードには、サーバ10が発行した端末認証コードが格納される。端末認証コードの詳細については、後述する。
端末20は、上記の枠内に二次元コードの画像が収まると、二次元コードの画像を分析し、その二次元コードの画像に格納された端末認証コードを取得する。端末20は、限定ではなく例として、端末認証コードの取得に成功すると、電子音を発したり、端末20本体を振動させたり、表示部24に表示される撮像結果の動画を静止画にしたりすることで、認証コードの取得に成功したことをユーザに報知する。ユーザは、端末20からの報知を認識すると、ATM50の現金取り出し口の扉が開口するまで待機し、現金取り出し口の扉が開口すると、現金取り出し口の内部に排出された現金(限定ではなく例として、10,000円)を受け取る。ATM50は、限定ではなく例として、ユーザが現金を受け取ると、現金取り出し口の扉を閉じる。
図3−9は、ATM50からの現金の引き出しが終了した後に表示される口座詳細画面の一例を示す図である。
タイトルバーの下側には、「Payment App」の階層メニューにおける現在位置として、現在実行中のサブメニューである「QQ銀行」が表示される。図3−9は、図3−6に示す口座詳細画面と同様の、「QQ銀行」のサブメニューを実行中のアプリケーション画面である。ここでは、図3−6に示す口座詳細画面と異なる部分について説明する。
「QQ銀行」の下側に表示されるQQ銀行についての仮想キャッシュカードの画像には、元々の口座残高の額(限定ではなく例として、図3−6に示す100,000円)から出金額(限定ではなく例として、10,000円)を差し引いた額(限定ではなく例として、90,000円)の文字列が口座残高の額として含まれる。
仮想キャッシュカードの画像と取引履歴表示ボックスとの間には、確認事項表示ボックスが表示される。確認事項表示ボックスには、先刻行われた取引内容が表示される。本実施例では、ATMから現金の引き出しがあったことと、その出金額と、出金後の口座残高とが確認事項表示ボックスに表示される。なお、確認事項表示ボックスは、そのボックス内の右上の×印を有するアイコンをタッチすることで消去される。
取引履歴表示ボックスの内容は、図3−6に示す取引履歴表示ボックスと比べて、先刻行われた現金の引き出しについての取引内容によって更新される。具体的には、限定ではなく例として、直近の3件の取引履歴のみが表示されるため、図3−6に示す取引履歴表示ボックスにおける最下段の「引出」が消去されるとともに、最上段の「振込」および中段の「預入」が、それぞれ中段および最下段に移動して表示される。そして、先刻行われた現金の引き出しについての取引内容が最上段に追加される。また、口座残高の時系列推移のグラフは、先刻行われた現金の引き出し結果が反映されて更新される。
提供サービス表示ボックスの内容は、図3−6に示す提供サービス表示ボックスと同様であるが、確認事項表示ボックスが表示されたため、提供サービス表示ボックスの上側の一部だけが表示部24に表示される。
<処理>
図4−1〜図4−4は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。
これらの図では、左側から順に、端末20の制御部21が実行する端末メイン処理、サーバ10の制御部11が実行する支払いアプリケーション管理処理、銀行サーバ40の制御部(不図示)が実行する銀行サーバメイン処理の一例をそれぞれ示している。
なお、図4−3および図4−4には、銀行サーバメイン処理の右側に、ATM50の制御部(不図示)が実行するATMメイン処理の一例をさらに示している。
フローチャートの各ステップは、限定ではなく例として、それぞれの装置のプロセッサが記憶部からプログラムを読み出して実行することにより実現される。
なお、以下説明するフローチャートは、本開示の手法を実現するための処理の手順を例示したものに過ぎない。このため、本開示の手法を実現するための処理は、以下説明するフローチャートに従って実行される処理に限定されず、一部のステップを省略したり、他のステップを追加したりすることも可能である。
最初に、例えば図3−1に示すアプリケーション画面が端末20の表示部24に表示された状態で、端末20のユーザが「マイカード」のアイコンをタッチする操作を行うと、端末20の支払いアプリケーション処理部211は、入出力部23がその操作を受けたことを認識する。そして、支払いアプリケーション処理部211は、記憶部28に記憶された支払いアプリケーションIDデータ2831から読み出した支払いアプリケーションIDを含み、登録済みのマイカードの一覧を要求する旨を含むマイカード一覧要求情報を、通信I/F22によって(通信I/F22を介して)サーバ10へ送信する(A110)。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によって端末20からマイカード一覧要求情報を受信すると、ユーザ管理データベース155のうちの、マイカード一覧要求情報に含まれる支払いアプリケーションIDが記憶されているユーザ管理データから、提携銀行認証データに含まれる銀行IDを取得する。
ここでは、上記のユーザ管理データにおける提携銀行認証データに銀行IDなどが登録されていないこととする。この場合、支払いアプリケーション管理処理部111は、登録された提携銀行がない旨を含むマイカード一覧情報を、通信I/F14によって端末20へ送信する。
なお、上記のユーザ管理データにおける提携銀行認証データに銀行IDなどが登録されている場合、支払いアプリケーション管理処理部111は、提携銀行データ154から、その銀行IDに関連付けられた、「提携銀行名」と「その他提携銀行情報」に含まれる小サイズキャッシュカード画像とを取得し、その銀行IDと、提携銀行名と、小サイズキャッシュカード画像とを含むマイカード一覧情報を、通信I/F14によって端末20へ送信する(B110)。
端末20の支払いアプリケーション処理部211は、通信I/F22によってサーバ10からマイカード一覧情報を受信すると、マイカード一覧情報を表示部24に表示させる(A120)。具体的には、限定ではなく例として、支払いアプリケーション処理部211は、限定ではなく例として、マイカード一覧情報に基づき、登録された提携銀行がないことを認識し、図3−2に例示したようなマイカード画面を表示部24に表示させる。
次いで、端末20のユーザが、マイカード追加用アイコンをタッチする操作を行うと、端末20の支払いアプリケーション処理部211は、入出力部23がその操作を受けたことを認識する。以下では、端末20のユーザがこれから登録し、利用しようとする提携銀行のことを「追加対象提携銀行」とも称する。そして、支払いアプリケーション処理部211は、読み出した支払いアプリケーションIDを含み、登録可能なマイカードの一覧を要求する旨を含むマイカード追加要求情報を、通信I/F22によってサーバ10へ送信する(A130)。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によって端末20からマイカード追加要求情報を受信すると、ユーザ管理データベース155のうちの、マイカード追加要求情報に含まれる支払いアプリケーションIDが記憶されているユーザ管理データを読み出す。そして、支払いアプリケーション管理処理部111は、提携銀行データ154に含まれる提携銀行IDのうち、そのユーザ管理データに登録されていない銀行IDを特定する。以下では、その銀行IDを「追加対象銀行ID」とも称する。ここでは、上記のように、そのユーザ管理データには銀行IDが登録されていないため、提携銀行データ154に含まれる提携銀行IDのすべてが追加対象銀行IDとなる。支払いアプリケーション管理処理部111は、提携銀行データ154から、追加対象銀行IDに関連付けられた提携銀行名と、追加対象銀行IDに関連付けられたその他提携銀行情報に含まれる提携銀行アイコン画像とを取得し、追加対象銀行IDと、取得した提携銀行名と、取得した提携銀行アイコン画像とを含む追加カード一覧情報を、通信I/F14によって端末20へ送信する(B120)。
端末20の支払いアプリケーション処理部211は、通信I/F22によってサーバ10から追加カード一覧情報を受信すると、追加カード一覧情報の内容を表示部24に表示させる。具体的には、支払いアプリケーション処理部211は、限定ではなく例として、追加カード一覧情報に基づき、図3−3に例示したようなカード追加画面を表示部24に表示させる。
端末20のユーザが、例えば、追加対象提携銀行のアイコンおよび名称が含まれた列アイテムをタッチする操作を行うと、端末20の支払いアプリケーション処理部211は、入出力部23がその操作を受けたことを認識し、ユーザの操作結果および追加カード一覧情報に基づき、ユーザによって選択された提携銀行の名称に関連付けられた提携銀行IDを特定する(A140)。
A140の後、支払いアプリケーション処理部211は、読み出した支払いアプリケーションIDと、特定した提携銀行IDを含む追加カード選択情報を、通信I/F22によってサーバ10へ送信する(A150)。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によって端末20から追加カード選択情報を受信すると、提携銀行データ154から、追加カード選択情報に含まれる提携銀行IDに関連付けられた提携銀行サーバURIを取得する。そして、支払いアプリケーション管理処理部111は、その提携銀行サーバURIを含む銀行サーバ情報を、通信I/F14によって端末20へ送信する(B130)。
端末20の支払いアプリケーション処理部211は、通信I/F22によってサーバ10から銀行サーバ情報を受信すると、図3−4に例示したような、例えば「口座番号」等の認証(認可)に必要な情報の入力を端末20のユーザに促すカード情報入力画面を表示部24に表示させる。ユーザが認証(認可)に必要な情報を入力し、認証ボタンをタッチする操作を行うと、支払いアプリケーション処理部211は、入出力部23がその操作を受けたことを認識する。その後、端末20とサーバ10と銀行サーバ40との間で認証システム認可登録処理が行われる。
本実施例では、認証システム認可登録処理は、限定ではなく例として、OAuthの規格に従って行われる。具体的には、支払いアプリケーション処理部211は、限定ではなく例として、ユーザによって入力された、「口座番号」、「暗証番号」等の各値を含む認可要求情報を、通信I/F22によって、銀行サーバ情報に含まれる提携銀行サーバURIをアクセス先として銀行サーバ40に送信する(A160)。
銀行サーバ40の制御部は、通信I/Fによって端末20から認可要求情報を受信すると、認可要求情報に基づき端末20のユーザが正当であるか否かを判定する認可判定処理を実行する(C110)。具体的には、銀行サーバ40の記憶部には、限定ではなく例として、銀行サーバ40を管理する銀行に口座を有する預金者に関する管理データを蓄積した口座管理データベースが記憶される。口座管理データベースには、オンラインバンキングのIDやパスワードといった認証情報に加え、預金者ごとの管理データとして口座管理データが含まれる。各口座管理データには、限定ではなく例として、預金者の口座の店番号、口座種別、口座番号、口座残高および取引履歴、その預金者の姓、名および生年月日、ならびにその預金者によって設定された暗証番号が関連付けて記憶される。
銀行サーバ40の制御部は、限定ではなく例として、銀行サーバ40の記憶部に記憶されている口座管理データベースから、認可要求情報に含まれる店番号、口座種別および口座番号が含まれる口座管理データを検索する。そして、銀行サーバ40の制御部は、限定ではなく例として、その店番号、口座種別および口座番号が含まれる口座管理データが存在し、かつその口座管理データに含まれる姓、名、暗証番号および生年月日と、認可要求情報に含まれる姓、名、暗証番号および生年月日とがそれぞれ一致している場合、端末20のユーザが正当であると判定する。
次いで、銀行サーバ40の制御部は、アクセストークンを生成する。本実施例では、銀行サーバ40の制御部は、限定ではなく例として、ランダムな番号を発生させるアルゴリズムに従って所定の桁数のランダムな番号を発生させ、これをアクセストークンとする。銀行サーバ40の制御部は、そのアクセストークンを、正当と判定したユーザの口座管理データに関連付けて記憶部に保存するとともに、そのアクセストークンを含むアクセストークン情報を、通信I/Fによって、APIを介してサーバ10へ送信する(C120)。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によって端末20からアクセストークン情報を受信すると、そのアクセストークン情報に含まれるアクセストークンを、その端末20またはその端末20のユーザの支払いアプリケーションIDおよびその銀行IDと関連付けてユーザ管理データベース155に保存する(B140)。これにより、端末20とサーバ10と銀行サーバ40との間で行われる認証システム認可登録処理が完了する。
なお、認証システム認可登録処理では、詳細には、C110の後、銀行サーバ40の制御部は、認可判定処理後一定期間内のアクセス許可を与える認可トークン情報を端末20へ送信する。そして端末20は、受信した認可トークンを含む情報をサーバ10へ送信し、サーバ10は、受信した認可トークンを含む情報を銀行サーバ40へ送信する。その後、C120が実行される。この認証システム認可登録処理の詳細については、OAuthの規格に基づいて処理を行うことが可能であるため、ここでは説明を省略する。
次いで、サーバ10の支払いアプリケーション管理処理部111は、追加対象提携銀行についてのアクセストークンが登録され、追加対象提携銀行のキャッシュカードの機能がサーバ10に付与された旨を含むマイカード追加成功情報を、通信I/F14によって端末20へ送信する(B150)。
端末20の支払いアプリケーション処理部211は、通信I/F22によってサーバ10からマイカード追加成功情報を受信すると、そのマイカード追加成功情報に基づき、追加対象提携銀行のキャッシュカードの機能のサーバ10への付与が成功したことを示す画面を表示部24に表示させる(A170)。
次いで、サーバ10の支払いアプリケーション管理処理部111は、ユーザ管理データベース155のうちの、その支払いアプリケーションIDが記憶されているユーザ管理データから、提携銀行認証データに含まれる銀行IDを取得する。ここでは、そのユーザ管理データにおける提携銀行認証データにおいて、端末20のユーザが新たに登録した「QQ銀行」の「銀行ID」、「銀行名」および「アクセストークン」に加えて、「RR銀行」の「銀行ID」、「銀行名」および「アクセストークン」が登録されていることとする。支払いアプリケーション管理処理部111は、提携銀行データ154から、その銀行IDに関連付けられた、「提携銀行名」と「その他提携銀行情報」に含まれる小サイズキャッシュカード画像とを取得し、その銀行IDと、取得した提携銀行名と、取得した小サイズキャッシュカード画像とを含むマイカード一覧情報を、通信I/F14によって端末20へ送信する(B160)。
端末20の支払いアプリケーション処理部211は、通信I/F22によってサーバ10からマイカード一覧情報を受信すると、マイカード一覧情報の内容を表示部24に表示させる。具体的には、支払いアプリケーション処理部211は、限定ではなく例として、マイカード一覧情報に基づき、図3−5に例示したようなマイカード画面を表示部24に表示させる(A180)。
次いで、端末20のユーザが、これから利用しようとする提携銀行の仮想キャッシュカードのアイコンをタッチする操作を行うと、端末20の支払いアプリケーション処理部211は、入出力部23がその操作を受けたことを認識する。ここでは、端末20のユーザが「QQ銀行」の仮想キャッシュカードのアイコンをタッチする操作を行うこととする。支払いアプリケーション処理部211は、読み出した支払いアプリケーションIDと、ユーザによって選択された提携銀行の銀行IDとを含むマイカード選択情報を、通信I/F22によってサーバ10へ送信する(A190)。
サーバ10の支払いアプリケーション管理処理部111が、通信I/F14によって端末20からマイカード選択情報を受信すると、サーバ10と銀行サーバ40との間で認証システム認可処理が行われる。具体的には、支払いアプリケーション処理部211は、限定ではなく例として、ユーザ管理データベース155のうちの、マイカード選択情報に含まれる支払いアプリケーションIDが記憶されているユーザ管理データにおける提携銀行認証データから、マイカード選択情報に含まれる銀行IDに関連付けられたアクセストークンを取得する。また、支払いアプリケーション管理処理部111は、提携銀行データ154から、マイカード選択情報に含まれる銀行IDに関連付けられた提携銀行サーバURIを取得する。そして、支払いアプリケーション管理処理部111は、そのアクセストークンを含み、端末20のユーザの口座に関する情報を要求する旨を含む口座参照要求情報を、通信I/F14によって、APIを介して、その提携銀行サーバURIをアクセス先として銀行サーバ40に送信する(B170)。
銀行サーバ40の制御部は、通信I/Fによって端末20から口座参照要求情報を受信すると、記憶部に記憶された口座管理データベースのうちの、口座参照要求情報に含まれるアクセストークンと関連付けられた口座管理データから、限定ではなく例として、店番号、口座種別、口座番号、口座残高および取引履歴、ならびに姓および名を取得し、これらを含む口座情報を、通信I/Fによって、APIを介して、サーバ10へ送信する(C130)。これにより、サーバ10と銀行サーバ40との間で行われる認証システム認可処理が完了する。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によって銀行サーバ40から口座情報を受信すると、限定ではなく例として、その口座情報から店番号、口座種別、口座番号、口座残高および取引履歴、ならびに姓および名を取得する。そして、支払いアプリケーション管理処理部111は、提携銀行データ154から、例えば、認証システム認可処理を行った提携銀行の銀行IDに関連付けられた、提携銀行名と、「その他提携銀行情報」に含まれる大サイズキャッシュカード画像とを取得し、限定ではなく例として、店番号、口座種別、口座番号、口座残高および取引履歴、姓および名、ならびにその銀行ID、提携銀行名および大サイズキャッシュカード画像を含むマイカード情報を、通信I/F14によって端末20へ送信する(B180)。
端末20の支払いアプリケーション処理部211は、通信I/F22によってサーバ10からマイカード情報を受信すると、マイカード情報の内容を表示部24に表示させる(A200)。具体的には、支払いアプリケーション処理部211は、限定ではなく例として、マイカード情報に基づき、図3−6に例示したような口座詳細画面を表示部24に表示させる。
次いで、支払いアプリケーション処理部211は、端末20のユーザがATM出金ボタンをタッチする操作を行うと、入出力部23がその操作を受けたことを認識し、図3−7に例示したような出金額入力画面を表示部24に表示させる。端末20のユーザが、出金額を入力した後、確認ボタンをタッチする操作を行うと、支払いアプリケーション処理部211は、支払いアプリケーションIDを読み出すとともに、サーバ10から受信したマイカード情報から銀行IDを取得する。そして、支払いアプリケーション処理部211は、限定ではなく例として、支払いアプリケーションIDと、出金額と、その銀行IDとを含むATM出金依頼情報を、通信I/F22によってサーバ10へ送信する(A210)。
サーバ10の支払いアプリケーション管理処理部111が、通信I/F14によって端末20からATM出金依頼情報を受信すると、サーバ10と銀行サーバ40との間で認証システム認可処理が行われる。具体的には、支払いアプリケーション管理処理部111は、限定ではなく例として、ユーザ管理データベース155のうちの、ATM出金依頼情報に含まれる支払いアプリケーションIDが記憶されているユーザ管理データにおける提携銀行認証データから、ATM出金依頼情報に含まれる銀行IDに関連付けられたアクセストークンを取得する。また、支払いアプリケーション管理処理部111は、提携銀行データ154から、ATM出金依頼情報に含まれる銀行IDに関連付けられた提携銀行サーバURIを取得する。そして、支払いアプリケーション管理処理部111は、そのアクセストークンと、ATM出金依頼情報に含まれる出金額とを含み、端末20のユーザの口座から電子マネー口座への電子マネーの振替を要求する旨を含む電子マネー振替依頼情報を、通信I/F14によって、APIを介して、その提携銀行サーバURIをアクセス先として銀行サーバ40に送信する(B190)。
銀行サーバ40の制御部は、通信I/Fによって端末20から電子マネー振替依頼情報を受信すると、記憶部に記憶された口座管理データベースのうちの、電子マネー振替依頼情報に含まれるアクセストークンと関連付けられた口座管理データに記憶された口座残高から、電子マネー振替依頼情報に含まれる出金額を減算するとともに、その口座管理データに記憶された取引履歴に今回の取引内容を加えることで、その取引履歴を更新する電子マネー振替処理を行う(C140)。
次いで、銀行サーバ40の制御部は、その出金額の電子マネーの振替が成功した旨を含む振替完了通知情報を、通信I/Fによって、APIを介して、サーバ10へ送信する(C150)。これにより、サーバ10と銀行サーバ40との間で行われる認証システム認可処理が完了する。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によって端末20から振替完了通知情報を受信すると、その振替完了通知情報に基づき、依頼した出金額の電子マネーの振替が成功したことを認識し、ユーザ管理データベース155のうちの、端末20から受信したATM出金依頼情報に含まれる支払いアプリケーションIDが記憶されているユーザ管理データに記憶された「電子マネー口座残高」の金額に、その出金額を加算する。そして、支払いアプリケーション管理処理部111は、端末認証コードの確認を依頼する旨を含む端末認証コード確認依頼情報を、通信I/F14によって端末20へ送信する(B200)。
端末20の支払いアプリケーション処理部211は、通信I/F22によってサーバ10から端末認証コード確認依頼情報を受信すると、ATM50のディスプレイに表示される二次元コードの画像を撮像するためのカメラ27を起動させるとともに、図3−8に例示したような、コード読み取り画面を表示部24に表示させる。
一方、端末20のユーザは、ATM50から現金を出金させるための操作をATM50に対して行う。本実施例では、端末20のユーザは、限定ではなく例として、引き出しサービスの事業者が提供する引き出しサービスを利用するためのボタンをタッチする操作をATM50の入出力部に対して行う。ATM50の制御部は、入出力部がその操作を受けたことを認識する(D110)。
次いで、ATM50の制御部は、端末認証コードを要求する旨を含む端末認証コード要求情報を、通信I/Fによってサーバ10へ送信する(D120)。本実施例では、
限定ではなく例として、引き出しサービスの事業者と、その引き出しサービスの事業者の管理するサーバ10のアドレスとの関係を含む関係情報がATM50の記憶部に記憶されており、ATM50の制御部は、その関係情報および入出力部が受けた操作内容に基づき、端末認証コード要求情報の送信先を取得する。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によってATM50から端末認証コード要求情報を受信すると、その端末認証コード要求情報に基づき、端末認証コードを生成する(B210)。
次いで、支払いアプリケーション管理処理部111は、端末認証コード情報を通信I/F14によってATM50へ送信する(B220)。
ATM50の制御部は、通信I/Fによってサーバ10から端末認証コード情報を受信すると、その端末認証コード情報をディスプレイに表示させる(D130)。
次いで、端末20の支払いアプリケーション処理部211は、図3−8に例示したように、端末認証コードを取得する。そして、支払いアプリケーション処理部211は、読み出した支払いアプリケーションIDと、取得した端末認証コードとを含む端末認証検証情報を、通信I/F22によってサーバ10へ送信する(A230)。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によって端末20から端末認証検証情報を受信すると、その端末認証検証情報と、ATM50へ送信した端末認証コード情報とに基づき端末20を認証する端末認証検証処理を行う。本実施例では、支払いアプリケーション管理処理部111は、限定ではなく例として、端末認証検証情報に含まれる端末認証コードと、端末認証コード情報に含まれる二次元コードの画像に格納された端末認証コードとが一致するか否かを確認する。支払いアプリケーション管理処理部111は、両者が一致することを確認した場合、端末20が正当なものと判断する。また、支払いアプリケーション管理処理部111は、端末認証コード情報を送信したATM50を払い戻し先ATMとして確定させる(B230)。
次いで、サーバ10の支払いアプリケーション管理処理部111は、現金の払い戻しを依頼する旨と、出金額とを含む払い戻し依頼情報を通信I/F14によってATM50へ送信する(B240)。
ATM50の制御部は、通信I/Fによってサーバ10から払い戻し依頼情報を受信すると、その払い戻し依頼情報に基づき、払い戻し依頼情報に含まれる出金額の現金を、ATM50の現金取り出し口の内部に排出し、その現金取り出し口の扉を開口させる(D140)。
端末20のユーザは、現金取り出し口の内部に排出された現金を受け取る。ATM50の制御部は、現金取り出し口の内部から現金が取り出されたことを検知すると、現金の払い戻しが完了したことを示す払い戻し完了通知を、通信I/Fによってサーバ10へ送信する(D150)。
サーバ10の支払いアプリケーション管理処理部111が、通信I/F14によってATM50から払い戻し完了通知を受信すると、サーバ10と銀行サーバ40との間で再度認証システム認可処理が行われる。具体的には、支払いアプリケーション管理処理部111は、限定ではなく例として、ユーザ管理データベース155のうちの、端末20から受信した端末認証検証情報に含まれる支払いアプリケーションIDが記憶されているユーザ管理データにおける提携銀行認証データから、端末20から受信したATM出金依頼情報に含まれる銀行IDに関連付けられたアクセストークンを取得する。また、支払いアプリケーション管理処理部111は、提携銀行データ154から、そのATM出金依頼情報に含まれる銀行IDに関連付けられた提携銀行サーバURIを取得する。そして、支払いアプリケーション管理処理部111は、そのアクセストークンを含み、端末20のユーザの口座に関する情報を要求する旨を含む口座参照要求情報を、通信I/F14によって、APIを介して、その提携銀行サーバURIをアクセス先として銀行サーバ40に送信する(B250)。
銀行サーバ40の制御部は、通信I/Fによってサーバ10から口座参照要求情報を受信すると、記憶部に記憶された口座管理データベースのうちの、口座参照要求情報に含まれるアクセストークンと関連付けられた口座管理データから、限定ではなく例として、店番号、口座種別および口座番号、電子マネー振替処理後の口座残高および取引履歴、ならびに姓および名を取得し、これらを含む口座情報を、通信I/Fによって、APIを介して、サーバ10へ送信する(C160)。
サーバ10の支払いアプリケーション管理処理部111は、通信I/F14によって銀行サーバ40から口座情報を受信すると、限定ではなく例として、その口座情報から店番号、口座種別、口座番号、口座残高および取引履歴、ならびに姓および名を取得するとともに、提携銀行データ154から、限定ではなく例として、認証システム認可処理を行った提携銀行の銀行IDに関連付けられた、提携銀行名と、「その他提携銀行情報」に含まれる大サイズキャッシュカード画像とを取得し、店番号、口座種別、口座番号、口座残高および取引履歴、姓および名、ならびにその銀行ID、提携銀行名および大サイズキャッシュカード画像を含むATM出金完了通知情報を、通信I/F14によって端末20へ送信する(B260)。
端末20の支払いアプリケーション処理部211は、通信I/F22によってサーバ10からATM出金完了通知情報を受信すると、ATM出金完了通知情報の内容を表示部24に表示させる(A240)。具体的には、支払いアプリケーション処理部211は、限定ではなく例として、ATM出金完了通知情報に基づき、図3−9に例示したような口座詳細画面を表示部24に表示させる。
A240の後、端末20の支払いアプリケーション処理部211は、端末メイン処理を終了する。B260の後、サーバ10の支払いアプリケーション管理処理部111は、支払いアプリケーション管理処理を終了する。C160の後、銀行サーバ40の制御部は、銀行サーバメイン処理を終了する。D150の後、ATM50の制御部は、ATMメイン処理を終了する。
なお、ここでは、ユーザの銀行口座に預金している電子マネーをATM50から現金で「引き出し」する場合の処理を示した。それに加えて、ユーザがATM50に預け入れた現金を、電子マネーでユーザの銀行口座に「預入」するように構成してもよい。
この場合の処理については、詳細な説明を省略する。
また、ここでは、端末20におけるA210の処理ステップが行われた後、ATM50におけるD110〜D130の処理ステップが行われる構成について説明したが、これに限定されない。サーバ10におけるA210に対する処理と、D120に対する処理はそれぞれ独立して実行することが可能なため、例えば、ATM50におけるD110〜D130の処理ステップを先に実行し、後からA210の処理ステップを実行してもよい。
<実施例の効果>
本実施例は、入出力部23(限定ではなく、第1受付手段の一例)が、電子マネーにチャージする候補として複数の銀行(限定ではなく、複数の金融機関の一例)の口座の登録を受け付ける。また、入出力部23が、出金額(限定ではなく、対象金額の一例)を受け付けて、登録された複数の銀行の口座の中から電子マネーに出金額をチャージして電子マネーの出金額をATM50(限定ではなく、現金自動支払機の一例)から出金するための銀行(限定ではなく、対象金融機関の一例)の口座の選択と、ATM出金ボタンの対向領域のユーザによるタッチ操作(限定ではなく、出金指示の一例)とを受け付ける。そして、表示部24が、出金額と銀行口座の選択とATM出金ボタンの対向領域のユーザによるタッチ操作とを受け付けたことに応じて、その口座から出金額が電子マネーにチャージされ、チャージされた出金額をATM50から出金するための情報を表示する構成を示している。
これにより、電子マネーのサービスを利用してユーザが簡単に現金を引き出すことを可能とすることができる。
<変形例>
以下、上記の実施例の変形例について説明する。
<変形例(1)>
上記の実施例では、サーバ10上の電子マネー口座で管理される貨幣を「電子マネー(電子貨幣)」とし、銀行サーバ40(銀行)の口座で管理される貨幣を「デジタル通貨(デジタル貨幣)」として区別した。しかしながら、両者を区別せず、両方とも「電子マネー」としてもよいし、両方とも「デジタル通貨(デジタル貨幣)」としてもよい。
また、「電子マネー」または「デジタル通貨」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。また、「電子マネー」または「デジタル通貨」には、暗号通貨(暗号資産)を含めてもよいし、含めなくてもよい。また、仮想通貨には、クーポンなどの物的貨幣を含めてもよいし、含めなくてもよい。
<変形例(2)>
上記の実施例では、端末20の支払いアプリケーション処理部211は、サーバ10へ送信すべき情報に、支払いアプリケーションIDを含めてサーバ10へ送信する構成について説明したが、支払いアプリケーション処理部211は、支払いアプリケーションIDの代わりに、端末20のユーザ名、端末20の端末電話番号または端末20の端末メールアドレスを、サーバ10へ送信すべき情報に含める構成であってもよい。この場合においても、サーバ10は、支払いアプリケーションユーザ登録データ153に基づき、端末20から受信する情報から支払いアプリケーションIDを特定することができる。
<変形例(3)>
上記の実施例で説明した表示画面の構成やユーザインターフェイス等は、あくまでも一例に過ぎず、これらに限定されない。
具体的には、限定ではなく例として、銀行口座(対象金融機関の口座)の選択と出金額(対象金額)の入力とを同じ画面で行うように構成してもよい。
また、限定ではなく例として、出金額(対象金額)の入力と出金のための操作(出金指示)とを同じ画面で行うように構成してもよい。
また、限定ではなく例として、銀行口座(対象金融機関の口座)の選択と出金額(対象金額)の入力と出金のための操作(出金指示)とを同じ画面で行うように構成してもよい。
このように、限定ではなく例として、対象金額と対象金融機関の口座の選択と出金指示とのうちの任意の組合せについて、同じ画面で受け付けを行うようにすることができる。
<変形例(4)>
上記の実施例では、サーバ10において、金融機関が発行するキャッシュカードが、端末20のユーザのアカウントに登録される構成について説明したが、電子マネーまたは電子マネーに変換可能なポイントを用いたサービスを利用できるカードも、端末20のユーザのアカウントに登録される構成であってもよいし、そうでなくてもよい。そのようなサービスは、具体的には、限定ではなく例として、ポイントをユーザに付与するポイントサービス、およびユーザからの預かり金を電子マネーとして保管するサービスなどである。以下では、上記のカードのことを電子マネーカードとも称する。電子マネーカードは、具体的には、限定ではなく例として、プリペイドカード、ポイントカードまたは会員カードなどである。また、電子マネーカードを発行する、非金融機関の事業者のことを発行事業者とも称する。
本変形例では、サーバ10の記憶部15が記憶する提携銀行データ154(図2−4参照)には、発行事業者の「事業者ID」、「発行事業者名」、「発行事業者サーバURI」および「その他発行事業者情報」が、「提携銀行ID」、「提携銀行名」、「提携銀行サーバURI」および「その他提携銀行情報」と同様に、関連付けて記憶される。
事業者IDには、発行事業者を識別するための識別情報として機能するIDであって、サーバ10によって、発行事業者毎に固有に設定されるIDが記憶される。
発行事業者名には、発行事業者の名称(限定ではなく例として、発行事業者の商号、愛称または通称などなど)が記憶される。
発行事業者サーバURIには、発行事業者が管理するサーバへのアクセス方法およびアクセス先を含むURIが記憶される。
「その他発行事業者情報」は、この発行事業者IDを有する発行事業者のその他の登録情報であり、限定ではなく例として、支払いアプリケーションにおいて使用される、発行事業者を記号化したアイコンの画像データである発行事業者アイコン画像、およびその発行事業者の電子マネーカードの外観を模した画像データである電子マネーカードデザイン画像等の情報がこれに含まれる。電子マネーカードデザイン画像は、例えば、大きいサイズの画像と小さいサイズの画像とがある。以下では、この大きいサイズの画像を「大サイズ電子マネーカード画像」とも称し、この小さいサイズの画像を「小サイズ電子マネーカード画像」とも称する。
図3−10は、端末20で実行される支払いアプリケーションにおいて表示部24に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、図3−2に示すアプリケーション画面と同様の画面であって、図3−1に示すアプリケーション画面において「マイカード」のアイコンがタッチされた場合に表示されるアプリケーション画面の一例を示す図である。
本変形例では、「+マークタップでカードを追加」の説明文の下側には、「AAA COFFEE」の商号を有するコーヒーショップが発行する電子マネーカードについてのマイカードのアイコンと、「BBB ブックス」の商号を有する書店が発行する電子マネーカードについてのマイカードのアイコンと、マイカード追加用アイコンと、が表示される。以下では、電子マネーカードについてのマイカードのことを仮想電子マネーカードとも称する。「AAA COFFEE」の商号を有するコーヒーショップの仮想電子マネーカードのアイコンには、そのコーヒーショップの発行事業者IDに関連付けられた小サイズ電子マネーカード画像が含まれる。「BBB ブックス」の商号を有する書店の仮想電子マネーカードのアイコンには、その書店の発行事業者IDに関連付けられた小サイズ電子マネーカード画像が含まれる。本変形例では、これらの仮想電子マネーカードがアルファベット順にZ型パターンで並べられる。
「マイカード」の右側に位置するソートアイコンがタッチされると、登録されている仮想電子マネーカードの順番を並べ替えることが可能となる。限定ではなく例として、ソートアイコンがタッチされると、「AAA COFFEE」の仮想電子マネーカードのアイコンと、「BBB ブックス」の仮想電子マネーカードのアイコンとがアルファベットの逆順にZ型パターンで並べられる。なお、ソートの指標は、アルファベットの他に、カードを発行する事業者の業種、五十音および登録日時などに変更することが可能である。限定ではなく例として、カードを発行する事業者の業種をソートの指標とした場合、提携銀行が発行する仮想キャッシュカードと、非金融機関である発行事業者が発行する仮想電子マネーカードとが分類される。
図3−11は、図3−3に示すアプリケーション画面と同様の画面であって、図3−10に示すアプリケーション画面においてマイカード追加用アイコンがタッチされた場合に表示されるアプリケーション画面の一例を示す図である。「追加するカードを選んでください」の説明文の下側には、追加可能なキャッシュカードを発行する提携銀行、および追加可能な電子マネーカードを発行する発行事業者のリストが表示される。このリストには、ユーザによって選択可能なように縦方向に並べられた複数の列アイテムが含まれ、その列アイテムには、提携銀行の提携銀行アイコン画像または発行事業者の発行事業者アイコン画像を含むアイコンと、そのアイコンの右側に位置する、その提携銀行または発行事業者の名称の文字列とが表示される。本実施例では、そのリストにおいて、限定ではなく例として、発行事業者である、「YY電器」の列アイテムおよび「ZZ雑貨」の列アイテム、ならびに提携銀行である、「PP銀行」の列アイテム、「QQ銀行」の列アイテム、「RR銀行」の列アイテムおよび「SS銀行」の列アイテムなどが並べられる。
「カードを追加」の右側に位置するソートアイコンがタッチされると、リストにおける列アイテムの順番を並べ替えることが可能となる。限定ではなく例として、ソートアイコンがタッチされると、リストにおける列アイテムの順番が、事業者の業種別、かつ提携銀行名または発行事業者名のアルファベット順に上から並べられる。図3−11では、ソートによって並べ替えられた後のリストが示される。なお、ソートの指標は、事業者の業種およびアルファベットの他に、五十音および登録日時などの他の指標またはこれらの指標の組み合わせに変更することが可能な構成にしてもよいし、そのようにしなくてもよい。
「カードを追加」の右側に位置するカメラのアイコンがタッチされると、端末20のカメラ27が使用可能となり、ユーザが自身の電子マネーカードをカメラ27で撮像すると、端末20は、撮像結果に基づき、その電子マネーカードに刻印され発行事業者名または図柄に基づき、その電子マネーカードを発行した発行事業者を認識する。そして、端末20は、限定ではなく例として、その発行事業者の列アイテムだけをリストに表示する。これにより、ユーザは、カメラ27で撮像した電子マネーカードを発行した発行事業者の列アイテムをリストに簡易に表示させることができる。特に、リストに非常に多くの列アイテムが含まれる場合に、ユーザによる目的の列アイテムの探索時間を効果的に短縮することができる。
図3−12は、図3−10に示すアプリケーション画面と比べて、「QQ銀行」の仮想キャッシュカードのアイコンと、「RR銀行」の仮想キャッシュカードのアイコンとが追加された場合に表示されるアプリケーション画面の一例を示す図である。
「マイカード」の右側に位置するソートアイコンがタッチされると、登録されている仮想キャッシュカードおよび仮想電子マネーカードの順番を並べ替えることが可能となる。限定ではなく例として、ソートアイコンがタッチされると、これらのアイコンが、事業者の業種別、かつ提携銀行名または発行事業者名のアルファベット順にZ型パターンで並べられる。なお、ソートの指標は、事業者の業種およびアルファベットの他に、五十音および登録日時などの他の指標またはこれらの指標の組み合わせに変更することが可能な構成にしてもよいし、そのようにしなくてもよい。
本変形例は、入出力部23(限定ではなく、第4受付手段の一例)が、電子マネーに関する複数のサービスの登録を受け付ける。そして、表示部24が、登録された複数の金融機関の口座と、登録された複数のサービスとを同じ画面に一覧表示する。
これにより、登録された複数の金融機関の口座と、登録された複数のサービスとを同じ画面でユーザが確認できるようにすることができる。
また、本変形例は、ソートアイコンへの操作によって、登録された複数の金融機関の口座と、登録された複数のサービスとを分類することができるため、ユーザの利便性を向上させることができる。
<変形例(5)>
上記の実施例では、端末20の支払いアプリケーション処理部211が、ユーザの操作に基づき、キャッシュカードの登録を受け付ける構成について説明したが、支払いアプリケーション処理部211は、支払いアプリケーションと異なるアプリケーションに登録されている金融機関の口座、またはそのアプリケーションが管理する金融機関の口座の情報に基づき、キャッシュカードの登録を受け付ける構成あってもよいし、そうでなくてもよい。
具体的には、限定ではなく例として、端末20の記憶部28には、端末20のユーザの収入および支出を管理し、金融機関の口座と連携する家計簿アプリケーションが記憶される。また、記憶部28には、限定ではなく例として、家計簿アプリケーションが金融機関の口座と連携するためのアカウントを示すアカウント情報が記憶される。
アカウント情報には、限定ではなく例として、その金融機関の口座の店番号、口座種別、口座番号および暗証番号、ならびにユーザの姓、名および生年月日などが含まれる。家計簿アプリケーションは、アカウント情報に基づき、その金融機関が管理する銀行サーバ40にアクセスし、銀行サーバ40から利用明細などを含む情報を通信I/F14によって取得する。家計簿アプリケーションは、取得した利用明細などを含む情報に基づき、端末20のユーザの収入および支出を管理する。
支払いアプリケーションは、限定ではなく例として、図3−3に示すアプリケーション画面において、家計簿アプリケーションに登録された金融機関の口座情報を利用可能にするためのアイコンを表示させる。支払いアプリケーションは、端末20のユーザによってそのアイコンがタッチされると、図3−3に示すアプリケーション画面を表示するとともに、記憶部28に記憶されたアカウント情報を取得し、アカウント情報に含まれる店番号、口座種別、口座番号、姓、名、暗証番号および生年月日の各値を、入力リストにおける「店番号」、「口座種別」、「口座番号」、「姓」、「名」、「暗証番号」および「生年月日」の各入力欄にそれぞれ表示させる。端末20のユーザが認証ボタンをタッチすることで、入力リストに入力された情報に基づき、銀行サーバ40による認証が実行される。
本変形例は、支払いアプリケーション処理部211(限定ではなく、取得手段の一例)が、金融機関の口座を登録済みの家計簿アプリケーションのアカウント情報を記憶部28から取得する。入出力部23が、取得されたアカウント情報から特定される登録済みの口座に基づいて、金融機関の口座の登録を受け付ける。
これにより、金融機関の口座を登録済みのアプリケーションのアカウント情報に基づいて電子マネーにチャージする候補として金融機関の口座を簡単に登録させることができる。