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

Abstract

【課題】給与として受け取ったデジタルマネーの残高を保証するための仕組みを提供すること。
【解決手段】 情報処理装置は、記憶部と、決済処理部とを有する。記憶部は、サービス利用者である事業者が電子決済サービスにおいて保有する事業者用アカウントに紐付く口座であって、企業与信により事業者に付与された与信枠を用いた利用額を示す情報を管理する決済用口座に関する情報を記憶する。決済処理部は、提携先のカード会社から、事業者用アカウントに紐付く物理カードを用いた請求情報を受信した場合、受信した請求情報に基づいて、決済用口座において管理されている利用額を更新し、事業者と所定の関係にあるサービス利用者が電子決済サービスにおいて保有するユーザアカウントであって、事業者用アカウントに紐付くユーザアカウントによる取引情報を受信した場合、取引情報に含まれる決済額に基づいて決済用口座において管理されている利用額を更新する。
【選択図】図４

Description

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

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

特許第６６８２６８８号公報

しかしながら、上記の従来技術では、端末装置を用いた決済を実現するための既存のプラットフォームを用いた決済スキームの援用を図ることが難しい場合がある。

本願は、上記に鑑みてなされたものであって、端末装置を用いた決済を実現するための既存のプラットフォームを用いた決済スキームの援用を図ることができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、記憶部と、送信部と、決済処理部とを有する。記憶部は、電子決済サービスのサービス利用者の各々に紐付く口座に関する情報を記憶する。送信部は、提携先のカード会社に設置されている端末装置に対し、電子決済サービスにおいて事業者用アカウントを保有する事業者からの要求に応じて、事業者用アカウントに紐付く物理カードの発行依頼を送信する。決済処理部は、カード会社から、物理カードを用いた決済に関する請求情報を受信した場合、記憶部に記憶されている立替用口座に管理されている資金から、電子決済サービスにおいてカード会社が保有する口座であって記憶部に記憶されている口座に対して、請求情報に含まれる決済額に相当する額を移行させる立替処理を実行する。

実施形態の一態様によれば、端末装置を用いた決済を実現するための既存のプラットフォームを用いた決済スキームの援用を図ることができるという効果を奏する。

図１は、実施形態に係る情報処理の概要（その１）の一例を示す図である。 図２は、実施形態に係る情報処理の概要（その２）の一例を示す図である。 図３は、実施形態に係る情報処理の概要（その３）の一例を示す図である。 図４は、実施形態に係る決済サーバの構成例を示す図である。 図５は、実施形態に係る残高情報記憶部に記憶される情報の一例を示す図である。 図６は、実施形態に係る与信枠情報記憶部に記憶される第２口座に関する情報の一例を示す図である。 図７は、実施形態に係る利用者情報記憶部に記憶される利用者情報の一例を示す図である。 図８は、実施形態に係るアカウント情報記憶部に記憶されるアカウント認証に関する情報の一例を示す図である。 図９は、実施形態に係る取引情報記憶部に記憶される取引情報の一例を示す図である。 図１０は、実施形態に係る決済サーバにより実行される利用登録処理の処理手順の一例を示すフローチャートである。 図１１は、実施形態に係る決済サーバにより実行される決済処理（その１）の処理手順の一例を示すフローチャートである。 図１２は、実施形態に係る決済サーバにより実行される決済処理（その２）の処理手順の一例を示すフローチャートである。 図１３は、実施形態に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

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

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

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

また、決済サーバ１００は、アカウント開設用のインターフェイスであるアカウント開設画面を通じて、プラットフォームを利用するための事業者用のビジネスアカウント（「事業者用アカウント」の一例）の開設手続に応じて、事業者により設定されたアカウント情報を管理する。たとえば、決済サーバ１００は、アカウント開設画面を通じて、事業者により識別情報として設定された事業者ＩＤを管理する。また、決済サーバ１００は、事業者ＩＤに紐付けて、事業者が電子決済サービスを利用した決済に用いる資金が管理される決済用口座の情報を管理する。決済用口座には、事業者によりチャージされた原資に相当する額の電子マネーの残高であるマネー残高を示す情報や、企業与信により事業者に対して付与された与信枠を示す情報が管理される。

また、決済サーバ１００は、ビジネスアカウントを開設済みの事業者が雇用する社員に対して、電子決済サービスのプラットフォームを通じて、事業者が所有するビジネスアカウントに紐付く決済用口座に管理されている資金により、社員が取引対象の代金の支払いを行う「会社払い」（「所定の支払手段」の一例）を提供するための環境を提供する。また、決済サーバ１００は、事業者に対して、「会社払い」を許可する社員に関する情報を設定するためのインターフェイスである事業者用管理画面を提供する。また、決済サーバ１００は、事業者に対して、事業者用管理画面を操作するための機能を備える事業者用のアプリケーションプログラムを提供してもよい。

また、決済サーバ１００は、電子決済サービスを利用する個人ユーザや事業者などのサービス利用者に対して、電子決済サービスを利用するための各種機能を備えたアプリケーションプログラム（以下、適宜「ユーザアプリ」と称する。）を配布できる。決済サーバ１００は、ユーザアプリ専用のインターフェイスを介して、ユーザアプリからの取引要求を受け付けた場合は、その取引要求に従って、口座間における電子マネーの送金処理などを含む情報処理を実行する。ユーザアプリは、決済先、決済元、及び決済額などの情報を含む取引情報を決済サーバ１００に送信する。なお、取引情報には、上述の各情報の他、取引を個別に特定するための取引コードや、取引が行われた日時を特定するための日時情報（タイムスタンプ）などの情報が含まれていてもよい。

図１に示す事業者端末１０は、商品やサービスなどの取引対象を個人ユーザに提供する事業を営む事業者であり、複数の社員Ｅを雇用して企業Ｘを経営する管理者Ｍにより利用される情報処理端末である。事業者端末１０を利用する事業者である管理者Ｍは、電子決済サービスを提供するサービス事業者との間でビジネスアカウントの利用契約を締結することにより、ビジネスアカウントを保有する。なお、管理者Ｍは、ビジネスアカウントの利用契約に加えて、電子決済サービスを提供するサービス事業者との間で、電子決済サービスのプラットフォームを用いた決済処理の利用許諾を得るための加盟店契約を締結している場合、加盟店ともなり得る。事業者端末１０は、たとえば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）などにより実現される。また、事業者端末１０は、決済サーバ１００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。たとえば、事業者端末１０は、決済サーバ１００により提供される管理画面を表示する。

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

図１に示す利用者端末２０は、企業Ｘを経営する事業者により雇用される社員Ｅにより利用される情報処理端末である。利用者端末２０は、電子決済サービスを利用した決済に関する取引情報を決済サーバ１００に送信できる。利用者端末２０は、たとえば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）などにより実現される。また、利用者端末２０は、決済サーバ１００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。図１に示す例では、利用者端末２０－１としてスマートフォンが示されており、利用者端末２０－２としてノート型ＰＣが示されている。

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

図１に示す店舗端末３０－１は、加盟店ＳＨ－１に設置される情報処理端末である。加盟店ＳＨ－１は、電子決済サービスを提供するサービス事業者との間で、電子決済サービスのプラットフォームを用いた決済処理の利用許諾を得るための加盟店契約を締結した事業者により運営および管理される店舗である。なお、企業Ｘの事業者は、電子決済サービスを提供するサービス事業者との間で加盟店契約を締結している場合、ビジネスアカウントの開設に加えて加盟店となる。店舗端末３０－１は、電子決済サービスを利用した決済に関する取引情報を決済サーバ１００に送信できる。店舗端末３０－１は、たとえば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）などにより実現される。また、店舗端末３０－１は、決済サーバ１００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。

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

（１－２．利用者端末２０を用いた決済について）
ここで、利用者端末２０を用いたコード決済（電子決済）の一例について説明する。以下の説明では、電子決済サービスを利用可能な加盟店である店舗Ｚに配置された２次元コード（ＱＲコード（登録商標））であって、店舗Ｚを識別する店舗識別情報を示す２次元コードを用いて、店舗Ｚから取引対象の提供を受ける利用者（たとえば、図１に示す社員Ｅなど）が利用者端末２０を用いた決済を行う例について説明する。なお、以下に説明するコード決済の一例は、任意の利用者が任意の利用者端末２０を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報を示す２次元コードは、ＱＲコードのみならず、バーコードや所定のマーク、番号などであってもよい。また、２次元コードは、紙などの媒体に印字された印刷物により物理的に構成される例に限られず、任意の端末に表示される画像情報により構成されていてもよい。

たとえば、利用者が店舗Ｚにて各種の商品やサービスといった取引対象の購入や利用に伴う決済を行う場合、利用者は、利用者端末２０に予めインストールされたユーザアプリを起動する。そして、利用者は、ユーザアプリを介して、店舗Ｚに設置された２次元コードを撮影する。このような場合、利用者端末２０は、取引対象の価格を入力するための画面を表示し、利用者あるいは店舗Ｚの店員から決済金額の入力を受け付ける。そして、利用者端末２０は、利用者を識別する利用者識別情報と、店舗識別情報（もしくは、店舗識別情報が示す情報、すなわち、店舗Ｚを示す情報（たとえば、店舗ＩＤ））と、決済額とを含む取引情報を決済サーバ１００へと送信する。利用者端末２０が店舗Ｚに設置されている２次元コードを撮影して取引情報を決済サーバ１００にアップロードすることにより行われる決済を「ユーザスキャン決済」と称する場合がある。

