JP7097710B2 - チケット管理サーバ及びプログラム - Google Patents

Description

本発明は、イベント等の入場に利用されるチケットを監視するチケット管理システムで用いられるチケット管理サーバに関する。

近年、スマートフォン等の携帯端末が普及したことに伴い、入場券を電子データ化した電子チケットを携帯端末に配布し、入場口において入場者の端末に格納されている電子チケットを確認することにより入場可否を判断する電子チケットシステムが提案されている。

例えば、特許文献１には、スマートフォンの画面に同時多点接触が可能なスタンプを用いて、電子チケットと当該電子チケットに対応したスタンプとによって電子チケットを使用済みとする消込処理を行う電子チケットシステムが開示されている。

特開２０１５－５２７５号公報

上記のような電子チケットが実用化されつつあるが、不正防止や利便性の向上といった点で改善の余地がある。例えば、チケットの不正転売（いわゆるダフ屋行為等）を効果的に防ぐことが求められる。また専用のアプリケーションを導入できる多機能端末（例えば、いわゆるスマートフォン）を持たない人にチケットを譲渡する場合には、専用のアプリケーションを導入できない端末での利用方法を提供したり、紙のチケットを発券する必要があるが、これらの方法についても、不正な使用や発券を防ぐことが求められる。

本発明は、上記課題の解決のためになされたものであり、改善されたチケット管理システムを提供することを目的とする。

上記の課題を解決すべく、本発明の一実施形態に係るチケット管理システムは、制御部と、チケットを識別するチケットＩＤと利用者電話番号とを対応付けて記憶するデータベースと、利用者の利用者端末とネットワークを介して通信可能な通信部と、を備える。制御部は、通信部にて受電可能な所定の発券用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの着信があったか否かを判定し、発券用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの架電があったことを含む判定条件を満たした場合に、発券装置にチケットを発券させる。

本発明では、制御部は、利用者端末にてチケットに対する発券開始操作がなされた旨を通信部にて受信したことに応じて、通信部にて受電可能な所定の発券用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの着信があったか否かを判定するとよい。

本発明では、通信部は、ネットワークを介して利用者の利用者端末及び発券装置と通信可能なネットワーク通信部と、電話回線を通じて利用者端末と通信可能な電話通信部とを備え、制御部は、利用者端末にてチケットに対する発券開始操作がなされた旨をネットワーク通信部にて受信したことに応じて、発券開始操作がなされてから所定の有効操作時間内に、電話通信部にて受電可能な所定の発券用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの着信があったか否かを判定し、有効操作時間内に発券用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの架電があったことを含む判定条件を満たした場合に、発券装置にチケットを発券させる命令を送信するとよい。

本発明では、通信部は、ネットワークを介して利用者の利用者端末と通信可能なネットワーク通信部と、電話回線を通じて利用者端末と通信可能な電話通信部とを備え、制御部は、利用者端末にてチケットに対する発券開始操作がなされた旨をネットワーク通信部にて受信したことに応じて、発券開始操作がなされてから所定の有効操作時間内に、電話通信部にて受電可能な所定の発券用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの着信があったか否かを判定し、有効操作時間内に発券用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの架電があったことを含む判定条件を満たした場合に、チケットを発券させるための発券情報を埋め込んだデータ埋込音声を利用者端末のスピーカから出力せしめ、発券装置に利用者端末から出力されたデータ埋込音声に基づきチケットを発券させるとよい。なお、データ埋込音声に埋め込まれる発券情報は、発券するチケットの券面の印刷内容を含むとよい。

本発明では、データ埋込音声を、電話回線を通じた音声通話により利用者端末に送信するとよい。あるいは、データ埋込音声を、ネットワークを通じたライブストリーミングにより利用者端末に送信してもよい。あるいは、データ埋込音声を、当該データ埋込音声を含む音声データファイルとしてネットワークを通じて利用者端末に送信してもよい。

本発明では、発券開始操作に伴い複数の発券装置のいずれから発券するかを示す識別情報を受け取り、判定条件が満たされた場合に、受け取った識別情報に対応する発券装置にチケットを印刷させるとよい。

本発明では、チケット管理サーバは、発券開始操作の前に利用者の利用者端末に、第１サイトにアクセスするよう促し、当該第１サイトに対する利用者端末によるアクセスに応じて、利用者端末に当該第１サイトへのアクセス履歴情報を記録せしめ、発券開始操作を行うために利用者端末に第２サイトにアクセスせしめ、利用者端末が第２サイトにアクセスしたことに応じて利用者端末から第１サイトへのアクセス履歴情報を取得するとよく、制御部が行う判定における判定条件は、第１サイトへのアクセス時に利用者端末に記録せしめたアクセス履歴と、第２サイトへのアクセス時に利用者端末から取得したアクセス履歴とが一致することを含むとよい。

本発明では、チケット管理サーバは、発券開始操作の前に利用者の利用者端末に、第１サイトにアクセスするよう促し、当該第１サイトに対する利用者端末によるアクセスに応じて、利用者端末から当該第１サイトへのアクセスに用いたユーザエージェントを示す第１ユーザエージェント情報を取得し、発券開始操作を行うために利用者端末に第２サイトにアクセスせしめ、利用者端末が第２サイトへのアクセスに用いたユーザエージェントを示す第２ユーザエージェント情報を取得するとよく、制御部が行う判定における判定条件は、第１ユーザエージェント情報と第２ユーザエージェント情報とが一致することを含むとよい。

本発明の他の実施形態に係るチケット管理サーバは、制御部と、チケットを識別するチケットＩＤと利用者電話番号とを対応付けて記憶するデータベースと、ネットワークを介して利用者の利用者端末と通信可能なネットワーク通信部と、電話回線を通じて利用者端末と通信可能な電話通信部と備える。制御部は、利用者端末にてチケットに対する持主登録開始操作がなされた旨をネットワーク通信部にて受信したことに応じて、持主登録開始操作がなされてから所定の有効操作時間内に、電話通信部にて受電可能な所定の登録用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの着信があったか否かを判定し、有効操作時間内に登録用電話番号に当該チケットのチケットＩＤに対応付けられた利用者電話番号からの架電があったことを含む判定条件を満たした場合に、チケットを利用者の持つ利用者端末に使用可能に表示させる。

本発明では、持主登録開始操作がなされたことに応じて、登録用電話番号を利用者の連絡先に送信するとよい。

本発明では、登録用電話番号として複数の候補電話番号を備え、持主登録開始操作がなされたことに応じて、複数の候補電話番号の何れかを登録用電話番号として利用者の連絡先に通知するとよい。

本発明では、チケット管理サーバは、持主登録開始操作の前に利用者の利用者端末に、第１サイトにアクセスするよう促し、当該第１サイトに対する利用者端末によるアクセスに応じて、利用者端末に当該第１サイトへのアクセス履歴情報を記録せしめ、持主登録開始操作を行うために利用者端末に第２サイトにアクセスせしめ、利用者端末が第２サイトにアクセスしたことに応じて利用者端末から第１サイトへのアクセス履歴情報を取得するとよく、制御部が行う判定における判定条件は、第１サイトへのアクセス時に利用者端末に記録せしめたアクセス履歴と、第２サイトへのアクセス時に利用者端末から取得したアクセス履歴とが一致することを含むとよい。

本発明では、チケット管理サーバは、持主登録開始操作の前に利用者の利用者端末に、第１サイトにアクセスするよう促し、当該第１サイトに対する利用者端末によるアクセスに応じて、利用者端末から当該第１サイトへのアクセスに用いたユーザエージェントを示す第１ユーザエージェント情報を取得し、持主登録開始操作を行うために利用者端末に第２サイトにアクセスせしめ、利用者端末が第２サイトへのアクセスに用いたユーザエージェントを示す第２ユーザエージェント情報を取得するとよく、制御部が行う判定における判定条件は、第１ユーザエージェント情報と第２ユーザエージェント情報とが一致することを含むとよい。

上記課題を解決するために、本発明の実施形態に係るプログラムは、コンピューターを、上記何れかのチケット管理サーバとして機能させるとよい。

