JP6910520B1 - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Abstract

【課題】端末装置を用いた決済の柔軟性を向上させる。【解決手段】本願に係る情報処理装置は、利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信部と、前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行部と、を有することを特徴とする。【選択図】図３

Description

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

従来、利用者の利便性を向上させるために、決済を柔軟に行うための技術が知られている。例えば、クレジットでの後払いサービスを提供する技術が提供されている（例えば特許文献１）。

特許第６６８２６８８号

しかしながら、上記の従来技術では、端末装置を用いた決済の柔軟性を向上させることが難しい場合がある。上記の従来技術では、主にクレジットカードを対象としており、例えば、所定期間内に後払いサービスで清算される第１上限額の所定割合以下で、複数回払いの一回で清算される第２上限額を設定しているに過ぎない。そのため、端末装置を用いた決済の柔軟性の点で改善の余地がある。

本願は、上記に鑑みてなされたものであって、端末装置を用いた決済の柔軟性を向上させることできる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信部と、前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行部と、を有することを特徴とする。

実施形態の一態様によれば、端末装置を用いた決済の柔軟性を向上させることできるという効果を奏する。

図１は、経費精算処理の一例を示す図である。 図２は、利用者端末の画面の一例を示す図である。 図３は、実施形態に係る所定方式払い処理の一例を示す図である。 図４は、所定方式払い処理における口座間の流れを示す図である。 図５は、実施形態に係る決済サーバの構成例を示す図である。 図６は、実施形態に係る口座データベースの一例を示す図である。 図７は、実施形態に係る利用者情報データベースの一例を示す図である。 図８は、実施形態に係る利用者端末の構成例を示す図である。 図９は、実施形態に係る第２アプリケーションの構成例を示す図である。 図１０は、実施形態に係る所定方式払い処理の手順の一例を示すフローチャートである。 図１１は、実施形態に係る情報処理システムによる情報処理手順を示すシーケンス図である。 図１２は、情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

〔１．実施形態〕
本実施形態の情報処理システム１により実現される所定方式払い処理についての説明に先立って、まず、図１を用いて、経費精算処理について説明する。図１は、経費精算処理の一例を示す図である。なお、以下では所定の決済処理（所定方式払いの処理）の一例として後払い処理について説明するが、所定の決済処理（所定方式払いの処理）は、後述する第２口座を用いた決済処理であれば、後払い処理に限られない。

〔１−１．情報処理システムの一例〕
図１に示すように、実施形態に係る情報処理システム１は、決済サーバ１０と、利用者端末１００と、精算処理サーバ２００と、事業者端末３００とを含む。決済サーバ１０、利用者端末１００、精算処理サーバ２００及び事業者端末３００は、ネットワークＮ（例えば、図５参照）を介して有線または無線により相互に通信可能に接続される。ネットワークＮは、例えば、インターネットなどのＷＡＮ（Wide Area Network）である。なお、図１に示した情報処理システム１には、複数台の決済サーバ１０、複数台の利用者端末１００、複数台の精算処理サーバ２００及び複数台の事業者端末３００が含まれていてもよい。なお、利用者が直接事業者端末３００に経費申請を行う場合、情報処理システム１には精算処理サーバ２００が含まれなくてもよい。この場合、例えば事業者端末３００が精算処理サーバ２００と同様の機能を有し、後述する処理で精算処理サーバ２００が利用者端末１００との間で行う情報の送受信を事業者端末３００が行ってもよい。また、この場合、後述する処理で事業者端末３００が精算処理サーバ２００との間で行う情報の送受信は、事業者端末３００内での情報の伝送であってもよい。

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

以下では、利用者端末１００を利用する利用者が保有する口座を「第１口座」と記載し、利用者が保有する第１口座とは異なる口座を「第２口座」と記載し、決済の支払先の口座を「第３口座」と記載し、事業者が保有する口座を「第４口座」と記載する場合がある。例えば、第１口座は、利用者端末１００を用いる電子決済に関する電子決済サービスに登録した利用者の口座である。例えば、第１口座は、利用者のプライベート口座である。

また、例えば、第２口座は、事業者に紐づけられた口座である。例えば、第２口座は、事業者がデポジットを行うための口座であってもよい。この場合、第２口座は、事業者がデポジットを行った金額の範囲内で所定方式払いでの利用が可能な所定方式払い口座であってもよい。また、第２口座は、所定の与信枠が設定された口座であってもよい。例えば、第２口座は、利用者が所属する事業者（企業等）を対象として与信枠が設定された口座である。例えば、第２口座は、事業者の与信口座となり、事業者ごとの与信枠の範囲で設定された所定方式払い口座である。なお、与信枠は事業者ごとに限らず、様々な態様により設定されてもよい。例えば、事業者（企業等）に属する社員等の利用者ごとに与信枠が設定されてもよい。例えば、各利用者の実績に応じて与信枠が設定されてもよい。例えば、過去の経費精算の実績に応じて、各利用者の与信枠が設定されてもよい。例えば、過去の経費精算の金額が多い利用者程、多い与信枠が設定されてもよい。例えば、一般社員の与信枠（第１枠）と幹部社員の与信枠（第２枠）とを実績に応じて設定してもよい。この場合、与信枠ごとに第２口座を設けてもよいし、１つの第２口座に複数の与信枠を対応付けてもよい。なお、上記は一例に過ぎず、所定方式払い処理が提供可能であればどのような態様により与信枠が設定されてもよい。以下では、説明のために与信枠が設定された第２口座を一例として示すが、第２口座は、所定方式払いとしての利用が可能であればどのような形式であってもよく、第２口座をその第２口座に紐づく事業者のWalletまたは単にWalletと記載する場合がある。

また、例えば、第３口座は、利用者端末１００を用いる電子決済に関する電子決済サービスにおいて支払先となる口座である。また、例えば、第４口座は、利用者が所属する事業者の口座である。なお、第１口座〜第４口座は、所定方式払い処理を説明するために、口座を区別するものであり、特に区別なく説明する場合「口座」と記載する場合がある。

また、詳細については後述するが、ここでいう所定方式払い処理とは、所定方式払い口座（与信口座）である第２口座を用いた決済（「所定方式払い決済」ともいう）を行う処理を言う。以下では、第２口座を用いない決済、すなわち通常の決済の処理については、所定方式払い処理と区別する場合、「通常の決済処理」や単に「決済処理」と記載する場合がある。

図１に示す利用者端末１００は、利用者によって利用される端末装置（情報処理装置）である。利用者端末１００は、例えば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）等により実現される。また、利用者端末１００は、決済サーバ１０や精算処理サーバ２００、事業者端末３００などによって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１に示す例では、利用者端末１００がスマートフォンである場合を示す。また、利用者端末１００は、ＧＰＳセンサ等の位置センサを有し、利用者の位置を検知する。利用者端末１００は、決済時の利用者の位置をその決済と対応付け、記憶部１２０に記憶してもよいし、決済サーバ１０や精算処理サーバ２００等の他の情報処理装置へ送信してもよい。例えば、利用者端末１００は、決済時の利用者の位置の情報を後述する決済情報や申請情報に含ませ、決済サーバ１０や精算処理サーバ２００等の他の情報処理装置へ送信してもよい。なお、利用者端末１００は、利用者の位置の情報を取得可能であれば、どのような態様により利用者の位置の情報を取得してもよい。例えば、利用者端末１００を利用する利用者は、利用者端末１００と通信可能なウェアラブルデバイスを身に付けることにより、ウェアラブルデバイスにより利用者の位置が検知されてもよい。この場合、利用者端末１００は、ウェアラブルデバイスから利用者の位置の情報を取得してもよく、位置センサを有しなくてもよい。なお、上記は一例であり、利用者端末１００は、様々な手段により利用者の位置の情報を取得してもよい。

図１に示す精算処理サーバ２００は、利用者が属する組織（事業者）から利用者に対して支払われる経費の精算処理サービスを提供する情報処理装置であり、例えば、サーバ装置やクラウドシステムにより実現される。例えば、精算処理サーバ２００は、事業者と利用者とを紐付けて管理し、経費の精算対象を示す精算情報を利用者から受け付けた場合に、当該利用者に紐付けられた事業者に対して精算情報に基づく情報を提供することで、精算処理を実現する。具体的な例を挙げると、精算処理サーバ２００は、利用者が利用するサービスであって、精算処理サービスと連携（紐付け）されているサービスにおける利用者の利用履歴を示す精算情報を受け付ける。

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

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

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

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

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

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

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

〔１−３．経費精算処理の概要〕
経費精算処理の概要について図１を用いて説明する。以下の説明では、利用者端末１００が利用者Ｕにより利用され、事業者端末３００が利用者Ｕの属する事業者Ｂにより利用される例を示す。また、以下の説明では、利用者端末１００を利用者Ｕと同一視し、事業者端末３００を事業者Ｂと同一視する場合がある。すなわち、以下では、利用者Ｕを利用者端末１００、事業者Ｂを事業者端末３００と読み替えることもできる。

