JP4327167B2 - ポイント発行装置、および、ポイント発行方法 - Google Patents

Description

本発明は、ネットワーク上に構築された仮想商店街において、商取り引きに伴う販売促進用サービスとしてのポイントサービスを実現するためのポイントサービスシステムに関する。

商店街でよく使われてきた顧客のロックイン（囲い込み）や販売促進の方法の１つとして、スタンプサービスがある。これは商品の購入金額に応じてクーポン券の発行などを行い、そのクーポン券などが一定の数に達した時点で景品などと交換したりするものである。

また、紙のクーポン券を使わずに顧客に磁気カードを持たせ、その磁気カードに記録されたサービスポイントを商品購入に際して、または景品などの交換に際して更新する方式もある。

この場合磁気カードはポイントを記録しておくだけでなく、本人のＩＤ（会員番号など）としての役割も持っている。なおクーポン券を使うにしても、カードを利用するにしても、商店街の中の全ての商店について、クーポン券やポイントを発行する条件（以下、買物の金額に対するポイントの発行率と称する。）、および還元する条件（以下、ポイントの還元率と称する。）は一律とされて、システムの運用がなされている。いずれのシステムも、各地の地域密着型の駅前商店街、銀座商店街など、多くの商店街で導入されている。

更に近年では顧客の商品購入形態も来店購入に止まらず、電話やパソコンなどを利用した通信販売も盛んになっており、またネットワーク上、例えばインターネットに接続された利用者端末に商品を表示（展示）し、顧客がその端末を使って買物をすることも実現されるようになっている。複数商店の商品が展示されている場合、そのような商店によって構成される商店街は仮想商店街（ショッピングモール）と言われる。このような場合には、従来の来店購入の場合のようなポイントサービスは実現されていなかった。

上述のクーポン券などを使用するスタンプサービスでは、消費者側ではクーポン券を台紙に貼る手間がかかったり、クーポン券の保存が面倒であるなどの問題点があり、また商店側ではクーポン券の事前購入による費用負担、手続きの煩わしさや、商品販売時に販売金額に応じたクーポン券の枚数を確認して顧客に渡さなければならないなどという面倒な作業を強いられるという問題点があった。

このような問題点を解決する目的で、ＰＯＳ（ポイント オブ セール）を利用したポイントサービスシステムが開発された。このシステムでは顧客が商品に対して精算を済ませた時点で、ＰＯＳ端末を利用してサービスポイントをホストシステムで集計し、例えば顧客に持たせている磁気カードに記録されたサービスポイントを更新するというような方式がとられている。

しかしながら、このように磁気カードを利用したポイントサービスシステムにおいても、顧客は常に商品購入時に磁気カードを携帯しなければならないという問題点や、磁気カードにサービスポイントの集計結果が記録されても、一般にポイントの発行店と還元店の間での精算は、例えばホストセンタを介して夜間バッチ方式で行われるために、買物の翌日にならないとポイントが有効にならず、景品との交換などが依然として不便であり、またポイント発行店と還元店の間での精算に時間がかかるという問題点があった。

本発明は、ネットワーク上に構築された仮想商店街におけるポイントサービスシステムを実現することにより、前述の問題点を解決すること、例えば顧客の磁気カードなどの携帯を不要とし、またポイントの発行から還元までの時間を短くして顧客へのサービスを向上させることを目的とする。更に例えば発行店でのポイント発行率を、店により、また時期により変化可能とすることなどにより、商店間の競争を促進し、顧客へのサービスが良く、商店への集客力の高い仮想商店街を実現することを目的とする。

図１は本発明の仮想商店街におけるポイントサービスシステムの原理構成ブロック図である。同図はネットワーク上、例えばインターネット上に構築された仮想商店街におけるポイントサービスシステムの原理構成を示し、仮想商店街は例えばインターネット上の特定のサーバ、すなわちウェブサーバの１つによって提供されているものとする。

図１においてポイント発行手段１は、顧客の買物の金額に応じてポイントを発行するものである。このポイント発行に際して、ポイント発行手段１は、顧客が買物をする商店名、買物金額等の入力情報に基づいて、仮想商店街の商店毎に設定されているポイント発行率、例えば１００円の買物に対して何ポイントのポイントを発行するかの発行率に応じて、ポイントの発行を行う。

ポイント管理手段２は、顧客毎のポイントの保有量を、例えばポイントの発行店に対応させて記憶するものである。
ポイント還元手段３は、顧客のポイント保有量に応じたポイントの還元として、顧客の買物支払い金額を減額させるものであり、例えば商店毎に設定されているポイント還元率に応じて、買物支払い金額を減額させる処理を実行する。

本発明において、顧客が仮想商店街のホームページ中で買物を行おうとすると、仮想商店街を構成する各商店のデータに対応させて、その顧客に対して各商店において発行され、現在有効である保有ポイント数が顧客側の端末に表示される。顧客はこの表示画面から適当な商店を選択し、買物ボタンを押すと注文の入力画面が表示され、顧客はその注文画面に注文データを入力し、注文ボタンを押すことにより、仮想商店街のウェブサーバにリンクしたポイントサービスシステムが起動され、ポイントの発行と、また注文時の顧客の指定に応じてポイントの還元サービスが実行される。

