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

Abstract

【課題】電子バリューによる報酬の支払いとこれに対応する原資の送金の柔軟な設計を図ることが可能な、プログラム、方法及び情報処理装置を提供する。【解決手段】決済処理システムによる報酬の支払に係る処理において、決済事業者のサーバ１１０Ａに含まれる１又は複数のプロセッサは、ユーザに対応付けられる報酬を管理する事業者に対応付けられた事業者のサーバ１１０Ｂから、報酬に関する情報（チャージ要求）を取得する。そしてユーザと報酬に関する情報とを対応づけ、チャージの合計額が限度額以上となった場合において、報酬の少なくとも一部に相当する額の電子バリューをユーザの残高にチャージし、所定の送金額の送金依頼を金融機関のサーバ１１０Ｃに送信する。【選択図】図５

Description

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

従業員等の労働者は事業者に対して労働力を提供し、従業員等はその対価として事業者から報酬が与えられる。報酬の支払いは、原則として、毎月一回以上、一定の期日を定めて現金で支払わなければならず、労働者の同意を得た場合には例外的に金融機関などへの入金で代替することができる。例えば特許文献１には、給料日前の従業員の資金需要に対応するための資金需要対応サービスとして、事業者が従業員へ貸付を行う技術が開示されている。

特開２０１７−１９１５９５号公報

従業員に対する報酬の支払方法としては、決済事業者が提供する決済サービスにおいて利用される電子バリューによる支払いも考えられる。このような電子バリューによって報酬を支払う場合、事業者は決済事業者に対して報酬の原資を提供する必要がある。当該原資の提供においては、銀行等の金融機関において開設された事業者の口座から、上記決済事業者の口座へと送金する場合が多い。しかしながら、当該送金に際しては手数料が発生する場合があり、送金の回数如何によっては事業者又は決済事業者の負担が重くなる場合がある。また、電子バリューでの報酬の支払いから原資の送金があるまでは、決済事業者は損金の状態となるため、報酬支払い及び原資送金それぞれのタイミングを適切に調整する仕組みに需要がある。

本開示は、電子バリューによる報酬の支払いとこれに対応する原資の送金の柔軟な設計を図ることが可能なプログラム、方法、及び情報処理装置を提供することを目的とする。

本開示の一実施形態に係る方法は、情報処理装置に含まれる１又は複数のプロセッサに、ユーザに対応付けられる報酬を管理する事業者に対応付けられた情報処理装置から、報酬に関する情報を取得する処理と、ユーザと報酬に関する情報とを対応づける処理と、所定のタイミングにおいて、報酬の少なくとも一部に相当する額の電子バリューをユーザの口座にチャージする処理と、事業者からの相当する額の送金の依頼を送信する処理と、を実行させる。

実施形態の一態様に係る決済処理システムの構成の一例、本開示に係るサーバのハードウェア構成の一例、本開示に係る端末のハードウェア構成の一例、及び実施形態に係る決済処理システムの構成を示すブロック図の一例を示す図である。 ユーザ情報のデータ構造の一例を示す図である。 事業者情報のデータ構造の一例を示す図である。 決済情報のデータ構造の一例を示す図である。 第１実施形態に係る決済処理システム１による事前設定に係る処理のシーケンスの一例を示す図である。 第１実施形態に係る決済処理システム１による報酬情報の共有に係る処理のシーケンスの他の一例を示す図である。 第１実施形態に係る決済処理システム１による報酬の支払に係る処理のシーケンスの一例を示す図である。 第１実施形態に係る決済処理システム１による清算に係る処理及び原資の送金に係る処理のシーケンスの一例を示す図である。 第１実施例に係る決済処理システム１による事前設定に係る処理のシーケンスの一例を示す図である。 第２実施例に係る決済処理システム１による報酬の支払い及び原資の送金に係る処理のシーケンスの一例を示す図である。 第３実施例に係る決済処理システム１による報酬の支払い及び原資の送金に係る処理のシーケンスの一例を示す図である。 第４実施例に係る決済処理システム１による報酬の支払い及び原資の送金に係る処理のシーケンスの一例を示す図である。

＜法令遵守＞
本明細書に記載の開示は、本開示を実施する各国の法令を遵守のうえで実施される。また、本明細書に記載の開示は、各国の法令を遵守するために必要な、当業者が成し得る全ての変更、置換、変形、改変、または修正をもって実施される。

本開示に係るプログラム、情報処理方法、及び情報処理装置を実施するための形態について、図面を参照して説明する。

＜システム構成＞
図１は、本開示の実施形態に係る決済処理システム１の構成を開示する。決済処理システム１では、ネットワーク１３０を介してサーバ１１０Ａ、サーバ１１０Ｂ、サーバ１１０Ｃと、端末１２０Ａ、端末１２０Ｂ、端末１２０Ｃとが接続される。

サーバ１１０Ａと、サーバ１１０Ｂと、サーバ１１０Ｃとをそれぞれ区別する必要がない場合は、サーバ１１０Ａとサーバ１１０Ｂとサーバ１１０Ｃとは、それぞれサーバ１１０と表現されてもよい。なお、ネットワーク１３０に接続されるサーバ１１０の数は限定されない。

端末１２０Ａと、端末１２０Ｂと、端末１２０Ｃとをそれぞれ区別する必要がない場合は、端末１２０Ａと端末１２０Ｂと端末１２０Ｃとは、それぞれ端末１２０と表現されてもよい。なお、ネットワーク１３０に接続される端末１２０の数は限定されない。

サーバ１１０と、端末１２０とをそれぞれ区別する必要がない場合は、サーバ１１０と端末１２０とは、それぞれ情報処理装置２００と表現されてもよい。なお、ネットワーク１３０に接続される情報処理装置２００の数は限定されない。

サーバ１１０は、ネットワーク１３０を介してユーザが利用する端末１２０に、所定のサービスを提供する。所定のサービスは、限定でなく例として、決済サービス、金融サービス、電子商取引サービス、インスタントメッセージングサービスを代表とするＳＮＳ（Social Networking Service）、楽曲・動画・書籍などのコンテンツ提供サービス等を含む。サーバ１１０は、単独で１以上の所定のサービスを提供してもよいし、複数で１以上の所定のサービスを提供してもよい。サーバ１１０が１以上の端末１２０に所定のサービスを提供することで、ユーザが端末１２０を介して所定のサービスを利用することができる。

決済サービスは、１以上のユーザが金銭または金銭相当物の授受ができるサービスを含む。決済サービスは、限定でなく例として、一次元コード（バーコードなど）、二次元コード（ＱＲコード（登録商標）など）（以下で、一次元コードおよび二次元コードをまとめて「二次元コード等」と総称する。）、近距離無線通信（ＮＦＣ (Near Field Communication)、ＢＬＥ（Bluetooth（登録商標） Low Energy）、Wi-Fi（登録商標）、超音波通信、赤外線通信など）を利用して決済を行うサービスを含む。また、代金の支払いを行うユーザ（支払者）の端末１２０が二次元コード等を読み取ることで決済を行うことを「ユーザ読取型コード決済」または「ＭＰＭ（Merchant Presented Mode）」と表現し、支払いを行うユーザの端末１２０が二次元コード等を表示し、表示された二次元コード等を、代金を請求する店舗側等のユーザ（販売者、請求者）の端末１２０が読み取ることで決済を行うことを「店舗読取型コード決済」または「ＣＰＭ（Consumer Presented Mode）」と表現する。なお、ＭＰＭおよびＣＰＭは、動的であってもよいし、静的であってもよい。