また、以下の説明では、精算処理サーバ２００が提供する精算処理サービスに関するアプリケーション（以下、単に「精算処理アプリ」と記載する場合がある）が利用者端末１００及び事業者端末３００にインストール済みであり、利用者Ｕと事業者Ｂとが紐付けられて精算処理サーバ２００に管理されているものとする。また、以下の説明では、決済サーバ１０が提供する電子決済サービスにおける利用者Ｕのアカウント（利用者ＩＤ）と、精算処理サーバ２００が提供する精算処理サービスにおける利用者Ｕのアカウントとが紐付けられており、アカウントの紐付けに関する情報が決済サーバ１０及び精算処理サーバ２００に管理されているものとする。

まず、利用者端末１００は、利用者Ｕの電子決済に関する処理を実行する（ステップＳ１）。なお、図１の例において、利用者端末１００は、上述した決済アプリを用いた決済手法により、店舗Ａに対して決済を行ったものとする。

続いて、店舗Ａの店員Ｍ１は、利用者Ｕにレシートを提供する（ステップＳ２）。例えば、店員Ｍ１は、利用者Ｕからの決済に応じて出力装置（例えば、プリンタや、ＰＯＳ（Point of Sales）端末など）ＯＤ１から出力（印刷）されるレシートを提供する。

なお、図１の例において、利用者Ｕが、店舗Ａに対する決済を経費の精算対象とすることを希望したものとする。この場合、利用者端末１００は、利用者Ｕの操作に応じて、経費の精算対象となる決済を示す決済情報の登録画面を表示する（ステップＳ３）。例えば、利用者端末１００は、利用者Ｕからの操作に応じて決済アプリを起動し、利用者Ｕが決済アプリを用いて行った決済の履歴の一覧画面を表示する。そして、利用者Ｕは、一覧画面から、店舗Ａに対する決済の履歴を選択し、利用者端末１００に登録画面の表示を指示する。

続いて、利用者Ｕは、利用者端末１００に表示された登録画面に決済情報を登録する（ステップＳ４）。例えば、利用者Ｕは、店舗Ａに対する決済内容と、店舗Ａから提供されたレシートを決済情報として登録する。

ここで、図２を用いて、利用者端末１００が表示する登録画面について説明する。図２は、利用者端末の画面の一例を示す図である。

図２に示すように、利用者端末１００は、利用者Ｕが決済アプリを用いて店舗Ａに対して行った決済を示す画面ＳＣ１を表示する。例えば、利用者端末１００は、支払先や、決済金額（決済額）、決済が行われた日時（取引日時）などの情報を示す決済内容と、支払先から提供されたレシートの登録操作を行うための領域ＡＲ１とを含む画面ＳＣ１を表示する。言い換えると、利用者端末１００は、決済内容が予め登録された状態の画面ＳＣ１を表示する。ここで、利用者Ｕが領域ＡＲ１に対する選択操作を行った場合、利用者端末１００は、画面ＳＣ１から画面ＳＣ２に遷移させる。

図２に示すように、利用者端末１００は、決済内容と、レシートの画像の登録操作を行うための領域ＡＲ２と、レシートの登録が完了したことを指示するための領域ＡＲ３とを含む画面ＳＣ２を表示する。ここで、利用者Ｕが領域ＡＲ２に対する選択操作を行った場合、利用者端末１００は、自装置の撮像部を起動し、店舗Ａから提供されたレシートの画像の撮影を利用者Ｕに指示する。そして、レシートの画像が撮影された場合、利用者端末１００は、画面ＳＣ２から画面ＳＣ３に遷移させる。

図２に示すように、利用者端末１００は、領域ＡＲ２に替えてレシートの画像Ｐ１を含む画面ＳＣ３を表示する。ここで、利用者Ｕが領域ＡＲ３に対する選択操作を行った場合、利用者端末１００は、決済情報の登録を完了する。

図１に戻り、説明を続ける。利用者端末１００は、登録された決済情報を、精算対象となる決済を示す精算情報として精算処理サーバ２００に送信する（ステップＳ５）。例えば、利用者端末１００は、図２に示す画面ＳＣ３に含まれるレシートの画像Ｐ１と、決済内容と、電子決済サービスにおける利用者Ｕの利用者ＩＤとを含む決済情報を精算情報として精算処理サーバ２００に送信する。なお、図１では、利用者端末１００が直接精算処理サーバ２００に精算情報を送信する場合を図示したが、利用者端末１００は決済サーバ１０を介して精算情報を精算処理サーバ２００に送信してもよい。例えば、利用者端末１００は決済サーバ１０に精算情報を送信し、利用者端末１００から精算情報を受信した決済サーバ１０が精算処理サーバ２００にその精算情報を送信してもよい。

続いて、精算処理サーバ２００は、精算情報に基づく経費の承認要求を事業者端末３００に送信する（ステップＳ６）。例えば、精算処理サーバ２００は、精算情報と、精算情報が示す経費の承認要求が発生したことを示す通知とを、利用者Ｕに紐付けられた事業者Ｂが利用する事業者端末３００に送信する。

続いて、事業者端末３００は、承認要求に対応する経費の支払要求を決済サーバ１０に送信する（ステップＳ７）。例えば、事業者Ｂは、精算処理サーバ２００から送信された精算情報の内容に不備があるか否かを確認する。そして、精算情報の内容に不備がない場合、事業者Ｂは、精算情報が示す経費の申請を承認し、事業者端末３００を用いて、利用者Ｕに対する経費の支払いに関する支払要求を決済サーバ１０に送信する。

続いて、決済サーバ１０は、支払要求に対応する支払処理を実行する（ステップＳ８）。例えば、決済サーバ１０は、経費の申請が承認された旨の通知を利用者端末１００に送信する。そして、決済サーバ１０は、決済アプリを用いた決済手段において利用可能な電子マネーであって、精算情報が示す経費（利用者Ｕによる店舗Ａへの決済金額）分の電子マネーを、事業者Ｂの口座（第４口座）から利用者Ｕの口座へと移行させる。

以上のように、利用者端末１００は、決済アプリを用いて支払先に対する決済を実行すると共に、決済アプリを介して当該決済を経費の精算対象とする精算情報を精算処理サーバ２００に送信する。これにより、情報処理システム１は、経費精算処理を行う。

〔１−４．所定方式払い処理の一例〕
ここから、図３を用いて、所定方式払い処理について説明する。図３は、実施形態に係る所定方式払い処理の一例を示す図である。なお、図１等で説明した点と同様の点については適宜説明を省略する。

上述した通常の決済処理による経費申請処理においては、利用者Ｕの口座（第１口座）から、店舗Ａの口座（第３口座）への電子マネーの移行と、事業者Ｂの口座（第４口座）から利用者Ｕの口座（第１口座）への電子マネーの移行とにより、利用者Ｕについての経費精算処理が完了する。このように、第２口座を用いない通常の決済処理による経費申請処理においては、利用者Ｕの口座（第１口座）から一度電子マネーが出金され、その後利用者Ｕの口座（第１口座）に同額の電子マネーが入金されることにより、経費精算処理が完了する。このように、通常の決済処理による経費申請処理においては、利用者Ｕの口座（第１口座）において、経費を利用者Ｕが一旦負担する（立て替える）、いわゆる持ち出しの状態が発生する。このような場合、経費として承認され、事業者Ｂの口座（第４口座）から入金されるまで、その負担分（持ち出しの分）の電子マネーは利用することができない。例えば、利用者Ｕの口座（第１口座）の残高が少ない場合、経費申請の対象となる決済が行えなかったり、持ち出しの分の電子マネーにより所望の決済ができなかったりする場合等が生じ得る。そのため、情報処理システム１は、以下のような所定方式払い処理を行うことにより、利用者端末１００を用いた決済を行う利用者の持ち出しが不要な決済処理を提供し、利用者端末１００を用いた決済の柔軟性を向上させる。

以下説明する図３の例では、運転手Ｍ２が運航するタクシーＴＸを利用者Ｕが利用して、所定方式払い処理を行う場合を示す。図３では、利用者Ｕの利用者端末１００にインストールされた決済アプリが、利用者Ｕの属する事業者Ｂの与信で設定された所定方式払い口座（第２口座）に関連付けられており、利用者Ｕが所定方式払い決済を選択すると、所定方式払い口座（第２口座）から支払いが行われる。

まず、タクシーＴＸによるサービスの提供を受けた利用者Ｕは、利用者端末１００にインストールされた決済アプリを介して、タクシーＴＸに設置された店舗識別情報Ｃ２を撮影する（ステップＳ１１）。図３の例では、店舗識別情報Ｃ２は、タクシーＴＸに配置され、タクシーＴＸを識別する２次元コード（ＱＲコード（登録商標））である。このような場合、利用者端末１００は、決済対象の価格を入力するための画面を表示し、利用者Ｕ或いはタクシーＴＸの運転手Ｍ２から決済金額の入力を受け付ける。

