JP7242819B1 - 情報処理装置、情報処理方法および情報処理プログラム - Google Patents

Abstract

【課題】利用者の利便性を向上させる。【解決手段】本願に係る情報処理装置は、利用者の利用者端末に送信された請求書が示す請求書情報と、利用者による請求書に関する支払日時の指定とを受け付ける受付部と、請求書情報に基づく決済を、指定を受け付けられた支払日時に行う決済処理部と、を備えることを特徴とする。【選択図】図１

Description

本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。

従来、電子化された請求書（適宜、「電子請求書」）を利用者の端末に送信し、請求書の請求金額を電子マネーで決済可能とするサービスを提供するための技術が知られている。また、紙の請求書であっても、請求書に印刷された請求金額等の情報を読み取り、電子マネーで決済可能とするサービスを提供するための技術も知られている。

特開２００７－３０５１６６号公報

しかしながら、上記の従来技術では、利用者にとって利便性が良いとは限らない。

例えば、上記の従来技術では、請求書への支払を実行するタイミングは利用者が支払手続を行ったタイミングであり、支払忘れが起こる可能性がある。また、上記の従来技術では、利用者が支払を行いたいタイミング（例えば、給料日後）に支払ができるとは限らない。

本願は、上記に鑑みてなされたものであって、利用者の利便性を向上させる情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、利用者の利用者端末に送信された請求書が示す請求書情報と、前記利用者による前記請求書に関する支払日時の指定とを受け付ける受付部と、前記請求書情報に基づく決済を、指定を受け付けられた前記支払日時に行う決済処理部と、を備えることを特徴とする。

本願に係る情報処理方法は、コンピュータが実行する情報処理方法であって、利用者の利用者端末に送信された請求書が示す請求書情報と、前記利用者による前記請求書に関する支払日時の指定とを受け付ける受付工程と、前記請求書情報に基づく決済を、指定を受け付けられた前記支払日時に行う決済処理工程と、を含むことを特徴とする。

本願に係る情報処理プログラムは、利用者の利用者端末に送信された請求書が示す請求書情報と、前記利用者による前記請求書に関する支払日時の指定とを受け付ける受付手順と、前記請求書情報に基づく決済を、指定を受け付けられた前記支払日時に行う決済処理手順と、をコンピュータに実行させることを特徴とする。

実施形態の一態様によれば、利用者の利便性を向上させることができるという効果を奏する。

図１は、実施形態に係る情報処理の一例を示す図である。 図２は、実施形態に係る決済サーバの構成例を示す図である。 図３は、実施形態に係る口座データベースの一例を示す図である。 図４は、実施形態に係る請求書情報データベースの一例を示す図である。 図５は、実施形態に係る利用者情報データベースの一例を示す図である。 図６は、実施形態に係る情報処理の手順の一例を示すフローチャートである。 図７は、決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に本願に係る情報処理装置、情報処理方法および情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．情報処理システム〕
図１を用いて、本実施形態の情報処理装置等により実現される情報処理について説明する。図１は、実施形態に係る情報処理の一例を示す図である。なお、図１では、本実施形態に係る情報処理装置の一例である決済サーバ１０によって、実施形態に係る情報処理等が実現されるものとする。

〔１－１．情報処理システムの構成〕
図１に示すように、実施形態に係る情報処理システム１は、決済サーバ１０と、利用者端末１００と、事業者端末２００とを含む。決済サーバ１０、利用者端末１００および事業者端末２００は、ネットワークＮ（例えば、図２参照）を介して有線または無線により相互に通信可能に接続される。ネットワークＮは、例えば、インターネットなどのＷＡＮ（Wide Area Network）である。なお、図１に示した情報処理システム１には、複数台の決済サーバ１０、複数台の利用者端末１００および複数台の事業者端末２００が含まれていてもよい。

図１に示す決済サーバ１０は、実施形態に係る情報処理を実行する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。例えば、決済サーバ１０は、利用者端末１００を用いる電子決済に関する電子決済サービスを提供する。例えば、決済サーバ１０は、取引対象の提供者（事業者）や取引対象が提供される利用者の口座を管理しており、利用者からの決済要求に従って、口座間において電子マネーの移行等を行うことで、各種決済を実現する。なお、電子マネーとは、例えば、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドル等の国家により提供される貨幣を電子的に取引可能としたものであってもよい。

