JP7341023B2 - 電子チケットの処理方法及びプログラム - Google Patents

Description

携帯端末に電子チケットをダウンロードし、イベント会場の入場ゲートで携帯端末のディスプレイ画面に対して所定の入力操作が行われたことを条件として入場を許可する電子チケットの処理方法に関するものである。

従来の紙チケットに代わり、インターネット上でチケットの申込や支払を受け付けチケット購入者に電子チケットを配信するサービスが普及しつつある。
これは、紙チケットには、他人への譲渡が容易であるため、不正転売が行われやすいという問題があるからである。

この問題を解決する手段として期待されているのが電子チケットであるが、次のような問題がある。すなわち、電子チケットを購入していない人が自分の携帯端末に不正な手段でチケット画像を表示させ、目視による入場確認をすり抜けてしまうという問題である。この不正入場を防止するために、紙チケットでは「もぎり」、すなわちチケットの半券をもぎり取るが、電子チケットではチケット画像を元の表示状態とは異なるように変化させる。この表示状態を変化させる処理（以下、「電子もぎり」という）に関する技術が種々開発されている。

例えば、特許文献１に開示された「チケット処理方法およびプログラム」の発明、および特許文献２に開示された「電子チケット管理方法および電子チケット管理プログラム」の発明では、電子チケット画像を携帯端末のディスプレイ画面に表示し、この画像に対してタップ入力またはスライド入力などの操作を行うことによって、電子もぎり処理を実行するのである。

特開２０１４－１４９５５６号公報 特開２０１５－１９７８６７号公報

特許文献１、２に記載の技術を利用すれば、高価な装置を導入することなく、不正入場を阻止できる。しかも、紙チケットをもぎるときと同様の直感的な操作性が得られる。
しかし、チケットが画面上の画像であるという点で、次の問題がある。それは、携帯端末のディスプレイ画面は光の反射や画面の明暗などが原因で、表示内容を読み取りづらいことがあり、紙チケットよりも入場処理に時間がかかりがちであるという問題である。
また、画面上の入力操作を利用者に行わせるのでは、不慣れな利用者に対して、係員が電子チケットを画面表示したり入力したりする操作を説明しなくてはならないこともある。そこで、特許文献１，２では、利用者に代わって係員が携帯端末の画面を操作するのであるが、係員が指で携帯端末に触れるため、利用者によってはこれを嫌がるという問題もある。

このような問題点に鑑み、本発明は、利用者本人が簡単な画面操作をすることで、電子もぎり処理ができるようにすることを目的とする。

前記の目的を達するために、本発明に係る電子チケットの処理方法は、
利用者の使用する利用者端末とインターネットを介して通信可能に接続し、利用者情報およびチケット情報を登録するデータベースを備えた管理コンピュータが、
前記利用者端末からのチケット購入要求及び利用者特定情報（例：利用者端末の機種固有情報）を受信すると、仮チケットを発行し、画像関連データを含む仮チケット情報を前記利用者特定情報と対応づけて前記データベースに登録するとともに前記利用者端末に送信するステップと、
チケット対象（例：コンサートやスポーツの試合）が開催される所定の時間帯（例：開場から開演の時間まで）に、前記利用者端末から前記利用者特定情報とともに正式チケット送信要求を受信するステップと、
前記正式チケット送信要求とともに受信した利用者特定情報と前記データベースに登録されている利用者特定情報とを照合し、一致しているならば、前記時間帯のみ入力操作が可能な複数の操作ボタンが付加された画像関連データを含む承認前正式チケット情報を前記利用者端末に送信するステップと、を行い、
前記利用者端末の画面上に承認前正式チケット画像（この承認前正式チケット画像は前記承認前正式チケット情報に含まれる前記画像表示関連の情報によって表示される）を表示し、付加表示された前記操作ボタンの２個以上に対する入力操作（下記の実施の形態では、タッチパネルディスプレイ上でのタップ入力）が所定の入場判定用コード（下記の実施の形態では、主催者側によって予め定められた４桁の数字）と一致することを条件に、前記承認前正式チケット画像とは異なる承認後正式チケット画像を前記画面に表示させることを特徴とする。