また、利用者端末１００は、通常の決済処理と所定方式払い処理とのいずれを行うかについて、利用者Ｕの選択を受け付ける。例えば、利用者端末１００は、決済金額の入力する画面に「所定方式払い処理」と記載したボタンを表示し、利用者Ｕがそのボタンを指定した場合、利用者Ｕの所定方式払い処理の選択を受け付ける。なお、上記は一例に過ぎず、利用者端末１００は、通常の決済処理と所定方式払い処理とのいずれを行うかが特定可能であれば、どのような入力態様により、利用者Ｕの選択を受け付けてもよい。例えば、利用者端末１００は、音声により、利用者Ｕの選択を受け付けてもよい。この場合、利用者端末１００は、利用者Ｕが「所定方式払い処理で」と発話した場合、利用者Ｕの所定方式払い処理の選択を受け付け、利用者Ｕが「通常の決済で」と発話した場合、利用者Ｕの通常の決済処理の選択を受け付ける。

図３の例では、利用者端末１００は、利用者Ｕの所定方式払い処理の選択を受け付ける（ステップＳ１２）。すなわち、利用者Ｕは、利用者ＵのタクシーＴＸの利用に関する決済（「対象決済ＴＳ」とする）の支払について、所定方式払い口座である事業者Ｂの第２口座により行うことを選択する。

そして、利用者端末１００は、決済サーバ１０に所定方式払い処理を要求する（ステップＳ１３）。例えば、利用者端末１００は、利用者Ｕを識別する利用者識別情報と、店舗識別情報Ｃ２（若しくは、店舗識別情報Ｃ２が示す情報、すなわち、タクシーＴＸを示す情報）と、決済金額とを示す情報とともに、所定方式払い処理を要求することを示す要求情報を決済サーバ１０へと送信する。このように、利用者端末１００は、利用者Ｕの対象決済ＴＳが所定方式払い処理の対象であることを示す情報（「処理対象情報」ともいう）を決済サーバ１０へと送信する。

所定方式払い処理の要求を受信した決済サーバ１０は、対象決済ＴＳについて所定方式払い処理を実行する（ステップＳ１４）。決済サーバ１０は、利用者Ｕが保有する口座（第１口座）ではなく、利用者Ｕの属する事業者Ｂに対して与信枠が設定された口座（第２口座）から、店舗識別情報Ｃ２が示すタクシーＴＸの口座（第３口座）へ決済の金額を移行させる処理を実行する。すなわち、決済サーバ１０は、利用者Ｕが保有する口座に対する処理を行うことなく、店舗識別情報Ｃ２が示すタクシーＴＸの口座への決済の金額の入金（支払い）を行う事により、対象決済ＴＳについて所定方式払い処理を完了させる。そして、決済サーバ１０は、対象決済ＴＳについて所定方式払い処理が完了した旨の通知を利用者端末１００へと送信する。

その後、利用者Ｕは、所定方式払い決済である対象決済ＴＳを経費の申請対象として選択する。これにより、利用者端末１００は、所定方式払い決済である対象決済ＴＳについて、経費の申請対象とする利用者Ｕの選択を受け付ける（ステップＳ１５）。例えば、利用者端末１００は、所定方式払い決済の一覧を示す画面を表示し、その一覧に対する利用者Ｕの選択を受け付ける。例えば、利用者端末１００は、所定方式払い決済の各々に対応する経費申請ボタンが配置された一覧を示す画面を表示し、利用者Ｕにより経費申請ボタンが指定された所定方式払い決済を経費の申請対象として選択を受け付ける。

図３の例では、利用者端末１００は、利用者Ｕが対象決済ＴＳの経費申請ボタンを選択し、対象決済ＴＳに対応するタクシーＴＸでの金額（例えば１０００円等）の所定方式払い決済を経費申請する画面（「経費申請画面」ともいう）を表示する。なお、経費申請画面は、利用者Ｕの操作に応じて、レシートを登録し、精算処理サーバ２００に経費申請を行う情報を送信するための画面であれば、どのような画面であってもよい。例えば、経費申請画面は、図２中の画面ＳＣ２、ＳＣ３と同様にレシート画像を登録し、精算処理サーバ２００に情報を送信する画面であってもよい。

そして、利用者端末１００は、経費申請画面における利用者Ｕの操作に応じて、対象決済ＴＳに対応するタクシーＴＸでの金額の決済を経費申請するための情報（申請情報）を精算処理サーバ２００へ送信する（ステップＳ１６）。

そして、精算処理サーバ２００は、対象決済ＴＳについての申請情報に基づく経費の承認要求を事業者端末３００に送信する（ステップＳ１７）。例えば、精算処理サーバ２００は、対象決済ＴＳについての申請情報と、申請情報が示す経費の承認要求が発生したことを示す通知とを、利用者Ｕに紐付けられた事業者Ｂが利用する事業者端末３００に送信する。

そして、事業者端末３００は、承認要求に対応する経費の支払要求を決済サーバ１０に送信する（ステップＳ１８）。例えば、事業者Ｂは、精算処理サーバ２００から送信された申請情報の内容に不備があるか否かを確認する。そして、申請情報の内容に不備がない場合、事業者Ｂは、申請報が示す経費の申請を承認し、事業者端末３００を用いて、対象決済ＴＳに関する精算要求を決済サーバ１０に送信する。例えば、事業者端末３００は、対象決済ＴＳを経費として承認したことを示す承認情報を決済サーバ１０に送信する。例えば、承認情報には、事業者Ｂや対象決済ＴＳの金額等を示す情報等、精算に必要な各種情報が含まれてもよい。

続いて、決済サーバ１０は、精算要求に対応する精算処理を実行する（ステップＳ１９）。決済サーバ１０は、承認情報が示す経費（対象決済ＴＳの金額）に手数料を加えた金額（「所定方式払い利用分」ともいう）を事業者Ｂの口座（第４口座）から他の口座へ移行する。例えば、決済サーバ１０は、対象決済ＴＳの金額を事業者Ｂに対して与信枠が設定された口座（第２口座）に移行し、手数料分の金額を決済サービスＸのサービス提供元の口座に移行する。なお、手数料がない場合、決済サーバ１０は、事業者Ｂの口座（第４口座）から事業者Ｂの口座（第２口座）へ、対象決済ＴＳの金額を移行させる処理を実行する。また、決済サーバ１０は、経費の申請が承認された旨の通知を利用者端末１００に送信してもよい。

以上のように、決済サーバ１０は、所定方式払い処理を行うことにより、利用者端末１００を用いた決済を行う利用者の持ち出しが不要な所定方式払い処理を提供し、利用者端末１００を用いた決済の柔軟性を向上させることができる。上記のような所定方式払い処理が利用できない場合、経費は社員（利用者Ｕ等）が一旦負担しなければならない。しかしながら、上記のような所定方式払い処理を利用することにより、社員（利用者Ｕ等）が所定方式払い経費精算を利用し期限内に会社（事業者Ｂ等）に経費精算することにより、所定方式払い利用分が相殺される。すなわち、社員（利用者Ｕ等）の第１口座の出入金を行うことなく、所定方式払い利用分についての処理を完了することができる。

〔１−４−１．経費として処理されない場合〕
なお、対象決済ＴＳが経費として承認されない場合、決済サーバ１０は、利用者Ｕの口座（第１口座）から事業者Ｂに対して与信枠が設定された口座（第２口座）へ対象決済ＴＳの金額を移行させる処理を実行する。例えば、決済サーバ１０は、対象決済ＴＳが経費として承認されたことを示す承認情報を所定の期間（対象決済ＴＳの決済時から２ヵ月等）内に受信しなかった場合、利用者Ｕの口座（第１口座）から事業者Ｂに対して与信枠が設定された口座（第２口座）へ対象決済ＴＳの金額を移行させる処理を実行する。これにより、決済サーバ１０は、対象決済ＴＳが経費として承認されない場合であっても、対象決済ＴＳの精算処理を適切に行うことができる。また、決済サーバ１０は、会社（事業者Ｂ等）の経費精算が遅れた場合は、所定方式払い分を社員（利用者Ｕ等）のプライベート口座（第１口座）から補填してもよい。

上記のように、所定方式払い処理を申請して経費として処理されない決済がある利用者については、決済サーバ１０は、所定方式払い処理の利用を停止してもよい。例えば、決済サーバ１０は、所定方式払いを使っているのに会社に経費精算しない利用者については、スコアが悪くなり、所定方式払いを使えなくしてもよい。例えば、決済サーバ１０は、スコアが所定値未満の利用者については所定方式払いを利用不可としてもよい。なお、スコアの算出の点についての詳細は後述する。