決済サーバ１００は、利用者端末２０から取引情報を受け付けると、利用者識別情報が示す利用者の口座から、店舗識別情報が示す店舗Ｚの口座へと、決済額に相当する分の電子マネーを移行させる。このとき、決済サーバ１００は、決済額に相当する分の電子マネーから店舗Ｚに課金する所定の手数料を差し引いてから、店舗Ｚの口座へ移行させてもよい。そして、決済サーバ１００は、取引が完了した旨の通知を利用者端末２０へと送信する。このような場合、利用者端末２０は、取引が完了した旨の画面や所定の音声を出力することで、電子マネーによる取引が完了した旨を利用者に通知する。あるいは、決済サーバ１００は、利用者識別情報が示す利用者の口座から決済額に相当する分の電子マネーを引き出して店舗Ｚの売り上げ情報として管理し、所定のタイミングで売上に相当する額の現金を店舗Ｚが保有する銀行口座に振り込んでもよい。この場合、決済サーバ１００は、利用者の口座から決済額に相当する分の電子マネーを引き出したタイミングで、電子マネーによる取引が完了した旨を利用者に通知してもよい。

なお、利用者端末２０を用いた決済は、上述した処理に限定されるものではない。たとえば、利用者端末２０を用いた決済は、店舗Ｚに設置された端末装置（以下、「店舗端末３０」と称する。）を用いたものであってもよい。具体的には、まず、利用者端末２０は、利用者を識別するための利用者識別情報を示すコード情報を画面上に表示させる。このような場合、店舗端末３０は、利用者端末２０に表示されたコード情報から利用者識別情報を読み取り、読み取った利用者識別情報（もしくは、利用者識別情報が示す情報、すなわち、利用者を示す情報（たとえば、利用者ＩＤ））と、決済額と、店舗Ｚを識別する情報とを含む取引情報を決済サーバ１００へと送信する。店舗端末３０が利用者端末２０に表示されたコード情報を読み取って取引情報を決済サーバ１００にアップロードすることにより行われる決済を「ストアスキャン決済」と称する場合がある。

決済サーバ１００は、店舗端末３０から取引情報を受け付けると、利用者識別情報が示す利用者の口座から、店舗Ｚの口座へと、決済額に相当する分の電子マネーを移行させる。そして、決済サーバ１００は、店舗端末３０あるいは利用者端末２０に対し、取引が完了した旨の通知を送信する。店舗端末３０あるいは利用者端末２０は、取引が完了した旨の画面や所定の音声を出力することで、電子マネーによる取引が完了した旨を利用者に通知する。また、決済サーバ１００は、利用者識別情報が示す利用者の口座から決済額に相当する分の電子マネーを引き出して店舗Ｚの売り上げ情報として管理し、所定のタイミングで売上に相当する額の現金を店舗Ｚが保有する銀行口座に振り込んでもよい。この場合、決済サーバ１００は、利用者の口座から決済額に相当する分の電子マネーを引き出したタイミングで、電子マネーによる取引が完了した旨を店員あるいは利用者に通知してもよい。

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

また、利用者端末２０を用いた決済は、利用者の口座から店舗Ｚの口座へと電子マネーを移行させる処理のみならず、たとえば、利用者の口座から他のユーザの口座へと電子マネーを移行させる決済（すなわち、ユーザ間での送金）であってもよい。たとえば、送金元の利用者が利用する利用者端末２０は、送金先のユーザを識別する利用者識別情報（例えば、送金先の利用者が利用する端末装置に表示される利用者識別情報）を読み取り、利用者から送金金額の入力を受け付け、読み取った識別情報と、送金金額と、利用者を識別する利用者識別情報とを示す情報を決済サーバ１００へと送信する。このような場合、決済サーバ１００は、利用者の口座から、送金先のユーザの口座へと、送金金額が示す額の電子マネーを移行させ、利用者端末２０または送金先のユーザが利用する端末装置に対し、送金が完了した旨の画面や所定の音声を出力させることで、送金が行われた旨を通知してもよい。

なお、利用者端末２０を用いた送金は、上述した処理に限定されるものではない。たとえば、利用者端末２０を用いた送金は、送金先のユーザの電話番号や、送金先のユーザを示す情報（たとえば、利用者ＩＤ）を利用者端末２０に入力することにより行われてもよい。具体的な例を挙げると、利用者端末２０は、送金先のユーザの電話番号または利用者ＩＤと、送金金額との入力を利用者から受け付け、入力された電話番号または利用者ＩＤと、送金金額と、利用者を識別する利用者識別情報とを決済サーバ１００へと送信する。そして、決済サーバ１００は、利用者の口座から、送信された電話番号または利用者ＩＤに紐づけられたユーザの口座へと、送金金額が示す額の電子マネーを移行させる。

ここで、送金先のユーザの電話番号や利用者ＩＤは、当該ユーザに関する情報と紐付けてユーザアプリに予め登録されていてもよい。この場合、利用者端末２０は、ユーザアプリに登録されたユーザ（送金先）の指定と、当該ユーザへの送金金額の入力とを利用者から受け付け、指定されたユーザに紐付けられた電話番号または利用者ＩＤと、送金金額と、利用者を識別する利用者識別情報とを決済サーバ１００へと送信する。

また、たとえば、利用者端末２０を用いた送金は、送金金額を受け取るためのリンク情報を送金先のユーザに提供することにより行われてもよい。具体的な例を挙げると、利用者端末２０は、利用者から送金金額の入力を受け付けて送金金額を受け取るためのリンク情報を生成し、リンク情報を含む電子メールを送信したり、リンク情報を含む投稿情報をＳＮＳ（Social Networking Service）に投稿したりすることで、送金先のユーザが利用する端末装置にリンク情報を提供する。そして、送金先のユーザがリンク情報を選択して受け取り操作を行った場合、決済サーバ１００は、利用者の口座から、送金先のユーザの口座へと、送金金額が示す額の電子マネーを移行させる。

なお、上述した決済手段や決済サービスは、商品の購入や役務の提供に対する対価の提供（債務の精算）のためのものに限定されるものではない。例えば、上述したように、決済手段や決済サービスは、複数のユーザが有する口座間の送金に関する機能を有していてもよい。すなわち、上述した決済手段や決済サービスは、ユーザや店舗等、電子マネーの所有者と紐づく任意の所有者の口座間における電子マネーの送受信を制御するサービスであればよい。すなわち、実施形態に係る決済手段や決済サービスは、電子マネーのやり取りを実現するための各種制御（電子マネーを介した各種の口座間送金制御のみならず、電子マネー口座と銀行口座間のやり取りに関する制御や、分割、ボーナス払いに伴う処理といった各種債権処理、その他電子マネーを含む財産のやり取りに関する各種制御）を実行する取引手段や取引サービスであれば、任意の態様で提供されるものであってもよい。また、このような取引手段や取引サービスが実現する各種の制御には、決済に関する制御と送金に関する制御の両方が含まれていてもよく、いずれか一方のみが含まれていてもよい。すなわち、「取引」とは、電子マネーに関する「決済」のみならず、電子マネーの「送金」やその他各種の処理をも含む概念である。すなわち、決済サーバ１００は、任意の所有者間における電子マネーのやり取りを制御する取引手段を実現する情報処理装置であってもよい。

（１－３．実施形態の概要について）
（１－３－１．情報処理の概要（その１））
以下、図面を参照しつつ、情報処理システムＳＹＳ－１において決済サーバ１００などにより実行される情報処理の概要を説明する。以下に説明する実施形態に係る情報処理の概要は、管理者Ｍが、社員Ｅに対し、電子決済サービスのプラットフォームを通じて取引対象についての代金の支払いを行うための所定の支払手段の１つとして、「会社払い」の利用を許可するためのアカウントを付与する情報処理の一例を示している。

まず、図１を用いて、実施形態に係る情報処理の概要（その１）について説明する。図１は、「会社払い」を実現するためのスキームの１つである「残高利用型」の概要を示している。「残高利用型」は、管理者Ｍが開設したビジネスアカウントに紐付く決済用口座に管理されているマネー残高を用いた「会社払い」を実現する。

なお、以下の説明では、事業者端末１０を管理者Ｍと同一視する場合がある。すなわち、以下では、管理者Ｍを事業者端末１０と読み替えることもできる。また、以下の説明では、利用者端末２０を社員Ｅと同一視する場合がある。すなわち、以下では、社員Ｅを利用者端末２０と読み替えることもできる。また、以下の説明において、図１に示す利用者端末２０－１および利用者端末２０－２を特に区別して説明する必要がない場合、利用者端末２０と総称する。