これによって、次のような利点がある。
第一に、チケット購入者と、会場に来場した者との照合が容易であるということである。携帯端末の機種固有情報などの利用者特定情報が一致することを確認するだけで、同一人と判断できるので、不正転売の防止が容易である。
第二に、入場直前の正式チケット画像と、係員の目視チェック時の画像とが異なるため、係員による入場可否の判断が迅速にできる。そのため、入場ゲートでの混雑を回避でき、紙チケットと電子チケットとを同一の入場ゲートで対応することも可能である。
第三に、紙チケットのもぎりに相当する画面上の入力操作は、利用者本人が行えるので、自分の携帯端末を係員に渡して操作してもらうには及ばない。
第四に、係員の目視チェックによるだけで入場の可否が判断できるので、検札用の機器を設置しなくてよい。

本発明によれば、不正転売と不正入場という電子チケットの問題点を同時に解決できる。

チケットの販売から入場までの処理概要を説明する図である。 仮チケット画像と、これに対応する正式チケット画像（入場承認前）を例示する図である。 サーバの機能ブロック構成図である。 利用者チケット情報データベースに記憶する情報を例示する図である。 イベント情報データベースに記憶する情報を例示する図である。 利用者端末の機能ブロック構成図である。 チケットの販売から入場までの処理フロー図である。 正式チケット画像が、入場ゲートにおいて異なる画像に変化したことを例示する図である。 正式チケット画像が、入場ゲートにおいて異なる画像に変化したことを例示するその他の図である。 利用者に配信可能なコンテンツを説明する図である。

本発明の一実施の形態のシステム（以下、「本システム」）について、図面を参照しながら、次の順で説明する。
（１）本システムによるチケット処理機能の概要
（２）本システムの構成
（２－１）本システムの全体構成
（２－２）本システムのサーバの機能ブロック構成
（２－３）本システムの利用者端末の機能ブロック構成
（３）本システムの動作
（４）本システムとコンテンツ配信システムとの連携
（５）変形例など

《 （１）本システムによるチケット処理機能の概要 》
図１は、本システムが提供するチケットの販売から入場許可までの機能の概要を説明する図である。
予め、電子チケットを利用しようとする人（以下、「利用者」）の携帯端末（以下、「利用者端末」）に、ネットワーク上のアプリストアなどからチケット購入プログラム（以下、「専用チケットアプリ」）をダウンロードしてインストールしておく。
利用者は、利用者端末２に保存された専用チケットアプリを起動し、システム管理コンピュータ（以下、「サーバ」）に対してチケットの申込をする（ステップＳ１）。
サーバ１は、受信した利用者端末２の機種固有情報がデータベースに未登録であれば、これを登録する（ステップＳ２）。以後、この機種固有情報がチケットおよびチケット所持者の正当性の確認の際に参照される。
サーバ１は、チケットの残数があれば仮チケットを利用者端末２に送信し、利用者端末２はこれを画面上に表示する（ステップＳ３）。この「仮チケット」とは、後述する「正式チケット」の引換券であり、チケット購入の証明となるものである。

利用者は、当日会場の入場ゲート付近に掲示されたＱＲコード（登録商標）に代表されるデータコードを仮チケット入手時に用いた利用者端末２で読み込み、正式チケットの発行をサーバ１に要求する（ステップＳ４）。
ここで、「正式チケット」とは、入場ゲートを通る際に必要となるチケットであり、原則として開演前の短時間に限りサーバ１から受信できる。
サーバ１は、正式チケットの発行を要求してきた利用者端末２の機種固有情報と仮チケット取得済みの利用者端末２の機種固有情報とを照合し（ステップＳ５）、一致すれば座席番号等の追加情報を含む正式チケットを生成して送信する（ステップＳ６）。この正式チケット画像の構成要素として２個以上の操作ボタンが含まれる。
利用者端末２の画面に表示された正式チケットを入場ゲートの係員に提示し、係員の指示どおりに操作ボタンに対する入力操作を行う。この入力操作の対象となる正式チケットを「承認前正式チケット」という。指示どおりに操作したならば、画面上の正式チケットが表示変化する（ステップＳ７）。係員はこの表示変化、すなわち電子もぎりを目視チェックし、入場ゲートの通過を承認する（ステップＳ８）。この目視チェックの対象となって入場を許可された正式チケットを「承認後正式チケット」という。

図２は、仮チケットと正式チケットを例示する図である。図２（ａ）の仮チケット画像にはチケットＩＤとチケット属性（例えば、イベント名、会場名、開催日、開場時間、開演時間など）が表示されている。図２（ｂ）の正式チケット画像には座席番号などの仮チケットにはない情報が付加されており、当日にならなければ分からない背景画像や背景色が付されることもある。また、正式チケットには、入場チェック時に用いられる複数の操作ボタンが付加されて表示される。図２の例では、それぞれ “１”、“２”、“３”、“４”のラベルを持つ４個の操作ボタンが、画面の４隅に近い位置に表示されている。この操作ボタンの２個以上を予めシステムが定めた順序でタップ入力すると、正式チケットの画像が変化し、この変化を目視した係員が入場を許可するのである。
以上、本システムの概要を説明した。
続いて、本システムの構成と動作を詳しく説明する。

