説明

クレジットカード処理のインフラを使用してクーポン割引を提供する方法及びシステム

クーポン(105)が、クーポン発行者のクレジットカード番号またはデビットカード番号などのアカウント識別子で符号化される。このクーポンは、磁気ストライプカードまたはスマートカードなどの、バーコード化されたクーポン、つまりクーポンカードであってよい。そのバーコード化されたクーポンは、アカウント識別子及び強化された消費者人口統計データなどの他の情報を伝えるために省スペースシンボル(RSS)などの簡潔な二次元記号体系を使用してよい。アカウント識別子、製品またはサービス識別子、及び割引識別子を含むクーポン情報は、販売場所(100)でクーポン(105)から得られる。消費者は割引のために貸方記入される。販売業者識別子を含む該クーポン情報は既存のクレジットカード端末(115)及びANSI X9などの通信プロトコルを使用して処理センタ(135)に通信され、従来のクレジットカード取引またはデビットカード取引のように処理される。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般的には新しい種類のクーポンに関し、そのクーポンを処理するための方法及びシステムに関する。
【背景技術】
【0002】
クーポンは至るところに存在している。印刷されたクーポンは雑誌や新聞、ダイレクトメールのチラシ、店内広告等に見られる。さらに、最近の現象としては消費者が自分のコンピュータとプリンタを使用し、クーポンを印刷できるようにするウェブサイトの使用がある。
【0003】
クーポンには提供されている割引、製造メーカ及び製品に関する情報を保持するためにバーコードが一般的に使用されている。バーコードは引き換えプロセスを容易にするので、バーコードの追加によりクーポンは小売業者、消費者、及び製造メーカに非常に人気が高いものとなった。特に、クーポンは、現在、クーポンを処理するために必要な情報を保持するために統一商品コード(UPC)クーポンコードなどの標準化されたバーコードフォーマットを使用している。UPCクーポンコードは全数字コードである。第1の数字は、それがクーポンを走査していることをPOSシステムに知らせる「5」というナンバーシステムキャラクタである。次に、5桁の会社番号がクーポン付きの(couponed)商品の製造メーカを識別する。次に、3桁のファミリコードが、通常、製品の型を識別する。次に、2桁の価格コードが割引金額、例えばクーポンの引き換え価格を識別する。最後の桁は前の11個の数字から計算されるチェックキャラクタである。
【0004】
さらに1997年以来、UCC/EAN−128クーポン拡張コードが使用されてきた。主要UPCクーポンコードに加えて、追加のバーコードシンボルが他の重要な情報を符号化する。そのコードは最初にナンバーシステムキャラクタ(NSC)を含む。2つの会社が、一方が0というNSC付き、他方が7というNSC付きの同じ製造メーカ番号を持つ可能性があるため、製造メーカのNSCは自動的に拡張コードに含まれる。次に、製造メーカによって発行される5桁のオファーコードが提供される。最後に、4桁のオファー有効期限コードが月/年(つまり07/99)のフォーマットで提供される。統一コード委員会(UCC)はクーポンフォーマットの5つの変形を提供している。
【0005】
従来、クーポンは、バーコードの中を走査することによってPOSで販売業者によって処理される。通常、販売業者は、消費者が適格な製品を購入したことを視覚的にチェックし、クーポンは回収され、定期的に外部の処理施設に郵送され、そこで手作業で処理される。販売業者は1ヶ月以上などかなりの期間、払い戻しを受けるために待たなければならない。
【発明の開示】
【発明が解決しようとする課題】
【0006】
本発明は、既存の通信及びPOSインフラを利用できる自動処理技法とともに、従来の巨大な、印刷されたクーポンの面積の多くを占める、例えばUCC/EAN−128フォーマットに比較して、情報伝達能力が強化されサイズが縮小されたクーポンフォーマットを提供する。本発明は、さらに小規模企業、個人、及び他のエンティティが、クーポンの使用に関する広大な量の人口統計情報及び個人消費者情報を収集できるようにし、クーポンが、関連する製品が購入されたときにだけ引き換えられることを保証する、クーポンを発行できるようにする方法及びシステムを提供する。
【0007】
1つの態様では、販売場所にある既存のクレジットカード及びデビットカードの処理インフラ及びクレジットカード及びデビットカードの処理センタを使用してクーポンの割引が提供される。本発明は、従来のバーコード化されたクーポンと比較して追加のデータを保持できる二次元構成要素を有するバーコード化されたクーポンも提供する。クーポンは特にクレジットカード番号またはデビットカード番号を保持した上で使用するために適している。
【0008】
クーポンによって追加データを保持できるようにし、かつクーポンのフォーマットをクレジットカード取引及びデビットカード取引で必要とされる既存のデータフォーマットに一致するように調整することによって、クーポンは、ある意味で、カスタマに貸し付けられている製造メーカまたは他のクーポン発行者のクレジットカードになる。クーポンの処理は、従来のクレジットカードまたはデビットカードの処理と同様になされるが、消費者は販売場所でクーポン割引を受け、クーポン発行者は割引金額について請求される。販売業者は電子決済(EFT)または他の仕組みを使用して割引について払い戻しを受けられる。したがって、クーポンの処理速度は大幅に加速され、新しいマーケティング機会が生じる。
【0009】
本発明の1つの態様では、販売場所での引き換えに適したバーコード化されたクーポンは、クーポンの発行者のアカウント識別子、製品識別子またはサービスの識別子、及び該製品またはサービスの購入時に消費者に貸方記入され、アカウント識別子に従って発行者に請求される割引金額の識別子を保持するバーコードシンボルを含む。他の態様では、販売場所での引き換えに適したバーコード化されたクーポンは、クーポンの発行者のアカウントの識別子、消費者のアカウントの識別子、及び消費者のアカウントに授与され、発行者のアカウントに請求される賞金金額の識別子を保持するバーコードシンボルを含む。同じデータを保持する磁気ストライプカード及びスマートカードなどの類似するクーポンカードが使用されてよい。バーコード化されたクーポン、磁気ストライプカードまたはスマートカードを販売場所で処理するための類似する方法も提供される。
【0010】
他の態様では、販売場所で販売業者から受け取られるクーポン取引情報を処理するための方法が、クーポン情報からクーポンの発行者のアカウント識別子、販売業者からの製品またはサービスの購入時に消費者に貸方記入された割引金額の識別子、及び販売業者のアカウント識別子を回収することを含む。料金は割引金額の識別子及び発行者のアカウント識別子に従って発行者のアカウントに対して請求され、支払いは割引金額の識別子及び販売業者のアカウント識別子に従って販売業者に代わって提供される。
【0011】
他の態様では、販売場所で販売業者から受け取られるクーポン取引情報を処理するための方法が、クーポン取引情報から、クーポンの発行者のアカウント識別子、消費者に授与される賞金金額の識別子、及び消費者のアカウント識別子を回収することを含む。料金は賞金金額識別子に従って発行者のアカウントに対して請求され、賞金は賞金金額識別子及び消費者のアカウント識別子に従って消費者の代わりに提供される。
【0012】
他の態様では、販売場所でバーコード化されたクーポンの引き換えを許可するための方法が、(a)クーポンを、そこから少なくとも1つの製品識別子を得るために走査することと、(b)そこから少なくとも1つの製品識別子を得るために販売場所で消費者によって購入される少なくとも1つの製品を走査することと、(c)不一致があるかどうかを判断するために、ステップ(a)で得られた製品識別子をステップ(b)で得られた製品識別子と比較することとを含む。不一致がない場合、クーポン引き換えが許可される。不一致がある場合には、引き換えは許可されない。
【0013】
関係するコンピュータプログラム製品も提供される。
【課題を解決するための手段】
【0014】
本発明によれば、クーポンで使用される記号体系をUCC/EAN−128コードから省スペースシンボル(RSS)または他の簡潔な及び/または二次元の記号体系に変更することによって、バーコードシンボルに含むことができる膨大な追加情報のために機能性が大幅に改善されたクーポンを作ることができる。さらに、クレジットカード取引のフォーマットを模倣することによって、バーコード、磁気ストライプ、及びスマートカードを利用するクーポンは、既存のまたは古くからあるクレジットカード処理のインフラを使用してクレジットカード取引のように処理できる。これは、クーポンに関連する追加データを伝達するだけではなく、関係する金銭の迅速な処理という利点も与え、それによって多大な新しいマーケティング機会を切り開く。引き換えセンタによって引き換えのためにクーポンを回収するという退屈さも回避される。さらに、本発明は、バーコード化されたクーポンに一次元シンボルと二次元シンボルの両方を与えることにより便利に段階的に導入できる。
【0015】
図1は、クーポン処理システムを示す。販売場所(POS)100は小売店、セルフサービスキオスク、バーチャルな場所、消費者の家、または販売業者が製品またはサービスを販売する他の事業場所であってよい。「販売業者」という用語は、基本的に、一般の人々、政府、企業対企業等にサービスを提供する企業を含む、製品またはサービスを提供する任意の企業を包含することが意図される。「販売する」、「購買する」等の用語は、従来の意味での販売に加え、製品及び他の装置の賃貸も包含することが意図される。スキャナ/リーダ110は、その内のどれかが本発明によるデータで符号化されている、バーコード化されたクーポン105を走査し、あるいはクーポンカードなどの磁気ストライプカードまたはスマートカードを読み取る。スキャナ/リーダ110には、情報を読み取り、それを販売業者コンピュータシステム120またはクレジットカード端末115に通信するためのソフトウェアが備えられる。磁気ストライプカードは既知のスワイプ式(swipe)リーダを使用して読み取られてよく、スマートカードは既知のスマートカードリーダを使用して読み取られてよい。したがって、紙などの基体の上に印刷されるバーコードシンボルを含むバーコード化されたクーポンに加えて、本発明は、同等のデータを記憶する磁気ストライプカード及びスマートカードなどの他のデータ記憶媒体とともに使用されてよい。多くの最新のPOS場所は既に、一次元バーコードと二次元バーコードの両方を読み取ることができるスキャナを備えている。RSSに適合したスキャナの一例はシンボルテクノロジーズ社(Symbol Technologies,Inc.)製のサイクロン(Cyclone)である。スキャナ110が一次元バーコードのみを読み取ることができ、二次元バーコードは読み取ることができない場合は、例えば、スキャナ110はRSS適応ではなく、クーポンの従来のバーコード部分が読み取られる。あるいは、RSS対応の別個の専用の次元スキャナ112が提供されてよい。スキャナ/リーダ112は、クレジットカード端末115と連動して動作するスタンドアロンRSSクーポン端末であってよい。それは電力及び他の端末/スキャナと共用されてよい電話回線を必要とする。スキャナ/リーダ112は、RSSクーポンだけを走査するためにレジカウンタに設置される第2のハンドヘルドスキャナを使用してよい。したがって、スキャナ/リーダ110がRSS対応ではないとき、別個の専用スキャナ/リーダ112はクーポンを走査する、または読み取るために使用されてよい。スキャナ/リーダ110がRSS対応である場合、別個の専用スキャナ/リーダ112は必要とされない。さらに、クーポンは、レジ係及び消費者に、それらが二次元スキャナによる処理を必要とすることを知らせるグラフィックスと添付テキストを有する場合がある。
【0016】
二次元バーコード用の走査装置は、小規模企業にとっても十分手頃となってきている。事実上、本発明から引き出される利点は、過去にスキャナに対するニーズがなかった企業にスキャナを入手することを奨励する。これは、消費者に製品ではなくおもにサービスを提供する美容院、旅行代理店、娯楽施設等のサービス業界の企業を含む。本発明に従って提供されるクーポンは従来のクーポンと同様に処理、走査されるため、レジ係及び消費者は特別な訓練を必要としない。さらに、すべての処理は電子的に発生するため、クーポンはそれらが走査された後に廃棄できる。廃棄されたクーポンは、誤用を防止するため例えば破砕することによって破壊される。この目的のためにスキャナ/リーダ110または112の中にシュレッダーを内蔵してもよい。
【0017】
スキャナ/リーダ110または112は、スワイプ式リーダ及びキーパッドを有してよいクレジットカード端末115と通信する。クレジットカード端末115のRS232ポートはスキャナ/リーダ110または112からデータを受信するために使用されてよい。このようなポートは、キーボードなどの周辺装置と接続するために利用される。クレジットカード端末115は、企業において、それらの製品またはサービスの支払いとしてクレジットカード及びデビットカードを受け入れる、至るところにある型であってよい。ヴェリフォン社(VeriFone,Inc.)は1つの主要な供給業者である。一般的には、クーポン情報は、情報を手作業で入力、バーコードを読み取りして、データをASCIIテキストとして装置に送信するなどの種々の手段、またはクーポンオファーがそのように設計されている場合には、磁気ストライプまたはスマートカード読み取りを介してクレジットカード端末115に伝達できる。スキャナ110は、使用可能な場合、例えばRS232リンクを介して、販売業者コンピュータシステム120と通信してよい。販売業者コンピュータシステム120は、在庫管理及び他の目的のために、購入された製品、売上高等に関する情報を記憶してよい。販売業者コンピュータシステム120はスキャナ110からクーポン情報も記憶してよい。キャッシュレジスタ及びディスプレイ122は、カスタマにそれぞれの購入された商品の価格を知らせるために、技術で既知のような販売業者コンピュータシステム120と通信してよい。
【0018】
本発明によれば、スキャナ/リーダ110または112によって得られる情報は、クレジットカードまたはデビットカードの番号などの、クーポンにより提供される割引を申し出るエンティティであるクーポン発行者のアカウント識別子を含んでよい。さらに後述されるように、このようなアカウント識別子の使用により、既存のスキャナ/リーダ110、クレジットカード端末115、及び既に設置されている上流の処理設備とプロトコルを含む、既存のクレジットカード及びデビットカードの処理インフラを使用してクーポンを電子的に処理できる。製品及び割引などの他のクーポン取引情報はアカウント識別子にピギーバックされ、同様にクレジットカード端末から上流の設備に通信される。クーポン割引は固定額または商品の正規の価格のパーセンテージとして提供されてよい。ある手法では、クレジットカード端末115は、スキャナ/リーダ110または112からのクーポン情報を処理する。別の手法では、クーポン情報は、クレジットカード端末115と類似した機能性を有する販売業者コンピュータシステム120によって処理される。どちらのケースでも、さまざまな取引のクーポン取引情報はクレジットカード端末115または販売業者コンピュータシステム120に記憶されてよい。毎日のように定期的に、クーポン取引情報はバッチジョブとして電話網などの通信網125を介して処理センタ135にアップロードされる。クーポン取引情報は、クレジットカード購入及びデビットカード購入のための既存のプロトコルを使用して通信される点は重要である。クレジットカード取引またはデビットカード取引を記述する複数の関連する規格またはプロトコルがある。基本的な規格は、参照してここに組み込まれるトラック3用バンクカード磁気ストライプデータコンテンツ(Bank Cards Magnetic Strip Data Content for Track 3)と題されるANSI X9.1−1991である。本発明に従って、クーポンのバーコードから読み込まれるデータはトラック3データをエミュレートしてよい。しかしながら、多くの変形も考えられ、本発明は任意のクレジットカードまたはデビットカード処理方式と共に使用できる。クーポンデータのバッチング及び処理は、処理センタ135により提供されるサービスのスケジュールに従って実行されてよい。
【0019】
ANSI X9規格は、クレジットカード番号またはデビットカード番号、カード/支払い種別、有効期限、カード及び消費者が存在するかどうか、取引金額、販売業者識別子、カスタマの郵便番号、取引日付と時刻、などのレジ係によって手作業で入力されるセキュリティ/許可コード、及び他の情報などの取引情報の通信を規定する。本発明とともに使用される際、この情報は「クーポン取引情報」と呼ばれてよい。カスタマがクレジットカードを使用して商品の支払いを行う従来の取引では、消費者に取引の記録を与えるために取引について最高105文字のANSI情報が消費者のクレジットカードの計算書に表示される。しかしながら、本発明では、アカウント識別子はクーポン発行者と関連付けられ、割引金額、製品識別子、消費者データ呼び他の情報を含むクーポン情報が105文字で伝えることができる。
【0020】
特にANSI X9のサブセットは、以下のデータ要素を含んでよいANXI X9.59支払いカードプロセスである。これはクレジットカード取引で予想されることの典型である。この規格はデビットカードにも同様に適用できる。支払いカードは、クレジットカードまたはデビットカードを指す。
【0021】
X9.59署名付き支払い要素:
StandardVersion X9.59プロトコルバージョン
Paycode 販売業者に対する支払い命令
PrcC カスタマアカウント番号(クーポン発行者アカウント番号になる)
LUID (カスタマ)局所一意識別子
PrcM 販売業者アカウント番号/ID
PaydataC 通過種別及び取引金額
DateS 取引日付/時刻
DateE アカウント有効期限
SHS{OD} 注文詳細のハッシュ
DSS{VD} X9.59署名付き要素のデジタル署名
X9.59追補フィールド
StandardVersion X9.59プロトコルバージョン
Paycode 販売業者に対する支払い命令
LUID (カスタマ)局所一意識別子
DateS 取引日付/時刻
SHS{OD} 注文詳細のハッシュ
DSS{VD} X9.59署名付き要素のデジタル署名
しかしながら、多くの変形が可能であり、本発明は任意のクレジットカード処理方式を包含することが意図される。
【0022】
本発明は、クーポン発行者から支払いを得るために処理できる任意のタイプのアカウント識別子との使用に適していることが意図される。これは、ビザ(Visa)、マスターカード(MasterCard)、及びディスカバーカード(Discover Card)などのユニバーサルクレジットカード、アフィニティカード、銀行により発行されるバンクカードを含むクレジットカード、アメリカンエキスプレス(American Express)、ダイナーズクラブ(Diners Club)、及びカルトブランシュ(Carte Blanche)などのエンターテインメントカード、デパートやガソリンスタンドチェーンまたは電話会社などの特定の企業またはチェーンの企業だけで有効なハウスカード、およびANSI X9規格を使用してクレジットカードと同じく処理できる、デビットカードのアカウント番号を含む。ハウスカード、ガソリンカード及びテレフォンカードは多くの場合独自のシステムに従うが、大部分の国内のクレジットカード及びデビットカードは、ANSI規格X4.13−1983規格に従う番号方式を有する。「クレジットカード番号」及び「デビットカード番号」等の語句は、それが数字、文字、他の記号の文字列を含むのか、あるいはその任意の組み合わせを含むのかに関係なく、それぞれ任意のクレジットカードまたはデビットカードの識別子を包含することを意図される。
【0023】
ANSI規格X4.13の下では、クレジットカードまたはデビットカードには15桁のアカウント番号と1個のチェック数字がある。クレジットカード番号の第1の桁は、例えば3が旅行/エンターテインメントカード、4がビザ、5がマスターカード、6がディスカバーカードなどのシステムを意味する。カード番号の構造はシステムごとに変化する。例えば、アメリカンエキスプレスのカード番号は37で始まり、カルトブランシュとダイナーズクラブは38で始まる。例えばアメリカンエキスプレスの場合、桁3と4は種別と通貨であり、桁5から11はアカウント番号であり、桁12から14はアカウント内のカード番号であり、桁15はチェック数字である。ビザの場合、桁2から6は銀行番号であり、桁7から12または7から15はアカウント番号であり、桁13または16がチェック数字である。マスターカードの場合、桁2と3、2から4、2から5または2から6は(桁2が1であるか、2であるか、3であるかあるいはそれ以外であるかに応じて)銀行番号である。銀行番号の後の15までの桁はアカウント番号であり、桁16がチェック数字である。
【0024】
随意的に、クーポン取引情報は各取引後ただちに処理されてよい。追加のオプションはクレジットカード端末115が処理センタ135から各取引の許可コードを得ることである。許可コードは、クレジットアカウントが優良であること、及び使用可能な十分な差引残高があることを保証する。それは従来のクレジットカードの購入のために受け取られるのと同じ許可コードであり、指定された状況で得られてよい。例えば、許可コードは、クーポン割引が特定の金額を超えると得られてよい。これは、例えばそれが指定金額を超えているかどうかを確かめるために割引金額をチェックするソフトウェアを使用して達成できる。コードは、前述されたように、クレジットカード端末115によって記憶され、処理センタ135に定期的にアップロードされる。販売業者は、クレジットカード端末115のプロバイダとのその合意に応じて許可コードを得ることを望んでよい。例えば、販売業者は取引の許可コードを得ることに合意する場合に、未許可のまたは不正な取引の発生が少なくなるため、より低い端末使用月額料金を請求されてよい。他方、コードを待つ間にレジプロセス中に遅延が生じる可能性がある。
【0025】
例えば銀行と関連する場合がある処理センタ135は、従来のカスタマのクレジットカードまたはデビットカードの購入と同様に、POS100から受信されるクーポン取引情報を処理する。しかしながら、本発明によれば、クーポン取引情報のアカウント識別子はクーポン発行者と関連付けられているため、クーポンの発行者のアカウント155はクーポンの割引金額について請求される。サービス料も処理センタ135または他の関係するエンティティによって査定され、サービサーアカウント150に維持される。この料金は、例えば固定料金またはパーセンテージなど、従来のクレジットカードまたはデビットカードの取引で査定される処理料金に類似してよい。それからクーポン取引情報に含まれる割引料金はクーポンを受け入れた販売業者のアカウント165に貸方記入される。販売業者は、既存のプロトコルを使用してクーポン取引状況とともに処理センタ135に通信される販売業者識別子で識別されてよい。処理センタ135にあるデータベースが、電子決済(EFT)のために販売業者識別子を販売業者アカウント番号に関連付けてよい。 あるいは、販売業者アカウント番号自体がクーポン取引情報の中に保持されてよく、その場合、払い戻し金を送るためにデータベースルックアップは必要とされない。後述のように、クレジットが消費者のアカウントに与えられることも可能である。有利なことに、販売業者は、例えば1営業日または2営業日前後で非常に迅速に払い戻しを受けることができる。また、本発明により可能になる短いフロート時間のため、販売業者は、5ドル、10ドル、50ドル以上などより高額のクーポンを進んで受け入れるであろう。したがって、以前ならば消費者に電気製品などのより高いコストの商品に大きな割引を与えるために郵送プログラムによってリベートを行っていたであろう製造業者や他の業者も、今は単に所望の値引きを付けたクーポンを提供することができる。郵便でのリベートを数週間も待つ必要がなく購入時に値引きを受けられるので、消費者はこのようなオファーにさらに反応しやすい。これらのリベートは「クーポンリベート」と呼ばれるであろう。本発明は、このようにして、クーポンが以前ならば例えば1ドル以下のささやかな割引を提供した領域から、数千ドルの購入が日常的に処理される領域にクーポンを移行することによって、クーポンの扱い方においてパラダイムシフトを可能にする。さらにより高額のクーポン割引には、既存のクレジットカード及びデビットカードの処理インフラと同じ保護が与えられる。
【0026】
図2は、クーポン処理方法を示す。ステップ205から225はPOSの場所100で発生してよく、ステップ230から260は処理センタ135で発生してよい。ブロック205では、クレジットカード番号が読み取られ、クーポン105から入力される。受信された情報が、例えば桁数や他の基準に基づき有効なクレジットカードであると考えられない場合、取引は拒否される(ブロック225)。ブロック210では、クーポンの有効期限が切れているかどうか、クーポンの有効期限が調べられる。有効期限が切れている場合、取引は拒否される。ブロック215では、割引の額が得られる。額を読み取ることができない場合、あるいは製品または他の基準と食い違っていると考えられる場合、取引は拒否される。ブロック220では、クーポンの中で符号化される他のデータが得られる。このデータは、クーポンの配布と引き換えに関する情報、及び人口統計データ及び入手可能な場合には個人に関連する特定のデータを含むそれらを引き換える消費者に関する情報など、本発明の手法を使用して符号化できる新しい情報を含む。
【0027】
前記ステップが無事に完了すると、クーポン取引情報はさらに処理される。ブロック230では、発行者のクレジットアカウントまたはデビットアカウントが、それが優良であるかどうか、及び十分な信用限度額があるかどうかを確かめるためにチェックされてよい。これは、前述されたように許可コードを得ることを必要としてよい。一般的には、大きな製造メーカなどの評判のよいクーポン発行者は、処理施設によりクレジットを供与され(extended credit)、処理施設が製造メーカからの支払いを得る前に販売業者に払い戻すようにしてもよい。他のケースでは、処理施設は、販売業者が支払いを受ける前に発行者が現金の預託を提供することを必要とする場合がある。クレジットカードプロトコルに基づいて発行者によってクーポン割引額を支払うためのアカウントに資金を送金させてよい。アカウントは最小の差引残高及びそれに付けられる補充レートを有する場合がある。この点において問題が検知されると、取引は拒否される(ブロック235)。このような問題が検出されなければ、ブロック240で取引は処理され、その結果資金を小売業者または他の販売業者へ送金すること(ブロック245)、処理のための料金を差し引くこと(ブロック250)、もしくは例えばクーポン発行者などの製造メーカのアカウントから資金を取ること(ブロック255)になる。クーポンはクレジットカード取引のように処理されるため、金は発行者のアカウントから引き出され、クーポン取引情報に提供されるオファーコード、及び発行者と処理装置の間で確立されるような取引処理の特定の詳細に従って販売業者のアカウントに送金される。ブロック260では、人口統計学等の追加のデータが追加の分析及びマーケティングリサーチのために施設に通信できる。クーポン取引情報から作成されるレポートは蓄積され、定期的にクーポン発行者に提示できる。クーポン発行者は情報レポートを受け取り、販売業者に対する払い戻し支払いを計画するために毎月、毎週、毎日、または他の時間間隔から選択する可能性がある。
【0028】
特にクーポン発行者または他のエンティティは入手できる大量の新しいクーポン情報を処理するためにソフトウェアを利用してよい。クーポンフォーマットを調整することにより、広告主と小売業者は、きわめて的を絞ったマーケティング、及び消費者の購買習慣、消費者の人口統計等を収集するためのマーケティングを行うことができる。例えば、クーポン情報は、クーポンの配布と引き換え、及びそれらを引き換えた特定の消費者に関係する情報を含んでよい。配布情報は、クーポンが配布された地理的な場所、新聞や雑誌の名称、朝刊、午後版または夕刊などの新聞の特定の版など特定の配布媒体、及び媒体の発行日を含んでよい。さらに、ダイレクトメールなどで特定の消費者に与えられるクーポンは、消費者のアイデンティティまたは年齢、学歴、収入、家族構成、過去の購買習慣等に関する人口統計情報で個別に符号化できる。
【0029】
ウェブベースクーポンなどの消費者がウェブサイトから印刷できるクーポンも、消費者のウェブサイトとの対話から得られる消費者に関する特殊な情報を含む場合がある。消費者が種々のクーポンから選択して、引き換えのためにそれらを印刷できるようにするインターネットウェブサイトは、二重使用を防ぐために一意に識別し、続き番号を振ることができる。消費者は、自分自身のコンピュータとプリンタを使用してクーポンを印刷する際に使用するためにウェブサイトから情報を受信する。このようなクーポンは、例えばバーコード、製品の写真、引き換えについての製造業者情報、制限、オファーコード、割引額、及び有効期限を有するなど、他の媒体で印刷されたクーポンと同じように見える。クーポンは店舗で提示され、クーポン発行者によって印刷されたクーポンと同じに処理される。一意の符号化方法及び続き番号が、クーポンが2回使用されていない、つまり重複されていないことを保証する。重複使用に対して消費者に警告を発することも出来る。クーポンは消費者の名前を記載することもできる。追加の人口統計情報は、クーポン処理中に製造メーカに伝達される。
【0030】
例えば、消費者は、関心のある商品の割引のためにクーポンを得るためにアンケートに回答するように依頼されることがある。ウェブサイトからのデータを使用して消費者によって印刷されたクーポンは、該回答から得られる情報を含むことがある。さらに、消費者は、消費者が支払いまたは賞金を受け取るべきであることを指定するクーポンを印刷するためにデータを受信することによって、ウェブサイトと対話するための現金支払いまたは賞金を与えられることがある。このケースでは、クレジットカードまたはデビットカードの番号または当座預金や普通預金の番号などの銀行口座識別子などの他のアカウント識別子が、クーポン発行者、例えばアンケートのスポンサーのクレジットカードまたはデビットカード番号とともにクーポンの中で符号化される。消費者のアンケートに対する回答もクーポンで符号化できる。クーポンの処理は、消費者が、クレジットカードまたはデビットカードで購入された商品を返品するときにクレジットを得る(obtains a credit)方法に類似している。代わりに、消費者の当座預金または普通預金に電子資金支払いを行うこともできる。あるいは、消費者は、製品またはサービスと引き換えることができるフリークエントフライヤーマイルに類似するポイントを与えられてよい。用語「賞金」等は、ここに説明されるような消費者に対するこのような支払いまたは賞金を包含することを意図する。賞金は、追加の要件なくウェブサイトとの消費者の対話の後に与えられてよい。
【0031】
例えば、製造メーカは、カスタマがお金を稼ぐという別の動機をもって参加するように招待されるウェブサイトをセットアップできるであろう。カスタマは、有効期限、アカウント番号、及び所在地住所とともに自身のクレジットカードまたはデビットカード情報を記入する。アンケートのためにウェブサイトでは「5分で次の10個の質問に答えてプロクターアンドギャンブル(Proctor and Gamble)から$1.00を儲けよう」と表示するかも知れない。カスタマはアンケートに記入し、セキュリティの目的でカスタマのクレジットカードまたはデビットカード、有効期限、及び所在地住所を要求するテキストフィールドのセットに記入する。それから、カスタマは結果として生じるクーポンを印刷し、それを処理するために販売業者に持ち込む。別の手法では、ウェブサイトでは、「すぐにプロクターアンドギャンブル(Proctor and Gamble)から$1,000,000を勝ち取るためにコンテストに参加しよう」と表示される。カスタマは、説明されたようにエントリ空欄及びテキストフィールドのセットに記入し、エントリはカスタマが勝者かどうかを判断するためにウェブサイトサーバに提出される。カスタマは、オンラインでその場ですぐに通知を受け、クーポンを印刷して商品を請求するためにデータを得ることができる。あるいはカスタマはクーポンを認可された販売業者に持ち込み、自分が賞を取ったかどうかを確かめてよい。
【0032】
本発明のクーポンの他の利点は、保持される追加情報によってクーポン発行者が製品の製造メーカとは別のエンティティであることができるという点である。これはクロスマーケティングや他の新しい種類のマーケティングと商売のための多くの機会を切り開く。対照的に、従来のクーポンは、製造メーカを識別し、クーポンが適用する製品上のコードと同じでなければならないUCC企業番号を保持するにすぎない。例えば、本発明によるバーコードは、UCC企業番号を介して製造メーカを識別する従来の部分と、別の関係者のアカウント識別子を識別する二次元バーコード部分などの追加の部分を有してよい。例示のために、ヘルスクラブが、消費者がエクササイズ装置または健康食品製品の割引を得ることができるようにするクーポンを発行してもよいし、あるいはホテルが、消費者がレンタカーまたは地元の観光施設の入場料の割引を得ることができるようにするクーポンを発行してもよい。別の例では、個人は受取人が特定の製品またはサービスの割引を得ることができるようにするギフトとしてクーポンを印刷できる。
【0033】
使用できる多様なバーコード記号体系について後述する。一般的には、本発明によるバーコードシンボルは、例えばUPC AまたはUCC−EAN−128などの既存のクーポン線形フォーマットの1つのように見える可能性があるが、RSSシンボルなどの二次元シンボルを追加する。POSの場所のレジカウンタがどのように設計されているのかに応じて、スキャナはどちらかのシンボルから追加の情報を求めることができる可能性がある。例えば、スキャナがRSS二次元追加データを求めるように設計されている場合、それは、それがクーポンであることを示す「5」という先頭の数字が付いたUPC(A)コードを確かめ、次にRSS二次元データがUPC(A)コードに追加されてよい。他方、クーポンのUCC/EAN−128部分が適切にフォーマットされている場合には、スキャナは、それがこのようなシンボルに遭遇する場合に追加の情報を求めてよい。UCC/EAN−128コードは、スキャナにそれがRSSシンボルの直線部分であることを理解させるために必要なフラグとリンケージ文字の両方がシンボルに含まれる場合にRSSシンボルの直線部分として読み取られてよい。幸いなことに、スキャナはUCC/EAN−128コードを、フラグとリンケージ文字があってもなくても読み取ることができ、両方の方法で動作するように設計されてよい。
【0034】
本発明の他の態様は、コンピュータがここに開示されている機能性を提供するこのようなバーコードシンボルを作成できるようにするためのコンピュータプログラム製品だけではなく、ここに開示されているバーコードシンボルを作成するようにプログラミングされるパーソナルコンピュータなどのコンピュータも含む。任意の既知のソフトウェア開発技法及びコンピュータプログラミング技法がこの目的のために使用されてよい。バーコードテクノロジー社(Barcode Technology)はこのようなソフトウェアの1つの供給業者である。
【0035】
図3(a)は、従来のUCC/EAN−128クーポンフォーマットを示す。シンボルは、垂直線だけを含むため線形または一次元である。シンボルは並んだ2個のバーコード、すなわち左側にUPC(A)統一商品コードシンボル305及び右側にUCC−EAN−128シンボル310を含んでいる。この2つの情報はこの目的用に設計されたスキャナにより1回の動作で走査できる。
【0036】
図3(b)は、UCC/EAN−128バーコードと結合された二次元バーコードの第1の実施形態を示す。シンボルは、シンボルのUPC(A)部分の上にRSSに次元複合コード325が印刷されたUCC/EAN−128クーポンフォーマット320を含んでいる。UCC/EAN 128クーポンフォーマットの規格に準拠することにより、追加のRSSに次元情報は、新しいRSSスキャナを装備した小売業者と新しい装置を装備していない業者の両方ともが同じクーポンを使用できるようにする。RSS情報を読み取ることのできる新しいスキャナを備えた小売業者は、ここに説明される新しい方法でクーポンを処理させることによって恩恵を受けるであろう。新しいRSSスキャナを備えていない小売業者は、彼らが従来行ってきたようにクーポンを受け入れ続けるであろう。
【0037】
図3(c)は、UCC/EAN 128バーコードと結合された二次元バーコードの第2の実施形態を示す。シンボルは、シンボルのUCC/EAN−128部分の上にRSSに次元複合コード325が印刷されたUSS/EAN 128クーポンフォーマット330を含んでいる。
【0038】
図4(a)〜図4(c)は、その設計がUCC/EAN 128クーポンフォーマットの規格に準拠するという要件によって制約されていないバーコードシンボルの例である。それらは、バーコードのサイズを最小限に抑え、追加のRSS二次元バーコードとともに、ここに説明される情報交換の種類を反映するように完全に設計し直されたRSSクーポンを提供する。
【0039】
図4(a)は、コード128バーコードと結合された二次元バーコードを示す。シンボルは、コード128バーコード415の上に印刷された二次元複合バーコード410を含んでいる。
【0040】
図4(b)は、UPC(A)バーコードと結合された二次元バーコードを示す。シンボルは、UPC(A)バーコード435の上に印刷された二次元複合バーコード410を含んでいる。
【0041】
図4(c)は、スタックバーコードと結合された二次元バーコードを示す。シンボルは、RSSスタック全方向性構成要素455の上に二次元複合440を含んでいる。
【0042】
図5(a)〜(g)は、最適化されたクーポンバーコードの例を示す。これらは、その設計がUCC/EAN 128クーポンフォーマットの規格に準拠するという要件により制約を受けないバーコードシンボルの他の例である。それらは、バーコードのサイズを最小限に抑え、追加のRSS二次元バーコードとの、ここに説明される情報交換のタイプを反映するように完全に設計し直されたRSSクーポンを提供する。バーコードは使用できるさまざまなサイズを表現する。RSSシンボルのさまざまな構成及び種類が、それらをさまざまに使用できるようにする。それぞれの例の二次元部分は同じであるが、各コードは異なる数の文字をもち、結果的に異なる幅になる線形部分を含む。例えば図5(a)〜(g)の線形部分にそれぞれ6桁から12桁をもつ。
【0043】
クーポンは更に小さなバーコードシンボルを使用してよいため、全体的なクーポンのサイズは縮小できる、あるいはさらに多くの人間が読み取ることができる販促情報が提供できる。例えば、図4(c)のフォーマットの総面積は0.66平方インチ、つまり図3(a)のUCC/EAN 128クーポンフォーマットの5.25平方インチ面積の12%である。RSSクーポンは追加の60文字分のデータをもつことができる。同じクーポンオファーを提供するために必要とされるページが少なくなるため、広告費を削減することができる。あるいはクーポンの追加の空間はグラフィックス等に充てることができる。紙の使用の削減のための環境上の利点も生じる。
【0044】
また、ここに開示されるバーコード化されたクーポンシンボルは、オファー番号、シリアルナンバー、有効期限、製品識別、ファミリコード及び価格コードなどの典型的なUCC/EAN−128クーポンフォーマットが保持する情報量を超えた増加した情報を提供する。RSS変形物は、UCC/EAN 128クーポンフォーマットの14文字を超えて、さらに56,338または2363多い文字の情報を可能にする。現在では388文字のフォーマットが適切であると考えられている。
【0045】
標準化されたフォーマットは、クーポンが含むことができる追加情報のために提供できる。例えば、標準的なICC/EAN−128クーポンフォーマットを超える追加情報は、(01)というアプリケーション識別子(AI)付きのグローバルトレードアイテムナンバー(GTIN)、AI(20)付き日付、時間、オファーコード、オファー有効期限、サブオファーコード、発行日、及び一意のシリアルナンバーを含む。例えば、オファーコード「12345」は、2002年8月24日日曜日にニューヨークタイムズ紙に印刷され、ニューヨークメトロポリタン地域で配布されたブランドXの石鹸のクーポンに割り当てられてよい。サブオファーコードは、クーポンが新聞の朝刊に掲載されたのか、午後版に掲載されたのか、あるいは夕刊に掲載されたのかを特定してよい。
【0046】
既存のクーポンフォーマットの他の問題は、ファミリコードに充てられる制限された面積である。ファミリコードは、製品のどのセットをクーポンが対象にしているのかを示すために製造メーカによって設計される。しかしながら、多様な企業の取り扱い品目のため、これは必ずしも製品の区別を行うために十分ではない。したがって、改良されたファミリコード情報が、本発明の追加データを伝える能力を使用して符号化できる。
【0047】
クーポンは、クレジットカードまたはデビットカードアカウントの有効期限及び/または個々のクーポンオファーの有効期限とともに符号化されてもよく、後者は処理中に引き換えのためのクーポンの有効性を立証するために使用される。製造メーカは複数のクーポンオファーを同時に実行させることができるため、有効期限はクーポンごとに変わってよい。RSSクーポンは特定の配布方法に備えて製造メーカによってそれに入れられる特殊な情報も含んでよい。例えば、特定の雑誌または新聞の読者が特定の人口統計データのセットを有する場合、それらの人口統計は、引き換え中にその情報が製造メーカに渡されるように雑誌に印刷されるクーポンを挿入できる。
【0048】
前述された情報に加えて、クーポンの文字列全体が符号化でき、CRCコード及びセキュリティコードを保持することができる。CRCコードはデータ完全性をチェックするために役立ち、重複クーポン及び不正クーポンを大幅に削減する、あるいは排除する。クーポンはかなりの程度の特異性で印刷できるため、詐欺及び複製のパターンはさらに容易に検出できる。クーポンに使用されるクレジットカード及びデビットカードの指定された番号のシーケンスを確保し、申し出られている割引に基づいて関連する取引限度を適用するなど、クレジットカード及びデビットカードの番号の不正使用を回避するために他の保護手段が提供できる。さらに、発行者のクレジットカードまたはデビットカードのアカウントはクーポンの有効期限に従ってそれと関連付けられた有効期限とすることができる。
【0049】
RSSクーポンの二次元部分に含まれる情報は、他者がその同じ情報を読み取り、使用できないようにするために、また処理センタが、クーポン発行者だけが利用できる封入された情報を読み取ることができないようにするために符号化されてよい。
【0050】
さらに、複製及び不正を削減するために大量印刷されたクーポンは、一意のオファーコード及びサブオファーコードを割り当てることによってさらに容易に差別化できる。
【0051】
本発明の他の利点は、それが小規模企業、個人、及び他のエンティティにクーポンを発行できるようにすることである。対比すると、従来のシステムの元では、UCC/EAN番号を保持する企業だけしか、既存のUCC/EAN−128クーポンフォーマットを使用してクーポンを主催できない。ここに説明されるクーポン引き換えシステムを用いると、システムは、あらゆる企業、人、または彼らがUPCシステムの製造業者であるかどうかに関係なく、クレジットカードまたはデビットカードのアカウント、及びバーコード印刷ソフトウェアを備えたパーソナルコンピュータを持つ他のエンティティに対して開放される。新しい商機が生じると期待される。
【0052】
クレジットカードまたはデビットカード取引システムを介してクーポンを最適に使用し、引き換えることのできるシステムを作成するために、以下を含む複数の技術及び商行為を導入する必要がある。
【0053】
a.銀行提携――銀行は、エスクロー勘定及び最小差引残高との契約上の取り決めでクーポンの発行者のクレジットカードまたはデビットカードアカウントを処理するためにセットアップされなければならない。
【0054】
b.処理/スキャナ――「Verifone」またはクーポンからクーポン情報を受け入れることができる他のクレジットカード処理機械を使用する。RSSクーポン及び従来のクーポンを読み取ることができるバーコードスキャナを使用し、クレジットカード処理機械と通信する。
【0055】
c.小売業者受け入れ――小売業者は、RSSクーポン情報を読み取り、理解するために進んで内部ソフトウェアを変更し、RSSクーポンを読み取るためにレジスキャナを更新するか、自らの従来のシステム及び新規にインストールされる二次元Verifone/スキャナと電話回線の両方でクーポンをダブルスキャンし、現在の引き換えプロセッサを断念しなければならない。
【0056】
d.製造業者の受け入れ――製造業者は、例えばバーコードテクノロジー社(Barcode Technology)のソフトウェアを使用して、進んで追加RSS情報がその中に含まれたクーポンを印刷しなければならない。
【0057】
e.カスタマ受け入れ――カスタマは、進んでRSSクーポンを使用しなければならない。バーコードのタイプは消費者にはほとんど重要ではないため、これは問題とはならない。製品及び割引が最大の関心である。
【0058】
図6は、関連付けられた製品が購入されたときにだけクーポンが引き換えられることを保証する方法を示す。
従来のクーポン処理の1つの問題は、販売業者のコンピュータシステムが、新しいクーポンが発行されたときにそれらを認識していないという点である。このため、販売業者のコンピュータシステムが新しいクーポンのオファーをどうしたらいいのか、つまりどのように処理するのかを知ることは困難である。例えば、既定のクーポンのための関連製品が実際にカスタマ注文に存在することを保証するセキュリティ方法は、そのコンピュータシステムがどの製品及び製品ファミリが該オファーに関連付けられるべきかを知っていることを必要とする。その情報が知られている場合には、スキャナとコンピュータは、UPC(A)コードが該製品と、購入されている製品に関連するクーポンについて存在することを確かめるためにダブルチェックできるであろう。この問題を解決するために、RSSクーポン自体が、グローバルトレードアイテムナンバー(GTIN)情報などの関連する製品識別子を含むことができるであろう。GTINは、包装識別子の形を取る12桁のUPCコードよりさらに具体的な情報を提供する14桁の番号である。例えば、GTINは石鹸が単一の商品として包装されているのか、6個パックとして包装されているのか、あるいはカートンとして包装されているのかも示すが、UPCコードは石鹸などの製品を識別する可能性がある。コンピュータはクーポンと関連付けられた製品GTINを読み取り、そのGTINまたはUPC(A)コードの存在がないか取引の中で他の製品を調べることができるであろう。一致がある場合には、クーポン引き換えは許可される。UPC−AバーコードシンボルはUCC−12識別番号を符号化するEAN/UPC記号体系のバーコードシンボルである。図4(b)を参照すること。GTINはすべてのRSSバーコード化クーポンで利用できるであろう。さらに旧式のUCC/EAN−128クーポンフォーマットを模倣しなければならない場合には、クーポンの二次元部分を、既存のバーコードシンボルタイプのUPC左半分またはEAN−128右半分の上に置くであろう。それらのケースでは、GTINは存在しないであろう。
【0059】
前記プロセスは図6に示されている。ブロック605では、本発明に従って提供されるクーポンがPOSで走査される。購入されている製品も走査される(ブロック610)。これらのステップは任意の順で発生する可能性がある。ブロック615では、クーポンで提供される製品識別子が一時的に記憶され、ブロック620では、製品上のバーコードからの製品識別子も記憶される。これらの製品識別子はGTINコードであってよい。消費者の注文が合計されるときに実行されてよいブロック630では、クーポンからの製品識別子のどれかが購入されている製品からの製品識別子との一致を有するかどうかに関して決定が下される。不一致がない場合(ブロック640)、クーポン割引が許可される(ブロック645)。不一致がある場合(ブロック650)、クーポン割引は許可されない。さらに、例えばキャッシュレジスタ及びディスプレイ上でレジ係及び許可されなかった特定のクーポンの消費者に知らせるためにメッセージが作成される。有利なことに、許可されていないクーポンの引き換え及び不正なクーポンの引き換えは抑えることができる。
【0060】
本発明を好ましい実施形態に関連して説明し図示したが、当業者に明らかとなるような多くの変形及び変型が本発明の精神及び範囲から逸脱することなくなされうるものであり、したがって、このような変形及び変型は本発明の範囲内に含まれることが意図されるため、本発明は前述されたような方法論または構成の詳細そのものに限定されるものではない。
【図面の簡単な説明】
【0061】
【図1】クーポン処理システムを示す。
【図2】クーポン処理方法を示す。
【図3(a)】従来のUCC/EAN−128クーポンフォーマットを示す。
【図3(b)】UCC/EAN−128バーコードと結合された二次元バーコードの第1の実施形態を示す。
【図3(c)】UCC/EAN−128バーコードと結合された二次元バーコードの第2の実施形態を示す。
【図4(a)】コード128バーコードと結合された二次元バーコードを示す。
【図4(b)】UPC(A)バーコードと結合された二次元バーコードを示す。
【図4(c)】スタックバーコードと結合された二次元バーコードを示す。
【図5(a)】最適化されたクーポンバーコードの例を示す。
【図5(b)】最適化されたクーポンバーコードの例を示す。
【図5(c)】最適化されたクーポンバーコードの例を示す。
【図5(d)】最適化されたクーポンバーコードの例を示す。
【図5(e)】最適化されたクーポンバーコードの例を示す。
【図5(f)】最適化されたクーポンバーコードの例を示す。
【図5(g)】最適化されたクーポンバーコードの例を示す。
【図6】クーポンが、関連する製品が購入されたときにだけ引き換えられることを確実にするための方法を示す。
【符号の説明】
【0062】
100 販売場所(POS)
105 クーポン
110 スキャナ/リーダー
112 スキャナ/リーダー
120 販売業者のコンピュータシステム
122 キャッシュレジスタ及びデイスプレイ
125 通信網
135 処理センタ
145 消費者アカウント
150 サービサーアカウント
155 発行者アカウント
165 販売業者アカウント