チケット管理システム１の構成を示す模式図である。 サーバ２の構成を示すブロック図である。 発券装置３の構成を示すブロック図である。 利用者端末４の構成を示すブロック図である。 チケットを受け取るときの手順を示すフローチャートである。 持主登録処理の手順を示すフローチャートである。 チケットを電子的に使用する手順を示すフローチャートである。 紙のチケットの発券処理の手順を示すフローチャートである。 電子的にチケットを受け渡す手順を示すフローチャートである。 第２実施形態における紙のチケットの発券処理の手順を示すフローチャートである。 第３実施形態における紙のチケットの発券処理の手順を示すフローチャートである。

以下、図面を参照して本発明の実施の形態を説明する。

〔チケット管理システムの基本構成〕
図１に示すように、本発明の第１実施形態に係るチケット管理システム１は、サーバ２と、複数の発券装置３と、複数の利用者端末４により構成される。サーバ２と発券装置３及び利用者端末４とは、インターネット等のネットワークＮＷを介して接続される。また、サーバ２及び利用者端末４は、電話回線網ＴＬにも接続される。

〔サーバの構成〕
サーバ２は、例えば、コンピュータシステムであり、キーボード、マウス、タッチパネル等の入出力装置、ＣＰＵ（Central Processing Unit）等の演算部及びＲＡＭ（Random Access Memory）、ＲＯＭ（read only memory）等の記憶装置を備えた本体、ＣＲＴ（Cathode Ray Tube）やＬＣＤ（Liquid Crystal Display）等の表示装置等から構成される。

図２に示すように、サーバ２は、少なくとも、記憶部２０１、制御部２０２、ネットワーク通信部２０３、及び電話通信部２０４を備える。サーバ２の記憶部２０１には、制御部２０２にて実行されるプログラムや、当該プログラムで用いられるデータ等が記憶されている。例えば、記憶部２０１は、チケット管理システム１におけるサーバ２の機能を実現するためのプログラム、チケット管理システム１にて管理する電子チケットに関するデータベースＤＢ、決済処理を行うプログラム等を記憶する。サーバ２は、上記の各構成が物理的に一体として構成されていなくてもよい。例えば、上記構成要素の一部または全部が遠隔地に分散して配置されていてもよく、それらが協働してサーバ２として機能するようにすればよい。

データベースＤＢは、電子チケットに関する情報として、チケットに関する情報（例えば、一意のチケットＩＤ、興行ＩＤ、券種、座席番号、消込キー、購入者の利用者ＩＤ、ステータス（使用済／未使用等）、券面画像等）、利用者に関する情報（例えば、一意の利用者ＩＤ、氏名、年齢、電話番号（利用者電話番号）、住所、性別、その他の属性、連絡先等）、興行に関する情報（例えば、興行ＩＤ、興行名、開催日時、開催場所等）を格納する。なお、本実施形態では、利用者に関する情報として携帯電話番号及び連絡先を必須とする。この連絡先は、利用者端末４にて情報の送受信が可能な連絡先（メールアドレス、ＳＮＳ等）とする。１枚のチケットに対応する１つのチケットＩＤに対し、１つの利用者ＩＤ、及び１つの興行ＩＤが紐づけられ、チケットＩＤを特定すれば、そのチケットを購入した利用者に関する情報やそのチケットで入場できる興行の情報を特定することができる。一人の利用者が同一の興行のチケットを複数枚購入した場合には、同一の興行ＩＤが紐づけられているチケットＩＤが１つのチケットＩＤに対して複数紐づけられることになる。

サーバ２の制御部２０２は、利用者端末４から送信されるリクエスト等に基づき、記憶部２０１に記憶されたプログラムに従った処理を実行する。例えば、制御部２０２は、記憶部２０１に記憶されているデータベースＤＢに対するデータの検索、新規登録、削除、更新といった処理を実行したり、ネットワーク通信部２０３やネットワークＮＷを介して、発券装置３、利用者端末４等との通信を行ったりする。また、制御部２０２は、電話通信部２０４を制御して、着信電話番号を取得したり、必要な音声を電話回線を通して送信したりする。

〔発券装置の構成〕
発券装置３は、サーバ２からの命令に基づいて、所定の用紙にチケットの情報を印刷して発行する。図３に示すように、発券装置３は、少なくとも、記憶部３０１、制御部３０２、通信部３０３、印刷部３０４、表示部３０５、マイク３０６、及びカメラ３０７を備える。

記憶部３０１には、制御部３０２にて実行されるプログラムや、当該プログラムで用いられるデータ等が記憶されている。例えば、記憶部３０１には、サーバ２からの命令に基づきチケットの情報を印刷するよう印刷部３０４を制御するプログラム、サーバ２からの命令に基づき発券機番号や各種の画面を表示するよう表示部３０５を制御するプログラム等が記憶される。複数の発券装置３を備えているチケット管理システム１では、個々の発券装置３を識別するために各発券装置３に発券機番号が割り当てられており、各発券装置３は自己の発券機番号を制御部３０２に記憶する。なお、発券機番号は各発券装置３に個別に割り当てられた発券用電話番号としてもよい。

制御部３０２は、記憶部３０１に記憶されている各種のプログラムを実行する。例えば制御部３０２は、サーバ２からの命令に応じてチケットを印刷すべく印刷部３０４を制御したり、表示部３０５の表示内容を制御したりする。

通信部３０３は、ネットワークＮＷを介して、サーバ２との通信を行う。その他、通信部３０３は、近距無線通信（ＮＦＣ）や、赤外線通信、可視光通信等が可能に構成されてもよい。印刷部３０４は、チケットを所定の用紙に印刷するプリンタである。チケットの用紙は、例えば所定の寸法に予め裁断され、必要に応じてミシン目が設けられた紙片としてもよいし、ロール紙を用いて印刷の都度所定の長に切断するようにしてもよい。

表示部３０５は、発券機番号を液晶ディスプレイ等の表示素子であり、発券装置３を識別するための識別番号である発券機番号や各種の通知や案内画面を表示する。なお、発券機番号は、表示部３０５に代えて／表示部３０５と併せて、発券機番号が印刷されたラベル等に表示してもよい。マイク３０６は音声による入力を受け付ける。

〔利用者端末の構成〕
利用者端末４は、例えば、タブレット型端末やスマートフォンであり、タッチパネル、ＣＰＵ等の演算部及びＲＡＭ、ＲＯＭ等の記憶装置、ＬＣＤ等の表示装置、音声を出力するスピーカ、音声を集音するマイク等を備える。

図４に示すように、利用者端末４は、少なくとも、操作部４０１、記憶部４０２、制御部４０３、通信部４０４、表示部４０５、マイク４０６、及びスピーカ４０７を備える。

操作部４０１は、利用者よる操作を受け付ける。操作部４０１は、表示部４０５に重ねて配置されたタッチパネルと、その他のボタンとを備える。記憶部４０２は、制御部４０３で実行するプログラムや、当該プログラムで用いるデータ等を記憶する。記憶部４０２には、例えば、オペレーションシステム（ＯＳ）、チケット管理システム１のためのアプリケーションプログラムや、このアプリケーションプログラムで用いる購入した電子チケットのデータ、利用者の情報等が記憶されている。

チケット管理システム１を利用するためのアプリケーションプログラムとして、専用のアプリケーションソフトを用いてもよいが、より汎用性の高いブラウザやメッセンジャーアプリケーションであってもよい。ブラウザやメッセンジャーアプリケーション（以下ではブラウザ等という）を用いる場合には、利用者端末４によりブラウザ等を利用してサーバ２にアクセスし、サーバ２のデータベースＤＢから、随時、購入した電子チケットに関するデータ等を取得して表示するように構成するとよい。以下で説明する実施形態では、チケット管理システム１を利用するためのアプリケーションプログラムとしてブラウザ等を用いるものとして説明する。

制御部４０３は、記憶部４０２に記憶されているブラウザ等をはじめとする各種のプログラムを実行する。ブラウザ等では、指定されたＵＲＬにアクセスしてウェブサイト等を表示するほか、後に詳述するように、記憶部４０２に記憶されている各種データや、操作部４０１の操作に基づいた処理が行われる。

通信部４０４は、ネットワークＮＷを介して、サーバ２との通信を行う。また、通信部４０４は、電話回線網ＴＬを用いた音声通話を行う。なお、ネットワークＮＷと電話回線網ＴＬは共通であってもよい。

表示部４０５は、液晶ディスプレイ等の表示素子であり、制御部４０３による制御の下、各種の情報（電子チケットの券面）を表示する。表示部４０５は、操作部４０１のタッチパネルと協働して各種の入力インタフェースを実現する。