必要に応じて、ユーザＸが利用する端末を端末１２０Ｘと表現し、ユーザＸまたは端末１２０Ｘに対応づけられた、所定のサービスにおけるユーザに対応付けられた情報をユーザ情報Ｘと表現する。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報、ユーザに対応付けられた電子バリュー（電子マネー）の残高情報、ユーザに対応付けられたクレジットカード情報（クレジットカード番号など）等を含むことができる。

ネットワーク１３０は、２以上のサーバ１１０、又は２以上の端末１２０を接続する。ネットワーク１３０は、端末１２０がサーバ１１０に接続した後、データを送受信することができるように接続経路を提供する。

ネットワーク１３０の１以上の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワーク１３０は、限定でなく例として、アドホック・ネットワーク（Ad Hoc Network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（Virtual Private Network：ＶＰＮ）、ローカル・エリア・ネットワーク（Local Area Network：ＬＡＮ）、ワイヤレスＬＡＮ（Wireless LAN：ＷＬＡＮ）、広域ネットワーク（Wide Area Network：ＷＡＮ）、ワイヤレスＷＡＮ（Wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（Metropolitan Area Network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮｓ（Integrated Service Digital Networks）、無線ＬＡＮｓ、ＬＴＥ（Long Term Evolution）、ＣＤＭＡ（Code Division Multiple Access）、ブルートゥース（Bluetooth（登録商標））、衛星通信等であってよく、これらが組み合わせられてもよい。ネットワーク１３０は、１つまたは複数のネットワーク１３０を含むことができる。

サーバ１１０、及び端末１２０は、本開示に記載される機能および方法を実現できる情報処理装置であればどのような情報処理装置であってもよい。

サーバ１１０、及び端末１２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、サーバ装置、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダなど）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ（Personal Digital Assistant）、電子メールクライアントなど）、ウェアラブル端末（限定でなく例として、メガネ型デバイス、時計型デバイスなど）、他種のコンピュータ、またはコミュニケーションプラットホーム等であってよく、これらが組み合わせられてもよい。

＜ハードウェア構成＞
（１）サーバのハードウェア構成
図１を用いて、決済処理システム１に含まれるサーバ１１０のハードウェア構成について説明する。

サーバ１１０は、プロセッサ１１１と、メモリ１１２と、ストレージ１１３と、入出力インタフェース（入出力Ｉ／Ｆ）１１４と、入力装置１１５と、出力装置１１６と、送受信部１１７とを有する。サーバ１１０のハードウェアの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。

サーバ１１０は、プロセッサ１１１と、メモリ１１２と、ストレージ１１３と、入出力Ｉ／Ｆ１１４と、送受信部１１７５との協働により、本開示に記載される処理、機能、または、方法を実現する。

プロセッサ１１１は、ストレージ１１３に記憶されるプログラムに含まれるコード、または、命令によって実現する処理、機能、または、方法を実行する。プロセッサ１１１は、限定でなく例として、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示されるそれぞれの、処理、機能、または、方法を実現してもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。

メモリ１１２は、ストレージ１１３からロードしたプログラムを一時的に記憶し、プロセッサ１１１に対して作業領域を提供する。メモリ１１２には、プロセッサ１１１がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ１１２は、限定でなく例として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等であってよく、これらが組み合わせられてもよい。

ストレージ１１３は、プログラムや各種データを記憶する。ストレージ１１３は、限定でなく例として、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等であってよく、これらが組み合わせられてもよい。

入出力Ｉ／Ｆ１１４は、サーバ１１０に対する各種操作を入力する入力装置１１５、および、サーバ１１０で処理された処理結果を出力する出力装置１１６に接続する。

入力装置１１５は、ユーザからの入力を受け付けて、入出力Ｉ／Ｆ１１４を介し、当該入力に係る情報をプロセッサ１１１に伝達できる全ての種類の装置のいずれか、または、その組み合わせにより実現される。入力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（画像を介した操作入力）、マイク（音声による操作入力）等であってよく、これらが組み合わせられてもよい。

出力装置１１６は、入出力Ｉ／Ｆ１１４を介し、プロセッサ１１１で処理された処理結果を出力することができる全ての種類の装置のいずれか、または、その組み合わせにより実現される。当該処理結果を映像または動画像として出力する場合、出力装置１１６は、フレームバッファに書き込まれた表示データに従って、当該表示データを表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力装置１１６は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイ、ＯＥＬＤ（Organic Electroluminescence Display）など）、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよい）に画像やテキスト情報等を表示可能な装置、スピーカ（音声出力）、プリンター等であってよく、これらが組み合わせられてもよい。なお、これらの出力装置は、３Ｄで表示データを表示可能であってもよい。

なお、入力装置１１５と出力装置１１６が一体化していてもよいし、入力装置１１５と出力装置１１６とは分離していてもよい。

送受信部１１７は、ネットワーク１３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。送受信部１１７は、ネットワーク１３０を介して、他の情報処理装置との通信を実行する機能を有する。送受信部１１７は、各種データをプロセッサ１１１からの指示に従って、他の情報処理装置に送信する。また、送受信部１１７は、他の情報処理装置から送信された各種データを受信し、プロセッサ１１１に伝達する。

（２）端末のハードウェア構成
図１を用いて、決済処理システム１に含まれる端末１２０のハードウェア構成について説明する。

端末１２０は、プロセッサ１２１と、メモリ１２２と、ストレージ１２３と、入出力Ｉ／Ｆ１２４と、入力装置１２５と、出力装置１２６と、送受信部１２７とを有する。端末１２０のハードウェアの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。

端末１２０は、プロセッサ１２１と、メモリ１２２と、ストレージ１２３と、入出力Ｉ／Ｆ１２４と、入力装置１２５と、出力装置１２６と、送受信部１２７との協働により、本開示に記載される処理、機能、または、方法を実現する。

プロセッサ１２１は、ストレージ１２３に記憶されるプログラムに含まれるコードまたは命令によって実現する処理、機能、または、方法を実行する。プロセッサ１２１は、限定でなく例として、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示されるそれぞれの、処理、機能、または、方法を実現してもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。

メモリ１２２は、ストレージ１２３からロードしたプログラムを一時的に記憶し、プロセッサ１２１に対して作業領域を提供する。メモリ１２２には、プロセッサ１２１がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ１２２は、限定でなく例として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等であってよく、これらが組み合わせられてもよい。

ストレージ１２３は、プログラムや各種データを記憶する。ストレージ１２３は、限定でなく例として、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等であってよく、これらが組み合わせられてもよい。

入出力Ｉ／Ｆ１２４は、端末１２０に対する各種操作を入力する入力装置１２５、および、端末１２０で処理された処理結果を出力する出力装置１２６に接続する。

入力装置１２５は、ユーザからの入力を受け付けて、当該入力に係る情報をプロセッサ１２１に伝達できる全ての種類の装置のいずれか、または、その組み合わせにより実現される。入力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（画像を介した操作入力）、マイク（音声による操作入力）等であってよく、これらが組み合わせられてもよい。