〔１−５．所定方式払い処理の概要〕
ここで、上述した所定方式払い処理の情報処理について概要を説明する。まず、タクシーＴＸを利用した利用者Ｕは、タクシーＴＸに対して所定方式払いで決済を行う。この点は、図３中のステップＳ１１〜Ｓ１３の処理に対応する。

そして、利用者Ｕによる所定方式払い決済に基づいて、事業者ごとのWalletとしての所定方式払い口座である第２口座（事業者Ｂの第２口座）からタクシーＴＸに対して支払いが行われる。この点は、図３中のステップＳ１４の処理に対応する。そして、情報処理システム１は、利用者Ｕの所定方式払い利用明細にタクシーＴＸの料金（以下「所定方式払いタクシー代」とする）を記憶する。例えば、決済サーバ１０は、利用者Ｕのプライベート口座（第１口座）に対応付けてタクシーＴＸの料金が所定方式払いであることを示す情報を記憶部１２０に記憶する。

そして、利用者Ｕは、事業者Ｂに経費申請を申請する。この点は、図３では精算処理サーバ２００を介して経費申請を行う構成であるため、図３中のステップＳ１５〜Ｓ１７の処理に対応する。そして、事業者Ｂが利用者Ｕの所定方式払いを行ったタクシー代を経費として承認した場合、以下の処理を行う。

事業者Ｂは、手数料を加えた所定方式払い利用分を入金する。事業者Ｂは、利用者Ｕの所定方式払いを行ったタクシー代に手数料を加えた所定方式払い利用分を入金する。この点は、図３中のステップＳ１９の処理に対応する。そして、決済サービスＸのサービス提供元は利用者Ｕの所定方式払いを行ったタクシー代を相殺する。例えば、決済サーバ１０は、利用者Ｕのプライベート口座（第１口座）に対応付けて記憶したタクシーＴＸの料金が所定方式払いであることを示す情報を記憶部１２０から削除することにより、利用者Ｕの所定方式払いを行ったタクシー代を相殺する。

ここから、所定方式払い処理における口座間の流れについて、図４を用いて概念的に説明する。図４は、所定方式払い処理における口座間の流れを示す図である。

まず、ある決済（対象決済）について所定方式払い処理が要求された場合、決済サーバ１０は、利用者が保有する口座である第１口座ＡＣ１ではなく、事業者のWalletとしての口座である第２口座ＡＣ２から、対象決済の支払先の口座である第３口座ＡＣ３へ対象決済の金額を移行させる処理を実行する（ステップＳ２１）。ステップＳ２１の処理が図３のステップＳ１３における処理に対応する。

そして、対象決済が経費として承認された場合、決済サーバ１０は、事業者が保有する口座である第４口座ＡＣ４から、第２口座ＡＣ２へ、対象決済の金額を移行させる処理を実行する（ステップＳ２２）。ステップＳ２２の処理が図３のステップＳ１９における処理に対応する。

なお、対象決済が経費として承認されなかった場合、決済サーバ１０は、利用者の第１口座ＡＣ１から、第２口座ＡＣ２へ、対象決済の金額を移行させる処理を実行する（ステップＳ３１）。

〔２．決済サーバの構成〕
次に、図５を用いて、上述した所定方式払い処理を実現するための決済サーバ１０の構成について説明する。図５は、実施形態に係る決済サーバの構成例を示す図である。図５に示すように、決済サーバ１０は、通信部２０と、記憶部３０と、制御部４０とを有する。

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

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

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

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

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

なお、口座データベース３１は、上記以外の項目を有してもよく、例えば口座の種別を示す「種別」の項目を有してもよい。この場合、口座ＩＤ「ＡＩＤ＃１」によって識別される口座については、項目「種別」に「第１」の利用者の口座（第１口座）であることを示す情報が格納される。また、口座ＩＤ「ＡＩＤ＃２」によって識別される口座については、項目「種別」に「第４」等の事業者の口座（第４口座）であることを示す情報が格納される。また、口座ＩＤ「ＡＩＤ＃４」によって識別される口座については、項目「種別」に「第３」等のサービス提供元の口座（第３口座）であることを示す情報が格納される。また、口座ＩＤ「ＡＩＤ＃２」によって識別される口座については、項目「種別」に「第２」等の事業者のWalletとしての口座（第２口座）であることを示す情報が格納される。なお、「口座ＩＤ」等により種別が特定可能である場合、「種別」の項目は含まれてなくてもよい。

（利用者情報データベース３２）
利用者情報データベース３２は、決済サーバ１０が提供する電子決済サービスの利用者に関する各種の情報を記憶する。ここで、図７を用いて、利用者情報データベース３２が記憶する情報の一例を説明する。図７は、実施形態に係る利用者情報データベースの一例を示す図である。図７の例において、利用者情報データベース３２は、「利用者ＩＤ」、「決済履歴」、「レシート情報」、「紐付け情報」といった項目を有する。なお、利用者情報データベース３２は、上記項目に限らず、利用者に関する様々な情報を記憶する。利用者情報データベース３２は、デモグラフィック属性やサイコグラフィック属性等の様々な属性情報等を利用者ＩＤに関連付けて記憶してもよい。例えば、利用者情報データベース３２は、利用者の年齢、性別、住所、勤務先、年収等を利用者ＩＤに関連付けて記憶してもよい。

「利用者ＩＤ」は、電子決済サービスにおいて利用者を識別するための識別情報を示す。「決済履歴」は、利用者が決済アプリを用いた決済手法により決済を行った履歴を示す。例えば、「決済履歴」は、各決済について、支払先、決済金額、決済が行われた日時、決済が行われた位置、経費精算としての申請の有無、経費精算としての処理の有無などといった情報が各決済に対応付けて格納される。例えば、経費精算としての申請が無しの場合、その決済は経費申請前決済であることを示す。また、例えば、経費精算としての申請及び処理の両方が有りの場合、その決済は経費として処理済みであることを示す。また、例えば、経費精算としての申請が有りであり、かつ経費精算としての処理が無しの場合、その決済は経費として申請されたが処理されていないこと（例えば経費として承認されてなかったこと）を示す。「レシート情報」は、利用者が決済アプリに登録したレシートに関する情報を示し、例えば、レシートの画像や、レシートの画像からＯＣＲ（Optical Character Recognition）を用いて特定した決済の内容などといった情報が格納される。

「紐付け情報」は、電子決済サービスにおける利用者のアカウントと、精算処理サービスにおける利用者のアカウントとの紐付けに関する情報を示し、例えば、「サービスＩＤ」、「利用者ＩＤ」といった項目を有する。「サービスＩＤ」は、精算処理サービスを識別するための識別情報を示す。「利用者ＩＤ」は、精算処理サービスにおいて利用者を識別するための識別情報を示す。

すなわち、図７では、利用者ＩＤ「ＵＩＤ＃１」によって識別される利用者の決済履歴が「決済履歴＃１」、レシート情報が「レシート情報＃１」であり、サービスＩＤ「ＳＩＤ＃１」によって識別される精算処理サービスにおける当該利用者の利用者ＩＤが「ＰＩＤ＃１１」である例を示す。

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

（受付部４１）
受付部４１は、利用者からの決済要求を受け付ける。例えば、図１の例において、受付部４１は、店舗識別情報Ｃ１と、利用者Ｕが入力した決済金額とを含む情報を利用者端末１００から受け付け、利用者情報データベース３２に格納する。

また、受付部４１は、経費の支払要求を受け付けてもよい。例えば、図１の例において、受付部４１は、事業者端末３００から、利用者Ｕに対する経費の支払いに関する支払要求を受け付ける。例えば、受付部４１は、受信部４４を介して、利用者端末１００、精算処理サーバ２００、事業者端末３００等の装置からの各種情報を受け付ける。

（決済処理部４２）
決済処理部４２は、通常の決済処理を実行する。決済処理部４２は、受付部４１が受け付けた決済要求に従い、決済処理を実行する。例えば、図１の例において、決済処理部４２は、利用者Ｕの口座から、店舗識別情報Ｃ１に対応する店舗Ａの口座へと、利用者Ｕが入力した決済金額分の電子マネーを移行させる。

（支払処理部４３）
支払処理部４３は、受付部４１が受け付けた支払要求に従い、支払処理を実行する。例えば、図１の例において、支払処理部４３は、経費の申請が承認された旨の通知を利用者端末１００に送信する。そして、支払処理部４３は、決済アプリを用いた決済手段において利用可能な電子マネーであって、精算情報が示す経費分の電子マネーを、事業者Ｂの口座から利用者Ｕの口座へと移行させる。

（受信部４４）
受信部４４は、通信部２０を介して端末装置等の外部の装置から情報を受信する。受信部４４は、利用者端末１００、精算処理サーバ２００、事業者端末３００等の装置から情報を受信する。

