JP2010250363A - ギフトポイント販売交換システム - Google Patents

Abstract

【課題】商品やサービスの販売に付随するポイントシステムではなく、ポイント自体を販売及び配布するポイントシステムを提供する。
【解決手段】ギフトポイント販売交換システムの運用サーバが、販売したギフトポイントのセット毎に一意に発行されたＩＤと付与された初期ポイント数とを紐付けし残高ポイント数とを対応付けて登録し、配布されたユーザの端末からＩＤと交換先事業者指定と交換先事業者が予めユーザ毎に一意に割り当てた交換番号と交換希望ポイント数とを受信し、対応する交換先事業者のサーバに対して交換番号及び交換希望ポイント数を含む交換実行要求を送信し、ギフトポイントと交換先ポイントとの交換処理の完了通知を受信してＩＤに対応する残高ポイント数を減算する。
【選択図】図１

Description

本発明は、一般的には販売促進若しくは顧客サービスのためのポイントシステムに関し、特に、専ら他のポイントと交換することを目的として発行されるギフトポイント販売交換システムに関する。

従来、商品やサービスを販売する事業者が、顧客サービスとして販売価格に応じたポイント（金銭的価値をもつ仮想媒体）を顧客に付与し、蓄積したポイントを物品や金券に交換させたり、新たな商品等の購入代金の一部に充当させたりするなど種々の特典を提供するシステム、いわゆるポイントシステムが広く知られている。現在では、多種多様な事業者がそれぞれ固有のポイントを発行しており、一人の顧客が、同時に複数の事業者のポイントユーザである状況が一般的となっている。

このような状況に伴って、異なるポイント同士の間で交換を行ったり、複数の異なるポイントを１つの共通ポイントに置換したりするシステムも提供されている。
特許文献１には、複数の事業者の発行した異なるポイント間での交換を可能としたシステムが開示されており、交換元ポイントと交換先ポイントの２つのポイント同士の需給関係から変換比率を決定して、交換を行っている。
特許文献２には、各種ポイントを１つの共通ポイントに変換し、まとめて利用できるシステムが開示されている。共通ポイントを任意の特定のポイントに逆変換することもできるため、共通ポイントを介して１つのポイントを別のポイントへ交換することができる。また、共通ポイントを他のユーザへ譲渡することもできる。

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

特許文献１、２のポイント交換システムは、既存の多種類のポイントを一人のポイントユーザが保有している状況下において、それらの既存の多種類のポイントを有効利用させることを目的としている。特許文献２の共通ポイントも、元々はいずれかの既存ポイントから変換されたものである。そして、既存ポイントは、いずれもそのポイント事業者が、本来の事業である商品販売やサービス販売の割引形態の一つとして提供しているものである。すなわち、既存ポイントは、それを発行すること自体が目的ではなく、あくまで商品やサービスの販売促進を図るための付随的な位置付けでしかない。

本発明は、商品やサービスの販売に付随するポイントシステムではなく、ポイントの発行、その配布及び交換を骨格とするシステム、すなわちポイント自体を販売したり配布したりすることを主目的とするポイントシステムを提供するものである。例えば商品券のように、第三者に無償で贈与することを目的として発行され販売されるポイントは、未だ提案されていない。このようなギフト的性質をもったポイントを、「ギフトポイント」と称することとする。

本発明によるギフトポイント販売交換ポイントシステムは以下の構成を有するものである。
交換先事業者の取り扱う交換先ポイントと交換可能なギフトポイントを購入配布事業者に販売し、該購入配布事業者から該ギフトポイントを配布された該交換先事業者のユーザが該ギフトポイントを該交換先ポイントへ交換するための処理を管理する運用サーバを備えたギフトポイント販売交換システムにおいて、該運用サーバが、前記購入配布事業者に複数のギフトポイントのセットを販売した際、各セット毎に一意に発行されたＩＤと各セットに対し付与された初期ポイント数とを紐付けし、該ＩＤと該初期ポイント数からの残高であるポイント数とを対応付けてデータベースに登録する手段と、前記購入配布事業者からギフトポイントのセットをそのＩＤとともに配布されたユーザの端末から、該配布されたセットのＩＤと、交換先事業者の指定情報と、前記交換先事業者によりユーザ毎に一意に割り当てられた交換番号と、交換希望ポイント数とを含む交換申込情報を受信する手段と、前記交換申込情報に含まれる交換先事業者の指定情報に対応する交換先事業者のサーバに対し、該交換申込情報に含まれる交換番号及び交換希望ポイント数を含む交換実行要求を送信する手段と、ギフトポイントと交換先ポイントとの交換処理を完了した交換先事業者のサーバから完了通知を受信した際、前記交換申込情報に含まれるＩＤ及び交換希望ポイント数に基づいて前記データベースにおける該ＩＤに対応するポイント数を該交換希望ポイント数だけ減算する手段とを有することを特徴とする。
上記システムにおいて、前記運用サーバが、ギフトポイントと交換先ポイントとの交換処理を完了した交換先事業者のサーバから、交換されたギフトポイントの集計結果に基づく精算要求情報を受信する手段をさらに有することが好適である。
上記システムにおいて、前記運用サーバが、前記購入配布事業者に複数のギフトポイントを販売するに先立って、予め所定数のギフトポイントのセットの各々に対し一意となるようにＩＤを発行し、各ＩＤに対して初期ポイント数を紐付けすることなく各ＩＤのみを前記データベースに登録する手段をさらに有し、前記購入配布事業者に複数のギフトポイントを販売する際に、前記データベースに登録されたＩＤから販売するギフトポイントのセット数だけのＩＤを切り取り、該切り取ったＩＤの各々と初期ポイント数とを紐付けすることが好適である。
上記システムにおいて、前記運用サーバが、前記購入配布事業者に複数のギフトポイントのセットを販売するとき、ギフトポイントのセット数と、各セットに対し付与すべき初期ポイント数とを含む申請情報を、管理用ウェブサイトを介して入力させ送信させる手段をさらに有することが好適である。
上記システムにおいて、前記運用サーバが、前記ユーザの端末から交換申込情報を受信するとき、該交換申込情報をユーザ用ウェブサイトを介して入力させ送信させる手段をさらに有することが好適である。

