JPWO2013047535A1 - サーバ装置、クーポン管理方法、通信システム及びプログラム - Google Patents

サーバ装置、クーポン管理方法、通信システム及びプログラム Download PDF

Info

Publication number
JPWO2013047535A1
JPWO2013047535A1 JP2013536308A JP2013536308A JPWO2013047535A1 JP WO2013047535 A1 JPWO2013047535 A1 JP WO2013047535A1 JP 2013536308 A JP2013536308 A JP 2013536308A JP 2013536308 A JP2013536308 A JP 2013536308A JP WO2013047535 A1 JPWO2013047535 A1 JP WO2013047535A1
Authority
JP
Japan
Prior art keywords
user
terminal device
terminal
electronic
electronic coupon
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2013536308A
Other languages
English (en)
Other versions
JP5661191B2 (ja
Inventor
将人 山田
将人 山田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Priority to JP2013536308A priority Critical patent/JP5661191B2/ja
Application granted granted Critical
Publication of JP5661191B2 publication Critical patent/JP5661191B2/ja
Publication of JPWO2013047535A1 publication Critical patent/JPWO2013047535A1/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

端末装置のメモリ領域を共有して複数の電子クーポンが書き込まれる場合であっても、所期の数を超えないように電子クーポンを提供する。記憶部１３は、メモリ領域２５１への書込処理の成功が確定した電子クーポンの未利用数と、この書込処理の成功が未確定である未確定数と、複数の端末装置に新たに提供可能な電子クーポンの残数を記憶する。第１更新部１１１は、第１電子クーポンの全体の残数から減じた数を第１電子クーポンの未確定数に加算する。第２更新部１１３は、未確定数の第１電子クーポンの書込処理を端末装置２０に指示する。第２更新部１１３は、端末装置２０での書込処理の成功が確定した後、第１電子クーポンの未確定数を未利用数に設定する。第２更新部１１３は、第２電子クーポンが記憶されたメモリ領域２５１に第１電子クーポンが上書きされた場合、第２電子クーポンの未利用数を残数に差し戻す。

Description

本発明は、ＩＣ（Integrated Circuit）チップ等に記憶して利用される電子クーポンを管理する技術に関する。
電子化クーポン（電子化したクーポン券）を利用したサービスが、例えば商店や企業がサービス提供者となって提供されている。電子クーポンサービスでは、携帯電話端末等の端末装置のモバイルＦｅｌｉＣａ（登録商標）等のＩＣチップに、予め入手した電子クーポンを記憶させておき、ユーザが店舗に設置されたリーダ／ライタに端末装置をかざすことによって、電子クーポンを利用することができる。この電子クーポンサービスでは、サービス提供者の予算やサービスの主旨等に照らして、例えば、提供することができる電子クーポンの総数や、ユーザ一人当たりが利用することができる数の上限が決められていることがあり、電子クーポンの提供及び利用を制限するための管理には正確さが求められる。
例えば、特許文献１は、ユーザの携帯電話と、ネットワーク上に存在する仮想店舗と、電子クーポンの利用状況を管理するクーポン管理サーバとを備えるシステムにおいて、電子クーポンが２重利用されないようにする仕組みについて開示している。特許文献１に記載された発明では、携帯電話が非接触ＩＣチップから電子クーポンを読み取ったことを契機に、自携帯電話が記憶する電子クーポンの利用可否を示す利用フラグを書き換えて、利用フラグが利用不可であることを示す期間には電子クーポンを利用できないようにする。この構成により、電子クーポンの利用の際に、携帯電話と仮想店舗との通信が切断した場合であっても、電子クーポンが２重利用されるのを回避することができる。特許文献２は、顧客側のＩＣカードが電子クーポンサービス毎に利用回数と上限回数とを記憶し、店舗端末がＩＣカードに記憶された利用回数と上限回数を読み取って、両者を比較することにより、電子クーポンの利用を制限することを開示している。特許文献３は、電子クーポンの再配布に伴う、電子クーポンの無制限な提供を防止するための仕組みを開示している。特許文献１に記載の発明では、クーポン発行サーバが、電子クーポンを発券する携帯端末のユーザ識別情報を記憶するデータベースや、該ユーザ識別情報と該携帯端末からの電子クーポンの再配布が許可された端末のユーザ識別情報とを紐付けたデータベースを有し、該紐付けの関係を満たす場合にのみ、該携帯端末からの電子クーポンの再配布が許可される。
特開２００８−２２５７１６号公報 特開２００６−２２１３８３号公報 特開２００７−７２９０６号公報
特許文献１及び特許文献２は、提供者側のサーバからユーザ側の端末装置に電子クーポンを提供する際の処理を原因として、複数の端末装置（例えば、クーポンを取得することができるすべての端末装置）に対して、予め決められた数を超えて電子クーポンが提供されることを防ぐための仕組みについては開示していない。ところで、電子クーポンが記憶させられるメモリ領域がサービス提供者毎（言い換えれば、電子クーポン毎）に分けられていて、各領域を一のサービス提供者に占有させる仕様であれば、提供者側のサーバからでも、ユーザ側の端末装置に記憶された電子クーポンの管理をしやすい。しかしながら、サービス提供者に占有させる領域を割り当てない仕組みによって、電子クーポンに関する情報を管理しようとすると、或る電子クーポンがメモリ領域に書き込まれた後、別の電子クーポンによって上書き消去されてしまったような場合に、提供者側のサーバからユーザ側の端末装置に記憶された電子クーポンに関する情報を正確に管理することが難しい。電子クーポンに関する情報がサーバ側で正確な管理が実現されないと、所期の数を超えて電子クーポンが提供されてしまうおそれがある。
また、提供可能な数がユーザ毎に制限された電子クーポンの各ユーザの保有状況を、ユーザ固有の識別子であるユーザＩＤを用いて管理しても、提供可能な数を超えて電子クーポンが利用される可能性がある。例えば、悪意のあるユーザが複数回会員登録を行うなどして１のユーザに複数のユーザＩＤが割り当てられた場合、そのユーザは、各ユーザＩＤを用いて電子クーポンを取得し利用することができる。厳格に１のユーザにつき１のユーザＩＤを割り当てることのできるシステムでは、ユーザがユーザＩＤを忘れたりそのユーザＩＤを用いたユーザ認証に必要なパスワードを忘れたりした場合には、ユーザＩＤの再発行に係る手続きが煩雑にならざるを得ない、という別の問題が生じる。
そこで、本発明は、端末装置のメモリ領域を共有して複数の電子クーポンが書き込まれる場合であっても、所期の数を超えないように電子クーポンを提供できるようにすることである。
上述した課題を解決するため、本発明のサーバ装置は、端末装置に提供されて当該端末装置において利用される各電子クーポンについて、前記端末装置に提供された電子クーポンの未利用数と、前記端末装置に対して新たに提供可能な電子クーポンの残数を記憶する第１記憶部と、前記電子クーポンが提供された端末装置を識別する端末ＩＤに、当該端末装置のユーザを識別する１のユーザＩＤを対応付けて記憶する第２記憶部と、前記電子クーポンを第１の端末装置に新たに提供する場合に、当該第１の端末装置の端末ＩＤと当該第１の端末装置のユーザのユーザＩＤとを取得する取得部と、前記電子クーポンの残数から、前記第１の端末装置に提供される前記電子クーポンの数を減じるよう、前記第１記憶部を更新する第１更新部と、前記第１更新部により減じられた数の電子クーポンについて前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する書込指示部と、前記書込指示部により前記書込処理の実行が指示される場合、前記第２記憶部において前記取得した端末ＩＤに前記取得したユーザＩＤを対応付ける書込部と、前記書込指示部の指示に応じた前記書込処理の成功が確定した後、前記減じられた数を前記電子クーポンの未利用数に設定するよう、前記第１記憶部を更新する第２更新部とを備えることを特徴とする。
本発明のサーバ装置において、前記第２更新部は、前記書込指示部の指示に応じた前記書込処理により他の電子クーポンに前記電子クーポンが上書きされた場合、当該他の電子クーポンの未利用数を当該他の電子クーポンの残数に加算して、当該未利用数をクリアするよう、前記第１記憶部を更新することが好ましい。
本発明のサーバ装置において、前記第１更新部は、前記第１電子クーポンの残数から減じた数を、前記書込処理の成功が未確定の電子クーポンの数である未確定数に設定して、前記第１記憶部に記憶させ、前記第２更新部は、前記書込処理の成功が確定した後、前記減じられた数である前記電子クーポンの未確定数を、前記電子クーポンの未利用数に設定し、当該未確定数をクリアすることが好ましい。
本発明のサーバ装置において、前記第２更新部は、前記第１の端末装置が前記指示に応じた前記書込処理に失敗した場合、前記未確定数を前記電子クーポンの残数に加算し、当該未確定数をクリアすることが好ましい。
本発明のサーバ装置において、前記第１記憶部は、一の端末装置に対して新たに提供可能な電子クーポンの残数を記憶し、前記第１の端末装置が利用した前記電子クーポンの利用数を含む利用履歴を取得する利用履歴取得部と、前記利用履歴取得部が取得した利用履歴に基づいて、前記利用した電子クーポンの前記未利用数、及び前記一の端末装置に対する残数のそれぞれから、前記利用数を減じるよう、前記第１記憶部を更新する第３更新部とを備えることが好ましい。
本発明のサーバ装置において、前記メモリ領域に前記電子クーポンを書き込む前記書込処理が終了した旨の通知を受け付けた後、前記第１の端末装置から前記書込処理の結果を取得する管理サーバに問い合わせて当該結果を取得する処理結果取得部を備え、前記第２更新部は、前記処理結果取得部により取得された前記結果に応じて、前記書込処理の成功が確定したか否かを判断することが好ましい。
本発明のサーバ装置において、前記書込指示部は、前記第２記憶部において、前記取得部が取得した端末ＩＤに前記取得部が取得したユーザＩＤと異なるユーザＩＤが対応付けられていない場合、又は、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に予め決められた条件を満たすときには、前記指示を行うことが好ましい。
本発明のサーバ装置において、前記書込指示部は、前記第２記憶部において、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に、前記条件を満たさないときには、前記指示を行わないことが好ましい。
本発明のサーバ装置において、前記書込指示部は、前記第２記憶部において、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合には、前記指示を行い、前記書込部は、前記条件を満たさないときに前記書込指示部により前記指示が行われた場合には、前記第２記憶部において前記取得した端末ＩＤに対応付けられたユーザＩＤを変更しないことが好ましい。
本発明のサーバ装置において、前記取得部は、前記第１の端末装置から前記端末ＩＤを取得したが前記ユーザＩＤを取得しなかった場合に、前記第２記憶部において当該端末ＩＤにいずれかのユーザＩＤが対応付けられているときには当該ユーザＩＤを取得し、前記第２記憶部において当該端末ＩＤがいずれのユーザＩＤとも対応付けられていないときには新たにユーザＩＤを発行して取得し、前記書込部は、前記書込指示部により前記指示が行われた場合に、前記取得部が前記第２記憶部からユーザＩＤを取得していたときには、前記取得した端末ＩＤに対応付けられたユーザＩＤを変更せず、新たにユーザＩＤを発行して取得していたときには、当該ユーザＩＤを前記取得した端末ＩＤに対応付けて前記第２記憶部に書き込むことが好ましい。
本発明のサーバ装置において、前記書込指示部は、前記指示を行ってから予め決められた期間が経過したことを前記条件とすることが好ましい。
本発明のサーバ装置において、前記書込指示部は、前記電子クーポンの利用可能期間が経過したことを前記条件とすることが好ましい。
本発明のサーバ装置において、前記書込指示部は、複数種類の電子クーポンについて、前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示した場合、終了時期が最も後である電子クーポンの利用可能期間が経過したことを前記条件とすることが好ましい。
本発明のサーバ装置において、前記端末ＩＤは、当該端末ＩＤが示す端末装置が有するメモリ領域に記憶され、提供可能な数がユーザ毎に制限された電子クーポンを提供する場合には、前記メモリ領域からの前記端末ＩＤの読み出しを指示し、提供可能な数がユーザ毎に制限されていない電子クーポンを当該第１の端末装置に提供する場合には、前記端末ＩＤの読み出しを指示しない読出指示部を備え、前記取得部は、前記読出指示部により前記端末ＩＤの読み出しが指示された場合に、当該指示に従って前記メモリ領域から読み出された前記端末ＩＤを取得し、前記書込指示部は、前記読出指示部により前記端末ＩＤの読み出しが指示されなかった場合に、前記提供可能な数がユーザ毎に制限されていない電子クーポンを前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示することが好ましい。
本発明のサーバ装置において、前記第２記憶部において、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられており、かつ、前記条件を満たす場合に、前記第２記憶部において、前記取得したユーザＩＤと、前記取得した端末ＩＤと異なる端末ＩＤとが対応付けられているときに、当該取得したユーザＩＤと当該異なる端末ＩＤとの対応付けを削除する削除部をさらに備えることが好ましい。
本発明のクーポン管理方法は、端末装置に提供されて当該端末装置において利用される各電子クーポンについて、前記端末装置に提供された電子クーポンの未利用数と、前記端末装置に対して新たに提供可能な電子クーポンの残数を記憶する第１記憶部と、前記電子クーポンが提供された端末装置を識別する端末ＩＤに、当該端末装置のユーザを識別する１のユーザＩＤを対応付けて記憶する第２記憶部とを備えるサーバ装置のクーポン管理方法であって、前記電子クーポンを第１の端末装置に新たに提供する場合に、当該第１の端末装置の端末ＩＤと当該第１の端末装置のユーザのユーザＩＤとを取得する取得ステップと、前記電子クーポンの残数から、前記第１の端末装置に提供される前記電子クーポンの数を減じるよう、前記第１記憶部を更新する第１更新ステップと、前記第１更新ステップにおいて減じられた数の電子クーポンについて前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する書込指示ステップと、前記書込指示ステップにおいて前記書込処理の実行が指示される場合、前記第２記憶部において前記取得した端末ＩＤに前記取得したユーザＩＤを対応付ける書込ステップと、前記書込指示ステップにおける指示に応じた前記書込処理の成功が確定した後、前記減じられた数を前記電子クーポンの未利用数に設定するよう、前記第１記憶部を更新する第２更新ステップとを有することを特徴とする。
本発明のクーポン管理方法において、前記第１記憶部は、端末装置が有するメモリ領域への書込処理の成功が確定した電子クーポンの未利用数を、端末装置に提供された電子クーポンの未利用数として記憶し、前記第２更新ステップは、前記書込指示部の指示に応じた前記書込処理により他の電子クーポンに前記電子クーポンが上書きされた場合、当該他の電子クーポンの未利用数を当該他の電子クーポンの残数に加算して、当該未利用数をクリアするよう、前記第１記憶部を更新することが好ましい。
本発明のクーポン管理方法において、前記書込指示ステップは、前記第２記憶部において、前記取得ステップで取得した端末ＩＤに前記取得ステップで取得したユーザＩＤと異なるユーザＩＤが対応付けられていない場合、又は、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に予め決められた条件を満たすときには、前記指示を行うことが好ましい。
本発明の通信システムは、サーバ装置と端末装置とを備える通信システムであって、前記サーバ装置は、端末装置に提供されて当該端末装置において利用される各電子クーポンについて、前記端末装置に提供された電子クーポンの未利用数と、前記端末装置に対して新たに提供可能な電子クーポンの残数を記憶する第１記憶部と、前記電子クーポンが提供された端末装置を識別する端末ＩＤに、当該端末装置のユーザを識別する１のユーザＩＤを対応付けて記憶する第２記憶部と、前記電子クーポンを第１の端末装置に新たに提供する場合に、当該第１の端末装置の端末ＩＤと当該第１の端末装置のユーザのユーザＩＤとを取得する取得部と、前記電子クーポンの残数から、前記第１の端末装置に提供される前記電子クーポンの数を減じるよう、前記第１記憶部を更新する第１更新部と、前記第１更新部により減じられた数の電子クーポンについて前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する書込指示部と、前記書込指示部により前記書込処理の実行が指示される場合、前記第２記憶部において前記取得した端末ＩＤに前記取得したユーザＩＤを対応付ける書込部と、前記書込指示部の指示に応じた前記書込処理の成功が確定した後、前記減じられた数を前記電子クーポンの未利用数に設定するよう、前記第１記憶部を更新する第２更新部とを備え、前記端末装置は、前記書込指示部の指示に従った前記書込処理により前記未利用数の電子クーポンを前記メモリ領域に書き込み、当該書込処理を終了したことを前記サーバ装置に通知することを特徴とする。
本発明の通信システムにおいて、前記第１記憶部は、端末装置が有するメモリ領域への書込処理の成功が確定した電子クーポンの未利用数を、端末装置に提供された電子クーポンの未利用数として記憶し、前記第２更新部は、前記書込指示部の指示に応じた前記書込処理により他の電子クーポンに前記電子クーポンが上書きされた場合、当該他の電子クーポンの未利用数を当該他の電子クーポンの残数に加算して、当該未利用数をクリアするよう、前記第１記憶部を更新することが好ましい。
本発明のプログラムは、端末装置に提供されて当該端末装置において利用される各電子クーポンについて、前記端末装置に提供された電子クーポンの未利用数と、前記端末装置に対して新たに提供可能な電子クーポンの残数を記憶する第１記憶部と、前記電子クーポンが提供された端末装置を識別する端末ＩＤに、当該端末装置のユーザを識別する１のユーザＩＤを対応付けて記憶する第２記憶部とを備えるコンピュータに、前記電子クーポンを第１の端末装置に新たに提供する場合に、当該第１の端末装置の端末ＩＤと当該第１の端末装置のユーザのユーザＩＤとを取得する取得ステップと、前記電子クーポンの残数から、前記第１の端末装置に提供される前記電子クーポンの数を減じるよう、前記第１記憶部を更新する第１更新ステップと、前記第１更新ステップにおいて減じられた数の電子クーポンについて前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する書込指示ステップと、前記書込指示ステップにおいて前記書込処理の実行が指示される場合、前記第２記憶部において前記取得した端末ＩＤに前記取得したユーザＩＤを対応付ける書込ステップと、前記書込指示ステップにおける指示に応じた前記書込処理の成功が確定した後、前記減じられた数を前記電子クーポンの未利用数に設定するよう、前記第１記憶部を更新する第２更新ステップとを実行させる。
本発明のプログラムにおいて、前記書込指示ステップは、前記第２記憶部において、前記取得ステップで取得した端末ＩＤに前記取得ステップで取得したユーザＩＤと異なるユーザＩＤが対応付けられていない場合、又は、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に予め決められた条件を満たすときには、前記指示を行うことが好ましい。
本発明によれば、端末装置のメモリ領域を共有して複数の電子クーポンが書き込まれる場合であっても、所期の数を超えないように電子クーポンを提供することができる。
通信システムの全体構成を示す図。 ＡＳＰサーバのハードウェア構成を示すブロック図。 クーポン管理テーブルのデータ構造を示す図。 ユーザ管理テーブルのデータ構造を示す図。 トランザクション管理テーブルのデータ構造を示す図。 保留リストテーブルのデータ構造を示す図。 端末装置のハードウェア構成を示すブロック図。 電子クーポンの提供に関する機能の機能的構成を示す機能ブロック図。 電子クーポンの利用に関する機能の機能的構成を示す機能ブロック図。 通信システムの全体的な処理の流れを示すシーケンスチャート。 端末装置が電子クーポンを取得しようとするときの画面例。 セット開始処理の流れを示すフローチャート。 データテーブルの更新の様子を示す図。 セット確定処理の流れを示すフローチャート。 セット確定処理の流れを示すフローチャート。 データテーブルの更新の様子を示す図。 データテーブルの更新の様子を示す図。 利用時処理の流れを示すフローチャート。 利用時処理により変化するデータテーブルのデータ構造を示す図。 データテーブルの更新の様子を示す図。 データテーブルの更新の様子を示す図。 データテーブルの更新の様子を示す図。 データテーブルの更新の様子を示す図。 ＡＳＰサーバのハードウェア構成を示すブロック図。 クーポン情報テーブルの構成を示す図。 ユーザ管理テーブルの構成を示す図。 保有状況管理テーブルの構成を示す図。 電子クーポンの管理に関する機能の機能的構成を示す機能ブロック図。 通信システムの全体的な処理の流れを示すシーケンスチャート。 クーポン取得画面を示す図。 端末ＩＤ要否判定処理の手順を示すフローチャート。 端末ＩＤ通知処理の手順を示すフローチャート。 クーポン提供判定処理の手順を示すフローチャート。 ユーザ管理テーブルの更新の様子を示す図。 ユーザ管理テーブルの更新の様子を示す図。 電子クーポンの書込処理の手順を示すシーケンスチャート。
１．第１実施形態
以下、図面を参照しつつ本発明の第１実施形態を説明する。
図１は、通信システム１の全体構成を示す図である。
通信システム１は、ＡＳＰ（Application Service Provider）サーバ１０と、端末装置２０と、店舗管理サーバ３０と、店舗端末４０と、アプリケーション管理サーバ５０とを備える。ＡＳＰサーバ１０は、端末装置２０に対して電子クーポンサービスを提供するサーバ装置である。ここにおいて、ＡＳＰサーバ１０は、端末装置２０からの要求に応じて、複数のサービス提供者による電子クーポンサービスを端末装置２０に提供する。端末装置２０は、ここではスマートフォンであり、ＡＳＰサーバ１０から提供された電子クーポンを取得する。ただし、端末装置２０はスマートフォンに限らず、携帯電話端末やタブレット端末、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）等の他の端末装置であってもよい。店舗管理サーバ３０は、端末装置２０により電子クーポンが利用された場合に、電子クーポンの利用の履歴である利用履歴を、ＡＳＰサーバ１０宛てに送信する。店舗端末４０は、電子クーポンを利用することができる店舗に設置されたコンピュータ装置である。店舗端末４０は、非接触式ＩＣカードとの間で無線通信を行ってデータの読み書きを行うリーダ／ライタ４１を有し、リーダ／ライタ４１により読み取ったデータに基づき利用履歴を生成し、生成した利用履歴を店舗管理サーバ３０宛てに送信する。アプリケーション管理サーバ５０は、端末装置２０における電子クーポンの書込処理に関する管理を司る管理サーバである。
通信システム１では、ＡＳＰサーバ１０、端末装置２０、店舗管理サーバ３０及びアプリケーション管理サーバ５０がそれぞれネットワークＮＷに接続されている。ネットワークＮＷは、ここでは、移動体通信網、ゲートウェイ及びインターネットを含む通信網である。店舗管理サーバ３０と店舗端末４０とは、例えば、専用の通信回線で接続されている。図１には、端末装置２０を１台だけ図示しているが、実際には、電子クーポンサービスを受けることができる端末装置２０が複数存在する。店舗管理サーバ３０は、一店舗につき一台設置されてもよいし、複数店舗につき一台設置されてもよいし、サービス提供者毎に一台ずつ設置されてもよい。店舗端末４０は、電子クーポンを利用可能な各店舗に設置されていて、実際にはより多数存在している。
図２は、ＡＳＰサーバ１０のハードウェア構成を示すブロック図である。図２に示すように、ＡＳＰサーバ１０は、制御部１１と、通信部１２と、記憶部１３とを備える。
制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）を備えるマイクロプロセッサである。ＣＰＵは、ＲＯＭや記憶部１３に記憶されたプログラムをＲＡＭに読み出して実行することにより、ＡＳＰサーバ１０の各部を制御する。通信部１２は、ネットワークＮＷに接続するためのインタフェースである。制御部１１は、通信部１２によりネットワークＮＷ経由で接続された外部装置と通信する。記憶部１３は、例えばハードディスク装置を備え、制御部１１により実行される電子クーポンサービスの提供に必要なプログラムを記憶する。また、記憶部１３は、クーポン管理テーブル１３１、ユーザ管理テーブル１３２、トランザクション管理テーブル１３３及び保留リストテーブル１３４を記憶する。
なお、記憶部１３は、電子クーポンサービスの提供に関する別の情報も記憶している。例えば、記憶部１３は、電子クーポンを提供する対象とするユーザの条件（年齢や性別等のユーザ属性）や、電子クーポンを提供する期間、電子クーポンを利用可能な期間等を記憶するが、本実施形態ではそれらの説明を省略する。ところで、本実施形態の電子クーポンは、電子バリューとも呼ばれる電子データであり、紙媒体として提供又は利用されるわけではない。しかしながら、以下の説明を理解しやすくするため、電子クーポンの提供又は利用可能な最小単位を、本実施形態では「枚」と称し、提供又は利用される電子クーポンの数（つまり、単位数）を、「枚数」と称する。
図３は、クーポン管理テーブル１３１のデータ構造を示す図である。
図３に示すように、クーポン管理テーブル１３１は、「クーポンＩＤ」と、「制限枚数（全体）」と、「利用枚数（全体）」と、「残枚数（全体）」とで示される各情報が対応付けられたデータテーブルである。「クーポンＩＤ」は、ＡＳＰサーバ１０により提供される電子クーポンを識別する識別情報である。「制限枚数（全体）」は、ＡＳＰサーバ１０により電子クーポンが提供される対象となる全ての端末装置２０（つまり、全ユーザ）に対する制限枚数（以下、「全体の制限枚数」という。）である。ＡＳＰサーバ１０では、利用を許可する電子クーポンの全ての端末装置２０に対する枚数の総和が、全体の制限枚数を超えないように管理される。「利用枚数（全体）」は、既に利用された電子クーポンの全ての端末装置２０に対する枚数の総和（以下、「全体の利用枚数」という。）である。全体の制限枚数は、全体の利用枚数の上限ということができる。「残枚数（全体）」は、全ての端末装置２０に対する電子クーポンの残数（以下、「全体の残枚数」という。）である。ＡＳＰサーバ１０では、提供する電子クーポンの全ての端末装置２０に対する枚数の総和が、全体の残枚数を超えないように管理される。
図３に示す例では、クーポンＩＤ「ＣＩＤ００１」の電子クーポンＡ、及びクーポンＩＤ「ＣＩＤ００２」の電子クーポンＢに関する情報を代表して示している。クーポンＩＤ「ＣＩＤ００１」の電子クーポンＡと、クーポンＩＤ「ＣＩＤ００２」の電子クーポンＢとは、ここでは、互いに異なるサービス提供者によって提供される電子クーポンである。図３の第１行に対応するレコードは、クーポンＩＤ「ＣＩＤ００１」の電子クーポンＡの全体の制限枚数が「１０００」であり、全体の利用枚数が「０」であり、全体の残枚数が「１０００」であることを意味する。図３の第２行に対応するレコードは、クーポンＩＤ「ＣＩＤ００２」の電子クーポンＢの全体の制限枚数が「５０００」であり、全体の利用枚数が「０」であり、全体の残枚数が「５０００」であることを意味する。
図４は、ユーザ管理テーブル１３２のデータ構造を示す図である。
図４に示すように、ユーザ管理テーブル１３２は、「ユーザＩＤ」と、「クーポンＩＤ」と、「制限枚数（個人）」と、「セット未確定枚数」と、「セット済未利用枚数」と、「利用枚数（個人）」と、「残枚数（個人）」とで示される各情報が対応付けられたデータテーブルである。「ユーザＩＤ」は、端末装置２０のユーザを識別する識別情報であるとともに、端末装置２０を識別する識別情報である。
本実施形態のユーザＩＤは、各端末装置２０に排他的に割り当てられた識別情報であるが、例えばＳＩＭ（Subscriber Identity Module）カードから特定される端末識別情報や電話番号、任意の識別番号等である。ユーザ管理テーブル１３２に書き込まれるユーザＩＤは、ここでは、端末装置２０の後述するＩＣチップ２５（具体的には、ＩＣチップ２５の所定のメモリ領域）に書き込まれたユーザＩＤに対応しているものとする。ここにおいて、同一ユーザに対応してＩＣチップ２５に書き込まれたユーザＩＤとユーザ管理テーブル１３２に書き込まれるユーザＩＤとは、一致していなくてもよい。両者のユーザＩＤが異なる場合には、例えば、ＡＳＰサーバ１０が同一のユーザのユーザＩＤ同士を対応付ける対応表を記憶部１３に記憶しておく。そして、この対応表を用いたユーザＩＤの照合により、ＡＳＰサーバ１０がユーザＩＤ同士の対応関係を特定すればよい。この対応表を用いる構成にすれば、例えば端末装置２０の機種変更が行われた場合であっても、ＡＳＰサーバ１０は対応表を更新するだけでよく、ユーザ管理テーブル１３２のユーザＩＤを更新しなくてよい。
「クーポンＩＤ」は、クーポン管理テーブル１３１に書き込まれるクーポンＩＤと同じである。「制限枚数（個人）」は、ＡＳＰサーバ１０により提供される電子クーポンの個々のユーザ（つまり、一の端末装置２０）に対する制限数（以下、「個人の制限枚数」という。）である。ＡＳＰサーバ１０では、利用を許可する電子クーポンの枚数が、一のユーザにつき個人の制限枚数を超えないように管理される。すなわち、個人の制限枚数は、個人の利用枚数の上限ということができる。
「セット未確定枚数」は、端末装置２０に提供される電子クーポンであり、ＩＣチップ２５の後述するメモリ領域２５１への書込処理（「セット」ともいう。）の成功が未確定の電子クーポンの数（未確定数）である。言い換えれば、セット未確定枚数は、電子クーポンの書込処理が終了していないか、又は電子クーポンの書込処理が成功又は失敗したがこの結果がＡＳＰサーバ１０に通知されていない（つまり、ＡＳＰサーバ１０で書込処理の結果が把握されていない）電子クーポンの枚数である。「セット済未利用枚数」は、端末装置２０に提供される電子クーポンであり、書込処理の成功が確定した未利用の電子クーポンの数（未利用数）である。言い換えれば、セット済未利用枚数は、電子クーポンがメモリ領域２５１に記憶されていると、ＡＳＰサーバ１０が把握した電子クーポンの枚数である。よって、このセット済未利用枚数の電子クーポンは、端末装置２０が利用可能な電子クーポンともいえる。
「利用枚数（個人）」は、一のユーザにより既に利用された電子クーポンの利用数（以下、「個人の利用枚数」という。）である。「残枚数（個人）」は、個々のユーザに対する電子クーポンの残数（以下、「個人の残枚数」という。）である。ＡＳＰサーバ１０では、提供する電子クーポンの枚数が、一のユーザにつき個人の残枚数を超えないように管理される。
図４に示す例では、ユーザＩＤ「ＵＩＤ００１」のユーザに対応する情報を代表して示しているが、電子クーポンサービスの提供を受けることができるユーザ毎に同様の情報が書き込まれている。例えば、図４の第１行に対応するレコードは、ユーザＩＤ「ＵＩＤ００１」のユーザにおける、クーポンＩＤ「ＣＩＤ００１」の電子クーポンＡの個人の制限枚数が「１０」であり、セット未確定枚数、セット済未利用枚数、及び個人の利用枚数がそれぞれ「０」であり、個人の残枚数が「１０」であることを意味する。図４の第２行に対応するレコードも、第１行と同様に解釈してよい。
図５は、トランザクション管理テーブル１３３のデータ構造を示す図である。
図５に示すように、トランザクション管理テーブル１３３は、「処理ＩＤ」と、「ステータス」と、「書込完了日時」とで示される各情報が対応付けられ、ユーザ毎に書込処理結果を管理するデータテーブルである。「処理ＩＤ」は、電子クーポンの書込処理を識別する識別情報である。「ステータス」は、電子クーポンの書込処理の結果を示す情報であり、成功、失敗又は未確定のいずれかを示す。書込処理が成功した場合はステータスが「成功」となり、書込処理が失敗した場合はステータスが「失敗」となり、書込処理の結果が未確定の場合はステータスが「未確定」となる。
なお、端末装置２０で電子クーポンの書込処理が成功した場合、その電子クーポンはＩＣチップ２５に記憶されているが、電子クーポンの書込処理が失敗した場合、その電子クーポンはＩＣチップ２５には記憶されていない。電子クーポンの書込処理が失敗した場合、この書込処理前にＩＣチップ２５に電子クーポンが記憶されていればこの電子クーポンがそのまま記憶された状態となる。
「書込完了日時」は、電子クーポンの書込処理が完了した日時を示す情報である。書込完了日時は、書込処理の結果が成功した場合に限って規定される情報である。図５に示すトランザクション管理テーブル１３３の例では、いずれの情報も書き込まれておらず、各フィールドがブランクである。
なお、通信システム１において実行される電子クーポンの提供に係る処理は、書込処理を含むトランザクション処理ということもでき、ＡＳＰサーバ１０と端末装置２０とで管理される電子クーポンに関する情報に齟齬が生じないように実行される。
図６は、保留リストテーブル１３４のデータ構造を示す図である。
図６に示すように、保留リストテーブル１３４は、「クーポンＩＤ」と、「利用日時」と、「利用枚数」とで示される各情報が対応付けられたデータテーブルである。「処理ＩＤ」は、トランザクション管理テーブル１３３に書き込まれる処理ＩＤと同じである。「利用日時」は、電子クーポンが利用された日時を示す情報である。「利用枚数」は、電子クーポンの個人の利用枚数である。ここでの利用枚数は、同一の電子クーポンが１回の利用において何枚利用されたかを示す。保留リストテーブル１３４の一つのレコードに書き込まれるクーポンＩＤ、利用日時及び利用枚数の組み合わせは、ＡＳＰサーバ１０が店舗端末４０から取得した利用履歴と同じである。このように、保留リストテーブル１３４は、端末装置２０による１回の電子クーポンの利用により生成される利用履歴が一つのレコードで書き込まれたデータテーブルである。
なお、図６の保留リストテーブル１３４の例では、いずれの情報も書き込まれておらず、各フィールドがブランクである。
図７は、端末装置２０のハードウェア構成を示すブロック図である。図７に示すように、端末装置２０は、制御部２１と、音声入出力部２２と、無線通信部２３と、ＵＩ（User Interface）部２４と、ＩＣチップ２５と、記憶部２６とを備える。
制御部２１は、ＣＰＵ、ＲＯＭ及びＲＡＭを有するマイクロプロセッサを備える。ＣＰＵは、ＲＯＭや記憶部２６に記憶されたプログラムをＲＡＭに読み出して実行することにより、端末装置２０の各部を制御する。音声入出力部２２は、マイクロホンやスピーカを有し、端末装置２０において音声の入出力に関わる機能を実現する。無線通信部２３は、無線通信回路やアンテナを備え、ネットワークＮＷに接続するためのインタフェースである。ＵＩ部２４は、例えばタッチパネルを備え、ユーザからの操作を受け付けるとともに、画像により情報を報知する。
ＩＣチップ２５は、プロセッサやアンテナ、データの読み書きに用いられるメモリ領域２５１を有している、近接型の非接触通信を行うためのＩＣチップである。ＩＣチップ２５のプロセッサは、アンテナにより受信した信号、又は制御部２１からの信号に応じてメモリ領域２５１にアクセスし、データの読み出し又はデータの書き込みを行う。メモリ領域２５１は、複数のサービス提供者のいずれか１のサービス提供者の電子クーポンが書き込まれるメモリ領域であり、言い換えれば、複数のサービス提供者で共有されるメモリ領域である。すなわち、或るサービス提供者の電子クーポン（第２電子クーポン）がメモリ領域２５１に記憶されている場合、他のサービス提供者の電子クーポン（第１電子クーポン）は、上書きによる書込処理で新たにメモリ領域２５１に記憶させられる。よって、元々メモリ領域２５１に記憶されていた電子クーポンは書込処理によって削除させられる。一方で、同一のサービス提供者の複数の電子クーポンについては、同時にメモリ領域２５１に記憶されることが許可される。ただし、この場合であっても、メモリ領域２５１に記憶された電子クーポンに上書きして、同一のサービス提供者の電子クーポンが書き込まれる。また、ＩＣチップ２５は、端末装置２０に割り当てられたユーザＩＤをメモリ領域２５１以外の所定のメモリ領域に記憶する。ここでは、端末装置２０のユーザのユーザＩＤを「ＵＩＤ００１」とする。ユーザＩＤは、電子クーポンの書込処理によって削除されない領域に記憶されている。
ところで、端末装置２０は、書込処理によってメモリ領域２５１の電子クーポンが削除された場合であっても、ＡＳＰサーバ１０に問い合わせることによって、いつでもその削除前の状態に戻して、電子クーポンをメモリ領域２５１に書き込むことができる。ＡＳＰサーバ１０は、ユーザ管理テーブル１３２によって端末装置２０毎に電子クーポンの提供及び利用に関する情報を管理しているからである。言い換えれば、ＡＳＰサーバ１０は、メモリ領域２５１から電子クーポンが削除された場合に、新たな電子クーポンの書込処理によって削除されたのか、又は利用により削除されたのかを、ユーザ管理テーブル１３２を参照して判定することができる。
また、メモリ領域２５１に電子クーポンを上書きにより電子クーポンの書込処理が実行される構成は、サービス提供者にとって好ましい事情もある。例えば、複数のサービス提供者の電子クーポンが端末装置２０に混在して記憶されてしまうことがないから、ユーザにとっては、電子クーポンを利用したり破棄したりする際の操作負担が軽減される。また、サービス提供者にとっても、複数のサービス提供者の電子クーポンが入り混じって表示されることがないため、他のサービス提供者とのサービスの差別化などの理由等で好ましい。
記憶部２６は、例えばＥＥＰＲＯＭを備え、制御部２１が実行するプログラムのほか、クーポン管理アプリケーション２６１を記憶する。制御部２１は、クーポン管理アプリケーション２６１を実行することにより、アプリケーション管理サーバ５０と通信して電子クーポンの書込処理を実行する。端末装置２０においては、いずれのサービス提供者の電子クーポンの提供を受ける場合にも、クーポン管理アプリケーション２６１が実行される。
次に、ＡＳＰサーバ１０の制御部１１の機能的構成を説明する。以下、電子クーポンの提供に関する機能と、電子クーポンの利用に関する機能とに分けて説明する。
図８は、ＡＳＰサーバ１０の電子クーポンの提供に関する機能の機能的構成を示す機能ブロック図である。図８に示すように、ＡＳＰサーバ１０の制御部１１は、プログラムを実行することにより、第１更新部１１１と、書込指示部１１２と、第２更新部１１３とに相当する機能を実現する。
第１更新部１１１は、端末装置２０に第１電子クーポンを新たに提供する場合、提供しようとする第１電子クーポンの枚数を、クーポン管理テーブル１３１の全体の残枚数から減じる。より詳細には、第１更新部１１１は、提供しようとする第１電子クーポンの枚数がクーポン管理テーブル１３１における第１電子クーポンのセット済未利用枚数よりも多い場合には、全体の残枚数から提供しようとする第１電子クーポンの枚数を減じるが、セット済未利用枚数の方が多い場合には、提供しようとする第１電子クーポンの枚数を全体の残枚数から減じない。そして、第１更新部１１１は、提供しようとする第１電子クーポンの枚数（全体の残枚数から提供しようとする枚数を減じた場合は、その枚数）を、第１電子クーポンのセット未確定枚数に設定するよう、ユーザ管理テーブル１３２を更新する。ここにおいて、第１更新部１１１は、第１電子クーポンを取得するためのクーポン取得要求を通信部１２により端末装置２０から取得したことを契機に、第１電子クーポンを新たに提供する処理を開始する。第１更新部１１１が全体の残枚数から減じた枚数をセット未確定枚数に設定する処理は、全体の残枚数から減じた枚数を、ゼロであるセット未確定枚数に加算する処理に等しい。
書込指示部１１２は、第１更新部１１１によりクーポン管理テーブル１３１及びユーザ管理テーブル１３２が更新された後、セット未確定枚数の第１電子クーポンをメモリ領域２５１に書き込む書込処理を実行するよう、通信部１２により端末装置２０に指示する。この指示を行う際、書込指示部１１２は、指示した書込処理の処理ＩＤと、ステータス（ここでは、ブランクとする。）と、書込完了日時（ここでは、ブランクとする。）とを対応付けて、トランザクション管理テーブル１３３に書き込む。
処理結果取得部１１４は、書込指示部１１２の指示に応じてメモリ領域２５１に第１電子クーポンを書き込む書込処理が終了した旨の通知を端末装置２０から受け付けた後、通信部１２によりアプリケーション管理サーバ５０に問い合わせて、この書込処理の結果を取得する。
第２更新部１１３は、通信部１２により端末装置２０と通信して、記憶部１３の各データテーブルを更新する。その際、第２更新部１１３は、処理結果取得部１１４が取得した書込処理の結果により書込処理の成功が確定したか否かを判断する。第２更新部１１３により実現される機能は、具体的には以下のとおりである。
第１に、第２更新部１１３は、書込指示部１１２の指示に従った第１電子クーポンの書込処理の成功が確定した後、第１電子クーポンのセット未確定枚数をセット済未利用枚数に設定して、セット未確定枚数をクリアする（つまり、ゼロにする）。ここにおいて、第２更新部１１３は、例えば、第１電子クーポンのセット済未利用枚数が「３」である場合に、「２」である第１電子クーポンのセット未確定枚数をセット済未利用枚数に設定するときには、設定後のセット済未利用枚数を「２」とする。
第２に、第２更新部１１３は、メモリ領域２５１に記憶されていた第２電子クーポンに第１電子クーポンを上書きする書込処理が端末装置２０で成功した場合、第２電子クーポンのセット済未利用枚数を第２電子クーポンの全体の残枚数に加算し、そのセット済未利用枚数をクリアする。その際、第２更新部１１３は、利用履歴が保留リストテーブル１３４に書き込まれている第２電子クーポンについては、セット済未利用枚数から利用履歴に含まれる利用枚数を減じた枚数を、全体の残枚数に加算することがある（つまり、全体の残枚数に差し戻す）。また、第２更新部１１３は、利用履歴が保留リストテーブル１３４に書き込まれている、第２電子クーポン以外の電子クーポン（第３電子クーポン）についても、セット済未利用枚数から利用履歴に含まれる利用枚数を減じた枚数を全体の残枚数に加算する。
一方、第２更新部１１３は、書込指示部１１２の指示に従った電子クーポンの書込処理の失敗が確定した場合、その電子クーポンのセット未確定枚数がセット済未利用枚数よりも多い場合には、セット未確定枚数とセット済未利用枚数との差分を、全体の残枚数に加算する（つまり、差し戻す）。第２更新部１１３は、セット未確定枚数がセット済未利用枚数以下である場合には、全体の残枚数への差し戻しを行わない。
第３に、第２更新部１１３は、第１電子クーポンの書込処理の結果が確定した場合、その結果をトランザクション管理テーブル１３３に書き込む。ここにおいて、第２更新部１１３は、成功で確定した書込処理については、ステータスを「成功」に書き換えるとともに、その書込完了日時を書き込む。
ＡＳＰサーバ１０の電子クーポンの提供に関する機能の説明は以上である。
図９は、ＡＳＰサーバ１０の電子クーポンの利用に関する機能の機能的構成を示す機能ブロック図である。図９に示すように、ＡＳＰサーバ１０の制御部１１は、プログラムを実行することにより、利用履歴取得部１１５と、第３更新部１１６とに相当する機能を実現する。
利用履歴取得部１１５は、ＩＣチップ２５のメモリ領域２５１に記憶された第１電子クーポンを端末装置２０が利用した場合、通信部１２により店舗管理サーバ３０と通信して、その第１電子クーポンの利用実績を取得する。
第３更新部１１６は、利用履歴取得部１１５が取得した第１電子クーポンの利用履歴により、記憶部１３に記憶された各データテーブルのうち、電子クーポンを利用した端末装置２０に対応する情報を更新する。
第１に、第３更新部１１６は、トランザクション管理テーブル１３３を参照して、結果が未確定である書込処理が存在せず、利用履歴取得部１１５が取得した利用履歴に含まれる利用日時が最新の書込完了日時よりも後である場合、セット済未利用枚数から利用履歴に含まれる利用枚数を減じる。一方、第３更新部１１６は、利用日時が最新の書込完了日時よりも前である場合、セット済未利用枚数から利用枚数を減じない。
第２に、第３更新部１１６は、トランザクション管理テーブル１３３を参照して、利用履歴取得部１１５が取得した利用履歴に含まれる利用日時が最新の書込完了日時よりも後である場合に、結果が未確定である書込処理が存在するときには、利用履歴に含まれる利用枚数の更新を保留して、その利用履歴を保留リストテーブル１３４に書き込む。一方、第３更新部１１６は、利用日時が最新の書込完了日時よりも前である場合には、セット済未利用枚数から利用枚数を減じない。
第３に、第３更新部１１６は、トランザクション管理テーブル１３３及び保留リストテーブル１３４を参照し、書込処理の結果がすべて確定した後、保留リストテーブル１３４に書き込まれた利用履歴に含まれる利用日時が最新の書込完了日時よりも後である場合には、セット済未利用枚数からこの利用履歴に含まれる利用枚数を減じる。一方、第３更新部１１６は、利用日時が最新の書込完了日時よりも前である場合には、セット済未利用枚数から利用枚数を減じない。
ＡＳＰサーバ１０の機能的構成の説明は以上である。次に、通信システム１の動作を説明する。
図１０は、通信システム１の全体的な処理の流れを示すシーケンスチャートである。
端末装置２０が電子クーポンを取得しようとする際には、ＡＳＰサーバ１０にアクセスしてブラウザを用いてその取得に必要な処理を行う。ここでは、端末装置２０は、取得しようとする電子クーポンを示すクーポンＩＤと電子クーポンの取得枚数とを含むクーポン取得要求を、ＡＳＰサーバ１０宛てに送信する（ステップＳａ１）。図１１は、端末装置２０が電子クーポンを取得しようとするときにＵＩ部２４に表示される画面例である。ユーザはＵＩ部２４を操作して、電子クーポンの取得枚数をプルダウンメニューＰａ１，Ｐａ２を用いて選択し、「クーポンを取得」と付されたソフトボタンＢａを選択する。
次に、ＡＳＰサーバ１０は、端末装置２０からクーポン取得要求を受信すると、セット開始処理を実行する（ステップＳａ２）。セット開始処理は、ＡＳＰサーバ１０が端末装置２０に電子クーポンの書込処理を指示するまでの処理である。次に、ＡＳＰサーバ１０は、アプリケーション管理サーバ５０に対して、電子クーポンの書込処理に関する処理依頼を行って、問合せＩＤの生成を要求する（ステップＳａ３）。アプリケーション管理サーバ５０は、ステップＳａ２の処理依頼に応じて生成した問合せＩＤを、ＡＳＰサーバ１０宛てに送信する（ステップＳａ４）。ここにおいて、処理依頼は、ＩＣチップ２５のメモリ領域２５１に書き込まれることとなる電子クーポンに関する情報（以下、「クーポン情報」という。）を含む。より具体的には、処理依頼は、クーポン取得要求と同じ電子クーポンＩＤと電子クーポンの取得枚数とを特定可能な情報を含む。問合せＩＤは、処理依頼を識別する識別情報である。
次に、ＡＳＰサーバ１０は、セット開始処理に応じた書込処理を指示するための書込指示を端末装置２０宛てに送信する（ステップＳａ５）。ここにおいて、ＡＳＰサーバ１０は、アプリケーション管理サーバ５０から受信した問合せＩＤを含めた書込指示を送信する。
端末装置２０は、ＡＳＰサーバ１０から書込指示を受信すると、クーポン管理アプリケーション２６１を実行し、アプリケーション管理サーバ５０宛てに書込指示に含まれていた問合せＩＤを送信する（ステップＳａ６）。アプリケーション管理サーバ５０は、端末装置２０から受信した問合せＩＤに対応する処理依頼に従い、書込処理に用いられるクーポン情報を端末装置２０宛てに送信する（ステップＳａ７）。端末装置２０は、アプリケーション管理サーバ５０から受信したクーポン情報に基づいて、電子クーポンの書込処理を実行する（ステップＳａ８）。ここにおいて、端末装置２０は、メモリ領域２５１に既に電子クーポンが記憶されている場合であっても、この電子クーポンへの上書きによる書込処理により、メモリ領域２５１に新たな電子クーポンを記憶させることとなる。
次に、端末装置２０は、書込処理の結果を示す結果通知を、アプリケーション管理サーバ５０宛てに送信する（ステップＳａ９）。ここにおいて、端末装置２０は、書込処理の結果が成功又は失敗のいずれであるかを示す情報と、この書込処理の書込完了日とを含む結果通知を送信する。次に、端末装置２０は、メモリ領域２５１に電子クーポンを書き込む書込処理が終了した旨を示す終了通知を、ＡＳＰサーバ１０宛てに送信する（ステップＳａ１０）。
ＡＳＰサーバ１０は、端末装置２０から送信された終了通知を受け付けた後、アプリケーション管理サーバ５０に問い合わせて、終了通知の送信元の端末装置２０における書込処理の結果の通知を要求する（ステップＳａ１１）。アプリケーション管理サーバ５０は、ＡＳＰサーバ１０からの問い合わせに応じて、ＡＳＰサーバ１０宛てに書込処理の結果（つまり、結果通知）を送信する（ステップＳａ１２）。アプリケーション管理サーバ５０が通知する書込処理の結果は、成功、失敗又は不明のいずれかである。ＡＳＰサーバ１０は、成功又は失敗という書込処理の結果を受け付けた場合には、書込処理の結果を確定させることができるが、不明という結果を受け付けた場合には、書込処理の結果を未確定のままとする。ＡＳＰサーバ１０は、ステップＳａ１２で送信されて受け付けた結果通知に従って、トランザクション管理テーブル１３３のステータスのフィールドに書込処理の結果を書き込む。
ＡＳＰサーバ１０は、端末装置２０から結果通知を受け付けると、セット確定処理を実行する（ステップＳａ１３）。セット確定処理は、端末装置２０における電子クーポンの書込処理の結果に応じて、ＡＳＰサーバ１０が各データテーブルを更新するための処理である。
上述したように、端末装置２０は、電子クーポンを利用すると直ちに（つまり、リアルタイムで）、書込結果をアプリケーション管理サーバ５０宛てに送信するとともに、終了通知をＡＳＰサーバ１０宛てに送信する。すなわち、本来は、端末装置２０の電子クーポンの書込処理が終了すると、直ちに、ＡＳＰサーバ１０はセット確定処理を開始する。しかしながら、端末装置２０が書込処理を行った後、端末装置２０が通信可能エリア外に移動するなどして、アプリケーション管理サーバ５０に結果通知を送信できなかったり、終了通知をＡＳＰサーバ１０に送信できなかったりした場合には、セット確定処理の開始が遅延する。例えば、ＡＳＰサーバ１０は、終了通知を受信しなかった場合には、端末装置２０において書込処理が終了したことを知り得ないので、書込処理中である場合の動作をするからである。この場合、ＡＳＰサーバ１０が書込処理の結果を取得する時期が遅延するので、それに伴って、セット確定処理の開始も遅延する。
なお、端末装置２０が終了通知や結果通知を送信できない原因は、端末装置２０が通信可能エリア外に居ることに限らない。例えば、端末装置２０において、クーポン管理アプリケーション２６１の実行が強制的に終了させられたこと（クーポン管理アプリケーション２６１の実行が終了させられたことや電源オフ等）や、端末装置２０のバッテリ切れがある。
端末装置２０は、クーポン管理アプリケーション２６１を実行した状態にある場合には、結果通知及び終了通知の送信が完了するまで、結果通知及び終了通知の送信を繰り返し試みる（つまり、リトライする）。一方、ブラウザやクーポン管理アプリケーション２６１が強制終了させられたり、端末装置２０が電源オフされたりした場合には、端末装置２０が通信可能な状態になっても、結果通知及び終了通知を送信しないことがある。よって、ＡＳＰサーバ１０は、クーポン情報を送信してから、一定時間終了通知を受信しない場合には、ステップＳａ１１の処理において、自発的にアプリケーション管理サーバ５０に書込処理の結果の問合せを行う。結果通知についても、端末装置２０からアプリケーション管理サーバ５０に送信されない。よって、アプリケーション管理サーバ５０は、クーポン情報を送信してから、一定時間経過しても結果通知を受け付けなかった場合には、書込処理の結果を不明、又は失敗と自発的に判断する。
ＡＳＰサーバ１０が端末装置２０に電子クーポンを提供しようと際の処理の流れは以上である。以降の処理は、端末装置２０が電子クーポンを利用するときの通信システム１の処理の流れを示す。
端末装置２０がメモリ領域２５１に記憶された電子クーポンを利用しようとするときには、端末装置２０を携帯したユーザは店舗端末４０が設置された店舗に趣いて、リーダ／ライタ４１にこの端末装置２０をかざす。店舗端末４０のリーダ／ライタ４１は、ＩＣチップ２５に記憶された電子クーポンを読み取って、ＩＣチップ２５に対するデータの読み書きを行う。
なお、店舗端末４０は、ＩＣチップ２５に記憶された電子クーポンが利用枚数以上残っているか否かを判断して、決済に反映させる等の処理を実行する。ここでの店舗端末４０の動作は、本発明で特別な構成を有していなくてよい。
店舗管理サーバ３０は、店舗端末４０によるメモリ領域２５１に対するデータの読み書きの結果や決済等の情報に基づいて、端末装置２０により利用された電子クーポンの利用履歴を生成し、ＡＳＰサーバ１０宛てに利用履歴を送信する（ステップＳａ１４）。ここにおいて、店舗管理サーバ３０は、電子クーポンが利用されると直ちに（リアルタイムで）、利用履歴を送信する。
ＡＳＰサーバ１０は、店舗管理サーバ３０から通信により利用履歴を取得すると、その利用履歴に応じて利用時処理を実行する（ステップＳａ１５）。利用時処理は、端末装置２０における電子クーポンの利用に応じて、ＡＳＰサーバ１０が各データテーブルを更新するための処理である。
以降においても、電子クーポンの取得に関する処理や電子クーポンに利用に関する処理が上記同様の手順により実行される。また、通信システム１においては、必ずしも図１０に示す流れで処理が実行されるわけではない。例えば、ＡＳＰサーバ１０がセット開始処理を実行して書込指示を送信した直後に利用履歴を取得した場合には、利用時処理を実行する。また、ＡＳＰサーバ１０は、利用時処理の直後に書込処理の結果通知を受け付けた場合には、セット確定処理を実行する。
ＡＳＰサーバ１０の動作について具体例を用いて詳細に説明する。ここでは、以下の（事象１）から（事象１２）で構成されるストーリに従って、ＡＳＰサーバ１０の動作を説明する。以下の「−」（ハイフン）の左側の時刻は、各事象の発生時刻（ＡＳＰサーバ１０の処理であれば、その開始時刻）であり、「−」の右側は事象の内容を示す。
（事象１）2011/6/29 10:04−電子クーポンＡを５枚提供するためのセット開始処理
（事象２）2011/6/29 10:05−電子クーポンＡのセット確定処理
（事象３）2011/6/29 11:00−電子クーポンＡを３枚利用（１回目）
（事象４）2011/6/29 12:00−電子クーポンＡを１枚利用（２回目）
（事象５）2011/6/29 15:00−電子クーポンＢを１０枚提供するためのセット開始処理
（事象６）2011/6/29 16:00−電子クーポンＡの利用履歴を取得（１回目）
（事象７）2011/6/29 17:00−電子クーポンＢを５枚利用（１回目）
（事象８）2011/6/29 18:00−電子クーポンＢの利用履歴を取得（１回目）
（事象９）2011/6/29 19:00−電子クーポンＢのセット確定処理
（事象１０）2011/6/29 20:00−電子クーポンＢを１枚利用（２回目）
（事象１１）2011/6/29 21:00−電子クーポンＢの利用履歴を取得（２回目）
（事象１２）2011/6/29 22:00−電子クーポンＡの利用履歴を取得（２回目）
（事象１）2011/6/29 10:04−電子クーポンＡを５枚提供するためのセット開始処理
まず（事象１）について説明する。
図１２は、セット開始処理の流れを示すフローチャートである。図１３は、各データテーブルの更新の様子を説明する図である。このセット開始処理前においては、記憶部１３に記憶されている各データテーブルは、図３から図６に示されるデータ構造であるとする。なお、図１３等のデータテーブルの更新の様子を説明する図では、更新により変化したフィールドを太枠で囲んで表すとともに、変化した電子クーポンの枚数を「○」の中に付した数値で表す。
ＡＳＰサーバ１０は、ステップＳａ１の処理で送信されたクーポン取得要求を受信したことを契機に、セット開始処理を開始する。このクーポン取得要求は、電子クーポンＡのクーポンＩＤ「ＣＩＤ００１」と、取得枚数「５」とを含む。
まず、ＡＳＰサーバ１０は、トランザクション管理テーブル１３３を参照して、ステータスが「未確定」の書込処理があるか否かを判断する（ステップＳａ２１）。ここにおいて、ＡＳＰサーバ１０は、書込処理の結果が成功又は失敗のいずれにも確定していない書込処理の存在の有無を判断する。図５に示されるとおり、ステータスが「未確定」の書込処理はないので、ＡＳＰサーバ１０はステップＳａ２１の処理で「ＮＯ」と判断し、ステップＳａ２２の処理に進む。
次に、ＡＳＰサーバ１０は、電子クーポンＡの全体の残枚数、及び個人の残枚数が、それぞれクーポン取得要求に含まれる取得枚数以上であるか否かを判断する（ステップＳａ２２）。ＡＳＰサーバ１０は、クーポン管理テーブル１３１に書き込まれた全体の残枚数、及びユーザ管理テーブル１３２に書き込まれた個人の残枚数のそれぞれと、取得枚数とを比較して、クーポン取得要求に応じて電子クーポンＡを提供できるか否かを判断する。
本実施形態において、全体の残枚数は、下記式（１）の関係を満たす。
全体の残枚数＝全体の制限枚数−Σ｛個人の利用枚数＋ＭＡＸ（セット済未利用枚数，セット未確定枚数）−保留リストテーブル１３４の利用枚数の合計｝ ・・・（１）
ただし、「Σ」は、全端末装置２０（全ユーザ）の総和であることを意味する符号である。ＭＡＸ（Ａ，Ｂ）は、ＡとＢのうち大きい方の値を採ることを意味する。
本実施形態において、個人の残枚数は、下記式（２）の関係を満たす。
個人の残枚数＝個人の制限枚数−個人の利用枚数 ・・・（２）
端末装置２０が設定可能な取得枚数の最大数は、下記式（３）の関係を満たす。
取得枚数の最大数＝ＭＩＮ｛個人の残枚数，全体の残枚数＋ＭＡＸ（セット済未利用枚数，セット未確定枚数）｝ ・・・（３）
ただし、ＭＩＮ（Ａ，Ｂ）は、ＡとＢのうち小さい方の値を採ることを意味する。
図３及び図４に示されるとおり、電子クーポンＡの全体の残枚数は「１０００」であり、個人の残枚数は「１０」であるから、それぞれ取得枚数の「５」を上回っている。よって、ＡＳＰサーバ１０は、ステップＳａ２２の処理で「ＹＥＳ」と判断して、ステップＳａ２３の処理に進む。
次に、ＡＳＰサーバ１０は、これから端末装置２０に指示する書込処理のステータスを「未確定」に設定して、トランザクション管理テーブル１３３を更新する（ステップＳａ２３）。図１３（ａ）に示すように、ＡＳＰサーバ１０は、この書込処理に処理ＩＤ「ＴｓＡ」を割り当てて、ステータス「未確定」と対応付けて、トランザクション管理テーブル１３３に新たに書き込む。このとき、書込完了日時のフィールドはブランクである。
次に、ＡＳＰサーバ１０は、電子クーポンＡの取得枚数をセット未確定枚数に設定するよう、クーポン管理テーブル１３１及びユーザ管理テーブル１３２を更新する（ステップＳａ２４）。図１３（ｂ）に示すように、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００１」の電子クーポンＡについて、全体の残枚数である「１０００」から取得枚数である「５」を減じて、全体の残枚数を「９９５」とするよう、クーポン管理テーブル１３１を更新する。また、ＡＳＰサーバ１０は、電子クーポンＡについて、全体の残枚数から減じた取得枚数である「５」をセット未確定枚数に設定するよう、ユーザ管理テーブル１３２を更新する。
ＡＳＰサーバ１０がステップＳａ２４の処理でセット未確定枚数に設定した取得枚数分の電子クーポンは、未だＩＣチップ２５への書込処理が行われていない電子クーポンであり、書込処理の結果が確定していない電子クーポンである。しかしながら、全体の残枚数から減じられた電子クーポンであるから、この取得枚数分の電子クーポンが他のユーザの端末装置２０に取得されることはない。
なお、ＡＳＰサーバ１０は、ステップＳａ２１の処理でステータスが「未確定」の書込処理があると判断した場合には（ステップＳａ２１；ＹＥＳ）、セット開始処理を終了する。本実施形態では、電子クーポンの枚数管理の説明を簡単にするために、ステータスが未確定の書込処理がある端末装置２０に対しては、ＡＳＰサーバ１０が新たなセット開始処理を行わないようにする。また、ＡＳＰサーバ１０は、ステップＳａ２２の処理において、全体の残枚数、又は個人の残枚数が取得枚数未満であると判断した場合には（ステップＳａ２２；ＮＯ）、セット開始処理を終了する。ＡＳＰサーバ１０は、全体の残枚数及び個人の残枚数のいずれも超えない取得枚数で電子クーポンを提供するから、過剰に電子クーポンを提供することのないよう、ここでセット開始処理を終了する。
（事象２）2011/6/29 10:05−電子クーポンＡのセット確定処理
次に（事象２）について説明する。
図１４及び図１５は、セット確定処理の流れを示すフローチャートである。図１６は、各データテーブルの更新の様子を示す図である。
ここでのセット確定処理の開始前は、保留リストテーブル１３４以外のデータテーブルのデータ構造は、図１３に示されるとおりである。また、このセット確定処理に先立って、ステップＳａ１２の処理に応じてＡＳＰサーバ１０が受け付けた結果通知により、書込完了日時「２０１１／６／２９ １０：０５」に、（事象１）のセット開始処理に応じて指示された書込処理が完了したものとする。ここでは、ＡＳＰサーバ１０は、成功で確定した書込処理を識別する処理ＩＤ「ＴｓＡ」に、ステータス「成功」と、書込完了日時「２０１１／６／２９ １０：０５」とを対応付けて、トランザクション管理テーブル１３３に書き込む（図１６（ａ）参照）。
セット確定処理において、ＡＳＰサーバ１０は、まず、セット確定処理の開始の契機となった書込処理が成功したものであるか否かを判断する（ステップＳａ１３０１）。ここにおいて、ＡＳＰサーバ１０は、書込処理が成功で確定したものと判断すると（ステップＳａ１３０１；ＹＥＳ）、ステップＳａ１３０２の処理に進む。次に、ＡＳＰサーバ１０は、ユーザＩＤ「ＵＩＤ００１」に対応付けられたセット済未利用枚数を全てクリアするよう、ユーザ管理テーブル１３２を更新する（ステップＳａ１３０２）。端末装置２０では上書きにより電子クーポンの書込処理が行われるから、ＡＳＰサーバ１０はメモリ領域２５１に記憶されていた電子クーポンのセット済未利用枚数をクリアして、その電子クーポンの全体の残枚数に加算する（つまり、差し戻す）。ここでは、差し戻す対象となる電子クーポンがないので、ユーザ管理テーブル１３２に特に変化はない。
次に、ＡＳＰサーバ１０は、電子クーポンＡのセット未確定枚数をセット済未利用枚数に設定するとともに、そのセット未確定枚数をクリアするよう、ユーザ管理テーブル１３２を更新する（ステップＳａ１３０３）。図１６（ｂ）に示すように、ＡＳＰサーバ１０は、「５」であるセット未確定枚数をセット済未利用枚数に設定して「５」にするとともに、セット未確定枚数をクリアして「５」から「０」にする。これにより、ＡＳＰサーバ１０は、メモリ領域２５１に書き込まれた電子クーポンＡの枚数と、ユーザ管理テーブル１３２における電子クーポンＡのセット済未利用枚数とを一致（同期）させたことになる。ＡＳＰサーバ１０は、セット開始処理のステップＳａ２４の処理で、提供しようとする枚数の電子クーポンＡが予め（つまり、予約的に）全体の残枚数から減じていたから、ここでは全体の残枚数を変化させることはない。
このように書込処理の成功が確定した電子クーポンＡは、セット開始処理の段階で他のユーザにより取得されないようになっていたため、セット開始処理が実行されたときから、セット確定処理においてセット済未利用枚数に加算されるまでの期間に、他のユーザによりこの電子クーポンＡが取得されることはない。
次に、ＡＳＰサーバ１０は、保留リストテーブル１３４に利用履歴が書き込まれているか否かを判断する（ステップＳａ１３０４）。図６に示されるとおり、ここでは、ＡＳＰサーバ１０は保留リストテーブル１３４に利用履歴が書き込まれていないと判断し（ステップＳａ１３０４；ＮＯ）、セット確定処理を終了する。
なお、ステップＳａ１３０１の処理でＡＳＰサーバ１０が書込処理に失敗したと判断した場合や、保留リストテーブル１３４に利用履歴が書き込まれている場合の動作については、後で説明することとなる。
（事象３）2011/6/29 11:00−電子クーポンＡを３枚利用（１回目）
（事象２）のセット確定処理後、端末装置２０により、「２０１１／６／２９ １１：００」において電子クーポンＡが「３」枚利用されたとする。この利用により、メモリ領域２５１が記憶する電子クーポンＡの残りの枚数は、「５」枚から「２」枚に減じられる。この利用を契機に、本来は、ＡＳＰサーバ１０が店舗管理サーバ３０から利用履歴を直ちに取得するはずである。ただし、ここでは、店舗端末４０や店舗管理サーバ３０の故障やネットワークＮＷにおける通信障害等の何らかの原因により、店舗管理サーバ３０がＡＳＰサーバ１０宛てに利用履歴を送信しなかった場合を想定する。この場合、ユーザ管理テーブル１３２においては、クーポンＡのセット済未利用枚数は「５」のままであるから、ＡＳＰサーバ１０と端末装置２０とにおいて、メモリ領域２５１に記憶されていると把握している電子クーポンＡに「３」枚の差異が存在する。本来は、ユーザ管理テーブル１３２においてセット済未利用枚数は「２」となるべきである。しかしながら、利用履歴によるユーザ管理テーブル１３２の更新がＡＳＰサーバ１０で行われていないので、セット済未利用枚数は「５」のままである。
（事象４）2011/6/29 12:00−電子クーポンＡを１枚利用（２回目）
（事象３）の後、端末装置２０により、「２０１１／６／２９ １２：００」において電子クーポンＡが「１」枚利用されたとする。この利用により、メモリ領域２５１が記憶する電子クーポンＡの残りの枚数は、「２」枚から「１」枚に減じられる。ここでも、店舗管理サーバ３０がＡＳＰサーバ１０宛てに利用履歴を送信しなかった場合を想定する。この場合、ユーザ管理テーブル１３２においては、クーポンＡのセット済未利用枚数は「５」のままであるから、ＡＳＰサーバ１０と端末装置２０とにおいて、メモリ領域２５１に記憶されていると把握している電子クーポンＡに「４」枚の差異が存在する。本来は、ユーザ管理テーブル１３２においてセット済未利用枚数は「１」となるべきである。しかしながら、利用履歴によるユーザ管理テーブル１３２の更新がＡＳＰサーバ１０で行われていないので、セット済未利用枚数は未だ「５」のままである。
（事象５）2011/6/29 15:00−電子クーポンＢを１０枚提供するためのセット開始処理
次に（事象５）を説明する。
電子クーポンＢを１０枚提供するためのセット開始処理においても、その処理の流れは、上述した（事象１）で説明した内容と基本的に同じである。よって、ここでのセット開始処理については、図１２を参照しつつ適宜省略しながら処理の流れを説明する。図１７は、各データテーブルの更新の様子を示す図である。ＡＳＰサーバ１０は、ステップＳａ１の処理で送信されたクーポン取得要求を受信したことを契機に、セット開始処理を開始する。このクーポン取得要求は、電子クーポンＢのクーポンＩＤとして「ＣＩＤ００２」と、取得枚数として「１０」とを含む。
ＡＳＰサーバ１０は、クーポン取得要求を受信すると、トランザクション管理テーブル１３３を参照して、ステータスが未確定の書込処理があるか否かを判断する（ステップＳａ２１）。図１６（ａ）に示されるとおり、ここではステータス「未確定」の書込処理がない。よって、ＡＳＰサーバ１０は、ステップＳａ２１の処理で「ＮＯ」と判断して、ステップＳａ２２の処理に進む。
次に、ＡＳＰサーバ１０は、電子クーポンＢの全体の残枚数、及び個人の残枚数がそれぞれ、取得枚数以上であるか否かを判断する（ステップＳａ２２）。図１３（ｂ）に示されるとおり、全体の残枚数が「５０００」であり、個人の残枚数が「２５」であるのに対し、取得枚数は「１０」である。よって、ＡＳＰサーバ１０は、ステップＳａ２２の処理で「ＹＥＳ」と判断して、ステップＳａ２３の処理に進む。
次に、ＡＳＰサーバ１０は、これから指示する書込処理のステータスを「未確定」に設定して、トランザクション管理テーブル１３３を更新する（ステップＳａ２３）。ここにおいて、ＡＳＰサーバ１０は、図１７（ａ）に示すように、処理ＩＤ「ＴｓＢ」を割り当てて、ステータス「未確定」と対応付けて、トランザクション管理テーブル１３３に新たに書き込む。
次に、ＡＳＰサーバ１０は、電子クーポンＢの取得枚数をセット未確定枚数に設定するよう、クーポン管理テーブル１３１及びユーザ管理テーブル１３２を更新する（ステップＳａ２４）。図１７（ｂ）に示すように、ＡＳＰサーバ１０は、クーポンＩＤが「ＣＩＤ００２」である電子クーポンＢについて、全体の残枚数を「５０００」から取得枚数の「１０」だけ減じて、「４９９０」とする。また、ＡＳＰサーバ１０は、全体の残枚数から減じた取得枚数である「１０」をセット未確定枚数に設定して、セット未確定枚数を「１０」にする。
ここでのセット開始処理は以上である。
（事象６）2011/6/29 16:00−電子クーポンＡの利用履歴を取得（１回目）
次に（事象６）を説明する。
図１８は、利用時処理の流れを示すフローチャートである。図１９は、各データテーブルの更新の様子を示す図である。
ＡＳＰサーバ１０は、「２０１１／６／２９ １６：００」に、（事象３）で利用された電子クーポンＡの利用履歴を店舗管理サーバ３０から取得したことを契機に、利用時処理を実行する。利用時処理が本来よりも遅れて開始される例としては、この時刻に店舗管理サーバ３０が復旧したり、ネットワークＮＷの障害が解消したりしたこと等が考えられる。ここにおいて、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００１」、利用日時「２０１１／６／２９ １１：００」、及び利用枚数「３」を含む利用履歴を取得する。
まず、ＡＳＰサーバ１０は、トランザクション管理テーブル１３３を参照して、ステータスが「未確定」の書込処理があるか否かを判断する（ステップＳａ１５１）。図１７（ａ）に示すように、ここでは、処理ＩＤ「ＴｓＢ」の書込処理の結果（ステータス）が未確定である。よって、ＡＳＰサーバ１０は、ステップＳａ１５１の処理で「ＹＥＳ」と判断し、ステップＳａ１５２の処理に進む。
次に、ＡＳＰサーバ１０は、店舗管理サーバ３０から取得した利用履歴に含まれる利用日時と、トランザクション管理テーブル１３３における最新の書込完了日時とを比較し、利用日時が最新の書込完了日時よりも後であるか否かを判断する（ステップＳａ１５２）。図１７（ａ）に示すように、ここでの最新の書込完了日時は「２０１１／６／２９ １０：０５」である。よって、ＡＳＰサーバ１０は、ステップＳａ１５２の処理で「ＹＥＳ」と判断し、ステップＳａ１５３の処理に進む。そして、ＡＳＰサーバ１０は、利用履歴によるセット済未利用枚数の更新を保留して（つまり、更新しないで）、この利用履歴を保留リストテーブル１３４に書き込む（ステップＳａ１５３）。
ステップＳａ３の処理では、ＡＳＰサーバ１０は、ステータスが未確定の書込処理が存在し、書込処理の結果の確定の遅延と、利用履歴の取得の遅延という、双方の遅延を原因として電子クーポンＡに関する情報を誤って管理をしないよう、利用履歴に基づく処理を一旦保留している。具体的には、ＡＳＰサーバ１０は、利用履歴を遅延して取得した場合にステータスが「未確定」の書込処理が残っているときには、その書込処理の結果が確定するまでは、メモリ領域２５１において電子クーポンＡに関する情報が書き換わった時刻が不明である。よって、ＡＳＰサーバ１０にしてみれば、取得した利用履歴が、その書込処理によって書き込まれた電子クーポンＡから利用されたものなのか、それ以前に記憶されていた電子クーポンＡの利用履歴が遅れて送信されたのかを、この時点で正確に判断することはできない。この理由により、ＡＳＰサーバ１０は、この判断を正確にできるようになるまで利用履歴に基づく処理を保留するわけである。ステップＳａ１５３の処理後の保留リストテーブル１３４は、図１９（ａ）に示されるとおりである。
次に、ＡＳＰサーバ１０は、個人の残枚数からステップＳａ１５３の処理で保留させた利用履歴の利用枚数を減じるとともに、利用履歴の利用枚数を個人の利用枚数に加算する（ステップＳａ１５４）。図１９（ｂ）に示すように、ここでは、ＡＳＰサーバ１０は、個人の利用枚数に「３」を加算して「０」から「３」にするとともに、個人の残枚数「１０」から「３」を減じて「７」にするよう、ユーザ管理テーブル１３２を更新する。
以上のＡＳＰサーバ１０の処理により、（事象３）における利用履歴の取得の遅延と、電子クーポンＢの書込処理の結果の確定の遅延とを原因とした電子クーポンＢの他のユーザによる重複取得は回避される。
なお、ステップＳａ１５１の処理で、ＡＳＰサーバ１０がステータスが未確定の書込処理がないと判断した場合の動作については、後で説明することとなる。
（事象７）2011/6/29 17:00−電子クーポンＢを５枚利用（１回目）
（事象６）の利用時処理の実行後、端末装置２０により、「２０１１／６／２９ １７：００」において電子クーポンＢが「５」枚利用されたとする。この利用により、メモリ領域２５１が記憶する電子クーポンＢの残り枚数は、「１０」から「５」に減じられる。ここでも、店舗管理サーバ３０がＡＳＰサーバ１０宛てに利用履歴を送信しなかった場合を想定する。この場合、ユーザ管理テーブル１３２においては、クーポンＢのセット済未利用枚数が「０」のままであるから、ＡＳＰサーバ１０と端末装置２０とにおいて、メモリ領域２５１に記憶されていると把握している電子クーポンＢに「５」枚の差異が存在する。本来は、ユーザ管理テーブル１３２においてセット済未利用枚数は「５」となるべきである。しかしながら、利用履歴によるユーザ管理テーブル１３２の更新がＡＳＰサーバ１０で行われていないので、セット済未利用枚数は「０」のままである。
（事象８）2011/6/29 18:00−電子クーポンＢの利用履歴を取得（１回目）
次に（事象８）を説明する。ここでの利用時処理の流れは、上述した（事象６）で説明した内容と基本的に同じであるから、図１８を参照しつつ適宜簡略化して説明する。図２０は、各データテーブルの更新の様子を示す図である。ここでは、ＡＳＰサーバ１０が、「２０１１／６／２９ １８：００」に、（事象７）で利用された電子クーポンＢの利用履歴を基に利用時処理を実行する。ここにおいて、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００２」、利用日時「２０１１／６／２９ １７：００」及び利用枚数「５」という利用履歴を取得することとなる。
まず、ＡＳＰサーバ１０は、ステータスが未確定の書込処理があるか否かを判断する（ステップＳａ１５１）。ここでは、図１７（ａ）に示すように、処理ＩＤ「ＴｓＢ」の書込処理のステータスが「未確定」である。よって、ＡＳＰサーバ１０は、ステップＳａ１５１の処理で「ＹＥＳ」と判断して、ステップＳａ１５２の処理に進む。次に、ＡＳＰサーバ１０は、トランザクション管理テーブル１３３を参照して、店舗管理サーバ３０から取得した利用履歴に含まれる利用日時が最新の書込完了日時よりも後であるか否かを判断する（ステップＳａ１５２）。ここでは、ＡＳＰサーバ１０は、最新の書込完了日時が「２０１１／６／２９ １０：０５」であるから、ステップＳａ１５２の処理で「ＹＥＳ」と判断し、利用履歴を保留リストテーブル１３４に書き込む（ステップＳａ１５３）。ステップＳａ１５３の処理後の保留リストテーブル１３４は、図２０（ａ）に示されるとおりである。
次に、ＡＳＰサーバ１０は、個人の残枚数から利用履歴の利用枚数を減じ、更に、利用履歴の利用枚数を個人の利用枚数に加算する（ステップＳａ１５４）。図２０（ｂ）に示すように、ＡＳＰサーバ１０は、個人の残枚数「２５」から「５」を減じて「２０」にするとともに、個人の利用枚数に「５」を加算して「０」から「５」にする。
以上のＡＳＰサーバ１０の処理により、電子クーポンＢの書込処理の結果の確定の遅延を原因とした、電子クーポンＢの重複取得が回避される。
ここでの利用時処理は以上である。
（事象９）2011/6/29 19:00−電子クーポンＢのセット確定処理
次に（事象９）を説明する。セット確定処理の手順については図１４を参照して説明する。図２１は、各データテーブルの更新の様子を示す図である。
以下に説明するセット確定処理の開始時はテーブルのデータ構造は、図２０に示されるものである。このセット確定処理に先立って、ステップＳａ１２の処理に応じてＡＳＰサーバ１０が受け付けた結果通知により、書込完了日時「２０１１／６／２９ １５：０１」に書込処理が完了したとする。この場合、ＡＳＰサーバ１０は、成功が確定した書込処理を識別する処理ＩＤ「ＴｓＢ」に、ステータス「成功」と、書込完了日時「２０１１／６／２９ １５：０１」とを対応付けて、トランザクション管理テーブル１３３に書き込む（図２１（ａ）参照）。
まず、ＡＳＰサーバ１０は、セット確定処理の開始の契機となった書込処理が成功したものであるか否かを判断する（ステップＳａ１３０１）。ＡＳＰサーバ１０は、書込処理が成功で確定したと判断すると（ステップＳａ１３０１；ＹＥＳ）、ステップＳａ１３０２の処理に進む。次に、ＡＳＰサーバ１０は、ユーザＩＤ「ＵＩＤ００１」に対応付けられた各電子クーポンのセット済未利用枚数を全てクリアして、それぞれ全体の残枚数に加算することによりセット済未利用枚数を差し戻す（ステップＳａ１３０２）。ここにおいて、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００１」の電子クーポンＡのセット済未利用枚数である「５」を全体の残枚数に差し戻して、全体の残枚数を「１０００」とする。一方、クーポンＩＤ「ＣＩＤ００２」の電子クーポンＢのセット済未利用枚数は「０」であるから、全体の残枚数はここでは「４９９０」のままである。
次に、ＡＳＰサーバ１０は、電子クーポンＢのセット未確定枚数をセット済未利用枚数に設定するとともに、そのセット未確定枚数をクリアするよう、ユーザ管理テーブル１３２を更新する（ステップＳａ１３０３）。図２１（ｂ）に示すように、ここでは、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００２」の電子クーポンＢについて、セット未確定枚数である「１０」をセット済未利用枚数に設定して「１０」にするとともに、このセット未確定枚数をクリアして「１０」から「０」にする。
次に、ＡＳＰサーバ１０は、保留リストテーブル１３４に利用履歴が書き込まれているか否かを判断する（ステップＳａ１３０４）。図２０（ａ）に示されるとおり、ＡＳＰサーバ１０は保留リストテーブル１３４に利用履歴が書き込まれていると判断し（ステップＳａ１３０４；ＹＥＳ）、ステップＳａ１３０５の処理に進む。
次に、ＡＳＰサーバ１０は、保留リストテーブル１３４から利用履歴を１件抽出する（ステップＳａ１３０５）。ここでは、ＡＳＰサーバ１０は、利用日時が最も後である利用履歴を抽出するが、いずれを抽出しても構わない。次に、ＡＳＰサーバ１０は、抽出した利用履歴の利用日時が最新の書込完了日時よりも後であるか否かを判断する（ステップＳａ１３０６）。ここにおいて、クーポンＩＤ「ＣＩＤ００２」、利用日時「２０１１／６／２９ １７：００」及び利用枚数「５」という利用履歴に対し、最新の書込完了日時が「２０１１／６／２９ １５：０１」である。よって、ＡＳＰサーバ１０は利用日時の方が後と判断し（ステップＳａ１３０６；ＹＥＳ）、抽出した利用履歴の利用枚数をセット済未利用枚数から減じる（ステップＳａ１３０７）。図２１（ｃ）に示すように、ここでは、ＡＳＰサーバ１０は、セット済未利用枚数「１０」から利用枚数「５」を減じて、セット済未利用枚数を「５」に設定する。そして、ＡＳＰサーバ１０は、ステップＳａ１３０５の処理で抽出した利用履歴を、保留リストテーブル１３４から削除する（ステップＳａ１３０８）。
次に、ＡＳＰサーバ１０は、保留リストテーブル１３４に利用履歴が残っているか否かを判断する（ステップＳａ１３０９）。ここで、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００１」の利用履歴が残っているので、ステップＳａ１３０９の処理で「ＹＥＳ」と判断し、ステップＳａ１３０５の処理に戻る。次に、ＡＳＰサーバ１０は、保留リストテーブル１３４から利用履歴を１件抽出する（ステップＳａ１３０５）。ＡＳＰサーバ１０は、抽出した利用履歴の利用日時が最新の書込完了日時よりも後であるか否かを判断する（ステップＳａ１３０６）。ここにおいて、クーポンＩＤ「ＣＩＤ００１」、利用日時「２０１１／６／２９ １１：００」及び利用枚数「３」という利用履歴に対し、最新の書込完了日時は「２０１１／６／２９ １５：０１」である。ＡＳＰサーバ１０は、利用日時の方が前と判断した場合（ステップＳａ１３０６；ＮＯ）、この利用履歴利用枚数を全体の残枚数から減じてから削除する（ステップＳａ１３０８）。ここでは、ＡＳＰサーバ１０は、電子クーポンＡについて、保留リストテーブル１３４に含まれる利用枚数である「３」を、電子クーポンＡの全体の残枚数である「１０００」から減じて「９９７」としてから、保留リストテーブル１３４から抽出した利用履歴を削除する（ステップＳａ１３０８）。
このステップＳａ１３０８の処理で、ＡＳＰサーバ１０が保留リストテーブル１３４に含まれる利用枚数を全体の残枚数から減じた理由を説明する。保留リストテーブル１３４に利用履歴が書き込まれていたということは、実際にはこの利用履歴から特定される利用枚数分の電子クーポンは既に利用されたものの、ステップＳａ１３０６の処理で「ＮＯ」と判断された場合には、この利用枚数が未だセット済未利用枚数からは減じられていないことになる。よって、セット済未利用枚数がそのまま全体の残枚数に差し戻されてしまうと、この利用枚数分が過剰に差し戻されて、この利用枚数分の電子クーポンが他のユーザにより重複取得されるおそれがある。この理由から、ＡＳＰサーバ１０は、保留リストテーブル１３４の利用履歴に含まれる利用枚数である「３」を全体の残枚数である「１０００」から減じて、「９９７」としている。図２１（ｄ）に示すように、この減算により、ＡＳＰサーバ１０は、結果的に、電子クーポンＡのセット済未利用枚数であった「５」から、保留リストテーブル１３４の利用履歴に含まれる利用枚数である「２」を減じた枚数分である「２」だけ、電子クーポンＡの全体の残枚数に差し戻したことになる。
ＡＳＰサーバ１０は、保留リストテーブル１３４に利用履歴が残っていないと判断すると（ステップＳａ１３０９；ＮＯ）、利用時処理を終了する。
以上の処理により、（事象３）の利用後のセット済未利用枚数が、ＡＳＰサーバ１０において正しく反映されたことになる。
（事象１０）2011/6/29 20:00−電子クーポンＢを１枚利用（２回目）
（事象９）のセット確定処理の後、端末装置２０により、「２０１１／６／２９ ２０：００」において電子クーポンＢが「１」枚利用されたとする。この利用により、メモリ領域２５１が記憶する電子クーポンＢの残り枚数は、「５」から「４」に減じられる。この時点では、ユーザ管理テーブル１３２においては、クーポンＢのセット済未利用枚数は「５」のままであるから、ＡＳＰサーバ１０と端末装置２０とにおいて、メモリ領域２５１に記憶されていると把握している電子クーポンＢに「１」枚の差異が存在する。
（事象１１）2011/6/29 21:00−電子クーポンＢの利用履歴を取得（２回目）
次に（事象１１）を説明する。ここでは、ＡＳＰサーバ１０が、「２０１１／６／２９ ２１：００」に、（事象１０）の電子クーポンの利用履歴を取得した場合の利用時処理を、図１８を参照しつつ説明する。図２２は、各データテーブルの更新の様子を示す図である。ここにおいて、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００２」、利用日時「２０１１／６／２９ ２０：００」及び利用枚数「１」という利用履歴を取得することとなる。
まず、ＡＳＰサーバ１０は、トランザクション管理テーブル１３３を参照して、ステータスが「未確定」の書込処理があるか否かを判断する（ステップＳａ１５１）。図２１（ａ）に示すように、ＡＳＰサーバ１０は、ステータスが未確定の書込処理がないと判断して（ステップＳａ１５１；ＮＯ）、ステップＳａ１５５の処理に進む。
そして、ＡＳＰサーバ１０は、店舗管理サーバ３０から取得した利用履歴に含まれる利用日時が最新の書込完了日時よりも後であるか否かを判断する（ステップＳａ１５５）。図２１（ａ）に示すように、ここでは、最新の書込完了日時が「２０１／６／２９ １５：０１」である。よって、ＡＳＰサーバ１０は、ステップＳａ１５５の処理で「ＹＥＳ」と判断し、個人の残枚数及びセット済未利用枚数のそれぞれから、利用履歴に含まれる利用枚数を減じる（ステップＳａ１５６）。図２２に示すように、ここでは、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００２」の電子クーポンＢについて、個人の残枚数を「２０」から「１」だけ減らして「１９」とし、セット済未利用枚数を「５」から「１」だけ減らして「４」とする。そして、ＡＳＰサーバ１０は、個人の利用枚数である「５」に利用枚数である「１」を加算し、個人の利用枚数を「６」とする（ステップＳａ１５７）。
以上の処理により、（事象１１）の電子クーポンＢの利用を原因とした、電子クーポンＢの重複取得が回避される。
（事象１２）2011/6/29 22:00−電子クーポンＡの利用履歴を取得（２回目）
次に（事象１２）を説明する。ここでは、ＡＳＰサーバ１０が、「２０１１／６／２９ ２２：００」に、（事象４）での電子クーポンＡの利用履歴を店舗管理サーバ３０から取得した際の利用時処理を説明する。ＡＳＰサーバ１０は、（事象４）の実行時に取得すべきであった利用履歴を取得して、利用時処理を実行する。ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００１」、利用日時「２０１１／６／２９ １２：００」及び利用枚数「１」という利用履歴を取得することとなる。
利用時処理については図１８を参照しつつ説明する。図２３は、各データテーブルの更新の様子を示す図である。ＡＳＰサーバ１０は、ステータスが「未確定」の書込処理があるか否かを判断する（ステップＳａ１５１）。ここにおいて、ＡＳＰサーバ１０は、図２１（ａ）に示すように、ステータスが未確定の書込処理がないと判断すると（ステップＳａ１５１；ＮＯ）、店舗管理サーバ３０から取得した利用履歴に含まれる利用日時が最新の書込完了日時よりも後であるか否かを判断する（ステップＳａ１５５）。図２１（ａ）に示すとおり、トランザクション管理テーブル１３３を参照して、最新の書込完了日時が「２０１／６／２９ １５：０１」であるから、ＡＳＰサーバ１０はステップＳａ１５５の処理で「ＮＯ」と判断する。そして、ＡＳＰサーバ１０は、個人の利用枚数に利用履歴における利用枚数を加算する（ステップＳａ１５７）。図２３（ａ）に示すように、ここにおいて、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００１」の電子クーポンＡについて、個人の利用枚数を「３」から「４」にするよう「１」だけ加算し、個人の残枚数「７」から「１」だけ減らした「６」とし、全体の残枚数「９９７」から「１」だけ減らして「９９６」とする。
この処理によって、（事象９）において実際には利用されていたにも関わらず、全体の残枚数に過剰に差し戻されていた「１」枚分の電子クーポンＡが、全体の残枚数から減じらされて全体の残枚数の誤りがここで解消される。
なお、上述したセット確定処理において、ＡＳＰサーバ１０がステップＳａ１３０１の処理で書込処理に失敗したと判定した場合も（図１４のステップＳａ１３０１で「ＮＯ」）、基本的には成功した場合と同じように動作する。具体的には以下のとおりである。
ＡＳＰサーバ１０は、保留リストテーブル１３４に利用履歴が書き込まれているか否かを判断する（ステップＳａ１３１０）。ここにおいて、ＡＳＰサーバ１０は、保留リストテーブル１３４に利用履歴が書き込まれていると判断すると（ステップＳａ１３１０；ＹＥＳ）、保留リストテーブル１３４から利用履歴を１件抽出する（ステップＳａ１３１１）。次に、ＡＳＰサーバ１０は、抽出した利用履歴の利用日時が前回の書込処理であって最新の書込処理の書込完了日時よりも後か否かを判断する（ステップＳａ１３１２）。ＡＳＰサーバ１０は、利用日時の方が後と判断すると（ステップＳａ１３１２；ＹＥＳ）、抽出した利用履歴の利用枚数をセット済未利用枚数から減じる（ステップＳａ１３１３）。そして、ＡＳＰサーバ１０は、抽出した利用履歴を保留リストテーブル１３４から削除し（ステップＳａ１３１４）、保留リストテーブル１３４に利用履歴が残っているか否かを判断する（ステップＳａ１３１５）。ＡＳＰサーバ１０は、利用履歴が残っていると判断すると（ステップＳａ１３１５；ＹＥＳ）、ステップＳａ１３１１の処理に戻る。一方、ＡＳＰサーバ１０は、保留リストテーブル１３４に利用履歴が残っていないと判断すると、セット未確定枚数をクリアして（ステップＳａ１３１６）、セット確定処理を終了する。ステップＳａ１３１６の処理において、セット未確定枚数がセット済未利用枚数より多い場合には、ＡＳＰサーバ１０は、セット未確定枚数とセット済未利用枚数との差分を全体の残枚数に加算する。
ところで、ＡＳＰサーバ１０は、ステップＳａ１３１２の処理で抽出した利用履歴の利用日時が前回の書込処理であって最新の書込完了日時よりも前と判断すると（ステップＳａ１３１２；ＮＯ）、抽出した利用履歴を保留リストテーブル１３４から削除する（ステップＳａ１３１４）。また、ＡＳＰサーバ１０は、ステップＳａ１３１０の処理で保留リストテーブル１３４に利用履歴が書き込まれていないと判断すると（ステップＳａ１３１０；ＮＯ）、ステップＳａ１３１６の処理を実行してからセット確定処理を終了する。
以上のように、ＡＳＰサーバ１０は、書込処理の結果が失敗の場合であっても、ステップＳａ１３１６の処理で、セット未確定枚数を全体の残枚数に加算してこのセット未確定枚数をクリアする処理を実行する点を除き、書込処理に成功した場合と同じように動作すればよい。
以上が、上記ストーリにおいてＡＳＰサーバ１０が実行する処理の説明である。
以上説明した実施形態によれば、電子クーポンの管理に関して以下のような作用効果を奏する。
第１に、ＡＳＰサーバ１０におけるクーポン提供時の処理を原因として、電子クーポンが他のユーザにより重複取得されないようにすることができる。セット開始処理において、ＡＳＰサーバ１０は、電子クーポンを端末装置２０に新たに提供する場合、全体の残枚数から減じた枚数をセット未確定枚数に設定してから、このセット未確定枚数の電子クーポンについての書込処理を端末装置２０に指示する。そして、ＡＳＰサーバ１０は、端末装置２０により実行された書込処理の成功が確定した後、セット未確定枚数をセット済未利用枚数に設定する。これにより、書込処理の成功後に、全体の残枚数から減じた取得枚数をセット済未利用枚数に直接設定した場合に生じうる、電子クーポンの重複取得を回避できる。更に、ＡＳＰサーバ１０は、書込処理がメモリ領域２５１の電子クーポンに新しい電子クーポンを上書きする処理であった場合には、セット未確定枚数がセット済未利用枚数より多いときに、セット未確定枚数とセット済未利用枚数との差分を全体の残枚数に加算する（差し戻す）。これにより、書込処理前に全体の残枚数から減じた取得枚数をセット済未利用枚数に直接設定したした場合に生じうる、電子クーポンの重複取得を回避できる。具体的には、ＡＳＰサーバ１０が上書きによる書込処理を行って既に記憶されていた電子クーポンが削除されようとした場合に、この書込処理の失敗を原因として、メモリ領域２５１にこの電子クーポンが残ってしまったときであっても、この電子クーポンが重複取得されるのを防ぐことができる。
第２に、ＡＳＰサーバ１０における電子クーポンの利用時の処理を原因として電子クーポンが他のユーザにより重複取得されないようにすることができる。ＡＳＰサーバ１０は、書込処理の成功が確定した場合にはその書込完了日時を記憶する。そして、ＡＳＰサーバ１０は、端末装置２０が電子クーポンを利用して利用履歴を取得すると、利用履歴に含まれる利用日時と最新の書込完了日時とを比較する。そして、ＡＳＰサーバ１０は、利用日時が最新の書込完了日時よりも後である場合、セット済未利用枚数から利用枚数を減じる一方、利用日時が最新の書込完了日時よりも前である場合、セット済未利用枚数から利用枚数を減じない。このように、ＡＳＰサーバ１０は、過去にメモリ領域２５１に記憶されていた電子クーポンに対応したセット済未利用枚数からは、利用履歴による利用枚数が減じない。これにより、（事象９）でも説明したように、ＡＳＰサーバ１０が電子クーポンを差し戻す際に、実際には利用されていた電子クーポンに相当し利用履歴に含まれている利用枚数分を減じておけば、この利用枚数分の電子クーポンがセット確定処理によって差し戻されて他のユーザに重複取得されてしまうのを防ぐことができる。
第３に、ＡＳＰサーバ１０は、第２の場合において、利用日時が最新の書込完了日時よりも後である場合に、結果が未確定である書込処理が存在するときには、セット済未利用枚数の更新を保留して利用履歴を記憶させる。そして、ＡＳＰサーバ１０は、結果が未確定であった書込処理の結果が確定した後、記憶しておいた利用履歴に含まれる利用日時が最新の書込完了日時よりも後である場合、セット済未利用枚数から利用枚数を減じる一方、利用日時が最新の書込完了日時よりも前である場合、セット済未利用枚数から利用枚数を減じない。これにより、結果通知の遅延により、ＡＳＰサーバ１０が書込処理の結果を確定させるのが遅れたとしても、書込処理の結果が確定してから利用履歴に基づく処理を行うので、セット確定処理によって電子クーポンが過剰に差し戻されて、この差し戻された電子クーポンが他のユーザに重複取得されるのを防ぐことができる。
更には、通信システム１において、ＡＳＰサーバ１０とアプリケーション管理サーバ５０とは独立したサーバ装置で実現されていて、クーポン管理アプリケーション２６１はＡＳＰサーバ１０がないと動作しないようになっている。これは、端末装置２０において、クーポン管理アプリケーション２６１が不正に利用されることを防ぐ目的としていることにもよる。具体的には、ＡＳＰサーバ１０がアプリケーション管理サーバ５０に対し署名通信で処理依頼を行った場合にしか、端末装置２０ではＩＣチップ２５に電子クーポンが書き込まれないようになっているから、クーポン管理アプリケーション２６１の不正利用を防ぐことができる。
２．第１実施形態の変形例
本発明は、上述した実施形態と異なる形態で実施することが可能である。本発明は、例えば、以下のような形態で実施することも可能である。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
［変形例１］
上述した実施形態の通信システム１では、電子クーポンの提供又は利用可能な最小単位を「枚」とし、提供又は利用される電子クーポンの数（単位数）を「枚数」とした電子クーポンを扱っていた。これに対し、電子クーポンの提供又は利用可能な最小単位となる数（すう）はこれに限らず、例えば、電子クーポンの提供又は利用可能な最小単位を「円」や「ドル」等の貨幣の単位としてもよい。この場合であっても、上述した実施形態の電子クーポンの「枚数」を、「円」や「ドル」等の貨幣の単位に置き換えればよいだけである。また、電子クーポンの提供又は利用可能な最小単位となる数は、「ポイント」（点）や「回数」（利用回数）等であってもよい。
［変形例２］
上述した実施形態において、ＡＳＰサーバ１０は、電子クーポンの提供時に関するセット開始処理及びセット確定処理と、電子クーポンの利用時に関する利用時処理との双方を実行していたが、それぞれ別のサーバ装置（ＡＳＰサーバ）が実行してもよい。この場合、セット開始処理及びセット確定処理を実行する側のＡＳＰサーバは、図９に示す機能を実現する必要がない。また、通信システム１において、書込処理の結果通知が遅延しない環境（又は、遅延がほとんどない環境）にある場合には、ＡＳＰサーバ１０が保留リストテーブル１３４に基づく処理を実行しないように、通信システム１を構成することも考えられる。この場合、上述した実施形態における全体の残枚数は、下記式（４）に置き換えられる。個人の残枚数については変化はない。
全体の残枚数＝全体の制限枚数−Σ｛個人の利用枚数＋ＭＡＸ（セット済未利用枚数，セット未確定枚数）｝ ・・・（４）
また、全体の残枚数は上述した式（１）又は式（４）の関係を満たし、個人の残枚数は上述した式（２）の関係を満たすものである。たとえ、ＡＳＰサーバ１０が各式の左辺に相当する全体の残枚数及び個人の残枚数そのものを記憶していなくとも、例えば右辺に相当するデータを記憶していれば、実質的に全体の残枚数や個人の残枚数を記憶していることに等しい。
［変形例３］
上述した実施形態では、ＡＳＰサーバ１０は、電子クーポンの利用があると直ちに、店舗管理サーバ３０から利用履歴を取得していた。これに対し、ＡＳＰサーバ１０は、予め決められた期間毎、又は予め決められた取得時期が到来したことを契機に、店舗管理サーバ３０から利用履歴を取得してもよい。この場合、ＡＳＰサーバ１０が利用履歴を取得する日時が電子クーポンの利用日時から或る程度遅延するが、ＡＳＰサーバ１０が上述した利用時処理を実行することにより、利用履歴の取得の遅延による重複取得は避けられる。
［変形例４］
上述した実施形態において、クーポン管理テーブル１３１及びユーザ管理テーブル１３２に相当するデータテーブルがサービス提供者ごとに独立していてよい。その理由について説明する。
あるサービス提供者Ａの電子クーポンａが端末装置２０のＩＣチップ２５に書き込まれていて、別のサービス提供者Ｂの電子クーポンｂがＩＣチップ２５に、クーポンａへの上書きにより書込処理が行われると、ＩＣチップ２５ではサービス提供者Ａの電子クーポンａが削除させられる。しかしながら、ＡＳＰサーバでは、この書込処理に応じてサービス提供者Ａの電子クーポンａのセット済未利用枚数を全体の残枚数に加算してセット済未利用枚数をクリアする、という電子クーポンの差し戻しを行うことができない。これにより、ＡＳＰサーバでは、ＩＣチップ２５から削除させられた電子クーポンがセット済未利用枚数として残留したままとなる。しかしながら、次にこの端末装置２０がサービス提供者Ａの電子クーポンの書込処理を実行する際には、ＡＳＰサーバで残留していた電子クーポンａのセット済未利用枚数が全体の残枚数に加算されてセット済未利用枚数がクリアされるから、特に問題は生じない。この場合、ＡＳＰサーバにおいては電子クーポンａのセット済未利用枚数がクリアされるまでは、この電子クーポンａがＩＣチップ２５に記憶されていないにも関わらず、セット済未利用枚数として残留するので、誰にも取得することのできない電子クーポンとなる。
以上のような理由により、サービス提供者毎にＡＳＰサーバを分けた構成としても共通のデータテーブルを参照する必要がない。また、サービス提供者Ｂの電子クーポンがＩＣチップ２５に書き込まれたことにより、サービス提供者Ａの電子クーポンが差し戻されるという、サービス提供者をまたがって連携される事象の発生を回避することできる。異なるサービス提供者（企業等）が同一のシステム（仕組み）を共用していることを一般ユーザに隠すことができる点で、ユーザの混乱回避や企業のブランディングの観点からも好ましい。
［変形例５］
上述した実施形態を以下のように変形することも可能である。
本変形例の前提として、ここでは、以下の（前提１）及び（前提２）を採用する。
（前提１）ユーザ管理テーブル１３２において「セット未確定枚数」に相当する情報が書き込まれないようにするとともに、ＡＳＰサーバ１０はセット未確定枚数に関わる処理を実行しない。
（前提２）クーポン管理テーブル１３１においては、「残枚数（全体）」に代えて「配布枚数（全体）」に相当する情報が書き込まれるようにする。配布枚数（全体）は、端末装置２０の全体に対して配布（つまり、提供）された電子クーポンの配布数（以下、「全体の配布枚数」ということがある。）であり、下記式（５）の関係を満たす。
残枚数（全体）＝制限枚数（全体）−配布枚数（全体） ・・・（５）
次に、本変形例のＡＳＰサーバ１０の機能的構成を上述した実施形態との相違点を中心に説明する。
第１更新部１１１は、第１電子クーポンを取得するためのクーポン取得要求を通信部１２による端末装置２０との通信により取得したことを契機に、第１電子クーポンを端末装置２０に新たに提供するための処理を開始する。第１に、第１更新部１１１は、クーポン取得要求で指定された第１電子クーポンの取得枚数を、クーポン管理テーブル１３１の全体の配布枚数に加算する。ただし、第１更新部１１１は、書込処理前においてユーザ管理テーブル１３２に書き込まれている第１電子クーポンのセット済未利用枚数を超える枚数のみを、全体の配布枚数に加算する。すなわち、第１更新部１１１は、第１電子クーポンがメモリ領域２５１に既に記憶されているときには、同じ第１電子クーポンについて上書きによる書込処理を実行させることになるから、取得枚数から書込処理前のセット済未利用枚数を減じた枚数を、全体の配布枚数に追加して加算することとなる。
第２に、第１更新部１１１は、クーポン取得要求で指定された第１電子クーポンの取得枚数を第１電子クーポンのセット済未利用枚数に加算する。ここにおいて、第１更新部１１１は、書込処理前においてユーザ管理テーブル１３２に書き込まれているセット済未利用枚数を超える枚数のみを、セット済未利用枚数に加算する。
第１更新部１１１の説明は以上である。
第２更新部１１３は、書込指示部１１２による書込指示が行われた後、処理結果取得部１１４が取得した書込処理の結果に応じて、以下の処理を実行する。第２更新部１１３は、書込処理の結果が成功で確定した場合、他の電子クーポン（第２電子クーポン）のセット済未利用枚数をそれぞれ全体の配布枚数から減じるとともに、セット済未利用枚数をクリアする。一方、第２更新部１１３は、書込処理の結果が失敗で確定した場合、第１更新部１１１で全体の配布枚数に加算された枚数を、第１更新部１１１による更新後の全体の配布枚数から減じるとともに、第１更新部１１１でセット済未利用枚数に加算された枚数を、第１更新部１１１による更新後のセット済未利用枚数から減じる。
本変形例の通信システム１の構成であっても、上述した実施形態の説明を、式（５）の関係に基づいて、「全体の残枚数」を「制限枚数（全体）−配布枚数（全体）」として読み替えれば、上述した実施形態と同等の作用効果を享受することができる。
また、本変形例は、（前提２）を採用しない構成に変形することも可能である。この場合、本変形例の“全体の配布枚数に加算／減算”という説明を、“全体の残枚数に減算／加算”と読み換えればよい。
以上のように、本変形例と変形例２の説明を合わせれば、ＡＳＰサーバ１０が“全体の残枚数”という情報そのものを記憶していなくても、“全体の残枚数”を間接的に導くことのできる情報を記憶する構成を有していれば本発明の範囲に含まれるとともに、上述した実施形態と同等の作用効果を享受することができる。このことは、個人の残枚数についても同じように説明することができる。
［変形例６］
上述した実施形態において、ＡＳＰサーバ１０は、電子クーポンの利用枚数を把握するために店舗端末４０から利用履歴を取得するが、利用履歴を取得するまでは、端末装置２０とＡＳＰサーバ１０とにおいて個人の残枚数に不整合が生じ、電子クーポンが重複取得されてしまうおそれがある。そこで、通信システム１においては、セット開始処理を開始したときから予め決められた期間においては、ＡＳＰサーバ１０が利用履歴を取得するまでその端末装置２０に別の電子クーポンを取得させないようにしてもよい。すなわち、ＡＳＰサーバ１０はセット開始処理を実行しないようにすればよい。この構成によれば、ＡＳＰサーバ１０は、別の電子クーポンを取得させないようにしている期間の間に利用履歴を取得できれば、この問題による電子クーポンの重複取得を回避できる。
［変形例７］
上述した実施形態において、ＡＳＰサーバ１０が電子クーポンの利用枚数を把握するために店舗端末４０から利用履歴を取得するが、店舗管理サーバ３０による利用履歴の送信が遅延する場合、ＡＳＰサーバ１０が利用履歴を取得するまでに別の電子クーポンの書込処理が行われると、全体の残枚数に不整合が生じ、電子クーポンが重複取得されてしまうおそれがある。つまり、電子クーポン利用後、利用履歴が送信されるまでに端末装置２０が別の電子クーポンを取得した場合、すでにメモリ領域２５１から削除されている利用済みの電子クーポンが、メモリ領域２５１に残っているとＡＳＰサーバ１０が誤認するため、利用済みの電子クーポンの分まで全体の残枚数に戻されてしまう。しかし、実際は、電子クーポンはメモリ領域２５１に残ったままなので、これが重複取得されてしまうおそれがある。そこで、ＡＳＰサーバ１０は、セット確定処理の際にクリアされるセット済未利用枚数については、全体の残枚数への差し戻しを予め決められた期間だけ遅らせるようにしてもよい。このようにすれば、全体の残枚数への差し戻しを待機している期間にＡＳＰサーバ１０が利用履歴を取得できれば、この問題による重複取得を回避できる。
［変形例８］
上述した実施形態の通信システム１では、店舗管理サーバ３０と店舗端末４０とが別々の装置であったが、これらを一体化した装置が用いられてもよい。この一体化した装置として、例えば、リーダ／ライタ機能を有しているパーソナルコンピュータやスマートフォン、ＰＯＳ（Point of sale）端末等がある。
また、ＡＳＰサーバ１０が、利用履歴を店舗管理サーバ３０ではなく端末装置２０から取得する構成を採ってもよい。
また、上述した実施形態では、ＡＳＰサーバ１０は、トランザクション管理テーブル１３３を参照して、ステータスが「未確定」の書込処理があると判断した場合は、セット開始処理を終了していた。しかしながら、本発明はこのような前提を必須とするものではなく、電子クーポンの枚数管理に支障がなければ、ステータスが「未確定」の書込処理がある場合に、セット開始処理を継続させることも可能である。
また、ＡＳＰサーバ１０の制御部１１が実現する各機能は、複数のプログラムの組み合わせによって実現され、又は、複数のハードウェア資源の協働によって実現されうる。
また、本発明は、ＡＳＰサーバ１０が実行するプログラムやクーポン管理方法として把握することも可能である。
３．第２実施形態
以下、図面を参照しつつ本発明の第２実施形態を説明する。
本実施形態に係る通信システムの全体構成は、第１実施形態のそれと同じである。よって、通信システムの全体構成についての説明は省略する。
本実施形態に係るＡＳＰサーバのハードウェア構成は、第１実施形態のそれと同じである。よって、ＡＳＰサーバのハードウェア構成についての説明は省略する。ただし、本実施形態に係るＡＳＰサーバ１０の記憶部１３は、図２４に示されるように、クーポン管理テーブル１３１、ユーザ管理テーブル１３２、トランザクション管理テーブル１３３及び保留リストテーブル１３４に代えて、クーポン情報テーブル１３５、ユーザ管理テーブル１３６及び保有状況管理テーブル１３７を記憶する。
図２５は、クーポン情報テーブル１３５の構成を示す図である。図２５に示すように、クーポン情報テーブル１３５は、「クーポンＩＤ」と、「クーポン名」と、「１ユーザあたりの提供制限枚数」と、「利用可能期間（開始日時）」と、「利用可能期間（終了日時）」とで示される各情報を対応付けたデータテーブルである。
「クーポンＩＤ」は、ＡＳＰサーバ１０により提供される電子クーポンを識別する識別子である。クーポンＩＤは、電子クーポンの種類毎に異なる。「１ユーザあたりの提供制限枚数」は、提供可能な数がユーザ毎に制限された電子クーポンである場合に、１のユーザに提供することができる電子クーポンの上限となる枚数である。言い換えれば、１ユーザあたりの提供制限枚数は、１のユーザの端末装置２０で取得可能な電子クーポンの上限となる枚数である。「利用可能期間（開始日時）」は、電子クーポンの利用が可能な期間の開始時期を示す日時である。「利用可能期間（終了日時）」は、電子クーポンの利用が可能な期間の終了時期を示す日時である。
以上の構成のクーポン情報テーブル１３５では、各電子クーポンに対応して、１ユーザあたりの提供制限枚数及び利用可能期間が設定されている。ただし、すべての電子クーポンに１ユーザあたりの提供制限枚数及び利用可能期間が設定されているとは限らず、どちらか一方が設定されていない電子クーポンもあれば、それら両方が設定されていない電子クーポンもある。
図２５に示すクーポン情報テーブル１３５には、クーポンＩＤ「ＣＩＤ００１」〜「ＣＩＤ００３」の電子クーポンに関する情報が示されている。クーポンＩＤ「ＣＩＤ００１」は、１ユーザあたりの提供制限枚数が「５」である電子クーポンを示し、利用可能期間（開始日時）が「２０１２／０２／０１ ０９：００」で、利用可能期間（終了日時）が「２０１２／０２／２９ ２３：５９」である。クーポンＩＤ「ＣＩＤ００２」は、１ユーザあたりの提供制限枚数が設定されていない電子クーポンを示す。つまり、ユーザは、クーポンＩＤ「ＣＩＤ００２」の電子クーポンを無制限に取得可能である。クーポンＩＤ「ＣＩＤ００２」の電子クーポンは、利用可能期間（開始日時）が「２０１２／０２／０１ ０９：００」で、利用可能期間（終了日時）が「２０１２／０２／２９ ２３：５９」である。クーポンＩＤ「ＣＩＤ００３」は、１ユーザあたりの提供制限枚数が「１０」である電子クーポンを示し、利用可能期間が設定されていない。利用可能期間が設定されていない電子クーポンは、時期に関係なくいつでも利用可能な電子クーポンである。
本実施形態では、クーポンＩＤ「ＣＩＤ００１」〜「ＣＩＤ００３」の電子クーポンは、同一のサービス提供者により提供される電子クーポンであるとする。ただし、クーポン情報テーブル１３５には、複数のサービス提供者により提供される電子クーポンに関する情報が格納されていてよい。
図２６は、ユーザ管理テーブル１３６の構成を示す図である。
図２６に示すように、ユーザ管理テーブル１３６は、「端末ＩＤ」と、「ユーザＩＤ」と、「有効期限」とで示される各情報を対応付けたデータテーブルである。「端末ＩＤ」は、端末装置２０を識別する端末装置２０固有の識別子であり、端末装置２０のＩＣチップに記憶されている端末ＩＤに対応している。ユーザＩＤは、端末装置２０のユーザを識別するユーザ固有の識別子である。ユーザ管理テーブル１３６において、１の端末ＩＤにはユーザＩＤが１つだけ対応付けられている。本実施形態のユーザＩＤは、ＡＳＰサーバ１０への会員登録によって、ＡＳＰサーバ１０により端末装置２０のユーザに割り当てられる識別子である。有効期限は、ユーザ管理テーブル１３６における端末ＩＤとユーザＩＤとの対応付けが有効である期限である。詳しくは後述するが、有効期限が経過した後の端末ＩＤとユーザＩＤとの対応付けは無効となる。無効となった対応付けについては、制御部１１によりユーザＩＤが別のユーザＩＤに変更される場合がある。
以上の構成のユーザ管理テーブル１３６は、例えば、ＡＳＰサーバ１０が端末装置２０に電子クーポンを提供する場合に、その提供の可否を判定するために参照される。
図２６に示すユーザ管理テーブル１３６では、端末ＩＤ「ａｂｃｄｅ００００１」とユーザＩＤ「ＵＩＤ０００１」とが対応付けられ、この対応付けの有効期限は「２０１２／０２／２９ ２３：５９」である。このような対応付けがユーザ管理テーブル１３６に格納されているということは、端末ＩＤ「ａｂｃｄｅ００００１」が示す端末装置２０のユーザには、既にユーザＩＤ「ＵＩＤ０００１」が割り当てられ、且つ、ＡＳＰサーバ１０がこの端末装置２０に電子クーポンを提供したことがあることを意味する。また、図２６に示す例では、端末ＩＤ「ａｂｃｄｅ００００２」とユーザＩＤ「ＵＩＤ０００２」とが対応付けられ、この対応付けの有効期限は「２０１２／０２／２９ ２３：５９」である。
図２７は、保有状況管理テーブル１３７の構成を示す図である。
図２７に示すように、保有状況管理テーブル１３７は、「ユーザＩＤ」と、「クーポンＩＤ」と、「取得済み未利用枚数」と、「利用枚数」と、「残枚数」とで示される各情報を対応付けたデータテーブルである。「ユーザＩＤ」及び「クーポンＩＤ」は既に説明したとおりの情報である。「取得済み未利用枚数」は、端末装置２０に提供されてＩＣチップに書き込まれた電子クーポンのうち、未だ利用されていない電子クーポンの枚数である。言い換えれば、取得済み未利用枚数は、端末装置２０が取得済みで利用可能な電子クーポンの枚数である。「利用枚数」は、端末装置２０に提供されてＩＣチップに書き込まれた電子クーポンのうち、既に利用された電子クーポンの枚数である。「残枚数」は、端末装置２０に提供可能な電子クーポンの残りの枚数である。この残枚数は、１ユーザあたりの提供制限枚数から利用枚数を減じた枚数に一致する。１ユーザあたりの提供制限枚数が設定されていない電子クーポンの場合、「残枚数」のフィールドには「なし」という情報が格納される。
以上の構成の保有状況管理テーブル１３７は、端末装置２０のユーザ毎の電子クーポンの保有状況を格納したデータテーブルである。
本実施形態に係る端末装置のハードウェア構成は、第１実施形態のそれと同じである。よって、端末装置のハードウェア構成についての説明は省略する。
なお、ＩＣチップ２５は、プロセッサやアンテナ、データの読み書きに用いられるメモリ領域２５１を有し、近接型の非接触通信を行うためのＩＣチップである。ＩＣチップ２５のプロセッサは、アンテナにより受信した信号、又は制御部２１からの指示に応じてメモリ領域２５１にアクセスしてデータの読み書きを行う。また、ＩＣチップ２５は、端末装置２０の端末ＩＤをメモリ領域２５１に記憶する。
ところで、メモリ領域２５１は、複数のサービス提供者のうちのいずれか１のサービス提供者の電子クーポンが書き込まれる仕様となっている。言い換えれば、メモリ領域２５１は、複数のサービス提供者で共有されるメモリ領域である。よって、或るサービス提供者の電子クーポンがメモリ領域２５１に記憶されている場合、他のサービス提供者の電子クーポンは、上書きによる書込処理でメモリ領域２５１に記憶させられる。つまり、元々メモリ領域２５１に記憶されていた電子クーポンは書込処理によって削除させられる。この場合であっても、端末装置２０は、上書きによる書込処理によってメモリ領域２５１の電子クーポンを削除したときには、ＡＳＰサーバ１０に問い合わせることによって、いつでもその削除前の状態に戻して、取得済みの電子クーポンをメモリ領域２５１に書き込むことができる。具体的には、ＡＳＰサーバ１０は、保有状況管理テーブル１３７において電子クーポンの保有状況を管理しているので、保有状況管理テーブル１３７に格納された情報に従って電子クーポンの書込処理を端末装置２０に行わせる。一方で、同一のサービス提供者の複数の電子クーポンについては、同時にメモリ領域２５１に記憶されることがある。例えば、クーポンＩＤ「ＣＩＤ００１」〜「ＣＩＤ００３」の電子クーポンが同時期にメモリ領域２５１に記憶されていることがある。
なお、電子クーポンをメモリ領域２５１に書き込む書込処理によって、メモリ領域２５１に記憶された端末ＩＤが消失することはない。
次に、ＡＳＰサーバ１０の制御部１１の機能的構成を説明する。
図２８は、ＡＳＰサーバ１０の制御部１１の電子クーポンの管理に関する機能の機能的構成を示す機能ブロック図である。図２８に示すように、ＡＳＰサーバ１０の制御部１１は、プログラムを実行することにより、読出指示部１１７と、取得部１１８と、提供部１１９と、書込部１２０とに相当する機能を実現する。
読出指示部１１７は、提供可能な数がユーザ毎に制限された電子クーポン（つまり、クーポン情報テーブル１３５で１ユーザあたりの提供制限枚数が設定された電子クーポン）を提供する場合には、端末装置２０が有するＩＣチップ２５のメモリ領域２５１からの端末ＩＤの読み出しを指示する。一方、読出指示部１１７は、提供可能な数がユーザ毎に制限されていない電子クーポン（つまり、クーポン情報テーブル１３５で１ユーザあたりの提供制限枚数が設定されていない電子クーポン）を提供する場合には、メモリ領域２５１からの端末ＩＤの読み出しを指示しない。
取得部１１８は、電子クーポンを端末装置２０に新たに提供する場合、端末装置２０の端末ＩＤと端末装置２０のユーザのユーザＩＤとを取得する。取得部１１８は、読出指示部１１７により端末ＩＤの読み出しが指示された場合には、その指示に従ってメモリ領域２５１から読み出された端末ＩＤを取得する。
提供部１１９は、クーポン情報テーブル１３５、ユーザ管理テーブル１３６及び保有状況管理テーブル１３７を参照し、取得部１１８が取得した端末ＩＤとユーザＩＤとに基づいて電子クーポンを新たに提供すると判定した場合には、１ユーザあたりの提供制限枚数の範囲内でこの端末ＩＤが示す端末装置２０に電子クーポンを提供するための処理を実行する。具体的には、提供部１１９は、ユーザ管理テーブル１３６において、取得部１１８が取得した端末ＩＤに取得部１１８が取得したユーザＩＤと異なるユーザＩＤが対応付けられていない場合には、電子クーポンを提供すると判定する。また、提供部１１９は、ユーザ管理テーブル１３６において、取得部１１８が取得した端末ＩＤに取得部１１８が取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に予め決められた条件を満たすときには、電子クーポンを提供すると判定する。ここでいう条件は、ユーザ管理テーブル１３６において設定された有効期限が経過し、端末ＩＤとユーザＩＤとの対応付けが無効になっていることである。また、提供部１１９は、１ユーザあたりの提供制限枚数が設定されていない電子クーポンを提供するための処理も実行する。
なお、提供部１１９が実行する電子クーポンを提供するための処理は、端末装置２０に電子クーポンの書込処理を実行させるための処理である。
書込部１２０は、記憶部１３に記憶されたユーザ管理テーブル１３６及び保有状況管理テーブル１３３にデータを書き込む処理を司る。書込部１２０は、例えば、提供部１１９により電子クーポンを提供するための処理が実行される場合、ユーザ管理テーブル１３６において、取得部１１８が取得した端末ＩＤに取得部１１８が取得したユーザＩＤを対応付ける。また、書込部１２０は、提供部１１９により実行された電子クーポンを提供するための処理や店舗管理サーバ３０から受信した電子クーポンの利用履歴に応じて、保有状況管理テーブル１３３を更新する。
ＡＳＰサーバ１０の機能的構成の説明は以上である。次に、通信システム１の動作を説明する。
図２９は、通信システム１の全体的な処理の流れを示すシーケンスチャートである。
本実施形態において、端末装置２０がＡＳＰサーバ１０から電子クーポンを取得するためには、事前に、ＡＳＰサーバ１０に対して会員登録を行う必要がある。具体的には、端末装置２０は、ｗｅｂブラウザを実行して会員登録を行うための所定のｗｅｂページを表示させ、ユーザの操作に応じて、ユーザＩＤ発行要求と、ユーザＩＤを用いたユーザ認証に用いられるパスワードとを、ＡＳＰサーバ１０宛てに送信する（ステップＳｂ１）。ＡＳＰサーバ１０は、端末装置２０からユーザＩＤ発行要求及びパスワードを受信すると、その端末装置２０のユーザに割り当てるユーザＩＤを１つだけ発行し、発行したユーザＩＤと受信したパスワードとを対応付けて会員情報として、この会員情報を記憶部１３に記憶させておく（ステップＳｂ２）。ＡＳＰサーバ１０は、ステップＳｂ２の処理で発行したユーザＩＤを端末装置２０に通知する（ステップＳｂ３）。ここにおいて端末装置２０は、ＡＳＰサーバ１０から通知されたユーザＩＤを、いわゆるクッキー（ｗｅｂブラウザを通じて訪問者のコンピュータに一時的にデータを書き込んで保存させる仕組み）を利用して、記憶部２６に記憶させておく。ただし、端末装置２０は第三者によるクッキーの情報の偽装によるなりすましの可能性を抑えるため、ユーザＩＤをそのまま記憶させるのではなく、そのハッシュ値（暗号値）を記憶させておいてもよい。また、本実施形態のＡＳＰサーバ１０は、端末装置２０のユーザに１つだけユーザＩＤを割り当てるべく、クッキーを利用して記憶部２６にユーザＩＤが記憶されている場合には、会員登録を拒否する。
以上が、端末装置２０が事前に行う会員登録の説明である。次に、端末装置２０がＡＳＰサーバ１０から電子クーポンを取得しようとする場合の動作について説明する。
端末装置２０のユーザは、電子クーポンをダウンロードしようとするときには、端末装置２０を操作してｗｅｂブラウザを実行させ、電子クーポンを取得するための所定のｗｅｂページを表示させる操作を行う。端末装置２０は、このユーザの操作に応じて、ページアクセス要求をＡＳＰサーバ１０宛てに送信する（ステップＳｂ４）。ＡＳＰサーバ１０は、ページアクセス要求を受信すると、ユーザ認証を行うべく、ユーザＩＤ及びパスワードの送信を端末装置２０に要求する（ステップＳｂ５）。端末装置２０は、ＡＳＰサーバ１０からユーザＩＤ及びパスワードの送信が要求されると、ユーザＩＤ及びパスワードの入力画面を表示して、ユーザにそれらの入力を促す。ここにおいて、ユーザは、ステップＳｂ３の処理で通知されたユーザＩＤとパスワードとを入力する。ただし、端末装置２０は、ユーザＩＤについては、クッキーを利用して記憶しておいたユーザＩＤを自動入力しておく。ただし、クッキーの情報が削除されていたり、クッキーの情報の送信拒否が端末装置２０に予め設定されていたりした場合には、端末装置２０のユーザはユーザＩＤを手動入力する。端末装置２０は、ユーザＩＤ及びパスワードが入力されてユーザにより送信を指示する操作が行われると、ユーザＩＤ及びパスワードをＡＳＰサーバ１０宛てに送信する（ステップＳｂ６）。
ＡＳＰサーバ１０は、ステップＳｂ６の処理で送信されたユーザＩＤ及びパスワードを受信すると、ユーザ認証を行う（ステップＳｂ７）。ここにおいて、ＡＳＰサーバ１０は、受信したユーザＩＤ及びパスワードと記憶部１３に記憶された会員情報とを照合し、ユーザＩＤ及びパスワードがともに一致する会員情報があった場合には、ユーザ認証に成功したと判定する。一方、ＡＳＰサーバ１０は、受信したユーザＩＤ及びパスワードがともに一致する会員情報がなかった場合には、ユーザ認証に失敗したと判定する。ＡＳＰサーバ１０は、ユーザ認証に失敗したと判定した場合には、図２９に示す残りの処理を実行せず、ユーザ認証に失敗した旨を端末装置２０に通知する。
なお、クッキーを利用して端末装置２０の記憶部２６にユーザＩＤが記憶されている場合、端末装置２０はステップＳｂ４の処理でページアクセス要求とともにユーザＩＤを送信してもよい。この場合、ＡＳＰサーバ１０は、ページアクセス要求とともに受信したユーザＩＤに基づいて、ステップＳｂ７の処理に相当するユーザ認証に成功したと判定してもよい。このような自動認証が行われた場合、前述のステップＳｂ５及びＳｂ６の処理が省略されることとなり、端末装置２０のユーザにとってはユーザＩＤ及びパスワードの入力画面による入力操作の手間がなくなる。また、ＡＳＰサーバ１０は、第三者によるクッキーの情報の偽装によるなりすましの可能性を抑えるため、ユーザＩＤを発行したときから又は前回のユーザ認証に成功したときから所定期間が経過するまでは、自動認証を行い、それ以降においては、ユーザＩＤ及びパスワードの入力画面による入力操作を端末装置２０のユーザに行わせてもよい。
ステップＳｂ７の処理でユーザ認証に成功した場合、ＡＳＰサーバ１０は、ユーザ認証に成功した旨を端末装置２０に通知する（ステップＳｂ８）。そして、端末装置２０は所定のｗｅｂページ（図３０に示すクーポン取得画面）をブラウザ上で表示させて、ユーザの操作に応じて、クーポン取得要求をＡＳＰサーバ１０宛てに送信する（ステップＳｂ９）。
図３０は、クーポン取得画面を説明する図である。
ユーザはＵＩ部２４を見ながら操作して、取得しようとする電子クーポンの種類と取得枚数とをプルダウンメニューＰｂ１，Ｐｂ２及びＰｂ３を用いて選択し、その選択後、「クーポンを取得」と付されたソフトボタンＢｂを選択する。例えば、ユーザはクーポン名「からあげ半額」という電子クーポンを取得しようとする場合、プルダウンメニューＰｂ１を操作して、取得枚数を「１」以上に設定する。ユーザは他の電子クーポンを取得しようとする場合にも同様に操作すればよい。
なお、図３０に示すクーポン取得画面のクーポン名は、クーポン情報テーブル１３５に格納されたクーポン名に対応する。また、クーポン取得画面において設定可能な電子クーポンの取得枚数の上限は、保有状況管理テーブル１３３に格納されている同電子クーポンの残枚数以下となる。
端末装置２０は、図３０に示すクーポン取得画面のソフトボタンＢｂが選択されると、取得しようとする電子クーポンとその取得枚数とを特定可能な情報（例えば、クーポンＩＤと取得枚数とのデータセット）を含むクーポン取得要求を、ＡＳＰサーバ１０宛てに送信する。
ＡＳＰサーバ１０は、端末装置２０からクーポン取得要求を受信すると、端末ＩＤ要否判定処理を実行する（ステップＳｂ１０）。
図３１は、端末ＩＤ要否判定処理の手順を示すフローチャートである。
まず、ＡＳＰサーバ１０は、１ユーザあたりの提供制限枚数が設定された電子クーポンの取得要求を受信したか否かを判定する（ステップＳｂ１０１）。ＡＳＰサーバ１０は、１ユーザあたりの提供制限枚数が設定された電子クーポンを含むクーポン取得要求を受信した場合（ステップＳｂ１０１；ＹＥＳ）、端末ＩＤ通知処理を実行すると判定する（ステップＳｂ１０２）。例えば、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００１」や「ＣＩＤ００３」の電子クーポンを含むクーポン取得要求を受信した場合には、端末ＩＤ通知処理を実行すると判定する。
一方、ＡＳＰサーバ１０は、１ユーザあたりの提供制限枚数が設定されている電子クーポンを含まないクーポン取得要求を受信した場合（ステップＳｂ１０１；ＮＯ）、端末ＩＤ通知処理を実行しないと判定する（ステップＳｂ１０３）。例えば、ＡＳＰサーバ１０は、クーポンＩＤ「ＣＩＤ００２」の電子クーポンのみの取得要求を受信した場合には、端末ＩＤ通知処理を実行すると判定する。
以上のように、ＡＳＰサーバ１０は、クーポン情報テーブル１３５において１ユーザあたりの提供制限枚数が設定されているか否かに応じて、端末装置２０の端末ＩＤの要否を判定する。
ＡＳＰサーバ１０は、端末ＩＤ要否判定処理を終了すると（図２９のステップＳｂ１０）、端末ＩＤ通知処理を実行すると判定していた場合には、端末ＩＤ通知処理を実行する（ステップＳｂ１１）。すなわち、ＡＳＰサーバ１０は、電子クーポンに１ユーザあたりの提供制限枚数が設定されている場合には、端末ＩＤ通知処理を実行する。一方、ＡＳＰサーバ１０は、電子クーポンに対して１ユーザあたりの提供制限枚数が設定されておらず、端末ＩＤ通知処理を実行しないと判定していた場合には、ステップＳｂ１１の処理をスキップし、端末ＩＤ通知処理を実行しない。
図３２は、端末ＩＤ通知処理の手順を示すフローチャートである。
まず、ＡＳＰサーバ１０は、アプリケーション管理サーバ５０に対して、端末ＩＤの通知に関する処理依頼を行って、問合せＩＤの生成を要求する（ステップＳｂ１１１）。アプリケーション管理サーバ５０は、ステップＳｂ１１１の処理で送信された処理依頼に応じて問合せＩＤを生成し、生成した問合せＩＤをＡＳＰサーバ１０宛てに送信する（ステップＳｂ１１２）。問い合せＩＤは、処理依頼を識別する識別子である。
ＡＳＰサーバ１０は、アプリケーション管理サーバ５０から問合せＩＤを受信すると、クーポン管理アプリケーション２６１の実行指示を端末装置２０宛てに送信する（ステップＳｂ１１３）。ここにおいて、ＡＳＰサーバ１０は、アプリケーション管理サーバ５０から受信した問合せＩＤを含む実行指示を送信する。
端末装置２０は、ＡＳＰサーバ１０から実行指示を受信すると、記憶部２６に記憶されたクーポン管理アプリケーション２６１を読み出して実行する。そして、端末装置２０は、クーポン管理アプリケーション２６１に従って、ＡＳＰサーバ１０から受信した実行指示に含まれていた問合せＩＤを、アプリケーション管理サーバ５０宛てに送信する（ステップＳｂ１１４）。アプリケーション管理サーバ５０は、端末装置２０から受信した問合せＩＤに対応する処理依頼に従って、問合せＩＤの送信元である端末装置２０宛てに端末ＩＤの読取指示を送信する（ステップＳｂ１１５）。
端末装置２０は、アプリケーション管理サーバ５０から受信した読取指示に従ってＩＣチップ２５に読取処理を行わせる（ステップＳｂ１１６）。ステップＳｂ１１６の処理では、制御部２１はアプリケーション管理サーバ５０からの読取指示に従って、ＩＣチップ２５のプロセッサに端末ＩＤの読み出しを指示する。この指示に従って、ＩＣチップ２５のプロセッサは、メモリ領域２５１にアクセスして端末ＩＤを読み出し、読み出した端末ＩＤを制御部２１に供給する。
端末装置２０は、ＩＣチップ２５から制御部２１に供給された端末ＩＤをアプリケーション管理サーバ５０宛てに送信する（ステップＳｂ１１７）。次に、端末装置２０は、端末ＩＤの読取処理が終了した旨を示す終了通知を、ＡＳＰサーバ１０宛てに送信する（ステップＳｂ１１８）。
なお、端末装置２０は、ステップＳｂ１１３の処理に応じてクーポン管理アプリケーション２６１を実行してから、ステップＳｂ１１７の処理までをクーポン管理アプリケーション２６１に従って実行する。
ＡＳＰサーバ１０は、端末装置２０から送信された終了通知を受信すると、アプリケーション管理サーバ５０に問合せＩＤを送信して、終了通知の送信元の端末装置２０の端末ＩＤを問い合わせる（ステップＳｂ１１９）。アプリケーション管理サーバ５０は、ＡＳＰサーバ１０からの問い合わせに応じて、ＡＳＰサーバ１０宛てに端末ＩＤを送信する（ステップＳｂ１２０）。ＡＳＰサーバ１０は、ステップＳｂ１２０の処理でアプリケーション管理サーバ５０から送信された端末ＩＤを取得する。
なお、ステップＳｂ１２０の処理において、アプリケーション管理サーバ５０は端末ＩＤをそのまま送信するのではなく、端末ＩＤを一意に特定可能な別の情報に変換して送信してもよい。この構成によれば、例えば通信システム１に複数のＡＳＰサーバが含まれる場合にＡＳＰサーバ毎に端末ＩＤの変換規則を異ならせておけば、第１のＡＳＰサーバがユーザＡの端末ＩＤを把握したとしても、それは第２のＡＳＰサーバにとってのユーザＢの端末ＩＤとは一致しない。これにより、例えば、第１のＡＳＰサーバ及び第２のＡＳＰサーバが共通のアプリケーション管理サーバ５０と通信して端末ＩＤを取得する構成であっても、第１のＡＳＰサーバが第２のＡＳＰサーバが提供するサービスに対して端末ＩＤを偽装するといった不正の発生を防止することが可能となる。
以上のように、ＡＳＰサーバ１０は、端末ＩＤを端末装置２０から取得する場合には、端末装置２０にクーポン管理アプリケーション２６１を実行させるとともに、アプリケーション管理サーバ５０経由で端末ＩＤのメモリ領域２５１からの読み出しを指示する。ＡＳＰサーバ１０と端末装置２０との間の情報のやり取りをアプリケーション管理サーバ５０が仲介するようにしている理由は、端末ＩＤの改ざんなど不正に情報が書き換えられるのを防ぎ、端末ＩＤを用いた情報管理のセキュリティ上の問題の発生を防止するためである。
ＡＳＰサーバ１０は、ステップＳｂ１１の処理の端末ＩＤ通知処理を終了すると、クーポン提供判定処理を実行する（ステップＳｂ１２）。クーポン提供判定処理は、端末装置２０に電子クーポンを提供するか否かを判定する処理である。ただし、本実施形態では、ＡＳＰサーバ１０は、１ユーザあたりの提供制限枚数が設定された電子クーポンを提供する場合には、クーポン提供判定処理を実行するが、１ユーザあたりの提供制限枚数が設定されていない電子クーポンを提供する場合には、クーポン提供判定処理を実行しない。
図３３は、クーポン提供判定処理の手順を示すフローチャートである。
まず、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６において、ステップＳｂ１１の端末ＩＤ通知処理で取得した端末ＩＤに何らかのユーザＩＤが対応付けられているか否かを判定する（ステップＳｂ１２１）。ＡＳＰサーバ１０は、端末ＩＤ通知処理によって取得した端末ＩＤに、いずれのユーザＩＤも対応付けられていない（例えば、端末ＩＤがユーザ管理テーブル１３６に格納されていない）と判定した場合には（ステップＳｂ１２１；ＮＯ）、ステップＳｂ１２２の処理に進む。そして、ＡＳＰサーバ１０は、端末ＩＤ通知処理で取得した端末ＩＤに、ステップＳｂ７のユーザ認証で用いたユーザＩＤを対応付けるよう、ユーザ管理テーブル１３６に端末ＩＤとユーザＩＤとを書き込む（ステップＳｂ１２２）。例えば、ユーザが会員登録を行ってから初めて電子クーポンをダウンロードしようとした場合には、端末ＩＤ通知処理で取得した端末ＩＤとユーザ認証で用いたユーザＩＤとの対応付けはユーザ管理テーブル１３６に格納されていない。
次に、ＡＳＰサーバ１０は、保有状況管理テーブル１３７に基づいて、端末装置２０に電子クーポンを提供可能か否かを判定する（ステップＳｂ１２３）。ここでは、ＡＳＰサーバ１０は、１ユーザあたりの提供制限枚数を超えない範囲内で電子クーポンを提供できるか否かを判定する。例えば、ＡＳＰサーバ１０は、クーポン取得要求で指定された電子クーポンの取得枚数がその電子クーポンの残枚数以下である場合には、電子クーポンを提供可能と判定することとなる。
ＡＳＰサーバ１０は、電子クーポンを提供可能と判定した場合には（ステップＳｂ１２３；ＹＥＳ）、ステップＳｂ１２２の処理でユーザ管理テーブル１３６に書き込んだ端末ＩＤとユーザＩＤとの対応付けの有効期限を設定する（ステップＳｂ１２４）。ここでは、ＡＳＰサーバ１０は、クーポン情報テーブル１３５を参照し、提供しようとする電子クーポンに利用可能期間が設定されている場合には、利用可能期間の終了日時を有効期限として設定する。また、ＡＳＰサーバ１０は、電子クーポンの利用可能期間が設定されていない場合には、現在日時から予め決められた期間後（ここでは、３０日後）を有効期限として設定する。また、ＡＳＰサーバ１０は、同一サービス提供者の複数種類の電子クーポンを端末装置２０に提供する場合に、各電子クーポンに利用可能期間が設定されているときには、終了時期が最も後である電子クーポンの利用可能期間の終了時期を有効期限として設定するとよい。また、ＡＳＰサーバ１０は、同一サービス提供者の複数種類の電子クーポンを端末装置２０に提供する場合に、利用可能期間が設定されている電子クーポンと設定されていない電子クーポンが混在するときには、有効期限が最も後となる電子クーポンに基づいて有効期限を設定するとよい。
ＡＳＰサーバ１０は、端末ＩＤとユーザＩＤとの対応付けの有効期限を設定すると、クーポン提供判定処理を終了する。なお、ＡＳＰサーバ１０は、ステップＳｂ１２３の処理で電子クーポンを提供可能でないと判定した場合には（ステップＳｂ１２３；ＮＯ）、エラー通知を行って（ステップＳｂ１２７）、クーポン提供判定処理を終了する。
ところで、ＡＳＰサーバ１０が、ステップＳｂ１１の端末ＩＤ通知処理で端末ＩＤ「ａｂｃｄｅ００００１」を取得していたとする。この場合、ユーザ管理テーブル１３６において、端末ＩＤ「ａｂｃｄｅ００００１」がユーザＩＤ「ＵＩＤ０００１」に対応付けられているから（図２６参照）、ＡＳＰサーバ１０はステップＳｂ１２１の処理で「ＹＥＳ」と判定する。
ステップＳｂ１２１の処理で「ＹＥＳ」と判定した場合、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６において、端末ＩＤ通知処理で取得した端末ＩＤを含む対応付けの有効期限前か否かを判定する（ステップＳｂ１２５）。ここで、現在日時が「２０１２／２／１６／１２：００」である場合、ＡＳＰサーバ１０は有効期限前であると判定し（ステップＳｂ１２５；ＹＥＳ）、ステップＳｂ１２６の処理に進む。次に、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６において端末ＩＤ通知処理で取得した端末ＩＤに対応付けられたユーザＩＤと、ステップＳｂ７のユーザ認証に用いたユーザＩＤとが一致するか否かを判定する（ステップＳｂ１２６）。ＡＳＰサーバ１０は両ユーザＩＤが一致しないと判定した場合（ステップＳｂ１２６；ＮＯ）、エラー通知を行って（ステップＳｂ１２７）、クーポン提供判定処理を終了する。
ユーザ管理テーブル１３６において端末ＩＤ通知処理で取得した端末ＩＤに対応付けられたユーザＩＤと、ユーザ認証に用いたユーザＩＤとが一致しないということは、１の端末装置２０のユーザに複数のユーザＩＤが割り当てられていることを意味する。よってこの場合に、ＡＳＰサーバ１０が端末装置２０に電子クーポンを提供してしまうと、各ユーザＩＤを用いて電子クーポンが端末装置２０に取得されてしまい、その取得枚数が１ユーザあたりの提供制限枚数を超える可能性が生じる。そこで、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６において、端末ＩＤ通知処理で取得した端末ＩＤにユーザ認証に用いたユーザＩＤと異なるユーザＩＤが対応付けられている場合には、エラー通知を行うことによって、１ユーザあたりの提供制限枚数を超えて電子クーポンを提供しないようにする。これにより、１の端末装置２０により、１のユーザあたりの提供制限枚数を超えて電子クーポンが利用されることを防止できる。
なお、１の端末装置２０のユーザに複数のユーザＩＤが割り当てられる場合として、例えば、会員登録の記憶部２６に記憶されたクッキーの情報が削除された場合がある。以上のＡＳＰサーバ１０の動作によれば、ユーザがクッキーの情報を削除し別のユーザになりすまして複数回会員登録を行った場合であっても、１ユーザあたりの提供制限枚数を超えて電子クーポンが不正に取得され利用されるのを防止することができる。
ステップＳｂ１２６の処理で、ＡＳＰサーバ１０が、ユーザ管理テーブル１３６において、端末ＩＤ通知処理で取得した端末ＩＤに対応付けられたユーザＩＤとステップＳｂ７のユーザ認証に用いたユーザＩＤとが一致すると判定した場合（ステップＳｂ１２６；ＹＥＳ）、ＡＳＰサーバ１０はステップＳｂ１２３の処理に進む。この場合、ＡＳＰサーバ１０が、前回の電子クーポン提供時と同じ端末ＩＤとユーザＩＤとの組み合わせを取得したことになるから、ユーザにより電子クーポンが不正取得されようとしているわけではないと推測することができる。そこで、ＡＳＰサーバ１０は既に説明した手順でステップＳｂ１２３及びＳｂ１２４の処理を実行し、１ユーザあたりの提供制限枚数の範囲内で電子クーポンを提供可能とすると判定することとなる。
また、ステップＳｂ１２１の処理で「ＹＥＳ」と判定した後、ＡＳＰサーバ１０がステップＳｂ１２５の処理で対応付けが有効期限前でない、つまり有効期限を経過したと判定した場合（ステップＳｂ１２５；ＮＯ）、ステップＳｂ１２２の処理に進む。この場合、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６における端末ＩＤ通知処理で取得した端末ＩＤを含む対応付けが無効であるから、この端末ＩＤにユーザ認証に用いたユーザＩＤを対応付ける。
例えば、ＡＳＰサーバ１０が１ユーザあたりの提供制限枚数が設定されたクーポンＩＤ「ＣＩＤ００１」の電子クーポンを提供しようとする場合において、現在日時が有効期限「２０１２／０２／２９ ２３：５９」よりも後である場合を考える。ここで、ステップＳｂ１１の処理で取得した端末ＩＤが「ａｂｃｄｅ００００１」で、且つ、ユーザ認証に用いたユーザＩＤがユーザＩＤ「ＵＩＤ０００３」であるときには、ＡＳＰサーバ１０は図３４に示すようにユーザ管理テーブル１３６を更新する。具体的には、ＡＳＰサーバ１０は、ステップＳｂ１２２の処理で、端末ＩＤ「ａｂｃｄｅ００００１」に対応付けられたユーザＩＤを「ＵＩＤ０００１」から「ＵＩＤ０００３」に変更する。そして、ＡＳＰサーバ１０はステップＳｂ１２３の処理で「ＹＥＳ」と判定すると、ステップＳｂ１２４の処理で有効期限を利用可能期間の終了日時に設定する。（ここでは、有効期限「２０１２／０２／２９ ２３：５９」のままである。）
また、ＡＳＰサーバ１０が、利用可能期間が設定されていないクーポンＩＤ「ＣＩＤ００３」の電子クーポンを提供しようとする場合において、現在日時が有効期限「２０１２／０２／２９ ２３：５９」よりも後であり、且つ、端末ＩＤが「ａｂｃｄｅ００００１」でユーザ認証に用いたユーザＩＤがユーザＩＤ「ＵＩＤ０００３」であるときには、ＡＳＰサーバ１０は図３５に示すようにユーザ管理テーブル１３６を更新する。具体的には、ＡＳＰサーバ１０は、端末ＩＤ「ａｂｃｄｅ００００１」に対応付けられたユーザＩＤを「ＵＩＤ０００１」から「ＵＩＤ０００３」に変更する。そして、ＡＳＰサーバ１０はステップＳｂ１２３の処理で「ＹＥＳ」と判定すると、ステップＳｂ１２４の処理で有効期限を現在日時から予め決められた期間後（例えば、３０日後）に設定する。（ここでは、有効期限「２０１２／０４／０３ １９：０４」とする。）
以上のように、ＡＳＰサーバ１０は、端末ＩＤ通知処理で取得した端末ＩＤを含む対応付けの有効期限が経過した後である場合には、この対応付けに含まれるユーザＩＤの変更を許可しているが、その理由は以下のとおりである。
或るユーザが所有していた端末装置２０が別のユーザに譲渡された場合において、それら両ユーザが会員登録を行ったときには、端末装置２０のユーザが電子クーポンを不正取得しようとするユーザではなくても、結果として、複数のユーザＩＤが１の端末装置２０のユーザに割り当てられることになる。また、端末装置２０の機種変更を行ったユーザが既に割り当てられたユーザを記録していなかった場合や、端末装置２０のユーザがユーザＩＤやパスワードを忘れてしまった場合に、やむを得ず複数回会員登録を行ったときにも、複数のユーザＩＤが１の端末装置２０のユーザに割り当てられることになる。このような場合にも、ＡＳＰサーバ１０が、ユーザ管理テーブル１３６における端末ＩＤとユーザＩＤとの対応付けと、端末装置２０から取得した端末ＩＤとユーザＩＤの組み合わせとが異なるという理由で、永続的に電子クーポンの提供を不許可としてしまうと、不正取得を目的としないユーザの電子クーポンの取得及び利用が妨げられてしまう。そこで、本実施形態のＡＳＰサーバ１０は、ユーザ管理テーブル１３６における端末ＩＤとユーザＩＤとの対応付けに有効期限を設定しておき、その有効期限が経過した後においては、ユーザ管理テーブル１３６の対応付けの変更を許可する。
前述したように、電子クーポンに利用可能期間が設定されている場合、ＡＳＰサーバ１０は利用可能期間の終了日時を対応付けの有効期限としている。これにより、ＡＳＰサーバ１０は、或る電子クーポンの利用可能期間後においては、ユーザ管理テーブル１３６における端末ＩＤとユーザＩＤとの対応付けを無効にするから、それ以降においては、この対応付けに一致しない端末ＩＤとユーザＩＤとを取得した場合であっても、電子クーポンを提供可能とする。この場合において仮に悪意のあるユーザが複数のユーザＩＤを用いてその電子クーポンを不正取得しようとした場合であっても、利用可能期間後にしかこの電子クーポンを取得できないので、１ユーザあたりの提供制限枚数を超えて電子クーポンが取得されても、その電子クーポンが実際に利用されることはない。すなわち、仮に電子クーポンが不正取得されても、それによる実害をサービス提供者が被ることはない。
また、電子クーポンに利用可能期間が設定されていない場合、ＡＳＰサーバ１０は電子クーポンを提供する処理を実行してから予め決められた期間が経過したことを条件として、対応付けを無効にする。これにより、ＡＳＰサーバ１０は、悪意のあるユーザが複数のユーザＩＤを用いて不正取得しようとした場合であっても、上記期間後にしか対応付けを更新しないので、短期間に大量の電子クーポンが不正取得されることはない。ただし、上記期間が長すぎると、正当なユーザの電子クーポンの取得及び利用が妨げられるし、逆に上記期間が短すぎると、悪意のあるユーザが複数のユーザＩＤを用いて電子クーポンを大量に不正取得する可能性が高まるので、両方の事情に照らして適切な期間に設定されているとよい。
以上のように、電子クーポンの不正取得の防止と、悪意のないユーザが複数ユーザＩＤを取得した場合でも電子クーポンの取得及び利用が妨げられないようにすることとの両立を目的として、ＡＳＰサーバ１０は、ユーザＩＤと端末ＩＤとの対応付けに有効期限を持たせ、有効期限を過ぎれば対応付けを無効にしている。
以上がクーポン提供判定処理の説明である。
ステップＳｂ１２３の処理で「ＹＥＳ」と判定しステップＳｂ１２４の処理で有効期限を設定した場合には、ＡＳＰサーバ１０は、クーポン提供判定処理の後に、電子クーポンを提供するための処理として電子クーポンの書込処理を端末装置２０に行わせる（ステップＳｂ１３）。ここにおいても、ＡＳＰサーバ１０はアプリケーション管理サーバ５０を介して端末装置２０に書込処理を行わせる。
図３６は、電子クーポンの書込処理の手順を示すシーケンスチャートである。
ＡＳＰサーバ１０は、アプリケーション管理サーバ５０に対して、電子クーポンの書込処理に関する処理依頼を行って、問合せＩＤの生成を要求する（ステップＳｂ１３１）。アプリケーション管理サーバ５０は、処理依頼に応じて生成した問合せＩＤを、ＡＳＰサーバ１０宛てに送信する（ステップＳｂ１３２）。ここにおいて、処理依頼は、ＩＣチップ２５のメモリ領域２５１に書き込まれることとなる電子クーポンの情報を含む。この情報は、電子クーポンのクーポンＩＤと電子クーポンの取得枚数とを特定可能な情報を含む。
次に、ＡＳＰサーバ１０は、書込処理の実行を指示するための書込指示を端末装置２０宛てに送信する（ステップＳｂ１３３）。ここにおいて、ＡＳＰサーバ１０は、アプリケーション管理サーバ５０から受信した問合せＩＤを含めた書込指示を送信する。端末装置２０は、ＡＳＰサーバ１０から書込指示を受信すると、クーポン管理アプリケーション２６１を実行し、アプリケーション管理サーバ５０宛てに書込指示に含まれていた問合せＩＤを送信する（ステップＳｂ１３４）。アプリケーション管理サーバ５０は、端末装置２０から受信した問合せＩＤに対応する処理依頼に従い、電子クーポンの書き込みに必要な（以下、「書込情報」という。）を端末装置２０宛てに送信する（ステップＳｂ１３５）。端末装置２０は、アプリケーション管理サーバ５０から受信した書込情報に基づいて、電子クーポンの書込処理を実行する（ステップＳｂ１３６）。
次に、端末装置２０は、書込処理の結果を示す結果通知を、アプリケーション管理サーバ５０宛てに送信する（ステップＳｂ１３７）。次に、端末装置２０は、メモリ領域２５１に電子クーポンを書き込む書込処理が終了した旨を示す終了通知を、ＡＳＰサーバ１０宛てに送信する（ステップＳｂ１３８）。
なお、端末装置２０は、ステップＳｂ１３３の処理に応じてクーポン管理アプリケーション２６１を実行してから、ステップＳｂ１３７の処理までをクーポン管理アプリケーション２６１に従って実行する。
ＡＳＰサーバ１０は、端末装置２０から送信された終了通知を受け付けた後、アプリケーション管理サーバ５０に問合せＩＤを送信して、終了通知の送信元の端末装置２０における書込処理の結果を問い合わせる（ステップＳｂ１３９）。アプリケーション管理サーバ５０は、ＡＳＰサーバ１０からの問い合わせに応じて、ＡＳＰサーバ１０宛てに書込処理の結果（つまり、結果通知）を送信する（ステップＳｂ１４０）。
ＡＳＰサーバ１０が端末装置２０に書込処理を行わせる場合に、アプリケーション管理サーバ５０経由で処理を行う理由は、電子クーポンに関する情報の改ざんなど不正に情報が書き換えられるのを防ぐためである。
ＡＳＰサーバ１０は、１ユーザあたりの提供制限枚数が設定されていない電子クーポンを提供する場合には、ステップＳｂ１０の端末ＩＤ要否判定処理の後、ステップＳｂ１１，Ｓｂ１２の処理をスキップして、図３６の手順で端末装置２０に書込処理を行わせる。
ＡＳＰサーバ１０は、ステップＳｂ１４０の結果通知に応じて書込処理が成功したと判定すると、実行された書込処理に応じて保有状況管理テーブル１３７を更新する（図２９のステップＳｂ１４）。ここでは、ＡＳＰサーバ１０は、新たに提供した電子クーポンの数を取得済み未利用枚数に加算する。
以上説明した実施形態によれば、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６にユーザＩＤと端末ＩＤとを対応付けて格納した後、対応付けの有効期限を経過するとこの対応付けを無効にする。これにより、端末装置２０のユーザに複数のユーザＩＤが割り当てられた場合であっても、電子クーポンが制限枚数を超えて利用される可能性を抑えることができる。また、ＡＳＰサーバ１０でこの対応付けを無効にする構成は、ＡＳＰサーバ１０が有効期限の経過後か否かを判定することで実現される。よって、このような仕組みを実現するために大規模なシステムの改修を行わなくてもよいし、ユーザの申し出により対応付けを無効にする手続きを人為的に行う場合の手間も生じない。
また、本実施形態では、ＡＳＰサーバ１０は、１ユーザあたりの提供制限枚数が設定された電子クーポンを提供する場合には、端末ＩＤの読み取りを指示し、１ユーザあたりの提供制限枚数が設定されていない電子クーポンを提供する場合には、端末ＩＤの読み取りを指示しない。これにより、ＡＳＰサーバ１０が１ユーザあたりの提供制限枚数が設定されていない電子クーポンを提供する場合には、電子クーポンの管理において不要である端末ＩＤ通知処理（つまり、図３１に示す処理）を省略できるので、いつでも端末ＩＤの読取処理を行う場合に比べて、ユーザが電子クーポンの取得を要求したときから、端末装置２０に電子クーポンを提供するまでの時間を短くすることができる。
更には、通信システム１において、ＡＳＰサーバ１０とアプリケーション管理サーバ５０とは独立したサーバ装置で実現されていて、クーポン管理アプリケーション２６１はＡＳＰサーバ１０がないと動作しないようになっている。これは、端末装置２０において、クーポン管理アプリケーション２６１が不正に利用されることを防ぐ目的としていることにもよる。具体的には、ＡＳＰサーバ１０がアプリケーション管理サーバ５０に対し署名通信で処理依頼を行った場合にしか、端末装置２０ではＩＣチップ２５から端末ＩＤを読み出したり、ＩＣチップ２５に電子クーポンを書き込んだりしないから、クーポン管理アプリケーション２６１の不正利用を防ぐことができる。
４．第２実施形態の変形例
本発明は、上述した実施形態と異なる形態で実施することが可能である。本発明は、例えば、以下のような形態で実施することも可能である。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
（変形例１）
ＡＳＰサーバ１０は、端末装置２０から取得したユーザＩＤと異なるユーザＩＤが端末ＩＤに対応付けてユーザ管理テーブル１３６に記憶されている場合、有効期限前であれば、電子クーポンを提供しなかった。これに代えて、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６において、端末装置２０から取得したユーザＩＤと異なるユーザＩＤが端末ＩＤに対応付けている場合にも、電子クーポンを提供してもよい。この場合、ＡＳＰサーバ１０は、ステップＳｂ１２６の処理の後のステップＳｂ１２７の処理では、エラー通知を行うとともに、ユーザの指示に応じて、ユーザ管理テーブル１３６で端末ＩＤに対応付けられているユーザＩＤのユーザに対して、電子クーポンを提供するための処理を実行すればよい。この場合にも、ＡＳＰサーバ１０は、ステップＳｂ１４で電子クーポンを提供する処理に応じて保有状況管理テーブル１３７を更新するが、ユーザ管理テーブル１３６における端末ＩＤとユーザＩＤとの対応付けを変更しないようにする。
この構成であれば、ユーザ管理テーブル１３６における対応付けに含まれるユーザＩＤと異なるユーザＩＤであっても、ＡＳＰサーバ１０は電子クーポンを提供できるので、ユーザは電子クーポンを取得しやすくなるとともに、上述した実施形態と同様、１ユーザあたりの提供制限枚数の範囲内で電子クーポンを提供することが可能である。
（変形例２）
上述した実施形態において、ＡＳＰサーバ１０は、会員登録したユーザに対して電子クーポンを提供していたが、会員登録しないユーザに電子クーポンを提供するものであってもよい。この場合も、ＡＳＰサーバ１０は、電子クーポンを新たに提供する場合には端末ＩＤとユーザＩＤとを取得して、上記実施形態と同等の手順で処理を実行すればよい。ＡＳＰサーバ１０が会員登録に関する処理を行わないで、端末装置２０のユーザにユーザＩＤを割り当てる構成として、例えば、以下の構成例１及び構成例２がある。
まず、構成例１を説明する。
構成例１では、通信システム１においてステップＳｂ１〜Ｓｂ３の処理を省略し、端末装置２０はステップＳｂ４の処理において、ユーザＩＤを含まないページアクセス要求をＡＳＰサーバ１０宛てに送信する。ＡＳＰサーバ１０は、ページアクセス要求を受信すると、上記ステップＳｂ５及びＳｂ６に相当する処理を行わず、ステップＳｂ７のユーザ認証に代えてユーザＩＤを新たに発行して取得する処理を行う。そして、ＡＳＰサーバ１０は、発行したユーザＩＤをユーザ管理テーブル１３６に書き込む。そして、ＡＳＰサーバ１０は、ステップＳｂ８の処理に代えて、端末装置２０のクッキーを用いてユーザＩＤを記憶させるための処理を行う。ステップＳｂ９以降の処理は、上述した実施形態と同じでよい。
次に、構成例２を説明する。
構成例２でも、通信システム１においてステップＳｂ１〜Ｓｂ３を省略し、端末装置２０はステップＳｂ４の処理において、ユーザＩＤを含まないページアクセス要求をＡＳＰサーバ１０宛てに送信する。ＡＳＰサーバ１０は、ページアクセス要求を受信すると、ステップＳｂ５〜Ｓｂ８に相当する処理を実行しないで、図３０に示すクーポン取得画面を端末装置２０に表示させる。端末装置２０は、クーポン取得画面を表示した後、ステップＳｂ９に相当する処理を実行して、クーポン取得要求をＡＳＰサーバ１０宛てに送信する。
なお、ここにおいては、ＡＳＰサーバ１０は、保有状況管理テーブル１３７に基づいて各ユーザ向けのクーポン取得画面を表示させることができないので、例えば設定可能な取得枚数の上限を１ユーザあたりの提供制限枚数とするなど、複数ユーザで共通のクーポン取得画面を表示させる。
次に、ＡＳＰサーバ１０は、ステップＳｂ１０の処理で、無条件に端末ＩＤ通知処理の実行が必要と判断する。そして、ＡＳＰサーバ１０は、ステップＳｂ１１の端末ＩＤ通知処理により端末ＩＤを取得すると、ユーザ管理テーブル１３６を参照して、取得した端末ＩＤに対応付けられたユーザＩＤの有無を確認する。ＡＳＰサーバ１０は、端末ＩＤに対応付けられたユーザＩＤがない場合には、構成例１と同様にして、ユーザＩＤを新たに発行して取得する処理を行う。そして、ＡＳＰサーバ１０は、発行したユーザＩＤを、端末ＩＤ通知処理により取得した端末ＩＤとを対応付けてユーザ管理テーブル１３６に書き込む。また、ＡＳＰサーバ１０は、クッキーを用いて端末装置２０にユーザＩＤを記憶させるための処理を行う。そして、ＡＳＰサーバ１０は、ステップＳｂ１２のクーポン提供判定処理を行うこととなる。
一方、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６において、取得した端末ＩＤに対応付けられたユーザＩＤがある場合には、上記変形例１と同様に、ＡＳＰサーバ１０は、ユーザ管理テーブル１３６を参照して、端末ＩＤ通知処理で取得した端末ＩＤに対応付けられているユーザＩＤを取得し、取得したユーザＩＤが示すユーザに対して電子クーポンを提供するための処理を実行する。すなわち、ＡＳＰサーバ１０は、ステップＳｂ１４の処理で電子クーポンを提供する処理に応じて保有状況管理テーブル１３７を更新するが、ユーザ管理テーブル１３６における端末ＩＤとユーザＩＤとの対応付けを変更しない。
（変形例３）
上述した実施形態において、ＡＳＰサーバ１０は、利用可能期間が設定された電子クーポンについてはその終了時期を有効期限にしていたが、利用可能期間が設定されていない電子クーポン同様、電子クーポンを提供する処理を行ってから予め決められた期間が経過したときを有効期限にしてもよい。このようにすれば、端末装置２０のユーザは、利用可能期間が設定された電子クーポンについて、その利用可能期間内に電子クーポンを取得することが可能となる。
また、ＡＳＰサーバ１０が端末ＩＤとユーザＩＤとの対応付けを無効にする条件は前掲の条件に限らず、永続的にこの対応付けが有効であることを回避できる条件であれば、他の条件を適用することもできる。
（変形例４）
上述した実施形態において、ＡＳＰサーバ１０は、１ユーザあたりの提供制限枚数が設定されている電子クーポンを提供する場合には、端末装置２０に端末ＩＤの読み取りを指示し、１ユーザあたりの提供制限枚数が設定されていない電子クーポンを提供する場合には、端末装置２０に端末ＩＤの読み取りを指示しなかったが、いずれの電子クーポンを提供する場合にも読み取りを指示してもよい。
また、端末ＩＤは、ＩＣチップ２５に記憶される端末ＩＤなくてもよく、例えば端末装置２０を個体識別できる偽装困難な他の情報であってもよい。例えば、本発明の端末ＩＤは、通信事業者で把握される契約情報に含まれる電話番号等の情報であってもよい。また、ユーザＩＤは、ＡＳＰサーバ１０によって割り当てられるものでなくてもよい。
（変形例５）
また、ＡＳＰサーバ１０が提供する電子クーポンはＩＣチップ２５での書込処理によりメモリ領域２５１に記憶され、リーダ／ライタに読み取られて利用されるものでなくてもよい。例えば、端末装置２０が提供された電子クーポンを意味する画像をＵＩ部２４に表示させ、店舗の従業員がＰＯＳ（Point of sale）端末を操作して電子クーポンを利用させてもよい。この場合、ＡＳＰサーバ１０は、電子クーポンを意味する画像を表示させるための情報を端末装置２０に送信する処理を、電子クーポンを提供する処理として実行することになる。
（変形例６）
上述した実施形態の通信システム１では、電子クーポンの提供又は利用可能な最小単位を「枚」とし、提供又は利用される電子クーポンの数（単位数）を「枚数」とした電子クーポンを扱っていた。これに対し、電子クーポンの提供又は利用可能な最小単位となる数（すう）はこれに限らず、例えば、電子クーポンの提供又は利用可能な最小単位を「円」や「ドル」等の貨幣の単位としてもよい。この場合であっても、上述した実施形態の電子クーポンの「枚数」を、「円」や「ドル」等の貨幣の単位に置き換えればよいだけである。また、電子クーポンの提供又は利用可能な最小単位となる数は、「ポイント」（点）や「回数」（利用回数）等であってもよい。
また、ＡＳＰサーバ１０は、提供される電子クーポンが１種類である場合において、１ユーザあたりの提供制限枚数が１枚であるときのように、電子クーポンを提供済みか否かのみによって各ユーザの電子クーポンの保有状況を管理できるのであれば、保有状況管理テーブル１３７に相当するデータを記憶しない構成であってもよい。このように本発明は、保有状況管理テーブル１３７に相当するデータを記憶することを必須とするものではない。
（変形例７）
上述した実施形態においてＡＳＰサーバ１０が実行していたユーザ認証に関する処理ステップＳｂ４〜Ｓｂ７の処理を、以下の処理に置き換えてもよい。この変形例では、ＡＳＰサーバ１０とは別途設けられた外部サーバ（以下、「認証サーバ」という。）が、端末装置２０から取得したユーザＩＤを用いてユーザ認証を行う。認証サーバは、ユーザ認証に成功すると、認証サーバは、ユーザ認証に成功した後に、ＡＳＰサーバ１０にワンタイムパスワードの発行を依頼する。このとき、認証サーバは、ワンタイムパスワードの発行依頼とともに、ユーザ認証に用いたユーザＩＤをＡＳＰサーバ１０に送信するものとする。ＡＳＰサーバ１０は、ワンタイムパスワードの発行依頼を受け付けると、その依頼元である認証サーバの正当性を、送信元ＩＰアドレスや電子署名等により確認する。ＡＳＰサーバ１０は、依頼元が正当であると判断した場合は、ワンタイムパスワードを発行し、発行したワンタイムパスワードと、発行依頼とともに受信したユーザＩＤとを対応付けて記憶部１３に記憶させる。そして、ＡＳＰサーバ１０は、発行したワンタイムパスワードを認証サーバに通知する。そして、認証サーバは、ユーザ認証の成功後に端末装置２０に表示させるｗｅｂページに、ＡＳＰサーバ１０が提供するｗｅｂページのハイパーリンクを設定して表示させる。このとき認証サーバは、ＡＳＰサーバ１０から通知されたワンタイムパスワードをハイパーリンクに埋め込んでおくことにより、このワンタイムパスワードを端末装置２０に提供する。
なお、ＡＳＰサーバ１０は、発行したワンタイムパスワードに有効期限を設けておき、有効期限の経過後にはこのワンタイムパスワードを無効にする。
次に、端末装置２０においてユーザにより上記ハイパーリンクを選択する操作が行われると、端末装置２０はハイパーリンクに対応したｗｅｂページを表示させるためのページアクセス要求をＡＳＰサーバ１０宛てに送信する（ステップＳｂ４の処理に相当）。前述したように、ハイパーリンクにはワンタイムパスワードが埋め込まれているから、端末装置２０は、ワンタイムパスワードをページアクセス要求に含めて送信したことになる。ＡＳＰサーバ１０は、ページアクセス要求を受信すると、ページアクセス要求に含まれるワンタイムパスワードが記憶部１３に記憶され、かつ、このワンタイムパスワードが有効期限前であるか否かにより、ステップＳｂ７に相当するユーザ認証を行う。ＡＳＰサーバ１０は、ワンタイムパスワードが記憶部１３に記憶され、かつ、このワンタイムパスワードが有効期限前であると判定すると、記憶部１３においてこのワンタイムパスワードに対応付けられたユーザＩＤでユーザ認証に成功したものとし、以降、上述した実施形態と同様の手順でステップＳｂ８以降の処理を行う。
なお、ＡＳＰサーバ１０は、認証に成功したワンタイムパスワードについてはこれを無効にする。
この変形例によれば、認証サーバとＡＳＰサーバ１０とでやり取りされるワンタイムパスワードでユーザ認証が行われるので、上述した実施形態に比べて、第三者により不正な方法でユーザ認証が行われる可能性を抑えることができる。また、認証サーバにてユーザＩＤに基づくユーザ認証が行われていれば、端末装置２０がページアクセス要求を送信した後にＡＳＰサーバ１０はユーザＩＤに基づくユーザ認証を行う必要がない。これにより端末装置２０のユーザにしてみれば、端末装置２０でＡＳＰサーバ１０が提供するｗｅｂページが表示された後に、ユーザＩＤやパスワードを入力する操作を行う必要がなく、電子クーポンの取得時における操作負担が減る。
（変形例８）
また、本発明は、１ユーザあたりの提供制限枚数が設定されている電子クーポン（第１電子クーポン）を提供する場合には、端末装置２０に端末ＩＤの読み取りを指示し、１ユーザあたりの提供制限枚数が設定されていない電子クーポン（第２電子クーポン）を提供する場合には、端末装置２０に端末ＩＤの読み取りを指示しない構成としても特定可能である。よって、この発明では、ユーザ管理テーブル１３６におけるユーザＩＤ及び端末ＩＤの無効にする仕組みを有していなくてもよい。この発明であっても、１ユーザあたりの提供制限枚数が設定されていない電子クーポンを提供する場合には、電子クーポンの管理において不要である端末ＩＤ通知処理（つまり、図３１に示す処理）を省略できるので、いつでも端末ＩＤの読取処理を行う場合に比べて、端末装置２０に電子クーポンを提供するまでの時間を短くすることができる。
この発明のクーポン管理装置は、提供可能な数がユーザ毎に制限された第１電子クーポンを提供した端末装置を識別する端末ＩＤを記憶する記憶部と、前記第１電子クーポンを提供する場合には、前記端末装置が有するメモリ領域に記憶された前記端末ＩＤの読み出しを指示し、提供可能な数がユーザ毎に制限されていない第２電子クーポンを当該端末装置に提供する場合には、前記端末ＩＤの読み出しを指示しない読出指示部と、前記読出指示部により前記端末ＩＤの読み出しが指示された場合に、当該指示に従って前記メモリ領域から読み出された前記端末ＩＤを取得する取得部と、前記記憶部を参照して前記取得部が取得した端末ＩＤに基づいて前記電子クーポンを提供すると判定した場合に、前記提供可能な数を超えない範囲内で当該端末ＩＤが示す端末装置に前記第１電子クーポンを提供するための処理を実行する一方、前記読出指示部により前記端末ＩＤの読み出しが指示されなかった場合に、前記第２電子クーポンを前記端末装置に提供するための処理を実行する提供部とを備えることを特徴とする。
（変形例９）
上述した実施形態の通信システム１では、店舗管理サーバ３０と店舗端末４０とが別々の装置であったが、これらを一体化した装置が用いられてもよい。この一体化した装置として、例えば、リーダ／ライタ機能を有しているパーソナルコンピュータやスマートフォン、ＰＯＳ端末等がある。
また、ＡＳＰサーバ１０の制御部１１が実現する各機能は、複数のプログラムの組み合わせによって実現され、又は、複数のハードウェア資源の協働によって実現されうる。
また、本発明は、ＡＳＰサーバ１０が実行するプログラムやクーポン管理方法として把握することも可能である。
（変形例１０）
上記の実施形態では、ユーザ管理テーブル１３２において設定される端末ＩＤとユーザＩＤとの対応付けに有効期限が設定され、その有効期限が経過すると、当該対応付けは無効になる。そして、当該対応付けの変更（具体的には、ユーザＩＤの変更）が許可される（図３３のステップＳｂ１２２参照）。よって、端末装置２０のユーザが自身のユーザＩＤやパスワードを失念してしまい別のユーザＩＤを取得した場合であっても、元のユーザＩＤと端末ＩＤとの対応付けの有効期限が経過すれば、新たなユーザＩＤを用いて電子クーポンの提供を受けることができる。また、すでに別のユーザＩＤと対応付けられている端末装置２０の譲渡を受け、当該端末に機種変更する場合であっても、当該ユーザＩＤと端末ＩＤとの対応付けの有効期限が経過すれば、譲渡を受けたユーザは、自己のユーザＩＤを用いて電子クーポンの提供を受けることができる。
しかし、上記の実施形態の場合、新たに変更されたユーザＩＤと、当該ユーザＩＤと従来対応付けられていた端末ＩＤとの対応付けは、削除されずに残ってしまう。例えば、図２６に示される例において、端末ＩＤ「ａｂｃｄｅ００００２」に対して、新たにユーザＩＤ「ＵＩＤ０００１」が対応付けられることになった場合、当該ユーザＩＤ「ＵＩＤ０００１」と、従来当該ユーザＩＤと対応づけられていた端末ＩＤ「ａｂｃｄｅ００００１」との対応付けは、削除されずに残ってしまう。よって、本例においては、端末ＩＤ「ａｂｃｄｅ００００１」によって識別される端末装置２０を新たに取得したユーザは、当該端末ＩＤとユーザＩＤ「ＵＩＤ０００１」との対応付けの有効期限が経過するまでは、クーポンの提供を受けられなくなってしまう。
そこで、上記の実施形態において、ユーザＩＤの変更を行う場合に、変更後のユーザＩＤと、当該ユーザＩＤと従来対応づけられていた端末ＩＤとの対応付けを削除するようにしてもよい。より具体的には、上記の実施形態の図３３のステップＳｂ１２２の直前又は直後において、図２９のステップＳｂ７のユーザ認証に用いたユーザＩＤと、同図のステップＳｂ１１の端末ＩＤ通知処理で取得した端末ＩＤと異なるＩＤとがユーザ管理テーブル１３２において対応づけられているときに、当該ユーザＩＤと当該異なる端末ＩＤとの対応付けを削除するようにしてもよい。このような構成によれば、上記の例において端末ＩＤ「ａｂｃｄｅ００００１」によって識別される端末装置２０を新たに取得したユーザは、当該端末ＩＤとユーザＩＤ「ＵＩＤ０００１」との対応付けの有効期限が経過するのを待たずとも、クーポンの提供を受けることができる。
（変形例１１）
上記の第２実施形態は、上記の第１実施形態と組み合わせてもよい。具体的には、第１実施形態の図１０のステップＳａ１の処理の前に、第２実施形態の図２９のステップＳｂ１〜Ｓｂ８の処理を実行してもよい。
また、第１実施形態の図１０のステップＳａ１の処理の後であって、ステップＳａ２の処理の前に、第２実施形態の図２９のステップＳｂ１０〜Ｓｂ１２の処理を実行してもよい。この場合、第１実施形態に係るクーポン管理テーブル１３１において、「クーポンＩＤ」ごとに、第２実施形態に係るクーポン情報テーブル１３５と同様に、「１ユーザあたりの提供制限枚数」を対応付けるようにしてもよい。また、第１実施形態に係るＡＳＰサーバ１０の記憶部１３に、第２実施形態に係るユーザ管理テーブル１３６を記憶するようにしてもよい。また、第１実施形態に係るクーポン管理テーブル１３１において、「クーポンＩＤ」ごとに、第２実施形態に係るクーポン情報テーブル１３５と同様に、「利用可能期間（開始日時）」と「利用可能期間（終了日時）」とを対応付けるようにしてもよい。また、ステップＳｂ１２の処理を実行する際に、ＡＳＰサーバ１０は、第２実施形態に係る保有状況管理テーブル１３７に代えて、第１実施形態に係るユーザ管理テーブル１３２を参照するようにしてもよい。
１…通信システム、１０…ＡＳＰサーバ、１１…制御部、１１１…第１更新部、１１２…書込指示部、１１３…第２更新部、１１４…処理結果取得部、１１５…利用履歴取得部、１１６…第３更新部、１１７…読出指示部、１１８…取得部、１１９…提供部、１２０…書込部、１２…通信部、１３…記憶部、１３１…クーポン管理テーブル、１３２…ユーザ管理テーブル、１３３…トランザクション管理テーブル、１３４…保留リストテーブル、１３５…クーポン情報テーブル、１３６…ユーザ管理テーブル、１３７…保有状況管理テーブル、２０…端末装置、２１…制御部、２２…音声入出力部、２３…無線通信部、２４…ＵＩ部、２５…ＩＣチップ、２５１…メモリ領域、２６…記憶部、２６１…クーポン管理アプリケーション、３０…店舗管理サーバ、４０…店舗端末、４１…リーダ／ライタ、５０…アプリケーション管理サーバ。
本発明のサーバ装置において、前記第２更新部は、前記書込指示部の指示に応じた前記書込処理により他の電子クーポンに前記電子クーポンが上書きされた場合、当該他の電子クーポンの未利用数を当該他の電子クーポンの残数に加算して、当該未利用数をクリアするよう、前記第１記憶部を更新することが好ましい。
本発明のサーバ装置において、前記第１更新部は、前記電子クーポンの残数から減じた数を、前記書込処理の成功が未確定の電子クーポンの数である未確定数に設定して、前記第１記憶部に記憶させ、前記第２更新部は、前記書込処理の成功が確定した後、前記減じられた数である前記電子クーポンの未確定数を、前記電子クーポンの未利用数に設定し、当該未確定数をクリアすることが好ましい。
本発明のサーバ装置において、前記第２更新部は、前記第１の端末装置が前記指示に応じた前記書込処理に失敗した場合、前記未確定数を前記電子クーポンの残数に加算し、当該未確定数をクリアすることが好ましい。
本発明のサーバ装置において、前記第１記憶部は、前記第１の端末装置に対して新たに提供可能な電子クーポンの残数を記憶し、前記第１の端末装置が利用した前記電子クーポンの利用数を含む利用履歴を取得する利用履歴取得部と、前記利用履歴取得部が取得した利用履歴に基づいて、前記利用した電子クーポンの前記未利用数、及び前記第１の端末装置に対する残数のそれぞれから、前記利用数を減じるよう、前記第１記憶部を更新する第３更新部とを備えることが好ましい。
本発明のサーバ装置において、前記メモリ領域に前記電子クーポンを書き込む前記書込処理が終了した旨の通知を受け付けた後、前記第１の端末装置から前記書込処理の結果を取得する管理サーバに問い合わせて当該結果を取得する処理結果取得部を備え、前記第２更新部は、前記処理結果取得部により取得された前記結果に応じて、前記書込処理の成功が確定したか否かを判断することが好ましい。

Claims (22)

  1. 端末装置に提供されて当該端末装置において利用される各電子クーポンについて、前記端末装置に提供された電子クーポンの未利用数と、前記端末装置に対して新たに提供可能な電子クーポンの残数を記憶する第１記憶部と、
    前記電子クーポンが提供された端末装置を識別する端末ＩＤに、当該端末装置のユーザを識別する１のユーザＩＤを対応付けて記憶する第２記憶部と、
    前記電子クーポンを第１の端末装置に新たに提供する場合に、当該第１の端末装置の端末ＩＤと当該第１の端末装置のユーザのユーザＩＤとを取得する取得部と、
    前記電子クーポンの残数から、前記第１の端末装置に提供される前記電子クーポンの数を減じるよう、前記第１記憶部を更新する第１更新部と、
    前記第１更新部により減じられた数の電子クーポンについて前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する書込指示部と、
    前記書込指示部により前記書込処理の実行が指示される場合、前記第２記憶部において前記取得した端末ＩＤに前記取得したユーザＩＤを対応付ける書込部と、
    前記書込指示部の指示に応じた前記書込処理の成功が確定した後、前記減じられた数を前記電子クーポンの未利用数に設定するよう、前記第１記憶部を更新する第２更新部と
    を備えることを特徴とするサーバ装置。
  2. 前記第２更新部は、前記書込指示部の指示に応じた前記書込処理により他の電子クーポンに前記電子クーポンが上書きされた場合、当該他の電子クーポンの未利用数を当該他の電子クーポンの残数に加算して、当該未利用数をクリアするよう、前記第１記憶部を更新する
    ことを特徴とする請求項１に記載のサーバ装置。
  3. 前記第１更新部は、
    前記第１電子クーポンの残数から減じた数を、前記書込処理の成功が未確定の電子クーポンの数である未確定数に設定して、前記第１記憶部に記憶させ、
    前記第２更新部は、
    前記書込処理の成功が確定した後、前記減じられた数である前記電子クーポンの未確定数を、前記電子クーポンの未利用数に設定し、当該未確定数をクリアする
    ことを特徴とする請求項１又は２に記載のサーバ装置。
  4. 前記第２更新部は、
    前記第１の端末装置が前記指示に応じた前記書込処理に失敗した場合、前記未確定数を前記電子クーポンの残数に加算し、当該未確定数をクリアする
    ことを特徴とする請求項３に記載のサーバ装置。
  5. 前記第１記憶部は、一の端末装置に対して新たに提供可能な電子クーポンの残数を記憶し、
    前記第１の端末装置が利用した前記電子クーポンの利用数を含む利用履歴を取得する利用履歴取得部と、
    前記利用履歴取得部が取得した利用履歴に基づいて、前記利用した電子クーポンの前記未利用数、及び前記一の端末装置に対する残数のそれぞれから、前記利用数を減じるよう、前記第１記憶部を更新する第３更新部と
    を備えることを特徴とする請求項１から４のいずれか１項に記載のサーバ装置。
  6. 前記メモリ領域に前記電子クーポンを書き込む前記書込処理が終了した旨の通知を受け付けた後、前記第１の端末装置から前記書込処理の結果を取得する管理サーバに問い合わせて当該結果を取得する処理結果取得部を備え、
    前記第２更新部は、
    前記処理結果取得部により取得された前記結果に応じて、前記書込処理の成功が確定したか否かを判断する
    ことを特徴とする請求項１から５のいずれか１項に記載のサーバ装置。
  7. 前記書込指示部は、前記第２記憶部において、前記取得部が取得した端末ＩＤに前記取得部が取得したユーザＩＤと異なるユーザＩＤが対応付けられていない場合、又は、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に予め決められた条件を満たすときには、前記指示を行う
    -ことを特徴とする請求項１から６のいずれか１項に記載のサーバ装置。
  8. 前記書込指示部は、
    前記第２記憶部において、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に、前記条件を満たさないときには、前記指示を行わない
    ことを特徴とする請求項７に記載のサーバ装置。
  9. 前記書込指示部は、
    前記第２記憶部において、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合には、前記指示を行い、
    前記書込部は、
    前記条件を満たさないときに前記書込指示部により前記指示が行われた場合には、前記第２記憶部において前記取得した端末ＩＤに対応付けられたユーザＩＤを変更しない
    ことを特徴とする請求項７に記載のサーバ装置。
  10. 前記取得部は、
    前記第１の端末装置から前記端末ＩＤを取得したが前記ユーザＩＤを取得しなかった場合に、前記第２記憶部において当該端末ＩＤにいずれかのユーザＩＤが対応付けられているときには当該ユーザＩＤを取得し、前記第２記憶部において当該端末ＩＤがいずれのユーザＩＤとも対応付けられていないときには新たにユーザＩＤを発行して取得し、
    前記書込部は、
    前記書込指示部により前記指示が行われた場合に、前記取得部が前記第２記憶部からユーザＩＤを取得していたときには、前記取得した端末ＩＤに対応付けられたユーザＩＤを変更せず、新たにユーザＩＤを発行して取得していたときには、当該ユーザＩＤを前記取得した端末ＩＤに対応付けて前記第２記憶部に書き込む
    ことを特徴とする請求項７から９のいずれか１項に記載のサーバ装置。
  11. 前記書込指示部は、
    前記指示を行ってから予め決められた期間が経過したことを前記条件とする
    ことを特徴とする請求項７から１０のいずれか１項に記載のサーバ装置。
  12. 前記書込指示部は、
    前記電子クーポンの利用可能期間が経過したことを前記条件とする
    ことを特徴とする請求項７から１１のいずれか１項に記載のサーバ装置。
  13. 前記書込指示部は、
    複数種類の電子クーポンについて、前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示した場合、終了時期が最も後である電子クーポンの利用可能期間が経過したことを前記条件とする
    ことを特徴とする請求項１２に記載のサーバ装置。
  14. 前記端末ＩＤは、当該端末ＩＤが示す端末装置が有するメモリ領域に記憶され、
    提供可能な数がユーザ毎に制限された電子クーポンを提供する場合には、前記メモリ領域からの前記端末ＩＤの読み出しを指示し、提供可能な数がユーザ毎に制限されていない電子クーポンを当該第１の端末装置に提供する場合には、前記端末ＩＤの読み出しを指示しない読出指示部を備え、
    前記取得部は、
    前記読出指示部により前記端末ＩＤの読み出しが指示された場合に、当該指示に従って前記メモリ領域から読み出された前記端末ＩＤを取得し、
    前記書込指示部は、
    前記読出指示部により前記端末ＩＤの読み出しが指示されなかった場合に、前記提供可能な数がユーザ毎に制限されていない電子クーポンを前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する
    ことを特徴とする請求項７から１３のいずれか１項に記載のサーバ装置。
  15. 前記第２記憶部において、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられており、かつ、前記条件を満たす場合に、前記第２記憶部において、前記取得したユーザＩＤと、前記取得した端末ＩＤと異なる端末ＩＤとが対応付けられているときに、当該取得したユーザＩＤと当該異なる端末ＩＤとの対応付けを削除する削除部をさらに備えることを特徴とする請求項７から１４のいずれか１項に記載のサーバ装置。
  16. 端末装置に提供されて当該端末装置において利用される各電子クーポンについて、前記端末装置に提供された電子クーポンの未利用数と、前記端末装置に対して新たに提供可能な電子クーポンの残数を記憶する第１記憶部と、
    前記電子クーポンが提供された端末装置を識別する端末ＩＤに、当該端末装置のユーザを識別する１のユーザＩＤを対応付けて記憶する第２記憶部と
    を備えるサーバ装置のクーポン管理方法であって、
    前記電子クーポンを第１の端末装置に新たに提供する場合に、当該第１の端末装置の端末ＩＤと当該第１の端末装置のユーザのユーザＩＤとを取得する取得ステップと、
    前記電子クーポンの残数から、前記第１の端末装置に提供される前記電子クーポンの数を減じるよう、前記第１記憶部を更新する第１更新ステップと、
    前記第１更新ステップにおいて減じられた数の電子クーポンについて前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する書込指示ステップと、
    前記書込指示ステップにおいて前記書込処理の実行が指示される場合、前記第２記憶部において前記取得した端末ＩＤに前記取得したユーザＩＤを対応付ける書込ステップと、
    前記書込指示ステップにおける指示に応じた前記書込処理の成功が確定した後、前記減じられた数を前記電子クーポンの未利用数に設定するよう、前記第１記憶部を更新する第２更新ステップと
    を有することを特徴とするクーポン管理方法。
  17. 前記第１記憶部は、端末装置が有するメモリ領域への書込処理の成功が確定した電子クーポンの未利用数を、端末装置に提供された電子クーポンの未利用数として記憶し、
    前記第２更新ステップは、前記書込指示部の指示に応じた前記書込処理により他の電子クーポンに前記電子クーポンが上書きされた場合、当該他の電子クーポンの未利用数を当該他の電子クーポンの残数に加算して、当該未利用数をクリアするよう、前記第１記憶部を更新する
    ことを特徴とする請求項１６に記載のクーポン管理方法。
  18. 前記書込指示ステップは、前記第２記憶部において、前記取得ステップで取得した端末ＩＤに前記取得ステップで取得したユーザＩＤと異なるユーザＩＤが対応付けられていない場合、又は、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に予め決められた条件を満たすときには、前記指示を行うことを特徴とする請求項１６又は１７に記載のクーポン管理方法。
  19. サーバ装置と端末装置とを備える通信システムであって、
    前記サーバ装置は、
    端末装置に提供されて当該端末装置において利用される各電子クーポンについて、前記端末装置に提供された電子クーポンの未利用数と、前記端末装置に対して新たに提供可能な電子クーポンの残数を記憶する第１記憶部と、
    前記電子クーポンが提供された端末装置を識別する端末ＩＤに、当該端末装置のユーザを識別する１のユーザＩＤを対応付けて記憶する第２記憶部と、
    前記電子クーポンを第１の端末装置に新たに提供する場合に、当該第１の端末装置の端末ＩＤと当該第１の端末装置のユーザのユーザＩＤとを取得する取得部と、
    前記電子クーポンの残数から、前記第１の端末装置に提供される前記電子クーポンの数を減じるよう、前記第１記憶部を更新する第１更新部と、
    前記第１更新部により減じられた数の電子クーポンについて前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する書込指示部と、
    前記書込指示部により前記書込処理の実行が指示される場合、前記第２記憶部において前記取得した端末ＩＤに前記取得したユーザＩＤを対応付ける書込部と、
    前記書込指示部の指示に応じた前記書込処理の成功が確定した後、前記減じられた数を前記電子クーポンの未利用数に設定するよう、前記第１記憶部を更新する第２更新部と
    を備え、
    前記端末装置は、
    前記書込指示部の指示に従った前記書込処理により前記未利用数の電子クーポンを前記メモリ領域に書き込み、当該書込処理を終了したことを前記サーバ装置に通知する
    ことを特徴とする通信システム。
  20. 前記第１記憶部は、端末装置が有するメモリ領域への書込処理の成功が確定した電子クーポンの未利用数を、端末装置に提供された電子クーポンの未利用数として記憶し、
    前記第２更新部は、前記書込指示部の指示に応じた前記書込処理により他の電子クーポンに前記電子クーポンが上書きされた場合、当該他の電子クーポンの未利用数を当該他の電子クーポンの残数に加算して、当該未利用数をクリアするよう、前記第１記憶部を更新することを特徴とする請求項１９に記載の通信システム。
  21. 端末装置に提供されて当該端末装置において利用される各電子クーポンについて、前記端末装置に提供された電子クーポンの未利用数と、前記端末装置に対して新たに提供可能な電子クーポンの残数を記憶する第１記憶部と、
    前記電子クーポンが提供された端末装置を識別する端末ＩＤに、当該端末装置のユーザを識別する１のユーザＩＤを対応付けて記憶する第２記憶部と
    を備えるコンピュータに、
    前記電子クーポンを第１の端末装置に新たに提供する場合に、当該第１の端末装置の端末ＩＤと当該第１の端末装置のユーザのユーザＩＤとを取得する取得ステップと、
    前記電子クーポンの残数から、前記第１の端末装置に提供される前記電子クーポンの数を減じるよう、前記第１記憶部を更新する第１更新ステップと、
    前記第１更新ステップにおいて減じられた数の電子クーポンについて前記第１の端末装置が有するメモリ領域への書込処理を実行するよう、前記第１の端末装置に指示する書込指示ステップと、
    前記書込指示ステップにおいて前記書込処理の実行が指示される場合、前記第２記憶部において前記取得した端末ＩＤに前記取得したユーザＩＤを対応付ける書込ステップと、
    前記書込指示ステップにおける指示に応じた前記書込処理の成功が確定した後、前記減じられた数を前記電子クーポンの未利用数に設定するよう、前記第１記憶部を更新する第２更新ステップと
    を実行させるためのプログラム。
  22. 前記書込指示ステップは、前記第２記憶部において、前記取得ステップで取得した端末ＩＤに前記取得ステップで取得したユーザＩＤと異なるユーザＩＤが対応付けられていない場合、又は、前記取得した端末ＩＤに前記取得したユーザＩＤと異なるユーザＩＤが対応付けられている場合に予め決められた条件を満たすときには、前記指示を行うことを特徴とする請求項２１に記載のプログラム。
JP2013536308A 2011-09-30 2012-09-25 サーバ装置、クーポン管理方法、通信システム及びプログラム Expired - Fee Related JP5661191B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013536308A JP5661191B2 (ja) 2011-09-30 2012-09-25 サーバ装置、クーポン管理方法、通信システム及びプログラム

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2011218630 2011-09-30
JP2011218630 2011-09-30
JP2012054658 2012-03-12
JP2012054658 2012-03-12
JP2013536308A JP5661191B2 (ja) 2011-09-30 2012-09-25 サーバ装置、クーポン管理方法、通信システム及びプログラム
PCT/JP2012/074597 WO2013047535A1 (ja) 2011-09-30 2012-09-25 サーバ装置、クーポン管理方法、通信システム及びプログラム

Publications (2)

Publication Number Publication Date
JP5661191B2 JP5661191B2 (ja) 2015-01-28
JPWO2013047535A1 true JPWO2013047535A1 (ja) 2015-03-26

Family

ID=47995567

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013536308A Expired - Fee Related JP5661191B2 (ja) 2011-09-30 2012-09-25 サーバ装置、クーポン管理方法、通信システム及びプログラム

Country Status (2)

Country Link
JP (1) JP5661191B2 (ja)
WO (1) WO2013047535A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7254995B1 (ja) 2022-05-12 2023-04-10 Kddi株式会社 データ処理装置、データ処理システム、データ処理方法及びプログラム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4738110B2 (ja) * 2005-09-08 2011-08-03 東芝テック株式会社 販売促進システム、販売促進方法および販売促進プログラム
JP5050581B2 (ja) * 2007-03-12 2012-10-17 大日本印刷株式会社 非接触ｉｃチップに記憶された電子クーポンを利用する方法、サーバおよびコンピュータプログラム
JP2009169766A (ja) * 2008-01-17 2009-07-30 Fuji Electric Holdings Co Ltd 電子クーポンシステム、そのサーバ、クーポン発行端末、クーポン利用・回収端末、プログラム

Also Published As

Publication number Publication date
JP5661191B2 (ja) 2015-01-28
WO2013047535A1 (ja) 2013-04-04

Similar Documents

Publication Publication Date Title
US10789578B2 (en) Network system, and server apparatus, server apparatus control method, and computer readable storage medium for use in same
JP5664378B2 (ja) 仮想ポイントカードシステム、仮想ポイントカードの管理方法、ポイントカード管理端末、携帯端末、ポイントカード管理プログラム、及びポイントカード利用プログラム
JP6655147B2 (ja) 決済システム
JP6849444B2 (ja) 認証装置、認証システム、認証方法及びプログラム
JP2019067432A (ja) 認証支援装置、認証支援方法、およびプログラム
JP5714712B2 (ja) サーバ装置、クーポン管理方法及び通信システム
JP2011209861A (ja) 取引方法及び取引システム
US9331964B2 (en) System, method, and apparatus for using a virtual bucket to transfer electronic data
WO2014155664A1 (ja) Ｉｄ管理装置、ｉｄ管理方法、およびｉｄ管理プログラム
JP5731883B2 (ja) 端末設置システム及び端末設置方法
KR101672324B1 (ko) 사용자의 간편한 복합 결제를 지원하는 모바일 결제 서비스 제공 시스템 및 방법
JP2021082359A (ja) 認証装置、認証システム、認証方法及びプログラム
JP2016181171A (ja) 情報処理装置、システム、方法およびプログラム
JPWO2015198874A1 (ja) 薬歴情報管理装置および方法、登録端末装置および方法、並びにプログラム
JP5661191B2 (ja) サーバ装置、クーポン管理方法、通信システム及びプログラム
JP6781483B2 (ja) 料金決済システム
JP2021077336A (ja) 顧客情報管理サーバ及び顧客情報の管理方法
JP2006209183A (ja) 名刺情報管理サーバと名刺情報管理端末と名刺情報管理プログラムと記録媒体と名刺情報管理方法
JP4800126B2 (ja) 属性情報検証方法、失効情報生成装置、サービス提供元装置、及び属性情報検証システム
JP5941865B2 (ja) サーバ装置、電子クーポン管理方法、通信システム及びプログラム
JP7484594B2 (ja) 顧客情報管理サーバ、顧客情報管理方法、及びプログラム
KR101705404B1 (ko) 카드 접촉을 통한 카드 사용 등록 시스템 및 이의 실행 방법
JP7402294B1 (ja) 情報処理システム、情報処理方法、及び情報処理プログラム
JP5686865B2 (ja) サーバ、サービス情報送信方法、及びプログラム
JP2022089435A (ja) 通信制御装置、通信制御システム、通信制御方法、及び、通信制御プログラム

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20141111

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141202

R150 Certificate of patent or registration of utility model

Ref document number: 5661191

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees