説明

チケット発行システム

【課題】 チケットの購入者と利用者との同一性を確保してダフ屋行為などの不当転売を防ぎつつ、偽造防止も図る。
【解決手段】 携帯電話などの利用者端末装置から、コンサートなどの利用対象を特定する利用対象特定情報と、利用者本人の顔写真画像と、を伴う発券要求((図(a) )を発券管理サーバへ送信させる。発券管理サーバでは、この発券要求に応じて、所定の認証コードを発生し、発生した認証コードを顔写真画像に電子透かしとして埋め込んで認証付顔写真画像51を作成し(図(b) )、デジタルデータの形式の電子チケット50(図(c) )を利用者端末装置へ返信する。利用者がコンサート会場でチケット50を提示すると、利用施設端末装置により認証付顔写真画像51に埋め込まれた認証コードが読み出され、真正なコードであることが確認される。また、改札係員により、顔写真を用いた本人確認が目視で行われる。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、チケット発行システムに関し、特に、利用者の本人確認を行うことができ、偽造防止機能を有する電子チケットもしくは物理的チケットを発行するためのシステムに関する。また、このシステムにより発行されたチケットをキャンセルしたり、再発行したりする技術に関する。
【背景技術】
【0002】
コンサートやスポーツ観戦などのイベントでは、通常、主催者が予めチケットの発行を行い、イベント会場においてチケットの提示を求める入場方法が採られている。列車や航空機の運航においても、乗車券や航空券といったチケットを予め発行しておき、搭乗前に改札を行うのが一般的である。また、チケットは、イベントの開催日時や場所を提示したり、交通機関の発着日時や時間を提示したりする役割も担っている。
【0003】
最近は、オンラインでチケットの申し込みを行うことも可能であり、自宅のパソコン、携帯電話、コンビニエンスストアなどの店舗端末からチケットの購入申し込みを行うと、郵送もしくは店頭引き換えといった形態で、チケットの入手が可能である。また、物理的なチケットを発行する代わりに、電子チケットの発行を行うシステムも提案されており、利用者は、デジタルデータの形式で発行された電子チケットを、携帯電話などの端末装置を用いてネットワーク経由で受信することもできる。
【0004】
たとえば、下記の特許文献1には、携帯電話に装着されたICカードに、電子チケットを格納しておき、イベント会場の入り口でこれをチェックするシステムが開示されている。また、特許文献2には、このような電子チケットの信頼性を高めるために、電子チケットのデータに電子透かしを埋め込む技術が開示されており、特許文献3には、チケット利用者の指紋や声紋などの生体情報を利用して認証を行う技術が開示されている。
【特許文献1】特開2004−185529号公報
【特許文献2】特開2004−078429号公報
【特許文献3】特開2004−295197号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
人気のあるコンサートやスポーツイベントでは、チケットの購入希望者が殺到し、入手が困難なプレミアチケットともなると、極めて高額で取引される例も少なくない。これは、夏期や年末という繁忙期における乗車券や航空券といったチケットについても同様である。このため、このような状況につけ込んだ悪徳業者が、チケットを意図的に買い占めて高額で販売することにより不当な利潤をあげる、いわゆるダフ屋行為を行うことが社会問題となってきており、更には、チケットの偽造という犯罪行為に至ることもある。
【0006】
一方、従来のチケット発行システムでは、一度発行したチケットをキャンセルしたり、再発行したりする処理を円滑に行うことができなかったため、チケットの購入者は、未使用チケットに対する払い戻しを受けられなかったり、チケット紛失による損害を被ったりする弊害があった。特に、コンサートやスポーツ観戦などのイベントでは、チケットのキャンセルや再発行には全く応じない例も少なくない。
【0007】
そこで本発明は、チケット購入者とチケット利用者との同一性を確保しつつ、偽造防止が可能なチケット発行システムを提供することを目的とし、また、チケットのキャンセルや再発行を容易に行うことができるチケット発行システムを提供することを目的とする。
【課題を解決するための手段】
【0008】
(1) 本発明の第1の態様は、図1の実施形態にその一例が示されているとおり、チケット発行システムにおいて、
チケットの利用対象を特定する利用対象特定情報と、チケットを利用する利用者本人の顔写真画像と、を伴う発券要求が利用者端末装置から送信されてきたときに、これを受信する発券要求受信部と、
この発券要求に応じて、利用対象特定情報で特定される利用対象についてチケットの供給が可能か否かを確認するチケット供給確認部と、
チケット供給確認部によりチケットの供給が可能であることが確認されたときに、発券要求に応じて所定の認証コードを発生し、発生した認証コードを顔写真画像に電子透かしとして埋め込む処理を行い、認証コードが埋め込まれた認証付顔写真画像を作成し、利用対象特定情報と認証付顔写真画像とを含むチケット情報を生成して発券処理を行う発券処理部と、
発券処理部が発生した認証コードを記録する発券履歴記録部と、
発券処理部が生成したチケット情報を利用者端末装置に送信するチケット情報送信部と、
チケット情報に含まれている認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出すコード読出部と、
コード読出部により読み出された認証コードが、発券履歴記録部に記録されている認証コードと一致することを確認し、その結果を報知する認証コード確認部と、
を設けるようにしたものである。
【0009】
(2) 本発明の第2の態様は、図1の実施形態にその一例が示されているとおり、上述の第1の態様に係るチケット発行システムにおいて、
コード読出部が、利用者端末装置のディスプレイ画面をデジタルカメラなどを利用して撮影することにより、認証付顔写真画像を取り込むことができるようにしたものである。
【0010】
(3) 本発明の第3の態様は、図1の実施形態にその一例が示されているとおり、上述の第1の態様に係るチケット発行システムにおいて、
コード読出部が、利用者端末装置からプリントアウトされた物理的なチケットの印刷面から、スキャナ装置などを利用して認証付顔写真画像を取り込むことができるようにしたものである。
【0011】
(4) 本発明の第4の態様は、図1の実施形態にその一例が示されているとおり、上述の第1の態様に係るチケット発行システムにおいて、
コード読出部が、通信装置を利用して利用者端末装置に対して有線もしくは無線通信を行うことにより、認証付顔写真画像を取り込むことができるようにしたものである。
【0012】
(5) 本発明の第5の態様は、図3の実施形態にその一例が示されているとおり、チケット発行システムにおいて、
チケットの利用対象を特定する利用対象特定情報と、チケットを利用する利用者本人の顔写真画像と、を伴う発券要求が利用者端末装置から送信されてきたときに、これを受信する発券要求受信部と、
この発券要求に応じて、利用対象特定情報で特定される利用対象についてチケットの供給が可能か否かを確認するチケット供給確認部と、
チケット供給確認部によりチケットの供給が可能であることが確認されたときに、発券要求に応じて所定の認証コードを発生し、発生した認証コードを顔写真画像に電子透かしとして埋め込む処理を行い、認証コードが埋め込まれた認証付顔写真画像を作成し、利用対象特定情報と認証付顔写真画像とを含むチケット情報を生成して発券処理を行う発券処理部と、
発券処理部が発生した認証コードを記録する発券履歴記録部と、
発券処理部が生成したチケット情報を物理的な媒体上に印刷して物理的なチケットを作成するチケット印刷部と、
物理的なチケットに印刷されている認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出すコード読出部と、
コード読出部により読み出された認証コードが、発券履歴記録部に記録されている認証コードと一致することを確認し、その結果を報知する認証コード確認部と、
を設けるようにしたものである。
【0013】
(6) 本発明の第6の態様は、図1および図3の実施形態にその一例が示されているとおり、上述の第1〜5の態様に係るチケット発行システムにおいて、
コード読出部が、チケットの利用施設に設置された利用施設端末装置を構成し、認証コード確認部に対して通信手段を介して交信できるようにし
認証コード確認部が、通信手段を介してコード読出部から送信されてきた認証コードについての一致確認を行い、その結果を通信手段を介してコード読出部に報知できるようにしたものである。
【0014】
(7) 本発明の第7の態様は、図1および図3の実施形態にその一例が示されているとおり、上述の第6の態様に係るチケット発行システムにおいて、
発券履歴記録部が、個々の認証コードを、対応する利用対象特定情報とともに記録するようにし、
コード読出部が、読み出した認証コードとともに、当該利用施設に係る利用対象特定情報を認証コード確認部に対して送信するようにし、
認証コード確認部が、認証コードと利用対象特定情報との双方についての一致確認を行うようにしたものである。
【0015】
(8) 本発明の第8の態様は、図4の実施形態にその一例が示されているとおり、上述の第1〜第7の態様に係るチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信するようにし、
発券履歴記録部が、認証コードとともにこれに対応するパスワードを記録するようにし、
利用者端末装置から、既に発券済みのチケットに関して、認証付顔写真画像とパスワードとを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
このキャンセル要求に含まれていた認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出し、読み出された認証コードおよびキャンセル要求に含まれていたパスワードが、発券履歴記録部に記録されている認証コードおよびパスワードと一致することを条件として、発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に設けるようにしたものである。
【0016】
(9) 本発明の第9の態様は、図4の実施形態にその一例が示されているとおり、上述の第1〜第7の態様に係るチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信するようにし、
発券処理部が、個々のチケットごとにユニークなチケットIDを発生し、このチケットIDを含むチケット情報を生成するようにし、
発券履歴記録部が、認証コードとともにこれに対応するチケットIDおよびパスワードを記録するようにし、
利用者端末装置から、既に発券済みのチケットに関して、チケットIDとパスワードとを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
このキャンセル要求に含まれていたパスワードが、このキャンセル要求に含まれていたチケットIDに対応して発券履歴記録部に記録されていたパスワードと一致することを条件として、発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に設けるようにしたものである。
【0017】
(10) 本発明の第10の態様は、図5の実施形態にその一例が示されているとおり、上述の第1〜第7の態様に係るチケット発行システムにおいて、
発券要求受信部が、利用者本人の個人情報とパスワードとを更に伴う発券要求を受信するようにし、
発券履歴記録部が、認証コードとともにこれに対応する個人情報およびパスワードを記録するようにし、
利用者端末装置から、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
このキャンセル要求に含まれていたパスワードが、このキャンセル要求に含まれていた利用対象特定情報および個人情報に対応して発券履歴記録部に記録されていたパスワードと一致することを条件として、発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に設けるようにしたものである。
【0018】
(11) 本発明の第11の態様は、図6の実施形態にその一例が示されているとおり、上述の第8〜第10の態様に係るチケット発行システムにおいて、
チケット供給確認部により、発券要求に対するチケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録するキャンセル待ち記録部を更に設け、
発券処理部が、キャンセル処理部によるキャンセル処理より、チケット供給が可能になった時点で、キャンセル待ちの列に記録されていた発券要求に応じた発券処理を実行するようにしたものである。
【0019】
(12) 本発明の第12の態様は、図6の実施形態にその一例が示されているとおり、上述の第8〜第10の態様に係るチケット発行システムにおいて、
チケット供給確認部により、チケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録するキャンセル待ち記録部を更に設け、
キャンセル処理部が、キャンセル待ちの列に発券要求が記録されていた場合にのみ、キャンセル処理を実行するようにしたものである。
【0020】
(13) 本発明の第13の態様は、図7の実施形態にその一例が示されているとおり、上述の第12の態様に係るチケット発行システムにおいて、
キャンセル要求を受信した時点でキャンセル待ちの列に発券要求が記録されていなかった場合に、当該キャンセル要求を「キャンセル待ち」を待機する列に記録する「キャンセル待ち」待機記録部を更に設け、
キャンセル処理部が、キャンセル待ちの列に新たな発券要求が記録された時点で、「キャンセル待ち」を待機する列に記録されているキャンセル要求に対するキャンセル処理を実行するようにしたものである。
【0021】
(14) 本発明の第14の態様は、図8の実施形態にその一例が示されているとおり、上述の第1〜第13の態様に係るチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信するようにし、
発券処理部が、個々のチケットごとにユニークなチケットIDを発生し、このチケットIDを含むチケット情報を生成するようにし、
発券履歴記録部が、認証コードとともにこれに対応するチケットID、パスワード、顔写真画像(もしくは認証付顔写真画像)を記録するようにし、
利用者端末装置から、既に発券済みのチケットに関して、チケットIDとパスワードとを伴う再発行要求が送信されてきたときに、これを受信する再発行要求受信部と、
この再発行要求に含まれていたパスワードが、この再発行要求に含まれていたチケットIDに対応して発券履歴記録部に記録されていたパスワードと一致することを条件として、発券履歴記録部の記録に基づいてチケット情報を再発行する再発行処理部と、
を更に設けるようにしたものである。
【0022】
(15) 本発明の第15の態様は、図9の実施形態にその一例が示されているとおり、上述の第1〜第13の態様に係るチケット発行システムにおいて、
発券要求受信部が、利用者本人の個人情報とパスワードとを更に伴う発券要求を受信する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応する利用対象特定情報、個人情報、パスワード、顔写真画像(もしくは認証付顔写真画像)を記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴う再発行要求が送信されてきたときに、これを受信する再発行要求受信部と、
この再発行要求に含まれていたパスワードが、この再発行要求に含まれていた利用対象特定情報および個人情報に対応して発券履歴記録部に記録されていたパスワードと一致することを条件として、発券履歴記録部の記録に基づいてチケット情報を再発行する再発行処理部と、
を更に設けるようにしたものである。
【0023】
(16) 本発明の第16の態様は、上述の第1〜第15の態様に係るチケット発行システムにおける発券要求受信部、チケット供給確認部、発券処理部、発券履歴記録部、認証コード確認部を、コンピュータにプログラムを組み込むことにより構成したものである。
【発明の効果】
【0024】
本発明に係るチケット発行システムによれば、購入者自身の顔写真に所定の認証コードを電子透かしとして埋め込んだ画像を有する電子チケットもしくは物理的チケットを発行することが可能になる。このため、チケットの利用時に、検札係員がチケット上の顔写真を照合することにより、利用者が購入者と同一であることを確認することができ、また、顔写真に埋め込まれた認証コード読み出すことにより、当該チケットが真正のものであることを確認することができる。しかも、発券履歴記録部に記録されている発券履歴を参照することにより、チケットのキャンセルや再発行を容易に行うことができるようになる。
【発明を実施するための最良の形態】
【0025】
以下、本発明を図示する実施形態に基づいて説明する。
【0026】
<<< §1.基本的な実施形態の全体構成 >>>
図1は、本発明の基本的な実施形態に係るチケット発行システムの構成を示すブロック図である。図には、利用者端末装置10、利用施設端末装置20、発券管理サーバ30、チケットDBサーバ40なる構成要素がそれぞれブロックとして示されているが、本発明に係るチケット発行システムは、これらのうち、利用施設端末装置20および発券管理サーバ30によって構成されるシステムである。なお、本発明に係るチケット発行システムは、単に、チケットの発行を行うだけのシステムではなく、発行したチケットを利用者が利用する時点において、当該チケットの認証処理までも行うシステムである。
【0027】
利用者端末装置10は、チケットの利用者が、チケットの発券(購入)を申し込むために用いる装置であり、発券管理サーバ30にアクセスする機能をもった装置であれば、どのような装置を利用者端末装置10として用いてもかまわない。実用上は、図1に示されているとおり、携帯電話11やパソコン12が、利用者端末装置10として用いられるケースが多いであろう。店舗端末13は、たとえば、コンビニエンスストアなどの店舗に設置された端末装置であり、利用者が店舗に来店して操作することを前提として用いられる。なお、図では、便宜上、1つの利用者端末装置10のみがブロックとして示されているが、実際には、もちろん、多数の利用者が、それぞれ別個の利用者端末装置10を利用して、発券管理サーバ30へアクセスすることになる。
【0028】
利用者端末装置10と発券管理サーバ30との間には、何らかの交信手段が設けられている必要がある。たとえば、両者間に専用通信路を確保してもかまわないが、実用上は、インターネットを介して両者間の通信を行うようにすれば十分である。発券管理サーバ30側の窓口となる部分をWebサーバによって構成するようにすれば、利用者端末装置10は、Webブラウザ機能により発券管理サーバ30に対してアクセスすることが可能になるので、汎用の携帯電話11やパソコン12をそのまま利用者端末装置10として用いることができるようになる。店舗端末13の場合は、専用線を用いて発券管理サーバ30にオンライン接続するのが一般的である。
【0029】
これに対して、利用施設端末装置20は、チケットの利用施設に設置された端末装置であり、やはり発券管理サーバ30との間に設けられた交信手段を介して、通信を行う機能を有している。ここで、チケットの利用施設とは、たとえば、コンサートのチケットであればコンサートホール、野球の観戦チケットであれば野球場、乗車券や航空券であれば駅や空港ということになる。実際には、この利用施設端末装置20は、個々の利用施設のチケット改札場所に設置して利用される。利用施設端末装置20と発券管理サーバ30との間の交信手段も、専用線によって実現してもよいし、インターネットを利用して実現してもよい。
【0030】
この利用施設端末装置20の主たる機能は、利用者が提示したチケットから、認証コードを読み出し、これが正しいものであるか否かを発券管理サーバ30に照会することにある。そこで、まず、チケットから認証付顔写真画像を読み込むために、利用施設端末装置20には、デジタルカメラ21、スキャナ装置22、近距離通信装置23のような画像入力手段が備わっている。また、利用施設端末装置20には、発券管理サーバ30に対する通信手段24と、認証コードの確認処理を実行する確認処理手段25と、が備わっている。確認処理手段25は、画像入力手段21〜23によってデジタルデータとして取り込まれた認証付顔写真画像から、埋め込まれていた認証コードを読み出す処理を行う。この認証コードは、通信手段24によって、発券管理サーバ30へと送信される。
【0031】
発券管理サーバ30は、本発明に係るチケット発行システムの本体ともいうべき構成要素であり、図示のとおり、発券要求受信部31、チケット供給確認部32、発券処理部33、チケット情報送信部34、発券履歴記録部35、認証コード確認部36の各構成要素を有している。もっとも、これらの各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより実現されるものである。
【0032】
本発明に係るチケット発行システムは、この発券管理サーバ30を構成する各構成要素31〜36に、利用施設端末装置20を加えることにより実現されるシステムということができる。利用施設端末装置20は、いわば本発明に係るシステムにおける出先機関として機能することになり、利用施設の現場において、利用者が提示したチケットから認証コードを読み出す働きをする。そこで、以下の説明では、利用施設端末装置20を、その機能に着目して、「コード読出部20」と呼ぶことにする。
【0033】
結局、図1に示す基本的な実施形態の場合、発券要求受信部31、チケット供給確認部32、発券処理部33、チケット情報送信部34、発券履歴記録部35、認証コード確認部36、そしてコード読出部20によって、本発明に係るチケット発行システムが構成されていることになる。なお、図では、便宜上、1つのコード読出部20のみがブロックとして示されているが、実際には、コード読出部20は、個々の利用施設ごとにそれぞれ設置されることになるので、実用上、発券管理サーバ30は複数のコード読出部20と交信することになる。
【0034】
一方、チケットDBサーバ40は、個々のコンサートやスポーツイベント、個々の列車や航空機についての1枚1枚のチケットの発行状態を管理するためのデータベースサーバであり、具体的には、個々のイベント会場、列車、航空機などの座席の配置に関する情報および1つ1つの座席について発券済であるか否かを示す情報が格納されている。このような機能をもったチケットDBサーバ40は、既に従来から利用されている公知のシステムであるため、ここではその詳細な説明は省略する。後述するように、本発明に係るチケット発行システムは、このような従来から利用されているチケットDBサーバ40へ空席の照会を行った上で、チケットの発行処理を行うことになる。
【0035】
通常、個々の事業体は、それぞれ独自にチケットDBサーバ40を設置しているので、たとえば、コンサートを主催する事業体、野球の試合を主催する事業体、列車を運行させる鉄道会社、航空機を運航させる航空会社などは、それぞれ別個独立したチケットDBサーバ40を設置することになる。したがって、本発明に係るチケット発行システムにより、種々のチケットを取り扱う幅広い運用を行うのであれば、発券管理サーバ30は、それぞれの事業体が設置したチケットDBサーバ40に空席の照会を行う必要がある。
【0036】
<<< §2.基本的な実施形態におけるチケットの発行 >>>
続いて、この図1に示す基本的な実施形態に係るチケット発行システムの個々の構成要素の機能を順に説明する。まず、発券要求受信部31は、利用者端末装置10から送信されてくる発券要求を受信する機能を有する。利用者は、利用者端末装置10を用いて発券要求受信部31へとアクセスを行い、所望のチケットについての発券要求を行うことになる。この発券要求には、少なくとも、利用対象特定情報と顔写真画像とが含まれている必要がある。図1に楕円で囲って示した「利用対象」および「顔写真」は、発券要求に含まれる「利用対象特定情報」および「顔写真画像」を示すものである。
【0037】
本願にいう「利用対象」とは、「チケットの利用対象」を意味するものであり、特定の日時に特定の場所で開催される各種イベントや、特定の日時に特定の場所で提供される種々のサービスを意味するものである。たとえば、「2004年12月24日の18:00から、東京×××体育館で開催される○○○○コンサート」なるイベントは、本願にいう「チケットの利用対象」の1つであり、「2004年12月24日、18:00東京駅発、博多行き新幹線」なる運輸サービスも、本願にいう「チケットの利用対象」の1つである。
【0038】
発券要求に含まれる「利用対象特定情報」は、このようなチケットの利用対象を特定する情報であり、「何に関するチケットを申し込みたいのか」という利用者の意志表示を示す情報になる。本発明のユニークな点は、このような「利用対象特定情報」とともに「顔写真画像」を含んだ発券要求の送信を前提としている点である。ここで、「顔写真画像」とは、チケットを利用する利用者本人の顔写真の画像を意味する。重要な点は、チケットの申込者の顔写真ではなく、チケットの利用者の顔写真である必要がある点である。すなわち、コンサートのチケットであれば、当該コンサートに実際に入場して鑑賞する本人の顔写真である必要があり、列車の乗車チケットであれば、当該列車に乗車する本人の顔写真である必要がある。
【0039】
発券要求受信部31は、このように、利用者端末装置10から、利用対象特定情報と顔写真画像とを含む発券要求が送信されてきたときに、これを受信する機能を有する構成要素であるが、実用上は、利用者端末装置10に対して、種々のガイドメッセージを送信し、利用者端末装置10から利用対象特定情報と顔写真画像とを含む発券要求を送信する処理が円滑に行われるような支援機能を、発券要求受信部31側に設けておくのが好ましい。たとえば、利用者端末装置10として、携帯電話11やパソコン12が利用されるのであれば、発券要求受信部31の機能の一部をWebサーバに担当させ、ガイド用のWebページを携帯電話11やパソコン12の画面上に表示させ、利用者が、このWebページ上の指示に従った操作を行うと、必要な情報を含んだ発券要求が自動送信されるような仕様にしておくのが好ましい。利用者端末装置10から顔写真画像を送信する方法としては、電子メールの添付書類として送信してもらうことも可能であるが、利用者端末装置10内にファイル転送用のプログラムを予めインストールしておき、このプログラムを利用して送信するようにしてもよい。
【0040】
なお、利用対象特定情報としては、必ずしも「2004年12月24日の18:00から、東京×××体育館で開催される○○○○コンサート」のような文字情報を用いる必要はなく、発券要求受信部31側において1つの利用対象を特定することが可能な情報であれば、どのような情報を利用対象特定情報として用いてもかまわない。たとえば、発券要求受信部31側から利用者端末装置10側に、コンサートの一覧リストをWebページのデータとして送信し、利用者に、このWebページ上のリストから所望のコンサート名を選択してクリックしてもらうようにすれば、発券要求受信部31側において、リスト上の1つのコンサートを利用対象として特定することが可能である。この場合、「リスト上の特定の位置を示すデータ」が、「利用対象特定情報」として用いられたことになる。要するに、利用者端末装置10側の操作により、何らかの利用対象を特定することが可能な情報であれば、どのような情報を利用対象特定情報として用いてもかまわない。
【0041】
一方、顔写真画像は、利用者側で用意する必要がある。最近は、デジタルカメラの普及により、利用者が自己の顔を撮影してデジタルデータからなる顔写真画像を得ることは、比較的容易である。特に、利用者端末装置10としてデジタルカメラ付きの携帯電話を用いている場合には、別途、デジタルカメラを用意する必要もない。また、利用者端末装置10として、コンビニエンスストアなどに設置された店舗端末13を用いる場合には、この店舗端末13自身にデジタルカメラを組み込んでおくようにし、発券要求を送信する際に、利用者の顔写真を自動的に撮影して送信する機能をもたせておくと便利である。
【0042】
さて、こうして発券要求受信部31により、発券要求が受信されると、チケット供給確認部32によって、受信された発券要求に含まれている利用対象特定情報で特定される利用対象について、チケットの供給が可能か否かを確認する処理が行われる。図示の実施形態では、チケット供給確認部32からチケットDBサーバ40に対して、発券要求に係る利用対象についての空席の有無が照会されることになる。もちろん、利用対象特定情報には、S席/A席/B席などの希望を含ませておけば、チケット供給確認部32は、当該希望に合致した空席の有無を照会することができる。
【0043】
発券要求に係る利用対象についての空席が確認できた場合、別言すれば、チケット供給確認部32によりチケットの供給が可能であることが確認された場合、以下に述べるような手順により、発券処理部33による発券処理が実行される。逆に、発券要求に係る利用対象についての空席がない場合には、発券要求受信部31から利用者端末装置10に対して、希望のチケットは調達できない旨の回答が送信される。
【0044】
発券処理部33による発券処理では、まず、発券要求に応じて所定の認証コードの発生が行われる。この認証コードは、後に、チケットの真正性を確認するために利用されるコードであり、基本的には、個々のチケットごとにユニークなコードにしておくのが好ましい。また、セキュリティを向上させるためには、悪意ある者に類推されることがないように、ある程度複雑なコードにしておくのが好ましい。実用上は、発券処理部33内に、所定のアルゴリズムに基づいて、ユニークな認証コードを自動発生させるプログラムを用意しておき、発券処理を行うたびに、新たな認証コードが生成されるようにしておけばよい。
【0045】
続いて、発生した認証コードを、発券要求とともに送信されてきた顔写真画像に、電子透かしとして埋め込む画像処理が行われる。電子透かしの技術は、既に公知の技術であるため、ここでは詳しい説明は省略するが、この技術により、認証コードが埋め込まれた認証付顔写真画像を作成することが可能になる。元の顔写真画像と認証付顔写真画像との差は、肉眼観察した程度では認識できないが、認証付顔写真画像については、埋め込み処理と逆のプロセスの画像処理を実行すると、電子透かしとして埋め込まれていた認証コードを読み出すことが可能になる。
【0046】
こうして、認証付顔写真画像が作成できたら、発券要求に含まれていた利用対象特定情報と作成した認証付顔写真画像とを含むチケット情報が生成される。なお、ここに示す実施形態では、発券処理部33において、個々のチケットのシリアル番号に相当するチケットIDを発生させ、これをチケット情報に含ませるようにしている。結局、発券処理部33によって生成されるチケット情報には、利用対象特定情報、認証付顔写真画像、チケットIDが含まれていることになる。本発明を実施するにあたって、チケットIDは必ずしも必須のものではないが、実用上は、個々のチケットを区別するための便宜を図るため、チケットIDを用いるのが好ましい。なお、チケットIDは、同一の利用対象に関して発行された個々のチケットを区別することができればよいので、利用対象ごとにそれぞれユニークなIDになっていれば足りる。
【0047】
また、座席番号などを指定する必要があるチケットの場合、発券処理部33は、この座席番号などを含むチケット情報を生成する処理を行う。この場合、座席番号などは、チケットDBサーバ40への照会により得ることができる。また、発券処理部33は、チケットDBサーバ40に対しても、チケット発行に伴い必要な記録を行う。すなわち、発券処理部33は、チケット情報の生成に伴い、チケットDBサーバ40内のデータベースに対して、空席を1つ減じる書き換え処理を実行する。
【0048】
こうして生成されたチケット情報は、チケット情報送信部34へと送られる。このチケット情報送信部34は、発券処理部33が生成したチケット情報を、利用者端末装置10に送信する役割を果たす。上述したとおり、ここに示す実施形態の場合、チケット情報は、利用対象特定情報、認証付顔写真画像、チケットIDなるデータの集合体であり、利用者端末装置10に対する送信方法は、利用者端末装置10の形態に応じて適宜選択することが可能である。
【0049】
たとえば、利用者端末装置10として、携帯電話11やパソコン12が用いられている場合には、電子メールを利用してチケット情報の送信が可能である。この場合、発券要求に、チケット情報の返信先の電子メールアドレスを入れておくようにすればよい。また、利用者端末装置10として店舗端末13が用いられている場合には、当該店舗端末13に対して、オンライン経由でチケット情報を送信することが可能である。この場合、店舗端末13にプリンタを組み込んでおき、送信されてきたチケット情報を紙面上に印刷することができるようにしておけば、利用者は、その場で物理的なチケットを持ち帰ることができる。
【0050】
なお、発券要求を送信する利用者端末装置10と、チケット情報を受信する利用者端末装置10とは、必ずしも同一の装置である必要はない。たとえば、パソコン12で発券要求を送信し、携帯電話11でチケット情報を受信してもよいし、店舗端末13で発券要求を送信し、パソコン12でチケット情報を受信するようなことも可能である。
【0051】
一方、発券履歴記録部35は、発券処理部33によって行われた発券処理の履歴を記録する機能をもった構成要素である。原理的には、発券履歴記録部35には、発券処理部33が発生した認証コードだけを記録しておけば足りるが、ここに示す実施形態の場合、認証コードとともに、これに対応する利用対象特定情報とチケットIDとを併せて記録するようにしてある。図には、「○○○○コンサート2004/12/24 18:00」なる利用対象特定情報と、「CK001」なるチケットIDと、「XYZ789」なる認証コードと、が互いに対応する情報として、発券履歴記録部35内に記録された状態が例示されている。
【0052】
<<< §3.基本的な実施形態におけるチケットの利用 >>>
前述の§2では、利用者からの発券要求に応じてチケット情報を発送する処理に用いられる個々の構成要素およびその機能を述べたが、この§3では、利用者がチケットを利用する際に、当該チケットを認証する処理に用いられる構成要素およびその機能を述べる。
【0053】
ここでは、便宜上、図2に示すような具体的な事例について、以下の説明を行うことにする。図2(a) は、§2のプロセスにおいて、発券要求とともに発券管理サーバ30側へと送信されたデータの一例を示す概念図である。前述したとおり、発券要求には、利用対象特定情報と顔写真画像とが含まれている。図示の例では、利用対象特定情報は、「2004年12月24日18:00より公演の○○○○コンサート」を特定するデータによって構成されている。このデータは、必ずしも前掲のような文字列からなるデータである必要はなく、発券管理サーバ30側で利用対象を特定することが可能であれば、任意のコードを利用対象特定情報として用いることができる。顔写真画像は、たとえば、JPEGやGIFフォーマットの画像データから構成されている。
【0054】
図2(b) は、このような発券要求に応じて、発券処理部33において行われる埋め込み処理の概念図である。図示の例では、「XYZ789」なる認証コードが発生され、顔写真画像に電子透かしとして埋め込む処理が行われた状態が示されている。認証付顔写真画像は、肉眼で観察する限りは、元の顔写真画像と区別できないが、デジタル処理により「XYZ789」なる認証コードが埋め込まれた状態となっている。
【0055】
図2(c) は、発券処理部33によって生成されたチケット情報の一例を示す平面図である。チケット情報は、図示のとおり、肉眼で認識できるチケット50を示す情報であり、利用者は、このようなチケット情報を受信した上で、これをディスプレイ画面上に表示させたり(電子チケットとして機能する)、プリンタで紙面上に出力させたり(物理的なチケットとして機能する)することができる。チケット50上には、認証付顔写真画像51と、利用対象特定情報52と、チケットID53とが表示されており、右側には半券54が設けられている。この例では、利用対象特定情報52として、コンサート名、日付、時刻、場所を示す情報のほか、座席番号やチケット金額を示す情報まで掲載しているが、もちろん、これは一例として示したものであり、利用対象を特定することが可能な情報であれば、利用対象特定情報52をどのような情報により構成してもかまわない。
【0056】
なお、図示のチケット50において、チケットID53は、本発明を実施する上で必須の構成要素ではないので、省略することも可能であるが、実用上は、個々のチケットを特定するためのIDとして用いるのが好ましい。また、半券54は、このチケット情報を紙面上にプリントして用いる場合の便宜のためのものであり、これも本発明を実施する上で必須のものではない。特に、チケット50をディスプレイ画面上で確認する電子チケットとしてのみ用いる場合には、半券54は実質的な意味をもたない。
【0057】
さて、利用者は、図2(c) に示すようなコンサートチケット50を、電子データの形式(電子チケット)もしくは紙面上にプリントした形式(物理的なチケット)で所持して、コンサート会場(利用施設)へ出向くことになる。コンサート会場の改札場所には、利用施設端末装置20(コード読出部)が設置されており、ここでチケットの真正性確認と利用者の本人確認とが行われる。
【0058】
チケットの真正性確認は、コード読出部20を用いて、利用者が提示したチケット50から、認証コードを読み出し、これが正しいものであるか否かを、発券管理サーバ30側に問い合わせることによって行うことができる。すなわち、コード読出部20は、利用者が提示したチケット50上に表示されているチケット情報内の認証付顔写真画像51から、電子透かしとして埋め込まれている認証コードを読み出す機能を有しており、読み出した認証コードを認証コード確認部36へと送信して、真正性を問い合わせる処理を行う。すなわち、画像入力手段21〜23によって認証付顔写真画像51がデジタルデータとして入力され、確認処理手段25によって認証コードの読み出しが行われ、通信手段24によって認証コードの送信が行われる。図示の例の場合、認証付顔写真画像51から「XYZ789」なる認証コードが読み出されることになり、この「XYZ789」なる認証コードが認証コード確認部36へと送信される。
【0059】
認証コード「XYZ789」の送信を受けた認証コード確認部36は、当該認証コードが、発券履歴記録部35に記録されている認証コードと一致することを確認し、その結果をコード読出部20に報知する処理を行う。具体的には、発券履歴記録部35内の認証コード欄に、「XYZ789」なるコードが存在するか否かを確認し、存在する場合には、当該認証コードは真正なコードである旨の確認結果を報知し、存在しない場合には、当該認証コードは真正なコードではない旨の確認結果を報知することになる。報知された確認結果は、確認処理手段25によって、何らかの形で提示される。
【0060】
上述した例のように、チケットの真正性確認は、コード読出部20から発券管理サーバ30側に対して、認証コードのみを送信することにより行うことが可能であるが、実用上は、更に、利用対象特定情報を送信するのが好ましい。たとえば、上述の例の場合、「2004年12月24日18:00より公演の○○○○コンサート」を特定するための利用対象特定情報と、「XYZ789」なる認証コードと、がコード読出部20から発券管理サーバ30へと送信されることになる。利用対象特定情報は、予め、利用施設端末装置として機能するコード読出部20に組み込んでおけばよい。図1に示す実施形態の場合、前述したとおり、発券履歴記録部35には、認証コードとともに、利用対象特定情報およびチケットIDが記録されている。したがって、認証コード確認部36は、「2004年12月24日18:00より公演の○○○○コンサート」を示す利用対象特定情報と「XYZ789」なる認識コードとの組み合わせが、発券履歴記録部35内に存在するか否かを確認する処理を行うことができる。
【0061】
このように、発券履歴記録部35に、個々の認証コードを、対応する利用対象特定情報とともに記録しておき、コード読出部20から認証コード確認部36に対して、認証コードとともに、当該利用施設に係る利用対象特定情報を送信するようにし、認証コード確認部36において、認証コードと利用対象特定情報との双方についての一致確認を行う確認方法を採れば、偽造チケットから読み出した認証コードが、発券履歴記録部35内に記録されている真正な認証コードと偶然一致してしまうような事態が生じる可能性を低減することができる。また、利用対象特定情報と認証コードとの組み合わせによる一致確認を行うようにすれば、個々の認証コードをすべてユニークなものにする必要はなくなるので、たとえば、別個のコンサートであれば、同一の認証コードを重複して用いるような運用も可能になる。もちろん、更に、チケットIDを組み入れた一致確認を行うことも可能である。
【0062】
コード読出部20は、利用者が提示するチケット50の形態に応じて、様々な機器を利用して構成することができる。たとえば、利用者が、携帯電話11やパソコン12を利用者端末装置10としてコンサート会場まで携帯し、ディスプレイ画面上に表示させる方法によってチケット50の提示を行うのであれば、画像入力手段を、デジタルカメラ21(実用上は、Webカメラと呼ばれているコンピュータ接続に適したカメラを用いるのが好ましい)によって構成しておけばよい。コンサート会場の改札場所において、ディスプレイ画面上に表示された図2(c) に示すようなチケット50を、デジタルカメラ21によって撮影し、デジタルデータとして読み込んだ認証付顔写真画像51から認証コードを読み出す処理を確認処理手段25によって実行すればよい。
【0063】
また、利用者が、紙面上にプリントアウトした物理的なチケット50をコンサート会場まで携帯し、これを提示するのであれば、画像入力手段を、スキャナ装置22によって構成しておけばよい。コンサート会場の改札場所において、紙媒体上に印刷された図2(c) に示すようなチケット50上の画像をスキャナ装置22によってデジタルデータとして読み込み、認証付顔写真画像51から認証コードを読み出す処理を確認処理手段25によって実行すればよい。もちろん、スキャナ装置22の代わりに、デジカメ21を用いることもできる。
【0064】
あるいは、利用者が、有線もしくは無線による近距離通信機能をもった携帯電話11やパソコン12を利用者端末装置10としてコンサート会場まで携帯し、有線もしくは無線通信によって、チケット50上の情報を送信して提示するのであれば、画像入力手段を近距離通信装置23によって構成しておけばよい。近距離通信としては、赤外線通信、無線LAN通信、Bluetooth通信などを利用可能である。利用者が、コンサート会場の改札場所において、携帯電話11やパソコン12から、必要なチケット情報を送信する操作を行えば、これを近距離通信装置23を介してデジタルデータとして読み込み、認証付顔写真画像51から認証コードを読み出す処理を確認処理手段25によって実行すればよい。なお、このような近距離通信機能を利用してチケット情報を送信する場合であっても、後述するように、本人確認を行う上で、ディスプレイ画面上に認証付顔写真画像51を表示させる必要はある。
【0065】
利用者が提示したチケット50から認証付顔写真画像51をデジタルデータとして取り込み、そこから所定のアルゴリズムに基づいて認証コードを読み出し、これを発券管理サーバ30に送信して真正性の確認結果の報知を受けるまでの処理は、すべて電子的な作業によって行われるので、実際には極めて短時間で実行されることになる。したがって、利用施設の改札場所に設置された利用施設端末装置20におけるチケットの真正性確認処理は、実際には、ほぼ一瞬のうちに実行される処理であり、確認結果は、確認処理手段25によって直ちに提示される。
【0066】
コンサート会場の改札場所の係員は、上述したチケットの真正性確認のための作業を行うとともに、利用者の本人確認のための作業を行う。この本人確認は、係員の目視によって行われる。すなわち、改札場所の係員は、利用者が提示したチケット50上の認証付顔写真画像51と、利用者本人の顔とが一致することを目視確認する。もちろん、係員の目視による一致確認であるから、現実的には、誤った一致確認が行われることもあり得るが、少なくとも「入り口で写真照合による本人確認が行われるチケット」という心証を一般利用者に与えることにより、転売を目的としたダフ屋行為を抑制させる効果は十分に得られる。
【0067】
結局、コンサート会場の改札場所の係員は、利用者から提示されたチケット50に対して、コード読出部20を用いた認証コードの確認処理(チケットの真正性確認処理)を行うとともに、認証付顔写真画像51と本人の顔とを照合することによる本人確認処理を行った上で、当該利用者の入場を許可することになる。もっとも、実用上は、認証コードの確認結果を音で報知するような仕組にしておけば、改札場所の係員は、音に注意しながら、チケット上の顔写真の照合を行う改札作業を行えばよいので、改札作業の負担は、それほど大きいものにはならない。
【0068】
もっとも、本人確認の処理は、必ずしも改札場所の係員による目視の作業によって行う必要はなく、コンピュータを利用したパターン照合処理によって自動的に行うようにしてもかまわない。たとえば、コンサート会場の改札場所において、来場した利用者本人の顔写真をその場で撮影して、デジタルデータとして取り込み、所定のアルゴリズムに基づいて比較照合処理を実行するするプログラムにより、チケット50から取り込んだ認証付顔写真画像51上の人物と同一であることを自動認識するようにしてもかまわない。
【0069】
なお、利用者は、チケット50を種々の方法で複製することが可能である。たとえば、デジタルデータの形式の電子チケットであれば、単なるファイルコピー作業により多数の複製を作成することができ、これをプリンタから出力させれば、物理的な形態のチケットも何枚も作成することができる。そこで、実用上は、複製による不正利用(重複利用)を防ぐために、上述のようなチケット50の利用が行われた時点で、発券管理サーバ30側において、当該認証コードを無効化する処理を行うようにするのが好ましい。
【0070】
たとえば、上述の例の場合、認証コード「XYZ789」の送信を受けた認証コード確認部36は、当該認証コードが、発券履歴記録部35に記録されている認証コードと一致することを確認し、その結果をコード読出部20に報知する処理を行うが、このとき、発券履歴記録部35内に記録されている認証コード「XYZ789」を無効化する処理(たとえば、削除する処理や、無効を示すフラグなどを付加する処理)を実行するようにする。そうすれば、再度、認証コード「XYZ789」についての照会があった場合には、認証コード確認部36は、不一致との判定を行うことができるので、同一の認証コードを重複して利用することはできなくなる。
【0071】
本発明に係るチケットでは、顔写真による本人確認が行われることになるので、理論的には、同一のチケットにより複数の者が入場することはできないはずであるが、現実的には、改札場所の係員による目視確認では、完全な本人確認を行うことはできない。したがって、実用上は、上述のように、利用施設において、チケットを利用した入場が1回行われた時点で、当該チケットについての認証コードを無効化する処理を行い、同一チケットを用いた2回目以降の入場を拒絶する運用を行うのが好ましい。
【0072】
<<< §4.物理的チケットを発行する実施形態 >>>
図1に示す実施形態では、チケットは、チケット情報送信部34からチケット情報というデジタルデータの形式で利用者の下に送信されることになる。利用者は、このデジタルデータの形式のチケットを、電子チケットとしてそのまま利用するか、プリンタなどを用いて物理的チケットの形式で出力した上で利用することになる。
【0073】
これに対して、図3に示す実施形態は、発券管理サーバ30側で物理的チケットの発行を行い、これを利用者に届けることができる。図1に示す実施形態との相違点は、チケット情報送信部34の代わりに、チケット印刷部37を設けた点だけである。チケット印刷部37は、発券処理部33を構成するコンピュータに接続されたプリンタによって構成され、発券処理部33が生成したチケット情報を紙などの物理的な媒体上に印刷して物理的なチケットを作成する機能を有している。したがって、発券管理サーバ30から、紙媒体上に印刷された形式のチケット50を出力することができる。こうして出力したチケット50は、利用者の下に郵便などの方法を利用して届けられる。なお、発券要求には、チケットの郵送先の住所などの情報を入れておく必要がある。
【0074】
結局、この図3に示す実施形態では、利用者が、利用者端末装置10を用いて発券要求を行うと、発行された物理的チケット50が、後日、郵便などで届けられることになる。この物理的チケット50を利用施設で利用する方法は、§3で説明したプリントアウトしたチケットを利用する方法と同様である。すなわち、コンサート会場の改札場所において、スキャナ装置22などを利用して認証付顔写真画像51の取り込みが行われ、認証コードの確認が実施されるとともに、顔写真による本人確認が行われることになる。
【0075】
<<< §5.キャンセルを受け付ける実施形態 >>>
本発明に係るチケット発行システムは、一度発行したチケットのキャンセルを行う処理にも適している。ここでは、このようなキャンセルを受け付ける機能をもったいくつかの実施形態を述べる。
【0076】
図4は、キャンセルを受け付ける機能をもった第1の実施形態に係るチケット発行システムの構成を示すブロック図である。図1に示す基本的実施形態との相違は、図4に示すシステムには、キャンセル要求受信部61およびキャンセル処理部62が付加されている点、発券要求受信部31が、利用対象特定情報および顔写真画像に加えて、更にパスワードを伴う発券要求を受信する点、発券履歴記録部35が、認証コードとともにこれに対応するパスワードを記録する機能を有する点、である。これにより、図4に示すシステムは、一度発行したチケットに対するキャンセル処理を行うことができる。
【0077】
利用者が、この図4に示すシステムに対して発券要求を行う場合、利用対象特定情報、顔写真画像、パスワードを発券要求受信部31に対して送信する必要がある。ここでは、説明の便宜上、「2004年12月24日18:00より公演の○○○○コンサート」を示す利用対象特定情報と、顔写真画像と、「APPLE」なるパスワードと、を含む発券要求が送信されたものとしよう。このような発券要求に応じて、発券処理部33によってチケット情報(利用対象特定情報、認証付顔写真画像、チケットID)が作成され、チケット情報送信部34によって利用者端末装置10へと送信されることは、図1に示す実施形態と全く同様である。また、利用者がこのチケットをコンサート会場で利用する際の手続も、前述の実施形態と全く同様である。
【0078】
この図4の実施形態では、発券要求に含まれていたパスワードが、認証コードとともに、発券履歴記録部35に記録されることになる。図示の例では、利用対象特定情報、チケットID、認証コード、パスワードが、互いに対応するデータとして、発券履歴記録部35に記録されている。パスワードは、利用者本人のみが知りうるデータであれば、どのようなデータであってもかまわない。このように、パスワードを発券履歴記録部35内に記録しておくのは、発券済みのチケットに関するキャンセル処理を円滑に行うためである。
【0079】
さて、ここでは、図2(c) に示すようなチケット50を入手した利用者が、都合により、当該コンサートに行けなくなったものとしよう。本発明に係るチケット発行システムで発行されたチケットは、チケットに顔写真が掲載された利用者本人しか利用することができないので、従来のチケットのように、他人に譲渡することはできない。したがって、本人が利用できなくなったチケットは、キャンセルせざるを得ない。このように、キャンセルせざるを得ない状況になった場合、利用者は、利用者端末装置10から発券管理サーバ30に対してキャンセル要求を行えばよい。
【0080】
キャンセル要求は、キャンセル要求受信部61によって受信され、キャンセル処理部62へ伝えられる。キャンセル要求受信部61を、Webサーバで構成しておけば、利用者は、利用者端末装置10のWebブラウザ機能を利用して、キャンセル要求受信部61へアクセスすることが可能である。もちろん、利用者端末装置10内に専用プログラムを組み込んでおけば、この専用プログラムの機能を利用して、キャンセル要求受信部61へアクセスすることもできる。
【0081】
このキャンセル要求には、少なくとも認証付顔写真画像とパスワードとが含まれるようにする。認証付顔写真画像は、既に発行済みのチケット情報に含まれているので、利用者は、これをそのまま返信すればよい。一方、パスワードは、利用者が発券要求を行ったときに入力したデータであるから、利用者自身であれば知っているはずの情報である。万一、利用者がパスワードを忘れてしまった場合、この実施形態に係るシステムでは、キャンセルを行うことができなくなる。したがって、チケットを発券する際には、入力したパスワードを忘れないように、利用者に対して十分に注意を喚起しておく必要がある。なお、実用上は、利用者端末装置10に、専用プログラムを組み込んでおき、発券要求およびキャンセル要求を行う際には、この専用プログラムを起動することにより、必要なデータが自動的に発券管理サーバ30側に送信されるようにしておくのが好ましい。また、利用者がパスワードを忘れてしまった場合の対策を用意しておくことも可能である。たとえば、パスワードを忘れてしまった利用者がキャンセル要求を行いたい場合には、何らかの方法で発券管理サーバ30にチケットIDを特定してパスワードの問い合わせをしてもらうようにする。発券管理サーバ30側では、このような問い合わせに応じて、発券履歴記録部35を参照して、利用者本人にパスワードを通知すればよい。この場合、チケットの発券時にチケット情報を送信した利用者本人のメールアドレスを記録しておくようにし、当該メールアドレス宛にパスワードを送信するようにすれば、本人になりすました第三者からパスワードの問い合わせがあったとしても、この第三者宛にパスワードが通知されることはない。
【0082】
キャンセル処理部62は、既に発券済みのチケットに関して、認証付顔写真画像とパスワードとを伴うキャンセル要求が送信されてきたら、このキャンセル要求に含まれていた認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出し、読み出された認証コードおよびキャンセル要求に含まれていたパスワードが、発券履歴記録部35に記録されている認証コードおよびパスワードと一致するか否かを確認する。そして、両者が一致した場合に、発券履歴記録部35の当該記録を無効化してキャンセル処理を行う。キャンセル処理部62は、当然、チケットDBサーバ40に対しても必要なキャンセル処理、すなわち、キャンセルされたチケットに対応する空席が1つ生じた旨の記録を行うための処理を実行する。
【0083】
たとえば、図2(c) に示すようなチケット50を入手した利用者が、これをキャンセルする場合、認証付顔写真画像51と「APPLE」なるパスワードとをキャンセル要求受信部61に対して送信する処理を行うことになる。キャンセル処理部62は、この認証付顔写真画像51から、埋め込まれていた認証コード「XYZ789」を読み出し、認証コード「XYZ789」およびパスワード「APPLE」なる組み合わせが、発券履歴記録部35内に記録されているか否かを確認する処理を行う。図4に示す例では、そのような組み合わせの存在が確認できるので、キャンセルを行うための条件を満たしている、との判断がなされ、チケットDBサーバ40に対してキャンセルにより空席が生じた旨の報告を行うとともに、発券履歴記録部35内の認証コード「XYZ789」を無効化する処理を行う。これにより、キャンセルされたチケット50を利用してコンサートに入場することはできなくなる。
【0084】
キャンセル要求を行うためにパスワードの入力を必須要件としているのは、不正な方法でチケット50を入手した第三者が、利用者になりすましてキャンセル要求を行うことを封じるためである。パスワードは、本来、正規の利用者のみが知りうるデータであるから、キャンセル処理部62は、認証コードとパスワードとの双方が一致した場合に、当該キャンセル要求を正規の利用者からの正規の要求であるものと判断することになる。
【0085】
なお、図4に示す例では、キャンセル要求に、認証付顔写真画像とパスワードの他に、チケットIDを入れるようにしているが、これはキャンセル処理部62が発券履歴記録部35内の記録データを検索する際の便宜を図るためである。図2(c) に示す例では、チケット50に、チケットID53が含まれているので、キャンセル要求に、このチケットID53を含ませることは容易にできる。一方、キャンセル処理部62は、このチケットID53を利用して、発券履歴記録部35を検索することが可能になる。たとえば、図4に示す例では、「CK001」なるチケットIDを用いた検索により、認証コード「XYZ789」およびパスワード「APPLE」なる組み合わせを容易に見付けることができる。
【0086】
もちろん、すべてのチケットに対してユニークな認証コードを発生させるようにすれば、このようなチケットIDを用いることなしに、所望の認証コードを検索することが可能である。しかしながら、個々の利用対象ごとにユニークな認証コードを発生させるようにした場合、利用対象が異なれば、同一の認証コードが用いられる可能性があるので、そのような場合には、キャンセル要求にチケットIDを含ませ、これを用いて検索を行うことができるようにするとよい。
【0087】
なお、すべてのチケットに対してユニークなチケットIDを発生させるようにしておけば、チケットIDとパスワードとを伴うキャンセル要求に基づいて、キャンセル処理を行うことも可能である。この場合、キャンセル処理部62は、発券履歴記録部35を参照した結果、チケットIDとパスワードとの組み合わせが一致すれば、これを正当なキャンセル要求と判断することができるので、認証コードの一致確認は省略することができる。したがって、キャンセル要求には、認証付顔写真画像を含ませておく必要はない。
【0088】
具体的には、図4に示す例の場合、利用者は、「CK001」なるチケットIDと「APPLE」なるパスワードとをキャンセル要求として送信すればよい。キャンセル処理部62は、発券履歴記録部35内を検索して、「CK001」および「APPLE」の組み合わせの存在を確認することにより、これを正当なキャンセル要求と判断し、「CK001」に対応して記録されている認証コード「XYZ789」を無効化することになる。
【0089】
図5は、キャンセルを受け付ける機能をもった第2の実施形態に係るチケット発行システムの構成を示すブロック図である。図4に示す第1の実施形態との相違は、図5に示すシステムでは、発券要求受信部31が、利用対象特定情報、顔写真画像、パスワードに加えて、更に個人情報を伴う発券要求を受信する点、発券履歴記録部35が、チケットIDの代わりに個人情報を記録する機能を有する点、キャンセル処理部62が、個人情報の一致判定を行う点、である。
【0090】
ここで、個人情報とは、利用者本人の個人的な事項に関する情報であり、たとえば、氏名、住所、電話番号、生年月日、電子メールアドレスなどの情報ということになる。利用者が、この図5に示すシステムに対して発券要求を行う場合、利用対象特定情報、顔写真画像、個人情報、パスワードを発券要求受信部31に対して送信する必要がある。ここでは、説明の便宜上、「2004年12月24日18:00より公演の○○○○コンサート」を示す利用対象特定情報と、顔写真画像と、「特許太郎 123−××××」なる個人情報(氏名と電話番号)と、「APPLE」なるパスワードと、を含む発券要求が送信されたものとしよう。このような発券要求に応じて、発券処理部33によってチケット情報(利用対象特定情報、認証付顔写真画像、個人情報)が作成され、チケット情報送信部34によって利用者端末装置10へと送信される。利用者がこのチケットをコンサート会場で利用する際の手続は、前述の実施形態と全く同様である。
【0091】
この図5の実施形態では、発券要求に含まれていた個人情報およびパスワードが、認証コードとともに、発券履歴記録部35に記録されることになる。図示の例では、利用対象特定情報、個人情報、認証コード、パスワードが、互いに対応するデータとして、発券履歴記録部35に記録されている。
【0092】
さて、この実施形態に係るシステムでは、チケットのキャンセルを行う場合、キャンセル要求には、少なくとも利用対象特定情報、個人情報、パスワードを含ませておくようにする。利用対象特定情報および個人情報は、既に発行済みのチケット情報に含まれているので、利用者は、これをそのまま返信すればよい。一方、パスワードは、利用者が発券要求を行ったときに入力したデータであるから、利用者自身であれば知っているはずの情報である。もちろん、前述したように、パスワードを忘れてしまった場合の問い合わせ機能を用意しておいてもよい。
【0093】
キャンセル処理部62は、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴うキャンセル要求が送信されてきたら、これらの情報が、発券履歴記録部35に記録されている情報と一致するか否かを確認する。そして、両者が一致した場合に、発券履歴記録部35の当該記録を無効化してキャンセル処理を行う。キャンセル処理部62は、当然、チケットDBサーバ40に対しても必要なキャンセル処理、すなわち、キャンセルされたチケットに対応する空席が1つ生じた旨の記録を行うための処理を実行する。
【0094】
たとえば、図5に示す例の場合、キャンセル要求として、「2004年12月24日18:00より公演の○○○○コンサート」を示す利用対象特定情報と、「特許太郎 123−××××」なる個人情報と、「APPLE」なるパスワードと、を含むキャンセル要求を送信すればよい。キャンセル処理部62は、発券履歴記録部35を検索して、「2004年12月24日18:00より公演の○○○○コンサート」を示す利用対象特定情報と「特許太郎 123−××××」なる個人情報との組み合わせを見つけ出し、この組み合わせに対応して記録されているパスワードが、キャンセル要求に含まれていたパスワード「APPLE」に一致することを確認することにより、キャンセルを行うための条件を満たしている、との判断を行う。そして、チケットDBサーバ40に対してキャンセルにより空席が生じた旨の報告を行うとともに、発券履歴記録部35内の対応する認証コード「XYZ789」を無効化する処理を行う。これにより、キャンセルされたチケット50を利用してコンサートに入場することはできなくなる。
【0095】
<<< §6.キャンセル待ちを受け付ける実施形態 >>>
上述した§5では、既に発行を受けたチケットをキャンセルしたいと欲する利用者の便宜を図る実施形態を述べたが、ここでは、チケットの発券要求を行った時点で売り切れの状態となっていたため、キャンセル待ちをしたいと欲する利用者の便宜を図る実施形態を述べる。
【0096】
図6は、このようなキャンセル待ちを受け付ける第1の実施形態に係るチケット発行システムの構成を示すブロック図である。この実施形態は、図4または図5に示す実施形態に、キャンセル待ち記録部63を更に付加したものである。ここで、キャンセル待ち記録部63は、利用者端末装置10からの発券要求に応じて、チケット供給確認部32がチケットDBサーバ40に対して確認を行ったところ、発券要求に対するチケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録する処理を実行する。そして、発券処理部33は、キャンセル処理部62によるキャンセル処理より、チケット供給が可能になった時点で、このキャンセル待ち記録部63内のキャンセル待ちの列に記録されていた発券要求に応じた発券処理を実行する機能を有する。
【0097】
たとえば、利用者甲が、あるコンサートXのチケットについての発券要求を行ったところ、既に、このコンサートXのチケットが完売状態であったものとしよう。この場合、利用者甲が、利用者端末装置10から発券要求を行っても、チケット供給確認部32がチケットDBサーバ40へコンサートXの空席を確認した段階で、当該チケットの供給が不可能であることが確認される。このような場合、甲の発券要求の情報(利用対象特定情報、顔写真画像、チケットの送信先アドレスなど)は、そっくりそのままキャンセル待ち記録部63にキャンセル待ちの列として記録される。
【0098】
もちろん、場合によっては、既にキャンセル待ちの列に先客として記録されている発券要求が存在することもありうる。こうして、キャンセル待ちの列に記録されたら、とりあえず甲に対しては、所望のチケットが完売状態なので、キャンセル待ちの手続に入った旨の報告がなされる。もちろん、甲に、キャンセル待ちを希望するか否かを尋ね、甲が希望した場合にのみ、キャンセル待ち記録部63への記録を行うようにしてもよい。
【0099】
さて、後日、既にコンサートXのチケットの発行を受けていた別な利用者乙が、都合により、当該チケットのキャンセル要求を行ったとしよう。このキャンセル要求は、キャンセル要求受信部61で受信され、キャンセル処理部62において、所定のキャンセル処理が行われることは、既に§5で述べたとおりである。こうして、キャンセル処理部62において、コンサートXのチケットについてのキャンセルが行われると、その事実が、発券処理部33へと報告される。そこで、発券処理部33は、キャンセル待ち記録部63に記録されているコンサートXに関するキャンセル待ちの列の中で、最も先頭に並んでいる発券要求を取り出して、当該発券要求に基づく発券処理を実行する。その結果、利用者甲の下に、コンサートXのチケット情報が送信されることになる。
【0100】
上述の例の場合、利用者甲宛に送信されるチケット情報は、発券処理部33によって新たに生成されたものであり、利用者甲の顔写真画像に新たな認証コード(利用者乙に対して発行した認証コードとは別なコード)が埋め込まれたものになる。前述したとおり、キャンセル処理部62は、発券履歴記録部35に記録されている乙に対して発行した認証コードを無効化する処理を行うので、利用者乙の手元にあるチケットは無効となる。
【0101】
なお、このようなキャンセル待ちの処理は、結局、乙のチケットを甲に手渡したのと同等の効果をもつ処理であるので、チケットDBサーバ40に対する更新処理を行う必要はない。もちろん、キャンセル処理部62からチケットDBサーバ40に対して、1枚のチケットがキャンセルされた旨の記録を行った後、発券処理部33からチケットDBサーバ40に対して、1枚のチケットが発行された旨の記録を行ってもかまわないが、実用上、このような更新処理は意味のない処理となる。したがって、上述した例のように、キャンセルされたチケットが、キャンセル待ちの利用者に渡った場合には、チケットDBサーバ40に対する更新処理は行う必要はない。
【0102】
ところで、場合によっては、一度発行したチケットに対するキャンセル要求を無条件で受け入れることが好ましくないケースもあり得る。販売済みのチケットの払い戻しに無条件で応じると、興行が経済的に成り立たなくなる危険性が生じるのも事実であり、実際、払い戻しには応じない旨が明記されたチケットも少なくない。図6に示す実施形態では、このような場合、条件付きでキャンセルに応じるような運用が可能になる。
【0103】
すなわち、チケットのキャンセルは、キャンセル待ちの利用者がいる場合にのみ応じる、という運用である。このような運用を行えば、実質的に、利用者間でチケットの受け渡しを行ったことと同じになるので、興行主側は経済的損失を被ることはない。このような運用を行う場合、キャンセル処理部62が、キャンセル待ち記録部63のキャンセル待ちの列を確認して、キャンセル待ちをしている発券要求が記録されていた場合にのみ、キャンセル処理を実行する構成にしておけばよい。
【0104】
たとえば、上述の例の場合、乙がコンサートXのチケットについてのキャンセル要求を行ったとすると、キャンセル処理部62は、キャンセル待ち記録部63内にコンサートXについての発券要求がキャンセル待ちとして記録されているか否かを確認する処理を行うことになる。もし、キャンセル待ちが全くなければ、キャンセル処理部62は、乙のキャンセル要求を拒絶することになる。上述の例のように、甲がキャンセル待ちをしていた場合にのみ、乙のキャンセル要求が認められることになる。
【0105】
ところで、このような運用を採ると、キャンセルを行いたい乙は、キャンセル待ちが現れた頃を見計らって、何度も同じキャンセル要求を出す作業を行わねばならない。図7のブロック図に示すシステムは、乙のこのような労力を軽減するための実施形態であり、図6に示す実施形態に、更に、キャンセル待ち待機記録部64を付加したものである。
【0106】
キャンセル待ち待機記録部64は、キャンセル要求を受信した時点で、キャンセル待ち記録部63内のキャンセル待ちの列に発券要求が記録されていなかった場合に、当該キャンセル要求を「キャンセル待ち」を待機する列に記録する処理を実行する。このキャンセル待ち待機記録部64内には、いわば、「キャンセル待ち」を待つ列が記録されることになる。キャンセル処理部62は、キャンセル待ち記録部63内のキャンセル待ちの列に新たな発券要求が記録された時点で、キャンセル待ち待機記録部64内の「キャンセル待ち」を待機する列に記録されているキャンセル要求に対するキャンセル処理を実行する。
【0107】
たとえば、乙がコンサートXのチケットについてのキャンセル要求を行ったとすると、キャンセル処理部62は、キャンセル待ち記録部63内にコンサートXについての発券要求がキャンセル待ちとして記録されているか否かを確認する処理を行うことになる。ここで、キャンセル待ちが記録されていた場合には、前述のとおり、キャンセルが実行されることになるが、コンサートXについてのキャンセル待ちが全くなければ、キャンセル処理部62は、乙のキャンセル要求をとりあえず拒絶することになる。このような場合、乙のキャンセル要求の情報は、そっくりそのままキャンセル待ち待機記録部64に「キャンセル待ち」を待機する列として記録される。
【0108】
もちろん、場合によっては、既に「キャンセル待ち」を待機する列に先客として記録されているキャンセル要求が存在することもありうる。こうして、「キャンセル待ち」を待機する列に記録されたら、とりあえず乙に対しては、キャンセル待ちを希望する利用者がいないので、「キャンセル待ち」を待機する手続に入った旨の報告がなされる。もちろん、乙に、「キャンセル待ち」の待機を希望するか否かを尋ね、乙が希望した場合にのみ、キャンセル待ち待機記録部64への記録を行うようにしてもよい。
【0109】
さて、後日、コンサートXのチケットを入手したいと希望する甲によって、発券要求がなされたとしよう。この場合、当該発券要求に応じて、チケット供給確認部32がチケットDBサーバ40に対して、空席があるか否かを確認する処理を行う。ここで、もし、このコンサートXにまだ空席がある場合には、チケット供給確認部32から発券処理部33に対して、チケットの供給が可能である旨の報告がなされ、発券処理部33は、通常の手順どおり、甲に対してチケットの発行を行うことになる。別言すれば、キャンセル待ちは生じないことになり、「キャンセル待ち」を待っていた乙のキャンセル要求は受け入れられない。
【0110】
しかし、甲の発券要求について、チケットDBサーバ40に問い合わせた結果、もし、空席がないことが確認された場合には、甲の発券要求は、一旦、キャンセル待ち記録部63へと記録され、形式的にキャンセル待ちの状態になる。そして、その事実が、キャンセル処理部62へと報告される。そこで、キャンセル処理部62は、キャンセル待ち待機記録部64に記録されているコンサートXに関する「キャンセル待ち」を待機する列の中で、最も先頭に並んでいるキャンセル要求を取り出して、当該キャンセル要求に基づくキャンセル処理を実行する。乙のキャンセル要求が先頭に並んでいた場合には、乙のキャンセル要求が受け入れられることになり、乙のチケットがキャンセルされ、甲に対してチケットの発行が行われることになる。
【0111】
このような処理により、キャンセル待ちを希望する者がいる場合に限って、キャンセルに応じるという運用を円滑に行うことが可能になる。このような運用は、興行主側からすれば、経済的な損失を被るリスクを減らすメリットが得られ、利用者側からすれば、条件付きではあるが、不要なチケットの払い戻しを受けられるメリットが得られる。
【0112】
<<< §7.再発行を受け付ける実施形態 >>>
続いて、ここでは、一度発行を受けたチケットを紛失した場合に、再発行を受けることが可能な実施形態を述べる。通常、チケットを紛失した場合、利用者はもはや当該チケットを利用することはできず、再発行に応じてもらうこともできない。しかしながら、本発明に係るチケット発行システムでは、このような場合でも、比較的容易に再発行処理に応じることが可能になる。
【0113】
図8は、再発行を受け付ける機能をもった第1の実施形態に係るチケット発行システムの構成を示すブロック図である。図1に示す基本的実施形態との相違は、図8に示すシステムには、再発行要求受信部71および再発行処理部72が付加されている点、発券要求受信部31が、利用対象特定情報および顔写真画像に加えて、更にパスワードを伴う発券要求を受信する点、発券履歴記録部35が、認証コードとともにこれに対応するパスワードおよび顔写真画像(もしくは認証付顔写真画像でもよい)を記録する機能を有する点、である。これにより、図8に示すシステムは、チケットが紛失した場合に再発行処理を行うことができる。
【0114】
なお、図1に示す基本的実施形態の場合、チケットIDの利用は任意であったが、この図8に示すシステムでは、発券処理部33により、個々のチケットごとにユニークなチケットIDを発生し、このチケットIDを含むチケット情報を生成する必要があり、発券履歴記録部35には、このチケットIDも記録しておく必要がある。
【0115】
利用者が、紙媒体としてのチケット50を紛失したり、利用者端末装置10内の電子データとしてのチケット50を紛失(データの消滅)したりした場合、発券管理サーバ30に対して再発行要求を行うことができる。この図8に示す実施形態では、再発行要求を行う場合、チケットIDとパスワードを再発行要求受信部71に対して送信する必要がある。再発行要求は、再発行要求受信部71によって受信され、再発行処理部72へ伝えられる。再発行要求受信部71を、Webサーバで構成しておけば、利用者は、利用者端末装置10のWebブラウザ機能を利用して、再発行要求受信部71へアクセスすることが可能である。もちろん、利用者端末装置10内に専用プログラムを組み込んでおけば、この専用プログラムの機能を利用して、再発行要求受信部71へアクセスすることもできる。実用上は、利用者端末装置10に、専用プログラムを組み込んでおき、この専用プログラムを起動することにより、再発行要求に必要なデータが自動的に発券管理サーバ30側に送信されるようにしておくのが好ましい。
【0116】
この再発行要求には、少なくともチケットIDとパスワードが含まれている必要がある。チケットIDおよびパスワードのいずれか一方でも不明な場合には、この実施形態に係るシステムでは、再発行を受けることができない。したがって、チケットを発券する際には、チケット上に記載されたチケットIDと入力したパスワードを忘れないように、どこかにメモしておくなど、利用者に対して十分に注意を喚起しておく必要がある。
【0117】
再発行処理部72は、既に発券済みのチケットに関して、チケットIDとパスワードとを伴う再発行要求が送信されてきたら、当該再発行要求に含まれていたパスワードが、当該再発行要求に含まれていたチケットIDに対応して発券履歴記録部35に記録されていたパスワードと一致することを条件として、発券履歴記録部35の記録に基づいてチケット情報を再発行する処理を実行する。
【0118】
たとえば、図2(c) に示すようなチケット50を紛失してしまった利用者が、このチケットの再発行を受ける場合を考える。この場合、当該利用者が、「CK001」なるチケットIDをどこかにメモしておいたものとし、「APPLE」なるパスワードを記憶していたものとしよう。
【0119】
図8に示す例において、「CK001」なるチケットIDと「APPLE」なるパスワードとを含む再発行要求が与えられた場合、再発行処理部72は、「CK001」なるチケットIDと「APPLE」なるパスワードとの組み合わせが、発券履歴記録部35内に記録されているか否かを確認する処理を行う。図8に示す例では、そのような組み合わせの存在が確認できるので、再発行を行うための条件を満たしている、との判断がなされ、再発行処理部72による再発行処理が実行される。すなわち、発券履歴記録部35内には、「CK001」なるチケットIDに対応して、利用対象特定情報、認証コード、顔写真画像というデータが記録されているので、再発行処理部72は、これらのデータを利用して、チケット情報を再発行することができ、これをチケット情報送信部34に送ることができる。顔写真画像の代わりに、認証付顔写真画像を発券履歴記録部35に記録しておいても同様である。
【0120】
こうして再発行されたチケット情報は、チケット情報送信部34によって利用者端末装置10へと送信される。なお、チケット情報を電子メールなどを利用して送信する場合には、再発行要求に送信先のメールアドレスを含ませておくようにすればよい。あるいは、発券要求に含まれていた送信先の情報を発券履歴記録部35に記録しておくようにすれば、再発行時にも、この記録されていた送信先の情報に基づいて、再発行されたチケット情報を送信することができる。
【0121】
図9は、再発行を受け付ける機能をもった第2の実施形態に係るチケット発行システムの構成を示すブロック図である。図8に示す第1の実施形態との相違は、図9に示すシステムでは、発券要求受信部31が、利用対象特定情報、顔写真画像、パスワードに加えて、更に個人情報を伴う発券要求を受信する点、発券履歴記録部35が、チケットIDの代わりに個人情報を記録する機能を有する点、再発行処理部72が、個人情報の一致判定を行う点、である。
【0122】
ここで、個人情報とは、利用者本人の個人的な事項に関する情報であり、たとえば、氏名、住所、電話番号、生年月日などの情報ということになる。利用者が、この図9に示すシステムに対して発券要求を行う場合、利用対象特定情報、顔写真画像、個人情報、パスワードを発券要求受信部31に対して送信する必要がある。図9では、説明の便宜上、「2004年12月24日18:00より公演の○○○○コンサート」を示す利用対象特定情報と、顔写真画像と、「特許太郎 123−××××」なる個人情報(氏名と電話番号)と、「APPLE」なるパスワードと、を含む発券要求が送信された場合の例が示されている。このような発券要求に応じて、発券処理部33によってチケット情報(利用対象特定情報、認証付顔写真画像、個人情報)が作成され、チケット情報送信部34によって利用者端末装置10へと送信される。
【0123】
この図9の実施形態では、発券要求に含まれていた利用対象特定情報、個人情報、パスワード、顔写真画像(もしくは認証付顔写真画像)が、認証コードとともに、発券履歴記録部35に記録されることになる。図示の例では、利用対象特定情報、個人情報、認証コード、パスワード、顔写真画像が、互いに対応するデータとして、発券履歴記録部35に記録されている。
【0124】
さて、この実施形態に係るシステムでは、チケットの再発行を行う場合、再発行要求には、少なくとも利用対象特定情報、個人情報、パスワードを含ませておくようにする。利用対象特定情報は、「2004年12月24日18:00より公演の○○○○コンサート」という事項を示す情報であるので、チケット50を紛失したとしても、利用者の記憶には残っている情報である。また、個人情報は、「特許太郎 123−××××」といった利用者個人の氏名、住所、電話番号などを示す情報であるから、これも利用者の記憶にある情報である。一方、パスワードは、利用者が発券要求を行ったときに入力したデータであるから、利用者自身であれば知っているはずの情報である。したがって、チケット50を紛失したとしても、再発行要求に必要な情報は、通常、利用者の頭の中にある情報ということができる。
【0125】
再発行処理部72は、紛失したチケットに関して、利用対象特定情報、個人情報、パスワードを伴う再発行要求が送信されてきたら、これらの情報が、発券履歴記録部35に記録されている情報と一致するか否かを確認する。そして、両者が一致した場合、別言すれば、再発行要求に含まれていたパスワードが、再発行要求に含まれていた利用対象特定情報および個人情報に対応して発券履歴記録部35に記録されていたパスワードと一致する場合に、再発行を行うための条件を満たしている、と判断し、再発行処理を実行する。この再発行処理が、発券履歴記録部35内の対応データを利用して行われる点は、前掲の第1の実施形態と同様である。
【0126】
<<< §8.その他の変形例 >>>
以上、本発明をいくつかの実施形態に基づいて説明したが、本発明はこれらの実施形態に限定されるものではなく、この他にも種々の形態で実施可能である。以下、いくつかの変形例を述べる。
【0127】
(1) 図10は、更に別な実施形態を示すブロック図である。この実施形態は、図1に示す基本的実施形態の変形例を示すものであり、図1の実施形態との相違点は、コード読出部38を発券管理サーバ30側に設け、利用施設端末装置26を単なる画像読出部として機能させた点である。
【0128】
すなわち、図1に示す実施形態では、利用施設端末装置20をコード読出部として用い、この利用施設端末装置20内で、認証付顔写真画像から認証コードを読み出す処理を行っていたが、図10に示す実施形態では、利用施設端末装置26は、単に認証付顔写真画像をデジタルデータとして読み出す機能しか有していない。この場合、利用施設端末装置26から発券管理サーバ30に対して、利用対象特定情報と認証付顔写真画像を送信すればよい。発券管理サーバ30側では、コード読出部38がこれらの情報を受け取り、ここで、認証付顔写真画像から認証コードを読み出す処理が実行される。こうして読み出された認証コードが、認証コード確認部36へと与えられ、真正な認証コードであることが確認され、確認結果が利用施設端末装置26へと報知される点は、図1に示す実施形態と同様である。
【0129】
このように、コード読出部を発券管理サーバ30側にもってくると、利用施設端末装置26側の処理負担は軽減されるが、認証コードを送信する代わりに、認証付顔写真画像を送信する必要が出てくるため、通信容量は若干増えることになる。
【0130】
(2) 上述の実施形態では、利用者に対する課金処理の説明は省略したが、実用上は、発券処理部33による発券処理が行われた時点で、利用者に対する課金処理(たとえば、利用者のクレジットアカウントにチケットの購入代金決済を求める処理)を行い、キャンセル処理部62によるキャンセル処理が行われた時点で、利用者に対する返金処理(たとえば、利用者のクレジットアカウントにチケットの返金代金を計上する処理)を行うことになる。このような課金/返金処理は、既に公知の技術であるため、ここでは詳しい説明は省略する。
【0131】
(3) §5以降に述べた実施形態は、いずれも図1に示す基本的実施形態についての変形例であるが、もちろん、図3に示す実施形態(郵便で物理的チケットを送付する実施形態)についても同様に、§5以降の変形例を適用可能である。
【0132】
(4) 上述の実施形態では、利用対象特定情報、チケットID、個人情報、認証コードをそれぞれ別個のデータとして説明したが、必要に応じて、これらを相互に関連したデータで構成してもかまわない。たとえば、利用対象特定情報に対応する文字列の末尾に、シリアル番号を付加したデータを、チケットIDとして用いることも可能であるし、チケットIDや個人情報の一部を利用して、認証コードを生成することも可能である。
【図面の簡単な説明】
【0133】
【図1】本発明の基本的な実施形態に係るチケット発行システムの構成を示すブロック図である。
【図2】図1に示すチケット発行システムにおけるチケット発行処理の概念を示す図である。
【図3】物理的チケットを送付する実施形態に係るチケット発行システムの構成を示すブロック図である。
【図4】キャンセルを受け付ける第1の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図5】キャンセルを受け付ける第2の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図6】キャンセル待ちを受け付ける第1の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図7】キャンセル待ちを受け付ける第2の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図8】再発行を受け付ける第1の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図9】再発行を受け付ける第2の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図10】図1に示す基本的実施形態の変形例に係るチケット発行システムの構成を示すブロック図である。
【符号の説明】
【0134】
10…利用者端末装置
11…携帯電話
12…パソコン
13…店舗端末
20…利用施設端末装置(コード読出部)
21…デジタルカメラ(画像入力手段)
22…スキャナ装置(画像入力手段)
23…近距離通信装置(画像入力手段)
24…通信手段
25…確認処理手段
26…利用施設端末装置(画像読出部)
30…発券管理サーバ
31…発券要求受信部
32…チケット供給確認部
33…発券処理部
34…チケット情報送信部
35…発券履歴記録部
36…認証コード確認部
37…チケット印刷部
38…コード読出部
40…チケットDBサーバ
50…チケット
51…認証付顔写真画像
52…利用対象特定情報
53…チケットID
54…半券
61…キャンセル要求受信部
62…キャンセル処理部
63…キャンセル待ち記録部
64…キャンセル待ち待機記録部
71…再発行要求受信部
72…再発行処理部

【特許請求の範囲】
【請求項1】
チケットの利用対象を特定する利用対象特定情報と、チケットを利用する利用者本人の顔写真画像と、を伴う発券要求が利用者端末装置から送信されてきたときに、これを受信する発券要求受信部と、
前記発券要求に応じて、前記利用対象特定情報で特定される利用対象についてチケットの供給が可能か否かを確認するチケット供給確認部と、
前記チケット供給確認部によりチケットの供給が可能であることが確認されたときに、前記発券要求に応じて所定の認証コードを発生し、発生した認証コードを前記顔写真画像に電子透かしとして埋め込む処理を行い、前記認証コードが埋め込まれた認証付顔写真画像を作成し、前記利用対象特定情報と前記認証付顔写真画像とを含むチケット情報を生成して発券処理を行う発券処理部と、
前記発券処理部が発生した認証コードを記録する発券履歴記録部と、
前記発券処理部が生成したチケット情報を利用者端末装置に送信するチケット情報送信部と、
チケット情報に含まれている認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出すコード読出部と、
前記コード読出部により読み出された認証コードが、前記発券履歴記録部に記録されている認証コードと一致することを確認し、その結果を報知する認証コード確認部と、
を備えることを特徴とするチケット発行システム。
【請求項2】
請求項1に記載のチケット発行システムにおいて、
コード読出部が、利用者端末装置のディスプレイ画面を撮影することにより、認証付顔写真画像を取り込む機能を有することを特徴とするチケット発行システム。
【請求項3】
請求項1に記載のチケット発行システムにおいて、
コード読出部が、利用者端末装置からプリントアウトされた物理的なチケットの印刷面から、認証付顔写真画像を取り込む機能を有することを特徴とするチケット発行システム。
【請求項4】
請求項1に記載のチケット発行システムにおいて、
コード読出部が、利用者端末装置に対して有線もしくは無線通信を行うことにより、認証付顔写真画像を取り込む機能を有することを特徴とするチケット発行システム。
【請求項5】
チケットの利用対象を特定する利用対象特定情報と、チケットを利用する利用者本人の顔写真画像と、を伴う発券要求が利用者端末装置から送信されてきたときに、これを受信する発券要求受信部と、
前記発券要求に応じて、前記利用対象特定情報で特定される利用対象についてチケットの供給が可能か否かを確認するチケット供給確認部と、
前記チケット供給確認部によりチケットの供給が可能であることが確認されたときに、前記発券要求に応じて所定の認証コードを発生し、発生した認証コードを前記顔写真画像に電子透かしとして埋め込む処理を行い、前記認証コードが埋め込まれた認証付顔写真画像を作成し、前記利用対象特定情報と前記認証付顔写真画像とを含むチケット情報を生成して発券処理を行う発券処理部と、
前記発券処理部が発生した認証コードを記録する発券履歴記録部と、
前記発券処理部が生成したチケット情報を物理的な媒体上に印刷して物理的なチケットを作成するチケット印刷部と、
前記物理的なチケットに印刷されている認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出すコード読出部と、
前記コード読出部により読み出された認証コードが、前記発券履歴記録部に記録されている認証コードと一致することを確認し、その結果を報知する認証コード確認部と、
を備えることを特徴とするチケット発行システム。
【請求項6】
請求項1〜5のいずれかに記載のチケット発行システムにおいて、
コード読出部が、チケットの利用施設に設置された利用施設端末装置を構成し、認証コード確認部に対して通信手段を介して交信する機能を有し、
認証コード確認部が、前記通信手段を介してコード読出部から送信されてきた認証コードについての一致確認を行い、その結果を前記通信手段を介してコード読出部に報知する機能を有することを特徴とするチケット発行システム。
【請求項7】
請求項6に記載のチケット発行システムにおいて、
発券履歴記録部が、個々の認証コードを、対応する利用対象特定情報とともに記録する機能を有し、
コード読出部が、読み出した認証コードとともに、当該利用施設に係る利用対象特定情報を認証コード確認部に対して送信する機能を有し、
認証コード確認部が、認証コードと利用対象特定情報との双方についての一致確認を行うことを特徴とするチケット発行システム。
【請求項8】
請求項1〜7のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応するパスワードを記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、認証付顔写真画像とパスワードとを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
前記キャンセル要求に含まれていた認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出し、読み出された認証コードおよび前記キャンセル要求に含まれていたパスワードが、前記発券履歴記録部に記録されている認証コードおよびパスワードと一致することを条件として、前記発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項9】
請求項1〜7のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信する機能を有し、
発券処理部が、個々のチケットごとにユニークなチケットIDを発生し、このチケットIDを含むチケット情報を生成する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応するチケットIDおよびパスワードを記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、チケットIDとパスワードとを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
前記キャンセル要求に含まれていたパスワードが、前記キャンセル要求に含まれていたチケットIDに対応して前記発券履歴記録部に記録されていたパスワードと一致することを条件として、前記発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項10】
請求項1〜7のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、利用者本人の個人情報とパスワードとを更に伴う発券要求を受信する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応する個人情報およびパスワードを記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
前記キャンセル要求に含まれていたパスワードが、前記キャンセル要求に含まれていた利用対象特定情報および個人情報に対応して前記発券履歴記録部に記録されていたパスワードと一致することを条件として、前記発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項11】
請求項8〜10のいずれかに記載のチケット発行システムにおいて、
チケット供給確認部により、発券要求に対するチケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録するキャンセル待ち記録部を更に設け、
発券処理部が、キャンセル処理部によるキャンセル処理より、チケット供給が可能になった時点で、前記キャンセル待ちの列に記録されていた発券要求に応じた発券処理を実行することを特徴とするチケット発行システム。
【請求項12】
請求項8〜10のいずれかに記載のチケット発行システムにおいて、
チケット供給確認部により、チケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録するキャンセル待ち記録部を更に設け、
キャンセル処理部が、前記キャンセル待ちの列に発券要求が記録されていた場合にのみ、キャンセル処理を実行することを特徴とするチケット発行システム。
【請求項13】
請求項12に記載のチケット発行システムにおいて、
キャンセル要求を受信した時点でキャンセル待ちの列に発券要求が記録されていなかった場合に、当該キャンセル要求を「キャンセル待ち」を待機する列に記録する「キャンセル待ち」待機記録部を更に設け、
キャンセル処理部が、前記キャンセル待ちの列に新たな発券要求が記録された時点で、前記「キャンセル待ち」を待機する列に記録されているキャンセル要求に対するキャンセル処理を実行することを特徴とするチケット発行システム。
【請求項14】
請求項1〜13のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信する機能を有し、
発券処理部が、個々のチケットごとにユニークなチケットIDを発生し、このチケットIDを含むチケット情報を生成する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応するチケットID、パスワード、顔写真画像(もしくは認証付顔写真画像)を記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、チケットIDとパスワードとを伴う再発行要求が送信されてきたときに、これを受信する再発行要求受信部と、
前記再発行要求に含まれていたパスワードが、前記再発行要求に含まれていたチケットIDに対応して前記発券履歴記録部に記録されていたパスワードと一致することを条件として、前記発券履歴記録部の記録に基づいてチケット情報を再発行する再発行処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項15】
請求項1〜13のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、利用者本人の個人情報とパスワードとを更に伴う発券要求を受信する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応する利用対象特定情報、個人情報、パスワード、顔写真画像(もしくは認証付顔写真画像)を記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴う再発行要求が送信されてきたときに、これを受信する再発行要求受信部と、
前記再発行要求に含まれていたパスワードが、前記再発行要求に含まれていた利用対象特定情報および個人情報に対応して前記発券履歴記録部に記録されていたパスワードと一致することを条件として、前記発券履歴記録部の記録に基づいてチケット情報を再発行する再発行処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項16】
請求項1〜15に記載のチケット発行システムにおける発券要求受信部、チケット供給確認部、発券処理部、発券履歴記録部、認証コード確認部、としてコンピュータを機能させるためのプログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate


【公開番号】特開2006−201997(P2006−201997A)
【公開日】平成18年8月3日(2006.8.3)
【国際特許分類】
【出願番号】特願2005−12342(P2005−12342)
【出願日】平成17年1月20日(2005.1.20)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Bluetooth
【出願人】(000002897)大日本印刷株式会社 (14,506)
【Fターム(参考)】