図１に示す利用者端末１００は、利用者Ｕ１によって利用される情報処理装置である。利用者端末１００は、例えば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）等により実現される。また、利用者端末１００は、決済サーバ１０によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１に示す例では、利用者端末１００がスマートフォンである場合を示す。

図１に示す事業者端末２００は、利用者に取引対象を提供する事業者によって利用される情報処理装置である。事業者端末２００は、例えば、スマートフォンや、タブレット型端末、ノート型ＰＣ、デスクトップＰＣ、携帯電話機、ＰＤＡ等により実現される。また、事業者端末２００は、決済サーバ１０によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１に示す例では、事業者端末２００がデスクトップＰＣである場合を示す。

なお、利用者端末１００および事業者端末２００は、所定の情報処理を実現する制御情報を決済サーバ１０から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）等のスクリプト言語やＣＳＳ（Cascading Style Sheets）等のスタイルシート言語、Ｊａｖａ（登録商標）等のプログラミング言語、ＨＴＭＬ（HyperText Markup Language）等のマークアップ言語等により記述される。なお、決済サーバ１０から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。

〔１－２．利用者端末１００を用いた決済処理〕
ここで、決済サーバ１０が実行する情報処理に先立ち、利用者端末１００を用いた決済（電子決済）の一例について説明する。なお、以下の説明では、店舗に配置された２次元コード（ＱＲコード（登録商標））であって、店舗を識別する店舗識別情報を示す２次元コードを用いて、利用者Ｕ１が利用者端末１００を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意の利用者Ｕ１が任意の利用者端末１００を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報は、ＱＲコード（登録商標）のみならず、バーコードや所定のマーク、番号等であってもよい。

例えば、利用者Ｕ１が店舗にて各種の商品やサービスといった決済対象の利用や購入に伴う決済を行う場合、利用者Ｕ１は、利用者端末１００に予めインストールされた決済用のアプリケーションを起動する。そして、利用者Ｕ１は、アプリケーションを介して、店舗に設置された店舗識別情報を撮影する。このような場合、利用者端末１００は、決済対象の価格を入力するための画面を表示し、利用者Ｕ１あるいは店舗の店員から決済額の入力を受付ける。そして、利用者端末１００は、利用者Ｕ１を識別する利用者情報と、店舗識別情報（もしくは、店舗識別情報が示す情報、すなわち、店舗を示す情報）と、決済額とを示す決済情報を決済サーバ１０へと送信する。

このような場合、決済サーバ１０は、利用者情報が示す利用者Ｕ１の口座から、店舗識別情報が示す店舗の口座へと、決済額が示す額の電子マネーを移行させる。そして、決済サーバ１０は、決済が完了した旨の通知を利用者端末１００へと送信する。このような場合、利用者端末１００は、決済が完了した旨の画面や所定の音声を出力することで、電子マネーによる決済が行われた旨を通知する。

なお、利用者端末１００を用いた決済は、上述した処理に限定されるものではない。例えば、利用者端末１００を用いた決済は、店舗に設置された店舗端末を用いたものであってもよい。例えば、利用者端末１００は、利用者Ｕ１を識別するための利用者識別情報を画面上に表示させる。このような場合、店舗に設置された店舗端末は、利用者端末１００に表示された利用者識別情報を読み取り、利用者識別情報と、決済額と、店舗を識別する情報とを示す決済情報を決済サーバ１０へと送信する。このような場合、決済サーバ１０は、利用者識別情報が示す利用者Ｕ１の口座から、店舗の口座へと、決済額が示す額の電子マネーを移行させ、店舗の店舗端末あるいは利用者端末１００に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。

また、利用者端末１００を用いた決済は、利用者Ｕ１が予め電子マネーをチャージした口座から店舗の口座へと電子マネーを移行させる処理のみならず、例えば、利用者Ｕ１が予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、決済サーバ１０は、店舗の口座に対して決済額の電子マネーを送金するとともに、利用者Ｕ１のクレジットカードの運用会社に対し、決済額を請求してもよい。