〔チケット管理システムの基本的な動作〕
上記のように構成されるチケット管理システム１を利用して、利用者がチケットを購入し、使用する基本的な流れを説明する。

〔チケットの購入と受け取り〕
利用者は、チケット販売者（例えば、チケット販売店舗、チケット販売端末、インターネットで提供されるチケットサイト等）から、所望のイベントのチケットを購入する。このとき、利用者は、イベント、席種、席数、チケットの受け取り方法等の諸条件を選択し、決済の手続きを行う。チケットの受け取り方法として電子チケットを選択した場合に、利用者は、自己の携帯端末を介してチケット管理システムを利用することとなる。以下、図５に示すフローチャートを参照して、受け取り方法として電子チケットを選択した場合のチケット受け取りの流れを説明する。

購入したチケットの代金の決済が完了すると、チケット販売者は、サーバ２に、購入されたチケットのチケットＩＤとチケットを購入した利用者の利用者ＩＤを送信し、サーバ２はこれを受信する（ステップＳ１００）。そして、サーバ２において、販売者から受信したチケットＩＤに紐づけられる購入者の利用者ＩＤとして、販売者から受信した利用者ＩＤを記録する（ステップＳ１１０）。また、サーバ２は、購入されたチケットを利用者端末４にて受け取るための受取ＵＲＬを、購入者の利用者ＩＤに紐づけられている連絡先（メールアドレス、ＳＮＳアカウント等）に送信する（ステップＳ１２０）。なお、発券番号、電話番号等の入力を条件に受け取りができるように構成してもよい。この受取ＵＲＬに対するアクセスはサーバ２により管理される。

利用者が利用者端末４のブラウザ等を用いてステップＳ１２０でサーバ２から送信された受取ＵＲＬにアクセスすることによりチケットを受け取る（ステップＳ１３０）。これにより、利用者端末４にてブラウザ等を利用してチケットを利用できるようになる。このとき、受取ＵＲＬへのアクセスに用いた利用者端末４のブラウザ等に、当該受取ＵＲＬにアクセスしたこと等を示す履歴情報（いわゆるＣｏｏｋｉｅ）として、所定の識別情報が記録される。サーバ２は、購入者の利用者ＩＤとＣｏｏｋｉｅを紐づけて記録する。このまた、サーバ２は受取ＵＲＬにアクセスした利用者端末４の機種、ブラウザ、ＯＳ等を示すユーザエージェントに関する情報（以下、「ＵＡ情報」という）を、購入者の利用者ＩＤに紐づけて記録する。

本実施形態のチケット管理システムでは、持主登録されていないチケットは、使用可能な状態とはならない。そこで、チケットを購入した利用者は、以下で説明する手順で持主登録を行う。

〔持主登録〕
図６は、持主登録処理の手順を示すフローチャートである。利用者が利用者端末４を用いてブラウザ等を起動してチケット管理システムのサイトにアクセスすると、チケットを購入済みの興行が選択可能に表示される（ステップＳ２００）。これらのうち、所望のチケットを選択したときに、チケットの持主登録が完了されていない場合、当該チケット券面とともに、当該チケットについての持主登録を行うための持主登録画面が表示される（ステップＳ２１０）。この持主登録画面へのアクセスはサーバ２により管理される。表示された持主登録画面にアクセスする。このとき、利用者端末４は、アクセスに用いているブラウザ等のＵＡ情報及びチケットを受け取るために受取ＵＲＬにアクセスしたときにブラウザ等に残されたＣｏｏｋｉｅ情報を、サーバ２に送信する（ステップＳ２２０）。また、サーバ２は、持主登録画面へのアクセスに応答して、利用者に登録用電話番号を通知する（ステップＳ２３０）。ここで、利用者に通知する方法としては、利用者の連絡先に登録用電話番号を送信するようにしてもよいし、利用者が利用者端末等を用いて閲覧可能なＷｅｂページに表示するようにしてもよい。この登録用電話番号は固定の電話番号でもよいが、複数の候補電話番号から選択された１つの番号を送信するようにして、表示の都度、異なる番号としてもよい。

続いて、利用者端末４は、持主登録処理を開始するための認証ボタンを、表示部４０５に表示する（ステップＳ２３５）。利用者により認証ボタンが押下されると、サーバ２は、押下時刻をチケットＩＤに紐づけて記録する（ステップＳ２４０）。認証ボタンＢ１は、本発明における持主登録開始操作の一例である。また、利用者端末４は、認証ボタンが押下されたことに応じて、ステップＳ２２０で受け取った登録用電話番号を表示する（ステップＳ２４５）。なお、登録用電話番号をステップＳ２３０にてサーバ２から利用者端末４に送信するのではなく、認証ボタンが押下されたことに応じて登録用電話番号をサーバ２から利用者端末４に送信し、表示部４０５に表示するようにしてもよい。

続いて、サーバ２は、押下時刻から所定の有効操作時間内（例えば４秒以内）に、チケットに紐づけて記録されている利用者電話番号の電話（通常は利用者端末４）から当該登録用電話番号に架電されたか否かを判定する（ステップＳ２５０）。この有効操作時間は、発券用電話番号を遠隔地にいる第三者に伝え、当該遠隔地からの代行操作により電話番号を掛けることが困難な程度に短い時間とするとよい。

ステップＳ２５０において、サーバ２は、押下時刻から所定の有効操作時間内（例えば４秒以内）に、チケットに紐づけて記録されている利用者電話番号の電話（通常は利用者端末４）から当該登録用電話番号に架電されたか否かを、次のようにして判定する。サーバ２は、電話通信部２０４により登録用電話番号にかかってきた電話を受電する。そして、電話通信部２０４は、発信元の電話番号及び架電された電話番号（候補電話番号の何れか）を特定する。サーバ２は、架電された電話番号に基づきチケットＩＤを特定し、当該チケットＩＤが、受電時刻から有効操作時間分だけ遡った期間内に押下時刻が記録されたチケットＩＤであるかを確認することで、有効操作時間内に登録用電話番号に架電されたか否かを判定する。

押下時刻から有効操作時間内に登録用電話番号に架電されなかった場合（ステップＳ２５０；Ｎｏ）には持主登録はされず、持主登録ができなかったことを通知する画面を利用者端末４の表示部４０５に表示させて（ステップＳ２６０）、持主登録処理が終了する。なお、発信元の電話番号が、チケットに紐づけて記録されている利用者電話番号と１文字違いだった場合や、頭の文字が抜けている場合等、誤入力と想定される際にはその旨を案内するように構成するとよい。このようにすれば、利用者電話番号を誤って登録していることに容易に気づかせ、利用者に利用者電話番号の修正を促すことができる。

一方、押下時刻から有効操作時間内に登録用電話番号に架電された場合（ステップＳ２５０；Ｙｅｓ）、サーバ２は、照合処理を行う（ステップＳ２７０）。照合処理では、チケットＩＤに紐づけられている購入者の電話番号をデータベースＤＢから抽出し、ステップＳ２５０で着信した番号と照合する。また、サーバ２は、購入者の利用者ＩＤに紐づけて記録されている受取ＵＲＬにアクセスしたときのＣｏｏｋｉｅ情報及びＵＡ情報を、ステップＳ２２０で利用者端末４から送信されたＣｏｏｋｉｅ情報及びＵＡ情報と照合する。照合処理で各情報の一致が確認されなかった場合（ステップＳ２７０；Ｎｏ）には持主登録はされず、持主登録ができなかったことを通知する画面を利用者端末４に表示させて（ステップＳ２６０）、持主登録処理が終了する。一方、照合処理で情報の一致が確認された場合（ステップＳ２７０；Ｙｅｓ）、サーバ２は、当該チケットについてデータベースＤＢに持主登録が完了したことを記録するとともに、利用者端末４に当該チケットを使用可能な状態で表示可能とする（ステップＳ２８０）。以後、利用者端末４でブラウザ等を起動してチケット管理システムのサイトにアクセスして当該チケットを表示したときには、当該チケットは使用可能な状態で表示される。

以上のような手順の持主登録処理によれば、チケットを購入した者が持主登録をしない限りチケットが使用可能にならないので、不正な譲渡や転売を抑止することができる。
〔電子チケットの使用〕