このように本発明においては、ネットワーク上に構築される仮想商店街にポイントサービスシステムを実現することによって、前述の目的を達成することが可能となる。
以下に、本発明の具体的な操作イメージについて説明する。

利用者が、たとえば仮想商店街のホームページをそのＵＲＬを使って開く。仮想商店街のホームページにリンクしたデータベースに登録してある商店街があらわれる。たとえば宝石店、衣料店、食品店のハイパーリンク又はイメージマップがあらわれる。ユーザが好みの商店へのハイパーリンクをクリックすると、その商店の商品名、イメージ、値段が画面にあらわれる。その好みの商品をクリックすることによって購入操作を行う。その商品はその商店から利用者に直送されて支払い決済される。

各商店が仮想商店街に加入すれば、仮想商店街のホームページにポイントサービスを受けられる旨の表示をする。
利用者が、たとえば服を購入したいときは、ポイントサービスを受けられる仮想商店街を利用した方が有利となる。各商店にとってもポイントサービスが顧客の吸引力となり、さらに仮想商店街のホームページに登録することによって宣伝効果も期待できる。仮想商店街をホームページに作成したサービスプロバイダにとっても、たとえば加入商店から加盟料あるいは購買額に応じたコミッション料を受け取ることができる。

利用者が仮想商店街を使用したいときには登録操作を行う。仮想商店街におけるデータベースにおいて、その利用者用の領域が割り当てられ、ユーザＩＤ、ユーザパスワードがその利用者に与えられる。なお、ユーザＩＤは利用者によって固定であるが、ユーザパスワードは利用者にとって自由に設定しなおすことが可能である。

利用者は仮想商店街にアクセスして自分のポイントと購入履歴を見ることができる。利用者が電子メール（ｅ−ｍａｉｌ）アドレスを有していれば、仮想商店街から現在のポイントを利用者に定期的に送るようにしてもよい。

以上説明したように本発明によれば、仮想商店街においてポイントサービスシステムを実現することによって、利用者側の利点として第１に買物のための交通費が不要になるなどネットワーク上での買物が便利であること、第２にポイントの即還元などの有利な点があること、第３にカードなどの携帯が不必要であること、第４に現在の保有ポイント数を簡単に把握できること、第５に商店間での競争によって利用者へのサービス向上が期待できることなど様々な利点がある。

商店側の利点としては第１に仮想商店街における集客力を向上させることによる売上げの増加、第２にポイントの事前購入が不必要であること、第３にカードなどの発行が不必要であること、第４に商店毎に独自できめこまかなサービスを実現できることなどの様々な利点があり、仮想商店街の発展に寄与するところが大きい。

図２は本発明の仮想商店街１０におけるポイントサービスシステム２を実現するネットワークの構成例の説明図である。同図において複数のサーバ１１，１２、および１３はネットワーク、例えばインターネットを構成しており、例えばサーバ１１、すなわちウェブサーバは仮想商店街１０を提供するものであり、サーバ１１にはポイントサービスシステムにおけるポイントデータや商店のデータを記憶する、後述のポイント管理テーブルや商店管理テーブルが格納されているサーバファイル１４が接続されているものとする。

例えばサーバ１２は、従来の仮想商店街にもネットワークを介して接続されており、サーバ１２を利用する利用者ｄ，ｅ，ｆは従来の仮想商店街にアクセスすることも、また本発明のポイントサービスシステムを有する仮想商店街１０にアクセスすることも可能である。仮想商店街１０は商店Ａ，Ｂ，Ｃ，・・・によって構成されているものとし、ここではこれらの商店は独自のサーバを持っていない場合を例としてポイントサービスシステムを説明するが、独自のサーバを持ちながら別の仮想商店街に出店することも可能である。

図３はインターネット上で本発明を実現するための仮想商店街のシステム構成ブロック図である。同図において仮想商店街はインターネット上のウェブサーバプログラム１５、図２のサーバファイル１４に対応し、後述するポイント管理テーブル、商店管理テーブルなどのデータを格納するデータベース１６、およびウェブサーバプログラム１５とデータベース１６の間のインタフェースプログラムとしてのＣＧＩ（コモン ゲート ウェイ インタフェース）プログラム１７から構成されている。

ウェブサーバプログラム１５はＨＴＴＰ（ハイパー テキスト トランスファ プロトコル）に基づいて処理を行うプログラムであり、利用者がＵＲＬ（ユニフォーム リソース ロケータ）によって指定したＨＴＭＬ（ハイパー テキスト マークアップ ランゲージ）ファイルを利用者に送信する。このＨＴＭＬファイルには、利用者に見せるべき情報の他に、関連するＨＴＭＬファイルのＵＲＬが格納されており、利用者がクライアント端末からそのＵＲＬを指定することにより、そのＵＲＬがネットワークを経由してウェブサーバプログラム１５に送信され、そのＵＲＬによって指定されるＨＴＭＬファイルが利用者に送られる。