図１に示す企業Ｘに所属する管理者Ｍは、まず、「会社払い」を利用するためのビジネスアカウントの開設およびマネー残高のチャージを行う（ステップＳ００）。たとえば、管理者Ｍは、決済サーバ１００から提供されるビジネスアカウント開設用のウェブページに、ユーザＩＤなどの必要事項の登録を行うことにより、ビジネスアカウントの開設手続を行う。管理者Ｍが登録するユーザＩＤは、管理者Ｍ（企業Ｘ）を識別するための事業者ＩＤ（事業者識別情報）として機能する。なお、決済サーバ１００は、ビジネスアカウントの開設希望者に固有の事業者ＩＤを任意に設定してもよい。また、たとえば、管理者Ｍは、ビジネスアカウントの開設の際に登録した銀行口座から、決済サーバ１００が所有する所定の銀行口座に対して送金する。決済サーバ１００は、管理者Ｍからの着金（送金の到着）を確認すると、管理者Ｍに対応するビジネスアカウントに紐付く決済用口座に対して、送金額に相当する額に電子マネーの残高であるマネー残高を反映する。

ビジネスアカウントの開設およびマネー残高のチャージを行った後、管理者Ｍは、事業者端末１０に表示される管理画面を操作して、「会社払い」を許可する利用者に関する利用者情報を設定する。たとえば、管理者Ｍは、利用者情報として、社員番号や、氏名や、認証用メールアドレスや、利用可能上限額などの情報を設定する。認証用メールアドレスは、社員Ｅに紐付くメールアドレスに該当する。また、利用可能上限額は、「会社払い」を利用して取引対象の代金の支払いを行うことが可能な金額として設定される上限額に該当する。なお、管理者Ｍは、利用者情報として、「会社払い」の利用が可能な取引対象のカテゴリ（たとえば、食品や飲食、交通など）を示す対象カテゴリ情報や、「会社払い」の利用が可能な場所を示す対象ロケーション情報などを設定してもよい。たとえば、対象ロケーション情報は、行政区や市区町村などのエリアを特定する情報の他、たとえば、提携先ホテルなどの特定の加盟店の情報などを含み得る。決済サーバ１００は、対象ロケーション情報に基づいて、「会社払い」が利用可能なエリアや、特定の加盟店などを絞り込むことが可能となる。

事業者端末１０は、管理画面を通じて管理者Ｍにより登録された利用者情報を、管理者Ｍによる操作に応じて決済サーバ１００に送信する（ステップＳ０１）。

決済サーバ１００は、事業者端末１０から利用者情報を受信すると、管理者Ｍが開設したビジネスアカウントと、電子決済サービスにおいて社員Ｅが所有しているユーザアカウントとを連携させるための会社払い利用開始案内メール（「認証用情報」の一例）を利用者端末２０に送信する（ステップＳ０２）。具体的には、決済サーバ１００は、利用者情報に含まれる認証用メールアドレスを宛先とし、ビジネスアカウントとユーザアカウントとを紐付けるための所定のリンクを含む電子メールを利用者端末２０に送信する。たとえば、所定のリンクは、ユーザアカウント登録用のウェブページを利用者端末２０に表示させるためのＵＲＬ（Uniform Resource Locator）などのアドレス情報に該当する。決済サーバ１００は、所定のリンクとして、ビジネスアカウントごとに固有のアドレス情報を生成し、会社払い利用開始案内メールに挿入する。

社員Ｅは、利用者端末２０を操作して、会社払い利用開始案内メール（以下、「案内メール」と称する。）のリンク先からアカウント認証を実行する（ステップＳ０３）。たとえば、決済サーバ１００は、社員Ｅから、案内メールに含まれる所定のリンクに対するアクセスを受け付けると、ユーザアカウント登録用のウェブページを表示させるための情報を利用者端末２０に送信する。利用者端末２０は、決済サーバ１００から受信した情報に基づいて、ユーザアカウント登録用のウェブページを表示する。社員Ｅは、利用者端末２０に表示されているウェブページに自身のユーザアカウントを示す情報を登録することによりアカウント認証を実施する。

なお、決済サーバ１００は、有効期限が設定された所定のリンクを含む案内メールを利用者端末２０に送信してもよい。これにより、決済サーバ１００は、社員Ｅから、案内メールに含まれる所定のリンクに対するアクセスを受け付けたタイミングで、所定のリンクに設定されている有効期限が切れている場合、ユーザアカウント登録用のウェブページを表示させるための情報を利用者端末２０に送信しない。

決済サーバ１００は、アカウント認証により社員Ｅによりユーザアカウントの登録が行われると、ビジネスアカウントと対象ユーザアカウントとの紐付け（アカウント連携）を行う（ステップＳ０４－１）。具体的には、決済サーバ１００は、社員Ｅがユーザアカウントの登録を行ったウェブページに対応するビジネスアカウントを示す情報と、社員Ｅにより登録されたユーザアカウントを示す情報とを対応付けて記憶部に格納する。

また、決済サーバ１００は、ビジネスアカウントと対象ユーザアカウントとを紐付けた後、対象ユーザアカウントの「会社払い」を有効化する（ステップＳ０４－２）。具体的には、決済サーバ１００は、対象ユーザアカウントに対応付けて、「会社払い」が有効であることを示す情報を記憶部に格納する。これにより、対象ユーザアカウントを所有するユーザが、ユーザアプリを用いてコード決済を行う際、決済額の支払手段として「会社払い」を選択可能な状態となる。決済サーバ１００は、「会社払い」の利用手続きが完了した旨の通知を利用者端末２０に送信することにより、社員Ｅに通知する。

社員Ｅは、「会社払い」の利用手続きが完了した後、ユーザアプリ上で、「会社払い」の利用可能枠を確認できる（ステップＳ０５）。社員Ｅがユーザアプリ上で確認できる「会社払い」の利用可能枠は、管理者Ｍにより登録された利用者情報に含まれる利用可能上限額に相当する。

また、社員Ｅは、電子決済サービスの加盟店ＳＨ－１において、ユーザスキャン、ストアスキャン、又はオンライン決済で決済する際、たとえば、支払手段として「会社払い」を選択して決済を行う（ステップＳ０６）。

決済サーバ１００は、利用者端末２０または店舗端末３０－１から取引情報を受信すると、会社払い元のビジネスアカウントの残高から即時減算して支払いを完了する（ステップＳ０７）。具体的には、決済サーバ１００は、取引情報において「会社払い」が選択されている場合、支払元であるユーザアカウントに対応付けられているビジネスアカウントを特定する。そして、決済サーバ１００は、特定したビジネスアカウントに紐付く決済用口座に管理されているマネー残高から、支払先として取引情報に含まれている加盟店ＳＨ－１に紐付く支払先口座に対して、取引情報に含まれる決済額に相当する額を移行させる処理を実行する。また、決済サーバ１００は、管理者Ｍからの要求に応じて、「会社払い」を利用した決済に関する取引情報を事業者端末１０に送信することにより管理者Ｍに提供する。

事業者端末１０は、「会社払い」を利用した決済に関する取引情報を決済サーバ１００から受信すると、受信した取引情報を管理画面上に表示する。管理者Ｍは、管理画面上に表示された取引情報を閲覧することにより、リアルタイムで取引明細を確認できる（ステップＳ０８）。

また、管理者Ｍは、管理画面を操作して、「会社払い」を利用した決済に関する取引情報の取引ファイルを決済サーバ１００からダウンロードし、ダウンロードした取引ファイルを経理管理システムにアップロードすることにより、経理管理元データとして取込処理を実行できる（ステップＳ０９）。

また、上述した情報処理の概要（その１）において、管理者Ｍは、たとえば、「会社払い」の利用を許可した社員Ｅが退職する場合、決済サーバ１００に対して、社員Ｅの利用登録の解除を要求する。事業者端末１０は、管理画面を通じて、管理者Ｍから社員Ｅについての「会社払い」の利用登録を解除する操作を受け付けると、決済サーバ１００に対して、社員Ｅについての「会社払い」の解除要求を送信する。決済サーバ１００は、事業者端末１０から、社員Ｅについての「会社払い」の解除要求を受信すると、社員Ｅに対応する利用者情報を非活性処理して、ビジネスアカウントとの紐付けを解除する。

また、上述した情報処理の概要（その１）において、管理者Ｍは、管理画面を操作することにより、「会社払い」の不適切な利用が認められる社員Ｅの利用可能上限額を減額したり、「会社払い」の利用を一時的に禁止したりしてもよい。

（１－３－２．情報処理の概要（その２））
以下、図２を用いて、実施形態に係る情報処理の概要（その２）について説明する。図２は、「会社払い」を実現するためのスキームの１つである「与信利用型」の概要を示している。「与信利用型」は、管理者Ｍが開設したビジネスアカウントに紐付く決済用口座に管理されている与信枠を用いた「会社払い」を実現する。以下に説明する実施形態に係る情報処理の概要（その１）は、ビジネスアカウントに紐付く与信枠に基づく処理である点が、上述した実施形態に係る情報処理の概要（その１）と相違する。