上述のように、チケット管理システム１で管理される電子チケットは、持主登録をすることにより使用可能となる。以下で説明するように、チケットは、電子的に使用することもできるし、紙のチケットを発券して使用することもできる。

図７は、持主登録が済んだチケットを電子的に（つまり、紙チケットを発券せずに、利用者端末４に表示させて）使用するときのチケット管理システム１の処理手順の一例を示すフローチャートである。利用者は、利用者が予め上述の持主登録を完了した状態で利用者端末４のブラウザ等を起動し、チケットを表示するための券面ＵＲＬにアクセスすることにより、電子チケットの券面を利用者端末４の表示部４０５に表示させ（ステップＳ３００）、入場口の係員に提示する。券面ＵＲＬへのアクセスはサーバ２により管理される。利用者端末４は、券面ＵＲＬにアクセスするときに、アクセスに用いているブラウザ等のＵＡ情報及びチケットを受け取るために受取ＵＲＬにアクセスしたときにブラウザ等に残されたＣｏｏｋｉｅ情報を、サーバ２に送信する。

係員は、当該イベントの電子チケットの券面が当該イベントのものであることを目視で確認しつつ、所定の消込操作（例えば、利用者端末４のタッチパネルに対し所定の操作を行う）ことにより、チケットを使用済みとする「消し込み」を行う（ステップＳ３１０）。利用者端末４は消込操作を受け付けると、使用済みであることを示す文字や画像（以下、「消印情報」という）を券面に重畳して表示するとともに、当該チケットのステータスを「使用済」とする（ステップＳ３２０）。また、利用者端末４は、当該チケットが使用済みとなったことを適切なタイミング（照合した直後でもよいし、暫く時間が経ってからでもよい）でサーバ２に通知し、サーバ２においても、当該チケットのステータスを「使用済」として（ステップＳ３３０）、処理を終了する。なお、利用者端末４は、消込操作を受け付けると、当該消込操作が正しいかを照合し、正しい場合にのみチケットを使用済みとし、正しくない場合には警告・通知等を行うようにするとよい。また、消込操作の照合の他、ステップＳ３００に伴い利用者端末４から送信されるＣｏｏｋｉｅ情報やＵＡ情報を、当該チケットの持主の利用者ＩＤに紐づけて記録されているＣｏｏｋｉｅ情報及びＵＡ情報と照合してもよい。なお、上記の例では利用者端末４に対する消込操作を受け付けることにより消し込みが行われたが、消し込みは他の方法で行ってもよい。例えば、利用者端末４の表示部４０５に、チケットの券面とともに識別コード（例えばＱＲコード（登録商標）等）を表示させ、これを入場口で読み取ってサーバ２に照合する等により、サーバ２側で消し込みの処理を行うようにしてもい。

〔紙のチケットの発券〕
一方、チケット管理システム１では、購入したチケットを紙のチケットとして発券して使用することも可能とされる。紙のチケットの発券は、発券装置３をチケットショップ等に常設しておき、興行の前に予め発券を行えるようにしてもよいし、発券装置３を興行の入場口の近くに設置して、入場の直前に発券を行うようにしてもよい。以下では図８に示すフローチャートを参照して、チケット管理システム１による紙のチケットの発券処理の手順を説明する。

発券処理に先立ち、利用者は、利用者端末４のブラウザ等を起動し、券面ＵＲＬにアクセスする。券面ＵＲＬへのアクセスはサーバ２により管理される。利用者端末４は、券面ＵＲＬにアクセスするときに、アクセスに用いているブラウザ等のＵＡ情報及びチケットを受け取るために受取ＵＲＬにアクセスしたときにブラウザ等に残されたＣｏｏｋｉｅ情報を、サーバ２に送信する。ここまでの処理手順はチケットを電子的に利用する場合と共通である。

券面ＵＲＬにアクセスすると、利用者端末４の表示部４０５には、券面の画像とともに紙発券ボタンが表示される。この紙発券ボタンを押下すると（ステップＳ４００）、発券処理が開始される。発券処理の開始に伴い、当該チケットの使用、譲渡、更なる発券ができない状態とされる。

ステップＳ４００で利用者が紙発券ボタンを押下すると、利用者端末４には発券機番号の入力を促す画面が表示される。これに応じて表示部３０５に表示されている発券機番号を利用者端末４に入力すると、利用者端末４は、サーバ２に発券機番号を送信する（ステップＳ４１０）。紙発券ボタンの押下は、本発明における発券開始操作の一例である。サーバ２は、発券機番号を受け取ると、利用者端末４に発券用電話番号を送信し、利用者端末４はこれを受信する（ステップＳ４２０）。このとき、サーバ２は、発券するチケットのチケットＩＤと発券用電話番号とを紐づけて記録する。発券用電話番号は固定の電話番号でもよいが、複数の候補電話番号から選択された１つの番号を送信するようにして、表示の都度、異なる番号としてもよい。なお、発券機番号として発券用電話番号を各発券装置３に個別に割り当てる構成では、ステップＳ４１０及び、ステップ４２０を省略することができ、表示部３０５に表示される発券用電話番号に電話をかけるだけで発券処理を開始することができる。したがって、専用のアプリケーションを導入できない端末からでも紙のチケットの発券処理をすることができる。

続いて、利用者端末４は、ステップＳ４２０で受信した発券用電話番号及び紙チケット発券のための照合を開始するための照合開始ボタンを、表示部４０５に表示する（ステップＳ４３０）。なお、ステップＳ４２０、Ｓ４３０において送信・表示した発券用電話番号は、利用者端末４の表示部４０５に代えて発券装置３の表示部３０５に表示されるように構成してもよい。利用者により照合開始ボタンが押下されると、サーバ２は、押下時刻をチケットＩＤに紐づけて記録する（ステップＳ４４０）。

続いて、サーバ２は、押下時刻から所定の有効操作時間内（例えば４秒以内）に、チケットに紐づけて記録されている利用者電話番号の電話（通常は利用者端末４）から当該発券用電話番号に架電されたか否かを判定する（ステップＳ４５０）。この有効操作時間は、発券用電話番号を遠隔地に伝え、当該遠隔地からの代行操作により電話番号を掛けることが困難な程度に短い時間とするとよい。

ステップＳ４５０において、サーバ２は、押下時刻から所定の有効操作時間内（例えば４秒以内）に、チケットに紐づけて記録されている利用者電話番号の電話（通常は利用者端末４）から当該発券用電話番号に架電されたか否かを、次のようにして判定する。サーバ２は、電話通信部２０４により発券用電話番号にかかってきた電話を受電する。そして、電話通信部２０４は、発信元の電話番号及び架電された電話番号（候補電話番号の何れか）を特定する。サーバ２は、架電された電話番号に基づきチケットＩＤを特定し、当該チケットＩＤが、受電時刻から有効操作時間分だけ遡った期間内に押下時刻が記録されたチケットＩＤであるかを確認することで、有効操作時間内に発券用電話番号に架電されたか否かを判定する。

押下時刻から有効操作時間内に発券用電話番号に、有効操作時間内に発券用電話番号に架電されなかった場合（ステップＳ４５０；Ｎｏ）にはチケットは発券されず、発券ができない旨を通知する画面を利用者端末４の表示部４０５に表示させるとともに、当該チケットを使用可能な状態に戻して（ステップＳ４６０）、発券処理が終了する。なお、発信元の電話番号が、チケットに紐づけて記録されている利用者電話番号と１文字違いだった、頭の文字が抜けている場合等、誤入力と想定される際場合等にはその旨を案内するように構成するとよい。このようにすれば、利用者電話番号を誤って登録していることに容易に気づかせ、利用者に利用者電話番号の修正を促すことができる。

一方、押下時刻から有効操作時間内に発券用電話番号に架電された場合（ステップＳ４５０；Ｙｅｓ）、サーバ２は、照合処理を行う（ステップＳ４７０）。照合処理では、チケットＩＤに紐づけられている利用者電話番号をデータベースＤＢから抽出し、ステップＳ４５０で着信した番号と照合する。また、サーバ２は、チケットの持主の利用者ＩＤに紐づけて記録されているＣｏｏｋｉｅ情報及びＵＡ情報を、券面ＵＲＬにアクセスした際に利用者端末４から送信されたＣｏｏｋｉｅ情報及びＵＡ情報と照合する。照合処理で情報の一致が確認されなかった場合（ステップＳ４７０；Ｎｏ）にはチケットは発券されず、発券ができない旨を通知する案内画面を利用者端末４の表示部４０５に表示させるとともに、当該チケットを使用可能な状態に戻して（ステップＳ４６０）、発券処理が終了する。

