JP2004094543A

JP2004094543A - 携帯端末、クーポン処理装置、クーポン管理サーバ

Info

Publication number: JP2004094543A
Application number: JP2002254127A
Authority: JP
Inventors: Koichiro Akiyama; 秋山　浩一郎
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2002-08-30
Filing date: 2002-08-30
Publication date: 2004-03-25
Anticipated expiration: 2022-08-30
Also published as: JP3950025B2

Abstract

【課題】柔軟性と安全性を兼ね備えた電子的なクーポンサービスを実現する。
【解決手段】クーポン処理装置と接続してクーポンサービスを享受可能な携帯端末においてクーポンサービスの供給元から衛星放送等によりクーポンデータを取得し、当該携帯端末の利用者に固有のクーポンサービスを享受するため用いることが可能な情報を該携帯端末の内部プロファイルから所定の処理手順に従い取得すると共に、該情報に基づいてクーポンデータに変更を加える。変更が加えられたクーポンデータをクーポン処理装置に送信して該携帯端末の利用者に固有のクーポンサービスを享受できるようにする。
【選択図】　　図１１

Description

【０００１】
【発明の属する技術分野】
本発明は、電子的なクーポンサービスを実現する際に用いられる携帯端末、クーポン処理装置、およびクーポン管理サーバに関する。
【０００２】
【従来の技術】
クーポンサービスは店舗において新規顧客の獲得のために広く行なわれ、来店客に対する値引き等のサービス形態として定着している。これらのクーポンサービスでは店舗が新聞広告等にクーポンを印刷し、顧客はこれを店舗に持参することにより、クーポンに印刷されたサービスを受けることができる。また最近ではインターネット上に当該店舗の広告を載せるとともに、クーポン券を表示し、そのサイトを参照した者が当該クーポン券を印刷し、店舗に持参した際には、クーポン券に記載のサービスを実施するなどのクーポンサービスを実施している店舗もある。
【０００３】
従来のクーポンサービスは、クーポンを配布する際にこれを不特定多数向けに配布するため、他社のサービスを受けている顧客であっても、自社のサービスを受けている顧客であっても、同一のクーポン券で同一のサービスしか提供できない。また、クーポン券の偽造も容易である。
【０００４】
さらに、新聞広告によるクーポンサービスは広告費用がかかる上、小規模店舗などでは実施できる機会が少ない。また、インターネットによるクーポン配布では広告費はあまりかからないが、広告サイトにアクセスしてもらわないとクーポンが配布できないという問題もある。
【０００５】
一方、携帯電話や電子手帳に代表されるような携帯端末が普及してきている。これらの携帯端末は通信機能と計算機能を兼ね備えており、通信機能に関して言えば電話ができるばかりでなく、電話回線を利用したインターネット接続サービスなども普及しつつある。また近年ではＢｌｕｅｔｏｏｔｈ（商標）やＩｒＤＡに代表されるような近距離無線機能を兼ね備えた携帯端末も普及してきている。これらの無線機能を利用すると、近距離通信に限定されるものの、料金負担のない通信を実現できる。これら携帯端末には、計算機能が備えられているため、通信の際にデジタル署名の生成及び検証を実現することも可能である。
【０００６】
さらに、従来の地上波放送、衛星放送以外にも自動車のように移動体する物体の中、若しくは携帯端末のように移動しながら利用する機器でも視聴できるような衛星放送（モバイル放送）が計画されている。
【０００７】
【発明が解決しようとする課題】
上述のように携帯端末が普及していること、および衛星放送のように公衆が利用可能な通信手段に着目して、従来にはない電子的なクーポンを実現し、その特徴に応じた柔軟なクーポンサービスを実現することが望まれている。この場合、従来と同様、クーポンの偽造等によるクーポンサービスの不正利用を回避することが必要とされる。
【０００８】
本発明はこのような事情を考慮してなされたものであり、柔軟性と安全性を兼ね備えたクーポンサービスを実現するための携帯端末、クーポン処理装置、クーポン管理サーバを提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明に係る携帯端末は、クーポン処理装置と接続してクーポンサービスを享受可能な携帯端末であって、前記クーポンサービスの供給元からクーポンデータを取得する手段と、当該携帯端末の利用者に固有のクーポンサービスを享受するため用いることが可能な情報を該携帯端末の内部プロファイルから所定の処理手順に従い取得すると共に、該情報に基づいて前記クーポンデータに変更を加える手段と、変更が加えられた前記クーポンデータを前記クーポン処理装置に送信する手段と、を具備することを特徴とする携帯端末である。
【００１０】
本発明に係るクーポン処理装置は、クーポンサービスの供給元から発行され、携帯端末を通じて該クーポンサービスの利用者から送信されたクーポンデータを受信する手段と、当該携帯端末の利用者に固有のクーポンサービスを享受するため該携帯端末において付加された付加クーポンデータを、受信した前記クーポンデータから抽出するとともに、該付加クーポンデータに応じて前記クーポンサービスの提供内容を決定する手段と、を具備することを特徴とするクーポン処理装置である。
【００１１】
本発明に係るクーポン管理サーバは、クーポンサービスの供給元から発行され、携帯端末を通じて該クーポンサービスの利用者から送信されたクーポンデータを受信し、該クーポンデータを処理して該クーポンサービスを提供するクーポン処理装置を管理するクーポン管理サーバであって、前記利用者のプロファイル情報を記録する手段と、前記クーポンサービスの利用において前記クーポン処理装置が処理した前記携帯端末からのクーポンデータについての履歴データを記録する手段と、前記プロファイル情報及び前記履歴データに基づいて、前記クーポンデータの妥当性を検査する手段と、を具備することを特徴とするクーポン管理サーバである。
【００１２】
本発明に係るクーポン処理方法は、クーポン処理装置と接続してクーポンサービスを享受可能な携帯端末におけるクーポン処理方法であって、前記クーポンサービスの供給元からクーポンデータを取得するステップと、当該携帯端末の利用者に固有のクーポンサービスを享受するため用いることが可能な情報を該携帯端末の内部プロファイルから所定の処理手順に従い取得すると共に、該情報に基づいて前記クーポンデータに変更を加えるステップと、変更が加えられた前記クーポンデータを前記クーポン処理装置に送信するステップと、を具備することを特徴とするクーポン処理方法である。
【００１３】
本発明に係るプログラムは、コンピュータをクーポン処理装置に接続してクーポンサービスを享受するためのクーポン処理プログラムであって、前記クーポンサービスの供給元からクーポンデータを取得する機能と、前記コンピュータの利用者に固有のクーポンサービスを享受するため用いることが可能な情報を該コンピュータの内部プロファイルから所定の処理手順に従い取得すると共に、該情報に基づいて前記クーポンデータに変更を加える機能と、変更が加えられた前記クーポンデータを前記クーポン処理装置に送信する機能と、を具備することを特徴とするクーポン処理プログラムである。
【００１４】
本発明に係るデータ構造は、クーポンサービスの供給元から発行されたクーポンデータに携帯端末が変更を加えるとともに該クーポンデータを該クーポンサービスの利用時にクーポン処理装置に送信するクーポンサービスシステムに適用されるクーポンデータのデータ構造であって、前記クーポンデータは、付加クーポンデータを含み、該付加クーポンデータは、前記クーポンサービスを前記携帯端末が享受する際の変更内容と、前記携帯端末のデジタル署名と、前記デジタル署名の検証に用いられる公開鍵についての所定の認証局による公開鍵証明書と、を具備することを特徴とするクーポンデータのデータ構造である。
【００１５】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施形態を説明する。まずは実施形態の説明における用語およびその意味について述べる。
【００１６】
実施形態でいう「携帯端末」とは携帯電話や電子手帳のように計算機能と通信機能を有し、移動しながらの利用を前提とした機器を意味する。また、「クーポン処理装置」とは店舗等に備えられ、計算機能と通信機能を有する機器をいい、クーポン処理機能を有する例えばＰＯＳ（ｐｏｉｎｔ−ｏｆ−ｓａｌｅ；販売時点情報管理システム）端末などがこれにあたる。
【００１７】
実施形態でいう「利用者」及び「店舗従業員」とは、不正を起こす可能性がある者と想定しているが、その一方で、「クーポン管理サーバ」は不正を起こさないという意味で信頼できると仮定している。また、携帯端末やクーポン処理装置は、これら信頼できるサイトと信頼できないサイトとの中間的な位置付けである。例えば、携帯端末およびクーポン処理装置はたとえ出荷段階で正常であったとしても、ハッカーによる解析等によって内部構造が明らかになり、内部構造の弱点をついた不正利用の可能性が否定できない。このような不正利用の可能性は、利用者が自宅でも利用できる携帯端末によって著しく高くなる。このため携帯端末にはそのデータ格納部やデータ処理部（後述する）へのアクセスに関し、データを勝手に読み込めない、勝手に書き込めない、あるいは勝手に改竄できないという意味での耐タンパ性が必要となる。
【００１８】
いずれの実施形態においても、携帯端末、クーポン処理装置にはいくつもの機種が存在し、機種毎に解析され易さが異なるのも事実である。このため、解析された機器を排除する仕組みが導入される。この仕組みは「リボケーション」と呼ばれ、各携帯端末、クーポン処理装置に「リボケーションリスト」と呼ばれるブラックリストを配信することによって実現される。
【００１９】
同様に、利用者や店舗従業員が不正を起こすとしても、その可能性は未知数である。そこで本実施形態では過去に不正行為を行ったことのある利用者や従業員、あるいは店舗についての情報をリボケーションリストという形態で各携帯端末、クーポン処理装置に配信し、該当する利用者、従業員、あるいは店舗をクーポンシステムから排除することができるような仕組みを導入している。尚、リボケーションリスト等を参考にして不正者を排除することは「リボーク」と呼ばれている。
【００２０】
リボケーションを実現するためには、不正が起こった場合に不正行為者を確実に特定できる仕組みが重要である。本発明は柔軟なクーポンサービスを提供し、利便性を向上させる一方で、不正が起こった際に不正行為者を確実に特定できる仕組みを提供する。これにより不正行為者をシステムから排除し、不正行為自体を防止できるようにする。
【００２１】
実施形態でいうクーポンデータは、図１に示すように基本クーポンデータと付加クーポンデータから構成され、それぞれ図２および図６に示すような内部構成を有する。尚、本実施形態では説明の簡単のため、特に断らない限り全てのデータ属性は固定長であるものとする。これは、後に述べるデータ抽出方式を簡単にするためであって、固定長のデータを可変長のデータにすることは自明な変形により可能である。
【００２２】
基本クーポンデータは、例えば放送局から放送配信されるデータであり、全ての視聴者に共通のクーポン情報である。図２に示すように、基本クーポンデータは情報識別子、キーワード情報、基本クーポンデータ本体、サービス業者の公開鍵証明書、サービス業者のデジタル署名から構成されている。情報識別子はこのデータが基本クーポンデータであることを示す情報である。サービス業者のデジタル署名は、後に説明するようにサービス業者の公開鍵暗号による基本クーポンデータへのデジタル署名である。尚、デジタル署名の対象となる範囲は情報識別子と基本ポイントデータ本体である。キーワード情報は、この基本クーポンデータが何に関するクーポンであるかをキーワードの形で表現したものである。図４に示すようにキーワード情報はキーワードの個数ｎと、それに引き続くｎ個のキーワードデータから構成される。キーワードデータは、例えばハンバーガー店のクーポンの場合、「飲食店」、「軽食」、「ハンバーガー」など複数考えられ、それらが言語データもしくはコードとして記録されている。これらのキーワードは携帯端末がクーポンデータを受信する際に、受信するクーポンの選択に利用される。
【００２３】
基本クーポンデータ本体は、例えば図３のような構成であり、クーポン識別子、サービス業者ＩＤ、放送業者ＩＤ、割引額、有効期限、クーポンポリシーから構成されている。
【００２４】
サービス業者ＩＤは本クーポンサービスを提供する業者の識別子である。クーポン識別子は当該クーポンデータを他のクーポンデータから識別するためのものであって、この情報により（後に述べるように）携帯端末に重複してクーポンデータが保存されるのを防ぐことができる。サービス業者ＩＤはクーポンサービスを行う業者を特定するための情報である。放送業者ＩＤは本クーポンを送信する放送業者の識別子である。また、割引額は本クーポンを利用することにより、ディスカウントできる金額を示している。実運用されているクーポンには一律に割引金額を提示する以外に割引率で定めたり、商品毎に割り引き額（率）が異なったり、割引サービスではなく、例えば１０００円以上の買上げに付き粗品を進呈するなどのサービスも実施されている。なお、本実施形態においては説明の簡単のため全商品一律の割引額による割引サービスとする。ただし、これは実サービスにおける様々なクーポンサービスに対する本発明の適用を妨げるものではない。有効期限は本クーポンサービスの有効期限を示している。
【００２５】
クーポンポリシーデータは、図９（ａ）に示すようにクーポンポリシーの数ｌと、ｌ個のクーポンポリシーからなる。個々のクーポンポリシーには、後に詳しく述べる付加クーポンデータをどのように生成するかという生成方法が示されている。本実施形態におけるクーポンポリシーは、図９（ｂ）に示すように種別情報、ポリシー識別子、適用条件、割引加算額、有効期間、有効期限延長フラグからなる。
【００２６】
種別情報は当該クーポンポリシーが必須条件であるのか、許可条件であるのかを示す情報である。ここでの必須条件とは、この条件が満たされなければクーポンサービスを実施しないというクーポンサービスを受ける際の必須の条件である。許可条件とは、条件が満たされれば記述されているクーポンサービスが受けられることを示す条件である。ポリシー識別子とは当該クーポンポリシーの識別子である。適用条件は以下の割引加算額、有効期間、有効期限延長フラグを持つ付加クーポンデータが発行されるための条件であり、本実施形態においては携帯端末のプロファイル（内部データ）に対する条件である。具体的な記述には、サービス業者側で定めた適用条件ＩＤが用いられる。例えば、「Ａ社での累積購入実績が一万円未満」を０ｘ０００１、「Ａ社での累積購入実績が１万円以上」を０ｘ０００２、「Ａ社での累積購入実績が１０万円以上」を０ｘ０００３などと定める。適用条件としては、これ以外にも後の第６のバリエーションで利用するような「個人情報（住所、氏名、年齢）の入力」などが考えられる。また、もちろんこれらの組み合わせ、「Ａ社での購入実績が１万円以上で、個人情報（住所、氏名、年齢）の入力」なども有用である。このような適用条件の記述には組み合わせ毎に適用条件ＩＤを定めるという定め方以外にも、適用条件ＩＤを併記することによって記述する方法も考えられ、後者の方がよりエレガントである。
【００２７】
尚、適用条件の記述の仕方に関しては、個々のサービス業者が都合の良いように定めるものであり、どのように定めても、サービス業者のクーポンサービスアプリケーション上で矛盾なく実装されていれば、本実施形態の処理では問題にならない。割引加算額は、基本クーポンデータが示す割引額について、適用条件が満たされた場合どのくらい加算できるかを示すものであり、有効期間は、付加クーポンデータを作成した時点からの当該付加クーポンデータがどのくらいの期間有効かを示したものである。例えば、適用条件が位置情報に関するものである場合、位置が変ってしまえばクーポンの条件が変ってしまう。即ち、店舗から遠くにいる人には割引率を高く、近くの人には割引率を低く設定するような場合、付加クーポンデータを作るのが常に会計する直前であると、誰でも一律の低い割引率になってしまう。そこで、店舗から遠い位置にいるうちにクーポンデータを確定しておく必要がある。しかし、無期限でそのクーポンが使えるのは問題なので一定の有効期間を決めるための情報である。
【００２８】
有効期限延長フラグは、有効期間から算出された有効期限が基本クーポンデータにおける有効期限を越えてしまった場合、これを延長して適用できるかを示すものであり、１の場合は延長可、０の場合は延長不可としている。
【００２９】
尚、上述の必須条件を持つクーポンポリシーが複数あった場合は、どれか１つに適用しなかった場合はクーポンの発行ができない。一方、複数の許可条件が存在した場合は次のように処理する。割引額１００円の基本クーポンデータに対し、購入実績に対するクーポン割引加算額を決めるポリシーが３つあって、それぞれ購入実績０であれば−１００円（即ち、割引なし）、１万円の購入実績があれば＋１００円、１０万円の購入実績に対しては＋１０００円という記述がなされていたとする。この場合３万円の購入実績がある顧客は１万円の購入実績はあるが１０万円の購入実績はないので、＋１００円のクーポン増額が実施され、当該基本クーポンデータは実質的に２００円の割引クーポンとして利用できる。
【００３０】
サービス業者の公開鍵証明書は、公開鍵を、後に説明する認証局によって当該公開鍵が確かにサービス業者ＩＤの公開鍵であることを証明したものである。サービス業者の公開鍵証明書は、図５に示すようにサービス業者ＩＤ、サービス業者名、有効期限、サービス業者の公開鍵、認証局のデジタル署名からなる。
【００３１】
ここで、デジタル署名に関して簡単に説明する。本実施形態でいうデジタル署名は公開鍵暗号を用いた方法であり、秘密鍵Ｋ_ｓで署名したものを公開鍵Ｋ_ｐで検証することによって実現される。公開鍵暗号では、公開鍵から秘密鍵を導出することは極めて困難であり、公開鍵を公開しても秘密鍵が漏れない限り、第三者がデジタル署名を作成することは事実上困難である。しかも署名を検証する公開鍵は文字通り公開しても構わない。したがって、初来店の顧客との間でも署名検証ができ、クーポンサービスのような不特定多数向けのシステムに最適である。公開鍵暗号には現在ＲＳＡ暗号や楕円曲線暗号等の方式が提案されており実用化が進んでいる。
【００３２】
しかし、便利な公開鍵暗号も全く問題がないわけではない。何故なら、公開鍵暗号を実現するには公開鍵と秘密鍵のペアを生成しなくてはならないが、この生成にはそれほど時間が掛かるわけではなく、しかもソフトウェアがあれば誰でも簡単に実現できるからである。従って、通信している相手がデジタル署名付きのクーポンデータと検証用の公開鍵を送信してきても、当該公開鍵がサービス業者ＩＤから示されたサービス業者の公開鍵か否かは直ちには分からない。即ち、当該従業員になりすました何者かが、公開鍵と秘密鍵のペアを生成し、作成した秘密鍵を使ってクーポンデータに署名を付け、公開鍵を当該サービス業者のものだと偽って送信すれば、これを受信したクーポン処理装置は、送信された公開鍵でクーポンデータのデジタル署名の正当性を確認することができる。したがって、当該クーポンデータが確かにサービス業者ＩＤをＩＤに持つサービス業者によって発行されたものであると誤解されてしまう。このような不正を防ぐためには、第三者によって受信した公開鍵が確かに当該サービスのものだと証明してもらう必要がある。この証明に用いられるのが公開鍵証明書である。
【００３３】
付加クーポンデータは、視聴者固有の情報（プロファイル）に基づいて作成されるデータであり、基本クーポンデータを修正する役割を持つ。このデータが本実施形態において特徴的な部分であり、クーポンデータを視聴者毎に適切に変更することによって、より効果的なサービスを実現するとともに、不特定多数の視聴者にクーポンデータを配布してもクーポンサービスが破綻せず、販売促進につながる仕組みを提供できる。ここで、視聴者固有の情報とは携帯端末の内部情報（携帯端末内部に蓄えられた情報）であり、例えば、クーポンを発行している企業の製品購入実績、クーポンを発行している企業の関連企業の製品購入実績、配信されている放送の契約情報、あるいは携帯端末の位置情報であったりする。付加クーポン情報は例えば製品購入実績の多い顧客に対しては割引額（もしくは割り引き率）を増加させたり、製品購入実績が全くない顧客に対しては割引額（もしくは割り引き率）を減額させるために利用される。
【００３４】
携帯端末の内部情報としては、上記したものの他に、電話機能に付随する電話番号、住所、氏名やメールアドレスなどの個人情報、携帯端末の製造メーカ、および型番などのように複数の携帯端末に共通の情報など、携帯端末内部に格納され得る幅広い情報が含まれる。住所などの個人情報は、後に本実施形態のバリエーションで述べるように、クーポンに個人情報を付加することを条件にサービスを提供する時に利用される。また、携帯端末の製造メーカなどの情報は、当該製造メーカの発売する関連機器を割引する場合などに利用される。
【００３５】
図６は付加クーポンデータの構成を示す図である。情報識別子は当該情報が付加クーポンデータであることを示す識別子である。また、携帯端末の公開鍵証明書は上記サービス業者の公開鍵証明書と同様に携帯端末の公開鍵であることが認証局によって証明されたデータである。携帯端末の公開鍵証明書は図５に示したサービス業者の公開鍵証明書と同様、図８のように構成される。各構成要素の意味も原則として同様であるので繰り返さないが、サービス業者が利用者もしくは携帯端末になっていることは多少注意を要する。即ち、サービス業者への公開鍵証明書の場合は対象はサービス業者であるが、携帯端末への公開鍵証明書の場合は、認証の直接の対象は携帯端末である。これにより本来なら利用者ＩＤであるべきところを携帯端末ＩＤとしている。そのため携帯端末ＩＤ以外に利用者ＩＤを発行しているサービスにおいては、携帯端末ＩＤを利用者ＩＤに読み替えて本実施形態を適用することができる。また携帯端末のデジタル署名は携帯端末の公開鍵暗号による本データへのデジタル署名である。ここでデジタル署名の対象となる範囲は情報識別子と付加ポイントデータ本体である。
【００３６】
付加クーポンデータ本体は図７のような構成であり、携帯端末ＩＤ、割引加算額、有効期限からなる。携帯端末ＩＤは付加クーポンデータを発行した携帯端末の識別子である。割引加算額は基本クーポンデータに示された割引額に対してどれだけ加算するのかを示している。ここでは加算と述べているが、この値をマイナス値にすることによって割引額を減ずることもできる。このため結果的に割引額を０として、クーポンを無効にすることも可能である。有効期限は本付加クーポンデータの有効期限を示している。この有効期限は基本クーポンデータから内部情報に基づいてクーポンデータを作成する時に生成されるため、内部情報がクーポン割引額に有利な状態でクーポンデータを生成して格納しておく場合にその有効期限を決めている。従って、付加クーポンデータにおける有効期限と基本ポイントデータにおける有効期限との関係は主にサービス業者によって解釈される。即ち、サービス業者Ａは基本クーポンデータに示された有効期限内でしかクーポンサービスを提供しないため、付加クーポンデータにおける有効期限は基本クーポンデータにおける有効期限の範囲を出ないと解釈する。一方で、サービス業者Ｂは基本クーポンデータに示された有効期限以外でもクーポンサービスを実施しているので、付加クーポンデータの有効期限を優先する。これらの条件は基本クーポンデータ内の上記クーポンポリシーにおける有効期限延長フラグに記述される。
【００３７】
図１１は本発明の一実施形態に係るクーポンサービスシステム全体の構成を示すブロック図である。本実施形態は携帯端末１、クーポン処理装置２、クーポンサーバ３、放送衛星４、従業員カード５及び認証局６からなる。認証局６は予め各携帯端末機器向けの公開鍵証明書、各クーポン処理装置機器向けの公開鍵証明書を発行する。また、各利用者向けに各携帯端末１の公開鍵証明書、各従業員向けの公開鍵証明書を発行する。携帯端末機器向けの公開鍵証明書と利用者向けの公開鍵証明書は携帯端末１に、クーポン処理装置機器向けの公開鍵証明書はクーポン処理装置２に、従業員向けの公開鍵証明書は従業員カード５にそれぞれシステム構築時に準備される。本システムにおいて認証局６はこのような公開鍵証明書を本人（もしくは機器）を確認して、作成する役割のみを担う。
【００３８】
本発明においては後に詳しく説明するように、放送の視聴者が放送配信により基本クーポンデータを受信し、携帯端末１はユーザの指示に従って当該基本クーポンデータから携帯端末１内の情報に基づいて付加クーポン情報が付加されてクーポンデータを生成し、携帯端末１の内部に格納される。
【００３９】
生成されたクーポンデータの使用に関する全体的な処理手順を図１２に示すフローチャートに沿って、図１１を参照しながら説明する。まず携帯端末１はクーポン処理装置２と無線通信で結び、当該無線通信によって後に各装置の処理の説明で詳しく述べるプロトコルに従って顧客の持っている携帯端末１はクーポン処理装置２を、クーポン処理装置２は顧客の持っている携帯端末１をお互いに本発明の安全性規格に則った正当な機器であることを認証する（Ｓ１２０〜Ｓ１２７）。認証が成功した場合は、携帯端末１は当該クーポンデータをクーポン処理装置２に送信する。認証に成功しなかった場合、当該携帯端末１もしくはクーポン処理装置２は本実施形態で必要なだけの安全規格に則っていない可能性があるので、その時点で処理を中止する（Ｓ１２４，Ｓ１２７）。
【００４０】
次に、クーポン処理装置２は携帯端末１から携帯端末ＩＤを取得し（Ｓ１２８）、クーポン処理装置２が持っている携帯端末リボケーションリストを検索して当該携帯端末１がリボークされているか否かチェックする（Ｓ１２９）。ここでリボークされていれば直ちに処理を終了する（Ｓ１２１０）。リボークされていない時は、携帯端末１に従業員が信頼できる人かを確かめさせるためにクーポン処理装置２は従業員カード５から店舗ＩＤ、従業員ＩＤ、従業員の公開鍵証明書を取得して（Ｓ１２１１）、そのうち店舗ＩＤ、従業員ＩＤを携帯端末１に送信する。携帯端末１はこれを受けて、独自に所有している店舗従業員リボケーションリストを検索して当該店舗ＩＤ、従業員ＩＤがリボークされているか否かチェックする（Ｓ１２１２，Ｓ１２１３）。リボークされていた時は直ちに処理を終了する（Ｓ１２１４）。リボークされていなかった時は携帯端末１はクーポンデータ本体をクーポン処理装置２に送信する（Ｓ１２１５）。クーポン処理装置２ではこれを受信し（Ｓ１２１６）、当該データに含まれる基本クーポンデータと付加クーポンデータのデジタル署名をそれぞれ検証する（Ｓ１２１７）。検証に成功した場合は当該クーポンデータのうち付加クーポンデータは改竄されていないと認められるので、クーポン処理装置２はこれに対してディスカウントを行い（Ｓ１２２０）、後に詳しく述べる処理手順でクーポンログデータを作成する（Ｓ１２２１）。ステップＳ１２１８において検証不成功の場合はエラー出力して直ちに処理を終了する（Ｓ１２１９）。一方、携帯端末１は当該クーポンデータを消去して処理を終える（Ｓ１２２２）。
【００４１】
以下では携帯端末１、クーポン処理装置２、クーポンサーバ３の順に各装置の構成と処理の内容を詳しく説明する。尚、図１１のシステム構成図中の認証局６、従業員カード５については構成及びその処理手順が極めて単純であるためここでは詳しく説明しない。
【００４２】
図１３は携帯端末の全体構成を示すブロック図である。図１３において限定受信部１３１、クーポン処理部１３２、クーポン使用部１３３に関しては後に詳しく説明する。また、以下では携帯端末の処理手順を放送受信処理、受信されたクーポンの処理、店舗でのクーポン使用時の処理の順に詳しく説明する。
【００４３】
図２０は限定受信部１３１の構成を示すブロック図である。限定受信は有料放送において視聴契約者のみが受信可能とするための仕組みをいう。限定受信は、放送コンテンツを暗号化して送信し、これを復号する鍵を視聴契約者だけに配信することによって実現される。
【００４４】
限定受信を行なうためチャネル毎の契約状態を記述した情報をチャネル契約情報と呼ぶ。例えば各チャネルにチャネル番号を付け、例えば図１４（ａ）のようにチャネル番号に対応したビットが１であるか否かによりチャネルの契約状態を表したビット列がチャネル契約情報である。図１４（ａ）では第２、第５、第７、第８チャネルが契約済であることを示している。また、図１４（ｂ）のようなチャネル契約情報の形式も考えられる。即ち、１チャネルに４ビットを割り当てることで、より詳細な契約状態を表現する。ここでは上記４ビット中、１ビット目に視聴の可否（１なら可、０なら否）が、２ビット目にはクーポンの割引額１００円アップの可否（１から可、０なら否）が、３ビット目には同じくクーポンの割引額２００円アップの可否が、４ビット目には同じくクーポンの割引額５００円アップの可否が示されている。即ち、図１４（ｂ）の例においては第１チャネルは視聴契約なし、第２チャネルはクーポン割引額２００円アップの視聴契約、第８チャネルはクーポン割引額５００円アップの視聴契約が表現されている。本発明では図１４（ｂ）に示すようなチャネル契約情報を利用して当該チャネルに放送配信された基本クーポンデータに対して付加クーポンデータを作成し、視聴者個別のクーポンデータを作成する。
【００４５】
また、チャネル契約情報に当該チャネル契約情報の有効期限などチャネル契約情報に制限を加える情報や、加入者の契約形態をより詳細に表現する情報を付加して契約情報が構成される。
【００４６】
更に、上記契約情報などの個別の加入者向けの限定受信情報を個別限定受信情報、チャネルキー情報など複数の加入者に共通の限定受信情報を共通限定受信情報という。これらは限定受信情報であることが明確である文脈においては、簡単のためそれぞれ個別情報、共通情報という。
【００４７】
本実施形態においては、限定受信に図１５のような鍵構成を採用している。即ちチャネル毎に定められている全ての携帯端末に共通のワーク鍵Ｋ_ｗを個別のマスター鍵Ｋ_ｍで暗号化して送信する。更に、そのワーク鍵Ｋ_ｗを使ってチャネルキーＫ_ｃｈを暗号化して送信する。放送コンテンツはチャネルキーＫ_ｃｈを使って慣用暗号方式で暗号化されているので、このチャネルキーで復号できる。ここでチャネルキーは解読を防ぐため通常１０分程度の短時間で変更しなくてはならない。これを送信するために個別のマスター鍵を使っていたのでは送信量が膨大となる。そのため全携帯端末に共通のワーク鍵を使う必要がある。またワーク鍵も何ヵ月という単位で同じ鍵を使うと危険なので、変更する必要があり、これを個別のマスター鍵で暗号化する仕組みとなっている。このことにより、例えマスター鍵が知られても、ワーク鍵を変更することによって無料視聴を防止することができる。
【００４８】
さて、本実施形態の限定受信システムにおいて放送携帯端末が受信するデータはコンテンツパケット、共通限定受信情報パケット、個別限定受信パケットの３種類である。コンテンツパケットは図１６に示すパケットデータ構造であり、情報識別子、チャネル識別子、チャネルキー識別子、スクランブルされた放送コンテンツからなっている。情報識別子は当該パケットの種別を示すもので、ここではコンテンツパケットであることを示す識別子を記述する。チャネル識別子は当該放送コンテンツがどのチャネルのコンテンツかを示すものである。また、チャネルキー識別子は当該放送コンテンツを復号するチャネルキーの識別子を示す。本実施形態における放送コンテンツは生の番組データもしくはクーポンパケットで、チャネルキー識別子で指定されたチャネルキーＫ_ｃｈで暗号化されている。
【００４９】
共通限定受信パケットはチャネルキー情報パケットとも呼ばれ、図１９に示すようなパケットデータ構造を有する。この共通限定受信パケットは、情報識別子、ワーク鍵識別子、チャネル識別子、チャネルキー識別子１、チャネルキー１、チャネルキー識別子２、チャネルキー２により構成されており、チャネル識別子からチャネルキー２までの部分は、ワーク鍵識別子で示されたワーク鍵で暗号化されている。情報識別子は当該パケットの種別を示すもので、ここでは共通限定受信パケット（チャネルキー情報パケット）であることを示す識別子を記述する。チャネル識別子は当該共通限定受信情報がどのチャネルのものかを示すものである。また、ワーク鍵識別子は当該共通限定受信パケットがどのワーク鍵Ｋ_ｗによって暗号化されているかを示す情報である。チャネルキー識別子は次に記述されているチャネルキーの識別子であり、チャネルキーはチャネル識別子で指定されているチャネルの放送コンテンツの暗号化に使われているチャネルキーを示している。ここで、チャネルキー識別子とチャネルキーが２組存在するのは、上記のようにチャネルキーは比較的短時間で変更されるため、チャネルキーの切り替えをスムーズに行う必要から現在使っているチャネルキーと次回使うチャネルキーを同時に送っているからである。もちろん、このように２組送信することは本発明には直接影響しないので、１組であっても構わない。
【００５０】
個別限定受信パケットは図１７に示すように、情報識別子、携帯端末ＩＤ、マスター鍵識別子、暗号化された契約情報からなっている。情報識別子は当該パケットの種別を示すもので、ここでは個別限定受信パケットであることを示す識別子を記述する。携帯端末ＩＤは当該契約情報を受信するべき携帯端末の識別子である。マスター鍵識別子は当該個別限定受信パケットを復号可能なマスター鍵の識別情報であり、正しく送受信されていれば、ここには当該パケットを受信した携帯端末の有するマスター鍵識別子が記述されている。
【００５１】
契約情報は、図１８に示すように、携帯端末ＩＤ、チャネル契約情報、有効期限、ワーク鍵の数ｋ及びｋ個のワーク鍵とワーク鍵識別子のペア、デジタル署名からなっている。携帯端末ＩＤは当該契約関連情報を受信するべき携帯端末の識別子であり、正常に送受信されていれば携帯端末内部の限定受信部１３１にある携帯端末ＩＤと一致したＩＤである。チャネル契約情報は上述した通り、当該携帯端末ＩＤを有する携帯端末の契約状態を示すものである。ワーク鍵識別子ｉは続くワーク鍵ｉの識別子である。本実施形態においてワーク鍵はチャネル毎に設定されているため、チャネル契約情報に対応したワーク鍵とワーク鍵識別子の組が入る。デジタル署名は当該契約情報の正当性を確認するための情報であり、主に偽造防止のために用いる。
【００５２】
尚、本実施形態ではこれら全ての情報は固定長で表現されたデータであるので、受信されたパケットから各情報を抽出する処理手順は改めて述べない。
【００５３】
次に、限定受信部１３１の構成と処理の流れを、図２０（もしくは図１３）を参照しながら図２１に示す処理手順に沿って説明する。図１３において、携帯端末は放送波を受信すると（Ｓ２１０）、それをＡ／Ｄ変換によりデジタルデータに変換する（Ｓ２１１）。次に、誤り検出／訂正を行い（Ｓ２１２）、正しく受信できたパケットのみをチャンネル選択部１３４に送信する。ここで、当該パケットが放送コンテンツ情報（パケット）である場合（Ｓ２１３）は現在視聴中のチャネルをチャネルＩ／Ｆ１３５を介して得て、チャネル選択部により視聴チャネルのみを選択するとともに限定受信部１３１内の放送フィルター部２０１に送信する。図２０に示すように、放送フィルター部２０１ではこれをデスクランブル部２０２へ送る（Ｓ２１５）。一方、共通限定受信パケット（共通制御パケット）である場合（Ｓ２１６）はチャネル選択部１３４を経て、放送フィルター部２０１から共通限定受信情報復号部２０３へ送られ（Ｓ２１７）、復号が開始される。あるいは個別限定受信パケット（個別制御パケット）である場合（Ｓ２１８）はチャネル選択部１３４を経て、放送フィルター部２０１から個別限定受信情報復号部２０４へ送られる（Ｓ２１９）。
【００５４】
コンテンツパケットに対する処理を図２２のフローチャートに沿って詳しく説明する。上記処理によって放送フィルター部２０１からデスクランブル部２０２へ送られたコンテンツパケットはチャネル識別子とチャネルキー識別子を分離され、それらをチャネルキー出力部２０５に送信し、チャネルキー出力部２０５に対してチャネルキーの出力を要請する。チャネルキー出力部２０５は契約判定部２０６での当該チャネルに対する契約判定を基に受信チャネルのチャネルキーをチャネルキー格納部２０７から抽出する（Ｓ２２０）。また、契約判定部２０６ではチャネルキー出力部２０５から送信されるチャネル識別子を受けて当該チャネルが視聴契約されているか否かをチャネル契約情報を参照して出力する。チャネルキー出力部２０５では送られてきた判定が許可であれば（Ｓ２２１）、チャネルキー格納部２０７から当該チャネルの当該チャネルキー識別子を保持したチャネルキーを得てデスクランブル部２０２へ送信し、不許可であればそこで当該コンテンツパケットに関する処理を終了する。デスクランブル部２０２では、スクランブルされたコンテンツを対応したチャネルキーで復号する（Ｓ２２２）。復号されたコンテンツデータは第２フィルター部１３４へ送信される。第２フィルター部１３４ではこれがクーポンデータであれば、クーポン処理部１３２へ送り（Ｓ２２４）、そうでなければ外部のディスプレイ等の出力装置に送信する（Ｓ２２５）。
【００５５】
次に共通限定受信パケットに関する処理手順を図２３に沿って説明する。共通限定受信パケットは放送フィルター部２０１から共通限定受信情報復号部２０３に送られる。ここで、共通情報の未暗号部に含まれるワーク鍵識別子を基にワーク鍵格納部２０８からワーク鍵を取得する（Ｓ２３０）。ここでワーク鍵が取得できなかった場合（Ｓ２３１）、処理を終了する。ワーク鍵が取得できたら、当該ワーク鍵で共通情報を復号する（Ｓ２３２）。復号された共通情報からチャネルキーＫ_ｃｈを取得し、チャネルキー格納部２０７に格納する（Ｓ２３３）。
【００５６】
次に個別限定受信パケットに関する処理手順を図２４に沿って説明する。個別限定受信パケットは放送フィルター部２０１から個別限定受信情報復号部２０４に送られる。ここで、個別情報の未暗号部に含まれる携帯端末ＩＤを読み込み、自装置の携帯端末ＩＤと照合する（Ｓ２４０）。当該携帯端末ＩＤが自装置のそれと一致しなかった場合は本パケットの処理を終了する。一致した場合は未暗号化部に含まれるマスター鍵識別子をキーにしてマスター鍵格納部２０９からマスター鍵を取得する。更に、当該マスター鍵を使って当該個別限定受信情報を復号し（Ｓ２４１）、復号して得られたワーク鍵をワーク鍵格納部２０８に格納する（Ｓ２４２）。次に契約情報は契約情報認証部２０１０に送られ、契約情報認証部２０１０ではデジタル署名検証鍵を、デジタル署名検証鍵格納部２０１１から取得してデジタル署名を検証する（Ｓ２４３）。検証が成功した場合は契約情報を契約情報格納部２０１２へ格納して処理を終える（Ｓ２４４）。検証が失敗した場合は契約情報が偽造されたか、受信不良によって壊された可能性があるので格納せずに終了する。
【００５７】
以上で限定受信部１３１の説明を終了する。
【００５８】
次にクーポン処理部１３２について詳しく説明する。図２５はクーポン処理部１３２の構成を示すブロック図である。クーポン処理部１３２の処理には放送配信された基本クーポンデータを格納する処理と基本クーポンデータから付加クーポンデータを作成し、クーポンデータを生成する処理がある。
【００５９】
図２６は、基本クーポンデータの格納処理の処理手順を示すフローチャートである。以下では基本クーポンデータの格納処理に関して図２５の全体構成図を参照しながら、図２６のフローチャートに沿って説明する。基本クーポンデータが第２フィルター部１３４からクーポン処理部１３２へ入力されると（Ｓ２６０）、クーポンフィルター部２５１はキーワードデータ格納部２５２から格納するクーポンを絞り込むためのキーワードを抽出し、入力された基本クーポンデータのキーワード情報と比較する（Ｓ２６１）。比較の結果、マッチングが取れた場合は基本クーポンＤＢ２５３に対してクーポン識別子などをキーにして検索し（Ｓ２６３）。当該基本クーポンデータが未登録であることを確認し（Ｓ２６４）、そうである場合に登録することにより、当該基本クーポンデータに関する処理は終了する（Ｓ２６５）。ここで、入力された基本クーポンデータがキーワード情報とマッチングしなかったり（Ｓ２６２）、基本クーポンデータが基本クーポンデータＤＢ２５３に存在した場合には本基本クーポンデータに関する処理をその時点で終了する（Ｓ２６４）。
【００６０】
図２７は付加クーポンデータの生成処理の処理手順を示すフローチャートである。以下、基本クーポンデータの格納処理について、図２５の全体構成図を参照しながら図２７のフローチャートに沿って説明する。クーポン処理部１３２はクーポン使用部１３３もしくは携帯端末のインターフェースからの要請で、付加クーポンデータの生成（即ちクーポンデータの生成）処理を開始する。ここでは簡単のため、クーポンデータを作成する対象の基本クーポンデータは処理開始の段階で入力によって（クーポン識別子などをキーとして）指定されるものとする。そうでないときは本処理に先立って基本クーポンデータＤＢ２５３を検索して必要となるクーポンに対応する基本クーポンデータを抽出する必要があるが、この処理はユーザインターフェースを経由して制御部から基本クーポンデータＤＢ２５３を検索すれば行えるので、ここではあえて説明を省略する。
【００６１】
入力された基本クーポンデータのクーポンＩＤをキーにして基本クーポンデータＤＢ２５３を検索し（Ｓ２７０）、該当する基本クーポンデータを抽出する（Ｓ２７１〜Ｓ２７３）。さらに抽出した基本クーポンデータからクーポンポリシーを抽出し（Ｓ２７４）、このクーポンポリシー中の種別情報を参照して必須条件を取り出し、それらを後程詳しく述べる手段で検査する（Ｓ２７５）。ここで必須条件を満たさない場合は本基本クーポンデータに関する処理は終了する（Ｓ２７６，Ｓ２７７）。必須条件を満たす場合は種別情報を参照して許可条件を取り出し、後に詳しく述べる手段で内部情報を参照することにより、最も有利なものを選択する（Ｓ２７８）。この詳しい処理の手順も後に詳しく述べる。
【００６２】
以上の処理により、何らかのクーポンポリシーが選択されたかをチェックする。即ち、必須条件をクリアしても当該基本クーポンデータと内部情報に関して許可条件に該当するポリシーがないことがあり得るのである（Ｓ２７９）。クーポンポリシーが存在した場合には当該クーポンポリシーの割引額を付加クーポンデータの割引額として付加クーポンデータを作成する（Ｓ２７１１）。そうでないときは割引加算額を０として付加クーポンデータを作成する（Ｓ２７１０）。いずれの場合も作成されたクーポンデータを制御部２５４を経由してクーポン使用部１３３へ送信し（Ｓ２７１２）、クーポン使用部１３３では後に詳しく述べる手段により、クーポンデータＤＢに格納する（Ｓ２７１３）。
【００６３】
次に、上記クーポンポリシーから付加クーポンデータを生成する処理において必須条件のチェックに関わる処理を図２８のフローチャートに沿って説明する。先ず、基本クーポンデータの中からクーポンポリシーを抽出し（Ｓ２８０）、クーポンポリシーデータの先頭にあるクーポンポリシー数ｋを取り出し変数ｋにセットする。次にｉ＝０、ｉ＝ｉ＋１として、ｉ＞ｋをチェックする（Ｓ２８１〜Ｓ２８３）。ここで、ｉ＞ｋであれば以下で詳しく述べる必須条件のチェックを終了する。すなわち、必須条件が全て満たされていたということであり、必須条件にあてはまる旨出力して終了する（Ｓ２８４）。
【００６４】
ｉ＞ｋを満たさなかったときは、クーポンポリシーｉを抽出し（Ｓ２８５）、当該クーポンポリシーが必須条件であるかを種別情報を参照して判断する（Ｓ２８６）。必須条件でなかった場合は本処理手順における検査対象ではないので、ｉを１インクリメントして次のクーポンポリシーを検査する。
【００６５】
必須条件であった場合は、まずそれがクーポン発行回数に関するポリシーかどうかをポリシー識別子を参照してチェックする（Ｓ２８７）。もしクーポン発行回数に関するポリシーであったら、クーポン作成実績ＤＢ２５５を検索し（Ｓ２８８）、適用条件に当てはまるか否かを判定する（Ｓ２８９）。ここで、クーポン発行回数によるポリシーは、同じクーポンが複数回発行されている場合、発行回数の上限を設定するためのものである。即ち、本発明に係るクーポンデータは放送により何回も発行されるため、何回でも利用可能となってしまう。このため、その上限を定めようとするのが本必須条件の趣旨である。即ちここでの条件チェックはクーポン作成実績ＤＢ２５５からクーポン識別子をキーに検索し、その作成回数がクーポンポリシーにおける制限回数を超えないことを確認することになる。ここで作成回数が超えていた場合は必須条件に当てはまらない旨出力し、処理を終了する（Ｓ２８１０）。
【００６６】
作成回数が上限以下であった場合、もしくはそもそも当該クーポンポリシーがクーポン発行回数に関するものでなかった場合には、当該クーポンポリシーが購入実績に関するものか否かをポリシー識別子を用いてチェックする（Ｓ２８１１）。購入実績に関するクーポンポリシーとは例えば購入金額１０００円以上の顧客のみにクーポン発行を行うというように「一定額の購入実績があった人のみクーポン発行を行う」もしくは逆に「一定額未満の人のみクーポン発行を行う」といったクーポンポリシーである。このようにクーポンポリシーを定めることにより、無制限なクーポン利用を防止し、クーポンを有効な販促手段とすることが可能となる。これを実現するため、クーポン作成部２５６から購入実績ＤＢ２５７を検索し（Ｓ２８１２）、該当の購入がどのくらいあったかを調査する。そこで得られた購入金額をクーポンポリシーと比較することによって必須条件に当てはまるか否かを判定する（Ｓ２８１３）。当てはまる場合はｉを１つインクリメントし、次のクーポンポリシーを検査する（Ｓ２８２）。当てはまらなかった場合には必須条件に当てはまらなかった旨を出力して終了する（Ｓ２８１４）。
【００６７】
本実施形態では、必須条件としてクーポン発行実績と商品購入実績とを示しているので、それ以外のクーポンポリシーが入力されても、無視されるが、一般には一定額以上のポイントが溜まっているなど他の実績要素やクーポン発行団体の会員であるなどの身分情報によって決まる必須条件もあり得る。これらの必須条件を実現するためには、条件に対応するＤＢなりメモリーが必要な以外は、これまで説明してきた処理手順で可能である。
【００６８】
更に許可条件のチェックに関わる処理に関しても上述した必須条件に関する処理と同様なのでここでは省略する。
【００６９】
次に許可条件の中から一番有利な許可条件を探索する処理に関して図２９のフローチャートに沿って説明する。まず、基本クーポンデータの中からクーポンポリシーを抽出し、クーポンポリシーデータの先頭にあるクーポンポリシー数ｋを取り出し（Ｓ２９０）、変数ｋについてのカウンタｉを０にセットする。次に、付加クーポン条件（付加クーポンを作成するに当たって最も有利な条件）を格納するメモリーを初期化する（Ｓ２９２）。初期化とは、ここでは割引加算額、有効期間、有効期限延長フラグをいずれも０にセットすることである。続いてｉ＝ｉ＋１として、ｉ＞ｋをチェックする（Ｓ２９３，Ｓ２９４）。ここで、ｉ＞ｋであれば以下で詳しく述べる許可条件のチェックを終了し、付加クーポン条件に記載されている条件を最も有利な許可条件として、これを出力する（Ｓ２９１０）。
【００７０】
ｉ＞ｋを満たさなかったときは、クーポンポリシーｉを抽出し（Ｓ２９５）、当該クーポンポリシーが許可条件であるかを種別情報を参照して判断する（Ｓ２９７）。許可条件でなかった場合は本処理手順での検査対象ではないので、ｉを１インクリメントして次のクーポンポリシーを検査する。
【００７１】
許可条件であった場合は、当該クーポンポリシーに書かれている適用条件を、内部情報を参照することによって検査する。これに当てはまる場合は割引加算額、有効期間、有効期限延長フラグの情報と現在の付加クーポン条件とを比較し（Ｓ２９８）、当該クーポンポリシーで提示された条件よりも付加クーポン条件の方が有利ならば、ｉを１インクリメントして次のセキュリティポリシーを検査する。当該クーポンポリシーで提示された条件の方が有利であれば付加クーポン条件を当該クーポンポリシーで置き換える（Ｓ２９９）。
【００７２】
ここで、付加クーポンデータとクーポンポリシーの比較には、いろいろな実現形態があるが、たとえば本実施形態では次のように実現される。即ち、割引加算額、有効期間、有効期限延長フラグの順で重要度を定め、比較して割引加算額が大きい方が有利とする。割引加算額が同じ場合は有効期間が長い方を有利とする。有効期間も同じ場合は有効期限延長フラグが１のものを優先する。もちろん実際にはもっと複雑なクーポンポリシーも考えられ、このような比較が妥当でない場合もあり得る。一般の場合にはユーザビリティを向上させるため、より複雑な比較を行わなければならないばかりか、場合によっては有利な条件をユーザがユーザＩ／Ｆを通して選択する必要がある。
【００７３】
このような処理をｉをインクリメントしつつ全てのクーポンポリシーについて繰り返し、最後に付加クーポン条件を出力して終了する。尚、クーポンポリシーには購入実績の他、限定受信の契約情報、ＧＰＳによる位置情報などがある。特に位置情報に関しては携帯端末が存在する位置が店舗から遠いところであれば割引き加算額をアップし、近いところであれば割引加算額を抑えることで、効果的な集客が可能となる。これらの実現にはクーポン処理部１３２の外にあるデータが必要になるが、それは制御部を通じて収集される。
【００７４】
以上により、クーポン処理部１３２における２種類の処理の説明を終了する。
【００７５】
次にクーポン使用部１３３について詳しく説明する。図３０はクーポン使用部１３３の構成を示すブロック図である。クーポン使用部１３３ではクーポンデータＤＢ３０１に蓄えられたクーポンデータを外部のクーポン処理装置に通信手段で送信する処理を行う。しかし、送受信処理といってもここではクーポンサービスを受けるために行う処理であり、お互いに信頼できる人が信頼できる機器を使って送信／着信した正しいデータであることを証明する必要性があるため、認証処理が含まれている。
【００７６】
以下ではクーポン使用時の処理を図３１に示すフローチャートに沿って説明する。尚、送信したいクーポンデータがクーポンデータＤＢ３０１に存在しない場合には、その時点でクーポン処理部１３２へクーポン作成の指示を送り、上述した手順に従ってクーポンデータを作成し、利用する。
【００７７】
クーポンの使用を行う際は、まず顧客の携帯端末からクーポン処理装置を通信で呼び出す（Ｓ３１０）。ここで考えられる通信は電話局経由の通信ではなく、Ｂｌｕｅｔｏｏｔｈ（商標）やＩｒＤＡなどに代表されるような近距離無線通信である。これは電話料金が掛からないばかりでなく、高速に通信できるなどのメリットがあるためクーポンサービスに利用しやすい。しかし、以下の実施形態においては電話局を経由する公衆回線型の通信でも同様に適用可能である。
【００７８】
携帯端末の呼びかけに応じてクーポン処理装置が応答したら、所定のプロトコルにより接続が行われる（Ｓ３１１）。接続が行われた後、携帯端末がクーポン処理装置の機器認証を機器認証部３０１により行なう（Ｓ３１２）。ここで、認証処理に関し詳しく説明する。本発明に係る機器で行われる認証は、通信相手が正しい機器であるかということを確かめるための認証である。実施形態の冒頭でも述べた通り、本実施形態では携帯端末、クーポン処理装置の装置自体は耐タンパ性が仮定できれば信頼に足るものと考えられる。逆に言えば、特別な方法で簡単にハッキングでき、装置内部のデータを勝手に書き換えられたり、読み出したりすることができる耐タンパ性が仮定できない装置は、最早信頼に足る装置ではないといえる。機器認証はそのような信頼できなくなった装置、およびクーポンサービスが実施できるレベルの安全性を有しないためクーポンサービスシステムとして使用が認められていない機器を排除するために行う。
【００７９】
図３３は機器認証の処理手順を示すフローチャートである。まずクーポン処理装置の機器ＩＤを問い合わせるチャレンジを作成し（Ｓ３３０）、制御部３０５、送受信部３０４を経由してクーポン処理装置に出力する（Ｓ３３１）。次に、当該チャレンジに対するクーポン処理装置のレスポンスを待つ（Ｓ３３２）。レスポンスを受信したら、そのレスポンスからクーポン処理装置機器ＩＤを機器認証部３０１が機器データ格納部３０２から抽出し、当該クーポン処理装置機器ＩＤで機器リボケーションリスト３０３を検索する（Ｓ３３３）。このリストに当該クーポン処理装置機器ＩＤが記載されていた場合（Ｓ３３４）は、当該クーポン処理装置は既にセキュリティシステムが崩壊している機器か、所定のセキュリティシステムを有しない機器であると判断し、その機器の信用力不足のため認証を終了する旨のエラーメッセージを出力して終了する（Ｓ３３５）。
【００８０】
ここで、当該クーポン処理装置の機器ＩＤがリボケーションリスト３０３に存在しなかった場合は、少なくともレスポンスされた機器の信用力は認められるので、続いて当該クーポン処理装置は本当に当該クーポン処理装置ＩＤの機器であるかの検証に進む。これには先に述べたように当該クーポン処理装置しか知りえない情報を利用した認証を行えばよい。即ち、当該クーポン処理装置の機器公開鍵証明書を問い合わせるチャレンジを作成し（Ｓ３３６）、上記と同様の手順でクーポン処理装置にこれを送り（Ｓ３３７）、レスポンスを受信する（Ｓ３３８）。ここでいう公開鍵証明書は、機器認証用の公開鍵証明書であり、図１０に示すような構成を有する。レスポンスを受信したら、レスポンスの中から公開鍵証明書を取得し、公開鍵証明書の中から機器ＩＤを取得して先にレスポンスされた機器ＩＤと比較する。比較の結果一致しなかった場合は公開鍵証明書か機器ＩＤに偽りがある旨のエラー出力して認証を終了する。一致した場合は更に認証局の公開鍵で公開鍵証明書を認証する（Ｓ３３９）。認証が成功した場合は公開鍵証明書は正しいことが証明されたので、次にチャレンジに進む。認証に失敗した場合には公開鍵証明書の認証に失敗した旨のエラー出力ののち、認証処理を終了する。
【００８１】
機器の公開鍵証明書の認証に成功したら、ｉ＝０に設定し（Ｓ３３１１）、メッセージＭ_ｉに対する当該公開鍵で検証できるデジタル署名の作成を要請するチャレンジを作成し（Ｓ３３１２）、これを出力する（Ｓ３３１３）。レスポンスを受信したら、メッセージＭ_ｉの署名を検証する（Ｓ３３１５）。検証に失敗したら、署名検証に失敗した旨のエラー出力を行う（Ｓ３３１７）。成功した場合はｉを１ずつ増やして同様のチャレンジレスポンスを平文を変えながらＮ回繰り返す（Ｓ３３１２〜Ｓ３３１６）。Ｎ回のいずれも成功した場合、当該クーポン処理装置は当該機器ＩＤだけが知る秘密鍵を使ってメッセージに署名していると認められるので当該機器ＩＤの機器であると確認できる。これにより認証成功して終了する旨の通知を携帯端末に送信する（Ｓ３３１８）。以上がクーポン処理装置の機器認証処理である。
【００８２】
以上の処理手順によりクーポン処理装置の認証に成功した時、同様の処理手順により行われるクーポン処理装置による携帯端末の認証を受ける。この認証処理手順を図３２に示す。まず、携帯端末はクーポン処理装置からのチャレンジを送受信部３０４で受信する（Ｓ３２０）。受信したチャレンジは制御部３０５を経由して機器認証部へ送られる。ここでの「問いかけ」には２種類あり、単純にクーポン処理装置ＩＤを問う問いかけと、携帯端末しか知りえない情報を使わない限り答えられない問いかけがある。前者の問いかけの場合、機器認証部では機器データ格納部から機器ＩＤを取得して制御部３０５、送受信部３０４を経由して携帯端末に送信する。
【００８３】
後者の問いかけであった場合は、同様にして機器認証部３０１で機器データ格納部３０２から秘密データを抽出してチャレンジにある処理を行う。後者の問いかけは具体的には、機器が秘密に保持する公開鍵暗号の秘密鍵を利用して送信した平文（メッセージ）にデジタル署名を生成せよといったものである。尚、ここでいう機器認証は基本的に個々の機器に対して行われるのではなく、たとえば機器の型名に対して行われる。即ち、同じ型名の機器は同一の機器ＩＤを持ち同一の（認証用の）秘密鍵を持っており、同一の基準で認証されるものとする。
【００８４】
上記手順により作成されたレスポンスは制御部３０５を経て送受信部３０４からクーポン処理装置に送信される（Ｓ３２２）。上記レスポンスに対してクーポン処理装置から認証終了か続行の通知を受信し、認証終了の通知を受信したならば（Ｓ３２３）、制御部３０５にて認証に成功したものであるかを判定し（Ｓ３２４）、認証に失敗した場合はその理由を出力し終了する。ここで、認証に成功したか否かの判定は、例えばクーポン処理装置からの終了通知にエラーコードが付加されているか否かによって判定できる。エラーコードが付加されている場合は認証失敗であり、当該エラーコードが示す理由により認証に失敗している。認証が失敗した場合は当該エラーコードに基づいてエラー出力を行なう（Ｓ３２５）。一方、認証終了しない場合は次のチャレンジがクーポン処理装置から送信されてくるのを待ち、当該チャレンジを受信したら上述と同様の処理を行う。
【００８５】
ここで、図３１の説明に戻る。
【００８６】
機器認証をパスしたら、携帯端末は引き続きクーポン処理装置２から携帯端末ＩＤの問いかけを受ける。そこで、携帯端末は限定受信部１３１にある携帯端末ＩＤを抽出し、クーポン処理装置２に携帯端末ＩＤを送信する（Ｓ３１８）。クーポン処理装置２側では図３４に示すようにこれを制御部３４１から携帯端末ＩＤ検証部３４２に送り、携帯端末リボケーションリスト３４３を参照して当該携帯端末ＩＤがリボークされていないかチェックする（Ｓ３１９）。ここでもしリボークされていたら要注意顧客である旨の出力を行い終了する（Ｓ３１１０）。ここで携帯端末リボケーションリスト３４３は過去にクーポンデータの不正取引を行ったことがある顧客で、取引停止期間内である携帯端末ＩＤのリストである。このため本リストに携帯端末ＩＤが登録されていた場合はその時点で取引を終了しなければならない。
【００８７】
もし、リボークされていなかった場合はクーポン処理装置２の制御部３４１は従業員カード読み込み部３４４から従業員カード５に書かれている店舗ＩＤ、従業員ＩＤ、従業員の公開鍵証明書を取得する（Ｓ３１１１）。ここで、従業員カード５とは従業員の電子的な身分証明書であり通常ＩＣカードの形態で実装されている。従業員はクーポン処理装置２を操作する時は必ず自分の従業員カード５をクーポン処理装置２の差込み口に挿入しなくてはならない。これにはクーポンサービスに関する従業員の責任を明らかにするとともに、不正者を排除する狙いがある。従業員カードから取得した店舗ＩＤ、従業員ＩＤは送受信部３４２を経由して携帯端末に送信され（Ｓ３１１２）、携帯端末側で当該店舗あるいは当該従業員がリボークされているか否かをチェックされる。ここで、リボークされていることが分かった場合、携帯端末は直ちに取引中止の旨の情報をクーポン処理装置に送信するので、クーポン処理装置はエラー出力して終了する（Ｓ３１１４）。
【００８８】
リボークされていなかった場合、携帯端末はクーポンデータをクーポン処理装置に送信する（Ｓ３１１５）。クーポン処理装置は当該クーポンデータを受信し（Ｓ３１１６）、後のクーポン処理装置の処理手順の説明の部分で詳しく述べる方法でクーポンデータを検証する（Ｓ３１１７）。ここで、検証が成功した場合はクーポン処理装置はクーポン使用による割引を実施する（Ｓ３１２０）。割引が実施された後当該クーポンデータをクーポンデータＤＢ３０１より削除して処理を終了する（Ｓ３１２１）。検証が成功しなかった場合はクーポンデータに誤りがある旨の出力がクーポン処理装置から出力され、それを基に携帯端末側ではエラー出力を行い終了する。
【００８９】
以上で携帯端末側の処理に関する説明を全て終了する。
【００９０】
続いてクーポン処理装置について詳しく説明する。なお、クーポン処理装置の処理手順は、携帯端末のそれと重複する部分が多いので異なる部分を中心に説明を行う。
【００９１】
図３４は、クーポン処理装置の全体構成を示すブロック図、図３５はクーポンデータを受理し割引を実施するまでの処理手順を示すフローチャートである。以下、受信したクーポンの処理に関して図３４の全体構成図を参照しながら、図３５のフローチャートに沿って説明する。
【００９２】
まず、顧客の携帯端末からクーポン処理装置を通信で呼び出し接続する（Ｓ３５０）。接続が行われたら、上述した携帯端末側の処理手順と同様に、クーポン処理装置との相互機器認証を行ない、認証に失敗したらエラー出力などを行い終了する（Ｓ３５１〜Ｓ３５６）。機器認証に成功したら、制御部３４１は携帯端末に携帯端末ＩＤの出力を要請し、携帯端末は携帯端末内の限定受信部１３１の携帯端末ＩＤ格納部から携帯端末ＩＤを取得して、制御部にこれを渡す（Ｓ３５７）。取得された携帯端末ＩＤは、送受信部を経由してクーポン処理装置に送信され、クーポン処理装置は携帯端末ＩＤのリボケーションリストを利用した認証を行う（Ｓ３５８）。認証が失敗した場合にはエラー出力して処理を終了し（Ｓ３５９）、成功した場合には、制御部３４１は従業員カード読込部３４４に従業員ＩＤ、店舗ＩＤ及び従業員の公開鍵証明書の読込みを命じ（Ｓ３５１０，Ｓ２５１１）、読み込んだ従業員ＩＤ、店舗ＩＤ、従業員の公開鍵証明書を携帯端末に送信する（Ｓ３５１２）。携帯端末はこれを受けて店舗・従業員リボケーションリスト３０６を検索し、当該店舗ＩＤの店舗もしくは当該店舗ＩＤの店舗の当該従業員ＩＤの従業員がリボークされていないかどうか確認する。ここでリボークされていた場合は、要注意従業員である旨のエラー出力が成され、処理をここで終了する（Ｓ３５１４）。リボークされていない場合には検証に成功したので処理を制御部３０５に移す。
【００９３】
制御部３４１は、携帯端末からクーポンデータを受信し（Ｓ３５１６）、当該クーポンデータをクーポンデータ検証部３４５に送信し、クーポンデータの検証を行う。クーポンデータの検証は、まずクーポンデータの基本クーポンデータ部分からサービス業者ＩＤ、クーポン識別子を抽出するとともに、付加クーポンデータから有効期限を抽出して、当該クーポンデータの有効性を判定する。有効性はまずサービス業者ＩＤのマッチングを行い自業者（もしくは提携業者）のものであることを確認した上で、クーポン識別子が現在可能なサービスか否かをチェックし、更に付加ポイントデータの中の有効期限内であることを確認することにより行う（Ｓ３５１７）。利用可能でない場合には、その旨のエラー出力を行い処理を終了する（Ｓ３５１８）。利用可能である場合には引き続き基本クーポンデータの認証を行う（Ｓ３５１９）。基本ポイントデータの認証は基本ポイントデータからサービス業者の公開鍵証明書を取得し、それを認証局公開鍵格納部３４６にある認証局の公開鍵で認証する。認証に失敗した場合にはそこで処理を終了し、エラーを出力する（Ｓ３５２１）。認証に成功した場合には公開鍵証明書の公開鍵を使って、基本ポイントデータに含まれるサービス業者のデジタル署名を検証する。検証に失敗した場合にはエラー出力をして処理を終了する。検証に成功した場合には引き続き付加ポイントデータの認証を行う（Ｓ３５２２）。付加ポイントデータの検証は基本ポイントデータの検証と同様なので省略する。
【００９４】
付加ポイントデータの検証が終了したら、制御部３４１は基本クーポンデータの割引額を付加クーポンデータで修正して割引額を算定し（Ｓ３５２６）、クーポンによる割引を実施し（Ｓ３５２７）、購入額から割引額を減額して請求する。更に、クーポンサービスを実施した旨を携帯端末に送信し（Ｓ３５２８）、携帯端末ではこれを受けて当該クーポンデータを消去する。次に制御部３４１はクーポンログ作成部３４７に処理を移し、図３６のようにクーポンデータにサービス実施時刻と従業員の秘密鍵によるデジタル署名及び従業員の公開鍵証明書とを付けてクーポンログファイルを完成させる（Ｓ３５２９）。このログファイルはクーポンサーバ３に送信され（Ｓ３５３０）、クーポンサーバ３上のデータベースに蓄積され、次に詳しく説明するように不正行為の検出処理に利用される。
【００９５】
続いてクーポンサーバの処理に関して詳しく説明する。図３７はクーポンサーバの全体構成を示すブロック図、図３８はクーポンを検査するための処理手順を示すフローチャートである。以下、クーポンの検査処理に関して図３７の全体構成図を参照しながら、図３８のフローチャートに沿って説明する。
【００９６】
クーポンサーバ３はクーポン処理装置２から送信されてくるクーポンログデータを送受信部３７１経由で受け、クーポンログデータ管理部３７２を経て、クーポンログデータＤＢ３７３に格納する。ここで、放送配信される基本クーポンデータは基本クーポンデータＤＢ３７４に、利用者の購入実績は購入実績ＤＢ３７５に、視聴契約情報は視聴契約ＤＢ３７６に、それぞれ基本クーポンデータ出入力部３７６、購入実績出入力部３７７、視聴契約出入力部３７８から入力され管理される。
【００９７】
以下、クーポログンデータを携帯端末毎に検査することによって不正取引があった場合はその事実を検知し、ならびにクーポンログデータの携帯端末ＩＤ、店舗ＩＤ、従業員ＩＤなどからかかる不正者を特定する処理手順を示す。各クーポン処理装置からのクーポンログデータの収集が完了した段階で、本処理手順は制御部３７９によって開始される。制御部３７９ではクーポンログ検査部３７１０にクーポンログデータの検査を行うように指示する。クーポンログデータ検査部３７１０ではこれを受けてｉ＝０にセットして検査を開始する（Ｓ３８２）。
【００９８】
検査は以下の手順で行う。尚、全ての携帯端末ＩＤは０からＭＡＸＩＤまでの間で設定されていると考える。まず、ｉを携帯端末ＩＤとして含むようなクーポンデータの存在をクーポンログデータＤＢ３７３を検索してチェックする（Ｓ３８３）。もしそのような携帯端末ＩＤを含むようなクーポンデータが存在しなかったら、ｉ＜ＭＡＸＩＤであることを確かめて、ｉを１インクリメントし、再度クーポンログデータの存在を検索する。ここで、もしｉ＜ＭＡＸＩＤでなかった場合は、処理が全て終了したことを意味するので終了する（Ｓ３８１）。
【００９９】
ｉを携帯端末ＩＤに持つようなクーポンログデータがクーポンログＤＢ３７３内に存在したら、クーポンログデータを全て検索してそのようなクーポンログデータを全て抽出する（Ｓ３８４）。そしてこれをクーポンログデータにある利用時刻情報に基づいてソートし、時間の早い順に並べる（Ｓ３８５）。
【０１００】
そして、その中のそれぞれのクーポンログデータに関し、まずクーポンログデータに付加された従業員のデジタル署名の検証を行う（Ｓ３８６）。この認証はまず、クーポンログデータに付けられた従業員の公開鍵証明書を認証局の公開鍵で認証し、認証に成功したら、上記公開鍵証明書に埋め込まれている公開鍵でデジタル署名を検証する。ここで、公開鍵証明書の認証、デジタル署名の認証のいずれかで認証に失敗した際には異常出力（Ｓ３８９）を行い、当該携帯端末の検証処理を中断してｉを１インクリメントし（Ｓ３８０）、次のクーポンログデータの処理（Ｓ３８３〜）に移行する。
【０１０１】
デジタル署名の認証に成功したら（Ｓ３８７）、次に基本クーポンデータを認証する（Ｓ３８８）。認証の方式はクーポン処理装置における同じ処理と同じなので、ここでは省略する。ここで、認証に失敗するクーポンログデータが存在した場合には（Ｓ３８１０）、異常出力を行い（Ｓ３８１１）、当該携帯端末の検証処理を中断してｉを１インクリメントし、次のクーポンログデータの処理に移行する。全てのクーポンログデータにおいて基本クーポンデータの異常が発生しなかった場合は、次に付加クーポンログデータの認証を行う（Ｓ３８１２）。この処理もクーポン処理装置におけるそれと同じであり、認証に失敗したときの処理も基本クーポンデータの場合と同様である。
【０１０２】
全てのクーポンログデータで付加クーポンデータの異常が発生しなかったときは、次に、付加ポイントデータとそれに対応する前回までにクーポン使用履歴、購入実績、放送契約の状態をそれぞれ、前回までにクーポンログＤＢ３７３、購入実績ＤＢ３７５、視聴契約ＤＢ３７６を参照して付加ポイントデータの正当性を検証する（Ｓ３８１５）。即ち、付加クーポンデータの作成時にそのような条件の付加クーポンデータを作ることが可能であったかを検査する。これによって仮に特定の携帯端末、クーポン処理装置のセキュリティ機能が破られていたとしても、不正を検出することができる。全てのクーポンログデータに関して付加クーポンデータが正当であった場合は当該携帯端末のクーポンログデータは正常であると判断し（Ｓ３８１６）、ｉを１インクリメントさせ、次の携帯端末ＩＤの携帯端末のクーポンログデータを検証する。しかし、いずれかに矛盾が生じたときには異常出力を行い（Ｓ３８１７）、当該携帯端末の検証処理を中断し、ｉを１インクリメントさせ、次の携帯端末ＩＤの携帯端末のクーポンログデータを検証する。
【０１０３】
さて、検査の結果異常であると判定された携帯端末ＩＤに関してはリボケーションリスト出入力部３７１１のインターフェースを利用してクーポンログデータＤＢ３７３を含む上記複数のＤＢを検索して異常の原因を探り、不正者を特定する。ここで注意しなくてはならないのは、不正者は必ずしも携帯端末の保持者とは限らないことである。何故なら従業員が利用者のデータをコピーするなどして不正利用している可能性もあるからである。後者のような場合、クーポンログデータの従業員ＩＤが常に同じ人物であることなどから犯人を特定することができる。このような理由のため不正者を特定する処理を誤りなく自動化することは難しい。
【０１０４】
尚、不正者が特定された場合、本実施形態ではリボケーションリスト入出力部３７１１を利用して店舗や従業員の不正であれば店舗・従業員リボケーションリスト管理部３７１２、利用者の不正であれば携帯端末リボケーションリスト管理部３７１３、また機器のハッキングが発覚した場合には機器リボケーションリスト管理部３７１４を経由してそれぞれのリボケーションリストＤＢ（３７１５、３７１６、３７１７）に登録する。
【０１０５】
また、これらのリボケーションリストを実際の携帯端末、クーポン処理装置に対して反映するには以下のような処理を行えばよい。まずクーポン処理装置に対しては例えば毎営業日の開始時までにクーポンサーバから各クーポン処理装置に新しい機器リボケーションリストと携帯端末リボケーションリストもしくはそれらの昨日との差分を送信する。携帯端末については機器リボケーションリストと店舗・従業員リボケーションリストを１ヶ月に１回程度の割合で公衆回線を通じて変更しても良いし、携帯端末自らがインターネットのホームページからダウンロードしてもよい。
【０１０６】
以上で実施形態の基本的な構成とその処理の説明を終了する。次にいくつかのバリエーションを述べる。
【０１０７】
第１のバリエーションは本実施形態におけるクーポン配信を放送でなく、公衆回線を使った電話などの双方向通信で行う方法である。双方向通信を利用することによってクーポンデータが視聴者に確実に送信される。これによって、放送では視聴者によって視聴している時間が異なるため、繰り返し配信しなければならないという点が解消される。しかし、比較的広い地域に配信するには通信費が掛かってしまう。そこで、インターネットを利用してアクセスしてくれる視聴者のみにクーポンをダウンロードする方法が考えられる。この手法では上述した通信費の問題は解決する。しかし、たまたまアクセスしてくれた特定の視聴者のみにクーポンを配信することになる。以上のように双方向通信によってクーポン配信を行う場合は現実的には受信者が偏るという問題がある。しかし、狭い地域住民への商店の販売促進のためのクーポンや一部の人しか使わないような専門的な物品の販売などの場合は本バリエーションの方式が放送配信よりも費用の点で優れている。
【０１０８】
第２のバリエーションは本実施形態では放送として有料放送を考えてきたが、有料放送でなくとも本発明は実施できる。例えば商店街が当該商店街内で流している無料放送で基本クーポンデータを送信するバリエーションが考えられている。この場合放送コンテンツを暗号化しないならば携帯端末の限定受信部は必要ない。もっともこの場合でも限定受信部に含まれる携帯端末ＩＤは限定受信部とは別に設けなくてはならない。このように構成することでより小さな構成で構成できるばかりでなく、複雑な処理がなくなるので面倒な操作もなくなる。
【０１０９】
第３のバリエーションは付加クーポンデータに携帯端末ＩＤではなく利用者ＩＤを付けるというバリエーションである。このようにすることによって不正者が携帯端末を変更した場合でも確実にリボークすることができる。しかし、このように構成するためには利用者側に利用者固有の情報を持ったＩＣカードを所有してもらわなくてはならない。このためコストが掛かり普及が困難な場合もある。更に携帯電話にこれを導入しようと考えると通常のＩＣカードではなくＳＩＭカードのようなＩＣカードを利用するようになる。尚、このバリエーションもそれぞれの機器の構成や処理手順に変化を加えなくても実現できる。
【０１１０】
第４のバリエーションはリボケーションを行わない構成方法である。このようにすると不正者が特定できても捕まえることができないように思えるが、利用者も店舗もまたその従業員も予めしっかり登録をしてサービスを開始すれば、その住所などから不正者に直接不正に対する補償を求めることができる。そればかりか本実施形態の様々なところで出現したリボケーションに関する処理が省略できるため高速なサービスが提供できる。実際、現行の携帯端末の無線通信機能を利用した一部のサービスにはサービスに掛かる処理時間が問題となっているものがありそのような場合に本バリエーションは有効である。
【０１１１】
第５のバリエーションは本実施形態では携帯端末でこれを構成したが、モバイルであることが本質的なので、従来技術のところで述べたような車に搭載された、受信端末でも利用可能である。この場合、受信端末を車の中から取り出せないことから受信端末とクーポン処理装置との接続処理が問題となるが従来技術で述べたＢｌｕｅｔｏｏｔｈ（商標）による通信を利用すると、指向性なく１０ｍは届くため、十分接続が可能である。
【０１１２】
第６のバリエーションは付加ポイントデータに氏名、住所、年齢、メールアドレスなどの個人情報を入力する構成方法である。ここまで本実施形態では付加ポイントに追加するデータは購入履歴などの情報から得られた割引加算率情報のみであり、必ずしも顧客個人を特定する情報ではなかった。しかし、従来からクーポンサービスは新規顧客の開拓に利用されてきたため、住所、氏名などの個人情報は（サービス業者にとって）極めて有用である。このため本バリエーションのように単に割引加算額だけでなく、個人情報を付加する必要がある。
【０１１３】
この要請を満たすためには、クーポンポリシー中の許可条件の中に「個人情報（住所、氏名、メールアドレス）の追加」を入れ、個人情報の追加をクーポン発行の条件とするとともに、図３９に示す通り、付加ポイントデータ本体に利用者氏名、利用者住所、利用者メールアドレスを追加すればよい。
【０１１４】
第７のバリエーションはセキュリティを重視しない構成方法である。本実施形態の割引額加算のように金銭に直結するサービス形態においては、セキュリティを重視した構成にならざるを得ないが、クーポンサービスには粗品を進呈するなどのように例え不正が起きても影響が少ないものも存在する。このようなクーポンサービスにおいてはセキュリティを重視した本実施形態のような構成であると、認証処理に相当の処理時間が掛かり、かえって使いにくいという問題点がある。このような場合、あえてセキュリティ処理を省略した方式とすることが望ましい。
【０１１５】
本バリエーションのクーポンデータにおける基本クーポンデータ、付加クーポンデータは図４０、図４１に示す構成であり、上述した実施形態の基本クーポンデータ、付加クーポンデータのそれぞれから公開鍵証明書とデジタル署名を除いた形態となっている。実際のところ、十分な安全性を満たすためにはこれらのデータはその他のデータと比較してサイズが大きく、この部分を削除することにより通信量を減らせるという２次的な効果も期待できる。
【０１１６】
また、基本クーポンデータと付加クーポンデータの一方のみを上述のように構成するというバリエーションも考えられる。このような構成は一般に基本クーポンデータと付加クーポンデータで情報の価値が相当違う場合に価値がある。例えば基本クーポンデータで割引額を１０００円とし、付加クーポンデータにおいて割引加算額が±１００円である場合には基本クーポンデータだけの安全性を守れば足りるという考え方もある。逆に基本クーポンデータでの割り引き額が１００円で、付加クーポンデータにおける割引加算額が±１０００円の時は上述とは反対に付加クーポンデータだけの安全性を守れば足りるという考え方もある。
【０１１７】
第８のバリエーションは上記第６のバリエーションと上記第７のバリエーションとの組み合わせに係る。即ち、許可条件として「個人情報（住所、氏名、メールアドレス）の提示」であり、クーポンサービスとして粗品進呈のような不正によるリスクが少ないサービスを考えたとき、サービス業者側は認証という意味で高度なセキュリティを考慮する必要がない。このような場合、上記第７のバリエーションにおける図４０に示すような基本クーポンデータに図４２に示すような付加クーポンデータを付加することによって、これを実現することが好ましい。更に進んで、図４３のように基本クーポンデータを付加クーポンデータの情報によって変更することにより実施することも可能である。この構成方法では関連付けられたデータを連結することにより、データ量を減らせるばかりか、データ処理も容易になる。図４３の例では基本クーポンデータと付加クーポンデータを別々に構成したときよりも、クーポンＩＤ、クーポンポリシーデータ、基本クーポンデータの有効期限が少なくなっている。
【０１１８】
実際、現状のクーポン券によるクーポンサービスはこのように個人情報を提示することにより、粗品を進呈するという形で実施されているものが殆どであり、本バリエーションは現状のサービスへの本発明の適用を示したものである。
【０１１９】
尚、本バリエーションにおいては基本クーポンデータを変更することにより、データを簡素化することが目的であり、この意味では変更後のクーポンデータに携帯端末や利用者のデジタル署名と公開鍵証明書を付加することは妨げない。実際、このように構成することによって、（不正の確率が高い）携帯端末利用者の不正を防ぐことができる。
【０１２０】
なお、本発明は上述した実施形態に限定されず種々変形して実施可能である。
【０１２１】
【発明の効果】
以上説明したように、本発明によれば、柔軟性と安全性を兼ね備えたクーポンサービスを実現するための携帯端末、クーポン処理装置、クーポン管理サーバを提供できる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るクーポンデータのデータ構造を示す図
【図２】本発明の実施形態に係る基本クーポンデータのデータ構造を示す図
【図３】本発明の実施形態に係る基本クーポンデータ本体のデータ構造を示す図
【図４】本発明の実施形態に係るキーワード情報のデータ構造を示す図
【図５】本発明の実施形態に係るサービス業者の公開鍵証明書のデータ構造を示す図
【図６】本発明の実施形態に係る付加クーポンデータのデータ構造を示す図
【図７】本発明の実施形態に係る付加クーポンデータ本体のデータ構造を示す図
【図８】本発明の実施形態に係る携帯端末の公開鍵証明書のデータ構造を示す図
【図９】本発明の実施形態に係るクーポンポリシーデータのデータ構造を示す図
【図１０】本発明の実施形態に係る機器認証用の公開鍵証明書のデータ構造を示す図
【図１１】本発明の一実施形態に係るクーポンサービスシステム全体の構成を示すブロック図
【図１２】本発明の実施形態に係るクーポンデータの使用に関する全体的な処理手順を示すフローチャート
【図１３】本発明の実施形態に係る携帯端末の全体構成を示すブロック図
【図１４】本発明の実施形態に係るチャネル契約情報に相当するビット列を示す図
【図１５】本発明の実施形態に係る限定受信における鍵構成を示す図
【図１６】本発明の実施形態に係るコンテンツパケットのデータ構造を示す図
【図１７】本発明の実施形態に係る個別限定受信パケットのデータ構造を示す図
【図１８】本発明の実施形態に係る契約情報のデータ構造を示す図
【図１９】本発明の実施形態に係る共通限定受信パケットのデータ構造を示す図
【図２０】本発明の実施形態に係る限定受信部の構成を示すブロック図
【図２１】本発明の実施形態に係る限定受信部の処理手順を示すフローチャート
【図２２】本発明の実施形態に係るコンテンツパケットに対する処理手順を示すフローチャート
【図２３】本発明の実施形態に係る共通限定受信パケットに関する処理手順を示すフローチャート
【図２４】本発明の実施形態に係る個別限定受信パケットに関する処理手順を示すフローチャート
【図２５】本発明の実施形態に係るクーポン処理部の構成を示すブロック図
【図２６】本発明の実施形態に係る基本クーポンデータの格納処理の処理手順を示すフローチャート
【図２７】本発明の実施形態に係る付加クーポンデータの生成処理の処理手順を示すフローチャート
【図２８】本発明の実施形態に係るクーポンポリシーから付加クーポンデータを生成する処理における必須条件のチェックの処理手順を示すフローチャート
【図２９】本発明の実施形態に係る許可条件の中から一番有利な許可条件を探索する際の処理手順を示すフローチャート
【図３０】本発明の実施形態に係るクーポン使用部の構成を示すブロック図
【図３１】本発明の実施形態に係るクーポン使用時の処理手順を示すフローチャート
【図３２】本発明の実施形態に係るクーポン処理装置による携帯端末の認証処理手順を示すフローチャート
【図３３】本発明の実施形態に係る機器認証の処理手順を示すフローチャート
【図３４】本発明の実施形態に係るクーポン処理装置の全体構成を示すブロック図
【図３５】本発明の実施形態に係るクーポンデータを受理し割引を実施するまでの処理手順を示すフローチャート
【図３６】本発明の実施形態に係るクーポンログファイルのデータ構造を示す図
【図３７】本発明の実施形態に係るクーポンサーバの全体構成を示すブロック図
【図３８】本発明の実施形態に係るクーポンを検査するための処理手順を示すフローチャート
【図３９】本発明の実施形態の変形例に係る付加ポイントデータ本体のデータ構造を示す図
【図４０】本発明の実施形態の変形例に係る基本クーポンデータのデータ構造を示す図
【図４１】本発明の実施形態の変形例に係る付加クーポンデータのデータ構造を示す図
【図４２】本発明の実施形態の変形例に係る付加クーポンデータのデータ構造を示す図
【図４３】本発明の実施形態の変形例に係る基本クーポンデータと付加クーポンデータの連結を示す図
【符号の説明】
１…携帯端末
２…クーポン処理装置
３…クーポンサーバ
４…放送衛星
５…従業員カード
６…認証局