本発明に係るギフトポイントは、発行販売事業者から購入配布事業者へ販売されるものであり、購入配布事業者がユーザへ無償で配布するものである。ユーザは、無償配布されたギフトポイントを、自己の保有する既存の交換先ポイントと交換することができる。交換先ポイントを取り扱う交換先事業者が、発行販売事業者との間で精算することで、最終的にギフトポイントが回収されたことになる。
従って、本発明のギフトポイントは、特定の商品やサービスとは全く無関係に、発行、有効化（所定のポイント数との紐付け）、販売、配布、交換、及び回収という一連の経路で流通する全く新規の概念をもったポイントである。
ギフトポイントは、商品券と同様に特定の商品やサービスとは全く無関係であるので、購入配布事業者は、多種多様な利用形態で自由にギフトポイントを利用することができる。
ギフトポイントは、各セット毎にＩＤ管理されているが、特定のユーザとは関係付けられていないので無記名性があり、この点でも自由な配布が可能である。また、個人情報保護も確保できる。それにも拘わらず、各セット毎に設定されたＩＤにより有効化から交換までを十分に管理することができる。

本発明によるギフトポイント販売交換システムの一実施例の概略構成図である。 本システムを適用するビジネスモデルのフローの概要を示す流れ図である。 運営サーバに接続されたデータベースの発行管理テーブルの構成例である。 運営サーバに接続されたデータベースの残高管理テーブルの構成例である。 運営サーバに接続されたデータベースの交換申込テーブルの構成例である。 運営サーバに接続されたデータベースの交換履歴テーブルの構成例である。 発行販売事業者の保管媒体に格納された発行管理テーブルの構成例である。 購入配布事業者のサーバに接続されたデータベースを形成する各テーブルの構成例である。 交換先事業者のサーバに接続されたデータベースを形成する各テーブルの構成例である。 交換先事業者のサーバに接続されたデータベースを形成する各テーブルの別の構成例である。 ＩＤ発行フローの流れ図である。 ギフトポイント有効化及び販売フローの流れ図である。 ギフトポイント配布フローの流れ図である。 ギフトポイント交換申込フローの流れ図である。 ギフトポイント交換実行フローの流れ図である。

図１は、本発明によるギフトポイント販売交換システムの一実施例の概略構成図である。
本システムを適用するビジネスモデルの局面における構成メンバーは、ギフトポイントを発行し販売する発行販売事業者２、ギフトポイントを購入し配布する購入配布事業者３、ギフトポイントを配布されるユーザ４、及びギフトポイントの交換先ポイントを取り扱う交換先事業者５を含む。購入配布事業者３、ユーザ４及び交換先事業者５は、それぞれ複数存在する。

本システムの技術的局面における主要部は、ギフトポイント運用サーバ（以下、「運用サーバ」と称する）１である。運用サーバ１は、ＡＳＰ(Application Service Provider)として実施することが効率的であるが、発行販売事業者２の主幹サーバの機能として実施してもよい。運用サーバ１は、適宜のコンピュータとして実施され、ＣＰＵが適宜のプログラムをメモリに読み込み実行することで本システムの各機能を実現する。

運用サーバ１のＣＰＵが実行する各処理を、便宜的に各処理部として表すと、ギフトポイントの発行及び登録を記録管理する発行登録処理部１１、ギフトポイントの有効化及び販売を記録管理する有効化販売処理部１２、ギフトポイントの交換申込を受付処理する交換申込処理部１３、ギフトポイントの交換を実行する交換実行処理部１４を有する。さらに、各処理に関する情報をネットワーク６を介して送受信するためにウェブサーバ１５が設けられ、ウェブサーバ１５は、発行登録処理部、有効化販売処理部及び交換実行処理部に関連する管理サイト１７と、交換申込処理部に関連する交換申込サイト１６の各ウェブサイトを構築管理する。

運用サーバ１には、本システムに関連するデータを格納するデータベース１８が接続されている。データベース１８には、例えば、発行管理テーブル１８１、残高管理テーブル１８２、交換申込テーブル１８４、交換履歴テーブル１８５などの各種テーブルが作成され、これらは関係データベースを構成している。

発行販売事業者２には、管理端末２１が有する。管理端末２１は、運用サーバ１の入出力端末として位置付けられる。任意であるが、発行販売事業者２は、管理のためにギフトポイントの発行記録を保管した媒体２２を保有してもよい。

購入配布事業者３がギフトポイントを購入し配布する目的は多様であり、特に限定されない。本発明のギフトポイントの配布は、基本的に無償で行われる。例えば、新規顧客獲得のために配布したり、長期利用顧客への特典として配布したりする利用形態がある。また、その配布方法は購入配布事業者３の自由裁量に任される。但し、本発明のギフトポイントの実体は電子データであるから、電子的な情報伝達手段を用いて配布されることとなる。具体例は後述する。

購入配布事業者３は、購入配布事業者サーバ３１を有する。購入配布事業者サーバ３１は、購入配布事業者３の本来の業務サーバに付加した機能として実施してもよく、本システム用の専用サーバとして実施してもよい。購入配布事業者サーバ３１には、本システムに関連するデータを格納するデータベース３２を接続されている。データベース３２には、例えば、購入管理テーブル３２１、配布管理テーブル３２２などの各種テーブルが作成されている。