また、利用者端末１００を用いた決済は、利用者Ｕ１の口座から店舗の口座へと電子マネーを移行させる処理のみならず、例えば、利用者Ｕ１の口座から、所定の取引対象を提供する提供者（事業者）の口座へと電子マネーを移行させる決済であってもよい。このような場合、利用者Ｕ１は、事業者が利用者Ｕ１に対して送付した支払帳票（例えば、コンビニ収納代行サービスにおいて用いられる振込票）に含まれるバーコードを、利用者端末１００が備える撮影装置（カメラ）で読み取る。そして、利用者端末１００は、読み取ったバーコードが示す支払先や支払額を画面に表示し、利用者Ｕ１から当該支払先に対する送金を承認する旨の操作を受け付けた場合、利用者識別情報と、支払額と、支払先を識別する情報とを示す決済情報を決済サーバ１０へと送信する。このような場合、決済サーバ１０は、利用者Ｕ１の口座から、支払先の口座へと、支払額が示す額の電子マネーを移行させる。

〔１－３．情報処理システム１の処理〕
ここで、従来、電子請求書を利用者の端末に送信し、請求書の請求金額を電子マネーで決済可能とするサービスを提供するための技術が知られている。しかしながら、このような技術では、請求書への支払を実行するタイミングは利用者が支払手続を行ったタイミングであり、支払忘れが起こる可能性があり、利用者にとって利便性がよいとは限らない。

そこで、決済サーバ１０は、実施形態に係る情報処理を実行する。以下、図１を用いて、決済サーバ１０が実行する情報処理について説明する。なお、以下の説明では、利用者端末１００が利用者Ｕ１により利用される例を示す。また、以下の説明では、利用者端末１００を利用者Ｕ１と同一視する場合がある。すなわち、以下では、利用者Ｕ１を利用者端末１００と読み替えることもできる。

まず、事業者端末２００から利用者端末１００に電子請求書Ｂ１が送信される（ステップＳ１）。ここで、電子請求書Ｂ１は、上述した電子マネーを用いたオンライン決済可能な請求書であり、請求書情報を含む。また、請求書情報とは、請求元である事業者の識別情報、請求先である利用者の識別情報、請求金額、支払期限等を含む情報である。図１の例では、利用者端末１００の画面上に請求書情報を含むバーコードが表示され、オンラインによる決済の他、店舗においてバーコードを読み取ることによって実店舗での決済も可能である。なお、利用者端末１００等に表示される請求書情報は、バーコードのみならず、２次元コード（ＱＲコード（登録商標））や所定のマーク、番号等であってもよい。

次に、利用者Ｕ１は、利用者端末１００を用いて、支払日時を指定する（ステップＳ２）。例えば、利用者Ｕ１は、電子請求書Ｂ１を受信する際または電子請求書Ｂ１を選択する際に、利用者端末１００の画面に表示されたカレンダーＣ１上で希望する日付をタップして選択することで、支払日時を指定する。また、利用者Ｕ１は、利用者端末１００の画面に表示された入力画面に直接希望する日時を入力することもできる。

このとき、利用者Ｕ１は、電子請求書Ｂ１を受信する前または電子請求書Ｂ１を選択する前に、支払日時を指定してもよい。例えば、利用者Ｕ１は、受信前や選択前にカレンダーＣ１上で支払日時を指定したり、直接日時を入力したりする他に、月々の支払日（例：毎月３０日）を事前に設定しておいてもよいし、請求書ごとの支払期限日に支払を実行する指定をしてもよいし、受信や選択した直後に支払を実行する指定をしてもよい。

続いて、決済サーバ１０は、利用者端末１００から請求書情報と支払日時の指定とを受け付ける（ステップＳ３）。例えば、決済サーバ１０は、請求書Ｂ１が示す請求書情報として、事業者ＩＤや利用者ＩＤ等の識別情報、請求金額、支払期限等を受け付ける。また、決済サーバ１０は、利用者Ｕ１が指定した支払日時として、支払を行う年月日や時刻、月々の支払日（例：毎月末）、支払実行条件（例：支払期限日に支払う、受信直後に支払う等）の指定を受け付ける。また、決済サーバ１０は、利用者端末１００から受け付けた請求書情報を記憶することもできる。

このとき、決済サーバ１０は、利用者端末１００から受け付けた支払日時の指定が支払可能期間でない場合（例：支払期限後の指定）には、その旨の通知を利用者端末１００に送信し、支払可能期間内で再指定するように促すこともできる。また、決済サーバ１０は、利用者端末１００から支払日時の再指定や支払日時の変更を受け付けることもできる。