受信部４４は、利用者が利用する端末装置を用いた所定の決済手段による決済が所定方式払い処理の対象であることを示す処理対象情報を受信する。受信部４４は、利用者による決済を所定方式払い処理の対象に指定する操作に基づく処理対象情報を端末装置から受信する。受信部４４は、決済が経費精算の対象であることを示す処理対象情報を受信する。受信部４４は、決済が事業者の経費として承認されたことを示す承認情報を受信する。

また、受信部４４は、所定方式払い決済について経費の精算要求を受け付けてもよい。例えば、図３の例において、受信部４４は、事業者端末３００から、利用者Ｕの所定方式払い決済について経費としての精算を要求する精算要求を受け付ける。

（算出部４５）
算出部４５は、経費精算の対象として指定された決済が経費として精算されたか否かに応じて、利用者の信用度合いを示すスコア（信用度スコア）を算出する。例えば、算出部４５は、利用者が経費申請を行った決済の数と、経費として承認された決済の数とに基づいて、スコアを算出する。算出部４５は、利用者が経費申請を行った決済の数により、経費として承認された決済の数を除算することにより、スコアを算出する。このように、算出部４５は、利用者の経費申請の承認率をスコアとして算出してもよい。なお、上記は一例に過ぎず、算出部４５は、様々な情報を適宜用いて、利用者のスコアを算出する。

（実行部４６）
実行部４６は、所定方式払い処理等の口座の出入金に関する各種の処理を行う。実行部４６は、処理対象情報が受信された場合、利用者が保有する第１口座とはである第２口座から、決済の支払先の口座である第３口座へ決済の金額を移行させる処理を実行する。例えば、実行部４６は、処理対象情報が受信された場合、利用者が保有する第１口座とは異なる口座であって、所定の与信枠が設定された口座である第２口座から、決済の支払先の口座である第３口座へ決済の金額を移行させる処理を実行する。実行部４６は、利用者が属する事業者の第２口座から、第３口座へ決済の金額を移行させる処理を実行する。

実行部４６は、承認情報を所定の期間内に受信した場合、事業者が保有する第４口座から第２口座へ決済の金額を移行させる処理を実行する。例えば、実行部４６は、所定の期間内に事業者端末３００から利用者Ｕの所定方式払い決済について精算要求を、承認情報として受信部４４が受け付けた場合、事業者が保有する第４口座から第２口座へ決済の金額を移行させる処理を実行する。

実行部４６は、決済が事業者の経費として承認されたことを示す承認情報が所定の期間内に受信しなかった場合、利用者が保有する第１口座から第２口座へ決済の金額を移行させる処理を実行する。例えば、実行部４６は、所定の期間内に事業者端末３００から利用者Ｕの所定方式払い決済について精算要求を受信部４４が受け付けなかった場合、決済が事業者の経費として承認されなかったと判定する。例えば、実行部４６は、所定の期間内に事業者端末３００から利用者Ｕの所定方式払い決済について精算要求を受信部４４が受け付けなかった場合、利用者が保有する第１口座から第２口座へ決済の金額を移行させる処理を実行する。

実行部４６は、算出部４５により算出された利用者のスコアに応じて、所定方式払い処理の利用可否を決定する。実行部４６は、利用者のスコアが所定値未満である場合、利用者に対して第２口座の利用を停止する。例えば、実行部４６は、利用者のスコアが所定値未満である場合、その利用者を特定する情報を所定方式払い不可リストに追加して記憶部１２０に記憶する。この場合、実行部４６は、所定方式払いの要求があった場合、その所定方式払いを要求した利用者（要求利用者）を示す情報と、所定方式払い不可リストとを比較し、要求利用者が所定方式払い不可リストに含まれる場合、要求利用者により所定方式払い処理を行わない。これにより、実行部４６は、スコアが所定値未満である要求利用者に対して第２口座の利用を停止する。

実行部４６は、事業者に対して与信枠が設定された第２口座から、第３口座へ決済の金額を移行させる処理を実行する。実行部４６は、利用者に応じた与信枠が設定された第２口座から、第３口座へ決済の金額を移行させる処理を実行する。実行部４６は、利用者の実績に応じて決定される与信枠が設定された第２口座から、第３口座へ決済の金額を移行させる処理を実行する。

〔３．利用者端末の構成〕
次に、上述した所定方式払い処理を実現するための利用者端末１００について図８を用いて説明する。図８は、実施形態に係る利用者端末の構成例を示す図である。図８に示すように、利用者端末１００は、通信部１１０と、記憶部１２０と、撮像部１３０と、表示部１４０と、制御部１５０とを有する。

（通信部１１０）
通信部１１０は、例えば、ＮＩＣ等によって実現される。そして、通信部１１０は、ネットワークＮと有線または無線で接続され、決済サーバ１０や、精算処理サーバ２００、事業者端末３００等との間で情報の送受信を行う。

（記憶部１２０）
記憶部１２０は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。例えば、記憶部１２０は、決済サーバ１０の利用者情報データベース３２に記憶された情報のうち、利用者端末１００を利用する利用者に対応する情報を記憶する。例えば、記憶部１２０は、利用者端末１００を利用する利用者の決済の履歴等の決済に関する情報（決済関連情報）や利用者の属性情報等の各種情報を記憶する。

（撮像部１３０）
撮像部１３０は、画像（動画或いは静止画）を撮像するための撮像装置である。撮像部１３０は、例えば、ＣＣＤ（Charged-coupled devices）センサやＣＭＯＳ（Complementary metal-oxide-semiconductor）センサ等の撮像素子により構成される。

（表示部１４０）
表示部１４０は、例えば液晶ディスプレイや有機ＥＬ（Electro-Luminescence）ディスプレイ等によって実現されるタブレット端末等の表示画面であり、各種情報を表示するための表示装置である。表示部１４０は、表示制御部１５２１による制御に応じて、各種情報を表示する。また、表示部１４０は、タッチパネルの機能により利用者の操作を受け付ける受付部として機能してもよい。この場合、表示部１４０は、利用者の指や専用ペンで利用者から各種操作を受け付ける入力装置としても機能する。

（制御部１５０）
制御部１５０は、コントローラであり、例えば、ＣＰＵやＭＰＵ等によって、利用者端末１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１５０は、コントローラであり、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

ここで、制御部１５０は、複数のアプリケーションを実行することにより、利用者端末１００に関する各種機能を実現することとなる。例えば、図８に示す例において、制御部１５０は、第１アプリケーション１５１や第２アプリケーション１５２を実行している。なお、制御部１５０は、図８に示すアプリケーション以外にも、任意の機能を発揮するための任意の数のアプリケーションを実行してよい。

第１アプリケーション１５１は、利用者端末１００のＯＳ（Operating System）となるアプリケーションである。第２アプリケーション１５２は、決済アプリであり、上述した決済処理を利用者端末１００に実行させる。以下、図９を用いて、第２アプリケーション１５２が有する機能構成の一例ついて説明する。図９は、実施形態に係る第２アプリケーションの構成例を示す図である。図９に示すように、実施形態に係る第２アプリケーション１５２は、表示制御部１５２１と、受付部１５２２と、選択部１５２３と、送信部１５２４とを有し、以下に説明する情報処理の機能や作用を実現または実行する。

（表示制御部１５２１）
表示制御部１５２１は、利用者端末１００の画面（表示部１４０）の表示を制御する。表示制御部１５２１は、利用者の操作に応じて表示部１４０の表示を制御する。表示制御部１５２１は、表示部１４０の表示するコンテンツなどの情報を生成し、生成した情報を表示部１４０に表示させる。

表示制御部１５２１は、画面ＳＣ１〜ＳＣ３等に示すような各種コンテンツを生成する。例えば、表示制御部１５２１は、Ｊａｖａ（登録商標）等の種々の技術を適宜用いて、画面（コンテンツ）を生成する。なお、表示制御部１５２１は、ＣＳＳやＪａｖａＳｃｒｉｐｔ（登録商標）やＨＴＭＬの形式に基づいて、画面（コンテンツ）を生成してもよい。また、例えば、表示制御部１５２１は、ＪＰＥＧ（Joint Photographic Experts Group）やＧＩＦ（Graphics Interchange Format）やＰＮＧ（Portable Network Graphics）など様々な形式で画面（コンテンツ）を生成してもよい。

また、図１の例において、表示制御部１５２１は、店舗Ａに設置された店舗識別情報Ｃ１を撮影するための画面や、決済対象の価格を入力するための画面、決済が完了した旨の画面などを表示させる。また、表示制御部１５２１は、決済アプリを用いて行った決済の履歴の一覧画面や、図２に示す画面などを表示させる。

なお、図２の例において、表示制御部１５２１は、決済アプリを用いて行った決済による決済金額、当該決済が行われた日時、並びに、当該決済による支払先を示す情報（すなわち、決済内容）を、利用者Ｕによる変更が不可能な状態で表示させてもよい。

（受付部１５２２）
受付部１５２２は、利用者の操作の情報を受け付ける。受付部１５２２は、利用者端末１００を利用する利用者によるカレンダーに含まれる日付の指定を受け付ける。受付部１５２２は、利用者端末１００を利用する利用者による経費として申請の指定を受け付ける。受付部１５２２は、通信部１１０を介して、外部装置から情報を受信する。受付部１５２２は、利用者端末１００を利用する利用者に関する情報を外部装置から情報を受信する。受付部１５２２は、利用者端末１００を利用する利用者の決済の履歴等の決済に関する情報（決済関連情報）を決済サーバ１０から受信し、記憶部１２０に格納する。なお、第２アプリケーション１５２は、決済関連情報を記憶部１２０に記憶しない場合、第２アプリケーション１５２内で決済関連情報を参照可能に管理してもよい。

受付部１５２２は、所定の決済手段を用いた決済を示す決済情報を受け付ける。例えば、図１の例において、受付部１５２２は、利用者Ｕが決済アプリを用いて店舗Ａに対して行った決済を示す決済情報の登録（入力）を受け付ける。

また、受付部１５２２は、端末装置の画面であって、所定の決済手段を用いた決済が完了したことを示す画面に表示される情報を、決済情報として受け付けてもよい。例えば、受付部１５２２は、図２に示す画面に予め登録された決済内容を決済情報として受け付ける。

また、受付部１５２２は、所定の決済手段を用いた決済による決済金額、当該決済が行われた日時、当該決済による支払先を示す情報の少なくともいずれかを含む決済情報を受け付けてもよい。例えば、受付部１５２２は、図２に示す画面に予め登録された支払先や、決済金額、決済が行われた日時などの情報を含む決済情報を受け付ける。

また、受付部１５２２は、所定の決済手段を用いた決済に応じて当該決済の支払先から出力される情報を示す画像を、決済情報として受け付けてもよい。例えば、受付部１５２２は、決済に応じて支払先が利用する出力装置から出力される領収書や、支払先の店員等による手書きの領収書などを示す画像を受け付ける。

また、受付部１５２２は、所定の決済手段を用いた決済の支払先から出力されるレシートを示す画像を、決済情報として受け付けてもよい。例えば、図１の例において、受付部１５２２は、出力装置ＯＤ１から出力されるレシートを示す画像を受け付ける。

なお、受付部１５２２は、レシートを示す画像からＯＣＲを用いて特定される情報を決済情報として受け付けてもよい。

また、受付部１５２２は、端末装置により撮影される画像を決済情報として受け付けてもよい。例えば、図１の例において、受付部１５２２は、撮像部１３０により撮影されたレシートの画像Ｐ１を受け付ける。

ここで、決済金額、当該決済が行われた日時、支払先を示す情報などといった情報以外にも、例えば、利用者が属する組織（事業者）における経費精算の規定に応じた情報を決済情報に含めたいといった要望が考えられる。したがって、受付部１５２２は、端末装置の画面であって、所定の決済手段を用いた決済が完了したことを示す画面に対する利用者の操作内容を、決済情報として受け付けてもよい。例えば、受付部１５２２は、決済が完了したことを示す画面に表示される決済金額の一部を経費とする旨の操作内容（例えば、経費とする金額）を受け付ける。また、利用者が複数の精算処理サービスを利用可能である場合、受付部１５２２は、いずれかの精算処理サービスの指定を受け付ける。

また、受付部１５２２は、画面に対して利用者が入力した決済内容を示すコメントを、決済情報として受け付けてもよい。例えば、受付部１５２２は、利用者が入力したコメントであって、利用者が属する組織における経費精算の規定を満たすための情報を含むコメントを決済情報として受け付ける。具体的な例を挙げると、受付部１５２２は、経費の種類（例えば、旅費交通費、接待交際費など）を示すコメントを受け付ける。また、決済が旅費交通費に関するものである場合、受付部１５２２は、移動手段や、移動経路などを示すコメントを受け付ける。また、決済が接待交際費に関するものである場合、受付部１５２２は、飲食等の参加者の名称、参加者が属する組織の名称などを示すコメントを受け付ける。

なお、受付部１５２２は、決済金額の一部を経費とすることを示すコメントを、決済情報として受け付けてもよい。例えば、受付部１５２２は、決済が完了したことを示す画面に表示される決済金額の一部を経費とする旨と、経費とする金額とを示すコメントを受け付ける。

さらに、利用者が複数の組織に属する場合（例えば、利用者が副業をしている場合）、適切な組織に経費の申請を行いたいといった要望が考えられる。したがって、受付部１５２２は、利用者が属する組織の指定を含む決済情報を受け付けてもよい。例えば、表示制御部１５２１は、利用者と紐付けられた複数の組織（例えば、精算処理サーバ２００において利用者と紐付けて管理されている組織）を、利用者が選択可能な状態で画面に表示させる。そして、受付部１５２２は、画面に表示された組織の選択操作を受け付ける。

（選択部１５２３）
選択部１５２３は、利用者の操作に応じて決済の態様を選択する。選択部１５２３は、利用者が指定した決済態様を選択する。選択部１５２３は、所定方式払い処理か通常の決済処理かのいずれかを選択する。選択部１５２３は、利用者が所定方式払い処理を指定した場合、所定方式払い処理を選択する。選択部１５２３は、利用者が通常の決済処理を指定した場合、通常の決済処理を選択する。選択部１５２３は、選択した決済の態様に応じた情報の送信を送信部１５２４に送信させる。

（送信部１５２４）
送信部１５２４は、選択部１５２３による決済の態様の選択に応じて決済サーバ１０に情報を送信する。送信部１５２４は、通常の決済処理が選択された場合、通常の決済処理を要求する情報を決済サーバ１０に送信する。また、送信部１５２４は、所定方式払い処理が選択された場合、所定方式払い処理を要求する情報を決済サーバ１０に送信する。

送信部１５２４は、端末装置の利用者に対して所定の経費の精算処理を実行する情報処理装置に対し、受付部１５２２により受け付けられた決済情報を、所定の経費の精算対象となる決済の内容を示す精算情報として送信する。例えば、図１の例において、送信部１５２４は、図２に示す画面ＳＣ３に含まれるレシートの画像Ｐ１と、決済内容と、電子決済サービスにおける利用者Ｕの利用者ＩＤとを含む決済情報を精算情報として精算処理サーバ２００に送信する。

また、送信部１５２４は、利用者が属する組織から利用者に対して支払われる所定の経費の精算処理を実行する情報処理装置に対し、決済情報を送信してもよい。例えば、図１の例において、送信部１５２４は、利用者Ｕが属する事業者Ｂから利用者に対して支払われる経費の精算処理サービスを提供する精算処理サーバ２００に対し、決済情報を送信する。

また、送信部１５２４は、所定の決済手段において利用可能な電子マネーを用いて利用者に対して所定の経費の精算処理を実行する情報処理装置に対し、決済情報を送信してもよい。例えば、図１の例において、送信部１５２４は、決済アプリを用いた決済手段において利用可能な電子マネーを用いる経費の精算処理サービスを提供する精算処理サーバ２００に対し、決済情報を送信する。

また、送信部１５２４は、利用者に紐付けられた情報処理装置に決済情報を送信してもよい。例えば、送信部１５２４は、決済サーバ１０において利用者と紐付けて管理されている精算処理サービスに対し、決済情報を送信する。

また、送信部１５２４は、申請情報を精算処理サーバ２００に送信する。送信部１５２４は、決済情報と同様の内容を含む申請情報を精算処理サーバ２００に送信する。

〔４．決済サーバ１０による所定方式払い処理のフロー〕
次に、図１０を用いて、実施形態に係る決済サーバ１０の所定方式払い処理の手順について説明する。図１０は、実施形態に係る所定方式払い処理の手順の一例を示すフローチャートである。

図１０に示すように、決済サーバ１０は、利用者が利用する端末装置を用いた所定の決済手段による決済が所定方式払い処理の対象であることを示す処理対象情報を受信する（ステップＳ１０１）。

決済サーバ１０は、利用者が保有する第１口座とは異なる口座である第２口座から、決済の支払先の口座である第３口座へ決済の金額を移行させる処理を実行する（ステップＳ１０２）。

〔５．情報処理システム１による情報処理のフロー〕
次に、図１１を用いて、実施形態に係る情報処理システム１による情報処理の手順について説明する。図１１は、実施形態に係る情報処理システムによる情報処理手順を示すシーケンス図である。なお、図１１に示すシーケンス図では、決済サーバ１０、利用者端末１００、精算処理サーバ２００及び事業者端末３００に関する処理を示す。

まず、利用者端末１００は、決済サーバ１０に所定方式払い処理を要求する（ステップＳ２０１）。利用者端末１００は、所定方式払い処理の対象となる決済（対象決済）を示す処理対象情報を決済サーバ１０に送信することにより、その対象決済の所定方式払い処理を要求する。