《 （２）本システムの構成 》
《 （２－１）本システムの全体構成 》
本システムでは、図３に示すように、インターネットＮを介してサーバ１と利用者端末２とが通信可能に接続する。
サーバ１は、チケットの販売から入場管理までの処理を行う情報処理装置であり、１台あるいは複数台からなる。
利用者端末２は、本システムを利用してチケットを購入し、当日会場に持参して入場許可を受ける人（利用者）が使用する端末装置であり、スマートフォンやタブレット端末などの携行可能な情報処理装置である。

《 （２－２）本システムのサーバの機能ブロック構成 》
サーバ１の機能ブロック構成について、図３を参照しながら説明する。サーバ１は、制御部１１、記憶部１２を備える。また、インターネットＮを介して利用者端末２とデータの送受信を行う通信インターフェース部１３、マウス、キーボード、ディスプレイなどの入出力部１４も備える。

記憶部１２は、利用者チケット情報データベース（以下、「利用者チケットＤＢ」）１２１、イベント情報データベース（以下、「イベント情報ＤＢ」）１２２を備えるとともに、サーバ１が各種処理を実行するために必要となるコンピュータプログラムやデータを記憶する。また、各種処理の実行中にデータを一時的に記憶するための作業領域としても用いられる。記憶部１２は、ＲＯＭ、ＲＡＭ、ハードディスクなどから構成される。

利用者チケットＤＢ１２１について図４を参照しながら説明する。
利用者チケットＤＢ１２１は、利用者端末２から本システムに最初にアクセスがあった時点で利用者登録をする。サーバ１が生成した利用者ＩＤ（Ａ１）が付与され、同時に利用者端末２の機種固有情報（Ａ２）が登録される。この機種固有情報は、本システムが提供する機能の実施において一人の利用者を特定する情報として中心的な役割を果たすのである。
利用者端末２からのチケット購入申込を受けて、利用者毎の、以下のようなチケット販売情報（Ａ３）が登録される。
・チケットを販売できたときはチケットＩＤを生成して登録し、仮チケットデータを登録する。
・座席番号は、当初は未定であるが、開催が近づいた所定の期間内に決定し登録する。
・座席番号などの利用者毎に異なる情報が記載された正式チケットデータを登録する。
・各種ステータスを登録する。ステータスには、チケットを購入できたか、代金を支払い済みか、正式チケットを発行したか、当日来場したか等が含まれる。
利用者個人情報（Ａ４）として、必要であれば氏名、住所、性別、年齢、連絡先などを登録する。

仮チケットデータおよび正式チケットデータはチケット属性データと画像関連のデータを含んでいる。チケット属性データは、イベントの名称、開催日時、演目、出演者、座席番号、料金など、当該イベントに関する種々のデータである。画像関連のデータには、チケット画像の元となる画像部品（例えば、チケット画像の背景に使用される写真や、背景との前面に表示されるデザイン化された文字や絵など）、チケット画像の生成を規定したスクリプトが含まれる。

イベント情報ＤＢ１２２について図５を参照しながら説明する。本システムは通常複数のイベントを対象とするので、各イベントにはイベントＩＤ（Ｂ１）を付与してイベント情報（Ｂ２）、チケット情報（Ｂ３）およびその他の情報を管理する。 イベント情報（Ｂ２）には、イベント名称、出演者、開催日・開場時間・開演時間、会場名などが含まれる。 チケット情報（Ｂ３）には、販売総数、残数、発券金額、販売期間などが含まれる。また、仮チケットから正式チケットへの交換時間、正式チケットに固有の画像情報、例えば背景画像も登録する。仮チケットから正式チケットへの交換時間として、開演前の２時間といったような短時間を登録する。正式チケットは、不正行為防止の観点より、イベント直前に利用者に発行することが望ましいからである。 正式チケットには座席番号のように利用者特有の情報もあるが、背景画像などの共通な情報はここに登録する。背景の絵柄や色はイベント毎に変え、開場時間にならなければわからないようにすると不正防止に効果がある。事前に絵柄などが分かっていると不正な行為を誘発しかねないからである。他に、入場ゲートで利用者による入力と照合するための入場判定用データも登録する。