またウェブサーバプログラム１５は、利用者が指定したＵＲＬが特定のもの、すなわちｃｇｉ−bin のディレクトリ下のファイルの場合には、そのファイル、すなわちプログラムを実行する。ここで実行されるプログラムはＣＧＩプログラム１７である。ＣＧＩプログラム１７は、例えばＳＱＬ（ストラクチャード クエリィ ランゲージ）言語をデータベース問い合わせ言語として発行し、データベース１６の管理は図示しないデータベースマネージメントシステム（ＤＢＭＳ）によって実行されることになる。

図４は仮想商店街の中に実現されるポイントサービスシステムの構成ブロック図である。同図においてポイントサービスシステム２０は、仮想商店街の顧客の保有するポイントを顧客毎に、またその発行時点毎に記憶するポイント管理テーブル、仮想商店街を構成する各商店のポイント発行率や還元率を、各商店毎に記憶する商店管理テーブルなどを格納するサーバファイル２１、顧客が商品を購入する毎にポイントを発行するポイント発行部２２、顧客の指定に応じて顧客の保持するポイントを還元して、顧客の商品購入価額を減額させるポイント還元部２３、顧客の保有するポイントの期限などを監視して、期限切れ間近のポイントがある場合に、対応する顧客にメールによって期限切れを知らせる処理などを行うパトロール部２４から構成されている。

ここで、サーバファイル２１は図３のデータベース１６上に設定され、ポイント発行部２２、ポイント還元部２３は図３のＣＧＩプログラム１７として登録されたものであり、パトロール部２４は図３のＣＧＩプログラム１７又は特には図示しない、例えば定期的に実行される独立したプログラムとして登録されたものである。

このポイントサービスシステム２０は、顧客が買物をしようとして商品の注文などを行う場合に、図３のウェブサーバプログラム１５からのリクエストによって起動される。また後述するように、買物代金がクレジットで引き落とされた場合などにも、特には図示しないプログラムによって起動される。

図５は顧客が仮想商店街（以下モールとも称する）にアクセスする場合の処理の流れの説明図である。同図において顧客、すなわちクライアントが仮想商店街を利用しようとする時には、 [１] でモールを管理するサーバ、すなわちモールサーバ（図３に対応）に仮想商店街に対する接続を要求し、モールサーバ内のウェブサーバプログラム１５（図３）はこの接続要求に対して [２] で、仮想商店街の各商店のデータや、そのクライアントが各商店で発行されたポイントの保有数などを示す仮想商店街の画面をＨＴＴＰデータ（ＨＴＭＬファイル）としてクライアント側に送信し、クライアントは受信したＨＴＴＰデータに基づいて画面表示を行い、利用者が [３] でその画面上で適当な商店を選択すると、クライアントは [４] でモールサーバに対して注文画面に対応するＵＲＬを送信し、モールサーバはＵＲＬに基づいて注文用の画面を [５] でクライアント側に送信する。

利用者が [６] で端末を利用して注文内容を入力すると、その注文内容はそれを処理するプログラムのＵＲＬと共にモールサーバ側に送信される。モールサーバ側では受信した注文内容をパラメータとしてＵＲＬのＣＧＩプログラムを起動し、起動されたプログラムは、注文受付処理として後述するポイント管理テーブル、および商店管理テーブルの内容を用いてポイント処理、すなわちポイントの発行処理、またはポイントの還元処理などを行い、商店、すなわちショップ側に処理結果や売上を通知する。

図６は、図５の [２] においてモールサーバからクライアント側に送信される仮想商店街の表示画面例（ホームページ）の説明図である。同図は仮想商店街を構成する各ショップの商品内容、値段、宣伝文句などのデータを示すと共に、そのクライアント、すなわち顧客が各ショップから発行され、現在保有中のポイント数と、その保有ポイントの中で最も有効期限までの期間が短いもの、すなわち一番古い有効期限、および各ショップ毎のポイントの発行率、還元率が表示される。

例えばショップＢに対する「４００」はポイントの保有数であり、０９０４０１はその中で最も古い有効期限が平成９年４月１日であることを示し、さらに図９に示すように発行率が１００、還元率が１であることが示されている。またショップＦに対する「特」は特別サービスの実施中であることを示し、またショップＥに対する「＊＊＊」はポイントサービスを行っていない店舗であることを示す。なお１つの画面上に全てのショップのデータが表示できない時には、スクロールによってその他のショップのデータが表示される。ショップの数が多い場合は、顧客の保有ポイント数が多い順序でショップのデータを表示することが顧客にとって便利とも考えられる。

図６においてクライアント、すなわち顧客が目当ての商店を選択し、買物ボタンを押すことにより、図５の [４] の動作に入り、 [５] でモールサーバから注文用の画面が送信される。