そして、所定方式払い処理の要求を受信した決済サーバ１０は、対象決済の所定方式払い処理を実行する（ステップＳ２０２）。決済サーバ１０は、利用者端末１００を利用する利用者が保有する第１口座とは異なる口座である第２口座から、対象決済の支払先の口座である第３口座へ対象決済の金額を移行させることにより、所定方式払い処理を実行する。

そして、利用者端末１００は、経費申請の対象となる決済を選択する（ステップＳ２０３）。例えば、利用者端末１００は、所定方式払い決済である対象決済を経費申請の対象として選択する。そして、利用者端末１００は、経費として申請する対象となる対象決済を示す申請情報（決済内容や、レシートの画像など）を精算処理サーバ２００に送信する（ステップＳ２０４）。例えば、利用者端末１００は、決済アプリを介して申請情報を精算処理サーバ２００に送信する。

そして、精算処理サーバ２００は、利用者端末１００から送信された決済情報（精算情報）に基づく経費の承認要求を事業者端末３００に送信する（ステップＳ２０５）。そして、事業者端末３００は、承認要求が示す経費の申請を承認する操作を事業者から受け付け、承認要求に対応する経費の精算要求を決済サーバ１０に送信する（ステップＳ２０６）。なお、図１１では、事業者端末３００が経費の支払要求を決済サーバ１０に送信する場合を図示したが、事業者端末３００は精算処理サーバ２００を介して経費の支払要求を決済サーバ１０に送信してもよい。例えば、事業者端末３００は精算処理サーバ２００に経費の支払要求を送信し、事業者端末３００から経費の支払要求を受信した精算処理サーバ２００が決済サーバ１０に経費の支払要求を送信してもよい。そして、決済サーバ１０は、事業者端末３００から受け付けた精算要求に対応する精算処理を実行する（ステップＳ２０７）。例えば、決済サーバ１０は、事業者端末３００から対象決済について精算要求を受信した場合、事業者が保有する第４口座から第２口座へ決済の金額を移行させる処理を実行することにより、精算処理を実行する。

〔６．変形例〕
上述の実施形態は一例を示したものであり、種々の変更及び応用が可能である。上述した例では、利用者端末１００が所定の決済処理（所定方式払い処理）を行う情報処理装置である場合を示したが、所定の決済処理（所定方式払い処理）を行う情報処理装置は、決済サーバ１０に限られない。例えば、所定の決済処理（所定方式払い処理）等の口座の出入金に関する処理を行う口座処理装置が所定の決済処理（所定方式払い処理）を行う情報処理装置であってもよい。すなわち、決済サーバ１０と所定の決済処理（所定方式払い処理）を行う情報処理装置とは異なる装置であってもよい。この場合、口座処理装置は、受信部４４と同様の機能を有する受信部、及び実行部４６と同様の機能を有する実行部を有する。口座処理装置の受信部は、利用者端末１００から情報を受信してもよいし、決済サーバ１０から情報を受信してもよい。そして、口座処理装置の実行部は、受信した情報を基に所定の決済処理（所定方式払い処理）等の口座の出入金に関する処理を行う。

〔６−１．決済情報〕
上述の実施形態において、送信部１５２４が、レシートの画像及び決済内容を含む決済情報を精算情報として送信する例を示したが、送信部１５２４の機能はこのような例に限定されない。例えば、送信部１５２４は、利用者が属する組織における経費精算の規定に定められた任意の情報を、精算情報として送信してもよい。また、送信部１５２４は、レシートの画像を含まない決済情報を精算情報として送信してもよい。

〔６−２．レシートの画像の登録〕
上述の実施形態において、決済アプリを用いて行った決済を経費の精算対象とすることを利用者が希望した場合に、受付部１５２２が、決済に応じて支払先から提供されたレシートの画像を受け付け、精算情報として利用する例を示した。しかしながら、受付部１５２２の機能はこのような例に限定されない。例えば、受付部１５２２は、経費の精算対象となる決済に限らず、決済アプリを用いて行なわれた決済のうち、利用者に任意に選択された決済について、支払先から提供されたレシートの画像の登録を受け付け、決済を識別するための情報（決済ＩＤ）と共に決済サーバ１０に送信してもよい。そして、決済サーバ１０は、受け付けたレシートの画像と、決済ＩＤとを紐付けて利用者情報データベース３２で管理し、利用者端末１００からの要求に応じてレシートの画像を提供する。

これにより、利用者端末１００は、決済アプリを用いて行った決済のそれぞれに対応するレシートの画像を利用者にすることができるため、利用者が紙媒体に印刷されたレシートを整理する必要がなくなり、利便性を向上させることができる。また、決済サーバ１０ＯＣＲを用いてレシートの画像から特定した情報（例えば、利用者の購入履歴）に基づいて、利用者に広告コンテンツ等を提供することができるため、利用者に提供する情報の訴求効果を向上させることができる。

〔６−３．複数の精算処理サービスとの連携〕
上述の決済サーバ１０が提供する電子決済サービスは、一の精算処理サービスに限らず、複数の精算処理サービスと連携（紐付け）されてもよい。そして、送信部１５２４は、電子決済サービスに紐付けられた複数の精算処理サービスのいずれかに対し、決済情報を送信してもよい。例えば、利用者が複数の組織に属する場合、決済サーバ１０は、利用者と、利用者が属する各組織と、各組織における経費の精算処理を行う際に利用される精算処理サービスとを紐付けて管理する。この場合、表示制御部１５２１は、利用者と紐付けられた組織を、利用者が選択可能な状態で画面に表示させる。そして、送信部１５２４は、利用者が選択した組織に紐付けられた精算処理サービス（言い換えると、精算処理サービスを提供する情報処理装置）に対し、決済情報を送信する。

なお、表示制御部１５２１は、利用者と紐付けられた複数の精算処理サービスを、利用者が選択可能な状態で画面に表示させてもよい。この場合、送信部１５２４は、利用者により選択された精算処理サービスに対し、決済情報を送信する。また、表示制御部１５２１は、利用者が登録した決済情報（例えば、経費の種類）に応じて、経費の申請先とする組織のサジェスト（提案）を示す情報、または、決済情報の送信先である精算処理サービスのサジェストを示す情報を表示させてもよい。

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

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

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

〔７．効果〕
上述してきたように、実施形態に係る情報処理装置（実施形態では決済サーバ１０）は、受信部４４と、実行部４６とを有する。受信部４４は、利用者が利用する端末装置（実施形態では利用者端末１００）を用いた所定の決済手段による決済が所定の決済処理（実施形態では所定方式払い処理）の対象であることを示す処理対象情報を受信する。実行部４６は、処理対象情報が受信された場合、利用者が保有する第１口座とは異なる口座である第２口座から、決済の支払先の口座である第３口座へ決済の金額を移行させる処理を実行する。

このように、実施形態に係る決済サーバ１０は、端末装置を用いた所定の決済手段による決済が所定の決済処理の対象である場合、利用者が保有する第１口座とは異なる口座である第２口座から、決済の支払先の口座である第３口座へ決済の金額を移行させる処理を実行する。これにより、決済サーバ１０は、利用者が保有する第１口座の金額を変動させることなく、決済の支払先への入金を完了させることができるため、端末装置を用いた決済の柔軟性を向上させることできる。

また、実施形態に係る決済サーバ１０において、受信部４４は、利用者による決済を所定の決済処理の対象に指定する操作に基づく処理対象情報を端末装置から受信する。

これにより、実施形態に係る決済サーバ１０は、利用者の操作に応じて、端末装置を用いた所定の決済手段による決済について所定方式払い処理を行うことにより、利用者の要望に応じて所定方式払い処理を行うことができ、端末装置を用いた決済の柔軟性を向上させることできる。

また、実施形態に係る決済サーバ１０において、受信部４４は、決済が経費精算の対象であることを示す処理対象情報を受信する。実行部４６は、利用者が属する事業者の第２口座から、第３口座へ決済の金額を移行させる処理を実行する。

これにより、実施形態に係る決済サーバ１０は、経費精算の対象となる決済について所定方式払い処理を行うことにより、利用者の口座からの支払先へ支払い、いわゆる持ち出しを行うことなく経費としての処理ができるため、端末装置を用いた決済の柔軟性を向上させることできる。

また、実施形態に係る決済サーバ１０において、受信部４４は、決済が事業者の経費として承認されたことを示す承認情報を受信する。実行部４６は、承認情報を所定の期間内に受信した場合、事業者が保有する第４口座から第２口座へ決済の金額を移行させる処理を実行する。

これにより、実施形態に係る決済サーバ１０は、決済が経費として承認された場合に、事業者が保有する第４口座から第２口座への入金を行うことにより、利用者の第１口座を対象とする出入金がなく経費精算を完了することができるため、端末装置を用いた決済の柔軟性を向上させることできる。