出力装置１２６は、プロセッサ１２１で処理された処理結果を出力することができる全ての種類の装置のいずれか、または、その組み合わせにより実現される。当該処理結果を映像または動画像として出力する場合、出力装置は、フレームバッファに書き込まれた表示データに従って、当該表示データを表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイ、ＯＥＬＤ（Organic Electroluminescence Display）など）、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよい）に画像やテキスト情報等を表示可能な装置、スピーカ（音声出力）、プリンター等であってよく、これらが組み合わせられてもよい。なお、これらの出力装置は、３Ｄで表示データを表示可能であってもよい。

なお、入力装置１２５と出力装置１２６が一体化していてもよいし、入力装置１２５と出力装置１２６とは分離していてもよい。

送受信部１２７は、ネットワーク１３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。送受信部１２７は、ネットワーク１３０を介して、他の情報処理装置との通信を実行する機能を有する。送受信部１２７は、各種データをプロセッサ１２１からの指示に従って、他の情報処理装置に送信する。また、送受信部１２７は、他の情報処理装置から送信された各種データを受信し、プロセッサ１２１に伝達する。

（３）その他
１以上の情報処理装置で構成されるクラウドコンピューティングが、サーバ１１０、または、端末１２０における処理、機能、または、方法の少なくとも一部を実現してもよい。

他の情報処理装置が、サーバ１１０または端末１２０における処理、機能、または、方法の少なくとも一部を実現してもよい。この場合、他の情報処理装置のプロセッサが、プロセッサ１１１またはプロセッサ１２１により実現される処理のうち少なくとも一部の処理を実現してもよい。

本開示の各実施形態のプログラムは、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムを記憶可能である。プログラムは、限定でなく例として、ソフトウェアプログラムやコンピュータプログラム等であってよい。

記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定でなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カードもしくはドライブ、任意の他の適切な記憶媒体等であってよく、これらが組み合わせられてもよい。記憶媒体は、揮発性、不揮発性、または、揮発性と不揮発性の組合せでよい。

また、本開示のプログラムは、当該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して、サーバ１１０、または、端末１２０に提供されてもよい。

また、本開示の各実施形態は、プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

なお、本開示のプログラムは、限定でなく例として、JavaScript（登録商標）、Pythonなどのスクリプト言語、Ｃ言語、Ｇｏ言語、Swift、Kotlin、Java（登録商標）などを用いて実装されてもよい。

＜その他＞
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよい。

本開示は、本開示に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。また、添付の特許請求の範囲は、特許請求の範囲対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。さらに、本開示は、当業者が成し得る、本開示における実施形態または実施例の１以上の特徴と、本開示における他の実施形態または実施例の１以上の特徴との任意の組合せを包含する。

加えて、特定の機能を実施するように適合される、配置される、能力を有する、構成される、使用可能である、動作可能である、または動作できる装置またはシステムあるいは装置またはシステムの構成要素に対する添付の特許請求の範囲での参照は、その装置、システム、または構成要素がそのように適合される、配置される、能力を有する、構成される、使用可能にされる、動作可能にされる、または動作できる限り、その装置、システム、構成要素またはその特定の機能がアクティベートされ、オンにされ、またはロック解除されているか否かに関わらず、その装置、システム、構成要素を包含する。

本開示は、明示されない限り、いずれの実施形態または実施例を実施するに際して、事前に、または、実施の直前にユーザからの同意を取得してもよい。また、取得する同意は、包括的なものでもよく、都度取得するものでもよい。

＜第１実施形態＞
第１実施形態は、例えば、ユーザに対応付けられる報酬を管理する事業者に対応付けられた情報処理装置から報酬に関する情報を取得した上でこれをユーザに対応付け、所定のタイミングにおいて、報酬の少なくとも一部に相当する額の電子バリューをユーザの残高にチャージすると共に、事業者からの前記した相当する額の送金の依頼を送信する実施形態である。

第１実施形態により、電子バリューによる報酬の支払いとこれに対応する原資の送金の柔軟な設計を図ることが可能になるという効果が得られる。

＜第１実施形態の構成＞
図１を用いてサーバ１１０および端末１２０の構成を説明する。
（１）サーバの構成
サーバ１１０は、プロセッサ１１１と、メモリ１１２，ストレージ１１３と、入出Ｉ／Ｆ１１４と、入力装置１１５と、出力装置１１６と、送受信部１１７とを有する。

プロセッサ１１１により実行されて構成されうる決済処理部、情報管理部における機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Artificial Intelligence）などにより実現されてもよい。

入出力I／F１１４は、入力装置１１５または出力装置１１６を介して、サーバ１１０により提供される各種のサービスを運営する事業者からの各種の設定操作等を受け付ける。

送受信部１１７は、プロセッサ１１１の指示に従い、端末１２０とのデータの送受信を行う。なお、送受信部１１７は、例えば、端末１２０等からのログイン要求に含まれるユーザＩＤ、及びパスワードにより端末１２０等のユーザが認証された際、端末１２０等とのＨＴＴＰＳ等を用いた通信用のセッションを接続する。そして、接続した通信用のセッションのＩＤに対応付けて、端末１２０等の通信用のアドレス、及びユーザＩＤ等を記憶しておく。そして、接続した通信用のセッションを用いて、端末１２０等にデータを送信する。

プロセッサ１１１は、所定のサービスを端末１２０のユーザに提供する処理を行う。

メモリ１１２は、ある実施形態において、次のプログラム１１２１、モジュール及びデータ構造、又はそれらのサブセットを格納する。

プログラム１１２１は、上述したとおり、ストレージ１１３からロードされたプログラムであって、開示の実施形態等に関する命令等が含まれる。

図２Ａは、ユーザ情報１１２２のデータ構造の一例を示す図である。図２Ａに示すとおり、ユーザ情報１１２２は、限定でなく例として、ユーザＩＤ、事業者ＩＤ、アクセストークン、報酬情報、及びユーザ信用スコア等を含む。ユーザＩＤは、ユーザを識別するための識別情報（ＩＤ）を含む。事業者ＩＤは、当該ユーザに報酬を支払う事業者を識別するための識別情報（ＩＤ）を含む。なお、ユーザが複数の事業者それぞれから報酬の提供を受ける場合に対応して、ユーザＩＤに複数の事業者ＩＤが対応付けられてもよい。

アクセストークンは、報酬管理アプリ等のクライアントアプリケーションが、決済管理アプリに係るユーザのデータを利用することを許可されていることを示すトークンを含む。アクセストークンを発行するためのプロトコルは、特に限定されないが、例えば、ＯＡｕｔｈ等であってよい。後述するように、ユーザがデータを利用することを所定のクライアントアプリケーションに許可した場合、当該アクセストークンがクライアントアプリケーションに提供される。報酬情報は、事業者からユーザに対して提供される報酬に関する情報を含む。

報酬情報は、例えば、報酬の額、当該報酬の対象となる期間等を含んでよい。

ユーザ信用スコアは、当該ユーザの信用スコアである。ユーザの信用スコアは、例えば、当該ユーザが決済元又は決済先となる電子バリューの決済に関する情報に基づいて算出されてもよい。決済に関する情報は、例えば、決済額や決済回数等に関する情報であってよい。決済額に関する情報としては、例えば、決済額の代表値（単価、平均値、及び中央値等）等であってよい。また、ユーザ信用スコアは、例えば、当該ユーザが決済元となる電子バリューの決済の決済先の信用スコアや、当該ユーザが決済先となる電子バリューの決済の決済元の信用スコア等に基づいて算出されてもよい。また、ユーザ信用スコアは、当該ユーザに報酬を提供する事業者の事業者信用スコアに基づいて算出されてもよい。また、ユーザ信用スコアは、金融機関における当該ユーザの口座の残高に基づいて算出されてもよい。また、ユーザ信用スコアは外部から当該スコアが取得されるように構成されてもよい。