一方、照合処理で情報の一致が確認された場合（ステップＳ４７０；Ｙｅｓ）、サーバ２は、当該チケットについてデータベースＤＢに紙発券を行ったことを記録するとともに、ステップＳ４２０で受け取った発券機番号の発券装置３に、印刷部３０４から当該チケットを印刷するよう命令を送信する（ステップＳ４８０）。当該発券機番号の発券装置３は、この命令を受け、印刷部３０４でチケットを印刷して（ステップＳ４９０）、発券処理を終了する。

以上のようにして、紙のチケットを発券することが可能とされる。本実施形態の発券処理では、発券時に電話番号、Ｃｏｏｋｉｅ情報、ＵＡ情報等を利用した照合を行うことにより、例えば、遠隔地から照合に必要な操作を行う等による、不正なチケットの発券を抑止することができる。発見した紙のチケットは、従来の紙のチケットと同様にイベントの入場口にて使用することができる。

〔半券の発券〕
上述した紙のチケットの発券処理は、未使用の紙チケットを発券する場合の他、電子チケットで入場を行った後で、使用済みのチケットの半券を発券する場合にも適用することができる。イベント会場の入場口にてチケットを消し込み、その後、上記の発券処理と同様の手順で電話番号、Ｃｏｏｋｉｅ、ＵＡ等による照合を経て半券を発行するようにするとよい。この場合、発券装置３は、会場内（例えば入場口を通過した直後）に設けるとよい。このようにすれば、電子チケットで複数人分のチケットをまとめて使用して入場をした場合に、利用者端末４を持たない入場者に、座席番号の案内や再入場等ための証明書として半券を発行することができる。また、利用者端末４のバッテリー残量が不足している場合に備えて紙の半券を発行することもできる。なお、利用者端末４は、電子チケットを消し込んだ時に、同時に利用するチケットの枚数が複数である場合やバッテリー残量が所定の閾値を下回る場合に、メッセージを表示部４０５に表示したり、通知音を発したりすることにより、紙の半券を発行するよう利用者に促すとよい。

〔チケットの譲渡〕
チケット管理システム１は、管理するチケットを持主から他人に譲渡することを可能とする。

チケットの譲渡は、譲渡を受ける者が改めて持主登録を行うことにより電子的にチケットを受け渡す方法と、紙のチケットを発券して受け渡す方法とが可能である。

〔電子的なチケット譲渡〕
図９に示すフローチャートを参照して、電子的にチケットを受け渡す方法の手順を説明する。電子的にチケットを受け渡す方法では、はじめに、譲渡元の利用者が予め上述の持主登録を完了した状態で、券面ＵＲＬにアクセスすることで譲渡するチケットを表示する。そして、その券面とともに表示される受渡先登録ボタンを押す（ステップＳ６００）。この受渡先登録ボタンを押すと、受渡先の電話番号の入力を促す画面が利用者端末４に表示される。当該画面に受渡先の電話番号を入力すると（ステップＳ６１０）、その電話番号がチケットＩＤとともにサーバ２に送信され、チケットＩＤに紐づけてデータベースＤＢに記録される（ステップＳ６２０）。また、譲渡元の利用者のブラウザ等では、当該チケットの使用や更なる譲渡ができない状態とされる（ステップＳ６３０）。

サーバ２は、チケットＩＤ及び譲渡先の電話番号を受信すると、これに応じて譲渡先の利用者が持主登録処理を行ための持主登録画面にアクセスするための持主登録ＵＲＬを発行し、譲渡元の利用者の連絡先（メールアドレス、ＳＮＳ等）に送信する（ステップＳ６４０）。譲渡元の利用者は、この持主登録ＵＲＬを譲渡先の利用者に転送する（ステップＳ６５０）。なお、持主登録ＵＲＬを、譲渡元の利用者を経由せずに、サーバ２から譲渡先の利用者に直接送るようにしてもよい。

譲渡先の利用者は、自己の利用者端末４を用いてステップＳ６５０で送信されたＵＲＬを受信し（ステップＳ６６０）する。そして、譲渡先の利用者は、購入時の持主登録処理（図６）におけるステップＳ２００～Ｓ２８０と同様の方法で持主登録を行う。サーバ２は、所定の期間内に譲渡先の利用者による持主登録が正常に完了したか否かを判定する（ステップＳ６７０）。そして正常に完了したと判定すると（ステップＳ６７０；Ｙｅｓ）、サーバ２のデータベースＤＢにおいて譲渡先の利用者が当該チケットの持主として記録され、譲渡元の利用者は持主ではなくなる。そして、譲渡先の利用者の利用者端末４に当該チケットが使用可能な状態で表示可能となる（ステップＳ６８０）。一方、例えば、所定の譲渡有効期間内に持主登録が完了しない場合など、譲渡先の利用者による持主登録が正常に完了しない場合には（ステップＳ６７０；Ｎｏ）、サーバ２は、譲渡先の電話番号の記録をデータベースＤＢから削除するとともに、譲渡元の利用者の利用者端末４で当該チケットを使用可能な状態で表示可能とする（ステップＳ６９０）。

以上のようにして、チケットを電子的に譲渡することが可能とされる。このように、チケットの電子的に譲渡する場合にも購入時と同様の持主登録を必要とすることにより、チケット管理システム１は譲渡元と譲渡先を把握することが可能となり、不正な譲渡や転売を抑止することができる。

〔紙のチケットの譲渡〕
一方、紙のチケットを発券して受け渡す方法は、持主である利用者が発券装置３によりチケットを発券し、発券したチケットを譲渡先に渡す方法である。紙のチケットの発券は、上述の紙のチケットを使用する場合の発券と同様に実現するとよい。なお、紙のチケットを譲渡する場合でも、紙のチケットを発券する前に持主登録を必要とするように構成すれば、不正な譲渡や転売を抑止することができる。この場合、発券する紙のチケットの券面に持主登録されている利用者の氏名等を印刷するように構成すると、不正な譲渡や転売を抑止する効果が特に期待できる。

〔第２実施形態〕
本発明の第２実施形態に係るチケット管理システムは、紙のチケットの発券方法が第１実施形態とは異なっている。すなわち、第２実施形態では、照合（図８のステップＳ４５０）を行うまでは第１実施形態と同様であるが、照合に成功した後、発券装置３から紙のチケットを発券させるための手順及び当該手順に関連したハードウェア構成において異なっている。

図１０は、第２実施形態における、発券装置３による発券処理の手順を示すフローチャートである。発券処理に先立ち、利用者が利用者端末４のブラウザ等を起動し、券面ＵＲＬにアクセスする。券面ＵＲＬへのアクセスはサーバ２により管理される。利用者端末４は、券面ＵＲＬにアクセスするときに、アクセスに用いているブラウザ等のＵＡ情報及びチケットを受け取るために受取ＵＲＬにアクセスしたときにブラウザ等に残されたＣｏｏｋｉｅ情報を、サーバ２に送信する。

券面ＵＲＬにアクセスすると、利用者端末４の表示部４０５には、券面の画像とともに紙発券ボタンが表示される。この紙発券ボタンを押下すると（ステップＳ７００）、発券処理が開始される。発券処理の開始に伴い、当該チケットの使用、譲渡、更なる発券ができない状態とされる。

ステップＳ７００で利用者が紙発券ボタンを押下すると、利用者端末４には発券機番号の入力を促す画面が表示される。これに応じて表示部３０５に表示されている発券機番号を利用者端末４に入力すると、利用者端末４は、サーバ２に発券機番号を送信する（ステップＳ７１０）。紙発券ボタンの押下は、本発明における発券開始操作の一例である。サーバ２は、発券機番号を受け取ると、利用者端末４に発券用電話番号を送信する（ステップＳ７２０）。この発券用電話番号は固定の電話番号でもよいが、複数の候補電話番号から選択された１つの番号を送信するようにして、表示の都度、異なる番号としてもよい。

続いて、利用者端末４は、ステップＳ７２０で受け取った発券用電話番号及び紙チケット発券のための照合を開始するための照合開始ボタンを、表示部４０５に表示する（ステップＳ７３０）。利用者により照合開始ボタンが押下されると、サーバ２は、押下時刻を記録する（ステップＳ７４０）。