図７は、図５のクライアント側からの [１] での仮想商店街への接続要求に応じて、モールサーバ側で作成され、クライアント側に送信される仮想商店街画面データの作成処理フローチャートである。このフローは、図３のＣＧＩプログラム１７の一部に対応する。同図において処理が開始されると、まずステップＳ１で利用者に顧客ＩＤを入力させるためのＨＴＴＰデータがモールサーバからクライアントに送信される。クライアント側で利用者が顧客ＩＤを入力すると、そのＩＤが画面を作成するプログラムのＵＲＬと共にサーバ側にステップＳ２で送信される。この画面を作成するプログラムのＵＲＬは、ステップＳ１でサーバからクライアントに送信されるＨＴＴＰデータに含まれている。

その後ステップＳ３からＳ７までの処理が、仮想商店街を構成する各商店について、それぞれ繰り返される。まずステップＳ３では、その商店が取り扱っている商品の内容、値段、宣伝文句などの商店情報が設定され、ステップＳ４でポイントサービスの実施店か否かが判定され、実施店でない場合にはステップＳ５で当該商店に対応してサービス不実施の表示が設定され、その商店に対する処理を終了し、他の商店に対してステップＳ３以降の処理が繰り返される。

ステップＳ４でポイントサービスの実施店であると判定された時には、ステップＳ６で図８に示すポイント管理テーブルの内容を参照して、そのクライアント、すなわちその顧客のその商店で発行されたポイントの保有数、および最古期限などが設定される。

図８はポイント管理テーブルの例の説明図である。同図においては、その仮想商店街の顧客のそれぞれに対してポイントの保有数が、そのポイントの発行店毎に格納されている。すなわちポイントが発行される毎にその発行日（購入日）、有効期限、ポイント数、発行店（購入店）、および有効フラグの内容が設定される。有効フラグが０となっていることは、後述するようにクレジット、口座引落し、口座振込など代金後払いで品物が購入され、まだ代金が精算されていないことを示す。

代金後払い購入の場合には、後述するように実際に代金の精算が行われ、入金された時点で有効フラグが１とされる。このように有効フラグを用いてポイントの有効／無効を制御する方法以外に、代金の入金後に過去にさかのぼり、再度ポイント計算をする方法も考えられる。以上の手続きは、入金されない（無効な）買物に対してポイントを発行するという問題を回避するものであるが、商店のリスクにおいて商品受注後直ちにポイントを有効とすることも実践的手法として考えられる。

図８のお知らせ欄のポイント数は、保有ポイント数の総計がこの数に達した時に、後述するパトロール処理によって顧客にメール通知が行われるポイント数を示す。ここでお知らせポイント数が例えば９０００となっているのは、図９で説明するように１０，０００ポイントたまるとポイント発行率が割増しとなるため、それに近づいたことを顧客に通知するためである。

図７のステップＳ６で顧客の保有ポイント数などの設定が行われた後に、ステップＳ７で各商店に対する特別サービス期間情報が設定され、その商店に対応する処理は終了し、次の商店に対するステップＳ３以降の処理が繰り返される。そして仮想商店街を構成する全ての商店に対するステップＳ３〜Ｓ７の処理が終了した時点で、ステップＳ８で商店街画面データのクライアント側への送信が行われ、処理を終了する。商店の数が多い場合にはクライアント端末側での送信待ち時間が大きくなるため、データを分割して送信することも有効である。

図９は、図７のステップＳ７で各商店毎に特別サービス期間情報の設定を行う場合などに参照される商店管理テーブルの例である。同図において、仮想商店街を構成する各商店に対してポイントの発行率、還元率、特別サービス期間の開始および終了時期、割増しポイント率が格納されている。例えば商店Ａに対する発行率１００は１００円で１ポイントのポイント発行が行われることを、また還元率１は１ポイントに対して１円の還元が行われることを、また割増しポイント率の内容は10,000ポイントたまった時点でポイントの発行率が２倍、すわなち１００円で２ポイントの発行になることを示している。発行率、還元率共に０、すなわち商店Ｅに対する値はポイントサービスが実施されていない商店であることを示す。また、ポイントの発行率、還元率を特定の期間のみ変更することも可能であり、図９の商店Ｆでは９６年上半期（１月１日〜６月３０日）が特別サービス期間であり、この期間内では５０円で１ポイント発行されることが示されている。

図１０は、ポイント管理テーブルに記憶されているポイントの有効期限の確認などを行う、パトロール処理のフローチャートである。この処理は例えば毎月末というように定期的に行われるものであり、処理が開始されるとまずステップＳ１１で、図８のポイント管理テーブルの内容が検索され、期限切れが間近となっているポイントが存在するか否かが判定される。存在する場合にはステップＳ１２で当該利用者、すなわち顧客に対する期限切れお知らせメール処理が行われた後に、また期限切れ間近のポイントが存在しない場合にはステップＳ１２の処理を行うことなく、ステップＳ１３の処理に移行する。