ユーザ４は、本システムのユーザであると同時に、交換先事業者５に登録されたユーザでもある。少なくとも、ユーザが本発明のギフトポイントを交換先ポイントと交換する時点で、当該ユーザが交換先事業者の登録ユーザとなっている必要がある。ユーザ４は、パーソナルコンピュータ又は携帯端末等のユーザ端末４を用いて本システムを利用する。

交換先事業者５は、既存のポイントシステムを運営する事業者であるが、ポイントシステム自体は本来の業務ではなく、例えば、インターネット販売業者、旅行会社、各種交通機関企業等である。これらの事業者のポイントシステムでは、その本来の業務に係る商品やサービスの販売価格に応じてユーザ（顧客）に対してポイントを付与し、蓄積ポイントと各種特典とを交換する。交換先事業者５は交換先事業者サーバ５１を有する。交換先事業者サーバ５１は、交換先事業者５の本来の業務サーバに付加した機能として実施してもよく、本システム用の専用サーバとして実施してもよい。交換先事業者サーバ５１には、本システムに関連するデータを格納するデータベース５２を接続されている。データベース５２には、交換先ユーザ管理テーブル５２１、交換先残高管理テーブル５２２、交換先交換履歴テーブル５２３が作成されている。

運用サーバ１、管理端末２１、購入配布事業者サーバ３１、ユーザ端末４１及び交換先事業者サーバ５１は、ネットワーク６を介して情報伝送可能に接続されている。

図２は、本システムを適用するビジネスモデルのフローの概要を示す流れ図である。
先ず、発行販売事業者はギフトポイントを発行する。ギフトポイントの発行とは、ギフトポイントの電子データを新規に作成することを意味する。購入配布事業者にギフトポイントを販売する。購入配布事業者はギフトポイントを購入する（ステップ２０１）。ギフトポイントの販売及び購入とは、代価と引き替えにギフトポイントの電子データを授受することを意味する。

ギフトポイントを購入した購入配布事業者は、任意の時点でギフトポイントをユーザに配布する（ステップ２０２）。ギフトポイントの配布とは、ギフトポイントの電子データを渡すことである。

ギフトポイントを配布されたユーザは、任意の時点でギフトポイントを交換先ポイントと交換する（ステップ２０３）。ギフトポイントと交換先ポイントの交換とは、ギフトポイントの電子データを、金銭的価値が同等である交換先ポイントの電子データに変換することである。

ギフトポイントを交換先ポイントに交換させた交換先事業者は、交換したギフトポイントに相当する代価を発行販売事業者に対して請求する（ステップ２０４）。この精算が完了することで、発行したギフトポイントの回収が完了する。

図３〜図７は、運営サーバ１に接続されたデータベース１８を形成する各テーブルの構成例を示す。各テーブルは共通するデータ項目を介して連動している。以下の説明においては、図１で用いた符号を参照する場合がある。

図３は、発行管理テーブル１８１の構成例である。データ項目として、「発行ＩＤ」３０１、「ＰＩＮ」３０２、「発行日」３０３、「有効期限条件」３０４、「有効化フラグ」３０５、「回収完了フラグ」３０６がある。発行ＩＤ(以下、単に「ＩＤ」と称する場合がある)３０１は、ひとまとまりのギフトポイントすなわちギフトポイントの１セットに対して一意に設定される識別番号である。ＰＩＮ３０２は、各ＩＤ毎に設定されるパスワードである。発行日３０３は、ギフトポイントの発行日すなわちＩＤ３０１の設定日である。有効期限条件３０４は、ギフトポイントの有効期限の決定条件を規定している。有効化フラグ３０５は、初期値が"０"であり、ギフトポイントが有効化された時点で"１"とされる。ＩＤの発行時点ではポイント数は設定されない。回収完了フラグ３０６は、初期値が"０"であり、１セットのギフトポイントのポイント数が全て交換された時点で"１"とされる。また、未有効化又は未交換であっても、有効期限を経過した時点で"１"とされる。

図３の発行管理テーブル１８１は、2009年6月15日経過時点の状態を例示している。また、この状態は、図４以降のテーブルの状態の例示とも連動している。2009年3月1日に、ＩＤが"G00001"から"G50000"までの５万セットのギフトポイントが発行されている。6月15日経過時点では、ＩＤが"G00001"から"G30000"までの３万セットのギフトポイントが有効化されている。また、この時点では、ＩＤが"G00002"のセットのみが回収完了している。

図４は、残高管理テーブル１８２の構成例である。データ項目として、「販売先」４０１、「発行ＩＤ」４０２、「有効化日」４０３、「有効期限」４０４、「ポイント残高」４０５がある。販売先４０１は、図１の購入配布事業者３である。有効化日４０３は、ＩＤに対してポイント数が紐付けられることにより、ギフトポイントが有効化される日である。通常、有効化日に購入配布事業者３への販売が実行されるので、有効化日は販売日でもある。有効期限４０４は、発行管理テーブル１８１の有効期限条件に基づいて決定される。ポイント残高４０５は、有効化日の時点では、初期ポイント数が入力される。ギフトポイントの交換が実行される毎に、交換されたポイント数だけ減算され、更新される。