次に、制御部１１の機能ブロック構成について説明する（図３を参照）。
制御部１１は、利用者入力受付部１１１、チケット販売部１１２、正式チケット発行部１１３、座席決定部１１４などを含む。これら各部の機能は、記憶部１２に格納されたコンピュータプログラムをＣＰＵがメモリ上に読み込んで、読み込んだコードを実行することによって実現されるが、その一部をハードウェアで実現してもよい。

利用者入力受付部１１１は、利用者端末２から送信される各種データを取得する。これらのデータには、チケット購入申込とそれに必要な個人情報および機種固有情報が含まれ、取得した情報は利用者チケットＤＢ１２１に登録する。また、チケット購入後には、当日イベント会場から正式チケットへの交換要求が送信されてくるので、これを受信する。

チケット販売部１１２は、利用者入力受付部１１１がチケット購入申込を受信すると、残数の有無を、イベント情報ＤＢ１２２を参照することによって確認する。残数がなければ、その旨を利用者端末２に送信する。 残数があっても、利用者チケットＤＢ１２１を参照し、すでにチケット購入済みであれば、チケットを販売しない。１台の利用者端末２で購入できるチケットは１枚が原則だからである。チケットを販売できるのであれば、チケットＩＤを生成し、このチケットＩＤを表示した仮チケットを生成して利用者端末２に送信する。 なお、購入申込が有った時点では申込を受け付けた旨を送信するにとどめ、所定期間内に代金支払があった時点で仮チケットを送信するようにしてもよい。利用者端末２で簡単にキャッシュレス決済ができるのであれば、インストールした決済アプリによって利用者の口座からシステム側の口座へ振り込むようにする。この場合は、即時振り込みが完了するので申込とほぼ同時に仮チケットを送信できる。ただし、支払方法は、本発明にとって本質的ではないので、詳しい説明は省略する。

正式チケット発行部１１３は、イベント開演前の所定の時間帯に利用者端末２からアクセスがあったときに、利用者チケットＤＢ１２１を参照して、機種固有情報の一致を確認したうえで、座席番号を含む正式チケットのデータを利用者端末２に送信する。ここで、送信されるデータには、正式チケットの画像に付加される複数の操作ボタンが含まれる。

座席決定部１１４は、正式チケット発行開始前に座席番号を決定し、利用者チケットＤＢ１２１に登録する。この座席番号は、正式チケット発行部１１３によって参照され、正式チケットのデータに含まれる。なお、座席の指定は開場の直前までに行えばよいのであって、仮チケット発行後の何時行ってもよい。ただし、座席指定情報を利用者に開示するのは正式チケットデータの送信時とすることが望ましい。不正転売防止の観点からである。

《 （２－３）本システムの利用者端末の機能ブロック構成 》
利用者端末２は、図６に示すように、記憶部２１、入出力部２２、通信インターフェース部２３、制御部２４を備える。

記憶部２１は、ＲＯＭ、ＲＡＭなどから構成され、制御部２４が各種処理を実行するために必要なプログラムやデータを記憶したり、処理実行中にデータを一時記憶するための作業領域として用いられたりする。 入出力部２２には、タッチパネルディスプレイ２２１が含まれる。タッチパネルディスプレイ２２１は、画面表示手段であるとともに、タップ入力やスライド入力などの操作を受け付ける入力操作手段でもある。また、当日会場に掲示されたＱＲコードを読み取るためにカメラ機能は必須である。 通信インターフェース部２３は、インターネットＮを介してサーバ１とデータの送受信を行う。

制御部２４は、例えばＣＰＵによって構成され、専用のチケットアプリ２１１及びその他のプログラムを実行する。これにより、サーバ１とデータを送受信して本システムによる各種機能の提供を受けることができる。 利用者端末２は、チケットアプリ２１１を予めインストールして記憶部２１に格納しておく。本システムが提供する機能を利用する場合、利用者端末２においてチケットアプリ２１１を起動し、サーバ１と情報の送受信を行う。 制御部２４は、チケットアプリ２１１等のプログラムをメモリ上に展開し、チケット購入部２４１、仮チケット表示部２４２、正式チケット要求部２４３、正式チケット表示部２４４、正式チケット更新表示部２４５等として機能する。

チケット購入部２４１は、サーバ１にチケットの購入を申し込み、残数があればサーバ１から仮チケットを受信し、記憶部２１に保存する。サーバ１へ申し込む際に、必要であれば住所、氏名、性別、年齢なども送信する。

仮チケット表示部２４２は、受信した仮チケットデータに含まれる画像部品を、同時に受信したスクリプトに従い、タッチパネルディスプレイ２２１に表示する。