ここでメール処理としては電子メール文を組立てて自動的にそのメールを発信する方法と、プリンタによって通知文を印刷し、人手によって郵便で送る方法などがある。前者の場合にはメールＩＤを、後者の場合には郵便住所などをポイント管理テーブル上に記憶しておく必要がある。いずれにせよ、ステップＳ１２ではメール処理を行うだけであり、実際に顧客に通知が発送されているか否か、または顧客によって通知結果が受取られているか否かについてはステップＳ１２で確認されるわけではない。

ステップＳ１３ではポイント管理テーブルの内容のお知らせ欄のポイント数と各顧客のポイント数の集計結果とが比較され、お知らせ対象者が存在するか否かが、また定期的にポイント集計結果を顧客に対してお知らせすることになっている場合にはお知らせ対象者が存在するか否かが判定され、対象者が存在する場合にはステップＳ１４でその利用者、すなわち顧客に対する所定数到達、または定期お知らせメール処理が実行された後に、またお知らせ対象者がない場合にはステップＳ１４の処理を実行することなく、ステップＳ１５の処理に移行する。

ステップＳ１５ではすでに期限の切れたポイントがあるか否かが判定され、ある場合にはそのポイントが無効とされて、パトロール処理を終了する。ポイントを無効にする場合、一定期間（例えば５年程度）、トラブルや問合せなどに備えて、無効状態のまま、そのポイントをポイント管理テーブル、またはアーカイブファイル等に記憶しておくことが望ましい。

図１１は、図６で顧客が買物を行う商店を選択した後に、表示される買物の入力画面であり、図１２はこの入力画面の表示の元となるｈｔｔｐデータである。この入力画面のｈｔｔｐデータには、顧客が仮想商店街の初期画面で入力した顧客ＩＤと、商店の識別情報が格納されている。すなわち、図１２における「＜FORM METHOD=POST ACTION=http://www.mall.aaa.co.jp/cgi-bin/program-a＞」は、この入力画面でデータが入力された後に、program-a の実行をwww.mall.aaa.co.jp というサーバにクライアントより依頼することを示している。また、＜INPUT TYPE=“hidden"NAME=“personal-ID" CHECKED VALUE=“aaa0001"＞は、このprogram-a の実行の依頼の際のパラメータとして送信するものを定義したものであり、すなわち、「personal-ID=aaa0001 」というデータ（顧客ＩＤがaaa0001 という意味）が送信されることが定義されており、「INPUT TYPE=“hidden" 」とはこのデータは表示されないということを定義したものである。また、同様に、＜INPUT TYPE=“hidden" NAME=“store-ID" CHECKED VALUR=“ 宇宙開発" ＞は、このprogram-a の実行の依頼の際のパラメータとして送信するものを定義したものであり、すなわち、「store-ID= 宇宙開発」というデータ（商店名が「宇宙開発」という意味）が送信されることが定義されており、「INPUT TYPE=“hidden" 」とはこのデータは表示されないということを定義したものである。

「＜INPUT TYPE=“checkbox" NAME=“prdl" 」はチェックボックスを画面に表示し、それが指示された場合に、「prdl=yes」というデータ（商品prdlを購入するという意味) をサーバに送信することを定義したものである。後続の「宇宙服」は画面に「宇宙服」という文字列を表示することを意味する。次の「＜INPUT TYPE=“text" NAME=prdl-num SIZE=“2"＞」は「宇宙服」の購入個数を入力する領域を２バイト分表示し、入力されたデータ（「prdl-num= 個数」として）を送信することを示している。＜ＢＲ＞は改行を意味する。また、「宇宙食」「宇宙船」についても同様である。「＜INPUT TYPE=“submit" VALUE=“ 買物" ＞は、「買物」というボタンを表示し、そのボタンが指示されると、上記で説明した処理を実行させるプログラム名およびそのパラメータをサーバに送信することを意味している。また、「＜INPUT TYPE=“reset" VALUE=“中心" ＞」は、「中止」というボタンを表示し、そのボタンが指示されると、これまで入力したパラメータの値をクリアすることを示している。

図１３は、上述の買物ボタンを押すことによって、図５の [５] でモールサーバから送信される注文用画面の例である。この注文用画面のＨＴＴＰデータには、顧客が前述のように商品を選択した際のデータ（商品名、数量）と、前の画面から引き継いでいるデータ（顧客ＩＤ、商店名）と、この画面に対応して実行されるＣＧＩプログラムのＵＲＬが組み込まれている。

図１３において顧客は商品送付先などを入力し、銀行振込、ネットワークマネーまたはクレジット支払いの３つのうちから支払い手段を指定し、ポイントを全部蓄積するか、全部還元するか、あるいは一部還元するか、一部還元の場合にはその還元するポイント数を指定する。また、この買物で得られるポイントを、例えば慈善団体などに寄付したり、例えば家族など他の顧客に付加する場合には、その寄付先などの識別子（ｉｄ）を指定して、注文ボタンを押すことにより、この画面のＨＴＴＰデータ内で指定されているＵＲＬのプログラム、すなわちポイントサービスシステム２０（図４）が起動されることになる。