図４の残高管理テーブル１８２は、2009年6月15日経過時点の状態を示している。2009年4月1日に、ＩＤが"G00001"から"G20000"までの２万セットのギフトポイントが"ＸＸ株式会社"に販売され、初期ポイント数は"5000"である。6月15日経過時点で、ＩＤが"G00001"のセットのポイント残高は"1000"に減算されている。また、"G00002"のセットのポイント残高は"0"となっており、回収が完了している。
また、2009年5月1日に、ＩＤが"G20001"から"G30000"までの１万セットのギフトポイントが"ＹＹ株式会社"に販売され、初期ポイント数は"10000"である。6月15日経過時点で、ＩＤが"G20002"のセットのポイント残高は"5000"に減算されている。

図５は、交換申込テーブル１８４の構成例である。データ項目として、「申込日」５０１、「発行ＩＤ」５０２、「交換ポイント数」５０３、「交換先」５０４、「交換番号」５０５、「交換完了フラグ」５０６がある。ユーザ４による１回のギフトポイントの交換申込を１件として、申込日順に逐次記録される。申込日５０１は、交換を申し込んだ日である。交換ポイント数５０３は、交換を希望するポイント数であり、残高管理テーブル１８２のポイント残高以下の数値であれば受け付けられる。交換先５０４は、希望する交換先ポイントの交換先事業者５である。交換番号５０５は、当該ユーザ４が交換先事業者５から予め割り当てられていたポイント交換用の番号である。交換完了フラグ５０６は、初期値が"０"であり、当該申込件に係る交換が実行された後に"１"とされる。

交換番号５０５について補足すると、これは、交換先事業者５が自己のポイントシステムの顧客（本システムのユーザ４でもある）のために一意に割り当てたものである。この交換番号５０５は、交換先事業者５がギフトポイントを交換先ポイントに交換する処理に用いる。一方、運用サーバ１は交換申込の受付の際に交換番号をユーザ４から取得するが、運用サーバ１自体は、ユーザ４がその交換番号の正当な保有者であるかを判断する個人情報を一切保有していないので、交換番号の入力が適切か否かをチェックデジットで確認する程度である。従って、運用サーバ１は、交換実行を交換先事業者５へ依頼する際にそのまま渡すのみである。このように、本システムでは、運用サーバ１が（すなわち発行販売事業者２が）、ユーザ４の個人情報を認識することは全くないという特徴がある。これにより、ユーザ４の無記名性が確保されるので、購入配布事業者３は、ギフトポイントを多様な形態で利用可能となる。

交換先事業者５は、自己の運営するポイントシステムの全顧客に対して交換番号を割り当ててもよく、あるいは、ギフトポイントから交換先ポイントへの交換を希望する顧客に対してのみ、交換番号を割り当ててもよい。どのような交換番号を生成するかは、交換先事業者５に委ねられる。例えば、交換先事業者５が本来の業務又は自己のポイントシステムのために顧客に割り当てたユーザＩＤをそのまま交換番号として利用してもよいし、ユーザＩＤとは別個に交換番号を割り当ててもよい。

図５の交換申込テーブル１８４は、2009年5月1日〜6月14日の期間の申込件の記録を示している。また、テーブルの状態は、6月15日経過時点である。図示の例では、実際のポイント交換は、毎月２回、１日と１５日に実行されることになっている。従って、5月1日〜5月14日の申込件は5月15日に交換実行され、5月15日〜5月31日の申込件は6月1日に交換実行され、6月1日〜6月14日の申込件は6月15日に交換実行されている。

図６は、交換履歴テーブル１８５の構成例である。データ項目として、「発行ＩＤ」６０１、「交換日」６０２、「交換ポイント数」６０３、「交換先」６０４がある。ＩＤ毎に交換実績を記録する。交換日６０２は、交換実行した日である。

図６の交換履歴テーブル１８５は、2009年6月15日経過時点である。ＩＤが"G00001"のセットは、5月15日に2000のギフトポイントをＡネット市場のポイントと交換し、6月15日に2000のギフトポイントをＣネットトラベルのポイントと交換している。この時点で、ＩＤが"G00001"のセットは"4000"のギフトポイントを交換済みである。これは、図４の残高管理テーブルにおいてＩＤが"G00001"のセットのポイント残高が"1000"であることと一致する。また、ＩＤが"G00002"のセットは"5000"の全ギフトポイントを交換済みであり、これは、図４の残高管理テーブルにおいてＩＤが"G00002"のセットのポイント残高が"0"であることと一致する。

図７は、発行販売事業者２の保管媒体２２に格納された発行管理テーブル２２１の構成例である。データ項目として、「発行ＩＤ」７０１、「ＰＩＮ」７０２、「発行日」７０３、「有効期限条件」７０４がある。このテーブルは、図３の発行管理テーブル１８１の一部を切り出したものである。発行販売事業者２は、ＩＤ発行時点でこの保管媒体２２を入手する。ギフトポイントの流通及び交換による状況変化は、管理端末２１から運営サーバ１にアクセスすることで把握できるので、この保管媒体２２の主な役割は、初期データのバックアップである。

図８は、購入配布事業者３のサーバ３１に接続されたデータベース３２を形成する各テーブルの構成例である。購入配布事業者３が、"ＸＸ株式会社"の例である。
図８の購入管理テーブル３２１は、購入配布事業者３が発行販売事業者からギフトポイントを購入する毎に逐次記録される。データ項目として、「発行ＩＤ」８０１、「ＰＩＮ」８０２、「購入日」８０３、「有効期限」８０４、「ポイント数」８０５、「配布済フラグ」８０６がある。購入管理テーブル３２１の内容は、図４の運営サーバの残高管理テーブル１８２の内容とほぼ一致している。2009年4月1日にＩＤが"G00001"から"G20000"の２万セットのギフトポイントを購入しているが、この購入管理テーブル３２１の購入日８０３は、残高管理テーブル１８２の有効化日４０２に一致する。但し、購入管理テーブル３２１のポイント数８０５には、残高管理テーブル１８２のポイント残高４０４の初期値が記録され、変動しない。１セットのギフトポイントは、初期ポイント数のまま分割されずに購入配布事業者３からユーザ４に配布されるためである。配布済みフラグ８０６は、初期値が"０"であり、配布が完了すると"１"とされる。