図２Ｂは、事業者情報１１２３のデータ構造の一例を示す図である。図２Ｂに示すとおり、事業者情報１１２３は、限定でなく例として、事業者ＩＤ、評価情報、事業者信用スコア、及び原資送金方式等を含む。事業者ＩＤは、事業者を識別するための識別情報（ＩＤ）を含む。評価情報は、ユーザ等が入力した当該事業者に対する評価に関する情報を含む。評価情報は、例えば、待遇面の満足度、社員の士気、風通しの良さ、成長環境、育成環境、法令遵守意識、及び評価の適性度等を含んでもよい。

事業者信用スコアは、当該事業者の信用スコアを含む。事業者信用スコアは、例えば、当該事業者が決済元又は決済先となる電子バリューの決済に関する情報に基づいて算出されてもよい。決済に関する情報は、例えば、決済額や決済回数等に関する情報であってよい。決済額に関する情報としては、例えば、決済額の代表値（単価、平均値、及び中央値等）等であってよい。また、事業者信用スコアは、例えば、当該事業者が決済元となる電子バリューの決済の決済先の信用スコアや、当該事業者が決済先となる電子バリューの決済の決済元の信用スコア等に基づいて算出されてもよい。また、事業者信用スコアは、当該事業者が管理する報酬に対応付けられたユーザのユーザ信用スコアに基づいて算出されてもよい。また、事業者信用スコアは、金融機関における当該事業者の口座の残高に基づいて算出されてもよい。

原資送金方式は、事業者から決済事業者への原資の送金方法について規定した方式を含む。原資送金方式は、任意に設定可能であるが、例えば、バルク方式、デポジット方式、及び都度方式等を含んでもよい。ここで、バルク方式は、電子バリューでの報酬のチャージの合計額が限度額以上となった場合に、所定金額の原資の送金処理が実行される方式を含む。当該限度額は、任意に設定可能であるが、例えば当該事業者の信用スコアに基づいて算出されてもよい。また、デポジット方式は、予め金融機関における事業者の口座から決済事業者の口座にデポジットとして所定額を入金しておき、当該デポジットを原資として、電子バリューでの報酬のチャージを実行する方式を含む。当該方式では、チャージが実行される度に当該デポジットを減算していき、デポジットの残高が所定額未満となった場合に、追加のデポジットとして原資の送金処理が実行されてよい。なお、所定額は事業者の信用スコアに基づいて算出されてもよい。また、都度方式は、電子バリューでの報酬のチャージの要求がある度に、原資の送金処理が実行される方式を含む。

原資送金方式は、事業者信用スコアに基づいて、決定されてもよい。例えば、それぞれの原資送金方式について基準値を定めておき、事業者信用スコアが当該基準値以上である事業者に限り当該原資送金方式を採用可能としてもよい。この場合、基準値が高い順に、バルク方式、都度方式、及びデポジット方式としてもよい。

図２Ｃは、決済情報１１２４のデータ構造の一例を示す図である。図２Ｃに示すとおり、決済情報１１２４は、決済事業者取引ＩＤ、事業者取引ＩＤ、決済元、決済先、決済額、決済日時、及びステータス等を含む。決済事業者取引ＩＤは、決済事業者が発行する取引ＩＤを含む。事業者取引ＩＤは、事業者が発行する取引ＩＤを含む。決済元は、電子バリューの送金元を示す情報（ユーザＩＤ及び事業者ＩＤ等）を含む。なお、決済事業者が特定のユーザ又は事業者に電子バリューをチャージする場合は、当該決済元は空欄のままであってもよい。決済先は、電子バリューの送金先を示す情報（ユーザＩＤ及び事業者ＩＤ等）を含む。決済額は、電子バリューの送金額を示す情報を含む。決済日時は、電子バリューの送金日時を示す情報を含む。

決済処理モジュール１１２５は、電子マネーによる決済に関する処理を実行する。例えば、決済処理モジュール１１２５は、報酬管理アプリ等のクライアントアプリケーションが、決済管理アプリに係るユーザのデータを利用することを許可されていることを示すトークンであるアクセストークンを発行する。また、決済処理モジュール１１２５は、ユーザの許可が取得された場合等に、決済処理モジュール１１２５又は他の認可サーバが発行したアクセストークンを、事業者のサーバ１１０Ｂ等に送信する。また、決済処理モジュール１１２５は、ユーザの許可が取得された場合等に、決済事業者が管理するユーザＩＤを事業者のサーバ１１０Ｂ等に送信する。また、決済処理モジュール１１２５は、チャージ要求を受信すると、所定の判定処理を実行した上で、ユーザに所定額（例えば、希望チャージ額等）の電子バリューを対応付ける（チャージする）チャージ処理を実行する。また、決済処理モジュール１１２５は、チャージ結果をユーザの端末１２０や事業者のサーバ１１０Ｂ等に送信する。

情報管理モジュール１１２６は、ユーザや事業者に関する種々の情報の管理に関する処理を実行する。例えば、情報管理モジュール１１２６は、事業者のサーバ１１０Ｂから報酬情報を受信し、当該報酬情報をメモリ１１２に記録する。また、情報管理モジュール１１２６は、報酬に関する通知をユーザの端末１２０に送信する。当該通知の内容は、報酬に関するものであれば特に限定されないが、例えば、報酬が利用可能になった旨や、報酬額が確定した旨等を含んでもよい。また、当該通知の内容は、報酬が利用可能になるタイミングを知らせるものであってもよい。また、情報管理モジュール１１２６は、事業者信用スコアやユーザ信用スコアの算出に必要なパラメータを適宜取得し、事業者信用スコアやユーザ信用スコアを算出する。事業者信用スコアやユーザ信用スコアの算出処理が実行されるタイミングは、特に限定されず、例えば、定期的（時間毎、日毎、週毎、月毎、年毎等）なタイミングや、不定期のタイミングの他、事業者信用スコア及び／又はユーザ信用スコアを規定する上述したパラメータのいずれかに変更があったタイミング等を含んでもよい。

送金管理モジュール１１２７は、金融機関における口座間の送金に関する処理を実行する。例えば、送金管理モジュール１１２７は、所定の条件下において、所定の送金額の送金依頼を金融機関のサーバ１１０Ｃに送信する。当該送金額は、原資送金方式に基づいて算出されてよい。例えば、原資送金方式がバルク方式の場合、当該所定の送金額はチャージの合計額或いは限度額に相当する（同一の他、手数料等を調整する場合を含む）額であってよい。また、原資送金方式がデポジット方式の場合、当該所定の送金額は予め規定された追加のデポジット額に相当する額であってよい。また、原資送金方式が都度方式の場合、当該所定の送金額は希望チャージ額に相当する額であってよい。

なお、１つ又は複数のプロセッサ１１１は、メモリ１１２から、必要に応じて各モジュールを読み出して実行する。例えば、１つ又は複数のプロセッサ１１１は、決済処理モジュール１１２５、情報管理モジュール１１２６、及び送金管理モジュール１１２７それぞれを実行することで、決済処理部、情報管理部、及び送金管理部を構成してもよい。また、ユーザ情報１１２２、事業者情報１１２３、及び決済情報１１２４の少なくとも一部は、ストレージ１１３に記憶されてもよい。また、決済処理モジュール１１２５、情報管理モジュール１１２６、及び送金管理モジュール１１２７の少なくとも一部は、ストレージ１１３に記憶されてもよい。