続いて、決済サーバ１０は、請求書情報に基づく決済処理を、利用者Ｕ１が指定した支払日時に実行する（ステップＳ４）。例えば、決済サーバ１０は、利用者Ｕ１の口座から請求元である事業者の口座へと、請求書情報として記載された請求金額分の電子マネーを移行させる。また、決済サーバ１０は、記憶した請求書情報に基づく決済処理を、利用者Ｕ１が指定した支払日時に実行することもできる。

このとき、決済サーバ１０は、利用者Ｕ１の口座の残高が請求金額に対して不足している場合には、事前に設定された利用者Ｕ１の別の口座から電子マネーを移行（自動チャージ）し、決済処理を実行することもできる。

最後に、決済サーバ１０は、利用者Ｕ１の請求書の決済に関する情報を通知する（ステップＳ５）。例えば、決済サーバ１０は、利用者端末１００に対して、利用者Ｕ１の請求書の決済が完了した旨の通知を実行する。

このとき、決済サーバ１０は、請求書の決済処理に際して、自動チャージが行われた場合には、その旨の通知を実行してもよい。また、決済サーバ１０は、請求書の決済処理に際して、電子マネーの残高不足により決済処理が完了できなかった場合には、その旨の通知を行い、支払方法を利用者Ｕ１に選択させる画面を利用者端末１００に表示してもよい。また、決済サーバ１０は、利用者Ｕ１の毎月支払の履歴に基づいて、支払忘れをしている可能性がある場合（例：毎月末までに支払われている水道料金の支払がない）には、その旨の通知を行うこともできる。

以上のように、実施形態に係る決済サーバ１０は、利用者の指定に基づき、請求書の支払予約を可能とし、請求書払いの支払忘れを防止することができる。すなわち、実施形態に係る決済サーバ１０は、利用者の利便性を向上させることができる。さらに、実施形態に係る決済サーバ１０は、支払忘れや電子マネーの残高不足を防止するための様々な通知を可能としたりすることによって、より利用者の利便性を向上させることができる。

〔２．決済サーバの構成〕
次に、図２を用いて、決済サーバ１０の構成について説明する。図２は、実施形態に係る決済サーバの構成例を示す図である。図２に示すように、決済サーバ１０は、通信部２０と、記憶部３０と、制御部４０とを有する。

〔２－１．通信部２０〕
通信部２０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部２０は、ネットワークＮと有線または無線で接続され、利用者端末１００、事業者端末２００等との間で情報の送受信を行う。

〔２－２．記憶部３０〕
記憶部３０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図２に示すように、記憶部３０は、口座データベース３１と、請求書情報データベース３２と、利用者情報データベース３３とを有する。

（口座データベース３１）
口座データベース３１は、利用者や事業者等が電子決済サービスにおいて所有する口座に関する各種の情報を記憶する。ここで、図３を用いて、口座データベース３１が記憶する情報の一例を説明する。図３は、実施形態に係る口座データベースの一例を示す図である。図３の例において、口座データベース３１は、「口座ＩＤ」、「所有者情報」、「口座残高」といった項目を有する。

「口座ＩＤ」は、口座を識別するための識別情報を示す。「所有者情報」は、口座を所有する所有者に関する情報を示し、例えば、所有者を識別するための識別情報が格納される。「口座残高」は、口座の残高を示す。

すなわち、図３では、口座ＩＤ「ＡＩＤ＃１」によって識別される口座の保有者の情報が「利用者＃１」であり、口座残高が「７，８００円」である例を示す。

（請求書情報データベース３２）
請求書情報データベース３２は、請求元である事業者が作成した請求書が示す各種の情報を記憶する。ここで、図４を用いて、請求書情報データベース３２が記憶する情報の一例を説明する。図４は、実施形態に係る請求書情報データベースの一例を示す図である。図４の例において、請求書情報データベース３２は、「請求書ＩＤ」、「事業者ＩＤ」、「請求金額」、「支払期限」といった項目を有する。

「請求書ＩＤ」は、事業者が作成した請求書を識別するための識別情報を示す。「事業者ＩＤ」は、請求書の作成を行った事業者を識別するための識別情報を示す。「請求金額」は、事業者が利用者に請求する金額を示す。「支払期限」は、利用者が事業者に請求金額を支払可能な期限を示す。