図８の配布管理テーブル３２２は、購入配布事業者３がユーザ４に対してギフトポイントを配布する毎に逐次記録される。データ項目として、「発行ＩＤ」８０１、「配布日」８０７、「配布先アドレス」８０８がある。配布日８０５は、ユーザ４に対してギフトポイントが配布された日である。ギフトポイントの配布はセット単位で行われる。配布先アドレス８０６は、ユーザ４の利用するユーザ端末４１に設定された電子メールアドレスである。購入配布事業者３は、配布対象のユーザ４の電子メールアドレスを予め入手しておく必要がある。この入手方法は本発明の範疇ではない。例えば、ユーザ４が購入配布事業者３の本来業務における既存顧客の場合、顧客情報の一つとして保有している。また、ユーザ４が購入配布事業者３の本来業務における新規顧客の場合、新規顧客情報の１つとして入手する。

図示の例では、2009年4月15日にＩＤが"G00001"から"G10000"の１万セットのギフトポイントを、１万人のユーザ４にそれぞれ配布している。これは4月1日に購入した２万セットのうちの半分に相当する。具体的には、対象の電子メールアドレス宛にギフトポイントの電子データを送信する。詳細は後述する。配布が完了すると、購入管理テーブル３２１の配布済みフラグ８０６を"１"とする。

図９は、交換先事業者５のサーバ５１に接続されたデータベース５２を形成する各テーブルの構成例である。交換先事業者５が、"Ａネット市場"の例である。
図９の交換先ユーザ管理テーブル５２１は、交換先事業者５が自己のポイントシステムの顧客情報として通常保有するユーザ管理テーブルであるが、本システムに適応させたデータ項目として「交換番号」９０３を設けている。交換番号については、図５で説明した通りである。「ユーザＩＤ」９０１及び「ＰＩＮ」９０２などのデータ項目は、交換先事業者５が本来の業務又は自己のポイントシステムのために顧客に割り当てたものである。

図９の交換先残高管理テーブル５２２は、交換先事業者５が自己のポイントシステムにおける顧客のポイント残高を管理するためのテーブルである。従って、「ポイント残高」９０４は、交換先ポイントの残高である。ギフトポイントから交換先ポイントへの交換が実行されると交換先ポイントの残高は加算されることになる。

図９の交換先交換履歴テーブル５２３は、交換先事業者５が、ギフトポイントから交換先ポイントへの交換を実行する毎に逐次記録される。データ項目として、「交換日」９０５、「ユーザＩＤ」９０１、「ギフトポイント数」９０６、「交換先ポイント数」９０７がある。ギフトポイント数９０６と交換先ポイント数９０７は、金銭的価値が同等となるように変換されるが、変換方法や変換率については本発明の範疇外であり、限定しない。

図９の交換先交換履歴テーブル５２３は、2009年6月15日経過時点の状態を示している。図示の例では、毎月２回、1日と15日に交換が実行される。図５の交換申込テーブル１８４及び図６の交換履歴テーブル１８５を参照すると、Ａネット市場を交換先とする申込は、5月1日と6月10日に発生しており、それぞれ5月15日と6月15日に交換実行されている。図９の交換先交換履歴テーブル５２３の記録はこれらと一致している。
また、残高管理テーブル５２２では、6月15日の交換実行により、ユーザＩＤが"ANM002"のポイント残高は、前日までの"12000"に"2500"だけ加算されて"14500"となっている。

図１０は、交換先事業者５のサーバ５１に接続されたデータベース５２を形成する各テーブルの別の構成例である。交換先事業者５が、"Ｂネット書店"の例である。
図１０の交換先ユーザ管理テーブル５２１は、図９のものとほぼ同じであるが、異なる点は、交換先事業者５における顧客のユーザＩＤをそのまま、本システムのための交換番号として利用している点である。図１０の交換先残高管理テーブル５２２及び交換先交換履歴テーブル５２３は、図９のものと同じである。

図１０の交換先交換履歴テーブル５２３は、2009年6月1日経過時点の状態を示している。図５の交換申込テーブル１８４及び図６の交換履歴テーブル１８５を参照すると、Ｂネット書店を交換先とする申込は、5月20日に発生しており、6月1日に交換実行されている。図１０の交換先交換履歴テーブル５２３の記録はこれらと一致している。また、残高管理テーブル５２２では、6月1日の交換実行により、ユーザＩＤが"B667"のポイント残高は、前日までの"2000"に"5000"だけ加算されて"7000"となっている。

図１１〜図１５は、本システムの各処理フローを示す流れ図である。各フローはいずれも例示であり、本発明の基本構成に沿う範囲において変形が可能である。説明において、図１〜図１０で用いた符号を参照する場合がある。また、流れ図の中で、点線囲いの工程は、コンピュータ処理以外の操作、あるいは本発明の範疇外の操作を意味する。

図１１は、ＩＤ発行フローの流れ図である。発行販売事業者端末（管理端末）２１は、運用サーバ１の管理サイト１７へアクセスし、ＩＤ発行申請画面の表示を要求する（ステップ１１０１）。