（２）端末１２０の構成
端末１２０は、プロセッサ１２１と、メモリ１２２と、ストレージ１２３と、入出力Ｉ／Ｆ１２４と、入力装置１２５と、出力装置１２６と、送受信部１２７と、を有する。

プロセッサ１２１により実行されて構成されうる決済処理部又は表示制御部における機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Artificial Intelligence）などにより実現されてもよい。

入力装置１２５は、端末１２０のユーザからの各種の操作等を受け付ける。

送受信部１２７は、プロセッサ１２１の指示に従い、サーバ１１０等とのデータの送受信を行う。なお、送受信部１２７は、例えば、サーバ１１０にログインした際、サーバ１１０とのＨＴＴＰＳ等を用いた通信用のセッションを接続する。そして、接続した通信用のセッションのＩＤに対応付けて、サーバ１１０の通信用のアドレス等を記憶しておく。そして、接続した通信用のセッションを用いて、サーバ１１０にデータを送信する。

プロセッサ１２１は、サーバ１１０により提供される所定のサービスを利用する処理を行う。

メモリ１２２は、ある実施形態において、次のプログラム１２２１、モジュール及びデータ構造、又はそれらのサブセットを格納する。

プログラム１２２１は、上述したとおり、ストレージ１２３からロードされたプログラムであって、各実施形態に関する命令等が含まれる。

決済情報１２２２は、上述したサーバ１１０Ａのメモリ１１２が記憶する決済情報１１２４と同様のデータ構造を有していてもよい。

決済処理モジュール１２２３は、電子マネーによる決済に関する処理を実行する。例えば、決済処理モジュール１２２３は、ユーザによる入力装置１２５の操作に応じて、事業者がユーザに対して電子バリューにより報酬を支払うことを許可する許可通知を、決済事業者のサーバ１１０Ａに送信する。また、例えば、決済処理モジュール１２２３は、ユーザによる入力装置１２５の操作に応じて、事業者がユーザに対して電子バリューにより報酬を支払うことが可能となるように、ユーザＩＤを事業者のサーバ１１０Ｂに送信する。また、例えば、決済処理モジュール１２２３は、ユーザによる入力装置１２５の操作に応じて、電子バリューでの報酬の支払の要求であるチャージ要求を決済事業者のサーバ１１０Ａに送信する。

表示制御モジュール１２２４は、決済に関する画面データを、出力装置１２６に表示するよう制御する。例えば、表示制御モジュール１２２４は、二次元コード等を読み取る画面を制御したり、決済情報を送信する画面を制御したり、決済の完了を通知する画面を制御したりする。

なお、１つ又は複数のプロセッサ１２１は、メモリ１２２から、必要に応じて各モジュールを読み出して実行する。例えば、１つ又は複数のプロセッサ１２１は、決済処理モジュール１２２３、表示制御モジュール１２２４それぞれを実行することで、決済処理部、表示制御部を構成してもよい。また、決済情報１２２２の少なくとも一部は、ストレージ１２３に記憶されてもよい。また、決済処理モジュール１２２３、及び表示制御モジュール１２２４の少なくとも一部は、ストレージ１２３に記憶されてもよい。

なお、以下では、端末１２０において実行される、事業者から提供される報酬を管理するアプリケーションを「報酬管理アプリ」と称する場合がある。また、以下では、端末１２０において実行される、決済事業者によって提供される決済サービスを利用するためのアプリケーションを「決済管理アプリ」と称する場合がある。これら報酬管理アプリや決済管理アプリはそれぞれ、メモリ１２２等に記憶された各種のモジュールによって構成され得る。

＜第１実施形態の動作処理＞
図３〜６を参照し、第１実施形態に係る決済処理システム１の処理について説明する。

（１）事前設定
図３は、第１実施形態に係る決済処理システム１の事前設定に係る処理のシーケンスの一例を示す。当該シーケンスでは、事業者がユーザに対して電子バリューによって報酬を支払うことが可能となるように、所定の認可サーバ（決済事業者のサーバ１１０Ａを含む）により発行されたアクセストークン等の識別情報が事業者のサーバ１１０Ｂに共有される。このように、アクセストークン等の識別情報を用いることで、決済事業者（のサーバ１１０Ａ）と事業者（のサーバ１１０Ｂ）との間で、ユーザの個人情報等を共有することなく、電子バリューでの報酬の支払を実行することが可能となる。

（ステップＳ１０１）まず、ユーザは、入力装置１２５を介して、報酬管理アプリを起動した上で、電子バリューによる報酬の支払いを可能とするための設定操作を行う。これにより、端末１２０Ａの表示制御モジュール１２２４は、決済管理アプリを起動し、電子バリューによる報酬の支払いの許可を入力するための画面を出力装置１２６に表示させる。そして、ユーザが入力装置１２５を介して、電子バリューによる報酬の支払いの許可を入力すると、端末１２０Ａの決済処理モジュール１２２３は、許可通知を決済事業者のサーバ１１０Ａに送信する。

（ステップＳ１０２）決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、ユーザの端末１２０Ａから許可通知を受信すると、所定の認可サーバ（サーバ１１０Ａであってもよい)によって発行されたアクセストークンを事業者のサーバ１１０Ｂに送信する。当該アクセストークンは、報酬管理アプリ等のクライアントアプリケーションが、決済管理アプリに係るユーザのデータを利用することを許可されていることを示すトークンである。

（ステップＳ１０３）次に、事業者のサーバ１１０Ｂは、決済事業者のサーバ１１０Ａからアクセストークンを受信すると、当該アクセストークンをユーザに関する情報に対応付けてメモリ１１２等に記録する。事業者のサーバ１１０Ｂは、当該アクセストークンを用いて、サーバ１１０Ａが管理する決済管理アプリに係るユーザのデータを利用するこが可能となる。以上で、事前設定に係る処理のシーケンスが終了する。

（２）報酬情報の通知
図４は、第１実施形態に係る決済処理システム１による報酬情報の共有に係る処理のシーケンスの一例を示す図である。当該シーケンスでは、事業者がユーザに対して支払うべき報酬に関する情報（報酬情報）が決済事業者に共有される。これにより、ユーザは後述する報酬の電子バリューでの支払を要求することが可能となる。

（ステップＳ２０１）まず、事業者のサーバ１１０Ｂは、所定のタイミングにおいて、ユーザの報酬に関する情報（報酬情報）を決済事業者のサーバ１１０Ａに送信する。当該所定のタイミングは特に限定されないが、例えば、定期的なタイミングや、事業者とユーザとの契約等の取決めにしたがった報酬額の確定時、サーバ１１０Ｂがユーザからのリクエストを受信したタイミング等であってよい。報酬情報は報酬額に関する情報を含む。

（ステップＳ２０２）決済事業者のサーバ１１０Ａの情報管理モジュール１１２６は、サーバ１１０Ｂから報酬情報を受信（取得）すると、当該報酬情報に含まれる各種の情報（報酬額等）をメモリ１１２に記録する。