正式チケット要求部２４３は、イベント会場の入場ゲートを通る際に必要となる正式チケットを受信する。具体的には、会場に掲示されているＱＲコードを、チケットアプリ２１１を起動させた状態で読み取ると、サーバ１に正式チケット送信要求が利用者端末２の機種固有情報とともに送信される。サーバ１に送信した機種固有情報が、利用者チケットＤＢ１２１に登録済の機種固有情報と一致している場合にのみ正式チケットを取得できるのである。

正式チケット表示部２４４は、受信した正式チケットデータに含まれる画像部品を、同時に受信したスクリプトに従い、タッチパネルディスプレイ２２１上に表示する。

正式チケット更新表示部２４５は、入場ゲートで係員が告げた入場判定用コードのとおりに正式チケットに付加された操作ボタンをタップすると、正しく入力操作が行われたことを条件に元の正式チケット画像とは異なる画像を表示する。係員が、この表示変化が適正と判断したならば、入場が許可されることになる。

以上、本システムの全体構成およびサーバ１と利用者端末２の各構成を説明した。 続いて、本システムの動作について図７を参照しながら詳しく説明する。

《 （３）本システムの動作 》
本システムは、利用者端末２がサーバ１と通信するためのＱＲコードを、ファンサイトや新聞・雑誌の広告などに掲載する。このＱＲコードには、サーバ１を特定する情報が含まれている。 利用者端末２はチケットアプリ２１１を起動してこのＱＲコードを読み込む（Ｓ１１）。これによりサーバ１にアクセスし、チケットの購入を申し込むことになり、同時に利用者端末２の機種固有情報もサーバ１に送信する（Ｓ１２）。サーバ１は、この機種固有情報を利用者チケットＤＢ１２１に登録する（Ｓ１３）。

サーバ１は、チケットの残数があれば、仮チケットを発行し、利用者端末２に仮チケットデータを送信する（Ｓ１４）。
このように本システムでは、利用者端末２で購入するので大量購入は不可能である。利用者端末２の機種固有情報で利用者管理を行うため、転売を業とする人がパソコンのプログラムを組んで一秒間に何回も自動でアクセスし、大量のチケットを購入するといった行為を阻止できるのである。
利用者端末２は、タッチパネルディスプレイ２２１に、図２（ａ）で示すような仮チケットの画像を表示する（Ｓ１５）。

本システムでは、イベント当日の会場において仮チケットを正式チケットへ交換しなければならない。そのために、入場ゲート付近にＱＲコードを多数掲示しておく。これを読み込むことによりサーバ１にアクセスするので、サーバ１はチケットを購入した人が当日会場に来ていることを確認できる。但しこれだけでは不正入場の防止にはならないので、後述の電子もぎり処理が必要となるのである。
当日来場した利用者は、仮チケット購入時に用いた利用者端末２にチケットアプリ２１１を起動して、掲示されたＱＲコードを読み込む（Ｓ１６）。これによりサーバ１にアクセスし、正式チケット発行要求をサーバ１に送信することになり、同時に機種固有情報も送信する（Ｓ１７）。 なお、ＱＲコードの掲示場所を入場ゲート付近などにすることは、不正防止に効果的である。通常会場内には警備スタッフなどがいるので、不正行為を抑止する心理的効果が働くからである。

サーバ１は、受信した機種固有情報が利用者チケットＤＢ１２１に登録されており、且つ正式チケットを未発行であれば（Ｓ１８でＹｅｓ）、座席番号を含む正式チケットを生成して利用者端末２に送信する（Ｓ１９）。イベントによっては身分証明書の提示が必要であるが、同一の利用者端末を使用していることを条件として、仮チケットと正式チケットを交換する本システムでは、簡単に本人確認ができる。これで不正転売を極力防止できるのである。 利用者端末２は受信した正式チケットデータをタッチパネルディスプレイ２２１に表示する（Ｓ２０）。この時点では、未だ入場許可を得ていないので、表示されたチケットを承認前正式チケットという。 Ｓ１８でＮｏの場合、すなわち機種固有情報の照合に失敗したとき或は既に正式チケットが発行されているとき、サーバ１は利用者端末２にエラーメッセージを送信したり、受信した機種固有情報をログファイルなどに登録したり、仮チケットを無効化したり等のエラー処理を行う（Ｓ２１）。