運用サーバ１は、管理サイト１７のＩＤ発行申請画面を表示させる（ステップ１１０２）。ＩＤ発行申請画面には、ＩＤ発行に必要な情報の入力欄が設けられており、管理端末２１において入力操作を行う。入力する情報は、申請件を識別する適宜の件名、発行するＩＤの数、有効期限（又は有効期限条件）等である。入力完了後、ＩＤ発行申請情報を送信する（ステップ１１０３）。

運用サーバ１は、ＩＤ発行申請情報を受信し、発行処理を実行する。要求された数のＩＤを新規に設定する。各ＩＤは、ギフトポイントの各セットのＩＤである。この段階ではポイント数は設定されない。設定した新規ＩＤに関するＩＤ発行情報を発行管理テーブル１８１へ登録する（ステップ１１０４）。発行管理テーブル１８１の有効化フラグ及び回収完了フラグを"０"に設定する。その後、運用サーバ１は、申請完了通知を、管理サイトを介して管理端末２１へ送信する（ステップ１１０５）。

管理端末２１は、申請完了通知を受信する（ステップ１１０６）。さらにその後、運用サーバ１は、ＩＤ発行情報例えば図８の発行管理テーブル２２１を適宜の記録媒体に保存する（ステップ１１０７）。その記録媒体を発行販売事業者２へ送付する（ステップ１１０８）。発行販売事業者２は、記録媒体を受領し保管する（ステップ１１０９）。

発行販売事業者２は、例えば、半年分若しくは１年分といった長期間に販売する予定のギフトポイントの全セット数を、一括して発行させ、それらのＩＤを保管しておく。これにより、購入配布事業者３から購入申込があったときに直ちに対応できる。

図１２は、ギフトポイント有効化及び販売フローの流れ図である。購入配布事業者３は、発行販売事業者２に対し、ギフトポイントの発注を行う（ステップ１２０１）。電話やＦＡＸで行ってもよいが、自動化する場合は、サーバ３１と運用サーバ１の間の処理となる。発注情報には、購入するギフトポイントのセット数すなわちＩＤ数と、各ＩＤに付与されるポイント数が含まれる。各セットに同じポイント数を付与するように指定してもよく、また、必要に応じて付与するポイント数をセット毎に異ならせるように指定してもよい。発行販売事業者２は、ギフトポイントの発注を受け付ける（ステップ１２０２）。発行販売事業者２は、管理端末２１から管理サイト１７へアクセスし、ポイント有効化申請画面の表示を要求する（ステップ１２０３）。

運用サーバ１は、管理サイト１７のポイント有効化申請画面を表示させる（ステップ１２０４）。ポイント有効化申請画面には、ポイント有効化及び販売に必要な情報の入力欄が設けられており、管理端末２１において入力操作を行う。入力する情報は、有効化件を識別する適宜の件名、有効化するＩＤの数、各ＩＤに紐付ける付与ポイント数、購入配布事業者情報等である。入力完了後、ポイント有効化申請情報を送信する（ステップ１２０５）。

運用サーバ１は、ポイント有効化申請情報を受信し、有効化処理を実行する。要求された数のＩＤを、発行済みＩＤから切り取るすなわち抽出する。さらに、切り取った各ＩＤ毎に、要求された付与ポイント数を割り当てる。この段階で、ＩＤと初期ポイント数とが初めて紐付けられる。続いて、これら初期のポイント残高情報を、残高管理テーブル１８２へ登録する。最後に、発行管理テーブル１８１における有効化済みＩＤの有効化フラグを"１"に更新する（ステップ１２０６）。その後、運用サーバ１は、申請完了通知を、管理サイトを介して管理端末２１へ送信する（ステップ１２０７）。

管理端末２１は、申請完了通知を受信する（ステップ１２０８）。さらにその後、運用サーバ１は、初期ポイント残高情報を適宜の記録媒体に保存する（ステップ１２０９）。その記録媒体を購入配布事業者３へ送付する（ステップ１２１０）。購入配布事業者３は、記録媒体を受領する（ステップ１２１１）。購入配布事業者３は、記録媒体の初期ポイント残高情報に基づいて、データベース３１の購入管理テーブル３２１にポイント購入情報を格納する（ステップ１２１２）。

なお、別の実施例として、初期ポイント残高情報は、ネットワーク６を介して運用サーバ１から購入配布事業者サーバ３１へ送信してもよい。
図示しないが、購入配布事業者３は、発行販売事業者２に対し、購入したギフトポイントの代価を支払う。

図１３は、ギフトポイント配布フローの流れ図である。ユーザ４は、購入配布事業者３に対し、予め電子メールアドレスを提示ないしは通知する（ステップ１３０１）。購入配布事業者３は、ユーザ４の電子メールアドレスを取得し、保存しておく（ステップ１３０２）。

ギフトポイントの配布日時は、購入配布事業者３が適宜決定する。配布日時になったとき、購入配布事業者サーバ３１は、配布対象のユーザ４の電子メールアドレスに対して、購入管理テーブル３２１に格納された未配布のギフトポイントのＩＤを紐付ける（ステップ１３０３）。続いて、ギフトポイント情報を含む電子メールを送信する（ステップ１３０４）。ギフトポイント情報には、ギフトポイントのＩＤ、当該ＩＤのＰＩＮ、初期ポイント数、有効期限等が含まれる。ＩＤ、ＰＩＮ及び初期ポイント数は必須である。

ユーザ端末４１は、電子メールを受信する（ステップ１３０５）。ユーザ４は、ギフトポイント情報をユーザ端末４１の記憶装置等に適宜保存しておく。

一方、運用サーバ１は、ＩＤと電子メールアドレスの紐付けと配布日を配布管理テーブル３２２に格納するとともに、購入管理テーブル３２１の配布済みフラグを"１"とする（ステップ１３０６）。