すなわち、図４では、請求書ＩＤ「ＢＩＤ＃１」により識別される請求書が事業者ＩＤ「ＭＩＤ＃１」により識別される事業者により作成され、請求金額が「請求金額＃１」、支払期限が「支払期限＃１」である例と、請求書ＩＤ「ＢＩＤ＃２」により識別される請求書が事業者ＩＤ「ＭＩＤ＃２」により識別される事業者により作成され、請求金額が「請求金額＃２」、支払期限が「支払期限＃２」である例とを示す。

（利用者情報データベース３３）
利用者情報データベース３３は、決済サーバ１０が提供する電子決済サービスの利用者に関する各種の情報を記憶する。ここで、図５を用いて、利用者情報データベース３３が記憶する情報の一例を説明する。図５は、実施形態に係る利用者情報データベースの一例を示す図である。図５の例において、利用者情報データベース３３は、「利用者ＩＤ」、「決済履歴」、「請求書ＩＤ」、「支払日時」といった項目を有する。

「利用者ＩＤ」は、利用者を識別するための識別情報を示す。「決済履歴」は、電子決済サービスを利用して行った決済の履歴を示し、例えば、決済先や、決済金額等といった情報が格納される。「請求書ＩＤ」は、事業者が作成した請求書を識別するための識別情報を示す。「支払日時」は、利用者が当該請求書の支払を希望する日時（支払予約日時）等を示す。

すなわち、図５では、利用者ＩＤ「ＵＩＤ＃１」によって識別される利用者の決済履歴が「決済履歴＃１」、「ＢＩＤ＃１」により識別される請求書の支払予約日時が「支払日時＃１」であり、「ＢＩＤ＃２」により識別される請求書の支払予約日時が「支払日時＃２」である例を示す。

〔２－３．制御部４０〕
制御部４０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、決済サーバ１０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部４０は、コントローラであり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。実施形態に係る制御部４０は、図２に示すように、受付部４１と、決済処理部４２と、通知部４３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。

（受付部４１）
受付部４１は、利用者の利用者端末に送信された請求書が示す請求書情報を受け付ける。例えば、受付部４１は、事業者端末２００が送信し、利用者端末１００が受信した電子請求書Ｂ１に含まれる請求書情報を受け付ける。また、受付部４１は、利用者端末１００が受信した複数の電子請求書のうち、利用者Ｕ１が選択した電子請求書Ｂ１に含まれる請求書情報を受け付けてもよい。ここで、受付部４１は、請求書情報として、請求書ＩＤ、事業者ＩＤ、請求金額、支払期限等を受け付ける。

また、受付部４１は、利用者による請求書に関する支払日時の指定を受け付ける。例えば、受付部４１は、利用者端末１００に表示された指定画面から、利用者Ｕ１の操作によって当該請求書の支払日時の予約を受け付ける。ここで、受付部４１は、利用者Ｕ１によって直接入力された支払日時を受け付けてもよいし、利用者Ｕ１によって利用者端末１００の画面に表示されたカレンダーをタップすることで指定された支払日時を受け付けてもよい。また、受付部４１は、月々の支払日（例：毎月３０日）の指定を受け付けてもよいし、請求書ごとの支払期限日に支払いを実行する指定を受け付けてもよいし、撮影して取り込んだ直後に支払を実行する指定を受け付けてもよい。

さらに、受付部４１は、電子請求書Ｂ１を受信する前または電子請求書Ｂ１を選択する前に、指定された支払日時を受け付けてもよい。例えば、受付部４１は、直接入力や画面上のカレンダー等を用いた支払日時を事前に受け付けるだけではなく、月々の支払日の指定を事前に受け付けてもよいし、請求書ごとの支払期限日に支払いを実行する指定を事前に受け付けてもよいし、受信や選択した直後に支払を実行する指定を事前に受け付けてもよい。

また、受付部４１は、支払日時の変更を受け付ける。例えば、受付部４１は、決済が完了していない請求書Ｂ１に関して、支払可能な期間内において、支払を希望する支払日時等の変更を受け付ける。また、受付部４１は、将来的に決済する請求書に関して、支払を希望する支払日時の指定の変更を受け付けてもよい。