続けて、サーバ２は、押下時刻から所定の有効操作時間内（例えば４秒以内）に、チケットに紐づけて記録されている利用者電話番号の電話（通常は利用者端末４）から当該発券用電話番号に架電されたか否かを判定する（ステップＳ７５０）。この有効操作時間は、発券用電話番号を遠隔地に伝え、当該遠隔地からの代行操作により電話番号を掛けることが困難な程度に短い時間とするとよい。

ステップＳ７５０において、サーバ２は、押下時刻から所定の有効操作時間内（例えば４秒以内）に、チケットに紐づけて記録されている利用者電話番号の電話（通常は利用者端末４）から当該発券用電話番号に架電されたか否かを、次のようにして判定する。サーバ２は、電話通信部２０４により発券用電話番号にかかってきた電話を受電する。そして、電話通信部２０４は、発信元の電話番号及び架電された電話番号（候補電話番号の何れか）を特定する。サーバ２は、架電された電話番号に基づきチケットＩＤを特定し、当該チケットＩＤが、受電時刻から有効操作時間分だけ遡った期間内に押下時刻が記録されたチケットＩＤであるかを確認することで、有効操作時間内に発券用電話番号に架電されたか否かを判定する。

押下時刻から有効操作時間内に発券用電話番号に、有効操作時間内に発券用電話番号に架電されなかった場合（ステップＳ７５０；Ｎｏ）にはチケットは発券されず、発券ができない旨を通知する画面を利用者端末４の表示部４０５に表示させるとともに、当該チケットを使用可能な状態に戻して（ステップＳ７６０）、発券処理が終了する。なお、発信元の電話番号が、チケットに紐づけて記録されている利用者電話番号と１文字違いだった、頭の文字が抜けている場合等、誤入力と想定される際にはその旨を案内するように構成するとよい。このようにすれば、利用者電話番号を誤って登録していることに容易に気づかせ、利用者に利用者電話番号の修正を促すことができる。

一方、有効操作時間内に発券用電話番号に架電された場合（ステップＳ７５０；Ｙｅｓ）、サーバ２は、照合処理を行う（ステップＳ７７０）。照合処理では、チケットＩＤに紐づけられている利用者電話番号をデータベースＤＢから抽出し、ステップＳ７５０で着信した番号と照合する。また、サーバ２は、チケットの持主の利用者ＩＤに紐づけて記録されているＣｏｏｋｉｅ情報及びＵＡ情報を、券面ＵＲＬにアクセスした際に利用者端末４から送信されたＣｏｏｋｉｅ情報及びＵＡ情報と照合する。照合処理で情報の一致が確認されなかった場合（ステップＳ７７０；Ｎｏ）にはチケットは発券されず、発券ができない旨を通知する案内画面を利用者端末４の表示部４０５に表示させるとともに、当該チケットを使用可能な状態に戻して（ステップＳ７６０）、発券処理が終了する。

一方、照合処理で情報の一致が確認された場合（ステップＳ７７０；Ｙｅｓ）、サーバ２は、電話通信部２０４にて、ステップＳ７５０にて受電した電話の音声通話を開始する（ステップＳ７８０）。そして、電話通信部２０４は、当該音声通話にて、発券装置３にチケットを印刷させるための情報（以下、「発券情報」という）を埋め込んだデータ埋込音声を利用者端末４に送信する（ステップＳ７９０）。なお、当該音声通話は所定の通話時間が経過後に切断されるようにするとよい。ここで、発券情報は、チケット券面のデータを全て含んでもよいし、必要に応じて暗号化されたチケットＩＤのみとしてもよい。発券情報をチケットＩＤのみとする場合には、発券装置３は、チケットＩＤとチケット券面のデータとを対応付けたデータを、予めサーバ２から受け取って記憶部３０１に格納しておくとよい。あるいは、発券情報を受け取る都度、チケットＩＤに対応するチケット券面のデータをサーバ２に照会してネットワークＮＷを介して受け取るようにしてもよい。また、発券情報は、ステップＳ７１０で入力された発券機番号を含むとよい。また、発券情報は、ステップＳ７４０で記録された押下時刻、発券用電話番号に架電された時刻等の発券処理の時刻を示すタイムスタンプ情報を含むとよい。

利用者は、利用者端末４のスピーカ４０７を発券装置３のマイク３０６にかざして、データ埋込音声をマイク３０６に入力する（ステップＳ８００）。発券装置３は、マイク３０６に入力された音声を復号して、発券情報を取得する（ステップＳ８１０）。そして、発券装置３は、受け取った発券情報が正当なものか否かを判定する（ステップＳ８２０）。

受け取った発券情報が正当なものか否かは、例えば以下のように判定するとよい。発券情報が発券機番号を含む場合には、データ埋込音声が入力された発券装置３の発券機番号と発券情報に含まれる発券機番号とが一致することを正当と判断する条件に含めるとよい。また、発券情報がタイムスタンプ情報を含む場合には、現在時刻が当該タイムスタンプ情報で示される時刻から所定の発券有効期間内に含まれていることを正当と判断する条件に含めるとよい。発券有効期間内は、データ埋込音声を録音してネットワークＮＷ等を介して遠隔地に送付することが困難な程度の時間（例えば３分）とするとよい。また、照合処理で情報の一致が確認されてから所定の時間内に音声が入力されたことを条件に含めてもよい。その他、ステップＳ７８０での照合が行われたことを示す情報が発券情報に含まれること等を正当と判断する条件に含めるとよい。

受け取った発券情報が正当なものである場合（ステップＳ８２０；Ｙｅｓ）、発券装置３は、印刷部３０４でチケットを印刷し、ステップＳ８２０での判断の結果等、当該チケットを発券したことを示す情報をサーバ２に送信する（ステップＳ８３０）。これを受けてサーバ２は、当該チケットについてデータベースＤＢに紙発券を行ったことを記録し（ステップＳ８４０）、発券処理を終了する。

一方、受け取った発券情報が正当なものでない場合（ステップＳ８２０；Ｎｏ）、発券装置３は、表示部３０５に発券できない旨を表示し、ステップＳ８４０での判断の結果等、当該チケットを発券しなかったことを示す情報をサーバ２に送信する（ステップＳ８５０）。これを受けてサーバ２は、当該チケットを使用可能な状態に戻して（ステップＳ８６０）、発券処理を終了する。

以上のようにして、紙のチケットを発券する際に、データ埋込音声を介して利用者端末４から発券装置３に発券情報を伝達することにより、照合時に遠隔地からの架電に成功したとしても、発券に必要なデータ埋込音声を発券装置３に伝達できないので、不正なチケットの発券をより効果的に抑止することができる。

〔第２実施形態の変形例〕
上記の第２実施形態では、電話回線ＴＬを介した音声通話により、サーバ２からデータ埋込音声を送信して利用者端末４で受信した。しかし、データ埋込音声は、電話回線ＴＬを介した音声通話以外の方法で利用者端末４に伝達され、利用者端末４のスピーカ４０７から出力されてもよい。例えば、データ埋込音声を、ネットワークＮＷを介したライブストリーミングによりサーバ２から送信して利用者端末４で受信し、利用者端末４にてデータ埋込音声をストリーミング再生することでスピーカ４０７から出力するようにしてもよい。また、データ埋込音声を、ネットワークＮＷを介して音声データファイルとして送信し、利用者端末４でこれを受信して、利用者端末４にて当該音声データファイルを再生することでデータ埋込音声をスピーカ４０７から出力するようにしてもよい。これらの方法によれば、サーバ２から利用者端末４への伝達過程においてデータ埋込音声が劣化しないので、発券情報の伝達にエラーが生じにくくすることができる。

また、データ埋込音声を、ネットワークＮＷを介して音声データファイルとして送信する構成では、利用者端末４が受け取った音声データファイルを転送することを制限したり、他の端末で当該音声データファイルを再生することを制限したりするように構成してよい。例えば、音声データを発券処理時のＣｏｏｋｉｅ情報やネットワークＮＷを介したデータ通信のセッション情報等と紐づけ、発券処理に用いた利用者端末４でのみ音声データファイルを再生できるようにするとよい。

〔第３実施形態〕
本発明の第３実施形態に係るチケット管理システムは、紙のチケットの発券方法が第１実施形態とは異なっている。すなわち、第２実施形態では、照合（図８のステップＳ４５０）を行うまでは第１実施形態と同様であるが、照合に成功した後、発券装置３から紙のチケットを発券させるための手順及び当該手順に関連したハードウェア構成において異なっている。

図１１は、第３実施形態における、発券装置３による発券処理の手順を示すフローチャートである。発券処理に先立ち、利用者が利用者端末４のブラウザ等を起動し、券面ＵＲＬにアクセスする。券面ＵＲＬへのアクセスはサーバ２により管理される。利用者端末４は、券面ＵＲＬにアクセスするときに、アクセスに用いているブラウザ等のＵＡ情報及びチケットを受け取るために受取ＵＲＬにアクセスしたときにブラウザ等に残されたＣｏｏｋｉｅ情報を、サーバ２に送信する。

券面ＵＲＬにアクセスすると、利用者端末４の表示部４０５には、券面の画像とともに紙発券ボタンが表示される。この紙発券ボタンを押下すると（ステップＳ９００）、発券処理が開始される。発券処理の開始に伴い、当該チケットの使用、譲渡、更なる発券ができない状態とされる。

ステップＳ９００で利用者が紙発券ボタンを押下すると、利用者端末４には発券機番号の入力を促す画面が表示される。これに応じて表示部３０５に表示されている発券機番号を利用者端末４に入力すると、利用者端末４は、サーバ２に発券機番号を送信する（ステップＳ９１０）。紙発券ボタンの押下は、本発明における発券開始操作の一例である。サーバ２は、発券機番号を受け取ると、利用者端末４に発券用電話番号を送信する（ステップＳ９２０）。この発券用電話番号は固定の電話番号でもよいが、複数の候補電話番号から選択された１つの番号を送信するようにして、表示の都度、異なる番号としてもよい。

続いて、利用者端末４は、ステップＳ７２０で受け取った発券用電話番号及び紙チケット発券のための照合を開始するための照合開始ボタンを、表示部４０５に表示する（ステップＳ９３０）。利用者により照合開始ボタンが押下されると、サーバ２は、押下時刻を記録する（ステップＳ９４０）。

続けて、サーバ２は、押下時刻から所定の有効操作時間内（例えば４秒以内）に、チケットに紐づけて記録されている利用者電話番号の電話（通常は利用者端末４）から当該発券用電話番号に架電されたか否かを判定する（ステップＳ９５０）。この有効操作時間は、発券用電話番号を遠隔地に伝え、当該遠隔地からの代行操作により電話番号を掛けることが困難な程度に短い時間とするとよい。

ステップＳ９５０において、サーバ２は、押下時刻から所定の有効操作時間内（例えば４秒以内）に、チケットに紐づけて記録されている利用者電話番号の電話（通常は利用者端末４）から当該発券用電話番号に架電されたか否かを、次のようにして判定する。サーバ２は、電話通信部２０４により発券用電話番号にかかってきた電話を受電する。そして、電話通信部２０４は、発信元の電話番号及び架電された電話番号（候補電話番号の何れか）を特定する。サーバ２は、架電された電話番号に基づきチケットＩＤを特定し、当該チケットＩＤが、受電時刻から有効操作時間分だけ遡った期間内に押下時刻が記録されたチケットＩＤであるかを確認することで、有効操作時間内に発券用電話番号に架電されたか否かを判定する。

押下時刻から有効操作時間内に発券用電話番号に、有効操作時間内に発券用電話番号に架電されなかった場合（ステップＳ９５０；Ｎｏ）にはチケットは発券されず、発券ができない旨を通知する画面を利用者端末４の表示部４０５に表示させるとともに、当該チケットを使用可能な状態に戻して（ステップＳ９６０）、発券処理が終了する。なお、発信元の電話番号が、チケットに紐づけて記録されている利用者電話番号と１文字違いだった場合等にはその旨を案内するように構成するとよい。このようにすれば、利用者電話番号を誤って登録していることに容易に気づかせ、利用者に利用者電話番号の修正を促すことができる。

一方、有効操作時間内に発券用電話番号に架電された場合（ステップＳ９５０；Ｙｅｓ）、サーバ２は、照合処理を行う（ステップＳ９７０）。照合処理では、チケットＩＤに紐づけられている利用者電話番号をデータベースＤＢから抽出し、ステップＳ９５０で着信した番号と照合する。また、サーバ２は、チケットの持主の利用者ＩＤに紐づけて記録されているＣｏｏｋｉｅ情報及びＵＡ情報を、券面ＵＲＬにアクセスした際に利用者端末４から送信されたＣｏｏｋｉｅ情報及びＵＡ情報と照合する。照合処理で情報の一致が確認されなかった場合（ステップＳ９７０；Ｎｏ）にはチケットは発券されず、発券ができない旨を通知する案内画面を利用者端末４の表示部４０５に表示させるとともに、当該チケットを使用可能な状態に戻して（ステップＳ９６０）、発券処理が終了する。

一方、照合処理で情報の一致が確認された場合（ステップＳ９７０；Ｙｅｓ）、サーバ２は、識別コード（バーコード、ＱＲコード（登録商標）等）を送信し、利用者端末４の表示部４０５に表示させる（ステップＳ９８０）。サーバ２が送信する識別コードは、チケット券面のデータを含んでもよいし、必要に応じて暗号化されたチケットＩＤのみとしてもよい。チケットＩＤのみを含める場合には、発券装置３は、チケットＩＤとチケット券面のデータとを対応付けたデータを、予めサーバ２から受け取って記憶部３０１に格納しておくとよい。あるいは、識別コードを読み取る都度、チケットＩＤに対応するチケット券面のデータをサーバ２に照会してネットワークＮＷを介して受け取るようにしてもよい。また、識別コードは、チケットを発券するために必要な情報のネットワークＮＷ上における所在を示すＵＲＬ等の情報を含んでもよい。また、識別コードは、ステップＳ９１０で入力された発券機番号を含むとよい。また、識別コードは、ステップＳ９４０で記録された押下時刻、発券用電話番号に架電された時刻等の発券処理の時刻を示すタイムスタンプ情報を含むとよい。識別コードは、利用者端末４の表示部４０５に表示されてから所定の時間が経過すると表示が消えるように構成するとよい。

利用者は、利用者端末４の表示部４０５を発券装置３のカメラ３０７にかざして、識別コードを発券装置３に読み取らせる（ステップＳ９９０）。そして、発券装置３は、読み取った識別コードが正当なものか否かを判定する（ステップＳ１０２０）。

受け取った識別コードが正当なものか否かは、例えば以下のように判定するとよい。識別コードが発券機番号を含む場合には、識別コードを読み取った発券装置３の発券機番号と識別コードに含まれる発券機番号とが一致することを正当と判断する条件に含めるとよい。また、識別コードがタイムスタンプ情報を含む場合には、現在時刻が当該タイムスタンプ情報で示される時刻から所定の発券有効期間内に含まれていることを正当と判断する条件に含めるとよい。また、照合処理で情報の一致が確認されてから所定の時間内に識別コードが読み取られたことを条件に含めてもよい。その他、ステップＳ９８０での照合が行われたことを示す情報が発券情報に含まれること等を正当と判断する条件に含めるとよい。

読み取った識別コードが正当なものである場合（ステップＳ１０２０；Ｙｅｓ）、発券装置３は、印刷部３０４でチケットを印刷し、ステップＳ１０２０での判断の結果、当該チケットを発券したことを示す情報等をサーバ２に送信する（ステップＳ１０３０）。これを受けてサーバ２は、当該チケットについてデータベースＤＢに紙発券を行ったことを記録し（ステップＳ１０４０）、発券処理を終了する。

一方、読み取った識別コードが正当なものでない場合（ステップＳ１０２０；Ｎｏ）、発券装置３は、表示部３０５に発券できない旨を表示し、ステップＳ１０４０での判断の結果、当該チケットを発券しなかったことを示す情報等をサーバ２に送信する（ステップＳ１０５０）。これを受けてサーバ２は、当該チケットを使用可能な状態に戻して（ステップＳ１０６０）、発券処理を終了する。

以上のようにして、紙のチケットを発券する際に、利用者端末４に表示させた識別コードを発券装置３にて読み取ることにより、照合時に遠隔地からの架電に成功したとしても、発券に必要な識別コードを発券装置３に伝達できないので、不正なチケットの発券をより効果的に抑止することができる。