図１４は図１３において顧客が注文ボタンを押すことによって起動されるポイント発行処理のフローチャートである。このフローは、図３のＣＧＩプログラム１７の一部のプログラムである図４のポイント発行部２２に対応する。同図において処理が開始されると、まずステップＳ２１で顧客が商品の注文を行った商店がポイントサービスの実施店か否かが判定され、実施店でない場合にはステップＳ２８で買物金額がそのまま支払請求額とされて、ポイント発行処理を終了する。ポイント発行処理の後には、図３のＣＧＩプログラム１７の一部のプログラムとして、一般的な注文処理と、代金請求処理が行われる。

ステップＳ２１でポイントサービスの実施店である場合には、ステップＳ２２でその顧客がすでに所有しているポイントの還元を希望し、かつその所有ポイント数がポイント還元サービスを行うための最低ポイントに達しているか否かが判定され、これらの条件を両方とも満足している場合以外はポイントの還元は行われず、ステップＳ２３で発行ポイントの計算が行われる。すなわち買物金額に相当するポイント数が、買物を行った当該店の発行率で算出される。なお還元サービスを行うための最低ポイント数についてはシステム内で一律にする方式と、商店毎に設定する方式との両方が考えられる。

そしてこのポイントが寄付や他の顧客に付加されるものであるか否かが図１３で説明した注文画面での指定によって判定され、自己用のポイントである場合には、ステップＳ２４でその顧客の保有ポイントとしてポイント管理テーブルに購入日から有効フラグ（１）までの内容を設定することによって記憶され、寄付や付加の場合にはステップＳ２５で寄付または付加先に対するポイントとして同様に記憶された後、ステップＳ２６で支払条件が判定される。例えば他の顧客への付加の場合には、買物毎に顧客が付加先を指定する方式と、あらかじめ付加先を登録しておき、自動的にそこに付加する方式とを併用すると便利である。

支払条件が即金払い、例えば電子マネー、電子小切手、電子手形などによって処理される場合には、ステップＳ２８の処理が行われた後に、ポイント発行処理を終了する。またクレジット払い、口座引落し、口座振込などのように事後精算の場合には、ステップＳ２７でそのポイントに対する有効フラグの内容を０とし、ポイントを入金があるまで無効とした後に、ステップＳ２８の処理を行い、処理を終了する。

ステップＳ２２でその顧客がポイントの還元を希望し、かつポイント還元サービスのための最低ポイントに達していると判定された場合には、ステップＳ３０で還元ポイントの計算処理が行われる。この詳細については図１５で説明する。

ステップＳ３０で還元ポイントの計算が行われた後に、ステップＳ３１で計算された還元ポイントの還元が行われた後の各商店に対する保有ポイント数がポイント管理テーブルに記憶され、ステップＳ３２で計算された還元ポイントに基づいて還元額が計算され、ステップＳ３３で買物金額から還元額が減額され、それを支払請求額とした後に処理を終了する。（図１４には示していないが、ステップＳ３３での支払請求額決定と同時に、その金額に対応してステップＳ２３からステップＳ２７の処理が実行され、ポイント発行が行われる。）
図１５は図１４のステップＳ３０、すなわち還元ポイントの計算処理の詳細フローチャートである。このフローは、図３のＣＧＩプログラム１７の一部のプログラムである図４のポイント還元部２３に対応する。同図において処理が開始されると、ステップＳ４０でまず今回買物をした商店と同一店のポイントのうち古いポイントから還元処理に使い、今回買物をした商店のポイント還元率に従って還元ポイントが算出される。そして顧客から指定された還元ポイント数に達しているか否かが判定され、達している場合にはその他の店のポイントを使用する必要はないので、処理を終了する。

不足の場合には、ステップＳ４２で不足分のポイント数を他の店から発行されたポイント保有数のうちで古いものから還元処理に使用することとし、全商店で共通の還元率に従って還元ポイントが算出され、ステップＳ４２で他の店との間でのポイント精算処理を行った後に処理を終了する。なお、他店で発行されたポイントを還元に使用する場合、全商店で共通の還元率ではなく、その店で別途に定められた還元率を用いることも考えられる。

すなわち本実施例においては、ポイントの還元処理において還元すべきポイントとして、まず第１に同一店のポイントから還元することを優先し、また第２に古いポイントから還元することを優先して処理が行われる。例えば図８において顧客ａが店Ｂで買物をするにあたり２５０ポイントの還元を希望する場合には、８年４月１日に商品を購入した際の２００ポイントと、８年４月８日に商品を購入した１００ポイントのうちの５０ポイントが還元に用いられることになる。８年４月２日に店Ｄで商品を購入した時のポイントは、ポイントの有効期限は古いが、他の店で発行されたものであるため、ここでは使われない。