なお、受付部４１は、受け付けた請求書情報を請求書情報データベース３２に格納する。また、受付部４１は、受け付けた支払日時の指定や支払日時の変更を利用者情報データベース３３に格納する。

（決済処理部４２）
決済処理部４２は、請求書情報に基づく決済を、指定を受け付けられた支払日時に行う。例えば、決済処理部４２は、利用者Ｕ１の利用者端末１００によって受信された請求書が示す請求書情報に基づく決済を行う。また、決済処理部４２は、記憶部３０に記憶された請求書情報に基づく決済を行うこともできる。

このとき、決済処理部４２は、利用者ＩＤが示す利用者Ｕ１の口座から、事業所ＩＤが示す事業者の口座へと、請求金額が示す額の電子マネーを、指定された支払日時に移行させる。また、決済処理部４２は、請求書情報に基づく決済を、変更を受け付けられた支払日時に行う。さらに、決済処理部４２は、請求書情報に基づく決済の請求金額に対して利用者Ｕ１が所有する電子マネーが不足している場合には、利用者Ｕ１が設定した所定の口座から不足する金額を電子マネーとして移行し、当該決済を行う。また、利用者端末１００を用いた決済は、利用者Ｕ１が予め電子マネーをチャージした口座から店舗Ａの口座へと電子マネーを移行させる処理のみならず、例えば、利用者Ｕ１が予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、利用者端末１００は、店舗Ａの口座に対して決済金額の電子マネーを移行させるとともに、利用者Ｕ１のクレジットカードの運用会社に対し、決済金額を請求してもよい。

（通知部４３）
通知部４３は、利用者Ｕ１に対して、決済に関する情報を通知する。例えば、通知部４３は、指定された支払日時が請求書情報に基づく支払可能な日時でない場合には、利用者Ｕ１に対して、支払日時の再指定を促す通知を行う。また、通知部４３は、利用者Ｕ１の過去の決済履歴に基づいて、利用者Ｕ１に対して、完了していない可能性がある決済に関する通知を行う。また、通知部４３は、決済の請求金額に対して利用者Ｕ１が所有する電子マネーが不足している場合には、利用者Ｕ１に対して、電子マネーが不足している旨の通知を行う。さらに、通知部４３は、決済の請求金額に対して利用者Ｕ１が所有する電子マネーが不足している場合には、利用者Ｕ１に対して、電子マネーの入金を促す通知を行う。

〔３．提供処理のフロー〕
図６を用いて、実施形態に係る決済サーバ１０の情報処理の手順について説明する。図６は、実施形態に係る情報処理の手順の一例を示すフローチャートである。なお、下記のステップＳ１０１～Ｓ１０４は、異なる順序で実行することもできる。また、下記のステップＳ１０１～Ｓ１０４のうち、省略される処理があってもよい。

第１に、決済サーバ１０の受付部４１は、請求書情報受付処理を実行する（ステップＳ１０１）。例えば、受付部４１は、事業者端末２００によって利用者端末１００に送信された電子請求書Ｂ１に含まれる請求書情報を受け付ける。

第２に、受付部４１は、支払日時受付処理を実行する（ステップＳ１０２）。例えば、受付部４１は、利用者Ｕ１によって利用者端末１００を用いて指定された支払日時を受け付ける。

第３に、決済処理部４２は、決済処理を実行する（ステップＳ１０３）。例えば、決済処理部４２は、請求書情報に基づく決済処理を、利用者Ｕ１が指定した支払日時に実行する。

第４に、通知部４３は、通知処理を実行し（ステップＳ１０４）、処理を終了する。例えば、通知部４３は、利用者Ｕ１の請求書の決済に関する情報（例：決済金額の不足、自動チャージ完了等）を通知する。

〔４．効果〕
上述してきたように、実施形態に係る決済サーバ１０は、受付部４１と、決済処理部４２と、通知部４３とを有する。

受付部４１は、利用者Ｕ１の利用者端末１００に送信された請求書が示す請求書情報と、利用者Ｕ１による請求書に関する支払日時の指定とを受け付ける。決済処理部４２は、請求書情報に基づく決済を、指定を受け付けられた支払日時に行う。これにより、実施形態に係る決済サーバ１０は、利用者の利便性を向上させることができる。