（ステップＳ２０３）決済事業者のサーバ１１０Ａの情報管理モジュール１１２６は、報酬に関する通知をユーザの端末１２０Ａに送信する。当該通知の内容は、報酬に関するものであれば特に限定されないが、例えば、報酬が利用可能になった旨や、報酬額が確定した旨等を含んでもよい。また、当該通知の内容は、報酬が利用可能になるタイミングを知らせるものであってもよい。端末１２０Ａの表示制御モジュール１２２４は、当該通知に基づいて報酬額等の報酬に関する情報を出力装置１２６に表示してもよい。以上で、報酬情報の通知に係るシーケンスが終了する。

（３）報酬の支払い及び原資の送金
図５は、第１実施形態に係る決済処理システム１による報酬の支払に係る処理及び原資の送金に係る処理のシーケンスの一例を示す図である。当該シーケンスでは、所定のタイミングにおいて電子バリューによる報酬の支払いが実行される。また、原資送金方式は、バルク方式であり、電子バリューでの報酬のチャージの合計額が限度額以上となった場合に、原資の送金処理が実行される。これにより、電子バリューでの報酬のチャージの度に原資の送金処理を実行する必要がなくなるため、処理の簡素化が図られ、また、原資の送金により発生する手数料の負担を軽減することが可能となる。

（ステップＳ３０１）報酬の少なくとも一部が電子バリューで支払われることを望むユーザは、任意のタイミングで、入力装置１２５を操作することにより報酬管理アプリを起動し、チャージを希望する額（希望チャージ額）及びその旨を入力する。これにより、端末１２０Ａの決済処理モジュール１２２３は、希望チャージ額を含むチャージ要求を、事業者のサーバ１１０Ｂに送信する。

（ステップＳ３０２）事業者のサーバ１１０Ｂは、端末１２０Ａからチャージ要求を受信すると、希望チャージ額の報酬が利用可能であるか否かを判定する。希望チャージ額の報酬が利用可能でないと判定された場合、サーバ１１０Ｂは端末１２０Ａにエラー通知を送信等した上で処理が終了する。

（ステップＳ３０３）希望チャージ額の報酬が利用可能であると判定された場合、事業者のサーバ１１０Ｂは、事業者取引ＩＤを発行し、当該事業者取引ＩＤと、希望チャージ額等のチャージ要求に含まれる情報とを対応付けてメモリ１１２等に記録する。

（ステップＳ３０４）次に、事業者のサーバ１１０Ｂは、チャージ要求を決済事業者のサーバ１１０Ａに送信する。当該チャージ要求は、アクセストークン、希望チャージ額、及び事業者取引ＩＤを含む。なお、決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、事業者のサーバ１１０Ｂからチャージ要求を受信した場合、アクセストークンの更新に係る処理を実行してもよい。例えば、決済処理モジュール１１２５は、ユーザの端末１２０Ａに、電子バリューでの報酬の支払の許可を要求し、ユーザによる当該許可を受信すると、新たに発行されたアクセストークンを事業者のサーバ１１０Ｂに送信してもよい。

（ステップＳ３０５）決済事業者のサーバ１１０Ａの情報管理モジュール１１２６は、チャージ要求を送信した事業者のサーバ１１０Ｂに係る事業者信用スコアを算出する。情報管理モジュール１１２６は、例えば、決済情報１１２４を参照して、当該事業者が決済元又は決済先となる電子バリューの決済に関する情報に基づいて事業者信用スコアを算出してもよい。当該決済に関する情報は、例えば、決済額や決済回数等に関する情報であってよい。また、当該決済額に関する情報としては、例えば、決済の合計金額、平均金額、及び中央値金額等であってよい。また、情報管理モジュール１１２６は、例えば、決済情報１１２４を参照して、当該事業者が決済元となる電子バリューの決済の決済先の信用スコアや、当該事業者が決済先となる電子バリューの決済の決済元の信用スコア等に基づいて事業者信用スコアを算出してもよい。また、情報管理モジュール１１２６は、例えば、当該事業者が管理する報酬に対応付けられたユーザのユーザ信用スコアに基づいて事業者信用スコアを算出してもよい。また、情報管理モジュール１１２６は、例えば、金融機関における当該事業者の口座の残高に基づいて事業者信用スコアを算出してもよい。

なお、事業者信用スコアの算出処理は、上述したステップＳ３０５のタイミングに限らず、任意のタイミングにおいて実行されてもよい。当該任意のタイミングは、例えば、定期的（時間毎、日毎、週毎、月毎、年毎等）なタイミングや、不定期のタイミングの他、事業者信用スコアを規定する上述したパラメータのいずれかに変更があったタイミング等を含んでもよい。

（ステップＳ３０６）決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、事業者のサーバ１１０Ｂからチャージ要求を受信すると、アクセストークンによってユーザを特定した上で、所定の判定処理を実行する。決済処理モジュール１１２５は、チャージの合計額（ステップＳ３０４で受信したチャージ要求に含まれる希望チャージ額を合計した額）が当該事業者について設定された限度額以上となるか否かを判定する。

（ステップＳ３０７）チャージの合計額が当該事業者について設定された限度額以上となると判定された場合（Ｓ３０７；Ｙｅｓ）、サーバ１１０Ａの送金管理モジュール１１２７は、所定の送金額の送金依頼を金融機関のサーバ１１０Ｃに送信する。当該所定の送金額はチャージの合計額或いは限度額に相当する（同一の他、手数料等を調整する場合を含む）額であってよい。

（ステップＳ３０８）金融機関のサーバ１１０Ｃは、サーバ１１０Ａから送金依頼を受信すると、当該送金依頼に基づいて送金依頼に含まれる送金額を事業者口座から決済事業者口座へ送金する処理（送金処理）を実行する。

（ステップＳ３０９）次に、金融機関のサーバ１１０Ｃは、送金処理結果を決済事業者のサーバ１１０Ａに送信する。なお、決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、金融機関のサーバ１１０Ｃから送金処理結果を受信すると、チャージの合計額から上述した限度額を減算する。

（ステップＳ３１０）次に、決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、電子バリューでの報酬の支払として、ユーザの残高に希望チャージ額の電子バリューをチャージする。具体的には、決済処理モジュール１１２５は、決済事業者取引ＩＤを発行し、当該決済事業者取引ＩＤに、事業者のサーバ１１０Ｂから受信した事業者取引ＩＤと、チャージに関する情報（例えば希望チャージ額等）とを対応付けて、決済情報に記録する。

（ステップＳ３１１）次に、決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、ユーザの端末１２０Ａに、チャージ処理結果を送信する。当該チャージ処理結果は、決済額や決済日時に関する情報を含んでもよい。

（ステップＳ３１２）また、決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、事業者のサーバ１１０Ｂに、チャージ処理結果を送信する。当該チャージ処理結果は、決済額や決済日時に関する情報を含んでもよい。また、当該チャージ処理結果は、決済事業者取引ＩＤと、事業者取引ＩＤとを含んでもよい。なお、事業者のサーバ１１０Ｂは、サーバ１１０Ａから受信したチャージ結果を、サーバ１１０Ｂが管理している情報と照合し、当該照合の結果を決済事業者のサーバ１１０Ａに送信してもよい。以上で、報酬の支払い及び原資の送金に係るシーケンスが終了する。

（４）清算
図６は、第１実施形態に係る決済処理システム１による清算に係る処理のシーケンスの一例を示す図である。当該シーケンスでは、例えば、所定期間においてユーザに対してチャージされた報酬の額と、当該所定期間において金融機関における事業者の口座から決済事業者の口座へ送金された原資の額との差分が清算される。

（ステップＳ４０１）まず、決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、所定期間の期末日時が到来したか否かを判定する。

