以下に、本願に係る管理装置、管理方法および管理プログラムを実施するための形態(以下、「実施形態」と記載する。)について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る管理装置、管理方法および管理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略する。
〔1.第1実施形態〕
〔1-1.管理処理について〕
図1を用いて、第1実施形態の管理装置等により実現される管理処理を説明する。図1は、第1実施形態に係る管理処理の一例を示す図である。なお、図1では、第1実施形態に係る管理装置の一例である決済サーバ10によって、実施形態に係る管理処理などが実現されるものとする。
図1に示すように、第1実施形態に係る管理システム1は、決済サーバ10と、利用者端末100と、支払元サーバ400と、銀行サーバ600と、ATM(Automatic Teller Machine)800とを含む。
決済サーバ10、利用者端末100、支払元サーバ400および銀行サーバ600は、ネットワークN(たとえば、図3参照)を介して有線または無線により相互に通信可能に接続される。ネットワークNは、たとえば、インターネットなどのWAN(Wide Area Network)である。なお、図1に示した管理システム1には、複数台の決済サーバ10、複数台の利用者端末100、複数台の支払元サーバ400、複数台の銀行サーバ600および複数台のATM800が含まれていてもよい。
決済サーバ10は、第1実施形態に係る管理処理を実行する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。たとえば、決済サーバ10は、利用者端末100を用いて所定のコードを表示または読み取ることによって行われる電子決済に関する電子決済サービスを提供する。たとえば、決済サーバ10は、取引対象の提供者や取引対象が提供される利用者が所有するデジタルマネーの決済口座を管理しており、利用者からの決済情報に従って、決済口座間においてデジタルマネーの移動等を行うことで、各種決済を実現する。なお、デジタルマネーとは、たとえば、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドル等の国家により提供される貨幣を電子的に取引可能としたものであってもよい。決済サーバ10を介して行われる電子決済サービスの処理内容については後述する。
利用者端末100は、利用者によって利用される情報処理装置である。利用者端末100は、たとえば、スマートフォンや、タブレット型端末や、ノート型PC(Personal Computer)や、デスクトップPCや、携帯電話機や、PDA(Personal Digital Assistant)等により実現される。図1では、利用者端末100がスマートフォンである場合の例が示されている。
支払元サーバ400は、利用者に対して給与を支払う事業者によって利用される情報処理装置であり、サーバ装置やクラウドシステム等により実現される。たとえば、支払元サーバ400は、利用者を雇用する企業(以下、「支払元」と記載する)に属するサーバ装置である。なお、支払元となる事業者は、企業(会社や法人等)に限らず、国、都道府県、市区町村等の自治体であってもよい。
利用者端末100および支払元サーバ400は、決済サーバ10によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。
また、利用者端末100および支払元サーバ400は、所定の情報処理を実現する制御情報を決済サーバ10から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、たとえば、JavaScript(登録商標)等のスクリプト言語やCSS(Cascading Style Sheets)等のスタイルシート言語、Java(登録商標)等のプログラミング言語、HTML(HyperText Markup Language)等のマークアップ言語等により記述される。なお、決済サーバ10から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。
銀行サーバ600は、利用者の銀行口座を管理する銀行に属する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。たとえば、銀行サーバ600は、銀行口座の利用履歴として、各カード会社や、各種サービスの提供者による銀行口座からの引き落としに関する情報(引き落とした金額や、引き落とした日時等)や、現在の口座情報(口座残高等)などを、利用者に対応付けて管理する。
また、銀行サーバ600は、インターネットなどのネットワークを介してATM800と有線または無線により相互に通信可能に接続される。ATM800は、利用者による操作に従って現金を払い出す。
利用者の雇用主である支払元は、利用者に対して定期的に(たとえば毎月1回)給与を支払う。そして、第1実施形態に係る管理システム1は、給与の支払いをデジタルマネーにて行う所謂「給与のデジタル支払い」に対応する。
まず、決済サーバ10は、支払元サーバ400から入金要求を受け付ける(ステップS1)。入金要求には、デジタルマネーの入金を受ける利用者(支払先)の識別情報(支払先識別情報、以下、「支払先ID」と記載する)、入金額および入金の名目が含まれている。図1には、入金要求の一例として、支払先ID「U1」、入金額「300,000円」、名目「給与」を含んだ入金要求を示している。
なお、支払先ID「U1」は、利用者U1の識別情報(利用者識別情報、以下、「利用者ID」と記載する)である。利用者IDは、利用者U1を識別することができる情報であればよく、数字、アルファベット、記号等またはこれらの組み合わせの他、たとえば、電話番号およびメールアドレス等であってもよいし、電話番号およびメールアドレス等と氏名との組み合わせであってもよい。氏名は、漢字、ひらがな、カタカナ、アルファベットのいずれでも構わない。また、入金要求には、支払元を識別する識別情報(支払元識別情報、以下、「支払元ID」と記載する)が含まれていてもよい。
つづいて、決済サーバ10は、入金要求に含まれる名目が給与であるか否かを判定する。そして、決済サーバ10は、入金要求に含まれる名目が給与である場合、その入金要求に含まれる利用者IDに紐付けられた総残高のうち給与残高に対して入金処理を行う。
たとえば、決済サーバ10は、「所有者ID」項目と、「総残高」項目と、「内訳」項目とを関連づけた口座情報を記憶する。「所有者ID」項目には、デジタルマネーの口座(決済口座)を所有する所有者を識別する識別情報(所有者識別情報、以下、「所有者ID」と記載する)が格納される。ここでは、「所有者ID」項目に、利用者U1を識別する利用者ID「U1」が格納される場合の例を示しているが、「所有者ID」項目には、利用者IDの他、支払元IDや、取引対象を提供する提供者を識別する識別情報(提供者識別情報、以下、「提供者ID」と記載する)等が格納されてもよい。「総残高」項目には、所有者IDによって識別される所有者が所有するデジタルマネーの総残高を示す情報を格納する。
「内訳」項目には、「総残高」項目に格納される総残高の内訳を示す情報が格納される。具体的には、「内訳」項目は、「給与」項目と「給与以外」項目とを含む。「給与」項目には、「総残高」項目に格納された総残高のうち、給与として入金されたデジタルマネーの残高を示す情報が格納される。「給与以外」項目は、「総残高」項目に格納された総残高のうち、給与以外の名目で入金されたデジタルマネーの残高を示す情報が格納される。
たとえば、図1には、口座情報の一例として、利用者ID「U1」、総残高「1,000,000円」、給与「700,000円」、給与以外「300,000円」を含んだ口座情報を示している。この場合において、図1に示す入金要求を受け付けた場合、決済サーバ10は、利用者ID「U1」に対応づけられた「総残高」項目を「1,000,000円」から「1,300,000円」に変更する。また、決済サーバ10は、利用者ID「U1」に対応づけられた「給与」項目を「700,000円」から「1,000,000円」に変更する(ステップS2)。なお、「給与以外」項目は、変更されない。
一方、決済サーバ10は、給与以外の名目を含んだ入金要求を受け付けた場合には、対応する口座情報のうち、「総残高」項目を変更するとともに「給与以外」項目を変更する。この場合、「給与」項目は、変更されない。なお、「給与以外」項目は、複数の項目に細分化されていてもよい。すなわち、給与以外の名目は、複数存在していてもよく、この場合、「給与以外」項目は、複数存在する名目に対応して細分化されてもよい。
このように、第1実施形態に係る管理システム1では、デジタルマネーの総残高のうち少なくとも給与残高を分けて管理することとした。これにより、たとえば、決済サーバ10は、総残高を示す残高情報(たとえば、総残高「1,300,000円」)を、給与残高を示す給与残高情報(たとえば、総残高「1,000,000円」)と給与以外残高を示す給与以外残高情報(たとえば、総残高「300,000円」)とに分けて利用者U1の利用者端末100に表示させることができる(ステップS3)。
したがって、第1実施形態に係る管理システム1によれば、給与のデジタル支払いが行われた場合に、給与を含む残高を適切に管理することができる。
ところで、給与のデジタル支払いにおいては、給与として支払われたデジタルマネーを現金化できるようにすることで利用者の利便性が担保できる。具体的には、給与として支払われたデジタルマネーをATMから引き出せるようにする必要がある。そこで、第1実施形態に係る管理システム1は、給与として支払われたデジタルマネーをATM800から引き出すことが可能に構成される。
たとえば、ATM800は、利用者U1による操作に従って、利用者IDおよび出金額を含む出金要求を銀行サーバ600に送信する(ステップS4)。利用者U1によるATM800に対する操作は、たとえば、ATM800が有するタッチパネルや物理的なボタンへの入力操作であってもよいし、利用者端末100が表示するQRコード(登録商標)等をATM800に読み取らせる操作であってもよい。ATM800に入力される情報には、少なくとも、利用者IDおよび出金額が含まれていればよい。
つづいて、銀行サーバ600は、ATM800から受け付けた出金要求を決済サーバ10に送信する(ステップS5)。
つづいて、決済サーバ10は、銀行サーバ600から受け付けた出金要求に基づき、対応する残高情報のうち「給与」項目を変更する。たとえば、出金要求に、利用者ID「U1」、出金額「100,000円」が含まれているとする。この場合、決済サーバ10は、利用者ID「U1」に紐付けられた「総残高」項目を「1,300,000円」から「1,200,000円」に変更するとともに、「給与」項目を「1,000,000円」から「900,000円」に変更する(ステップS6)。
つづいて、決済サーバ10は、利用者IDおよび出金額を含む出金指示を銀行サーバ600に送信する(ステップS7)。銀行サーバ600は、出金指示を受け付けると、決済サーバ10が属する事業者、すなわち、電子決済サービスを提供する企業の銀行口座から、出金指示に含まれる出金額を引き落とす(ステップS8)。なお、この処理は、決済サーバ10から出金指示を受け付けたタイミングで行われてもよいし、たとえば月に1回の予め決められたタイミングで行われてもよい。
また、銀行サーバ600は、出金額を含む出金指示をATM800に送信する(ステップS9)。そして、ATM800は、出金指示に含まれる出金額と同額の現金を払い出す(ステップS10)。
このように、第1実施形態に係る管理システム1において、利用者U1は、自身が所有するデジタルマネーの総残高のうち、給与残高分のデジタルマネーをATM800から現金として引き出すことができる。
なお、上述した現金化に関する仕組みは、給与として支払われたデジタルマネーを対象とするものであり、給与以外の名目で支払われたデジタルマネーに関しては対象外であってよい。給与以外の名目で支払われたデジタルマネーについても現金化可能とすると、たとえばマネーロンダリング(資金洗浄)の温床となること等が懸念される。このため、決済サーバ10は、給与以外残高のATM800からの出金を禁止してもよい。ただし、給与以外残高が複数の項目に細分化される場合、細分化された複数の項目のうち何れかについては、ATM800からの出金を許容してもよい。
〔1-2.利用者端末100を用いた決済について〕
次に、利用者端末100を用いた決済(電子決済)の一例について図2を参照して説明する。図2は、第1実施形態に係る電子決済処理の一例を示す図である。管理システム1では、上述したデジタルマネーの総残高のうち給与残高および給与以外残高の両方を電子決済に利用することが可能である。
図2に示すように、管理システム1は、提供者端末200をさらに含んでいてもよい。提供者端末200は、利用者に取引対象を提供する提供者によって利用される情報処理装置である。提供者端末200は、たとえば、POS(Point of Sales)端末や、スマートフォン、タブレット型端末、ノート型PC、デスクトップPC、携帯電話機、PDA等により実現される。また、提供者端末200は、決済サーバ10によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図2には、提供者端末200がPOS端末である場合の例が示されている。
以下の説明では、店舗Aに配置された2次元コード(QRコード(登録商標))であって、店舗Aを識別する識別情報(以下、「店舗コード」と記載する)C1を示す2次元コードを用いて、利用者U1が利用者端末100を用いた決済を行う例について説明するが、第1実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意の利用者が任意の利用者端末100を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗コードC1は、QRコード(登録商標)のみならず、バーコードや所定のマーク、番号等(すなわち、所定のコード)であってもよい。
たとえば、利用者U1が店舗Aにて各種の商品やサービスといった決済対象(取引対象)の利用や購入に伴う決済を行う場合、利用者U1は、利用者端末100に予めインストールされた決済アプリを起動する。そして、利用者U1は、決済アプリを介して、店舗Aに設置された店舗コードC1を撮影して読み取る(ステップS11)。このような場合、利用者端末100は、決済対象の価格を入力するための画面を表示し、利用者U1或いは店舗Aの店員から決済金額の入力を受け付ける。そして、利用者端末100は、利用者U1を識別する利用者IDと、店舗コードC1(若しくは、店舗コードC1が示す情報、すなわち、店舗Aを示す情報(たとえば、提供者ID))と、決済金額とを示す決済情報を決済サーバ10へと送信する。
決済サーバ10は、利用者端末100から決済情報を受け付けると(ステップS12)、利用者IDが示す利用者U1の決済口座から、店舗コードC1が示す店舗Aの決済口座へと、決済金額が示す額のデジタルマネーを移動させる(ステップS13)。そして、決済サーバ10は、決済が完了した旨の通知を利用者端末100へと送信する(ステップS14)。このような場合、利用者端末100は、決済が完了した旨の画面や所定の音声を出力することで、デジタルマネーによる決済が行われた旨を通知する。
なお、利用者端末100を用いた決済は、上述した処理に限定されるものではない。たとえば、利用者端末100を用いた決済は、店舗Aに設置された提供者端末200を用いたものであってもよい。たとえば、利用者端末100は、利用者U1を識別するための利用者IDを画面上に表示させる。このような場合、店舗Aに設置された提供者端末200は、利用者端末100に表示された利用者IDを読み取り、利用者IDと、決済金額と、店舗Aを識別する情報とを示す決済情報を決済サーバ10へと送信する。このような場合、決済サーバ10は、利用者IDが示す利用者U1の決済口座から、店舗Aの決済口座へと、決済金額が示す額のデジタルマネーを移動させ、店舗Aの提供者端末200或いは利用者端末100に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。
また、利用者端末100を用いた決済は、利用者U1が予めデジタルマネーをチャージした決済口座から店舗Aの決済口座へとデジタルマネーを移動させる処理のみならず、たとえば、利用者U1が予め登録したクレジットカードを用いた決済であってもよい。このような場合、たとえば、利用者端末100は、店舗Aの決済口座に対して決済金額のデジタルマネーを移動させるとともに、利用者U1のクレジットカードの運用会社(カード会社)に対し、決済金額を請求してもよい。
また、利用者端末100を用いた決済は、実店舗に対するものに限らず、たとえば、電子商取引サービスでの取引対象に対する決済(すなわち、オンライン決済)であってもよい。このような場合、たとえば、利用者端末100は、利用者U1を識別する利用者IDと、提供者IDと、取引対象の価格(決済金額)とを示す決済情報を決済サーバ10へと送信する。そして、決済サーバ10は、利用者IDが示す利用者U1の決済口座から、提供者IDが示す提供者の決済口座へと、決済金額が示す額のデジタルマネーを移動させ、利用者端末100に対し決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知する。
〔2.決済サーバの構成〕
次に、図3を用いて、決済サーバ10の構成について説明する。図3は、第1実施形態に係る決済サーバ10の構成例を示す図である。図3に示すように、決済サーバ10は、通信部20と、記憶部30と、制御部40とを有する。
(通信部20について)
通信部20は、たとえば、NIC(Network Interface Card)等によって実現される。そして、通信部20は、ネットワークNと有線または無線で接続され、利用者端末100、提供者端末200、支払元サーバ400および銀行サーバ600等との間で情報の送受信を行う。
(記憶部30について)
記憶部30は、たとえば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図4に示すように、記憶部30は、口座データベース31を有する。
(口座データベース31について)
口座データベース31は、利用者、給与の支払元、提供者などが電子決済サービスにおいて所有する口座(決済口座)に関する各種の情報(上述した残高情報の一例)を記憶する。ここで、図4を用いて、口座データベース31が記憶する情報の一例を説明する。図4は、第1実施形態に係る口座データベースの一例を示す図である。図4の例において、口座データベース31は、「口座ID」、「所有者ID」、「総残高」、「内訳」といった項目を有する。
「口座ID」項目には、決済口座を識別するための識別情報(口座識別情報、以下「口座ID」と記載する)が格納される。「所有者ID」項目には、口座IDに紐付けられた決済口座を所有する所有者を識別するための識別情報が格納される。たとえば、図4に示す例において、「所有者ID」項目には、利用者U1の利用者ID「U1」、給与を支払う支払元の支払元ID「E1」、取引対象を提供する提供者の提供者ID「P1」等が格納されている。
「総残高」項目には、決済口座の総残高を示す情報が格納される。「内訳」項目には、総残高の内訳を示す情報が格納される。具体的には、「内訳」項目には、「給与」項目および「給与以外」項目が含まれており、「給与以外」項目は、たとえば「通常」項目、「利益」項目等に細分化されている。
「給与」項目には、「総残高」項目に格納された総残高のうち、給与として入金されたデジタルマネーの残高を示す情報が格納される。「給与以外」項目には、「総残高」項目に格納された総残高のうち、給与以外の名目で入金されたデジタルマネーの残高を示す情報が格納される。
また、「給与以外」項目のうち、「通常」項目には、決済口座の所有者が自らチャージしたデジタルマネーの残高を示す情報が格納される。一例として、「通常」項目には、決済口座に紐付けられたクレジットカードまたは銀行口座から入金されたデジタルマネーの残高を示す情報が格納される。「利益」項目には、たとえば、管理システム1が提供する電子決済サービスを利用した際に決済金額に対してキャッシュバックされたデジタルマネーの残高を示す情報が格納される。
(制御部40について)
制御部40は、コントローラ(controller)であり、たとえば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、決済サーバ10内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部40は、コントローラであり、たとえば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。第1実施形態に係る制御部40は、図3に示すように、受付部41と、入金処理部42と、出金処理部43と、表示制御部44とを有し、以下に説明する情報処理の機能や作用を実現または実行する。
(受付部41について)
受付部41は、デジタルマネーの入金要求を受け付ける。ここで、入金要求に含まれる情報の一例について図5を参照して説明する。図5は、第1実施形態に係る入金要求の一例を示す図である。
図5に示すように、入金要求には、たとえば、「支払元ID」、「支払先ID」、「入金額」、「名目」といった情報が含まれる。「支払元ID」は、入金要求を送信した支払元の識別情報であり、「支払先ID」は、支払先の識別情報である。また、「入金額」は、入金されるデジタルマネーの金額を示す情報であり、「名目」は、入金の名目を示す情報である。図5に示す入金要求は、支払元ID「E1」によって識別される利用者U1の雇用主から支払先ID「U1」によって識別される利用者U1に、給与として「300,000円」が入金されることを示している。
また、受付部41は、デジタルマネーのATM800への出金要求を受け付ける。ここで、出金要求に含まれる情報の一例について図6を参照して説明する。図6は、第1実施形態に係る出金要求の一例を示す図である。
図6に示すように、出金要求には、たとえば、「銀行ID」、「出金元ID」、「出金額」、「出金先」といった情報が含まれる。「銀行ID」は、出金要求を送信した銀行の識別情報であり、「出金元ID」は、出金を行う利用者の識別情報である。また、「出金額」は、出金額を示す情報であり、「出金先」は、出金先(どこへ出金するか)を示す情報である。図6に示す出金要求は、銀行ID「B1」の銀行から送信されたものであって、出金元ID「U1」の利用者(すなわち利用者U1)がATMから100,000円の出金を行うことを示している。
受付部41は、電子商取引サービスでの取引対象に対する決済に関する決済情報を受け付けてもよい。たとえば、受付部41は、利用者を識別する利用者IDと、取引対象を提供する提供者を識別する提供者IDと、取引対象の価格(決済金額)とを示す決済情報を利用者端末100から受け付ける。
また、受付部41は、店舗に設置された提供者端末200から決済情報を受け付けてもよい。たとえば、受付部41は、提供者端末200が読み取った利用者IDであって、利用者端末100に表示された利用者IDと、決済金額と、店舗を識別する情報とを示す決済情報を受け付ける。
また、受付部41は、利用者端末100からデジタルマネーの総残高の確認要求を受け付けてもよい。この場合、確認要求には、少なくとも利用者IDが含まれていればよい。
(入金処理部42について)
入金処理部42は、受付部41によって受け付けられた入金要求に基づいて口座データベース31に対する入金処理を行う。
具体的には、入金処理部42は、入金要求に含まれる支払元IDに紐付けられた決済口座から、入金要求に含まれる支払先IDに紐付けられた決済口座に対し、入金要求に含まれる入金額に相当するデジタルマネーの資金移動を行う。すなわち、入金処理部42は、支払元IDに紐付けられた決済口座の総残高から入金額を減算するとともに、支払先IDに紐付けられた決済口座の総残高に入金額を加算する。
また、入金処理部42は、入金要求に含まれる名目が「給与」であるか否かを判定する。そして、入金処理部42は、入金要求に含まれる名目が「給与」である場合、支払先IDに紐付けられた決済口座の総残高のうちの「給与」項目に対して入金額を加算する。
一方、入金処理部42は、入金要求に含まれる名目が「給与以外」である場合、支払先IDに紐付けられた決済口座の総残高のうちの「給与以外」項目に対して入金額を加算する。たとえば、入金処理部42は、入金要求に含まれる名目が「通常」である場合、支払先IDに紐付けられた決済口座の総残高のうちの「通常」項目に対して入金額を加算する。また、入金処理部42は、入金要求に含まれる名目が「利益」である場合、支払先IDに紐付けられた決済口座の総残高のうちの「利益」項目に対して入金額を加算する。
(出金処理部43について)
出金処理部43は、受付部41によって受け付けられた出金要求に基づいて口座データベース31に対する出金処理を行う。
具体的には、出金処理部43は、出金要求に含まれる出金元IDに紐付けられた決済口座から、出金要求に含まれる出金額に相当するデジタルマネーを減算する。そして、出金処理部43は、通信部20およびネットワークNを介し、出金要求に含まれる銀行IDの銀行サーバ600に対して出金指示を送信する。出金指示には、出金元IDおよび出金額といった情報が含まれていてもよい。
また、出金処理部43は、出金要求に含まれる出金先が「ATM」であるか否かを判定する。そして、出金処理部43は、出金要求に含まれる出金先が「ATM」である場合、出金元IDに紐付けられた決済口座の総残高のうちの「給与」項目から出金額を減算する。
なお、出金処理部43は、出金要求に含まれる出金先が「ATM」以外である場合、たとえば、出金先が「銀行口座」である場合、出金元IDに紐付けられた決済口座の「給与」項目および「通常」項目のうち、利用者によって選択された項目から出金額を減算してもよい。出金元とする残高項目(ここでは、「給与」項目および「通常」項目)の選択は、ATM600への操作によって行われても良い。また、利用者によって予め設定されていてもよい。
(表示制御部44について)
表示制御部44は、管理システム1が提供する電子決済サービスに関するコンテンツを利用者が利用する利用者端末100に表示させる。
たとえば、表示制御部44は、受付部41によって利用者端末100から総残高の確認要求が受け付けられた場合に、確認要求に含まれる利用者IDによって識別される利用者の利用者端末100に対し、その利用者が所有する決済口座の総残高を示す残高情報を送信する。このとき、表示制御部44は、たとえば、利用者IDに紐付けられた決済口座から「総残高」項目、「給与」項目および「給与以外」項目の各情報を取得し、取得した各情報を決済アプリを介して利用者端末100に表示させる。
利用者端末100に表示される残高情報の一例を図7に示す。図7は、第1実施形態に係る利用者端末100の画面の一例を示す図である。図7には、一例として、利用者U1が所有する決済口座の残高情報が示されている。
図7に示すように、表示制御部44は、利用者ID「U1」に紐付けられた決済口座から「総残高」項目として「1,000,000円」、「給与」項目として「700,000円」および「給与以外」項目として「300,000円」の各情報を取得し、取得した各情報を利用者端末100に表示させる。
このように、表示制御部44は、デジタルマネーの総残高を給与残高と給与以外残高とに分けて利用者が利用する利用者端末100に表示させる。
〔3.管理処理のフロー〕
次に、第1実施形態に係る決済サーバ10の管理処理の手順について説明する。まず、入金処理の手順について図8を参照して説明する。図8は、第1実施形態に係る管理処理のうち入金処理の手順の一例を示すフローチャートである。
図8に示すように、決済サーバ10は、入金要求を受け付ける(ステップS101)。つづいて、決済サーバ10は、入金要求の名目が「給与」であるか否かを判定する(ステップS102)。名目が「給与」であると判定した場合(ステップS102;Yes)、決済サーバ10は、給与残高への入金を行う(ステップS103)。具体的には、決済サーバ10は、支払元の決済口座から支払先の給与残高への資金移動を行う。
一方、入金要求の名目が「給与」ではない場合、すなわち、「給与以外」であると判定した場合(ステップS102;No)、決済サーバ10は、給与以外残高への入金を行う(ステップS104)。具体的には、決済サーバ10は、支払元の決済口座から支払先の給与以外残高への資金移動を行う。ステップS103またはステップS104の処理を終えると、決済サーバ10は、入金処理を終了する。
次に、出金処理の手順について図9を参照して説明する。図9は、第1実施形態に係る管理処理のうち出金処理の手順の一例を示すフローチャートである。
図9に示すように、決済サーバ10は、出金要求を受け付ける(ステップS201)。つづいて、決済サーバ10は、出金先がATMであるか否かを判定する(ステップS202)。出金先がATMであると判定した場合(ステップS202;Yes)、決済サーバ10は、給与残高からの出金を行う(ステップS203)。
一方、出金先がATMではない場合、すなわち、出金先が銀行口座であると判定した場合(ステップS202;No)、決済サーバ10は、給与残高および給与以外残高のうち利用者によって選択された残高項目からの出金を行う(ステップS204)。ステップS203またはステップS204の処理を終えると、決済サーバ10は、銀行サーバ600に対して出金指示を送信し(ステップS205)、出金処理を終了する。
〔4.第2実施形態〕
次に、第2実施形態に係る管理処理について図10を参照して説明する。図10は、第2実施形態に係る管理処理の一例を示す図である。
図10に示すように、決済サーバ10は、支払元サーバ400から給与の入金要求を受け付けた場合に(ステップS21)、給与の支払先となる利用者の決済口座に対して給与としてのデジタルマネーを入金する(ステップS22)。上述したように、給与の入金要求には、たとえば、給与の入金を受ける利用者(支払先)の識別情報(支払先ID)、入金額および入金の名目が含まれる。また、上述したように、決済サーバ10は、入金要求に含まれる名目が「給与」である場合に、入金要求に含まれる金額のデジタルマネーを支払先IDに紐付けられた決済口座の「給与残高」に入金する。
つづいて、決済サーバ10は、支払先の決済口座に給与として入金されたデジタルマネーの一部を、支払先である利用者の利用者情報に基づいて用途ごとに仕分ける仕分け処理を行う(ステップS23)。
たとえば、利用者情報には、給与の仕分けに関する設定情報(以下、「仕分け情報」と記載する)が含まれていてもよい。仕分け情報には、たとえば、取引対象を識別する識別情報(取引対象識別情報、以下、「取引対象ID」と記載する)、取引対象の提供元である提供者を識別する識別情報(提供者識別情報、以下、「提供者ID」と記載する)、取引対象の金額等が含まれる。
図10に示す例では、用途Aに「10,000円」、用途Bに「5,000円」、用途Cに「3,000円」を仕分けるように設定されている。この場合、決済サーバ10は、利用者の決済口座に給与としてのデジタルマネーが入金された場合に、仕分け情報に従って、給与として入金されたデジタルマネーのうち、10,000円を用途Aに利用するデジタルマネーとして、5,000円を用途Bに利用するデジタルマネーとして、3,000円を用途Cに利用するデジタルマネーとして仕分ける。この場合、決済サーバ10は、給与として入金されたデジタルマネーのうち、18,000円分については、用途A~Cに用途が限定される。つまり、利用者が用途A~C以外の用途に利用することができる給与は、給与の総額から18,000円を差し引いた金額となる。
このように、第2実施形態に係る決済サーバ10は、給与として入金されたデジタルマネーを利用者情報に基づいて仕分けることで、給与として入金されたデジタルマネーの用途を限定する。これにより、利用者は、たとえば、光熱費や通信費、学費など、毎月必ず発生する支出分を仕分けるように設定しておくことで、給与の使い過ぎを抑制することができる。
また、決済サーバ10は、給与としてのデジタルマネーが入金された場合に、用途ごとに仕分けられたデジタルマネーを自動的にその用途に用いてもよい。たとえば、用途Aが、利用者が所有する運用口座への入金である場合、決済サーバ10は、給与として入金されたデジタルマネーのうち10,000円を運用口座に自動的に移動させてもよい。また、たとえば、用途Bが、利用者が定期的に(たとえば毎月)購入している商品の購入である場合、決済サーバ10は、給与として入金されたデジタルマネーのうち5,000円を、その商品を提供する提供者の決済口座に移動させてもよい。
このように、決済サーバ10は、給与として入金されたデジタルマネーの仕分け処理として、給与として入金されたデジタルマネーの一部を利用者が所有する決済口座内で取り置きしてもよいし、給与として入金されたデジタルマネーの一部を利用者が所有する決済口座以外の口座へ移動させてもよい。
また、決済サーバ10は、利用者による入力操作に基づいて仕分け情報を生成してもよいし、利用者情報のうち出金履歴情報に基づいて生成してもよい。たとえば、決済サーバ10は、出金履歴情報に基づき、利用者が定期的に購入する取引対象を推定し、推定した取引対象の取引対象ID、その取引対象を提供する提供者の提供者ID、その取引対象の金額を含む仕分け情報を生成してもよい。この際、決済サーバ10は、生成した仕分け情報を利用するか否かを利用者に提案し、提案が承認された場合に、生成した仕分け情報を採用するようにしてもよい。
〔5.決済サーバの構成〕
次に、第2実施形態に係る決済サーバの構成について図11を参照して説明する。図11は、第2実施形態に係る決済サーバの構成例を示す図である。
図11に示すように、第2実施形態に係る決済サーバ10の制御部40は、取得部45と、資金移動部46と、推定部47と、判定部48と、決済処理部49と、提案部50とを有する。また、第2実施形態に係る決済サーバ10の記憶部30は、履歴データベース32と、登録情報データベース33と、請求情報データベース34とを有する。
(口座データベース31について)
第2実施形態に係る口座データベース31が記憶する情報の一例について図12を参照して説明する。図12は、第2実施形態に係る口座データベースの一例を示す図である。
図12に示すように、第2実施形態に係る口座データベース31は、「給与」項目として、「普段使い」項目、「取り置き#1」項目、「取り置き#2」項目といった項目が含まれている。「普段使い」項目には、給与として入金されたデジタルマネーのうち、用途が限定されてないデジタルマネー、すなわち、利用者が自由に利用することができるデジタルマネーの金額が格納される。「取り置き#1」項目および「取り置き#2」項目には、給与として入金されたデジタルマネーのうち、用途が限定されているデジタルマネーの金額が格納される。なお、これら「取り置き」項目は、後述する登録情報データベース33における「仕分け情報」項目と連動しており、「仕分け情報」項目に新たな取り置き項目が追加された場合に、新たに追加された取り置き項目が口座データベース31にも追加される。
なお、第2実施形態に係る入金処理部42は、名目として「給与」を含んだ入金要求が受け付けられた場合に、入金要求に含まれる「金額」のデジタルマネーを決済口座の「給与」項目のうち「普段使い」項目に格納する。「普段使い」項目に格納されたデジタルマネーの一部は、その後、後述する資金移動部46によって、「給与」項目のうちの「取り置き」項目や給与が入金された決済口座以外の口座に移動されることとなる。この点については後述する。
(履歴データベース32について)
履歴データベース32は、利用者が過去に行った取引の履歴に関する情報(出金履歴情報の一例)を記憶する。ここで、履歴データベース32が記憶する情報の一例について図13を参照して説明する。図13は、第2実施形態に係る履歴データベースの一例を示す図である。
図13に示す例において、履歴データベース32は、「利用者ID」、「日時」、「提供者ID」、「取引対象」、「金額」といった項目を有する。
「利用者ID」項目には、取引を行った利用者の利用者IDが格納される。「日時」項目には、取引が行われた(決済が行われた)日時が格納される。「提供者ID」項目には、取引対象を提供した提供者の提供者IDが格納される。「取引対象」項目には、取引対象を特定するための情報(たとえば、品番、商品名など)が格納される。「金額」項目には、取引対象の提供に対して利用者が支払った金額が格納される。
(登録情報データベース33について)
登録情報データベース33は、利用者に関する登録情報(利用者情報の一例)を記憶する。ここで、登録情報データベース33が記憶する情報の一例について図14を参照して説明する。図14は、第2実施形態に係る登録情報データベースの一例を示す図である。
図14に示す例において、登録情報データベース33は、「利用者ID」、「氏名」、「年齢」、「性別」、「家族構成」、「運用口座ID」、「仕分け情報」といった項目を有する。
「利用者ID」項目には、利用者IDが格納される。「氏名」項目には、利用者IDによって識別される利用者の氏名が格納される。なお、「氏名」項目に格納される氏名は、漢字に限らず、ひらがな、カタカナ、アルファベット等により示されてもよい。「年齢」項目には、利用者IDによって識別される利用者の年齢が格納される。「性別」項目には、利用者IDによって識別される利用者の性別が格納される。「家族構成」項目には、利用者IDによって識別される利用者の家族構成が格納される。たとえば、利用者との間柄、氏名、年齢、性別といった情報が「家族構成」項目に格納される。「運用口座ID」項目には、利用者IDによって識別される利用者が所有する運用口座を識別する識別情報(運用口座識別情報、以下、「運用口座ID」と記載する)が格納される。
「仕分け情報」項目には、利用者IDによって識別される利用者に対して設定された仕分け情報の内容が格納される。たとえば、「仕分け情報」項目には、「仕分けID」、「提供者ID」、「取引対象」、「設定金額」といった項目が含まれる。
「仕分けID」項目には、仕分け情報を識別するための識別情報が格納される。ここでは、「取り置きID」および「送金ID」の2種類の仕分けIDが格納される。「取り置きID」は、利用者の決済口座に取り置く仕分け情報を識別する識別情報であり、「送金ID」は、利用者の決済口座以外の口座に送金する仕分け情報を識別する識別情報である。
「提供者ID」項目には、仕分けIDによって識別される仕分け情報において、用途となる取引対象を提供する提供者の提供者IDが格納される。「取引対象」項目には、仕分けIDによって識別される仕分け情報において、用途となる取引対象を特定するための情報(たとえば、品番、商品名など)が格納される。「設定金額」項目には、仕分けIDによって識別される仕分け情報において、決済口座に取り置きされる、または、決済口座以外の口座に送金されるデジタルマネーの設定金額が格納される。
(請求情報データベース34について)
請求情報データベース34は、たとえば提供者端末200または提供者が所有する提供者サーバから送信される請求情報を記憶する。ここで、図15を用いて、請求情報データベース34が記憶する情報の一例を説明する。図15は、第2実施形態に係る請求情報データベースの一例を示す図である。図15の例において、請求情報データベース34は、「請求情報ID」、「利用者ID」、「提供者ID」、「支払期限」、「取引対象」、「金額」といった項目を有する。
「請求情報ID」項目には、請求情報を識別するための識別情報が格納される。「提供者ID」項目には、請求元である提供者を識別する提供者IDが格納される。「利用者ID」項目には、請求先である利用者を識別する利用者IDが格納される。「支払期限」項目には、請求された金額の支払期限が格納される。「取引対象」項目には、請求の対象となる取引対象を示す情報が格納される。ここでは、理解を容易にするために、「電気」、「水道」と記載したが、「取引対象」項目には、取引対象を特定することができる情報が格納される。「金額」項目には、請求先に請求する金額が格納される。
(取得部45について)
取得部45は、利用者に関する利用者情報を取得する。たとえば、取得部45は、利用者情報として、口座データベース31、履歴データベース32、登録情報データベース33、請求情報データベース34に格納された各種の情報を取得する。
(資金移動部46について)
資金移動部46は、受付部41によって入金が受け付けられたデジタルマネーのうち、給与として入金されたデジタルマネーの一部を取得部45によって取得された利用者情報に基づいて移動させる。
資金移動部46は、登録情報データベース33に記憶された仕分け情報に従って、給与として入金されたデジタルマネーの一部を、給与としてのデジタルマネーが入金された決済口座内の「取り置き」項目、または、給与としてのデジタルマネーが入金された決済口座以外の口座に移動させる。なお、取り置きIDが付された仕分け情報は、取得部45によって登録情報データベース33から取得される。
まず、決済口座内の「取り置き」項目にデジタルマネーを移動させる場合について説明する。
上述したように、給与としてのデジタルマネーは、まず、決済口座の「給与」項目のうちの「普段使い」項目に入金される。「普段使い」項目にデジタルマネーが入金されると、資金移動部46は、取り置きIDが付された仕分け情報に従って、「普段使い」項目に入金されたデジタルマネーの一部を、「取り置き」項目に移動させる。たとえば、図14に示す登録情報データベース33には、利用者ID「U1」の利用者に対し、「取り置き#1」および「取り置き#2」の2つの仕分け情報が紐付けられている。資金移動部46は、利用者ID「U1」の利用者U1に給与としてのデジタルマネーが入金された場合に、利用者ID「U1」に紐付けられた決済口座の「普段使い」項目から「取り置き#1」項目および「取り置き#2」項目に、デジタルマネーを移動させる。
このとき、資金移動部46は、決済口座の「取り置き」項目に格納されている金額が、仕分け情報の「設定金額」項目に格納されている金額と一致するように、「普段使い」項目から「取り置き」項目にデジタルマネーを移動させる。
たとえば、給与の入金前において、決済口座の「取り置き#1」項目に「100円」が格納されていたとする。この場合、資金移動部46は、決済口座の「取り置き#1」項目が「15,000円」になるように、決済口座の「普段使い」項目から「取り置き#1」項目に「14,900円」を移動させる。
なお、資金移動部46は、「取り置き」項目の残高に関係なく、仕分け情報の「設定金額」項目に格納された金額のデジタルマネーを決済口座の「普段使い」項目から「取り置き」項目に移動させるようにしてもよい。
ここで、図14に示すように、「取り置き#1」の仕分け情報には、複数の提供者IDおよび複数の提供対象が紐付けられている。一例として、「取り置き#1」の仕分け情報には、提供対象として「電気」、「水道」等が紐付けられている。このように、「取り置き#1」の仕分け情報は、毎月発生する支出(固定費)を取り置くための仕分け情報であってもよい。このような「取り置き#1」の仕分け情報に紐付けられる「設定金額」項目には、利用者によって入力された金額が格納されてもよいし、後述する推定部47によって推定された金額が格納されてもよい。推定部47の内容については、後述する。このように、資金移動部46は、推定部47によって推定された一月あたりの支出額に基づき、給与として入金された前記デジタルマネーの一部を「取り置き」項目に移動させてもよい。
また、「取り置き#1」の仕分け情報には、上記のような公共料金に限らず、たとえば、利用者が定期的に(たとえば毎月)購入している取引対象(たとえば、サプリメントや使い捨てコンタクトレンズ等)が紐付けられてもよい。このような「取り置き#1」の仕分け情報に紐付けられる「設定金額」項目についても、利用者によって入力された金額が格納されてもよいし、後述する推定部47によって推定された金額が格納されてもよい。
つづいて、給与として入金されたデジタルマネーの一部を、給与としてのデジタルマネーが入金された決済口座以外の口座に移動させる場合について説明する。
「普段使い」項目に給与としてのデジタルマネーが入金されると、資金移動部46は、送金IDが付された仕分け情報に従って、「普段使い」項目に入金されたデジタルマネーの一部を別口座に移動させる。たとえば、図14に示す登録情報データベース33には、利用者ID「U1」の利用者に対し、「送金#1」および「送金#2」の2つの仕分け情報が紐付けられている。一例として、資金移動部46は、利用者ID「U1」の利用者U1に給与としてのデジタルマネーが入金された場合に、利用者ID「U1」に紐付けられた決済口座の「普段使い」項目から、「送金#1」に紐付けられた提供対象「運用#1」によって識別される運用口座に対し、「送金#1」に紐付けられた設定金額「3,000円」を移動させる。
ここで、「送金#1」の仕分け情報は、後述する提案部50による提案に基づいて生成されてもよい。提案部50の内容については、後述する。このように、資金移動部46は、給与として入金されたデジタルマネーのうち提案部50によって提案された金額のデジタルマネーを運用口座に自動的に移動させてもよい。
(推定部47について)
推定部47は、取得部45によって取得される利用者情報のうち、履歴データベース32に記憶された出金履歴情報に基づき、利用者が定期的に購入する取引対象およびその金額を推定する。
一例として、推定部47は、出金履歴情報に基づき、利用者が複数の月にわたって連続で購入している取引対象を特定する。たとえば、推定部47は、図13に示す履歴データベース32を参照し、利用者ID「U1」の利用者U1が、提供者ID「P1」の提供者が提供する金額「5,000円」の提供対象「サプリメント」を複数月(たとえば3ヶ月)連続で購入していることを特定する。この場合、推定部47は、提供者ID「P1」の提供者が提供する金額「5,000円」の提供対象「サプリメント」を、利用者が定期的に購入する取引対象として推定する。
また、推定部47は、取得部45によって取得される利用者情報のうち、履歴データベース32に記憶された出金履歴情報に基づき、その利用者の一月あたりの支出額を推定してもよい。
一例として、推定部47は、履歴データベース32を参照し、利用者の一月あたりの支出額を複数月(たとえば、直近の3ヶ月)分算出し、その平均額(平均支出額)を一月あたりの支出額として推定する。
この際、推定部47は、取引対象を限定して平均支出額を算出してもよい。たとえば、推定部47は、水道、ガス、電気等の公共料金に限定して平均支出額を算出してもよい。また、推定部47は、公共料金に加え、塾等の月謝、家賃、ローン等、毎月必ず支出される固定費に限定して平均支出額を算出してもよい。
また、推定部47は、請求情報データベース34に記憶された請求書情報に基づき、一月あたりの支出額を推定してもよい。
たとえば、推定部47は、図15に示す請求情報データベース34を参照し、利用者ID「U1」に紐付けられた請求書情報として、請求情報ID「請求#1」および「請求#2」の請求情報を特定する。「請求#1」の請求書情報は、利用者ID「U1」の利用者U1に対し、提供者ID「P4」の提供者から、支払期限「2021/3/27」までに取引対象「電気」の代金として金額「8,000円」の支払いが請求されていることを示している。また、「請求#2」の請求書情報は、利用者ID「U1」の利用者U1に対し、提供者ID「P5」の提供者から、支払期限「2021/3/27」までに取引対象「水道」の代金として金額「7,000円」の支払いが請求されていることを示している。
この場合、推定部47は、電気代および水道代の合計金額である「15,000円」を利用者U1の3月の支出額として推定してもよい。
また、推定部47は、給与として入金されたデジタルマネーの金額と利用者情報とに基づき、運用口座に移動させるデジタルマネーの金額を推定してもよい。
たとえば、推定部47は、登録情報データベース33に記憶された利用者の年齢、性別および家族構成の少なくとも1つに基づき、給与の金額に対する運用口座に入金する金額の割合を決定する。たとえば、決済サーバ10は、年齢、性別および家族構成等の組み合わせと上記割合とを紐付けた相場情報(たとえば、「30代の独身男性なら、給与の3%を運用に回す」といった情報)を予め記憶していてもよく、この場合、推定部47は、相場情報に基づいて上記割合を決定してもよい。
そして、推定部47は、給与の金額と上記割合とを用いて、運用口座に移動させるデジタルマネーの金額を推定する。
(判定部48について)
判定部48は、受付部41によって決済情報が受け付けられた場合に、決済の内容が、決済口座における「取り置き」項目に設定された用途と合致するか否かを判定する。
たとえば、決済情報に、利用者ID「U1」、提供者ID「P4」、提供対象「電気」が含まれている場合、判定部48は、決済の内容が、「取り置き#1」の仕分け情報に設定された用途、すなわち、「取り置き#1」に紐付けられた提供者IDおよび提供対象と合致すると判定する。
また、決済情報に、利用者ID「U1」、提供者ID「P1」、提供対象「サプリメント」が含まれている場合、判定部48は、決済の内容が、「取り置き#2」の仕分け情報に設定された用途、すなわち、「取り置き#2」に紐付けられた提供者IDおよび提供対象と合致すると判定する。
(決済処理部49について)
決済処理部49は、受付部41によって受け付けられた決済情報に従って決済処理を実行する。たとえば、決済処理部49は、利用者IDが示す利用者の口座から、提供者IDが示す提供者の口座へと、決済金額が示す額のデジタルマネーを移動させる。
ここで、決済処理部49は、受付部41によって受け付けられた決済情報の内容が、決済口座の「取り置き」項目に設定された用途と合致すると判定部48によって判定された場合、用途が合致する「取り置き」項目の残高を用いて決済処理を行う。
たとえば、受付部41によって受け付けられた決済情報に、利用者ID「U1」、提供者ID「P1」、提供対象「サプリメント」、金額「5,000円」が含まれている場合、決済処理部49は、「取り置き#2」項目の残高「5,000円」から提供者ID「P1」の決済口座に「5,000円」を移動させる。
このように、「取り置き」項目に紐付けられたデジタルマネーの利用は、その「取り置き」項目に設定された用途に限定される。したがって、利用者は、毎月必要となるデジタルマネーを「取り置き」項目に予め取り置きしておくことで、デジタルマネーの無駄遣いを抑制することができる。
(提案部50について)
提案部50は、推定部47による推定結果に基づいて仕分け情報を生成し、生成した仕分け情報の内容を通信部20およびネットワークNを介して利用者端末100に送信して、生成した仕分け情報を用いた給与の取り置きまたは自動送金を行うことを利用者に提案する。
そして、上記提案を承認する旨の通知を通信部20およびネットワークNを介して利用者端末100から受信した場合、提案部50は、登録情報データベース33に対し、承認された仕分け情報を登録情報データベース33に登録する。
なお、提案部50は、利用者が利用者端末100を操作して自ら作成した仕分け情報を通信部20およびネットワークNを介して受信した場合に、受信した仕分け情報を登録情報データベース33に登録してもよい。
(表示制御部44について)
第2実施形態に係る表示制御部44は、給与としてのデジタルマネーの総残高すなわち給与残高を、取り置き残高と普段使い残高とに分けて利用者が利用する利用者端末100に表示させる。
たとえば、表示制御部44は、受付部41によって利用者端末100から給与残高の確認要求が受け付けられた場合に、確認要求に含まれる利用者IDによって識別される利用者の利用者端末100に対し、その利用者が所有する決済口座のうちの給与残高、すなわち、「給与」項目に紐付けられたデジタルマネーの総額を送信する。このとき、表示制御部44は、たとえば、利用者IDに紐付けられた決済口座から「普段使い」項目および「取り置き」項目の各情報を取得し、取得した各情報を決済アプリを介して利用者端末100に表示させる。
利用者端末100に表示される給与残高情報の一例を図16に示す。図16は、第2実施形態に係る利用者端末100の画面の一例を示す図である。図16には、一例として、利用者U1が所有する決済口座の給与残高情報が示されている。
図16に示すように、表示制御部44は、利用者ID「U1」に紐付けられた決済口座から「給与」項目として「525,000円」、「普段使い」項目として「500,000円」および「取り置き」項目として「25,000円」の各情報を取得し、取得した各情報を利用者端末100に表示させる。
このように、表示制御部44は、デジタルマネーの給与残高を普段使い残高と取り置き残高とに分けて利用者が利用する利用者端末100に表示させてもよい。
〔6.管理処理のフロー〕
次に、第2実施形態に係る決済サーバ10の管理処理の手順について説明する。まず、仕分け情報の登録処理について図17を参照して説明する。図17は、第2実施形態に係る管理処理のうち仕分け情報の登録処理の手順の一例を示すフローチャートである。
図17に示すように、決済サーバ10は、推定部47による推定結果に基づき、仕分け情報を生成する(ステップS301)。つづいて、決済サーバ10は、生成した仕分け情報を利用者端末100に送信して、仕分け情報の登録を利用者に提案する(ステップS302)。
つづいて、決済サーバ10は、ステップS302の提案が承認されたか否かを判定する(ステップS303)。提案が承認されたと判定した場合(ステップS303;Yes)、提案した仕分け情報を登録情報データベース33に登録する(ステップS304)。
ステップS304の処理を終えた場合、または、ステップS303において提案が承認されなかった場合(ステップS303,No)、決済サーバ10は、仕分け情報の登録処理を終了する。
次に、資金移動処理について図18を参照して説明する。図18は、第2実施形態に係る管理処理のうち資金移動処理の手順の一例を示すフローチャートである。
図18に示すように、決済サーバ10は、給与としてのデジタルマネーを口座データベース31の普段使い残高(「普段使い」項目)に入金する(ステップS401)。つづいて、決済サーバ10は、「取り置きID」が紐付けられた仕分け情報(「取り置き」仕分け情報)が登録情報データベース33に登録されているか否かを判定する(ステップS402)。「取り置き」仕分け情報が登録されていると判定した場合(ステップS402;Yes)、決済サーバ10は、「取り置き」仕分け情報に従って、普段使い残高から取り置き残高へデジタルマネーを移動させる(ステップS403)。
ステップS403の処理を終えた場合、または、ステップS402において「取り置き」仕分け情報が登録されていない場合(ステップS403;No)、決済サーバ10は、「送金ID」が紐付けられた仕分け情報(「送金」仕分け情報)が登録情報データベース33に登録されているか否かを判定する(ステップS404)。「送金」仕分け情報が登録されていると判定した場合(ステップS404;Yes)、決済サーバ10は、「送金」仕分け情報に従って、普段使い残高から別口座へデジタルマネーを移動させる(ステップS405)。
ステップS405の処理を終えた場合、または、ステップS404において「送金」仕分け情報が登録されていない場合(ステップS404;No)、決済サーバ10は、資金移動処理を終了する。
次に、決済処理について図19を参照して説明する。図19は、第2実施形態に係る管理処理のうち決済処理の手順の一例を示すフローチャートである。
図19に示すように、決済サーバ10は、決済情報を取得する(ステップS501)。つづいて、決済サーバ10は、取得した決済情報の内容が取り置き残高に設定された用途と合致するか否かを判定する(ステップS502)。取り置き残高に設定された用途と合致すると判定した場合(ステップS502;Yes)、決済サーバ10は、取り置き残高を用いて決済処理を行う(ステップS503)。
一方、ステップS502において、取り置き残高に設定された用途と合致しない場合(ステップS502;No)、決済サーバ10は、普段使い残高を用いて決済処理を行う(ステップS504)。ステップS503またはステップS504の処理を終えると、決済サーバ10は、決済処理を終了する。
〔7.変形例〕
上述の実施形態は一例を示したものであり、種々の変更および応用が可能である。
上述した実施形態では、給与として入金されたデジタルマネーの一部を移動させる場合の例について説明したが、これと同様に、給与以外のデジタルマネーの一部を取り置きしたり、別口座に移動させたりしてもよい。たとえば、図12に示す口座データベース31において、「給与以外」項目に、「普段使い」項目や「取り置き」項目といった項目が含まれていてもよい。この場合、給与以外の名目を含んだ入金要求が受け付けられた場合に、入金要求に含まれる「金額」のデジタルマネーを決済口座の「給与以外」項目のうち「普段使い」項目に格納する。「普段使い」項目に格納されたデジタルマネーの一部は、その後、後述する資金移動部46によって、「給与」項目のうちの「取り置き」項目や給与が入金された決済口座以外の口座に移動されることとなる。このように、資金移動処理は、給与以外のデジタルマネーを対象として実行されてもよい。
支払元サーバ400から決済サーバ10に送信される入金要求には、「支払日」の情報が含まれていてもよい。「支払日」は、入金処理が実行される日付を指定する情報である。この場合、決済サーバ10は、入金要求に含まれる「支払日」によって指定された支払日に入金処理を実行する。言い換えれば、決済サーバ10は、「支払日」によって指定された支払日まで入金処理を保留する。このように、管理システム1は、給与のデジタル支払いを予約することができるように構成されてもよい。
なお、「支払日」の情報は、月日のうち少なくとも月の情報を含んでいればよい。たとえば、「支払日」の情報として「4月」が含まれる場合、決済サーバ10は、4月の予め決められた日(たとえば4月25日)に入金処理を実行すればよい。
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、逆に、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。たとえば、各図に示した各種情報は、図示した情報に限られない。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、上記してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
〔8.効果〕
上述してきたように、実施形態に係る決済サーバ10は、所定のコードの読み取りによる電子決済に用いられるデジタルマネーの残高を管理する管理装置であって、受付部41と、入金処理部42とを有する。受付部41は、デジタルマネーの入金を受ける利用者の識別情報および入金の名目を含む入金要求を受け付ける。入金処理部42は、受付部41によって受け付けられた入金要求に含まれる名目が給与である場合に、当該入金要求に含まれる識別情報に紐付けられた総残高のうち給与残高に対する入金処理を行い、受付部41によって受け付けられた入金要求に含まれる名目が給与以外の名目である場合には、当該入金要求に含まれる識別情報に紐付けられた総残高のうち給与以外残高に対する入金処理を行う。
これにより、実施形態に係る決済サーバ10は、利用者が所有するデジタルマネーの残高を、給与残高と給与以外残高とに分けて管理することができる。したがって、実施形態に係る決済サーバ10によれば、給与のデジタル支払いが行われた場合に、給与を含む残高を適切に管理することができる。
また、実施形態に係る決済サーバ10において、受付部41は、利用者の識別情報を含むATMへの出金要求を受け付ける。また、実施形態に係る決済サーバ10は、受付部41によって出金要求が受け付けられた場合に、出金要求に含まれる識別情報に紐付けられた総残高のうち給与残高からの出金処理を行う出金処理部43を有する。
これにより、利用者は、デジタルマネーで受け取った給与を現金化する際に、銀行口座を経由することなく(すなわち、デジタルマネーを一旦銀行口座に移動させることなく)、直接ATMから引き出すことができる。
また、実施形態に係る決済サーバ10は、総残高を給与残高と給与以外残高とに分けて利用者が利用する利用者端末100に表示させる表示制御部44を有する。
これにより、利用者は、自身の決済口座に入金された給与の残高を容易に確認することができる。また、利用者は、自身が所有するデジタルマネーの総残高のうち、ATMで現金化することができるデジタルマネーの残高を容易に把握することができる。
また、実施形態に係る決済サーバ10は、取得部45と、受付部41と、資金移動部46とを有する。取得部45は、所定の決済手段を利用する利用者に関する利用者情報を取得する。受付部41は、利用者に対するデジタルマネーの入金を受け付ける。資金移動部46は、受付部41によって入金が受け付けられたデジタルマネーのうち、給与として入金されたデジタルマネーの一部を取得部45によって取得された利用者情報に基づいて移動させる。
これにより、利用者は、給与として入金されたデジタルマネーの一部を、たとえば毎月必要となる光熱費等のために取り置きしたり、あるいは、運用口座などの決済口座以外の口座に自動的に送金したりすることができる。したがって、実施形態に係る決済サーバ10によれば、給与のデジタル支払いに対応する電子決済サービスの利用を促進させることができる。
また、実施形態に係る決済サーバ10において、資金移動部46は、給与として入金されたデジタルマネーの一部を、給与としてのデジタルマネーが入金された決済口座以外の口座に移動させる。これにより、利用者は、たとえば端末操作を操作することなく、入金された給与のうちの一部を所定の口座に移動させることができる。したがって、実施形態に係る決済サーバ10によれば、給与のデジタル支払いに対応する電子決済サービスの利用を促進させることができる。
また、実施形態に係る決済サーバ10において、決済口座以外の口座は、運用口座である。実施形態に係る決済サーバ10は、給与として入金されたデジタルマネーの金額と利用者情報とに基づき、運用口座に移動させるデジタルマネーの金額を推定する推定部47をさらに有する。資金移動部46は、給与として入金されたデジタルマネーのうち推定部47によって推定された金額のデジタルマネーを運用口座に移動させる。
これにより、利用者は、たとえば端末操作を操作することなく、入金された給与のうちの一部を運用口座に移動させることができる。また、運用口座に移動させるデジタルマネーの金額が推定部47によって推定されるため、利用者は、給与のうちいくらを運用に回すかについて悩むことがない。したがって、実施形態に係る決済サーバ10によれば、給与のデジタル支払いに対応する電子決済サービスの利用を促進させることができる。
また、実施形態に係る決済サーバ10において、資金移動部46は、給与として入金されたデジタルマネーの一部を、給与としてのデジタルマネーが入金された決済口座のうちの取り置き残高に移動させる。
これにより、利用者は、たとえば毎月必要となるデジタルマネーを決済口座内で取り置きしておくことができるため、デジタルマネーの無駄遣いを抑制することができる。
また、実施形態に係る決済サーバ10は、判定部48と、決済処理部49とを有する。判定部48は、所定の決済手段を用いた決済に関する決済情報が取得された場合に、決済の内容が、取り置き残高に設定された用途と合致するか否かを判定する。決済処理部49は、判定部48によって決済の内容が用途と合致すると判定された場合に、取り置き残高を用いた決済処理を行う。
これにより、取り置き残高に入金されたデジタルマネーの用途を限定することができる。言い換えれば、取り置き残高に入金されたデジタルマネーがその用途以外の用途に使用されることを抑制することができる。
また、実施形態に係る決済サーバ10は、取得部45によって取得される利用者情報のうち、利用者が所有する決済口座の出金履歴情報に基づき、一月あたりの支出額を推定する推定部47を有する。資金移動部46は、推定部47によって推定された支出額に基づき、給与として入金されたデジタルマネーの一部を取り置き残高に移動させる。
このように、推定部47によって推定された一月あたりの支出額を取り置き残高に取り置くことで、利用者によるデジタルマネーの使い過ぎを抑制することができる。
また、実施形態に係る決済サーバ10は、取得部45によって取得される利用者情報のうち、利用者に対する請求の内容を示す請求書情報に基づき、一月あたりの支出額を推定する推定部47を有する。資金移動部46は、推定部47によって推定された支出額に基づき、給与として入金されたデジタルマネーの一部を取り置き残高に移動させる。
このように、推定部47によって推定された一月あたりの支出額を取り置き残高に取り置くことで、利用者によるデジタルマネーの使い過ぎを抑制することができる。また、請求書情報に基づいて支出額を推定することで、一月あたりの支出額をより精度よく推定することができる。
また、実施形態に係る決済サーバ10は、給与としてのデジタルマネーの総残高を、取り置き残高と、取り置き残高以外の残高とに分けて利用者の利用者端末100に表示させる表示制御部44を有する。
これにより、利用者は、自身の決済口座に入金された給与の残高のうち、用途が限定されているデジタルマネーの残高と、自由に使えるデジタルマネーの残高とを容易に把握することができる。
〔9.ハードウェア構成〕
また、上述してきた各実施形態に係る決済サーバ10は、たとえば、図20に示すような構成のコンピュータ1000によって実現される。以下、決済サーバ10を例に挙げて説明する。図20は、決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ1000は、CPU1100、RAM1200、ROM1300、HDD1400、通信インターフェイス(I/F)1500、入出力インターフェイス(I/F)1600、およびメディアインターフェイス(I/F)1700を有する。
CPU1100は、ROM1300又はHDD1400に格納されたプログラムに基づいて動作し、各部の制御を行う。ROM1300は、コンピュータ1000の起動時にCPU1100によって実行されるブートプログラムや、コンピュータ1000のハードウェアに依存するプログラム等を格納する。
HDD1400は、CPU1100によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス1500は、通信網500(実施形態のネットワークNに対応する)を介して他の機器からデータを受信してCPU1100へ送り、また、通信網500を介してCPU1100が生成したデータを他の機器へ送信する。
CPU1100は、入出力インターフェイス1600を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。CPU1100は、入出力インターフェイス1600を介して、入力装置からデータを取得する。また、CPU1100は、入出力インターフェイス1600を介して生成したデータを出力装置へ出力する。
メディアインターフェイス1700は、記録媒体1800に格納されたプログラム又はデータを読み取り、RAM1200を介してCPU1100に提供する。CPU1100は、かかるプログラムを、メディアインターフェイス1700を介して記録媒体1800からRAM1200上にロードし、ロードしたプログラムを実行する。記録媒体1800は、たとえばDVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
たとえば、コンピュータ1000が決済サーバ10として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部40の機能を実現する。また、HDD1400には、決済サーバ10の記憶装置内の各データが格納される。コンピュータ1000のCPU1100は、これらのプログラムを記録媒体1800から読み取って実行するが、他の例として、他の装置から所定の通信網を介してこれらのプログラムを取得してもよい。
〔10.その他〕
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
また、上述した決済サーバ10は、機能によっては外部のプラットフォーム等をAPI(Application Programming Interface)やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。
また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。たとえば、受付部は、受付手段や受付回路に読み替えることができる。