また、通知部４３は、支払日時が請求書情報に基づく支払可能な日時でない場合には、利用者Ｕ１に対して、支払日時の再指定を促す通知を行う。これにより、実施形態に係る決済サーバ１０は、支払可能期限を管理することで利用者の利便性を向上させることができる。

また、受付部４１は、支払日時の変更をさらに受け付け、決済処理部４２は、決済を、変更を受け付けられた支払日時に行う。これにより、実施形態に係る決済サーバ１０は、支払予約の変更を可能にすることで利用者の利便性を向上させることができる。

通知部４３は、利用者Ｕ１の過去の決済履歴に基づいて、利用者Ｕ１に対して、完了していない可能性がある決済に関する通知をさらに行う。これにより、実施形態に係る決済サーバ１０は、請求書の支払忘れをさらに防止することが可能となり利用者の利便性を向上させることができる。

決済処理部４２は、決済の請求金額に対して利用者Ｕ１が所有する電子マネーが不足している場合には、利用者Ｕ１が設定した所定の口座から不足する金額を電子マネーとして移行し、決済を行う。これにより、実施形態に係る決済サーバ１０は、電子マネーのチャージ忘れによる支払不能を防止することが可能となり利用者の利便性を向上させることができる。

通知部４３は、決済の請求金額に対して利用者Ｕ１が所有する電子マネーが不足している場合には、利用者Ｕ１に対して、電子マネーが不足している旨の通知をさらに行う。これにより、実施形態に係る決済サーバ１０は、電子マネーのチャージ忘れを認識することが可能となり利用者の利便性を向上させることができる。

通知部４３は、決済の請求金額に対して利用者Ｕ１が所有する電子マネーが不足している場合には、利用者Ｕ１に対して、電子マネーの入金を促す通知をさらに行う。これにより、実施形態に係る決済サーバ１０は、電子マネーのチャージ忘れを回避することが可能となり利用者の利便性を向上させることができる。

〔５．ハードウェア構成〕
また、上述してきた各実施形態に係る決済サーバ１０は、例えば、図７に示すような構成のコンピュータ１０００によって実現される。以下、決済サーバ１０を例に挙げて説明する。図７は、決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（実施形態のネットワークＮに対応する）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、また、通信網５００を介してＣＰＵ１１００が生成したデータを他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が決済サーバ１０として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部４０の機能を実現する。また、ＨＤＤ１４００には、決済サーバ１０の記憶装置内の各データが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から所定の通信網を介してこれらのプログラムを取得してもよい。

〔６．その他〕
以上、本願の実施形態を説明したが、これら実施形態の内容により本発明が限定されるものではない。また、前述した構成要素には、当業者が容易に想定できるもの、実質的に同一のもの、いわゆる均等の範囲のものが含まれる。さらに、前述した構成要素は適宜組み合わせることが可能である。さらに、前述した実施形態の要旨を逸脱しない範囲で構成要素の種々の省略、置換または変更を行うことができる。

また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

例えば、上述した決済サーバ１０は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットホーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティング等で呼び出して実現するなど、構成は柔軟に変更できる。

また、上述してきた実施形態および変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、制御部は、制御手段や制御回路に読み替えることができる。

１ 情報処理システム
１０ 決済サーバ
２０ 通信部
３０ 記憶部
３１ 口座データベース
３２ 請求書情報データベース
３３ 利用者情報データベース
４０ 制御部
４１ 受付部
４２ 決済処理部
４３ 通知部
１００ 利用者端末
２００ 事業者端末

Claims (9)

1. 利用者の利用者端末を用いた決済サービスであって当該利用者を識別する利用者識別情報と決済先を識別する決済先識別情報と決済額との通知を受け付けると当該利用者識別情報と対応する口座の電子マネーを当該決済先識別情報と対応する口座へ当該決済額分移動することで行われる決済サービスを提供するアプリケーションを介して、所定の事業者が発行した請求書を記憶する所定の端末から、前記利用者の前記利用者端末に送信された請求書が示す請求書情報と、前記利用者による前記利用者端末を用いた前記請求書に関する支払日時の指定とを受け付けると、当該請求書情報と指定された支払日時と前記利用者を識別する利用者識別情報とを対応付けて所定の記憶装置に記憶させる受付部と、
   前記所定の記憶装置に記憶された支払日時となった場合は、当該支払日時と対応付けられた前記請求書情報が示す決済額分の電子マネーを、当該支払日時と対応付けられた前記利用者と対応する口座から、当該支払日時と対応付けられた前記請求書情報が示す事業者識別情報と対応する口座へ移動させることで、前記請求書情報に基づく決済を行う決済処理部と、
   を備えることを特徴とする情報処理装置。