（ステップＳ４０２）期末日時が到来したと判定された場合（ステップＳ４０１；Ｙｅｓ）、サーバ１１０Ａの決済処理モジュール１１２５は、所定の送金額の送金依頼を金融機関のサーバ１１０Ｃに送信する。ここで、当該所定の送金額は、所定期間におけるチャージの合計額から、当該所定期間において金融機関における事業者の口座から決済事業者の口座へ送金された額の合計額を差し引いた額であってよい。

（ステップＳ４０３）金融機関のサーバ１１０Ｃは、サーバ１１０Ａから送金依頼を受信すると、当該送金依頼に基づいて送金依頼に含まれる送金額を事業者口座から決済事業者口座へ送金する処理（送金処理）を実行する。

（ステップＳ４０４）次に、金融機関のサーバ１１０Ｃは、送金処理結果を決済事業者のサーバ１１０Ａに送信する。以上で、清算に係る処理のシーケンスが終了する。

＜＜第１実施例＞＞
第１実施例は、事業者がユーザに対して電子バリューによって報酬を支払うことが可
能となるように、決済事業者のサーバ１１０Ａが管理するユーザＩＤが事業者のサーバ
１１０Ｂに共有される実施例である。換言すれば、上述の実施形態に開示するアクセス
トークンに代えて、ユーザＩＤを用いる実施例である。
＜＜第１実施例の効果＞＞
第１実施例によれば、アクセストークンの発行に関する処理やこれを実行する情報処理装置が不要となることで、決済処理システム１の構成を簡素化する効果が得られる。
＜＜第１実施例の構成＞＞
第１実施例に係るシステム構成や、サーバ、端末の構成等は、基本的に第１実施形態
に係るシステム構成や、サーバ、端末の構成等と同様である。
＜＜第１実施例の動作処理＞＞

図７は、第１実施例に係る決済処理システム１による事前設定に係る処理のシーケンスの一例を示す図である。第１実施例においては、上述した「（１）事前設定」に係るシーケンスに代えて、以下のシーケンスが実行される。

（ステップＳ５０１）まず、ユーザは、入力装置１２５を介して、決済事業者が管理するユーザＩＤを事業者に共有するための操作を行う。例えば、ユーザは、報酬管理アプリの設定画面等においてユーザＩＤを入力し、当該ユーザＩＤを事業者に提供することを選択する。

（ステップＳ５０２）次に、端末１２０Ａの決済処理モジュール１２２３は、入力されたユーザＩＤを事業者のサーバ１１０Ｂに送信する。

なお、ステップＳ１０４〜Ｓ１０５に代えて、端末１２０Ａにおいて報酬管理アプリが決済管理アプリを起動させた上で、ユーザによる所定の操作に応じて端末１２０Ａの決済処理モジュール１２２３が許可通知を決済事業者のサーバ１１０Ａに送信し、当該許可通知を受信したサーバ１１０Ａの決済処理モジュール１１２５が、ユーザＩＤを事業者のサーバ１１０Ｂに送信してもよい。ユーザによる所定の操作としては、具体的には、決済管理アプリにおいてユーザＩＤの共有の許可を入力するための画面が表示され、ユーザがユーザＩＤの共有を選択するものであってもよい。或いは、当該報酬管理アプリがユーザＩＤの共有を選択するための所定のコード（ＱＲコード等の二次元コード等であってよい）を表示し、ユーザが当該コードを端末１２０Ａのカメラ等の入力装置１２５によって読み取るものであってもよい。

（ステップＳ５０３）事業者のサーバ１１０Ｂは、ユーザの端末１２０ＡからユーザＩＤを受信すると、当該ユーザＩＤをユーザに関する情報に対応付けてストレージ１１３等に保存する。以上で、事前設定に係る処理のシーケンスが終了する。

第１実施例においては、例えば、上述した「（３）報酬の支払い及び原資の送金」のステップＳ３０４で送信されるチャージ要求は、アクセストークンに代えてユーザＩＤを含んでもよい。また、第１実施例においては、例えば、上述した「（３）報酬の支払い及び原資の送金」のステップＳ３０６では、決済処理モジュール１１２５は、チャージ要求に含まれるユーザＩＤによってユーザを特定してもよい。

＜＜第２実施例＞＞
第２実施例は、原資送金方式がデポジット方式であり、予め金融機関における事業者
の口座から決済事業者の口座にデポジットとして所定額を入金しておき、当該デポジッ
トを原資として電子バリューでの報酬のチャージが実行される実施例である。

＜＜第２実施例の効果＞＞
第２実施例によれば、これにより、電子バリューでの報酬のチャージの度に原資の送金処理を実行する必要がなくなるため、処理の簡素化が図られ、また、原資の送金により発生する手数料の負担を軽減することが可能となる。更に、第２実施例によれば、電子バリューでの報酬のチャージに先駆けて、予め事業者から決済事業者に対してデポジットが提供されるため、例えば事業者信用スコアが比較的低い事業者に対しても、電子バリューでの報酬のチャージを許可することが可能となる。
＜＜第２実施例の構成＞＞
第２実施例に係るシステム構成や、サーバ、端末の構成等は、基本的に第１実施形態
に係るシステム構成や、サーバ、端末の構成等と同様である。
＜＜第２実施例の動作処理＞＞

図８は、第２実施例に係る決済処理システム１による報酬の支払い及び原資の送金に係る処理のシーケンスの一例を示す図である。第２実施例においては、上述した「（３）報酬の支払い及び原資の送金」に係るシーケンスに代えて、以下のシーケンスが実行される。

（ステップＳ６０１）まず、予め金融機関のサーバ１１０Ｃはデポジットの入金処理を実行する。具体的には、サーバ１１０Ｃは、例えば、決済事業者のサーバ１１０Ａ及び事業者のサーバ１１０Ｂ等から送金指示を受信した場合や、所定のタイミングの到来を条件として、当該入金処理を実行してよい。これにより、金融機関における事業者の口座から決済事業者の口座に対して、デポジットとしての所定額が入金される。

（ステップＳ６０２〜Ｓ６０６）次に、ステップＳ６０２〜６０６として、上述したステップＳ３０１〜Ｓ３０５それぞれと同様の処理が実行される。

（ステップＳ６０７）次に、決済処理モジュール１１２５は、金融機関のサーバ１１０Ｃから取得したデポジットの残高が所定額未満となるか否かを判定する。

（ステップＳ６０８）次に、デポジットの残高が所定額未満となると判定された場合（ステップＳ６０７；Ｙｅｓ）、サーバ１１０Ａの送金管理モジュール１１２７は、所定の送金額の送金依頼を金融機関のサーバ１１０Ｃに送信する。当該所定の送金額は予め規定された追加のデポジット額に相当する額であってよい。

（ステップＳ６０９〜Ｓ６１３）次に、ステップＳ６０９〜６１３として、上述したステップＳ３０８〜Ｓ３１２それぞれと同様の処理が実行される。以上で、報酬の支払い及び原資の送金に係るシーケンスが終了する。

＜＜第３実施例＞＞
第３実施例は、原資送金それぞれが都度方式であり、電子バリューでの報酬のチャー
ジの要求がある度に、原資の送金処理が実行される実施例である。

＜＜第３実施例の効果＞＞
第３実施例によれば、電子バリューでの報酬のチャージと原資の送金処理との間のタイムラグが低減されることで、決済事業者が損金となるリスクを低減する効果が得られる。