Claims

クーポン処理装置と接続してクーポンサービスを享受可能な携帯端末であって、
前記クーポンサービスの供給元からクーポンデータを取得する手段と、
当該携帯端末の利用者に固有のクーポンサービスを享受するため用いることが可能な情報を該携帯端末の内部プロファイルから所定の処理手順に従い取得すると共に、該情報に基づいて前記クーポンデータに変更を加える手段と、
変更が加えられた前記クーポンデータを前記クーポン処理装置に送信する手段と、
を具備することを特徴とする携帯端末。
前記携帯端末の内部プロファイルから前記所定の処理手順に従い付加クーポンデータを作成する手段を具備し、
クーポンサービスの供給元から取得した前記クーポンデータに、作成された前記付加クーポンデータを付加することにより前記クーポンデータに変更を加えることを特徴とする請求項１に記載の携帯端末。
前記携帯端末の内部プロファイルは、当該携帯端末の地理的位置情報、前記クーポンサービスの供給元に係わる商品の購入実績情報、前記クーポンデータの放送に係わる視聴契約情報、および前記クーポンサービスの供給元への当該携帯端末利用者の会員登録情報のいずれかを含むことを特徴とする請求項１乃至３のいずれかに記載の携帯端末。
前記クーポン処理装置に送信する前記クーポンデータに、少なくとも当該携帯端末によるデジタル署名を添付する手段を具備することを特徴とする請求項１乃至３のいずれかに記載の携帯端末。
前記デジタル署名のための公開鍵について、所定の認証局により証明された公開鍵証明書を添付する手段を具備することを特徴とする請求項４に記載の携帯端末。
衛星放送による一方向通信に基づいて前記クーポンサービスの供給元からクーポンデータを受信することを特徴とする請求項１乃至５のいずれかに記載の携帯端末。
当該携帯端末からの要求送信を含む双方向通信に基づいて前記クーポンサービスの供給元からクーポンデータを受信することを特徴とする請求項１乃至５のいずれかに記載の携帯端末。
クーポンサービスの供給元から発行され、携帯端末を通じて該クーポンサービスの利用者から送信されたクーポンデータを受信する手段と、
当該携帯端末の利用者に固有のクーポンサービスを享受するため該携帯端末において付加された付加クーポンデータを、受信した前記クーポンデータから抽出するとともに、該付加クーポンデータに応じて前記クーポンサービスの提供内容を決定する手段と、
を具備することを特徴とするクーポン処理装置。
前記クーポンデータに添付された前記供給元によるデジタル署名、および前記付加クーポンデータに添付された前記携帯端末のデジタル署名の少なくともいずれかを、それぞれのデジタル署名について添付された公開鍵証明書に基づいて検証する手段と、
前記公開鍵証明書に基づく検証結果に基づいて、前記クーポンデータが不正なものか否かを判定する手段と、
を具備することを特徴とする請求項８に記載のクーポン処理装置。
クーポンサービスの供給元から発行され、携帯端末を通じて該クーポンサービスの利用者から送信されたクーポンデータを受信し、該クーポンデータを処理して該クーポンサービスを提供するクーポン処理装置を管理するクーポン管理サーバであって、
前記利用者のプロファイル情報を記録する手段と、
前記クーポンサービスの利用において前記クーポン処理装置が処理した前記携帯端末からのクーポンデータについての履歴データを記録する手段と、
前記プロファイル情報及び前記履歴データに基づいて、前記クーポンデータの妥当性を検査する手段と、
を具備することを特徴とするクーポン管理サーバ。
クーポン処理装置と接続してクーポンサービスを享受可能な携帯端末におけるクーポン処理方法であって、
前記クーポンサービスの供給元からクーポンデータを取得するステップと、
当該携帯端末の利用者に固有のクーポンサービスを享受するため用いることが可能な情報を該携帯端末の内部プロファイルから所定の処理手順に従い取得すると共に、該情報に基づいて前記クーポンデータに変更を加えるステップと、
変更が加えられた前記クーポンデータを前記クーポン処理装置に送信するステップと、
を具備することを特徴とするクーポン処理方法。
コンピュータをクーポン処理装置に接続してクーポンサービスを享受するためのクーポン処理プログラムであって、
前記クーポンサービスの供給元からクーポンデータを取得する機能と、
前記コンピュータの利用者に固有のクーポンサービスを享受するため用いることが可能な情報を該コンピュータの内部プロファイルから所定の処理手順に従い取得すると共に、該情報に基づいて前記クーポンデータに変更を加える機能と、
変更が加えられた前記クーポンデータを前記クーポン処理装置に送信する機能と、
を具備することを特徴とするクーポン処理プログラム。
クーポンサービスの供給元から発行されたクーポンデータに携帯端末が変更を加えるとともに該クーポンデータを該クーポンサービスの利用時にクーポン処理装置に送信するクーポンサービスシステムに適用されるクーポンデータのデータ構造であって、
前記クーポンデータは、付加クーポンデータを含み、該付加クーポンデータは、
前記クーポンサービスを前記携帯端末が享受する際の変更内容と、
前記携帯端末のデジタル署名と、
前記デジタル署名の検証に用いられる公開鍵についての所定の認証局による公開鍵証明書と、
を具備することを特徴とするクーポンデータのデータ構造。