(57)【要約】【課題】  チケットの購入者と利用者との同一性を確保してダフ屋行為などの不当転売を防ぎつつ、偽造防止も図る。【解決手段】  携帯電話などの利用者端末装置から、コンサートなどの利用対象を特定する利用対象特定情報と、利用者本人の顔写真画像と、を伴う発券要求（(図(a) ）を発券管理サーバへ送信させる。発券管理サーバでは、この発券要求に応じて、所定の認証コードを発生し、発生した認証コードを顔写真画像に電子透かしとして埋め込んで認証付顔写真画像５１を作成し（図(b) ）、デジタルデータの形式の電子チケット５０（図(c) ）を利用者端末装置へ返信する。利用者がコンサート会場でチケット５０を提示すると、利用施設端末装置により認証付顔写真画像５１に埋め込まれた認証コードが読み出され、真正なコードであることが確認される。また、改札係員により、顔写真を用いた本人確認が目視で行われる。【選択図】  図２
2006201997.tif 000002
【特許請求の範囲】
【請求項１】
チケットの利用対象を特定する利用対象特定情報と、チケットを利用する利用者本人の顔写真画像と、を伴う発券要求が利用者端末装置から送信されてきたときに、これを受信する発券要求受信部と、
前記発券要求に応じて、前記利用対象特定情報で特定される利用対象についてチケットの供給が可能か否かを確認するチケット供給確認部と、
前記チケット供給確認部によりチケットの供給が可能であることが確認されたときに、前記発券要求に応じて所定の認証コードを発生し、発生した認証コードを前記顔写真画像に電子透かしとして埋め込む処理を行い、前記認証コードが埋め込まれた認証付顔写真画像を作成し、前記利用対象特定情報と前記認証付顔写真画像とを含むチケット情報を生成して発券処理を行う発券処理部と、
前記発券処理部が発生した認証コードを記録する発券履歴記録部と、
前記発券処理部が生成したチケット情報を利用者端末装置に送信するチケット情報送信部と、
チケット情報に含まれている認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出すコード読出部と、
前記コード読出部により読み出された認証コードが、前記発券履歴記録部に記録されている認証コードと一致することを確認し、その結果を報知する認証コード確認部と、
を備えることを特徴とするチケット発行システム。
【請求項２】
請求項１に記載のチケット発行システムにおいて、
コード読出部が、利用者端末装置のディスプレイ画面を撮影することにより、認証付顔写真画像を取り込む機能を有することを特徴とするチケット発行システム。
【請求項３】
請求項１に記載のチケット発行システムにおいて、
コード読出部が、利用者端末装置からプリントアウトされた物理的なチケットの印刷面から、認証付顔写真画像を取り込む機能を有することを特徴とするチケット発行システム。
【請求項４】
請求項１に記載のチケット発行システムにおいて、
コード読出部が、利用者端末装置に対して有線もしくは無線通信を行うことにより、認証付顔写真画像を取り込む機能を有することを特徴とするチケット発行システム。
【請求項５】
チケットの利用対象を特定する利用対象特定情報と、チケットを利用する利用者本人の顔写真画像と、を伴う発券要求が利用者端末装置から送信されてきたときに、これを受信する発券要求受信部と、
前記発券要求に応じて、前記利用対象特定情報で特定される利用対象についてチケットの供給が可能か否かを確認するチケット供給確認部と、
前記チケット供給確認部によりチケットの供給が可能であることが確認されたときに、前記発券要求に応じて所定の認証コードを発生し、発生した認証コードを前記顔写真画像に電子透かしとして埋め込む処理を行い、前記認証コードが埋め込まれた認証付顔写真画像を作成し、前記利用対象特定情報と前記認証付顔写真画像とを含むチケット情報を生成して発券処理を行う発券処理部と、
前記発券処理部が発生した認証コードを記録する発券履歴記録部と、
前記発券処理部が生成したチケット情報を物理的な媒体上に印刷して物理的なチケットを作成するチケット印刷部と、
前記物理的なチケットに印刷されている認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出すコード読出部と、
前記コード読出部により読み出された認証コードが、前記発券履歴記録部に記録されている認証コードと一致することを確認し、その結果を報知する認証コード確認部と、
を備えることを特徴とするチケット発行システム。
【請求項６】
請求項１〜５のいずれかに記載のチケット発行システムにおいて、
コード読出部が、チケットの利用施設に設置された利用施設端末装置を構成し、認証コード確認部に対して通信手段を介して交信する機能を有し、
認証コード確認部が、前記通信手段を介してコード読出部から送信されてきた認証コードについての一致確認を行い、その結果を前記通信手段を介してコード読出部に報知する機能を有することを特徴とするチケット発行システム。
【請求項７】
請求項６に記載のチケット発行システムにおいて、
発券履歴記録部が、個々の認証コードを、対応する利用対象特定情報とともに記録する機能を有し、
コード読出部が、読み出した認証コードとともに、当該利用施設に係る利用対象特定情報を認証コード確認部に対して送信する機能を有し、
認証コード確認部が、認証コードと利用対象特定情報との双方についての一致確認を行うことを特徴とするチケット発行システム。
【請求項８】
請求項１〜７のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応するパスワードを記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、認証付顔写真画像とパスワードとを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
前記キャンセル要求に含まれていた認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出し、読み出された認証コードおよび前記キャンセル要求に含まれていたパスワードが、前記発券履歴記録部に記録されている認証コードおよびパスワードと一致することを条件として、前記発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項９】
請求項１〜７のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信する機能を有し、
発券処理部が、個々のチケットごとにユニークなチケットＩＤを発生し、このチケットＩＤを含むチケット情報を生成する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応するチケットＩＤおよびパスワードを記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、チケットＩＤとパスワードとを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
前記キャンセル要求に含まれていたパスワードが、前記キャンセル要求に含まれていたチケットＩＤに対応して前記発券履歴記録部に記録されていたパスワードと一致することを条件として、前記発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項１０】
請求項１〜７のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、利用者本人の個人情報とパスワードとを更に伴う発券要求を受信する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応する個人情報およびパスワードを記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
前記キャンセル要求に含まれていたパスワードが、前記キャンセル要求に含まれていた利用対象特定情報および個人情報に対応して前記発券履歴記録部に記録されていたパスワードと一致することを条件として、前記発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項１１】
請求項８〜１０のいずれかに記載のチケット発行システムにおいて、
チケット供給確認部により、発券要求に対するチケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録するキャンセル待ち記録部を更に設け、
発券処理部が、キャンセル処理部によるキャンセル処理より、チケット供給が可能になった時点で、前記キャンセル待ちの列に記録されていた発券要求に応じた発券処理を実行することを特徴とするチケット発行システム。
【請求項１２】
請求項８〜１０のいずれかに記載のチケット発行システムにおいて、
チケット供給確認部により、チケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録するキャンセル待ち記録部を更に設け、
キャンセル処理部が、前記キャンセル待ちの列に発券要求が記録されていた場合にのみ、キャンセル処理を実行することを特徴とするチケット発行システム。
【請求項１３】
請求項１２に記載のチケット発行システムにおいて、
キャンセル要求を受信した時点でキャンセル待ちの列に発券要求が記録されていなかった場合に、当該キャンセル要求を「キャンセル待ち」を待機する列に記録する「キャンセル待ち」待機記録部を更に設け、
キャンセル処理部が、前記キャンセル待ちの列に新たな発券要求が記録された時点で、前記「キャンセル待ち」を待機する列に記録されているキャンセル要求に対するキャンセル処理を実行することを特徴とするチケット発行システム。
【請求項１４】
請求項１〜１３のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信する機能を有し、
発券処理部が、個々のチケットごとにユニークなチケットＩＤを発生し、このチケットＩＤを含むチケット情報を生成する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応するチケットＩＤ、パスワード、顔写真画像（もしくは認証付顔写真画像）を記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、チケットＩＤとパスワードとを伴う再発行要求が送信されてきたときに、これを受信する再発行要求受信部と、
前記再発行要求に含まれていたパスワードが、前記再発行要求に含まれていたチケットＩＤに対応して前記発券履歴記録部に記録されていたパスワードと一致することを条件として、前記発券履歴記録部の記録に基づいてチケット情報を再発行する再発行処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項１５】
請求項１〜１３のいずれかに記載のチケット発行システムにおいて、
発券要求受信部が、利用者本人の個人情報とパスワードとを更に伴う発券要求を受信する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応する利用対象特定情報、個人情報、パスワード、顔写真画像（もしくは認証付顔写真画像）を記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴う再発行要求が送信されてきたときに、これを受信する再発行要求受信部と、
前記再発行要求に含まれていたパスワードが、前記再発行要求に含まれていた利用対象特定情報および個人情報に対応して前記発券履歴記録部に記録されていたパスワードと一致することを条件として、前記発券履歴記録部の記録に基づいてチケット情報を再発行する再発行処理部と、
を更に備えることを特徴とするチケット発行システム。
【請求項１６】
請求項１〜１５に記載のチケット発行システムにおける発券要求受信部、チケット供給確認部、発券処理部、発券履歴記録部、認証コード確認部、としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、チケット発行システムに関し、特に、利用者の本人確認を行うことができ、偽造防止機能を有する電子チケットもしくは物理的チケットを発行するためのシステムに関する。また、このシステムにより発行されたチケットをキャンセルしたり、再発行したりする技術に関する。
【背景技術】
【０００２】
コンサートやスポーツ観戦などのイベントでは、通常、主催者が予めチケットの発行を行い、イベント会場においてチケットの提示を求める入場方法が採られている。列車や航空機の運航においても、乗車券や航空券といったチケットを予め発行しておき、搭乗前に改札を行うのが一般的である。また、チケットは、イベントの開催日時や場所を提示したり、交通機関の発着日時や時間を提示したりする役割も担っている。
【０００３】
最近は、オンラインでチケットの申し込みを行うことも可能であり、自宅のパソコン、携帯電話、コンビニエンスストアなどの店舗端末からチケットの購入申し込みを行うと、郵送もしくは店頭引き換えといった形態で、チケットの入手が可能である。また、物理的なチケットを発行する代わりに、電子チケットの発行を行うシステムも提案されており、利用者は、デジタルデータの形式で発行された電子チケットを、携帯電話などの端末装置を用いてネットワーク経由で受信することもできる。
【０００４】
たとえば、下記の特許文献１には、携帯電話に装着されたＩＣカードに、電子チケットを格納しておき、イベント会場の入り口でこれをチェックするシステムが開示されている。また、特許文献２には、このような電子チケットの信頼性を高めるために、電子チケットのデータに電子透かしを埋め込む技術が開示されており、特許文献３には、チケット利用者の指紋や声紋などの生体情報を利用して認証を行う技術が開示されている。
【特許文献１】特開２００４−１８５５２９号公報
【特許文献２】特開２００４−０７８４２９号公報
【特許文献３】特開２００４−２９５１９７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
人気のあるコンサートやスポーツイベントでは、チケットの購入希望者が殺到し、入手が困難なプレミアチケットともなると、極めて高額で取引される例も少なくない。これは、夏期や年末という繁忙期における乗車券や航空券といったチケットについても同様である。このため、このような状況につけ込んだ悪徳業者が、チケットを意図的に買い占めて高額で販売することにより不当な利潤をあげる、いわゆるダフ屋行為を行うことが社会問題となってきており、更には、チケットの偽造という犯罪行為に至ることもある。
【０００６】
一方、従来のチケット発行システムでは、一度発行したチケットをキャンセルしたり、再発行したりする処理を円滑に行うことができなかったため、チケットの購入者は、未使用チケットに対する払い戻しを受けられなかったり、チケット紛失による損害を被ったりする弊害があった。特に、コンサートやスポーツ観戦などのイベントでは、チケットのキャンセルや再発行には全く応じない例も少なくない。
【０００７】
そこで本発明は、チケット購入者とチケット利用者との同一性を確保しつつ、偽造防止が可能なチケット発行システムを提供することを目的とし、また、チケットのキャンセルや再発行を容易に行うことができるチケット発行システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
(1)   本発明の第１の態様は、図１の実施形態にその一例が示されているとおり、チケット発行システムにおいて、
チケットの利用対象を特定する利用対象特定情報と、チケットを利用する利用者本人の顔写真画像と、を伴う発券要求が利用者端末装置から送信されてきたときに、これを受信する発券要求受信部と、
この発券要求に応じて、利用対象特定情報で特定される利用対象についてチケットの供給が可能か否かを確認するチケット供給確認部と、
チケット供給確認部によりチケットの供給が可能であることが確認されたときに、発券要求に応じて所定の認証コードを発生し、発生した認証コードを顔写真画像に電子透かしとして埋め込む処理を行い、認証コードが埋め込まれた認証付顔写真画像を作成し、利用対象特定情報と認証付顔写真画像とを含むチケット情報を生成して発券処理を行う発券処理部と、
発券処理部が発生した認証コードを記録する発券履歴記録部と、
発券処理部が生成したチケット情報を利用者端末装置に送信するチケット情報送信部と、
チケット情報に含まれている認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出すコード読出部と、
コード読出部により読み出された認証コードが、発券履歴記録部に記録されている認証コードと一致することを確認し、その結果を報知する認証コード確認部と、
を設けるようにしたものである。
【０００９】
(2)   本発明の第２の態様は、図１の実施形態にその一例が示されているとおり、上述の第１の態様に係るチケット発行システムにおいて、
コード読出部が、利用者端末装置のディスプレイ画面をデジタルカメラなどを利用して撮影することにより、認証付顔写真画像を取り込むことができるようにしたものである。
【００１０】
(3)   本発明の第３の態様は、図１の実施形態にその一例が示されているとおり、上述の第１の態様に係るチケット発行システムにおいて、
コード読出部が、利用者端末装置からプリントアウトされた物理的なチケットの印刷面から、スキャナ装置などを利用して認証付顔写真画像を取り込むことができるようにしたものである。
【００１１】
(4)   本発明の第４の態様は、図１の実施形態にその一例が示されているとおり、上述の第１の態様に係るチケット発行システムにおいて、
コード読出部が、通信装置を利用して利用者端末装置に対して有線もしくは無線通信を行うことにより、認証付顔写真画像を取り込むことができるようにしたものである。
【００１２】
(5)   本発明の第５の態様は、図３の実施形態にその一例が示されているとおり、チケット発行システムにおいて、
チケットの利用対象を特定する利用対象特定情報と、チケットを利用する利用者本人の顔写真画像と、を伴う発券要求が利用者端末装置から送信されてきたときに、これを受信する発券要求受信部と、
この発券要求に応じて、利用対象特定情報で特定される利用対象についてチケットの供給が可能か否かを確認するチケット供給確認部と、
チケット供給確認部によりチケットの供給が可能であることが確認されたときに、発券要求に応じて所定の認証コードを発生し、発生した認証コードを顔写真画像に電子透かしとして埋め込む処理を行い、認証コードが埋め込まれた認証付顔写真画像を作成し、利用対象特定情報と認証付顔写真画像とを含むチケット情報を生成して発券処理を行う発券処理部と、
発券処理部が発生した認証コードを記録する発券履歴記録部と、
発券処理部が生成したチケット情報を物理的な媒体上に印刷して物理的なチケットを作成するチケット印刷部と、
物理的なチケットに印刷されている認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出すコード読出部と、
コード読出部により読み出された認証コードが、発券履歴記録部に記録されている認証コードと一致することを確認し、その結果を報知する認証コード確認部と、
を設けるようにしたものである。
【００１３】
(6)   本発明の第６の態様は、図１および図３の実施形態にその一例が示されているとおり、上述の第１〜５の態様に係るチケット発行システムにおいて、
コード読出部が、チケットの利用施設に設置された利用施設端末装置を構成し、認証コード確認部に対して通信手段を介して交信できるようにし
認証コード確認部が、通信手段を介してコード読出部から送信されてきた認証コードについての一致確認を行い、その結果を通信手段を介してコード読出部に報知できるようにしたものである。
【００１４】
(7)   本発明の第７の態様は、図１および図３の実施形態にその一例が示されているとおり、上述の第６の態様に係るチケット発行システムにおいて、
発券履歴記録部が、個々の認証コードを、対応する利用対象特定情報とともに記録するようにし、
コード読出部が、読み出した認証コードとともに、当該利用施設に係る利用対象特定情報を認証コード確認部に対して送信するようにし、
認証コード確認部が、認証コードと利用対象特定情報との双方についての一致確認を行うようにしたものである。
【００１５】
(8)   本発明の第８の態様は、図４の実施形態にその一例が示されているとおり、上述の第１〜第７の態様に係るチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信するようにし、
発券履歴記録部が、認証コードとともにこれに対応するパスワードを記録するようにし、
利用者端末装置から、既に発券済みのチケットに関して、認証付顔写真画像とパスワードとを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
このキャンセル要求に含まれていた認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出し、読み出された認証コードおよびキャンセル要求に含まれていたパスワードが、発券履歴記録部に記録されている認証コードおよびパスワードと一致することを条件として、発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に設けるようにしたものである。
【００１６】
(9)   本発明の第９の態様は、図４の実施形態にその一例が示されているとおり、上述の第１〜第７の態様に係るチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信するようにし、
発券処理部が、個々のチケットごとにユニークなチケットＩＤを発生し、このチケットＩＤを含むチケット情報を生成するようにし、
発券履歴記録部が、認証コードとともにこれに対応するチケットＩＤおよびパスワードを記録するようにし、
利用者端末装置から、既に発券済みのチケットに関して、チケットＩＤとパスワードとを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
このキャンセル要求に含まれていたパスワードが、このキャンセル要求に含まれていたチケットＩＤに対応して発券履歴記録部に記録されていたパスワードと一致することを条件として、発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に設けるようにしたものである。
【００１７】
(10)  本発明の第１０の態様は、図５の実施形態にその一例が示されているとおり、上述の第１〜第７の態様に係るチケット発行システムにおいて、
発券要求受信部が、利用者本人の個人情報とパスワードとを更に伴う発券要求を受信するようにし、
発券履歴記録部が、認証コードとともにこれに対応する個人情報およびパスワードを記録するようにし、
利用者端末装置から、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴うキャンセル要求が送信されてきたときに、これを受信するキャンセル要求受信部と、
このキャンセル要求に含まれていたパスワードが、このキャンセル要求に含まれていた利用対象特定情報および個人情報に対応して発券履歴記録部に記録されていたパスワードと一致することを条件として、発券履歴記録部の当該記録を無効化してキャンセル処理を行うキャンセル処理部と、
を更に設けるようにしたものである。
【００１８】
(11)  本発明の第１１の態様は、図６の実施形態にその一例が示されているとおり、上述の第８〜第１０の態様に係るチケット発行システムにおいて、
チケット供給確認部により、発券要求に対するチケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録するキャンセル待ち記録部を更に設け、
発券処理部が、キャンセル処理部によるキャンセル処理より、チケット供給が可能になった時点で、キャンセル待ちの列に記録されていた発券要求に応じた発券処理を実行するようにしたものである。
【００１９】
(12)  本発明の第１２の態様は、図６の実施形態にその一例が示されているとおり、上述の第８〜第１０の態様に係るチケット発行システムにおいて、
チケット供給確認部により、チケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録するキャンセル待ち記録部を更に設け、
キャンセル処理部が、キャンセル待ちの列に発券要求が記録されていた場合にのみ、キャンセル処理を実行するようにしたものである。
【００２０】
(13)  本発明の第１３の態様は、図７の実施形態にその一例が示されているとおり、上述の第１２の態様に係るチケット発行システムにおいて、
キャンセル要求を受信した時点でキャンセル待ちの列に発券要求が記録されていなかった場合に、当該キャンセル要求を「キャンセル待ち」を待機する列に記録する「キャンセル待ち」待機記録部を更に設け、
キャンセル処理部が、キャンセル待ちの列に新たな発券要求が記録された時点で、「キャンセル待ち」を待機する列に記録されているキャンセル要求に対するキャンセル処理を実行するようにしたものである。
【００２１】
(14)  本発明の第１４の態様は、図８の実施形態にその一例が示されているとおり、上述の第１〜第１３の態様に係るチケット発行システムにおいて、
発券要求受信部が、パスワードを更に伴う発券要求を受信するようにし、
発券処理部が、個々のチケットごとにユニークなチケットＩＤを発生し、このチケットＩＤを含むチケット情報を生成するようにし、
発券履歴記録部が、認証コードとともにこれに対応するチケットＩＤ、パスワード、顔写真画像（もしくは認証付顔写真画像）を記録するようにし、
利用者端末装置から、既に発券済みのチケットに関して、チケットＩＤとパスワードとを伴う再発行要求が送信されてきたときに、これを受信する再発行要求受信部と、
この再発行要求に含まれていたパスワードが、この再発行要求に含まれていたチケットＩＤに対応して発券履歴記録部に記録されていたパスワードと一致することを条件として、発券履歴記録部の記録に基づいてチケット情報を再発行する再発行処理部と、
を更に設けるようにしたものである。
【００２２】
(15)  本発明の第１５の態様は、図９の実施形態にその一例が示されているとおり、上述の第１〜第１３の態様に係るチケット発行システムにおいて、
発券要求受信部が、利用者本人の個人情報とパスワードとを更に伴う発券要求を受信する機能を有し、
発券履歴記録部が、認証コードとともにこれに対応する利用対象特定情報、個人情報、パスワード、顔写真画像（もしくは認証付顔写真画像）を記録する機能を有し、
利用者端末装置から、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴う再発行要求が送信されてきたときに、これを受信する再発行要求受信部と、
この再発行要求に含まれていたパスワードが、この再発行要求に含まれていた利用対象特定情報および個人情報に対応して発券履歴記録部に記録されていたパスワードと一致することを条件として、発券履歴記録部の記録に基づいてチケット情報を再発行する再発行処理部と、
を更に設けるようにしたものである。
【００２３】
(16)  本発明の第１６の態様は、上述の第１〜第１５の態様に係るチケット発行システムにおける発券要求受信部、チケット供給確認部、発券処理部、発券履歴記録部、認証コード確認部を、コンピュータにプログラムを組み込むことにより構成したものである。
【発明の効果】
【００２４】
本発明に係るチケット発行システムによれば、購入者自身の顔写真に所定の認証コードを電子透かしとして埋め込んだ画像を有する電子チケットもしくは物理的チケットを発行することが可能になる。このため、チケットの利用時に、検札係員がチケット上の顔写真を照合することにより、利用者が購入者と同一であることを確認することができ、また、顔写真に埋め込まれた認証コード読み出すことにより、当該チケットが真正のものであることを確認することができる。しかも、発券履歴記録部に記録されている発券履歴を参照することにより、チケットのキャンセルや再発行を容易に行うことができるようになる。
【発明を実施するための最良の形態】
【００２５】
以下、本発明を図示する実施形態に基づいて説明する。
【００２６】
＜＜＜  §１．基本的な実施形態の全体構成  ＞＞＞
図１は、本発明の基本的な実施形態に係るチケット発行システムの構成を示すブロック図である。図には、利用者端末装置１０、利用施設端末装置２０、発券管理サーバ３０、チケットＤＢサーバ４０なる構成要素がそれぞれブロックとして示されているが、本発明に係るチケット発行システムは、これらのうち、利用施設端末装置２０および発券管理サーバ３０によって構成されるシステムである。なお、本発明に係るチケット発行システムは、単に、チケットの発行を行うだけのシステムではなく、発行したチケットを利用者が利用する時点において、当該チケットの認証処理までも行うシステムである。
【００２７】
利用者端末装置１０は、チケットの利用者が、チケットの発券（購入）を申し込むために用いる装置であり、発券管理サーバ３０にアクセスする機能をもった装置であれば、どのような装置を利用者端末装置１０として用いてもかまわない。実用上は、図１に示されているとおり、携帯電話１１やパソコン１２が、利用者端末装置１０として用いられるケースが多いであろう。店舗端末１３は、たとえば、コンビニエンスストアなどの店舗に設置された端末装置であり、利用者が店舗に来店して操作することを前提として用いられる。なお、図では、便宜上、１つの利用者端末装置１０のみがブロックとして示されているが、実際には、もちろん、多数の利用者が、それぞれ別個の利用者端末装置１０を利用して、発券管理サーバ３０へアクセスすることになる。
【００２８】
利用者端末装置１０と発券管理サーバ３０との間には、何らかの交信手段が設けられている必要がある。たとえば、両者間に専用通信路を確保してもかまわないが、実用上は、インターネットを介して両者間の通信を行うようにすれば十分である。発券管理サーバ３０側の窓口となる部分をＷｅｂサーバによって構成するようにすれば、利用者端末装置１０は、Ｗｅｂブラウザ機能により発券管理サーバ３０に対してアクセスすることが可能になるので、汎用の携帯電話１１やパソコン１２をそのまま利用者端末装置１０として用いることができるようになる。店舗端末１３の場合は、専用線を用いて発券管理サーバ３０にオンライン接続するのが一般的である。
【００２９】
これに対して、利用施設端末装置２０は、チケットの利用施設に設置された端末装置であり、やはり発券管理サーバ３０との間に設けられた交信手段を介して、通信を行う機能を有している。ここで、チケットの利用施設とは、たとえば、コンサートのチケットであればコンサートホール、野球の観戦チケットであれば野球場、乗車券や航空券であれば駅や空港ということになる。実際には、この利用施設端末装置２０は、個々の利用施設のチケット改札場所に設置して利用される。利用施設端末装置２０と発券管理サーバ３０との間の交信手段も、専用線によって実現してもよいし、インターネットを利用して実現してもよい。
【００３０】
この利用施設端末装置２０の主たる機能は、利用者が提示したチケットから、認証コードを読み出し、これが正しいものであるか否かを発券管理サーバ３０に照会することにある。そこで、まず、チケットから認証付顔写真画像を読み込むために、利用施設端末装置２０には、デジタルカメラ２１、スキャナ装置２２、近距離通信装置２３のような画像入力手段が備わっている。また、利用施設端末装置２０には、発券管理サーバ３０に対する通信手段２４と、認証コードの確認処理を実行する確認処理手段２５と、が備わっている。確認処理手段２５は、画像入力手段２１〜２３によってデジタルデータとして取り込まれた認証付顔写真画像から、埋め込まれていた認証コードを読み出す処理を行う。この認証コードは、通信手段２４によって、発券管理サーバ３０へと送信される。
【００３１】
発券管理サーバ３０は、本発明に係るチケット発行システムの本体ともいうべき構成要素であり、図示のとおり、発券要求受信部３１、チケット供給確認部３２、発券処理部３３、チケット情報送信部３４、発券履歴記録部３５、認証コード確認部３６の各構成要素を有している。もっとも、これらの各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより実現されるものである。
【００３２】
本発明に係るチケット発行システムは、この発券管理サーバ３０を構成する各構成要素３１〜３６に、利用施設端末装置２０を加えることにより実現されるシステムということができる。利用施設端末装置２０は、いわば本発明に係るシステムにおける出先機関として機能することになり、利用施設の現場において、利用者が提示したチケットから認証コードを読み出す働きをする。そこで、以下の説明では、利用施設端末装置２０を、その機能に着目して、「コード読出部２０」と呼ぶことにする。
【００３３】
結局、図１に示す基本的な実施形態の場合、発券要求受信部３１、チケット供給確認部３２、発券処理部３３、チケット情報送信部３４、発券履歴記録部３５、認証コード確認部３６、そしてコード読出部２０によって、本発明に係るチケット発行システムが構成されていることになる。なお、図では、便宜上、１つのコード読出部２０のみがブロックとして示されているが、実際には、コード読出部２０は、個々の利用施設ごとにそれぞれ設置されることになるので、実用上、発券管理サーバ３０は複数のコード読出部２０と交信することになる。
【００３４】
一方、チケットＤＢサーバ４０は、個々のコンサートやスポーツイベント、個々の列車や航空機についての１枚１枚のチケットの発行状態を管理するためのデータベースサーバであり、具体的には、個々のイベント会場、列車、航空機などの座席の配置に関する情報および１つ１つの座席について発券済であるか否かを示す情報が格納されている。このような機能をもったチケットＤＢサーバ４０は、既に従来から利用されている公知のシステムであるため、ここではその詳細な説明は省略する。後述するように、本発明に係るチケット発行システムは、このような従来から利用されているチケットＤＢサーバ４０へ空席の照会を行った上で、チケットの発行処理を行うことになる。
【００３５】
通常、個々の事業体は、それぞれ独自にチケットＤＢサーバ４０を設置しているので、たとえば、コンサートを主催する事業体、野球の試合を主催する事業体、列車を運行させる鉄道会社、航空機を運航させる航空会社などは、それぞれ別個独立したチケットＤＢサーバ４０を設置することになる。したがって、本発明に係るチケット発行システムにより、種々のチケットを取り扱う幅広い運用を行うのであれば、発券管理サーバ３０は、それぞれの事業体が設置したチケットＤＢサーバ４０に空席の照会を行う必要がある。
【００３６】
＜＜＜  §２．基本的な実施形態におけるチケットの発行  ＞＞＞
続いて、この図１に示す基本的な実施形態に係るチケット発行システムの個々の構成要素の機能を順に説明する。まず、発券要求受信部３１は、利用者端末装置１０から送信されてくる発券要求を受信する機能を有する。利用者は、利用者端末装置１０を用いて発券要求受信部３１へとアクセスを行い、所望のチケットについての発券要求を行うことになる。この発券要求には、少なくとも、利用対象特定情報と顔写真画像とが含まれている必要がある。図１に楕円で囲って示した「利用対象」および「顔写真」は、発券要求に含まれる「利用対象特定情報」および「顔写真画像」を示すものである。
【００３７】
本願にいう「利用対象」とは、「チケットの利用対象」を意味するものであり、特定の日時に特定の場所で開催される各種イベントや、特定の日時に特定の場所で提供される種々のサービスを意味するものである。たとえば、「２００４年１２月２４日の１８：００から、東京×××体育館で開催される○○○○コンサート」なるイベントは、本願にいう「チケットの利用対象」の１つであり、「２００４年１２月２４日、１８：００東京駅発、博多行き新幹線」なる運輸サービスも、本願にいう「チケットの利用対象」の１つである。
【００３８】
発券要求に含まれる「利用対象特定情報」は、このようなチケットの利用対象を特定する情報であり、「何に関するチケットを申し込みたいのか」という利用者の意志表示を示す情報になる。本発明のユニークな点は、このような「利用対象特定情報」とともに「顔写真画像」を含んだ発券要求の送信を前提としている点である。ここで、「顔写真画像」とは、チケットを利用する利用者本人の顔写真の画像を意味する。重要な点は、チケットの申込者の顔写真ではなく、チケットの利用者の顔写真である必要がある点である。すなわち、コンサートのチケットであれば、当該コンサートに実際に入場して鑑賞する本人の顔写真である必要があり、列車の乗車チケットであれば、当該列車に乗車する本人の顔写真である必要がある。
【００３９】
発券要求受信部３１は、このように、利用者端末装置１０から、利用対象特定情報と顔写真画像とを含む発券要求が送信されてきたときに、これを受信する機能を有する構成要素であるが、実用上は、利用者端末装置１０に対して、種々のガイドメッセージを送信し、利用者端末装置１０から利用対象特定情報と顔写真画像とを含む発券要求を送信する処理が円滑に行われるような支援機能を、発券要求受信部３１側に設けておくのが好ましい。たとえば、利用者端末装置１０として、携帯電話１１やパソコン１２が利用されるのであれば、発券要求受信部３１の機能の一部をＷｅｂサーバに担当させ、ガイド用のＷｅｂページを携帯電話１１やパソコン１２の画面上に表示させ、利用者が、このＷｅｂページ上の指示に従った操作を行うと、必要な情報を含んだ発券要求が自動送信されるような仕様にしておくのが好ましい。利用者端末装置１０から顔写真画像を送信する方法としては、電子メールの添付書類として送信してもらうことも可能であるが、利用者端末装置１０内にファイル転送用のプログラムを予めインストールしておき、このプログラムを利用して送信するようにしてもよい。
【００４０】
なお、利用対象特定情報としては、必ずしも「２００４年１２月２４日の１８：００から、東京×××体育館で開催される○○○○コンサート」のような文字情報を用いる必要はなく、発券要求受信部３１側において１つの利用対象を特定することが可能な情報であれば、どのような情報を利用対象特定情報として用いてもかまわない。たとえば、発券要求受信部３１側から利用者端末装置１０側に、コンサートの一覧リストをＷｅｂページのデータとして送信し、利用者に、このＷｅｂページ上のリストから所望のコンサート名を選択してクリックしてもらうようにすれば、発券要求受信部３１側において、リスト上の１つのコンサートを利用対象として特定することが可能である。この場合、「リスト上の特定の位置を示すデータ」が、「利用対象特定情報」として用いられたことになる。要するに、利用者端末装置１０側の操作により、何らかの利用対象を特定することが可能な情報であれば、どのような情報を利用対象特定情報として用いてもかまわない。
【００４１】
一方、顔写真画像は、利用者側で用意する必要がある。最近は、デジタルカメラの普及により、利用者が自己の顔を撮影してデジタルデータからなる顔写真画像を得ることは、比較的容易である。特に、利用者端末装置１０としてデジタルカメラ付きの携帯電話を用いている場合には、別途、デジタルカメラを用意する必要もない。また、利用者端末装置１０として、コンビニエンスストアなどに設置された店舗端末１３を用いる場合には、この店舗端末１３自身にデジタルカメラを組み込んでおくようにし、発券要求を送信する際に、利用者の顔写真を自動的に撮影して送信する機能をもたせておくと便利である。
【００４２】
さて、こうして発券要求受信部３１により、発券要求が受信されると、チケット供給確認部３２によって、受信された発券要求に含まれている利用対象特定情報で特定される利用対象について、チケットの供給が可能か否かを確認する処理が行われる。図示の実施形態では、チケット供給確認部３２からチケットＤＢサーバ４０に対して、発券要求に係る利用対象についての空席の有無が照会されることになる。もちろん、利用対象特定情報には、Ｓ席／Ａ席／Ｂ席などの希望を含ませておけば、チケット供給確認部３２は、当該希望に合致した空席の有無を照会することができる。
【００４３】
発券要求に係る利用対象についての空席が確認できた場合、別言すれば、チケット供給確認部３２によりチケットの供給が可能であることが確認された場合、以下に述べるような手順により、発券処理部３３による発券処理が実行される。逆に、発券要求に係る利用対象についての空席がない場合には、発券要求受信部３１から利用者端末装置１０に対して、希望のチケットは調達できない旨の回答が送信される。
【００４４】
発券処理部３３による発券処理では、まず、発券要求に応じて所定の認証コードの発生が行われる。この認証コードは、後に、チケットの真正性を確認するために利用されるコードであり、基本的には、個々のチケットごとにユニークなコードにしておくのが好ましい。また、セキュリティを向上させるためには、悪意ある者に類推されることがないように、ある程度複雑なコードにしておくのが好ましい。実用上は、発券処理部３３内に、所定のアルゴリズムに基づいて、ユニークな認証コードを自動発生させるプログラムを用意しておき、発券処理を行うたびに、新たな認証コードが生成されるようにしておけばよい。
【００４５】
続いて、発生した認証コードを、発券要求とともに送信されてきた顔写真画像に、電子透かしとして埋め込む画像処理が行われる。電子透かしの技術は、既に公知の技術であるため、ここでは詳しい説明は省略するが、この技術により、認証コードが埋め込まれた認証付顔写真画像を作成することが可能になる。元の顔写真画像と認証付顔写真画像との差は、肉眼観察した程度では認識できないが、認証付顔写真画像については、埋め込み処理と逆のプロセスの画像処理を実行すると、電子透かしとして埋め込まれていた認証コードを読み出すことが可能になる。
【００４６】
こうして、認証付顔写真画像が作成できたら、発券要求に含まれていた利用対象特定情報と作成した認証付顔写真画像とを含むチケット情報が生成される。なお、ここに示す実施形態では、発券処理部３３において、個々のチケットのシリアル番号に相当するチケットＩＤを発生させ、これをチケット情報に含ませるようにしている。結局、発券処理部３３によって生成されるチケット情報には、利用対象特定情報、認証付顔写真画像、チケットＩＤが含まれていることになる。本発明を実施するにあたって、チケットＩＤは必ずしも必須のものではないが、実用上は、個々のチケットを区別するための便宜を図るため、チケットＩＤを用いるのが好ましい。なお、チケットＩＤは、同一の利用対象に関して発行された個々のチケットを区別することができればよいので、利用対象ごとにそれぞれユニークなＩＤになっていれば足りる。
【００４７】
また、座席番号などを指定する必要があるチケットの場合、発券処理部３３は、この座席番号などを含むチケット情報を生成する処理を行う。この場合、座席番号などは、チケットＤＢサーバ４０への照会により得ることができる。また、発券処理部３３は、チケットＤＢサーバ４０に対しても、チケット発行に伴い必要な記録を行う。すなわち、発券処理部３３は、チケット情報の生成に伴い、チケットＤＢサーバ４０内のデータベースに対して、空席を１つ減じる書き換え処理を実行する。
【００４８】
こうして生成されたチケット情報は、チケット情報送信部３４へと送られる。このチケット情報送信部３４は、発券処理部３３が生成したチケット情報を、利用者端末装置１０に送信する役割を果たす。上述したとおり、ここに示す実施形態の場合、チケット情報は、利用対象特定情報、認証付顔写真画像、チケットＩＤなるデータの集合体であり、利用者端末装置１０に対する送信方法は、利用者端末装置１０の形態に応じて適宜選択することが可能である。
【００４９】
たとえば、利用者端末装置１０として、携帯電話１１やパソコン１２が用いられている場合には、電子メールを利用してチケット情報の送信が可能である。この場合、発券要求に、チケット情報の返信先の電子メールアドレスを入れておくようにすればよい。また、利用者端末装置１０として店舗端末１３が用いられている場合には、当該店舗端末１３に対して、オンライン経由でチケット情報を送信することが可能である。この場合、店舗端末１３にプリンタを組み込んでおき、送信されてきたチケット情報を紙面上に印刷することができるようにしておけば、利用者は、その場で物理的なチケットを持ち帰ることができる。
【００５０】
なお、発券要求を送信する利用者端末装置１０と、チケット情報を受信する利用者端末装置１０とは、必ずしも同一の装置である必要はない。たとえば、パソコン１２で発券要求を送信し、携帯電話１１でチケット情報を受信してもよいし、店舗端末１３で発券要求を送信し、パソコン１２でチケット情報を受信するようなことも可能である。
【００５１】
一方、発券履歴記録部３５は、発券処理部３３によって行われた発券処理の履歴を記録する機能をもった構成要素である。原理的には、発券履歴記録部３５には、発券処理部３３が発生した認証コードだけを記録しておけば足りるが、ここに示す実施形態の場合、認証コードとともに、これに対応する利用対象特定情報とチケットＩＤとを併せて記録するようにしてある。図には、「○○○○コンサート２００４／１２／２４  １８：００」なる利用対象特定情報と、「ＣＫ００１」なるチケットＩＤと、「ＸＹＺ７８９」なる認証コードと、が互いに対応する情報として、発券履歴記録部３５内に記録された状態が例示されている。
【００５２】
＜＜＜  §３．基本的な実施形態におけるチケットの利用  ＞＞＞
前述の§２では、利用者からの発券要求に応じてチケット情報を発送する処理に用いられる個々の構成要素およびその機能を述べたが、この§３では、利用者がチケットを利用する際に、当該チケットを認証する処理に用いられる構成要素およびその機能を述べる。
【００５３】
ここでは、便宜上、図２に示すような具体的な事例について、以下の説明を行うことにする。図２(a) は、§２のプロセスにおいて、発券要求とともに発券管理サーバ３０側へと送信されたデータの一例を示す概念図である。前述したとおり、発券要求には、利用対象特定情報と顔写真画像とが含まれている。図示の例では、利用対象特定情報は、「２００４年１２月２４日１８：００より公演の○○○○コンサート」を特定するデータによって構成されている。このデータは、必ずしも前掲のような文字列からなるデータである必要はなく、発券管理サーバ３０側で利用対象を特定することが可能であれば、任意のコードを利用対象特定情報として用いることができる。顔写真画像は、たとえば、ＪＰＥＧやＧＩＦフォーマットの画像データから構成されている。
【００５４】
図２(b) は、このような発券要求に応じて、発券処理部３３において行われる埋め込み処理の概念図である。図示の例では、「ＸＹＺ７８９」なる認証コードが発生され、顔写真画像に電子透かしとして埋め込む処理が行われた状態が示されている。認証付顔写真画像は、肉眼で観察する限りは、元の顔写真画像と区別できないが、デジタル処理により「ＸＹＺ７８９」なる認証コードが埋め込まれた状態となっている。
【００５５】
図２(c) は、発券処理部３３によって生成されたチケット情報の一例を示す平面図である。チケット情報は、図示のとおり、肉眼で認識できるチケット５０を示す情報であり、利用者は、このようなチケット情報を受信した上で、これをディスプレイ画面上に表示させたり（電子チケットとして機能する）、プリンタで紙面上に出力させたり（物理的なチケットとして機能する）することができる。チケット５０上には、認証付顔写真画像５１と、利用対象特定情報５２と、チケットＩＤ５３とが表示されており、右側には半券５４が設けられている。この例では、利用対象特定情報５２として、コンサート名、日付、時刻、場所を示す情報のほか、座席番号やチケット金額を示す情報まで掲載しているが、もちろん、これは一例として示したものであり、利用対象を特定することが可能な情報であれば、利用対象特定情報５２をどのような情報により構成してもかまわない。
【００５６】
なお、図示のチケット５０において、チケットＩＤ５３は、本発明を実施する上で必須の構成要素ではないので、省略することも可能であるが、実用上は、個々のチケットを特定するためのＩＤとして用いるのが好ましい。また、半券５４は、このチケット情報を紙面上にプリントして用いる場合の便宜のためのものであり、これも本発明を実施する上で必須のものではない。特に、チケット５０をディスプレイ画面上で確認する電子チケットとしてのみ用いる場合には、半券５４は実質的な意味をもたない。
【００５７】
さて、利用者は、図２(c) に示すようなコンサートチケット５０を、電子データの形式（電子チケット）もしくは紙面上にプリントした形式（物理的なチケット）で所持して、コンサート会場（利用施設）へ出向くことになる。コンサート会場の改札場所には、利用施設端末装置２０（コード読出部）が設置されており、ここでチケットの真正性確認と利用者の本人確認とが行われる。
【００５８】
チケットの真正性確認は、コード読出部２０を用いて、利用者が提示したチケット５０から、認証コードを読み出し、これが正しいものであるか否かを、発券管理サーバ３０側に問い合わせることによって行うことができる。すなわち、コード読出部２０は、利用者が提示したチケット５０上に表示されているチケット情報内の認証付顔写真画像５１から、電子透かしとして埋め込まれている認証コードを読み出す機能を有しており、読み出した認証コードを認証コード確認部３６へと送信して、真正性を問い合わせる処理を行う。すなわち、画像入力手段２１〜２３によって認証付顔写真画像５１がデジタルデータとして入力され、確認処理手段２５によって認証コードの読み出しが行われ、通信手段２４によって認証コードの送信が行われる。図示の例の場合、認証付顔写真画像５１から「ＸＹＺ７８９」なる認証コードが読み出されることになり、この「ＸＹＺ７８９」なる認証コードが認証コード確認部３６へと送信される。
【００５９】
認証コード「ＸＹＺ７８９」の送信を受けた認証コード確認部３６は、当該認証コードが、発券履歴記録部３５に記録されている認証コードと一致することを確認し、その結果をコード読出部２０に報知する処理を行う。具体的には、発券履歴記録部３５内の認証コード欄に、「ＸＹＺ７８９」なるコードが存在するか否かを確認し、存在する場合には、当該認証コードは真正なコードである旨の確認結果を報知し、存在しない場合には、当該認証コードは真正なコードではない旨の確認結果を報知することになる。報知された確認結果は、確認処理手段２５によって、何らかの形で提示される。
【００６０】
上述した例のように、チケットの真正性確認は、コード読出部２０から発券管理サーバ３０側に対して、認証コードのみを送信することにより行うことが可能であるが、実用上は、更に、利用対象特定情報を送信するのが好ましい。たとえば、上述の例の場合、「２００４年１２月２４日１８：００より公演の○○○○コンサート」を特定するための利用対象特定情報と、「ＸＹＺ７８９」なる認証コードと、がコード読出部２０から発券管理サーバ３０へと送信されることになる。利用対象特定情報は、予め、利用施設端末装置として機能するコード読出部２０に組み込んでおけばよい。図１に示す実施形態の場合、前述したとおり、発券履歴記録部３５には、認証コードとともに、利用対象特定情報およびチケットＩＤが記録されている。したがって、認証コード確認部３６は、「２００４年１２月２４日１８：００より公演の○○○○コンサート」を示す利用対象特定情報と「ＸＹＺ７８９」なる認識コードとの組み合わせが、発券履歴記録部３５内に存在するか否かを確認する処理を行うことができる。
【００６１】
このように、発券履歴記録部３５に、個々の認証コードを、対応する利用対象特定情報とともに記録しておき、コード読出部２０から認証コード確認部３６に対して、認証コードとともに、当該利用施設に係る利用対象特定情報を送信するようにし、認証コード確認部３６において、認証コードと利用対象特定情報との双方についての一致確認を行う確認方法を採れば、偽造チケットから読み出した認証コードが、発券履歴記録部３５内に記録されている真正な認証コードと偶然一致してしまうような事態が生じる可能性を低減することができる。また、利用対象特定情報と認証コードとの組み合わせによる一致確認を行うようにすれば、個々の認証コードをすべてユニークなものにする必要はなくなるので、たとえば、別個のコンサートであれば、同一の認証コードを重複して用いるような運用も可能になる。もちろん、更に、チケットＩＤを組み入れた一致確認を行うことも可能である。
【００６２】
コード読出部２０は、利用者が提示するチケット５０の形態に応じて、様々な機器を利用して構成することができる。たとえば、利用者が、携帯電話１１やパソコン１２を利用者端末装置１０としてコンサート会場まで携帯し、ディスプレイ画面上に表示させる方法によってチケット５０の提示を行うのであれば、画像入力手段を、デジタルカメラ２１（実用上は、Ｗｅｂカメラと呼ばれているコンピュータ接続に適したカメラを用いるのが好ましい）によって構成しておけばよい。コンサート会場の改札場所において、ディスプレイ画面上に表示された図２(c) に示すようなチケット５０を、デジタルカメラ２１によって撮影し、デジタルデータとして読み込んだ認証付顔写真画像５１から認証コードを読み出す処理を確認処理手段２５によって実行すればよい。
【００６３】
また、利用者が、紙面上にプリントアウトした物理的なチケット５０をコンサート会場まで携帯し、これを提示するのであれば、画像入力手段を、スキャナ装置２２によって構成しておけばよい。コンサート会場の改札場所において、紙媒体上に印刷された図２(c) に示すようなチケット５０上の画像をスキャナ装置２２によってデジタルデータとして読み込み、認証付顔写真画像５１から認証コードを読み出す処理を確認処理手段２５によって実行すればよい。もちろん、スキャナ装置２２の代わりに、デジカメ２１を用いることもできる。
【００６４】
あるいは、利用者が、有線もしくは無線による近距離通信機能をもった携帯電話１１やパソコン１２を利用者端末装置１０としてコンサート会場まで携帯し、有線もしくは無線通信によって、チケット５０上の情報を送信して提示するのであれば、画像入力手段を近距離通信装置２３によって構成しておけばよい。近距離通信としては、赤外線通信、無線ＬＡＮ通信、Bluetooth通信などを利用可能である。利用者が、コンサート会場の改札場所において、携帯電話１１やパソコン１２から、必要なチケット情報を送信する操作を行えば、これを近距離通信装置２３を介してデジタルデータとして読み込み、認証付顔写真画像５１から認証コードを読み出す処理を確認処理手段２５によって実行すればよい。なお、このような近距離通信機能を利用してチケット情報を送信する場合であっても、後述するように、本人確認を行う上で、ディスプレイ画面上に認証付顔写真画像５１を表示させる必要はある。
【００６５】
利用者が提示したチケット５０から認証付顔写真画像５１をデジタルデータとして取り込み、そこから所定のアルゴリズムに基づいて認証コードを読み出し、これを発券管理サーバ３０に送信して真正性の確認結果の報知を受けるまでの処理は、すべて電子的な作業によって行われるので、実際には極めて短時間で実行されることになる。したがって、利用施設の改札場所に設置された利用施設端末装置２０におけるチケットの真正性確認処理は、実際には、ほぼ一瞬のうちに実行される処理であり、確認結果は、確認処理手段２５によって直ちに提示される。
【００６６】
コンサート会場の改札場所の係員は、上述したチケットの真正性確認のための作業を行うとともに、利用者の本人確認のための作業を行う。この本人確認は、係員の目視によって行われる。すなわち、改札場所の係員は、利用者が提示したチケット５０上の認証付顔写真画像５１と、利用者本人の顔とが一致することを目視確認する。もちろん、係員の目視による一致確認であるから、現実的には、誤った一致確認が行われることもあり得るが、少なくとも「入り口で写真照合による本人確認が行われるチケット」という心証を一般利用者に与えることにより、転売を目的としたダフ屋行為を抑制させる効果は十分に得られる。
【００６７】
結局、コンサート会場の改札場所の係員は、利用者から提示されたチケット５０に対して、コード読出部２０を用いた認証コードの確認処理（チケットの真正性確認処理）を行うとともに、認証付顔写真画像５１と本人の顔とを照合することによる本人確認処理を行った上で、当該利用者の入場を許可することになる。もっとも、実用上は、認証コードの確認結果を音で報知するような仕組にしておけば、改札場所の係員は、音に注意しながら、チケット上の顔写真の照合を行う改札作業を行えばよいので、改札作業の負担は、それほど大きいものにはならない。
【００６８】
もっとも、本人確認の処理は、必ずしも改札場所の係員による目視の作業によって行う必要はなく、コンピュータを利用したパターン照合処理によって自動的に行うようにしてもかまわない。たとえば、コンサート会場の改札場所において、来場した利用者本人の顔写真をその場で撮影して、デジタルデータとして取り込み、所定のアルゴリズムに基づいて比較照合処理を実行するするプログラムにより、チケット５０から取り込んだ認証付顔写真画像５１上の人物と同一であることを自動認識するようにしてもかまわない。
【００６９】
なお、利用者は、チケット５０を種々の方法で複製することが可能である。たとえば、デジタルデータの形式の電子チケットであれば、単なるファイルコピー作業により多数の複製を作成することができ、これをプリンタから出力させれば、物理的な形態のチケットも何枚も作成することができる。そこで、実用上は、複製による不正利用（重複利用）を防ぐために、上述のようなチケット５０の利用が行われた時点で、発券管理サーバ３０側において、当該認証コードを無効化する処理を行うようにするのが好ましい。
【００７０】
たとえば、上述の例の場合、認証コード「ＸＹＺ７８９」の送信を受けた認証コード確認部３６は、当該認証コードが、発券履歴記録部３５に記録されている認証コードと一致することを確認し、その結果をコード読出部２０に報知する処理を行うが、このとき、発券履歴記録部３５内に記録されている認証コード「ＸＹＺ７８９」を無効化する処理（たとえば、削除する処理や、無効を示すフラグなどを付加する処理）を実行するようにする。そうすれば、再度、認証コード「ＸＹＺ７８９」についての照会があった場合には、認証コード確認部３６は、不一致との判定を行うことができるので、同一の認証コードを重複して利用することはできなくなる。
【００７１】
本発明に係るチケットでは、顔写真による本人確認が行われることになるので、理論的には、同一のチケットにより複数の者が入場することはできないはずであるが、現実的には、改札場所の係員による目視確認では、完全な本人確認を行うことはできない。したがって、実用上は、上述のように、利用施設において、チケットを利用した入場が１回行われた時点で、当該チケットについての認証コードを無効化する処理を行い、同一チケットを用いた２回目以降の入場を拒絶する運用を行うのが好ましい。
【００７２】
＜＜＜  §４．物理的チケットを発行する実施形態  ＞＞＞
図１に示す実施形態では、チケットは、チケット情報送信部３４からチケット情報というデジタルデータの形式で利用者の下に送信されることになる。利用者は、このデジタルデータの形式のチケットを、電子チケットとしてそのまま利用するか、プリンタなどを用いて物理的チケットの形式で出力した上で利用することになる。
【００７３】
これに対して、図３に示す実施形態は、発券管理サーバ３０側で物理的チケットの発行を行い、これを利用者に届けることができる。図１に示す実施形態との相違点は、チケット情報送信部３４の代わりに、チケット印刷部３７を設けた点だけである。チケット印刷部３７は、発券処理部３３を構成するコンピュータに接続されたプリンタによって構成され、発券処理部３３が生成したチケット情報を紙などの物理的な媒体上に印刷して物理的なチケットを作成する機能を有している。したがって、発券管理サーバ３０から、紙媒体上に印刷された形式のチケット５０を出力することができる。こうして出力したチケット５０は、利用者の下に郵便などの方法を利用して届けられる。なお、発券要求には、チケットの郵送先の住所などの情報を入れておく必要がある。
【００７４】
結局、この図３に示す実施形態では、利用者が、利用者端末装置１０を用いて発券要求を行うと、発行された物理的チケット５０が、後日、郵便などで届けられることになる。この物理的チケット５０を利用施設で利用する方法は、§３で説明したプリントアウトしたチケットを利用する方法と同様である。すなわち、コンサート会場の改札場所において、スキャナ装置２２などを利用して認証付顔写真画像５１の取り込みが行われ、認証コードの確認が実施されるとともに、顔写真による本人確認が行われることになる。
【００７５】
＜＜＜  §５．キャンセルを受け付ける実施形態  ＞＞＞
本発明に係るチケット発行システムは、一度発行したチケットのキャンセルを行う処理にも適している。ここでは、このようなキャンセルを受け付ける機能をもったいくつかの実施形態を述べる。
【００７６】
図４は、キャンセルを受け付ける機能をもった第１の実施形態に係るチケット発行システムの構成を示すブロック図である。図１に示す基本的実施形態との相違は、図４に示すシステムには、キャンセル要求受信部６１およびキャンセル処理部６２が付加されている点、発券要求受信部３１が、利用対象特定情報および顔写真画像に加えて、更にパスワードを伴う発券要求を受信する点、発券履歴記録部３５が、認証コードとともにこれに対応するパスワードを記録する機能を有する点、である。これにより、図４に示すシステムは、一度発行したチケットに対するキャンセル処理を行うことができる。
【００７７】
利用者が、この図４に示すシステムに対して発券要求を行う場合、利用対象特定情報、顔写真画像、パスワードを発券要求受信部３１に対して送信する必要がある。ここでは、説明の便宜上、「２００４年１２月２４日１８：００より公演の○○○○コンサート」を示す利用対象特定情報と、顔写真画像と、「ＡＰＰＬＥ」なるパスワードと、を含む発券要求が送信されたものとしよう。このような発券要求に応じて、発券処理部３３によってチケット情報（利用対象特定情報、認証付顔写真画像、チケットＩＤ）が作成され、チケット情報送信部３４によって利用者端末装置１０へと送信されることは、図１に示す実施形態と全く同様である。また、利用者がこのチケットをコンサート会場で利用する際の手続も、前述の実施形態と全く同様である。
【００７８】
この図４の実施形態では、発券要求に含まれていたパスワードが、認証コードとともに、発券履歴記録部３５に記録されることになる。図示の例では、利用対象特定情報、チケットＩＤ、認証コード、パスワードが、互いに対応するデータとして、発券履歴記録部３５に記録されている。パスワードは、利用者本人のみが知りうるデータであれば、どのようなデータであってもかまわない。このように、パスワードを発券履歴記録部３５内に記録しておくのは、発券済みのチケットに関するキャンセル処理を円滑に行うためである。
【００７９】
さて、ここでは、図２(c) に示すようなチケット５０を入手した利用者が、都合により、当該コンサートに行けなくなったものとしよう。本発明に係るチケット発行システムで発行されたチケットは、チケットに顔写真が掲載された利用者本人しか利用することができないので、従来のチケットのように、他人に譲渡することはできない。したがって、本人が利用できなくなったチケットは、キャンセルせざるを得ない。このように、キャンセルせざるを得ない状況になった場合、利用者は、利用者端末装置１０から発券管理サーバ３０に対してキャンセル要求を行えばよい。
【００８０】
キャンセル要求は、キャンセル要求受信部６１によって受信され、キャンセル処理部６２へ伝えられる。キャンセル要求受信部６１を、Ｗｅｂサーバで構成しておけば、利用者は、利用者端末装置１０のＷｅｂブラウザ機能を利用して、キャンセル要求受信部６１へアクセスすることが可能である。もちろん、利用者端末装置１０内に専用プログラムを組み込んでおけば、この専用プログラムの機能を利用して、キャンセル要求受信部６１へアクセスすることもできる。
【００８１】
このキャンセル要求には、少なくとも認証付顔写真画像とパスワードとが含まれるようにする。認証付顔写真画像は、既に発行済みのチケット情報に含まれているので、利用者は、これをそのまま返信すればよい。一方、パスワードは、利用者が発券要求を行ったときに入力したデータであるから、利用者自身であれば知っているはずの情報である。万一、利用者がパスワードを忘れてしまった場合、この実施形態に係るシステムでは、キャンセルを行うことができなくなる。したがって、チケットを発券する際には、入力したパスワードを忘れないように、利用者に対して十分に注意を喚起しておく必要がある。なお、実用上は、利用者端末装置１０に、専用プログラムを組み込んでおき、発券要求およびキャンセル要求を行う際には、この専用プログラムを起動することにより、必要なデータが自動的に発券管理サーバ３０側に送信されるようにしておくのが好ましい。また、利用者がパスワードを忘れてしまった場合の対策を用意しておくことも可能である。たとえば、パスワードを忘れてしまった利用者がキャンセル要求を行いたい場合には、何らかの方法で発券管理サーバ３０にチケットＩＤを特定してパスワードの問い合わせをしてもらうようにする。発券管理サーバ３０側では、このような問い合わせに応じて、発券履歴記録部３５を参照して、利用者本人にパスワードを通知すればよい。この場合、チケットの発券時にチケット情報を送信した利用者本人のメールアドレスを記録しておくようにし、当該メールアドレス宛にパスワードを送信するようにすれば、本人になりすました第三者からパスワードの問い合わせがあったとしても、この第三者宛にパスワードが通知されることはない。
【００８２】
キャンセル処理部６２は、既に発券済みのチケットに関して、認証付顔写真画像とパスワードとを伴うキャンセル要求が送信されてきたら、このキャンセル要求に含まれていた認証付顔写真画像から、電子透かしとして埋め込まれている認証コードを読み出し、読み出された認証コードおよびキャンセル要求に含まれていたパスワードが、発券履歴記録部３５に記録されている認証コードおよびパスワードと一致するか否かを確認する。そして、両者が一致した場合に、発券履歴記録部３５の当該記録を無効化してキャンセル処理を行う。キャンセル処理部６２は、当然、チケットＤＢサーバ４０に対しても必要なキャンセル処理、すなわち、キャンセルされたチケットに対応する空席が１つ生じた旨の記録を行うための処理を実行する。
【００８３】
たとえば、図２(c) に示すようなチケット５０を入手した利用者が、これをキャンセルする場合、認証付顔写真画像５１と「ＡＰＰＬＥ」なるパスワードとをキャンセル要求受信部６１に対して送信する処理を行うことになる。キャンセル処理部６２は、この認証付顔写真画像５１から、埋め込まれていた認証コード「ＸＹＺ７８９」を読み出し、認証コード「ＸＹＺ７８９」およびパスワード「ＡＰＰＬＥ」なる組み合わせが、発券履歴記録部３５内に記録されているか否かを確認する処理を行う。図４に示す例では、そのような組み合わせの存在が確認できるので、キャンセルを行うための条件を満たしている、との判断がなされ、チケットＤＢサーバ４０に対してキャンセルにより空席が生じた旨の報告を行うとともに、発券履歴記録部３５内の認証コード「ＸＹＺ７８９」を無効化する処理を行う。これにより、キャンセルされたチケット５０を利用してコンサートに入場することはできなくなる。
【００８４】
キャンセル要求を行うためにパスワードの入力を必須要件としているのは、不正な方法でチケット５０を入手した第三者が、利用者になりすましてキャンセル要求を行うことを封じるためである。パスワードは、本来、正規の利用者のみが知りうるデータであるから、キャンセル処理部６２は、認証コードとパスワードとの双方が一致した場合に、当該キャンセル要求を正規の利用者からの正規の要求であるものと判断することになる。
【００８５】
なお、図４に示す例では、キャンセル要求に、認証付顔写真画像とパスワードの他に、チケットＩＤを入れるようにしているが、これはキャンセル処理部６２が発券履歴記録部３５内の記録データを検索する際の便宜を図るためである。図２(c) に示す例では、チケット５０に、チケットＩＤ５３が含まれているので、キャンセル要求に、このチケットＩＤ５３を含ませることは容易にできる。一方、キャンセル処理部６２は、このチケットＩＤ５３を利用して、発券履歴記録部３５を検索することが可能になる。たとえば、図４に示す例では、「ＣＫ００１」なるチケットＩＤを用いた検索により、認証コード「ＸＹＺ７８９」およびパスワード「ＡＰＰＬＥ」なる組み合わせを容易に見付けることができる。
【００８６】
もちろん、すべてのチケットに対してユニークな認証コードを発生させるようにすれば、このようなチケットＩＤを用いることなしに、所望の認証コードを検索することが可能である。しかしながら、個々の利用対象ごとにユニークな認証コードを発生させるようにした場合、利用対象が異なれば、同一の認証コードが用いられる可能性があるので、そのような場合には、キャンセル要求にチケットＩＤを含ませ、これを用いて検索を行うことができるようにするとよい。
【００８７】
なお、すべてのチケットに対してユニークなチケットＩＤを発生させるようにしておけば、チケットＩＤとパスワードとを伴うキャンセル要求に基づいて、キャンセル処理を行うことも可能である。この場合、キャンセル処理部６２は、発券履歴記録部３５を参照した結果、チケットＩＤとパスワードとの組み合わせが一致すれば、これを正当なキャンセル要求と判断することができるので、認証コードの一致確認は省略することができる。したがって、キャンセル要求には、認証付顔写真画像を含ませておく必要はない。
【００８８】
具体的には、図４に示す例の場合、利用者は、「ＣＫ００１」なるチケットＩＤと「ＡＰＰＬＥ」なるパスワードとをキャンセル要求として送信すればよい。キャンセル処理部６２は、発券履歴記録部３５内を検索して、「ＣＫ００１」および「ＡＰＰＬＥ」の組み合わせの存在を確認することにより、これを正当なキャンセル要求と判断し、「ＣＫ００１」に対応して記録されている認証コード「ＸＹＺ７８９」を無効化することになる。
【００８９】
図５は、キャンセルを受け付ける機能をもった第２の実施形態に係るチケット発行システムの構成を示すブロック図である。図４に示す第１の実施形態との相違は、図５に示すシステムでは、発券要求受信部３１が、利用対象特定情報、顔写真画像、パスワードに加えて、更に個人情報を伴う発券要求を受信する点、発券履歴記録部３５が、チケットＩＤの代わりに個人情報を記録する機能を有する点、キャンセル処理部６２が、個人情報の一致判定を行う点、である。
【００９０】
ここで、個人情報とは、利用者本人の個人的な事項に関する情報であり、たとえば、氏名、住所、電話番号、生年月日、電子メールアドレスなどの情報ということになる。利用者が、この図５に示すシステムに対して発券要求を行う場合、利用対象特定情報、顔写真画像、個人情報、パスワードを発券要求受信部３１に対して送信する必要がある。ここでは、説明の便宜上、「２００４年１２月２４日１８：００より公演の○○○○コンサート」を示す利用対象特定情報と、顔写真画像と、「特許太郎  １２３−××××」なる個人情報（氏名と電話番号）と、「ＡＰＰＬＥ」なるパスワードと、を含む発券要求が送信されたものとしよう。このような発券要求に応じて、発券処理部３３によってチケット情報（利用対象特定情報、認証付顔写真画像、個人情報）が作成され、チケット情報送信部３４によって利用者端末装置１０へと送信される。利用者がこのチケットをコンサート会場で利用する際の手続は、前述の実施形態と全く同様である。
【００９１】
この図５の実施形態では、発券要求に含まれていた個人情報およびパスワードが、認証コードとともに、発券履歴記録部３５に記録されることになる。図示の例では、利用対象特定情報、個人情報、認証コード、パスワードが、互いに対応するデータとして、発券履歴記録部３５に記録されている。
【００９２】
さて、この実施形態に係るシステムでは、チケットのキャンセルを行う場合、キャンセル要求には、少なくとも利用対象特定情報、個人情報、パスワードを含ませておくようにする。利用対象特定情報および個人情報は、既に発行済みのチケット情報に含まれているので、利用者は、これをそのまま返信すればよい。一方、パスワードは、利用者が発券要求を行ったときに入力したデータであるから、利用者自身であれば知っているはずの情報である。もちろん、前述したように、パスワードを忘れてしまった場合の問い合わせ機能を用意しておいてもよい。
【００９３】
キャンセル処理部６２は、既に発券済みのチケットに関して、利用対象特定情報、個人情報、パスワードを伴うキャンセル要求が送信されてきたら、これらの情報が、発券履歴記録部３５に記録されている情報と一致するか否かを確認する。そして、両者が一致した場合に、発券履歴記録部３５の当該記録を無効化してキャンセル処理を行う。キャンセル処理部６２は、当然、チケットＤＢサーバ４０に対しても必要なキャンセル処理、すなわち、キャンセルされたチケットに対応する空席が１つ生じた旨の記録を行うための処理を実行する。
【００９４】
たとえば、図５に示す例の場合、キャンセル要求として、「２００４年１２月２４日１８：００より公演の○○○○コンサート」を示す利用対象特定情報と、「特許太郎  １２３−××××」なる個人情報と、「ＡＰＰＬＥ」なるパスワードと、を含むキャンセル要求を送信すればよい。キャンセル処理部６２は、発券履歴記録部３５を検索して、「２００４年１２月２４日１８：００より公演の○○○○コンサート」を示す利用対象特定情報と「特許太郎  １２３−××××」なる個人情報との組み合わせを見つけ出し、この組み合わせに対応して記録されているパスワードが、キャンセル要求に含まれていたパスワード「ＡＰＰＬＥ」に一致することを確認することにより、キャンセルを行うための条件を満たしている、との判断を行う。そして、チケットＤＢサーバ４０に対してキャンセルにより空席が生じた旨の報告を行うとともに、発券履歴記録部３５内の対応する認証コード「ＸＹＺ７８９」を無効化する処理を行う。これにより、キャンセルされたチケット５０を利用してコンサートに入場することはできなくなる。
【００９５】
＜＜＜  §６．キャンセル待ちを受け付ける実施形態  ＞＞＞
上述した§５では、既に発行を受けたチケットをキャンセルしたいと欲する利用者の便宜を図る実施形態を述べたが、ここでは、チケットの発券要求を行った時点で売り切れの状態となっていたため、キャンセル待ちをしたいと欲する利用者の便宜を図る実施形態を述べる。
【００９６】
図６は、このようなキャンセル待ちを受け付ける第１の実施形態に係るチケット発行システムの構成を示すブロック図である。この実施形態は、図４または図５に示す実施形態に、キャンセル待ち記録部６３を更に付加したものである。ここで、キャンセル待ち記録部６３は、利用者端末装置１０からの発券要求に応じて、チケット供給確認部３２がチケットＤＢサーバ４０に対して確認を行ったところ、発券要求に対するチケット供給が不可能であることが確認された場合に、当該発券要求をキャンセル待ちの列に記録する処理を実行する。そして、発券処理部３３は、キャンセル処理部６２によるキャンセル処理より、チケット供給が可能になった時点で、このキャンセル待ち記録部６３内のキャンセル待ちの列に記録されていた発券要求に応じた発券処理を実行する機能を有する。
【００９７】
たとえば、利用者甲が、あるコンサートＸのチケットについての発券要求を行ったところ、既に、このコンサートＸのチケットが完売状態であったものとしよう。この場合、利用者甲が、利用者端末装置１０から発券要求を行っても、チケット供給確認部３２がチケットＤＢサーバ４０へコンサートＸの空席を確認した段階で、当該チケットの供給が不可能であることが確認される。このような場合、甲の発券要求の情報（利用対象特定情報、顔写真画像、チケットの送信先アドレスなど）は、そっくりそのままキャンセル待ち記録部６３にキャンセル待ちの列として記録される。
【００９８】
もちろん、場合によっては、既にキャンセル待ちの列に先客として記録されている発券要求が存在することもありうる。こうして、キャンセル待ちの列に記録されたら、とりあえず甲に対しては、所望のチケットが完売状態なので、キャンセル待ちの手続に入った旨の報告がなされる。もちろん、甲に、キャンセル待ちを希望するか否かを尋ね、甲が希望した場合にのみ、キャンセル待ち記録部６３への記録を行うようにしてもよい。
【００９９】
さて、後日、既にコンサートＸのチケットの発行を受けていた別な利用者乙が、都合により、当該チケットのキャンセル要求を行ったとしよう。このキャンセル要求は、キャンセル要求受信部６１で受信され、キャンセル処理部６２において、所定のキャンセル処理が行われることは、既に§５で述べたとおりである。こうして、キャンセル処理部６２において、コンサートＸのチケットについてのキャンセルが行われると、その事実が、発券処理部３３へと報告される。そこで、発券処理部３３は、キャンセル待ち記録部６３に記録されているコンサートＸに関するキャンセル待ちの列の中で、最も先頭に並んでいる発券要求を取り出して、当該発券要求に基づく発券処理を実行する。その結果、利用者甲の下に、コンサートＸのチケット情報が送信されることになる。
【０１００】
上述の例の場合、利用者甲宛に送信されるチケット情報は、発券処理部３３によって新たに生成されたものであり、利用者甲の顔写真画像に新たな認証コード（利用者乙に対して発行した認証コードとは別なコード）が埋め込まれたものになる。前述したとおり、キャンセル処理部６２は、発券履歴記録部３５に記録されている乙に対して発行した認証コードを無効化する処理を行うので、利用者乙の手元にあるチケットは無効となる。
【０１０１】
なお、このようなキャンセル待ちの処理は、結局、乙のチケットを甲に手渡したのと同等の効果をもつ処理であるので、チケットＤＢサーバ４０に対する更新処理を行う必要はない。もちろん、キャンセル処理部６２からチケットＤＢサーバ４０に対して、１枚のチケットがキャンセルされた旨の記録を行った後、発券処理部３３からチケットＤＢサーバ４０に対して、１枚のチケットが発行された旨の記録を行ってもかまわないが、実用上、このような更新処理は意味のない処理となる。したがって、上述した例のように、キャンセルされたチケットが、キャンセル待ちの利用者に渡った場合には、チケットＤＢサーバ４０に対する更新処理は行う必要はない。
【０１０２】
ところで、場合によっては、一度発行したチケットに対するキャンセル要求を無条件で受け入れることが好ましくないケースもあり得る。販売済みのチケットの払い戻しに無条件で応じると、興行が経済的に成り立たなくなる危険性が生じるのも事実であり、実際、払い戻しには応じない旨が明記されたチケットも少なくない。図６に示す実施形態では、このような場合、条件付きでキャンセルに応じるような運用が可能になる。
【０１０３】
すなわち、チケットのキャンセルは、キャンセル待ちの利用者がいる場合にのみ応じる、という運用である。このような運用を行えば、実質的に、利用者間でチケットの受け渡しを行ったことと同じになるので、興行主側は経済的損失を被ることはない。このような運用を行う場合、キャンセル処理部６２が、キャンセル待ち記録部６３のキャンセル待ちの列を確認して、キャンセル待ちをしている発券要求が記録されていた場合にのみ、キャンセル処理を実行する構成にしておけばよい。
【０１０４】
たとえば、上述の例の場合、乙がコンサートＸのチケットについてのキャンセル要求を行ったとすると、キャンセル処理部６２は、キャンセル待ち記録部６３内にコンサートＸについての発券要求がキャンセル待ちとして記録されているか否かを確認する処理を行うことになる。もし、キャンセル待ちが全くなければ、キャンセル処理部６２は、乙のキャンセル要求を拒絶することになる。上述の例のように、甲がキャンセル待ちをしていた場合にのみ、乙のキャンセル要求が認められることになる。
【０１０５】
ところで、このような運用を採ると、キャンセルを行いたい乙は、キャンセル待ちが現れた頃を見計らって、何度も同じキャンセル要求を出す作業を行わねばならない。図７のブロック図に示すシステムは、乙のこのような労力を軽減するための実施形態であり、図６に示す実施形態に、更に、キャンセル待ち待機記録部６４を付加したものである。
【０１０６】
キャンセル待ち待機記録部６４は、キャンセル要求を受信した時点で、キャンセル待ち記録部６３内のキャンセル待ちの列に発券要求が記録されていなかった場合に、当該キャンセル要求を「キャンセル待ち」を待機する列に記録する処理を実行する。このキャンセル待ち待機記録部６４内には、いわば、「キャンセル待ち」を待つ列が記録されることになる。キャンセル処理部６２は、キャンセル待ち記録部６３内のキャンセル待ちの列に新たな発券要求が記録された時点で、キャンセル待ち待機記録部６４内の「キャンセル待ち」を待機する列に記録されているキャンセル要求に対するキャンセル処理を実行する。
【０１０７】
たとえば、乙がコンサートＸのチケットについてのキャンセル要求を行ったとすると、キャンセル処理部６２は、キャンセル待ち記録部６３内にコンサートＸについての発券要求がキャンセル待ちとして記録されているか否かを確認する処理を行うことになる。ここで、キャンセル待ちが記録されていた場合には、前述のとおり、キャンセルが実行されることになるが、コンサートＸについてのキャンセル待ちが全くなければ、キャンセル処理部６２は、乙のキャンセル要求をとりあえず拒絶することになる。このような場合、乙のキャンセル要求の情報は、そっくりそのままキャンセル待ち待機記録部６４に「キャンセル待ち」を待機する列として記録される。
【０１０８】
もちろん、場合によっては、既に「キャンセル待ち」を待機する列に先客として記録されているキャンセル要求が存在することもありうる。こうして、「キャンセル待ち」を待機する列に記録されたら、とりあえず乙に対しては、キャンセル待ちを希望する利用者がいないので、「キャンセル待ち」を待機する手続に入った旨の報告がなされる。もちろん、乙に、「キャンセル待ち」の待機を希望するか否かを尋ね、乙が希望した場合にのみ、キャンセル待ち待機記録部６４への記録を行うようにしてもよい。
【０１０９】
さて、後日、コンサートＸのチケットを入手したいと希望する甲によって、発券要求がなされたとしよう。この場合、当該発券要求に応じて、チケット供給確認部３２がチケットＤＢサーバ４０に対して、空席があるか否かを確認する処理を行う。ここで、もし、このコンサートＸにまだ空席がある場合には、チケット供給確認部３２から発券処理部３３に対して、チケットの供給が可能である旨の報告がなされ、発券処理部３３は、通常の手順どおり、甲に対してチケットの発行を行うことになる。別言すれば、キャンセル待ちは生じないことになり、「キャンセル待ち」を待っていた乙のキャンセル要求は受け入れられない。
【０１１０】
しかし、甲の発券要求について、チケットＤＢサーバ４０に問い合わせた結果、もし、空席がないことが確認された場合には、甲の発券要求は、一旦、キャンセル待ち記録部６３へと記録され、形式的にキャンセル待ちの状態になる。そして、その事実が、キャンセル処理部６２へと報告される。そこで、キャンセル処理部６２は、キャンセル待ち待機記録部６４に記録されているコンサートＸに関する「キャンセル待ち」を待機する列の中で、最も先頭に並んでいるキャンセル要求を取り出して、当該キャンセル要求に基づくキャンセル処理を実行する。乙のキャンセル要求が先頭に並んでいた場合には、乙のキャンセル要求が受け入れられることになり、乙のチケットがキャンセルされ、甲に対してチケットの発行が行われることになる。
【０１１１】
このような処理により、キャンセル待ちを希望する者がいる場合に限って、キャンセルに応じるという運用を円滑に行うことが可能になる。このような運用は、興行主側からすれば、経済的な損失を被るリスクを減らすメリットが得られ、利用者側からすれば、条件付きではあるが、不要なチケットの払い戻しを受けられるメリットが得られる。
【０１１２】
＜＜＜  §７．再発行を受け付ける実施形態  ＞＞＞
続いて、ここでは、一度発行を受けたチケットを紛失した場合に、再発行を受けることが可能な実施形態を述べる。通常、チケットを紛失した場合、利用者はもはや当該チケットを利用することはできず、再発行に応じてもらうこともできない。しかしながら、本発明に係るチケット発行システムでは、このような場合でも、比較的容易に再発行処理に応じることが可能になる。
【０１１３】
図８は、再発行を受け付ける機能をもった第１の実施形態に係るチケット発行システムの構成を示すブロック図である。図１に示す基本的実施形態との相違は、図８に示すシステムには、再発行要求受信部７１および再発行処理部７２が付加されている点、発券要求受信部３１が、利用対象特定情報および顔写真画像に加えて、更にパスワードを伴う発券要求を受信する点、発券履歴記録部３５が、認証コードとともにこれに対応するパスワードおよび顔写真画像（もしくは認証付顔写真画像でもよい）を記録する機能を有する点、である。これにより、図８に示すシステムは、チケットが紛失した場合に再発行処理を行うことができる。
【０１１４】
なお、図１に示す基本的実施形態の場合、チケットＩＤの利用は任意であったが、この図８に示すシステムでは、発券処理部３３により、個々のチケットごとにユニークなチケットＩＤを発生し、このチケットＩＤを含むチケット情報を生成する必要があり、発券履歴記録部３５には、このチケットＩＤも記録しておく必要がある。
【０１１５】
利用者が、紙媒体としてのチケット５０を紛失したり、利用者端末装置１０内の電子データとしてのチケット５０を紛失（データの消滅）したりした場合、発券管理サーバ３０に対して再発行要求を行うことができる。この図８に示す実施形態では、再発行要求を行う場合、チケットＩＤとパスワードを再発行要求受信部７１に対して送信する必要がある。再発行要求は、再発行要求受信部７１によって受信され、再発行処理部７２へ伝えられる。再発行要求受信部７１を、Ｗｅｂサーバで構成しておけば、利用者は、利用者端末装置１０のＷｅｂブラウザ機能を利用して、再発行要求受信部７１へアクセスすることが可能である。もちろん、利用者端末装置１０内に専用プログラムを組み込んでおけば、この専用プログラムの機能を利用して、再発行要求受信部７１へアクセスすることもできる。実用上は、利用者端末装置１０に、専用プログラムを組み込んでおき、この専用プログラムを起動することにより、再発行要求に必要なデータが自動的に発券管理サーバ３０側に送信されるようにしておくのが好ましい。
【０１１６】
この再発行要求には、少なくともチケットＩＤとパスワードが含まれている必要がある。チケットＩＤおよびパスワードのいずれか一方でも不明な場合には、この実施形態に係るシステムでは、再発行を受けることができない。したがって、チケットを発券する際には、チケット上に記載されたチケットＩＤと入力したパスワードを忘れないように、どこかにメモしておくなど、利用者に対して十分に注意を喚起しておく必要がある。
【０１１７】
再発行処理部７２は、既に発券済みのチケットに関して、チケットＩＤとパスワードとを伴う再発行要求が送信されてきたら、当該再発行要求に含まれていたパスワードが、当該再発行要求に含まれていたチケットＩＤに対応して発券履歴記録部３５に記録されていたパスワードと一致することを条件として、発券履歴記録部３５の記録に基づいてチケット情報を再発行する処理を実行する。
【０１１８】
たとえば、図２(c) に示すようなチケット５０を紛失してしまった利用者が、このチケットの再発行を受ける場合を考える。この場合、当該利用者が、「ＣＫ００１」なるチケットＩＤをどこかにメモしておいたものとし、「ＡＰＰＬＥ」なるパスワードを記憶していたものとしよう。
【０１１９】
図８に示す例において、「ＣＫ００１」なるチケットＩＤと「ＡＰＰＬＥ」なるパスワードとを含む再発行要求が与えられた場合、再発行処理部７２は、「ＣＫ００１」なるチケットＩＤと「ＡＰＰＬＥ」なるパスワードとの組み合わせが、発券履歴記録部３５内に記録されているか否かを確認する処理を行う。図８に示す例では、そのような組み合わせの存在が確認できるので、再発行を行うための条件を満たしている、との判断がなされ、再発行処理部７２による再発行処理が実行される。すなわち、発券履歴記録部３５内には、「ＣＫ００１」なるチケットＩＤに対応して、利用対象特定情報、認証コード、顔写真画像というデータが記録されているので、再発行処理部７２は、これらのデータを利用して、チケット情報を再発行することができ、これをチケット情報送信部３４に送ることができる。顔写真画像の代わりに、認証付顔写真画像を発券履歴記録部３５に記録しておいても同様である。
【０１２０】
こうして再発行されたチケット情報は、チケット情報送信部３４によって利用者端末装置１０へと送信される。なお、チケット情報を電子メールなどを利用して送信する場合には、再発行要求に送信先のメールアドレスを含ませておくようにすればよい。あるいは、発券要求に含まれていた送信先の情報を発券履歴記録部３５に記録しておくようにすれば、再発行時にも、この記録されていた送信先の情報に基づいて、再発行されたチケット情報を送信することができる。
【０１２１】
図９は、再発行を受け付ける機能をもった第２の実施形態に係るチケット発行システムの構成を示すブロック図である。図８に示す第１の実施形態との相違は、図９に示すシステムでは、発券要求受信部３１が、利用対象特定情報、顔写真画像、パスワードに加えて、更に個人情報を伴う発券要求を受信する点、発券履歴記録部３５が、チケットＩＤの代わりに個人情報を記録する機能を有する点、再発行処理部７２が、個人情報の一致判定を行う点、である。
【０１２２】
ここで、個人情報とは、利用者本人の個人的な事項に関する情報であり、たとえば、氏名、住所、電話番号、生年月日などの情報ということになる。利用者が、この図９に示すシステムに対して発券要求を行う場合、利用対象特定情報、顔写真画像、個人情報、パスワードを発券要求受信部３１に対して送信する必要がある。図９では、説明の便宜上、「２００４年１２月２４日１８：００より公演の○○○○コンサート」を示す利用対象特定情報と、顔写真画像と、「特許太郎  １２３−××××」なる個人情報（氏名と電話番号）と、「ＡＰＰＬＥ」なるパスワードと、を含む発券要求が送信された場合の例が示されている。このような発券要求に応じて、発券処理部３３によってチケット情報（利用対象特定情報、認証付顔写真画像、個人情報）が作成され、チケット情報送信部３４によって利用者端末装置１０へと送信される。
【０１２３】
この図９の実施形態では、発券要求に含まれていた利用対象特定情報、個人情報、パスワード、顔写真画像（もしくは認証付顔写真画像）が、認証コードとともに、発券履歴記録部３５に記録されることになる。図示の例では、利用対象特定情報、個人情報、認証コード、パスワード、顔写真画像が、互いに対応するデータとして、発券履歴記録部３５に記録されている。
【０１２４】
さて、この実施形態に係るシステムでは、チケットの再発行を行う場合、再発行要求には、少なくとも利用対象特定情報、個人情報、パスワードを含ませておくようにする。利用対象特定情報は、「２００４年１２月２４日１８：００より公演の○○○○コンサート」という事項を示す情報であるので、チケット５０を紛失したとしても、利用者の記憶には残っている情報である。また、個人情報は、「特許太郎  １２３−××××」といった利用者個人の氏名、住所、電話番号などを示す情報であるから、これも利用者の記憶にある情報である。一方、パスワードは、利用者が発券要求を行ったときに入力したデータであるから、利用者自身であれば知っているはずの情報である。したがって、チケット５０を紛失したとしても、再発行要求に必要な情報は、通常、利用者の頭の中にある情報ということができる。
【０１２５】
再発行処理部７２は、紛失したチケットに関して、利用対象特定情報、個人情報、パスワードを伴う再発行要求が送信されてきたら、これらの情報が、発券履歴記録部３５に記録されている情報と一致するか否かを確認する。そして、両者が一致した場合、別言すれば、再発行要求に含まれていたパスワードが、再発行要求に含まれていた利用対象特定情報および個人情報に対応して発券履歴記録部３５に記録されていたパスワードと一致する場合に、再発行を行うための条件を満たしている、と判断し、再発行処理を実行する。この再発行処理が、発券履歴記録部３５内の対応データを利用して行われる点は、前掲の第１の実施形態と同様である。
【０１２６】
＜＜＜  §８．その他の変形例  ＞＞＞
以上、本発明をいくつかの実施形態に基づいて説明したが、本発明はこれらの実施形態に限定されるものではなく、この他にも種々の形態で実施可能である。以下、いくつかの変形例を述べる。
【０１２７】
(1)   図１０は、更に別な実施形態を示すブロック図である。この実施形態は、図１に示す基本的実施形態の変形例を示すものであり、図１の実施形態との相違点は、コード読出部３８を発券管理サーバ３０側に設け、利用施設端末装置２６を単なる画像読出部として機能させた点である。
【０１２８】
すなわち、図１に示す実施形態では、利用施設端末装置２０をコード読出部として用い、この利用施設端末装置２０内で、認証付顔写真画像から認証コードを読み出す処理を行っていたが、図１０に示す実施形態では、利用施設端末装置２６は、単に認証付顔写真画像をデジタルデータとして読み出す機能しか有していない。この場合、利用施設端末装置２６から発券管理サーバ３０に対して、利用対象特定情報と認証付顔写真画像を送信すればよい。発券管理サーバ３０側では、コード読出部３８がこれらの情報を受け取り、ここで、認証付顔写真画像から認証コードを読み出す処理が実行される。こうして読み出された認証コードが、認証コード確認部３６へと与えられ、真正な認証コードであることが確認され、確認結果が利用施設端末装置２６へと報知される点は、図１に示す実施形態と同様である。
【０１２９】
このように、コード読出部を発券管理サーバ３０側にもってくると、利用施設端末装置２６側の処理負担は軽減されるが、認証コードを送信する代わりに、認証付顔写真画像を送信する必要が出てくるため、通信容量は若干増えることになる。
【０１３０】
(2)   上述の実施形態では、利用者に対する課金処理の説明は省略したが、実用上は、発券処理部３３による発券処理が行われた時点で、利用者に対する課金処理（たとえば、利用者のクレジットアカウントにチケットの購入代金決済を求める処理）を行い、キャンセル処理部６２によるキャンセル処理が行われた時点で、利用者に対する返金処理（たとえば、利用者のクレジットアカウントにチケットの返金代金を計上する処理）を行うことになる。このような課金／返金処理は、既に公知の技術であるため、ここでは詳しい説明は省略する。
【０１３１】
(3)   §５以降に述べた実施形態は、いずれも図１に示す基本的実施形態についての変形例であるが、もちろん、図３に示す実施形態（郵便で物理的チケットを送付する実施形態）についても同様に、§５以降の変形例を適用可能である。
【０１３２】
(4)   上述の実施形態では、利用対象特定情報、チケットＩＤ、個人情報、認証コードをそれぞれ別個のデータとして説明したが、必要に応じて、これらを相互に関連したデータで構成してもかまわない。たとえば、利用対象特定情報に対応する文字列の末尾に、シリアル番号を付加したデータを、チケットＩＤとして用いることも可能であるし、チケットＩＤや個人情報の一部を利用して、認証コードを生成することも可能である。
【図面の簡単な説明】
【０１３３】
【図１】本発明の基本的な実施形態に係るチケット発行システムの構成を示すブロック図である。
【図２】図１に示すチケット発行システムにおけるチケット発行処理の概念を示す図である。
【図３】物理的チケットを送付する実施形態に係るチケット発行システムの構成を示すブロック図である。
【図４】キャンセルを受け付ける第１の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図５】キャンセルを受け付ける第２の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図６】キャンセル待ちを受け付ける第１の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図７】キャンセル待ちを受け付ける第２の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図８】再発行を受け付ける第１の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図９】再発行を受け付ける第２の実施形態に係るチケット発行システムの構成を示すブロック図である。
【図１０】図１に示す基本的実施形態の変形例に係るチケット発行システムの構成を示すブロック図である。
【符号の説明】
【０１３４】
１０…利用者端末装置
１１…携帯電話
１２…パソコン
１３…店舗端末
２０…利用施設端末装置（コード読出部）
２１…デジタルカメラ（画像入力手段）
２２…スキャナ装置（画像入力手段）
２３…近距離通信装置（画像入力手段）
２４…通信手段
２５…確認処理手段
２６…利用施設端末装置（画像読出部）
３０…発券管理サーバ
３１…発券要求受信部
３２…チケット供給確認部
３３…発券処理部
３４…チケット情報送信部
３５…発券履歴記録部
３６…認証コード確認部
３７…チケット印刷部
３８…コード読出部
４０…チケットＤＢサーバ
５０…チケット
５１…認証付顔写真画像
５２…利用対象特定情報
５３…チケットＩＤ
５４…半券
６１…キャンセル要求受信部
６２…キャンセル処理部
６３…キャンセル待ち記録部
６４…キャンセル待ち待機記録部
７１…再発行要求受信部
７２…再発行処理部
【図１】
2006201997.tif 000003
【図２】
2006201997.tif 000004
【図３】
2006201997.tif 000005
【図４】
2006201997.tif 000006
【図５】
2006201997.tif 000007
【図６】
2006201997.tif 000008
【図７】
2006201997.tif 000009
【図８】
2006201997.tif 000010
【図９】
2006201997.tif 000011
【図１０】
2006201997.tif 000012