ホーム > 特許ランキング > ＰａｙＰａｙ株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024144006
(43)【公開日】2024-10-11
(54)【発明の名称】情報処理装置、情報処理方法及び情報処理プログラム
(51)【国際特許分類】
G06Q 20/36 20120101AFI20241003BHJP
G06Q 20/06 20120101ALI20241003BHJP
【ＦＩ】
G06Q20/36
G06Q20/06 300
【審査請求】未請求
【請求項の数】13
【出願形態】ＯＬ
(21)【出願番号】P 2023146982
(22)【出願日】2023-09-11
(62)【分割の表示】P 2023051194の分割
【原出願日】2023-03-28
(71)【出願人】
【識別番号】519110124
【氏名又は名称】ＰａｙＰａｙ株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】柳瀬 将良
(72)【発明者】
【氏名】大塚 千壽子
【テーマコード（参考）】
5L020
5L055
【Ｆターム（参考）】
5L020AA11
5L020AA68
5L055AA11
5L055AA68
(57)【要約】
【課題】加盟店からの要求に応じた決済処理を円滑に実行すること。
【解決手段】本願に係る情報処理装置は、決済情報記憶部と、チャージ部と、実行部とを有する。チャージ部は、利用者に割り当てられる仮想口座を電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、仮想口座への入金通知を受信した場合、仮想口座に入金された入金額に相当する額の電子マネーを、入金通知により着金が検知された仮想口座に対応付けられている電子ウォレットであって、利用者が保有する利用者ウォレットにチャージする。実行部は、入金通知を受信した場合、決済要求記憶部を参照して、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、決済要求を受付済みであるか否かを判定し、決済要求を受付済みであると判定した場合、決済要求に基づく決済処理を実行する。
【選択図】図４
【解決手段】本願に係る情報処理装置は、決済情報記憶部と、チャージ部と、実行部とを有する。チャージ部は、利用者に割り当てられる仮想口座を電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、仮想口座への入金通知を受信した場合、仮想口座に入金された入金額に相当する額の電子マネーを、入金通知により着金が検知された仮想口座に対応付けられている電子ウォレットであって、利用者が保有する利用者ウォレットにチャージする。実行部は、入金通知を受信した場合、決済要求記憶部を参照して、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、決済要求を受付済みであるか否かを判定し、決済要求を受付済みであると判定した場合、決済要求に基づく決済処理を実行する。
【選択図】図４
【特許請求の範囲】
【請求項1】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行する情報処理装置であって、
前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部と、
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記仮想口座に入金された入金額に相当する額の電子マネーを、前記入金通知により着金が検知された前記仮想口座に対応付けられている電子ウォレットであって、前記利用者が保有する利用者ウォレットにチャージするチャージ部と、
前記入金通知を受信した場合、前記決済要求記憶部を参照して、前記着金が検知された前記仮想口座に対応付けられている前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行部と
を有することを特徴とする情報処理装置。
前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部と、
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記仮想口座に入金された入金額に相当する額の電子マネーを、前記入金通知により着金が検知された前記仮想口座に対応付けられている電子ウォレットであって、前記利用者が保有する利用者ウォレットにチャージするチャージ部と、
前記入金通知を受信した場合、前記決済要求記憶部を参照して、前記着金が検知された前記仮想口座に対応付けられている前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行部と
を有することを特徴とする情報処理装置。
【請求項2】
前記実行部は、
前記対象利用者について複数の前記決済要求がある場合、前記対象利用者により予め設定される優先順位に従って、前記決済処理を実行する
ことを特徴とする請求項１に記載の情報処理装置。
前記対象利用者について複数の前記決済要求がある場合、前記対象利用者により予め設定される優先順位に従って、前記決済処理を実行する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項3】
前記実行部は、
前記対象利用者について前記決済要求に基づく前記決済処理を実行する際、前記決済要求に含まれる請求金額を参照し、前記対象利用者が保有する利用者ウォレットのマネー残高が前記請求金額に満たない場合、前記対象利用者に対して残高不足である旨を通知し、前記対象利用者が保有する利用者ウォレットの残高不足が解消されたことを契機として、前記決済要求に基づく前記決済処理を実行する
ことを特徴とする請求項１に記載の情報処理装置。
前記対象利用者について前記決済要求に基づく前記決済処理を実行する際、前記決済要求に含まれる請求金額を参照し、前記対象利用者が保有する利用者ウォレットのマネー残高が前記請求金額に満たない場合、前記対象利用者に対して残高不足である旨を通知し、前記対象利用者が保有する利用者ウォレットの残高不足が解消されたことを契機として、前記決済要求に基づく前記決済処理を実行する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項4】
前記実行部は、
前記利用者からの要求に応じて、前記利用者について受付済みの前記決済要求に関する情報を提供する
ことを特徴とする請求項１に記載の情報処理装置。
前記利用者からの要求に応じて、前記利用者について受付済みの前記決済要求に関する情報を提供する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項5】
前記実行部は、
前記加盟店から受付済みの前記決済要求に、前記着金のタイミングに連動して即時の決済を要求することを示すフラグ情報が含まれている場合、前記決済処理の完了に応じて、前記着金のタイミングに連動して決済が行われた旨の通知を前記対象利用者に通知する
ことを特徴とする請求項１に記載の情報処理装置。
前記加盟店から受付済みの前記決済要求に、前記着金のタイミングに連動して即時の決済を要求することを示すフラグ情報が含まれている場合、前記決済処理の完了に応じて、前記着金のタイミングに連動して決済が行われた旨の通知を前記対象利用者に通知する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項6】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行する情報処理装置であって、
前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部と、
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記決済要求記憶部を参照し、前記入金通知により着金が検知された前記仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行部と
を有することを特徴とする情報処理装置。
前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部と、
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記決済要求記憶部を参照し、前記入金通知により着金が検知された前記仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行部と
を有することを特徴とする情報処理装置。
【請求項7】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行するコンピュータが実行する情報処理方法であって、
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記仮想口座に入金された入金額に相当する額の電子マネーを、前記入金通知により着金が検知された前記仮想口座に対応付けられている電子ウォレットであって、前記利用者が保有する利用者ウォレットにチャージするチャージ工程と、
前記入金通知を受信した場合、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照して、前記着金が検知された前記仮想口座に対応付けられている前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行工程と
を含むことを特徴とする情報処理方法。
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記仮想口座に入金された入金額に相当する額の電子マネーを、前記入金通知により着金が検知された前記仮想口座に対応付けられている電子ウォレットであって、前記利用者が保有する利用者ウォレットにチャージするチャージ工程と、
前記入金通知を受信した場合、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照して、前記着金が検知された前記仮想口座に対応付けられている前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行工程と
を含むことを特徴とする情報処理方法。
【請求項8】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行するコンピュータに、
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記仮想口座に入金された入金額に相当する額の電子マネーを、前記入金通知により着金が検知された前記仮想口座に対応付けられている電子ウォレットであって、前記利用者が保有する利用者ウォレットにチャージするチャージ手順と、
前記入金通知を受信した場合、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照して、前記着金が検知された前記仮想口座に対応付けられている前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行手順と
を実行させることを特徴とする情報処理プログラム。
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記仮想口座に入金された入金額に相当する額の電子マネーを、前記入金通知により着金が検知された前記仮想口座に対応付けられている電子ウォレットであって、前記利用者が保有する利用者ウォレットにチャージするチャージ手順と、
前記入金通知を受信した場合、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照して、前記着金が検知された前記仮想口座に対応付けられている前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行手順と
を実行させることを特徴とする情報処理プログラム。
【請求項9】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行するコンピュータが実行する情報処理方法であって、
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照し、前記入金通知により着金が検知された前記仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行工程
を含むことを特徴とする情報処理方法。
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照し、前記入金通知により着金が検知された前記仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行工程
を含むことを特徴とする情報処理方法。
【請求項10】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行するコンピュータに、
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照し、前記入金通知により着金が検知された前記仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行手順
を実行させることを特徴とする情報処理プログラム。
前記利用者に割り当てられる仮想口座を前記電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、前記仮想口座への入金通知を受信した場合、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照し、前記入金通知により着金が検知された前記仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行手順
を実行させることを特徴とする情報処理プログラム。
【請求項11】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行する情報処理装置であって、
前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部と、
前記利用者に対して給与を支払う法人の法人アカウントに紐付く電子ウォレットから、前記利用者が保有する電子ウォレットである利用者ウォレットに対して、前記法人からの要求に応じて、前記給与に相当する額の電子マネーをチャージするチャージ処理を実行するチャージ部と、
前記チャージ処理の完了に応じて前記決済要求記憶部を参照し、前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行部と
を有することを特徴とする情報処理装置。
前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部と、
前記利用者に対して給与を支払う法人の法人アカウントに紐付く電子ウォレットから、前記利用者が保有する電子ウォレットである利用者ウォレットに対して、前記法人からの要求に応じて、前記給与に相当する額の電子マネーをチャージするチャージ処理を実行するチャージ部と、
前記チャージ処理の完了に応じて前記決済要求記憶部を参照し、前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行部と
を有することを特徴とする情報処理装置。
【請求項12】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行するコンピュータが実行する情報処理方法であって、
前記利用者に対して給与を支払う法人の法人アカウントに紐付く電子ウォレットから、前記利用者が保有する電子ウォレットである利用者ウォレットに対して、前記法人からの要求に応じて、前記給与に相当する額の電子マネーをチャージするチャージ処理を実行するチャージ工程と、
前記チャージ処理の完了に応じて、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照し、前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行工程と
を含むことを特徴とする情報処理方法。
前記利用者に対して給与を支払う法人の法人アカウントに紐付く電子ウォレットから、前記利用者が保有する電子ウォレットである利用者ウォレットに対して、前記法人からの要求に応じて、前記給与に相当する額の電子マネーをチャージするチャージ処理を実行するチャージ工程と、
前記チャージ処理の完了に応じて、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照し、前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行工程と
を含むことを特徴とする情報処理方法。
【請求項13】
オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行するコンピュータに、
前記利用者に対して給与を支払う法人の法人アカウントに紐付く電子ウォレットから、前記利用者が保有する電子ウォレットである利用者ウォレットに対して、前記法人からの要求に応じて、前記給与に相当する額の電子マネーをチャージするチャージ処理を実行するチャージ手順と、
前記チャージ処理の完了に応じて、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照し、前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行手順と
を実行させることを特徴とする情報処理プログラム。
前記利用者に対して給与を支払う法人の法人アカウントに紐付く電子ウォレットから、前記利用者が保有する電子ウォレットである利用者ウォレットに対して、前記法人からの要求に応じて、前記給与に相当する額の電子マネーをチャージするチャージ処理を実行するチャージ手順と、
前記チャージ処理の完了に応じて、前記利用者が会員として取引対象の提供を受ける前記電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する決済要求記憶部を参照し、前記利用者ウォレットを保有する対象利用者について、前記決済要求を受付済みであるか否かを判定し、前記決済要求を受付済みであると判定した場合、前記決済要求に基づく決済処理を実行する実行手順と
を実行させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。
【背景技術】
【0002】
昨今、政府では、資金移動業を営む資金移動業者に対し、上述の電子マネーや仮想通貨といったデジタルマネーにより給与の支払いを認める、所謂「給与のデジタル払い」の導入が検討され始めている。これに関連して、給与のデジタル払いに関連した技術も提案されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０２２－１５１８７３号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記の従来技術では、給与のデジタル払いに関連する電子決済サービスにおいて、加盟店からの要求に応じた決済処理を円滑に実行する上で改善の余地がある。たとえば、現状では、電子決済サービスの利用者が加盟店から提供を受ける取引対象の代金の支払いを電子決済により実行する場合、加盟店からの決済要求がなければ、決済処理が行われることはない。
【0005】
本願は、上記に鑑みてなされたものであって、給与のデジタル払いに関連する電子決済サービスにおいて、加盟店からの要求に応じた決済処理を円滑に実行することができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【0006】
本願に係る情報処理装置は、オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行する情報処理装置であって、決済情報記憶部と、チャージ部と、実行部とを有する。決済情報記憶部は、利用者が会員として取引対象の提供を受ける電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する。チャージ部は、利用者に割り当てられる仮想口座を電子決済サービスを運営するサービス事業者に貸し渡す銀行により運営及び管理される連携銀行サーバから、仮想口座への入金通知を受信した場合、仮想口座に入金された入金額に相当する額の電子マネーを、入金通知により着金が検知された仮想口座に対応付けられている電子ウォレットであって、利用者が保有する利用者ウォレットにチャージする。実行部は、入金通知を受信した場合、決済要求記憶部を参照して、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、決済要求を受付済みであるか否かを判定し、決済要求を受付済みであると判定した場合、決済要求に基づく決済処理を実行する。
【発明の効果】
【0007】
実施形態の一態様によれば、加盟店からの要求に応じた決済処理を円滑に実行することができるという効果を奏する。
【図面の簡単な説明】
【0008】
【発明を実施するための形態】
【0009】
以下に本願に係る情報処理装置、情報処理方法及び情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法及び情報処理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
【0010】
〔１．実施形態〕
図１を用いて、実施形態に係る情報処理装置などにより実現される情報処理について説明する。図１は、実施形態に係る情報処理の概要を示す図である。なお、図１では、実施形態に係る情報処理装置の一例である決済サーバ１００によって、実施形態に係る情報処理などが実現されるものとする。
図１を用いて、実施形態に係る情報処理装置などにより実現される情報処理について説明する。図１は、実施形態に係る情報処理の概要を示す図である。なお、図１では、実施形態に係る情報処理装置の一例である決済サーバ１００によって、実施形態に係る情報処理などが実現されるものとする。
【0011】
（１－１．実施形態に係る決済サービスに対応する情報処理（その１）の全体像）
以下、実施形態に係る決済サービスに対応する情報処理（その１）の全体像について説明する。図１は、実施形態に係る決済サービスに対応する情報処理（その１）の全体像を概略的に示す図である。以下の説明において、実施形態に係る決済サービスは、電子決済サービスに内包されるサービスの１つとして利用者Ｕおよび加盟店Ｚに提供されるサービスであり、利用者Ｕの給与の着金（つまり給与に対応する額の電子マネーの電子ウォレットに対するチャージ処理の完了）に連動して利用者ウォレットから代金の支払いを実現するためのサービスである。
以下、実施形態に係る決済サービスに対応する情報処理（その１）の全体像について説明する。図１は、実施形態に係る決済サービスに対応する情報処理（その１）の全体像を概略的に示す図である。以下の説明において、実施形態に係る決済サービスは、電子決済サービスに内包されるサービスの１つとして利用者Ｕおよび加盟店Ｚに提供されるサービスであり、利用者Ｕの給与の着金（つまり給与に対応する額の電子マネーの電子ウォレットに対するチャージ処理の完了）に連動して利用者ウォレットから代金の支払いを実現するためのサービスである。
【0012】
以下、実施形態に係る決済サービスは、振込サービスを利用して、電子決済サービスの利用者Ｕが給与を電子マネーで受け取ることを前提とする。また、実施形態に係る決済サービスは、利用者Ｕが、加盟店Ｚから提供される取引対象の代金を支払うための支払手段として電子決済サービスを用いた電子決済を利用することを前提とする。このような前提の元、実施形態に係る決済サービスは、加盟店Ｚが顧客である会員に対して請求する取引対象の代金を、会員と加盟店Ｚとの間で会員の給与振り込み時に決済することを事前に合意形成することにより、仮想口座に対する着金（または、仮想口座を介した給与に対応する電子マネーへの着金）をトリガーとして実行する点に特徴がある。なお、以下に説明する情報処理は、振込サービスを利用して受け取る資金が給与ではない場合も同様に適用できる。また、以下では、仮想口座に対する着金に連動したサービスを提供する場合の情報処理の一例を説明するが、実施形態に係る情報処理は、たとえば、電子決済サービスの利用者に対して給与を支払う法人の法人アカウントに紐付く電子ウォレットから、前述の法人から給与の支払いを受ける利用者が保有する電子ウォレット（つまり利用者ウォレット）に対する給与に対応する電子マネーのチャージを行う場合も同様に適用できる。すなわち、以下に説明する情報処理は、給与の着金のタイミングが把握できれば、給与の入金経路は仮想口座であるか、ウォレット間の資金移動であるかを問わない。
【0013】
図１に示すように、実施形態に係る決済サービスは、サービス事業者Ｘ、銀行Ｙ、及び加盟店Ｚにより提供される。銀行Ｙは、金融機関の一例であり、銀行以外の他の金融機関であってもよい。なお、以下の説明において、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕ）は加盟店Ｚの会員にも該当し、利用者と会員とを相互に読み替えることができる。
【0014】
サービス事業者Ｘは、電子決済に関する電子決済サービスを利用者Ｕに提供する事業を営む。たとえば、電子決済サービスは、コード決済による電子マネーのやり取りを制御する所定の取引手段を提供するサービスに該当する。
【0015】
また、サービス事業者Ｘは、電子決済サービスに連携した連携サービスの１つとして、振込サービスを利用者Ｕに提供する。振込サービスは、仮想口座（バーチャル口座ともいう。）を経由した銀行口座への振込を通じて、各種資金を電子マネーで受け取ることを可能とするサービスである。サービス事業者Ｘは、振込サービスを利用者Ｕに提供する際、銀行Ｙから借り受けた複数の仮想口座の中から任意に選択した仮想口座を、電子決済サービスにおいて利用者Ｕが保有する電子ウォレットに一意に対応付ける。そして、サービス事業者Ｘは、電子ウォレットに対応付けた仮想口座を利用者Ｕに通知する。利用者Ｕは、サービス事業者から通知された仮想口座を振込先として振込元に通知することにより、電子ウォレットを通じて、各種資金を電子マネーで受け取ることができる。
【0016】
また、サービス事業者Ｘは、電子決済サービスの１つとして、着金に連動して利用者ウォレットから代金の支払いを行う決済サービス（以下、「着金連動決済サービス」という。）を利用者Ｕおよび加盟店Ｚに提供する。たとえば、サービス事業者Ｘは、電子決済サービスの利用者のうち、振込サービスを利用している利用者Ｕの要求に応じて、着金連動決済サービスの利用を許諾する。着金連動決済サービスは、後述するように、利用者ウォレットを通じて行われる決済処理について、あたかも銀行を利用した口座振替のようなＵＸ（user experience：ユーザエクスペリエンス）を利用者Ｕに提供する。また、サービス事業者Ｘは、所定の契約を交わした特定の加盟店（たとえば、加盟店Ｚ）に対して、着金連動決済サービスの利用を許諾する。着金連動決済サービスは、後述するように、加盟店が電子決済サービスを利用して決済を行う際の利便性を向上できる。
【0017】
銀行Ｙは、サービス事業者Ｘなどの事業者に対して、各種金融サービスを提供する事業を営む。銀行Ｙは、自行における口座の所有者（サービス事業者Ｘを含む）に対して、仮想口座を貸し出すサービスを提供する。銀行Ｙは、各種金融サービスの１つとして、仮想口座をサービス事業者Ｘに貸し出すサービスを提供する。
【0018】
加盟店Ｚは、顧客として、所定の登録手続を行った会員に対して、商品やサービスなどの取引対象を提供する事業を営む。加盟店Ｚは、会員が取引対象の代金を支払うための決済方法として、サービス事業者Ｘにより提供される電子決サービスを用いた電子決済を導入する。これにより、加盟店Ｚの会員は、電子決済サービスを利用可能な利用者であれば、加盟店Ｚから提供された取引対象の代金の支払方法として、電子決済サービスを用いた電子決済を利用できる。
【0019】
そして、図１に示す決済サービスでは、まず、サービス事業者Ｘと加盟店Ｚとの間で情報連携が実施される（ステップＳ００）。すなわち、利用者Ｕなどの電子決済サービスの利用者についてサービス事業者Ｘが管理するユーザアカウントの情報と、加盟店が有する会員管理ＤＢに保存される会員情報とが連携される。たとえば、サービス事業者Ｘは、電子決済サービスの利用者Ｕに関する利用者情報と、利用者Ｕが会員として取引対象の提供を受けている加盟店に関する加盟店情報とを予め関連付けた連携情報を保持する。また、加盟店Ｚは、電子決済サービスの利用者Ｕに関する利用者情報と、加盟店Ｚの会員に関する会員情報とを予め関連付けた連携情報を保持する。情報連携は、電子決済サービスの利用登録時に対象者により登録された個人情報と、加盟店Ｚから取引対象の提供を受けるために必要となる会員登録時に対象者により登録された個人情報とを突合することにより実現できる。または、利用者Ｕが自ら、連携する電子決済サービスの利用者情報と加盟店Ｚの会員に関する会員情報を指定して連携してもよい。利用者情報には、たとえば、電子決済サービスにおいて利用者Ｕを一意に特定するために各利用者に対してサービス事業者Ｘにより付与された固有の識別情報である利用者ＩＤが含まれる。また、加盟店情報には、電子決済サービスにおいて加盟店を一意に特定するために各加盟店に対してサービス事業者Ｘにより付与された固有の識別情報である加盟店ＩＤが含まれる。また、会員情報には、たとえば、加盟店Ｚにより各会員に付与された固有の識別情報である会員ＩＤが含まれる。なお、サービス事業者Ｘと加盟店Ｚは、情報連携により得られる同一の情報を互いに保持していてもよい。
【0020】
続いて、図１に示す決済サービスでは、銀行Ｙが、振込元金融機関から仮想口座を振込先とする銀行振込を受け付けると（ステップＳ０１）、仮想口座と収納先法人名義口座との対応関係を保存している振込ＤＢを参照し、振込処理を実行する（ステップＳ０２）。たとえば、銀行Ｙは、振込先である仮想口座に紐付く収納先法人名義口座への振込を実行する。なお、振込元金融機関から仮想口座を振込先とする銀行振込は、利用者Ｕに対する給与の振込に該当する。
【0021】
また、銀行Ｙは、仮想口座への着金を検知すると（ステップＳ０３）、管理ＤＢを参照し、対象となる仮想口座の貸出先であるサービス事業者Ｘに対して、仮想口座に対する入金通知を送信する（ステップＳ０４）。
【0022】
サービス事業者Ｘは、銀行Ｙとの連携システムを通じて、仮想口座への入金通知を受信すると、受信した入金通知に基づきチャージ処理を実行する（ステップＳ０５）。たとえば、サービス事業者Ｘは、受信した入金通知に基づいて、給与に対応する電子マネーの残高をチャージする。また、サービス事業者Ｘは、チャージ処理に成功すると（ステップＳ０６）、利用者の給与に対応するマネー残高にチャージ処理がされた旨を通知するための給与着金通知を加盟店Ｚに送信する（ステップＳ０７）。たとえば、サービス事業者Ｘは、連携情報に基づいて、給与着金通知の送信先となる加盟店を特定できる。具体的には、サービス事業者Ｘは、連携情報を参照して、マネー残高のチャージが行われた利用者ウォレットに紐付く利用者ＩＤに対応付けられている加盟店ＩＤを送信先として特定する。このとき、サービス事業者Ｘは、着金があった仮想口座に対応付けられている電子ウォレットである利用者ウォレットを保有する対象利用者に関する利用者情報（たとえば、利用者ＩＤ）を合わせて加盟店Ｚに通知する。これにより、サービス事業者Ｘは、加盟店Ｚに対して、会員に対して給与の着金があったことを速やかに通知できる。
【0023】
加盟店Ｚは、加盟店システムを通じて、サービス事業者Ｘの決済システムから給与着金通知を受信すると、会員管理ＤＢに基づいて、給与着金通知に対応する会員を特定するとともに、決済予定金額（すなわち、会員への請求金額）を参照する（ステップＳ０８）。そして、加盟店Ｚは、特定した会員に関する決済要求、すなわち代金の請求先となる会員に対応する利用者ＩＤや請求金額を示す情報や加盟店ＩＤを含む決済要求をサービス事業者Ｘに送信する（ステップＳ０９）。具体的には、加盟店Ｚは、給与着金通知に含まれる利用者ＩＤと連携情報とに基づいて会員ＩＤを特定し、特定した会員ＩＤに紐付く請求金額を取得する。そして、加盟店Ｚは、特定した会員ＩＤに対応付けられている利用者ＩＤと、特定した会員ＩＤに紐付く請求金額を含む決済要求をサービス事業者Ｘに送信する。
【0024】
サービス事業者Ｘは、加盟店Ｚから決済要求を受信すると、決済要求に従って決済処理を実行する（ステップＳ１０）。たとえば、サービス事業者Ｘは、決済要求に含まれている利用者ＩＤに基づいて、代金の請求先となる会員が電子決済サービスにおいて保有する利用者ウォレットを特定するとともに、決済要求に含まれている加盟店ＩＤに基づいて、代金の請求元となる加盟店が電子決済サービスにおいて保有する加盟店ウォレットを特定する。そして、サービス事業者Ｘは、特定した利用者ウォレットから、特定した加盟店ウォレットに対して、決済要求に含まれる請求金額に相当する額を資金移動する。また、サービス事業者Ｘは、特定した利用者ウォレットから、決済要求に含まれる請求金額に相当する額を差し引いて加盟店Ｚの売上として管理し、所定のタイミングで売上に相当する額の現金を加盟店に紐付く銀行口座へ振り込んでもよい。そして、サービス事業者Ｘは、決済処理が完了すると、決済処理結果を加盟店Ｚに返却する（ステップＳ１１）。なお、サービス事業者Ｘは、加盟店Ｚから受信する決済要求に会員ＩＤが含まれている場合（すなわち、サービス事業者Ｘと加盟店Ｚとの間で同一の情報を連携情報として共有する場合）、会員ＩＤと連携情報とに基づいて利用者ＩＤを特定し、特定した利用者ＩＤに基づいて、代金の請求先となる会員の利用者ウォレットを特定してもよい。また、サービス事業者Ｘは、決済要求に含まれる加盟店ＩＤから、給与着金通知の送信先である加盟店Ｚからの決済要求であると判定した場合、決済処理の完了に応じて、給与の着金に連動した決済が行われた旨（または、決済が正常に完了した旨）を対象利用者に通知してもよい。
【0025】
このように、図１に示す決済サービスに対応する情報処理（その１）によれば、サービス事業者Ｘは、加盟店Ｚが会員に対して請求する取引対象の代金を、会員と加盟店Ｚとの間で事前に合意された会員の給与振り込み時（すなわち、会員に給与が着金したタイミング（会員の利用者ウォレットに給与に対応する残高がチャージされたタイミング）ともいえる）に決済するため、給与着金通知とともに、着金があった仮想口座に対応付けられている利用者ウォレットを保有する対象利用者に関する利用者情報（たとえば、利用者ＩＤ）を加盟店Ｚに提供する。一方、加盟店Ｚは、会員に対して給与の着金があったことを速やかに認識でき、対象会員に対する決済要求を速やかにサービス事業者Ｘに返却できる。このようにして、図１に示す決済サービスに対応する情報処理（その１）によれば、サービス事業者Ｘは、加盟店Ｚからの要求に応じた決済処理を円滑に実行できる。また、図１に示す決済サービスに対応する情報処理（その１）によれば、加盟店Ｚが従前は知り得なかった会員の給与が着金したタイミングを把握でき、請求先に一定のマネー残高が期待できる状態で代金の請求を行うことができる。これにより、残高不足により決済が正常に完了しない事態が起こる可能性を低くでき、加盟店Ｚが電子決済サービスを利用して決済を行う際の利便性を向上できる。
【0026】
また、図１に示す決済サービスに対応する情報処理（その１）において、サービス事業者Ｘは、銀行Ｙから着金があった旨の通知を受け付けた場合、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者から承認を得ていることを条件として、対象利用者に代金の請求を行う加盟店に対して、対象利用者に関する利用者情報とともに、着金があった旨を通知してもよい。
【0027】
また、図１に示す決済サービスに対応する情報処理（その１）において、サービス事業者Ｘは、加盟店Ｚから予め設定される所定の期日までに、代金の請求先となる対象利用者（たとえば、図１に示す利用者Ｕなど）について着金があった旨の通知が銀行Ｙから受け付けられなかった場合、対象利用者に代金の請求を行う加盟店Ｚに対して、代金の請求先となる対象利用者について、着金がなかった旨を通知してもよい。また、サービス事業者Ｘは、決済要求に含まれる加盟店ＩＤから、給与着金通知の送信先である加盟店Ｚからの決済要求であると判定した場合、決済処理の完了に応じて、給与の着金に連動した決済が行われた旨（または、決済が正常に完了した旨）を対象利用者に通知してもよい。
【0028】
（１－２．実施形態に係る決済サービスに対応する情報処理（その２）の全体像）
以下、実施形態に係る決済サービスに対応する情報処理（その２）の全体像について説明する。図２は、実施形態に係る決済サービスに対応する情報処理（その２）の全体像を概略的に示す図である。図２に示す決済サービスに対応する情報処理（その２）は、着金に連動して利用者ウォレットから代金の支払いを行う取引対象の選択を対象利用者から受け付けて、利用者により選択された取引対象の提供元である加盟店に対して、連携対象として対象利用者に関する利用者情報を提供する点が、図１に示す決済サービスに対応する情報処理（その１）とは相違している。
以下、実施形態に係る決済サービスに対応する情報処理（その２）の全体像について説明する。図２は、実施形態に係る決済サービスに対応する情報処理（その２）の全体像を概略的に示す図である。図２に示す決済サービスに対応する情報処理（その２）は、着金に連動して利用者ウォレットから代金の支払いを行う取引対象の選択を対象利用者から受け付けて、利用者により選択された取引対象の提供元である加盟店に対して、連携対象として対象利用者に関する利用者情報を提供する点が、図１に示す決済サービスに対応する情報処理（その１）とは相違している。
【0029】
すなわち、図２に示す決済サービスに対応する情報処理（その２）において、決済サービスの利用者Ｕは利用者端末１０を操作して、決済を実現するための利用者用のアプリケーションプログラム（以下、適宜「決済アプリ」と称する。）を起動する。そして、利用者Ｕは、決済アプリを通じて、給与着金時支払可能先一覧を表示する一覧画面Ｗを利用者端末１０に表示させる。一覧画面Ｗに一覧として表示される給与着金時支払先は、利用者Ｕが、着金に連動して利用者ウォレットから代金の支払いを行うことが可能なサービスに該当し、サービス事業者Ｘにより提供される。給与着金時支払先は、加盟店Ｚにより会員に対して提供されるサービスとも言える。
【0030】
利用者Ｕは、一覧画面Ｗに表示される給与着金時支払可能先一覧の中から、着金に連動して利用者ウォレットから代金の支払いを行うサービスを選択し、選択したサービスを示す情報を含む利用者情報をサービス事業者Ｘに登録する（ステップＳ３０－１）。利用者情報には、上述の利用者ＩＤが含まれていてもよい。
【0031】
サービス事業者Ｘは、利用者Ｕから選択したサービスを示す情報の登録を受け付けると、利用者Ｕにより選択されたサービスの提供元である加盟店Ｚに対して、利用者Ｕに関する利用者情報を連携情報として提供する（ステップＳ３０－２）。サービス事業者Ｘは、選択したサービスを提供する加盟店Ｚに対して着金があった旨の情報提供を実施することについて利用者Ｕが承認することを条件として、利用者Ｕからサービスの選択を受け付けてもよい。また、サービス事業者Ｘは、給与着金時支払先とするサービスの選択（または、選択したサービスの登録）が行われた時点で、選択したサービスを提供する加盟店Ｚに対して着金があった旨の情報提供を実施することについて利用者Ｕが承認したものとみなしてもよい。この場合、サービス事業者Ｘは、利用者Ｕの利用者ＩＤに対応付けて、前述の承認を取得済みであることを示す情報を登録してもよい。
【0032】
また、サービス事業者Ｘは、利用者Ｕから、着金に連動して利用者ウォレットから代金の支払いを行うサービスの選択を受け付ける際、仮想口座に対する給与着金予定日を示す情報を利用者Ｕから受け付けて、受け付けた給与着金予定日を示す情報を、利用者情報とともに、サービスの提供元である加盟店Ｚに提供してもよい。
【0033】
加盟店Ｚは、サービス事業者Ｘから、利用者Ｕに関する利用者情報を取得すると、利用者Ｕを所定のウェブサイトに誘導し、所定の登録手続の実施を要求する。加盟店Ｚは、利用者Ｕによる所定の登録手続が正常に完了した場合、利用者Ｕに対して会員ＩＤを付与する。そして、加盟店Ｚは、サービス事業者Ｘから取得した利用者情報（たとえば、利用者ＩＤを含む）と、利用者Ｕに付与した会員ＩＤと、所定の登録手続により利用者Ｕにより登録された会員情報とを関連付けて、会員情報として会員管理ＤＢに登録して管理する。
【0034】
以降、図２に示す決済サービスに対応する情報処理（その２）において、ステップＳ３１～ステップＳ４１の処理が実行される。なお、ステップＳ３１～ステップＳ４１の処理は、上述した図１に示すステップＳ０１～ステップＳ１１の処理と同様であるので、説明は省略する。
【0035】
このように、図２に示す決済サービスに対応する情報処理（その２）によれば、サービス事業者Ｘは、加盟店Ｚが会員に対して請求する取引対象の代金を、会員と加盟店Ｚとの間で事前に合意された会員の給与振り込み時（すなわち、会員に給与が着金したタイミング（会員の利用者ウォレットに給与に対応する残高がチャージされたタイミング）ともいえる）に決済するため、着金に連動して利用者ウォレットから代金の支払いを行うサービスを利用者Ｕに選択させ、選択されたサービスの提供元に対して、利用者Ｕに関する利用者情報を提供することにより情報連携を行う。また、図２に示す決済サービスに対応する情報処理（その２）によれば、水道やガス、電気などのライフラインを提供する事業者や、金融商品を提供する事業者などが加盟店であり、利用者Ｕが選択可能なサービスとして存在すれば、利用者Ｕがこれらの事業者を選択することにより、水道光熱費の支払や金融商品の買付などといった定期的に行われる代金の支払いが給与の着金に連動して実行され、利用者ウォレットを通じて行われる決済処理について、あたかも銀行を利用した口座振替のようなＵＸ（user experience：ユーザエクスペリエンス）を利用者Ｕに提供できる。
【0036】
（１－３．実施形態に係る決済サービスに対応する情報処理（その３）の全体像）
以下、実施形態に係る決済サービスに対応する情報処理（その３）の全体像について説明する。図３は、実施形態に係る決済サービスに対応する情報処理（その３）の全体像を概略的に示す図である。図３に示す決済サービスに対応する情報処理（その３）は、着金があった旨の通知を受け付けた時点で加盟店Ｚから決済要求を受付済みである場合、決済要求に基づく決済処理を実行する点が、図２に示す決済サービスに対応する情報処理（その２）とは相違している。
以下、実施形態に係る決済サービスに対応する情報処理（その３）の全体像について説明する。図３は、実施形態に係る決済サービスに対応する情報処理（その３）の全体像を概略的に示す図である。図３に示す決済サービスに対応する情報処理（その３）は、着金があった旨の通知を受け付けた時点で加盟店Ｚから決済要求を受付済みである場合、決済要求に基づく決済処理を実行する点が、図２に示す決済サービスに対応する情報処理（その２）とは相違している。
【0037】
すなわち、図３に示す決済サービスに対応する情報処理（その３）において、決済サービスの利用者Ｕは利用者端末１０を操作して決済アプリを起動する。そして、利用者Ｕは、決済アプリを通じて、給与着金時支払可能先一覧を表示する一覧画面Ｗを利用者端末１０に表示させる。
【0038】
利用者Ｕが、一覧画面Ｗに表示される給与着金時支払可能先一覧の中から複数のサービスを選択した場合、利用者Ｕに対して支払優先順位の設定を要求し、各サービスの支払優先順位の設定を受け付けるようにしてもよい。この場合、利用者Ｕは、選択した各サービス、各サービスに対応する支払優先順位、及び給与着金予定日を示す各情報をサービス事業者Ｘに登録する（ステップＳ５０－１）。なお、利用者Ｕが、一覧画面Ｗに表示される給与着金時支払可能先一覧の中から、着金に連動して利用者ウォレットから代金の支払いを行うサービスを１つだけ選択した場合、支払優先順位の設定は行われない。この場合、利用者Ｕは、選択したサービス、及び給与着金予定日を示す各情報をサービス事業者Ｘに登録することになる。
【0039】
サービス事業者Ｘは、利用者Ｕから、たとえば、選択した各サービス、各サービスに対応する支払優先順位、及び給与着金予定日を示す各情報の登録を受け付けると、利用者Ｕにより選択されたサービスの提供元である加盟店Ｚ－１および加盟店Ｚ－２に対して、利用者Ｕに関する利用者情報を連携情報としてそれぞれ提供する（ステップＳ５０－２）。
【0040】
加盟店Ｚは、サービス事業者Ｘから、利用者Ｕに関する利用者情報を取得すると、利用者Ｕを所定のウェブサイトに誘導し、所定の登録手続の実施を要求する。加盟店Ｚは、利用者Ｕによる所定の登録手続が正常に完了した場合、利用者Ｕに対して会員ＩＤを付与する。そして、加盟店Ｚは、サービス事業者Ｘから取得した利用者情報と、利用者Ｕに付与した会員ＩＤと、所定の登録手続により利用者Ｕにより登録された会員情報とを関連付けて、会員情報として会員管理ＤＢに登録して管理する。そして、加盟店Ｚは、会員管理ＤＢに登録されている会員情報を参照して、サービス事業者Ｘに対して、給与着金通知の受信を待つことなく、決済要求を事前に送信する。たとえば、図３に示すように、加盟店Ｚ－１は、給与着金予定日の前日までに、請求先となる会員を特定するとともに、決済予定金額を参照する（ステップＳ５１）。そして、加盟店Ｚ－１は、代金の請求先となる会員に対応する利用者ＩＤや請求金額や給与着金のタイミングに連動して即時の決済を要求することを示すフラグ情報を示す情報を含む決済要求をサービス事業者Ｘに送信する（ステップＳ５２）。たとえば、加盟店Ｚは、会員情報に含まれる給与着金予定日を所定のタイミングで定期的に参照する。また、加盟店Ｚは、少なくとも、明日から所定日数以内の日付が給与着金予定日に設定されている会員ＩＤを選別し、選別した会員ＩＤに対応付けられている請求情報および利用者ＩＤを取得する。そして、加盟店Ｚは、取得した請求情報と、利用者ＩＤと、給与着金のタイミングに連動して即時の決済を要求することを示すフラグ情報とを含む決済要求をサービス事業者Ｘに送信する。実施形態において、給与着金のタイミングは、代金の請求先となる利用者ＩＤに紐付く利用者ウォレットに対して、給与に相当するマネー残高をチャージするのチャージ処理が正常に完了したタイミングともいえる。また、加盟店Ｚが決済要求を送信するタイミングは、加盟店の請求サイクルにて、該当月（たとえば前月）の決済予定金額が確定したタイミングであってもよい。この場合、加盟店Ｚは、該当のタイミングで、利用者Ｕが利用者ウォレットからの代金の支払い（すなわち、給与払い）を選択しているか否かを判定し、利用者Ｕが利用者ウォレットからの代金の支払いを選択していると判定された場合、請求情報と、利用者ＩＤと、給与着金のタイミングに連動して即時の決済を要求することを示すフラグ情報とを含む決済要求をサービス事業者Ｘに送信してもよい。
【0041】
以降、図３に示す決済サービスに対応する情報処理（その３）において、ステップＳ５３～ステップＳ５８の処理が実行される。なお、ステップＳ５３～ステップＳ５８の処理は、上述した図２に示すステップＳ３１～ステップＳ３６の処理と同様であるので、説明は省略する。
【0042】
サービス事業者Ｘは、たとえば、加盟店Ｚ－１から受信した決済要求を保存する。そして、サービス事業者Ｘは、銀行Ｙから入金通知を受信した場合、代金の請求先となる会員に対応する会員情報や請求金額を示す情報を含む決済要求を仮想口座に対する着金があった旨を通知するための給与着金通知を加盟店Ｚ－１に送信することなく、決済処理を実行するか否かを判定する。たとえば、サービス事業者Ｘは、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者（たとえば、利用者Ｕ）について、決済要求を受付済みであるか否かを判定し、決済要求を受付済みであると判定した場合、加盟店Ｚ－１から受付済みの決済要求に基づく決済処理を実行する（ステップＳ５９）。たとえば、サービス事業者Ｘは、加盟店Ｚ－１から受付済みの決済要求に、上述のフラグ情報が含まれている場合、銀行Ｙからの入金通知に応じて、代金の請求先となる利用者ＩＤに紐付く利用者ウォレットに対するマネー残高のチャージ処理が正常に完了したタイミングで、決済処理を実行してもよい。そして、サービス事業者Ｘは、決済処理が完了すると、決済処理結果を加盟店Ｚ－１に返却する（ステップＳ６０）。また、サービス事業者Ｘは、加盟店Ｚ－１から受付済みの決済要求に上述のフラグ情報が含まれている場合、決済処理の完了に応じて、給与の着金に連動した決済が行われた旨（または、決済が正常に完了した旨）を対象利用者に通知してもよい。
【0043】
たとえば、サービス事業者Ｘは、対象利用者（たとえば、利用者Ｕ）について複数の決済要求がある場合、対象利用者により予め設定される優先順位に従って、決済処理を実行してもよい。
【0044】
また、たとえば、サービス事業者Ｘは、対象利用者（たとえば、利用者Ｕ）について決済要求に基づく決済処理を実行する際、決済要求に含まれる請求金額を参照し、対象利用者が保有する利用者ウォレットのマネー残高が請求金額に満たない場合、対象利用者に対して残高不足である旨を通知し、利用者ウォレットの残高不足が解消されたことを契機として、決済要求に基づく決済処理を実行してもよい。
【0045】
また、たとえば、サービス事業者Ｘは、利用者Ｕからの要求に応じて、利用者Ｕについて受付済みの決済要求に関する情報を提供してもよい。決済要求に関する情報には、たとえば、決済要求に対応するサービスを示す情報や、請求金額を示す情報が含まれていてもよい。
【0046】
また、サービス事業者Ｘは、銀行Ｙから入金通知を受信した場合、利用者ウォレットへのチャージ処理を実行せずに、仮想口座に入金された金額を元にして決済処理を実行してもよい。たとえば、サービス事業者Ｘは、仮想口座に入金された入金額に相当する電子マネーをウォレットの残高にチャージすることにより、ウォレットの残高が所定の上限金額を超えることになった場合、利用者Ｕが予め指定する返金用の銀行口座に対して返金を行う処理（オートスイープとも称される。）を実行する必要があるが、上述の構成により、返金を行う処理が必要となる事態を未然に回避することができる可能性を高めることができる。
【0047】
このように、図３に示す決済サービスに対応する情報処理（その３）によれば、サービス事業者は、加盟店Ｚが会員に対して取引対象の代金を請求するために、利用者ウォレットを通じて既に行われている決済処理を、給与着金通知の受付を契機として実行するため、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者（たとえば、利用者Ｕ）について、決済要求を受付済みであるか否かを判定し、決済要求を受付済みであると判定した場合、決済要求に基づく決済処理を実行する。これにより、図３に示す決済サービスに対応する情報処理（その３）によれば、給与の着金に連動して、できるだけ速やかに加盟店Ｚからの決済要求を処理できる。
【0048】
〔２．装置構成〕
（２－１．システム構成）
以下、実施形態に係る装置構成の一例について具体的に説明する。まず、実施形態に係る情報処理の説明に先駆けて、図４を参照しつつ、実施形態に係る情報処理システムＳＹＳの構成の一例について説明する。図４は、実施形態に係る装置構成例を示す図である。
（２－１．システム構成）
以下、実施形態に係る装置構成の一例について具体的に説明する。まず、実施形態に係る情報処理の説明に先駆けて、図４を参照しつつ、実施形態に係る情報処理システムＳＹＳの構成の一例について説明する。図４は、実施形態に係る装置構成例を示す図である。
【0049】
図４に示すように、実施形態に係る情報処理システムＳＹＳは、利用者端末１０と、決済サーバ１００と、連携銀行サーバ２００と、加盟店サーバ３００とを含む。利用者端末１０、決済サーバ１００、連携銀行サーバ２００、及び加盟店サーバ３００は、ネットワークＮを介して有線または無線により相互に通信可能に接続される。ネットワークＮは、たとえば、インターネットなどのＷＡＮ（Wide Area Network）である。
【0050】
図４に示す決済サーバ１００は、実施形態に係る情報処理を実行する情報処理装置である。決済サーバ１００は、典型的にはサーバ装置であるが、メインフレームやワークステーションなどにより実現されてもよい。また、決済サーバ１００がサーバ装置により実現される場合、単独のサーバ装置により実現されてもよいし、複数のサーバ装置及び複数のストレージ装置が協働して動作するクラウドシステムなどにより実現されてもよい。決済サーバ１００は、電子決済に関する電子決済サービスを利用する利用者（たとえば、図１に示す利用者Ｕなど）に提供する事業を営むサービス事業者Ｘ（図１など参照）により運営および管理される。
【0051】
決済サーバ１００は、たとえば、電子決済サービスに関する各種の情報処理を実行する。具体的には、決済サーバ１００は、コード決済を実現するための各種機能を設けられている決済アプリを、電子決済サービスの利用者である一般消費者に配布する。決済サーバ１００は、決済アプリ専用のインターフェイスを介して、決済アプリからの取引要求を受け付けた場合は、その取引要求に従って、口座間における電子マネーの送金処理などを含む情報処理を実行する。決済アプリは、決済先、決済元、及び決済額などの情報を含む取引情報を決済サーバ１００に送信する。なお、取引情報には、上述の各情報の他、取引を個別に特定するための取引コードや、取引が行われた日時を特定するための日時情報（すなわち、タイムスタンプ）などの情報が含まれていてもよい。
【0052】
また、決済サーバ１００は、上述の振込サービスに関する各種の情報処理を実行する。たとえば、振込サービスは、仮想口座を経由した銀行口座への振込を通じて、利用者の給与や給与以外の各種資金を電子マネーで受け取ることを可能とする。なお、振込サービスは、コード決済を実現するための決済アプリ内で起動するミニアプリとして構成されてもよいし、この決済アプリとは独立して用意された固有のアプリケーションプログラムにより構成されてもよい。
【0053】
また、決済サーバ１００は、電子決済サービスに内包されるサービスの１つとして、着金に連動して利用者ウォレットから代金の支払いを実現するための決済サービスを提供する。
【0054】
図１に示す連携銀行サーバ２００は、サービス事業者Ｘ（図１など参照）などの事業者に対して、各種金融サービスを提供する事業を銀行Ｙ（図１など参照）により運営及び管理される情報処理装置である。連携銀行サーバ２００は、典型的にはサーバ装置であるが、メインフレームやワークステーションなどにより実現されてもよい。また、連携銀行サーバ２００がサーバ装置により実現される場合、単独のサーバ装置により実現されてもよいし、複数のサーバ装置及び複数のストレージ装置が協働して動作するクラウドシステムなどにより実現されてもよい。
【0055】
連携銀行サーバ２００は、たとえば、各利用者からの指示に応じた送金や振替などの銀行業務に関する処理を実行する。また、連携銀行サーバ２００は、銀行口座の利用履歴として、各カード会社や、各種サービスの提供者による銀行口座からの引き落としに関する情報（たとえば、引き落とした金額や、引き落とした日時など）や、現在の口座残高などを含む口座情報などを、口座名義人に対応付けて管理する。
【0056】
また、連携銀行サーバ２００は、各種金融サービスの１つとして、自行において実口座を保有する事業者に対して、実口座に紐付く仮想口座を貸し渡すサービスを提供する。
【0057】
図１に示す加盟店サーバ３００は、加盟店サーバ３００は、所定の登録手続を行った会員に対して、商品やサービスなどの取引対象を提供する事業を営む加盟店Ｚ（たとえば、図１など参照）により運営及び管理される情報処理装置である。加盟店サーバ３００は、典型的にはサーバ装置であるが、メインフレームやワークステーションなどにより実現されてもよい。また、加盟店サーバ３００がサーバ装置により実現される場合、単独のサーバ装置により実現されてもよいし、複数のサーバ装置及び複数のストレージ装置が協働して動作するクラウドシステムなどにより実現されてもよい。加盟店Ｚは、会員が取引対象の代金を支払うための決済方法として、サービス事業者Ｘにより提供される電子決済サービスを用いた電子決済を導入する。加盟店サーバ３００は、所定の登録手続を行った会員に対して、商品やサービスなどの取引対象を提供する事業を営む。
【0058】
（２－２．振込サービスについて）
以下、決済サーバ１００が、電子決済サービスの利用者からの要求に応じて、かかる利用者に提供する振込サービスについて説明する。決済サーバ１００は、決済アプリなどを通じて、利用者から振込サービスの利用登録要求を受け付けると、利用者に対する仮想口座の割当、及び、利用者情報の登録を実行する。たとえば、決済サーバ１００は、連携する銀行から予め借り受けた複数の仮想口座のうち未使用の状態である仮想口座を任意に選択し、選択した仮想口座を特定するための口座情報（口座番号）と、利用者に固有の識別情報とを関連付けて登録する。なお、決済サーバ１００は、利用者に固有の識別情報として、たとえば、電子決済サービスの利用登録時に決済サーバ１００が利用者ごとに個別に割り振る利用者ＩＤを利用できる。
以下、決済サーバ１００が、電子決済サービスの利用者からの要求に応じて、かかる利用者に提供する振込サービスについて説明する。決済サーバ１００は、決済アプリなどを通じて、利用者から振込サービスの利用登録要求を受け付けると、利用者に対する仮想口座の割当、及び、利用者情報の登録を実行する。たとえば、決済サーバ１００は、連携する銀行から予め借り受けた複数の仮想口座のうち未使用の状態である仮想口座を任意に選択し、選択した仮想口座を特定するための口座情報（口座番号）と、利用者に固有の識別情報とを関連付けて登録する。なお、決済サーバ１００は、利用者に固有の識別情報として、たとえば、電子決済サービスの利用登録時に決済サーバ１００が利用者ごとに個別に割り振る利用者ＩＤを利用できる。
【0059】
また、決済サーバ１００は、利用者情報の登録において、資金移動業に対して、法令により義務付けられている滞留規制の遵守を目的として、仮想口座を経由して銀行口座に入金された金額のうち、所定額を超える額の現金を利用者に返金するための返金用の銀行口座の情報を利用者から取得してもよい。この場合、決済サーバ１００は、利用者から取得した返金用の銀行口座の情報を、上述の固有情報に関連付けて登録する。
【0060】
また、決済サーバ１００は、利用者が使用する端末装置に対し、振込サービス用の仮想口座を特定するための口座情報（口座番号）に送信することにより、利用者に口座情報を提供する。利用者は、決済サーバ１００から提供された口座情報を、給与や諸経費などの振込先として勤め先の企業などの振込依頼先へ知らせる。利用者から口座情報を受け取った企業などの振込依頼先は、自身が保有する銀行口座から、この口座情報を振込先（送金先）として、たとえば、給与や諸経費などの所定の振込を行う。決済サーバ１００は、仮想口座に対する着金を検知すると、仮想口座が割り当てられている利用者の電子ウォレット（電子マネー口座）に対して、仮想口座に対する入金額に相当する電子マネーを入金（チャージ、又は残高加算ともいう）する。このようにして、利用者は、振込依頼先に口座情報を知らせることにより、仮想口座を経由した銀行口座への振込を通じて、利用者の給与や給与以外の各種資金を電子マネーで受け取ることができる。
【0061】
（２－３．決済サーバ１００の構成）
以下、図４を用いて、実施形態に係る決済サーバ１００の構成について説明する。図４に示すように、決済サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。
以下、図４を用いて、実施形態に係る決済サーバ１００の構成について説明する。図４に示すように、決済サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。
【0062】
（通信部１１０について）
通信部１１０は、たとえば、ＮＩＣ（Network Interface Card）などによって実現される。そして、通信部１１０は、ネットワークＮと有線または無線で接続され、利用者端末１０や、連携銀行サーバ２００や、加盟店サーバ３００などの他の装置との間で情報の送受信を行う。
通信部１１０は、たとえば、ＮＩＣ（Network Interface Card）などによって実現される。そして、通信部１１０は、ネットワークＮと有線または無線で接続され、利用者端末１０や、連携銀行サーバ２００や、加盟店サーバ３００などの他の装置との間で情報の送受信を行う。
【0063】
（記憶部１２０について）
記憶部１２０は、たとえば、ＲＡＭ（Random Access Memory）やフラッシュメモリ（Flash Memory）などの半導体メモリ素子、または、ハードディスクや光ディスクなどの記憶装置によって実現される。図４に示すように、記憶部１２０は、利用者情報記憶部１２１と、連携情報記憶部１２２と、認可状態記憶部１２３と、選択サービス情報記憶部１２４と、決済要求記憶部１２５とを有する。
記憶部１２０は、たとえば、ＲＡＭ（Random Access Memory）やフラッシュメモリ（Flash Memory）などの半導体メモリ素子、または、ハードディスクや光ディスクなどの記憶装置によって実現される。図４に示すように、記憶部１２０は、利用者情報記憶部１２１と、連携情報記憶部１２２と、認可状態記憶部１２３と、選択サービス情報記憶部１２４と、決済要求記憶部１２５とを有する。
【0064】
（利用者情報記憶部１２１について）
利用者情報記憶部１２１は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）に関する利用者情報を記憶する。図５は、実施形態に係る利用者情報記憶部１２１に記憶される利用者情報の一例を示す図である。
利用者情報記憶部１２１は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）に関する利用者情報を記憶する。図５は、実施形態に係る利用者情報記憶部１２１に記憶される利用者情報の一例を示す図である。
【0065】
図５に示すように、利用者情報記憶部１２１に記憶されている利用者情報は、「利用者ＩＤ」の項目と、「アカウント情報」の項目と、「ウォレットＩＤ」の項目と、「仮想口座番号」の項目とを有している。利用者情報が有するこれらの項目は相互に対応付けられている。
【0066】
「利用者ＩＤ」の項目には、電子決済サービスの利用者を一意に特定するために各利用者に対して付与された固有の識別情報である利用者ＩＤが記憶される。
【0067】
「アカウント情報」の項目には、振込サービスの利用者のユーザアカウントに関する情報が記憶される。ユーザアカウントに関する情報には、振込サービスにログインするためのログイン情報（たとえば、ログインＩＤやパスワードを含む）や、利用者の氏名、住所、電話番号、メールアドレスなどの個人情報などが含まれる。
【0068】
「ウォレットＩＤ」の項目には、電子決済サービスにおいて利用者が保有する電子ウォレットである利用者ウォレットを一意に特定するために利用者ウォレットに付与された固有の識別情報であるウォレットＩＤが記憶される。
【0069】
「仮想口座番号」の項目には、利用者ウォレットに対応付けられている仮想口座を一意に特定するために仮想口座に付与された固有の口座番号を示す情報が記憶される。
【0070】
（連携情報記憶部１２２について）
連携情報記憶部１２２は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）に関する利用者情報と、電子決済サービスを導入する加盟店（たとえば、図１に示す加盟店Ｚなど）の会員に関する会員情報とを予め関連付けた連携情報を記憶する。図６は、実施形態に係る連携情報記憶部１２２に記憶される連携情報の一例を示す図である。
連携情報記憶部１２２は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）に関する利用者情報と、電子決済サービスを導入する加盟店（たとえば、図１に示す加盟店Ｚなど）の会員に関する会員情報とを予め関連付けた連携情報を記憶する。図６は、実施形態に係る連携情報記憶部１２２に記憶される連携情報の一例を示す図である。
【0071】
図６に示すように、連携情報記憶部１２２に記憶される連携情報は、「利用者ＩＤ」の項目や、「加盟店ＩＤ」の項目や、「個人情報」の項目などといった複数の項目を有している。連携情報が有するこれらの項目は相互に対応付けられている。
【0072】
「利用者ＩＤ」の項目には、電子決済サービスの利用者を一意に特定するために各利用者に対して付与された固有の識別情報である利用者ＩＤが記憶される。「利用者ＩＤ」の項目に記憶される利用者ＩＤは、利用者情報が有する「利用者ＩＤ」の項目に記憶される利用者ＩＤと同一の情報である。
【0073】
「加盟店ＩＤ」の項目には、加盟店を識別するために加盟店ごとに付与された識別情報である加盟店ＩＤが記憶される。
【0074】
「個人情報」の項目には、電子決済サービスの利用者が利用登録時に設定した個人情報が記憶される。「個人情報」の項目には、加盟店から取得した会員の個人情報が記憶されてもよい。たとえば、加盟店から取得した会員の個人情報のうち、電子決済サービスの利用登録時における設定されていなかった個人情報を記憶してもよい。「個人情報」の項目に記憶される個人情報は、たとえば、電子決済サービスの利用者と、加盟店の会員との同一性を確認する場合や、本人確認などの処理に用いられてもよい。
【0075】
図６に示す連携情報によれば、電子決済サービスの利用者について、電子決済サービスにおける利用者情報と、加盟店における会員情報との対応関係を把握可能となる。なお、図６に示す連携情報記憶部１２２は、電子決済サービスの利用者に対して加盟店から付与された会員ＩＤを記憶してもよい。会員ＩＤは、加盟店Ｚにより各会員に付与される固有の識別情報である。
【0076】
（認可状態情報記憶部１２３について）
認可状態記憶部１２３は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）から、加盟店（たとえば、図１に示す加盟店Ｚなど）に対して着金があった旨の情報提供を実施することについて予め承認を得ているか否かを示す認可状態情報を記憶する。図７は、実施形態に係る認可状態記憶部１２３に記憶される認可状態情報の一例を示す図である。
認可状態記憶部１２３は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）から、加盟店（たとえば、図１に示す加盟店Ｚなど）に対して着金があった旨の情報提供を実施することについて予め承認を得ているか否かを示す認可状態情報を記憶する。図７は、実施形態に係る認可状態記憶部１２３に記憶される認可状態情報の一例を示す図である。
【0077】
図７に示すように、認可状態記憶部１２３に記憶される認可状態情報は、「利用者ＩＤ」の項目と、「加盟店ＩＤ」の項目と、「認可状態」の項目とを有している。認可状態情報が有するこれらの項目は相互に対応付けられている。
【0078】
「利用者ＩＤ」の項目には、電子決済サービスの利用者を一意に特定するために各利用者に対して付与された固有の識別情報である利用者ＩＤが記憶される。「利用者ＩＤ」の項目に記憶される利用者ＩＤは、利用者情報や連携情報が有する「利用者ＩＤ」の項目に記憶される利用者ＩＤと同一の情報である。
【0079】
「加盟店ＩＤ」の項目には、加盟店を識別するために加盟店ごとに付与された識別情報である加盟店ＩＤが記憶される。「加盟店ＩＤ」の項目に記憶される加盟店ＩＤは、連携情報が有する「加盟店ＩＤ」の項目に記憶される加盟店ＩＤと同一の情報である。
【0080】
「認可状態」の項目には、加盟店に対して着金があった旨の情報提供を実施することについて予め承認を得ているか否かを示す情報が記憶される。たとえば、図７に示すように、「認可状態」の項目に「承認」が記憶されている場合、加盟店に対して着金があった旨の情報提供を実施することについて予め承認を得ていることを示している。
【0081】
図７に示す認可状態情報によれば、対象利用者について、加盟店ごとに情報提供の承認が得られているかを把握できる。
【0082】
（選択サービス情報記憶部１２４について）
選択サービス情報記憶部１２４は、利用者端末１０で動作中の決済アプリ上に表示された一覧画面Ｗにおいて、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）により、先着金に連動して利用者ウォレットから代金の支払いを行うサービスとして選択された選択サービスに関する情報を記憶する。図８は、実施形態に係る選択サービス情報記憶部１２４に記憶される選択サービスに関する情報の一例を示す図である。
選択サービス情報記憶部１２４は、利用者端末１０で動作中の決済アプリ上に表示された一覧画面Ｗにおいて、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）により、先着金に連動して利用者ウォレットから代金の支払いを行うサービスとして選択された選択サービスに関する情報を記憶する。図８は、実施形態に係る選択サービス情報記憶部１２４に記憶される選択サービスに関する情報の一例を示す図である。
【0083】
図８に示すように、選択サービス情報記憶部１２４に記憶される選択サービスに関する情報は、「利用者ＩＤ」の項目と、「サービス」の項目と、「加盟店ＩＤ」の項目と、「優先順位」の項目とを有している。決済要求に関する情報が有するこれらの項目は相互に対応付けられている。
【0084】
「利用者ＩＤ」の項目には、電子決済サービスの利用者を一意に特定するために各利用者に対して付与された固有の識別情報である利用者ＩＤが記憶される。「利用者ＩＤ」の項目に記憶される利用者ＩＤは、利用者情報や、連携情報や、認可状態情報が有する「利用者ＩＤ」の項目に記憶される利用者ＩＤと同一の情報である。
【0085】
「サービス」の項目には、電子決済サービスの利用者により、着金に連動して利用者ウォレットから代金の支払いを行うサービスとして選択されたサービスを特定するための情報が記憶される。なお、サービスを一意に特定するために各サービスに付与された識別情報が記憶されていてもよい。
【0086】
「加盟店ＩＤ」の項目には、加盟店を識別するために加盟店ごとに付与された識別情報である加盟店ＩＤが記憶される。「加盟店ＩＤ」の項目に記憶される加盟店ＩＤは、連携情報や認可状態情報が有する「加盟店ＩＤ」の項目に記憶される加盟店ＩＤと同一の情報である。
【0087】
「優先順位」の項目には、選択した各サービスの支払優先順位を示す情報が記憶される。なお、「優先順位」の項目に記憶される支払優先順位を示す情報は、利用者により、着金に連動して利用者ウォレットから代金の支払いを行うサービスとして複数のサービスが選択された場合に、利用者からの設定を受け付けて登録される。
【0088】
（決済要求記憶部１２５について）
決済要求記憶部１２５は、加盟店（たとえば、図１に示す加盟店Ｚなど）から受付済みの決済要求に関する情報を記憶する。決済要求は、加盟店が電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）でもある会員に対して取引対象の代金を請求するために、決済サーバ１００に送信する。図９は、実施形態に係る決済要求記憶部１２５に記憶される決済要求に関する情報の一例を示す図である。
決済要求記憶部１２５は、加盟店（たとえば、図１に示す加盟店Ｚなど）から受付済みの決済要求に関する情報を記憶する。決済要求は、加盟店が電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）でもある会員に対して取引対象の代金を請求するために、決済サーバ１００に送信する。図９は、実施形態に係る決済要求記憶部１２５に記憶される決済要求に関する情報の一例を示す図である。
【0089】
図９に示すように、決済要求記憶部１２５に記憶される決済要求に関する情報は、「請求元（加盟店ＩＤ）」の項目と、「請求先（利用者ＩＤ）」の項目と、「請求金額」の項目と、「給与着金連動決済フラグ」の項目といった複数の項目を有している。決済要求に関する情報が有するこれらの項目は相互に対応付けられている。
【0090】
「請求元（加盟店ＩＤ）」の項目には、代金の請求元である加盟店ＩＤが記憶される。「請求先（利用者ＩＤ）」の項目には、代金の請求先である利用者ＩＤが記憶される。「請求金額」の項目には、決済要求により請求される金額を示す情報が記憶される。「給与着金連動決済フラグ」の項目には、給与着金のタイミングに連動して即時の決済を要求することを示すフラグ情報が決済要求に含まれていたか否かを示す情報が記憶される。たとえば、図９にように、「給与着金連動決済フラグ」の項目に「あり」が記憶されている場合、フラグ情報が含まれていたことを示す。
【0091】
（制御部１３０について）
制御部１３０は、コントローラ（controller）であり、たとえば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などによって、決済サーバ１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、たとえば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路により実現され得る。
制御部１３０は、コントローラ（controller）であり、たとえば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などによって、決済サーバ１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、たとえば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路により実現され得る。
【0092】
図４に示すように、制御部１３０は、チャージ部１３１と、実行部１３２とを有し、これらの各部により、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０には、決済サーバ１００が実行する各種処理の拡張などに応じて、図４に示す各部とは異なる新たな機能部が導入されてもよい。
【0093】
（チャージ部１３１について）
チャージ部１３１は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）が保有する電子ウォレットである利用者ウォレットに予め対応付けられている仮想口座に対する着金があった旨の通知を受け付けた場合、仮想口座に入金された入金額に相当する額の電子マネーを、着金が検知された仮想口座に対応付けられている利用者ウォレットにチャージする。
チャージ部１３１は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）が保有する電子ウォレットである利用者ウォレットに予め対応付けられている仮想口座に対する着金があった旨の通知を受け付けた場合、仮想口座に入金された入金額に相当する額の電子マネーを、着金が検知された仮想口座に対応付けられている利用者ウォレットにチャージする。
【0094】
また、チャージ部１３１は、利用者に対して給与を支払う法人（たとえば、利用者の勤め先の企業など）の法人アカウントに紐付く電子ウォレットから利用者が保有する電子ウォレットである利用者ウォレットに対し、法人からの要求に応じて、前記給与に相当する額の電子マネーをチャージするチャージ処理を実行してもよい。
【0095】
（実行部１３２について）
実行部１３２は、仮想口座に対する着金があったの通知の受付、又は利用者ウォレットに対するマネー残高のチャージ処理の完了（すなわち正常完了）に応じて、連携情報記憶部１２２に記憶されている連携情報を参照し、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者（たとえば、図１に示す利用者Ｕなど）に対して予め関連付けられている加盟店（たとえば、図１に示す加盟店Ｚなど）を特定し、特定した加盟店に対して、対象利用者に対応する利用者情報とともに着金があった旨の通知を実行する。
実行部１３２は、仮想口座に対する着金があったの通知の受付、又は利用者ウォレットに対するマネー残高のチャージ処理の完了（すなわち正常完了）に応じて、連携情報記憶部１２２に記憶されている連携情報を参照し、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者（たとえば、図１に示す利用者Ｕなど）に対して予め関連付けられている加盟店（たとえば、図１に示す加盟店Ｚなど）を特定し、特定した加盟店に対して、対象利用者に対応する利用者情報とともに着金があった旨の通知を実行する。
【0096】
たとえば、実行部１３２は、代金の請求に関する決済要求を加盟店から受け付けた場合、決済要求に含まれている利用者情報（たとえば、利用者ＩＤ）に基づいて、代金の請求先となる対象利用者が保有する利用者ウォレットを特定し、特定した利用者ウォレットから、決済要求に含まれる請求金額に相当する額を、加盟店が保有する加盟店ウォレットに資金移動する決済処理を実行してもよい（たとえば、図１および図２参照）。また、実行部１３２は、決済処理として、特定した利用者ウォレットから、決済要求に含まれる請求金額に相当する額を差し引いて加盟店Ｚの売上として管理し、所定のタイミングで売上に相当する額の現金を加盟店に紐付く銀行口座へ振り込んでもよい。
【0097】
また、たとえば、実行部１３２は、着金があった旨の通知を受け付けた場合、認可情報記憶部１２３に記憶されている認可状態情報を参照して、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者（たとえば、図１に示す利用者Ｕなど）から、加盟店に対して着金があった旨の情報提供を実施することについて予め承認を得ていることが確認されることを条件として、対象利用者に代金の請求を行う加盟店に対して、対象利用者に関する利用者情報とともに、着金があった旨を通知してもよい（たとえば、図１参照）。具体的には、実行部１３２は、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者に対応する利用者ＩＤを利用者情報記憶部１２１から取得する。そして、実行部１３２は、取得した利用者ＩＤとともに、着金があった旨の通知を、通信部１１０を通じて、加盟店に送信する。
【0098】
また、たとえば、実行部１３２は、着金があった旨の通知を受け付けた場合、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者（たとえば、図１に示す利用者Ｕなど）から、加盟店に対して着金があった旨の情報提供を実施することについて予め承認を得ていることを条件として、対象利用者に代金の請求を行う加盟店に対して、対象利用者に関する利用者情報とともに、着金があった旨を通知してもよい。
【0099】
また、たとえば、実行部１３２は、加盟店から予め設定される所定の期日までに、代金の請求先となる対象利用者（たとえば、図１に示す利用者Ｕなど）について着金があった旨の通知が受け付けられなかった場合、対象利用者に代金の請求を行う加盟店に対して、代金の請求先となる対象利用者について、着金がなかった旨を通知してもよい。
【0100】
また、たとえば、実行部１３２は、着金に連動して利用者ウォレットから代金の支払いを行う取引対象の選択を対象利用者（たとえば、図１に示す利用者Ｕなど）から受け付けた場合、対象利用者から上述の承認を得られたものとして取り扱い、利用者により選択された取引対象の提供元である加盟店に対して、対象利用者に関する利用者情報を連携情報として提供してもよい（図２参照）。
【0101】
また、たとえば、実行部１３２は、取引対象の選択を利用者（たとえば、図１に示す利用者Ｕなど）から受け付けたことを条件として、利用者に対応付けて上述の承認を取得済みであることを示す情報を認可状態記憶部１２３に登録してもよい。
【0102】
また、たとえば、実行部１３２は、取引対象の選択を利用者（たとえば、図１に示す利用者Ｕなど）から受け付ける際、仮想口座に対する給与着金予定日を示す情報を利用者から受け付けて、受け付けた給与着金予定日を示す情報を、利用者情報とともに、取引対象の提供元である加盟店に提供してもよい。
【0103】
また、たとえば、実行部１３２は、着金があった旨の通知を受け付けた場合、決済要求記憶部１２５を参照して、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者（たとえば、図１に示す利用者Ｕなど）について、加盟店（たとえば、図１に示す加盟店Ｚ）から決済要求を受付済みであるか否かを判定し、決済要求を受付済みであると判定した場合、決済要求に基づく決済処理を実行してもよい（たとえば、図３参照）。実行部１３２が加盟店から受け付ける決済要求には、給与着金のタイミングに連動して即時の決済を要求することを示すフラグ情報が含まれていてもよい。この場合、実行部１３２は、決済要求に上述のフラグ情報が含まれていることを条件として、対象利用者について、即時の決済処理を実行する。
【0104】
また、たとえば、実行部１３２は、対象利用者（たとえば、図１に示す利用者Ｕなど）について複数の決済要求がある場合、予め設定される優先順位に従って、決済処理を実行してもよい。
【0105】
また、たとえば、実行部１３２は、対象利用者（たとえば、図１に示す利用者Ｕなど）について決済要求に基づく決済処理を実行する際、決済要求に含まれる請求金額を参照し、対象利用者が保有するウォレットのマネー残高が請求金額に満たない場合、対象利用者に対して残高不足である旨を通知し、対象利用者が保有する利用者ウォレットの残高不足が解消されたことを契機として、決済要求に基づく決済処理を実行してもよい。
【0106】
また、たとえば、実行部１３２は、電子決済サービスの利用者（たとえば、図１に示す利用者Ｕなど）からの要求に応じて、利用者について受付済みの決済要求に関する情報を提供してもよい。
【0107】
また、たとえば、実行部１３２は、加盟店から受付済みの決済要求に、着金のタイミングに連動して即時の決済を要求することを示すフラグ情報が含まれている場合、決済処理の完了に応じて、着金のタイミングに連動して決済が行われた旨の通知を対象利用者に通知してもよい。
【0108】
また、たとえば、実行部１３２は、チャージ部１３１により、利用者ウォレットに対して法人アカウントから給与に相当する額の電子マネーをチャージするチャージ処理が実行された場合、このチャージ処理の完了に応じて、連携情報を参照し、チャージ処理が行われた利用者ウォレットを保有する対象利用者に対して予め関連付けられている加盟店を特定し、特定した加盟店に対して、対象利用者に対応する利用者情報とともに対象利用者に対して給与の着金があった旨の通知を実行してもよい。
【0109】
〔３．処理手順例〕
（３－１．決済サーバによる処理（その１））
以下、実施形態に係る決済サーバ１００により実行される情報処理の処理手順の一例を説明する。まず、図１０を用いて、実施形態に係る決済サーバ１００により実行される情報処理（その１）の処理手順の一例を説明する。図１０は、実施形態に係る決済サーバ１００により実行される情報処理（その１）の処理手順例を示すフローチャートである。なお、図１０に示す処理手順は、決済サーバ１００が有する制御部１３０により実行される。制御部１３０は、決済サーバ１００の稼働中、図１０に示す処理手順を繰り返し実行する。
（３－１．決済サーバによる処理（その１））
以下、実施形態に係る決済サーバ１００により実行される情報処理の処理手順の一例を説明する。まず、図１０を用いて、実施形態に係る決済サーバ１００により実行される情報処理（その１）の処理手順の一例を説明する。図１０は、実施形態に係る決済サーバ１００により実行される情報処理（その１）の処理手順例を示すフローチャートである。なお、図１０に示す処理手順は、決済サーバ１００が有する制御部１３０により実行される。制御部１３０は、決済サーバ１００の稼働中、図１０に示す処理手順を繰り返し実行する。
【0110】
図１０に示すように、実行部１３２は、連携銀行サーバ２００から入金受付通知を受信したか否かを判定する（ステップＳ１０１）。
【0111】
実行部１３２は、連携銀行サーバ２００から入金受付通知を受信したと判定した場合（ステップＳ１０１；Ｙｅｓ）、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者を特定する（ステップＳ１０２）。
【0112】
また、実行部１３２は、特定した対象利用者について、加盟店に対して着金があった旨の情報提供を実施することについての承認を取得済みであるか否かを判定する（ステップＳ１０３）。
【0113】
実行部１３２は、特定した対象利用者について、加盟店に対して着金があった旨の情報提供を実施することについての承認を取得済みであると判定した場合（ステップＳ１０３；Ｙｅｓ）、対象利用者に代金の請求を行う加盟店に対して、対象利用者に関する利用者情報とともに、着金があった旨を通知して（ステップＳ１０４）、図１０に示す処理手順を終了する。
【0114】
実行部１３２は、特定した対象利用者について、加盟店に対して着金があった旨の情報提供を実施することについての承認を取得済みではないと判定した場合（ステップＳ１０３；Ｎｏ）、図１０に示す処理手順を終了する。なお、実行部１３２は、加盟店に対して着金があった旨の情報提供を実施することについての承認を取得済みではないと判定した場合、利用者に対して、情報提供を承認するか否かの問合せを行ってもよい。
【0115】
上述のステップＳ１０１において、実行部１３２は、連携銀行サーバ２００から入金受付通知を受信していないと判定した場合（ステップＳ１０１；Ｎｏ）、図１０に示す処理手順を終了する。
【0116】
（３－２．決済サーバによる処理（その２））
以下、図１１を用いて、実施形態に係る決済サーバ１００により実行される情報処理（その２）の処理手順の一例を説明する。図１１は、実施形態に係る決済サーバ１００により実行される情報処理（その２）の処理手順例を示すフローチャートである。なお、図１１に示す処理手順は、決済サーバ１００が有する制御部１３０により実行される。制御部１３０は、決済サーバ１００の稼働中、図１１に示す処理手順を繰り返し実行する。
以下、図１１を用いて、実施形態に係る決済サーバ１００により実行される情報処理（その２）の処理手順の一例を説明する。図１１は、実施形態に係る決済サーバ１００により実行される情報処理（その２）の処理手順例を示すフローチャートである。なお、図１１に示す処理手順は、決済サーバ１００が有する制御部１３０により実行される。制御部１３０は、決済サーバ１００の稼働中、図１１に示す処理手順を繰り返し実行する。
【0117】
図１１に示すように、実行部１３２は、電子決済サービスの利用者からの要求に応じて、利用者端末１０で動作中の決済アプリ上に、着金に連動して利用者ウォレットから代金の支払いを行うことが可能なサービスの一覧を表示する（ステップＳ２０１）。
【0118】
また、実行部１３２は、対象利用者から、サービス選択および給与着金予定日を受け付けたか否かを判定する（ステップＳ２０２）。
【0119】
実行部１３２は、サービス選択および給与着金予定日を受け付けたと判定した場合（ステップＳ２０２；Ｙｅｓ）、対象利用者に対応付けて、対象利用者により選択されたサービスの提供元である加盟店への情報提供が承認済みであることを示す情報を、認可状態記憶部１２３に登録する（ステップＳ２０３）。
【0120】
また、実行部１３２は、着金予定日を示す情報を、対象利用者に関する利用者情報とともに、サービスの提供元である加盟店に提供して（ステップＳ２０４）、図１１に示す処理手順を終了する。
【0121】
上述のステップＳ２０２において、実行部１３２は、サービス選択および着金予定日を受け付けていないと判定した場合（ステップＳ２０２；Ｎｏ）、図１１に示す処理手順を終了する。
【0122】
（３－３．決済サーバによる処理（その３））
以下、図１２を用いて、実施形態に係る決済サーバ１００により実行される情報処理（その３）の処理手順の一例を説明する。図１２は、実施形態に係る決済サーバ１００により実行される情報処理（その３）の処理手順例を示すフローチャートである。なお、図１２に示す処理手順は、決済サーバ１００が有する制御部１３０により実行される。制御部１３０は、決済サーバ１００の稼働中、図１２に示す処理手順を繰り返し実行する。
以下、図１２を用いて、実施形態に係る決済サーバ１００により実行される情報処理（その３）の処理手順の一例を説明する。図１２は、実施形態に係る決済サーバ１００により実行される情報処理（その３）の処理手順例を示すフローチャートである。なお、図１２に示す処理手順は、決済サーバ１００が有する制御部１３０により実行される。制御部１３０は、決済サーバ１００の稼働中、図１２に示す処理手順を繰り返し実行する。
【0123】
図１２に示すように、実行部１３２は、連携銀行サーバ２００から入金受付通知を受信したか否かを判定する（ステップＳ３０１）。
【0124】
実行部１３２は、連携銀行サーバ２００から入金受付通知を受信したと判定した場合（ステップＳ３０１；Ｙｅｓ）、連携情報記憶部１２２を参照して、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者を特定する（ステップＳ３０２）。
【0125】
また、実行部１３２は、特定した対象利用者について、決済要求を受付済みであるか否かを判定する（ステップＳ３０３）。
【0126】
実行部１３２は、特定した対象利用者について、決済要求を受付済みであると判定した場合（ステップＳ３０３；Ｙｅｓ）、受付済みの決済要求が複数あるか否かを判定する（ステップＳ３０４）。
【0127】
実行部１３２は、受付済みの決済要求が複数あると判定した場合（ステップＳ３０４；Ｙｅｓ）、優先順位記憶部１２４に記憶されている支払優先順位に従って、決済要求に基づく決済処理を実行し（ステップＳ３０５）、図１２に示す処理手順を終了する。
【0128】
一方、実行部１３２は、受付済みの決済要求が複数ではなく単数であると判定した場合（ステップＳ３０４；Ｎｏ）、、決済要求に基づく決済処理を実行し（ステップＳ３０６）、図１２に示す処理手順を終了する。
【0129】
上述のステップＳ３０３において、実行部１３２は、特定した対象利用者について、決済要求を受付済みではないと判定した場合（ステップＳ３０３；Ｎｏ）、加盟店から送信される決済要求に応じて、決済処理を実行し（ステップＳ３０７）、図１２に示す処理手順を終了する。
【0130】
実行部１３２は、連携銀行サーバ２００から入金受付通知を受信していないと判定した場合（ステップＳ３０１；Ｎｏ）、図１２に示す処理手順を終了する。
【0131】
上記ステップＳ３０３において、実行部１３２は、対象利用者に対応する決済要求に、給与着金のタイミングに連動して即時の決済を要求することを示すフラグ情報が含まれていたか否かを判定してもよい。
【0132】
〔４．変形例〕
（４－１.給与着金予定日の候補日の提供について）
上述の実施形態で説明した決済サービスに対応する情報処理（その２）において、決済サーバ１００は、給与着金予定日を利用者から受け付ける代わりに、対象利用者の利用者端末１０で動作する決済アプリ上に、着金予定日の選択肢の候補を表示させ、対象利用者に選択させるようにしてもよい。この場合、決済サーバ１００は、対象利用者に対応する着金履歴から、対象利用者の給与着金予定日を予測し、予測した候補を着金予定日の選択肢として、対象利用者の決済アプリ上に表示させてもよい。
（４－１.給与着金予定日の候補日の提供について）
上述の実施形態で説明した決済サービスに対応する情報処理（その２）において、決済サーバ１００は、給与着金予定日を利用者から受け付ける代わりに、対象利用者の利用者端末１０で動作する決済アプリ上に、着金予定日の選択肢の候補を表示させ、対象利用者に選択させるようにしてもよい。この場合、決済サーバ１００は、対象利用者に対応する着金履歴から、対象利用者の給与着金予定日を予測し、予測した候補を着金予定日の選択肢として、対象利用者の決済アプリ上に表示させてもよい。
【0133】
（４－２.連携銀行から取得される給与の振込予約に応じた処理について）
上述の実施形態で説明した決済サービスに対応する情報処理（その３）において、決済サーバ１００は、連携銀行サーバ２００から、仮想口座を振込先とする給与振込の振込予約に応じた事前通知を受け付けてもよい。この場合、決済サーバ１００は、振込予約から把握可能な振込予定の給与の額と、着金予定の仮想口座に対応付けられている利用者ウォレットに記録されているその時点のマネー残高とに基づいて、加盟店から受付済みの決済要求に含まれる請求金額を清算できるか否かを確認してもよい。そして、決済サーバ１００は、着金予定の給与の額と、その時点のマネー残高を合わせても、請求金額の清算が難しい場合、その旨を対応する利用者ウォレットを保有する利用者に通知してもよい。
上述の実施形態で説明した決済サービスに対応する情報処理（その３）において、決済サーバ１００は、連携銀行サーバ２００から、仮想口座を振込先とする給与振込の振込予約に応じた事前通知を受け付けてもよい。この場合、決済サーバ１００は、振込予約から把握可能な振込予定の給与の額と、着金予定の仮想口座に対応付けられている利用者ウォレットに記録されているその時点のマネー残高とに基づいて、加盟店から受付済みの決済要求に含まれる請求金額を清算できるか否かを確認してもよい。そして、決済サーバ１００は、着金予定の給与の額と、その時点のマネー残高を合わせても、請求金額の清算が難しい場合、その旨を対応する利用者ウォレットを保有する利用者に通知してもよい。
【0134】
（４－３．手数料について）
上述の実施形態において、サービス事業者Ｘは、給与着金通知の送信を行うサービス（以下、「給与着金通知サービス」という。）を利用する加盟店Ｚから、所定の手数料を徴収してもよい。この場合、決済サーバ１００の制御部１３０（たとえば、実行部１３２）は、加盟店Ｚからの決済要求を受け付けると、決済要求に含まれる請求金額から給与着金通知サービスの利用に伴う所定の手数料の相当する額を減算した金額により決済処理を実行してもよい。また、サービス事業者Ｘは、給与着金の着金に連動して即時に実行する決済を行うサービス（以下、「給与着金連動決済サービス」という。）を希望する加盟店Ｚから、所定の手数料を徴収してもよい。この場合、決済サーバ１００の制御部１３０（たとえば、実行部１３２）は、加盟店Ｚからの決済要求を受け付けると、決済要求に含まれる請求金額から給与着金連動決済サービスの利用に伴う所定の手数料の相当する額を減算した金額により決済処理を実行してもよい。また、サービス事業者Ｘは、給与着金通知サービスを利用する際の手数料よりも、給与着金連動決済サービスを利用する際の手数料を高額に設定してもよい。
上述の実施形態において、サービス事業者Ｘは、給与着金通知の送信を行うサービス（以下、「給与着金通知サービス」という。）を利用する加盟店Ｚから、所定の手数料を徴収してもよい。この場合、決済サーバ１００の制御部１３０（たとえば、実行部１３２）は、加盟店Ｚからの決済要求を受け付けると、決済要求に含まれる請求金額から給与着金通知サービスの利用に伴う所定の手数料の相当する額を減算した金額により決済処理を実行してもよい。また、サービス事業者Ｘは、給与着金の着金に連動して即時に実行する決済を行うサービス（以下、「給与着金連動決済サービス」という。）を希望する加盟店Ｚから、所定の手数料を徴収してもよい。この場合、決済サーバ１００の制御部１３０（たとえば、実行部１３２）は、加盟店Ｚからの決済要求を受け付けると、決済要求に含まれる請求金額から給与着金連動決済サービスの利用に伴う所定の手数料の相当する額を減算した金額により決済処理を実行してもよい。また、サービス事業者Ｘは、給与着金通知サービスを利用する際の手数料よりも、給与着金連動決済サービスを利用する際の手数料を高額に設定してもよい。
【0135】
（４－４．システム構成について）
上述の実施形態では、情報処理システムＳＹＳに含まれる決済サーバ１００が、電子決済サービスに関する処理や、振込サービスに関する処理や、実施形態に係る決済サービスに対応する情報処理（図１～図３参照）を行う例を説明した。しかし、実施形態に係る情報処理システムＳＹＳの構成は、このような例には特に限定される必要はなく、電子決済サービスに関する処理を行うサーバ装置と、振分サービスに関する処理を行うサーバ装置と、実施形態に係る決済サービスとがそれぞれ物理的に異なる個別のサーバであってもよく、又は、それぞれのサーバ装置が異なるシステムに属するサーバ装置であってもよい。この場合、それぞれのサーバ装置が相互に連携して、それぞれの処理に必要な情報をやり取り可能な状態で通信可能に接続される。
上述の実施形態では、情報処理システムＳＹＳに含まれる決済サーバ１００が、電子決済サービスに関する処理や、振込サービスに関する処理や、実施形態に係る決済サービスに対応する情報処理（図１～図３参照）を行う例を説明した。しかし、実施形態に係る情報処理システムＳＹＳの構成は、このような例には特に限定される必要はなく、電子決済サービスに関する処理を行うサーバ装置と、振分サービスに関する処理を行うサーバ装置と、実施形態に係る決済サービスとがそれぞれ物理的に異なる個別のサーバであってもよく、又は、それぞれのサーバ装置が異なるシステムに属するサーバ装置であってもよい。この場合、それぞれのサーバ装置が相互に連携して、それぞれの処理に必要な情報をやり取り可能な状態で通信可能に接続される。
【0136】
また、上述の実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、逆に、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【0137】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【0138】
また、上記してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【0139】
〔５．効果〕
上述してきたように、実施形態に係る決済サーバ１００は、オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行する情報処理装置であって、連携情報記憶部１２２と、チャージ部１３１と、実行部１３２とを有する。連携情報記憶部１２２は、利用者に関する利用者情報と、前記利用者が会員として取引対象の提供を受ける前記加盟店の顧客である会員に関する会員情報とを予め関連付けた連携情報を記憶する。チャージ部１３１は、利用者が保有する電子ウォレットである利用者ウォレットに予め対応付けられている仮想口座に対する着金があった旨の通知を受け付けた場合、仮想口座に入金された入金額に相当する額の電子マネーを、着金が検知された仮想口座に対応付けられている利用者ウォレットにチャージする。実行部１３２は、着金があったの通知の受付、又は利用者ウォレットに対するマネー残高のチャージ処理の完了に応じて、連携情報を参照し、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者に対して予め関連付けられている加盟店を特定し、特定した加盟店に対して、対象利用者に対応する利用者情報とともに着金があった旨の通知を実行する。
上述してきたように、実施形態に係る決済サーバ１００は、オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行する情報処理装置であって、連携情報記憶部１２２と、チャージ部１３１と、実行部１３２とを有する。連携情報記憶部１２２は、利用者に関する利用者情報と、前記利用者が会員として取引対象の提供を受ける前記加盟店の顧客である会員に関する会員情報とを予め関連付けた連携情報を記憶する。チャージ部１３１は、利用者が保有する電子ウォレットである利用者ウォレットに予め対応付けられている仮想口座に対する着金があった旨の通知を受け付けた場合、仮想口座に入金された入金額に相当する額の電子マネーを、着金が検知された仮想口座に対応付けられている利用者ウォレットにチャージする。実行部１３２は、着金があったの通知の受付、又は利用者ウォレットに対するマネー残高のチャージ処理の完了に応じて、連携情報を参照し、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者に対して予め関連付けられている加盟店を特定し、特定した加盟店に対して、対象利用者に対応する利用者情報とともに着金があった旨の通知を実行する。
【0140】
また、実行部１３２は、代金の請求に関する決済要求を加盟店から受け付けた場合、決済要求に含まれる利用者情報に基づいて、代金の請求先となる対象利用者が保有する利用者ウォレットを特定し、特定した利用者ウォレットから、決済要求に含まれる請求金額に相当する額を、加盟店が保有する加盟店ウォレットに資金移動する決済処理を実行してもよい。
【0141】
また、実施形態に係る決済サーバ１００は、加盟店に対して着金があった旨の情報提供を実施することについて利用者から予め承認を得ているか否かを示す認可状態情報を記憶する認可状態記憶部１２３をさらに有していてもよい。実行部１３２は、着金があった旨の通知を受け付けた場合、認可状態情報を参照して、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者から承認を得ていることが確認されれることを条件として、対象利用者に代金の請求を行う加盟店に対して、対象利用者に関する利用者情報とともに、着金があった旨を通知してもよい。
【0142】
また、実行部１３２は、加盟店から予め設定される所定の期日までに、代金の請求先となる対象利用者について着金があった旨の通知が受け付けられなかった場合、対象利用者に代金の請求を行う加盟店に対して、代金の請求先となる対象利用者について、着金がなかった旨を通知してもよい。
【0143】
また、実行部１３２は、着金に連動して利用者ウォレットから代金の支払いを行う取引対象の選択を対象利用者から受け付けた場合、利用者により選択された取引対象の提供元である前記加盟店に対して、前記対象利用者に関する前記利用者情報を提供してもよい。
【0144】
また、実行部１３２は、取引対象の選択を利用者から受け付けたことを条件として、利用者に対応付けて前記承認を取得済みであることを示す情報を認可状態記憶部１２３に登録してもよい。
【0145】
また、実行部１３２は、取引対象の選択を利用者から受け付ける際、仮想口座に対する着金予定日を示す情報を利用者から受け付けて、受け付けた着金予定日を示す情報を、利用者情報とともに、取引対象の提供元である加盟店に提供してもよい。
【0146】
また、実施形態に係る決済サーバ１００は、オンラインシステムを通じて利用者に提供される電子決済サービスに関する処理を実行する情報処理装置であって、決済要求記憶部１２５と、チャージ部１３１と、実行部１３２とを有する。決済要求記憶部１２５は、利用者が会員として取引対象の提供を受ける電子決済サービスの加盟店から予め受け付けた決済要求に関する情報を記憶する。チャージ部１３１は、利用者が保有する電子ウォレットである利用者ウォレットに予め対応付けられている仮想口座に対する着金があった旨の通知を受け付けた場合、仮想口座に入金された入金額に相当する額の電子マネーを、着金が検知された仮想口座に対応付けられている利用者ウォレットにチャージする。実行部１３２は、着金があったの通知を受け付けた場合、決済要求記憶部１２５を参照して、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、決済要求を受付済みであるか否かを判定し、決済要求を受付済みであると判定した場合、決済要求に基づく決済処理を実行する。
【0147】
また、実行部１３２は、対象利用者について複数の決済要求がある場合、対象利用者により予め設定される優先順位に従って、決済処理を実行してもよい。
【0148】
また、実行部１３２は、対象利用者について決済要求に基づく決済処理を実行する際、決済要求に含まれる請求金額を参照し、対象利用者が保有する利用者ウォレットのマネー残高が請求金額に満たない場合、対象利用者に対して残高不足である旨を通知し、対象利用者が保有する利用者ウォレットの残高不足が解消されたことを契機として、決済要求に基づく決済処理を実行してもよい。
【0149】
また、実行部１３２は、利用者からの要求に応じて、利用者について受付済みの決済要求に関する情報を提供してもよい。
【0150】
また、実行部１３２は、加盟店から受付済みの決済要求に、着金のタイミングに連動して即時の決済を要求することを示すフラグ情報が含まれている場合、決済処理の完了に応じて、着金のタイミングに連動して決済が行われた旨の通知を対象利用者に通知してもよい。
【0151】
このように、実施形態に係る決済サーバ１００は、たとえば、加盟店が会員に対して取引対象の代金を請求するために、利用者ウォレットを通じて既に行われている決済処理を、給与着金通知の受付を契機として実行するため、給与着金通知とともに、着金があった仮想口座に対応付けられている利用者ウォレットを保有する対象利用者に関する利用者情報を加盟店Ｚに提供する。また、実施形態に係る決済サーバ１００は、たとえば、着金に連動して利用者ウォレットから代金の支払いを行うサービスを対象利用者に選択させ、選択されたサービスの提供元に対して、対象利用者に関する利用者情報を提供することにより情報連携を行う。また、実施形態に係る決済サーバ１００は、着金が検知された仮想口座に対応付けられている利用者ウォレットを保有する対象利用者について、決済要求を受付済みであるか否かを判定し、決済要求を受付済みであると判定した場合、加盟店から受付済みの決済要求に基づく決済処理を実行する。このようなことから、実施形態に係る決済サーバ１００によれば、加盟店からの要求に応じた決済処理を円滑に実行することができるという効果を奏する。
【0152】
〔６．ハードウェア構成〕
また、上述してきた実施形態または変形例に係る決済サーバ１００は、たとえば、図１３に示すような構成のコンピュータ１０００によって実現される。図１３は、実施形態または変形例に係る決済サーバ１００の機能を実現するコンピュータの一例を示すハードウェア構成図である。
また、上述してきた実施形態または変形例に係る決済サーバ１００は、たとえば、図１３に示すような構成のコンピュータ１０００によって実現される。図１３は、実施形態または変形例に係る決済サーバ１００の機能を実現するコンピュータの一例を示すハードウェア構成図である。
【0153】
コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。
【0154】
ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。
【0155】
ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（実施形態のネットワークＮに対応する）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、また、通信網５００を介してＣＰＵ１１００が生成したデータを他の機器へ送信する。
【0156】
ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。
【0157】
メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【0158】
例えば、コンピュータ１０００が変形例に係る決済サーバ１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部２３０の機能を実現する。すなわち、ＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラム（たとえば、情報処理プログラム）との協働により、実施形態または変形例に係る決済サーバ１００による処理を実現する。また、ＨＤＤ１４００には、決済サーバ１００の記憶装置内の各データが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から所定の通信網を介してこれらのプログラムを取得してもよい。
【0159】
〔７．その他〕
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【0160】
また、上述した決済サーバ１００は、機能によっては外部のプラットフォームなどをＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。
【0161】
また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。例えば、制御部は、制御手段や制御回路に読み替えることができる。
【符号の説明】
【0162】
ＳＹＳ 情報処理システム
１００ 決済サーバ
１１０ 通信部
１２０ 記憶部
１２１ 利用者情報記憶部
１２２ 連携情報記憶部
１２３ 認可状態記憶部
１２４ 選択サービス情報記憶部
１２５ 決済要求記憶部
１３０ 制御部
１３１ チャージ部
１３２ 実行部
２００ 連携銀行サーバ
３００ 加盟店サーバ
１００ 決済サーバ
１１０ 通信部
１２０ 記憶部
１２１ 利用者情報記憶部
１２２ 連携情報記憶部
１２３ 認可状態記憶部
１２４ 選択サービス情報記憶部
１２５ 決済要求記憶部
１３０ 制御部
１３１ チャージ部
１３２ 実行部
２００ 連携銀行サーバ
３００ 加盟店サーバ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】