図２に示す企業Ｘに所属する管理者Ｍは、まず、「会社払い」を利用するためのビジネスアカウントの開設を行うとともに、企業与信により与信枠の付与を受ける（ステップＳ２０）。たとえば、管理者Ｍは、決済サーバ１００から提供されるビジネスアカウント開設用のウェブページに、ユーザＩＤなどの必要事項の登録を行うことにより、ビジネスアカウントの開設手続を行う。管理者Ｍが登録するユーザＩＤは、管理者Ｍ（企業Ｘ）を識別するための事業者ＩＤ（事業者識別情報）として機能する。なお、決済サーバ１００は、ビジネスアカウントの開設希望者に対して、事後的に変更可能な任意の事業者ＩＤを個別に割り振ってもよい。また、たとえば、管理者Ｍは、ビジネスアカウントの開設後、電子決済サービスを提供するサービス事業者に対して与信枠の付与を申請する。サービス事業者は、管理者Ｍから与信枠の付与申請を受けると、管理者Ｍが所属する企業Ｘについて与信審査を実行し、与信審査の結果を管理者Ｍに通知するとともに、与信審査の結果に応じた与信枠を付与する。

ビジネスアカウントの開設およびマネー残高のチャージを行った後、管理者Ｍは、事業者端末１０に表示される管理画面を操作して、「会社払い」を許可する利用者に関する利用者情報を設定する。たとえば、管理者Ｍは、利用者情報として、社員番号や、氏名や、認証用メールアドレスや、利用可能上限額などの情報を設定する。認証用メールアドレスは、社員Ｅに紐付くメールアドレスに該当する。また、利用可能上限額は、「会社払い」を利用して取引対象の代金の支払いを行うことが可能な金額として設定される上限額に該当する。なお、管理者Ｍは、利用者情報として、「会社払い」の利用が可能な取引対象のカテゴリ（たとえば、食品や飲食、交通など）を示す対象カテゴリ情報や、「会社払い」の利用が可能な場所を示す対象ロケーション情報（たとえば、コンビニエンスストアやホテル、駅）などを設定してもよい。

事業者端末１０は、管理画面を通じて管理者Ｍにより登録された利用者情報を、管理者Ｍによる操作に応じて決済サーバ１００に送信する（ステップＳ２１）。

決済サーバ１００は、事業者端末１０から利用者情報を受信すると、受信した利用者情報を記憶部に登録する。また、決済サーバ１００は、管理者Ｍが開設したビジネスアカウントと、電子決済サービスにおいて社員Ｅが所有しているユーザアカウントとを連携させるための会社払い利用開始案内メールを送信する（ステップＳ２２）。具体的には、決済サーバ１００は、利用者情報に含まれる認証用メールアドレスを宛先とし、ビジネスアカウントとユーザアカウントとを紐付けるための所定のリンクを含む電子メールを利用者端末２０に送信する。たとえば、所定のリンクは、ユーザアカウント登録用のウェブページを利用者端末２０に表示させるためのＵＲＬ（Uniform Resource Locator）などのアドレス情報に該当する。決済サーバ１００は、所定のリンクとして、ビジネスアカウントごとに固有のアドレス情報を生成し、会社払い利用開始案内メールに挿入する。

社員Ｅは、利用者端末２０を操作して、会社払い利用開始案内メール（以下、「案内メール」と称する。）のリンク先からアカウント認証を実行する（ステップＳ２３）。たとえば、決済サーバ１００は、社員Ｅから、案内メールに含まれる所定のリンクに対するアクセスを受け付けると、ユーザアカウント登録用のウェブページを表示させるための情報を利用者端末２０に送信する。利用者端末２０は、決済サーバ１００から受信した情報に基づいて、ユーザアカウント登録用のウェブページを表示する。社員Ｅは、利用者端末２０に表示されているウェブページに自身のユーザアカウントを示す情報を登録することによりアカウント認証を実施する。

なお、決済サーバ１００は、有効期限が設定された所定のリンクを含む案内メールを利用者端末２０に送信してもよい。これにより、決済サーバ１００は、社員Ｅから、案内メールに含まれる所定のリンクに対するアクセスを受け付けたタイミングで、所定のリンクに設定されている有効期限が切れている場合、ユーザアカウント登録用のウェブページを表示させるための情報を利用者端末２０に送信しない。

決済サーバ１００は、アカウント認証により社員Ｅによりユーザアカウントの登録が行われると、ビジネスアカウントと対象ユーザアカウントとの紐付けを行う（ステップＳ２４－１）。具体的には、決済サーバ１００は、社員Ｅがユーザアカウントの登録を行ったウェブページに対応するビジネスアカウントを示す情報と、社員Ｅにより登録されたユーザアカウントを示す情報とを対応付けて記憶部に格納する。

また、決済サーバ１００は、ビジネスアカウントと対象ユーザアカウントとを紐付けた後、対象ユーザアカウントの「会社払い」を有効化する（ステップＳ２４－２）。具体的には、決済サーバ１００は、対象ユーザアカウントに対応付けて、「会社払い」が有効であることを示す情報を記憶部に格納する。これにより、対象ユーザアカウントを所有するユーザが、ユーザアプリを用いてコード決済を行う際、決済額の支払手段として「会社払い」を選択可能な状態となる。決済サーバ１００は、「会社払い」の利用手続きが完了した旨の通知を利用者端末２０に送信することにより、社員Ｅに通知する。

社員Ｅは、「会社払い」の利用手続きが完了した後、ユーザアプリ上で、「会社払い」の利用可能枠を確認できる（ステップＳ２５）。社員Ｅがユーザアプリ上で確認できる「会社払い」の利用可の枠は、管理者Ｍにより登録された利用者情報に含まれる利用可能上限額に相当する。

また、社員Ｅは、電子決済サービスの加盟店ＳＨ－１において、ユーザスキャン、ストアスキャン、又はオンライン決済で決済する際、たとえば、支払手段として「会社払い」を選択して決済を行う（ステップＳ２６）。

決済サーバ１００は、取引情報において「会社払い」が選択されている場合、利用者端末２０または店舗端末３０－１から取引情報を受信すると、サービス提供者が予め保有する立替用口座のマネー残高から、支払先として取引情報に含まれている加盟店ＳＨ－１に紐付く支払先口座に対して、取引情報に含まれている決済額に相当する額を移行する立替処理を実行して、加盟店ＳＨ－１に対する支払いを完了する（ステップＳ２７－１）。また、決済サーバ１００は、取引情報に含まれている支払い支払元であるユーザアカウントに対応付けられているビジネスアカウントを特定する。決済サーバ１００は、特定したビジネスアカウントに紐付く決済用口座に管理されている与信枠における利用額を更新する（ステップＳ２７－２）。具体的には、決済サーバ１００は、取引情報に含まれている決済額に相当する額を、ビジネスアカウントに紐付く与信枠における利用額に加算する。

事業者端末１０は、「会社払い」を利用した決済に関する取引情報を決済サーバ１００から受信すると、受信した取引情報を管理画面上に表示する。管理者Ｍは、管理画面上に表示された取引情報を閲覧することにより、リアルタイムで取引明細を確認できる（ステップＳ２８）。

また、管理者Ｍは、管理画面を操作して、「会社払い」を利用した決済に関する取引情報の取引ファイルを決済サーバ１００からダウンロードし、ダウンロードした取引ファイルを経理管理システムにアップロードすることにより、経理管理元データとして取込処理を実行できる（ステップＳ２９）。

また、管理者Ｍは、ビジネスアカウントの利用契約を締結した際、サービス提供者との間で取り交わした所定の期日に基づいて、「会社払い」の利用額を後日支払うことにより精算を完了する（ステップＳ３０）。たとえば、管理者Ｍは、提携先の銀行Ｂ－１から、サービス提供者が利用代金の振込先として指定する銀行Ｂ－２の指定口座に対して、「会社払い」の利用額を集計した精算金額を送金する。

なお、上述した情報処理の概要（その２）において、たとえば、「会社払い」の利用を許可した社員Ｅが退職する場合の情報処理については、図１に示す情報処理の概要（その１）の場合と同様である。

（１－３－３．情報処理の概要（その３））
以下、図３を用いて、実施形態に係る情報処理の概要（その３）について説明する。図３は、「会社払い」を実現するためのスキームの１つである「与信利用＋物理券面発行型」の概要を示している。「与信利用＋物理券面発行型」では、管理者Ｍが開設したビジネスアカウントに紐付く決済用口座に管理されている与信枠と、管理者Ｍから社員Ｅに配布される物理カードとを用いた「会社払い」が実現される。

なお、図３に示す情報処理の概要（その３）において、ステップＳ３０～ステップＳ４０の処理については、図２に示すステップＳ２０～ステップＳ３０と同様である。以下では、ステップＳ４１～ステップＳ４７の処理について説明する。

図３に示す情報処理システムＳＹＳ－２は、サービス提供者が提携するカード会社Ｙに設置されているカード会社端末２００や、サービス提供者から電子決済サービスのプラットフォームを用いた決済処理の利用許諾を得ていない非加盟店ＳＨ－２に設置されている店舗端末３０－２を有している。