図８（ａ）に例示するように、承認前正式チケット画像には、仮チケットと同様にイベント名、会場名、開催日、開場時間、開演時間などが表示されているとともに、仮チケットにはない座席番号などの情報も含まれる。承認前正式チケット画像には、チケット属性を表示するほかに、これにオーバーラップして“１”、“２”、“３”、“４”というラベルを持つ４つの操作ボタンが画面の4隅に近い位置に表示される。

ここで危惧されるのは、入場前に誤って入力処理をしてしまうことである。これを防止するために、「入場ゲートにて入力操作を行ってください」等の警告ボタンをチケット画像上に付加表示し、このボタンをタップしてからでないと操作ボタンの操作ができないようにしてもよい。

承認前正式チケットを入場ゲートの係員に提示すると、係員が３～４桁の数字である入場判定用コードを告げるので、利用者は言われたとおりに画面上の数字をタップする（Ｓ２２）。これが、本システムにおける電子もぎり操作である。このもぎり操作はボタンをタップするだけなので、画面操作に不慣れな人であっても簡単にできる。そのため、係員ではなく利用者本人がもぎり操作を行えるのであるが、この点も本システムの特徴のひとつである。 タップされた数字は、タッチパネルディスプレイ２２１で検出され、正式チケットと同時にサーバ１から受信したスクリプトによって入場判定用コードと一致するか否かが照合される。

「入場判定用コード」は、予めイベントの主催者が決定し、当日係員に知らせておく。
この入場判定用コードは、 “２１４３”のように、全部異なる数字でもよいが、”３１３２”のように、重複可としてもよい。全部異なる数字のときは、並べ方は２４通りであるが、重複可のときは、２５６（＝４の４乗）通りもあるからである。ただし、”３３１２”のように、同じ数字が連続出現するとタップ操作の仕方によっては、正確に検出できないことがあるので、同じ数字の出現は可、但し、連続出現は不可とすればよい。この場合の数は、１０８（＝４×３×３×３）通りになる。いずれも、誤操作を防ぐには十分である。離れた位置にある４個の操作ボタンを、入場判定用コードと同じ順序で誤ってタップする可能性はゼロに近いからである。

利用者端末２にダウンロード済みのスクリプトが、利用者による入力操作と入場判定用コードとを照合して、一致している場合（Ｓ２３でＹｅｓ）に画面表示を変化させる（Ｓ２４）。これが、入場承認後正式チケットである。承認前と承認後では画像の背景色が白色から赤色に変わる（図８の（ａ）から（ｂ）への変化）といった分かりやすい変化をするものとする。この画面表示の変化を係員が目視すると入場が許可される。
このように、入場ゲートの係員は、画像が変化したことを確認するだけで、チケット所有者の入場の可否を判断できる。

承認前と承認後のチケット画像は異なっていることが一見してわかりさえすればよい。そこで、背景色の変化に限らず、図９（ａ）のように承認前正式チケットでは、操作ボタンを大きめにし、イベント名称などのチケット属性の文字を薄くし、正しく操作ボタンがタップされたなら、図９（ｂ）のように操作ボタンを消去し、チケット属性の文字を鮮明にしてもよい。
あるいは、承認前正式チケットでは、操作ボタンを大きめにし、チケット属性は表示せず、代わりに「入場ゲートで係員に見せるまでは操作ボタンをタップしないように」といった注意書きを表示し、正しく入力されたならば、操作ボタンも注意書きも消去して、チケット属性の文字を表示してもよい。
Ｓ２３でＮｏの場合，つまり画面が変化しなかったときは、再度タップ操作をし、所定回数の操作をしても表示が変化しなければ、適宜エラー処理をするものとする（Ｓ２５）。
なお、承認後画像に変化した後は、操作ボタンを消去したり操作ボタンへの入力を無効としたりすることで、承認前画像に戻らないようにする必要がある。

入場判定用コードと利用者入力との照合処理は、利用者端末２側で実行してもよいが、サーバ１との送信によって行ってもかまわない。その場合は、タップ入力をチケットアプリ２１１やスクリプトによってサーバ１に送信し、サーバ１が予め決めてあった入場判定用コードと照合し一致しているならば、入場承認後正式チケットを端末に送信するのである。このように、入場判定用コードの照合は利用者端末２側で行っても、サーバ側１で行ってもいずれでもかまわない。ただし、利用者端末２側で行ったときは、入場が承認されたことをサーバ１へ送信し、利用者チケットＤＢ１２１に記録することが望ましい。

