知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023036426
(43)【公開日】2023-03-14
(54)【発明の名称】キャッシュバックを行うための方法及びシステム
(51)【国際特許分類】
G06Q 20/06 20120101AFI20230307BHJP
【ＦＩ】
G06Q20/06
【審査請求】未請求
【請求項の数】4
【出願形態】ＯＬ
(21)【出願番号】P 2021143479
(22)【出願日】2021-09-02
(71)【出願人】
【識別番号】506220597
【氏名又は名称】株式会社スコープ
(74)【代理人】
【識別番号】110000523
【氏名又は名称】アクシス国際弁理士法人
(72)【発明者】
【氏名】草刈 直弘
【テーマコード（参考）】
5L055
【Ｆターム（参考）】
5L055AA12
(57)【要約】
【課題】キャッシュバックの受け取り手段を選択することができる方法及びシステムを提供すること。
【解決手段】システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備える。第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にする。管理サーバの購買条件マッチングモジュールは、レシート情報からデータを生成する、又は読み込む。更に、管理サーバの購買条件マッチングモジュールは、生成データに基づいて、キャッシュバックの適用可否を判定する。第２のＷｅｂサーバは、商品及び／又はサービス提供者の端末からのリクエストに応答して、キャッシュバック申込情報及びキャッシュバックの適用可否の判定結果を表示する。管理サーバの送金実行モジュールは、送金指示を出力する。
【選択図】図１
【解決手段】システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備える。第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にする。管理サーバの購買条件マッチングモジュールは、レシート情報からデータを生成する、又は読み込む。更に、管理サーバの購買条件マッチングモジュールは、生成データに基づいて、キャッシュバックの適用可否を判定する。第２のＷｅｂサーバは、商品及び／又はサービス提供者の端末からのリクエストに応答して、キャッシュバック申込情報及びキャッシュバックの適用可否の判定結果を表示する。管理サーバの送金実行モジュールは、送金指示を出力する。
【選択図】図１
【特許請求の範囲】
【請求項1】
消費者へのキャッシュバックを行うための方法であって、
システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備え、
前記管理サーバは、購買条件マッチングモジュールと、送金実行モジュールとを備え、
前記方法は、
前記第１のＷｅｂサーバが、消費者の端末からのキャッシュバック申込情報を受信するステップと、
前記第１のＷｅｂサーバが、前記管理サーバへ、前記キャッシュバック申込情報を送信するステップと、
前記管理サーバの前記購買条件マッチングモジュールが、前記キャッシュバック申込情報からテキストデータを生成する又は読み込むステップと、
前記管理サーバの前記購買条件マッチングモジュールが、前記生成した又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するステップと、
前記第２のＷｅｂサーバが、商品及び／又はサービス提供者の端末からのリクエストに応答して、前記キャッシュバック申込情報及び前記キャッシュバックの適用可否の判定結果を、前記管理サーバから取得して表示するステップと、
前記管理サーバの前記送金実行モジュールが、送金指示を出力するステップと、
を含み、
ここで、
前記第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にするインターフェースを提供し、
前記第１のＷｅｂサーバは、レシート情報を、消費者の端末からアップロード可能にするインターフェースを提供し、
前記送金実行モジュールは、上記指定された金融エンティティへの送金指示を出力する、
方法。
システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備え、
前記管理サーバは、購買条件マッチングモジュールと、送金実行モジュールとを備え、
前記方法は、
前記第１のＷｅｂサーバが、消費者の端末からのキャッシュバック申込情報を受信するステップと、
前記第１のＷｅｂサーバが、前記管理サーバへ、前記キャッシュバック申込情報を送信するステップと、
前記管理サーバの前記購買条件マッチングモジュールが、前記キャッシュバック申込情報からテキストデータを生成する又は読み込むステップと、
前記管理サーバの前記購買条件マッチングモジュールが、前記生成した又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するステップと、
前記第２のＷｅｂサーバが、商品及び／又はサービス提供者の端末からのリクエストに応答して、前記キャッシュバック申込情報及び前記キャッシュバックの適用可否の判定結果を、前記管理サーバから取得して表示するステップと、
前記管理サーバの前記送金実行モジュールが、送金指示を出力するステップと、
を含み、
ここで、
前記第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にするインターフェースを提供し、
前記第１のＷｅｂサーバは、レシート情報を、消費者の端末からアップロード可能にするインターフェースを提供し、
前記送金実行モジュールは、上記指定された金融エンティティへの送金指示を出力する、
方法。
【請求項2】
請求項１の方法であって、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否の判定結果のほかに、レシート情報を表示するステップと、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否について、目視での確認を設定するためのインターフェースを提供するステップと、
を更に含む方法。
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否の判定結果のほかに、レシート情報を表示するステップと、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否について、目視での確認を設定するためのインターフェースを提供するステップと、
を更に含む方法。
【請求項3】
消費者へのキャッシュバックを行うためのシステムであって、
前記システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備え、
前記管理サーバは、購買条件マッチングモジュールと、送金実行モジュールとを備え、
前記第１のＷｅｂサーバは、消費者の端末からのキャッシュバック申込情報を受信するように構成され、
前記第１のＷｅｂサーバは、前記管理サーバへ、前記キャッシュバック申込情報を送信するように構成され、
前記管理サーバの前記購買条件マッチングモジュールは、前記キャッシュバック申込情報からテキストデータを生成する、又は読み込むように構成され、
前記管理サーバの前記購買条件マッチングモジュールは、前記生成した、又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するように構成され、
前記第２のＷｅｂサーバは、商品及び／又はサービス提供者の端末からのリクエストに応答して、前記キャッシュバック申込情報及び前記キャッシュバックの適用可否の判定結果を、前記管理サーバから取得して表示するように構成され、
前記管理サーバの前記送金実行モジュールは、送金指示を出力するように構成され、
ここで、
前記第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にするインターフェースを提供するように構成され、
前記第１のＷｅｂサーバは、レシート情報を、消費者の端末からアップロード可能にするインターフェースを提供するように構成され、
前記購買条件マッチングモジュールは、前記レシート情報からテキストデータを生成する、又は、読み込むように構成され、
前記送金実行モジュールは、上記指定された金融エンティティへの送金指示を出力するように構成される、
システム。
前記システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備え、
前記管理サーバは、購買条件マッチングモジュールと、送金実行モジュールとを備え、
前記第１のＷｅｂサーバは、消費者の端末からのキャッシュバック申込情報を受信するように構成され、
前記第１のＷｅｂサーバは、前記管理サーバへ、前記キャッシュバック申込情報を送信するように構成され、
前記管理サーバの前記購買条件マッチングモジュールは、前記キャッシュバック申込情報からテキストデータを生成する、又は読み込むように構成され、
前記管理サーバの前記購買条件マッチングモジュールは、前記生成した、又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するように構成され、
前記第２のＷｅｂサーバは、商品及び／又はサービス提供者の端末からのリクエストに応答して、前記キャッシュバック申込情報及び前記キャッシュバックの適用可否の判定結果を、前記管理サーバから取得して表示するように構成され、
前記管理サーバの前記送金実行モジュールは、送金指示を出力するように構成され、
ここで、
前記第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にするインターフェースを提供するように構成され、
前記第１のＷｅｂサーバは、レシート情報を、消費者の端末からアップロード可能にするインターフェースを提供するように構成され、
前記購買条件マッチングモジュールは、前記レシート情報からテキストデータを生成する、又は、読み込むように構成され、
前記送金実行モジュールは、上記指定された金融エンティティへの送金指示を出力するように構成される、
システム。
【請求項4】
請求項３のシステムであって、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否の判定結果のほかに、前記レシート情報を表示するように構成され、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否について、目視での確認を設定するためのインターフェースを提供するように構成される、
システム。
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否の判定結果のほかに、前記レシート情報を表示するように構成され、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否について、目視での確認を設定するためのインターフェースを提供するように構成される、
システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、キャッシュバックを行うための方法及びシステムに関する。
【背景技術】
【0002】
近年では、サービスの享受、及び／又は、物の購入の際に、現金ではなく、電子決済手段を使用するケースが増加しつつある。電子決済手段は、様々な形で分類されるが、典型的には、クレジットカード、バーコード決済、電子マネー、暗号資産などが挙げられる。様々な決済手段が乱立している昨今、一個人で、複数の電子決済手段を使用しているケースも珍しくない。
【0003】
特許文献１では、利用者の有しているポイントを電子マネーと交換するポイント－電子マネー交換処理が可能な構成を開示している。特許文献２では、キャッシュバックの際に電子マネーの口座へ送金することを開示している。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】国際公開第２０１６／１０３７７２号
【特許文献2】特許第６７１０８２０号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上述しているように、一個人が、複数の電子決済手段を使用しているケースは珍しくない。こうした状況下において、サービス、及び／又は、物の購入に際して、キャッシュバックを行うことがある。キャッシュバックを受ける消費者側の立場からみると、複数の電子決済手段を各々の目的に応じて使い分けるケースがある（例えば、家計の管理の理由から、収入に該当するイベントは特定の電子マネーで一元管理したいなど）。したがって、必ずしも、購入時に使用した電子決済手段で、キャッシュバックを受けとることを希望しない場合もある。
【0006】
そこで、本開示は、キャッシュバックの受け取り手段を選択することができる方法及びシステムを提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明者が鋭意検討したところ、レシート情報などを消費者が提供してキャッシュバックの申込の際に、キャッシュバックの受け取り手段を選択できる構成を思いついた。これにより、消費者にとって、都合の良い電子決済手段にて、キャッシュバックを受け取ることができる。
【0008】
上記知見に基づいて発明が完成され、本開示は、一側面において、以下の発明を包含する。
（発明１）
消費者へのキャッシュバックを行うための方法であって、
システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備え、
前記管理サーバは、購買条件マッチングモジュールと、送金実行モジュールとを備え、
前記方法は、
前記第１のＷｅｂサーバが、消費者の端末からのキャッシュバック申込情報を受信するステップと、
前記第１のＷｅｂサーバが、前記管理サーバへ、前記キャッシュバック申込情報を送信するステップと、
前記管理サーバの前記購買条件マッチングモジュールが、前記キャッシュバック申込情報からテキストデータを生成する又は読み込むステップと、
前記管理サーバの前記購買条件マッチングモジュールが、前記生成した又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するステップと、
前記第２のＷｅｂサーバが、商品及び／又はサービス提供者の端末からのリクエストに応答して、前記キャッシュバック申込情報及び前記キャッシュバックの適用可否の判定結果を、前記管理サーバから取得して表示するステップと、
前記管理サーバの前記送金実行モジュールが、送金指示を出力するステップと、
を含み、
ここで、
前記第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にするインターフェースを提供し、
前記第１のＷｅｂサーバは、レシート情報を、消費者の端末からアップロード可能にするインターフェースを提供し、
前記送金実行モジュールは、上記指定された金融エンティティへの送金指示を出力する、
方法。
（発明２）
発明１の方法であって、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否の判定結果のほかに、レシート情報を表示するステップと、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否について、目視での確認を設定するためのインターフェースを提供するステップと、
を更に含む方法。
（発明３）
消費者へのキャッシュバックを行うためのシステムであって、
前記システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備え、
前記管理サーバは、購買条件マッチングモジュールと、送金実行モジュールとを備え、
前記第１のＷｅｂサーバは、消費者の端末からのキャッシュバック申込情報を受信するように構成され、
前記第１のＷｅｂサーバは、前記管理サーバへ、前記キャッシュバック申込情報を送信するように構成され、
前記管理サーバの前記購買条件マッチングモジュールは、前記キャッシュバック申込情報からテキストデータを生成する、又は読み込むように構成され、
前記管理サーバの前記購買条件マッチングモジュールは、前記生成した、又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するように構成され、
前記第２のＷｅｂサーバは、商品及び／又はサービス提供者の端末からのリクエストに応答して、前記キャッシュバック申込情報及び前記キャッシュバックの適用可否の判定結果を、前記管理サーバから取得して表示するように構成され、
前記管理サーバの前記送金実行モジュールは、送金指示を出力するように構成され、
ここで、
前記第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にするインターフェースを提供するように構成され、
前記第１のＷｅｂサーバは、レシート情報を、消費者の端末からアップロード可能にするインターフェースを提供するように構成され、
前記購買条件マッチングモジュールは、前記レシート情報からテキストデータを生成する、又は、読み込むように構成され、
前記送金実行モジュールは、上記指定された金融エンティティへの送金指示を出力するように構成される、
システム。
（発明４）
発明３のシステムであって、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否の判定結果のほかに、前記レシート情報を表示するように構成され、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否について、目視での確認を設定するためのインターフェースを提供するように構成される、
システム。
（発明１）
消費者へのキャッシュバックを行うための方法であって、
システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備え、
前記管理サーバは、購買条件マッチングモジュールと、送金実行モジュールとを備え、
前記方法は、
前記第１のＷｅｂサーバが、消費者の端末からのキャッシュバック申込情報を受信するステップと、
前記第１のＷｅｂサーバが、前記管理サーバへ、前記キャッシュバック申込情報を送信するステップと、
前記管理サーバの前記購買条件マッチングモジュールが、前記キャッシュバック申込情報からテキストデータを生成する又は読み込むステップと、
前記管理サーバの前記購買条件マッチングモジュールが、前記生成した又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するステップと、
前記第２のＷｅｂサーバが、商品及び／又はサービス提供者の端末からのリクエストに応答して、前記キャッシュバック申込情報及び前記キャッシュバックの適用可否の判定結果を、前記管理サーバから取得して表示するステップと、
前記管理サーバの前記送金実行モジュールが、送金指示を出力するステップと、
を含み、
ここで、
前記第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にするインターフェースを提供し、
前記第１のＷｅｂサーバは、レシート情報を、消費者の端末からアップロード可能にするインターフェースを提供し、
前記送金実行モジュールは、上記指定された金融エンティティへの送金指示を出力する、
方法。
（発明２）
発明１の方法であって、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否の判定結果のほかに、レシート情報を表示するステップと、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否について、目視での確認を設定するためのインターフェースを提供するステップと、
を更に含む方法。
（発明３）
消費者へのキャッシュバックを行うためのシステムであって、
前記システムは、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備え、
前記管理サーバは、購買条件マッチングモジュールと、送金実行モジュールとを備え、
前記第１のＷｅｂサーバは、消費者の端末からのキャッシュバック申込情報を受信するように構成され、
前記第１のＷｅｂサーバは、前記管理サーバへ、前記キャッシュバック申込情報を送信するように構成され、
前記管理サーバの前記購買条件マッチングモジュールは、前記キャッシュバック申込情報からテキストデータを生成する、又は読み込むように構成され、
前記管理サーバの前記購買条件マッチングモジュールは、前記生成した、又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するように構成され、
前記第２のＷｅｂサーバは、商品及び／又はサービス提供者の端末からのリクエストに応答して、前記キャッシュバック申込情報及び前記キャッシュバックの適用可否の判定結果を、前記管理サーバから取得して表示するように構成され、
前記管理サーバの前記送金実行モジュールは、送金指示を出力するように構成され、
ここで、
前記第１のＷｅｂサーバは、キャッシュバックの送金先を複数の金融エンティティから指定可能にするインターフェースを提供するように構成され、
前記第１のＷｅｂサーバは、レシート情報を、消費者の端末からアップロード可能にするインターフェースを提供するように構成され、
前記購買条件マッチングモジュールは、前記レシート情報からテキストデータを生成する、又は、読み込むように構成され、
前記送金実行モジュールは、上記指定された金融エンティティへの送金指示を出力するように構成される、
システム。
（発明４）
発明３のシステムであって、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否の判定結果のほかに、前記レシート情報を表示するように構成され、
前記第２のＷｅｂサーバが、前記キャッシュバックの適用可否について、目視での確認を設定するためのインターフェースを提供するように構成される、
システム。
【発明の効果】
【0009】
上記発明の一側面において、第１のＷｅｂサーバは、キャッシュバックに利用する金融エンティティを複数の金融エンティティから指定可能にするインターフェースを提供する。これにより、消費者にとって、都合の良い電子決済手段にて、キャッシュバックを受け取ることができる。
【図面の簡単な説明】
【0010】
【図1】一実施形態において、ＵＲＬデータベースの概要を示す。
【図2】一実施形態において、キャッシュバックマスタデータベースの概要を示す。
【図3】一実施形態において、キャッシュバック申込データベースの概要を示す。
【図4】一実施形態において、金融エンティティデータベースの概要を示す。
【図5】一実施形態において、レシート情報をアップロードするインターフェースの概要を示す。
【図6】一実施形態において、送金先を指定するインターフェースの概要を示す。
【図10】一実施形態において、送金先を指定するインターフェースの概要を示す。図６に示すインターフェースにてＡＴＭから受け取りを選択（例えば、「ＡＢＣ銀行ＡＴＭ受け取り」をタップ）したときに表示される。
【図11】一実施形態において、申込情報を確認するインターフェースの概要を示す。申込情報を一覧形式で表示されており、送金状況に応じて、送金を実行するための操作（送金実行ボタン）が可能なように実装されている。
【発明を実施するための形態】
【0011】
以下、発明を実施するための具体的な実施形態について説明する。以下の説明は、発明の理解を促進するためのものである。即ち、本発明の範囲を限定することを意図するものではない。
【0012】
１．システムの概要
一実施形態において、本開示は、消費者へのキャッシュバックを行うためのシステムに関する。システムは、少なくとも、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備える。これらの構成要素は、相互にネットワークで接続される。ネットワークの種類は特に限定されず、無線有線を問わず、インターネットであっても、ＷＡＮであっても、ＬＡＮであってもよく、公知のネットワークを採用してもよい。
一実施形態において、本開示は、消費者へのキャッシュバックを行うためのシステムに関する。システムは、少なくとも、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備える。これらの構成要素は、相互にネットワークで接続される。ネットワークの種類は特に限定されず、無線有線を問わず、インターネットであっても、ＷＡＮであっても、ＬＡＮであってもよく、公知のネットワークを採用してもよい。
【0013】
なお、本明細書で述べるサーバは、物理的な１台の情報処理装置に限定されない。例えば、負荷分散手段により、複数台の情報処理装置が同一の機能及び役割を担う構成にし、外側からはあたかも１台のサーバが動作しているように見える構成であってもよい。あるいは、１つのサーバ内で、複数の異なる機能及び役割を担う場合には、機能及び役割ごとに、複数の物理的な情報処理装置に分散させてもよい。一方で、複数の異なる機能及び役割を担うサーバを、１台の物理的な情報処理装置に集約してもよい。
【0014】
上述したように、一実施形態における本開示のシステムは、少なくとも、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバとを備える。しかし、このことは、それぞれに対応した３台のサーバが存在する構成に限定されるものではない。例えば、第１のＷｅｂサーバは、複数台の物理的な情報処理装置に分散されてもよい。別の例では、第１のＷｅｂサーバと第２のＷｅｂサーバは、物理的に同一の１台の情報処理装置に集約されてもよい。また、管理サーバで、複数のモジュールを備える場合には、各モジュールに対応した複数台の物理的な情報処理装置に分散されてもよい。
【0015】
サーバとしての情報処理装置は、当分野で公知の装置を採用することができる。典型的には、プロセッサ、メモリ、通信機能、記憶媒体等を少なくとも備えるものであればよい。そして、情報処理装置には、所望のプログラムがインストールされており、当該プログラムをプロセッサが実行することで、各種機能を担うモジュールが実現される。
【0016】
以降では、管理サーバと、第１のＷｅｂサーバと、第２のＷｅｂサーバの各々の役割及び構成について詳述する。
【0017】
２．第１のＷｅｂサーバ
第１のＷｅｂサーバは、消費者が所有する端末（例えば、スマートフォンなど）がアクセスしたときに、Ｗｅｂサイトを提供するためのサーバである。具体的な例としては、第１のＷｅｂサーバは、消費者の端末からのキャッシュバック申込を受け付けるためのインターフェースとなるＷｅｂサイトを提供することができる。
第１のＷｅｂサーバは、消費者が所有する端末（例えば、スマートフォンなど）がアクセスしたときに、Ｗｅｂサイトを提供するためのサーバである。具体的な例としては、第１のＷｅｂサーバは、消費者の端末からのキャッシュバック申込を受け付けるためのインターフェースとなるＷｅｂサイトを提供することができる。
【0018】
こうした機能を実現するため、第１のＷｅｂサーバは、インターフェース生成モジュール、受信モジュール、送信モジュールを備える。
【0019】
インターフェース生成モジュールは、キャッシュバック申込を受け付けるためのインターフェースとなるＷｅｂページを動的に生成する機能を有することができる。また、インターフェース生成モジュールは、後述するデータベース等から適宜必要な情報を取得することができる。
【0020】
受信モジュール及び送信モジュールは、必要な情報の送受信を行うための機能を有する。例えば、インターフェース生成モジュールがＷｅｂページを生成するのに必要な情報を取得したり（例えば管理サーバ等から）、消費者の端末からの各種リクエスト、入力等を受信したり、逆に、消費者の端末に提示するのに必要な情報を送信したり（例えば管理サーバ等へ）するなどの役割を担う。
【0021】
３．第２のＷｅｂサーバ
第２のＷｅｂサーバは、商品及び／又はサービス提供者が所有する端末（例えば、スマートフォン、タブレット端末、パソコン等）がアクセスしたときに、Ｗｅｂサイトを提供するためのサーバである。具体的な例としては、第２のＷｅｂサーバは、キャッシュバックの条件の設定、申込状況の確認、送金状況の確認などをおこなうためのＷｅｂページを提供することができる。
第２のＷｅｂサーバは、商品及び／又はサービス提供者が所有する端末（例えば、スマートフォン、タブレット端末、パソコン等）がアクセスしたときに、Ｗｅｂサイトを提供するためのサーバである。具体的な例としては、第２のＷｅｂサーバは、キャッシュバックの条件の設定、申込状況の確認、送金状況の確認などをおこなうためのＷｅｂページを提供することができる。
【0022】
こうした機能を実現するため、第２のＷｅｂサーバは、インターフェース生成モジュール、受信モジュール、送信モジュールを備える。
【0023】
インターフェース生成モジュールは、キャッシュバックの条件の設定、申込状況の確認、送金実行、送金状況の確認などのインターフェースとなるＷｅｂページを動的に生成する機能を有することができる。また、インターフェース生成モジュールは、管理サーバ（例えば、後述するデータベース）等から適宜必要な情報を取得することができる。受信モジュール及び送信モジュールの機能は、上述した第１のＷｅｂサーバの受信モジュール及び送信モジュールと同様であってもよい。
【0024】
４．管理サーバ
管理サーバは、第１のＷｅｂサーバ及び第２のＷｅｂサーバに必要な情報を提供することができる。また、管理サーバは、第１のＷｅｂサーバ及び第２のＷｅｂサーバを経由して受信されたリクエストに対する処理を行うことができる。
管理サーバは、第１のＷｅｂサーバ及び第２のＷｅｂサーバに必要な情報を提供することができる。また、管理サーバは、第１のＷｅｂサーバ及び第２のＷｅｂサーバを経由して受信されたリクエストに対する処理を行うことができる。
【0025】
こうした機能を実現する目的で、管理サーバは、購買条件マッチングモジュールと、送金実行モジュールを備える。
【0026】
好ましくは、管理サーバは、更に、受信モジュール、送信モジュール、及びデータベース、キャッシュバック申込受付モジュールを備えてもよい。
【0027】
４－１．購買条件マッチングモジュール
購買条件マッチングモジュールは、２つの機能を備える。１つめは、購買等の証明となるレシート情報を抽出する機能である。２つめは、キャッシュバックの申し込み情報の内容が、キャッシュバック適用条件を充足するか否かの判定を行う機能である。これらに対応して、購買条件マッチングモジュールは、サブモジュールとして、レシート情報収集サブモジュールと、マッチングサブモジュールとを備えてもよい。
購買条件マッチングモジュールは、２つの機能を備える。１つめは、購買等の証明となるレシート情報を抽出する機能である。２つめは、キャッシュバックの申し込み情報の内容が、キャッシュバック適用条件を充足するか否かの判定を行う機能である。これらに対応して、購買条件マッチングモジュールは、サブモジュールとして、レシート情報収集サブモジュールと、マッチングサブモジュールとを備えてもよい。
【0028】
４－１－１．レシート情報収集サブモジュール
レシート情報収集サブモジュールは、レシート情報を抽出するように構成される。一つの例としては、レシート情報抽出サブモジュールは、記録されたキャッシュバック申込情報からテキストデータを生成する、又は、読み込むように構成される。通常、キャッシュバックが適用されるための条件として、特定の商品、及び／又はサービスを購入することが挙げられる。したがって、キャッシュバックの申し込みの際には、購入の証拠（例えば、レシート）が必要となる。そこで、購入の証拠となるレシート情報（例えば、レシートの画像ファイル、レシートの電子ファイル（例えばＰＤＦ形式等）、購買を特定するための識別情報（例えば、取引番号、契約コード等）等）を、受領する必要がある。そして、受領した後は、各種処理を行うため、キャッシュバック申込情報からテキストデータが生成される。これに伴い、レシートの画像ファイルに含まれる文字の情報などもテキスト化される。あるいは、キャッシュバック申込情報が、ＯＣＲ等の処理が必要ない形式のデータである場合（例えば、電子レシート）には、キャッシュバック申込情報から、テキストデータを読み込むようにしてもよい。
レシート情報収集サブモジュールは、レシート情報を抽出するように構成される。一つの例としては、レシート情報抽出サブモジュールは、記録されたキャッシュバック申込情報からテキストデータを生成する、又は、読み込むように構成される。通常、キャッシュバックが適用されるための条件として、特定の商品、及び／又はサービスを購入することが挙げられる。したがって、キャッシュバックの申し込みの際には、購入の証拠（例えば、レシート）が必要となる。そこで、購入の証拠となるレシート情報（例えば、レシートの画像ファイル、レシートの電子ファイル（例えばＰＤＦ形式等）、購買を特定するための識別情報（例えば、取引番号、契約コード等）等）を、受領する必要がある。そして、受領した後は、各種処理を行うため、キャッシュバック申込情報からテキストデータが生成される。これに伴い、レシートの画像ファイルに含まれる文字の情報などもテキスト化される。あるいは、キャッシュバック申込情報が、ＯＣＲ等の処理が必要ない形式のデータである場合（例えば、電子レシート）には、キャッシュバック申込情報から、テキストデータを読み込むようにしてもよい。
【0029】
なお、本明細書で述べる「レシート情報収集サブモジュール」は、モジュール自身に、テキスト化する機能を備えるのではなく、外部のテキスト化ツールとのインターフェース機能を備えるだけであってもよい。例えば、ＯＣＲ解析ＡＰＩサブモジュールを更に備えたうえで、上述したレシートの画像などからテキストデータを生成する場合、外部のテキスト化ツールに画像をアップロードし、そして、当該ツールから、テキスト化の結果となるデータを受信するように構成されてもよい。したがって、「キャッシュバック申込情報からテキストデータを生成する」といった場合には、外部のテキスト化ツールを利用してテキストデータを生成する場合も包含する。
【0030】
外部のテキスト化ツールは、特に限定されず、ＯＣＲ機能を有する物であれば、何でもよい。外部のテキスト化ツールは、一実施形態における本開示のシステムの外部に存在してもよく、すなわち、サードパーティがネットワーク経由で提供するものであってもよい。こうしたサードパーティが提供するツールを利用する場合、レシート情報収集モジュールは当該ツールを利用するためのＡＰＩを備えることができる。サードパーティが提供するツールは特に限定されないが、例えば、Ｃｌｏｖａ ＯＣＲ、Ａｚｕｒｅ Ｃｏｍｐｕｔｅｒ Ｖｉｓｉｏｎ ＯＣＲ、Ｃｌｏｕｄ Ｖｉｓｉｏｎ ＡＰＩなどが挙げられる。
【0031】
別の例では、レシート情報抽出サブモジュールは、記録されたキャッシュバック申込情報に含まれる購買を特定する情報を抽出するとともに、外部のデータベースを参照して、購買情報を取得してもよい。例えば、キャッシュバックの申込情報には、購買を特定するコードのみが入力されており（例えば、取引番号など）、レシート情報抽出サブモジュールは、当該コードに基づいて、販売元のデータベース等に問い合わせ（例えば、クエリ発行）を行い、購買の詳細情報を取得するようにしてもよい。この場合、消費者にとっては、レシート情報の入力の手間が楽になるため、メリットが大きい。
【0032】
いずれの例においても、レシート情報抽出サブモジュールを利用することで、購買条件マッチングモジュールは、テキストデータを生成すること等ができる。そして、このテキストデータは、次に述べる購買判定の際に使用される。
【0033】
４－１－２．購買条件マッチングサブモジュール
購買条件マッチングサブモジュールは、キャッシュバックの申し込み情報の内容が、キャッシュバック適用条件を充足するか否かの判定を行うことができる。その際には、上述したテキスト化されたデータ、又は読み取ったデータ等を利用することができる。
購買条件マッチングサブモジュールは、キャッシュバックの申し込み情報の内容が、キャッシュバック適用条件を充足するか否かの判定を行うことができる。その際には、上述したテキスト化されたデータ、又は読み取ったデータ等を利用することができる。
【0034】
判定に使用する条件は、特に限定されず、商品サービス提供者が適宜設定することができる。条件の例としては、例えば、以下から選択される１以上の項目が挙げられる：購入チェーン、購入店舗、購入日時、購入商品及び／又はサービス、購入金額、消費者のプロフィール（年齢、性別、職業、家族構成等）。
【0035】
例えば、キャンペーン期間中に購入されたことを条件とする場合には、キャンペーン期間の開始日と終了日を判定条件として記憶する。そして、テキスト化されたデータから購入日を取得する。そして、当該購入日が開始日と終了日の間になっているかどうかを判定することで、キャッシュバックの条件を満たすか否かを判定できる。
【0036】
購買条件マッチングモジュールは、判定結果を記録することができる。例えば、キャッシュバック申込情報を記録したデータベースに、判定結果（例えば、キャッシュバックの適用可否に関する条件を満たすか否かの判定結果）を記録することができる。
【0037】
４－２．送金実行モジュール
送金実行モジュールは、送金指示を出力するように構成される。当該出力指示は、例えば、第２のＷｅｂサーバからのリクエストに基づいてもよい。例えば、第２のＷｅｂサーバが提供するインターフェースにおいて、商品及び／又はサービス提供者の端末からの操作に応答して、送金指示のリクエストが生成されてもよい。そして、生成されたリクエストが、第２のＷｅｂサーバから、管理サーバに送信されてもよい。さらに、送金実行モジュールは、これに基づいて送金指示を出力してもよい。
送金実行モジュールは、送金指示を出力するように構成される。当該出力指示は、例えば、第２のＷｅｂサーバからのリクエストに基づいてもよい。例えば、第２のＷｅｂサーバが提供するインターフェースにおいて、商品及び／又はサービス提供者の端末からの操作に応答して、送金指示のリクエストが生成されてもよい。そして、生成されたリクエストが、第２のＷｅｂサーバから、管理サーバに送信されてもよい。さらに、送金実行モジュールは、これに基づいて送金指示を出力してもよい。
【0038】
送金指示の具体的な内容は特に限定されないが、例えば、以下の項目が挙げられる。送金先を特定する情報、送金を行う日、送金金額等。また、送金先を特定する情報の例としては、銀行等の金融機関の場合には口座情報（例えば、本店コード、支店コード、預金種別、口座番号等）であってもよい。また、電子マネーの決済機関である場合には、アカウント識別情報（例えば、アカウントＩＤ、バーコードなど）であってもよい。
【0039】
４－３．その他モジュール及び／又はデータベース等
管理サーバは、上記以外に更に別のモジュールを備えてもよい。例えば、管理サーバは、キャッシュバック申込受付モジュール、受信モジュール、送信モジュール、データベース等を備えてもよい。キャッシュバック申込受付モジュールは、第１のＷｅｂサーバを経由して受信したキャッシュバック申込情報を記録するように構成される。好ましくは、キャッシュバック申込情報は、データベースなどに記録してもよい。受信モジュール及び送信モジュールは、管理サーバ以外の各種構成要素（例えば、第１のＷｅｂサーバ、第２のＷｅｂサーバ等）との通信を行うことができる。また、管理サーバは、限定されるものではないが、目的・機能に応じて各種データベースを備えることができる。
管理サーバは、上記以外に更に別のモジュールを備えてもよい。例えば、管理サーバは、キャッシュバック申込受付モジュール、受信モジュール、送信モジュール、データベース等を備えてもよい。キャッシュバック申込受付モジュールは、第１のＷｅｂサーバを経由して受信したキャッシュバック申込情報を記録するように構成される。好ましくは、キャッシュバック申込情報は、データベースなどに記録してもよい。受信モジュール及び送信モジュールは、管理サーバ以外の各種構成要素（例えば、第１のＷｅｂサーバ、第２のＷｅｂサーバ等）との通信を行うことができる。また、管理サーバは、限定されるものではないが、目的・機能に応じて各種データベースを備えることができる。
【0040】
データベースの形式は、特に限定されず、当分野にて公知の方式（ＮｏＳＱＬ、リレーショナル等）を採用することができる。
【0041】
例えば、管理サーバは、以下のデータベースのうち１種類以上を備えてもよい。
ＵＲＬデータベース、
キャッシュバックマスタデータベース、
キャッシュバック申込データベース、
金融エンティティデータベース
ＵＲＬデータベース、
キャッシュバックマスタデータベース、
キャッシュバック申込データベース、
金融エンティティデータベース
【0042】
ＵＲＬデータベースは、例えば、キャッシュバックキャンペーンごとに異なるＵＲＬを使用する場合に、ＵＲＬの情報を記憶するために使用してもよい。一例を図１に示す。例えば、ＵＲＬは、消費者側が利用するＵＲＬ（第１のＷｅｂサーバが提供するサイトに対応）と、商品・サービス提供者側が利用するＵＲＬ（第２のＷｅｂサーバが提供するサイトに対応）とが含まれてもよい。消費者側が利用するＵＲＬについては、キャッシュバックキャンペーンごとに異なったインターフェースになる蓋然性が高いため、キャンペーンごとに異なるＵＲＬを利用するようにしてもよい。一方で、商品・サービス提供者側が利用するＵＲＬについては、キャッシュバックキャンペーンごとに異なったＵＲＬにしてもよい。しかし、こちらについては、消費者側が利用するＵＲＬほど、カスタマイズの幅が大きくはないので、共通のＵＲＬにしてもよい（そして、ログインする際の認証情報に応じて表示内容を切り替える程度でもよい）。
【0043】
キャッシュバックマスタデータベースは、キャッシュバックキャンペーンに関するマスタ情報を記憶するために使用してもよい。例えば、図２に示すように、キャッシュバックキャンペーンの識別情報、キャッシュバックキャンペーンに関する管理を行うためのアカウントおよびパスワード、キャンペーンの名称、キャッシュバック適用の判定条件、利用可能な金融エンティティ等の情報を記憶するために使用してもよい。一部の項目については、多様な条件及びフォーマットに対応できるように、当分野で任意の技術を利用してもよい。例えば、キャッシュバック適用の判定条件などは、判定項目ごとにカラムを設けてもよいが、キャンペーンごとに独自の項目などを柔軟に設定できるよう、ＪＳＯＮ等の形式を使用してもよい。
【0044】
キャッシュバック申込データベースは、消費者からのキャッシュバック申込の情報を記憶するために使用してもよい。キャッシュバック申込の情報としては、例えば、図３に示すように、キャンペーンの識別情報、申込を特定する情報（例えば、申込番号）、レシート情報（例えば、レシートの画像データ、テキスト形式のレシート情報等）、送金先識別情報、申込者の基本情報、アンケート情報、送金金額、キャッシュバック適用の判定結果、目視での判定結果、送金処理のステータス（送金処理の実行の有無、及びその結果）などの情報が含まれてもよい。
【0045】
金融エンティティデータベースは、金融エンティティ（例えば、銀行、キャッシュレス決済機関等）に関するマスタ情報を管理するために使用してもよい。例えば、図４に示すように、金融エンティティデータベースは、金融エンティティ識別情報、名称、種別（例えば、銀行系、クレジットカード系、暗号資産系、電子マネー系などの区別をするためのコード）、必要な入力項目、及びそのプロパティ（例えば、桁数情報、入力可能な数値文字記号などの制限等）、連携機関への認証コードなどを含んでもよい。なお、電子マネーとは、現金を介さずに決済可能な技術的手段であり、特定の国で流通している通貨を単位としてデータが管理されるものを指す。また、電子マネーは、プリペイド式（すなわち、あらかじめ一定の金額をチャージしておく必要がある）であってもよく、即時決済式（すなわち、商品等の購入時に銀行等の口座から引き落としされる）であってもよく、後払い式（商品等の購入から一定期間経過した後に、銀行等の口座から引き落としされる）であってもよい。また、電子マネーは、非接触式であってもよく、コード（たとえばＱＲコード（登録商標）等）読み取り式であってもよく、アプリを通してオンラインで送金可能な方式であってもよい。
【0046】
以降では、上述した構成のシステムを用いた、消費者へのキャッシュバックを行うための方法の具体例について詳述する。
【0047】
５．キャッシュバック方法
一実施形態において、本開示は、消費者へのキャッシュバックを行うための方法に関する。前記方法は、少なくとも以下のステップを含む。
・第１のＷｅｂサーバが、消費者の端末からのキャッシュバック申込情報を受信するステップ
・第１のＷｅｂサーバが、管理サーバへ、キャッシュバック申込情報を送信するステップ
・管理サーバの購買条件マッチングモジュールが、キャッシュバック申込情報からテキストデータを生成する又は読み込むステップ
・管理サーバの購買条件マッチングモジュールが、生成した又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するステップ
・第２のＷｅｂサーバが、商品及び／又はサービス提供者の端末からのリクエストに応答して、キャッシュバック申込情報及びキャッシュバックの適用可否の判定結果を表示するステップ
・管理サーバの送金実行モジュールが、送金指示を出力するステップ
一実施形態において、本開示は、消費者へのキャッシュバックを行うための方法に関する。前記方法は、少なくとも以下のステップを含む。
・第１のＷｅｂサーバが、消費者の端末からのキャッシュバック申込情報を受信するステップ
・第１のＷｅｂサーバが、管理サーバへ、キャッシュバック申込情報を送信するステップ
・管理サーバの購買条件マッチングモジュールが、キャッシュバック申込情報からテキストデータを生成する又は読み込むステップ
・管理サーバの購買条件マッチングモジュールが、生成した又は読み込んだテキストデータに基づいて、キャッシュバックの適用可否を判定するステップ
・第２のＷｅｂサーバが、商品及び／又はサービス提供者の端末からのリクエストに応答して、キャッシュバック申込情報及びキャッシュバックの適用可否の判定結果を表示するステップ
・管理サーバの送金実行モジュールが、送金指示を出力するステップ
【0048】
以下では、上記ステップ等について詳述する。
【0049】
５－１．キャッシュバック申込情報の受信及び送信
消費者は、情報処理端末（例えば、スマートフォン等）を使用してＷｅｂサイトにアクセスする。Ｗｅｂサイトにアクセスするためのアプリケーションは、特に限定されない。例えば、ブラウザソフトでもよいし、ＳＮＳアプリ（より正確には当該アプリに組み込まれるブラウザ機能）であってもよい。
消費者は、情報処理端末（例えば、スマートフォン等）を使用してＷｅｂサイトにアクセスする。Ｗｅｂサイトにアクセスするためのアプリケーションは、特に限定されない。例えば、ブラウザソフトでもよいし、ＳＮＳアプリ（より正確には当該アプリに組み込まれるブラウザ機能）であってもよい。
【0050】
また、Ｗｅｂサイトにアクセスする際には、例えば、レシートや、実店舗の掲示板などに表示される二次元バーコードなどを利用してアクセスしてもよい。あるいは、ＳＮＳやそれ以外の広告付きのアプリなどに表示されるリンク付きの広告を経由してアクセスしてもよい。さらには、プッシュ通知などに組み込まれたリンクを経由してアクセスしてもよい。
【0051】
上記アクセスに応答して、第１のＷｅｂサーバは、消費者の端末に、キャッシュバック申込を行うためのインターフェース画面を提供することができる。
【0052】
上記インターフェースは、種々の情報を入力可能にするように構成されるが、少なくとも、以下の情報を入力することを可能にする構成されてもよい。
・レシート情報の入力
・キャッシュバック先の情報の入力
・レシート情報の入力
・キャッシュバック先の情報の入力
【0053】
レシート情報の入力は、例えば、図５に示すように、消費者の情報処理端末に搭載されるカメラ機能を利用して、紙面のレシートを撮影し、撮影後のデータをアップロードするようにしてもよい。また、紙面のレシートが長すぎて、一枚で撮影できない場合には、複数枚アップロードできるように、インターフェースを構成してもよい。その場合には、第１のＷｅｂサーバ又は管理サーバにおいて、画像処理モジュールを設けて、一枚のレシートの情報に再構成できるようにしてもよい。
【0054】
紙面のレシートを使用しない例として、例えば、ネット通販などでは、領収書を電子ファイルの形式（例えばＰＤＦなど）で各自必要に応じてダウンロードするケースもある。その場合には、電子ファイルの形式の領収書を、アップロードするようにしてもよい。紙面のレシートを使用しない別の例としては、購入内容を特定するコードを入力するようなインターフェースにしてもよい。この場合には、入力されたコードに基づいて、管理サーバ側で照会を行い、購入の詳細情報を別途取得する処理を実行してもよい。
【0055】
また、キャッシュバック先の情報の入力に関しては、例えば、図６に示すように、まず、金融エンティティの選択を可能にするインターフェース画面を、第１のＷｅｂサーバが提供してもよい。
【0056】
金融エンティティを選択した後は（例えば、図６に示す複数のラジオボタンのいずれかを選択した後は）、選択された金融エンティティの特性に応じて、入力に必要な項目を切り替えて表示させるように、インターフェース画面を、第１のＷｅｂサーバが提供してもよい。
【0057】
例えば、金融エンティティとして、銀行などの金融機関を選択した場合には、図７に示すように、本店名（又は金融機関コード）、支店名（又は支店コード）、預金種別（又は預金種別コード）、口座番号、口座名義人などの入力項目を、インターフェース画面に表示させてもよい。一方で、電子マネーを選択した場合には、そのアカウント等の入力項目を、インターフェース画面に表示させてもよい。例えば、図８に示すように、選択された電子マネーの種類に対応する管理番号の入力項目を表示するようにしてもよい。あるいは、図９に示すように、選択された電子マネーの種類に対応する管理番号と、当該管理番号に関連付けされた電話番号の少なくとも一部の入力項目を表示するようにしてもよい。このように、同じ電子マネーであっても、選択された内容に応じて、入力項目を切り替えてもよい。あるいは、図１０に示すように、ＡＴＭと連携した金融エンティティが選択された場合には、お客様番号、受取人氏名、受取人フリガナなどの入力項目を表示するようにしてもよい。
【0058】
こうした入力項目の切り替えは、例えば、上述した金融エンティティデータベースにおいて、各金融エンティティに対応する入力項目を管理しておき、第１のＷｅｂサーバが、当該データベースの情報を取得し、取得した情報に基づいて、インターフェース生成モジュールが表示項目を生成するようにしてもよい。あるいは、キャンペーンごとに異なるＵＲＬ管理をしている場合には、個々のＵＲＬごとにカスタマイズを行ってもよい。
【0059】
第１のＷｅｂサーバは、レシート情報の入力、及び、キャッシュバック先の情報の入力以外に、例えば、申込者の基本情報を入力するためのインターフェースを提供してもよい。基本情報としては、例えば、名前、フリガナ、性別、年齢、職業、メールアドレス、郵便番号、住所、連絡先電話番号、規約同意のチェックなどが含まれてもよい。また、基本情報以外に、例えば、アンケート情報などの入力項目、入力内容の最終確認画面等を表示させてもよい。消費者の情報処理端末では、例えば、最終確認画面等を経て、申込を示す動作を実行する。
【0060】
このようにして、第１のＷｅｂサーバが、消費者の端末からのキャッシュバック申込情報を受信することができる。受信後、第１のＷｅｂサーバは、管理サーバへ、キャッシュバック申込情報を送信することができる。
【0061】
５－２．管理サーバによる処理（消費者からのキャッシュバック申込の記録）
管理サーバは、第１のＷｅｂサーバから送信されたキャッシュバック申込情報に対して種々の処理を実行することができる。これに対応して、管理サーバは、上述した各種モジュール、或いは、それ以外のモジュールを備えることができる。
管理サーバは、第１のＷｅｂサーバから送信されたキャッシュバック申込情報に対して種々の処理を実行することができる。これに対応して、管理サーバは、上述した各種モジュール、或いは、それ以外のモジュールを備えることができる。
【0062】
まず、管理サーバのキャッシュバック申込受付モジュールは、キャッシュバック申込情報を記録する。記録する場所は、特に限定されず、ローカルの記憶媒体であってもよく、或いは、クラウド上のストレージであってもよい。
【0063】
記録する形式は、特に限定されないが、典型的にはデータベース（例えば、キャッシュバック申込データベース等）に適合した形式で記憶することが好ましい。例えば、リレーショナルデータベースであれば、テーブル形式することが好ましい。
【0064】
５－３．管理サーバによる処理（キャッシュバック申込記録の処理）
キャッシュバック申込情報を記録した後、管理サーバの購買条件マッチングモジュールが、キャッシュバック申込情報からテキストデータを生成することができる、或いは、読み込むことができる。好ましくは、キャッシュバック申込情報に含まれるレシート情報からテキストデータを生成することができる。別の好ましい例では、キャッシュバック申込情報に含まれる、購入内容を特定するコードに基づいて、テキストデータを生成することができる。
キャッシュバック申込情報を記録した後、管理サーバの購買条件マッチングモジュールが、キャッシュバック申込情報からテキストデータを生成することができる、或いは、読み込むことができる。好ましくは、キャッシュバック申込情報に含まれるレシート情報からテキストデータを生成することができる。別の好ましい例では、キャッシュバック申込情報に含まれる、購入内容を特定するコードに基づいて、テキストデータを生成することができる。
【0065】
テキストデータを生成する、又は、読み込むための仕組み等は特に限定されず、レシート情報の形式に応じて適宜設定することができる。例えば、レシート情報が、テキスト形式のＰＤＦファイルである場合には、当該ファイルに埋め込まれているテキストデータを抽出するように構成されてもよい。
【0066】
レシート情報が、画像データである場合（例えば、画像形式のＰＤＦファイル、レシートの写真（例えば、ＪＰＥＧ、Ｇｉｆ、ＰＮＧなどのデータ））、画像データからテキストデータを生成してもよい。例えば、ＯＣＲなどのツールを利用することで、テキストデータを生成してもよい。
【0067】
また、ＯＣＲツールは、本開示のシステム内で実装することは必要ではなく、ＡＰＩ等を利用して、外部のサービスを利用してもよい。
【0068】
テキストデータ作成後は、購買条件マッチングモジュール（又は、レシート情報収集サブモジュール）は、データベース（例えば、キャッシュバック申込データベース等のレシート情報解析結果等）に当該データを記憶することができる。
【0069】
５－４．管理サーバによる処理（キャッシュバックの適用可否の判定）
テキストデータを作成した後、又は読み取った後は、購買条件マッチングモジュール（例えば、マッチングサブモジュール）は、判定を行うことができる。具体的には、テキストデータの内容が、キャッシュバックキャンペーン適用対象となる条件を満たす購買であるかどうかを判定することができる。
テキストデータを作成した後、又は読み取った後は、購買条件マッチングモジュール（例えば、マッチングサブモジュール）は、判定を行うことができる。具体的には、テキストデータの内容が、キャッシュバックキャンペーン適用対象となる条件を満たす購買であるかどうかを判定することができる。
【0070】
上記判定を行うにあたっては、判定条件の情報を別のソースから取得してもよい。例えば、購買条件マッチングモジュールは、キャッシュバックマスタデータベースから、判定条件を取得してもよい。そして、取得した情報に基づいて、テキストデータに含まれる情報が、キャッシュバックキャンペーン適用対象となる条件を満たす購買であるかどうかを判定してもよい。
【0071】
その後、購買条件マッチングモジュール（例えば、マッチングサブモジュール）は、データベース（例えば、キャッシュバック申込データベース）に判定結果を記憶することができる。
【0072】
６．第２のＷｅｂサーバによる判定結果表示
商品及び／又はサービス提供者は、情報処理端末から第２のＷｅｂサーバにアクセスし、上述したキャッシュバックキャンペーンの申込状況の確認を行う。具体的には、第２のＷｅｂサーバは、適宜認証（ログイン認証処理等）を行った後、情報処理端末からのリクエストに応じて、商品及び／又はサービス提供者が行っている、及び／又は、過去に行ったキャッシュバックキャンペーンに対する申込内容を一覧形式で表示することができる。例えば、図１１に示すように、申込内容を一覧形式で表示することができる。そして、各申込内容の詳細を図１２に示す形式で表示することができる。
商品及び／又はサービス提供者は、情報処理端末から第２のＷｅｂサーバにアクセスし、上述したキャッシュバックキャンペーンの申込状況の確認を行う。具体的には、第２のＷｅｂサーバは、適宜認証（ログイン認証処理等）を行った後、情報処理端末からのリクエストに応じて、商品及び／又はサービス提供者が行っている、及び／又は、過去に行ったキャッシュバックキャンペーンに対する申込内容を一覧形式で表示することができる。例えば、図１１に示すように、申込内容を一覧形式で表示することができる。そして、各申込内容の詳細を図１２に示す形式で表示することができる。
【0073】
表示する項目としては、特に限定されないが、申込者の氏名、レシート情報（例えば、テキスト化した情報、又は、テキスト化する前の画像情報）、購買条件マッチングモジュールによるキャッシュバックの適用可否判定結果、目視での確認結果、送金金額、送金処理の有無、送金処理結果等のうち１以上が挙げられる。これらの情報は、１つの画面にてすべて表示する必要はなく、一覧形式で表示する際には、一部の項目だけにしてもよい。そして、詳細情報を表示する操作に応答して、他の項目を表示するようにしてもよい。
【0074】
商品及び／又はサービス提供者は、申込内容一覧を閲覧しながら、各申込における購買条件マッチングモジュールによるキャッシュバックの適用可否判定結果を確認することができる。例えば、図１１に示す一覧形式から、特定の行の情報を選択後、詳細情報を表示するための操作を行ってもよい。それによって、例えば、図１２に示すような詳細情報画面を表示してもよい。また、レシート情報を別途目視により確認して、購買条件マッチングモジュールの判定結果が正しいかどうかを確認してもよい。目視により確認した結果については、画面上で記録することができる（例えば、図１２では「目視判定結果」の項目を利用）。こうした目的から、申込内容の一覧においては、目視での確認結果を入力するためのインターフェースを、第２のＷｅｂサーバは提供することができる。
【0075】
また、別の一実施形態においては、例えば、目視による確認作業を省略してもよく、その場合には、目視での確認結果の項目は表示項目から省略することができる。
【0076】
７．送金実行
商品及び／又はサービス提供者は、端末の操作を通して、申込内容一覧を閲覧しながら、適宜特定の申込に対して、選択指定を行い、送金の指示をリクエストすることができる。例えば、図１１に示すように、送金実行ボタンなどを設けて送金を実行することができる。
商品及び／又はサービス提供者は、端末の操作を通して、申込内容一覧を閲覧しながら、適宜特定の申込に対して、選択指定を行い、送金の指示をリクエストすることができる。例えば、図１１に示すように、送金実行ボタンなどを設けて送金を実行することができる。
【0077】
当該リクエストは、端末から第２のＷｅｂサーバに送信され、更には、第２のＷｅｂサーバから管理サーバへ送信される。管理サーバの送金実行モジュールは、当該リクエストに基づいて送金指示を行うことができる。
【0078】
送金実行モジュールの送金指示は、キャッシュバック申込情報に含まれる指定された金融エンティティ先に、ネットワークを通して送信される。
【0079】
送信する具体的な宛先などは、例えば、金融エンティティデータベースを利用して取得してもよく、或いは、これに変えて、各金融エンティティが提供するＡＰＩを利用してもよい（その場合には、コールＡＰＩなどをデータベースで管理してもよい）。
【0080】
その後、送信先側のサーバ等で適宜処理され、消費者へキャッシュバックされる。なお、キャッシュバックの処理がうまくいかない場合には、金融エンティティ側のサーバからエラーの通知が送信され、送金実行モジュールが受信する。そして、データベース（例えば、キャッシュバック申込データベース）に、送金処理結果として、失敗した旨の記録が行われる。逆に、送金完了した場合には、金融エンティティ側のサーバから送金完了の通知が送信され、データベースに記録される。
【0081】
８．マスタ生成
上記の一連のステップを実施する前段階として、いくつかのマスタデータを準備しておくことが好ましい。こうしたマスタデータの作成は、マスタ画面にて適宜実行することができる。
上記の一連のステップを実施する前段階として、いくつかのマスタデータを準備しておくことが好ましい。こうしたマスタデータの作成は、マスタ画面にて適宜実行することができる。
【0082】
キャッシュバックに関連するマスタデータとしては、以下のデータが挙げられる。
・キャッシュバックキャンペーンの識別情報
・キャッシュバックキャンペーンの申込受付サイトのＵＲＬ（第１のＷｅｂサーバにて提供されるサイトのＵＲＬ）
・キャッシュバックキャンペーンの管理サイトのＵＲＬ（第２のＷｅｂサーバにて提供されるサイトのＵＲＬ）
・キャッシュバックキャンペーンの識別情報
・キャッシュバックキャンペーンの申込受付サイトのＵＲＬ（第１のＷｅｂサーバにて提供されるサイトのＵＲＬ）
・キャッシュバックキャンペーンの管理サイトのＵＲＬ（第２のＷｅｂサーバにて提供されるサイトのＵＲＬ）
【0083】
また、上記以外に、更に以下のデータが挙げられる。
・商品及び／又はサービス提供者アカウント
・認証パスワード
・キャンペーン名称
・キャッシュバック適用条件
・対応金融エンティティ
・商品及び／又はサービス提供者アカウント
・認証パスワード
・キャンペーン名称
・キャッシュバック適用条件
・対応金融エンティティ
【0084】
金融エンティティに関連するマスタデータもあらかじめ作成しておくことが好ましい。例えば、少なくとも以下の項目のデータを記憶するように構成されることが好ましい。
・金融エンティティ識別情報
・金融エンティティ名称
・種別
・項目１
・項目１プロパティ
・項目２
・項目２プロパティ
…
・項目Ｎ
・項目Ｎプロパティ
・認証コード（送金処理などで、決済機関に接続するのに必要な情報）
・金融エンティティ識別情報
・金融エンティティ名称
・種別
・項目１
・項目１プロパティ
・項目２
・項目２プロパティ
…
・項目Ｎ
・項目Ｎプロパティ
・認証コード（送金処理などで、決済機関に接続するのに必要な情報）
【0085】
以上、発明の具体的な実施形態について説明してきた。上記実施形態は、具体例に過ぎず、本発明は上記実施形態に限定されない。例えば、上述の実施形態の１つに開示された技術的特徴は、他の実施形態に適用することができる。また、特記しない限り、特定の方法については、一部の工程を他の工程の順序と入れ替えることも可能であり、特定の２つの工程の間に更なる工程を追加してもよい。本発明の範囲は、特許請求の範囲によって規定される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