管理者Ｍは、カード会社Ｙに対して、社員Ｅに利用させるための物理カードの発行を依頼する（ステップＳ４１）。また、管理者Ｍは、カード会社Ｙに対して物理カードの発行依頼を行う際、電子決済サービスのサービス提供者から企業与信により付与された与信枠を、物理カードの利用可能限度額として設定することを要求してもよい。この場合、事業者端末１０は、カード会社端末２００に対して、管理者Ｍが保有するビジネスアカウントに関する情報および利用可能上限額を示す情報とともに、カード発行依頼を送信する。

カード会社端末２００は、事業者端末１０から送信されたカード発行依頼を受信する。カード会社Ｙは、管理者Ｍにより依頼されたカード発行依頼を確認すると、管理者Ｍからの依頼に応じた枚数の物理カードを印刷および発行する（ステップＳ４２－１）。たとえば、カード会社Ｙは、管理者Ｍからの要求に応じて、各社員Ｅに対して、それぞれ１枚ずつの物理カードを発行できる。カード会社Ｙは、発行した物理カードの情報（たとえば、カード番号など）を、管理者Ｍのビジネスアカウントに紐付けて、たとえば、カード情報を管理するために予め用意されたシステム上に記録する。また、カード会社Ｙは、各社員Ｅに対して物理カードを発行した場合、管理者Ｍ（のビジネスアカウント）および各社員Ｅ（のユーザアカウント）に紐付けて、物理カードの情報をシステム上に記録してもよい。これにより、カード会社Ｙが管理するシステム上で、管理者Ｍ（事業者）が雇用する社員Ｅごとに物理カードの利用に関するカード利用明細が個別に記録され、管理される。すなわち、カード会社Ｙにおいて、カード会社Ｙから管理者Ｍ（事業者）に対して物理カードの利用に関する請求があった際に、その請求は実際にはどの社員Ｅが利用したものかが管理される。なお、管理者Ｍが、カード会社Ｙから各社員Ｅごとに発行を受けた物理カードの情報を、自由に各社員Ｅに個別に割り当てて管理してもよい。そして、カード会社Ｙは、発行した物理カードを、管理者Ｍを宛先として郵送する。なお、カード会社端末２００は、物理カードの発送および到着予定日などを通知するためのメッセージを事業者端末１０に送信してもよい。企業Ｘは、カード会社Ｙにより発行された物理カードを受領すると、受領した物理カードを対象となる社員Ｅに対して交付する（ステップＳ４２－２）。

社員Ｅは、勤務先（企業Ｘ）から交付を受けた物理カードを利用して、非加盟店ＳＨ－２において「会社払い」により決済を行う（ステップＳ４３）。非加盟店ＳＨ－２に設置されている店舗端末３０－２は、カード決済情報をカード会社端末２００に送信する。カード会社端末２００は、店舗端末３０－２からカード決済情報を受信すると、カード決済に用いられた物理カードに対応付けられているビジネスアカウントを特定し、特定したビジネスアカウントに対する請求情報を決済サーバ１００に送信する。

決済サーバ１００は、カード会社端末２００から請求情報を受信すると、請求情報に基づいて決済処理を実行する。たとえば、決済サーバ１００は、立替用口座のマネー残高から、請求情報に含まれている決済額（請求金額）に対応する額を、電子決済サービスにおいてカード会社Ｙが保有する口座に移行する立替処理を実行して、カード会社Ｙに対する支払いを完了する（ステップＳ４４－１）。また、決済サーバ１００は、請求情報に含まれているビジネスアカウントに紐付く決済用口座に管理されている与信枠における利用額を更新する（ステップＳ４４－２）。具体的には、決済サーバ１００は、請求情報に含まれている決済額に相当する額を、対象ビジネスアカウントに紐付く与信枠における利用額に加算する。なお、決済サーバ１００は、社員Ｅごとに物理カードの発行を受けた場合、物理カードごとに社員が利用可能な利用可能与信枠を設定してもよい。この場合、決済サーバ１００は、各物理カードに対して設定した利用可能与信枠の合計がビジネスアカウントに紐付く与信枠（企業Ｘの与信枠）を上回ることがないように、各物理カードに設定する利用可能与信枠を制御してもよい。

事業者端末１０は、「会社払い」を利用するための物理カードを用いた決済に関する取引情報を決済サーバ１００から受信すると、受信した取引情報を管理画面上に表示する。管理者Ｍは、管理画面上に表示された取引情報を閲覧することにより、リアルタイムで取引明細を確認できる（ステップＳ４５）。なお、事業者端末１０は、取引明細を表示する際、「会社払い」に利用された物理カードに紐付く社員Ｅの情報（ユーザアカウント）を合わせて表示してもよい。

また、管理者Ｍは、管理画面を操作して、「会社払い」を利用するための物理カードを用いた決済に関する取引情報の取引ファイルを決済サーバ１００からダウンロードし、ダウンロードした取引ファイルを経理管理システムにアップロードすることにより、経理管理元データとして取込処理を実行できる（ステップＳ４６）。

また、管理者Ｍは、ビジネスアカウントの利用契約を締結した際、サービス提供者との間で取り交わした所定の期日に基づいて、「会社払い」を利用するための物理カードの利用額を後日支払うことにより精算を完了する（ステップＳ４７）。たとえば、管理者Ｍは、提携先の銀行Ｂ－１から、サービス提供者が利用代金の振込先として指定する銀行Ｂ－２の指定口座に対して、物理カードの利用額を集計した精算金額を送金する。

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

（通信部１１０について）
通信部１１０は、たとえば、ＮＩＣ（Network Interface Card）などによって実現される。そして、通信部１１０は、ネットワークＮと有線または無線で接続され、事業者端末１０や、利用者端末２０や、店舗端末３０や、カード会社端末２００などとの間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、たとえば、ＲＡＭ（Random Access Memory）やフラッシュメモリ（Flash Memory）などの半導体メモリ素子、または、ハードディスクや光ディスクなどの記憶装置によって実現される。図４に示すように、記憶部１２０は、残高情報記憶部１２１と、与信枠情報記憶部１２２と、利用者情報記憶部１２３と、アカウント情報記憶部１２４と、取引情報記憶部１２５とを有する。

（残高情報記憶部１２１について）
残高情報記憶部１２１は、電子決済サービスにおける各サービス利用者に紐付くマネー残高を管理する第１口座に関する情報を記憶する。たとえば、第１口座は、各サービス利用者に紐付くマネー残高の１つとして、事業者によりチャージされた原資に基づく電子マネーの残高であるマネー残高を管理する。

図５に、実施形態に係る残高情報記憶部１２１に記憶される情報の一例を示す。図５に示すように、残高情報記憶部１２１が記憶する第１口座に関する情報は、「口座ＩＤ」の項目と、「所有者情報」の項目と、「マネー残高」の項目とを有している。第１口座に関する情報が有するこれらの項目は相互に対応付けられている。

「口座ＩＤ」の項目には、サービス利用者の各々が所有する第１口座を特定するための識別情報である口座ＩＤを示す情報が記憶される。「所有者情報」の項目には、第１口座を所有する個人ユーザや事業者などの所有者を特定するための情報を記憶する。たとえば、「所有者情報」の項目には、第１口座の所有者の各々が電子決済サービスにおいて使用するユーザＩＤなど、所有者の各々を識別するための識別情報が記憶される。「マネー残高」の項目には、第１口座のマネー残高を示す情報が記憶される。

たとえば、図５によれば、口座ＩＤ：「ＡＣ＃Ｋ１－１」で特定される第１口座の所有者が「事業者＃００１」で特定される事業者であり、マネー残高が「１，２３４，５６７円」であることが示されている。

（与信枠情報記憶部１２２について）
与信枠情報記憶部１２２は、企業与信により事業者に付与された与信枠を示す情報と、与信枠を用いた利用額を示す情報とを管理する第２口座に関する情報を記憶する。図６に、実施形態に係る与信枠情報記憶部１２２に記憶される第２口座に関する情報の一例を示す。図６に示すように、与信枠情報記憶部１２２に記憶されている第２口座に関する情報は、「口座ＩＤ」の項目と、「所有者情報」の項目と、「利用額｜与信枠」の項目とを有している。第２口座に関する情報が有するこれらの項目は相互に対応付けられている。

「口座ＩＤ」の項目には、事業者の各々が所有する第２口座を特定するための識別情報である口座ＩＤを示す情報が記憶される。「所有者情報」の項目には、第２口座を所有する事業者を識別するための識別情報が記憶される。たとえば、「所有者情報」の項目には、第２口座の所有者の各々が電子決済サービスにおいて使用する事業者ＩＤなど、所有者の各々を識別するための識別情報が記憶される。「利用額｜与信枠」の項目には、事業者に対して付与された与信枠を示す情報と、与信枠における事業者（または事業者により「会社払い」を許可された社員）による利用額を示す情報が記憶される。また、「利用額｜与信枠」の項目に記憶される利用額は、決済ごとに更新（加算）される累計値（累計利用額）である。

たとえば、図６によれば、口座ＩＤ：「ＡＣ＃Ｋ１－２」で特定される第２口座の所有者が「事業者＃００１」で特定される事業者であり、この事業者に付与された与信枠が「１０，０００，０００円」であり、与信枠における利用額が「７，８９４，３２１円」であることが示されている。