なお、上記に本発明の実施形態を説明したが、本発明はこれらの例に限定されるものではない。また、前述の実施形態に対して、当業者が適宜、構成要素の追加、削除、設計変更を行ったものや、各実施形態の特徴を適宜組み合わせたものも、本発明の要旨を備えている限り、本発明の範囲に含有される。

１ チケット管理システム
２ サーバ
３ 発券装置
４ 利用者端末
ＮＷ ネットワーク
ＴＬ 電話回線網

Claims (15)

1. 制御部と、
   チケットを識別するチケットＩＤと利用者電話番号とを対応付けて記憶するデータベースと、
   利用者の利用者端末とネットワークを介して通信可能な通信部と、を備えるチケット管理サーバであって、
   前記制御部は、
   前記利用者端末にてチケットに対する発券開始操作がなされた旨を前記通信部にて受信したことに応じて、前記発券開始操作がなされてから所定の有効操作時間内に、前記通信部にて受電可能な所定の発券用電話番号に当該チケットのチケットＩＤに対応付けられた前記利用者電話番号からの着信があったか否かを判定し、
   前記発券用電話番号に当該チケットのチケットＩＤに対応付けられた前記利用者電話番号からの架電があったことを含む判定条件を満たした場合に、発券装置に前記チケットを発券させることを特徴とするチケット管理サーバ。
2. 前記通信部は、
   ネットワークを介して前記利用者の利用者端末と通信可能なネットワーク通信部と、
   電話回線を通じて前記利用者端末と通信可能な電話通信部とを備え、
   前記制御部は、
   前記利用者端末にてチケットに対する発券開始操作がなされた旨を前記ネットワーク通信部にて受信したことに応じて、前記発券開始操作がなされてから所定の有効操作時間内に、前記電話通信部にて受電可能な所定の発券用電話番号に当該チケットのチケットＩＤに対応付けられた前記利用者電話番号からの着信があったか否かを判定し、
   有効操作時間内に前記発券用電話番号に当該チケットのチケットＩＤに対応付けられた前記利用者電話番号からの架電があったことを含む判定条件を満たした場合に、前記チケットを発券させるための発券情報を埋め込んだデータ埋込音声を前記利用者端末のスピーカから出力せしめ、前記発券装置に前記利用者端末から出力されたデータ埋込音声に基づき前記チケットを発券させることを特徴とする請求項１に記載のチケット管理サーバ。
3. 前記データ埋込音声に埋め込まれる発券情報は、発券するチケットの券面の印刷内容を含むことを特徴とする請求項２に記載のチケット管理サーバ。
4. 前記データ埋込音声を、電話回線を通じた音声通話により前記利用者端末に送信することを特徴とする請求項２または３に記載のチケット管理サーバ。
5. 前記データ埋込音声を、ネットワークを通じたライブストリーミングにより前記利用者端末に送信することを特徴とする請求項２または３に記載のチケット管理サーバ。
6. 前記データ埋込音声を、当該データ埋込音声を含む音声データファイルとしてネットワークを通じて前記利用者端末に送信することを特徴とする請求項２または３に記載のチケット管理サーバ。
7. 前記発券開始操作に伴い複数の前記発券装置のいずれから発券するかを示す識別情報を受け取り、
   前記判定条件が満たされた場合に、受け取った識別情報に対応する発券装置にチケットを印刷させることを特徴とする請求項１から６の何れか１項に記載のチケット管理サーバ。
8. 前記チケット管理サーバは、前記発券開始操作の前に前記利用者の利用者端末に、第１サイトにアクセスするよう促し、
   当該第１サイトに対する前記利用者端末によるアクセスに応じて、前記利用者端末に当該第１サイトへのアクセス履歴情報を記録せしめ、
   前記発券開始操作を行うために前記利用者端末に第２サイトにアクセスせしめ、前記利用者端末が第２サイトにアクセスしたことに応じて前記利用者端末から前記第１サイトへのアクセス履歴情報を取得し、
   前記制御部が行う判定における前記判定条件は、前記第１サイトへのアクセス時に前記利用者端末に記録せしめたアクセス履歴と、前記第２サイトへのアクセス時に前記利用者端末から取得したアクセス履歴とが一致することを含むことを特徴とする請求項１から７の何れか１項に記載のチケット管理サーバ。
9. 前記チケット管理サーバは、前記発券開始操作の前に前記利用者の利用者端末に、第１サイトにアクセスするよう促し、
   当該第１サイトに対する前記利用者端末によるアクセスに応じて、前記利用者端末から当該第１サイトへのアクセスに用いたユーザエージェントを示す第１ユーザエージェント情報を取得し、
   前記発券開始操作を行うために前記利用者端末に第２サイトにアクセスせしめ、前記利用者端末が第２サイトへのアクセスに用いたユーザエージェントを示す第２ユーザエージェント情報を取得し、
   前記制御部が行う判定における前記判定条件は、前記第１ユーザエージェント情報と前記第２ユーザエージェント情報とが一致することを含むことを特徴とする請求項１から８の何れか１項に記載のチケット管理サーバ。
10. 制御部と、
    チケットを識別するチケットＩＤと利用者電話番号とを対応付けて記憶するデータベースと、
    ネットワークを介して利用者の利用者端末と通信可能なネットワーク通信部と、
    電話回線を通じて前記利用者端末と通信可能な電話通信部とを備えるチケット管理サーバであって、
    前記制御部は、
    前記利用者端末にてチケットに対する持主登録開始操作がなされた旨を前記ネットワーク通信部にて受信したことに応じて、前記持主登録開始操作がなされてから所定の有効操作時間内に、前記電話通信部にて受電可能な所定の登録用電話番号に当該チケットのチケットＩＤに対応付けられた前記利用者電話番号からの着信があったか否かを判定し、
    有効操作時間内に前記登録用電話番号に当該チケットのチケットＩＤに対応付けられた前記利用者電話番号からの架電があったことを含む判定条件を満たした場合に、前記チケットを前記利用者の持つ利用者端末に使用可能に表示させるチケット管理サーバ。
11. 前記持主登録開始操作がなされたことに応じて、前記登録用電話番号を前記利用者の連絡先に送信することを特徴とする請求項１０に記載のチケット管理サーバ。
12. 前記登録用電話番号として複数の候補電話番号を備え、
    前記持主登録開始操作がなされたことに応じて、複数の候補電話番号の何れかを前記登録用電話番号として前記利用者の連絡先に通知することを特徴とする請求項１１に記載のチケット管理サーバ。
13. 前記チケット管理サーバは、前記持主登録開始操作の前に前記利用者の利用者端末に、第１サイトにアクセスするよう促し、
    当該第１サイトに対する前記利用者端末によるアクセスに応じて、前記利用者端末に当該第１サイトへのアクセス履歴情報を記録せしめ、 前記持主登録開始操作を行うために前記利用者端末に第２サイトにアクセスせしめ、前 記利用者端末が第２サイトにアクセスしたことに応じて前記利用者端末から前記第１サイ トへのアクセス履歴情報を取得し、
    前記制御部が行う判定における前記判定条件は、前記第１サイトへのアクセス時に前記利用者端末に記録せしめたアクセス履歴と、前記第２サイトへのアクセス時に前記利用者端末から取得したアクセス履歴とが一致することを含むことを特徴とする請求項１０から１２の何れか１項に記載のチケット管理サーバ。
14. 前記チケット管理サーバは、前記持主登録開始操作の前に前記利用者の利用者端末に、第１サイトにアクセスするよう促し、
    当該第１サイトに対する前記利用者端末によるアクセスに応じて、前記利用者端末から当該第１サイトへのアクセスに用いたユーザエージェントを示す第１ユーザエージェント情報を取得し、
    前記持主登録開始操作を行うために前記利用者端末に第２サイトにアクセスせしめ、前記利用者端末が第２サイトへのアクセスに用いたユーザエージェントを示す第２ユーザエージェント情報を取得し、
    前記制御部が行う判定における前記判定条件は、前記第１ユーザエージェント情報と前記第２ユーザエージェント情報とが一致することを含むことを特徴とする請求項１０から１３の何れか１項に記載のチケット管理サーバ。
15. コンピューターを、請求項１から１４の何れか１項に記載のチケット管理サーバとして機能させるプログラム。
    

Images