＜＜第３実施例の構成＞＞
第３実施例に係るシステム構成や、サーバ、端末の構成等は、基本的に第１実施形態
に係るシステム構成や、サーバ、端末の構成等と同様である。

＜＜第３実施例の動作処理＞＞
図９は、第３実施例に係る決済処理システム１による報酬の支払い及び原資の送金に係る処理のシーケンスの一例を示す図である。第３実施例に係る当該シーケンスでは、上述したステップＳ３０７は実行されない点以外は、ステップＳ７０１〜Ｓ７１２として上述したステップＳ３０１〜Ｓ３０５及びＳ３０７〜Ｓ３１２と同様の処理が実行される。なお、ステップＳ７０７における送金額は、ステップＳ７０１における希望チャージ額に相当する額であってよい。

＜＜第４実施例＞＞
第４実施例は、所定の日時が到来した場合に、電子バリューでの報酬のチャージが実
行される実施例である。

＜＜第４実施例の効果＞＞
第４実施例によれば、ユーザがチャージ要求を入力せずとも所定の日時の到来に伴って自動的に報酬がチャージされるため、ユーザのチャージ要求の入力の負担が軽減される。

＜＜第４実施例の構成＞＞
第４実施例に係るシステム構成や、サーバ、端末の構成等は、基本的に第１実施形態
に係るシステム構成や、サーバ、端末の構成等と同様である。

＜＜第４実施例の動作処理＞＞
図１０は、第４実施例に係る決済処理システム１による報酬の支払い及び原資の送金に係る処理のシーケンスの一例を示す図である。第４実施例においては、上述した「（３）報酬の支払い及び原資の送金」に係るシーケンスに代えて、以下のシーケンスが実行される。

（ステップＳ８０１）決済事業者のサーバ１１０Ａの決済処理モジュール１１２５は、所定の日時が到来したか否かを判定する。ここで、当該所定の日時は特に限定されず、ユーザ、決済事業者、及び事業者等が任意に設定可能である。当該所定の日時は、例えば、日毎、週毎、月毎等の特定の曜日や日時として規定されてもよい。所定の日時が到来したと判定された場合（ステップＳ８０１；Ｙｅｓ）、ステップＳ８０２に進む。所定の日時が到来していないと判定された場合は、当該ステップＳ８０１が繰り返される。

（ステップＳ８０２〜Ｓ８０７）次に、ステップＳ８０２〜Ｓ８０７として、上述したステップＳ３０７〜Ｓ３１２それぞれと同様の処理が実行される。以上で、報酬の支払い及び原資の送金に係るシーケンスが終了する。なお、ステップＳ８０２における送金額と、ステップＳ８０５におけるチャージの額とは、予め定められた額であってよい。また、当該予め定められた額は、事業者信用スコア及び／又はユーザ信用スコア等によって算出されてもよい。

なお、開示技術は、上述した実施形態に限定されるものではなく、開示技術の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。例えば、上述した各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更し、または並列に実行することができる。

１ 決済処理システム
１１０ サーバ
１１１ プロセッサ
１１２ メモリ
１１３ ストレージ
１１２２ ユーザ情報
１１２３ 事業者情報
１１２４ 決済情報
１１２５ 決済処理モジュール
１１２６ 情報管理モジュール
１１２７ 送金管理モジュール
１１４ 入出力Ｉ／Ｆ
１１５ 入力装置
１１６ 出力装置
１１７ 送受信部
１２０ 端末
１２１ プロセッサ
１２２ メモリ
１２３ ストレージ
１２２２ 決済情報
１２２３ 決済処理モジュール
１２２４ 表示制御モジュール
１２４ 入出力Ｉ／Ｆ
１２５ 入力装置
１２６ 出力装置
１２７ 送受信部
１２８ 読取部
１１２３ 決済処理モジュール
１２２３ 決済処理モジュール
１２２４ 表示制御モジュール
１５２３ 決済確認モジュール
１５２４ 表示制御モジュール

Claims (14)

1. 情報処理装置に含まれる１又は複数のプロセッサに、
   ユーザに対応付けられる報酬を管理する事業者に対応付けられた情報処理装置から、報酬に関する情報を取得する処理と、
   前記ユーザと前記報酬に関する情報とを対応づける処理と、
   所定のタイミングにおいて、前記報酬の少なくとも一部に相当する額の電子バリューを前記ユーザの残高にチャージする処理と、
   前記事業者からの前記相当する額の送金の依頼を送信する処理と、を実行させる方法。
2. 前記事業者の信用スコアを取得する処理、をさらに実行させる、請求項１に記載の方法。
3. 前記事業者の信用スコアは、前記事業者が決済元又は決済先となる前記電子バリューの決済に関する情報に基づいて算出される、請求項２に記載の方法。
4. 前記事業者の信用スコアは、前記事業者が決済元又は決済先となる前記電子バリューの決済の決済額に基づいて算出される、請求項３に記載の方法。
5. 前記事業者の信用スコアは、前記事業者が決済元又は決済先となる前記電子バリューの決済の合計金額、平均金額、及び中央値金額のうち少なくとも１つに基づいて算出される、請求項３に記載の方法。
6. 前記事業者の信用スコアは、前記事業者が決済元となる前記電子バリューの決済の決済先の信用スコア、及び前記事業者が決済先となる前記電子バリューの決済の決済元の信用スコアのうち少なくとも１つに基づいて算出される、請求項２に記載の方法。
7. 前記事業者の信用スコアは、前記事業者が管理する前記報酬に対応付けられた前記ユーザの信用スコアに基づいて算出される、請求項２に記載の方法。
8. 前記送金の依頼は、前記所定のタイミングで送信される、請求項１又は２に記載の方法。
9. 前記送金の依頼は、前記電子バリューのチャージの合計額が所定額以上となった場合に、送信される、請求項２から７のいずれか一項に記載の方法。
10. 前記事業者からのデポジットを受け付ける処理、を更に実行させる方法であって、
    前記送金の依頼は、前記デポジットが所定額以下となった場合に、送信される、請求項２から７のいずれか一項に記載の方法。
11. 前記所定のタイミングは、前記ユーザからのリクエストを受信したとき、及び所定の日時が到来したときのうち少なくとも１つを含む、請求項１から１０のいずれか一項に記載の方法。
12. 前記報酬に関する情報は、前記報酬の額の情報を含む、請求項１から１１のいずれか一項に記載の方法。
13. ユーザに対応付けられる報酬を管理する事業者に対応付けられた情報処理装置から、報酬額に関する情報を取得する取得部と、
    前記ユーザと前記報酬額に関する情報とを対応づける登録部と、
    所定のタイミングにおいて、前記報酬額の少なくとも一部に相当する額の電子バリューを前記ユーザの残高にチャージするチャージ部と、
    前記事業者からの前記相当する額の送金の依頼を送信する送信部と、を備える情報処理装置。
14. 情報処理装置に含まれる１又は複数のプロセッサに、
    ユーザに対応付けられる報酬を管理する事業者に対応付けられた情報処理装置から、報酬額に関する情報を取得する処理と、
    前記ユーザと前記報酬額に関する情報とを対応づける処理と、
    所定のタイミングにおいて、前記報酬額の少なくとも一部に相当する額の電子バリューを前記ユーザの残高にチャージする処理と、
    前記事業者からの前記相当する額の送金の依頼を送信する処理と、を実行させるプログラム。

Images