（利用者情報記憶部１２３について）
利用者情報記憶部１２３は、「会社払い」の利用を許可する利用者に関する利用者情報を記憶する。図７に、実施形態に係る利用者情報記憶部１２３に記憶される利用者情報の一例を示す。図７に示すように、利用者情報記憶部１２３に記憶される利用者情報は、「事業者ＩＤ」の項目や、「社員番号」の項目や、「氏名」の項目や、「認証用メールアドレス」の項目や、「利用可能上限額」の項目や、「利用可能業種」の項目などといった複数の項目を有する。利用者情報が有するこれらの項目は相互に対応付けられている。

「事業者ＩＤ」項目には、事業者によるビジネスアカウントの開設時に識別情報として設定された事業者ＩＤを示す情報が記憶される。「社員番号」の項目には、「会社払い」が許可される社員に固有に割り振られている社員番号を示す情報が記憶される。「氏名」の項目には、「会社払い」が許可される社員の氏名を示す情報が記憶される。「認証用メールアドレス」の項目には、「会社払い」のアカウント認証時に用いられる案内メールの送信先となるメールアドレスを示す情報が記憶される。「利用可能上限額」の項目には、「会社払い」による利用の上限額が記憶される。「利用可能業種」の項目には、「会社払い」の利用が可能な取引対象の提供元となる店舗や企業などの業種を示す情報が記憶される。なお、利用者情報は、「利用可能業種」の項目の代わりに、「会社払い」を利用が可能な取引対象のカテゴリを示す情報を記憶する項目を有していてもよい。また、利用者情報は、「会社払い」の利用が可能な場所を示す利用可能場所（対象ロケーション情報）を記憶する項目を有していてもよい。たとえば、対象ロケーション情報は、行政区や市区町村などのエリアを特定する情報の他、たとえば、提携先ホテルなどの特定の加盟店の情報などを含み得る。決済サーバ１００は、対象ロケーション情報に基づいて、「会社払い」が利用可能なエリアや、特定の加盟店などを絞り込むことが可能となる。

図７によれば、事業者ＩＤ：「事業者＃００１」で識別される事業者が雇用する社員の一人である「トッキョタロウ（社員番号：社員＃００１－１）」に対応する認証用メールアドレスが「ｔａｒｏ＊＊＊＠ｅｘｍｐｌｅ．ｃｏｍ」であり、利用可能上限額が「５０，０００円」であり、利用可能業種が「交通および飲食」であることが示されている。

（アカウント情報記憶部１２４について）
アカウント情報記憶部１２４は、「会社払い」のアカウント認証に関する情報を記憶する。図８に、実施形態に係るアカウント情報記憶部１２４に記憶されるアカウント認証に関する情報の一例を示す。図８に示すように、アカウント情報記憶部１２４に記憶されるアカウント認証に関する情報は、「ユーザＩＤ」の項目や、「連携事業者ＩＤ」の項目や、「会社払い」の項目などといった複数の項目を有している。アカウント認証に関する情報が有するこれらの項目は相互に対応付けられている。

「ユーザＩＤ」の項目には、電子決済サービスにおいて個人ユーザが使用するユーザＩＤを示す情報が記憶される。たとえば、「ユーザＩＤ」の項目にユーザアカウントとして記憶されるユーザＩＤは、アカウント認証により利用者端末２０から受信される。「連携事業者ＩＤ」の項目には、ユーザアカウントに紐付けられるビジネスアカウントを示す情報が記憶される。「会社払い」の項目には、対象ユーザアカウントに対応する支払手段の１つとして「会社払い」を有効化するか否かを示す情報が記憶される。

図８によれば、ユーザＩＤ：「ユーザ＃００１」で示されるユーザアカウントと、連携事業者が開設したビジネスアカウント：「事業者＃００１」とが連携され、対象ユーザアカウントに対応する支払手段の１つとして「会社払い」が有効化されていることが示されている。

（取引情報記憶部１２５について）
取引情報記憶部１２５は、電子決済サービスを利用して行われた取引情報が記憶される。図９に、実施形態に係る取引情報記憶部１２５に記憶される取引情報の一例を示す。図９に示すように、取引情報記憶部１２５に記憶される取引情報は、「取引番号」の項目や、「支払元」の項目や、「支払先」の項目や、「取引日時」の項目や、「支払金額」の項目や、「取引対象」の項目や、「支払手段」の項目などといった複数の項目を有している。取引情報が有するこれらの項目は相互に対応付けられている。

「取引番号」の項目には、取引ごとに割り振られる番号を示す情報が記憶される。「支払元」の項目には、支払元を識別するための情報が記憶される。「支払先」の項目には、支払先を識別するための情報が記憶される。「取引日時」の項目には、取引日時を示す情報が記憶される。「支払金額」の項目には、支払金額を示す情報が記憶される。「取引対象」の項目には、取引対象または取引対象の業種を示す情報が記憶される。「支払手段」の項目には、支払手段を示す情報が記憶される。

図９によれば、支払元が「ユーザ＃００１」で識別される個人ユーザであり、支払先が「加盟店＃１１２」で識別される加盟店であり、取引日時が「２０２２年１０月２０日 ０９：００」であり、支払金額：「２，０００円」であり、取引対象の業種が「タクシー」であり、支払手段が「会社払い」である取引情報が示されている。

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

（受付部１３１について）
受付部１３１は、通信部１１０を通じて、電子決済サービスにおいてビジネスアカウントを保有する事業者が利用する事業者端末１０から送信された利用者情報を受け付ける。たとえば、受付部１３１は、後述する提供部１３５により提供される管理画面を通じて事業者により登録された利用者情報を受け付ける。受付部１３１が受け付ける利用者情報は、ビジネスアカウントに紐付く決済用口座であって記憶部１２０に記憶されている決済用口座に管理されている資金に基づいて、取引対象の代金の支払いを行う所定の支払手段である「会社払い」の利用が許可されるサービス利用者に関する情報である。「会社払い」の利用が許可される利用者の典型例としては、電子決済サービスのサービス利用者（個人ユーザ）であって、ビジネスアカウントを保有する事業者と雇用関係などの所定の関係にある利用者が想定される。

（送信部１３２について）
送信部１３２は、ビジネスアカウントと、サービス利用者が電子決済サービスにおいて保有するユーザアカウントとを連携させるための認証用情報を、サービス利用者が利用する利用者端末２０に送信する。

たとえば、送信部１３２は、管理画面を通じて受付部１３１が受け付けた利用者情報に含まれる認証用メールアドレスを宛先とし、ビジネスアカウントとユーザアカウントとを紐付けるための所定のリンクを含む電子メールを認証用情報として利用者端末２０に送信できる。また、たとえば、送信部１３２は、有効期限が設定された所定のリンクを含む電子メールを利用者端末２０に送信できる。

また、送信部１３２は、提携先のカード会社に設置されているカード会社端末２００に対し、ビジネスアカウントを保有する事業者からの要求に応じて、ビジネスアカウントに紐付く物理カードの発行依頼を送信する。また、送信部１３２は、企業与信により事業者に付与された与信枠を利用可能上限額とする物理カードの発行依頼を送信できる。

また、送信部１３２は、ビジネスアカウントを保有する事業者からの要求に、事業者が雇用する社員Ｅのユーザアカウントが含まれる場合、ビジネスアカウントおよびユーザアカウントに紐付く物理カードの発行依頼を送信できる。

（登録部１３３について）
登録部１３３は、認証用情報に対する利用者の操作に応じて利用者端末２０から受信したユーザアカウントを示す情報と、ビジネスアカウントとを紐付けて記憶部１２０に登録する。また、登録部１３３は、対象ユーザアカウントの「会社払い」を有効化する。

（決済処理部１３４について）
決済処理部１３４は、サービス利用者の決済に関する取引情報において「会社払い」が選択されている場合、決済用口座に管理されている資金に基づいて、取引情報に含まれる支払先に紐付く支払先口座であって記憶部１２０に記憶されている支払先口座に対して、取引情報に含まれる決済額に相当する額を移行させる処理を実行する。

たとえば、決済処理部１３４は、第１口座において管理されるマネー残高から、支払先口座に対して、決済額に相当する額を移行させる。また、たとえば、決済処理部１３４は、取引情報の受信に応じて、記憶部１２０に記憶されている立替用口座から支払先口座に対して、決済額に相当する額を移行させる立替処理を実行するとともに、第２口座において管理される利用額を更新する。

また、決済処理部１３４は、提携先のカード会社（たとえば、図３に示すカード会社Ｙ）から、物理カードを用いた決済に関する請求情報を受信した場合、記憶部１２０に記憶されている立替用口座に管理されている資金から、電子決済サービスにおいてカード会社が保有する口座であって記憶部１２０に記憶されている口座に対して、請求情報に含まれる決済額に相当する額を移行させる立替処理を実行する。また、決済処理部１３４は、立替処理を行った決済額に基づいて、事業者の決済用口座である第２口座に管理されているビジネスアカウントに紐付く利用額を更新する。