2. 前記支払日時が前記請求書情報に基づく支払可能な日時でない場合には、前記利用者に対して、前記支払日時の再指定を促す通知を行う通知部、
   をさらに備えることを特徴とする請求項１に記載の情報処理装置。
3. 前記受付部は、
   前記支払日時の変更をさらに受け付け、
   前記決済処理部は、
   前記決済を、変更を受け付けられた前記支払日時に行う、
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記通知部は、
   前記利用者の過去の決済履歴に基づいて、前記利用者に対して、完了していない可能性がある決済に関する通知をさらに行う、
   ことを特徴とする請求項２に記載の情報処理装置。
5. 前記決済処理部は、
   前記決済の請求金額に対して前記利用者が所有する電子マネーが不足している場合には、前記利用者が設定した所定の口座から不足する金額を電子マネーとして移行し、前記決済を行う、
   ことを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記通知部は、
   前記決済の請求金額に対して前記利用者が所有する電子マネーが不足している場合には、前記利用者に対して、前記電子マネーが不足している旨の通知をさらに行う、
   ことを特徴とする請求項２に記載の情報処理装置。
7. 前記通知部は、
   前記決済の請求金額に対して前記利用者が所有する電子マネーが不足している場合には、前記利用者に対して、前記電子マネーの入金を促す通知をさらに行う、
   ことを特徴とする請求項２に記載の情報処理装置。
8. コンピュータが実行する情報処理方法であって、
   利用者の利用者端末を用いた決済サービスであって当該利用者を識別する利用者識別情報と決済先を識別する決済先識別情報と決済額との通知を受け付けると当該利用者識別情報と対応する口座の電子マネーを当該決済先識別情報と対応する口座へ当該決済額分移動することで行われる決済サービスを提供するアプリケーションを介して、所定の事業者が発行した請求書を記憶する所定の端末から、前記利用者の前記利用者端末に送信された請求書が示す請求書情報と、前記利用者による前記利用者端末を用いた前記請求書に関する支払日時の指定とを受け付けると、当該請求書情報と指定された支払日時と前記利用者を識別する利用者識別情報とを対応付けて所定の記憶装置に記憶させる受付工程と、
   前記所定の記憶装置に記憶された支払日時となった場合は、当該支払日時と対応付けられた前記請求書情報が示す決済額分の電子マネーを、当該支払日時と対応付けられた前記利用者と対応する口座から、当該支払日時と対応付けられた前記請求書情報が示す事業者識別情報と対応する口座へ移動させることで、前記請求書情報に基づく決済を行う決済処理工程と、
   を含むことを特徴とする情報処理方法。
9. 利用者の利用者端末を用いた決済サービスであって当該利用者を識別する利用者識別情報と決済先を識別する決済先識別情報と決済額との通知を受け付けると当該利用者識別情報と対応する口座の電子マネーを当該決済先識別情報と対応する口座へ当該決済額分移動することで行われる決済サービスを提供するアプリケーションを介して、所定の事業者が発行した請求書を記憶する所定の端末から、前記利用者の前記利用者端末に送信された請求書が示す請求書情報と、前記利用者による前記利用者端末を用いた前記請求書に関する支払日時の指定とを受け付けると、当該請求書情報と指定された支払日時と前記利用者を識別する利用者識別情報とを対応付けて所定の記憶装置に記憶させる受付手順と、
   前記所定の記憶装置に記憶された支払日時となった場合は、当該支払日時と対応付けられた前記請求書情報が示す決済額分の電子マネーを、当該支払日時と対応付けられた前記利用者と対応する口座から、当該支払日時と対応付けられた前記請求書情報が示す事業者識別情報と対応する口座へ移動させることで、前記請求書情報に基づく決済を行う決済処理手順と、
   をコンピュータに実行させることを特徴とする情報処理プログラム。

Images