また自商店で発行したポイントの還元率を全店共通の値より高く設定することにより、同じ店で買物をすると顧客が得をする仕組みを作ることができる。
図１５のステップＳ４２で行われる他の店との間でのポイント精算処理については、まず第１の方法としてポイント還元の度にそのつど精算する方法と、第２に一週間、あるいは一カ月とか適当な期間のポイントの増減（還元結果）を蓄積しておき、全ての店の増減をその期間全体に渡って一括処理、すなわち精算する方法と、第３の方法としてポイントを発行する時に発行店が還元相当金額を、例えばショッピングモールの組合などに一時金として預託し、それを精算にあてる方法などが考えられる。

図１６は、例えば定期的に仮想商店街を構成する全商店の間で行われるポイント精算処理に使用される、精算用還元ポイント格納テーブルの例である。このテーブルには、仮想商店街を構成する全ての店舗Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，・・・のそれぞれに対して、顧客が自商店で買物を行い、他の商店で発行されたポイントを還元した場合のポイント還元量と、他商店で買物を行い、その際自商店のポイントが還元された場合のポイント還元量とが、それぞれ累積された値Ｘ，Ｙが記録されている。例えば月末に精算を行う場合には、月末毎にＸとＹとの差が求められ、その値がプラスであれば受取り精算、マイナスであれば支払精算が行われる。例えば顧客がＢ商店で買物をし、その際に２００ポイントをＢ商店発行、５００ポイントをＣ商店発行のポイントで還元した時、このテーブルの中のＢ商店のＸ欄に５００、Ｃ商店のＹ欄に５００のポイント還元数が記録される。このテーブルのＸ−Ｙ欄は、月末精算の処理、すなわちＸとＹとの差が計算された直後の状態を示している。

図１７はクレジット、口座引落し、口座振込などの場合の代金精算時におけるポイント有効化処理の説明図である。このフローは、図３のＣＧＩプログラム１７からは独立した制御プログラムに対応する。図１４のステップＳ２７で説明したように、商品の購入時に代金支払条件としてクレジットなど代金後払いが指定されると、商品購入に対応する発行ポイントに対する有効フラグが０とされ、代金が入金された時点で有効フラグが１に変更される。この場合基本的な考え方として、ポイントの発行率はステップＳ２３で算出されたものが用いられる。例えば年末の特別ポイントサービス期間中に商品を買った場合には、代金が特別サービス期間終了後に入金される場合でも、この特別ポイントサービスが適用される。

図１７において商店又は金融機関等からモールサーバに入金通知があると、まずステップＳ４５でポイント管理テーブルの該当エントリが特定され、ステップＳ４６でそのエントリのポイント有効フラグが１とされ、ステップＳ４７でその顧客の有効ポイント数の合計が求められ、その合計ポイント数がお知らせポイント数に到達している場合にはステップＳ４８でそれを顧客に知らせるお知らせメールの処理が行われた後に、所定数に到達していない場合には何らの処理を行うことなく、処理を終了する。このような代金後払いに対する入金通知の処理は、まとめて実行することにより効率を上げることができ、商店又は金融機関からモールサーバに複数の入金通知が同時にあったような場合には、ステップＳ４５からステップＳ４８の処理を反復して行えばよい。

図１８は、図９に示した商店管理テーブルの内容を、各商店のサーバから変更するような場合の入力画面の例である。このような画面を用いて、各商店のサーバから商店管理テーブルの内容の新規設定、変更、または削除が可能となる。商店管理テーブルのデータを悪意を持って改ざんするような行為が許されると甚大な被害が発生するため、この商店管理テーブルに対するアクセス権限などについて、セキュリティを守るための万全の処置が必要である。

なお、仮想商店街のホームページ内の商店をクリックすることにより、遠隔地にあるその商店のホームページにアクセスするようにしてもよい。この場合、購入情報はその仮想商店街のホームページにリンクしたデータベースと商店のホームページにリンクしたデータベースに同時に格納されるように設定される。当該商店がその仮想商店街に加盟したとき、その商店のホームページにリンクしたデータベースに登録されている購入情報が既存のネットワーク転送コマンドを使って仮想商店街のホームページにリンクしたデータベースにも通知されるようにする。この場合利用者は仮想商店街のホームページから商店へのホームページにアクセスして、その商店からの購入にあたっては、当該仮想商店街のポイントサービスを受ける旨、利用者が一度登録すればその後は商店のホームページを用いて直接購買をしても、利用者はポイントサービスシステムを利用できる。さらに各商店は、そのホームページのリンクしたデータベースを常時更新することにより、その商店の最新の商品を利用者に提供することを容易にする。

最後に本発明のポイントサービスシステムを実現するためのプログラムのローディングについて説明する。図１９は本実施例としての仮想商店街におけるポイントサービスシステムを実現するためのプログラムが記録された記憶媒体の説明図である。同図においてコンピュータ１０１は本体１０４とメモリ１０５とから構成されており、本体１０４に対しては可搬型記憶媒体１０２からプログラムなどをロードすることも、またプログラム提供者側からネットワーク１０３を介してプログラムなどをローディングすることも可能である。

コンピュータ１０１の本体１０４は図２において仮想商店街１０を構成するサーバ１１に相当し、またメモリ１０５はサーバファイル１４に相当するものと考えることができる。