（提供部１３５について）
提供部１３５は、事業者用アカウントにより利用可能なユーザインターフェイスであって、「会社払い」に関する各種操作を実行可能な事業者用の管理画面を提供する。

また、提供部１３５は、管理画面を通じて、「会社払い」を用いた取引明細に関する情報を事業者に提供できる。また、提供部１３５は、電子決済サービスを利用するためにサービス利用者に配布されるユーザアプリを通じて、サービス利用者が「会社払い」を利用して支払いを行うことが可能な額を示す利用可能枠に関する情報を提供できる。

また、制御部１３０は、上述した各部に加えて、物理カードごとに請求情報を管理する管理部を有していてもよい。管理部は、事業者がカード会社から社員ごとに物理カードの発行を受けた場合（提携先のカード会社に対して、ビジネスアカウントおよびユーザアカウントに紐付く物理カードの発行を依頼した場合）、物理カードに紐付く社員のユーザアカウントごとに、カード会社Ｙから取得される請求情報を管理する。たとえば、管理部は、請求情報に含まれるユーザアカウントごとに請求情報を抽出し、抽出した請求情報をユーザアカウントごとに対応付けて管理する。また、管理部は、事業者がカード会社から社員ごとに物理カードの発行を受けた場合、物理カードごとに社員が利用可能な利用可能与信枠を設定してもよい。この場合、管理部は、各物理カードに対して設定した利用可能与信枠の合計がビジネスアカウントに紐付く与信枠（たとえば、事業者が保有する与信枠）を上回ることがないように、各物理カードに設定する利用可能与信枠を制御してもよい。また、上述の提供部１３５は、「会社払い」を用いた取引明細に関する情報を事業者に提供する際、「会社払い」に利用された物理カードに紐付く社員Ｅの情報（ユーザアカウント）を合わせて表示することにより、事業者に提供してもよい。

〔３．処理手順例〕
（３－１．利用登録処理）
以下、実施形態に係る決済サーバ１００における処理手順の一例を説明する。まず、決済サーバ１００が実行する利用登録処理の処理手順について説明する。図１０に、実施形態に係る決済サーバ１００により実行される利用登録処理の処理手順の一例を示すフローチャートである。

図１０に示すように、受付部１３１は、ビジネスアカウントを保有する事業者が利用する事業者端末２０から、ビジネスアカウントに紐付く決済用口座であって記憶部１２０に記憶されている決済用口座に管理されている資金に基づいて取引対象の代金の支払いを行う「会社払い」の利用が許可されるサービス利用者に関する利用者情報を受け付ける（ステップＳ１０１）。

送信部１３２は、利用者情報に含まれる認証用メールアドレスを宛先として、ビジネスアカウントと、サービス利用者が電子決済サービスにおいて保有するユーザアカウントとを連携させるための会社払い利用案内メールを、サービス利用者が利用する利用者端末２０に送信する（ステップＳ１０２）。

登録部１３３は、会社払い利用案内メールに対する利用者の操作に応じて利用者端末２０から受信したユーザアカウントと、ビジネスアカウントとを連携する（ステップＳ１０３）。具体的には、登録部１３３は、利用者端末２０から受信したユーザアカウントを示す情報と、利用者情報の送信元であるビジネスアカウントを示す情報とを紐付けて記憶部１２０（アカウント情報記憶部１２４）に登録する。

また、登録部１３３は、対象ユーザアカウントに対応付けて、「会社払い」が有効であることを示す情報を記憶部１２０に格納することにより、対象ユーザアカウントの「会社払い」を有効化する（ステップＳ１０４）。

そして、登録部１３３は、たとえば、利用者情報に含まれる認証用メールアドレスを宛先として、利用者端末２０に手続完了メールを送信することにより、利用者に対して、「会社払い」の利用手続きが完了した旨を通知して（ステップＳ１０５）、図１０に示す処理手順を終了する。

（３－２．決済処理（その１））
以下、決済サーバ１００が実行する決済処理（その１）の処理手順について説明する。図１１に、実施形態に係る決済サーバ１００により実行される決済処理（その１）の処理手順の一例を示す。

図１１に示すように、決済処理部１３４は、通信部１１０を通じて、たとえば、利用者端末２０や店舗端末３０から送信されたサービス利用者の決済に関する取引情報を取得する（ステップＳ２０１）。

また、決済処理部１３４は、取引情報において「会社払い」が選択されているか否かを判定する（ステップＳ２０２）。

また、決済処理部１３４は、取引情報において「会社払い」が選択されていると判定した場合（ステップＳ２０２；Ｙｅｓ）、取引情報に含まれている支払元のユーザアカウントに紐付く累計利用額が利用可能上限額以下であるか否かを判定する（ステップＳ２０３）。

また、決済処理部１３４は、支払元のユーザアカウントに紐付く累計利用額が利用可能上限額以下であると判定した場合（ステップＳ２０３；Ｙｅｓ）、取引情報に含まれている取引対象の提供元に対応する業種が利用可能業種に対応しているか否かを判定する。

また、決済処理部１３４は、取引情報に含まれている取引対象の提供元に対応する業種が利用可能業種であると判定した場合（ステップＳ２０４；Ｙｅｓ）、「会社払い」により即時決済を行って（ステップＳ２０５）、図１１に示す処理手順を終了する。

一方、決済処理部１３４は、取引情報に含まれている取引対象の提供元に対応する業種が利用可能業種ではないと判定した場合（ステップＳ２０４；Ｎｏ）、「会社払い」を利用できない旨を、取引情報の送信元に通知して（ステップＳ２０５）、図１１に示す処理手順を終了する。

上述のステップＳ２０３において、決済処理部１３４は、支払元のユーザアカウントに紐付く累計利用額が利用可能上限額を超えていると判定した場合（ステップＳ２０３；Ｎｏ）、上述のステップＳ２０５の処理手順に移る。

上述のステップＳ２０２において、決済処理部１３４は、取引情報において「会社払い」が選択されていないと判定した場合（ステップＳ２０２；Ｎｏ）、「会社払い」以外の他の支払手段により即時決済を行って（ステップＳ２０６）、図１１に示す処理手順を終了する。

（３－３．決済処理（その２））
以下、決済サーバ１００が実行する決済処理（その２）の処理手順について説明する。図１２に、実施形態に係る決済サーバ１００により実行される決済処理（その２）の処理手順の一例を示す。

図１２に示すように、決済処理部１３４は、通信部１１０を通じて、提携カード会社から請求情報を受信すると（ステップＳ３０１）、立替用口座のマネー残高から、提携カード会社の口座に対して、請求金額に相当する額を移行して（ステップＳ３０２）、立替処理を実行する。

また、決済処理部１３４は、請求情報に含まれているビジネスアカウントに紐付く決済用口座に管理されている与信枠における利用額を更新して（ステップＳ３０２）、図１２に示す処理手順を終了する。

〔４．変形例〕
（４－１．複数の利用可能枠の提供について）
上述の実施形態において、管理者Ｍは、「会社払い」の利用を許可する社員Ｅに対して、複数の利用可能枠を提供してもよい。この場合、管理者Ｍは、社員Ｅに対して提供する利用可能枠ごとに、利用可能上限額を設定してもよいし、利用可能枠の各々に対応する金額を合計した利用可能条件額を設定してもよい。また、管理者Ｍは、「会社払い」の利用を許可する社員Ｅに対して、マネー残高に基づく利用可能枠と、与信枠に基づく利用可能枠とを個別に設定してもよい。この場合、決済サーバ１００の登録部１３３は、対象ユーザアカウントに対応付けて、マネー残高に基づく利用可能枠と、与信枠に基づく利用可能枠とを個別に記憶部１２０（アカウント情報記憶部１２４）に登録する。また、社員Ｅが副業勤務者である場合、社員Ｅに対応する（社員Ｅが保有する）ユーザアカウントに紐付けて、各勤務先の事業者ごとに「会社払い」の利用可能枠を有していてもよい。

（４－２．報酬の付与について）
上述の実施形態において、決済サーバ１００は、たとえば、社員Ｅが、支払手段として「会社払い」を用いてコード決済を行った場合のポイントなどの報酬を、「会社払い」を提供するビジネスアカウントに対して付与してもよい。

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

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

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

〔５．効果〕
上述してきたように、実施形態に係る決済サーバ１００は、記憶部１２０と、送信部１３２と、決済処理部１３４とを有する。記憶部１２０は、電子決済サービスのサービス利用者の各々に紐付く口座に関する情報を記憶する。送信部１３２は、提携先のカード会社に設置されているカード会社端末２００に対して、電子決済サービスにおいて事業者用アカウントを保有する事業者からの要求に応じて、事業者用アカウントに紐付く物理カードの発行依頼を送信する。決済処理部１３４は、カード会社から、物理カードを用いた決済に関する請求情報を受信した場合、記憶部１２０に記憶されている立替用口座に管理されている資金から、電子決済サービスにおいてカード会社が保有する口座であって記憶部１２０に記憶されている口座に対して、請求情報に含まれる決済額に相当する額を移行させる立替処理を実行する。