図１４は、ギフトポイント交換申込フローの流れ図である。ユーザ４は、有効期限内であればいつでもギフトポイントを交換先ポイントに交換できる。また、ユーザ４が、複数の交換先事業者に登録されたユーザである場合、それらの中から所望する交換先ポイントを選択してギフトポイントの交換対象とすることができる。
交換を希望するとき、ユーザ端末４１から運用サーバ１の交換サイトへアクセスする（ステップ１４０１）。運用サーバ１は、交換サイトのログイン画面を表示し、ギフトポイントのＩＤとＰＩＮの入力を要求する（ステップ１４０２）。ユーザ端末４１において、ギフトポイントとともに取得したＩＤとＰＩＮを入力し、送信する（ステップ１４０３）。

運用サーバ１は、発行管理テーブル１８１を参照することにより、入力されたＩＤとＰＩＮが登録されているか否かを判断し、登録されていれば交換サイトへのログインを承認する（ステップ１４０４）。続いて、運用サーバ１は、交換申込画面を表示する（ステップ１４０５）。交換申込画面には、ポイント残高照会を選択する入力欄、交換履歴照会を選択する入力欄、及び、交換申込情報の入力欄が設けられている。ポイント残高照会または交換履歴照会は、必須ではなくユーザがポイント交換の参考とするために任意に選択する。

ユーザ４は、ギフトポイントの残高または過去の履歴を確認したい場合、ユーザ端末４１からポイント残高照会または交換履歴照会の要求を運用サーバ１へ送信する（ステップ１４０６）。

運用サーバ１は、ポイント残高照会の要求を受信したときは、ＩＤに基づいて残高テーブル１８２を参照し、そのＩＤに該当するポイント残高を取得して交換申込画面に表示する。また、交換履歴照会の要求を受信したときは、ＩＤに基づいて交換履歴テーブル１８５を参照し、そのＩＤに該当する交換履歴を取得して交換申込画面に表示する（ステップ１４０７）。

ギフトポイントの交換を申し込む場合、ユーザ端末４１において交換申込情報を入力し、送信する（ステップ１４０８）。交換申込情報には、交換先事業者を指定する情報、その交換先事業者から予め割り当てられた交換番号、及び、交換を希望するギフトポイントのポイント数が含まれる。現在のポイント残高の範囲内であれば任意のポイント数を交換することができる。本システムの特徴は、ギフトポイントを交換する際に、ユーザ４が個人情報を入力する必要がないことである。従って、少なくともギフトポイントの発行販売事業者２に対しては、ユーザ４の無記名性が確保され個人情報保護が図られる。

運用サーバ１は、交換申込情報を受信すると、その中に含まれる交換番号のチェックデジットのチェックを行い、入力が適切であるか否かを判断する（ステップ１４０９）。交換番号の入力が一応適切と判断されれば、その交換申込情報の受付処理を行う。交換番号の入力が不適切と判断されれば、エラーを表示し、再入力を促す。

交換申込情報の受付処理においては、交換を希望するポイント数を残高テーブル１８２のポイント残高から減算する（ステップ１４１０）。但し、この段階では、未だ交換先事業者におけるポイント交換は実行されないので、一応、仮更新としておく。後日、交換先事業者においてポイント交換の実行が不可能となった場合には、ポイント残高の更新を取り消して元の状態に復帰できる。さらに、交換申込テーブル１８４に新規申込件として交換申込情報を格納する（ステップ１４１１）。この時点では、交換完了フラグを"０"とする。その後、交換サイトを介してユーザ端末４１に申込完了通知を送信する（ステップ１４１２）。ユーザ端末４１は、申込完了通知を受信する（ステップ１４１３）。

図１５は、ギフトポイント交換実行フローの流れ図である。ギフトポイントから交換先ポイントへの変換自体は、交換先事業者サーバ５１により実行される。図示の例では、毎月２回（例えば1日と15日）にポイント交換が実行される。別の実施例として、交換申込情報を受け付ける毎に、即座にポイント交換を実行することも可能である。しかしながら、バッチ処理とする方がシステムへの負担が少なく、効率的である。

運用サーバ１は、交換を実行する所定の期日に交換申込テーブル１８４を参照し、対象期間に受け付けた交換申込情報を抽出する（ステップ１５０１）。続いて、運用サーバ１は、抽出した交換申込情報の各々に含まれる交換キーとその交換キーに紐付けられた交換希望ポイント数とを含む交換実行要求を交換先事業者サーバ５１へ送信する（ステップ１５０２）。このとき、ギフトポイントのＩＤは不要である。交換先事業者サーバ５１は、ギフトポイントのＩＤについては関知しておらず、また、交換実行には不要だからである。

交換先事業者サーバ５１は、交換実行要求を受信する（ステップ１５０３）。続いて、交換先事業者サーバ５１は、交換実行要求に含まれる交換番号に基づいて交換先ユーザ管理テーブル５２１を参照し、その交換番号が存在するか否かを判断する（ステップ１５０４）。その交換番号が存在すれば、交換番号が有効であると判断し、その交換番号に紐付けられた交換先ユーザＩＤを取得する。なお、交換先ユーザＩＤと交換番号を兼用している場合は、交換番号をそのまま交換先ユーザＩＤとして認識する。

続いて、交換実行要求に含まれる交換希望ポイント数を、適宜の変換方法に従って交換先ポイントのポイント数に変換する（ステップ１５０５）。さらに、取得した交換先ユーザＩＤに基づいて交換先残高テーブル５２２を参照し、変換した交換先ポイント数をポイント残高に加算する（ステップ１５０６）。その後、交換先事業者サーバ５１は、運用サーバ１に対してポイント交換の完了通知を送信する（１５０７）。