図４におけるポイントサービスシステムを構成するポイント発行部２２、ポイント還元部２３、およびパトロール部２４などは、例えば前述のように図３のＣＧＩプログラム１７として登録されるが、そのＣＧＩプログラム１７は例えば図１９におけるメモリ１０５に格納され、そのプログラムは本体１０４によって実行される。ここでメモリ１０５としては、例えばランダムアクセスメモリ（ＲＡＭ）、またはハードディスクなどが使用される。

またポイントサービスシステムを実現するためのプログラムなどが可搬型記憶媒体１０２に記録され、コンピュータ１０１にそのプログラムをローディングすることによってポイントサービスシステムを実現することも可能である。この可搬型記憶媒体１０２としてはメモリカード、フレキシブルディスク、ＣＤ−ＲＯＭ（コンパクトディスクリードオンリメモリ）、光ディスク、光磁気ディスクなど市販され、流通可能な任意の記憶媒体を使用することができる。また本発明のポイントサービスシステムを実現するためのプログラムなどが、プログラム提供者側からネットワーク１０３を介してコンピュータ１０１側に送られ、そのプログラムがローディングされることによって、仮想商店街におけるポイントサービスシステムを実現することも可能である。

以上本発明の実施例を詳細に説明したが、本発明の実施方法はこの実施例に限定されることなく、特許請求の範囲に記載された範囲内で、この実施例と異なる様々な実施形態を実現することができることは当然である。特に、例えば請求の範囲の買物の内容としては旅行、ホテル、レストラン、劇場などの予約も含まれることは当然である。

本発明の原理構成を示すブロック図である。 本発明のポイントサービスシステムを実現するネットワークの構成例の説明図である。 インターネット上で実現される仮想商店街のシステム構成ブロック図である。 仮想商店街の中に実現されるポイントサービスシステムの構成を示すブロック図である。 顧客が仮想商店街にアクセスする場合の処理の流れの説明図である。 モールサーバから顧客側に送信される仮想商店街の表示画面例を示す図である。 顧客側に送信される仮想商店街画面データの作成処理のフローチャートである。 ポイント管理テーブルの例を示す図である。 商店管理テーブルの例を示す図である。 パトロール処理のフローチャートである。 顧客による商店選択後に表示される買物用入力画面の例を示す図である。 図１１の画面表示の元となるｈｔｔｐデータを説明する図である。 モールサーバから顧客側に送信される注文用画面の例を示す図である。 ポイント発行処理のフローチャートである。 ポイント還元処理の詳細フローチャートである。 精算用還元ポイント格納テーブルの例を示す図である。 クレジット代金等精算時におけるポイント有効化処理のフローチャートである。 商店管理テーブルの内容変更などのための入力画面の例を示す図である。 本実施例を実現するためのプログラムが記録された記憶媒体の説明図である。

符号の説明

１ ポイント発行手段
２ ポイント管理手段
３ ポイント還元手段
１０ 仮想商店街
１１〜１３ サーバ
１４，２１ サーバファイル
１５ ウェブサーバ
１６ データベース
１７ ＣＧＩ（コモン ゲートウェイ インタフェース）
２０ ポイントサービスシステム
２２ ポイント発行部
２３ ポイント還元部
２４ パトロール部

Claims (2)

1. 商品購入に伴うサービスポイントを発行するポイント発行装置であって、
   購入金額に対するポイントの発行数として定義されるポイント発行率を記億する管理テーブルと、
   顧客識別情報、および、顧客識別情報に対応づけて購入毎のボイント保有量、および、ポイン保有量の有効無効を識別する有効フラグを記憶する顧客テーブルと、
   顧客端末からの購入情報に基づき、前記管理テーブルに記憶されるポイント発行率に基づき該購入金額に相当するポイント数を算出し前記顧客テーブルに、購入した顧客の顧客識別情報に対応づけて算出した該ポイント数を該購入のポイント保有量として記録するとともに、該購入のポイント保有量の有効フラグを無効に設定し、購入した商品の購入金額の入金後に、該顧客テーブルにおいて、該購入のポイント保有量の有効フラグを有効に設定する発行手段とを
   備えることを特徴とするポイント発行装置。
2. 商品購入に伴うサービスポイントを発行するポイント発行方法であって、コンピュータが、
   顧客端末からの購入情報に基づき、購入金額に対するポイントの発行数として定義されるポイント発行率を記憶する管理テーブルに記憶されるポイント発行率に基づき、該購入金額に相当するポイント数を算出し、顧客識別情報、および、顧客識別情報に対応づけて購入毎のポイント保有量、および、ボイント保有量の有効無効を識別する有効フラグを記憶する顧客テーブルに、算出した該ポイント数を該購入のポイント保有量として記録するとともに、該購入のポイント保有量の有効フラグを無効に設定する算出ステップと、
   購入した商品の前記購入金額の入金後に、前記顧客テーブルにおいて、該購入のポイント保有量の有効フラグを有効に設定する発行ステップとを
   備えることを特徴とするポイント発行方法。

Images