また、記憶部１２０は、事業者用アカウントに紐付く口座であって、企業与信により事業者に付与された与信枠を示す情報と、与信枠を用いた利用額を示す情報とを管理する決済用口座に関する情報を記憶してもよい。送信部１３２は、与信枠を利用可能上限額とする物理カードの発行依頼を送信してもよい。決済処理部１３４は、立替処理を行った決済額に基づいて、決済用口座に管理されている事業者用アカウントに紐付く利用額を更新してもよい。

また、送信部１３２は、事業者からの要求に事業者が雇用する社員のユーザアカウントが含まれる場合、事業者用アカウントおよびユーザアカウントに紐付く物理カードの発行依頼を送信してもよい。

また、決済サーバ１００は、物理カードに紐付くユーザアカウントごとに、請求情報を管理する管理部を有してもよい。

また、管理部は、物理カードごとに利用可能与信枠を設定してもよい。

また、管理部は、与信枠の範囲内で、利用可能与信枠を設定してもよい。

また、決済サーバ１００は、事業者用アカウントにより利用可能なユーザインターフェイスである事業者用の管理画面を通じて、物理カードを用いた決済に関する取引情報を事業者に提供する提供部１３５をさらに有する。

また、提供部１３５は、取引情報を事業者に提供する際、事業者が雇用する社員の情報であって、物理カードに紐付くユーザアカウントの情報を提供してもよい。

このようなことから、実施形態に係る決済サーバ１００は、上述した各部により実行される処理、又は各部のうちのいずれかの組合せにより、端末装置を用いた決済を実現するための既存のプラットフォームを用いた決済スキームの援用を図ることができる。たとえば、決済先が電子決済サービスの加盟店ではない場合であっても、電子決済サービスの既存のプラットフォームを用いた決済スキームの少なくとも一部を援用して、「会社払い」に対応する決済処理を実現できる。

〔６．ハードウェア構成〕
また、上述してきた実施形態に係る決済サーバ１００は、たとえば、図１３に示すような構成のコンピュータ１０００によって実現される。図１３は、実施形態に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力ＩＦ（Interface）１０６０、入力ＩＦ１０７０、ネットワークＩＦ１０８０がバス１０９０により接続された形態を有する。

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラムなどに基づいて動作し、各種の処理を実行する。一次記憶装置１０４０は、ＲＡＭなど、演算装置１０３０が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory)、ＨＤＤ、フラッシュメモリ等により実現される。

出力ＩＦ１０６０は、モニタやプリンタといった各種の情報を出力する出力装置１０１０に対し、出力対象となる情報を送信するためのインターフェイスであり、たとえば、ＵＳＢ（Universal Serial Bus）やＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）といった規格のコネクタにより実現される。また、入力ＩＦ１０７０は、マウス、キーボード、およびスキャナなどといった各種の入力装置１０２０から情報を受信するためのインターフェイスであり、たとえば、ＵＳＢなどにより実現される。

なお、入力装置１０２０は、たとえば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）などの光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリなどから情報を読み出す装置であってもよい。また、入力装置１０２０は、ＵＳＢメモリなどの外付け記憶媒体であってもよい。

ネットワークＩＦ１０８０は、ネットワークＮを介して他の機器からデータを受信して演算装置１０３０へ送り、また、ネットワークＮを介して演算装置１０３０が生成したデータを他の機器へ送信する。

演算装置１０３０は、出力ＩＦ１０６０や入力ＩＦ１０７０を介して、出力装置１０１０や入力装置１０２０の制御を行う。たとえば、演算装置１０３０は、入力装置１０２０や二次記憶装置１０５０からプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行する。

たとえば、コンピュータ１０００が実施形態に係る情報処理装置の一例である決済サーバ１００として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）を実行することにより、制御部１３０と同様の機能を実現する。すなわち、演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）との協働により、実施形態に係る決済サーバ１００による処理を実現する。

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

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

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

ＳＹＳ－１、ＳＹＳ－２ 情報処理システム
１０ 事業者端末
２０ 利用者端末
３０ 店舗端末
１００ 決済サーバ
１１０ 通信部
１２０ 記憶部
１２１ 残高情報記憶部
１２２ 与信枠情報記憶部
１２３ 利用者情報記憶部
１２４ アカウント情報記憶部
１２５ 取引情報記憶部
１３０ 制御部
１３１ 受付部
１３２ 送信部
１３３ 登録部
１３４ 決済処理部
１３５ 提供部

本願に係る情報処理装置は、記憶部と、決済処理部とを有する。記憶部は、電子決済サービスのサービス利用者である事業者が前記電子決済サービスにおいて保有する事業者用アカウントに紐付く口座であって、企業与信により前記事業者に付与された与信枠を用いた利用額を示す情報を管理する決済用口座に関する情報を記憶する。決済処理部は、提携先のカード会社から、事業者用アカウントに紐付く物理カードを用いた請求情報を受信した場合、受信した請求情報に基づいて、決済用口座において管理されている利用額を更新し、事業者と所定の関係にある前記サービス利用者が前記電子決済サービスにおいて保有するユーザアカウントであって、事業者用アカウントに紐付くユーザアカウントによる取引情報を受信した場合、取引情報に含まれる決済額に基づいて決済用口座において管理されている利用額を更新する。

Claims (10)

1. 電子決済サービスのサービス利用者の各々に紐付く口座に関する情報を記憶する記憶部と、
   提携先のカード会社に設置されている端末装置に対し、前記電子決済サービスにおいて事業者用アカウントを保有する事業者からの要求に応じて、前記事業者用アカウントに紐付く物理カードの発行依頼を送信する送信部と、
   前記カード会社から、前記物理カードを用いた決済に関する請求情報を受信した場合、前記記憶部に記憶されている立替用口座に管理されている資金から、前記電子決済サービスにおいて前記カード会社が保有する口座であって前記記憶部に記憶されている前記口座に対して、前記請求情報に含まれる決済額に相当する額を移行させる立替処理を実行する決済処理部と
   を有することを特徴とする情報処理装置。
2. 前記記憶部は、
   前記事業者用アカウントに紐付く口座であって、企業与信により前記事業者に付与された与信枠を示す情報と、前記与信枠を用いた利用額を示す情報とを管理する決済用口座に関する情報を記憶し、
   前記送信部は、
   前記与信枠を利用可能上限額とする前記物理カードの発行依頼を送信し、
   前記決済処理部は、
   前記立替処理を行った前記決済額に基づいて、前記決済用口座に管理されている前記事業者用アカウントに紐付く前記利用額を更新する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記送信部は、
   前記事業者からの要求に前記事業者が雇用する社員のユーザアカウントが含まれる場合、前記事業者用アカウントおよび前記ユーザアカウントに紐付く物理カードの発行依頼を送信する
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記物理カードに紐付く前記ユーザアカウントごとに、前記請求情報を管理する管理部
   をさらに有することを特徴とする請求項３に記載の情報処理装置。
5. 前記管理部は、
   前記物理カードごとに利用可能与信枠を設定する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記管理部は、
   前記与信枠の範囲内で、前記利用可能与信枠を設定する
   ことを特徴とする請求項５に記載の情報処理装置。
7. 前記事業者用アカウントにより利用可能なユーザインターフェイスである前記事業者用の管理画面を通じて、前記物理カードを用いた決済に関する取引情報を前記事業者に提供する提供部
   をさらに有することを特徴とする請求項１に記載の情報処理装置。
8. 前記提供部は、
   前記取引情報を前記事業者に提供する際、前記事業者が雇用する社員の情報であって、前記物理カードに紐付くユーザアカウントの情報を提供する
   ことを特徴とする請求項７に記載の情報処理装置。
9. 電子決済サービスのサービス利用者の各々に紐付く口座に関する情報を記憶する記憶部を有するコンピュータが、
   提携先のカード会社に設置されている端末装置に対し、前記電子決済サービスにおいて事業者用アカウントを保有する事業者からの要求に応じて、前記事業者用アカウントに紐付く物理カードの発行依頼を送信する送信工程と、
   前記カード会社から、前記物理カードを用いた決済に関する請求情報を受信した場合、前記記憶部に記憶されている立替用口座に管理されている資金から、前記電子決済サービスにおいて前記カード会社が保有する口座であって前記記憶部に記憶されている前記口座に対して、前記請求情報に含まれる決済額に相当する額を移行させる立替処理を実行する決済処理工程と、
   を実行することを特徴とする情報処理方法。
10. 電子決済サービスのサービス利用者の各々に紐付く口座に関する情報を記憶する記憶部を有するコンピュータに、
    提携先のカード会社に設置されている端末装置に対し、前記電子決済サービスにおいて事業者用アカウントを保有する事業者からの要求に応じて、前記事業者用アカウントに紐付く物理カードの発行依頼を送信する送信手順と、
    前記カード会社から、前記物理カードを用いた決済に関する請求情報を受信した場合、前記記憶部に記憶されている立替用口座に管理されている資金から、前記電子決済サービスにおいて前記カード会社が保有する口座であって前記記憶部に記憶されている前記口座に対して、前記請求情報に含まれる決済額に相当する額を移行させる立替処理を実行する決済処理手順と、
    を実行させることを特徴とする情報処理プログラム。

Images