本システムの電子もぎり操作は、次の利点がある。
操作ボタンのほかに、入力操作を検知し入場判定用コードと照合するスクリプトを利用者端末２が取り込んでいなくてはならないので、単なるスクリーンのコピーだけでは電子もぎり操作ができない。
入場ゲートの係員は、利用者に入場判定用コードを伝えて利用者自身に操作させるので、係員が利用者の携帯端末に触れなくてよい。
利用者による入力操作だけで、入場ゲートを通すことができる。入場ゲートがたいへん混雑していて、しかも座席指定が無い場合、既に入場している人が自分の携帯端末を仲間のゲート入場時にのみ貸し出すといったことはありうるが、承認後画像に変化した後なので、仲間が不正に入場することを防止できる。

ところで、入場可能な場合、画面表示が変化することに着目すると、この表示変化を利用者サービスの提供に活用しうる。例えば、通常背景色が赤く変化するのに対し、金色の背景に変わったならば、この画面を何らかの特典（例えば、握手会）への参加チケットにする、といったこともできるのである。

《 （４）本システムとコンテンツ配信システムとの連携 》
本システムは、インターネットを介して電子チケットを購入するものである。電子チケットの実体はデジタルデータであって、デジタルデータのダウンロードという点で、コンテンツ配信システムなどの映像コンテンツと異なるものではない。それならば、本システムをコンテンツ配信システムの一部に組み込んでサブシステムとしたり、連携させたりすることも可能である。

図１０は、本システムをコンテンツ配信システムの一部として組み込んだ例である。図中二重枠の矩形で表現した項目については、上記の説明の中で言及済みである。 チケット販売開始前には通常新聞やＷｅｂでプロモーション活動を行う。新聞記事などに本システムを介して購入できることを告知するとともに、本システム専用のアプリであるチケットアプリをダウンロード可能とする（Ｆ１１）。ダウンロードすると本システム側では、利用者端末２の機種固有情報を登録するので、システム側は適当なタイミングでプッシュ通知を送り、利用者端末２上でイベントの予告動画などを視聴できるのである（Ｆ１２）。 仮チケットを入手すると、チケット購入に謝意を表する映像などをダウンロードできる（Ｆ１３）。 イベント開催前にも、適当なタイミングでイベントと関連のあるコンテンツが配信されてくる（Ｆ１４）。

当日会場で本チケットを入手した後には、開場前の楽屋映像などが配信されてくる（Ｆ１５）。 イベント終了後も所定期間内は、利用者サポートを行う。このサポート期間内は、別の有料コンテンツを告知するコンテンツや後日開催される別イベントのチケット販売サイトへのリンクを通知したりする（Ｆ１６）。これは、利用者チケットＤＢ１２１に機種固有情報を登録しているので、イベント後であっても利用者端末２を廃棄したり機種変更したりしない限り、利用者端末すなわち利用者個人を特定できるからである。 このように、本システムは、コンテンツ配信システムの一部に組み込まれたり、連携したりすることで、利用者に対し各種のコンテンツを提供できるのである。つまり、本システムの電子チケットは、紙チケットとは単に媒体が異なるというだけでなく、工夫次第でいろいろな価値を付加することができる。これは、紙チケットでは実現困難なことであり、電子チケットならではの利点である。

《 （５）変形例など 》
以上、実施の形態について説明したが、これらのシステム構成、機能ブロック構成、処理フロー、データベースのテーブル構造などは例示にすぎない。

上記の実施の形態では、利用者端末２はＱＲコードを介してシステムに登録したり仮チケットを入手したりしていた。
ＱＲコードを使うことは便利ではあるが、本発明にとって必須ではない。ＱＲコードを介さずに、チケット販売用のウェブサイトから購入を申しこんだ場合も、利用者端末２の機種固有情報はシステム側に送信されるからである。重要なのは、利用者端末２の機種固有情報がシステムに登録されることなのである。

上記の実施の形態では、正式チケットを入手するために会場に掲示されたＱＲコードを読み込んでいる。しかし、仮チケット画像に正式チケット取得用のボタンを含ませ、当日の所定時間帯に限りこれをタップする等の方法で入手してもよい。
方法の如何によらず開演までの所定の時間帯に仮チケットを正式チケットに交換できればよいのである。

また、入場判定用コードを複数用意してもよい。たとえば、係員は、複数の４桁の数字を書いたメモ書きを持ち、そのうちから一つを無作為に選んで、入場者に指示してもよい。
入場判定用コードは、２桁あるいは３桁でもよい。４つの操作ボタンのうち異なる２つを順にタップする場合の数は、１２通りである。画面上離れた位置にある操作ボタンの２つを誤って入場判定用コードどおりにタップしてしまう可能性は極めて低く、実用上２桁でもかまわないのである。