なお、上記ステップ１５０４で交換番号が存在せず、無効であった場合には、ポイント交換は実行不能となる。その場合、交換先事業者サーバ５１は、運用サーバ１に対してポイント交換実行不能エラーを通知する。例えば、ユーザ４が運用サーバ１に対して交換申込を行った時点では、ユーザ４は交換先事業者のユーザでもあったが、ポイント交換を実行する時点では、既に交換先事業者のユーザでなくなっている場合などが、この事例に該当する。

運用サーバ１は、ポイント交換の完了通知を受信する（ステップ１５０８）。続いて、運用サーバ１は、交換申込テーブル１８４の交換完了フラグを"１"に更新するとともに、交換履歴テーブル１８５に交換履歴情報を格納する（ステップ１５０９）。さらに、残高テーブル１８２のポイント残高を確定する（ステップ１５１０）。なお、ポイント交換の完了通知ではなく、ポイント交換実行不能エラーの通知を受信した場合は、残高テーブル１８２のポイント残高を元の状態に復帰させる。

運用サーバ１は、残高テーブル１８２のポイント残高が、確定後に"０"となったか否かを判断し、"０"となった場合は、発行管理テーブル１８１の回収完了フラグを"１"とする。これにより、そのＩＤをもつギフトポイントのセットに含まれる全ポイント数が交換されたことになり、回収が完了したことになる。

一方、交換先事業者サーバ５１は、ポイント交換の実行後、交換先交換履歴テーブル５２３に交換履歴情報を格納する（ステップ１５１２）。その後、定期的にギフトポイントの精算処理を行う。交換先事業者サーバ５１は、対象期間に交換先交換履歴テーブル５２３に記録された交換履歴情報に含まれるギフトポイントのポイント数を集計する。集計結果に基づいて、交換事業者５は、発行販売事業者２に対して精算要求情報を送付する（ステップ１５１３）。発行販売事業者２は、精算要求情報を受領し、交換されたギフトポイントに相当する代価を交換先事業者５に支払うことにより精算を実行する。

１ ギフトポイント運用サーバ
１１ 発行登録処理部
１２ 有効化販売処理部
１３ 交換申込処理部
１４ 交換実行処理部
１５ ウェブサーバ
１６ 交換申込サイト
１７ 管理サイト
１８ データベース
２ 発行販売事業者
２１ 管理端末
３ 購入配布事業者
３１ 購入配布事業者端末
４ ユーザ
４１ ユーザ端末
５ 交換先事業者
５１ 交換先事業者サーバ

Claims (5)

1. 交換先事業者の取り扱う交換先ポイントと交換可能なギフトポイントを購入配布事業者に販売し、該購入配布事業者から該ギフトポイントを配布された該交換先事業者のユーザが該ギフトポイントを該交換先ポイントへ交換するための処理を管理する運用サーバを備えたギフトポイント販売交換システムにおいて、該運用サーバが、
   前記購入配布事業者に複数のギフトポイントのセットを販売した際、各セット毎に一意に発行されたＩＤと各セットに対し付与された初期ポイント数とを紐付けし、該ＩＤと該初期ポイント数からの残高であるポイント数とを対応付けてデータベースに登録する手段と、
   前記購入配布事業者からギフトポイントのセットをそのＩＤとともに配布されたユーザの端末から、該配布されたセットのＩＤと、交換先事業者の指定情報と、前記交換先事業者によりユーザ毎に一意に割り当てられた交換番号と、交換希望ポイント数とを含む交換申込情報を受信する手段と、
   前記交換申込情報に含まれる交換先事業者の指定情報に対応する交換先事業者のサーバに対し、該交換申込情報に含まれる交換番号及び交換希望ポイント数を含む交換実行要求を送信する手段と、
   ギフトポイントと交換先ポイントとの交換処理を完了した交換先事業者のサーバから完了通知を受信した際、前記交換申込情報に含まれるＩＤ及び交換希望ポイント数に基づいて前記データベースにおける該ＩＤに対応するポイント数を該交換希望ポイント数だけ減算する手段とを有することを特徴とする
   ギフトポイント販売交換システム。
2. 前記運用サーバが、ギフトポイントと交換先ポイントとの交換処理を完了した交換先事業者のサーバから、交換されたギフトポイントの集計結果に基づく精算要求情報を受信する手段をさらに有することを特徴とする請求項１に記載のギフトポイント
3. 前記運用サーバが、前記購入配布事業者に複数のギフトポイントを販売するに先立って、予め所定数のギフトポイントのセットの各々に対し一意となるようにＩＤを発行し、各ＩＤに対して初期ポイント数を紐付けすることなく各ＩＤのみを前記データベースに登録する手段をさらに有し、
   前記購入配布事業者に複数のギフトポイントを販売する際に、前記データベースに登録されたＩＤから販売するギフトポイントのセット数だけのＩＤを切り取り、該切り取ったＩＤの各々と初期ポイント数とを紐付けすることを特徴とする請求項１に記載のギフトポイント販売交換システム。
4. 前記運用サーバが、前記購入配布事業者に複数のギフトポイントのセットを販売するとき、ギフトポイントのセット数と、各セットに対し付与すべき初期ポイント数とを含む申請情報を、管理用ウェブサイトを介して入力させ送信させる手段をさらに有することを特徴とする請求項１に記載のギフトポイント販売交換システム。
5. 前記運用サーバが、前記ユーザの端末から交換申込情報を受信するとき、該交換申込情報をユーザ用ウェブサイトを介して入力させ送信させる手段をさらに有することを特徴とする請求項１に記載のギフトポイント販売交換システム。

Images