また、実施形態に係る決済サーバ１０において、実行部４６は、決済が事業者の経費として承認されたことを示す承認情報が所定の期間内に受信しなかった場合、利用者が保有する第１口座から第２口座へ決済の金額を移行させる処理を実行する。

これにより、実施形態に係る決済サーバ１０は、決済が経費として承認されなかった場合に、利用者の第１口座から第２口座への入金を行うことにより、経費として承認されない場合も適切に処理を完了することができるため、端末装置を用いた決済の柔軟性を向上させることできる。

また、実施形態に係る決済サーバ１０は、算出部４５を有する。算出部４５は、経費精算の対象として指定された決済が経費として精算されたか否かに応じて、利用者の信用度合いを示すスコアを算出する。

これにより、実施形態に係る決済サーバ１０は、決済が経費として精算されたか否かに応じて、利用者の信用度合いを示すスコアを算出することで、経費精算に関する利用者の信用度を把握することを可能にすることできる。

また、実施形態に係る決済サーバ１０において、実行部４６は、利用者のスコアが所定値未満である場合、利用者に対して第２口座の利用を停止する。

これにより、実施形態に係る決済サーバ１０は、スコアが低い利用者に対して第２口座の利用を停止することで、経費精算に関する信用度が低い利用者の所定方式払い処理を停止することにより、所定方式払い処理の不正な利用を抑制することできる。

また、実施形態に係る決済サーバ１０において、実行部４６は、事業者に対して与信枠が設定された第２口座から、第３口座へ決済の金額を移行させる処理を実行する。

これにより、実施形態に係る決済サーバ１０は、事業者に対して与信枠を設定して、所定方式払い処理を行う事で、事業者の与信を用いて決済を行うことができるため、端末装置を用いた決済の柔軟性を向上させることできる。

また、実施形態に係る決済サーバ１０において、実行部４６は、利用者に応じた与信枠が設定された第２口座から、第３口座へ決済の金額を移行させる処理を実行する。

これにより、実施形態に係る決済サーバ１０は、利用者に応じた与信枠を設定して、所定方式払い処理を行う事で、利用者ごとに与信枠を設定することができるため、端末装置を用いた決済の柔軟性を向上させることできる。

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

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

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

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

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

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

〔９．その他〕
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述した利用者端末１００は、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。例えば、受付部は、受付手段や受付回路に読み替えることができる。

１ 情報処理システム
１０ 決済サーバ
２０ 通信部
３０ 記憶部
３１ 口座データベース
３２ 利用者情報データベース
４０ 制御部
４１ 受付部
４２ 決済処理部
４３ 支払処理部
４４ 受信部
４５ 算出部
４６ 実行部
１００ 利用者端末
１１０ 通信部
１２０ 記憶部
１３０ 撮像部
１４０ 表示部
１５０ 制御部
１５１ 第１アプリケーション
１５２ 第２アプリケーション
１５２１ 表示制御部
１５２２ 受付部
１５２３ 選択部
１５２４ 送信部
２００ 精算処理サーバ
３００ 事業者端末

Claims (17)

1. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信部と、
   前記処理対象情報が受信された場合、所有者に対応付けて口座データベースに記憶された口座のうち、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座であって、前記口座データベースに記憶された第３口座へ前記決済の金額の電子マネーを移行させる処理を実行する実行部と、
   を有し、
   前記実行部は、
   前記利用者に応じた与信枠が設定された前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理装置。
2. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信部と、
   前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行部と、
   を有し、
   前記受信部は、
   前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
   前記実行部は、
   前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行し、
   前記受信部は、
   前記決済が前記事業者の経費として承認されたことを示す承認情報を受信し、
   前記実行部は、
   前記承認情報を所定の期間内に受信した場合、前記事業者が保有する第４口座から前記第２口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理装置。
3. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信部と、
   前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行部と、
   を有し、
   前記受信部は、
   前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
   前記実行部は、
   前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行し、
   前記実行部は、
   前記決済が前記事業者の経費として承認されたことを示す承認情報が所定の期間内に受信しなかった場合、前記利用者が保有する前記第１口座から前記第２口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理装置。
4. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信部と、
   前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行部と、
   経費精算の対象として指定された前記決済の数と、当該決済が経費として精算された数とを用いた演算により、前記利用者の信用度合いを示すスコアを算出する算出部と、
   を有し、
   前記受信部は、
   前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
   前記実行部は、
   前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理装置。
5. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信部と、
   前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行部と、
   を有し、
   前記受信部は、
   前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
   前記実行部は、
   前記利用者が属する事業者に対して与信枠が設定された前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理装置。
6. 前記実行部は、
   前記利用者の前記スコアが所定値未満である場合、前記利用者に対して前記第２口座の利用を停止する
   ことを特徴とする請求項４に記載の情報処理装置。
7. 前記受信部は、
   前記利用者による前記決済を所定の決済処理の対象に指定する操作に基づく前記処理対象情報を前記端末装置から受信する
   ことを特徴とする請求項１〜６のうちいずれか１つに記載の情報処理装置。
8. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信工程と、
   前記処理対象情報が受信された場合、所有者に対応付けて口座データベースに記憶された口座のうち、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座であって、前記口座データベースに記憶された第３口座へ前記決済の金額の電子マネーを移行させる処理を実行する実行工程と、
   含み、
   前記実行工程は、
   前記利用者に応じた与信枠が設定された前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理方法。
9. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信手順と、
   前記処理対象情報が受信された場合、所有者に対応付けて口座データベースに記憶された口座のうち、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座であって、前記口座データベースに記憶された第３口座へ前記決済の金額の電子マネーを移行させる処理を実行する実行手順と、
   をコンピュータに実行させ、
   前記実行手順は、
   前記利用者に応じた与信枠が設定された前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理プログラム。
10. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信工程と、
    前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行工程と、
    含み、
    前記受信工程は、
    前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
    前記実行工程は、
    前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行し、
    前記受信工程は、
    前記決済が前記事業者の経費として承認されたことを示す承認情報を受信し、
    前記実行工程は、
    前記承認情報を所定の期間内に受信した場合、前記事業者が保有する第４口座から前記第２口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理方法。
11. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信手順と、
    前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行手順と、
    をコンピュータに実行させ、
    前記受信手順は、
    前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
    前記実行手順は、
    前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行し、
    前記受信手順は、
    前記決済が前記事業者の経費として承認されたことを示す承認情報を受信し、
    前記実行手順は、
    前記承認情報を所定の期間内に受信した場合、前記事業者が保有する第４口座から前記第２口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理プログラム。
12. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信工程と、
    前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行工程と、
    含み、
    前記受信工程は、
    前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
    前記実行工程は、
    前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行し、
    前記実行工程は、
    前記決済が前記事業者の経費として承認されたことを示す承認情報が所定の期間内に受信しなかった場合、前記利用者が保有する前記第１口座から前記第２口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理方法。
13. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信手順と、
    前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行手順と、
    をコンピュータに実行させ、
    前記受信手順は、
    前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
    前記実行手順は、
    前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行し、
    前記実行手順は、
    前記決済が前記事業者の経費として承認されたことを示す承認情報が所定の期間内に受信しなかった場合、前記利用者が保有する前記第１口座から前記第２口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理プログラム。
14. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信工程と、
    前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行工程と、
    経費精算の対象として指定された前記決済の数と、当該決済が経費として精算された数とを用いた演算により、前記利用者の信用度合いを示すスコアを算出する算出工程と、
    含み、
    前記受信工程は、
    前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
    前記実行工程は、
    前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理方法。
15. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信手順と、
    前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行手順と、
    経費精算の対象として指定された前記決済の数と、当該決済が経費として精算された数とを用いた演算により、前記利用者の信用度合いを示すスコアを算出する算出手順と、
    をコンピュータに実行させ、
    前記受信手順は、
    前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
    前記実行手順は、
    前記利用者が属する事業者の前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理プログラム。
16. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信工程と、
    前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行工程と、
    含み、
    前記受信工程は、
    前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
    前記実行工程は、
    前記利用者が属する事業者に対して与信枠が設定された前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理方法。
17. 利用者が利用する端末装置を用いた所定の決済手段による決済が所定の決済処理の対象であることを示す処理対象情報を受信する受信手順と、
    前記処理対象情報が受信された場合、前記利用者が保有する第１口座とは異なる口座である第２口座から、前記決済の支払先の口座である第３口座へ前記決済の金額を移行させる処理を実行する実行手順と、
    をコンピュータに実行させ、
    前記受信手順は、
    前記決済が経費精算の対象であることを示す前記処理対象情報を受信し、
    前記実行手順は、
    前記利用者が属する事業者に対して与信枠が設定された前記第２口座から、前記第３口座へ前記決済の金額を移行させる処理を実行することを特徴とする情報処理プログラム。
    

Images