上記の実施の形態では、操作ボタンのラベルは数字であったが、英字やカナなどの文字でもよく、絵や図でもよい。操作ボタン同士を区別できればよいのである。
操作ボタンの位置は画面の４隅でなくても、互いに離れた位置にあればよい。また、操作ボタンの個数は４個に限るものではなく、２個以上であれば何個でもよい。

本発明のチケット処理方法は、１台の利用者端末と１枚のチケットとがリンクしていることから転売防止に効果的である。しかも、紙チケットのもぎりと同様な効果が簡便に実現できるので不正入場も防止できる。したがって、セキュリティ上好ましい電子チケットとして幅広い支持が期待できる。

１：サーバ
１２１：利用者チケット情報データベース
２：利用者端末
２１１：チケットアプリ
２２１：タッチパネルディスプレイ
Ｎ：インターネット

Claims (5)

1. 利用者の使用する利用者端末とインターネットを介して通信可能に接続し、利用者情報およびチケット情報を登録するデータベースを備えた管理コンピュータが、
   前記利用者端末からのチケット購入要求及び利用者特定情報を受信すると、仮チケットを発行し、画像関連データを含む仮チケット情報を前記利用者特定情報と対応づけて前記データベースに登録するとともに前記利用者端末に送信するステップと、
   チケット対象が開催される所定の時間帯に、前記利用者端末から前記利用者特定情報とともに正式チケット送信要求を受信するステップと、
   前記正式チケット送信要求とともに受信した利用者特定情報と前記データベースに登録されている利用者特定情報とを照合し、一致しているならば、前記時間帯のみ入力操作が可能な複数の操作ボタンが付加された画像関連データを含む承認前正式チケット情報を前記利用者端末に送信するステップと、を行い、
   前記利用者端末の画面上に承認前正式チケット画像を表示し、付加表示された前記操作ボタンの２個以上に対する入力操作が所定の入場判定用コードと一致することを条件に、前記承認前正式チケット画像とは異なる承認後正式チケット画像を前記画面に表示させることを特徴とする電子チケットの処理方法。
2. 前記利用者特定情報は、前記利用者端末の機種固有情報であることを特徴とする請求項１に記載の電子チケットの処理方法。
3. 前記の各操作ボタンには数字、文字あるいは図がラベルとして表示されていることを特徴とする請求項１または２のいずれか１に記載の電子チケットの処理方法。
4. 利用者の携帯端末にダウンロードされ、通信ネットワークを介してチケット販売サイトにアクセスして電子チケットの購入から入場までの処理を行うチケット処理プログラムであって、
   前記携帯端末に、
   前記チケット販売サイトの管理コンピュータにチケット購入要求とともに利用者特定情報を送信し、発行された仮チケットの画像関連データを含む仮チケット情報を受信し、仮チケット画像を画面表示するステップと、
   チケット対象が開催される所定の時間帯に、前記利用者特定情報とともに正式チケット送信要求を前記管理コンピュータに送信するステップと、
   前記時間帯のみ入力操作が可能な複数の操作ボタンが付加された画像関連データを含む承認前正式チケット情報を前記管理コンピュータから受信するステップと、
   前記携帯端末の画面上に承認前正式チケット画像を表示し、付加表示された前記操作ボタンの２個以上に対する入力操作が所定の入場判定用コードと一致することを条件に、前記承認前正式チケット画像とは異なる承認後正式チケット画像を前記画面に表示させるステップと、
   を実行させることを特徴とするプログラム。
5. 通信ネットワークを介してチケット販売サイトにアクセスしてきた利用者の使用する利用者端末に対して、電子チケットの販売から入場管理までの処理を実行し、利用者情報及びチケット情報を登録するデータベースを備えたコンピュータに、
   前記利用者端末からのチケット購入要求及び利用者特定情報を受信すると、仮チケットを発行し、画像関連データを含む仮チケット情報を前記利用者特定情報と対応づけて前記データベースに登録するとともに前記利用者端末に送信するステップと、
   チケット対象が開催される所定の時間帯に、前記利用者特定情報とともに正式チケット送信要求を前記利用者端末から受信するステップと、
   前記正式チケット送信要求とともに受信した利用者特定情報と前記データベースに登録されている利用者特定情報とを照合し一致しているならば、前記時間帯のみ入力操作が可能な複数の操作ボタンが付加された画像関連データを含む承認前正式チケット情報を前記利用者端末に送信するステップと、
   を実行させることを特徴とするプログラム。

Images