【特許請求の範囲】
【請求項1】
販売場所での引き換えに適したバーコード化されたクーポンであって、
前記クーポンの発行者のアカウント識別子、製品識別子またはサービス識別子、及び前記製品またはサービスの購入時に消費者に貸方記入され、前記アカウント識別子に従って前記発行者に請求される割引金額の識別子を保持するバーコードシンボルを備える、販売場所での引き換えに適したバーコード化されたクーポン。
【請求項2】
前記アカウント識別子がクレジットカード番号またはデビットカード番号の少なくとも1つを備える請求項1に記載のバーコード化されたクーポン。
【請求項3】
前記バーコードシンボルが印刷される基体をさらに備える請求項1に記載のバーコード化されたクーポン。
【請求項4】
前記バーコードシンボルの少なくとも一部が、前記アカウント識別子がその中に保持される二次元シンボルを備える請求項1に記載のバーコード化されたクーポン。
【請求項5】
前記二次元シンボルが省スペースシンボル(RSS)のシンボルを備える請求項4に記載のバーコード化されたクーポン。
【請求項6】
前記バーコードシンボルが第1のクーポン情報を保持する一次元部分と、前記アカウント識別子を保持する二次元部分とを含む請求項1に記載のバーコード化されたクーポン。
【請求項7】
前記製品識別子またはサービス識別子が、販売場所で該クーポンの引き換えを許可する際に使用するためのグローバルトレードアイテムナンバー(GTIN)を備える請求項1に記載のバーコード化されたクーポン。
【請求項8】
販売場所での引き換えに適したバーコード化されたクーポンであって、
前記クーポンの発行者のアカウントの識別子、消費者のアカウントの識別子、及び前記消費者のアカウントに授与され、前記発行者のアカウントに請求される賞金金額の識別子を保持するバーコードシンボルを備えるバーコード化された、販売場所での引き換えに適したバーコード化されたクーポン。
【請求項9】
前記クーポンがウェブベースクーポンとして前記消費者によって印刷され、
前記バーコードシンボルが前記ウェブサイトとの前記消費者の対話の間に得られる前記消費者に関連する情報を保持する、
請求項8に記載のバーコード化されたクーポン。
【請求項10】
前記賞金金額が前記ウェブサイトによって指定される請求項8に記載のバーコード化されたクーポン。
【請求項11】
前記発行者のアカウント識別子が、クレジットカード番号またはデビットカード番号の少なくとも1つを備える請求項8に記載のバーコード化されたクーポン。
【請求項12】
前記バーコードシンボルの少なくとも一部が、前記発行者のアカウント識別子がその中に保持される二次元シンボルを備える請求項8に記載のバーコード化されたクーポン。
【請求項13】
販売場所での引き換えに適したクーポンカードであって、
前記クーポンの発行者のアカウントの識別子、消費者のアカウントの識別子、及び前記消費者のアカウントに授与され、前記発行者のアカウントに請求される賞金金額の識別子を保持する磁気ストライプカードまたはスマートカードの少なくとも1つを備えるクーポンカード。
【請求項14】
販売場所でバーコード化されたクーポンを処理するための方法であって、
前記クーポンの発行者のアカウント識別子、製品識別子またはサービス識別子、及び前記製品またはサービスの購入時に消費者に貸方記入され、前記アカウント識別子に従って前記は後者に請求される割引金額の識別子を得るために前記クーポンの上のバーコードシンボルを走査することを含む、販売場所でバーコード化されたクーポンを処理するための方法。
【請求項15】
前記アカウント識別子、製品識別子またはサービス識別子、及び割引金額識別子を処理センタで処理するために処理センタに通信することをさらに含む請求項14に記載の方法。
【請求項16】
前記通信することが、販売場所にあるクレジットカード端末を使用して実行される
請求項15に記載の方法。
【請求項17】
前記アカウント識別子がクレジットカード番号を含み、アカウント識別子、製品識別子またはサービス識別子、及び割引金額識別子がクレジットカード通信プロトコルを使用して前記処理センタに通信される請求項14に記載の方法。
【請求項18】
前記アカウント識別子がデビットカード番号を含み、前記アカウント識別子、製品識別子またはサービス識別子、及び割引金額識別子がデビットカード通信プロトコルを使用して前記処理センタに通信される請求項14に記載の方法。
【請求項19】
前記バーコードシンボルの少なくとも一部が、前記アカウント識別子がその中に保持される二次元シンボルを含む請求項14に記載の方法。
【請求項20】
前記二次元シンボルが省スペースシンボル(RSS)のシンボルを含む請求項19に記載の方法。
【請求項21】
前記バーコードシンボルが、第1のクーポン情報を保持する一次元部分及び前記アカウント識別子を保持する二次元部分とを含む請求項14に記載の方法。
【請求項22】
販売場所でクーポンカードを処理するための方法であって、
前記クーポンの発行者のアカウント識別子、製品識別子またはサービス識別子、及び前記製品またはサービスの購入時に消費者に貸方記入され、前記アカウント識別子に従って前記発行者に請求される磁気ストライプカードまたはスマートカードの少なくとも1つを読み取ることを含む、販売場所でクーポンカードを処理するための方法。
【請求項23】
販売場所で販売業者から受け取られるクーポン取引情報を処理するための方法であって、
前記クーポン取引情報から、前記クーポンの発行者のアカウント識別子、前記販売業者からの製品またはサービスの購入時に消費者に貸方記入された割引金額、及び前記販売業者のアカウント識別子を回収すること、
前記割引金額識別子及び前記発行者の前記アカウント識別子に従って前記発行者の前記アカウントに対する料金を提供すること、
前記割引金額識別子及び前記販売業者の前記アカウント識別子に従って前記販売業者の代わりに支払いを行うこと、
を含む、販売場所で販売業者から受け取られるクーポン取引情報を処理するための方法。
【請求項24】
前記クーポン取引情報から、前記製品またはサービスの識別子を回収することをさらに含む請求項23に記載の方法。
【請求項25】
前記クーポン取引情報から、前記消費者と関連する人口統計データを回収することをさらに含む請求項23に記載の方法。
【請求項26】
前記発行者のアカウント識別子がクレジットカード番号またはデビットカード番号の少なくとも1つを含む請求項23に記載の方法。
【請求項27】
前記クーポン取引情報が、販売場所にあるクレジットカード端末から受け取られる請求項23に記載の方法。
【請求項28】
販売場所で販売業者から受け取られるクーポン取引情報を処理するための方法であって、
前記クーポン取引情報から、前記クーポンの発行者のアカウント識別子、消費者に授与される賞金金額の識別子、及び前記消費者のアカウント識別子を回収すること、
前記賞金金額識別子及び前記発行者アカウント識別子に従って前記発行者の前記アカウントに対して料金を提供すること、
前記賞金金額識別子及び前記消費者のアカウント識別子に従って前記消費者の代わりに賞金を提供すること、
を含む、販売場所で販売業者から受け取られるクーポン取引情報を処理するための方法。
【請求項29】
前記発行者のアカウント識別子がクレジットカード番号またはデビットカード番号の少なくとも1つを含む請求項28に記載の方法。
【請求項30】
前記消費者のアカウント識別子が、クレジットカード番号、デビットカード番号、または銀行口座番号の内の少なくとも1つを含む請求項28に記載の方法。
【請求項31】
販売場所でバーコード化されたクーポンの引き換えを許可するための方法であって、
(a)少なくとも1つの製品識別子をそこから得るために前記クーポンを走査すること、
(b)少なくとも1つの製品識別子をそこから得るために販売場所で消費者によって購入される少なくとも1つの製品を走査すること、
(c)不一致があるかどうかを判断するために、ステップ(a)で得られる前記少なくとも1つの製品識別子を、ステップ(b)で得られる前記少なくとも1つの製品識別子と比較すること、
(d)不一致がない場合、前記クーポンの引き換えを許可すること、
(e)不一致がある場合、前記クーポンの引き換えを許可しないこと、
を含む、販売場所でバーコード化されたクーポンの引き換えを許可するための方法。
【請求項32】
ステップ(a)で得られた前記少なくとも1つの製品識別子がグローバルトレードアイテムナンバー(GTIN)またはUPCバーコードシンボルの少なくとも1つを備える請求項31に記載の方法。
【請求項33】
ステップ(b)で得られた前記少なくとも1つの製品識別子がグローバルトレードアイテムナンバー(GTIN)またはUPCバーコードシンボルの少なくとも1つを含む請求項31に記載の方法。
【請求項34】
販売場所での引き換えに適したバーコード化されたクーポンを印刷する際に使用するためのコンピュータプログラム製品であって、
前記クーポンの発行者のアカウント識別子、製品識別子またはサービス識別子、前記製品またはサービスの購入時に消費者に貸方記入され、前記アカウント識別子に従って前記発行者に請求される割引金額の識別子を保持するバーコードを印刷する際に使用するためのコンピュータによって実行されるように適応されるソフトウェアを備える、販売場所での引き換えに適したバーコード化されたクーポンを印刷する際に使用するためのコンピュータプログラム製品。
【請求項35】
前記アカウント識別子がクレジットカード番号またはデビットカード番号の少なくとも1つを含む請求項34に記載のコンピュータプログラム製品。
【請求項36】
前記バーコードシンボルの少なくとも一部が、前記アカウント識別子がその中に保持される二次元シンボルを含む請求項34に記載のコンピュータプログラム製品。
【請求項37】
前記二次元シンボルが省スペースシンボル(RSS)のシンボルを含む請求項36に記載のコンピュータプログラム製品。
【請求項38】
前記バーコードシンボルが、第1のクーポン情報を保持する一次元部分及び前記アカウント識別子を保持する二次元部分とを含む
請求項34に記載のコンピュータプログラム製品。
【請求項39】
前記製品識別子またはサービス識別子が、前記販売場所での前記クーポンの引き換えを許可する際に使用するためのグローバルトレードアイテムナンバー(GTIN)を含む、請求項34に記載のコンピュータプログラム製品。
【請求項40】
販売場所での引き換えに適したバーコード化されたクーポンを印刷する際に使用するためのコンピュータプログラム製品であって、
前記クーポンの発行者のアカウントの識別子、消費者のアカウントの識別子、及び前記消費者のアカウントに授与され、前記発行者のアカウントに請求される賞金金額の識別子を保持するバーコードシンボルを印刷する際に使用するためのコンピュータによって実行されるように適応されるソフトウェアを備える、販売場所での引き換えに適したバーコード化されたクーポンを印刷する際に使用するためのコンピュータプログラム製品。
【請求項41】
前記クーポンがウェブベースクーポンとして前記消費者によって印刷され、
前記バーコードシンボルが前記ウェブサイトとの前記消費者の対話中に得られる前記消費者に関連する情報を保持する、
請求項40に記載のコンピュータプログラム製品。
【請求項42】
前記賞金金額が前記ウェブサイトにより指定される請求項40に記載のコンピュータプログラム製品。
【請求項43】
前記発行者のアカウント識別子が、クレジットカード番号またはデビットカード番号の少なくとも1つを含む請求項40に記載のコンピュータプログラム製品。
【請求項44】
前記消費者のアカウント識別子が、クレジットカード番号、デビットカード番号、または銀行口座番号の少なくとも1つを含む請求項40に記載のコンピュータプログラム製品。
【請求項45】
前記バーコードシンボルの少なくとも一部が、前記発行者のアカウント識別子がその中に保持される二次元シンボルを含む、
請求項40に記載のコンピュータプログラム製品。
【請求項46】
販売場所での引き換えに適したバーコード化されたクーポンであって、
前記クーポンの発行者のアカウント識別子、製品識別子またはサービス識別子、及び前記製品またはサービスの購入時に消費者に貸方記入され、前記アカウント識別子に従って前記発行者に請求される割引金額の識別子を保持するバーコードシンボルを備え、
前記アカウント識別子がクレジットカード番号またはデビットカード番号の少なくとも1つを備える、販売場所での引き換えに適したバーコード化されたクーポン。
【請求項47】
販売場所でバーコード化されたクーポンを処理するための方法であって、
前記クーポンの発行者のアカウント識別子、製品識別子またはサービス識別子、及び前記製品またはサービスの購入時に消費者に貸方記入され、前記アカウント識別子に従って前記発行者に請求される割引金額の識別子を得るために前記クーポン上のバーコードシンボルを走査することを含み、
前記アカウント識別子がクレジットカード番号またはデビットカード番号の少なくとも1つを含む、販売場所でバーコード化されたクーポンを処理するための方法。
【請求項48】
販売場所で販売業者から受け取られるクーポン取引情報を処理するための方法であって、
前記クーポン取引情報から、前記クーポンの発行者のアカウント識別子、前記販売業者からの製品またはサービスの購入時に消費者に貸方記入された割引金額識別子、及び前記販売業者のアカウント識別子を回収すること、
前記割引金額識別子と前記発行者の前記アカウント識別子に従って前記発行者の前記アカウントに対して請求を行うこと、
前記割引金額識別子及び前記販売業者の前記アカウント識別子に従って前記販売業者の代わりに支払いを提供すること、
を含み、
前記発行者のアカウント識別子が、クレジットカード番号またはデビットカード番号の少なくとも1つを含む、販売場所で販売業者から受け取られるクーポン取引情報を処理するための方法。


【図1】
image rotate

【図2】
image rotate

【図3(a)】
image rotate

【図3(b)】
image rotate

【図3(c)】
image rotate

【図4(a)】
image rotate

【図4(b)】
image rotate

【図4(c)】
image rotate

image rotate

【図6】
image rotate


【公表番号】特表2006−511888(P2006−511888A)
【公表日】平成18年4月6日(2006.4.6)
【国際特許分類】
【出願番号】特願2004−565503(P2004−565503)
【出願日】平成15年12月16日(2003.12.16)
【国際出願番号】PCT/US2003/039887
【国際公開番号】WO2004/061736
【国際公開日】平成16年7月22日(2004.7.22)
【出願人】(504208647)インターナショナル バーコード コーポレイション (2)
【出願人】(504164413)
【出願人】(505229645)
【Fターム(参考)】